Richtlijnen voor het ontwerpen van een computerspel. Introductie Oorspronkelijk was het doel om een onderzoek te doen naar “The story of storytelling” om inspiratie op te doen voor het bedenken en vertellen van een verhaal in adventuregame stijl. Door tijdgebrek is dit onderdeel in dit onderzoek vervallen en heb ik me gefocust op het ontwerpproces van computerspellen in het algemeen. Over het ontwerpen van computerspellen heb ik twee naslagwerken gelezen. Een hele korte samenvatting van de belangrijkste richtlijnen geef ik hier. De aanbevelingen zijn veelal van persoonlijke en wat vrijblijvende aard. Het eerste boek dat ik las was “The art of computer game design, van Chris Crawford”, waarin een aantal ervaringen van de schrijver zijn beschreven. Het andere boek “Digital game Based Learning” van Marc Prensky geeft wat richtlijnen voor het (laten) ontwerpen van educatieve spellen. De aanbevelingen van Marc Prensky zijn interessant om kennis van te nemen, maar begeven zich op er globaal niveau. Veel visie van de schrijver wordt voor het voetlicht gebracht en verder voornamelijk veel verkooppraatjes en suggesties voor het krijgen van budgetten om überhaupt aan een ontwerp te kunnen beginnen. Chris Crawford is veel concreter in zijn aanbevelingen en van de relevante hoofdstukken uit zijn boek geef ik hier een korte samenvatting.
“The art of computer game design” Na een algemene inleiding over wat spellen zijn en een taxonomie van computerspellen waagt Chris Crawford zich aan een procesbeschrijving voor het ontwikkelen van een computerspel. Wat betekent de computer voor het spel? Voordelen ? De computer beidt een grote flexibiliteit vergeleken bij bijvoorbeeld bordspelen. Een omgeving kan naar believen veranderen, het speelveld kan zichzelf aanpassen etc. ? De computer is een betrouwbare scheidrechter in het spel. ? Zeer geschikt voor het bijhouden van scores en het toepassen van, vaak gecompliceerde regels. Het is ook niet nodig dat de speler alle regels kent voordat hij gaat spelen. De computer kent ze immers. Het spel wordt niet opgehouden door “administratieve rompslomp”. ? De computer kan als tegenspeler fungeren. Je kunt dus spelen tegen een “intelligente” tegenstander, terwijl je alleen bent. ? De computer kan de verschafte informatie beperken. Door dit op een handige manier in te zetten kunnen zeer boeiende spellen ontworpen worden waarbij de speler de informatie moet achterhalen door de gebeurtenissen en reacties te analyseren. Door de beperkte informatie wordt de verbeelding van de speler gestimuleerd. ? De computer kan data over netwerken (telefoon, internet) versturen. Hierdoor kun je op afstand spelen, tegen een of meer tegenstanders. Nadelen ? De i/O interface is een van de grootste manco’s van computerspellen. Invoer gebeurt door toetsenbord, muis en joystick, de uitvoer van het spel is veelal in geluid en beeld. Dit beperkt het ontwerp van het spel enorm. En de mogelijkheden van de interface zijn dan
? ?
ook zeer bepalen voor het ontwerp. Een spel waarin over diagonale bewogen moet worden, heeft bijvoorbeeld veel nadelen t.o.v. een orthogonaal opgezet spel. De computer is ontworpen voor een enkel speler. Met meer speler moet je eigenlijk ook meer computers tot je beschikking hebben. (voor educatieve spellen is dit een serieuze beperking! Groepsleren is dus niet automatisch ondersteund door de computer) Het computerspel moet worden geprogrammeerd. Omdat niet alles evengoed in programma code te realiseren is, is dit wel de grootste beperking. Het beste is het als de ontwerper en de programmeur in dezelfde persoon verenigd zijn (communicatie over (on)mogelijkhden is dan geen hindernis. In lek geval moeten beide thuiszijn op het werkterrein van de ander.
Design voorschriften 1. Pas je doel aan, aan de omgeving Ontwerp geen acties of omgeving in een spel die niet past bij de computeromgeving. Een voorbeeld is het gebruik van honingraatspeelvelden. Deze speelvelden hebben het voordeel dat er geen hoekpunten zijn, en alle overgangen naar naastgelegen velden gelijkwaardig zijn. De grafische interface van de computer is echter lineair opgezet en het afbeelden van een honingraatstructuur is erg moeilijk.
2. Transplanteer niet Ontwerp een spel dat gemaakt is voor de computeromgeving. Kopieer niet een bestaand spel naar de computer omdat het dan een computerspel wordt, maar maak gebruik van de specifiek voordelen van de computer. (denk maar aan het eerste vliegtuigontwerp met klapperende vleugels: transplantatie van bestaand concept naar ongeschikte omgeving)
3. Ontwerp om de interface heen De interface bepaalt de interactie tussen spel en speler, en moet dus in het ontwerp leidend zijn. Met een slechte interface is geen enkel spel plezierig om te spelen. Besteed veel tijd aan het ontwerpen van een spel dat goed aansluit op de interface. Laat de speler niet met de muis balderen in een referentie systeem om bepaalde spelparameters te achterhalen als dat ook kan met een grafisch icoontje dat verschijnt als je je muis over het te onderzoeken onderdeel beweegt. Ook met kleurveranderingen kun je veelzeggend informatie weergeven, op een manier die zeer goed past bij de grafische uitvoer van het computerspel.
4. Houd het ontwerp “schoon” Houd de algemene spelstructuur consequent. Ga bij problemen geen uitzonderingen maken en lapmiddelen programmeren, maar pas liever het hele concept aan. Een spel moet kunstzinnige eenheid uitstralen om de speler te boeien en mee te voeren in de fantasiewereld van het spel.
5. Sla niet teveel informatie op, maar bewerk informatie Deze richtlijnen gaan aan het eenvoudige door mij te ontwikkelen spel voorbij. Met de snelle computers die iedereen vandaag de dag ter beschikking heeft hoef ik niet bang te zijn dat mijn spel heel erg groot wordt doordat ik teveel informatie opsla. Dit aspect zou eventueel relevant kunnen worden bij het opslaan van heel veel grafische informatie, waar die net zo goed meet en “draw-commando” gegenereerd kan worden.
6. Bewaar de eenheid in je ontwerp-inspanning Chris beschrijft de samenwerking tussen de ontwerper en programmeur als een gezamenlijke sprong van een polsstokhoogspringer en een gewone hoogspringer die aan elkaar geboden zijn: gedoemd tot mislukken, en tot elkaar veroordeeld. Daarom is het belangrijk dat gedurende het gehele proces de ontwerper en programmeur heel erg nauw samenwerken, omdat beider inspanningen interfereren.
Het ontwerp proces Het ontwerp proces verloopt globaal in een aantal stappen die hieronder beschreven worden. In de praktijk zullen de stappen door elkaar gaan lopen maar ze moeten wel allemaal gezet worden.
1. Keuze van doel en onderwerp Een spel moet een DOEL en een onderwerp hebben. Het doel is echter het allerbelangrijkste en bestaat uit: DOEL: Beschrijving van de beoogde fantasieën die het spel zal ondersteunen en de beoogde emoties die het spel bij de speler teweeg zal brengen. Later in het ontwerpproces zullen er momenten komen dat er opties zullen moeten worden weggestreept tegen elkaar. Het doel zal dan kunnen helpen bij het bepalen van de prioriteiten en de beslissing zodanig sturen dat de eenheid van ontwerp het beste bediend wordt. Mijn doel zal iets zijn als: De speler moet intrinsiek gemotiveerd de voorgelegde puzzels oplossen, en daarbij de koppeling naar de werkelijkheid kunnen maken. De speler moet (de drijfveer achter) zijn handelingen kunnen benoemen en onthouden. Dit moet werken zowel in een adventure setting als in een vorm waarin de puzzels “an sich”gepresenteerd worden. Het is een misverstand om te geloven dat het onderwerp (ruimtereis, 16e eeuw, atlantis etc.) ondergeschikt zijn aan een doel. Een spel gaat niet over een periode of setting maar over abstracties als “elektriciteit leren”, “ervaring opdoen met ruimtelijke ordening (sim city)”, leidinggeven, etc.
2. Onderzoek en voorbereiding Als een doel en onderwerp bedacht zijn begint de periode van oriëntatie. Vergaar zoveel mogelijk informatie over de beide aspecten en laat dit “borrelen”. In deze fase moet je NOG NIET GAAN PROGRAMMEREN. Je bedenkt zoveel mogelijk ideetjes en schrijft deze op. Beschrijf hoe je ze gaat implementeren, maar wees later bereid om ze op te geven als ze niet helemaal in het ontwerp blijken te passen. (zie eerste scène op de straat van de elektriciteit pilot van M.Koops, deze scène had beter achterwege gelaten kunnen worden maar is in het spel gebleven “omdat ie al bestond”. Uit speelervaringen is inmiddels gebleken dat ik direct sterk had moeten zijn en dit staaltje lastig programmeerwerk had moeten offeren aan de speelbaarheid en “momentum”).
3. Ontwerp fase In de ontwerp fase moeten drie onderdelen samengevoegd worden: the I/O structuur, de spelstructuur en de programmastructuur. Deze drie moeten simultaan worden ontwikkeld omdat ze in harmonie moeten samenwerken. I/O structuur De I/O structuur moet effectief zijn. Maak geen schitterende plaatjes die afleiden van de essentie maar maak ze ook niet te saai. Breng details aan war het functioneel is. Voorkom verder een frustrerende interface. Een optie die niet werkt waar de speler dat intuïtief wel verwacht is erg frustrerend en de speler zal afhaken. Een goede interface stelt de speler in staat om stevige interactie hebben met de virtuele omgeving, liefst een groot aantal variabelen te beïnvloeden, en er helemaal in op te gaan. Tegelijkertijd moet deze interactie door de I/O interface van de computer verwerkt worden op een intuïtieve manier. Dit dilemma wordt door de ontwerpers creativiteit opgelost, door een heldere input structuur te bedenken waarin veel opties mogelijk zijn. Dat is niet makkelijk, maar kicken als het is gelukt!! De I/O structuur voor het elektriciteitsspel wordt overgenomen van AGS adventure games die hun sporen reeds verdiend hebben Game structuur Centrale probleem is hoe je doel en onderwerp in een structuur giet die beide recht doet. Je moet een “key element” uit de omgeving lichten en tot metafoor kneden van je doel (bijvoorbeeld in een strategisch oorlogsspel is alles terug te brengen op de centrale component: beweging). In het elektriciteitsspel dat zich in de ruimte zal afspelen is ook zo’n centrale metafoor nodig, waarom alles is terug te voeren. Via simulaties van elektriciteitsschakelingen gewenste situaties initiëren. Programmastructuur Dit is de structuur van het computerprogramma dat het spel creëert. De onderdelen uit de spelstructuur moeten hier gerepresenteerd worden in computertaal. Een modulaire opzet lijkt mij het beste, waarbij opdrachten en verhaal elkaar in programmeurtechnische zin zo min mogelijk kruisen. Evaluatie van het ontwerp ? Toets het ontwerp aan je doel. Bewerkstelligt het ontwerp het beoogde resultaat, zal de speler de juiste emotionele ervaringen ondergaan? ? Is het spel stabiel? Kun je niet ineens zonder brandstof komen, of juist erin verdrinken?
4. Pre-programming phase Tot dusver heb je de ontwerpen schetsmatig opgezet. Nu wordt het tijd voor een volledige documentatie van het spel. Bepaal hoe de I/O interface er precies uit gaat zien, en definieer de interne spel-structuur.
5. Programming phase De gemakkelijkste fase van allemaal ;-) Nu gewoon aan de slag en maken wat je bedacht hebt.
6. Play-test Het testen van het spel kan volgens Chris Crawford het beste gedaan worden door ervaren spelprogrammeurs omdat die niet met idiote onhaalbare verzoeken zullen komen. Ik denk dat het testen met de toekomstige doelgroep interessanter is. Dus op dit valk zal ik me niet aan de aanbevelingen van de schrijver houden.
