Procedurally generated dungeons

I finally got around to improving the way procedurally generated locations work. Now, locations can have a procgen tag, which causes the game to look for a default set of rules for generating the location when the player enters it. This lets me specify things like which dungeon generation algorithm to use, what tiles to use, which monsters to make present, and things like that.

Additionally, I can specify a list of overrides on a per-level basis, so I can make certain floors of a dungeon different. For example, the first few levels could be brick-and-mortar dungeons, before devolving into rock face caverns with their own colour scheme and different monsters present. Another option available to me is to specify a premade map, so I can have fixed points within a dungeon — boss chambers, alters, shops, or whatever. Within these premade locations, I can even specify which position and level within the dungeon an exit should take you to, so I can also make shortcuts around larger labyrinths. All this should let me build some more engaging dungeon locations.

Alongside this dungeon revamp, I added a couple of complimentary features: procedurally generated quests and quest-locked portals. BotLG is a little unusual in that monsters won’t attack the player; combat is only initiated by the player bumping into a monster themselves. Now, this would mean that you could carefully navigate your way to the bottom of a dungeon and never face any actual danger, which is ridiculous.

To help combat this, I implemented a flag on portals (like doors, staircases, etc., any tile that moves you to another location) that makes that portal only work if a specified quest has been completed. When you enter a dungeon floor, a quest template is picked from a list, and the conditions to complete it are adjusted based on the current difficulty level. Players can only use the stairs down to the next level once the quest is completed; if the player leaves the dungeon, the quest is abandoned.

I’m going to use this system to flesh out the Rat King’s Lair, the first procedural dungeon the player will come across, and then add in a couple more. I’m increasingly thinking I need to revamp the starting area so the player can more immediately jump into some dungeon crawling without having to find the Rat King’s Lair, which is a fair distance away from the player’s start location, and a little off the beaten track.

Sunday 9th February, 2020

Made a start on the Monster Hunter World expansion, Iceborne, this afternoon. Not only do I enjoy the puzzle of figuring out each new monster (I just beat Beotodus and Banbaro, and tracked down a Viper Tobi-Kadachi), but the central farming – crafting – upgrading cycle is a source of inspiration.

I also played a little of Slashie’s Ananias roguelike on mobile. The more time goes on, the more convinced I become that BotLG can be even more a roguelike, and that I should lean more into those features and away from the idle ones. I’m seriously considering making most, if not all, gathering nodes have a limited supply of resources with a respawn timer. That would force more active play, and alongside that I’m thinking of slashing action times in half, to make the gameplay much more immediate.


Once I’ve got all the features I plan on implementing sorted, I can fiddle about with action durations and resource availability and generally balance the numbers. Limited resources that respawn and more immediate gameplay options would definitely work; I’ve been testing that with the wood logging nodes, but I still want the game to be playable as an idle one; there needs to be long-term actions that the player can set their character doing and then leave them to it for a while. One option is to make gathering more immediate, but have crafting take longer. You gather interactively while playing, and then idle in town turning your gathered materials into useful products.

Another option is to have a spread of materials available in each location; the most common would be infinite nodes that you can idle at, and rarer materials would limited and on a respawn cycle. This would make the gathering professions a little like fishing in most MMOs, where the fishable water provides an infinite supply of fish, but to catch a specific or rarer variety you have to hunt down a limited, respawning “fishing pool”.

Either way, what I’m concentrating on next week — tomorrow — is procedural dungeon generation. Once I’m happy with that, it’ll truly be more roguelike and I’ll feel less self-conscious describing it as such, and taking part in r/roguelikedev discussions.

Saturday 8th February, 2020

Inspired by the prolific bloggers I admire, and my purchase today of The Developer’s Guide to Content Creation, I’ve decided to try and blog here a little more frequently. I’m going to be marking all of these posts as asides and putting them in their own category, to separate them a bit from the regular development-focused posts.

Now, of course, I’m a PHP/devops developer by trade, and my primary hobby is creating this web-based roguelike game, so I’m sure these posts will still contain a lot of development talk, but I’m also allowing myself the freedom to write on less tightly focused subjects, and perhaps even be a little more personal. I think often they’ll be about what I got done the previous day, much like Richard Herring’s long-running (and delightful) Warning Up.

Today I went to IKEA to pick up a few bits and pieces. I wanted a couple of things for my desk at my upcoming job (a new wireless charger for my phone, and a pot plant, primarily) and, of course, ended up buying far more than that. It’s impossible to leave that place without buying a whole range of unnecessary widgets that seem like a good idea at the time. I love IKEA. I’m a nester at heart.

When I got in I helped a friend with some WordPress configuration for her excellent art portfolio site, then ended up chatting with Simon about combat balance and a couple of bugs he’d discovered in BotLG; I added them to the list for Monday.

I ended the day by making a good start on a PHP script to generate (hopefully) balanced weapons. I have a rule that I don’t work on BotLG over the weekend, though naturally that will change once I start work again next month. But for right now, I’m so full of ideas and enthusiasm it feels like a shame not to capitalise them when I’m sat at my keyboard.

Work, work

I have some news. About four months ago, I quit my job to work on BONES of the LOST GOD, and, after a few mis-steps and prototype dead-ends, it’s now nearly finished. I’m really pleased with it and the work I’ve done.

However — I need to go back to work and start earning some money, and so I’m taking a full-time devops role at an e-commerce company. However, I don’t start for three weeks which should give me time to finish off, do a little refactoring, and get the game into a position where I can more easily add further content on evenings and weekends.

I’ve got four main things left to do:

  • Re-balance combat and the monsters. Monsters (and combat with them) doesn’t scale very well at the moment as you level up; in particular attack quickly outstrips defence, and combat is a bit swingy at low levels, which can feel frustrating. So this needs looking at, and I have a big spreadsheet of numbers on the go at the moment.
  • Improve procedural generation of dungeons. This works, but the environments it generates are not very interesting. I want to improve the environments it generates, add more dungeon templates (forest, cavern, dungeon, caves etc.), and make delving into dungeons a more rewarding experience.
  • Implement merchants and account-wide storage. So far there’s no UI for buying or selling items, and no UI for long-term storage and retrieval of items. Both of these are going to share some UI and behind-the-scenes work, so I’m bundling them together.
  • Character retirement and account-wide progress. Right from day one I’ve envisaged BotLG as an idle/incremental game, and the one key genre mechanic that’s missing is the idea of prestige; that is, giving up all your current progress for a long-term bonus. I’ll be implementing this by allowing player characters to retire, at which point they will provide resources periodically based on their skills.

I don’t regret doing this — I’m incredibly proud of what I’ve created — and similarly I’m not sad about going back into work; I’m looking forward to it. If I get everything listed ticked off, the game will contain all the major mechanics I envisaged, so I can’t complain.

I’m going to keep the Patreon campaign open until the end of February and then close it; it seems a little disingenuous to take monthly pledges for something I can’t hand-on-heart say I’ll be working on most of the time. If you want to continue to support BONES of the LOST GOD, I have a ko-fi donation page up and I’m going to try and use that a little more.

This is definitely not the end of the project! There’s still a tonne of content to implement (on top of the things listed above) and I have a feeling I’ll be updating and supporting this for a long time to come. Thanks for sticking around.

Questing and crafting

Two new things this week; quests and crafting.


When you enter a location containing an NPC who has something for you to do, you’re presented with a little message:

When you find the NPC, you can interact with them to see what quests they have available, and to hand in any you have completed for them in return for some rewards.

So far, the quests system can handle three different types of quests; all of which will be familiar to RPG players:

  • Kill a specified number of specific enemies
  • Acquire a specified number of items
  • Acquire a specified number of quest-specific items, which only drop while the quest is active

For the gathering items quests, those items can be from the result of performing a gathering skill, like fishing or logging, or looted from monsters. All quests can have multiple objectives. Quests can be one-off or repeatable, and can require the player to have completed previous quests before they become available, allowing me to chain them together to create a quest line.

Recipes and crafting

The second big thing of the week was adding in recipes and crafting. Characters can learn recipes from various items, which then enables them to do some crafting. At the moment that’s limited to cooking and woodworking, but there’s a few more production skills in the pipeline.

Once a character has learnt a recipe from a book or scroll, they can approach a crafting station — the campfire in the traveller’s camp to do cooking, for example — a little window pops up allowing the player to select a recipe and begin creating items.

Because BotLG has a strong gathering/crafting focus, I expect I’m going to be writing a lot of recipes in the next few weeks (and probably authoring a huge spreadsheet in an attempt to achieve some semblance of balance).

Miscellaneous other tweaks

I’ve also done a fair amount of smaller tweaks and improvements this week:

  • There’s now a little minimap that shows the surrounding area with interactable objects highlighted
  • Player characters and NPCs now have a configurable speed, so different monsters can move around at different rates; the player can also equip some boots of striding to boost their movement speed
  • Pop-up dialogue boxes now stack, so you can click an item referenced by a quest, for example, and keep your position
  • Side panels now remember if they’re open or closed between sessions
  • New reading, eating, and potion-quaffing actions; potions are automatically consumed in combat as required
  • Various CSS and JS tweaks

People, places, and things

I’ve worked on three things, mainly, this week. I started out by implementing NPCs the player can interact with. Under the hood they’re essentially just the same as monsters, only they have a dialogue system for their main action, instead of combat. But there’s no reason why in future you couldn’t fight NPCs or parley with monsters. I created a simple branching dialogue system, where you’re presented with what the NPC has to say, and then you have some pre-canned responses to choose from that can lead to further dialogue.

BONES of the LOST GOD is based on a play-by-mail Labyrinth Lord campaign I ran back in the day. At the centre of that campaign was the city of Rooksfoot, an economically-thriving but morally dubious city dominated by a magical arena where sell-swords and adventurous hopefuls would fight to the death for a cheering crowd and the promise of fame and riches. I’m both excited and nervous to be re-implementing the city in this game, and having some NPCs seemed like a good excuse to put the first hint of the city in-game:


Getting past that guard forms the opening segment of the game, and forces the player to go explore the surrounding area. I have two or three different ways in mind for the player to get into the city for the first time, and once they’re in, coming and going as they please will become much easier.

The next thing I worked on was items. I made the view item screen much more detailed and attractive, and made a bunch of new items to support initial character creation, so new characters now receive a set of starting gear better tailored to their rolled attributes. Here’s an example item:

It’s listed as a two-handed weapon, with a strength attribute, so performing basic melee attacks with it will use your strength attribute. Most weapons are strength based, but lighter, more finesse based weapons will use dexterity, instead.

But the main thing to note here is how wielding the item — a staff in this case — actually grants the character access to two actions: fireball and basic attack. For the first time, player characters can now perform different actions in combat, instead of just wailing away with basic melee attacks round-after-round. I’ve been wanting to implement this for weeks, and finally it’s here.

BotLG is a classless game, but characters have attributes and items available to them that are very much in the mould of the traditional fantasy RPG. How your character behaves in combat (and elsewhere) is very much decided by the items they choose to equip themselves with. You can load yourself up with heavy armour, sword and shield and play a strong warrior type, or wield a poisoned dagger and light armour and be the assassin-rogue. This also allows for some neat customisation. If you want to be something a little more unique — a necromancer-bard, perhaps — that’s fine! Get yourself some evil robes covered in death-magic runes, and equip the biggest, baddest trumpet you can find.

Note: neither evil necromancer robes nor trumpets of any size have been implemented (yet). But they could be! And you’d get different spells and actions from each, and they might even synergise a little, and you’d be the happiest necro-bard for miles around.


My next steps are to spruce up monsters, so there’s a bit of variety as you’re exploring dungeon-like locations. Monsters work mechanically the same as player characters, so they also benefit from equipment granting actions to use in combat, but so far none of them are wielding anything that provides anything other than a basic attack.

In tandem with improved monsters, I want to add some quests into the game, so there’s a bit of structure to the slaughter. I already have code written that tracks when you need to collect items for a quest, how many you have, and if a monster should have a chance to drop a quest item. All that’s missing is some UI to allow players to start and complete quests, which I can now tie into the NPC dialogue system.

But is it a roguelike?

It’s been an interesting week for thinking about the word roguelike. On Tuesday, I was finally forced to admit that the game I am making is, in fact, a roguelike:

I’ve been working on procedurally generated maps this week, you see. And with that final piece of the puzzle slotted into place, I finally felt like I had enough elements to realistically consider BotLG to be a roguelike game. Not a traditional roguelike, perhaps, but a roguelike nonetheless.

It’s since turned out to be the perfect week to have these thoughts, as yesterday @humbit set r/roguelike on fire by publishing the excellent blog post, The “Roguelike” War Is Over. I’m firmly in the camp that @humbit argues for; language changes whether you like it or not, and roguelike doesn’t mean the same thing today as it did Back In The Day, and that’s okay. What’s important is that everyone knows what you mean when you say it — yes, even you, grumpy grognard, even if you don’t like it — and it’s easy enough to just say traditional roguelike if you really, really, want a pure turn-and-text based experience. No-one has to lose out here.

The obvious problem with discussions about roguelike vs roguelite is that they’re UTTERLY BORING. There’s nothing new to say but we’ve been treading the same ground for literally years. It’s beyond beating a dead horse. It’s beating a zombie horse. Can we just… stop?

The “Roguelike” War Is Over

So is BONES of the LOST GOD really a roguelike — by anyone’s standards? I think so. Let’s take a look through the Berlin Interpretation guidelines as a flawed but decent-enough starting point:

High-value factors

  • Random environment generation: Yes! Dungeons and wilderness are now procedurally generated. There are some fixed-point locations that are consistent, however.
  • Permadeath: Yes! Characters die, and when they’re gone, they’re gone, along with all their stuff. There is an account-wide storage system, so you can “bank” some items between characters, which softens the blow a little.
  • Turn-based: Sort of! Combat is turn based. Movement is not, but combat and movement are modal, which we’ll get onto in a moment.
  • Grid-based: Yes! All the map locations are grid-based. Players and monsters of all sizes take up one tile.
  • Non-modal: No! Probably the biggest rule breaker here, but movement and combat occur separately from each other, and what actions are available to you very much depends on what you’re currently doing.
  • Complexity / Resource Management: Eventually! So, there’s not a lot of complexity in the game yet, but several systems are in place that will result in complexity as more items, monsters and effects are added. So watch this space on this one.
  • Hack’n’slash: Yes! Killing lots of monsters is important in roguelikes, and there’s plenty of monsters to kill in BotLG.
  • Exploration and discovery: Yes! I spent enough time on making field-of-view and fog-of-war work nicely alongside a mix of hand-made and procedurally generated maps, and all the best stuff will be tucked away in dungeons and the wilderness, so I hope exploration will be a strong component of gameplay.

Low value factors

  • Single player character: Yes! I originally envisaged BotLG as a party-based RPG, but after some play testing, I’ve fallen back to a single character to speed things up, and I think it was the right decision.
  • Monsters are similar to players: Yes! They share the same attributes, skills and equipment as players, and use the same rules for movement and combat.
  • Tactical challenge: Not so much! BotLG is slightly more about the strategic long-game of refining equipment and skills over the course of multiple characters, and combat is abstracted thus that there are not many tactical decisions to make.
  • ASCII display: Nope! The game world is represented with graphical tiles, and I think it looks great.
  • Dungeons: Yes! Not just the traditional rooms and corridors, but also cave systems, overgrown forests, mountain passes, boggy swampland, etc. etc.
  • Numbers displayed up-front: Yes! There’s no secrets here. You can see all your attributes, item properties and damage numbers.

So is it a roguelike?

I think it is! A weird one, maybe, but definitely in the ballpark! More importantly, I’ve started to think of it as one, and it’s partially how I would describe it. It still has all of its initial idle/incremental features, so I’m thinking of it as an idle/incremental RPG with a roguelike world. That seems to cover all of the bases. It’s not a traditional roguelike by any stretch, but it certainly ticks enough of the boxes.

It does have some distinctly unroguelike elements. As you and the monsters/NPCs are wandering around the map, there’s no taking turns; everyone moves at the same time, so there’s no tactical tile-hopping and waiting. But that doesn’t matter, because combat is initiated only by the player deliberately “bumping” a monster, and combat is modal, so there aren’t any positional considerations. Because a big part of the game is idle/incremental gathering and crafting, I ruled that is was not important that monsters could attack you when they wanted to. It’s entirely possible to play out a character to the level cap as a pacifist gatherer/crafter, though you’d be missing out on a decent chunk of content– crafting some items requires components only obtainable through looting monsters. What’s important is that you could play the game this way, and when you eventually retire that pacifist crafter, you’ll get account-wide bonuses reflecting the life they lived.

Making a monster

I’m working on combat. It’s kind of slow going, because it’s the most involved part of the game, and it needs a lot of other structures and objects to be in place first. Not least of which are monsters. Thanks to an audience suggestion, I’ve started with skeletons, a classic 1 hit dice monster.

For that, I needed a way of creating new monsters, keeping each unique copy of them persistent in the database, and managing them. I also wanted a way of making sure that combat could occur between players-and-monsters, monsters-and-monsters, and players-and-players. I big part of the BONES of the LOST GOD setting is battling in the magical arena at Rooksfoot, so I need to support all those types of combat.

The easiest way to go about that is to make sure that both Monsters and Characters are interchangeable; Monsters should implement the same interface as Characters. Looking through the game ruleset I’m using, with a bit of fudging and the invention of some creative items (monsters will have to invisibly equip items like “dragon’s hide”, “dragon claws” and “scroll of dragon’s breath” to set their AC, damage output, etc.) I don’t see why that shouldn’t be possible. So after a bit of work and some refactoring, I now have some new factory and blueprint objects.

When I want to create a new type of monster, I just have to crack open my trusty Monster Manual, and create a corresponding new Blueprint. This defines the monster’s name, appearance, attributes and statistics, equipment, and so on. I can create permutations of the same monster by defining some methods in there to return different values each time.

Then when it’s time to spawn a monster into the world, I take the Blueprint and give it to the Factory object, which creates a new Character and applies the settings from the Blueprint, resulting in a brand-new character/monster saved to the database. In fact, it’s so nice and flexible that I named them NPC Factory/Blueprints; and I’ll be using them to generate townsfolk, quest givers and the like, as well as monsters. It’s also pleasing to me that everything that’s alive and active in the game world is stored away in the same place in the database. There’s some enumerated flags in there so I can tell PCs and NPCs apart at a glance, and it seems to work quite nicely.

(In theory, all this means monsters and NPCs could be recruitable as player characters, further down the line. It also means it’s trivial to turn or clone player characters into NPCs; which is how I intend to do asynchronous PvP combat — it’s almost like I had a plan for this all worked out!)

Last but not least, I’m changing the way Characters are attached to Users; instead of tying them directly to the user’s account as I’m doing currently, I’ll be introducing the concept of a Party; a container for a list of Characters. Having this intermediary step means I can write combat as an event that happens between two or more parties, without having to consider who owns the party; all the UI will have to do is allow the player a way to assign actions to their Characters instead of AI and combat will progress non-the-wiser. Actually writing the monster’s AI, though, is a task for another day.

Character and Item generation

I’ve been working on BONES of the LOST GOD’s Character and Item generation this week. First of all, here’s an example character, wearing a few items:

The stats rolled might look a little off if you’re used to Dungeons & Dragons‘ traditional 3-18 range. Instead, each ability score falls in the range 11-16, with lower numbers being much more prevalent. Ability bonuses scale much more linearly as well, with no dead spots, so getting an extra +1, even at the low end, should feel like a genuine improvement. It’s going to be a brutal game, but you’ll have a whole party of hapless heroes to use, and an infinite stream of fresh recruits, so the odds are still in your favour.

I’ve also got some encumbrance and quality ratings in there. Each item generated is unique (albeit built from templates), so I can track the durability of each item separately. Because your items can break, and you can’t carry an infinite amount of stuff, there’s some tactical decisions to be made before setting off into the wilderness. It also opens the door for having perishable items, field repair kits, and all sorts of other little mechanics.

You can have a play with the generator herelet me know if you manage to roll up someone cool! Both player characters and NPCs are going to be drawn from the same pool, so each time I need a NPC, or to populate a roster of potential new recruits, they’ll be coming from the characters created by this generator.

Next up I’ll be fleshing out the items a little more, and then having the game automatically generate a new party of characters for newly-registered players.

Scheduled Maintenance

My hosting provider, Linode, will be performing scheduled maintenance next Wednesday, October 23rd:

Recently, we identified a commit to the upstream Linux kernel as the cause of an increase in emergency maintenance on our platform. After implementing and gaining confidence in a fix, we are now ready to roll this update out to the remainder of our fleet. We’re confident this will resolve the bug and ultimately lessen the amount of unplanned maintenance for your Linodes as a result of this specific issue.

The server will unavailable from 2019-10-23 2:00:00 AM UTC, for up to two hours. Typically it’s much shorter than that, usually lasting around half an hour.