I’ve been developing and filling in a number of gaps in my abilities, regarding procedural methods and other things. Now that I’ve finished the major milestone in my day job I have a little time to post what I’ve been doing aside from what I’m supposed to be doing.

On a few new games:

I’ve been working on a few smaller projects, for fun as well as a much needed chance to polish something for general use. The 80%/20% (the last 20% of a project takes 80% of the total time) is very true, and I’ve managed to avoid it for a while, so doing these smaller projects may help get me back into project completion mode.

The first is a shooter where you don’t shoot. Instead you have a reflector (the blue circle in front of you, the equally blue critter):

The reflector takes any enemy shot and redirects it….

…hopefully back in their face.

This can make for some heated moments, as well as an interesting turnabout. “Bullet hells” can turn to your advantage. Being in the right place at the right time can devastate wave after wave of baddie.

Have the infrastructure for levels, bosses, and bullet patterns…classically, assets are the big time sink. I’ve been getting back up to speed on pixel art, and balancing random level generation.

Another game I’ve been tinkering with isn’t as far along, but I do have a level system and minor agent behavior-Codenamed “Efpeyess”:

Actually, I may use this code for a few ideas I have, a first-person game, maybe a few third-person ones as well.

Both of these games have a flexible enough method of level and critter handling that any variety of procedural methods could be used to generate worlds. How interesting they’d be depends entirely on how you go about determining the algorithims.

One idea I’ve been working on is multiprocedure (or metaprocedure, if you feel pretentious). The issue: People are excellent pattern recognizers. If you use only a single algorithm to build whatever you’re building, people will catch on quickly. A series of terrain maps that only use Perlin noise will all look basically the same. A series of mazes generated using the same math will blur together in the spectator’s eye. These algorithims are useful (in Perlin’s case practically necessary), but probably shouldn’t be used exclusively.

When you want novel content, you do NOT want them all to blur to a vague grey. One problem is that random numbers are designed to do exactly this. While you might want go statistical spreads when calling rand(), statistical aberration by definition makes something unique and novel.

One way to get around the “grey goo” is to mix and match different emergent and chaotic algorithms. The way you mix and match these algorithms, as well as how much you mix them can itself be determined by some chaotic element. One might mix the Perlin noise with Voronoi cells, to get labyrinth-like canyons in the middle of high mountain ranges.

One trick is to not use every method at your disposal every time. Things are usually awesome because they are rare-or at least not experienced repetitiously. A galaxy with planets that have an equal amount of every type of terrain will get dull fast. Some might be almost entirely mountains, others largely ocean (I’m posting this from such a planet right now), others might a plains punctuated by volcanic badlands-and few might have a healthy mix of various biomes.

For agents and architecture, the idea is the same. You should have enough coherency to be recognizable, but enough variance to be worth recognition.

Some of this I’ve been developing as I’ve been playing with terrain generation-I’ll probably go into a step by step process in a later post. For now, I’ll just post some of the results.

On Terrain:

I love terrain mapping more than any healthy person probably should. I’m currently experimenting with random terrain generation (and navigation) using a combination of Photoshop, Processing, and C++. The pipeline of experimentation is informed by my theory:

a) If I can do it in Photoshop I can do it in Processing, but dynamically.

b) If I can do it in Processing I can do it in C++, but faster.

It can go backwards when I want pretty pictures to show people (or print out):

The map created was tested in Photoshop, but I did not do anything I don’t know how to do, at least in principle, in Processing or C++. The shading is done using a Processing applet I did, which simply compares the height of the pixel to the upper left and shades accordingly. I use this trick for shading the 3D mesh as well. I found the algorithm online at GameDev.net, a lot of good return on minimal coding trickery.

Right now I’m mainly doing the simplistic (far, far too simplistic) height->color, although I have been experimenting with a “climate filter”, that tries to make more desert at the equator and more snow at the poles. It’s a combination of a simple gradient and Perlin noise. I added a subtle amount of it here, you might notice some snowy patches that aren’t on mountains, and some sandy regions inland. Like I said, it’s subtle, but when you try to do things with at least a touch of realism, subtlety is everything. If I do a more in depth post on the process I’ll show you some before/after pics.

By the way, the color isn’t bad, it’s iconic. I’ll be doing some better color schemes once I’m happier with the terrain-generating math.

One might see a few Voronoi-like canyons to the north and to the west on the map-these were blended in to the Perlin noise-based terrain. In flythroughs, they are by far the most interesting and recognizable places to go to on the map. This is, of course, relative. If the whole map had been largely Voronoi cells punctuated by Perlin mountains, the mountains would have been the major draw point for visitors.

At this stage I can funnel it into whatever build of Bushido I’m currently turning to spaghetti:

The next step, of course, is to update my work on the critters and cities that will be populating such wilderness.