1 / 23

Game Development Documents

Game Development Documents. GözdeÇetin. documentation does have a legitimate place in the creation of modern computer games, and it is the designer’s job to make sure those documents are created, maintained, and used effectively. Document Your Game.

landen
Télécharger la présentation

Game Development Documents

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Game Development Documents GözdeÇetin

  2. documentation does have a legitimate place in the creation of modern computergames, and it is the designer’s job to make sure those documents are created, maintained, and used effectively.

  3. DocumentYourGame • As a game designer, you will be primarily concerned with what is commonly called thedesign document. • However, there are manyother pieces of documentation used in the creation of modern computer games.

  4. ConceptDocument, PitchDocumentorProposal • This document is shown to the money, the suits, the decision makers, in order to convince them to spend a lot of money on the idea, thereby funding its development • Writing a concept document can be quite a lot of fun, since the writer gets tofocus on the most exciting parts of the game and does not have to worry about all themessy details of actually implementing the game.

  5. CompetitiveAnalysis • The competitive analysis is another document used in trying to sell yourgame. • The competitive analysis then lists a number of other games that have shipped in therecent past that are similar to the proposed game, and then describes how each of these games performed(via average review score, quotes from various reviews, and sales figures, if available).

  6. Design Document • The design document’s goal is to fully describe and detail the gameplay of thegame. • The design document needs to describe how the game functions so that someoneworking on the development team can see exactly what he needs to create.

  7. Flowcharts • Flowcharts can be used to chart the areas the playersprogress to and from in the game. • Flowchartscan be eitherhandmade or developed using various flowchart creation tools, such as Visio.

  8. SampleProgressFlowchart

  9. StoryBible • A story bible, is a good place to document a game’s potentially extensiveback-story. • On the other hand, even with a complex game-world, you may not need a storybibleat all.

  10. Script • Dialogsand the accompanying descriptions of the situations during which the dialogoccurs (stage directions) should be contained within the game’s script.

  11. For instance, here is an example of a script that could be used for a cut-scene in anadventuregame: • When the PLAYER approaches PAUL and SANDY after resurrecting the TREEOF PLENTY, PAUL will be visibly thrilled at the player’s arrival. He immediatelybursts into effusive praise for the player’s accomplishments: • PAUL: That’s just the solution we have been praying for! You have saved ourgreat Tree, and nothing we can do could ever thank you enough. Please acceptthis token of our appreciation... • PAUL tosses a BAG OF FLIMFLAMS at the player’s feet. SANDY steps forward: • SANDY: [Apologetically] We know it’s not much, but . . . • PAUL: [Interrupting] It’s all we have! • SANDY: [Cowering] Please do not hate us for our poverty. . .

  12. If players have branching conversations, the script will need to takeon a special form. • Here a scriptmight use small amounts of pseudocode, using IF-THEN-ELSE or SWITCH-type syntaxto communicate when the players would hear different pieces of dialog.

  13. Returning to our adventure game example • IF The player asks about “FLIMFLAM”: PAUL: A FlimFlam is a drop of dew, fallen from the morning sky, carefullywrapped in a baby leaf from the Tree of Plenty. It has special curative propertiesfor Humanoids, when rubbed on the back of the neck. • IF the player asks about “TREE” OR “PLENTY”: PAUL: The Tree of Plenty has been my people’s source of life since before anyof us can remember.Without the shade it provides, my people grow exhaustedin the noonday sun.Without its leaves, we have nothing to eat. Without itsstrength, my people are weak. • DEFAULT if the player asks about anything else: PAUL: I do not know of what you speak, stranger. We are not the most intelligentof peoples; we are not as wise as a great traveler, such as yourself.

  14. Games thatfeaturea lot of branchingconversations, suchas DeusEx, oftenincludea scriptinglanguagespecificallyforimplementingthedialog.

  15. Art Bible • The art bible is often composed primarily of concept sketches and other resources thatartists can refer to as they are working on creating various visual assets for the game. • The art bible is usually notcompiled or written by the designer, but instead by the lead artist working with histeam.

  16. The Game Minute • The game minute is typically a one- to three-page document that describes in detail ashortsection of gameplay.

  17. Storyboards • Storyboards are an established film and television device for sketching or mocking-upshots before they are actually filmed. • Sometimeswhen people get overly excited bystoryboarding a game it can be another case of movie envy, where developers actuallywishtheywerefilmmakers.

  18. Technical Design Document • A technical design document (TDD) is the sister specification to the design document.Whereas the design document focuses on how the game will function, the technicaldesign document discusses how that functionality will be implemented.

  19. Thedocumentmayinclude the overall code structure, what major classes will be used, descriptions of therendering architecture, details of how the AI will function, and any amount of otherimplementation-side information. Pseudocode is appropriate, though not required.

  20. Schedules & Business/Marketing Documents • Business-oriented information is neitherappropriate in the design document, nor does it belong in any of the other documentswehavediscussed, exceptfortheconceptdocument. • It is besttoseparate out such marketing plans and business data into distinct documents, wherethe people concerned with such information can best review it.

  21. No StandardDocumentation • Some teams may split thedesign document into two documents, one containing only gameplay information andthe other containing only story and level progression descriptions. • Some developmentteams may create only a design document, having no need for a story bible.

  22. TheBenefits Of Documentation • Beyond making the suits happy, good documentation really can help make your gamebetter, regardless of whether you are developing it alone in your basement or with ateam of thirty other developers.

  23. ThankYou.

More Related