Supersnelle Game Productie
Het is weer eind april: de vierde periode begint en voor de tweedejaars-studenten Game Design & Development staan de komende tien laatste weken van het jaar in het teken van een eigen project waarin alle kennis en vaardigheden samenkomen: Game Production. Met een team van meestal 10-15 developers wordt in een professionele setting gewerkt aan een speelbare entertainment game. De kunst is om, naast productie draaien, het ontwikkelproces op orde te krijgen en een functionele teamindeling te combineren met een efficiënte iteratieve planning.
Natuurlijk zijn 10 weken erg beperkt om iets te realiseren – iets wat veel game studio’s al als feedback gaven. Het lukt echter elk jaar om een interessante demo op te leveren die waarde heeft voor het portfolio van de studenten (zie Zeloite). De ervaring van de afgelopen jaren levert een aantal tips en trucs om de succeskans te verhogen – tips en trucs die waardevol zijn buiten deze setting dus tijd om ze te delen!
Project Management Triangle
In een zeer kort tijdsbestek zijn je mogelijkheden beperkt – wees je dus bewust van deze beperkingen en stem al je keuzes af op deze beperkingen. Dit houdt je project realistisch en zorgt ervoor dat onrealistische ideeën snel afgeschoten kunnen worden. De project management triangle geeft hier duidelijk zicht op: er is een vast verband tussen de bronnen die je hebt om werk te verzetten (resources), de beschikbare tijd (schedule) en het te realiseren eindresultaat (scope). Als je bijvoorbeeld minder tijd hebt, heb je meer resources nodig om hetzelfde eindresultaat te bereiken.
De projectmanagament-driehoek.
In een korte productie binnen het onderwijs zijn twee aspecten vast: het project duurt tien weken (schedule) en je hebt een vast team (resources). De conclusies is dus dat je alleen nog de scope kunt verkleinen om de eindstreep succesvol te halen. Zie verder: The Project Management Triangle.
Product Breakdown Structure
Om je scope te kunnen beperken moet je precies weten wat je gaat ontwikkelen. Natuurlijk heb je een eerste spelconcept nodig – het liefst in de vorm van een game design document. Maar maak hier geen boekwerk van: een spelconcept kan ook in enkele A4-tjes helder uiteengezet worden. Om van spelconcept tot een productieplan te komen moet je het concretiseren in te ontwikkelen onderdelen. Hiervoor is een zogenaamde product breakdown structure (PBS) ideaal. Deze verdeelt je eindproduct in onderdelen en daaruit kun je een heldere asset list destilleren.
Stel je wilt een platformer ontwikkelen met drie levels. Waarschijnlijk heb je een main character, een of meer enemies, een eindbaas en een aantal level onderdelen. Vergeet bovendien niet de verschillende UI-onderdelen als beginscherm, menu, in-game UI en eventuele andere schermen.
Een product breakdown structure (PBS).
De weergegeven PBS is slechts een begin; vele onderdelen kunnen verder uitgesplitst worden. Let op de indeling: hoewel er drie levels zijn is er maar één uitgewerkt in onderdelen. Hetzelfde geldt voor de characters: er is vanuit gegaan dat de verschillende characters (main, enemy, eindbaas) variaties zijn op dezelfde basis – graphics en scripts kunnen per individu afgeleid worden van een basis-character.
Je kunt hier ook andere keuzes in maken: wel drie levels opnemen en één daarvan uitsplitsen in delen. Het laagste niveau in de opdeling bestaat uit concrete assets: die-en-die animatie, dat-en-dat script. De verzameling van al die concrete assets vorm je asset list en de basis voor de planning. In de planning begin je dan ook op het laagste niveau en integreer je alle delen tot het eindproduct – hierbij volg je de PBS van onder naar boven. Zie verder: Product Breakdown Structure.
Flow Diagram
In de product breakdown structure is geen volgorde aangegeven – terwijl deze volgorde wel van belang is voor de uiteindelijke game. Een flow diagram kan inzicht geven hoe de verschillende onderdelen samenkomen. Bovendien benadrukt dit wat de speler stap-voor-stap voor zich krijgt als hij/zij het spel speelt. Tot slot is het erg bruikbaar voor (paper) prototyping omdat elke stap in de game conreet is weergegeven.
Een flow-diagram.
Let op: noch de PBS, noch het flow diagram geven iets aan over de volgorde van productie! Je kunt dus in de planning een andere volgorde aanhouden dan de uiteindelijke opbouw van de game. Vaak is het wenselijk eerst een speelbare demo te hebben voordat een tutorial level wordt ontwikkeld. En de onderdelen van het level heb je eerder nodig dan alle verschillende animaties voor de karakters.
Game Design No-No’s
Het gekozen spelconcept is misschien wel de belangrijkste factor in de kans van slagen van een korte productie. Veel beginnende game designers en/of developers onderschatten de beschikbare tijd en/of overschatten hun mogelijkheden. Hoewel het lastig blijft in te schatten hoeveel ontwikkeltijd nodig is voor een bepaald spelconcept, er zijn zeker een aantal aspecten te noemen die alarmbellen dienen te doen rinkelen:
- multiplayer — Tenzij je een groep ervaren multiplayer-developers in je team hebt is een multiplayer-game simpelweg te complex om in korte tijd te ontwikkelen. Je aandacht gaat uit naar allerlei technische zaken in plaats van naar gameplay.
- mini-games — Naast dat mini-games een slap excuus zijn om geen compact en to-the-point spelconcept te maken leidt het er ook toe dat je allerlei verschillende mechanics en art apart zult moeten ontwikkelen. Daar is geen tijd voor.
- online — Tenminste, als online betekent dat er een peristente wereld in de lucht gehouden moet worden. Dit levert een risico op in de ontwikkeling en zorgt bovendien voor een actief beheertraject na oplevering van de game.
- 3D en 6-DoF — Lastig te realiseren en goed uit te voeren: je hebt beperkte controle over de speler die in vrijheid rond kan lopen en haalt je allerlei onnodige problemen op de hals.
Zie verder: Your Game Idea is Too Big.
Repeatable & Resuable Mechanics
Twee concrete aspecten van de gameplay maken een spelconcept klein genoeg om in een kortere tijd te producren – deze noem ik repeatable mechanics en reusable mechanics. Met repeatable mechanics bedoel ik een basis game mechanic die je kunt herhalen – vaak is dit al gekoppeld aan een genre maar ook in een innovatief concept kun je dit gebruiken. Met de basissetting van een platformer – character, jumps, platforms, obstakels en enemies – kun je vele verschillende levels ontwikkelen. Bovendien kun je vanaf daar spelen met de moeilijkheidsgraad, snelheid, verschillende enemies, verschillende attacks, et cetera. Als je één basislevel hebt gerealiseerd is het een kwestie van uitbreiden. Als de tijd het toestaat kun je zelfs nieuwe mechanics introduceren – double jump, secondary attack, et cetera.
Met reusable mechanics bedoel ik net iets anders. Als je voor een doolhof spel een set aan deuren, sleutels en switches hebt kun je daarmee tig verschillende puzzels ontwikkelen. Daarnaast kun je dezelfde mechanic op meerdere manier gebruiken zonder dat je deze apart hoeft te ontwikkelen: de melee attack kan misschien prima dienst doen als bash-actie om bepaalde muren te doorbreken.
Repeatable mechanics en reusable mechanics zijn volgens mij de sleutel om een beknopt concept te maximaliseren tot gevarieerde gameplay. Ze zijn trouwens precies het tegenovergestelde van mini-games en dat is waarom mini-games in de no-no-lijst hierboven staan!
Separate Art from Programming
Enkele keren heb ik een beginnend game development team in de wachtstand gezien: de programmeurs konden niet verder omdat er nog geen art voor de main character was. Dit is natuurlijk onzin – zo vroeg mogelijk in het proces moet je de art-pipeline scheiden van de technische realisatie. Dit kan door te werken met placeholder art.
In het voorbeeld van de platformer kunnen de programmeurs prima met standaard assets als cubes, spheres en planes een speelbare level maken – een zogenaamde greybox scene (meestal worden standaard assets in saai grijs weergegeven). Je kunt in deze opzet zelfs al werken aan gameplay balancing. Op het moment dat de uiteindelijke art assets er zijn is het een kwestie van zoek-en-vervang. Als je een strakke naamgeving voor de placeholders aanhoudt is dit zelfs te automatiseren. De integratie voor een deelproduct is dan ook concreet gemaakt.
Cutscenes & Levels
De meeste kleinere producties volgen een redelijk standaard opzet voor de game – deze zie je al terug in de diagrammen hierboven en volgen het idee rondom mechanics. Dit bestaat uit een lineaire aaneenschakeling van levels. Soms is het nodig om, tussen de levels door, door middel van cutscenes delen van de context of het verhaal aan het licht te brengen. In Jesse Schell’s boek The Art of Game Design is dit weergegeven als de string-of-pearls methode:
String-of-Pearls
Het ontwikkelen van cutscenes is een tijdrovend proces. Ook al gebruik je de in-game assets hiervoor, je zult toch een en ander achter elkaar moeten zetten in een scene-script en wellicht zijn er extra animaties nodig. Een snelle truc is om de concept art die je hebt ontwikkeld te gebruiken voor de cutscenes. Dit ziet er doorgaans al fantastisch uit en als je slim speelt met bewegende uitsnedes, audio en tekst kun je in korte tijd veel vertellen zonder extra art productie.
Dezelfde truc kun je gebruiken voor de instructies: in plaats van een of meer tutorial-levels te ontwikkelen of de speler progressief te laten kennismaken met de spel-elementen, kun je in een of meer mooi opgemaakte screenshots duidelijk maken wat de bedoeling is. Dit kan zelfs weer als cutscene dienen.
Het ontwikkelen van levels kan snel gaan maar komt pas echt op stoom als alle basiselementen klaar staan. In een korte productie is dit echter pas relatief laat in het ontwikkeltraject het geval – te laat om optimaal te profiteren van deze winst. De greybox-aanpak biedt hier al een behoorlijk voordeel. Samen met de scope-beperking is het een slimme zet om de aandacht te leggen op één eerste speelbare level.
Dit level hoeft niet het eerste level van het spel te zijn – het ontwikkelen van een tutorial level met speciale uitleg en speciale puzzels is eigenlijk zonde als daardoor de echte gameplay in het gedrang komt. Kies daarom voor een eerste speelbare level; je werkt dan aan een minimal playable subset van de game. Als gekozen wordt voor een later level met alle beoogde functionaliteit wordt de scope iets groter maar werk je wel aan een vertical slice: een demonstratie van alle features van het spel in een basissetting.
Slot
Er zijn natuurlijk nog veel meer tips. Gebruik bijvoorbeeld bestaande packages voor art, animaties of code; werk in 2D in plaats van in 3D of in ieder geval met een vast camera-standpunt; werk met technologie die jij en je team goed kennen… In ieder geval: maak er een begin mee want zonder te starten gebeurt er sowieso niets!
