Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
March 21, 2019
arrowPress Releases







If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 

Breaking Chess, but just enough

by Yanko Oliveira on 03/30/16 07:54:00 pm   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

Part one of the “X: a Game of YZ” Postmortem.

I’ve never got to a point where I felt like pouring hours into studying a game to become good at it. And no doubt it takes a certain type of analytical mind to truly excel at chess, but most of that (as with everything) is hard work and knowing the intricacies between possible strategies. This means luck won’t play a part into it and a rookie will never beat someone with experience.

But what if we changed that? What if we removed experience and years of study from the equation? How much would that level the play field? What if every chess game was different and you had to learn it on the fly? This was the base for “X, a game of YZ”, which was created for the 2015 ProcJam and you can play on my itch.io. 

It’s been a while since the ProcJam and I have terrible memory, so bear with me. But as far as I remember, the idea came to me because of some Windom Earle comment in a Twin Peaks episode when he realizes that the good guys were using Pete’s chess abilities to stall the game. If you have no idea what I’m talking about, go watch Twin Peaks, it’s awesome!

As I mentioned, I never really put time into studying chess, aside from the every now and then chess match with my dad when I was a kid - I played Battle Chess just to watch the cool animations. So it shouldn’t come as a surprise that I wasn’t aware that Fairy Chess was a thing, which I just found out after a quick chat with Jefferson from BitCake Studio (who by the way just released Holodrive on Steam, go check it out!), after the prototype was about 1/3 done. However, it was a good pointer to indicate that, since other people have screwed up chess, I could too!

But not being an actual chess connoisseur, how could I expect to design a decent procedural chess game in less than a week, only using after work hours? Most of the design was already set in stone anyway - it’s broken chess, but still chess. However, the driving force behind the design was the primordial question: how possible is it for an unexperienced player to beat an experienced one if the move and piece sets were different? How different does the approach need to be if you have to learn the rules on the fly? My conclusion was that creating a sandbox to try and answer those questions would be enough.

Since this was a game jam, there wouldn’t be that much time to break the rules, since I still wanted this to still be minimally enjoyable to play - therefore, building a new rationale from the ground up would require a lot of iteration time, which I didn’t have. This left me the option of trying to dissect basic elements regarding pieces, movement and positioning. 

So from the basics, we have

  • A board: a board with checker pattern, 8x8. The game actually supports NxM grids because I wanted variable sizes as well, but I ultimately decided not to follow that direction because I wouldn’t have time to playtest it.
  • Movements: all movements have a “can move backwards” flag. If this flag is off, the piece can only move in the direction of the opposite player, until it reaches the very last line (then it can also walk backwards). By default, pieces have a minimum and maximum range, with a chance to be able to move any distance. There’s also a chance of being able to ignore blocked squares and “jump over” pieces.
    As in chess, the possible move types are:
    • Vertical: only move forward and backwards
    • Cross: only move in straight lines
    • Diagonal: only move in “X"s
    • Omnidirectional: can move in any of the 8 directions
    • Special: has a movement pattern that depends on the piece’s position
  • Pieces: I organized the pieces into archetypes. They are inspired by the pieces in chess, both in form and function. I ended up with
    • Pawn: weakest piece, doesn’t walk very far. Serves as cannon fodder and to block the path of other pieces.
    • Support: pieces you use to make plays and back up other pieces. These come from Bishops or Knights.
    • Heavy: they are basically support pieces with a bigger chance to have unlimited move distance. Inspired by the Rooks.
    • Royalty: these have a greater chance of having omnidirectional movement, and a greater chance of being a King piece.
  • Kings: the king is selected randomly from the generated pieces, and each archetype has a different chance of being the King piece. But since this is about breaking chess, why not have multiple kings? This also comes in handy when you can end up having your most mobile piece as the King, so having multiple means you can go Kamikaze with one of them.
  • Capturing: it’s pretty much the same, except pieces that jump over other pieces can opt not to capture them. I also didn’t have time to figure out how alternate capture movements (eg: the way pawns capture diagonally) could be randomized without making everything way more complex for the player.
  • Positioning: I kept the 2 line structure, with pawns in the front and more important pieces in the back. However, there’s a chance for any piece to be anywhere.

Sheesh, that’s a lot. So how exactly do we assemble the piece set for a given match? Let’s look at the code, because I don’t remember anymore.

Uhh, yeah, I’ll just describe it (it’s jam code, don’t judge).

  1. Decide how many different pieces we’ll have
  2. Until we have enough pieces, do:
    1. Select a piece archetype
    2. Select the movement type
    3. Figure out if it can jump over other pieces and if it can go backwards
    4. If there are no kings yet, roll if this is a King. If it is, flag it as the king. If there are already kings, check the chance of having multiple kings and make this a king as well if fate so chooses.
    5. Get the random name for this piece
    6. If this is a pawn, flag it as the pawn
  3. After generating all piece types, we position the pieces, based on if they are pawns or not.
  4. If we have no king, mark the first Royal piece as a king. If there’s no Royal piece, try Heavy pieces. If not, a Support piece. In the freak case of not having any of those, we run another method that falls back to a King creation (which is basically the same as before, but forcing the "Is King” flag to true). Then position the newly created king in a random position.

The positions for the pieces are mirrored on opposing teams, as it would be expected. But everything else is pretty random, and we have to teach the players how to play on the fly. That is, admittedly, one of the worst “what went wrongs” in the game, partially because I didn’t put that much time into it, partially because it’s super hard to do that properly without the need for a tutorial at every match start. 

In the end, I opted to simply show the possible positions a piece can occupy when you hover over it, including the opponent’s pieces. Also, there’s a sidebar with all the informations about the piece. To help condense the information a bit, we use the cheesy compound name trick: all movement patterns have a keyword assigned to them. This means the player can quickly glance at a piece’s name and realize how it should move. Does that work? I have no idea, but it seems that people can make sense out of it, which is the least we need to do!

If every piece has so much information assigned to it, the least we could do is giving them different visuals. In the next post when I’ll explain how I went from an accidental bong generator to beautifully crafted mahogany chess pieces. Stay tuned!


Reblogged from my personal blog. You can read the original post here.


Related Jobs

FoxNExt Games
FoxNExt Games — San Jose, California, United States
[03.20.19]

Producer
Heart Machine
Heart Machine — Culver City, California, United States
[03.19.19]

Systems Programmer
Heart Machine
Heart Machine — Culver City, California, United States
[03.19.19]

Quality Assurance Lead
Insomniac Games
Insomniac Games — Durham, North Carolina, United States
[03.19.19]

Designer





Loading Comments

loader image