The source code is public domain (except for GreenSock’s stuff, which is Copyright, and you’ll have to download from them), and can be downloaded here: http://raelifin.com/files/ChessInFlash/ChessInFlashSource.zip

_ _ _
_ X _
O X _

The “O” player would pick randomly, because the “thought” of blocking X, and playing a drawn-out game was equally terrible as that of a quick death. Essentially, I had made an AI that really hated playing, and so would commit suicide.

Okay. Easily enough fixed. Never mind the half a day spent looking for bugs… Just keep coding…

I dropped the continual punishment/error factor and jacked up the punishment for lost games (keeping the old continual punishment factor for tie games). So now my AI played out to tie games (good)… with completely pathetic moves!

Here’s an example:

_ _ _ _ _ _ _ _ _

_ X _ _ _ _ _ _ _

O X _ _ _ _ _ _ _

O X _ _ _ _ _ _ X

O X _ _ _ _ _ O X

O X _ X _ _ _ O X

O X _ X O _ _ O X

O X X X O _ _ O X

O X X X O O _ O X

O X X X O O X O X

Now, what’s really fascinating is that it’s not playing randomly. If there’s ever a situation where one agent could win, the other blocks it. Even in complex situations where one agent can set up a sure victory in the future (a fork), the other blocks it. In other words, it’s defense is impeccable, but it has essentially no offense.

Thankfully I had stared at the code enough, and the past bug was fresh enough for me, that I didn’t need to debug for hours to find this one. The problem is I told each agent that the other one was perfectly rational. A perfectly rational agent makes no mistakes, and in Tic-Tac-Toe this means the best outcome you can hope for is a tie. Both agents knew this, and so every action (that didn’t lead to certain defeat) was equally futile. I had convinced my AI that the very game of Tic-Tac-Toe was pointless, so it stopped “trying” to win!

I tweaked the AI so that it thinks its opponent is only probably rational, but perhaps a little spontaneous. Now it plays aggressively. ^_^

Web Data:


* Huge number of volunteers for genome database

Telepathy:
* “Force Trainer” toy provides MRI for kids.
* Implant wires motor cortex to computer.

“Green” tech:
* “Mission One” electric motorcycle goes 150mph, with a 150-mile range and an optimum charge time of 2 hours.

I’ve been thinking about the future of currency this evening, and oh! I made a quick little simulation of the Fibonacci sequence the other day.

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. :)