Whether you are a designer, producer, artist, or programmer, scope dominates game development. It drives decision-making on every scale, makes or breaks production, and defines the relationships between team members.
I find scope, and how we deal with it, fascinating. For the purposes of this post, lets call an the act of dealing with scope “scoping”, and someone who pays attention to scope “scope-minded”.
Scope and Timing
Attention to scope is primarily dictated by production schedule.
Being too scope-minded in the early stages or a project can be stifling to creativity. It can lead you towards safe decisions and prevent you from thinking outside the box. This is why a common rule in brainstorming is “no ideas are bad”.
Yet as we all know, it only takes the blink of an eye for optimistic blue sky dreaming to turn into nightmarish overscoping. It’s an easy trap to think “the more we can stuff in for the deadline, the better”, but refusing to trim down often results in a lower quality product that lacks focus. In addition, poor scoping can lead to crunch and taking shortcuts, creating new design and technical problems down the road that end up costing more time than you saved.
The key here is to not stress out from constant changes, and to recognize that scoping is a reality of game development.
That’s not to say consistent underplanning shouldn’t be addressed, but attempts to force-fit a waterfall production into what is by nature an iterative task, misses the point. The better solution is to facilitate the iterative process. (“Facilitating iteration” is a massive topic on its own, so I won’t go there today.)
In healthy teams, what emerges from this reality is a rhythmic ebb and flow that feels a little like breathing. The ideal is to breath in, absorbing all the ideas and possibilities, keep what is essential, then breath out the excess. It’s never perfect but you keep at it and improve with practice. This rhythm is happening on every scale – for the full project, for each major milestone, and for each sprint.
Scope and Roles
Attention to scope is also dictated by your role in a team.
Designers lean on the side of pushing scope. They want the best game possible, so they are incentivized to push scope to the edge of possibility. But this is a delicate dance, because an overscoped design will just result in a worse overall product. I imagine that many creative directors (or other stakeholders with creative input) have very little grasp of scope, and rely on producers and programmers to rein their vision in. But the most effective and versatile designers are constantly balancing an open mind with an eye on scope.
Programmers tend to be be the most scope-minded on a task-to-task basis. They are the most invested in keeping the foundation solid, and will most directly dictate the production timeline for a feature. Programmers may still be ambitious and may get excited by designs (after all if they’re here, they love games), but the best ones seem to always push for doing things the right way.
On larger scales, designers and programmers can only advocate for changes to scope. Someone has to make the tough decisions, which brings us to production.
In a small company, production wears multiple hats. A single person can be CEO, producer, creative director, and manager all at the same time. With so many responsibilities to juggle, all they can do is listen to the different opinions from the team, take into account their own instincts, and make decisions on a case-by-case basis. Key to success is being an all-rounder that lives in all aspects of development.
But as a company grows, production roles become more specific, and eventually someone’s primary role becomes “scope police”. In the worst cases, this can result in fiery battles between teammates and disastrous stalemates. But if the team members in these roles have chemistry, you can get a healthy role-driven push and pull.
For example: Suppose a Lead Designer identifies an issue with the design and pushes for a big change, only to get a no from the Producer. At this point the LD can choose to push for a compromise, or harder for his/her way. Meanwhile the Producer can choose to continue pushing back, or give-in after some time.
With trust and respect, both parties will pick and choose their battles carefully, resulting in a much higher quality game that neither balloons out of scope nor corners itself into major design issues. The process might sound exhausting but it can actually be liberating; the LD is free to be more creative and trust the Producer to rein things in, and the Producer can be more conservative and trust the Lead Designer to push for what really matters.
For me personally – as a designer/programmer hybrid in a small company – I find myself juggling hats. The programmer in me always wants to scope down, while the designer in me wants to consider every avenue. And while I don’t have decision making power on the very high level, I find that this dual mindset is invaluable to bridging gaps between team members, some of who live on extreme opposite ends of the scope-mindedness spectrum. Fortunately, I enjoy the challenge.
Applying Scope to My Life
As I am constantly immersed in scoping, I can’t help but be scope-minded in my life outside work.
Some ways I am scoping down right now:
- I will steer away from large scope blog post ideas (like the “Feedback Loops” series), and focus on off-hand thoughts for the time-being. Occasionally I might write a long post organically (like this one).
- I almost started a side game project with a friend, but realized very quickly that it was drawing time and energy from my main work, so I am shelving it.
- I will focus my research and learning a bit. In addition to critically playing games, and my daily habit of reading articles/listening to podcasts, I want focus on developing my systems design toolbox.
Soon enough, it will be time again to reevaluate my goals and start dreaming up the big blue sky for my free time. But perhaps – like in game development – this is all part of a natural ebb and flow, and I just need to let myself breathe.