Zombie Corp.

During my first year of college I showed up one Friday for my C++ class only to find that it was canceled. Not wanting to simply go home quite yet, I talked one of the other teachers into letting me sit in and participate in one of the upper level game-development classes. We were broken into teams and instructed to design a game to work on for the rest of the quarter. I, of course, didn’t have to code anything, being in the class just for that day, but I jumped in anyway.

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.