Item Variants and Randomization in Roguelikes

Most roguelikes apply some sort of randomization to their items, which makes a lot of sense for a genre focused on replayability. This can take the form of enchantments, prefixes, suffixes, or even randomized stats or different properties not necessarily reflected directly in an item’s name like the above list. The various possible combinations can really stack up and turn an otherwise limited pool of base items into a wider variety of interesting problem-solving tools, one that the player won’t usually have full access to in a single run.

The original Rogue offers the most basic set of possibilities, +/- modifiers on a base set of items, e.g. “+2, +1 mace” which has a +2 to-hit modifier and +1 damage, or “-1 plate mail” with its lower defense. Overall Rogue doesn’t really have many different item characteristics to modify or games systems to interact with, which is a primary limiting factor in the extent of randomization a game can support. (Items in Rogue may also be cursed and therefore non-removable except via special means, though that is a tangential mechanic tied more to the identification minigame rather than item randomization itself.) Still, with just a handful of tweakable variables Rogue provides a decent number of additional item variants, and that’s before further modification by the player via scrolls, or negative modifiers from enemies. You can read more about Rogue’s itemization here and here.

An inventory from Rogue, showing multiple item variants.

Many later roguelikes adopted the same numerical modifier-based approach to randomization, itself derived from pre-Rogue tabletop RPGs and often called “enchantments” in the context of roguelikes. NetHack, Angband, ADOM, Linley’s Dungeon Crawl… lots of big early roguelikes rely on enchantments as a core element of their item generation.

Of course most started to take it further.

Even Rogue’s first descendant, Moria, already took the next step of sometimes assigning an item a random property from a pool of possibilities, such as resistance against a particular damage type, to create more unique “ego items.”

A Moria inventory containing numerous ego items with various modifiers (this shot actually taken from the later C-port Umoria).

Moria’s descendant Angband also included ego items (over 100 properties), but expanded the concept of randomized items even further by adding the option to activate “Randomly Generated Artifacts,” abbreviated “randarts.” This replaces the game’s standard set of hand-crafted artifacts (“standarts”) with a separate set of procedurally generated artifact items that approximate the power level of those in the original set, while allowing them to become different types. This combined with Angband’s already large pool of base items (more than 500), enchantments, and ego modifiers, and there is quite a huge array of possibilities, making for a heavily loot-focused experience. It’s no surprise that Angband went on to have a heavy influence on Diablo’s design!

An Angband randart. That’s… uh… quite a lot of modifiers!

Linley’s successor DCSS is more or less the same, with options ranging from the typical enchantments, egos (separately called “brands” with respect to weapons), and a smaller number of randarts that combine multiple properties drawn from a decent-sized pool of possibilities.

A DCSS equipment list taken from the character overview screen, with representation from a good variety of variant categories.

Despite beginning development in the 90s and continuing off and on for the next couple decades, unlike some of its contemporaries ADOM did not add truly randomized items beyond the usual enchantments or ego-style modifications in the form of prefixes and suffixes. Perhaps one of the more unique aspects of ADOM here is that the degree of possible enchantments, among other properties, is tied to the material the item is composed of.

An ADOM equipment list with a large number of enchantment values, and including some different materials like crystal and eternium.

By comparison, in true Angband fashion the distant Angband descendant ToME 4 fully embraces randomized items and has quite the pool of possibilities.

A ToME 4 inventory sample with details for one of the items.

That said, certainly not all modern roguelikes follow the long-term trend towards increasing variability and randomness. Brogue is a good example of a streamlined roguelike that offers a lot of interesting gameplay centered around a core set of items modified only by pure enchantments and its own style of egos/brands called “runics.”

A Brogue inventory list including some enchantments and armor with a runic conferring immunity to enemies of the infernal type.

Randomized items tend to be a great feature in combination with permadeath, especially in those games where there isn’t much in the way of challenges outside taking on various enemies with whatever gear the player has at their disposal (i.e. the majority of roguelikes, especially classic ones). If every time it’s the same challenges at each depth with the same set of potential items, there are fewer and fewer unexpected encounters or unique situations to overcome that haven’t already been “solved” through previous experience. This is why many Angband players eventually activate the randarts option, to really mix it up. Then of course these items and their randomized capabilities can also do a good job of making the whole experience more exciting--ooh more shiny loot what is this YES THIS THING IS AWESOME!!!

Yeah so there’s definitely going to be junk in there, but also powerful and fun items as well (which inevitably cause to you get overconfident then die a horrible death :P)

Yet there are also some really nice roguelikes without any randomly modified items at all, not even basic enchantments, which ensure replayability through other means.

The Ground Gives Way is one of the best examples, where instead of offering randomized items it has an absolutely huge number of handcrafted items with varying rarities. A single run also doesn’t take too long (1~2 hours), so players have a chance to quickly start finding items they’ve never seen before, or only rarely, even after becoming pretty familiar with the game.

A TGGW inventory/equipment list.

Some items can also be transformed through external means, such as being cooked, coated, rusted, or upgraded by NPC services (one of the main uses for gold).

A TGGW enchanter offering their services. Other types of NPCs can modify or convert other types of items.

While randomized items help add to the “dynamic” nature of a roguelike experience, there are other ways to achieve a similar result, by moving beyond items, the player character and other creatures. Classic roguelikes don’t tend to do much of this (traps occupying a single space are a very minor example), but we’re seeing more and more of it in modern specimens. This is another area TGGW reduces its reliance on randomized items to create interesting/beneficial/detrimental scenarios, by offloading some of that work onto the environment itself. Standing at certain locations, or in certain rooms, might have various benefits or drawbacks, either due to environmental features themselves or because certain weapons are more or less effective depending on the immediate surroundings.

Nothing like some open lava to accidentally fall into when confused! Or knock an enemy into. There’s also a valve elsewhere on the map which could perhaps flood the area, and the “open melee” status listed at the bottom right affects the effectiveness of certain types of weapons due to where @ is standing.

Despite its relatively small item pool and low emphasis on random variants, Brogue has an even greater emphasis on terrain factors that really help support the dynamic gameplay in a way that keeps repeated runs interesting.

Brogue’s trippy colors come from impactful terrain features like water, lava, and gases.

Cogmind fits more on this end of the spectrum, with a decent chunk of its dynamicity coming from external non-item factors including special encounters and events, enemies that work together at a higher level, interactive machines, highly destructible terrain, traps that cover a wider area, hidden corridors used by hostiles, etc.

Certainly many of those aspects are also simply an important part of building a living world heavy on immersion, but in terms of pure mechanical design they also supplement replayability in ways that items will not, because yep, all of Cogmind’s items are static.

Cogmind’s Strictly Static Items

Having been in development for so long, and being a bit of a genre outlier in that there aren’t any randomized items (not even simple enchantment-like modifiers), more than one Cogmind player has suggested adding what is at this point almost a roguelike staple. But items being static is of fundamental importance to the design, for many reasons:

• Familiarity -- Building familiarity with all the specific items and their capabilities across multiple runs helps immensely with planning or even just quickly putting together a balanced build from piles of scrap. Simply seeing an item’s name let’s the experienced player know whether it’s something they can immediately put to good use, maybe save for later, or ignore entirely. Eventually a lot of time is saved by not having to always be opening the info for each item to learn about it, and recall that temporarily applicable info if and when it’s in use or being carried for potential use. This aspect doesn’t matter as much in games with fewer items, or fewer items in use at once, but there are always a ton of items available in a given area in Cogmind because all actors are composed of them, plus those just found in the environment.
• Turnover -- Cogmind involves plenty of replacing lost gear, upgrading to better items, and swapping tools for different situations--equipment/inventory management is a bigger part of the gameplay than in almost any other roguelike (so much so that many UI features are built to facilitate this process). This is a function of being designed around destructible parts (items) and a relatively fast-paced progression system, and as such it would be unfortunate to require players to frequently read and reread the info for a bunch of random items with unique properties (à la randarts), especially when they may not even be around for long. Compared to Cogmind, other roguelikes tend to have more static loadouts, or equipment that the player themself gradually improves over time, maintaining familiarity the entire way, for example using only a few different weapons across an entire run instead of the many dozens in a typical Cogmind combat run (and that’s just weapons!). Yeah with static items we lose the thrill of finding great uniques, or laughing at the ridiculous ones, but we can get those thrills in other ways :)
• Balance -- Salvaging other robots is an important source of items, and they need to have balanced builds based on the same items that Cogmind can use. Doing a proper job of this requires static characteristics, which also further ties into player strategy since you then know where or how to acquire many specific useful items (wherever the associated types of robots operate), enabling both short- and long-term planning of a different nature than what’s found in other roguelikes. Low on treads or armor? Find a nearby Sentry. Need a Recalibrator? Find a Mechanic who may be hanging around a Repair Station. And so on. Being able to shore up a messy build, or round out a good one, doesn’t generally come down to raw luck as much as it does being familiar with where to source the right parts at the right time.

So by design we clearly want to go with static items, but as mentioned before with TGGW, we can enhance replayability and partially make up for the lack of randomized items via pure quantity. With already over 1,000 items (and always more coming!), there’s a lot to find in Cogmind.

The art for about 800 of Cogmind’s items, shrunk to fit them in a reasonable space :P

(I don’t want to veer too far off topic here, but it’s worth mentioning that items in Cogmind are divided into core items and special uniques or rare items that are more difficult to acquire, with the core category rebalanced and finalized in the previous Beta 11 overhaul to ensure the foundation is solid before we start getting a lot more of the latter which are great for contributing to the fun and surprise factor while unlocking yet more interesting play possibilities.)

We’ve hit 2k words at this point, which is a whole lotta words to say most roguelikes have randomized items while Cogmind’s items are static and that can be a good thing, too…

Well… time for an experiment.

Randomized Items in My Cogmind?!

I guess as I write this article the “experiment” is just about coming to a conclusion (a success?!), an experiment to see how randomized items might work in Cogmind. What form could they take? Would they be fun? Create interesting situations?

Now of course I wouldn’t go as far as to undermine the fundamental design and make this a widespread feature, but as I was working on Beta 12 an opportunity presented itself to make this an isolated special mechanic, and, though very doubtful at first, I was pretty interested in seeing if it was even possible.

The first roadblock actually has nothing to do with game design at all, but architecture. After all, it’s not likely that a code base assuming items are static throughout a decade of development would be able to feasibly support randomized items!

Normally at startup Cogmind loads all the game data, including item stats, and references it during play. As with most games, each “instance” of an item (for example each Assault Rifle you have attached, or in inventory, or on the ground) does not store a complete set of stats. Instead, it only stores a subset of values that might change, like its current/remaining integrity, because they all have the same max integrity and we don’t need each of them storing that separately, right? For that value we can just check the reference data, since it doesn’t change anyway.

An excerpt from the file containing static item definitions (values not necessarily accurate anymore since I originally shared this image elsewhere seven years ago, but you get the idea :P).

Item instances only storing a small amount of variable data is a pretty clear obstacle to giving items unique randomized stats. The solution which will require minimal changes elsewhere in the game is to reserve a number of slots in the item reference data and allow them to be modified as well. This theoretically would enable randomized items to work pretty much seamlessly as far as the rest of the architecture goes, but naturally comes with its own limitations. Modifying underlying reference data simultaneously modifies every instance of the given item, regardless of where they are, so to take advantage of this relatively seamless approach we’re going to have to limit randomized items to a reasonable scope:

• Only Cogmind can use them. This keeps the total number down, saving resources and preventing the internals (and really the overall design) from becoming a complicated mess.
• Randomized items must start equipped and cannot be removed without destroying them. This prevents them from existing in the wild where they could easily multiply (assuming these things are created dynamically, which will be the plan going forward). Designwise this limitation has other significant advantages anyway, in terms of balance and otherwise preventing potentially tedious play or confusion.

So we’ll have to enforce a cap on the number of such items allowed, but in exchange gain the ability to modify any underlying value of an item instance, in real time. For this purpose a number of placeholder entries are added to the item reference data.

Randomizable placeholder weapon data entries as they appear listed in the static item data file.

Of course, since we have items which can change on a runwise basis, likely even multiple times during the same run, the originally “static data” for these items must also be recorded as part of a player save file. In the past we could just use freshly loaded item data each time the game starts, but now some of those entries might be overwritten by whatever is in the save file if continuing an earlier run. (There’s quite a lot of static item data and not all of it is needed for randomized items, so while trying not to record more of it than necessary, yeah there were a few funny/weird bugs coming from getting this right while building and testing the system…)

Some relevant statistics to give a better idea of the amount of data of each type:

• Variables unique to each normal item instance: 17
• Static data values stored for reference by all instances of a given item: 100
• Data values saved for randomized items in otherwise static item data: 47

So randomized items might change up to about half of the data that is normally static, and instead of an item instance being defined by up to 17 unique variables, for randomized item instances that number increases to 64 (17+47).

Where are these randomized items going to come from? Next time we’ll introduce the Scrap Engine…