Official development blog

Player Metrics (Alpha Challenge 2015)

Player metrics are an important resource for a game developer, providing valuable insight into player preferences, capabilities, strategies, and more. Data is also fun, so I’m here share it with you all :D

Cogmind features the ability to upload player statistics at the end of each run (opt-in only, of course, in case some players are opposed to the idea), giving players a passive way to contribute to development.

Certainly one of the best ways to learn how players interact with a game is to observe them playing it in person (or via streams/LPs), but those opportunities are more suited to examining interaction from a UX/learning perspective, while in-game metrics collection is the only practical approach to form a broader view of the player base. This view is steeped in quantitative detail, and scales nicely.

Having access to real data from players, as opposed to theoretical predictions relied upon during the earliest stages of development, enables developers to improve the game or at least make sure it’s working as intended. During early access this also has the benefit of informing future design and balance decisions.

Alpha Challenge 2015

I’ve been collecting data for a few months since alpha launch, but until recently only used it to compile the leaderboards, being too busy to do anything else productive with it. Ever since launch it’s been my intention to hold a tournament for alpha supporters, so with a stable mostly mechanics-complete Alpha 3 behind us we finally did that this month, a two-week event which turned out great.

As an organized event (with prizes!) “Alpha Challenge 2015″ was an effective way to stimulate participation and related discussion, as well as a good opportunity to write some code to analyze the wealth of data coming in. Overall it was a surprisingly large amount of work and I couldn’t make any progress on the game itself for the duration, but the resulting discussion and analysis is technically another important part of development!


General overview of the two-week AC2015, in numbers. (click for full size)

You can see the full results of the tournament here, but the purpose of this post is to more broadly examine the heaps of data for what it can tell us about Cogmind and our players.


Some points to note before going into our analysis:

  • The data doesn’t include all runs (or even all players), only those that qualified for inclusion, defined as non-anonymous players who earned at least 500 points. Players automatically receive 500 points for ascending beyond the first depth (though it’s still possible to earn enough points before leaving that area). This eliminates from the pool 258 runs where the player was either destroyed before they did anything meaningful, or were perhaps start scumming or learning the game.
  • Graphs depicting data by depth include only runs that ended at that depth, not historical data for runs that made it beyond that point (data which is unavailable). The effect slants the data in various ways, but the impact is not significant enough to undermine the usefulness of the results.
  • The participation rate was 4.62% of the approximate 1,450 owners at the start of the event, which seems fairly good considering a lot of players bought to support the game but don’t intend to play until 1.0, or already tried it out a bit for fun but don’t intend to dive in until it’s complete to get the “full experience.” (And of course others also just happened to be busy during the event.) Still, conclusions drawn from this data are generally valid for describing the characteristics of the greater player base and how they would fare in the game, as in this group we clearly have a spectrum experienced and inexperienced players. A few players even bought during the Challenge and jumped right in; others repeatedly reached the late game to vie for the top 10 spots.

On to the data!


Taking a look at preferences is one good reason for getting as many players participating at once as possible. It’s also something I’ve been the most curious about, and now we have answers! Cogmind’s score sheet uploads mostly report gameplay metrics, but there’s a handful of other variables such as those enabling us to create the following graphs.


Player input/map UI preferences.

For its first 18 months of development (excluding 7DRL and the interim hiatus) Cogmind was purely ASCII, and its visual design is first and foremost aimed at the traditional roguelike community. So it’s no surprise that more than one-third of players forgo the tileset default in favor of the easily parseable, Matrix-hacking, alphabet-soup style.

That said, one of the goals with Cogmind is to attract fresh players to the genre, and even in alpha it’s succeeding in that goal by becoming the very first roguelike for some! Without tiles as a gateway this would be an elusive goal, even despite the game’s unique take on ASCII visuals. Certainly a larger portion of early access players are hardcore roguelike fans, which pumps up the ASCII numbers somewhat, so I expect the ASCII percentage to drop as the player base expands (it will be very interesting to look at this ratio again once Cogmind is on Steam). For comparison, according to the 2012 DCSS survey “only” 24% of players use ASCII in that game, plus 1) that was three years ago--DCSS’s popularity has since increased--and 2) it’s not on Steam.

The most interesting takeaway from the input graph, keyboard vs. mouse, is the rather significant number of keyboard users, again about one-third of the total and, again, like ASCII we can attribute this to a greater percentage of dedicated genre fans taking part in alpha access. “Mouse users” includes those who solely use the mouse, or a hybrid mouse-keyboard style to speed up some commands; “keyboard” is a special mode in which the mouse cannot be used, so it’s pretty clear cut who’s relying purely on the keyboard (the fastest way to play). As with tiles, a fully mouse-enabled interface is a vital accessibility feature needed to reach a broader audience.

We’ll take a closer look at ASCII and input preferences as part of the scores discussion further below.


Player font preferences.

Font size is less of a preference than an incidental variable reflecting screen size, since a majority of players play in fullscreen mode which selects the largest possible font size that will fit. From this we can extrapolate the game resolution (not otherwise recorded) and compare their respective usage ratios to the values assumed prior to launch.

Last year while discussing fonts in roguelikes I wrote about common resolutions (direct link to relevant chart; see also the beginning of this post for a Cogmind-specific chart w/considerations), and we can now see that the predictions more or less hold true for Cogmind’s current players. The largest group of players (44.8%) use a 1080p (FHD) screen, followed by the second largest group (17.9%) using 720p (HD).

Regarding typeface, I’m pleased to learn that a significant majority of players (70.8%) prefer the original Cogmind typeface. To accommodate players who were having trouble reading it on today’s high-DPI monitors I did add dozens of alternative font options post-release, though while more readable those do lose the thematic appeal of the default typeface. Still, that’s 29.2% of players who would have been less happy without the new fonts.

Play Time

An average 32 minutes per session (or entire run for at least half of players) seemingly qualifies Cogmind as a coffee-break roguelike, but this wasn’t my aim to begin with. While the game is designed for epic scope, it does happen to be easy to pick up an earlier run in progress, as everything you need to know is displayed right on the HUD. Stopping a session mid-map isn’t advisable, in order to maintain general floor-wide situation awareness (especially if corrupted since you can lose map data), though new areas are frequent enough. Because these mostly wipe the slate clean, and you can’t travel backwards to previously visited areas, there are plenty of opportunities to pause a run at points that keep a low barrier to continuing later. There is also anecdotal evidence that late-game players were shortening sessions to 10-15 minutes each to avoid making mistakes =p, and others remarked that it was easy to pick up unfinished runs.


Runs completed each day, and the total number of participants by that point.

Throughout the event there was a fairly steady increase in new participants, playing anywhere from 20  to 75 runs each day. (For comparison, there are approximately 25 runs per day under normal circumstances--no event, no recent release.)

The majority of runs (71.5%) occurred during the first half (Sep. 9-15), and 35.8% of participants each played 10 or more games throughout the event. This latter group formed the majority of players still playing through the event’s latter half as they competed for achievements and the top 10.

Weekends (Sep. 12-13; Sep. 19-20) don’t seem to have had any meaningful impact on participation.


Cumulative play time throughout the event, and the number of hours played per day.

In all, 484.7 hours were played (again, this excludes nearly one-third of runs, those that didn’t make it beyond the first floor), with a trend that more or less reflects the previous graph. A few participants were playing a lot and making it quite far on some runs, which combined with the relatively small pool of players is enough to skew the data upward on some days.


Duration of individual runs.

On average, it takes about half an hour to escape the “early game” (Materials), and about an hour and a half to reach the late game (Research). However, the duration of a run is largely impacted by strategy--where a given Cogmind lies on the stealth-combat spectrum. Stealth runs will be significantly faster, and are more closely represented by the Min line, while getting bogged down in combat and the rebuilding cycle will pull a run towards the Max line. Also notice that the average is much closer to Min than Max at all but one depth*, suggesting that either most of the Max values are outliers or more players were attempting stealth runs. (*Note: -1 has very few data points.)

Segment-specific observations:

  • Materials: The seemingly unreasonable Max play time in these early floors actually represent a brand new player learning the game--probably a lot of reading going on.
  • Factory: These numbers are not players still learning the game, but rather reflect the fact that Cogmind gets much harder here and maps are huge. It’s easy for beginners fresh from being able to conquer Materials to spend a lot of time wandering around the Factory engaging in the back and forth of combat, which becomes significantly more intense at this depth.
  • Research: Regardless of player experience, it’s easy for anyone to spend a while searching for exits here, a fact supported by the sudden rise of our Min line.
  • Surface: The huge range seen at depth 0 (victory!) exemplifies the difference potential between stealth and combat runs. Both the Min and Max here were achieved by one of our latest experts, zzxc, with a fastest speed win of 81 minutes (1867 turns*) and the highest-scoring combat victory that took 6.9 hours (28,485 turns*). (*The fastest builds can move 10 or more times in a single turn, while slow builds might move only once per two turns, or slower.) For reference, including wins outside the tournament stealth runs take anywhere from 3k-5k turns and last 80-120 minutes, while full combat runs take from 17k-28k turns and last 4-7 hours. Currently expert player Happylisk holds the record for fastest combat win in real time, at 4.2 hours.

Overall the average play time to each depth seems well balanced, gradually rising at a rate of 10-20 minutes per map (this again supports the earlier mention of coffee break convenience). We’ll see the time spent at each depth change with the addition of many more maps in future releases, though those are optional side routes so the choice is up to the player whether to branch out horizontally.


Scores started out spread all over the place, with clearly experienced players making it to Research early on, intermediate ones to Factory, and beginners falling in Materials and the early branches.


Change in the average score (cumulative over all previous scores), shown with the highest individual score for each day.

The average individual best scores (i.e. the values used to measure players against one another) increased 77.7% from their lowest point at the beginning of the event to the end. By comparison the average of all scores rose by only 15.6%, dragged upwards by players improving their skills even as new/less experienced players continued to join in the later days. At the same time that average had some downward drag in the form of high frequency players who hadn’t learned how to reliably exit the early floors and could still die in Materials despite being capable of performing okay in the mid-game. (Early and mid-game strategies can differ greatly so some players might be better at one than the other.)

Other observations:

  • Both averages plateau for the last couple days because there were no significant personal bests added in that period.
  • Close to two-thirds of players (59.7%) managed to at some point rise above the all-score average, a rather high percentage that reflects the greater luck factor involved in runs for players who have trouble reliably besting the mid-game. (They might come across some really nice parts, for example.)
  • Looking at the daily highs, the tournament’s only two combat wins are apparent on 9/17 (zzxc) and 9/20 (Happylisk). Full combat wins are much more risky--and longer--than stealth wins and therefore score significantly higher. None of the tournament’s four stealth/speed wins even set a daily high.

Regarding wins, five players had won the game before the event, but only two competed so we didn’t end up with a lot of recorded wins, at least not by different players. Leader zzxc won five times (basically whenever he wanted to stealth run it =p); he’s also generously written a spoiler-filled guide about how to achieve such a victory here. In the week immediately following the Challenge we added three new stealth winners :).

As no players yet have complete knowledge of the game (those with more experience tend to specialize in certain areas), participants playing the most games naturally had a better opportunity to learn more and push up their best scores. You can see this below where the top half of players averaged 20 runs throughout the two-week Challenge:


Number of participants with best scores falling within the indicated range, showing also the average number of runs by each participant in that category. (*Excludes non-qualifying runs.)

At the other end, many of the players with few runs originally joined alpha to support development, but haven’t yet gotten much into it while they wait for 1.0, participating this time around just to be a part of the event (and perhaps in some cases for a chance to win a random prize). This group of players averaged only 1-5 runs, most of them of shorter length.

The final top 10 ended up being quite competitive, with many of the top participants repeatedly besting their own scores and leapfrogging up the board:


Cogmind Alpha Challenge 2015, Top 10 High Scores.

Let’s look at scores from another angle, based on depth reached:


Scores achieved by players who died at a given depth.

The red Max line represents combat runs, where the point rewards are greater (accompanied by a higher chance of death). Speed runs on the other hand always fall between the Avg and Min line. In fact, players automatically receive 500 points per depth after -10, so the Min line couldn’t get much lower than it is--subtracting 4,500 points (9*500) from that 8K run to the surface, minus the further 2K bonus for the win, leaves only ~1.5K points earned on the entire way up!

Good combat runs will beat out a speed win on points half way through the game, as soon as the difficulty starts to ramp up and the odds of survival go down quickly without superior adaptive tactics. That said, the dynamics of both combat and speed runs will change quite a bit between now and 1.0 when many new maps, routes, and options will have been added. Also, because the world will continue to get wider instead of deeper, depth alone will not be able to tell us as much about progress as it can now.

From the Max spike at -4, one can see that there is plenty of point potential even before reaching the late game, it’s just risky (that player had to have died on -4 to be recorded here, and looking at that record I see they apparently attracted way too much attention but didn’t go down easily and earned a ton of points for it). Farming for points is dangerous lest you suddenly lose valuable parts just before climbing to a new depth and start off in a new area in less than ideal condition.

Now it’s time for a little interesting combination analysis, taking multiple UI preferences and checking if there’s any correlation with score. (Okay, we’re not looking to calculate real correlation, just make a fun bar graph…)


Player input/map UI preference combinations.

First, notice that nearly half of players are using mouse input with the tileset, the most accessible way to play. By comparison, the smallest portion of players combine keyboard mode with tiles, which makes sense since anyone using pure keyboard controls is likely pretty hardcore, and many traditional roguelike players enjoy ASCII. (Of course, this entire graph is only so reliable because not all players have the full range of choices available to them. For example someone may want to go full keyboard but can’t because Cogmind doesn’t currently support alternative international layouts, or they may want to use tiles but their screen is small enough that they need ASCII in order to better parse the map.)

With regard to score, the assumption here would be that pure keyboard users in ASCII mode are the “most hardcore” and therefore more likely to achieve higher scores. This seems to be the case:


Comparing input/map UI preferences with averages of each participant’s best (highest) score.

Of course there will be exceptions--the #2 ranked player, for example, falls under the largest Mouse + Tiles category, and even if we remove our relative outlier zzxc (30,733 points), the KB + ASCII average is still 7.5K, or an average 31% higher than the other combinations (our second outlier doesn’t belong to the KB + ASCII average so the general shape holds true). All things said, as a display of averages this graph is pretty interesting!

While we’re on the subject, looking at records of all winning players including those outside the tournament, three use Mouse + Tiles, two use Mouse + ASCII, and two use KB + ASCII, so if we use winning as the primary metric rather than score, the UI preferences come closer to simply matching the preference distribution graph (3 : 2 : 2 | 48% : 20% : 20%). That sample size is too small to be meaningful, but it’s fun :D. The current distribution is also impacted by game age: Cogmind is quite young, and some long-time mouse players will eventually tend to transition to keyboard while seeking more efficient means of play, but they haven’t had long enough to do that yet.


Finally we get down to specific mechanics.

At the core of the game, and the player’s only choice in terms of permanent character development, is how many slots of each type to choose as you evolve. For experienced players looking at the end game these choices are likely driven by a long-term plan, but for others the decision might be influenced by the current situation at the end of a floor, including but not limited to what you happen to be carrying in your inventory =p.

In any case, by the half-way point it’s apparent that utility slots start to outnumber everything else. Power, propulsion, and weapons all have varying degrees of diminishing returns depending on your strategy, while utilities always remain the most flexible, capable of effects ranging from intel and defense to offensive augmentation. Given the mechanics, the optimum slot strategy will always be to evolve as few non-utility slots as you think you need, and pour everything else into utilities. (That doesn’t mean you might not overdo it at some point, wishing you had an extra power/propulsion/weapon slot instead of all those utilities.) You can see this play out in the graph below:


The fewest and most of each slot type on any build destroyed at a given depth (this only takes into account the highest-scoring runs for each player, so by definition it excludes many speed runs and narrows the visible ranges). (Click to view at full size.)

Power slots can vary greatly depending on how much energy your style requires (many of the best utilities are extremely power hungry). Space afforded to propulsion is largely dependent on your preferred form of movement. Similarly, weapon counts are going to be directly proportional to how confrontational you want to be.

A less permanent but equally important aspect of the game, dynamic inventory size (see the full design analysis) can tell us a lot about play style.

The most successful combat builds always end up using a good number of utility slots to expand inventory capacity, particularly suitable for that style of play. (Slow Cogminds getting caught in the wrong place without enough spare parts can, if unlucky, be picked apart pretty easily and end up stripping down to flee.)


Min/Avg/Max inventory size at each depth, where “Carried” refers to the average number of items held in inventory throughout the game to that point.

The red Max line again represents full combat builds, here carrying multiple Storage Units to have as many spare parts on hand as possible (for reference, a single High-Capacity unit holds 8 parts). The average run contains a more manageable 10-20 spaces (one or two units on top of the base inventory space, 4). And speed runs often get by on much lighter inventory.

Notice the low Carried values! Actually, note that in practice it’s likely a little bit higher than shown here for all depths except 0 because before death Cogminds are known to run around naked while frantically searching for an exit =p. I have noticed, however, that some players do run around with partially empty inventories during normal play, which is a really bad idea and generally unnecessary given all the scrap lying around.

At the high end, carrying 50 items at once is fairly insane and I admit not something I expected when first designing the inventory system. This strategy was pioneered by the first combat winners, though past a certain point you reduce your overall effectiveness by using up too much valuable utility space for storage. Some tweaks will eventually be necessary to put a cap on what is feasible. That and the current inventory UI was optimized for a size of 20 or so, with 10-12 items viewable at once and up to 20 conveniently reachable via sorting commands, so even larger inventories can be tedious to manage. (I have ideas for some adjustments there, if necessary.)


Most players do some amount of hacking. If anything a terminal is a source of potentially free information depending on what easier direct hacking targets are available.


Hacking data.

The per-machine data comes as no surprise:

  • Terminals (84.0% of all hacks) are by far the most common interactive machine, and offer the widest variety of functionality. I’m guessing most players who pass a terminal will generally tap into it to at least see what’s available.
  • Repair Stations (9.4%) are much less common, but make it possible to increase the longevity of vital parts, which is a valuable benefit when you’ve already found something you really want to keep. (Unless it came off a robot, or you can build your own, you’re unlikely to find one again!)
  • Scanalyzers (6.6%) are easy to hack so they do get some use, but based on Fabricator access data more than half of the resulting schematics obviously go to waste. I have a couple ideas to increase the usefulness of Scanalyzers, both alone and in combination with Fabricators.
  • Fabricators (3.6%) are rare enough that even players who want to use them may not have ample opportunity. The cost-benefit of building parts and robots is only worth it in special cases, though that was the purpose behind the system. Low usage rates can also be attributed to many players having still not learned how to build things.
  • Recycling Units (1.8%) aren’t so useful right now since there are better ways to collect matter. This machine will be getting a complete overhaul and become much more valuable later. I anticipate this percentage will rise significantly.

The number of hacks per unique machine seems reasonable. Terminal targets can be hacked with a single command each, but there are more options and terminals usually allow for about three hacks before being traced. Non-terminal machines require at least two hacks to accomplish something (this is because it would otherwise be too easy to bypass security by brute forcing the system over time); this ups the numbers on those machines. (Note this graph doesn’t account for machines that were intentionally skipped by the player, so it in no way reflects the relative popularity of a given machine type, which we already saw in the first graph.)

The Success (43.3%) vs. Failure (56.7%) graph doesn’t really tell us much since we don’t know the difficulty of the attempted hacks, except maybe that players generally stop hacking once they’ve been detected rather than risk a trace.


10 most successful hacks at terminals, out of a current total of 39.

Because the score sheet doesn’t currently tally target-specific failed hacking attempts, this graph is less useful to us for analyzing player behavior as it naturally prioritizes the most common and easiest hacks. What we can see is that players are using these hacks, and in what general ratios. To make the data more meaningful I’ve shown the base difficulty for each target type. For example, Emergency Access Points and Machine Controls both have the same difficulty (50% base chance), but the latter is obviously preferred by more than 2 to 1. (That’s interesting because I’m not sure how well players even understand the effect of sabotage via “Control(Machines),” which is not yet explained anywhere in game.)

Unreport Threat (i.e. “Alert(Purge)”) appears last among the top 10, though my impression is that it’s one of the most sought after targets and I suspect anyone who knows their hacking is also going after that one manually.

There are four other hacks with a 50% base chance to succeed which are not on this graph--Transport Status, Reinforcement Status, Terminal Index and Hauler Manifests--none of which are surprising since the first three aren’t as useful, while the last one is at most useful only once per floor, if that. Maintenance Status is the only high-chance hack (70%) that isn’t on the list but might be if everyone had the same understanding: There are so many maintenance bots running around that getting a snapshot of their locations works as a poor man’s map layout hack (a discovery made by early Cogmind strategist jimmijamjams).


As anyone who plays Cogmind becomes aware of before long, the world isn’t just a static place waiting for you to explore it and encounter inhabitants awaiting your arrival. (For more about this, read The Living Dungeon.) Based on the amount of negative “influence” you’re having on the surroundings, the central AI reacts to your presence with what it considers a proportional response in order to contain the damage. This acts as a sort of self-adjusting difficulty level (though handled in a realistic manner), by which players earning higher scores will come up against greater resistance.

The effect has been toned down somewhat since the earliest versions, to give players a fighting chance in the late game which used to be pretty overwhelming unless you spent all your time in stealth mode. Still, as you can see below it becomes increasingly difficult to keep your influence from rising later in the game:


Average peak influence over the history of runs ending at each depth.

That said, all the winning builds (arrived at depth 0) were apparently those which were able to keep their influence relatively low throughout the game. Even one of the two combat wins was close to the average value!

Influence directly translates to security level, which is what really determines the hostile response:


Average amount of time at each security level during all runs, showing also the longest duration (“Max”) reached during an individual run.

There are actually five security levels. A few players made it to #4, but the data was so insignificant that the percentage didn’t register by the end of two weeks, so here we’ve left out both 4 and (oh my you wouldn’t last long) 5. The highest level we’ve got in this graph is someone who apparently spent nearly a quarter (24%) of their game at level 3.

There was a time earlier in Alpha when it was easier to rack up influence with a small army at your side, and players who did that ended up in so much trouble once that army was gone. (The system is more realistic and appropriately balanced now.)

The vast majority of runs (74%) remained at Low Security; of course, as we’ll see further below 54% of runs didn’t make it out of Materials, i.e. the early game, where it’s not so easy to raise your security level very high. From the peak influence graph further above, you can see that after a relatively steady level of influence through Materials the true danger starts in Factory, where influence begins climbing rapidly. This is a side effect of both greater numbers of more dangerous enemies (including the appearance of Programmers) and longer stretches between map transitions (which are a way to lose some heat).


Total number of squads dispatched, divided by type.

The primary way in which the AI responds to the presence of Cogmind or other hostiles is to dispatch different types of squads depending upon the activity involved. I’m not going to go into detail here because doing so would be somewhat spoilery, but we can talk about the obvious outlier here, Assault squads. Assaults are only dispatched to deal with a significant threat, so even without hacking terminals to check the current security status you know you’re pissing off the AI when this happens. It usually doesn’t take more than a few such squads to squash Cogmind, so we don’t see as many of them because either they stopped a run, or the player was able to keep their influence low enough under the radar that they weren’t dispatched in the first place.


In Cogmind, if you’re not sneaking or running--or possibly hacking--you’re shooting. That means lots of projectiles flying around. Just how many? This many:


Every single shot fired during the tournament, all 206,227 of them :D

The four types of ranged damage each have their own properties, though in terms of player choice this graph must also be taken with a grain of salt because often times players equip themselves with parts salvaged from hostile robots, and robots are most likely to carry kinetic weapons, followed by some thermal, very little electromagnetic, and virtually no explosives.

Still, the general popularity of kinetic is likely above that of the other types, since it doesn’t generate much heat (thermal/EM) or require much matter (explosive). And of course some amount of choice is behind the data because 1) there are certainly plenty of weapon caches and 2) kinetic weapons are actually more rare than thermal weapons in terms of random finds. So there is meaning here, after all.

Just over half the shots fired were kinetic (52.9%), probably the easiest type to use. As the other major category, thermal accounts for nearly a third (28.0%), and could use an additional benefit or two (beyond the recently added offensive meltdown potential), because it is not usually worth simultaneously powering thermal weapons and a range of utilities. By comparison, better energy and heat balance contribute to the stable versatility of kinetic-based builds.

Electromagnetic (14.8%) weapons are somewhat more rare, and only available from a very small number of hostiles, which, combined with their lower damage and reliance on specific side-effects, means they don’t see much use. However, during the tournament it was confirmed that, where possible, complete reliance on EM in the late-game is OP. There will be a few tweaks to this damage type coming up.

Explosives (4.3%) are one of the most valuable and sought after weapons in the game, but at the same time we can see that most players learn pretty quickly to show restraint when they get one because the level of destruction and resource drain are enough to do anyone in. (There are stories of those who don’t show restraint--the path is glorious, but the ending ain’t pretty.)

Even assuming restraint, despite only 4.3% of shots being fired from an explosive weapon, an average of 28.7% of all damage inflicted was due to explosions:


About one-third of damage inflicted was from explosions.

The percentage of explosion damage remains fairly steady throughout the depths, with a few understandable exceptions:

  • As finding an explosive weapon isn’t absolutely guaranteed, players who died in the first couple depths were less likely to have had one, while those who did find one quite likely made it to -8 or -7. When used correctly an early Grenade Launcher is like an Advance to GO card, where GO is the Factory.
  • The low surface value (20%) comes from a majority of victories being stealth runs (i.e. where you don’t go blowing everything up).

In a more general sense, the relatively small 4.3% of shots doing 28.7% of the damage suggests that explosives were being effectively used against groups of hostiles (as one would expect). Certainly they’re more powerful than other weapons, but not nearly 6.7 times as powerful. Actually, from the data (and weapon stats) we can extrapolate that roughly 2.7 robots were hit per explosion.

On the same graph we can also examine the average total damage per depth, which doesn’t offer us anything particularly interesting except that jump at -3. In combination with that, notice that seven of the top ten players (as shown on the earlier high scores list) were stopped in -3, hence this is where they made their last stand against more difficult opponents (and more importantly in a more difficult environment) than in previous depths. An alternative way to read the same data (since we can’t be sure the damage wasn’t inflicted before arriving in -3) is that only players who were more capable of dealing significant damage were able to even reach -3.

So how effective was all this shooting…


Cumulative average combat robot kill counts during runs ending at each depth (e.g. players destroyed on -4 had on average destroyed about 80 combat robots). Graph includes only the most common combat robot classes.

In terms of total kills, the trend is gradual and clear. Aw yeah.

The noticeable spike at the end is because 1) by then the player can be armed with what are currently the most powerful weapons in the game, which outclass anything the enemy can throw at you there (trust me, they’re holding the fearsome stuff in reserve for more important locations and events to come :P) and 2) players prepared to exit -1 have free reign to use surplus resources to first attract attention and take down as many hostiles as possible before leaving.


  • Grunts and Swarmers are the most common patrol robot, and travel in groups, so they are naturally the most common kill. Duelists and Brawlers are occasionally found accompanying Grunts, and not so often as part of regular patrols, so their numbers are fairly small.
  • Sentries guard important intersections so taking some of them out is inevitable, but they always work solo (and can be circumvented), so again fairly small numbers there.
  • Programmers don’t start appearing until -7, after which both they and Hunters gradually increase in number.

How do those numbers compare to robots minding their own business:


Cumulative average non-combat robot kill counts during runs ending at each depth (e.g. players destroyed on -2 had on average destroyed about 40 non-combat robots). Graph includes only the most common non-combat robot classes.

The total number of non-combat robot kills flattens out through the latter third of the game presumably because you don’t have the luxury of taking them out while worrying about the then much deadlier foes patrolling the corridors of Research and beyond. They also don’t provide much in the way of useful salvage by this point--if you’re looting Wheels or Light Ion Engines there is a good chance you’re soon to be scrap (unless you can remain minimally effective just long enough to locate a real cache).


  • Despite being unarmed, Recyclers are public enemy #1 since they ruthlessly spirit away your hard-earned loot. If some players weren’t already using warning shot tactics to shoo them away, these would certainly also enjoy the top kill spot. Already two pieces of fan art have surfaced about Recyclers (1, 2), together with countless mentions among players in other capacities. They’re (in)famous!
  • Haulers are “the piñatas of Cogmind,” though not as plentiful as the other types, so their ratio looks about right.
  • Tunnelers are not necessarily the safest of the bunch--they do tend to stay out of the way, but there are also fewer of them to begin with. They’re likely destroyed only when in the way.
  • Builders are frequently caught in crossfires as they work to repair combat zones.
  • Workers are the most abundant robot, and also roam about fairly slowly, so they are more likely to become an obstacle in a narrow corridor and warrant a shot in the back, as well as be in the wrong place at the wrong time and get blasted by stray shots. Their greater numbers also mean they’re the most readily available target when low on matter or you need a quick power source. I’m not entirely sure where the Worker death spike came from for the last bar, but there are only two players who contributed to that data segment, so it has to do with their particular style (blow the crap out of everything)--it’s also not as huge a difference as it appears, only an extra five or so Workers destroyed.

In short: players hate Recyclers, Haulers are piñatas, Tunnelers are few, Builders get in the way, and Workers are everywhere.

Comparing the previous two graphs, aside from the last couple depths players generally destroyed twice as many combat robots as non-combat robots.

Lots of robots were destroyed, but then most Cogminds didn’t make it out alive, either…


Many Cogminds were harmed in the making of these stats.

First see that beautiful curve on the right. It’d be really interesting to compare what it looks like after some time with the same set of players--I’ve no doubt the peak would gradually begin to shift upward, but for the duration of the tournament it makes sense as seen here since the overall community experience level was relatively low.

The low death count at -10 can be attributed to most deaths on the first floor not earning enough points to qualify for inclusion. However, without the point boost from evolution those 33 Cogminds that were included must have caused quite a stir.

The steep drop from -9 to -8 occurred because anyone with the ability to beat -9 won’t likely have too much trouble with -8. Similarly, the drop from -6 to -5 is players experienced with the early Factory floors being fairly successful in the Factory at large. Further up, many players who reached the late game had trouble facing down the gateway that is -3, as it’s another jump in difficulty from the Factory.

Overall, 54.2% of deaths occurred in the early game (-10/-9/-8), 38.0% in mid game (-7/-6/-5/-4), and 7.8% in late game (-3/-2/-1).

Another factor contributing to higher death counts in the early game are the branches, which only exist at that point and keep players at a given depth for longer. (Mid/late-game branches have yet to be added, so the same effect could come into play for them later.) This is reflected in the left graph, where you’ll see that a combined 105 players (16.9%) died in Mines and Storage (early branches).

How did players fare before death:


Warning: Graph is pretty meaningless.

The above graph, showing approximately how much core integrity Cogmind had left on each floor that was survived, is heavily impacted by the lack of historical run data, as the only way to get these values is to calculate backwards from the point of death and average the remaining integrity out over all previous depths. It would be far more meaningful to look at data from individual runs, especially if we stored the necessary values explicitly (plotting that data from all players as overlapping line graphs would be pretty awesome).

But perhaps there is meaning in at least explaining why this graph doesn’t tell us much.

From an individual run’s point of view, as an average it smooths out factors like a lucky exit find that let Cogmind advance relatively unscathed, or the all too common narrow escapes. I’ve made it to an access point with less than 0.1% of integrity remaining, and heard stories of others doing the same. It’s intense.

By averaging all runs together, it also merges the very different data resulting from play styles on complete opposite sides of the spectrum. Combat builds are much more likely to reach an exit with less than half their integrity (remember that in Cogmind core integrity damage is irreparable--you must ascend to the next depth to evolve), while stealth/speed runs don’t have much trouble ascending with 80-90% (it’s an all-or-nothing approach)

Maybe in its current form this data would be somewhat more telling if, again, we compare it to the same set of players later on. At least we could look to see if the 60-70% range has shifted towards 100% with improved skill. The shift would be a slow one, since it’s inevitable that combat builds will lose a portion of their integrity to attrition. The addition of more branches at each depth will also shift the range back towards 0%. That will be something to watch closely :)

Among the factors contributing to death irrespective of core integrity:


Corruption goes up and up and up… mostly.

System corruption is one of the game’s food clocks (described in more detail in The Importance of Roguelike Food Clocks). A lack of core repair is the other, which plays a bigger role while Cogmind is weaker in the first half of the game. Corruption doesn’t take over as a serious threat until Programmers start showing up in -7 (see the 400% jump from -8). After that it’s a gradual rise as Programmers become more common and carry more powerful EM weapons, then it plateaus for the late-game stretch. The spike at -2 is players new to the late game getting in over their heads and dying as they get deeper into Research (-2 is probably the most difficult floor in the current version, by the way).

As with other data, there is a large difference between play styles, and these values lie somewhere in the middle ground. By the end of the game, combat builds can peak at 30%+ corruption, while stealth runs can race through the entire game close to zero (they don’t need a food clock--for them the real danger is getting caught in a trap, or chased down by Swarmers, and picked to pieces).

Worth noting, before encountering Programmers (in Materials), those low corruption records are either someone not being careful with their EMP Blaster (self-inflicted corruption), or hanging out too close to an exploding Neutrino Reactor. Don’t do that.


Putting this together (both the event and the statistics) was a ridiculous amount of work so it’s not going to happen again anytime soon. That said, at least the groundwork has been laid to reduce the effort required to simply look at and compare data--the game can now output all these graphs for me :). Later on where tweaks are made we can reload some of these same graphs with data from future versions and see what has changed.

Thanks again to everyone who participated!

Posted in Meta | Tagged , , , , , | 8 Responses


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 Gamedev | 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