What you should know before choosing open development

Opening up your game to the public is always a scary thing. We all know first impressions matter, and that we only get one shot at them.

And of course, it's even harder to make a game perfect -- even most AAA titles these days launch with a Day One patch! So why then, have so many companies pivoted to an Early Access model?

Early Access is a relatively new approach to development, with the first 12 Early Access titles launching less than a decade ago in March 2013. From there, Early Access games took off. You're probably familiar with Valheim, Splitgate, or Baldur's Gate 3. These are all titles in varying stages of development but are playable now by the public, warts and all.

With this approach paying off for so many developers and publishers, we now have a series of 'cousins' to Early Access. You've probably heard terms like beta, demo, playtest, and open development. At their core, each of these approaches is the same: it means getting your game into the public's hands before it's done, polished, or finished.

While this approach benefits the game, it can also become a hindrance to the team, trapping them in a state of "it's almost done!" forever

So why do it? How do you streamline and optimize your team for the process? How do you talk to your players? We'll take a look at all of this and more in the following graphs, but the first thing I want you to think about is the importance of having a vision for the finish line.

Early Access allows developers to tweak and polish their work for as long as they want before reaching version 1.0. While this approach benefits the game, it can also become a hindrance to the team, trapping them in a state of "it's almost done!" forever. That's why you must know where you're going when choosing open development by:

1. Creating a timeline for your game's updates.
2. Prioritizing the features you want to test and improve before launch.
3. Being realistic about how long each objective will take to accomplish, and being prepared to delay your timeline as needed based on player feedback.

We chose open development because our game, Galahad 3093, had to meet player needs at launch, not after, as it required robust multiplayer features. To do this, we began open development with a playable base game, a checklist of features needed before launch, and a commitment to regular updates.

Each update, players went hands-on with the game, which at the start only featured one map, one game mode, and a few dozen customization options. Each game update responded to player feedback, while also introducing a feature from our checklist. With each update, the core experience continually improved thanks to player feedback, and our feature list grew more and more "launch ready."

Sounds simple, right? It isn't -- and one of the biggest challenges is how to facilitate, receive, and filter that player feedback in the first place! That brings us to the next and maybe most important part of open development.

External and internal communication

External communication fuels open development, but it can be tough because the general public has very little idea about how games are made.

The first step to remedying this is by being honest and regularly available to your players -- and educating them in the process. Keep them updated on the game's development process with blog posts, Steam updates, and social media. Get into the weeds if you have to!

It's better to arm your community with the reasons, rationale, and thinking behind development than to keep them in the dark. In turn, this makes for better feedback! Most people who respond or ask questions are people who already care about your game, but do your best to engage with everyone. After all, you want your fully-launched game to be as broadly accessible and fun as possible.

The importance of community management

As you educate players through your frequent, honest updates, you will build a community, which requires both attention and nurturing. A healthy Early Access community is engaged with your game for a long time, and staying on top of their questions and concerns is a lot of work.

This can't be neglected or deprioritized -- it has to be someone's job (or at least a big part of someone's job) to monitor feedback and engage with players. This means you may consider hiring a community manager much earlier than you initially planned, so you can focus on the game's development while they focus on collecting, collating, and prioritizing player feedback.

That's a huge part of the community manager's job: separating signal from noise. It will be the community manager's responsibility to be the middleman between the players and the development team. If you're lucky, your community will be filled with passionate players, but not every piece of feedback can or should be treated equally.

Sometimes the first comment isn't the root of the issue, and it takes conversation to find the root of the real problem. That's why it's important to align and communicate your vision for development with your community manager, so they can both articulate it to the community, educate them on your internal processes and pipelines, and engage with them to get the most useful feedback. Otherwise, how is this person going to know what information is worth flagging to the team? Or what feedback necessitates further investigation?

As the middleman, the community manager must maintain constant external and internal communication to understand what is being addressed in the game, what will come later, and how the development timeline has changed. This information should be shared with the community to set expectations and avoid blowback around delays.

Another challenge your community manager must tackle is onboarding new players. Not only do new players need to learn the game, but they must also learn the game's status in Early Access. How else can they provide helpful feedback? An Early Access FAQ, Steam forums, and digestible blog posts are helpful resources to share with new players, or else your community manager will be bogged down with the same questions every time a new player checks out your game.

We learned this lesson the hard way from using Discord for external communication. The team loved Discord for engaging with players and encouraging regular feedback and questions. However, Discord does not preserve information well for later audiences, which is why we also recommend forum options like Reddit or Steam for players to reference for recurring topics and ongoing updates.

It's better to arm your community with the reasons, rationale, and thinking behind development than to keep them in the dark

As a community platform, Discord can also be insular and intimidating for new players to use. It's important to establish respectful community rules from the start and appoint trusted players as moderators to foster a welcoming environment. Creating a supportive community will help your game as well, as your most passionate players will feel encouraged to help new players.

This community approach helped Galahad 3093 address the skill gap that formed during open development. The game built a passionate group of players over several months -- and because they had more game hours, these players ended up being far more skilled than any new player could hope to be. Without skill-based matchmaking, we relied on our supportive community guidelines to create a welcoming space for new players. Our hardcore players understood that if more people had a good experience with the game, the game was more likely to succeed at launch.

Have a solid development roadmap

And to reach that launch, you of course need the third and final key component of Early Access: development. To succeed here, you'll need to follow your plan from step one, focusing on regular updates that improve the core experience and add requested features.

Prioritization is key in your plan to avoid expanding your game's scope to an untenable state. Simutronics committed to a weekly cadence of updates to deliver consistent, meaningful changes at a manageable rate. The weekly cycle kept the team on task and forced us to choose the most important feature updates, balance changes, and new content for the next update. We did not have time to waste on unimportant tasks.

Prioritization is key in your plan to avoid expanding your game's scope to an untenable state

A regular cycle of updates also helps minimize mistakes. When Simutronics set its sights on the next weekly update, unfixed bugs were at the top of our work-tracking software. We didn't allow ourselves to procrastinate bug fixes, which helped us maintain a stable pre-release game that didn't turn off new players.

Since Simutronics is very morally opposed to burnout and crunch time, prioritization helped minimize the risks of those becoming a factor. Our commitment to weekly updates meant that any task could be pushed to the next week if need be. We'd rather delay a feature than work extra hours that strain team morale in the long run. Knowing your team's capacity and workflow when planning updates will help you avoid delays, but remember that your plan's timeline is never set in stone.

Another way to avoid delays is testing features early. Do not waste weeks or months on an addition that may not work or be fun. Prioritize the base elements of the feature, not the bells and whistles. Let your community go hands-on with the feature early, and use their feedback to help you identify which bells are worthwhile... and which whistles are not.

This approach to feature implementation will optimize your team's time spent polishing the game, allowing you to focus on your development timeline and stay on track for your full launch.

So before you start building that Early Access timeline, know that open development can be very rewarding if done right. You are committing to giving some devoted fans the game experience they are looking for.

However, you have to be careful that you consider not only their needs and wants, but also your own. Your community doesn't have the full picture of your vision. How can they when it includes a content roadmap, marketing plans, business models, potential partnerships, and more?

Players will always tell you what they do and don't like, and they'll suggest ways to fix those issues. Sometimes it's the perfect suggestion, and sometimes their solution just doesn't fit in your plans. Open development is ultimately about finding the compromise that works best for both the community and your team.