next »

[Kyzrati]

(...continued from previous post)

Clocks
From early on I always wanted to make sure Cogmind had sufficient food clocks, although as the world expanded in the time since, I've added a few areas in which there is no clock for whatever reason. For a while I've planned to eventually address these as opportunities present themselves.

That's not to say we need incredibly tight clocks--Cogmind clocks are lenient enough to offer plenty of flexibility to allow for different play styles, but assigning some explicit value to time by giving it a mechanical impact is good for balance in a goal-oriented roguelike like Cogmind (as opposed to a sandbox), otherwise any number of weird player strategies might start to emerge as they take advantage the inevitable design cracks in a complex web of systems that can start to break down when you have unlimited time to poke at them in a single run. While some players enjoy puzzling out creative ways to get ahead, at the extreme end it eventually devolves into optimal tedium which is overall harmful to the experience. I wrote about this factor in my recent article on game design philosophy.

Garrisons originally had their own clock whereby the alert level gradually rises over time (as opposed to the usual decay or at least remaining neutral), thus overstaying in a single Garrison could have a negative impact on the following map.

As one of its perks, RIF-aligned builds were not affected by this type of ambient alert increase, which made Garrisons a lot safer for those players. But RIF has since gotten a lot more powerful in its own right, with even more benefits to come in Beta 12, so we really do need to consider a clock that applies to everyone, and seeing as we're building Garrisons 2.0 here, of course it makes sense to do that now as part of the new design!

At the same time, the original alert increases for non-RIF builds were a bit too punishing for players to seriously consider these maps as part of their route, so I didn't want to simply say "okay RIF isn't immune anymore."

Initially I approached this as an opportunity to come up with some new type of clock. Over the years I've been adding more unique clocks as part of different kinds of challenges in Cogmind, so maybe there was something suitable for Garrisons as well? Some concepts:

• More enemies could show up? Okay so that's not a new concept, and kinda used generally throughout Cogmind for both clock and non-clock responses, so nothing special there and even kinda repetitive, not to mention it invites farming anyway.
• Sterilization is another option, the floorwide response to farming on some other maps, slowly raising the ambient temperature to eventually melt anything that doesn't evacuate. I've already reused a slightly altered version of this in the new DSF maps, and balance-wise don't find it suitable for Garrisons anyway.
• Probably the most interesting and unique possibility I considered is eventually permanently sealing each of the Garrison exits one by one, until eventually there is absolutely no way out and you are trapped and lose the run! This is less harsh than it might sound at first, since the closing escape window would be clearly telegraphed to the player along with sufficient time to leave, and unlike other floors the exit locations are not exactly hard to find (they're all in predictable locations with mostly predictable paths to reach them). That said, if someone were to actually lose that way for some reason it would feel kinda bad, plus (unless the mechanics get even more complicated than that) it's a very hard cap on time, whereas flexible clocks are generally more desirable than brick walls where possible!

So, uh, what's a flexible mechanic that ties into a bunch of other mechanics already? ...alert level xD

Yeah we'll just do that, only this time we'll tweak it differently!

Alert still increases naturally over time while inside a Garrison, but it will be much more lenient for a while, then eventually the rate begins to quickly ramp up, before plateauing. Mind you, the rate of increase plateaus, not the alert, so you generally don't want to hang around too long once it starts ramping up, but the option is there if you need a little more time, depending on what is acceptable given the circumstances.

Ambient alert accumulation inside a Garrison begins from turn 1200, though remember the alert depicted here is purely from being inside the Garrison, excluding any other alert resulting from actions within, like... blasting everything :)

The numbers used are based on a wealth of player run stats, in combination with the desired balance for these new Garrisons. The time required to full clear will generally push alert quite high, but is technically still achievable and not unreasonable if that's something the player wants to do, while the option to bail early is always available.

Note that while RIF builds no longer immediately benefit from simply being RIF builds in this scenario, by design that play style comes with more tools for controlling alert, so at least retains some indirect benefit.


Balance
With all these new encounters, the average content density inside Garrisons just shot up. However, I don't think higher density itself has a significant impact on difficulty, which would be the main concern. Garrison map flow remains unchanged from before, with all exits directly accessible from the center via four spokes, and encounter rooms are either further out towards the edges, or at least off the beaten path, meaning they can usually be avoided if desired, serving mostly as optional areas for the player to investigate based on their own risk-reward tolerance.

The added variety no doubt makes Garrisons more interesting and fun to explore, but also introduces new design challenges. Encounters now make up at least half of their content, including many of the potential benefits (even the holy grail itself, the RIF Installer!), but many of these extra rooms are hidden behind one or maybe even two layers of phase walls which not all players are equipped to detect. This can make exploring a Garrison very problematic, even unfun. In theory it could be optimal to destroy all the walls in a search for hidden paths (especially with Beta 11 when there was no clock adding at least some time pressure), assuming one is willing to pay the alert cost for the collateral damage.

To help alleviate this I added a guaranteed Terminal embedded in the wall of a random main corridor, a Terminal that lists the "Access(Emergency)" hack which reveals all hidden doors and phase walls across the entire map (expanded behavior beyond its normal effect).

Access(Emergency) inside a Garrison is quite revealing...

So simply exploring the main areas of the Garrison will eventually lead to discovering this Terminal, which offers a pretty good chance of marking all the hidden paths, but first you have to find it.

Failing that (gets blasted in a fight? hacking attempts unsuccessful?), one of the potential "encounters" is another Terminal nook containing a new "Download(Registry)" hack with an even more extreme effect, revealing all terrain, security locations, and even item caches.

Download(Registry) is even more revealing! If available, that is.

But it's not a guaranteed find, and being an encounter itself there is a chance it's not easily accessible, either (it has no door of its own, but the area selected for it may otherwise not be directly linked to a main corridor).

So that's just one possible option. The reason these options are more important inside Garrisons is because a number of typical sensor types are blocked, which is where the costly backup approach comes in: Destroying the Phase Generator eliminates the blocking (at the cost of raising alert further), and also opens all the phase walls, making it easier to explore freely. There's usually (but not always) at least one Phase Generator in a Garrison, and it can often be found through natural exploration since it's designed to be heard through phase walls that lead to it.


RIF Installers (again!)
Any RIF build visiting a Garrison is itching to find this thing ASAP. More abilities? Yes, please! (In fact, I even added a new ability for Beta 12 so we're up to 16 now, 7 of which have multiple levels.)

It used to be fairly easy to find--if it's not adjacent to your starting position, follow the spokes to each of the three exits and it'll be at one of those, but now that Installer placement has been merged with the encounter system it could be anywhere! Including of course outlying hidden areas (see the image from earlier for one such example). That's a problem.

Forcing some players to repeatedly full clear Garrisons to ensure they find these is excessive, so I added a new mechanic to help out: Once a player has installed the RIF system, getting anywhere near other Installers will automatically ping them, revealing their precise location.

There it is! Now to find the entrance...

There is precedent for this behavior, since RIF-capable builds already similarly ping nearby Garrison Access points elsewhere in Complex 0b10, and adding this feature elegantly solves the "where the hell is the Installer?!" issue. In fact, it could even be considered more interesting than the predictable locations used before, since the new randomized locations might require a bit more exploration to uncover, as well as figuring out how to reach the Installer once discovered. That while making sure it's not damaged in the process, since who knows what else is lurking around...

Incidentally damaged RIF Installers (:O) will no doubt be more common in Beta 12, though there are balance factors at play here, too:

• A single Garrison may contain more than one RIF Installer. That's pretty exciting news for RIF users, though it's worth being cautious since the second potential installer may be trapped or defended!
• Looping back to a main floor through one other particular new encounter for a shot at another Garrison (and its Installer(s)) at the same depth is a possibility. This is different from normal exits in that it always loops, regardless of where the other exits lead.

Overall the average total ability count across an entire run will likely be higher than before among players who want to optimize for it.

Installer-rich environment detected!

Non-RIF Builds
RIF this, RIF that... but as I stated at the beginning, one of the goals here is to give more non-RIF builds good reasons to visit Garrisons as well!

I think the update manages to deliver on this point, and we'll see other builds Garrison diving at least some of the time, as a part of existing strategies or even entirely new ones. Advantages include:

• Out-of-depth parts, often significantly so.
• Other situationally useful rewards such as large numbers of traps or Authchips. Also allies, sometimes pretty effective ones.
• Unique intel. Among the new Terminals added to Garrisons, we also have new hacks enabling the download of patrol navigation and security data for the next map, intel which can be quite useful given its scope.
• Then there's the really big one, an entirely new meta mechanic spanning many areas of the game with significant strategic impacts outside Garrisons and even into extended, but requiring Garrison visits to trigger and... nurture. Almost sounds like RIF, but by design the two are actually mutually exclusive options, so I look forward to seeing who uses it, and when and how. Writing about this new feature could be a whole new article topic on its own, but given that it's steeped in lore and is one of those things meant for people to uncover naturally, I won't go into any details here. Let's just say it's neat, and it's useful. I'll almost certainly be streaming it at some point though, so that would be one way to learn about it from me, aside from the usual places in the community.

These advantages exist on top of the original beneficial side effect of passing through a Garrison, whereby looping back to the same depth reduces the size of all patrols (while you have your chance to harvest more resources? find an elusive branch?).

Hm, what's this?

Events
While encounters help flesh out the general Garrison experience, there is another potential layer on top of that to further shake things up: Events.

Events are not all that frequent, but when they do occur have a map-wide impact. These are various faction-level activities that might be beneficial for the player, or add some new danger, or something in between.

For spoiler reasons I won't say more about these, other than to point out that from a design perspective it's nice to have this extra layer so that once players are familiar with the individual encounters possible in a Garrison, and come up with localized strategies for those, there's always the chance for something to come along and change the strategic equation in a bigger way.

In other words, events contribute to avoiding the "flat" experience of simply moving from point A to B, dealing with whatever challenges lie at the destination, then the next one beyond that.

Technically we have encounters that when close enough to one another might bleed into each other due to an alarm trap, untimely patrol, call for reinforcements, Terminal trace investigation, or... accidental retreat in the wrong direction? :P

And this approach is reflected throughout Cogmind's other maps as patrol routes change, units carry out unique duties across different areas, and yet others are dispatched to react to something far away (dungeon environments can be about as dynamic as an open world!), but Garrisons are smaller maps with fewer macro systems at play, so it helps to add that extra layer of potential content to mix it up. For the same reason, DSFs (even smaller and simpler than Garrisons) also have the occasional event.

This sort of mutlilayered approach is also really useful for emphasizing the lore, taking advantage of another dimension to bring the world to life. It's not just "Cogmind vs. the world," it's "Cogmind happens to occupy this world alongside many other actors with their own goals, friends, and enemies."

Again these events are uncommon, since we still want most Garrisons to be focused around their encounter content and balance, as opposed to events which generally take over the entire floor and make it into something quite different. As I have it set now, there is a 60% chance of having a single event across a full run that visits a Garrison at every single depth, and a 10% chance of having two. 30% of seeds have no Garrison event at all, regardless of how many are visited. Events are special!

[Kyzrati]

Item Variants and Randomization in Roguelikes
[Cross-posted from the devblog here--follow link for better formatting and light-on-dark style.]

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.

(continued in next post...)

[Kyzrati]

(...continued from previous post)

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...

[KorbohneD]

Dang, that was a really interested article about randomized items! Thanks for that
Also, thanks to you I started playing Brogue, which is pretty cool!
I am looking forward to your game now!

[Kyzrati]

Thanks! I thought it was a pretty important and relevant topic to cover about roguelikes in general, and in addition to the bits I already knew thought it'd be worth diving deeper for a little extra research over a couple days to supplement the main idea. Interesting to see it branching out over the decades

Brogue is a neat one, have fun!

[Kyzrati]

The Scrap Engine
[Cross-posted from the devblog here--follow link for better formatting and light-on-dark style.]

Last time I wrote about item variants and randomization in roguelikes, and how Cogmind is purely based on a large set of static items, but more recently I've been running an experiment to play with not-so-static items. The entire mechanic revolves around a single new utility: the Scrap Engine.

A new utility is born.

The Scrap Engine operates like the Field Recycling Unit in that in addition to the normal inactive and active states it can also be cycled to COLLECT mode, during which it will "eat" items at the current location. These items are presumed to be disassembled and added to the Engine's resources in order to be mixed with others and reassembled into new "constructs," the name for a new category of randomized items. Instead of creating new ones it can also use these resources to modify existing constructs. Although in both cases the results are indeed based on the inputs, the process is not deterministic, so it's not a pure "crafting" mechanic in that sense.

Constructs can be power sources, propulsion, or weapons. Utilities are generally defined almost exclusively by their effect and its degree, and due to the architecture (that again!) cannot even combine effects (this one is most definitely impossible in Cogmind, unlike the workarounds that enabled randomizable item stats without too much trouble), so no utility constructs, but in the end this is probably for the better due to number of other reasons I won't get into here.

I was really unsure any of this would work at all, since internally it's quite complex and therefore hard to gauge what outcomes are possible and whether they'd really fit into Cogmind, which has a pretty strong focus on design balance. In fact, I was unsure throughout the entirety of building the system, which made it rather challenging to work up the motivation to power through a lot of what needed to be done (I normally need to see a clear goal to help with that!).

As with building any complex system, I took the safer route of starting simple, using power constructs as a first test case since they involve the smallest number of variables. Of course that might make them a little less representative of the kind of system we'd need later, and therefore require more changes down the road (spoiler alert: it did :P), but at least it would be easier to wrap my head around this crazy feature while working on the building blocks.

Creating a construct and modifying one are two rather different processes.


Construct Creation
Construct creation requires multiple unique items as input, which is both more interesting and makes more sense since we're trying to create something new but based on existing parts (which comes in handy as a baseline for proper balance!).

The first iteration simply averaged together the stats of all the input items. This might seem deterministic, though wasn't necessarily easy to control since the Scrap Engine requires multiple different items to be loaded as resources, but might only use some of those to create a new construct.

Still, simply averaging stats could be more predictable than I wanted, not to mention generated less interesting results by creating items which were basically "neither this nor that" without much chance for real unique qualities that stand out, so I later changed this process to also have a chance to completely ignore a particular input source for the purposes of a single stat calculation.

An example of a new power source created when the Scrap Engine combined a Reinforced Fission Core with a Hybrid Antimatter Reactor, showing the stats of both items alongside those of the resulting construct. Mass, integrity and heat generation values are more or less averages, but fortunately here the hybrid power's lower energy supply did not factor in, while the total storage capacity was increased.

As you can see it also generates a new name for the item, which can be fun and sort of hint at where it came from, or in some cases its functionality. More on naming later.


Construct Modification
Despite the added randomization, new constructs are not going to be amazingly unique items, for sure, or where the system shines. Modifying constructs is where things start to get crazy.

Like creation, modification generally requires having multiple unique input parts available among the Scrap Engine's resources. However, the more varied results of modification stem from two primary factors:

• Only some individual stats or properties are chosen to be modified, leaving others unchanged. This can result in much wilder combinations not seen in any of the handcrafted static items.
• Having a greater number of slots occupied by constructs increases the power of buffs, and also decreases the effects of debuffs.

Taking our "Antimatter-Fission Reactor" created before and modifying it with another mid-game reactor that has some significant benefits but also drawbacks to balance them ends up doing nothing to our construct but giving it a much better power supply rate without the drawbacks of the original (which itself has zero storage capacity and is rather heavy). Of course this "Fission-Heavy Reactor" could have turned out much worse if only the negatives were applied, or more middling if multiple stats were modified at once.

While eating certain items gives the player a decent amount of control over what to expect from an initial construct's creation, that control is decidedly more limited during modification, which is where things get interesting. Controlling the general direction of modification is still possible, given experience with the system, but it's an overall swingy process that can make a build quite powerful for a time, only to eventually become weaker later on.

Playing this somewhat chaotic style is akin to riding a wave of power, working to creatively survive the downturns to rise again and crush the opposition. In that way it's actually quite similar to Cogmind's general premise, losing parts only to rebuild and come back stronger, but for experienced players the troughs of those waves are not usually as deep due to superior tactics and strategy, whereas a construct-based play style will force most runs to ride those waves both deep and high.

No these things are totally not held together using duct tape, regardless of what duct tape Dave here says! (Sketch by Zyalin, a throwback to the old piece featuring a derelict perched atop giant makeshift legs.)

Multislot Constructs
To maintain balance, multislot items used to create or modify constructs have their stats divided by their number of slots, so their "multislotness" is not a property they can transfer normally. Instead, each time a construct is modified it has a chance to expand in size, with that chance falling the larger it grows.

In fact, power and propulsion constructs can only grow in order to increase their effectiveness--having more than one at a time is not possible. This was a very early decision in the design process when I realized that possessing too many unique constructs at once would lead to the same issues I described as potential negatives of having a randart-like system of numerous variables to be familiar with mixed with Cogmind's gameplay of frequently changing parts.

It'd be fine if there were only a few such equipment slots, but in theory player builds will eventually top out at 12~15 construct slots, which is a lot of items with procedurally shifting stats to keep track of. Too many. Then there's also the issue of having to ensure propulsion is of the same type for it to be usable simultaneously, which would be a lot crazier if they're all individual constructs that are changing left and right, and there isn't even control over which of them undergoes modification. (Hybrid propulsion styles are already possible through the construct system of stat merging, anyway, even if it's just combined into a single construct.)

Basically there's no reason to add all that extra complication, so multislot power and propulsion it is.

Hm, fast and tanky?! This screenshot is from a recent run of mine plowing through Armory with a treaded exoskeleton moving at a good clip (84!) due to being boosted with a bunch of combat hover units.

Weapon constructs can expand, because multislot weapons are cool, but more than one is possible and even sometimes desirable, both for handling different scenarios and also to allow a construct build to tweak its weapons looking for better candidates to retain and improve (sometimes they can get so ineffective it might be smart to start one over?). Plus some tactics work better with numerous weapons.

This two-slot cannon construct carried me through a couple floors in my last stream. Five projectiles, all with respectable damage and 9% blast crit?! The main drawback is clearly the massive heat generation, which had me running multiple cooling systems and/or injectors, and still sometimes backing off from larger fights to cool down. But it sure shined when something needed to die fast, especially with a Kinecellerator attached :D

As usual the player can always choose to not evolve extra slots of a certain type, or use non-construct parts to block slots they don't want constructs to use either for creation or expansion.


Construct-Related Mechanics
Aside from multislot expansion there are actually quite a few nuances to the design that were required to keep constructs fun and balanced...

• As mentioned before, having more constructs results in better mods. This reflects the concept that all such parts are interconnected with the Scrap Engine and other constructs.
• For that reason, removing (or even just losing) a construct also damages the Scrap Engine itself! This puts a cap on what could otherwise be a cycle of tedium by repeatedly eating items and modifying constructs seeking better results.
• Fortunately the Scrap Engine can transform into an armored version of itself by eating armor (so there is a use for some utilities in here, after all!), and also repair itself by eating more armor in that state. This mechanic is vital since the entire build revolves around this utility so it needs to be maintained throughout an entire run! If the armored version is eventually "destroyed," it reverts to the normal version, giving more opportunity to armor it up again.

All armored up!

• Constructs themselves can also be repaired, a side effect of any modification (35% of max integrity each time), and having constructs eventually take damage is inevitable, so construct evolution is in turn inevitable due to the repair/modification process. This reinforces the "chaotic wave of power" design described earlier.
• Like the armored Scrap Engine reverting to its unarmored version, "destroyed" multislot constructs are not fully destroyed! Instead the construct loses a slot and turns into a smaller version of itself. This is an especially important factor with regard to power and propulsion constructs, which can only improve by growing, since otherwise there's the chance to suddenly lose all propulsion at once and a need be ready for that at all times, a huge drain on resources. Cogmind part losses need to happen gradually so there is ample opportunity to recover or change tactics before the situation gets even worse.

A powerful 3-slot cannon is shown here in the log being reduced to a 2-slot cannon, so you don't completely lose your primary source of firepower that might have been carefully "crafted" over time. The replacement is somewhat damaged as well, but it's better than being totally gone!

• Constructs gain immunity to effects that can otherwise outright remove parts, such as severing or thievery, since good constructs are hard enough to build and maintain as is, so losing one in this way would be pretty devastating.
• Construct weapons are also immune to misfires caused by system corruption, since that would be unnecessarily unfair since they can't safely be removed in situations where misfiring would have potentially disastrous consequences.

Strategy
Having playtested this new mechanic for a while, I've found that it comes with many interesting new strategic considerations, a whole new play style which can be both fun and challenging in its own ways.

Like when to leave some slots empty for a chance to grow an existing construct, since in multislot form they gain a further bonus to their stats as per the normal rules of handcrafted multislot items to make up for their other drawbacks.

Or thinking about when and what to eat, when to create new constructs, or try to modify some, or hold off completely and have the Scrap Engine save its resources for later (leave it off), or even store some resources separately in inventory in order to feed it later as part of a lone batch.

There's also the balancing of such a build's constructs and the benefits they bring (especially in greater numbers) against the use of normal items, which are swappable... and predictable :P. How many slots to devote to utilities vs. construct-supporting slot types? The former don't contribute to construct effectiveness, but are the most versatile slot and useful for any build. Also there's the fact that the Scrap Engine itself occupies two of those utility slots.

Should one evolve or reserve an extra non-construct weapon slot for swapping potential? On that note, one aspect not yet mentioned is that weapon constructs are only built from guns and cannons, thus excluding launchers and special or melee weapons. The latter categories are excluded from the construct system for having too few relevant variables or results that wouldn't balance properly, but as normal parts they can still be quite useful during most runs so leaving room for swapping one in might be important depending on strategy or preference.


QoL/UI Features
Any big new feature is likely to need some UI love, so for proper testing including game feel and convenience I added a few new relevant interface bits.

One useful behavior is to highlight all edible items while the Scrap Engine is in COLLECT mode by intermittently blinking them white.

Highlighting visible construct resources while collecting them with the Scrap Engine.

Technically the set of valid targets is a consistent subset of item types, so given time the player will know what they can and cannot collect, but this feature helps learn applicable targets to begin with, and being able to parse the visible map to see all such items at a glance also comes in handy when there are many items scattered about.

One of the more typical but important parts of any new feature is audio feedback, so I added a range of sound effects (in some cases more than one for additional variation since they'll be repeated a lot) for collecting items, creating constructs, and modifying them. Sure there's the log messages recording these events, but the audio for a log message is not specific to a given action, so for important actions it's nice to have unique sound effects for extra reinforcement.

At this time I realized the Field Recycling Unit had been relying purely on the message log to report item collection, so while at it I also added a sound effect for that one so it stands out when you leave it on and it chomps down on that really nice item that was sitting on the floor just the previous turn ;)

The most important supporting UI feature was something I didn't even plan to implement at first, to add to the "mystery factor" (at least in test builds, where the Scrap Engine was originally code named the Mystery Engine :P). The idea was to not have any built-in way to know what items had been eaten so far, and therefore not really be sure what resources were currently or still available to the Scrap Engine when turned on. But players could (and would) make note of things they were eating if I didn't find a suitable way to include this in the UI, and if we're including it we may as well reveal what actually remains, since obviously the contents have a bearing on the potential results, and it's nicer to at least have some basis for planning with what is already a chaotic mechanic.

Behold, the contents of the Scrap Engine revealed!

The Scrap Engine inventory temporarily appears any time its content changes, e.g. due to item collection or using some to create or modify a construct, and also whenever the Scrap Engine is toggled to COLLECT mode, making that a manual method to force it to appear. There's a new config setting to adjust the duration it remains visible each time it appears, or turn it off completely.

(I'm sure some players might want this particular window to be something persistent and separately toggleable, but as an item-specific mechanic I'd prefer to keep it automatic if possible, especially since the list can often be rather long and the only place to fit it is over the map view.)

Through observation the list can also be used to learn that the Scrap Engine will only hold up to ten items worth of resources (i.e. ten items) of a given type before collecting new ones starts to replace old ones in first-in-first-out priority. So with enough collection it's also possible to avoid using the contents and instead replace old items with better new ones if desired. More strategy! This could come into play if for example a lot of low-quality items were picked up during an emergency but ended up not being necessary, or a good construct build was simply maintained for so long that other items originally collected around the same time have already been outclassed by newly available ones.

(continued in next post...)

[Kyzrati]

(...continued from previous post)

Construct Naming
While it may seem to be of secondary importance, in fact part of my original drive to make this whole concept work was the potential I saw in creative naming possibilities. I had hoped that the naming of constructs could feel as cool as the names generated by Cogmind's seed system, a random mashup of item names resulting in some really evocative stuff. "ReactiveArmageddonRifle," "HypercooledWeaponHammer," "GodChainStabilizer," "AerolevSuspensionInjector," "TacticalProtonAccelerator..." I want to use one of those!

Alas, we're not quite going to get that level of cool out of construct names, as I'll explain below, but I do think they'll be pretty fun. I actually ended up using a somewhat different naming scheme for each type of construct, depending on their needs...

Having started with power constructs as a test case, and being inspired by the seed generation system in the first place, the underlying naming system for these was built in the same manner, breaking apart names of constituent items and merging them to create a new name.

Of course we're going to need a suffix to represent the type (engine/core/reactor), and also have to obey overall item name length limits so it fits in various UI locations while also being reasonable to read, so I decided to stick with only up to two words pulled from source items. For example a Nuclear Core and Deuterium Engine could combine to create a Nuclear-Deuterium Engine; later modifying it with various Ion Engines could randomly replace "Deuterium" with "Ion" to create a Nuclear-Ion Engine construct. Overall it's nice for the construct names to reflect what items went into their creation/modification.

In the case where source items are all variants of the same class of power source, such as many Ion engines, instead of the result being an Ion-Ion Engine, which is pretty weird, the naming process would convert it to "Multi-Ion Engine."

The only other special case for power constructs is the addition of a "Cld." (cooled) prefix if overloadable, so that the name itself carries this useful piece of information like it generally does for normal power sources. This is an important reason we can't really have crazy construct names--we're going to need that space to include meaningful info! (unlike the seeds, which are pure fun and often nonsensical)

An overloaded Multi-Particle Reactor in the parts list. You can also see the '&' character in front of its reference letter, as a reminder that it's a construct and cannot be removed (akin to the ':' character for processor-like parts, but here an even more special case).

This naming approach was satisfactory for power sources, but the propulsion situation adds new complications.

Right away I decided that all propulsion constructs are dubbed "exoskeletons," a term generic enough that it can theoretically refer to any form of movement (while sounding cool!), and the actual type of movement appears as a prefix at the beginning, e.g. Flying/Hovering/etc, since we do need that info to be obvious from the name. This gives us the naming format "[type] [unique] Exoskeleton," where [type] is excluded if legged (kinda the default form of an exoskeleton).

As for the [unique] part of the name, propulsion unfortunately could not make effective use of the seed-like "break down and recombine names" approach. There are too many propulsion items containing either no useful words, or only words that that aren't reasonably compatible with this system insofar as it's used to build constructs. So I had to design an alternative for that component, and decided I'd just specify applicable words manually. For example Arm. Treads can contribute the word "Armored," and Hvy. Siege Treads can contribute the word "Siege."

(I originally preferred the seed-like system's method, because it's dynamic, and once coded shouldn't require any more attention to content since it will automatically include names from new items as they are added and used--basically less data to work with and worry about, but having a good final result is of course more important, and it's not like tons of items are being added all the time anyway.)

Propulsion construct names don't use "Multi-" like power sources do. If duplicate words are all that's available from the given sources, the name will just leave it at a single word, rather than inserting any kind of hyphenated solution.

This Hovering Siege-Myomer Exoskeleton is pretty fast for its support. Maybe it has other drawbacks... or maybe not!

Note that in some rare cases it's theoretically possible to fail at assigning a name to a given construct from its source material, in which case it'll just be called a "Power Construct" or "Construct Exoskeleton," though additional modifications will eventually rename it.

Weapon constructs have an even more involved naming scheme, being the most complex of the constructs and therefore ideally conveying even more relevant info through their name. The format: [optional prefix] [damage type] [unique] Construct/[G/C].

Construct/C would be a cannon, /G a gun, referring to their type since even though gun constructs can technically become even more powerful than cannons, the difference can have a bearing on at least some mechanics like gunslinging, knockback, and blasting matter off targets.

Again because many weapon names include words that can't be effectively detected by an automated system, I used the new data option added for propulsion to manually define associated words where applicable, so that's where [unique] comes from, pulling only one random word to use there since we often don't really have room for more. The pool of relevant words to choose from is actually weighted by the rating of their source items, and limited to using only those which match the resulting construct's damage type, altogether an attempt to increase the relevance of a choice while still allowing for some outliers.

I thought it'd be a good idea to reference the damage type in the weapon name itself, but didn't want to be too repetitive about it, so instead use a list of words related to a given damage type, and pull randomly from that. So an EM weapon might directly insert "EM" for that section, or instead use "Charged" or others.

The prefix at the beginning of a name is optional, but special characteristics of many normal weapons in Cogmind are reflected via a prefix, so I think doing the same with constructs is a good idea. They're helpful, could be cool, and don't take up too much space since they're all abbreviated.

These are assigned whenever there's some aspect of the weapon that stands out, ranking all potential prefixes that reflect properties which meet a minimum threshold, similar to the point system used by the build classification system first described here, but applied instead to common weapon prefixes.

So a weapon gets a certain number of points towards the Precision prefix based on its positive targeting modifier (if any), compared to points towards Hypervelocity earned via penetration, and so on. Some prefixes sound like they could be based on relative values, for example "High-powered," in which case its degree is determined by weighing it vs. the average damage of all other other non-construct weapons of the same damage type.

Regardless of degree, certain properties override all other prefixes since they reflect important core behavior: these include guided and spread (arc) weapons, and any that fire multiple projectiles.

Deadly construct weapons! Construct builds overall feel somewhat weaker and less reliable early on, but get progressively stronger into the late game as long as they can be maintained.

Into Beta 12
This has been a pretty huge detour from the main plans for Beta 12, though at least it's looking increasingly likely this could actually work?

I don't have any hard player data with respect to this new mechanic since none was included in the scoresheet yet, but the initial idea was to get anecdotal feedback anyway--details and more nuanced balance changes could come later once this feature is established.

For a while it felt like this might end up reserved for some weird special event mode where it's forced on the player with slightly different rules, though after seeing others toy with it, and playing with it myself, I'm getting more confident there could be a place in Cogmind's next version to include the Scrap Engine (in terms of design, that is, because lore is actually where it first came up anyway so fitting it in there isn't an issue). There's still a need to see people using it in a wider range of scenarios, which I'm sure I'll see in the meantime while working on other parts of Beta 12.

In any case, building new construct combinations, and dealing with the consequences one way or another, has been a fun experience.

I've streamed some construct build playthroughs of my own, in which I talk about the design and strategy while testing it out in actual runs. The first is here:

[ernanir]

You are still going at it like a maniac. Good. Keep at it!

[Kyzrati]

I am indeed, it never ends!!! (although in that regard I must also say that it's the maniac fans who play a very important role in keeping it going )

[Kyzrati]

Still going strong



And thus time for another annual review! 2022 saw Cogmind's 10th anniversary, celebrated by its largest-ever release, and Beta 12 is still in development but getting quite large itself... Read about Year 9 of the Cogmind on the dev blog, concluding with the usual look at the months ahead.

[JobLeonard]

Ten years?! We've been on this forum for TEN YEARS ALREADY?!

Anyway, congrats man!

[Kyzrati]

Haha I know, crazy...

I haven't been participating on the forums (or any forums, really) these days, not same way as years ago, having shifted time elsewhere, but still around after all this time. Also still no end in sight for Cogmind yet.

[Kyzrati]

Polymind: This holiday season you are NOT the Cogmind



It's the end of another year, Cogmind's 10th, and to celebrate I put together a special event that turns the world on its head for an extremely different Cogmind-but-not-Cogmind experience: Polymind!

You can't use items yourself, but you can blend into Complex 0b10 by taking control of almost any robot :)

Rely on your host's capabilities to survive, or switch to another host when the need arises or circumstances force it... Be a Worker (really now...), be a Programmer (ooh), be a Behemoth (now we're talking), be almost anything. Also try not to be too suspicious and be a productive member of the Complex, or find a deadly host and suddenly unleash hell, only to mop up some patrols then return to work as an Engineer inconspicuously rebuilding the local area...

Check out the release notes for the full changelog and feature demos.

I will probably be writing some more about this mode for my blog later on, including some player stats which will probably be fun to look at once the event-specific leaderboards are compiling data.

[JobLeonard]

I did not expect a Messiah remake in Cogmind form, but here we are

[Kyzrati]

Oh wow that's a game I haven't heard about in a long time xD

I remember when that came out... made a bit of a splash. Possession mechanics are certainly not uncommon in games, or even within roguelikes (there are a number of them, including several where it's the main mechanic but they're mostly 7DRLs), here being kind of a neat alternative way to use the world which is already built up :D

[Kyzrati]

And now players are like "wow this could be expanded some more and released as an entirely separate game!"

[Kyzrati]

On Backtracking in Roguelikes
[Cross-posted from the devblog here--follow link for better formatting and light-on-dark style.]

More than once over the years we've had discussions in the roguelike development community regarding the idea of "backtracking," and with good reason: whether or not to allow it has quite a lot of implications!

Here we're primarily talking about the player revisiting earlier floors on their journey, rather than backtracking within a single map (though I'll cover that topic a bit separately at the end), and our discussion focuses on roguelikes of the dungeon delving variety, since open world games generally allow backtracking by default.


Examples
Let's open with a sample cross section of the types of map transitions available in the roguelike space:

• DCSS: Floors generally contain multiple stairs which lead to either the next floor or back to the previous one. The majority of roguelikes fall into this category, although not necessarily the multiple stairs part.
• Cogmind: At the other end of the spectrum, some roguelikes don't allow backtracking to earlier floors at all. This group also includes DRL/Jupiter Hell and Infra Arcana, but it's a pretty small group overall. (DCSS variant "Hellcrawl" removes the up stairs from that game, notably increasing the difficulty.)
• Moria/Angband: These are unique in that backtracking is allowed, but by default it generates a new floor each time! Although not true backtracking in every sense, it will naturally count in some ways. The approach is quite thematic, in any case, getting lost exploring the Mines of Moria, or maze-like fortress Angband :)

Heading back up some stairs ('<') in Moria for your very own "I have no memory of this place" moment.

• Rogue: Interestingly, in the original Rogue backtracking as a part of the ongoing diving process was not a thing! You can only proceed down stairs until you acquire the amulet, then you can finally go up stairs, but each floor in the return direction is generated anew, essentially requiring playing through 51 floors to beat the game!

One traditional reason it might make sense for roguelikes to allow backtracking is because the goal is often to reach a destination then escape back out, not unlike your typical RPG dungeon adventure.

Different games handle the escape in a variety of ways, perhaps throwing some kind of new challenges at the player along the way, for example being intercepted by powerful monsters the entire way in DCSS, or being harassed on the way out of Angband by an angry Morgoth after stealing one of the Silmarils from his crown in Sil (or the newer Sil-Q).

The Ground Gives Way has an especially interesting approach, having the dungeon's statues come to life after you acquire the trombone relic (yes, trombone) at the bottom, and you have to escape without being killed by the animated statues or whatever other creatures might still be in the way because they weren't dealt with before. The interesting part is that you can see all these statues on the way in, foreshadowing potentially difficult bottlenecks on the way out (assuming you can't directly confront and outright destroy all the living statues, a decent assumption for many builds).

These statues will come to life on the way out and try to stop you--better have a plan when the time comes! (Tip: If you put down the trombone they'll stop following you, giving you an opportunity to deal with other issues, rest, or prepare in other ways.)

By comparison, Cogmind is purely about escape, starting from the inside, so there's no reason to go back as part of the conclusion.


To Backtrack or not to Backtrack
I was originally going to divide this article into two sections highlighting the "advantages and disadvantages" of each approach, but it's not always clear whether a given mechanic or consideration would neatly fall under one of those two categories, especially given that additional design adjustments can turn a drawback into a positive, or otherwise mitigate issues, so it's more a question of simply examining the implications of a particular choice and accounting for it in a game's wider design. So instead we'll take a topical approach.


Realism
Being able to backtrack is generally going to be more realistic in the RPG sense--of course your character should be able to go back and pick up that item they left behind, or fight that enemy that scared you away before. Plenty of roguelikes are designed as CRPGs first, so it makes sense they'd want backtracking for this factor alone, if anything.

Some roguelikes don't go heavy on realism, in which case backtracking for this reason can be considered a non-issue and solely a decision to be made within the greater mechanical design, though this does mean progress ends up feeling gamier overall.

Since thematic plausibility and lore are quite important in Cogmind, I added reasoning for why you can't backtrack, so that's an option as well. In general it's good practice to try to explain anything that doesn't work as players might otherwise expect, and the one thing you can count on setting player expectations is realism! Realism is optional (these are games!), but ideally we want everything to at least make some sense within the context of the game world itself.


Stashes
While on the subject of realism, it also makes plenty of sense you can go back to collect resources left behind earlier. In a game setting, though, this can be quite an annoyance from a design perspective (harder to balance!) and is likely to either become a player crutch or lead to tedious optimal play (a topic I covered in my game design philosophy article).

As a result, you sometimes see developers coming up with ways to address issues arising from players creating "stashes" of items to return to. DCSS has an interesting historical summary of changes related to its stashes, including methods to decrease player reliance on them.

As a fully item-focused roguelike (in that items are everything to you, with no other types of character progression), stashes used to be extremely useful for an optimal player in TGGW. That's before the aliens showed up :)

Aliens arrive while you're napping to steal things the player has touched, and you can sometimes catch a glimpse of them running away with an item, or theoretically even try to stop them before they teleport away, but it's pretty tough, so you're highly encouraged to always keep anything you want to use for the long run. Under this scheme, strategically the player may also opt to leave an item on the ground, untouched until they might want it, but it can be hard to justify that decision since in many cases if it's a quality item you won't be entirely sure what specific item it is until you've picked it up to identify and it's got that human scent all over it :P

Caught red-handed, but good luck stopping them.

An alternative approach to stashes is to simply embrace them as part of the design, even going so far as to outright give the player a safe location to stash extra items they don't need at the moment, for example in a town. Heck, throw in shops to visit while you're at it :D

An Angband town, which serves as a hub to return to for stashing items, or shopping.

An example of a player home inventory in Angband (taken from here among the great LPs by TooMuchAbstraction).

Or an even simpler approach: just give the player a practically infinite inventory :P

Of course stashes aren't always an issue--depending on how the game works there may not even be a use for them, although the reason it comes up so often in roguelikes is that the genre is overall fairly item-heavy, not just different useful gear but especially consumables, which leans towards stashes being a thing.

If tight enough, a roguelike's typical food clock or other similar feature pushing the player forward might also serve as a suitable countermechanic, or impose prohibitive costs on abuse/overuse of stashes.


Grind
Grinding as a strategy, or even existing as a possibility, is pretty unwelcome among modern roguelike fans. Not universally so, to be sure, but grind tends to be more of a roguelite thing.

Preventing backtracking cleanly cuts out a number of potential types of grinding (such as returning to fight weaker enemies to maximize XP or resources), thereby serving as another feature contributing to a player's forward momentum.

Of course for some roguelikes, grind is an acceptable part of the gameplay for those who want it. No doubt the grindiest of classic roguelikes is Moria/Angband, and this honor is a direct result of backtracking as per the mechanic described earlier. Simply going up and down stairs to generate new maps ("level scumming") gives access to theoretically almost anything that can appear at a given depth, so a player can use this to not only raise more levels from repeated combat before pressing forward, but perhaps even more in the spirit of ultimate grinding, you can keep regenerating maps to search for specific items.

In a way Angband further facilitates some of the grinding process with its "level feeling" text on entering a map, revealing how dangerous the floor feels, how good the items potentially are, and maybe even a "special feeling" like "You feel strangely lucky..." or "You have a superb feeling about this level" to indicate additional features such as a vault.

Then in 2015 the Angband maintainers doubled down by making the grind even more player-friendly, adding level feeling information directly to the status bar in numerical form.

Angband level feeling indicator "LF:X-Y," where X/Y refer to the danger/treasure level on a scale of 1~9. Y even shows as $ if an artifact was generated on the current floor.

Well fast forward to 2017 (27 years after Angband's first release) and a new option is added to the game, one that changes everything: persistent levels!

Birth options menu during Angband character creation. Even after five years, birth_levels_persist is still considered an experimental feature with potential bugs to work out.

Yes it's optional and clearly not the default considering it removes one of Angband's defining features, but this addition made the game playable for some who hated the original incentive to grind, dangling there like a carrot at every depth, and also gave existing players an alternative way to enjoy the content. Some technically were already playing it that way before, without the grinding, but enforcing that conduct can take a lot of self-control, especially in a game with permadeath ;)

Anyway, Angband has taken up a good chunk of the article so far because I think it's an interesting study for this topic, considering you can experience two very different approaches to backtracking in a single roguelike. There's a lot of conversation out there about how different types of players prefer one or the other.


Difficulty
For the same reason backtracking might make way for grinding, it also serves as a way to help soften difficulty spikes, especially those that might occur immediately on entering a new (and presumably more difficult) map. If finding it hard to press forward after using the stairs, one could theoretically go back and switch to a different map (Angband), or approach the new floor from a different point (DCSS with its multiple stairs), or go grind more resources/XP left behind in earlier areas to help advance.

Cogmind has very large maps so this isn't as much of an issue--you're generally not going to full clear all maps anyway, and there are usually many possible routes within a given map (especially counting terrain destruction, employed liberally by players :P), so encountering a dangerous bottleneck required for progress is not all that common. Cogmind also has "spawn protection" on main maps explicitly to give the player more breathing room on entry (though not in optional branch maps, where ambushes are indeed possible! just an extra part of their potential danger in exchange for the rewards within).

It's not usually in your best interest to explore the entirety of every map in Cogmind--they're big and you're likely to lose more than you gain from doing so. Above is an export of one player's unusually lengthy journey across a large swathe of a 200x200 map in search of a particular destination (a desired exit).

Zorbus is a good example of difficulty spikes on entering a new map where backtracking is not allowed. You're in for a crazy ride almost any time you take the stairs in this DnD-style roguelike, especially given the pretty significant jump in danger from map to map, where all the enemies are higher level than you until you catch up, and thin them out a bit first.

My party in Zorbus getting ambushed by all manner of powerful enemies coming from the west, south and east right outside the opening room (clearly the NPCs know what's up!). Large battles are common on entering a new Zorbus map. They will spot you, hunt you, tell their friends, then hunt you with their friends :P

This aspect of Zorbus was softened a bit following response to the game during its wider release on Steam recently, at least protecting the player from being right near the level boss on entry, which could understandably be pretty devastating xD

(continued in next post...)

[Kyzrati]

(...continued from previous post)

Stairs
Stairs are an interesting design issue in roguelikes regardless of which backtracking rules apply.

Without backtracking, players are stuck with dealing with whatever they encounter on the other side, though hopefully have tools for managing sudden difficult situations, such as immediately teleporting away, or perhaps specifically preparing for a potential ambush before entering.

In Zorbus, blinking away is a common strategy for escaping dire threats. Cogmind doesn't have easy/unlimited teleporting, but also has the spawn protection rules to avoid issues in many areas, and where those don't apply, a player might indeed decide to enter prepared for a close-range ambush, like with a launcher at the ready :P

In most cases I feel safer entering caves with a launcher out to blast any group loitering on the other side. (It's less of an issue for some builds, though, or if traveling with allies.)

With backtracking, developers have the unfortunate task of addressing "stair dancing," or repeatedly using stairs as an easy escape option, even as part of localized combat tactics. Do enemies follow through stairs? How far? What else do they do if they see a player leave but don't follow?

Various solutions, or pieces of a solution, include:

• Nearby enemies can follow via stairs, for example in DCSS and Caves of Qud, but in games that do this there's always the problem of just how far away will enemies follow from? It's often still optimal if you can use this tactic to split them up, or at least temporarily break LOS to some while fighting others. Qud has an interesting addition here where you can actually use the stairs then stand on them to fight enemies that are coming one-by-one, but it's blind combat and you can't see which one you're attacking.
• Attach a resource cost to reusing stairs. For example drain stamina so the player is at an immediate tactical disadvantage after doing it, should enemies follow. Or using stairs takes more game time, further advancing whatever food/other types of clocks the game employs.
• Reusing stairs first gives nearby enemies free attacks of opportunity.
• Enemies that saw the player reuse the stairs wait nearby, then get the initiative/first strike on the player's return.
• Teleport players after going back through stairs (a possibility in DCSS variant "bcrawl").
• Make reusing stairs impossible while in combat (some TGGW stairs are called "twisted stairs" and behave this way, while others are normal, so traveling down the former might be more dangerous).
• Design such that stair dancing is meaningless. For example it was originally an optimal tactic in Tangledeep, but the developer later changed it so that all monsters heal fully heal when the player leaves, but the player doesn't have passive regeneration.

Anyway, stair dancing is definitely high on the list of issues a developer wants to consider if backtracking is a thing. My own DCSS play and stair dancing experience (circa 2010) was a strong influence on Cogmind, in that it was the whole reason I decided I didn't want backtracking at all, despite the other advantages of making that choice which I later came to appreciate (Cogmind was originally a 2012 7DRL, so the scope wasn't imagined to be anywhere near what it eventually became--there were far fewer considerations then :P).


Design Control
For several reasons already touched on, removing backtracking affords tighter control over progression and mechanical design since map transitions serve as a hard cutoff, turning individual maps into more isolated units. Expanding on that, the designer now also has reliable points at which to determine specifically what the player has and has not done by then, a fact that won't change going forward. While roguelikes of the hack-n-slash variety (uh, lots of them xD) maybe don't care so much about this aspect, there are definitely some greater benefits to be had among modern games branching out beyond that style.

Being able to refer back to an entire immutable history of player interactions with prior maps and their content, developers are able to more easily build sturdy plot lines that are harder to disrupt, for example. In open-world CRPGs where you have plot and quests, I imagine many of you have had the experience of breaking them one way or another :P

I've written a lot about "Weaving Narratives into Procedural Worlds" before, and it would be vastly more work to achieve the same results if backtracking were possible, simply due a ridiculously large expanding web of possibilities. If you can visit NPCs in any order, or revisit earlier locations after later events have occurred, each new connection and route ideally needs to be accounted for, or risk feeling like a loose end. Alternatively, you could explicitly block the player from doing many of these disruptive things, which is less immersive, so we're essentially trading in a potentially gamier "no backtracking" rule in order to ensure we can create more realistic interactions throughout the world, covering more of those bases in a satisfactory manner.

In cogmind the web of possibilities is already increasingly complex the further the player reaches, and that's assuming players cannot revisit earlier areas. To demonstrate, below is an abstract visualization of Cogmind’s potential plot-related encounters with major NPCs. The game begins at the left, and progresses to a win at the far side. The story is tightly integrated into the gameplay, and many of these encounters have implications for later encounters, for the player, or for the world in general.

Major NPCs, colored by faction, showing those with a direct effect on some later encounter (arrows), as well as those with a relatively significant long-term impact on gameplay (bracketed length). And that's just the major ones :P

Now for small-scale quests or one-off minor NPCs, backwards travel is not a big deal, but for anything on a grander scale, the control afforded by forcing the player forward keeps the amount of work required to a sane level. It's certainly still doable, after all there are open-world roguelikes, but it somewhat limits the types of interconnected events and content you can add, or the level of detail added to each one, unless there's enough dev resources to account for and build all the unique permutations, or simply have those possibilities take a more generic form (i.e. integrate them into generic faction-based systems and revolve more around dynamic relationships rather than building a compounding handcrafted story).

As far as story goes there's definitely something to be said for allowing the player to revisit an earlier location and find a new experience there, but I'm willing to sacrifice that possibility for all the other benefits.

In Cogmind I can safely introduce extreme changes to the player's capabilities or relationships without having to worry about the implications on earlier areas (of which there would be many, making it really hard or in some cases impossible to implement a number of my ideas :P). Also because Cogmind has a branching world structure in which we know that not all branches will be visited, the player is forced to make permanent choices about where they will travel for benefits (or challenges) XYZ down the road. Linear dungeons don't need to consider this sort of thing, but it's quite important for branching dungeons, where without backtracking we've suddenly built a new layer of design control directly into the world structure itself.

Sample Cogmind world map, in which the player can choose their route but only move upward or sideways to a new map. (This version excludes a number of spoiler areas, especially towards the end--a full-size version and more info can be found at the beginning of my series on spicing up Cogmind's primary maps.)

Compare to DCSS, which also has a branching structure but allows backtracking, meaning players instead have a range of non-mutually exclusive options to combine, or return to later if desired. More freedom for the player, less control for the dev. Not that strong controls are necessary, of course--it's built with this level of open-ended freedom in mind.

A DCSS dungeon map linked from the wiki. It's fairly old since it's from version 0.19 (2016!), but it gets the point across (open image for full size).

Meta Complexity
On a larger scale, new maps serving as a cutoff point also allow players to repeatedly unload some previous content from memory. It's just their current state and resources, and the path forward--less about traveling back and forth, and more about exploring the unknown, which in turn happens to be more in the roguelike spirit (says me :P) (but think about it!).

Backtracking and the implication that an optimal player probably needs to be keeping as much useful run background info in their mind might add yet more overhead, especially if one stops playing for a while and resumes a run in a later session--in some cases it's much easier to pick up and continue an unfinished run in a roguelike that doesn't have backtracking since you just check your character info and take a look at the map (where you may have even efficiently stopped right at a transition point).

Roguelikes with backtracking, especially those that don't play out in a linear dungeon, also add a greater amount of navigational overhead that developers will ideally optimize away through good QoL features. Again looking at DCSS, you have a way to quickly perform multifloor searches for locations of matching known objects in order to autotravel to them:

Auto-travel in DCSS to facilitate what would otherwise require players to have a much better memory, or take notes :)

Of course a roguelike player isn't usually one to shy away from complexity, but the more you can streamline the process of getting to the fun decision-making parts of a game the better.

TGGW is a linear dungeon, but backtracking to visit certain dungeon features is quite useful at times, so it also includes a convenient map list accompanied by the characters for notable features at that depth--NPCs, stairs, teleporters, mechanical valves, terrain that might contain something... (there is also a key elsewhere on the UI)

Architecture
As we've seen there's a good bit of design overhead for allowing backtracking, and this comes with additional architecture costs as well.

In terms of disk/memory footprint, in the modern day it's no problem to store lots of old map data for potential reuse, though perhaps these considerations played some role in the decision behind always generating new maps in the earliest classics (Rogue/Moria). Naturally there's also then the need to be able to reuse that data, which requires more supporting code.

There also might be a need for partial simulation of other maps, for example in order to enable methods to combat stair dancing, or add more realistic behavior, plus of course building any additional systems to support backtracking, be they mechanics-related or for the interface.

Basically: Doing backtracking right is going to require more work under the hood compared to just forgetting about the past :P


Addendum: Intramap Backtracking
So what I really wanted to cover in this article is backtracking to previous maps, since that's usually what people tend to have questions about, or opinions on, in our community dev discussions. Backtracking in terms of "revisiting local areas on the same map," however, doesn't seem to get nearly as much discussion. Since it's a somewhat related concept and worth taking into consideration during map design, I'll add a few notes about it here.

Some amount of backtracking in this sense is inevitable for tactical reasons (retreeaat!!!), or even strategic ones (returning to face a previously discovered challenge after preparing, visiting a local stash, etc.), though absent of player-initiated reasons to backtrack, it's nice to be able to leave it as a mostly optional part of dungeon navigation, especially in roguelikes with larger maps.

In other words, ideally the player isn't experiencing too much "well I've fully explored this section of the map, time to trek all the way back to a junction to find other new areas." The larger the map, the more relevant this issue becomes, so I've definitely taken this idea to heart given that Cogmind basically has the largest maps among non-open world roguelikes :P

For this reason I like to make sure there are enough looping paths providing alternative routes to reach different areas, meaning fewer dead ends. This helps cut down on backtracking and is more likely to offer new encounters rather than having to revisit cleared/now empty space, should the player choose to continue exploring forward. Retreading old ground is generally a boring part of a roguelike, and I prefer to keep the focus on exploration.

An old demonstration put together for one of my cave generation articles, with separate overlays showing both the general flow of the map and the loopable routes contained within, making it easier for the player to do more exploring than backtracking, even when traveling in a general direction (e.g. from one side of the map to the other).

As with freely backtracking to earlier maps, local backtracking can, however, be facilitated through QoL features to help mitigate the downsides.

Some roguelikes rely on autoexplore, which cuts down on the negative impact of empty space (both backwards and forwards!). Similar movement-enhancing features include "running" (commands to move in a single direction until an obstacle is hit), or even simply selecting a destination and automatically pathfinding to it, which is clearly pretty effective at unwinding a recent detour to return to a main path, or directly approach unexplored areas elsewhere.

Exploring a TGGW dungeon with the help of shift-modified movement keys, which will continue in a given direction until stopped/reach something interesting/see something dangerous, and even follow corridors.

Personally I feel that using the mouse to click some faraway spot to return from a dead end has a good chance of interrupting the flow of exploration in some roguelikes, turning the map into a series of disjointed encounters, the relative locations of which don't even matter anymore. This topic actually comes up a lot with respect to game design and autoexplore being an unfortunate band-aid.

But we can sorta do something about that if we want to! Wandering threats are a big help (especially combined with interwoven looping layouts :D). That passage that was cleared earlier might not be so clear on the next visit.

Cogmind has an easier time taking this to the extreme since it's more of a living world than the typical roguelike, filled with lots of actors which means lots of potential encounters shifting around, sometimes across great distances. Some actors may leave the map, other new ones may come in... It's a busy place, and the macro strategic environment combined with various clocks trying to push you forward mean that autoexplore is both wasteful and dangerous, which I think is a good sign in roguelike design.

A bunch of actors (colored by category) doing their thing on one section of a map in Cogmind, and this is without player interference or other events, which might mix things up and lead to yet more variety.

Earlier I mentioned QoL's role in mitigating some of the potential negatives of backtracking, and yet another area for it to shine here is with features such as item searching and other memory aids.

To that end I added item searching and filtering to Cogmind a couple years back, and it is pretty glorious when you need it.

In Cogmind filtering known items by name and/or other criteria, to highlight them on the map and path there.

Zorbus' item search and filter interface is similarly cool, a nice implementation that also includes a closeup of the selected item and its surroundings, as well as a path to it.

Zorbus item search UI in action.

Anyway, backtracking in the intramap sense is almost universally found to some degree or another in a roguelike. The real question is whether you're going to allow players to visit old maps again, and get the most out of taking whichever approach you decide on :)

[Kyzrati]

I normally cross-post articles here, but I guess it's not impossible that this one in particular might get updated again at some point, so it's probably better to just link to it. (I actually update a lot of my articles over there after the initial publication, but mainly to add links to other relevant content that's written later on.)

It's originally from patreon last year, when I summarized my game design philosophy and the rationale behind it, including of course examples from Cogmind. In its current form the article covers topics relating to many aspects of a game including vision, difficulty, balance, content, tedium, exploits, and UI/UX:

Kyzrati's Game Design Philosophy

[Kyzrati]

Special Mode Design, Polymind Part 1: Architecture, Features, and Balance
[Cross-posted from the devblog here--follow link for better formatting and light-on-dark style.]

At the end of 2022 I launched Cogmind's most involved special event yet: Polymind (not to be confused with my earlier unrelated 7DRL, POLYBOT-7!). The release announcement already covers the basics, so I'll assume you're familiar with those already and avoid rehashing most of that here. Instead let's talk development! Now that the event is over, towards the end we'll also be taking a look at player stats from Polymind, which also had its own leaderboard for the duration.

Polymind cover image. The word layout was actually created in REXPaint, which was faster than trying to use Photoshop since it was easy to drop in Cogmind tiles and manipulate those on a grid.

In terms of dev investment, Polymind is Cogmind's most involved alternate mode yet, requiring well over a hundred high-paced hours of mostly coding work to realize. Unlike most prior events which tended to be concentrated in just a few areas of the code, this one is all over the place. It modifies the AI, player input, alert mechanics, part interaction... all sorts of stuff, while also adding many of its own new mechanics, too.

In short, Polymind enables the player to take direct control of almost any other robot, basically "possession" mechanics as found in many other games. For years players have jokingly imagined roleplaying as a Worker or some other lowly non-combat robot frequently seen roaming the complex. In Polymind it's not only possible, but doing so can even aid in your survival :)

In a complete departure from Cogmind's normal core mechanic, the player is unable to attach any parts, or even evolve more slots, but is instead entirely dependent on hosts for protection, or avoiding detection completely by melding into Complex 0b10. While undetected, you can move around as if you belong, trying to keep your suspicion down, or eventually need to figure out a way out of trouble when things start going south. Fighting is always an option, too, but can be a dangerous one in the long term without access to Cogmind's normally superior capabilities.


Is this Even Possible?
There were a lot of questions when initially considering whether to implement this mode, since more often than not a common but high-level comment like "[feature X] would be pretty cool..." is so much easier to say than actually build :P

So the very first thing I had to do after selecting Polymind from my list of potential event ideas was to do a feasibility study looking at the potential roadblocks with respect to Cogmind's fundamental architecture and design.


Architecture
A good many roguelikes are coded such that the player and non-player "actors" (creatures/mobs/entities/whateveryoucallthem) are based on the exact same systems and data structures. This is really helpful for balancing the game, simplifying player understanding of mechanics and interactions, and of course simply building the game where you can have a ton of interactive systems but don't have to always treat the player as some separate special case.

In this sense, roguelikes probably lend themselves well to possession mechanics, inherently being easier to swap in some other actor for the player to control without worrying about too many unexpected side effects. While Cogmind does have a few player-specific exceptions with regard to certain mechanics where necessary for balance reasons (usually being a little more lenient on the player), for the most part it follows this roguelike design tenet: The player is just another Entity composed of a handful of base stats and operating as a collection of items that confer the majority of their additional capabilities.

That doesn't mean Polymind was completely smooth sailing on the architecture front, just... close to it :P

As I wrote about in Item Variants and Randomization in Roguelikes, data for Cogmind objects such as items (and Entities!) is mostly held in static databases loaded on startup, essentially a large number of game-defining values which are assumed to remain unchanged while Cogmind is running. I already had to address this roadblock in order to implement Constructs with variable stats for the upcoming Scrap Engine mechanics, so I was able to draw from that experience and code when working with Polymind. Directly editing the underlying data seems easy enough, and makes sense, but could have unintended side effects since it wasn't built with that in mind, not to mention requires separate attention to actually loading and saving the relevant unique data changes for runs in progress, data which exists outside the normal serialization process. Anyway, as with Constructs it works but it's a bit crude, as one might expect when venturing outside the bounds of what a system was designed to do in the first place...

Polymind also benefited from RPGLIKE, another earlier special mode, for which I had already added indirect access to a number of Cogmind stats that might be modified through abnormal/non-part means as a simpler alternative to editing underlying data which I had always wanted to avoid before. For example, instead of editing Cogmind's base sight range in the database, leveling up that stat in RPGLIKE would edit a separate value, and retrieving sight range for an Entity first checks whether it's the player, in which case it will draw from the separate value, or instead from the database for any other Entity. This offers another avenue for changing that value (and a few others) where applicable, if I don't want to worry about saving and loading things directly to and from a supposedly static database...

So while this mode was already a lot of work, it would've been even more time-consuming if not for the fact that it could be built on the foundation of several big projects that came before.

In the end it's not an ideal solution for the architecture side of things, but it works, and I'm open to cooking up a bit of spaghetti when it comes to putting together special events since they're short-term projects isolated in the code anyway.

The "possession" process itself is interesting in that it actually destroys the host and transfers their stats to Cogmind, while separately storing as much of the original information necessary to recreate the host if and when the player releases control at a later point.

The code used to take control of a host, transferring its stats to Cogmind, along with the reverse process for restoring Cogmind's default stats upon releasing control.

 

Data stored about a new host before destroying it. Not very much is required for recreation, since the majority of a robot's values are either static or properties of their constituent parts, all of which are simply returned/reattached to the host later (any that still exist at the time, that is). hostID, killCount and routeIndex are actually not even necessary for the process--those are recorded purely for scoresheet generation purposes, since it wants to create a leaderboard of the hosts with top kill counts, and where they were originally found.

Due to how this latter system operates, storing the host's original faction to restore it later, one side effect allowed players to discover a facet of Cogmind's internal design which wasn't previously known (and is confusing unless I explain it :P).

As players see it, Cogmind robots don't actually indicate their specific faction, instead simply showing whether they are friendly, neutral, or hostile to the player, so sometimes in a few special case branch maps, as far as the data goes NPCs might technically belong to a "faction" that doesn't behave as one might expect in another map. What this means is that specifically in Polymind, controlling such an NPC and releasing them in one of these other maps might cause them to be friendly to robots one would think are their enemies!

I did this early on in Cogmind development since it wouldn't have any noticeable impact on the game, reusing "factions" on different maps for different purposes in order to keep the total number of required factions as low as possible. This is one of many things that could be addressed in the long term if more work was put into this event, but the focus was on gameplay in the main complex (more on that decision later), and the potentially unexpected faction behavior actually only comes into play in very few situations anyway.

Honestly I recall considering a more dynamic faction system for pre-alpha Cogmind, since at the time I was close to building one for X@COM, Cogmind's predecessor and the source of its initial code, and although I later did do that for X@COM, I didn't really see a strong need for it in Cogmind compared to the overhead it would add, so decided to forgo it. I've since started adding a few extra faction slots to Cogmind for different purposes, but it's still not a dynamic system which would be even more flexible.


Design
On the design side my primary concern was interface complications, since all necessary interactions must be fully mouse and keyboard compatible, where a deficiency on one side or the other will as usual serve to limit and guide the mechanics. While in some cases mouse input in particular did require special attention, I was happy to discover that pretty much all of my goals there were achievable.

One new UI feature required on several different levels in order for Polymind to even be feasible is a toggleable force melee mode. Normally a "force melee" type interaction is enabled by holding a modifier key, though technically due to command conflicts has never been possible when combining force melee and diagonal movements using vi key directional input, for example. Alternative input options exist for such an occasion (not incredibly common), but for quite a while I have always planned to address the issue more directly with an optional universal toggle, so this was the perfect opportunity to finally make it a reality.

Force Melee on the Special Commands menu, toggleable via Spacebar then mouse click, or from the main interface with Spacebar-e or Shift-Alt-e.

(I'll write about more mode-specific interface features later.)

Mechanically speaking, one of the big potential roadblocks was how to let the player remain friendly with all those bots out there that otherwise attack on sight. It's not as simple as changing faction relation settings, which would introduce its own set of bigger problems. Instead I found a simpler solution to circumvent faction considerations and treat the player differently depending on their current host and status: just don't let hostiles add the player as an enemy if they don't currently see them as one.

Each AI normally stores its own list of enemies that it remembers for however long, a duration set initially by the AI's robot type and can be shortened by system corruption or ECM effects. Polymind-Cogmind is blocked from being added to "hostile" AI memory if using a host friendly to the AI (based on that host data we stored earlier!) and not currently suspicious.

Technically under this system, if the player manages to break line of sight with hostile pursuers and significantly lower their suspicion level, perhaps in combination with switching to a new host (which itself lowers suspicion), they can once again be removed from pursuers' memory and operate in safety, though the pursuers will likely investigate the local area and potentially discover the player again if suspicion again reaches the maximum level.

Technical design issues resolved, the other early requirement was to convince myself that the mode would actually be fun.

This aspect can be harder to nail down in gamedev, but at an early stage there's really no need to get into the nitty gritty details--I just needed to focus on the bigger picture: Will this create challenges that the player can overcome by making interesting decisions using the resources and capabilities they have available at the time? What will the player be thinking from moment to moment during the various scenarios I can envision under the type of gameplay this will lead to? What can I do or add to help facilitate that interesting gameplay?

This line of thinking leads into some Polymind-specific features like the free intel system on controlling a new host. And of course first and foremost this is also where the suspicion system and corresponding jobs system come into play. I saw enough flexibility in those that players could find a fun balancing act to carry out in there, oscillating between suspicious and unsuspicious as necessary throughout their run to achieve their goals amidst evolving circumstances. Assuming the numbers are set right, that is, but balancing is for later when the features are actually implemented. The important part is to know that it's theoretically a good track to be on before investing the required dev time.


Multitile Robots
This was huge (haha). Multitile robots are cool. They also tend to be a nightmare to work with. I wrote a lot about them in Developing Multitile Creatures in Roguelikes, but letting the player control one is a different and even more complex matter!

Multitile bots felt like they were close to derailing the project in its latest stages, since I had repeatedly pushed them further and further down the TODO list until they were just about at the end, then by the time I got to working on them and we were past my initial deadline for completion, all the related bugs sure took a long time to weed out (Polymind was definitely completed later than I wanted).

At one point it felt like they might need to be cut--essentially no controlling multitile hosts allowed, but I really felt like we had to have them in there if at all possible! They're just too cool, and an important goal of this mode was to attempt to allow the player to control almost anybot. Even if only a few players ever ended up doing it, it needed to be a thing (cue late-hour coding sessions xD).

My first experience with this was back in 2019, when players were postulating what it'd be like if Cogmind could occupy multiple spaces as 2x2 bots do, so at the time as a joke test I simply changed the one variable determining Cogmind's Entity size and surprisingly it actually more or less worked. Now that's a far cry from what it takes to have proper full control of a large robot, but at least it showed me that such a change doesn't immediately break the game!

A recording from 2019 showing the quick and dirty version of a 2x2 Cogmind. Of course, Cogmind doesn't have a tile large enough for it to occupy multiple cells like true large Entities, so instead the game automatically renders other adjacent tiles found in the tileset positions where such image data would normally be stored :P

A quick and dirty sketch by Zyalin to go with our innovative multitile Cogmind design that seems to be melding with various other robots...

(continued in next post...)