Bachelorthesis Evaluierung von 3D Game

Transcription

HOCHSCHULE REUTLINGEN
Alteburgstraße 150
72762 Reutlingen
Fakultät für Informatik
Studiengang Medien- und Kommunikationsinformatik
BACHELORTHESIS
EVALUIERUNG VON 3D GAME ENGINES
Bearbeiter
Dennis Schneider
Gustav-Schwab-Str. 5
72762 Reutlingen
Matrikel Nr.: 062148
Betreuer
Prof. Dr. rer. nat. Uwe Kloos
Prof. Dr. -Ing. Wolfgang Keller
Datum 18.01.2010
Danksagung
Die vorliegende Arbeit entstand im Rahmen meiner Bachelor Thesis an der Hochschule
Reutlingen, Fakultät Informatik, Studiengang Medien- und Kommunikationsinformatik.
„Denk falsch, wenn du magst, aber denk um Gottes Willen für dich selber.”
Doris Lessing
Ich danke meiner Freundin, meinen Eltern, meinen Freunden und meiner Familie für ihre
ständige Unterstützung sowie meinem Betreuer Herr Prof. Kloos für seine hervorragende
Betreuung.
ii
Kurzfassung
Diese Bachelor Thesis behandelt die Evaluierung von 3D Game Engines. Im Laufe der Arbeit
wird untersucht, ob sich Game Engines für den Einsatz in der Lehre eignen. Dabei wird in
einem Kapitel auf die Unterschiede gewöhnlicher Grafik Engines bzw. Rendering Engines
und Game Engines eingegangen. Es werden auch die verschiedenen Anwendungsgebiete,
sowie die wichtigsten Komponenten von Game Engines erläutert. Im weiteren Verlauf werden
die Vorgehensweise und die Methoden bei der Auswahl und Bewertung der Game Engines
beschrieben. Unter Verwendung einer Engine wird anschließend die Konzeption und Implementierung einer Anwendung erklärt, mit der zum einen die Engine demonstriert und zum
anderen gezeigt werden soll, wie die Theorie der Computer Grafik praktisch und spielerisch
erlernt werden kann. Ein Kapitel ist der Engine selbst gewidmet, in welchem sie genauer
erläutert wird. Zur weiteren Evaluierung der Anwendung wurde außerdem ein Fragebogen an
Personen verschickt, die am Kurs Computer Grafik derzeit teilnehmen oder teilgenommen
haben, um die Anwendung und deren Wirkung zu testen. Die Ergebnisse wurden anschließend
ausgewertet und werden im Laufe der Arbeit erläutert.
Abstract
This Bachelor Thesis describes the evaluation of 3D game engines. Throughout this Thesis it
will be evaluated if game engines are suitable for the assigment of teaching. Thereby the
differences of usual graphics engines respectively rendering engines and game engines will be
discussed. The different fields of application as well as the most important components of a
game engine will also be shown. In the further process the approach and the specific methods
for the selection and rating of the game engines will be described. The implementation and
the concept of an application using such a game engine will be discussed. The purpose of
the application is to demonstrate the used engine and to show how it is possible to learn
computer graphics practically and playfully. The used engine has its own chapter in which it
is specified more carefully. For the further evaluation of the application a questionnaire has
been sent to different persons who are attending or have attended the course of computer
graphics in order to test the application and its effects. The results have then been evaluated
and are described closer throughout this Thesis.
iii
Beschreibung der verwendeten Technologien
Die Entwicklung der Anwendung für diese Thesis wurde auf zwei Betriebssystemen parallel
vorgenommen, um auch tatsächlich die volle Plattformunabhängigkeit des Quellcodes zu
testen. Dadurch sollten auch Unterschiede bei der Verwendung der beiden Grafikschnittstellen
OpenGL und DirectX festgestellt werden. Zur Entwicklung des Spiels unter Kubuntu Linux
wurde als Entwicklungsumgebung Eclipse1 Version 3.5.0 „Galileo“ mit dem Plugin CDT 23
verwendet. Mit CDT wird es möglich, C / C++ Projekte auf der Eclipse IDE 4 zu entwickeln.
Unter Windows XP wurde für die Entwicklung Visual Studio 2008 verwendet. Als 3D Game
Engine diente das OGRE SDK 5 in der Version 1.6.3 „Shoggoth“. Für die Erstellung von
Grafiken für die Anwendung und für dieses Dokument wurden die kostenlosen Programme
„The GIMP“6 und „Inkscape“7 benutzt. Für die Diagramme der Unified Modelling Language
wurde das frei verfügbare Programm „Umbrello“8 eingesetzt.
In der vorliegenden Arbeit werden englische Fachbegriffe bei ihrer ersten Nennung kursiv
dargestellt.
Begriffsklärung
Diese Thesis behandelt als Thema die Evaluierung von 3D Game Engines. Jedoch werden
auch Engines in die Evaluierung mit einbezogen, die an sich in ihrer Grundform keine Game
Engines, sondern nur reine Rendering Engines bzw. Grafik Engines sind. Durch vorhandene
sogenannte Wrapper und externe Bibliotheken lassen sich diese Rendering Engines aber zu
vollwertigen Game Engines erweitern. An dieser Stelle wird ausdrücklich darauf hingewiesen,
dass auch diese reinen Rendering Engines in dieser Arbeit als „Game Engines“ bezeichnet
werden und nicht für jede Form einer Engine der Begriff explizit differenziert wird. An manchen
Stellen werden sie auch schlicht „Engines“ genannt.
1
http://www.eclipse.org/
C/C++ Development Tooling
3
http://www.eclipse.org/cdt/
4
Integrated Development Environment (dt. Integrierte Entwicklungsumgebung)
5
Software Development Kit
6
http://www.gimp.org/
7
http://www.inkscape.org/
8
http://uml.sourceforge.net/
2
iv
Inhaltsverzeichnis
1 Einleitung
1.1 Motivation und Relevanz . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Struktur dieser Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Game Engines
2.1 Einführung und Grundlagen . . . . . . . . . . . . . . . .
2.1.1 Der Unterschied zwischen einer Grafik Engine und
2.1.2 Die Komponenten einer Game Engine . . . . . .
2.2 Populäre Game Engines . . . . . . . . . . . . . . . . . .
2.2.1 Kommerziell . . . . . . . . . . . . . . . . . . . .
2.2.2 Open Source / Kostenlos . . . . . . . . . . . . .
2.3 Anwendungsgebiete . . . . . . . . . . . . . . . . . . . .
2.3.1 Spiele . . . . . . . . . . . . . . . . . . . . . . .
2.3.2 Virtuelle Realität und Simulationen . . . . . . . .
2.3.3 Informationsvisualisierung . . . . . . . . . . . . .
2.3.4 Visualisierung von Gebäuden und Landschaften .
2.3.5 Medizin . . . . . . . . . . . . . . . . . . . . . .
2.3.6 Lehre . . . . . . . . . . . . . . . . . . . . . . . .
. . .
einer
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
1
1
2
3
. . . . . . . .
Game Engine
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
5
5
5
6
11
11
13
16
16
16
18
19
20
21
3 Evaluierung der Game Engines
3.1 Vorgehensweise . . . . . . . . . . . . . . .
3.2 Gewichtung der Kriterien . . . . . . . . . .
3.3 Ergebnisse der Nutzwertanalyse . . . . . . .
3.4 Auswahl der zu verwendenden Engine . . .
3.5 Demonstration und Ansätze für die Lehre .
3.6 Erstellung und Auswertung des Fragebogens
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
23
29
31
34
35
37
4 OGRE
4.1 Engine Einführung . . . . . . . . . . . . .
4.2 Struktur und Aufbau von OGRE . . . . .
4.2.1 Root Objekt . . . . . . . . . . . .
4.2.2 Szenenmanager und Szenengraph .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
40
40
42
42
42
.
.
.
.
v
Inhaltsverzeichnis
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
44
44
45
46
5 Konzeption
5.1 Spielkonzept . . . . . . . . . . . . . . . . . . . . . .
5.1.1 Grundlagen der Spielemechanik . . . . . . . .
5.1.2 Übertragung auf das eigene Spielkonzept . . .
5.2 Anforderungen . . . . . . . . . . . . . . . . . . . . .
5.2.1 Zielbestimmung und Einsatz der Anwendung
5.2.2 Produktumgebung . . . . . . . . . . . . . . .
5.2.3 Qualitätszielbestimmungen . . . . . . . . . .
5.2.4 Weitere Teile des Pflichtenheftes . . . . . . .
5.3 Architektur . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
49
49
49
52
53
53
54
55
56
56
.
.
.
.
.
.
.
.
58
58
59
60
65
72
72
74
74
4.3
4.2.3 Ressourcenmanagement . . . . . . .
4.2.4 Render Systeme und Render Targets
4.2.5 OGRE Manager . . . . . . . . . . .
Erweiterungen für OGRE . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6 Implementierung
6.1 Grundlagen . . . . . . . . . . . . . . . . . . . . . .
6.2 Struktur und Aufbau . . . . . . . . . . . . . . . .
6.2.1 Klassen . . . . . . . . . . . . . . . . . . .
6.2.2 Implementierung der Ansätze für die Lehre .
6.3 Probleme und Lösungen bei der Implementierung .
6.3.1 Kollisionserkennung . . . . . . . . . . . . .
6.3.2 Laden und Entladen der Levels . . . . . . .
6.3.3 Darstellung von Terrain . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7 Fazit und Ausblick
76
7.1 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
7.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Literaturverzeichnis
A Anhang
A.1 Tabellen der Nutzwerte untersuchter Engines . . . . . . .
A.2 Installation des Spiels . . . . . . . . . . . . . . . . . . . .
A.3 Installation und Einrichtung des OGRE SDKs . . . . . . .
A.3.1 Manuelle Erstellung . . . . . . . . . . . . . . . . .
A.3.2 Erstellung mit Hilfe des OGRE Application Wizards
A.3.3 Fehlerquellen . . . . . . . . . . . . . . . . . . . .
A.4 Fragebogen . . . . . . . . . . . . . . . . . . . . . . . . .
79
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
93
93
96
97
98
105
105
106
vi
1 Einleitung
1.1 Motivation und Relevanz
Computer- und Videospiele erlangen zunehmend einen höheren Status in unserer heutigen
Kultur. Waren sie früher gesellschaftlich mehr oder weniger verpönt, gibt es heutzutage sogar
ganze Verbände und Wettkämpfe rund um Computer- und Videospiele, genannt E-Sport 1 .2 In
Ländern wie Südkorea haben Spieler von Computer- und Videospielen sogar den Status eines
Stars, vergleichbar mit einem Sänger oder Filmstar in den westlichen Ländern. Computerund Videospiele stellen einen neuen Teil der Unterhaltung dar. Im Gegensatz zu Filmen
oder Büchern ist die Teilnahme am Computer- oder Videospiel interaktiv. Man bewegt sich
selbstständig, man trifft eigene Entscheidungen und erlebt die Geschichte hautnah. Man
tritt quasi selbst in die Hauptrolle der Geschichte. Die Spiele lassen es mittlerweile sogar
zu, Einfluss auf die Handlungen zu nehmen. Waren Spiele früher ausschließlich linear, ist es
heute möglich, verschiedene Wege innerhalb der Spiele zu gehen und somit zu alternativen
Enden zu gelangen. Laut einer Pressemitteilung des Statistischen Bundesamt Deutschland
aus dem Jahre 2004 verbringen vor allem Jugendliche zwischen 15 und 17 Jahren täglich eine
Stunde vor dem Computer mit Computerspielen. Je älter die Personen, desto weniger dient der
Computer als Freizeitinstrument.3 Einen neuen Weg hat hier die Nintendo Wii eröffnet, mit
der sogar die obersten Altersgruppen spielen, da sie einen komplett neuen Weg der Interaktion
bietet. Weltweit werden verschiedene Konferenzen wie beispielsweise die gamescom4 in Köln
abgehalten, in deren Mittelpunkt interaktive Spiele und Unterhaltung stehen.
Die Absichten von Spielen haben sich stellenweise ebenfalls verändert. Stand früher ausschließlich die Unterhaltung im Vordergrund, gibt es heutzutage Spiele, die auf einen Lernoder Ausbildungseffekt abzielen - sogenannte Serious Games. Es gibt Spiele wie Anatomy of
1
elektronischer Sport
Vgl. Süddeutsche Zeitung (2009)
3
Vgl. Statistisches Bundesamt (2009)
4
http://www.gamescom.de/
2
1
1 Einleitung
Care 5 , bei dem Krankenschwestern bzw. Krankenpfleger den Umgang mit Patienten lernen
sollen oder beispielsweise Global Conflicts 6 , bei dem Schüler einen Journalisten verkörpern,
Artikel schreiben müssen und so beispielsweise Konflikte wie etwa zwischen Palästina und
Israel verständlich gemacht werden sollen. Es existieren auch Advergames, die ausschließlich
auf den Zweck der Werbung abzielen. Ein nennenswertes Beispiel ist hier Americas Army 7 ,
ein Spiel, das von der US Armee zur Anwerbung und Rekrutierung von Soldaten dient. In
diesem Zusammenhang sollte auch der wirtschaftliche Nutzen von Computer- und Videospielen genannt werden: Allein in Deutschland liegt der Umsatz von Computerspielen laut dem
Interessenverband Bundesverband Interaktive Unterhaltungssoftware im Halbjahr 2009 bei
649 Millionen Euro. Im Zeitraum von Januar bis Juni des Jahres 2005 lag der Umsatz bei 474
Millionen Euro. Hier kann man die starke Entwicklung des Marktes für Videospiele beobachten,
immerhin handelt es sich um einen erhöhten Umsatz von 175 Millionen Euro für das erste
Halbjahr.8
War es früher üblich, ein Spiel komplett von Grund auf selbst zu entwickeln, wird heute mit
Hilfe von sogenannten Game Engines die Entwicklung vereinfacht. Ein Teil dieser Engines
ist sogar kostenlos verfügbar. Dies eignet sich perfekt für Hobby-Entwickler, Studenten und
natürlich auch für Personen, die mit der Entwicklung von Spielen Geld verdienen möchten.
Diese Game Engines selbst werden nicht nur für die Entwicklung von Spielen verwendet,
sondern auch für etwaige andere Zwecke. Betrachtet man die verschiedenen Einsatzzwecke
genauer, so liegt es nur nahe, solche Engines auch für die Lehre einzusetzen. In dieser Arbeit
sollen entsprechende Engines gefunden und evaluiert werden, die zur Lehre des theoretischen
Hintergrunds der Computer Grafik verwendet werden können.
1.2 Zielsetzung
Ziel dieser Arbeit ist es, 3D Game Engines zu finden, welche im Kurs Computer Grafik
der Hochschule Reutlingen zur spielerischen und praktischen Vermittlung der Theorie von
Computer Grafik verwendet werden können. Zudem soll geprüft werden, ob diese Art der
Vermittlung auch sinnvoll ist. Zu Beginn wird eine Übersicht über verschiedene signifikante
5
http://www.willinteractive.com/the-anatomy-of-care
http://www.globalconflicts.eu/
7
http://www.americasarmy.com/
8
Vgl. Bundesverband Interaktive Unterhaltungssoftware (2009)
6
2
1 Einleitung
Game Engines, deren Komponenten und auch deren unterschiedliche Anwendungsgebiete
gegeben. Anschließend werden diverse Game Engines zusammengetragen, die sich für die Lehre
eignen könnten. Im weiteren Vorgehen wird anhand bestimmter Kriterien eine Bewertung
dieser Engines vorgenommen. Die Engines mit der höchsten Bewertung werden anschließend
ausgewählt und genauer betrachtet. Sie werden noch einmal tiefergehend auf die Kriterien
geprüft und gegeneinander abgewogen. Die Engine mit der höchsten Bewertung wird anhand
eines Spieles demonstriert, mit dem auch die theoretischen Konzepte der Computer Grafik
vermittelt werden sollen. Die Schwerpunkte bei der Implementierung liegen dabei auf der
Demonstration der Fähigkeiten der Engine und der Vermittlung der Konzepte der Computer
Grafik. Mit Hilfe eines Fragebogens soll außerdem ausgewertet werden, ob die Theorie
praktisch und spielerisch erlernt werden kann. Dieser Fragebogen wird an verschiedene
Studenten verschickt, die am Kurs Computer Grafik der Hochschule Reutlingen derzeit
teilnehmen oder bereits teilgenommen haben.
Bei der Auswahl wird auf kommerzielle Engines verzichtet.
1.3 Struktur dieser Thesis
Diese Thesis ist folgendermaßen strukturiert:
• Kapitel 2 beschreibt das Thema Game Engines ausführlich. Es wird dabei auf die
Grundlagen von Game Engines eingegangen. Es werden Begriffe geklärt, populäre
Beispiele für Game Engines genannt und Anwendungsgebiete und aktuelle Entwicklungen
vorgestellt
• Kapitel 3 behandelt die Evaluierung der Game Engines und geht dabei konkret auf die
Vorgehensweisen und Methoden bei der Evaluierung sowie die daraus resultierenden
Ergebnisse ein
• Kapitel 4 präsentiert die durch die Evaluierung ausgewählte Engine OGRE. In Diesem
Kapitel wird eine Einführung in OGRE gegeben, die Struktur und der Aufbau der Engine
erklärt und einige wichtige Erweiterungen vorgestellt
• Kapitel 5 widmet sich der Konzeption der Anwendung auf Basis von OGRE
• Kapitel 6 zeigt die konkrete Implementierung und damit verbunden die Struktur der
Anwendung, die Implementierung der Ansätze für die Lehre und die dabei aufgetretenen
Probleme und deren Lösungen
3
1 Einleitung
• Kapitel 7 fasst die Erkenntnisse dieser Arbeit zusammen und gibt einen Ausblick für
die Zukunft
• Der Anhang beinhaltet die Installationsanleitung für die im Rahmen dieser Arbeit
entwickelten Anwendung, eine Installationsanleitung für das OGRE SDK, sowie nicht
aufgeführte Tabellen der Nutzwertanalyse aus Kapitel 3 und den Fragebogen
4
2 Game Engines
In diesem Kapitel wird ein Überblick über das Thema Game Engines gegeben. Dabei wird auf
die Grundlagen eingegangen. Es wird unter anderem erläutert, wo der Unterschied zwischen
einer Game Engine und einer reinen Grafik Engine bzw. Rendering Engine liegt. Darüber
hinaus soll ein Einblick in die Anwendungsgebiete von Game Engines ermöglicht werden. Am
Ende des Kapitels wird auf die aktuellen Entwicklungen und einige populäre Beispiele für
kommerzielle sowie quelloffene (engl. open source) Game Engines eingegangen.
2.1 Einführung und Grundlagen
2.1.1 Der Unterschied zwischen einer Grafik Engine und einer Game Engine
Eine Grafik Engine hat auf unterster Ebene die Verantwortung, die Objekte zu zeichnen, die
ein Betrachter sieht. Der Programmierer einer Engine verwendet typischerweise eine GrafikAPI wie OpenGL oder Direct3D, um einen Renderer zu programmieren, welcher die Objekte
korrekt zeichnen muss. Auf manchen Plattformen existiert keine Hardwarebeschleunigung
oder eine Standard API ist nicht verfügbar, somit muss der Programmierer möglicherweise
das gesamte Grafiksystem schreiben, welches dann ausschließlich auf der CPU läuft. Das
ganze wird als Software Renderer bezeichnet. Obwohl die heutige Grafik-Hardware es unnötig
macht, einen Software Renderer auf solchen Systemen bereitzustellen, ist es in vielen Fällen
immer noch sehr wichtig - zum Beispiel für den Einsatz von Grafik auf eingebetteten Systemen
wie beispielsweise Handys und Handhelds.1 Eine Grafik Engine hat demnach vor allem eine
wichtige Hauptaufgabe: die Zeichnung und Darstellung von Objekten. Wie unterscheidet
sich eine reine Grafik Engine nun von einer Game Engine? Generell ausgedrückt liegt der
Unterschied darin, dass außer dem Renderer noch weitere Komponenten enthalten sind. Eberly
(2005) hat hierzu ein Referenzwerk geliefert, das über die Jahre zu der bekannten Game
1
Vgl. Eberly (2005), S. 149 f.
5
2 Game Engines
Engine Gamebryo2 geführt hat. In diesem Werk beschreibt der Autor anhand der eigens
entwickelten Game Engine die Architektur durch folgende Komponenten:
• Die Kernsysteme, bestehend aus dem Low-Level-System, dem mathematischen System
und dem Objektsystem
• Der Szenengraph und der Renderer
• Die Kollisionserkennung und Physik
Nach Gregory (2009) lassen sich noch weitere Komponenten ergänzen:
• Frontend
• Ressourcen Manager
• Animationssystem
• Audiosystem
• Netzwerkfunktionalität
• Scripting
• Künstliche Intelligenz
2.1.2 Die Komponenten einer Game Engine
Zuvor wurden einige wichtige Komponenten einer Game Engine aufgezählt. In diesem Abschnitt
soll nun genauer auf die Komponenten und deren Aufgaben eingegangen werden. Es gibt
noch eine Menge weiterer Bestandteile, deren vollständige Aufzählung und Beschreibung
in dieser Arbeit allerdings den Rahmen sprengen würde. Daher werden ausschließlich die
signifikantesten aufgeführt.
Low-Level-System
Das Low-Level-System beinhaltet die grundlegenden Datenstrukturen, Speicherzuweisungbzw. bereinigung und Funktionen wie Dateiverwaltung. Manche zur Verfügung gestellte
2
http://www.emergent.net/1/Gamebryo/
6
2 Game Engines
Datentypen sind nicht unbedingt optimal für eine Engine zu verwenden. Daher verwendet
etwa Eberly (2005) in seiner eigenen Engine selbst implementierte Datenstrukturen für Arrays,
Hash Tabellen, Hash Sets, Listen, Sets, Stacks und Strings. Durch die selbst verwendeten
Datenstrukturen lässt sich die Geschwindigkeit einer Anwendung merklich erhöhen. Mit Hilfe
der Dateiverwaltung werden Dateien geöffnet und gelesen und über die Speicherzuweisungbzw. bereinigung wird es ermöglicht, spezielle Datenstrukturen wie beispielsweise ein zweidimensionales Array zu löschen.3
Mathematisches System
Jede Engine, die sich mit Computer Grafik auseinandersetzt, benötigt zwangsweise ein
Teilsystem für Mathematik wie Vectoralgebra und Matrixalgebra. Dieses Teilsystem stellt
dann Funktionen für die Berechnung von trigonometrischen Funktionen wie Sinus, Cosinus
und Tangens sowie Vektoren, Matrizen und Quaternionen bereit. Auch die Farben werden
über dieses Teilsystem geregelt.4
Objektsystem
Eine Grafik Engine ist groß und komplex und wird daher hinsichtlich der Bibliotheken
entsprechend entworfen, meist unter Verwendung des objektorientierten Paradigmas. Das
Objektsystem stellt automatische Dienste für die Entwickler bereit, welche mit der Verwaltung der Objekte zusammenhängt, die sich aus der objektorientierten Programmierung der
Anwendung ergibt. Beispielhaft kann hier das Abrufen der Typinformation eines Objektes
oder einer Variable zur Laufzeit genannt werden.5
Renderer
In Abschnitt 2.1.1 auf Seite 5 wurde bereits kurz auf den Renderer eingegangen. Er ist
für die Zeichnung der Objekte zuständig, wie beispielsweise Punkte, Linien und dreieckige
Polygonnetze (engl. Mesh). Dabei kümmert er sich um geometrische Transformationen und
Typen sowie um Texturen, Materialien und Beleuchtung. Dieser Vorgang des Zeichnens
wird manchmal auch als „fixed-function pipeline“ bezeichnet. Früher war es nur möglich,
vorgegebene Funktionen der Grafikschnittstelle aufzurufen. Neuere Grafik Hardware erlaubt
es allerdings, die Hardware selbst zu programmieren. Diese Programme werden auch Shader
3
Vgl. Eberly (2005), S. 33 ff.
Vgl. Eberly (2005), S. 53
5
Vgl. Eberly (2005), S. 105
4
7
2 Game Engines
genannt. Es gibt zwei Arten von Shadern, Vertex Shader und Pixel Shader, auf die im späteren
Verlauf der Arbeit noch eingegangen wird.6
Szenengraph
Die Welt eines Spiels wird als Szene bezeichnet. Die Objekte in der Welt sind ein Teil
dieser Szene. Wenn man nun die gegenseitigen Beziehungen zwischen den Objekten und
deren verschiedenen Attributen mit einbezieht, könnte man das Resultat als Szenengraph
bezeichnen. Über diesen Szenengraph kann man dann die Objekte begrenzen, die vom Renderer dargestellt werden. Beispielsweise wenn sie überhaupt nicht oder nur teilweise sichtbar
sind. Dadurch muss der Renderer weniger verarbeiten. Dies wird als Szenengraphmanagement bezeichnet. Sichtbarkeitsentscheid bzw. Verdeckungsberechnung sind ein Aspekt des
Szenengraphmanagements. Es könnte als Frontend des Renderers bezeichnet werden.7
Kollisionserkennung und Physik
Kollisionserkennung ist ein komplexes Themengebiet und unerlässlich für die Interaktion mit
der virtuellen Spielwelt. Häufig verwenden Physiksysteme ein Kollisionserkennungssystem, um
physikalische Grenzen zu bestimmen und darüber hinaus ein Kollisionsrückmeldungssystem,
welches die Bewegung der kollidierenden Objekte verändert.8 Kollisionserkennung stellt sicher,
dass Objekte sich nicht gegenseitig durchlaufen können. Was die meisten Game Engines
heutzutage als „Physik“ bezeichnen, ist genauer gesagt eine Simulation der Dynamik starrer
Körper (engl. rigid body dynamics). Ein starrer Körper ist ein idealisiertes, unendlich hartes,
nicht deformierbares und festes Objekt. Die Dynamik bezieht sich dabei auf den Prozess
der Bestimmung, wie diese starren Körper sich über die Zeit und unter dem Einfluss von
Kräften bewegen und interagieren.9 Kollision und Physik sind für gewöhnlich eng miteinander
verzahnt. Heutzutage entwickeln nur noch wenige Firmen ihr eigenes Kollisionserkennungsbzw. Physiksystem, stattdessen werden SDKs von externen Entwicklern verwendet. Hier gibt
es beispielsweise die Havok Physik Engine10 oder PhysX11 von Nvidia. Darüber hinaus gibt
es viele quelloffene Systeme wie beispielsweise die Open Dynamics Engine (ODE).12
6
Vgl. Eberly (2005), S. 149 f.
Vgl. Eberly (2005), S. 150
8
Vgl. Eberly (2005), S. 487 f.
9
Vgl. Gregory (2009), S. 595
10
http://www.havok.com/
11
http://www.nvidia.de/object/nvidia_physx_de.html
12
Vgl. Gregory (2009), S. 41 f.
7
8
2 Game Engines
Frontend
Im Frontend eines Spiels trifft man häufig auf das sogenannte Heads-Up Display (HUD), wie
beispielsweise Energie- oder Munitionsanzeige. Zum Frontend gehören auch die Spielemenüs,
eine Konsole oder bestimmte Entwicklungswerkzeuge, die unter Umständen mit dem finalen
Produkt mitgeliefert werden. Außerdem zählt zum Frontend auch die grafische Benutzeroberfläche (GUI), über die der Spieler Aufgaben wie beispielsweise die Manipulation eines Inventars
vornehmen kann. Weiterhin gehören zu dieser Komponente Videos und Zwischensequenzen,
die während des Spiels gezeigt werden.13
Ressourcen Manager
Der Ressourcen Manager stellt meist eine Schnittstelle zur Verfügung, durch die Bestandteile
des Spiels, wie zum Beispiel Bitmaps, Modelle, Texturen oder Audiodateien zugänglich
gemacht werden. Einige Engines greifen auf eine Sofortlösung zurück und überlassen es dem
Spieleprogrammierer, die Rohdateien direkt auf der Festplatte oder innerhalb komprimierter
Archive abzurufen, wie etwa bei Quake 3.14 Als gutes Beispiel sei an dieser Stelle der
Ressourcenmanager von OGRE genannt, der in Kapitel 4 auf Seite 40 näher beschrieben wird.
Animationssystem
Animationen sind ein wichtiger Bestandteil in jedem Spiel. Dabei gibt es fünf verschiedene
Grundtypen von Animationen, die in Spielen verwendet werden:
• Sprite / Texture Animation
• Rigid Body Hierarchy Animation
• Skeletal Animation
• Vertex Animation
• Morph Targets
Bei Skeletal Animation wird ein detailliertes dreidimensionales Charakter Polygonnetz von
einem Animateur mit Hilfe eines relativ simplen Knochensystems positioniert. Wenn sich die
13
14
9
2 Game Engines
Knochen bewegen, bewegen sich die Vertices des dreidimensionalen Objektes mit. Skeletal
Animation ist heutzutage die am weitesten verbreitete Methode der Animation.15
Audiosystem
Das Audiosystem kümmert sich um entsprechende Effekte wie etwa 3D Sound und um die
Wiedergabe und Verwaltung von Audiodateien.
Netzwerkfunktionalität
Spiele haben heutzutage häufig einen Mehrspielermodus (engl. Multiplayer ), in dem mehrere
Spieler gegeneinander antreten können. Daher enthalten Game Engines häufig Netzwerkfunktionen. Integriert man einen Mehrspielermodus in ein Spiel, so muss das gesamte Konzept
bestimmter Komponenten dementsprechend angepasst werden. Die Quake Engine ist beispielsweise bekannt für ihren „client-on-top-of-server“ Modus, in dem jede ausführbare Datei (engl.
executable) auf einem einzelnen PC im Einzelspielermodus als Client und Server gleichzeitig
fungiert.16
Scripting
Viele Game Engines verwenden sogenannte Skriptsprachen, um die Entwicklung von spielspezifischen Regeln und Inhalten einfacher und schneller abwickeln zu können. Ohne Skriptsprachen
müsste das Spiel neu kompiliert und gelinkt werden, falls eine Änderung an der Logik oder
den Datenstrukturen vorgenommen wird. Mit Hilfe einer Skriptsprache können Änderungen
an der Spielelogik und den Daten durch Modifikation und Neuladen des Skriptcodes bewirkt
werden.17
Künstliche Intelligenz (KI)
Ursprünglich für gewöhnlich nicht als Teil einer Game Engine angesehen, wird zunehmend
erkannt, dass die selben Muster für künstliche Intelligenz in so ziemlich jedem KI System
auftauchen. Eine Firma namens Kynogon hat bereits eine kommerzielle KI Engine namens
Kynapse entwickelt, die als Grundlage für KI dienen kann. Auf dieser Grundlage kann dann
weitere spielespezifische KI entwickelt werden.18
15
Vgl.
Vgl.
17
Vgl.
18
Vgl.
16
Gregory
Gregory
Gregory
Gregory
(2009),
(2009),
(2009),
(2009),
S.
S.
S.
S.
42
44 f.
47
47
10
2 Game Engines
Nachdem in diesem Abschnitt ein Überblick über die wichtigsten Komponenten einer Game
Engine gegeben wurden, folgt im kommenden Abschnitt eine Beschreibung der signifikantesten
Game Engines.
2.2 Populäre Game Engines
Im Laufe der Jahre haben sich diverse Game Engines besonders hervorgehoben und auch
weiterentwickelt. Dazu zählen im kommerziellen Bereich unter anderem die Unreal Engine,
die CryEngine, die id Tech Engine, die Gamebryo Engine und die Source Engine. Im Open
Source bzw. kostenlosen Bereich existieren namhafte Engines wie beispielsweise Nebula Device,
Crystal Space, OGRE, Panda3D, jMonkey, XNA und die Irrlicht Engine. In diesem Abschnitt
sollen die signifikantesten Engines vorgestellt werden, selbstverständlich gibt es noch eine
Vielzahl weiterer Engines.
2.2.1 Kommerziell
Unreal Engine
Die Unreal Engine wurde von Epic Games im Jahre 1998 mit dem Spiel Unreal veröffentlicht.
Die aktuelle Version der Unreal Engine, Version 3, ist ein komplettes Entwicklungsframework
für DirectX10 fähige PCs, Xbox 360 und Playstation 3. Sie beinhaltet ein Renderingsystem,
ein Animationssystem, ein Physiksystem, ein Audiosystem, Netzwerkfunktionalität, ein eigenes
Scriptingsystem und mehrere Werkzeuge, beispielsweise für die Erstellung von Spielumgebungen, Materialien, Animationen und Benutzeroberflächen. Die Unreal Engine findet in einer
Vielzahl von Spielen wie beispielsweise der bekannten Unreal Tournament Serie Verwendung
und spielt auch auf Next-Generation-Konsolen eine wichtige Rolle.19 Die Unreal Engine ist
eine der bekanntesten Engines der Spielegeschichte.
Im Verlauf dieser Arbeit wurde das Unreal Development Kit veröffentlicht, mit dem kostenlos
für nichtkommerzielle Zwecke entwickelt werden kann.20
19
20
Vgl. Unreal Technology (2009a)
Vgl. Unreal Development Kit (2010)
11
2 Game Engines
id Tech Engine
Die id Tech Engine ist ebenfalls eine der bekanntesten Engines der Spielegeschichte und wurde
in verschiedenen Versionen in unterschiedlichsten Spielen eingesetzt. Die aktuelle Version
4 kam bisher in Titeln wie Doom 3, Quake 4, Prey und dem erst kürzlich veröffentlichten
neuesten Teil der Wolfenstein-Serie zum Zuge. Höhepunkte der id Tech 4 Engine sind
dynamisches Licht in Echtzeit und „MegaTexture“, wodurch „beispielloses Terrain-Detail“21
ermöglicht wird. Sie unterstützt verschiedene Plattformen wie beispielsweise PC, Mac, Xbox
360 und Playstation 3.22 Die id Tech Engine 5 befindet sich derzeit in Entwicklung und wird
als Zukunftstechnologie angepriesen.
Die Vorgänger id Tech 2 und id Tech 3 sind mittlerweile vom Entwickler unter der GPL Lizenz
als Open Source freigegeben. Sie wurden in bekannten Spielen wie Quake 2 und Quake 3
genutzt.23
CryEngine
Die CryEngine ist eine von Crytek24 entwickelte Engine aus Deutschland. Ursprünglich
von den Gebrüdern Yerli ins Leben gerufen, fand sie als Debüt im Spiel FarCry Verwendung. Die CryEngine Version 2 kam beispielsweise im Spiel Crysis zur Anwendung und wird
von der Mediadesign Hochschule für Design und Informatik25 zum Zwecke der Lehre und
Forschung eingesetzt. Version 2 der CryEngine umfasst verschiedene Effekte wie beispielsweise
Lichtberechnung in Echtzeit, volumetrische Wolken und Motion Blur. Zusätzlich gibt es
ein Audiosystem für Sound und Musik, einen Leveleditor, Netzwerkfunktionalität und ein
fortgeschrittenes System für künstliche Intelligenz. Darüber hinaus basiert sie auf einem
modularen Design, geschrieben in der Sprache C++.26 Derzeit befindet sich die Version 3
der CryEngine in Entwicklung.
Im Verlaufe der Arbeit erschien die CryEngine Version 3 in einer für Bildungszwecke kostenlosen
Version.27
21
ID Software (2009a)
Vgl. ID Software (2009a)
23
Vgl. ID Software (2009b)
24
http://www.crytek.com/
25
http://www.mediadesign.de/
26
Vgl. CryEngine 2 (2009)
27
Vgl. Crytek (2009)
22
12
2 Game Engines
Gamebryo Engine
Gamebryo ist eine flexible und plattformunabhängige Game Engine, die über eine Rendering
Engine mit Unterstützung für dynamisches Licht, Schatten, Materialien, ein Physiksystem, ein
Animationssystem, ein Terrainsystem zur Darstellung von Landschaften, einen Leveleditor und
Netzwerkfunktionalität verfügt. Darüber hinaus kann sie auch für Konsolen wie beispielsweise
die Nintendo Wii genutzt werden.28
Source Engine
Die Source Engine ist eine Game Engine, mit der bekannte Spiele wie Half-Life 2, Counter
Strike: Source und Team Fortress 2 entwickelt wurden. Sie ist eine hochqualitative Engine,
die mit der Unreal Engine 3 hinsichtlich der grafischen Möglichkeiten und der Werkzeuge
konkurriert.29 Source basiert auf einer modularen, komponentenbasierten Architektur, die
nahtlose Integration neuer Funktionalitäten und Technologien ermöglicht. Zur Engine gehören
ein Rendering System mit Shadern, Materialien, dynamischem Licht und Schatten, ein
Animationssystem inklusive Werkzeuge zur Erstellung von Animationen, ein Leveleditor, ein
Physiksystem, ein Audiosystem und Netzwerkfunktionalität. Die Source Engine kann auch für
Spielekonsolen wie beispielsweise Playstation 3 eingesetzt werden.30
2.2.2 Open Source / Kostenlos
Nebula Device
Nebula Device ist eine quelloffene Game Engine, die vom deutschen Entwicklerstudio Radon
Labs31 entwickelt wird und beispielsweise im Spiel Drakensang Verwendung findet. Sie enthält
eine DirectX9 Rendering Engine, die neuere Effekte wie Bump Mapping, Echtzeitschatten und
High Dynamic Range Rendering beherrscht. Sie verfügt über Systeme für Audio, Animation,
Eingabe und Scripting.32
28
Vgl. Gamebryo (2009)
30
Vgl. Source Engine (2009)
31
http://www.radonlabs.de/
32
Vgl. Nebula Device (2009)
29
13
2 Game Engines
Crystal Space
Crystal Space ist ein plattformunabhängiges Software Development Kit für 3D Grafik in
Echtzeit, mit speziellem Fokus auf Spieleentwicklung. Sie ist in C++ geschrieben und
verfügt über Fähigkeiten wie unter anderem Level of Detail, Kollisionserkennung und über
ein Soundsystem.33
OGRE
OGRE ist eine ausgereifte, stabile, zuverlässlige, flexible, plattformunabhängige und umfassende
Bibliothek für die Entwicklung von 3D Grafik Anwendungen in Echtzeit.34 OGRE wird auch in
kommerziellen Projekten verwendet. Nennenswert seien hier die Spiele des Entwicklerstudios
Deck1335 , wie beispielsweise Ankh, Venetica oder Jack Keane. OGRE wird in Kapitel 4 auf
Seite 40 ausführlich behandelt.
Panda3D
Panda3D ist eine 3D Game Engine, die derzeit von Disney und der Carnegie Mellon Universität
entwickelt wird. Sie ist eine Programmbibliothek für 3D Rendering und Spieleentwicklung.
Die Anwendungen von Panda3D werden für gewöhnlich mit C++ oder Python über ein sogenanntes Scripting Interface geschrieben, welches die Panda3D Bibliothek steuert. Panda3D
ist quelloffen und frei einsetzbar für jeglichen Zweck, auch für kommerzielle Entwicklung.36
Derzeit findet die Engine in zwei großen Online Rollenspielen Verwendung: Disneys Toowntown Online37 und Disneys Pirates of the Carribean Online38 . Beide Spiele können kostenlos
erworben und gespielt werden.
jMonkey Engine
jMonkey Engine (Abkürzung jME) ist eine leistungsstarke szenengraphbasierte Grafikschnittstelle.
Ein Großteil der Inspiration hinsichtlich des Designs stammt hierbei von Eberly (2005). jME
wurde entwickelt, um den Mangel an einer umfassenden in Java geschriebenen Grafik Engine
auszugleichen. jME ist vollständig quelloffen unter der Verwendung der BSD Lizenz. jME kann
33
Vgl. Crystal Space (2009)
Vgl. Junker (2006), S. 1 und S. 5
35
http://deck13.com/
36
Vgl. Panda3D (2009)
37
http://www.disney.co.uk/toontown/
38
http://piratesonline.go.com/v3/#/community/community-home.html
34
14
2 Game Engines
in jedweder Art verwendet werden, privat sowie kommerziell. Die Engine besitzt eine szenengraphbasierte Architektur. Darüber hinaus beherrscht sie verschiedene Typen von Geometrie,
wie beispielsweise Bezier Patches, Linien, Punkte, Modelle wie Milkshape, MD2, ASE und
weiteren, Terrain, Level of Detail und mehr. Außerdem beherrscht jME High-Level-Effekte
wie Render to Texture, Environment Mapping und Partikel Systeme.39
Irrlicht Engine
Die Irrlicht Engine ist eine quelloffene 3D Engine. Sie ist in C++ geschrieben und auch für
.NET Sprachen verfügbar. Sie ist komplett plattformunabhängig, beherrscht Direct3D und
OpenGL, besitzt einen eigenen Software Renderer und verfügt über alle aktuellen Eigenschaften,
die in kommerziellen 3D Engines vorzufinden sind. Es gibt eine riesige aktive Gemeinschaft
und viele Projekte, die sich in Entwicklung befinden und die Engine verwenden. Man kann im
gesamten Web Erweiterungen und Verbesserungen für Irrlicht finden, wie alternative Terrain
Renderer, Portal Renderer und Editoren.40
XNA
XNA ist eine noch recht junge Entwicklung von Microsoft. Die Abkürzung XNA ist ein
Wortspiel und steht für „XNA is not an Acronym“. Mit Microsoft XNA ist es erstmals möglich,
als nicht professioneller Spieleentwickler Ein- und Mehrspielerspiele zu erstellen, die auf dem
PC, der Xbox 360 Konsole und dem Zune laufen.41 XNA ist eine einfach zu verwendende
und leicht zugängliche Plattform für Spieleentwicklung. Ziel ist es, Spieler zu fördern, damit
sie ihre eigenen Spiele entwickeln und diese mit der Online Community teilen, so wie es etwa
YouTube42 mit Videos macht. XNA basiert auf Microsofts Programmiersprache C# und
der Common Language Runtime (CLR). Die primäre Entwicklungsplattform ist dabei Visual
Studio oder das freie Gegenstück Visual Studio Express.43
39
Vgl. jMonkeyEngine (2009)
Vgl. Irrlicht (2009)
41
Vgl. Lobao u. a. (2009), S. xxi
42
http://www.youtube.com
43
Vgl. Gregory (2009), S. 26 f.
40
15
2 Game Engines
2.3 Anwendungsgebiete
Game Engines werden heutzutage nicht nur zur Realisierung von Computer- und Videospielen
verwendet. Es existieren viele weitere Anwendungsgebiete. Beispielsweise werden sie bei der
Visualisierung von Gebäuden und Landschaften, in der Medizin oder in Schulen eingesetzt. In
diesem Abschnitt werden wichtige Bereiche für die Anwendung von Game Engines vorgestellt
und erläutert.
2.3.1 Spiele
Der ursprüngliche Zweck von Game Engines lag selbstverständlich in der Entwicklung von
Spielen. Game Engines erleichtern die Entwicklung von Spielen, da sie eine Wiederverwendung bedeutsamer Teile von Softwarekomponenten ermöglichen. Hierbei wird eine Trennung
der Softwarekomponenten vorgenommen, wie beispielsweise der Kollisionserkennung, der
Rendering Engine und dem Audiosystem.44 Im vorangegangenen Abschnitt wurden bereits
signifikante Beispiele für Game Engines und deren Komponenten genannt.
2.3.2 Virtuelle Realität und Simulationen
In der Arbeit von Mól u. a. (2008) wird die Entwicklung einer virtuellen Gebäude-EvakuierungsSimulation auf Basis einer Game Engine beschrieben. Simulationen benötigen eine ausreichende
Möglichkeit der dreidimensionalen grafischen Darstellung. Für realistische Ergebnisse müssen
dabei auch die Auswirkungen physikalischer Gesetze, wie beispielsweise Gravitation und Kollisionskräfte berücksichtigt werden. Eine Eigenentwicklung für diesen Zweck wäre aufwändig.
Einige Game Engines erfüllen dabei die Anforderungen der Simulationen virtueller Realität.
Im Rahmen der Arbeit wurde ein dreidimensionales Modell des IEN (Instituto de Engenharia Nuclear, Nuclear Engineering Institute) erstellt, um vorbeugende Evakuierungstests
durchzuführen und somit die Evakuierungsplanung zu unterstützen. Eine virtuelle Simulation eignet sich in einer gefährlichen Umgebung wie einem Kernkraftwerk besser als eine
Evakuierungsübung in echter Umgebung - beispielsweise um Feuer, Rauch oder radioaktive
bzw. chemische Kontamination zu simulieren. Ziel der Tests ist es, Einsichten und Vorschläge
44
16
2 Game Engines
über Gebäude- und Bürogrundrisse, wie beispielsweise die Lage von Treppen und deren Dimensionen oder alternative Fluchtwege zu erhalten. Die Vorteile liegen hier in der Flexibilität von
Game Engines, da sie meist unabhängig von den Szenarios oder Anwendungen sind, für die sie
ursprünglich entwickelt wurden. Darüber hinaus ist der Quellcode für manche Game Engines
teilweise offen verfügbar. Daher können sie für komplett neue Szenarien und Anwendungen
verwendet werden. In dieser Arbeit wurde mit der Unreal Engine 2 Runtime Demo Version
gearbeitet, einer eingeschränkten Version der Unreal Engine 2.
Abb. 2.1: Anwendungsgebiet virtuelle Realität / Simulation: Evakuierung eines Gebäudes
(Vgl. Mól u. a. (2008))
Eine weitere Arbeit von Jacobson und Lewis (2005) handelt von CaveUT, einem quelloffenen
und kostenlosen Projekt basierend auf dem Spiel Unreal Tournament, welches projektionsbasierte virtuelle Realität (VR) erschwinglich und zugänglich macht. Dabei modifiziert CaveUT
Unreal Tournament in dem Maße, dass es die Bilder auf mehreren Displays darstellt. Der
Betrachter wird dabei von den Displays umgeben. Dies ist besonders für VR Anwendungen
geeignet. Ein Mehrfachbildschirmdisplay basierend auf CaveUT benötigt einen Server Computer, der sich zu mehreren Client Computern verbindet. Jeder Client betreibt dabei einen
Bildschirm auf dem Display. Dieses Display ist für gewöhnlich eine Projektionswand, die von
einem digitalen Projektor beleuchtet wird. Dabei wird ein gewöhnliches Mehrspielerspiel in
Unreal Tournament mit einem normalen Spieler auf dem Server und jeweils einem Zuschauerspieler auf jedem der Clients gestartet. Jeder Zuschauer dupliziert dabei den Sichtbereich
17
2 Game Engines
des Spielers auf dem Server. Auf jedem Client rotiert CaveUT die Sicht in die virtuelle Welt,
so dass jeder Bildschirm den entsprechenden Teil der zusammengesetzten Sicht zeigt. Um
dies perspektivisch korrekt darzustellen, benutzt CaveUT VRGL45 . Dies ist eine OpenGL
Bibliothek, die speziell für VR Anwendungen angepasst wurde.
Abb. 2.2: Anwendungsgebiet virtuelle Realität / Simulation: Mehrfachbildschirmdisplay auf
Basis von Unreal Tournament (Vgl. Jacobson und Lewis (2005))
2.3.3 Informationsvisualisierung
Bei der Informationsvisualisierung (engl. information visualization) geht es um die Verwendung interaktiver visueller Repräsentationen, um die Wahrnehmung zu verstärken.46 Für diese
neuartige Disziplin der Darstellung wird vermehrt auch auf Game Engines zurückgegriffen.
Kot u. a. (2005) entwickelten mit Hilfe der Quake 3 Engine ein Werkzeug, mit dem Quellcodes besser verständlich gemacht werden können. Die meisten Werkzeuge verwenden für
diesen Zweck textuelle oder zweidimensionale schematische Diagramme, andere verwenden
45
46
http://planetjeff.net/html/pro_vrgl.html
Vgl. Ware (2004)
18
2 Game Engines
dreidimensionale Darstellungen. Ziel der Arbeit war es, in einer dreidimensionalen virtuellen
Umgebung Metaphern zu verwenden, um Beziehungen im Code darzustellen und Interaktionen
mit Informationsgegenständen zu unterstützen. Es sollten darüber hinaus mehrere Nutzer
den Code gemeinsam verstehen können, beispielsweise durch Besichtigung des Codes in der
Spielwelt, durch Kommentierung des Codes und über kommunikative Mittel. Um dies nicht
alles selbst entwickeln zu müssen, wurde hierbei auf eine Game Engine zurückgegriffen. Kernanforderung war es, Quellcodedateien als dreidimensionale Objekte in einer dreidimensionalen
Welt und Beziehungen und Querverweise zwischen deren Abhängigkeiten darzustellen.47
Abb. 2.3: Anwendungsgebiet Informationsvisualisierung: Quellcode verständlich machen. Links
sieht man die Darstellung einer Header-Datei und einer Implementierungs-Datei
aus der Sprache C als dreidimensionale Objekte. Rechts sieht man die textuelle
Darstellung von Code. Beides unter der Verwendung der Quake 3 Engine (Vgl. Kot
u. a. (2005))
2.3.4 Visualisierung von Gebäuden und Landschaften
Fritsch und Kada (2004) beschreiben in ihrer Arbeit die Darstellung von Gebäuden und
Landschaften mit Hilfe einer Game Engine. Hier lägen laut den Autoren die Vorteile vor
allem bei den Kosten und der ausgezeichneten Darstellungsperformanz sowie der ständigen
Weiterentwicklung der Game Engines.48 Manche Game Engines sind dabei speziell auf
47
48
Vgl. Kot u. a. (2005), S. 53 f.
Vgl. Fritsch und Kada (2004), S. 621
19
2 Game Engines
Innen- bzw. Außenräume spezialisiert. Die Autoren gehen hierbei auf die Quake 3 Engine für
Innenräume und die Unreal Engine 2 für Außenräume ein. In einer weiteren Arbeit von Herrlich
(2007) geht es um die Entwicklung eines Prototyps für ein Werkzeug für Landschaftsarchitektur
basierend auf der CryEngine von Crytek.
Abb. 2.4: Anwendungsgebiet Gebäudevisualisierung: Darstellung eines Innenraums (Vgl.
Fritsch und Kada (2004))
2.3.5 Medizin
Auch im medizinischen Bereich gibt es Ansätze für die Verwendung von Game Engines. Marks
u. a. (2007) untersuchen in ihrer Arbeit die Tauglichkeit von Game Engines für die Entwicklung
von Anwendungen für die medizinische Ausbildung und simuliertes chirurgisches Training.
Die zunehmende Komplexität und die zunehmenden Kosten von chirurgischem Training und
der konstanten Weiterentwicklung chirurgischer Vorgehensweisen sind verantwortlich für die
Auslagerung des chirurgischen Trainings in eine virtuelle Umgebung. Selbstverständlich gibt
es kommerzielle Simulatoren für die Bereiche der Medizin, bei denen allerdings die immensen
Kosten einen Nachteil darstellen.49 Game Engines bieten hier außer dem Kostenfaktor auch
technische Vorteile, wie beispielsweise die ständige Aktualisierung und Anpassung der Engines
an die Grafik Hardware sowie der grafischen Algorithmen. Durch Netzwerkfähigkeit ist es
möglich, ohne physische Grenzen weltweit kooperativ Aufgaben auszuführen. Dies wird durch
49
Vgl. Marks u. a. (2007), S. 273
20
2 Game Engines
die Verwendung von kommunikativen Mitteln wie Headsets oder textuellem Chat sicher
gestellt. Darüber hinaus können Game Engines unterschiedliche Sprachen verwalten. Die
Benutzeroberflächen, der Sound und die Eingabegeräte können ebenfalls angepasst werden.
Ein weiterer Vorteil ist der visuelle Realismus, hervorgerufen durch grafische Effekte wie unter
anderem Bump Mapping, Schatten und Tiefenschärfe. Dabei wurden die Engines anhand
verschiedener Aspekte getestet, wie beispielsweise der Möglichkeit zur Erstellung eigener
Inhalte oder die physikalische Interaktion mit den Modellen innerhalb des Spiels.50
Abb. 2.5: Anwendungsgebiet Medizin: Simuliertes chirurgisches Training mit einer Game
Engine (Vgl. Marks u. a. (2007))
2.3.6 Lehre
Für den Bereich der Lehre existieren bereits ebenfalls zahlreiche Einsatzmöglichkeiten. Ein
Beispiel zeigen Shabanah und Chen (2009): Hierbei geht es um die Lehre von Algorithmen mit
Hilfe eines Ansatzes namens „AVuSG“, Algorithm Visualization using Serious Games. Wie aus
dem Namen ersichtlich, geht es um die Visualisierung von Algorithmen mit Hilfe von Serious
Games. Dabei wird ein Algorithmus in vier Formen visualisiert: als Text, als Flussdiagramm,
als Demonstration eines Spiels und als Spiel selbst. Weiterhin integriert der AVuSG Ansatz
50
Vgl. Marks u. a. (2007), S. 275 ff.
21
2 Game Engines
Lerntheorien und Modelle zusätzlich zur Motivationstheorie, um drei Lernmodelle einzuführen,
die das Lernen von Algorithmen vereinfachen sollen. Derzeit wird ein ähnliches Thema in einer
Abschlussarbeit von Marinska (2010) an der Hochschule Reutlingen behandelt. Dabei geht es
um die Lehre von Softwaretechnik und theoretischen Grundlagen mit Hilfe von Serious Games.
Eine weitere Idee für die Lehre zeigen Burd u. a. (2007) oder etwa Shultz (2006), welcher die
Verwendung einer Game Engine für die Lehre von Informatik mit Hilfe einer auf pädagogische
Zwecke ausgelegten Game Engine beschreibt. Die Entwicklung von Computerspielen wirkt laut
dem Autor höchst motivierend auf viele Studenten, die gerade erst mit Informatik beginnen.
Die Studenten lernen dabei im Rahmen eines Seminars den Umgang mit Schleifen, Variablen,
der Erstellung von Objekten und Methodenaufrufen während sie die Klassen verwenden, die
von der Game Engine bereitgestellt werden.
Betrachtet man die vielseitigen Anwendungsgebiete von Game Engines, lässt sich das große
Potential der Game Engines erkennen. Um nun zu prüfen, ob sie sich für die Lehre im Bereich
der Computer Grafik eignen, wird im folgenden Verlauf der Arbeit eine Evaluierung geeigneter
Engines für den Einsatz in der Lehre vorgenommen.
22
Dieses Kapitel behandelt die Vorgehensweise und die Methoden, mit denen die entsprechenden
Game Engines ausgewählt und bewertet werden. Es wird dabei genauer auf die Methode der
Entscheidungsfindung, die Auswahl der Kriterien, die Kriterien an sich, deren Gewichtung und
die daraus resultierenden Ergebnisse eingegangen. Weiterhin werden die Ansätze für die Lehre
sowie die Demonstration der Engine und die Auswertung der Ergebnisse eines Fragebogens
zur Evaluierung der im Rahmen dieser Thesis entwickelten Anwendung behandelt.
3.1 Vorgehensweise
Im ersten Schritt wird hierbei zunächst mit der Recherche nach diversen Game Engines
begonnen. Dabei helfen vor allem die Internetseiten DevMaster.net1 sowie die deutsch- und
englischsprachige Version von Wikipedia2 , welche einen guten Überblick über die vielen
verfügbaren Engines bieten. Diese Engines werden anschließend tabellarisch festgehalten und
nach kommerziellen und quelloffenen bzw. kostenlosen Engines sortiert. Im weiteren Verlauf
muss ein Bewertungssystem für die Bewertung der Engines erarbeitet werden. Hierfür wird
ein Verfahren aus der Betriebswirtschaftslehre verwendet. Die Bewertung der Engines erfolgt
anhand einer einfachen Variante der Nutzwertanalyse. „Die Nutzwertanalyse ist ein formalisiertes Verfahren zur Entscheidungsfindung oder -vorbereitung, wenn es um eine Auswahl von
Handlungsalternativen unter Berücksichtigung eines mehrdimensionalen Zielsystems geht“.3
„Den Anfang einer Nutzwertanalyse bildet die Entwicklung eines Zielsystems - es sei denn,
es könnte auf ein bereits existierendes Zielsystem zurückgegriffen werden“.4 Da noch kein
Zielsystem existiert, muss zunächst solch ein Zielsystem entwickelt werden. Das übergeordnete
1
http://www.devmaster.net/engines/
http://de.wikipedia.org/
3
Adam (1996), S. 412
4
Brede (2005), S. 268
2
23
Ziel stellt hierbei das Finden einer geeigneten Game Engine dar. Für dieses Zielsystem müssen
am Anfang zunächst Teilziele erarbeitet werden. Diese vereinen später weitere Teilziele unter
sich, die im Folgenden als Kriterien bezeichnet werden.
Abb. 3.1: Nutzwertanalyse: Das Zielsystem
Dabei wurden im Bezug auf die Engines folgende Teilziele und deren Kriterien selbstständig
erarbeitet:
Teilziel Community
Nr.
Kriterium
Beschreibung
Gewichtung
1
Größe / Support /
Wird die Engine weiterhin gepflegt? Gibt es ein Forum, in
14
Qualität
dem man Unterstützung erhält? Gibt es Projekte, die die
Engine nutzen? Wer entwickelt / erweitert die Engine?
2
Vorhandene Beispiele
Gibt es genügend Beispiele, anhand derer die Engine
12
erlernt werden kann? Wie ist die Qualität der Beispiele?
Tab. 3.1: Kriterien für die Game Engines: Teilziel Community
Hierbei handelt es sich um das Teilziel der „Community“. Unter diesem Teilziel befinden sich
alle Kriterien, die mit der Gemeinschaft rund um eine Game Engine zusammenhängen.
24
Teilziel Technische Aspekte / Möglichkeiten
Nr.
Kriterium
Beschreibung
Gewichtung
3
Unterstützte Tools
Gibt es Unterstützung für gängige Modellierungswerkzeuge
9
wie 3dsmax, Maya, Milkshape, Blender? Werden Formate
für Animationen unterstützt?
4
Programmiersprache(n)
Welche Programmiersprache(n) werden verwendet? C++
7
spielt in der Spieleentwicklung eine große Rolle, der
Studiengang hat seinen Fokus aber nicht auf
Spieleentwicklung, sondern Programmierkonzepte.
5
Umfang, Funktionen
Handelt es sich um eine reine Render- Engine oder werden
und Features
typische Funktionen einer Game Engine angeboten wie
10
zum Beispiel Kollisionserkennung, Level Editoren,
Szenengraphen etc.? Bietet die Engine moderne Effekte
und Verfahren wie beispielsweise Bump Mapping, Physik,
Heightmaps etc.?
6
Aufbau und Struktur
Eine Engine mit objektorientiertem Aufbau erleichtert die
8
Programmierung und macht sie übersichtlicher. Ist die
Engine modular aufgebaut? Kann sie leicht erweitert
werden?
7
Unterstützte
Auf welchen Betriebssystemen ist die Entwicklung und
Plattformen und
Ausführung möglich? Welche grafischen Schnittstellen
Schnittstellen
werden unterstützt?
6
Tab. 3.2: Kriterien für die Game Engines: Teilziel Technische Aspekte / Möglichkeiten
Das Teilziel „Technische Aspekte / Möglichkeiten“ beinhaltet alle Kriterien, die in irgendeiner
Weise mit dem technischen Hintergrund einer Engine zusammenhängen.
25
Teilziel Erlernbarkeit
Nr.
Kriterium
Beschreibung
Gewichtung
8
Komplexität und
Wie ist die Lernkurve? Ist die Engine einfach aufgebaut
12
Lernkurve
und leicht zu verstehen? Wie leicht gelingt der Einstieg?
Können relative Anfänger mit der Engine umgehen? Dies
ist wichtig, da die Engine innerhalb kurzer Zeit erlernt
werden sollte
9
Verfügbare Literatur
Gibt es Artikel, Bücher etc., die beim Erlernen / Erläutern
10
der Engine hilfreich sind?
10
Dokumentation
Ist die Engine gut dokumentiert? Gibt es ein Wiki, eine
12
Anleitung und eine Referenz für die
Programmierschnittstelle? Wie ist die Qualität von diesen?
Tab. 3.3: Kriterien für die Game Engines: Teilziel Erlernbarkeit
Unter dem Teilziel der „Erlernbarkeit“ werden die Kriterien zusammengefasst, die mit der
Einarbeitung und der Schwierigkeit des Umgangs mit der Engine in Verbindung stehen.
Bei der Nutzwertanalyse ist es meist nicht möglich, die Unabhängigkeit der einzelnen Teilziele
zu bewahren.5 Da in diesem Fall beispielsweise die Lernkurve auch ein Stück weit mit den
vorhandenen Beispielen, dem Support der Community und den Programmiersprachen verbunden ist, lässt sich auch hier keine vollständige Unabhängigkeit erreichen. Die Nutzwertanalyse
kann somit „lediglich als vereinfachendes, heuristisches Vorgehen“6 bezeichnet werden.
Bei der Erschließung der Kriterien hilft eine intensive Recherche der Internetpräsenzen der
jeweiligen Engines, sowie Wikipedia und DevMaster.net, welche einen umfassenden Überblick
über die wichtigen Aspekte einer Game Engine bieten. DevMaster.net verfügt zusätzlich
über ein System für Rezensionen, bei dem die Benutzer ihre Erfahrungen mit den Engines
schildern können. Daraus lassen sich Kriterien für alle drei Teilziele erschließen. Die Kriterien
und deren jeweiligen Beschreibungen können den Tabellen 3.1, 3.2 und 3.3 entnommen
werden. Anschließend erfolgt die Gewichtung der jeweiligen Kriterien nach ihrer Relevanz dargestellt in Abbildung 3.1 auf Seite 24 als kleine Zahlen unter den Kriterien. Auch hier
ist eine gewisse Subjektivität nicht zu vermeiden. Manche Personen würden möglicherweise
die Programmiersprachen höher gewichten, weil sie ihrer Meinung nach eine größere Rolle
spielen. Oder sie würden den Aufbau und die Struktur einer Engine weit geringer gewichten,
5
6
Vgl. Adam (1996), S. 414 f.
Adam (1996), S. 415
26
weil dieses Kriterium aus ihrer Sicht weniger wichtig erscheint. Näheres zu der Gewichtung
der Kriterien folgt im Abschnitt 3.2 auf Seite 29. Zusätzlich zu den herkömmlichen Kriterien
existieren zwei weitere sogenannte „K. O. Kriterien“: Zum einen müssen die Engines kostenlos
und unter einer freien Lizenz verfügbar sein und zum anderen müssen sie die Fähigkeit besitzen, dreidimensionale Bilder darzustellen. Eine Engine, die lediglich zweidimensionale Bilder
darstellen kann, wäre zur Vermittlung der Theorie der Computer Grafik nicht ausreichend
geeignet. Eine genauere Beschreibung bezüglich der Entscheidung, nur kostenlose und unter
einer freien Lizenz stehende Engines zu verwenden, findet sich am Ende dieses Abschnitts.
Nach der Gewichtung ist das Zielsystem vollständig und es kann mit der Bewertung der jeweiligen Game Engines begonnen werden. Dies geschieht mit Hilfe der sogenannten Zielerreichungsbzw. erfüllungsgrade. Diese beschreiben die Qualität der Erfüllung für ein entsprechendes
Kriterium auf einer Skala. Dabei können die Kriterien mit „1“ (schlecht), „2“ (befriedigend),
„3“ (gut) und „4“ (sehr gut) bewertet werden. Dazwischen gibt es ebenfalls Bewertungen wie
beispielsweise „3.5“ (sehr gut bis gut).
Abb. 3.2: Nutzwertanalyse: Zielerreichungsgrade
Eine feinere Abstufung ist nicht möglich bzw. nötig, da die Bewertung anhand einer relativ
oberflächlichen Recherche vorgenommen wird. Dadurch ist es kaum möglich, feine Detailunterschiede der Engines festzustellen. Dies geschieht erst mit dem praktischen Direktvergleich
der Engines, siehe Abschnitt 3.4, Seite 34. Ein Zielerreichungsgrad unter „1“ ist nicht möglich,
dies ist die schlechteste Bewertung. Ob ein Kriterium wie beispielsweise die Dokumentation
gar nicht oder nur rudimentär vorhanden ist, spielt letztendlich keine Rolle. Tatsächlich verfügen die meisten Engines auch über die grundlegenden Anforderungen der Kriterien. Kaum
eine Engine könnte es sich erlauben, ohne Dokumentation veröffentlicht zu werden. Somit
können nun die tatsächlichen Erreichungsgrade bestimmt werden. Hierfür werden die Engines
anhand der Kriterien geprüft. Diese Prüfung geschieht durch eine Recherche der jeweiligen
Internetpräsenzen, Wikis, Dokumentationen, Foreneinträge, Rezensionen und Beispiele der
27
Engines. Die Zielerreichungsgrade werden anschließend mit den entsprechenden Gewichtungen für die jeweiligen Kriterien multipliziert. Dadurch werden die letztendlichen Nutzwerte
berechnet. Um alternative Ergebnisse (Nutzwerte) zu erhalten, wäre es natürlich möglich, die
Gewichtung anzupassen bzw. alternative Erreichungsgrade festzulegen. Die Berechnung der
Nutzwerte wird dabei mit Hilfe einer Tabellenkalkulation vorgenommen, die automatisch die
Gewichtung mit den Erreichungsgraden multipliziert. Anschließend werden die Engines und
deren Bewertung nochmals hinsichtlich der Kriterien untersucht und manche Erreichungsgrade
angepasst. Dadurch entstehen nun die endgültigen Ergebnisse. Hierbei werden die drei Engines
mit der höchsten Bewertung für das weitere Auswahlverfahren gewählt, der Rest der Engines
wird aussortiert. Dieses erste Auswahlverfahren dient der groben Filterung, um ungeeignete
Engines auszuschließen. Eine genauere Beschreibung der Ergebnisse wird in Abschnitt 3.3 auf
Seite 31 gegeben, die des weiteren Vorgehens wird in Abschnitt 3.4 auf Seite 34 dargestellt.
Man beschränkt sich in dieser Arbeit auf quelloffene bzw. kostenlose Engines. Die Gründe
dafür sind vielfältig. Zum einen gibt es insgesamt eine große Anzahl an Engines. Würde
man bei der Auswahl zusätzlich kommerzielle Engines testen, so würde dies den Rahmen
sprengen. Darüber hinaus ist es bei kommerziellen Engines oft schwieriger, einen Einblick
zu erhalten, da häufig keine offenen Beispiele im Internet verfügbar sind. Quelloffene und
kostenlose Engines sind außerdem wesentlich schneller und einfacher verfügbar, da nicht erst
eine Lizenz erworben werden muss. Dies ist auch aufgrund mangelnden Geldes ein großer
Vorteil. Häufig bieten die Hersteller kommerzieller Engines nicht einmal eine Testversion an.
Und Versionen für Bildungszwecke sind entweder recht teuer oder die Versionen sind so sehr
im Funktionsumfang eingeschränkt, dass nicht einmal Zugriff auf den Quellcode möglich
ist. Ein Beispiel: Für die nicht aktuelle Version der Unreal Engine (Version 2) muss man
für kommerzielle Zwecke rund 350.000 US Dollar zahlen.7 Es existiert hierfür eine Version,
die Unreal Engine 2 Runtime, die allerdings sehr stark eingeschränkt ist und allenfalls für
technische Demos taugen könnte.8 Bei Open-Source-Engines hat man meist eine öffentlich
zugängliche API Dokumentation und viele Beispiele. Darüber hinaus erhält man kostenlosen
und oft auch sehr guten und schnellen Support in den Foren. Eine freie Lizenz spricht nicht
nur für die Flexibilität der Engine, weil der Quellcode offenliegt und sie somit von jeder Person
erweitert werden kann. Es bilden sich dadurch auch größere Gemeinschaften, da es mehr
Leuten ermöglicht wird, sich mit der Engine auseinanderzusetzen. Weiterhin ist es durch eine
7
8
Vgl. Unreal Technology (2009b)
Vgl. Unreal Technology (2009c)
28
freie Lizenz meist ohne Probleme möglich, das entstehende Produkt zu verbreiten, oftmals
auch in kommerzieller Hinsicht. Heutzutage werden auch im kommerziellen Bereich - sei es
nun die Spieleentwicklung oder andere Bereiche - häufig Open Source Engines verwendet, die
oft ohne weiteres mit kommerziellen Engines konkurrieren können. Ein Beispiel sei hier OGRE,
welche ebenfalls im kommerziellen Bereich eingesetzt wird, siehe Abschnitt 2.2.2 auf Seite 14.
Die Lizenz und die Kosten sind daher K. O. Kriterien bei der Auswahl der Engines.
3.2 Gewichtung der Kriterien
Dieser Abschnitt geht genauer auf die Kriterien ein, die bei der Bewertung der Engines
verwendet werden. Hier soll erklärt werden, warum die einzelnen Kriterien ihre entsprechende
Gewichtung erhielten. Die Kriterien wurden zuvor anhand der wichtigsten Aspekte einer
Engine mit Hinblick auf die Erlernbarkeit erarbeitet. Dabei wurden sie im Verlauf der Arbeit
mehrfach überarbeitet und mit dem betreuenden Professor abgestimmt.
Das oberste Ziel der Nutzwertanalyse, das Finden einer geeigneten Game Engine, „vereinigt
in sich die Gesamtheit - also 100% - aller Zielvorstellungen, die mit dem Projekt verfolgt
werden sollen.“9 Daher erscheint unter dem obersten Ziel die Zahl 100. Entsprechend wird
im ersten Durchlauf eine ungefähre Gewichtung vorgenommen, so dass die Teilziele in der
Summe 100 ergeben. Daraufhin werden die Kriterien erneut überarbeitet und in weiteren
Durchläufen die Gewichtung entsprechend angepasst, bis die finale Gewichtung erreicht wird.
Wie im vorigen Abschnitt erwähnt, ist die Gewichtung hierbei subjektiv geprägt und erlaubt
auch eine alternative Gewichtung.
Größe der Community und Support wird mit einer Gewichtung von 14 am höchsten
eingestuft, da dies einer der wichtigsten Punkte einer Game Engine ist. Eine gute Community
gibt nicht nur Hilfestellung bei der Einarbeitung und bei Problemen bezüglich der Engine,
sondern erweitert und verbessert sie auch aktiv und hält sie somit über einen längeren Zeitraum
am Leben.
Vorhandene Beispiele wird mit 12 gewichtet. Die vorhandenen Beispiele werden unter
dem Teilziel „Community“ angelegt, da die Anzahl der vorhandenen Beispiele, Tutorials und
bestehenden Projekte häufig von der Community abhängen. Die Beispiele helfen enorm bei
9
Brede (2005), S. 268
29
der Einarbeitung und dem Verständnis mit dem Umgang einer Engine. Darüber hinaus zeigen
sie oftmals verschiedene Ansätze und Lösungsmöglichkeiten.
Unterstützte Tools wird mit 9 Punkten gewichtet. Für die zusätzliche Erstellung von
Inhalten, wie beispielsweise dreidimensionale Modelle, sind externe Werkzeuge nötig. Daher
ist es wichtig, dass die Formate, die bei den Engines zum Einsatz kommen, auch von den am
weitesten verbreiteten Werkzeugen unterstützt werden.
Programmiersprache(n) wird mit 7 gewichtet. Diesem Kriterium darf keine zu wichtige Rolle
zugemessen werden. Im besten Fall werden von den Engines mehrere Programmiersprachen
unterstützt, damit man selbst zwischen den Sprachen wählen kann. Die wichtigste Sprache der
Spieleentwicklung, C++, sollte allerdings unterstützt werden. Java käme hier beispielsweise
nicht in Frage, da sie in der Spieleentwicklung kaum eine Rolle spielt.
Umfang, Funktionen und Features wird mit 10 gewichtet. Die Engines sollten über die
gängigsten Verfahren verfügen, wie beispielsweise aktuelle grafische Effekte und grafische
Verfahren. Damit ist sichergestellt, dass auch aktuelle Themengebiete der Theorie von
Computer Grafik gelehrt werden können. Werden weitere Funktionen, wie Kollisionserkennung
oder ein Szenengraph unterstützt, so erleichtert dies den Umgang mit der Engine.
Aufbau und Struktur wird mit 8 gewichtet, da eine monolithische Struktur es verwehrt,
eine Engine auf einfache Art zu erweitern. Der Aufbau und die Struktur unterstützen also
die Flexibilität einer Engine und vereinfachen die Verwendung. Dadurch erhöhen sich auch
die Möglichkeiten seitens der Community, die Engine zu erweitern und zu verbessern. Ein
objektorientierter Aufbau erleichtert dabei ebenfalls den Umgang mit der Engine und dient
der Lehre der Programmierkonzepte.
Unterstützte Plattformen und Schnittstellen wird mit 6 am geringsten gewichtet. Die
Plattformunabhängigkeit darf hier keine übergeordnete Rolle spielen. Allerdings sind die
Schnittstellen OpenGL und Direct3D wichtig für die Lehre der Computer Grafik und in vielen
Fällen unterstützen plattformunabhängige Engines beide Schnittstellen. Dadurch wird die
Engine auch für mehr Personen einsetzbar, die unterschiedliche Betriebssysteme verwenden.
Komplexität und Lernkurve wird mit 12 gewichtet. Es ist sehr wichtig, dass die Engine
schnell erlernbar und gut verständlich ist. Die Einarbeitung in eine komplexe Engine mit hoher
Lernkurve ist zeitintensiv. Berücksichtigt man die kurze Zeit eines Semesters, wirken eine
geringe Komplexität und eine niedrige Lernkurve unterstützend.
30
Verfügbare Literatur wird mit 10 gewichtet. Literatur hilft nicht nur bei der wissenschaftlichen
Arbeit mit der Thesis, sondern auch beim Erlernen der Engine. Ein gutes, übersichtliches
Buch oder ein umfassender Artikel gehen mehr ins Detail als ein herkömmliches Tutorial
oder andere vergleichbare Beispiele und stellen Zusammenhänge und Hintergründe besser dar.
Darüber hinaus erhält man die Informationen auf einen Blick und muss sie nicht erst im Netz
zusammensuchen.
Dokumentation wird mit 12 gewichtet. Die Dokumentation spielt eine große Rolle. Im
Wiki werden Einführungen, Installationsanleitungen und Lösungen für Probleme präsentiert.
Außerdem wird Hilfe für Erweiterungen gegeben. Die Dokumentation der Schnittstellen ist
wichtig für den Einstieg sowie die weitere Arbeit mit einer Engine.
3.3 Ergebnisse der Nutzwertanalyse
Gemessen anhand der ermittelten Nutzwerte gehen drei Engines als beste hervor: Microsofts
XNA, Irrlicht und OGRE. Die Bewertung soll bei diesen Engines an dieser Stelle nun genauer
betrachtet werden. Die restlichen Tabellen der Nutzwerte für die jeweiligen Engines finden
sich im Anhang auf Seite 93. Die Kriterien befinden sich in den Tabellen ab Seite 24.
XNA erreicht im Vergleich zu anderen Engines einen immer noch sehr guten Nutzwert. Die
höchsten Erreichungsgrade hat XNA bei den unterstützten Tools, beim Aufbau und der
Struktur und bei verfügbarer Literatur und der Dokumentation.
XNA nutzt das .x bzw. .fbx Format, das von jedem größeren, aber auch von vielen kleineren
Modellierungswerkzeugen unterstützt wird. Auch beim Aufbau und der Struktur verfügt
XNA über einen sehr guten Ansatz. Die Struktur wird dabei durch das XNA Game Studio
vorgegeben, dadurch lassen sich einheitliche Programme schreiben. Es wird die Erstellung
sogenannter Game Components ermöglicht, die in verschiedenen Projekten wiederverwendet
oder mit anderen Entwicklern ausgetauscht werden können. Dies könnte beispielsweise ein
Code zur Darstellung von Terrain oder etwas Vergleichbares sein. Es gibt viel Literatur zu XNA.
Auf der Seite der ACM Bibliothek10 gibt es mehrere Artikel und es existieren auch mehrere
Bücher. Hier hat XNA gegenüber den anderen Engines eine deutlich bessere Bewertung
erhalten. Die Dokumentation deckt innerhalb der Microsoft Developer Library11 alles ab. Als
10
11
http://portal.acm.org/portal.cfm
http://msdn.microsoft.com/en-us/library/default.aspx
31
Programmiersprache unterstützt XNA ausschließlich C#. XNA kann lediglich auf Windows
Plattformen verwendet werden und beherrscht ausschließlich die Schnittstelle Direct3D. Der
ermittelte Nutzwert und die einzelnen Bewertungen sind in Tabelle 3.4 dargestellt.
Microsoft XNA
Kriterium
Erreichungsgrad
Nutzwert
1
3.5
49
2
3
36
3
4
36
4
3
21
5
2.5
25
6
4
32
7
2
12
8
2.5
30
9
4
40
10
4
48
Gesamt
329
Tab. 3.4: Ergebnisse der Nutzwertanalyse: Nutzwert Microsoft XNA
Irrlicht belegt gemessen am Nutzwert den zweiten Platz. Irrlicht ähnelt OGRE in vielerlei Hinsicht. Bei der Größe, dem Support und der Qualität der Community, den unterstützten Tools,
den Programmiersprachen, dem Umfang, den unterstützten Plattformen und Schnittstellen und
bei der Komplexität und Lernkurve schneidet Irrlicht mit dem bestmöglichen Erreichungsgrad
ab. Die Community um Irrlicht gliedert sich in mehrere verschiedensprachige Gemeinschaften,
unter anderem Deutsch und Französisch. Allein die englischsprachige Community hat ca.
11300 registrierte Mitglieder. Sie ist sehr aktiv und entwickelt stetig Erweiterungen sowie
Verbesserungen für die Engine. Man erhält schnell Antworten auf gestellte Fragen. Es werden
sämtliche Formate unterstützt, wie etwa für Maya, 3dsmax, COLLADA, Milkshape und
weitere. Irrlicht ist in C++ geschrieben, jedoch existieren mehrere Anbindungen für Sprachen
wie Java, .NET und Delphi. Es gibt einen Leveleditor sowie ein Soundsystem und Anbindungen
für die gängigsten Physikbibliotheken. Irrlicht beherrscht Direct3D, OpenGL und verfügt über
einen eigenen Software Renderer. Vor allem Lernkurve und Komplexität sind sehr niedrig. Der
ermittelte Nutzwert und die einzelnen Bewertungen sind in Tabelle 3.5 dargestellt.
32
Irrlicht
Kriterium
Erreichungsgrad
Nutzwert
1
4
56
2
3.5
42
3
4
36
4
4
28
5
4
40
6
3.5
28
7
4
24
8
4
48
9
2.5
25
10
3.5
42
Gesamt
369
Tab. 3.5: Ergebnisse der Nutzwertanalyse: Nutzwert Irrlicht
Den besten Nutzwert erreicht OGRE. Hier liegen die Stärken der Engine vor allem in der
Community, den unterstützten Tools, den Programmiersprachen, dem Aufbau und der Struktur,
den unterstützten Plattformen und Schnittstellen sowie der Dokumentation. Die Community
umfasst ca. 20000 Mitglieder, davon einige Kernmitglieder, welche dauerhaft weiterentwickeln
und sehr aktiv im Forum sind. Die Community hat bereits viele zusätzliche Programme für
OGRE geschaffen. Bei Fragen erhält man innerhalb kürzester Zeit Antworten. Auch hier werden
alle gängigen Werkzeuge unterstützt. Bei den Programmiersprachen ist die Hauptsprache
C++, darüber hinaus existieren aber verschiedene Anbindungen, beispielsweise für Java, C#
und Python. Somit ist es möglich, OGRE auch mit anderen Sprachen zu verwenden. Daher
erhält OGRE auch hier die bestmögliche Bewertung. Der Aufbau von OGRE ist sehr modular
und flexibel, es lassen sich verschiedene Methoden zur Darstellung von Terrain sehr einfach
austauschen, man kann auf einfache Weise ein Physiksystem hinzufügen und es existiert
eine große Anzahl an Frameworks, welche die Entwicklung mit OGRE erleichtern. OGRE
verfolgt einen sehr objektorientierten Ansatz, beispielsweise durch die starke Verwendung
von Entwurfsmustern. Die Dokumentation von OGRE ist sehr gut, es werden Beispiele bei
der Installation mitgeliefert und das Wiki verfügt über sehr gute Einführungen und Artikel
für die Weiterbildung. Darüber hinaus gibt es eine Schnittstellendokumentation sowie ein
Benutzerhandbuch. Es gibt sogar ein Glossar für die gängigsten Begriffe der Computer Grafik.
Der ermittelte Nutzwert und die einzelnen Bewertungen sind in Tabelle 3.6 dargestellt.
33
OGRE
Kriterium
Erreichungsgrad
Nutzwert
1
4
56
2
3.5
42
3
4
36
4
4
28
5
3.5
35
6
4
32
7
4
24
8
3.5
42
9
3
30
10
4
48
Gesamt
373
Tab. 3.6: Ergebnisse der Nutzwertanalyse: Nutzwert OGRE
Viele andere Engines scheitern an der Dokumentation, der Lernkurve und Komplexität, den
vorhandenen Beispielen und der Community. Das sind mitunter die wichtigsten Punkte
einer Engine. Oft liegt dies daran, dass die Engines sich noch in einem frühen Stadium der
Entwicklung befinden. OGRE wird im Gegensatz dazu seit 10 Jahren entwickelt. Daher sollten
diese noch recht jungen Engines in Zukunft nicht einfach außer Acht gelassen werden.
3.4 Auswahl der zu verwendenden Engine
Die Engine, die letztendlich Verwendung finden soll, wird durch ein praktisches Ausspielen der
Engines gegeneinander ausfindig gemacht. Dabei wird für jede der drei besten Engines eine
kleine Anwendung geschrieben, um die Engines genauer zu testen und durch die praktische
Entwicklung herauszufinden, welche Engine letztendlich am besten geeignet ist.
Im Direktvergleich schneidet XNA am schlechtesten ab. Bei XNA fällt vor allem auf, dass viele
Beispielprojekte meist über einen sehr großen Umfang verfügen. Kleinere Beispiele würden eine
schnellere und bessere Einsicht in ein Problem oder einen Lösungsansatz geben. Beim Studium
von größeren Beispielen fehlen oft Zusammenhänge innerhalb der Anwendung, der Code
kann nicht so einfach verstanden werden und benötigt somit eine längere Einarbeitungszeit.
Bei XNA werden außerdem keinerlei Beispielprojekte mitgeliefert. Zudem setzt XNA von
34
Beginn an auf die Verwendung von Shadern. Zwar gibt es dafür eine Standardvorlage, jedoch
lässt sich mit dieser nur ein recht kleines Spektrum an Effekten und Beleuchtung abdecken.
Allgemein ist die Lernkurve und die Komplexität höher als bei den anderen Engines, vor allem,
da man von Beginn an die Programmierung von Shadern beherrschen muss. Somit muss
man auch zwingend über eine shaderfähige Grafikkarte verfügen, um mit XNA entwickeln zu
können. Weiterhin kann XNA nur auf Windows Plattformen mit der Schnittstelle Direct3D
verwendet werden und unterstützt lediglich die Programmiersprache C#.
Irrlicht schneidet sehr gut beim Direktvergleich ab. Vor allem der positive Eindruck von
Erlernbarkeit und niedriger Komplexität verstärkt sich beim praktischen Testen. Auch die
verfügbaren Beispiele und die Gemeinschaft um die Engine weisen eine hohe Qualität auf.
Die Recherchen in der Dokumentation und dem Wiki zeigen allerdings einige Mängel. Zum
Zeitpunkt der Verfassung dieser Arbeit befindet sich das Irrlicht Wiki in einer Umstrukturierung, wodurch kein brauchbares Einstiegstutorial verfügbar ist. OGRE hinterlässt in den
genannten Punkten im Direktvergleich durchweg einen besseren Eindruck. Daher fällt die
Wahl letztendlich doch auf OGRE.
3.5 Demonstration und Ansätze für die Lehre
Um die letztendlich gewählte Engine zu testen, zu demonstrieren und einen guten Lösungsansatz zu ermöglichen, wurde ein Konzept für ein Spiel entwickelt. Dieses enthält die
grundlegenden Anforderungen, über die das Spiel verfügen muss. Das Spielprinzip gestaltet
sich hierbei recht simpel: Der Spieler steuert ein geometrisches Objekt über eine Strecke
und muss dabei versuchen, Hindernissen sowie gegnerischen Objekten auszuweichen. Beim
Zusammenprall verliert der Spieler an Energie. Wenn er bestimmte Objekte aufsammelt,
gewinnt er an Punkten und Fähigkeiten. Das Spiel ist darauf ausgelegt, die Fähigkeiten der
verwendeten Engine zu demonstrieren und Ansatzpunkte für die Lehre der Computer Grafik
zu geben. Ganovelli und Corsini (2009) zeigen einen Ansatz für die Lehre von Computer
Grafik mit Hilfe eines Rennspiels für mehrere Spieler. Das Rennspiel ist ein Framework, dessen
Rendering Methode von den Studenten eigens implementiert werden muss. Dadurch ergeben
sich unterschiedliche Lösungsansätze, die dann unter den Studenten verglichen werden können.
Durch die Entwicklung mit Hilfe des Frameworks sollen die Studenten mit grundsätzlichen
und fortgeschrittenen Themen der Computer Grafik vertraut gemacht werden. Zu den grund-
35
sätzlichen Themen gehören dabei geometrische Transformationen sowie Beleuchtung und
Texturen. Geometrische Transformationen erlernen die Studenten dabei durch die Positionierung von Szenenobjekten, durch Kamerabewegungen oder durch Anwendung von Matrizen
zur Rotation der Autoreifen. Bei der Beleuchtung wird das Phong Beleuchtungsmodell mit
einem ambienten Licht und einem Richtungslicht verwendet. Zusätzlich können die Studenten
am Rand der Straße beispielsweise Lampen platzieren. Um den Umgang mit Texturen zu
lernen, können die Studenten die Autos, das Terrain, die Gebäude und die Straße selbst
texturieren. Um eine ausreichende Punktzahl in der Bewertung zu bekommen, muss man dabei
die grundsätzlichen Themen implementieren. Zu den fortgeschrittenen Themen zählen unter
anderem Shadow Mapping, Partikel Systeme und Skyboxes. Das Framework wurde testweise
in verschiedenen Universitäten verwendet. Dabei konnten die Studenten zwischen anderen
Projekten und dem Framework des Rennspiels wählen. 28 von 30 Studenten entschieden
sich dabei für das Framework des Rennspiels. Die meisten Studenten bezeichneten es als ein
hilfreiches Lernwerkzeug.12
Wie lassen sich die Lehransätze nun in die eigene Anwendung integrieren? Hierfür wurden
folgende Ideen gesammelt:
• Der Spieler soll über eine Matrixmanipulation das Spielerobjekt bewegen bzw. skalieren
können
• Das Spiel wird in Levels aufgeteilt. In jedem Level wird ein anderes Thema der Computer Grafik behandelt. Je weiter der Spieler fortschreitet, desto mehr Aspekte der
Computer Grafik werden berücksichtigt. Behandelt man im ersten Level ausschließlich
grundlegende Themen der Computer Grafik, so werden im letzten Level fortgeschrittene
Themengebiete wie beispielsweise Shader abgedeckt
• Über sogenannte Informationsbildschirme und Informationstexte werden Informationen
zum aktuellen Level eingeblendet
• Die Objekte im Spiel können vom Spieler selbst texturiert werden
• Über ein Quiz am Ende eines Levels muss der Spieler sein angeeignetes Wissen beweisen,
indem er eine Fragestellung korrekt beantwortet
• Der Code an sich lässt sich selbstverständlich auch für die Lehre verwenden. Durch
Änderungen am Code ist es möglich, anhand der daraus resultierenden Auswirkungen
12
Vgl. Ganovelli und Corsini (2009)
36
zu lernen
• Über das Materialsystem der Engine können Materialien ohne neues Kompilieren
verändert und die Resultate begutachtet und verstanden werden
Laut Clua u. a. (2006) verbessert sich der Lernprozess aus Gründen der Motivation und aufgrund der Hochwertigkeit der Ergebnisse, die mit relativ wenig Aufwand hervorgerufen werden
können, wenn ein interaktiver, spielerischer Ansatz verwendet wird. Einen ähnlichen Ansatz
verfolgt Taxén (2003), der den Lernprozess darüber hinaus mit Hilfe einer konstruktivistischen
Didaktik unterstützt. Auf die konstruktivistische Didaktik soll hier nicht näher eingegangen
werden. Taxén (2003) lässt die Teilnehmer dabei im praktischen Teil seines Kurses Texturen
auf ein dreidimensionales Modell abbilden. Zusätzlich sollen die Teilnehmer ein Modell doppelt
so schnell rotieren lassen und eine Kamera und verschiedene Lichtquellen an unterschiedliche
Positionen verschieben sowie deren Eigenschaften ändern.13
3.6 Erstellung und Auswertung des Fragebogens
Um die Tauglichkeit der Anwendung zu evaluieren, wird ein Fragebogen mit Hilfe von Open
Office und Microsoft Word entwickelt und an die betreuenden Professoren sowie an die
Studenten des derzeitigen und des ehemaligen Semesters der Computer Grafik mitsamt der
Anwendung geschickt.
Der Fragebogen geht dabei auf allgemeine Fehler ein, die beim Start oder während des
Spielablaufs auftreten können. Es werden Fragen zum Spielspaß, zur Schwierigkeit des Spiels
und zur Spielidee gestellt. Außerdem enthält der Fragebogen Fragen zur Bedienung und zum
Spielziel. Dabei wird hinterfragt, ob das Spielziel ersichtlich ist oder nicht. Abgesehen von
diesen allgemeinen Fragen wird auch explizit auf die Computer Grafik eingegangen, etwa ob
man es für sinnvoll hält, die Theorie spielerisch erlernbar zu machen oder ob die Anwendung
überhaupt hilft. Weiterhin können auch Ideen für die Ansätze der Lehre und allgemeine
Verbesserungsvorschläge beziehungsweise Anregungen eingetragen werden.
13
Vgl. Taxén (2003), S. 3
37
Leider wurden nur vier Fragebögen zurückgesandt. Zwei Personen haben aufgrund der
Fehler beim Spielstart den Fragebogen nicht ausgefüllt, obwohl sich in einer mitgesandten
Installationsanleitung eindeutige Anweisungen zur Fehlerbehebung befanden. Die Auswertung
der Fragebögen zeigt, dass mehr als die Hälfte der Personen Probleme beim Start des Spiels
haben, ausgelöst durch eine veraltete Version von DirectX. Dreiviertel der Befragten macht das
Spiel Spaß und auch die Spielidee gefällt. Wobei es hinsichtlich der Spielidee Anregungen gibt,
sie insgesamt noch spannender zu gestalten. Drei von vier Befragten finden es auch sinnvoll,
die Computer Grafik spielerisch erlernbar zu machen. Alle Testpersonen geben an, dass sich das
Spiel gut bedienen und auch steuern lässt. Dabei ist das Spielziel nicht durchweg ersichtlich,
auch den Ansatz mit der Matrixmanipulation haben nicht alle verstanden. Darüber hinaus gibt
es noch einige Fehler im Spielablauf. Manchmal können bestimmte Objekte nicht eingesammelt
werden und das Spiel muss neu gestartet werden, um freigeschaltete Levels auswählen zu
können. Weiterhin lassen sich manchmal Menüs der grafischen Benutzeroberfläche nicht
öffnen. Nur zwei Personen haben Angaben zur Schwierigkeit des Spiels gemacht, dabei war es
einmal zu leicht und einmal zu schwer. Alle Testpersonen sind sich einig, dass die Interaktion
im Spiel noch gesteigert werden sollte, es sollte also noch mehr Möglichkeiten geben, die
Theorie interaktiv zu erlernen. Insgesamt sind die Befragten einer Meinung, dass es dem
Spiel derzeit noch an Abwechslung mangelt und mehr interaktive Aufgaben integriert werden
sollten. Die Mehrheit der Testpersonen lernt derzeit noch nichts durch die Anwendung, was
aber auch vor allem an der kurzen Testzeit liegen könnte - man merkt den Fragebögen an,
dass sie hektisch ausgefüllt wurden und dass die dazugehörige Anwendung nicht ausreichend
getestet wurde. Manche Testpersonen merkten nicht einmal, dass das Spiel über mehrere
Levels verfügt. Zu den Problembereichen der Computer Grafik zählt laut einer Testperson
der Bereich der Mathematik. Diesem Bereich sollte demnach noch mehr Aufmerksamkeit
in der Anwendung gewidmet werden. Die Befragten fühlen sich manchmal auch durch das
hektische Spielprinzip überfordert. Hier gilt es also nachträglich nochmals zu prüfen, ob sich
das Spielprinzip in der gegenwärtigen Form überhaupt für die Lehre eignet.
Insgesamt lässt sich aus den Ergebnissen schließen, dass die Anwendung bisher noch keine
sinnvolle Anwendung für die Lehre darstellt. In vielen Bereichen fehlt noch der Feinschliff.
Das Spiel ist noch zu schwer und der Spielablauf zu hektisch. Auch an der spielerischen
Interaktion zum Erlernen der Theorie mangelt es noch. Der überwiegende Teil der Befragten
hält es aber für sinnvoll, Computer Grafik praktisch und spielerisch erlernbar zu machen.
Clua u. a. (2006) und Ganovelli und Corsini (2009) haben zuvor bereits gezeigt, welche
38
positiven Auswirkungen spielerisches und interaktives Lernen haben kann. Die Ergebnisse
der Auswertung sind allerdings kritisch zu betrachten, da von den Testpersonen offenbar
nicht ausreichend getestet wurde und zu wenige Personen den Fragebogen ausgefüllt haben.
Weiterhin fehlte in diesem Fall auch die unterstützende Didaktik des Lehrers. Wird die
Anwendung unter Anweisungen des Lehrers verwendet, ergibt sich möglicherweise ein anderes
Ergebnis.
Der Fragebogen befindet sich im Anhang im Abschnitt A.4 auf Seite 106.
39
4 OGRE
Dieses Kapitel behandelt die im vorigen Kapitel durch die Nutzwertanalyse bestimmte Engine
im Detail: Es wird eine allgemeine Einführung gegeben, anschließend erfährt man genaueres
über die Entwickler, die hinter OGRE stehen. Weiterhin werden Struktur und Aufbau der
Engine erläutert und in diesem Zusammenhang die Philosophie des Designs erklärt. Im letzten
Teil wird auf einige wichtige Erweiterungen eingegangen, die OGRE erst zu einer Game Engine
im eigentlichen Sinne erweitern.
4.1 Engine Einführung
OGRE ist eine Abkürzung und steht für „Object Oriented Rendering Engine“. Hieraus ist bereits
erkennbar, dass die Engine großen Wert auf Objektorientierung legt. Mit Hilfe von OGRE ist
es möglich, 3D-Echtzeitanwendungen zu entwickeln. OGRE ist im Kern keine vollständige
Game Engine, kann aber aufgrund der flexiblen und modularen Architektur ohne weiteres zu
einer Game Engine erweitert werden. Es existieren zahlreiche zusätzliche Bibliotheken wie
beispielsweise CEGUI oder OIS, die bei der Erstellung von grafischen Benutzeroberflächen
und dem Abfangen von Benutzereingaben helfen. Weiterhin gibt es sogenannte „Wrapper “,
die es zum Beispiel ermöglichen, eine Physikengine wie die Open Dynamics Engine (ODE) zu
verwenden.
OGRE bietet gleichwertige Unterstützung für OpenGL und Direct3D und läuft auf Windows,
Linux und Mac OS X. OGRE bietet unter anderem Funktionen wie zum Beispiel Unterstützung
für verschiedene Shading Sprachen, ein Materialsystem, verschiedene Schattentechniken und
Texturformate wie PNG, TGA, JPG und vieles mehr.1 Das SDK ist unter der Lesser GNU
Public License2 lizenziert. Das bedeutet zum einen, dass OGRE selbst kostenlos ist und zum
anderen, dass damit erstellte Anwendungen frei vertrieben werden können.
1
2
Vgl. Junker (2006), S. 4 f.
http://www.gnu.de/documents/lgpl.en.html
40
4 OGRE
Der Gründer von OGRE, Steve Streeting, beschreibt die Philosophie von OGRE folgendermaßen:
„Many other engines whilst technically impressive lack the cohesive design and the consistent
documentation to allow them to be used effectively. Many of them have long features lists,
but have the feel of a bunch of tech demos lashed together with twine, with no clear vision
to hold them together. Like any other software system this becomes their downfall as they
become larger. Most other engines are also designed for one particular style of game or demo
(e. g. first-person shooters, terrain roamers).
OGRE is different. OGRE is design-led rather than feature-led. Every feature that goes into
OGRE is considered thoroughly and slotted into the overall design as elegantly as possible
and is always fully documented, meaning that the features which are there always feel part
of a cohesive whole. Quality is favoured over quantity, because quantity can come later quality can never be added in retrospect. OGRE uses sound design principles learned, tried
and tested many times in commercial-grade software - the object-orientation mentioned in
its moniker is just on of those approaches - frequent use of design patterns is another.“3
In kurzen Worten zusammengefasst liegt der Fokus der Engine auf dem Design und nicht
auf der Masse von Bestandteilen. Alle Bestandteile werden so elegant wie möglich in das
Gesamtkonzept integriert, das Augenmerk richtet sich also auf Qualität und nicht auf Quantität.
Entwurfsmuster und objektorientierte Programmierung sind ein Aspekt der Philosophie von
OGRE. Damit schlägt diese Engine einen zukunftsgerichteten Weg ein.
OGRE wurde von Steve Streeting Ende des Jahres 2000 ins Leben gerufen und war von
Anfang an als gut konzipierte, szenenstrukturierte und unabhängige Engine geplant. Steve
Streeting konnte zuvor auf eine zehnjährige Karriere als professioneller Softwareentwickler
zurückblicken und hat an einer Reihe von Projekten mitgearbeitet, unter anderem auch im
Bereich des grafischen Renderings.4 Derzeit wird OGRE von einem Kernteam entwickelt, das
zum Zeitpunkt dieser Thesis aus sechs Mitgliedern besteht.5
3
Junker (2006), S. 6
Vgl. Junker (2006), S. xvii
5
Vgl. OGRE (2009e)
4
41
4 OGRE
4.2 Struktur und Aufbau von OGRE
OGRE ist in mehrere Teilsysteme unterteilt, die im Folgenden näher beschrieben werden.
4.2.1 Root Objekt
Das Root Objekt ist der Hauptzugangspunkt einer OGRE Anwendung. Über dieses Objekt
wird der Zugang zu jedem Teilsystem innerhalb einer OGRE Anwendung ermöglicht. Die
Instanziierung des Root Objektes startet OGRE und die Zerstörung des Objektes beendet
OGRE ordnungsgemäß.6 Über das Root Objekt erhält man zum Beispiel Zugriff auf den
Szenenmanager und das Render Fenster.
4.2.2 Szenenmanager und Szenengraph
Dass OGRE szenengraphbasiert ist, wurde zuvor bereits erwähnt. Das Szenengraphkonzept ist
Teil eines größeren Konzepts in OGRE, das als Szenenmanager bekannt ist. Alle Implementierungen eines Szenengraphen werden von der Klasse des Szenenmanagers abgeleitet. Dabei
werden sogenannte „Scene Nodes“ an den Szenenmanager angehängt. Diese Scene Nodes
sind jene Objekte, die später in der Szene bewegt werden können. An diese Scene Nodes
können weitere Kindobjekte angehängt und anschließend bewegt, rotiert und skaliert werden.
Sie können auch unabhängig vom Szenengraph existieren. Wenn man vermeiden möchte, dass
die Objekte dargestellt werden, koppelt man sie schlichtweg vom Szenengraph ab. Die meisten
Objekte werden als Instanzen von Entity an den Szenengraph angehängt, die ebenfalls vom
Szenenamanager erstellt werden.7 Entity Objekte enthalten die Rendering Eigenschaften,
auch bekannt als Materialien.8 Diese Entity Objekte vergügen unter Umständen über weitere
Subentitys. Ein Beispiel wäre hier das Modell des OGRE Kopfes. Es enthält Angaben zu
den Texturen sowie weitere Subentitys wie etwa Zähne und Augen, die wiederum einzeln
angesprochen werden können.
6
Vgl. Junker (2006), S. 46
8
7
42
4 OGRE
Abb. 4.1: OGRE: Der Szenengraph (Vgl. Junker (2006), S. 39)
Ein Szenengraph ist typischerweise für schnelle Suchen und Abfragen optimiert. Er ermöglicht
dem Benutzer, bestimmte Elemente in der Nähe von anderen Elementen zu finden. Es wird
außerdem ermöglicht, Polygone zu finden, zu sortieren und auszusortieren (engl. culling),
um eine effizientere Darstellung erhalten zu können. Mitunter wird der Szenengraph auch
für Kollisionserkennung oder für Teilsysteme wie Audio und Physik verwendet. Anders als
die meisten Implementierungen, baut OGRE auf eine austauschbare Architektur für den
Szenengraph. Dies ermöglicht im Gegensatz zu vielen anderen Szenengraphimplementierungen
somit also die Verwendung von anderen Datentypen wie Physik oder Audio.9
Das Design von OGRE ermöglicht es auch, mehrere Szenenmanager gleichzeitig zu verwenden.
9
43
4 OGRE
Je nach Art der Ausrichtung und dem Zweck der Anwendung wird davon profitiert. Für
viele ist diese Herangehensweise die Lösung für die „Portalling“-Problematik. „Portal“ ist
die läufige Bezeichnung für die Grenze zwischen einer Optimierungs- bzw. Komplexitätsmanagementstrategie und einer anderen Strategie, wie zum Beispiel der Betrachtung einer
Landschaft aus dem Fenster eines Innenlevels. Dies ist nicht einfach, weil die Szenenmanager
oft speziell für die Darstellung von Innen- oder Außenarealen optimiert sind. Daher bietet
OGRE verschiedene Typen von Szenenmanagern an.10
4.2.3 Ressourcenmanagement
Alles was von OGRE benötigt wird, um eine Szene darzustellen, wird als Ressource (engl.
resource) bezeichnet. Und alle Ressourcen werden von einem einzigen Objekt verwaltet, dem
ResourceGroupManager. Dieses Objekt ist für die Positionsbestimmung und Initialisierung
der Ressourcen zuständig, die unter den angegebenen Suchpfaden gefunden werden. Dazu
gehören unter anderem Meshs, Materialien, Fonts, Texturen und andere Ressourcen.11
4.2.4 Render Systeme und Render Targets
Das Render System ist eine Verallgemeinerung zwischen OGRE und der darunter liegenden
Programmierschnittstelle der Hardware für OpenGL bzw. Direct3D. Für gewöhnlich interagiert
man nicht direkt mit dem Render System. Stattdessen interagiert man mit einem Objekt, das
vom Render System erstellt wird und als Render Target bezeichnet wird. Render Target ist
eine Verallgemeinerung von zwei wichtigen Objekten in OGRE: Das Render Fenster und die
Render Texture. Das Render Fenster ist das Hauptfenster einer Anwendung, es lassen sich
auch mehrere Render Fenster in einem erstellen. Es kann hierbei automatisch oder manuell
über das Root Objekt oder über das Render System erstellt werden. Eine manuelle Erstellung
erlaubt mehr Einstellungsmöglichkeiten des Fensters, wie beispielsweise die Auflösung und
den Namen.12 Mit der Render Texture können Teile der Szene oder die gesamte Szene auf
einer Textur dargestellt werden.13
10
Vgl.
Vgl.
12
Vgl.
13
Vgl.
11
Junker
Junker
Junker
Junker
(2006),
(2006),
(2006),
(2006),
S.
S.
S.
S.
78 f.
46 ff.
48
161
44
4 OGRE
4.2.5 OGRE Manager
Ein Manager in OGRE ist eine Klasse, die den Zugang zu oder die Lebensdauer von anderen
verwandten Objekttypen verwaltet. Hier sollen auszugsweise einige Beispiele für Manager
genannt und erläutert werden:
• Der Materialmanager verwaltet alle Materialinstanzen in der Anwendung und erlaubt
die Wiederverwendung von Materialobjekten mit demselben Namen
• Der Texturmanager verwaltet die Lebensdauer von und den Zugang zu allen Texturen,
die innerhalb der Anwendung referenziert, geladen oder verwendet werden
• Der Plattformmanager ermöglicht einen abstrakten Zugriff auf alle Details der unterliegenden Hardware und dem Betriebssystem, wie beispielsweise Timer und fensterspezifische Dinge wie etwa den OGRE Konfigurationsdialog beim Start einer Anwendung
• Der Archivmanager ermöglicht den Zugriff auf Ressourcen wie Ordner im Dateisystem
oder komprimierte Dateien wie etwa ZIP
Es existieren weitere Manager, unter anderem für Meshs, Fonts, Overlays, Skeletons, Partikel
und Logging.14
14
Vgl. Junker (2006), S. 49 ff.
45
4 OGRE
Abb. 4.2: OGRE: High Level Klassendiagramm von Root Objekt und Managern (Vgl. OGRE
(2009b))
4.3 Erweiterungen für OGRE
Wie zuvor bereits erwähnt, handelt es sich bei OGRE nicht um eine Game Engine, sondern um
eine reine Rendering Engine. An dieser Stelle sollen beispielhaft einige wichtige und sinnvolle
Erweiterungen für OGRE vorgestellt werden, die die fehlenden Komponenten ersetzen oder
OGRE auf andere Art und Weise sinnvoll bereichern können.
OIS
OIS steht für „Object Oriented Input System“, und stellt ein objektorientiertes Eingabesystem
dar. Es handelt sich hierbei um eine plattformunabhängige Open-Source-Bibliothek, mit der
Tastaturen, Mäuse und Joysticks angesteuert werden können. Mit OIS können Eingaben in
OGRE abgefangen werden.15
CEGUI
CEGUI steht für „Crazy Eddie’s GUI System“ und ist eine plattformunabhängige freie Bibliothek, die Fenster und Widgets bereitstellt. Mit der Bibliothek lassen sich grafische Benutzer15
Vgl. OGRE (2009d)
46
4 OGRE
oberflächen entwickeln. CEGUI wird oftmals in OGRE Anwendungen eingesetzt, kann jedoch
auch in anderen Projekten verwendet werden.16
OgreODE
OgreODE ist ein Wrapper für die bekannte Physikbibliothek ODE (Open Dynamics Engine).
ODE beherrscht die Simulation starrer Körper. Die Bibliothek enthält auch ein Kollisionserkennungssystem.17
NxOgre
NxOgre ist ein Wrapper für die bekannte Physikbibliothek PhysX18 . Ursprünglich wurde
PhysX von Ageia entwickelt.19
OgreNewt
Hierbei handelt es sich um einen Wrapper für eine weitere Physikbibliothek namens Newton
Game Dynamics20 , die kostenlos für nichtkommerzielle Zwecke eingesetzt werden kann.21
COLLADA
COLLADA stellt ein wichtiges Unterfangen der gesamten 3D-Grafikindustrie dar. Es handelt
sich hierbei um ein gemeinsames Format, das alle Programme zur Inhalteerstellung wie etwa
3dsmax oder Blender verstehen können. Das COLLADA Format basiert auf XML. Es existiert
ein Plugin für OGRE, welches in der Lage ist, dieses Format zu verwenden.22
OgreAL
OgreAL ist ein Wrapper für OpenAL, wodurch sich Musik und 3D-Audioeffekte in OGRE
Anwendungen integrieren lassen. OpenAL ist eine plattformunabhängige 3D-Audio-API, die
von Creative entwickelt wurde und unter anderem für Spiele oder andere Anwendungen
verwendet werden kann. Es ist eine statusbasierte API, die einem Muster folgt, welches dem
von OpenGL ähnelt.23
16
Vgl. OGRE (2009a)
Vgl. Open Dynamics Engine (2009)
18
Vgl. NxOgre (2009)
19
Vgl. Junker (2006), S. 252
20
http://newtondynamics.com/
21
Vgl. Junker (2006), S. 252
22
Vgl. Junker (2006), S. 251
23
Vgl. OGRE (2009c)
17
47
4 OGRE
Ogitor
Ogitor ist ein pluginbasierter WYSIWYG 24 Editor für OGRE. Mit diesem ist die einfache
Erstellung von Szenen möglich, die anschließend mit OGRE geladen werden können. Durch das
von OGRE inspirierte Plugin-Konzept ist es möglich, eigens für OGRE entwickelte Bibliotheken
direkt in Ogitor zu verwenden. Dabei wird ein XML Format namens „.ogscene“ verwendet.
Es ist allerdings auch möglich, eigene Plugins für den Export bzw. Import zu verwenden.25
24
25
Abk. für „What you see is what you get“
Vgl. Ogitor (2009)
48
5 Konzeption
In diesem Kapitel wird die Konzeption der Anwendung beschrieben. Es wird auf die Erhebung
der Anforderungen und deren Definitionen eingegangen. Ausgehend von den Anforderungen
wird eine Architektur für die Anwendung entwickelt, die im Verlauf des Kapitels näher
beschrieben wird.
5.1 Spielkonzept
5.1.1 Grundlagen der Spielemechanik
Um ein Spiel für die Lehre zu entwickeln, wird zunächst mit der Konzeption des Spiels
begonnen. Hierbei wird im ersten Schritt das Genre des Spiels festgelegt. Da das Spiel zum
Zwecke der Lehre eingesetzt werden soll, werden Genres wie Shooter oder Strategiespiele
außen vor gelassen und als Genre das Feld der Geschicklichkeit gewählt. Im weiteren Schritt
wird eine Spielidee erdacht. Der Spieler soll dabei eine Spielfigur über eine festgelegte Strecke
steuern und Hindernissen sowie anderen gegnerischen Objekten ausweichen. Hierfür müssen
zunächst die konkreten Spielelemente- und regeln festgelegt werden. Schell (2008) beschreibt
diese folgendermaßen:
„Game mechanics are the core of what a game truly is. They are the interactions
and relationships that remain when all of the aesthetics, technology, and story
are stripped away.“ 1
Hier gibt es laut Schell (2008) verschiedene Aspekte der Spielemechanik, die im Folgenden
näher beschrieben werden.
1
Schell (2008), S. 130
49
5 Konzeption
Raum (Space)
Ein Aspekt der Spielemechanik ist der Raum. Dabei muss jedes Spiel in irgendeiner Art von
Raum stattfinden. Über diesen Raum werden die verschiedenen Orte definiert, die innerhalb
eines Spiels existieren und wie sie miteinander zusammenhängen. Beispielsweise nutzt das
Spiel Tic-Tac-Toe ein diskretes, zweidimensionales Spielfeld. Diskret bedeutet hier, dass man
sich mehr um die Grenzen des Spielfelds, als um den Platz darin kümmert.2
Objekte, Eigenschaften und deren Beschaffenheiten (Objects, Attributes, States)
Innerhalb des Spiels und genauer der Spielwelt gibt es Objekte wie beispielsweise Charaktere,
Requisiten, Anzeigetafeln und andere Dinge, die gesehen oder manipuliert werden können.
All diese Dinge gehören in diese Kategorie. Diese Objekte sind sozusagen die „Nomen“ der
Spielemechanik. Sie haben für gewöhnlich eine oder mehrere Eigenschaften, dazu gehört auch
die aktuelle Position in der Spielwelt. Eigenschaften in einem Rennspiel sind beispielsweise die
maximale Geschwindigkeit und die aktuelle Geschwindigkeit eines Autos. Jede Eigenschaft hat
eine aktuelle Beschaffenheit. Die Beschaffenheit der Eigenschaft „maximale Geschwindigkeit“
könnte 150 km/h sein, während die Beschaffenheit der Eigenschaft „aktuelle Geschwindigkeit“
75 km/h sein könnte. Wenn Objekte die Nomen der Spielemechanik sind, sind Eigenschaften
und deren Beschaffenheit die Adjektive. Eigenschaften können dabei statisch, wie beispielsweise
eine Farbe, oder dynamisch sein (Bewegungsmodus mit drei möglichen Beschaffenheiten wie
„normal“, „schnell“ oder „langsam“).3
Aktionen (Actions)
Ein weiteres wichtiges Element ist die Aktion. Aktionen sind laut Schell (2008) die „Verben“
der Spielemechanik. Dabei gibt es zwei Sichtweisen auf Aktionen. Oder anders ausgedrückt,
zwei Wege, die Frage, was ein Spieler machen kann, zu beantworten. Die erste Art von
Aktionen sind die operativen Aktionen. Diese stellen die Basisaktionen dar, die ein Spieler
ausführen kann. In dem Spiel Dame kann ein Spieler beispielsweise einen Spielstein forwärts
bewegen, einen Gegner überspringen oder sich rückwärts bewegen (nur die Dame). Die andere
Art von Aktionen stellen resultierende Aktionen dar. Diese haben nur im Gesamtbild des
Spiels eine Bedeutung. Sie hängen damit zusammen, wie der Spieler die operativen Aktionen
verwendet, um ein Ziel zu erreichen. Ein Beispiel aus Dame: Einen Spielstein beschützen,
2
3
Vgl. Schell (2008), S. 133 ff.
Vgl. Schell (2008), S. 136
50
5 Konzeption
indem man einen anderen Spielstein hinter diesen Stein bewegt. Oder man zwingt einen
Gegner, einen ungewollten Sprung zu machen. Oder man opfert einen Spielstein, um den
Gegner auszutricksen. Diese resultierenden Aktionen sind oftmals nur unterschwellig vorhanden
und sehr strategisch, kennzeichnen aber laut vielen Game Designern ein gutes Spiel. Dies sind
Aktionen, die nicht Teil der Spielregeln an sich sind, sondern Aktionen und Strategien, die
völlig natürlich entstehen, wenn das Spiel gespielt wird.4
Regeln (Rules)
Die Regeln sind die grundlegendsten Elemente eines Spiels. Sie definieren den Raum, die
Objekte, die Aktionen, die Konsequenzen und Grenzen der Aktionen und die Ziele. In anderen
Worten ermöglichen sie all die Spielemechanik, die bis jetzt aufgeführt worden ist.5
Fertigkeit (Skill)
Das Element der Fertigkeit setzt den Fokus vom Spiel auf den Spieler. Jedes Spiel erfordert
von den Spielern, bestimmte Fertigkeiten zu trainieren. Wenn die Schwierigkeit des Spiels
den Fertigkeiten des Spielers entspricht, bleibt der Spieler herausgefordert und motiviert. Die
meisten Spiele erfordern nicht nur eine Fertigkeit von einem Spieler, sondern mehrere. Dabei
kann man die Fertigkeiten in verschiedene Kategorien unterteilen, wie zum Beispiel physische
Fertigkeiten wie etwa Stärke, Ausdauer und Koordination beim Sport. Dazu könnte man auch
die Manipulation eines Spielecontrollers zählen. Weiterhin gibt es mentale Fertigkeiten wie
Gedächtnis, Beobachtung und die Fähigkeit, Puzzles zu lösen. Zur letzten Kategorie gehören
soziale Fertigkeiten wie Täuschung des Gegners und Kommunikation. Poker ist beispielsweise
ein Spiel, das die sozialen Fertigkeiten fordert.6
Zufall (Chance)
Zufall ist ein wichtiger Bestandteil eines guten Spiels, denn Zufall bedeutet Ungewissheit und
Ungewissheit bedeutet Überraschungen.7
4
Vgl.
Vgl.
6
Vgl.
7
Vgl.
5
Schell
Schell
Schell
Schell
(2008),
(2008),
(2008),
(2008),
S.
S.
S.
S.
140 f.
144
151
153 f.
51
5 Konzeption
5.1.2 Übertragung auf das eigene Spielkonzept
Die zuvor genannten Punkte der Spielemechanik werden bei der Konzeption des Spiels berücksichtigt. Der Raum, in dem das Spiel in diesem Fall stattfindet, ist eine dreidimensionale
festgelegte Strecke. Der Spieler kann die Strecke nicht verlassen, sondern sich nur innerhalb
eines bestimmten Bereiches bewegen. Dabei spielen lediglich die x-Achse und die z-Achse eine
Rolle. Der Spieler kann sich weder auf noch ab bewegen. Die Steuerung findet somit auf einer
zweidimensionalen Ebene statt. Innerhalb der Spielwelt gibt es den Charakter des Spielers,
das Spielerobjekt. Außerdem existieren hier statische und sich bewegende Hindernisse, sowie
aufsammelbare Objekte. Diese haben Eigenschaften wie Farbe, Texturen, Geschwindigkeit
(insofern sie sich bewegen), Position und entsprechende Beschaffenheiten. Die Basisaktionen
des Spielers umfassen die Steuerung des Spielerobjektes nach links oder rechts über die
Pfeiltasten und die Manipulation des Spielerobjektes über eine Matrix. Der Spieler kann
dadurch Hindernissen ausweichen. Er bewegt sich während des Spiels automatisch vorwärts.
Darüber hinaus kann der Spieler über bestimmte Tasten Menüs aufrufen und Informationen
über die Levels abrufen.
Einige Regeln wurden zuvor bereits genannt. Der Spieler kann sich nicht selbstständig vorwärts
oder auf und ab bewegen. Das Verlassen des Spielfelds ist ebenfalls nicht möglich. Prallt der
Spieler mit Hindernissen zusammen, so verliert er an Energie. Hat er alle Energie verloren, so
verliert er ein Leben. Sind wiederum alle Leben aufgebraucht, endet das Spiel. Der Spieler hat
dabei die Möglichkeit, über aufsammelbare Objekte seine Fähigkeiten zu beeinflussen, negativ
sowie positiv. Er erkennt dabei anhand der Farbe der Objekte, ob sie positive oder negative
Auswirkungen haben. Die Auswirkungen selbst erkennt der Spieler nicht, was den Aspekt des
Zufalls anspricht. Durch das Sammeln erhält er außerdem Punkte, welche die Motivation
steigern sollen. Die wichtigste Fertigkeit im Spiel ist das Reaktionsvermögen und die Geschicklichkeit des Spielers. Es gilt, den Hindernissen auszuweichen, dabei die Objekte aufzusammeln
und ohne Kollision durch das Level zu kommen. Dabei muss man vorausschauend denken
und einschätzen können, wann eine Aktion zu Verlust von Energie führen könnte. Hierfür
gibt es auch verschiedene Schwierigkeitsgrade, damit die Herausforderung an die Fähigkeiten
des Spielers angepasst werden kann. Außerdem wird der Spieler über mentale Elemente, wie
beispielsweise die Eingabe einer Transformationsmatrix, gefordert. Soziale Fertigkeiten werden
bisher nicht benötigt. Der Zweispielermodus ist in der ersten Variante der Anwendung zwar
angedacht, aber noch nicht integriert.
Weiterhin werden bereits im Voraus Spezifikationen bezüglich der grafischen Darstellung, wie
52
5 Konzeption
zum Beispiel die Verwendung von fortgeschrittenen Effekten wie Bump Mapping und Shadern
festgelegt, sowie eine simple Rahmengeschichte für das Spiel erdacht.
5.2 Anforderungen
Die Anforderungen werden aus dem zuvor beschriebenen Konzept des Spiels unter der Berücksichtigung der Lehre der Computer Grafik erhoben. Hierfür wird ein Pflichtenheft nach Helmut
Balzert angefertigt, welches die Zielbestimmung, den Produkteinsatz, die Produktumgebung,
die Produktfunktionen, die Produktdaten, die Benutzungsoberfläche, Qualitätszielbestimmungen, globale Testszenarien, Anforderungen an die Entwicklungsumgebung und andere
erwähnenswerte Ergänzungen näher beschreibt. Das Pflichtenheft wird separat mit dieser
Arbeit abgegeben.
5.2.1 Zielbestimmung und Einsatz der Anwendung
Die Anwendung, die im Rahmen dieser Thesis entwickelt werden soll, dient als Basis für ein
Programm, das zur Lehre der Computer Grafik eingesetzt werden kann. Darüber hinaus sollen
mit der Anwendung die Fähigkeiten von OGRE aufgezeigt werden. Dabei richtet sich die
Anwendung an zwei Zielgruppen. Zum einen sollen Studenten, die an der Vorlesung Computer
Grafik der Hochschule Reutlingen teilnehmen, die Theorie praktisch und spielerisch erlernen
können. Zum anderen soll es Professoren damit ermöglicht werden, die Lehre zu unterstützen.
Beispielsweise könnte die Anwendung zur Prüfungsvorbereitung oder aktiv in der Vorlesung
verwendet werden. Für den sinnvollen Gebrauch der Anwendung sollten Kenntnisse über das
Gebiet der Computer Grafik bereits vorhanden sein. Das Spiel kann die vollständige Lehre
nicht ersetzen, es benötigt begleitende Didaktik durch einen Lehrer.
Die Anwendung würde dabei auf den privaten Computern beziehungsweise auf den Computern
im Multimediaraum der Hochschule Reutlingen und auf dem Computer des Professors
verwendet werden. Daher lässt sich auch keine tägliche Betriebszeit festlegen, die Anwendung
bedarf auch keiner speziellen Beobachtung. Gewartet werden muss die Anwendung insofern,
dass mit der Zeit neue Funktionen hinzugefügt werden können.
53
5 Konzeption
Musskriterien
Es soll ein Spielerobjekt durch eine vorgegebene Umgebung gesteuert werden. Mit dem
Spielerobjekt sollen Objekte aufgesammelt und Hindernissen ausgewichen werden. Dabei wird
eine Kamera aus Sicht der dritten Person verwendet. Die Spielumgebungen werden hierbei
in Levels eingeteilt. Zusätzlich zu diesen Anforderungen sollen Ansätze integriert werden,
anhand von denen die Theorie der Computer Grafik spielerisch und praktisch beigebracht
werden kann. Außerdem soll alles über eine grafische Benutzeroberfläche bedienbar sein.
Wunschkriterien
Zu den gewünschten Anforderungen zählt die Verwendung einer Nintendo WiiMote zur
Steuerung des Spielerobjektes, die Verwendung einer Kamera aus der ersten Person und eine
Kollisionserkennung, mit der die Kollision zwischen den Objekten festgestellt werden soll.
Weiterhin sollen eigene 3D-Objekte mit Hilfe eines Modellierungswerkzeuges erstellt und im
Spiel verwendet werden. Als weitere Wunschkriterien werden ein Soundsystem zum Abspielen
von Audiodateien, die Führung einer Punkteliste (Highscore), die Verwendung von Animationen, die Verwendung eines Physiksystems für die realistische Darstellung physikalischer
Abläufe und ein Zweispielermodus festgehalten.
Es sei nochmals erwähnt, dass der Fokus der Anwendung auf einer Demonstration der
Fähigkeiten von OGRE und der Lehre von Computer Grafik liegt. Daher wird auch nicht
die Entwicklung eines hochwertigen Spiels angestrebt. Dies bezeichnet man als sogenanntes
Abgrenzungskriterium.
5.2.2 Produktumgebung
Aus der Zielbestimmung und dem Einsatz der Anwendung lassen sich die Anforderungen für
die Produktumgebung ableiten.
Software
Da von den Professoren und den Studenten und auch im Multimediaraum vorwiegend Windows verwendet wird, wird als Hauptbetriebssystem Windows (XP, Vista) angestrebt. Da
aber ein möglichst großer Personenkreis die Anwendung verwenden können soll, werden auch
Nutzer von Linux und Mac OS X berücksichtigt. OGRE kapselt den Zugriff auf die darun-
54
5 Konzeption
terliegende Grafikhardware, daher ist es möglich, die Anwendung auch plattformunabhängig
bereitzustellen.
Hardware
Um die Anwendung verwenden zu können, wird ein Computer mit einer Grafikkarte benötigt.
OGRE stellt keinen Software Renderer zur Verfügung, der die Berechnung auf der CPU
vornehmen würde. Da auch fortgeschrittene Gebiete der Computer Grafik behandelt werden,
sollte eine Grafikkarte der neueren Generation vorhanden sein, die den Umgang mit Shadern vorzugsweise Shader Model 3.0 - beherrscht.
5.2.3 Qualitätszielbestimmungen
Besonderes Augenmerk bei den Qualitätszielbestimmungen - oft auch als nichtfunktionale
Anforderungen bezeichnet - liegt auf der Korrektheit, der Zuverlässigkeit, der Erweiterbarkeit
und der Portierbarkeit der Anwendung. Die Korrekheit beschreibt dabei die Fehlerfreiheit
der Ergebnisse. Angenommen bei der Eingabe der Werte für eine Transformationsmatrix
würden korrekte Werte eingetragen, aber das Ergebnis der Transformation des Objektes wäre
inkorrekt. Dies hätte zur Folge, dass falsche Kenntnisse daraus gezogen würden. Es wird
dabei auch angestrebt, die Anwendung und damit verbunden die Funktionen so zuverlässig
und robust wie möglich umzusetzen. Das bedeutet, dass bei Fehleingaben die Anwendung
weder abstürzt noch durch andere Handlungen seitens des Anwenders infunktional gemacht
werden kann. Es bedeutet, dass die Anwendung auch unter ungünstigen Bedingungen gut
läuft. Ein weiterer wichtiger Punkt ist die Erweiterbarkeit der Anwendung. Mit dieser Arbeit
wird nur die Grundlage einer Anwendung für die Lehre geschaffen. Auch in Zukunft soll es
möglich sein, die Anwendung zu erweitern und sie um neue Ansätze für die Lehre und andere
Funktionen zu ergänzen. Die Portierbarkeit der Anwendung bezieht sich auf die Fähigkeit der
Anwendung, auf verschiedenen Computersystemen lauffähig zu sein.
Weniger Bedeutung wird hierbei der Effizienz der Anwendung zugemessen. Dies umfasst
die Sparsamkeit der Anwendung bezüglich der Ressourcen, was unter anderem durch gute
Algorithmen und einen guten Programmierstil erreicht wird. Dies könnte bei einem Redesign
der Anwendung vermehrt berücksichtigt werden.
55
5 Konzeption
5.2.4 Weitere Teile des Pflichtenheftes
Das Pflichtenheft enthält bereits die grundlegende Dialogstruktur der interaktiven Benutzeroberfläche und eine genauere Beschreibung der Produktfunktionen. Weiterhin enthält es
einige Testszenarien und Testfälle, deren Erfüllung ein Muss für die korrekte Funktionalität der
Anwendung darstellt. Die Speicherung der Produktdaten lässt sich ebenfalls dem Pflichtenheft
entnehmen. Diese umfasst die Konfiguration des Spiels und die Speicherung der Punktzahl
des Spielers in einer Konfigurationsdatei bzw. in einer Datenbank. Diese Abschnitte sind
selbsterklärend und lassen sich dem dieser Arbeit beigefügten Pflichtenheft entnehmen.
5.3 Architektur
Aus den zuvor genannten Anforderungen und der Konzeption des Spiels kann nun die
Architektur der Anwendung abgeleitet werden, die in Abbildung 5.1 zu sehen ist.
Die Anwendung wird nach objektorientierten Maßstäben konzipiert. Dabei wird auf die Verwendung eines Frameworks zurückgegriffen. Die Idee hierfür stammt aus einem Beispielprogramm
aus dem Wiki von OGRE. Das Framework eignet sich perfekt für die Lehre, da einzelne
Programmfunktionen selbstständig ersetzt werden können, ähnlich wie es Ganovelli und Corsini
(2009) gezeigt haben. Darüber hinaus ist durch die objektorientierte Herangehensweise und
das Framework auch die Erweiterbarkeit garantiert, da neue Programmelemente problemlos
hinzugefügt werden können.
Die Klasse OgreApplication stellt hierbei das Framework dar. In dieser Klasse werden alle
OGRE spezifischen Variablen erstellt und initialisiert, die auch in anderen Anwendungen
basierend auf OGRE wiederverwendet werden können. Von dieser erbt die Klasse Game und
übernimmt damit die entsprechenden Methoden und Attribute. Die Klasse Menu verwaltet
alle mit der Benutzeroberfläche zusammenhängenden Elemente, wie beispielsweise die im
Pflichtenheft beschriebene Menüstruktur. Die Klasse Sound initialisiert und verwaltet die
Audiodateien, die im Spiel verwendet werden. GameObject stellt eine abstrakte Klasse dar
und enthält entsprechende Funktionen zum Hinzufügen, Positionieren und Löschen von
Objekten. Von dieser Klasse erben dann die Klassen Player, Object und Enemy. Diese
Klassen spezifizieren wiederum weitere, je nach Klasse benötigte Funktionen. Die Klasse
Level repräsentiert jeweils ein Level des Spiels und ermöglicht das Laden und Entladen der
56
5 Konzeption
Levels. Über die Klasse Game werden die Komponenten zusammengefügt und kommunizieren
miteinander. Die Klasse Game enthält dabei auch die Logik des Spiels und verwaltet Spieler,
sowie Gegner und Hindernisse. Außerdem wird hier die Kollisionserkennung zwischen diesen
Objekten vorgenommen.
Es sei bereits vorab darauf hingewiesen, dass sich diese Architektur im späteren Verlauf nicht
vollständig bewährt hat. Die Unterschiede zwischen der konzipierten und der tatsächlich
umgesetzten Architektur werden im kommenden Kapitel genauer erläutert.
Abb. 5.1: Konzipiertes Klassendiagramm der Architektur
57
6 Implementierung
In diesem Kapitel wird zunächst auf die Grundlagen der Implementierung eingegangen. Im
Anschluss werden Struktur und Aufbau der mit OGRE entwickelten Anwendung genauer
untersucht und erläutert. Dabei wird anhand einiger ausgewählter exemplarischer Codebeispiele
die Funktionsweise der Anwendung demonstriert. Auf die Implementierung der Ansätze für
die Lehre wird gesondert eingegangen. Am Ende des Kapitels werden die Probleme und deren
Lösungen betrachtet, die während der Entwicklung der Anwendung auftraten.
6.1 Grundlagen
Für OGRE existieren diverse Wrapper für Programmiersprachen. Dadurch ist es möglich, OGRE
Anwendungen mit Hilfe von Programmiersprachen wie Java, C# oder Python zu erstellen.1
Für diese Arbeit wurde auf die ursprüngliche Kernsprache von OGRE zurückgegriffen: C++.
Diese Programmiersprache ist am besten dokumentiert und es gibt ausreichend Beispiele. Als
Entwicklungsumgebung wurde Eclipse 3.5.0 „Galileo“ verwendet. Für die Entwicklung von
OGRE können viele verschiedene Entwicklungsumgebungen genutzt werden. Zum Zeitpunkt
der Implementierung war das OGRE SDK in der Version 1.6.3, Codename „Shoggoth“ die
aktuelle Version. Während der Arbeit erschien die Version 1.6.5 „Shoggoth“ von OGRE,
die verschiedene Fehler behebt. Die Entwicklung der Anwendung fand hauptsächlich auf
Linux statt, daher wurde als Schnittstelle vorwiegend OpenGL verwendet. Zum Testen der
Plattformunabhängigkeit und des Quellcodes wurde zusätzlich unter Windows XP mit Hilfe
von Visual Studio 2008 getestet und entwickelt.
1
Vgl. Junker (2006), S. 253 f.
58
6 Implementierung
6.2 Struktur und Aufbau
Die Architektur der finalen Anwendung unterscheidet sich in mancher Hinsicht von der im
Konzept aus Abschnitt 5.3 auf Seite 56 beschriebenen Architektur. Im Konzept wird mit
abstrakten Klassen für das Spielerobjekt, für aufsammelbare Objekte und für die gegnerischen
Objekte gearbeitet. Dies wurde in der finalen Anwendung aus Zeitgründen nicht mehr
umgesetzt. Es war ursprünglich nur eine gemeinsame Klasse Enemy für gegnerische Objekte
sowie Hindernisse angedacht. Während der Umsetzung ergab sich anlässlich einer besseren
Verwaltung der Objekte eine Aufteilung in eine Klasse SceneryObject für Hindernisse und
Elemente des Levels, die statisch sind. Zusätzlich wurden die Klassen AnimatedEnemy für
animierte bewegliche Feinde und SimpleEnemy für nicht animierte bewegliche Feinde angelegt.
Diese Klassen sollten in der konzipierten Architektur von der Klasse Game verwaltet werden.
Während der Umsetzung ergab sich hier allerdings sinnvollerweise eine Auslagerung dieser
Klassen in die Level Klasse, da sie eindeutig feste Bestandteile eines jeden Levels sind.
Weiterhin wurde die Klasse GameOverlay nachträglich eingefügt, um die Elemente des mit
OGRE erstellten Overlay-Systems zu verwalten. Aus dem Konzept nicht ersichtlich, aber
ursprünglich angedacht war, dass die Klasse Level jeweils ein Level des Spiels repräsentiert.
Auch hier wurde aus Zeitgründen anders verfahren. Die Klasse Level enthält nun alle Levels
„hard gecoded“ und verwaltet das Laden und Löschen dieser Levels. Zusätzlich übernimmt sie
die Kollisionserkennung mit den Hindernissen, Gegnern und aufsammelbaren Objekten und
verwaltet diese.
59
6 Implementierung
Abb. 6.1: Finales Klassendiagramm der Architektur der Anwendung
6.2.1 Klassen
Dieser Abschnitt geht kurz auf den allgemeinen Aufbau einer OGRE Anwendung ein. Anschließend werden die implementierten Klassen und ihre Funktionen beschrieben.
In einer grundlegend minimalen OGRE Anwendung, die in einem Fenster läuft und über einen
Konfigurationsdialog eingestellt werden kann, wird zunächst das sogenannte Root Objekt von
OGRE instanziiert. Über dieses Objekt erhält man Zugriff auf das Render Fenster, in der die
Anwendung letztendlich dargestellt wird.
60
6 Implementierung
Algorithmus 6.1 Eine minimale OGRE Anwendung
// Instanziieren des Root Objektes
Root *root = new Root();
// Anzeigen des Konfigurationsdialoges
root->showConfigDialog();
// Initialisierung des Root Objektes
root->initialise(true, “Mein Render Fenster“);
// Erstellen eines Render Fensters mit automatischen Werten
RenderWindow *window = root->getAutoCreatedWindow();
// Starten des Renderns
root->startRendering();
In dieser Anwendung, gezeigt in Algorithmus 6.1, wird allerdings noch nichts dargestellt. Soll
etwas dargestellt werden, so wird ein Szenenmanager, ein Viewport und eine Kamera benötigt.
Den Zugriff auf den Szenenmanager erhält man wiederum über das Root Objekt. Die Kamera
erhält man anschließend über den Szenenmanager und den Viewport über das Render Fenster.
Dies wird in Algorithmus 6.2 dargestellt.
Algorithmus 6.2 Erstellung von Szenenmanager, Camera und Viewport
// Erstellung des Szenenmanagers
SceneManager* sceneManager = root>createSceneManager(ST_GENERIC, “Mein SzenenManager“);
// Erstellung einer Camera
Camera* camera = sceneManager->createCamera(“HauptCamera“);
camera->setAspectRatio(1.33333f);
camera->setFOVy(30.0f)
// Erstellung des Viewports
Viewport* viewPort = window->addViewport(camera);
In Abbildung 6.1 ist das Klassendiagramm der umgesetzten Anwendung abgebildet. Die
abstrakte Klasse OgreApplication ist ein Framework und erbt von der OGRE spezifischen
Klasse FrameListener und den beiden OIS Klassen KeyListener und MouseListener, die für
Benutzereingaben benötigt werden. Ein Framework ist eine teilweise aufgebaute Anwendung.
Der Entwickler ergänzt hierbei die Anwendung, indem er eine eigene Implementierung für
die fehlende Funktionalität innerhalb des Frameworks bereitstellt oder das vorgegebene Verhalten überschreibt.2 Dies wird an dieser Stelle mit virtuellen Funktionen in C++ realisiert.
2
61
6 Implementierung
Diese Funktionen können grundlegend implementiert und in einer abgeleiteten Klasse vervollständigt oder überschrieben werden. Die Klasse OgreApplication kümmert sich um die
Initialisierung des OGRE Root Objektes und der OIS Benutzereingaben. OgreApplication
liest die Ressourcen ein und initialisiert diese, erstellt den FrameListener, den Szenenmanager
und das Render Fenster und wandelt OIS MouseButtons in CEGUI MouseButtons um. Dies
sind grundlegende Tätigkeiten, die häufig in OGRE Anwendungen gemacht werden müssen
und somit wiederverwendet werden können. Aus diesem Grund wurden sie in diese Klasse
ausgelagert. Von dieser Klasse erbt die Klasse Game. Sie initialisiert und verwaltet alle mit
der Spielelogik zusammenhängenden Komponenten, wie etwa die Levels und das Spielerobjekt.
Hier werden auch die Objekte für das Menü, den Sound und das Overlay-System erstellt.
Darüber hinaus wird hier die Kamera erstellt und Benutzereingaben werden mit Hilfe von
OIS abgefangen und verarbeitet. Die Klassen Menu und GameOverlay sind für die grafische
Benutzeroberfläche verantwortlich. Die Klasse Menu regelt die mit CEGUI erstellten interaktiven Elemente der grafischen Benutzeroberfläche. Die Klasse GameOverlay kümmert sich
mit Hilfe des OGRE Overlay-Systems um die nicht interaktiven Elemente, wie zum Beispiel
die Anzeige der Punktzahl, Energie und Leben des Spielers und die aktuelle Position im
Koordinatensystem. Darüber hinaus werden über das Overlay-System Informationen zum
Level, die Levelnamen und bei Kollision mit Objekten eine Schadensanzeige eingeblendet. Die
Klasse Sound initialisiert die Audiobibliothek Audiere3 , mit deren Hilfe Audiodateien abgespielt
werden können. Außerdem verwaltet sie die im Spiel verwendeten Audiodateien und bietet
entsprechende Funktionen, um diese abzuspielen. Die im Spiel verwendeten Audiodateien
stammen hierbei von der Internetpräsenz Soundjay4 . Die Klasse Player repräsentiert einen
Spieler. Über die Klasse kann das Spielerobjekt unter anderem zur Szene hinzugefügt, bewegt,
skaliert, seine Geschwindigkeit beschleunigt oder vermindert und die Anzahl seiner Punkte
erhöht oder gesenkt gewerden. Ähnliche Funktionen bieten die Klassen SimpleEnemy, die
nicht animierte, sich bewegende Feinde repräsentiert und AnimatedEnemy, die animierte, sich
bewegende Feinde repräsentiert. Die Klasse Object stellt die Objekte im Level dar, die vom
Spieler aufgesammelt werden können. Innerhalb der Levels gibt es Hindernisse und Objekte,
welche die Landschaft zieren und denen ausgewichen werden muss. Diese werden durch die
Klasse SceneryObject repräsentiert.
Der Ansatz mit dem Framework und der grundlegende Code dafür stammen aus dem Wiki
3
4
http://audiere.sourceforge.net/
http://www.soundjay.com/
62
6 Implementierung
der Internetpräsenz von OGRE.5
Die Klassen Player, Object, SceneryObject, SimpleEnemy und AnimatedEnemy repräsentieren jeweils auch ein dreidimensionales Objekt, das an den Szenengraphen angehängt wird.
Dies geschieht über den Szenenmanager. Wie zuvor bereits erwähnt, wird der Szenenmanager
innerhalb der Klasse OgreApplication erstellt. Wie erhalten nun die Unterklassen wie etwa
Player Zugriff auf den Szenenmanager? Da die Klasse Game von der Klasse OgreApplication
erbt, erhält sie auch Zugriff auf das Objekt des Szenenmanagers. Dieses wird wiederum über
den Konstruktor an die jeweiligen Objekte übergeben, damit sie Zugriff auf den Szenenmanager erhalten und so beispielsweise die Objekte zur Szene hinzugefügt oder gelöscht werden
können. Ähnlich wird bei dem Render Fenster und der Klasse Menu verfahren. Das Render
Fenster wird über den Konstruktor an die Menu Klasse weitergegeben. Dieses wird von CEGUI
benötigt, um die Menüs darstellen zu können.
Es wurde zuvor bereits erwähnt, dass sogenannte „Scene Nodes“ an den Szenengraphen
angehängt werden. Jedes Scene Node hat dabei nur einen Vaterknoten und keinen oder
mehrere Kinderknoten. Dies ähnelt einer Baumstruktur. Im Fall dieser Anwendung werden
alle Scene Nodes an das Wurzel-Scene-Node angehängt. Die Hierarchie wird in Abbildung
6.2 exemplarisch dargestellt. Es wäre weiterhin sinnvoll, diese Scene Nodes an ein jeweiliges
Level-Scene-Node anzuhängen, um eine bessere Hierarchie zu gewährleisten.
Abb. 6.2: Die Szenengraphhierarchie der Anwendung
5
Vgl. OGRE (2010a)
63
6 Implementierung
Wie weiter oben erwähnt, verwaltet die Game Klasse die Spielelogik. Über die Methode
frameStarted des FrameListeners werden zu Beginn eines jeden dargestellten Frames Kollisionen abgefragt. Es wird geprüft, ob der Spieler beispielsweise die Pausetaste gedrückt und
somit den Pausemodus aktiviert hat oder ob das Hauptmenü geöffnet wurde. All dies wird mit
Hilfe boolescher Variablen gelöst. Wird die Pausetaste gedrückt, so wird die entsprechende
Variable auf true gesetzt. Mit Hilfe einer if-Abfrage wird dann die Ausführung der anderen
Funktionen in der Methode frameStarted verhindert. In dieser Methode wird auch geprüft,
ob der Spieler verloren hat oder sich an einer bestimmten Stelle im Level befindet und dort
die Geschwindigkeit erhöht wird. Es werden innerhalb der Methode die Feinde, der Spieler
sowie die Kamera bewegt und Infotexte angezeigt. Alles was sich dynamisch während des
Spiels ändert, wird in der Methode frameStarted behandelt.
Über die Game Klasse wird auch die Konfigurationsdatei des Spiels ausgelesen, die derzeit
Einstellungen zur Schwierigkeit und zur Sprache des Spiels enthält. Die Einstellungen für
Auflösung und Vollbild können noch nicht verwendet werden. Diese Konfigurationsdatei
wird mit Hilfe von GLib, einer Teilbibliothek des GTK+6 Projektes, realisiert. GTK+ war
ursprünglich ein grafischer Werkzeugsatz für Gnome und XFCE, die beiden populärsten Linux
Desktopumgebungen.7 GLib kann unabhängig von GTK+ verwendet werden und verfügt
über vielfältige Funktionen wie beispielsweise Bäume, Listen, Funktionen für das Dateisystem
oder eben die Möglichkeit, sogenannte „Key Files“ auszulesen.8 Diese sind vergleichbar
mit .ini Dateien in Windows. Die Daten werden in Gruppen aufgeteilt, wobei der Name in
eckigen Klammern auftaucht. Kommentare werden mit der Raute eingeleitet. Mit Hilfe von
GLib kann auf die Gruppen und die darin befindlichen Attribute zugegriffen werden. Der
Code hierfür stammt aus einem von anderen Studenten mit OGRE realisierten Projekt und
wurde entsprechend an die Anwendung angepasst.9 In Algorithmus 6.3 ist die verwendete
Konfigurationsdatei abgebildet.
6
http://www.gtk.org/
Vgl. Krause (2007), S. 2
8
Vgl. Krause (2007), S. 159
9
http://decoy.addictedtocreation.com/
7
64
6 Implementierung
Algorithmus 6.3 Konfigurationsdatei des Spiels
# This is the Settings file for DodgeHead
# It contains all necessary settings for the game
[Graphic]
Resolution=1024x768
Fullscreen=true
[Language]
#english=en, german=de
Language=en
[Gameplay]
#Easy=0, Medium=1, Hard=2
Difficulty=0
6.2.2 Implementierung der Ansätze für die Lehre
Die Theorie der Computer Grafik wird innerhalb der Anwendung über verschiedene Ansätze
vermittelt, die in diesem Abschnitt näher erläutert werden.
Levels
Die Levels orientieren sich an verschiedenen Themengebieten der Computer Grafik. Das erste
Level enthält die Basis und zeigt den Prozess der Rasterung und lehrt darüber hinaus grundlegende Bereiche der Computer Grafik. Das zweite Level behandelt Backface Culling, Clipping
und Farben sowie deren Interpolation. Das dritte Level führt Texturen ein, das vierte Level
enthält Beleuchtung und damit verbunden Shading und das fünfte Level beschäftigt sich mit
fortgeschrittenen Themen wie Bump Mapping und Shadern. Der Aufbau der Levels entspricht
somit weitestgehend dem an der Hochschule Reutlingen gelehrten Kurs der Computer Grafik.
Hierbei wurden die Themen in den Levels parallel zu den Folien des Kurses angeordnet. Die
Levels werden direkt im Code mit Hilfe von Objekten von OGRE realisiert. Die Hindernisse
im Level sind dabei von OGRE vorgegebene Modelle, die je nach Situation skaliert werden,
um sie beispielsweise breiter oder höher zu machen. Da die Levels direkt im Code erstellt
sind, muss jedes Objekt von Hand im dreidimensionalen Raum platziert werden. Hier wäre in
Zukunft die Verwendung eines Leveleditors ratsam.
65
6 Implementierung
Abb. 6.3: Lehre der Konzepte: Thematik der Levels (Level 1 bis Level 5 von links nach rechts)
Informationsfenster und Informationstext
Über einen Tastendruck ist es jederzeit möglich, während des Spiels Informationen abzurufen. Dabei wird das Spiel pausiert und ein Fenster mit Informationen eingeblendet. Diese
Informationen haben Bezug zum Level, in dem sich der Spieler aktuell befindet. Das erste
Level behandelt die Grundzüge der Computer Grafik, wie beispielsweise die Rasterung. Zu
diesem Thema werden dann im ersten Level Hintergrunddetails zum Verfahren und andere
damit verbundene Informationen über das Informationsfenster eingeblendet. Der Spieler erhält
damit ein tiefgehenderes Wissen über die Theorie, die hinter der praktischen Umsetzung
des Levels steht. Dieses Informationsfenster ist Teil der Klasse Menu und somit der mit
Hilfe von CEGUI erstellten Benutzeroberfläche. Die Texte befinden sich dabei getrennt nach
Levels in separaten XML Dateien. Je nach Levelnummer wird hier im Code über die Methode
showInfoScreen(infoScreen) der Klasse Menu das entsprechende Informationsfenster geladen
und angezeigt. Dabei wird in der Klasse Game abgefragt, welches Level aktuell geladen ist
und der Methode showInfoScreen übergeben.
Weiterhin wird an der linken Seite des Bildschirms über die Methode updateInfobox(infoText)
der Klasse GameOverlay ein Informationstext eingeblendet, der sich abhängig von der Position des Spielerobjektes im Level verändert. Diese Position wird innerhalb der Methode
frameStarted abgefragt. Hier können Informationen zu den verwendeten Techniken bezüglich
der Computer Grafik, aber auch allgemeine Hinweise zum Spiel eingeblendet werden.
66
6 Implementierung
Abb. 6.4: Lehre der Konzepte: Informationsfenster während des Spiels
Matrixmanipulation
Der Spieler erlernt die Theorie der Computer Grafik interaktiv. Das geschieht innerhalb des
Spiels unter anderem mit Hilfe eines Menüs, welches Eingabefelder in der Anordnung einer
4x4 Matrix beinhaltet. Hat der Spieler zu wenig Energie und steht kurz vor dem Verlust
des letzten Lebens, so erhält er die Möglichkeit über diese Matrix das Spielerobjekt zu
transformieren. Konkret kann das Spielerobjekt dadurch verschoben (Translationsmatrix)
und skaliert (Skalierungsmatrix) werden. Im letzten Level ist es beispielsweise notwendig,
das Spielerobjekt zu skalieren, um damit enge Passagen passieren zu können und somit
den Verlust von Energie zu vermeiden. Eine Matrix ist ein rechteckiges Array von m x n
Skalaren. Matrizen sind ein komfortabler Weg, um lineare Transformationen wie Translation,
Rotation und Skalierung darzustellen.10 Dabei wird die Matrix des Objektes nicht direkt
mit einer Transformationsmatrix multipliziert. Es werden die entsprechenden Werte aus der
eingegebenen Matrix extrahiert und an vordefinierte Funktionen von OGRE für Translation
und Skalierung weitergegeben. Intern rechnet OGRE nicht mit 4x4 Matrizen, daher ist eine
direkte Matrixmultiplikation nicht möglich. Auch dieses eben angesprochene Matrixmenü ist
ein Teil der Menu Klasse und wurde mit Hilfe von CEGUI erstellt. Über die Callback Funktion,
10
67
6 Implementierung
die an den „Bestätigen“-Button des Matrix Menüs gebunden ist, werden anschließend die im
Menü eingegebenen Werte der Matrix an das entsprechende Attribut mMatrix der Klasse
Menu übergeben. Wird der „Bestätigen“-Button nicht gedrückt, so laufen 30 Sekunden ab
und die Werte werden automatisch weitergegeben. Das Attribut mMatrix ist hierbei vom Typ
Matrix4. Dies ist ein von OGRE vorgegebener Typ. In der Klasse Game wird dieses Menü über
die Methode showMatrixMenu() aufgerufen, wenn der Spieler kurz vor dem Verlieren steht.
Anschließend werden die Werte der Matrix aus dem Menü an eine Methode des Spielerobjektes
namens transformByMatrix() übergeben.
Abb. 6.5: Lehre der Konzepte: Matrizenrechnung über das Matrixmenü
Materialsystem
Über OGREs Materialsystem ist es möglich, ohne erneutes Kompilieren der Anwendung
Änderungen an Farben, Texturen, Shadern oder Partikeln vorzunehmen. Dadurch kann man
einfach mit den Materialien experimentieren und anschließend die Ergebnisse in der Anwendung
betrachten. Die Farben lassen sich beispielsweise einfach abändern, dadurch kann mit den
ambienten, diffusen und spekularen Anteilen experimentiert werden. Bei den Texturen können
verschiedene Formen des Mappings getestet oder gar die gesamte Textur ausgetauscht werden.
Auch mit Partikeln kann experimentiert werden. Für die Anwendung werden beispielsweise
beim Aufsammeln von Objekten Partikel angezeigt, die mit OGREs Partikelsystem realisiert
werden. Hierbei wird auf vorgefertigte Partikelsysteme zurückgegriffen.
68
6 Implementierung
Shader
Shader sind ein fortgeschrittenes Gebiet der Computer Grafik. In Kapitel 2.1.2 auf Seite 7
wurde bereits erwähnt, dass es zwei verschiedene Arten von Shadern gibt, Vertex Shader und
Pixel Shader. Vertex Shader ermöglichen es, die Zeichnung basierend auf Vertex Attributen
wie Positionen, Normalen und Farben zu kontrollieren. Ein einfacher Vertex Shader könnte
beispielsweise ein dreieckiges Polygonnetz zeichnen, bei dem der Benutzer die Vertex Positionen
und die Farben selbst angibt. Pixel Shader ermöglichen es, die Zeichnung auf bildbasierten
Attributen vorzunehmen. Ein einfacher Pixel Shader könnte beispielsweise Vertex Positionen,
Texturkoordinaten und eine Textur (Bild) interpolieren und die finalen Pixel füllen, die zum
gezeichneten Objekt gehören. Das Schreiben von Shadern kann anspruchsvoller sein als die
Verwendung der „fixed-function pipeline“.11 Mit Hilfe von Shadern werden innerhalb der
Anwendung verschiedene Effekte realisiert, wie beispielsweise der Bloom-Effekt (Glüh-Effekt)
im fünften Level der Anwendung oder die Verzerrung der Sicht, wenn man ein schwarzes
Objekt aufsammelt. Diese Shader werden dabei wie zuvor erwähnt über das Materialsystem
von OGRE realisiert. Es wird hierbei auf vordefinierte Shader zurückgegriffen, sie wurden
nicht selbst geschrieben.
Texturieren
In einer frühen Version befindet sich ein weiterer Ansatz der Lehre, bei dem das Spielerobjekt
selbst mit Texturen versehen werden kann. Dadurch sollen die Verfahren des Texture Mappings
veranschaulicht werden. Über ein mit CEGUI angefertiges Menü kann der Spieler in der
aktuellen Version der Anwendung die Texturen des Spielerobjektes anpassen, beispielsweise
von den Augen, Zähnen, Ohrringen oder dem Körper. Dabei kann zunächst das Körperteil
und anschließend eine passende Textur ausgesucht werden. Um dies zu ermöglichen, wird dem
Menüobjekt bei der Erstellung ein Zeiger auf das Spielerobjekt übergeben. Wird ein Körperteil
und anschließend eine Textur ausgesucht, so wird über eine Callback Funktion die Methode
activateTexture(itemTexture, itemTextureSubEntity) des Spielerobjektes aufgerufen. Dabei
wird der Methode die Nummer der Textur und die Nummer des Subentitys übergeben. Über
eine switch-Anweisung kombiniert mit einer if-Anweisung wird dann abgefragt, um welches
Körperteil es sich handelt und welche Textur darauf angewendet werden soll.
11
Vgl. Eberly, 2005, S. 149 f.
69
6 Implementierung
Abb. 6.6: Lehre der Konzepte: Selbstständiges Texturieren
Grafische Benutzeroberfläche und Mehrsprachigkeit
Für die grafische Benutzeroberfläche des Spiels wurde zum einen CEGUI und zum anderen das
Overlay-System von OGRE verwendet. CEGUI ist eine Abkürzung und steht für Crazy Eddie’s
GUI System. Dabei wurden für die entsprechenden interaktiven grafischen Menüfenster, die mit
Hilfe von CEGUI erstellt wurden, sogenannte Layout-Dateien angelegt. Diese Layout-Dateien
enthalten XML Code, der den Aufbau eines Fensters beschreibt. CEGUI ist in der Lage,
diese XML Dateien zu parsen und die entsprechenden Oberflächen zu konstruieren. CEGUI
beherrscht viele Elemente wie scrollbare Bereiche, Checkboxen, Dropdown Comboboxen
und viele andere. Wird hier ein Knopf gedrückt oder eine Combobox verwendet, so lassen
sich über sogenannte Callback Funktionen anschließend bestimmte Ereignisse auslösen, wie
beispielsweise das Schließen des aktuellen und das Öffnen eines neuen Menüs.
Für nicht interaktive Elemente der grafischen Benutzeroberfläche wurde das Overlay-System
von OGRE verwendet. Ein Overlay (dt. Überlagerung) überlagert, wie aus dem Namen bereits
ersichtlich, alle anderen Elemente in einer Szene.12 Hiermit werden die Punktzahl, die Energie,
die Leben und die Position des Spielers dargestellt. Wenn der Spieler mit einem Objekt
kollidiert, werden am Bildschirmrand vier rote Quadrate eingeblendet, die den Benutzer über
12
Vgl. Junker (2006), S. 227
70
6 Implementierung
einen Zusammenstoß informieren. Der Informationstext an der linken Seite des Bildschirms
wurde ebenfalls als Overlay realisiert. Über entsprechende Methoden wie showOverlay(),
hideOverlay() und updateOverlay() lassen sich die Overlay-Elemente einblenden, verbergen
oder aktualisieren. Die Codegrundlage für die Overlay-Dateien stammt aus dem Kapitel über
OGRE Programmierung aus Deitel (2007).
Zudem ist es aufgrund der im Abschnitt 6.2.1 erwähnten Konfigurationsdatei möglich, das
Spiel in mehreren Sprachen zu spielen. Wie bereits erwähnt, basieren die Layout-Dateien
auf dem XML Format. Dadurch ist es möglich, für jede Sprache eine andere XML Datei zur
Verfügung zu stellen. Dabei haben die Dateien für die englische Sprachversion beispielsweise
den Namen „menuname_en.layout“. Das Kürzel „en“ steht dabei für Englisch. Wird nun in
der Konfigurationsdatei Englisch als Sprache angegeben, wird beim Laden der XML Dateien
der Name der Layout Datei, wie beispielsweise „menuname_“ mit dem Kürzel „en“ aus der
Konfigurationsdatei und dem Dateiende „.layout“ konkateniert. Dadurch werden immer die in
der Konfigurationsdatei angegebenen Sprachdateien geladen.
Abb. 6.7: Grafische Benutzeroberfläche: Das Hauptmenü
71
6 Implementierung
6.3 Probleme und Lösungen bei der Implementierung
Während der Implementierung traten Probleme verschiedener Art auf. Diese galt es, durch
bestimmte Herangehensweisen und Methoden zu lösen. Dieser Abschnitt geht auf die Probleme
ein und erläutert die entsprechenden Lösungsansätze.
6.3.1 Kollisionserkennung
Für die Umsetzung von Kollisionserkennung existieren keine repräsentativen, aussagekräftigen
Beispiele in der Dokumentation und der Literatur von OGRE, die die Verwendung einer
herkömmlichen Methode der Kollisionserkennung erklären. Daher wurde selbst eine simple
Kollisionserkennung implementiert. Zwar wird das Spiel dreidimensional dargestellt, jedoch
spielt die y-Achse keine Rolle in der Logik des Spiels. Die Kollision mit den Objekten
spielt sich ausschließlich auf der x-Achse und der z-Achse ab. Hierbei wurde mit der Axis
Aligned Bounding Box (AABB) der jeweiligen Objekte (Entitys) gearbeitet. Eine Axis Aligned
Bounding Box ist eine einfache, sechsseitige Box, bei der jede Seite parallel zu einer der
Hauptebenen (engl. cardinal planes) steht.13 Hierbei wird berechnet, ob sich der maximale
bzw. minimale x-Wert der AABB des Spielers - ausgehend von der aktuellen x-Position des
Spielerobjektes - im Bereich der AABB eines anderen Objektes befindet. Selbiges gilt für
den z-Wert der AABB des Spielerobjektes. Problematisch ist hierbei, dass die AABB einen
größeren Bereich abdeckt, als die Objekte eigentlich einnehmen. Dadurch kommt es bereits
zu Kollisionen, wenn sich die sichtbaren Teile der Objekte gar nicht berühren. Aufgrund dieser
Tatsache werden bei der Abfrage einige Einheiten abgezogen, damit die Kollisionserkennung
etwas toleranter wird.
13
Vgl. Dunn und Parberry (2002), S. 248
72
6 Implementierung
Abb. 6.8: Kollisionserkennung: Axis Aligned Bounding Box
Algorithmus 6.4 Kollisionserkennung zwischen Spieler und Hindernissen
/∗ Wenn s i c h d e r ä u ß e r s t e Punkt d e r Bounding Box d e s S p i e l e r s i n
p o s i t i v e r s o w i e n e g a t i v e r x−R i c h t u n g ( a u s g e h e n d von d e r a k t u e l l e n
S p i e l e r p o s i t i o n a u f d e r x−Achse ) i n n e r h a l b d e s B e r e i c h e s d e r
Bounding Box d e s H i n d e r n i s s e s b e f i n d e t . . . ∗/
i f ( ( p l a y e r −>g e t P o s i t i o n ( ) . x + ( p l a y e r −>getAABB ( ) . getMaximum ( ) . x − 1 5 )
>= m S c e n e r y O b j e c t I t e r a t o r −>g e t P o s i t i o n ( ) . x − (
m S c e n e r y O b j e c t I t e r a t o r −>getAABB ( ) . getMaximum ( ) . x ) ) && ( p l a y e r −>
g e t P o s i t i o n ( ) . x − ( p l a y e r −>getAABB ( ) . getMaximum ( ) . x − 1 5 ) <=
m S c e n e r y O b j e c t I t e r a t o r −>g e t P o s i t i o n ( ) . x + ( m S c e n e r y O b j e c t I t e r a t o r
−>getAABB ( ) . getMaximum ( ) . x ) ) ) {
/∗ . . .
s e l b i g e s f ü r d i e z−Achse p r ü f e n ∗/
i f ( ( p l a y e r −>g e t P o s i t i o n ( ) . z − ( p l a y e r −>getAABB ( ) . getMaximum ( ) . z −
1 5 ) <= m S c e n e r y O b j e c t I t e r a t o r −>g e t P o s i t i o n ( ) . z + (
m S c e n e r y O b j e c t I t e r a t o r −>getAABB ( ) . getMaximum ( ) . z ) ) && ( p l a y e r −>
g e t P o s i t i o n ( ) . z + ( p l a y e r −>getAABB ( ) . getMaximum ( ) . z − 1 5 ) >=
m S c e n e r y O b j e c t I t e r a t o r −>g e t P o s i t i o n ( ) . z − (
m S c e n e r y O b j e c t I t e r a t o r −>getAABB ( ) . getMaximum ( ) . z ) ) ) {
/∗ K o l l i s i o n h a t s t a t t g e f u n d e n ∗/
return true ;
}
}
73
6 Implementierung
6.3.2 Laden und Entladen der Levels
Wie zuvor erwähnt, befinden sich die Levels „hard gecoded“ in der Level Klasse. Zu Beginn
der Entwicklung waren die Objekte für jeden Level, wie beispielsweise Hindernisse, Gegner und
aufsammelbare Objekte, in herkömmlichen Arrays gespeichert. Dies setzte allerdings voraus,
dass für jeden Level und für jeden Objekttyp ein eigenes Array mit einer festen Länge angelegt
werden musste. Im späteren Verlauf der Entwicklung fiel auf, dass die Levels dynamisch
zur Laufzeit geladen werden mussten. Beispielsweise, wenn etwa das nächste Level erreicht
wurde. Die naheliegende Lösung war hier, ein dynamisch befüllbares Array zu verwenden. C++
bietet hierfür die Standard Template Library (STL) an. Diese ist in der Standardbibliothek
von C++ enthalten und wurde von Hewlett Packard bzw. Alex Stepanov entwickelt. In
Form von Templates werden durch die STL Klassen für verschiedene Bereiche zur Verfügung
gestellt, unter anderem die Vector Klasse. Diese stellt arrayähnliche Listen für verschiedene
Datentypen bereit.14 Dadurch war es möglich, diese arrayähnlichen Listen zur Laufzeit zu
löschen und mit Levelobjekten zu befüllen. Mit Hilfe eines Iterators werden die Listen dann
durchlaufen und die einzelnen Objekte über die Methode addToScene() hinzugefügt. Werden
die Objekte gelöscht, so wird die Liste ebenfalls mit einem Iterator durchlaufen und jeweils die
Methode removeFromScene() aufgerufen. Auf diese Weise wird auch die zuvor beschriebene
Kollisionserkennung für einzelne Objekte durchgeführt.
6.3.3 Darstellung von Terrain
Zur detaillierteren grafischen Darstellung des Spiels wurde versucht, ein Terrain darzustellen,
welches die Levels umgeben sollte. Dies wurde mit Hilfe des Terrain Szenenmanagers von
OGRE und einer Heightmap gelöst. Leider ließ sich dabei die Position des Terrains nicht
verschieben, es wurde automatisch am Ursprung des Koordinatensystems in positiver Richtung
der z-Achse erstellt. Dadurch wäre es nötig gewesen, die bereits implementierten Teile des
Spiels so anzupassen, dass sie sich um das Terrain herum anordnen. Als Lösung wurde im
Forum von OGRE eine neue Version des Terrain Szenenmanagers gefunden, der sich zur Zeit
der Arbeit noch in einer frühen Version befand und Abhilfe für diese Probleme schaffen soll.
Bedauerlicherweise hätte hierfür eine unstabile Version von OGRE installiert werden müssen.
Zudem ist der neue Terrain Szenenmanager noch nicht dokumentiert und es existieren wenige
14
Vgl. Erlenkötter (2005), S. 271 f.
74
6 Implementierung
Beispiele. Letztendlich wurde die Darstellung von Terrain verworfen. Eine Alternative wäre
bei einer zukünftig geplanten Darstellung von Terrain die Erstellung eines Mesh-Objektes in
einem Modellierungswerkzeug wie 3dsmax mit Hilfe einer Heightmap. Diese könnte dann um
die Hauptstrecke der Levels herum angeordnet werden, so wie die anderen Objekte bisher
auch. Vor allem wenn keine Kollision mit diesem Terrain berechnet werden müsste, wäre diese
eine angemessene Lösung.
Gegen Ende der Arbeit wurde der erste Release Candidate der OGRE Version 1.7.0 veröffentlicht, der den neuen Terrain Szenenmanager enthält.15
15
Vgl. OGRE (2010b)
75
7.1 Fazit
In dieser Arbeit sollte untersucht werden, ob Game Engines für den Zweck der Lehre, speziell
für den Bereich der Computer Grafik, eingesetzt werden können. Im Verlauf der Arbeit wurde
der genaue Unterschied zwischen einer reinen Grafik Engine und einer Game Engine, sowie
deren Komponenten näher erläutert. Es wurden die unterschiedlichen Anwendungsgebiete von
Game Engines sowie einige populäre Beispiele dieser Engines aus dem kommerziellen sowie
quelloffenen Bereich aufgezeigt. Im weiteren Vorgehen wurde mit Hilfe selbst erarbeiteter
Kriterien und der Nutzwertanalyse systematisch eine geeignete Engine, in diesem Fall OGRE,
herausgearbeitet. Diese wurde anschließend anhand eines zuvor konzipierten Spiels demonstriert. Dabei wurde auch versucht, Ansätze für die Lehre der Theorie der Computer Grafik
zu schaffen. Mit Hilfe eines Fragebogens wurde eine genauere Evaluierung der Anwendung
vorgenommen, um positive Aspekte, Potentiale und Schwachstellen in Erfahrung zu bringen
sowie um zu prüfen, ob die Anwendung bereits eine sinnvolle Unterstützung für die Lehre
darstellt. Der Fragebogen hat dabei gezeigt, dass die Befragten bisher noch keinen Lerneffekt
erkennen können. Die Anwendung selbst ist noch nicht ausgereift genug, es mangelt an
spielerischer Interaktion zum Erlernen der Theorie und sie leidet noch an Fehlern. Außerdem
ist das Spiel trotz verschiedener Schwierigkeitsgrade offenbar noch zu schwer und es mangelt
insgesamt an Abwechslung. Dabei sind sich drei der vier Befragten dennoch einig, dass das
spielerische Erlernen Sinn macht. Es ist allerdings anzumerken, dass die Befragten offenbar
nicht sehr viel Zeit in die Evaluierung investiert haben. Es lässt sich teilweise erkennen, dass
die Anwendung nur oberflächlich und flüchtig getestet wurde. Aus diesem Grund und aufgrund
der geringen Rückmeldung sind die Ergebnisse des Fragebogens daher kritisch zu betrachten.
Andere Arbeiten, wie beispielsweise Ganovelli und Corsini (2009) und Clua u. a. (2006) haben
jedoch bereits gezeigt, dass Studenten durch den praktischen und spielerischen Ansatz und
das personalisierte Lernen eine erhöhte Motivation zeigen.1 Aus diesen Erkenntnissen lässt
1
Vgl. Ganovelli und Corsini (2009), S. 2032
76
sich schließen, dass die Verwendung von Game Engines auch in der Lehre im Bereich der
Computer Grafik Sinn macht, auch wenn die entwickelte Anwendung den Zweck noch nicht
ausreichend erfüllt.
Die für diesen Zweck eingesetzte Engine, OGRE, hat sich abschließend betrachtet als gute
Wahl erwiesen. Die Verwendung der Engine war insgesamt einfach, es mangelte lediglich an der
praktischen Integration neuer Komponenten und die Einrichtung der Entwicklungsumgebung
war stellenweise mühevoll. Beispielsweise wurde während der Entwicklung versucht, eine
Physikengine zu integrieren, was aufgrund fehlender Abhängigkeiten in der Entwicklungsumgebung und Inkompatibilitäten zwischen verschiedenen Codebestandteilen aufgegeben wurde.
Zudem war die Erstellung der interaktiven Benutzeroberfläche mit CEGUI ebenfalls mühevoll
und wenig intuitiv. Ein weiterer Kritikpunkt ist die Abhängigkeit von vielen DLLs. Hinsichtlich
dieser Mängel würde es sich lohnen, die nächstbessere Engine Irrlicht als Alternative zu
prüfen. Möglicherweise ist hier die Integration neuer Bestandteile oder die Erstellung von
Benutzeroberflächen einfacher und intuitiver gehalten. Für die Verwendung in der Lehre ist
OGRE jedoch mehr als ausreichend.
7.2 Ausblick
Es ist geplant, die im Rahmen dieser Thesis entwickelte Anwendung im Kurs Computer
Grafik der Hochschule Reutlingen zu verwenden. Aller Wahrscheinlichkeit nach wird sie zur
Unterstützung in der Vorlesung und zur Prüfungsvorbereitung eingesetzt. Wie zuvor bereits
erwähnt, weist die Anwendung bisher noch einige Mängel auf und bedarf daher einer weiteren
Überarbeitung. Die Grundlagen für Erweiterbarkeit, Konfiguration, Mehrsprachigkeit und
einige Ansätze für die Lehre wurden gegeben. Hinsichtlich der Lehre der Computer Grafik
gilt es, weitere Ansätze zu implementieren, die das interaktive Erlernen ermöglichen. Als
weitere Möglichkeit wurde ein Quiz innerhalb der Anwendung angedacht, bei dem der Spieler
Fragen aus dem Bereich der Computer Grafik beantworten muss, um beispielsweise ein Level
zu beenden. Weiterhin ist bereits der Ansatz implementiert, eine eigene Texturierung des
Spielerobjektes vornehmen zu können. Hier sollte noch die Möglichkeit gegeben werden, die
verschiedenen Methoden des Texture Mappings verwenden zu können. Weiterhin könnten
interaktive Ansätze zum Erlernen von Beleuchtung integriert werden. Beispielsweise durch
die eigene Platzierung von Lichtquellen und die Festlegung der Art von jenen, wie etwa
77
Richtungslichter oder Punktlichtquellen. Zudem sollte die Schwierigkeit des Spiels und damit
verbunden die Geschwindigkeit gesenkt werden, damit sich die Anwender mehr auf das
Erlernen der Theorie konzentrieren können.
Abgesehen von der Einführung weiterer Elemente und der Beseitigung von Fehlern, sollte ein
Redesign einiger Komponenten der Anwendung in Betracht gezogen werden. Die Levelklasse
enthält beispielsweise alle Levels, sollte jedoch nur einen Level repräsentieren. Hinsichtlich der
Architektur könnten die im Konzept angedachten abstrakten Klassen umgesetzt werden. Ein
guter Ansatz wäre es, die Hierarchie des Szenengraphen zu verbessern und somit übersichtlicher
zu machen. Derzeit werden die Scene Nodes einfach an den Wurzelknoten des Szenengraphen
angehängt und nicht etwa nach Levels organisiert. Die Entwicklung oder Verwendung eines
Leveleditors wäre ebenfalls empfehlenswert, da sonst weitere Levels aufwändig von Hand
erstellt oder bearbeitet werden müssten. Abgesehen davon werden in der Anwendung bisher
noch keine Fehler abgefangen und verarbeitet. Da im Spiel auch fortgeschrittene Techniken
wie Shader verwendet werden, sollte eine Prüfung der Hardwarefähigkeiten vorgenommen
werden, damit das System bei ungenügender Hardware nicht einfach abstürzt.
Wurden alle Fehler beseitigt und weitere Ansätze zum Erlernen der Theorie integriert, sollte
eine erneute Prüfung der Anwendung vorgenommen werden. Wenn möglich mit direktem
Feedback in der Vorlesung Computer Grafik. Dies würde wahrscheinlich einen, wie in diesem
Fall, mangelhaft ausgefüllten Fragebogen verhindern. Außerdem könnte dadurch getestet
werden, ob das Spiel unter der begleitenden Didaktik eines Lehrers eine bessere Wirkung
erzielt.
78
[Adam 1996] Adam, Dietrich: Planung und Entscheidung - Modelle, Ziele, Methoden. 4.
Auflage. Gabler, Wiesbaden, 1996
[Brede 2005] Brede, Helmut: Grundzüge der öffentlichen Betriebswirtschaft. 2. Auflage.
Oldenbourg Wissenschaftsverlag, München, 2005
[Bundesverband Interaktive Unterhaltungssoftware 2009] Bundesverband Interaktive Unterhaltungssoftware: Marktzahlen Computer- und Videospiele - 1. Halbjahr 2009. 2009. – URL http://www.biu-online.de/fileadmin/user/dateien/
BIU-Marktzahlen_1._Halbjahr_2009.pdf. – [Online; Stand 08. Oktober 2009]
[Burd u. a. 2007] Burd, Bary ; Goulden, John ; Ladd, Brian ; Rogers, Michael ;
Stewart, Kris: Computer games in the classroom, or, how to get perfect attendance,
even at 8 AM. In: SIGCSE ’07: Proceedings of the 38th SIGCSE technical symposium on
Computer science education. New York, NY, USA : ACM, 2007, S. 496–496. – ISBN
1-59593-361-1
[Clua u. a. 2006] Clua, Esteban ; Feĳó, Bruno ; Rocca, Jason ; Schwartz, Jon ;
Graças, Maria das ; Perlin, Ken ; Tori, Romero ; Barnes, Tiffany: Game and
interactivity in computer science education. In: SIGGRAPH ’06: ACM SIGGRAPH 2006
Educators program. New York, NY, USA : ACM, 2006, S. 2. – ISBN 1-59593-364-6
[CryEngine 2 2009] CryEngine 2: Technology. 2009. – URL http://www.cryengine2.
com/index.php?pnr=1&conid=2. – [Online; Stand 06. Dezember 2009]
[Crystal Space 2009]
Crystal Space: Features. 2009. – URL http://www.
crystalspace3d.org/main/Features. – [Online; Stand 12. Dezember 2009]
[Crytek 2009]
Crytek:
Free Educational License for CryENGINE® 3.
2009.
–
URL http://www.crytek.com/news/news/?tx_ttnews[tt_news]=165&tx_
ttnews[backPid]=1&cHash=8966bc7019. – [Online; Stand 06. Dezember 2009]
[Deitel 2007] Deitel, Paul J.: C++ How to Program. 6. Auflage. Prentice Hall, New
Jersey, 2007
[Dunn und Parberry 2002] Dunn, Fletcher ; Parberry, Ian: 3D Math Primer for Graphics
and Game Development. Wordware Publishing, Plano, Texas, 2002
[Eberly 2005] Eberly, David H.: 3D Game Engine Architecture - Engineering Real-Time
Applications with Wild Magic. Morgan Kaufmann, San Francisco, 2005
79
[Erlenkötter 2005] Erlenkötter, Helmut ; Moos, Ludwig (Hrsg.): C++: Objektorientiertes Programmieren von Anfang an. 8. Auflage. Rowohlt Verlag, Reinbek, 2005
[Fritsch und Kada 2004] Fritsch, Dieter ; Kada, Martin: Visualisation Using Game
Engines. In: ISPRS Commission 5 (2004), S. 621–625
[Gamebryo 2009] Gamebryo: Gamebryo Gaming Engine. 2009. – URL http://www.
emergent.net/en/Products/Gamebryo/. – [Online; Stand 18. September 2009]
[Ganovelli und Corsini 2009] Ganovelli, Fabio ; Corsini, Massimiliano: eNVyMyCar: a
multi-player car racing game for teaching Computer Graphics. In: Computer Graphics Forum
28 (2009), dec, Nr. 8, S. 2025–2032. – URL http://vcg.isti.cnr.it/Publications/
2009/GC09
[Gregory 2009] Gregory, Jason ; Lander, Jeff (Hrsg.) ; Whiting, Matt (Hrsg.): Game
Engine Architecture. A K Peters Ltd., Natick, 2009
[Herrlich 2007] Herrlich, Marc: A Tool for Landscape Architecture Based on Computer
Game Technology. In: ICAT ’07: Proceedings of the 17th International Conference on
Artificial Reality and Telexistence. Washington, DC, USA : IEEE Computer Society, 2007,
S. 264–268. – ISBN 0-7695-3056-7
[ID Software 2009a]
ID Software: Internetpräsenz. 2009. – URL http://www.
idsoftware.com/business/idtech4/. – [Online; Stand 10. Oktober 2009]
[ID Software 2009b] ID Software: Technology Licensing. 2009. – URL http://www.
idsoftware.com/business/technology/. – [Online; Stand 18. September 2009]
[Irrlicht 2009] Irrlicht: Features. 2009. – URL http://irrlicht.sourceforge.net/
features.html. – [Online; Stand 18. September 2009]
[Jacobson und Lewis 2005] Jacobson, Jeffrey ; Lewis, Michael: Game Engine Virtual
Reality with CaveUT. In: Computer 38 (2005), Nr. 4, S. 79–82. – ISSN 0018-9162
[jMonkeyEngine 2009] jMonkeyEngine: About jMonkey. 2009. – URL http://www.
jmonkeyengine.com/wiki/doku.php?id=about_jme. – [Online; Stand 18. September
2009]
[Junker 2006]
Junker, Gregory: Pro OGRE 3D Programming. Apress, New York, 2006
[Kot u. a. 2005] Kot, Blazej ; Wuensche, Burkhard ; Grundy, John ; Hosking, John:
Information visualisation utilising 3D computer game engines case study: a source code
comprehension tool. In: CHINZ ’05: Proceedings of the 6th ACM SIGCHI New Zealand
chapter’s international conference on Computer-human interaction. New York, NY, USA :
ACM, 2005, S. 53–60. – ISBN 1-59593-036-1
[Krause 2007]
2007
Krause, Andrew: Foundations of GTK+ Development. Apress, New York,
80
[Lobao u. a. 2009] Lobao, Alexandre S. ; Evangelista, Bruno ; Leal De Farias,
Jose A. ; Grootjans, Riemer: Beginning XNA 3.0 - Game Programming From Novice
to Professional. Apress, New York, 2009
[Marinska 2010] Marinska, Silviya: Untersuchung von Serious Games-Methoden für die
Verwendung in der Informatik Ausbildung, Hochschule Reutlingen, Bachelor Thesis, 2010
[Marks u. a. 2007] Marks, Stefan ; Windsor, John ; Wünsche, Burkhard: Evaluation
of game engines for simulated surgical training. In: GRAPHITE ’07: Proceedings of the 5th
international conference on Computer graphics and interactive techniques in Australia and
Southeast Asia. New York, NY, USA : ACM, 2007, S. 273–280. – ISBN 978-1-59593-912-8
[Mól u. a. 2008] Mól, Antônio Carlos A. ; Jorge, Carlos Alexandre F. ; Couto, Pedro M.:
Using a Game Engine for VR Simulations in Evacuation Planning. In: IEEE Computer
Graphics and Applications 28 (2008), S. 6–12. – ISSN 0272-1716
[Nebula Device 2009] Nebula Device: What is the Nebula Device? 2009. – URL
http://nebuladevice.cubik.org/what-is-n2/. – [Online; Stand 18. September 2009]
[NxOgre 2009] NxOgre: What is it? 2009. – URL http://nxogre.org/what. – [Online;
Stand 11. Dezember 2009]
[Ogitor 2009] Ogitor: About. 2009. – URL http://www.ogitor.org/about/. –
[Online; Stand 05. Dezember 2009]
[OGRE 2009a] OGRE: CEGUI. 2009. – URL http://www.ogre3d.org/wiki/index.
php/CEGUI. – [Online; Stand 05. Dezember 2009]
[OGRE 2009b] OGRE: Documentation Architecture. 2009. – URL http://www.ogre3d.
org/wiki/index.php/Documentation_Architecture. – [Online; Stand 08. Dezember
2009]
[OGRE 2009c] OGRE: OgreAL. 2009. – URL http://www.ogre3d.org/wiki/index.
php/OgreAL. – [Online; Stand 05. Dezember 2009]
[OGRE 2009d] OGRE: OIS. 2009. – URL http://www.ogre3d.org/wiki/index.php/
OIS. – [Online; Stand 05. Dezember 2009]
[OGRE 2009e] OGRE: Team. 2009. – URL http://www.ogre3d.org/about/team. –
[Online; Stand 08. Dezember 2009]
[OGRE 2010a] OGRE: Example Framework Demystified. 2010. – URL http://www.
ogre3d.org/wiki/index.php/Example_Framework_Demystified. – [Online; Stand
06. Januar 2010]
[OGRE 2010b] OGRE: OGRE 1.7.0 RC1 [Cthugha] Released! 2010. – URL http://www.
ogre3d.org/2009/12/31/ogre-1-7-0-rc1-cthugha-released. – [Online; Stand 08.
Januar 2010]
81
[Open Dynamics Engine 2009] Open Dynamics Engine: User Guide. 2009. – URL
http://www.ode.org/ode-latest-userguide.html. – [Online; Stand 09. Dezember
2009]
[Panda3D 2009] Panda3D: Welcome to Panda3D. 2009. – URL http://www.panda3d.
org/. – [Online; Stand 18. September 2009]
[Schell 2008] Schell, Jesse: The Art of Game Design: A Book of Lenses. Morgan
Kaufmann, San Francisco, 2008
[Shabanah und Chen 2009] Shabanah, Sahar ; Chen, Jim X.: Simplifying algorithm
learning using serious games. In: WCCCE ’09: Proceedings of the 14th Western Canadian
Conference on Computing Education. New York, NY, USA : ACM, 2009, S. 34–41. – ISBN
978-1-60558-415-7
[Shultz 2006] Shultz, Gerald A.: Using a simple game engine in teaching CS1: conference
workshop. In: J. Comput. Small Coll. 22 (2006), Nr. 1, S. 161–161. – ISSN 1937-4771
[Source Engine 2009] Source Engine: Source Engine Overview. 2009. – URL http:
//source.valvesoftware.com/. – [Online; Stand 18. September 2009]
[Statistisches Bundesamt 2009] Statistisches Bundesamt: Computer in der Freizeit von
jungen Männern bevorzugt. 2009. – URL http://www.destatis.de/jetspeed/portal/
cms/Sites/destatis/Internet/DE/Presse/pm/2004/06/PD04__261__ikt.psml. –
[Online; Stand 18. August 2009]
[Süddeutsche Zeitung 2009] Süddeutsche Zeitung: Ein Sport wie jeder andere? 2009.
– URL http://www.sueddeutsche.de/computer/24/420786/text/. – [Online; Stand
08. Oktober 2009]
[Taxén 2003] Taxén, Gustav: Teaching computer graphics constructively. In: SIGGRAPH
’03: ACM SIGGRAPH 2003 Educators Program. New York, NY, USA : ACM, 2003, S. 1–4
[Unreal Development Kit 2010] Unreal Development Kit: Unreal Development Kit.
2010. – URL http://www.udk.com/index.html. – [Online; Stand 04. Januar 2010]
[Unreal Technology 2009a]
Unreal Technology: Current technology - Unreal
Engine 3. 2009. – URL http://www.unrealtechnology.com/features.php?ref=
technology-overview. – [Online; Stand 18. September 2009]
[Unreal Technology 2009b] Unreal Technology: Licensing Terms. 2009. – URL
http://www.unrealtechnology.com/terms.php. – [Online; Stand 10. November 2009]
[Unreal Technology 2009c] Unreal Technology: Unreal Development Kit. 2009. –
URL http://www.unrealtechnology.com/development-kit.php. – [Online; Stand
11. Oktober 2009]
[Ware 2004] Ware, Colin: Information Visualization: Perception for Design. Morgan
Kaufmann, San Francisco, 2004
82
Abbildungsverzeichnis
2.1
2.2
2.3
2.4
2.5
Anwendungsgebiet virtuelle Realität / Simulation: Evakuierung eines Gebäudes
Anwendungsgebiet virtuelle Realität / Simulation: Mehrfachbildschirmdisplay
auf Basis von Unreal Tournament . . . . . . . . . . . . . . . . . . . . . . . .
Anwendungsgebiet Informationsvisualisierung: Quellcode verständlich machen.
Links sieht man die Darstellung einer Header-Datei und einer ImplementierungsDatei aus der Sprache C als dreidimensionale Objekte. Rechts sieht man die
textuelle Darstellung von Code. Beides unter der Verwendung der Quake 3
Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Anwendungsgebiet Gebäudevisualisierung: Darstellung eines Innenraums . . .
Anwendungsgebiet Medizin: Simuliertes chirurgisches Training mit einer Game
Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
18
19
20
21
3.1
3.2
Nutzwertanalyse: Das Zielsystem . . . . . . . . . . . . . . . . . . . . . . . . 24
Nutzwertanalyse: Zielerreichungsgrade . . . . . . . . . . . . . . . . . . . . . 27
4.1
4.2
OGRE: Der Szenengraph . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
OGRE: High Level Klassendiagramm von Root Objekt und Managern . . . . 46
5.1
Konzipiertes Klassendiagramm der Architektur . . . . . . . . . . . . . . . . . 57
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
Finales Klassendiagramm der Architektur der Anwendung . .
Die Szenengraphhierarchie der Anwendung . . . . . . . . . .
Lehre der Konzepte: Thematik der Levels (Level 1 bis Level 5
rechts) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Lehre der Konzepte: Informationsfenster während des Spiels .
Lehre der Konzepte: Matrizenrechnung über das Matrixmenü
Lehre der Konzepte: Selbstständiges Texturieren . . . . . . .
Grafische Benutzeroberfläche: Das Hauptmenü . . . . . . . .
Kollisionserkennung: Axis Aligned Bounding Box . . . . . . .
. . . . .
. . . . .
von links
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . .
. . .
nach
. . .
. . .
. . .
. . .
. . .
. . .
.
.
.
.
.
.
66
67
68
70
71
73
A.1
A.2
A.3
A.4
Tutorial:
Tutorial:
Tutorial:
Tutorial:
.
.
.
.
.
.
.
.
.
.
.
.
98
99
99
100
Die Umgebungsvariable setzen
Ein neues Projekt einrichten . .
Das richtige Projekt auswählen
Das Projekt richtig einstellen .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 60
. 63
83
Abbildungsverzeichnis
A.5
A.6
A.7
A.8
A.9
A.10
A.11
Tutorial:
Tutorial:
Tutorial:
Tutorial:
Tutorial:
Tutorial:
Tutorial:
Eine Quelldatei hinzufügen . . . . . . . .
Die Projekteinstellungen vornehmen . . .
Allgemeine Projekteinstellungen . . . . . .
Debugging Einstellungen . . . . . . . . .
Die Einstellungen der Programmiersprache
Die Linkereinstellungen vornehmen . . . .
Die Linkereinstellungen vornehmen . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
100
101
101
102
103
103
104
84
Tabellenverzeichnis
3.1
3.2
3.3
3.4
3.5
3.6
Kriterien für die Game Engines: Teilziel Community . . . . . . . . . . . . .
Kriterien für die Game Engines: Teilziel Technische Aspekte / Möglichkeiten
Kriterien für die Game Engines: Teilziel Erlernbarkeit . . . . . . . . . . . .
Ergebnisse der Nutzwertanalyse: Nutzwert Microsoft XNA . . . . . . . . .
Ergebnisse der Nutzwertanalyse: Nutzwert Irrlicht . . . . . . . . . . . . . .
Ergebnisse der Nutzwertanalyse: Nutzwert OGRE . . . . . . . . . . . . . .
.
.
.
.
.
.
24
25
26
32
33
34
A.1
A.2
A.3
A.4
A.5
A.6
A.7
Ergebnisse
Ergebnisse
Ergebnisse
Ergebnisse
Ergebnisse
Ergebnisse
Ergebnisse
.
.
.
.
.
.
.
93
94
94
95
95
96
96
der
der
der
der
der
der
der
Nutzwertanalyse:
Nutzwertanalyse:
Nutzwertanalyse:
Nutzwertanalyse:
Nutzwertanalyse:
Nutzwertanalyse:
Nutzwertanalyse:
Nutzwert
Nutzwert
Nutzwert
Nutzwert
Nutzwert
Nutzwert
Nutzwert
Panda3D . . . .
Horde3D . . . .
jMonkeyEngine
Crystal Space .
Axiom . . . . .
NeoAxis . . . .
Lightfeather . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
85
Algorithmenverzeichnis
6.1
6.2
6.3
6.4
Eine minimale OGRE Anwendung . . . . . . . . . . . .
Erstellung von Szenenmanager, Camera und Viewport .
Konfigurationsdatei des Spiels . . . . . . . . . . . . . .
Kollisionserkennung zwischen Spieler und Hindernissen
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
61
61
65
73
86
Glossar
Die Definitionen für die einzelnen Begriffe stammen von Wikipedia2 und aus dem Wiki von
OGRE3 .
Advergames (Werbespiele)
Advergames stellen Spiele dar, die in unterhaltsamer Form der Werbung dienen.
API
siehe Application Programming Interface
Application Programming Interface (Programmierschnittstelle)
Eine Programmierschnittstelle ist eine Schnittstelle, die von einem Softwaresystem anderen
Programmen zur Anbindung an das System zur Verfügung gestellt wird. Oft wird dafür die
Abkürzung API verwendet.
Backface Culling
Der Begriff Backface Culling bezeichnet eine Technik der 3D-Computergrafik, mit der ein
Großteil von nicht sichtbaren Dreiecken (oder allgemeiner: von Polygonen) einer Szene entfernt
wird. Hierdurch wird die Darstellungsgeschwindigkeit erhöht.
Bezier Patches
Bezier Patches sind eine Form von gekrümmten Oberflächen.
Bump Mapping
Hierbei handelt es sich um eine Technik zur Darstellung von extrem detailreichen Objekten, ohne die Geometriekomplexität des Objektes zu erhöhen, die vor allem in 3DVisualisierungsprogrammen zum Einsatz kommt. Der Trick dabei ist, dass die benötigten
Informationen in einer Textur gelagert werden, mit deren Hilfe Schattierungen auf eine
Oberfläche gezeichnet werden. Es ist somit nur eine Illusion, welche Oberflächenunebenheiten
simuliert, die in der Geometrie des Modells gar nicht vorhanden sind.
(Syn.: Reliefzuordnung)
2
3
http://wikipedia.de/
http://www.ogre3d.org/wiki/index.php/Main_Page
87
Glossar
Clipping
Als Clipping oder Abschneiden (englisch to clip = „abschneiden“, „kappen“) bezeichnet man
in der Computergrafik das Abschneiden von Grundobjekten am Rand eines gewünschten
Bildschirmausschnittes oder Fensters. Ein Fenster kann dabei ein beliebiges Polygon sein.
CLR
Siehe Common Language Runtime
Common Language Runtime
Die Common Language Runtime (CLR) ist die Laufzeitumgebung von .NET und stellt somit
den Interpreter für den standardisierten Zwischencode, der Common Intermediate Language
(CIL), dar.
Central Processing Unit
Der Hauptprozessor (engl. central processing unit, CPU), im allgemeinen Sprachgebrauch
oft auch nur als Prozessor bezeichnet, ist die zentrale Verarbeitungseinheit (ZVE) eines
Computers, die in der Lage ist, ein Programm auszuführen.
CPU
Siehe Central Processing Unit
Direct3D
Direct3D ist eine Programmierschnittstelle (API) von Microsoft für 3D-Computergrafik.
Direct3D ist ein Bestandteil von DirectX. Direct3D dient dazu, Windows-Anwendungen
einen möglichst direkten Zugriff auf die Hardware eines Computers zu geben. Häufig verwendet wird Direct3D vor allem für Computerspiele, bei dem es mit dem plattform- und
betriebssystemunabhängigen OpenGL konkurriert.
DirectX
DirectX ist eine Sammlung von COM-basierten Programmierschnittstellen für multimediaintensive Anwendungen (besonders Spiele) auf der Windows-Plattform und kommt auch auf
der Spielekonsole Xbox zum Einsatz.
Entity
Ein Entity ist eine Instanz der Klasse MovableObject von OGRE. Dies könnte ein Auto, eine
Person oder einen Hund darstellen. Ein Entity hat dabei keine fixe Position in der Welt und
basiert auf diskreten Polygonnetzen.
Environment Mapping
Environment Mapping ist eine effiziente Methode, um in der Computer Grafik spiegelnde
Oberflächen zu simulieren und zu rendern. Dabei wird die Umgebung des spiegelnden Objekts
als Textur gespeichert und auf die Oberfläche des Objekts abgebildet (mapping).
88
Glossar
(Syn.: Reflection Mapping)
E-Sport (elektronischer Sport)
Der Begriff E-Sport bezeichnet den Wettkampf im Austragen von Computerspielen im
Mehrspielermodus.
Grafik Engine
Eine Grafik Engine (wörtlich „Grafik-Maschine“, freier etwa: „Grafiktriebwerk“ oder „Grafikmodul“) ist ein mitunter eigenständiger Teil eines Computerprogramms oder einer ComputerHardware, welcher für dessen Darstellung von Computergrafik zuständig ist, meist möglichst
realitätsgetreuer 3D-Computergrafik, wie Gegenstände, Umwelt und Personen (Stichwort:
Virtuelle Realität). Im Zusammenhang mit 3D-Computergrafik bezeichnet man die Grafik
Engine daher dann auch als 3D-Engine.
Graphical User Interface (Grafische Benutzeroberfläche)
Eine grafische Benutzeroberfläche (engl. Graphical User Interface, Abk. GUI) ist eine SoftwareKomponente, die dem Benutzer eines Computers die Interaktion mit der Maschine über
grafische Symbole erlaubt. Die Darstellungen und Elemente (Arbeitsplatz, Symbole, Papierkorb,
Menü) können meist unter Verwendung eines Zeigegerätes wie einer Maus gesteuert werden.
(Syn.: grafische Benutzerschnittstelle)
GUI
Siehe Graphical User Interface
Heads-Up-Display
Das Head-Up-Display (HUD; sinngemäß: Anzeigefeld in Blickrichtung; Frontsichtdisplay) ist
ein Anzeigesystem, bei dem die für den Nutzer wichtigen Informationen in sein Sichtfeld
projiziert werden.
Heightmap (Höhenfeld)
Höhenfelder sind zweidimensionale skalare Felder, die ein Höhenrelief beschreiben. Jedem Ort
ist hier also ein Wert zugeordnet, der eine Position in der dritten räumlichen Dimension angibt,
eine Höhe. So können z. B. die Höhenreliefs von Landschaften und anderen Oberflächen als
Höhenfeld beschrieben werden.
High Dynamic Range Rendering
High Dynamic Range Rendering (HDRR) bezeichnet in der Computergrafik die Bildsynthese
(„Rendering“) unter Berücksichtigung der in der Natur vorkommenden großen Helligkeitsschwankungen. Im Gegensatz zu den herkömmlichen 256 Helligkeitsabstufungen pro Farbkanal
werden beim HDRR Farben intern mit ausreichend hoher Präzision repräsentiert, um einen sehr
großen Bereich von Helligkeiten abzudecken. Dies ermöglicht die Darstellung starker Kontraste
89
Glossar
ohne übermäßigen Detailverlust und die Anwendung von Effekten wie der Simulation von
Linsenstreuung.
HUD
siehe Heads-Up Display
Level of Detail
Mit Level of Detail (LOD) (deutsch: Detailstufen) bezeichnet man die verschiedenen Detailstufen bei der Darstellung virtueller Welten. Um die Geschwindigkeit von Anwendungen
der virtuellen Realität zu steigern, setzt man meist auf gleichzeitiges Nutzen von hoher
Detailgenauigkeit im Nahbereich und niedriger Detailstufe im Fernbereich.
Mesh (Polygonnetz)
Ein Polygonnetz (engl. Mesh) ist eine Sammlung von Vertices, Kanten und Seiten, die die
Form eines Polyeder-Objektes in der Computer Grafik definieren. Die Seiten bestehen für
gewöhnlich aus Dreiecken, Vierecken oder anderen simplen gewölbten bzw. ausgehöhlten
Polygonen. Ein Polyeder ist ein Teil des dreidimensionalen Raumes, der ausschließlich von
geraden Flächen begrenzt wird, wie beispielsweise ein Würfel.
Motion Blur (Bewegungsunschärfe)
Als Bewegungsunschärfe (engl. motion blur) bezeichnet man in der Fotografie eine auf Zonen
begrenzte Unschärfe in Bildern bewegter Objekte. In Computerspielen und Animationen (computergenerierten Filmen) wird Bewegungsunschärfe eingesetzt, um Bewegungen realistischer
zu machen.
OpenGL
OpenGL (Open Graphics Library) ist eine Spezifikation für eine plattform- und programmiersprachenunabhängige Programmierschnittstelle zur Entwicklung von 2D- und 3D-Computergrafik.
Der OpenGL-Standard beschreibt etwa 250 Befehle, die die Darstellung komplexer 3D-Szenen
in Echtzeit erlauben.
Phong Beleuchtungsmodell
Das Phong Beleuchtungsmodell ist ein Beleuchtungsmodell in der 3D-Computergrafik, das
dazu verwendet wird, die Beleuchtung von Objekten zu berechnen.
Portal Rendering
In Echtzeit Computer Grafik bezeichnet Portal Rendering einen Algorithmus für Sichtbarkeitsentscheid. In einer Spielszene gibt es möglicherweise viele Polygone, von denen zu einer
bestimmten Zeit nur ein paar sichtbar sind. Sichtbarkeitsentscheid hilft dem Renderer zu
entscheiden, welche sichtbar sind und welche nicht.
90
Glossar
Rendering Engine
Siehe Grafik Engine
Render to Texture
Im Kontext von OGRE bezeichnet Render to Texture eine Technik, bei der die dargestellten
Pixel auf eine Textur anstatt auf den Bildschirm gezeichnet werden.
Scene Node
Ein Scene Node in OGRE ist ein logisches Element in der Hierarchie des Szenengraphen,
welcher zur Organisation der Objekte in der Szene dient. Ein Scene Node kann mehrere
Kindknoten oder bewegliche Objekte haben (wie etwa Kameras, Lichter, Partikelsysteme
usw.).
Serious Game (digitales Lernspiel)
Der Begriff digitales Lernspiel (engl. Serious Game) bezieht sich auf Spiele, die in einer hardund softwarebasierten virtuellen Umgebung stattfinden und die erwünschtes Lernen anregen
wollen.
Shader
Shader, auch als Schattierer bezeichnet, sind Hardware- oder Softwaremodule, die bestimmte
Renderingeffekte bei der 3D-Computergrafik implementieren. Aus technischer Sicht bezeichnet
„Shader“ denjenigen Teil eines Renderers, der für die Ermittlung der Farbe eines Objektes
zuständig ist – im Gegensatz zu dem Teil, der die Sichtbarkeit des Objektes ermittelt. Shader
wurden ursprünglich für das Shading, also die Beleuchtungs-Berechnung, entwickelt, werden
aber mittlerweile auch für andere Dinge verwendet. Der Begriff „Shader“ wird sowohl für die
Hardware-Shader als auch für die darauf laufenden Programme selbst verwendet.
Shadow Mapping
Shadow Mapping ist eine Methode der Computergrafik, um Schattenwurf darzustellen. Beim
Shadow Mapping wird zunächst die sogenannte Shadow Map erzeugt. Diese ist eine aus
Sicht der Lichtquelle erzeugte Tiefenkarte, enthält also Informationen über den geringsten
Abstand von Objekten einer Szene zur Lichtquelle. Durch den Vergleich des Abstandes des
zu rendernden Objektes zur Lichtquelle und dem entsprechenden Punkt in der Shadow Map
kann der Schattenwurf berechnet werden.
Skybox
Eine Skybox ist ein Satz von sechs Bildern, die einen Würfel bilden, der hinter allem dargestellt
wird. Somit ist der Betrachter immerzu „im“ Würfel. Dies ist sinnvoll für die Erstellung der
Illusion von Himmeln und ähnlichem.
91
Glossar
Software Rendering
Software-Rendering bezeichnet die Methode der Grafikberechnung ohne spezialisierte Hardware, d. h. nur durch die CPU ohne Unterstützung durch eine Grafikkarte oder Vergleichbares.
Die Grafikkarte leitet dabei unbeteiligt die von der CPU berechneten Daten an den Monitor
weiter.
Standard Template Library
Als Standard Template Library (STL) werden verschiedene in der Programmiersprache C++
geschriebene Bibliotheken bezeichnet.
Texture Mapping
Der Begriff Texture Mapping (deutsch etwa Musterabbildung) bezeichnet ein Verfahren
der 3D-Computergrafik. Es dient dazu, die Flächen dreidimensionaler Oberflächenmodelle
mit zweidimensionalen Bildern – sogenannten „Texturen“ – und Oberflächeneigenschaften
auszustatten.
UML
Siehe Unified Modelling Language
Unified Modelling Language
Die Unified Modeling Language, kurz UML (auf deutsch „Vereinheitlichte Modellierungssprache“),
ist eine von der Object Management Group (OMG) entwickelte und standardisierte Sprache
für die Modellierung von Software und anderen Systemen.
Vertex / Vertices
Ein Vertex ist in der Geometrie eine Ecke eines Polygons.
Wrapper
Als Wrapper bezeichnet man in der Informationstechnik ein Stück Software, welches ein
anderes Stück Software umgibt. Dies kann sich sowohl auf ganze Programme, als auch nur
auf einzelne Programmteile bis Klassen beziehen. Die "Umhüllung" kann sowohl visueller
als auch technischer Natur sein. Wrapper werden aus unterschiedlichen Gründen eingesetzt,
zumeist sind das Kompatibilitäts-, Sicherheits- oder architektonische Gründe.
92
A Anhang
A.1 Tabellen der Nutzwerte untersuchter Engines
Panda3D
Kriterium
Erreichungsgrad
Nutzwert
1
3
42
2
3
36
3
3
27
4
3.5
24.5
5
3.5
35
6
3.5
28
7
4
24
8
4
48
9
2.5
25
10
3
36
Gesamt
325.5
Tab. A.1: Ergebnisse der Nutzwertanalyse: Nutzwert Panda3D
93
A Anhang
Horde3D
Kriterium
Erreichungsgrad
Nutzwert
1
3
42
2
2
24
3
3.5
31.5
4
3.5
24.5
5
3
30
6
3
24
7
3
18
8
2.5
30
9
1
10
10
2.5
30
Gesamt
264
Tab. A.2: Ergebnisse der Nutzwertanalyse: Nutzwert Horde3D
jMonkeEngine
Kriterium
Erreichungsgrad
Nutzwert
1
3.5
49
2
3.5
42
3
3
27
4
2
14
5
3.5
35
6
3.5
28
7
4
24
8
3
36
9
1
10
10
3
36
Gesamt
301
Tab. A.3: Ergebnisse der Nutzwertanalyse: Nutzwert jMonkeyEngine
94
A Anhang
Crystal Space
Kriterium
Erreichungsgrad
Nutzwert
1
2.5
35
2
2.5
30
3
3
27
4
3.5
24.5
5
3.5
35
6
3.5
28
7
4
24
8
2.5
30
9
2.5
25
10
3
36
Gesamt
294.5
Tab. A.4: Ergebnisse der Nutzwertanalyse: Nutzwert Crystal Space
Axiom
Kriterium
Erreichungsgrad
Nutzwert
1
2
28
2
2
24
3
3.5
31.5
4
3
21
5
3.5
35
6
3.5
28
7
4
24
8
3
36
9
1
10
10
3
36
Gesamt
273.5
Tab. A.5: Ergebnisse der Nutzwertanalyse: Nutzwert Axiom
95
A Anhang
NeoAxis
Kriterium
Erreichungsgrad
Nutzwert
1
2.5
35
2
2
24
3
3.5
31.5
4
3
21
5
4
40
6
3.5
28
7
3
18
8
2.5
30
9
1
10
10
3
36
Gesamt
273.5
Tab. A.6: Ergebnisse der Nutzwertanalyse: Nutzwert NeoAxis
Lightfeather
Kriterium
Erreichungsgrad
Nutzwert
1
2
28
2
2
24
3
3.5
31.5
4
3.5
24.5
5
4
40
6
3
24
7
3.5
21
8
3.5
42
9
2
20
10
2.5
30
Gesamt
285
Tab. A.7: Ergebnisse der Nutzwertanalyse: Nutzwert Lightfeather
A.2 Installation des Spiels
Das Spiel lässt sich leicht installieren. Das Spiel befindet sich in einer RAR-Datei, die
schlichtweg entpackt werden muss. Sollte es beim Spielstart zu Fehlermeldungen kommen
96
A Anhang
oder das Bild der Anwendung schwarz bleiben, hilft meist eine Installation der aktuellen Version
von DirectX1 , eine Aktualisierung der Grafikkartentreiber und die Installation des Nvidia
CG Toolkits2 . Das Spiel wird über die ausführbare Datei mit dem Namen „DodgeHead.exe“
gestartet, die sich im Hauptverzeichnis befindet.
A.3 Installation und Einrichtung des OGRE SDKs
Dieser Abschnitt behandelt die Installation des OGRE Software Development Kits auf einer
Windows Plattform (XP) mit Visual Studio. Hierbei kann entweder die kostenlose Express
Edition oder auch das Visual Studio verwendet werden.
Die entsprechenden Pakete zur Installation des SDKs findet man unter http://www.ogre3d.
org/download/sdk. Sollte OGRE auf einer anderen Plattform installiert werden, findet man
die entsprechenden Anleitungen im Wiki auf der Seite http://www.ogre3d.org/wiki/
index.php/Installing_An_SDK. Anschließend folgt man den Anweisungen der Installation.
Ist die Installation beendet, so kann man sich an die Konfiguration der Entwicklungsumgebung
wagen. Wird eine Version von Visual C++ verwendet, die aktueller als VC++ .NET 2003 ist,
so kann auch der OGRE Application Wizard verwendet werden. Weiterhin wurde die englische
Version von Visual Studio verwendet.
Die Anleitung zur Installation und Einrichtung des SDKs basiert auf Einträgen aus dem Wiki
der OGRE Internetpräsenz:
Das manuelle Erstellen einer Anwendung:
http://www.ogre3d.org/wiki/index.php/SettingUpAnApplication
Das Erstellen mit Hilfe des OGRE Application Wizards:
http://www.ogre3d.org/wiki/index.php/The_Complete_Blanks_Guide_To_Using_
The_OGRE_SDK_AppWizard
Die Installation des SDKs für Visual Studio:
http://www.ogre3d.org/wiki/index.php/Installing_the_Ogre_SDK_for_Visual_
C%2B%2B
1
2
http://www.microsoft.com/games/en-US/aboutGFW/pages/directx.aspx
http://developer.nvidia.com/object/cg_toolkit.html
97
A Anhang
A.3.1 Manuelle Erstellung
Umgebungsvariable
Eventuell muss man die Umgebungsvariable selbst einrichten. Diese Umgebungsvariable
zeigt dann immer auf den Installationsordner von OGRE. Damit kann man alle Pfade,
die man in der Entwicklungsumgebung einstellt, relativ zu diesem Pfad einstellen. Das
erleichtert beispielsweise die Arbeit, wenn man das Projekt auf mehreren Rechnern zum
Laufen bringen möchte. Wenn man das OGRE SDK runtergeladen hat, sollte automatisch eine
Umgebungsvariable angelegt worden sein. Existiert sie nicht, dann sollte man OGRE_HOME
manuell definieren. Wenn man den Quellcode runtergeladen hat, legt man am besten eine
neue Variable namens OGRE_SRC an, die auf den entsprechenden Ordner zeigt.
Man kann die Umgebungsvariable unter Windows XP anlegen, indem man einen Rechtsklick
auf „Arbeitsplatz“ macht, den Reiter „Erweitert“ auswählt und dort unter dem Punkt
„Umgebungsvariablen“ eine neue Variable „OGRE_HOME“ mit dem Pfad zum Ordner, das
das OGRE SDK beinhaltet, setzt.
Abb. A.1: Tutorial: Die Umgebungsvariable setzen
Ein Projekt anlegen
1. Man öffnet Visual C++ und erstellt ein neues Projekt.
98
A Anhang
Abb. A.2: Tutorial: Ein neues Projekt einrichten
2. Anschließend wählt man „Visual C++ / Win 32“ und dort den Unterpunkt „Win 32
Project“ aus. Anschließend gibt man einen Projektnamen und den Pfad zum Projekt
an.
Abb. A.3: Tutorial: Das richtige Projekt auswählen
3. Als Anwendungstyp wählt man „Windows Application“ und „empty Project“.
99
A Anhang
Abb. A.4: Tutorial: Das Projekt richtig einstellen
4. Nun fügt man eine neue Quelldatei zum Projekt hinzu. Dies ist wichtig, da sonst die
Projekteinstellungen nicht vorgenommen werden können.
Abb. A.5: Tutorial: Eine Quelldatei hinzufügen
Ein Projekt richtig konfigurieren
Wenn das Projekt den Namen „TutorialAnwendung“ trägt und man den Pfad beispielsweise auf „C:\Workspace“ setzt und den Haken für „Create directory for solution“ angek-
100
A Anhang
lickt hat und dort „TutorialSolution“ angibt, dann sieht die Struktur folgendermaßen aus:
„C:\Workspace\TutorialSolution\TutorialAnwendung“. Wenn man keinen Ordner für die Solution auswählt, ist die Struktur einfach „C:\Workspace\TutorialAnwendung“. Für gewöhnlich
müsste es mit der folgenden Konfiguration keine Probleme mit den DLLs geben. Die Einstellungen beziehen sich alle auf die Debug Konfiguration, für Release Konfiguration ersetzt
man die Pfade „Debug“ durch „Release“ und entfernt bei entsprechenden Bibliotheken das
„_d“ am Ende. Unter „Project Properties“ und „Configuration Properties“ nimmt man die
folgenden Einstellungen vor:
Abb. A.6: Tutorial: Die Projekteinstellungen vornehmen
1. Unter „Configuration Properties / General“ setzt man das Output Directory auf
„bin\$(ConfigurationName)“ und das Intermediate Directory auf „obj\$(ConfigurationName)“.
Abb. A.7: Tutorial: Allgemeine Projekteinstellungen
101
A Anhang
2. Unter Debugging fügt man bei Command „bin\$(ConfigurationName)\$(ProjectName).exe“
ein. Weiterhin fügt man unter Working Directory „bin\$(ConfigurationName)“ ein.
Im Gegensatz zum Tutorial im Internet wird in diesem Tutorial die Anwendung im
Verzeichnis ausgeführt, in dem sich auch das Visual Studio Projekt befindet. Auf der
Abbildung 8.8 kann man sehen, dass sich die Umgebungsvariable im Pfad befindet.
Diese sollte entfernt werden. Das verhindert, dass die kompilierte Anwendung in das
allgemeine OGRE SDK Verzeichnis verschoben wird und dort viele auszuführende
Dateien angelegt werden.
Abb. A.8: Tutorial: Debugging Einstellungen
3. Unter „C / C++“ fügt man unter Additional Include Directories „include; $(OGRE_HOME)\include;
$(OGRE_HOME)\samples\include“ ein.
102
A Anhang
Abb. A.9: Tutorial: Die Einstellungen der Programmiersprache
4. Jetzt fügt man unter „Linker / General“ unter Output File „$(OutDir)\$(ProjectName).exe“
und unter Additional Library Directories „$(OGRE_HOME)\lib“ ein.
Abb. A.10: Tutorial: Die Linkereinstellungen vornehmen
5. Abschließend fügt man unter „Linker / Input“ bei Additional Dependencies „OgreMain_d.lib OIS_d.lib“ ein. Möchte man heir die Release Einstellungen verwenden, lässt
man das „_d“ am Ende einfach weg.
103
A Anhang
Abb. A.11: Tutorial: Die Linkereinstellungen vornehmen
Nun ist das Projekt korrekt konfiguriert und die Entwicklung einer Anwendung mit dem
OGRE SDK kann beginnen. Zusätzlich müssen noch die DLLs aus dem Ordner „bin/release“ beziehungsweise „bin/debug“ in den entsprechenden Ordner des Projektverzeichnisses
verschoben werden.
Installation zusätzlicher Bibliotheken
Für die Entwicklung der Anwendung dieser Thesis wurden zusätzlich die Bibliotheken GLib
und Audiere verwendet. Hierfür legt man am besten einen Ordner unterhalb des OGRE
SDK Ordners namens „addons“ an und kopiert dorthin die jeweiligen Quelldateien, die für
die Entwicklung benötigt werden. Dann fügt man die jeweiligen Include Verzeichnisse wie
oben beim dritten Schritt beschrieben zur Konfiguration hinzu. Außerdem muss man die
Bibliotheken einbinden, wie beim vierten Schritt beschrieben. Hierfür gibt es meistens einen
Ordner namens „lib“, in dem sich die Bibliotheken befinden. Zur Verwendung der zusätzlichen
Bibliotheken müssen dann noch die jeweiligen DLL Dateien in den Ordner kopiert werden, in
dem die auszuführende Datei liegt.
Die Anwendung wurde für diese Arbeit entsprechend vorbereitet, es muss lediglich noch das
SDK von OGRE installiert und die Umgebungsvariable gesetzt werden. Anschließend kann
das Visual Studio Projekt geöffnet und verwendet werden.
104
A Anhang
A.3.2 Erstellung mit Hilfe des OGRE Application Wizards
Eine wesentlich einfachere Methode der Installation ist der OGRE Application Wizard. Dies ist
ein Assistent, der bei der Erstellung eines Projektes behilflich ist. Den OGRE Application Wizard findet man unter http://sourceforge.net/projects/ogreconglo/files/. Nach
dem Herunterladen navigiert man in den Ordner des Wizards und installiert ihn mit Hilfe eines
Doppelklicks auf die entsprechende .js-Datei. Den Ordner lässt man an der entsprechenden
Stelle bestehen.
Unter Windows Vista / Windows 7 benötigt man eine Eingabekonsole als Administrator.
Diese erhält man unter „Start Menü / Alle Programme / Zubehör“, dann macht man einen
Rechtsklick auf die Eingabekonsole und startet sie als Administrator.
Nun kann man die Entwicklungsumgebung starten und ein neues Projekt anlegen. Hier wählt
man als Template eine OGRE SDK Anwendung aus und gibt den entsprechenden Namen und
den Pfad des Projektes an. Anschließend entscheidet man sich für eine Standard Anwendung
und je nach Bedarf für ein eigenes Framework oder das Beispiel-Framework. Anschließend
beendet man den Assistenten. Nun kann mit der Entwicklung begonnen werden.
Sollte beim Kompilieren eine Zeile namens „SET_TERM_HANDLER“ Ärger machen, entfernt
man sie einfach. Diese Zeile ist in neueren Versionen nicht mehr nötig.
Der OGRE Application Wizard richtet lediglich OIS und CEGUI als zusätzliche Bibliotheken
ein. Im vorangegangenen Abschnitt wird die manuelle Installation zusätzlicher Bibliotheken
behandelt. Der Application Wizard richtet das Projekt außerdem so ein, dass nach dem
Kompilieren die Anwendung im bin-Ordner des OGRE SDKs gefunden wird und nicht im
Projektverzeichnis.
A.3.3 Fehlerquellen
Sollte es zu Fehlern bezüglich der DLLs kommen oder andere Probleme geben, erhählt man
Hilfe im Ogre Wiki unter dem Link http://www.ogre3d.org/wiki/index.php/BuildFAQ.
Zwei Probleme traten bei der Installation des SDKs in dieser Thesis auf. Zum einen das
Fehlen der „windows.h“, was mit der Installation des Windows SDKs3 behoben werden kann.
3
http://msdn.microsoft.com/de-de/windows/bb980924.aspx
105
A Anhang
Zum anderen fehlte eine DLL, die Direct3D betraf. Dieser Fehler wurde durch die Installation
der aktuellen DirectX Version behoben.
A.4 Fragebogen
1. Gab es Probleme beim Spielstart? Wenn ja, wie lautet der Fehler?
2. Hat Ihnen das Spiel Spaß gemacht?
JA | NEIN
3. Wie gefällt Ihnen die Spielidee?
4. Halten Sie es für sinnvoll, Computer Grafik spielerisch erlernbar zu machen?
JA | NEIN
5. Lässt sich das Spiel gut bedienen / steuern?
JA | NEIN
6. Wenn bei Frage 4 „NEIN“ angekreuzt wurde, schreiben Sie hier bitte, warum es
sich nicht gut steuern / bedienen lässt
7. Ist das Spielziel ersichtlich? Wenn nein, warum nicht?
8. Sind Ihnen Fehler im Spielablauf aufgefallen? Wenn ja, welche?
9. War das Spiel zu schwer oder zu leicht? Wenn eines von beiden zutrifft, erklären
Sie bitte warum?
10. Sollte die Interaktion im Spiel noch gesteigert werden?
JA | NEIN
11. Was könnte Ihrer Meinung nach noch verbessert werden?
12. Hat Ihnen das Spiel in irgendeiner Weise geholfen, die Konzepte der Computer
Graphik zu verstehen? Wenn ja, wie?
13. Welche Bereiche der Computer Grafik haben Ihnen im Unterricht persönlich Probleme bereitet bzw. waren schwer verständlich und sollten im Spiel näher behandelt
werden?
14. Haben Sie weitere Ideen, wie man die Konzepte der Computer Grafik spielerisch
erlernbar machen könnte?
15. Sonstige Anregungen oder Kritik zum Spiel
106
A Anhang
Bereits bestehende weitere Ideen
Bisher weiter angedachte Ideen wären Quizfragen innerhalb des Spiels, wenn man bestimmte
Kugeln aufsammelt oder am Ende eines Levels.
Vielen Dank für das Ausfüllen des Fragebogens!
107
Selbständigkeitserklärung
Ich versichere, dass ich diese Bachelor Thesis selbstständig verfasst, keine anderen als die
angegebenen Quellen und Hilfsmittel benutzt sowie alle wörtlich oder sinngemäß übernommenen Stellen in der Arbeit gekennzeichnet habe. Die Arbeit wurde noch keiner Kommission zur
Prüfung vorgelegt und verletzt in keiner Weise Rechte Dritter.
Reutlingen, den 18.01.2010
Dennis Schneider
108

Bachelorthesis Evaluierung von 3D Game

Transcription

Similar documents

Das Spiel zur Hit

Akzeptanz von Tangible User Interfaces im AR Gaming

Vergleich von 3D Game Engines - Institut für Visualisierung und

Diplomarbeit - Universität Passau

GameStage@AEC - Ars Electronica

(2006) 3D-Interface für das Naked-Objects

Tutonium – Interaktive Tutorials für Web

und Rettungsmissionen unter eingeschränkten Sichtverhältnissen

lehrerhandbuch