Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
November 18, 2018
arrowPress Releases
  • Editor-In-Chief:
    Kris Graft
  • Editor:
    Alex Wawro
  • Contributors:
    Chris Kerr
    Alissa McAloon
    Emma Kidwell
    Bryant Francis
    Katherine Cross
  • Advertising:
    Libby Kruse






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


 

Chess + Rogue = Chogue: Some notes on hybrid game design

by Pippin Barr on 06/12/18 12:38:00 pm   Featured Blogs

2 comments Share on Twitter    RSS

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.

 

Despite the fact that Jonathan and I have been working on it for very, very long and slow time, I see that I’ve never actually written anything publicly about Chogue. And so, allow me to explain.

I’ve already forgotten the proper origin story for this game, but I do know that Rilla came up with the name. It’s a portmanteau of ‘chess’ and ‘rogue’ and, like any good portmanteau, explains the essence of the game. Chogue is a hybridisation of chess and classic Rogue.

From zero to Chogue in way, way more than 60 seconds

A key inspirational starting point for the work was (as it was for our game Game Studies) the old “wouldn’t it be funny if…?” approach to game design. In this case we had a vision of chess pieces navigating a Rogue-like dungeon and the oddities that might ensue from that. A knight, for example, could jump through walls into rooms; a bishop wouldn’t be able to go down a one-tile-wide corridor; and so on, hilarity ensues.

We actually took the project seriously enough to do some paper prototyping in a café with honest to god chess pieces and grid paper. I felt like a real game designer as we played rounds of the basic mechanics (chess on a dungeon-shaped board), thought about the simplest opponent AI we could get away with, and tuned the difficulty level as the player went down successive levels. Ah, the summer of 2017. Then the fall semester hit, then the winter semester. And now… ah, the summer of 2018.


Image: Chogue paper-prototyping

Fortunately, Jonathan built up a head of steam with the project and has managed to actually implement the vast majority of the game on his own, with me jumping in for tiny bits and pieces (dungeon generation, chess notation), but mostly serving as a play-tester and co-designer. Over time the game has gone from our paper prototype to an actual Unity Thing that you can play (well, that we can play - you can’t as yet) and many design decisions have been made along the way.

Hybridisation as game design

The core research direction that Chogue represents for us (outside of it being funny and entertaining to make, we’re both professors at a university so there’s always that ulterior motive) is about the idea of hybridisation of games. If we think of both chess and Rogue as sets of design decisions (or sets of mechanics if you prefer), then what happens if you create a game that takes some of the decisions from chess and some of the decisions from Rogue?

Thus, for example, Chogue uses the Rogue dungeon layout algorithm (literally) but represents it with chess checkered squares. Chogue uses the chess movement rules for pieces, but the Rogue visibility rules for unvisited rooms and corridors. Chogue uses the ‘flavour’ messages from Rogue (“You have defeated the kobold”), but the algebraic notation of chess (“23. Re20 Qxe20 (The queen has defeated your rook)”).


Image: Chogue dungeon layout

And so on. Each moment of design requires us to ask the question of whether we’re going to make (or, really, take) our decision based on chess or Rogue. It’s a process very related to the translation-based design approach I’ve written about in the past, breaking a design into atomic pieces and thinking hard about them as you might about the words of a sentence, or the sentences on a page. Of course, Chogue is more like blending two books into one. Hilarity ensues?

Venturing off into design space

The hybridisation approach, choosing design decisions from two different games, naturally means that we’re exploring a specific space of design. At any moment we could, in theory, choose a decision from either chess or Rogue (unless of course it’s a mechanic/design concept that exists purely in one of the games). As such, our decisions trace a path through this design space, and not the only path. All around us are branches not taken.

Except that we did decide to take one of those branches, exactly as a way to express this idea of the space of design. As such, there are actually two Chogues in our repository.

In one ChogueChogue Classic if you like, we’ve adopted the attacking/capturing rules of chess. So as you move your (chess) pieces around in the dungeon environment, when you move your piece onto an enemy piece, you remove it from the board, capturing it. So it goes with chess: death is swift, and there’s no power differential at the moment of capture between a pawn and a queen. A wonderful and disturbing consequence of the chess capture rules is the experience of making a move and then seeing with horror a black piece come sliding out of a dark, unexplored area, to capture your piece. Thus, the chess capturing rules combine with Rogue’s hidden information rules to yield a kind of survival horror experience. It’s great!


Image: Chogue's "fog of war"

In the other Chogue, let’s call it Cherry Chogue, we’ve adopted the attacking rules of Rogue. As such, pieces have hit-points (HP), and when you make what would be a ‘capture’ in chess, your piece moves through the intervening space, hits the opposing piece, dealing some amount of damage, and then retreats to its original square (unless it defeats/kills the opposing piece, in which case it replaces it as with a chess capture). This is “just” the other side of the hybridisation coin - it’s the Roguerule for attacking rather than the chess rule, but it’s a radically different game. Importantly, in Rogue (and so in Chogue) you can miss when you attack, leading to comedy gold like a queen missing a pawn when attacking it. Further, it opens up a different relationship to space - knowing your queen is very unlikely to die in a single attack, you can explore with her more freely, perhaps even ignoring the enemy pieces chipping away at your HP in favour of revealing more and more of the dungeon as a scout. There’s more, but you get the idea.

Oh god, design space might be fractal or recursive or something

One thing that comes up with our approach is that decisions beget decisions, of course. It’s not the case that you can always cleanly take a rule from one game, apply it to Chogue and you’re done, often there are further implications and decisions to make.

In what I have facetiously (and now a little regretfully) called Cherry Chogue above, the fact of using Rogue attacks results in a question. How many HP should a piece have? And again, recursively, you can answer this question with either game. In Rogue the avatar starts with 12 HP, so you could say that every player piece just has 12 HP, as each is an avatar of the player. Or you could possibly say that you divide the 12 HP evenly among the player’s pieces, since they are collectively the player’s avatar. Then you’d have to make some related and consistent decision for the opposing pieces’ HP, which could be different, given that Rogue’s enemies have different levels of robustness.

Or, as we did, you could answer the HP question with chess. In chess, each piece has a defined ‘value’ that are used to help make a basic calculation of the strength of a given position. The queen is worth nine, a rook five, a bishop three, and so on. It feels elegant, then, to say that a piece has as many HP as its associated chess value. This even works well in the case of the king, which is kind of ‘worthless’ in chess (you don’t count it), and thus in Cherry Chogue has minimal HP, despite being the ‘most important piece’.


Image: Chogue's Rogue-style attacking rules

An interesting/risky/stupid aspect of these mode of conceptual design decision-making in the context of an actual game-y game like Chogue (it’s not a conceptual art piece, it’s a game) is that you naturally eliminate certain design affordances for balancing. We can’t really adjust the HP of the different pieces to make them more or less powerful, nor can we really alter their movement rules for the same reason - chess dictates those things. As such, you can of course paint yourself into a corner, but it’s at least a very conceptually consistently painted corner.

Coming soon?

We are long way through the development of Chogue (and by we I mean Jonathan), so I can imagine we’ll release it pretty soon (Classic Chogue to begin with) and you can see how all of these decisions and hybridisations feel for yourself.

After all, it’s one thing to just read about it, and quite another to try to become a Grandmaster of Chogue. (Oh no, we should include a ratings system with that kind of nomenclature, oh no, design is everywhere, even in the jokes!)


Related Jobs

Monomi Park
Monomi Park — San Mateo, California, United States
[11.16.18]

Senior Game Engineer
Cold Iron Studios
Cold Iron Studios — San Jose, California, United States
[11.15.18]

Console Gameplay Engineer
Cold Iron Studios
Cold Iron Studios — San Jose, California, United States
[11.15.18]

Infrastructure Engineer
Cold Iron Studios
Cold Iron Studios — San Jose, California, United States
[11.15.18]

Site Reliability Engineer





Loading Comments

loader image