Not Quite The Shortest Update Ever, But Not Far Off

Just a very short one this week I’m afraid folks, with a few updates:

Employment and House Moving

So, on October 1st, I’m starting a new job! I’m going to be a postdoctoral fellow in game studies at the University of York (where I did my doctorate) for up to three years as part of this massive thing. This is the same project that Michael Cook of ProcJam fame is now part of (also as a postdoc, though in his case in Falmouth) so hopefully some awesome things will come out of that collaboration (we already have one intriguing idea vaguely in the works). Of course, moving back to York necessitates house moving, which is going to be taking up a lot of my time for the next couple of weeks – updates will still be every weekend, but I might upload some of my pre-written general games discussion/criticism/design ones rather than URRpdates for the next week or two. We’ll see how time pans out.

Houses and NPCs

I’ve been reconsidering how difficult it would be to assign NPCs like guards to specific houses in specific districts this release, and I actually don’t think it would be that tricky and shouldn’t be more than a couple of days of work… so I’ll probably do that. I have this week finished off everything to do with guards (though clearly some of it will need changing if I do indeed implement this kind of “real scheduling” for this release) and done some general bugfixing, minor improvements to the quantum scheduling system for moving around the map, etc etc. All timings are now correct, and the system will be readily transferable to important AIs whose actions around the map also need to be timed and tracked.

Roguelike Radio

I assume everyone knows this by now, but I’ve recently become the co-host of Roguelike Radio! The most recent episode (the Q&A) is a particularly good one, I think, and we have a great discussion between just myself and Darren about “information” in roguelikes coming up. Check it out here.

Next up?

Next up is still, as I’ve been saying for a little while now, day/night scheduling, shops closing up, things like that. At that point, however, it becomes apparent that we need to get people going back to their homes, which brings us back to the guards point, so actually for the next few weeks I’m going to work on some lesser things whilst I’m moving house (like improving how aristo families are generated, bug-fixing a bunch of left-overs from previous releases, more clothing generators, a few alterations I want to make to city generation, etc), and then once I’m settled back in York at the end of this month and can really focus again on a larger project, I’ll push on with a concerted effort to the final part of NPC handling, which is giving all NPCs who matter homes, and tracking them and their behaviour wherever they are in the world. Whew. See you next week!

In the mean time, a smaller and general reminder: if you ever want to keep track of URR elsewhere beyond this blog, I must humbly recommend my Twitter feed, the URR Facebook page, or IndieDB – the former particularly is full of screenshots which generally get posted before the weekly update!

Scheduling, World Travel, NPC Replacement

Short-Term Replacing

Now, some stationary NPCs require two special things: they might need to be replaced in the short term (so there will always be a guard in any guard location, but at certain points in the day a new guard should come along and relieve the other guard, who would presumably be getting tired), and they might need replacing in the long term (e.g. gladiators who have died by now, or sailors lost at sea, etc – the game needs to replenish its volume of some of these NPCs when some are killed or cease to be important). Long-term replacing is not yet required (since NPCs, and the player, cannot yet die), but for short-term replacing, there is now a system in place to perform this task. When a guard spawns, the game sets a length of their watch, and when this period is up, a new guard is spawned as close to the guard as possible without the player being able to see the new guard spawn. The new guard then travels to the location of the old guard, and once they are on adjacent tiles, they switch places, and the old guard then moves out of the district and despawns, whilst the new guard becomes effectively identical to the old guard. I’ve also set up a system where there is a set “pool” of guards for each place, so perhaps you’ll be able to persuade certain guards to let you in if you know when their shift is, and their willingness to be bribed/persuaded/threatened/etc? Here, therefore, we have both the guards on a mint changing over, after which a priestess and her escort ramble past:

Guardswitch1

Nice Robe

And the equivalent in a bank: they would not ordinarily all change over in this short a space of time, but for the sake of testing, it looks pretty neat:

Guardswitch2

Travel and Abstract Scheduling

Once I’d implemented this guard system, I then realized the game needed to track this wherever in the world the player was (or, at least, when the player next sets foot on that tile, work out which of the two guards should be on their shift, and spawn them). This seemed trivial, but it quickly became clear I was going to have to do other things before this. If I want the game to see how long it has been since the player last set foot on a map grid, then I have to know precisely how many turns/how much time moving on the travel map takes – and that, in turn, means programming that fully (currently there is just a placeholder of 20 “ticks” of the clock for each grid moved) and also making sure it cannot be exploited, and that moving on the travel map is never more/less efficient in terms of time spent than moving on the local maps (so, for instance, if on the world map you move north, north-west, then west, it should only count you a few turns as you move through the “corner” of the NW tile, since you wouldn’t walk to the middle before turning… but this rapidly makes the calculations very complex, as the calculations have to look at your previous two turns to figure out what would have been the most optimal way to move from Tile 1 -> Tile 2 -> Tile 3 if you’d been doing it on the local map instead of fast travelling). As such, I spent two days this week developing a detailed calculating system for working out the most optimal path the player could have taken between what I call two tiles and their outcome – the outcome being either pressing Enter to explore that tile, or moving onto a third tile – and thereby ensuring that, for long distance, fast travel is always equal to the most optimal path the player could possibly take on foot, i.e. the player should not be encouraged to spend real-world minutes slogging around the world on the local map, as it will never be faster (it will either be equally fast, or slower). So, basically, the system now tracks your previous two moves, and all the possibilities of those moves, and then when your third decision causes these possibilities to “collapse” (forgive the quantum terminology) the game calculates how long the most optimal way of carrying out that movement would all have taken, before then letting the player do any more interacting. This might sound strange, and it took a solid two days to code, but now it works perfectly and can handle all scenarios of the player’s fast-travel movement, and is always efficient, and allowed me to finally return to guards and ensure that the game knew which guard should be on patrol duty. In 0.9 therefore this system will be expanded to actually take account of terrain: moving on roads will be very fast if you have a mount, moving on desert will be extremely slow if you aren’t in a caravan, moving on mountains will be even slower unless one takes a mountain pass, and moving on ocean will, of course, be impossible unless one charters a ship.

Exploration

As part of the above, I decided to do a little bit of work on how the world map is going to look to explore -this is still not going to be the first release where the map starts mostly shrouded (though it seems very clear that that will be 0.9 early next year), but I wanted to implement it at the same time anyway. When you move you now uncover all the tiles in a circle around you (effectively a 5×5 grid centered on the player with the corners removed) but you can also see all mountains in a far larger area, to simulate the ability to, naturally, see things which are higher up than other things (profound, I know). In the future I’ll probably let you see a decent distance across the ocean, too, but I haven’t added that yet. Here are gif and image examples of how this looks, which I’m very happy with at the moment:

Unexplored2

Unexplored1

Finally…

Last but not least, many thanks to the extremely generous donations of the last couple of weeks; I really appreciate them! Over the coming week I’ll be working on completing the scheduling system for NPCs – day night cycles, going “home”, that kind of thing – and doing a lot of remaining edge cases and things like that, so once that’s all done, I might get working on one of the other clothing generators for this release, or keeping track of the “crucial” NPCs. We’ll see. See you then!

“Stationary” NPCs – Priests, Guards, Shopkeepers, Jailers, Mercenaries

This week I’ve implemented almost all the “stationary” NPCs. To explain what I mean by this, URR has three “tiers” of NPC: the crowd, the stationary, and the crucial. Crowd NPCs spawn and despawn as the player moves around the world map and are of importance insofar as they demonstrate the demographics of the nation, and you will be able to acquire significant information about the generality of the nation/religion/culture they belong to from them, and they serve also, when in crowds, to illustrate something of that nation’s ideologies (so you’ll only see a crowd with a bunch of people trailing a priest in quite a religious nation, for instance). Stationary NPCs are positioned in locations where there must always be an NPC serving a certain function, but the individual is not of particular important. Examples would be priests in religious buildings, jailers in prisons, innkeeps, guards, and many others. In some cases these individuals will “change” around after time – guards, for example, will be “met” by another guard at a certain point who will then take over the guarding role, i.e. they change shifts – whilst others, like priests, will obviously not change every few hours. Crucial NPCs, meanwhile, are those NPCs who are of sufficient importance to the game and the world that regardless of where the player is, the actions and movements of these NPCs will always be tracked. This category is primarily for NPCs like rulers, religious leaders, inquisitors, heretical leaders, nobles, military officers, and the like. Also, very rarely, what appears to be a stationary NPC will actually be a crucial NPC. Which is to say: in a jail, maybe 95% of the prisoners will be “general” prisoners, but a tiny number might have massive global significance due to their past role in a grand plot, and one wouldn’t know which was which until uncovering a path of clues which lead you to the important prisoner. Ninety-nine out of every hundred priests might be good loyal clerics… but perhaps one in a hundred hides an religious artefact of immense importance in their private quarters?

So, this week it has been the turn of all the stationary NPCs. Here are some examples:

Priests

Priests now spawn in religious buildings and cathedrals. In religious buildings, the priest lives on the top floor and will return there in the evenings; in cathedrals they have distinct rooms on the ground floor to which they will retreat as and when appropriate. For the time being,  however, they just spend their time around the ground floor of the cathedral interacting with the worshipers, going about their own worship, etc. There is actually a tiny bug in the below gif – the priest was standing on the same tile at the altar, when they should be standing next to the altar – but I’ve since fixed that, but I otherwise rather liked this gif so decided to stick with it.

Priests

Embassies

Embassies now have clerks and diplomats in them; the clerks are probably going to be “general” NPCs in the embassy crowd, whilst I think diplomats will be assigned to specific areas. The ambassadors for each nation in other nations will be crucial NPCs who will always be tracked separately, so they haven’t been coded just yet.

Emba

Servants/Slaves

Servants/slaves (depending on whether the nation is a slaving nation or not) now spawn and go about their business sensibly in upper-class houses. The houses will also, of course, get visitors in the form of various aristos from time to time, and then later, we’ll get working on the “crucial” NPCs – i.e. the family who lives there – generating properly. Thus, for now, here’s an example of some servants and some general citizens. You’ll note the servants will always stand next to something, either next to a person to serve them, or next to a chair/table/whatever in order to keep it clean and tidy. They’ll sometimes return to their quarters in the basement, and once I get schedules working, they’ll obviously retire there at night.

Uppercrowd

Prisoners

In jails (in nations with the Penitentiary ideology) we can now find prisoners in the cells, one prisoner per bed, milling around. As mentioned above, a small number might be someone of particular importance, but it’ll be up to the player to decipher who (if anyone) that might be. Prisoners will also be on release schedules (or at least, the lucky ones will be!) so they’ll be replaced whenever one moves out. I might add some kind of system whereby the different floors of each jail are for different types of prisoner – I’ll think about that going forward.

Jahail

Archivists

Below the cathedrals of theocratic nations you’ll find a crypt… and if you explore that crypt, you might come across a room containing the most secret archives of that religion. Right now these are tables without books, as we don’t have book generation yet, but we do now have the archivist, and their guard(s), spawning. Here’s a gif of me finding an archivist in a half-flooded crypt in a city next to the ocean, and then having a look at the archivist, and looking at his religious garment (which you’ll note has grey patterning – as well as “default” robes and the “religious leader” robes with gold patterning I showed last week, I’ve added in a mid-tier version with grey patterning which will be given to people like archivists, abbots, inquisitors etc, who are higher-ranked than the average priest but not the leader(s) of the entire religion). The “Archivist” is depicted with a ‘V’, and the ‘g’s are of course the guards:

Archivist

Once books are generating, archivists will be guarding the most important secrets of their religion, so the books behind them will be immensely important to find a way to read…

More Guards

Guards have also been added to several other areas which need them, such as Officers’ Quarters, and Mansions, and various other places, and the guards for now all shout the “Oy, shop that!” placeholder (along with their x/y coordinates) once you walk into their territory:

Ofguard

Monasteries

I’ve now temporarily (or permanently, we’ll see) removed the “Cultism” religious ideology and replaced it with, for the time being, the far more interesting “Monastic” option, and as such, we now have monasteries spawning. These are structured in the form of a religious building in the middle, a range of paths and vegetable gardens around it, a “loop” of monastic housing in a shape based on the civilization’s spatial preference, with several other important rooms (libraries, dining halls, abbot’s quarters, etc) spaced around the outside (or sometimes the inside). As examples, here we have a map grid containing a monastery (diamond), then the player standing outside one (cross), then inside from the player’s perspective (square) and an absolute perspective in the same monastery (circular) – note of course that all the wall in middle and edges of the fourth picture is not actually wall, since outside the monastery is where the vegetable garden is, but all the spare space in an “interior” map is just filled in with wall:

NewS

Monastery Outside

Insaad

Inside1

Next Release?

I find myself with a quandary. Everything to do with NPCs and their schedules, behaviour, appearance, etc, will be finished, at the latest, by the end of next month. However, one will not be able to interact with NPCs at this point: there will be no conversation system. At this point my intention is to continue working on this release until the conversation system is fully implemented and as deep/detailed as I want it to be, and thereby make this the largest (in terms of time invested) release URR has ever had, so looking to release in Oct/Nov. As the first gameplay release, this seems appropriate on some level – I want the first gameplay release to have a lot to do (or at least a lot of people to talk to!) rather than a little. On the other hand, I do strive (with mixed success) to release new versions as rapidly as I can. So: what does everyone think? Right now I feel I’d rather save up both NPCs and conversations for one massive first gameplay release, rather than make NPCs 0.8 and conversations 0.9, as I think a world full of NPCs you can’t interact with will feel rather peculiar… but I’d like to hear your thoughts.

Next Week

Next week… I have no idea. Something involving NPCs in some way. See you then!

Crowds, Slums, Pathfinding, Campfires, Demographics, Priests, etc

It has been a busy fortnight, with house-moving (in progress) and secret projects (almost ready to start) and programming (proceeding nicely) and various other endeavours (far from complete), but I’ve finished all ambient crowd behaviour, and a couple of other things besides. Here’s a pretty massive round-up of what has been happening in the last three weeks since the last full URRpdate:

Priest Clothing

I decided to work last week on a second of the four high-level clothing archetypes (feudal, nomadic, hunter-gatherer, religious) – the religious clothing. For this I did a standard expansive image search, collated a range of religious dresses, and then attempted to break them down into commonalities, differences, and readily exchangeable parts. The colouring of each piece of religious clothing, much like the prayer mats we saw a few weeks ago, are connected to the altars they worship at. The highest-ranking priests in the religion will have slightly snazzier robes, whilst if the religion has any kind of poverty-is-holy ideology or similar, they might have duller robes. Here is a set of six possible robes all using a potential “demonic” colour scheme (just since that’s the one I was testing the systems with, but how nice do they look?!), and then some with their attendant altars alongside (one “Eldritch” archetype, one “Pantheon”, and two “Standard”), and lastly an example of the higher tier of religious clothing reserved for religious leaders (hence the lovely gold filigree):

Priest Clothes

Altvest

Popeclothes

Priests use the same shoes as the nation they’re in, and usually the lower-class variation (though in some religions priests will be barefoot). With these done, that means approximately half the clothing generation for 0.8 is done – feudal clothing is 99% finished (I just need to put in a few final touches to the lower-class variations) and religious clothing is now finished. I’ll probably work on nomadic clothing next, as I have a few ideas of what archetypes I want to generate those around, then I’ll do hunter-gatherer clothing probably last before this version’s release. Armour and things like that will come later (0.9?) so for the time being, all soldiers and other military personnel just have lower-class clothing, or upper/middle-class if they are officers (which in the future they’ll probably keep, but just wear beneath their armour).

Slums and Encampments

The last few areas which needed handling for NPCs have been dealt with. NPC crowds now spawn, move and despawn intelligently in slums outside major cities, and also in hunter-gatherer encampments. Pictures of slum, and encampment, and example crowds:

Slumgi

HGcrowd

Remaining Interior Behaviour

All buildings which can have crowds in them (e.g. a tavern can have randoms wander in. but a royal mint cannot) now have those crowds behaving intelligently at all times, and – as far as I can tell – this is entirely glitch/bug/crash free regardless of what building, what civilization, what demographics the NPCs in question are, etc. Here are some examples of an arena and a longhouse, since I thought these were both rather pleasing, especially in the longhouse as people gather around the table:

Arena

Lonhouse

Pathfinding Problems

Some buildings and some parts of the external map were starting to produce a problem – if you had two NPCs (or an NPC and the player) trying to get through the same one-tile tunnel between walls, at the same time, then they couldn’t slip past each other. I implemented a temporary solution (whereby crowd NPCs will look for another objective if they find someone blocking the one-tile route down to their current objective) but this wasn’t good enough for the future, especially once we begin handling important NPCs whose paths cannot just be changed on a whim. So, now, if you have two NPCs who meet, and NPC 1 is trying to move onto the tile NPC 2 is on, and NPC 2 wants to move onto the tile NPC 1 is on, *and neither of them can find another way around* by stepping on a diagonal, and they would both allow the other to step past them (so they aren’t enemies), then the game will look at which one of them has the longest wait until their next turn, and then schedule a special “simultaneous” turn for them both to switch places at the same instant for that more distant turn (so that neither NPC can move “faster” than it should be able to). I’ve now implemented this to work indoors and work outdoors, so here’s an outdoor (filmed in “slow motion” to make it clear) example of this:

Switch

However, this became trickier when I wanted to combine it with the player. Clearly the player should be able to do this as well, but it required writing quite a hefty new chunk of code, for handling if the player tries to move through an NPC, or an NPC tries to move through the player, because obviously I don’t want to remove agency from the player, or allow NPCs to shove the player around the place (as that would get quickly annoying), but nor should the player somehow be able to exploit this ability to move NPCs around the map (I’m not sure how this could be an issue in the future, but it seems better to just produce a robust system now rather than worrying about it later). Either way, we clearly needed a way for NPCs to walk past the player if the player is being an ass and standing in the way:

Stuck

So, there are two scenarios: what if the player wants to move onto another NPC, and what is another NPC wants to move onto the player. It would be deeply annoying to allow the player’s character to be “pushed around” by other NPCs, so that was something I knew I had to avoid, but at the same time I had to ensure that you cannot exploit the system by somehow pushing around NPCs yourself. If an NPC wants to move onto the player, therefore, they initiate a special two-turn move, where the NPC takes two turns instead of one and “squeezes” past the player, taking both moves on the second turn – so from the player’s perspective, the NPC moves next to them on Turn 0, remains there for Turn 1, and then moves to the other side of them on Turn 2. If the player moves in the interim, then normal pathfinding resumes and the two-turn move is cancelled. (Of course, the two turn move only works if the tile beyond the player is free, the player and the NPC’s relations are friendly enough that the player would let the NPC get past, etc). Here’s an example, where I start off looking at the approaching slave, then turn to the other side, and sure enough the slaves pass “through me” using this special two-turn move:

flip

This also results in a message being printed, along the lines of “The [NPC type] squeezes past you”. The other version is; what if the player wants to get past an NPC who is blocking a one-tile area? An NPC blocking a one-tile area and standing *still* should be an impossible scenario – I am certain there are no areas which are valid for crowd NPCs adopting the “meandering” walking type which are also only one-tile wide – so if one encounters an NPC in an enclosed space, it’ll be if you and the NPC are moving towards each other and need to cross over. If the NPC “initiates” the move, we get the scenario shown above. If the player initiates the move, then the game looks at both the player and the NPC, does the usual check of whether they are allowed to move through or not (this might have to wait until 0.9, as it’s going to be a complex calculation – for now it just returns “yes”) and then, if so, it has the player move along with the obstructing person during the later of their two turns (so if the player is next scheduled to move on turn 18174, and the NPC on turn 18175, then both will move on 18175, so that neither character is able to have a “free turn”). You then switch places with them, as shown in this example, where I step into an NPC who I am friendly enough with to switch places, then I turn around (taking one turn) and we therefore see the NPC two turns behind me, and they then leave. Had I just stood still, then they would have initiated the two-turn move, going “through” me without forcing my movement.

Mymove

The three systems shown here also work when indoors as well as outdoors. These are all very rare scenarios, and I suspect will (for the most part) only happen if the player is standing deliberately still to try to annoy the NPCs, but it still needed handling. With all of this done, I am now… 99% that all NPCs of all categories, whether inside or outside, and whether dealing with the layout of the terrain, the motion of other NPCs, or the motion of the player themselves, should be able to path correctly past any obstacles (I think there is still one final minor non-crash bug here involving NPCs who have stopped to admire something, and if they have stopped in a “line”, then other NPCs may struggle to get past, but I’m working on fixing that one). As a last note on this, it’s also worth noting that in almost all cases I’ve worked hard to ensure every corridor/path both inside and outside is, in most cases, at least two tiles wide. However, in certain areas – slave quarters, some cathedral generations, slums, and a bunch of other places – one tile corridors can generate, so it was clearly important to handle these sorts of scenarios.

Also, now I need to at some point have you be able to switch your “walking style” from “walking” to “shoving” (or “pushing”, maybe?) so that in the rare possibility of a blockade (which I *think* should be impossible, as I’ve modeled spawning a bunch of NPCs on every tile in an enclosure and they’ve always managed to find their way out so far) you can always push your way through NPCs and force them all to move into the position you previously occupied, though that might not make them all that friendly to you. Nevertheless – and although I’m not even sure such a scenario can ever happen – it seems like an important addition which I’ll probably add this release, and it should be simple (note if there’s an NPC there, and if so, just switch places with it).

Campfires

Hunter-gatherer encampments now have campfires, beds, and tables. Only the fires so far have an image, but the beds and tables will be made of either wood or stone, and will get images before the end of this release:

Campy

We still need more variation and detail in these areas – a lot more, honestly – but hunter-gatherer areas now look slightly less bleak and empty than they did a little while ago (in the above picture you can see some stone chair/tables and a second fire). More soon, hopefully, though anything beyond tables, chairs and beds might have to wait until 0.9 or a little beyond. I’m focusing on feudal nations this release (although all NPCs will be present), and it’ll probably be the next release when I do more on nomadic and hunter-gatherer NPCs and societies.

Guards

We now have guards! Guards appear outside Parliaments, Mints, Embassies, Officers’ Quarters, Armouries, Mansions and Citadels in the middle of Fortresses, and also inside Banks and Arenas (the former to guard the vaults, the latter to keep the crowd at bay and make sure nobody interferes with the combat). The game also now notes every part of the map which needs a special “permission” in order to access it, and guards are tethered to certain permissions, meaning that if the player steps onto a tile which has the (‘Embassy’,24) permission and the player isn’t from the nation with the id# 24, then the guards will act – right now the game just registers this since the conversation system isn’t in yet, but that’s the plan. So, here are some guards doing their guarding thing (they currently wear standard clothing since armour generation doesn’t exist yet):

Majors

And then here’s a slice of the visual map, and the “forbidden” map, which shows the parts of the terrain close to the armoury door which will trigger the ire of the guards, so we can see that anything within the courtyard, and some of the tiles just outside the the gate, will trigger their ire (the guards don’t show up on this view, but as we saw above, the guards are basically standing just outside the gate):

Armo

So, now we just wait until later this release when I get working on a conversation system and the guards can accost you! More on this later once I figure out how precisely it works, but all the guards spawn, and detect intruders, and that’s all that matters for now.

Distance Demographics

The crowd’s demographics now vary according to the expansiveness of the nation in question. By this I mean – if the nation is small, then all people spawn with the genetic demographics (skin tone, hair colour, eye colour, etc) of the capital, or nearby. If the nation is large, the game will sometimes look for a random tile in that nation’s territory to choose the demographics from (which is to say, if you’re in the capital city it’ll normally be a “capital person”, and sometimes someone from further out; if you’re in a town, it’ll normally be a “town person”, but sometimes someone from further out) and use those to spawn the person instead; and if the nation has colonies it’ll do the same. This means if you run into two people in a nation with the same cultural demographics (clothing, hairstyles, etc) but very different skintone/hair colour etc, then you can reasonably deduce that nation is either very large, or has some colonies somewhere. Here are two examples of this kind of crowd, and the latter you’ll note has a priest leading some followers (the priest of course now spawns with the right robes). Rather annoyingly I wasn’t able to quickly find a nation which had colonies/homelands with skin tones at the two extreme ends of the spectrum, but you still get the idea from these of a lot more variation in the larger and more expansive empires:

Mixcrowd

Mixcrowd2

Another thing this has got me wondering: in future versions (0.9 or 0.10 onwards) all the map except your home nation will be in shroud when you start. Should colonies be “lit” or not? I think the best solution is that colonies don’t start as explored, and if you take a ship to one of your own nation’s colonies, perhaps all the colony land is then revealed when you arrive? In contrast, normally, you’ll just explore the tiles around you as you move, and if you take a ship, it will perhaps show you the ocean path you move along? That seems like a good compromise without having a situation where you start with a few chunks of the map explored which are disconnected from your nation’s homeland.

Lesser Houses

I’ve now implemented the first stage in generating families/houses which are less important than the small number at the top of each civilization (one of which, of course, belongs to the player) but are still noteworthy. In nations with the “Vassalage” ideology, one of these families will have a special “Manor” building spawn in each town in that nation, and a family rules each of these manors and therefore each town. In Vassalage nations the other smaller buildings in upper class districts will also belong to these families (so they have a manor, and a home in the capital), whilst in non-vassalage districts these buildings will also belong to second-tier families, but not “special” ones (as in, rich merchants or whatever, not those with direct feudal/political power). However, for the vassalage nations, these all needed coats of arms! So, I’ve returned to the sigil generation system and added in the ability for “lesser” houses to have coats of arms. These are much simpler than the major houses, and have a geometric pattern determined by the aesthetic preference of their nation (octagon, square, circle, cross, diamond) which feeds into an algorithmic sequence that combines various elements (I’ll also add a system ensuring there can’t be more than 5 vassalage nations, and they can’t share a shape, to ensure variety across the game world). Now, bearing in mind of course there are meant to be for lesser/more general houses… what do you think?

Subthings

Compare, of course, with some examples of important families:

Majors

So what do you think of the minor ones? Good, bad, too little detail, too similar, just right…? Of course, they still need mottoes, and I’m thinking of having it tether them to the towns they’re from in some way (or perhaps these lesser houses don’t have mottoes?).

What next?

Next up I’ll be working on adding more “fixed” NPCs like guards – so this means tellers in banks, priests in religious buildings, servants in mansions, officers in officers’ quarters, delegates in parliaments, and so on. This week is probably also going to see a little bit of reworking of some aspects of world generation, since I need to add in a system for vassalage nations to generate and track these other houses, and for parliamentary nations to figure out how many delegates they should have (I have a cool system planned for this), and I might add in the new “Monastic” religious ideology I’ve been thinking about for a while too. Either way, I’d say we’re about 75% through NPC mechanics at this point, and in a fortnight or so I think everything with NPCs should be finished, and then we can move onto the other massive part of this release – conversations. See you next week!

Dungeon H@cks Book Review

A few months ago I was contacted by one David L Craddock, who informed me that he had written a roguelike history called Dungeon H@cks, soon to be published, and asked if I’d be interested in reviewing it for the blog. I said yes (appropriate disclosure: no financial incentives or anything of the sort), and since it seem reasonable to assume that a lot of people reading this blog would find a book about roguelikes to be the kind of thing they’re interested in, it seemed sensible to say yes! So, without further ado:

DHacks_NoLogo

The book consists of three sections: firstly a number of chapters looking at the majority of major classic roguelikes – Rogue, Sword of Fargoal, Hack, NetHack, Moria, Angband and ADOM, and their progenitor Beneath Apple Manor. It also contains a number of “Side Quests”, akin to a “Notes” section at the end of an academic book chapter where one expands on points tangential to the main discussion, but nevertheless relevant or interesting; and interviews with John Harris (of the @Play column) and Brian Harvey (of Hack). Now, I don’t think I’ve written a book review in over four years, so this is mainly going to be a list of observations, some particular interesting quotes and similarities between the stories of development, and some reflections on this slice of roguelike history (and gaming history more generally) contrasted against my own experiences of working in the genre.

Firstly, two themes seem to run through-out the book: the importance and specificity of programming languages, computer models and distribution methods and operating systems, and secondly the inspirations of the different developers and the extent to which earlier games (quite naturally) inspired those who came later. For the former, I was struck by the similarity of University background for many of the developers, particularly in Computer Science, Engineering and Physics departments in very high-ranking universities: UC Berkeley, UC Santa Cruz, MIT, Stanford, etc. While a scholarly background certainly seems to demographically persist in contemporary roguelike developers – and it shouldn’t come as too much of a surprise to us when thinking about classic roguelikes which were created in an era where it was rare for any location other than a campus computer lab to actually have, y’know, computers – I thought it was striking the extent to which the classics of the genre emerged from this environment. Ideas repeated in many of the chapters – distributing a game on a single university network, or having a computer lab with a single computer, or having campus computers where an Angband borg plays as the screensaver, etc – seem completely alien today and speak to forms of game development, distribution, and user-base creation, which were deeply historically specific. The book also discussed the links between the pre-open-source movement and roguelikes…

Stephenson believes that NetHack played a part in the open-source movement. “We predated open-source [as a formalized movement], but I do think that the fact that we made a huge amount of source code available, without charge and under a public license—an early variant of the LGPL [Lesser General Public License]—helped to promote the idea of making software available for public use without cost.”

…noting in many of the chapters the importance of making the code (or parts of the code) open to the public in order to encourage engagement from the player-base, new people being added to the development team, etc. It was also interesting to note the odd attempt here and there to make these into commercial games, and the various reasons why these didn’t come together, situated within the broader discourse of creating free software for the enjoyment of development, and the enjoyment of seeing players attempt the games, and encouraging a collaborative development process which (in most cases) is obviously anathema to the model of a commercial game.

Equally, the book discusses the inspirations of the respective developers in a lot of depth, and as someone who has only become involved in Computer Science in the last four years, it was this which appealed to me a little more than discussion of operating systems and distribution methods (which tended to dominate the earlier chapters more than the later chapters, although maybe this is a reflection of stricter computing requirements (especially with Rogue) eventually giving way to (slightly) stronger computers?). Many developers spoke of their experiences with Dungeons & Dragons and in the cases of later developers, the earlier roguelike games obviously served as inspirations. One quote from Michael Toy of Rogue fame – that “Moria is probably the closest to what I wanted to do when I made Rogue” – seems particularly illustrative in this regard. Others, meanwhile, speak of the desire for particular player experience – exploration, a sense of danger, a sense of something at stake, etc (all things I’m sure we can recognize from the roguelikes we play these days). When the book discussed the reasons behind procedural generation for the earliest games, it of course noted the value of PCG for dealing with computational constraints where you can only store a certain amount of fixed data, but it was interesting to also note the reverse of this:

Unable to ascribe more interesting characteristics to the majority of monsters [due to technical constraints], Toy and Wichman simply gave more health and stronger attacks to monsters higher up on the food chain.

PCG has obviously often been used in the past to overcome memory constraints – Elite being a perfect example, whilst I assume that far more recently No Man’s Sky does something of the sort – but memory constraints nevertheless meant that monsters in some of the earlier games had to be simpler than the developers wanted due to these same technical constraints. Indeed, we can readily see this “just give them more health” logic in so many modern games where upping the difficult simply means your foes have more health and do more damage, and this made me wonder slightly if this was borne out of an era where adding to a health/damage number was trivial, but adding to something like AI intelligence was extremely challenging? (And, indeed – is this not still the case today?)

Moving on, the chapter on NetHack had this interesting comment to make both about the famous saying about the DevTeam, but more importantly, the subsequent comment about what we would now call “simulationism” in roguelike design:

The DevTeam’s seemingly telepathic ability to predict every possible action gave rise to the acronym TDTTOE, The DevTeam Thinks of Everything. “The more options you have to manipulate the game environment, the more immersive and interesting the game is,” asserted Raymond.

Simulationism is a common topic of discussion in roguelikes (as one can see from my recent entries about the crowd mechanics in URR, both here and on the various other sites I post URRpdates) and people are often split on this – some players enjoy the complexity that a simulationist game offers and the many ways (as the above quote suggests) one can manipulate the game environment, whilst others see simulationism as an undesirable move away from “tighter” game design and towards something less focused, more expansive, and in some cases perhaps more easily exploitable. The choices of the words “immersive” and “interesting” lead me back to my own reflections with NetHack – this was definitely how I felt when I played it as my first ever roguelike. The depth of systems like polymorphing, wishing, genociding, demon summoning, etc, made NetHack feel like this complex immersive world which wasn’t just a bunch of dungeon levels laid out for the player (Dark Souls does this amazingly well – and I can’t have a blog entry without praising Dark Souls!), and in turn, it made it into an interesting experience to learn these systems and figure out how to use them well. With that said, though, there’s always a fine line between simulationism and making optimal play require a lot of grinding or farming – I think NetHack does it well in this regard, but that’s the other side of that same coin. Similarly…

There was a natural tendency for the devs to see the game from the point of view of someone who played it constantly and obsessively; thus, over time, their notion of not making it ‘too easy’ gradually ratcheted up the difficulty level to the point where you couldn’t really enjoy it casually anymore

…is the other danger of simulationism: that the inexperienced player will have a far harder time making sense of the game when it has all these complex systems doing things under the hood (see, for example, my recent piece about the demon system in NetHack). I don’t want to draw any conclusions about it here, but the book explores some of the systems in roguelikes which aren’t connected to their core gameplay loop, and offers (as above) some interesting rationales as to the inclusion of these types of system.

Another comment which stuck with me given my own game design and academic research interests was this one, about Moria:

While browsing the computer’s directory of files late one night, he stumbled upon proof that his attempts to imbue denizens with personalities was working better than intended. Manuals had been written by students describing the vindictiveness of this or that monster, and how the monster seemed to remember that players had attacked it earlier. When he approached the authors of the manuals to explain that probabilities and random numbers were pulling the strings, the students politely but firmly silenced him, insisting that they knew the monsters were truly sentient.

This, to me, seems strongly reminiscent of both Tommy Thompson’s recent work into seeing whether players can identify procedural and hand-made levels, and my own experiences with comments here, by email, and elsewhere: that players of PCG games sometimes mistake complex PCG for simple, or PCG for hand-made, or vice versa. It’s very interesting to see an older but still comparable observation that player experience assigns meaning where there perhaps is none (and can also fail to assign meaning where there is some) and the human tendency towards apophenia.

Another comment I thought was interesting was this one in the discussion of Angband:

“We want [randomized experiences] within parameters. Either there should be no chance of an encounter with, say, a great wyrm [dragon] on level 1 at all, or [the odds] should be so low that they’re basically zero. Most players will never see it. And those [odds] basically end up being the same thing. If a person dies to a super-powerful enemy once, they might complain, but as long as it doesn’t happen a lot, it’s not really a big deal.”

This, again, seems to speak to a fundamental roguelike debate, and yet seems to stop short of saying what (I think) most developers would say is the obvious solution. Should we be able to have a goblin spawn with a wand of death on the first floor? The quote above obviously argues strongly in favour of the answer being yes, arguing that this yields interesting gameplay experience within set parameters and that “basically zero” is, in essence, akin to “zero”. Now, this is something I’ll be discussing more fully I hope in the future if the secret project I’ve hinted about once or twice here comes to fruition, but I have to take the other stance: if the two are truly indistinguishable, then why not prevent those early deadly goblins, as they surely only have a negative effect on gameplay experience, the possibility for even the most skilled players to have a high win-rate, etc? I personally think that is a surprisingly big deal, and something I hope to talk more about in the future, and the book does a good job of exploring some of the rationales behind different spawn systems, out of depth monsters, etc.

I was also struck by the number of stories which involved being taught by a relative – generally a parent or older sibling – the very basics of (often BASIC) programming. Although I also had an Electron, Spectrum ZX, C64 and Amiga as a child (I don’t recall the model, but possibly an Amiga 500?) and a family friend who knew his programming pretty well, this was an experience I never had. Both of my parents are university graduates, but neither in computer science nor natural science, and I don’t have any siblings. When I was around six I attempted to get this family friend to teach me programming, but after an afternoon where I attempted (without success) to clone the excellent Exolon, I quickly abandoned the thing and felt playing games was infinitely more rewarding than creating the damned things. In hindsight, I realize I had the mistaken assumption that Phil Fish mentions in Indie Game: The Movie: that when one is young, one thinks that a game is made by just sitting down and making the game, and it is hard to appreciate what that process actually entails in a technical sense until one has actually done it. Although some of these tales were very similar, it (like the ubiquity of the University computer labs described earlier) spoke strongly to a particular era and a particular background common to most of the earliest roguelike developers, making a set of useful and important historical observations about the particular circumstances which gave rise to the genre.

The later sections of the book move away from discussing specific games and speak instead on other topics: the 7DRL Challenge (edit: since moved into its own book) and a number of interviews. These read as quite distinct to the main historical narrative of the book, and although they make a useful addition for the dedicated reader, they felt very much like a highly extended set of appendices than a separate section of the book proper. The “side quests”, however – the parts which resemble a “notes” section and offer a little bit of additional/tangential/interesting information on some other topic in the book – are very interesting, and yield a lot of amusing anecdotes and useful details on the actual experience of developing these games, some of the problems and concerns and questions, the earlier media interest in roguelikes, personal experiences with fans, etc, which I highly recommend reading.

However, a few negative points must also be noted here. Firstly, in the version I had (eBook version, a month ago), there were a few typos here and there – no more than I normally produce in a lengthy piece of work, but quite a few had clearly been missed in the editing process. That didn’t bother me in the slightest (since I’m always more generous in this regard to books that don’t come from major presses, especially since – having worked with major presses – I’ve seen the level of assiduousness and care major press editors put into every piece of writing and how much time it must take up), but I think it should be mentioned, even though it didn’t detract from my interest in the slightest. Additionally, the interviews were worth reading, but felt a little bit apart from the rest of the book, and might perhaps have made a more interesting blog post or magazine piece, or something of the sort, than a book addendum? However, these are both small nitpicks (and I am told David has sent a newly typo-free version to all publications of the book, so I assume the first point is now dealt with) which did not reduce the quality of what the work had to say.

So, in summary: an interesting read which will appeal to use intrigued by the technical specifics of early roguelikes, the design rationales, the social context of their games, their legacies, the earliest development of what we would now call the “roguelike community”, the impact of roguelikes upon games and gaming more generally, and a lot of interesting and amusing observations and anecdotes throughout. The book also spoke to a lot of debates which take place on this blog and in the roguelike (and procedural generation) community about a range of topics (many of which I’ve mentioned above), and (speaking as a sociologist) it shed interesting light on the social and cultural conditions within which the earliest games in the genre arose, and the broad levels of comparability between the demographic situations of many of the developers of that era (and the playerbase which became interested in these same games). Since this is the first book review to date on this blog and I certainly haven’t implemented any kind of formal rating system (and nor do I intend to), let’s just say: if you’re a classic roguelike fan, I recommend it. Tells us a lot about where we came from, a lot about where we are, a little about where we’re going (that only gets a small chapter at the end!), and how and why roguelikes came to take the shapes we recognize today.