Official development blog

Inventory Management

Inventories are almost a staple component of any roguelike, and as such there is usually some amount of inventory management required to play them. Deciding what to carry for contingencies is an important part of roguelike strategy (plus it’s fun! …or cause to kick yourself later). For these decisions to be meaningful, games almost always place some kind of limit on inventory space. It might be a design-imposed static value (52, 26, or less), or derived from strength etc.

Cogmind has an inventory system, too, but at any point in the game it’s the player who decides how important a role they want the inventory to play.

How is that possible?

Dynamic Inventory Size

Cogmind has a very small base inventory size--only four slots, meaning you can only carry a maximum four extra items/parts. Relatively tiny by roguelike standards, but you can very well play through the game with this number.

Should you want the ability to carry more parts, you can control the size of your inventory by attaching storage modules of various weights/capacities. Thus these non-permanent expansions to your inventory come at the cost of utility slots that could be used to attach usable parts. Doing this essentially trades an amount of “immediately usable part” space for even more parts that are not immediately usable.


Base inventory size (left) vs. an inventory taking advantage of a single medium storage unit.

Inventory size varies greatly, from four items to dozens of items, based on how much extra storage capacity you want (and can fit). And in addition to play style considerations, as with any loadout in Cogmind the amount of inventory space can also be quickly changed to adapt to new situations, like significantly expanding capacity to carry along an entire stockpile of armor plating before an expected dangerous confrontation.

Aside from the temporary nature of storage expansions (like any other part you can also unwillingly lose a storage module when it’s destroyed), the most unique aspect of Cogmind’s inventory system is that it’s not controlled indirectly via some other stat (e.g. strength) that has a long-term impact on a character and also affects other aspects of their abilities. The trade-offs are both non-permanent and immediately transparent. “Right now do I want to increase my inventory size by four, or attach another type of active sensor?”

To a (very) limited extent, Cogmind’s inventory also takes volume into account. In the 7DRL prototype all parts were equal in size (one slot), while now we may have very large parts that occupy two or more slots. I wouldn’t want to go to far with this system and risk overcomplicating inventory management and item comparability, so it applies only to a small number of special parts. It’s still nice to have that option for flexibility in item design. Without it some of the amazing parts in the game wouldn’t be feasible since the player could potentially attach too many of them. (See more about large parts and how they look in your inventory in this old post.)

As for storage modules themselves, I opted to keep them all the same “size” (one slot) regardless of their capacity, instead differentiating them only by weight. This is to keep the system simple. Large storage modules are themselves much heavier--the weight of contained items is not taken into account, another abstraction of unnecessary detail.

As mentioned earlier, depending on your strategy it’s technically not even necessary to increase your inventory size. You start with a fair number of usable attachment slots (7), and that number can eventually rise pretty high (26!). In fact, before long you may not even need all your slots for active parts, leaving them free for occasional use as makeshift “inventory space.” The caveat: parts can only be attached in their proper slot type whereas inventory space accepts any item.

The Purpose of Inventory

Cogmind’s lack of consumables (read more about that design feature here) means you aren’t expected to be hoarding a lot of single-use items for contingencies, which is one reason the game can get away with this highly flexible inventory design.

So what is the inventory for, then?

If you’ve played the prototype, you’ll know that in certain encounters it’s likely you’ll lose more than a few parts that will need replacing. Your inventory is a good source of those parts--you’ll often find duplicates in stockpiles that can be carried around as spares. It’s also for storing alternate types of weapons/utilities/propulsion that you don’t have enough slots to attach.

However, this doesn’t imply you absolutely must have a large inventory. Sticking with a smaller inventory is perfectly possible, and results in an even more dynamic game since you’re forced to use what you find locally rather than what you’re lugging around (there is plenty of scrap to be found after a battle). It also means you’ll be slightly more prepared to immediately deal with different situations since you’ll have more useful parts attached at once (no slots occupied by storage). You’ll also weigh less, especially important for hover/flight propulsion.

So keeping your inventory small is a strategic choice.

There is one other factor to consider along with inventory size that you won’t find in most other roguelikes: attaching parts from the inventory has several associated costs (more than simply time). Attaching a part also consumes energy, which is generated free by power sources and usually not an issue, though it can be annoying when you’re in the middle of a fight and need to attach a new power source which may require shutting down active utilities and waiting for backup power to slowly recharge (because the battle already drew down too much energy). More importantly it consumes matter, a (semi-)finite resource. This puts a hard limit on the frequency with which you can swap out parts until you acquire more matter, usually by salvaging other robots.

Thus having a huge inventory doesn’t always mean you can effectively use it all, as it’s tied in to resource management. Related strategy tip: Even though it does take time to attach/detach parts, sometimes doing so while under fire is a good idea, and not too dangerous since Cogmind is nowhere close to a one/few-hits-and-you-die kind of game--taking some extra damage is not a huge deal. Attaching a part during combat will restore or provide extra functionality while also adding extra protection.

Forcing Decisions

In most roguelikes the design includes some gray area that offers ways to circumvent inventory limits. Games with persistent maps may allow the player to create a so-called “stash” where they can store items for later retrieval, or simply return to a previous area to scavenge for items left behind.

Neither of these is possible in Cogmind--you pretty much have to carry everything you may want to use later.

You can’t revisit previous maps (a feature to be explored in a future post), and anything left lying around will be cleaned up by recycler bots.


Recycler arriving to clean up a little pile of parts I left on the ground.

The only exceptions to recycler cleanup are intentional stockpiles placed on a map, but these are less reliably useful than gear known to drop from specific robots. You can get specific items by salvaging robots known to use them, but if you want them you’re going to have to take them with you.

In the 7DRL you could technically create a stash and come back to it as long as you remained on the same map and destroyed all the recyclers first. That strategy no longer works on most maps because new maintenance bots are dispatched to replace any that have gone missing.

Another different aspect of the new recyclers is that they no longer simply wander around carrying whatever junk they happened to pick up (you could originally chase them down and take them out to get parts back)--once their inventory is full they’ll actually take the parts to recycling stations and convert them to matter! (You can retrieve this matter from the station, unless it’s already reached a quota, at which point it will be transferred away.)

Altogether the system is designed to force inventory decisions. As a side effect, stash-free design contributes to the “eliminate grinding” philosophy.

That’s not to say there are absolutely no external alternatives to expanding inventory size, though other methods aren’t necessarily as reliable. The first which comes to mind are potential helpers--hacked haulers can carry stuff for you, but I’m not yet sure how effective this will be yet, as I haven’t tested it in true play. You can also remember existing stockpile locations (or hack to find them), since those won’t move. Stockpiles are like “randomized game-specified stashes,” but too much backtracking can be dangerous and wasteful (more so later in the game).


Update 160629: For an even more in-depth look at the advanced UI features aimed at facilitating inventory management in Cogmind, see this more recent post.

This entry was posted in Mechanics and tagged , , , , . Bookmark the permalink. Trackbacks are closed, but you can post a comment.


  1. kripto
    Posted December 5, 2014 at 5:51 pm | Permalink

    One thing you didn’t mention ( Or I’m blind and didn’t see ), if a storage unit gets blown up, will it’s contents get destroyed too? Or will they be fine? Or maybe a random chance of them surviving or not that depends on what destroyed the storage thing?

    • Kyzrati
      Posted December 5, 2014 at 7:57 pm | Permalink

      Good question--it crossed my mind while doing the final proofread this morning, but I didn’t think to add it in.

      I think the best solution in this case is the simple approach: The storage unit itself is destroyed, but only to the point that it can no longer effectively contain/deliver anything, so you lose the part itself while everything inside just falls to the ground (unless you have enough surplus capacity to continue holding it).

      Otherwise you run into issues of which objects are in which container (if you have more than one). That and almost everyone seeing a storage unit likely to be destroyed soon would, in the case of contained item destruction being a possibility, preemptively remove the items or handle them some other way anyway rather than risk it. Destroying the items would also be pretty mean ;)

      However, if we find that larger inventories are inherently superior in too many ways (not necessarily true), we could add a chance of item destruction to somewhat reduce their effectiveness and just say any item held in your inventory in general “could have been in” a given container. I’ve no doubt some players would get annoyed at the lack of control in this case, though.

      Related to this, one reader brought up a question on Twitter about the necessity of having a large inventory, as it might seem like lots of inventory space is inherently superior despite the added weight. While some players will certainly find large inventories beneficial, these will mostly be heavier builds relying on treads and legs for movement. They are naturally slower and will even need to carry extra parts because they will be forced to fight more/longer battles, being unable to make a speedy escape.

      Faster flying/hovering robots on the other hand theoretically don’t need to carry as many replacements because they have an easier time maneuvering around and away from enemies, and are also incapable of carrying too much weight anyway because it will slow them down to the point that they may as well be using treads. So unless you are already using a slow form of movement, you have to think twice about allocating weight to inventory space rather than usable items.

      It kind of balances out in the end, but exactly how to tune that balance it is up to the player.

      • kripto
        Posted December 5, 2014 at 8:35 pm | Permalink

        Yeah, that seems to be the most reasonable one to go for, I just thought I’d make sure. Thanks for the reply!

Post a Comment

Your email is never published nor shared. Only the anti-spam entry is required. See here for the privacy policy.

You may use these HTML tags and attributes <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>