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.

Mapping BotLG

It’s October now, so that means NaMuBuMo is upon us! This seems like a perfect excuse to take some time to plot out the world of BONES of the LOST GOD; luckily, I have some geography already, from it’s first incarnation as a play by mail game. I’ve started a Twine project to help with the mapping, more for the editor’s layout and connection tools:

There’s a lot more stuff in Rooksfoot that needs adding — the forge-shrine to Phaestus, Myxile’s Menagerie, the various Guild Houses, the offices of the Statistique, the Temple of Anama, the Halls of the Stone-Blood Fists, Froome’s the chemists, Wilson & Co., (a cheese shop of some good standing), and I’m sure a bunch of other places that got mentioned once in passing.

That’s great and all — Rooksfoot is the main hub location after all — but it’s also a little daunting given that BotLG is now a lot more graphical, with each location having a couple of sentences of description, but more significantly, a tiled map to explore (complete with fog of war and line of sight). I’ve made a start on a graphical map editor, and, while not strictly in the spirit of NaMuBuMo, I’ll be using some time this month to also work on that.

I can lean on some procedural generation to create some of the maps — the forests, for example, and some of the more dungeon-like content (like the Rat’s Nest, and the eventual procedural dungeon beneath The Skull), but I think much of the city will end up being hand-made. I’m thinking I can use a traditional dungeon generator to dig out room shapes, and then re-connect them with wider passageways and hand-decorate them to produce some sections of the city; but to really do justice to some of the more “iconic” locations, like the ribcage arena, I’ll be making those from scratch.

A few new sprites

I’ve been doing some edits to Quale’s Scroll-o-Sprites to create some new creatures, I’m particularly pleased with the cat wizard and horse soldier. The bear-man is also kind of interesting; it makes me wonder if I could eventually come up with something to represent an owlbear.

I’m thinking of chopping the sprite sheet up further into heads and bodies, to see if I can create something like the system Pokemon Fusion uses, but that’s a job for another day.

Upcoming game jams

There are two game jam events coming up in the next couple of months that are of distinct interest to me. Next month, the Mud Coder’s Guild are holding a month-long jam in association with the folks at Written Realms, the first National Mud Building Month (or namubumo, if you’d rather).

NaMuBuMo challenges you to create 100 MUD rooms (or substantive locations) in 31 days, mirroring the long-running NaNoWriMo novel-writing challenge:

Writing up 100 rooms in 31 days doesn’t sound quite as daunting as 50,000 words over 30 days but making an interesting world in those 100 rooms (or more) within that month will be more challenging than one might suspect. Like NaNoWriMo participants are expected to craft this world within the confines of the given month, concept to completion. There is no one holding you to that or any other rule but yourself, of course, and there is nothing to gain other than personal satisfaction.

Secondly, November will bring 2019’s Procjam. It’s always a great event:

The goal is to Make Something That Makes Something – that could be a videogame with procedural generation in, or maybe an artwork that uses generative systems somehow, or a physical card deck that randomly creates Shakespeare plots – whatever you like, whatever makes you excited to make things. As usual, we encourage you to make it your own by starting early, finishing late, or adapting the times to make it healthier for you. We can’t wait to see what you’ll make!

This year’s announcement post from long-time organiser Mike Cook contains some further news; after this year he’ll be stepping down and is looking for volunteers to take over the reins.

Pathfinding, redux

This evening I got pathfinding working around a larger, scrolling map. I thought this would be best demonstrated in motion, so here’s a little YouTube video of it in action:

I had to turn the sprites down to 32×32 from 64×64, as the view seemed too claustrophobic that zoomed in. This has some unfortunate knock-on effects for the mobile client — I think at 32×32 the tiles will be too small to accurately tap on — but I’ll tackle that another day.

What makes “Clicker Games” good?

Here’s a nice little YouTube video from RealityEscape on what makes a clicker game good:

Just in case the name didn’t give it away, Bones of the Idle has a strong idle/clicker component. When you’re gathering materials

There’s a few points raised that I want to briefly talk about in the context of Bones‘ design:

Ascension

I kind of have a system in mind for “ascension”, whereby players will be able to retire characters in exchange for a regular offline income. You get to start over with a new character, and every day you’ll receive some income and items based on all your retired character’s skills. Potentially these retirees will appear in the game as NPCs.

Autoclickers and scripting

I don’t care, in general. The client is written in Javascript and executed in the browser, so there’s only so much I can do to stop people using the developer console to script things. All the important stuff is server-side and validated there, but there’ll still be little shortcuts dedicated students of Javascript could uncover. I just have to minimise what scripters can get away with, and try not to sweat the small stuff.

Monetisation

Bones of the Idle is free to play, and there’s no adverts. It’s also not going to be nagging you to spend money. However, my time has value, and I’m not adverse to money. I set up a Ko-fi page here, where people can chip in with donations if they feel the game is worth it.

If I ever add anything resembling micro transactions — in general I have no issues with them, when done well — I’d have them be ethical, not lootboxes, and definitely not pay-to-win.

Point of view

Last night was the inaugural meeting of my new after school study club, and it was a very cosy, pleasant experience. We went around the table and talked about our various works-in-progress, discussed the merits of various database/model frameworks, and eventually settled down to work on our individual projects.

I spent the time getting field-of-view and fog-of-war working in Bones of the Idle. I already had some code from an earlier JS roguelike project to hand, so with a bit of refactoring I was able to slot that into place:

There is nothing insignificant in the world. It all depends on the point of view” — Goethe

The darker areas around the edges represent tiles the player has seen before, but currently cannot see (fog of war), with brighter tiles they can currently see surrounding them. As you can see, their field of view isn’t a perfect circle, as it’s being obscured by the nearby trees.

Now that the player can be placed on the map (which in turn can be larger than the view port, a new feature over the previous code base), the next obvious step is to re-implement pathfinding and get them moving around and scrolling. I still want that to be verified server-side, so again I’m hoping to take the existing code I already have, give it a polish, and drop it in place.

Aesthetics

I spent a bit of time last night working on the new look for Bones of the Idle. I’ve been on a bit of a lo-fi vaporwave kick at the moment, and seeing how much of the game is supposed to evoke a kind of wistful nostalgia for late 80s/early 90s BBS door games like Legend of the Red Dragon (1989) and classic ASCII roguelikes (Rogue, 1980), as well as early pixel art gems from the 8-bit eras of the Spectrum and Commodore 64, vaporwave seemed like a good fit.

Some vaporwave discussion on YouTube

Prototyping

I prototyped some UI elements like simple buttons, basic form elements, overlays and popup boxes, and ended up implementing them on the main home screen, which I think looks pretty good now:

It’s aggressively neon, the green glows in a totally tacky way, and I’m mixing green and pink in a way that shouldn’t exist in nature. In short, I’m pretty pleased with it.

I’ll be sticking mainly with this colour palette (top row), which I think most would consider to be canonically vaporwave, but I’ll also be experimenting with the colours on the bottom row, which are the 180° hue-rotated compliments. In theory they should compliment each other well (if used sparingly), but I’m no designer or colour theorist. I’m pretty confident in my skills for the more technical aspects of getting this game built, but the look and feel of it is something I’m really going to have to work at and pay close attention to.