Over on John C. Wright's blog, he posts the rules for an alternate version of chess: http://www.scifiwright.com/2014/03/baroque/.
What do you think? Something to add to CPM2DoB? I like the incorporation of different ways to capture an enemy piece, either replacing, jumping, squeezing, withdrawing from, or all of the above. I could easily see incorporating some of these as moves.
Showing posts with label CPM2DoB. Show all posts
Showing posts with label CPM2DoB. Show all posts
Tuesday, March 4, 2014
Monday, April 29, 2013
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:
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.
Saturday, April 6, 2013
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!)
NYI: Auras.
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. |
Wednesday, March 6, 2013
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:
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:
Saturday, March 2, 2013
Quick Takes (3/1/2013)
Greetings from the couch!
Apparently, telling your wife that you don't believe in this whole "period" thing, and that she's just making it up, doesn't get you any brownie points.
#
The Murloc wants to move to Mission Viejo. I want to move to Lake Elsinore. The Murloc has pointed out that Lake Elsinore is far from everything and everyone important (sorry, Blue Fox). This got me thinking:
Median sales price for Mission Viejo (Nov-12 to Jan-13):
$480,000
Median sales price for Lake Elsinore (Nov-12 to Jan-13):
$214,775
Price of a Cessna Skycatcher ≈ $145,000
The choice, it seems, is clear.
#
Apparently, telling your wife that you don't believe in this whole "period" thing, and that she's just making it up, doesn't get you any brownie points.
#
The Murloc wants to move to Mission Viejo. I want to move to Lake Elsinore. The Murloc has pointed out that Lake Elsinore is far from everything and everyone important (sorry, Blue Fox). This got me thinking:
Median sales price for Mission Viejo (Nov-12 to Jan-13):
$480,000
Median sales price for Lake Elsinore (Nov-12 to Jan-13):
$214,775
Price of a Cessna Skycatcher ≈ $145,000
The choice, it seems, is clear.
#
Damien has reached the phase where he is now pretending to be things that he is not. He has previously pretended to exist in other states (such as pretending to be asleep, particularly when we're yelling at him, as if he can't get in trouble if we think he's asleep), but now he is pretending to be other creatures. After showing him the Simon's Cat videos on YouTube, he pretended for the rest of the evening to be a cat, and crawled around and meowed. He plays the act very well, since he will refuse to talk when he's a cat, and only nod or shake his head in answer to questions. After we put him to bed that evening, we would occasionally hear little mews from the bedroom. Just the other night, we gave him a piece of cheese, and while eating it he declared that he was a mouse, and began squeaking.
I'm sure child psychologists would talk about this being an important development milestone and indicates some form of cognitive step towards abstraction and the ability to reason. However, like a physicist explaining the colors of a sunset in terms of the light refraction caused by the interaction of different wavelengths of the electromagnetic spectrum with atmospheric dust, they would simultaneously be entirely correct and entirely missing the point.
You simply can't explain joy through science.
#
Speaking of Simon's Cat, you can watch all the films here. They're short and cute:
#
Colloquialism of the day/week/month: "As satisfying as bacon on a Saturday morning during Lent."
#
Right now:
The Murloc is sewing a dress for a new friend's little girl's birthday. She likes to listen to her Aerosmith station on Pandora whenever she is sewing. It makes me feel like I'm back in college, rooming with Whale Biologist Tom Adams. Perhaps I should ask her to buy me a coke, for old times' sake.
Let's hope AJN and ECN don't get word of this cute little pink dress with pearls and lace, or The Murloc might have to start a home business!
#
Right now:
The Murloc is sewing a dress for a new friend's little girl's birthday. She likes to listen to her Aerosmith station on Pandora whenever she is sewing. It makes me feel like I'm back in college, rooming with Whale Biologist Tom Adams. Perhaps I should ask her to buy me a coke, for old times' sake.
Let's hope AJN and ECN don't get word of this cute little pink dress with pearls and lace, or The Murloc might have to start a home business!
#
A spoiler/preview of CPM2DoB:
Wednesday, February 27, 2013
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:
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! |
Wednesday, February 20, 2013
Lenten Loopholes
The solution was so obvious. It's been staring me in the face for so long. I can't believe I didn't think of it sooner.
As is widely know, my Usual Lenten Prohibitions include video games. Alas and alack. I've long realized that I need to substantially cut back on vidjimagame time, so for extra penance this year, I haven't played any computer games since the start of Septuagesima tide, and won't even allow myself chess or crossword puzzles on my phone, nor Angry Birds on the tablet (not even during boring homilies at Mass! I know, penitential, right?). Hopefully, this will stick after Lent and lead to more meaningful use of my time, and not just The Biggest Video Game Binge in History come Easter.
But anyways, this leaves me with the problem of, y'know, not being able to play video games. What am I to do with all this time that I should be using doing something else?
Then it struck me.
As is widely know, my Usual Lenten Prohibitions include video games. Alas and alack. I've long realized that I need to substantially cut back on vidjimagame time, so for extra penance this year, I haven't played any computer games since the start of Septuagesima tide, and won't even allow myself chess or crossword puzzles on my phone, nor Angry Birds on the tablet (not even during boring homilies at Mass! I know, penitential, right?). Hopefully, this will stick after Lent and lead to more meaningful use of my time, and not just The Biggest Video Game Binge in History come Easter.
But anyways, this leaves me with the problem of, y'know, not being able to play video games. What am I to do with all this time that I should be using doing something else?
Then it struck me.
What I give up for Lent every year:
- Playing video games.
What I do not give up, nor have ever given up, for Lent:
- Debugging video games.
So the solution, then, is obvious. Either a), get a job as a video game tester, or b) write my own video games, then debug them. Then, so long as the play can be justified as falling under the general category of "testing", it's all cool, right?
Subscribe to:
Posts (Atom)