This winter holiday season I released Cogmind’s seventh special mode, “RPGLIKE,” and quite unlike other events which have not necessarily been designed as permanent parts of the game to promote going forward, this one definitely is, and serves a specific purpose in that regard.

A number of people are interested in the world of Cogmind, but find that it’s extremely unique mechanics don’t click for them, most specifically the rampant item destruction, heavy item management requirements, and generally decent level of tactical prowess required to succeed. There are difficulty settings to somewhat mitigate these aspects, including even more recently the ability to quick save/load in all but the hardest mode, but those still don’t change the fundamental nature of adapting to loss and dealing with natural attrition, characteristics that permeate the normal Cogmind experience by design.

So I thought I’d try an experiment in attempting to convert Cogmind gameplay into an optional experience more similar to other traditional roguelikes. This means a number of things, most importantly a system for permanent progression, the ability to heal yourself, and items that don’t break.

Early Concepts

The earliest ideas for this mode were even more extreme than the final result (which is itself a pretty extreme departure from regular Cogmind :P). They assumed your parts would be completely immune to damage, and that you could simply heal either by “resting,” or gradually over time--basically your usual CRPG/roguelike mechanical tropes.

However, the design went through a number of iterations before implementation even began, because as I tried to run the numbers and make sure there would be some semblance of balance (also taking into account likely player strategies given each scenario), it became apparent said tropes in that form really couldn’t exist in the world of Cogmind and keep the game fun at all. I mean sure they’d be fun insofar as it can sometimes be fun to just run around practically invincible destroying everything, but there would basically be no challenges unless I also put a lot of focus on changing the nature of the existing challenges.

But with a mode already planned to be this big, it wouldn’t be reasonable to take on yet another huge amount of work on top of it, just for a special mode, so those starting points inevitably had to be scaled back… but we’ll get to that later. The implementation really started in earnest with one of the less questionable aspects: gaining XP and using it to choose permanent upgrades.

Upgrades

Instead of the usual evolution effects with each new depth as Cogmind approaches the surface, even basic stats like slots, max core integrity, and heat generation would be gained as XP-earned upgrades. But this being “RPG-like,” we definitely need more stats to modify on level up…

Types

I started with a broader and longer list of factors the player could theoretically be given control over as they leveled, but pared it back to below 26 because I wanted them all to fit in a single window, visible without scrolling, while still being entirely accessible via letter keys. (This is yet another of the many cases in which Cogmind’s design is guided by UI restrictions, rather than prioritizing content over ease-of-use, but that’s honestly the best way to go about it because there’s plenty of design space within even much tighter restrictions, so usability should generally be the priority.)

Notice that many of these upgrades overlap with existing item effects, at least in part if not entirely. This honestly isn’t an ideal way to build this mode, which would benefit more from having every single upgrade provide or improve a unique ability unable to be acquired via any other means. But the better alternative would be a huge undertaking, whereas basing upgrades on existing systems and code is fairly quick by comparison--altogether it took a couple days to build the upgrade UI and get it hooked in with the game’s data that it could modify.

Having some overlap does, however, enable the player’s progression strategy to emphasize one of flexibility (more slots, like regular Cogmind which is maximum flexibility) or safety/consistency (using permanent upgrades), especially in cases where the functionality they’re after can come from either a part or upgrade. Upgrades are naturally also the more accessible of the two options, since they only require XP and can be obtained at any point, rather than finding the relevant part (and better versions of it later).

You can actually graph when it’s more effective to have a part for a given effect vs. the upgrade, to a certain extent, weighing the cost of the upgrade vs. the cost of evolving the required slot, but the calculations change over time depending on the necessary part’s precise effect, and how many slots the build already has, since the latter get increasingly expensive. Trying to optimize these decisions can be complicated yet further by additional requirements in some cases. For example increasing raw energy generation is a simple straightforward way to get more power, but power sources can do the same thing and also come with more storage capacity for surplus energy, though also produce heat, require additional mass support, and occupy an additional power slot (yet another upgrade).

Relative costs are clearly the most important balancing factor here.

Costs

XP is used to increment upgrades, and each has a base cost, a modifier (a static value for the amount of stat increase per upgrade), and a cost modifier (a static value for the amount of increase in cost for each additional time an upgrade is incremented). For example, the first upgrade to sight range costs 100, increases by 1 per upgrade, and each upgrade after the first adds 200 to the cost (e.g. 300 to upgrade it a second time).

The result of this system is a linear increasing cost for repeated upgrades, essentially adding to the cost of specialization. 1,500 is the amount of XP available to spend at each new level raised, so according to the graph the 8th sight range upgrade, from 23 to 24, requires an entire level’s worth of experience! At that point (or even before) it’s probably more cost effective to add another utility slot and attach a part that extends sight range, depending on how expensive utility slots are getting :)

As for where the raw numbers for different upgrade costs came from, I wanted to start with a base cost of 500 for a single first slot upgrade, and use that as the basis for all other costs. This makes sense since slots are central to Cogmind’s balance to begin with. The particular value of 500 also 1) gave enough room below it to fit the other lesser upgrade base costs and 2) wasn’t too long in terms of digits (even after the intended increase in costs over time) to mess with the planned upgrade UI layout. As usual, before starting any of this I’d already mocked up the UI:

To be sure relative costs were about right without needing much actual playtesting, I built a spreadsheet in which I could drop in different base values, cost increments, and stat modifiers to see how they would affect the progression and player abilities at each level, especially in comparison to other upgrades.

Without an interactive chart something like this would take forever, and although I spent a good couple hours poring over these numbers, once it was done and I went in to actually playtest, very few changes were necessary afterward.

Inventory

One of the big questions early in the design was what to do about inventory capacity? Too large an inventory would be both boring and also doesn’t really contribute much since in RPGLIKE you don’t need to carry spare parts to combat attrition like you do in the regular mode--seeing as your parts won’t be destroyed, you just need a little space for the occasional consumable, or a handful of alternate parts for special situations.

Thus I decided it would be better to fold inventory capacity into the upgrade system and have each slot be very expensive, while starting with no capacity at all!

On the technical side, we already have the Pure Core challenge mode (no inventory allowed), which automatically converts any Storage Unit you step on into matter, but that was more of a janky solution which feels weird for the more “serious” tone I wanted to retain for RPGLIKE, since it’s obviously not realistic and you can still see Storage Units as parts, and on other bots which use them.

For RPGLIKE I went a step further and made it so that Storage Units essentially don’t exist. On startup, all robots equipped with Storage Units have them removed and their base inventory capacity is increased by a corresponding amount, changing the underlying game data in the process. Then of course I had to make sure it still wasn’t possible to get them via other means, like through fabricators, schematic hacks, or any kind of random spawning, and at first that seemed like it was going to take ages considering all the possibilities…

Then I remembered I could just use an existing “item distribution” setting and automatically convert all storage parts to “unique parts that can only be placed manually by the game”, as if they belong to the ranks of very high-rating special gear, and just like that they won’t be accessible through any other means :)

Of course this approach cannot handle cases in which Storage Units are actually manually added to the map via prefabs, so for those I fell back on the Pure Core method and just convert them all to matter, which is fine because the player will never actually see them as Storage Units to begin with.

With such low inventory sizes, Relay Couplers were also given special consideration. Builds focused more heavily on bothacking will want to carry spare couplers, but even at the high end inventory sizes in RPGLIKE are generally going to be only between maybe a quarter to a third of what you normally might have, so all Relay Couplers have their value doubled.

Caps

I prefer to avoid capping upgrades if possible, but there are some upgrades which would simply be too powerful without some kind of limitation. Technically we can enforce a more “natural” limitation by having those particular upgade costs scale very quickly, but because I decided to have costs scale linearly, trying to put later levels out of range would also put even earlier/mid-level upgrades out of range, so that approach wouldn’t work as well.

Instead I had to put an artificial cap on those upgrades which would be far too powerful if players focused on them, namely damage resistances and damage modifiers.

Progression

“XP” for applying towards upgrades is made available in chunks, one per level, where each level raised both requires and provides 1,500 XP.

Because I decided to have earned XP translate directly to the value used for upgrading (i.e. there’s no additional/separate unit of value awarded at each level to use for upgrading), and upgrade costs increase with specialization, thus it makes the most sense for the amount of XP per level to remain static. Yes we lose the option of having inflationary XP-per-level thresholds often seen in RPGs, but it keeps things simpler both on the inside and outside :)

The total XP target for each depth comes in handy for balancing costs and XP gains. To make sure the numbers would work out, I put together a separate “build theory” table with some sample slot arrangements likely for a given depth in a regular (non-RPGLIKE) game, and had it automatically tally what this build would cost in terms of XP:

Because basics like core integrity increases and minimal heat dissipation would no longer be included as benefits of Cogmind’s natural evolution, I also tallied the total cost including those corresponding upgrades (including also base inventory capacity) to arrive at the true XP cost of a regular build. By comparing the total XP cost to what a player would likely/hopefully have at a certain depth, and taking into account the cost of optional upgrades, I could see how much leeway there would be for builds compared to the regular mode and adjust for a desirable progression and power level that way.

Sources of XP

The latest April Fools mode, “Pay2Buy,” had a system one might liken to XP in the form of earning CogCoins for purchasing parts from the store. It was based entirely on accumulating alert, since alert in Cogmind already translates to difficulty, by design, so the more trouble you cause, the more you earn, and therefore the more you also have to deal with the consequences of your actions.

For RPGLIKE I wanted to use that same system, relying on alert increases to award XP, but because this was to be more than a little temporary event, the system needed to allow for a greater variety of play styles, and therefore required a somewhat wider variety of XP sources.

I thought of possibly adding very explicit sources of XP unique to RPGLIKE, such as certain enemies or special locations, but again, variety is better here and my eventual conclusion according to my notes was that “XP needs to be from whatever actions we want to incentivize, so it should really be a combination of things.”

So in addition to alert, which already encompasses a range of actions that tie into creating mayhem, I also decided to award XP for all sources of bonus points. Most of these resemble “XP bonuses” you might find in an RPG for plot-related encounters, and also tie into ally-caused destruction, allowing allies to help you earn XP as well just like they help raise your score (important especially for those builds/runs that frequently rely on help from allies).

But the largest single contributor to XP, or at least on par with alert-sourced XP for combat builds, is actually a separate category: Exploration. One of the defining factors of regular Cogmind progression is that your core improvements come from “evolution” automatically as you approach the surface, meaning you don’t have to grind out levels or worry about accomplishing specific tasks to remain effective. This leaves a lot more room for freedom to try a huge range of play styles, so I decided that exploration is far too important to pass up as a source of XP, since anything else would end up limiting creativity.

Simply visiting different maps gives significant XP rewards, where main maps are worth an entire level’s worth of XP, while the value of branch maps varies, but is always at least a third of that for each map. A few special (or especially dangerous) maps are even worth more than one level.

After playtesting with it I was very happy with the result, and from sample runs I’ve seen by other players in RPGLIKE mode so far, regardless of style their progression tends to be at least somewhat close to the intended targets outlined above.

Level Curve

That observation can also be explained by a built-in XP adjustment that tries to maintain a tighter “level curve.” (Level progression itself is indeed linear, although if we graphed the XP levels reached by different players at a given depth it would of course result in a curve.)

To keep players from getting too far ahead of the curve, diminishing returns on XP gains are applied beyond a certain point (specifically the “target max level” for a given depth). It’s not a huge immediate falloff, and one can still get some levels ahead, but the returns do get smaller and smaller until hanging around on the same map farming alert for XP is really not worth it, not when you can head up to the next depth and earn those same levels much more easily.

I also wanted to prevent some players from falling behind the curve, but decided this wasn’t necessary in Rogue mode (the hardest difficulty setting), so in Adventurer and Explorer difficulties the reverse of the diminishing XP formula is applied to XP gains by players who are below the minimum target level, allowing them to more easily catch up if they’ve somehow fallen too far behind.

(Here I’d like to share some sample graphs of level curves from our data, but sadly although the data has been collected, the leaderboard system to access it has not yet been completed…)

Timing

The upgrade menu is accessible at any time.

I originally thought of doing upgrades during Cogmind’s normal evolution process, but realized 1) this would require two new UI windows and be more complicated to implement and 2) was clearly thinking too much “inside the Cogmind box.” I mean it should be like most CRPGs where you can get your new goodies at any time, right? :)

So in RPGLIKE, whenever a new level is hit there’s a notification and the menu is always right there. XP can even be saved for later, accumulated for an upgrade that’s become too expensive for a single level, or for other strategic purposes.

Starting Conditions

Naturally for a mode as different as this, it makes sense to have unique starting conditions. It’s also an opportunity to add a bit of CRPG-like “character generation” right from the start.

Players start with a chunk of initial XP (more for lower difficulties) that can be spent immediately on upgrades to start defining their build. The base amount in Rogue mode is set at just enough to create what is more or less a normal starting loadout:

Starting core integrity is higher than usual, since that’s what takes the brunt of attacks instead of parts, unlike the normal game.

The base starting build before any upgrades is only 4 slots! This is the first time a Cogmind build has the option to only ever rely on a single Propulsion/Utility/Weapon slot. (Because I was curious and wanted to try it out, I actually did a complete 4-slot, upgrade-only, run recently :P)

There’s also no inventory capacity by default, but again it’s not as important in this mode, so most people will/should start with fewer than 3 upgrades there and reallocate the significant XP savings elsewhere on multiple cheaper but effective upgades.

UI

The upgrades UI appears in the same location that Pay2Buy did, and resembles it in some ways, but because the latter’s expanded form actually made use of a generic list class that I built for use throughout Cogmind, while the upgrading would require many more unique interactive features, I had to write this new one from scratch. No problem, I do rather enjoy designing and building interfaces :D

First, because it could be easy to miss the fact that you’ve raised a level in the first place, especially because it often happens when other things are going on, aside from the inevitable message log event there’s also extra feedback in the form of a unique sound effect and blinking indicator above the level/XP summary. I don’t want any of Cogmind’s notifications to be modal or anything quite so interrupting/in-your-face/immersion-breaking, so that’s as far as I went.

As usual I always want everything to be fully accessible via both mouse and keyboard, and in the case of the latter there are even three different input schemes. The standard Cogmind approach is of course lower/upper case characters for increasing/decreasing their respective values. Also with lists like these it’s nice to be able to navigate directionally, so both arrow keys and numpad can be used to move the selector up and down, with left and right incrementing and decrementing the current value.

As you can see references for key commands are built into the interface itself, making them easy to learn. The “Up/Down/Left/Right” in the corner isn’t really attached to anything, but players will generally intuit that it refers to key commands and try them out, seeing the effect it has on the UI.

Probably the biggest challenge with a UI like this is that upgrades cannot actually be applied until confirmed, but before that point it’s still necessary to show their state, modified cost, limits, etc. given the desired upgrade(s). This can get somewhat complicated, and also potentially require a fair amount of duplicated code for various purposes.

In the end I used a solution that simply retrieves direct memory references for respective stat values, which can be used to both query the current base value (and temporarily modify it as necessary) as well as apply each modification later once confirmed. The amount of code involved ended up being quite small, but could have been larger if the upgrades were more complicated than simple integers (and integers where positive values are always good, at that!). I did actually remove one planned upgrade partway through implementation because it would break the elegance of this system :P

Classes

Character classes are a staple feature of most RPGs, but at odds with Cogmind’s normal free-form build-as-you-go approach. This being “RPGLIKE” mode, it sure would be nice to fit classes in there somewhere…

Fortunately Cogmind already had a built-in feature that would help here: the automated build classification recently added with Beta 9. It analyzes your current build and assigns it a base class name with maybe a special modifier, but must be activated manually (doesn’t appear by default) because that particular feature didn’t really fit with the type of immersive atmosphere I wanted to create for Cogmind. Regardless, it’s certainly appropriate for a mode like this, so I made it active despite whatever the advanced config file says. A fair number of people who didn’t know about it before will probably even think it’s unique to RPGLIKE :P

The classification system does take into account the effects of RPGLIKE upgrades when deciding on a class, which took a while to merge with the classification system and wasn’t even present in the earliest prereleases since I wasn’t sure I’d have enough time to get around to it, but I’m glad I did because I think it’s pretty important for accuracy purposes given that many of the upgrades would be taking the place of various slots/parts.

“Healing”

Exactly how to restore core integrity would be a pretty central point of RPGLIKE gameplay, but I still hadn’t even figured out how it would work while already building the UI and setting upgrade costs. Since the first “purely RPG” ideas like resting-to-recovery or gradual recovery couldn’t really work balance-wise in Cogmind, it seemed I’d have to wait for a better solution to pop up, and at least there’d be spare time in between working on the other features to mull over different possibilities.

Healing over time would have clearly been boring in so many ways, not unlike it can be in some other roguelikes! But at least these other roguelikes are specifically designed around individual encounters, where you’re often at full capabilities for each one and when you go into a given battle, it’s you vs. that current enemy/enemies which you’ll probably either squash or which might have a chance to kill you if you make too many mistakes (maybe even just one mistake xD).

Cogmind has always been more about attrition and tactics vs. a much larger complex and numerous potential enemies, which individually don’t really pose a threat to you. So that whole central aspect of the game (and all the content and balancing associated with it) would have to change for rest/gradual-healing to be feasible, and as I mentioned earlier that’s outside the scope of this mode, and also unnecessary anyway since there are other methods.

Another problem particular to healing over time is that Cogmind doesn’t have the consumables most other roguelikes do in order to handle short-term variance, consumables like… health potions! It’s from here that I started taking a new approach to the idea of integrity restoration, and realized we’d need a whole new item to do it.

Protomatter!

Thus Protomatter was born, a whole new item permanently added to the game for a special mode, and in that sense the first of its kind. (One other event, the holiday mode from 2018, also added items, but that mode no longer exists so neither do the items associated with it.)

Protomatter is basically like a health potion, dropped randomly by some combat-capable enemies instead of regular Matter, and used to restore core integrity (or if one’s core is already maxed, it repairs any damaged parts).

I definitely didn’t want it to be like health potions in other CRPGs where you can simply chug them when in danger for an instant boost of HP, possibly even up to full. Having it take time to use would be more appropriate for Cogmind, and add a bit to the tactical decision of when and where to use it.

The original implementation (that patrons tried out in the first prerelease) was simpler but quite funny: It determined how much of the Protomatter was required for a full heal (or to use all of it even if not enough for a full heal), then calculated the required number of turns to do that, and applied it all as a single uninterruptible action. That was by far the easiest way for me to implement it rather than spreading its use over multiple turns, but the way the numbers worked out this meant you could in some cases end up sitting there applying Protomatter for 15 or more turns! One can imagine the potential consequences of such a long action--enemies you didn’t even know were there yet might round a corner and start shooting you to pieces :P

Instead I ended up having to take the more complicated route and have it apply on a turn-by-turn basis, with pacing determined by the player who could simply wait while standing on top of it in order to apply the next batch. Some of the complexity came from the application process itself (mainly where it involved attached parts), but also simply from properly handling the messaging system so it would show the desirable results once you’d finally finished applying Protomatter, rather than spamming the message log with too many individual messages.

At first I wasn’t sure what to call this item, but it soon became obvious it should be related to Matter because:

• Protomatter would similarly be a pretty fundamental item throughout a run
• Protomatter would sometimes be dropped as salvage (instead of regular Matter) (note that to avoid destabilizing the existing balance, all Matter drops were increased a bit as well)
• Like Matter, it’s affected by salvage-modifying attacks (although unlike Matter it can never have its amount increased by a positive net salvage modifier)
• I would need a tile for this new item, and the Matter tile would be a good choice here since it’s otherwise only used once and doesn’t fall into any other category

At the same time, I wanted to also differentiate it from matter because it not only has a different purpose but would also have different fundamental behavior, so I gave it a unique naming scheme, “Protomatter-XX” (e.g. Protomatter-56, where 56 is its remaining amount).

Protomatter behaviors that differ from Matter:

• Can be picked up as an item and held in inventory (not in containers like Matter), important for allowing some backup repairs depending on how much inventory capacity you have and want to devote to this purpose.
• Suddenly decays randomly, disappearing from the map (unless in inventory or currently under the player), as it’s important to prevent stockpiling Protomatter on the map itself, since in the right hands that just makes it easier to become invincible.
• Cannot be merged or stacked, because that would also make it too easy to stockpile unless some kind of arbitrary limits were put in place, but may as well do with that altogether since it just unnecessarily complicates things.

On the topic of naming, the first options considered for a moment then thrown out were to just jokingly call these Health Potions, but even though it would be really in theme for this event, RPGLIKE is meant to be a more serious mode so I had to come up with something better. “HP Kit” or “HP Unit” were similarly passed over :P

Damage Transfer

While working on the new “healing” mechanics, I decided this was an opportunity to change the initial idea that all incoming damage would go straight to your core, practically doing away with item destruction entirely and behaving more like your average roguelike with RPG-like progression.

Reducing the role of item destruction is definitely one of RPGLIKE’s primary goals, but completely removing the risk of that happening felt like it would unnecessarily gut a lot of the feeling of Cogmind--your parts always appearing in perfect shape would be fairly awkward, and we can get the anti-item destruction effect without going to that extreme, by just redirecting most of the part damage to the core, instead of every last bit. This also helps retain some of the coverage-related balance inherent in Cogmind’s part stats (there is definitely noticeable destabilization, however--that’s unavoidable).

So 80% of damage to parts goes instead to the core (it’s funny because there’s actually a part in the regular game which has this exact effect, although naturally the strategic implications are quite different there due to the lack of frequent core restoration). Even though it seems you don’t really lose many (or any!) parts in this mode, it still feels more natural if they’re taking a bit of damage from attacks, and it could still come into play if you’re playing very poorly or incorrectly managing Protomatter reserves and acquisition.

Honestly I think we could probably do with a lower percentage than 80, at least for Rogue mode, and it would make RPGLIKE more challenging while still retaining its uniqueness., but that’s a slippery slope that leads right back to the default Cogmind experience ;)

While on the subject of healing, I should mention that several times I considered allowing XP to be used to repair current core integrity as separate from the current/max integrity increase that it ended up as, but ultimately decided against allowing that since upgrades were meant to be instantaneous and that would be just like the “emergency chugging of potions” I was trying to avoid.

Records

As a more permanent official mode recommended for some players, RPGLIKE also got exclusive treatment as far as the scoresheet is concerned.

The history log records slot upgrades (since they’d normally be reflected in evolution messages but those won’t happen in this mode), as well as each level gained (since that aspect of progression is pretty important to the mode and can be interesting to see in the context of other events along with the turn counter).

RPGLIKE also gets its own section in the scoresheet, recording many other details on a per-map basis.

What’s Next?

Could RPGLIKE mode be better? Yes, in many ways! I mean this is no surprise given that it’s a mode designed on top of another game and basically turns it on its head :P

I do plan to still do some more work on RPGLIKE mode, or at least tweak it. Precisely how to improve it also really depends on the goal of doing so, since what constitutes an “improvement” is subjective, and in its current form it’s most definitely not the primary way I would want to play Cogmind.

I mean I’ve been having a lot of fun with it, as you can see from the already several streams I did in this mode:

• RPGLIKE Intro Run -- An introduction to the new mode plus a relatively quick but complete run based around one of the overpowered EX-tech parts I’d never used before (spoiler: we torch 0b10)
• RPGLIKE No-crutches Run w/Kinetics -- No FarCom, no RIF, no imprinting. Just a pure kinetic combat build out to shoot anything that gets in its way.
• RPGLIKE 4-slot limit “Babymind” run -- No slot upgrades allowed, just 4 slots total straight to the end. We go mostly melee, a bit of hacking, and using allies to do much of the fighting. (Several big guys fight on our side because FLK :D)

An introduction to the new mode plus a relatively quick but complete run based around one of the overpowered EX-tech parts I’d never used before (spoiler: we torch 0b10)

But it’s far too easy. For the first iteration this was intentional though--I guided it towards the easy side for a couple reasons:

• It’s a holiday event! For something like this it’s better to aim for fun over anything else. After all, it’s optional and not like it removes the regular mode, anyway.
• In games there’s often a fine line between too easy and too hard when you have a healing system, certainly much finer than Cogmind’s usual death by attrition and an accumulation of long-term mistakes rather than one or two recent mistakes. Designing a healing system that can ride that line more closely would take a lot more theorizing and playtesting than there was time for. Heck it might even be impossible given Cogmind’s other mechanics.

My personal main goal for RPGLIKE’s theme was to add a system of permanent progression and all but eliminate part destruction, and it satisfied those goals well. It will never be heavily balanced like the regular game--that would require too many changes, but it’s still fun either way, and at least the challenge level can be tweaked. Those who enjoy this mode aren’t necessarily looking for complete balance anyway, at least it doesn’t sound that way from all the feedback :)

Bonus: RPGLIKE Strategy Notes

While playtesting RPGLIKE I was noting down various strategies and/or observations for later reference:

• It seems to get easier over time, as is generally the case with other “RPG-like” roguelikes but quite the opposite of regular Cogmind (which tends to get harder as you progress)
• That said, you also gain levels very quickly at the start (plus have extra XP to spend on upgrades you normally wouldn’t have) and as long as you can ensure you don’t destroy most of the Protomatter out there, it’s unlikely you’ll actually die.
• Either way, you generally feel a lot more free to be reckless because damage can generally be repaired, and mistakes aren’t going to be as costly in the long run like they normally are.
• Inventory capacity is going to be low throughout the run, but that’s okay because you don’t need spares. It becomes more of a simple storage for items needed in alternative situations, or even consumables (“health potion” Protomatter, and in one of my runs I had a PSU Rigger so I just kept filling my limited inventory space with nothing rigged power sources :P)
• Can use more/different types of items you might not otherwise normally keep attached, since they won’t break! This is especially useful for unique parts that cannot normally be replaced.
• There’s little reason to use anything slower than hover unless you want siege mode or other tread benefits, because propulsion is much more protected in this mode anyway, and even mass support can be gained via upgrading.
• Repairing core and parts is separate, and core is often more important, so it can be advantageous to save your Protomatter specifically to repair core rather than worrying about parts, which can be replaced, after all. However if you’ve upgraded core integrity quite a lot and then lost much of it, getting enough Protomatter to repair both core and parts can become difficulty, putting attached unique parts at risk.
• Because you generally have few to no spare parts (since you don’t normally need them, or can’t spare any inventory space), cave-ins are extremely dangerous, even more so than usual. To a lesser extent the same goes for other effects that remove and/or directly damage parts such as Blade Traps, Saboteurs, etc). The most dangerous effects are technically avoidable, though.
• Honestly in it’s release state it’s kinda like a wizard mode for testing the effectiveness of builds, at least in an offensive capacity, since you can try them in different scenarios without fear of inevitably losing them after a period.
• Can save XP for later when you really need it, either to buff some ability that will be of immediate use, or to increase core integrity in a pinch.

Some of these may no longer quite be as applicable after updates, but they’re relevant as far as the Winter 2019 event goes ;)

Addendum: Beta 9.4 Updates

Not long after this article went up I released Beta 9.4, mainly as an update for RPGLIKE mode. It didn’t involved any sweeping changes, and you can read about some of its other tweaks in the linked release notes, but here I did want to at least mention that the role of armor-type parts as protective gear was restored for Cogmind.

The solution was to simply have armor absorb more damage than usual (40% instead of 80%), turning it into a sort of consumable in the RPGLIKE world of otherwise far less consumable parts. This means builds can use armor as a way to avoid the need to rely on acquiring as much Protomatter.

Further changes will contingent on the size of RPGLIKE’s post-event player base and the data we see from these runs.