docSeminar Game Development Engines and Middleware
download 
Plainte Transcription
Seminar Game Development Engines and Middleware
Seminar Game Development Engines and Middleware Robert Krause 1005528 12. Juni 2007 Aufgabensteller: Prof. Dr. Uwe Borghoff Betreuer: Dipl.-Inform. Daniel Volk Institut für Softwaretechnologie Fakultät für Informatik Universität der Bundeswehr München INHALTSVERZEICHNIS 3 Inhaltsverzeichnis 1 Einleitung 5 2 Entwicklungsprozess 7 2.1 Wiederverwendung . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2 Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3 Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3 Aufbau und Architektur einer Game-Engine 11 3.1 Typisierung und Kategorisierung . . . . . . . . . . . . . . . . 11 3.2 Arbeitsweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.3 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4 Besonderheiten im Spieleentwicklungsprozess 17 4.1 Engineauswahl . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.2 Engine-Skripting . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.3 Cross-Platform-Development . . . . . . . . . . . . . . . . . . 20 5 Ausblick 21 4 INHALTSVERZEICHNIS 5 1 Einleitung Aus einem langen Entwicklungsprozess entstanden und von den großen Gedanken der Wiederverwendung und Abstraktion getragen, sind Engines und Middleware heutzutage nicht mehr aus dem Bereich der Softwareentwicklung, insbesondere der Spieleentwicklung, wegzudenken. Engines und Middleware nehmen Spieleherstellern einen großen Teil doppelter Arbeit ab, da auf bereits programmierten Quellcode zurückgegriffen wird und bieten durch eine geschickte Softwarearchitektur den Spieledesignern die Möglichkeit sich auf den wesentlichen, kreativen Anteil zu konzentrieren, auch ohne technisches Fachwissen über Computer besitzen zu müssen. Selbst durch unbezahlte Hobbyprogrammierer entstehen und verbessen sich inzwischen fortlaufend frei erhältliche Softwareprodukte, bei denen der Quellcode offen liegt und die ihren kommerziellen Konkurrenzprodukten in nichts nachstehen. Diese Seminararbeit soll die Entstehung, den Aufbau und die Integration von Engines und Middleware mit Bezug auf den Spieleentwicklungsprozess behandeln. Dazu soll zunächst von der allgemeinen Softwareentwicklung ausgegangen und die Motivation zur Entwicklung der Engines und Middleware beschrieben werden. Im Anschluss wird die Funktionsweise und Architektur der Spiele-Engines erklärt und das Vorgehen eines Spieleherstellers während der Entwicklung eines Computerspiels näher beschrieben. Als Teil des Seminars ”Game Development” ist diese Seminararbeit in Zusammenhang mit weiteren Seminararbeiten zu sehen, deren Inhalt gegenbebenfalls als Wissen vorausgesetzt werden kann. Entstanden ist sie nach einer mehrwöchigen Phase der Literaturstudie, bei der auffallend war, dass jede Quelle Game-Engines und Game-Middleware unterschiedlich beschreibt und es keine feste, wissenschaftliche Definition dazu zu geben scheint. Deshalb habe ich versucht, die für mich treffendste Beschreibung zu finden und eine klare Abgrenzung zu erarbeiten, die beim fortlaufenden Lesen erkenntlich werden sollte. 6 1 EINLEITUNG 7 2 Entwicklungsprozess Im Folgenden soll zunächst auf die Entwicklung von Middleware und Engines und den Grundgedanken der Wiederverwendung eingegangen werden. 2.1 Wiederverwendung Software wurde früher von Teams aus wenigen erfahrenen Programmierern entwickelt. Diese mussten detailiertes Wissen über Hardware und Betriebssystem besitzen und erstellten Programme ”aus einem Guss” mit fest im Quelltext verdrahteten Funktionalitäten. Wenn nun neue, ähnliche Software entwickelt oder bestimmte Leistungsmerkmale vorhandener Software übernommen werden sollte, wurde mit der Programmierung immer wieder bei Null angefangen - ”das Rad wurde neu erfunden”. Im Rahmen wachsender Software-Komplexität und steigender Qualitätsansprüche erkannte man die Notwendigkeit einer grundlegenden Änderung in der Software-Entwicklung. So wurde im Jahr 1967 der Begriff des ”Software Engineering” als ein Teilgebiet der Informatik ins Leben gerufen, das unter anderem das Gebiet der ”Software-Wiederverwendung” umfasste. Die Idee ist, ”gewonnene Ergebnisse und Erfahrungen aus vorhergegangenen Software-Projekten in neuen Projekten wiederzuverwenden und so schrittweise systematisch zu verbessern” [Bec96, S. 9]. Um vorhandenen Problemen wie • schwer absehbarer Entwicklungszeit und Entwicklungskosten • mangelnder Qualität wegen ständiger Neuentwicklung • schlechte Überschaubarkeit bei größeren Projekten • Bedarf an Expertenwissen über Hardware und Betriebssystem zu entgehen, entwickelte man Methoden wie • Quelltextgeneratoren • Bibliotheken und Toolkits • Frameworks , auf die ich im Folgenden noch etwas genauer eingehen möchte. 8 2 ENTWICKLUNGSPROZESS Quelltextgeneratoren Quelltextgeneratoren stellen einen ersten Schritt in Richtung Wiederverwendung dar. Sie beruhen auf dem Ansatz des ”Copy&Paste”1 und erzeugen nach Vorgabe bestimmter Spezifikationen Quelltext für einen bestimmten Anwendungsbereich. Die Idee ist, Quelltext, der im Großteil für ähnliche Aufgaben gleich bleibt, zusammen zu fassen und nur die Abweichungen im Generator zu definieren. Als Beispiel kann man sich das Öffnen einer Datei vorstellen. Der Quelltextgenerator erzeugt hier den nötigen Code um das Betriebssystem bzw. die Hardware die Datei öffnen zu lassen, der ja bei jedem Dateiöffnungsprozess identisch ist. Dynamische Anteile wie zum Beispiel der Dateiname werden im Generator angegeben und dann automatisch im Quelltext eingebettet. Bibliotheken und Toolkits Fasst man den oft verwendeten und jedes mal fast identischen Quelltext nun in Blöcke zusammen und kapselt sie vom eigentlichen Programm ab (Modularisierung), so entstehen Bibliotheken und Toolkits. Allgemein kann sie als ”Sammlungen programmiersprachlicher Module, Klassen, Funktionen und Methoden, die gemeinsam eine Basisfunktionalität bereitstellen” [Lin99, S. 53], bezeichnen. Bibliotheken schaffen Transparenz, da sie zugrunde liegende Funktionalitäten verbergen und bieten so Programmierern die Möglichkeit, bereits vorhanden Quellcode mittels klar definierter Schnittstellen in ihre Programme einzubinden. Im genannten Beispiel muss der Programmierer, um eine Datei zu öffnen, nur noch eine Funktion einer Bibliothek aufrufen und den gewünschten Dateinamen übergeben. Frameworks Während Bibliotheken mit ihren Funktionen einen thematisch abgegeschlossenen Bereich (zum Beispiel Dateioperationen) abdecken, stellt ein Framework schon das Grundgerüst eines kompletten Programms bereit. Das heißt, Frameworks schreiben die Architektur einer Anwendung und damit einen festen Ablauf vor und sind somit meist für einen bestimmten Anwendungstyp konzipiert. Da ein Framework eine feste Struktur besitzt, braucht der Programmierer nur noch seine Funktionen einzubetten um es wie gewünscht zu spezialisieren. Ein Beispiel für Frameworks sind elektronische Warenhäuser im Internet, bei denen bereits komplette Routinen der Datenverwaltung, Darstellung und Kaufabwicklung implementiert sind und der Programmierer nur noch gewünschte Anpassungen und Erweiterungen vornehmen braucht. 1 Kopieren und Einfügen 2.2 Middleware 2.2 9 Middleware Auf dem Weg zur Entwicklung von Engines liegt neben Wiederverwendung in hohem Maße auch das Prinzip der Abstraktion, das nun anhand von Middleware behandelt werden soll. Direkt übersetzt bedeutet der Begriff ”Middleware” so etwas wie ”Zwischenware”, das heißt, ein Produkt, das zwischen etwas steht. Entstanden ist sie aus zwei Beweggründen: • Software wurde größtenteils unabhängig voneinander entwickelt und bot keine Möglichkeit der Interoperabilität mit anderer Software • Anwendungen wurden für eine Plattform entwickelt und waren inkompatibel zu anderen Betriebsystemen oder Hardwarearchitekturen Also kam die Idee eines Produkts auf, das zwischen andere Programme ”geschaltet” werden kann, um diese zu verbinden und Daten austauschen zu lassen. Diese Produkte bezeichnen wir heute als ”Middleware”. Zusammenfassend kann man sie als ”anwendungsunabhängige Technologie, die Dienstleistungen zur Vermittlung zwischen Anwendungen anbietet, so dass die Komplexität der zugrundeliegenden Applikationen und Infrastruktur verborgen wird” [Ruh01] bezeichnen. Abbildung 1: Middleware zwischen Anwendungen So können Programme, die auf Middleware oder den Output von Middleware zugreifen, die Daten in gewohnter Art und Weise interpretieren und brauchen sich nicht um eventuelle Konvertierungen kümmern (Abb. 1). Abbildung 2: Middleware zwischen Spiel und Plattform Game-Middleware ist oft als Application Programming Interface (API) zu verstehen (hier: DirectX), um eine Abstraktion zur Systemplattform zu schaffen und Spielen so die Möglichkeit zu geben, über einheitliche StandardSchnittstellen die Hardware zu steuern (Abb. 2) - eine Schichtenarchitektur entsteht. 10 2.3 2 ENTWICKLUNGSPROZESS Engine Nachdem mit Middleware eine Abstraktion zur Hardware geschaffen wurde, soll nun durch Engines eine weitere Abstraktionsebene entstehen. Der Begriff Engine stammt aus dem Englischen und bezeichnet einen Motor oder eine Maschine. Diese Übersetzung deutet bereits eine eher technische Beziehung an und genau das stellt die Engine in zweierlei Hinsicht dar. Zum einen nimmt sie die Aufgaben des ”Motors” innerhalb einer Software wahr und übernimmt als die antreibende Kraft die Verwaltung zentraler Aufgaben, ohne die das Programm nicht funktionieren würde. Zum anderen wird versucht durch die Engine eine Abkapselung der zugrunde liegenen Technik vom eigentlichen Inhalt der Software zu erreichen. Während bei Frameworks der Entwickler seinen Inhalt noch als Quellcode in das Framework einbetten musste (White Box), bieten Engines Schnittstellen in Form von Editoren, Tools und Skripting um den Inhalt in die Anwendung oder das Spiel zu integrieren. Die Notwendigkeit eigener Programmierarbeit im Engine-Quellcode, entfällt hierbei (Black Box). Durch das Zusammenfassen bestimmter anwendungsspezifischer Funktionalitäten, sind Engines, genau wie Frameworks, für jeweils einen bestimmten Anwendungstyp konzipiert (beispielsweise Datenbank- oder Grafik-Engines). Abbildung 3: Einordnung der Engine zwischen Anwendung und Hardware Abbildung 3 zeigt die Aufteilung der Anwendung in Inhalt und Engine, was eine neue Abstraktionsebene erzeugt. Während vorher noch eine reine Abstraktion zur Hardware mittels Middleware statt fand, wird nun die gesamte Behandlung des Inhalts abstrahiert. Auf diese Art und Weise kann der Anwendungsentwickler seiner eigentlichen Aufgabe der Entwicklung des Softwareinhalts nachkommen und braucht sich nicht jedes Mal mit der technischen Umsetzung auseinander zu setzen. 11 3 Aufbau und Architektur einer Game-Engine Im vorangegangen Kapitel haben wir gesehen, worum es sich bei einer Engine handelt. Eine Spiel- oder Game-Engine bezeichnet nun die Engine und damit wiederum antreibende Kraft - das Kernstück - innerhalb eines Computerspiels. Das Ziel bleibt gleich: eine Trennung zwischen Daten (Spielinhalt) und zugrunde liegender Technik, also der Umsetzung des Inhalts für den Spieler, zu schaffen. 3.1 Typisierung und Kategorisierung Um ein Spiel interessant zu gestalten, bedarf es mehr als nur einiger animierter Bilder, unter anderem Sound, Künstlicher Intelligenz (KI) und Netzwerkunterstützung. Da eine Spiel-Engine, die all diese Funktionalitäten umfasst, schnell unübersichtlich werden würde und die Wartbarkeit erschwert, werden Game-Engines im Allgemeinen modularisiert. Abbildung 4: Modularisierung der Game-Engine Dazu stehen alle Module, die hier ebenfalls als (Teil-)Engine bezeichnet werden und für sich einen speziellen technischen Teilbereich des Spiels behandeln, in ständiger Kommunikation mit dem Game-Engine-Kern, der die gesamte Ablaufsteuerung übernimmt (Abbildung 4). Da Computerspiele von der Interaktion und Dynamik des Spielers leben, können nicht alle Handlungen und Abläufe fest programmiert werden, sondern müssen während des Spielens simuliert werden. Deshalb fasst man die Aufgaben der Physik- und KI-Engine oft zum Bereich der Simulation zusammen. Bevor die Arbeitsweise der Game-Engine mit besonderem Augenmerk auf den Engine-Kern (und der enthaltenen Spiel-Hauptschleife) beschrieben werden, sollen zunächst die hier dargestellten wichtige Teil-Engines näher erläutert werden. 12 3 AUFBAU UND ARCHITEKTUR EINER GAME-ENGINE Grafik-Engine Die Grafik-Engine ist für die gesamte Visualisierung auf dem Bildschirm zuständig. Nach [Wik07c] bietet sie ”einem Programmierer eine große Palette von grafischen Funktionen und Effekten (geometrische Objektbeschreibung, Oberflächentexturen, Licht und Schatten, Transparenz, Spiegelungen usw.), so dass er für seine spezielle Anwendung diese nicht stets neuprogrammieren muss”. Unterteilt wird die Grafik-Engine meist in einen Teil zur Echtzeitberechnung und -darstellung der Spieldaten (wie Level, Charaktere, usw.) auf dem Bildschirm, dem sogenannten ”Renderer” und in einen Teil, der die grafische Benutzerschnittstelle, das sogenannte ”Graphical User Interface” (GUI) erzeugt. Nähere Informationen über Grafik in Computerspielen finden sich in der Seminararbeit ”Computer Game Graphics”. Sound-Engine Für Sound-Effekte, Hintergrundmusik und anderweitige akkustische Ausgabe ist die sogenannte Sound-Engine zuständig. Ähnlich wie die GrafikEngine bietet sie dem Programmierer Funktionen und Effekte um Töne und erstellte Soundtracks auszugeben und mit zum Beispiel Echos oder Rauschen zu modifizieren. Heutzutage sind Sound-Engines sogar in der Lage, speziell angefertigte 3D-Sounds auf 5.1- oder 7.1-Surroundsysteme auszugeben. Physik-Engine Physik-Engines dienen der Simulation und Berechnung physikalischer Abläufe wie zum Beispiel von Flugbahnen oder dem Aufeinanderprallen von Körpern. Dabei geht es weniger um korrekte physikalische (realitätsnahe) Umsetzung, sondern aus Gründen der Effizienz und des Spielspasses mehr um die Anwendung physikalischer und mathematischer Gesetzmäßigkeiten mit variablen, vom Programmierer zu bestimmender, Natur-”Konstanten”. Unter anderem ist die Physik-Engine auch für den wichtigen Teilbereich der Kollisionserkennung zuständig. Hierbei wird in periodischen Abständen geprüft, ob die Figuren des Spiels andere Gegenstände der Spielwelt schneiden und dann ein Hindernis simuliert, sodass Spielfiguren nicht durch Wände oder Gegenstände hindurch laufen können. Die Anwendung von Physik in Computerspielen, aber auch anderen Anwendungen, geht so weit, dass mittlerweile sogar speziell für physikalische Berechnungen optimierte Hardwarelösungen in Form von Physikkarten oder Physikchips auf Grafikkarten existieren. 3.1 Typisierung und Kategorisierung 13 Netzwerk-Engine Die Netzwerk-Engine ist für die gesamte Kommunikation eines Spiels im Netzwerk zuständig. Bei jedem Spiel endet irgendwann der von den Entwicklern vorgesehene Spielverlauf in Form von Missionen oder Kampagnen. Um dem damit schwindenden Spielspass entgegen zu wirken, beinhalten viele Spiele eine Mehrspielerfähigkeit (Multiplayer) wodurch Spieler gegeneinander oder miteinander antreten können. Zur Unterstützung übernimmt die Netzwerk-Engine die Verwaltung der Multiplayer-Umgebung und bietet dem Programmierer die Möglichkeit, diese mit einfachen Mitteln durch vorgefertigte Funktionen in sein Spiel einzubauen. KI-Engine Die gesamte Abarbeitung der künstlichen Intelligenz in Computerspielen wird in der Künstlichen Intelligenz Engine (KI-Engine) realisiert. Dem Programmierer wird hier durch vorgefertigte Funktionen die Möglichkeit gegeben, seine Spielfiguren mit einer Art Intelligenz zu versehen. Hierzu werden KI-Regeln (Wenn-Dann-Regeln) erstellt, die zu KI-Skripten zusammen gefasst werden und in periodischen Abständen im Spiel abgearbeitet und geprüft werden. Dazu gehört sowohl die Art der KI, wie sie Schachcomputer haben um Probleme zu lösen, als auch die sogenannte Pfadsuche, wobei Figuren selbstständig Wege zwischen Orten im Spiel finden müssen. Die Entwicklung der Künstlichen Intelligenz geht sogar dahin, dass Figuren innerhalb eines Spiels miteinander kommunizieren um taktische Absprachen zu treffen oder sich auf die Spielweise des Gegners einstellen. Ich möchte an dieser Stelle auf die Seminararbeit ”Artificial Intelligence in Computer Games” verweisen, die sich noch eingehender mit dem Thema der künstlichen Intelligenz auseinandersetzt. Skripting-Engine Skriptsprachen bieten dem Programmierer die Möglichkeit, Spielabläufe und Spiellogik auf eine abstrahierte Art zu beschreiben. Die Skript-Engine übernimmt hierbei, zur Laufzeit des Spiels, die Überprüfung und Auslösung der in der Skriptsprache definierten Aktionen und Handlungen. Sie unterstützt den Programmierer dahingehend, dass keine Abläufe mehr in ”echten” Programmiersprachen wie beispielsweise C++ geschrieben werden müssen, sondern alles was in der Spielwelt passieren kann über die Skript-Engine und die zugrunde liegende Skriptsprache realisiert werden kann. Detailiertere Informationen zur Skript-Engine und dem Engine-Skripting sind im Kapitel 4.2 zu finden. 14 3 AUFBAU UND ARCHITEKTUR EINER GAME-ENGINE 3.2 Arbeitsweise Nachdem nun die üblichen Bestandteile einer Game-Engine bekannt sind, soll erklärt werden, wie diese zusammen wirken und wie die Game-Engine, insbesondere der Engine-Kern, arbeitet. In Abbildung 4 (Kapitel 3.1) war bereits die Unterteilung einer Spiele-Engine zu sehen und der zentrale Teil, der Spiel-Engine-Kern, zu erkennen. Die gesamte Aufgabenverteilung und Steuerung der Engine und des Spiels als Ganzes geschieht im Engine-Kern. Beim Starten eines Computerspiels hat die Engine, genauer gesagt der EngineKern, zunächst die Aufgabe eine Grundkonfiguration des Spiels herzustellen. Dazu gehört das Einlesen und Verarbeiten der Konfigurationsdateien und gegebenenfalls übergebener Startparameter sowie die Initalisierung der TeilEngines und die Darstellung eines Spielmenüs. Alle Handlungen, die der Spieler im Menü vornimmt, werden an den EngineKern weitergeleitet, der dann die durchzuführenden Befehle wie Änderungen der Optionen, Laden eines Levels oder Beenden des Spiels an die in der Game-Engine vorhandenen Teil-Engines weiter leitet. Hat sich ein Spieler dafür entschieden das eigentliche Spiel zu starten oder fortzusetzen, leitet der Engine-Kern alle nötigen Maßnahmen ein und kommuniziert mit den Teil-Engines. Um die stetigen Veränderungen der Spielwelt darzustellen und auf Interaktionen des Spieler eingehen zu können, führt die Engine in periodischen Abständen Überprüfungen und damit verbunden, Änderungen der Spielwelt durch. All diese Aktionen zur Aktualisierung und Darstellung des Spielinhalt werden in der sogenannten Hauptschleife (Game Main Loop) als Teil des Engine-Kerns zusammen gefasst. Nach [Kna06], [Fei06] und [Dam02] finden bei jedem Durchlauf der Hauptschleife folgende Aktionen statt: 1. Eingaben des Spielers (wie Mausbewegungen oder Tastendrücke) einlesen, interpretieren und daraus neue Befehle für die Spielwelt erstellen 2. KI-Engine nimmt aktuelle Lage wahr und berechnet daraus mittels KI-Regeln Änderungen für Figuren und Gegenstände des Spiels 3. Aufgrund der Änderungen durch Spieler und KI werden Spielfiguren und Gegenstände bewegt und animiert 4. Physik-Engine stellt sicher, dass alle Bewegungen entsprechend der vorgegebenen Physik korrekt ablaufen und überprüft, ob durch Bewegungen Kollisionen entstanden sind, um diese entsprechend aufzulösen 3.3 Architektur 15 5. Sound-Engine überprüft, ob durch Änderungen der Spielwelt neue Geräusche oder Soundtracks abgespielt werden müssen 6. Grafik-Engine erstellt aus dem Blickpunkt des Spielers ein neues Bild auf die aktuelle Spielwelt Die Abläufe in der Hauptschleife werden meist in Eingabe (Punkt 1 und 2), Simulation (Punkt 3 und 4) und Ausgabe (Punkt 5 und 6) unterteilt. Durch schnelle, wiederholte Durchläufe dieser Ablaufkette kann eine hohe Aktualisierungsrate erreicht und damit dem Spieler die Präsenz einer ”echten”, lebenden Welt, die auf seine Handlungen reagiert, suggeriert werden. Jedes Spiel enthält in Abhängigkeit von Spielgenre, vorhandener Teil-Engines und anderer spielspezifischer Kriterien eine mehr oder weniger ausgeprägte Spiel-Hauptschleife. In der Anzahl der Durchläufe pro Sekunde können sich die Hauptschleifen allerdings stark unterscheiden. So benötigt eine SchachspielEngine deutlich weniger Durchläufe, da nur nach Änderung von Schachfiguren neue Berechnungen folgen. Bei einem 3D-Spiel allerdings erfolgen 30-60 Durchläufen pro Sekunden, da eine möglichst hohe Bildwiederholrate erzielt und sehr zeitnah auf Eingaben des Spielers reagiert werden muss. Wenn es das Spiel zu beenden gilt, führt der Engine-Kern Programmroutinen durch um den ursprünglichen Systemzustand vor Spielstart wiederherzustellen. Dazu werden zuerst eventuelle Spielstände gesichert und aktuelle Konfigurationen des Spiels gespeichert, Teil-Engines beendet und Hardwarezustände (wie beispielsweise Bildschirmauflösung) auf den vorherigen Systemzustand zurückgesetzt. 3.3 Architektur Nach Aufbau und Arbeitsweise einer Game-Engine soll nun die Beschreibung der Architektur folgen. Dazu wird zunächst Softwarearchitektur definiert, um dann die einzelnen Ebenen der Schichtenarchitektur zu erläutern. Softwarearchitektur selbst beschreibt die Zusammensetzung und das Zusammenspiel von Komponenten eines Softwaresystems. ”Sie wird wesentlich durch nicht-funktionale Eigenschaften wie Modifizierbarkeit, Wartbarkeit, Sicherheit oder Performance bestimmt.” [Wik07d] Um die Zusammenhänge bei der Architektur von Computerspielen zu erklären, beziehe ich mich im Folgenden auf eine Darstellung von Hannes Niederhausen [Nie06, S. 14]. 16 3 AUFBAU UND ARCHITEKTUR EINER GAME-ENGINE Abbildung 5: Softwarearchitektur eines Computerspiels Im Verlauf dieser Arbeit wurden die in Abbildung 5 gezeigten vier wichtigen Abstraktionsebenen bereits eingeführt. Die Treiberebene bildet die Abstraktion zur Hardware (Hardware Abstraction Layer (HAL)). Diese erzeugt eine Standard-Schnittstelle zur Hardware die um meist unterschiedlichen Systemkomponenten über einheitliche Befehle zu steuern (vgl. auch Middleware/API Kapitel 2.2). Eine weitere Abstraktionsebene wurde mit der (Game-)Engine geschaffen (hier: Modulebene). Aus Gründen der Übersichtlichkeit, Wartbarkeit und Teamfähigkeit wurde die Engine modularisiert (vgl. auch Game-Engine Kapitel 3.1). Jedes Teilmodul nutzt die gemeinsame Schnittstelle über die Treiberebene um die Funktionalität der Hardware auszuüben. Der Bereich der Gamecode Ebene spielt hauptsächlich eine Rolle, wenn Spieleentwickler eine Engine für ihr Spiel kaufen anstatt diese selbst zu entwickeln. Eine gekaufte Engine erfüllt selten sofort alle Ansprüche, die Entwickler an die Funktionalität der Engine stellen. Deshalb müssen in vielen Fällen noch diverse Anpassungen an die Engine vorgenommen werden, damit diese alle Besonderheiten des Spiels (zum Beispiel wegen eines besonderen Genres) abdeckt. Diese Anpassungen finden in der Gamecode Ebene statt und können in Form erstellter Plugins oder auch als Skript in die Engine eingebunden werden um die Funktionalitäten wie gewünscht zu modifizieren. (vgl. auch Engine-Skripting Kapitel 4.2) Die Ressourcenebene umfasst nun alle Daten, die mit dem eigentliche Spiel auf kreativer Ebene zu tun haben. Dazu gehören Spieldaten (wie Texturen, Modelle, Sounds, usw.) und die Spiellogik (meist Skripte), die das gesamte logische Spielgeschehen beschreibt und steuert. 17 4 Besonderheiten im Spieleentwicklungsprozess Dieses Kapitel befasst sich mit dem Einsatz und der Einbettung von Engines und Middleware im Spieleentwicklungsprozess. Dabei soll auf Fragen der Engineentwicklung, Anpassungen der Engine an das Spiel und Kompatiblität zu anderen Hardware- oder Softwarearchitekturen eingegangen werden. 4.1 Engineauswahl Früher oder später stellt sich für jeden Spieleentwickler die Frage, welche Engine sich für das zu erstellende Spiel am besten eignet oder ob man sogar selbst eine eigene Engine programmieren sollte. Um hier eine weise Entscheidung zu treffen, sollten wir uns zunächst mit den Vor- und Nachteiler eigener, gekaufter (kommerzieller) oder kostenloser (gegebenenfalls open source2 ) Engines befassen. Bei der Entwicklung einer eigenen Engine ist zu beachten (Vor- und Nachteile): • Engine wird primär für dieses Spiel entwickelt und liefert daher alle geforderten Funktionalitäten • das Team ist mit der Engine vertraut, kann Modifikationen und Erweiterungen sofort durchführen und Fehler schnell beheben • Engine kann im Nachhinein für weitere Projekte der Entwickler wiederverwendet oder sogar verkauft werden • hohe mathematische und programmiertechnische Kenntnisse sind vorausgesetzt • möglicherweise lange und schwer einschätzbare Entwicklungszeiten der Engine (damit verbunden ggf. hohe Entwicklungskosten) Entscheidet sich ein Entwickler dafür, eine eigene Engine zu erstellen, muss dies natürlich zu Beginn der Entwicklung erfolgen. Neben dem Designentwurf des Spiels, muss dann auch ein Architekturentwurf der Engine folgen und entschieden werden, welche Teil-Engines benötigt werden, welche Plattformen die Engine unterstützen soll und welche Middleware (OpenGL, Speedtree, usw.) verwendet werden soll. Andere Gruppen wie Grafiker, Modellierer, Designer, etc. arbeiten trotzdem parallel zur Engineentwicklung bereits am Spielinhalt. Da die Engine zu diesem Zeitpunkt noch nicht fertig ist, verschiebt sich auch die Erstellung eines Prototypen. 2 der Quellcode liegt offen und ist frei zugänglich 18 4 BESONDERHEITEN IM SPIELEENTWICKLUNGSPROZESS Wenn man sich nun dafür entscheidet die Engine eines Drittanbieters zu verwenden, bedenke man (Vor- und Nachteile): • Entwicklungszeit und -kosten werden gespart • höhere Qualität der Engine durch meist auf diesem Gebiet spezialisierte Entwickler • möglicherweise hohe Lizenzkosten • Team muss sich erst mit der Engine vertraut machen und einarbeiten • viele Spiele mit der selben Engine wirken weniger individuell • eigene, neuartige Genres lassen sich mit vorgefertigten Engines schwer realisieren Bevor allerdings die Engine eines Drittanbieters für ein eigenes Projekt verwendet werden kann, muss diese erst an die besonderen Eigenschaften und Anforderungen des Spiels angepasst werden. Bei Engines mit offenem Quellcode, ist das relativ einfach, da die Entwickler Änderungen in beliebiger Größe und Detailgrad direkt im Quellcode vornehmen können. Da die gesamte Funktionalität der Engine offen liegt, lassen sich auch gesamte Blöcke im Quellcode austauschen und Anbindungen an eigene Software ohne Verwendung von Middleware leicht realisieren. Wenn Engines ohne Quellcode (closed source) gekauft werden, ist man in hohem Maße auf den Hersteller angewiesen. Dieser muss ohne Zugriff auf den Quellcode zu geben, die Engine dynamisch und flexibel gestalten und Möglichkeiten schaffen, die komplette Funktionalität der Engine zu Modifizieren. Hierzu legt er der Engine zusätzliche Tools bei, die den Entwicklern auf abstrakte Weise Änderungen an der Engine oder den Programmroutinen durchführen lassen. Weiterhin schaffen Hersteller Schnittstellen in Form von Plugins oder Skripten (sogenanntes Engine-Skripting), um Spieleentwickler in die Lage zu versetzen, eigene, neue Funktionen einzubinden oder bestehende Funktionen der Engine ersetzen zu können. Wenn die Entwickler andere Tools verwenden, die von sich aus keine Möglichkeit bieten mit der Engine zu kommunizieren, sind sie auf Middleware angewiesen, die zwischen Engine und Tool ”geschaltet” werden kann. Auf den angesprochen Bereich des Engine-Skripting soll nun im Folgenden etwas näher eingegangen werden. 4.2 Engine-Skripting 4.2 19 Engine-Skripting Engine-Skripting bezeichnet das Verfahren eine Engine oder sogar das darauf aufbauende Spiel mittels Skripten zu steuern und zu verändern. Die Idee ist die technische Ebene einer Hochsprache zu abstrahieren und den Spiele-Designern eine leicht verständliche, gut strukturierte Skriptsprache (zum Beispiel LUA) an die Hand zu geben, um Engine oder Spielwelt zu modifizieren. Die Bearbeitung der Skripte geschieht in der Skript-Engine, wobei hier die in der Skriptsprache formulierten Anweisungen mittels eines Interpreters interpretiert werden und dann die geforderten Aktionen auf dem System ausgeführt werden. Skripte lassen sich ohne Neukompilierung des Spiels laden und interpretieren, wodurch sich schnell und bequem Änderungen am Spielinhalt und -verhalten durchführen lassen. Daneben bieten Skriptsprache durch den Interpreter eine gesicherte Umgebung, in der auch bei syntaktisch oder logisch falschem Skripting keine schweren Systemschäden auftreten können. Computerspiele werden meist in mehreren Programmiersprachen entwickelt. Die Verwendung hängt davon ab, an welcher Stelle und in welchem Teil des Spiels, die Programmiersprachen am effizientesten eingesetzt werden können. Während beispielsweise das Skripting in einer möglichst abstrakten Sprache, mit der sich Spielverhalten leicht beschreiben lässt, stattfindet, wird für die Programmierung der Grafik-Engine meist eine Mischung aus C und Assembler genutzt, weil es hier auf die Geschwindigkeit der Abarbeitung der Befehle ankommt. Der Einsatz von Skriptsprachen bietet dem Spielehersteller allerdings nicht nur den Vorteil der effizienten Entwicklung von Spielen. Viel mehr entsteht dadurch die Möglichkeit auch den Spielern selbst Einfluss auf das Spiel nehmen zu lassen. So können Spieler eigenen Inhalt und Ideen einbringen und das Spiel so, neben den vom Hersteller verkauften Addons und Extension Packs, für sich und andere auch einen längeren Zeitraum interessant gestalten. Dazu ist es aber notwendig, dass der Hersteller Schnittstellen zum Spiel schafft, in denen die Spieler ihren eigenen Inhalt und Skripte erstellen und einbinden können. Dies geschieht durch sogenannte Software Development Kits (SDK), die Hersteller dem Spiel beilegen oder nachträglich zur Verfügung stellen. Hierbei Handelt es sich um Sammlungen von Werkzeugen, Programmen und Editoren, ähnlich diesen, die die Spieledesigner zur Entwicklung des Spiels verwendet haben. Alle Veränderungen, die Spieler vornehmen, um den kreativen Inhalt oder das Spielgeschehen ihren Wünschen anzupassen, werden allgemein als ”Modding” bezeichnet. Die Seminararbeit ”Development Suites and Game Modifications” wird vertiefend auf dieses Themengebiet eingehen. 20 4.3 4 BESONDERHEITEN IM SPIELEENTWICKLUNGSPROZESS Cross-Platform-Development Viele Spiele sprechen große Zielgruppen an, die diese allerdings nicht immer auf dem PC zuhause spielen möchten. Die Konsumenten wünschen sich die Unterhaltung auch auf ihre Spielkonsolen, Videoautomaten oder Handys. Das haben die Spielehersteller natürlich auch erkannt und bieten daher ihre Spiele für ein möglichst großes Spektrum von Hardwareplattformen und verschiedene Betriebssysteme an. Die unterschiedlichen Hard- und Softwarearchitekturen sind untereinander allerdings nicht kompatibel, so kann keine PC-CDRom in eine Playstation eingelegt werden oder kein Windows-Spiel unter Linux starten. Im Verlauf dieser Arbeit haben wir bereits die Schichtenarchitektur der Engine (Abbildung 5) kennen gelernt. Durch die angewandte Abstraktion und Trennung von Engine und Inhalt muss nicht das komplette Spiel neu erstellt werden, sondern nur die plattformspezifischen Teile (dem Spielinhalt ”ist es egal” auf welcher Systemplattform er dargestellt wird). Vereinzelt reicht es schon, nur die Treiberebene zu ersetzen, um so die Kompatiblität zu einem anderen Betriebssystem zu schaffen. Eine Portierung auf andere Hardwareplattformen stellt sich allerdings etwas schwieriger dar. Hierbei ist neben der Notwendigkeit einer kompletten Neukompilierung bereits während der Entwicklung der Engine darauf zu achten, spezielle Hardwarefunktionen, die beispielsweise nur auf einem Intel-CPU ausgeführt werden können, zu vermeiden. Ferner können dann durch einen Ausstausch der Treiberebene (mit einer Treiberebene / API des Konsolenherstellers) und damit der Schnittstelle zwischen Hardware und Software (ähnlich einer Virtuellen Maschine), darüber liegende Programme ohne inhaltliche Modifikationen auf gewohnte Art und Weise die Hardware ansprechen (sie merken nicht einmal, dass eine andere Hardware zugrunde liegt). Des weiteren darf nicht vergessen werden, dass andere Plattformen, besonders durch spezielle Hardware, auch andere Systemvoraussetzungen bieten. Besonders müssen hier die Spielekonsolen hervorgehoben werden, da diese meist lange Zeit im Einsatz sind, sich dadurch nicht immer auf dem aktuellen Stand der Technik befinden und so möglicherweise nicht die selbe Performance wie der PC zuhause bieten. Um weiterhin einen flüssigen Ablauf des Spiels zu gewährleisten, müssen in der Engine, bereits während der Entwicklung, Vorkehrungen getroffen werden, die Leistung bestimmter Teil-Engines (meist Grafik) zu drosseln, damit das Spiel auch auf schlechter ausgestatteten Plattformen lauffähig bleibt. Hier gilt es zum einen den Besitzern schlechterer Hardware mit flüssig ablaufenden Spielen entgegen zu kommen, als auch den Spielern mit neuester Technik eine hohe Ausnutzung ihrer Spielehardware zu bieten. 21 5 Ausblick Im Laufe dieser Arbeit sollte die Stellung und Wichtigkeit von Engines und Middleware in der Spieleentwicklung klar geworden sein. Durch geschickt gewählte Abstraktionsebenen ist es möglich geworden die künstlerische Arbeit eines Designers von der technischen Arbeit eines Programmiers zu trennen. Dadurch werden Entwicklungseschwindigkeit und Qualität des Spiels verbessert, was dem Hersteller in Kostenersparnis und dem Spieler in Spielspass zu Gute kommt. Modularisierung und klar definierte Schnittstellen bieten die Option, ganze Teile einer Engine austauschen und so Funktionalitäten zu ersetzen oder Kompatiblität zu anderen Hardwareplattformen zu schaffen. Leider lassen sich neue, ausgefallene Spielgenres schwierig auf herkömmlichen, bestehenden Engines aufsetzen und mehrere, auf derselben Engine beruhenden Spiele, wirken weniger individuell. Game-Engines finden heutzutage vermehrt Anwendung auch außerhalb ihres eigentlich konzipiertes Einsatzes in Computerspielen. Durch dieses sogenannte ”Serious Gaming” entstehen immer mehr Werbespots, 3D-Rundflüge, Taktiksimulationen oder Präsentationen auf der Grundlage einer SpieleEngine. Grund dafür ist, dass Heute, in einer Zeit frei erhältlicher GameEngines und steigender Benutzerfreundlichkeit Jedermann in der Lage ist mit der nötigen Software und ein wenig Wissen darüber, eigene Spiele und 3D-Welten zu erstellen. Hierin findet sich für Wirtschaft, Wissenschaft oder Militär eine kostengünstige, einfache Alternative professionelle 3D-Visualisierungen zu erstellen, ohne auf teure Präsentationswerkzeuge zurückgreifen zu müssen. Die Zukunft von Engines ist schwer abzusehen, aber es ist gut vorstellbar, dass im Zuge weiterer Spezialisierung von Engine-Herstellern und wachsender Gemeinden im Open Source Bereich, universelle Spieleengines entstehen. Diese könnten mittels Plugins, Skripting und Werkzeugen den Entwicklern auf hoher Abstraktion die Möglichkeit bieten, die Engine komplett zu modifizieren um auch extravagante, neuartige Genres enstehen zu lassen. Um den Umgang mit Game-Engines und die Erstellung und Verwendung von 3D-Spielen, -Welten und -Simulationen noch einfacher zu gestalten, wurden Hilfsmittel in Form von Programmen, Werkzeugen und Ressourcensammlungen erstellt um so ohne großen Aufwand und möglichst schnell Projekte erstellen zu können. Diese Hilfsmittel werden zu sogenannten Development Suiten zusammen gefasst, womit sich die anschließende Seminararbeit eingehend befassen wird. 22 5 AUSBLICK ABBILDUNGSVERZEICHNIS 23 Abbildungsverzeichnis 1 Middleware zwischen Anwendungen . . . . . . . . . . . . . . 9 2 Middleware zwischen Spiel und Plattform . . . . . . . . . . . 9 3 Einordnung der Engine zwischen Anwendung und Hardware . 10 4 Modularisierung der Game-Engine . . . . . . . . . . . . . . . 11 5 Softwarearchitektur eines Computerspiels . . . . . . . . . . . 16 24 ABBILDUNGSVERZEICHNIS 25 LITERATUR Literatur [Bec96] Stefan Becker. Überblick über Ansätze und Werkzeuge der umfassenden Software-Wiederverwendung. Universität Kaiserslautern, Fachbereich Informatik, 1996. [Bri05] Daniel Gottschlag, Mathias Bricke. Entwicklung von Computerspielen/Game Middleware. Otto-von-Guericke-Universität Magdeburg, 2005. [Bro01] William A. Ruh, Francis X. Maginnis, William J. Brown. Enterprise Application Integration. John Wiley & Sons, 2001. [Dam02] Holger Dammertz. Spiele unter Linux (SDL). Universität Ulm, 2002. [Fei06] Luis Valente, Aura Conci, Bruno Feijó. Real Time Game Loop Models for Single-Player Computer Games. Universidade Federal Fluminense, 2006. [Fug04] Torben Fugger. 3D-Game-Engine. Universität Koblenz, 2004. [Geb07] Nikolaus Gebhardt. Irrlicht - Lightning Fast Realtime 3D Engine. http://irrlicht.sourceforge.net/, 2007. [Kna06] Björn Knafla. Wie kommt der Drache ins Computerspiel? Universität Kassel, 2006. [Lin99] Christian Lindig. Algorithmen zur Begriffsanalyse und ihre Anwendung bei Softwarebibliotheken. Universität Braunschweig, Fachbereich für Mathematik und Informatik, 1999. [Nac05] Lennart Nacke. Facilitating the Edication of Game Development. Otto-von-Guericke Universität Magdeburg, Fachbereich Informatik, 2005. [Nie06] Hannes Niederhausen. Architektur im Bereich der Entwicklung von Computerspielen. Universität Leipzig, Fachbereich Informatik, 2006. [Opp03] Christian Geiger, Leif Oppermann. Skriptbasierte Entwicklung interaktiver 2D/3D-Inhalte. Hochschule Harz, Medieninformatik, 2003. [Rin06] Ralf Dörner, Dirk Ringe. Kein Kinderspiel. iX 9/2006, 2006. [Ste04] Kai Sterker. Andonthell www.linuxgames.com, 2004. Engine Architecture. 26 LITERATUR [Web06] Niels Weber. Spiele-Software und Open Source. Technische Universität Berlin, 2006. [Wik07a] Wikipedia. Framework. Framework, 2007. http://de.wikipedia.org/wiki/ [Wik07b] Wikipedia. Game engine. Game_engine, 2007. http://en.wikipedia.org/wiki/ [Wik07c] Wikipedia. Grafik-Engine. Game-Engine, 2007. http://en.wikipedia.org/wiki/ [Wik07d] Wikipedia. Softwarearchitektur. http://de.wikipedia.org/ wiki/Softwarearchitektur, 2007.
