The Case for Steam Early Access

Boian Spasov

Steam Early Access gets a lot of bad rap at times. Gamers are certainly justified to criticize incomplete or abandoned titles and developers who don’t deliver what they promised. Still, our experience with Steam Early Access as developers has been nothing but positive and I am certain that it helped us make a better game.

Victor Vran was in Early Access from February 2015 till July 2015. Five months may not sound like a lot of time for a project that was developed for several years, but it was in those few months that the project grew more than in any other period throughout its development.

Can you have a proper release after Early Access?

Nobody out there knew about our game when we first released in Steam Early Access. This was, of course, our fault – we should’ve started with the marketing earlier. If you’ve opened our Steam forums on the first day, you would’ve found four threads titled like “Confused. Is this game like Van Helsing?” and not one thread that explains what the game actually is.

Thankfully, Early Access gave us the time to remedy the situation and things were very different on our actual release day five months later. By that time we had thriving Steam forums with many players that knew the ins and outs of Victor Vran and were more than happy to welcome newcomers and “very positive” user reviews with 93% user approval creating a very different impression to people that discovered our game for the first time.

There is one myth I’ve heard repeated several times – that you can’t have a proper game release after Early Access and that players, youtubers and journalists tend to ignore titles that were previously released to the public. I can’t speak for other titles, but this was certainly not true for Victor Vran. Our first few weeks after release were very strong both in terms of sales and press coverage and I think that the community contributed to this as several reviews commented that the Early Access players present the game very favorably in their reviews.

Communicating with the players

As with any relationship, communication is crucial and perceived problems will get worse if you stay silent. This is particularly true for the Early Access community that consists of gamers who want to talk with the developers and help them shape the final form of their game.

We encouraged the whole design team to partake in forum discussions, comment on our reviews and generally talk with the players as much as possible, even in-game. The programmers also got in touch directly with any user that experienced some kind of issue that we can’t replicate.

This was all very new to us and we’ve certainly made our share of mistakes, but in general we adhered to two simple rules that helped us avoid PR nightmare:

Never promise anything that is not yet set in stone
Never, for any reason, lie

So, here’s my advice: talk to your players, listen to them, act on their feedback, explain your decisions with logical arguments and be the engaged, communicative developer they deserve. Always keep in mind that they want the same thing as you – a better game. In the end, when your players know that you listen and respond, you will receive much more valuable feedback from them.

We imagined Bastion, they saw Diablo

Whatever expectations and plans you have before your game is live, Early Access will surprise you and change your priorities. People will see issues where you haven’t expected, they will be passionate about new features that you haven’t thought about or have previously dismissed.

We entered Early Access with the budget to develop several major features based on the feedback we receive. Before the game went public, we imagined it a title more similar to Bastion that the mainstream hack-and-slash RPGs. It turns out the users saw Diablo instead. Since the comparisons with hack-and-slash RPG kept coming, we decided to deliver what the user wanted, even if it meant reworking our core features.

We redesigned our leveling system from scratch because the players were not happy with the initial one. Our itemization felt too simple for a game of this genre so we introduced a crafting system and reworked several types of items (Demon Powers, Destiny Cards) to add more depth to the possible build variations. We added tons of quality of life improvements to the interfaces based on user suggestions. All endgame features we introduced were wholly based on user feedback and expectations.

Every single one of those decisions was received favorably by our community. Remember to pre-allocate the time for such features in advance – this flexibility will pay off in the end.

Beta testing, integrated bug reporting tools

We don’t have a large QA team. For previous projects we’ve outsourced QA testing. For Victor Vran we relied on Early Access as our primary platform for testing the game before official release.

We added integrated tools for feedback and bug reporting in the game itself. Pressing the F1 button anywhere in the game opens a form to submit a bug or feedback directly to our database. Relevant information and a screenshot are automatically included in the report. This feature was so useful to us that we kept it even after official release.

The response was immense. Closing duplicate and erroneous issues took some time but still there were tons of valid bugs and issues reported by our users during Early Access. In the end, Victor Vran turned out more stable and bug-free on release day than any of our previous titles that didn’t have the luxury of an Early Access beta test.

My Early Access cheat sheet

If you consider Early Access for your game, here is a recap and some extra food for thought:

Start with a plan. Release with a roadmap and share it with the community. Schedule some time to develop new features based on user feedback.
Build the core of your Steam community. Your first players should feel welcome and a part of the development process; this is why they are buying an incomplete game, after all.
Talk with the community! Encourage the dev team to join the discussions, even if this costs them some time during work hours. Announce upcoming major features in advance. Ask the players for their suggestions and ideas – “How do you think this system should work instead?”
Establish a pipeline for receiving and analyzing feedback and bug reports. Volume matters here – if many players are bothered by an issue it is highly probable that it is a major one and you should address it promptly.
Identify marketing messages that work for the all-important release day. Consider using your favorite Steam reviews as testimonials.
Iterate fast and update often, even if this means breaking your game at times. Maintaining a constantly changing live game is harder than developing a project that is not yet released to the public, but the benefits are numerous.
Don’t be afraid to experiment – players will be more forgiving at this stage and major changes will be accepted much more favorably during Early Access than after release.
Read all user reviews under a magnifying glass, and pay particular attention to the negative ones. Try to provide a developer reply to each negative review, even the ones with objectively inaccurate claims.
Watch how the players play your game. Play with them if the game supports multiplayer. Watch them on the Steam streaming service otherwise.
Have fun! The last few months before actual release when the game really “clicks together” are, in my opinion, the most rewarding period of the game development cycle. Experiencing this with thousands of players while your game is live in Early Access can be truly special!