Official development blog


Most roguelikes, and the vast majority of RPGs/item-heavy games in general, have consumable items. From a design perspective this makes a lot of sense since consumables are the easiest and most direct way to indicate that effect X can be achieved Y number of times. They’re also a logical way to enable the player to “find” (and carry, etc.) a limited number of abilities which are not necessarily linked to their character, adding a lot more dynamic potential to the gameplay.

The Cogmind prototype (7DRL) did not include consumables, initially because keeping a 7DRL simple is a good way to ensure finishing, and consumables happened to be among the underdeveloped features cut from the design. Sci-fi equivalents of potions and scrolls, things like “coatings” and “software programs,” are also not very appealing to me given the game world.

On rebooting development last year there were yet more reasons to leave out consumables. I like the game’s strong focus on parts--nearly every item in the game is a part Cogmind can attach, and consumables would really muddy up the existing inventory. A proper implementation of consumables would probably even require an entirely separate inventory system because their size and effects would make them so much unlike other parts as to be incomparable. Comparability is important when dealing with inventory use and weighing item effects/usefulness during the design process. One very common way to reconcile item comparability in roguelikes is to use weight, but in Cogmind the inventory doesn’t use item weight as a mechanic at all, and only uses space/volume to a small degree. I’m certainly not adding more inventories just for consumables.

Besides, Cogmind’s general mechanics already include a lot of the “dynamic potential” that consumables are able to provide, especially since you lose parts so frequently. Any item can be destroyed while you are using it, a mechanic very unlike those in most other roguelikes, one which overlaps with consumables. In a sense all parts are consumable.

Last year I did, however, add a new mechanic that simulates consumable items more closely by essentially accelerating the rate at which an item is used up: deterioration (see last section), but honestly I haven’t used it at all yet. I do really like it as a mechanic and think it fits well into the game, there just aren’t enough items yet to expand into that category. Perhaps it will find more use in a future expansion, but for now most of the game’s item list is complete (there are 630).

But Didn’t You Just Say…

And now for the main event!

Well, over the past couple days when I was supposed to be working on maps, I instead spent them adding a few consumables. Not deteriorating parts, mind you, but something more directly resembling traditional consumables: single-use parts.

One is a “disposable” weapon, where the part is the projectile itself; some have crazy special effects that involve trade-offs; others become a permanent part of you. All are very rare and unique so I won’t be giving you any details :). They’re also generally recognizable since they fall into a new sub-category of items that I can’t tell you about, either (spoilers and all…).

Like other special items, they’re not dropped randomly, but are instead found in prefab areas (though of course the locations of these areas are randomized).

So why add them? For one they’re either extremely powerful (well beyond what a normal part is capable of), extremely useful (offering unique benefits no normal part is capable of), or offer new tactical possibilities, which you may decide you need/want to have when tackling the end game, especially if you decide to go after a boss.

They are all late-game items, and very limited since you’ll only find a handful during a given playthrough. There aren’t many types in all, but they do run the consumable effect spectrum from buffing, attacking, escaping, to the all-encompassing “special effect.”

I like how they’re implemented as actual parts, which fits well in the game both mechanically and according to the lore (the latter you’ll have to wait and see). As parts you’ll still have to attach them to use them, but they take effect and disappear immediately after connecting them to your core.

Okay, I wasn’t planning on going into details about the new consumables, but I need an image for this post! So here is Cogmind attaching a Terrabomb, which instantly vaporizes all wall and earth over a huge radius. Lots of potential uses for this one…


Activating a Terrabomb.

Other Consumable-like Features

Two other previously unmentioned elements are consumable in nature, and while neither has been implemented yet, I’m pretty sure both of these features will be a thing.

The first is secret single-use hacking commands. There won’t be many of these, but I’d like to have NPCs provide you with a few that can be later used to achieve special effects. You can, after all, type in anything you want at any terminal (see the section on manual hacking for an example). This is an interesting take on “consumables that can only be used in a certain location.”

The other is dynamic terminal passwords. By destroying Operators, robots that oversee local activity, you may obtain their terminal password which can, within a certain time limit, be used to improve your chances of successfully hacking a terminal. Each can only be used once, though, before the system will catch on to you and change the passwords immediately.

A Note on Progress

This past week I got seriously side-tracked, which I’m sure will happen more and more as the end of development nears (it’s not “near” but it is “nearing,” ever so gradually =p).

Last week began with work on a new category of randomized map content (room-based encounters), but before I could continue I had to finish deciding what kinds of encounters were necessary, then while beginning to implement those I needed to define more clearly the remaining robots missing from the roster, so I started on that and couldn’t quite finish because some of them were NPCs and would make use of special items that hadn’t been added yet, so I started adding a couple of those and figured I might as well do all the ones I can think of…

So here I am adding consumables--ha, pushed all the way back to item development! There are not too many of them, but each one takes a good bit longer to implement than a normal item since they are unique and have special behaviors (i.e., more to code). They’re certainly lots of fun, at least.

Next week I should be back on track with robots, and then finally get back to map encounters…

Update 181119: It’s been over four years since this original post, and Cogmind has grown quite a bit in the time since. I’ve written more about the state of consumables here.

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


  1. Posted August 17, 2014 at 2:14 am | Permalink

    I haven’t read most of your posts but I did see a while back your weapon creator. Which reminded me of Borderlands random generated weapons properties (or better items). Have you thought of doing something like that with Cogmind, random generated item proprieties? A gun can have x damage, x accuracy, x reload, x fire rate, x element, x type (shotgun, machine gun, bazooka, pistol, sniper, etc…)

    • Kyzrati
      Posted August 17, 2014 at 7:12 am | Permalink

      Diablo-style randomized items are best suited for grindy games with insane amounts of loot, which is meant to make the grind slightly more bearable. Cogmind is designed to have no grind whatsoever (being without XP), and I like that every single item is handcrafted to set property parameters in line with type and many other considerations (lots of cross-referencing involved).

      Yes, there are a lot of items, and I did use spreadsheets to keep certain stats within a basic progression of (only) 9 levels, but the value ranges are actually quite low (late-game items are often around 2-3 times better than early items) and items are made more unique by properties that aren’t reflected in the progression. The spreadsheets were a basis for reference only--some weapons may even have damage equivalent to weapons two or more levels higher than their own, because that is part of the lore for that that particular weapon. The high number of items comes mostly from the fact that there are so many unique types of items with completely different behavior. For example, more than 1/3 of all items are utilities, and those are divided among 83 unique abilities. Weapons are similarly sub-divided by their special qualities like disruption potential, overloadability, penetration, critical potential, multi-shots, guided, damage type, and unique special effects. So the seemingly large number of items is actually closer to a minimum number needed to make use of the many different properties available--most weapons are defined using only a small selection of potential properties.

      In Cogmind, discovering what items do or hoping for a random item with ever so slightly better stats should not be a meaningful part of the experience for non-beginners, so I’d like that part of the game to be static. If stats are randomized, because there are already many parts being dropped players end up spending a lot of the game looking at and comparing numbers, which can be facilitated with the right UI, but is still pretty boring in my opinion.

      Many players do enjoy the grind, but I’m not seeking to attract the type of player that most enjoys looking for the next +1 damage weapon. I want tactics and strategy! A design that emphasizes a growing meta-familiarity with what each item is good for makes for a smoother experience in that regard, even more so for a relatively short game like Cogmind.

      Funny that just yesterday I happened to be thinking about this topic when recalling players asking if X@COM would have randomly generated items. It just doesn’t work well with most strategy games, unless you make the differences relatively trivial, in which case why have them at all?

      (Sorry: This is not a diatribe, just spilling thoughts on the matter since it hasn’t been discussed before!)

      • Posted August 17, 2014 at 7:39 am | Permalink

        Thx for the answer. You do have a point there. It was just a thought.

        • Kyzrati
          Posted August 17, 2014 at 7:46 am | Permalink

          No problem, thanks for bringing it up. It is definitely a topic worth exploring, especially since roguelikes are known for pushing lots of randomized content.

  2. AlanWithTea
    Posted August 24, 2014 at 8:05 am | Permalink

    I like the thought process here. I’m always in favour of asking the question “does this add something worthwhile?” and I applaud you for refusing to include consumables simply because it’s the ‘normal’ thing to do.

    • Kyzrati
      Posted August 24, 2014 at 8:17 am | Permalink

      Thanks. A game’s design principles should trump all other considerations. Consumables just don’t fit here, so… no go. In a lot of other roguelikes, however, they certainly do fit. There is also something to be said for holding onto elements with which genre fans are familiar. A lot of Cogmind’s elements are experimental and come together to form what is essentially a game very much unlike most other roguelikes. This can be both a good and bad thing ;)

  3. Posted April 25, 2018 at 2:01 am | Permalink

    A roguelike without consumables?
    Insta-buy from me

    • Kyzrati
      Posted April 25, 2018 at 7:12 am | Permalink

      Hehe, yeah it’s a departure from the norm, though it’s also important to point out that the other departure from the norm is such that there’s rampant item destruction, causing most items to act like “consumables” in the long term :P

      (Once you get good at Cogmind this is less of an issue, but for new players it can be a bit of a shock!)

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>