Sponsored By

Opinion: On Time and On Budget

In this reprinted <a href="http://altdevblogaday.com/">#altdevblogaday</a>-opinion piece, Relic Entertainment senior AI programmer Jesse Cluff introduces the concept of Scope Plans and explains why developers should use them to build their game's core fir

Jesse Cluff, Blogger

July 18, 2011

4 Min Read

[Relic Entertainment senior AI programmer Jesse Cluff introduces the concept of Scope Plans and explains why developers should consider them to focus on their building their game's core first, in this #altdevblogaday-reprinted opinion piece.] I'd like to talk about something near and dear to every developers heart: not having to work weekends. Sorry I meant to say: 'shipping products on time and on budget'. Now, there are many factors that can result in things going wrong with the schedule for a project. But most tend to be related to either the speed at which a team is working or to wasted work. The former is quite complicated, dealing with pipelines, build processes, ease of use of certain critical systems, iteration time, etc. So, I'm going to talk about the latter. We do generally try to design a game that is achievable within the time and budgets we have (though some would question even this). This isn't really dealing with that aspect of planning (the total work to be completed), but rather the way that work is broken up. Due to our optimistic natures and desire to exceed ourselves, we tend to attempt too much, so inevitably we must reduce scope at some point (or many points) throughout a project. In my 15+ years in the industry working at such studios like Radical, Rockstar, and Relic, I have never once seen a plan to deal with avoiding wasted work, something I'm going to call a Scope Plan. Scope reduction (aka 'cutting stuff') is almost always done in an ad hoc manner, and almost always involves cutting things that have had significant resources already devoted to them or results in things being cut we really want while keeping other things we don't really care much about. Why would we keep things we don't care about? Well usually because they are already pretty much done, or they are integral to the story, or maybe they represent a core game mechanic (and the other feature/unit/etc that we would prefer to take its place is far from finished). Whatever the case, we shouldn't be doing scope reduction in this way, we should be cutting stuff according to a plan, and we should be building stuff with the expectation that significant portions of the design will be cut. In order for this to be done easily, there should already be a Scope Plan in place from the start. This plan will allow us to focus on the core subset of the game first – the portions of the game that if done to high quality would result in a game to be proud of (if a little short and lacking some variation). Once these portions are well underway, the ability to expand scope into the next scope layer will be more easy to assess. Even if these latter areas are eventually cut again, less work will have been done on them. The most important aspect of this though is that we only cut 'extra things', we only cut things we can live without, we only cut things that aren't integral to the story. We are able to meet schedules and stay on time and on budget by decreasing scope rather than trying to cram development time and resources into a limited timeline. A practice that is rarely effective, is certainly not very efficient, and takes a toll on the team and possibly the company as a whole. We are often forced into trying to complete more than is possible because everything left to do is considered 'core' or is already at 95% quality. A whole title at 95% quality still requires a massive amount of work to finish and all of the cuts at that point are extremely difficult to make. The basic idea is very simple though. Every major system that will influence scope needs a scope plan (number of units, number of levels or encounters, number of weapons or abilities, story, etc) in its initial design to be approved. And all of these scope plans need to agree with each other. For example the core story scope must only involve elements from the core level scope and core unit scope. This will make the story design more complicated of course as it must cope from the start with the addition of units, NPCs, and entire levels, but it's very doable, and will make the process of scope expansion and reduction relatively painless and straightforward. [This piece was reprinted from #AltDevBlogADay, a shared blog initiative started by @mike_acton devoted to giving game developers of all disciplines a place to motivate each other to write regularly about their personal game development passions.]

About the Author(s)

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like