clock menu more-arrow no yes

Filed under:

How to do early access right

New, 3 comments

It may not work for everyone, but it worked for us

As I’m writing this, in three days’ time, Broforce will come out of Steam Early Access and enter the world as a complete game. It’s been a three year journey, and this is the third time we’d set a launch date within ourselves at the studio. Third time lucky, as they say! Standing on the precipice of final launch, somewhat sleep deprived, managing a scary list of "to-do"s and swinging wildly between elation, pride and terror, it seems like the perfect time to write a post-mortem of our experiences in Early Access.

Were we successful?

Writing an article on "How To Early Access" would imply that we’ve been successful at it. And I think it’s fair to say that we did traverse the choppy waters of Early Access fairly well.

We’ve consistently maintained positive user ratings throughout our years on Early Access — even reaching the top 10 highest user rated games on Steam in August this year, which blew us away.

broforce steam

Our monthly sales remained steady enough to keep our studio in business while we worked on the game far longer than we’d originally planned — even as we grew from five to 11 team members and moved to bigger offices twice. For us, this is the most overwhelming success we could have hoped for.

One thing we tried to avoid was ever issuing a game-breaking update, or releasing unplayable content. A large part of what makes Early Access so appealing to smaller teams is the direct interaction with the community — it gives us both the opportunity to receive critical feedback on gameplay, but it also helps our small team identify and squash minibugs before launch, as we don’t have huge QA teams like larger developers.

But the downside to Early Access is that sometimes it’s abused, and developers or publishers issue pre-alpha content that’s barely playable. Charging money for broken content on Early Access only serves to create a distrust between gamers and developers. We worked really hard to avoid creating that perception with Broforce.

So How Did We Do It?

In July 2013, we were #2 on Steam Greenlight with 82,000 votes when we were Greenlit and entered Early Access. Our time in Greenlight taught us innumerable lessons about what worked (and what didn’t) that we carried through to the Early Access platform. Our basic triquetra of principles have been:

1. To have a fun, playable beta for our supporters at all times.

This meant each update had to be rigorously tested by our team throughout each monthly update cycle. An inner circle of core friends and fans helped to make sure the majority of game-breaking bugs had been outed, and that we’d need to work through the next day or two immediately after the update to fix the ones that slipped through the cracks. It also shaped our development in that we couldn’t add anything that would break or change the game completely, so updates had to be vertical slices. Which, thankfully, suited the kind of game Broforce is.

To accomplish this, we had a closed group of fans on Steam called our "Beta Testers" group who tested each build for us before it went live. Setting it up was really easy — we simply asked for volunteers, and gave those people the access code. Whenever we had a new "stable" build, we'd upload it there first, and they'd have at it. It proved incredibly valuable.

We'd never have been able to test Broforce so thoroughly without them. Their names are in the credits at the end of the game — they are our superstars.

2. To update regularly and often.

By keeping our updates fairly regular and within several weeks of each other, we provided both the press and our backers with new, fun content to explore. There was a visible track record of forward development, and new backers could immediately see we were constantly working on the game. This inspired confidence in new backers, and loyalty within the Broforce community.

The press also had newsworthy content to use with each bigger update we put out, so we
stayed current and kept growing. With our first few updates, press had experienced playable, fun content being added to the game, and that established a sense of trust — helping Broforce remain worthy of the press’ attention. The confidence that they could jump back into the game and have fun with the new content lended to a constant flow of articles, exposing Broforce to new audiences throughout development.

3. To keep communicating with our backers.

We’ve always taken fan feedback seriously, and this continued to be a cornerstone in our
development strategy. Our team made time (somehow) to interact on the forums regularly — we thanked people for bug reports, we encouraged critical feedback, we implemented ideas where we could. Our fans grew to know that we were listening, and that their opinions mattered.

What Could We Have Done Differently?

We set ourselves the lofty goal of updating the game once a month. The idea was to keep
development moving forward so we could finish the game, and keep press and fan interest up while we did so, by regularly providing them with exciting new content. Mostly, we achieved this — but it was often hellishly difficult to keep crunching on one deadline after the next.

The pace we set for ourselves was brutish, but there was so much we wanted to fit into the  game and every small slice we outlined for the next update invariably expanded as the days  slipped by and more "we have to do that!" ideas crept in. We’d start the new month barely recovered from the last frantic push to get all those awesome ideas in and working for the  previous update, with a new list of "to go back to"s and a longer list of bug fixes, just to repeat the cycle again.

The thing is, Broforce is a product of love, made by a team of creatives who constantly push themselves to do better, surrounded by a community of fans who are just as passionate about the subject matter as we are. And it’s hard to set boundaries on that. We consistently came up against the dynamic struggle of doing our best, and doing what we can within our resource limitations.

Generally, it went something like me saying "We don’t have time for that", and the team saying "Sure we do, we’ll just work twice as hard". Burnout is a real thing (which is kind of a slogan in our studio), so managing each team member’s ambition to do their best for the project, in the time allocated, while not killing themselves, was and will always be a constant tug of war.

We've never lost any team members to burnout, considering how hard we've worked at times, we've been really lucky. We've gone through moments of job satisfaction dropping to zero, for example when someone has pushed through without sleep to get something in the game, only to find out it doesn't work (i.e. it isn't as fun as we thought it'd be, or it doesn't fit with everything else the way we expected it to), and having to sit down and rework it in time for an update.

Mostly our close-to-burnout experiences have been solved with R&R right after a hectic crunch.

During our most difficult phases, I arranged a lot of fun team activities, trying to do something different each time — dinners out, full body massages, shooting practice, office prizes like new gaming consoles, etc. I'd also walk around the office feeding everyone multi-vitamins, and tried to enforce days of rest here and there.

One of the best decisions we made for the studio was hiring a chef to cook the team healthy, balanced lunches and dinners. Team members contribute towards it and the studio covers the rest — it definitely helps keep energy levels up during stressful times. And since we moved into the current studio / dev house at the end of last year, we now have a sauna that the guys enjoy using to recharge their batteries.

These things cost money, but again the other lessons discussed above allowed us to keep a steady revenue stream, and the investment into the emotional well-being of the team was worth it. Not everyone will have that option, but it was another indication that our strategy was working.

We’ve gotten better at this. We’ve learnt to scale down ideas (a little), work (a lot) more effectively, and not to over-promise (as often). We’ll never be perfect at it, but I’ve seen incredible growth in our team in all of these areas throughout the Broforce development journey. It’s the kind of thing you can only get better at through experience, and I don’t see us stopping making games we love any time soon, so at least there’s no time limit on that.

With three days left of this incredible experience, I’d like to close with a cheers to the brotastic Broforce community who has helped us become better developers, and made Broforce a better game. A cheers to our benevolent publisher overlords, Devolver Digital, who helped us reach heights we didn’t dream of back in 2012. And a third and final cheers to our team. We did it, bros.