How To Make A Cube In 81 Easy Steps

Hi all! It's been a couple of weeks since my last post. I've been very focused these couple of weeks on trying to generate buildings from an algorithm. It's been slow going. The basic algorithm goes something like this:

1) Generate a shape.

2) Do stuff to the shape.

3) Texture the shape.


The first step is the easiest. Here is a shape:

I chose a box, since that is the basic building block of most buildings. I'm going to add in a cylinder and a triangular prism, later, and those three shapes should be able to make up the vast majority of buildings that I would want to create.

Now, even this first step wasn't as simple as it appeared. In computer graphics, shapes are made up of vertices connected into triangles:

Each vertex must be given a three-coordinate vector that defines where it is in the game world, and each triangle must be given three numbers defining which vertices make up the triangle. If these numbers are messed up, the game engine doesn't know how to turn the list of vertices into a three dimensional shape, and we get all sorts of strangle holes and non-rendered parts of the shape. To complicate this even further, all meshes (the technical name for the things which compose a computer graphics shape) also have a list of normal vectors, which define which way each surface faces and how light bounces off that surface, and a list of UV coordinates, which define how a two dimensional texture is mapped onto the three dimensional surface of the mesh. 

So even just to generate this simple box, I have to tell the computer where all the vertices go, how to combine those vertices into triangles, how to calculate the normal vectors of that shape, and how to handle UV mapping onto the shape. Just for one box!

The hard part, though, is step two. Manipulating this shape means manually adding new vertices at positions based on the positions of existing vertices (not so bad), and then recalculating the triangles to account for those new vertices (really freaking hard). That's what's gotten me stalled for the past couple of weeks. There is a solution out there, because plenty of people have gotten it working. But those people probably know a lot more about coding than me. 

Luckily, there's quite a bit more to the game than the procedural generation! I may be approaching things in the wrong order. My new plan goes like this: Build the other game systems (shooting, hacking, enemies and AI, modeling), put together a demo level (without the procedural generation) to see whether or not it all works, then continue work on the level generation once I have a feasible game. Throughout all of this, I will continue to learn about procedural level algorithms and hopefully by the time I get to the end of this phase, I will know enough to put together fun, interesting city levels procedurally.

In fact, I've already started looking into procedural generation of 2-D levels. Working in only two dimensions saves me from having to work with meshes at all, for now. Also it's probably more logical to start with the easier stuff rather than diving straight into the deep end. Also also, this gives me a chance to work on my animation skills! I have a vague sort of idea for a platformer starring this little hunter:

I'm not sure whether or not I will make it into a full game, since I'm already working on the shooter. I will definitely use it to practice animation and procedural generation.

Check out this video I watch when I want to keep myself excited about the work I'm doing:

That project uses L-systems and graph grammars to create architecture, which is the same system I'm trying to implement.

Stay tuned!

Here's an article that sums up my love for fantasy, nature, and video games with an evocative analysis of landscapes. And here's a brilliant re-imagining of the tired question, "can games be art?".