Roskilde Universitet Forår First Person Shooter. Datalogi 4. Semester. Forfatter: Jeppe Emil Nygaard Vejleder: Henning Christiansen

Transkript

1 Roskilde Universitet Forår 2015 First Person Shooter Datalogi 4. Semester Forfatter: Jeppe Emil Nygaard Vejleder: Henning Christiansen

2 Abstract This project investigates how programming 3D works in java, from the point of view of making a firstpersonshooter game. It explores how 3D programming is coded from scratch, what mathematics is needed and how it is all rendered to the computer screen. There is created a small 3D world, in which you can use the keyboard to move around. The project explains how this is coded, and how the mathematics works in Java. Furthermore the project discuss how 3D programming in java and an existing 3Dengine like Unity, is different. What the game might have looked like, if a different tool was used to do the programming. 2

3 Indhold Abstract... 2 Indledning og Motivation... 4 Problemformulering... 5 Afgrænsning Programmerings værktøjer JAVA JAVA JDK JAVA IDE Benyttede biblioteker Programanalyse Design af en 3D verden D Programspecifikation og mål Hvad skal programmet kunne? Vindue Pixels D Effekt Rotation Bevægelse Udseende Implementering af mål Opbygning Ramme Spil Brugerkontrol Kontrol Render

4 3.3.7 Render3D Skærm Spillets udseende Test af programmet Diskussion Konklusion Videreudvikling Referencer Internetsider: Litteratur Andre Ressourcer: Appendix Koden til Programmet Indledning og Motivation Nogle af de mest populære computerspil der udviklet til dato, har taget udgangspunkt i First-Person, synsvinklen. Spilleren vil styre sin karakter rundt i en 3D verden og se verdenen fra et førstepersons perspektiv. Målet med spillene er forskelligt, men de mest populære spil er ud fra en krigssituation, hvor to hold spiller mod hinanden med udgangspunkt i at slå modstanderholdet ihjel. Eksempelvis anslår man at Counter-Strike, har solgt op mod 4.2 mio. kopier, og antallet af spillere har sandsynligvis været højere (WEB1). Hvordan er et sådant spil udviklet, og hvad er nødvendigt for at lave en 3D verden i JAVA? Dette projekt vil omhandle udvikling af en 3D verden, som fundament til et First-Person-Shooter spil, i stil med Counter-Strike. Projektet vil tage udgangspunkt i udviklingen af 3D verdenen, og styringen rundt i denne. 4

5 Problemformulering Hvordan programmeres 3D i JAVA, og hvordan kan man styre en karakter rundt i en 3D verden? Afgrænsning Projektet afgrænser sig til udelukkende at udvikle en 3D verden, der kan styres rundt i ved brug af tastatur og mus. Grundet projekts ressourcemæssige begrænsninger, vil der kun være fokus på at udvikle et meget begrænset forstadie til en 3D verden. Der vil være fokus på at kunne bevæge sig rundt i en verden, men uden detaljeret grafiske komponenter. 2. Programmerings værktøjer I dette afsnit vil der blive beskrevet de teoretiske værktøjer, der er brugt for at udvikle koden til programmet. Der er programmeret i JAVA og der er brugt Eclipse, som IDE (Integrated development environment). Nedenfor vil blive beskrevet mulighederne ved JAVA og dets udviklingsværktøjer. Der vil ydermere blive beskrevet alle de JAVA værktøjer brugt i programmet og senere hvordan disse er brugt i specifikt i programmet. I opgaven er benyttet to bøger, som baggrund for programmeringen. Ingen af vil der direkte refereret til, men bagvedliggende viden om programmering, er dannet på baggrund af disse (Se litteraturliste). 2.1JAVA Java er ét programmeringssprog ud af mange, men et højt udviklet sprog. Javas fordel ligger i de næsten uendelige biblioteker af værktøjer, add-inns og extension, som kan bruges til næsten hvad som helst. Java er et objektorienteret sprog, hvilket betyder at koden udtænkes fra ideen om at bygge alt op i objekter, der så kan samles. Disse objekter er så inddelt i klasser, der kan tænkes som kasser der kan indeholder mange objekter. I disse kasser sættes metoder (funktioner) op, som bestemmer reglerne for hvordan objekterne opfører sig. Man kan tænke på opbygningen, som en slags afspejling 5

6 af den virkelige verden, i dette tilfælde en vilkårlig krigssituation. Her vil der så være en række faktorer der er vigtige for at gengive denne situation, herunder; Spillere, skydevåben, baner etc. Disse er alle gengivet i forskelligt niveau af detaljering, og har alle forskellig betydning i programmet JAVA JDK Java development kit eller udviklingsværktøjet for Java, er den grundlæggende udviklingspakke. Denne indeholder værktøjerne til at udvikle og programmere i Java, herunder; biblioteker, en archiver, en compiler og andre værktøjer JAVA IDE Et IDE eller Integrated development environment, er i virkeligheden en udvikling af JDK. Det er en Java applikation, til at skrive i Java og tilbyder brugeren at samle udviklingen i et simpelt Graphical user interface (GUI). Det kan bruges til at skrive direkte i Java, og har en indbygget compiler, debugger og executioner. Det valgte IDE i dette projekt er Eclipse. Dette fordi det tilbyder de nødvendige værktøjer i et simpelt og nemt GUI. Det er primært udviklet til at kode grafik, og derfor er det også glimrende til at udvikle spil Benyttede biblioteker I dette projekt er der benyttet nogle biblioteker, som har været nødvendige for at programmet virker, herunder; 1. Java.math Dette er et bibliotek som tilbyder forskellige matematiske funktioner. Disse bruges til at fungerer primært som en indbygget lommeregner, der kan hjælpe med at sætte programmets algoritmer op. Det kunne eksempelvis være cosinus og sinus, som er brugt i dette projekt. 2. Java.awt AWT eller Abstract Windowing Toolkit. Dette er et bibliotek, som tilbyder en lang række værktøjer til at lave et grafisk interface. Eksempelvis bruges det i dette projekt til at lave et Canvas, eller et lærred, som vil fungere som vinduet til gengivelse af programmet. 6

7 3. Programanalyse Denne del af opgaven vil fokusere på at beskrive de delmål og det samlede mål i opgaven. Derefter hvordan disse er implementeret, eller ikke indfriet. Herunder en beskrivelse af målene, måden de kan opnås på og til sidst en detaljeret beskrivelse af koden i forhold til de mål sat forinden. 3.1 Design af en 3D verden Første en gennemgang af hvad 3D er og hvad 3D grafik indebærer i programmering. Dernæst vil en række mål for opgaven blive gennemgået. 3D For at designe en 3D verden er der en række begreber, der er nødvendige at fastslå. Først er det nødvendigt at forklare hvad der forstås ved 3D, hvad der forstås ved 3D i programmering og til sidst dernæst hvordan 3D kan bruges i spil. 3D er en forkortelse af tredimensionelt og betyder at noget er i tre dimensioner. Dette kan eksempelvis være dybde, bredde og længde, altså tre dimensioner af en verden, i dette tilfælde en geometrisk. Ved programmering bruges også den geometriske 3D verden, da opsætningen af 3D i programmering ville være det samme som at udregne 3D objekter i et koordinatsystem. En computerskærm er som standard todimensionel og derfor er tredimensionel programmering, i virkeligheden en todimensionel optisk illusion af et se tre dimensioner. Ved programmering bruges der typisk 3 koordinater repræsenteret som x (længde), y (bredde) og z (dybde/højde). Disse udregninger visses som en række billeder, gengivet af computeren. Målet med dette er at hvert billede eller frame indeholder så meget information som muligt. Dernæst vises billeder med en hastighed på mellem billeder pr. sekund. Dette for at gengive en illusion af bevægelse, dette kaldes og rendering. Rendering kan sammenlignes med at tage et billede og ved illusionen af bevægelse, vil man ændre perspektivet hvorfra billedet tages, og så tage 60 billeder i sekundet. I 3D spilprogrammering er der en lang række parametre som vil gøre spillet bedre og verdenen flottere. Nogle er vigtige for at andre funktioner fungerer i spillet, andre er kun for visuel forbedring. Eksempelvis vil skygger, vand og røg, ikke umiddelbart kunne bruges til meget andet end at det ser flot ud visuelt. Andre funktioner som refleksioner og lyskilder, vil kunne bruges til at måle afstande og til at tegne billedet. I 3D vil verdenen være opbygget af objekter og en typisk teknik til at bygge en verden i 3D, er polygonteknikken eller vektorgrafik. I denne teknik af 3D programmering bygger man alle objekter op i tredimensionelle figurer, der så sættes sammen til større objekter. Dette er en teknik der oftest 7

8 benyttes til eksempelvis logoer, arkitekttegninger da denne måde at skabe 3D billeder på ikke fylder lige så meget, som andre metoder. En anden måde at lave 3D på i programmering er raytracing, denne metode benytter sig af en omvendt lyseffekt. Hvor normalt vil øjet opfange de lysstråler der sendes fra overflader, og bruge dem til at lave et billede. I programmering tager man udgangspunkt i øjets perspektiv og sender stråler den anden vej, for at opbygge en verden. Strålerne rammer alle pixels på skærmen, og strålerne reflekterer videre og eller absorberes. Programmet følger strålerne, og man kan måle afstand, gennemsigtighed og flere parametre. Billederne vil tegnes ud fra denne teknik. Dette er begge måder at opbygge hvad man kalder 3D engines (maskiner), altså software der kan programmere 3D. Der findes allerede flere højtudviklede 3D engines, da programmering af 3D fra bunden er tidskrævende, og kan er svært. Derfor vil oftest i 3D udvikling, bruges præudviklede engines såsom; Unity og Panda3D, disse har brugervenligt interface, og kan simplificere 3D udviklingen gevaldigt. Målet med dette projekt er dog at udvikle en forsimplet udgave af en 3D engine, selvom spiludvikling ville være nemmere med en eksisterende 3D engine. Projektets mål er at designe grundelementerne til et firstpersonshooter spil, der kan sammenlignes med et eksisterende spil, herunder Counter-strike, HalfLife eller Battlefield. Det skal ikke være nær så kompliceret, men med fokus på de basale elementer. Dog er projektet afgrænset til at starte med at programmere 3D verdenen, hvor spilleren vil kunne bevæge sig rundt i. Det er heller ikke helt ukompliceret og en del skal programmeres, før JAVA vil kunne gengive en oplevelse af 3D. Nedenfor vil specificeres hvad programmet skal kunne og hvilke faser programmets målsætninger er delt op i. 3.2 Programspecifikation og mål Denne del af opgaven vil specificere hvad programmet skal kunne og hvad delmålsætningerne og de endelige målsætninger vil indebære. Dette med hensigt at til sidst at konkludere ud fra disse målsætninger og hvordan de er indfriet. 8

9 3.2.1 Hvad skal programmet kunne? Det klare mål med dette projekt er at lave en basal verden i 3D, hvori man kan bevæge sig rundt med tastaturet. Programmets krav vil være opdelt i en række parametre, der vil prøves at opnås. Disse vil være delmålene for programmet og det samlede mål vil være beskrevet til sidst i denne del af projektet. Parametrene vil være delt op i en rækkefølge af betydning for programmets udfoldelse Vindue I første omgang vil målet være at få et vindue frem med overskriften Skydespil. Dette er for at sætte rammen for spillet. Her vil der kunne bestemmes størrelse af vinduet, og indholdet af spillet vil vises i vinduet Pixels Anden del af programmeringen vil omhandle indholdet af vinduet, her vil de første skridt i grafikken blive taget. Vinduet deles op i en række firkanter (pixels), disse vil blive brugt til at tegne billeder på skærmen, ved at tegne farver i hver enkelt pixel. De vil blive tegnet i programmet, som en funktion af bredde * højde, og firkanterne. Pointen er at bruge vinduet som koordinatsystem, hvor firkanterne tegnes mellem X og Y aksen. Pixels bestemmes af vinduets opløsningsstørrelse, eksempelvis 600*600= pixels eller firkanter D Effekt Tredje del af programmet vil være at få gengivet en 3D effekt af programmet. Her vil der indgå den næste dimension i visningen. Der er allerede bredde og højde, for at få 3D effekten skal der tilføjes dybde. Ved at tilføje dybde i billedet vil man kunne føle en 3D effekt. Dette gøres ved at lave et centrum i billedet, der får billedet til at pege indad. På den måde vil der kunne ses vægge, loft og gulv i billedet Rotation 9

10 For at kunne have tæt på en fuld 3D oplevelse, er det vigtigt at man kan roterer i billedet. Med dette menes at perspektivet kan ændres i billedet. Man skal kunne rotere hele vejen rundt om sig selv. Dette for at brugeren kan bevæge sig realistisk, i alle retninger af billedet. Dette gøres ved at implementerer en Cosinus, Sinus funktion, så en fuld cirkel kan skabes Bevægelse Bevægelse er første skridt i retningen af brugerinteraktion. Her vil der implementeres bevægelse ved brug af tastaturet, målet er at kunne bevæge sig fremad, bagud og til begge sider i billedet. Og til sidst at kunne ændre perspektivet, så brugeren vil kunne bevæge sig i alle retninger, undtaget op og ned Udseende Sidste del af dette projekt vil forsøge at designe et udseende for verdenen. Dette ved at indsætte farver og billeder i de pixels der allerede er gengivet i visningen af programmet. 3.3 Implementering af mål Denne del vil fokusere på de delmål der allerede er sat og hvordan de er implementeret i koden. En detaljeret beskrivelse af koden i forhold til delmålene, de problemer der var med dem, og de valg der er taget i kodningen Opbygning Programmet er indtil videre bygget op i tre pakker og herunder i syv klasser. Det underliggende diagram viser sammenhængen mellem klasserne. 10

11 3.3.2 Ramme Denne klasse ligger i pakken mappen.fps, som er hovedgruppen. Denne er klassen der laver et Canvas, eller det lærred der skal gengive programmet. Denne klasse er rammen for programmet, deraf også navnet, og skal starte, slutte spillet og herudover også tjekke om det kører. Det er i denne klasse der sættes hvor stort skærmbilledet skal være, hvilke dele af spillet af dele der skal starte og i hvilken rækkefølge. 11

12 3.3.3 Spil I denne klasse laves de underliggende spilkonfigurationer der styrer brugerens interaktion med spillet. Indtil videre er der i denne klasse kun bevægelsen i 3D verdenen. Altså kun brugerens bestemmelse af kontrollen i spillet, denne klasse henter bestemmelsen af et Keyevent og rapporterer data videre til ramme, der igen tegner billedet, afhængigt at brugerens synsvinkel. Det er i denne klasse der bestemmes hvilke symboler på tastaturet der betyder hvad, eller hvilke der skal bruges Brugerkontrol I denne klasse laves reglerne for hvad der sker, hvis et Keyevent udfolder sig, altså de data der bruges til at styre hastighed og rotation. Det er selve matematikken for bevægelsen. I denne klasse er der lavet en altså hvilket parameter der skal gøre hvad, når der bruges en tast. Eksempelvis vil der enten lægges til eller trækkes fra x, afhængigt af retningen vi bevæger os i spillet. Der er en relativ simpel måde at bevæge sig på, altså styre hvorfra på aksen i et koordinatsystem vi tegner billedet Kontrol I denne klasse indhentes keyevents og bruges til at forklarer Java, hvordan programmet reagerer på keyevents. Disse bruges som udvidelse og sammenhængende med klassen brugerkontrol og samles i klassen Spil. Opsummerende for de tre ovenstående (Spil, Brugerkontrol og Kontrol), bestemmer spil hvilke taster der skal bruges, i brugerkontrol bestemmer hvad der ske hvis disse taster trykkes og i kontrol henter vi Javafunktionerne, til tastaturkontrol Render I denne klasse laves vores pixels, der bruges til at tegne vores skærmbillede. Dette ved at bede Java tegne et array af små firkanter, der så senere kan bruges til at tegne farverne på skærmbilledet Render3D I denne klasse laves 3D effekten i vores skærmbillede. Denne vil jeg forklare yderligere grundigt, da det er den mest komplicerede klasse. Den indeholder nogle ret komplicerede matematiske konstruktioner, for at få 3D effekten frem. Under er et billede af koden, der ligger til grund for 3D effekten i programmet. 12

13 I denne del af koden er introduceret et parameter i dybde, dybdens funktion vil være at skabe 3D effekten i gengivelsen på skærmen. Det kan ses at den array af pixels der tidligere er lavet, nu består af tre parametre; [x+y*width]. Positionen af kameraet er sat til at være styret af keyboardet, det vil sige at hver gang vi vil fremad vil der enten lægges til eller trækkes fra x, det gør at det viste billede vil ændre sig i forhold til hvor mange gange vi trykker på enten frem eller tilbage. Det samme er sat til y, så man bevæger sig til enten højre eller venstre. Altså er det udgangspunktet for gengivelsen af billedet der ændre sig. For at vise effekten af de beregninger der er lavet, er der lavet det der hedder et bitshift, som laves ved brug af tegnene [&] [<<, dette betyder at vi bestemmer hvilke farver der skal vises og derved kan tydeliggøre visningen af 3D. Hvis ikke denne teknik var brugt, ville billedet se noget anderledes ud. Hvilket jeg vil demonstrerer længere nede under overskriften spillets udseende. Så essentiel er der lavet nogle beregninger, for at lave en tredimensionel verden, der hentes igen og igen. Hver gang vi bevæger os ændrer vi enten x eller y, for at ændre visningen af billedet. 13

14 3.3.8 Skærm I denne klasse tegner vi spillet, og udfører handlingerne fra render. Denne klasse fungerer som en extension af render klassen. Den henter render3d klassen og tegner den på skærmbilledet. 4. Spillets udseende Spillets udseende når programmet er kørt, vil vise en meget simpel 3D verden. Det er et billede der hele tiden tegnes, og ved bevægelse igen tegnes. Billedet er et udklip fra programmet når det kører. Det kan ses at billedet gengiver en række af firkanter som vises fra bunden og toppen af billedet og parallelt ind mod midten, dette er 3D effekten. Det sorte i midten er lavet for at gengive en form for synsbegrænsning, i form af tåge. Dette optimerer både programmets framerate, da der skal tegnes færre pixels og desuden vil det i videreudvikling gengive en realistisk begrænsning af karakterens syn. 14

15 Billedet ovenfor viser at rotationen starter, og 3D billedets form ændre sig. Dette ved at ændre aksen i billedet og tegne billedet fra en anden synsvinkel. Dette billede viser at hele vejen omkring vinduet synsvinkel, derfor kan man ved bevægelse se resten af billedet. Positionen i billedet bestemmer hvordan billedet tegnes. Farverne i billedet er et produkt af 15

16 et bitshift, og ville se anderledes ud, hvis ikke dette var lavet. Det underliggende billede viser os hvordan farverne ville være fordelt, hvis ikke der var lavet et bitshift. Det næste naturlige visuelle skridt i programmet vil være at få tegnet billeder af vores pixels, sådan at himlen eksempelvis er blå med nogle enkelte skyer og at gulvet er genkendeligt. Derudover vil det være meget relevant at få lavet en afgrænsning af verdenen med vægge. Først derefter vil det være relevant at begynde at designe objekter til placering i verdenen. 5. Test af programmet Det er naturligt at teste hvad programmet kan på forskellige måder, for at finde løsninger og ideer til videreudvikling. I den forstand er det første man bør teste, hvad programmet gør i forhold til hvad det skal kunne. Her blev der i starten af projektet sat en række mål for hvad programmet skulle kunne, opsummeret; Skal programmet kunne gengive en simpel 3D verden, hvori man med tastatur kan bevæge sig rundt. 16

17 Programmets afleverede form kan indtil videre opnå målet for at være en simpel 3D verden, hvori man kan bevæge sig rundt med tastatur. Der er opbygget en simpel 3D verden af pixels, der er klar til at blive udvidet. Dog var et mål også at få tegnet billeder af de pixels, eksempelvis at få malet, himlen blå og lavet gulvet i en genkendelig fremstilling. Dette nåede jeg ikke at få færdiggjort, da ressourcerne ikke var til det og det viste sig mere kompliceret end jeg havde forventet. I forbindelse med at optimerer programmet, kan der laves en ret simpel test, der i Eclipse kan køres i realtime (man kan lave ændringer i koden, mens programmet kører). Dette er en FPS (Frames per second) test, der tæller hvor mange billeder der produceret i sekundet. Dette giver en klar indikation af hvor godt programmet kører. Desto flere billeder det kan producere, jo bedre er programmet skruet sammen. I bund og grund handler det om at den mængde data computeren kan fremvise, er begrænset og hvis der er få billeder i sekundet, betyder det at programmet er ulogisk. Altså vil datamængden være for stor. Siden programmet er i sin tidlige fase, vil man kunne forvente at datamængden stiger, hver gang man indsætter flere og mere komplicerede funktioner og derfor skal FPS helst op og ramme over 100 billeder pr. sekund. Dette afhænger selvfølgelig af den computer der bruges til at køre programmet, men jo flere computere der kan bruge programmet jo bedre. Koden til testen ser sådan ud i programmet og er en System.out.println funktion. Testens resultater var mindre gode på min computer, men det skal nævnes at computeren den er kørt på er meget gammel, og ikke så hurtig. Testens resultat er vist nedenfor. 17

18 Det kan se at programmet kan køres med omkring 22 fps. Dette er selvfølgelig langt fra godt nok, og derfor er testen nødvendig at udfører på en bedre computer. Dog skal det nævnes at programmet godt kan køre på lav billedfrekvens, det er i forhold til yderligere udvikling at en bedre frekvens kræves, da yderligere udvikling ofte er parallel med den mængde data computeren skal læse og køre. Computeren testen blev udført på er ældre HP med 2Gb Ram og en 2GH duocore processor. Den næste computer der vil blive udført en FPS test på er en APPLE MacBook, med 4Gb ram og med en 2.5 GigaHertz i5 processor. På denne er resultatet allerede vokset til over 50 fps, hvilket er en betydelig forskel i billedkvalitet og i hastighed. Dette viser at programmet kører som det skal og ved en endnu bedre computer vil resultatet formenligt kun blive bedre. Testene viser os at udgangspunktet for at gå videre med programmeringen er fin, hvis testene havde været dårlige, ville det have været vigtigt at kigge på opbygningen af koden. Logikken i koden er altafgørende for både overskueligheden og udfaldet af programmet. 18

19 6. Diskussion I denne del af opgaven vil to relevante spørgsmål diskuteres, for at sætte projektets proces i perspektiv. Det første spørgsmål som er oplagt at stille er; Hvad kan programmet i forhold til hvad der blev sat af mål? Målet med dette projekt var til at starte med at udvikle et simpelt firstpersonshooter spil, i samme stil som Counter-Strike, helt fra bunden. Alt dette programmeret i Java. Dette mål blev dog grundet ressourcermæssige udfordringer ændret til at udvikle en simpel 3D verden, hvori man kunne implementere simpel tastaturbevægelse. Visionen til hvordan udseendet af 3D verdenen skulle se ud, var fra start at lave en realistisk gengivelse af hus, en have eller noget helt andet, men en verden der var en realistisk gengivelse af noget eksisterende. Denne målsætning kunne ikke indfries, da kompleksiteten af dette udfordrede de ressourcer der var til rådighed. Dette er selvfølgelig skuffende, da dette ville være det første visuelle skridt mod det oprindelige mål og man kunne have vist en designmæssig tilgang til udviklingen af spillet. Det reviderede mål blev alligevel delvist mødt og tests viste at den foreløbige programkode kørte fint i forhold til en FPS test, hvilket er vigtigt for udviklingen af programmet. Det næste spørgsmål som giver mulighed til diskussion er; Hvad havde været anderledes hvis man i stedet har bruget en 3D engine som Unity? For at besvarer dette spørgsmål er det nødvendigt at forstå hvad forskellen på dette projekts indgangsvinkel til kodning er, og hvordan projektets mål kunne have været nået ved at bruge et program som Unity. Dette projekts udgangspunkt lå i at udvikle et computerspil fra bunden, men da ressourcerne ikke var tilstrækkelige, blev dette mål nedjusteret. Der er dog stor forskel på at udvikle en 3D verden i Java og på at udvikle 3D i Unity, som er en eksisterende 3D engine. Unity har allerede al matematikken til at udvikle 3D og derfor er det ikke nødvendigt at skrive de matematiske formler, for visningen af 3D elementer. Dette er selvfølgelig en stor forskel og derfor vil resultatet ved samme ressourcer tilgængelige være radikalt anderledes. Da der allerede er udviklet 3D matematikken i Unity, ville udviklingen være af det specifikke design og ville være mere objektorienteret. Der ville være fokus på at udvikle det visuelle og spillets udformning ville være større fokus, men opgavens udgangspunkt var at programmere det fra 19

20 bunden. Derfor ville det være et forkert valg at bruge en allerede eksisterende 3D engine. Læringsprocessen i at programmere det fra bunden, var den vigtigste faktor i valget af projekt. Afslutningsvis er det vigtigt at understrege at et færdigt spil, med de værktøjer der er blevet valgt at bruge hele tiden været for højt sat. Det har vist sig at være mere kompliceret end først antaget og derfor ændrede opgavens udgangspunkt sig også. 7. Konklusion Projektet startede ud med et mål om at programmere et firstpersonshooter spil fra bunden. Dette mål viste sig urealistisk og forventningerne måtte skrues ned og projektets mål blev nedjusteret til kun at lave en simpel 3D verden hvori bevægelse skulle være muligt med tastaturet. Dette blev indfriet og efter en FPS test, kunne det konkluderes at programmets opbygning var godkendt, da det på en forholdsvis ny computer viste lige over 50 fps. Derved blev det reviderede mål mødt. Problemformuleringen lød hvordan programmeres 3D i JAVA, og hvordan kan man styre en karakter rundt i en 3D verden? Dette viste sig at være mere kompliceret end forventet, da beregninger for 3D er komplicerede i Java og skal kodes fra bunden. 3D billedet blev kodet til at være et uendeligt billedet uden vægge, men med fuld rotation, sådan at bevægelse bagud, fremad, højre og venstre kunne laves. Med bitshift blev 3D effekten fremhævet ved at vise alt i grøn og blåt. Et simpelt 3D billede blev lavet og med nogle nogenlunde simple ændringer i koden, kunne man bruge tastaturet til at ændre perspektivet for billedet. Det havde været interessant at kigge på at få lavet et mere realistisk og kompliceret udseende for 3D verdenen, men dette kunne desværre ikke indfries. Det havde været naturligt at lave vægge, og begynde på at kode objekter som næste skridt for programmet, men grundet tid og andre omstændigheder måtte dette droppes. Programmet endte med at blive så godt som det kunne nå at blive, forventningen om at lave en simpel 3D verden blev mødt. Programmets udgangspunkt lå i at lave det fra bunden i Java, da læringsprocessen for projektet betød en del for valget af emne. Spillet kunne have set meget anderledes ud, havde man valgt at programmere det i en eksisterende 3D engine, såsom Unity. Dette havde frigjort en masse tid, som kunne bruges på at designe 3D verdenen, i stedet for at lave den grundlæggende matematik for den. 20

21 8. Videreudvikling Det næste naturlige skridt i retning af et spil efter den visuelle fremstilling, ville være at kigge på udvikling af objekter. Disse objekter kunne både være træer, sten, kasser etc. og den grafiske udvikling af dem ville være relevant for spillets udseende og design. Dernæst er det interessant at begynde at tænke på spillets opbygning og objektbevægelse, afstandsbedømmelse, skygger, reflekteringen. Det ville være relevant at tænke på at udvikle en raytracing funktion, for at få 3D verdenen til at fungere efter hensigten. Først til sidst ville det rigtige spil begynde at kunne tage form. Der ville skulle udvikles AI (artificial intelligence), multiplayer og spillerinteraktion. Dog er den grafiske del af spillet først, så derfor også den næste del der skal udvikles. 9. Referencer 8.1 Internetsider: WEB 1 Besøgt Brugt som generelt baggrundsinformation om 3D programmering 8.2 Litteratur - Harbour, Jonathan S. (2011); Beginning Java SE 6 Game Programming (3rd Edition), Course Technology / Cengage Learning 21

22 - Sedgewick, Robert. Wayne, Kevin (2006); Introduction to programming in Java, Princeton University 8.3 Andre Ressourcer: Java Runtime Environment or Development Kit: Eclipse IDE: Appendix - Konklusion - Abstract Koden til Programmet Klassen Ramme package mappe.fps; import java.awt.canvas; import java.awt.dimension; import java.awt.graphics; import java.awt.image.bufferstrategy; import java.awt.image.bufferedimage; import java.awt.image.databufferint; import javax.swing.jframe; import mappe.fps.brugerkontrol.kontrol; import mappe.fps.grafik.skærm; public class Ramme extends Canvas implements Runnable { private static final long serialversionuid = 1L; public static final int WIDTH = 800; public static final int HEIGHT = 600; public static final String Titel = "Skydespil"; //titel på spillet, vises i vinduet private Thread thread; private Skærm skærm; private Spil spil; private BufferedImage img; private boolean running = false; 22

23 private int[] pixels; private Kontrol Kontrol; public Ramme() { Dimension size = new Dimension(WIDTH, HEIGHT); setpreferredsize(size); setminimumsize(size); setmaximumsize(size); skærm = new Skærm(WIDTH, HEIGHT); spil = new Spil(); img = new BufferedImage(WIDTH, HEIGHT, BufferedImage.TYPE_INT_RGB); pixels = ((DataBufferInt) img.getraster().getdatabuffer()).getdata(); // Laver en random udfyldning af pixels, ved brug af arrayaet img private void start() { Kontrol = new Kontrol(); // til styringen i spillet, mus + tastatur addkeylistener(kontrol); addfocuslistener(kontrol); addmouselistener(kontrol); addmousemotionlistener(kontrol); if (running) return; running = true; thread = new Thread(this); thread.start(); private void stop() { if (!running) return; running = false; try { thread.join(); catch (Exception e) { e.printstacktrace(); System.exit(0); public void run() { int frames = 0; double unprocessedseconds = 0; long previoustime = System.nanoTime(); double secondspertick = 1 / 60.0; int tickcount = 0; boolean ticked = false; while (running) { long currenttime = System.nanoTime(); long passedtime = currenttime - previoustime; previoustime = currenttime; unprocessedseconds += passedtime / ; while (unprocessedseconds > secondspertick) { tick(); unprocessedseconds -= secondspertick; ticked = true; tickcount++; if (tickcount % 60 == 0) { System.out.println(frames + "FPS");// En Frames per second tæller, der printer FPS 23

24 til optimering af billedet, ved at se hvor mange billeder den kan printe previoustime += 1000; // primært frames = 0; if (ticked) { render(); frames++; render(); frames++; private void tick() { spil.tick(kontrol.key); private void render() { BufferStrategy bs = this.getbufferstrategy(); if (bs == null) { createbufferstrategy(3); return; skærm.render(spil); for (int i = 0; i < WIDTH * HEIGHT; i++) { pixels[i] = skærm.pixels[i]; Graphics g = bs.getdrawgraphics(); g.drawimage(img, 0, 0, WIDTH + 10, HEIGHT + 10, null); g.dispose(); bs.show(); public static void main(string[] args) { Ramme spil = new Ramme(); JFrame vindue = new JFrame(); vindue.add(spil); vindue.pack(); vindue.settitle(titel); vindue.setdefaultcloseoperation(jframe.exit_on_close); vindue.setlocationrelativeto(null); vindue.setresizable(false); vindue.setvisible(true); spil.start(); Klassen Spil package mappe.fps.grafik; import mappe.fps.spil; 24

25 public class Skærm extends Render { private Render3D visning; public Skærm(int width, int height) { super(width, height); visning = new Render3D(width, height); public void render(spil spil) { for (int i = 0; i < width * height; i++) { pixels[i] = 0; visning.gulv(spil); visning.renderdistancelimiter(); draw(visning, 0, 0); Klassen Brugerkontrol package mappe.fps.brugerkontrol; public class Brugerkontrol { public double x, z, y, rotation, xa, za, rotationa; public void tick(boolean fremad, boolean bagud, boolean venstre, boolean højre, boolean drejvenstre, boolean drejhøjre) { double rotationshastighed = 0.025; double gåhastighed = 1; double xfremadbagud = 0; double zhøjrevenstre = 0; if (fremad) { xfremadbagud++; if (bagud) { xfremadbagud--; if (venstre) { zhøjrevenstre--; if (højre) { zhøjrevenstre++; if (drejvenstre) { rotationa -= rotationshastighed; if (drejhøjre) { rotationa += rotationshastighed; * gåhastighed; * gåhastighed; xa += (zhøjrevenstre * Math.cos(rotation) + xfremadbagud * Math.sin(rotation)) za += (xfremadbagud * Math.cos(rotation) - zhøjrevenstre * Math.sin(rotation)) 25

26 x += xa; z += za; xa *= 0.1; za *= 0.1; rotation += rotationa; rotationa *= 0.5; Klassen Kontrol ackage mappe.fps.brugerkontrol; import java.awt.event.focusevent; import java.awt.event.focuslistener; import java.awt.event.keyevent; import java.awt.event.keylistener; import java.awt.event.mouseevent; import java.awt.event.mouselistener; import java.awt.event.mousemotionlistener; public class Kontrol implements KeyListener, FocusListener, MouseListener, MouseMotionListener { public boolean[] key = new public void mousedragged(mouseevent e) public void mousemoved(mouseevent e) public void mouseclicked(mouseevent e) public void mouseentered(mouseevent e) public void mouseexited(mouseevent e) public void mousepressed(mouseevent e) public void mousereleased(mouseevent e) public void focusgained(focusevent e) { 26

27 @Override public void focuslost(focusevent e) { for (int i = 0; i < key.length; i++){ key[i] = public void keypressed(keyevent e) { int keycode = e.getkeycode(); if (keycode > 0 && keycode < key.length) { key[keycode] = public void keyreleased(keyevent e) { int keycode = e.getkeycode (); if (keycode > 0 && keycode < key.length) { key[keycode] = public void keytyped(keyevent e) { Klassen Render package mappe.fps.grafik; public class Render { public final int width; public final int height; public final int[] pixels; public Render(int width, int height) { this.width = width; this.height = height; pixels = new int[width * height]; public void draw(render render, int xoffset, int yoffset) { for (int y = 0; y < render.height; y++) { int ypix = y + yoffset; if (ypix < 0 ypix >= height) { continue; for (int x = 0; x < render.width; x++) { int xpix = x + xoffset; if (xpix < 0 xpix >= width) { continue; 27

28 int alpha = render.pixels[x + y * render.width]; if (alpha > 0) { alpha; pixels[xpix + ypix * width] = Klassen Render3D package mappe.fps.grafik; import mappe.fps.spil; public class Render3D extends Render { public double[] zbuffer; private double renderdistance = 5000; public Render3D(int width, int height) { super(width, height); zbuffer = new double[width * height]; public void gulv(spil spil) { double loftposition = 8; double gulvposition = 8; double fremad = spil.kontrol.z; // double retning = spil.kontrol.x; // double rotation = spil.kontrol.rotation; double cosinus = Math.cos(rotation); double sinus = Math.sin(rotation); for (int y = 0; y < height; y++) { double loft = (y - height / 2.0) / height; double z = gulvposition / loft; // Z Kontrollere dybden i 3D // verdenen if (loft < 0) { z = loftposition / -loft; for at gå for at gå til for (int x = 0; x < width; x++) { double dybde = (x - width / 2.0) / height; dybde *= z; double xx = dybde * cosinus + z * sinus; double yy = z * cosinus - dybde * sinus; int xpix = (int) (xx + retning); // + retning... // frem og tilbage int ypix = (int) (yy + fremad); // + fremad... 28

29 ((ypix & 15) * 16) << 8; // højre og venstre zbuffer[x + y * width] = z; pixels[x + y * width] = ((xpix & 15) * 16) if (z > 500) { pixels[x + y * width] = 0; public void renderdistancelimiter() { for (int i = 0; i < width * height; i++) { int color = pixels[i]; int brightness = (int) (renderdistance / (zbuffer[i])); if (brightness < 0) { brightness = 0; if (brightness > 255) { brightness = 255; int r = (color >> 16) & 0xff; int g = (color >> 8) & 0xff; int b = (color) & 0xff; r = r * brightness / 255; g = g * brightness / 255; b = b * brightness / 255; pixels[i] = r << 16 g << 8 b; Klassen Skærm package mappe.fps.grafik; import mappe.fps.spil; public class Skærm extends Render { private Render3D visning; public Skærm(int width, int height) { super(width, height); visning = new Render3D(width, height); public void render(spil spil) { for (int i = 0; i < width * height; i++) { 29

30 pixels[i] = 0; visning.gulv(spil); visning.renderdistancelimiter(); draw(visning, 0, 0); 30