ontwerpdocumentatie doelgroep

Transcriptie

1 De ontwerpdocumentatie voor een game bevat de volgende onderdelen met bijbehorende uitwerking. Sommige onderdelen kunnen (deels) niet relevant zijn, in dat geval geef je aan waarom dat stuk niet relevant is. Ontwerpdocumentatie wordt vooraf gemaakt. Je beschrijft hier wat je bedacht hebt. Gaandeweg merk je ongetwijfeld, dat sommige dingen anders moeten of niet kunnen. In dat geval pas je de documentatie aan. Dat is prima. Het is echter niet acceptabel als je achteraf je ontwerpdocumentatie nog helemaal maakt! Zorg altijd dat je de hele game ontwerpt en beschrijft, ook al weet je van tevoren zeker dat je het niet helemaal kunt maken. Dit helpt je om te bepalen welke delen je zeker moet maken. doelgroep Beschrijving van je doelgroep. Wie behoren tot je doelgroep en waarom past je spel bij deze doelgroep. Deze beschrijving moet onderbouwd zijn. Je moet hier een link leggen naar je oriëntatierapport.

2 veldontwerp Leg uit hoe je speelvelden eruit gaan zien en waarom zo. Dit doe je met behulp van schetsen en diagrammen. Je kunt ze bijvoorbeeld op papier maken, fotograferen en in de ontwerpdocumentatie plakken. Zorg dat ze goed leesbaar zijn. Je mag dingen natuurlijk ook digitaal uitwerken. Alleen tekst is niet voldoende. Je mag uiteraard met klassen van speelvelden werken. Een klasse is een verzameling speelvelden waarin dezelfde elementen en mechanismes (of een subset daarvan) gebruikt worden. Je beschrijft dan het meest uitgebreide speelveld van de klasse. Een voorbeeld van een klasse van speelvelden vind je in Sokoban van Michel Fiege. Hierin zitten 2 velden die tot dezelfde klasse behoren, omdat ze precies dezelfde elementen en mechanismes gebruiken. De volgende vragen helpen je bij het bepalen waar je allemaal aan moet denken. Hoeveel verschillende speelvelden en klassen van velden zijn er en waarom deze hoeveelheid? Per klasse van speelvelden maak je een schets en beantwoord je de volgende vragen. o Waarom zien de speelvelden in deze klasse er zo uit? o Welke delen zijn statisch bepaald en waarom? Statisch bepaald wil zeggen dat de programmeur de elementen in het speelveld zet. o Welke delen worden dynamisch gegenereerd en waarom? Dynamisch gegenereerd wil zeggen dat code de elementen in het speelveld zet. o Per dynamisch gegenereerd deel geef je aan hoe de code werkt en waarom zo. Dit mag je natuurlijk achteraf beschrijven! Hoe kan de speler navigeren tussen de diverse speelvelden en menu's en waarom is dat zo? Hier is een beschrijving alleen niet voldoende, maak een diagram waarin je de speelveld en menu overgangen visueel laat zien

3 opbouw Leg uit hoe je game opgebouwd is en waarom zo. Voorbeelden van opbouw zijn: Hoe is de volgorde van speelvelden en waarom is die zo? Hoe wordt het spel binnen een speelveld of over diverse speelvelden heen moeilijker een waarom is dat zo? Hoe wordt de PC (player character) beter gedurende het spel en waarom is dat zo? Hoe wordt een terugkomende NPC sterker gedurende het spel en waarom is dat zo? Hoe worden bepaalde game mechanismes moeilijker gedurende het spel en waarom is dat zo? Hoe worden beloning beter en straffen zwaarder gedurende het spel en waarom is dat zo? De volgende vragen helpen je bij het bepalen waar je allemaal aan moet denken. Bij sommige van deze vragen kunnen schetsen of diagrammen verhelderend werken. Hoe en wanneer beloon je de speler en waarom is dat zo? Hoe en wanneer bestraf je de speler en waarom is dat zo? Hoe en wanneer daag je de speler uit en waarom is dat zo? Hoe en wanneer ontwikkelt zich de moeilijkheid of complexiteit tijdens het spel en waarom is dat zo? Hoe en wanneer ontwikkelt zich de PC in het spel en waarom is dat zo? Hoe en wanneer kan een speler zijn/haar voortgang bewaren en waarom is dat zo? Mogelijkheden om voortgang te bewaren zijn bijvoorbeeld: o Voortgang bewaren is niet mogelijk. o Voortgang bewaren gaat automatisch. o De speler kan op bepaalde punten in het spel kiezen om de voortgang te bewaren. o De speler kan op ieder moment vrij bepalen om de voortgang te bewaren

4 artificial behavior (kunstmatig gedrag) Elk goed spel vertoont kunstmatig gedrag. Vaak wordt dit AI (artificial intelligence) genoemd, maar wij gebruiken liever de term artificial behavior. Kunstmatig gedrag is het gedrag dat je geprogrammeerd hebt. Voorbeelden zijn het bewegen van een NPC, het open- en dichtgaan van deuren als de PC ergens overheen loopt of iets doet enzovoorts. Leg uit hoe het kunstmatig gedrag in je spel werkt. Beschrijf voor al het kunstmatig gedrag in je spel het volgende. Welke strategieën ga je programmeren en waarom die? Hoe en wanneer veranderen de strategieën gedurende het spel en waarom dan en zo? Welke algoritmes heb je gebruikt en waarom deze? Dit mag je natuurlijk achteraf beschrijven! verhaal (optioneel) Je kunt ervoor kiezen om een game met een verhaallijn te maken. Dat hoeft echter niet. Er zijn veel spellen waar geen of weinig verhaal in zit en die toch succesvol zijn. Als je kiest om een verhaallijn te gebruiken, dan beschrijf je het verhaal. Een goed verhaal heeft een begin, midden en een einde. Het verhaal moet logisch opgebouwd zijn, bij je game concepten passen en consistent geïmplementeerd kunnen worden. De keuze voor wel of geen verhaallijn moet je echt bewust maken. Voor een verhaallijn kiezen en het bedenken en beschrijven van het verhaal vervolgens afraffelen heeft meestal een negatieve invloed op je spel! - 4 -

5 gebruik en gebruiksvriendelijkheid Beantwoord de volgende vragen met betrekking tot je spel: Hoe bedient de gebruiker het spel en waarom zo? Hoe leert de gebruiker het spel spelen en waarom zo? Moet hij/zij een handleiding buiten het spel lezen, een handleiding in het spel lezen, een tutorial doorlopen of leert iemand het spel door het te spelen of gebeurt dit op nog een andere manier? opgeloste niet-triviale problemen Let op: Bij ieder opgelost probleem is duidelijk vermeld welk teamlid het probleem heeft opgelost; de oplosser. Voor elk opgelost probleem is er maar 1 oplosser! Het kan zijn dat je geholpen hebt bij het oplossen van een probleem, dan mag je dat aangeven, maar je bent dan niet de oplosser van het probleem! Beschrijf alle niet-triviale problemen die jullie zijn tegengekomen en hebben opgelost. Voor elk probleem beschrijf je het volgende: Wie de oplosser is. Eventueel welk teamlid (eventueel teamleden) er geholpen heeft. Wat is precies het probleem. Hoe heb je het probleem opgelost en waarom zo. Tenminste 1 alternatieve oplossing die je hebt bedacht en waarom deze minder goed is dan de gekozen oplossing. Zoals je weet, is de eerste oplossing die je bedenkt voor een niet-triviaal probleem niet noodzakelijk de juiste of beste. Het is daarom belangrijk, dat je alternatieve oplossingen bedenkt, alle oplossingen tegen elkaar afweegt en uiteindelijk de beste oplossing kiest. Het beschrijven en afwegen van meer dan 1 alternatieve oplossing voor een niettriviaal probleem kan een positief effect hebben op je cijfer. andere niet-triviale problemen Soms kun je wel een theoretische oplossing bedenken voor een niet-triviaal probleem, maar kun je deze oplossing niet omzetten in code. Dat hoeft niet altijd erg te zijn. Beschrijf in dat geval hier de volgende dingen voor het probleem: Welke teamleden hebben zich bezig gehouden met dit probleem. Wat is precies het probleem. Wat is de theoretische oplossing voor het probleem. Wat blokkeerde je om code te schrijven voor deze oplossing

6 gekopieerde niet-triviale oplossingen Soms zijn problemen echt te moeilijk of te tijdrovend om zelf op te lossen of er code voor te schrijven. Als dat het geval is, dan kan je leraar je toestemming geven om de oplossing van iemand anders te gebruiken. Bijvoorbeeld iemand die een oplossing voor jouw probleem op internet heeft gezet. Je moet altijd zorgen dat je toestemming van je leraar hebt. Het is verstandig om via de mail om toestemming te vragen. Simpelweg de eerste oplossing pakken is ook hier niet toegestaan. Je moet dan ook gaan zoeken naar tenminste 1 alternatief en uiteindelijk de beste oplossing kiezen en overnemen. Als je geen alternatief kunt vinden, neem je contact op met je leraar. Wanneer je een probleem niet zelf oplost, moet je de volgende dingen beschrijven: Welke teamleden hebben zich bezig gehouden met dit probleem. Wat is precies het probleem. Welke oplossingen heb je gevonden (tenminste 2), welke heb je gebruikt en waarom. Wat blokkeerde je om zelf de oplossing te vinden