Skripting und Modding - Institut für Verteilte Systeme

Seminar 3D-Modellierung und virtuelle Präsenz
My-HL
Scripting / Modding / Programmierung von 3D-Objekten
- Ausarbeitung Dominik Jäger
1
Inhaltsverzeichnis
1 Einleitung........................................................................................................................................ 3
2 Modding.......................................................................................................................................... 3
2.1 Begriffserklärung..................................................................................................................... 3
2.1.1 Erweiterungsset................................................................................................................ 3
2.1.2 Mod.................................................................................................................................. 3
2.1.2.1 Mutator..........................................................................................................................3
2.1.2.2 Partial / Total Conversion............................................................................................. 4
2.1.2.3 Standalone..................................................................................................................... 4
2.1.2.4 Engine........................................................................................................................... 4
2.2 Die Entstehung.........................................................................................................................4
2.2.1 Geschichte........................................................................................................................ 4
2.2.2 Kommerzieller Erfolg...................................................................................................... 4
2.2.3 Unterstützung in Spielen.................................................................................................. 5
2.3 Fallbeispiele............................................................................................................................. 5
2.3.1 Bekannte Mods................................................................................................................ 5
2.3.2 Half-Life...........................................................................................................................6
2.3.3 Half-Life 2: Garry's Mod................................................................................................. 7
3 Editing............................................................................................................................................. 7
3.1 Inhalte...................................................................................................................................... 8
3.1.1 Arten von Spielinhalten................................................................................................... 8
3.1.2 Strukturierung von Spielinhalten..................................................................................... 9
3.2 Editoren..................................................................................................................................10
3.2.1 Half-Life: Worldcraft / Hammer....................................................................................10
3.2.2 Modding in Second Life................................................................................................ 11
4 Scripting........................................................................................................................................ 12
4.1 Beispiele für Skriptsprachen..................................................................................................12
4.1.1 QuakeC...........................................................................................................................12
4.1.2 Python............................................................................................................................ 12
4.1.3 Python in Blender...........................................................................................................13
4.1.4 Scripting in Second Life: Linden Scripting Language...................................................14
4.2 Programmierung von 3D-Objekten....................................................................................... 14
4.2.1 Programmierung in 3D-Umgebungen............................................................................14
4.2.2 Spezielle 3D-Objekte..................................................................................................... 15
4.2.3 Modifizieren von 3D-Objekten...................................................................................... 16
4.3 Beispiele.................................................................................................................................16
4.3.1 Türe................................................................................................................................ 17
4.3.2 Portal.............................................................................................................................. 17
5 Quellenangaben............................................................................................................................. 18
5.1 Bilder..................................................................................................................................... 18
5.2 Informationen.........................................................................................................................18
2
1 Einleitung
Dieses Dokument ist eine Ausarbeitung des Themas „Scripting / Modding / Programmierung von
3D-Objekten“ aus dem Seminar „3D-Modellierung und virtuelle Präsenz“ im Sommersemester
2007 an der Universität Ulm, Institut für verteilte Systeme.
Der Titel des Themas enthält drei Themenbereiche, die hier folgendermaßen behandelt werden:
Modding ist das Hauptthema dieser Ausarbeitung und stellt einen roten Faden durch alle
Themengebiete dar. Deshalb beginnt dieses Dokument auch mit einem allgemeinen Abschnitt über
Modding bevor in einem zusätzlichen Themengebiet namens „Editing“ die verschiedenen Aspekte
der Modifikation von Spielinhalten behandelt werden. Hier werden auch einige Beispiele bekannter
Editoren für Spielinhalte vorgestellt. Scripting kann ebenso wie Editing als ein Werkzeug für die
Realisierung von Mods betrachtet werden. Daher wird dieser Bereich nach dem Kapitel „Editing“
als drittes behandelt. Die Programmierung von 3D-Objekten bezieht sich auf die Möglichkeiten, die
man unter anderem mit Scripts hat, in 3D-Umgebungen mit Objekten verschiedenster Art
umzugehen. Dieser Abschnitt stellt eine Vertiefung des Abschnitts über Scripting dar, wobei die
behandelten Grundlagen aber auf beliebige Programmiersprachen übertragbar sind.
2 Modding
2.1 Begriffserklärung
Es haben sich neben dem Begriff „modding“ noch einige weitere ähnliche bzw. synonyme Begriffe
eingebürgert, deren Unterschiede im folgenden erläutert werden.
2.1.1 Erweiterungsset
Erweiterungssets sind Erweiterungen des Spiels, die vom Hersteller des Spiels vertrieben werden,
um das Spielerlebnis mit neuen Inhalten zu verlängern. Diese Erweiterungen benötigen in der Regel
eine Installation des Hauptspiels, um lauffähig zu sein und werden zu einem niedrigeren Preis als
das Original angeboten. So kann mit relativ wenig Entwicklungsaufwand der kommerzielle Erfolg
des Originalspiels fortgeführt werden. Von der technischen Umsetzung her werden solche
Erweiterungen in heutigen Spielen genau so realisiert wie auch Mods. Für die Unterscheidung
dieses Begriffs von einem Mod gibt es mehrere Gründe. Zum einen werden bei Erweiterungssets
meist nur relativ wenige Änderungen am Spielprinzip vorgenommen und stattdessen vorrangig die
Geschichte des Originalspiels fortgesetzt. Außerdem werden Erweiterungssets vom Hersteller des
Spiels oder einer lizesierten zweiten Firma gezielt für den kommerziellen Spielemarkt entwickelt.
2.1.2 Mod
Der Begriff „mod“ ist eine Abkürzung von „modification” (dt. Modifikation) und somit „modding“
eine Abkürzung von „modifying“ (dt. modifizieren, ändern). Modding ist also ein Vorgang der
Modifikation einer Sache. In dem hier behandelten Kontext ist mit Modding das Modifizieren von
Computerspielen gemeint und wird im folgenden entsprechend verwendet. Im Gegensatz zu
Erweiterungssets ist eine Mod eine von Spielern abgeänderte Versionen eines Spiels. Obwohl schon
einige wenige Mods den Sprung zum kommerziellen Produkt geschafft haben, werden diese nicht
von Anfang an vom Hersteller des Spiels unterstützt. Stattdessen sind Mods anfangs häufig nur
Hobby-Projekte von Fans des Spiels. [3]
2.1.2.1 Mutator
Der Begriff „Mutator“ wurde z.B. von der Unreal Tournament Reihe geprägt. Er bezeichnet eine
minimale Änderung in der Spielkonfiguration. Meistens wird nur ein Parameter wie z.B.
Schussstärke oder Gravitation verändert, um das Spielerlebnis abwechslungsreicher zu gestalten.
3
2.1.2.2 Partial / Total Conversion
Eine Mod bezeichnet man als „Partial Conversion“, wenn nur einige Inhalte des Originalspiels
geändert und alle anderen aus dem Originalspiel übernommen wurden. Wurden alle oder zumindest
die meisten Inhalte modifiziert, kann die Mod als „total conversion“ bezeichnet werden. Eine total
conversion Mod ändert zumindest das Spielprinzip und die meisten im geänderten Spiel
vorkommenden Inhalte, kann aber den Quellcode des Hauptprogramms unverändert lassen.
2.1.2.3 Standalone
Eine Mod bezeichnet man als „Standalone-Mod“, wenn ihre Installation bereits alle zum Spielen
benötigten Dateien beinhaltet und somit das Originalspiel nicht vorausgesetzt wird.
2.1.2.4 Engine
Die „engine“ bezeichnet das Kernprogramm eines Spiels. Ändert eine Mod dieses Kernprogramm,
was die Verfügbarkeit des Originalquellcodes voraussetzt, bezeichnet man diese als „Engine-Mod“.
2.2 Die Entstehung
2.2.1 Geschichte
Modifikationen von Spielen haben ihren Ursprung in der Spieler-Community. Schon zu C64 Zeiten
versuchten Spieler mit ausreichenden Programmierkenntnissen, Originalspiele nach ihren
Vorstellungen abzuändern. Zu dieser Zeit brachten die Spiele im Gegensatz zu heute noch keine
eingebaute Unterstützung für solche Vorhaben mit und die Änderungen mussten direkt im
Sourcecode des Spiels erfolgen. Eines der ersten Spiele auf dem PC, dass die Erstellung eigener
Levels ermöglichte war Doom. Die Werkzeuge waren damals allerdings noch wenig ausgereift und
schwer zu bedienen. Tiefer gehende Modifikationen, z.B. an der Spiellogik erforderten weiterhin
eine Änderung des Sourcecodes, welcher allerdings bereits seit Jahren vom Hersteller offen gelegt
wurde. Dies hat bereits einige engine-mods hervorgebracht, welche z.B. die Grafik auf einen
neueren Stand gebracht haben. Auf diesen engine-mods aufsetzend entstanden dann auch viele
Mods, die weit über das erstellen eigener Levels hinausgehen und teilweise noch heute weiter
entwickelt werden. Diese Entwicklung hatte zur Folge, dass Mods vor allem im Genre der firstperson-shooter sehr populär geworden sind.
In den Jahren nach der Veröffentlichung von Doom gab es einige weitere Spiele des selben
Herstellers, welche eine immer bessere Unterstützung für Mods boten. So gab es für das Spiel
Quake bereits eine einfache Skriptsprache namens QuakeC, welche in einem späteren Kapitel noch
näher betrachtet wird. Diese ermöglichte bereits weitreichende Änderungen an der Spiellogik, der
Spielphysik und vielem mehr ohne dass eine Änderung am Quellcode des Hauptprogramms
notwendig war. Auch der Quellcode dieses Spiels und der seines Nachfolgers Quake 2, was eines
der Spiele mit den meisten Mods überhaupt ist, wurde bereits offen gelegt.
Da die Entwicklung einer großen Mod sehr aufwendig ist, schließen sich oft mehrere Spieler zu
einer Gruppe zusammen, um die Mod zu realisieren. Hier wird dann in der Regel eine ProjektWebsite ins Leben gerufen, über die sich die Gruppe koordinieren und Beta-Versionen ihrer Mod
veröffentlichen kann. So können verschiedene Aspekte der Entwicklung auf die entsprechenden
Talente in der Gruppe aufgeteilt werden. Dieser Prozess ist vergleichbar mit der Entwicklung einer
open source Anwendung, wobei hier allerdings die Erstellung und das Design von Spielinhalten im
Vordergrund steht.
2.2.2 Kommerzieller Erfolg
Die Half-Life Mod „Counter-Strike“ ist das Paradebeispiel einer kommerziell erfolgreichen Mod.
Sie konnte das Originalspiel im online multi-player Bereich deutlich übertrumpfen und ist bis heute
eines der meist gespielten Mods. Angesichts des großen Erfolgs der Mod im online Bereich
4
entschloss sich der Hersteller von Half-Life, Valve Software, das Entwickler-Team zu unterstützen
und die Mod kommerziell zu vertreiben. Dies ist ein gutes Beispiel dafür, wie eine Gruppe von
Hobby-Entwicklern mit einer guten Idee eine Einstiegschance in die Spiele-Industrie erhalten
konnte. Dem Beispiel folgend werden heute viele talentierte Entwickler aus der Modding-Szene
von Spielefirmen eingestellt. So entstanden in jüngster Vergangenheit bereits kommerzielle
Nachfolger ehemals frei erhältlicher Mods als eigenständiges Spiel.
Ein Beispiel hierfür ist die Mod „Enemy Territory“, welche ehemals für das Spiel „Return to Castle
Wolfenstein“ entwickelt wurde und jetzt vom ursprünglichen Entwicklerteam, welches inzwischen
ebenfalls vom Hersteller des Originals übernommen wurde, als eine Art Strategiespiel im QuakeUniversum unter dem Namen „Enemy Territory: Quake Wars“ weitergeführt wurde.
Diese Beispiele sollen vermitteln, wie weitläufig die Möglichkeiten im Bereich Modding sind und
welchen enormen Einfluss Mods auf die Spieleindustrie genommen haben. [1], [2]
2.2.3 Unterstützung in Spielen
Der kommerzielle Erfolg vieler Mods trug dazu bei, dass in heutigen Spielen einiger Genres die
Unterstützung von Mods obligatorisch geworden ist. Aber das vereinfachen von Änderungen an
Spielinhalten bringt auch direkt für den Hersteller des Spiels Vorteile. So erfordert das einfache
Umschalten zwischen verschiedenen Inhalten eine gewisse Modularisierung in der Architektur des
Programms und der Strukturierung der Inhalte sowie eine möglichst gute Trennung von Programm
und Inhalten. Dies erleichtert auch die Herstellung und Einbindung eigener Erweiterungen sowie
die lizensierte Weiterverwendung der engine durch andere Hersteller.
Viele Hersteller veröffentlichen sogar ganze software development kits mit den selben Editoren und
Hilfsanwendungen, die auch vom Hersteller selbst für die Erstellung der Spielinhalte verwendet
wurden.
2.3 Fallbeispiele
Im Folgenden werden einige Beispiele für Mods gezeigt, anhand deren individuellen Eigenschaften
die zuvor eingeführten Begriffe näher erläutert werden. Die Beispiele in diesem Kapitel stammen
aus dem Genre der Ego-Shooter, da dieses, wie schon zuvor erwähnt, eine Art Vorreiter-Rolle in
der Unterstützung von Mods einnimmt.
2.3.1 Bekannte Mods
Das wohl bekannteste Mod ist die auf Half-Life basierende Total Conversion „Counter-Strike“. Sie
bietet neben eigenen Maps, Models, Waffen und Texturen auch einen völlig
neuen Spielmodus. Dieser beinhaltet die Auseinandersetzung zwischen zwei
Teams, den Terroristen und einer Anti-Terror Einheit. Während man je nach
Art der Map als Terrorist eine Bombe an einem festgelegten Zielort
deponieren bzw. Geiseln nehmen muss, versucht man in der Anti-Terror
Einheit, Bomben zu entschärfen bzw. Geiseln zu befreien. Der Gewinner
einer Runde erhält eine Belohnung in Form von Geld, welches über ein
Kaufen-Menü in neue Waffen und Ausrüstungsgegenstände investiert
werden kann. Dies verschafft gewinnenden Teams einen Vorteil in der
nächsten Runde. Ein derart komplexes Spielprinzip war im MehrspielerModus des Originalspiels Half-Life nicht enthalten.
Abbildung 1: Spielcover - Eine weitere bekannte Mod ist „Desert Combat“, eine Total Conversion des
Counter-Strike
Spiels Battlefield 1942, welches, wie der Name schon sagt, im 2. Weltkrieg
angesiedelt ist. Desert Combat [5] versetzt die Inhalte dieses Spiels in das 21. Jahrhundert.
Beispielsweise wurden Propellerflugzeuge durch Düsenjäger ersetzt.
Manche Mods sind bereits für mehrere Spiele erschienen. So zum Beispiel die Mod „Team
Fortress“ [4], welche neben neuen Maps und Models auch verschiedene neue Spielmodi im
5
Mehrspieler-Bereich einbringt, die ähnlich wie in Counter-Strike einen Wettstreit zwischen zwei
Teams vorsehen. Ein Beispiel dafür ist der wohl sehr bekannte Spielmodus „Capture the Flag“, bei
dem die Teams versuchen, die Flagge des jeweils anderen Teams in die eigene Basis zu überführen,
ohne die eigene Flagge zu verlieren. Ein weiterer Modus, involviert das einnehmen von Basen,
wobei das Team gewinnt, welches als erstes alle Basen einnehmen konnte. Des weiteren gibt es
anders als bei Counter-Strike mehrere Soldaten-Klassen wie z.B. Grenadier, Scharfschütze,
Sanitäter, Techniker und Spion, aus denen die Spieler wählen müssen. So ergibt sich eine
interessante Aufgabenteilung innerhalb der Teams.
All dies sind Mods, die man ohne es vorher zu wissen kaum von einem eigens entwickelten Spielen
unterscheiden kann. Obwohl diese Mods fast alle Inhalte ändern, zeigen sie jedoch lange nicht alle
Möglichkeiten der Modifikation auf. Hierfür lohnt es sich, einige unbekanntere Mods zu betrachten,
die weit ausgefallenere Änderungen aufweisen. Eine kleine Auswahl solcher Mods wird im
folgenden Abschnitt vorgestellt.
2.3.2 Half-Life
Das Spiel Half-Life ist eines der Spiele mit den meisten Mods überhaupt.
Es bat zu der Zeit seiner Veröffentlichung bereits eine sehr gute
Unterstützung für die Erstellung von Mods. Welche Möglichkeiten HalfLife hierzu bietet, wird in einem späteren Kapitel noch im Detail
besprochen. Diese Tatsache führte dazu, dass bereits früh Mods für dieses
Spiel verfügbar waren. Viele der zahlreichen Half-Life Mods sind
lediglich Partial Conversions des Hauptspiels, die sich auf die Änderung
ganz bestimmter Inhalte beschränken. Oft sind diese Änderungen sehr
ausgefallen und zeigen so eindrucksvoll, was im Bereich Modding alles
möglich ist. Anhand der folgenden Beispiele wird dies verdeutlicht.
Die Mod „Snow War Half-Life“ ändert das Spiel dahingehend, dass anstatt Abbildung 2: Spielcover sich mit Schusswaffen zu bekriegen, eine Half-Life
Schneeballschlacht veranstaltet wird. Die geworfenen Schneebälle müssen
zuvor auf einer Schnee-bedeckten Oberfläche aufgenommen werden. Dies
zeigt, wie einfach ein unterhaltsames Spielprinzip durch wenige
Änderungen realisiert werden kann. Wie man im Screenshot links sehen
kann, sind ebenfalls die Models geändert. Beispielsweise kann man das
Spiel in Gestalt eines Weihnachtsmann oder Schneemannes bestreiten.
Abbildung 3: Screenshot - Eine Mod, die mehr in die Richtung Rollenspiele
Snow War
abzielt, ist „Wizard Wars Half-Life“. In dieser
Mod werden Zaubersprüche und ähnliches als Waffen eingesetzt. Die
eigenen Maps bestehen aus mittelalterlicher Architektur und die Models
sind Zauberer. Im Bild links kann man ein Burg-Level sehen, in welchem
das Spiel stattfindet. Die Hände, die hier einen Totenschädel schweben
lassen, sind technisch gesehen nicht Teil des Models sondern gehören
zusammen mit dem Schädel zur Waffen-Geometrie. Dem so genannten Abbildung 4: Screenshot Wizard Wars
„Head Up Display“ kurz „HUD“, welches Daten des Spielers anzeigt
wurde hier ebenfalls ein neues Design verpasst.
Ein Beispiel für einen einfallsreichen Spielmodus ist die Mod „Science and
Industry Half-Life“, in der man versucht, Wissenschaftler in die eigene
Forschungseinrichtung zu entführen, wo diese für das eigene Team nach
besseren Waffen forschen. Wer mehr Wissenschaftler in seiner Gewalt hat,
besitzt dadurch einen Vorteil durch bessere Ausrüstung. Im Screenshot
links sieht man, wie der Transport der entführten Wissenschaftler in die
eigene Basis realisiert wurde. Da viele Inhalte wie Models und Texturen
Abbildung 5: Screenshot - aus Half-Life unverändert übernommen wurden, spricht man auch hier
Science & Industry
lediglich von einer Partial Conversion. Im folgenden abschließenden
6
Beispiel ist dies anders und es wurde fast alles geändert.
„Worms Half-Life“ ist eine Mod, welche das Spieldesign von dem
bekannten Spiel „Worms“ ab geschaut hat. Wie man auf dem Screenshot
sehen kann, wurde hier außer dem zugrunde liegenden Genre nichts
sichtbares übernommen. Die Models sind Würmer, welche sich dem
Vorbild entsprechend mit Waffen wie Dynamit bekriegen. Es gibt eigene
Maps mit eigenen Texturen und auch das Head Up Display wurde
angepasst.
Abbildung 6: Screenshot Worms Half-Life
2.3.3 Half-Life 2: Garry's Mod
Wie sein Vorgänger ist auch Half-Life 2 ein Spiel mit weitreichenden Modifikationsmöglichkeiten.
Das Ausmaß dieser Möglichkeiten zeigt sich eindrucksvoll in einer Mod namens „Garry's Mod“.
Diese Mod verwandelt das Hauptspiel in einen so genannten
Sandbox-Editor für das Spiel selbst. Ein Sandbox-Editor ist ein
Editor, der die Spiel-Engine benutzt, um geänderte Spielinhalte
nach dem WYSIWYG Prinzip genau wie im Spiel selbst
darzustellen. In Garry's Mod können Inhalte wie bewegliche
Objekte, Fahr- und Flugzeuge gebaut werden. Außerdem kann
die Physik beeinflusst werden und es gibt sogar die
Möglichkeit, Models via Ragdoll-Physik zu bearbeiten. Mit
diesen Möglichkeiten können bereits erstaunlich viele Dinge
realisiert werden. Besonders populär sind hierbei möglichst
ausgefallene Kettenreaktionsmaschinen, welche dann auf
Abbildung 7: Screenshot - Garry's Mod
Video-Plattformen wie http://www.youtube.com/ online
gestellt werden. Wer hier nach den Schlüsselwörtern „Garry's Mod“ oder „gmod“ sucht, wird
hunderte Videos von solchen Aufbauten finden, in denen zum Beispiel riesige Dominosteine in
einer Map aufgestellt werden durch die eine lange Kettenreaktion realisiert wird. Des weiteren
können aber auch noch steuerbare Vehikel erstellt werden. So werden oft aus fertigen Gegenständen
des Spiels wie Container und Reifen unter Verwendung von Physik-Tools ausgefallene Fahr- oder
Flugzeuge gebaut. Die Physik-Engine in Half-Life 2 ist sehr mächtig wodurch auch Dinge wie
Katapulte relativ einfach realisiert werden können.
3 Editing
Im Gegensatz zu den großen 3D-Modellierungsprogrammen wie Maya oder 3D-Studio MAX
beschränken sich die bei Spielen mitgelieferten Programme auf die Erstellung von Inhalten für nur
dieses spezielle Spiel. Daraus folgt, dass beim Erstellen von Inhalten bestimmte Eigenschaften der
Spiel-Engine und der genutzten Grafikhardware berücksichtigt werden müssen, um die Inhalte
überhaupt in das Spiel einbinden zu können. So darf z.B. eine maximale Anzahl von Lichtquellen
oder Polygonen nicht überschritten werden oder Texturen müssen Quadrate mit einer Zweierpotenz
als Seitenlänge sein. Diese Restriktionen können je nach Spiel-Engine und Ziel-Hardware variieren
und es ist oft nicht der Fall, dass Verstöße gegen diese Regeln von den Editoren abgefangen
werden. Man merkt so oft erst beim Test im Spiel, ob ein Inhalt lauffähig ist.
Des weiteren müssen erstellte Inhalte oft in spezielle Formate überführt werden, die meist auf
Effizienz im Spiel optimiert sind. Ein Beispiel dafür sind die „bsp“-Dateien, die z.B. In Half-Life
zum Einsatz kommen. Sie enthalten eine Map in Form eines BSP-Baumes (Binary Space Partition),
im den Zugriff auf die Geometrie während des Spiels zu beschleunigen. Da der Baum in der Datei
abgelegt wird, kann er vorher aufwendig optimiert werden, was durch spezielle Map-Compiler
7
realisiert wird. So kann es z.B. auch passieren, dass die eigene Map zu komplex ausgefallen ist und
der Kompiliervorgang mehrere Stunden in Anspruch nimmt. Dies ist dann meist auch ein Indiz
dafür, dass die Map im Spiel später nicht effizient laufen wird oder dass sie Fehler enthält. Mehr
dazu gibt es im Kapitel über Editoren. Zunächst werden aber typische Inhalte von heutigen Spielen
vorgestellt und anschließend ihre Strukturierung innerhalb der Spielarchitektur erläutert.
3.1 Inhalte
Die in heutigen Spielen vorkommenden Inhalte lassen sich in einigen wenigen Kategorien
zusammenfassen. Obwohl diese in verschiedensten proprietären Dateiformaten abgelegt sein
können, unterscheiden sie sich jedoch oft nur geringfügig von einander. Dies kann durch einige
Fakten der heutigen Spiele-Entwicklung begründet werden. Zum einen werden heute wenige SpielEngines für sehr viele Spiele wiederverwendet. Zum anderen legt die Tatsache, dass mit den
meisten Spielen die reale Welt nachgeahmt werden soll, eine ähnliche Strukturierung der
Spielinhalte nahe. Außerdem gibt auch die aktuelle Grafikhardware bereits einige Standards vor, die
ein Spiel heute benutzen muss. Im folgenden werden sowohl die Arten der Inhalte als auch deren
Strukturierung in modernen Spielen erläutert.
3.1.1 Arten von Spielinhalten
Wie bereits erwähnt, lassen sich die wichtigsten Spielinhalte heutiger Spiele in wenigen Kategorien
zusammenfassen:
Maps enthalten die mit reichlich Zusatzinformationen ausgestattete Geometrie der Spielwelt. Sie
beinhalten sowohl statische als auch dynamische Elemente der Welt. Der statische Anteil wird oft
fest als BSP-Baum gespeichert, was einen sehr Effizienten Zugriff auf die Welt-Geometrie während
des Spiels erlaubt. Dadurch können z.B. Dinge wie die Kollision von Objekten mit der WeltGeometrie sehr effizient berechnet werden. Die Speicherung der Maps als PSB-Baum erlaubt auch
eine aufwendige Vorberechnung eines möglichst optimalen Baumes. Hierfür werden spezielle MapCompiler verwendet, auf die im Kapitel über Editoren noch beispielhaft eingegangen wird. Maps
enthalten neben der Geometrie der Spielwelt auch eine Menge Zusatzinformationen, die sowohl
Teile der Spiellogik als auch Funktionen der Grafik- und Physikengines steuern können. Beispiele
hierfür sind Startpositionen für Spieler, Trigger-Mechanismen und Skripts.
Models sind Geometriedaten von Charakteren im Spiel, sowohl die der Spieler als auch die von
Gegnern und anderen CPU-gesteuerten Akteuren im Spiel. Neben der Geometrie enthalten ModelDateien meist auch die zugehörigen Texturen und ein Skelett-System inklusive Animationen für
verschiedene Verhaltens- und Bewegungsarten der Figur. Diese werden heute bereits oft mit Hilfe
von Motion-Capturing Verfahren erstellt.
Texturen sind zweidimensionale Bilder, die auf die dreidimensionale Geometrie projiziert werden,
um Details hinzuzufügen und einen realistischeren Eindruck zu erwecken. In modernen Spielen
werden sie jedoch nicht nur für diesen Zweck benutzt. Sie werden z.B. auch benutzt, um NormalMaps, Displacement-Maps, Shadow-Maps und vieles mehr zu speichern, welche alle einen spezielle
Rolle in der Erzeugung möglichst realistischer Bilder spielen.
Die in Spielen zu sehenden Menüs zur Auswahl von Spielmodi und zur Konfiguration des Spiels
sind letztendlich nur Grafiken, die von einer grafischen Oberfläche in das Spiel geladen werden.
Somit können diese meist leicht durch modifizierte Versionen ersetzt werden. In normalen
Applikationen wird dies auch als „skinning“ bezeichnet. Ähnlich verhält es sich mit Head Up
Displays, welche im Grunde durch die selbe Technik realisiert werden.
Je nach Spiel kann das Spielverhalten mehr oder weniger weitreichend alleine durch das Ändern
von Parametern in Konfigurationsdateien modifiziert werden. Eine bekannte Dateiendung hierbei
ist „ini“. Dinge die hier geändert werden können sind zum Beispiel Tastenbelegungen, die
Geschwindigkeit von Fahrzeugen, Schussfrequenzen von Waffen und vieles mehr.
8
3.1.2 Strukturierung von Spielinhalten
Ähnlich wie die Kategorien von Spielinhalten, ist auch die Strukturierung der Inhalte in den meisten
Spielen annähernd die selbe. Die Inhalte werden hierarchisch
in Verzeichnissen organisiert, wobei das Wurzelverzeichnis
den Namen der Mod besitzt. So kommt es, dass die Inhalte des
HauptHauptspiels technisch gesehen nichts anderes als eine Mod
spiel
sind. Man kann diese also als „Standard-Mod“ des Spiels
bezeichnen, deren Wurzelverzeichnis oft den Namen des
Hauptspiels oder des Herstellers besitzt. Diese InhaltsVerzeichnisbäume werden oft noch in ContainerDateiformaten gespeichert, die, wie z.B. pk3-Dateien der
Quake 3-Engine dem ZIP-Format ähneln. Diese Container
bringen einige Vorteile bei der Installation und der
Speicherung des Spiels auf der Festplatte. So läuft die Kopie
Mod
hunderter kleiner Dateien z.B. Deutlich langsamer ab als die
Kopie einer einzelnen Datei gleicher Größe und die zusätzliche
Komprimierung spart Speicherplatz sowohl auf dem
Abbildung 8: Verzeichnisbaum vom
Distributionsmedium als auch auf der Festplatte. Soll die
Spielinhalten
Engine des Spiels eine andere als die Standard Mod laden, so
muss diese entweder über die Kommandozeile als Parameter übergeben oder durch ein
Auswahlmenü des Hauptspiels aktiviert werden.
Will man also eigene Inhalte anstatt der Originalinhalte einstellen, muss man diese lediglich in der
gleichen Verzeichnisstruktur unter einem Wurzelverzeichnis mit dem Namen der eigenen Mod
ablegen. Das Mod-Auswahlmenü des Spiels wird dieses dann in der Regel selbst erkennen und zur
Auswahl anbieten. Die Struktur und die Namen der Unterverzeichnisse müssen exakt die selbe
Struktur und die selben Namen wie Der Verzeichnisbaum des Standard-Mods haben, da diese in der
Regel fest in der Engine kodiert sind. Dateien in den Ordnern, wie zum Beispiel Map-Dateien
müssen jedoch nicht unbedingt gleich benannt werden oder in der selben Anzahl auftreten, da diese
von der Engine dynamisch abgefragt und im Spiel zur Auswahl angeboten werden. Zumindest ist
dies im Mehrspieler-Bereich oft so. Will man eine Einzelspieler-Mod realisieren, gibt es je nach
Spiel und Genre unterschiedliche Konventionen, um zum Beispiel die Map für das erste Level
festzulegen. In manchen Genres wie zum Beispiel bei Rollenspielen kommt es auch vor, dass es
keine Einteilung in Maps gibt, da es im Spiel nur eine einzige große Spielwelt gibt, die auf eine
andere Weise realisiert ist.
Um das Modding an einem geeigneten Spiel auszuprobieren sind einfache Änderungen an den
Inhalten des Hauptspiels
am besten geeignet. Als
erstes muss man das
„Mods“-Verzeichnis
identifizieren.
Anschließend kopiert man
das
Standard-Mod
Verzeichnis unter einem
anderen
Namen,
z.B.
„MyMod“ in das selbe
Verzeichnis,
in
der
Abbildung links grün
Abbildung 9: Verzeichnisbaum - Partial
dargestellt. In Spielen, die
Conversion
ein Auswahlmenü für
Mods im Spiel anbieten, wird dieses jetzt in der Regel bereits
angezeigt. Aktiviert man es, wird allerdings nur die Standard- Abbildung 10: Verzeichnisbaum - Total
Mod geladen, da die Inhalte ja noch die selben sind. Um dies Conversion
9
zu ändern, sucht man sich jetzt z.B. eine Map-Datei (in der Abbildung hell-grün dargestellt) und
lädt sie in den passenden Editor, welcher dem Spiel im günstigsten Fall beiliegt. Die Möglichkeiten
von Änderungen hängen jetzt nur noch davon ab, wie gut man die Bedienung des Editors bereits
erlernt hat. Für die Spiele mit guter Unterstützung für Modding existieren im Internet oft zahlreiche
Tutorials für die Bedienung der mitgelieferten Editoren. Eine einfache Änderung wie das Wechseln
einer Wandtextur oder das Einfügen eines zusätzlichen einfachen Objekts lässt sich jedoch oft auch
ohne vorige Einarbeitung realisieren und anschließend im Spiel begutachten. So kann man nun
immer mehr Inhalte ändern, neue Inhalte hinzufügen und andere löschen bis nichts von
Originalinhalt mehr übrig ist, wie in der Abbildung rechts dargestellt. Das ist dann, zumindest auf
die Inhalte bezogen, eine Total Conversion.
3.2 Editoren
Im folgenden Abschnitt werden anhand einiger Beispiele mehrere typische Werkzeuge für das
Modding in Spielen bzw. Online-Welten vorgestellt.
3.2.1 Half-Life: Worldcraft / Hammer
Half-Life und auch sein Nachfolger Half-Life 2 sind Spiele mit einer hervorragender Unterstützung
für Modding. Deshalb werden die vom Hersteller veröffentlichten Editoren und Programme für die
Erstellung von Inhalten für diese Spiele hier als Beispiel vorgestellt.
Eines der wichtigsten Tools für das Modding in Half-Life 2 ist der Leveleditor Hammer, der zu
Half-Life 1 Zeiten noch unter dem Namen Worldcraft bekannt war. Dieser richtet sich wie die
meisten proprietären Editoren der Spieleentwickler mit seiner Funktionalität nach den
Möglichkeiten der Spiel-Engine. So weisen z.B. Texturen meist die Größe 512x512 auf. Außerdem
müssen fertige Maps in das BSP-Format konvertiert werden. Ist diese Konvertierung erfolgreich
abgeschlossen, sollte man eine lauffähige Map für Half-Life im BSP-Format vorliegen haben. Die
genannten Programme müssen im Editor ähnlich wie Compiler einer Programmierumgebung
eingebunden werden. Anschließend müssen noch die benutzten Texturen eingebunden werden.
Diese waren in Worldcraft gesammelt in Form einiger weniger WAD-Dateien abgelegt wie z.B. Die
Half-Life.wad Datei, die sich im Hauptverzeichnis des Spiels befand. Im Hammer Editor jedoch,
werden Texturen als spezielle Materialien behandelt und getrennt gespeichert.
Sind diese Einstellungen getätigt, kann man damit beginnen, seine eigenen Maps zu erstellen. Dafür
gibt es in Hammer zwei grundlegende Elemente: Brush-Entities und Point-Entities. Brush-Entities
können sowohl Grundprimitive wie Quader und Zylinder als auch komplexere Objekte oder Trigger
und Effekte sein. Point-Entities existieren nur in einem Punkt im Raum und unterteilen sich in die
drei folgenden Unterkategorien:
•
Logic Entities: Unsichtbare Entities, die Aspekte des Spiels wie z.B. die künstliche
Intelligenz beeinflussen.
•
Prob Entities: Nicht lebende Objekte, die Models für ihre Erscheinung verwenden können
und diesen ein bestimmtes Verhalten, z.B. das eines Vehikels zuweisen.
•
NPC Entities: NPC steht für Non Player Character. NPC Entities repräsentieren Computer
gesteuerte Charaktere wie z.B. Gegner und besitzen eine vordefinierte künstliche
Intelligenz.
Will man eine funktionstüchtige Map erstellen, sollte man wissen, wie Größenangaben in Half-Life
interpretiert werden. Die Größe von Objekten wird in so genannten „World Units“ gemessen. So ist
eine normale Wand z.B. 128 World Units hoch und eine Spielfigur 72 World Units. Also müssen
Türen, durch die man aufrecht gehen können soll auch mindestens 72 World Units groß sein. Bei
den 128x128 Pixel großen Texturen aus Half-Life 1 entsprach ein Pixel in der Textur einer World
Unit. Im Hammer Editor sind es durch die größeren Texturen 4 Pixel pro World Unit.
Mit diesen grundlegenden Informationen zu Map-Editing in Half-Life sollten bereits gute Resultate
erzielbar sein. Wer mehr über den Hammer Editor lernen möchte, kann sich im Valve Developer
10
Center die offizielle Dokumentation so wie eine Dokumentation zu Level Design anschauen. [6],
[7], [8], [9]
3.2.2 Modding in Second Life
Als Beispiel für Modding in einer Online-Welt sollen die Möglichkeiten hierzu in Second Life
erläutert werden. Da in Online-Welten nur eine Welt für alle Beteiligten existiert, die konsistent auf
zentralen Servern gehalten wird, unterscheidet sich Modding in
einigen Aspekten von dem, was bisher erläutert wurde. So ist
Modding in Online-Welten mehr als ein Leistungsmerkmal des
Programms zu sehen, welches von jedem Nutzer in Anspruch
genommen werden können soll. Die Editoren sind größtenteils
in die Engine der Online-Welt integriert und werden so zu
einem Teil des Online-Lebens. Außerdem sind die möglichen
Änderungen an der Welt an sich auf kleine Bereiche pro
Nutzer beschränkt, um die Welt im Großen und Ganzen in
einem vernünftigen Zustand zu halten.
Ein Beispiel für das integrierte Editieren von Inhalten sind die
Editoren, die den Nutzern zur Verfügung stehen, um den
eigenen Avatar zu modifizieren. Hier können z.B. die Form,
Abbildung 11: Screenshot - Second Life
die Haut, die Haare (siehe Abbildung links), die Augen und die
Editor
Kleidung des Avatars bearbeitet werden, was ein integraler
Bestandteil des Konzepts der Online-Welt ist, da es eine fast uneingeschränkt individuelle
Repräsentation der Nutzer in der Welt ermöglicht.
Eine weitere Möglichkeit, die Welt zu ändern, sind selbst erstellte Objekte. Auf der Website von
Second Life finden sich Videos, die eindrucksvoll demonstrieren, wie sehr komplexe Objekte in
sehr wenig Zeit gebaut werden können. In einem Video im Showcase der Seite war z.B. zu sehen,
wie eine in wenigen Minuten eine detaillierte Gitarre erstellt wurde. Die Tatsache, dass hergestellte
Objekte in der Online-Welt verkauft werden können, eröffnet sogar die Möglichkeit, mit dieser Art
von Modding Geld zu verdienen.
Zu guter Letzt gibt es in Second Life die Möglichkeit, ein Stück Land zu erwerben, auf dem man
dann ein Haus bauen kann. Durch kooperatives Bauen können
hier auch mehrere Nutzer an einem großen Objekt
zusammenarbeiten. Das Stück Land kann interessanterweise
auch eine Insel im Meer sein. In diesem Fall kann man
entweder aus einigen vorgefertigten Landschaften wählen, oder
aber seine eigene Geometrie in Form eines so genannten
„Terrain File“ einschicken. Die Landschaft in Second Life ist
durch ein Gitter von Höhenwerten realisiert. Durch diese feste
Topologie lassen sich Landschaften in einem Bild mit
mehreren Kanälen speichern, wobei jedes Pixel Informationen
für einen Knotenpunkt im Gitter enthält. Die insgesamt 13
Kanäle enthalten alle Informationen, die für die Engine wichtig
sind.
Abbildung 12: Screenshot - Second Life
Insel
Ein paar der Kanäle sind im folgenden aufgelistet:
•
1: Height (Höhe der Landschaft in diesem Gitterpunkt)
•
3: Water Height (Wasserspiegel in diesem Gitterpunkt)
•
5: For Sale (Das Land ist zu verkaufen)
•
7: Public Edit Land (Das Land darf von jedem verändert werden)
•
9: Flying Allowed (Das Land darf überflogen werden)
Wie man sehen kann, wird hier mit einem sehr einfachen Prinzip eine umfangreiche Änderung der
11
Welt ermöglicht. [12]
4 Scripting
Im Gegensatz zu kompilierten Sprachen, werden Scripts zur Laufzeit interpretiert. Diese werden
manchmal aus Effizienzgründen vorher in einen Bytecode kompiliert, welcher dann anstelle des
Script-Codes von einer Virtual Machine innerhalb des WirtProgramms interpretiert wird. Scripts sind also plattformunabhängig und können ohne eine Änderung am WirtProgramm geändert werden. Diese Eigenschaft machen sich
Spiele heute zunutze, um möglichst viele Aspekte des Spiels
ohne eine Neu-Kompilierung der Spiel-Engine realisieren zu
können. Diese Aspekte umfassen z.B. Teile der Spiellogik, der
KI und der Physik. Außerdem können Aufgaben wie
Menüführung, Inventar-Verwaltung, Ereignisbehandlung und
-auslösung und vieles mehr in Form von Scripts implementiert
werden. Dies erleichtert auch die Kollaboration in großen
Entwickler-Teams, wie sie heute bei kommerziellen Spiel- Abbildung 13: Kompilierte Sprachen und
Projekten üblich sind, da z.B. Designer bei ihrer Arbeit nicht Skriptsprachen im Vergleich
mit dem in der Regel in C++ geschriebenen Sourcecode der Spiel-Engine in Berührung kommen.
Da der Sourcecode kommerzieller Spiel-Engines nur in den seltensten Fällen und auch dann oft erst
nach einigen Jahren offen gelegt wird, ermöglichen Scripts auch Mod-Entwicklern eine Vielzahl
von Änderungen, die sonst nur durch Modifikationen des selben möglich wären. [10]
4.1 Beispiele für Skriptsprachen
4.1.1 QuakeC
Quake war eines der ersten Spiele mit der Unterstützung für Scripting. Die zugehörige
Skriptsprache QuakeC wird durch den Compiler „qcc“ in einen Bytecode vorkompiliert, der dann
von einem Bytecode-Interpreter im Spiel verarbeitet wird. Die Syntax ist der kompilierten Sprache
C nachempfunden wodurch sich auch die Analogie zum C-Compiler „gcc“ erklärt. Die
Möglichkeiten der Sprache waren damals noch sehr begrenzt. So konnten z.B. keine Typ- oder
Variablendefinitionen vorgenommen werden und „entity“ war der einzige Referenz-Typ (Entities
sind Objekt im Spiel). Außerdem wurden alle Strings in einem einzelnen String-Buffer gespeichert,
was z.B. Funktionen, die mit zwei String-Argumenten gleichzeitig arbeiten, unmöglich macht. Des
weiteren fehlen der Sprache jegliche Ein-/Ausgabefunktionen.
Trotz der oben genannten Beschränkungen war mit der Sprache bereits einiges möglich. So konnte
das Verhalten von Waffen, Aspekte der Spiellogik, die Spielphysik und Teile der künstlichen
Intelligenz beeinflusst werden. Außerdem konnten Ereignisse im Spiel ausgelöst werden. [11]
4.1.2 Python
Ein Beispiel für eine bekanntere Skriptsprache ist Python. Sie ist sehr weit verbreitet,
was unter anderem an ihrer leichten Erlernbarkeit liegt. Sie bietet des weiteren auch
die Möglichkeit der Erweiterung mit C-Bibliotheken, was auch die Einbindung
hocheffizienter Algorithmen ermöglicht. Die Popularität dieser Sprache erkennt man
am besten an den Anwendungen, welche sie benutzen. Dies sind, nur um einige unter
vielen zu nennen, die 3D-Editoren Blender und Maya, das Bildbearbeitungsprogramm
GIMP sowie das bekannte Spiel Battlefield 2.
12
4.1.3 Python in Blender
Der 3D-Editor Blender hat einen
eingebauten Python-Interpreter und
kann somit durch Scripts gesteuert
Abbildung 14: Die Symbolleiste des File Windows von Blender
werden. Um ein Python-Script in
Blender zu laden, kann man im Text-Window über das File-Menü eine Script-Datei öffnen. Die
Symbol-Leiste des Text-Windows ist links abgebildet, über das Auswahlmenü rechts können
verschiedene geladene Scripts selektiert werden. Das Script
wird durch Betätigen der Tastenkombination ALT-P
ausgeführt. Da Scripts in Blender immer Zugriff auf alle
globalen Objekte und Funktionen des Editors haben, können so
z.B. Animationen erstellt, Verformungen ausgeführt und
spezielle Objekte erzeugt werden. Wie man im Screenshot
recht sieht, können Scripts die grafische Oberfläche von
Blender nutzen, um z.B. Parameter einzulesen. Mit dem Script
in der Abbildung kann ein gefülltes Polygon mit variabler Abbildung 15: Beispiel für ein Skript,
Anzahl von Kanten erstellt werden, wobei alle Eckpunkte auf dass die Blender Oberfläche benutzt
dem Kreis mit dem eingestellten Radius liegen.
In der Abbildung links ist ein Beispiel-Script zu sehen, welches ein in Blender geladenes Objekt
namens „Plane“ um 0.5 Einheiten auf der X-Achse
# python example - move a plane:
verschiebt und es um 0.2 Einheiten um die Z-Achse
rotiert. Als erstes wird Blender mit dem import Befehl
import Blender
eingebunden. Blender kann nun als statisches Objekt
verwendet werden. Ein Objekt in Blender ist ein
Datensatz mit Positions- und Größenangaben eines
object = Blender.Object.Get("Plane")
bestimmten 3D-Objekts. Will man nun ein
vorhandenes
Objekt
bestimmten
Namens
object.LocX += 0.5
modifizieren,
kann
man
dies
mit
dem
Befehl
object.RotZ += 0.2
Blender.Object.Get(„<Name>“) tun, der eine Referenz
auf das Objekt zurück gibt. Mit dieser Referenz kann
Blender.Redraw()
man nun alle Felder des Object-Datensatzes # python example - change focal length:
ändern. Im Beispiel werden die Felder LocX (XKoordinate) und RotZ (Rotation um die Z- import Blender
Achse) geändert. Anschließend wird die
Oberfläche von Blender mit dem Redraw-Befehl camera = Blender.Camera.Get("Camera")
neu gezeichnet, um die Änderungen sichtbar zu
machen. Im nächsten Beispiel, das rechts camera.Lens = cam.Lens * 2.0
abgebildet ist, wird die Brennweite einer
Kamera namens „Camera“ auf ähnliche Weise
Blender.Redraw()
verändert. Der einzige Unterschied hierbei ist,
dass das Feld „Lens“ für die Brennweite nicht Teil des Object-Datensatzes ist, sonder zum CameraDatensatz gehört. Deshalb wird anstatt dem Befehl Blender.Object.Get(„<Name>“), der Befehl
Blender.Camera.Get(„<Name>“) verwendet, welcher eine Referenz auf den Camera-Datensatz
zurück gibt. Diese kann nun wie im obigen Beispiel modifiziert werden. Anschließend wird auch
hier die Oberfläche neu gezeichnet. Diese Unterscheidung zwischen Objects, Cameras und noch
einigen weiteren Objekten ist wichtig für das Verständnis des internen Objekt-Modells von Blender.
Man muss dieses von einem echten objektorientierten Modell unterscheiden, da Camera nicht von
Object ableitet, sondern stattdessen mit einem Object-Datensatz verknüpft ist, welcher z.B. auch mit
anderen 3D-Objekten geteilt werden kann. Andererseits kann eine Camera auch mehrere Objects
haben, welche im Editor als Duplikate der Camera in Erscheinung treten.
13
// LSL Beispiel:
default
{
state_entry()
{
llSay(0, "Hello, Avatar!");
}
}
4.1.4 Scripting in Second Life: Linden Scripting Language
Auch in Second Life gibt es die Möglichkeit, Scripts
einzusetzen. Hier geschieht dies mit der so genannten Linden
Scripting Language, einer Skriptsprache, die eigens für Second
Life entwickelt wurde. Sie basiert auf Zuständen und
Ereignissen. So können mehrere Zustände deklariert werden,
welche Handler-Funktionen für alle möglichen Ereignisse in
der Welt enthalten. Innerhalb dieser Handler-Funktionen kann
sowohl die gewünschte Funktionalität implementiert, als auch
in einen anderen Zustand gewechselt werden. Beim Eintritt in einen Zustand wird die
„state_entry“-Funktion aufgerufen und der Standard-Zustand trägt bezeichnender Weise den Namen
„default“. In der Abbildung links ist ein einfaches „Hello World“-Script dargestellt. Dieses Script
kann z.B. an ein Objekt im Spiel gebunden sein, welches dann in diesem Fall bei seiner Erzeugung
den Satz „Hello, Avatar!“ von sich gibt.
Mit der Linden Scripting Language können sogar sehr fortgeschrittene Dinge wie PhysikSimulationen implementiert werden. Außerdem gibt es
die Möglichkeit, ein Partikelsystem zu erzeugen und default {
touch_event() {
zu steuern. Dies geschieht mit der llParticleSystemllParticleSystem( [
Funktion wie im Beispiel rechts dargestellt. Diese
Funktion erhält ihre Parameter in einer Liste, welche
PSYS_PART_FLAGS, // =
Paare von Parameter-Name und Parameter-Wert
PSYS_PART_EMISSIVE_MASK,
enthält. Diese Übergabesemantik wird im Beispiel
PSYS_SRC_PATTERN, // =
durch die „=“-Zeichen in den Kommentaren
PSYS_SRC_PATTERN_EXPLODE,
verdeutlicht. Im Gegensatz zum letzten Beispiel wird
PSYS_PART_START_COLOR, // =
hier nicht die
<1,0,0>
„state_entry“-Fun
] );
ktion sondern die
}
„touch_event“}
Funktion
implementiert.
Das Partikelsystem wird also bei einer Berührung mit dem
Objekt ausgelöst. Will man das Partikelsystem ändern oder
Abbildung 16: Screenshot - Second Life
Partikelsystem in Aktion
ganz abschalten, muss man die selbe Funktion mit einer
entsprechend geänderten beziehungsweise leeren Liste „[]“ aufrufen. Das Resultat dieses Scripts
kann im Screenshot links begutachtet werden. Das schwebende Objekt wurde gerade von einem
Avatar berührt. [12], [13], [14]
4.2 Programmierung von 3D-Objekten
Der folgende Abschnitt behandelt die Programmierung von 3D-Objekten, wie sie vor allem beim
Modding von Spielen benötigt wird. Es wird hierbei nicht auf eine bestimmte Programmier- oder
Skriptsprache eingegangen, sondern stattdessen die grundlegenden Konzepte der Programmierung
in 3D-Umgebungen vermittelt.
4.2.1 Programmierung in 3D-Umgebungen
Bei der Programmierung in 3D-Umgebungen wie Spielen kommen ganz bestimmte Aufgaben auf
einen zu, die im Folgenden erläutert werden. Als einfachstes Beispiel können Objekte natürlich ihre
Position ändern. Man kann sie beliebig oft erzeugen, platzieren, verschieben, orientieren und wieder
14
löschen. Des weiteren kann man sie animieren und mit der Spiellogik verknüpfen. Wie oben im
Beispiel zur Linden Scripting Language gesehen, können Effekte wie Partikelsysteme erzeugt und
gesteuert werden. Dann gibt es die Möglichkeit, physikalische Abläufe wie Fahrphysik oder
Kollisionserkennung zu programmieren. Bezogen auf die Spiellogik müssen z.B. Inventare
verwaltet und Ereignisse behandelt oder ausgelöst werden. Dies sind nur einige Beispiele für die
vielfältigen Möglichkeiten, die einem bei der Programmierung in 3D-Umgebungen zur Verfügung
stehen.
4.2.2 Spezielle 3D-Objekte
Die Programmierung von 3D-Objekten, vor allem im Bereich Modding in Spielen, erfordert die
Kenntnis einiger spezieller Objekte, welche in Spielen Verwendung finden. Diese werden im
folgenden erläutert.
Kameras sind ein wichtiger Bestandteil eines jeden Spiels. Obwohl man sie nicht sieht, sind sie
doch immer vorhanden. Das man sie nicht sieht, liegt darin, dass man als Spieler selbst so zu sagen
in der Kamera ist und durch sie in die Spielwelt hinaus schaut. Kameras
projizieren die dreidimensionale Welt auf eine zweidimensionale
Bildebene, um die Darstellung auf zweidimensionalen Medien wie
Monitoren zu ermöglichen. In Spielen sind oft mehr Kameras vorhanden
als man denkt. Ein gutes Beispiel hierfür sind Rennspiele, bei denen man
zwischen verschiedenen Perspektiven umschalten kann. Hier ist für jede
Abbildung 17: Kamera
Perspektive eine Kamera vorhanden, die an das Auto gebunden sind und
sich so mit dem Auto bewegen. Schaltet man also in eine andere Perspektive, macht das Spiel nichts
anderes als auf eine andere Kamera zu schalten. Mit Kameras kann man aber noch mehr machen als
nur verschiedene Sichten des Spielers in die Welt bereitzustellen. Ist im Auto ein Rückspiegel, so
ist dieser in der Regel nur eine nach hinten gerichtete Kamera, deren Bildebene auf den Rückspiegel
gelegt wird. So kann mit einer Kamera ein einfacher Spiegel realisiert werden.
Moderne 3D-Spiele bieten in der Regel eine Möglichkeit, 3D-Szenen zu
beleuchten. Dies geschieht durch dir Platzierung von Lichtquellen in der
Szene. Diese können neben der normalen Beleuchtung auch für die
Realisierung dynamischer Lichteffekte genutzt werden. Grafikkarten
unterstützen in der Regel eine bestimmte Anzahl
dynamischer Punktlichtquellen, an die sich ein Abbildung 18: Lichtquelle
Leveldesigner oder Skript-Programmierer halten muss.
Ein wichtiges und sehr mächtiges Konzept zur Auslösung von Ereignissen
in Spielen sind so genannte „Trigger“. Trigger bieten Mechanismen zur
Auslösung und Steuerung von Ereignissen im Spiel. Ein Trigger ist ein
spezielles, meistens unsichtbares 3D-Objekt, das durch einen bestimmten
Vorgang im Spiel aktiviert wird und daraufhin weitere Ereignisse auslösen
Abbildung 19: Trigger
kann. Ein Beispiel für einen Trigger ist eine unsichtbare Box, die bei
Berührung durch die Spielfigur ein Ereignis, wie z.B. das Öffnen einer Türe, oder allgemeiner, die
Aktivierung eines Scripts, auslöst. Dieses Konzept wird zum Beispiel auch von den Half-Life
Editoren verwendet.
Neben Lichtquelle gibt es in Spielen oft noch andere speziellere Möglichkeiten, optische Effekte zu
realisieren. Ein Beispiel hierfür sind die bereits behandelten Partikelsysteme.
Was wäre ein Spiel ohne Ton? Soundeffekte werden in Spielen oft an 3D-Objekte gebunden. So
kann z.B. dem Boden an einer Stelle ein bestimmter Auftritts-Ton zugewiesen werden oder der
Knall einer Explosion kann an einer bestimmten Stelle platziert und mit einem Wirkungsbereich
versehen werden.
15
Ein weiteres wichtiges Objekt sind Pfade. Mit Pfaden lassen sich Objekte
animieren. Aufzüge und Schienenbahnen sind z.B. häufig an einen Pfad
gebunden, welchen sie, möglicherweise durch ein Trigger-Objekt ausgelöst,
entlang fahren.
Models werden in modernen Spielen mit der Hilfe von Skeletten animiert.
Skelette beschreiben die Knochenstruktur des Models und somit seine
Bewegungsmöglichkeiten. Sie werden heute auch oft mit der Physik-Engine
verknüpft, um so genannte Ragdoll Physics zu realisieren. Hierbei werden
Skelette anhand ihrer Constraints möglichst realistisch animiert. So können z.B.
Die Auswirkungen eines Schusses auf ein Model an einer bestimmten Stelle Abbildung 20:
Skelett
simuliert werden,
Ein schon etwas älteres aber immer noch verwendetes Konzept sind so genannte Sprites. Sprites
sind zweidimensionale Bilder, die im dreidimensionalen Raum orientiert sind. Damit wurden in
älteren Spielen teilweise ganze Bäume dargestellt. Durch die Orientierung dieser Bilder in Richtung
der Kamera entstand so eine Art pseudo-3D-Effekt. In neueren Spielen werden in der Regel nur
noch kleinere Objekte wie Grashalme oder Baumblätter mit Sprites dargestellt.
4.2.3 Modifizieren von 3D-Objekten
3D-Objekte können auf verschiedene Arten modifiziert werden. Als erstes kann man ihre Punkte
affinen Transformationen unterziehen, also Translationen, Rotationen,
Scherungen und vieles mehr. Des weiteren kann der Schnitt zweier Objekte
ermittelt werden, was z.B. bei der Kollisionserkennung gebraucht wird.
Anhand dieser Daten können nun boolesche Operationen ausgeführt werden,
wobei z.B. nur der Teil des einen Objektes übrig bleibt, der
nicht in der Schnittmenge der beiden Objekte liegt. Dies
kann z.B. für die Realisierung eines Schadensmodells in
einem Rennspiel verwendet werden. Schließlich kann man
natürlich auch das Material eines Objekts beeinflussen,
indem man das Objekt z.B. mit einer Textur und einer
Normal-Map belegt. Mögliche Materialeigenschaften Abbildung 22:
Abbildung 21: Affine
können je nach Spiel-Engine und Hardware variieren. Das Schnitt zweier
Transformationen
waren
die
wichtigsten
essentiellen Objekte
Modifikationsmöglichkeiten von 3D-Objekten, mit denen bereits ein großer Teil der Funktionalität
eines Spiels realisiert werden kann.
4.3 Beispiele
Die folgenden Beispiele stellen jeweils lediglich eine Möglichkeit unter vielen dar, die beschriebene
Funktionalität zu realisieren. Die tatsächlich verwendeten Mechanismen könne je nach Spiel sehr
unterschiedlich sein. Die jeweiligen Mechanismen werden durch Bilderfolgen illustriert. Die
Abfolge ist immer von links nach rechts und von oben nach unten. Die folgenden Bilder wurden
selbst mit dem Programm OpenOffice Impress erstellt.
16
4.3.1 Türe
Um eine sich öffnende Türe zu realisieren, können die folgenden Schritte ausgeführt werden. Als
erstes wird eine Trigger-Box um die Türe platziert. Dann muss die Drehachse der Türe festgelegt
werden. Berührt nun die Spielfigur die Trigger-Box, wird die „öffnen“-Animation für die Türe
ausgelöst. Optional kann auch ein Script gestartet werden, das z.B. vorher überprüfen kann, ob die
„öffnen“-Taste betätigt wurde oder das Inventar einen Schlüssel für die Tür enthält.
4.3.2 Portal
Ein weiteres einfaches Beispiel ist die Erstellung eines Portals. Auch hier kann man eine TriggerBox, die im Portal platziert ist verwenden, um das eigentliche Ereignis des Ortwechsels der
Spielfigur auszulösen. Schneidet die Geometrie der Spielfigur die Trigger-Box, so wird die
Spielfigur an den festgelegten Zielort (in der Bildfolge als roten Kreis markiert) verschoben.
17
5 Quellenangaben
5.1 Bilder
[Abbildung 1] http://blog.sabinechristiansen.de/wp-content/uploads/2006/11/cs.jpg
[Abbildung 2] http://ec1.images-amazon.com/images/I/51SYKC2DHEL._AA280_.jpg
[Abbildung 3] http://www.hlportal.de/images/images/medium/3815.jpg
[Abbildung 4] http://www.hlportal.de/images/images/original/1258.jpg
[Abbildung 5] http://www.hlportal.de/images/images/original/1551.jpg
[Abbildung 6] http://www.hlportal.de/images/images/medium/941.jpg
[Abbildung 7] Screenshot aus dem Video http://www.youtube.com/watch?v=3rkG-3man3k
[Abbildung 8] Selbst in OpenOffice Impress erstellt
[Abbildung 9] Selbst in OpenOffice Impress erstellt
[Abbildung 10] Selbst in OpenOffice Impress erstellt
[Abbildung 11] http://www.second-life.com/
[Abbildung 12] http://secondlife.com/community/land-islands.php
[Abbildung 13] Selbst in OpenOffice Impress erstellt
[Abbildung 14] http://www.blender.org/documentation/htmlI/PartEX/python/gfx/textButtons.pn
g
[Abbildung 15] http://www.blender.org/documentation/htmlI/PartEX/python/gfx/python_demo
_gui.png
[Abbildung 16] http://www.kan-ed.org/second-life/graphics/avatar-next-to-generator2.jpg
[Abbildung 17] Selbst in OpenOffice Impress erstellt
[Abbildung 18] Selbst in OpenOffice Impress erstellt
[Abbildung 19] Selbst in OpenOffice Impress erstellt
[Abbildung 20] Selbst in OpenOffice Impress erstellt
[Abbildung 21] Selbst in OpenOffice Impress erstellt
[Abbildung 22] Selbst in OpenOffice Impress erstellt
5.2 Informationen
[1] Artikel „Video game companies encourage modders“
http://www.hollywoodreporter.com/hr/search/article_display.jsp?vnu_content_id=10004849
56
[2] Artikel „The Top 5 Most Moddable Games“
http://www.bit-tech.net/gaming/2007/06/12/top_5_moddable_games/1
[3] Wikipedia Artikel zu „Mod“
http://en.wikipedia.org/wiki/Mod_(computer_gaming)
[4] Wikipedia Artikel zu „Team Fortress”
http://de.wikipedia.org/wiki/Team_Fortress#Team_Fortress_Classic
[5] Wikipedia Artikel zu „Desert Combat“
http://en.wikipedia.org/wiki/Desert_Combat
[6] Tutorial zum Worldcraft Editor
http://www.dhlp.de/
[7] Wikipedia Artikel zu „Hammer Editor“
http://de.wikipedia.org/wiki/Hammer_Editor
[8] Valve Developer Community Wiki
http://developer.valvesoftware.com/wiki/Main_Page
[9] Dokumentation zu Valve's Hammer Editor
http://developer.valvesoftware.com/wiki/Valve_Hammer_Editor
[10] Wikipedia Artikel zu „Scripting language“
http://en.wikipedia.org/wiki/Scripting_language
18
[11] Wikipedia Artikel zu „QuakeC“
http://en.wikipedia.org/wiki/Quakec
http://de.wikipedia.org/wiki/QuakeC
[12] Website von Second Life
http://www.secondlife.com/
[13] Wikipedia Artikel zu „Linden scripting language“
http://en.wikipedia.org/wiki/Linden_Scripting_Language
[14] Tutorial „Using the Linden Script Language“
http://www.kan-ed.org/second-life/using-LSL.html
19