Game Development – Introduction: Week 4
|
Last week we handed in our Game Design Document and (since it ate 25 hours of my time last week, leaving little time for anything else) that’s what this post will be about (
A Game Design Document is basically the game in a document. It’s primarily for the project group, intended to be a comprehensive guide to the existing project group and potential new members about the what’s and why’s of the product, document design decisions and be the go-to document when it’s time to implement features and/or create assets. Now, we’ve often heard it said that “nobody” reads the design document, except perhaps the person writing it (if you are lucky). Now obviously, you want a design document that’s practical and useful to the team but even when that’s true, there’s still value for the designer in formalizing all parts of their game design into one cohesive entity before going on to do your one-page-designs/documentation of choice. Things that might’ve seemed obvious and given can prove to be less so when put next to the rest. So how did we go about creating this document for our game? Step 1: Layout We were provided several templates by our teacher and we took our cues from there. The first thing was to group these into sections that would cover all aspects of the game and provide clear indication about the type of information in that chapter: 1. Game Design (Concept, Gameplay) Game Design (not the most intelligently named section in hindsight): This section describes our take on our chosen concept and the basic gameplay from a player perspective, divided into (A) Player role and actions and (B) Player decisions and mindset. (A) describes the player’s role and what the player is expected to accomplish as well as the actions available to the player to do so. (B) (Since it is a strategy-based game), What decisions the player is expected to make during gameplay and what mindset we want to keep the player in while making these decisions. The purpose of this section is to quickly introduce the reader to concept and gameplay to give the reader a sense of what to expect in the sections to come. Technical: This is the most content-heavy section of the document, mostly intended as technical documentation for the team. Game States is a section that displays the different states of the game via flow-chart, followed by an explanation for each state and the transitions associated with it.
These descriptions include the conditions for both victory and failure for the player and what happens in both cases.
This is followed up by a section on the Graphical User Interface and HUD with descriptions of all components. Some of the components had to be finished on the fly (like the seed inventory) and look much better now (like the seed inventory, the seeds now have different shapes to make them more distinguishable to people with color blindness).
After that player controls, again with the picture + description for clarity:
The section after that is Characters, divided into Player Character, Plant Units (Including the player’s “base”) and Goblins (Including the enemies’ base). Illustration of an area-of-effect-attack: This is followed up with a section on statistics where all characters are assigned a number ranging from 1-20 on various stats like “Damage, Range, Fire Rate, Health, Speed”, descriptions of type and duration of special effects etc. Due to the fact that the project was and is lagging behind in the code department for various reasons, there has so far been little opportunity to playtest the game outside of the paper prototype. The numbers are therefore not to be interpreted literally but rather as indicators of the characters’ stats relative to each other and as guidelines to the coders when they implement the damage system. These statistics are accompanied by charts on the characters’ behaviours, more specifically how enemies and plant units prioritize their targets based on type (player, type of plant unit, type of goblin, base).
Level Design/Challenges: This section starts off with descriptions of the games themes (tropical forest, disrespect for nature, colonialization by an invading force etc) and what this means for the design of static objects and backgrounds in the game. It continues with a section on level layout (currently just one level) and an explanation on why it looks that way and how it’s intended to be used to challenge the player. Then come the gameplay scenarios. Now this one is interesting. The type of game we are making means that the way the player will encounter challenges is more based around “when” than “where” and divided over one level rather than several so the challenges are scenarios rather than different types of hurdles. This section is intended to explain what increasingly difficult challenges the player will encounter during gameplay and how the player will be introduced to the game mechanics. Remember that while writing this document, there was very little opportunity for playtesting. So, while constructing this section I tried to structure the scenarios in such a way that the assumptions made about player behaviour would be as few as possible (provided that they player is trying to play the game, not deliberately screwing around with it). In a previous section about player decisions and mindset the decisions the player is required to make are grouped into sections like deciding which seed to order next, then where to place it etc. The scenarios presented in this section are callbacks to these decisions, linking each decision to a scenario. The scenarios range from the player’s first introduction to the game, to encountering all different types of goblins, to the finishing assault on the enemy base. An example of this would be the player decision on choosing an unit type. This is a decision the player has to make throughout the game, based on the circumstances but the way the player first encounters this decision is after their first encounter with a melee goblin unit (which spawns the most frequently). The ranged goblin is the second most probable to spawn, after that the bombardier goblin, both with a ranged-type of attack. So one of those will be the type the player encounters after the melee type. The player will so far only have used the defense-type plant in combat, with a close-ranged attack. That will not be effective against these types of goblins, so the player has to figure out which plant unit is more suitable. It sounds very basic but getting it down in writing makes it much clearer how the game works and how a challenge is presented to the player. This section is a guide to the art style of the game with sections for the player character, backgrounds, static objects, plant units and enemies as well as the perspective and camera angle. The purpose of this section is to be a guide to the artists working on the project when creating new assets for the game. In hindsight, we could’ve included a section on the animation style as well. Audio: This section is a guide to the audio landscape of the game with descriptions of the general style as well as a list on necessary assets for the game. Aesthetic goals: This section is composed of the aesthetic goals for the game, divided into types of fun and success modes (for when these goals are accomplished) and failure modes (when the game has failed to accomplish the set goals). I took care to be precise in defining these goals to make them easier to test later. This section is relevant for all parts of the game as the aesthetic goals are benchmarks for the final product. Dynamics: As player behaviour has been expanded upon at length in previous section, here the focus lies on tying together the aesthetic goals under the types of fun that are tied to player behaviour (physical challenge – coordination and problem-solving – strategy) to specific game mechanics and behaviours that are intended to fulfil these aesthetic goals.
Congratulations on making it through all that text! As an extra bonus, here is an animation for one of the plant units that has been part of my SCRUM-sprint this week (no it’s not cleaned up yet):
If anyone is interested in looking at the actual document, leave a comment and I’ll try to make it happen. Cheerio! 🙂  |
