De afgelopen nacht hebben we tot half zeven doorgewerkt om onze inzending voor de Game Development Rally 2009 van de Nederlandse Game Dagen (NLGD) af te ronden. Hoewel we een en ander hebben moeten schrappen, is Kwork toch een leuke game geworden die, zeker gezien de ontwikkeltijd van amper twee maanden, een brede gameplay biedt. Tijd om eens even uitgebreid terug te kijken (aangezien ik al die tijd ook al weinig geschreven heb).

Je kunt overigens Kwork hier spelen.

Opdracht

De casus voor de NLGD GDR 2009 was: ontwikkel een Tamagotchi-achtige game, gericht op chronisch zieke kinderen van 8 tot 12 jaar. De game zou uiteindelijk moeten gaan passen in de online omgeving van de CliniClowns, Villa Neuzenroode. Nu lopen de rillingen mij al over de rug bij het woord Clown (en zeker van het type Clini) maar het was een mooie aanleiding om, samen met vier studenten Game Design & Development, de stoute schoenen aan te trekken en mee te doen.

Dit alles niet helemaal zonder eigenbelang: de prijs voor de winnaar is €20.000,- en zelfs gedeeld door vijf is dat nog een leuke aanwinst. De competitie was open voor studenten maar ook professionele ontwikkelaars, zolang de game studio maar niet groter was dan 10 personen.

Concept

Het game design concept waar we al snel mee kwamen was een combinatie tussen een kindvriendelijke stijl (cartoon-achtig) met serieuze, niet kinderachtige gameplay. We hebben elementen uit role-playing games in een vrolijke omgeving gebracht en toegepast in de verzorgende Tamagotchi-vorm.

De speler ontwikkelt een karaktertje, een Kwork, die bestaat uit een lichaampje met een staartje, een bekje en oogjes. De onderdelen zijn vervangbaar en in de loop van het spel kan de speler een eigen karakter ontwikkelen door lichaamsdelen te verzamelen. Helemaal in RPG-stijl beschikt de speler over vuur, ijs, electro en gif-eigenschappen, die naar mate de game vordert verder ontwikkeld worden. Verder verzamelt de speler eten dat daarna aan de Kwork gevoerd kan worden.

De game is zo veel mogelijk vrijgehouden van tekst — nagenoeg alles wordt met symbolen en vooral met kleuren weergegeven. Zo is de health aangegeven met een glow die in sterkte afneemt als de health daalt. De helderheid van de kleur van de Kwork daalt mee. De kleur zelf wordt weer bepaald door de mix van de vier eigenschappen: meer vuur geeft meer rood en meer ijs geeft juist meer blauw. Zo kun je steeds zien waar je Kwork goed in is.

Gameplay

De gameplay is opgedeeld in twee gameplay modes: travel en battle. In travel-mode reis je door een wereld met items, quests en arena’s. In battle-mode neem je het op tegen andere Kworks. De navigatie wilden we eenvoudig maar wel spannend maken en dus kozen we voor een muisgestuurde besturing met een geschakeld karaktertje — niet helemaal onbekend met Flow natuurlijk.

Voor het battle-systeem is gebruik gemaakt van de vier eigenschappen (vuur, ijs, electro en gif) in combinatie met vier moves: verdedigend (dodge), aanvallend (charge), aanvallen op afstand (ranged) en je wonden likken (heal). In de basis is het systeem gebaseerd op rock-paper-scissors, waarbij de combinatie van eigenschappen, skills en moves bepaalt hoe effectief je actie is. Met de juiste karakterontwikkeling en moves kun je elke vijand verslaan.

Save games

Omdat een RPG met karakterontwikkeling over langere tijd plaatsvindt, konden we niet om save games heen. Allereerst was er vanuit de opdracht sprake van een zogenaamde Game Service, waarin user accounts en high scores geregeld zouden zijn. Hoewel er een specificatie werd gegeven, is nooit duidelijk geworden hoe een game aan de juiste authenticatie komt om scores op te slaan en users op te vragen. We moesten (blijkbaar) dus in allerijl ons eigen user-systeem bouwen.

Na in de weer te zijn geweest met registratieforms, profielpagina’s in PHP en een database in SQL hebben we een simpele oplossing gekozen: de voortgang wordt opgeslagen in een uitgebreide cookie. Zo gaat het spel steeds verder waar je was gebleven.

Bugs

Ondanks dat er een en ander aan functionaliteit is gesneuveld, is het spel toch redelijkerwijs afgekomen. Zoals elk goed spel zitten er natuurlijk bugs in. De twee meest storende hebben te maken met het level design en de achterliggende code. Oorspronkelijk hadden de levels geen grenzen (zoals in Flow) en was er geen collision detection nodig; later kwamen er grenzen bij.

Allereerst worden items gegenereerd niet goed geplaatst: deze staan soms in de modder, waar je dus niet kunt komen. Het simpele placement algoritme gokt random een plek totdat er geen collision is met de randen. Om te voorkomen dat het spel hier blijft hangen wordt na een stuk of 20 keer het item hoe dan ook geplaatst. Maar wellicht zit hier een foutje in.

Ten tweede kan een speler met een beetje goede wil zijn Kwork toch door een muur sturen en het level verlaten. Dit komt omdat een Kwork altijd een beetje ruimte nodig heeft om te draaien, wat het oplossen van collision lastig maakt. De collision situatie zal altijd even blijven bestaan. Als iemand hier een goed en eenvoudig idee voor heeft houd ik mij aanbevolen!

Voordeel is wel dat navigatie-bug de placement-bug opheft: je kunt nu toch de items ophalen waar je niet zou moeten kunnen komen…

Slot

Ik hoop later nog in te gaan op een paar specifieke leermomenten in dit development traject. Voor ons was het wel een domper er halverwege achter te komen dat de prijzen niet direct in geld (€20.000,-) maar deels in natura (support voor het starten van een bedrijf) zouden worden uitgekeerd. Dit was ons niet duidelijk vanaf het begin. Zeker omdat ook bestaande developers mochten meedoen.

Verder ontbrak de al genoemde user-service uit de opdracht en werd i.p.v. het opgeleverde totaalconcept (site, intro, uitleg, etc.) opeeens gevraagd om alleen de SWF. Uit z’n context geplaatst, is het veel lastiger het spel ineens te begrijpen. Zo werden we op een aantal punten verrast door de organisatie, die de regels hier en daar anders interpreteerden dan wij.