Good game design is frequently hampered by a failure to properly scope ideas which is exacerbated by a corresponding failure to course correct scope problems in relation to execution (how it’s done), consistency (how it feels in relation to the rest of the game), and overall quality (how polished it appears). In other words, our eyes are consistently bigger than our stomachs! I’m sure everybody has experienced this problem: an ambitious boss round that’s missing a lot of functionality, a level design that gets cut in half, a vehicle that controls like crap, etc. Uhm, well, ok, maybe those are just all mine!
A simple definition of scope is “a measure of the breadth and width of a game in terms of assets, resources, time, and ambition.” Assets are the individual pieces that are needed to make a game at a very microscopic level: models, textures, scripts, code, sound files, etc. Resources are the people, software / tools, money, facilities, and equipment needed to produce the assets. Time is an estimation of the number of hours, days, weeks, months, and years it will take to create the assets with the given resources. Ambition is simply a measure of how big the game idea is.
Scope can be an elusive concept for a lot of people. It’s somewhat of a mystical art combining experience (good or bad), analysis (measuring known quantities like time against features and resources), and good old gut feelings. I came up with this exercise to put scope into perspective for a class on game design. I suppose if you were ballsy enough, you could also email it to a lead or manager who may also be unclear on the concept! This is by no means a complete list of every factor that can affect game development, but it should be applicable to just about any company and project. Here’s how it works. Go through each category, pick the answer that most suits your project, and write down the point value for each of your answers. Ready?
• Schedule: some level of management (internal studio or external producer) allocates an amount of time that a project will take to complete. In a best case scenario, this is based on estimates provided by the team. In a worst case scenario, it’s an unrealistic amount of time based on budget or a specific release date.
o Does the schedule allow more than a year for production? +2
o Does the schedule provide a year for production? +1
o Does the schedule give less than a year for production? -2
• Team: a good team lineup doesn’t always assure a smooth development cycle or a successful product, but a bad team never amounts to any good. Teams with a history are often able to overcome unexpected challenges and adversity whereas greener teams may crumble under the pressure!
o Are you working with a seasoned team (multiple development cycles)? +2
o Are you working with a proven team (at least one development cycle)? +1
o Are you working with an unproven team (no shared development cycle for the majority of the team members)? -1
• Technology: technology takes time to develop. If this time is concurrent with the actual development of the game, then problems are guaranteed to occur when technology isn’t ready for production. Technical risk is most often mitigated by adopting existing, proven technology although this can also be problematic…
o Is the project using existing and proven proprietary technology? +2
o Is the project using licensed technology? +1
o Is the project using new, unproven technology? -1
o Is the project switching to a different technology? -2
• Platform: this is pretty simple. The longer a platform has been around, the easier it becomes to develop for it.
o Is the target platform a mature platform? +1
o Is the project a launch title for a new platform? -1
• Preproduction: preproduction is all about project planning and prototyping. This critical part of the development cycle helps assess risk and resources.
o Does the schedule allow for a full preproduction cycle? +2
o Does the schedule allow for a partial preproduction cycle? +1
o Is there no preproduction cycle? -2
• Ideas: original ideas are generally the hardest ideas to tackle whereas existing properties can remove some of the risk with established standards. Licensed properties are a complete crapshoot. Some offer a great deal of creative freedom while others throw the shackles on the development team. For example, in the original Sega Genesis Jurassic Park game I worked on, Steven Spielberg insisted that no dinosaurs die in the game!
o Is the game based on an existing property? +2
o Is the game an original intellectual property? +1
o Is the game part of a licensed property? -1
• Tools: a video game is only as good as its toolset allows it to be. Tools that provide quick iteration times are the best. Slow or buggy tools take time away from production in ways too numerous to mention (at least in this post). Ideally, every discipline (art, design, code, sound, etc.) has the best tools possible!
o Is there a full tools suite for all disciplines? +2
o Are there only limited tools? -1
o Is there no toolset at all? -2
• Company: this is a scary one! The lifetime of a company is no real indicator of how smooth the development process will go. Over time, experience and common sense at most companies take a back seat to office politics and poor development processes that have become ingrained!
o Does the company have a proven track record? +1
o Is it a new company with no track record? -1
OK, time to add your numbers and see where you’re at in relation to scope:
-14 0 +14
————————————————————————–
FAILURE! TROUBLE? SUCCESS
So really, you’d want all your projects to be somewhere between 4 and 14. If you have a smart team and a good schedule, then there’s no real reason you should develop a bad game with that kind of scope. If you average out to 0 with your answers, then it’s time to ask management some questions and see if you can’t get responses that bump you back up into the more acceptable range. Anything less than 0 should be cause for alarm. Hopefully you’ve reached this conclusion before you start developing the game!