About one year ago I launched this new blog to provide updates on Cogmind’s development. 1,533 hours later development is still chugging along. Yes, I keep detailed stats about where time is allocated and plan to share those figures and more in a (much) later post, but today I want to write about the first year with regard to the planning that goes into a long-term indie project, as a way of reviewing both where we’ve come from and where we’re headed (1.0 of course!).
First, take a moment to look at the past year, in the form of all the images that have appeared on this blog so far:
Development (re)started in July 2013 when I wrote an expanded design doc (1,320 words for the 7DRL became 18,000 words). After some time spent cleaning up the mess that was a hastily coded 7DRL, the next few months were spent adding support for basic mechanics that were missing from gameplay: guided weapons, salvos, overloading, multi-tile robots, melee combat, large parts, factions, burnout, momentum, EM disruption, hacking, and machines. These were new systems fundamental to the updated game that could be implemented in any order I felt like, thus this period was mostly spent coding down a long list of mechanics--overall a pretty free-form phase of development.
Development time for individual items like those listed above can be measured in days, but the next phase would move into major components and require an ordered approach. You don’t want to start work on the world generation before a good chunk of the content is ready, or build robots before most of the parts are designed. At this point I also needed to know about how much longer development might take. Enter the first roadmap:
Estimated time required for each component is measured in months, with the total expected time for completion at the bottom. The date the roadmap was written appears at the top.
Every couple weeks or so I revisit the roadmap to check that development is proceeding on schedule. Rather than update the roadmap over time, I update a new copy of it in order to keep old states for comparison, making it possible to track when and where the pace of development differs greatly from estimates, if at all.
Looking back at the first half year of roadmaps, I’m pleased to see that my estimates were fairly accurate:
Keep in mind that this is only a high-level general roadmap. Most of the intermittent planning stages are spent writing and organizing extensive medium- and short-term to-do lists which are referenced daily/hourly.
Because frequently pausing development of a major feature is an inefficient use of time, newly discovered bugs and necessary little improvements are collected on to-do lists for later and handled in between major features. These lists tend to grow significantly and while this phenomenon is not explicitly shown in the roadmap, it is taken into consideration for the time estimates--always pad your estimates!
Looking at the process so far, and what still lies ahead, three phases of development emerge from the data:
- Mechanics: The initial roadmapless phase where basic functionality is designed and coded. A period of very code-heavy development.
- Content: Create objects based on all available mechanics. A data-heavy phase without much coding.
- World: Build the game world using content from the previous phase. A mix of equal parts data manipulation and coding. Lots of iteration is necessary to reach the intended experience, and algorithms are tweaked to fix inadequacies in the results. (Development has recently been shifting into this phase.)
So what happened to the fourth phase?
It actually belongs at the front--phase 0. Ideally development of a new game begins with a so-called “vertical slice” of the game experience to make sure the long period of development will be worth it. At the simplest level this is a prototype that proves the core mechanic, and I already had this in 2012 with the 7DRL and therefore didn’t revisit it. This is actually a small cause for worry because the new hacking mechanic, a pretty major element, has never been tested as part of the whole! (The ability to have allies is another game changer, but I’m less worried about that.)
The Last 10%
Most developers have heard the saying that the last 10% of a game is 90% of the work. Now I haven’t by any means reached the last 10% just yet, but the principle is nonetheless already taking some effect.
After a year of work there’s already a mechanically sound, mostly bug-free experience with dozens of robots, many hundreds of items, hundreds of pieces of ASCII art, a thousand sound effects, a fully-animated interface, blah, blah, blah… but no game! Every day I literally remind myself “still so much to do…”
Looking back at the first roadmap, nine months from December is… now! There are several reasons for this.
Firstly, because there are many variables in development and I don’t want to waste time planning too far into the future, the last 25% of my original roadmap was either oversimplified or missing important features.
My roadmaps also don’t take into account real life delays, things like vacations, family issues, the occasional freelance job… You’ll notice that the provided selection of roadmaps ended just before May. The string of good examples ends there, as that’s when I put development on hold for five weeks to deal with some other obligations. Another week in July was reserved for family, and several weeks will be eaten up come October, and probably December, too.
I’m luckier than most full-time devs in that I have relatively low operating costs and don’t need to set an absolute release date, but having a roadmap is still essential for staying on track, and of course helping answer questions like “WHEN CAN WE PLAY IT?!”
So when can we play it…?
Now that we’ve definitely moved into the latter half of development, it’s time to revisit the roadmap and make sure it’s accurate based on what we know now.
As you can see I’ve switched from months to weeks as we break larger features into smaller chunks for the final run. While using days as the unit of measure would enable more accurate individual items (some may take less than one week, some more), there’s no reason to bother with that level of detail since it’s difficult to predict--might as well fudge it and let the values average out in the end.
Adding in some previously missing elements also increases the total time required. Based on the roadmap, and knowing that at least four weeks later this year will see no development, the absolute earliest we’ll see a pretty complete game is March 2015. Game development sure does take a long time!
I’ve been wanting to make a prettier and more detailed public progress graph available on a new Cogmind site, but haven’t gotten around to building the site yet (hopefully soon). Instead I’ll just post the chart here for now.
Yeah, it looks full of big holes, a result of the disproportionate amount of time required by individual items (some of those bars represent week-long projects, while others took an entire month), and also because the mechanics and much internal work are underrepresented.
Also note that some remaining components will be outsourced: Sprites and ambient map sound/music. Those don’t even appear on the roadmap, as much of the work would be done in parallel anyway.
So March 2015 it is? Not exactly. In fact, I’m still aiming for a first release this year. Still debating how to handle the whole release issue…
What state should a game be released in?
I believe a free game should be released as soon as it’s playable. This gives the developer immediate feedback from interested players and the game can grow around them. Heck, if Cogmind were free I’d release it right now since it’s already playable and fun even without a complete game world.
The issue becomes a little trickier with a commercial product, especially when you want to reach the largest possible audience in a market flooded by more and more games--many obscure games don’t get a second look so the first impression is pretty important, be it by media or by players themselves. Releasing too early is putting a greater portion of the results in the hands of chance.
Cogmind is more than just a roguelike dungeon romp, but you won’t see that in the game’s current state. By the time it’s done there will be a story, lore, NPCs… While it’s currently very “playable” in the game sense, the intended experience is simply not anywhere near complete. I hope that when people see, or play, the game they can see a greater range of what it has to offer.
So I can at least say that it won’t be released now.
There are two options I’m considering for how to start releasing.
One is as a demo for a Kickstarter campaign. Still not sure if I should bother with that route since it would postpone 1.0 even further, though it would give the game greater exposure (while implying that “it’s not done yet”) and bring in more money that could be spent on better audio-visual components. I almost want to do this simply as an elaborate excuse to get myself a Cogmind T-shirt =p
The other is simple alpha funding, which itself could go one of two ways. Either initially sell only through my own site without trying to reach out to a larger audience, gradually getting into the market and expanding exposure as necessary, or wait a little longer and go for a bigger early access release on multiple platforms.
“When it’s done.”
Haha, just kidding. Little roguelike dev joke there.
Each of the “hows” might have its own slight affect on the first release date. KS would be earliest, small-scale alpha would be later, and full-scale early access would be latest. I’d like to think that any of these options would see the game out there somewhere in a November-December time frame.*
*Fake fine print: No promises.