todd

Twitch Games and World Building (but not together...yet)

As usual, Here Be Dragons can be grabbed here.

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.

2^16

NOTE: If you have trouble loading the page below, click "Main" up top, it should load the whole page correctly.

Been awhile...

As usual, the Here Be Dragons application is available for download.

Hopefully I'll have more to show soon, on many fronts.

Aside from a rather interesting day job, I've been working on strengthing the codebase (with some help from a few other folks) for 'Dragons and its kin. I've also been trying to relearn the quirks of pixel art and spritemaking, learning more and more about matrix projections and other 3D math, exploring the form of the first-person walkthrough, using crayons for the first time in what must be 10 years-If you think that this is all towards one project, your crazy, and if you think that they're for disparate ones, you're even crazier.

For the moment, I've compiled what I call "The Book of Permutations". Click on the applet and use the arrows to navigate:

That said, I'm not quite sure if this qualifies as the specific mathematical definition of the term "permutation". Some of you might liken it to "Every Icon" by John F. Simon, Jr. While the form is almost identical, I ultimately did this for somewhat different reasons. "Every Icon" is basically of a clock,
counting through every combination of a 32X32 bitmap, a process that will likely take several times longer than the projected lifespan of our universe. "Permutations", on the other hand,is more of a reference. Instead of counting through every 32X32 icon, I iterated through every 4X4 bitmap-a feat much more finite, consisting of only 65,536 elements. The totality of these images could easily fit in a book, or on a single image (here is the "index").

To look up (some would say "generate" or even "draw") an image, I find it easiest to work from the bottom up, that portion changes the slowest due to the way I visualize the counting. You can scan the whole book in under a minute, so equating an image to a number, while tricky, can be very fast once you get the hang of it.

The process was rather simple. Count to 65,536 (any power of two could work, although you want one that you can depict as a sqaure or rectangle if you want a nice, solid bitmap), converting the number to binary. Make each "1" black and each "0" white. I am certain this is what Simon did for "Every Icon", and it works here as well. Years ago (before I heard of "Every Icon", I swear!) I had the idea of doing this with an 8X8 grid, the standard size of a small icon. This would end of being an emormous 2^64 images. What actually brought me to this number were a few fables and other oddities. The I Ching has 64 trigrams, for instance. Legend has it that the inventor of Chess
requested as a reward 1 coin (or grain) on the first square, 2 on the next, 4 after that, until all 64 squares were accounted for. Incidentally, he was beheaded. The other story involved the puzzle known as the Towers of Hanoi. A series of discs must be changed according to a recursive system (at least that's the most efficient way to do it). For n discs, the minimal number of moves to complete the puzzle is (2^n - 1) moves. The story has a divine Tower consisting of (that's right) 64 discs, and upon its completion the world will end. Any student of combinatorics
will probably think the Tower is something of an optimisitic projection-last count the Sun is expected to last another 5 billion years or so. Even if the discs were moved at rates of one a second, the Tower would take much, much longer than that to complete. Still, 2^64 pops in a lot of "big number" myths.

I ended up doing 4X4 since it is another power of two in dimension (computers love those), and adding even a single pixel doubles the size of the whole collection-the definition of diminishing marginal returns. Besides, one can simply take four pieces from "Permutations" and create any larger 8X8 image-Of course, you can do this with a single pixel, but 4X4 is where images start to really emerge. Check out the faces (a few around #26889), the letter "A" (try around #40854), and the hilighted black sphere (#28630). Of course, each image has its inverse in there somewhere as well, along with a lot of variants. If you didn't care about inverses, actually, you could cut your work in half. If you didn't care about rotation, could further cut the work in into a quarter. Trust me, though,
rotation is a big deal-things look different on their side and upside down, especially at this scale.

Part of this experiment was to answer the question "What if someone alphabetzed Borges' Library of Babel?". The answer is somewhat interesting. You can see that the pattern looks something like a fractal grid, indeed I inadvertently created a fractal through this process-each larger element containing a the smaller elements that preceded it. Larger collections, like my 8X8 grid and "Every Icon", would look pretty much exacly like this image as well.

In terms of procedural content, this brings up a lot to think about. 4X4 is an interesting scale, for instance. It's just large enough to have recognizable icons (like the letters and designs above), but just small enough so that the overwhelming amount of junk or "noise" is not terribly overwhelming. In fact, even a lot of the "noise" can be read as either a part of a larger, more interesting picture, or still has enough abstract flair to prove useful for some graphical escapade. Also, a good procedural method would "cull" the elements that you would want out of this total, all-encompassing set-The culling itself could be a complex neural net, or a random pixel generator, or somebody with a mouse and some artistic sense.

Most ideas about digitally exhausting a system usually veer toward the "it's finite, but really really big, too big to be useful"-In this case I chose a value that was big, but also managable, and, I think, quite interesting to ponder.