Starbound Post-Mortem: Part 1
Updated: Jan 23
DISCLAIMER: This is not about the quality of the end product or a review of the game itself. This is my guess on how the development cycle went based on their dev diaries.
A game’s development cycle is long and rarely straightforward. Features are altered to accommodate emergent gameplay and popular trends, adding time—and expenses—to the development process. Early-stage planning can reduce delays from mid-process design changes, whether it’s a AAA title or an indie game, but this can be hard to picture without an example. I'll be using Starbound, by indie-studio-now-publisher Chuckefish, due to their extensive blog that covers years of development. For those that don't know, Starbound is a 2D side-scrolling exploratory sandbox that can be described as “Terraria in space.” It made a name for itself, being well-received by critics, raising over $1,000,000 on Kickstarter, and selling over 2.5 million units. So while Starbound is certainly a successful product, was it developed effectively?
Looking at its development process, we can uncover valuable lessons. With a Steam Early Access release in December of 2013 and a full release on July 22nd, 2016, the case can be made that, with proper planning and project controls, the development time could have been minimized. Going by blog entries covering combat reworks, monster reworks, and systems that don't fit the game's theme/tone, you'll see why I chose Starbound as an example of how pre-planning could have cut development time. In the interest of fairness, some of the issues that will be covered have been addressed in post-launch updates, but I'll only be covering development up until the 1.0 release.
As Chucklefish hasn’t released in-depth data regarding development, I'll make estimates based on 30 blog entries I ID'ed as unnecessary work for demonstrative purposes. Just so we're on the same page, what I consider unnecessary work is any time a system was overhauled or a feature is added that doesn't contribute to the game's theme/tone. With that out of the way, let's do some math. As Chucklefish team members had jobs in addition to working on Starbound, my assumptions are as follows: in my best-case scenario, I assume work per blog entry averaged four work days from two people—one artist, one programmer—while in the worst-case scenario they averaged two weeks for four people—two artists and two programmers. In my best case scenario, the work time per person results in 120 days, about 2/3 of a year added up. In my worst-case scenario, this comes out to be 420 days per person, a little over four and a half years combined.
With a team that grew to 15 people, system reworks and feature creep mean a significant investment of time and effort. While pre-production planning wouldn't have cut these numbers entirely, it would have reduced these figures significantly by eliminating redundant work and keeping the scope narrow enough to work effectively. My assumptions also don’t take into account delays caused by waiting for feature sets to be completed before starting the next task, which, of course, adds development time. I'm hoping if you learn anything Starbound’s development process, it's that pre-production planning can save time, money, and effort by eliminating reworks of systems and containing feature creep.