This page covers "b5.py", the April 2007 build, and was written starting 26 May, 2007.
by "build", I mean a work-in-progress implementation of the "KC" concept, which is based on the King's Court / "supercheckers" board game. This is a fan-made game with no official relation to the original board game.
I used "pygame", which is basically a port/wrapper libaray of SDL to Python, in a w32 environment (more specifically, Windows XP, but it should work on any python platforms). The build I'm analysing is about 1,300+ lines of code, which to me is too big for what it does but my real issues is with the organisation of the code, not the size.
I wrote this while trying to design the program as well, and also while learning Python, libSDL, and pygame. This implies the usual inconsistencies that come for an ad hoc project. Nonetheless, I happened upon some key features neeeded for the final:
That being said, let's get on with the tour.
First up, I'll talk about the context-dependent menu system (CDMENU). This is a menu whose options change dependent on context. In this case, "the context" is given by various game states or modes. These modes are present in the board game, but they're automatically implemented by the players as they play by applying the rules, almost unconsciously. Since the computer only does what it's told explicitly, they need to be made more obvious... that only occurred to me after I had done it, however. There's something to be said for Rapid Prototyping as a way of solving design problems.
The menu on the right side of the screen has "Chain..." highlighted, although it would be a lot clearer if I used an arrow of some sort to emphasized that. Anyhow, the selector is "holding" and "orange" piece. One of the visual cues I developed was changing the cursor slightly when it was holding a piece, from when it was in free-range mode.
Now, in a board game, if you wanted to jump the two orange pieces in the inner court with the piece selected above, you'd just grab it and make the motions, tapping on the intermediate square to let others know your intentions. On the pc, you could literally simulate that by making you hold down a mouse button or something, but it is more ergonomic to use the "Action button" to switch modes from holding to released/free-motion. I also used the same button to select the highlighted menu option, in an more animated engine, some visual and audio cue to shift attention to the cdmenu would probably be helpful (or annoying).
So what happened here is the piece south/downwards of the piece being held was jumped, and then action pressed to release/move it, and then the cdmenu asks you to Confirm (which will confirm the move as a jump), chain... (which will allow you to do one or more additional jumps), or Cancel (which will allow you to "take back" the move, rather than commit to it.
Anyhow, he're what you do in the computer game:
Move to the intermediate spot, and press "Action" to select "Chain...". This leads to another menu, "ChainMore", which lets you know that you have made at least 2 consecutive jumps already, "BackStep", which would take back the last jump only, End Chain to let that be the end of the move, and "Cancel" to start all over.
In this case, they are no more jumps that can be made, so the "ChainMore" option does not appear.
Here, the chain was just ended, and the move implemented. It's not Green's turn. The final product should keep separate track of Green and Orange's cursors, for hot-seat play, perhaps.
Anyhow, the menu is now gone since we're in "free" mode, not holding a piece. Note that the selector thingy has changed slightly and now has just the 4 corners, no mid-pieces.
Now, here's a typical reply from green, later on in the game, about to eat the last Orange piece from the inner court.
And the blue text to the top of the screen shows the outcome: Green wins.
Unlike the DOS game, which had a separate victory screen, for this prototype, I just coded the in-game logic and hacked together the rest, so there's no combo counter or anything so fun and dramatic. The final game will have those things, though, and won't be outdone by its DOS predecessor.
The are problems with implementing a this particular board game, which is very easy to learn for humans, as a computer game. These problems involve the hidden complexity of the ruleset, as well as my tendancy to only try doing this using technology which is relatively new to me. The complexity was not apparent to me until I tried to "do a simple game" and became aware of these non-obvious-to-me problems. Now that I'm aware of them and have successfully implemented solutions, work on KC can progress towards doing a full game, with ability to play against the computer and so forth.
The pygame environment provided a convenient place to do rapid proto-typing as a design-resolution exercise.
[ Index of KC2 Project ] [ Up to main site index ]
Lord Granitor, aka K31. 26 May, 2007. - 03 Jun. 2007.
[ Homepage: http://geocities.datacellar.net/granitor ]
Yeah, I know, this writing is crap. Blame it on the heat.
