User Tools

Site Tools



We want to picture the the work of the project team “Simulation”(Ernst, Roepke) within the 2011 summer semester. The implementation of the concept, written in the first semester was started.

After an introduction, which will define the starting point of our work, the goal and the process model will be described.

Afterwards we present the concept and the implementation-details that are based on it. We will point out the results and the current project status.

We produced two videos were created, demonstrating the application. The primary focus of the project was to keep accessibility and transparency. These two aspects were always considered as necessary during the project implementation. The documentary ends with a conclusion and look-out.

Introduction and motivation

In the first semester the project team did the first milestone for a simulation software using the physics and graphics engine from Crytek.

Therefore a concept was developed and we will keep on working on it. New ideas are developed while communicating with other teams.

Several motivation aspects derive by seeing a parallel project: The “APS Simulator” that is becoming more and more interesting and important.

The Team of the “APS Simulator” has developed a software that controls a virtual robot in a simulated room. The graphical output is separated from the program logic and is based on OpenGL.

One target of our project was to produce a graphically output for the Simulator


In our project concept we defined several different objectives for our simulation software. These can be presented in an accessible way. The following figure shows these schematically:


Reference point Description
A The software simulates a space similar to a modern computer game
B A user can log in and interact in the simulated space by using a computer standing anywhere in the world
C A clearly defined interface software give developers the opportunity to develop software that can access, interact, read values within the simulated space automatically without the intervention of a user
D The simulated space is designed to give multiple users the possibility to move within the simulated room simultaneously and influence each other
E The presence in the simulated space can be a human avatar. Here are several possible characters
F The amount of avatars includes not only human models, also robot models are possible
G An avatar that is controlled, but has a defined level of independent action and reaction is conceivable
H The representation of the simulated space is not limited to one model per user / program. There are predefined expert systems with different characters available, which can move independently in space or become moved by a user.
I The user can connect as a mere observer in the simulated space
J On the side of the participants, the simulation is presented acoustically and visually
K Only clear signals are send to the simulated room
L All access to the simulated space, whether by man or program is done via a uniform interface

By implementing these basic functionalities, several objectives can be achieved. Using a modular implementation will help to combine these functions an help teams to work parallel and efficiently.

The aim of the current project team was to implement a set of basic functions during the summer semester 2011:

Goal is the conception and implementation of an external program for gaining access to the simulated room through a defined interface.

This goal is shown in the schematic representation of the project “simulation” with the points B, L and K, and marked by the following figure in the concept:


Reference point Description
A The software simulates a space similar to a modern computer game
B A user can log in and interact in the simulated space by using a computer standing anywhere in the world
K Only clear signals are send to the simulated room
L All access to the simulated space, whether by man or program is done via a uniform interface

Another goal is to ensure accessibility, location and network transparency.


Konstantin Ernst, B. Sc. -

Edward Roepke, B. Sc. -

Process Model

A process model is a manual that divides a project into different phases to structure and lead the development. The work is organized and set to a correct order to simplify the implementation of a project.

There are different development models available. We organize our project with the Scrum process model.

Scrum is one of the most popular process models using agile methods. It allows the customer in cooperation with the the product owner to set up a so-called Product Backlog for the requirements of development, which can be easily extended or modified.

In addition, this process model has the advantage that the center is the development team that can work independently without any other influences, and does not need a project manager.

The ScrumMaster helps the team and avoids disturbing influences from outside and ensures the compliance with the procedures.

The product owner must define the requirements that are worked out with the customer and prioritize and divide them into small packets.

Together with the team the Sprint Backlog is formed out of the Product Backlog. It contains all elements that will be processed within the next sprint. The team than implements these elements in the Sprint, which can last between one and four weeks. During a sprint, the team works undisturbed and no new requirements are made. The team meets in a short-Daily Scrum and responds to three questions:

  • What have I done since the last Daily Scrum?
  • What has hindered me?
  • What will I do until the next Daily Scrum?

After a sprint a review (Sprint Review) is done and the implementation is shown to product owner. In another review, the Sprint Restrospektive, things are discussed that have worked particularly well in the last sprint, and things that need improving.

Scrum offered multiple advantages for us:

  • clear roles
  • quickly deployable
  • extensible requirements
  • supported focus is the developing team
  • Sprints are consistent with the customer's desired presentation period

Since we are already familiar with Scrum, we were able to work out the possibilities that are offered by scrum.

The FH offered us to use a scrum online tool, which can support using Scrum. There is a platform that supports the coordination of the work. Analogous to the Scrum-process you can create a Product Backlog and fill it with requirements. It arises a listing of all items that are required for the project.

It was a challenge for us to estimate the complexity and duration of individual points in the backlog. Scrum provides to assess the complexity with so-called story points.

After the prioritization of our backlog, we have made an estimate with relative complexity weights. For the story points often numbers of the Fibonacci series are used. The scrum online tool offers a “Business Value” with the values ​​100, 200, 300, 500, 800, 1200, 2000 and 3000, with which the tasks can be evaluated in relation to each other.

The easiest to-do entry in the backlog gets the assigned 100 and the most difficult one the 3000. Then the other entries are distributed within this classification.

With this method the calculation of the required time for the tasks is possible. Afterwards the velocity of the team can be determined. This value means the amount of work that can be made by the team within a sprint. This amount results from the sum of the story points that were processed in the Sprint.

Usually, the teams, if they have already spent some time together, determine the velocity out of their experience. For new teams, or when a new employee enters into the team, the velocity can vary. A more detailed classification is possible only after several sprints. Then the team works together efficiently, and can estimate the number of story points.

In a new team the backlog item will be prioritized and selected for the sprint. Once a person of the team is uncertain whether the time of the sprint is sufficient for the tasks, the selection is canceled.

The new subject areas, such as Lua or gSOAP made an accurate assessment difficult for us, so we mostly used the second method (for new teams). To coordinate our sprints, we spread them over the time of the semester. For the period between the first lecture on 15.4.2011 and 15.7.2011 we have conducted seven sprints, which we have called from Sprint A to Sprint G.

With the online tool items can be stored in the Product Backlog and slightly set to the individual sprints and assigned to each team member.

During developing coordination was an important component. It was found that the mainly regularly performed daily scrums were a big help. The online scrum tool can improve this coordination, since it is an additional tool to focus the transmitted information at various meetings or telephone calls.

We have applied the two-weekly meetings to the sprint review in which the results were presented to fellow students and from their feedback, ideas and possibilities were arising.

Due to the small number of team members the Scrum retrospectives were not regularly. We performed the process of continuous improvement within the Daily Scrum. In conversations, it became quickly apparent what should be kept, and what should be changed.

Requirements and concept

The desired objective can be divided into three sub-goals:

  • Definition of the interface for accessing the simulated space in terms of inter-process communication
  • Development of a receiver module, which is part of the simulated room and is taking orders from outside (called “server”)
  • Development of an example program, which communicates via the interface with the server (“Client”).


With the interface to two programs or processes should communicate with each other. This is called inter-process communication (IPC). Therefore a big number of technologies is existing. The technology used for the interface had to have the following requirements:

  • The interface must provide location transparency
  • The interface must ensure network transparency
  • The interface must be transparency in terms of programming language
  • The interface must be extensible and allow future modifications
  • The interface must be replaceable to allow to switch to a different technology
  • The interface is not allowed to interfere with the simulation software.

To meet these requirements, we have developed the following concept: We use two interfaces. The first one using SOAP, the other one sockets.

For the implementation of the interface there is a thread implemented in the simulation software.

Thus both interfaces work parallel independently to the rest of the program. With the implementation in a separate thread the implementation is modular and changeable. In addition, further interfaces can parallel be implemented.

The client can connect to the preferred interface.

All interface forward the information to the server function “BaSys_Server:: process client information ()”. Thus, it does no matter which interface chosen.


The server is a program that executed the signals send through the interface. The following things are requirements for the server:

  • The server should not affect the rest of the program.
  • The Cry Engine supports the interpretation of LUA during run time. This has the advantage that own LUA scripts and functions can be implemented without modifying the program logic. The server must include functions to execute these Lua-functions. These calls must be kept generally, so new LUA scripts and functions can easily be changed by the user / developer, without compiling and rebooting the server.
  • Since the interface does not check the information sent to the content and forwards them untested to the server, there have to be access permissions implemented to the server.

To meet these requirements we have developed the following concept: For the server a separate class is created. An instance of it will be created by the interface. Thus, the functions of the server works parallel and independently from the rest of the program.

The server has a function “BaSys_CallLuaFunction”. This function takes one parameter - the name of the called LUA function.

Thus, the call of LUA scripts is independent from the function name.

A specialization of th LUA functions with one or more parameters will be done later. Rights management is an extremely important issue. However, planning and implementation does not make sense at an early stage of development.


Developers are given absolute freedom for implementation the client. Programming language and type of program can be freely chosen. The program only needs to work with the SOAP - interface. The simulation software can even be addressed through a Web browser (see PHP-SOAP Client)

Schematic representation

The concept and the interrelationships of the three sub-goals just described are shown simplified in the following figure:


Reference point Description
A The client is an external program. The language can be chosen freely. It implements the functionality to connect to an interface.
B The client sends its information to the desired interface.
C So far, there are two interfaces: SOAP and sockets. Those do not interpret the data.
D The server accepts requests from the interface and interprets the content. In the current implementation the server provides the ability to call any Lua function.
E The user / developer can define own LUA scripts and functions. These can be executed without changing the interface or the server.


Below the implementation of the concept is described.


Since the simulation software is not created from scratch as mentioned above, but formed by modification (“modding”) of the existing computer game “Crysis”, first a new mod was created.

This mod is called “BaSysMod”. Therefore, a new project in the development environment “Microsoft Visual Studio 2008” has been created. To make the preparation for the creation of this modding project as transparent as possible, we have created a video tutorial. Herein we explain the necessary steps. Below the further implementation is described.

All components were implemented within the BaSysMod.


In order to ensure consistent and clear programming, the following conventions were defined:

* C++ classes

  • The name of a class receives the prefix “BaSys_”
  • Classes are stored in the folder “BaSys”
  • Classes are preceded by a comment block containing the following information:
    • Description
    • Author
    • Version
    • Creation Date
    • Date of last modification
  • C++ functions and methods
  • In the first line of a function or method name and “- start” is logged.
    BaSys_Common::Log(“BaSys_Server::BaSys_Server - start”);
  • In the last line of a function or method name “- end” is logged.
    BaSys_Common::Log(“BaSys_Server::BaSys_Server - end”);
  • Functions and methods are preceded by a comment block that contains the following information:
    • Description
    • Author
    • Version
    • Creation Date
    • Date of last modification
    • Description of parameters
    • Description of return value
  • LUA scripts
    • LUA scripts are stored in the script directory “BaSys”, or any of its subfolders
    • File name of LUA scripts is the prefix “BaSys_” prefix.
    • The first line in a LUA script shows “LUA”, the script name and “- start”.
      Example of the script file “BaSys_Main”:
      System.LogAlways(“LUA:BaSys_Main - start”);
    • The last line in a LUA script shows “LUA”, the script name and “- end”.
      Example of the script file “BaSys_Main”:
      System.LogAlways(“LUA:BaSys_Main - end”);
  • Lua functions
    • In the first line of a function or method the name of the function and “- start” is shown.

BaSys_Log(“BaSys_examplefunction - start”)

  • In the last line of a function or method “- end” and the name of the function is shown.
    BaSys_Log(“BaSys_examplefunction - end”)
  • * Lua Functions and methods are preceded by a comment block that contains the following information:
  • Description
  • Author
  • Version
  • Creation Date
  • Date of last modification
  • Description of parameters
  • Description of return value

Main routine

To implement a main routine, the class “BaSys_Main” was created. It contains the main routine, in which the instances of the remaining BaSys classes are created and coordinated.

To run this main routine, while starting the game or the editor, an instance is created within the function “init” of the class “CGame”. In the main routine the threads for SOAP - and the socket - port are started.

The implementation is shown below:


For the implementation of the basic functionality, a new class “BaSys_Common” is created. This contains a Funktion “BaSys_Common:: Log”, which helps the developer debugging. It logs several informations to a file. It was implemented as shown below:

LUA functionality

To comfortably gain access to the engine's internal script system, a class “BaSys_LUA” was created. Here we selected methods simplifying access to the engine's internal script system. So far there are two functions:

  • BaSys_LUA::loadScriptFile (ScriptFilePath)
    This function loads a script file. If the developers / users write own Lua functions, these file must first be loaded before the function can be called. This is done by this function. We have you implemented as shown below:
  • BaSys_Lua::call (FunctionName)
    This function calls an LUA function. We have implemented this function as shown below:

===== Interface - Sockets For the interface a class “BaSys_TCP_Interface” was initially created. This derives from the class CryThread. To start the thread of the interface, an instance is generated in the class “BaSys_Main” and the method “start ()” is called. The interface thus runs parallel to the rest of the program as desired.

Interface - SOAP

SOAP is a protocol for exchanging XML-based messages. It is recommended by the World Wide Web Consortium (W3C) to be used for cross-platform RPC. It regulates with specification of a framework how data and remote procedure calls should be made. It does not matter which semantics is used. SOAP can be used to invoke remote processes, or as a messaging system to exchange data.

SOAP is used especially when the compatibility between systems is necessarily. SOAP is very flexible because of its open design. Disadvantages of SOAP protocol are the high transmission volumes. This also increases the computational requirement. With SOAP a XML document is created at the transmitter and then validated.

To provide flexibility, metadate is inserted during creating. Even simple queries are enlarged by this. On the other hand complex transactions can be summarized by the flexible structure. This is advantageous to strongly coupled systems, because transfers can be made in one request.

A SOAP message consists of two elements: an optional header and a body, named envelope. In the header, the meta-information about, for example, routing, encryption, or the transaction identification is placed. The envelope has a namespace attribute that is referenced. Structure of a SOAP message:

<?xml version=“1.0”?>
<s:Envelope xmlns:s=“”>

In the body statements of procedure calls or information for data exchange are available. SOAP is language-tolerant and can be implemented in any programming language. In addition, SOAP provides network transparency.

Compared to other protocols such as CORBA or RMI, SOAP provides the possibility of easy implementation. Because SOAP communicates using HTTP, port shares or firewalls are no problem.

In particular, the gSOAP framework has been used. gSOAP is an open source development environment for Web services. It supports C and C++ and is optimized for performance. Since the compression of gSOAP supports XML data, the data volume is reduced. Because the source code is freely available, it can be readily adapted.

gSoap provides an automated connection between XML and C++. By automatically generating code the development effort is simplified. gSoaps own compiler creates WSDL, SOAP and XML-specific elements without intervention by the user. At the same time, automatically secures and guarantees various elements, such as validity, memory management and serialization.

The user must care about WSDL / SOAP / XML items, he can delegate this task to gSoap.

To use gSoap the gSoap package in addition to a C++ compiler is required.

The SOAP package includes two executable files:

  • wsdl2h.exe - Creates header files by using a WSDL file
  • soapcpp2.exe - Generates the stubs and skeletons for the client and server.

The gSoap wsdl2h imports one or more WSDL and XML files and generates a header file with C / C++ syntax for the Definition of the Web services. The gSoap soapcpp2 compiler then takes this header file and generates XML serializer for the data (soapH.h and soapC.cpp), the client-side stubs (soapClient.cpp) and the server-side skeletons (soapServer.cpp).

With the soapcpp2-compiler it is also possible to create a header file without the prior WSDL definitions.

Using soapcpp2.exe -2 -S -j BaSysService.h all necessary files are generated. Information on the paraments: In the BaSysService.h some information are needed for gSoap:

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);

gSoap takes the needed information: name, type, namespace, function and its parameters.


For the server the class “BaSys_Server” was created. In the first instantiation the LUA script “\ Mods \ BaSysMod \ Game \ Scripts \ BaSys \ BaSys_Main.lua” is loaded (This is the starting point for future scripts). In this script other BaSys scripts are loaded i. e. the script “BaSys_example.lua”, which contains a sample function. Because the functionality to access the internal LUA scripting system is encapsulated in a class “BaSys_LUA” to make access easy, it shows that the implementation of the class “BaSys_Server” is very simple: Since the server receives and calls only a LUA function from the interface and we already have created a class BaSys_LUA that simplifies this call up, we could implement this functionality in just a few lines:

So is the implementation of server is ready.

Client – Sockets

As an example we have created a simple, applications which addresses the BaSysMod and provide the ability to send strings to the interface. This client can be downloaded in the download section. The following image shows the program:

Client – SOAP

We have developed two clients for the SOAP protocol to check the flexibility. A Java- and a PHP-Client was created.

Withe an IDE (i. e. Netbeans) it is possible to generate the stubs out of a WSDL-file.

Afterwards the functions of the server can be called:

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

Furthermore a PHP-Client was developed that is also using the information out of the WSDL to send the XML-call. The Quellcode is quite small:

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” />

The XML-call that is send an the server is shown below:

<soap:Envelope xmlns:soap=“” xmlns:urn=“urn:basysservice”>

'' <soap:Header/> ''
'' <soap:Body> ''
  '' <urn:callLuaScript> ''



To demonstrate the application of our software without installation effort, we have created two videos. These are described below. The download is in the download area.

Video 1 - Creating your own Crysis Mod In this video we show independently of the project, how to make your own mod from setting up the development environment, “Microsoft Visual Studio 2008” to compiling and testing.

Video 2 - The BaSysMod In this video tutorial we will presented our mod “BaSysMod”. The video shows, how to insert our project files and how to set up „Microsoft Visual Studio 2008“. The functions and components are described. The video end with an demonstration of our mod.


Accessibility is the principle and goal for all BaSys projects .

So we have assigned the highest priority to accessibility.

The concept of accessibility as comprehensively implemented. We consider our first project from two perspectives:

  • The project itself, which aim is to create a software.
  • The result of the project, the software itself

In these two points, the principle of accessibility is implemented in a separate way. These are explained in more detail in the following two chapters.

With these Three concepts we ensure accessibility to this project:

  • Accessibility
  • Transparency
  • Multilingualism

To provide every person the opportunity to understand the project development and all development steps easily, every step is documented and accessible to everyone within this wiki.

This documentation is designed for people from all disciplines and not only to the department of computer science. It is a particular challenge to provide such a complex and computer science oriented project for people without in-depth knowledge of computer science. Therefore the project team asks for criticism and inspiration.

To eliminate another barrier, the documentation is maintained in parallel in German.

Accessibility in the simulation

For software development there are also proven techniques in order to enforce accessibility:

  • Access transparency and network transparency
  • Performance transparency

These points are concepts from computer science and very technical.

All listed forms of transparency have been included in the concept of the software.


Project Management

We used SCRUM as project management tool.

Project Dokumentation

The project documentation is accessible at all time by using a wiki. Changes, corrections and additions can be made by any BaSys students. We welcome any form of participation in our project.

Feedback and suggestions

We are open and gratefull for feedback, criticism and inspiration. Please mail to one of the project-members.

Conclusion and outlook

During this semester we have successfully implemented a first aspect of our concept derived from the Project “simulation”

In the first phase, we have pointed out the requirements, always with the aspect of accessibility.

During the implementation phase, the concept was adjusted from time to time.

An external application can now connect to our server by using the two interfaces.

The internal transmission of information works as planned and allows to call a Lua function. We see a big potential for the achievement of other goals within the simulation project concept.

Through open communication within the interdisciplinary lectures, we have gained new inspiration for the project.


Aktuelle Projektdateien

Datum Kurzbeschreibung Download
11.07.2011 BaSysMod mit TCP Client und compilierter BaSysMod.dll.
Socket-Schnittstelle startet im Thread, Server ruft LUA-Funktionen auf.

Weitere Software

Datum Kurzbeschreibung Download
11.07.2011 Einfacher TCP Client, verbindet sich mit beliebiger IP auf Port 666, sendet und empfängt Textnachrichten Download
11.07.2011 Einfacher Java-SOAP Client, verbindet sich auf localhost mit Port 6666 Download
11.07.2011 Einfacher PHP-SOAP Client, verbindet sich auf localhost mit Port 6666 Download


Datum Titel Autor Download
11.07.2011 Erstellung eines Crysis-Mod Konstantin Ernst Download
11.07.2011 Der BaSysMod Konstantin Ernst Download


[1] ABRAMI, PFAFF, STRUWE; Der APS Sumulator; URL:; Datum: 01.07.2011

[2] CRYMOD; Crytek´s Official Modding Community; URL:; Datum: 28.06.2011.

[3] CRYTEK; CryENGINE 2; URL:; 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:; Datum: 10.07.2011

[6] MARC LAYER; Corba Dienste; URL:; Datum: 03.06.2011

[7] RIAS A. SHERZAD; WebService in Java; URL:; Datum: 03.06.2011

[8] CHRISTIAN JÄNICKE; Grundlagen – SOAP; URL: Datum: 03.06.2011

[9] STEPHAN BÖGEL; RMI- Remote Method Invocation; URL:; Datum 03.06.2011

[10] R. LERUSALIMSCHY, L. H. DE FIGUEIREDO, W. CELES; LUA 5.1 Reference Manual; URL: 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:; Datum: 04.06.2011

You could leave a comment if you were logged in.
en/basysmod.txt · Last modified: 2014/11/24 12:37 (external edit)