Abutroid
| Projektdetails | |
|---|---|
 | |
| Abschluss: | 2007 |
| Umfang: | Prototyp |
| Genre: | Action-Jump'n Run |
| Entwickler: | Thomas Hilbert |
| Rahmen: | Hobbyprojekt |
| Dauer: | 4 Monate |
| Plattform: | Windows (.NET) |
| API: | Managed DirectX |
Abutroid wurde gezielt als Bewerbungsprojekt für die Games Academy entwickelt. Der Fokus lag dadurch weniger auf meinem persönlichen technischen Fortschritt, als vielmehr auf der Demonstration meiner Fähigkeit, ein lauffähiges Spiel mit fortlaufender Story zu programmieren.
Als Grundlage für Abutroid diente die Idee einer offenen Welt, deren
Erforschung lediglich durch die begrenzten Möglichkeiten des Protagonisten
eingeschränkt wird. Indem der Protagonist seine Fähigkeiten erweitert, kann
er nach und nach immer mehr Bereiche der Welt betreten, die ihm vorher
verschlossen waren. Dieses Prinzip entspringt Spielen wie "Metroid".
Um die Story, die dem Spiel zugrunde liegt, tiefer mit dem tatsächlichen
Gameplay zu verflechten, wurde dem Spieler die Möglichkeit gegeben, alle
relevanten Objekte in seiner Umgebung zu scannen, um Informationen über
diese Objekte zu erhalten. Dazu benutzt der Spieler die Maus, so dass das
Spiel trotz der Sidescroller-Perspektive mit der aus Egoshootern gewohnten WASD+Maus-Kombi
gesteuert wird.
Diese Steuerung erlaubt es dem Spieler, sehr gezielt mit Objekten in seiner
Umgebung zu interagieren, selbst während er läuft, springt oder kämpft.
Dieses Prinzip ähnelt stark der Steuerung im Spiel "Abuse". Daher auch der
Name "Abutroid" (Abuse+Metroid).
Technik
Abutroid wurde komplett in C# programmiert und basiert auf Managed DirectX.
Spielwelt
Die Spielwelt besteht aus mehreren Räumen, welche jeweils in 3D Studio Max gebaut wurden. Durch gezielte Benennung bestimmter Objekte in der Szene ist es möglich, Models, Lichter und Trigger in den Raum zu importieren. Ein Cube mit dem Namen ",,,ip,goto,1,0,caveEntrance" wäre unsichtbar, passierbar und würde einen Spieler, der ihn betritt, in Welt 1, Raum 0 an die Position "caveEntrance" teleportieren. Entsprechend muss in Welt 1, Raum 0 auch ein Point-Helper mit dem Namen "position,,caveEntrance" existieren.
Dies ermöglichte mir den Bau einer Spielwelt in kurzer Zeit, ohne Verwendung externer Editoren, deren Anwendung ich erst hätte lernen und für deren Dateiformate ich hätte Importer schreiben müssen. Da Zeit damals sehr knapp war (das Projekt musste rechtzeitig zur Bewerbungsphase an der Games Academy fertig sein) entschied ich mich also für die Verwendung von 3D Studio.
Kollisionserkennung
Kollisionen in Abutroid basieren vollständig auf Tracelines. Beim Laden der Spielwelt werden aus den Faces der 3D-Objekte sogenannte "Solids" erzeugt und in einen BSP-Tree einsortiert. Tracelines können so sehr effizient auf Kollision mit diesen Solids prüfen. Durch Verwendung eines eigens dafür gemodelten Kollisionsmeshs mit stark reduziertem Polycount kann die Performance der Kollisionserkennung außerdem noch erhöht werden.
Trigger und Story
Rätsel-Logik wie "Tür öffnet, wenn Schalter aktiviert wird", wird über Trigger abgebildet. Ein Trigger hat eine festgelegte Anzahl an Inputs und einen Output. Es existieren Trigger für logische Operation wie AND, OR und NOT, aber auch Signalgeber wie Sensoren und Schalter und Akteure wie Türen, Partikelsysteme, Animations- und Sound-Objekte. Auch Story-Mechanismen wie Quest-Fortschritte etc. werden über Trigger abgebildet.
Die Erzeugung und Verschaltung der Trigger geschieht größtenteils hardgecodet in speziellen Raum- und Welt-Klassen. Diese Klassen behandeln Events wie "OnLoad", "OnPlayerEnteredRoom" etc. Das wäre natürlich durch Scripting und einen speziellen Editor besser umzusetzen. In diesem Editor würde man die Trigger erzeugen und verschalten und dann die entsprechenden Daten direkt in das Welt-File einbetten. Das würde die Story aus dem Programmcode lösen und so auch einem Gamedesigner ohne Programmierkenntnisse die Möglichkeit der Bearbeitung geben.