Prep Hard Win Easy

Category: Gamedevelopment

MA | Gamedeveloper Project-documentatie 2015 v1.1

Gebaseerd op het kwalificatiedossier Applicatieontwikkeling geldig vanaf 1 augustus 2015

Inleiding

In dit document vind je informatie over de fases en voor het maken van documentatie bij het uitvoeren van projecten als Gamedeveloper.

Algemeen

De volgende opmerkingen gelden voor elk document dat je schrijft binnen de uitvoering van een project. Controleer dus elke document voor dat je inlevert of laat controleren op deze punten:

Begin elk document met een duidelijke inleiding. In de inleiding vertel je waar het document over gaat zodat de lezer weet wat hij gaat lezen. Probeer daarbij zo specifiek mogelijk te zijn; geef geen uitleg wat een definitiestudie, FO of TO is maar leg kort uit wat je gaat vertellen, hoe het document is op gebouwd of iets dat de lezer moet weten voordat hij het document gaat lezen.

Zorg dat de opmaak van de documenten consequent is. Gebruik niet onnodig veel verschillende soorten opmaak van de tekst zonder dat je daar een reden voor hebt, dit leidt alleen maar af van de inhoud. Gebruik zoveel mogelijk de functies van je teksteditor om het document netjes op te maken, bijvoorbeeld kop- en voetteksten, automatische inhoudsopgave, opmaakprofielen etc. De verschillende documenten binnen een project moeten een gelijke opmaak hebben zodat je duidelijk kunt zien dat ze bij elkaar horen.

Zorg dat belangrijke informatie duidelijk in of op het document vermeld staat. Als je een document op de grond vindt moet je kunnen zien van wie het is, waarvoor en wanneer het is geschreven en welke pagina.

Geef alle documenten een duidelijk versienummer zodat je weet wat je laatste versie is, en wat een eerdere versie is.. Elke keer als je een document (voorlopig) oplevert geef het een nieuw nummer. Aan het nummer moet ook te zien zijn dat het een definitieve versie is. Begin je nummering bijvoorbeeld met 0.1, 0.2, 0.3 … De definitieve versie krijgt dan het nummer 1.0. Als het definitieve document in de loop van het project toch nog moet aanpassen, door bijvoorbeeld nieuwe informatie of inzichten, ga je verder met B1-K1-W1, B1-K1-W2 etc. Zo is duidelijk te zien dat de laatste documenten een aanpassing is op de definitieve versie.

Planning en logboek

Om het proces van het maken van een project of opdracht goed te laten verlopen is het handig om een planning te maken. Hierdoor kan je zien wanneer welk onderdeel af moet zijn, of er verschillende fasen zijn die je moet plannen en hoeveel tijd het project of de opdracht in beslag gaat nemen.

Om tijdens een project of een opdracht, de werkzaamheden die je doet goed te volgen, zul je een logboek bij moeten houden. Het logboek verschaft de projectbegeleider inzicht in het verloop van je project (uitvoering), in de planning en in het realiseren van je product. Je werkzaamheden leg je vast om je voortgang te bewaken.

Lever bij elk product dat je oplevert je planning en je logboek als bijlage in. De planning en het logboek zijn documenten die de projectbegeleider van jou wil zien. Dit zijn dus geen documenten die de opdrachtgever wil zien.

Naam: Groep: Project:
Datum Tijd Activiteit

Kerntaak 1: Levert een bijdrage aan het ontwikkeltraject

De volgordelijke plaats van de documenten binnen het proces:

Part Production Schedule ----> Part Functional specs --------> Part Technical specs ------------->
Game Design Doc --------------------------------------------------------------------------------->

Bovenstaande betekent dat werkproces B1-K1-W2 parallel loopt aan de andere werkprocessen en van invloed is op alle te schrijven onderdelen binnen alle kerntaken

Werkproces B1-K1-W1 Stelt de opdracht vast

Input: Projectbeschrijving / Briefing
Output: Game High Concept Document
Beoordeling: Projectbegeleider vervolgens opdrachtgever
Voor wie: Opdrachtgever

Game High Concept Document:

  • Eisen en wensen opdrachtgever(MoSCoW)
  • Haalbaarheid eisen en wensen
  • Voor- en nadelen afwegen van keuzes en conclusie trekken
  • Uren- en kostenopgave, kosten alleen indien mogelijk
  • Grove planning op basis van pre-production, production, post-production fases

Werkproces B1-K1-W2 Levert een bijdrage aan het projectplan

Input: Game High Concept Document, !! Feedback van de opdrachtgever
Output: Opzet Game Design Document hoofdstukken
Output: Opzet en verwijzing naar iteratieve planning(Scrumboard) in hoofdstuk ‘Production Schedule’ opnemen
Beoordeling: Projectbegeleider vervolgens opdrachtgever
Voor wie: De opdrachtgever en teamleden

Game Design Document > Hoofdstukken

Dit is een goed voorbeeld van een Game Design Document die toegegeven wat gedateerd is maar toch veel tussen- en eindproducten bevat.

  • Game description
    • Design Goals
    • Influences & Sources
    • Target Market
  • Functional specifications
    • Game Mechanics
      • Core Game Play
      • Game Flow
      • Characters / Units
      • Game Play Elements
      • Game Physics and Statistics
      • Artificial Intelligence
      • Multiplayer
  • User interface
    • Flowchart
    • GUI Objects
  • Art and video
    • Overall Goals
    • 2D Art & Animation
    • GUI
    • Marketing and Packaging Art
    • Terrain
    • Game Play Elements
    • Special Effects
    • 3D Art & Animation
    • Cinematics
    • Assets Pipeline
  • Sound and music
    • Overall Goals
    • Sound FX
  • Story
    • Player Characters
    • Secondary Characters
    • Enemy Characters
    • Story theme
    • Visual theme
    • Story Outline
  • Level requirements
    • Level Diagram
    • Asset Revelation Schedule
    • Level Design Seeds
  • Technical specifications
    • Game Mechanics
      • Game engine
      • Platform and OS
      • Performance Budget
      • Devices
      • External Code
      • Code Objects
      • Control Loop
      • Game Object Data
      • Data Flow
      • Artificial Intelligence
  • Production schedule
    • Scope
    • Scheduling
    • Dependencies
    • Cost Estimate

Werkproces B1-K1-W3 Levert een bijdrage aan het ontwerp

Input: Game High Concept Document, Game Design Document !! Feedback van de opdrachtgever
Output: Uitwerking hoofdstuk ‘Functional specifications’ en ‘Technical specifications’
Beoordeling: Projectbegeleider vervolgens opdrachtgever
Voor wie:De opdrachtgever en teamleden

  • Functional specifications
    • Game Mechanics
      • Core Game Play
      • Game Flow
      • Characters / Units
      • Game Play Elements
      • Game Physics and Statistics
      • Artificial Intelligence
      • Multiplayer
  • Technical specifications
    • Game Mechanics
      • Game engine
      • Platform and OS
      • Devices
      • Performance Budget
      • External Code
      • Code Objects
      • Control Loop
      • Game Object Data
      • Data Flow
      • Artificial Intelligence

Werkproces B1-K1-W4 Bereidt de realisatie voor

Input: Functional- en Technical Specifications
Output: Uitwerking hoofdstuk ‘Technical specifications’
Beoordeling: Projectbegeleider
Voor wie: Teamleden en toekomstige teamleden

  • Technical specifications
    • Game mechanics
      • Game engine
      • Platform and OS
      • Devices
      • Performance Budget
      • External Code
      • Code Objects

Kerntaak 2: Realiseert en test (onderdelen van) een product

Werkproces B1-K2-W1 Realiseert (onderdelen van) een product

Input: Game Design Document
Output: Gerealiseerde game(onderdelen) die voldoen aan de eisen van de opdracht en complete en goed verzorgde documentatie.
Beoordeling: Projectbegeleider
Voor wie: OPdrachtgever en teamleden

Fysiek bewijs in digitaal formaat:

  • Volledige speelbare export van de game, bestaande uit:
    • Geeintegreerde animaties, grafische, audiovisuele, functionele en technische componenten
  • Screenshots van de game
  • Opgenomen in een versiebeheersysteem
  • Toegepaste conventies en documentatie

Realisatieverslag:

  • Persoonlijke logboek in verhaalvorm
  • Wat ging goed of fout -> noem voorbeelden

Werkproces B1-K2-W2 Test het ontwikkelde product

Doel: Correct uitgevoerde testactiviteiten en (vervolg)acties
Input: User stories
Output: Alpha testrapport
Beoordeling: Projectbegeleider
Voor wie: De opdrachtgever

Alpha testrapport:

  • Beschrijving van wat je gaat testen (testplan) op basis van userstories, sfeer en beleving
  • Overzicht van testers en hun inzet
  • Video en/of screenshots van het testen (eventuele foutmeldingen)
  • Beschrijving van de uitgevoerde verbeteringen

Kerntaak 3: : Levert een product op

Werkproces B1-K3-W1 Optimaliseert het product

Input: Alpha testrapport
Output: Beta testrapport, Stijl samenhang beoordeling, Optimalisatieplan en een optimaal werkende game(onderdelen)
Beoordeling: Projectbegeleider vervolgens opdrachtgever
Voor wie: Opdrachtgever en teamleden

Beta testrapport:

  • Beschrijving van wat is getest op basis van beleving
  • Overzicht van testgroep en hun inzet
  • Video en/of screenshots van het testen (eventuele foutmeldingen)
  • Beschrijving van de uitgevoerde verbeteringen

Optimalisatieplan:

  • Beoordelen van de samenhang stijl van algemene, audio- en visuele elementen
  • Verzamelen gebruikerservaringen, testresultaten en verbeterpunten
  • Optimalisatieplan, rekening houdend met nieuwe ideeĆ«n, verbeterpunten, de commerciĆ«le- en verkoopdoelen van de game

Werkproces B1-K3-W2 : Levert het product op

Doel: Een door de opdrachtgever/projectleider opgeleverd product
Input: optimaal werkende game(onderdelen)
Output: Final demo/Presentatie
Beoordeling: Projectbegeleider
Voor wie: Opdrachtgever

Final demo/presentatie:

  • Overtuigende en begrijpelijke demo van de game die aansluit op de vooraf gestelde eisen

Werkproces B1-K3-W3 : : Evalueert het opgeleverde product

Input: De gerealiseerde game
Output: Game Post Mortem Document
Beoordeling: Projectbegeleider en opdrachtgever
Voor wie: Teamleden

Game Post Mortem Document:

  • Verslag volgens het STARRT model, denk aan: briefing, onderzoek, brainstorming, doelstellingen, samenwerking binnen het team, realisatie, testing, launch, tijdbewaking en afspraken
    • Situatie
    • Taak
    • Actie
    • Resultaat
    • Reflectie
    • Transfer

Beoordeling communicatie

Tijdens het beoordelen van de communicatie wordt er op de volgende punten gelet:

  • Zijn er vooraf afspraken over onderlinge normen en waarden gemaakt?
  • Hoe is er met problemen om gegeaan?
  • Welke communicatiemiddelen zijn er gebruikt?
  • Hoe is de samenwerking verlopen?
  • Voelen de teamleden zich serieus genomen?
  • Is een ieders mening en idee welkom?
  • Is er voldoende motivatie- of vaardigheid?
  • Worden hoofd- en bijzaken herkend?
  • Is er gebruikt gemaakt van LSD:)(Luisteren, Samenvatten en Doorvragen)

Beoordeling documentatie

Tijdens het beoordelen van de documentatie wordt er op de volgende punten gelet.

Onderdeel: Uitleg:

Titelblad:

een duidelijk voorblad met daarop vermeld:

  • de titel van het document
  • plaats, de maand en het jaartal van publicatie (inlever datum)
Inhoudsopgave:

de inhoudsopgave vermeldt de titels van de hoofdstukken, paragrafen met de daarmee corresponderende nummering en de pagina’s. Deze moet automatisch worden gegenereerd met Word.

De inhoudsopgave moet een duidelijk overzicht geven van het document.

Voorwoord:

hierin behandel je zaken die niet rechtstreeks in verband staan met het onderwerp zoals:

  • bedankjes aan medewerkers en instellingen
  • de aanleiding tot het document
  • als er een vorige document bestaat: het verband met het vorige

Inleiding:

een definitie en afbakening van het onderwerp:

  • de probleemstelling (tip: gebruik hierbij de project naam)
  • een uitleg over de opbouw van het document
  • toelichting op de methode van onderzoek

Opmerking: het voorwoord en de inleiding mogen op 1 pagina worden gezet.

Kern:

de antwoorden op alle vraagstukken en opdrachten:

  • Geef niet te veel maar zeker niet te weinig antwoord op vragen en opdrachten.
  • Verwerk de vraag of opdracht in uw antwoord, vermeld anders de vraag of opdracht voorafgaand aan uw antwoord.
  • Geef duidelijk aan om welke vragen opdrachten en/of hoofdstukken het gaat.

In de inleiding heeft je voor een probleemstelling gekozen waardoor het document zich kan beperken tot een thema. De probleemstelling is de centrale vraag die beantwoord moet worden. De belangrijkste aspecten die je bij het schrijven in de gaten moet houden zijn:

  • de overzichtelijkheid: die moet blijken uit de indeling in hoofdstukken en paragrafen (Zie ook de inhoudsopgave)
  • de objectiviteit: beperk je bij de weergave van de feiten tot die feiten. Loop niet op conclusies vooruit.

Slot:

Dit is het laatste hoofdstuk waarin:

  • een terugblik op de kern wordt gegeven (samenvatting)
  • conclusies uit de voorafgaande hoofdstukken worden getrokken
  • een mening van de schrijver wordt geformuleerd. (o.a. Wat vond je ervan en wat heb je ervan geleerd)

Bronvermelding:

  • geef precies aan waar je de informatie gevonden hebt (boeken, tijdschriften, kranten, Internet). Bij internet vermeldt je de site naam.
  • Opmerking: het slot en de bronvermelding mogen op 1 pagina worden gezet.

De verzorging:

  • Zorg dat je alle koppen en subkoppen een opmaakprofiel geeft. Dit heb je nodig om later uw inhoudsopgave te genereren.
  • De hoofdstukken en paragrafen dienen exact dezelfde benaming te hebben als in de inhoudsopgave. (Gebruik hiervoor de optie Inhoudsopgave in Word)
  • Gebruik een voettekst met daarin, (links)namen, (midden)documentnaam, (rechts)blz. nummering.
  • nummer de pagina’s behalve titelblad.
  • De (hoofd)letters die jij voor de hoofdstuktitels enz. gebruikt moeten consequent van dezelfde soort zijn.
  • Het standaard lettertype dat je gebruikt is Arial 11pt.
  • De hoofdstukken dienen boven aan een volgende pagina te beginnen.

Verwijzingen en/of voetnoten dienen steeds op dezelfde wijze te zijn aangegeven.

Algemeen

Wanneer je informatie van Internet haalt let dan op het volgende:

  • letterlijk kopiëren van Internet is niet goed. Filter alle onnodige informatie er tussenuit en geef duidelijk antwoord op de vragen, niet meer en niet minder.

Bewaar zelf altijd een digitale kopie van de instructie. Op deze manier heb je altijd een back-up van jouw document en kun je dit document later gebruiken als referentie materiaal.

Standaarden coderen

Er zijn een aantal redenen waarom de layout van de code van groot belang is. Met name zorgt een goede layout voor een verhoging van de kwaliteit van de code. In de code sluipt heel gemakkelijk een foutje. Bij een goede layout is het vaak al moeilijk een fout te vinden en te herstellen, laat staan bij code die onoverzichtelijk is opgesteld. De code moet later bij onderhoud van het programma met zo min mogelijk moeite gelezen kunnen worden. Onoverzichtelijk geschreven code maakt dit juist moeilijk zo niet onmogelijk. De code moet door anderen gelezen kunnen worden. Als je samenwerkt met anderen, is het handig als die anderen ook de code kunnen lezen die jij geschreven hebt.

Codeblokken

Codeblokken zijn regels code die tussen accoladen staan. Binnen een codeblok kunnen weer andere codeblokken voorkomen. Zo staat in het voorbeeld hieronder de codeblok van een lus binnen de codeblok van een methode staan. Een codeblok wordt voorafgegaan door een openingsaccolade { en wordt afgesloten met een sluitaccolade }. Na een openingsaccolade springt je op de volgende regel één tab in. Na de sluitaccolade springt je op de volgende regel terug.. De openingsaccolade staat als laatste teken op een regel na een spatie meteen na bijvoorbeeld het sluithaakje na van een methode. De sluitaccolade staat als enig teken op de regel en in de kolom van de eerste letter die staat op de regel van de openingsaccolade.

Voorbeeld:

tekenTekst($ tekst) {
int teller;   
           coderegel;  
           coderegel;  
           for( teller = 0; teller < 10; teller ++)  {  
                       coderegel ;  
                       coderegel ;  
           }  
           coderegel ;  
           coderegel ;  
}  

Operatoren

Vergelijkingsoperatoren (==, !=, <, <=, > en >=) worden altijd omgeven door spaties.

Voorbeelden:

for( teller = 0; teller < 10; teller ++)

Ook numerieke operatoren ( *, /, +, -, %, *=, /=, +=, -=, %=, ++, en --) worden omgeven door spaties, één ervoor en één erachter.

Voorbeeld:

som = a + b;

In dit voorbeeld komt ook de toekenningsoperator ( =) voor die ook door spaties omgeven wordt.

Commentaar

Toelichting op je code is heel belangrijk. Zo kan de ander met wie je samenwerkt, de code begrijpen en kun je zelf de code een jaar later ook nog begrijpen.

Om op één regel commentaar te leveren gebruik je // en om op meerdere regels achter elkaar commentaar te zetten, gebruik je /* … */. Zet in ieder geval boven elk blok C#-code commentaar, boven elke klasse en elke methode in de klasse:

In commentaar dat over de gehele klasse gaat, staat de naam van de klasse, een algemene beschrijving van de klasse, de naam van de auteur en het versienummer met de datum van de laatste wijziging.

Boven elke methode staat de naam van de methode, een algemene beschrijving van de methode, de parameters en wat de teruggave is. Als er geen parameters zijn, dan staat er achter Parameters: geen. Hetzelfde geldt voor return. Ook wordt er eventueel naar andere methodes binnen (zoals in het voorbeeld) of buiten de klasse verwezen.

Door deze manier van commentaar schrijven (zie de dubbele asteriksen aan het begin en het einde van het commentaar) kan er op eenvoudige manier een broncodedocumentatie gegenereerd worden.

Voorbeelden van doc generators, zie:

Zie verder voor de conventies van coderen:

http://framework.zend.com/manual/B1-K1-W12/en/coding-standard.coding-style.html

Wanneer jouw ultieme game in jouw hoofd zit en je die eerste stap op weg naar het ‘maken’ wil zetten kan het zeer overweldigend zijn om van jouw verbeelding tot implementatie te raken. Onderstaande is een stap-voor-stap plan om te voorkomen dat je zaken mist tijdens het coden van jouw game.

  1. Pre Production Phase
    1. analyze brief
    2. research
    3. brainstorming
    4. determine game objectives
    5. determine game rules
    6. determine core gameplay1
    7. visualize colour schemes
    8. visualize concept art for all sprites/models
    9. create level/map mockups
    10. create high-concept doc
  2. Production Phase
    1. determine scale & proportion
    2. determine engine
    3. setup versioning repository
    4. setup directory structure
    5. code main loop
    6. code levels/maps basics
    7. code core gamemechanics2
    8. code player
    9. code physics(kinematics)
    10. code controls
    11. create primitive objects
    12. code objects attributes and behavior
    13. code collision detection
    14. create basic sound effects
    15. code blocking out
    16. apply basic sound effects
    17. apply scale/proportion
    18. create lo-res environmental 2D sprites/3D models
      • characters, objects, life forms, scenery, vegetation, walls, furniture, vehicles, lighting etc…
    19. animate lo-res environmental 2D sprites/3D models
    20. place/rig lo-res environmental 2D sprites/3D models
    21. code level/maps
    22. code game logic
    23. code gamemechanics2
    24. code enemies
    25. code ai
    26. create lo-res textures for all sprites/models
    27. apply lo-res textures on all sprites/models
    28. create lo-res visual effects
    29. apply lo-res visual effects
    30. create transitional visual effects
    31. apply transitional visual effects
    32. adding game features*
    33. code backend
    34. test core gameplay1
    35. alpha playtest
    36. refactor according to testreport
    37. alpha game demo
    38. create hi-res polished textures for all sprites/models
    39. apply hi-res polished textures on all sprites/models
    40. create ui/hud interface art
    41. apply ui/hud interface art
    42. create hi-res polished visual effects
    43. apply hi-res polished visual effects
    44. create final polished sound effects
    45. apply final polished sound effects
    46. create cinematics (cut scenes)
    47. apply cinematics
  3. Post Production Phase
    1. beta testing final
    2. redesign according to testreport
    3. beta game demo
    4. packaging design / packing code
    5. soft launch
    6. promotion
    7. hard launch
    8. maintenance

1.) Gameplay
Gameplay zijn alle acties die gedaan kunnen worden:

  • door de speler
  • door andere objecten als reactie op de acties van de speler
  • door andere objecten als zelfstandige acties

2.) Gamemechanics
Gamemechanics is de manier om Gameplay mogelijk te maken door een op regels gebaseerd interactief systeem die in staat is om:

  • acties te ontvangen
  • reacties te geven

*TV Tropes(2015). Videogame Tropes. Geraadpleegd op 5 november 2015, van http://tvtropes.org/pmwiki/pmwiki.php/Main/VideogameTropes

Copyright © 2024 Prep Hard Win Easy

Theme by Jim DunkUp ↑