How do you know when you’re ready to take a prototype into production with a bigger team? Or when you’ve prepared enough to start playtesting a live service game with external players?
These are tough questions to answer, partly because there isn’t much experience to go around. Dev teams typically need to stay small until an early prototype has been validated. A natural consequence is that most folks in our industry have never been involved in the early stages of a prototype that goes on to be expanded and refined by a large team.
I don’t claim to be an expert, but i’ve been fortunate enough to work on a few such projects. What i’ve noticed is that the team’s ability to make sound decisions and iterate quickly are more important than what’s actually on the screen – even several months or years into development (depending on scope).
When trying to redefine an existing genre or innovate toward a new genre, expect to spend at least a year answering questions that you would’ve thought were too basic to ask. The truth is we don’t have a very good understanding of what makes most mature game genres shine. No one’s ever sure that their unreleased game will hold up for ten thousand hours.
Most major titles essentially evolved from absurdly large sample sizes (thousands of prototypes?) with absurdly long play times (billions of hours?) poured into evaluating and refining and doubling down on working patterns. That’s not a design process. That’s straight up natural evolution.
But developing some sufficient measure of that understanding is half the “genre-defining” challenge. I think we’re trying to do two things here:
- Craft a fun game that’s complex enough to take players a long time to figure out
- Become the world’s most capable team at improving that game in real time before (and rapidly after) shipping.
If we release a game that’s awesome at first glance and throughout the first 100 hours, we’ll gain a lot of player trust and a lot of leeway to continue growing it. That depth is the first step toward making players recognize our expertise as developers, to establish a constructive relationship.
We’ll need to keep building upon that foundation under real time pressure from players (and from deeply engaged internal devs as our team scales up). Trust is much harder to regain than to maintain, so it’s important to avoid major mistakes that could undermine their trust.
All player feedback is valuable to some extent, but not all suggestions are. Sometimes we’ll have to pump the brakes a bit when heated discussions start jumping straight to solution space, before articulating the underlying pain points clearly enough.
Ultimately, dedicated players just want to know that the biggest fires are being prioritized. And they want to be able to follow the reasoning for any implemented solution.
To meet these needs, we probably have to become the world’s leading experts in our genre. I think that’s the right bar to set. If the established experts can’t solve a problem quickly, players will have to be somewhat understanding and patient, instead of demanding immediate (and short-sighted) answers.
This last part requires open communication. We’ll earn space to operate by demonstrating that expertise.
For any given problem, players will propose their own theoretical fixes, and they’ll want those suggestions considered. Hearing us explain how several potential solutions wouldn’t work because of unseen limitations or fatal implications, and why the direction we ultimately chose is sound will go a long way toward building confidence in the team.
Sometimes players will find perfect answers too. In fact, it’ll probably happen more and more frequently over time, until players are generating more viable ideas than our team can internally.
But the hard part is always evaluation. Our job is to separate the good suggestions from the flawed ones, quickly and reliably. So there’s no getting around that expertise requirement.
Of course there will always be the practical struggle of staying sane in R&D as we’re constantly swinging back and forth between “Oh no, we don’t know what we’re doing, let’s learn stuff” and “Oh no, we haven’t done anything in forever, let’s build stuff!”
Just remember that both phases are valuable, and genuine creativity requires cycling between them to some degree. Whatever game you think you want to make at the outset, trying to build it will almost certainly make you reconsider your theory.