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. 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 "
