Official development blog

Cogmind Alpha Access LAUNCHED!

Cogmind is here!

Pre-Alpha development has officially come to an end with the release of our first Alpha version over on the website. Thank you for your patience and support through the nearly two years that this blog has been sharing progress updates on the game. It’s been a long journey, and we’re not done yet, but Cogmind has finally reached a state worthy of release as we work towards 1.0 in the open.

Welcome to Alpha!

To introduce you to the awesomeness inside, we’ve put together an epic trailer that you’re going to want to fullscreen and watch in HD for maximum roguelike (wouldn’t hurt to turn up the volume, either =p):

Trailer music by Alex Yoder.

Please help spread the word by sharing the trailer and/or Cogmind site with anyone who might be interested, be they friends and family or online communities. The more support we can rally at this stage, the better the final game will be! Thank you!

Future of the Dev Blog

For those of you who have enjoyed reading about the implementation of Cogmind’s features and roguelike development in general, know that the dev blog will continue to serve that function. Game news updates and release announcements, on the other hand, will be concentrated on the appropriate forum board.

Posted in Release | Tagged , | 13 Responses

Map Composition

Much of the “living dungeon” concept described previously applies to the main complex, and some branches. Roguelikes of significant scope tend to use a combination of map generation techniques, necessary to fill the game world with unique maps appropriate for their respective areas. Different map types are also likely to require different algorithms to populate them with content including inhabitants, objects, events, etc. Thus Cogmind utilizes a network of systems to produce the wide range of maps needed for the world.


Cogmind map type composition, where thicker arrows represent a heavier relative emphasis on a given system as an input.

In total there are about two dozen types of maps (six of which will be included in the first alpha version). Those belonging to the main complex are generated by the tunneling algorithm, which may draw on a small amount of handmade content in the form of prefabs and encounters. A number of branches are created in the same manner, but a second category of branches, those described earlier as being outside the central AI’s area of direct influence, use an alternative method. As you can see in the diagram above, branches require more work (more inputs).

An explanation of usage scenarios for each of the four primary sources of map generation will help demonstrate how each plays a role in creating individual maps.

Tunneling Algorithm

This is Cogmind’s primary map generator, which I introduced in an in-depth post back before it was complete.

A single algorithm is capable of producing a broad range of unique layouts by adjusting dozens of parameters.


Some example maps generated for main complex areas (click for full size).

In some cases the differences are subtle when viewed like this, but in play will lead to different experiences (even when we overlook the fact that content will vary between the maps as well). In general it would be out of theme to use wildly different parameters since after all these maps are a part of the same complex.

Shown above is the first stage of map creation, the basic layout as passed from the procedural map generator to the game for content insertion. During the first-stage mapgen process, data about every junction, door, room, and open area is recorded for reference, along with analysis results like a relative seclusion heatmap (see the dungeon metrics post for some related images and explanations). The first stage map generator also comes with a range of visualization tools to examine different aspects of a map’s layout for parameter tweaking--changes can be made to a text file, then press a key and immediately regenerate a map based on new parameters. It takes a while to reach a preferable style, but is still much more efficient than try to tweak in the game itself, where there is a lot more to map generation than just the layout!

Tunneler-generated maps are furnished and populated in game based on a system that weighs random content according to depth and/or map type. This applies to machines and stockpiles (see here and here for methods and diagrams), as well as robots.

These maps make up the bulk of the game world, and are the ones in which the living dungeon really shines.

Cellular Automata

A portion of the branches require a layout very different from what a corridor-and-room tunneling algorithm can provide. For that purpose we also have a modified cellular automata algorithm (see the algorithm’s in-depth introduction for more info and images). Like the tunneling algorithm, it is driven by a variety of parameters capable of producing maps in different styles, though for now there is only one usage found in game: the mines.


A fully revealed mine (click for full size).

Because these maps have a fairly different structure compared to tunneler-generated maps (more linear, less branching and looping), they cannot feasibly use the same content distribution system. They are instead populated entirely by so-called “encounters,” which are described in more detail below.


Encounters are an additional mechanism through which to add content to tunneler-generated maps, and the only way to add content to automata-generated maps. A single “encounter” can be as simple as a local patrol or stockpile of parts, or something more complex like a story event.

Regardless of map type, the most useful feature of encounters is the ease with which they can be used to add handmade content. Encounters can make use of both pre-drawn map pieces and the powerful scripting system originally developed for X@COM. Thus there are now practically unlimited possibilities for unique map content.

However, taking full advantage of this “anything is possible” scope in the main complex is both unnecessary and would interfere with the living dungeon mechanics, while also making much of the game unpredictable and therefore unreasonably difficult. Instead, the more interesting/unusual encounters are concentrated in branch maps, making those optional areas of the game a playground for the most experienced, curious, or lost players ;).

Encounters have their own weighted distribution scheme, with the option to randomize their content (within parameter bounds) for additional variation. To aid in tweaking encounter frequency values, the system comes with a debugging visualization tool that shows where encounters are placed on a given map in game.


A mine with distributed encounter types marked with their associated category color (click for full size).

Encounters are divided into four categories to help visualize how a map could play out:

  • Fluff: Provide atmosphere rather than a mechanical effect on gameplay. A common example would be an area filled with debris.
  • Rewards: Unprotected “free” rewards that can take many forms, components or allies being the most common.
  • Risk vs. Reward: Like rewards, only you’ll probably have to overcome some obstacle to gain that reward.
  • Danger: Outright dangerous encounter with no explicitly defined rewards (though you could theoretically still benefit from salvage). Most often these are simply hostile robots, but the power of encounters can create other interesting situations…

The way in which some of the encounters are implemented might break the otherwise consistent realism that defines the living dungeon, for example a robot could suddenly “emerge from the shadows” in a dark area, though I believe this is a worthwhile sacrifice to enable more interesting and unexpected encounters. Said encounters may be found in some branches to liven up the experience--you won’t see this behavior in the main complex, again reinforcing the idea that the core world areas offer a more traditional roguelike experience while outlying regions contain experimental and less predictable content.

Though not required for content that can dynamically fit any space, encounters may also specify a “prefab” when applicable.


Last year I described how handmade map pieces are drawn in REXPaint and integrated into the map generation process. That was back when the prefab system was first developed, and not yet put to use in game. Those prefabs are now used for two things: encounters and special entrances/exits. The latter are integrated directly into both map generation algorithms, while encounter prefabs can be dropped into an existing room or “cave” (a single room-area in an automata-generated map).


One of many storage area layouts (shown in both ASCII and tiles versions). Now that is a room you want access to! (Then you’ll want to figure out a way to simultaneously equip 12 grenade launchers =p)

Like encounters, prefabs can randomly change their orientation and shift their position (it’s often even necessary to face and link to a door!).

As you can see, all sources of map data are procedural in nature, or support randomization in terms of where and what is injected into the maps. Every run is sure to be unique.

Posted in Design | Tagged , , , , , , , | 6 Responses

The Living Dungeon

Having introduced the world of Cogmind from a macro perspective, we now zoom in on the anatomy of individual floors.

In a majority of roguelikes, the content of a given dungeon map is unchanging, and individual encounters on that map play out in relative isolation. When you arrive there are X number of enemies in the area, you encounter an enemy and fight, then another somewhere else, or maybe flee and end up fighting two different enemies together. The overall dungeon experience can be described as a series of encounters where the frequency of enemies (or loot) determines the pacing, and in-between periods are used for resting up or dispatching minor “filler” enemies. Moreover, these enemies might simply wait around for the player to arrive, or perhaps wander around with no particular goal. This is a pretty lifeless world, but is perhaps an apt description of what we could call “pure roguelikes,” which reduce the roguelike formula to its tactical decision-making core. It’s little surprise that pure roguelikes have no need for story elements, as the role-playing emerges entirely from events that play out as a result of player decisions on exploration, leveling, and combat. Yet the consequences of your actions don’t last beyond the effects on your character or equipment.

Why not make dungeons a bit more dynamic? What if the contents of a map could change depending on your actions there? What if your actions there could lead to changes on other maps? Doing these things leads to deeper gameplay without sacrificing anything that defines a roguelike.

Cogmind does these things.

It’s Alive!

As suggested before, Cogmind’s world is composed of areas which are “more than just a dungeon” (see bottom of this post for some background). Cogmind is not a sandbox game by any measure, but it does handle map content very differently from other non-sandbox roguelikes. Instead of random enemies just sitting/wandering around waiting for the player to come fight them, each robot has a place in a simplified but meaningful ecosystem.

They are actually dynamic parts of a larger community in which each each individual has their own purpose and job. Not only does seeing them carrying out their tasks make the world feel more alive, you can even “become a part of their job” in many ways. Obviously combat robots will attack you when you’re deemed a threat, but you’ll also be sharing the corridors with many robots that aren’t out to do you harm, instead reacting to your actions indirectly as per their routine.


Engineers rebuild floors, walls and doors destroyed by yourself or other robots.



Workers clean up debris, here from a destroyed machine.



Recyclers collect damaged and surplus components for breakdown.



Tunneler digging out a new room, and engineers adding walls, floors, and a door on the way out. (They apparently decided not to finish a bit of the south wall…)

This is one of the more immediately obvious unique aspects of Cogmind maps, seeing lots of these green robots going about their business. Some might annoy you, but a resourceful Cogmind will find multiple ways that these non-combat robots can be of use under the right circumstances!

There are additional types of non-combat robots in the game--those listed above happen to be some examples which were already introduced in the public prototype (though all have since undergone some behavioral and capability upgrades). You can discover the rest in game.

Reverse Dungeon Keeper

Cogmind is kind of like Dungeon Keeper in reverse. That almost makes it sound like a normal roguelike, but there’s more to the analogy than that.

We have both the “robot ecosystem” outlined above, as well as an actual overarching AI controlling the community’s reaction to your presence and actions on a larger scale. You not only have to think about your interactions (combat or otherwise) on an individual robot-to-robot level, but in many cases must also consider the repercussions of your decisions further down the road.

Depending on the circumstances, your unauthorized or hostile actions will be reported, and you will be hunted, or cause enough mayhem and invite a robot army to converge on your position. Thus a particular map’s inhabitants are not entirely static. Robots will come and go, and you can even hijack this system via hacking to instruct certain robots to leave the map, or perhaps ask for a shipment of goodies to your location :D.

Completionists might be annoyed that “clearing” a map is next to impossible. The central AI will continue to dispatch units for various purposes, be they maintenance bots necessary to keep the zone running within parameters, or combat-capable bots to deal with troublemakers.

That said, there are areas outside the central AI’s sphere of influence, which is the difference between the main complex and some of the branches as distinguished in the previous post about the world layout. We’ll talk about the gameplay implications further down.

Rules Access

An important question with regard to these “hidden mechanics” is how the player learns about them. Cogmind is not a black box, which would make for poor roguelike design given that the average player cares about details and having enough knowledge necessary to make informed decisions. There are secrets, for sure, but those belong to the realm of content rather than mechanics.

Basic mechanics are explained via the in-game manual and context help, but there is no such direct system for learning about the central AI. That is accomplished as part of a separate learning process for which there are multiple channels to obtain information contributing to an overall understanding of how it works.

At the simplest level there are a handful of intercepted log messages (global “alerts”) that indicate when the central AI is doing something significant.


Probably the most dreaded message you’d see in your log while playing the prototype. There are now worse messages, so stay on your toes ;).

Learning about the AI also ties into information warfare (also here) in several ways, as sensors will enable you to observe enemy movements from afar, and terminals can be hacked for a large amount of relevant information or even control over the system. The most important terminal hack for figuring out the state of the central AI would be “Alert(Check),” which retrieves the current alert level for the local area.


Retrieving the current alert level, which can range from “low security” to 1 to 5.

If the alert level is on the rise, you might want to think twice before starting a firefight around a large array of explosive reactors--those chain reactions can really piss them off!

For those hidden mechanics difficult to figure out purely through observation, non-immersion-breaking NPCs found in certain areas will provide hints or direct advice. (Those areas have not yet been added to the game.)

Posted in Design, Game Overview | Tagged , , | 4 Responses

A World of Robots

In the previous post we discussed many of the traditional vs. unique characteristics of Cogmind, but one area was just too big to not cover on its own: the makeup of the world itself. For over a year on this blog we’ve demonstrated individual mechanics and features, along with how those fit into a bigger picture. Here for the first time I’d like to look at the biggest picture possible with an introduction to the world of Cogmind from a macro perspective.


If you played and remember the Cogmind prototype (7DRL), you probably don’t remember the story.

We can’t fault your memory, because there wasn’t much of a story to remember--a single sentence in your message log towards the beginning indicates you’ve “escaped from the scrapyard,” and from there it’s just fleeing and shooting robots. If you manage to beat the prototype there is a tiny bit more text, but other than that no greater setting or actors are provided to flesh out the backstory. The website and manual offered slightly more in the form of a paragraph of generic sci-fi material, which still falls into the “excuse to throw some mechanics together” category occupied by many story-light roguelikes.

Things are very different now.

The final version will contain a complete world with NPCs to meet, lore to discover, and secrets to uncover, all while enabling you to become a part of unfolding events and help shape their outcome (if you wish to). A future post will be dedicated to exploring the story of aspect of the game, which in the alpha version initially only exists as in-game lore--the semi-interactive parts will be coming later.

This post focuses on the world in which that story takes place, though only in a general sense because gradually learning the details through play is part of the fun.

For now I’ll say the story of Cogmind takes place in our galaxy (though not on Earth), a couple centuries in the future. Your part of the story is played out underground on a single planet, but the whos, whats, and whys are for you to figure out.


As in the prototype, you start at the bottom of a subterranean complex and are attempting to reach the surface. However, we now have multiple crisscrossing routes leading to that destination.

In terms of both content and play experience, the world can be divided into two distinct types of areas: main zones and branches. The main zones link together to form a straight shot from start to finish, while it’s also possible to move between those and outlying branches wherever you find the right access points.


A simplified breakdown of Cogmind’s subterranean world. (Note: The first alpha version includes the entire main complex and two early branches; the many remaining branches are still under construction, to be added over the next 5-6 months. Thus it currently includes much of the “core game,” while the planned additional content will turn it into the epic adventure prescribed by the design doc.)

So why bother taking branches if you can go straight to the end? After all, Cogmind has no XP system so the need to seek out additional areas in which to grind, a common impetus for travel and exploration in RPGs, does not apply.

The route you take will actually depend on a rather large number of factors.

You can in fact take the direct path straight to the end--the straight run is a perfectly valid way to win, and usually the fastest. For an experienced player, the biggest advantage there is a more predictable environment, an idea you’ll better understand with the next two posts introducing the central AI and examining the anatomy of individual floors.

While branches are completely optional, there are numerous reasons you may end up visiting them, primarily to:

  • Escape pursuit
  • Explore the story
  • Acquire better/special components and allies
  • Challenge yourself

By design, there is a somewhat greater chance that you’ll discover exits leading to branches before those that enable you to ascend to the next depth. Thus you may sometimes decide (or be forced) to take these exits first in order to evade dangerous pursuers, possible because pursuers will not chase you to other areas--there is an implied “you made it into inter-zone tunnel networks and lost them.”

In turning the prototype into a full game, to provide more room for content I expanded the world horizontally rather than vertically. This is seen with both the addition of branches, and the fact that many main complex maps are much larger than before. Last year I showed an image which appropriately demonstrates the evolution:


A sample main complex factory floor, 2012 vs. 2014.

The significant increase in scale means it is now more difficult to reach or happen across normal map exits (though there are now additional means of getting your bearings via hacking etc.), and therefore a greater chance that due to poor choices (or just bad luck), you may at various points find yourself in a bind and end up taking advantage of alternative routes offered by branches.

Branches are useful as more than simple escape routes though, especially if you discover their entrances early enough to warrant intentionally taking a detour. From a mechanical standpoint, some branches give access to special parts not found elsewhere--all the best components in the game are only available via branches. In the same way, some branches might also be a source of allies, help of the kind you’ll rarely encounter in the main complex.

In both cases it will take practice and experience to figure out what’s out there, how to get it, and whether it’s worth going out of your way to get. I can say that some of the additional branches will provide helpful means for tackling the late game, most importantly the alternate endings.

Said alternate endings themselves are in fact only accessible outside the main complex, and in this we see another important aspect of the branches: story elements. Pretty much all of the story, aside from lore you can access via terminals, is told throughout the branches. While you’ll be able to learn about what’s going on during your travels through the main complex, that area is more similar to the traditional mechanics-focused roguelike experience. The vast majority of opportunities to engage and affect the story exist off the main path.

As such, branch areas are built differently than the main complex, designed with a possibility for interesting semi-random (and therefore less predictable) events. I’ll talk more about this in the next post.

Regardless of part-, ally- or story-related benefits, visiting more branches is also an optional way to challenge yourself, and will help achieve a higher final score.

As you can see, branches have a lot to offer. That said, you won’t be able to completely avoid the main complex. Branches will eventually force you back into the main complex at some point, and you’ll have to find another branch exit to leave again.

For a demonstration of a rather long path through the world, see the image below:


A sample path through the world of Cogmind (remember, you start from the bottom and move upward).

Note that this is just a mockup--the world map is one of the final remaining UI elements to implement, so there’s no way to access it in game yet. It will look something like that, and include animation.

The map is only revealed gradually as you traverse it, with question marks standing in for names of areas you haven’t officially identified. You as a player will learn to rely on meta knowledge to know where you are, but in game the names of local and neighboring regions are only discovered via hacking. For the mockup above I’ve made the three main complex areas known, “Materials,” “Factory,” and “Research,” as these are unchanged from the prototype.

Have fun discovering the other maps! There are plenty more not shown, though again the alpha will initially only include two early-game branch types. This is both to demonstrate what branches will be like, and to ensure there is enough interesting early-game content for those of you who, um, spend a lot of time in the early game ;). Other maps are coming, though you’ll have your hands full with the existing large mid/late-game main complex maps since for now they’re balanced on the hard side until we get more alternative routes in there.

Access Points

Access to different maps/areas is via one of two types of exits: “stair exits” take you up to the next depth (and by extension the next main complex map), while “door exits” lead to branches. Collectively these are simply called “access points.”

In ASCII, exits to main complex areas are depicted using the traditional ‘<’, while exits to branches use ‘>’. In tiles mode, the two are represented by stairs and a special door, respectively.


Cogmind map exit type representations (known).

The destination of a given exit, as demonstrated above with their labels showing, is only shown if you’ve already used hacking to discover where they lead, otherwise both types appear as stair exits and you can’t differentiate the two (labels will simply read “???”). So taking an unidentified exit could lead you on an unintended detour, a risk you can either accept or avoid by hacking terminals to figure out which direction is which.

There are sometimes other clues that enable experienced players to discern where an exit leads without hacking. Certain branch exits may appear with a unique recognizable layout.


You can’t fool me with those stairs, it’s all too obvious this leads to the mines.


A key design element I’ve yet to explain here, one without which might leave you confused, is that there is no backtracking in Cogmind. You can’t simply step back through a door and return to the previous area--advancing to a new map is a permanent move.

You are technically being pursued through hostile territory, and by the time you leave an area your presence there has been noted and retracing your steps would be too dangerous. That and the idea is you’ve covered quite some ground between leaving the previous map and entering the new one, which is why you’re suddenly a good bit safer after coming out the other side of an exit.

Earlier I mentioned the game’s emphasis of horizontal over vertical depth. Regarding layout, we can see that the quickest path through the game traverses only ten maps, while taking branches could easily lengthen the game to twice that or more. Combine this with the lack of backtracking and you’ll find that it’s impossible to visit every location in a single play. This provides us with greater replayability, though that is not the purpose here--we get plenty of replayability via procedurally generated content! Instead it forces an experienced player to make decisions that give up one potential benefit for another, sort of like choosing which of many parts to carry along, only on a much larger scale.

Another reason worth designing away excess vertical progression is that we assume each new depth should provide us with increasingly powerful components and robots to avoid seeming too repetitive. While the game does in fact use this kind of progression, the level range is small enough that each can introduce truly unique content rather than an endless supply of rehashed items with modifiers (+1, +2, +5, +10, +25, +50…+1000…). Cogmind focuses on mechanical differences and only a mild power curve--it’s linear and by the numbers indicates that the average late-game components are in a lot of cases only three to four times as effective as those found at the beginning. With a little luck an early-game robot could even fairly quickly take down a mid-game robot.

The design does not migrate completely away from vertical progression (of item stats) because there is something to be said for that “I found another cool, better thing!” feeling, though as a compromise said progression is often combined with some extra meaningful benefit.

So we’ve established that you will likely end up taking some branches to either side of the main complex, either by choice or by force, but at the same time the game does a lot to push you upward. This is accomplished by the strictest limitation of all: Cogmind’s core integrity. Damage to the core cannot be repaired, and is only restored each time you evolve when moving closer to the surface. (The reason for this is part of the story.) Some players didn’t like that about the 7DRL version and insisted on a way to repair yourself, but this is really a core feature of the game, without which much of the design falls apart. Depending on strategy and performance, in some cases you won’t have the endurance or loadout to travel through branches at a given depth before you have to ascend towards the surface in order to evolve (very important when the alternative is permadeath!). For the same reason, you also can’t spend too much time on a single map since you’ll lose the war of attrition against a relentless enemy war machine. Read more about this and Cogmind’s other “food clock”-like mechanics here.


In Cogmind you don’t have a lot of your own stats to increase over time, nor do you need many. There is no character generation process through which the player can say “this is my character.” Most capabilities are instead bestowed directly by the components you choose to attach, and personal (if temporary) differentiation happens at play time.

Those few base stats you do possess increase automatically each time you evolve on ascending to a new depth, and they do so at the same rate each game (i.e. they are not randomized). Core integrity and heat dissipation rise in small amounts, while the only other, and certainly most important, “stat” is the number of slots of each type to add during evolution.

Thus even if you take an unidentified stairway out of an area, it will be obvious if you are actually ascending to another depth (and therefore a main complex map), since it will allow you to select your new slots instead of going straight into a new area (branch).


Slot type selection interface during inter-depth evolution.

Combat Optional

Overall the route you take each game will largely be a factor of chance and strategy, both at the macro level (is the ultimate goal a high score? a certain ending? a specific achievement?) and the micro level (i.e. your preferred build and what components you find or manage to steal).

Without a need to grind to advance, you really are just looking for the exit(s) on each floor. As you’d assume the best way to achieve this is to be as sneaky as possible (except when you can’t :D).

Personally I believe Cogmind’s mechanics offer the best roguelike integration of stealth into a game that can just as well be about all-out open combat. This is important because the most successful strategies will likely be a stealth-combat hybrid, which in turn affects your route through the world. For example, after failure to avoid being spotted in a particularly dangerous area, you may decide that that fighting your way through an approaching army to get to a better exit is not worth the risk compared to taking a less desirable but unguarded exit you passed earlier.

It can also take a little while to acquire proper stealth gear (and is easier to lose it to intense firefights), so runs will often fluctuate between death-mobile and ninja-bot, simply by necessity and circumstance.

Posted in Design, Game Overview | Tagged , | 11 Responses

Cogmind the Roguelike

Probably one of the latest hot marketing terms to see rampant use in the indie scene is “roguelike,” regardless of whether it really suits the game in question.

No, I don’t plan to tackle that can of worms (the topic gets more than enough attention over on /r/roguelikes), but I would like to begin a series of posts aimed at clarifying “what makes Cogmind a roguelike,” and, more importantly, what perhaps unexpected features it adds to the mix.

We’ll start with the basics, those features which most players familiar with the genre have come to expect.

Procedural Generation

This is the element that has apparently become synonymous with “roguelike,” which is completely wrong--granted it’s an absolutely required core feature of roguelikes, but the genre is defined by so much more than PCG (procedural content generation).

For each new game Cogmind generates the world layout, individual maps, and procedurally* distributes what content you might encounter. *Note that “procedural” is not “random”--the process is driven by data and algorithms with a purpose.

However, overuse or misuse of PCG risks leading to a bland experience, thus most roguelikes don’t go so far as full procedural generation of enemies, items, etc. Neither does Cogmind. Players and the world itself can both benefit from a certain amount of static content to latch onto. In Cogmind we could easily generate robots from an assortment of parts (considering we have so many), but there’s a lot of value in keeping robots (and parts) hand-crafted as they are. Static content has two advantages, enabling 1) us to build the game’s lore around specific dependable content and 2) players to form a strategy around known factors in an otherwise ever-changing world.

In this area Cogmind is therefore pretty much what you expect from a roguelike: maps are generated, most everything else is defined beforehand and referenced by the generator when putting those maps together. The approach is sufficient to provide infinite replayability without putting too great a burden on the player to relearn everything with each new play.


Cogmind’s map generator building factory map layouts for a 200×200 space from a combination of algorithms and a few hand-made prefab pieces.


Another roguelike staple, permadeath goes hand-in-hand with procedural generation. In case you didn’t know, permadeath means no loading saved games aside from continuing your most recent game, and loss is permanent (unless you’re cheating!=p). It would be quite boring if a game forced you to restart from the beginning on failure without offering a new experience each time, hence the advantage of procedural maps here.


You’ll be seeing a lot of this until you get the hang of it. (One of the performance indicators is obscured as it’s a minor spoiler. Also, the factors that contribute to your final score will likely be changing.)

Cogmind is actually more forgiving than many traditional roguelikes. In most roguelikes if you stand motionless and unresponsive next to an enemy, you’ll probably be dead in mere turns.

Not so with Cogmind. While I wouldn’t recommend letting enemies wail on you, the mechanics are such that sudden death is impossible. Even quick death is unlikely unless you’re intentionally avoiding the most basic defensive measures (or you’re exploring optional dangerous areas in the late-game).

You are pretty resilient and most likely to die from poor planning/decision-making, or attrition (this works because there is no normal way to heal/repair damage beyond reaching new areas!). The pre-alpha is currently not balanced enough to promise you won’t run into some very deadly situations, but the final goal is a fair game in which you can win a majority of runs once you’ve accumulated enough meta experience.

Despite the long-term attrition approach to success or failure, rarely are you forced into a “walking dead” scenario wherein you’re pretty much guaranteed to lose the game but just haven’t died yet.

For the experienced player, comebacks are commonplace. You can be reduced to a barely functioning mobile pile of scrap, only to several hundred turns later once again be an armored four-legged menace bristling with cannons (or maybe you decided to keep a low profile and stole some flight units and sensor gear instead).

And even for the new player, there’s always the opportunity to simply absorb the damage from attacks while fleeing (or even outrun pursuers) until you happen across an exit, which might be just around the next corner.

In short, there is always hope! On reaching a new area you’ll (usually) be safe from attack for a bit, giving you a chance to build up if necessary.


This is a somewhat controversial factor of roguelikeness, more so in modern times where there’s a high degree of genre mixing going on in the indie segment. Roguelike gameplay traditionally takes place in both discrete time and space (the two are fairly complementary). Certainly all the classic roguelikes fall under this category.

Roguelikes are a test of problem solving skills rather than reflexes, thus we should have as much time as necessary to consider options and make decide on a course of action. Sure we’re all guilty of the “pressed the key too many times and died” experience, but we did have the opportunity to stop and think if we hadn’t gotten so complacent at the wrong time!

This puts pausable real-time games like FTL into a gray area I won’t address here, but I do think non-pausable real-time games, while they can certainly embrace the roguelike spirit, really belong to a different category (“roguelites”) because they test decision-making from a different angle by putting an emphasis on physical coordination.

Anyway, Cogmind is turn-based and grid-based, the latter part so ingrained in the UI that even the map tileset doesn’t use connected wall segments.

Regarding the turn-based mechanics, for those who haven’t played the prototype I should briefly introduce how it works. Cogmind uses a “time-energy” system as seen in a number of other roguelikes: Each game turn gives every actor (robot) 100 units of time, and performing an action reduces the available time by the cost (duration) of that action. Whichever robot has the greatest available “time” is the next to act. So performing actions with a greater time requirement will allow other robots to perform more actions before you can act again (unless they, too, perform time-consuming actions).

All of this happens under the hood, though you’ll get a feel for it as you play, plus some of the numbers are shown to you where important to help make comparisons and weigh decisions.

Most actions take about 100 time units, i.e. can be carried out once per turn. There are primarily two other actions that can vary greatly in how much time they require: movement and shooting.


Current speed in “time to move one space” as shown in the HUD. Also the amount of time required to fire the currently active volley of weapons.

One significant difference between Cogmind’s design and the average “time-energy” system (or other similar system) is that in other games the time differences between actions are intentionally fairly subtle, or at least don’t exceed a certain reasonable threshold. By comparison it’s possible in Cogmind to have extremely exaggerated time costs, so be careful of that! This would be a result of your own design, something you have to aim to balance while maintaining peak efficiency for the functionality you want.

In a worst case scenario assuming you’re a massive hulk of parts hopping along on one leg, you could move a single space and suddenly everyone within sight gets 2-3 shots at you, and again for every further step you take (in this case, if your goal is to escape, you may be forced to drop your stuff and run; or pull out that grenade launcher you’ve been hoarding and make a stand!).

The opposite is also true: you could fly so fast that enemies don’t even see you as you zip down the corridor and off into another room.

As you can see your speed value is incredibly important to how things play out.

Firing weapons can have a similarly exaggerated effect on relative time since you’re allowed to fire as many weapons as you want, but the total firing time could span multiple turns during which other robots can continue to act.

This makes large attacks front-loaded (since you are in effect spending a block of future time that you don’t have--time energy can be negative), but dangerous if used improperly. The benefit to larger volleys is that each additional weapon requires less additional time to fire, until it’s almost insignificant (because the more firing, the more that are able to do so simultaneously).

There is a lot of tactical decision-making involved in how many of what type of weapon to fire at what kind of target, but that will be for you to explore.


Ah, bumping into something until you kill it, the time-honored simplest method of conflict resolution in roguelikes.

It’s true that roguelikes don’t have to be combat-oriented, but aside from fun 7DRL experiments we see that the most popular roguelikes are all about causing death and destruction.

For all its guns, cannons, and missile launchers, Cogmind is actually kind of an anti-combat game. Unlike in other roguelikes, combat is not a way to improve yourself. Sure you can “re-appropriate” parts scrapped from a robot, but there are also plenty found elsewhere for the taking (and what you find elsewhere is better, no less).

This has the advantage of making the stealth approach a much more meaningful strategy, which the game has plenty of mechanics to support. You aren’t required to fight anything at all. That said, it’s likely that even the stealthiest Cogmind, and most players aiming to win (as opposed to just causing mayhem, which is lots of fun, too), will end up fighting the occasional battle in the interest of avoiding greater confrontations that are even more difficult to evade or control. (For example, if you encounter a lone patrol squad that might spot you and warn others, you have the choice to lure them to a suitable battleground and take them out, or take a detour and risk it.)

Most roguelikes are heavy on combat, and while the genre is now trending towards more interesting forms of interaction than bump-them-til-they-die, melee attacks remain a staple action. They take a back seat in Cogmind.

In fact, Cogmind’s original prototype had no melee weapons at all--they have since been added as a new option you probably won’t solely rely on, but that do come in handy in certain situations.


Handy indeed…

The vast majority of combat in Cogmind takes place at range, which changes the experience significantly. This is not you one-sidedly mowing down waves of short-range attackers approaching from a distance; encounters are all-out firefights in which almost every enemy you meet can pound you from range.

Not only that, but you can fire as many weapons as you can attach and power at once, none of those left hand, right hand limits :)


About to let loose (poor strategy--one grenade or rocket at a time would be enough for these guys). I made this into a gif so you could see the scene in both ASCII and tiles.

Inventory Management

Interaction is a key gameplay element in roguelikes. While items (and usually by extension an inventory) are by no means required for a roguelike, they do offer a useful medium for expanding the number of possible interactions.

I’ve already covered Cogmind’s unique inventory system and its impact on gameplay in great detail in a separate post.

ASCII & Tiles

While I don’t believe ASCII is an essential feature of roguelikes, it does embody the ideal roguelike interface: a simple easily readable representation designed to facilitate decision-making. For my take on the inherent benefits of ASCII as opposed to tiles, see this earlier post. No sense in rehashing that discussion here.

Most popular roguelikes these days offer both modes, and so does Cogmind. The use of ASCII is pretty well represented and documented throughout the blog and game website; the tileset and an analysis of its composition can be seen/read here.

What most roguelikes don’t have is ASCII art. Drawing it all was a huge amount of work (one reason most RLs avoid it…), but in Cogmind every item has associated art that adds a lot of character (or “characters” depending on how you look at it =p).


Compilation of ASCII art samples (click for full size, or check out the introduction to all these item categories in the Cogmind ASCII Art Gallery).

Cogmind’s ASCII particle effects are also a big draw seen elsewhere only in moderation, not least of all because they can cause a bit of a pacing issue with what are normally quick to play games. The negatives are mitigated by tying animation speed to the importance of the attack--weak weapons animate extremely quickly while big powerful weapons and explosions can afford a little extra time for their animation (like maybe 300-1500 milliseconds compared to 100-200ms).


If I’m going to put the effort into making something blow up, may as well as give it some juicy particle goodness. (Composite image showing explosion reversal and switch to tiles mode for fun.)


Roguelikes are traditionally not very accessible. [/understatement]

However, modern roguelikes are trending towards broader accessibility, what with standard 2D visuals (no ASCII, even?!), proper mouse support, and other features mainstream audiences expect from a modern game. This is great for attracting new players to the genre, something we need in order to create bigger better roguelikes, while also aiding discoverability of those that already exist.

What I’ve done with Cogmind is apply most of these same modern UX design principles to a traditional ASCII interface, which surprisingly very few developers bother to do. And why not? We get to keep our minimalist ASCII and at the same time make the game accessible to players who won’t, for example, memorize 100 keyboard commands.

Simply put, Cogmind’s design adheres to a handful of guidelines that go a long way towards accommodating different types of players.

First and foremost, every action and command must be accessible via both mouse and keyboard. Sometimes there are even multiple keyboard commands for the same action (four different sets of movement commands are supported).

Furthermore, alphanumeric keyboard commands are embedded directly into the UI wherever they make sense and can look good, facilitating learning of hotkeys.


Embedded keyboard commands appear all over the place, and fit nicely with the style of the interface.

Here I must regretfully announce one of Cogmind’s only major failings in this area: there are no keyboard rebinds! It’s theoretically possible, but given the state of the program architecture would be a rather large project in itself. Everything is arranged on the keyboard as logically as possible, though this doesn’t help players with non-US keyboards. We’ll see what kind of issues we encounter once the game is released, but there’s always mouse input, or a mouse-keyboard hybrid, as alternatives.

And we’ll see if we can get any of the really fringe players on board with drag-and-drop inventory manipulation! :)

Cogmind doesn’t yet have any explicit support for color blind players, though some solutions could be implemented based on needs as described in an earlier post.

One design feature that will hopefully mitigate the need for alternative color blind solutions, while at the same time improving the general player experience, is multi-channel feedback.

Wherever possible, Cogmind presents the same information through multiple means, usually a combination of colored words, symbols, sound effects, and animation.

For example, when you are low on core integrity (health) a warning sound plays, a red “ALERT” text box appears next to integrity on the HUD, and all the interface window frames oscillate between their normal green color and red. It’s unlikely you’ll miss the news.


Plenty of indicators and alarms warn you when things aren’t going so well.

An example of multiple ways to obtain the same information: The name of an enemy robot is automatically shown when you first see it, and can also be found by hovering the cursor over it (to show its name, whether it’s spotted you and other info in the HUD scan info area), pressing ’1′ to label all robots, holding ctrl-shift and hovering the cursor to label that one robot, right-clicking on the robot to open its full data page, or pressing ‘x’ (look mode) then ‘tab’ to automatically shift the cursor to the enemy and label it (from where you can press ‘d’ for data to open its info if you want to know more than the scan window shows).


Calling up a label for a nearby robot, basic data for which is also shown in the HUD scan window: red name for hostile, green rectangle for its current core integrity, red exclamation mark meaning it’s spotted you, and the base chance to hit it. (Same scene shown in both ASCII and tiles.)

Text-heavy games like roguelikes place a lot of importance on fonts, and with good reason because there’s a lot of reading to do. I’ve mentioned before that Cogmind’s design attempts to shift as much information as possible from the message log to the map itself, but you’ll still be reading plenty of words, phrases, and short sentences.

The earliest roguelikes, true terminal RLs, had no choice but to stick to a single font, but with more and more of today’s roguelikes making use of emulated terminals, we have more options and should use them to lighten the burden on the player. (For an in-depth discussion and lots of images from other roguelikes, see this post.) Wide/square fonts are difficult for reading text, while narrow/rectangular fonts create distorted maps. So why not use a mix of both? Naturally plenty of modern roguelikes that have moved away from the traditional grid-based environment already do this, but we can technically apply it to the grid as well.


For the 7DRL/prototype Cogmind chose to emphasize a square cell size for maps, which unfortunately meant that text like the list of parts was not very pleasant to read--this has been vastly improved by enabling mixed font dimensions in the current version.

Improved readability of the respective interface areas is Cogmind’s biggest single visual change from the 7DRL prototype, and something that sets it apart from almost every other ASCII roguelike. With multiple fonts we can get the best of both worlds. (More about Cogmind’s font design here.)

Audio feedback is an element of accessibility, but also contributes to the game’s environment, so it gets its own section:


One could say this feature is somewhat controversial with regard to roguelikes, because it is known that many traditional roguelike players will play a game silently or to alternative music/audio, even when the game provides its own. Certainly players we may be able to attract from adjacent genres are used to and interested in relying on a game’s own audio, and I think there is much room in traditional roguelikes for the suitable application of sound effects.

Audio feedback is to me one of Cogmind’s biggest leaps forward as far as roguelike evolution is concerned. Not many traditional roguelikes take advantage of the potential benefits of a robust sound system, and none do it to the same extent Cogmind does. I’ve already written an entire series of posts on the usage and development of sound effects in roguelikes and Cogmind.

While I wouldn’t say audio is absolutely necessary to play, it is without a doubt a huge part of both the experience and the accessibility of the interface. The interface is relatively dense and there can be a lot going on, making it sometimes difficult to notice everything of importance. Thus for every visual effect there is an accompanying sound (yes, that’s quite a lot of sounds), making it more likely you’ll be aware of important events and changes.

In its final state Cogmind will include even ambient sound effects to further develop the atmosphere, as described before. The goal there, as with map-wide ambient music/sound, will be to implement them in a manner that doesn’t interfere with the existing sound system’s accessibility-enabling qualities.

More than a Dungeon

The average roguelike dungeon-diving experience can be described as a single player exploring corridors and rooms in which lurk individual or groups of unrelated monsters or humanoids. You aren’t expected to question why that dragon didn’t eat those orcs last time it got hungry.

Roguelikes with themed dungeon areas get around this oddity by at least limiting the local population to a variety of similar or related creatures, though rarely do we see any kind of larger ecosystem (the recently revived Incursion is a notable exception). This form does have its merits, successfully condensing as much interesting and unique material into as small a space as possible and thereby increasing the number of unexpected emergent situations to focus on the tactical decision-making aspect so central to roguelikes.

In this area Cogmind makes a rather large departure from most roguelikes with one of its more exciting aspects that I’ve been holding off discussing in any detail: A dynamic world with an overarching AI.

One reason for delaying its introduction was that it’s a final stage of pre-alpha development that has only taken shape in recent months, and of course even in introducing this feature I can only say so much without spoiling the game by revealing how it works.

In short, all robots have some purpose other than just attack the player (and many robots don’t/can’t attack at all), while many areas of the game are overseen by a larger AI that controls the population, a population which is at the same time capable of communicating within its own ranks.

This is actually a huge topic to be discussed in two separate upcoming posts, one about the world layout and traversing it, and another about the inhabitants of that world. Stay tuned for those. Linked.


The “list of features” approach is not always a valid way to identify “roguelikes,” a label that some players afford to games simply based on the gestalt experience offered by the totality of their moving parts. It is nonetheless a useful way to discuss this timeless argument. I mean topic.

Few will claim that Cogmind is not a roguelike, but at the same time there are many elements that set it apart from traditional roguelikes in both form and substance. I hope that it will appeal to both long-time players and those new to the genre. A truly modern roguelike. Rock, Paper, Shotgun really picked up on that when they named Cogmind one of the best upcoming PC games of 2015, writing “Cogmind is an impressive merging of old and new school game design.” :D

Posted in Design, Game Overview | Tagged , | 12 Responses