Official development blog

Cogmind ASCII Art Gallery

Cogmind’s ASCII art has drawn a lot of attention where it’s been shown on Reddit and Twitter, but I haven’t  been showing much of it here on the blog. I suppose it makes sense to accumulate enough of it for a grand one-place-to-go-to-see-Cogmind-ASCII-art type post.

This is that post ;)

ASCII art style is traditionally divided into only a handful of categories: shaded art that uses groups of characters based on their pixel density, block art (similar to pixel art, but with really big pixels), and line art. Cogmind falls into the last category, relying mostly on line segments and the occasional block or other glyph to form a semi-abstract outline of an object and its details.

In terms of game objects, Cogmind contains art for both items and machines. You won’t see robot art--their appearance is left entirely to the imagination (except in tiles mode, of course).

For more general reading on the background of ASCII art in roguelikes and Cogmind, see this earlier post.


The majority of the art belongs to items, of which there are currently 638. It took about two weeks (103 hours to be precise) to draw and paint each individual item, including the time spent working on concept sketches and color schemes.

Keep in mind that in choosing the following art, to avoid spoilers (and giving away all the best stuff) almost no high-end parts are shown. Many of those you’ll find in the game look cooler than what you see here.


Weapons make up a third of the items, and therefore about a third of the art. They’re the only category that makes heavy use of color themes for easier recognition. Among them you’ll notice green, yellow, or blue for energy weapons, changing to orange, red, or purple for many of the more powerful ones. Most ballistic weapons use a brown/white scheme, though they break that mold at higher ratings.

Guns, Ballistic (Kinetic): Cause variable damage, have high recoil, and are effective at very long range. Also more likely to inflict critical damage, instantly destroying the target component.


Minigun, High-powered Shotgun, Heavy Machine Gun

Guns, Thermal: Damage has low variability, and firing causes no recoil but is usually only effective from short to medium range. Also increase target heat on successful impact.


Particle Gun, Quantum Rifle, Heavy Gatling Gun

Guns, Electromagnetic: Cause less physical damage in exchange for the ability to corrupt the target’s systems, an alternative way to destroy a robot. Some EM weapons are also capable of temporarily disabling individual components or an entire robot.


Arc Projector, Gamma Rifle, EM Shotgun

Cannons, Ballistic (Kinetic): More powerful version of ballistic guns--heavier, and drain more resources.


Mass Driver, Assault Cannon, Gauss Cannon

Cannons, Thermal: More powerful version of thermal guns--heavier, and drain more resources.


Plasma Cannon, Phase Cannon, Neutron Cannon

Cannons, Electromagnetic: More powerful version of EM guns--heavier, and drain more resources.


EM Pulse Cannon (there are few EM cannons--don’t want to reveal them all here)

Launchers, Explosive: Affect all targets in the area of effect, dividing damage into chunks that are applied randomly across each target. Targets further from ground zero usually take less damage, and there’s rarely useful salvage remaining from targets hit by explosives.


Heavy Rocket Launcher, Neutron Missile Launcher, Hellfire Missile Launcher

Launchers, Electromagnetic: EM weapons that affect all targets in the area of effect. Collateral damage is low, though these are the most effective way to bring down multiple armored targets at once.


Advanced EMP Blaster (there are few EM launchers--don’t want to reveal them all here)

Special: Unique weapons that don’t fall into any other category, either tools or those with special effects.


Mining Laser, Plasma Cutter

Melee, Impact: Cause knockback, and the impact is much more likely to damage fragile internal systems.


Great Maul, Heavy Flail

Melee, Slashing: High damage, and capable of severing parts clean off the target.


Chainsword, Plasma Sword

Melee, Piercing: Critical strikes are more likely, in addition to a bonus to directly damage a target’s core.


Lance, Kinetic Spear


Another huge and varied category. However, colors for non-weapon item types generally don’t follow any particular scheme, instead using whatever looks good for that particular design or makes the most sense conceptually. The primary exceptions: matter-related parts are usually purple, and processors/hackware are colored based on the stat they augment:


Processor/hackware color schemes.

Processors: Lightweight components that benefit a single stat or ability. For these I went with a microchip-style appearance (border style indicates the relative effectiveness of each part).


Launcher Guidance Computer, Improved Signal Interpreter, Advanced Target Analyzer

Hackware: Like processors, except their benefits apply specifically to hacking.


Footprint Analyzer, Improved Hacking Suite, Advanced Deep Network Scanner

Armor: Physical protection, often with special properties like defense against certain damage types or focusing coverage on certain areas.


Reflective Medium Armor, Insulated Light Armor, Core Shielding

Cooling: Devices that dissipate heat, for those loadouts which produce excessive amounts of heat under certain conditions.


Heat Sink, Cooling System

Defense: Large subcategory of shields, fields, and subsystems that block or absorb potential damage or negative effects.


Heat Shielding, Advanced Thermal Shield, Force Field (top row); Improved Remote Shield Generator, Anti-missile System, Improved Energy Mantle (bottom row)

Offense: Enhance offensive capabilities of some weapons, or mitigate negative side-effects of their use.


Improved Particle Charger, Recoil Stabilizer, Overload Amplifier

Resource: Enable Cogmind to manipulate or alter the behavior of mass, matter, energy, heat, salvage etc.


Advanced Power Amplifier, Weight Redistribution System, High-powered Tractor Beam

Sensors: Devices for detection and analysis of the surrounding environment.


Improved Sensor Array, Long-range Terrain Scanner, Structural Scanner

Stealth: Prevent enemies from tracking and swarming Cogmind, or evade attack more easily.


Advanced ECM Suite, Improved Transmission Jammer, Cloaking Device

Storage: Hold parts and resources.


Small Storage Unit, Energy Well, Improved Matter Compressor

System: Help deal with system corruption, memory issues, and a range of malfunctions.


Error Protection Suite, Recalibrator, System Purifier

(The above groups were subdivided for art categorization purpose--as classified in game utilities fall under only six designations: Devices, Storage, Processors, Hackware, Armor, and [REDACTED]. The last category you can discover later in the game.)


Flight: Don’t support much weight, but definitely the quickest way to get around, and even fly over enemies.


Electron Diverter, Diametric Drive, Nuclear Pulse Thruster

Hover: A fairly fast form of movement that can still support a good amount of weight (the viability of both hover and flight have been improved significantly over the 7DRL version).


Aerolev Unit, Gravmag System, Anti-grav System

Wheels: Easy to find, but hard to keep--most wheels are not made for combat.


Compact Wheel, Wheel, Armored Wheel

Legs: A good mix of weight support and speed. And yes, you can hop on one leg ;)


Flexi-carbon Leg, Myomer Leg, Centrium Leg

Treads: Slow and heavy duty, for the tank that needs to carry everything and the sun. (No really, you can carry a miniature sun if you need the power.)


Light Treads, Medium Treads, Heavy Treads


An essential but not so varied category in terms of game mechanics. By functionality, the main subdivision for power sources would be “standard” vs “light/micro” versions, where the latter weigh less but in turn come with little capacity for energy storage. But this division is not reflected in the classification system, which is instead based on power level:

Engines (1-3)


Ion Engine, Deuterium Engine

Cores (4-6)


Nuclear Core, Fission Core

Reactors (7-9)


Graviton Reactor, Vortex Chain Reactor


In this case the art is the on-map image itself, made possible because machines are multi-space props, something you don’t see too often in ASCII roguelikes.

Interactive Machines

The five types of interactive machines have each been covered before--this post contains links to pages describing their functions (along with art, though some has changed since then). Below you can see some variations of Terminals (T), Fabricators (F), Scanalyzers (S), Repair Stations (R), and Recycling Units (Y).


A selection of interactive machines (map excerpts).

Non-Interactive Machines

This category of machines is mostly for atmosphere, though some may explode if not treated nicely. There are over 100 non-interactive machines which appear in areas that make sense for their intended function.


A selection of non-interactive machines from the early game.

See more non-interactive machines in their native habitat here (guaranteed lots of destruction and explosions :D).


It’s really fun to combine static art with the scripting engine to animate it. The engine can import ASCII art files and move glyphs, manipulate colors, handle image layers separately, reference specific art coordinates…


All the item art appears in the data screen for their respective item. Opening info about an item displays its image at the top of the window, animating its appearance:


Animated appearance of item art

Title Screen

The game already features some full-sized screens of procedural ASCII, though the title screen is the first of them to combine static art with animation:


Cogmind title animation (click for full size).

Read here for more about how the title screen was put together.

More such animations will be added later for components like the evolution, game end, and game over screens.


I also consider the UI to be art, though more so when in motion.


Compilation of nine different interface elements as they appear in use (3.5 MB gif).

Even more animated interface elements can be seen in earlier posts about UI feedback and information warfare.

Particle Effects

ASCII particle effects are similarly a form of art, and come in various styles unique to Cogmind. The primary difference being that none of their components are manually drawn--they’re created purely by procedural scripts. Many of these have been shown before in dedicated posts here and here, and their making was discussed here.

Doesn’t hurt to show some more :D


Compilation of ASCII particle effects.



ASCII particle effects--stills from the above gif.

Creating ASCII Art

All of the art in Cogmind was created using an in-house tool: REXPaint. I’ve made it freely available for anyone to use, so check it out! In a future post I’ll be covering REXPaint’s many potential uses in roguelike development.

If you’re interested in the process used to create some of the game’s art, specifically the item art, I’ve written about it in detail here.


Neutron Missile Launcher ASCII art time lapse.


Notice: Cogmind has been nominated for Indie of the Year 2014! Thanks to everyone who voted in the first round! Please vote again in the final round to see how high we can get.

Posted in Art | Tagged , , , , , , , | 4 Responses

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).

Posted in Mechanics | Tagged , , , , | 3 Responses

Information Warfare

Knowledge is king in roguelikes. I’m not talking meta knowledge--that’s important, too, but this is about situational knowledge at a given point in any single run. Roguelikes are all about exploring and confronting the unknown (see intro to old fog of war post), and success is all that much closer if you can uncover as many unknowns as possible before they somehow result in your death. This is especially true in Cogmind, where a number of maps are quite large (thus containing many angry robots) and if you make too many wrong turns while unprepared you could end up with an unmanageable situation that can only spiral further out of control.

The most vital component of information warfare is knowing “what is where.” This knowledge influences where you move, both within a small tactical area and on a greater strategic level, creating all subsequent situations and leading to all other results. In a static or even linear game this is not much of an issue, but with roguelikes we have randomized map layouts and content, hence this factor retains its importance every time you play.

Utility parts are the primary means of obtaining that information. For that purpose we have sensor arrays, signal interpreters, seismic analyzers, terrain scan processors, structural scanners, spectral analyzers… you get the point, there’s a lot of options. You can’t realistically use them all, so you have to pick what you think is more important--or whatever you can find (and maybe carry some alternatives in your inventory).

*Note that you can also forget all this and attempt to just blow everything away. This is stuff for the cautious ninjabot.

Robot Knowledge

You always have access to the basic attributes of a robot by simply opening its data page, which will show you its class, size, rating (sort of equivalent to level/difficulty), movement type and speed, core integrity, current temperature, and any weapons.

Attaching a Scan Processor will add to that a full parts list, including internal components, and better versions report core exposure (how exposed the core is to attack), salvage potential if destroyed, and damage resistances. It’s not the greatest part to dedicate a slot to since player experience (or spoilers) eventually render it mostly useless. (I’d actually like to expand the usefulness of the Scan Processor and have an idea how to do it--maybe later.)

Sensor Arrays, which allow you to detect robots outside your field of vision, are far more useful. In fact, the ability to know what robots are where outside your FOV is so powerful that two separate parts are required to get the full effect:

  • Sensor Arrays only tell you where there is something within their detection range. No more details, just a blip.
  • Signal Interpreters can tell you more about those blips, ranging from size only (low-end interpreters) to class or even specific robot (high end).

This mechanic is made more interesting by the fact that not every robot out there is an enemy. So you can technically get by without a Signal Interpreter if you don’t mind the occasional false alarm, or you can learn to differentiate certain blips by waiting a bit and watching its movement pattern.


Watching nearby robots move via Long-range Sensor Array (no interpreter).



The same view with and without the Advanced Signal Interpreter, which shows those robots with as much detail as if they were in your FOV! Going straight or left here we’re going to run into enemies, and simply turning the corner we’ll be spotted by a Watcher.

With information like that you can be a lot more confident in your movements--plot a path around hostile robots, or prefer to take on those you are better equipped to deal with, or dodge a passing patrol by ducking into a room (enjoying a suspenseful wait to see whether they plan to visit your hiding place or not ;))


Continuing on the concept of map-based informational feedback covered in the previous post, activation of all informational utilities is now accompanied by a UI animation. These animations are meant to 1) look cool, of course!, and 2) provide additional feedback where possible. If anything the animation will at least remind you of the utility’s area of effect. (Alternatively that same information is available to mouse users by simply hovering the cursor over the utility in the parts list, which shows the AOE faintly superimposed over the map.)

Activating a Sensor Array shows not only its radius, but also each known robot’s relation to you: hostile (red), neutral (gray), or friendly (green).


Activating an Improved Sensor Array.

Activating it can quickly pick out the threats if there are a large number of robots milling about. And remember you can repeatedly deactivate/reactivate utilities, since it’s a free action, anyway.


Activating a Signal Interpreter on top of that Imp. Sensor Array.

With a powerful enough Signal Interpreter, robot labels (discussed in the previous post) also work for those outside your FOV while the interpreter is active.


Signal Interpreter with robot labels.

Map Knowledge

Knowing where other robots are is only one piece of the picture. Sure they’re the only potentially dangerous thing out there, but at the wrong place and time that danger can multiply based on the map layout. Plotting an optimal path through unexplored territory is difficult without at least clues as to which routes won’t lead to dead ends where you may be forced to fight. You can also save yourself a lot of trouble by finding ways to circumvent enemy positions. Recall that the main goal in Cogmind is to locate and reach exits, so one way to increase chances of survival is to search the map as efficiently as possible before attracting too much attention.

In short, you want ways to reveal the map. This is a pretty powerful ability to have and thus, like robot sensors, the full effect is divided between two separate parts:

  • Terrain Scanners determine the range within which you can detect terrain.
  • Terrain Scan Processors have a “density” factor which determines how quickly that terrain is revealed. A scanner providing map data without any additional processing reveals terrain at much slower rate.

With at least a scanner, terrain within a given radius is gradually revealed, providing more and more clues to the layout as you move around.


Imp. Terrain Scanner combined with a Seismic Analyzer (the weakest processor type). (I’ve left the radius highlight active so you can see where it scans out to.)

This means that even a low-density analysis is useful, even though it doesn’t tell you everything. Eventually with enough time or sufficiently powerful processor the entire area will be revealed.


Remaining stationary while an Imp. Terrain Scanner and Imp. Terrain Scan Processor reveal the nearby layout. (I’ve activated a Sensor Array so you can see other robots moving around as an indicator of the passage of time.)


Activating terrain scanners will remind you of their AOE, and also happens to point out doors (just to add a little something…).


Activating an Improved Terrain Scanner.

The processor animation is pretty simple, mostly reinforcing the radius again but with brighter versions reflecting a higher density.


Activating increasingly powerful processors (their effectiveness does stack).

Hidden Doors

I haven’t brought this mechanic up before. It wasn’t in the original design, either--a comment on Reddit a few months ago got me thinking about them and it turns out they add so much to the game that I figured they should be added sooner rather than later. I was considering keeping them a secret (I mean hey, they’re hidden doors!), but you’ll start encountering them right away in the game, and they’re not exactly rare (quite common, actually), so what the hell let’s talk about them now.

The idea is that most maps contain a number of “emergency access” doors used only by combat robots to more quickly reach flash points. Intruders unfamiliar with the territory can be ambushed, or think they’ve reached a dead end and turn to fight off pursuers only to suddenly be attacked from two sides. The mechanics should lead to some interesting situations. When robots start emerging from a room you thought was empty, now you’ll know why.

Terrain scanners don’t reveal hidden doors, which appear as normal walls until detected. You can, however, eventually figure out where these doors are hidden if you scan enough terrain to find corridors behind walls. Obviously seeing one of these doors open also counts as detecting it. Even if you don’t see it, it still opens automatically for you just like any other door, but it’s unlikely you’ll be spending lots of time running along room walls searching for them. You’ve got better things to do (and if you don’t you soon will after wasting so much time).

A better option is the dedicated Structural Scanner, now carried by engineer bots. This type of scanner is useful in that it auto-identifies hidden doors as soon as they are within view.


Exploring with a Structural Scanner. Without an active scanner, walking into that room would show nothing but normal walls.

Finding hidden doors saves you lots of time, making it possible to cut corners for a more direct route to an exit, sometimes circumventing entire sections of a map.

There is also a nifty animation to go along with its activation:


Activating a Structural Scanner.

System Corruption

To a degree, both robot and map knowledge are susceptible to interference from system corruption. Once Cogmind has been corrupted, low-level Sensor Arrays will sometimes report false signals (the number of false signals increases with the degree of corruption), and you can lose map data for previously visited areas!

Corruption is caused by electromagnetic damage, though it doesn’t start to play a significant role in the game until about mid-way through when the more fearsome EM-armed Programmers start tracking you down. Even if you don’t immediately notice your corruption value increasing, or some of the less intrusive effects like garbled log messages, the fact that your interface starts glitching will inform you pretty quickly ;).

As in the 7DRL, system corruption has other effects, too; just wanted to drop a mention of its relation to information warfare.

Sight Range

We can’t pass up this most basic element of roguelike information warfare, the maximum range to which your field of view extends. After all, it does determine what information is always immediately available and (usually) reliable.

To keep things simple, most robots have a sight range similar to your own (around 16), the main exception being Watchers that have augmented visual sensors for obvious reasons. Upgrading your own sight range, even beyond that of Watchers, is a great way to spot hostile robots before they spot you, but this only works in long corridors or large halls. Decidedly less effective than a sensor array-processor combo, though this only requires one slot.

In the 7DRL you could only guess whether an enemy had spotted you yet; now that we have a couple different ways to know that (see previous post), enhancing your sight range is a useful option.


While not required, hacking terminals is a fairly important way to gain information, some of which overlaps with what you can obtain from the various utilities described above.

The original game was designed without hacking, though theoretically it will be nice to have alternative sources of information, as well as greater flexibility in what can be provided. From a design perspective, parts need to provide fairly equivalent benefits due to the low-resolution slot system (e.g. you start the game with only 7 slots, 2 of which accept utilities). Any items with questionable relative value will always lose out in the fight for limited inventory space. Therefore, we can’t realistically rely on parts for some unique types of information. Terminals serve as a source of that information. I’ve mention some of the possibilities before, but the final list is not set yet.

The Other Side

Everything covered so far about information warfare is from Cogmind’s point of view, when it’s technically a two-way battle. What tools you choose to rely on (if any) heavily determines the outcome, though we can introduce a few more factors by also examining this topic from the enemy’s perspective.

First and foremost, your position is a pretty important piece of information. Once a hostile robot spots you, it will try to alert any nearby allies and tell them where you are. If there happens to be a chain of robots in the vicinity and this information gets passed around enough, you could have a lot of company on your hands.

An interesting new part, the Transmission Jammer, can prevent hostile robots from transmitting these messages to each other. I haven’t gotten far enough in world testing to see how effective it is in managing “situations,” but I’d imagine it’s going to be pretty useful. It automatically jams all transmissions in its area of effect.


Activating an Advanced Transmission Jammer, which will keep that Watcher (and Swarmer) from reporting my position to allies.

Unless you’re really confident in your capacity to annihilate all comers, you’d do well to reveal your position only when necessary, because once certain robots are pursuing you it can be tough to shake them.

You can, however, reduce the length of time robots are capable of tracking you after you’re out of sight by employing one of the ECM Suites. They are amazingly effective at getting you out of trouble, but the better ones require significant amounts of energy to operate (a balance issue).

And that’s pretty much it for the other side! There is currently one robot that factors into the information warfare game in a special way, but I’ll let you figure that one out. I have a couple more ideas for such robots I’d like to eventually add since there’s still a lot of room to explore here.

Posted in Design | Tagged , , , , , | 2 Responses

UI Feedback: Map Dynamics 2.0

A while back I mentioned a design initiative based on the concept of “map dynamics,” aimed at increasing player focus on the map area as opposed to the message log or other windows. After the initial spate of related features and animations, this part of development was put on hold as the rest of the game took shape.

With much of the game complete, and development inching ever closer to needing a more polished-looking dynamic interface before reaching out to the average gamer, it was about time to revisit this topic since we could now identify all the necessary features and implement them in a consistent manner all at once.

Before now we didn’t have a dedicated system for handling the large number of UI animations that would layer over the map area, as it’s tough to design a system without knowing the full extent of what you need it to handle. The resulting implementation (i.e. code-wise) is less flexible than I’d like it to be, but on the outside it looks cool and the style is consistent throughout. (At this point I’m happy to sacrifice code quality if it’ll get results, but I’ll stop myself wherever it threatens to screw me over in the future).

Might as well pick up where we left off in February.

I went back to the “explosion prediction” feature and added brackets that show the explosion’s maximum theoretical area of effect, just for reference since you can already see the more important shades of color representing damage falloff and obstacle blocking.


Explosion Prediction System 2.0 (I predict… you’re all going to die. I was right!)

There was more pure “fluff” animation I wanted to add to the UI for missiles and explosions, but that was cut as a feature unnecessary for 1.0. Almost every other animation on the list was implemented, because they offer meaningful feedback or other information to the player.

Object Identification

No, I’m not talking about the “ID minigame” (subsystem) present in many roguelikes. More basic than that, the first step before you can take each action in a game is to identify what’s what in the environment around you. Although proponents of tile-based games might argue otherwise, this isn’t an issue unique to ASCII roguelikes. Sure objects are represented by letters instead of images, but the devil is in the details and you really need to know exactly what you’re up against (enemies) and what tools are available (items). Images don’t convey that information perfectly until you’ve learned what the game tells you they are, which is no different from an ASCII interface!

I remember holding the Alt key in Diablo 2 (sort of a roguelike, yeah?) to instantly see names for all items on the ground. That sure saves a lot of time and makes sense in any game where loot is plentiful (Diablo, Cogmind…)


You can now call up labels for all items on the map, even those outside your field of vision in areas that you’ve visited before.


Item labels.

This is great for both surveying all items in view, and locating some item elsewhere on the map that you may not have cared for earlier but now really need and can’t recall where you saw it. Of course, depending on why this hypothetical item was there in the first place, it may be gone when you arrive! Remember that recyclers clean up after a battle, or if they find items strewn about where they’re not supposed to be (e.g. your stash).

In the 7DRL you would know this item was already gone, because (no one ever mentioned it, but) back then you could technically see doors being opened/closed, walls being destroyed/repaired, and items being dropped/picked up outside your field of vision as long as you had been to that area of the map before. It just wasn’t very noticeable under the green overlay; plus you probably wouldn’t expect the game to be so lenient in that regard. For the prototype I never had time to code a solution to properly record and conceal everything. As part of this latest update, explored areas of the map no longer automatically reflect changes since you’ve been there. They remain as you last saw them, including even labels for items that no longer exist.

With these and other labels below you can also see additional benefits from having a separate font for text and map (an idea I’ve discussed before): More label content fits in a smaller area, and the narrower font helps naturally distinguish label information from the rest of the map, an important necessity in ASCII roguelikes since the map consists of mostly alphanumeric glyphs as well. You’ll notice that to reinforce that difference I’ve opted to use a style which inverts foreground and background colors.


Labels on Demand™ are also available for the other most common map object: robots. Hostile and allied robot labels are activated separately. They display the robot class (not full name), and are color-coded by that robot’s remaining core integrity (from green to red).


Robot labels (hostiles).

Disarmed combat robots will be labeled instead with gray, so you know they are no longer a threat.

Notice that with all labels they automatically attempt to reorient themselves to avoid covering each other or important features (other similar objects):


Auto-orienting labels organizing themselves into the most visible arrangement possible.

Where there’s a really huge cluster of items/robots some overlap will be unavoidable, in which case there’s always the original scan window as a fallback for identifying objects. Plus that gives you more detailed information, anyway.


The whole point of the game is to move forward, so finding map exits is a very high priority. Finding the right exit is even more important since they don’t all lead to the same place and you won’t always want to immediately head through the first exit you find. Thus exit labels are fairly important and useful to have access to.

Calling up labels for exits will pinpoint their location as well as display the name of the destination, if known. Unknown exits appear labeled with question marks:


Exit labels.

While there’s nothing stopping you from entering an unknown exit (except FEAR! =p), you will often want to do a bit of hacking to figure out where exits lead.

Because Cogmind maps are quite large compared to the average dungeon roguelike, it’s very likely that exits will be out of the map view area. Thus when you activate exit labels, they will identify even those previously discovered which are now off screen--if you can’t see a label it will show an alternate label (simply the name of the exit) at the edge of the view in the direction of that exit. These labels automatically reorient themselves along the map edge as you shift the view.


Shifting the map to seek off-screen exits.


We can take this system one step further by automating label displays where it makes sense.

Now when you spot a new hostile robot for the first time it will automatically be labeled directly on the map (with its full name rather than the class designation shown for manual labels).

All newly spotted items are labeled as well--it is AMAZING how useful this is compared to the 7DRL where you had to mouse over each item to identify it. Using look mode via the keyboard to tab between visible items was/is pretty fast, but “fast” can’t really compare to “instant” ;). Simply by walking into a new room you can tell if it contains anything you want.


Auto-labeling items and robots. For the grand finale I blow them all to pieces.

Unlike manually accessed labels which only display one type of object at a time (either robot or item), as you move around automatic labels of either kind might appear, so you’ll notice they use a different color scheme to avoid confusion. While robots are labeled green to red by remaining integrity, common items are gray, prototypes are white, and anything outside your current field of vision is blue. (There’s a fourth classification with its own color, but that one’s a secret.)

Auto-labels for threats and items are individually toggleable in the options menu, if you don’t want them.

Auto-labeling of exits is accompanied by a recognizable beep that should stand out from the other interface noise, since exits are so important, though the larger label size will make it pretty apparent:


Finding and approaching an exit.

Input Scheme

We’re kinda running out of keys on the keyboard--how are we supposed to control manual labels?

First of all I freed up the numbers. They were originally used to access information about inventory objects, but that was actually a minor inconsistency in the input scheme I’ve been wanting to change anyway. Inventory item information is now Shift-#, which corresponds nicely to the Shift-a~z used for attached part information.

Press a number 1~4 to label hostiles, allies, items, or exits. Pressing the same number again, or Esc, will deactivate the labels immediately if you don’t want to wait two seconds for them to expire and disappear on their own.

We’re also running out of UI space, so a new solution was required for mouse support. Fortunately object label buttons fit nicely, both physically and conceptually, in the existing scan window. The buttons need not be always visible, so simply hovering the cursor over what is normally an informational scan window switches its contents to a list of buttons that can be clicked to call up labels (or cancel them if you click again).


Using the mouse to access labels.

Note that if there are no objects of the desired type to label, a message is shown to that effect at the top of the map view.

While keyboard look mode won’t be as useful anymore given that you can display map-wide labels instantly, it also auto-labels any object the cursor passes over. The name and details also appear in the scan window as usual, but it’s nice to not have to move your eyes away from the map.


Object auto-labels in keyboard “examine mode.” At the end of the recording I’m using hotkeys to automatically cycle between robots/items rather than shifting the cursor via movement keys.

Side note: I wonder how many players will actually use pure keyboard mode? Or whether anyone besides myself used it to play the 7DRL?


The labels introduced above are all useful both in and out of combat. We also have a collection of new labels that provide combat-specific feedback.

After a certain (adjustable) delay on entering targeting mode, the map displays the chance to hit each hostile robot in FOV.


Automatic hit% labels in target mode.

Where combat is concerned, the results of an attack are the most important feedback element, one that wasn’t too obvious in the 7DRL. Back then I did add a “calculations” window in which you could see the values used in the attack formula along with precise results.


The calculations window showing more specific attack results. (That armor I happen to be using for testing so I don’t get hurt =p). The level of detail shown is adjustable in the options. Content is also scrollable just like other log/message windows.

That window still exists (above), but we can make the most important information much easier to obtain through more on-map auto-labels for attack effects. If an attack damages a target’s core (not a part), the map will flash that robot’s remaining core integrity (as a percent). Destroyed parts are also named, and there’s an indicator when a core is temporarily disabled (some electromagnetic attacks).


Attack effect auto-labels, Cogmind’s version of the “floating numbers” you see in many games.

The system was originally also showing white numbers for EM-caused system corruption, but I decided to remove that for now since I think it works better as an unknown factor.

Combat labels are entirely optional because some players may consider them too intrusive. Attack effect descriptions do get in the way of enjoying the particle effects.

Being Spotted

Just because you can see another robot does not necessarily mean it has already seen you, but this information was never communicated in any way in the 7DRL. Now whenever you see a robot that has started tracking you, the space it occupies will glow for a bit.


Spotted by several hostiles on entering a corridor.

Technically a hostile robot may have started tracking you before you saw it, if it got your location from another robot or simply has a greater sight range, but it doesn’t glow until entering your FOV so you know it sees you. In case you missed the glow or aren’t sure, this information is now reflected in the scan window with a red ‘!’.


This robot has spotted and is currently tracking you.

Now that we have a more reliable way of knowing whether you’ve been spotted, I’d like to eventually add ECM mechanics that can temporarily prevent robots from noticing you even when you’re in their FOV. This would make melee approaches more interesting and provide another tool for the stealth-oriented build. There is already a set of ECM parts, but they only work to escape detection after being spotted and tracked rather than avoid detection in the first place. [New ECM mechanics are for much later, since we're beyond the point of adding unplanned features until at least the first release.]

The next post will examine more feedback features (and UI animations!), especially as it relates to utility parts.

Posted in GUI | Tagged , , , , , , , , | 9 Responses

Anatomy of an ASCII Title Screen

The design philosophy behind Cogmind emphasizes maximum immersion wherever possible. For this reason I’d like to avoid game-y interface elements--those which are not part of the game world itself but instead remove your mind from that world and remind you that it’s a game. (A fact you’re obviously unlikely to forget, but anything that breaks the illusion is still bad.)

As discussed earlier, we tucked the options and game menus away with the help and manual interface using the same animated style as the rest of the game to make the transition to “non-game-world space” a little less jarring. An options menu accessible from anywhere, plus mandatory permadeath (and no save menu--games aren’t so long you might play multiple runs in parallel), mean we could almost do away with the title screen entirely.

I like how the the 7DRL has no title screen--immediately on opening the game you are dumped right into the action regardless of whether starting a new game or continuing an old one. So for a long while I’ve been operating under the assumption that the game may not even have a title screen, doing away with an unnecessary “gateway” into the game itself.

More recently I’ve reconsidered that direction, since even without any interactive functionality (we’ve now removed or relocated everything that would apply), a title screen does have other advantages. One of the most important is name recognition in various places the game may appear, e.g. screenshots, and more importantly YouTube LPs.

Plus it’s an opportunity to have a cool-looking title logo.

And that’s actually where the change in direction originated from. It started with a Twitter follower pointing out that the official Cogmind logo as seen on the new website doesn’t reflect the art style of the game. It “needs the ASCII treatment.”

Thus I began sketching an alternative design in REXPaint for whatever purpose:


First concept sketch evolution for an ASCII-fied Cogmind title logo. (Click for full size, as with all other images in this post.)

As it started to look promising, I imagined how fun it would be to animate it and put it in the game. So of course I had to try :)

Flow-wise we already had an intro that plays when starting a new game, so the title was inserted before that and leads directly into it--the two work pretty well together since they share the same animated ASCII style. Both the title and intro are skipped completely if continuing a previous game.

Title Art Composition

When the title is shown, the goal is to minimize its “intrusive nature” and make it look like it belongs in the game world. This isn’t too hard since everything uses the same ASCII animation engine, and in terms of composition you’ll notice the title also uses the same style of line art used for items. (I still have yet to do a dedicated post showing off the different types of art in their final form, but some examples were previously shown here.)

I already liked the concepts, though the last iteration seemed a bit overdone, so I aimed to use something like the second to last one. First I redid some of the ASCII “circuitry” to rebalance the overall shape and flow of the title.


Rebalanced “ASCII circuitry” and some slight color adjustments.

The animation plan was to actively draw the background circuitry, then have the word appear on top of that. This means we’ll also want to draw parts that are under the word itself, as they’ll be showing before the word appears. So I split the art into two layers, one for the word itself, and another for everything behind it:


Title art separated into layers.

Minimalist is good, but I didn’t think this would be enough substance for a fully animated title which could really use at least a tiny bit of buildup. What better than even more circuitry! So I drew a third layer under both of those:


Stacking three art layers. (The bottom layer is drawn in a single flat gray--no shading--because the shading will be applied during animation as necessary.)

This bottom layer should look good both by itself and when combined with either or both of the layers above it. This meant a lot of layer toggling during the editing process. The bottom layer is only used fleetingly, though, (and is not a part of the final appearance) so the attention to this kind of detail is mostly overkill.

The animation part was pretty easy, only requiring a handful of scripts. For the curious:


Title screen animation scripts.

The second half of the above scripts are used to animate the title itself; the first half actually animates the “Grid Sage Games presents” text which appears before it. (Yes, might as well put that in there since we have a title now.)

The bottom-most layer, and first to animate, is seeded with 20 randomly located emitters from which the ASCII lines are traced in gray along cardinal paths (i.e. no diagonal drawing). Half a second later 20 more emitters are created on the middle layer, which is traced in green (this one allows diagonal paths as well, to ensure quicker complete coverage). Another second layer the title flashes in with a special glitch effect, while at the same time the bottom layer flashes in its entirety for a moment before quickly fading out. See it below:


Cogmind title animation. (Click!)

That’s it, three layers of ASCII art imported from a REXPaint .xp file. Notice one key difference between the result of the animation and the art itself: The “COGMIND” lines are brighter and have a background color to them. Turns out that when I borrowed an existing script to draw that part of the title, its design happens to leave the background color behind. I liked the fact that it stands out more and also melds the letters with the background circuitry via the few half-cell blocks scattered around the edges. So I kept it that way.


A static shot of the final title appearance, in game.

There you have it, Cogmind’s new “title screen.” Conceptually it’s still an out-of-game element, but at least it doesn’t require interaction--the game automatically starts about two seconds after the animation is complete.

Posted in Art | Tagged , , , , , | 6 Responses