Kurze Einleitung :
Vor knapp 1 1/2 Wochen habe ich angefangen ein neues Spiel zu proggen, nämlich einen Spaceshooter á la R-Type/Salamander, allerdings mit OpenGL und komplett in 3D. Für alle die R-Type bzw. Salamander nicht kennen (was gut möglich ist, stammen nämlich alle aus der 16/8-Bit Konsolenzeit), es handelt sich dabei im "Ballerspiele" im Weltraum die immernur in eine Richtung ablaufen, also keine 6DOF wie z.B. bei WingCommander oder Freelancer.
Unterschied zu den von mir genannten Titeln ist bei Terrorcide - The Nuclear Sword of Damocles (Arbeitstitel) die Ansicht von hinten, so dass der 3D-Faktor besser rauskommt. Ausserdem möchte ich auch zumindest Ansatzweise sowas wie eine richtige Story einbauen, weshalb es bei jeder Mission sowohl ein Briefing als auch ein Debriefing geben wird. Der programmiertechnische Teil ist bereits so gut wie abgeschlossen (~2000 Zeilen, exklusive meiner Basecodeunits), momentan werkle ich daher am Content, also 3D-Modelle, Grafiken und Missionsskripts.
Zuerst aber wie gewohnt ein paar Screenshots :
Kurze Erklärung zu den "WIP"-Screenshots (v.l.n.r.) :
- Hier sieht man den Messagecomputer und das Briefing für die erste Mission.
- Der Spieler wurde grade von seinem Dropship ausgesetzt und macht Staub aus den Asteroiden.
- Mitten im freien Raum bei der Asteroidenjagd, kurz vor dem Erreichen der Zielbasis in Mission 1.
- Formationstest (dazu später mehr).
Zum Programmiertechnischen :
Wie gesagt besteht der Quellcode des Spiels aus knapp 2000 Zeilen (darin enthalten sind meine Basecodeunits wie z.B. TexturenManager, ModelManager usw. nicht) und ist bisher (ein wenig Selbststolz kann nicht schaden
) wohl der sauberste und "schönste" Quellcode den ich für ein größeres Projekt geschrieben habe.
Die Verwaltung aller Objekte in der Spielwelt übernimmt bei mir ein TEntityManager (der Begriff Entity sollte den meisten Lesern ein Begriff sein), der eine Liste von TBaseEntity-Objekten verwaltet. Objekte wie Raumschiffe (TActor), Geschosse (TBullet) und Explosionen (TExplosion) sind von dieser Klasse abgeleitet, die die wichtigsten abstrakten Funktionen und Prozeduren beinhaltet (Update, Render, IsObsolete). Verwaltet werden alle Objekte dann dynamisch über eine Pointerliste. Die Verwaltung aller Spielobjekte über einen solchen Entitätenmanager macht die Sache übrigens sehr einfach. Neue Entitäten werden auch über die (überladene) Funktion SpawnEntity erstellt, so dass andere Klassen (z.B. über Skripts) leicht neue Objekte in die Welt einfügen können.
Und wenn wir grade beim Thema Skripte sind : Missionen sowie alle anderen extern benötigten Daten liegen in Form von XML-Dateien vor. Wer selbst das XML-Format nutzt, kennt seinen riesigen Vorteil, nämlich die leichte Erweiterbarkeit. Die Verwaltung des Missionskomplexes wikelt dabei die Klasse TMissionManager ab, die nicht nur neue Missionen aus der entsprechenden XML-Datei lädt, sondern sich auch drum kümmert das die in dieses Datei abgelegten Missionsereignisse an der korrekten Position getriggert werden (dazu gleich mehr).
Alle anderen relevanten Daten verwaltet der TDataManager. Darunter fallen z.B. Formationen und Gizmoinformationen für die einzelnen 3D-Modelle.
Das Rendering (bzw. der ganze 3D-Teil) ist wohl (momentan) weniger interessant. Aber wie schon NapalmBomber3D soll auch Terrorcide als Freeware-Titel eher den Casual-Gamer ansprechen und soll daher auch auf älterer Hardware laufen. Deshalb gehe ich sowohl bei der graphischen Komplexität als auch beim Detailgrad Kompromisse ein. Also nur 2^n*2^n-Texturen (nicht zu groß), recht geringer Polygoncount und vorerst keine Shader. Da ich meinen fertigen ModelManager verwende, werden die 3D-Modelle je nach Hardware entweder als Displaylisten oder als VBOs (letztere nach Material sortiert) gerendert. Der TexturenManager nutzt auf neueren Karten dann auch die automatische Mipmapgeneration, was sich zumindest beim Laden bemerkbar machen sollte.
Einziges "interessantes" Merkmal des Rendervorganges ist daher die Z-Sortierung aller transparenten Objekte (Explosionen und Geschosse), da es sonst besonders bei heisser Action (viele Explosionen und Geschosse gleichzeitig sichtbar) zu hässlichen Effekten käme. Momentan sortiere ich noch mit dem langsamen (aber leicht zu implementierendem) BubbleSort-Algorithmus, der auch eigentlich ausreichen sollte. Andere Algorithmen wie z.B. QuickSort bringen nämlich erst wirklich bei einer großen Anzahl zu sortierender Elemente was.
Kollision ist übrigens auch schon implementiert. Momentan aber nur über BoundingBoxen, was zwar für den Anfang ausreichend ist, aber auf jeden Fall noch verfeinert wird. Werde später also noch zusätzlich Kollision auf Dreiecksbasis einbauen, da pure BBs bei einigen (End)gegnertypen die mir vorschweben alles andere als brauchbar wären.
Die Tools :
So ziemlich jeder Spielentwickler hat begriffen das der wichtigste Teil bei der Entwicklung die passenden Tools sind. Eine tolle Engine nützt ohne Tools zur Contenterstellung nämlich nichts, weshalb ich für Terroricde bisher bereits 3 verschiedene Tools entwickelt habe.
AfterModel (Screenshot) :
Mit diesem Tool kann ich sog. Gizmos (den Begriff hab ich einfach so mal aus 3DSMax übernommen) an meinen Modellen platzieren, die ich dann im Spiel nach Gusto interpretieren kann. Normalerweise sind das die Waffenpositionen und Glows an den Schiffen. Exportiert werden diese Gizmos dann nach XML und vom DataManager den passenden Modellen zugeordnet.
FormationBuilder (Screenshot) :
Eigentlich wollte ich zuerst per Zufall irgendwelche feindlichen Schiffe im Level erstellen lassen, was sich allerdings ziemlich schnell als chaotisch und spielerisch kaum interessant herausgestellt hat. Ausserdem lässt sich dort auch schlecht der für spätere Missionen höhere Schwierigkeitsgrad realisieren. Da ich aber schon nen Entitätenmanager habe mit dem ich bequem neue Aktoren dynamisch erstellen kann, hab ich mir schnell noch ein Tool zusammengebaut mit dem man Formationen erstellen und nach XML exportieren kann. Diese Formationen kann man dann leicht mit dem Missionsskripter an festgelegten Levelpositionen spawnen lassen. So hat man dann 100%ige Kontrolle über das wo und wann innerhalb einer Mission.
MissionsScripter (Screenshot) :
Wie bereits gesagt soll das Spiel storygetrieben sein. Da kann ich natürlich nicht einfach hingehen und per Zufall irgendwo Feinde bzw. Objekte erstellen. Deshalb hab ich bereits am Anfang der Entwicklung einen kleinen Missionsskripter geschrieben, der eine Ereignisliste erstellen kann. Dort kann man dann z.B. angeben das an Levelposition X Objekt Y mit im Skripter eingestellten Eigenschaften erstellt wird. Ausserdem kann man hier noch Briefing/Debrieing, Missionstitel, Länge und Umgebung (u.a.) einer Mission festlegen.
Das wars also erstmal zu meinem kleine Projekt. Habe den Zeitraum bis zur Fertigstellung mal auf 1-2 Monate festgelegt, und schätze das auch einhalten zu können. Das Spiel ist bereits lauffähig, aber ich wollte keine Version veröffentlichen in der es nur 1 1/2 fertige Missionen zu spielen gibt. Das wäre dann doch ein wenig langweilig, aber innerhalb der nächsten paar Wochen dürfte die erste spielbare Version mit 3-4 Missionen auf euch zukommen. Wie gesagt bastle ich momentan sowohl an der Story als auch (v.a., da sehr zeitraubend) an den 3D-Modellen.
