Developer: Mag het ietsje meer design?



Nikki Kuppens is gamedesigner bij W!Games. In zijn column schrijft hij maandelijks over de belevenissen van een gamedeveloper.

Als je tijdens schoolprojecten aan een game werkt, dan heb je enorm veel vrijheid. Tenzij het in de opdracht is vastgelegd, kies je zelf een engine, een platform en een aanpak. Niemand die zich bemoeit met de details. Maar zodra je als professionele designer aan de slag gaat met commerciële titels, dan zijn het juist de kleinste details die nauwlettend in de gaten worden gehouden.

Vrij spel

Ineens werk je niet meer aan een game die je naar eigen inzicht in elkaar zet en werkt op de gemiddelde pc. Nu bouw je een product dat uit moet komen op één of meerdere zorgvuldig samengestelde, zeer specifieke platformen. Dat betekent dat je moet ontwikkelen op basis van de mogelijkheden en eigenschappen van die consoles. Als designer hoef je je gelukkig niet direct bezig te houden met de technische capaciteit of grafische kracht van bijvoorbeeld een PS3, maar dat wil niet zeggen dat je vrij spel hebt. Een groot deel van mijn Greed Corp-tijd heb ik namelijk doorgebracht met het bestuderen en naleven van de door platformhouders gestelde richtlijnen: de zogenaamde Technical Certification Requirements.

Mass Effect

Sony, Microsoft en Nintendo hebben hier hun eigen benamingen voor, maar in grote lijnen komt het op hetzelfde neer. Wat staat er dan zoal in die voorschriften? De documentatie hiervan is uiteraard vertrouwelijk, dus ik zal een voorbeeld geven aan de hand van een console waar ik momenteel niets mee te maken heb: de Wii. Die melding dat je het polsbandje om moet doen, zodat je televisie niet sneuvelt, moet daar een minimum aantal seconden staan. Ook of je die melding wel of niet weg mag drukken, en zo ja met welke knoppen, wordt bepaald door Nintendo. Een ander, voor de hand liggend voorschrift, is hoe groot je downloadable game als bestand maximaal mag zijn. Geen regels die echt van invloed zijn op mijn werkzaamheden, maar dat ligt anders als de platformhouder verplicht stelt dat je game bijvoorbeeld Achievements en Leaderboards bevat.

Deze voorschriften moet je niet licht opvatten, want de platformhouder weigert gewoon keihard je game als ze genoeg vinden dat niet aan hun verzoeken voldoet. Het probleem voor kleinere developers, die voor het eerst met een bepaald platform werken, is dat die documentatie nogal in de papieren kan lopen. Grotere studio’s hebben vast mensen die zich daar specifiek mee bezig houden, doorliepen al meerdere malen dat proces en kunnen vanwege hun naamsbekendheid blijkbaar wel eens gematst worden. Het beste voorbeeld daarvan zijn de teksten van Mass Effect 2, die niet te lezen zijn op een te ouderwetse televisie, maar waar Bioware mee wegkwam.

Functioneel

Sinds de huidige generatie consoles is het allemaal nog een stuk uitgebreider geworden, omdat extra functionaliteit als online gamen en gebruikersprofielen weer hun eigen set regels krijgen. De lastigste voorschriften zijn degene die invloed hebben op de kern van je game, op wat je sowieso al van plan was of nodig had. Toevoegingen als Achievements zijn er redelijk makkelijk bij te designen, maar het foutloos implementeren van ingewikkelde matchmaking, zoals die in Greed Corp, is nog een hele opgave. Als designer in een relatief klein bedrijf, dat zelf de game uitgeeft, mag je dat allemaal lekker zelf uitzoeken. Vaak betekent dit dat je eerst aardig wat moet lezen voordat je creatief en oplossend bezig kunt zijn. Vervelender is het als jouw implementatie niet geheel aan de eisen blijkt te voldoen. Zeker als je het idee hebt iets beters bedacht te hebben en gewoon bezig wilt zijn met ‘echt’ game design.

Ik wil echter niet zeuren over zogenaamd buitensporige reglementen van platformhouders. Integendeel, want als ik iets geleerd heb van het doorspitten van alle TCR’s, dan is het wel dat ze er met een reden zijn. Ze zorgen voor consistentie in alle producten op hetzelfde platform en dat betekent dat je als designer gebruik kunt maken van conventies waar gamers bekend mee zijn. Ook gaat het lang niet altijd om beperkingen, maar ook om een solide basis en bewezen oplossingen. Als je die les eenmaal geleerd hebt, dan gaan TCR’s onderdeel uitmaken van je designwerkzaamheden en wordt het een uitdaging alles zo overkoepelend op te zetten dat je slaagt op alle platformen.

3 reacties

  1. Stone · 19-5-2010 · 23.47 uur

    allereerst bedankt voor greed corp, ik speel het nu een week. en vind het te gek. oke, ik begin bijna zat te worden, maar ik ben dan bijna door de sihgle player heen. dus een interessant concept die precies lang genoeg is.

    ik snap niet zo goed wat je probleem is. eerst geef jij aan hoe lastig deze regels wel niet zijn (voor de kleinere ontwikkelaar) en dat je hun nut of noodzaak wel begrijpt . daarnaast wees blij dat je enkel aan zo weinig normen vast zit. als ik op mijn werk een project heb. (elktrotechniek) heb ik te maken met het bestek, daarnaast de NEN1010 tevens het bouwbesluit diverse andere normen bijv brandvielighied en daarboven nog eens eventeule normen van de gebruiker bijv het rijksbureau of schiphol. ik denk dat je ik je handje mag klappen met de beperkte opgelegde regel.

  2. Nikki Kuppens · 20-5-2010 · 10.19 uur

    @Stone: Het is niet mijn bedoeling dit over te brengen als een probleem, ondanks dat het wel iets verder gaat dan ‘zo weinig normen’. :)

    Het is een column over een onderwerp dat mij opviel in mijn werkzaamheden in de afronding van Greed Corp (bedankt voor de complimenten) en het werken aan te publiceren consolegames. Puur iets om gewoon eens iets over te vertellen vanuit het ontwikkelproces en waar ik veel van geleerd heb als designer.

  3. ellen · 21-5-2010 · 11.37 uur

    Mooie inkijkje van waar je als developer in de praktijk mee te maken krijgt.

Volg de reacties op deze post via RSS

Plaats een reactie

Registreer je als vaste gebruiker. Heb je dit al eens gedaan, log dan in.

Hou de discussie menselijk en inhoudelijk. Reageer bij voorkeur onder je echte naam, met je foto als avatar (via Gravatar).

Toegestane HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>