Practical Game Design
上QQ阅读APP看书,第一时间看更新

Game content

In the context of scope and structure, game content refers to games that are designed to be experienced (or consumed). This would include things such as game levels, items, characters, abilities, vehicles, achievements, weapons, missions, and storylines. Since the main gameplay mechanics and rules are the essential foundations upon which everything is built, you generally do not treat them as parts of the game content. Instead, you focus on anything that builds upon your foundations, adds value, and increases the lifetime of your game.

In the case of a simple racing title, the content would include all of the tracks, cars, and car parts (including cosmetic items such as paint colors and stickers you can put on your car), as well as the breadth of available game modes (such as time-trial, single-race, tournament, multiplayer head-to-head, and so on). Sounds, music, and the story would also be included, but these components are admittedly less likely to make or break the product. After all, it's safe to assume that many players will quickly lose interest once they master the game mechanics and familiarize themselves with all tracks, cars, and modes, no matter how much story and music we put into the product.

A game designer is often faced with important decisions on the relationships between rules and content. Try to look well ahead and predict the areas that might change and expand. Think carefully about the following questions:

  • Is everything hand-crafted by the development team? Or will you use randomization and/or procedural generation?
  • Will you expand game content after the game is released? Which parts? How often and to what extent?
  • Do you plan to use user-generated content? How will you ensure its quality? How will you moderate it?

That's a lot to think about, so let's unpack the content-specific terminology and help you answer these questions!

Always disclose your intentions within the design specification of each game feature. Let's say you're working on a collection feature. Not knowing that the initial set of 10 collectible items will be later expanded to 100 can have very dangerous consequences. The entire user interface around the feature might need to be remade and the code for creating, storing and displaying these items rewritten. In a sample scenario with only 10 items, your User Interface designer may opt for using large, animated objects, but as soon as that number grows to 100 the inventory becomes hard to navigate and the game's performance suffers and all because the rest of the team were not prepared to support your final intentions. The art assets themselves might even go through an entirely different (and more systemic) pipeline once the aspirations for a large quantity are known. You could even end up using an art outsourcer or automating large parts of the creation and implementation processes!