Official development blog


Cogmind is a game about robots, so it’s about time we talk about them (finally!).

It’s taken quite a while to get to this point because robots are built upon the game mechanics and items (and to an extent, the story), so holding off on this central element enables us to consider the full range of options when designing them. In a few special cases items were created to support a specific robot concept, but plenty of unique robots emerged from the existing item set given the huge range of available parts. And I don’t mean superficially “unique” as in simple stat modifications like “extra +2 damage here!” or “more armor on that one!” Enemy robots differ significantly in their loadout and behavior, and will thus require different tactics to deal with.

Last week I finished off a majority of the designs and data entry for the new robots in order to continue pushing ahead with world building, a process which got bogged down with unknowns in the encounter system (since we didn’t have all the robot designs in place yet).

Anatomy of a Robot

First some background.

All robots are composed of a “core” and any number of attached parts. A robot is destroyed by destroying its core, which may even require only a single hit in some cases, though it’s more difficult to hit a core while it’s covered by parts. You often end up destroying some parts first, causing the robot to lose whatever functionality those parts were providing.


A mockup blueprint for the H-66 Slayer, a class 2 Hunter robot. ASCII art shown for parts is that for the various parts from the game, but there are no composite images like this one in game. (No art or visualization is planned for robots; I put this together specifically for this post, drawn in REXPaint.)

Note that although it would seem more realistic and even add greater tactical options, you cannot target specific parts, as that would make the game too easy--just disarm everyone, or target their propulsion system and run away! (Solutions such as making weapons more difficult to hit/destroy would imbalance the part systems.)

The core+parts system is no different from yourself, the Cogmind, as all robots follow the same rules. From an implementation perspective this is usually the best way to go about handling the player in a roguelike (it’s also much easier to balance a game in which more of the content is directly comparable, rather than asymmetrical). With Cogmind in particular, it allows for much tighter game design since you can cannibalize other robots for parts. Any of them. If they can do it, so can you. This even applies to some of the very interesting special effects.

Base Classes and Subvariants

I’d rather leave most of the content to player discovery, but seeing as the prototype has been in the wild for a while and played by many, I’ll use that as a starting point for the discussion.

Essentially I’ve imported all the same base classes from the 7DRL:

  • Watcher: Unarmed surveillance bot that warns nearby combat robots to enemy presence.
  • Swarmer: Small flying bots that work in larger groups to overwhelm intruders.
  • Grunt: Basic gun-toting front-line combat robot.
  • Sentry: Slow heavily-armored guard bot.
  • Hunter: Fast and deadly robots that work in pairs to track down threats with a vengeance.
  • Programmer: Track down rogue bots and corrupt them using electromagnetic weaponry.
  • Behemoth: Large war machines tasked with guarding high-value locations.

Each class has its own ASCII letter, ‘w’ for watcher, ‘s’ for swarmer, etc., using upper case for any that are considered “large” (easier to hit), e.g. ‘Y’ for sentry, ‘B’ for behemoth. Actually, this time around you’ll also find that a few really large robots even occupy multiple spaces, like the behemoth (four spaces--a 2×2 square; read more). Fleeing through a narrow corridor or doorway is now a valid way to escape them :)

Several sub-variants exist for each of the classes where better variants are constructed from similar but better parts, and often lead squads, if applicable, or simply appear on later levels. There are on average three variants per class, distinguished by color on the map, and of course by name everywhere else. Taking the watcher as an example, early in the game they appear as the W-16 Scout, then later on as the W-25 Informer and W-44 Eye. The prefix before each robot name tells you 1) the class (letter) of the robot and 2) their relative threat level on a scale from 1~99. Watchers themselves cannot harm you, but are dangerous because they’ll attract much more unwanted attention. Beware higher numbers.

Cogmind doesn’t belong to any class--you’re obviously not quite like them, a premise explored by the story.

Named NPCs are all unique robots as well.

More Classes, and Variety

In addition to the above list, there are eight new base classes for combat robots. The cool thing is none of them use normal “guns,” i.e. it’s not a case of simply adding many more shades of “attacks for X damage.” Thus much of the expansion since the prototype has been in terms of variety, not simply expansion for expansion’s sake.

True roguelike design should embrace elements and content that promote new interactions and emphasize tactical differences rather than the grindy hack-and-slash of your average RPG. While Cogmind has its fair share of numbers and stats to pore over, in the end I want the game to be more about strategic calculation, not mental math with stats. You don’t have to worry too much about the details, just be sure to put yourself in the right position and make choices that reflect what you’re best at and you’ll generally come out ahead. When playing the 7DRL I could do quite well without closely examining all the stats, instead simply using the highest-rated parts I could find and basing my decisions/actions on the strategy most suited to those types of parts. This will no doubt frustrate some players who do want to calculate everything in detail. (For that there is an optional console to see a breakdown of every attack calculation, if you must.) One advantage of this kind of design is that it makes the game a lot more accessible than it might otherwise appear. [/aside]

Back to the new classes… I won’t list them here, but know that there are robots with a melee focus, or a special kamikaze-like attack, or who hold you in place and study your composition and loadout (for devious purposes, mwuahaha), and more.

Support Robots

There were plans to include at least one kind of “support” robot in the 7DRL, but they were cut due to time restrictions. Now they’re definitely in, and there are a few different classes. Support robots have no combat capability of their own, but serve to boost or assist allies in some way. Gaining them as followers is a good way to improve your own survivability without attracting the attention that raising an army of lethal robot killers would ;)

Non-Combat Robots

One thing you don’t often see in roguelikes, or at most only in small numbers, are creatures that don’t have an impact on combat. On one hand we can attribute this to the premium on letters and map space in ASCII roguelikes, as well as the genre tendency to minimize “fluff” in boiling gameplay down to its most essential elements.

But Cogmind’s setting is not your average dungeon in which every denizen is out for blood. It’s a subterranean complex supposedly inhabited by a robot civilization of sorts, so even if just for atmosphere we need it to actually be inhabited. Fortunately we can always populate the maps with thematic robots that both have a purpose and serve as fluff.

You can already see this in the prototype (7DRL), with tunnelers excavating new areas, workers clearing debris, recyclers cleaning up the aftermath of a battle, haulers carrying parts around, builders reconstructing walls and doors… These robots will generally ignore you and go about their business.


Engineers at work, or “Hey! I just blew that up!” (Yes, they will seal you behind a wall if you are in the way.)

If you can gain control of them, you can also have them work for you doing whatever it is they normally do: carry extra parts, build walls to block off areas, dig new tunnels…

In a pinch, non-combat robots are also an easy way to farm parts. The parts won’t be the best, but it’s nice to know you can easily get access to at least a basic power source, or wheels, or utilities like a hauler’s storage unit, a recycler’s tractor beam, a tunneler’s seismic analyzer, a builder’s structural scanner, etc.


Destroyed robots leave behind salvage, which comes in two forms: matter and parts.

The ambiguous “matter” is used as the ammo for ballistic weapons and most explosives, as well as a resource consumed to attach new parts (fuse/link them to the core). The amount of matter remaining when a robot is destroyed depends on its class and what weapons it was hit by (not just “destroyed by”--it’s a cumulative effect). Blasting robots to pieces with explosives will leave much less salvage than pinpoint targeting with lasers, or even better, corrupting the target’s system with EM projectiles. This is one way for the game to limit the use of explosives (besides the obvious “he’s using explosives send in everything we’ve got!”), since powerful explosives require a lot of matter to use, but in turn you’ll receive less matter for using them too frequently.

Parts dropped by destroyed robots will usually be somewhat damaged, but are nonetheless a great way to to augment (or at least restore) your capabilities after an encounter. This is pretty much required, actually, since you won’t always find enough stockpiles of fresh parts when you need them. Nor is there unrealistically dropping of random parts from robots--they can only drop what they themselves use (and still have at the time of destruction). Thus with only a few special-purpose exceptions, all robot designs are static, enabling you to know what to expect when confronting a given type of robot, and also hope that certain useful parts will survive their destruction. I love taking cloaking devices and targeting computers from downed hunters (see first image), and I almost always track down a hauler early on to expand my inventory capacity.


Taking out a U-05 Engineer, which leaves behind some matter (‘%’) its structural scanner (‘!’) and light ion engine (‘*’).

Static robot designs help solve a common problem with roguelikes: relying entirely on random drops (which are usually not type-weighted in any way) can have the player feeling like they are completely at the mercy of a merciless RNG in terms of loot. Like that wizard who just never seems to find a staff. Randomness is good, but not when you have zero control over your destiny and it happens to kill you by denying access to fundamental items. Shops are occasionally used as a way around this (giving you a choice of items from among many), but that’s only half a solution because their stock is still random. This is really more of an issue in games that have a huge range of potential items, and Cogmind is one of those games, so I like that the player has a semi-reliable way of obtaining essential parts.

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


  1. ConstructUnit_5m:13
    Posted August 27, 2014 at 12:50 pm | Permalink

    Will the construction robots always be sent to damaged locations? It seems like if they know it was a weapon that caused the damage, a combat drone should clear the area before sending in non-combatants. It would be hard to believe that if there is a rampaging PC known to be going around, at least some of the workers didn’t need an armed escort, right?

    • Kyzrati
      Posted August 27, 2014 at 7:57 pm | Permalink

      Hello ConstructUnit_5m:13, welcome to your new home :)

      Non-combat robots are fairly mindless and stick to their assigned tasks, only calling for help if they themselves are under attack (at which point they also flee). Technically if the enemy’s entire force is working together at the full efficiency you might expect, and you are considered a high priority target, you would die very, very quickly ;) They only devote resources to deal with actual current threats, and only as much as they think is necessary--you are not the only potential threat, nor are you necessarily considered dangerous (especially not until later in the game).

      Most maps already have a significant contingent of non-combat robots roaming around working, so those that show up on their own are just the ones tasked with maintaining the local area. However, if you start intentionally remodeling the dungeon, the enemy will send in engineers and tunnelers along with armed escorts to deal with the situation.

  2. Posted September 3, 2014 at 4:09 am | Permalink

    Note that although it would seem more realistic and even add greater tactical options, you cannot target specific parts, as that would make the game too easy--just disarm everyone, or target their propulsion system and run away! (Solutions such as making weapons more difficult to hit/destroy would imbalance the part systems.)

    While you can’t target specific parts, can one type of weapon damage only specific parts? Like a “pacifier” pulse bomb disabling all weapons in the vincinity or a “dance beat hacking pulse” making all robots system fry while making propulsion systems move totally random!

    • Kyzrati
      Posted September 3, 2014 at 10:07 am | Permalink

      “Dance beat hacking pulse,” hahaha…

      Broad effects like that seem more suited to consumables since they would be too effective compared to other parts. Unless we make them not entirely reliable (in which case many players won’t bother to use them) or give them a very high resource cost.

      I do like those two ideas in particular, though; I’ve added them to the list of long-term potential enhancements. Similar to what you describe, robots corrupted from EM damage may move randomly instead of in their intended direction, but the tactical possibilities of having it as a controllable effect over an area are interesting.

      As a way to prevent them from being infinitely repeatable, effects like this could possibly fit into the design as rare late-game consumables I described earlier, or in combination with the deteriorating part effect (which isn’t used anywhere yet), like a utility that disrupts propulsion systems within a certain range but gradually loses integrity itself in the process.

      • Reiver
        Posted September 5, 2014 at 5:44 am | Permalink

        Hm. The Pacifier could be fun if it hits your guns too, eh?

        Either leave ’em behind and advance to cripple the ambush that’s waiting for you before running back to rearm, or keep it as your precious Plan B on a stealth run…

        • Kyzrati
          Posted September 5, 2014 at 8:02 am | Permalink

          Yep, that would be interesting. We’ll see how adaptable the AI is when impacted by special effects that affect status and therefore behavior. Right now the AI is honestly way too simple--it’s fun to play against, but it won’t be able to elegantly deal with odd situations. Not too long from now I’ll be moving into AI development, and I’m still wondering whether I should just fill in the remaining behavior or redesign it completely which would entail refactoring a lot of already completed work…

          On a related note, I’ve been worrying that I’m spending way too long developing Cogmind considering that the 7DRL phase put together a fun and simple game in very short order. I’ve spent many times that amount of time on development already, though I’m not sure if it’s “many times the game.” Probably just me underestimating the game’s value, but I can’t help it.

    • Moral Molar
      Posted March 26, 2015 at 4:17 am | Permalink

      The pacifier effect affecting guns in an area would be a great advantage for melee fighters. Disable the guns, run in and smash as many robots as possible before they get the fire capability back.
      However, the natural AI response to a gun-scrambling AoE is to scramble away from the epicenter and then fry the enemy -- or shoot the jammer if it’s shootable.

      • Kyzrati
        Posted March 26, 2015 at 10:32 am | Permalink

        True, though enemies without usable weapons will flee and you still have to chase them down.

        There are several other effective approaches for melee attacks, e.g.:
        *Ambush robots from around corners
        *Use superior speed to get in their face before they can do much (plus moving quickly also helps you avoid attacks)
        *Temporarily disable a robot via special disrupting weapons, then approach before they reboot (these attacks can also affect a target’s weapons, but you can’t count on either happening)

        There is still the possibility of adding an area-effect ability as described, later on in another form. It’s in the design doc, but I won’t introduce the details until if and when it’s implemented.

  3. Xecuter
    Posted December 3, 2014 at 4:32 am | Permalink

    First off, I have to mention that I only very recently learned about Cogmind and I’m giddy with excitement! Bravo! It seems like its shaping up to be a glorious RL. I. AM. STOKED. I’ve been binge-reading the blog in chronological order and I wish it would never end.

    Second, why are you so cruel, master!?
    “A mockup blueprint for the H-66 Slayer, a class 2 Hunter robot. ASCII art shown for parts is that for the various parts from the game, but there are no composite images like this one in game. (No art or visualization is planned for robots; I put this together specifically for this post, drawn in REXPaint.)”

    Looking at this image, I can’t help but imagine some sort encyclopedia cataloging parts, robots, machines, etc. with those blueprint-type rendition for fluff.

    Super-quick mockup using your images:
    I leave you to imagine some tree-based navigation window with categories and entries on the left side

    Every time the Cogmind encounters a new robot/part/machine/etc., a new entry could be added with very little detail except some nice ASCII art (can’t overstate how much I like your ASCII art :D) and using sensors/scanners could further populate the entries with more info.
    This encyclopedia would need to be permanent between games for it to have any kind of value.

    I know you mentioned several times that immersion is an important goal for Cogmind, so that kind of permanence between “runs” most likely doesn’t fit in your vision. However, being kind of a sucker for that kind of player-dependent repository of knowledge, I had to mention it!
    One can dream, right?

    One last thing: I’m throwing money at the screen but nothing’s happening :(

    • Kyzrati
      Posted December 3, 2014 at 8:03 am | Permalink

      Glad you’ve managed to wade through the entire blog ;). Stay tuned for ever more long posts which I’ve already written but are being posted only intermittently because a lot of work went into them! (Was considering a new post yesterday, but decided to postpone it for a couple days because the last one was so lengthy and only posted a week ago.)

      You’re not the first person to suggest/hope that robot images like this find their way into the game, but you are definitely the first to try and convince me by using a mockup =p. You’re right that any kind of permanence doesn’t really fit the theme, especially since (unlike the 7DRL) having detailed knowledge about robots even gives you benefits against them. However, something like these images could possibly have their use outside the game. Maybe in an online reference? Or as a reward of some kind?

      Even so, it would be pretty low priority considering that there are over 100 robots,
      and assuming each of these takes 10 minutes to put together, that’s a couple days of work! Writing a system to do it procedurally rather than manually would either produce mediocre results or take a very long time, which is another reason against using it in game, at least for now.

      I may make some more in the future for fun. Actually, I should make a really stylized one to fit among the Cogmind wallpapers which will be coming out soon. Thanks for reminding me. If you like the ASCII art you’ll love these :D

      > One last thing: I’m throwing money at the screen but nothing’s happening :(

      Well, something’s happening over here--I may not be getting paid yet, but I’m working on it nonetheless! ;)

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>