\chapter{Designovervejelser}
\begin{intro}
I dette afsnit vil de overvejelser, der er gjort vedrørende designet af klient og server bliver gennemgået. Først vil de generelle designovervejelser blive gennemgået, hvorefter de markante forskelle på klient og server vil blive gennemgået hver for sig.
\end{intro}
\section{Generelle designovervejser}
Overordnet indeholder klienten og serveren meget fælles funktionalitet, hvilket indbyder til at genbruge den samme kode i begge programmer. Dette stiller dog visse krav til designet, da det skal være udformet generelt nok til at kunne håndtere begge programmers krav.

De skal begge:
\begin{itemize}
\item Sende og modtage beskeder.
\item Indeholde information om banen og samtlige spillere.
\item Være i stand til at manipulere de aktive objekter i spillet
\end{itemize}

Programmerne er bygget op omkring Model View Controller (MVC) mønstret. 

Modellen består af spillets data, dvs spillere, bane, skibe, polygoner, kanter og punkter. Samt information om spillets status. Disse komponenter er fælles for både klient og server. 

View-delen består af klasser og metoder til at visualisere spillet. Samt klasser til at modtage input fra bruger og sende det videre til controller-delen. Da server hverken skal modtage input fra bruger eller vise noget på skærmen er denne del helt fraværende på serveren. View-delen vil derfor kun indgå i klient-programmet.

Controller-delen er så vidt muligt fælles for server og klient. Server står for for selve spillogikken dvs. den behandler spillerens handlinger. Klienten skal derimod håndtere input modtaget fra view delen. Desuden håndterer controller-delen hvert programs afvikling. For at klienten og server kan kommunikere over netværket på en hensigtsmæssig måde deler de et interface til netværkssystemet, som de begge implementerer og tilføjer deres egne specifikke metoder.

Figur \ref{fig:MVCKS} på side \pageref{fig:MVCKS} viser en opdeling af de forskellige dele af klient og server i kasser: en for både model, view og controller. Som det fremgår af figuren er view kun til stede i klienten, mens model og controller for største delens vedkommende deler funktionalitet.  

\begin{figure}[h]
\begin{center}
    \begin{minipage}[t]{\textwidth}
        \begin{center}
	        \scalebox{0.4}{\includegraphics{gfx/mvcblaster.pdf}}
            \caption{Områder indelt efter MVC}
            \label{fig:MVCKS}
        \end{center}
    \end{minipage}
\end{center}
\end{figure}

De fælles områder er søgt illustreret på figur \ref{fig:omraader} på \pageref{fig:omraader}. 

\begin{figure}[h]
\begin{center}
    \begin{minipage}[t]{\textwidth}
        \begin{center}
	       \scalebox{0.6}{ \includegraphics{gfx/faelles.pdf}}
            \caption{Oversigt over hvor delene hører til}
            \label{fig:omraader}
        \end{center}
    \end{minipage}
\end{center}
\end{figure}

\section{Opbygning}

\subsection{Model}

Modellen kan forholdsvis nemt danne basis for de klasser, der skal indgå i programmet. \texttt{Level} er den central klasse i modellen. Den indeholder en bane kaldet \texttt{Map} samt skibene (\texttt{Ship}) og deres skud (\texttt{Bullet}). Banen indeholder informationer om banens opbygning, størrelse etc. 

Banens form repræsenteres af polygoner (\texttt{Polygon}).  En polygon er opbygget af 3 kanter (\texttt{Edge}), der hver består af en vektor (\texttt{Vector}). Disse tre klasser bliver benyttet til at konstruere banen og skibet. Banen består af en lang række polygoner, der til sammen udgør den verden skibet kan bevæge sig rundt i. Skibet består også af polygoner. Helt simpelt behøver der kun være et enkelt, men der er intet i vejen for at sammensætte et skib af flere polygoner. 

Da \texttt{Bullet} og \texttt{Ship} begge er bevægelige objekter skal de have mange af de samme egenskaber. Derfor nedarver de fra \texttt{Objekt} som indeholder data, der kan repræsentere hastighed, acceleration, position , orientering og ændringen i orientering. 

For en oversigt over klasserne se figur \ref{fig:m} i bilag \label{sec:umlbilag}.


\subsection{View}

Funktionaliteten til at tegne enkelte objekter i modellen ligger i objekter selv. Således indeholder klasserne \texttt{Ship}, \texttt{Bullet} og \texttt{Map} funktionalitet til at tegne sig på skærmen. Derudover skal der på skærmen angives statusinformation om spillet. De infomationer, der er til til rådighed for spilleren er, resterende energi, skud, brændstof og antal point. Disse informationer er repræsenteret ved klassen \texttt{StatusView}. Endvidere er det muligt for spilleren at orientere sig om hvorledes stilling er i spillet. Dette foregår i \texttt{scoreview}, hvor man efter ønske kan blive præsenteret for en liste af samtlige spillere og deres point antal. 

Da det aldrig er til at vide, hvilke andre views det kunne være hensigtsmæssigt at anvende i spillet, er view-delen opbygget efter designmønstret decorator som defineret i \cite{patterns}. Ved at anvende dette mønster er det nemt at opbygge et system til at håndtere udvidelse af informationerne på skærmen. 

Inputhåndteringen skal med de valgte API'er foregår centralt. Derfor konstrueres en klasse, der for hver frame, der tegnes indeholder information om hvilke former for interaktion brugeren har udført. Denne klasse kaldes \texttt{InputController}

For en oversigt over klasserne se figur \ref{fig:v} i bilag \label{sec:umlbilag}.

\subsection{Controller}

Controller-delen består af følgende dele: Netværk, spil logik og selve afviklingen af programløkken. De fælles dele af netværksfunktionaliteten er lagt i klassen \texttt{NetWorkcontroller}. Klienten og serveren kan nedarve fra denne klasse og tilføje den funtionalitet, der er specifik for dem. 

Spillogikken, der ligeledes er forskellig for både server og klient, håndteres på samme måde som netværket, dvs der nedarves fra en fælles klasse. Denne klasse kalds \texttt{GameController}. 

Programløkken findes for serveren i \texttt{ServerController} og for klienter i \texttt{ClientController}. Disse er ansvarlige for al opsætning, såsom at gøre skærmen klar til at tegne på i klientens tilfælde, starte netværk etc. For hver opdatering af spillet sørger controllerne for at håndtere input, opdatere spillets tilstand og i klientens tilfælde sørger \texttt{ClientController} for at view tegner spillet.

For en oversigt over klasserne se figur \ref{fig:c} i bilag \label{sec:umlbilag}.

En samlet oversigt over delene i både klient og server kan ses på figur \ref{fig:samlet} i bilag \ref{sec:umlbilag}.
