Official development blog

Font Creation

Finding the perfect font can be difficult, even more so if you’re also hoping that font will offer a unique appearance associated with your game. You’ll often come across fonts that possess several of the right qualities but have other drawbacks, especially when taking into consideration the many factors covered in the previous post about roguelike fonts in particular. This is when you want to take those qualities as inspiration and break out the pixel brush. Roguelikes have so few visual assets that it’s worth investing some time developing your own font. I’ve been making and working with bitmap fonts for about ten years, so I’ll share some of my observations and workflow tips here.


There are two main options for dealing with fonts: 1) use a font engine to render a TrueType font (.ttf), or 2) use a bitmap.

TrueType has the advantage of being scalable to almost any size, making it the solution with ultimate flexibility. However, this flexibility comes at the cost of precise pixel control, thus TTFs won’t always look good at all sizes. In a game where text is secondary this drawback may not be a huge deal, but with terminal roguelikes (emulated or not), the text is the graphics, so it’s nice if we can control every pixel. Think of roguelike fonts as pixel art in that regard. Also note that creating a proper TFFs requires a good bit of technical knowledge, and specific tools.

Most roguelikes, and many 2D games, use bitmap fonts instead. The bitmap approach is great for that pixel-perfect WYSIWYG appearance. I’m guessing that most readers already know what a “bitmap font” is, but just in case:


A bitmap font image (REXPaint code page 437 in 10×10).

As in the above image, all the characters are pre-drawn in a grid, and at runtime the game copies individual characters from this image and puts them on the screen to form words.

The main drawbacks to bitmap fonts are the need for different bitmaps for every font size (if more than one), a lack of automatic kerning (which you get with TTFs), and narrow characters (like ‘i’) taking up much more horizontal space than they should. Bitmap fonts don’t have to be limited to monospaced output, but with a grid-based terminal display we don’t have the luxury of specifying character spacing.

Aside from that, bitmaps are more powerful than they appear. At runtime the engine can recolor them to any color necessary:


Each of these sentences was produced from the same bitmap shown above.

And “pixel-perfect” doesn’t have to mean sharp edges--bitmap fonts are even capable of alpha shading and anti-aliasing:


To demonstrate, the 10×10 font bitmap was upscaled in Photoshop using a smoothing algorithm, producing anti-aliased characters that can be copied as well. (Naturally in actual use we’ll want to manually draw in the antialiasing--full pixel control FTW!)

As seen above, alpha-enabled fonts can be recolored all the same and preserve their alpha transparency.


With bitmap fonts the other consideration is what layout to use. Your game, or other programs, need to know where each letter is located, just as if this were any other sprite map. Since you can specify the coordinates, it’s really up to you.

One of the more common choices is US code page 437, the standard extended ASCII layout used by games like Dwarf Fortress--the same such layout you see in the first bitmap shown above. Some programs may orient it differently (column-wise rather than row-wise), but in general there is a benefit to making the bitmap directly correlate to ASCII values. There are lots of bitmap files already out there in the wild, and if you can read a more standard format like CP437 then you can potentially import any of them without trouble.

For Cogmind I’m not interested in reusing other bitmaps, nor am I using the entire code page 437 set, so seeing as we only have to map the character positions once in the source, might as well make editing the font easier by creating our own layout:


Bitmap layout for the Cogmind 7DRL/prototype default font. The layout will remain more or less the same, but the font will be retired (it’s a Deja Vu font--I didn’t make it).

This layout ignores the many ASCII characters we don’t need, and lines up lower and upper case letters immediately next to each other. Much cleaner to edit.

Tools & Basics

There are a ton of drawing programs out there, many free, though I always use Photoshop, even for pixel work (for which I don’t think it’s particularly suitable, but I’ve been using it regularly for about 15 years so it’s what I’m used to…). Examples will be shown in PS but translate to just about any decent program.


Below is the 9×18 text font design file.


One of Cogmind’s 9×18 fonts. Most of the (non-experimental) font files are layered like this.

All font files have a “guide” layer which shows the boundaries of each cell, useful when zoomed in drawing individual characters and for eyeballing pixel padding. I always use an overlay for guides in PS because using lines would occupy space and then you have to remember which cell the line belongs to and maybe even draw over it. (Area-based guides are also useful because you can ctrl-click the layer to select the entire guide area, though that doesn’t matter in this case and is a technique for other PS work.)

The 9×18 font currently includes three variants: “cogmind” (a highly-stylized sci-fi font), “wide” (8×10), and “narrow ” (7×10). Remember that when making a bitmap font for roguelikes in which a character will occupy an entire cell, we must embed horizontal character spacing and vertical line spacing in the actual font, so characters will rarely take up an entire cell in the bitmap itself. We can describe the variant by its letter size (I use the dimensions of ‘A’).

Common glyphs like lines are held in a separate layer since they don’t differ between variants.


When creating a font in multiple sizes and variant styles, to save time we’ll obviously be doing a lot of copying.

The 9×18 font actually began its life as a direct copy of the 16×16 square font, shifting lines/columns as necessary followed by tweaking features to bring it more in line with the other narrow text fonts and improve readability (in words). The 16×16 square font itself began as an upscaled 12×12:


The 16×16 font immediately after upscaling from 12×12--definitely needs lots of adjustments, but having most of the pixels there already will save plenty of time.

Note that when upscaling for this purpose, to avoid anti-aliasing/smoothing we have to change the resampling method to “Nearest Neighbor”:


Scaling pixel art images in Photoshop, because we’re going to fix them up manually.

Because larger fonts take much longer to draw, even if the intent isn’t to use a smaller font you can begin by drawing the general style at a size like 8×8 then upscale it. From there you can tweak the strokes, or even add anti-aliasing:


An example of scaling a smaller font for manual adjustment.

Typeface Anatomy

When you do have to draw from scratch, the first thing to do is decide on some basic parameters that will more or less remain consistent throughout the font. The relative positions of these three lines are especially important:


The font baseline, mean line, and cap line.

Most characters sit on the baseline, the cap line defines the upper edge of capital letters, and the mean line is where we find the crossbars for capital letters and often the tops of lower case letters.

Remember that for roguelikes we must also embed both character and line spacing in the bitmap itself, and these can have a significant impact on the final result.


The difference between leaving two (left, 7×10) or one (right, 8×10) pixel of horizontal space in the 9×18 font.

When scaling variants to multiple sizes, I’ll first sketch a quick reference diagram to ensure the ratio of space and glyph size remains fairly consistent to keep the style intact across each version.


Spacing reference data for a text font at three different sizes.


This post is geared towards the technical aspects of making bitmap fonts, but I can offer some simple guidelines and techniques for design.


It’s pretty obvious that fonts each have their own theme, essentially a set of defining characteristics that show the glyphs belong to the same group (font). Creating a consistent cohesive font is simply a matter of making a list of rules that define those characteristics, then sticking to it. Rules regarding how different letters treat the reference lines (base/mean/cap), uniform behavior of decenders (hanging lower case strokes), relative prominence of punctuation…

Again that last one is very important for roguelikes, since periods especially are so commonly used on maps. An extra pixel or two can make a huge difference in the overall appearance of a map. This and other thickness-related concerns are inseparable from the use of color, since they work together to determine how bright the interface will be overall (assuming the use of a traditional black background). Fine periods are compatible with bright colors, but thick periods would threaten to overwhelm the map unless presented only in dark colors.


Look at the huge difference a period makes: 1×1 vs. 2×2.

As you can see, even with a darker color the map is harder to read with a thicker period--looks like the 2×2 version would need to be even darker to work at that size. That’s a 12×12 map font, for which Cogmind is currently using the 1×1 centered dot (left).

In the end, a theme’s rules may need to be bent or broken for a few stubborn letters that aren’t too compatible with the chosen style, but do so sparingly.

Text vs. Map

In the previous post we outlined several properties that differentiate the ideal text font and map font, and we can actually treat them somewhat differently in our bitmap images. Herein lies another advantage of separating the two: For map fonts we can ignore character and line spacing for the purpose of text readability and instead put glyphs in the center of their own cell.


Glyphs from a 16×16 font demonstrating map font centering--they no longer share the same baseline.

This is another step away from the classic text-as-map roguelike appearance, but preserves the even distribution of space between objects as found in normal game maps. The advantage is most apparent with the period, which usually sits on the baseline but in this case can mark the center of an empty map position. Few if any roguelikes use this feature, but Cogmind certainly will:


An in-game comparison of non-centered vs. centered map fonts (16×16). Centering the glyphs results in better alignment between different map components.

While it’s true that in raising the baseline for lower case characters you might reduce the visual effect of “tall vs. short” when horizontally adjacent to their upper case counterparts, truly large creatures are best presented as multi-cell objects anyway (as they are in Cogmind), and upper case letters do still occupy more pixel space.


When creating a bitmap font, it’s important to realize that while an individual character may look cool, its difficult to give a well-rounded appraisal while pixeling it because 1) you are usually zoomed in close, and 2) there is no question of how recognizable the character really is (you already know what you’re drawing!).

We must examine the font at its native resolution during the process. Most painting software comes with some kind of “preview” feature with which you can observe changes to the image itself while editing as if it were zoomed out. In Photoshop, selecting the “Window > Arrange > New Window for…” option creates a duplicate window for the current image, and both are updated simultaneously, so one can be set to the original image size to see changes as they are made while zoomed in at the pixel level.

But even keeping an eye on the font bitmap at its native resolution is not a complete solution. Remember that the readability of text fonts is partially defined by how characters interact with other neighboring characters. Seeing the font in action will suggest additional necessary tweaks, so intermittently dropping it into the game helps refine the design. For that purpose I keep a separate copy of REXPaint where I can quickly drop in fonts and see how well they work. (It helps that Cogmind’s GUI mockups are all stored in REXPaint .xp files.)

This is the second in a three-part series on roguelike fonts:

Posted in Design, Dev Series: Fonts | Tagged , | Leave a comment

Fonts in Roguelikes

The first aspect of a traditional roguelike viewers tend to notice is the color palette, but when it comes down to actually playing a game which requires interpreting large amounts of text, color takes a backseat to the importance of the font. Characters/glyphs form not only words and sentences, they even represent the map and every object contained within, blurring the distinction between font and sprites/tiles. Thus roguelike developers should not overlook the many considerations that go into creating or choosing the right font. This is the first post in a series that will explore those considerations, share font creation techniques, and look at examples from Cogmind itself. Note that although the topic is discussed in terms of roguelikes, some of the concepts and methods touched on apply to all kinds of games.


The number one consideration with a font that’s meant to be read a lot is, surprise, readability! This consideration is often at odds with the desire to stylize a font to give it a unique look reflecting the theme of the game. So while roguelikes are often set in a fantasy world, they don’t use the styled fantasy fonts you might see in a lot of graphical CRPGs (especially older ones). There are many reasons for this, and a number of factors that affect readability.

Single Font

By necessity, traditional roguelikes use a single font for everything displayed, be it text or map information. There’s already an inherent dilemma here: The idea of “readability” takes on a different meaning when referring to either text or a map. The ideal readable text font produces easily recognizable words and sentences, while a map font should produce “tactically readable” maps. With the latter, glyphs should be drawn with an eye towards easy individual recognition rather than as a component of a larger word. This is different from regular font design which places heavy emphasis on how letters interact, knowing that we recognize words as a collection of letters and not for the individual letters of which they’re composed. Thus individual letters in fantasy text fonts can be fairly stylized, but would take an extra moment to recognize or distinguish when used in isolation on a map. Certainly it’s possible for a player to adapt to even the strangest fonts used in this way, as they are simply representative symbols, but letters often carry addition information to aid recognition, like using categorical abbreviations such as ‘c’ for canine, ‘h’ for humanoid, ‘z’ for undead, etc. Less readable fonts also create yet another barrier to adoption when players already have to face learning a new set of input, mechanics, and glyph meanings, systems which themselves may already be complex (though are not required to be). Even long-time roguelike players tend to have a low adoption rate for different roguelikes, not even trying them unless there is an extremely compelling reason to do so, or they need a break from their favorite RL ;)

Another characteristic of tactically readable maps is a square aspect ratio, where horizontal and vertical distances are equivalent in terms of both screen space and game space. Having to translate between the two is something long-time players will be familiar with.


Dungeon Crawl Stone Soup in ASCII mode, with all cells within range 7 encircled. Here Sigmund is 7 steps away, but could feel a lot more menacing if he approached from the left or right. As if Sigmund wasn’t intimidating enough…

This relic of old console roguelikes is best avoided since it unnecessarily* distorts space and causes a disconnect between what we see and the actual situation. (*Unless we count nostalgia among those necessary qualities.)

The reason this convention is so prevalent is that we have the “single font” factor (and that font gives preference to text readability due to a high ratio of text content) combined with another roguelike characteristic: the grid-based display.

Grid-Based Display

Unlike most other games, as a traditionally terminal-based genre roguelikes originated in a grid environment. Though technically no longer restricted in the same way, even many newer roguelikes are played in emulated terminals that maintain the same convention to preserve that traditional look and feel (being simpler to code is another factor).

Given our single-font, grid-based display, what happens if we favor a square aspect ratio to aid tactical decision-making? This:


The Cogmind 7DRL/prototype used a square font to make the map easier to interpret, but the effect on the text… not so readable.

The issue is even more acute with large blocks of text, which become a chore to read as your eyes have to move 50% faster to decipher each line of text. Libtcod seems to be a major force influencing the trend in this direction, because it uses square fonts by default and is one of the primary tools for new developers. Many libtcod games use square fonts, and their text readability suffers as a result.

Words and sentences are more difficult to clearly lay out in a strict grid because some letters are naturally narrower than others. Interfaces without a grid can specify a static one or more pixels between characters, or even apply kerning (adjusting the distance between letters based on their neighbors), to resolve spacing issues.


We can’t discuss fonts without mentioning the two major classifications: serif and non-serif. Serifs are short lines protruding from the ends strokes/lines that form a glyph.


Sans-serif vs. serif letters.

In roguelikes, serifs can serve to distinguish ’1′, ‘l’, and ‘I’, which is especially important in cases where all of these are used to represent map objects as they don’t belong to a word which can be used as a reference when interpreting them. This same consideration comes into play when selecting a monospace programming font, where you also want to make sure that ‘O’ (the letter) and ’0′ (zero) are easy to distinguish.

In addition to their functional impact, serifs are also meaningful stylistically. Serifed fonts tend to evoke a fantasy aesthetic, though that’s not to say you can’t use serif fonts in sci-fi games. For roguelikes at least serif fonts do have the most traditional appeal, no doubt for nostalgic reasons since the IBM PC/MS-DOS console font was mostly serifed.


IBM PC code page 437.



Caves of Qud: A sci-fi roguelike displayed with a good old serifed non-square font.

Fonts can say a lot about a game, though.


This font says “I am probably not a fantasy game.”

In general sans-serif fonts tend to suggest more sci-fi qualities: crisp, clean, streamlined. I’ll be sticking to that theme for Cogmind’s fonts, so no serifs.


There are many solutions for addressing the readability issues discussed above.


If you want a square aspect ratio but don’t want to sacrifice too much readability and don’t mind being forced into a certain style, sufficiently small wide fonts are fairly readable. Like this 8×8:


Incursion: Halls of the Goblin King, shown in a small 8×8 font (click for original size). Characters are small, but then so is the relative space between them.

Using small fonts also enables you to pack a lot of content/information into the UI, though this isn’t advisable for mouse-enabled interfaces where cell size suddenly matters for click accuracy. Fortunately roguelikes are heavy on keyboard use. Despite its many features, Cogmind is entirely playable via keyboard and/or mouse. However, if you’re on a netbook and running one of the 10×10 mini-fonts, I’d recommend sticking to the keyboard unless you don’t mind occasionally clicking the wrong target ;)


While properties that make a roguelike “readable” can be defined objectively, players’ own preferences won’t always align with that definition. More importantly, each player’s situation may differ somewhat due to factors including eyesight, available light, monitor size and quality, etc.

Roguelikes are often pretty good about offering ways to customize the experience to meet these different needs, and with such a low overhead to providing alternative game appearances (just a bitmap), it makes sense to do give players many options in that regard.


Using the options menu to swap between the two 10×10 mini-fonts I’ve been working on for Cogmind (what you see here is the text version, which is 5×10). With these, the smallest resolution/window supported by the game is 800×600.

Font switching is fairly common in terminal roguelikes, but developers can’t rely on the player to decide on the best one right away. A game’s default font ends up being quite important since a majority of players just go with the default, which becomes the font associated with the game in general (screenshots/LPs). There’s also the first impression to consider, since a font that doesn’t click with a given player can contribute to them not liking the game early on (in which case they may not get deep enough into it to want to swap in another font).

Mixed Fonts

To get the best of both worlds, a square aspect map font and narrower font for text, we have to take the radical step unavailable to standard terminal roguelikes: use multiple fonts. As mentioned in the intro, roguelike usage of fonts traditionally blurs the distinction between font and sprites/tiles. However, even if we don’t go as far as using actual sprites, by separating the two we can at least choose an ideal font for each.

Now that many roguelikes with a grid-based interface use an emulated terminal, instructing them to store font information for each cell and pull characters from one of two separate font bitmaps at render time is easy. My own engine uses the simplest implementation, which has the narrow text font take up exactly half the width of the current square font.


A Cogmind parts list like that seen in the earlier 7DRL/prototype image, converted from 12×12 to 6×12 half-width font. Whew.

Half-width text fonts technically double the number of horizontal cells in the interface, but allow layered UI elements to stack nicely while partially obscured lower layers can still be displayed properly. This is more compatible with the cell-stacking system of my own engine which simplifies culling, retains the traditional grid-based look, and is simple to manage since UI offsets are still handled in cells rather than pixels.


A random UI layout mockup showing how 6×12 (green) and 12×12 (red) cells stack on each other.

The primary drawback to this approach is the heavier CPU load from all the extra cells for the same amount of screen space. Cogmind’s display requires more processing power than the 7DRL, but it’s been two years since then, plus the cell stacking system was later optimized somewhat.


The original roguelikes never had to worry about the player’s monitor resolution, expecting instead an 80×25 console window--fullscreen support wasn’t an issue, nor were the implications of different monitors.

Today many players like to fully utilize their screen space rather than keep a game windowed like some application. To accomplish this, unlike tile-based or 3D games that scale geometry, textures, sprites, fonts, and interface elements, roguelikes have an alternative option (or the only option before/without the use of non-console engines): swap out font bitmaps to change the resolution of the entire game to match the target resolution as closely as possible.

For most games it would be costly and time-consuming to manually recreate assets for multiple resolutions, but not so for roguelikes. All we have to do is redraw the font map, a single image, at a different size. This enables us to keep a crisp-looking pixel-perfect appearance at any resolution for which there is a font.

An example of why we don’t want to just stretch the interface:


Caves of Qud in OpenGL mode.

The OpenGL version of Caves of Qud scales the entire interface rather than using an actual font renderer (compare to the earlier CoQ terminal image, which is pure awesome). While rendering fonts would be a better option, even those don’t always look good at every resolution. Working with pixels we know exactly what the result will look like, and seeing as it’s fairly easy to provide fonts for multiple resolutions, I think we should make that effort.

Once we decide against automated scaling, the next important question is how many resolutions do we have to realistically support? Wikipedia has aggregated some interesting and useful data on that topic:


Most common display resolutions that games should support, because that’s what players are using.

Ranking display resolution usage by percentage of Steam users, we see that more than half are using one of either 1920×1080 or 1366×768.

Because a given resolution will not necessarily be evenly divisible by any font, in making these additional fonts we’ll need to consider some other solutions.

The simplest is to add black strips around the interface to fill extra space (a.k.a. letterboxing), though it’s best to minimize usage of this method as some will complain it’s not “true fullscreen” (however, it is important to remember in gamedev that technically someone will complain regardless of what you do…).


An 80×60 console GUI rendered using a 12×12 square font, the largest that will fit the entire interface within a 1366×768 resolution. This happens to be Cogmind’s UI layout, and what it would look like letterboxed at this resolution.

Ideally one or more interface elements will have adjustable dimensions, so that we can increase the amount of actual visible content as opposed to leaving portions of the screen space unused. For games where the maps are large (like Cogmind), we can increase the amount of visible map area.


Taking the same GUI elements from above and expanding their content (no stretching) results in a 66% increase in map/log width (+33 cells), and ~8% increase in map/HUD height (+4 cells). Because the 12×12 font is not perfectly divisible into 1366, there will be 5-pixel vertical bars along each side, a small price to pay for a pixel-perfect interface.

The third font post, in which I’ll cover Cogmind fonts in more detail, will also discuss the selection of font sizes and target resolutions.

A second observation to take away from the display data: Wide screens are now the norm, thus new games should develop their GUIs accordingly. Cogmind happens to have been designed for a 4:3 aspect ratio, which are growing increasingly rare as far as fullscreen resolutions go. Of course, there are a few advantages as well: 1) takes up less space when windowed, 2) keeps information more evenly distributed, 3) requires less computing power. That said, after reviewing the state of resolutions here, on rebooting development of my other game X@COM I now plan to redesign the UI to take full advantage of wide screen support.

This is the first in a three-part series on roguelike fonts:

  • Part 1: Fonts in Roguelikes
  • Part 2: Font Creation
  • Part 3: Cogmind Fonts (coming soon)
Posted in Design, Dev Series: Fonts | Tagged , , , , | 8 Responses


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

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

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

Anatomy of a Robot

First some background.

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


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

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

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

Base Classes and Subvariants

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

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

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

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

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

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

Named NPCs are all unique robots as well.

More Classes, and Variety

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

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

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

Support Robots

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

Non-Combat Robots

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

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

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


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

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

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


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

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

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


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

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

Posted in Design | Tagged , , , | 6 Responses


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

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

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

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

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

But Didn’t You Just Say…

And now for the main event!

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

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

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

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

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

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

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


Activating a Terrabomb.

Other Consumable-like Features

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

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

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

A Note on Progress

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

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

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

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

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

Cogmind Roadmap: Year 1 and Beyond

About one year ago I launched this new blog to provide updates on Cogmind’s development. 1,533 hours later development is still chugging along. Yes, I keep detailed stats about where time is allocated and plan to share those figures and more in a (much) later post, but today I want to write about the first year with regard to the planning that goes into a long-term indie project, as a way of reviewing both where we’ve come from and where we’re headed (1.0 of course!).

First, take a moment to look at the past year, in the form of all the images that have appeared on this blog so far:


Images from the past year of Cogmind development as shown on this blog (click for mega size).

First Roadmap

Development (re)started in July 2013 when I wrote an expanded design doc (1,320 words for the 7DRL became 18,000 words). After some time spent cleaning up the mess that was a hastily coded 7DRL, the next few months were spent adding support for basic mechanics that were missing from gameplay: guided weapons, salvos, overloading, multi-tile robotsmelee combat, large parts, factions, burnout, momentum, EM disruption, hacking, and machines. These were new systems fundamental to the updated game that could be implemented in any order I felt like, thus this period was mostly spent coding down a long list of mechanics--overall a pretty free-form phase of development.

Development time for individual items like those listed above can be measured in days, but the next phase would move into major components and require an ordered approach. You don’t want to start work on the world generation before a good chunk of the content is ready, or build robots before most of the parts are designed. At this point I also needed to know about how much longer development might take. Enter the first roadmap:


Cogmind’s very first roadmap, which didn’t appear until after about six months of development.

Estimated time required for each component is measured in months, with the total expected time for completion at the bottom. The date the roadmap was written appears at the top.

The Cycle

Every couple weeks or so I revisit the roadmap to check that development is proceeding on schedule. Rather than update the roadmap over time, I update a new copy of it in order to keep old states for comparison, making it possible to track when and where the pace of development differs greatly from estimates, if at all.

Looking back at the first half year of roadmaps, I’m pleased to see that my estimates were fairly accurate:


The first half year of Cogmind roadmaps.

Keep in mind that this is only a high-level general roadmap. Most of the intermittent planning stages are spent writing and organizing extensive medium- and short-term to-do lists which are referenced daily/hourly.

Because frequently pausing development of a major feature is an inefficient use of time, newly discovered bugs and necessary little improvements are collected on to-do lists for later and handled in between major features. These lists tend to grow significantly and while this phenomenon is not explicitly shown in the roadmap, it is taken into consideration for the time estimates--always pad your estimates!

Four Phases

Looking at the process so far, and what still lies ahead, three phases of development emerge from the data:

  1. Mechanics: The initial roadmapless phase where basic functionality is designed and coded. A period of very code-heavy development.
  2. Content: Create objects based on all available mechanics. A data-heavy phase without much coding.
  3. World: Build the game world using content from the previous phase. A mix of equal parts data manipulation and coding. Lots of iteration is necessary to reach the intended experience, and algorithms are tweaked to fix inadequacies in the results. (Development has recently been shifting into this phase.)

So what happened to the fourth phase?

It actually belongs at the front--phase 0. Ideally development of a new game begins with a so-called “vertical slice” of the game experience to make sure the long period of development will be worth it. At the simplest level this is a prototype that proves the core mechanic, and I already had this in 2012 with the 7DRL and therefore didn’t revisit it. This is actually a small cause for worry because the new hacking mechanic, a pretty major element, has never been tested as part of the whole! (The ability to have allies is another game changer, but I’m less worried about that.)

The Last 10%

Most developers have heard the saying that the last 10% of a game is 90% of the work. Now I haven’t by any means reached the last 10% just yet, but the principle is nonetheless already taking some effect.

After a year of work there’s already a mechanically sound, mostly bug-free experience with dozens of robots, many hundreds of items, hundreds of pieces of ASCII art, a thousand sound effects, a fully-animated interface, blah, blah, blah… but no game! Every day I literally remind myself “still so much to do…”

Looking back at the first roadmap, nine months from December is… now! There are several reasons for this.

Firstly, because there are many variables in development and I don’t want to waste time planning too far into the future, the last 25% of my original roadmap was either oversimplified or missing important features.

My roadmaps also don’t take into account real life delays, things like vacations, family issues, the occasional freelance job… You’ll notice that the provided selection of roadmaps ended just before May. The string of good examples ends there, as that’s when I put development on hold for five weeks to deal with some other obligations. Another week in July was reserved for family, and several weeks will be eaten up come October, and probably December, too.

I’m luckier than most full-time devs in that I have relatively low operating costs and don’t need to set an absolute release date, but having a roadmap is still essential for staying on track, and of course helping answer questions like “WHEN CAN WE PLAY IT?!”

So when can we play it…?

Now that we’ve definitely moved into the latter half of development, it’s time to revisit the roadmap and make sure it’s accurate based on what we know now.


The latest development roadmap (ordered).

As you can see I’ve switched from months to weeks as we break larger features into smaller chunks for the final run. While using days as the unit of measure would enable more accurate individual items (some may take less than one week, some more), there’s no reason to bother with that level of detail since it’s difficult to predict--might as well fudge it and let the values average out in the end.

Adding in some previously missing elements also increases the total time required. Based on the roadmap, and knowing that at least four weeks later this year will see no development, the absolute earliest we’ll see a pretty complete game is March 2015. Game development sure does take a long time!

Current Progress

I’ve been wanting to make a prettier and more detailed public progress graph available on a new Cogmind site, but haven’t gotten around to building the site yet (hopefully soon). Instead I’ll just post the chart here for now.


Current development progress, rendered of course in Cogmind’s UI style :)

Yeah, it looks full of big holes, a result of the disproportionate amount of time required by individual items (some of those bars represent week-long projects, while others took an entire month), and also because the mechanics and much internal work are underrepresented.

Also note that some remaining components will be outsourced: Sprites and ambient map sound/music. Those don’t even appear on the roadmap, as much of the work would be done in parallel anyway.

Release Schedule

So March 2015 it is? Not exactly. In fact, I’m still aiming for a first release this year. Still debating how to handle the whole release issue…


What state should a game be released in?

I believe a free game should be released as soon as it’s playable. This gives the developer immediate feedback from interested players and the game can grow around them. Heck, if Cogmind were free I’d release it right now since it’s already playable and fun even without a complete game world.

The issue becomes a little trickier with a commercial product, especially when you want to reach the largest possible audience in a market flooded by more and more games--many obscure games don’t get a second look so the first impression is pretty important, be it by media or by players themselves. Releasing too early is putting a greater portion of the results in the hands of chance.

Cogmind is more than just a roguelike dungeon romp, but you won’t see that in the game’s current state. By the time it’s done there will be a story, lore, NPCs… While it’s currently very “playable” in the game sense, the intended experience is simply not anywhere near complete. I hope that when people see, or play, the game they can see a greater range of what it has to offer.

So I can at least say that it won’t be released now.


There are two options I’m considering for how to start releasing.

One is as a demo for a Kickstarter campaign. Still not sure if I should bother with that route since it would postpone 1.0 even further, though it would give the game greater exposure (while implying that “it’s not done yet”) and bring in more money that could be spent on better audio-visual components. I almost want to do this simply as an elaborate excuse to get myself a Cogmind T-shirt =p

The other is simple alpha funding, which itself could go one of two ways. Either initially sell only through my own site without trying to reach out to a larger audience, gradually getting into the market and expanding exposure as necessary, or wait a little longer and go for a bigger early access release on multiple platforms.

Dammit, WHEN?!

“When it’s done.”

Haha, just kidding. Little roguelike dev joke there.

Each of the “hows” might have its own slight affect on the first release date. KS would be earliest, small-scale alpha would be later, and full-scale early access would be latest. I’d like to think that any of these options would see the game out there somewhere in a November-December time frame.*

*Fake fine print: No promises.

Posted in Uncategorized | Tagged , , , | 11 Responses