MERCHANT 2.0. Update van de locatie gebaseerde ios MMORPG Merchant Kingdom. Bedrijf Oberon Interactive. Stagebegeleider Stefan Leijnen

MERCHANT 2.0 Update van de locatie gebaseerde iOS MMORPG Merchant Kingdom

Bedrijf Oberon Interactive

Stagebegeleider Stefan Leijnen

Auteur Tom van Duist [email protected]

Bedrijfsbegeleider Richard de Boer

29 januari 2014

AFSTUDEERVERSLAG OBERON INTERACTIVE

MERCHANT 2.0 Update van de locatie gebaseerde iOS MMORPG Merchant Kingdom

Auteur Leerling-nummer Email Telefoon Onderwijsinstelling Opleiding Stagebegeleider Bedrijf Adres Telefoon Bedrijfsbegeleider Stageperiode

Tom van Duist 500603011 [email protected] 06-81695008 Hogeschool van Amsterdam Game Technology Stefan Leijnen Oberon Interactive Stadhouderskade 160, Amsterdam 020-3449480 Richard de Boer Sep. 2013 - Jan. 2014

Amsterdam, 29 januari 2014

5

Voorwoord Dit verslag is geschreven naar aanleiding van mijn afstudeerstage bij Oberon Interactive. In dit verslag zal ik zo helder mogelijk de realisatie van mijn afstudeeropdracht beschrijven. Namelijk de realisatie van Merchant 2.0, het vervolg op het locatie gebaseerde MMORPG spel Merchant Kingdom dat eerder door Oberon Interactive is uitgebracht in de Apple App Store voor iOS apparaten.

6 VOORWOORD __________________________________________________________________ 5 SAMENVATTING ________________________________________________________________ 9 1. INLEIDING___________________________________________________________________ 10 1.1 OBERON INTERACTIVE _________________________________________________________ 1.1.1 Huidige stand van zaken _________________________________________________ 1.1.2 Focus ________________________________________________________________ 1.2 MERCHANT - HET SPEL _________________________________________________________ 1.3 DE OPDRACHT_______________________________________________________________

10 10 10 11 13

2. PLAN VAN AANPAK ___________________________________________________________ 15 2.1 PROBLEEMSTELLING ___________________________________________________________ 2.1.1 Deelvragen ___________________________________________________________ 2.2 ANALYSE HUIDIGE VERSIE _______________________________________________________ 2.3 FASERING__________________________________________________________________ 2.3.1 Oriëntatie en analyse ___________________________________________________ 2.3.2 Ontwerpfase __________________________________________________________ 2.3.3 Realisatiefase _________________________________________________________ 2.3.4 Opleverfase ___________________________________________________________ 2.4 PLANNING _________________________________________________________________ 2.5 INVENTARISATIE PRODUCTEN _____________________________________________________ 2.5.1 Conclusie _____________________________________________________________ 2.5.2 Advies _______________________________________________________________

15 15 15 16 16 16 16 17 17 18 18 18

3. ANALYSEFASE________________________________________________________________ 19 3.1 SPELER STATISTIEKEN __________________________________________________________ 3.1.1 Avatar geslacht ________________________________________________________ 3.1.2 Tutorial ______________________________________________________________ 3.1.3 Guild keuze ___________________________________________________________ 3.1.4 Alle spelers op level _____________________________________________________ 3.1.5 Actieve spelers op level __________________________________________________ 3.1.6 Spelers in het eindspel ___________________________________________________ 3.1.7 Bezochte locaties _______________________________________________________ 3.2 VERKOOP STATISTIEKEN ________________________________________________________ 3.2.1 Aantal afnemers _______________________________________________________ 3.2.2 Verkoop populariteit ____________________________________________________ 3.3 CONCLUSIE _________________________________________________________________

19 20 21 22 24 25 26 27 28 28 30 32

4. ONTWERPFASE ______________________________________________________________ 33 4.1 UITWERKEN CONCEPTEN ________________________________________________________ 4.1.1 Objectives ____________________________________________________________ 4.1.2 Design _______________________________________________________________ 4.1.3 Artisan (Ambachtsman) _________________________________________________ 4.1.4 Right Hand (Rechterhand)________________________________________________ 4.1.5 Visuele karavaan _______________________________________________________ 4.1.6 Visuele schatten _______________________________________________________ 4.1.7 Betere chat functie en contact informatie ___________________________________ 4.1.8 Overig _______________________________________________________________ 4.2 INTERACTION DESIGN __________________________________________________________

33 33 34 34 34 35 35 35 35 35

7 4.3 PROTOTYPE_________________________________________________________________ 37 4.3.1 Omgevingsmap en toolbar _______________________________________________ 37 4.3.2 Popup menu en view container ____________________________________________ 38 4.3.3 Grens probleem ________________________________________________________ 39 4.3.4 Niet haalbare concepten _________________________________________________ 40 4.4 OPGELEVERDE PRODUCTEN ______________________________________________________ 42 4.4.1 Merchant 2.0 concepten _________________________________________________ 42 4.4.2 Merchant 2.0 units______________________________________________________ 42 4.4.3 Merchant 2.0 level verloop _______________________________________________ 42 4.4.4 Objectives_____________________________________________________________ 42 4.4.5 Prototype _____________________________________________________________ 42 4.4.6 Product backlog ________________________________________________________ 42 5. REALISATIEFASE ______________________________________________________________ 43 5.1 REDESIGN, REFACTOR EN MERGE FASE _______________________________________________ 43 5.1.1 Gemaakte keuzes _______________________________________________________ 43 5.1.2 Opgeleverde producten __________________________________________________ 44 5.2 OBJECTIVES FASE _____________________________________________________________ 46 5.2.1 Gemaakte keuzes _______________________________________________________ 46 5.2.2 Opgeleverde producten __________________________________________________ 46 5.3 SOCIALE FASE _______________________________________________________________ 52 5.3.1 Gemaakte keuzes _______________________________________________________ 52 5.3.2 Opgeleverde producten __________________________________________________ 52 5.4 UNIT FASE _________________________________________________________________ 55 5.4.1 Gemaakte keuzes _______________________________________________________ 55 5.4.2 Opgeleverde producten __________________________________________________ 55 6. CONCLUSIE __________________________________________________________________ 61 6.1 RESULTAAT _________________________________________________________________ 61 6.2 REFLECTIE __________________________________________________________________ 61 6.2.1 Eigen ervaring _________________________________________________________ 61 6.2.2 Proces ________________________________________________________________ 62 7. AANBEVELINGEN _____________________________________________________________ 63 7.1 VOOR DE RELEASE ____________________________________________________________ 63 7.2 NA DE RELEASE ______________________________________________________________ 65 BRONNENLIJST _________________________________________________________________ 66 BEGRIPPENLIJST ________________________________________________________________ 67 A. VROEGE CONCEPTEN MERCHANT 2.0 _____________________________________________ 68 B. CONCEPTEN ONTWERPFASE ____________________________________________________ 71 C. UNITS ______________________________________________________________________ 74 D. PRIMAIRE OBJECTIVES _________________________________________________________ 75 E. SECUNDAIRE OBJECTIVES ______________________________________________________ 76 F. PRODUCT BACKLOG ___________________________________________________________ 77

8

9

Samenvatting Inleiding Dit is het afstudeerverslag van Tom van Duist over de afstudeeropdracht die hij bij Oberon Interactive heeft gedaan. Centraal in de opdracht staat het spel Merchant Kingdom dat door Oberon Interactive is ontwikkeld en in 2010 in de Apple App Store is uitgebracht. Het spel wordt online gespeeld waarbij de GPS locatie van de speler een belangrijke rol speelt. Spelers kunnen nederzettingen bouwen die gekoppeld zijn aan de locatie in de echte wereld. Zo kunnen spelers een imperium opbouwen, nederzettingen van andere spelers tegenkomen om hier bepaalde acties te verrichten en later ook de loyaliteit van nederzettingen van andere spelers afdwingen doormiddel van hun culturele status of bezetting met een leger. Het doel van het spel is een zo groot mogelijk imperium op te bouwen. Aanleiding Aanleiding van de opdracht is het feit dat Merchant Kingdom in 2010 is uitgebracht en er sindsdien geen grote updates voor zijn ontwikkeld. Na een periode van succes is het aantal actieve spelers terug gelopen. Merchant 2.0 moet daar weer verandering in brengen. Daarnaast hebben de spelers al langere tijd naar een update gevraagd. Opdracht De opdracht is het maken van de applicatie kant van het spel en moet aan de volgende eisen voldoen: geschikt voor het draaien onder het nieuwste iPhone besturingssysteem, verbeterde omgevingsmap en game elementen toevoegen aan de eerste stadia van de game. Daarnaast is er ook ruimte om met eigen ideeën voor concepten te komen . Aanpak Vervolgens ben ik begonnen met het wegwijs worden met het project en het maken van een planning. Alvorens met de Analysefase is begonnen. Tijdens deze fase is de spelerdata geanalyseerd van de huidige versie van het spel, aan de hand van deze analyse zijn bepaalde conclusies getrokken en aanbevelingen gedaan die zijn meegenomen in de rest van de ontwikkeling. Daarna volgde de ontwerpfase waarin de aanbevelingen en andere ideeën zijn uitgewerkt tot concrete spelconcepten. Ook is er een prototype gemaakt om nieuwe technieken en de haalbaarheid van bepaalde concepten te testen. Vervolgens volgde de realisatiefase waarin de producten werden gerealiseerd. Opgeleverde producten Het streven om een product op te leveren dat klaar is voor de release is helaas niet gelukt. Maar het is wel gelukt een aantal onderdelen op te leveren die Oberon een stuk dichterbij brengen bij Merchant 2.0. Belangrijkste hiervan zijn: - Analyserapport; feitelijk H3: Analysefase. - Omgevingsmap; interactieve map waarvan de acties op locaties gedaan worden. - Objectives systeem; primaire en secundaire objectives die de speler begeleiden. - Nieuwe units; nieuwe units als oplossing voor problemen uit de analyse. - Units upgraden; de mogelijkheid om units te upgraden. - Game Center Integratie; betere integratie met Apple's Game Center. Conclusie Hoewel er helaas geen product is opgeleverd dat klaar is voor de release, zijn de beoogde vereisten voor de opdracht wel gehaald. - Merchant 2.0 is geschikt voor en maakt gebruik van de nieuwste iOS techniek. - Er is een nieuwe interactieve omgevingsmap opgeleverd. - De beginstadia van het spel zijn aangevuld met objectives en nieuwe units. Er waren aanvankelijk wat problemen omdat door omstandigheden de veranderingen aan de server niet op tijd waren doorgevoerd. Dit is opgepakt door andere taken, die origineel nog niet op de planning stonden, eerder op te pakken. Hierdoor is de schade beperkt gebleven.

10

1. Inleiding In de inleiding wordt er het een en ander verteld over het bedrijf waar de opdracht uitgevoerd is en het huidige spel waar de opdracht op verder bouwt. En wordt er op de opdrachtomschrijving in gegaan.

1.1 Oberon Interactive Oberon is gevestigd in het centrum van Amsterdam, aan de Stadhouderskade, en bestaat inmiddels twintig jaar. Het is in 1993 opgericht door Martijn Lemmens, Douwe Osinga en Hans-Peter Harmsen, waarvan alleen de laatste nog werkzaam is bij het bedrijf. Oorspronkelijk richtten ze zich op (publieke) informatiezuilen. Later hebben ze zich gericht op screensavers waarvan de bekendste voor de NS maar andere klanten waren KLM, de Koninklijke Landmacht en later games voor o.a. Heineken, Dixons en Wolters Nordhoff. Ook hebben ze RSS toegepast waarvan de populairste de Volkskrant Nieuwsklikker, andere klanten waren Voetbal International, De Telegraaf, en verschillende ministeries en grote VVV'sI.

1.1.1 Huidige stand van zaken Op dit moment werken er rond de vijftien werknemers bij Oberon. Het management, operaties en strategie wordt uitgevoerd door Hans-Peter Harmsen, Gert Braun en Richard de Boer respectievelijk. Daarnaast bestaat het bedrijf uit een mix van iOS, Android, backend- en front end developers en designers. Oberon is nu vrijwel volledig gericht op mobiel. Ze helpen hun klanten te richten op mobiel door te adviseren in de mobiele strategie en deze te verwezenlijken, al dan niet doormiddel van een mobiele applicatie of een website. Er wordt voornamelijk gewerkt in opdracht, o.a. voor grote klanten als T-Mobile met de My-Tmobile app, PayPal, de Nationale Nederlanden, DELTA, Microsoft, War Child, TUI, Olvarit en Houthoff Buruma I.

1.1.2 Focus Oberon richt zich vooral op nieuwe ontwikkelingen binnen de online marketing. De laatste jaren is hierin een verschuiving ontstaan richting mobiel en Oberon is volledig ingericht om deze ontwikkeling te volgen en hun klanten daarin te accommoderen. De visie van Oberon is dat de mobiele app hierin een belangrijke schakel is en zodoende ontwikkelen ze applicaties en mobiele websites voor alle belangrijke platformen. Ze helpen hun klanten te focussen op mobiel en geloven dat een organisatie daarmee dichter bij hun klanten en gebruikers komt te staanII.

I Oberon Interactive, 20 jaar online, jubileum boek van Oberon Interactive, Amsterdam, 2013 II Oberon Interactive, wat we doen (2013) Bezocht op 23-12-2013, http://www.oberon.nl/nl/wat-we-doen/

11

1.2 Merchant - Het spel Het doel van het spel is een imperium op te bouwen doormiddel van het bouwen van nederzettingen. Deze nederzettingen produceren bepaalde goederen zoals hout of eten, wat nodig is om de nederzettingen uit te breiden tot kastelen en legers te trainen. Originele toevoeging is dat alles in het spel is gekoppeld aan de fysieke locatie in de wereld, wat gelijk een dynamiek toevoegt aan dit veel beproefde concept van bouwen en heersen I. Als de speler app opstart en naar de omgevingsmap gaat ziet hij een kaart, dat in de echte wereld ongeveer honderdvijftig bij honderdvijftig meter beschrijft, en is opgedeeld in negen vakjes van ongeveer vijftig bij vijftig meter. Op deze vakjes kunnen spelers een nederzettingen bouwen. Bepaalde handelingen, zoals het upgraden van een gebouw en het ophalen van de geproduceerde goederen, kunnen alleen worden gedaan als de speler zich ook op de locatie van de nederzetting bevindt. Als spelers zich door de echte wereld begeven kunnen ze nederzettingen en kastelen van andere spelers tegenkomen waar vervolgens bepaalde handelingen verricht kunnen worden zoals spioneren en stelen, maar ook een cadeau geven of een minstreel laten optreden voor geld II.

Figuur 1: Omgevingsmap Merchant 1.5.

I II

Figuur 2: Locatie view Merchant 1.5.

Oberon Interactive, 20 jaar online, jubileum boek van Oberon Interactive, Amsterdam, 2013 Merchant Kingdom, pedia. Bezocht op 10-09-2012 http://www.merchantkingdomgame.com/pedia/output/pedia.html

12 Daarnaast heeft elke regio zijn eigen markt. Hier kunnen goederen te koop worden aangeboden voor andere spelers. Elke markt is gekoppeld aan een regio, Castricum heeft zijn eigen markt met andere prijzen dan Amsterdam, wat het lucratief kan maken om tussen beide markten te reizen en goederen te verhandelen. Later in het spel kunnen spelers legers maken waarmee andere nederzettingen aangevallen kunnen worden, als de aanvaller wint kan hij deze bezetten. Dit verandert niks voor de speler waar de nederzetting van is behalve dat hij een deel van de belasting aan de bezetter moet betalen en zijn nederzetting nu trouw is aan de bezetter, wat betekent dat deze inwoners nu meetellen in zijn imperium. Het uiteindelijke doel is een zo groot mogelijk imperium opbouwen. Dit doe je door zoveel mogelijk inwoners onder jouw gezag te hebben, hetzij doordat ze in je eigen nederzettingen wonen of nederzettingen die via bezetting onder jouw gezag vallen. Op deze manier worden gebieden en regio's verdeeld over de gezaghebbende. Zo heb je een 'Count van Amsterdam', wie het machtigste is in Amsterdam. Alle Counts van een gebied vallen onder de 'Duke of North Holland' welke uiteindelijk valt onder de 'Prince of the Netherlands'. Prins worden van een land is de hoogste prestatie in het spel.

Figuur 3: Speler nederzettingen.

Figuur 4: Nobility tab.

13

1.3 De opdracht In 2009 kwamen de eerste ideeën bij Oberon voor een locatie gebaseerde MMORPG voor de iPhone. Eind 2010 kwam het spel in de App Store en was het een aardig succes. Waarna er een paar updates zijn uitgebracht, waaronder een versie onder de banner van uitgever ChillingoI maar er is sindsdien niet veel verbeterd of toegevoegd. Mede door het uitblijven van verbeteringen is het aantal actieve spelers, behalve een groep fanatieke fans, ver terug gelopen. Het doel van de opdracht is kort gezegd een nieuwe versie van het spel maken, Merchant 2.0. In essentie blijft het spel grotendeels hetzelfde maar er is veel ruimte voor nieuwe vormgeving, verbetering van het interactie design, het bedenken en toevoegen van nieuwe spel elementen en het uitzoeken en terug dringen van de speler uitval in de beginfase van de game. Maak Merchant geschikt voor het draaien onder iOS 7. Met andere woorden betekend het dat de huidige versie compatibel gemaakt moet worden met de nieuwste iOS en iPhone. Ook is het de bedoeling dat de vormgeving en het interactie design flink op de schop gaat. Het huidige design bestaat uit veel statische schermen met tabellen. De omgevingsmap bestaat bijvoorbeeld uit een enkel scherm verdeeld in negen plaatjes die de verschillende locaties en nederzettingen om de speler heen voorstellen. Het is de bedoeling dat dit wordt vervangen door een grotere map die kan bewegen en die opgebouwd is uit een achtergrond, bijvoorbeeld een woestijn, waar de verschillende type gebieden overheen worden gelegd, zoals zoutvlaktes of oases. Wanneer er op deze gebieden een nederzetting staat zal deze aan de rand van de oase of midden op de zoutvlakte worden gezet. Daarnaast moeten verschillende handelingen direct vanaf de map uitgevoerd kunnen worden. Het scherm wanneer je een nederzetting bezoekt, wat op dit moment een nieuw scherm opent met een aantal tabellen en knoppen, komt er ook meer uit te zien als een echt dorp door bijvoorbeeld een plattegrond met gebouwen er op. Daarnaast zijn er veel spelers die tijdens het begin van het spel afhaken (Boer, R. de. 2013a). Er is data beschikbaar die geanalyseerd kan worden om er hopelijk achter te komen op welke momenten de spelers het meeste afhaken en vervolgens maatregelen te bedenken om uitval op deze momenten zoveel mogelijk terug te dringen. Verder is er ook ruimte voor het bedenken van andere verbeteringen en het implementeren van nieuwe spel elementen.

I

Oberon Interactive, 20 jaar online, jubileum boek van Oberon Interactive, Amsterdam, 2013

14

F ig u u r 2

Figuur 5: Oud design idee voor de omgevingsmap.

Figuur 6: Oud design idee voor het locatieaanzicht.

15

2. Plan van aanpak In dit hoofdstuk wordt er verder ingegaan op de aanpak van het project. Zo worden eerst de probleemstelling en de deelvragen geformuleerd alvorens de aanpak wordt besproken. De aanpak is hierbij opgedeeld in de verschillende fases en aan de hand daarvan is er een planning en een inventarisatie van de eindproducten opgesteld.

2.1 Probleemstelling Een nieuwe versie van Merchant Kingdom die gebruik maakt van de laatste ontwikkelingen op iOS gebied, een nieuwe omgevingsmap heeft en andere speltechnische toevoegingen en verbeteringen met oog voor de beginfase met zich mee brengt gaat de nieuwe versie uitmaken, Merchant 2.0. Zoals door Richard de Boer, mijn bedrijfsbegeleider binnen Oberon Interactive, is omschreven in het formulier voor de aanvraag van de afstudeeropdracht: Belangrijkste wijzigingen in versie 2.0 zijn het klaarmaken voor iOS 7, het bouwen van een nieuwe location view en het verrijken van de early game met door hem zelf te bedenken concepten.

2.1.1 Deelvragen Merchant bestaat bijna twee jaar, en door de gewijzigde techniek van iOS zijn er problemen ontstaan. Het spel had ooit rond de tienduizend actieve gebruikersI maar dit is terug gevallen naar enkele honderden. Daarnaast wensen de spelers al een tijdje vernieuwing (Boer, R. de. 2013a) in de vorm van nieuwe toevoegingen en uiterlijk of een compleet nieuwe versieII. Daaruit is de probleemstelling voortgekomen, maar om beter te kunnen begrijpen waar het probleem ligt en welke specifieke onderdelen het belangrijkst zijn om aan te pakken zullen de volgende deelvragen eerst behandeld worden. Hoe presteert de huidige versie? - Waar haken nieuwe spelers op af? - Op welke punten vallen de meeste spelers af? - Is de tutorial toereikend genoeg? Hoe kan het spel (visueel) aantrekkelijker worden gemaakt voor de doorsnee speler? - Hoe kan het interaction design dit faciliteren? - Hoe kan het augmented gevoel beter overgebracht worden? - Kan de eerste indruk zo verbeterd worden dat meer spelers blijven hangen?

2.2 Analyse huidige versie Om te beginnen zal de spelerdata van de huidige versie van Merchant geanalyseerd worden. Hiervoor wordt data uit de database beschikbaar gesteld die ik zal analyseren in de hoop bepaalde patronen te ontdekken. Zo is er al door Oberon aangegeven (Boer, R. de. 2013a) dat een groot deel van de spelers inde begin fase alweer afhaken. Door de analyse van de spelerdata uit de database hoop ik bepaalde punten in het spel te vinden waar spelers tegen aan lopen om hier vervolgens een oplossing voor te bedenken. Aan de hand van de resultaten van deze analyse zal ik aanpassingen en nieuwe spelconcepten aan Oberon voorleggen en wordt bepaald welke de hoogste prioriteit hebben en wat er in de planning past. I II

Oberon Interactive, 20 jaar online, jubileum boek van Oberon Interactive, Amsterdam, 2013 Berichten van spelers (2013) Bezocht op 10-09-2013 https://www.facebook.com/merchantkingdom

16

2.3 Fasering Het project al ongeveer een half jaar in beslag nemen en bouwt verder op een bestaand product, daarom is gekozen om gebruik te maken van verschillende project methodologieën. Allereerst is gebruik gemaakt van de waterval methode waarbij het project in verschillende fasen is ingedeeld. De eerste fase zal zijn de Oriëntatie en analyse fase, gevolgd door een Ontwerpfase. Gevolgd door de realisatiefase die in zichzelf is opgedeeld aan de hand van een iteratieve project methode. Bij de iteratieve methode wordt er tijdens elke sprint hetzelfde traject gevolgd van definiëren, bouwen, testen en opleveren. Dit iteratieve proces wordt herhaald tot vlak voor het einde van het project verloop, en wordt daarna gevolgd door een opleverfase waar naast de oplevering ook ruimte is voor verbetering van het product en verslag.

2.3.1 Oriëntatie en analyse In de eerste fase zal ik mezelf eerst oriënteren en beter bekend maken met het huidige spel en de structuur van de code. Merchant 2.0 krijgt de vrijheid om waar nodig volledig gebruik te maken van de nieuwe technieken in iOS7, de nieuwste iOS versie. Hier zal ik mij beter bekend mee maken en inlezen. Vervolgens zal ik de spelerdata van de huidige versie analyseren en met bepaalde aanbevelingen komen voor de nieuwe versie.

2.3.2 Ontwerpfase Tijdens deze fase zal ik mijn bevindingen van de analyse tijdens de analyse fase verwerken in concepten en ideeën voor verbeteringen. Daarnaast is er ook ruimte voor het uitwerken van eigen ideeën en concepten waarvan ik denk dat die wat zullen toevoegen aan het spel. Tijdens deze fase zal dus veel gewerkt worden aan de uitwerking en verbetering van spelconcepten en zal er eventueel een nieuw interactie design gemaakt worden. Verder zal ik waar nodig bezig zijn met het programmeren van prototypes om bepaalde ontwerpen en technieken eerst uit te testen alvorens ze verder uit te werken en in het spel te implementeren tijdens de realisatie fase. Er zal een product backlog worden gemaakt met alle onderdelen die we in het meest optimale geval in de nieuwe versie verwerkt willen hebben. Dit wordt tijdens de realisatie fase gebruikt om de iteraties in te delen.

2.3.3 Realisatiefase De realisatiefase zal volgens de iterative project methode ingedeeld worden in verschillende iteraties. De lengte van deze iteraties zal tijdens de ontwerpfase worden bepaald maar deze zal waarschijnlijk rond de twee tot drie weken komen te liggen. Aan het begin van elke sprint wordt gedefinieerd wat er in die sprint wordt gerealiseerd, aan het einde worden de nieuwe onderdelen getest en wel opgeleverd of weer naar de product backlog verplaatst waarna ze bij het definiëren van de volgende sprint weer ingedeeld kunnen worden. Deze fase zal dus uit een iteratief proces bestaan van definiëren, bouwen, testen en opleveren. De gebruikte methode tijdens deze fase is losjes gebaseerd op mijn SCRUM ervaringen, ik zal deze techniek niet volledig toepassen omdat ik veel individueel zal werken en bepaalde onderdelen van SCRUM dan overbodig zullen zijn zoals de daily standup meetings en het uitwerken van onderdelen in volledige userstories. Aangezien de product owner op momenten ook onderdeel is van het ontwikkelteam (en waarschijnlijk ook de aangewezen persoon voor de rol als scrum master zou zijn).

17

2.3.4 Opleverfase Tijdens deze laatste fase wordt het spel definitief opgeleverd, verder wordt er een advies geschreven dat Oberon adviseert over verdere verbeteringen van Merchant. Daarnaast zal ik in deze fase mijn afstudeerverslag afronden en de resultaten presenteren.

2.4 Planning Aan de hand van de bovenstaande fasering kan de volgende planning worden gemaakt.

Figuur 7: Project planning.

Waarbij de realisatie fase weer op de volgende manier is ingedeeld.

Figuur 8: Fasering van de realisatiefase.

18

2.5 Inventarisatie producten Merchant 1.3 analyse document Dit document zal bestaan uit een analyse van de spelerdata van de huidige Merchant versie. De hele database is beschikbaar voor analyse. Uit deze analyse zullen bepaalde conclusies worden getrokken en hier zullen aanbevelingen op worden gebaseerd voor Merchant 2.0. Prototype Tijdens de ontwerpfase zal er een prototype worden gebouwd op basis van iOS 7 waar nieuwe toepassingen die alleen in iOS 7 beschikbaar zijn zullen worden getest. Verder zullen hier concepten met betrekking tot de gebruikersinteractie worden getest. Spel concepten Tijdens de ontwerpfase zullen er ook spelconcepten worden uitgewerkt aan de hand van de conclusies van het analyse rapport, maar er is ook ruimte om eigen concepten en ideeën uit te werken en voor te leggen. Interaction design Er is al aangegeven dat Merchant 2.0 een nieuw uiterlijk moet krijgen en nieuw aan moet voelen, hiervoor zijn al schetsen voor een nieuwe omgevingsmap maar deze zijn nog niet compleet uitgewerkt. Er zal een interactie design gemaakt moeten worden waarin wordt bepaald hoe deze omgevingsmap aansluit op de rest van de applicatie. Product backlog Aan het einde van de ontwerpfase zal er een product backlog worden opgeleverd met alle onderdelen die we in Merchant 2.0 willen verwerken. Merchant 2.0 Dit is het product waar het allemaal om draait, een nieuwe versie van Merchant volledig ondersteund door iOS 7, met een nieuw uiterlijk, verbeteringen om speler terugval in het begin van het spel te beperken, andere verbeteringen om het spel beter te balanceren en nieuwe functies zoals nieuwe units.

2.5.1 Conclusie Aan het einde van het proces zal er in de conclusie duidelijk worden gemaakt wat mijn werkzaamheden teweeg hebben gebracht en in hoeverre aan de opdracht is voldaan. Eventueel zal er ook een conclusie worden getrokken over wat er nog meer gedaan had kunnen worden als er meer tijd beschikbaar was.

2.5.2 Advies Tot slot zal ik een advies opstellen aan Oberon waarin ik mijn advies geef ten opzichte van verdere ontwikkeling of toekomstige updates van het spel.

19

3. Analysefase Dit hoofdstuk is vrijwel een identieke vertaling, van het Engels naar het Nederlands, van het aan Oberon opgeleverde document Merchant 1.3 analyse. In dit document wordt in elke subparagraaf een grafiek behandeld. Deze grafieken zijn opgesteld met data dat uit de database van Merchant 1.3 is gehaald en geanalyseerd om bepaalde verbanden te vinden. Aan de hand van elke grafiek wordt geprobeerd een conclusie te trekken. Alle data uit dit hoofdstuk komt van de Europese server. Er zijn servers opgezet voor verschillende werelddelen maar voor de analyse lag de focus op de Europese servers, waar nog het actiefst wordt gespeeld.

3.1 Speler statistieken Ten eerste zijn hier een aantal algemene statistieken met betrekking tot het spel en de spelers. Geregistreerde spelers: Actieve spelersI: Spelers met nederzettingen: Totaal aantal nederzettingen: Gemiddeld aantal nederzettingen per speler: Totaal bezochte locaties: Totaal verdiend XP: Aantal corrupte/inactieve spelersII:

I

25136 1275 4734 44917 9.48 7873332 86865549 2547

Spelers die actief worden beschouwen aan de hand van het feit dat ze niet corrupt zijn, geld hebben en nederzettingen hebben. II Een nederzetting wordt corrupt als de eigenaar deze een tijdje niet bezoekt, een speler wordt corrupt als al zijn nederzettingen corrupt zijn.

20

3.1.1 Avatar geslacht In het kort: Als de standaard waarden voor het kiezen van een geslacht er niet is zal men misschien echt zelf een keuze maken.

Figuur 9: Distributie van de geslachtskeuze. Hoewel deze keus puur esthetisch is, is het grote verschil toch opvallend.

Mogelijke oorzaak Verschillende onderzoeken hebben laten zien dat het bij spelers van MMORPGs een veel voorkomende praktijk is om een virtuele avatar te kiezen van het tegenovergestelde geslacht van de speler zelf. Volgens (Yee, Ducheneaut, Yao en Nelson, 2011) kiezen 53.3% van de mannelijke en 18.5% van de vrouwelijke spelers van het spel World of Warcraft een avatar van het tegenovergestelde geslacht. Soortgelijke resultaten werden gevonden door (Lou, Park, Cha, Lei en Chen, 2013) onder de spelers van een Taiwanese MMORPG waar één op de drie spelers een avatar van het tegenovergestelde geslacht heeft. Zelfs al zou 99% van de spelers van Merchant Kingdom uit mannelijke spelers bestaan, dan suggereren de resultaten van voorgenoemde onderzoeken dat een groter deel van de spelers met een vrouwelijke avatar zou spelen. Gezien het grote aantal spelers, vijfentwintigduizend, die deze keuze hebben gemaakt binnen Merchant Kingdom is hier dus iets anders aan de hand. De standaard waarde van deze keuze staat normaal gesproken op de mannelijk avatar en de speler moet bij het aanmaken van een account een knop omzetten om een vrouwelijke avatar te kiezen. Het is goed mogelijk dat een groot deel van de spelers dit over het hoofd zien, of dat er na het invullen van de naam meteen op volgende wordt geklikt. Oplossing Door hier geen standaard waarde in te vullen worden spelers gedwongen om deze keuze expliciet aan te geven. Op deze manier moet de speler de keuze bewust maken en worden er waarschijnlijk meer vrouwelijke avatars gekozen.

21

3.1.2 Tutorial In het kort: Veel spelers komen niet voorbij de eerste stap van de tutorial, laat staan het einde van de tutorial. De aanleiding hiervoor is waarschijnlijk dat de tutorial een afgebakende staat is in plaats van een geïntegreerd onderdeel van het spel. De tutorial zou meer visuele hints kunnen gebruiken in plaats van alleen tekst.

Figuur 10: Progressie van de tutorial. Zoals valt af te lezen maakt minder dan de helft van de spelers de tutorial af.

Probleem Zoals in de bovenstaande grafiek valt te zien heeft 59% van de geregistreerde gebruikers de tutorial niet afgemaakt, waarvan 47% niet verder is gekomen dan de eerste stap van de tutorial. Waar de tutorial bestaat uit een totaal van vijf stappen die volbracht kunnen worden in een paar minuten door een gevorderde speler, en die een beginnende speler niet meer dan tien tot vijftien minuten zou moeten duren. Bijna 60% van de spelers heeft het spel dus niet langer dan een paar minuten gespeeld, veel te weinig om de gameplay te kunnen ervaren. Mogelijke oorzaak De tutorial bestaat uit een van afgebakende staat van het spel. Daarbij worden grote stukken tekst gebruikt om de stappen uit te leggen, waarna de speler moet onthouden wat hij precies moet doen. Dit soort tutorials kunnen een groot aantal spelers afschrikken (Jarvinen, 2010), veel spelers hebben niet het geduld of hebben hoe dan ook geen zin om een (dergelijke) tutorial te doen. Oplossing De tutorial moet meer naadloos geïntegreerd zijn in het spel en moet de speler beter begeleiden. De tutorial moet het liefst niet een apart onderdeel van het spel zijn maar meer geïntegreerd zijn in het spel, bijvoorbeeld in de vorm van een reeks tips en opdrachten die de speler door het spel loodsen. Ook kunnen er visuele hints gebruikt worden om de speler te helpen bij het vinden van de juiste knoppen zodat hij niet verdwaald raakt in de verschillende schermen op zoek naar bijvoorbeeld de treasure knop.

22

3.1.3 Guild keuze In het kort: Het ziet er naar uit dat een groot deel van de spelers een van eerste keuzes kiest. Dit kan zijn omdat spelers geen zin hebben om te lezen wat de verschillende guilds inhouden of omdat ze de eerste knop op het scherm indrukken (in dit geval de keuze knop die de keuze bevestigt). Een oplossing kan zijn het verminderen van de tekstuele uitleg per guild of een opsomming van de voor en nadelen bovenin toevoegen. En in plaats van een keuze knop een selecteer en bevestig knop om de kans op het per ongeluk kiezen van een guild te verkleinen.

Figuur 11: Guild keuze distributie. De keuzes die als eerst worden gepresenteerd worden relatief vaker gekozen.

Probleem De bovenstaande grafiek geeft de verdeling van de guild keuzes weer. Waar de Explorers, Manufacturers, Traders en Thieves guilds elkaar opvolgen als eerste, tweede, derde en vierde keus respectievelijk die de speler krijgt voorgeschoteld na het voltooien van de tutorial. Zoals valt af te lezen kiest een relatief groot gedeelte van de spelers voor de eerste keus die ze krijgen, de Explorers guild. Vooral onder de spelers die niet verder zijn gekomen dan level nul is dit goed zichtbaar, hier is bijna 50% voor de eerste keuze gegaan. Als je kijkt naar de spelers vanaf level één en hoger is de verdeling al meer gelijk en is de Manufacturers guild het meest populair Mogelijke oorzaak De spelers die niet verder zijn gekomen dan level nul waren waarschijnlijk überhaupt geen serieuze spelers of hebben de verkeerde eerste indruk gekregen. Toen ze wel de tutorial afmaakten en de guild keus voorgeschoteld kregen heeft een groot gedeelte van deze spelers de eerste guild gekozen toen ze de kans kregen. Daarnaast is het verschil tussen de verschillende guilds niet meteen overduidelijk. Uit de naam van de guild kunnen spelers wel het een en ander opmaken maar spelers moeten de complete tekst lezen om de details te begrijpen. Veel spelers hebben waarschijnlijk geen zin om vier stukken tekst te lezen.

23

Oplossing Wat er verbeterd kan worden is om naast tekst met uitleg over de guild, in het begin een klein overzicht weer te geven met een korte samenvatting van de voor- en nadelen:

Daarnaast zou het goed zijn om de keuze knop op elk guild schermpje waarmee de speler gelijk de keuze maakt te vervangen door een selectie knop waarna de gebruiker langs de andere guild keuzes moet scrollen om aan het einde de bevestig knop tegen te komen. Zo wordt voorkomen dat spelers per ongeluk een keuze maken.

24

3.1.4 Alle spelers op level In het kort: De meeste spelers die wel de tutorial afmaken halen vervolgens level één niet. Waarschijnlijk omdat ze in het diepen worden gegooid. Een mogelijke oplossing zou zijn om de tutorial langer door te laten lopen en kleine opdrachten toe te voegen die de speler voor een langere periode blijven begeleiden.

Figuur 12: Het aantal spelers dat op dat moment op elk level zijn. Na de tutorial is er een enorme afname in het aantal spelers.

Probleem De bovenstaande grafiek geeft weer hoeveel spelers er op elk leven zijn, spelers die de tutorial niet af hebben gemaakt zijn hier niet in meegenomen. Nadat spelers de tutorial hebt afgemaakt beginnen ze op level nul. Na een paar acties hebben spelers al genoeg XP vergaard om level één te bereiken. Zoals valt af te lezen zijn 4768 (46%) spelers van de in totaal 10239 spelers die de tutorial hebben afgemaakt niet verder gekomen dan level nul. Deze zijn dus binnen een paar minuten gestopt na het afmaken van de tutorial. Tussen level één en twee zijn er ook nog relatief veel spelers afgehaakt maar daarna is de verdeling gelijkmatiger met een kleine toenamen tussen de levels negen tot vijftien, waar ongeveer de laatste fase van het spel zich bevindt en wat lang duurt om doorheen te komen. Mogelijke oorzaak De tutorial, welke verplicht is en een flink opstakel is voor een groot aantal spelers, legt wel elk van de vijf stappen duidelijk uit. Waarna de speler een beloning krijgt en een tip hoe ze het spel het beste kunnen aanpakken. Maar daarna worden spelers in het diepen gegooid wat het kleine percentage spelers dat voorbij level nul komt kan verklaren. Veel spelers weten waarschijnlijk toch nog niet goed genoeg wat ze moeten doen en/of ze hebben geen zin om zelf uit te zoeken wat ze moeten doen. Oplossing De tutorial zou beter in het spel geïntegreerd, en daarmee minder opdringerig, kunnen zijn. Op deze manier zal het waarschijnlijk minder spelers afschrikken en kan de tutorial over een groter deel van het spel uitgerekt worden. In plaats van vijf stappen zou de tutorial bijvoorbeeld vijfentwintig kleine opdrachten kunnen bevatten die de speler op weg helpen en blijven begeleiden. Daarnaast is het ook een plek waar spelers, door middel van de opdrachten, hints vinden over hoe ze verder zouden kunnen spelen. Maar het hoeft niet verplicht te zijn, het is geen afgebakende tutorial status waar het spel zich in bevind.

25

3.1.5 Actieve spelers op level In het kort: De verdeling over de levels onder de actieve spelers is hoe het idealiter voor alle spelers zou zijn: de meeste vorderen door het eerste deel van het spel.

Figuur 13: Het aantal actieve spelers dat op dat moment op elk level zijn. De meeste spelers bevinden zich in de laatste fase van het spel.

The bovenstaande grafiek laat, net als de grafiek hiervoor in 3.1.4, het aantal spelers zien die op een bepaald level zijn, maar deze grafiek laat alleen actieve spelers zien in plaats van alle spelers. Zoals valt af te lezen loopt vanaf level acht het aantal spelers drastisch op. Dus voor alle, op dit moment actieve, spelers die de tutorial hebben afgemaakt vorderen de meeste door het eerste gedeelte van het spel. Idealiter wil je deze grafiek voor alle spelers van het spel.

26

3.1.6 Spelers in het eindspel In het kort: Voor alle actieve spelers zijn de meeste tot ver in het eindspel gevorderd, er zijn niet veel lage level spelers (meer).

Figuur 14: Actieve spelers die alle vier de gildehuizen hebben gebouwd.

De bovenstaande grafiek geeft het aantal actieve spelers weer en waarvan wie er alle vier de gildehuizen hebben gebouwd. Spelers die alle vier de gildehuizen hebben kunnen maken zijn erg ver in het eindspel gevorderd, wat betekend dat het grootste gedeelte van de spelers die nu nog spelen dit al voor geruime tijd doen. Hier kunnen we dus uit opmaken dat er op dit moment weinig lage level spelers zijn of nog bij komen.

27

3.1.7 Bezochte locaties In het kort: Zoals eerder al opgemerkt, stoppen veel spelers met spelen voor en vlak na het afmaken van de tutorial. Dit wordt opnieuw duidelijk door te kijken naar het aantal locaties dat bezocht is door spelers. Nadat ze wat gereisd hebben blijven veel ook voor langere tijd spelen.

Figuur 15: Aantal spelers dat meer dan een bepaald aantal locaties hebben bezocht.

De bovenstaande grafiek laat zien hoeveel spelers op meer dan een bepaald aantal locaties is geweest. Dus 24201 spelers hebben één of meer locaties bezocht. Hier kan worden opgemaakt dat van alle spelers die één locatie hebben bezocht er ongeveer zeshonderd niet een volgende locatie hebben bezocht. Maar 7668 spelers, of ongeveer 32%, hebben meer dan negen locaties bezocht wat betekend dat ze naar minstens één andere plek zijn gereisd na het voor het eerst opstartten van het spel en daar nieuwe locaties hebben bezocht. Daarna stopt weer 36% van de spelers voordat ze meer dan zesentwintig locaties hebben bezocht, wat betekend dat ze naar minstens drie verschillende plekken zijn gegaan om locaties te ontdekken. Wanneer spelers dit punt bereiken wordt de afname geleidelijker. Mogelijke oorzaak Net zoals bij eerdere grafieken te zien was stopt een groot deel van de spelers voordat ze de tutorial hebben afgemaakt en dat is hier weer duidelijk. Maar 32% van de spelers bezoekt locaties buiten de start positie.

28

3.2 Verkoop statistieken Allereerst een aantal algemene statistieken, de prijs is gebaseerd op de huidige Apple in-app tier prijzen.

Totaal aantal transacties: Aantal unieke kopers: Gemiddelde transacties per koper: Gemiddelde transactie prijs: Gemiddelde uitgaven per koper:

21747 2462 8.83 € 2.29 € 20.26

3.2.1 Aantal afnemers In het kort: Omdat de transacties niet aan individuele spelers gekoppeld kunnen worden zal de data vergeleken worden met een demografische spelers groep van ongeveer 4800-4400 spelers die gebaseerd op een aantal aannames verkregen is. Deze demografische groep is het waarschijnlijkst om in-app aankopen te doen en hieruit kunnen we concluderen (gezien de verkoop statistieken) dat van alle spelers in deze demografische groep ongeveer 50% in-app aankopen zal doen.

Figuur 16: Aantal spelers die een bepaald level hebben gehaald. Alle spelers die de tutorial hebben gedaan hebben automatisch level nul gehaald.

De transactie data kan (helaas voor deze analyse) niet aan individuele spelers gekoppeld worden. Dus zal er een demografische spelers groep gemaakt worden die het meest waarschijnlijk zijn om in-app aankopen te doen aan de hand van een aantal aannames gemaakt met het oog op verschillende statistische informatie. Kijkend naar bovenstaande grafiek, en terugblikkend op 1.7 Bezochte locaties, kunnen we een redelijk veilige schatting maken van het aantal spelers dat potentieel in-app aankopen zal doen.

29 We kunnen bijvoorbeeld voor de ongeveer vijfduizend spelers die zijn gestopt met spelen tussen level nul en één, en dus vlak na de tutorial gestopt zijn, veilig aannemen dat deze spelers geen in-app aankopen gedaan zullen hebben aangezien deze spelers over het algemeen maximaal vijftien minuten hebben gespeeld. Hetzelfde geldt voor vrijwel alle spelers tussen level één en twee en degene die minder dan vijfentwintig locaties hebben bezocht. Zij hebben het spel tussen de vijftien minuten en maximaal drie kwartier gespeeld, hebben maar een aantal locaties bezocht en zijn in dit deel van het spel nog geen obstakels tegen gekomen zoals het opraken van geld en andere middelen. Ze hebben dus nog niet hoeven wachten met het bouwen van gebouwen en hebben zo weinig gereisd dat ze hoogstwaarschijnlijk de toegevoegde waarde van het kopen van units nog niet hebben ondervonden. Mochten ze dit wel gedaan hebben, en als gevolg in-app aankopen hebben gedaan kunnen we weer vrij veilig stellen dat het grootste gedeelte van de spelers na het uitgeven van geld wel langer waren blijven spelen. Kans Het punt waar we kunnen zeggen dat de spelers echt begonnen zijn met het spelen van het spel na het voltooien van de tutorial begint ongeveer rond level twee en wanneer ze een hebben rond gereisd en verschillende locaties hebben bezocht. Vanaf dit punt wordt het waarschijnlijk dat spelers in-app aankopen gaan doen (hoewel de mediaan waarschijnlijk op een veel later punt in het spel zal liggen). Uitgaande van deze demografische groep, die ongeveer 4800-4400 spelers bevat. Vervolgens kijkend naar de transactie statistieken kunnen we een totaal van 2462 unieke spelers zien die in-app aankopen hebben gedaan. Dat is minstens 50% van de vrij ruim veronderstelde demografische groep, wat totaal niet slecht is. Dus het grootste punt van belang zou zijn het verhogen van het aantal spelers dat door het eerste deel van het spel vordert en het vergroten van het aantal spelers dat de demografische groep opmaakt en mogelijk in-app aankopen doen.

30

3.2.2 Verkoop populariteit In het kort: Kijkend naar de populariteit van de verschillende verkopen kunnen we een aantal kansen zien: 1) Nog een Kings Favors pakket aanbieden met meer Favors. 2) De in-app aankoop van de Settler en Carrier units ook voor latere spelers interessant houden door de goud prijs te laten oplopen per gekochte unit. 3) Dit werkt ook voor andere units zoals de opslag units en dit zal tegelijkertijd dienst doen als een gold sink.

Figuur 17: De populairste in-app aankopen gebaseerd op het aantal verkopen.

Aan de bovenstaande grafiek kunnen we zien welke in-app aankopen het populairst zijn. Hier kunnen een paar opmerkingen over gemaakt worden: -

-

Settler: Spelers hebben vooral in het begin veel voordeel bij deze unit maar is dan relatief duur en je kan er veel gebruiken, dus het is niet verassend dat deze het populairst is. 100 Kings Favors: Dit is de duurste in-app aankoop, maar geeft de speler 100 Kings Favors voor een schappelijke prijs (vergeleken met de 10 en 50 Favors pakketten) en kan de het leven van de speler erg vergemakkelijken door de mogelijkheid van het afkopen van wachttijden. Carrier: Nog een unit waar je als beginnende speler veel aan hebt en tijdens het hele spel handig is, maar de goud prijs is voor beginnende spelers vrij hoog. MyKingdomPro: Niet meer beschikbaar. Wagontrain: De beste unit voor het uitbreiden van je opslag. BatteringRam: Alleen interessant voor spelers in het allerlaatste stadium van het spel, maar de in-app aankoopprijs van 89 eurocent is erg goedkoop vergeleken met de goud prijs van 15.000 goud.

De rest van de units zijn het interessants in het begin van het spel, naar maten de speler verder komt (en een aantal weken aan het spelen zijn) is de goud prijs geen obstakel meer.

31 Kans Er liggen een aantal kansen hier. Een is bij de Kings Favors, die erg populair zijn, vooral het duurste pakket. Blijkbaar zijn een hoop spelers bereid om geld uit te geven aan Kings Favors en geven ze de voorkeur aan het pakket met de beste prijs kwaliteit verhouding. Een nog groter pakket van misschien wel 250 of zelfs 500 Kings Favors zou deze spelers dienen. Daarnaast zouden de plaatsen in het spel waar spelers Kings Favors kunnen gebruiken om een klein voordeel te krijgen kunnen worden vergroot zodat er meer Favors worden uitgegeven. De tweede kans ligt bij de units, de meest populaire units (de Settler en de Carrier) zijn degene die de spelers vrijwel het hele spel kunnen gebruiken. Vanaf het begin van het spel tot wanneer ze de grens van het maximaal aantal nederzettingen hebben bereikt. Maar het is eigenlijk alleen voordelig om de units via een in-app aankoop te bemachtigen tijdens het begin en misschien het midden van het spel (tot maximaal zes weken speeltijd ongeveer). Dit omdat de goud prijs voor deze units voor spelers in het begin van het spel vrij hoog is, maar relatief gezien erg laag is wanneer ze verder in het spel gevorderd zijn. Als deze units voor alle spelers moeilijk(er) zouden zijn om te verkrijgen zou dit ook spelers op een hoger level aanmoedigen om ze via een in-app aankoop te verkrijgen. Bijvoorbeeld door de goud prijs van de unit op te laten lopen per gekochte unit. Dit zou daarnaast een tweede doel dienen, namelijk die van een gold sink naarmate spelers steeds meer goud hebben. Een andere kans ligt er nog bij de opslag units, de Wagon Train en Covered Wagon. Net als de Settler en Carrier units zijn ze relatief gezien erg duur in het begin van het spel maar worden ze voor de spelers steeds makkelijker om te kopen naarmate ze verder in het spel vorderen. Deze zouden ook duurder kunnen worden per verkregen unit en ook hier zal dit twee doelen dienen. Namelijk dat als gold sink en zal het spelers aanmoedigen om ze via een in-app aankoop te bemachtigen.

32

3.3 Conclusie De geanalyseerde data laat zien dat de meeste spelers die aan het spel beginnen de tutorial niet afmaken of zelfs niet verder komen dan de eerste stap van de tutorial (3.1.2), en opnieuw na het voltooien van de tutorial stopt een groot aantal spelers (3.1.4, 3.1.7). Daarnaast hebben spelers die wel de tutorial afmaken en de kans krijgen om een guild te kiezen de neiging om met de eerste optie te gaan (3.1.3). Dit leidt tot de conclusie dat de tutorial een groot obstakel is voor veel spelers en dat ze niet graag stukken tekst lezen voordat ze kunnen beginnen met spelen, zij het voor de tutorial of de guild keuze. Dus de tutorial dient vereenvoudigd en beter geïntegreerd te worden in het spel en minder grote hoeveelheden tekst bevatten per stap. Daarnaast zou er ook gebruik gemaakt kunnen worden van visuele hints om de speler in de juiste richting te wijzen, bijvoorbeeld door de knop op te lichten waar de speler op moet klikken in plaats van het uitleggen via tekst. Daarnaast zou de tutorial langer moeten zijn en minder abrupt stoppen zodat spelers niet in het diepe worden gegooid. Wanneer spelers wel een hoger level bereiken (drie of hoger) en een aantal locaties hebben bezocht, blijft de meerderheid van de spelers voor een tijdje spelen (3.1.4, 3.1.5, 3.1.7). Dit leidt tot de conclusie dat veel spelers genieten van het latere deel van het spel en alleen de eerste paar opdrachten, de eerste paar minuten tot aan ongeveer vijftien tot dertig minuten gameplay, een groot obstakel zijn voor veel spelers. De geanalyseerde verkoop data samen met de aannames gemaakt in 3.2.1 laten zien dat spelers waarvan gezegd kan worden dat ze echt zijn gaan spelen (ongeveer twee levels na de tutorial zijn gevorderd) circa de helft in-app aankopen doet. Dus dit benadrukt weer hoe belangrijk het is dat het eerste gedeelte van het spel toegankelijker is voor een groter gedeelte van de spelers. Daarnaast laat 3.2.2 'verkoop populariteit' zien dat er een aantel goede kansen liggen om de omzet uit in-app aankopen van het spel te vergroten door ze voor een groter aantal spelers een voordeel op te laten leveren. Concluderend kunnen we stellen dat het eerste deel van het spel, vooral de tutorial en de eerste twee daaropvolgende levels, toegankelijker moeten zijn om er voor te zorgen dat er een grotere spelerbasis ontstaat uit hetzelfde aantal geregistreerde gebruikers. Dit heeft op zijn beurt en samen met een aantal aanpassingen met betrekking tot de in-app aankopen de potentie om de totale omzet van het spel doen vergroten.

33

4. Ontwerpfase In dit hoofdstuk wordt de ontwerpfase toegelicht. Dit is de overgangsfase van de analysefase naar de realisatiefase. Tijdens deze fase werden bepaalde concepten, al dan niet ontstaan uit de resultaten van de analysefase, verder uitgewerkt. Vervolgens werd er een prototypen gemaakt om nieuwe technologie van iOS 7 en de haalbaarheid van bepaalde concepten te testen.

4.1 Uitwerken concepten De ontwerpfase borduurt verder op de resultaten van het analyse onderzoek en vroege concepten die tussendoor zijn bedacht, deze zijn terug te zien in bijlage A. Allereerst is er nagedacht over manieren om bepaalde problemen met Merchant 1.5 op te lossen die door het analyse onderzoek aan het licht zijn gekomen of hierdoor zijn bevestigd. De twee grootste problemen zijn: -

De tutorial en de paar minuten daarna zijn een groot obstakel voor de meeste spelers. Een groot gedeelte van de spelers stopt al met spelen voordat ze de gameplay hebben ervaren, veel spelers haken dus door de eerste indruk af.

Om te proberen deze problemen zoveel mogelijk terug te dringen zijn de volgende oplossingen bedacht: -

De tutorial wordt vervangen door vrijblijvende Objectives. Het design gaat compleet overhoop, dit wordt het visite kaartje van de Merchant 2.0 update, de map wordt het centrale punt van het spel en gaat visueel veel meer tot de verbeelding spreken.

Verder zijn belangrijke concepten: De Artisan, Right Hand, Visuele karavaan, Visuele schatten, Betere chat functie en Contact informatie. Alle concepten zijn terug te vinden in bijlage B.

4.1.1 Objectives De objectives vervangen de tutorial. In plaats van een verplichte tutorial die spelers vast zet in een beperkte status van de game gaan er twee categorieën van objectives komen. De primaire objectives zijn de rode lijn door het spel en worden in een vaste volgorde vrijgespeeld. Het is niet verplicht om deze objectives te doen maar begeleiden de speler wel in het spel en geeft beloningen in de vorm van XP en goud. De secundaire objectives volgen geen vaste lijn en hiervan is er elke dag eentje voor de speler beschikbaar om te voltooien. De objective wordt elke dag uit een aantal mogelijke objectives voor de speler gekozen gebaseerd op zijn level. Het doel van deze objectives is om de speler vrij te laten in wat hij doet. De beginnende speler moet niet overweldigd worden met een opdringerige tutorial die de speler beperkt in zijn vrijheid en verplicht om lappen tekst te lezen om er doorheen te komen alvorens aan het echte spel te kunnen beginnen. De objectives zullen de speler in een meer geïntegreerde manier aan de hand nemen, en doormiddel van kleine, makkelijke opdrachten de speler bekend maken met de mogelijkheden van het spel.

34

4.1.2 Design Het huidige design van Merchant 1.5 is geen probleem voor een klein deel van de spelers die aan het spel beginnen, gezien de groep trouwe fans die het spel nog steeds dagelijks spelen. Maar zoals in het analyse onderzoek is te zien stopt 28% van de spelers al voordat ze de eerste stap van de tutorial hebben gedaan. En 31% maakt de tutorial niet af, die in het uiterste geval ongeveer maximaal vijftien minuten in beslag kan nemen. Maar 41% van de spelers komt dus door de eerste paar minuten gameplay. Dit percentage hopen we fors te verhogen door de tutorial te vervangen door hiervoor genoemde objectives, en daarnaast de eerste indruk te verbeteren door een nieuw design. Centraal in dit design is de map, die visueel een stuk aantrekkelijker zal worden. In plaats van negen bruin/grijze lijntekeningen die de verschillende landschappen en dorpjes voorstellen komt de map te bestaan uit een interactief landschap die de speler kan verplaatsen en vergroten. Op deze map worden de landtypen en dorpjes geplaatst. Veel handelingen van de game zullen vanaf deze map te doen zijn. Zo opent elke locatie op de map een eigen menu van zwevende knopjes waarmee de speler handelingen op die locatie kan verrichten, zoals een locatie toe-eigenen of een handeling verrichten op een nederzetting van een andere speler. Als de speler een nederzetting bezoekt dan wordt deze weegegeven als een plattegrond met daarop de verschillende gebouwen. Door te klikken op deze gebouwen zullen verschillende handelingen verricht kunnen worden zoals het upgraden van een gebouw. Daarnaast gaat de toolbar een grote rol spelen in het nieuwe design. Deze geeft bovenin het scherm altijd een aantal actuele statistieken weer en bevat knoppen naar andere belangrijke onderdelen van het spel zoals de karavaan, berichten en objectives. Meer hier over in 4.2 Interaction design.

4.1.3 Artisan (Ambachtsman) De Artisan is een nieuwe unit die is bedacht om spelers een extra sociale optie te geven. Het basis principe van de Artisan is dat hij de productie van een nederzetting een boost geeft aan de hand van zijn XP en level. De enige manier voor de Artisan om XP te vergaren is om deze bij een nederzetting van een andere speler te stationeren. Op deze manier voegt het de mogelijkheid toe om andere spelers te helpen, waar je voorheen vrijwel alleen maar nadelige handelingen bij andere spelers kon uitvoeren zoals het stelen van goederen of het saboteren van bepaalde gebouwen.

4.1.4 Right Hand (Rechterhand) De Right Hand is een duurdere unit die later in de game handig is. Wanneer een nederzetting een tijdje niet bezocht wordt ontstaat er corruptie, in de praktijk betekend dit dat als een nederzetting vijf dagen niet is bezocht deze één goud per dag gaat kosten. Dit neemt per dag met het dubbele toe tot een maximum van 256 goud. Door de nederzetting te bezoeken vervalt de corruptie. Dit zorgt er dus voor dat spelers min of meer gedwongen worden om nederzettingen regelmatig te onderhouden door ze te bezoeken, waardoor spelers goed moeten nadenken waar ze een nederzettingen bouwen. Nadeel hiervan is dat spelers later in het spel zoveel nederzettingen hebben dat het lastig wordt om ze allemaal te blijven bezoeken. De Right Hand kan hier een oplossingen bieden, als jouw rechterhand kan je hem op pad sturen naar corrupte nederzettingen om de corruptie daar te bestrijden in jouw naam. Dit moet wel goed afgesteld zijn want het is niet de bedoeling dat spelers nooit meer langs hun nederzettingen hoeven te gaan.

35

4.1.5 Visuele karavaan Voor beginnende spelers kan het nog wel eens lastig zijn om te begrijpen wat je als speler nou precies representeert. In principe ben je zelf een karavaan die met jouw actuele GPS gebaseerde positie meereist en zo nederzettingen op locaties kan bouwen en bezoeken. Om dit duidelijker over te brengen aan de speler wordt de karavaan ook weergegeven op de nieuwe omgevingsmap. Als de speler bijvoorbeeld een handeling op een locatie heeft uitgevoerd wordt de karavaan bij die locatie weergegeven.

4.1.6 Visuele schatten Om in Merchant 1.5 een schat te zoeken moest er eerst naar een locatieaanzicht genavigeerd worden en op het schat knopje worden geklikt waarna er een kleine kans was om daadwerkelijk een schat te vinden. In de praktijk betekende dit voor spelers die aan het rondrijzen zijn om schat te zoeken dat ze zo snel mogelijk één voor één alle negen locaties moeten openen en op het schat icoontje klikken om vervolgens op relocate te klikken om het spel aan te passen aan je gewijzigde GPS locatie om weer opnieuw te beginnen met alle negen locaties af te gaan. Dit is een heel repetitief proces en dit willen we tegengaan door niet pas te kijken of ergens een schat ligt wanneer de speler er op klikt, maar om deze visueel op de map weer te geven, en alleen wanneer er ook daadwerkelijk een schat ligt. De speler moet dus op de map op zoek naar een schat, ligt deze er dan kan hij op de locatie klikken en op de 'graaf schat op' knop om deze te vergaren.

4.1.7 Betere chat functie en contact informatie De huidige Merchant heeft een beperkte sociale integratie. Je kan spelers alleen als contact toevoegen als je daadwerkelijk bij een nederzetting van deze speler bent, en alleen als je contact bent kun je elkaar berichtjes sturen. In Merchant 2.0 wordt Game Center in de app geïntegreerd waardoor spelers automatisch contact zijn met hun Game Center vrienden, en je spelers toe kan voegen met hun Game Center ID. Daarnaast moet het mogelijk zijn om spelers op naam te zoeken en vervolgens aan je Game Center vrienden toe te voegen. Ook moet het makkelijker zijn om met vrienden te chatten en moet er meer informatie over vrienden te zien zijn, met betrekking tot hun Kingdom, aantal inwoners, aantal nederzettingen etc. Dit maakt het voor spelers makkelijk om hun voortgang met elkaar te vergelijken.

4.1.8 Overig Verder zijn er een aantal documenten opgesteld die de concepten in groter detail uitwerken. Zo is er het units document, terug te zien in bijlage C, die voor elke unit in detail beschrijft wat deze doet en op welk level. Daarnaast is het level verloop op de schop gegooid, er zijn nu zestig levels in plaats van twintig en speelt de speler bepaalde onderdelen vrij naarmate hij een hoger level bereikt, dit is in groter detail besproken in 5.4 Unit fase.

4.2 Interaction design Voor het nieuwe design is een interaction design gemaakt. Omdat grote delen van de game hetzelfde blijven qua interaction design is er alleen rekening gehouden met de nieuwe onderdelen. De nieuwe omgevingsmap (surroundings view) staat centraal in het interaction design. Vanaf hier kunnen verschillende handelingen worden verricht op de map en vanaf de toolbar bovenin het scherm kan naar andere delen van de app worden genavigeerd. Bijvoorbeeld naar de 'Kingdom' tab welke hetzelfde is als de huidige game en is daarom niet verder uitgewerkt in het wireframe.

Figuur 18: Het nieuwe interaction design vanaf de omgevingsmap.

36

37

4.3 Prototype Vanuit het oog van het nieuwe design van de omgevingsmap en het interaction design is er een prototype gemaakt. Er is gekozen om eerst een prototype te maken om de nieuwe, alleen met iOS 7 te gebruiken sprite engine Sprite Kit te testen. Sprite Kit biedt een grafische render infrastructuur en werkt met een traditionele update loop. Daarnaast is er een vrij uitgebreide animatie infrastructuur wat het makkelijk maakt om eenvoudige animaties uit te voeren met de spritesI. Omdat dit een nieuwe engine is en de basis interface die de rest van de game aan elkaar knoopt volledig zal veranderen wordt er dus eerst een prototype gemaakt waar de nieuwe technieken in zullen worden getest. Mocht dit allemaal goed gaan en naar wens functioneren dan is het de bedoeling dat de nieuwe omgevingsmap en de toolbar in een keer overgezet kunnen worden naar het Merchant 1.5 project wat vervolgens verder door het leven zal gaan als Merchant 2.0.

4.3.1 Omgevingsmap en toolbar Na onderzoek te hebben gedaan naar Sprite Kit is er gelijk begonnen met het bouwen van het prototypen aan de hand van het interaction design. Hierbij is eerst de opbouw van de omgevingsmap en het locatieaanzicht gemaakt, hiervoor was ooit binnen Oberon al art gemaakt voor een toekomstige update dus hier kon ik gelijk mee aan de slag. Vervolgens werd de toolbar middels Sprite Kit gebouwd. Toen deze in vrij korte tijd grofweg waren neergezet (zie screenshots), werd geacht bewezen dat het haalbaar is om de nieuw plattegrond op deze manier neer te zetten.

Figuur 19: Omgevingsmap.

Figuur 20: Middels Sprite Kit geanimeerde toolbar.

I Sprite Kit programming guide - About Sprite Kit (2013) Bezocht op 23-09-2013 https://developer.apple.com/library/IOs/documentation/GraphicsAnimation/Conceptual/SpriteKit_PG/Introduc tion/Introduction.html

38

4.3.2 Popup menu en view container Vervolgens is er op het prototype verder gebouwd om deze geschikt te maken om over te zetten naar het complete Merchant project. Zo is langzamerhand de gebruikersinteractie en vormgeving verbeterd. Daarnaast is er gelijk rekening gehouden met het originele project en zijn er lege containers aangemaakt waar bepaalde schermen van de huidige game in kunnen worden geplaatst. En is er een popup menu toegevoegd waaruit verschillende handelingen op een locatie gedaan kunnen worden zoals spioneren en goederen ophalen.

Figuur 21: Kingdom scherm geopend vanuit de toolbar.

Figuur 22: Locatie popup menu geopend door op een locatie te klikken.

39

4.3.3 Grens probleem Verder zijn er oplossingen bedacht voor problemen met het huidige design. In het design was geen rekening gehouden met het geval waar een gebruiker precies op de grens staat van twee verschillende gebieden, bijvoorbeeld een woestijn en een jungle. Dit is eerst gepoogd op te lossen door beide achtergronden te laten overlappen en dan mooier in elkaar over laten vloeien doormiddel van sprite kit' texture blend modesI, maar dit gaf niet het gewenste resultaat. Er is uiteindelijk een tijdelijke oplossing gekomen door een gradiënt grens tussen beide gebieden te tekenen. Daarnaast is de toolbar van een lay-out en labels met dummy data voorzien.

Figuur 23: Grens probleem, er is geen rekening gehouden met de overgang tussen grens gebieden.

I

Figuur 24: Grens probleem, blend mode test.

Sprite Kit SKNode' SKBlendNode (2013) Bezocht op 30-12-2013 https://developer.apple.com/library/ios/documentation/SpriteKit/Reference/SKNode_Ref/Reference/Refer ence.html#//apple_ref/doc/c_ref/SKBlendMode

40

Figuur 25: Grens probleem, tijdelijke oplossing, en dummy data toolbar.

4.3.4 Niet haalbare concepten Device rotatie Er is geprobeerd rotatie van het scherm met de nieuwe map mogelijk te maken. Zodat als de telefoon word gedraaid wanneer de map is geopend deze mee roteert en de toolbar automatisch verdwijnt zodat de map in zogenaamde landscape modus gebruikt kan worden waarbij het scherm dus op zijn kant wordt gebruikt. Normaal gesproken zou dit geen probleem moeten zijn aangezien de rotatie automatisch uitgevoerd kan worden door de iOS SDK wanneer je hier gebruik van wilt maken. Het probleem is echter dat het ene moment de rotatie wel mogelijk moet zijn, en het andere moment niet, en dat is binnen dezelfde view controller niet mogelijk. Of de view controller ondersteund wel rotatie, of hij doet het niet en de view die de map weergeeft wordt altijd door dezelfde view controller weergegeven. Je zou de mogelijkheid tot rotatie wel aan en uit kunnen zetten maar wanneer je deze uitzet als het scherm al in landscape modus is, roteert deze niet automatisch terug wat het spel wel zou moeten ondersteunen wanneer er vanuit landscape modus een scherm wordt geopend die geen landscape modus ondersteund. Dit is waarschijnlijk een bewuste keuze van Apple aangezien er anders geforceerde rotaties optreden waar de gebruiker wordt gedwongen om zijn telefoon weer terug te draaien. Dit zou nog wel mogelijk zijn wanneer er een nieuw scherm wordt geopend maar dan nog moet de gebruiker zo min mogelijk worden gedwongen zijn telefoon te draaien. Het zou nog wel mogelijk zijn om handmatig de verschillende views te transleren om zo de juiste oriëntatie te forceren maar dit zou erg veel tijd vergen om juist te doen. Verder kwam naar voren na een aantal tests dat de rotaties geforceerd overkomen en dus het doel van de rotatie te niet doen: de gebruiker meer vrijheid geven in de manier hoe hij de app gebruikt. Er is dus afgezien van dit concept.

41 Interactief locatieaanzicht Voor het scherm dat de speler te zien krijgt wanneer hij een locatie bezoekt. Hetzij vanaf de omgevingsmap of een van zijn andere nederzettingen vanuit de Kingdom tab, zou ook een compleet nieuwe interface komen, hiervoor waren al ideeën voor en minimale designs voor gemaakt. Dit zou net als de omgevingsmap worden gebouwd met de Sprite Kit engine en de speler meenemen zijn nederzetting in. De speler zou een isometrisch aanzicht van zijn nederzetting te zien krijgen waar een landschap is te zien en de gebouwen van zijn nederzetting op staan. Door opzij te vegen kan de speler meer van de nederzetting te zien krijgen. Net zoals bij de omgevingsmap kan de gebruiker op gebouwen klikken om statistieken te zien of acties uit te voeren zoals het gebouw upgraden, stock ophalen of soldaten trainen. De toolbar zou in dit aanzicht specifieke details geven van de locatie zoals het aantal inwoners en de productie capaciteit. Nederzettingen zouden er per landschap en productie tak anders uit kunnen zien. Zo zou een kippenboerderij andere gebouwen hebben dan een steengroeven, en is het landschap waar de gebouwen staan anders als deze zich in een woestijn bevindt tegenover de bergen. Hoewel het prototype aantoonde dat het een haalbaar concept is, bracht het ook in herinnering hoeveel moeite het zou kosten om compleet uit te werken. Er zijn in totaal eenentwintig gebouwen in een nederzetting, waarvan vier afhankelijk zijn van de productie tak, en acht gebouwen verschillende upgrade levels hebben. Al deze gebouwen moeten met bijbehorende art correct op de plattegrond geplaatst worden en moeten allemaal aparte acties of informatie schermen vanaf de map weergeven. Verder kunnen er evenementen worden georganiseerd die bijvoorbeeld op het dorpsplein weergegeven moeten worden. Dit paste gewoonweg niet in de scope van de stageperiode.

Figuur 26: Concept voor een interactief locatieaanzicht.

42

4.4 Opgeleverde producten Aan het einde van deze fasen zijn er een aantal producten opgeleverd. Deze worden hieronder kort in detail besproken.

4.4.1 Merchant 2.0 concepten Aan de hand van het analyse onderzoek zijn bepaalde concepten bedacht, daarnaast zijn er ook andere concepten bedacht met als doel iets aan het spel toe te voegen. Zoals gewoonweg meer mogelijkheden voor de speler of om bestaande onderdelen te verbeteren. Zie hiervoor bijlage B.

4.4.2 Merchant 2.0 units Het hele unit model is op de schop gegaan. Elke unit kan nu 2 keer geüpgrade worden, ze beginnen op Rookie en worden vervolgens geüpgraded naar Expert en als laatst naar Master. Units hebben een bepaald aantal XP nodig alvorens ze naar het volgende level geüpgrade kunnen worden, elke unit vergaard XP op een andere manier. Zie bijlage C.

4.4.3 Merchant 2.0 level verloop In de huidige Merchant kon de speler level twintig bereiken, maar dit duurde ontzettend lang en het level voegde verder niet zoveel toe naast dat er op sommige levels een beloning werd uitgedeeld zoals een opslag unit. In Merchant 2.0 kan er tot level zestig geleveld worden, waarbij het aantal XP per level minder snel toeneemt zodat het niet te lang duurt per level. Daarnaast spelen levels bepaalde functionaliteit vrij. Zie hiervoor figuur 41 in 5.4 Unit fase.

4.4.4 Objectives De objectives zijn opdrachten die de speler van de koning krijgt en zijn ingedeeld in twee verschillende categorieën. De primaire objectives vormen de rode draad door het spel, vooral in de beginfase spelen deze een belangrijke rol. Deze bestaan uit een reeks (optionele) opdrachten die de speler door het spel begeleiden. Zie bijlage D. De secundaire objectives vormen geen bepaalde volgorde, een speler krijgt gewoonweg elke dag een nieuwe willekeurig gekozen opdracht uit een bepaalde groep voor zijn level. Deze zorgen er voor dat spelers ook later in het spel elke dag iets hebben om te doen. Zie bijlage E.

4.4.5 Prototype Het prototypen zoals die in dit hoofdstuk is besproken.

4.4.6 Product backlog De product backlog bevat een lijst met onderdelen die we in de game verwerkt willen zien. Zoals bijvoorbeeld de primaire objectives. Deze lijst wordt per iteratie gebruikt om te bepalen wat ervan gedaan zal worden. Zie bijlagen F voor de complete product backlog.

43

5. Realisatiefase Door samenkomst van omstandigheden en op korte termijn veranderende prioriteiten op kantoor hadden de personen die verantwoordelijk waren om bepaalde veranderingen aan de server scripts door te voeren niet de tijd die we hadden berekend bij het samenstellen van de iteraties. Hierdoor liepen bepaalde onderdelen vertraging op en werden onderdelen van andere sprints naar voren gehaald die wel gedaan konden worden zonder verandering aan de scripts. Hierdoor zijn de verschillende iteraties door elkaar gaan lopen, maar hierover meer in H6.2 Reflectie. Hieronder zal ik toch per fase de verschillende onderdelen belichten om het overzichtelijker te houden.

5.1 Redesign, refactor en merge fase De eerst sprint van de realisatie fase staat volledig in het teken van het refactoren van de oude code base (door Joris van Gasteren). Het verder verbeteren van de gebruikers ervaring van met name de omgevingsmap van het prototypen, gemaakt tijdens de ontwerpfase. En het uiteindelijk samenvoegen van deze twee, wat vanaf dan als het Merchant 2.0 project door het leven zal gaan en de basis zal vormen voor de rest van de realisatie.

5.1.1 Gemaakte keuzes Omdat er niet genoeg tijd is om de hele applicatie van scratch af aan overnieuw te schrijven is er gekozen om het nieuwe design van de map, ontwikkeld in het prototypen tijdens de ontwerpfase, samen te voegen met het oude Merchant 1.5 project. Om dit samenvoegen zo soepel mogelijk te laten verlopen en de verdere ontwikkeling van de game te vergemakkelijken moet een groot deel van de oude code gerefactored worden opdat grote delen in de huidige vorm slecht herbruikbaar zijn. Een van de iOS developers die ook een aantal updates heeft gedaan aan eerdere versies van Merchant, Joris van Gasteren, zal zich over de refactor van het oude project ontfermen. Hij zal de eerste helft van de sprint de tijd nemen om grote delen van de code die niet meer nodig zijn weg te gooien en vrijwel alle views refactoren naar een beter te onderhouden structuur. In het kort zal hij er dus voor zorgen dat er een overzichtelijker en beter te onderhouden project overblijft dat klaar is voor het invoegen van het prototypen. In de tussentijd zal ik nog een laatste slag slaan aan het prototypen om vooral de opmaak en de gebruiker interactie met de interface te verbeteren. Hieronder vallen onder andere het invullen van de interactieve toolbar, het visueel op de map weergeven van de karavaan, het verbeteren van het gedrag van het popup menu en de algehele interactie met de map. Daarnaast zal ik het protypen klaar maken voor het gebruiken van echte data van de server voor de invulling van de inhoud. Deze sprint zal dus vooral in het teken staan van het refactoren van het oude project, het samenvoegen van het oude project met de nieuwe interface van het prototypen en de app correct gebruik laten maken van de (nieuwe) backend scripts.

44

5.1.2 Opgeleverde producten Vernieuwd design en interactie Met betrekking tot het design zijn er nog een aantal grote verbeteringen doorgevoerd in het begin van de sprint om de gebruikers ervaring te verbeteren en het visueel aantrekkelijker te maken. Zo wordt de omgevingsmap omgeven door een rand (een Fog of War) wat het mogelijk maakt om verder uit te zoomen en een overgang voorstelt tussen de omgeving die de speler kan zien en wat hij niet kan zien. Daarnaast zijn met betrekking tot het popup menu dat verschijnt als je op een locatie klikt een aantal verbeteringen doorgevoerd. Deze krult nu om de locatie heen en de locatie zelf wordt via een visuele weergaven geselecteerd zodat het voor de gebruiker nog duidelijker is dat de acties die hij via dit menu uitvoert betrekking hebben op de geselecteerde locatie. Verder centreert de map automatisch op de geselecteerde locatie en is deze de focus tijdens het zoomen zodat de aandacht automatisch op de geselecteerde locatie wordt gevestigd. Ook is zogenaamde deceleration aan de map toegevoegd, wat betekend dat de map langzaam tot stilstand komt wanneer deze beweegt als gevolg van een handeling van de gebruiker. Als de gebruiker zijn vinger over het scherm veegt blijft de map door bewegen nadat het scherm los is gelaten. Vervolgens neemt de snelheid van deze beweging af tot dat deze compleet tot stilstand komt.

Figuur 27: Verbeterd menu en locatie selectie.

Figuur 28: Fog of War en de GPS map achter de omgevingsmap.

45 Interactieve toolbar De weergaven van de toolbar is ingevuld en geeft de meest belangrijke statistieken weer die de gebruiker ten alle tijden nodig kan hebben bij het maken van belangrijke beslissingen. Er zijn links ook twee knoppen om gemakkelijk het social en objectives scherm, respectievelijk, te openen. Daarnaast kan doormiddel van bijvoorbeeld op de statistieken te klikken met betrekking tot de voorraad, het voorraad scherm worden geopend. Visuele schatten en karavaan In plaats van de gebruiker op een knopje te laten drukken om naar een schat te zoeken en deze vervolgens een kans geven om iets te vinden, zijn de schatten naar de map verplaatst. Deze worden nu alleen op de kaart weergegeven als er daadwerkelijk een schat op te graven valt. Daarnaast wordt de karavaan, de feitelijke belichaming van de speler, op de map weergegeven bij de nederzetting waar hij zich op dat moment bevind, of waar hij als laatste een actie heeft uitgevoerd.

Figuur 29: Schatten en de karavaan.

Verwijderen van de 'ververs' knop Er is een systeem ontwikkeld waarbij labels die een tijd weergeven zichzelf automatisch updaten. Ook zullen schermen die inhoud weergeven die na verloop van tijd, of zelfs bij het openen al, verouderd kunnen zijn in dat geval een update van de server vragen en zichzelf verversen. Op deze manier hebben we de ververs knop die voorheen op elk scherm werd weergegeven kunnen verwijderen. Samengevoegd 2.0 project Halverwege de sprint hebben we het prototypen in het Merchant 2.0 project gevoegd. Hierbij is de nieuwe omgevingsmap van het prototypen het nieuwe begin scherm van het spel en de plaats van waaruit de rest van het spel bereikt kan worden. Link backend Na het samenvoegen van het prototypen met het Merchant 2.0 project moest de nieuwe omgevingsmap nog correct met de data van de server aangesloten worden omdat het prototypen tot nu toe alleen nog maar dummy data gebruikte. Hiervoor zijn een aantal aanpassingen op de server doorgevoerd omdat op sommige plekken meer, en op een andere manier, informatie nodig was. De server moet bijvoorbeeld meteen meegeven of er op een locatie een schat ligt zodat deze weergegeven kan worden. De omgevingsmap krijgt nu andere data van de server die hij nodig heeft om een correcte weergaven te maken van de omgeving.

46

5.2 Objectives fase De tweede sprint staat in het teken van de objectives. Dit wordt een vrijwel compleet nieuw systeem van twee soorten objectives, de primaire en secundaire objectives, welke de speler door het hele spel heen van opdrachten voorzien. Dit was vooral voor de backend een zware fase omdat de server bij elke actie van de gebruiker verschillende regels moet controleren of de speler hiermee vooruitgang heeft geboekt met een objective.

5.2.1 Gemaakte keuzes Uit de analyse van de spelerdata was gebleken dat de tutorial in de oude versie van het spel een groot obstakel is voor veel spelers, en ook een hoop spelers vlak na de tutorial stoppen met spelen (binnen enkele minuten). Daarom is besloten om de huidige tutorial er helemaal uit te halen en dit te vervangen door een objectives systeem. Hierbij is gekozen voor twee soorten objectives, namelijk de primaire objectives en de secundaire objectives, alle opdrachten zijn optioneel. Primaire objectives De primaire objectives zijn de rode lijn door het spel en worden per level vrijgespeeld. Deze zijn van te voren vastgesteld, zowel de opdracht als de volgorde waarin deze voor de speler beschikbaar komen. Het doel van de primaire objectives is om de speler weg wijs te maken in het spel en hem de goede kant op te sturen. In plaats van de oude tutorial van vijf opdrachten in een gesloten omgeving worden de rode objectives door vrijwel het hele spel heen getrokken waarbij ze in het begin sturend zijn en naar mate het spel vordert de speler steeds meer vrijheid geven. Secundaire objectives De secundaire objectives worden daarentegen willekeurig gekozen uit een grote pot van opdrachten aan de hand van het level van de speler. Deze objectives zijn een goede manier voor de speler om XP te vergaren en geeft ze iets te doen om het spel voor op te starten. Er is voor een systeem gekozen waarbij de speler een vast aantal secundaire objectives heeft die hij kan gaan voltooien, als er eentje wordt voltooid komt er een nieuwe willekeurige opdracht beschikbaar. Objectives kunnen worden geweigerd, in welk geval na een bepaalde tijd een nieuwe objective beschikbaar komt. Deze countdown is vervolgens weer af te kopen met Kings Favors. De speler heeft maximaal drie secundaire objectives, als hij er geen 3 heeft die klaar zijn om te doen dan is de rest in afwachting met een countdown beginnende bij 30 minuten.

5.2.2 Opgeleverde producten De volgende producten zijn aan het einde van de sprint opgeleverd. Objective lijsten Lijst die de regels beschrijft die de server moet kunnen controleren om te zien of een speler een bepaalde objective heeft gehaald. Bijvoorbeeld 'bouw gebouw x' waarbij x elk willekeurig gebouw kan zijn. Aan de hand van deze lijst, welke objectives de server dus kan controleren, zijn de definitieve primaire en secundaire objective lijsten gemaakt.

47 Objectives interface Voor de objectives view was een nieuwe interface nodig. Voor de twee verschillende objective types is een tabje om er tussen te schakelen. Verder zie je standaard een lijst met objectives die voor de speler actief zijn en die nog niet gedaan zijn. Daarnaast is er voor de primaire objectives ook een lijst met objectives die wel voltooid zijn.

Figuur 30: Objectives interaction design wireframe.

48

Figuur 31: Objectives begin scherm, lijst met beschikbare primaire objectives.

Figuur 32: Dummy secundaire objective.

49 Scroll bericht Wanneer er bepaalde belangrijke berichten voor de speler zijn, zoals waarschuwingen of errors waarom een bepaalde handeling niet mogelijk is, of bepaalde berichten die terug komen van de server, worden deze doormiddel van een geanimeerde scroll weergegeven.

Figuur 33: Scroll tijdens de animatie.

Figuur 34: De uitgevouwen scroll.

Map achtergrond Om de speler bewuster te maken van het feit dat hij een locatie gebaseerde game aan het spelen is, en om een mogelijkheid te geven om de locatie ten opzichte van de echte wereld te zien wordt er een plaatje van een plattegrond achter de omgevingsmap weergegeven, zoals te zien is in komende screenshots. Bij het opstarten van het spel wordt er op de achtergrond de standaard MKMapkit van iOS geladen, en hier wordt een zogenaamde snapshot van gemaakt. Dit plaatje wordt vervolgens in de SpriteKit die de omgevingsmap weergeeft als achtergrond sprite gebruikt. Gradiënten Verschillende grafische verbeteringen doormiddel van het vervangen van gradiënt plaatjes door het programmatisch maken van gradiënten. Zo is de overgang van de grenzen tussen twee verschillende gebieden verbeterd. Bijvoorbeeld bij de overgang van heuvels naar woestijn wordt de overgang natuurlijker gemaakt met een gradiënt van groen naar geel. Verder is de rand om de omgevingsmap heen vervangen door een gradiënt en de manier hoe wordt aangegeven welke locatie is geselecteerd.

50

Figuur 35: Voor het toevoegen van de map achtergrond en gradiënt.

Figuur 36: Na, map achtergrond en FoW en geselecteerde locatie gradiënt.

Figuur 37: Na, de gradiënten die de grens van vier verschillende gebieden verbind.

51

Grotere omgevingsweergaven Vooruit lopend op de scout unit, is het nu mogelijk om de omgeving niet alleen door middel van een drie bij drie weergaven weer te geven maar ook grotere eenheden, zoals vijf bij vijf hieronder weergegeven.

Figuur 38: Omgevingsmap met een 5 bij 5 locatie weergaven.

52

5.3 Sociale fase Het sociale onderdeel van het spel willen we in de nieuwe versie op een paar punten verbeteren. In de oude Merchant was het al mogelijk om een contact met een andere speler te worden en elkaar berichten te sturen. Maar het was bijvoorbeeld alleen mogelijk om een andere speler een bericht te sturen of als contact uit te nodigen als je deze ook echt in de wereld tegen kwam (een van zijn nederzettingen bezocht). Dit willen we op een aantal punten verbeteren met onder andere een zoek functie waarmee spelers een contact verzoek kunnen sturen, betere integratie met Game Center, meer statistieken over de contacten en een betere chat functie.

5.3.1 Gemaakte keuzes Merchant is een MMORPG, oftewel een massaal online rollenspel. Spelers kunnen nederzettingen van andere spelers tegenkomen en hier verscheidene acties uitvoeren, waar de eigenaar van de nederzetting middels berichtgeving van op de hoogte wordt gebracht, hetzelfde geld voor het kopen van goederen op de markt. Spelers worden dus door middel van berichten bewust gemaakt van de acties die andere spelers uitvoeren en die betrekking hebben tot hun koningrijk of handel. Verdere sociale actie, zoals het direct communiceren met andere spelers werd niet bevorderd en was ook niet nodig om bepaalde doelen te halen of acties uit te voeren. In Merchant 2.0 willen we een aantal veranderingen doorvoeren die het makkelijker moet maken voor spelers om elkaar te vinden, met elkaar te communiceren en hun voortgang met elkaar te vergelijken. Daarnaast is er een nieuwe unit bedacht, de Artisan, die interactie tussen spelers bevordert, daarover meer in 5.4 Unit fase.

5.3.2 Opgeleverde producten Interaction design De oude Profile tab in Merchant 1.5, die een aantal basis statistieken over de speler weergaf zoals level en punten maar daarnaast ook de berichten weergaf, is in Merchant 2.0 vervangen door de Social sectie welke via een knop op de toolbar geopend wordt. Hierop zijn de functionaliteit van de oude Profile en het nieuwe Social scherm samengevoegd aan de hand van het volgende interaction design.

Figuur 39: Social scherm.

Figuur 40: Social interaction design wireframe.

53

Zoekfunctie In de zoekfunctie kunnen spelers op naam naar andere spelers zoeken, waarna ze een lijst met spelers te zien krijgen met korte informatie over die spelers zoals rank, hun relatie tot die speler en de laatste keer dat deze online is geweest. Verder worden hier de Game Center vrienden weergegeven die ook Merchant spelen.

54 Game Center De game is al gedeeltelijk geïntegreerd met Game Center, zo wordt sinds versie 1.5 de Game Center ID van spelers gebruikt om ze te identificeren, voorheen werd hier een unieke ID voor gebruikt die uniek is per iOS device. Omdat we een duidelijke scheiding willen houden tussen Game Center vrienden en contacten in Merchant zullen Game Center vrienden niet automatisch een contact zijn. Dit omdat spelers dat misschien niet wenselijk vinden, in verband met privacy of gameplay strategisch. Contacten kunnen van elkaar namelijk extra informatie inzien zoals de laatste keer dat hij heeft ingelogd, de regio (waar een speler de regie over kan hebben) waar dit was, bijvoorbeeld Amsterdam. En een aantal Gameplay statistieken zoals aantal nederzettingen en inwoners. Daarom worden je Game Center vrienden alleen weergegeven bij de zoekfunctie. Al open je de zoek functie dan staat de lijst met Game Center vrienden die Merchant spelen er automatisch, vervolgens kan er met de zoekfunctie tegelijkertijd tussen de normale spelers en Game Center vrienden worden gezocht, waarna de speler ervoor kan kiezen om deze een verzoek tot contact te versturen. Contact statistieken Om de prestaties in het spel beter te kunnen vergelijken met vrienden zal er meer informatie beschikbaar zijn over de andere spelers en vooral de contacten. Alle spelers zullen op hun profiel pagina informatie bevatten over hun rank, de relatie tot deze speler en de laatste keer dat de speler heeft ingelogd zodat te zien is of het een nog actieve speler is. Contacten zullen daar en tegen meer uitgebreide informatie bevatten, zoals level, aantal nederzettingen, inwoners en regio waar hij/zij voor het laatst actief was. Al deze informatie zorgt dat spelers zich goed kunnen vergelijken met hun vrienden. Daarnaast zullen er ook nieuwe units worden geïntroduceerd waarbij deze informatie van belang kan zijn zoals de Artisan. Chat functie Het is al mogelijk om berichten naar elkaar te sturen, maar het systeem hiervoor nodigt in zijn huidige status niet uit tot het chatten tussen spelers. Het systeem voor het sturen van berichten moet het voor spelers makkelijker maken om met elkaar te communiceren.

55

5.4 Unit fase De vierde, en tevens laatste thema fase staat in het teken van de units. Het hele systeem achter de units gaat flink op de schop en er zullen een aantal nieuwe units bij komen. De units zijn min of meer opgedeeld in twee verschillende soorten, de opslag units en de specialisten. De opslag units zijn bijvoorbeeld paarden en wagens, hiervan kan de speler er een ongelimiteerd aantal van in zijn karavaan hebben en zijn alleen bedoeld om de opslag capaciteit van de karavaan te vergroten. Daar tegen over staan de specialist units, of de specialisten. Deze dienen allemaal een specifiek doel, passief of actief en hiervan kan je er in de oude versie van sommige maar één hebben en van andere meerderen. Onder de specialisten vallen bijvoorbeeld de Thief die je in staat stelt om goederen bij andere nederzettingen te stelen, of de Gold Digger die de kans vergroot om schatten te vinden.

5.4.1 Gemaakte keuzes In Merchant 2.0 is het de bedoeling dat de specialisten een grotere rol gaan spelen in het spel. Om dit te bereiken zullen de bestaande specialisten op de schop gaan en zullen er een aantal nieuwe specialisten bijkomen. Van elke specialist kan de gebruiker er maar één in zijn karavaan hebben. Voorheen was het bijvoorbeeld mogelijk om meerdere spionnen te hebben, wat de speler in staat stelden om meerdere keren achter elkaar te proberen om te spioneren als het de eerste keer mislukte. Daarnaast zal elke specialist twee keer te upgraden zijn, van Rookie, naar Expert, naar Master. Op deze manier blijven units langer interessant omdat een unit die op Rookie level bijvoorbeeld alleen interessant is voor de beginfase van het spel na een upgrade ook weer interessant kan zijn voor een latere fase. Verder hebben is er voor gekozen om niet alles gelijk beschikbaar te stellen aan de speler. In de oude versie waren alle specialisten en opslag units gelijk beschikbaar voor de speler, en was de goud prijs een drempel waardoor spelers pas later in het spel bepaalde units konden kopen. Waar in het oude spel de speler een maximum van level twintig kon behalen, is ongeveer hetzelfde aantal XP in de nieuwe versie verdeeld over zestig levels. Hierdoor zullen spelers sneller een level omhoog gaan, wat al een beloning op zich is omdat spelers hun level met andere spelers kunnen vergelijken, maar kunnen we ze ook vaker belonen door op bepaalde levels nieuwe specialisten vrij te spelen. Verder wordt de speler zo niet overdonderd door een groot aantal mogelijkheden die hij toch nog niet kan gebruiken, maar worden de nieuwe opties geleidelijk aan geïntroduceerd en kan de speler bij elk nieuwe level op de nieuwe mogelijkheden gewezen worden. Daarnaast zijn er een aantal nieuwe units bedacht. Ze zullen niet allemaal in de uiteindelijk versie van het spel belanden maar er zijn nieuwe units bedacht om bepaalde problemen proberen op te lossen die aan het licht zijn gekomen door de analyse van de spelerdata (zie 3. Analysefase). Zo zijn er nieuwe units bedacht om bepaalde handelingen die tijdens het verloop van het spel te repetitief worden te minimaliseren, een extra sociaal component toevoegen, spelers tijdens de begin fase meer opties geven om spullen te verzamelen of om spelers die in de latere fase veel nederzettingen hebben tegemoet komen.

5.4.2 Opgeleverde producten Vrijspelen van onderdelen Zoals in onderstaande illustratie is te zien zullen er op verschillende levels bepaalde onderdelen vrijgespeeld worden. De tweede kolom geeft een schatting weer van hoelang een gemiddelde speler ongeveer bezig is om dat punt in het spel te bereiken. Hoewel de speler maximaal level zestig kan bereiken, is bij level dertig alles vrijgespeeld, het level wordt dan nog wel gebruikt voor het bepalen voor welke objectives een speler in aanmerking komt en geld als een prestige statistiek waarmee spelers elkaar kunnen vergelijken. Zodra een specialist beschikbaar is kan de speler deze kopen doormiddel van goud of een in-app aankoop. Om een specialist te kunnen upgraden moet er eerst een bepaald aantal XP behaald zijn met die unit voordat deze geüpgrade kan worden (zie bijlage C). Zo moet de speler bepaalde units wel gebruiken voordat hij ze kan upgraden.

56

Figuur 41: Volgorde van vrijspelen.

Upgraden van specialisten Zoals in bovenstaande illustratie ook valt op te merken zijn er van elke unit drie verschillende types. Wanneer de speler een nieuwe unit aanschaft begint deze op het zogenaamde Rookie level. wanneer de speler het juiste level heeft bereikt, en genoeg XP heeft vergaard met de specialist, kan hij deze upgraden naar het volgende level. In de onderstaande illustratie is hiervan een voorbeeld te zien. Wanneer de speler de unit aanschaft, op Rookie level, verbetert deze specialist de productie van een nederzetting. De productie heeft betrekking op de eersterangs goederen die vooral belangrijk zijn in het begin van het spel. Na het upgraden van de unit, naar Expert level, verbetert de Artisan niet alleen de productie van eersterangs goederen, maar ook de fabricage van tweederangs goederen en zo wordt deze specialist ook weer interessant voor spelers later in het spel.

57

Figuur 42: De Artisan specialist.

Artisan De Artisan specialist is ontstaan nadat ik een bepaald probleem in de huidige versie van de game had opgemerkt. Bepaalde acties die een speler kan doen bij een nederzetting van een andere speler hebben effect op de relatie tussen die speler. Zo kan een speler doormiddel van een Thief proberen goederen te stelen uit een nederzetting. Dit heeft uiteraard een negatief effect op de relatie tussen deze spelers. De andere negatieve acties zijn saboteren, wat een gebouw tijdelijk buiten werking stelt, en dus mogelijk de productie stopt, en spioneren (wanneer de spion wordt betrapt). De acties die een positieve invloed hebben zijn het optreden met een Minstrel, waar de eigenaar van de Minstrel goud voor krijgt en de eigenaar van de nederzetting eigenlijk niks voor krijgt, en pay respect, het achterlaten van handelswaar als cadeau. Ik vond de positieve acties niet helemaal in verhouding staan met de negatieve en wilde er een wat socialere specialist aan toevoegen. Eentje waarvoor spelers misschien met elkaar gaan communiceren. Daarnaast leek het me een leuke optie om spelers de mogelijkheid te geven om de opbrengst van één bepaalde nederzetting te verhogen mocht hij deze goederen harder nodig hebben dan anderen. Daar is de bovenstaande Artisan specialist uit gekomen. Wanneer deze gestationeerd wordt bij een nederzetting verhoogd hij de opbrengst van deze nederzetting. Het sociale onderdeel is dat hij alleen XP vergaard wanneer hij wordt gestationeerd bij de nederzetting van een andere speler, en met een verhoging van maximaal 15% kan het voor spelers erg lonen om onderling afspraken te maken om hun Artisan bij elkaar neer te zetten. Right Hand De Right Hand specialist is bedacht als elite unit voor de latere fase van het spel en spelers die veel nederzettingen hebben en sommige niet meer zo vaak bezoeken. Als een speler vijf dagen achter elkaar een nederzetting niet bezoekt wordt deze namelijk corrupt. Dit houd in dat de nederzetting elke dag geld gaat kosten. Het begint met één goud en neemt per dag met het dubbele toe. Spelers kunnen de Right Hand kopen met een in-app aankoop en deze kan vervolgens in hun naam naar een nederzetting afreizen om daar de corruptie te doen dalen. Het is een vrij dure specialist omdat het ook een groot voordeel met zich mee brengt, spelers hoeven niet meer al hun nederzettingen langs, maar het is toch vooral een optie die het leven van de speler vergemakkelijkt en hem niet perse een voordeel oplevert tegenover andere spelers. Aangezien je er ook voor kan kiezen om alleen nederzettingen te bouwen op plaatsen waar je vaak komt of die in de buurt zijn. Of je verlies kunt nemen en gewoon de corruptie betalen. De Right hand kan nooit alle van de maximaal veertig toegestane nederzettingen corruptieloos houden aangezien er een volledige dag nodig is voor zijn taak.

Figuur 43: De Right Hand unit.

58 Andere specialisten Het unit document is te zien in bijlage C. Deze bevat alle andere opslag units en specialisten. Ze zullen niet allemaal in het spel belanden maar zijn wel op een zeker moment bedacht als zomaar een idee of oplossing voor een bepaald probleem. Units die ik nog heb bedacht hiervoor zijn de Saboteur 2, als directe tegenhanger van de Artisan. De Treasure Hunter, aangezien de Gold Digger in zijn originele vorm uit het spel verdwijnt zal deze specialist het voor spelers later in het spel ook weer interessant maken om schatten te zoeken, en kunnen er opnieuw schatten gevonden worden in gebieden waar de normale schatten al zijn gevonden. Carrier Andere belangrijke veranderingen met betrekking tot de specialisten zijn de Carrier. Deze specialist haalt de goederen op bij een van je nederzettingen als je zelf niet in de buurt bent. Voorheen kon je er zoveel van hebben als je wilt en werd het later in het spel een erg repetitieve handeling om elke dag een Carrier naar elk van je nederzettingen te sturen. De nieuwe carrier kan, als hij geüpgrade is, automatisch langs alle nederzettingen gaan wat een op den duur erg irritante handeling overbodig maakt. Worker Daarnaast is de Worker een belangrijke nieuwe unit. Deze kan op een lege plek, dus waar nog geen nederzetting is gemaakt, aan het werk worden gezet om eersterangs goederen te verzamelen. Deze unit zal dus vooral interessant zijn voor spelers in het begin van het spel en zal dus ook gelijk beschikbaar zijn. De unit doet er een korte tijd over om de spullen te verzamelen waarna de gebruiker hem weer op een andere plek aan het werk kan zetten. Het geeft de speler dus de mogelijkheid om te blijven spelen en maakt zo de gameplay een stuk sneller voor de beginnende spelers. Scout Verder is de Scout een belangrijke nieuwe unit. Dit is een speciale unit, alleen verkrijgbaar als in-app aankoop en tegen een vrij hoge prijs maar vergemakkelijkt het leven van de speler aanzienlijk. De scout geeft de speler namelijk de mogelijkheid om een groter gebied om zich heen te zien. Waar normaal in totaal een gebied van drie bij drie locaties te zien is, kan er met de scout op het hoogste level tot maximaal zes bij zes locaties te zien zijn. Zo kan de speler acties uitvoeren op een groter gebied zonder meer te reizen.

59 Unit acties Alle unit acties die betrekking hebben op een nederzetting zullen te doen zijn vanaf de omgevingsmap, zoals in onderstaande illustratie is te zien. Welke unit acties mogelijk zijn worden door de server bepaald, deze geeft per locatie aan welke acties beschikbaar zijn. Wordt een actie niet meegegeven dan wordt de bijbehorende knop ook niet weergegeven. Of de actie ook daadwerkelijk op dat moment uitgevoerd kan worden door de speler wordt aangegeven doormiddel van een bijbehorende code. Wanneer deze nul is, kan de actie uitgevoerd worden en wordt de knop normaal weergegeven. Als deze een ander getal als nul is komt deze overeen met een code die terug te vinden is in de database en overeenkomt met een tekst. In dat geval wordt de knop met een grijs tint weergegeven, en zal deze de bijbehorende waarschuwing tonen als er toch op de knop gedrukt wordt. Wanneer de speler het juiste level heeft behaald waarbij de actie beschikbaar is zal deze altijd worden weergegeven, eventueel met bijbehorende waarschuwingscode als de betreffende specialist nog niet ingehuurd is.

Figuur 44: Specialisten acties vanaf de omgevingsmap.

60 User interface De interactie tussen de unit schermen is er als volgt uit komen te zien. De opslag units worden simpelweg weergegeven als een lijst met de opslag units die de speler heeft en hoeveel hij er daarvan heeft. Dit is niet anders dan in de voorgaande versie. Het specialisten scherm en de lijst met specialisten die op dit moment niet in de karavaan aanwezig zijn en dus op weg zijn moeten wel op de schop. Aangezien je van elke specialist er nog maar één kan hebben, vanaf het detail scherm van de specialist kan je deze terug roepen naar de karavaan, en je kan zien wat er nodig is om deze te upgraden. Vervolgens kan je in een volgend scherm meer details over de upgrade zien en deze vervolgens uitvoeren. Het koop unit scherm is simpelweg een lijst met units die je vanaf dat scherm gelijk kan kopen.

Figuur 45: Unit interaction design wireframe.

61

6. Conclusie Hier bespreek ik het uiteindelijk behaalde resultaat en reflecteer ik op mijn werkzaamheden en het verloop van het project proces.

6.1 Resultaat De probleemstelling was als volgt gedefinieerd in 2. Plan van aanpak: Een nieuwe versie van Merchant Kingdom die gebruik maakt van de laatste ontwikkelingen op iOS gebied, een nieuwe omgevingsmap heeft en andere speltechnische toevoegingen en verbeteringen met oog voor de beginfase met zich mee brengt gaat de nieuwe versie uitmaken, Merchant 2.0. Alle drie van deze punten zijn volledig afgewerkt. De applicatie is geschikt en maakt gebruik van de nieuwste technieken van iOS 7. Er is een volledig nieuwe en interactieve omgevingsmap opgezet. En de beginfase van het spel is aangevuld met de primaire en secundaire objectives, een nieuwe unit (worker) en het sneller levelen en daarmee vrijspelen van onderdelen. Het is dan wel niet gelukt om aan het einde van de stage een product op te leveren die volledig klaar is voor een App Store release, wat wel een streven was aan het begin van de opdracht. Maar daar voor in de plaats zijn er een aantal extra onderdelen opgeleverd zoals de objectives, het upgrade systeem van de units en is er vanaf de omgevingsmap een volledig nieuw interaction design geïmplementeerd waarin de omgevingsmap en de toolbar centraal staan. Verder heeft de omgevingsmap zeer uitgebreide functionaliteit gekregen met het oog op de acties die vanaf de map gedaan kunnen worden. Daarnaast is veel design gemaakt waar geen tijd voor was om het te implementeren. Zoals in de product backlog en concepten te zien is (bijlage F en B respectievelijk) zijn er nog allerlei concepten bedacht die niet in de uiteindelijke versie zijn gekomen maar waar wel (game-) design en documentatie voor is gemaakt.

6.2 Reflectie Hier zal ik reflecteren op mijn tijd bij Oberon Interactive, aller eerst aan de hand van mijn eigen ervaringen en daarna op het proces van het verloop van de opdracht.

6.2.1 Eigen ervaring Bij het maken van de opdracht heb ik veel vrijheid gekregen van Oberon, niet alleen in het bouwen van de applicatie maar ook in het bedenken en naar voren brengen van nieuwe concepten en ideeën. Als een gevolg heb ik het erg naar mijn zin gehad, en vond ik het leuk om aan de opdracht te werken. Ik vind het jammer dat het niet is gelukt om een product op te leveren dat af is voor een release in de Apple App Store, maar dat wat neergezet is kan door Oberon in relatief korte tijd hiervoor klaar gemaakt worden. Het grootste onderdeel dat nog gedaan moet worden is het nieuwe design van de schermen, de designer heeft dit voor het grootste gedeelte al opgezet en ik ben begonnen met de implementatie hiervan. Verder moet de balans van het spel opnieuw getest worden. Ik heb het erg naar mijn zin gehad bij Oberon met het werken aan deze opdracht omdat ik veel vrijheid kreeg om mijn eigen ideeën voor te dragen en uit te werken. Ik kon me erg goed vinden in de ideeën die op een eerder tijdstip al bij Oberon waren bedacht en tijdens het proces zijn ontstaan, en zo hebben we een aantal erg leuke toevoegingen aan het spel kunnen doen. Verder kon ik het goed vinden met mijn collega's welke stuk voor stuk erg ervaren zijn in hun vakgebied en mij daardoor goed konden helpen als ik ergens tegenaan liep.

62

6.2.2 Proces Zoals eerder al genoemd was de originele planning door omstandigheden in het water gelopen. Er waren op kantoor door een samenloop van omstandigheden andere prioriteiten ontstaan met betrekking tot de indeling van de backend developer die aan de server kant veranderingen door zou voeren die ik nodig had om de desbetreffende fase af te ronden. Omdat Merchant een project van Oberon zelf is, en de rest van de projecten allemaal in opdracht zijn van klanten zijn de deadlines van die projecten belangrijker voor Oberon dan een tussentijdse deadline van Merchant. Dus toen er door omstandigheden een tekort aan mankracht was en er problemen waren ontstaan met andere projecten moest de developer die de backend taken voor Merchant op zou pakken bijspringen. Dit kan ik begrijpen en heb ik ook begrip voor maar helaas gebeurde dit al tijdens de eerste iteratie van de realisatie fase. Deze fase was erg licht aan de backend kant maar de iteratie die daarna zou komen, de objectives fase, was daar en tegen erg zwaar voor de backend. Tegen die tijd was de situatie nog niet verholpen en als gevolg heeft de backend vrijwel de hele realisatie fase achter de feiten aan gelopen. Uiteindelijk is het wel opgelost doordat twee andere developers zijn ingepland om bij te springen, maar aangezien die eerst met andere projecten bezig waren en de planning al een aantal weken van te voren wordt gemaakt heeft dit enige tijd geduurd. In de tussentijd had ik het voor mijzelf opgelost door aan andere taken te gaan werken waar ik geen veranderingen aan de server kant voor nodig had. Dit betekende wel dat ik aan taken moest beginnen die eigenlijk pas waren geplant voor de volgende iteratie, waardoor alle iteraties door elkaar heen gingen lopen en er geen gestructureerde opzet meer bestond van definiëren, implementeren, testen en opleveren. Onderstaande illustraties laten zien hoe het verloop van de realisatiefase er volgens de planning uit had moeten zien, en een benadering van hoe het verloop er in de realiteit uit zag.

Figuur 46: Originele planning van de realisatiefase.

Figuur 47: Benadering van het uiteindelijke verloop van de realisatiefase.

Met grootste uitschieter de objectives fase, die aan de backend kant toch enigszins onderschat was, vooral de secundaire objectives. De regels van deze objectives moesten willekeurig gegenereerd worden aan de hand van een aantal gegevens zoals het level van de speler. Dit was lastig om te implementeren omdat er veel verschillende regels zijn en ze ook allemaal gecontroleerd moeten worden als er een actie is uitgevoerd. Hieraan zijn zodoende tot op het laatste moment nog onderdelen toegevoegd wat aan de applicatie kant dan weer getest moest worden.

63

7. Aanbevelingen Hier volgt mijn advies aan Oberon Interactief met betrekking tot de ontwikkeling en onderhoud van Merchant 2.0 nadat mijn stageperiode tot een einde is gekomen. Dit advies is gebaseerd op conclusies getrokken uit de analyse (3. Analysefase), taken die nog gedaan moeten worden voordat het spel uitgebracht kan worden. En naar wat er in mijn ogen moet gebeuren nadat het spel uit is gebracht om het voor spelers interessant te houden.

7.1 Voor de release De volgende onderdelen moeten nog afgewerkt worden voordat het spel uitgebracht kan worden. Dit zijn onderdelen die niet in de planning van de stageperiode pasten of die pas gedaan kunnen worden nadat alle spel technische onderdelen volledig zijn gebouwd, dat is op het moment van schrijven nog niet het geval. Testen Er zijn met deze nieuwe versie een aantal onderdelen bijgekomen die veel aan het model van het spel veranderen. Zo zijn de objectives toegevoegd die de speler de mogelijkheid geven om veel XP te verdienen, en is er de Worker unit die best een impact zou kunnen hebben op het verloop van de beginfase van het spel. Dan is er nog de Carrier unit, een van de belangrijkste units van het spel en die is volledig op de schop gegaan. En het vrijspelen van de verschillende spelonderdelen aan de hand van het speler level. Al deze onderdelen hebben een impact op het volledige verloop van het spel. Dit moet dus goed getest worden. Om dit goed te kunnen doen moet het spel gespeeld worden door een groepje mensen. Aangezien het een MMORPG is, zal dit bij definitie een tijdrovende onderneming zijn aangezien het normaal gesproken een paar weken duurt voordat een speler überhaupt een kasteel zou kunnen bouwen. Mijn aanbeveling is dan ook om qua balans van het spel verloop vooral te richten op de beginfase van het spel. Op deze fase zal de impact van de objectives, nieuwe units en vrijspelen van onderdelen de grootste impact hebben. Het grootste probleem wat ik hier zie ontstaan is dat spelers te makkelijk XP verdienen en zo sneller in level stijgen dan dat de bedoeling is. Dan zouden spelers bijvoorbeeld het kasteel al vrijspelen een week voordat de gemiddelde speler hem kan veroorloven. Dan hopen de vrijgespeelde onderdelen zich op en ontstaat er precies de situatie die we met het vrijspelen van onderdelen willen vermijden. Gelukkig kan dit eenvoudig tegen gegaan worden door of minder XP uit te delen met de objectives, of door het benodigde XP per level omhoog te doen. Aangezien dit met een formule wordt berekend kan dit eenvoudig gedaan woorden door het basis getal aan te passen. Naar aanleiding van een meeting die we hebben gehad (Boer, R. de. 2013b) zou het mogelijk moeten zijn om alle timers in het spel, die de server bijhoud, met een factor te versnellen. Dit zou het proces van testen aanzienlijk versnellen.

64 Design Op het moment van schrijven is designer Sho Stegmeijer vrij ver gevorderd met het design van de schermen en interface onderdelen. Mijn advies is dan ook om dit design af te maken waarbij de meeste schermen opnieuw werden ontworpen en plaatjes bijgewerkt. Dit geeft het spel een nieuw en fris uiterlijk waarbij het samen met de nieuwe omgevingsmap echt als een opvolger van het oude Merchant Kingdom voelt.

Figuur 48: Nieuwe design voor de locatie info en acties vanaf de omgevingsmap.

Figuur 49: Nieuwe design voor het locatieaanzicht.

65

7.2 Na de release Aan de hand van de analyse in 3. Analysefase was naar voren gekomen dat het grootste gedeelte van de spelers die met Merchant Kingdom begonnen tijdens of vlak na de tutorial stopten. Daarna bleef het grootste gedeelte van de spelers wel een tijdje spelen maar nam dit weer vrij snel af na het punt waar spelers ongeveer alles hebben vrijgespeeld en gedaan. Om dit tegen te gaan is het belangrijk om het spel te blijven onderhouden en andere acties te ondernemen om oude spelers een reden te geven om te blijven spelen. Updates Doormiddel van (kleine) updates uit te brengen met nieuwe spel elementen krijgen oude spelers weer een reden om het spel op te starten. In de product backlog in bijlage F staan nog een aantal onderdelen die niet in de planning pasten maar later als updates uitgebracht kunnen worden. De in mijn ogen belangrijkste concepten zal ik kort toelichten. Nieuwe units Door het toevoegen van nieuwe units geef je de speler gelijk een aantal nieuwe opties. Zo krijgt de speler iets nieuws om te doen, in het geval van de Highwayman een actie uitvoeren op de locatie van een andere speler. Het mooie bij de units is dat de speler ze ook nog twee keer kan upgraden dus mocht hij het een leuke unit vinden, of het laatste level van de unit erg interessant vinden, heeft hij genoeg te doen. Een goede unit voor een latere update zou de Treasure Hunter zijn. Deze unit geeft spelers in de laatste fase weer de mogelijkheid om schatten te vinden op oude locaties. Zo kan hij dus weer opnieuw beginnen met het doorzoeken van zijn omgeving naar, deze keer grotere, schatten. Muren Een andere veelzijdige toevoeging zou zijn die van de muren in combinatie met de Battering Ram of Marschall unit. Dit geeft spelers de mogelijkheid om één van drie verschillende soorten muren om zijn nederzetting of kasteel heen te bouwen om hem extra te verdedigen bij een aanval. De tegenhanger hiervan is de Battering Ram, herdoopt tot Marshall, die voor elk upgrade level meer verdedigingspunten van de muur teniet doet en XP verdient door nederzettingen aan te vallen. Objectives Doordat de objectives volledig op de server worden gegenereerd en bijgehouden is het mogelijk om zonder een update van de applicatie de objectives aan te passen. Zo kunnen er steeds nieuwe objectives aan het spel toegevoegd worden. Interactief locatieaanzicht Zoals eerder bedacht en kort getest tijdens de ontwerpfase, maar wat niet in de planning pasten, zou het een mooie toevoeging zijn om het locatie scherm te vervangen met een Sprite Kit scene vergelijkbaar met de omgevingsmap. Het zou er uitzien als een dorpje dat van een zijaanzicht wordt bekeken en de gebruiker op huisjes kan klikken om acties uit te voeren. Gaande weg wordt het dorpje steeds uitgebreider. Dit zou wel een grotere update zijn. Acties Om de aandacht vast te blijven houden zouden er ook andere acties gedaan kunnen worden. Zo zouden er kortingsacties gegeven kunnen worden op bepaald in-app aankopen. Of de King kan bepaalde acties uitvoeren die betrekking hebben tot het hele spel. Denk aan hij (of de barbaren) geeft een bericht uit dat ze goederen in de uitverkoop doen voor een bepaalde periode. Of spelers krijgen tijdelijk de scout specialist zodat ze het voordeel hiervan in kunnen zien.

66

Bronnenlijst Gesprekken - Boer, R. de. Bijeenkomst voor het invullen van de stageovereenkomst, Amsterdam, 27 juni 2013a. -

Boer, R. de. Wekelijkse bijeenkomst: objectives, Amsterdam, 21 oktober 2013b.

Wetenschappelijk - Yee, N., Ducheneaut, N., Yao, M., en Nelson, L. Do Men Heal More When in Drag? Conflicting Identity Cues Between User and Avatar. Proceedings of CHI 2011, 2011. -

Lou, J.-K., Park, K., Cha, M., Park, J., Lei, C.-L., en Chen, K.-T. Gender swapping and user behaviors in online social games, Rio de Janeiro, Brazil, 2013.

Websites - Jarvinen, A. "First Five Minutes: How Tutorials Make or Break Your Social Game" (2010) Bezocht op 09-10-2013 http://www.gamasutra.com/view/feature/132715/first_five_minutes_how_tutorials.php -

Merchant Kingdom, about. Bezocht op 10-09-2013 http://www.merchantkingdomgame.com/about

-

Merchant Kingdom, pedia. Bezocht op 10-09-2012 http://www.merchantkingdomgame.com/pedia/output/pedia.html

67

Begrippenlijst MMO(-RPG) Massive Multiplayer Online (Role Playing Game), oftewel een massaal online meerspeler (rollen) spel, waarmee online videospellen worden bedoeld waarbij een groot aantal spelers tegelijk met elkaar kunnen spelen binnen een virtuele wereld. Gameplay Met gameplay wordt de manier bedoeld hoe spelers het (computer) spel ervaren en wordt bepaald door de regels die door het spel zijn neergezet maar ook door de besturing, presentatie en het geluid. XP Experience points, vrij vertaald naar het Nederlands zijn het ervaringspunten. Vrijwel altijd gebruikt als de afkorting XP of Exp en wordt veel gebruikt in (computer)rollenspellen als beloning voor de speler voor het afronden van opdrachten, het verslaan van vijanden of het behalen van andere prestaties. Is een graadmeter van hoe ver men is gevorderd in het spel. Kings Favors Kings Favors zijn een speciaal soort valuta binnen Merchant die spelers doormiddel van een in-app aankoop kunnen bemachtigen. Kings Favors worden binnen het spel gebruikt om tijd af te kopen, denk hier aan de tijd dat het duurt om een gebouw te bouwen of die een Carrier unit nodig heeft om naar de karavaan terug te keren. Fog of war Fog of war, vrij vertaald als oorlogsmist, is een term die in computerspellen wordt gebruikt wanneer een deel van het landschap voor de speler onzichtbaar wordt gemaakt omdat het buiten zicht is, vaak in de vorm van een donkere mist. Gold sink Vrij vertaald een 'goud afnemer'. Een proces in een video spel waarbij goederen of een valuta, bijvoorbeeld goud, uit de economie wordt gehaald om inflatie tegen te gaan. Interaction Design Het interaction design van een software product definieert de structuur en het gedrag van de software vanuit het perspectief van de gebruiker. In-app aankopen Met in-app aankopen worden alle aankopen bedoeld die gedaan kunnen worden vanuit een applicatie nadat deze al op een apparaat is geïnstalleerd, vrijwel altijd voor geld. In-app tier prijzen Wanneer je een applicatie via de Apple App Store verspreid en hierin in-app aankopen wilt aanbieden ben je altijd afhankelijk van de in-app tier prijzen bepaald door Apple. Zo staat tier 1 voor €0.79 en tier 2 voor €1.59 etc. Van tijd tot tijd worden deze prijzen verhoogd. SCRUM Scrum is een flexibele projectmethode om software producten te maken. Door middel van korte iteraties, genaamd sprints, wordt er door een multidisciplinair team telkens werkende software opgeleverd om na een x aantal sprints tot het eind product te komen. Product backlog De product backlog in de SCRUM project methodologie verwijst naar een (op prioriteit) gesorteerde lijst met eisen. Dit kan bestaan uit nieuwe functionaliteit, bugs of nonfunctionele toevoegingen die afgewerkt moeten worden om tot het gewenste eindproduct te komen.

68

A. Vroege concepten Merchant 2.0 Dit document bevat een aantal ideeën voor verbetering van de huidige en toevoeging van nieuwe spelelementen om Merchant te verbeteren door bepaalde "problemen" op te lossen of nieuwe functionaliteiten en mogelijkheden toe te voegen. De ideeën zijn ingedeeld in de volgende 3 categorieën: veranderingen ter verbetering van de interface zodat het meer als een game oogt, het aanpassen huidige elementen ter verbetering van de spel balans en het oplossen van problemen, en ten slot het toevoegen van nieuwe functionaliteiten die het spel leuker moeten maken en de speler meer opties geven.

A.1 Verbetering van de interface A.1.1 Nederzetting als plattegrond - Wat: In plaats van de nederzetting weer te geven d.m.v. een paar categorieën (basis, speciaal etc.) met daarachter een tableview met de verschillende gebouwen kan de nederzetting weergegeven worden op een plattegrond of een (scrollbaar) vooraanzicht van gebouwen en lege kavels. - Waarom: Dit zal een aantal (saaie) knoppen en tableviews die de nederzetting representeren vervangen door een interactieve representatie van de nederzetting en oogt hopelijk meer uitnodigend voor de onervaren management/MMO gamer. - Extra: Een combinatie van een plattegrond en een scrollbaar vooraanzicht. Op de plattegrond is je nederzetting van bovenaf te zien met een aantal gebieden zoals een productie gebied met alle productie gebouwen en opslag of het stadscentrum met de pub, tavern en de housing etc. Wanneer je op een van deze gebreide klikt kom je in een scrollbaar vooraanzicht van dat specifieke gebied. A.1.2 Karavaan weergeven op de omgevingskaart - Wat: Je karavaan als icoontje o.i.d. weergeven op de omgevingskaart. - Waarom: Dit geeft duidelijker weer aan de speler dat jij de karavaan bent. A.1.3 Karavaan weergeven op de omgevingsmap (afhankelijk van 1.) - Wat: De karavaan wordt weergegeven op de plattegrond of vooraanzicht van de nederzetting waar je op dat moment bent. - Waarom: Laat de speler duidelijk zien dat jij als karavaan de nederzetting binnen bent en visualiseert nogmaals, net als punt 2, wat je eigenlijk bent als speler.

A.2 Aanpassen huidige elementen A.2.1 Upgrade carrier - Wat: Een carrier zal in eerste instantie een stuk goedkoper zijn dan in de huidige situatie, maar deze kan maar een maximale hoeveelheid spullen dragen, vervolgens kun je je carrier upgraden zodat deze meer kan dragen. Verder kan je maximaal zoveel carriers als nederzettingen. - Waarom: In de huidige situatie is het management in het begin van het spel m.b.t. je stock en het aantal carriers dat je tot je beschikking hebt vrij lastig, vooral omdat carriers dan relatief duur zijn en je nederzettingen niet veel op kunnen slaan. Verder in het spel zijn de carriers relatief juist heel goedkoop waardoor de game mechaniek van het managen van je carriers en het ophalen van je stock plots vrijwel wegvalt. Door carriers goedkoper te maken en vervolgens te upgraden wordt de overgang van de begin situatie waar het relatief veel werk is naar de uiteindelijke situatie waar je er bijna geen werk meer aan hebt een stuk geleidelijker en geeft de speler een extra doel waar hij langzaam heen kan werken.

69

-

-

-

-

A.2.2 Corruptie kwijtschelden Wat: De corruptie van een speler na een lange tijd van inactiviteit kwijtschelden. Dit kan in de vorm van een push bericht van de Koning omdat je koninkrijk (wat uiteindelijk weer valt onder dat van de koning) zo onbeheersbaar was geworden dat de Koning een handje heeft geholpen. Waarom: Dit moet ervoor zorgen dat speler die na een langdurige inactiviteit (paar weken), en ontmoedigd waren door de corruptie, een zetje krijgen om toch weer te gaan spelen. Kort gezegd moet het oude spelers aanmoedigen om weer te beginnen. Extra: Misschien nog een extra welkomst pakketje geven met wat gold o.i.d. om ze weer op weg te helpen en er op wijzen dat je maar een x aantal keer een nieuwe kans krijgt van de Koning. A.2.3 Voeg contact toe op naam Wat: Voeg een contact toe door simpelweg zijn naam te zoeken of via game center contacten. Waarom: Het moet makkelijker worden voor spelers om elkaar te vinden en met elkaar te communiceren.

A.3 Toevoegen van nieuwe functionaliteit -

-

-

-

-

-

A.3.1 Dagelijkse opdrachten Wat: Speler krijgt elke dag een kleine opdracht, al dan niet aangegeven door een push bericht. Denk aan simpele opdrachten als upgrade een gebouw, vind een schat of zelfs zo simpel als bezoek nederzetting (van een andere speler). Voor deze opdrachten zal de speler een kleine hoeveelheid XP en goud of simpele goederen krijgen. Waarom: Dit moet ervoor zorgen dat, vooral beginnende spelers, terug worden gelokt naar het spel en doormiddel van eenvoudige opdrachten verder wegwijs worden gemaakt in het spel. Extra: Deze opdrachten zouden qua moeilijkheidsgraad mee kunnen stijgen met het level van de speler. Waar de opdracht voor beginnende spelers haalbaar moet zijn om geen verwarring/frustratie te veroorzaken, kan een wat verder gevorderde speler bijvoorbeeld de opdracht krijgen bouw een theater. Een semigevorderde speler zou al snel in kunnen zien dat deze opdracht voor hem nog niet haalbaar is maar hij maakt toch kennis met de verschillende mogelijkheden. A.3.2 Afgezant/rechterhand Wat: Een nieuwe unit die in naam van de speler de corruptie in een nederzetting kan verlagen. Deze zal net als de carrier een bepaalde tijd onderweg zijn. Deze unit is uniek en doet er lang over (een dag?) ongeacht de afstand. De aanschafprijs en onderhoud moeten hoog genoeg zijn zodat deze alleen in de endgame tot de beschikking komt en er bestaat altijd een kans dat hij faalt waardoor hij terug wordt gestuurd / wordt opgesloten voor een paar dagen / o.i.d. Waarom: Laat in het spel kan corruptie erg vervelend worden, deze unit moet de spelers een extra optie geven om corruptie te bestrijden. Maar het zal nooit een volledige vervanger moeten worden voor het bezoeken van nederzettingen om corruptie tegen te gaan. Extra: Deze unit zou ook in plaats van goud te kosten alleen voor Kings Favors of geld te koop kunnen zijn.

70 A.3.3 Craft specialist - Wat: Deze unit zal later in het spel tot je beschikking komen en is uniek. Wanneer deze in een nederzetting wordt gestationeerd zal hij het productie proces van deze nederzetting overzien waardoor hij langzamerhand in level stijgt en uiteindelijk de productie bevorderd met zijn kennis. - Waarom: Geeft spelers later in het spel nog een laatste mogelijkheid om een van hun productie straten efficiënter te maken. - Extra: Mogelijkheid om de unit bij een nederzetting van een bevriende speler te stationeren waar hij vervolgens zijn kennis gebruikt om daar de productie enigszins op te voeren tegen betaling. A.3.4 Berichten achterlaten op locatie - Wat: Laat een bericht achter bij een nederzetting die je vervolgens kan lezen door er heen te gaan. - Waarom: Geeft spelers een extra (sociale) actie in hun eigen en andermans nederzettingen wat het sociale aspect van het spel moet verhogen. - Extra: In plaats van alleen een bericht voor de eigenaar kan er een soort van message board/paal zijn bij een nederzetting waar iedereen berichten kan plaatsen en deze kan lezen. A.3.5 Nederzetting raakt in verval - Wat: Als een speler voor een hele lange tijd (enkele maanden) inactief is zullen zijn nederzettingen in verval raken waarna ze volledig worden verlaten en de plek vrij komt voor andere spelers om een nederzetting te bouwen. - Waarom: Dit moet ervoor zorgen dat de wereld niet vol staat met inactieve spelers en dat deze locaties uiteindelijk geclaimde kunnen worden door actieve spelers. - Extra 1: Geef spelers een (aantal) waarschuwing(en) dat hun nederzettingen dreigen te vervallen. I.c.m. punt A.2.2 kan dat al wanneer de corruptie wordt kwijtgescholden. - Extra 2: Laat de nederzettingen van de speler niet gelijk vervallen, maar markeer ze als 'vervallen'. Wanneer ze als zodanig zijn gemarkeerd kunnen andere spelers de locatie claimen, of wat er van over is zoals alleen de basis gebouwen op een laag level omdat de rest is vervallen. Zolang andere spelers ze nog niet hebben geclaimd kan de originele speler de nederzettingen nog claimen. A.3.6 Verplaats inwoners - Wat: Geef de mogelijkheid voor spelers om hun inwoners van nederzettingen met hun karavaan te vervoeren, al dan niet met speciale wagens. - Waarom: Geeft spelers extra flexibiliteit met het verdelen van hun inwoners, kan bijvoorbeeld van pas komen bij het maken van een nieuwe nederzetting of wanneer een nederzetting weinig inwoners over houdt i.v.m. het trainen van een leger. - Extra: Nieuwe unit(s) die het vervoeren van mensen mogelijk maakt.

71

B. Concepten ontwerpfase Dit zijn concepten uit het brainstorm document waar tijdens de ontwerpfase allerlei concepten en ideeën in zijn geplaatst en waarvan de beste/haalbare verder zijn uitgewerkt. B.1 Upgrade Unit Specialisten kunnen worden geüpgraded voor betere functionaliteit en statistieken. Rookie -> Experienced -> Expert Spelers kunnen maar één Thief, Minstrel etc. kopen, deze kunnen ze dan upgraden om ze meer te laten stelen en/of een betere slaag kans te geven. Carrier -> vervoer meer en sneller Dragoman -> toegang tot goedkopere en zeldzamere spullen Betaal XP + goederen om te upgraden B.2 Right Hand Stuur je Right Hand naar een nederzetting om daar de corruptie te verlagen. Moet alleen beschikbaar zijn in de laatste fase van het spel (hoge onderhoudskosten?) en er zal een soort van straf of kans aan moeten zitten zodat het niet voor alle nederzettingen gebruikt kan worden. Daarnaast moet hij er vrij lang over doen, bijvoorbeeld een dag, zodat er niet snel achter elkaar veel nederzettingen bezocht kunnen worden. -

Technische implicaties: Nieuwe unit actie script Deamon changes Art? B.3 Artisan De Artisan verhoogt de productie, vervaardiging en ambacht wanneer in een nederzetting geplaatst en is gebaseerd op zijn XP. De Artisan wordt getraind wanneer hij in de nederzetting van een andere speler wordt geplaatst. Na een dag komt hij automatisch terug en heeft hij XP verdient. Wanneer hij bij een eigen nederzetting wordt geplaatst blijft hij daar totdat hij weer wordt opgehaald.

-

Technische implicaties: Nieuwe unit actie scripts Deamon changes Art? B.4 Laat de karavaan op de map zien Laat de karavaan van de speler als een icoontje op de omgevingsmap zien op de locatie die hij op dat moment aan het bezoeken is of waar hij als laatst is geweest. Op deze manier wordt aan de speler laten zien dat hij met zijn karavaan reist. De karavaan kan ook op het locatieaanzien worden weergegeven om aan te geven dat hij met de karavaan bij de locatie is die hij bekijkt, wanneer je een andere nederzetting in je imperium bekijkt waar je niet in de buurt bent ziet de speler dit niet. Technische implicaties: Alleen aan de applicatie kant, misschien verschillende plaatjes wanneer de karavaan groter wordt.

72 B.5 Migreer inwoners De speler kan speciale karren kopen waarmee hij inwoners van zijn nederzettingen in zijn karavaan mee kan laten reizen. Hierdoor kan hij inwoners van zijn nederzettingen van de ene naar de andere migreren. Dit maakt het voor de meer gevorderde spelers, die van micromanagement houden, mogelijk om zijn inwoners rond te schuiven om bijvoorbeeld een nieuwe nederzetting snel te bevolken of inwoners naar zijn barakken te brengen. Technische implicaties: - Nieuwe units nodig. - Caravan moet inwoners kunnen opslaan - Moet inwoners tussen de karavaan en nederzettingen kunnen verplaatsen, net zoals soldaten. B.6 De King verminderd corruptie Nadat een speler voor een lange periode inactief is geweest, krijgt hij een bericht van de Koning die hem verteld dat hij de speler heeft geholpen door hem van alle corruptie in zijn imperium af te helpen en dat hij hem een kleine hoeveelheid goederen en goud heeft gegeven om hem weer op weg te helpen. De corruptie in het spel werkt op een goede manier om spelers terug te laten komen, maar na een erg lange periode van corruptie kan het spelers afmoedigen om weer te beginnen met spelen. Hun imperium is dan zo corrupt dat (al) hun goud weg kan zijn waardoor spelers misschien minder snel weer gaan spelen. Kosten: de Koning neemt een deel of zijn complete leger in beslag. Technische implicaties: Vooral database en deamon, moet de duur en mate van corruptie van spelers bijhouden en vervolgens een bericht sturen, het liefst een push bericht. B.7 Nederzettingen raken in verval Wanneer een nederzetting voor een nog langere tijd corrupt is dan wanneer de Koning dit kwijt scheld (zie B.6) dan raakt de nederzetting in verval. In plaats van dat de nederzetting uit de wereld wordt verwijderd, andere spelers kunnen een nederzetting die in verval is repareren en eigen maken wanneer ze beginnen met de standaard gebouwen. Spelers waarvan de in verval geraakte nederzetting is kunnen gewoon inloggen om het verval ongedaan te maken. Dit zorgt ervoor dat de nederzettingen op drukke locaties in verloop van tijd weer in beheer komen van actieve spelers Technische implicaties: Database en deamon, moet de duur van de corruptie bijhouden en een waarschuwing sturen. Applicatie kant heeft plaatjes of icoontjes nodig om aan te geven wanneer een nederzetting corrupt is, ook moet er een werkwijze zijn om hem te repareren. B.8 Objectives De speler krijgt objectives (van de King) die hij kan voltooien voor XP en goud. Deze objectives zullen de tutorial vervangen en de spelers door de eerste fase van het spel loodsen. De objectives bestaan uit twee verschillende categorieën, de rode en de gele objectives. De rode objectives zijn de rode draad in het spel en helpen de speler op weg. De gele geven de speler meer te doen en een manier om XP te verdienen. Technische Implicaties: Vooral de server kant, waar de objectives gegenereerd en bijgehouden dienen te worden, de applicatie geeft ze alleen weer. Hier dient wel een interface voor ontworpen te worden.

73 B.9 Verhoog de kans van acties met Kings Favors De speler kan Favors gebruiken wanneer hij op het punt staat om een actie uit te voeren zoals stelen of spioneren om de kans op succes te vergroten. Een extra manier om Favors uit te geven. B.10 Geef de naam van de verkoper weer Wanneer de speler iets van de markt koopt, wordt er bij de goederen aangegeven welke speler deze goederen aanbiedt. Op die manier kan je kiezen van welke speler je goederen koopt en van welke juist niet aan de hand van je relatie met die speler. Zo kan de speler bijvoorbeeld kiezen om niet van iemand te kopen die hem recentelijk heeft aangevallen. Technische implicaties: De server moet van alle goederen op de markt bijhouden van welke speler ze zijn en dit meegeven. De app moet vervolgens voor dezelfde goederen die van allerlei verschillende spelers weergeven wat misschien snel onoverzichtelijk wordt, hier moet dus een goede interface voor ontworpen worden. B.11 Gedetailleerde contacten Laat meer details zien van de contacten van de speler. Naast hun rank kan ook het aantal inwoners en nederzettingen aangegeven worden. Misschien zelfs een lijst met zijn nederzettingen, net als de speler dat van zichzelf kan zien met de naam, productie typen en aantal inwoners. En een lijst met de aan de speler gelieerde nederzettingen. Zo kan de speler makkelijker de progressie van zijn vrienden bijhouden en met zichzelf vergelijken. B.12 Zichtbare schatten De schatten worden direct op de locatie op de omgevingsmap weergegeven, de speler kan ze vervolgens gelijk opgraven en zijn beloning innen. -

-

Technische implicaties: Alle locaties moeten direct zichtbaar zijn, geen Fog of War. De kans om een schat te vinden moet gelijk worden berekent bij het ophalen van de locaties en niet pas bij het zoeken naar de schat. Art voor de schat.

Figuur 50: De Unit spreadsheet, hierop zijn alle statistieken en eigenschappen van de units uitgewerkt. Gele arcering geeft aan dat er nog verder over nagedacht moest worden voordat ze in het spel verwerkt zouden kunnen worden en de rode arcering dat ze er hoogstwaarschijnlijk niet in zouden komen.

74

C. Units

Figuur 51: De Unit spreadsheet, hierop zijn alle statistieken en eigenschappen van de units uitgewerkt. Gele arcering geeft aan dat er nog verder over nagedacht moest worden voordat ze in het spel verwerkt zouden kunnen worden en de rode arcering dat ze er hoogstwaarschijnlijk niet in zouden komen.

75

D. Primaire objectives

Groene arcering is klaar en blauwe arcering moet nog getest worden.

Figuur 52: Een voorbeeld van een aantal secundaire objectives. Colom test geeft aan hoe de server moet testen of een objective gehaald is, x en y geven waar nodig weer hoe bepaalde waardes van de test gevuld moeten worden.

76

E. Secundaire objectives

77

F. Product backlog Dit is de product backlog die gebruikt is om de verschillende iteraties van de realisatie sprint te vullen. De arcering en nummering in de eerste kolom geeft de indeling aan zoals die er aan het einde uit zag.

Figuur 53: De product backlog zoals deze in de ontwerpfase is neergezet en gaan de weg in iteraties is ingedeeld.