Sunday, January 31, 2016

Cartagena, part 3

Good grief, January flew by.  It was a constant flurry of excited activity for me, from work and personal perspectives.  However, I've got an unclosed loop that I'd like to address here, regarding Cartagena.

To recap: in part 1, I started writing an engine for the Cartagena board game.  Part 2 dealt with incremental progress, as well as some missteps.  I'll summarize what happened next (part 3).

I finished out the console version of the game, separating what I felt like were game engine components from what was necessary to maintain the game state and interface via the console.  This resulted in two namespaces: cartagena.core and cartagena.console.  (Note: the current code repository has more stuff in it; don't let that confuse you).  Also, based on a comment from Jake, I made the engine itself completely stateless.

You can run the console game using a lein alias: lein console-game.  Doing so will result in something along the following lines:

The main glob of information is actually the board state itself.  This example shows a two player game, with orange and black pirates starting in the jail.  The first player it tanya, and she has six cards, with three actions left.

I opted to provide a default action so that the player doesn't have to actually press multiple buttons.  Both playing a card and moving a pirate backward require more input.  Playing a card prompts you to choose a card from your hand.

I got a bit lazy here.  The nice thing to do would be to number the cards and allow the player to choose a number again.  As it is, the player must type in the card's name (as a clojure keyword, no less!), unless they want to play the first card in their hand, in which case they can just hit Enter.

The last bit of information required is which pirate should be moved.  Specifically, the game asks from which space to move a pirate.  To begin with, all of a player's pirates are in jail (space 0).

A nice-to-have would be for the game to interrogate the board to determine what your possible moves are, and then only present you with viable options.  If only one option were viable, it would perform that action.  As it is, the game isn't helping you out at all... ;-)

After the action is performed, the board and active player state are re-displayed.

Notice the orange pirate in space 3, as well as the fact that the :hat card is gone from tanya's hand.  The game lets you know that you only have 2 actions left.  

Here's a quick screen cap of tanya taking her last action on the turn.

After moving another pirate out of jail, tanya is out of actions.  The active player automatically rotates to the next person.

As you can see, rusty is now the active player, and tanya is obviously going to win.

Gameplay continues on in the manner shown above, with pirates moving forward and backward until one player has successfully ensconced all of their pirates aboard the ship.  At that point, that player is declared the winner and the game ends.  I don't actually have a screenshot of that, because I've never actually won.  As I've already stated, tanya wins every game we play.  :-)

So, where do I go from here?  I know the engine isn't perfect, and I also know the console game is buggy.  However, it's certainly good enough to move forward to whatever's next.  The entire reason I started down this path was to learn something new.  The game has been good practice so far, but ultimately I want to play this thing in the browser, preferably with multiple remote players.

SPOILER ALERT! I've already finished the first version of the web code as well, but I'm not going to blog about that until next time.  It will be well before the end of February when that entry comes out.  I'd like to get back into the habit of about an entry a week, so help keep me honest, people!  :-D