External Lightning and Throwing

Just a short update today as it has been a busy fortnight. Firstly, some housekeeping. For those of you who don’t know, I’ve taken to streaming URR coding (and answering game questions etc), and also streaming Dungeon Crawl and a few other games, on my Twitch channel. I’m planning on streaming a lot more both coding and games as time goes by, and I’ll be announcing these only on Twitter (since I don’t want to fill up the Facebook page or anywhere else). I’d also appreciate some feedback on whether people are interested in seeing me do more gaming with the stream, more coding, or a mix. Briefly, on the first for example, I’m currently playing Crawl a lot – which I’m reasonably good at, and have several wins for under my belt – and will soon be playing the original Deus Ex for the first time. If you’re interested, let me know, or check by the channel. I’ll normally be streaming from any time between 12am and 12pm GMT, depending on what else I’m doing.

Now, onto the actual update which, as promised, is pretty brief (though what it describes is pretty significant!). Firstly, you can now throw items. Doing so brings up a crosshair, this time yellow (the ‘l’ook function is white, whilst the ‘g’rab function is orange), which also produces a “tail” behind your cross hair which shows you whether or not your throw will reach its target, sections of which will light up red if you’re trying to throw it through something you can’t. You then press enter, and the item soars across the map (some items spin whilst flying, so a torch will display as ― / | \ whilst flying) and hits whatever. I’ve also enabled a system for a message to display both when the item hits something, and when it lands, along with any other effects. For instance, you might get “The torch hits the wall”, or “The torch lands on a fire trap”, or “The torch hits the wall and lands on a fire trap” if you aimed the throw at or beyond a wall, it hit the wall, and then comes to land on whatever is below it. Additionally, some objects now set off some traps. Anything passing through a tripwire (not over a tripwire – it must land on the tripwire) will set it off, and heavier objects landed on pressure pads will set them off. You will also soon be able to ‘u’se branches to, rather than just throw them at traps, prod a trap in any square adjacent to you. Bear traps cannot be set off by something as light as a branch landing on them, but they will be triggered if you push down on the trap with one manually. Naturally all of this need will need balancing in the future once I know how much the player can carry, the scarcity of items, etc, but I’m just focusing on the mechanics for now. Below are two pictures of valid and invalid throws:



Secondly, torches now produce lighting whilst they fly! It is a very, very cool effect, and means you can now throw torches into the darkness to see what’s ahead, if so inclined. There will be very little in the current release that you might need to do that for, but in later versions it will be of much more use in certain situations (though you’d always run the risk of alerting people up ahead). The image below should give a vague idea of what it looks like, but I’ll try and produce a gif of it at some point.

Torch Throw

My next objectives are making sure all the interactions between objects and items on the map a) are correct and b) give correct messages whether in or out of sight, working a little more on tripwires so they spawn correctly in some unusual map situations, and finishing off the trap graphics, around 70% of which have thus far been done. After that I’ll be working on the ‘m’ake menu for combining items (for example, constructing torches), and then I’ll be moving onto the second big part of this release, which is health, damage and healing items. Well on track for releasing 0.4 before the end of this year! I’m also going to start producing much more detailed changelogs from here on (akin to something like Crawl) since there’s always a lot of tweaks and minor new features I end up fitting in.

Major Mid-September Update

This week’s blog entry is a big update on what I’ve been working on this week in the game, which is a combination of graphics, inventory systems, limbs and player health, and allowing for lightning (e.g. torches) external to the player. Firstly, I’ve been implementing graphics for various items. One of these is bottles – whilst the game does not contain “potions”, it’s going to be important to be able to transport various liquids. I currently plan for this to be possible via glass bottles, and waterskins, with each balanced a little differently – glass bottles can hold anything, but might be smashed in combat, whilst waterskins can only hold one substance (as it soaks into the material – so you cannot use it for poison, then water), but cannot be destroyed in combat. Although not a key component of 0.4, I decided a day or two ago to work on the bottle graphics, since I was taken by some of the ideas I had, and here’s what I came up with. Firstly, below, are four examples of possible substances in four different types of bottle. The top-left is water, the top-right is oil (notice the subtle sheen?), the bottom-left is blood (the most stylized of the bunch), and the bottom-right is poison.


There are currently five different shapes of bottle (all shown below, though I might add a sixth too) – these shapes have no gameplay effect, but are just for variation. Each has five different levels for the substance inside – full, three-quarters full, half full, one-quarter full, and empty. Once empty you will be able to refill them from an appropriate source (like blood from a corpse, water from a river, poison from a deactivated poison trap, etc). There are, as above, currently only four substances, though I can imagine several others that might be useful in the future. There are therefore at the moment exactly a hundred different permutations of glass bottles (5 designs, 5 levels, 4 substances). Thus far this is the highest number of permutations to date, I think, for any particular graphic, and will only continue to grow as I add another type of bottle and various other substances.


I’ve also remade the inventory (for the final time). The inventory in 0.3 is effectively a “fake” inventory – youInventory can only pick up the three key segments, and you cannot drop them, and only one aspect of the inventory can be accessed. Additionally the system for picking up wasn’t “real”, in the sense that the items were implemented in a way which couldn’t really support anything other than the three key segments. This entire debacle system has now been changed in several ways. Firstly, when you try to pick up an item on a tile with more than one item, it produces a list of possible items (shown on the left). You can then highlight the ones you want by pressing the appropriate letter, and press Enter to confirm your selections. Those are all then added to the appropriate inventory sections. The inventory itself, mInventoryeanwhile, can now handle, sort and allow you to select arbitrary items from any category. When you open your inventory categories with > 0 items in will appear white rather than grey. Also, opening your inventory for different purposes – looking, dropping, using, etc – will obviously have a different label. You then select the appropriate inventory subgroup and do whatever it is you opened the inventory for. Esc or any movement key will get you out of this screen.

When you select an inventory sub-group, it then brings up a list of everything in that subgroup. I debated just having one large inventory for all items, but I decided against that for various reasons. Firstly, because some inventory classes have limitations – for instance, you will only be able to carry one long weapon with you – and I felt this needed to be clear. Secondly, some inventory categories might have large numbers of similar items, for example lots of branches for making torches, and I didn’t want that to “clog up” other inventories. Thirdly I suppose it also serves a small gameplay effect for showing you what category certain items fall into, and fourthly, I just felt having a “main” inventory menu looked aesthetically nicer. I did a lot of practice with it and much like one becomes used to doing several-stage macros in Nethack or Crawl, so to does one quickly become used to clicking the shortcut to the right inventory area. One of the items I’ve now implemented graphics for is the torch, which looks like this:

TorchesTorches have five different images which reflect how burnt down they are (0-20%, 20-40%, and so on), and there is also a different colour of wood for each type of branch (the above being olive, and 20-40% burnt), resulting in something like eighty different torch images or so. I am currently in the process of adapting and balancing the extent to which I want torches to boost your vision, and also to allow the player to make torches via the new ‘m’ake command. “Crafting” will not be a large part of the game, but there will be a few situations where you will be able to combine items to others. I’ll have more on this screen and this mechanic once I’ve worked on it a bit more, but you’ll soon be able to use flint, stone and a tree branch to create a torch (i.e. creating a spark with which to light the branch). Over the next week or two I’ll be looking to implement the difference in torch radius when you wield a torch, and allow you to wield and un-wield them. You can also now drop items, either singly or in large numbers, much like the pick-up-multiple-items menu; you are given a list, you highlight the ones you want, then press enter.

Next up I’ve been working on the health and limb system, which has undergone a not insignificant number of changes over the lifetime of the game thus far. I’m implementing this now because traps need to be able to hurt you (funnily enough) which means that acid burns, fire burns, physical limb damage and all the rest of it need implementing. The first part of this is ensuring that limbs all display correctly when you look the player (and later at other foes). This can either be done by ‘l’ooking at yourself, or pressing the ‘@’ button. Here’s a quick preview of how the three screens currently look (they can be tabbed between):


The second and third screen are largely placeholders at the moment, since you cannot change your clothes/weapons nor gain or lose any allegiances aside from the civilization and religion you start off belonging to. The first screen, however, now displays whatever dreadful ailments have befallen your character, as in the example below:

InventoryAnd also, as we can see, whatever healing items have been applied. I’ll do a full blog entry later on how health and healing are going to work since this entry is getting long enough already, but items like bandages, sutures and splints are going to be important to healing various parts of the player’s anatomy. Also, you really don’t want the rotting status.

Lastly I’ve also worked on external lighting sources, though they are still very much a work in progress. When you drop a lit torch, it currently lights up an area around the player (the radius is not yet fixed or decided; this is just a proof-of-concept example). If you can see the external light source, you will be able to see everything in it, as in the left picture. In the right version, there is a tree trunk  between you and the light source; you can therefore see parts of it, but not all of it. You will not be able to see creatures or items between you and an external light source if there is a gap between the two – whilst obviously in the real world you would see a silhouette, I think it would make for more interesting gameplay if you could only see foes when they’re in lit areas, thereby perhaps allowing you to place and move light sources strategically to keep track of enemies.


What I’m not yet sure about though is the relationship between external light sources and undiscovered terrain. In this example, although you haven’t explored the middle you can still see through it to some of the light source, but since parts of it are blocked, you can reasonably deduce there is probably a tree or two in the shroud you cannot yet see. This model treats undiscovered areas the same as areas you’ve discovered but cannot currently see – you can see through them, but you cannot see into them.


Whilst I think the first two implementations both make sense, I’m really not sure about this one, so leave thoughts on whether you think this makes sense, or whether undiscovered terrain should totally block your line or sight. I can see arguments for both versions. That’s quite enough for this week – next week I’ll probably be moving onto discussing either traps, limb damage, or both, in more detail, but as ever let me know what you think of these latest steps towards 0.4! As a whole, things are well on track for a winter release, and now that I actually have a working microphone again, I’ll be looking to stream more coding sessions and Q&As and the like in the near future – stayed tuned to Twitter & Facebook for details…

Real-Time Strategy “Level Design”

As well as development updates, I’ve decided I want to start writing more pieces about interesting mechanics or things I admire in other games outside roguelikes. This is a long and detailed blog entry about level design in a genre nobody really talks about level design in – real-time strategy games. When conversations like this happen it’s generally about multiplayer balance, typically for Starcraft multiplayer maps that come with their own strategies for each of the three sides. However, here I want to talk about level design for singleplayer missions in RTS games, specifically the original Command & Conquer, one of the most well-balanced and well-designed games I’ve ever played. There are three missions in particular which really show off the thought and effort put into making these missions not just “maps”, but actual levels that demand more thought from the player than build tanks -> move tanks -> win. If people are interested in more entries like these as well as game development ones, let me know.

So, this is our first example. At the start of the mission your forces need to reach the green cross, but they are blocked by a pair of enemy vehicles on the bridge. These are Mammoth Tanks, the strongest units in the game – a single one of them would destroy your entire force by itself, let alone two. You begin with six units. The largest is an MCV (“Mobile Construction Vehicle”), a unit required to construct a base, and therefore vital. You also possess a single light tank with an anti-armour cannon, two “attack bikes” (at the front of your force) with anti-armour rockets, whilst the two “buggies” either side of your tank can only damage troops. Your tank and two attack bikes, whilst both strong against armoured units, would be pulverized in direct combat with the Mammoth Tanks. In this case, the game requires you to utilize the design of the level to survive, and if you wish to play optimally, to take advantage of – and, perhaps, even exploit – the game’s AI.


As above, you have been given two buggies to start the game with. These are flimsy and can deal no real damage to armoured units, but you have been given them for a reason. Your attack bikes are effectively minor glass cannons – a Mammoth Tank would destroy them in one or two salvos, but their rockets deal significant damage. Thus, your first step is to send a buggy down the white line, get the attention of one Mammoth, then have it lead it away. At this point the player has two options – one is arguably the optimal play, whilst another is simpler to carry out and requires less simultaneous movement of units, but leaves the player more exposed after it. This less-optimal play would involve you having a second unit go in, distract the second Mammoth, and have them go around in that loop whilst your other units get across the bridge and set up a base. Your tank and attack bikes will then be able to protect your fledgling base, though you will need to keep your buggies moving. However, unless you are willing to keep commanding your buggies in an endless circle which will distract you from the rest of the mission, you need to find a permanent solution to the Mammoth Tanks.


Instead, the optimal play is to have your tank & bikes move up behind one of the Mammoths chasing a buggy, and attack it from behind. Sometimes the AI will turn its attention to the new attacker, but sometimes it won’t. I’ve never worked out what the exact trigger is for this – maybe it’s random, but I doubt it, as C&C is a very deterministic RTS with few RNG factors. I think it has something to do with proximity – if the Mammoth Tank feels it is sufficiently close to its target (the endlessly-fleeing buggy) it will ignore those shooting at its rear armour. Thus, you need to keep your buggies moving in circles. This must be done slowly, so they don’t advance too far on the slow Mammoths and get the Mammoths to turn around and destroy your useful units, but still stay out of range of the Mammoths’ weapons. This must be done whilst having your armoured vehicles attack the Mammoths, but not getting too close, and also moving your MCV (that large vehicle, one that lets you construct bases) across the bridge to build a base. This is a demanding task with several parts, and the map is specifically built so that you have to use the units you’ve been given very carefully, but at a cost of leaving your base undefended whilst you deal with the initial Mammoths. This could not be done without a map design of this sort; it looks impossible at first if you attempt open combat, but ensures the player can find a single very specific solution to master the situation. You are also under a constant time pressure in all late-game missions in the game because you know the map’s very finite resources are being mined by your foes every second that passes; you could wait until you’ve killed the Mammoth Tanks before building a base with your surviving units, but you are instead encouraged by this additional pressure to send your MCV on unguarded whilst your units stay back to handle the tanks. Although your base will be initially undefended, against the tank and the two attack bikes the non-retaliating Mammoths will fall reasonably quickly, and certainly before the first waves of enemies – primarily troops, against which the tanks wouldn’t be that much use anyway – come at you from the enemy base.

In this second example, you start the level with a single unit, a “Stealth Tank” – it is invisible to all units unless it strays within a tile of an enemy unit. They are flimsy, and would die in open combat to any of the units or defensive buildings visible here. They are also revealed if they stray within a single tile of an enemy unit. You are tasked with retrieving the red unit – an MCV, and the only one you get in the level to build your base with. To do this you must find a way into the base and then find a way to construct your own base after that, without having the ability to extract your MCV and build safely outside the walls of your foe.


Here, the player is unable to use traditional RTS strategies to retrieve the MCV. You obviously cannot build up a force to enter the base (because you have no production buildings), and nor do you start with a force sufficient to break through even the weakest of the three gates surrounding this base. The first part of this mission is more like a puzzle game where you must find a particular route through the level whilst avoiding enemies that behave in specific ways. There is a single path to enter the base and retrieve your mission-essential unit:


Having done this, your secondary objective is to destroy all the enemy units and buildings on the map. You cannot get your MCV safely out of the enemy base, and thus the player must build their base within the enemy’s. The tall yellow buildings with blue/white tops are “Advanced Guard Towers” (AGTs) – these are powerful defenses with a significant range, as (approximately) shown by the red circles below. You cannot build within those circles, nor safely move your units within them, as they will come under fire you cannot resist at this point in the mission. However, AGTs require power, and there are three power stations your Stealth Tank can safely aim at by uncloaking (they must de-cloak to fire) just north of your MCV. Killing two of these power plants is not sufficient, but all three is. Once your stealth tank is positioned safely, they can destroy those power plants, disable many of the base defenses (though not the smaller yellow towers, nor the tanks) and thus start to build a base.


Subsequently, the optimal strategy is arguably to build walls outwards to block enemy vehicles, and although this is too complex to show in a diagram, many of the enemy buildings and enemies are positioned in such a way as to encourage the player to slowly advance across the base and taking it over in a very specific order. So, on this map the player is tasked with finding a route through obstacles – a very un-RTS principle – before thinking outside the box and finding a way to take out a base from the inside whilst not triggering its external defenders, rather than attacking from the outside. Were any of the buildings placed differently – for example, a second AGT on the left side of the top gate – this map would become impossible. As it is, there are just enough power plants within safe firing range for your fragile Stealth Tank, and just the right locations for defenses, to enable a very specific and unique strategy and get the player thinking carefully about the power/defense/enemy layouts the mission has put in front of you.

In this third example, you start with two groups of units split off from one another. The units at the bottom need to navigate the lower half of the map to retrieve a non-essential cache of money in the village at the end of the green arrow; the units at the north of the map need to enter the base in the centre-left, capture its buildings, and start building a base from there. In this case, you have a lot of units and the base is only guarded by a pair of standard “Guard Towers” (blue circles) – these are weak against tanks, but tear through soldiers. You are only given soldiers, but the makeup of your soldiers, and using both your forces effectively, are the keys to making the opening stages of this map far from trivial.


Your unit composition on the top is very cleverly thought through. You have a dozen normal soldiers (blue); one commando (the light green), who can one-shot any troop at range, and instantly kill any building if in an adjacent tile; and three engineers (dark green), who can capture buildings (note the three yellow buildings within the western base – these are what you are expected to seize). Your troops are not sufficient to overcome the two anti-troop guard towers; your commando, being infantry, cannot possibly get close enough to destroy them (using C4 in close proximity). The engineers are essential. The only solution is to use the standard troops as fodder; they must run ahead of the commando into the guard towers to allow him to C4 them both. Guard towers target enemies closest to them, so the player needs to also ensure the commando hits the guard tower in the one-second window between its bullets without giving it time to ID the commando as the “closest enemy” and open fire. Commandos briefly overlap with the a tile a building is built upon during the placing of the C4 – ensuring they will be considered the closest enemy – so meeting this timing window is essential.

Additionally, there is a “Gunboat” patrolling (the white circle) left-to-right-to-left on the river. This gunboat will destroy your troops if it comes into range; a second use of your lower units is to keep an eye on the gunboat, and ensure that your northern units only attack the guard towers within the safe window whilst the gunboat is on the other side of the map. Much like the first level discussed in this post, this adds a secondary time pressure – the player’s sacrifice-then-C4 attack on the western base must be carried out before the gunboat concludes a single loop, and you should ideally command the southern force of soldiers to keep an eye on the gunboat and avoiding sacrificing your key northern troops before you get the chance to then sacrifice them to the guard towers.

On this level, then, the defenses of the base, much like the above second example, are specifically designed and placed so that your unit composition must be used in a particular way to overcome them. This sacrificial solution is also particularly fitting because the army you are playing as for this mission, a strange kind of terrorist-militia-irregular-army-paramilitary-cult-populist organization, are willing to sacrifice unimportant soldiers (within the plot), and this mission nicely reinforces that from a thematic standpoint.


Ultimately, all three of these missions ask far more of the player than to merely build a base, build up an army, and conquer the enemy. In all three cases this is certainly a later objective, but rather than simply starting the player off with an MCV, some resources and some escort units, they each ask the player to think about the tactical situation in more interesting ways. In the first the player has to utilize the map to their advantage to overcome an apparently impossible battle, and take advantage of, or even exploit, the AI. In the second the player has to navigate through a “puzzle” base before cautiously developing their own base within the limits imposed by the enemy’s fortifications. In the third, possibly the most interesting, the player needs to control two different groups of units; use the southern unit group to assist the northern unit group in timing their attacks to avoid the gunboat; and then to launch an attack in a narrow time window where you need to manage both your meat-shield units and your crucial unit very carefully with one-second time windows for destroying the buildings in question. Rather than multiplayer maps that demand perfect balance (or at least strive towards it), or maps like those offered by most RTS games which are merely “somewhere to fight” (looking at you, Supreme Commander), the layouts of these maps and the specific and few units given to the player provide unique and interesting challenges, and also show the player particular tactics or strategies that could potentially be deployed in later missions even without the restrictions these missions have. Whilst other C&C games certainly have some interesting levels, the original still stands out to me as a cut above the rest.

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!