Author: by Blair Fraser

The original Sins of a Solar Empire released in 2008 to critical and commercial success. Development responsibilities for the game and its two subsequent expansion packs were shared between Ironclad Games and published by Stardock Entertainment.

Staffing breakdown for Stardock developers on Sins: Rebellion

Even after two expansions, the teams felt the definitive version of the game had not yet been realized. With Ironclad Games working on the forthcoming Sins of a Dark Age, Stardock took a greater role in the development of the stand-alone expansion Sins of a Solar Empire: Rebellion to do just that.

Sins: Rebellion was developed with a small team over 13 months, including about a week of crunch (mostly individual late nights clustered around the various beta and final releases). Stardock's staffing peaked at 11 developers, as shown below.

What Went Right

1. Focused Design

The original Sins of a Solar Empire was a game of considerable scope and depth when it was initially released. After two additional expansions, simply adding more ship variants or weapon buff technologies would have been adding content without purpose.

We also had logistical constraints. Stardock's other internal projects limited the number of art staff that would be available to us. Additionally, engine memory constraints limited the number of assets that could be added. We ended up taking a quality over quantity approach, both as an intentional design choice and out of necessity.

Concept for one of the six new Titan warships (click for full size)

Careful gameplay balance was needed to make these units game-changers, without overpowering other strategic options. Click for larger version.

With this in mind, the design of the game followed the approach of adding unique and game-changing technology, ships, and victory conditions. With that approach came additional risk. Features like destroying entire planets or players abandoning their homeworld and "going mobile" added new strategies, but also could have upset the balance of the entire game if implemented poorly.

Gameplay balancing to avoid these risks quickly becomes a time sink when a complete match lasts 5-plus hours. We also needed to balance the needs of hardcore competitive multiplayer fans with our larger single-player focused audience. Since the development of the original Sins, an "MVP" program was used to mitigate these problems. Through this program we invite some of our most active community members to receive regular builds throughout development and give feedback on the balance of new gameplay features.

The MVP program combined with our team's strategy design expertise and long experience with the franchise allowed us to walk that fine line of making big new changes without breaking the core of what fans had grown to love. This paid dividends in reinvigorating the gameplay and was the high point of many reviews.

2. Cutting Scenarios

One of the complaints that showed up consistently in reviews of the original game was its lack of a campaign. We'd always felt that a campaign wasn't a good fit for the type of gameplay that Sins of a Solar Empire offered. Our sandbox style games also tend to last as long as most single player campaigns. Though a traditional campaign was off the table, we did design a "Scenarios" feature to address a player's desire for more controlled and deliberately paced gameplay challenges.

About eight months into development, we took a hard look at the work remaining on the project and realized that moving forward on the Scenarios feature would likely result in:

We decided to cut the feature, while leaving in the underlying tech for modders to experiment with post-release. It may be odd to have a complaint from reviewers and fans alike in the "What Went Right" section of a postmortem, but we feel we made the right decision to ensure what we did deliver fans was of the highest quality.

3. Proven Technology

Despite the Iron Engine nearing five years old, it's solid and proven technology that our engineers loved to work with. The ability to update art and design content and see the results on the fly was invaluable, especially in a game where single play sessions can last in the tens of hours.

If we weren't confident in the existing tech, the project would have likely been cancelled before it got off the ground. We knew from the start that switching engines or making major overhauls was out of scope for the time and budget we had to work with (as is usually the case with expansions).

One new ability allows players to destroy whole planets, drastically altering the map

While the core tech worked great, the game was beginning to show its age. Instead of major overhauls, we identified graphics features that would keep us visually competitive with recent releases while staying within the scope of the project. Some examples include dynamic shadows, anisotropic filtering, and improving anti-aliasing quality. These features allowed us to keep using tech we were familiar with without letting down fans and critics with dated visuals.

4. Win-Win Beta

For three months leading up to the final release, we ran an extended beta that ended up as one of the keys to success for the entire project. Each phase of the beta, lasting about a month, would add two more of the six total new factions to the game. These phases allowed us to isolate areas of the game for technical and gameplay testing, as well as continue to keep interest high all the way up to release day. Throughout the beta, the Sins community was fantastic in providing quality gameplay feedback and assisting in uncovering hard to reproduce bugs. We owe a lot to our fans.

However, we came extremely close to throwing this all away. Our initial plan was to hold back two of the factions for release day, so there would be a significant chunk of never-before-seen content left to discover. Instead, we took the cautious route, released all the factions as part of the beta, and uncovered some terrifying bugs that could have led to a disastrous release.

In the end it was a win-win on multiple levels. For our fans, it allowed them early access to an anticipated game and the opportunity to provide meaningful input on its development. For us, it drove preorders, kept buzz up, and guaranteed a smooth and stable release.

5. The End of Retail

Stardock has a complicated history with digital distribution platforms, as we developed and ran the Impulse service for several years. With the sale of Impulse to GameStop in 2011, we were no longer constrained as to where and how Sins: Rebellion was distributed. This led us to fully integrate Steamworks and forgo a retail release in North America and most international markets.

An argument for digital distribution

Compared to the benefits of a digital-only release, both Stardock and Ironclad didn't think the date commitments and low cut of boxed product sales were worth the hassle anymore. That choice paid off. We saw pre-orders increase by 630 percent compared to the release of the original Sins of a Solar Empire in 2008. While we don't attribute this entirely to increased focus on digital distribution, it certainly played a large part.

Relative comparison of total units sold

We started accepting preorders on the Stardock web store several weeks before they were available on Steam. When preorders became available on Steam, we saw the expected jump in overall sales, but interestingly saw no dip in direct sales of the game through the Stardock web store. We've also seen huge jumps in sales from Steam's promotions and price discounts without any negative effect on overall sales trends.

In addition to the sales benefits, the integration of Steamworks has improved the ease of beta/release/update management, error tracking, and verification of international retail activations.

What Went Wrong

1. Lack of Formal Production Practices

Despite what we generally considered a smooth and successful development cycle, we weren't without our fair share of setbacks. For the first six months of production, one person was juggling design, project management, and a number of significant project-external responsibilities.

They were -- obviously -- overtasked. It led to a lack of communication on scheduling between studio management and the development team. Initial estimates for the number of artists required were too low, and the project was starting to fall months behind schedule.

In response, a dedicated producer was assigned to take over production responsibilities. When the producer transitioned onto the project, the status of the project was reviewed with team members to ensure the current list of tasks was accurate and complete.

After the tasks were organized into a backlog, team members in each department met to give rough estimates for these tasks. Tasks were typically estimated as one day, three days, one week, or two weeks. Any task over two weeks was broken down into more detail. We rarely attempted to estimate tasks with any more accuracy during mid/long-term planning; as we'd just be fooling ourselves into thinking our predictions were more precise than they could be.

Once the project review was complete, we kept things on track with a daily standup and weekly sprint review/planning combo meeting. During sprint review/planning meetings would typically run through the following agenda:

These meetings would take about an hour. The producer and designer would be present for the entire meeting. The rest of the team would be present for varying amounts of time based on need so a UI artist didn't have to sit through 30 minutes of technical discussion.

While the understaffing of project management likely cost us a month or two, we were ultimately able to recover. This made sure there was more bandwidth to implement and maintain formal production processes while making sure the design was the best it could be.

2. Unexpected Departure

Further complicating early development, a key employee we planned to assign to the Sins: Rebellion art team left the company. This individual had been the go-to artist for working with the Iron Engine for the previous expansion pack, and had valuable experience working with the more technical aspects of that toolset's art pipeline.

When they left, we had not yet staffed the art team, and there was no obvious person to transfer that knowledge to. Additionally, they were still assigned to another project within the studio, which took priority over documenting their pipeline knowledge in the weeks before departure.

When we finally did hire and free up art staff to come onto the project, much of the first month was spent re-learning that pipeline. Thorough documentation (or not losing the team member to begin with) could have saved time early on as well as making technical hiccups in the art pipeline easier to resolve later in development.

3. Inter-Studio Communication

Any project coordination work between two separate studios will have related challenges at some point. Luckily, our relationship with Ironclad has been, and continues to be, fantastic on both a personal and professional level (we love you guys <3).

However, the ease of this relationship allowed us to be lax in our communication. Coordinating approval of game mechanic designs, UI visuals, and other art assets by email was a slow process. These "done pending approval" elements of the game multiplied the uncertainty that goes with most production estimates. For example, instead of knowing our UI artist would be free to move onto another studio project with approximately a two-week margin of error, we always had to add the caveat of "if we don't have any surprises in the feedback".

Something as simple as a scheduled weekly call could have eliminated the occasional blocking issue and identified problem areas in development more quickly. The lesson for us was, treat external team members like internal ones and schedule regular meetings, even if they are just a brief touchpoint, to make sure everyone is on track.

4. Shadows

One of our goals was to keep Sins: Rebellion as visually stunning as its predecessor was when it first released. A major hurdle was the implementation of real-time shadows, with the sheer number of units being drawn over a wide variety of scales. A completely new method was required.

One of our engineers was tasked with implementation of this major graphics feature, despite being unfamiliar with Iron Engine's graphics tech. This led to burning over three months of an engineer's time because this misallocation of a task wasn't identified and reassigned to Ironclad's team earlier. Setting a clear milestone to evaluate the progress of major or risky features would have found and fixed this issue early on. In the end, the pain of development is numbed whenever a Titan ship eclipses the sun and casts an entire enemy fleet in darkness.

Two Titans battle it out

5. Legacy Bugs & Assumptions

Throughout the early phases of the beta, we'd gotten intermittent reports of players getting desynchronized during multiplayer matches, forcing them to restart. Partway through a match, they would discover inconsistencies between the state of the game on different player's machines.

A planet might be owned by a Player A on one machine, but owned by Player B on another. A battle could be raging in one corner of the galaxy between two players, while the third player would see nothing. Worse, unless players were constantly communicating with each other as to the state of the game, the desynchronization would often go noticed for 30 minutes or more. However, these reports were uncommon, consistent with what had rarely been reported in previous releases of the game, and couldn't be reproduced with stable network conditions.

Or so we thought.

With the potential time suck of a wild goose chase, and the uncertainty of whether we'd actually fix what we thought was a rare issue, the siren song of "It's always been like that" was too strong for us to resist.

In reality, we had introduced a number of new desync bugs that had a reproduction rate of nearly 100 percent if you were playing the right type of match. It turns out this was a match type a lot of people happen to enjoy.

Large universes played with four players or more made for some epic multiplayer matches. They also made for some epically long multiplayer matches -- so much so that playing one would keep one third of our dev team tied up for a full day. As you might expect, this time commitment resulted in those games being played less frequently than other modes during development.

In the end, the community yelled loud enough to snap us out of our spell. It added a hiccup to the beta and an unwanted scramble towards the end of an otherwise smooth dev cycle, but disaster was averted. It forced our hand -- to focus both on the desynchronization issues we had introduced and the ones that had been there all along. This was a blessing in disguise, as it resulted in a multiplayer experience that was much more stable than any other title in the series.

Conclusion

Not without its lessons learned, Sins of a Solar Empire: Rebellion is now the most successful launch and one of the smoothest development cycles in Stardock and Ironclad's history. Based on our review of the successes and failures along the way we plan to continue extended and complete public betas for all of our future titles. It's cemented our confidence in a digital-only strategy. Most importantly, it has reinforced our commitment to quality above all else in the games we release.

Project Stats

Developers: Stardock Entertainment & Ironclad Games

Platform: PC

Release Date: June 12, 2012

Developers: 15 (at peak)

Development Time: 13 months

Tools & Technology:

Distribution