Hello we’re Goblinz Studio, an indie game publisher specialized in Early Access & Open Development. We’ve shipped Dungeon Rushers, Robothorium, Sigma Theory and now Seeds of Resilience. All of them have been through Early Access.
This article is based on our experience with Subtle Games (Antonin & Alexandre, developers of Seeds of Resilience) and what we’ve learned from the production of this game. Kudos to them! Seeds of Resilience is out today!
What is Open Development?
It’s hard to give a hard-written definition, but I would say it’s when:
The game is buyable or free
There are regular updates at frequent times (weekly, monthly, etc.)
Players have some kind of power on how the game is developed (low or high power)
The studio is transparent about their processes
Some examples of Open Development are Dwarf Fortress, Endless Games (through Games2Gether), Neurovoider, Slay the Spire and Dead Cells. Pretty neat’o games huh?
There is a lot to say about Open Development, I will give simple tips & tricks that should empower you in this path.
I’ve worked on a dozen different game communities and I can say this is an important rule. If you’re secretive, your community won’t be comfortable sharing hard feedback with you. Same thing for discussing aggressively when you receive harsh feedback. Just remember to be cool with people, even if they’re “small players” and they’ll give it back to you.
We’ve found that the best update timing is MONTHLY.
This way you can have:
Buffer week: you push the update, gather community feedback and share things with people. Production is usually frozen during this week.
Production week: aka leave me alone I want to work. You have the peace of mind on focusing on the next update!
Testing week: this was the trickiest to find. This testing week give your developers and community some time for playtesting and debugging! It’s also convenient for localization community players that want to help before the patch is released. You can use the beta branch on Steam one week before Buffer week.
Content Strategy - Making ass-kickin updates!
The most important thing with open development is “What are you actually putting into the game?”. If you come to Open Development with a super fixed immovable schedule of what you wanted to do : YOU’RE DOING IT WRONG.
If you do this, it means your players have 0 impact on your development, and loose the “open” tag. They don’t need to lead the whole thing, just being there to support you with all the weight on your shoulders!
Choose a focus : innovation or improvement
Updates can mainly go 2 ways:
INNOVATION - You add new stuff to the game, it can be content, gameplay features, a better core loop or whatever.
IMPROVEMENT - You’re improving what’s already there! You make a better UI / UX, kill the bugs or improve the framerate. It’s also fine tuning the game even more. You may even be adding new languages to the localization!
you can do both, but sometimes it’s interesting to do IMPROVEMENT, because players often complain about bugs!
Content Philosophy : A bit for everyone
In game design, you have to make features for every path of the game : short term, medium term and long term. Your game needs to be good for the beginners, the intermediate and the veterans. This way: everyone gets fun!
That’s something you use in open development as well.. On every update, if you can add content for those 3 kinds of players, your current players will be happy! It’s a good constraint as well for making creative decisions.
Now we’ve seen the big lines, let’s move onto smaller tips!
Example of Hades update, with courtesy of SuperGiantGames. Just to be clear: we didn't work on Hades! They had a pretty cool update picture so I wanted to show it.
Tips #1 - Name and theme your update!
If you call your update Patch 0.17.0, players will think : “what the fuck is this shit?”. That look like a very basic advice, yet few people do it! You don’t have to give every patch a name. If it’s a monthly update with a lot of stuff in it, find a theme!
Finding a theme also empowers your creative decisions and processes. For instance we had a “Ingame Seasons Update”. This way, all the team knows that what they’re updating are to improve the sensation of Seasons.
It has beneficial side effects. You patch specific parts of the game, for instance you can make a “Good Tutorial Update”!. We did an update called “Agriculture & Sound Design”, where we revamped the whole sound design.
Another good side effect is that players will understand what’s in this new update, why they need to get back into it.
Tips #2 - Progress must always be visible!
In game development, it’s easy to get lost in backend optimization and tools! You gotta make sure that you always push something players can see moving and play. It doesn’t have to be the whole update with new stuff, but I’d say at least 25%. For the player, tools and optimization can be very abstract. For instance, a player that already had a good computer won’t see the changes
Tips #3 - Vacation Month
A “Vacation Month Update”, where you ship nothing is actually super interesting. First, you can take some rest (remember “Your community looks like you and your game”). Then, you actually have more time for the next update. It allows you to have several members of the team on different vacations time. You can also take the buffer week from Month N-1 and Month N+1 to make a bigger update.
Sum-up: Discuss, Work, Build Hype!
I hope you enjoyed the read, let me know if there are specific things you’d like to know about open development!