Thoughts on Metro: Last Light

A couple of weeks ago I spent roughly 10pm to 7am one day playing through Metro: Last Light on the highest difficulty. I’ve previously played Metro 2033, and despite a few flaws I found it to be a refreshingly difficult FPS, with some challenging mechanics (gas masks/filters, and bullets-are-money), sometimes very difficult level design, interesting quasi-bosses and a willingness to try weird ideas which (generally) worked very well. It also had that notorious checkpoint-free area where you interfere in the battle between the Communist and Nazi factions, which rates as surely one of the hardest and most rage-inducing FPS checkpoints in history (at least with the impressive itinerary of useless weapons I was carting around at the time). In Last Light, there are two parts I want to talk about, which it respectively does far better and far worse than the original. The first is to acknowledge how well-done one particular area of the game – “the swamp” – was, and how cleverly a bunch of different mechanics were brought together in this area, along with some nice subtle and passive aspects of world-building in the Metro universe; the second is to do with item balance and the importance of item scarcity, the way in which Last Light inexplicably did away with a central part of what made the original so interesting.

- The Swamp

As Artyom, the hero of Metro, you explore this area twice (or possibly the second time is a “marsh” rather than a “swamp”, but the distinction is irrelevant) – it consists of a combination of land and water, containing various red flags that denote safe areas. If you plunge into the foul water below your character drags himself back out, having lost several seconds, but if you do so too many times in short succession (I think there is a timer here) a creature will swim up and consume you in short order. First time you arrive you come here in the day – another apocalypse survivor has set up an automated raft to ferry you across the swamp, but it requires fuel which you must find and deliver to the motor which will drag the raft towards you, before then allowing you to escape.


Your first look at the swamp…

The swamp succeeds firstly because it feels like a genuine ecosystem – when you get here you see some water-based enemies you’ve met once or twice before, but also a host of other creatures who do not interact with you, but just swim or scuttle about. Other enemies disappear and reappear from the surface of the swamp (I think/assume despawning when they dip under the water) and, whilst they rarely attack you, their constant presence lends a lot of life to the area and emphasizes you’re stepping into somewhere with a very alive and very active selection of mutated fauna, not the dark and silent catacombs that make up many of Metro’s levels. It’s a welcome change of pace - whilst much of the world is dead, this section serves very well as a bit of ambient storytelling to demonstrate that much of the world is not deserted of life (even if the life is nothing like we recognize) and that entire ecosystems have built up; we see larger creatures preying on smaller ones whilst we’re out here, and just the general flurry of biological activity all around.


These guys flit, swim and hunt around you as you progress through the swamp, but are not unwilling to attack if suitably provoked.

This flurry of activity also serves a few clever gameplay effects. It builds up a stronger sense of urgency about your activity than in darker, ostensibly “spookier” regions – all this activity around you suggests at any moment the occupants of this swamp might lose their patience with you and attack, whilst the player wonders what exactly might set off such a response. Are the enemies programmed to attack after a certain period? Maybe only after you pick up some fuel? Or perhaps they’ll leave you entirely alone unless you attack or come to close to one of the creatures minding its own business? The uncertainty over what exactly might trigger them is eminently realistic – who could possibly guess what would incite giant mutant shrimps to attack you? The region seems less safe than other areas despite being so bright and open, and you’re constantly spinning around and checking behind you. This is not because you fear things emerging from some dark crevice or hidden hive, but because you want to make sure you haven’t done anything to annoy the inhabitants. Equally, if you do, the ensuing combat feels subtly different to that elsewhere in the game, where you attempt to deal with the creatures you’ve annoyed whilst avoiding triggering any others. Having only played it once, I’m uncertain what the actual triggers are, but I’m pretty certain proximity to the “shrimps” aggravates them, and possibly just standing still for too long makes them increasingly annoyed at the bipedal invader tramping around above their swamp.

Another effect of keeping you moving to avoid the foes couples nicely with the filter mechanic, which is everpresent in outdoor areas. This consists of managing the air filters on your gas mask, which are in short supply and must be replaced whilst outdoors to filter out the toxic fumes of the world above. In the swamp the player wants to push forward without bothering the inhabitants too much, whilst the filter time constraints prevent you from necessarily pushing up against the boundaries of the play area. It’s a pretty simple trick, but an effective one to stop you finding all the invisible walls. The swamp seemed like a genuinely massive area and I never came up against its boundaries. You still need to explore to keep a decent number of filters, but the constant threats (which often respawn in areas like this) and the timer combine to keep you moving and stop you breaking the illusion of the open level. The outdoor levels seem far more open than in other games, due partly to the superb design of the outdoor areas (when you make it to St Basil’s Cathedral and the Kremlin Wall is a particularly good moment), but also because of this exploration limitation.

- Item Balance

The original Metro had two central forms of limited resource. These were ammunition and the gas mask filters discussed above. Sadly, whilst Last Light improved on the formula of the original in terms of world-building, these two aspects were very much dumbed down in the sequel, regardless of the difficulty level you choose to play on. Firstly, ammunition. The currency in the game is “military-grade bullets”, which are more powerful than normal bullets. You can shoot them, but as the game reminds you this would be “literally burning money”. In the original Metro (at least at max difficulty) such bullets were genuinely rare, however much you explored, and there were situations where the use of these bullets was a difficult decision. You can get the extra damage in your current battle, but you won’t be able to buy new bullets or upgrades for your guns later down the line. It worked very well. Here, however, even when I just held down automatic fire to pour bullets into certain bosses or hordes of enemies, not even once did I a) even consider using a military-grade bullet for extra damage, nor b) come even close to running out of military grade bullets to sell and fully restock every single ammo clip and grenade inventory every time I found a vendor. You can get through the hardest challenges the game has to offer as long as you have decent aim, don’t hold down the trigger like a madman on every enemy, and you make sure to scavenge every corpse (which takes seconds). I think this is due to two factors – firstly there are simply more bullets around the place (obviously), but the knife is far easier to use in this sequel, and as a non-depleting resource, the number of bullet kills I had was maybe 10-15% lower than in Metro 2033 due to the immense quantities of humans and mutants I stabbed in the face. This combination means the careful inventory management of the original is, sadly, a thing of the past. I would go as far as to say the number of military-grade bullets should have been halved, at the very least, to keep that mechanic intact.

If you are ever unable to afford everything you want every time you want it, you're Doing Something Wrong.

If you are ever unable to afford everything you want every time you want it, you’re Doing Something Wrong.

Secondly, filters. In the first half of the game these work great, and as mentioned above serve a very good purpose in some of the tougher outdoors sections. However, after you enter the third (and worst) act of this four-act game, suddenly the developers seem to have had the “place air filter” button permanently held down on their mice. Although struggling to get above 2:00 of air for most of the first half (and often having to survive without a filter at all for many seconds whilst finding another), I believe I finished the game with something stupid like 20:00 of air backed up. Filters are everywhere. Every corpse, every box, every toilet contains one. Every filter seemingly contains another filter, hidden within it like Inception’s dream layers, just to make sure you don’t run out. Artyom’s movement speed should have been halved at the very least by the sheer weight of these things he’d have been lugging around by the end. A lot of the final two acts take place in the outside so you need a lot of filters – that’s fine. But either the developers assume people wouldn’t explore, or they assumed players are just painfully incompetent, as otherwise there’s simply no other reason to simply hurl as many of these things at the player. All the tension and difficulty of maintaining your air earlier – sometimes even deliberately choking for a period to extend your life – whilst sometimes fighting difficult fights is utterly lost when you can just chuck in a new air filter with the same ease as reloading a gun. Tension evaporates, and fighting outside is no different to fighting inside, except having to replace Filter n with Filter n+1 every few minutes, which is a pretty meaningless act when there’s no possible way you could run out. It also enables you to rush through this third act without pausing and feeling any real pressure to explore, making the several-hour section absolutely trivial – the filters are placed directly in your path, rather than hidden, and no extra effort is required to build up your impressive stash of filters.

By the time you get here, you will have so many filters you could outfit every human survivor and still have some to spare.

By the time you get here, you will have so many filters you could outfit every human survivor and still have some to spare.

- Final Thoughts

Both Metro games are skilled at coupling environments, subtle storytelling and gameplay together. The level design is generally combined well with the creatures you find there, and does work for contributing to the story and generating specific feelings in the player. Whereas a game like Bioshock can be heavy-handed in its level design – it gives you a puddle of water or a pool of oil, immediately setting up obvious combinations of weapon/plasmid use – Metro’s environments seem to me much more interesting, and much more willing to produce a unique enemy or unique idea purely for that one region, and the effort combining the environments and the gameplay really shows. As for item balance, the first game in particular gave you a very stringent inventory system which promoted difficult and interesting decisions (much like other games which present you with limited resources), an aspect which was sadly lost in the sequel, even if those mechanics remain interesting ones which will hopefully be meaningfully reinstated in any future edition of the franchise. In a future blog entry I want to talk more about the kind of background storytelling I’ve mentioned here, and also how I want to couple environments and gameplay and URR in the future. For the more roguelike-minded, a great example of this is the new version of the Vaults in Dungeon Crawl (as of 0.12), where the enemy set and the physical layout of the area work together in interesting (and generally unpleasant) ways… but that’s a post for another time.

Next time, we’ll have a URR update, at which point everything to do with traps, throwing and handling projectiles (as those who watch my stream will know) have been finished, including graphics for all objects and all traps. After that, I’ll either be moving onto a lot of tweaks and small changes for 0.4, or the other large part of the next version – the health system. Stay tuned…

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.