Official development blog


Traps. Right, that’ll be easy. Design a handful of spaces that when stepped on by the player cause any of a number of effects. Just a couple days of work.

Or not.

That might be the case with traps in most roguelikes, but not Cogmind traps. Two weeks later, they’ve been heavily integrated into many aspects of the game--map generation, hacking, particle effects, sound effects, object labels, off-screen event resolution, FOV code, pathfinding, prefabs… in total traps added 1,202 lines of code to the source, a 1.83% increase. Then of course there was the huge number of tests to run to make sure all these things were operating normally, especially in the context of other macro systems.

Traps were not a part of Cogmind’s original design, and as recently as one month ago were still an afterthought on the “maybe one day” list. In a change of direction I decided to completely remove another feature slated for early alpha implementation in favor of traps, because I believe they can serve to somewhat satisfy players seeking a greater variety of interaction with the environment, in addition to their other benefits.


Cogmind’s game design is very much focused around robots and parts, a principle most important on the map where the intent is to avoid cluttering it with too many disparate categories of objects and therefore symbols. A side-effect of this focus is a relative lack of chances for unique environment interaction. You have destructible terrain and exploding machines, but dozens of other features are packed away into interactive machine interfaces, out of sight. No chests, no altars, no pools of liquid, and no fountains. Not that most dungeon crawling roguelikes thrive on environment interaction--mobs and items are generally much more important than furnishings and terrain features--but Cogmind’s expansive and open map layouts can make it feel even more barren than its counterparts. Personally I think interactive machines already offer quite a lot in terms of dynamic environment manipulation (with still more functions planned), but can understand the desire to physically see more elements out there on the map itself, and have a greater variety of distinctive objects to interact with.

I don’t want to stray too far from the guiding philosophy here by adding a ton of unique objects to the environment, but within the context described above traps do offer a nice package in which to provide more of those “interesting terrain features”--they’re static, compact, varied, and visually unobtrusive. In fact, they’re so unobtrusive they’re invisible! :P

On a gameplay level, traps provide alternatives for stealth builds (anyone inclined, really, but those who don’t have as much space to spare for combat gear benefit the most) to deal with hostiles. They also create additional challenges in the form of preventable but not always predictable events. More on trap effects later.


We’ll start by taking a look at traps’ appearance in game.

For ASCII I went with my first choice and instinct, the ‘^’ common among traditional roguelikes. There really wasn’t any question about that until I decided that all traps would be floor-based and I thought that ‘_’ might be an appropriate alternative. However, an underscore is both less obvious and lacks the same precedent; it also simply doesn’t look at interesting, or menacing. Sorry, underscores, but carets are menacing in their pointiness :D


Spot the traps in these classic roguelikes.

Regarding underscores, one might imagine that a “less obvious” glyph would be a good choice to represent traps due to their nature, but in a turn-based non-twitch game about making decisions based on the full extent of available knowledge, punishing players for not being able to notice something on the map is a poor design choice. Not that players are likely to miss visible traps at first, anyway. They’ve been integrated into the auto-label system so you get a nice pop-up on discovering one:


Auto-labeling a trap on detection, right behind a door.

Rather than create a new label category, for which there’d be no room in the interface, I simply merged them with what were “enemy/ally” labels, renaming the categories to “hostile/friendly.” After all, traps are simply immobile friends or enemies :)


Scan window and auto-label categories update.

In line with earlier talk of avoiding map clutter, all traps are represented by the same symbol, a caret. The only difference between them is color.


All current types of traps, seen here in the testing sandbox.


The tiles version of traps has only just reached the concept stage, and isn’t in game yet. Above are multiple WIP samples (remember Cogmind’s tileset is handled in grayscale), but the single-symbol-for-all-traps approach holds true in that mode.

This doesn’t mean that you only have color to rely on (especially important for color-impaired players, but there are so many traps and a limited set of colors that even I can’t always distinguish certain traps). Manual labels can be called up to get a quick overview of the terrain:


Calling up manual labels for “Hostiles,” which includes some traps I’ve spotted.

One of the interesting obstacles to trap design was incorporating them into the map alongside items. As a rule, to simplify the map viewing and interaction only one object can occupy a space at a time (excluding robots, which can stand on anything except machines). Normally traps are unseen/unknown to the player and we can’t have dropped items avoid those locations, so what happens when the player discovers a trap while an item is sitting on it? The only options here are to either destroy the item or move it. Naturally the latter makes a lot more sense, and while it’s still not entirely logical, Cogmind doesn’t aim for hyper-realism, anyway, much less where that would interfere with player convenience. It’s a good enough solution, handled by pushing all items away from the trap rather than even more unrealistically teleporting the blocking item to the nearest available spot.


Item shifting due to trap detection.


Traps are organized into groups called arrays, which can be manipulated as a whole through nearby terminals, but are triggered individually. An entire array will consist of the same type of trap. Traps are found in a variety of layouts:


Sample trap array layouts, by category.

Layouts are not entirely predictable, but in most cases an array is composed of more than one trap, so strategically speaking even if you get on the bad side of one trap (e.g. it chops your leg off), you can assume there are more nearby and theoretically seek out the rest then use them to your advantage… unless you have absolutely no way to detect the others (maybe later!), or were unfortunate enough to trigger a bomb that blew them all up =p

Trap counts are particularly difficult to balance across Cogmind maps. Too many and the player would be absolutely forced to carry a reliable way to detect them; too few and they become an occasional annoyance that the player will rarely even bother to consider. This is a major reason for organizing them into multi-trap arrays--groups of traps are a lot more meaningful in the big picture where the idea is that players can use traps against the enemy. Even though traps might not be hugely abundant in most areas after I err towards the latter “distribute fewer rather than more” approach, players who ignore that possibility for a while then suddenly take a hit from one trap still have the option to find a way to reprogram the rest, at which point the one hit could have been worth it.


A trap is normally triggered when a robot moves over it, though triggering isn’t a certainty. The chance is based on the form of propulsion used. Flying over a trap will only be detected 20% of the time, while rolling over it in treads is 100%, with varying degrees in between. (There are also some other interesting circumstances that trigger traps, not to be revealed here.)

Stasis traps, designed to catch unauthorized fast movers, use the opposite chance (ex: 100 -- 20 = 80%). And as you can see, rolling around in your tank will trigger every single landmine you’re unlucky enough to encounter (if you’re not actively practicing detection and avoidance). To compensate, treads (and to a lesser extent, legs) are getting an integrity boost, which I think they needed a little bit of anyway to further offset the fact that their slow speed essentially forces a fight with any hostile that spots you. At the same time, slower movement also has the advantage of greater opportunities to locate traps while moving through an area.

Faster forms of movement get a separate chance to evade already triggered traps when using maneuvering thrusters, though it’s funny how this doesn’t really help if you triggered a massive explosion :P

On the UX side, traps do not trigger in the exact moment you step on them--there is a 360ms delay during which an alarm sound plays. The same sound effect is used for all traps, and the reason for the delay is two-fold:

  • 360ms is a very short period, but it creates a moment of suspense during which you aren’t sure exactly what’s about to happen. (Slightly longer would be better for suspense, but too annoying in its potential to slow actions.)
  • More importantly, this provides feedback as to the cause of what’s happening. It makes extra clear that an explosion, for example, isn’t the result of a robot blasting you from around a corner. Sure this information can be gleaned from the log, but good UI design provides redundant feedback through multiple channels.

Well, that escalated quickly.

Triggered traps leave open ground that is then repaired by engineers to normal concrete floor.


Unlike most roguelikes where you may have just one or two ways to detect traps, in Cogmind there are many methods:

  • Built-in sensors give a small chance to detect each trap in view each turn
  • Carry one or more active structural scanners to increase the chance
  • Hack terminals, in the same way that looking for hidden doors works
  • Nearby allied Operators will detect those in your field of view
  • Pick up a non-expired Operator data core
  • Blast a wide area of ground with explosives--any surviving trapped areas will stand out among the rubble because they are better reinforced

There are also several “non-detection” alternatives that let you know traps are nearby before having revealed them, including triggering another trap in the same array, or simply seeing trap-related hacking options appear in a terminal interface (only listed if there are actually traps near the terminal).


Once you’ve detected traps, there are also multiple ways to deal with them:

  • Rewire them individually using a Datajack (improved results when done in combination with hacking utilities)
  • Blow up the floor, or set them off with an EMP (these work even if you haven’t found the trap--just annihilate everything)
  • Take another route, or make one--most areas are accessible via multiple paths (sometimes through hidden doors), and if not you could excavate a tunnel of your own
  • Hack terminals to disarm or reprogram entire trap arrays at once

Hacking nearby trap arrays via terminal commands.

Traps converted for your own use, triggering when a hostile passes over them, will oscillate on the map:


Aw yeah, these traps are MINE. Now I just need to find some enemies to lure over here… (or keep it as a convenient area to retreat to)

To make controlled traps more predictable and therefore more useful, it is assumed that in reprogramming them you also raised their sensitivity to dangerous levels, such that they will always trigger regardless of the robot’s propulsion type. You’re welcome :)


Like items (parts) in Cogmind, the goal with trap effects is to be more than simply direct damage and increasingly large numbers. There is a very small amount of “number increasing” going on, while the majority of traps rely on unique effects to differentiate themselves (or in the case of damaging traps, at least unique aspects to their damage, like a special side-effect or different damage:AOE:falloff ratios for explosions that impact their tactical implications). Now that I think of it, there aren’t even any traps that simply do direct damage to the robot stepping on them without some other effect.

So sure we have basic landmines, because explosions are satisfying (admittedly more so when an enemy is doing the triggering), though we mostly have other effects like slicing off parts or setting off alarms. In fact, I say “traps are done” but the effect of one in particular is not--its special effect alone will take an entire week to complete. Yes, it’s a bit of feature creep, but I feel it adds some very interesting possibilities to the game, as it’s far more than just a regular trap. I will neither confirm nor deny what this trap does--just wait for the next release and find out for yourself :D

Another important consideration in trap effect design was ensuring that most are also useful to the player in some way, while not being altogether deadly when triggered accidentally. There are even multiple types of traps you may want to step on and trigger under certain circumstances! How’s that for interesting ;). This plays into the idea that traps should fully serve their new role as a multi-use terrain feature.

In the end, it makes more sense to think of “traps” as an optional new resource to use against the enemy. Yes they can damage and maim you, but for the experienced player their presence is a net positive. For those that you do trigger, however, none are trivial. Unlike other roguelikes where traps are either pointless (e.g. you can 100% recover from their effects immediately after triggering one) or deadly (they can kill an unprepared character in a single hit), in Cogmind there is no recovery until you reach the next depth--an important rule underpinning much of the game’s mechanics--and traps are nowhere near powerful enough to kill you unless you were almost done for, anyway. (The ALMOST_DONE_FOR status is best avoided, by the way!)

To conclude, here’s a nice new way of rewarding pursuers for their tenacity:


Luring the enemy into their own traps pisses them off, by the way :D

Okay, one more. Much to the enemy’s chagrin, here I step on a heavy explosive while they’re in mid-assault:


Just another perk of being a bigger badder robot than they are.

Posted in Design | Tagged , , , | 10 Responses

Roguelike Development with REXPaint

I mention REXPaint a lot on this blog. This is not coincidence, nor because I created it. It happens to be an incredibly useful piece of software for roguelike development!

REXPaint is an in-house tool I developed in 2013 shortly before resuming work on Cogmind. It has since been made freely available for other devs, artists, players… anyone who might need a powerful and user-friendly ASCII editing program. After two years of using and updating it, I’m pretty familiar with how to take advantage of its features for roguelike development, and would like to provide a little guide to ways REXPaint can make your life easier.


First, an overview of what REXPaint can do:

  • Edit characters, foreground, and background colors separately
  • Draw shapes and text
  • Copy/cut/paste areas
  • Undo/redo changes
  • Preview effects simply by hovering the cursor over the canvas
  • Palette manipulation
  • Image-wide color tweaking and palette swaps
  • True-color RGB/HSV/hex color picker
  • Create multi-layered images
  • Zooming: Scale an image by changing font size on the fly
  • Built-in image browser
  • Extreme image compression (far better than png)
  • Exports to PNG, ANS, TXT, CSV, XML, XPM, BBCode
  • Skinnable interface
  • Load custom fonts

For gifs showing many of these features in action, see the features page on the REXPaint blog.

As you can see, it’s a fully-featured paint program, albeit focused on manipulating ASCII images. It turns out that interface, maps, and art, all three separate elements in other games, are unified in roguelikes that embrace the ASCII aesthetic. Thus a single editor like this can benefit work on many different aspects of a traditional roguelike.


In the early stages of game development you have the design and mockup phase. One of the nice things about creating a roguelike is that with the right editor you have an extremely reliable way to preview what the game will look like even before building a prototype! Any visual element from UI and maps to text and art can be accurately drawn and assessed for the right layout, colors, and overall “feel.”


The original Cogmind primary UI mockup, as drawn in REXPaint. (click for full size)

Some earlier Cogmind mockups have been mistaken for screenshots, because there’s no way to tell the difference! (Sometimes I have a mockup displayed on my desktop and click on it to interact before realizing it’s not actually the game =p.) Of course, to achieve this effect you’ll have to load your game’s custom font into REXPaint. (Or use one of REXPaint’s own fonts for your game, which is fine, too--classic terminal fonts are available, as well as many from legacy systems. More fonts are coming in future versions.)

For a developer, being able to see everything as it will be / as you want it can be very motivating, especially as it gives you a clear goal to aim for and reduces the need for tedious trial-and-error design.

Even after there’s a working prototype, and really all throughout development, there’s often a need to add new features and UI elements. These can be drawn from scratch, or better yet expand upon the original mockups to save time and ensure compatibility. With Cogmind I design many related parts of the interface in a single image, using multiple layers to store each one. Any given layer can be hidden/revealed to show how different elements interact. The top layer is for annotations.


Multi-layered mockup--overlaying the original image with some data windows and the hacking interface (all handled in REXPaint). (click for full size)

Eventually you’ll build up a little library of convenient reference material. Coding the UI is so much easier with a pixel/cell-perfect representation at hand.


Not every roguelike needs ASCII art, but those that use it can definitely benefit from a tool like REXPaint. Rather than hard code art into the source or rely purely on text files, it’s much more efficient to use a dedicated tool designed to streamline the creation process, then import the results into the game at runtime.

In terms of organization, there are a couple different ways this can be achieved. The most straightforward method would be to simply draw each piece of art in its own image. REXPaint is equipped to facilitate this approach, since it includes a built-in image browser which enables you to quickly swap between different images for editing, comparison, or copy-pasting. (Tip: Ctrl-tab is a new hotkey that instantly swaps back and forth between the current and most recently opened image. Great for frequent inter-image work.)

Depending on your workflow, the one-image-per-asset approach could quickly become unwieldy once you have more than a handful of small assets, so another method is to create “ASCII spritesheets.” This borrows the concept behind asset storage for most pixel/texture-based games, and it’s what I do with Cogmind.

Related assets are grouped into fewer image files, and the game knows how to find and extract specific images it needs. Cogmind currently has two different types of spritesheets (adapting to what seemed like the most convenient method for each situation): even-distribution spritesheets and irregular spritesheets.

Item art always fits into the same rectangular area at the top of the data window, and as such it’s a good candidate for an evenly distributed spritesheet:


A blank item art spritesheet, including macro coordinates for reference. (click for detail)

To create a new spritesheet I just use REXPaint’s file browser to copy the blank spritesheet (shift-click), rename the new image, and drop in art (usually drawn on a separate canvas). The game knows that individual pieces of art all use the dimensions 24×10, thus it only needs the “macro coordinates” of the image for a given item in order to find that art.


Excerpt from a spritesheet (“swep”: special weapons), and above that you can see how art is referenced by file name and coordinate in data files. (Typing in the item name isn’t necessary, but it’s nice to have for reference.)

Machines can be of any size and the game must know exactly what area they occupy, so for those I went with a free-form spritesheet wherein each image is enclosed by a very faint rectangle. Pieces of art can appear anywhere in the file--just give the game a rect’s top-left coordinate and it will automatically measure the width and height of the rectangle to extract the art within:


A subset of non-interactive machines, together with the part of their data file that indicates their art offset coordinates.

Animation & Post-Processing

REXPaint does not natively support image animation. Theoretically you could manage it by using a different layer for each frame, or putting frames adjacent to one another in a spritesheet, though without a way to preview the animation in program (or export it as an animated gif) it’s probably of limited use.

For my own projects, I prefer the greater flexibility of handling animation in code/scripts. Cogmind’s new title screen is an example of taking a multi-layered ASCII image from REXPaint and applying procedural animations to it.


Cogmind title screen animation.

Read more about the title creation process here.

For a more basic example of post-processing, see this spritesheet excerpt containing low/mid-level fabricators:


A subset of interactive fabricators.

Notice that they’re all gray, though in game interactive machines always appear in color so they stand out from other machines. Just as you can recolor sprites and textures using color keying or shaders, you can also consider recoloring ASCII foregrounds/backgrounds or even altering glyphs. And this is after they’ve been imported into the game. This way I only care about the relative brightness of the glyphs--colors for specific machine types can be set elsewhere, and changed easily.


You may notice that the above images tend to have a lot of unused space as far as spritesheets go. I’m not worried about wasted space in these spritesheets, since they compress extremely well.

REXPaint’s native format, saved with an “.xp” extension, is highly compressed and squeezes even the most massive images to negligible size. The format specification is openly available (see the manual, Appendix A), so anyone willing to read and decompress binary files can take advantage of this format in their own games. There’s even some code you can reference: REXPaint user /u/BaconSoap has kindly open sourced his C# RexReader for importing .xp files; for online use, /u/chiguireitor has written a Node.js module to load and draw REXPaint sprites; there’s also the Rockpick library for Clojure users, by /u/aaron_ds.

If you’d prefer to work with text files, REXPaint can just as easily export .csv or .xml files (as well as unicode .txt, but that strips all color data). The drawback to text files is they lack compression and therefore take up quite a bit of space despite being easier to read in. In any case, .csv is the best text option.


A file size comparison across all export formats currently supported by REXPaint--this one for the 69×28 title screen shown above (image dimensions are in cells, not pixels).

Useful Tricks

In my past year with REXPaint I’ve come up with a number of time-saving practices that might help you, too.

Setting up the right workspace environment can speed things up immensely. For example, early on while working on item art concept sketches I realized that it was a real pain to find some of the glyphs I frequently used from the default CP437 layout. Numbers and letters are easy enough, but most of the items use a line art style, and the many different orientations of lines are ordered pretty randomly and even blend together in the spritesheet. So I created an art “worksheet” and redrew the glyphs in a more understandable orientation at the top. RXPaint’s right-click-to-copy interface makes accessing the needed lines much faster:


Copy-pasting glyphs to draw a Gatling Laser. Much easier than finding them in the grid to the left.

I can just copy that worksheet as a base when starting a new set of images.

Later when I began adding color to the concept images and developing Cogmind’s color schemes, I added those schemes directly to the worksheet as well. Drawing palettes onto the canvas itself is just as easy as using the actual palette since you can always right-click to copy a color. (It’s arguably even better, since you can do a few things that aren’t easy with the normal palette, like copying entire sections of colors and moving them together.)


Cogmind’s item color pairing reference (indicates primary and highlight color).

That’s not to say the actual palette is useless. Besides supporting unlimited numbers of palettes, it provides lots of additional functionality like image-wide swaps, color shifting, and saving colors from the RGB/HSV/hex picker.

If you do start (or are already) using REXPaint, I highly suggest skimming the manual’s complete list of commands, since the UI’s lack of any kind of submenu interface means there is no way to discover advanced features--on that list you’ll probably discover some very useful functions you didn’t know were available…

The three most common REXPaint features I use for my own work:

1. The aforementioned copy-selection-by-right-click tool. I love paint programs that have this feature, since you’re commonly reusing the same colors (and/or in the case of ASCII, glyphs) which can often be found much more close to where you’re editing than the actual selection area of the UI. In REXPaint in particular, this feature copies only what elements you have active (e.g. glyph/foreground/background), so you also have the option of selectively copying only parts of the source cell.

2. Foreground and background colors can be shifted left or right based on their palette position via a Shift- or Alt-click. So by setting up your palette correctly, i.e. order shades in rows, you can first draw in gray or some other single color, then tweak the shading as necessary.


Painting the Gatling Laser drawn above, then tweaking foreground color brightness. Notice the color selector automatically shifting in the palette.

3. An easy way to test out different colors throughout an image is by using single color swaps. Shift-clicking on one palette color and then on another switches all occurrences of the first color throughout the image. (REXPaint supports full palette swaps as well, but this feature is more convenient.)


Fast color swapping in REXPaint.

Final note: If like me you end up using REXPaint for a lot of different purposes, it can help to have multiple copies in parallel, each with their own appropriate config and loaded fonts.


Multiple Cogmind development copies of REXPaint.

Additional reading: For more information, check out the art-related posts below.


Roguelike maps are most often procedurally generated, at least in part. Some roguelikes use one or more static maps, which can be drawn in REXPaint and imported into the game. A far more common practice than fully static maps is merging bits of static content with procedural maps.

As I’ve explained before, I think there are lot of advantages to integrating hand-crafted components into procedural generation algorithms, and REXPaint is one tool for creating those hand-crafted areas. In fact, I already wrote an entire post on prefabs in Cogmind, so I won’t rehash all that content here.

The basic idea is that you can draw a specific area how you want it to look, even storing additional static data where it belongs, like using a combination of glyphs and foreground/background colors to represent terrain, props, mobs, objects or other map features. This information can be split up into multiple layers for convenience, and contain markers referenced by some external text file which further describes the map’s contents. (Check out the post linked above for images and details.)

On the topic of mapping, I also use REXPaint to design layout parameters that inform the procedural generation of Cogmind’s maps, but those are too spoilery to share here ;)

Future Feature?

For Cogmind the prefab editing method described above is sufficient, but I’ve considered one possible extension to REXPaint that would make roguelike map work even easier. The idea is to integrate named objects (and maybe even some related data?) directly into the map itself. At best this could essentially take the place of the external text file used for Cogmind’s prefabs.

This would be a major extension of REXPaint’s functionality (taking it beyond pure image editing), so I would want to get it right, requiring that I have my own test case to guide implementation. Cogmind isn’t quite complex enough to warrant developing this feature, but one of my future games just might be. Of course, this feature must also be conceived as a generic solution that isn’t tied down to some specific game.

Anyway, if you might want to use this feature, let me know in the comments so I can add you to the small but growing list of interested devs. Another new way to discuss features and interact with other users is via the dedicated board on the recently opened Grid Sage Forums. Feel free to leave comments here or there if there are any other features you’d like to see in REXPaint. I may do another release within the next few months.

Sample Projects

So obviously I’m using REXPaint for my own projects (currently Cogmind and X@COM), but what are others doing with it?

A good number of roguelike devs know about and use the program, though many roguelikes never see the public eye (or take a very long time to reach it) so most of the downloads have yet to lead to any concrete games.

One notable exception is Kerosene Thunder, an air combat roguelike by Pishtaco over on TIGSource. His first mockup was drawn in REXPaint earlier this year:


Kerosene Thunder mockup (click for full size).

And he’s drawing the planes in ASCII, too:


Starfighter from Kerosene Thunder demo

It’s still in the early stages, but I tried the first tech demo and it has the makings of what could become a very cool game. You can see more recent screenshots in the forum thread.

I know many other roguelike devs actively using REXPaint for their projects, but haven’t seen much of their work yet. If you are a developer using REXPaint for your game, let me know in the comments or elsewhere! (The only requirement is that it must be linkable and display screenshots I can easily find and pick from.) At some point I will make a dedicated page showcasing all such games.

REXPaint has also been picked up by some forum game GMs and players to visually map what’s going on, mostly in boards frequented by roguelike players (ex: DF/C:DDA forums). I hadn’t thought of that when making REXPaint, but it’s a pretty creative and useful idea :).

Some artists have also picked up REXPaint just for fun. Among them DragonDePlatino, maker of the DawnLike RL tileset, used it almost like a pixel art program to make this dwarf:


Dwarf by DragonDePlatino

And here’s Zelda the Roguelike (a mockup):


Zelda the Roguelike, by qbicfeet.

Bonus: Some ship mockups for a modular ASCII shmup I was prototyping last year:


The shmup that wasn’t to be.

See more art in the REXPaint gallery.

Since I began releasing ANSI versions of REXPaint, about a fifth of downloaders target that, which would be for those interested in drawing traditional escape-code ANSI art (.ans files). No one from that particular scene has shown me anything yet, though.

If you have used or are using REXPaint for your own art, maps, mockups, or other project, drop a note in the comments to tell us about it! (Better yet, show us!)


I won’t claim that REXPaint is the best option for everyone needing a tool like this. Some of the other options might work better for you, so check them out, too!

  • ascii-paint (2009): The first modern ASCII editor, by Shafqat Bhuiyan and libTCOD roguelike library creator Jice.
  • ASCIIPaint (2010): An ASCII editor written in flash--somewhat slow and not easy to use, but it’s the first and only one I tried out when looking to make some ASCII art, thus it’s the editor that convinced me I needed to make my own ;).
  • ascii animator (2011): Ben Porter’s fork of ascii-paint that expands the interface to add support for animations and gif exports. Definitely check this out if you want to make animated ASCII art.
  • advASCIIdraw (2013): This one is a little more like raster art programs than your normal ASCII editor. It supports multi-cell brushes, making it a better choice for large pieces of art with varied content. Unfortunately it comes with a serious drawback: there is no undo/redo feature, which is extremely important for any kind of editor--not because people make mistakes, but because it encourages experimentation. Lack of an undo function is a pretty big barrier to “efficient creativity.”
  • Playscii (2015): A very new open source option with a rapidly expanding feature set. I haven’t tried this one before so I can’t offer any opinions; check out the website for details.
Posted in Uncategorized | Tagged , , , , , , , , | 6 Responses

Readable Text Fonts for Roguelikes

There’s a reason “terminal” fonts are a standard for traditional roguelikes even today. Certainly tradition plays a part, but even more importantly, they’re designed to be highly readable.

Last year while still in pre-alpha Cogmind received a huge influx of font bitmaps to support different resolutions, in some cases with multiple variants at a given size. At that point the goal was to make sure Cogmind had a unique look that was also consistent regardless of resolution (or as close as possible given the difficulty of pixel-perfect scaling that maintains proportionality).

With the alpha launch behind us and hundreds of players diving into the game and providing feedback, the first few releases were/are aimed at quality of life enhancements--tweaking the interface and adding optional features that will improve the experience for even a minority of players (because the options menu is not already crowded enough =p).

By far the top request is to improve readability. A majority of players enjoy and prefer the Cogmind’s original font, but a number of factors contribute to poor readability for some players:

  • The UI is extremely dense, and at minimum must be able to display an 80×60 grid of characters, thus screen resolution places an upper limit on the size of each character.
  • Modern high-DPI monitors squeeze the grid cells into an even smaller physical space, making the native fonts hard to make out since in many cases they rely on lines with a pixel width of only one.
  • For the same reason, Cogmind’s native fonts don’t usually stream or record very well--video compression tends to reduce single-pixel lines to almost nothing.

We can resolve these issues for most players by providing thicker fonts with more even pixel distribution, as well as multiple options at each size to suit slight differences in personal preference. These alternate fonts will lack the thematic appeal that we get with Cogmind’s sci-fi font, but accommodating players is more important--readability trumps all in a text-heavy game. Besides, they’re optional :)

With single words and short phrases readability is less of an issue. The biggest problems arise when reading log text, hacking results, and dialogue where there are full sentences and paragraphs to parse, so that’s the best test of readability and what I show below.

Four New Typefaces

Typeface #1: X11

This font comes from a common Linux windowing system. You can find a huge collection of bitmaps and even the source code for producing them here. Of the new fonts, X11 might be the easiest to read overall as it’s the most traditional of the bunch.


New X11 fonts.

Typeface#2: Terminus

For Cogmind, I like Terminus for its natural readability with a shape that still preserves some sci-fi flavor. See many more sizes and optional features of this typeface here.


New Terminus fonts.

Typeface #3 / 4: Proggy / Dina

These fonts will be familiar to many programmers, as they’re commonly used for coding. Programming fonts are a natural place to look for good roguelike fonts, since they’re both monospaced and designed to facilitate character recognition.


Cogmind’s entire engine loop as seen in the IDE (VS2010). I’ve been using Dina as my coding font for about eight years.

Adding these to the game was simply to provide some extra options at smaller resolutions, which they work best at. You can see the full selection of Proggy/Dina fonts here (all by the same author).


New Proggy fonts.


New Dina fonts.

Options Menu

As of Alpha 2, Cogmind comes with a mind-boggling 82 font bitmaps.


Showing some of the fonts in action via the options menu.

For comparative images showing all the new fonts grouped by size, see this forum post. (There are also many larger sizes available for resolutions at and above 2K, though all are derived from fonts shown above.)

More Possibilities

The above fonts seem to have solved the readability issue for most players, at least those for whom their resolution-limited size is not simply too small regardless of font (and therefore requiring a larger screen to select greater sizes).

More typefaces can easily be added, though I think the current set combined with what was already there is enough to cover most needs. (The new fonts come with Alpha 2, to be released soon, though they were pre-released separately weeks ago in the forum post linked above.)

For those of you developing your own roguelikes, another nice option to consider is an amazing customizable font named Input.


This is the fourth in a four-part series on roguelike fonts:

Posted in Dev Series: Fonts | Tagged , , | 8 Responses

Releasing a Commercial ASCII Roguelike, a Post-Mortem

(Graphs and sales data follow the wall of text to give them context.)

Releasing Cogmind felt great--two years of hard work finally reaching a state where I could share it in its entirety.

Honestly I would have preferred to release much earlier, but the really early 0.10 roguelike release approach is too risky with a commercial game, especially so with a game like Cogmind where it might otherwise be difficult to instantly convey to anyone only semi-interested in this type of game that it’s a truly unique addition to the roguelike genre and games in general. Surely the long-time fans who played the original prototype understand the significance of what Cogmind aims to achieve, but part of the goal is to attract a broader audience while staying true to the game’s traditional roguelike roots. I wanted it to explode onto the scene with a strong trailer and good gameplay from the get go.

More importantly, releasing too early would have also significantly slowed progress, because as a responsible indie developer I’m obligated to interact with the community. I can’t say I don’t enjoy it, but there’s no denying that simultaneously managing a community takes a toll on the pace of development.

Instead of releasing early I focused on making the development process as open as possible and frequently shared information through various channels. (My “indie marketing methods” are a topic for a separate future post.)

I’ve released games before, but this was my first commercial endeavor, and let me tell you it’s a completely different experience!

With so many amazing games out there in the market, convincing potential players of the value in your own is hard enough for little known indie devs, let alone when you ask players to hand over real money at the same time. Adding money to the equation naturally puts a greater burden on one’s sense of responsibility--it’s no longer players deciding to try out a hobby project that costs only the time invested in playing it, it’s people who believe in you and the game enough to contribute to its financial sustainability. With Cogmind this is an even bigger factor because it has begun with an alpha release, and a pricey one at that (more on this topic later). I’m humbled by the strong support Cogmind has received so far, and it drives me to continue pushing the boundaries of what is possible.

We’ll begin with the events surrounding release week itself…

Release Week

Several days before the alpha launch, I began putting together an ordered step-by-step list of things to do immediately before release, and those that would take the game through release day and beyond.

It included everything from transferring new live website content (prepared and waiting in separate directories), to mailing list notifications, to forum/social media announcements (all pre-written), to activating the forums and subreddit, to confirming that important parts of the website were operating normally… In all it would be a very hectic day, but with a detailed triple-checked list I would be freer to attend to unforeseen roadblocks. And we did have one serious hitch come launch day, literally the very last pre-launch checklist item: Revealing the trailer.

Around 9:30 AM I switched Cogmind’s Alpha Launch Trailer (uploaded and set up a couple days earlier) from private to public on YouTube, and much to my horror not a single one of the embedded links sprinkled throughout announcements and the website were working! Viewed directly the video worked fine, but no embedding despite having checked, re-checked, and even toggling all related settings. YouTube wasn’t helpful at all, giving absolutely no hint as to the cause of the problem, instead showing a generic error message anywhere the video was embedded.

I waited about 15 minutes to see if it might be a timing issue (the error message did suggest “try again later”), but I simply couldn’t wait any longer and decided to harness the adrenalin rush to completely re-ready the trailer from scratch. So I started over--deleted the original trailer, uploaded the 155 MB file again, reset all the associated options, and re-embedded it everywhere it would appear. As part of my preparation I’d kept a list of all locations where I’d previously embedded the trailer, which came in extremely handy to make sure I didn’t miss anything in my rush to fix this. Still, this detour delayed the launch by an hour :/

That day I barely stepped away from my computer at all until 4 AM the next morning (at which point I slept next to it until about 9 AM, waking up only when my wife walked in to ask “Are you okay?” =p)

The entire day was spent with plans (simple text docs) and social media on one monitor, and Google Analytics open on another. In my excitement I didn’t think to record what I was seeing to share it here, but with GA I could watch in real time how many visitors were coming to the Cogmind site, and from where. When I noticed an unfamiliar source link I could immediately follow it to see what people were saying, and answer any questions if necessary. Twitter was also good for instant communication with players.

Since I had no previous experience with a commercial game launch from my own website, I was worried that a surge in traffic could exceed some kind of server limit (I’m currently using only a shared server), so I even had cPanel open to keep an eye on server resources, but this turned out to be completely unnecessary. Even with several dozen visitors browsing at any given moment, server resource meters barely showed a blip. Whew.

Marketing & Exposure

As this was only a “soft launch” of Cogmind as a playable (and enjoyable) Alpha, mostly intended as a way for existing die hard fans to join the development process, I didn’t contact any press prior to release.

In fact, I didn’t even announce a specific release date. For as long as a month prior to launch my schedule targeted May 19th, but I wanted to remain flexible in case some oversight required postponing it by another week. While I’m fairly experienced at estimating project development cycles, releasing a game commercially adds a lot of unfamiliar variables to the mix, so I couldn’t be sure I’d get it right and wanted to leave room for adjustments.

Somewhat into May I started to hear from fans who’d begun checking the website daily, so I announced the likely release date via Twitter to save them the trouble, and on May 12th when everything seemed on track I also posted an in-depth announcement on /r/roguelikes to give the core audience a heads up.

On launch day I posted an announcement in all the same places I’d been regularly sharing news throughout development--my dev blog, Facebook, Twitter, and forum threads on TIGS and Bay 12. Then also one less frequented but very important location (to avoid spamming it with development news): The roguelikes subreddit:


The launch announcement on /r/roguelikes is one of the sub’s highest voted threads of all time :D.

A huge thanks to the encouraging number of fans willing to put money on the table on day one.

Overall performance in the first few days was impressive given the complete lack of press coverage. It was nice to see years of work finally coming to fruition, giving me confidence that I’m on the path to sustainable development. A handful of small indie news sites picked up on the launch, but even collectively their limited audiences couldn’t compare to support from the existing roguelike community at large.

However, after a couple days when the initial surge of sales naturally began to drop off, I contacted Rock, Paper, Shotgun since they’d written about Cogmind a couple times before, including as part of their “Best Upcoming PC Games of 2015″ feature. Shortly thereafter they published an announcement which drove another sales spike:


Google Analytics session statistics for Cogmind’s Alpha Launch (click for full size). Notice that “% New Sessions” is fairly low, because many community members are frequent visitors to my site. (The value is the same looking only at the first 24 hours of launch, and the 24 hours before that, so we can mostly discount this as being attributed to repeat visits by those who’d just found the game.)

Some additional stats for your reference while we’re at it:


Naturally English-speaking countries top the list here. The UK percentage is slightly higher than usual for my site (it usually hovers around 5%)--the May value is most likely skewed because RPS is based in the UK.



Browser and mobile device data.

On both the initial launch day and the day RPS published its article it was exhilarating to watch the real-time website stats, which showed an average 30 visitors browsing at any given moment. On other days the number hovered around 5~10.


Sales driven by the RPS article. As an indie developer releasing a first title, seeing an inbox that looks like this is one of the greatest feelings.

This at least surmounted the first hurdle, proving that Cogmind is promising enough to convince new players to jump in, but the anxiety didn’t quite end there.

What if they didn’t like it?

Fortunately reception turned out to be overwhelmingly positive, for which I guess there wasn’t much cause to worry since I’d already spent more than a year managing expectations through social media. (Later I’ll be writing about specific marketing methods that were used to build and maintain the original audience.)

Of course not everyone visiting the website had heard of Cogmind before, so I did see a few voices of skepticism. The lack of media previews/reviews were no doubt keeping some prospective players from pulling the trigger. What we needed were some testimonials/quotes from real players. These happened to be piling up fast, so on the second day I collected some good ones and linked them directly from the Buy page:


Cogmind: Early player quotes (click for full size).

In the absence of official reviews (though several good LPs did begin popping up immediately after release), I’m certain the page of quotes helped convince* some players less familiar with the project that it was worth it, as did the long-running dev blog and to a lesser extent the newly active forums and subreddit for those who searched around. (*While I didn’t do any A/B testing, I was watching GA and could see visitors going Buy page > Quotes > Buy.)

Throughout the first week I continued to update the Buy page with information and adjustments based on both direct feedback and discussions I was monitoring online. That combined with the many other pressing issues that popped up--troubleshooting for players with issues unique to their OS, finding temporary workarounds for a few bugs, basic marketing and promotion efforts (mostly by joining discussions as they appeared)--kept me busier than I’ve ever been for such a long period in my life.

For two weeks straight starting from a couple days prior to launch, I only managed to get 5~6 hours of sleep each day. Definitely not enough, but my sense of responsibility to the community and Cogmind itself kept me going. Several times I imagined how nice it would be to have a team with which to split up the never-ending list of tasks. I’m surprised I wasn’t stopped in my tracks by sickness (that didn’t happen until just after my schedule returned to normal--thank you, body).

It’s also interesting to imagine how much different this experience must have been from releasing a game 20~30 years ago when social media and constant connectivity weren’t even a thing. Sure as a developer today you still have the choice to ignore them, but that’s ill advised given how beneficial monitoring and adjusting to reactions in real time is for any kind of marketing plan.

Part of the purpose behind Cogmind’s soft launch was to teach myself what a commercial launch is like, and I believe it’s achieved that goal. The full launch next year should be somewhat less hectic since I now have a clearer idea of what to expect and can plan accordingly. Of course there’s also an established and growing community I can lean on in some regards, and for that I’m very thankful :)


The original release schedule determined in January 2015 put the release in April, but as we neared that date it was apparent Kacper’s tileset wasn’t going to be quite ready, plus I happened to get really sick for much of April, so it made sense to postpone it to May.

As far as marketing strategy goes, supposedly the second-to-last Tuesday in a given month is the best day to release a game, so I settled on May 19th. Pushing the date back several weeks gave plenty of time to perfect launch preparations and handle all the non-game parts of the plan--website, forums, payment system (that turned out to be rather complicated and took several days to get set up just right), etc. That worked well to keep me from getting overly stressed about the whole thing.

Seeing as I’m not the only one who reads up on marketing strategy, it should come as no surprise that launching with me that day were several other indie games and The Witcher 3… This would have been more worrisome if I was going for a general release, but as stated this launch was primarily aimed at the existing core fans who’d already been waiting for years. I’ll be more careful about setting the 1.0 launch date.

Technically Cogmind was available for much of its audience (in the U.S.) on the evening of May 18th, equivalent to the morning of my 19th here in Asia, so I was a little ahead of those other games, too.

The close proximity of releases did result in some memorable moments, one in which someone asked to trade away Witcher 3 for Cogmind, and--while not related to release dates this was also interesting--someone else “honestly regretted having purchased GTA V instead of Cogmind.” It’s awesome to read stuff like that as an indie developer.


The most controversial aspect of Cogmind’s alpha launch was the price. Charging for a traditional roguelike is already against the norm, much less launching an alpha at $30. However, the backlash was far less severe than I expected, with complaints in the minority and even individuals outside the regular fan base coming to my defense.

A humorous comment in response to the alpha trailer serves as a backdrop for a discussion on roguelike pricing: “Why is this not unfairly cheap like all other roguelikes? :P”

The roguelike community has long enjoyed the availability of sprawling highly replayable games with deep gameplay, all free of charge. These great games can be free because they’re developed as hobby projects which can take as long as they need to reach maturity, while also having lighter asset requirements than most games.

Cogmind takes a different approach, reaching for a level of audiovisual polish never before seen in a traditional ASCII roguelike, at the same time shortening the “epic roguelike” development cycle from 6~10 years to “only” 3 years. Developing a quality game within a reasonable time frame requires a significant investment, one that members of an underserved niche community are apparently more than happy to support when a developer finally comes along to make the leap.

Thus it wasn’t too surprising when a lot of roguelike fans expressed their confidence in the value of Cogmind. Some examples:

  • “Cogmind is the most beautiful and dynamic ASCII roguelike I have ever seen.” --jason0320
  • “It’s like seeing Doom the first time when everyone was stuck with Wolfenstein at best.” --HRose
  • “I honestly believe this is one of the most fantastic games of any genre I have ever played.” --biomatter

But among the dissenting voices I heard the comment “Only fanatics would pay a price like that.” Fortunately…


Always know your target market demographics :)

In a genre traditionally dominated by free games, one would naturally question the wisdom of selling a roguelike at a premium, even a high-quality one. However, roguelike fans have formed a healthy tight-knit community, one that is all too happy to see the genre expanded with modern games which still lean heavily on traditional elements. Not long after Cogmind’s launch, another roguelike developer on Reddit (/u/chiguireitor) posted a poll to the core roguelike players community there (/r/roguelikes), and among the questions was one regarding payment. The results are enlightening:


Payment tendencies among the roguelike community.

We can’t know the reasoning behind the “already did” buyers, since they could fall into either the “reluctant” or “supportive” categories, but taken together there is a respectable portion of the community willing to pay for a good roguelike. In any case, this partially explains the strong initial support for Cogmind despite the preponderance of free roguelikes.

Still, it’s important to examine why I chose the price that I did at this stage.

First of all, I had originally considered a Kickstarter campaign, but it was both logistically problematic (not available in my country) and for Cogmind in particular I don’t like the common types of backer rewards that either give up some element of creative freedom by allowing backers to decide game content itself, or provide extras that drain time and resources which could otherwise be devoted to game development.

While I didn’t take that route, Cogmind’s alpha release was still built around a crowdfunding model for which there is a precedent that alpha access costs around $20~30 in exchange for some additional perks beyond what future purchasers will receive. (In this case mostly taking the form of in-game credit.)

Quality niche games are also often priced in this range, and I believe Cogmind to be the epitome of both quality and niche. Certainly the price could start lower if the game appealed to a broader audience, but it’s not the type of game that is likely to achieve broad popularity, nor does it strive to do that.

Games must be priced for their market, not some general “okay indie games average about $10 right now so this should be $10, too.” Take a game like RimWorld, for example--a unique high-quality indie game that can afford to set a base price of $30 because no other game can offer the same experience.

Secondly, even if from an economic perspective we assume that a somewhat lower introductory price would result in greater total revenue (which at the right price point it almost certainly would), is that what we want right now, during alpha? Nope.

While the ultimate goal is to recover the full financial investment in Cogmind’s development, and hopefully even generate profit that can be reinvested into future games, the current stage is more about interacting with the core community for whom the game is designed, not those who buy discounted games on a whim and may or may not ever even play them, or maybe play for a little while and probably complain that “it’s too hard” (in the case of Cogmind, a punishing traditional roguelike) then give up, never to play again.

For the alpha I want quality players who are familiar with where Cogmind is coming from, who really care about Cogmind, or who’ve at least taken some time to educate themselves about the game given the wealth of information available online. Higher prices generally lead buyers to make an informed decision, and informed buyers are more often happy players.

Players who pay more are also much more likely to dig deeper into a game to discover what it has to offer, and like the roguelike classics before it Cogmind is a rewarding game to delve into…

In a general sense, when pricing a game with a fairly long open development cycle and plenty of room to grow, it makes sense to start at the higher end of what is acceptable to the target audience (assuming the initial state is a game already worth the price to that audience!). You can always lower the price over time, but raising it won’t go over nearly as well.

During the alpha access campaign, because a number of visitors to the website are undoubtedly interested in Cogmind but turned off by the current price, they have the option to leave their email address instead. Prominently displaying this sign-up information on the Buy page both lets these potential players know Cogmind will be available for less next year and gives me a way to notify them when that happens--everyone wins! This was an excellent suggestion received shortly after launch, exemplifying another benefit of getting out there and engaging the potential audience and acting on their feedback where it makes sense.

My decisions here were all based on an analysis of current market conditions, my own objectives, and most importantly the characteristics of the game I’m selling. Every game must find its own price reasoning based on numerous relevant factors. Overall it took a couple months to settle on a model, and this after more than a year of observing the performance of other games.


Another obvious influence from the KS crowdfunding model is the idea of multiple “tiers.”


Cogmind Alpha Access Tiers

I didn’t originally plan on having tiers, but prior to launch some fans expressed a desire to buy multiple copies which they could then gift to others, and naturally they’d appreciate a discount. So I decided to add a couple extra tiers, also throwing in a shirt I’d designed at the highest tier. (At first I intended to offer the t-shirt with a copy of the game for an extra fee, but the payment processor said I couldn’t sell physical products that didn’t ship immediately, so I got creative and instead made it a “free bonus” at the highest tier.)

The package tier approach turned out to have some unexpected benefits.

Some players not interested enough to support Cogmind at the $30 alpha price saw the buy-three-for-the-price-of-two intermediate tier as a way to get alpha access at 33% off--all they needed was to find two other buyers. Many of these groups formed organically via their forum/social media of choice, i.e. free marketing. (Even as I write this post, two separate individuals on Twitter are introducing the game to their followers and asking if anyone wants to join them.)


Part of the problem with Cogmind’s introductory price is that I call it an early access “alpha,” eliciting understandable knee-jerk reactions of “Alpha =/= $30.”

Fortunately long-time followers are well aware of the years of open development behind the game already, and know it to be far more complete than what might normally be dubbed an alpha.

At launch Cogmind could easily have been considered a beta release, but then I don’t want players to judge it as nearing completion because the goal is much more epic. In roguelike tradition there’s plenty of game to enjoy already, and it’s fun with an extremely low bug-to-content ratio, but development will continue for up to a year.

At the same time, while I will always stay true to my vision for Cogmind, there’s no doubt that current players will help define some aspects of the final game, either directly or indirectly, and that, too, is meaningful and valuable to them as early access participants.


Given the somewhat controversial price and low external exposure, the most important question is: Did it work? The answer is yes, so far.

I remember thinking before launch… okay, we currently have about 650 items that can be claimed via the alpha access campaign tiers--I’ll be happy if those trickle away throughout the remainder of alpha development. Gone in a week and a half.

I was pretty shocked. It’s an “alpha,” after all, and my first commercial release.

Impressive, but taking a serious look at the numbers we still have quite a ways to go. Since picking up the Cogmind prototype in June 2013, I’ve invested approximately $43k USD into development (all costs included). After taxes and fees about half of that has been recovered so far, and now we already find ourselves heading into the infamous long tail, which will likely (hopefully) transform into the stegosaurus tail at some point, especially once we reach 1.0 with a much bigger launch and broader marketing effort.

The good news is, thanks to generous alpha supporters I’m confident we can expand the total budget and reinvest this initial sum to realize the best version of my complete vision for Cogmind! A huge thanks to everyone who’s made this possible :D.

Cogmind’s recalculated total budget from zero to 1.0 now lies somewhere around $70k. We’ll see how accurate that is next year…

In summary, is this performance good for an indie traditional roguelike? Hell yeah!

Is it a lot of money? Well, no :(. It’s a pittance for two years of full-time work--a regular day job would blow this away, but there is hope and it’s rewarding to (for now) be able to continue creating something that myself and others love! Let’s hope this becomes a sustainable trend. Traditional roguelikes require so much work that I don’t know how smart it is to do this as a commercial endeavor, but at least the result is a high-quality game that can be delivered in a relatively short period.

Now let’s look at a few graphs.


Cogmind Alpha Launch Sales Data, Month 1.

For the alpha launch, since there were two primary sources of buyers as discussed earlier, we’re in an interesting position to compare the reaction to the game between the core audience (long-time fans and roguelike enthusiasts) vs. a general indie PC audience (RPS etc.).

Notice the sales peaks are reversed compared to the trailer/website peaks.

The first spike is an immediate rush by fans to get Cogmind on day one. Yay! Conversion rates are impressive here, but don’t mean much there when you have a pool of people waiting to watch the trailer and jump on the website solely to buy the game. Incredibly steep slopes on that first sales spike reflect the fact that it was mostly composed of dedicated followers. Cogmind wasn’t even announced anywhere else in those first few days.

Then RPS published their announcement (and a few smaller sites naturally pick up the news from there), followed by another surge in sales, surprising considering a large portion of RPS readers had never heard of Cogmind or were not necessarily interested in traditional roguelikes. Judging based purely on the first two days of sales from each source, the ratio of buys by RPS readers visiting the site and/or watching the trailer was nearly half that of the core fans, despite the high price. This bodes well for when Cogmind is completed and launched on a larger scale.

Note: More stats specific to trailer views can be seen in the trailer post-mortem.

In Retrospect…

Every post-mortem needs a section like this. The old “What would I do differently?”

Here I’m happy to say almost nothing.

Certainly I would want a more clearly designed Buy page, kinda like what it started out as on day one, instead of the hodgepodge of notices and even flashing text (yep, I went that far) that it became after days of tweaks to address different issues.

I would’ve also liked to have that “email notification sign-up” ready from day one as well--adding it only after a day or so missed the initial surge of visitors, some of whom would’ve signed up. At least I know that most of those visitors are roguelike community regulars, so they’ll probably hear about Cogmind through regular channels, anyway.

Unrealistically, releasing six months to a year earlier would’ve been nicer since the advent of VAT in 2015 had a pretty huge effect on prices for European players--there would’ve been more, and they would’ve been happier, if the high price wasn’t pushed yet higher by such a massive tax rate.

All said I think the launch went really well, and the main reason for that is everything was planned out well in advance. It was hectic, but only in terms of there always being more to do than I had time for, so I repeatedly adjusted my TODO list as necessary to make sure any high-priority items were taken care of. I lived with that list in my face for two weeks, and interestingly, some things I’d planned to do “later on launch day” were literally pushed back more than a week as more pressing issues were inserted.

Anyway, the point is make a list, frequently skim it to ensure it’s prioritized, and knock things off the top one by one.

The Future of Cogmind

Having successfully transitioned from private development to a public launch with an engaged and satisfied community, it’s time to look towards the real beta/1.0. Up to a year of additional work will yield the full story and cast of NPCs, many more maps and some new parts and mechanics, more ambient sound effects, music… While I could crank out 1.0 by the end of the year on my own, having an active community in the foreground will slow that down a bit, and the final version will be better for it. No sense in rushing it as long as we have steady progress and (generally) a new release every month.

In terms of the business plan, while I aim to eventually put Cogmind on Steam for access to a broader market, that time is not now. Aside from that being a different audience for which the game is not quite ready, financially speaking it’s nice to start off with as many direct sales as possible so that most of the funding makes it to me--money that can go into development rather than fattening the coffers at some corporation. Think of the money that would have been lost from those charts above (and all the sales since) if I’d started out in Steam. Yes volume will more than make up for it, but that’s for a later time. In related news, five weeks after launch GOG contacted me about releasing through them… No rush, but it’s nice to be recognized.

I hope you enjoyed this bit of inside data. Expect another post-mortem with many more figures and comparative analysis after we launch 1.0. Since the beginning of development I’ve also been collecting detailed time management stats that will explain where I’ve allocated that most valuable of resources, but that’s for a separate future analysis.

Posted in Post-Mortem | Tagged , , , , | 30 Responses

The Making of Cogmind’s Alpha Trailer

A game’s trailer is extremely important, so rather than release some mediocre video recordings during pre-alpha development I decided to let gifs show off the animation while keeping the audio side of things to myself, waiting for the game to reach a more complete state when I could then invest a lot of time into producing a proper video.

My previous experience with ASCII videos taught me that they’re difficult to do well,  so I knew it would take a while to find a satisfactory process for Cogmind.

In the end Cogmind’s 90-second trailer required nearly three weeks of full-time effort from inception to final production. At first I considered hiring someone else to do it (a professional), but I like creating things myself, and finding, hiring, and bringing another person up to speed on the project would take a while, not to mention one of the most time-consuming parts--collecting clips for a trailer--is something I’d still have to do myself, anyway.

In all I spent several days researching and testing various recording, editing, and encoding methods, a day or so scripting animations, several days per iteration recording various game content, a couple days about half-way through thinking of solutions for various issues, a couple days collecting and analyzing feedback, and another couple days producing and encoding the final version.

The easiest way to talk about all the aspects of trailer production is to simply follow the process from beginning to end.


I’d read a bit about trailer production before and saved the best bits, so I started by refreshing myself with some useful reference articles, the two best sources of information for me being Kert Gartner’s blog and an article by

The most important general tips can be summarized with a few bullet points:

  • Keep it short, 60-90 seconds.
  • You don’t have to showcase every mechanic, just give an idea of how it plays.
  • Zoom in on details the viewer should be paying attention to, if confined to a smaller area than the entire screen/UI.
  • Follow dramatic structure for the best effect (setup > build > climax > conclusion).
  • Leave the viewer wanting more.

On the technical side I found surprisingly little reliable information about techniques for creating high-quality pixel art trailers, so I would have to figure that out on my own. That’s also part of the reason I’m sharing my findings here :)


The obvious first step is to figure out what to show in the trailer.

A couple times over previous months I’d made a list of features and trailer format sketches, but when it came time to write the final version, rather than taking the “list of features” approach common among game trailers I decided on a slightly more story-like method that also reflects how you play the game. It begins with your boot-up sequence, then quickly progresses through each element of the experience: explore, learn, evolve, rebuild, evade, destroy. Obviously “destroy” is our high-action climax.

Each segment was added to a spreadsheet-based outline to have an idea of whether the content would fit within a reasonable time frame, and provide an organized reference during recording:


Part of the first draft trailer content outline (unedited!). The format aims to condense Cogmind into a series of segments that can be represented by one or more clips from the game. Most segments of the trailer were changed in some way or another between the first and final versions.

The outline was fairly accurate, and showed that the trailer would be on the long side at nearly two minutes. But no sense fretting about that right away; it would be easier to edit it down after seeing it in action to analyze which portions work and which don’t.

As expected, the first pass felt too slow, so much of the same content was recut into a quick trailer only half as long (60s), with a faster intro in a more instantly gripping cinematic trailer style. But that second approach felt too fast for a game like Cogmind, not to mention it didn’t clearly say as much about the game itself. You can see a rough concept for the alternate intro here.

While a cinematic trailer would be more fun to watch, it might also misrepresent the game or attract the wrong audience, players that could be disappointed with the game for not being what they expected. Certainly a key part of marketing is getting everyone and anyone to watch your trailer, even if doing so takes a trailer that doesn’t specifically say much about your game and how it plays. I’ve seen trailers that are fun, but say almost nothing about the game in question. What a waste of my time. I’d rather steer away from deceptive tactics in favor of using the opportunity to show off as much of what the game is really like as possible.

The trailer should be something I can point to and say “this is Cogmind in a nutshell.”

Another reason for dropping the second intro concept is that its aesthetics look very out of place compared to the rest of the trailer, which is composed entirely of the blocky terminal UI, glyphs, and pixel art. I think the intro we did use, cut directly from the intro of the current alpha version itself, does a good job setting the atmosphere and tone using the same aesthetic style you see in the game.

For the rest of the trailer content, clearly something in between the long and short versions was necessary. So I revisited the first version and shortened each segment by cutting out any static shots and less meaningful content, even managing to throw in some extra clips and still come out a full 30 seconds shorter than the original length.

At 90 seconds Cogmind’s trailer comes in at the longer end of the “acceptable length” spectrum, mostly due to the slow intro. Perhaps not the best way to hook average players, but I think it will work for anyone who might be interested in the genre/style that Cogmind represents… Terminal console! Retro sci-fi! Roguelike!?

I felt the necessity to show a few more scenes than usual because Cogmind’s otherwise minimalist presentation might give the impression that it’s a simple game. I think the final pacing works okay, though, and there’s a pretty natural progression from one element to the next. The trailer clearly follows dramatic structure from the thematic intro through a gradual build to the climax, and is well-supported by music the entire way.


Recording video clips is (for me) by far the most time-consuming part of trailer production. After deciding the desired recording conditions, there’s looking for and/or setting up those conditions for recording, then redoing a scene again and again until it turns out just right. I keep save game files for each situation in case I needed to revisit them to re-record (I did end up revisiting them all for the final version, as the first time was a quicker rough pass).


The alpha trailer’s video content. About three times as many clips were recorded in all, but these are all that went into the final version.


It took a while to figure out what software was best suited for the task.

My options were more limited than most games because Cogmind doesn’t explicitly use the video card, eliminating the possibility of recording software supplied by various GPU manufacturers that reads the card directly, or third-party applications such as FRAPS which function in the same manner.

I’d heard good things about OBS, and rather liked how easy it was to record with, so that was my first choice. However, multiple attempts later I couldn’t get it to record Cogmind without any loss of color accuracy, even with supposedly lossless settings. Naturally the final trailer will end up being compressed before it reaches the viewer, but if the clips I record for production purposes already start out looking bad, the final product will suffer for it.


The game itself on the left, and an OBS playback of the same scene on the right.

OBS obviously works for some people, but not me. I’m sure it didn’t help that OBS couldn’t rely on my video card and had to record the desktop directly.

So for recording I fell back on my old standby, Camtasia Recorder, which I had used years before and was surprised that it had improved significantly since then (finally…). The good thing is it’s made to record the desktop, and does a great job of it with perfect color and pixel accuracy, all with small output file sizes. I did encounter a couple issues:

  • System audio must be set to output 44.1k, otherwise audio recordings will be distorted. Mine was 48k and it took a while to figure that out.
  • Windows 7 caps desktop recording at 30 fps while Aero is active. Camtasia can be set to temporarily deactivate Aero every time you record a new clip, but it’s a somewhat slow process that would make quickly re-recording clips tedious. I could have also just turned Aero off manually for the duration of recording work, but I figured 30 fps is good enough for Cogmind and YouTube doesn’t usually use 60 fps anyway.

Other than that it’s a pretty nice recorder, and you can specify the exact area to record for cases where it’s smaller than the entire window/screen.


The biggest problem facing ASCII/pixel art recordings is the huge hit on final quality caused by YouTube compression. Compression works okay on “normal” videos in the way it smears/blends pixels, but the effect is hell on detailed 1px-width ASCII surrounded by blackness.


A capture from an old X@COM video I recorded looks like this even in 720p HD. High definition!?

The first method of dealing with this is to give YouTube the highest resolution possible so it has more data to refer to in the compression, and also offers viewers with the bandwidth a way to view an outright better quality video. Thus the goal with Cogmind was to upload the trailer in 1440p.

As I only have a 1920×1200 monitor I considered buying a 1440p specifically for recording the trailer, but I was worried my poor laptop wouldn’t be able to handle both running the game at that size and recording it. Not to mention files would be much larger and slower to edit. The alternative was to record the game at 720p to save on processing power (and therefore production time), then upscale the final trailer. Cogmind’s default/native resolution is 720p, so it made sense to record at that size and upscale (more on that in the editing section).

A second even more effective method for recording pixel art is to zoom wherever possible. Zooming increases pixel size so the art is less susceptible to the effects of compression, at the same time helping focus on the action which is probably only occurring on a subset of the full screen anyway. This is especially useful with Cogmind since the full interface can be pretty overwhelming, though you don’t need to be paying attention to the entire thing at once.

Rather than zooming to an arbitrary size, nearly every zoomed shot in the trailer is recorded at either 636×360 or 424×240. These dimensions are precisely divisible into 1272×720, the size of Cogmind’s full 720p window, a factor that will come in handy later on. (Note “720p” actually has a width of 1280, but Cogmind only scales in multiples of its grid dimensions, so a full 720p window leaves 4px black bars on either side--it’s not noticeable, but they’re in the trailer, too.)


Early on I decided I could speed up production and keep the visuals consistent by using the game engine itself to create as much of the animation and text as possible, rather than relying heavily on post-processing software for transitions and special effects. It did take a little while to both write these scripts and add a place in the game where I could test and record them, but overall it was less of an investment than it would be to learn new software and techniques--obviously I’m already quite familiar with my own engine, so I may as well leverage what I’m good at.


One of three styles of text animation seen in the trailer.

Minimal editing requirements also meant I could stick to simple software with which I was already familiar: Camtasia Studio. It does have a couple annoying limitations, namely lack of support for relative directory structures within projects, and only one project may be open at once. Aside from these it’s plenty easy to stitch media together, layer and adjust video and audio, and dynamically zoom or pan to different areas.

That said, except where dynamic zooming/panning in a single scene was required (only one instance), I actually avoided using Camtasia to zoom because there’s no way to control the quality. Not that the quality is horrible, but with pixel art the idea is to retain as much clarity as possible at every stage of the recording and editing process.

Every time you convert or resize a video the quality could degrade, so I needed a method to create a very high-quality upscale without side effects like those that ruin ASCII videos due to compression. For this I used nearest neighbor scaling. I found only two programs capable of this, Movavi and Adobe After Effects. Testing showed that the latter produced smoother animations, but the required file sizes were huge and Camtasia chokes on large files. Theoretically I could have produced a higher quality trailer with a faster computer, but not on my dev laptop with this many clips:


The timeline for Cogmind’s alpha trailer as it neared completion.

So I went with the cheap lightweight solution, Movavi, which can be set to rescale a video in “draft” mode (in video speak this is the equivalent of nearest neighbor scaling).


My Movavi nearest neighbor upscale settings. Note that audio set to “Auto” outputs AAC, which is not compatible with Camtasia Studio, so I had to change that to PCM.

As mentioned earlier, zoomed scenes were recorded at 360p and 240p, so upscaling them to match the full-size 720p trailer gives pixel-perfect results without any distortion! Never in my life have I been happier that 1272 (Cogmind’s native width) is evenly divisible by 636 and 424. It was convenient to produce both the close-ups used throughout the middle of the trailer, and the really tight shots seen at the end.


Look at that beautifully crisp pixel scaling compared to the fuzzy mess of a regular zoom.


As soon as the first pass rough edit was complete I shared it with our trailer composer Alex Yoder to give him some material to work from and get an idea of what direction he planned for the music (before that I’d already provided him with a copy of the game and documents outlining the world and story).

The music is an absolutely essential part of the trailer that really glues it all together, and helps set the mood as much as the visuals. With his initial concept in place, it was just a matter of waiting until the trailer reached its final iteration before he could time the music to match a few crucial points.


Early feedback played an important role in shaping the trailer during the editing process. Here I’d like to thank Ben Porter, 0x0961h, Highsight, Matt Chelen, and of course Alex Yoder (composer) and Kacper Woźniak (artist), for watching the trailer in a few iterations and providing constructive feedback that led to real improvements in the final product. Getting feedback from more than one source was great for the different insights and perspectives, while any areas of overlapping criticism were in definite need of change.

Probably the hardest part of getting feedback on a trailer I didn’t want to make available to the general public is that I didn’t have easy access to the most valuable opinions: those from outside the circle of people already quite familiar with Cogmind (which is pretty much everyone who knows me…). I’m sure the trailer could be improved further by gathering reactions from a broader audience, but my marketing department is not quite equipped for that :).

One interesting side effect of the trailer feedback that came from respondents’ girlfriends and wives (including my own) was a change to the title logo shown at the end. Apparently all this time the font reads more like “COGMINO” to the uninitiated, something I’d only heard once before and didn’t really take into consideration until suddenly more and more people brought it up. So half-way through trailer production I redesigned the logo to make the “D” more D-like and even modified the “C” for some symmetry.


A smaller version of the Cogmind title logo, animated.

This required changing the logo throughout the game, blog, websites, and forums… Still, better before launch than after!


The first step to finalizing the trailer was to output a lossless AVI from Camtasia (that gave a 7.5 GB file for 90 seconds of video…). But before upscaling to our 1440p target resolution, here I ended up using After Effects for something after all.

Because the colors recorded from the game (especially the intro) were somewhat dark, and that characteristic would be further exaggerated by compression, the entire trailer needed a bit of brightening, something that Camtasia can’t do--it’s pretty bare bones in terms of video enhancement features. After Effects is of course the perfect choice, and fortunately its one-month trial is plenty of time to handle something like this, so I didn’t actually have to own it. I had AE add a global +30 to brightness, then render the same lossless AVI.

The final step was to use Movavi to both upscale the trailer to 1440p (draft/nearest neighbor!) and convert it to a high-quality MP4, which came out to 155 MB. The MP4 file size produced by Movavi was both smaller than its high-quality AVI output and appeared to give the same results when both were uploaded to YouTube, so I stuck with MP4 since it’s a more widely compatible format. (As I discovered when I tried sharing them with others, AVI containers require the right codecs to play so it’s not a great format to rely on.)

I also created a 48 MB 720p MP4 to provide as a smaller option for direct download. (Some people like to download trailers, so I made both HD versions available on the website.)


And the final trailer (mp4 downloads available here if interested):

Post Mortem

In all it took 135 hours (!) to complete the trailer, totaling an approximate $2k USD investment for audio and production time.* The costs were steep (even more so considering that was time during which I wasn’t working on the game itself), but I think it was well worth it. Producing a mediocre trailer to cap two years of development would be very disappointing to say the least!

(*To be clear, the primary costs were my own time spent on the trailer, and the fact that I hired a professional composer (Alex Yoder) to create a track that fit the mood of the game and timing of the trailer content, rather than tacking on some less than ideal royalty free music found online. I strongly believe that game audio is an incredibly important part of the experience, both in a trailer and within the game itself. You can produce a trailer for much less, and much more quickly, but it depends on the type of game and trailer you want.)

Even after the trailer was complete (production stretched from April 7~27), I still watched it multiple times nearly every day up until launch. It felt so good to see the experience of the game summed up in 90 seconds like that.

On launch day I was happy to finally show everyone the full extent of what I’d been working on as a whole, rather than piecemeal in the form of snapshot blog posts. Public reception was great, and I very much enjoyed reading the feedback. One comment was particularly memorable: “Watched the trailer and immediately said ‘Oh….oh no.’ My wife asked what was wrong. I showed her the trailer and halfway through she said ‘Well you need THAT, it looks like.’ She’s right. I do. Buying post-workday.” --Double_Atari

Below are viewer stats showing the May 19th launch through the end of the month:


Cogmind alpha trailer view stats (May 2015).

The first spike is launch day, and the second is from a later announcement on RPS. Viewing hours totaled 206 in May alone, so that at least tops what I put into producing the trailer =p.

Relative audience retention was for the most part above average for YouTube videos of similar length:


Cogmind alpha trailer relative audience retention (May 2015).

And by the absolute audience retention graph you can see that even at the one-minute mark we’ve kept approximately two-thirds of viewers watching which is quite good:


Cogmind alpha trailer absolute audience retention (May 2015).

As for the future, I don’t look forward to making another trailer simply because it’s 1) a ton of work, 2) keeps me from working on the game, and 3) the alpha trailer already reflects much of the final experience while also showing as much of the game as I’d ever want to in a video, in order to avoid spoiler content.

It would seem like a better alternative to a future trailer would be shorter and even flashier, and show less gameplay, though as stated I don’t really like that approach, as “sensible” as it is from a marketing standpoint.

Posted in Uncategorized | Tagged , , , , | 5 Responses