INHOUDSOPGAVE. Hoofdstuk 1 Inleiding Pagina 03. Hoofdstuk 2 Gameconcept Pagina 05. Hoofdstuk 3 Audience, Platform en Marketing Pagina 06

Transcriptie

1

2 INHOUDSOPGAVE Hoofdstuk 1 Inleiding Pagina 03 Hoofdstuk 2 Gameconcept Pagina 05 Hoofdstuk 3 Audience, Platform en Marketing Pagina 06 Hoofdstuk 4 Gameplay Pagina 07 Hoofdstuk 5 Augmented Reality Pagina 10 Hoofdstuk 6 Game Character Pagina 13 Hoofdstuk 7 Media lijst / Assets List Pagina 15 Hoofdstuk 8 Techniek Pagina 16 Hoofdstuk 9 Weekverslagen Pagina 18 Hoofdstuk 10 Evaluatie Pagina 22 Hoofdstuk 11 Onderzoek Pagina 25 Pagina 2

3 HOOFDSTUK 1: INLEIDING 1.1 Projectdocument Het projectdocument laat zien welke stappen we tijdens het project hebben genomen en waarom. We beargumenteren onze beslissingen en geven inzicht in onze keuzes en handelingen. Het onderzoek hebben we achter in het document geplaatst omdat we ons met dit document eerst op de kern van het concept willen richten. 1.2 Visie en eindproduct We hadden in gedachten om een kant en klaar prototype op te leveren. Dit is helaas niet gelukt. De technische uitvoering liep niet zo soepel als gedacht en het viel ons toch wat tegen. In het begin van het project waren we aan het worstelen met het concept. We hadden wel ideeën welke kant we op wilden gaan, maar het werd maar niet concreet. 1.3 Context van het project We hebben een game ontwikkeld voor middelbare scholieren met het thema Drugs in the City waarmee de speler inzicht krijgt of iets leert over de invloed van drugs, het gebruik en de handel in de grote stad. Bij het maken van een serious game gaat het om het vertalen van elementen uit de werkelijke wereld naar spelregels en spelmechanismen. 1.4 Doelgroep De doelgroep zijn de middelbare scholieren van Nederlandse scholen. We maken geen onderscheid op cultuur of religie. We kijken ook niet naar het opleidingsniveau van de scholier (VMBO, HAVO, VWO of Gymnasium). Dit omdat we de game niet willen beperken door te kijken naar lesinhoud of lesniveau. 1.5 Doel van een Serious Game We willen jongeren onbewust laten leren tijdens het spelen van de serious game. Zo zal de speler in eerste instantie niet doorhebben dat het idee in de tweede laag vooral informatie bevat over drugs en de mindset bij het gebruiken van drugs. De eerste laag is wat de speler letterlijk ziet wanneer hij de game speelt. Verder moet de game een bepaalde funfactor bezitten waardoor de game een lust moet zijn om te spelen. Pagina 3

4 1.6 Planning De planning hebben we opgesteld aan het begin van het project. We hebben de planning tijdens het project aangepast en herschreven om verschillende eigen deadlines te halen. Maandag Dinsdag Woensdag Donderdag Vrijdag Zaterdag Zondag Kick Off Fieldresearch bezoek BNN Brononderzoek Games Brononderzoek bronnen Week februari 02 februari 03 februari 04 februari 05 februari 06 februari 07 februari Fieldresearch Bezoek Jellinek Brononderzoek bronnen Fieldresearch Bezoek Jellinek Preventie Brononderzoek bronnen Brononderzoek bronnen Week februari 09 februari 10 februari 11 februari 12 februari 13 februari 14 februari Conceptdag Fieldresearch Enquetes Fieldresearch Enquetes Week februari 16 februari 17 februari 18 februari 19 februari 20 februari 21 februari Drie concepten Karel Danny weg tot 2 maart Conceptdag Conceptdag Individuele concepten Individuele concepten Week februari 23 februari 24 februari 25 februari 26 februari 27 februari 28 februari Conceptdag Die concepten Karel pitchen Conceptdag Visuele stijl bepalen Week maart 02 maart 03 maart 04 maart 05 maart 06 maart 07 maart Groepsbespreking Concept finetunen Concept finetunen Digitaal prototype Week maart 09 maart 10 maart 11 maart 12 maart 13 maart 14 maart Groepsbespreking Kaarten afronden Gameart afronden Programmeren bug-delete-day Individuele taken afronden Individuele taken afronden Week maart 16 maart 17 maart 18 maart 19 maart 20 maart 21 maart Research inleveren uur Projectfilm Projectfilm Presentatie Projectfilm Presentatie Post Mortum Week maart 23 maart 24 maart 25 maart 26 maart Pagina 4

5 HOOFDSTUK 2: GAMECONCEPT Kabouter X heeft drugs gebruikt, maar dit gaat min of meer mis. Als speler moet jij ervoor zorgen dat je kan helpen bij de symptomen die de X vertoont. Dit kan je doen door de juiste handelingen uit te voeren bij het aanwezige symptoom. Het is jouw taak om de kabouter op te knappen, maar niet het kan natuurlijk ook wel eens fout gaan. 2.1 Game logline: Game in een zin Probeer de kabouter te helpen wanneer het fout gaat tijdens het gebruiken van drugs door de juiste handelingen uit te voeren. 2.2 Gameconcept De kabouter vertoont een aantal symptomen. Per beurt kunnen spelers enkel spelen tegen het op dat moment meest dominante symptoom. Spelers proberen de symptomen op te lossen door juiste handelingen te verrichten tegen het meest dominante symptoom. Bij het uitvoeren van een juiste handeling wordt de speler positief beloont, bij het spelen van een negatieve handeling krijgt de speler een negatieve score. Deze heeft ook een positieve zijde, namelijk dat je een andere speler een negatieve score kunt geven. Bij het oplossen van een symptoom krijg je bonuspunten. Als je een symptoom naar de afgrond brengt krijg je zelf alle schade. Een symptoom verdwijnt uit het spel wanneer het zijn uiterste heeft bereikt. Het spel is afgelopen als alle symptomen uit het spel verdwenen zijn. De speler met de hoogste score is de winnaar. We schetsen realistische toestanden waarin een drugsgebruiker zich kan bevinden, en laten de speler daar in een realistische manier mee omgaan. Door de game te spelen leert de scholier te handelen wanneer iemand in zijn of haar situatie drugs heeft gebruikt. Zo zou hij kunnen leren mensen met een bad trip gerust te stellen of mensen uit een bepaalde roes te halen. Zo leert de scholier te handelen om mensen die onder invloed zijn van drugs te helpen. Unique Selling Point Het unieke element van onze game is dat we een combinatie hebben gevonden tussen een digitale en een fysieke tastbare game door middel van Augmented Reality. Het leermoment verschult in de tweede laag van het concept en is niet direct waar het spel zelf om gaat. Daarnaast is de funfactor zodanig hoog doordat spelers vrij zijn om tegen of met elkaar te spelen, en de keuze hebben om de kabouter wel of niet te helpen. Leerervaring De acties die je als speler kunt uitvoeren in het spel op de kabouter zijn acties die je in het echte leven ook kunt uitvoeren om iemand te helpen als het foutgaat bij drugsgebruik. De speler leert door middel van kleine animaties en uitkomsten van handelingen op de situatie van het moment. Uit tests is gebleken dat de scholieren ook leren door onderlinge communicatie. Dit was zelfs de meest grote leerfactor. Look and feel We hebben gekozen om de look en feel van de game in een grungy stijl toe te passen. Dat wil zeggen dat niet alles even vrolijk is, en dat de kabouter er niet al te vriendelijk en verzorgd eruit ziet. Dit hebben we gedaan om een bepaalde sfeer neer te zetten. Pagina 5

6 HOOFDSTUK 3: AUDIENCE, PLATFORM EN MARKETING 3.1 Briefing We ontwerpen een serious game voor middelbare scholieren, met het thema Drugs in the City waarmee de speler inzicht krijgt of iets leert over de invloed van drugs, het gebruik en de handel in de grote stad. Bij het maken van een serious game gaat het om het vertalen van elementen uit de werkelijke wereld naar spelregels en spelmechanismen. 3.2 Doelgroep De doelgroep zijn de middelbare scholieren van Nederlandse scholen. We maken geen onderscheid op cultuur of religie. We kijken ook niet naar het opleidingsniveau van de scholier (VMBO, HAVO, VWO of Gymnasium). Dit omdat we de game niet willen beperken door te kijken naar lesinhoud of lesniveau. 3.3 Doel van een Serious Game We willen jongeren onbewust laten leren tijdens het spelen van de serious game. Zo zal de speler in eerste instantie niet doorhebben dat het idee in de tweede laag vooral informatie bevat over drugs en de mindset bij het gebruiken van drugs. De eerste laag is wat de speler letterlijk ziet wanneer hij de game speelt. Verder moet de game een bepaalde funfactor bezitten waardoor de game een lust moet zijn om te spelen. 3.4 Platform De platform van de game kan varieren van het besturingssysteem. Zowel op Windows als op Apple is de game speelbaar. Om geen problemen te hebben met het opstarten en spelen van de game raden wij aan om de game te draaien op Windows. Dit omdat de game is ontwikkeld op Windows. 3.5 System requirements Omdat de game gebruik maakt van Augmented Reality, heb je een aantal vereisten nodig om input te kunnen geven aan het spel: - Beamer / scherm (schermresolutie minimaal 1280 pixels) - Camera / webcam - Speelkaarten (kabouterkaarten + handelingskaarten) - Computer met minimaal Flashplayer 10 (de game draait binnen de Flash omgeving) - Minimum RAM van 2GB - Dual Core processor Het speelscherm wordt 1280 pixels breed zodat het beeld groot genoeg is om overzichtelijk en duidelijk te zijn. Uit onderzoek is gebleken dat de meeste beamers de dag van vandaag een resolutie aankunnen 1280 pixels. 3.5 Promotie / verspreiding van de game De game promoten we met een kleine campagne. Deze campagne bestaat bijvoorbeeld uit een website, een poster serie en folders voor middelbare scholen. We willen met de campagne vooral de scholieren en de scholen aanzetten tot overweging om de game te spelen. Als tweede laag komt daarbij kijken dat de les een educatieve inhoud over drugs bevat. Uiteraard kunnen we het de campagne ook op grotere schaal voeren. Misschien is het mogelijk om de applied game voor te leggen aan de Minister van Onderwijs. Zo zou de game doorgevoerd kunnen worden op elke middelbare school, en deel van het vakkenpakket kunnen worden. Niet dat het een apart vak wordt, maar dat het toegepast zou kunnen worden tijdens het vak levensbeschouwing of maatschappijleer. Een andere manier om de middelbare scholieren de game te laten spelen is om zelf presentaties aan middelbare scholen te geven. Zo zouden we scholen zelf voorlichting moeten geven over de applied game, en hen op het educatieve aspect moeten wijzen. Pagina 6

7 HOOFDSTUK 4: GAMEPLAY 4.1 Gameplay omschrijving Vier spelers nemen plaats achter een tafel die voor een scherm staat. Iedere speler krijgt 2 kaarten om te starten. Een random speler mag beginnen. Bij het begin van je beurt mag je een derde kaart trekken van de stapel handelingkaarten. De kabouter heeft enkele symptomen. Het symptoom wat het meest dominant is (de hoogste waarde heeft), is het symptoom waartegen gespeeld wordt. Het doel is om deze symptomen op te lossen (tot nul te herleiden). Als deze symptomen echter uit de hand lopen, worden ze ook uit het spel gehaald. De kabouter vertoont een symptoom waartegen de speler een handeling speelt. Deze handeling kan positief of negatief uitpakken. 4.2 Controls Omdat we deels een fysieke game hebben ontwikkeld zijn de controls zeer eenvoudig. De enige controls waarmee de speler te maken krijgt is het opgooien van een kaart. Dit gaat overigens per beurt kloksgewijs. De kabouterkaart ligt altijd in beeld, daarnaast moet een andere kaart gelegd worden. Wanneer de animatie volledig is afgespeeld kan de opgegooide kaart aan de kant worden gelegd, buiten het bereik van de camera. 4.3 Rules - Elke speler krijgt 2 kaarten - Bij het begin van een beurt wordt een nieuwe kaart getrokken (dus 3 kaarten max. in hand) - Elke speler begint met een score van 0 punten - Symptomen krijgen een willekeurige startwaarde - Het meest dominante symptoom (symptoom met hoogste waarde) is het symptoom waartegen gespeeld wordt. Als bij het begin van een beurt een ander symptoom een hogere waarde heeft, wordt dit het symptoom waartegen gespeeld wordt. - Verhelpen van een symptoom levert een bonus op van Bij het spelen van de Bel 112 (instant cure) kaart krijgt de speler die deze kaart gespeeld heeft, als positieve punten de waarde van het symptoom op dat moment - De bel 112 kaart verdwijnt uit het spel als hij gespeeld is - Als een handeling gespeeld wordt die negatief werkt, worden de negatieve punten door de speler aan een speler naar keuze toegewezen - Ben je echter de oorzaak van het uit de hand lopen van een symptoom, dan krijg je zelf de negatieve punten - Bij het uit de hand doen lopen / verhelpen krijg je enkel de overschot van punten die een symptoom nog heeft, niet de waarde van de actie Score / win conditions De score bepaald uiteindelijk wie de game heeft gewonnen. Een spelersscore is altijd individueel en kan positief of negatief zijn. Bij het uitvoeren van een juiste handeling wordt de speler positief beloont, bij het spelen van een negatieve handeling krijgt de speler een negatieve score. Deze heeft ook een positieve zijde, namelijk dat je een andere speler een negatieve score kunt geven. Bij het oplossen van een symptoom krijg je bonuspunten. Als je een symptoom naar de afgrond brengt krijg je zelf alle schade. - Elke speler begint met een score van 0 punten - Een scoremeter (6 stuks) heeft een waarde van 0 tot Bij het opgooien van een negatieve kaart ontvang je zelf -5 punten. De volledige puntenvan de kaart geef je weg aan een tegenspeler. Wanneer je met deze kaart een meter tot 0 brengt krijg een puntenaftrek van -20 punten. - Bij het opgooien van een positieve kaart krijg je zelf alle punten. Wanneer je met deze kaart een meter tot 100 brengt krijg een beloning van +20 punten. Pagina 7

8 4.4 Scherminterface De scherminterface laat zien hoe de interactie verloopt tijdens het spelen van de game. INTERFACE SPEELSCHERM Versie: 2.0 Datum: 9 maart 2010 Project: Drugs in the City GAMEPLAY LAADSCHERM SPEELSCHERM 01. LAADSCHERM CRAS FRINGILLA PORTA BLANDIT. CRAS MATTIS VENENATIS MAGNA ET EUISMOD. LOREM IPSUM DOLOR SIT AMET, CONSECTETUR ADIPISCING ELIT DURUM. LAADBALK FUNCTIONALITEITS ASPECTEN 01. LAADSCHERM Voordat de game gespeeld kan worden, moet de applied game eerst geladen worden. Daarvoor is het laadscherm. Wat het eerst opvalt is het laadicoon. Het laadicoon geeft aan dat het spel geladen wordt. Ook staat er een opmerking / tip vermeld die de speler kan helpen tijdens het spelen van de game. Deze bestaat altijd uit een korte tekst (niet meer dan twee regels). De laadbalk onder aan het scherm geeft aan hoever het laden in zijn voortgang is. Zo hebben de spelers een indicatie hoelang het laden nog duurt. INTERFACE SPEELSCHERM Versie: 2.0 Datum: 9 maart 2010 Project: Drugs in the City GAMEPLAY LAADSCHERM SPEELSCHERM 01. SPEELSCHERM 02. STATUSBALKEN ANGSTIG DUIZELIG FLAUWVALLEN ONRUSTIG PANIEK ZIEK 03. SPELERS + SCORE SPELER SPELER ANIMATIE TIJD SPELER SPELER FUNCTIONALITEITS ASPECTEN 01. SPEELSCHERM 03. SPELERS + SCORE De camera is het gebied wat de camera registreerd. Door de camera op de kabouterkaart (en handelingskaarten) te richten wordt de augmented reality (AR) zichtbaar. De spelers zijn zelf ook zichtbaar als 'kabouter'. Ze kunnen een puntmuts opzetten die op een hoofdband wordt geprojecteerd met de AR functie. De game wordt maximaal gespeeld met 4 spelers. Elke speler heeft een andere kleur puntmunts. Dit wordt met een icoontje duidelijk gemaakt. Verder heeft elke speler een individuele positieve of negatieve score. Deze wordt in dit vlak bijgehouden. Wanneer de score van een speler verandert wordt dit met een subtiele animatie weergegeven. Er zijn twee balken zichtbaar in het camera-scherm. De tijdbalk geeft aan hoevel seconden een speler heeft voordat zijn beurt voorbij is. Binnen deze tijd moet hij een kaart opgooien. Als de animatiebalk begint te lopen zien de spelers dat de camera de kaart heeft geregistreerd. Als de balk vol is, is de animatie geladen en begint de animatie van de kaart te spelen. 02. STATUSBALKEN De statusbalken geven de status van de drugskabouter aan. Deze balken worden gevuld met positieve en negatieve handelingen van de gebruiker. Wanneer er een balk egaal wordt, is het onderwerp weggespeeld. Dit resulteerd in een bepaalde score voor de gebruiker (positief of negatief). De meest volle balk qua positieve handelingen wordt bespeeld. Pagina 8

9 4.5 Modes and other features We hebben geen gamemodes in onze game ontwikkeld omdat dit geen meerwaarde zou zijn voor de spelers. De features kunnen we omschrijven als wat belangrijk zijn in onze game zoals realistische animaties. De kabouter staat nooit stil en zal bewegen als een echt persoon. Deze kleine dingen maken de game af. 4.6 Levels Kabouterkaarten bepalen het soort level. Per kabouterkaart is er een kabouter met bepaalde symptomen. Het level en dus de moeilijkheidsgraad verschilt per kaart. Zo is de kabouter van level 3 gevoeliger voor sommige handelingen dan de kabouter van level 1. De handelingen moeten dus strikter en meer overdacht worden uitgevoerd. 4.7 Tijd De tijd is een essentieel aspect waar de spelers mee te maken krijgen. Er zijn twee balken zichtbaar in het camera-scherm. De tijdbalk geeft aan hoevel seconden een speler heeft voordat zijn beurt voorbij is. Binnen deze tijd moet hij een kaart opgooien. Als de animatiebalk begint te lopen zien de spelers dat de camera de kaart heeft geregistreerd. Als de balk vol is, is de animatie geladen en begint de animatie van de kaart te spelen. Pagina 9

10 HOOFDSTUK 5: AUGMENTED REALITY 5.1 Wat is Augmented Reality (AR)? Augmented reality, of transrealiteit, is het versmelten van de echte (fysieke) en de virtuele wereld. Ook wel toegevoegde realiteit genoemd. Met deze techniek is het mogelijk om objecten te laten verschijnen in 3D die er niet zijn. Door middel van een digitale camera wordt de werkelijkheid herkend en bestaat de mogelijkheid op het beeldscherm informatie toe te voegen aan deze werkelijkheid. Deze informatie kan bestaan uit tekst en beeld, 2D en 3D. 5.2 Waarom Augmented Reality? - Het is een nieuwe technologie die geen nieuwe en zware hardware vereist - Controls en handeling zijn eenvoudig uit te voeren, de complexiteit uit zich op het scherm - 4 mensen laten samenspelen: - 4 mensen achter één computer plaatsen is niet praktisch - In het geval de kaarten echt verborgen moeten blijven (zoals bij ons het geval is), is de beste manier om het spel te spelen dus via een netwerk. (Hiervoor zou je dus al 4 computers nodig hebben). - Interactie tussen de spelers onderling is veel minder bij alleen een pure digitale game - Je speelt het spel met elkaar, niet met iemand op het internet - De visuele feedback die je krijgt, krijg je niet bij een pure analoge game - De AR biedt een extra dimensie, waardoor we een extra funfactor oproepen 5.3 FLARToolKit: AR voor Flash FLARToolKit is een open source toolkit voor augmented reality (AR) applicaties. Iedereen kan de FLARToolkit gratis gebruiken voor nietcommerciële doeleinden. FLARToolKit wordt uitgelezen met Flash en de technologie Flex. Hieronder FLARToolKit in het kort: - OpenSource - ActionScript 3 versie van ARToolKit - FLARToolKit herkend vormen aan de hand van code en oriënteerd de positie in de werkelijkheid - Eigen vormen toepasbaar door middel van code en visuals - Ondersteund door flash 3D engines (Papervision3D, Away3D, Sandy, Alternativa3D) 5.4 Speelkaarten We werken dus met symbool herkenning voor augmented reality. Deze symbolen nemen het grootste deel van de ruimte in. Verder hebben we weinig ruimte voor illustraties en ook niet genoeg tijd om deze te maken, dus zullen we vooral werken met tekst. Belangrijk voor de symboolherkenning is dat er een zo groot mogelijk contrast moet zijn en de omgeving moet egaal zijn. Daarmee bedoelen we dat er niet te veel dingen op de achtergrond moeten gebeuren. Dit omdat de computer anders meer rekentijd nodig heeft en de animatie kan gaan schokken. De vormgeving van de speelkaarten zijn daarom simplistisch vormgegeven. De kaarten zijn wit en de opdruk van het symbool en de teksten zijn zwart. Zo zijn ze goed leesbaar voor de speler en de camera. Op de kaart staat de handeling / functie vermeld om te kunnen zien waarvoor de gebruiker de kaart kan gebruiken. Pagina 10

11 5.4 Voorbeeld Hieronder staat een voorbeeldcode met het desbetreffende symbool. De codes en symbolen voor de game hebben we overigens zelf geschreven en getekend. Dit omdat we zelf de vormen wilden bepalen en om fouten in de code te voorkomen. De codes hieronder staan drie keer vernoemd. Dit hebben we gedaan omdat de FLARToolKit gebruikt maakt van RGB. Staand (niet gedraaid) RGB Staand (1x links gedraaid) RGB Staand (2x links gedraaid) RGB Staand (3x links gedraaid) RGB Pagina 11

12 Pagina 12

13 HOOFDSTUK 6: GAME CHARACTER 6.1 Character design In onze game is een slechts een character aanwezig, dat is de kabouter die onder invloed is van drugs. Deze kabouter zou geen kabouter zijn zonder puntmuts, puntschoenen en rauwe grijze baard. Hij heeft grote ogen en staat in een kromme houding naar voren gebogen. In een ietswat artistieke maar comic-stijl is deze vormgegeven. Zo heeft hij dunne armpjes, een wat vierkant breed postuur en staan zijn benen ver uit elkaar. Het character is niet een standaard lieve kabouter zoals we deze kennen uit filmpjes en prentboeken. 6.2 Karakter en gedrag Het karakter van de kabouter is afhankelijk van de statussen van de meters en de handelingen van de spelers. In de modus waarbij geen interactie plaats tussen de kabouter en de spelers zal het karakter ingetogen en rustig zijn. De kabouter kijkt wat om zicht heen en zal geen specifieke acties uitvoeren. Het gedrag is variabel doordat de spelers invloed daarop kunnen uitoefenen. Overigens zal het gedrag van de kabouter enkel en alleen tot uiting komen door een handelingskaart op te gooien. Pagina 13

14 6.3 Inspelen op de doelgroep Middelbare scholieren zijn zowel jongens als meisjes en na onderzoek bleek dat de voorkeuren voor een stijl erg verschillend liggen. De jongens gaan vooral voor stoer en realistisch terwijl de meisjes van simpel en gestileerd houden. Tim Burton lijkt echter bij beide groepen erg in trek te zijn, vanwege het analoge gevoel in zijn stijl. Daar springen wij dan ook op in, zonder een directe stijl van Burton over te nemen. Wij gebruiken het idee van het gebruiken van een analoog element in een digitale creatie. 6.4 Stijl Jongens gaan vaak voor de realistische shooters en voetbal games en meisjes zijn eerder casual gamers. Het is dan moeilijk om een middenweg te vinden tussen realistische en gestileerd en om daarbij de interesse van beide groepen te winnen. Wat beide groepen wel leuk blijkt te vinden is de stijl van Tim Burton. Maar wat maakt hem nou populair? Dat is het analoge gevoel dat hij geeft. Zijn films voelen echt als met de hand gemaakt en dat trekt de kijkers meer naar de films toe. Als wij dit analoge gevoel ook kunnen creëren, dan hebben we de hele doelgroep te pakken. Daarom hebben we gekozen om gebruik te maken van verf textures. Wat heeft het verder met drugs te maken? Misschien niet eens zo veel. Het enige is dat de stijl niet realistisch is, maar verferig en toch ook niet te gestileerd. Dus dit wijst op een verschil tussen de echte wereld en de wereld van die van een drugsgebruiker. Het heeft vooral wat toe te voegen aan de ervaring. Deze ervaring moet leuk, doch leerzaam zijn. Deze stijl is leuk, de vorm van de kabouters is grappig en de textuur geeft het een handvaardig gevoel. Het is niet te hip, dus de spelers begrijpen dat dit iets anders is dan de normale spellen die ze spelen. 6.5 Ervaring wat we willen overbrengen We willen dat de ervaring plezier oproept en dat de visuele stijl ook uitlokt tot het zoeken van interactie. De vormen zijn daarom gestileerd en toch 3D, omdat we met augmented reality werken. Bepaalde lichaam eigenschappen zijn overdreven en dat maakt de kabouter kenmerkend. Tijdens de interactie met de kabouter is het belangrijk dat de speler zich kan inleven in de kabouter, dus moet de kabouter veel karakter bevatten. 6.6 Textuur Voor de leerzame ervaring en om aan te sluiten op het augmented reality concept (waar analoog en digitaal met elkaar vermengen), combineren we analoog en digitaal ook in de stijl. Zo krijg je een combinatie tussen 3D modellen en handgemaakte textures. Deze textures worden eerst in photoshop gekleurd, getest op het model en vervolgens uitgeprint op a3. Daar wordt overheen geverfd met aquarel verf en vervolgens weer ingescand. Na wat eventuele kleuraanpassingen in Photoshop wordt het nieuwe texture dan weer op het model gezet. 6.7 Kleuren De kleuren zijn aarde gericht, dus allemaal wat minder gesatureerd. De aarde tinten zijn kalmer voor het oog en realistischer qua natuur. Omdat de textuur met sterke verfklodders wordt gemaakt, is deze al druk, daarom is het beter dat de kleuren niet zo druk zijn. Pagina 14

15 HOOFDSTUK 7: MEDIA LIJST / ASSET LIST In dit hoofdstuk behandelen we alle media en elementen die gemaakt moeten worden voor het spel. 7.1 Interface Assets - Wireframes De wireframes geven de werking en de interactie aan van het gebruikersscherm - Textures De sfeer en de grafische invulling van de interface - Speelscherm Scherm wat de camera ziet - Animatiebalk De animatiebalk geeft aan wanneer een kaart wordt herkend, en hoe lang het duurt voordat de kaart geladen is. - Tijdbalk De tijdbalk geeft aan wat hoeveel seconden een speler heeft voordat zijn beurt voorbij is - Statusbalken De statusbalken geven de status van de kabouter aan (angstig, flauwvallen, duizelig, onrustig, paniek en ziek) - Spelers + Score Het aantal spelers met eigen kleur en bijbehorende score - Laad-icoon Tijdens het laden van het spel, is er een icoon dat het proces aantoont - laadbalk De laadbalk geeft een schatting van de laadtijd voor het spel gespeeld kan worden - laad tip Tijdens het laden wordt er een tip over het spel gegeven aan de spelers 7.2 Environments - Rustige omgeving Voor het spel optimaal te spelen, moeten de spelers zorgen dat ze een rustige (witte) achtergrond hebben - Computer De computer is het medium om het spel te kunnen spelen - Camera De camera registreert de kaarten om deze uit te lezen 7.3 Characters - Sideview De sideview laat de bouw,het postuur en de houding van het character zien - Model Het model van het character is de 3D uitwerking van de sideview - Textures De sfeer en de grafische invulling van het character - Animaties Maken het spel visueel interessanter en laat handeling aan spelers zien 7.4 Speelkaarten - Kaartlayout De kaartlayout geeft aan wat op elke kaart moet staan - Vormgeving De sfeer en de grafische invulling van de kaart - Symbool Elke kaart krijgt een symbool die kan worden uitgelezen door de camera - Speelkaarten Kaarten met een grootte van 85 x 55 mm (visitekaartje); 19 handelingskaarten (acties), 1 kabouterkaart (prototype), 4 spelerskaarten (aantal spelers) Pagina 15

16 HOOFDSTUK 8: TECHNICAL SPEC 8.1 Technische analyse In de technische analyse wordt uitgelegd hoe we technisch te werk zijn gegaan Nieuwe technologie De game maakt gebruik van augmented reality. De core technologie gebruikt voor Gorro is FLARToolkit. Het principe van augmented reality is als volgt: - Er zijn patronen in de fysieke ruimte die door de techniek herkend kunnen worden - Een camera neemt de fysieke ruimte waar - Deze beelden worden geanalyseerd door de computer om de patronen terug te vinden - Op basis van de positie van het patroon in de fysieke ruimte wordt dan een 3D model in de digitale ruimte geplaatst - De computer geeft het originele gefilmde beeld terug met de 3D visuals als overlay - Aan de hand van de verschillende patronen kan er code geschreven zodat er specifiek gereageerd wordt per patroon - De patronen zijn ook zo opgesteld dat de computer ziet hoe een kaart gedraaid is en hier dan ook het model op aanpast Belangrijkste software development tasks Core gameplay zal geprogrammeerd worden in Flash. Augmented Reality zijde van het spel wordt gemaakt via Flex. Er wordt gameplay toegevoegd aan de engines van FLARToolkit en FLARManager. Uiteindelijk moeten het Flash en Flex gedeelte met elkaar verbonden worden Risico s Framerate blijkt niet optimaal te zijn. Beeld wat terug naar de gebruiker gestuurd wordt is pixelated vanwege de kleine resolutie die Flash maar kan verwerken. Het verhogen van het output beeld gaat snel ten koste van de framerate. Flash blijkt heel slordig om te gaan met RAM verbruik. Bij het continu inladen van models loopt het RAM gewoon vol Alternatieven ARToolkit of ofxfeducialfinder. Beide werken via openframeworks (C/C++). Framerate bij deze pakketten is beter en RAM verbruik valt makkelijker in de hand te houden. Het probleem van deze alternatieven is echter dat er een hele hoop aangepast moest worden om met ze te kunnen gaan ontwikkelen. 8.2 Development platform en tools Software - Flex - Flash - Notepad++ - De MonsterDebugger - FLARToolkit (Copyright (C) Saqoosha, Ryo Iizuka) - FLARManager (Eric Socolofsky) - Actionscript XML - custom created pat bestanden - Collada bestanden (.dae) - Photoshop - Maya Pagina 16

17 8.2.2 Hardware - Webcam - Beamer / beeldscherm - PC 8.3 Interface technical specs Een camera is nodig om beelden binnen te trekken zodat deze dan als input gebruikt kunnen worden. Dit alles wordt al automatisch verzorgd door het FLARToolkit pakket. 8.4 Controls technical specs Het spel wordt aangestuurd door fysieke kaarten in beeld te brengen. 8.5 Rendering systeem Het renderen wordt intern verzorgd door Papervision3D die in het FLARToolkit pakket ingesloten zit 8.6 Hoe technisch te spelen en korte troubleshooting - Zorg ervoor dat er een camera aangesloten is. Indien het beeld niet verschijnt, wordt de camera niet herkend of staat de camera in de standby stand. Het spel zal de eerste camera die hij vindt als input nemen. - Om acties te kunnen uitvoeren moet de kabouterkaart ten alle tijde in beeld liggen. - De speler die aan de beurt is mag een kaart in beeld brengen. - Indien de timer stopt bij het inlezen van de kaart, moet je de kaart eventjes opnieuw in beeld brengen. - De herkenning kan heel gevoelig zijn als er veel beweging op de achtergrond plaatsvindt. Zorg ervoor dat de achtergrond van de ruimte waarin je speelt niet teveel beweging bevat. - Zorg voor voldoende belichting. Camera s hebben de neiging om ruis te maken indien ze niet geschikt zijn te werken in een duistere omgeving. Pagina 17

18 HOOFDSTUK 9: WEEKVERSLAGEN In de weekverslagen hebben we beschreven wat we hebben gedaan, wat er goed ging en wat er eventueel fout ging. 9.1 Week 01 - Gebrainstormd over concept - Enkele zaken vastgepind - Basis voor concept bedacht - Enquêtevragen opgesteld voor middelbare studenten - Eerste onderzoek gedaan - langsgegaan bij BNN met betrekking tot Spuiten en Slikken - op internet op jacht gegaan naar gegevens - Eerste moodboards gemaakt Wat te doen volgende week? - Langsgaan bij Jellinek - Concept afwerken 9.2 Week 02 - Basis vorig concept aan de kant geschoven - Verder gebrainstormd over concept - Nieuw concept uitgekozen - Onderzoek - Langsgegaan bij Jellinek - Middelbare scholen langsgegaan om enquêtes af te nemen - Enquête op internet geplaatst en kennissen gecontacteerd - Enkele onderzoeksresultaten verwerkt - Concepten afgewogen tegenover elkaar en knoop doorgehakt welk idee we gaan uitwerken Wat te doen volgende week? - Concept compleet verfijnen - Eerste prototypes maken / testen - Onderzoek trachten af te ronden - Stijlideeën bedenken Wat is er misgegaan? - Middelbare scholen wilden allemaal niet meewerken aan enquête. - Concept van vorige week leek leuk voor de gameplay, maar de boodschap werd negatief. Concept bedacht vanuit de boodschap. - Iedereen merkte dat we niet echt veel vorderingen maakten. Een gesprek heeft ervoor gezorgd dat we doelgerichter aan de slag gingen. 9.3 Week 03 - Planning opgesteld - Gebrainstormd over 2 nieuwe concepten - Functionaliteit Smartboard getest - Onderzoek + enkele onderzoeksresultaten verwerkt Pagina 18

19 Wat te doen volgende week? - Concepten nogmaals bekijken of gameplay voldoende duidelijk is - Als één van de drie concepten gekozen is, dit concept verder uitwerken - Eerste prototypes maken / testen - Visuele representaties van 3 concepten maken - Concept art maken Wat is er misgegaan? - Concept compleet verfijnen lukte niet echt omdat we uiteindelijk 3 verschillende concepten moesten hebben. Het team wilde het concept niet te diep uitwerken als er de kans bestaat dat er concepten wegvallen. - Nog geen prototypes gemaakt omdat we 3 verschillende concepten moesten hebben. - Op planning stond om een techniek te kiezen, maar hangt dus af van welk concept gebruikt wordt. 9.4 Week 04-2 nieuwe concepten bijbedacht - Paper prototype van het gekozen concept gemaakt - Playtests uitgevoerd - Gameplay aangepast indien nodig bleek uit playtests - Visuele stijl bepaald Wat te doen volgende week? - (indien mogelijk) Content voor uiteindelijk prototype beginnen produceren - Officieel design document beginnen invullen - Digitaal prototype maken - Playtesten - Concept art maken 9.5 Week 05 - Op zoek gegaan naar mogelijkheden om augmented reality te verkrijgen - Fiducial Finder voor openframeworks op Mac proberen aan de praat krijgen - ARToolkit voor openframeworks op PC proberen aan de praat krijgen - FLARToolkit klaarmaken voor programmeren gameplay - Moddellen kabouter - UV unwrappen kabouter - Kabouter ontwerp gemaakt - Orthogonale projecties van kabouter gemaakt - Ontwerp van speelkaarten - Visueel design doc aangevuld Wat te doen volgende week? - Productie game starten - Bijspringen waar nodig - Playtesten of er iets geleerd wordt van het spel - Animeren kabouter indien mogelijk - FLARToolkit multi patroon herkenning werkende krijgen met custom models - Officieel design document invullen - Programmeren gameplay - Interface ontwerpen - Textures kabouter maken Pagina 19

20 Wat is er misgegaan? - Bart Jan is ziek geworden en was eventjes uitgeschakeld tot en met dinsdag. - Zowel Fiducial Finder als ARToolkit waren een hel om werkende te krijgen. De uitvoerbare bestanden werkten, maar eens er geprobeerd werd om zelf aan de slag te gaan, moesten er een hele hoop dingen aangepast en bijgesteld worden. Na 2 dagen intensief het toch proberen werkende te krijgen, is de beslissing genomen om te kijken of FLARToolkit (ARToolkit voor AS 3.0) niet gewoon werkte. Gelukkig kon er wel makkelijker met dit pakket gewerkt worden. Verwerking beeld data is iets trager, maar voldoende voor prototype. - Er is nog een klein probleem in verband met het weergeven van de custom models bij multi patroon herkenning, maar moet volgende week opgelost worden. 9.6 Week 06 - Geplaytest om te kijken of mensen iets opsteken van de game - De groepsnaam en gamenaam gekozen Groepsnaam: Flapdoodle; Gamenaam: Gorro - Interface ontworpen - Wireframes interface gemaakt - Custom patronen gemaakt voor op de kaarten - Officieel design document deels ingevuld - Multipatroon herkenning met custom models werkende gekregen - Gezocht naar een oplossing voor het RAM-verbruik probleem (zie Wat is er misgegaan? ) - Manier gevonden om een SWF mooi te integreren en hierdoor dus gebruik te kunnen maken van de ingesloten visuals - Kabouter geunwraped - Gameplay programmeren - Tweaks aan kabouter gemaakt: ogen vergroot; oogballen rond gemaakt voor animeren; UV map aangepast voor nieuwe ogen - Eerste texture kabouter gemaakt Wat te doen volgende week? - Bewust blijven van wat er nog allemaal gedaan moet worden! - De nodige documenten eens onder de loep nemen - Wat meer optimaliseren van de technische kant van de Augmented Reality - Officieel design document verder invullen - Rigging kabouter - Verder programmeren gameplay - Animatie kabouter - Kijken wat de beste oplossing is voor onze speelkaarten en deze kaarten dan maken - Final texture kabouter maken - Animatie kabouter Wat is er misgegaan? - In feite is het volgende niet iets wat mis is gegaan, maar meer een tegenvaller. Het blijkt dat Flash heel slordig omgaat met het terug vrijmaken van geheugen. Dit komt voort uit de dagen dat men ervan uitging dat niemand echt heel lang bezig zou zijn binnen een Flash omgeving. Door de komst van Flex en de RIA s is dit echter veranderd. Veel mensen lopen tegen het probleem aan dat een Flex programma het geheugen volop gaat bezetten. In onze game komt dit sterk naar voren als er ongeveer 10 kabouters tegelijk op het scherm weergegeven moeten worden. Het RAMverbruik stijgt enorm en op het ogenblik dat de kabouters niet meer weergegeven worden en dus verwijdert zouden moeten worden uit het geheugen, blijft het verbruik hoog. Het is zelfs zo dat als er hierna nieuwe kabouters weergegeven worden, het verbruik nog meer stijgt omdat de vorige kabouter plaatsen in het geheugen dus niet vrijgegeven worden! Er wordt naar een oplossing gezocht, maar gelukkig kan er wel een workaround gemaakt worden indien het probleem niet opgelost raakt. Pagina 20