Design

In dit blog zal ik uitweiden over het ontwerpproces tijdens The River Challenge. Er zijn twee game designers binnen het team, Leea Verschelden en ikzelf, Wytze Kamp. Bij beslissingen overleggen we in ieder geval met beide designers en vaak in samenspraak met de rest van het team.

Vooronderzoek & briefing

Op 6 februari zijn we begonnen met het project en hebben we allen tijd besteed aan een kort vooronderzoek naar de klant en gerelateerde riviermanagement projecten als voorbereiding op de briefing van 10 februari. Op deze briefing hebben we kennis gemaakt met de klant en is de opdracht uitgelegd. We hebben de opdracht gekregen om een digitaal spel te maken over riviermanagement met een aantal eisen, namelijk:

• Het spel is gericht op scholieren die met de laatste jaren van de middelbare school bezig zijn.
• Het spel is toegankelijk voor een grote groep mensen.
• Spelers leren spelenderwijs over de problematiek en dilemma’s van riviermanagement.
• Er wordt informatie verzameld over de beslissingen die spelers maken en deze data wordt verstuurd naar Universiteit Utrecht.

We hebben bij de briefing ook een bordspel gespeeld dat ontworpen was door de klant. Hierin moest de afweging worden gemaakt tussen een aantal maatregelen bij een riviernederzetting. Vervolgens werd er 25 jaar verder gekeken om de gevolgen van deze beslissing te zien. Er waren een aantal dingen die de klant zelf anders wilde zien dan in het bordspel. Ten eerste lag de nadruk in het bordspel vrijwel volledig op veiligheid, terwijl er ook moet worden gedacht aan het gebruik maken van water. Verder waren er enkele termen die moeilijk te begrijpen waren voor leken (zoals ons). Toegankelijkheid is één van de belangrijkste punten van ons spel, dus we moeten hier rekening mee houden in ons ontwerp.

Brainstorm

Na de briefing hebben we een brainstorm gehouden met de gehele groep. Er kwamen een aantal interessante ideeën op tafel, maar de ideeënstroom kwam langzaam op gang en is nooit op volle kracht gekomen. Naar aanleiding van het teleurstellende resultaat hebben we enkele dagen later een tweede brainstorm georganiseerd. Deze verliep beter en we genereerden aanzienlijk meer ideeën met potentie.

Na het filteren en verzamelen van de resultaten van beide brainstorm sessies hebben we idee voor idee gezamenlijk bekeken. Hierbij noemden we eerst de positieve en interessante punten van elk concept, gevolgd door een kritische benoeming van de negatieve punten. Op basis hiervan hielden we een beperkt aantal ideeën over. Hierop volgde een stemronde om een uiteindelijke selectie te maken van 3 verder uit te werken concepten. Unaniem hebben we toen gekozen voor het Piramide spel, de NederNomaden en Saboteur.

Uitwerking concepten

Voor de uitwerking van idee naar volledig spelconcept hebben we de groep opgesplitst. Leea en Lennard hebben in eerste instantie gewerkt aan Piramide, terwijl Amanda en ik hebben gewerkt aan Saboteur. Deze tijd heeft Serge besteed om onderzoek te doen naar de mogelijkheden van ontwikkelingsplatformen. Daarna heeft de hele groep gezamenlijk NederNomaden verder uitgewerkt tijdens mijn afwezigheid.

Van Piramide tot Paleis op de Dam

Het idee van Piramide was dat 4 spelers aan een gemeenschappelijk gebouw werken in een rivierdelta. Door de structuur van de rivierdelta heeft elke speler een individueel beheerd stuk rivier, een stuk beheerd door 2 spelers en een gemeenschappelijk stuk rivier dat wordt beheerd door 4 spelers.

Het doel van dit spel was om conflicten tussen spelers te veroorzaken, waardoor zij gedwongen waren om een compromis met elkaar te sluiten. Dit sluit aan bij de wrijving tussen meerdere groepen in echt riviermanagement. We wilden dit resultaat bereiken door elke speler een eigen type boot te geven, met een aantal vereisten en eigenschappen. Dit wordt pas een echte uitdaging wanneer twee spelers met verschillende eisen over hetzelfde stuk rivier moeten varen om bij te dragen aan de bouw van de ‘piramide’.

Na evaluatie van het concept besloten we dat het zich teveel richtte op scheepvaart. Om dit te verhelpen hebben we het achterliggende idee van een dorp uitgebreid als een centraler spelelement. De speler moet de te vervoeren grondstoffen verzamelen met de inwoners. Hiervoor moeten de inwoners tevreden en productief blijven, en dus beschermd worden tegen het water. Droogte en overstromingen zullen grote problemen opleveren, omdat de boten, gebouwen en bevolking hierdoor schade op zullen lopen.

Om voldoende boten, materialen en mankrachten aan te leveren is het belangrijk dat de speler goed voor zijn inwoners zorgt. De groei, het geluk en de veiligheid van de bevolking zijn belangrijke factoren die het bouwproces van het paleis beïnvloeden. Hierdoor ontstaat er een dilemma waarbij de speler zowel de investering in bevolking en in paleisbouw goed zal moeten afwegen. Teveel bouw aan het paleis betekent uiteindelijk een langzame vooruitgang in de samenleving. Investeer teveel in de samenleving en de bouw van het paleis duurt te lang.

De speler zal zich in eerste instantie met zijn eigen stuk rivier en samenleving bezig houden, om de levering van bouwstoffen en arbeidskrachten op gang te krijgen. Daarna zal hij zich gedwongen voelen om te overleggen met andere spelers en gezamenlijk besluiten te nemen. Het overleg zal daarna moeilijker worden, doordat er nog meer mensen zijn met eigen belangen. Daarnaast zal de speler bezig zijn met het dilemma tussen paleisbouw en ontwikkeling van de samenleving. Spelers zullen zowel coöperatief bezig willen zijn als competitief, want ze willen een zo groot mogelijk bijdragen leveren.

Om het thema toepasselijker te maken voor de opdracht hebben we de bouw van de piramide vervangen met het bouwen van het Paleis op de Dam en is de naam daarop aangepast.

Van Saboteur tot Rollenspel

Saboteur begon als een idee waarbij 4 spelers voor een spelcomputer zitten en één van hen heimelijk het bericht krijgt dat hij de saboteur is. De spelers kregen in dit spel de mogelijkheid een karakter te bewegen en onderweg vlakken te verhogen, verlagen en te bebouwen. De saboteur kon daarnaast nog een kleine invloed op de rivier uitoefenen.

Het doel van de saboteur is om een bepaalde hoeveelheid schade te veroorzaken aan de bouwwerken van spelers.  Het doel van de overige spelers is om een bepaald niveau van welvaart te bereiken. Wanneer één van de twee groepen het doel haalt, zal het spel eindigen.

Wanneer de saboteur genoeg schade heeft veroorzaakt is hij de winnaar en verliezen de andere 3 spelers. Ze worden wel gerangschikt op mate van welvaart.

Wanneer de overige spelers gezamenlijk genoeg welvaart hebben opgebouwd, dan winnen deze 3 spelers en verliest de saboteur. De spelers worden gerangschikt op mate van welvaart.

Als het spel eindigt zullen alle spelers (behalve de saboteur) individueel aangeven wie er volgens hen de saboteur is, dit gebeurt voor de puntenweergave. De spelers die goed gekozen hebben krijgen een bonus bovenop hun punten.

Dit concept is uitgewerkt naar een papieren prototype en getest. Uit de test bleek onder andere dat de saboteur nog veel te veel macht had om andere spelers tegen te werken. De saboteur won in een vrij korte tijd. De spelers hadden bovendien moeite om goed te bouwen, omdat er zoveel vereisten aan elk gebouw zaten. Daarnaast lag de focus van het spel heel sterk op één persoon die specifiek aangewezen was als saboteur.

Om het concept interessanter te maken hebben we de beslissing gemaakt om het spel minder te richten op één saboteur en meer op emergente conflicten tussen meerdere spelers. De speler zal een kleine samenleving op zijn eigen manier ontwikkelen en eraan gehecht raken. Er zullen spelers in de buurt zijn die meehelpen of tegenwerken met de tactiek die de speler voor zichzelf heeft gekozen. Sommige spelers zullen erg geschikt blijken om mee samen te werken, terwijl andere spelers wrijving opleveren. Door deze factoren zal de speler praten met andere spelers zodat hij met andere mensen problemen zoals overstromingen en droogte kan oplossen.

Spelers beheren samen met andere mensen (bekend en onbekend) een stuk grond inclusief rivier en ontwikkelen hun eigen samenleving/dorp. Mensen kunnen titels en badges verdienen met hun gedrag en attitude ten opzichte van de omgeving en andere spelers. Deze titels leiden tot verschillende invalshoeken en tactieken in de ontwikkeling van de samenleving en het rivier management. Door de combinatie van invalshoeken zullen mensen met elkaar samenwerken of juist tegenwerken. Tijdens de sociale interactie die ontstaat wisselen mensen hun redenering uit en krijgen alle spelers een bredere kijk op riviermanagement en het ontwikkelen van hun samenleving.

Verschillende voorbeelden van te behalen titels zijn ‘Innovator’, ‘Natuurliefhebber’, ‘Ecoterrorist’, ‘Collaborateur’, ‘Agrariër’ en ‘Havenmeester’.

Om hun doelen te behalen hebben spelers voldoende mogelijkheden, zoals het plaatsen van huizen, fabrieken, boerderijen, natuurgebieden en dijken; het opwaarderen van de geplaatste gebouwen om de kwaliteit daarvan te verbeteren; handelen met andere spelers om voldoende grondstoffen te verzamelen.

Spelers zullen een beperkt aantal keren per dag een actie kunnen uitvoeren, zodat er asynchroon (los van elkaar) gespeeld kan worden. Daarnaast kunnen ze het berichtensysteem van het sociale netwerk gebruiken om informatie uit te wisselen en te praten. Het grootste deel van middelbare scholieren en studenten is aangemeld op Facebook. Daarnaast is dit spel simpel en begrijpelijk, zodat mensen die niet veel games spelen er weinig moeite mee zullen hebben.

Voor het vernieuwde concept heeft Amanda een digitaal prototype gemaakt met behulp van Excel. In de eerste test waren de mechanismes voor waterstanden en blijheid van mensen nog niet geïmplementeerd. Hierdoor negeerde één speler compleet het doel van het spel en richtte zich compleet op het tegenwerken van een andere speler. Ondanks zijn minachting voor het speldoel won hij bijna, maar één speler die wel op het speldoel lette won het spel uiteindelijk. Het spel miste op dit punt nog een sterke ‘klik’, iets wat ervoor zorgt dat het leuk blijft om te spelen.

De titel van het spel is aangepast naar Rollenspel, vanwege de verschillende titels die spelers kunnen nastreven en de rol die ze daardoor vervullen.

Van NederNomaden naar River Rivals

NederNomaden was een verzameling van ideeën, meer een thema dan een concreet spelidee. We hebben een aantal keren uitgebreid gepraat over het concept en we vonden wel een aantal interessante richtingen. De meest interessante vonden we een spel waarbij het doel was om met nomaden langs de rivier te reizen en zowel behoefte had om de rivier te laten overstromen als om de rivier in toom te houden.

Het idee heeft zich uiteindelijk ontwikkeld naar een concept geïnspireerd door Dungeon Keeper. Met als uitgangspunt om de rivier zowel bewust te laten overstromen als de rivier onder controle te houden werd het onderstaande concept ontwikkeld.

Rivier rivalen is een competitie tussen twee spelers, waarbij het doel is om de tegenstander zo veel mogelijk schade toe te brengen terwijl je je eigen inwoners veilig houdt. Spelers beheren een drietal verschillende werkers, namelijk boerinnen, bouwvakkers en waterwerkers. Elk van deze werkers heeft een aantal eigen functies en benodigdheden. Alle werkers hebben voedsel nodig, daarnaast hebben ze een leef- en werkgebied nodig om vrolijk te blijven.

Boerinnen verbouwen de gewassen en oogsten deze, zodat er altijd voldoende voedsel is voor de bevolking. Zij werken op de boerderij/natuurgebieden.

Bouwvakkers zorgen ervoor dat er gebouwen worden gebouwd, dat het terrein bewerkt wordt zodat het werkbaar is en zij verhogen en verlagen het land waar dat nodig is. Ze bouwen op het land.

Waterwerkers zijn verantwoordelijk voor de rivier en alle bouwwerken die hiermee te maken hebben. Zij bouwen schepen, baggeren de rivier en voeren alle andere werkzaamheden in het water uit. Hiervoor werken ze op gedeeltelijk ondergelopen gebied.

Boten kunnen alleen varen wanneer de rivier diep genoeg is en  dus niet te droog ligt. Boten leveren extra bouwmateriaal, maar moeten afgeladen worden door waterwerkers.

Verder kunnen de spelers de waterstromen op een aantal manieren tijdelijk aanpassen. Denk hierbij aan het tijdelijk verhogen en verlagen van het waterpeil, een enkele hoge golf sturen of het blokkeren van de rivier op een punt.

Rivier Rivalen zal de speler onder druk zetten om zichzelf snel te ontwikkelen, de sterke en zwakke punten van het land van zowel zichzelf als de tegenstander in de gaten te houden, en ook gebruik te maken van deze analyse. Daarnaast zal hij te maken krijgen met het dilemma tussen water binnenlaten om land bruikbaar te houden en  het buitenhouden van water ter veiligheid van de inwoners. Daarnaast moet er een balans gehouden worden in de grootte van de verschillende werkers, teveel van één soort zal leiden tot verspilling van grondstoffen, inefficiënt landgebruik of de dood/het verlaten van werkers.

Door de directe competitie tussen de 2 spelers hebben we dit spel River Rivals genoemd.

Concept pitch

Naast het uitwerken van spelmechanismes en bepalen van speldoelen is er door Amanda en Lennard voor elk concept een stijl voorgesteld. Om voor te bereiden op de concept pitch heb ik eerst een overzichtsdocument gemaakt waarin elk concept in detail beschreven staat. Deze informatie heb ik met beeldmateriaal gecombineerd en een eerste opzet gemaakt voor de concept pitch. Van alle drie de concepten in de presentatie zijn de doelen, de unieke kwaliteiten en een oppervlakkig overzicht van de spelmechanismes beschreven. Met deze concept pitch zijn we naar Universiteit Utrecht gegaan.

De klant was voornamelijk enthousiast over het Rollenspel en River Rivals. Paleis op de Dam was naar hun idee te beperkt in focus, doordat er alsnog veel nadruk lag op de scheepvaart. Ze vonden het overleg tussen een grotere groep mensen wel interessant.

Het Rollenspel vonden ze sterk vanwege de verschillende perspectieven waar de speler mee te maken krijgt en de toepassing van Facebook als platform. Ze zagen echter nog niet wat de speler daadwerkelijk aan het doen was en hoe hij te maken kreeg met de andere spelers.

River Rivals vonden ze sterk vanwege de aandacht voor de verschillende groepen die hun eigen eisen en taken hadden en de sterke focus op het in balans houden van het water. Daarnaast vonden ze de directe competitie tussen spelers een sterk element van het spel.

Na de uitweiding van de klant over de verschillende concepten vroegen zij ons welk concept onze favoriet was. We hebben toen aangegeven dat we het liefst aan de gang wilden met River Rivals, unanieme favoriet binnen de groep. De klant heeft hiermee ingestemd onder de voorwaarde dat we een aantal veranderingen zouden maken aan het concept.

Conceptvoorstel & reactie

Naar aanleiding van de wensen van de klant zijn we een week lang bezig geweest om een vernieuwd concept te ontwerpen en documenteren. Dit conceptvoorstel kun je hier vinden:

https://docs.google.com/open?id=0B4BUHaisYEtXM19sS0dScmxOZkE

Een week later hebben we de reactie op het conceptvoorstel ontvangen van de klant. Het voornaamste punt daarin was dat de focus van het spel bij waterbeheer moet blijven. Elk spelelement moet op de één of andere manier afhankelijk zijn of een verband hebben met water.

Op de planning stond dat we al op 12 april zouden testen, maar naar mijn idee waren er nog niet genoeg functionaliteiten ingebouwd om een nuttige test uit te voeren. Achteraf gezien was dit een naïeve beslissing. We hadden op dat punt al speler feedback kunnen gebruiken, ondanks het ontbreken van een groot aantal spelmechanismes.

De twee weken daarna heb ik met Leea veel overleg gepleegd om het concept aan te passen aan de reactie van de klant, in meer detail uit te werken en de achterliggende spelmechanismes te beschrijven. In deze tijd hebben we veel kleine beslissingen gemaakt, maar er waren een aantal punten waar we niet uit konden komen.

Week van 23-04

Uiteindelijk stuitten we in het game design tegen een aantal problemen aan. Ten eerste was het doel van het spel te ‘vaag’, niet meetbaar genoeg. Daarnaast wilden we de focus van het spel verder op de rivier leggen en ons aanpassen aan een aantal andere wensen van de klant. Leea en ik kwamen niet uit de problemen dus hebben we de hulp van het hele team erbij geroepen. We hebben uitgelegd hoe we ervoor stonden in design en welke problemen we hadden. Uit dit gesprek zijn een aantal grote veranderingen voortgekomen.

Ten eerste wisselde het doel van het ‘high score’ model afhankelijk van de blijheid van wethouders, naar een systeem waarbij de speler zelf meer inbreng had. De speler krijgt de keuze uit een aantal ‘bouwdoelen’, waarbij hij kan kiezen om bijvoorbeeld 3 fabrieken te bouwen. Als de speler dit doel behaald heeft en zijn wethouders zijn tevreden, dan mag hij een nieuw doel kiezen. Hierdoor heeft de speler een moment om duidelijke voorkeur aan te geven en een meetbaar doel. De tijd van de speler wordt bijgehouden, dus hoe sneller een speler zijn doelen behaald hoe beter.

Een ander probleem dat we hadden was dat de fabriek niets met water te maken had, en zowel de fabriek als de haven geen duidelijke functie leken te hebben. De enige reden om die gebouwen te maken, was om de wethouders tevreden te houden. Daarom hebben we de fabriek goederen laten produceren die naar de haven vervoerd moesten worden. De boten die bij de haven komen zullen daarna de goederen exporteren.

Bomen misten interessante gameplay. De speler zet deze eenmaal neer en dan zouden ze blijven staan. In plaats daarvan hebben we besloten dat bomen vanzelf gaan groeien op grond met voldoende vochtigheid. Hierdoor heeft de speler geen directe controle over de plaatsing van bomen, maar kan hij wel een bewuste invloed daar op uitoefenen.

Om de spelers een extra hulpmiddel te geven ter beheersing van het water hebben we besloten een sluis toe te voegen aan het spel. Met sluizen kan de speler een gebied specifiek wel of niet onder laten lopen en kan hij door slim te spelen minder afhankelijk zijn van de hoogte van het water. Een sluis wordt neergezet tussen 2 verhoogde stukken land en er kunnen een aantal sluizen boven op elkaar worden neergezet. Door op te de sluis te klikken opent deze zich en wordt er water doorgelaten. Als het water hoger komt te liggen dan de sluis, dan zal de sluis kapot gaan.

Een laatste punt van verwarring en overbodige complexiteit in het ontwerp waren de werkers in het spel. In eerste instantie wilden we 3 verschillende werkers maken die elk hun eigen taken hadden. Tijdens deze meeting hebben we besloten dat er 1 type werker is die alle taken zal uitvoeren.

Week van 07-05

Op 9 mei hebben we een playtest uitgevoerd met het digitale prototype. We hebben bij 2 spelers getest en daaruit kwamen veel verwachte en onverwachte problemen. Het speldoel was nog niet in het spel geïmplementeerd, maar dit hebben we vervangen met fysieke kaarten die het doel aangeven. Verder hebben we de tutorial en enkele informatie mechanismes vervangen met een mondelingen uitleg van de controls en spelmechanismes. Hierbij hebben we erop gelet dat we evenveel informatie gaven als het spel zou doen. We hebben beide playtests gefilmd met een camera, gericht op de speler. Bij de 2^e playtest hebben we Fraps geïnstalleerd voor het maken van schermopnames.

Beide spelers vonden dat het spel goed functioneerde. De besturing was duidelijk, alhoewel ze liever een klik-en-sleep mechanisme voor het bouwen hadden gehad. Dit besturingselement stond al wel gepland, maar was nog niet geïmplementeerd.

Spelers wisten niet waar ze moesten beginnen met het spel. Daarnaast was het onduidelijk voor de spelers welke functies de haven en fabriek hadden en wisten ze niet dat de twee van elkaar afhankelijk waren. Bovendien werd de vraag ‘waarom exporteer ik?’ gesteld.

Eén van de grootste problemen was dat de speler compleet niet aan het letten waren op de wethouders. Deze tekst stond slecht leesbaar onderin het scherm, maar ze wisten sowieso niet welke informatie hiermee werd gecommuniceerd en wat voor effect dat op henzelf had.

Nog enkele kleine waarnemingen: De bomen groeiden overal, maar spelers wisten niet waarom en bemoeiden zich er niet mee.  Het water vormde geen dreiging, er waren wel overstromingen maar gebouwen ging niet kapot. Er was met één boerderij een overvloed aan voedsel.

Het grootste probleem leek de doelloosheid van de spelers. Ze waren wel naar hun doel aan het toe werken, maar ze waren simpelweg de bouwinstructies aan het volgen zonder naar een hoger doel toe te werken.

Na afloop van de playtest hebben Leea en ik het videomateriaal geanalyseerd en hebben een aantal ontwerpkeuzes gemaakt. Een probleem waar we geen oplossing voor konden vinden was het doel van het spel. We hebben alle waarnemingen, conclusies en oplossingen op het whiteboard geschreven en de rest van het team geïnformeerd. Door middel van een korte brainstorm zijn we toen tot de volgende  iteraties gekomen.

Het doel van het spel veranderd compleet. Spelers moeten een zo groot mogelijke bevolking accommoderen en verzorgen. In plaats van bevolkingsgroei door nieuwe huizen te bouwen, komen er nu vanzelf inwoners bij je dorp. Deze zul je vervolgens moeten verzorgen door eten, huizen, handel en natuur te verzorgen. De speler wint het spel wanneer hij 20 inwoners heeft verzameld en deze allemaal tevreden zijn. Het spel wordt verloren wanneer het geluk van de inwoners onder de 30% daalt.

Om het geluk van de mensen te versimpelen hebben we de 4 verschillende wethouders samengevoegd tot het algemene geluk van de burgers. Hierdoor hoeft de speler slechts 1 gelukswaarde in de gaten te houden. Gevolg hiervan is dat het doel om de speler voorkeur aan te laten geven voor bepaalde bevolkingsgroepen hierdoor verdwijnt. Met oog op de resterende tijd is dit een verstandige beslissing, aangezien we niet genoeg tijd hebben om uitgebreid te experimenteren voor een oplossing die dit doel bereikt.

In eerste instantie zouden wethouders aangeven dat er problemen waren bij bepaalde gebouwen, zoals het gebrek aan werkers bij fabrieken of droogte bij een boerderij. Om de feedback naar de speler directer te maken en door het verwijderen van de wethouders, hebben we besloten om deze problemen bij het desbetreffende gebouw te plaatsen.

Een andere versimpeling van het spel is het samenbrengen van ‘werkers’ en ‘inwoners’. In eerste instantie waren dit twee verschillende dingen. Bij het verhogen van inwoners ging het aantal werkers wel omhoog, maar werkers konden dood door gebrek aan voedsel zonder dat het inwoneraantal daalde. Nu zijn werkers hetzelfde als inwoners. Inwoners kunnen niet meer dood door verhongering, in plaats daarvan gaat het geluk van de mensen omlaag en zal de speler daardoor verliezen.

De spelers wisten niet hoe ze moesten beginnen, daarom hebben we besloten voor de volgende test een aantal gebouwen te plaatsen in het level. Hierdoor kunnen spelers bij de bestaande gebouwen afkijken wat hun functie is en hebben ze een beginsituatie om vanuit verder te bouwen.

Verder willen we de speler meer controle en begrip geven van de bomen. Vanaf nu zal de speler zelf bomen moeten planten en deze zullen zich verspreiden naar aanliggende vlakken als ze volgroeid zijn.

Uiteindelijk hebben we besloten om het hele multiplayer component van het spel te verwijderen, omdat dit niet gaat lukken in de tijd die we hebben. We kunnen de belangrijkste doelen die we voor het spel hebben opgezet wel behouden, alleen niet de doelen die betrekking hebben op de competitie tussen de twee spelers. Ter vervanging van een mens als tegenstander hebben we besloten spelsessies van spelers op te slaan en deze bij andere spelsessie af te spelen. Hierdoor wekken we wel de indruk dat er een tegenstander  in het spel zit en zal er alsnog een sterker gevoel van competitie aanwezig zijn. Bovendien kan de speler dan leren van de tactieken van de gesimuleerde tegenstander.

Week van 21-05

Op 24 mei zijn Lisa en ik eerst naar de klant gegaan. We hebben daar het meest recente prototype laten zien en onze ontwerpkeuzes uitgelegd. Ze waren zeer tevreden, maar hadden nog wel enkele suggesties voor ons. Ten eerste het toevoegen van ‘speltips’ die de speler prikkelen om te reflecteren op zijn keuzes en hem in de goede richting kunnen helpen. Daarnaast kwam er nog de suggestie voor een moeilijkheidsgraad, waarbij de wateraanvoer heftiger ingesteld zou zijn. Dit zijn twee toevoegingen die we van plan zijn om te implementeren.

Later op de dag hebben we een drietal playtests uitgevoerd. We hebben opnieuw de tests opgenomen met een camera op de speler gericht en Fraps voor schermopnames.

In de versie van het prototype dat we hebben gebruikt was het speldoel nog niet geïmplementeerd. We hebben in plaats daarvan opnieuw een blad uitgeprint met daarop de doelen van het spel.

De belangrijkste waarnemingen waren als volgt:

• De drie mensen die hebben getest hebben alle drie verloren. De eerste tester verloor door een gebrek aan voedsel, hij liet zijn boerderijen droog staan. De andere twee verloren door een onverwachte vloedgolf van de rivier.
• Er mist directe feedback wanneer je voedsel krijgt, goederen vervoert of als er iets kapot gaat.
• Spelers begrepen de verschillende functies van de gebouwen niet. Zo begrepen ze niet dat er een fabriek moet worden gebouwd voordat je met je haven goederen kunt exporteren.
• Eén speler zei ‘Nu staat het er allemaal toch? Wat moet ik doen?’. Bovendien had hij het gevoel dat hij uiteindelijk niets bereikt had.
• Twee van de spelers waren zich er in eerste instantie niet van bewust dat het water vanzelf steeg en daalde. Hierdoor werden ze uiteindelijk verrast door een golf die hun gebouwen vernielde.

Naar aanleiding van deze playtest hebben we een beperkt aantal beslissingen gemaakt. In verband met de resterende tijd hebben we niet zoveel aanpassingen kunnen maken als we hadden gewild.

De grootste verandering is dat de speler opnieuw met een leeg speelveld begint. De tutorial en de gebouwen zelf leggen de werking van elk van de gebouwen aan de spelers uit tijdens het spelen. Hierdoor bouwt de speler zelf begrip op van de gebouwen en heeft hij complete controle over het indelen van zijn stad.

Daarnaast hebben we de functie van fabrieken en havens sterker gemaakt. Eerst moest een bepaald aantal goederen geëxporteerd worden op een bepaald aantal inwoners. Nu levert het exporteren van goederen geld op. Dit geld wordt niet gebruikt om te bouwen, maar wordt geconsumeerd zoals dat al met voedsel gebeurde. Elke inwoner heeft een vaste consumptie en de hoeveelheid geëxporteerde goederen zal dus moeten stijgen met het stijgen van het inwonersaantal. Hierdoor is het nut van fabrieken en havens helder voor de spelers.

Laatste 2 weken

We hebben in de laatste en voorlaatste week nog playtests uitgevoerd, maar we hebben geen veranderingen meer kunnen implementeren die daaruit voortkwamen. Onder andere merkten we dat de spelers meer controle wilden over het bouwen. Op dit moment heeft een gebouw 3 bij 3 vlakken nodig om gebouwd te worden, maar dit mechanisme haalt een deel van de controle van de speler weg. Daarnaast werkt het mechanisme net iets anders dan spelers in eerste instantie verwachten.

Verder hebben we gemerkt dat veel van onze doelen met het spel behaald worden. Spelers leren elke ronde dat ze spelen hoe ze de rivier kunnen gebruiken en hoe ze zich er tegen kunnen beschermen. Ze proberen oplossingen te vinden die zowel bij laag als hoog water functioneren. Elke ronde van een speler wordt er weer iets nieuws geleerd en gereflecteerd.

We hebben de laatste week besloten dat de simulatie van de andere speler niet geïmplementeerd wordt, omdat we daar geen tijd voor hadden. Daarnaast zijn er enkele mechanismes gesneuveld of in mindere mate uitgewerkt dan verwacht. Hieronder staan de belangrijkste opgesomd.

• Het prioriteitensysteem van de werkers. De werkers doen nu nog niet altijd wat de speler verwacht of verlangt.
• Aangeven waar je een gebouw wilt plaatsen zou de speler meer controle en vrijheid geven.
• Het watersysteem is beperkt in de uitwerking. Een aantal functies missen, waardoor het water zich niet realistisch gedraagt en soms vreemd gedrag laat zien.
• De sluis zou een extra hulpmiddel toevoegen om het water te controleren, maar is niet essentieel om de leerdoelen van de speler te bereiken en een leuke spelervaring te creëren.
• Tips voor de speler, die hem bewust aanzetten tot reflectie tijdens en na het spelen van het spel. Dit zou spelers kunnen helpen die moeite hebben om te winnen, door hen bewuster een bepaalde denkrichting  in te sturen.
• De alarmtoren zou kort van tevoren aangeven dat er hoog water op komst is, waardoor spelers zich tot op zekere hoogte kunnen voorbereiden op een overstroming en begrijpen wat er aan de hand is.

Het belangrijkste element dat we nu nog missen, al is het geen onderdeel van de gameplay zelf, is het verzamelen en versturen van de spelsessies naar de klant. Zij hadden deze wens, zodat ze konden evalueren hoe de gemiddelde persoon over riviermanagement nadenkt. We hadden nauwelijks genoeg tijd om het spel in een goed speelbare, afgemaakte staat te krijgen, daarom hebben we deze functionaliteit helaas moeten weglaten.