Official development blog

The Alpha Release Cycle: Running a Successful EA Program

Just last week I put out Cogmind’s tenth alpha release, and as we speed towards the end of the open alpha period, now is a good opportunity to look back at the very deliberate pattern behind the development of each release, a repeating cycle that has continued for over a year now.

And not just development itself, either--I’ll also be describing how I use social media in parallel with this process, because that outreach and interaction with the community is important to growing and maintaining the audience necessary to drive a successful indie game (i.e. anything not backed by advertising dollars where you can basically just pay for your potential audience).

Hopefully by sharing my approach here, other game devs might learn something useful, and players will better understand what goes on behind the scenes while waiting around for a new major version to drop :D

One Month

Assuming no special circumstances or interference from external factors, I aim for one major alpha release every month.*

I’ve found that interest tends to wane when letting players wait too much longer than one month for new content and features. I’m sure the appropriate length of time here varies by game--for example something driven more by community content could easily go longer between releases.

A shorter two-week cycle (or even less) could work, but presents its own problems. It means that each release will naturally be less substantial, and therefore less impressive, and fewer people talk about things lacking impressiveness :P

So for marketing purposes it’s better to turn each one into a somewhat larger production, while doing so also increases the likelihood that players will feel that each new release is worthwhile, since it’s enough development time to address multiple facets of progress, namely work on a sizeable chunk of new content, make adjustments to existing mechanics and content based on player experiences, and provide fixes for any previously discovered issues.

As a full-time solo indie there are also residual tasks to deal with (e.g. community stuff) for each new release, and those are better to spread out than trying to maintain some unsustainable breakneck pace (it’s easy to be overwhelmed!), whipping back and forth between front-facing promotional efforts and internal dev work.

Thus a one-month cycle strikes a balance between making just enough progress to be considered significant, while not keeping players waiting. My cycle is divided into three distinct phases, each of which I’ll walk through in detail below.


At its simplest the cycle looks like this, but there are a lot of details in there.

*One month is the ideal, anyway. Looking back at Cogmind’s previous release dates, the true numbers show an average between 5-6 weeks. This is due to said special circumstances and external factors, including a multi-week community event, a recent vacation, and a detour to build the technical foundation for a large unique part of the world. I also write at least several blog posts and other articles per month (like this one :P), and the time to do that has to be edged in there somewhere.

Phase 1: New Content

Half of the cycle, the first two weeks, is devoted almost purely to completing the majority of the release-to-be’s new content. For Cogmind that means working on new maps and the lore, NPCs, dialogue, plot elements, and sometimes new items that go along with them.

So I’ll generally spend the first day of a new cycle sketching map layouts on paper, followed by figuring out what parameters my mapgen utility needs to meet that criteria.


Working on a variety of maps in Cogmind’s mapgen utility. I’ve written a lot about map generation before.

I also write up a text file for each new map that describes its layout, inhabitants, special encounters, and summarizes its gameplay value in terms of challenges and how it could fit into a player’s long-term strategy. Here is an example of such a file for the Recycling map, one of the less involved areas but it still gives you a clearer idea (warning: minor spoilers if you haven’t played! This is also why I can’t really show files for other/better maps--the spoilers are much worse :P).

All of the above is a pretty organic process because sometimes the map might do a better job of informing the text, and sometimes the opposite is true, leading to a bit of back and forth adjustments between them until they align.

When the map is generating within expectations and will likely play as desired, all the other details start to go in, like prefabs and the other content listed before--everything that combines to make a map come alive.

New content comes first in the cycle because it’s the largest component of a new release, with the most moving parts, and it can be more difficult to accurately predict what its full implementation will entail. Maybe a new area needs a new mechanic to go along with it? Or an existing system needs to be expanded? If a release deadline approaches, little tasks can always be postponed to a future release, but a new major alpha release without complete new content defeats the purpose :P. Therefore it’s safest to get this out of the way early on, which has the added benefit of allowing further development to proceed with peace of mind.

On the Outside

When it comes to promoting Cogmind, my goal is to always have at least one image/gif to show for each week (if not more), which makes this first phase the most difficult in that regard since it is centered around either internal development of non-visual elements or content that I don’t like to spoil. Sometimes there’s just nothing to share!

To avoid breaking that rule, I might spend Friday instead working on some quick UI/visible feature that I can show, just to be able to keep putting something out there. It’s motivating to interact with players and followers over some new development, and from everyone else’s perspective they can see that, yes, progress is being made. Keeping that flow of information going is important.

Whatever I do have, I generally share to Twitter first, and sometimes other forums where Cogmind gets a lot of attention (Bay 12, TIGS), depending on what it is.


This sometimes includes development shots, since those following a game in alpha development are likely interested in the process itself. Above is the FOV transition detection test visualization.

At the end of each week, I also share whatever I’ve been doing to /r/roguelikedev’s Sharing Saturday, usually taking anything I’ve posted to Twitter and using that as the foundation for a post, adding to it notes on whatever else happened, e.g. blog posts, release details, plans.

By the end of this phase, it’s about time to do a progress report for the forums and /r/Cogmind, summarizing recent developments. Again, keeping players in the loop is crucial to maintaining interest, not to mention the responsible thing to do once the very first player has given money to support alpha development. They have a right to know, and it’s not very difficult to post a few words to update everyone on its status! For reference, here are the progress updates for the latest alpha: 7/21, 7/28.

Phase 2: New Features

The next phase is shorter, a week devoted to some bigger feature (or maybe two), either mechanics or UI-related, which is chosen by analyzing and weighing what’s most important to address, what’s most requested, and what’s most feasible at the time.

For Alpha 10 it was the lore collection UI and evasion stat summary window, Alpha 9 was the interactive machine overhaul, Alpha 8 was real-time FOV updating, and so on.


Cogmind evasion readout in action.

Regarding the feasibility aspect, it wouldn’t have been as efficient to implement the lore UI early on, since a good portion of what it was designed to access wasn’t added until Alphas 8 and 9. If implemented before that, it may have been necessary to go back and make adjustments later, meaning wasted effort! I never choose what to work on based on what I want to be doing, but rather what I should be doing at the time, after all factors are taken into consideration.

Developments in this phase are a good pair with Phase 1 because they are generally features that all players can experience. It’s nice to ensure with each release that there’s something new for everyone, especially those who may not yet have the knowledge or skill required to reach all the new content/maps (particularly in recent releases, as those areas are further and further from the beginning of the game).

On the Outside

This phase is much easier to share than the first because it doesn’t contain spoilers and the results are generally worth showing and very recordable (GIFs!). Anything big produced from Phase 2 is shared to all of the places mentioned earlier. Around the end of this week it’s also time for another progress update.

Phase 3: The Little Stuff

In the run up to release, the last week (or more often just 3-4 days) gets a lot more exciting. Accelerating progress is always exciting :).

Phase 3 starts with a review of the TODO list. I primarily organize development through a single text file containing everything from high priority plans, feature requests, known bugs, mechanic tweaks that came out of playtesting or reading about alpha players’ experiences, random thoughts of what can be improved, all the way down to low-priority long-term “maybe” stuff. Any dev time outside Phase 3, this list tends to get out of priority order as new items are thrown in (usually at the top), and priorities can also change with each release depending on the results of the previous release, among other factors.

Thus the first order of business here is to take the top section of that list, a realistic number of tasks to complete that would be nice to include in the next release, and reorder them based on priority.

While the previous phases focus only on the new, this one includes all three components of development: simple new features, changes to existing content/features, and bug fixes.

All bugs are immediately prioritized to the top, since I won’t release until all of them are fixed (there usually aren’t too many, and nothing serious). By leaving this for the end of the alpha cycle, all the bugs in the previous release will have been found (most I find myself while playing, since I know how everything is intended to work and can spot them relatively easily), so all of them can be solved at once.

Remaining items are prioritized according to the same factors considered in Phase 2, in addition to how long each might take to implement.


An excerpt of what a post-prioritized list looked like for Alpha 10 (click for full size). This file is actually named changelog.txt, because it also includes the current and all previous changelogs, with earlier versions at the bottom, the current one at the top, and all the TODO items in the middle, where completed TODO items can be immediately reworded and shifted right up to the changelog.

Notice that a given listed topic may also have a link to a forum thread, some other web location, or even a player’s name. Whenever applicable I’ll save links to any relevant discussion on that topic, often useful for reference once I’ve inevitably forgotten the details (way too much to keep track of!). There some of the reasoning will have already been done--usually including my own opinions at the time--thereby shortening the implementation process and offering different points of view against which to compare my more recent thoughts.

As mentioned earlier, this list can be cut short as necessary if release day is approaching, which is why it’s saved for last. I’ll just keep chipping away at it until I run out of time, and anything that’s not done continues to survive on in the list for future release work.

My workload for this phase is not purely time-based, however. Just as important as fleshing out the “something for everyone” aspect of a release as begun in Phase 2 is the desire to ensure the changelog reaches a certain length. Yes, length as in number of lines :P. Examined closely, changelog length is a poor metric for the quality of a release; after all, a single item may take as little as a few minutes to implement, while another line may represent an entire day’s worth of work, if not more! Regardless, appearances are important, so if a release is imminent and the changelog hasn’t yet reached my prescribed length, I may choose to promote a few easier tasks to fill it out.

Besides, we already know that the release is a good one from an experience standpoint, because that’s what the first several weeks were spent ensuring :D

On the Outside

This is by far the most outwardly prolific phase, and as such there is no shortage of images to share. Release day is also not far away, so towards the end of this phase I screenshot features and record gifs (LICEcap is great for that, and I optimize the results with gifsicle), and collect them all into an “Upcoming Features” post in lieu of a standard progress update. Here‘s an example from Alpha 10. And 9. (They’re cross-posted to the subreddit, too.)


List of images collected to demo Alpha 10 features.

This is also generally when and where I’ll imply that the public release will be coming within the week, though I never announce specific dates because anything could go wrong and there’s no sense in making a promise that might be broken.

There are also enough images here that I’ll be able to share them intermittently on Twitter, and often save one for the #screenshotsaturday hashtag on Twitter to maybe have a better chance of exposing someone new to the game.


Pre-release testing is important, but there isn’t all that much of it to do shortly before release given my approach to feature and content development. Each element added to the game undergoes extensive testing based on a list of potential problems prepared both prior to and during implementation, as different considerations are thought of at each stage. Whether brainstorming, designing, or coding, in the background I’m constantly asking “what could go wrong here?”, and jot all those possibilities down so that once the feature is presumably complete, every single condition on that list (which may be dozens of items long) is explicitly tested. It’s essentially a QA job, only in this case my deep familiarity with the source and systems makes it easier to think up hypothetical issues. Integrating this process closely with development of a single feature also increases efficiency, taking advantage of peak understanding of the new system and code behind it.

Before testing a feature, anything in the list which might affect other test items is shifted to the top, and nearly every change to the source is immediately compiled into a new build for testing before moving on to the next item. Compiling is quite fast, as is testing on the game side with the help of debug mode, where it’s easy to teleport around, spawn objects, reveal maps, and basically control any aspect of the game necessary to confirm or disprove issues. Finding bugs before they reach players is a worthy goal, and a good debug mode is essential for quickly setting up test scenarios to stay as efficient as possible.

With that kind of process throughout Phases 1-3, there isn’t as much need for a dedicated testing phase. But in game development, complexity rapidly expands with the number of interacting systems, making it difficult to fully predict the results. A portion of issues will inevitably make it all the way to players. However, testing still plays a vital late-cycle role in preventing the worst problems: crashes or known errors caught by assertions in the code. And there is a pretty good way to keep these out of the release: automated testing.

The goal with automated testing is of course to get maximum coverage, for which I have two main setups.

The first is aimed at map generation, an extremely involved process from building the initial layout to defining its contents with the help of scripts. In this test the game starts normally, loads the first map, chooses a random exit and builds that next map, and continues like that to the end of the game before starting over at the beginning again.


Mapgen auto-test. This one I usually let run for a few hours, directly in the debugger, and that’s enough to feel safe.

The second auto-test is aimed at AI behavior (both central and individual), combat and many of the game’s other mechanics, looking to crash or bug out by repeatedly loading different maps and pitting a wide variety of different opponents against each other. Hundreds of them, in teams. In a game where the world is already pretty alive with robots carrying out their regular duties, this gets pretty chaotic, and chaos is good for testing :).


AI/mechanics auto-test. This one is carried out in four separate games running in parallel, all four of which will continue running overnight. If none of them encountered any issues then it’s safe to say it’s ready for release, otherwise any problems are fixed and all four will be run again the next night. Normally the player is automatically teleported to a remote inaccessible location so as to not interfere with the tests (their turn is simply skipped), but if you want to see some of the AIs blasting each other, I recorded that here :D

Testing sometimes overlaps with the latter part of Phase 3 because in a worst case scenario it might be two or three nights before the all clear. And the worst thing that can happen to a player is to have the game crash, so it’s vital that these thousands of runs are played by my laptop first--laptops never complain if the game crashes :P

Release Prep

The day before release it’s time to package it up and get ready to put it out there.

To make sure I don’t forget anything I follow a simple step-by-step checklist:


Pre-release checklist (the content is explained below).

Once the game is zipped up, I unzip it and run to confirm a fresh copy is working as expected, and that often evolves into a couple hours of playtesting, mostly for fun (it’s hard to stop :P) but also to be on the lookout for anything glaringly wrong. On average there’s usually one thing that I notice which needs a quick fix, so I do that and slip in a new executable.

Then I pre-write all the release announcements for the next day:


Announcements ready!

The first and most important would be the release notes, which give a more in-depth explanation of major features than the changelog can. (Ex: Alpha 10 release notes.) That’s followed by reformatting it for /r/Cogmind, and the simpler versions prepared for other forums.

For each of these announcements I follow a similar format each time (which varies somewhat by channel). It’s nice to have something that works and just follow it, to save time and effort.

I also screenshot the changelog, which will be sent out on Twitter. I always highlight the more noteworthy additions and changes by highlighting them, so the list is easier to parse for those looking to get a general idea. That highlighting carries over to the other forums (and subreddit) where I also post it.

Altogether the prep process can take the better part of a day.

Release Day

Release day itself is almost always a Tuesday or Wednesday, because

  • More people are paying attention to social media around that time, so more likely to hear the news (including non-players who might be hearing about it for the first time).
  • Fewer players will jump on the download right away, meaning I can get in a hotfix (if necessary) before an issue impacts too many players.
  • I wouldn’t want to be dealing with issues over the weekend, which is more likely to be family time.
  • This leaves Monday open to do final prep work, and extra time over the previous weekend to do more auto-testing when I might not otherwise be using my computer for development. (Testing must be done alone, because my dev machine is a five-year-old old cheap laptop :P)

Aiming for specific days of the week is another reason a single alpha cycle might have a few extra days tacked on, as mentioned in the beginning, because I’ll have to wait around for the next window.

With all the real work having been done the day before, first thing in the morning (which is actually evening in the US where most of the players are, because I’m in Asia) I’ll open up all the targets for pre-written announcements and start filling them in--multiple forums, the subreddit, YMLP, Twitter, Facebook, Rogue Basin, etc.


Getting ready to post all release announcements.

So I’m mostly on autopilot, which is good because I’m kinda not entirely “with it” early in the morning, sometimes even more so after staying up too late the night before to make sure everything is in order for a smooth release.

With that ready I’ll upload the latest build to FastSpring, the distribution system, at which point anyone can now get the latest version but technically won’t know about it until the announcements are made.


Updating a product in FastSpring.

This is where everything is done very quickly, because it can be confusing for a new player if they buy while I’m in the middle of a version transition, i.e. getting a newer version than has been shared.

As soon as the game files are ready, I’ll immediately upload the server file containing the release news and latest version number, which notifies anyone who starts up the game that a new version is available.

Then I release all the announcements at once.


Then I sit back and relax. Sort of :). Each time it’s a huge relief to have yet another release behind me, and I’m generally pretty tired from the inevitable accelerating pace towards the end of a cycle, but there is always more to do!

I’ve got to update the roadmap on the FAQ:


Latest iteration of the roadmap. It’s great to have a place where players can both see how much has been done, and watch progress towards major milestones.

As part of the announcements I send out email notifications to owners, using YMLP, a newsletter service provider I can’t recommend. (MailChimp is presumably better, but they’re more expensive and better for high-volume senders, whereas I don’t send out emails very frequently--nor do I have much money xD) Despite repeated changes to avoid the problem, these days the email is filtered as spam for some users of some email providers. There are so many ways to get the news and many players follow progress one way or another so I’m not worried about players not knowing. But I still keep an eye on the YMLP outgoing email monitor to see what portion of owners are receiving and opening the email.


YMLP mail monitor.

I’ll also be monitoring the forums, email, and chat for issues with the new release. Anything serious will get an immediate hotfix, which I’ll usually turn around within an hour, and if it’s still release day I’ll probably do it as a stealth update to the existing version rather than going with a minor version increment, also providing a publicly downloadable patch for anyone who already got the release.

For each release there are feedback threads on the forums (example) where alpha players can discuss the latest release without cluttering up the forums with separate threads (and are more likely to offer feedback when there is an explicit place to do it). These and other forum threads are where the majority of my notes (i.e. the TODO list from earlier) on what to tweak will come from.

More recently I’ve taken to releasing interesting stats and player metrics from the previous version, since the leaderboards are wiped with each major release. For example:


Alpha 9 stats posted here after the Alpha 10 release.

Players enjoy stats, and developers can also learn something from the metrics:

  • 81% of players use fullscreen (i.e. 19% play windowed)
  • 10% use hjkl for movement
  • 21% prefer ASCII over tiles
  • 27% use only the keyboard, no mouse
  • About half of players stick with the default font, while the rest are divided up among many fonts, but among them Terminus and the older default are the most popular

While I’m at it, some resolution stats, which aren’t too unexpected since we can see similar trends in the Steam survey results: 46% use 1080p, 15% use 768p, 26% use resolutions in between, 12% use resolutions above 1080p.

I also post a different kind of release announcement to IndieDB, one that mixes the changelog with all the preview images collected earlier, but wait until the first Friday after release to do that.

It’s fun to stream the new release, which usually comes with a new weekly seed, though my laptop apparently can’t handle streaming anymore so I’ll get back into that when I finally get a new one :P


Even if other devs don’t use this same pattern, the point is to figure out a cycle that works and stick to it! The details will vary by game and individual, but it’s always nice to maintain a consistency that players can appreciate.

I can say that Cogmind would have a very hard time being successful without repeatedly reminding everyone it exists through both visual progress updates and meaty version releases.

From time to time I receive emails and PMs from appreciative players, and while I was writing this article a follower posted one of those comments that makes a dev feel all warm and fuzzy inside, and happens to be really on point here, so I’ll temporarily suppress my ego-blocker to reproduce it here:

“Not to needlessly inflate your ego or anything, but you are without a doubt the best solo project developer I’ve ever seen. Your first playable version of the product was shockingly polished. Your steady stream of updates is unmatched. The super low level of bugs per release is actually straight unbelievable. Your dedication to using your own new ideas rather than easy tried and true mechanics is in a league of it’s own.

Following your progress I feel like I’m witnessing the output of a team of veteran programmers under time dilation.

I don’t know how you do it.”

Maybe there’s some value to this approach.

Note: Regarding the subtitled “successful EA program,” there are definitely other aspects to discuss such as the important issue of pricing, but I’ll write about that another day once I have more data to share!

Posted in Gamedev | Tagged , | 2 Responses

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