The Great Gif Exchange, Week 9

I’ve been crunching at work, so I haven’t gotten much done in several weeks.

More progress .gifs, mainly working on terrain:


The Great Gif Exchange, Week 7 (+SURPRISE)

Here’s my .Gif for week 7:

I got the ProceduralMeshComponent from the wiki to work. I didn’t quite figure out how to get reliable collisions (weird things where chunks spawned in the editor didn’t line up etc.).

I will have to redo my texturing scheme, because Marching Cubes doesn’t work with just UV coordinates. I’m thinking I need to use triplanar texturing, so I’m going to have to figure out how to do that.

I couldn’t for the life of me get movement to work how I wanted. I really need to drain some time into that so that I can actually have something game-y.

BONUS! World Tree Design Doc

Here’s my cut-and-pasted notes on how I am going to design the world representation for AI:

For the large scale AI, everything is in a tree. Something like this:

  • world
    • region
      • town
        • building
          • person
            • merchant
              • item
                • food
                  • bread
                    • steal
                    • buy
                    • pay 10 money
                    • trade
                • building materials
              • job
                • money
                  • get money
            • cannibalism
              • food
        • building
          • person
            • blacksmith
              • item
              • job
              • employ
            • cannibalism
              • food

Every node has difficulty associated with it, which can be relative to the agent searching the tree (e.g. thieves are open to stealing, cannibals don’t care about eating people, species tend to do things certain ways etc.).

By representing the entire problem like this, it becomes so much simpler. Just fill in all the nodes, plug in A*, build actions from path, and you’re done (obviously, this is still going to be fucking hard).

Agents could think about the future by having surplus as an additional heuristic on nodes, so they’ll buy more food than they need in order to not get hungry all the time.

Anyways, I’m super excited about this, because it breaks down the problem really well. It’ll take work, but I want to make it so that voxel data isn’t required for low LOD AI simulation. The AI would only use the tree for their position/actions. This would be huge in terms of memory and performance savings. However, converting from low LOD to high LOD when the player gets near could be difficult (e.g. if the AI “built” something in low LOD, it may not have been possible to build that thing in high LOD).

The Great Gif Exchange, Week 5

My Gif for Week 5 of the Great Game Dev Gif Exchange:

This is four separate chunks updating in real time in the editor. Their editor position determines the position of noise. This is shown when I move it slightly, showing that the (noise) world stays the same, but visual surface representation changes.

I really wanted to get chunk spawning working so that I would have an infinite/very big world, but I got stuck on Unreal’s SpawnActor function and trying to get code Autocomplete to work.

I didn’t know Gfycat limited my videos to 15 seconds until just after I made this Gif, which is why it cuts off at the end.

The Great Gif Exchange, Week 4

After two consecutive weeks of failure (no .gif), I have broken my streak.

Here’s my Game Dev Gif Exchange .gif for week 4:

In case you missed my last post, a coworker and I have challenged each other to create a .gif each week showing progress we made on our games. This is so we’re both held accountable for weeks that we slack off.

I’ve done poorly thus far, but I’m going to get better.

What the .Gif is Demonstrating

My .gif production values weren’t high because it was getting late.

You’re seeing the default Unreal character falling through two chunks of voxel terrain. They’re generated with a 2D simplex noise heightmap. He falls through because I haven’t figured out how to get collision hooked up.

Theoretically, they’re position sensitive, so where ever I put the object in the editor, the noise will be picked for that position (so if they’re the right distance away, it’ll be seamless).

I say “theoretically” because it was getting late and I didn’t have time to actually line them up and see if the right noise was being picked.

I used Marching cubes for surface extraction, which is why there are 45 degree angles instead of blocks. If I copied over the normals from PolyVox the terrain would look smooth (and if I increased the voxel resolution).

Behind the scenes, I’m linking to Galavant’s third party wrapper to get noise for the chunks. The wrapper is built by Jam and put in a static library, which Unreal then links to.

On Build Systems, Visual Aesthetic, and Other Terrors

First of all, sorry for the stupid title.

A coworker and friend of mine realized that our progress on our personal projects has been abysmal. Said coworker came up with a challenge to exchange one .gif every Friday showing the progress we made on our games. Gifs are more exciting than screenshots (a la reddit /r/gamedev’s Screenshot Saturday), which makes the challenge more exciting.

Anyways, here is my .gif for the very first week :

It’s pretty shitty, but an important submission nonetheless. This is me dropping an Unreal Actor into the editor. This runs my own C++ code which uses PolyVox to generate a 3D voxel mesh. Yes, I’ve decided to go with 3D voxel, which brings us to the first part of this post: Visuals.

Visual Aesthetic

Now, one thing that I’ve been struggling with since Galavant’s inception (as Horizon), is what Galavant will look like visually. 2D, 3D, top down, first person, parallel, isometric, and the list goes on. I think I’ve made up my mind to use 3D top down voxels with Marching Cubes.

Because the view is top down, I don’t have to go to any extents to make LOD or far views possible. Top down should have less demand for high performance as a result of this. I don’t want the rendering to take too much time because I want to focus on simulation.

I am using voxels because building and a large procedural world are essential to my vision for Galavant. Marching Cubes is an algorithm that generates a smooth mesh for voxels. I don’t want my game to look like Minecraft, especially because of the amount of terrible games that have the same aesthetic.

Because of my unique view, I have done some research to find games that employ a similar style. I’m going to dump it here so you can get some idea of what I might be going for.

This video showcases the 3D top-down perspective with voxels:

I also plan on having a similar technique of fading the roof/things blocking the player once they go indoors. Note that I’m not going for the blocky look (at least, not for terrain).

Here’s another 3D top down voxel game:

I think the controls in Galavant will be twin-stick style, like the .gif above.

Here’s a 3D top-down game which almost exclusively uses billboarding (which I like):

An isometric 3D tile-based game:

Another top down 3D voxel game (remember, I’m not going for the blocky look for organic things):

An example of a pretty 3D top-down shooter:

A 3D top down low-poly Crossy Road aesthetic:

Mix between hard-edged building and Marching Cubes terrain:

I’m not going for a photorealistic look like this game, although I am going for smooth terrain plus voxel building.

Another 3D top down voxel game:

All they need to do to make that game look way more enjoyable is make everything five times faster…

This is a really interesting voxel game:

What’s interesting about this is that I believe they are using Marching Cubes, but in order to get the blocky look as well as nice slopes, everything you place is actually four voxels rather than one. I think I will likely do something very similar for Galavant.

They go a little overboard, but I do like their post processing shaders. I don’t think I could manage their hi-fi textures, though.

It’s also interesting how they add a bit of noise at mesh generation level so that the world isn’t a perfect grid. It gives it a Sly Cooper-type look to it that I like.

Here is good looking low poly terrain:

I like the overall aesthetic of this, although it’s a little too indie/artsy for Galavant:

Steven’s Sausage Roll has a 3D top down view with blocky, noisy tiles:

Traverse MMO has a gorgeous low-poly aesthetic:

I do like the vignetting; it’s a little too heavy in these screenshots, but I still want some in Galavant.


If you guys actually read and enjoy my posts, I know you like the dirty technical details.

Unreal Engine

I’ve decided to use Unreal as a frontend (more on that later) because I believe it has the least amount of effort to go from zero to triangles on the screen. I likely will not be using Unreal’s physics, logic, etc.

I learned about how to link external libraries in Unreal’s build system, which was a massive pain in the ass, both because the documentation is lacking, and because I’m on Ubuntu (mostly undocumented). Galavant is going to be an external library, so this is important to know how to do.

Frontend/Backend: The Grand Construction of Galavant

I plan on using a somewhat novel project construction for Galavant. It’s important to me to have Galavant available for as many platforms as possible. In order to accomplish this, Galavant itself is going to be a platform independent library. This library (called the “backend”) references wrapper functions for everything from threading to sound and graphics. The “frontend” must provide all of these wrapper functions with implementations. I plan on using Unreal as the first frontend for Galavant, but I am going to make it as easy and as straightforward as possible to make new frontends.

One very interesting idea is making a LibRetro frontend. LibRetro itself is designed for this strong separation, so making a LibRetro frontend for Galavant immediately makes Galavant work on all LibRetro frontends (like RetroArch). I could directly use LibRetro as the abstraction layer of Galavant, but I don’t want to rely on any external libraries within Galavant (this includes the STL).

Build Systems

Another thing I’ve struggled with is the build system. Previously, makefiles were my go-to on both Horizon and Base2.0. If you read Horizon’s and Base2.0’s makefiles, you’ll see they sucked. A lot. Now, to be fair, I was somewhat using them incorrectly because I couldn’t figure out how to automatically generate dependencies.

Late in Horizon’s life, I decided to switch over to using Code::Blocks project files to build Horizon. However, I cannot stand doing text editing in Code::Blocks (Sublime Text is simply too good), and adding files is painful.

Sublime Text has a mechanism to add Build Systems, which is awesome, powerful, and customizable, but requires a makefile-like thing to actually do the work.

I asked my coworkers what they recommended, and Jam came up. The side-by-side comparison on the introduction page between Jamfiles and Makefiles instantly sold me on Jam. They’re platform agnostic, simple, and straightforward. Within a couple of hours, I got them working on a few of my test projects in Galavant, and I’ve been won over.

The Near (-ish) Future

For the near future of Galavant I will be working on the lowest of the low – getting a solid build system workflow set up, creating the abstraction layer for threading, debugging, performance, and other essential features, and thinking more about how to proceed with the large scale engine design.

I will likely also be experimenting with Unreal on the side. You can check out my channel for past dev live stream shit if I remember to turn it on here and there.

My last broadcast showed me experimenting with voxels in Unreal: live video from makuto9 on

That’s all for now; hopefully, I didn’t bore you to death.