\section{Teknologivalg}

Dette afsnit undersøger hvilke teknologier der skal vælges i designet af Blaster.

En kort opsummering af de valg der er foretaget hidtil:

Blaster skal visualiseres med polygoner.
Der skal bruges en editor til at fremstille baner til Blaster, da filformatet er komplekst.
Blaster skal kunne indlæse en bane som editoren har lavet.
Både Blaster og editoren skal kunne afvikles på MacOS X og Windows, og gerne Linux hvis muligt.
Selve Blaster skal bestå af en klient og en server der kan kommunikere med hinanden.

Kravet om, at både spillet såvel som editoren skal kunne afvikles på både Windows og MacOS X har stor betydning for hvilke teknologier, der er egnede til at implementere spillet og editoren. Det har desuden været et ønske fra forfatterne at forsøge at bruge sproget C++ hvis muligt. Dette ønske kom først og fremmest af en interesse for at lære et nyt programmeringssprog. 

\subsection{Valg af grafik API til spillet}
Spillet skal kunne visualiseres med brug af Java2D eller OpenGL. Hvis spillet kun skulle afvikles på styresystemet Windows havde Direct 3D også været en mulighed, men er irrelevant, da Direct X ikke findes til Mac OS X.

Java2D og OpenGL tilbyder mange af de samme faciliteter. Begge APIer er i stand til at tegne polygoner, samt at bruge diverse transformationsmatricer til at orientere og placere polygonerne på skærmen. OpenGL har den store fordel, at det kan accelleres på hardware, hvilket gør det markant hurtigere end Java2D.

OpenGL kan bruges med både C og Java via 3. parts pakken GL4Java, og er implemeteret både i MacOS X og Windows, hvilket gør det til et naturligt valg til at visualisere spillet, uanset hvilket sprog spillet implementeres i.

\subsection{Valg af programmeringssprog til spillet}

Spillet skal kunne tegnes i et vindue eller på hele skærmen med OpenGL. En mulighed havde været at implementere selve programmet særskilt på MacOS X og Windows med henholdsvis Apples Cocoa API og Objective C programmeringssprog til Mac OS X og Microsofts Direct X API og C++ til Windows. Selve spillet kunne så implementeres som et C++ modul som begge programmer brugte til det egentlige indhold. Således ville Cocoa og Direct X stå for at oprette et vindue og håndtere input fra brugeren, og C++ modulet for at tegne spillet med OpenGL samt at behandle det input, som det modtager.

En anden mulighed havde været at bruge Java. Java har som tidligere nævnt adgang til OpenGL. Dog havde forfatterne et ønske om at benytte C++ til selve spillet hvis det var muligt.

En tredie mulighed var at bruge et 3. parts API og bibliotek ved navn SDL , som binder sig til henholdsvis Cocoa og DirectX, og i øvrigt har lignende bindinger til Linux. Brugen af SDL sikrer, at den samme C++ kode kan compiles og afvikles på både MacOS X og Windows. SDL håndterer skærmen og input, således at man slipper for at bekymre sig om styresystemsspecifikke problemer og kan koncentrere sig om selve spillet.

Sideløbende til SDL findes SDL\_net, der ligesom SDL abstraherer mellem Cocoa og Direct X, abstraherer mellem begge styresystemers netværksimplementation. SDL\_net sørger dermed for, at netværkskoden ikke skal implementeres forskellige på MacOS X og Windows.

\subsection{Valg af programmeringssprog til editoren}
Editoren har nogle helt andre krav end selve spillet. Foruden at skulle kunne afvikles både på MacOS X og Windows, skal editoren have et grafisk brugerinterface (GUI) med vinduer, menuer og hvad der ellers hører til. SDL egner sig til at åbne tomme vinduer hvori et spil kan tegnes, men kan ikke håndtere egentlige GUI elementer.

Der findes en række 3. parts C eller C++ biblioteker som kan håndtere vinduer m.m. på både MacOS X og Windows, som f.eks. mxWindows. Dog vurderes det at Swing er nemmere at bruge, og da forfatterne alligevel har erfaring med Swing er det et naturligt valg at implementere editoren i Java.

\subsection{Valg af filformat til banen}
En bane skal kunne skrives fra editoren, som er et Java program, samt indlæses i spillet, som er et C++ program. Dette udelukker at bruge Javas Serializable interface til at flytte banen fra editoren til spillet, da det ikke giver mening at forsøge at indlæse en stream af Java objekter i et C++ program. Derfor må et tekst-baseret format bruges. Projektgruppen har tidligere erfaring med brug af XML dokumenter i Java via 3. parts pakken Electric XML , og fandt hurtigt en ligende pakke til C++ ved navn TinyXML . Da banens format i forvejen har en klar struktur, valgtes XML som det format der bruges til at flytte baner fra editoren ind i spillet. 