Container Madness : Skapandeprocess av ett spel som simulerar en ARMG -- Automated Rail Mounted Gantry crane

Container Madness

Skapandeprocess av ett spel som simulerar en ARMG  Automated Rail Mounted Gantry crane. av Niklas Nolte, nne07001@student.mdh.se

2011-06-20

ABB Crane Systems byBrick Interface AB

Mälardalens Högskola, akademin för innovation, design och teknik (IDT)

Handledare: Linus Källberg (Mälardalens Högskola, IDT), Daniel Eriksson (byBrick Interface AB) Examinator: Thomas Larsson (Mälardalens Högskola, IDT)

Abstract

Svenska Syftet med den här rapporten är att redogöra för hur jag gått till väga för att skapa ett spel som simulerar en ARMG  Automated Rail Mounted Gantry crane med hjälp av Microsoft XNA 4.0 Framework. Projektet är ett samarbete mellan byBrick Interface AB och ABB Crane Systems.

Jag kommer att berätta om hur jag gått till väga med delar som analys, design, implemantation och testning och även berätta om resultatet och vilka förbättringar som kan göras.

Rapporten innehåller även en kort presentation av Microsoft XNA 4.0 Framework.

Engelska The purpose of this report is to present how I have created a game that simulates an ARMG  Automated Rail Mounted Gantry crane using Microsoft XNA 4.0 Framework. The project is a cooperation between byBrick Interface AB and ABB Crane Systems.

I will explain how I have managed research, design, implementation and testing and also present the result and discuss possible improvements that can be made.

Innehåll

6.2 Kollisionshantering vid föryttning . . . 11

6.3 Kollisionshantering vid containerlyft . . . 12

6.4 Klasser . . . 13 6.4.1 Menu . . . 13 6.4.2 PlayerStatistics . . . 13 6.4.3 ModelObject . . . 13 6.4.4 Container . . . 13 6.4.5 Truck . . . 13 6.4.6 Arrow . . . 14 6.4.7 CraneGameEngine . . . 14 6.4.8 PowerUp . . . 14 6.4.9 Sprite2D . . . 15 6.5 Autofunktion . . . 15

6.6 Alternativ till skuggor . . . 16

7 Testning 17 7.1 Kontinuerlig testning . . . 17

7.2 Användarstudie i projektets slutfas . . . 17

8 Resultat 19 8.1 Screenshots . . . 19

8.2 Förbättringar . . . 23

8.3 Utvärdering av XNA 4.0 . . . 23

Figurer

2.1 XNA programöde . . . 7

3.1 Crane Simulator 2009 . . . 8

4.1 Tidsplanering . . . 9

6.1 Axis-aligned Bounding Box . . . 10

6.2 Överlappande Bounding Boxes . . . 11

6.3 Kollisionshantering . . . 12

6.4 Klasser och enumeratorer . . . 13

6.5 Hörnen justeras efter marken och containern och visar var liften benner sig i X- och Z-led. På den vänstra bilden ser man hur tre av kryssen ligger nere mot marken medan det fjärde ligger uppe på en container. . . 16

7.1 Diagram med medelvärden för de frågor som ställdes efter att testpersoner spelat spelet i ungefär 10 minuter. . . 17

7.2 Diagram över fördelning av ålder och kön på testpersonerna. . . 18

8.1 Startmeny. . . 19

8.2 Läge mellan två banor. Statistik på hur väl man klarat sig visas. . . 20

8.3 Lastning av container på lastbil. . . 20

8.4 Positionering ovanför den container som ska lyftas. Spelaren måste sänka ner liften för att de fyra röda lamporna ska bli gröna och indikera att liften är rätt positionerad. . . 21

8.5 Här är containern som ska lyftas upp helt dold bakom andra containrar. Spelaren måste förlita sig på de fyra lamporna för att positionera sig rätt. . . 22

1 Inledning

Det här projektet har utarbetats tillsammans med handledare på byBrick Interface AB veckorna innan jag började med utvecklingen. byBrick Interface AB har i sin tur föreslagit ett samarbete med ABB Crane Systems. För byBricks del så är arbetet till stor del en utvärdering av Microsoft XNA 4.0 Framework och hur det kan komma till användning som komplement till nuvarande tekniker.

Syftet med spelet är att det ska användas i reklamsyfte för ABB Crane Systems på mässor för att locka kunder till montern och liknande samt vid olika kundaktiviteter för att lätta upp stämningen.

Spelet ska även nnas tillgängligt för anställda på ABB Crane Systems för att på ett roligt sätt lära sig hur det är att köra en kran.

Arbetsnamnet för projektet är Container Madness. Vad det kommer att heta i slutändan är inte klart.

1.1 Specikation

Följande punkter är krav ifrån ABB Crane Systems och byBrick Interface AB. Utöver detta gavs fria händer till att utöka och förbättra projektet.

ID Prio. Beskrivning Källa

0001 1 Skapa ett roligt och informativt spel som efterliknar ABB Crane Systems

containerkransystem för staplingskranar (ARMG - Automated Rail Mounted Gantry crane).

ABB Crane Systems byBrick Interface AB

0002 1 Spelet ska inte ta för lång tid att spela ABB Crane Systems 0003 1 Spelaren ska få information och statistik

på hur väl han/hon har klarat sig under spelets gång, tex. genomsnittstid på lastad container och hur mycket man krockar osv.

ABB Crane Systems

0004 1 Spelet ska använda 3D-grak. byBrick Interface AB 0005 1 Spelet ska vara skrivet i C# och XNA. byBrick Interface AB Vid ett möte med kontaktperson på ABB Crane Systems föreslogs följande tillägg:

ID Prio. Beskrivning Källa

0006 2 Under spelets gång ska det visas

information om de system som används. ABB Crane Systems 0007 3 Det ska nnas en High Score lista ABB Crane Systems

1.2 Spelidé

En ARMG  Automated Rail Mounted Gantry crane är i verkligheten i princip helt automatisk och körs bara manuellt i vissa situationer. Men om allt ska vara automatiskt blir det ju inget spel så istället är kranen i det här fallet manuellt styrd.

Spelet går ut på att spelaren ska manövrera containerkranen och lasta ett antal containrar på en lastbil innan tiden tar slut. Under spelets gång kan spelaren plocka upp Power-Ups som hjälper spelaren att klara av varje bana. När tiden tar slut eller spelaren klarar den sista banan är spelet över.

Spelaren har dessutom hjälp av mätsystem som indikerar var kranen benner sig för att underlätta för spelaren. Detta visas genom att fyra stycken lampor antingen är röda eller gröna.

1.3 Termer

Följande termer kommer att användas i rapporten och vissa av dem blir mer utförligt beskrivna i senare kapitel. • XNA 4.0 Framework (Microsoft XNA 4.0 Framework) - Ett ramverk för spelutveckling till PC, XBOX360

och Windows Phone som är skapat av Microsoft. [James2010, Cawood&McGee2009, Carter2009]. Förklaras vidare i sektion 6.

• HLSL (High Level Shader Language) - Ett språk för att skriva så kallade shaders för utnyttjande av mer avancerade funktioner i Microsoft Direct3D.

• Bounding Box - Ett rätblock som omsluter ett 3D-objekt. [Ericson2005] • Power Up - Ett objekt som ger spelaren fördelar under spelets gång.

• ARMG - Automated Rail Mounted Gantry (crane). Den typ av kran som används i spelet.

2 XNA

XNA är en samling verktyg som bygger på Microsoft DirectX. Det nns till exempel färdiga funktioner som hanterar inmatning från tangentbord, mus och spelkontroller. Det nns också funktioner som hanterar grak, ljud och inbyggt stöd för nätverksanvändning. Detta för att underlätta för spelutvecklare, som slipper uppnna hjulet på nytt i varje ny applikation.

2.1 Content Pipeline

Content Pipeline är en viktig del av XNA. När vi ska använda en l som till exempel lagrar ett 3D-objekt så innehåller den ofta mer information än vad som behövs för att XNA ska kunna hantera 3D-objektet. Vi behöver därför konvertera len till ett objekt som bara håller den information som är väsentlig. Content Pipeline importerar, processar och sparar len i en typ som vi sedan kan använda i vår applikation. En ytterligare fördel är att len processas vid compile time, det vill säga när vi kompilerar applikationen. Skulle det vara något fel i len kommer kompilatorn att säga ifrån vilket gör att vi märker detta direkt och felet kommer inte dyka upp senare någon gång under runtime. Det nns inbyggt stöd för ett antal ltyper men man kan även skriva egna importerare.

2.2 XNA programöde

Programödet i ett XNA-projekt är relativt simpelt. Först initieras variabler och därefter laddas grak, ljud m.m in i Content Pipeline. Därefter växlar programmet mellan att uppdatera spelets tillstånd och att rita ut grak på skärmen.

3 Analys

Eftersom idén till spelet är ganska enkel har jag inte behövt göra någon omfattande analys. Jag har studerat en del information och lmer på ABB Crane Systems website [ABBCraneWebsite] för att få en bättre uppfattning om hur kransystemet är uppbyggt och fungerar och vilka bitar jag kan ta med i spelet. En stor del har varit den visuella biten då spelet ska representeras i 3D och försöka efterlikna verkligheten i viss mån.

Eftersom jag tidigare aldrig gjort något spel i 3D med hjälp av XNA mer än en labb i en kurs så krävdes viss research på detta ämne innan jag kunde sätta igång med spelet. Boken 3D Graphics with XNA Game Studio 4.0 [James2010] har vart till stor hjälp. Jag har i början av projektperioden studerat exempel och tekniker i boken som visat allt ifrån hur man på ett enkelt sätt ritar ut 3D-objekt med hjälp av de i XNA-ramverket fördenerade funktionerna till att skriva egna HLSL-shaders med som exempel era ljuskällor och dimeekter samt element som skuggor.

Figur 3.1: Crane Simulator 2009

Jag har inte hittat några tidigare exempel på spel som använder denna typ av kranar. Det närmaste jag har hittat var en simulator där man lastar containrar på en båt, men där var det en helt manuell kran som användes. Däremot nns exempel på spel med lyftkranar, men även de är helt manuella. Ett sådant exempel är Crane Simulator 2009 [CraneSimulator] som visas i Figur 3.1.

4 Arbetssätt

Jag har jobbat självständigt under hela projektets gång och haft mailkontakt med handledare på byBrick Interface AB och Mälardalens Högskola för att visa hur spelet vuxit fram och för att få feedback och förslag på ändringar. Jag har även haft möte med ABB Crane Systems och handledare på byBrick Interface AB för att visa upp och utvärdera spelet. Vid det första mötet föreslogs tillägg som att visa statistik på hur väl spelaren klarat sig samt high-scorelista och att viss information om det riktiga systemet ska visas under vissa sekvenser i spelet. Det var framförallt när man tar en Power-Up som gör att kranen kör automatiskt och lastar ett antal containrar. Ett annat förslag var att ha olika kameravinklar under spelets gång. Till exempel att man yttar vyn till top-down när man närmar sig den container man ska ta.

4.1 Upplägg

Projektettiden har varit tjugo veckor på halvfart och följande gur visar hur tiden har fördelats.

Figur 4.1: Tidsplanering

5 Design

Spelidén utarbetades tillsammans med min handledare Daniel Eriksson på byBrick Interface AB. Han hade i tidigare uppdrag åt ABB Crane Systems gjort animationer av de kransystem som används i spelet. Vår idé var att låta användaren styra en kran och lasta utvalda containrar från en containerstack till lastbilar. För att göra det lite roligare och inte bara en ren simulering bestämde vi att containrarna skulle ha olika egenskaper som påverkar kranen samt att spelaren bara har en viss tid på sig att lasta alla containrar. Exempel på egenskaper är olika vikt och hållbarhet som gör att man kan ytta kranen olika snabbt och gör att man bara kan krocka ett visst antal gånger med dem innan de går sönder.

Därefter har vi använt oss av en form av Cooperative Design [Wikipedia_1] som innebär att både jag som utvecklare och kunden kan komma med förslag på nya funktioner i spelet under utvecklingens gång.

6 Implementation

6.1 Kollisionshantering och Bounding Boxes

En stor del av mekaniken i spelet är kollisionshantering. Den är till för att begränsa hur man kan ytta kranen och containrarna så att objekten inte yter in i varandra. Jag använder mig av Axis-aligned Bounding Boxes (AABBs) [Ericson2005] eftersom de objekt som kan kollidera i de esta fall är låd-formade. En AABB är en låda i 3D-rymden som innesluter alla punkter i 3D-objektet i fråga. Detta ger en stor fördel då vi kan kontrollera ett väldigt lågupplöst objekt med endast 8st punkter istället för ett objekt där vi skulle behöva gå igenom kanske era tiotusentals punkter. En Bounding Box är i princip två tredimensionella punkter som representerar de största och de minsta X-, Y- och Z-värden av alla punkter i 3D-objektet. En AABB kan skapas genom att objektets alla punkter läses och de största respektive de minsta värdena sparas.

Figur 6.1: Axis-aligned Bounding Box

I XNA nns det en klass som heter BoundingBox som representerar en AABB. Det nns också funktioner för att kontrollera ifall två stycken AABBs överlappar varandra eller om en punkt innesluts i en AABB. Däremot nns det ingen enkel funktion för att läsa punkterna i ett 3D-objekt vilket jag tycker är en brist i XNA. Jag har istället använt en funktion som jag funnit på en blog[Roastedamoeba_2010] som beskriver hur man gör just detta.

För att underlätta debugging vid implementationen av kollisionshanteringen gjorde jag även en funktion som ritar ut sfärer i alla åtta hörn på en AABB. På så vis går det att lätt se storleken på och placeringen av en Bounding Box.

6.2 Kollisionshantering vid föryttning

Här använder jag mig av funktionen BoundingBox.Intersects(BoundingBox) som kontrollerar om två stycken AABB överlappar varandra. Jag yttar först kranen i X-led med aktuell hastighet(distans) och testar sen om det är en kollision. Jag kontrollerar den container som yttas mot alla andra containrar genom att loopa igenom listan, och även mot lastbilarna och ser om det är en kollision. Om det är en kollision yttar jag tillbaka kranen med en distans som är större än hastigheten så att det ser ut som att kranen studsar tillbaka vid kollisionen. Därefter kontrollerar jag på samma sätt föryttning i Y- och Z-led.

Jag testade först att ytta alla axlar samtidigt men det visade sig vara svårt att veta i vilken axelföryttning kollisionen sker och således vilken axel som måste korrigeras.

6.3 Kollisionshantering vid containerlyft

När man ska lyfta en container måste liften vara rätt positionerad ovanför containern. Detta mäter jag med fyra punkter nedanför liften som är placerade strax under och en liten bit innanför maximum- och minimumvärdena för liftens AABB. Dessa fyra punkter måste innefattas i AABBn för den container som ska lyftas. Jag har även en punkt placerad mitt under liften som kontrollerar vilken container den benner sig ovanför. Jag kontrollerar även att de fyra punkterna ligger i samma AABB.

6.4 Klasser

Följande stycke beskriver de klasser jag har skapat för spelet samt vad de används för.

Figur 6.4: Klasser och enumeratorer 6.4.1 Menu

Klass som hanterar och ritar startmenyn. Inparameter är den skärmupplösning som för närvarande används, för att rita ut menyn på rätt ställe oavsett upplösning.

6.4.2 PlayerStatistics

PlayerStatistics är en klass som håller reda på all information som har med spelaren att göra. Det är i princip bara en lista med variabler och ett antal funktioner för att räkna ut statistik, samt en funktion som returnerar en sträng med all data i rätt format.

6.4.3 ModelObject

ModelObject är den klass som hanterar ett 3D-objekt. Den är till för att enkelt ytta, rotera och skala ett 3D-objekt. Här nns även metoder för att ge 3D-objekt eekter med hjälp av HLSL-shaders. ModelObject är en utökning av klassen Model som nns i XNA 4.0.

6.4.4 Container

Ärver från ModelObject. Skillnaden är att Container även har parametrar för containerns hållbarhet, värde, typ och hur snabbt kranen kan ytta containern.

6.4.5 Truck

6.4.6 Arrow

Ett objekt som representerar den pil som pekar på den container som ska plockas upp. Arrow är ett ModelObject som har en egen uppdateringsfunktion vilken gör att pilen rör på sig mot den valda containern. Det nns även en funktion som sätter ny position.

6.4.7 CraneGameEngine

Hjärnan i spelet är klassen CraneGameEngine som håller reda på och uppdaterar alla variabler och objekt som används under spelets gång. När vi skapar ett objekt av typen CraneGameEngine så laddas först all grak och alla 3D-objekt in till Content Pipeline och alla variabler sätts till standardvärden. Därefter körs funktionen LoadLevel() som i det här fallet laddar den första banan.

Den första banan använder bara standardcontainrar, det vill säga containrar utan extra egenskaper. Container-stacken består av 11*13 staplar av containrar som kan ha mellan 0 och 8 containrar i vardera stapel. Första banan har bara ett lager med containrar som placeras ut i en nästlad for-loop. Det vill säga att alla staplar har antingen 0 eller 1 containrar. Antalet slumpas ut.

För att visa vilken container som ska plockas upp av spelaren placeras en tydlig pil som pekar ut den containern i fråga. Jag väljer på liknande vis som jag placerar ut Power-Ups i stycke 2.6.5 ut en container att peka på.

I LoadLevel() sätts även det antal containrar som spelaren måste lasta för att klara banan, samt den tid som spelaren har på sig.

Då en bana väl är inladdad övergår spelet i en loop som växlar mellan att uppdatera och rita grak. I upp-dateringsfasen för CraneGameEngine kontrolleras först vilka tangenter som är nedtryckta. Detta för att se i vilken riktning kranen ska yttas eller om spelaren försöker plocka upp eller lasta en container. Kranen yttas med funktionen MoveCrane() som avgör vilka delar av kranen som ska yttas beroende på vilken riktning som gäller. MoveCrane() kallar i sin tur på funktionen Collide() och kontrollerar antingen den container man lyfter eller själva liften mot containerstacken om någon kollision sker. Om en kollision sker så korrigeras föryttningen.

Om spelaren försöker lyfta en container måste liften vara rätt placerad över en container. Detta kontrolleras med funktionen ContainerNear() som returnerar ett index på den container som är placerad närmast under liften. För att lyftet ska lyckas måste även de fyra kontrollamporna vara tända som indikerar att liften är rätt placerad mot containern. När spelaren lyfter en container fungerar föryttningen på samma sätt som om man inte lyfter. Den enda skillnaden är att kollisioner även kontrolleras mot den container som lyfts.

Om spelaren försöker landa en container på en lastbil kallas metoden DropContainer() som kontrollerar att con-tainern är rätt placerad mot en lastbils ak. Om spelaren lyckas lasta en container adderas poäng och extra tid, samt antalet containrar att lasta minskar med ett. Därefter kallas SetTarget() som tar fram nästa container som ska hämtas och markerar den och uppdateringsfasen är genomförd.

6.4.8 PowerUp

En Power-Up är ett objekt som spelaren kan ta genom att ytta kranens lift så den träar objektet. Det nns ett antal olika sådana objekt som gör att spelaren klarar sig bättre och får mer poäng.

• Extra Poäng - Det nns två olika Power-Ups som ger spelaren 250 respektive 500 poäng. • Extra Tid - Spelaren får extra tid på sig att klara av banan.

• TPS - Denna Power-Up kallar på autofunktionen som nämns i stycke 7.5. Autofunktionen körs tre gånger per Power-Up

Power-Ups placeras alltid ovanför en container som ligger överst i en stack på banan. Eftersom jag sparar mina Container-objekt i en länkad lista kan jag inte på ett enkelt sätt se om en container ligger överst i en stack. För detta har jag en rekursiv funktion som kontrollerar om en slumpvis vald container ligger överst i en stack genom att testa så det inte nns en container i listan som har samma X- och Z-värde men ett högre Y-värde. Om den valda containern inte ligger överst väljer jag en ny container och testar denna på samma sätt. Därefter placeras en slumpvis vald Power-Up ut.

Ett alternativ till den länkade listan hade varit att ha en array av arrayer för att spara containrarna i vilket hade varit något eektivare och man skulle inte behöva gå igenom alla containrar vid kollisionskontroll, utan istället bara testa de i arrayen närliggande staplar. Programmeringsmässigt är det enklare att använda en länkad lista istället för

6.4.9 Sprite2D

Sprite2D är en enkel klass som hanterar bilder. Klassen är en liten utökning av Texture2D som följer med XNA 4.0. Jag använder den för att rita ut kontroll-lamporna.

6.5 Autofunktion

Det jag kallar Autofunktion är när programmet tar över kontrollen av kranen och automatiskt hämtar och lastar ett antal containrar. Det inträar när spelaren tar en viss Power-Up. Autofunktionen simulerar det verkliga systemet TPS - Target Positioning Sensor, som i verkligheten är ett 3D-laserscanningsystem.

När autofunktionen körs utgår vi ifrån den nuvarande positionen som kranen har. En variabel håller reda på index på den container som ska hämtas och med hjälp av den får vi fram positionen som denna container har. För att ytta kranen och plocka upp containern körs kranens lift upp i max-läge för att den inte senare ska krocka med något på vägen mot destinationen. Därefter yttas hela kranen i X- och Z-led samtidigt tills den är framme inom viss marginal från destinationen. Väl framme åker kranens lift ner tills den är precis ovanför containern. Detta mäts genom att kontrollera om en punkt en bit under liften kolliderar med containerns bounding box. Därefter kopplas containern så att den i princip blir en del av kranen och yttas samtidigt som kranen yttas. Nu sätts destinationen om till positionen för aket på en av de två lastbilarna. Kranen och containern yttas på samma sätt som tidigare tills den är framme på lastbilens ak. Därefter yttas containern från listan av containrar så att den istället blir en del av lastbilen. Samtidigt sätts en agga på lastbilen som indikerar att den ska köra iväg. Vidare adderas poäng och statistik till spelaren samt att en Power-up eventuellt dyker upp på spelplanen. Om autofunktionen fortfarande gäller upprepas allt igen. Om autofunktionen inte gäller yttas liften upp ovanför lastbilen och spelaren återfår kontrollen av kranen igen och kan fortsätta spela.

6.6 Alternativ till skuggor

Ett problem är att man utan skuggor har svårt att se var kranens lift benner sig i X- och Z-led. Då implementationen av skuggor kräver mer research om HLSL-shaders behövdes ett alternativ. Vid ett möte med handledare på MDH kläcktes idén med att låta fyra bollar eller liknande visa var hörnen på liften benner sig genom att låta bollarna följa höjden på marken och containerstaplarna.

Jag skapade således en funktion som hämtar punkterna i liftens Bounding Box och lägger dessa i en array. Därefter justerar jag X- och Z-värdena så de ligger innanför Bounding Boxen. I nästa steg går jag igenom de fyra punkter, de fyra med lägst Y-värde, som ska användas och kontrollerar dessa mot alla containrar och justerar Y-värdet om någon punkt kolliderar med en container. Här visade det sig vara en fördel att ha containrarna sparade i en länkad lista. Då en kollision sker kan jag bara fortsätta loopen. Om det ligger en container staplad ovanför den container där kollisionen sker ligger den senare i listan.

Figur 6.5: Hörnen justeras efter marken och containern och visar var liften benner sig i X- och Z-led. På den vänstra bilden ser man hur tre av kryssen ligger nere mot marken medan det fjärde ligger uppe på en container.

7 Testning

7.1 Kontinuerlig testning

Under hela projektperioden har jag låtit personer testa spelet för att få feedback och idéer till förbättringar och tillägg. Det största problemet har visat sig vara kontrollen av kranen som sköts med tangentbordet, samt att det behövs skuggor för att förbättra djupseendet då man yttar containrarna.

Då jag inte har någon handkontroller till PC'n att testa med har jag istället utnyttjat en av de stora fördelarna med XNA och konverterat spelet till min XBOX360. Eftersom detta bara var ett test och inget krav från kunden skapade jag ett nytt projekt för XBOX360 i Visual Studio och kopierade över all kod. Därefter var det bara att ändra så att inmatning görs ifrån handkontroller istället för tangentbordet. Detta var det enda jag behövde ändra för att det skulle fungera. Det visade sig vara mycket enklare att kontrollera kranen med handkontrollen till XBOX360.

En annan sak som testpersoner påpekat är att jag först hade för kort tid innan spelet tog slut. Nybörjare behöver mer tid på sig för att komma igång och förstå hur kranen reagerar när man styr den. Ett förslag var att ha obegränsat med tid på den första banan för att underlätta för spelare att komma igång eller att ha en separat testbana med obegränsad tid där spelare kan öva på att kontrollera kranen.

7.2 Användarstudie i projektets slutfas

I slutfasen av arbetet sammanställdes ett frågeformulär som testpersoner ck svara på efter att de spelat spelet. Detta för att få svar på hur bra problemen lösts. Formuläret bestod av sex påståenden om spelet som besvaras på en femgradig skala från Stämmer inte alls till Stämmer helt. Följande påståenden skulle besvaras:

1. Startmenyn är tydlig och lätt att förstå 2. Det är lätt att förstå vad spelet går ut på 3. Det är lätt att kontrollera kranen

4. Det nns tillräckligt med tid för att hinna klara uppdragen (banorna)

5. Kontroll-lamporna och markörerna är till hjälp vid positionering av kranen ovanför container/lastbil 6. Spelet är roligt

Testpersonerna var totalt elva i åldrarna 20-50 år och i alla utom ett fall män. Resultatet av frågeformuläret är som följer:

1,0 2,0 3,0 4,0 5,0

1. Startmenyn är tydlig och lätt att förstå

2. Det är lätt att förstå vad spelet går ut på

3. Det är lätt att kontrollera kranen

4. Det finns tillräckligt med tid för att hinna klara uppdragen (banorna)

5. Kontroll-lamporna och markörerna är till hjälp vid positionering av kranen ovanför container/lastbil

Exempel på resultat som skiljer sig mellan testpersonerna var att två av elva personer hade svarat med högsta värde att det fanns tillräckligt med tid medan de övriga låg mellan två och tre.

Ett annat exempel var fråga fem där de esta hade svarat fyra till fem, medan en person inte svarat alls och kommenterat med vilka lampor? då personen missat dem helt. Jag tror dock detta berodde på att vi testade spelet på en 30 skärm. På en så stor skärm hamnar lamporna lite ur fokus då kameran centrerar bilden efter var liften benner sig och det är där man oftast tittar.

0 1 2 3 4 5 6 7 8 man kvinna 20-29år 30-39år 40-50år

Figur 7.2: Diagram över fördelning av ålder och kön på testpersonerna.

Utöver frågorna ck testpersonerna möjlighet att ge förslag till förbättringar på spelet. Exempel på förbättringar: • Power-Ups kan ge mer tidstillägg. 5 sekunder gör ingen större skillnad.

• Tydligare indikation när man kraschar. Till exempel en varningsskylt som blinkar till när man kolliderar. Detta var det era personer som påpekade.

• Olika kameravinklar. Alternativt att man kan styra och rotera kameran själv. • Göra så den container man ska hämta blinkar lätt för att lättare se den. • Göra kranen transparent när den skymmer liften.

• Zooma in när man närmar sig containern som ska lyftas eller lastbilarna när man ska lasta.

• Införa en illustration av chefens humör som speglas av hur väl man kontrollerar kranen. Till exempel en avatar som kommer med kommentarer under spelets gång.

8 Resultat

Resultatet har blivit en fullt fungerande prototyp av ett containerkranspel som jag kallar Container Madness. Spelet består i stort sett av två komponenter:

• En startmeny där spelaren kan göra vissa inställningar och få information om spelet

• Själva speldelen som består av tre olika banor med växande svårighetsgrad. Om spelaren klarar den tredje banan så växlar spelet tillbaka till startmenyn och statistik över hur väl spelaren klarat sig visas.

De element som jag har implementerat är: • Simulering av en ARMG crane i 3D-miljö. • Simulering av TPS.

• Spelet tar på grund av tidsbegränsningen inte mer än fem minuter att spela från början till slut, vilket möter de krav som ställts.

• Statistik över spelresultat och visning av kort information när TPS är aktiv. • HLSL-shader med dim-eekt.

8.1 Screenshots

Här följer ett antal bilder som visar hur slutresultatet ser ut.

Figur 8.2: Läge mellan två banor. Statistik på hur väl man klarat sig visas.

Figur 8.4: Positionering ovanför den container som ska lyftas. Spelaren måste sänka ner liften för att de fyra röda lamporna ska bli gröna och indikera att liften är rätt positionerad.

Figur 8.5: Här är containern som ska lyftas upp helt dold bakom andra containrar. Spelaren måste förlita sig på de fyra lamporna för att positionera sig rätt.

8.2 Förbättringar

De förbättringar och funktioner som inte under projektperioden implementerats är kanske framförallt grakrelaterade, men även viss spelmekanik skulle kunna lyfta spelet till en högre nivå. Det främsta som bör implementeras är skuggor då det har varit ett återkommande problem vid testning av spelet.

En annan sak som kan förbättras är att implementera styrning med en analog joystick. Det skulle underlätta då man själv lättare skulle kunna bestämma hastigheten vid föryttning av kranen.

Implementation av fysik skulle även det vara intressant. Med fysik menar jag att man skulle kunna låta containrarna påverkas av varandra vid kollisioner. Till exempel att en container som lyfts och slår i en annan container då skulle börja snurra och gunga och skapa problem för spelaren. Även att man låter containrar stå snett och oregelbundet i staplarna så att spelaren måste justera liften genom att vrida den till rätt läge innan den container som ska lyftas upp kan förankras. Om dessa exempel implementeras måste kollisionshanteringen göras om från grunden, då objektens Bounding Boxes inte längre kommer att vara axelorienterade, vilket i sin tur leder till en mycket mer komplex implementation.

8.3 Utvärdering av XNA 4.0

Kan då XNA användas i syfte att göra mer avancerade simulatorer och liknande? Jag tycker att jag med denna pro-totyp visat att XNA är en kompetent plattform som har stor potential för att skapa mindre applikationer i såväl 2D som 3D. Inte minst på grund av enkelheten att skapa en applikation som går att använda på en PC och samtidigt lätt kan konverteras för användning på XBOX360 och kanske framförallt till Windows Phone vilket gör att användnings-områdena blir många. Det skulle vara intressant att se hur väl denna applikation fungerar på just Windows Phone och kanske blir det ett framtida projekt.

9 Referenser

[ABBCraneWebsite] http://www.abb.co.uk/industries/us/9AAC132769.aspx?country=GB, (2010-05-25) [Carter2009] Chad Carter, Microsoft XNA Game Studio 3.0 Unleashed, Sams, (2009)

[Cawood&McGee2009] Stephen Cawood & Pat McGee, Microsoft XNA Game Studio Creators Guide, McGraw-Hill, (2009)

[CraneSimulator] http://www.giantbomb.com/crane-simulator-2009/61-28003/, (2010-05-25)

[Ericson2005] Christer Ericson, Real-Time Collision Detection, Morgan Kaufmann Publishers, (2005), (pages 77-87) [James2010] Sean James, 3D Graphics with XNA Game Studio 4.0, Packt Publishing, (2010), (pages 8-116)

[Roastedamoeba_2010] http://www.roastedamoeba.com/blog/archive/2010/12/10/drawing-an-xna-model-bounding-box, (2010-05-25)