上QQ阅读APP看书，第一时间看更新

Scoping a Game Project

In this chapter, we'll teach you the concepts and relationships between a game's overall scope, its structure, and its content. We'll explore real-world examples and help you build an understanding of how to better document the size, complexity, and dependencies in your game, as well as to help you estimate your tasks.

The game's scope is a term used to define the project's perceived size and complexity. Without knowing the scope in advance, any production scheduling, costing, and staffing would be nigh on impossible. The scope is usually well defined by the time you wrap up the first version of the game design document.

As a game designer working on establishing the initial scope, it's your responsibility to list all of the game's features, functionalities, and systems, as well as to approximate the entirety of the game's content. This includes the quantity and complexity of gameplay mechanics, playable levels, missions, cutscenes, storylines and dialog, sound effects and music, playable and unplayable characters, weapons, power-ups, items, and so on.

Once the project enters production, you're likely to keep using your scoping expertize whenever you work on a new feature proposal or design revision.

It's always good to make sure your ideas are not too costly or beyond the possibilities of the technology or the team (constraints can channel and boost your creativity) but do not overthink the scope too early! Writing down the scope only makes sense once the structure and core gameplay ideas are well defined.

Beware of feature creep! Sometimes less is more; deciding what to remove is harder but more important than dreaming of new features. The term feature creep is often used when describing scenarios (or even whole projects) in which we attempt to resolve our problems and make the game more compelling by adding more and more features and content, rather than working out the issues living deep within the base game systems and mechanics. Knowing what to keep and what to cut is an essential skill for any game designer. Changes on paper and during prototyping are the easiest and cheapest to make. Don't be afraid to propose cuts early on, as later may end up being too late.

After the first drafts of the GDD (game design document) and TDD (technical design document, usually maintained by the lead developer) are finalized, the representatives of various disciplines from your team and studio will be able to estimate the amount of time needed to deliver on the project. This, in turn, allows the producer to create and agree upon the schedule and budget.

Since game development is highly unpredictable, you can expect the scope and estimations to be frequently revised and a 20-40% uncertainty buffer added to each estimation (some people go as far as to double their initial estimates).

On a side note, it's important to acknowledge that in certain projects you could deal with continuous iteration. This means that your scope will stay relatively undefined and flexible for the duration of the project. Such scenarios are rare, require clear short-and mid-term objectives, and should not become an excuse to generate an unsustainable amount of work for yourself or others. After all, even if time and resources are not an issue, you rarely want to spend ten years on a single game, only to have the entire industry move towards a different direction, distribution platform, and technology.