Crafting the Perfect Game Design Document: Game Design Fundamentals | Jack Wakem | Skillshare

Playback Speed

  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x

Crafting the Perfect Game Design Document: Game Design Fundamentals

teacher avatar Jack Wakem, Video Game Designer

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Lessons in This Class

40 Lessons (1h 39m)
    • 1. Course Introduction

    • 2. Course Tips

    • 3. Class Project

    • 4. The Basis of the GDD

    • 5. The Project Scope: Section 1

    • 6. The Game Name: Section 1

    • 7. The Game Concept: Section 1

    • 8. Player Objective Summary: Section 1

    • 9. Genre/Niche Analysis: Section 1

    • 10. Target Demographic: Section 1

    • 11. Game Flow Summary: Section 1

    • 12. Game Aesthetic Direction: Section 1

    • 13. Project Estimations: Section 1

    • 14. Monetization Strategy: Section 1

    • 15. Game Structure: Section 2

    • 16. Game Progression: Section 2

    • 17. Game Level Structure: Section 2

    • 18. Detailed Player Objective Analysis: Section 2

    • 19. Game Flow Scenario: Section 2

    • 20. Mechanic Summary: Section 3

    • 21. Main Mechanic Summary: Section 3

    • 22. Player Action and Control: Section 3

    • 23. Objects/Assets Functionalities: Section 3

    • 24. Game Economy: Section 3

    • 25. UI Screen Flow: Section 3

    • 26. UI Functionality: Section 3

    • 27. Story, Setting and Characters: Section 4

    • 28. Plot Summary: Section 4

    • 29. Game World: Section 4

    • 30. Level Design Ethos: Section 4

    • 31. Character Summaries: Section 4

    • 32. Technology Considerations: Section 5

    • 33. Technology Requirements: Section 5

    • 34. System Requirements: Section 5

    • 35. AI Capabilities: Section 5

    • 36. Financial/Management: Section 6

    • 37. Timeline Planning: Section 6

    • 38. Conclusion

    • 39. Class Project

    • 40. Class Conclusion

  • --
  • Beginner level
  • Intermediate level
  • Advanced level
  • All levels
  • Beg/Int level
  • Int/Adv level

Community Generated

The level is determined by a majority opinion of students who have reviewed this class. The teacher's recommendation is shown until at least 5 student responses are collected.





About This Class

Learn how to craft the perfect game design document and steer your development team towards success!

Why should I take this course?

The video game industry is massive, worth an estimated $155 billion in 2020. And this industry is rapidly growing posing opportunity for anyone who dares to get involved. This course will provide you with a deep understanding of the documentation associated with video game development, perhaps, the start you need to begin your career within the game industry?

For existing game developers, this course will take your abilities as a game developer to the next level, enabling you to write game design documents that truly drive your team forward. 

Who is this course for?

Anyone and everyone with an interest in game design and development. Whether you are a programmer, artist or game hobbyist, this course is for you. Anyone who wants to develop their understanding of what truly makes a video game work. 

Any requirements for this course?

Nope! Although some sort of familiarity with video games would help immensely. 

What will I learn in this course?

In this course you will learn;

  • The importance of game design documents as documentation and its role in shaping the development process
  • How to craft the perfect game briefing to quickly and effectively communicate your ideas to developers and investors
  • A step by step examination of all the essential sections of the game design document
  • Guidelines and best practices for when writing a game design document

So, join this class today and learn how you can craft the perfect game design document to guide your development team to success!

Meet Your Teacher

Teacher Profile Image

Jack Wakem

Video Game Designer


Email: [email protected]

Discord: Alpenglow#1251

See full profile

Class Ratings

Expectations Met?
  • Exceeded!
  • Yes
  • Somewhat
  • Not really
Reviews Archive

In October 2018, we updated our review system to improve the way we collect feedback. Below are the reviews written before that update.

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

Take classes on the go with the Skillshare app. Stream or download to watch on the plane, the subway, or wherever you learn best.


1. Course Introduction: Welcome to my new course that would teach you how to effectively develop in depth game design documents. Giving your game's development process the best chances for success through clear documentation and communication to your team and yourself. Giving your game's development clear direction, and a cohesive plan of attack. In this course, you will learn the importance of game design document, documentation, and their role in shaping the development process. Have to craft the perfect game briefing to quickly and effectively communicate your ideas to developers and investors. A step-by-step examination of all the essential sections of game design document, guidelines and best practices for when rotting again, XIJ, sorry, joined this course today and learn how to effectively develop games on documents to communicate your ideas and ensure your developers are united in a common direction. Given your game, the best chances for a successful development process. 2. Course Tips: Thank you for enrolling in this course. Before we get started on the main class content, I would like to outline some tips so you can get the most out of this class. The course is structured into seven sections. The first outlining the practicalities of the game design document within the development process and the final six day telling exact sections within the typical game design document. After starting the sections on the specific sections within a game design document is mass suggestion that you begin to work Assad the videos with the course project, which I will outline next video. Alternatively, it might also be beneficial to take notes during the class, either using the skill share note-taking system or one of your EIN. Be shorter record any useful information you learned in the course as this will greatly improve your knowledge and help you memorize what you learn. Thank you for enrolling in this course, and I'll see you next time. 3. Class Project: Alright, in this video, we will be discussing the final project for the course. The project for this course will be a submission of your very own games on document based on an original idea of yours or an existing video game. Following the template explored within his course with creative freedom for adding your own personal phages. You write a full game design document and submit it within the project section of this course. Rotting your own games on document is a lengthy process. So if you feel you are under time constraints, feel free to simply submit the project scope slash introduction section of your document. But stretching for the submission of a full document will be better in improving your abilities as a game designer. Once again, thank you for enrolling in this course, and I'll see you next lesson. 4. The Basis of the GDD: Game design documents are a crucial part of any gans developed. Traditionally device at the very start of a project and constantly updated throughout development. Game design documents can be described as an exhaustive blueprint of what the design is say as the final product. Detailing aspects of the game such as art, game mechanics, UI, play controls, level design, sound and music, story, characters, and monetization. It must be noted that games on documents are considered to be living documents, meaning that the document will constantly change, right against development, sometimes, as often as daily. Sometimes the game design document will be somewhat lackluster at the start of a game's development, but will inevitably become a full-fledged manifesto of the game's design by the completion of again. So why exactly isn't exhaustive documentation of the games ideas useful for the development of a video game. There are a couple of very crucial raisins while these sort of documentation is required during, during development, regardless of team size and is even required during solid development. One, game design documents serve as a sort of stable, concrete place to recall ideas. Too often, some people make the mistake of attempting to retain ideas that they have had for a video game in their head. And human memory is very shaky at Best. Buy, consolidating your ideas into this document, you will ensure that no great ideas disappear. Also, consolidate your ideas into a document. It shows that your team will have a deep understanding of the gans premise, features and aspects. Two, games on documents, keep yourself and your team focused on the task at hand. During the design stage of a video game development, problems can arise in regard to the number of features within your game. Designers may add an overwhelming number of features or too little, which will made a lackluster experience for players. Especially when a designer initially attempts to add too many features, development will suffer due to time constraints and financial limitations, with some features appearing half-baked and careless and the final product. By using a game design document, designers can accurately keep track of all the features within the game and have a better indication of the nature of these features. Keeping your development team focused and on track. Three, game design documents help organize development and keep everything in order. Game design documents serve as almost a checklist of a video against features and is immensely helpful to developers when they are planning their development cycle. By laying out all the intended features of your video game. Developers can say what needs to be completed and in watch anymore in order to complete them. In terms of management, a game design document will also allow them to say what each of the departments need to do and coordinate their efforts. So they are working towards a single feature at a time for game design documents, keep your team, you nodded and moving towards a collective vision for the game. Too often during against development, different members of the team will have drastically different visions of what the final product will be. This is never good during against development. And development will become absolutely chaotic with different members of the team producing elements of the game with little cohesiveness. Game design documents explicitly lay out a vision for the video game, ensuring all team members know exactly what they need to do. And you knots attain towards a common vision. Five, game design documents are extremely useful for devising marketing strategy. Often marketing efforts are outsourced to another company. And the game design document will allow them to easily devise your games selling points. The document will also typically have information regarding your target demographic. Crucial information required when deciding your marketing approach. In summary, the game design document plays a massive role within the development of your game, serving as a blueprint to developers and allowing you to achieve a bird's eye view of what your game will obey. Thanks for watching, and I'll see you next lesson where we will start to break down the components of games on documents. 5. The Project Scope: Section 1: First section of any games on document, often called the project's scope or game summary, can be interpreted as a simple, condensed overview of the entire document. Useful as a tool to pitch investors and game developers your ideas. When presenting new games on document are the Papal. Keep in mind that the project scope will be the first section read. So within this section, be sure to keep everything simplistic and short with rate as being able to quickly gloss over the details of your game. Game designers should complete this section prior to development at the minimum, if not completed prior to the pitching stage. The project scope will often include an overview of the gans concept, including K features, genre, story premise, demographic considerations, and a description of the piezo objectives. All datas that helped the raiders of the document get a general idea of the premise of your video. Again, within this section of the course, we will go over every notable feature that should be included within the project scope in great, in great detail with examples of H and tips for best practices when compiling this section of the document. Thanks for watching and I'll see you next lesson. 6. The Game Name: Section 1: Within the project scope, designs will often include a short section that explores possible game names and all the mythology of deducing the name of the game prod to development. Amazon's will often not have a confirmed name for the video game. Instead, operating under a working project hurdle. For example, the development of a horror survival game may simply be known as the project horror Development. Anyway, the short concise section of the project scope will outline ideas for the name of the video. Again. For example, going back to the hoary example, possible game named section may read something like this, must contain words relating to horror or synonyms of anything meaning monsters, forest, sinister, or scary. Possible names include losses, nitride, eerie, backwards, plane ticket, monstrosity, abomination, monster realm, et cetera. In this example, we can see the games on a hasn't fully realized a name for that video again. But they have decided what the methodology will be for devising the gans name, and have produced several ideas for the title as examples of what they are looking for. When writing this section, make sure to clearly define what you want your game title to vote for players and outline some guidelines for devising your game's title. If avalanche correctly, you will find members of your development team being empowered to come up with their own ideas with the game's title. And you, as a game designer can sit back and let your games naturally develop. Thanks for watching, and I'll see you next time. 7. The Game Concept: Section 1: The video game concept, a short and simple statement that is a few sentences at most that outlines a concept video, video game. The game concepts diamond should include a description of your games, cave, mechanics and features, world aesthetics, player roles, and perhaps some technical specifications. Let's look at an example. Virtual reality game that is about surviving an onslaught of strange creatures in sinister forest. Game translates into real laugh controls rotate fine to look around, shake phone to repel creatures. Possibility of walking in real life, to walk forwarding game. Alright, so we can see in his game concept statement that the game designer clearly highlights the central features within the video game. Virtual reality controls and an idea of the desired functionality of the phone. The stamen also highlights the desires, intentions to develop the game on a portable device. And more importantly, the designer establishes the player's objective of survival and day towels the world's aesthetics. The game concept statement is one of the most important features of the project scope and is often presented first on the document. A short, concise and revealing concept statement is a powerful tool for caching the document raiders interests and inspiring them to get involved within the game and actively raid the rest of the document. When running your game's concept statement, make sure it accurately highlights the premise of your game and some defining features that differentiate it from the other titles. It should be concise and easy to read. Thanks for watching, and I'll see you next lesson. 8. Player Objective Summary: Section 1: The pilot objective, often an overview of the overriding pyre objectives and written in a condensed form, perhaps as a list of what the plan needs to do within the game in a broad sense. For example, one, complete h naught without being killed by any creatures to collect all the objects within h naught of the game. And three, progress through the knots to complete the game. Although the plays objectives could be analyzed from a closer perspective. Outlining the objectives of the play in a broad sense gives the reader a better indication of the gans premise. The pliers objectives are a crucial component of every game because it stimulates motivation and tangible player action through goal-setting. Defining what the plays role within the game will be, is crucial in understanding the fundamentals of your video. Again, within the pyre objective summary, it is often useful for game designers to include a simple analysis of the Paez skills required for successful completion of the video game. As explored within my game mechanic course and skill share, playa skills can be categorized into three main categories, physical, mental, and social skills. Within your player objective summary, you could highlight some of the desired skills that place should possess to successfully complete the game. It is useful to explicitly define the skills for your development team because it helps shape the team's vision of the game, shaping the gameplay experience around what you want the player to feel. Challenge was, thanks for watching and see you next lesson. 9. Genre/Niche Analysis: Section 1: The genre analysis section of the project scope is immensely helpful to mark it as a management. Providing crucial information about where your game will be positioned against the seemingly endless competition. Within this section, you as a game designer, may simply define the genre your game exists in. Or perhaps could go further and identify some genre tropes that you will incorporate it into your game. For example, if I defined my game as a horror survival, I would cite Paul lighting, feelings of scarcity and open map design as tropes. I intend to cooperate into my game. A useful strategy for running this section of the project scope is to provide some examples of similar titles to yours. For example, within the horror game we've been using as an example, I could provide an analysis of games such as the forest outlast or Resident Evil. Within this analysis, I would identify similar features I will be present within my m, whether it be level design, movement mechanics or lining systems. This game analysis provides radius of your game design document with an immediate visualization of what your game is trying to be. Being able to use the other title as an indication of what you were trying to achieve mechanic wise and visually. Within your analysis of similar game titles, Be sure to clearly identify similar features and provide plenty of screenshots, pitchers, et cetera, for visual stimulation. As this will immensely help in raiders visualizing what your game will look like. Thank you for watching and I'll see you next time. 10. Target Demographic: Section 1: The target demographic, the top of people who you are making the game for. Demographics are simply the characteristics of your desired target audience. For example, gender, age, income level, country of origin, et cetera. By declaring the demographic within the project scope section of the document, you as games on a commune form raiders by your overall aims commercially. Once you've declared your demographic, is often crucial to L on the features of each demographic and how you will incorporate these considerations into the actual design of the game. Let's look at an example. Hypothetically, let's say we are designing gritty, realistic real-time wall strategy game. And we have declared the target demographic to be male, 18 to 25-year-old. A feature of this demographic, which we could list is moderate disposable income, limited family commitment, meaning more time for recreational activities to video games. Within the document and this section in particular, we could list these attributes and perhaps a couple of derived game design objectives. For example, we could declare that the game will aim to encourage extended playtime and microtransactions to further progress, which would be especially effective on this demographic. Through this declaration of the games demographic and their features, we can inform readers of the document and ourselves how the design of the game will be shaped and molded to appeal to our audiences. Thanks for watching, and I'll see you next lesson. 11. Game Flow Summary: Section 1: Guy inflow summaries essentially brief outline of the game's level structure which will be built upon further in the document. As a game designer, you should provide raiders of the document with a short, brief description of how gameplay will be organized. Within this section, you outline the gans level structure, essentially how are components of gameplay broken up? For example, within his section, I could explain how I plan to have a certain number of levels and briefly outline the differences between them. Feel free to reference the previous section of pyre objectives and explain what conditions need to be met for the level to change and the player to progress within the video game. For example, using the previous horror titles reference, I could outline in this section that the player will be required to complete five stages of ten nights with H naught being completed when the place successfully survives eight in-game hours without being killed by the creatures, which will be equivalent to eight minutes real-time. As the levels and stages progress, the game's general difficulty will be scaled upwards. After raises the document finishes section of the project scope. They should be able to visualize what the gameplay will look like and how big level to be structured. When writing this section of the game design document, make sure you include generalized information on how many levels there will be and how the applied transitions between them. Essentially just enough information to give the reader a general idea, as we will be going into a lot more detail further in the document. Thank you for watching and I'll see you next time. 12. Game Aesthetic Direction: Section 1: The game's aesthetics, essentially, what is your gamma going to look like? This section of the project scope deals with the visuals of your video game. Think lodging, textures, models, environmental assets, colors, games, characters, et cetera. Within this section of the project scope, it is often beneficial to divide it into categories based off asset types, an outline and requirements for H, sauteing specific features regarding the aesthetic, for example, environment to total assets, the environmental tile assets, to have a consistent pixel anesthetic with a dampened color scheme that gives off post apocalyptic vibes. Elements to be considered under this category include houses, grass, natural foliage, rocks, water tiles, et cetera. Tall size of 16 by 16, matte brown color scheme, Jaggard, pixelated edges plus sharp contrast. Within this session, it is imperative that you include visual examples of your desired aesthetics and the feel of your guys world and characters through your very own concept art for the game. Or perhaps a mismatch of similar game art styles if you are on a tight budget. This section is arguably the most important feature of the document, as easy as most indicative of the final product. With the visual aid being an amazing tool to get investors in developers on your side. The section within the project scope serves as a reminder to your gains artists of the desired aesthetics and keeps their work consistent. Often a separate document known as the art bible is assembled specifically for Alice. But nevertheless, this section is equally as important in forming your team of the game's aesthetics. Thanks for watching, and I'll see you next lesson. 13. Project Estimations: Section 1: The actual project estimation section, simply an overview of your game's development from a managerial perspective. Of course, summarized as we will go into way more detail later in the document, her extreme examples of game elements you could be outlining within this section of the document. Objects simply give a brief outline of all the game objects that must be made. Systems, scripting system based largely of game mechanics. For example, movement. Within the movement system, you could list basic functionalities such as sprinting, jumping, swimming, crouching, cetera. Dialogue. If your game has distinct character and dialogue, try to estimate the number of lines, perhaps breaking it into categories such as narrative dialogue, music and sound effects. Alan, all the music and sound effects that will be present within your game. Gamma. Perhaps you will compose some game out for static loading screens to try to give an estimate on how many pieces you will need to commission for the final product levels. Try to give a rough estimate of the number of levels that your game will have if your game is an open weld title, try to estimate the size of the map and the number of different environments. The project estimation section is very important, delving into managerial considerations and helping rate is assessed the size and complexity of your video game that you plan to develop by actually estimating the work that needs to be completed to develop your video game, you can truly understand the feasibility of the project, cutting back or adding features as necessary. Thanks for watching, and I'll see you next class. 14. Monetization Strategy: Section 1: At the end of the day, majority of video games are developed with the intention of profit. And the profitability of a game is the most important consideration investors will decide upon when investing into your project. With this in mind, it is time to discuss an important feature of the project's scope section within the game design document, the monetization strategy. Within the monetization strategy section of the document, we will outline how exactly we plan to make money through a video game. Whether it be through a standalone buying process for the amp, subscription-based membership, advertising or microtransactions. A common format of this section is to simply state our monetization policy I macro transactions. Then we will l on several guidelines as to how the strategy will be incorporated into the game. Often adopt point form. For example, acetic based skins for purchase through in-game shop. Shop purchases in form of Dragon coins, which have real world monetary value. Dragon coins are purchased directly for real-world money. Premium currency top can be acquired within the game at a ridiculously low rate, which inspires pies to purchase the premium currency after their limited experience with its usage. This limited example shows you what a video game Manto strategy could look like and how we would represent it through a game design document to read as in the most simplistic way possible. When writing this section of the document, be sure to use concise language and explicitly outline how you will incorporate your monetization strategy into the video game design in terms of what it will actually look like within your game. Thanks for watching and I'll see you next lesson. 15. Game Structure: Section 2: The game structure. This section of the document aims to outline how the video game actually fits together, what each level looks like, and how the player transitions between these levels. This part of the game design document can be considered fairly brief when in comparison to the other sections. However, it is just as important. When raises the document come across his section, we should aim to empower them with an understanding of the game structure and enable them to visual, to visualize how the player moves throughout the game. The primary components of the game structure section of the document include game progression, level structure, a detailed play objective analysis, and a play flows scenario. However, please note that this is simply a recommendation of what you should include within his section. And you are more than welcome to change up the structure as he plays. Within this section of the course, we will outline each component of the game structure section of the document and provide examples of the formatting and general structure of each component and how we will apply games on principles to each. Thanks for watching, and I'll see you next class. 16. Game Progression: Section 2: Began progression. Essentially a detailed description of how the player will move through each individual level within the video game. For the following section, I formulated a table to help organize each level and keep track of all the details of H. All sections of this type will be explained in more detail later in the lesson. Within the project scope, we organized the levels into stages and outlines the defining features of each stage. So naturally, we are going to further explain the defining features of each stage. Now that we've explained in depth the defining features of the stage, it's time to formulate the stage purpose. Essentially, the broader overarching aims of the stage within the video game. For example, we could state the main purpose of a certain stage was to develop the player's abilities in using the default controls. Often the purposes of many early game stages, which e, with each level within stage serving as a sort of interactive tutorial. If we clearly state the purpose of each stage raises the document will be empowered to truly understand each loves purpose and user games on a can keep yourself centered around a series of concrete objectives. Alright, now it's time to explore each individual level. Within the template I've crafted table that includes the sections of on the level airline, the level objectives, level features, level assets and progression criteria. But I'm sure you think of other sections that you wish to include when talking about individual levels. Alright, so let us examine each individual component. The level airline. First of all, it would be beneficial to assign a name and perhaps a number to the level for referencing and communication purposes. Within the outline, we will give a general description of the individual level, referencing unique features and the required player's skills. Let's look in an example. Desert Storm level 23, centered around the player attempting to escape a village located within the Sahara desert that is controlled by enemy fighters. Player must utilize stealth and speed to evade capture while simultaneously attempting to rescue fallen comrades. Taught and claustrophobic map design with Paul lighting. From this example, we can clearly see the desires, intentions fits level, and what they are trying to accomplish. We have glossed over the other sections briefly alluding to level objectives, map features, and some of the progression criteria. But now it's time to go into even more depth. All right, now let us have a look at the other section, level objectives. This is pretty self-explanatory. We're going to be declaring the individual level objectives, simply stating what the player is actually trying to achieve within each level. Before we proceed, it's important to distinguish the difference between level objectives and player objectives. Player objectives tend to be broader and more relevant to all levels within game. Objectives such as kill enemies and avoid enemy file. Level objectives are more specific and tend to be limited to individual levels. Objectives such as Play the enemy bunker or assassinated certain character, etcetera. Alright, so with that out of the way, it's hard to define l level objectives, perhaps represented as a hierarchy of goals with primary and secondary. Secondary goals. Often levels within video games will be comprised of a string of goals with even more girls being unlocked once the previous one has been accomplished. For example, let's suppose we have a FPS game and we're playing level where the primary objective is to assassinate a character. As sequence of objectives written order could look something like this. Assassinate random character. One, maneuver to vantage, location. Play vantage point of enemies, setups like nist to kill random character, distract guards to expose random character. Three, a Skype area. Avoid enemy detection. Rich getaway vehicle. All right, so within this example, I've clearly express a sequence of primary objectives within the game and listed secondary objectives associated with each stage of the level. When raiders of the document come across my explanation level objectives, they should be able to clearly visualize how the level progress and how the player will move through the individual level. Alright, next section, the level features. Within this section we will essentially detail all the smaller level specific features. We will outline features such as players spawn and objective points required player's skills list several potential players strategies explained the layer of the map, perhaps running a Visual Design, the MapPlayer, and also detailed plot, narrative details associated with that level. Within this section, you should write down everything in anything that data's a feature of the level, no matter how minute. Now we have the level assets. This is purely convenient, especially during development. Within this section, you should list all the assets that will be present within each level. Things such as environmental models such as certain houses, walls and grass tiles, audio files, music, player characters, UI acids, gun models, et cetera. This is very useful during development as level designs conceivably looked to the games on document to know the exact assets that they will be utilizing in that level. Dylan. Finally, we have the progression criteria. Essentially the criteria the plan needs to fulfill to successfully complete the level. This is quick and simple summary and can probably be listed in dot point form. This section could potentially look something like this. One. Player rages evac 0.410 minute time limit to play has successfully brought autumn to evac point. A simple list of criteria. When people read this section of the game design document, they will understand how the player moves to the next level. The progression criteria often tied to level objectives, with levels often being completed as soon as the primary objective has been successfully achieved. So that's it. That is the game progression section of the game design document. Thank you for watching and I'll see you next lesson. 17. Game Level Structure: Section 2: The Game Level structure. A detailed description of how the games levels will be organized and how the player will transition in between them. This section of the game design document is very similar to the game flows summary in the project scope. However, we will be going into much more detail about the intricacies of each stage and exploring exactly how we will organize the levels. During this section of the document, it may be useful to include a visual representation of how all the stages fit together, perhaps using a simple linear diagram. For example, within a game, the player successfully complete stage one. And from this they unlock stages 234, all of which can be completed simultaneously. Let's look at how this could look like visually. As you can see, it's fairly straightforward, but some games have very complicated gambles structures. In some games, completing certain levels within a game will unlock new stages. But perhaps supplier also unlocks a new stage only if they collect a certain item within a mission that can be missed entirely. We can represent all of these through diagram, but perhaps it may be best represented through a criterion for advancement under a heading for each stage, let's look at an example. Advancement criteria. Sacred Stage seven, nuclear labs complete stages 1235, acquire nuclear passcode autumn emission down below stage to choose to save the nuclear science in mission end game, stage five, have a minimum power rating of one hundred, ten hundred, two hundred and thirty. From this example, you can clearly see how the player can unlock the secret stage than the game and how the other levels within the game connect to it. We could choose to do something like this for every stage within the gallium and perhaps individual levels. If we need to throw a clear indication of the gans level structure radar will be able to visualize how the player moves through all the levels and where they are heading. Thanks for watching, and I'll see you next lesson. 18. Detailed Player Objective Analysis: Section 2: Within the projects go, we outlined what the play is trying to accomplish within the game in order to successfully complete it. Now, it's time to comprehensively detail the exact conditions that the plan must fulfill to achieve these objectives and outline the desired strategies for its accomplishment. Before we get started, remembered in the previous video, how we outlined the pi's objectives within each level. What we will be outlining here should be considered broader player objectives. Building upon our player object is some rate within the project scope section of the document, we can start to construct a table of sorts with categories for classification, objective overview, and difficulty scaling. To start off with, we will simply state the objective in the simplest language possible. Then we get to the classification of the objective. Within this section, there are a couple of categories we could assign the objective to. For example, is the nominated objective of gameplay goal mean the player accurately perceives this within the game, or perhaps it may be a plot goal, IE, and objective of the protagonists within the game that they are striving to achieve within the story. The objective could also be classified as a short or long-term goal. Short-term goals being objectives of the player that they must accomplish within a short time bases such as avoiding being killed by enemies or the longterm, IE. And objectives such as cleared the kingdom of enemy invaders. An objective that could take the entirety of the game to accomplish. The objective could also be primary or secondary. Or primary objective being considered the most important objective relevant to the player. And secondary objectives being less relevant, or perhaps even optional to actually achieve within the game. Alright, after staying the objective and classifying it, now it's best we actually described the objective, explain to rate as what the player is actually trying to accomplish, why they should try to accomplish it, and how subjective is relevant to the rest of the game. Try to give a detailed outline of the objective itself and give readers the ability to understand why the player actually wants to achieve the goal and some of the mechanics associated with it. Finally, we have a section on difficulty scaling. Essentially what features will we implement within the video game to challenge players while they strive to achieve this objective, difficulty sailing is primarily implemented through game mechanics. Essentially mechanics that the player must contend with in order to accomplish the objective. Within this section, it might be easiest to simply write a dot point summary of all the processes within the game that prevent the player from easily accomplishing the objective. Let's have a look at an example of a detailed plate objective summary. Objective, shoot targets on rollercoaster. Classification, gameplay goal, immediate goal, primary goal, objective overview. Player needs to shoot targets with this selected weapon while Rava, hitting the role coaster. In order to accumulate points, player needs to accumulate points so they can win the game. Difficulty scaling targets on the role coast or alternate sources. Targets on the roller coaster. Sometimes how specific movement patterns. Some targets on the roller coaster, Cafe, and don't give the Piranesi points. Within this video game, we can consider the primary objective, shooting targets on the roller coaster. Because this is the Al-Qaeda's strategy to accumulate points. And when the video again, after reading this section of the document, radius, should be able to visualize how the pi's objectives actually translates into the game itself. Basically realizing what the players in game actions will look like. Thank you for watching, and I'll see you next time. 19. Game Flow Scenario: Section 2: Finally, the play flow scenario, although not present within many game design documents, a play flow scenarios extremely helpful in visualizing what the game will play luck. The play flow scenario, very, very similar to a movie script or perhaps an intense moment of a novel. It is simply a short inspired piece of fiction that details the scenario that could be encountered by the players within the video game. Often, the play flow scenario could be used in a peach setting to set the overall mood and clearly convey the tone of the game to other people. Let's gloss over an example. The pliers stops to restaurant moment and a grizzled appears from nowhere and grabs onto him. He's unable to shake the crater off and his vision goes black. Suddenly the creature jump scares him. He's vision goes red. Here's DOD. Notice within this excerpt of the pipeline scenario, the designer clearly invokes some of the key mechanic for the video game and the attack movements of the enemy creature. The Rotter clearly demonstrates what the final video, again, product will look like two applies, an intense sort of way mirroring the tone of the desired product. Often the play flow scenario can be found within the first section of the document, as it is very useful in pitch situations. However, it must be noted that play flow scenarios are very important in achieving a big picture view of what the gameplay progression will look like suppliers, which makes it an important part of the game structure section of the document. When constructing a lifeless narrow within your document, make sure you select a scenario that the player is likely to encounter while playing your game, and a situation that is indicative of the entirety of the gameplay experience. Be sure to accurately depict the gamechanger SUV again, from the perspective of the player and use descriptive language throughout the piece. Thanks for watching. I'll see you next lesson. 20. Mechanic Summary: Section 3: Section three, the mechanic summary. Within this section, the games on document, we will be outlining the game mechanics of our video game, covering aspects of the game such as player movement, enemy behaviors, game economies, game rules, physics system's, web class systems, etc. The list is essentially endless, but if it is a mechanic, then we will be recording its functionality here. This section of the document will always be the longest, often comprising of over half the document size. Additionally, this will be the section of the document that is constantly revised. New game mechanics devised, revised, tweaked, and thrown out completely on the daily. With this in mind, I've devised a generalized structure that will support concert revisions while maintaining its ease of use and clear communication. This section of the course will most definitely be the longest and probably the most important. As game mechanics need to be explained in a lot of data within this document. Also, feel free to check out my other school Shea course on game mechanics as this would definitely help your understanding of what is about to be explained. Thanks for watching, and I'll see you next lesson where we will begin to dissect different mechanic features within this section of the document. 21. Main Mechanic Summary: Section 3: The main mechanic summer, and in-depth explanation of the primary game mechanics that will be present within your video game. In the next couple lessons on this class and school share, I outline specific formats, so player actions and controls, objects and attributes, game economies and UI systems. However, within this video, I will l n, a generalized formula that you could use to communicate your game mechanics that don't fit into these categories within these compiler of them connect summary of the game design document. Majority of the video games mechanics will be outlined. Before we get started exploring the structure of this section, we need to realize the game mechanics can broadly be classified into systems. Ie, physics system's weapon systems, movement systems, economic systems, etc. Several game mechanics makeup something that we would classify as a system. With this in mind, we should structure this section of the game design documents similarly, within the main mechanic, some rate we will be outlining the main systems in our game, detailing the mechanics that make up each individual system and explain all the functionalities associated with it. It's a bit hard to explain with an example. All right, let us suppose we have a physics system that looks something like this. Pseudo gravity physic system, gravitational system for all game objects within levels primarily used for difficulty scaling and puzzle solving opportunities. Suppliers, system mechanics, mechanic, basic gravitational pull of all GameObjects towards large surfaces, mechanical explanation and features. Within the game default gravity is applied to all game objects and they will accelerate towards the largest surface within the level. Usually this means that all game objects will be resting against the floor within levels. Gravity behaviors can be reversed by player. Player possesses unique ranged weapon that can reverse gravity of selected objects. Objects selected by ranged weapon will exert a force outwards when acted upon by gravitational forces. As a result of this, objects will have the ability to rapidly accelerate away from surface of other objects. Default gravity behaviors of game objects resume after predetermined timeframe. Game objects exert forces onto other GameObjects when they collide with threshold velocity, objects exert force onto other objects and they collide, especially true with anti-gravity objects. This causes some objects to also move when hit with another moving object. Some objects such as buttons, has visual functionalities that are, are activated when another object exerts force upon it. Primarily used as a tool for designers to stimulate puzzle-solving. In this example, you can clearly see how the design represents the system and the hierarchy of individual gamma can exit comprises of physics systems are often overwhelmingly complicated, but they can be better understood by Raiders if you break them down into a system, into individual mechanics, essentially defining smaller rules of interactions between the game objects within the video game. Although this is a simplistic physics system, we can say how the play will interact with these mechanics and use them to puzzle solve within the game. Within this section of the games on document, you should include a summary of all game mechanics in a format similar to this. Try to make them as detailed as possible and empower the rate of the document to be able to clearly understand all processes within your video game. Thanks for watching, and I'll see you next lesson. 22. Player Action and Control: Section 3: Player actioning control. Essentially how and in what ways does apply interact with the game world. In this section of the game design document, we will be detailing player movement systems. One thing before we get started with in Moscow, share class on gaming gettings. I detail immersive and objective Claire actions, objective player actions being in the literal controller functionalities and then linked reciprocation within the game. And immersive player actions being the virtue actions of the Paez avatars such as jumping, walking, and shooting. Within this section, it may be beneficial to L on both classes of player action. Perhaps starting with a summary of control or slash keyboard input. Often designers who sought a diagram of sorts, simply a picture of a controller with links to the associated player actions. For example, let us look at the controller diagram for cola Judy. Within the games on document, designers will often include a diagram such as this to give readers an immediate sense of how the players interact with the gap. In this diagram, we can clearly see how each button links within in-game action. The square Bowden is linked with the railroad player action and x button is associated with the jump state. Now that we have simply listed all the controls and the stated The linked player actions is now to explicitly detail the intricacies of H. We could decide to structure each individual player action under a unique subheading with a reference in the title to the associated control input. For example, jump expansion, player controller, salaries upwards certain velocity of a player movements disabled during our time. Plays enter state of increased damage and lower defense. Within the example, you can see how the game designer references individual player action. It gives raises the document and RDD of how the player jump state impacts all the aspects of the game. Within the example is explained that the player will sustain more damage. However, there are tax strength will be increased whenever they activate the jump k, as well as other player move men actions being disabled. Although this is a very simple example, you can start to visualize what these individual movement mechanical look like within the game. Thank you for watching, and I'll see you next lesson. 23. Objects/Assets Functionalities: Section 3: Within our video games, we have objects, perhaps the most crucial component of video games and the main source of game mechanics. This section of the document will outline every object within the game. It's functionalities, aesthetics, and also its relationship with other game elements. Now, this is an absolute mammoth of a task. Most video games have a countless number of objects within them. So I recommend classing them into categories. For example, I could create categories such as weapons, environmental assets, armor sets, etc. And perhaps I could also create subcategories. So for example, with a weapon category, I could have categories such as Millay, ranged and magic weapons. Through this method of categorizing similar items into categories, I can outline general features of h. There are applicable to all onto the in the class. For example, weapons, the weapons class of objects defined by pi required items that we used, damage enemy, enemy units. All webinar items received damage value, critical heat, chance, speed, size, weight, and cell value attributes. Weapon items are equipped to in weapons. All of the pi's inventory equipped weapons are immediately despite on prior model. Weapons can further be categorized into Millay, ranged and magic subclasses. Alright? So within this example we can see some of the basic attributes associated with the broad category of weapons and how it will be broken down further into subclasses. Within this initial description of the item, be sure to include a description of its general functionality. For example, if you Allen the sword category under weapons, remember to date how, how the sword will work, IE, the base damage is calculated and then a random critical chance multiply applied damage then apply to enemy. Within every class and subclass of item, we need to add the minimum list specific items, or perhaps a sign ARM specific values and describe Otto Munich features. Once again, I find it best to simply construct a table of all atoms in, in a subcategory. This time we could have sections on Adam's name, the autumn index, item description, autumn acquisition, and other category specific values. Let's look an example of what this could look like. Otto name vol means crusader sword autumn index to a 189 description in Ghana found in the minds of volume in among the ruins of his mysterious ancient civilization. It's handled glitters, a magnificent read. Acquisition found by looting vol me destroy a boss enemy involved me, cabins, location, damage, stats based damaged equals 833, critical percentage equals 5.3%. Rarity, platinum tear. Alright, so this is a pretty simple example, but I'm sure you get the point. Within a more in-depth games on document, you could add some more values to each atom, such as sell price, weight, scrap value, speed, size, etcetera. These are just some things that I think would be relevant within the melee weapons class. So feel free to devise some other values for all of your, our Artem classes. This section of the document can truly reach massive proportions with several autumn classes and subclasses. But it's crucial for development. As documentation like this will help keep track of all the atoms within the game. When detailing items within your game, feel free to also include some visual indication of HRM where necessary. As this will help in the identification of age and make sure to give a general explanation or the functionality of age class and or item. As you really need to communicate this with the Raiders of your document. Thank you for watching and I'll see you next class. 24. Game Economy: Section 3: The game economy mechanics hammering. Within our video games, we will often have virtual economies. And economy being simply described as a system of exchanging things of value. Within a video game is extremely likely that we will have some sort of currency, typically represented as coins, points, etc. A basic item that is acquired by the player throughout their play, through an exchange for other items within the game. Within this section of the document, we will outline every process within that game that involves these nominated currency. The first component is section, will be a general outline of the currency and the economic systems within the video game. For example, we could outline that the game will have two currency tabs, a basic and premium one, with the premium one, manly being Aquadro microtransactions. Then we would outline the purposes of h y exactly. Have we decided to implement this type of cancer into a video game? We could sought psychological reasons, such as stimulating extended gameplay for suppliers because of desires for mastery in competition, or perhaps simply to stimulate revenue generation. Now, we must explicitly explained the processes of Qazi acquisition, especially how does the player acquire currency throughout the game. This explanation may best be completed through a civil dot point list, outlining every possible way to obtain the currency within the game. For example, your list could look something like this. Opening crates found around the environment, selling equipment and items to vendors founded on the map, completing challenges and missions, defeating and looting enemy corpses. For each possible way to acquire Qazi, we must also outline things such as county yield, IA, How much money does the player get from doing this acquisition time? I, how long does the plan need to spend doing this to get money? Or balancing methods? Ia, how would the game balance all these county acquisition methods to ensure one method isn't exploited, et cetera. For this section of the economic mechanics summary, I would recommend completing a table of some sort that outlines all the methods for county acquisition. And then we have a component that outlaws all the uses for the consonants in the game. I've represented within the template in the form of a table. For each use of the county, we should provide detailed documentation on the associated processes. Ie, How much does it cost to do this thing? The exchange affects what happens on the Pyrex, changes the money. Use, use, React restrictions. Ie does again restrict the player for museum County on this method multiple times. And finally, a general outline of each county use IE. What does this exchange actually look like within the game? Let us say, for example, our game has a general MPC shop that the player can access to, trade currency for useful items and weapons are documentation could look something like this. Pause the video now if you want to have a look at this example, as it will take a long time. We had actually read it out. However, an URI, the example you realize just how much space the economic mechanical takeout within the game design document. However, even with this in mind, you should make it as detailed as possible, impairing the radar to be able to understand all economic processes within the game. Mainly how the player acquires currency, the uses of the currency, and a better understanding of the monetization strategy if you have decided to use microtransactions of some sort. Thanks for watching and I'll see you next time. 25. UI Screen Flow: Section 3: Building upon the previous section on UI functionality, it may be beneficial to construct a visual representation of the ScreenFlow between the different screens and the UI elements. This is usually an extremely brief section, often on the comprised of a diagram. However, it serves an important purpose in informing readers of how the games UI will link together all the different stages, screens, and levels. It is also a broader view of the next section, the doctrine that will delve into the intricacies of the games UI functionalities. Let's look at an example of what the UR ScreenFlow section could look like. Within this diagram, we can see every individual screen and how each screen is linked. Within the diagram, we can see how the level scrape connects to the main menu screen through the options menu and individual Main Menu button within that Options menu. Now, we should also recognize that some of the main screens, such as the Totto menu and Level screen have subs grains. Within the previous example, we explained how the player transitions between level screen and the main menu screen through the options menu, which in itself is a sort of sub screen that overlays the level scripting. We can represent this through the diagram of relative a's given the rate of the document, a better visualization of the games UI elements. Thanks for watching and I'll see you next lesson. 26. UI Functionality: Section 3: Within your game mechanics section of the Games and document, it may be beneficial to class UI functionalities into a separate section. Within this section on your game games, game mechanics, you should outline the functionalities of all US systems. Think MO counts, health, the Main Menu button, the options menu, and the title screen. Before we get started, a note on structuring. Within this section, I find it extremely helpful if I organize my UI component into separate screens and then explore the intricacies of H screening date. How under that heading, I find it helpful to construct a table for each individual screen and subscript within your video game with categories such a UI component, classification and functionality. From this table, we can l on every UI component within a screen and explain their purpose in the video game. Let's take a look at what this could look like. This is the video again, do, I'm sure just about every aspiring game designer is at least familiar with its existence. But just in case he's a screenshot of the Pi's UI within the main game. Here's what our documentation could look like within now video again, player level screen. You are component, player health, classification. In gain value, display, functionality, display of the pliers health, a value that can range from 0 to a 100. The exact integer value of health is displayed with the corresponding animated head that changes state according to the Pi's health value. This gives the player a visual indication of how hurt they are. You are component done top display, classification, static image, functionality, static image of the play is currently selected weapon visual indication to inform player UI component, MR. can classification in Game value display functionality. Despite of the players MO can vary that can range from 0 to the maximum MR. capacity of the player's selected weapon. As you can see within this screenshot, there are plenty of other UI components that I haven't even mentioned. But for the purpose of keeping this video short, I won't go into too much detail, but hopefully you can understand the general format of this section. When writing this section on UI functionalities aimed to give the raise a solid understanding of how each component works and explicitly state it's taught by simply classifying UI components as buttons, static images, value, despise, et cetera. You empower the rater to automatically assume some of its functionalities and allow them to understand how the pi's will interact with your UI systems. Thanks for watching, and I'll see you next lesson. 27. Story, Setting and Characters: Section 4: Story setting and characters. Within the section of our games on document, we will be outlining the narrative of our video game in terms of the plot, the characters, and the world in which they exist. As detailed in Moscow share calls on player psychology. A primary source of pleasure, enjoyment is derived from play discovery and submission to game worlds. Essentially, the associated law and experience created from plays immersing themselves within a fictional world is one of the key reasons why games such as World of Warcraft, the Uncharted series, and the last boss or soy popular. Often development teams will construct separate documents that allen All of the narrative intricacies associated with the video game. But that does not mean we shouldn't at least include a short section that outlines the narrative and its influence on the games designed. With this in mind, this section of the document outline the associated narrative within our game, the characters, and a more detailed examination of a guy world, as well as level design ethos as inspired by the story. Thanks for watching, and I'll see you next class. 28. Plot Summary: Section 4: Storytelling is crucial part of video games, with extensive narratives featured in majority of video games. Within this section of the document, we will l on the plot summary of the events within our video game. So how exactly do we go about doing this in the most efficient way? Often videogames have massive narratives with plenty of underlying details about the most minute of plot lines. A commonly accepted ethos in storytelling is a concept of misty mountains upon the horizon. Metaphorical mountains that the player can see on the horizon, but doesn't get the chance to explore. It can only wonder what it would be like to be over there. Essentially. This means within any great narrative, the Rotter include small, insignificant details that are open up. Even more possibilities within the story. Never explicitly explained, but help inspire a sense of curiosity within players. For example, an inscription on an in-game items such as the sword could say, found in the minds of von Neumann among the ruins of this mysterious ancient civilization. It's handle glitters, magnificent red. Now does apply it ever get the chance to actually learn of what happens. This one's great civilization, probably not, but it doesn't matter. All that matters is that the pyre imagines a world grader than what they actually get to experience within the game. We could also reference volume in through some strange dialogue with a bar dwelling stranger or perhaps request to recover mysterious artifact for involvement from a character. Storytelling is one of the most exhilarating experiences as gammas honor, but also the most painful to actually document. But alas, we will try within our games on document. Within our games on document, we'll, we will focus on communicating the central narrative of the video game. That is the main story, the main narrative experienced by pyres. First things first, try to summarize the plot into a couple of paragraphs, including K, date house, including Nobel events, moments, levels, locations, character deaths, et cetera. Essentially we are aiming to gloss over the plot and give readers a general understanding of the game story before we go into much more detail in the following section. Now, I like to break down the narrative into stages. Essentially date hailing every narrative data how within specific stages and all levels. This gives the real of the document in, in-depth understanding of the plot throughout your game, and breaks up the plot into manageable sections. So you aren't completely overwhelmed when you were running the document within the tablet, I've struck to this section through a table, breaking up the game, it is stages that comprise of x amount of levels. The stages have been named and given an index number. Then it's time to briefly jot down the locations supply will travel through within that section of the game with the column named game locations. This is very useful to readers and I will connect the plot nicely to the upcoming section within the document that we're airline game locations. Now it's finally time to actually L on the narrative within H damage. You can do this many ways. Perhaps you simply jot down the plot indoor points in chronological order, or rotten in death creative piece similar to the game, for example, within Section two, it's up to you. The only thing that matters is how well your plot explanation is understood by the raiders of the games on document. Let's look at a quick example. Stage. Stage four, the cabins, game locations, del city cabins, the allegiance Kevin headquarters, del Citysearch system, narrative breakdown. After x's escape from Dell city authorities, he's assessing these critical injuries from within the del city sewerage system. X is injuries a severe, and the realization of his mortality dawns upon him. Suddenly the search system is swarmed by del city authorities and x must stealthily evade capture. After evading capture and navigating the Surge, he accidentally fall through an uneven floor and finds himself who is in the dark and Unforgiven Kevin layer, with little hope, he presses on into the darkness. From this example, we can get us since the narrative within the section of the game and members of the development team can get a sense of the sequence of events within this stage of the video game. Remember back to earlier within this class when move detailing level structure and we are Lund level objectives. When running your narrative breakdown for each level, try to link it with the levels, objectives and flow. Successful games will pair objectives of the player with the progression of the plot, especially within modern story-driven games. Thanks for watching, and I'll see you next time. 29. Game World: Section 4: The game world description. This feature of the story, setting and characters section of the game design document is remarkably similar to the game's aesthetic section within the project scope, the document, and has elements of the level design section as well. Within this section, designs will usually include a diagram of the entire world map. This is especially important for open world titles. Often this world map will be stylized. But the only important requirement is that the map gives the reader an in-depth understanding of the layout of all locations within the game and the general geography of the map. Within the map, you could choose to provide a key that shows all locations within the game, perhaps by using a grid system. For massive open world games, this can reach higher levels of complexity and make the map appear cramps. The games world description can also rate dazzling levels of complexity depending on how much data you wish to include within this section of the games on document. For those wishing to keep it simple, I recommend a simple table that could look something like this. Within this table, you should include sections for the location, associate law location features, and even perhaps a featured level section. The location section is pretty self-explanatory. Simply said, locations dam, and perhaps a referencing system that we use to identify the location on the game map above this section. Next we have a section for associate law. Essentially, just an outline of the history of this location within the game. Was this location, ancient civilization that was destroyed by invading enemies. Perhaps it was an ancient neck romantic plaza ritual, or maybe the location of a terrorist organization and massive supply of nuclear weapons. If there's any Lord pi will encounter within the gain that is linked to this location. You need to reference it within this section. Location features. Are there any notable features in this location? Think physical features such as building aesthetics, mountainous terrain, perhaps dislocation has an expensive cave system. These features could also refer to game mechanics. For example, if within your game you have a game mechanic, Web Police units have the ability to arrest you. Dislocation could provide you the opportunity to bribe them, which could be linked system of the associated law that details how the city has become corrupt. Sensually, this section can seemingly be endless, Which is why you may struggle to fit everything in a table form. Next, we have a simple referencing section that we can use to record every level within the game that the players will spend time within level. If you wish to include even more detail within this section, IS simply recommend scrapping the table and running the same description of the location under the described categories, under a simple heading, causing your document to look something like this. Let's look at a quick example of what a location breakdown could look like. Location, mage city, associated law, established in the year 1490 as a Kevin for black magic by the major leader society. War-torn after recent civil war against the dark hottest and the lot majors currently ruled by dark colors and they're lit and there King, Lord Eve Storm, tyrannical later with subjects living under constant fear. Location features central palace with sprawling, dilapidated neighborhood. War-torn straits. Location features vast Underground, expansive sacred tunnels built upon the earliest wars. Featured levels, breakthrough. Level three, Return of the King. Level 42, secret sauces. Level 43. That was a very brief example. But I'm sure that that example has given you a good indication how you would format this section of the game design document. It's up to you on how much data you wish to put into this section. And dependent really on the complexity of your video game. Thanks for watching, and I'll see you next lesson. 30. Level Design Ethos: Section 4: Within our video game, we must create levels, essentially the different stages of our video game, whether it be different environments in our open world, increasingly difficult stages of a puzzle-solving video game or specific missions within a game. Within the previous section and the games on document, we outline the game weld announced harm to transform this fundamental description of the game world into a tangible set of guidelines that will inform level designers as they build our virtual world. Now, this is often a difficult stage within the design process, as you'll ever design ethos when change throughout development. As game phages change and developers experiment. But it's important to get together this section of the document to maintain consistency and cohesiveness between your gans levels and to ensure that the level design fulfills your gains vision. So what do these guidelines actually look like on paper? You'll level design ethos can be distilled into three main features, aesthetics, level, architecture, and flow. In this lesson, we will be exploring how we can best represent these three main features within the game design document. Alright, ascetics, simple enough, as informed by our game world description, can we devise a sort of checklist which refer to when designing a levels. Within this checklist, we should refer to aesthetics, IAEA. Everything look like. This checklist can be a simple dot point lists that touches based upon all the visual features of the Maps design. Be sure to include references to the environment and building asset tops. Level architecture. Level architecture is the actual layout of the map. Think placement of houses, checkpoints, enemies, platforms, et cetera. As informed by the video against narrative, we need to construct a believable game world. This is probably the bulky, so most detailed comparative level design ethos and probably the most important as well. Within the previous section, we did a location by location breakdown and define the features of a unique location. From these defined features, we could begin to derive some level design guidelines within massive games that feature plenty of unique locations, it may be beneficial to define level architecture as per location using a format similar to this. It is a simple structure and we will list simple requirements of a levels architecture and simple dog point form to keep things simple. Finally, we have flow, essentially the pacing of the player as they move throughout level. Believe it or not, we can derive a safeguard lines based on things such as narrative in the game world. Again, we could choose destruction as simple dot point list referencing several general features that all levels within the game should share. Within the actual development process, it may be beneficial to construct an example level based off these level design guidelines. This example level could be referred to by level designers to ensure what they have created is consistent with what has been previously built. This example level should be constructed as early as possible within development and should be improved by the entirety of the team. Thanks for watching, and I'll see you next time. 31. Character Summaries: Section 4: Now it is time to L on the characters the plays will encounter during their playthrough of the video game. This is an important section as characters within our games are what gives him flair. And the main components of narrative. The section can be structured through subheadings toggled with every character's name, ranked from most relevant to less relevant. Some of the most Monica artist might not even neither on section, it can simply be clumped together in a table at the end of this section or R, Let's start with a format for the main protagonists within the game. Characters, the pile will constantly be in contact with and perhaps their own avatar as well. When airline the characters in a video game, there's some essential characteristics that we must reference. When referencing a main character within this section of the document, we should first stay there for name, pretty self-explanatory. Then perhaps we should give a bit of a character set. A short, brief general description of the character, maybe only a couple of lines long. This is perfect for Raiders, the document to get an initial sense of your character's personality and their role in the video game. Now we should L on the character's backstory, often within video games, as we get to know characters better throughout our playthrough, the character's backstory is often something that will develop throughout the game with the prior learning gradually, often within the game design document, we can give a general sketch of the character's backstory, especially if we will be referencing within the game. Next, we have a section on character aesthetics. Essentially, what does this character look like within the game? In this section, we could reference facial features, clothing, body type, mannerisms, etcetera. This section is especially helpful for artists within development and also the radar in visualizing what the character actually looks like within the game. Character attributes. This is a broad section detailing things such as personality and skills. Is the character a Graaf, softly spoken, tough guy? Or perhaps they're acquired on intimidating ally, whatever they are, we will be outlining the personality here. We could also lumber skill section summary into here. Perhaps the character is a novice expert, an expert racing car driver, or a stellar athlete. Anything that informs the reader about how his character will be within the game should be recorded here. Now the most important feature of any character within video games, the characters role within the game. What is the character's purpose in the video game? Do they serve as the main antagonist or perhaps they are special ally that aids the pile within battle. Within this section, be sure to clearly identify what the character's doing within your game and outline their relationship with the player. Alright, let's look an example of a main character profile. Character Captain val, born and raised in the tropics of Indonesia. Captain veil is natural-born explorer with tribal instincts and one of the plies Main Score bats backstory. Born within Indonesian tribal setting. It raised from ages of three to 18 by tribal elders as a warrior encounters explorers while scavenging for a lost tribal artifact that has been taken, captured, and taken to England of scientific purposes. Acclimated to western culture, learns language and joins the army because of alienation from society. Quickly is cells within the army and becomes company commander are two demonstrating savage violent tendencies within early battles. Character, aesthetics, dark-skinned, with a hardened face. It tells a violent past. Captain val is rarely seen anything apart from military fatigues and specialized knife bolsters. The captain wears a tribal insignia with unknown origins, character attributes, graph inquired, the capitalism and a few words, insightful, insightful in impatient the captain is a force to be reckoned with. Captain val is combat expert, proficient in hand-to-hand combat and specialized uses of knives, and expert navigator and Special Operations captain, character role. Captain veil serves as a supporting character for the pile and a helpful ally within battle, also serves as the pi's mentor within the early stages of the game, often used within tutorial sequences. All right, so this example is completely stupid. But we can see how the game designer has developed the character and how some of these character quirks may can't come into play within the video game. Similarly to the main character profiles, we will outline the details of all minor characters within the game. Just really condensed, briefer form, perhaps structured in a table. Within the table we could outline details such as their name, where the paella and count them, our character description and perhaps a link to the characters dialogue. The last essential feature of very characters that purpose, it was exactly their purposes in the game and their role in shaping the pi's gameplay experience. Let's look at an example of a minor character. Character name, mysterious traveler, encountered, dragon alley tavern, dragon city. Playa a must visit location at night between hours or one AM and four AM. Character description. Tall, robbed man with a concealed face, weathered sword and shield, tells story a violent past, persistent yet quiet, all knowing but cautious. Dialogue. Communicate. Let me tell you a story. Purpose, character responsible for assigning the pyre, the sacred side quest, or over the wall. Alright, so we can imagine this example in just about every medieval RPG, a classic example of a minor characters, that purpose is to assign the pious sacred side quest. We fill in the necessary details just so there is a document can get a brief idea of what they may look like within the game. Although we shouldn't spend as much time and developing these characters are short and simple character sketches more than enough for developers to get an understanding of how to include this character in the game. Thanks for watching, and I'll see you next time. 32. Technology Considerations: Section 5: Section five, the technology considerations part of our games on document. Within this section of the document, we will be outlining all technology requirements for the development of our video game. Technology restrictions and requirements are a huge part of development. So naturally we are going to include them in the games on document. This is perhaps the most technical section, the document, and may require input from another member of your team with specialized knowledge of programming and other technological aspects of your video game. Within this section of the game design document, we will outline technology with cognitive about video game platform specific requirements and porting guides and AI functionalities. Thanks for watching, and I'll see you next class. 33. Technology Requirements: Section 5: Within the games on document, we will often declare a series of technological requirements slash objectives. So within this section, we will be outlining aspects of the game, such as frame rate, file size, resolution, etc. Technological aspects of a game that the average player doesn't really talk about. This is a fairly brief section with a simple structure that essentially lists the required technological objective, and then provides a detailed summary of the tangible guidelines that need to be upheld during development to meet the goal, I recommend constructing a table that looks something like this. Let's look in an example. Objective 40 FPS on low-power Computing Systems. Guidelines, efficient programming practices with limit of update functions, efficient level loading techniques, regular FPS tests throughout development. So in summary, after the raid has finished this section of gamma and document, they should understand the objectives of the developers and how their technological goals will impact upon the final version of the video game from the pilot's perspective. Thanks for watching, and I'll see you next lesson. 34. System Requirements: Section 5: System requirements, more specifically, technology requirements that must be met for the video game to successfully run on different platforms. Within the video game industry, it has become a standard for video games to be able to play a multiple systems manly console such as PlayStation and Xbox. And also put Pasi platforms, but also platform such as iOS and the Nintendo Switch. Anymore with experience in game development, will understand the pain of porting videogames to different platforms. So within this section, we will be outlining our intentions of developing on different platforms and devising a series of practical requirements to ensure our gang can have the best chances of success on alternate platforms. To begin, you should clearly state the primary platform. That is the platform you are developing the game to run on first, many indie developers simply developed for PC, then port other platforms as necessary simply due to the ease and quickly building and testing the game on PC platforms. Now, for the other platforms are recommend producing table of sorts with a column for platforms that you can list in order of priority. For example, I might decide that after I developed my game for PC, I would put it to Xbox. After I had successfully done that, I would consider pairs for and then maybe iOS devices. After stating each platform that you desire to port a version of the game too, list any platform specific technical requirements. For example, on iOS devices, you may have to modify the resolution of your game and optimize the graphics to be more efficient on device with limited computing power. After stains specific requirements for each individual platform, developers of your game should have a better understanding of porn requirements, preparing them for when they are required to develop the game for other platforms. Thanks for watching, and I'll see you next class. 35. AI Capabilities: Section 5: Ai is an increasingly important part of video games and requires special attention during development due to its seemingly complex nature. With that said, I believe II deserves its very own section within the document to outline the required capabilities and requirements within the video game. For example, by my outline the requirements of the II's polyphonic capabilities, sorting lists of requirements. One, the IOM must navigate to the destination, avoiding environmental assets and traps. Two, I must decide upon destination based of a hierarchy of needs. And three, the AI must alternate movement patterns and attack strategies by soft players stats to invoke on predictability by clearly stating what I as a game designer want the AI to be capable of and their role within the video game. Game programmers can easily envision what they are building and clearly understand the designer's intentions. Of course, the IRI is likely to be way more complex than the example exported in this lesson. So I suggest breaking down the AI into components such as power falling capabilities, attack decision-making, an AI group coordination within this section of the document in may be beneficial to also include possible AIR solutions and keep track of specific algorithms that may be used to develop the game's AI. Within each category of AI requirements, you could keep a simple dot point list with possible solutions. For example, within the polyphonic section, you could list algorithms such as a star, Dijkstra's algorithm or D star. You could also link a bunch of resources, such as links to similar video games with desired AI functionalities. Thank you for watching and I'll see you next class. 36. Financial/Management: Section 6: Finally, we have arrived at the final section of our games and document the financial and management planning guide. Perhaps the most meticulous and time-consuming compose the document, requiring intense and focused estimations and knowledge of market conditions and management styles. The section of the document is essentially an explanation of the actual development of your game, outlining general logistics and your plan of attack for developing this game within budget and meeting all deadlines imposed upon you. This is the section of the document that will come under the more scrutiny from investors in management and move require intense negotiations, compromise. Within the financial slash management section of the Amazon document, Wu outline financial projections, the projects management ethos, and conduct timeline planning for development. Important considerations that investors and other authorities will keep an eye on. Thanks for watching, and I'll see you next lesson. 37. Timeline Planning: Section 6: Simply a plan on how long each stage of development will take time-wise, and the strategies used to dictate how deadlines are established and in what order. Within project management, there are several commonly used practices for when planning timelines. One of which is the classic Gantt chart. The Gantt chart is essentially a bar graph that illustrates a project schedule serving as a visual representation of deadlines, task lengths, and task types. Within your game design document, feel free to include a visual representation of your timeline with whatever top of illustration you feel best conveys information such as deadlines and task lengths. I personally recommend again shot that could look something like this. After presenting a diagram of salts that gives an overview of the project and expected deadlines. It's Tom to build upon this in way more data. I recommend producing a table for every aspect of the game's development. Programming, music, game art, sound, modelling, playtesting, marketing, etc. And then within each table listing every single task that needs to be completed and providing a detailed description of the actual task and the work that needs to be completed. After providing a detailed description, readers should immediately be able to recognize the work that needs to be completed and get a sense of the scope of the project. After this description, you should provide several Tom on estimates, perhaps expected working days and a proposed deadline. These estimates are extremely helpful to project managers who should be able to realize how they will begin to, to structure the schedule of development. Lastly, it might be a good idea to propose a priority writing, essentially dictating how important these task is in the game's development. Let's look an example of what this could look like within a game design document. Programming, task, player movement system, description, player movement system with basic state changes, animations, jump and creditability. Timeline estimates, five working days deadline, 12th of March. Priority writing, ten high priority. Task enemy II, path finding, description, comprehensive II par filing capabilities, hierarchical based goal-setting and multivariate destination decision-making. Timeline estimates. 30 working days, deadline, 24th of April, priority writing six, medium priority. Alright. So within this example we can see how the design has prioritized programming tasks and structured the document to best give readers an understanding of the work that needs to be completed. From this documentation, project managers can directly take the required work to be completed and fit them into a tangible schedule to ensure that the project is developed with the greatest efficiency. Although this example only has to outline tasks within your game design document. Don't be surprised if this reaches a much greater number. Majority of the outline toss, he will have been referenced within the project scope section of the document. But the difference here will be the level of detail in the task description and the estimated task length and established deadlines. So make sure you reference the project scope and ensure everything is consistent throughout the document. Thanks for watching and I'll see you next time. 38. Conclusion: Finally, we are now ready to wrap up this whole document with a conclusion, several concluding remarks that taught together the whole document. These are your final remarks to the radar. So it is very important that your conclusion leaves a mark and inspires them to get involved with the project. When writing your conclusion, remember that you may be informal and emotive Lee, appealing to raiders on a personal level. Here are some things that you could include within your final remarks. One, the potential of the project, whether it be insane revenue predictions or the chance of producing a critically acclaimed masterpiece, really sell the radar, the idea of what this game could be, and the chances for commercial success to ease of development till the radar. How smoothie you expect development to be, assuring them through your date Hout a meticulous planning. Three previous successes. If you and your team have developed games in the past, convince the reader of your proven track record to produce great games under tight deadlines and restrictions. Include these things, new concluding statements, and you will give yourself the best chances of finding people to join your project. Thanks for watching, and I'll see you next lesson. 39. Class Project: Now that we have completed the review of all the sections and the components of the game design document. It's time to complete the class project as detailed within the introductory videos of this course, the class project will involve the rotting and submission of your very own games on document based off an original idea or a pre-existing video game. Due to the lengthy time it takes to write a full-fledged games on document. Feel free to simply submit the project scope section of the document as it gives summarize view of your video game. However, I encourage you to stretch for the submission of the full document. As this will stretch your abilities as games honor, and encouraging improvement of your skills. Thanks for watching, and I'll see you next class. 40. Class Conclusion: Well, what a journey it's been. Congratulations if you made it this far. Thank you so much for watching and I hope you have gained some new insight into the process of crafting outstanding games on documents. And that you will use what you have learned to develop some awesome games. Make sure to give me a follow on skill. If you want to watch more content like this. And keep in the loop for when I dropped more course on games on and other aspects of game development. Shared his course to friends and remember to leave a review and let me know what you thought about this format and the course in general. I've gone through the course project to the previous lessons. So feel free to complete if your cane and remember to check out everyone else's projects in the project section of this class. Also, feel free to ask them questions when the community tab of this class, I will be answering enactive. Alternatively, you can find my personal email within the course description. So feel free to send any questions you may have. Don't be a stranger. Once again, thanks for watching and I'll see you next time.