Design journal
Jonathan writing...
Had lunch with Pippin... we have agreed to approach this as a "rational" hybridization experiment in which the two models to merge are Chess and Rogue (the original... or as original as possible. We should probably do some work to find an actual "original" version). The process will be to map out all the relevant design aspects of both games and for each decide from which model to draw, or whether we need to come up with an actual hybrid feature. These two sets of features should constitute a "hybridization matrix" that will in fact correspond to the design space of this hybrid. Chogue will be one possible trajectory within that space, a series of decision within a finite set of possibilities.
My current purpose is mostly to complete the framework with working chess pieces (as we've pretty much established to choose chess pieces over rogue pieces -- this decision should be documented somewhere). We still need the kings (easy) and pawns (a bit more complicated because of the special rules: move twice on first move, eat in diagonal, and queen when reaching the end).
We were also keen on keeping a single screen for the whole game world (as in Rogue and Chess). I checked the text mode standards for Rogue era computers and judging from screenshots it seems quite clear that it follows the 80x25 characters standard. In our current framework, this seems too much to fit in one screen and has a very unbalanced ratio for square cells (chess cells). Characters are not squares, they are higher than large. For now, I've settled to the other standard of 40x25 which also feels quite big. Perhaps this will change when the game world is made of smaller room interconnected with corridors (rogue-like).
Jonathan writing...
I've implemented a Level1 scene with a basic chessboard and the usual chess layout. The point was to decide on a turn-taking mechanic. The options were:
- All black pieces play once, then all white pieces play once (rogue style arguably, considering Rogue is 1 against all)
- Black plays one piece of their choice, white plays one piece of their choice (chess style)
I've implemented the chess option. This required some more AI for the computer to decide which piece to play. It looks through all pieces, sees if any can take the king, if not if any can take a piece, if not move one as close to the king as possible (could be the one closest to the king, currently, it's the first one I guess)
We can also test this scheme in the LevelGen scene which plays very differently now that black only plays one piece, and it usually looks really dumb because it doesn't play a piece close to the human king necessarily (probably to fix)
I've also enforced that same color pieces are not good to take.
I'm starting to regret the collider-based logic. It was simple to implement but bugs pop up wherein the collections of possible destinations and pieces to take are not correctly updated...
Jonathan writing...
Fixed many bugs. Seems much more robust now. Can play both the LevelGen scene and the Level1 scene (the latter being just chess). The main addition is AI refinement. Now when the AI cannot eat anything, it will select the piece that can move closest to the king. It's particularly interesting in the LevelGen scene since the pieces seem much more aware of the king now,
Pippin (finally) writing...
I'm writing in here to try to think about how the map generation stuff is going to work. I've just read the existing level generation based on noise and then cellular automata - surprisingly simple, impressively effective. And, of course, not really connected with what we're doing now - but the basic concept of creating a Texture2D with pixels set to wall/not-wall is very clear and doesn't get in the way of anything.
Based on Rogue the plan is to generate levels based on these constraints
- Implied 3x3 grid of possible rooms
- Rooms can vary in dimensions between some maximum and minimum (based around the padding needed in the grid for hallways)
- Rooms have some probability of actually being put in (that is, it's possible some grid spaces have no room in them). This is a special case that it might be better to work out after working out a consistent 3x3 rooms version.
- Rooms can be connected to adjacent rooms by hallways
- Hallways have a start and end point on the wall of a given room, it can be anywhere along the wall
- Hallways seem to follow more or less a 'shortest path' between the two points (though for 'diagonals' it's not 100% clear how it decides things, randomly?)
- Hallways don't 'jiggle' their way, when they're making up an offset between the doors they do the whole offset and then proceed straight
- There's a special case with hallways when there's an omitted room where it seems like a hallway can trace around the omitted room??? But not always? Oh Rogue, you rogue.
- Also seems like there's a special case with omitted rooms where you can have an intersection of hallways
Our map can be pretty much exactly the same as Rogue's except that we have the requirement of hallways being at least two tiles broad at all times, which changes the padding etc. but is essentially 'the same thing'?
Things for me to do:
- Generate 9 randomly sized rooms
- Choose start and end points (different colours)
- Choose connection points
- Connect the points
- Then work out special cases: omitted rooms, omitted connections
Big thing: reachability. Rogue never generates a set of rooms where there's a room you can't get to (does it? How would you know, now that I think about it?) At the very least, Rogue never generates a set of rooms where you can't get to the stairs. So there's an issue of making sure you can get from the start to the finish.
Continues...
Got the basics of random sized rooms in the 3x3 grid to render in Unity, so I at least can make the parts talk to each other. Now stuck on the problem of representing and connecting the hallways. Probably something where I need to take a break and come back to it as it doesn't seem that complex when I think about it, but the code eludes me. Getting there.
Pippin writing...
Since the last entry there has been plenty of agonising about the way to implement the Rogue algorithm, plenty of false starts and tears. Eventually Jonathan figured our a pretty good approximation and while I was trying to implement the ideas behind that I found the original Rogue algorithm still nestled in the embrace of the Wayback Machine here:
I eventually came to be able to understand how to deal with the generation of the dungeon image in all its padding, hallway-space-leaving, "gone" rooms as little corridor sections, horrible glory. At this point we have a pretty-close-to-rogue generation system with the exception that it doesn't have the ability to just not generate a room. Which, now that I think about it, isn't actually all that complex to add, so I'll do that in a second.
One major tension that arose from writing the algorithm is that it turns out that at the low resolution we were using initially, the map is kind of horribly limited in the kinds of rooms it can generate (because there's so much padding involved - a tile around a room for 'walls' and then two tiles minimum between padded rooms to provide a space for a hallway). When I created a larger image to be able to incorporate a higher-resolution dungeon, it's starting to look a little hard to read in the actual generated version in Unity. Not sure how to resolve this just yet, but it's a definite issue.
(There are some small problems like the fact I've added extra padding to the top and right of the map to make calculations easier. Should probably just trim them off somehow. Shouldn't be all that hard.)
One fun observation while generating this maps is that it's possible for hallways to be diagonally adjacent and thus traversable by a whole bunch of the pieces. That's chess for you, eh?
I'm wondering whether pieces should be childed to the current tile they're on to facilitate hiding (by enabled/disabling the tile). But that said, in Rogue itself there are are few states:
- A room you've never seen is totally invisible
- A room you're in is totally visible including enemies
- A room you've seen but are not in is visible, but you can't see its contents
(And then there's weird-ass behaviour of hallways.)
I guess tiles should always have a reference to pieces on them, and pieces should always have a reference to their current tile. Maybe they do already... I should read the code... okay well the pieces do but the tiles don't. Maybe that matters, maybe it doesn't.
Pippin again
As is my custom, I thought I'd just lay down a few thoughts here since the game has advanced a specific block at this point. This will probably be repetitive (as is also my custom!).
-
I added a few more process images to the images section of the process folder of the Unity project. Continues to kind of elude me how to use these 'properly' in conjunction with either the design writing process itself or with some imagined analysis of the game down the line. When I take the screenshots they always feel like important documentation of a moment in the process and I'm often 'proud' of what they represent, but are the obviated by the ability to call up the commit they come from anyway? What is their actual purpose? Without kind of knowing that I always feel uneasy about them. Part of the solution is probably to explicitly fold them into the journal itself. That can be done if you put them in the same folder as the wiki if you've downloaded it as a repository, so maybe that's something I should be doing explicitly.
-
Interesting to reflect on why I've been so unconvincing (for me) in terms of writing process stuff here. I definitely think I have a sense of things slipping through the gap between me and Jonathan - that he will magically handle elements of documentation, or worse that I don't bother to write something down because we've talked about it and therefore it's kind of 'already said' and not in need of recording. Which is pretty much the opposite. But it's true that it feels like double work to write down the contents of a conversation we have about something. (This is an aspect that doesn't come up when I work alone because the writing is a form of talking to myself and thus surfacing my own ideas in a conversational way.)
-
Thinking about one of the base ideas of the project being to explicitly make choices between Rogue design and Chess design again. It impacts on pretty much everything which is nice. So much so that I think in terms of the dungeon generator I could never have been happy unless our maps were a pretty damn close representation of the real Rogue maps. And, for instance, we're talking about implementing the same visibility rules of the original Rogue. I kind of like slavishly recreating the decisions of somebody else in this slightly new context, but at the same time there's a weird laziness to it? (An inconvenient laziness given how bloody long it took me to do the dungeon generation, though.) I guess I need to wait until we have something that feels more like the actual game to judge how interesting or not this process really is?
-
I'm losing the thread of the comedy again when I look at the real game, and it's interesting to me how vital that comedy feels to me in terms of maintaining an interest in the overall game. The key motivator has been laughing about the game and its possible scenarios with Jonathan, that's what has kept me going in the face of less interesting technical challenges. Looking at our aesthetics, I suspect we might need to think about some little comic inflection to the graphics or something? Right now it's so stark. (But so is chess and so is Rogue of course... so would that be breaking the rules?) Hard to say, but I definitely feel a need to reinforce the possibility of laughing at what happens rather than taking is seriously? (And I note that neither Rogue not Chess are especially funny? To me at least... so is Chess+Rogue funny? Consistently?).
-
My worst fear is that this turns into a game we try to make a proper game, weirdly. Like something with strategic depth etc. But I suppose if that's something that were to fall into our laps, that's fine?
Jonathan
Today has been about two things: initial level placement and visibility.
#Piece placement Current design commitment is that on a new level, incoming pieces (from last level) are distributed on the lower end of the starting room, looking a bit like a regular chess setup. Ready to move. This is also the Rogue way in a way, though it is trivial to speak of "placement" since there is only one player piece. Should we push forward and reproduce as much as possible the chess order of piece types?
As for the enemy pieces, they are scattered randomly in the dungeon rogue-like. There might be some balancing issues here, however I wonder how balanced Rogue actually is. It always felt terrifyingly random.
#visibility This is full rogue-like. A player piece can see everything in the room it currently is. When it exits a room, the room is still "discovered" but its content is hidden. Same for the corridors, however they are not discovered at once, like the rooms, but little by little (roughly 1 cell in advance). The difference is that this is true for many player pieces, meaning that multiple rooms (and their content) can be visible at once.
The main departure from Rogue obviously is that the pieces can move more than one tile at the time, meaning the player pieces can venture into undiscovered territory (our design trick here is that potential piece destinations are highlighted without being visible), revealing tiles as they move. this also means that invisible enemy tiles can emerge from the shadows to eat one of your pieces!
Pippin
I merged in a very simple change to the dungeon generation, but it gave me an opportunity to actually experience the game as it is now. It very suddenly feels like a real thing. Centrally, it now has sufficiently many of the rogue/chess combination decisions represented in the system that the experiential consequences are becoming visible instead of notional. There's a really interesting dynamic at play that is like neither game, which feels pretty perfect in terms of this experiment.
There's some kind of a "game feel" thing going on with the pacing perhaps. It feels like a slow game at the moment as pieces sail sedately through their moves. Playing a queen all the way across the dungeon, say, takes some pretty serious journey time. Is it too much? What would the difference be if it were a teleportation style movement, more decisive (and aggressive?). An issue with that would be that in the current lerp-style movement you get to see things revealed as the piece moves, which has a kind of elegance to it system wise? If the teleportation format, would you still reveal the interim room?
I suppose this is a question about chess moves in general. When you lift a piece from the board and place it in its new location, how is that perceived by the other pieces? (So to speak.) Do they live in a 2D world, in which case lifting and placing down a piece is a form of teleportation (much like the things that happen in Flatland). That particularly makes sense for knight moves, which otherwise have to phase through solid objects in the lerp model?
So this could be an argument for: "movement is teleportation, interim spaces are not considered explored"?
Re: meeting an enemy in the dark. This is a super harsh experience! My queen was captured by an invisible rook. In Rogue it's more acceptable to meet an opponent in the dark because they damage but don't usually kill you. In chess it's all or nothing, so you're just a goner! This is mitigated by the idea that you're a party, though. I guess it would make some sense in that way to send lower-value pieces into unknown spaces? Even if they move more awkwardly and are thus more likely to get captured in there?
At any rate, this now feels like an actual game!
Since we often talk about this game in terms of a kind of matrix of decisions where we take rules selectively from one or the other of the two games, I thought I would at least start to sketch out what those are to try that experiment on for size.
- Board/floor-plan: Rogue. Dungeon generation algorithm pretty much purely with the exception of making hallways two-tiles wide to allow for knights and bishops to pass. (Hilarious to have the single-tile-wide hallway, but not funny enough to offset the frustration.) The exception is the first level (and maybe the last?) which resembles a chess board instead.
- Floor tiles: Chess. Using the chequered tiles helps to signify Chess is in effect (as well as the pieces obviously). This is also important to make the first level look like an actual chessboard, which is a good joke and makes a huge amount of sense in the 'universe' of Chogue.
- Entities/agents/avatars. Chess. The player's pieces and the enemy pieces are all chess pieces. This is kind of the central conceit alongside the dungeon generation for the board - chess pieces find themselves in a Rogue world. This defines movement rules and of course game over situations (king captured - this reminds me that at one point we were going for checkmate instead of capture). In using Chess we're also using the idea of the player having multiple pieces. At present this is semi-arbitrary and needs a bit of thought.
- Piece selection. ?. If Chess then we would presumably start with the full set, play the first board, and then have the pieces remaining proceed through the dungeons. (A weird alternative I'm thinking of right now is that from the first move Black's pieces all flee into the dungeon? But that won't make sense and would make pawns impossible. Elegant, but a failure?) We've also discussed a more Rogue-esque (but NOT Rogue) idea of selecting a class and just having a single piece (funny, but renders the game unplayable presumably unless you restore the idea of HP and other Rogueries), or having a team you select based on some number of points (with the cost of pieces corresponding to their traditional chess valuations).
- Movement. Chess. Kind of repeating myself, but unlike in Rogue where every piece moves like a King, in Chogue pieces move according to chess rules. This leads to funny stuff like a knight jumping through walls. It also changes the value of the pieces for exploration. Comedy effect of pawns being utterly useless (question of Queening though). Ability to move into unseen areas is big - we have the classic computer-chess move-indicators that highlight all available squares (including squares in unrevealed areas, and hence all these issues around risk).
- Turn taking. Chess. White moves, black moves, white moves, etc. This means you can move the same piece on multiple turns, which allows for exploration behaviour which feels right and interesting, and actually functions as a kind of callback to Rogue. Means enemy movement isn't too overwhelming, but can lead to kind of boring scenarios where you're next to a black piece and it just sits there.
- Enemy AI. ?. Kind of a dumb-ass Chess AI? Or just a dumb AI in general. Has a set of prioritised ideas about getting the king, capturing any piece (without checking risk right now), getting toward the king (which means they ignore other pieces which is dull and should change)
- Attacking. Chess. Pieces capture in just the same way that chess pieces do.
- Visibility. Rogue. (For the moment?) We use Rogue's rules around what the player can see. Specifically, you can see a room if you're in it and it is then 'discovered' which means you can always see it. You can see the pieces/elements in a room when you're in it, but they become invisible when you leave. In hallways you can only see your current square and all adjacent squares (including diagonal) (have we implemented this?)
- Game over. Chess. You capture the enemy king or your king is captured (which is slightly non-chess since that's not something that actually happens in Chess, you get to the move before that eventuality). Need to think about that (but I guess we can say we're taking the king's movement style and significance, but not the chess rules around checkmate). This raises a couple of other possibilities not integrated: stalemate (ha ha - but only possible if we include the idea of not moving into check), and resignation (funny on the player side as a 'restart', but especially funny if the computer opponent resigned.
That will do for now. There are probably others, and there's an opportunity here to write about roads not taken.
I have not been diligent in writing what I've been doing!
Essentially I've been concerned with the elusive balance. No big design moves, but playing, trying to find out what aspects of Chogue are engaging and trying to emphasize them,
Certainly, one highlight of Chogue stems from the combination of Rogue's visibility rules and Chess' instantaneous captures. In Rogue, if you stumble upon a previously invisible snake, you might get one surprise hit but you are likely to survive it to adjust your strategy. In Chogue, if you land on a tile that was covered by an invisible enemy piece, you lose that piece straight away. This is made even scarier by the fact that that piece may arrive from quite far, being preceded by a sliding noise (you don't know yet whether it will land on your piece or not, but you fear it will) then seeing it emerge from the dark and eat your piece. As Ben Kybartas observed, Chogue turned Chess into a Survival Horror game.
This is a dramatic moment, however, it takes a lot of place. With the stupid AI, surprise attacks are the main threats in Chogue. And with Rogue's visibility rules, if you send a scout in a piece, it gets eaten, then you lose track of that thing that ate you. And you are condemned to send waves of blind scouts in the room of terror hoping one will land on an uncovered tile, revealing the enemy and allowing you to deal with it.
I felt this was a bit /too/ unfair in regards to Chess' strategic foundations. In this version, I've tried a compromise: you can still get eaten when going into a room, but the room and its contents remains visible afterwards, allowing you to plan a riposte. For now, I feel this is better. It's also less weird visually with the pieces disappearing and popping back.
As mentioned, one thing that we felt was a bit lost was the possibility for chess-like puzzles to occur: how do I cross this room while avoiding or eating these enemy pieces? The stupid AI doesn't help, but the new visibility compromise does. With it, I've increase the number of enemies (to compensate for their stupidity). There are moments where you need to think a second how to navigate the pieces or how to lure enemies in a trap. It's still quite shallow (a better AI would be needed) but it's not trivial.
When beginning to think the game on the longer term, one issue that arise was how to reconcile Chess and Rogue's very different "arcs". Chess is a game of attrition, with pieces disappearing progressively until resolution. Rogue (as all RPGs) is a story of infinite growth: you get better, stronger, find more advanced weapons... and this is kept in check by the fact that your enemies are following a similar curve. Chogue is in a weird place with the player undergoing attrition and the enemies coming back in force with each new level.
Pippin and I discussed of ways to import Rogue's leveling up on Chess pieces. We also observed that a great part of the appeal of Rogue is loot, which is absent for Chogue. Combining these ideas, I decided to implement "loot pieces" which amount to finding new equipment or potions in Rogue, but in Chess terms, your character doesn't get better, your party is. So you can now find loot pieces which join your party when you capture them.
There is also the problems of beginning and end (or absence thereof as in Rogue). Pippin and I liked the idea of beginning with a regular chess board that would represent the first level. The enemy king leaves on his first turn, entering a staircase. This serves the purpose of communicating that this is not a regular chess game, and suggests that you should also be entering that staircase if you want to find the king and checkmate him. There's something of "the princess is in another castle" to this. This is now implemented and I find is quite effective in introducing the game in a very natural way.
The issue with this is that it may be felt as tedious upon replays, once you get the joke. Also, you care about keeping as many pieces since they will be useful later. There is a shortcut, which is to play just a few moves to open a channel for your queen directly to the staircase but testers don't seem to pick up on that quickly. However, it was noted that there's something very satisfying in playing a regular game of chess with the stupid AI and beating the shit out of it.
Remains the question of the end... once again the models collide: end with checkmate or infinite levels. For now, we have chosen both at the same time. As you go deeper, there is increased probability of meeting the enemy king, if you do, you can decide to capture him (the AI is to dumb for an actual checkmate scenario) which leads to a player victory. However, as this might prove frustrating for someone on a good rogue-like run, you can also choose to ignore the king and continue moving forward in infinite levels.
Procedural generation always makes everything tricky. There are a bunch of parameters that can (and have been) tweaked but in the end it's all very arbitrary:
- Enemy placement: with every level, there are more enemies, but they also increase in piece value (rooks and queens are the masters of Chogue, they become more frequent in further levels)
- The king only begins to have chances to appear around level 6. Not sure why... the early tests pointed to 7-8 as being high score runs so it felt reasonable to aim for them. However, many things have changes and I'm not sure what's the expected good run anymore. I've managed to find and capture the king without being particularly attentive so perhaps it's too easy... but then I'm also quite the expert at Chogue by now and does the game need to be difficult? Having greatly enjoyed FTL and Into the Breach, I think it should be difficult to reach the king just to increase the excitement of seeing him.
- Loot pieces also increase, in order to give a change to players to replenish. I also find they afford interesting chess moments as it's sometimes hard to get a piece without it being immediately captured.
- I've added a status bar at the bottom, mimicking that of Rogue
- I've also added a message bar at the top, once again mimicking Rogue. This one is purely for comedy since all pieces always "score an excellent hit" on each other
- I've added "gold" to be collected. It's useless, but it's part of the dungeon crawling fun. What particularly motivated me to do this was that my status bar felt empty, adding "gold" makes it better!
- We had discussed of using chess notations to communicate captures (Ben also suggested that independantly) and with the size of our gris, this could yield absurd lines such as Ky31xBj25... I was too lazy to do this one which would require some non-trivial work.
Mostly concerned by some bugs:
- game is sometimes slow, I don't know why. (edit: I know which script is to blame and it could really increase performances... just hoping I haven't made things less stable)
- rarely, a capture fails and both pieces are one top of each other... this is really irritating as it's hard to reproduce.
- selected destination tiles is a bit tricky, you need to click on the center of something that is quite small...
Of course there are possible outstanding design issues but Chogue is a thing now!
It has been a terribly long time since I wrote something in here.
Part of the reason for that is that Jonathan and I have been doing a lot of our design and development discussion over email rather than in this journal. That's a meta thing to think about in terms of MDMA and how we imagine it working in team based projects. Even with just the two of us it has immediately felt a lot more natural to discuss ideas either in person (which remains deeply ephemeral - occasionally in the past I've taken notes, but it's rare) or over email (which at least leaves a trace and can be folded into the repo at some point).
Although we've done pretty well I think with email, it's definitely a different approach and it's not really codified in the same way that, for instance, the rigour of a journaling practice or commit messages is. This is really a bit of a blind spot for me in terms of process because team-work is quite outside my experience in development. It's good that we're carrying out the experiment and it makes me wonder how we might work out some ways to make our process as a team a little tighter in terms of process documentation.
Jonathan's been doing basically all the development work to make Chogue a real thing, but I was finally able to jump in and contribute a small thing to the code which was to have standard chess algebraic notation for the moves made as well as 'flavour text' (ala Rogue) associated with capturing moves. Nothing spectacular code-wise but it feels surprisingly good to play the game with this addition. To be clear this means seeing lines like
3. Qxbb20 (Your queen captures the bishop) Rh18
Along with other notations like check (+) and pawn promotion to a queen (=Q).
Pleasingly, we also have to invent a piece of notation because we've moved into having two versions of the project, one in which the pieces have hit-points (HP) and 'fight' by ramming each other according to their movement style (e.g. Rogue-based combat); and one in which the pieces simply capture each other (e.g. Chess-based combat). In the Rogue version, then, you need a symbol that accounts for attacking a square but not actually capturing it (as I write that I wonder whether a fully successful attack should result in you moving to that square? It doesn't in Rogue...). So we now have * to indicate "attacks" (but doesn't capture). And associated flavour texts, so:
3. Q*bb20 (Your queen swings and hits the bishop) Rh18
4. Qxbb20 (Your queen has defeated the bishop) Nc7
One outcome of having move notation in combination with the 'fog of war' from Rogue is that the notation of black's moves actually tell you some potentially valuable information about what's lurking in there. If you're able to read the board a little (e.g. know roughly which rank and file is which) a black move notation can tell you, say, that a queen is closing in on your little encampment of pieces. It definitely adds to a sense of excitement I think - a tantalising piece of information that makes the dark that much more interesting and alive.
The game is in quite a good state at this point. It has a beginning (default chess board with stairs), a middle (playing chess/rogue in dungeons) and an end ("checkmate" one way or another). A lot of the bugs have been ironed out and it's actually borderline fun to play at this point. It's ended up being strangely interesting!
I guess it's mostly polish from here? No major features needed. Perhaps a couple of smaller conceptual ideas to work through (like the idea of 'checkmate' actually). More bugs. Then... it's done? Vraiment?
I want to return to the exercise of writing down design decisions as framed by the two different games. I've already done this before, but it seems worth returning to. I'm going to avoid my habit of lengthy reflection on each element, and if I can I'll try to organise them a bit, as something I'm intrigued by with this hybridisation approach to design is the way that there can be nested design decisions that depend on earlier decisions?
-
Spatial layout = Rogue (Other than the opening chess board we use the Rogue dungeon generation algorithm.)
-
Agents = Chess (Every entity is represented as a chess piece)
-
Agent movement = Chess (Pieces move as in chess, questionable whether this is distinct, but you could just have the pieces represented with chess symbols)
-
Player avatar(s) selection = Chess (You start on a chess board and this represents your team going into the dungeon. As such you're not a single character but rather a set of characters. In a Rogue-like this would probably be achieved by having you select your team, but we opt for the much cleaner solution of a full set of chess pieces, especially as Rogue doesn't have multiple avatars, and Chogue would be impossible with a single piece for the player.)
-
AI agent(s) selection = Rogue* (The AI agents spawn randomly with increasing difficulty in the dungeons after the first board (where it has a normal chess set). * - Obviously this is an approximation of how Rogue does things, rather than a translation of the algorithm it uses to assign enemies to a dungeon.
-
-
Turns = Chess (Only one piece moves per side per turn)
-
Game over = Chess (But only sort of. There is no checkmate in Chogue, only capturing the King or having your King captured. Sprititually it's Chess.)
- Continuation = Rogue? (We added the option of ignoring capturing the King in order to go deeper, which is a Rogue-like quality, but not strictly something that can happen in Rogue itself as there is no Final Boss)
-
Quantifiable outcome = Chess and Rogue? (You can either take your win on capturing the king, equivalent to checkmate (realistically it's just 'the next move'), or you can continue down levels of the dungeon surviving, which is a Rogue form of value. But now I bother to look it up and you can win Rogue too by getting the Amulet of Yendor and returning to the surface. It starts spawning at level 26. This raises the possibility of the King of Yendor. In Rogue you have to then return to the surface. Not sure how it accounts for levels as you go upwards? I guess if it says you 'won on level 3' it means you always made it out? I'm confused. Going down a rabbit-hole of things with this... I think if you quit with the amulet you 'win' on that level? It would make sense (though might kill us) to include these element in the branched versions? Or not.)
-
Visibility = Rogue* (Rooms are visible when you've discovered them (by being in them), corridors are visible around you as you move in them. * - Agents/items remain visible even when you're not in a room. Is this one of the only examples of a real inconsistency?)
-
Items = Rogue (The idea of having collectable items comes from Rogue. We have gold pieces, which count toward a score, and we have chess pieces, which replace Rogue's potions/weapons/scrolls/etc.)
-
Promotion = Chess* (Obviously this is a chess rule, but it's important to say we actually include it in the game - pawns queen when the reach the 'end' of the board in front of them, signified by a wall. * - Pieces always promote to a Queen, whereas in Chess you choose what piece to promote to.)
-
AI = Chess??? (We didn't have a specific reference point for AI, but we could claim it's a chess-like AI at least in the sense that it understands it wants to capture your King and focuses on that objective, often to its detriment.)
-
Status UI = Rogue (We mimic Rogue's two status bars. The top reports the most recent action as in Rogue, the bottom reports the set of key statistical indicators [level, HP, pieces in team, captures, gold].)
- Action reporting = Chess (Non-combat moves made are reported in standard algebraic notation)
Branch 1: Chogue Classic
-
Combat = Chess (Pieces capture immediately and replace the attacked piece)
- Action reporting = Rogue (Capturing moves are reported in standard algebraic notation with the addition of a Rogue-style flavour message)
Branch 2: Cherry Chogue
-
Combat = Rogue (Cherry Chogue) (Pieces attack squares and can hit or miss, retreating to their own square until defeating the enemy)
-
Defeat = Chess (On defeating an enemy the piece is captured as in chess)
-
Health = Rogue (Chess doesn't have health obviously)
- Health points (HP) = Chess (Pieces have as many HP as they are worth points in chess, Queen = 9 etc.)
-
Action reporting = Rogue (Attacking and capturing moves are reported in algebraic notation with two new symbols [. = miss, * = hit] and with Rogue-style flavour messages)
-
One of the outstanding issues we've had with Chogue almost from the beginning has been the question of how it ends. Thanks to our hazy assumptions about how classic Rogue works (we figured, without checking, that it was an infinite series of procedural dungeons) we ended up deciding, without really deciding, to go with chess's endings in terms of our design through hybridisation.
That meant that we would use checkmate as the determiner of a game won or lost. Except that in the context of our dungeons and the balance of the game and most of all the AI, checkmate is pretty hard to accomplish and it's really not very satisfying. So as a kind of further hybrid decision, the game ends when you capture the enemy king or your king is captured. Not quite checkmate, but rather what checkmate implied - which is itself kind of nice, because it's almost a transgressive treat, as a chess player, to actually capture the opponent's king rather than just prove you could. It also fits well with the opening screen of the game, in which the enemy king escapes down some stairs on a regular chess board - it makes dramatic sense that the game ends when you track him down.
All was well with this 'checkmate' decision, with the enemy king appearing with increasing possibility as you go further down in the dungeons. We even implemented the idea that if you're not careful the king will escape down further sets of stairs when threatened, which was fun. However, a challenge emerged when we sent the game out to testers and heard back from one of them that they felt frustrated by capturing the king and having the game end - they wanted something more roguelike in which they could challenge themselves to go deeper!
Putting aside the mild elation that anyone wanted to play the game more at all, this was a potential issue. Chess has a very sharp endpoint and isn't designed to last for eons (long, drawn-out games notwithstanding), which is in tension with the roguelike tradition of procedural content and potential infinity. Our response was to scramble our way into a screen in which, upon capturing the enemy king, the player can decide to end there or to carry on exploring the (now kingless) dungeon. This felt like a fair approach, essentially giving players the option of choosing a chess or Rogue resolution to that key moment. It's true that it only felt like a 'good enough' decision, but it was, well, good enough.
As it turns out, though, we were being somewhat seduced into thinking about Rogue as a roguelike (apparent even in my language above). Chogue is a hybrid of chess and Rogue, two real games. It's a roguelike in that sense only, not in the broader game culture meaning of the term. Really, it's a Rogue-like, if anything. On the morning of one of our final sprint days to get "Chogue Classic" (working title) out the door, I happened to do some reading about Rogue and therefore happened to run into the fact that Rogue totally has a well-defined ending.
Rogue victory screen (image from The CRPG Addict)
In Rogue your objective is not to go ever downward, surviving infinite levels of dungeon, although it's true that each level is procedurally generated (and thus you potentially can go down infinite levels). No, your objective is to find the Amulet of Yendor and return it to the surface. The amulet spawns on level 26. So this actually gives Rogue a very well-defined structure. (If you're curious you can read a couple of people's reports of finishing Rogue here and here.)
After telling Jonathan about it, both of us shared the same immediate thought: "The King of Yendor!" Rogue's structure solved the problems we'd been having with Chogue entirely. The objective of Chogue is now to capture/vanquish the King of Yendor and then return to the "light of day" (Rogue's manual and the game itself talk endlessly about this), which will be represented by the initial chess board level. It's a very neat and tidy solution to what was one of the few elements of the game that was feeling kind of dissatisfying and not cleanly resolved. It also addresses the desire for more 'extreme'/elongated play as we've set the King of Yendor to appear at level 13 (26 was deemed too insane in our context), and getting there and back will not be easy. It's very satisfying that it comes directly out of the method of design via hybridisation we've been using all along in terms of choosing a decision from one game or the other.
Another bonus of this approach that we discovered is the reintroduction of a tiny amount of narrative. Very early in our design process we'd talked about making a very different version of a chess+Rogue game that focused on procedural storytelling, a challenge we were both interested in. Over time, obviously, Chogue became a more formal game and the narrative drained away. With the introduction of a quest structure, though, and particularly in the form of the King of Yendor the narrative element is back in a pleasingly understated way.
Simply finding the in the game king is a thrill, but noticing that when he attacks or is attacked the flavour text says something like "The King of Yendor captured your pawn" is surprisingly powerful. Every other piece is referred to only by its type, only the King of Yendor is named in this way, and it implies a potentially epic backstory that the player can, if they wish, fill in for themselves. The disjunction between that kind of narrative and chess is especially fun. Along with this, the game now has an ending with a narrative resolution, the player having gone on their long journey to slay the King of Yendor and then return home to be celebrated. It means something, you know?
So in the end, by staying true to the design process we set for ourselves of choosing decisions from either chess or Rogue, and remembering that we're talking about Rogue and not a roguelike, we've ended up with a kind of perfect shape for the game that will hopefully satisfy its players as much as it satisfies us. It feels good to follow a semi-formal process like this and see that the result of that commitment is a really coherent piece of work.
Long live the King of Yendor!