Daily news, dev blogs, and stories from Game Developer straight to your inbox
Sponsored By
Should your game be released on early access?
Let's say you're a small indie studio thinking about releasing your next game on early access. What production and business factors should you consider? This post looks into what you might want to think about when checking if early access is right for you
10 Min Read
First off, it's difficult to talk about this kind of thing without first outlining the kind of studio that wants to attempt early access. So for the sake of argument, let's say we're dealing with these factors for your studio/game:
You want to create a game with complex, interlocking systems. If the game were built using a traditional development model, it would require a significant amount of QA to bug fix,
You're a small studio of 10 people, and
With your previous game, you missed 60% of your internal milestone deadlines.
This is a quick snapshot of the key factors that may affect feasibility for early access. Now we'll drill down and ask some tough questions.
Since this is the first time the indie studio is attempting early access, you would first need to check if this model is realistic for the team. There are two major questions I would want answered to see if early access is feasible:
Why did the team miss so many of its internal milestones on the last project?
Does the team have the resources to handle the new processes required to successfully deliver an early access project?
MILESTONES
Regular and impactful updates are critical to the commercial success of early access. These updates also prevent the project from languishing in development indefinitely. This is why you need to ensure the team will be able to hit their milestones reliably.
There are any number of reasons why a team might miss its milestones, some of which include:
poor allocation of resources – often solved by logging tasks properly and holding regular retrospectives,
failing to include tasks in the backlog – often solved by setting clear goals defined by a project roadmap, and
unclear design direction, which can result in scope creep and wasted work – often solved by devoting enough time to defining the major design goals with the help of design sprints (a design sprint is very different than a regular production sprint. For a great resource on the subject, look up Jake Knapp's book, Sprint).
The producer would need interrogate what led to the team missing their milestones and alter processes to prevent that from happening. It's important to address why the team missed its last project's milestones even though the next set of milestones will be quite different for an early access game. Gaining a clear understanding of how a team delivers updates – no matter the model – will benefit future projects.
If there is no clear reasons (or too many reasons) for why milestones were missed, then early access may not be feasible. It is critical that milestones be met in early access - your community is watching.
NEW PROCESSES
The previous project was developed using a closed development model. You need to make sure the team has the resources to handle new processes related to early access. I would suggest the following major changes/considerations:
Define the design goals for early release differently to how you would for a closed development game
Create a comprehensive event tracking, analytics, and reporting system (there is a wonderful GDC postmortem for Subnautica, where Jonas Bötel discusses this in detail)
Align marketing and community management with our regular updates
Design Goals
I would break up design goals into three sections: design for initial release, iterative design updates, and the gold release. (Note: I am not going to talk about what follows the gold release, since that portion would be similar for closed development vs. early access). For the initial design, the scope needs to be large enough such that players can enjoy the core gameplay loop for an extended period of time (several updates following initial release). It would also be worth having some experimental elements in the initial release as well, to gauge players' reaction and feedback on how those elements might be refined.
For the iterative releases, the added scope would need to be small enough so that updates can be delivered every 4-6 weeks (ideally). More frequent, smaller updates perform better than larger, less frequent updates. That's not to say larger updates aren't welcome – they would just need to be developed concurrently with more regular updates. Scope decisions for iterative designs would come from a combination of internal design decisions and feedback from the community. The process would be to refine what works, change or cut what doesn't, and add in new elements for the community to test.
Lastly, the gold release is largely determined by the commercial success of early access. Generally speaking, most early access games don't see a windfall of money when it's first released – it's normally a slow build. That means there must be enough cashflow to ensure the early release has enough runway for a chance to gain momentum. If the game does not perform well, despite regular updates and marketing, then the remaining budget should be spent on locking the scope and delivering the gold release. On the other hand if the game performs so well, the scope either needs to be defined and locked with milestones set to deliver a gold release, or you might consider implementing a schedule that fits a games-as-a-service model. While it's a great problem to have that your game is so popular in early access, you have unlimited funds to continue development as GaaS, your team still needs to ask themselves if they want their studio to be locked into this game indefinitely.
Tracking System
Devoting programming resources to add in a robust analytics and reporting system (similar to what Unknown Worlds did for Subnautica) would greatly enhance the iterative updates. Unknown Worlds added in a brilliant system that tracked as much player behaviour as possible, and gave them an in-game tool to provide feedback. A tracking system like this offers the following benefits:
you can identify and change elements players do not enjoy
you can identify and refine elements players are enjoying
you can cut or change decision points that lead to design branches that few players are exploring
you can spend less time in design meetings speculating about changes to scope (it's a decision making aid)
makes bug fixing more efficient
Ultimately, a tracking system can help provide updates that have the biggest positive impact on players. It determines what the game will be and what it will not be, allowing the team to lock the scope much more quickly.
Marketing & Community Management
Marketing would set up a content schedule that aligns with the initial release, iterative updates, and gold release. The role is spread over a longer period of time in an early access model, but it has the benefit of regular shareable updates and fewer concerns about press embargos. The critical thing for marketing is to draft a content schedule that accommodates a variety of iterative updates (ex. one update may have fewer art assets to share). For community management, the tracking system would be invaluable. They would see clearly what players are and are not enjoying, and share that knowledge with the community. They would also need to ensure players are communicating on the right channels, so as much data can be funneled back as possible. For Twitch streamers, the partners you seek will change over the course of development and with each update. The team would need to determine which streamers will be involved at which points, saving bigger names for the more significant releases and as the player base grows.
FEASABILITY
Are these new processes feasible for a team of ten? To know the answer, you might consider the following questions:
Do you have a plan if key members need to leave for a significant amount of time during the iterative process? Churn happens, but if key people leave during the iterative updates, that could delay releases. It would help to make sure the iterations can be delivered with a moderate level of productivity, so people aren't leaving because of burn out.
Do you have a cashflow plan for what an unsuccessful, satisfactory, and successful early access project looks like? You would need to pre-plan the minimum number of updates following launch, plus anticipate how much it would cost to deliver a gold release. For the gold release, the larger the scope becomes, the more expensive it will be to tie up loose ends and deliver. Expecting the initial release to finance future iterations is risky.
Does your game have a suitable core loop that lends itself to a substantive initial release as well as impactful regular updates through early access? Some genres lend themselves better to early access than others.
Do you have enough nice-to-have ideas that extend beyond the core loop of the game? A big advantage of early access is testing out experimental features with an audience and gauging their reaction. You should have a number of those designed, and possibly design others once you receive feedback.
What is the minimum amount of time you need to deliver impactful updates regularly? The shorter, the better, but it's a purely determined by how much content the team can deliver. This is probably one of the more difficult questions to answer until early design documents and prototypes have been made. This is something that may also change once you receive player feedback that affects the scope. It might be worth running several sprints leading up to initial release, to get a sense of how much work the team can produce in a given time.
If the game involves a lot of writing, what will a realistic editorial schedule for initial release, iterative releases, and leading up to gold release look like? This is also a difficult question to answer, since the plan may change based on player feedback. However, the writers should spend time anticipating the decision branches/characters/game events that do and do not resonate with players so they can refine their writing in subsequent releases.
Does the programming department have the resources and understanding to deliver a tracking system alongside the initial release, then likely have time to iterate on that system throughout future early access releases? This is an important – but significant – added workload for the programmers. This is something the producer would probably want to muck into, since it's possible knowledge and workflow related to analytics falls outside the current expertise of a small team.
Can QA feed into the tracking system, to ensure it covers all the data points you need? They will be involved earlier than they normally are in the process. With early access and a solid tracking system in place, QA would shift more towards the front and middle of the project. This would affect cashflow.
Does marketing have a comprehensive content schedule in place leading up to initial release, during iterative releases, leading up to gold release, and following gold release? While a schedule can be locked leading up to initial release, marketing will need to remain flexible throughout the iterative releases, which can be demanding. You would need to anticipate what releases might look like following the initial release so marketing can prepare.
Can those responsible for community management be key team members in the tracking system's development? Like QA, their input will be integral to shaping what the tracking system becomes. With analytics, there are many data points that can be gathered that will have absolutely no use, so you must ensure that each data point is statistically meaningful.
For the most part, these questions are just challenges to be overcome, but if some of these are such big challenges that you can't deliver some of the new processes outlined above, then early access might not be a feasible solution.
CONCLUSION
Early access is a highly effective way to develop a game, especially considering how actively engaged your community can become throughout the process. But it doesn't work for every game and every team. A much bigger studio may have the resources to deliver early access more easily, which is why I chose a small studio as our test case. A poorly managed development cycle or poor budgeting can lead to a game languishing in early access indefinitely.
Hopefully these considerations help you decide if early access is right for you. I'd be interested to hear if you have other questions you might ask yourself before jumping into early access.
Read more about:
BlogsAbout the Author(s)
You May Also Like
Latest News
Trending
Featured Blogs
