Keeping Up the Pace: 5 Principles for Fast-Moving Game Development
At Mighty Bear Games, we’re always on the lookout for ways to improve our production pipeline and process, staying fresh with relevant processes and approaches for our current projects.
I’d like to share a few of the principles we’ve been applying to keep ahead of the game, from my perspective as the Product Owner/Game Lead. Some of these are more challenging or uncomfortable than others, and I’ll be the first to admit that I need more practice at following some!
First Principles Thinking
Use a key metric as a guide — before starting on a game update or milestone, decide your overall goal.
What’s the most important and impactful thing you should be addressing in the game on right now, based on the available data you have?
If you decide for example that sending mid-term retention up to a new height should be the focus, every feature you work on should positively impact mid-term retention. Anything that doesn’t contribute towards this goal shouldn’t be in the plan right now. This can be tricky — you’ll likely have to push back features you were really looking forward to until they’re more relevant, but it makes more sense for the project to remain focused on the task at hand.
Just making this decision can be tricky. Maybe some of the team feel a new game mode is exactly what the game needs. Or you’re thinking that reducing friction and annoying “snags” in the flow of the game and addressing progression itself will deliver better results. As you’ll read later in this article, it is important to make an informed decision and see it through so that you can measure the impact later.
Repeat the Important Information and Always Provide a Reason
Share the first principle you’ve arrived at with the development team, along with the reason why. Get into a habit of repeating this information. Sharing information with the rest of the team is akin to planting a seed or setting up a chain reaction. The potential opportunities from repeating information cannot be understated.
- It can take a while for the impact on everyone’s work/workload to sink in. The more times something is said, the more “real” it is perceived as being — it can’t just be something said in passing if you’ve heard the same point five times in one week.
- Team members may have been away when the news was first shared, thus being inadvertently left out of the loop.
- Some of the team may have simply been occupied with other things on their mind and didn’t fully digest the information.
During my experience on previous projects I was more hands-on with, I would often only know the “what”, not the “why”— this left me ill-equipped to make decisions on the fly.
Having an understanding of the “why” allows everyone to make the right small decisions (of which there will be many) along the way, and reduce the chances of needing to go back and correct things later. These small decisions add up.
Recently, I’ve been striving to communicate with greater specificity, even when it involves tough decisions — not leaving anything up to interpretation. My goal is to contribute to a smoother and more efficient process for everyone.
The Iron Triangle
In the world of game development, especially in leadership roles, we often find ourselves fighting the triangle of constraints: Time, Quality, and Cost. It’s a delicate balancing act and one that often poses significant challenges. Over the past year, some of my most difficult experiences have involved trying to make plans work within the constraints of the triangle. How do we get the desired quality given the Cost and Time constraints we have? Shipping a feature that doesn’t deliver the desired impact towards the goal the team has in mind is an opportunity wasted.
If a feature has not reached the desired Quality range, it might make more sense to hold it back and give it a little extra time to be fully realized. Of course, there could be an impact on the Cost/Time dimensions of the triangle here. Consider the first principle of a feature, and don’t fall into the trap of the sunk-cost fallacy. Maybe it becomes clear that a given feature will never reach the desired impact and it is time to rethink rather than extend resources unnecessarily.
There have been times when we’ve needed to break the triangle to give a feature the impact it needed. We also revisit our processes from time to time to see if they could provide more Time or Cost optimization.
Process the Processes!
I was listening to a podcast (I wish I remembered which one!) earlier this year when I heard someone explain that the best process is to take away all processes, only adding what is absolutely necessary and even then, only adding it when there’s been a proven reason to do so.
Over the past few years, we have built our process with the best intentions — to ensure that no details get missed and that features are delivered as they should be. This often meant detail-heavy design documentation with a growing amount of content requirements existing simply because we had encountered a one-time problem at one point or another. This amount of “paperwork” was often preventing us from moving fast, since a Designer would need to go back and update a document with each review or iteration. We had started resorting to “Design Specs” — mini design docs which were extremely light on the details. As more documents were starting to use the Design Spec format, we realized it was time for a change.
We reset our feature design documentation and review process from scratch, reintroducing only the most necessary procedures.
The result of this resetting of processes is documentation that is now lightweight and easy for different stakeholders or team members to find the relevant information. We still include the most important process based on lessons from the past, but a lot of the legacy requirements are gone.
Our Design Documentation template shrank by over 60%. I’m not going to lie, it was painful to strip out so much, especially when we could still remember the reasons and context for adding each detail. But moving forward we’ll be able to implement a feature at a much better pace and be less bogged down by the paperwork. It was the right thing to do.
This optimization has allowed us to move from the initial design to the implemented version of a feature much more quickly. We’ll likely need to add a process back in here and there, but we’ll be mindful of keeping an eye on how the process and documentation expand in the future.
Be Paranoid, Stay Paranoid
I’m a paranoid person. I used to joke with ex-colleagues that my suspicious theories usually work out 80% of the time and I’d probably still stand by that. Unfortunately, I didn’t use to act on the paranoia as much — there are situations I can think of where I could have created a more positive outcome for everyone if I had reacted to a “hunch” I had. I’ve found the more experience I’ve gained, the more accurate these become — there are certain things I start to see coming from a while away. These days if I have a feeling something might go wrong or there could be a problem somewhere, I force myself to call it out — everyone on the team has this same obligation.
Because everyone can call out their concerns freely, this gives me a constant flow of potential problems to consider and work through — which should we act on and which we shouldn’t; we can’t react to everything.
If I consider a risk to be big enough, I’ll follow where this paranoia takes me. Maybe I’m concerned about a potential oversight on a newly implemented feature. Or maybe I think we should finish an important new feature ahead of the scheduled completion date because of issues we’re starting to see stack up where I can picture us missing our planned release date.
My advice to anyone would be to stay paranoid and think about what could go wrong, but mix that with a dose of input from people with more insight on the ground than yourself, and then make a decision. I really appreciate it when I share a concern with someone and they offer a completely different perspective; this could put me at ease. On the other hand, it could make me even more concerned that no one is concerned — at this point maybe I need to build a case for my concern and see if it pans out. If not it might be time to move on.
Closing Tip, Don’t Forget to Evaluate…
Implementing a large number of targeted new features based on first principles at a fast pace can definitely be impactful, but it is important to revisit these features and track the success they have (or haven’t) had. Adding the right mix of data points (eg. analytics) required to draw conclusions allows the team to quickly pinpoint the most impactful features and focus their iteration efforts on the right parts of the game.
