City Districts

This week I’ve been working on two major things – religions and cities. I haven’t totally finished off religions yet so I’m going to leave those for next week’s update, and focus now instead on cities. For a couple of weeks cities have been generating names based on how their civilization likes to name cities (there’s a huge variety of possibilities in this regard – not all city names are just “X+Y” “Winterhome”, “Axehearth” style) but the cities have only appeared on the world map as outlines, produced by the city’s reasonably-organic growth after several centuries of simulated time.


Although generating the interiors of cities for the player to work around are going to happen in the release after the one I’m working on now (currently 0.5, city interiors will see the light of day in 0.6), I decided to work on generating the rough outline of those interiors so that I could begin to fill up the “Cities” section of the in-game encyclopedia with some meaningful information. Thus, cities are split into districts. I’ve done this for several reasons. Firstly it will aid the player in knowing approximately where in the city they want to go for a particular objective by splitting the city into distinct parts; secondly it is arguably more realistic when one considers the kinds of layout post-medieval cities had; thirdly it allows for various mechanics involving the player either being allowed into certain districts, or being able to sneak/fight your way in, rather than having the city as a single huge map; and, fourthly, it allows for some rather aesthetically pleasing city maps. There are currently a range of districts planned. Here’s an incomplete list of what will generate in each district:

Docks: Ships. (Blue ‘D’)
Market: All types of item shop. (Yellow ‘$’)
Recreational: Arenas, pubs, gambling. (Purple ‘R’)
Upper Class Housing: Noble houses. (White ’1′)
Middle Class Housing: Guilds? (Light Grey ’2′)
Lower Class Housing: Jails, keysmiths. (Grey ’3′)
Medical: Gardens, Apothecaries, Hospitals, Fountains, physicians. (Green ‘+’)
Military: Barracks, weapon/armour traders, smiths. (Red ‘[‘)
City Centre: Cathedrals (and equivalents), libraries, government, universities, courts, mints, etc. (Blue Diamond)
Castle: Dungeons, ruler (if Monarchy/Stratocracy), weapons/armour, treasury. (Grey ‘#’)
Religious: Many religious temples, smaller altars, etc. (Lilac ‘^’)

Once I’d settled on this, I needed to get the game generating the districts in sensible layouts. This took a bit of working out because there were a range of variables. Firstly there were some districts cities had to have – such as city centres, and castles, and so forth. Secondly I had to order additional districts, like military or medical districts, in an appropriate order and probability weighting to get them appearing at the kind of frequency I want; thirdly, and most trickily, I needed to make sure districts that could sometimes be viable – such as docks if near a cost, military districts if the civ isn’t pacifist, and religious districts if the civ allows freedom or religion – generated in the right cities, knew which districts they were “more important than”, and generally were integrated into the lists of the generic districts well. Once this was done, I then worked on getting the cities to show in a zoomed-in map the player will be able to view both in the encyclopedia, and when moving between districts. I’m very happy with how these have come out:


Castles and city centres are *generally* close to the middle of the city, but you can get significant variation if the city has grown in a strange shape, existed near a coast where it couldn’t necessarily spread out a lot, or simply if the 1/9 chance (I think) for a castle or city centre to not be at the geographical centre of the city comes to pass. I’m still deciding what other information the encyclopedia should display for cities, but this will be one key part. In later versions city districts will be unknown until the player either explores them for the first time or learns information about that district from some other source, but for now I’ve just got it showing all the districts. Next week I’ll be talking about religions, their icons/symbols, how they generate, what benefits/disadvantages they give you, and what agendas religions may want their followers to pursue.

Cities, Roads and Towns

I’ve been working on adding cities, roads and towns to the world map. They’re generated in that order – each feudal civilization is given a capital city, and then everything goes from there. Cities start off as a small 2×2 structure. As time goes by, cities can expand in any direction, up to a maximum of a 5×5 size. A city reaching that full size is very rare – most cities don’t end up being twenty-five tiles in size and generally end up between fifteen and twenty. I tried a lot of different character sets for depicting cities, but in general I ended up showing them in the way displayed below. In the future each tile will be a distinct district, such as “administrative”, “market”, “military”, “medical” and so forth, but those aspects are still in the planning stages. The bigger the city, therefore, the more districts and the more services. Some district types might be particularly rare compared to others.

Meanwhile, once the cities have been placed on the map the game then adds a series of roads. I expected this to be quite simple, but as it turned out making a network of roads which wasn’t too dense, wasn’t too sparse, looked organic and found their own way around the map in an intelligent way was surprisingly tricky. Firstly, I didn’t want diagonal roads. Roads had to move orthogonally – the logic behind this was simply that I couldn’t find any ANSI/extended character that could accurately depict the shift from horizontal or vertical roads to diagonal ones. So, that meant that the pathfinding algorithm had to work only by moving in orthogonal directions. However, this was not without problem. For those who know how A* works, if you disable any diagonal directions it will still basically split the path into “diagonal” bits – even if those are just done by going up-left-up-left-up-left, rather than diagonally – and then long stretches of horizontal or vertical bits. What this meant was that any time roads were trying to path to a distant point, all the roads would line up (as we see below) and funnel themselves towards their target. Needless to say, this looks like crap.


My initial solution was to try having the path sometimes divert from the optimal route. Say, each four “steps” there is a possibility for the path to divert one tile in a direction perpendicular to the route of travel. However, having tried this, it rapidly produced its own set of problems. What if the road decides to divert at a crucial point, and then cannot actually rejoin the initial route? Say, if it diverts on the tile before a coastline, and then cannot path back to where it needs to be, what would happen to that road? The solution to this would be to have the game check every time it wants to divert and make sure it can safely get back onto the right route, but then you’d just have roads which basically bounced up and down on a straight line, which – having tested it – also looked like crap. In the end the solution was pretty obvious, but I think reasonably elegant and simple. Once the world map is created, the game goes through the map and picks a certain selection of tiles – very few, and in a regular (though hard to spot if you don’t know it) pattern – that prevents any horizontal or vertical line from continuing for more than nine tiles at the max. A trivial solution, and once it tried to pathfind on this new, hidden map – also excluding mountains and deserts, which will in the future have their own methods of travelling across – you get something like this. The routes are still fairly optimal, but look organic and realistic:




Once the road system is added to the map, the game then starts to work on placing towns. Whilst roads are being placed the game makes a note of each road – once they’re done, it then goes through each road in turn and measures how long it is. The longer it is, the more towns will be placed. In general each road will only have a single town, but roads above 50 or 60 tiles have a good shot of generating with two towns. This is obviously subject to change – I have on idea yet whether this will be too many towns, too few, or roughly enough. I should add towns and roads will not generate on the human scale for the next release; they will only be shown on the world map for now. However, if you check the development plan, 0.6 will see some of these areas actually starting to generate for you to walk around. As for mountains and deserts, the current intention is for “mountain passes” to generate which require navigation in a special way (still working on the specifics) whilst deserts have no roads or obvious means of travel. I currently plan for the player to be able to either navigate across them on their own – whilst taking the risk of running into a travelling nomadic civilization – or to make contact with a nomadic caravan who may take you safely across the desert. Again, this is for now squarely in the “future mechanics” category, but those are my initial thoughts. I’m also currently working on having the game add in other appropriate settlements (e.g. towns which aren’t on main roads, mines atop resources, farms, etc) and connecting them intelligently to the main road system, and we’ll have some more 0.5 world maps in a few weeks. Next time I’ll talk about generating the names for cities for all types of civilizations (hunter-gatherer settlements, feudal cities and nomadic encampments have very different names) and for the various religions the game is generating.

Efficient Map Generation & RPS Postmortem

For those who didn’t notice my incessant spamming of this link on every media outlet possibly available to me, I was interviewed for Rock Paper Shotgun earlier this week, and the interview can be found here: The response has been insane, and has made me very glad that I chose a higher hosting package for this site than I initially expected to need. Several gigabytes of downloads have taken place in the last week and the game is still flying off the shelves (metaphorically speaking) as I type this. Thanks to all the new people who’ve found the site, downloaded the game, followed on Facebook, Twitter or Twitch - I hope you like what you’ve seen, and that the development plan and the future objectives for the game sound like something you’d like to be a part of. I make a point of replying to every single comment, email or tweet I get, so if you have any comments, observations, criticisms or whatever else, do please send them my way. I’m well over 50% of the way through developing version 0.4 (see the development plan for more info), and it will be released before the end of the year.

And on that note, this fortnight’s update is a relatively short one, though a lot of work has been done. I’ve now enabled the ability to export the map grid you’re currently on into a .png file (much like you can currently export the various world map overlays by pressing ‘X’). More importantly, I’ve been redoing all the terrain generation, and have reduced the loading and saving times on all map grids by between 50% and 90%, depending on what’s on the map grid. Grids with buildings and interiors naturally take slightly longer to generate than other areas, but the reduction is very significant. All of those who say the game takes too long to load some segments (you are undoubtedly correct) can hopefully, now, rest easy that they won’t be waiting through the same kinds of load times. I’m also changing how the game stores data so that the save files will be less colossal; this is an ongoing process, but the save files for 0.4 will certainly be smaller than their titanic 0.3 brethren. The remaking of the terrain generation algorithm is perhaps 90% completed now, and one thing I’ve been doing is also adding more detail to the ziggurat regions. I felt they were looking a little sparse, so it seemed appropriate to do something to improve them a tad:


And a gif of these structures at dawn, day, dusk and night (note also the changing shading on the trees):


For the time being these extra structures are just decoration, but in the future they too will be fully explorable, and each ziggurat region on the world map will have a lot more content in it than it currently does. In line with some feedback I’ve got, I’ve decided that there are only going to be three ziggurat locations on the map – each one will contain a single large ziggurat that will contain a key fragment, and the other ziggurats will contain a number of other things in them. I’d like each map grid you end up exploring to be a significant thing, so each grid area (like the one above) is going to contain a far larger amount of content. I’m now switching back to finishing off throwing and projectiles once and for all – perhaps only a day’s work remains there – then I’ll be moving onto handling the health system. Next week we’ll have a summary of all the other developments over the last month and then follow that up with the start of health and injuries.

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.

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.