Tea Leaves

Bonaguil 0.1

by peterb

Because I'm kinda thickheaded, I spent my weekend vacation programming a game. That's my idea of relaxation. I'm funny that way.

This is a bare-bones reimplementation of the SSI-published Apple ][ strategy game Fortress, ("A game of strategic development and fortification") which combines elements of Go and Chess, although it is much less sophisticated than either of those games. I don't know if this was based on some actual board game; I suspect not, since the scoring is irritating enough that I can't imagine doing it without a machine's help. It's a fun game, though, and I got tired of firing up the emulator in order to play it. Thus, this version, which I call Bonaguil (I was considering calling it "Harlech," since the original Fortress used the ancient tune "Men of Harlech" as its theme song, but if you've ever actually seen Château-Fort de Bonaguil up close and personal, you'll agree it's a good choice).

Bonaguil is a game of taking territory. Each player takes a turn; on a player's turn they can either place a new castle on an unoccupied square, or fortify one of their existing castle. Castles can be fortified twice, so a castle has a strength of 1, 2, or 3. Castles exert their strength level on the square they are on and on the squares in all 4 cardinal directions (or fewer, if they're on an edge.) Influence strength of like castles are additive, influences of opposite-coloured castles that intersect are subtractive (so two strength 1 castles of opposite colours with one empty space between them result in that empty space being uncontrolled.)

If a castle is on a space with no positive influence, it is "in check" (for example, two opposite coloured castles right next to each other will control the spaces away from each other, but will put each other "in check", in the absence of any other factors). The game represents being "in check" by the drawbridge coming up and the windows turning red. A castle on a space the enemy controls is destroyed. Newly placed castles get to exert influence before they are destroyed, so it is legitimate to drop a castle in a suicidal spot if doing so might kill an enemy castle

The present version is extremely primitive, but all of the game logic is encapsulated in its own class, so it will be easy to extend, which I'll be doing over the next few weeks. I even went ahead and drew some cheesy icons and used those instead of text display, even though I'm about as comfortable with drawing as W.C. Fields was with playing with children. My initial cut was a bit more colorful -- I used red and blue, instead of black and white -- but I toned it down to try to stay true to the feel of the original.

Features I plan on adding, if I can find the time, include:

• Some basic AI so you can play without a partner (this was claim to fame of the original Fortress: it had different AIs with different play styles, and they adapted and learned as you played them) At least in the short term, I'll probably focus my effort on making the AI module pluggable so I can sucker other people into doing the hard work allow the gaming community unfettered access to express their creativity.


• Some in-game help and instructions so that people other than those who played the original Apple ][ game know what the heck is going on.


• Some animations / better user feedback. There's one tricky corner case where it is a legitimate game strategy to drop a castle in a suicidal position because you're trying to take out an enemy castle that is already in check. As it is now, both the enemy castle and your castle disappear pretty much simultaneously. This is "correct," but a small delay and some 'death animation' for a castle might make it more clear to the player what just happened.


• Apropos of that, I'd like to support multiple icon sets, so that people aren't stuck with my horrible little pictures.


• Allow the user to set some of the game's parameters. The big one here is game length (it's currently hardwired to 21 turns), but there's no reason we couldn't let people choose arbitrary board sizes (internally, the game can handle any size square board; I did the initial testing with a 3x3 board).


• A log of game moves so games can be replayed (and debugged, for that matter)


• Long-shot goal: network play, and player history/ratings.

I'll release the source code under some fairly permissive non-Gnu license once I'm comfortable that it's not completely embarrassing -- it's been several years since I've done anything in Java, so this is still too rough to show the source code to anyone yet.

Which brings me to a brief digression: God, I love Java. I know this is probably simply the-grass-is-greener syndrome. I work writing systems-level code for a high-performance distributed filesystem in C. I have to ask myself questions like "What happens when we get a request to do a few thousand of these operations at once?" or "What happens if this update needs to go out to several thousand clients?" Programming a little game like this in Java is like being an alcoholic on-the-wagon children's clown at a party with an open bar. "Yeah! Let's do this the slow way because it doesn't matter! Hey, I need some scratch space. Let's just allocate a bunch of objects even if I might not use them! Hmmm, gonna be doing some arithmetic. I'll just precache a matrix table of every integer addition with addends below 1000 just because I can! WAHOOOOOOOOOOO IT'S PARTY TIME!"

(Of course, after I do those things, I make sure to complain to everyone I know that Java is slow. Just kidding!)

I had a basic, text-only version of the game up and running in about 60 minutes; it took just another two hours or so to get the graphical version working, and most of that was spent drawing the icons. It's not very pretty, of course, and it doesn't do much of anything yet. But just the mere thought of how much more painful this would have been to implement in pure C on pretty much any platform you care to name -- well, it makes me love Java all over again.

If you see something that looks like a bug, please drop me a line and try to describe what you saw.

Hopefully the authors of the original game (Jim Templeton and Patty Dembrook -- I've tried to locate them, without success) won't sue me.

To play Bonaguil, if you have a Java-enabled browser, just click here. I've noticed some "issues" getting it to work if you're behind a firewall, so if any Java gurus want to educate me on how to deploy an applet that doesn't break in a firewalled environment, I'm all ears.

Posted by peterb at August 2, 2004 12:45 PM | Bookmark This