6.2.1
Användandet av Unity
Ett av de tidigaste valen gruppen hade var valet av spelmotor. Gruppen visste att en spel- motor skulle behövas för att färdigställa kundens produkt och då stod valet mellan Unity eller Unreal Engine. Unity valdes som grund för simuleringen för att arbetsstationerna som kunden bidrog med hade Unity samt att en gruppmedlem hade erfarenhet av Unity.
När Unity valdes som grafikmotor så uteblev alla andra alternativ eftersom det är myc- ket omständligt att byta spelmotor för att man då behöver skriva om mycket kod. Även om det är omständligt att byta spelmotor så ska det inte vara någon omöjlighet att byta till Unreal Engine [21]. Detta för att det finns flera likheter i uppbyggnaden och det medför att ett byte är möjligt. Att gå från Unity till Unreal Engine verkar vara det enda bytet av spelmotor som har en guide för hur man skulle kunna gå till väga. Det tyder på att andra spelmotorer har större skillnader och är betydligt mycket omständligare att byta till. Eventuella konsekvenser av att projektet är låst till Unity är dess beroende på Unity:s fortsatta utveckling av grafikmo- torn. Under utvecklingen av detta projekt utnyttjades Unity:s licensvillkor som innebär att spelmotorn kan används gratis för projekt med liten omsättning. Om Unity väljer att ändra sin hantering av licenser skulle det kunna innebära att projektet inte kan få någon vidare utveckling på grund att det inte finns pengar till en licens.
6.2.2
Skapandet av animationer
I nuläget är många av de animationer som används av studenterna inte så levande som be- hövs för att skapa en bra upplevelse. De animationer som laddades ner från Mixamo be- dömdes vara levande, men gruppens egna animationer var inte. Detta kan ge upphov till en konflikt i vad användaren kan förvänta sig. Ett alternativ till att göra alla animationer för hand vore att istället använda sig av Inverse Kinematics, vilket skapar animationen givet en startpose och en slutpose. Förutom att detta hade underlättat arbetet med animationer hade det gett ett mer konsekvent utseende hos studenternas beteenden. Detta tros kunnat öka hur levande studenterna i simuleringen upplevs. Det hade även kunnat ge en mer realistisk si- mulering, då Inverse Kinematics även kan användas för att se till att studenterna sitter ner på föremål i miljön.
6.2.3
Användandet av Node.js
Att använda Node för att skriva back-end var ett väldigt enkelt val. Det grundade sig i att projektgruppen ville prova ett nytt programspråk som ingen hade använt sig av tidigare, men samtidigt ett programspråk som inte är för okänt. Att använda ett nytt programspråk är nog inte det absolut bästa att göra om man vill uppnå resultat snabbt. Men då detta är i utbild- ningssyfte och vi vill lära oss nya programspråk och tekniker så valdes Node att användas för detta.
6.3
Vilka val har tagits för att simuleringen ska hjälpa personen att bli
mer bekväm?
Studenterna i simuleringen är skapade för att verka levande men lite ”dumma” eftersom det går åt mycket resurser för att ha realistiska modeller för studenterna. Det bedömdes att detta var alldeles för belastande för att vara en möjlighet. En hypotes har inom gruppen formulerats med hjälp av handledare understödd av Uncanny Valley-teorin [24] på följande vis: en vacker grafisk modell av studenterna skulle kräva mer utförlig interaktion mellan studenterna och användaren för att skapa en illusion av verkligheten. Enligt hypotesen skulle det inte tjäna något syfte att ha en realistisk grafik om miljön inte beter sig realistiskt. Det skulle leda till en konflikt mellan vad användaren ser och vad användaren förväntar sig
6.4. Gemensamma erfarenheter
hända. Att istället använda människoliknande modeller som verkar levande skulle det enligt hypotesen skapa en bättre upplevelse för användaren. Då förväntningar på hur realistiska studenterna i simuleringen beter sig kommer vara lägre.
Ett alternativ till de nuvarande modellerna och animationerna hade varit att satsa på mer realistiska modeller och animationer. Kravet för det blir att hårdvaran dels kan exekvera systemet med den ökade belastningen samt att animationerna ser mer realistiska ut. För att uppnå detta kan animationer skapas från rörelsemönster istället för att skapas för hand. Då skulle variationen hos studenterna komma ifrån att spela in många personers rörelsemönster och då inte bara baseras på modellens utseende.
Med hjälp av den data som samlas in kommer förbättringsförslag ges till användaren och statistik över användningen presenteras. Om förbättringsförslagen inte är rimliga, eller om statistiken som visualiseras inte förstås kommer det inte hjälpa användaren att se vad som kan förbättras med presentationen. Vidare är det viktigt att systemet genererar förbätt- ringsförlag som tolkas på ett passande sätt. Detta för att förmedla förbättringsförslag på ett konstruktivt sätt till användaren.
Simuleringen kan anpassas efter den svårighetsgrad som användaren vill ha genom att justera hur miljön ser ut. Användaren kan till exempel justera hur mycket publiken inte- ragerar med användaren, publikens storlek samt rummets storlek. Detta ger användaren möjlighet till att skapa lämpliga scenarion anpassade för användarens behov. Detta i jäm- förelse med att bara erbjuda ett scenario tros göra upplevelsen mindre ansträngande för användaren, då användaren har kontroll över hur scenariot ska se ut och hur det ska spelas upp.
6.4
Gemensamma erfarenheter
I detta avsnitt diskuteras några av de främsta erfarenheterna gruppmedlemmarna fått kring arbetet och utvecklandet av produkten som är överförbara till framtida projekt.
6.4.1
Sen ankomst
Tanken med en fikakassa var att den skulle motverka sena ankomster till viktiga händelser, men det är oklart hur bra det fungerade. Kassan innehöll mer än 1000 kronor vid projektets slut. Erfarenheter som kan dras av detta är att fikakassan behöver ha en annan struktur för att det ska motverka sena ankomster. En till anledning till att fikakassa inte fungerade så bra kan vara att när man kan betala för att man är försenad så har man redan blivit bestraffad och behöver därför inte känna någon skuld. Men om man inte behöver betala något så har man inte blivit bestraffad och kan då känna mer skuld.
En förbättringsmöjlighet hade varit att göra avgiften större, så att det skulle kännas vär- re om man kommer sent. En variation av detta förslag är att de första tio minuterna har en högre avgift än de övriga minuterna som överträds. Exempelvis skulle man kunnat ha en startavgift på 50kr de första tio minuterna följt av 10kr för varje extra tio minuter man är sen. Detta skulle kunna minska antalet förseningar som sker i början av ett pass utan att ge en i längden allt för stor avgift.