Aufgabenbeschreibung

 

Aufgabenstellung

Ziel dieser Übung ist es, durch Implementierung eines 3D-Computergraphik-Spiels einige der wichtigsten Algorithmen in der Computergraphik kennen zu lernen und praktische Erfahrung im Umgang mit gängiger 3D-Hardware und Software zu gewinnen. Das Genre des Spieles ist im Prinzip frei wählbar, jedoch muss es gewisse Anforderungen erfüllen:

• Es muss sich um ein 3D-Spiel handeln bei dem alle 3 Dimensionen sinnvoll für die Darstellung der Welt und das Gameplay genutzt werden. Gameplay, das sich auch wie beispielsweise in Pac-Man in einem reinen 2D-Spiel umsetzen ließe, ist nicht zulässig.
• Eine im Raum bewegliche und schwenkbare Kamera ist Pflicht. Dabei muss die Kamera nicht unbedingt vom Spieler aktiv gesteuert werden, aber der angezeigte Bildausschnitt der Welt muss sich ändern. Wenn immer die komplette Spielwelt sichtbar wäre, wie bei Pac-Man, so wäre diese Anforderung nicht erfüllt.
• Es muss sich bei dem Spiel keineswegs um ein "klassisches" 3D-Spiel handeln, wir freuen uns immer über neuartige und verrückte Ideen. In erster Linie zählen bei uns Spielspaß und die computergraphischen Effekte.

Wenn ihr euch nicht sicher seid ob euer Konzept die Anforderungen erfüllt könnt ihr die Tutoren im Informatikforum fragen. Außerdem bekommt ihr nach der 1. Abgabe hilfreiches Feedback von den Tutoren.

Zusätzlich zu diesen Anforderungen müssen in eurem Spiel eine Reihe von computergraphischen Effekten implementiert werden.

Restriktionen

Zwar dürft ihr für die LU auf fertige Libraries zurückgreifen, allerdings gelten für diese bestimmte Restriktionen:

• Ihr dürft keinen Sourcecode oder Shadercode per copy&paste von Webseiten oder Tutorials übernehmen. Wenn ihr euch an bestimmten Ressourcen orientiert gebt diese unbedingt in der Dokumentation eures Programms an.
• Keine Libraries die das Rendern von 3D-Modellen für euch übernehmen, da das Anlegen und Rendern von Vertexbuffers ein zentraler Bestandteil der LU ist. Ihr dürft aber fertige Libraries zum Laden von Modellen benutzen.
• Keine fertigen Engines: Euer Spiel darf nicht auf einer Engine basieren, oder wesentliche mit dem Rendering verknüpfte Teile einer solchen verwenden. Codeteile, die verwendet werden dürfen, umfassen nur Collision Detection, AI, Sound oder Code zum Laden (aber nicht zum Anzeigen) von Modellen. (ausgenommen sind die Engine-Gruppen).
• Keine fertigen Scenegraph-APIs wie OpenInventor, da das Aufbauen einer Szenenhierarchie Bestandteil der LU ist.
• Die Teile einer Library oder Engine, die selbst OpenGL-Befehle benutzt/umsetzt, sollt ihr nicht verwenden, da das Erlernen von OpenGL Teil der Übung ist (das heißt allerdings nicht automatisch dass alle Teile einer Engine/Library, die nicht OpenGL verwenden, benutzt werden können (sh. obige Punkte). Beispiel dafür sind etwa die ilutGL-Funktionen von DevIL.
• Grundregel lautet: alles was eigentlich der Lehrinhalt der LU ist, soll von euch selbst implementiert werden!

Damit wir nachvollziehen können, welche Libaries ihr wie verwendet habt, fügt bitte folgenden Dinge eurer Abgabe bei:

• Ein Verzeichnis "external", wo die externen Libraries, die ihr verwendet habt, in unmodifizierter, gezippter Form vorliegen (außer für die auf der Homepage empfohlenen Libraries).
• In der Dokumentation: Ein kurzer Abschnitt, der angibt, ob und wie ihr den externen Code verändert habt.
• Für alle Libaries, die auch Rendering-Komponenten enthalten (z.B. Model-Loader): Ein kurzer Abschnitt, der angibt, wie ihr die Library verwendet habt (z.B. welche Funktionen wurden aufgerufen).

Engine-Spiele

Es besteht die Möglichkeit für 4 bis 6 Gruppen Spiele mit ausgereiften 3D-Engines zu entwickeln. Für die Laborübung stehen die Open Source-Engine Ogre3D, die eine reine Rendering Engine ist, und die kommerzielle Shark3D-Engine von Spinor zur Verfügung:

Shark3D

Die kommerzielle Shark3D 3D Engine steht seit 2005 für die CG23 LU zur Verfügung. Warum eine kommerzielle 3D Engine? Der Grund für dieses Angebot ist, daß im Alltag eines Gamedevelopers die Eigenentwicklung einer 3D Game Engine von Grund auf eine zunehmend untergeordnete Rolle spielt; an deren Stelle tritt die Anpassung von lizensierten 3rd Party Engines. Diese teilen sich sich in spezialisierte Engines wie z.B. die Unreal2-, Doom3- oder Half-Life-2-Engines oder allgemeiner einsetzbaren Middlewareengines wie z.B. Renderware, Gamebryo (Netimmerse), Lithtech oder eben Shark3D. Eine wesentliches Merkmal ist die Unterstützung der kommerziell sehr wichtigen Videospielplattformen, die aus lizenzrechtlichen Gründen auf Open Sourceengines wie z.B. Ogre oder Fly 3D nicht verfügbar ist.

Shark3D ist eine moderne, extrem modular aufgebaute C++ 3D Multiplattformengine (PS2, XBox, PC Windows & Linux) vom deutschen Softwarehersteller Spinor, die sowohl im kommerziellen als auch im akademischen Bereich erfolgreich eingesetzt wird. Spinor hat dem CG Institut Support für die Student Licenses zugesichert, was nach negativen Erfahrungen mit dem Einsatz unsupporteter Lizenzen von Renderware in der Vergangenheit besonders wichtig ist.

Shark3D für die CG23 Laborübung zu verwenden, bietet Studenten die Möglichkeit, sich mit einer mächtigen Middlewarelösung vertraut zu machen und richtet sich an Leute,die schon etwas Erfahrung in der Programmierung mit C++ besitzen. Die Aufgabe besteht hier nicht darin, mittels GLUT und etwas OpenGL Wissen das Grundgerüst einer 3D Engine zu programmieren, sondern sich in ein mächtiges Framework einzuarbeiten und die darin verborgenen Möglichkeiten bzgl. Echzeitschatten, komplexe Shader etc für die eigene Spielidee zu nutzen. Ein besonderes Feature dabei ist das "dynamic resource update", das einen extrem kurzen Turnaroundzyklus erlaubt (näheres dazu auf der Spinor Webpage unter "Workflow"). Das Hauptaugenmerk liegt dabei, neben dem Spielspaß, natürlich auf der Integration von Grafikfeatures.

Die Shark3D Features kurz zusammengefaßt:

• Renderer: Flexible Shadersupport, Shadowvolumes & -maps, Projected Shadows, Bumpmaps, Mirrors, ...
• Animation Engine: Skeleton, Hierarchical, Mesh, ...
• Physics: Integrated rigid body or 3rd party
• Audio: 3D, WAV & OGG
• Networking: High- & lowlevel network support
• Scripting: Integrated proprietary "Perch" scripting language, Java
• Platforms: PS2, XBox, Windows, Linux

XNA

Dieses Jahr steht euch das XNA Game Studio 3.0 zur Verfügung, mit dem sich mit C# Spiele für Windows und Xbox 360 entwickeln lassen. Als IDE wird dabei Visual Studio verwendet, weiters setzt XNA auf DirectX 9 auf, ist also praktisch der Nachfolger von Managed DirectX. Neben einem kompletten Framework sind einige praktische Tools und eine eigene Content-Pipeline inkludiert, euch werden also Arbeiten wie Model Loading, Window Management, etc. komplett abgenommen. XNA unterstützt KEINE Fixed-Function Pipeline mehr, d.h. alle Effekte werden als Shader implementiert.

Wir erwarten, dass euer Spiel auch auf einer XBox 360 läuft und stellen euch dazu eine Creators Club-Mitgliedschaft zur Verfügung. Das Institut besitzt weiters eine XBox 360, auf der ihr dort testen könnt. Die Kompatibilität zur XBox bedeutet hauptsächlich eine Einschränkung: Es können keine Unmanaged (C++) 3rd Party Tools verwendet werden, da diese nicht auf der XBox laufen. Das betrifft vor allem Physik-Engines wie PhysX. Es gibt aber bereits einige Alternativen, z.B.: JigLibX. Dieses Framework ist zwar noch in einer Beta-Version, funktioniert aber auch unter Xbox 360. Diverse einfachere Physik-Modelle sind auch bereits in einigen Starter-Kits implementiert, vor allem die BoxCollider Library im Ship Game.

Zum Begin ist es empfehlenswert, sich die Tutorials und Starter Kits genauer anzusehen, einige davon werden mit dem Game Studio mitgeliefert, weitere findet man unter creators.xna.com. Eine andere, sehr gute Ressource ist Ziggyware.

Wenn ihr ein Spiel mit einer fertigen Engine entwickeln wollt solltet ihr bereits Erfahrung mit Graphikprogrammierung und C++ mitbringen, da diese Systeme sehr umfangreich und komplex sind.

Das Entwickeln mit fertigen Engines unterscheidet sich grundsätzlich vom Schreiben eines eigenes kleinen Spiels, da man zwar eine umfangreiche Codebasis zur Verfügung hat mit der sich sehr schnell aufwendige Effekte und optisch ansprechende Ergebnisse umsetzen lassen, man den Code allerdings erst überblicken muss. Da sich die Anforderungen nicht mit denen der anderen Gruppen vergleichen lassen gilt für Engine-Spiele ein eigenes individuell abgestimmtes Benotungsschema.

Wenn ihr ein Engine-Spiel entwickeln wollt bewerbt euch unter cg23-engines#cg.tuwien.ac.at.

Gamedeveloper-Feedback

Wir bieten besonders aussichtsreichen Gruppen die Möglichkeit ihr Spiel bei professionellen Spieleentwicklern in Wien zu präsentieren. In regelmäßigen Meetings arbeitet ihr eng mit Brancheninsidern zusammen und bekommt wertvolles Feedback. Die Auswahl der Gruppen wird von uns nach der 2. Abgabe vorgenommen und ist unabhängig davon ob das Spiel eine fertige Engine nutzt oder nicht.