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:
You can change the board dimensions, allow wraparound, and eventually, I'll implement hex grids.
You can set the number of players, and set how many moves each player can make on his turn.
Victory conditions are any victory piece, every victory piece, decimation, and annihilation. Pieces can be flagged as victory pieces which means you win by capturing the enemy victory piece(s) in the first two victory conditions. Decimation means you have to capture a certain percent of the enemy pieces (defaults is 10%, i.e., you have to decimate the enemy, in its literal meaning), and annihilation means you have to capture every enemy piece.
I've also implemented the UI to edit pieces, moves, auras, and the board configuration.
This lets you edit the "master piece" list, which is a list of all the kinds of pieces in the game. You'd give the piece a name (for easy identification), and tell which player can control it. You can also choose from one of the included piece images (courtesy the Resident Murloc) or load your own.
For the pieces, you can set stats such as armor, health, damage, and healing. There are eight armor rankings, which correspond to damage reduction from the eight directions. This obviously applies only to games where pieces have different damage rankings. So, for instance, a piece might have strong damage reduction from frontal attacks, but be weak in the flanks. I haven't quite decided how the armor arcs will be distributed; whether north, south, east, and west armor only reduce damage coming directly from those directions, and diagonal armor reduces damage from the general diagonal; or if the diagonal should only apply to direct diagonal attacks, and north, south, east, and west armor would cover the entire arc.
 |
| Should the knight's attack apply against the rook's south armor or south-west armor? |
"Victory piece" I covered earlier, and it just means that for certain rule sets the piece either must or can be captured to win. "Spy" means that the piece is treated as a friendly piece to the pieces on other teams. At one point in time, I got it in my head to make a Team Fortress 2 piece set, and this seemed like a requirement. The only way an enemy could damage a spy is if the enemy has a move which also hurts friendlies.
Speaking of moves....
There are a lot of settings for a move. You tell it the change in X and Y, and the number of repeats allowed ("range"). So a knight's moves are ±1,±2 and ±2,±1 with a range of 1. A bishop can move ±1,±1 with a range of 8 (or higher for larger boards). "Enemies hit" and "friends hit" allow a piece to move through other pieces and hit things on the other side, damaging (or healing) everything along the way. So some pieces might be juggernauts that break through enemy lines. "Friends hit" is ostensibly for healing moves, so a bishop can heal everything along a line. As mentioned before, it can also be used to attack spies.
Multiplier is just a factor applied to the piece's base damage. This way, the piece might have certain attacks, like a frontal assault, that are more powerful than its flanking moves. Splash just indicates the range of splash damage. This allows for AOE (area of effect) attacks that will damage multiple pieces. "Turns" (or maybe it should be called "moves") tells how many of the moves per turn are used up by this move. This applies when the board rules allow more than one move per turn. You might have an especially powerful move that takes more than one move.
Row/column conditions are how you tell that the move can only be made in certain places. For instance, a pawn can only move forward two spaces when it's in the second rank. When the condition is "-1" it means the row or column doesn't matter. Otherwise, the move can only be made in the specified row/column. Unfortunately, the conditions are too primitive to allow for castling. At the moment, I'm not sure how to easily implement the complex conditions under which castling is allowed (the king hasn't moved, isn't in check, none of the intermediate spaces are checked, and a rook is present at the appropriate place). Certainly, I could implement it, but I would either have to hard-code it, or the move definitions would become awfully complex. I could probably make a relatively simple UI adjustment that would allow you to specify that the move can only be made if another piece is in the correct spot, but I'm not sure how to easily add the other conditions. Adding to this is the fact that, unfortunately, there won't be rules that would limit the available moves when in check, since I'm not sure how that would work with multiple victory pieces--two or more of which might be in check--or victory pieces with more health than their attackers; it should be possible to capture the enemy victory piece with your own, if yours has more health. Combined, this means the program won't be dealing with "check" or "checkmate". You win by killin' the bastards, and the program doesn't care if you make a dumb move and put your king at risk.
There are a few different move types. ATTACKMOVE is the default, and corresponds to most chess moves. It means the piece will attack the space if occupied, or just move to it if not. Contrast this with ATTACKIFOCCUPIED which means that the piece can only move to a space is occupied. For example, a pawn can only move on the diagonal if there's a piece to attack. There's also ATTACKNOMOVE which means the piece will make the attack without moving to the space if the piece is captured. I envisioned this being used for archers or other ranged attackers in a Roman Legion-style piece set.
HEAL means that the move adds the piece's healing value to the attacked piece's health, rather than deducting the damage. You could accomplish the same thing by specifying a negative damage multiplier, so I'm not sure why I included this move type (or healing values to begin with). I think it was for simplicity. Also, separate healing values makes it easier to define moves that damage enemies and heal allies at the same time, if I ever decide to include that sort of thing. [Update]: I figured out why there's a separate heal move: a move with negative damage means it's increased by the piece's armor, because damage equals (damage * damage multiplier) - armor. A heal won't take armor into account.
MOVEONLY is the opposite of ATTACKIFOCCUPIED. Whereas the latter will skip over unoccupied spaces to attack occupied ones, the former will skip occupied spaces to move to unoccupied ones (so long as Enemies Hit or Friends Hit allows the pass-through).
Comparison of a pawn with diagonal move, range 5, enemies hit 3. In both cases, valid moves are purple:
 |
| ATTACKIFOCCUPIED: the move will skip unoccupied spaces to attack occupied ones. |
 |
| MOVEONLY: the move will skip occupied spaces to move to unoccupied ones. |
Lastly is TRANSFORM which means the move isn't a move, per se, but will allow the piece to transform to another piece, if the row/column conditions are met. This is applied after another move is made. You can also set what the piece can transform into, with the default being "Any". The obvious example is a pawn which can transform into another piece when it reaches the last rank, but you could also use this to make a piece which can, say, transform back and forth from bishop to rook at will (at the end of each turn). After you move the piece, you could change it for the next turn. This would also be used by a Druid which can turn from caster to moonkin, cat, or bear forms, each with different moves and strengths, in a hypothetical WoW piece set.
 |
| I'm going to rename "buffs" to "auras" at least in the UI, to make it a little less MMO-centric. I probably won't bother updating the variable or control names, which I'm sure couldn't possibly ever confuse me. |
If you're wondering how far I've gotten with actually implementing all this, the answer is pretty far, but not quite far enough. The UI to add all these pieces and attributes, and define a starting board configuration is in place. In the process of writing and testing that UI, I also had to implement the code to check for allowable moves, which was the hard part. All that really remains is to calculate buffs, and actually allow the moves to be made during gameplay, then calculate damage, deduct heatlh, check for victory, and turn control over to the next player. It's very close to playable. Maybe a week to a month?
Normally, with a project like this, I start out with a lot of enthusiasm and ideas about all the cools things that the game should do, then become completely overwhelmed by the scope of the project, wouldn't even know where to begin with the necessary data structures and custom classes and project organization and just slowly back away while avoiding eye contact. That didn't happen for some reason this time. I think it's because, going in to it, I had a very clear vision of what I wanted to do, so I knew what classes I needed to write and what properties they should have. The last game I attempted (our "Starship Combat" strategy game), I had so many features in my mind, most of which were just vague ideas, that I didn't even know what classes to write, or what they should do.
The next posts will be on reading/writing save files, the piece artwork, and some of the custom piece sets that I've created or have in mind. Hopefully that will give me enough time to actually get a working, playable build of the program.
oooOOOooo...
ReplyDeleteNow I want to play.