Student Gamedevelopment: De Imagine Cup - part 8

Vele gamers dromen wel eens van hun eigen game maken. Van je hobby je beroep maken, is altijd plezierig. Ook Thijs Morlion, student Digital Arts and Entertainment, is op de goede weg. Aan de Howest is hij sinds anderhalf jaar druk in de weer om een volwaardig gamedeveloper te worden. In deze wekelijkse column neemt hij je mee in de wondere wereld van een student gamedeveloping. Allerhande topics zullen onder handen worden genomen en jullie vragen zullen zeker worden beantwoord!

Vorige week heb ik jullie meer verteld over het waterfall-systeem dat in vele bedrijven wordt gebruikt om een project op poten te zetten. Ik sprak echter ook over een tweede techniek die soms wordt toegepast, namelijk het Scrum-systeem. Dit systeem verschilt op tamelijk veel vlakken van het vorige en zal vooral de improvisators onder ons wel bekoren. Hieronder kun je een schematisch overzicht vinden van het Scrum-systeem. Het staat garant voor een soepel project- en ontwikkelingsverloop. Ik zal deze week overlopen hoe men precies te werk gaat in dit systeem.

Dit systeem, dat ongeveer midden de jaren ’90 opgekomen is, gaat vooral uit van de feedback die men om de zoveel tijd krijgt van elkaar. Feedback staat hier immers centraal en dient om het project zo goed als mogelijk af te leveren in de voorziene tijd. Het begint allemaal met het indelen van het project in grote blokken. Eerder heb ik het al meermaals gehad over het designdocument waarin achteraan een planning zit bijgesloten. Aan het begin van de ontwikkeling is het belangrijk dat je voor jezelf en je team een globaal overzicht kan geven van de mogelijke ontwikkelingstijd en de stadiums die je project kan kennen. Het is een goede oefening, ook buiten de game-industrie overigens, om precies zoals een helikopter een overzicht te gaan krijgen van je project en dit te gaan indelen in kleinere stukken van zaken die op één of andere manier samenhangen. Dan ga je stap voor stap gaan kijken wanneer je deze stukken afgewerkt wilt zien en wie welke rol krijgt in elk stuk.

Op de afbeelding kun je zien dat de eerste stap het opdelen is van je project in kleinere, samenhangende gehelen. Vervolgens werk je ieder blok op dezelfde manier af. De tweede stap hier is ook weer het indelen van één blok. Elk blok die je zelf vooropgesteld hebt, kun je nog meer onderverdelen in kleinere stukjes die moeten worden uitgewerkt. Dit zie je op de afbeelding bij “Sprint Backlog”. Een sprint is een klein stukje van het project dat je wilt verwezenlijkt zien binnen de vooropgestelde tijd; in dit geval een maand. Je maakt de planning op, zegt wie wat moet doen en begint aan de ontwikkeling. Dan komt echter het meest cruciale stuk van dit ganse systeem. Na elke 24 uur komt het volledige team samen en gaan ze overleggen. Men kijkt wat er geslaagd is, waar de planning moet worden bijgeschaafd, waar er iets is misgelopen in de klassedesigns of als er ergens bugs zijn opgedoken. Tijdens de meeting wordt er druk bijgeschaaft en zorgt men ervoor dat iedereen voor de komende 24 uur weer perfect weet wat hij/zij moet doen. Anders dan het waterfall-systeem is feedback in dit systeem dus wél toelaatbaar. Voor mensen die graag plannen en alles graag uitwerken op voorhand is dit misschien niet zo’n goeie methode.

Wijzelf passen op school dus dit systeem toe. De feedback is in ons geval niet dagelijks, maar wekelijks. Elke week sturen de leerkrachten wat bij, geven ze tips en zeggen ze wat er beter kan. We moeten voor hen ook elke week een document, het zogenaamde SCRUM-rapport, opstellen waarin we vertellen wat iedereen binnen het team verwezenlijkt heeft tijdens de voorbije week en wat we gepland hebben tegen de volgende week. Zo kunnen de leerkrachten ietwat volgen of onze planning al dan niet klopt en of iedereen zijn werk wel doet. Wijzelf hebben binnen het team dan een regelmatige feedbackronde waarin we ieders werk bekijken en zeggen wat beter kan. Het is belangrijk dat je dit als team zelf ook doet en niet altijd enkel en alleen kijkt naar externe feedback.

Als alle deeltjes van het project dan uiteindelijk uitgewerkt zijn, kun je een volledig werkend project afleveren dat kwalitatief even hoog uitgewerkt zal zijn als een team die het waterfall-systeem toepast. Het hangt dus af van bedrijf tot bedrijf welk systeem geschikt is voor welk team van medewerkers. Ik herhaal nog eens dat deze systemen algemeen zijn en niet noodzakelijk enkel gebruikt worden in gamestudio’s. Ook voor kleine schoolprojecten kun je een van deze twee systemen gebruiken. Weliswaar in het klein, maar het kan zeker helpen om een meer gestroomlijnde ontwikkeling te hebben van je product of werk!

Zo, deze week is het de week van de waarheid en weten we of we naar New York mogen om ons spel te gaan voorstellen aan de wijde wereld. Binnenkort kun je hier zeker een setup vinden van ons spel, die jullie dan allemaal veelvuldig zullen kunnen uittesten!