Flow, now with ebbs

Flow has some improvements in speed and looks. One of the updates was moving flow to a separate data layer. This allows the flow to go over short cubes, flow through fortifications and so on. But you saw that last week in my #screenshotsaturday post.

This week I was on vacation in Hawaii, so admittedly I wasn’t working on AOG too much. However, with the long flights and half the trip being stormy-rainy weather, I was able to implement active flows and flow out. Active flows are the flows the player will use to power equipment and they are immune to evaporation. When a flow is active it means there is flow moving through that position to somewhere else on the map. Or somewhere off the map, which is where flow outs come in. When a flow finds the edge of a map, that’s a flow out point. The flow out points take their flow level from their source each cycle. The effect this has is to limit the wide spread of flow once it reaches the edge of a map. Combined with active flows, this forms streams on a flat surface. The series of screen shots below show water spreading out from a source cube. At first a wide spread, then when the edge of the map is reached. The number of active flows decreases because most of the water is flowing off map. The flows that are no longer active eventually dry up and leave only the active flows.

I start by placing a flow source.

The water flows and ebbs spreading out from the source.

It continues to do so, and nears an edge of the map.

When it reaches the edge, the water begins to flow out at those points. Eventually, other water dries up and all that remains is a “stream like” flow from the source to the map edge.

Here I’m showing off some of my debugging tools that shows me the path a flow takes. This one is one of the flow out paths.

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 :)

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.

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 :). 

LD21 - Escape Innerspace!

I’ve finished my game for Ludum Dare 21: Escape Innerspace. It’s loosely based on the classic movie “InnerSpace”.  I could be happier with it, but I’m fairly proud that I finished a complete game on my first attempt.

Overall I enjoyed the experience. I’ll probably compete again in future events.

Some things I learned:

• I write hacky/crummy code when under a time constraint.
• Drawing out a story board before creating an animation sequence helps a lot.
• Sound effects are fairly easy to implement using Slick and lwjgl (that should come in handy for Age of Goblins later on)
• I should have a better overall plan of attack before starting on small projects like this (I had a vague idea for a game, then just started coding, I should have flushed out the idea more, it would have helped picking my underlying data structures)

Working in 2D was fun. I also really liked making maps by hand. The map for Escape InnerSpace used pixels of specific colors to specify spawn points and passable terrain. That made things easy. That being said, I’m excited to get back to working in 3D on Age of Goblins. I’m writing some shaders that hopefully will do some cool things I’ve been wanting. 

Escape Innerspace: Source code: https://bitbucket.org/byte56/ld21

Don’t judge me by that source code :)

Few things

This week has been productive so far. Monday night and tonight (Tuesday night) I’ve implemented:

• Building placement - Detects valid placements for buildings. Buildings can be rotated. Buildings in general still need a lot of work, this is just the placement portion. Since I don’t have 3D models made for the buildings, the space they would take up just gets filled with brick cubes :) Can you tell I’m putting off art related work? 

• Camera orbit / follow - instead of just “strafing” the camera left and right, it can now “orbit”. The camera just finds the cube that’s in the center of the window and uses that as the pivot point for rotating around. Subsequently the code I wrote for this is reused to look at any point in the world. This could be used for a tutorial or jumping the camera to points of interest, like stinking dwarf attacks.

• 3D cube selection - Sketch-up style! Select a region of cubes, then you can click and drag that region up, down, left, right, whatever. Pull the selection out into the sky to make a selection for adding cubes, creating a wall or tower. Or pull it into the ground to create selection for removing cubes, creating a tunnel or shaft. This is actually pretty fun to use. I was using it to select some cubes on top of one hill, and dragging that out to create a bridge to another hill top. This feature still needs some work, but it’s off to a great start. (That green blob is the unit, you may recognize it from my first video, usually they’re blue. When doing a task the units change to the color of the task, it’s for debugging, so I know they’re doing their work).

• And a few other little things that were on my “ever growing, never shrinking” to-do list.
• Lastly, I updated the blog :p

Feels good to be productive. 

Unit Goals

I’ve re-worked how units get things done. I gave them goals.

Up until this weekend units had a few things controlling them. They had the Unit worker, which did things like make sure they had jobs and checked their physics to make sure they weren’t flying. There was also the Job worker, which would move the units around, make them add/remove cubes and modify their inventory. 

Now the new system is much simpler, easier to understand and easier to debug. Basically, the Unit worker does everything. The Job worker still exists, but it’s only there to hand out jobs and make sure that jobs and their tasks are still valid.

The units now have a main goal and a secondary goal. (I’ll talk about goals and tasks from here on out, just remember that as far as the unit is concerned, they’re the same thing) When they need work, they ask the job worker for a job. Then they ask the job for a task. For example, a player selects 20 cubes they want removed. That’s a remove job. Then each one of the cubes that needs to be removed is a remove task. Each job is made up of tasks. So when a unit is assigned to a remove job, it asks the job what it’s main goal should be. The job finds the remove task closest to the unit, then that task becomes the unit’s main goal.

So what’s with the secondary goals? Those are the things that need to get done before the main goal can be completed. Continuing with the remove job example, the secondary goal would be “Move within range of the cube to be removed”. Once the secondary goals are met, the unit can start work on the main goal.

Once the main goal is complete, the unit can just ask the job for the next task.

Well I said it was simpler, so you should have seen the other system! Here it is in graph form:

Does Age of Goblins need any testers?

I'd be more than glad to help!

Age of Goblins isn’t ready for outside testing just yet. Likely testing will start with friends and family, then move to a select group of pre-alpha testers.

Once the game is playable (ready for alpha), I’ll move on to a “buying the game gets you into the alpha, beta and all future versions of the game” model, similar to the Minecraft model. With the alpha being sold at a very reduced price, the beta less so and finally the “release” version at full price.

Keep following the development blog, I’ll release details on how pre-alpha testers will be selected when I’m closer to that stage. Thanks for the interest and thanks for the question.

My early thoughts on Gadgets

All gadgets are controlled via the magic of “wireless” or as the head goblin gadgeteer calls it “Quantum steam entanglement”.

Gadgets are controlled by a Gadget Controller Cube, one cube can handle up to 128 gadget pairs (256 gadgets for those keeping track). Gadget links are paired with punch cards, in the form of: Activator->Reactor. Where, Activator and Reactor are both gadgets placed anywhere in the world. For example, the goblins have built a door, a pressure plate, and a lamp. If I want the door to open and the lamp to light when something steps on the pressure plate. I can create one of the following punch cards:

Pressure Plate -> Door
Pressure Plate -> Lamp

I can get the same results if I define it like this:

Pressure Plate -> Door
Door -> Lamp

This also means that the lamp will light any time the door opens, not just when the pressure plate is stepped on.

Of course I can define it like this as well:

Pressure Plate -> Lamp
Lamp -> Door

So that the door opens whenever the light is on, maybe not as useful, but you get the idea. Every gadget has an input and an output. When the gadget is “Active” its output is active. All gadgets can have multiple gadgets on its output, but many will be limited to a single input. However, for you advanced gadgeteers, there are OR (2 inputs), AND(2 inputs) and NOT(1 input) logic cards that will help you create everything you want. Logic cards are just like punch cards, and fit inside the gadget control cube, so you don’t have to clutter everything up.

Finally, I’ve updated the wiki with a very small list of gadgets.

Units and Font

So far this weekend I’ve worked a lot on bugs in the unit jobs. So far the jobs are: Add, Mine, Channel. I know, Mining and Channeling may seem similar, but there’s a key difference. Mining leaves a layer for your units to walk on, Channeling removes the entire cube, opening the space below. This is the aspect of Dwarf Fortress that I thought would be tricky to bring into a 3D world, but this seems to work.

This is what Mining the cube on the left looks like:

And this is Channeling the same cube:

Then of course adding cubes works just like you may think. Cubes are added… You can select what type of cube to add, or just tell the Goblins to use whatever they have on hand.

Finally, I spent this morning creating a number font. I’d looked all over for a Nixie tube font, but couldn’t find one. So I created my own! Yeah, it has the same programmer art style as all my other stuff, but it’ll do for now. Here’s a little count down:

Sorry for the flashy post :)

Did some drawing the other day. Improved my radial menu a bit. It’s not done yet, but it is fully animated, the gear rotates and everything. I forgot to show it off in the latest video, I’ll show it off next time. This coming weekend I’m focusing on units. I want to start playing this game!

What Language is age of goblins written in and what libraries does it use?

Age of Goblins is written in Java, using OpenGL. For all the OpenGL functionality I’m using the Lightweight Java Game Library (LWJGL). I’m also using a modified version of the Themable Widget Library (TWL) andSlick for the UI.

Not using TWL anymore. I've created my own GUI library, ByteGUI (clever name right?). I'll release it separately at some point as a free library for other game developers.

The engine is written by me. In retrospect it would have saved a lot of time to have something pre-made, but I wrote one that’s pretty flexible, generic and easy to expand. Plus I know all the details of how it works :). Thanks for the question!

Wiki

I’ve been working on Age of Goblins meta data, I created a wiki. Sort of like documenting my code, but in a more useful manner. Additionally it gives me a big picture view, and helps organize my thoughts. I don’t know if wikis are usually created before the game is complete, but it seems like it’ll save a lot of time later. I’ll continue to update that as development progresses. The wiki can be found at: wiki.ageofgoblins.com

Maybe someday I’ll have some devoted fans that can help me fill it out, ‘till then only I get to edit!

Now, to get flow working well enough to make a video!

Behind the scenes

This week I’ve been working on some behind the scenes code changes. The user can now cycle through maps freely. There’s a button in the UI that will generate a new map. This means you can generate a map, look around to see if you like it, keep it or generate a new one right then.

Yes, that means that the maps are finite. Not the infinite world of Minecraft. I thought about making it an infinite world, even went so far as to prototype it. The problem is, that unlike Minecraft, it matters what’s happening “off screen”. I can’t just write all the chunks the camera isn’t near to disk. Do the goblins just stop working when you’re off looking at some other part of the infinite world? Of course not.

This weekend I’ll be working on smoothing unit movements with cubic splines. That means setting up some generic animation type stuff. I’m creating a class that can take the path I find with A* and use those as key frames to generate smooth movement along a cubic spline. Also I plan on getting some proper unit physics to allow for unexpected events in a path. I imagine I’ll use AABBs (axis-aligned bounding box), which should be pretty fast.

Also, stairs and ramps are in game now. The code that generates the faces for the stairs takes the number of steps as a parameter, so I can easily change the size of the steps if it works better for the goblins. I need to clean up textures on the stairs and ramps to make them not look so squished/stretched. Perhaps I’ll tackle that this weekend too.

A light post

A light post

Lighting is at a pretty good place right now. It hasn't gone through a bunch of optimization, but it’s pretty fast. It works sort of like flow. Say we have a situation like this with a light inside a little tunnel:

The flow starts at the position of the light (of course).

The light flows through cubes that are light transparent and touches the faces of cubes that are not, and sets their color along the way.

The “flow” distance is limited by the falloff of the light. For each face the “flow” touches, I calculate the distance and the intensity, the dot product of the light vector and the normal of the face. This means that if light isn't “pointed toward” the face, it doesn't get lit. This alone works OK, but doesn't take into account solid objects, like walls.

If shadows are enabled, then before we set a face light, we check to make sure it has line-of-sight with the source. This is a bit more processing intensive. However, what’s cool is we only have to do it once! We only have to compute it again if a cube in range of the light is added or removed. Otherwise the light is “baked” into the texture of the cube. Plus I already had solid picking code, and can use it here too.

This is actually really fast, considering. The lighting is done without noticeable delay. Check out the screenshots of it in game on the gallery page. The shadows produced are a bit chunky, since it’s a per face lighting, not even per vertex or per pixel. But it’s fast and it works for me!

Perhaps later I’ll do something nifty like Minecraft and have smooth lighting.

Also, who doesn’t love SketchUp?

That's the name of the game

The votes are in! The name of the game is Age of Goblins. I purchased ageofgoblins.com. It will be the future domain of the game page, but for now it just points to this blog.

Additionally, I’ve posted the first video of the game. The video shows off the slice feature and unit jobs in action. You can find the video on my YouTube channel.

Unit jobs

I’ve implemented unit jobs and tasks. Jobs are made up of multiple tasks. Basically a job is something like “channel all these cubes”. That job would contain tasks like “move to this position” or “channel this cube”. It works fairly well and allows a lot of flexibility in the job scheduler and units performing the jobs. I don’t have the unit models in the game yet, so they are just represented by little diamond outlines. However, it sure is fun to watch them move around and work!

I’m working on getting a video capture program I like and getting some videos up. Much better than these boring screen shots. Should have some within the next week or so.

Yet again, more water

My water flow algorithm was getting pretty bulky. So, like any good programmer I rewrote it from scratch. I really like the new algorithm. A nice recursive algorithm that’s really fast. Standing on the shoulders of giants, I used some of the aspects of water flow as described in this article on Dwarf Fortress. I always liked the water in Dwarf Fortress compared to that in Minecraft.

For example in Minecraft it’s easy to get a situation like this:

Which in some cases is fun, for making under water buildings and the like. However, I wanted something more “realistic” like Dwarf Fortress offers, like this: 

I like it! I’ll try to get some videos up of it in action.

The images and interview can be found here: http://www.gamasutra.com/view/feature/3549/interview_the_making_of_dwarf_.php?page=1

Additionally today is my 2 year wedding anniversary with my beautiful wife. Thanks to her for putting up with me spending all my free time on this game!

Minecraft question

I just saw some screenshots on your blog and they look a bit like Minecraft... Coincidence? :P

Huh. I was going more for a “3D Dwarf Fortress with textures instead of ASCII characters”. Or maybe like a “3rd person empire building game based on Infiniminer”. ;)

Yes, I agree, my game and Minecraft both employ the use of textured cubes, they can be added and removed. However, beyond that, they’re pretty different. I’m making a 3rd person empire building game. My game gives the player the task of taking their small group of goblins and building a large, powerful goblin empire. Both games are inspired by similar sources, but they are taking different paths.

It’s understandable that my game could be mistaken for a Minecraft look-a-like from these early screenshots alone. Just follow the progress of the game and I’m sure you’ll see it develop into something new and different. Thanks for the question.

More water work, NetBeans and threads

Spent most of the day Sunday on water flow and un-flow. Un-flow is working OK, but it’s not exactly where I want it yet. That’s fine with me it’s fun to work on. Sometimes I get these little oscillating patterns of flow that remind me of Conway’s Game of Life.

Water flows farther on surfaces that aren’t porous. This means you can create channels of stone that will carry water around (if you don’t have the resources to build pipes yet). This will be critical for all the goblin steam craft, water wheels and decorative fountains. 

NetBeans keeps saying that x class isn’t found. So, I have to touch the class file, clean build, then try again. What usually follows is class y not being found, so I have to repeat. I ended up writing a script that goes through and touches all the files. Then I can clean build once, without issue. Also, NetBeans has been giving me silly errors like:

Exception in thread “main” java.lang.RuntimeException: Uncompilable source code - missing method body, or declare abstract

This is immediately after tweaking one little bit of code, then rebuilding. Obviously not removing the method body. /sigh. I’ve upgraded to the latest version 7.0, and I haven’t had any more issues with the classes not being found. However, there are some issues with the NetBeans UI and undo was acting weird. All that is better than missing classes though, so it’ll do.

I’ve been having threads die, without warning, without throwing an exception and not reaching any of their exit points. It’s a mystery, an annoying, frustrating mystery. For now, I’ve just added a thread watcher to see when threads go missing. The watcher then starts a new thread in it’s place. After more work on the water flow, the threads seem to have stopped disappearing. So I guess they were just crashing hard enough to not report. Hard to say.

Water!

Added water and flow. However, I haven’t added “un-flow”, so once water is there, it’s there to stay. I was also playing with the land generation algorithms to get some more interesting stuff in there. I’m using a combination of 2d perlin noise and 3d perlin noise. As you can see from the screens page, there was some interesting stuff! I think I've got it a little toned down to the kind of landscape I was looking for.

Working on the UI

I’m really liking the TWL interface! Byte56Game0 is getting a goblin steamwerks style interface. Unfortunately, it only has my “programmer art” right now. Artwork is something I’ll have to really spend a lot of time on or outsource at some point. Also I’ve posted some images of the game on the Screens page.

Keep in mind, this is pre-alpha stuff! Textures are likely to change, like I said, programmer art:

Hello world!

My first post, I’ll try to explain what I’m up to. I’m making a game! It’s a 3D, 3rd person, voxel based, goblin city/mine/fortress builder. The goblins have gained a little smarts and are finally settling down and building themselves an empire! Inspired by Dwarf Fortress, Infiniminerand MineCraft.

This is my first game, and it’s fairly early in development. I work on it when I’m not at my day job. I’d like to use this blog to provide progress reports on it’s development, and get feedback about the direction of the game. It’s written in Java/OpenGL (using LWJGL), so should support Windows/Linux/Mac. I’ll post screen shots of the game soon.