IT Eksamensprojekt. Unity Spil IT B RTG. Klasse 3.4. Louis Drejer, Markus Duus og Mikkel Jensen

Transkript

1 IT Eksamensprojekt Unity Spil IT B RTG Klasse 3.4 Louis Drejer, Markus Duus og Mikkel Jensen Fra

2 1.0 Indledning 1.1 Analyse 1.2 Problemformulering 1.3 Målgruppe 1.4 Løsningsforslag 1.5 Valg af løsningsforslag 1.6 Afgrænsning 1.7 Userstories Need to have: Nice to have: 2.0 Overordnet design 2.1 Visuelt Design Spilleren Banerne Menu 2.2 Interaktionsdesign Dimension Dimension Dimension Dimension Dimension 2.3 Værktøjer Unity Tiled Tiled2Unity Beepbox Sonic Pi 3.0 Iterationer 3.1 Første Iteration Planlægning Design Implementering Test Videreudvikling 3.2 Anden Iteration Planlægning Design Implementering 1

3 Spil Musik Test Videreudvikling 3.3 Tredje Iteration (endeligt produkt) Planlægning Design Level Level Room (House) Implementering Spil Musik Test Videreudvikling 4.0 Licens 4.1 Kreditering DelPåSammeVilkår CC BY SA Licens Fordele Ulemper 4.2 Kreditering IkkeKommerciel DelPåSammeVilkår CC BY NC SA Licens Fordele Ulemper 4.3 Vores licens 5.0 Konklusion 6.0 Litteraturliste 7.0 Bilag Bilag 1: Projektbeskrivelse Projektbeskrivelse Bilag 2: Tidsplan Bilag 3: Kode for spil Bilag 4: Kode for musik 2

4 1.0 Indledning 1.1 Analyse I dagens Danmark spiller computeren en kæmpe rolle. Gallup har lavet en statistik hvor det ses at børn i alderen fra 8 16 år, i gennemsnit bruger ca. 3,5 timer foran computeren hver 1 dag, hvor det meste af tiden bruges på internettet eller på at spille spil. Et problem der kommer af dette, er at de unge begynder at bruge flere penge på spil, 2 samtidig med at det bliver nemmere og nemmere at købe spil og at lave indkøb i spillene. At unge bruger mere tid foran skærmen er ikke noget vi kan gøre noget ved, men da der er nogle unge der bruger mange penge på spil, har vi tænkt os at lave et gratis spil. 1.2 Problemformulering Der er i dagens Danmark mange unge der bruger for meget tid foran computeren, hvor en stor del af tiden bliver brugt på spil, som man ikke kan lære noget fra. Derudover er der også nogen der bruger for mange penge på disse spil. Det er disse problemer vi vil bearbejde i denne rapport. 1.3 Målgruppe Da det er problemer for unge vi kigger på, skal det også være i denne gruppe hvor vores målgruppe er. Her har vi tidligere sat alderen til at være for unge mellem 8 og 16 år, men da dette er for stor en målgruppe vil vi indsnævre den nærmere. Her besluttede vi os for at vores målgruppe skulle være for unge i 14 års alderen 1.4 Løsningsforslag Til vores løsningsforslag ser vi på forskellige typer af spil, som matcher vores problemstilling. Vi har herunder tre forskellige spiltyper, der kan fungere som en løsning til vores problem. RPG spil: Denne spiltype er oftest fokuseret på magi og fabeldyr, samt det overnaturlige, hvilket danner grundlag for skabelsen af en alternativ verden. Spillere har en tilbøjelighed til at leve sig ind i denne verden, hvor man får mulighed for kunne være en anden. Her kan man få lov til at teste mange overnaturlige kræfter af, som man ellers ikke ville kunne finde i virkeligheden. Eksempelvis kunne man kaste ild ud af hænderne eller måske bare flyve igennem skyerne. Med dette kan man blive underholdt gennem indlevelse af disse fantasier. Arkade spil: Denne spiltype er fokuseret på spil som f.eks. pacman og pinball, hvilket er spil der typisk 1 bruger syv timer daglig foran en ska erm/ 2 lokker boern og unge til at brugepenge/ 3

5 kan findes i offentlige forretninger, der har til formål at indtjene penge ved meget små betalinger, der foregår ved at en spiller/kunde indsætter en mønt i en maskine, hvorledes at du får lov til at spille. Spillet i disse maskiner er simple og underholdende, hvilket derfor også rammer en større målgruppe, og på denne måde øger indtjeningsmulighederne. Dog vil vi ikke lave maskinen, men blot spillet der spilles, da der her vil blive lagt vægt på underholdning. Strategispil: Strategispil er en lidt anden genre end de to forrige, da man her skal bruge tid på at tænke sig om for at kunne gennemskue spillets gang og mange puslespil (bedre kendt som puzzle ). På denne måde bliver man underholdt igennem puslespil og gåder, der kan virke belønnende når løses. Når puslespillet løses bliver der givet adgang til spilleren at kunne bevæge sig videre til det næste niveau. 1.5 Valg af løsningsforslag Udfra den baggrund vi har på alle vores løsningsforslag, så har vi valgt at anvende løsningen med at lave et strategispil. Strategispil handler som sagt meget om at tænke sig om mht. hvilken strategi el.lign. man vil anvende, hvor det her ikke altid er sikkert at der findes flere løsninger. Af denne årsag bliver man nødt til at finde på en masse løsninger, for at kunne bevæge sig videre i spillet. Sammenlignet med de andre spil, så vil dette være simpelt og gratis (hvis vi ser på det i en evt.indtægts situation), hvorledes der bliver fundet underholdning i løsningsstrategier. Arkade spillet ville også kunne fungere som en løsning, men er mere anvendeligt hvis et af målene er at tjene penge, hvilket ikke er hvad der prioriteres. Derudover er spiltypen for simpelt til at kunne være underholdende i lang tid, sammenlignet med de to andre løsningsforslag. Herudover er RPG spillet også lidt uden for målet (problemstillingen), da der oftest bliver anvendt vold i spillet, hvilket igen er noget vi ikke vil prioritere, da det ikke passer helt med problemstillingen. Denne spiltype har tilbøjelighed til at kunne blive avanceret igennem forskellige game mechanics (måder at spille på), som igen kan gå hen og stride lidt imod kravet om at spillet skal være simpelt. Dette er selvfølgelig afhængigt af hvilke mechanics man indbygger i spillet. På grundlag af disse sammenligninger, så virker strategispillet som et oplagt valg af løsning, da det nemt kan udfylde vores kriterier for et simpelt og underholdende spil (der kan være gratis). 1.6 Afgrænsning Nu da vi har fundet vores løsningsforslag, så er det på tide at uddybe hvad vores løsning skal indeholde. Løsningsforslaget er som sagt valget af at lave et strategispil. Med dette strategispil vil vi gerne inddrage nogle små egenskaber fra de andre genre, men stadig have fokus på at spillet skal være udfordrende af hensyn til hvordan man kan se igennem diverse puslespil. En af de ting vi er inspireret af fra RPG typen er ideen om at man styre en figur/karakter rundt på diverse niveauer i spillet. Derudover skal denne karakter kunne udføre en handling, der hjælper spilleren med at gennemføre de forskellige puzzles. 4

6 Disse puzzles skal være udfordrende, samt at de skal give spilleren noget tænke over uden at det bliver kedeligt. Det skal være underholdende. Ved dette skal disse puzzles handle meget om at man skal være istand til at kunne kombinere forskellige mønstre, se sammenhængen mellem disse og anvende karakterens begrænsede handlinger, til at kunne assistere spilleren i at gennemføre de forskellige niveauer. 1.7 Userstories Vi har valgt at dele vores user stories i need to have og nice to have. Hvilket vi vil gennemgå i det følgende afsnit: Need to have: Det skal være let at styre. Spillet skal kunne blive anvendt hurtigt og nemt, så vi vil fokusere på at have meget få taster. Her skal de eneste controls i spillet være at man kan styre sig selv. Som styreknapper vil vi anvende de mest anvendte knapper til computerspil når man skal bevæge sig frem og tilbage, fra side til side, knapperne W,A,S,D. Der skal være et bevægeligt objekt Det bevægelige objekt skal være hovedpersonen i spillet, det er den som brugeren bevæger frem og tilbage, og til næste bane. Det skal være et overskueligt spil. Det er det primære krav vi selv har stillet til spillet, hvis det ikke er overskueligt så vil brugeren heller ikke bruge særlig meget tid på det. Det er ikke alle som læser om hvad spillet handler om i vores valgte målgruppe Der skal være et eller flere bevægelige objekter. De bevægelig objekt kan være ens karakter, men det kan også være objektet som ens karakter kan interagere med Nice to have: Temamusik til spillet Med lidt musik vil man få et lidt bedre humør. Ligesom i spil som Mario og andre arcade spil, bringer det en form for liv ind i spillet. Flere Sværhedsgrader Der ville være ret udfordrende at kunne justere sværhedsgraden på spillet. Jo højere oppe den kommer, desto svære bliver spørgsmålet. Spillet skal have en startmenu Når man åbner spillet, skal man kunne bestemme om man vil gå videre ind i selve spillet, slukke spillet eller skifte nogle indstillinger, som f.eks. lydniveau. 5

7 2.0 Overordnet design 2.1 Visuelt Design Spilleren Det første design vi lavede, var designet til vores spils hovedkarakter. Her tænkte vi at det ville være smartest at gemme vores karakters arme under en kappe, da vi derfor kan undlade en del sprites, og at det vil blive lettere at få karakteren til at lave flydende bevægelser, når der ikke er så mange detaljer man skal have styr på. Vores ide var at skabe en hætte/kappeklædt person hvor man kun kan skimte øjne. Efter vi havde fastsat det kunne vi gå i gang med at konstruere en rough af karakteren (Roughen ses på billedet til højre). Efter vi havde lavet et grunddesign for vores karakter, kiggede vi på forskellige farver som vi kunne bruge til karakteren. Vi startede med at give vores karakter nogle lilla streger, hvor vi ud fra disse farvede streger fandt andre der passede godt sammen med dem. Da vi gik efter et retro tema i vores spil, valgte vi at give karakteren færre pixels, samt at have karakteren i høj kvalitet ville kræve for meget tid at lave alle de forskellige sprites vi skulle bruge. På billede nederst til venstre ses det første færdige karakterdesign, som vi af hensynsmæssige årsager var nødt til sænke kvaliteten på. Nederst til højre ses så den endelige sprite vi endte at med bruge. 6

8 2.1.2 Banerne Ud fra vores valgte løsning begyndte vi at designe forskellige levels. Da intentionen ved spillet er at det skal kunne videreudvikles, mente vi at 2 levels ville være et passende antal, således er der blevet lagt et grundlag for hvordan man kan designe ekstra levels. Som beskrevet i punkt 1.6, så har vi tænkt os at lave et puzzle spil, hvor det primære formål er at finde en sammenhæng i banerne og kunne tænke sig igennem de forskellige levels udfordringer. Her tænkte vi at vi skulle lave et forholdsvis let første level, så vores spiller kan komme ind i spillet og finde ud af hvordan spillet fungerer aht. controls osv. Efter at vi nu har bestemt os for vores antal af levels, og hvad deres tema skal være, kan vi gå i gang med at lave roughs til level designs. Vores første til det første level ses på billedet herunder. Tanken er at man starter nede i venstre hjørne og skal derfra finde den rigtige vej videre til næste level. I level 2 har vi øget niveauet en smule. I denne bane går du ud på at finde den rigtige vej igennem banen ved teleportere sig fra rum til rum. Banen består af 9 rum og i hvert rum er der 4 teleporte døre(det er firkanterne i rummet). Det det så handler om er at komme ind til midterrummet, hvor man så kan komme videre til næste level, den har vi dog valgt at se bort fra da vi som skrevet havde besluttet os for at lave 3 baner. Roughen til bane 2 kommer så til at se følgende ud. 7

9 2.1.3 Menu Vi har også valgt at lave en simpel menu, så man ikke hopper direkte ind i spillet. Her laver vi en meget standard startskærm, med en play knap, option knap og en exit knap. Play knappen vil føre en videre ind i spillet, under options knappen ville man kunne placere muligheder for at skrue op og ned for lyden, samt at man ville kunne give spilleren en mulighed for at skifte spillets opløsning. 8

10 2.2 Interaktionsdesign Når man beskæftiger sig i at designe interaktive digitale produkter, gør man ofte brug af begrebet interaktionsdesign. Interaktionsdesign dækker både over informationsdesign, navigationsdesign og ikke mindst interaktionsdesign. Når man skal designe/analyse det interaktionsdesign i ens produkt, gør man brug af modellen kaldet De 5 dimensioner Dimension Første dimension kaldes for ord. Det er her den skriftlige del af kommunikation bliver designet. Da vi har en ung målgruppe er det vigtigt, at vi skriver et sprog de kan forstå. Derfor har vi valgt at tage udgangspunkt i andre spils menuer. De er ofte bygget op i 3 punkt/muligheder play, option og exit. Dem har vi taget til os, da det er det vores målgruppe er vant til. Derudover har vi tænkt os at forklare styring og hvad spillet går ud på under option knappen, samt at have indstillinger for eksempel lydniveau og opløsning. Her vil vi igen tænke over vores sprogbrug, da de skal forstå hvad der står Dimension Den anden dimension kaldes for Visuel repræsentation. Det gælder alt det visuelle som ikke er ord. Dette punkt har vi tænkt meget over, for det er vigtigt spilleren forstår hvilken vej han skal gå vores baner. Det er også derfor vi har valgt at i vores første level skal den sti spilleren skal følge er mørkere end resten af banens farver. Vi vil også have nogle trækker og slip knapper hvor man kan skrue op og ned for musikken i spillet. Dem vil vi placere inde under options. De andre visuelle repræsentationer har vi allerede præsenteret i afsnittet om visuelt design Dimension Den tredje dimension kaldes for Fysiske rum og objekter. Denne dimension handler om hardwaren. Som tidligere beskrevet så er det computerspil, så man skal bruge computeren til at kunne spille det. Derudover skal man bruge en mus/touchpad til at starte spillet. Man skal også bruge et tastatur da det er via det man kan styre sig rundt i spillet. Vi har tænkt at bruge tasterne W,A,S og D. Da det er det mest normale for computerspil. Det gode er med computerspil er at man kan spille dem overalt, hvis bare man har en computer Dimension Den fjerde dimension kaldes for Tid. Her kigger man på hvor lang tid brugeren skal bruge på de tre første dimensioner, for at have nået ens mål med interaktionen. Da vi laver et spil, 9

11 vil det komme an hvad ens formål med at spille det er. Hvis ens formål med spillet er at klare det, vil tiden variere alt efter hvor god man er til spillet Dimension Den femte dimension kaldes for Adfærd. Med andre ord, tænker man i denne dimension på, hvilke følelser og reaktioner spilleren får ved interaktionen. Vi håber at de vil blive underholdt og dermed spille vores gratis spil. Dermed kan vi være med til at løse vores problem, som omhandlede at børn bruger for mange penge på spil. 10

12 2.3 Værktøjer Unity Efter vi havde undersøgt en del om forskellige gameengine. Fandt vi frem til at den bedste game engine var Unity. Unity er oprindelig et dansk program lavet af David Helgason, Joachim Ante og Nicholas Francis. Unity er en gratis game engine, hvor man har mulighed for at programmer 2D og 3D spil. Formålet med en game engine såsom Unity er at levere et udviklingsmiljø, som gør processen i at udvikle spil væsentligt hurtigere og nemmere. Ved at have en engine kan man ved hjælp af en nem brugergrænseflade hurtigt gøre ting, som ellers ville have taget meget lang tid og være meget uoverskueligt, hvis man skulle have skrevet det i kodesprog. Den grafiske repræsentation af diverse spilobjekter i relation til hinanden betyder, at man nemt kan se hvordan ens spil skrider fremad. Selve Unity s interface kan man se på det ovenstående billede. Som man kan se har vi delt den op i 5 dele, nemlig i project window, scene view, hierachy window, inspector window og Toolbar. I Project vinduet kan man se ens bibliotek, altså der hvor alle ens spites, scrips og andre dele til ens projekt ligger. Dem kan man dermed let overskue hvor de er. I Scene view kan man visuelt se det man laver, og her giver Unity en lov til at navigere og redigere i ens baner/scener. Derudover har man også mulighed for at se det i 2D og 3D alt afhængig af om det et 2D eller 3D spil. I Hierarki vinduet kan man se hvordan hver af objekterne er bygget op hierarkisk i den enkelte scene, dermed afslører hierarkiet også hvordan objekterne er fastgjort til hinanden. I Inspector vinduet kan man se og redigere i et markeret objekts egenskaber. Disse egenskaber varierer dog, da der er forskel på objekterne. 11

13 Den sidste del er Toolbaren. Den giver en adgang til de mest væsentlige funktioner i programmering. Den venstre del af toolbaren indeholder de grundlæggende værktøjer til at lave en scene visning af det objekt man arbejder med. Knapperne i midten er til at afspille, spole og pause den scene man er i gang med afspille. Den højre del af toolbaren består af en account knap hvor man kan se sin unity bruger. Derudover er der to layout knapper som ændrer opsætning i programmet Tiled Tiled er et værktøj vi har brugt i den sene ende af projektet, til at lave levels til vores spil med. Det fungerer ved at man vælger en størrelse på det kort man vil lave, hvor man så får det antal tiles til at at lave banen på. Hvis man f.eks. valgte et 32 x 32 kort, ville det blive 32 tiles bredt og langt. På disse tiles kan man så lægge et gulv eller sætte objekter/sprites. I Tiled er det også muligt at lave collision bokse, der gør at man ikke kan gå igennem objekter, såsom vægge eller træer Tiled2Unity Tiled2Unity er et program der automatisk eksporterer baner lavet i Tiled til ens Unity projekter. Dette vil blive lagt ind i Unity som et objekt. 12

14 2.3.4 Beepbox Til at lave musik til spillet, har vi valgt at bruge Beepbox. Beepbox er et gratis online musikprogram, der kan bruges til at lave 8 bit musik. Beepbox fungerer ved at man laver mønstre der så spiller en lyd, hvor man her kan afspille 4 forskellige samtidig. De nummererede bokse i bunden kan man ændre nummer, hvor der så vil blive spillet en anden melodi, efter hvad for et mønster man laver i dem. Den lilla oval afgør hvilken del af sangen som bliver spiller. Det er også muligt at bestemme i hvilken tone der bliver spillet i, samt hvor hurtigt det bliver afspillet Sonic Pi Udover at lave en slags træk og slip musik. Så har vi også valgt at programmer en melodi til vores start menu. Til brugte vi Sonic Pi. Sonic Pi er et open source programmeringsmiljø, som er det designet til at skabe nye lyde, ved at live kode det. Sonic Pi blev udviklet af Dr. Sam Aaron ved University of Cambridge. Den egentlig grund til han valgte at udvikle programmet var fordi han manglede noget software han kunne bruge til at kode musik live til sit band. Grunden til det blev til et open source program var fordi Dr. Sam Aaron mente at den kunne hjælpe en til at forstå de grundlæggende principper inde for programmering af egen musik. 13

15 Dette er Sonic Pi interface, det er bygget op af fire hovedbokse. Den første er er den boks jeg har kaldt for programmerings panelet. Det her man programmere programmet. Boksen til højre (også kaldt logbog over afspilningen). Her kan man holde øje med hvordan ens program bliver afspillet. Den tredje boks ned i venstre hjørne (hjælpe dokumenter). Her har man forskellige tutorial til forskellige dele funktionen i sonic pi. Den sidste boks er den jeg har kaldt for fejl boksen, det er her der kommer til at står noget hvis der er skrevet noget forkert i koden. Derudover har man forskellige andre mulighed. Man kan blandt andet lave 10 forskellige sange og have overblik over dem. Hver sang kaldes også for buffer 0 (fra 0 op til 10). Derudover har man forskellige muligheder oppe i toppen af programmet. Man kan blandt andet afspille programmet og stoppe afspilningen. Derudover kan man gemme koderne, hvis man derimod gerne lave en melodi fil udaf det skal man bruge knappen som hedder Rec. Her optager man sangen og ud fra det får man en WAV fil som man kan afspille og bruge til vores spil. Den sidste knapper man skal have styr på er dem op i højre hjørne. Her kan vi zoome ind og ud på vores koder, for at skabe noget overblik. 14

16 3.0 Iterationer Nu ved vi hvilke værktøjer vi har tænkt os at bruge, så vi kan derfor begive os videre til at starte vores iterationsproces. Denne proces er delt op i 3 faser; første, anden og tredje iteration, hvor man følger spillets udvikling imens at vi bygger videre på spillet/produktet. Derudover, er der bestemte underpunkter vi gennemgår for hver iteration. Her starter man med at planlægge hvad der skal nås og laves for iterationen. Derefter gennemgås nyt design (af sprites, musik el.lign.), samt implementeringen af dette og hvorledes det anvendes i samarbejde med evt. koder/scripts. Efterfølgende skal de nye features testes og vurderes. Til sidst en kort gennemgang af hvad vi vil videreudvikle til næste iteration. 3.1 Første Iteration Planlægning Målet med vores første iteration er at få implementeret vores sprites i unity. Derudover vil vi gerne have den til at kunne skifte mellem de forskellige sprites. Så når den går til højre bruger den spriten til højre og omvendt. Derudover vil vi også gerne kunne styre vores karakter rundt Design Som tidligere beskrevet, så startede vi med at designe vores karakter. Ud fra den, designede vi flere forskellige mellem sprites, der havde til formål at skabe en gå animation. På billedet til højre kan man se vores basis sprites i venstre halvdel af billedet, stående på en række over hinanden. Det vi har lavet flere sprites til denne basis vi havde, således at vi kan skabe en gå animation for vores karakter i spillet. Vi satte vores sprites op i et skema i Paint.NET, såfremt at vi kunne få unity til at aflæse dette sprite sheet, og placere sprites i den rækkefølge vi ønsker. Denne rækkefølge kan ses på billedet nedenfor. Herefter programmerede vi styring til billederne og hvad som sker når man styrer karakteren i forskellige retninger. Nedenfor kan man se hvordan vores spiller ser ud når den går til højre, venstre, op og ned. 15

17 3.1.3 Implementering Vi har nu designet for vores karakter på plads, så nu skal de have tilføjet egenskaber og justeres. Nu skal vi give vores karakter en animation i hver retning (op, ned, venstre og højre), således at den bliver mere livlig. Til dette har vi besluttet at bruge W, A, S og D tasterne på tastaturet, til at fungere som piletaster for karakterens kontrol. På billedet herunder ses der et bevægelses diagram for gå animationer af vores karakter. Måden dette fungerer på er at man har 3 forskellige aktiviteter. Den første aktivitet er loading af vores idle sprites (karakteren er inaktiv), derefter vil der blive aktiveret en animation (gå animation), hvor der efterfølgende tjekkes for om der skal foretages et loop af animationen. Derudover er der også transitions (de hvide pile der forbinder de forskellige komponenter). Disse hjælper med at skabe en overgang for når man skifter retning. F.eks. går man imod højre og skifter til at gå opad, her vil diagrammet gå ind og udvælge hvilken sprite den skal lave en overgang til. I dette tilfælde vil den skifte til spriten der går opad, samt dens animation. Dette er ens for hver side af vores karakter (op, ned, venstre, højre). Sprites for disse sider kan ses herunder: Hver af disse sider har en idle tilstand hvorledes at spillet kun loader vores idle sprites, hvilket vil sige at når karakteren er inaktiv og ingen aktioner aktiveres. Derefter blev der tilføjet til alle siderne, en kommando der sagde at: Hvis en vilkårlig knap trykkes, vil spriten til den gældende side, aktivere en animation. 16

18 Denne animation har vi selv lavet via unity s animation værktøj, og de tidligere sprites, som vi lavede. Billedet nedenunder viser 5 sprites i en bestemt rækkefølge, der tilsammen skaber en gå animation, for når vores karakter går mod venstre. Her ses det at denne animation strækker sig over 0,12 sekunder, hvor vi har tilføjet at den skal lave et loop af denne animation. Kort sagt betyder det at så længe man trykker på den angivne knap (som i dette tilfælde vil være A tasten på tastaturet), vil dette loop fortsætte. Til vores animation af vores karakter, har vi tilhørende script, der styrer hvilke knapper der styrer hvilke sprites. F.eks. vil knappen A kontrollere de sprites der går imod venstre, lige såvel vil knappen D, styre de sprites der går imod højre, osv. Det dette script gør er, at den specificere kommandoerne der bliver givet gennem de 4 knapper (W, A, S, D). Alle vores scripts er lavet i C#Sharp. Til at starte med, så begynder alle Unity s C#Sharp script med: using UnityEngine; using System.Collections; Dette er til for at scriptet loader Unity s kommandoer og værktøjer. public class PlayerAnimation : MonoBehaviour { public Animator anim; void Start () { anim = GetComponent<Animator>(); Det ovenstående henter dataen fra vores bevægelses diagram, aht. hvorledes de 4 knapper er forbundet med hinanden via de hvide pile. 17

19 void Update () { if(input.getkey (KeyCode.A)) { anim.setbool("left", true ); anim.setbool("right", false ); anim.setbool("down",false); anim.setbool("up",false); I koden ovenfor har vi en kommando: Input.GetKey, hvilket inddrager en vilkårlig knap, som vi har sat til at være A. Denne knap bliver forbundet til de animationer vi havde lavet tidligere, som var kaldet Left, Right, Down og Up. Her udelukker man egentligt bare de andre animationer, udover den man gerne vil bruge på knappen. Dette betyder at når Left er true, og Right (såvel de andre retninger) er false, så udelukker man de andre animationer, således at den ønskede retning/animation er blevet specificeret. I koden nedenfor tilføjer man gå animationerne, ved at sige: Hvis knappen A er aktiv, så vil WalkLeft blive aktiveret. Hvis knappen A ikke er aktiv, så vil WalkLeft ikke blive aktiveret. WalkLeft er navnet på den animation (/serie af sprites) der sker, når man går imod venstre. if (Input.GetKey (KeyCode.A)) { anim.setbool (" WalkLeft ", true ); else { anim.setbool (" WalkLeft ", false ); Dette sørger for at aktivere den animation der hedder WalkLeft. Disse linjer kode er ens for alle retninger, da de følger samme princip, dog skal navnene i koden ændres til den rigtige animation. Eks. if (Input.GetKey (KeyCode. A ) = if (Input.GetKey (KeyCode. D ) Eller: anim.setbool (" WalkRight ", false ) = anim.setbool (" WalkRight ", false ) 18

20 Nu er animationerne på plads, hvilket betyder at vi nu kun mangler at tilføje et par linjer kode (et script) der gør karakteren istand til at bevæge op og ned af x og y akserne i spillet. public class PlayerMovement1 : MonoBehaviour { public float speed; void Update () { if(input.getkey (KeyCode.D)) { transform.translate (Vector2.right * speed); Ovenfor ser vi koden for bevægelse. Til at starte med skriver vi: public class, for at vi kan vedhæfte scriptet til et objekt i spillet, hvilket i dette tilfælde er vores karakter. Her bruger vi samme princip som før, hvor vi vælger en Key /tast, som i dette tilfælde er D. Til denne tast tilføjer vi en bevægelse der hedder Vector2.right * speed. Dette betyder at når vi trykker på knappen D, så vil vi bevæge os mod højre (right), i en bestemt hastighed der kan reguleres inde i Unity s spilindstillinger. Til sidst indstillede vi hvordan vores kamera skulle bruges. Vi valgte at kameraet skulle følge spilleren, frem for at det evt. kunne se hele banen på en gang. Men for at justere kameraet, blev vi nødt til at skrive en kort kode, der indstillede det til at følge spilleren. Koden ses herunder: Transform target; void Start () { target = GameObject.Find ("Player").transform; I den første del af koden, skriver vi at kameraet skal finde GameObject Player. Dette er vores karakter. På denne måde låses kameraet fast på vores karakter, og følger den uanset om hvor den går hen. void Update () { 0, 10); transform.position = target.position + new Vector3 (0, Den sidste del af denne kode er til for at centralisere spilleren i kameraets midte. Dette ses i de koordinater der indtastet i slutningen kodelinjen (0, 0, 10). Herudover kan det også ses i transform.position, hvorledes at vi siger at vi gerne vil ændre hvordan kameraet sidder. 19

21 3.1.4 Test Målet med første iteration var at vi skulle gøre vores karakter i stand til at kunne bevæge sig i de 4 givne retninger, og have animationer tilhørende til disse retninger. Der blev testet på dette hele tiden under udviklingsprocessen, men i sidste ende lykkedes det at få koden til at virke. Problemerne vi var stødt på, havde noget at gøre med hvordan vores animationer var forbundet med hinanden. Her kunne man f.eks. trykke på A og bevæge sig mod venstre, men have animationerne fra dem der gik opad. Dette problem er blevet løst, og vi kan fortsætte Videreudvikling Til næste iteration skal vi rette fejlen, så figuren får en mere flydende bevægelse. Derudover skal vi have lavet en bane som vores figur skal styres rundt på. Vi skal også finde ud af hvordan man laver vægge som man ikke kan gå igennem, men som man godt kan gå foran og bagved. 20

22 3.2 Anden Iteration Planlægning I denne iteration skal vi lave alle de punkter vi fremsagde under videreudviklings afsnittet. Derudover vil vi gerne lave en start menu, så vi ikke bare springer direkte ind i spillet. Men for at genopfriske hvad vi sagde i det forrige afsnit om videreudvikling, så vil vi her gerne lave noget musik til vores spil, samt designe og lave nogle redskaber, som vores karakter kan interagere med. Det lavede vi i form af blokke man kunne rykke skubbe rundt i spiller, samt vægge og andre objekter, som man ikke kan gå igennem Design Til disse objekter vores spiller skal kunne intergere med, valgte vi at starte med at lave nogle bokse, hvor på den ene, spilleren kunne rykke rundt, og på den anden, spilleren ikke kunne rykke rundt. Her var den mobile boks lyseblå, og den faste var orange. Disse så således ud (sammenlignet med vores karakter): Disse bokse var meget nemme at tilføje i spillet, da det eneste man skulle var at tilføje et GameObject, hvilket faktisk er en standard mekanisme der oftest anvendes når der skal tilføjes/importeres nye genstande til spillet. 21

23 3.2.3 Implementering Spil Til dette GameObject beskrevet i sidste design afsnit (3.2.2), tilføje vi en sprite til objektet/enheden, hvilket vi gjorde med disse to bokse. Til disse bokse benyttede vi os af Unity s standardkomponenter, som rummer et hav af muligheder. Her benyttede vi os af komponent serien: Physics 2D. I Physics 2D, brugte kun 2 delkomponenter, for at opnå det resultat vi gerne ville have. Disse komponenter var: Box Collider 2D og Rigidbody 2D. Det første komponent, Box Collider 2D, var hvad der bestemte hvornår et objekt ville kollidere med et andet. På de to billeder forneden, kan man se et eksempel for disse 22

24 collision bokse, som er markeret med grønne punkter på boksen. Her kan man justere hvorvidt man ønsker at boksen skal kunne strække. Det andet delkomponent vi tilføjede til disse prototyper af interaktion, var Rigidbody 2D. Dette komponent tillod det gældende objekt, at blive fast/massivt, således at når spilleren gik ind i objektet, ville det rykke sig (spilleren skubber objektet). Derudover kunne man låse denne rigidbody fast til x, y og z akserne, såfremt at spilleren ikke længere ville kunne rykke objektet, men heller ikke passere det. Kort sagt ville objektet fungere som en væg. Vi tilføjede herudover også en startmenu til spillet. Startmenuen bestod af tre knapper; en start knap; options knap og en exit knap. 23

25 Ved at trykke på start knappen blev man sendt videre ind i spillet, og man kan begynde at spille det. På den anden knap Options vil man blive ført videre til hvor man ændre nogle indsillinger for spillet, og ved at trykke på exit vil man lukke spillet. Her ses indstillingerne for play knappen, hvor man bestemmer hvad der skal stå på knappen og hvilken farve den skal have. I bunden bestemmer man hvad der skal ske når man trykker på knappen, hvor det her er sat til at man ved at trykke på knappen, vil loade spillet. Her ses så de samme for exit knappen, hvor det ses at den er rød, og at når man trykker på den vil spillet lukke. Derudover har vi også lavet et script til vores knappers funktioner. Dette script er meget simpelt og vedhæftes som et komponent af objektet ved brug. Det scriptet egentligt gør er helt simpelt at sige at når startknappen bliver trykket på, vil unity loade spil scenen ( in game ). Her er der tale om 2 scener, hvor den ene er startmenuen og hvor den anden er selve spillet. Derudover tilføjer det også en exit funktion til vores røde exit knap. 24

26 Musik Det som er generelt for alt komponering af musik er at man altid skal starte med at finde ud af hvor mange beats der er pr. minut, så man kan definere tempoet i sangen. Desto højere tallet er, jo går sangen. Vi valgte at sætte vores musik til at have 100 bpm (beats per minute). use_bpm 100 Efter vi havde fastsat vores bpm, valgte vi at definere en struktur i vores koder som senere skulle gøre det lettere at programmere, da man har en struktur som er ens for alle koderne. Strukturen blev sådan at når man skulle programmere inden for de forskellige lyde skulle man starte med introen (også kaldt i). Her forekom der et stykke som blev kaldt for a stykket (a), Herefter kommer b stykket(b), tilslut kom c stykket(c). define :structure do i,a,b,c Efter vi havde defineret strukturen for opstillingen af koderne, er det nu tid til at definere rytmen i programmet ved at loope koderne. loop do 1.times { i.call 1.times { a.call 1.times { b.call 1.times { i.call 1.times { a.call 1.times { b.call 1.times { c.call end end Kommandoen in_thread do, gør det muligt at køre flere lyde på en gang. Netop på den baggrund gør vi brug af: in_thread do Nu skal vi vælge den lyd som vi gerne vil programmere i. Det gør vi ved bruge kommandoen use_synth. Den lyd vi valgte var en puls lyd, men det skulle dog ikke være en klassisk puls lyd. Vi valgte at ændre lidt i den, hvilket gjorde vi ved at kalde kommandoen use_synth_defaults, som gør at vi kan ændre i forskellige parameter, som vi kan efterfølgende programmere i. Her bruger vi release kommandoen, som ændrer hvor lang tid tonen lyder. Kommandoen mod_rate er nødvendig at have med for at kunne afspille puls lyde. Den sidste kommando vi gør brug af er amp, som gør det muligt at ændre på lydens lydstyrke. use_synth :pulse use_synth_defaults release: 0.2, mod_rate: 5, amp: 0.6 Når man har programmet hvordan lyden skal lyde, kan man gå i gang med at programmere melodien. Den har vi, som tidligere skrevet, delt op i en intro, et a stykke, et b stykke og et c stykke. Her starter vi med at programmere melodien til introen. Det gør vi ved at definere introen. Det gør vi ved at køre kommandoen play_pattern_timed. Derefter definerer vi tempoet som vi sætter til 0,25 beats pr. lyd. Lydene vi bruger er tonerne d,f og a. Derudover gør vi brug af kommandoen nil som fungerer på samme måde som sleep, der betyder den ikke 25

27 spiller nogen lyd. Vi gør det samme for a,b og c stykket. Til sidst defineres strukturen så den passer med den vi definerede i starten. intro = > { play_pattern_timed([nil,:d5,nil,:f5,nil,:a5,nil; :d5,nil,:f5,nil,:a5,nil,:f5,nil,:d5], [0.25]) theme_a = > {play_pattern_timed([nil,:f5,nil,:a5,nil,:c5,nil, :f5,nil,:a5,nil,:c5,nil,:a5,nil,:f5], [0.25]) theme_b = > {play_pattern_timed([nil,:e5,nil,:g5,nil,:b5,nil, :e5,nil,:g5,nil,:b5,nil,:g5,nil,:e5], [0.25]) theme_c = > { play_pattern_timed([:c5,:c5,nil,:c5,nil,:c5,:d5,nil, :e5,:c5,nil,:a4,:g4,nil,nil,nil, :c5,:c5,nil,:c5,nil,:c5,:d5,:e5, nil,nil,nil,nil,nil,nil,nil,nil, :c5,:c5,nil,:c5,nil,:c5,:d5,nil, :e5,:c5,nil,:a4,:g4,nil,nil,nil, :e5,:e5,nil,:e5,nil,:c5,:e5,nil, :g5,nil,nil,nil,nil,nil,nil], [0.25]) structure(intro, theme_a, theme_b, theme_c) end Nu gør vi næsten det samme som for lyden pulse. Vi gør dog brug af en anden lyd kaldet beep. Når vi har kaldt den lyd. Laver ændre vi lidt på den oprindelig lyd ved at kommanden use_synth_defaults. Det første vi laver om på attacken. Det den gør at den holder tonen så jo højere det tal desto længere tid varer tonerne. Det næste vi laver om på er sustain. Det giver lidt sig selv hvad den gør den opretholder tonen. Den sætter vi lavt, for vi vil gerne have korte toner. Den sidste funktion release, gør at tonen bliver lysere. Derfor sætter vi den til 0,0 så den er derfor dybere end normalt. Herefter kører vi de samme koder/lyde som i del et. in_thread do use_synth :beep use_synth_defaults attack: 0.0, sustain: 0.05, release: 0.0 intro = > { play_pattern_timed([nil,:d5,nil,:f5,nil,:a5,nil, :d5,nil,:f5,nil,:a5,nil,:f5,nil,:d5], [0.25]) theme_a = > { play_pattern_timed([nil,:f5,nil,:a5,nil,:c5,nil, :f5,nil,:a5,nil,:c5,nil,:a5,nil,:f5], [0.25]) theme_b = > { play_pattern_timed([nil,:e5,nil,:g5,nil,:b5,nil, :e5,nil,:g5,nil,:b5,nil,:g5,nil,:e5], [0.25]) theme_c = > { play_pattern_timed([:c5,:c5,nil,:c5,nil,:c5,:d5,nil, :e5,:c5,nil,:a4,:g4,nil,nil,nil, 26

28 :c5,:c5,nil,:c5,nil,:c5,:d5,:e5, nil,nil,nil,nil,nil,nil,nil,nil, :c5,:c5,nil,:c5,nil,:c5,:d5,nil, :e5,:c5,nil,:a4,:g4,nil,nil,nil, :e5,:e5,nil,:e5,nil,:c5,:e5,nil, :g5,nil,nil,nil,nil,nil,nil], [0.25]) structure(intro, theme_a, theme_b, theme_c) end in_thread do For at programmere en lyd som kunne lyde som en tromme. Her valgte vi så at bruge lyden cnoise, dog med nogle ændringer. Men disse ændringer er præcist de samme som i beep lyden. Derudover vælger vi kun at spille hver anden tone i forhold til de første to dele. use_synth :cnoise use_synth_defaults attack: 0.0, sustain: 0.05, release: 0.0 intro = > { play_pattern_timed([nil,:d5,nil,nil,nil,:a5,nil, nil,nil,:f5,nil,:a5,nil,:f5,nil,:d5], [0.25]) theme_a = > { play_pattern_timed([nil,:f5,nil,nil,nil,:c5,nil, nil,nil,:a5,nil,:c5,nil,:a5,nil,:f5], [0.25]) theme_b = > { play_pattern_timed([nil,:e5,nil,nil,nil,:b5,nil, nil,nil,:g5,nil,:b5,nil,:g5,nil,:e5], [0.25]) theme_c = > { play_pattern_timed([:c5,:c5,nil,:c5,nil,:c5,:d5,nil, :e5,:c5,nil,:a4,:g4,nil,nil,nil, :c5,:c5,nil,:c5,nil,:c5,:d5,:e5, nil,nil,nil,nil,nil,nil,nil,nil, :c5,:c5,nil,:c5,nil,:c5,:d5,nil, :e5,:c5,nil,:a4,:g4,nil,nil,nil, :e5,:e5,nil,:e5,nil,:c5,:e5,nil, :g5,nil,nil,nil,nil,nil,nil], [0.25]) structure(intro, theme_a, theme_b, theme_c) end Test Her i den anden iteration af produktet, implementerede vi vægge og objekter, der flyttes når man går ind i dem. Her testede vi for at man ikke kunne gå gennem vægge, samt at det var muligt at rykke på objekter ved at have ens karakter til at skubbe dem. Her virkede vores vægge fint og det var muligt for os at rykke bestemte objekter ved at skubbe til dem. Vi testede her også for om musikken vi havde lavet, blev afspillet inde i spillet efter vi havde sat derind. Her blev musikken spillet perfekt. 27

29 3.2.5 Videreudvikling Til den endelige iteration skal vi have lavet baner, og lave en ny funktion som f.eks. enten fjender eller plader på jorden, der gør at man kan teleportere (warpe) fra plade til plade. Vi skal også have lavet vores menu skærm til den sidste iteration. 3.3 Tredje Iteration (endeligt produkt) Planlægning I denne sidste iteration, skal vi have lavet 2 baner som vores karakter skal klare sig igennem. Vi skal også have implementeret en funktion, der gør at man ved at træde på en bestemt tile, vil man blive transporteret til en tilsvarende tile, hvor man så også kan gå tilbage igen Design Level 1 I denne fase tog vi udgangspunkt i vores rough fra tidligere. Ud fra den lavede vi nogle træer, så man fik stemningen af at man gik i en skov som man skulle finde den rigtige vej igennem. Denne skov består primært af en mørkeblå farve. Farverne til dette level blev inspireret af vores karakters design, da den primært bestod af mørke farver, dog ville vi gerne skabe en kontrast mellem vores spiller og banen man spillede på, fordi det dermed ville blive nemmere at se hvor man befandt sig. Da karakteren bestod af en mørkerød farve, mente vi at det ville være passende at anvende en mørkeblå farve til det første level. 28

30 Disse mørkeblå farver blev vist igennem de sprites vi havde lavet til dette level. Her lavede vi sprites til en sti, som spilleren skulle følge, for at komme videre i spillet. Derudover lavede vi 2 forskellige designs af træer for (som sagt tidligere) for at skabe følelsen af at man befandt sig i en skov. Her var det ene design lyserødt og grønt, og det andet var bare en omfarvning til lyseblå og lilla. Træerne fik lyse farver, da det ville være lidt kedeligt at spiller et helt mørkt spil, derfor hjælper de med at kompensere. Ovenfor ses en liste over alle de sprites der er blevet anvendt i det første level. Alle de blå firkantede sprites har samme funktion, men har forskelligt udseende, for at spillet ikke bliver for ensartet og kedeligt Level 2 Da vi havde lavet designet for det første level, tænkte vi at vi gerne ville have endnu et level i spillet, som var lidt mere kompliceret. Dog fulgte vi stadig temaet af en blå bane, som stod i kontrast til karakteren. Designet af dette level var bygget op omkring et labyrint koncept, hvor spilleren skulle finde vej ind til midten af denne labyrint. Designet af denne ses herunder: 29

31 Denne labyrint er dog ikke nogen almindelig labyrint som man f.eks. har set bag på morgenmadspakkerne, men en labyrint der warper (transporterer) spilleren rundt til de forskellige rum. Hvert rum, udover start og slutrummet, har 4 platforme der skal transportere spilleren hen til en et andet rum. Dette vil blive uddybet yderligere i punkt Nedenfor ses alle de sprites som vi anvendte i dette level. Her kan man også se navnene på spritesne, som skulle hjælpe med vide hvor hvilke sprites skulle placeres hvor Room (House) Når man først kom ind i spillet, skulle vi have et sted hvor man startede, og her tænkte vi at man starter i eget hus. Selve huset har meget lyse farver, der giver en hjemlig følelse, for at få en til at føle det er et sikkert sted. 30

32 Her kan tydeligt de ses på væggene at man befinder sig inde i en bygning. Der er også gulvtæppe. borde og en måtte hvor der står HOME SWEET HOME, hvilket alle indikerer at man er inde i et hus. Nedenfor ses de sprites der blev brugt i husets design. Nogle af disse sprites havde vi lavet flere design til, hvor der dog kun var meget små forskelle. 31

33 3.3.3 Implementering Nu når alt designet og musikken var på plads, så var det på tide at implementere det i vores spil, med de rigtige funktioner og komponenter Spil Til implementering af de 2 levels og det ene rum, i Unity, brugte vi et program kaldet Tiled. Dette program gjorde os istand til at (som sagt i punkt 2.3.2) designe levels på en nem, hurtig og simpel måde. Vi tog helt simpelt bare vores sprites fra da vi lavede designet, og lagde dem ind i Tiled. Helt simpelt overførte man helt basiske.png filer (sprites/billeder) over i programmet, hvor der herefter blev lavet en lille mappe, der indeholder disse sprites. Herfra kunne man bare klikke på den ønskede man gerne vil placere, og plotte dem ind på det canvas man har opsat. Herinde kunne man også give bestemte tiles forskellige funktioner, der senere vil kunne bliver konverteret over i Unity. Her var det primært Collisions vi tilføje til forskellige blokke i Tiled. Som det kan ses på billedet herunder, har vi her tilføjet en collision til en rød blok, dvs. at når denne blok konverteres over i Unity, så vil spilleren ikke kunne passere denne blok, da den vil fungere som et fast objekt. 32

34 Disse røde tiles (sprites) er blevet placeret i layers, bagved det terræn vi har lavet, dvs. de 2 blå levels. Nedenfor ses et billede af det første level, men som det fremgår, kan man se en masse lysegrønne bokse rundt omkring diverse objekter (typisk træer og kanten af banen). Disse grønne bokse, er de selvsamme som blev anvendt i punkt , hvilket betyder at de fungere som objekter i spillet, som spilleren kan collide (sammenstøde) med. I level 2 lavede vi et nyt script, der gjorde os istand til at flytte karakteren rundt, når den ramte et bestemt objekt. Dette anvendte vi meget i specielt dette level, dog blev det også anvendt som en overgang til de andre levels. På billedet af level 2 herunder, ses vores platforme (som forklaret tidligere i afsnit ) kunne transportere/teleportere spilleren rundt til de forskellige rum. Vi har anbragt bogstaver på disse platforme for at vise sammenhængen mellem hvor man blev teleporteret hen. 33

35 I spillet kommer man fra level 1 s top højre hjørne, til bund rummet med én platform, med bogstavet A. Her kan de ses at i det nederste højre hjørne står der endnu et A, dette indikerer hvor man bliver teleporteret hen. Dette gælder selvfølgelig også for de andre bogstaver og platforme. Målet er nå ind til midterrummet, hvor der står et E. Koden bag denne teleportations funktion ses herunder. using UnityEngine; using System.Collections; Som altid starter alle koder med dette, da det er til for at scriptet kan loade bestemte dele af Unity s værktøjer. public class Warp : MonoBehaviour { public Transform warptarget; void OnTriggerEnter2D (Collider2D other) { Her indstiller vi collider indstillingen for et objekt, til at warpe til et target, dvs. en nye destination, som man selv udvælger. Debug.Log ("An object Collided"); other.gameobject.transform.position = warptarget.position; 34

36 Dette er så koden for vores target, punktet for hvor et andet objekt vil blive teleporteret/warpet hen. Dette script skal man bare tilføje til et GameObjekt, som et komponent, for at ændre typen af collider boksen. Kort sagt betyder dette at når spilleren collider med denne boks, som er blevet indstillet til at warpe af vores warp script, vil blive teleporteret fra punkt A til punkt B Musik For at implementere musikken i spillet, kan man bruge en funktion fra Unity, hvor man kan afspille baggrundslyde i spillet. Her brugte vi den 3. sang vi havde lavet, da vi syntes det var den sang der passede bedst i de baner vi havde lavet. For at få spillet til at spille baggrundslyde, gik vi ind i Unitys SoundManager, og lagde MP3 lydfilen ind. På billedet til højre kan så se hvordan man kan kalibrere lyden, bestemme lydniveau osv. Her er nogle bokse vi har valgt til, hvilket Play On Awake og Loop. Play On Awake gør at når man er forbi startskærmen, og man kommer ind spillet, vil den sang man har valgt blive afspillet. Loop gør at når sangen er færdig, vil den blive spillet forfra Test For vores endelige produkt fik vi nogle fra klassen til at prøve spillet. Her skulle vi teste de levels vi havde designet. Da det første level kun består af at man skal bevæge sig fra punkt a til punkt b, klarede alle dette level nemt. I det næste level, hvor man kunne warpe rundt ved at træde på bestemte plader på jorden, tog det længere tid for testpersonerne at komme igennem levelet, men det lykkedes dog alle at klare det. Her blev der ikke fundet nogle problemer med styring eller lignende. 35

37 3.3.5 Videreudvikling For videreudvikling på spillet, ville vi lave flere levels, hvor der muligvis ville være nye funktioner. Disse nye funktioner kunne f.eks. yderligere controls, som at kunne løbe, samle ting op, eller der kunne være fjender, som man skulle finde en måde at undgå på. 4.0 Licens Til vores spil skal vi vælge en licens, for at bestemme om der kan videreudvikles på det, og om det må blive brugt kommercielt. Vi vil her kigge på to forskellige licenser, og bestemme os for en af dem, ud fra hvilke fordele og ulemper de har. 4.1 Kreditering DelPåSammeVilkår CC BY SA Licens Denne licens tillader andre at bearbejde, ændre og udbygge på ens værk til kommercielle formål, så længe de krediterer en og benytter samme licens til det afledte værk. Alle nye værker der er baseret på ens værk, vil også have samme licens og kan altså bruges til kommerciel brug Fordele Da denne licens tillader andre at bearbejde vores værk, er der andre der kan videreudvikle på vores værk, og gøre spillet længere og muligvis forbedre det Ulemper Da det var i vores problem at unge bruger for mange på spil, er det selvfølgelig en ulempe at andre kan tage penge for deres afledte værker. 4.2 Kreditering IkkeKommerciel DelPåSammeVilkår CC BY NC SA Licens Denne licens lader andre ændre og bygge videre på ens værk, så længe det er ikke kommercielt og de husker at kreditere en, samt at de licenserer afledte værker under samme vilkår Fordele Denne licens tillader ligesom den anden for andre at bearbejde ens værk, hvilket vil gøre det muligt for at andre at forbedre spillet, samt at give spillet en længere spilletid. Her er det heller ikke tilladt for andre at bruge de afledte værker til kommerciel brug, hvilket stemmer overens med vores problem. 36

38 4.2.2 Ulemper Da afledte værker af vores spil ikke må bruges kommercielt, vil der være en mindre interesse for at arbejde videre på spillet. 4.3 Vores licens På baggrund af de to licensers fordele og ulemper, har vi besluttet at anvende licensen: Kreditering IkkeKommerciel DelPåSammeVilkår CC BY NC SA Licens. Dette valg er baseret på at det skal være muligt at forbedre og gøre spillet længere, samt at, da vores problem var at unge bruger for mange penge på spil, skal spillet ikke koste noget. Hvis vi sætter et licensmærke på spillet, vil det så se ud som foroven. 5.0 Konklusion Vi lavede et gratis spil da vores problem er at der mange unge, der nutildags bruger for mange penge på spil. Her havde først en stor målgruppe på 8 til 16 år, som vi senere indsnævrede til dem er i 14 års alderen. Vi kom med tre forslag til forskellige spiltyper, hvor vi endte med at beslutte os for at lave et strategi spil. Til at lave spillet brugte vi gameenginen Unity, samt Tiled til at lave banerne i vores spil. Til musik benyttede vi Beepbox og Sonic Pi. Til udviklingen af vores spil gennemgik vi 3 iterationer, hvor vi i den første iteration gjorde det muligt for os at gå rundt. I den 2. iteration lavede vægge og gjorde det muligt at flytte bestemte objekter ved at gå ind i dem. I den sidste og tredje iteration implementerede vi musikken i spillet, og derefter lavede vi levels og implementerede en ny funktion. Det spil vi fik lavet overholdte alle de Need To Have userstories vi havde sat, men der var et Nice To Have Userstory, vi ikke fik implementeret; at man skulle kunne ændre sværhedsgraden, hvilket heller ville give i den form for spil vi har lavet. Efter vi havde lavet produktet valgte vi også en licens til det, hvis vi havde tænkt at publicere det. Her valgte vi en licens der gør man arbejde videre på spillet, så længe man ikke tager for det. 37