Official development blog

Tutorials and Help: Easing Players into the Game

With a generally lower barrier to add content compared to other games, roguelikes have a tendency to be packed with features and mechanics, and while that doesn’t characterize every roguelike out there (notably 7DRLs and other quick hobby projects), there is an important need to help new players overcome the initial barriers to learning a new roguelike. At least if we want those new players to stick around long enough to learn what’s so fun about it :)

Many roguelikes do borrow a portion of their paradigms from prior games in the genre, be they common keyboard commands or ASCII meanings, and that helps lessen the burden to some degree, but there will always be plenty more to learn. So the question is how do we teach it?

Traditionally roguelikes would come with an explanatory text file, and probably a ‘?’ page/window in the game itself, but little to nothing else. Even today some roguelikes still leave it at that. But game design has evolved quite a lot since the early days of roguelikes, and players are familiar with (and often come to expect) many more help-oriented systems, so we’re seeing an increasing number of roguelikes that incorporate them, especially after migrating away from terminal displays and grid-based, ASCII-only graphics.

Some players are more forgiving than others, and will slog through a slow and difficult learning process in the hope there is an interesting and fun game on the other side, but with easy access to a large and growing selection of games these days, player attention spans and willingness for punishment have declined significantly. To reach the most potential fans possible, new roguelikes need lower barriers to entry so that those who might enjoy the game--but not learning it--make it through that first stage.

That was my starting point for designing Cogmind’s help-oriented features, and here I’ll be discussing the most important ones.


First off, the easiest way to help a player is to make it so they don’t actually need help in the first place :P. Obviously that won’t work for all cases, but as a principle should be applied anywhere feasible. This is most easily applied to input, making important actions easy, intuitive, and accessible based on what players expect: Click on self to open status window. / Click somewhere to move there. / Click on an enemy to aim (shows a targeting line), click again to fire. / Right-click on an object for more information. / Drag item from the inventory to equipment list to attach them. / Drag them from the HUD to the map to drop them… Notice the common theme here is that these all involve the mouse. Full mouse support is a must for accessibility. Players can transition to partial or full keyboard use with time, once they have a grasp of the new mechanics and other components to learn. Why force them to learn everything at once if they don’t want to?


Drag-drop example.

For players who do eventually learn to use only the keyboard (or do it right off), which right now is 26% of Cogmind players, because the mechanics don’t have much overlap with other roguelikes there isn’t a whole lot of existing experience to invoke there. In fact, I can list them all here easily: ‘?’ for help, numpad/hjkl/arrows for movement, ‘f’ for fire, and ‘.’ for wait. That’s it. The rest are unique, and there are a ton of them, but in most cases there is a pattern, or they start with the letter of what they represent, which aids the learning process.

To teach any commands that the player hasn’t figured out on their own there are two separate ‘?’ pages, one for beginners and one for experts. This is to avoid overwhelming new players with a page full of commands they won’t need right away anyway (or at all if they’re using just the mouse); instead the basic commands page provides the minimum amount of commands and information a mouse user needs to use and understand the entire interface. By comparison the advanced commands page is packed with every command in the game, including duplicates (some actions are possible via multiple different keys).


Basic commands.



Advanced commands.

Also notice that window-specific commands are displayed in their relative windows, and certain parts of the interface (for example the top-right HUD area) have descriptions explaining each piece of data.

But input is generally the lesser fraction of what a player has to learn. Mechanics are the bigger issue!


Some mechanics can and will be understood naturally through regular play, but even in these cases it’s possible to speed up the learning process, not to mention the need to teach other mechanics and stats might be too opaque or unclear without additional explanation.

The old go-to in that case would be the manual. Cogmind includes a text manual that fully explains all mechanics and UI features, weighing in at 8,000 words. But to make it easier to reference and put it where players are most likely to need it, the manual can be opened within the game itself in an interactive form.


In-game manual example.

Manuals are good when players have a lot of free time and would just like to browse or even thoroughly read through the manual for information they might not already know, and if the topics are arranged sensibly they can also make it easy to seek out information on a given topic in order to answer a specific question. But honestly specific questions are best handled at the point where they’re asked, and that means context help.

In Cogmind this is how the stats are handled, because the status page, robot info page, and item info page are all a combination of data and graphs, the meanings or implications of which won’t always be obvious to the player, and making them search through the manual each time they need to learn something is a terrible and frustrating requirement. So simply clicking on any stat provides an explanation (or for non-mouse users, pressing Up/Down and hitting Enter on an entry).


Context help example.

In general the way to head off player uncertainty is to ensure that obtaining information is as intuitive, automatic, or direct as possible. Thus another way the UI works to help the player:


Automated map labels, which help players learn the ASCII (or the ASCII-like minimalist tiles) for objects, and even if they forget them, labels are still always available to speed up the recognition process!


The player’s first contact with the interface and mechanics is of course extremely important, so many games these days start out with a tutorial (or at least make it optional and recommend it). I was originally loath to provide a tutorial at all, because I didn’t want to include immersion-breaking elements (like there’s no main/start menu), especially not right at the beginning. But from an audience-building perspective that would be a massive mistake.

So eventually I came up with an “immersive tutorial” that teaches the basics by introducing them step by step in a few short connected rooms. And these rooms are a plausible place for the game to start, so it doesn’t feel out of place.

The tutorial map, basically an alternative version of the first floor of the game that leads normally into the rest of the game, is only shown three times for each player, the first three times they play. I decided to have it repeat more than once so a new player isn’t suddenly thrown into a new and unfamiliar starting area the second time they play (this being a roguelike, the “second run” will probably come pretty quickly :P).

Also, it’s a very short tutorial anyway, and the second and third time through it doesn’t even include the tutorial messages, so it loses even that little bit of tutorial feel. “Tutorial messages” appear in the message log, hot pink and blinking and with a special beep, and still people sometimes miss them after the first few as they’re eager to explore. Oh well.

While the better alternative, modal tutorial messages, are great for forcing players to pay attention, they’re very intrusive and really ruin the immersion I’m trying to create, so I decided against that approach pretty quickly. (It’s a bit of design conflict between accessibility and the theme, which honestly plays out in many more areas than just this one, and is really annoying :P)

Anyway, each tutorial message is only shown once, and most of the important ones are context-triggered, for example telling you to drag-drop an item you just picked up in order to equip it, and they work in tandem with the tutorial map based on how it’s laid out.

A lot of thought went into the layout of the tutorial map which, unlike much of the rest of the procedurally generated world, is completely static. It’s only four rooms total, and the idea is that the player encounters elements in a very specific order, without simultaneously seeing other elements that would distract them from what it is they’re supposed to be learning at that time (despite how small the area is).


Tutorial map layout with explanation (click for full size).

In those four rooms the player learns pretty much everything they need to have a good time, which is the best way to start any roguelike :D. Sure there is plenty more to learn, but that can all come with time. Also, for comparison check out the regular non-tutorial start area:


Standard Cogmind starting area. There are only two rooms, where the player starts with more options for gear--all in the immediate vicinity--and then can head over to the next room and leave right away.

Independent of the tutorial map, later in the game as new elements are encountered, there are some tutorial messages to explain features that might be incredibly important but not necessarily obvious--for example bumping into machine control panels to interact with them. At various timed points there are also other more general non-context reminders, telling the player about the manual, or how to save and exit, etc.


Turn counts on which time-based tutorial messages are shown.


Sometimes players like to seek help outside the game, and that’s where having a community comes in handy.

Letting individual groups of players spring up in their own forum threads wherever they may be is nice, and that will happen regardless, but it’s still worth having dedicated forums these days, so I did that and love the community interaction it brings. When players ask questions in a public forum dedicated to a single game, the answer can in turn help anyone else who comes looking for similar help.

I set up /r/Cogmind for a similar purpose, but Reddit is a pretty terrible format for a long-term community that can benefit from preservation of information and more convenient search functionality, so it’s more of a communication channel than a great source of help.

In either case, though, communities have advantage of providing a type of help that isn’t usually provided by the game: strategies. This is something a manual won’t cover, and while in Cogmind there are NPCs who give tips for survival, that can only cover a small portion of the potential useful advice… So player guides are another valuable form of third-party help :)

Many roguelikes of significant size and following also end up with a wiki. In my case rather than wait for someone to create one on some free site with ads and that we don’t have as much control over, shortly after releasing I set one up on my site. It’s almost entirely run by players.

Hopefully all these features (and who knows maybe more to come?) will be enough when Cogmind reaches the hands of even more players in the future!

Posted in Design | Tagged , , , | 5 Responses

Roguelike Celebration--See you in San Francisco?

I’ve always wanted to go to an IRDC (International Roguelike Developers Conference), but they’ve always been in Europe, not easy for me to reach from way out here in East Asia. More recently IRDC has also made its way into the US, but always out on the East Coast, so still not quite within my means.

Then I noticed a number of other developers signing on to this “Roguelike Celebration” event being hosted by genre enthusiasts Noah, Britta, and Asheesh in San Francisco for a day of activities aimed at both players and developers. My brother happens to live right down the road from the venue, only about 10 hours by plane from me, and I figured this is the best opportunity I could hope for short of hosting an event myself, so San Francisco it is! :D

I’ll not only get to meet some Cogmind players who I already know will be there (maybe you, too?), but also a number of other developers, several of which I’ve known only online for some time now.

And I’m not just going as a spectator--I’ll be giving a talk alongside a great cast of other speakers, including devs from Dwarf Fortress, DCSS, Brogue, Caves of Qud, and… the original Rogue :P

You can see the complete list of speakers and topics here.

I haven’t prepared my own talk yet, but I did settle on a topic, which is kind of a summary of the entirety of Cogmind development: “Taking Traditional Roguelikes Mainstream.” So I’ll be explaining a wide range of design elements across the interface, presentation, sound design, and more that work to broaden Cogmind’s appeal beyond the core roguelike audience.

I hope you’re interested, and I hope to see you there! If you can make it, I suggest getting a ticket as soon as possible, because the price will be reportedly be going up after this Wednesday (7/20). (The cost is just to cover event expenses.)


Come celebrate with us!

Posted in Meta | Tagged , , | 2 Responses

Inventory Management, Revisited

Few roguelikes are without some kind of inventory system, as it’s a familiar and flexible way to provide access to the tools a player uses to overcome challenges. Regardless of however many items an inventory might contain--2, 26, 52, or something else--how it interacts with the rest of the mechanics, as well as how the player interacts with the system itself, both play important roles in shaping the player’s experience.

With Cogmind in particular, there is a huge amount of inventory management involved in regular play. By comparison, with many roguelikes you settle into a set of equipment that only changes when you find some better individual item, rather than when that equipment has simply been damaged too many times, or an enemy suddenly gets a lucky critical hit that destroys one. In Cogmind all attached items essentially act as physical shields that protect you to varying degrees, and they can all be destroyed. According to the combined stats of reported runs from the previous version (Alpha 8), 43.5% of all items players equipped were destroyed before being removed or replaced. That’s a surprisingly high number for a roguelike, but is of course something the player expects and can prepare for. (Note that for the purposes of this topic, “inventory” also includes “equipment in use,” thus bringing the number and types of slots into play. These concepts are essentially inseparable with regard to the management aspect.)

Back in 2014 during pre-alpha development I wrote an article on Inventory Management (hence this title’s “Revisited”), that one explaining the purpose of inventory and the ideas behind dynamic inventory size and decision forcing. Since then however, there have been a few changes, and certainly an expansion on the interface side of things, altogether enough to warrant another more in-depth look.


From a UI perspective, with Cogmind an important goal of the inventory system was to make interacting with it as simple as possible. As one would expect with a system marked by high turnover, there’s a lot of item removal, equipping, and swapping to be done, and the UI had to be designed to facilitate that.

With such a variable inventory state and the relevant actions being quite frequent, priority #1 is to keep the number of required commands down. The first step towards achieving that goal is to ensure both the inventory and equipment are visible on the main GUI, thus they occupy a non-insignificant 29% of the screen space at all times.


The base 4:3 layout for the main interface, with dedicated inventory/equipment areas highlighted. Even the 16:9 layout is 24% inventory.

Without the need to open a separate menu for inventory actions, the number of commands is already cut in half--a minimal OPEN > SELECT > EQUIP > CLOSE becomes SELECT > EQUIP! But there are many ways to do even better than that.

On the mouse side, Cogmind supports drag-and-drop inventory management, allowing mouse-using players to just drag items where they want them to go. This is the most intuitive method of item manipulation for beginners, helping keep the barrier to entry low.


Drag-drop inventory management example.

The dragging doesn’t even have to be to a specific location--items will automatically be equipped to the first applicable slot, or if there is no room then dragging to a specific target allows it to be swapped. Drag to the inventory to unequip, drag to the map to drop… Also for mouse users, ctrl-clicking an object on the map bypasses the inventory completely and equips it.

But playing with the mouse isn’t necessary, and pure keyboard players have access to a number of extremely convenient features as well. In addition to single-command equipping (Ctrl-#), single-command unequipping (Alt+Letter), and single-command dropping (Alt-#), items can be equipped directly from the ground with the ‘a’ key, in which case if there isn’t any free space they will intelligently replace a current item that is outright inferior, and if the replaced item is better than something in the inventory, it will be stored and the worst item will be dropped instead. (The same system applies to equipping items from the inventory, and picking up items from the ground (‘g’)--all of them use the same automated system.)


Cogmind smart inventory explanation.



Keyboard-driven example, just moving around pressing ‘a’ to automatically replace parts.

Here it’s worth mentioning a helpful aspect of Cogmind’s design contributing to inventory management’s simplicity: only one item may be present on the ground at a given location. So when you go to pick something up there is no need to specify what it is you want! Very handy. (This same feature aids rapid assessment of what items are nearby, compared to some other tactical grid-based games in which you may be faced with stacks of items, requiring a more indirect way of seeing what they are and therefore adding an extra layer of abstraction between player and items.)


So how many items are we working with here? Cogmind only has four types of equipment slots--power, propulsion, utility, weapons--and starts with seven slots divided evenly among them (only one for power). That slot count, which equates to the number of items that can be in simultaneous use, gradually increases to 26 (that number oh-so-common in roguelikes for obvious reasons :P). Using a common humanoid system as a comparison, that’s like having a character with several heads and bodies, a couple amulets, all 10 ring fingers, and numerous arms and legs. Cogmind’s pure inventory, on the other hand, is rather small compared to most roguelikes, with a base size of only four, though that size is flexible depending on the player’s strategy. It can increase to 20~30 or even more if the player is willing and capable of devoting enough of their slots to storage space. The average peak inventory size of all reported runs in Alpha 8 was 8.78 items, though an average of only 5.03 items were carried at any given time (wasteful!). (The first post about inventory management talks more about flexible inventory sizes.)

The trade off is that extra storage is heavy and slows you down, so the tankier the build, the more likely it can maintain a larger inventory capacity (and will also probably need one due to increased combat attrition as a slower mover).

For balance purposes, back in Alpha 6 I did remove the largest inventory expansion module, Hcp. Storage Units (+8), otherwise we’d likely be seeing a higher average capacity. Now the heaviest single-slot inventory boosting item gives an extra six slots. Some players like to stack two or even three of those to get an inventory size of 16 or 22. The largest recorded inventory capacity in Alpha 8 contained 28 slots.

Still, a large inventory is not always necessary, and a game can be won simply on the back of the versatility afforded by a couple dozen pieces of active equipment. That and with the removal of Hcp. (“high-capacity”) storage, it’s a little easier to reach the point where the slot cost of maintaining a given inventory size reduces a build’s overall effectiveness (because storage doesn’t do anything but hold spare parts :D).

About slots: Most items only occupy a single slot, to facilitate swapping and avoid unnecessary complexity (in terms of design, implementation, and most importantly on the player’s end), but some less common special-purpose items might occupy multiple slots at once (usually just two, though there are a few items even larger than that). I added that feature (which didn’t exist in the first prototype) as a way to enable another type of “cost” that could be traded for some benefit.

More UI!

An important consideration when you have so much in the way of items/equipment to manage is ways to organize and compare them. To that end, there is a feature that sorts attached items by subtype so that same and similar items can be grouped together, quite useful when you have a couple dozen pieces of equipment divided into only four slot types.


Equipment sorting in action.

The inventory can also be forward- and reverse-sorted by mass, type, and integrity (all three accessible by both keyboard and mouse).


Inventory sorting in action.

In terms of additional information, the space out to the right of items is used to show stat visualizations, of which there are currently six:


Cycling through item data visualizations: Coverage, Details, Integrity, Energy, Heat, Mass. A seventh will be added soon, and we’ve recently been discussing the possibility of adding yet more alternative graphs to suit other player preferences.

Frequent swapping of items (of which there are quite a few) is also made easier by side-by-side comparisons that highlight any differences.


Item stat comparisons.


Stat comparison in action.

All these features combine to support the inventory management aspect of the game, and players of course really like it when whatever they want or need to do is easy.

The primary remaining imperfect aspect of the inventory management system is dealing with very large inventories, because the inventory displays no more than 12 items at a time, of which you can only interact with 10 (since the two at each end are themselves scroll buttons).

At one point on the forums we were talking about a special “inventory management” mode that could involve a temporary window displaying the full inventory contents and make it easier to do multiple inventory actions in a row. Maybe something like this:


Mockup: An open full-size inventory window.

But since then, with somewhat smaller inventory sizes (no Hcp.) and a large number of convenience features (above), I’m pretty sure this is no longer an issue worth introducing another major interface feature for. Also, as of Alpha 6 processors and hackware can no longer be repeatedly swapped out, which was the primary cause behind a frustrating amount of inventory shuffling for optimal play, so it looks like the issue has solved itself through other evolutions in the game.

Still, every time it seems like some part of the interface is done, another way to improve it pops up for some reason or another, so I’m sure we’ll be seeing yet more in terms of inventory management features :D

Posted in Design | Tagged , , | Leave a comment

Iterative UI Design

Today I’d like to share the process behind the development of a singular UI feature, in particular the part (equipment)-sorting implementation, which is a good example of taking a simple premise and working it one step at a time, examining the results of each new element added throughout the process until as a whole it satisfied (and even exceeded) expectations.

The Issue

Inventory turnover is quite frequent in Cogmind (more on that here), and the result is almost inevitably a cluttered list of equipment in the HUD, especially later in the game when you can equip a couple dozen different parts, and especially with utilities, the most versatile category of parts capable of a wide range of functionality.


A cluttered list of parts.

While playing I’ve found myself sometimes having to take time out to reorganize that list, grouping multiple parts with complementary effects like heat sinks, hackware, or other processors to better understand my build at a given time. And I know that some other players do this as well, as having a list of equipment that’s easier to parse facilitates rapid decision-making and avoids otherwise unnecessary mistakes.

So what we needed was a way to quickly and automatically group identical parts, or parts with similar functionality.

Initial Work

With interfaces there’s of course the important question of how to present this feature to the player, but in this case I didn’t start there, having only a vague idea of how best to do that. Instead, it made more sense to start with something more fundamental--without regard for appearances, the first step was to simply make sure the sorting algorithm itself worked, and just display the final result.

In game development, piling on too many features at once, even just multiple facets of a single feature, unnecessarily increases the complexity of the task. Everything should be broken down into the smallest understandable pieces so that any bumps along the way can be smoothed without too much confusion as to where the problem might lie.

Where the sorting is concerned, nothing special is going on, it simply reorganizes items by moving all empty slots to the end of their own category, while the items are listed in ascending order determined by comparing each item’s internal database ID number.


Stage 1: Sort and instantly move parts to their new location.

As expected, that didn’t quite work so well the first few times I tried it--bugs here and there, crashing immediately the first time I tried to use it (this is common :P), and on subsequent attempts doing odd things like stacking a bunch of items on top of each other, or erasing them completely -_-

All issues were resolved quickly, though, because the code was unburdened by whatever else I’d end up doing later to improve it for the final iteration.


It’s no secret that I like to animate everything I can, so it’s never a question of if, but how. Animations not only have a lot of potential cool factor, but when done right can also provide good visual feedback for an action or command.

For the sorting I decided to start out with something really simple, which would likely not be good enough for a permanent solution but required the same code along the path towards where I felt like I wanted to head, anyway. Basically the idea is rather than “teleporting,” items should somehow actually move, so I started with just having them slide directly from their current slot to their destination.


Stage 2: Slide vertically to post-sort position.

To accomplish this, I repositioned entire subconsoles themselves as part of the animation, which is an approach I’ve actually never used anywhere else in the interface, though is something I’ve been looking forward to doing for a long time. (For a detailed look at what I mean by “subconsoles,” see this piece I wrote on Cogmind’s UI implementation.)

The result is better than nothing, but with all the items shifting over one another it’s really hard to tell what is and isn’t moving, so the animation doesn’t add anything of value to the process.

A better way to make it more obvious what is moving is to shift them along more than one axis, i.e. offset them a little to one side.


Stage 3: Slide along an arc to the destination.

At the above stage I also wanted to try and convey some information in the amount of offset, specifically that items moving further from their previous position would travel along a wider arc, like so:


Arc sorting path visualization example (not actual sort targets).

But the effect was a little too messy for my tastes, especially since the coarse grid resolution of a strict terminal interface doesn’t leave any room for gradual pixel offsets (a rule I’ll not break in Cogmind for any reason). Items are either barely offset, or offset quite a bit.

Note: I originally thought I’d have some of them, perhaps the empty slots, offset to the right while everything else moved along the left side,  but assumed that would reintroduce too much chaos.

Seeing as the distance-based variable offset was causing a problem, I just removed the variability, setting them all to use a static animation offset whether they were moving to an adjacent slot or to a position ten slots away. At this point I also changed the movement path from an arc to a straight up rectangle to make it easier for the eye to follow given the grid.


Rect sorting path visualization example (not actual sort targets).



Stage 4: Slide along a rectangle to the destination.

With the desired movement path more or less determined, I saw that when many items were moving at once, while you could sorta tell which they were, it would be far more helpful if the movements were easier to follow, and the first way to tackle that is to simply not do them all at once!

Thus each item is “staggered,” beginning its movement animation at a random time within an acceptable range from when the command is entered (in this case 0~700ms). Each item takes 300ms to reach its destination, regardless of the distance, so the entire animation will take no longer than 1 second, regardless of the number of items involved.

In addition to the staggering, it was also time for some cosmetic enhancements to moving items in order to further improve readability. Two such effects were added:

  • Any item that will/is/was moving will have its reference letter repeatedly replaced with a random one for the entire duration of the sort. The letter is going to change anyway (because it’s moving to another position in the alphabetical list), so rather than just have it suddenly change, why not spruce it up with a little something? This also works well in combination with the staggering, since any given sorted item is only moving about one-third of the time during the sort, but even while it’s not moving you’ll be able to identify which those are.
  • On arriving at its final position, an item will flash white and fade back to its original colors, a process that takes 400ms. The flash reinforces which items just moved, and just plain looks cool. To me this plus the staggering really makes the whole effect :D

Stage 5 (final): Staggered sliding with randomized letters, and white flash on arrival.

Oh yeah, and there’s a little beep each time an item reaches its destination :D

From inception to its final form, this process took approximately four hours.


Other considerations encountered during implementation:

  • Item order doesn’t normally hold any meaning, except with weapons, which when active will fire in the order listed. For strategic reasons some players may prefer that certain weapons to fire first, so in that case it was necessary to add an option to ignore them for sorting purposes. Sorting was primarily meant for utilities, anyway, and to a lesser extent propulsion. I do a lot of weapon toggling myself, but don’t really care about their firing order, so I’ll be happy to sort them with this new feature :)
  • Further improvements could maybe include the option for fully automated sorting which operates immediately when a part is attached, so the player never even has to use a command to do it manually. Less impressive than seeing a bunch of items being sorted together, though :P
  • The current system doesn’t yet take into account integrity differences between items with identical ID numbers (this is obvious with the Exp. Heat Sinks in the final sample, as they reverse positions twice), so there is still room for better consistency and other sorting improvements.
Posted in GUI | Tagged , , , | Leave a comment

Cogmind, 1 Year of Alphas

Cogmind Alpha Access is one year old! (One could optionally end this sentence with “!?!?”)

“Year 1″ since release in May 2015 overlaps with some previous postmortems I’ve done, so rather than rehash that content here I’ll just be linking to it where appropriate. That said, there is plenty of fresh data to share, too :)

The Year 2 of the Cogmind recap is a pretty good general summary of 2015, something I’ll do again at the end of this year. Since then a lot of the work has gone towards overhauling a few mechanics to improve gameplay, and adding more and more content to complete the full world as planned. So, yeah, eight major releases later Cogmind development is still rolling along.

Today though I’d like to focus more on sales and other aspects specific to the alpha which haven’t been covered as much before.

Also, this week I’ll be updating the Cogmind website‘s text and all screenshots. Here are some of the scenes I’ve been working with for the new site:


Composite gif featuring gratuitous ASCII destruction.


Still of that reactor array exploding. (Click here for separate full-view image.)

On to the data…


As of today Cogmind has 2,119 players. Or maybe that’s “players,” because in reality the majority would be better classified as supporters at the moment, i.e. those who joined the alpha program to help the project see 1.0, and maybe try it out every so often before then, or just wait.

There are also an additional 738 people on a special one-time mailing list accessible at the top-right of the buy page, to be notified when Cogmind reaches its intended lower base price (for those who can’t afford to chip in now, or who simply want a lower price for whatever reason). Of course, a number of those people may have signed up earlier and eventually bought anyway, and another portion will never see an email because it’ll end up in their spam box :P

In terms of active players, based on the uploaded game stats there are usually about 20 runs played per day, though that number has fallen in recent months as sales have started to decline somewhat, something you’ll see further down. However, the caveat there is that I don’t actually know everyone who’s playing, only those who opt in to data uploading via the options menu (I do know that not everyone opts in). The active player count is naturally above average in the week after a new release.

Many thanks to the core group of players who have been a continuous help when it comes to providing feedback on each release--zxc, Happylisk, Decker, Sherlockkat, Shobalk, and more have stuck with it for a long time and have helped improve the game for everyone. Even others who simply talk about their experiences give me a lot to go on when I consider balance and potential features, revealing any disparities between the intended vs. perceived vs. actual effects of any changes.


I’m not broke yet!

If you’d like detailed coverage of the first month of sales and other data and issues surrounding launch, you can read my in-depth postmortem here. Crazy and exciting times, that first month :D

But that was only a month, and there have been eleven more since then :P

On the funding side those eleven months have been noticeably less exciting, though there were a few unexpected sales spikes in the first few months after launch. Unexpected because I haven’t been doing any advertising, but I did write that first postmortem which apparently got some traction, and Cogmind has also occasionally been picked up by news and review sites.


Cogmind Year 1 gross revenue, annotated.

Each new alpha release naturally tends to give a slight boost to sales simply because news gets posted around, so there’s the obvious incentive to get new releases out there, but at the same time I want each one to be truly significant, so it’s a balancing act to work on a major version as long as possible before it really needs to be released.

Still, the ongoing sales numbers are so small compared to the initial release (lots of people were waiting for that…) that the alpha release effect isn’t so apparent above. Looking at a monthly revenue chart will explain a little more about the long-term cycle


Cogmind Year 1 gross revenue by month.

The first 3-4 months were all about the initial wave of attention based largely on pent up interest, so they don’t really count. Then revenue started settling into a long, slow trend downward. I believe in the bigger picture November was a pre-holiday slump, since I don’t have any Cogmind-specific details to explain why that was the lowest month. I can say that sales and releases of other games don’t seem to have any real impact on Cogmind sales, likely because Cogmind’s numbers are so small to begin with (really, a couple sales per day makes that day for me :D), plus it’s a unique game.

February I can explain, though. That was a release leap month, when I was working on a big alpha update laying the foundation for the development of a whole new and very different part of the world, so it took extra long and there were the usual news updates but no releases during that period. The effect was also likely amplified by a post-holiday slump, especially after a fairly successful December and January.

Ever since February I’ve started expecting that revenue could truly flatline at any time, but that has yet to play out (whew!). This May is turning out to be another February-like month, though, so it’s increasingly important that I start looking forward. More on that later.

For fun, here’s the revenue by country for the corresponding period.


Cogmind Year 1 gross revenue by country.

Nothing surprising there, given that Cogmind is only available in English. There are dozens more countries on the list below that, among them my own--Taiwan, where currently there are only two supporters (no, I don’t know them!).

So in short, Cogmind has grossed US$ 62k in its first year. That sounds like a lot, but “first year” means first year on sale--development has been ongoing as my primary job for nearly three years now, averaging out to a little over $20k per year, or barely enough to get by. (Right now assuming minimum wage I’m still short $10k.)

Am I happy about it? Hell yeah! While I wouldn’t call commercial traditional roguelike development sustainable just yet, I’m confident that I’ll actually start turning a profit (to fund the next game!) with increased exposure and the inevitable 1.0. And for now at least it’s been enough to continue on without too much worry, instead of rushing to 1.0, which means a better/more game for you :D


Thanks to everyone for your support so far! If I wasn’t on this full time we wouldn’t have seen anywhere near the current progress. Here is a composite changelog from the past year, Alphas 1 through 8, and this is where the time has been invested:


Cogmind development time, July 2013 -- April 2016 (excludes 2012 7DRL work).

The total time investment comes to 5,218 hours.

Cogmind is a code-heavy game, since the vast majority of visual assets are scripted rather than drawn manually--that same graph for other games would look quite different. Not surprisingly two-fifths of development is spent writing code.

As is common with most (successful) indie games, community efforts play a large role in that success. At least a third of my time is spent writing blog posts, posting development updates, and (more recently this past year) on the forums interacting with players.

Sure it would be nice if more of that effort could instead be funneled directly into the game itself, but honestly a portion of that community interaction helps get the word out about the game (thereby enabling everything else because that’s where revenue comes from :P) while also having a number of indirect benefits for the game itself. Interacting with others, or even just writing for a reflective audience of me, has helped shape the game over the years. This approach is the foundation of well-rounded healthy development, something enjoyed by few AAA studios, where everything takes a back seat to marketing and revenue concerns. (The #1 goal there is to maximize profit, after all. If my goal with Cogmind was to maximize profit at minimal risk rather than make a dream game, it would be on Steam and at “1.0″ already.)

In the graph you can also see the Content category is starting to rear its head there, an increasingly important part of late-alpha development as most of the mechanics and systems are in place, but the world has plenty more locations to fill in.

The Future

Where do we go from here? Well, as usual there’s the development roadmap outlined over on the FAQ which is updated with every release.


Cogmind roadmap as of April 27, 2016.

As indicated it’s really just a general outline, and there are quite a few other features (and even new locations) I want to edge in there if I can afford to.

In the near term, another release will be out within the next few weeks, then there will be a slight lull for part of the summer as I take a trip to visit family (it’s been years) and hopefully recover from my recent injuries without issue. Then it’s back home to work on late-game stuff and releases will continue throughout the rest of the year.

The biggest elephant in the dungeon is obviously Steam--Cogmind needs to be there eventually, most importantly as a way to reach new players. It’s unfortunately not anywhere near as simple as I’d like it to be (my current arrangement is super simple by comparison). Due to my situation, I have no choice but to remotely set up a company in the U.S. (as a foreigner) to sell Cogmind via Steam. Yeah, not fun. (WTF I JUST WANNA MAKE GAMES /minirant.) That’s only one factor among many, though.

Increasing exposure and expanding the player base requires a huge investment of time that would further drag on development, but it might become necessary before long depending on how many new players the next couple months bring. Tough to balance!

Cogmind is far enough along (and close enough to completion) that it’s about time to see what if any effect a slightly lower price will have on take up. So to celebrate the one-year anniversary of Cogmind Alpha Access, starting this week I’ll be offering a new limited-quantity tier at $25. Although one could say it’s 17% off the $30 price, it’s not technically a “sale” because the new tier doesn’t come with any perks, so it has somewhat lower intrinsic value as well. I’m extremely curious what kind of impact this will have on sales. As usual, I’ll be sharing the results at some point.

But for now, because they took forever to create and I want my money’s worth, here are a few of the updated website images to come :D


Activating a terrain scanner.


Activating a transmission jammer.


Dev shot of a fully-revealed factory map generated using the latest algorithm (lots of important changes from a year ago).

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