Stellaris is a strategy game where players can build the stellar empire of their dreams. By navigating a series of interlocking economic, scientific and political systems, players create a unique storyline of exploration and contact with dozens of species.

On a spectrum of simplicity versus complexity, this is at the far opposite end from checkers. Still, once you learn the basics of managing your empire, Stellaris can be a blast.

The business model for Stellaris is echoed in many strategy titles. The 1.0 version of the game forms a foundation upon which years of new functionality and paid DLC can be designed and shipped. In the case of Stellaris, 20 expansions are available, ranging in price from $8 to $20, with the game itself retailing for $40. These expansions add everything from new species to entirely new storylines, political systems, and technologies. In Overlord, you can create new stellar megastructures and better specialize vassal states, while Synthetic Dawn introduces AI civilizations and hive minds.

This strategy makes the lifetime value of a committed Stellaris fan as high as $280 over the course of six years of releases, and there are further expansions on the way.

The approach of adding both new content and new game systems keeps things fresh, engaging both experienced players and newbies alike. It allows amortization of initial development expenses over a longer period, while maintaining the viability of the base game’s price.

Of particular note is that every major DLC release coincides with an update to the game that every customer gets even if they don’t pay for any expansions. The DLC model makes it economically viable to continue maintaining the intricate systems that drive the game, fixing bugs and eliminating tedium.

Stellaris is a better game today than it was six years ago.

How do I know all this? It’s easy.

Occasionally, I read the developer diaries.

Software storytelling

Software is itself a strategy game. We are constantly pivoting between the scope of our ambitions, the time cost of building systems, the complexity cost of systems already in motion, and the coordination and labor costs of the humans driving all of it. None of this is easy, and much of it is hidden well beneath the surface, out of view of most software consumers.

Indeed, it is a frequent gripe of game developers in particular that players rarely understand just how expensive it is to build a game to any high standard.

In the case of Stellaris, the business model requires at least a handful of engaged players to grasp these tradeoffs, and the game’s underlying systems, well enough to have a conversation about making changes and fixes.

Only by having informed dialogue with the community could Paradox Development Studio hope to learn what they need to make the game have lasting business value six years running. A game that no one wants to play isn’t a viable commercial enterprise.

Their solution? Like many indie games, Stellaris publishes developer diaries. These represent an exhaustive body of regular dispatches from the code mines where the game is constantly reborn, revealing everything from the high level goals of a new release to the underlying minutiae of the development process. As of this week, Stellaris devs have written 279 dispatches, posted to their forum, where fans of the game can respond.

Dev diaries provide a tantalizing preview of upcoming adjustments to the game, which builds interest and even stimulates participation in betas and previews, when necessary. The diaries describe changes, fixes and replacements to game mechanics, show off new UI elements, and explain the rationale for changes and investments.

While only a small proportion of the game’s player base reads and engages with the diaries, the ones who do understand both the developers themselves, and their output, on a level that’s rarely seen in the software business.

This opens the possibility for communication and feedback with much deeper shared context between the most invested community members and the development team. As changes are in-flight, discussion in response to dev diaries allows the team to gauge sentiment and interest, while players can ask questions and learn more about goals and hiccups.

The result is a fruitful venue for dialogue and a community that can be as informed as it wants to be. This matters in a multiplayer strategy game. You need people eager and willing to participate, or there will be no one for new customers to play with.

Broader community lessons for all projects

“Community” is a frustrating, poorly understood concept in technology spaces. It’s not stickers or t-shirt guns. It’s not a thing you bolt onto a conference. It’s not a thing you can buy.

Community is the sum total of people who are invested in the success and fruitful application of a project, as well as their bonds with one another. Community emerges around a project when that project’s values and ambitions are shared by a larger group than just its developers. Community could be measured in the volume of people who would have a genuinely shitty afternoon if they learned your project was dead, as well as the resulting acts of commiseration between them.

In the 60’s, when it seemed Star Trek might die, letter writing campaigns to NBC bought the show extra life. After the show’s cancelation, the community of people served by Star Trek’s vision of the future lived on, organizing spontaneous conferences to discuss the show, and eventually, to meet its stars and creators.

Not everyone is making Star Trek or Stellaris. But if you want your project to punch above its weight, you need to build the ranks of people willing to work for its success.

Developer diaries are a powerful lever on this point. They create a regular cadence for project storytelling, they provide context around your decisions, they invite people to engage you with ideas and feedback—some of which will be grounded in the exact constraints your diaries have explained!

This creates a basis for relationships. Not just between you and the people who you hope will care about your project, but between those people as well. It’s an opportunity to create a lingua franca of the project, creating bonds between those who are similarly excited by its progress and intricacies.

Without concerted storytelling effort, the work of building software is invisible, even in the most open source of contexts. Your commits and files can only tell part of the story. Sometimes the most interesting code is the stuff you chose not to write. Developer diaries are an opportunity to reveal those decisions.

If you want a base of truly invested community members, literate in the larger philosophical and strategic underpinnings of your work, it’s worth exploring how a developer diary practice could serve your project.