Let's Code – CPM2DoB Part 5: Slay

So Lent ended and suddenly I could play games that I didn't write, which sort of cut into my time (more than motivation) to finish CPM2DoB. Also, the fact that it is now actually playable makes me think less about plowing ahead to get something finished.

But the main reason I haven't been working on CPM2DoB is because I finally noticed that Slay came out for Android, and I've been playing that non-stop. I used to have Slay for my iPhone, but when I picked up my Android, it had not yet been released for the platform (the loss of that, Bejeweled Blitz, and my Cross Sums app, were the hardest part about switching to Android). A couple weeks ago, I thought back to Slay and found out it was finally released on Android.

Slay is a brilliant game. Simple rules which lead to complex strategies. Addictive turn-based gameplay. All wrapped in a cute little package. The game is played on a hex grid. At the start, you have territories scattered across an island, along with five other players. Each territory has a capital, and the capital accumulates the wealth of that territory. Each territory gets one resource per turn for each hex space in the territory (unless there's a tree on the space). Resources are required to buy your soldiers and also for their upkeep. The basic units are peasants, which cost 10 resources to buy. Putting two peasants together makes a spearman. A spearman plus a peasant makes a knight, and a knight and a peasant makes a barron. You can capture enemy spaces so long as they are not defended by a unit as strong as your attacking unit. So peasants can take spaces so long as they are not defended by other units. Spearmen can take spaces defended by peasants. Knights, by spearmen, etc. Units defend the space they occupy and all adjacent spaces. In addition to defending with soldiers, your capital acts as a defense unit (equivalent in power to a peasant) and you can also build defense towers (equivalent to spearmen).

Units also require resources for their upkeep. A peasant takes 2 resources, a spearman 6, knights 18, and barrons 54. If a territory runs out of resources, all units in that territory die. You can join your territories, obviously, by capturing the spaces in between them. And you can split enemy territories. So a major part of the strategy is to outflank the enemy, splitting his territories, and causing his troops to die of starvation, but without overextending yourself, and opening your own troops to being outflanked.

While playing this, I began wondering how some of these simple strategy game concepts—such as resource management, territory control, and unit purchase costs—could be applied to chess. I began to think it might be fun to add a new game mode to CPM2DoB that incorporates these concepts. The rules I have in mind might go something like this:

• At the start of the game, the spaces in the board are randomly assigned a resource level. They would probably be simple, like three resource levels: low, medium, and high. Low resources spaces would give one resource, medium would give two, and high would give three. The spaces would visually indicate what resource level they give.
• Each player starts with a king. All other pieces must be purchased with resources.
• At the start of the player's turn, he receives resources based on the spaces he controls. Something like full resources for every space he occupies or threatens uncontested (i.e., one of his pieces can move to it, but no other players' pieces can), and half resources if he threatens it, but it is contested (i.e., another player is also threatening it).
• Alternatively, it might be more Slay-like, where once you've captured a space, it's yours and you gain resources for it until another player takes it.
• On his turn, a player could either move a piece or purchase a new piece. New pieces are placed in relation to the king, based on the piece's moves. So a new knight could be placed a knight's move from the king, a new queen would be placed a queen's move from the king. I think in this game mode, pawns could move forwards, backwards, and to the sides, and capture on the diagonals.
• Pieces should require upkeep, probably related to the purchase price. If a player runs out of resources and can't pay the upkeep, I'm not sure what will happen to his pieces. They might start losing health; they might die off in some order (maybe based on piece rank) until the upkeep payment can be made with the player's current resources. Or, I might go full-Slay, and all the pieces die. This might be how you lose.

So, what do you think? I haven't started programming this game mode in yet. I have a number of other changes to make. Most importantly, I need to implement AI, so I have something to test this out against. I have an idea of how I'm going to implement AI, but that is in itself a great big can of worms.

Let's Code - CPM2DoB Part 4: WHAM!

That, my friends, is the sound of running head-first into the solid brick wall of poor code structure.

I just wanted to let you know that yes, this project is still alive. As Easter loomed, I had a major project due at work that kept me from working on it much, and The Murloc also had a thing happening that required I look after the boys at home. All in all, not much time was to be had for coding.

But I did get it working and playable! (Barely.)

So back to the aforementioned skull-shattering, neck-breaking, spine-telescoping, head-on collision. I was probably about an hour away from a playable build of the game, just putting the finishing touches on the methods that handled pieces movement, damage, captures, transformation, and victory checks, when I discovered a fatal flaw in my code organization. It was caused mainly due to laziness and not thinking ahead, but resulted in a flaming crash.

(The specifics were that I was writing the piece transformation method, y'know to allow a pawn to turn into a queen. Unfortunately, the master list of the different piece types (or "masterPieces" as it's known in the code), was not visible in scope to the transformation algorithm. I could have patched it by awkwardly passing the list as a parameter through the several layers of function calls necessary to get it where it was needed, but that would have been an awkward kludge on what was already a very kludgy mess. The alternative was to move the master piece list to the class where it was needed. But that required one change, which required a restructuring over here, which meant these other methods wouldn't work and would need to be redesigned, which meant this part was now over-complicated and should be streamlined, etc., etc. All in all, what was looking to be an hour or so of coding turned into a week. On the plus side, the code was much better organized once I finished.)

So after struggling fuming, and fussing, I finally got a working build! You can move pieces! And capture! And it will even check for victory conditions! (Yay!)

Rememeber: victory is capture-based, not checkmate-based, since checkmate is impossible to determine for random damage and kings that can fight back after taking a few hits.

NYI: Auras.

Let's Code - CPM2DoB Part 3: Purpose

There are 2,771 results for "Chess" in the Google Play store. Googling "Chess app for Windows" returns about 10 million results. There's even several open source chess engines. So why am I writing a chess program again?

Well, aside from "for practice", I wanted to do something different. What if the pieces had different moves? What if queens could move like knights, or knights weren't limited to one hop and could continue to move along their path, like bishops and rooks? What if the pieces started in different arrangements? What if they were in a wedge formation, rather than abreast? What if all the pawns were replaced with queens? What if the victory conditions were different? What if you had to capture both king and queen to win? What if the board had special properties, like wrap-around edges, or was 10x10 instead of 8x8? What if it was a hexagonal grid? What if pieces had health and damage? What if it took several attacks to kill some pieces? What if others could heal their teammates? What if pieces had auras that would enhance the abilities of pieces near them?

By now we're hardly talking about chess, but some strange turn-based RPG strategy game hybrid that just happens to have chess pieces. Oh, that's a good idea, too. What if you could change the look of the pieces?

That was the idea behind a Chess Pirate Mercenaries 2D of Battle. I wanted to write a chess program with user-definable pieces and moves, that could handle all sorts of different board configurations and rules. So now, I can show you the rest of the Options dialog that I fuzzed out in the last update:

Let's Code - CPM2DoB Part 2: Cosmetics

Part I.

Well, I was planning on talking about design philosophy this week, and was going to explain what's different about Chess Pirate Mercenaries 2D of Battle, but I got sidetracked. There's a simple truth when it comes to form design (and cosmetic programming in general):

The amount of time needed to perfect a form increases exponentially as the form nears perfection.

Basically, there's this weird vortex where, as you put more time into perfecting the design, it takes even more time to perfect than it did before. So if the form is sorta OK, then it'll take a little bit longer to make it perfect. But if the form is great, then it'll take even more time to perfect it. Weird, huh?

I have made progress on the game mechanic design, but ended up devoting more time to making it pretty. So now we have this:

Oo! Aah! Textures!