Terrain Features : Pools of Water

For most of August I was working on modifications to the terrain generator. Previously I had to generate the entire world at once, and it had to be square and a power of 2 in size. There also wasn't much leeway for modifying the output data. With the new changes I've made it can generate what I call a "world region", which is a n x m sized region of the world and it has the ability to run feature placement over the output before it gets turned into the final heightmap/tilemap. This also brings it closer to the eventual goal of being able to specify biomes and make use of temperature/moisture maps based on the surrounding sea and mountains.

Feature Placement

The first feature placement algorithm I've been working on is for pools of water. Since fresh water is second only to oxygen in urgency of need for survival, I need to give the player access to water in some fashion otherwise the game will be rather short.

When it comes to terrain generation there's two different approaches you can use. Teleological or ontogenetic. Those sound complicated, but it comes down to asking the question, is the terrain generated as the result of simulating real world processes or is it faked to look like it was?

An example of simulating using real world processes would be to generate a height map using a plate tectonics simulation, then apply many passes of thermal and water erosion algorithms over the result. Next, add water to the world and if sufficient water flows into a local minimum, you have a pool of water.  That's not even the whole story, to be realistic you should also model the permeability of the surrounding rock, the level of the water table, the rainfall for the surrounding area, and so on...

As you can imagine this is pretty complex, as the forces that shape terrain in the real world come about as a result of processes involving physics, chemistry, biology  and geology. The other thing to note is that the terrain all around us was generated over approximately 4.5 billion years, so creating realistic looking terrain through simulation typically takes a lot of iterations even if you take shortcuts.

Faking it

The alternative is to fake the terrain. The general approach is that you use algorithms that have nothing to do with simulating how real terrain is formed. For example, generating some perlin noise, applying a mask to shape the noise to give it the right shape and then smoothing the result using a gaussian blur etc.

I decided to take this approach, since I'm trying to write a game, not a geological simulation of the Earth.  Following the "fake it" approach, my pool placement algorithm looks something like this:

1. Pick a random spot in the world.
2. Determine if the area is suitable for a pool of water, ie not too steep. If not, jump back to 1.
3. Generate a pool shaped terrain depth mask.
4. Blend the depth mask with the existing heightmap to introduce a depression to the terrain.
5. Calculate a suitable water level for the pool.
6. Loop over the lowered terrain adding water where the depth is below the calculated water level.

There are complications will this approach which I won't delve into here at this time as I'm still refining the algorithm. I ran into quite a few problems that I didn't anticipate, such as how to blend the depth mask with the surrounding terrain so that it looks like it's supposed to be there, not just splatted over the top. My initial approach was to smooth the terrain then apply the mask as is, but it tended to produce a flat area that looked out of place.  In the end I came up with a blending approach that uses the distance from the pool as a blending coefficient such that terrain 5 tiles away from the pool uses the local height map and anything closer uses a blend of the two.

Selecting a suitable candidate site was also very important, as some terrain is completely unsuited to forming a pool, for example, if the site has too much of a slope.  Pools placed here tended to look absolutely terrible and often leaked their water out into the rest of the world as the pool edges were too thin.

The part which gave me the most trouble was designating which tiles should be water. The pool placement affects the height map directly, but the game tiles take their height from the surrounding 4 height map values, so I needed a way to determine which tiles are affected by the height map changes and should now be water. I tried a few different "smart" approaches that took advantage of knowledge of the original water mask but found the best solution was actually "dumb", using a flood fill to find the lowest point and then use a recursive fill to process neighbouring height map values. (Thanks to my colleague Ben for suggesting that one). It works like a charm, and has the added benefit of being able to called on the original height map to generate seas or oceans.

Figure 1: The player character enjoys a little swim.

As you can see in the above image, the water renderer is pretty much as basic as you can get. In the future I'd like to add reflections, ripples, specular highlights, waves and a bunch of other effects that help to sell the idea that its actually water, not a flat alpha blended plane. For now though, it will have to do.

July Progress Report

What's the latest happenings in the world of Bulldog? Well, lately I've been thinking alot about the big picture, such as all the cool features and mechanics I want to have in the end-game. Unfortunately these are likely to years away realistically, but I can't help dreaming.

In a more down to earth sense, I think it's way past time that I start posting screenshots and perhaps even short videos showing how things look. I've been loathe to show anything as I didn't consider it good enough to show, but I've resolved to at least try to put up some screenshots, so here goes:

The player character (placeholder model) standing amongst sand.

Zoomed out view of my test sandbox.

In the past few months I've been continuing work on fleshing out the mechanics of the game. Recently I overhauled my lighting system to handle the dynamic range from full noon sun to middle of the night, but still have appropriate detail visible in either. I also added in the ability to have local sources of light, such as that emitted from torches or explosions. Visibility at night is going to be an important mechanic, so the lighting model is really key to having that be believable.

This month I've been working on the ability to build structures in the game, such as campfires, which has taken alot longer than I expected given how I already had a job queuing system in place. A good deal of the work has been in making the system robust so the player doesn't randomly lose items if he cancels halfway through, or preventing the player from duplicating items through an exploit. I'm also working on a new font that looks a lot better than the previous one I showcased in my article on signed distance fields. I'm excited to see how it turns out in game.

Progress Report

In my last post I mentioned that February was going to be "Graphics Month". That turned out to be a bit of failure overall. ZBrush really wasn't the right tool for the job, but to cut a long story short, I once again looked at Blender and persevered with it long enough to get somewhere. I also found a few tutorials that really helped get me up to speed. I also found that making a cheat-sheet with all the common keyboard shortcuts was very handy, especially when coming back to it after a few days/weeks.

Most of the time I spent with Blender involved getting my head around UV-unwrapping, which isn't a trivial task, but absolutely necessary to have anything able to be textured. So far I've created only 2 small models, a rock (for terrain dressing purposes) and a campfire, but its a start.

In the past few months I've been tidying up the project quite a bit, disabling functionality that is only half finished, in an attempt to create a solid build so I can start passing it on to friends for feedback. My development schedule thus far has been fast and loose, whereby I'm not really developing towards a set of known goals, I just work on whatever interests me at the time. Unfortunately this has led to a the majority of features being only half finished, which is going to have to stop. So from here on I've started making feature lists for the next few monthly sprints, which has really helped focus my efforts in recent weeks. I've tentatively planned the next few months of development work, which I'd never really managed to do in advance.

One of the advantages of starting to show it around is obviously feedback, but also its forced me to care about the completeness of features. It's fine to leave something unfinished for development purposes, like say not handling some unusual edge case (with the idea of coming back to it and finishing it later), but once you start giving it out to people there's an expectation that everything works. 

Pre-Alpha 1 was a reasonable success, though I had some teething issues getting the deployment correct due to not really understanding SlimDX's installation requirements properly. So far the feedback has largely been related to the camera system which is one of the first things I coded, and suffered from a situation where the controls made perfect sense to me, but didn't necessarily reflect what others might try to do. Fortunately one of my alpha testers works in user interface / graphic design, so he'll hopefully point out all my mistakes before they become too deeply ingrained. :)

The next step

I wrote about missing my target date in my last post, but what recent development have I done in Bulldog?

Last week I developed a sound playing engine for the game, to finally give the world of Bulldog some sound. Currently the only sound it plays is when you click on Button Controls in the user interface, but it's a start.  In the future there will be ambience, such as wind or rain, or waves crashing on the shore, as well as creature sounds such as bird calls and eventually, music and perhaps even some voices.

In the past 3 months I've been spending alot of time trying to get the core mechanics of the game working. These are boring things like moving to a particular grid square, picking up an item, dropping an item etc. There's quite a bit of complexity in the interactions between the world and the user interface that caused a few nasty edge cases. I hadn't considered these when I originally coded the command/dispatch engine, which is responsible for executing creature's commands in the game.

For example, since there's a half second delay between issuing a drop command and the item leaving your inventory, in the initial, naive version, it was possible to queue up two drop commands on the same item, and cause the item to be duplicated, which is obviously a bad thing. Thinking in the manner of someone trying to exploit the system exposed a few other situations where this type of thing can occur, so I had to revise the way commands are executed in order to prevent problems like that, but I'm pretty sure I've got all my bases covered now.

Plans for the future?

February will officially be "graphics month", where I dedicate my development time to purely working on the graphics of the game. The key focus of this month will be drawing additional in-game art, such as icons for the items in game, but more importantly, 3D models for all the creatures and items. I've been putting off creating 3D models since I started the project, because it's not really my forte. I dabbled with 3d modelling way back when 3DS Max 1 was the latest thing, and haven't done anything since, so I pretty much have to learn 3D modelling from scratch using new software, so it's not something Ive been looking forward to.

I'm doing everything for this project legit, so I can't simply pirate the latest 3DS Max and just go for it. That said, 3DS max is far too expensive for me to afford for this project. While I've managed to use some of the tools and resources my company already owns, (such as Adobe Illustrator and Photoshop), 3D modelling is something my business has no need for, so justifying the $3,500 outlay to my business partners (and myself) is impossible. Similarly, from a personal perspective I can't afford it either.

I've looked at free alternatives, but haven't found one that doesn't have an enormous learning curve and weird esoteric commands. It annoys me that Autodesk don't sell a cut down (and cheaper) version of 3Ds Max that just has features like 3d modelling and UV unwrapping, and no fancy stuff like caustics, cloth simulations or fluid dynamics. Hell, the app doesn't even need a proper renderer. They did provide a version that was designed for games people specifically, called Gmax, but that was discontinued in 2005 and only saves the models into a proprietary format that is useless to me.

All that said, I recently looked at ZBrush, which is held in high esteem by a lot of people, and was shocked to discover it costs only $700, which is well within my price range. So I've got the 30-day trial sitting on my laptop and plan to evaluate it shortly.

Beyond February?

In the short term I want to get something demo-able to friends and family, and the graphics is the only thing holding me back at the moment. If all goes well, I hope to iterate a few times on the demo, adding more complete features and making changes based on feedback, and then start working on Phase 2 and the eventual proper release, which I'm VERY excited about. My plan is for everything up until the proper release to be available for free, and then charge something like $15 for the commercial release, which will entitle you to all additional content and features added from then on for free (and there will be a lot of them).

While it seems pretty popular with indy developers at the moment to fund development with preorders, I don't think I could justify this. In terms of what the customer would actually get, and the fact that I have a full time job so don't need the preorder money to survive, so at this stage that's not part of my plans.