How To Know When Your Game Is ‘Done’
As larger teams and companies are diving into creating games and experiences, I often hear the question from teammates and leadership “How will we know when the game or product is ‘done’?”
The truth is, art is never complete, especially when so many products are live services. But setting proper objectives and constraints will help you know when you’re ready to ship, so your team can ship a game or product that doesn’t churn the players you plan to acquire.
Setting Constraints for the Team
Constraints help teams make decisions based on scope and timelines. So much creativity can come from a team when proper milestones are set.
Picture your product at launch. Make plans for your:
- Core loop
- Meta loop and progression
- Social strategy
- Monetization strategy
- Art/visual bar
This will help you break down each strategy into the minimum features necessary to accomplish your objectives in each category. Create a work back plan, progress on your tasks, playtest, and iterate.
Example of good constraints include:
- Design pillars to always test your decisions against
- Art concepts to identify what a final aesthetic might look like
Game Jams — The Ultimate Way to Practice Constraints
Game jams or hackathons are the best way to become skilled in setting constraints and understanding scope. They give you a dose of scope, understanding other people’s strengths and skills, and objective setting, in a limited time — typically 48 hours.
Participating in 15+ game jams throughout my career has certainly helped me empathize with my teammates and helped me align with my producers on the scope our team can commit to shipping.
Setting Objectives for the Team
I’ve worked on a few teams where we may have had milestones set, but the team wasn’t clear on the objectives for launch. It caused us to not understand what went right or what could have gone better once we launched, keeping us from aligning on a path forward.
It’s important to set clear, measurable objectives that allow your team to understand what they’re going to learn from launch. Or how they’ll iterate to get to that goal if everything doesn’t go as planned.
A good example of this could be:
We hypothesize that players will retain for x days if they stay in-game for 30 minutes.
It can be easy to look around at the market and see products that have all the features you’d like to include in your game or product. But in reality, those products had to start somewhere, and often if you take a look at where they started, they had only a subset of the features you see today.
I played World of Warcraft for years. When a vanilla version came out again years after it had been on the market, I played it and realized how much simpler Blizzard had shipped it out as.
The most important part is to realize that everything doesn’t need to be perfect in our day and age, but make sure to design features in a way that don’t keep your team from being able to implement long-terms plans or systems.