Plot, Story, and the Game Itself

First off, here are some two-part sigils. The coats of arms are now all but finished, and just one more day is needed before I’ll be done with them and moving on to generating ruling families and civilization histories. There’s about a dozen potential components to these sigils and, as with all the others, any given symbol cannot be repeated more than once in the same world gen.


But now onto the crux of this entry. Recently I’ve had a few questions about the long-term plot and direction of Ultima Ratio Regum. Many have noticed – rightly – that 99% of what has been implemented in the game so far is best termed as world-building. Ziggurats are the only “gameplay” that has yet been developed, but they are obviously in their very early stages and lacking a large number of features. A few people have asked – what is the plot of the game? What will the gameplay actually look like? What kind of structure will the game possess in terms of advancement, leveling, and so forth? I’m therefore going to answer some of those questions. Some of them, however, I’ll be keeping secret, and some will be partial answers, since a large part of the game is going to be around uncovering what exactly there is in the game, how to decipher languages, gain access to new areas, find artifacts, and so forth. This entry is therefore going to let you know a bit about the structure, and some hints towards what some of the areas are, and what the overall “arc” of the story and the game are.

The game will consist of nine central dungeons, located in broadly random positions around the world map. Three of them will be “easy”, three reasonably tricky, and three very, very challenging. As long-time readers of this blog will know, Ultima Ratio Regum is not just intended to be a game which is difficult in a game-mechanics sense like other roguelikes – which require you to understand the game’s systems, think tactically about your choices, and balance large numbers of different factors – but also a game that will require the player to think hard about puzzles, riddles, cryptographic languages, and a number of other delicious secrets I’m not going to share yet. Although permadeath, each game is likely to last longer than a game of traditional dungeon-crawling roguelikes, and a significant portion of the game is coming to understand the world intellectually, not just learning how to defeat it mechanically. Much of the world building is important in this regard – noble family mottos might contain clues, for example, whilst city districts might harbour cults that can help you with particular dungeons or distant cities might contain trade routes that help you easily move between them.

The game plan roughly divides into four blocks as shown below. The first block which we’re a good 50%+ through now is the world-building block. This block is coming first because as I’ve developed the game it has become clear it needs to be done in this order. How can NPCs spawn in dungeons without a civ for them to belong to? How can there be any use to money and loot if there’s nobody to trade with? How can you survive for any length of time without people to buy healing items from? Not to mention the fact that a number of the plot details of the world need there to be civilizations in existence that can be affected by your actions in the nine central dungeons. Something I’m going to be announcing later in the year (think around May/June time) once I’ve finished my doctorate might mean Block 1 might be finished in the space of just a year rather than at the current pace (part-timing is tricky), but Block 1 is going to be the priority until the main five points highlighted below are finished. Once “the world” is in place, I’ll then be moving onto Block 2, containing the three easiest dungeons, and also the end-game dungeon. The game will therefore be winnable upon the completion of Block 2. Blocks 3 and 4 are for those of us who like going after our 15 Runes in DCSS, the toughest endings in ADOM and the conducts in Nethack.

Block 1: World-Building

– Town/Village/City Building Interiors
– NPCs, Schedules, Occupations, Conversations.
– Trade, Markets, Shops, Coinage, Mountain/Sea Travel
– Weapons, Armour, Shields, Ammunition, etc
– Combat mechanics, Move Sets, Skills, Stamina.

Block 2: The Early Game

– Dungeon 1, Ziggurats (three small structures, tropics, traps, riddle puzzles)
– Dungeon 2, (one large structure)
– Dungeon 3, Saal’s Cage (one large location)
– End-Game Dungeon

Block 3: The Mid Game

– Dungeon 4, (three small structures)
– Dungeon 5, The Garden of Forking Paths, (one large location)
– Dungeon 6, (one large structure)

Block 4: The End Game

– Dungeon 7, (three small structures)
– Dungeon 8, The Cog of the World (one large location)
– Dungeon 9, (one large structure)

As above, the model of the game is going to be akin to that of Dungeon Crawl Stone Soup (I do know what all nine areas are going to be, I just don’t want to reveal/name them all yet). Once you complete any three dungeons, of which naturally the three early-game dungeons are the easiest, you will gain access to the end-game dungeon (akin to the Realm of Zot). You can complete the game there… or keep playing, for the end-game dungeon will serve a purpose that is not just “the final dungeon”, but rather the actions you take there will affect the outside world as well and potentially aid your quest to complete all nine areas. Once you unlock the end-game dungeon, which will happen upon clearing three dungeons, you can close out the game or continue playing to try and seek out a higher-scoring victory. I haven’t even begun to think about the scoring system yet, but it will be very clear how many of the nine dungeons have been cleared when a player completes the game.

I’m also going to say a little about the story. The three primary inspirations for the story are Neal Stephenson, Umberto Eco and most importantly Jorge Borges. The core of the game’s story is basically an exploration of reality – to what extent is reality fixed, and to what extent is it contingent on our beliefs? Is there an external reality or is the universe just what we all “agree” it is? This is particularly relevant when considering Borges’ short story Tlön, Uqbar, Orbis Tertius which is a key inspiration for the game. In the tale a kind of “conspiracy” of intellectuals seek to change what we hold reality to be by imagining a new world that is roughly contiguous with the existing one but with many distinct differences, and that by replacing all records of this world with records of that currently “fictional” world, that world will “become” this – the consensus will be that this new world is the real world, for there will no longer be any records to suggest otherwise, and that therefore ideas and beliefs determine the reality we perceive. I think this is a fascinating idea (and this is partly the academic in me speaking now) and will be reflected within the game. I’ll be saying more about this later – but not much, as I believe in the Dark Souls school of minimalist overt storytelling – and once the early-game dungeons become fully implemented this will become clearer, but this concept will not just be part of the story but also have an important gameplay aspect later on. So that’s all the plot/game future information for now! Next week I’ll be rounding up the concluding parts of sigils, and then working on families and histories – see you all then.

Procedural Riddle Generation II

Where we left off last time we had a series of clue planned. For a 2×2 puzzle, for example, the first clue might need to be “Top-Left is west of Top-Right and north of Bottom-Left”, and the second is “Bottom Right is next to Bottom-Left”. To do this, the game then finds a synonym for each clue component, all of which have a variety of synonyms. For example, a lizard can be referred to as a “reptile”, “sticky footed one”, “cold blooded one”, “scaly one”, “one who regrows tails” or “tree climbing reptile”, whilst a skull may be a “dead one”, “cranium”, “one of bone”, “memento mori”, “reminder of mortality” or “deathly visage”. One is chosen at random each time a particular block is in a puzzle, with plurals added appropriately.

An earlier release had a number of different ambiguous clues. One was “the reptile” – this could be a snake or a lizard. If only one of the blocks had generated that would be fine, but there was always the risk that both would generate and therefore the solution would be ambiguous until you’d tested both, at which point the player would know from that point on which was correct and which was false. A few people actually suggested to me that ambiguity of this sort was acceptable – the player needs to figure out the identities of vague clues – but this is a very bad idea. It fails to meet the three design goals I mentioned in the first part of this series, and given that some puzzles will be associated with traps in the coming version 0.4, I cannot allow any trial-and-error where’s something to stake.

It reminds me of the idea of “Guess what the teacher’s thinking”. Imagine a teacher says “Name a classical composer”. You say “Beethoven”, and the teacher says “Wrong! The answer was Mozart”. You did answer the question, but the question wasn’t worded well enough to make clear to you the range (or narrowness) of the expected responses. It question implied there were many possible answers, but since there was actually only one, a less stupid question would have been “Name a classical composer born in 1756”. This would be the same issue – the “lizard” clue could mean either, but only one will be accepted by the game. Another example of this was the “shadowed moon”. This was meant to be the eclipse, but it could be interpreted as being eclipse, crescent, half or even gibbous moon. Much too unclear. Another clue that I never realized was vague came to my attention in a very unusual way which I think says something interesting about the different ways people “read” games.


This is a young boar (this is also the only blog entry which will have such endearing pictures). It has stripes. One of the clues for a boar was something like “the one with the young stripes”. I realized most people might not instantly know this, but with a little bit of research, or a process of elimination, should have made this clear. However, consider the three variations of the boar block – two of them have things akin to “stripes”.


One player suggested they found the clue confusing because one of the boar designs didn’t have stripes, and this made them wonder if the variations of image on blocks had some impact on the clues. Nothing like this even remotely occurred to me before release, but it made me realize (not for the first time) that others will “read” a game differently to you, especially if you’re the designer and have been staring at the game for a long time. I therefore removed this clue because it raised a little confusion about the relationship between the clue and the particular variation of the block.

Similarly, for those who follow the blog you may know of the endless confusion and debate over how to work one particular clue. “West of” is fairly self-explanatory, but there are a large number of clues that state one block is “opposite” another. This is meant to refer to a block that is orthogonal and as-close-as-possible to another block. For example, if you have a 2×2 clue, then the bottom-right could be “opposite” the bottom-left or top-right, but not the top-left. The lower-level clues were designed to build up an understanding of what exactly this term means that could then be applied to the higher-level challenges. This went through a number of different iterations. I tried “next to”, but that meant that if there was a gap between two pressure pads – even if orthogonally adjacent – some players were confused about whether this classed as “next to”. I also tried “adjacent to” but some players thought this meant only left-right, not up-down. “Touching” was equally unclear, whilst “proximate to” was vague and could include diagonals, conceivably. I don’t know if “opposite” is ideal, but it’s certainly less ambiguous than a bunch of the other options – it implies there are no other blocks in between A and B, and that it can be vertical as well as horizontal. This was another example where both my “reading” of the game differed from that of others (I thought “next to” was fine, at first), and that clues need to remain cryptic, “in character”, without being unclear. Of course, every clue could say “A is either left, right, up or down from B, without a block in the middle, and potentially with a blank tile in the middle”… but somehow that just doesn’t have the same ring to it.

Procedural Riddle Generation I

I’m now starting a little retrospective series on the last release. My approximate plan is to this week start with puzzle/riddle generation (part 1), finish it off with part 2 next week, then move onto a post about generating ziggurat interiors. We’ll probably then have an entry about designing the extra languages – aesthetically, not in terms of code – and at some point later, when languages are fully implemented, I’ll be talking about them.

So, this first entry will detail the design goals of the puzzles and the process of creating the puzzle solutions, checking the solution will be valid and assigning clues to them; next week’s entry will conclude this two-part series by covering how clues are generated and written by the game, and how to ensure clues are clear, even if they are cryptic (two apparently contradictory goals).


I had three objectives when beginning the process. These will also be applicable for future forms of puzzle too.

Firstly, all puzzles should be solvable on the first try. There must be no trial and error. Some puzzles may, later, come with traps of varying severity and lethality (traps will likely be integrated into puzzles for 0.4); they must be avoidable with perfect play. This is not to say they might not take a long time to solve, but you should always be able to submit the correct answer first time. If there is any ambiguity, there need to be more clues, or the puzzle needs reworking. Given the clues, puzzles can be cryptic, but they must never be ambiguous.

Secondly, the puzzle must have only one solution. This is not just because having multiple solutions makes a puzzle easier, but also because getting the software to recognize all solutions that meet the clue requirements on the fly, rather than upon the generation of the puzzle, was a far more challenging task.

Thirdly, all puzzles must use the smallest number of clues possible. That is to say that if the game provides you with four clues, but one is superfluous, it should be able to remove that clue and keep paring down clues until you have the bare minimum required. This once again increases difficulty, but also reduces the amount of data (potentially duplicated data) the player needs to process.

There are three stages to the puzzle, of which the second stage is the major focus. The first stage is deciphering the riddle – for example, understanding that “the creature of poison arrows sits north of the many-legged one” means “a frog is north of a spider”, which we’ll talk about next time because those phrases are generated quite late in the process. The second stage is working out the placement of all the different blocks based on the clues you’ve been given (which, as above, should be only just sufficient to solve the puzzle with), and the third stage (the most minor) involves maneuvering the blocks into position. The third is just a minor Sokoban puzzle in some situations, so let’s skip over that one.

The first stage in generating a puzzle is to determine how difficult a puzzle should be placed. There are two sizes of ziggurat, “medium” and “large”. I originally intended to have “small” ones as well, but I found them a little too small to really feel like a full dungeon (using “dungeon” in the broadest sense); whilst that feeling would decrease in future versions once I add more room types, for the time being we’re just going for medium and large. A medium ziggurat has four floors and a large has five. There are five different “levels” of puzzle, 1-5, of which level 5 are considered “boss” puzzles and can only be placed on the penultimate floor (so the third floor in a medium, or fourth floor in a large). The final floor always houses either a clue, or a secret item – in later versions there will be far more variety and these peaks will include treasure, loot, weaponry, various other items, and potentially “boss” level NPCs who have also made their way into that same ziggurat. For now, however, three ziggurats contain secrets, whilst the others contain clues directing the player towards those with secrets.

The floor the puzzle is being generated on determines the level of puzzle; harder puzzles appear on higher floors. It is weighted to give you a logical progression of puzzle difficulty in each ziggurat, but also to allow for unusually difficult puzzles to rarely appear on each floor (similar to “out of depth monsters” in Dungeon Crawl). I will focus on the placement in the later entry of ziggurat dungeons, but the game basically draws a route from door -> stairs or stairs -> stairs and places rooms of appropriate difficulty along that route. Some ziggurats will have a tougher combination of puzzles, some easier, but given that I’m making a procedurally generated game I certainly don’t mind a little variation, and once other factors are in play – such as traps in 0.4! – difficulty should equal itself out more easier than with just a single challenge from the puzzle rooms.

The next stage is to pick a puzzle. There are several for each level. For example, Level 1 puzzles can be 2×1, 3×1, or 4×2. Level 2 can be 2×2 or a “cross” (like the five dots on a die rotated 45 degrees). At the higher end, the Level 5 boss puzzles can be 12×1, 3×3, 5×2 or a “star” (3×3 with the middle removed but an extra pressure pad on each edge), as shown below:

BpssroomsOnce it has chosen a puzzle shape, it then selects correct blocks at random from a series of all blocks. So, if we have a 2×2 puzzle, it might select a Full Moon, a Snake, a Spider and a Winter Tree. Full Moon might be classed as block a, Snake as b, Spider as c and Winter Tree as d (the puzzle being ab on the top level, then cd below, to form the 2×2 square). The game then picks from a variety of what I’ve been called “clue orientations”. For 2×2, for instance, it may pick a particular corner then give two definite orientations next to it. So, if it picks the top-left corner, it would generate a clue (details next week) that says the top-left is on the east of the top-right and north of the bottom-left. It would then know that the second clue needs to relate the bottom-right tile, but because the earlier two clues are directional, this final clue doesn’t need to be.

In any case where a non-directional clue can be used, the game prefers to do that because it’s automatically more difficult. Saying “X is west of Y” is simpler than “X is opposite Y” and having to figure out whether that is north, south, east or west according to the rest of the clue. However – and 0.3.1b fixed a few issues like this – it soon became clear you simply had to have some directional clues. For example, the 3×3 grid is symmetrical in all four orientations, to simply saying “opposite” for all clues would mean the clue could be solved in four orientations. I felt this both made the puzzles easier, and possibly more importantly, would actually be a lot harder for the game to check if there were multiple solutions. For more advanced sets of pressure pads, there are a large number of potential methods by which the game can produce the clues. For example, for a 3×3 grid, it might create a clue for the top row, a clue for the bottom, then go from there; or it might create a clue for the top-right corner, a clue for the bottom-left corner, then three more; or it might create a clue for the three in the middle (vertically) then work out from there. Obviously the larger the pressure pad pattern, the more clue orientations there are, but the harder it was to make sure all clue orientations can be solved. Despite my best efforts 0.3.0 had a few that couldn’t be solved, but those were all fixed for 0.3.1’s release. Lastly, each puzzle can only contain a particular block once, so you can never get two of the same block in one puzzle, although variations upon a theme – ziggurats of different sizes or trees of different seasons – are allowed. This is again to be remove ambiguity – if there are two frogs in a puzzle, there might be multiple solutions, which means trial and error might come into it, and that was unacceptable according to the design plans at the top of this entry.

Thus, once it has selected it blocks and gone through a number of possible permutations, it then develops the clues. Next week I’ll be going over this process, and the tricky balance between keeping clues cryptic, but also unambiguous.

Also, 0.1.3c is out with a few small bug fixes, and one big one which nobody spotted but I realized was there, which I’m afraid breaks save compatibility. ENJOY, INTERNET!

Viewing Direction and Multi-Layered Tiles

Most roguelikes have a single z level and a single perspective. What I mean by the first of these is simple – each floor of the dungeon is flat, and there are never objects you’re too “high” or too “low”, vertically, to see. You cannot be too low to see over a particular barrier, and nor can you ever be too high to see something hidden below a ledge, for example. What I mean by the second, however, is that tiles look the same irrespective of the angle they’re viewed from. Viewing a wall tile from any angle is always a wall, whether you’re in the chamber the wall makes up, or the corridor that the wall is just one side of. Viewing a door will always look like a door whichever side you view it from. Obviously there may be modifiers – spells of effects that reduce your line of sight, or cause hallucinations, or similar – but the objects remain stationary in your view under normal situations.

URR is a little different. Originally I only had z levels, and that means certain areas would have to look different. This is much the same as Dwarf Fortress. Areas significantly above the player print as a filled-in ‘^’ icon; areas above you produce a ‘v’; whilst your line of sight is obstructed by areas that are too high above the player’s current level. This needed a lot of work to implement because the characters that need printing on each tile are not fixed but relative to the player’s height. However, there’s also a second aspect which is becoming increasingly important – tiles which look different from alternative angles, not just from alternative heights. In this first screenshot inside a ziggurat, you’re in the room with the relevant clue, and that displays correctly. That’s obviously what’s meant to happen, and it does so fine.


However, it is possible for the player to get behind this inscription and view it from the back. This could lead to the possibility that depending on the generation of the level, you could see a clue from behind before you actually reached that room with the clue! If the wall containing a clue was also a wall of a corridor leading to the clue, then you’d get to see the clue early (odd, but not a big issue), but also the player character would be able to magically read an inscription through the wall, which I deem to be a real immersion-breaker, and also warn the player about the location of a puzzle room in the dungeon. At the moment that final aspect doesn’t matter, but in the future with resource management and potential enemies, that kind of foreknowledge about the terrain might matter. So, I had to find a solution to this.

I considered what exactly the problem was; seeing the inscription tile, without being in the room the inscription refers to, should not show it. My first trial simply made the game notice which wall the clue was on, and print appropriately. If it was on the southern wall, any player north, north-west, north-east, west or east of the clue would see the ‘?’ whilst any player south of the clue would see the brick icon. This resulted in this:


Which worked great. What this meant, however, was that being below the inscription, even if you couldn’t actually see it, would have it reprint. Moving across the horizontal or vertical axis for a clue would make its appearance change even if there was no way to view it from behind. This worked to fix the original bug, but made other possible situations rather less elegant. If you were north of a north-wall inscription but couldn’t see it, it would still reprint. This meant that moving around would randomly keep redrawing the visible inscriptions according to each axis for each inscription that you crossed. As above, this did prevent the reading-inscriptions-through-walls error, but there’s really no need to hide the inscription in this case because you cannot view this from behind. I needed a system that would do what was shown above – inscriptions viewed from behind vanish – but only if they can be viewed from behind, so that the image below could also occur:


Without changing from the above code, the inscription to the south of me would vanish, for no good reason. So, I returned to the process and iterated it again. I added in a new piece of code that had it check whether that particular square can even be seen from behind. So, if an inscription is on the southern wall, it checks if the south-western, southern or south-eastern tile from that tile are “open” to the player, and therefore can be seen. If any of these registered as being open, then it would revert to the solution in the second square – being behind it print the wall instead. However, if they are register as closed – in the third picture it is on the northern wall, and the NW, N and NE squares are all walls – it doesn’t need to print anything new because you can never view that inscription from behind. This solution ensured that only in the very, very rare situation where the inscription can be viewed from behind will it print a wall instead.

This is part of a much wider requirement for the game. There are multiple other types of tile that have to display differently based on the player situation. For example, doors can only display if the player’s height is less than or equal to the door’s location. For example, if there is an area with a height of 20, and levels 18/19/20 contain a three-level door, then standing atop that tile must hide it, whilst being anywhere below it must show it. This means a hefty part of the rendering code is basically for “exclusions” – for showing things if the player is at certain heights, or certain angles. Most tiles can be trivially displayed regardless of your angle, but a few tiles of these sorts require special treatment. Indoor areas, because they lack height, are significantly simpler because nothing has to be rendered specially to take account of the player’s location on the z axis. I haven’t yet decided how to handle things like bridges that you can walk under, but it’ll probably be handled like walking underneath tree leaves. I don’t yet know how many other aspects like this there will be, but I’m sure more will arise as time goes by. In the mean time, however, version 0.3.1 will be released in the coming week with a set of minor bug-fixes, and will be the last version until 0.4 later this year, in which – I am proud to announce – you will be able to die. I’m hyped.

June Progress II

The last week  has seen more coding than much of the last month – having lacked the internet for the past week, very little else has been done aside from it. As ever, the release is a mix of things I’m making public before-hand and a few secrets I want people to find, but here the updates I can share. I’m aiming for release probably around late July at the moment, but it might get pushed into early August. The first half of July is almost entirely full with academic work, so we’ll just have to see how it goes. I’ll be doing a lot of playtesting towards the end of June once I have a pretty stable build, but ziggurats are looking all but finished.

Puzzles are 100% finished. There are five “levels”, finishing off with “boss” level puzzles. Even when I know how to solve the puzzles, they still take me some thought. Playtesting it with people who don’t know how they are generated under the hood have found them so far genuinely challenging and really interesting to solve, so I have high hopes. They include a vast quantity of procedural art (something like 200+ images?) and over 300 possible puzzle permutations, and that’s not even counting the clues. You’ll have to play A Lot if you want to see even a small percentage of these things.

Ziggurats are 99% finished. They generate the entire buildings, all puzzles generate (as above), the structures inside and outside match up, dungeons are three-dimensional, which is to say staircases lead directly up and down, not to random points on the floor above, and some areas can only be accessed from floors above or below. It makes for a really interesting structure to explore, and it’ll be all the better in the future once a greater variety of rooms exist. Special ziggurats also have secrets atop them, whilst by the end of tomorrow other ziggurats will have clues pointing you towards the special ziggurats if you’ve taken the wrong one. In the future these will be treasure rooms etc. Lastly, as well as “Look-up” graphics for blocks, I’m adding ones for doors, iron gates, and a few other things. They look pretty cool.

A basic inventory system is now in place. This is not what it will look like in the future, but suffices for the time being to deal with the few items now in the game. It won’t be redone for the release after this (probably), but certainly will once a decent number of items actually enter the game.

Next update will be next Monday, and since I now have internet at my new place, they should be regular until release (I know I keep saying this, and failing to keep to it, but I’ll try). By this time next week, ziggurats should be totally finished and I should be onto bug fixing and optimizations. I’ve had a very crazy idea for hugely reducing save/load times I need to try out, amongst other things.

As a final note, I’ve taken to streaming games on Twitch. At the moment I’m doing a Dungeon Crawl Stone Soup extended endgame run, but I might stream coding and playtesting or similar in the future if people are interested, and it could be a cool way to just chat with you guys! Let me know what you think, and see you next week (or on a stream). My account is, and I’ll probably be streaming some DCSS half an hour after this blog entry goes up…