\chapter{Diskussion}
\begin{intro}
I det følgende vil design og implementering af editoren og spillet blive diskuteret. Desuden vil de valg der er blevet truffet i projektet blive diskuteret.
\end{intro}

\section{Spillet}
Det implementerede spil fungerede ikke som en helhed ved projektets afslutning. Klienten fungerede dog nok til at grundlæggende funktioner kunne testes.

\subsection{Design}
Spillet er designet over et MVC-mønster. Dette har gjort at der er selve spil-logikken er separeret fra f.eks. fremvisning, brugerinteraktion osv.  MVC-mønsteret har vist sig at være meget velegnet til spil, netop p.g.a. seperationen imellem de forskellige dele. Det har bl.a. lettet designet af serveren og klienten. På serveren kan man helt undlade at optegne spillet, uden at det påvirker spillets gang. På klienten kan man uden videre opdatere spillets model, uden at det giver nogle problemer.

Implementationen af View i spillet har også virket meget godt. Det er relativt let at indsætte et nyt view ind i spillet, uden at skulle ændre ved de eksisterende views.

Brugen af en fælles super-klasse for server/klient, til at håndtere hovedparten af netværks-kommunikationen har lettet implementationen af server og klient-kode. Det har ikke krævet mere end nogle få linjes kode at implementere klienten, når den først benyttede sig af den fælles netværkskode.

\subsection{Implementeringen}
I dette afsnit vil det blive vurderet hvorvidt det er lykkedes at implementere spillet tilfredsstillende. Der bliver taget udgangspunkt i kravspecifikationen for klient og server. 

I server delen af spillet er stort set alle kravene blevet opfyldt. Der er dog visse steder implementationen halter. Det primære problen i server implementationen lige er at beskedsystemet ikke fungere. Server kan godt oprette forbindelse via tcp og sende/modtage via udp. Men der er ingen måde at håndtere de besked serveren får vi udp. Det har betydet at det meste af spil-logikken enten ikke er implementeret, eller ikke har været testet. Al den grundlæggende funktionalitet, så som kollision-detektion, indlæsning af baner, og simpel fysik fungerer. Men da man ikke kan spille et egentligt spil er ting som point-givning hverken testet eller implementeret. 

Klienten delen lider under de sammen problemmer som serveren. Den er således heller ikke i stand til at behandle de beskeder den får fra serveren, hvilket i praksis betyder, at den ikke kan modtage informationer om de andre spillere. Det er derfor ikke muligt at spille spillet sammen med andre spillere i øjeblikket. Endvidere er de sorte huller, der er nævnt i gameplay afsnittet ikke blevet implementeret. Disse er blevet undladt p.g.a tidsmangel og ikke fordi det ville være noget større problem at implementere det. Men hen mod slutningen af projektet var det nødvendigt at prioritere nogle ting ned. Da sorte huller ikke var essentiel for hverken klienten eller serverens funktionsevne, men blot var en del, der ville have fremmet spillets gameplay blev det nedprioriteret.

Generelt virker alt på nær netværket i den nuværende implementation af spillet. Dette skyldes hovedsageligt at beskeder ikke virker, men der har også vist sig at være småfejl i selve netværks-koden. Det skal dog bemærkes at der tilsyneladende kun er tale om fejl i programmet, og ikke mangler.

Hvis man overordnet set kal fremhæve noget, der kan betegnes som godt i programmet, kan bl.a. selv designet nævnes. Designet har gjort det det nemt så genbruge kode fra klient på serveren og omvendt. Envidere har de anvendte mønstre, hjulpet med til at spillet er lidt at udvide f.eks. med nye views. Det kan også fremhæves at selve den visuelle del af spillet er blevet vellykket da grafikken på skærmen stemmer overens med det forventede resultat. 

Der er dog også vise elementer i spillet, der ikke fungere så godt som man kunne have håbet. Det gælder bl.a. kollision. Det er i øjeblikket ikke til at afgøre hvilken kant (\texttt{Edge}) man støder sammen med. Dette bevirker at man ikke kan lave realistiske kollisioner. Derudover er der er ikke nogen grafisk brugergrænseflade til spillet, hvilket gør det mindre bruger venligt. Det bevirker også at der er en del ting som f.eks. spillernavn og server adresse, der er fastkodet ind i programmet 

Selvom der er fejl i spillet koden vuderer gruppen dog at det overordnet set er lykkedes at implementere spillet. Største delen af de krav, der er stillet til spillet er blevet opfyldt. Det er da også gruppens vurdering at den fejlbehæftede del samt yderligere brugerorienterede forbedringer vil kunne laves på ca 4 arbejdsdage. 

\section{Editor}
Til spillet blev der udviklet en editor som et hjælpeværktøj til at designe baner. Editoren fungerede tilfredsstillende ved projektets afslutning.

\subsection{Design}
Editoren er lige som serveren udviklet efter MVC-mønsteret. Dette gør editoren let at udvide, hvis det en dag skulle være nødvendigt. Valget at bruge et Strategy-mønster til at håndtere de forskellige tilstande i editoren, har vist sig at være yders fornuftig. Det er enddog meget let at tilføje nye tilstande til editoren. Dog kunne der med fordel være brugt f.eks. Command mønstret \cite{patterns} til menu funktioner.

\subsection{Implementeringen}
Vi har valgt at implementere editoren i Java, bl.a. fordi alle i gruppen på forhånd har et godt kendskab til Java. Dette har vist sig fornuftigt, da det har betydet at editoren på trods af dens mange egenskaber har været meget lettere at implementere end hvis den f.eks. var programmeret i C++. Sprog-valget har samtidigt givet platformsuafhængighed af editoren.

Hvis man ser på editoren med kravspecifikationen for øje er det umiddelbart lykkedes at implementere editoren fuldt tilfredsstillende. Den lever op til alle de krav der er stillet til den. Den overholder desuden MVC mønstret ret godt, hvilket gør den med at udvide. 

En andet ting der skal fremhæves er de forskellige tilstande editoren kan befinde sig i. Lige nu kan editoren befinde sig i to tilstande. En hvor man kan tegne polygoner og en hvor man kan flyttte polygoner. For at gøre det muligt at udvide editoren med flere tilstande, er stategy \cite{patterns} mønstret blevet benyttet. Dette bevirker at man uden større problemer kan indsætte tilstande. Det kunne eksempelvis være ønskværdigt at farvelægge en polygon eller lægger en tekstur på en polygon.  
Et af kritikpunkterne i editoren er Brugerfladen. Den lever ikke helt op til de krav som man kunne forvente, f.eks. får man ikke noget visuelt feedback når man vælger en kant. Vi ser dog ikke dette som en større mangel, da editoren aldrig har være ment som andet end et hjælpemiddel til at skrive bane-filer, hvilket man må sige den fuldt lever op til.

\section{Diskussion af valg}

Det blev fra starten valgt at lave en editor til at opbyyge baner med. Selve ideen med at lave en bane editor er generelt en god ide til udvikling af spil. Udover at det er nemt for udvikleren af spillet at lave baner at teste spillet med, så kan evtuelle senere brugere og så drage nytte af en editor til at lave egne baner. Det kan dog argumenteres for at udvikling af en editor i forbindelse projektet har været skudt over målet. Det er kommet til at tage en for stor del af den tid, der var til tådighed i projektet. Det havde været mere hesigtsmæssigt, hvis man i stedet havde håndkodet nogle baner i stedet.

Endvidere kan det diskuteres, hvor hensigtsmæssigt der var at kode spillet i C++. Rent fagligt har det givet gruppen en indsigt i et nyt sporg som anvendes til mange store applikationer og spil. Herudover har det givet et indblik i en lidt anden tilgang til objekt orienteret programmering. Omvendt har det har det taget tid at sætte sig ind i et nyt sprog.

Hvis spillet havde været lavet i Java kunne hele problematikken med at finde biblioteker til understøttelse af platformsuafhængished have været undgået. Men det har trods alt været en meget lærerigt at anvende et andet programmeringssporg, tiltrods for de ulemper det har medført.



