Design Overhaul 1: Capping Inventory

Last time here on the blog we covered sensor changes and other new related utilities coming to Cogmind’s next major update. At the time I wrote:

Cogmind’s next update (Beta 11) is taking years of play experience, feedback, and observations into consideration for a comprehensive review of the many items and their stats with an eye towards readjusting a variety of aspects to create an even more balanced and fun game full of interesting decisions and trade offs. A number of values need to be reevaluated in the light of all the changes and (especially) tons of additions that have been made in the years since 2012.

While many of the early design decisions established a good foundation that in a general sense has withstood the test of time by both attracting and holding the interest of many long-time players, and along the way the integration of new mechanics and content expansions certainly resulted in a number of retroactive adjustments to prior work to keep things more or less balanced, there’s never been a much wider review of the kind we’ve wanted to do since like… five years ago xD

Especially with regard to less vital parts of the game, there’s been an understanding in the community that one day they could one day all be addressed together as part of the “Great Utility Update” (so called because Cogmind’s largest category of items and many of those frequently discussed in balance/usefulness terms happen to be utilities), so lots of these kinds of things have piled up over the years.

With Cogmind basically done and preparing to embark on expansions definitely outside the realm of what was originally planned (see the 2020 ARG :P), Beta 11 is finally the time to do this big review.

But we’re not starting with the little stuff! On the contrary, if there are any significant balance changes to be made, those need to happen first, and it just so happens that some of these are indeed coming down the pipeline, somewhat unexpectedly, even…

Capping Inventory Capacity

One of the more fundamental design levers when it comes to utilities is whether or not their effect stacks when attaching multiple of the same type. Storage Units have always been stackable, meaning players who want to carry around even more spare parts (and don’t mind being overweight, because storage is heavy!) could just load up on extra Storage Units and fill them with salvage and looted parts. Among the better players, over time this feature clearly led to rampant inventory inflation, and we saw more and more superheavy storage-laden builds working their way through most of the game like that until they’d shed most or all of their storage and use the contents to assemble their ultimate build for the final stretch/extended game. Basically the safest play tended to be maximize inventory size for as long as possible, whatever players thought they could get away with depending on their build goals and how dangerous their chosen route might be along the way.

Zyalin‘s depiction of a storage-laden Cogmind build (in particular a bothacking RIF build, a topic we’ll get to later).

This whole approach is actually kinda anti-Cogmind, circumventing much of the “dynamically adapt to circumstances” aspect while being a significant drag on the build effectiveness and the experience in general (due to generally slower builds and more utility slots allocated to increasing storage capacity because spare parts are so valuable compared to using the slot for one other active part).

Either avoid most confrontations, or suffer from higher than average part attrition due to reduced effectiveness both in and out of combat while constantly cycling through replacement parts instead.

Other drawbacks of massive inventory growth start to appear as their size expands further beyond what the interface was designed to handle. The original GUI layout and functionality assumed that builds would generally have one or two pages of inventory content (or at most three), as it can only display up to 12 parts at once and allows interaction with 10 of them (equivalent to the 1~0 number keys). Then of course there are the players frequently running around with 5~6 pages of inventory (10 has happened before, too xD) and it becomes cumbersome to use on top of the weaker build resulting from having so many utility slots devoted to all those Storage Units.

Insane inventory capacity at work in the wild. This particular streamer’s late-game build had a total of 18 utility slots at the time, 10 of which were occupied by storage units xD (not to mention the focus on evolving utility slots meant having evolved nothing else).

Players being inventive and challenging themselves to work their way outside the bounds of a game’s design can be interesting, but less so if it’s a very easily triggered compulsive behavior like hoarding.

That’s not to say the goal here is to completely remove the potential for superheavy hauler builds--even in Beta 11 fairly large inventories will still be possible, but some kind of limitations would really help here and I believe 1) we do still need to tweak the cost-benefit equation when it comes to carrying an almost endless supply of parts, and 2) this can be done in a way that also keeps the game more fun by freeing up more utility slots for other purposes.

At the same time, I’m grateful for the period over which players did put a lot of pressure on the inventory management interface because it gave us QoL enhancements like swap functionality :)

Demonstrating two of the many ways to swap parts in Cogmind.

So with a general consensus in the community that inventory capacities were getting out of hand, naturally the next step is to figure out what to do about it…

<no_stack> Storage Units

In the Balance Overhaul discussion thread on the forums, zxc repeated his outlandish suggestion to go with <no_stack> storage (referring to the in-game tag used to mark utilities that cannot be stacked). One might think that too extreme a change, and I was definitely in this camp from the beginning. For one I prefer to avoid no_stack whenever possible since it’s a very hard limitation, and that can mean somewhat less flexibility in terms of build variety, especially worrisome in this case due to how central the storage capacity element is to a build--to me the the ability to mix and match different types of Storage Units (or multiples of a certain type) to get just the right balance of mass and capacity seemed really important. But it can also be easy to overlook the fact that limitations in one area open up more opportunities elsewhere, particularly in this case as we get even more utility options (like the latest infowar set!).

A range of less extreme alternatives were proposed by other players, but I decided we could try some truly experimental patron builds featuring behaviors which might not actually make it into the official release, and if we’re going experimental, might as well go extreme to begin with and see how that feels before possibly dialing it back or examining other options in more detail.

Numbers

Taken in isolation, simply slapping no_stack behavior onto Storage Units does indeed seem way too radical and likely to both weaken many builds, but compensating with much greater capacity from a single unit as well as adding extra types to choose from resolves these issues nicely.

The main question here is of course what kind of inventory sizes are we targeting?

Somewhere around an inventory size of 20~25 seems reasonable for the average combat build--it’s a size I’m familiar with since I often go with that, and others agreed, so let’s let the Large and High-capacity units straddle that range and extrapolate from there. Altogether this results in only about two pages of inventory items, which is very reasonable to work with, and remember that concentrating this much storage into a single slot also frees up one or two extra utility slots for other uses, helping those existing inventory slots go the extra mile since increased build effectiveness somewhat reduces the need for spares.

Of course some builds might still like to carry more than that, which is fine, so under no_stack rules that would require adding some more options at the higher end which come with pretty hefty costs, namely both significantly higher mass and an additional slot.

After testing and tweaking, it turns out no_stack storage is a great improvement overall, and the final set is as follows:

Beta 11 Storage Units reworked and expanded for compatibility with no_stack behavior.

As you can see there the naming system was shifted a bit, allowing all existing robot builds to continue using the same type of storage as before, good for both loadout familiarity as well as retaining names that feel more in line with each robot’s purpose as originally designed (mainly the non-combat varieties).

Numberwise, with the main series mass doubles for each linear increase in capacity, which is the same style of progression we had before except instead of focusing on +2 capacity per jump, the new number is +5. And because most builds will attach some type of Storage Unit, but Cogmind’s base inventory size has always been 4, to avoid creating a bunch of awkward inventory sizes like 9, 14, 19, 24 and so on, the base inventory size (the amount of storage with no additional units attached) was increased to 5. This makes any related mental calculations a bit easier.

Overall these changes to mean player power in the early- and mid-game are somewhat higher, but this is fine because it means we can more safely add more challenges there to compensate ;)

Cargo Storage Unit art.

The most common question among players with regard to this type of inventory cap is “what about full RIF builds?!” (maybe sometimes with more exclamation marks? :P) Since we could always adjust the RIF system if necessary, this wasn’t even a concern for me going into the no_stack experiment--wait and see, right? That’s just one secondary system, after all, whereas the goal here was to first modify a core gameplay element. It’s an inevitable question, though, seeing as some RIF builds focus on hoarding a huge supply of spare couplers as their main source of power, and using them in smaller numbers doesn’t require the support of numerous other parts so there’s plenty of room for storage utilities.

Once no_stack was implemented I did a full RIF run to test it out, as well as listened to feedback from patrons doing the same, and surprisingly even without any other changes it was actually a better experience! Despite a reduction in total inventory capacity, without the excessive amount of storage myself and others might choose to attach, there was plenty more room for active Relay Couplers, couplers which 1) don’t need to occupy inventory space anyway and 2) can help deal with threats (especially when combined with RIF abilities, many of which rely on having a relevant active coupler in the first place). Plus of course optional room for other non-coupler parts, too, such as infowar, armor, or whatever you need…

More active couplers = more fun :D

The full run is archived on YouTube:

(Also remember this is just relevant to “full RIF” builds, whereas there are alternate RIF strategies that use only one or two types of couplers, or even none.)

Players will notice that the Lightpack unique item is not included in the storage chart above; this is because it will be balanced differently given its special origin. And there is also room for additional unique storage types, in fact even more so given that they’re no longer stackable, since the knowledge that they must be used in isolation rather than potentially in combination with other Storage Units makes more interesting designs possible.

As for acquisition, the new Huge type can be found in stockpiles, and while the new Cargo Storage Units are unlikely to be found just lying around, they can still be fabricated from schematics, or taken from from a new type of robot and dispatch coming to Beta 11.

Up next in part 2 is a significant flight and hover rebalance, leg upgrades, overweight penalty changes, and more…