Sunday, May 20, 2012

Progress Report

It's been a while, so I suppose I owe another post on my progress.

I've spent a while shuffling languages and ideas, trying to zero in on the best way to build an engine that can support the game I want to make.

I was originally working in Unity, but eventually decided that while Unity is a very powerful engine for rapid game development, its real strength lies in its 3D editor, which I wasn't using. My game is based almost entirely on procedural generation, well outside of what Unity is designed to handle. So I spent far more time than I liked with trying to figure out how to work around limitations in the engine, and in some places simply had to compromise on what I could do. I eventually decided this wasn't acceptable.

While working with Unity, though, I had fallen in love with C#. So I determined I'd make the engine in C#, but targeted at Mono, with the intent of keeping it multi-platform. Toward that end, I grabbed a library called OpenTK, which provides bindings for OpenGL, OpenAL and OpenCL, a set of multi-platform open standards for graphics, audio and general-purpose GPU processing, respectively. I made some pretty substantial progress using those, but when trying to utilize the more advanced graphics functionality I encountered some flaws with the bindings that I couldn't work around.

And thus I've arrived back at my old standby: C++, with SDL and OpenGL.

Unfortunately, all of this environment switching has a high cost. I'm not quite starting from scratch each time, but it almost feels like I am. It's a major setback, and a huge amount of work has to be redone. However, I'm confident I won't be switching again. C++ is a bit more complicated to work in, but it applies no artificial limits. Anything I want to do, and can't, will be because the hardware can't handle it, not because the environment is constrained.

Now this isn't the only reshuffling I've done. The first part of the game I'm attempting to implement is the terrain engine. The reason for this is that it's the riskiest component, and it's very central, in that how I implement it will heavily influence how I implement everything else, and even influence a lot of details of the game design. I've been unsure exactly how best to go about it, or whether I could even find a way to meet all of my fairly steep requirements. Those requirements are:
  1. It needs to be fully dynamic, so it can be reshaped on the fly.
  2. It needs to support overhangs and caves (a simple heightmap won't do).
  3. It needs a viewing distance of at least a few km, and a geometry resolution of no larger than a meter, on commonly available PC hardware.
Originally, I was trying to do this with voxel cube terrain, because that definitely fulfills the first two requirements, and the third is just optimization. Unfortunately, I couldn't find a way to optimize it sufficiently. It's easy to blame the slowness and low viewing distance (144m) of Minecraft on the fact that it's in Java, or accuse Notch of being a bad programmer, but the reality is that drawing that many cubes is really hard on the GPU. Also, given that there is no clean way to apply level of detail, and your view gets wider as the viewing distance increases, when you double the viewing distance, you roughly quadruple the amount of geometry you have to draw.

So in order to achieve point 3, I went back to the drawing board. I spent a couple weeks brainstorming, and reading. I came across this amazing blog called ProcWorld, by a very talented programmer, Miguel Cepero, who is working on his own procedural world generator. Many of his techniques aren't useful to me, because his worlds are pre-generated over hundreds of hours on a render farm, whereas mine need to be made on the fly. However, it exposed me to an algorithm by the name of marching cubes, which I'm honestly a bit embarrassed I hadn't heard of before.

Marching cubes is a very fast, clean and elegant way of taking a mathematically defined surface and turning it into a set of polygons, at an arbitrary resolution. This surface has to be described in terms of a 3D density map, and a threshold value, such that points that are denser than the threshold are inside the surface, and points less dense than the threshold are outside the surface.

The first chapter of GPU Gems 3 describes not just how to implement marching cubes, but how to implement it very efficiently in the GPU, using a multi-pass shader. I realized it would be relatively easy to extend their implementation to allow for smooth, seamless level of detail with geomorphing.

Unfortunately, this is where OpenTK failed me, and I realized I needed to switch away from C#. I got the basic, naive GPU implemention of marching cubes working, but of course it was way too slow. So I began work on the multi-pass version described in GPU Gems 3, and discovered that OpenTK had a bug I couldn't work around (or figured out how to fix) with its support for transform feedback, the OpenGL feature that allows for the multi-pass technique.

So now I'm back in C++, building up all the basic infrastructure of a new engine. I decided that, since I'm starting a new engine anyway, I'd build it with a component-based architecture. Which has slowed me down a little, because it's unfamiliar territory, but I believe it will pay dividends down the road. Anyway, I now have that mostly in place, and fairly soon I should be able to dive back into the terrain engine itself.

No promises on when I'll have visible results to show. I still have a day job, after all.

Friday, April 27, 2012

Old Content Restored

It turns out I was able to extract my old posts from my browser cache, so I've restored them below, with the appropriate dates attached and everything. I even updated the download links to point at their new Google Drive locations.


Thursday, April 26, 2012

Never using Linode again

So was previously hosted on Linode. It wasn't terribly difficult to setup. I got WordPress working on it, and it chugged along just fine for about six months.

Then two days ago, I got a series of six messages from their customer support, as follows:

  1. They were going to reboot my server because they had detected some issues with it.
  2. The machine was experiencing a hardware failure, and they were going to transfer the drives to a known good machine.
  3. This was taking longer than expected, and they had no ETA.
  4. Their attempt to recover my data was unsuccessful, but they were going to setup a new, equivalent Linode on a new machine for me, and give me a three month credit on my account, as way of apology.
  5. Instructions for how to restore my data if I had paid for the extra backup service (which I hadn't even realized existed as a separate, special service).
  6. The new Linode was setup.
The entire thread happened over the course of a few hours early Wednesday morning. By the time I got up, it had already played out, and I read over the entire thread multiple times, in shocked disbelief.

Needless to say, I decided I was done doing business with Linode. They're friendly and helpful, their rates aren't unreasonable, and there's a lot of good things I can say about them. However, their competitors can offer me real assurances, which I have reason to trust, that this sort of event will never occur, short of an apocalyptic disaster.

I briefly considered AWS, as they seem to be the most reliable hosting service available. However, I realized that what I was hosting was essentially just a blog, with an attached gallery and a few downloads. Blogger can give me all that, and it's a hell of a lot less effort. That means I can spend more time working on the project that this site is meant to showcase, and less on building and maintaining the site itself.

Tuesday, August 23, 2011

New Home

I’ve just finished transferring this site to a new host, owned and operated solely by me (and Linode, that I’m renting the server from). Previously, I was using space generously donated by Ashelia over at, but unfortunately I couldn’t configure things to work quite how I wanted without sabotaging the other sites I was sharing the space with. So, time to strike out on my own!

In the process, I also put in the time to improve the appearance of the site, including actually putting a logo at the top. I’m quite fond of the little iron spirit. I think he needs a name, though I haven’t decided on one yet. Suggestions are welcome.

I also finally have e-mail attached to this domain. So I can be contacted at contact, admin, webmaster, mike, michael and mpowell,, and I like to be thorough. But for now, I’m mostly advertising

Friday, August 19, 2011

Lack of Updates

Given the small burst of traffic I’m receiving after tweeting this URL at Notch, and the fact that I haven’t posted anything since March, I figured I should provide a progress update.

First of all: It’s still alive, though progress slowed for a bit, and it’s direction has now shifted slightly.

The big thing that happened is I got a new job. This job didn’t take up more time. Quite the opposite. It cut 2 hours of commuting out of my schedule. However, it also introduced me to the wonders of Test Driven Development, and all sorts of other good practices, which I hadn’t previously been exposed to. I spent close to two months exploring that and other related subjects, not wanting to dive too deep into my code for fear that my approaches would all be invalidated by what I learned next.

I finally reached a point where I felt ready to dive back in. However, in the interim, I’d gotten really excited about some of the simpler things I could do on the other end of the game, the actual down-in-the-world portion. So, I decided to take a two-pronged approach to developing the final product.

On one end, I build a detailed world generator, which is the project I’ve been working on that you see up here.

On the other end, I build a bunch of the gameplay in a small world using a relatively simple terrain generation algorithm.

So for now, I’m focusing on the gameplay side. And the game is currently tentatively titled Fire & Stone, though I reserve the right to change my mind on that. I’ll post a demo of that up here as soon as I have something sufficiently usable.

Edit: Also added a long-overdue screenshots page, after three separate friends and family independently suggested it in the space of about 5 minutes.

Thursday, March 31, 2011

Genesis Engine Demo v0.1.1a Released!

I’ve released version 0.1.1a and put it up. You can download them right here: Mac | Windows

The biggest change is perhaps the least visible. The maps are now broken up into sectors, which allows it to handle significantly larger maps, and render them much more smoothly during the generation process. On top of this, there are numerous UI and usability improvements. The full changelist is as follows:

User Interface:
  • Zoom button – Once generation is complete, the map displays fit to the screen. Hit the zoom button to view it at 100% scale, and drag it around.
  • Cloth button – It no longer automatically generates the cloth map view. Now it waits for you to hit the Cloth button, and once it’s generated, you can use this button to toggle between the cloth view and detail view.
  • Continent Shadows – During the generation process, it displays a “shadow” of where the continents will be located.

Generation Process:
  • Continent Shuffle – At the beginning of the generation process, the continents push away from each other (and the wall) just a bit, to cause them to overlap less.
  • Mountains react less to continent size – It used to be that mountains would be smaller, more detailed and closer to the coastline on smaller continents. This is no longer the case.
  • Smarter mountain locations – It used to be that mountains were generated in a full loop around every continent, but then their height, and presence, on a given pixel was determined by a global noise map. Now, each continent places mountains around some portion of it’s arc, and the global noise map, while still present, has a lot less affect.

Core Systems:
  • Sectors – The map is now broken up into sectors, with each sector being 256×256 in size. This allows for much larger maps, and a better framerate during generation.
  • New File Format – This follows with the sectors change. It can still load v0.1.0a files, but it will save in the new format.
  • Localization Support – All user-facing text is now stored in external data files, making it easier to edit and localize.


The image exporter has been temporarily removed. Moving to sectors created some significant challenges in exporting the whole map as one image. I think I have a solution, but it hasn’t been implemented yet.

Download: Mac | Windows

Sunday, February 27, 2011

Genesis Engine Demo Available

After much toil, blood, sweat and tears, I have the first public build of the Genesis Engine available for people to play around with (v0.1.0a). It’s pretty bare bones at this stage, just a simple UI for you to select some parameters for the world, and a Generate button that builds a world to those parameters. It will save out the final cloth map rendering to a PNG automatically (see clothmap.png in the executable directory), and has the ability to save and load a fully generated world (see the world.genesis file, also in the executable directory).

There will be a lot more to come on this project in the coming months, but this should be enough to whet your appetite, and show the potential for this world generation algorithm.

Download here