Onderzoek programmatuur en software ontwikkelmethodieken

Transcriptie

1 Onderzoek programmatuur en software ontwikkelmethodieken Auteur: Datum: Versie: Project: Vak: Kevin Wilmink Raindrops Design for Space

2 Intro In dit onderzoek wordt er onderzocht hoe het te verwezenlijken project (Raindrops) voor Design for space het beste geïmplementeerd kan worden. Er wordt gekeken welk ontwikkelplatform het meest geschikt is, diens voor- en nadelen in kaart gebracht. Vervolgens wordt er gekeken naar de verschillende software ontwikkelmethodieken en welke het meest geschikt is voor een project van dit kaliber. Omdat de speler zelf het belangrijkste wordt in het spel en speelt met een onconventioneel object (waterdruppel) word er gekeken naar welke technieken er gebruikt kunnen worden om dit gevoel te kunnen versterken. De opdracht De opdracht van het project van Design for space is het maken van een game waarin de speler ruimtelijke uitdagingen moet overwinnen. Het spel moet voorzien worden van 3 verschillende (ruimtelijke)mechanismes. Het project beslaat een tijdsperiode van 4 weken voor het conceptueren en 5 weken voor het implementeren. Welk ontwikkelplatform past het beste bij het te ontwikkelen design for space project? Voor het maken van een ruimtelijk spel (3d omgeving) zijn er verschillende programma s en technieken voorhanden. Dit onderzoek wordt begrenst tot Unity 3d en XNA. De reden hiertoe is dat op school de meeste kennis van deze 2 programma s voorhanden is, in beiden les wordt gegeven en beiden zich toespitsen op het ontwikkelen van games. Unity 3d kenmerken Unity 3d is eenvoudiger en een sneller ontwikkelplatform in verhouding tot XNA. In unity 3d zijn voor veel basis functies allerlei libraries en technieken voorhanden. Bijvoorbeeld kent Unity 3d voor collisions (botsingen tussen objecten) een volledige set aan colliders (het gebied rond een 3d model waarin het programma weet dat 2 objecten met elkaar boksen). Daarbij is unity 3d ook veel visuele dan XNA, Unity 3d werkt doormiddel van slepen en klikken waarin tegen XNA alle functionaliteit komt uit zelf geschreven code. De visualisatie in unity zorgt ervoor dat de programmeur een beter (visueel) beeld heeft wat er gebeurd en kan hiertoe ook indirect leiden tot een stabielere code en minder/sneller debuggen (onverwachte fouten oplossen). Unity is ook een volledig medium voor het ontwikkelen van een game, het programma kent voor veel mogelijke bestandsformaten functionaliteit. Omdat Unity 3d veel basis facetten van het game ontwikkelen uit handen neemt, zal het ontwikkelen van het project voor design for space sneller gaan in vergelijking bij XNA. Dit zal ertoe leiden dat er meer tijd over zal blijven om eventuele lagere prioriteit onderdelen alsnog te implementeren (shoulds en could s). In unity schrijft de programmeur voornamelijk scripts om de elementen aan te sturen. Unity ondersteund zowel C# (C sharp) als Js (Java script). Een opvallend verschil tussen Unity 3d en XNA is dat objecten in Unity 3d vanuit zichzelf werken qua programmeer denkwijze (onderwater zullen de programma s hetzelfde werken). Dat wil zeggen een object update zichzelf en doet een mutatie als er

3 iets veranderd moet worden. In XNA werkt dit andersom een object wordt elk frame opnieuw getekend door een overkoepelend object. In principe wordt er elk frame weer een totaal nieuw scherm getekend. Unity kent ook een goede (basis) ondersteuning voor het creeeren van particles (explosies, dwarelende stofwolkjes, etc) licht effecten en mist. In unity 3d is het creeeren van een sfeervolle wereld daarom sneller en eenvoudiger mogelijk dan in verhouding tot XNA. XNA kenmerken XNA is een framework dat Microsoft toegankelijk heeft gemaakt voor het ontwikkelen van games. XNA bied een goede ondersteuning voor het ontwikkelen van xbox, windows based pc en Zune games. XNA werkt met de programmeer taal C#. XNA wordt gezien als een meer professioneel medium dan Unity 3d. XNA wordt veelal gebruikt in combinatie met visual studios (code bewerkingsprogramma), ook van Microsoft. XNA wordt krachtig ondersteund door microsoft en kent een levendige community. XNA is echter een complexer medium als Unity 3d. Het kent veel minder basis functionaliteit en veel meer zal zelf geschreven moeten worden. Hoewel dit meer tijd zal kosten qua programmateur (en het verwezenlijken van eventuele shoulds en coulds), is XNA wel flexibeler. De basis functionaliteit die zelf geschreven moeten worden (engine) kan meer naar de hand worden gezet van de programmeur en beter toegespitst worden op het project. XNA is dan ook een programmeertaal die niet zou misstaan op het C.V. van een serieuze gameontwikkelaar. In de gamebiz heeft XNA dan ook een hoger aanzien dan Unity 3d. Hoewel beide programma s zijn voor- en nadelen hebben is Unity 3d een betere keuze voor dit project. Unity 3d zijn grote kracht zit hem in het feit dat het sneller werkt als XNA, omdat veel elementen al voor de programmeur gedaan worden. Omdat er voor dit project geen complexe (engine)functies nodig zijn is het onnodig om veel elementen te herschrijven in XNA. Alsmede omdat het project van een vrij kort tijdsbestek is (5 weken) is het ook eerlijker tegenover de andere teamleden om het snellere ontwikkelplatform te kiezen. De reden hiertoe is dat er meer uit het concept geïmplementeerd kan worden en niet het ontwikkelplatform (programmatuur) de bottleneck van het project wordt. Welke ontwikkelmethodiek past het beste bij dit project? Het project kent 2 duidelijke (verplichte) fases, de concept- en de productiefase (implementatiefase). In de eerste fase wordt er vooral gericht op het bedenken, testen en ontwikkelen van een krachtig concept. De tweede fase beslaat het uitwerken van dit concept. Het ontwikkelteam bestaat uit vier mensen waarvan een enkel persoon zich richt op het programmeren van de game. Door deze verplichte standaard kan er al snel gedacht worden naar de meer conventionele ontwikkelmethodieken. Om tot een goede ontwikkelmethodiek te komen is het een goed idee om uit bestaande ontwikkelmethodieken de punten te pakken die het best aansluiten bij het Design for space project. Een ontwikkelmethodiek die goed aansluit bij deze verplichte eigenschappen is het waterval model. In het waterval model wordt het project in fasen opgedeeld (bijvoorbeeld: analyse, concept, ontwerp, implementatie, testen). De volgende fase pas gestart als de vorige volledig foutloos en

4 compleet is. Hierdoor is het niet nodig terug te koppelen. Andere kenmerken aan het watervalmodel is dat alle besluiten worden vast gelegd in documentatie. Dit zorgt ervoor dat wanneer er nieuwe mensen in het project komen deze snel kunnen worden ingelezen in het project. Omdat het project maar een kort tijdsbestek beslaat en de kans nihil is dat er nieuwe projectleden worden opgenomen in het bestaande project zijn de tijdskosten van het maken van deze extra documentatie groter dan de baten die het oplevert. Het is dan ook verstandig om van dit onderdeel van het waterval model af te zien. Omdat speelbaarheid en gevoel een erg belangrijk onderdeel zijn bij games is het belangrijk veel te playtesten (mensen het spel laten spelen en hun bevindingen meenemen). In de ontwikkelmethodiek van Rapid Prototyping wordt er in korte tijd snel een speelbaar geheel neergezet, waar vervolgens aanpassingen aangedaan worden aan de hand van de feedback van het playtesten. Hoewel dit een snelle ontwikkelmethodiek is om snel tot een product te komen zorgt dit veelal voor cowboy code. Code die niet efficiënt, ongestructureerd is, maar enkel met de focus op werking. Een derde ontwikkelmethodiek is incrementele ontwikkelmethodiek. Kort gezegd komt dit neer op het waterval model maar in plaats van een x aantal hoofdfasen te doorlopen. Wordt op elk onderdeel het waterval model toegepast. Op elk onderdeel wordt apart een analyse, concept, ontwerp, implementatie en test fase toe gepast. Een vierde ontwikkelmethode kan die van XP (extreem programming) zijn. XP is nog erg jong en dient zichzelf nog te bewijzen in de wereld van software ontwikkeling. XP kent echter een aantal unieke elementen die wellicht ten positieve van het project gebruikt kunnen worden. Kenmerkend aan XP is dat het slagen van het project uiteindelijk draait om het schrijven van code en niet om randzaken (documentatie). Ook XP kent snelle productieve sprints (zoals rapid prototyping dit kent). XP is een agile ontwikkelmethode wat inhoud dat het zeer flexibel is en er snel kan worden bijgesteld mochten er (onverwacht) veranderingen optreden. Deze flexibele aard past goed bij het vele playtesten en diens eventuele aanpassingen. In XP wordt de te schrijven code verdeeld over de programmeurs, elke progammeur kent alles en zit overal in. Code wordt gerievewed door elkaar en wordt aan elkaar uitgelegd. Een ander kenmerk is dat code wordt geschreven in paren. Twee programmeurs zitten samen achter één computer om tot een hogere kwaliteit code te komen en beiden bekent te worden met bepaalde delen van de code. De kwaliteit wordt ook gewaarborgt door het veel refactoren van code (code herschrijven om het efficienter, netter te maken zonder nieuwe functionaliteit toe te voegen). Het refactoren van code en het snel neerzetten van nette code is een krachtig element van XP dat past binnen het design for space project. Echter het paar programmeren gaat moeilijk worden omdat het team uit 4 man beslaat en we ook mankracht nodig zijn op andere kwaliteiten. De extra werkdruk die hierdoor komt te liggen op de enkele programmeur is gedeeltelijk in te dammen door documentatie werk weg te laten (er is maar een enkele programmeur aan het werk). Waarschijnlijk ligt de gouden weg in het combineren van de meest aansluitende elementen van deze 4 ontwikkelmethodieken. Het is een goed idee om in hoofdfasen te werken (analyse, onderzoek, concept, ontwerp, implementatie,etc.). Terugkoppeling tussen afgesloten hoofdfasen moet minimaal worden(waterval model), alsmede door de verplichting van de twee verplichte fasen van school. Het project met diens levels,

5 Mechanismes, etc is goed op te delen in aparte subfasen (incrementele ontwikkeling). Deze subfase moet vervolgens gelijk begonnen kunnen worden met een korte sprint (XP, Rapid prototyping). De ontwerp/concept elementen van deze subfase moeten al gedaan zijn in de grote globale ontwerp/concept hoofdfase. Binnen elke fase moet er veel geplaytest worden (Rapid prototyping) omdat gevoel niet te ontwerpen is. Elke subfase starten en afsluiten zoals dit werkt in het waterval model maar binnen elke fase de rapid prototyping toe te passen. Wanneer nieuwe elementen voortborduren op bestaande delen code is het belangrijk dat deze code goed werkt en duidelijk is. Op deze onderdelen is het verstandig om refactoring toe te passen (XP) om geheel duidelijk te maken. Bij refactoring moet voortdurend de berekening gedaan worden: de tijd die de refactor kost + de eventuele performance winst is deze hoger als de kosten van het opnieuw inlezen van (oude code) her te gebruiken code + eventueel risico op fouten en het debuggen hiervan. Refactoring moet enkel toegepast worden als het winst oplevert en niet omdat de code er netter van wordt. Welke mogelijkheden en technieken kunnen het beste gebruikt worden om de speler (waterdruppel) zo krachtig mogelijk in beeld te brengen? Het concept van het spel voor design for space heet Raindrops (Spawn studios) Het spel speelt zich af in een grote boom waar de speler zich doorheen navigeert als een waterdruppel. De speler wil de boom laten groeien en leven door knopjes en blaadjes aan te raken en water te geven. De kracht en geloofwaardigheid van dit spel moet voortkomen uit de waterdruppel die de speler bedient. In deze subvraag wordt er ingegaan op de verschillende mogelijkheden en technieken die toegepast kunnen worden om dit doel te bereiken. Groeien en verkleinen De speler zal gedurende het spel water oppakken en afgeven. De speler wordt hierdoor groter en kleiner. Er zijn drie mogelijkheden hiervoor. De eerste is om van de speler verschillende 3d modellen te maken en de juiste in te laden aan de hand van het verzamelde water. Hoewel er hierdoor veel variëteit tussen de stadia s van de speler is (het aantal verzameld water bepaald de grote van de spelerdruppel). Is het overschakelen tussen verschillende stadia s minder flexibel (het is stadia A of B). Een tweede mogelijkheid is een enkel model te gebruiken en deze te animeren in verschillende stadia s. Hoewel het overschakelen tussen stadia s op deze wijze goed geanimeerd kan worden, wordt het resultaat minder prettig als er een stadia overgeslagen moet worden. Ook wordt het probleem van stadia A of B behouden (geen tussen waarden). Een derde mogelijkheid die vooral de nadruk legt op de programmeur is de waterdruppel doormiddel code te vergroten of verkleinen. Hoewel animaties op deze wijze meer werk vereisen is deze manier erg flexibel met tussenwaarden tussen de verschillende stadia s. Ook hier zal de meest ideale weg liggen tussen verschillende technieken. De druppel moet doormiddel van code een goede flexibele overgang kennen tussen de verschillende stadia s, maar om druk bij de programmeur weg te halen is ervoor te kiezen om enkele geprogrammeerde animaties te versterken/laten overnemen door geanimeerde modellen.

6 Gameplay waterdruppel gevoel De speler moet het gevoel hebben met een waterdruppel te spelen en diens gedrag. Er moet daarom een goede middenweg gevonden worden tussen realisme en gameplay. Aan de programmeur te taak om de waterdruppel zo te programmeren dat het gedrag volledig flexibel aan te passen is door het wijzigen van enkele variabelen (zonder dat er wijzigingen in de logica van de code gedaan hoeven worden). Het ligt echter buiten het bereik van dit onderzoek hoe een water druppel daadwerkelijk beweegt. In een vervolgonderzoek kan hierop ingegaan worden en zou er vast gelegd kunnen worden met welke facetten er rekening gehouden moet worden om een druppel levensecht te laten lijken. Conclusie In dit document is er onderzoek gedaan naar verschillende facetten die spelen bij het opzetten van het Design for space project met betrekking tot het spel Raindrops. Er komt naar voren dat Unity 3d het ontwikkelplatform is dat het beste past dit project. Dit komt doordat Unity 3d s veel ondersteund wordt op school, zich op games richt en een sneller ontwikkelmedium is dan zijn alternatief XNA. Het ontwikkelplatform en programmatuur zal op deze wijze niet een bottleneck vormen voor het project en diens projectleden. Als software ontwikkelmethodiek komt een combinatie van verschillende erkende software ontwikkelmethodieken het beste uit de bus. De afbakening in de verschillende fases van het waterval mode. Het snelle testbare resultaat uit het rapid prototyping/ XP ontwikkelmethodiek. Het waarborgen van code kwaliteit doormiddel van refactoring uit XP en het doorlopen van incrementele cyclussen op losse onderdelen uit de incrementele ontwikkelmethode. De kracht van het spel komt voornamelijk uit het gevoel die speler heeft met waterdruppel, de waterdruppel moet daarom veel aandacht krijgen en moet een perfectie harmonie kennen tussen realisme en gameplay. Veel winst in dit gevoel kan gevonden worden in het combineren van geanimeerde modellen met geprogrammeerde modellen (ideale overgang).

7 Bronnenlijst Literatuur: Lunn, K (juni 2004) Software engineering met UML, Nerderland: Acemic Service Beedle, Mike & Schwaber, Ken (oktober 2001) Agile software Development With Scrum, Engeland