Im Folgenden wird die Arbeit des Projektteams „Simulation“ (Ernst, Roepke) des Sommersemesters 2011 begründet, beschrieben und das Semesterergebnis betrachtet.
Hierbei wurde die Umsetzung eines ersten Aspektes des im vorigen Semester ausgearbeiteten, umfangreichen Konzeptes begonnen.

Nach einer Einleitung und Motivation, die den Ausgangspunkt der ADrbeit definieren wird das Ziel erläutert, wird das eingesetzte Vorgehensmodell beschrieben.
Anschließend wird das entwickelte Konzept vorgestellt, auf dem die praktische Umsetzung basiert. Im Anschluss hieran werden Implementierungsdetails aufgeführt und das Ergebnis und der aktuelle Projektstand vorgestellt.

Darüber hinaus wurden zwei Videos erstellt, welche die Anwendung der erstellten Software demonstrieren. Der primäre Fokus des Projektes „Simulation“ liegt auf Barrierefreiheit und Transparenz. Diese Aspekte wurden stets sowohl in der Projektdurchführung, als auch in der Konzipierung und Durchführung der Softwareentwicklung berücksichtigt.
Die Dokumentation wird mit einer Schlussbetrachtung und einem Ausblick abgeschlossen.

Im ersten Semester legte das Projektteam den Grundstein für eine umfangreiche Simulationssoftware unter Verwendung des Physik- und Graphik-Engine der Firma CryTek.

Hierfür wurde zunächst ein Konzept entwickelt. Die Konzeptentwicklung ist nicht abgeschlossen.
Durch die gemeinsame Betrachtung im Rahmen der interdisziplinären AIIPS-Veranstaltung an der Fachhochschule Frankfurt am Main wächst das Konzept und wird fortwährend weiterentwickelt und dabei durch Inspirationen anderer Projektteams geformt und verfeinert. Erste Ideen für die Umsetzung der Teilaspekte wurden gemeinsam gesammelt.

Durch Einblick in das parallele Projekt „APS Simulator“ wurde eine der beschriebenen Einsatzmöglichkeiten priorisiert: Das Projekt „APS Simulator“ gewinnt zunehmend an Bedeutung.
Die Arbeitsgruppe des „APS Simulator“ entwickelt eine Software, die einen virtuellen Roboter im Raum steuert und hat hierbei bereits erstaunliche Ergebnisse erzielt. Die graphische Ausgabe ist klar von der Programmlogik getrennt. Sie basiert auf OpenGL und hat eine sehr einfache Anmutung.
Die graphisch ansprechende Darstellung von Modellen und die Steuerung eines Roboters im Raum stellen einen Teil der von uns angestrebten Simulationssoftware dar.

Der Bedarf hieran motivierte uns dazu, die Umsetzung unseres Konzeptes in diesem Aspekt zu beginnen.

Im Projektkonzept wurden verschiedene Einsatzziele der angestrebten Simulationssoftware definiert. Diese lassen sich auf eine endliche Menge von gemeinsamen, allgemeinen Grundfunktionalitäten herunterbrechen. Die folgende Abbildung stellt diese schematisch dar:


Legende

Sind diese Grundfunktionalitäten erst einmal entwickelt, lassen sich die unterschiedlichen Einsatzziele theoretisch durch deren Kombination umsetzen.
Die Aufteilung auf diese Grundfunktionalitäten wird durch eine generelle und modulare Umsetzung möglich. Die Entwicklung der einzelnen Funktionen kann in sich geschlossen und parallel erfolgen. Mehrere Projektteams können hieran parallel und somit effizient arbeiten.
Das aktuelle Projektteam hat sich im Sommersemester 2011 die Umsetzung von einer dieser Grundfunktionalitäten als Ziel gesetzt:

Ziel sind die Konzeptionierung und Umsetzung, um mit einem externen Programm durch eine definierte Schnittstelle Zugriff in den simulierten Raum zu erhalten.

Dieses Ziel wird in der schematischen Darstellung des Gesamtziels des Projektes „Simulation“ durch die Referenzpunkte B, L und K beschrieben, und durch folgende Abbildung im Gesamtkonzept markiert:

Legende

Ein weiteres Ziel ist es, im Rahmen der Barrierefreiheit bei der Projektdurchführung Sprach-, Orts- und Netzwerktransparenz zu gewährleisten.

Konstantin Ernst, M. Sc. - info@konstantinernst.de

Edward Roepke, B. Sc. - roepke@stud.fh-frankfurt.de

Ein Vorgehensmodell ist eine Arbeitsanleitung, die ein Projekt in verschiedene strukturierte Phasen einteilt und die Entwicklung leitet. Es wird die einzuhaltende Reihenfolge der Arbeiten bei Organisation und Durchführung des Projektes dargestellt.
Es existieren verschiedene Vorgehensmodelle. Wir organisieren die Durchführung mit dem Vorgehensmodel Scrum.

Scrum ist eines der bekanntesten Vorgehensmodelle mittels agiler Methoden. Es ermöglicht dem Kunden in Zusammenarbeit mit dem Produktverantwortlichen Product Owner ein sogenanntes Product Backlog für die Anforderungen der Entwicklung aufzusetzen, welches jederzeit erweitert oder verändert werden kann. Zusätzlich hat dieses Vorgehensmodell den Vorteil, dass das im Mittelpunkt stehende Entwicklerteam selbständig ohne weitere Einflüsse arbeiten kann und keinen Projektleiter benötigt.

Der ScrumMaster unterstützt dabei das Team, hält störende Einflüsse von außen ab und achtet auf die Einhaltung der Vorgehensweisen. Der Produktverantwortliche (Product-Owner) muss die mit dem Kunden ausgearbeiteten Anforderungen definieren, in kleine Pakete einteilen und priorisieren. Zusammen mit dem Team wird dann aus dem Product-Backlog das Sprint-Backlog gebildet. Darin werden alle Elemente festgehalten, die innerhalb des nächsten Sprints bearbeitet werden. Das Team setzt diese Elemente dann in dem Sprint, der zwischen einer und vier Wochen dauern kann, um. Während eines Sprints soll das Team ungestört arbeiten können. Es werden während dieser Zeit keine neuen Anforderungen an das Team herangetragen. Das Team soll untereinander täglich in einem kurzen Daily-Scrum jeweils drei Fragen beantworten:

• Was habe ich seit dem letzten Daily-Scrum getan?
• Was hat mich dabei behindert?
• Was werde ich bis zum nächsten Daily-Scrum tun?

Nach einem Sprint wird in einer Rückschau (Sprint-Review) dem Product-Owner die Entwicklung präsentiert. In einer weiteren Rückschau, der Sprint-Restrospektive, werden Dinge besprochen, die im vergangenen Sprint besonders gut funktioniert haben, und Dinge, die der Verbesserung bedürfen.
Für uns boten sich durch Scrum mehrfache Vorteile:

• klare Rollen
• schnell einzusetzen
• erweiterbare Anforderungen
• unterstützter Mittelpunkt ist das entwickelnde Team
• Sprints decken sich mit dem vom Kunden gewünschten Präsentationszeitraum

Da wir bereits mit der Vorgehensweise bei Scrum vertraut waren, konnten wir die Möglichkeiten, die Scrum bietet, weiter ausarbeiten.
Über die FH bot sich uns die Möglichkeit ein Scrum-Online-Tool zu verwenden, welches das Vorgehen mittels Scrum unterstützen kann.
Dadurch existiert eine Plattform, die die Koordination der Arbeiten unterstützt. Analog zum Scrumprozess kann man ein Product-Backlog erstellen und gemeinsam mit Anforderungen füllen. Es entsteht nach und nach eine Auflistung aller für das Projekt erforderlichen Punkte.
Eine Herausforderung war für uns erneut, die Komplexität und Dauer der einzelnen Punkte im Backlog einzuschätzen. Scrum bietet die Möglichkeit der Einschätzung mit so genannten Storypoints. Nach der Priorisierung unseres Backlogs haben wir eine Abschätzung über relative Komplexitäts-Gewichtungen vorgenommen. Als Storypoints werden oftmals die Zahlen der Fibonacci-Reihe verwendet. Das Scrum Online-Tool bietet hier einen „Business Value“ mit den Werten 100, 200, 300, 500, 800, 1200, 2000 und 3000, mit dem die Aufgaben im Verhältnis zueinander bewertet werden. Der am einfachsten zu erledigende Eintrag im Backlog erhält die 100 zugewiesen und der am Schwersten zu bewältigende Eintrag die 3000. Danach werden die weiteren Einträge innerhalb dieser Einteilung verteilt.
Mit diesem Verfahren lässt sich dann auch die benötigte Zeit für die Aufgaben des Backlogs errechnen. Dazu ist es nötig, die Velocity des Teams zu bestimmen. Dieser Wert bedeutet die Menge an Arbeit, die das Team innerhalb eines Sprints leisten kann. Diese Menge ergibt sich aus der Summe der Storypoints, die in dem Sprint abgearbeitet wurden. Gewöhnlich können die Teams, sofern sie bereits einige Zeit miteinander gearbeitet haben, die Velocity aus der Erfahrung bestimmen. Bei neuen Teams, oder wenn ein neuer Mitarbeiter in das Team eintritt, kann die Velocity aber auch schwanken. Eine genauere Einteilung ist erst nach mehreren durchlaufenen Sprints möglich. Dann hat sich das Team aufeinander abgestimmt und eingestimmt und kann die Anzahl der Storypoints abschätzen.
In einem neuen Team werden die priorisierten Elemente des Backlogs betrachtet und für den Sprint ausgewählt. Sobald eine Person des Teams unsicher ist, ob die Zeit des Sprints für die Aufgaben ausreichend ist, wird die Auswahl abgebrochen.
Durch die neuen Themengebiete, wie z. B. Lua oder gSOAP war eine genaue Abschätzung schwierig, so dass wir zumeist das letztere Verfahren (für neue Teams) angewendet haben. Um unsere Sprints zu koordinieren, haben wir diese über die Zeit des Semester verteilt. Für die Zeit zwischen der ersten Vorlesung am 15.04.2011 und der Prüfung am 15.07.2011 haben wir 7 Sprints durchgeführt, die wir von Sprint A bis Sprint G bezeichnet haben. Im Online-Tool lassen sich die in dem Product-Backlog gespeicherten Einträge leicht in die einzelnen Sprints übernehmen und den einzelnen Teammitgliedern zuweisen.
In der Entwicklung war die Abstimmung eine wichtige Komponente. Es zeigte sich, dass die regelmäßigen von uns überwiegend täglich durchgeführten Scrums eine große Hilfe waren. Das Online-Scrum-Tool kann diese Koordination verbessern, da es eine weiteres Hilfsmittel ist, um die bei verschiedenen Treffen oder Telefonaten übermittelten Informationen zu bündeln. Das Sprint-Review haben wir in den zweiwöchentlichen Treffen angewendet, in denen die Gesprächsergebnisse mit Kommilitonen aufgezeigt wurden und aus dem Feedback Ideen und Möglichkeiten erwachsen sind.
Durch die geringe Teammitgliederanzahl wurden die Scrum-Retrospektiven nicht speziell durchgeführt. Vielmehr wurde der Prozess der ständigen Verbesserung mittels der Daily Scrums durchgeführt. In Gesprächen wurde dadurch jeweils schnell deutlich, welche Elemente beim Vorgehen beizubehalten sind und welche nicht.

Das angestrebte Ziel lässt sich in drei Teilziele aufteilen:

• Definition der Schnittstelle für den Zugriff auf den simulierten Raum im Sinne der Interprozesskommunikation
• Entwicklung eines Empfängermoduls, welches Teil des simulierten Raumes ist und Befehle von extern entgegennimmt und ausführt (im Folgenden „Server“ genannt)
• Entwicklung eines Beispielsprogramms, welches von extern über die Schnittstelle mit dem Server kommuniziert (im Folgenden „Client“ genannt).

Über die Schnittstelle sollen zwei Programme bzw. Prozesse miteinander kommunizieren. Man spricht hierbei von Interprozesskommunikation (im Folgenden IPC genannt). Hierfür besteht bereits eine Anzahl von Technologien. An die eingesetzte Technologie für die Schnittstelle gibt es folgende Anforderungen:

• Die Schnittstelle muss Ortstransparenz gewährleisten
• Die Schnittstelle muss Netzwerktransparenz gewährleisten
• Die Schnittstelle muss im Sinne der Sprachtransparenz Zugriff unabhängig der verwendeten Programmiersprache des Clients gewährleisten
• Die Schnittstelle muss erweiterbar sein und zukünftige Modifikationen und Zusätze erlauben
• Die Schnittstelle muss auswechselbar sein, um den Umstieg auf eine andere Technologie zu ermöglichen
• Die Schnittstelle darf den Programmfluss der Simulationssoftware nicht negativ beeinflussen oder blockieren.

Um diesen Anforderungen gerecht zu werden haben wir folgendes Konzept entwickelt:
Wir setzen direkt zwei Schnittstelle um. Die erste mit der Technologie SOAP, die zweite mit Sockets.

Für die Implementation der Schnittstelle wird in der Simulationssoftware jeweils ein eigener Thread implementiert.
Somit laufen beide Schnittstelle parallel und unabhängig zum restlichen Programm. Der Programmfluss wird nicht gestört. Durch die Implementation in einem eigenen Thread ist die Implementierung modular und damit auswechselbar. Zudem können somit weitere Schnittstelle parallel zu dieser implementiert werden. Der Client kann sich später mit einer beliebigen Schnittstelle verbinden.

Alle Schnittstelle leiten die Information des Clients direkt an die Serverfunktion „BaSys_Server::processClientInformation()“ weiter. Somit ist egal, welche der implementierten Schnittstelle der Client anspricht. Dies macht das Konzept der Schnittstelle zukunftssicher, neue Schnittstelle können problemlos hinzugefügt werden und auch „blockierende“ Technologien können bedenkenlos eingesetzt werden.

Der Server ist ein Programmteil, der die Signale auswertet, die von extern an die Schnittstelle gesendet werden. Folgende Anforderungen werden an den Server gestellt:

• Der Server darf den übrigen Programmfluss nicht beeinflussen
• Die Cry-Engine unterstützt die Interpretation von LUA zur Laufzeit. Dies hat den Vorteil, dass eigene LUA-Scripte und -Funktionen implementiert werden können, ohne die Programmlogik zu modifizieren. Der Server muss Funktionen enthalten, um während der Laufzeit LUA-Scripte und -Funktionen auszuführen. Dieser Aufruf muss allgemein gehalten werden, damit neue LUA-Skripte und -Funktionen komfortabel vom Anwender/Entwickler erstellt und angesprochen werden können, ohne jedes Mal den Server anpassen zu müssen.
• Da die Schnittstelle die gesendeten Informationen nicht auf Inhalt überprüft, sondern ungeprüft an den Server weiterleitet, müssen Zugriffsberechtigungen im Server implementierbar sein.

Um diese Anforderungen zu erfüllen haben wir folgendes Konzept entwickelt:
Für den Server wird eine eigene Klasse erstellt. Eine Instanz hiervon wird von der Schnittstelle erzeugt. Somit laufen die Funktionen des Servers parallel und unabhängig vom restlichen Programm. Im Server wird eine Funktion „BaSys_CallLuaFunction“ implementiert. Diese Funktion erhält einen Parameter. Hierin wird der Name der LUA-Funktion übergeben, die die Server-Funktion dann aufruft.
Somit ist der Aufruf von LUA-Skripten allgemein und unabhängig vom jeweiligen Funktionsnamen.

Eine Spezialisierung für LUA-Funktionen mit einem oder mehreren Parametern findet zu einem späteren Zeitpunkt statt. Rechtemanagement ist ein äußerst wichtiges Thema. Allerdings macht eine Planung und Umsetzung in einem so frühen Entwicklungsstadium noch keinen Sinn und wird deshalb vorübergehend vernachlässigt.

Bei der Implementierung des Clients wird dem Entwickler absoluter Freiraum eingeräumt. Programmiersprache und Art des Programms können frei gewählt werden. Das Programm muss lediglich die SOAP-Schnittstelle der Simulationssoftware bedienen. Dieser Freiraum geht soweit, dass es sogar möglich ist, die Simulationssoftware über einen Webbrowser anzusprechen (vergleiche SOAP Client)

Das Konzept und die Zusammenhänge der drei eben beschriebenen Teilziele werden in der folgenden Abbildung vereinfacht dargestellt:

Legende

Im Folgenden wird die Umsetzung des Konzeptes beschrieben.

Da die Simulationssoftware wie bereits erwähnt nicht von Grunde auf neu erstellt wird, sondern durch Modifikation („Modding“) aus dem bestehenden Computerspiel „Crysis“ geformt wird, wurde zunächst ein neuer Mod angelegt.
Dieser trägt den Namen „BaSysMod“.
Hierzu wurde ein neues Projekt in der Entwicklungsumgebung „Microsoft Visual Studio 2008“ angelegt. Um die Vorbereitung für die Erstellung dieses Modding-Projektes transparent zu machen, haben wir ein Video-Tutorial erstellt. Hierin werden die notwendigen Schritte erklärt. Im Folgenden wird die weitere Umsetzung beschrieben.

Alle Bestandteile wurden innerhalb des BaSysMod umgesetzt.

Um eine einheitliche und übersichtliche Programmierung zu sichern, werden folgende Konventionen festgelegt:

• C++ Klassen
  • Die Bezeichnung einer Klasse erhält das Präfix „BaSys_“
  • Klassen werden im Ordner „BaSys“ oder in einem Unterordner hiervon abgelegt
  • Klassen wird ein Kommentarblock vorangestellt, der folgende Informationen enthält:
    • Beschreibung
    • Autor
    • Version
    • Erstellungsdatum
    • Datum der letzten Änderung
      Beispiel:
      
• C++ Funktionen und Methoden
  • In der ersten Zeile einer Funktion oder Methode wird der Name und „ - start“ über die definierte Log-Funktion ausgegeben.
    Beispiel:
    BaSys_Common::Log(„BaSys_Server::BaSys_Server - start“);
  • In der letzten Zeile einer Funktion oder Methode wird der Name und „ - end“ über die definierte Log-Funktion ausgegeben.
    Beispiel:
    BaSys_Common::Log(„BaSys_Server::BaSys_Server - end“);
  • Funktionen und Methoden wird ein Kommentarblock vorangestellt, der folgende Informationen enthält:
    • Beschreibung
    • Autor
    • Version
    • Erstellungsdatum
    • Datum der letzten Änderung
    • Beschreibung der Parameter
    • Beschreibung des Rückgabewertes
      Beispiel:
      
  • LUA-Scripte
    • LUA-Script werden im Script-Verzeichnis „BaSys“, oder einem seiner Unterordner abgelegt
    • Dateinamen von LUA-Scripten wird das Präfix „BaSys_“ vorangestellt.
    • Die erste Zeile in einem LUA-Script gibt „LUA:“, den Scriptname und „ – start“ aus.
      Beispiel der Scriptdatei „BaSys_Main“:
      System.LogAlways(„LUA:BaSys_Main - start“);
    • Die letzte Zeile in einem LUA-Script gibt „LUA:“, den Scriptname und „ – end“ aus.
      Beispiel des Scriptdatei „BaSys_Main“:
      System.LogAlways(„LUA:BaSys_Main - end“);
  • LUA-Funktionen
    • In der ersten Zeile einer Funktion oder Methode wird der Name der Funktion und „ - start“ ausgegeben.
      Beispiel:
      BaSys_Log(„BaSys_examplefunction - start“)
    • In der letzten Zeile einer Funktion oder Methode wird der Name der Funktion und „ - end“ ausgegeben.
      Beispiel:
      BaSys_Log(„BaSys_examplefunction - end“)
    • LUA-Funktionen und -Methoden wird ein Kommentarblock vorangestellt, der folgende Informationen enthält:
      • Beschreibung
      • Autor
      • Version
      • Erstellungsdatum
      • Datum der letzten Änderung
      • Beschreibung der Parameter
      • Beschreibung des Rückgabewertes
        Beispiel:
        

Um eine Hauptroutine zu implementieren, wurde die Klasse „BaSys_Main“ angelegt. Sie beinhaltet die Hauptroutine, innerhalb der die Instanzen der restlichen BaSys-Klassen erstellt und koordiniert werden.
Damit diese Hauptroutine durchlaufen wird, sobald das Spiel oder der Editor starten, wird in der Klasse „CGame“ des Spiels in der Funktion „Init“ eine Instanz der Klasse BaSys_erstellt. In der Hauptroutine der BaSys_Main werden aktuell die Threads der SOAP- und der Socket-Schnittstelle gestartet.
Die Implementation zeigt sich wie folgt:

Für die Implementierung von Basisfunktionalitäten wurde eine neue Klasse „BaSys_Common“ angelegt. Diese enthält bisher eine Funktion „BaSys_Common::Log“, welche dem Entwickler Debugging erleichtert. Sie schreibt Informationen in die Konsolenausgabe und in eine Log-Datei. Sie wurde wie folgt implementiert:

Um den Zugriff auf das Engine-interne Scriptsystem komfortabel zu gestalten, wurde eine Klasse „BaSys_LUA“ erstellt. Hierin haben wir Methoden zusammengestellt, die den Zugriff auf das Engine-interne Scriptsystem deutlich vereinfachen. Bisher gibt es zwei Funktionen:

• BaSys_LUA::loadScriptFile (ScriptFilePath)
  Diese Funktion lädt ein Scriptfile ein. Schreibt der Entwickler/Anwender eigene Lua-Funktionen in eine Scriptdatei, muss diese Dateien zunächst geladen werden, bevor die Funktion aufgerufen werden kann. Das geschieht durch diese Funktion. Wir haben Sie folgendermaßen implementiert:
  
• BaSys_Lua::call (FunctionName)
  Diese Funktion ruft eine eingeladene LUA-Funktion auf. Wir haben diese Funktion folgendermaßen implementiert:
  

Für die Schnittstelle wurde zunächst eine Klasse „BaSys_TCP_Interface“ angelegt. Diese leitet von der Klasse CryThread ab. Um den Thread der Schnittstelle zu starten, wird hiervon in der zentralen Klasse „BaSys_Main“ eine Instanz erzeugt und die Objektmethode „Start()“ aufgerufen. Die Schnittstelle läuft somit wie gewünscht parallel zum restlichen Programm.

SOAP ist ein Protokoll zum Austausch XML-basierter Nachrichten. Es wird von dem World Wide Web Konsortium (W3C) zur Verwendung für plattformübergreifende RPCs empfohlen. Es reglementiert über die Vorgabe eines Frameworks wie Daten und entfernte Prozeduraufrufe erfolgen sollen. Dabei ist unerheblich welche Semantik verwendet wird. SOAP kann u. A. zum Aufrufen von entfernten Prozessen, als Nachrichtensystem oder zum Datenaustausch verwendet werden.

SOAP wird insbesondere dann verwendet, wenn die Kompatibilität zwischen Systemen gesichert werden soll. SOAP ist durch seinen offenen Entwurf sehr flexibel. Nachteile von SOAP sind das hohe Protokollaufkommen und die damit verbundenen Übertragungsvolumina. Dies erhöht auch die Rechenanforderung. So wird ein XML-Dokument beim Sender erstellt und danach validiert. Um eine hohe Flexibilität zu bieten, werden bei der Erstellung Metadaten eingefügt. Auch einfache Abfragen werden dadurch vergrößert. Dem gegenüber können aber durch den flexiblen Aufbau auch komplexe Transaktionen zusammengefasst werden. Dies ist Vorteil gegenüber stark gekoppelten Systemen, weil Übertragungen in einer Anfrage erfolgen können.

Eine SOAP-Nachricht besteht aus zwei Elementen: einem optionalen Header und einem Body, die als Envelope bezeichnet werden. Im Header werden die Meta-Informationen über beispielsweise Routing, Verschlüsselung oder zur Transaktionsidentifizierung untergebracht. Der Envelope hat ein Namensraum-Attribut auf das referenziert wird. Struktur einer SOAP-Nachricht:

<?xml version=„1.0“?>
<s:Envelope xmlns:s=„http://www.w3.org/2003/05/soap-envelope“>
<s:Header>
</s:Header>
<s:Body>
</s:Body>
</s:Envelope>
Im Body können Anweisungen zu Prozeduraufrufen oder Informationen zum Datentausch stehen. SOAP ist sprachtolerant und lässt sich in allen Programmiersprachen implementieren. Zudem leistet SOAP Netzwerktransparenz. Für die Implementation der Schnittstelle wird in der Simulationssoftware ein eigener Thread implementiert. Somit läuft die Schnittstelle parallel und unabhängig zum restlichen Programm. Der Programmfluss wird nicht gestört. Durch die Implementation in einem eigenen Thread ist die Implementierung modular und damit auswechselbar. Zudem können somit weitere Schnittstellen parallel zu dieser implementiert werden.

Gegenüber anderen Protokollen wie CORBA oder RMI bietet SOAP die Möglichkeit der einfachen Implementierung. Da SOAP mittels HTTP kommuniziert, sind auch Portfreigaben oder Firewalls kein Problem.

Im speziellen wurde das gSOAP Framework verwendet. gSOAP ist eine Open Source Entwicklungsumgebung für Web-Services. Es unterstützt C und C++ und ist auf Performanz optimiert. Da gSOAP die Kompression von XML-Daten unterstützt, wird das Datenvolumen reduziert. Da der Source-Code frei verfügbar ist, kann er ohne weiteres angepasst werden.

gSoap bietet eine automatisierte Anbindung zwischen XML und C++. Durch die automatische Code-Generierung vereinfacht sich der Entwicklungsaufwand. Über einen eigenen Compiler werden WSDL, SOAP und XML-spezifische Elemente ohne Benutzereingriff erstellt. Gleichzeitig werden automatisch verschiedene Elemente, wie die Validität, das Speichermanagement und Serialisierung überprüft und sichergestellt.
Der Benutzer muss sich um keine WSDL/SOAP/XML-Elemente kümmern, er kann diese Aufgabe gSoap überlassen.
Zur Verwendung ist neben dem C++ Compiler das gSoap-Packet erforderlich, dass über diese Seite erhältlich ist. \\Das SOAP-Paket bietet unter anderem zwei ausführbare Dateien:

• wsdl2h.exe – Erstellt anhand einer WSDL-Datei entsprechende Headerdateien
• soapcpp2.exe – Generiert die Stubs und Skeletons für Client und Server.

Die gSoap wsdl2h importiert eine oder mehrere WSDL- und XML-Dateien und generiert daraus eine Headerdatei mit C/C++-Syntax für die Definition des Web-Services. Der gSoap soapcpp2 Compiler nimmt dann diese Headerdatei und generiert daraus XML-Serialisierer für die Daten (soapH.h und soapC.cpp), die Clientseitigen Stubs (soapClient.cpp) und die Serverseitigen Skeletons (soapServer.cpp).
Es ist mit dem soapcpp2 Compiler aber auch möglich, ohne vorherige WSDL-Definition aus einer Headerfile eine WSDL zu erstellen.
Über eine Datei namens BaSysService.h definieren wir welche Funktionen wir aufrufen lassen möchten. Es wäre auch möglich komplexe Datentypen zu definieren. Diese Datei beschreibt unsere Schnittstelle die von außen zugreifbar sein soll.

In der BaSysService.h müssen dafür einige Informationen für gSOAP angelegt werden:

gsoap ns service name: basys
gsoap ns service style: rpc
gsoap ns service encoding: encoded
gsoap ns service namespace: urn:basysservice
int ns_callLuaScript(char *function, int &result);

Die Skeletons und die WSDL werden über den Aufruf der soapcpp2.exe erstellt:

soapcpp2.exe -2 -S -j BaSysService.h

(Informationen zu den Parametern: http://www.cs.fsu.edu/~engelen/soapdoc2.html#tth_sEc9.1

Damit steht die Schnittstelle zur Verfügung. Zusätzlich muss nun die gewünschte Methode implementiert werden die bei einer Anfrage aufgerufen wird:

int basysService::callLuaScript(char *function, int &result)

Für den Server wurde die Klasse „BaSys_Server“ angelegt. Bei der Instanziierung wird zunächst das LUA-Script „\Mods\BaSysMod\Game\Scripts\BaSys\BaSys_Main.lua“ eingeladen (Dieses bildet den Ausgangspunkt für spätere Scripts). In diesem Script werden die weiteren BaSys-Scripts geladen. Unter anderem das Script „BaSys_example.lua“, welches eine Beispielsfunktion enthält.
Da die Funktionalität für den Zugriff auf das interne LUA-Scriptsystem in einer eigenen Klasse „BaSys_LUA“ gekapselt wurde, um den Zugriff komfortabel zu gestalten, zeigt sich die Implementierung der Klasse „BaSys_Server“ sehr schlicht:

Da der Server lediglich einen LUA-Funktionsnamen von der Schnittstelle entgegennimmt und aufruft, und wir bereits eine Klasse BaSys_LUA erstellt haben, die diesen Aufruf maximal vereinfacht, konnten wir diese Funktionalität in wenigen Zeilen implementieren:

Damit ist die Umsetzung des Servers abgeschlossen.

Exemplarisch haben wir eine einfache, selbständige Applikation erstellt, die den BaSysMod über Sockets anspricht und dem Anwender die Möglichkeit bietet, Zeichenketten an diese Schnittstelle zu senden. Dieser Client kann im Downloadbereich heruntergeladen werden. Folgende Abbildung zeigt das Programm:

Wir haben zwei Clients für das SOAP Protokoll entwickelt, um die Flexibilität zu demonstrieren. Es wurde ein Java- und einen PHP-Client erstellt.

Mittels der WSDL-Datei ist es über eine Entwicklungsumgebung wie z. B. Netbeans möglich die Stubs vollständig automatisch generieren zu lassen.

Danach kann man direkt die entsprechende Funktion des entfernten Servers aufrufen:

private static int callLuaScript(java.lang.String function) {
basysservice.Basys service = new basysservice.Basys();
basysservice.BasysPortType port = service.getBasys();
return port.callLuaScript(function);
}

Die WSDL-Datei wird dabei fest in dem Java-Programm eingebunden. Im Weiteren wurde ein PHP-Client entwickelt, der ebenfalls über die in der WSDL enthaltenen Informationen seinen XML-Aufruf sendet.

Die gesamte Datei sieht dabei wie folgt aus:

<?php
$msg=„BaSys_examplefunction“;
if (key_exists('msg', $_POST)) {
try {
$client = new SoapClient('basys.wsdl');
$res = $client→callLuaScript($_POST['msg']);
echo „Result: {$res}<br/>“;
} catch (exception $ex) {
echo '<pre>'.$ex→__toString().'</pre>';
}
}
?>
<form action=„index.php“ method=„post“>
<input type=„text“ name=„msg“ value=“<?php echo htmlentities($msg); ?>„ />
<input type=„submit“ value=„Senden“ />
</form>

Die eigentliche Anfrage, die der Client an den Server richtet lautet wie folgt:

<soap:Envelope xmlns:soap=„http://www.w3.org/2003/05/soap-envelope“ xmlns:urn=„urn:basysservice“>
<soap:Header/>
<soap:Body>
<urn:callLuaScript>
<function>BaSys_examplefunction</function>
</urn:callLuaScript>
</soap:Body>
</soap:Envelope>''

Um die Anwendung unserer Software auch ohne Installationsaufwand zu demonstrieren, haben wir zwei Videos erstellt. Diese werden im Folgenden beschrieben. Der Download ist im Downloadbereich möglich.

Video 1 - Erstellung eines eigenen Crysis-Mod
In diesem Video zeigen wir projektunabhängig, wie man seinen eigenen Mod erstellt, von der Einrichtung der Entwicklungsumgebung „Microsoft Visual Studio 2008“ bis zur Compilierung und einem Test.

Video 2 - Der BaSysMod
In diesem Videotutorial wird unser Mod „BaSysMod“ vorgestellt. Das Video zeigt, wie man unsere Projektdateien praktisch anwendet, also die Entwicklungsumgebung „Microsoft Visual Studio 2008“ einrichtet und die Projektdateien einbindet und ausführt. Die Funktionsweise und Zusammenhänge der einzelnen Komponenten und Klassen werden erläutert. Das Video schließt mit einer Demonstration der Anwendung ab.

Barrierefreiheit bildet den Grundsatz und das Ziel aller BaSys-Projekte.
So haben auch wir in diesem Projekt der Barrierefreiheit höchste Priorität zugeordnet.
Um das Konzept der Barrierefreiheit möglichst umfassend umzusetzen, betrachten wir unser Projekt zunächst aus zwei Perspektiven:

• Das Projekt an sich, welches die Erstellung einer Software als Ziel hat.
• Das Resultat des Projektes, also die Software selbst

In diesen beiden Punkten wird das Prinzip der Barrierefreiheit unterschiedlich umgesetzt. Diese werden in den folgenden beiden Kapiteln näher erläutert.

Drei Konzepte, durch die wir Barrierefreiheit in diesem Projekt gewährleisten:

• Zugänglichkeit
• Transparenz
• Mehrsprachigkeit

Um jeder Person die Möglichkeit zu bieten, die Projektentwicklung und alle Entwicklungsschritte leicht nachvollziehen oder selbst in das Projekt einsteigen zu können, werden alle Fortschritte, Erfahrungen und Erkenntnisse strukturiert, dokumentarisch protokolliert und stehen für jeden zugänglich in diesem Wiki-Dokument zur Verfügung.
Diese Dokumentation richtet sich an Interessenten aus allen Disziplinen und beschränkt sich keinesfalls nur auf den Fachbereich der Informatik. Es ist eine besondere Herausforderung, solch ein komplexes und informatiklastiges Projekt für Personen ohne vertieftes Vorwissen verständlich darzustellen, daher bittet das Projektteam um Kritik und Inspirationen.
Um eine weitere Barriere zu eliminieren, wird die Dokumentation parallel in englischer Sprache gepflegt.

Für Softwareentwicklung gibt es ebenfalls bewährte Techniken, um Barrierefreiheit zu durchzusetzen:

• Zugriffstransparenz & Netzwerktransparenz
• Nebenläufigkeitstransparenz
• Leistungstransparenz

Diese Punkte sind Konzepte aus der Informatik und sehr technisch. Für detaillierte Beschreibungen und nähere Informationen sind diese Begriffe zu Artikeln des Online-Lexikon Wikipedia verlinkt.
Alle hier aufgeführten Formen von Transparenz wurden im Konzept der Software berücksichtigt.

Zum Projektmanagement haben wir, wie bereits angesprochen, SCRUM eingesetzt.

Die Projektdokumentation steht jederzeit zugänglich in diesem Wiki zur Verfügung. Änderungen, Korrekturen und Erweiterungen können von jedem BaSys-Studenten vorgenommen werden. Wir freuen uns über jede Form der Teilnahme an unserem Projekt.

Für Feedback, Kritik und Inspirationen sind wir offen und dankbar, bitte als Mail an eines der Projektmitglieder.

In diesem Semester haben wir einen ersten Aspekt des umfangreichen Konzeptes des Projektes „Simulation“ herausgegriffen und erfolgreich umgesetzt.
In der ersten Phase haben wir die Anforderungen im Sinne von Barrierefreiheit und Zukunftssicherheit zusammengestellt ein genaues Konzept entwickelt, welches diese Anforderungen gewährleistet.
Während der Implementationsphase wurde das Konzept umgesetzt und hin und wieder in Details angepasst. Letztendlich erreichten wir den technischen Durchstich.
Eine externe Applikation kann sich nun zwischen zwei Schnittstellen entscheiden, über die sie mit unserer Software kommuniziert.
Die interne Weiterleitung der gesendeten Informationen geschieht wie geplant und ermöglicht es, eine LUA-Funktion aufzurufen. Im Einsatz der Crytek-Engine ist LUA eine mächtige Komponente. Wir sehen hier großes Potential für die Erreichung weiterer Projektziele des Simulationskonzeptes.

Durch die offene Kommunikation im Rahmen der interdisziplinären AIIPS-Veranstaltung an der Fachhochschule Frankfurt am Main haben wir neue Inspirationen gesammelt, um das Projekt auch im nächsten Semester zielgerichtet voranzutreiben.

BaSysMod
Unseren Modifkationen an dem Spiel Crysis haben wir den Namen BaSysMod gegeben.

C++
C++ ist eine Programmiersprache. Mit C++ ist sowohl objektorientiertes, generisches als auch prozedurales Programmieren möglich. C++ bietet maschinennahe und abstrakte Programmierung.

Klasse
Unter einer Klasse oder einem Objekttyp ist in der objektorientierten Programmierung ein Modell für eine Anzahl von ähnlichen Objekten gemeint.

Client
Ein Client ist ein Computerprogramm, das Kontakt zu einem anderen Computerprogramm, dem Server, aufnimmt, um dessen Funktionen zu nutzen.

Compiler
Ein Compiler oder Übersetzer bezeichnet ein Computerprogramm, das den Quelltext eines Programms in eine Zielsprache umwandelt.

Cry-Engine
Die CryEngine ist eine Spiel-Engine des deutschen Entwicklerstudios Crytek.

Crytek
Die Crytek GmbH ist ein deutsches Spielentwicklungsunternehmen.

Debugging
Debugging bezeichnet das Diagnostizieren und Auffinden von Fehlern in Computersystemen.

Entwicklungsumgebung
Entwicklungsumgebung ist ein Programm zur Entwicklung von Software.

Hauptroutine
In den meisten Hochsprachen gibt es eine Hauptroutine und Subroutinen. Die Hauptroutine („main“) ist das eigentlich ablaufende Programm.

Implementation
Die Implementierung bezeichnet die Umsetzung festgelegter  Strukturen und (Arbeits-) Abläufe in einem System unter Berücksichtigung einer Spezifikation.

Instanz
Eine Instanz ist in der objektorientierten Programmierung ist ein Objekt, welches zur Laufzeit aus einer Klasse erzeugt wird.

Interprozesskommunikation
Unter Interprozesskommunikation versteht man die Kommunikation zwischen Prozessen auf demselben Computer.

IPC
siehe Interprozesskommunikation

Java
Java ist eine objektorientierte Programmiersprache. Mit Java werden meist keine herkömmlichen Programme in Maschinensprache erzeugt, sondern Bytecode, der dann in einer speziellen Laufzeitumgebung ausgeführt wird.

Konsole
Eine Konsole ist die Einheit zur Befehlseingabe und zur Ausgabe der Befehlsergebnisse eines Computers

LUA
Lua ist eine imperative und erweiterbare Skriptsprache zum Einbinden in Programme, um diese leichter weiterentwickeln und warten zu können.

Funktion
Eine Funktion ist eine Unterroutine eines Programms. Hauptmerkmal einer Funktion ist es, dass sie ein Resultat zurückliefert und deshalb im Inneren von Ausdrücken verwendet werden kann.

Skript
Programme, die in Skriptsprachen geschrieben sind, werden Skripte genannt

Methode
In der objektorientierten Programmierung ist mit Methoden ein Konstrukt gemeint, welches das Verhalten von Objekten beschreibt.

MOD
Eine Mod ist eine Erweiterung bzw. Veränderung eines Computerspiels. 

Modding
Modding bezeichnet das Verändern oder erweitern eines Computerspiels

Netzwerktransparenz
Mit dem Begriff Netzwerkstransparenz bezeichnet man die Fähigkeit eines Protokolls nachvollziebar für die Anwendung Daten über ein Computernetzwerk auszutauschen

Objekt einer Klasse
Ein Objekt bezeichnet in der objektorientierten Programmierung (OOP) ein Exemplar eines bestimmten Datentyps oder einer bestimmten Klasse

OpenGL
OpenGL ist eine Spezifikation für eine plattform- und programmiersprachenunabhängige Programmierschnittstelle zur Entwicklung von 2D- und 3D-Computergrafik. 

Ortstransparenz
Ortstransparenz bedeutet in der Programmierung, dass der Benutzer einer verteilten Anwendung den tatsächlichen Ort des angefragten Objektes oder der angefragten Ressource nicht kennen muss. Der Name eines Objektes enthält daher auch keine Informationen über dessen Ort.

PHP
PHP ist eine Skriptsprache, die hauptsächlich zur Erstellung dynamischer Webseiten oder Webanwendungen verwendet wird.

Rechtemanagement
Rechteverwaltung bezeichnet Verfahren, mit denen die Nutzung digitaler Medien kontrolliert und verwaltet werden soll.

Schnittstelle
Die Schnittstelle oder auch das Interface ist der Teil eines Systems, der der Kommunikation dient.

SCRUM
Scrum ist ein Vorgehensmodell der agilen Softwareentwicklung.

Server
Ein Server ist unter Anderem ist ein Programm, das mit einem anderen Programm, dem Client, kommuniziert, um ihm Zugang zu speziellen Funktionen zu verschaffen.

Simulation
Simulation kann definiert werden als ein Sammelbegriff für die Darstellung oder Nachbildung physikalischer, technischer, biologischer, psychologischer oder ökonomischer Prozesse oder Systeme durch mathematische oder physikalische Modelle, wobei die Untersuchung des Modelles einfacher, billiger oder ungefährlicher als die des Originals ist und die Erkenntnisse Rückschlüsse auf die Eigenschaften des Originals erlauben.

Skeleton
Skeleton wird im Bereich Programmierung für eine automatisch generierte Struktur verwendet, die ein Programmierer oder Benutzer dann ausbauen kann.

SOAP
SOAP ist ein Netzwerkprotokoll, mit dessen Hilfe Daten zwischen Systemen ausgetauscht und Remote Procedure Calls durchgeführt werden können.

Sockets
Ein Socket ist ein Software-Modul, mit dessen Hilfe sich ein Computerprogramm mit einem Rechnernetz verbinden und mit anderen Computern Daten austauschen kann. 

Sprachtransparenz
Bei Anwendung die mittels mehrerer verschiedener Programmiersprachen realisiert wurden soll die Interaktionen zwischen einzelnen Teilkomponenten unabhängig von der Programmiersprache sein, die für die Implementierung der jeweiligen Teilkomponente benutzt wurde.

Stub
Die Funktionalität eines entfernten, nur über ein Netzwerk erreichbaren Softwaresystems wird auf dem lokalen System in Form einer „Stub-Komponente“ zur Verfügung gestellt.

Thread
Ein Thread bezeichnet in der Informatik einen Ausführungsstrang oder eine Ausführungsreihenfolge in der Abarbeitung eines Programms.

WSDL
Die Web Services Description Language (WSDL) ist eine plattform-, programmiersprachen- und protokollunabhängige Beschreibungssprache für Netzwerkdienste (Webservices) zum Austausch von Nachrichten auf Basis von XML.

XML
XML, ist eine Auszeichnungssprache zur Darstellung hierarchisch strukturierter Daten in Form von Textdaten.

[1] ABRAMI, PFAFF, STRUWE; Der APS Sumulator; URL: http://www.basys.fh-frankfurt.de/dokuwiki/de:simulator2.0; Datum: 01.07.2011

[2] CRYMOD; Crytek´s Official Modding Community; URL: http://www.crymod.com/; Datum: 28.06.2011.

[3] CRYTEK; CryENGINE 2; URL: http://crytek.com/cryengine/cryengine2/overview; Datum: 05.06.2011

[4] BORIS GLOGER, Scrum – Produkte zuverlässig und schnell entwickeln, 2009; ISBN: 978-3446419131

[5] IT-AGILE, Die Experten für agile Softwareentwicklung; URL: http://www.it-agile.de/scrum.html; Datum: 10.07.2011

[6] MARC LAYER; Corba Dienste; URL: http://www.marclayer.de/stud/proj/cos/CORBAservices.php; Datum: 03.06.2011

[7] RIAS A. SHERZAD; WebService in Java; URL: http://www.theserverside.de/webservice-in-java/; Datum: 03.06.2011

[8] CHRISTIAN JÄNICKE; Grundlagen – SOAP; URL: http://www.bitworld.de/index.php/grundlagen/soap: Datum: 03.06.2011

[9] STEPHAN BÖGEL; RMI- Remote Method Invocation; URL: http://www.sbgl.de/rmi/; Datum 03.06.2011

[10] R. LERUSALIMSCHY, L. H. DE FIGUEIREDO, W. CELES; LUA 5.1 Reference Manual; URL: http://www.lua.org/manual/5.1/: Datum: 12.06.2011

[11] BJARNE STROUSTUP; Einführung in die Programmierung mit C++, 2010; ISBN: 978-3868940053

[12] gSOAP; Toolkit Software Download Instruction; URL: http://www.cs.fsu.edu/~engelen/soap.html; Datum: 04.06.2011