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.

Testing

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.

Post-Release

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

Conclusion

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:

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!

• Update 170125: Pricing a Roguelike
• Update 170307: Dissecting a Cogmind Changelog