About

I'm a software engineer who works on game development part time. I teach game development (on gamedev.stackexchange.com and lynda.com). I'm always working on something, and I'll post updates here. Let me know if there's a game development topic you want to know more about, I probably know the answer, or at least where to get one.

Friday, October 28, 2011

I love the flooding video. Super nice work. The sad thing is that you will be hired by Blizzard before you'll finished this game ;-)
Thanks, I’m glad you like it. Luckily, I’m working towards a goal of financial independence, so the risk of being hired away is low. Plus I think Blizzard would frown on my “research” days, where I just play games the whole time :)

Saturday, October 1, 2011

The latest on flow


Once again, I’ve rewritten flow. I think I’m actually honing in on some kind of optimal solution for my needs. So far in my iterations I’ve come up with two basic methods for moving flow around, push or pull. But first some definitions.

Flow: So far, this is just Water or Lava. 
Cycle: A step through the flow loop. Ideally touches all flowing cubes to update them.
Source cubes: Infinite sources of flow (springs, rivers, etc.). While they will never run out of flow, they have a limited supply of flow per cycle.
Flow cubes: Cubes that have flow in them.

And now the two flow moving methods.
Push:
In this method, I keep track of source cubes. Each cycle these cubes had a certain amount of flow they want to get rid of. So I loop through each source cube, and find somewhere logical to put their flow. This is done by stepping out from source cubes until we find somewhere the flow fits, and then filling in that space. I’d skip past cubes that had full flow, to save the trouble of propagating flow through cubes that are already full, and would be full after. Additionally there’s some smoothing involved that lets us look for places where there’s too much flow, and spread it evenly among it’s neighbors.
Pull:
In this method, I keep track of all the cubes that are not full yet, including empty cubes that are directly adjacent to cubes with water in them. I also keep track of what Y level the cubes are on, lower level cubes get priority. Each cycle I start at the lowest level, and work my way up. This kind of simulates gravity, it makes sure that things will flow down hill before spreading on top of the hill. At each level I select cubes randomly until I’ve gone through all the cubes on that level. When a cube is selected, it follows it’s parent flows back trying to find a source cube. If it finds a source it pulls flow from it. If the source cube is empty for that cycle, it will check it’s parent flow. If the parent flow has two or more flow than the current flow cube, the current flow cube takes 1 unit of flow away. This has kind of a leveling effect.
With both methods I keep track of parent flows. This is required to see if a flow still has a source. This is where I think the pull method works so much better. When there is no source the pull method, it can just seek the highest parent, and take flow from them. See the image below to see what the parent child connections can end up looking like. Here black is the parent and white is the child. Parents can have multiple children, but children can’t have multiple parents. Also, as you can see, flows are non-diagonal only. This simplifies things greatly, but does make for some unintuitive flow paths.

My latest rewrite implemented the pull method. It’s mostly working. There are still a few issues I’m working on, but I’m getting closer. Check out how it looks in the video below. Feel free to ask questions about specifics if you’re trying to implement something similar.


Saturday, August 27, 2011

Progress Update


I’ve been spending my time on two areas lately: the engine and unit tasks. 
The engine:
Vertex/fragment shaders mostly. These have helped a lot. Primarily with the slice feature. Age of Goblins does chunking with its terrain. Before the shader, these chunks were 64x1x64. Each chunk was 1 cube tall. That made it really easy to “slice” through them. I’d just not draw chunks above the “slice level”. Additionally I have some code that creates what I call “void caps”. This is a special layer that hides all the cubes the player hasn’t discovered yet, as well as the void that’s left when you start cutting through geometry. Of course this came at a performance cost. I needed considerably more chunks to fill the same volume when they’re only 1 cube tall.
Now the shader comes along. With a little bit of GLSL code in the fragment shader:
if(WorldPos.y > maxY)
    discard;
I can get rid of all the geometry above a specific height. Now I can use whatever chunk height I want! This sped things up quite a bit. Luckily I’ve kept all my code nice enough that I only had to change the y chunk size constant and everything still works. 
Elsewhere in shader land I’ve been tinkering with some lighting effects that should give the landscape a bit more depth. A sort of “lighting rig”. Still needs some more tweaking and testing with different conditions. Finally, I’m in the middle of working out how I’m going to do some vertex displacement to recreate the smoother cubes on the graphics card (as seen here).

Unit tasks:
Building off my previous work of giving units a main goal and sub goals. I’ve implemented a goal stack. This allows me to give units higher level goals, and not have to walk them through each little task along the way. The goal stack works something like this:
while(!CurrentGoal.NeedsToStartAreMet())
    TaskStack.Push(CurrentGoal)
    CurrentGoal = CurrentGoal.GetSecondaryGoal()
In the end, you’re left with a list of tasks, in order, that need to get done before the main goal can be started. To put this into an in game example, the situation could be that I’ve just ordered a goblin to place a rock cube at position xyz. The goblin doesn’t have a cube like that in their backpack, but there is one in a storage bin near by. So before the goblin even moves their goal stack would look like this:
  1. Go to storage bin     <— top of stack
  2. Pickup rock cube
  3. Go to position xyz
  4. Place rock cube
Clearly there’s some more work in creating that list, like finding the nearest available rock cube. But that’s all taken care of by the goblin as well (with a little help from the world item finder).
Pretty neat! To help test this out I implemented in-world objects. So when goblins are clearing away cubes, once their backpacks are full, they’ll just leave the cube (in item form) on the ground. This is similar to Dwarf Fortress (sans the backpacks) and Minecraft (much larger backpacks). Of course (as usual) the in game representation of this is just a little colored dash, since I haven’t gotten around to implementing the pretty graphics for it :).