Yesterday I decided to play with some genetic programming. Though I found a neat GP resource, I decided to work from scratch and build a simulated tide-pool with algae/plants and animals of indeterminate form. Truth be told, I’m not even sure what I did really “counts” as genetic programming because the only evolved feature is the behavior for the animals. Regardless, I wrote the thing in a single day and got some neat emergent behavior and a screen-saver-wannabe. Green dots are “plants” and yellow/white/red/black are “animals”.

The code and runnable Jar are here. Everything is public domain, though I humbly request you don’t try to pass the work off as your own. The pulsing brightness is supposed to be day & night. The source code is really sloppy, so keep in mind that this was a quick, shoot-from-the-hip sort of project and please have forgiveness.

Controls:
Minus/Underline = Slower
Plus/Equals = Faster

Everything (code and images) is public domain. Credit is nice, but not necessary. Download code (and runnable jar) here. Created using Slick (Build #266) with LWJGL (2.0b1).

A Geocentric View of the Universe.

Another Geocentric Perspective.

View from Jupiter.

Oh, and I almost forgot! One of the other neat things I did with the simulation was “experimentally” measure the speeds of the planets (except Neptune). I looked up average orbital distances and the mass of the sun on Wikipedia and then tweaked the initial velocity of each planet until the orbit looked roughly circular. I did this mostly out of laziness, but I was shocked at how close I had gotten to the real values.

Most of the class was thinking of making an obscenely huge strategy game akin to Risk meets Monopoly, which just so happens to be the sort of design which I despise. Having spent many long years learning the hard way to design as small as possible, I helped my team brainstorm a small, grid-based, strategy game based on resource management and simple unit-movement. My hope was that the project would be basic enough that it could be running with an initial rule-set within the week and that the remainder of the term could be devoted to polishing the interface/graphics and working on the rules. (I was only vaguely aware of it at the time, but this sort of thinking would expand into rapid-prototyping, playtest-heavy, and iterative design philosophies in my own work.)

We decided on a zombie theme, with the twist that the zombies were actually corporate pawns, and the necromancers were CEOs. It’s kinda vanilla, but it was a 1-hour design within a group of relative strangers. We presented our designs for the class and they decided to work on Risk-Monopoly. That weekend, in about 8 hours*, I built a working alpha for the game:

EDIT: If the images aren’t working, you may need to view this post by itself.

Rules:
The player on the left (pink/green) goes first. And then blue player takes a turn, and so on.
To move an army, drag them to an adjacent square. (They move like kings in chess.)
Armies are composed of undead: zombies, lawyers, or both.

Each space is commercial, residential or corporate (Starbucks, house or building). At the beginning of each turn, you get cash to buy lawyers with and new interns to turn into zombies. The goal of the game it to capture your opponent’s skyscraper. The income is as follows:
Corporate Space: +$5,000 & +5 interns / turn
Commercial Space +$2,000 / turn
Residential Space +2 interns / turn

Each turn you get one action (upper-right), in addition to moving each unit. Select a board space then chose:
PROMOTE: Turn all interns into zombies at the selected space.
HIRE: Hire lawyers for $5,000 each at the selected space.
DEVELOP: Selected commercial or residential space now produces 2N+2, where N = current production. (Units are single interns or thousands of dollars.) Each space can only be developed twice.

If you move into a space that has an enemy army, you deal damage to them, killing a number of units. If you defeat all units in a space, you capture it. An army with both lawyers and zombies loses its zombies first. Lawyers deal roughly 5x
more damage to zombies (I forget the actual multiplier).

It’s really a very boring game, but the idea is that it’s playable and (mostly) bug free. Additional rules and features can easily be added onto the skeleton in an attempt to make it more engaging. At the end of the week you’ll have a game, though, and you’ll have a good impression of roughly how fun it is. This last part is vital, I think, to good game design.
Rapid-prototyping lets me play a game with very little time investment. This lets me determine whether it is worth making.

* This amount of time is actually quite excessive for such a simple game. At the time I wasn’t using Slick, and I didn’t have much experience with applets.

Disclaimer: I do not own any of the graphics used in the game, but I feel that they are used fairly. Unlike most of my work, this game is not open source, and I ask that you do not redistribute it without permission. Its sole intent is to showcase what I did one weekend, and maybe talk a little about game-programming.