Realisatie | agd-portfolio

THINK 1

Eerst hadden we als input voor de core mechanic dat de speler op het scherm moest tikken om een explosie te creëren, wat daarna weer de blob door de level bewoog. Als test wouden we alle soorten van input testen en hier de beste uit selecteren. Ik kreeg als opdracht de swipe input te schrijven en was eerst erg sceptisch over swipen als een inputmethode voor onze game, maar uiteindelijk werd deze als beste uitgekozen binnen ons groepje. De enige bronnen die ik dacht te gebruiken voor deze cycle zijn eigenlijk alleen de uitleg over wat er allemaal binnen de Unity API mogelijk is.

Gebruikersinteractie: Realisatie

MAKE 1

-Eerst moest ik er achter komen wanneer de speler het scherm aanraakte, dit deed ik d.m.v. te kijken wanneer de waarde van Input.touchCount hoger is dan 0.
-Ik kwam er achter dat binnen de Unity API er een Enumeration is genaamd TouchPhase, waarmee ik ik ook kon checken of wanneer een swipe begon, geannuleerd werd en eindigde. Dit gebruikte ik om onderscheid te maken tussen wat een echte swipe is.
-Vervolgens wordt er een Force uitgeoefend op de Rigidbody van de speler met een Vector die berekend werd met de begin -en eindpunt van de swipe.

CHECK 1

Uit analyse op playtests en ingevulde formulieren van 1 van mijn projectpartners, blijkt dat de swipe toch nog de leukste inputmethode is. Dit gaat dus tegen mijn verwachtingen in. Alleen kan het altijd nog verbetering gebruiken. Daarom hebben we besloten om elke sprint weer terug te komen op het verbeteren/polishen van de core mechanic. Ik heb trouwens niet meer bronnen nodig gehad om deze cycle te kunnen realiseren.

THINK 2

Tijdens het playtesten naar de verschillende inputmethoden was het duidelijk dat speler niet direct door hadden dat ze konden swipen en als ze dat wel door hadden wisten ze niet dat de lengte van hun swipe verschil uitmaakte. Mijn doel is dan ook om er voor te zorgen dat er een lichte spoor wordt achter gelaten op het scherm die de speler zijn/haar swipe volgt, zodat het hiervoor genoemde probleem kan worden verholpen. Ik denk dat er in misschien in de Unity API binnen de touchscreen gedeelte ook wel een functie hiervoor zou kunnen zijn en zo niet dan zal ik het proberen met de Particle System.

MAKE 2

Toen ik mijn zoektocht begon naar de iets binnen de Unity API, kwam ik eigenlijk al gelijk al op tips van mensen op forums om het beter via de Unity TrailRenderer te doen, dan uit code dingen te proberen tekenen.

https://docs.unity3d.com/Manual/class-TrailRenderer.html

De instructies waren super makkelijk te volgen vanaf de originele Unity Manual pagina.

CHECK 2

Het resultaat wat ik heb behaald is beter dan ik het verwachtte. Ik dacht dat ik een tijdelijke “placeholder” versie zou maken dat er nog visueel niet al te best uitziet maar wel functioneerde, alleen deze versie ziet er ook gelijk super fijn uit en valt redelijk weinig aan te verbeteren (Natuurlijk kan je altijd wel wat verbeteren, maar in dit geval hoeft daar prioriteit op te worden gesteld). De enige problemen die ik had waren met dat de Trail niet op de juiste positie werd getekend, maar dit had ik al snel weten te fixen door Camera.main.ScreenToWorldPoint en de Z-as waar de Trail werd getekend op een negatieve waarde te zetten, zodat het bovenop de level werd getekend, maar niet achter de camera zelf.

CONTEXT 3

Het doel wat ik wil behalen in deze cycle is dat de core mechanic beter aanvoelt. Op het gebied van Tactile Polish en Visual Polish. De speler moet een indruk krijgen dat het poppetje werkelijk een blob is en beweegt als een blob dat zou doen. Er moet wat meer leven in.

LEARNINGS 2

Ik heb vooral in deze cycle geleerd dat er überhaupt zoiets bestaat als een TrailRenderer en kan dit voortaan gelijk gebruiken als ik feedback nodig heb voor een bepaalde beweging zoals een swipe, of als ik een verdwijnend spoor zou willen achterlaten bij de speler. Van het Re-Factor’de code heb ik geleerd dat mijn script nog veel te “hardcoded” was en dat ik beter i.p.v. zorgen te maken waar het object zich bevind in de scene, gewoon de sorting layer waarop het getekend word kon veranderen.

CONTEXT 1

Om mijn beroepstaak Gebruikersinteractie: Realiseren te bewijzen heb ik er voor gekozen om in mijn eerste cycle de core mechanic van onze game te verbeteren. Op het gebied van Motion Polish.

Al mijn cycles zullen dezelfde bron gebruiken voor het definiëren van de type Polish dat ik toepas. De bron hiervoor is hetzelfde boek als bij mijn beroepstaak Gebruikers Interactie Analyse, namelijk Game Feel: A Game Designer's Guide to Virtual Sensation van Steve Swink.

Een korte versie van deze types is hier te vinden bij dit Gamasutra Artikel:
http://www.gamasutra.com/view/feature/130734/game_feel_the_secret_ingredient.php?page=4

LEARNINGS 1

Ik heb deze cycle vooral geleerd om geen vooroordelen te hebben over bepaalde methoden van input alleen omdat ik het op het eerste gezicht niet vind passen bij de game.

CONTEXT 2

Het doel wat ik wil behalen in deze Cycle is op het gebied van Visual Polish. Tijdens het Swipen zal er dus een visuele spoor zichtbaar zijn om de speler te laten zien wat zijn/haar swipe was.

Nadat ik een GameObject had gemaakt met een licht witte Material, moest ik het alleen nog koppelen aan de swipe van de speler.

Dit deed ik dus met de bovenstaande code, waar ik steeds het object een nieuwe positie meegaf als er op de touchscreen gedrukt werd.

Bij de “Code-Refactoring van alle scripts in het project” (door Almar) is de script alleen wel veranderd en opgeschoont, maar de werking is praktisch hetzelfde.

Hierboven is dan ook de swipe te zien met een richting naar Linksboven, rechtsonder begint de swipe ook te verkleinen en vervagen zoals ik in de TrailRenderer heb ingesteld.

MAKE 3

Het eerste wat ik heb gedaan, is hulp op youtube zoeken of deze eigenschappen ook met shaders te waren realiseren. Het resultaat waar ik op kwam is, dat het wel met shaders te doen is, maar het verandert dan de eigenschappen van Bob niet. Bob zou dan alleen maar blob-achtig lijken, maar niet zo functioneren (indeuken/stuiteren/plakken).

Vervolgens heb ik de Unity Asset Store afgezocht naar assets die zouden kunnen werken en vond de volgende 2.
1. https://www.assetstore.unity3d.com/en/#!/content/13327
2. https://www.assetstore.unity3d.com/en/#!/content/68777

We zijn uiteindelijk voor de goedkoopste gegaan (2D Soft Body), om te kijken of die voldoende was en we niet ons budget onnodig hoefde te besteden aan iets duurder als het goedkope ook werkt.

Het implementeren van de asset was redelijk gemakkelijk, maar het bracht wel wat problemen met zich mee.

-De kracht die op de force werd uitgeoefend door de swipe werkte heel anders omdat de zachte eigenschappen van de blob nu de kracht beter kon incasseren. (Dit kwam omdat de Rigidbody van Bob nu was opgesplits in 4 kleinere Rigidbodies, die elk de kracht opvangde en op elkaar weer uitoefende in de verkeerde richting vanwegen de Joints waarmee ze aan elkaar vast zaten).
-Bob kon nu vastzitten in muren vanwege de meerdere colliders waar hij uit bestond, i.p.v. 1 cirkel collider.
- Bob zijn vervorming kon helemaal kapot gaan, als er teveel kracht op hem werd uitgeoefend door de swipe. Dus er moest heel wat gebalanceerd worden met krachten en massa’s.

Ik had voorlopig deze problemen maar gelaten voor wat ze zijn, omdat na mijn pogingen om de scripten aan te passen die we met de asset kregen, er weinig veranderde en een limiet geven aan hoe hard Bob mag bewegen vonden we ook niet goed in ons spel passen dus die oplossing werd ook verwaarloost. Later wisten mijn projectpartners deze problemen te fixen.

THINK 3

We hebben eerst om Bob te representeren gebruik gemaakt van een ronde Blauwe bal. Deze bal had wel stuiterende eigenschappen, maar voelde niet echt als een blob aan. Bovendien leek het ook daadwerkelijk alleen maar op een bal, en zat er weinig karakter in. Deze problemen hoop ik te verhelpen in deze cycle. Ik denk dat de bronnen die ik zal gebruiken of alleen assets zijn van de Unity Asset Store of misschien videos over shaders.

CHECK 3

Mijn doelen zijn behaald! Bob voelt nu ook werkelijk als een blob met een persoonlijkheid. De playtesters verwijzen nu ook naar de blob als “hij” en niet meer “de bal”. We hebben zelfs testers gehad die gingen zwaaien naar het scherm omdat de blob ging knipperen. Hieruit vind ik wel blijken dat de persoonlijkheid nu al redelijk in Bob zit. De blob eigenschappen zullen we alleen nog wel in verdere cycles aan sleutelen hebben we besloten, om de perfecte “feel” te vinden.

LEARNINGS 3

Ik kon op zich wel al om met programma’s zoals Photoshop, dus het gene waar ik het meeste heb geleerd deze cycle is de asset die we hebben gebruikt voor de blob effect. Ik had namelijk niet verwacht dat het zoveel problemen met zich zou meenemen en wist ze dus ook niet zonder de hulp van mijn projectpartners op te lossen.

LEARNINGS 4

Ik heb deze cycle met behulp van Michel geleerd hoe ik mijn AudioController die ik voor velen projecten gebruikte, kon optimaliseren waardoor het nu veel efficiënter en handiger werkt. Bovendien heb ik geleerd dat binnen de thema blijven met de geluiden heel belangrijk is, aangezien ik eerst een soort sci-fi achtige geluid had voor het pauzeren van het spel, maar later dit naar een “andere” poppende bel geluid heb veranderd omdat dit beter bij de stijl van ons spel past. Bovendien heb ik met behulp van mijn projectengenoten hun feedback geleerd dat geluid echt een gigantisch verschil maakt voor de gameplay.

CHECK 4

Mijn doel is in ieder geval behaald, want we hebben in ons spel de meest essentiële sfx tot nu toe. Het voegt ook super veel toe qua feedback aan de spelers en zelfs aan ons tijdens het testen. Het was wel even realiseren dat mijn ouder AudioController script zijn slechte punten had en daarom ben ik tevreden dat ik met hulp dit ook heb kunnen verbeteren. Het resultaat is daarom ook veel beter dan ik had kunnen verwachten. De bronnen die ik heb gebruikt waren ook precies degene die ik opnoemde in mijn think en ik heb geen andere bronnen hoeven raadplegen.

MAKE 4

Als eerst hebben een gameobject nodig met een script die een referentie heeft naar alle geluiden en vanuit alle andere scripts aangeroepen kan worden. Ik had dit al wel vaker gedaan, dus heb ik weer mijn vertrouwde oude aanpak genomen.

THINK 4

De benodigde bronnen voor deze cycle zijn eigenlijk de locaties waar ik de audiobestanden weet te halen.

Ik heb zelf al een groot voorraad aan gekochte SFX op m’n pc, waar ik tussen zal kijken.
De geluiden die ik niet heb zal ik dan waarschijnlijk via een gratis game audio website downloaden. Bijv.
http://www.freesound.org/browse/
http://opengameart.org/art-search-advanced?keys=&field_art_type_tid%5B%5D=13
Als ik desnoods nog steeds geen geschikte audio kan vinden zal ik deze zelf maken.

Ik heb zelf al veel vaker de leiding gehad over geluid en muziek in mijn vorige projecten en heb ook veel kennis over de Unity Audio Mixer en muziekcompositie. Dus verwacht ik geen problemen.

Het doel dat ik wil behalen deze cycle is dat ten minste de gameplay elementen geluid hebben, zodat de feedback aan de spelers niet alleen maar visueel is.

CONTEXT 4

Het doel wat ik wil behalen in deze Cycle is op het gebied van Sound Polish. Ons spel heeft geluiden nodig en ik wil daar de beste SFX bij vinden en op de meest efficiënte manier aanroepen.

LEARNINGS 5

Ik heb in deze cycle vooral geleerd dat het moeilijk is om consistent goeie afbeeldingen te maken. Omdat mijn App Icon heel erg goed werd gevonden en er niet over gezeurd werd, had ik verwacht dat alles wat ik maak mijn projectpartners wel tevreden zou maken. Dit zorgde er waarschijnlijk voor dat ik niet meer kritisch genoeg was over mijn eigen creaties en zo niet door had dat ik een slechte design heb gemaakt qua afbeelding. Een volgende keer zou ik bij mijn checks feedback vragen aan mensen die meer verstand hebben van media design of art, zoals m’n vrienden van de CMD afdeling op het HvA of misschien zelfs m’n vrienden die Game Art studeren op het HKU. Aangezien zij ook de do’s and don’ts weten van visuele compositie.

CHECK 5

Ik heb mijn doel behaald met weinig problemen. Alle afbeeldingen werden geaccepteerd door de Google Playstore en onze app stond gelijk online. Mijn projectpartners waren tevreden met alle afbeeldingen behalve de aller laatste Achievement afbeelding met de cactus. Ze vonden dat alles in het plaatje onlogisch was. Ons spel heeft niets met een cactus te maken, er zijn geen wormen in ons spel en ook nergens stenen. Bovendien vonden ze het teleurstellend vergeleken met de rest van de tekeningen, vooral omdat dit de moeilijkste te behalen Achievement tot nu toe is, vonden ze het niet echt belonend voor de speler.

MAKE 5

Voor de App icon begon ik eerst met een template die er voor zorgde dat het pictogram op verschillende formaten werd aangemaakt zodra het hoofdplaatje tekende.

THINK 5

Om onze app in de Google Playstore te plaatsen hebben we een aantal tekeningen of afbeeldingen nodig, waarvan een aantal verplicht zijn en een aantal alleen nodig zijn voor onze features.

De zeker benodigde afbeeldingen zijn: ·
- Een App Icon, zodat onze app een afbeelding heeft op de store.
- Een Store Header, zodat boven op de App pagina van ons spel ook een soort banner is die de leegte vult. (Dit is trouwens verplicht om het spel te mogen publiceren.)

De niet per se benodigde afbeeldingen zijn: ·
- 5 Afbeeldingen voor de Achievements binnen onze game.

Ik denk dat ik met de sprites die we nu hebben voor onze game, wel voldoende bronnen heb om mijzelf uit te leven binnen Adobe Photoshop.

Mijn doel is om al deze afbeeldingen in een zelfde soort stijl te creëren zodat ze een duidelijk beeld geven van ons spel en dat mijn projectpartners er tevreden mee zijn.

CONTEXT 5

Het doel wat ik wil behalen in deze Cycle is op het gebied van Visual Polish. Onze game heeft een aantal tekeningen nodig voor de Google Playstore.

Nu ik het lichaam had wou ik Bob wat persoonlijkheid geven, dit deed ik door ogen voor hem te tekenen.

Dit was de eerste soort oog dat ik had gemaakt, maar achteraf vond ik ‘m veel te direct en het leek alsof Bob een staarwedstrijd met de speler probeerde te houden. (grijs achtergrond is om het hier zichtbaar te maken waar de randen zijn)

Uiteindelijk was dit mijn verbeterde oog sprite geworden. De reflecties zorgde voor een veel zachtere blik en de randen geven een soort van diepte effect.

Om dan uiteindelijk nog te voorkomen dat Bob uitgedroogde ogen krijgt, heb ik een Animatie aan de ogen gegeven waarbij ik dus een dichte oog sprite heb gemaakt. Ik had natuurlijk ook vanuit een script dit kunnen doen zodat Bob op compleet random intervallen knippert, maar voor nu was dit voldoende en viel het de spelers en mijn projectpartners niet eens op dat de animatie een vaste cycle is.

Eerst begon ik met de Unity Audio Mixer aan te maken, met 3 verschillende hoofdmixers BackgroundMixer voor de achtergrond geluiden en muziek, de SoundEffectsMixer voor de alle geluidseffecten en nog een UserInterfaceMixer voor alle menu geluiden. Al deze mixers hebben weer allen een aantal mixergroepen die achteraf kunnen worden afgesteld tegenover elkaar en gebruik kunnen maken van effecten en alle andere functies van de Unity Audio Mixer.

Vervolgens mijn AudioController script die wordt meegegeven aan de AudioManager Prefab, die allemaal Audio Sources heeft per geluidje. Elk van deze AudioSources hebben een output naar de bijbehorende AudioMixerGroup.
-Boven het script declareer ik eerst AudioSources voor elke geluid met daarboven een summary per AudioSource. (Dit zorgt er voor dat als later ergens in een ander script het geluid aangeroepen moet worden, er in de syntax-list ook een beschrijving verschijnt welke geluid het is.)
-Daarna haalt het script eerst alle AudioSources op en stopt ze in een array.
-Met de static methodes PlaySong en StopSong kan je overal in het project vanaf elke script de gewenste geluiden en muziek oproepen en stoppen. (Bovendien kan je de Pitch en Volume van de AudioSource dan ook bij het aanroepen veranderen, omdat de AudioSources zelf ook static zijn.)

Uiteindelijk heb ik samen met iemand uit m’n groepje (Michel) de script hebben moeten opknappen om ervoor te zorgen dat de instellingen van de spelers worden opgeslagen over de Muziek en SFX volumes.

De AudioController ziet er hierdoor compleet anders uit.
-Het werkt nu niet meer met een Prefab die allemaal AudioSources heeft, maar ééntje die allemaal referenties naar Prefabs heeft, die dan weer allemaal hun eigen AudioSource hebben geleid naar de juiste AudioMixerGroup in de Output.
-De Audiomixer is dus nog wel hetzelfde gebleven.
-Zodra er een geluid wordt opgeroepen, wordt er de juiste Prefab geïnstantieerd op de juiste locatie in de scene en wordt weer verwijderd wanneer deze klaar is met spelen.

Nu we dan de Audio Controller hebben, komen we aan bij de geluiden zelf. De belangrijkste geluiden voor de gameplay zelf zijn dan ook de volgende.

1. “Splat”, dit is het geluid wat gepitched wordt afgespeeld elke keer als Bob de grond aanraakt en dus slijm achterlaat. Hiervoor heb ik een modder achtige squishy geluid uitgekozen, omdat dit het beste de impact van een slijmerig object kon nabootsen.

2. “Switch”, dit is het geluid wanneer de speler een knop heeft ingedrukt in het spel om een deur te openen. Hiervoor heb ik het geluid gebruikt van een daadwerkelijke schakelaar, zodat het een voldoende feedback zou geven dat de knop ook werkelijk is ingedrukt.

3. “Timed Button”, is een soort van wekker of timer achtige snelle tikgeluid. Dit zorgt ervoor dat de speler opgefokt raakt en snel naar de deur gaat voordat deze dicht gaat. Het geluid wordt ook gestopt wanneer de deur zich sluit.

4. “KeyPickup”, is een soort geluid van een klein metalen voorwerp dat tegen een ander metalen voorwerp aankomt. Het geluid klinkt ook als een sleutelbos, wanneer iemand deze oppakt en daarom vond ik het ideaal voor het oppakken van een sleutel.

5. “Woosh”, is het geluid dat je zeer zacht en gepitched hoort als je swipe succesvol is uitgevoerd om Bob voort te bewegen. Dit geeft ook feedback dat je swipe dus geldig was en onderscheidt zich zo van swipes die mislukt zijn omdat de speler misschien met meerdere vingers op het scherm zat. De pitch zorgt ervoor dat het geluid elke keer weer net iets anders klinkt en zo niet vervelend wordt om aan te horen. Een idee is misschien nog wel om de lengte van de swipe een factor te maken voor hoe laag of hoog het geluid gepitched zal worden, maar dit is nog niet mogelijk binnen onze AudioController.

6. “Finished Sparkles”, is het geluid wat klinkt als magische triangles die zeer licht worden aangeslagen. Dit geluid speelt zich af wanneer de speler het level gehaald heeft en is dus een soort van opluchtende geluid. Dat is dan ook de reden waarom ik voor zo’n lichte, luchtige en magische geluid heb gekozen.

7. “EarnedFriend”, is een generiek “Poppende Bel” geluid. Dit geluid krijg je wanneer je een van je friendly blobs hebt bevrijdt. De friendly blobs lijken nog zeer dood of versteend wanneer je ze in het level ziet en wanneer je er dus tegenaan loopt, hoor je een poppende bel en verschijnen ze levend achter je.

8. “Door”, is een “Tick” geluid op hol/licht hout. Dit geluid komt samen met de animatie waarmee de deuren open gaan. Omdat wij een animatie hebben waarbij de deuren 1 voor 1 elkaar aansteken met open gaan, komt dit geluid ook meerder malen achter elkaar voor de hoeveelheid deurblokken die open gaan.

9. “Yeah”, is het geluid dat de Friendly Blob maken zodra ze achter je aan zweven en je heel hard voortbeweegt. Het geluid is pitched om zo de verschillende blobs verschillende stemmen te geven, maar het klinkt als een soort van “Wheee”, “Yeah” of “Yaaayy” om een soort achtbaan reactie te geven aan de Blobs die met je worden meegetrokken door het gehele level heen. Bovendien heb ik de hoeveelheid aangepast van hoe vaak dit geluid wordt opgeroepen, omdat het anders zeer irriterend op de speler kan werken. (Dit werkt met een random waardes die booleans uit en aan zetten met zeer weinig kans.)

-Omdat de hoofdpersoon bij ons spel Bob de blob is, staat hij groot vooraan.
-Achter Bob zweven in een slangenpatroon 3 vrienden, de hoeveelheid die hij elk level kan behalen.
-De zon staat ook rechtsboven in beeld, omdat het een belangrijke factor is binnen de premise van onze game.
-Een zilveren overlopende rand vond ik wel authentieke gevoel geven aan onze app, als je het tussen alle andere games op de PlayStore ziet staan. Het geeft een vorm van kwaliteit aan. De rand is alleen weer niet goud, omdat ik dit persoonlijk niet bij de kleuren binnen de icon vond passen.

Daarna komt de “Header” voor de storepagina, ook wel de functieafbeelding genoemd.
De exacte afmetingen moesten 1024 bij 500 pixels zijn.

Bij deze afbeelding probeerde ik een vorm van symmetrie uit. Iets wat ik eigenlijk ook bij de App Icon wou, maar omdat die vierkant moest zijn, paste het niet helemaal. Bij deze functieafbeelding daarentegen lukte dat wel. In de spotlight heb ik dan onze hoofdpersoon weer, links en rechts een even aantal friendly blobs en dan boven gecentreerd om de leegte in de lucht te vullen de titel van het spel. De lettertype hiervan is een soort van rondachtig en vervormd, net als de eigenschappen van Bob de blob. De kleur heb ik wel wit gemaakt, omdat de lucht al blauw was en nog eens blauw er niet goed erop viel. Bovendien heeft het de kleur van wolken wat wel past in de lucht. (Dit is dan ook de reden dat ik liever geen andere kleur wou gebruiken in de lucht.)

Als laatste komen de Achievement icons. We hadden tot nu toe 5 Achievements die te behalen waren. Deze heb ik allemaal in dezelfde Photoshop project gemaakt, alleen allemaal op een andere laag, zodat ik zeker wist dat ze allemaal dezelfde afmetingen hadden en snel tussen te afbeeldingen kon verwisselen om ze te vergelijken.

1. “Oh, K swipes”

Dit is de Achievement die te behalen was als je 1000 keer geswiped hebt, daarom heb ik ook het getal 1000 diagonaal neergezet, met een vinger erbij die aan het swipen is in dezelfde diagonale richting.

2. “One for all, all for one”

Dit is de Achievement die je krijgt als je voor het eerst alle 3 de friendly blobs hebt bevrijdt in een level. Hiervoor heb ik de 3 friendly blobs voorin weergeven met een vermoeide maar gerustgestelde Bob achter ze.

3. “Tutorial Master”

Dit is een Achievement die je krijgt als je alle tutorial missies hebt uitgespeeld. Omdat de tutorial levels ook maar 5 waren, heb ik Bob afgebeeld met 5 opgehangen medailles achter hem die tentoon staan.

4. “Levelpack 1 Master”

Dit is de Achievement die je krijgt als je alle levels van de eerste Levelpack hebt uitgespeeld. Ik wou het bij dit plaatje simpel houden, daarom heb ik ook enkel een getal 1 gebruikt met wat grijs getinte wolken er achter voor een diepte effect.

5. “No one left behind”

Dit is de Achievement die je krijgt als je ALLE friendly blobs in het eerste Levelpack hebt bevrijd. Dit was het eerste moment waarbij ik moeite had met het plaatje. Ik wou leegte uitbeelden, om te laten zien dat er niemand meer was overgebleven. Alleen had ik geen stofwolk of een leeg woestijn achtige afbeelding te creëren. Dus heb ik besloten om een Cactus af te beelden voor het woestijn gevoel en een worm die weg gaat van een steen om eenzaamheid te tonen.

CONTEXT 6

We hadden meer visuele feedback nodig voor als er op een knop was ingedrukt. Dit bleek uit de playtests die we hadden gedaan aan het einde van onze 4de sprint, omdat de spelers geen verschil zagen tussen normale knoppen en knoppen met een timer. Je kon wel al geluid horen tikken, maar in een omgeving waar het luid was of als je het geluid als speler uit hebt staan, kreeg je deze feedback niet mee.

THINK 6

Om te beginnen willen we dus ervoor zorgen dat de spelers visueel feedback krijgen dat de timer knop die ingedrukt is, anders is dan een normale knop. Dit is dan ook het resultaat wat ik wil behalen met deze cycle.

Het eerste idee van mijn groep was om een compleet nieuwe knop te maken voor de timer knop, dus dat we een ander plaatje zouden gebruiken of een nieuwe plaatje zelf tekenen. Ik was hier alleen al gelijk tegen, omdat het verwarring bij de speler kan veroorzaken alsof de ene geen knop is en anders geactiveerd dient te worden, wat dus niet het geval is.

Bovendien heb ik bij Control Conference 2016 een talk van Mikkel Svendsen (Visual Effects Artist bij Playdead (Makers van Limbo en Inside) ) bijgewoond en heb hier veel tips gekregen over dat je je visuele feedback altijd 90% moet verminderen. In andere woorden het moet super subtiel zijn en nooit de spelers afleiden. Daarom wil ik ook dat de feedback die wij met de knop willen geven duidelijk is, maar niet de speler afleid.

MAKE 6

Om te beginnen wou ik gebruik maken van de particle system van Unity om bij het indrukken een korte feedback te geven dat de knop is ingedrukt.

Ik heb dus eerst een effect gemaakt dat ervoor zorgt dat er in een pulse een aantal particles worden losgelaten, ze een kleur meekrijgen, langzaam hun kleur verliezen, langzaam doorzichtig worden en vervolgens helemaal te verdwijnen.

Na een methode (ParticleBurst) te hebben aangemaakt die de particle systeem eenmalig activeerd elke keer als de knop weer wordt geactiveerd (in onze code staat Deactivate bij de regel waar de ParticleBurst wordt aangeroepen, omdat technisch gezien de knop niet meer indrukbaar is) functioneerde alles zoals het hoort.

Vervolgens was het dus tijd om onderscheid te maken tussen een normale knop en een timer knop, in ieder geval moest ik iets met de particles doen zodat ze er anders uitzagen.

Mijn oplossing hiervoor was simpel. Ik had de icon van de gesloten timer deuren gepakt en die meegegeven aan de particle system.
Als extraatje heb ik ook de particle langzaam laten roteren waardoor het lijkt alsof het een klok is die tikt.

Hier hield ik op. Aangezien ik deze feedback subtiel genoeg vond. Een andere optie kon zijn dat de speler een klok of getal op zijn/haar UI kreeg, maar ik vond dat dus al veel te afleidend. Het zou de speler teveel afleiden van zijn omgeving en de speler zou alleen maar naar de klok of getal kijken en hierdoor makkelijker kleine fouten maken en af kunnen gaan.

CHECK 6

Ik heb een clean playtest gedaan zonder geluid, met vrienden die het spel nog nooit eerder hebben gespeeld of gezien. Dit leek mij de perfecte manier om te testen of de feedback wel goed overkomt. Vooral met level 4 werd het al duidelijk voor ze dat de icon van de particles die van de knop afkomen dezelfde zijn als die op de deuren staan. Ze begonnen ook al daarna gelijk een verschil te zien tussen de particles van normale en de timer knoppen. De conclusie die ik hieruit kan trekken is dat ik mijn doel dus heb behaald en zonder enige problemen. Behalve misschien dat ik af en toe de Unity API moest raadplegen voor wat ook alweer elke eigenschap van de Particle System deed, omdat deze bij elke versie weer heel erg wordt veranderd. https://docs.unity3d.com/Manual/class-ParticleSystem.html

LEARNINGS 6

Wat ik vooral heb geleerd deze cycle is, dat het eigenlijk best leuk is om met de Unity Particle system rond te spelen en zolang de shaders voor de material van je particle maar op de MobileShaders staan, er echt zowat geen prestatie verloren gaat. Ik dacht altijd dat particles de frames per second van je mobiele game best wel snel omlaag zouden brengen, maar blijkbaar als je er subtiel mee om gaat hoeft dat niet altijd waar te zijn. Bovendien vind ik het wel mooi dat ik de principes die ik had meegekregen van een talk op Control Conference zelf wist te implementeren in dus het huidige project. Dit geeft me wel een vorm van zelfvertrouwen dat wat de professionals doen, niet onmogelijk is voor mij om het ook te doen.