Wobei „neu“ relativ zu sehen ist. Welche Gegner und Bossgegner zusätzlich zu den bisher bekannten neu dazu kommen sollen, steht seit vielen Monaten fest (insgesamt 8 neue Charaktere sind geplant, 4 Bossgegner, 3 normale Gegner und eine ungefährliche Ratte). Auch die dafür notwendigen Grafiken sind schon seit längerem zum größten Teil fertig. Der Zombie gehört dabei zu meinen Lieblingsmotiven – so fein ausgearbeitet und detailliert ist sonst kaum ein Gegner. Das müssen sie im Allgemeinen auch nicht, schließlich sieht man sie im Spiel meist nur in relativ kleinen Größen (um die 100 Pixel hoch, die Bossgegner etwas größer).

Kompliziert und langwierig ist der Einbau in die Quelltexte (C++) und das Schaffen einer für jeden Gegnertyp eigenen kleinen KI. Ich fände es schrecklich langweilig, wenn alle Gegner nur stur hin und her laufen würden. Der Zombie beispielsweise wird häufig stehen bleiben, langsam herum schlurfen, aber schlagartig schneller werden, wenn er Stevie bemerkt.

Bevor ihr euren Taschenrechner bemüht. Waren es damals noch insgesamt 173 Einträge, sind es jetzt bereits 265. Offen sind hingegen nur etwas mehr als damals. 43 damals zu 49 heute.

• In den bisherigen Glow-Versionen wurde nur sehr selten von der Möglichkeit Gebrauch gemacht, schräge Fußböden (Slopes) in den Levels zu verwenden. Das möchte ich gern ändern. Dummerweise stolpert man über immer mehr irritierende Bugs, sobald man etwas intensiver mit Schrägen hantiert. Manchmal fällt unser Held durch den Fußboden, wenn man beim Sprung genau die Kante zwischen zwei schrägen Tiles erwischt. Gegner wandern Schrägen hinauf, bleiben aber dann hängen und können sich nicht mehr bewegen. Nervig. So macht das Bauen von coolen Levels keinen Spaß. Dabei kann die Lösung manchmal ganz einfach sein: Slope(false);, fertig. Nur die Stelle im Code zu finden, an der diese Zeile bisher fehlte, das war nicht so einfach.
• Der Verwirrungszauber soll die Gegner durcheinander bringen, sie sollen nicht mehr wissen wo vorn und hinten ist, auf der Stelle hin und her laufen und Stevie nicht mehr erkennen. Bisher war das so implementiert, dass die Bewegung der Gegner vollständig gestoppt und nur ihre Blickrichtung in einem festen Takt umgekehrt wurde. Das funktionierte, war aber nicht wirklich schön. Es sah beinahe aus, als ob die KI abgestürzte wäre. Die Lösung waren wieder zwei bis drei Zeilen Quelltext an den richtigen Stellen: Die Gegner laufen weiter, auch wenn sie verwirrt sind, sie drehen aber in kurzen Abständen zufällig um (nicht mehr alle im gleichen Rhythmus). Dann noch die Feinderkennung abschalten und das war’s schon. Cooler Nebeneffekt: Bei diesen Änderungen ist praktisch kostenlos auch eine Funktion abgefallen, die den Gegnern mehr Individualität verleiht. Sie verlassen ihre festgelegten Patrouillen-Pfade jetzt manchmal und drehen mitten auf dem Weg vorzeitig um.
• Ein sehr alter Bug hieß: „Feuer ist nach Schnellladen extrem laut“. Holger hatte mehrfach danach gesucht und ich genauso. Ohne Erfolg. Dabei ist die Lösung erschreckend einfach, wenn man sich einmal klar gemacht hat, wie die Feuergeräusche entstehen: Sobald ein Feuer in Hörreichweite kommt, wird sein Sound-Loop gestartet. Das passiert im normalen Spiel mit jedem Feuer einzeln, abhängig davon, wie sich Stevie durch den Level bewegt. Beim Schnellladen kann es dagegen passieren, dass schlagartig viele Feuer in Hörreichweite sind und alle gleichzeitig gestartet werden. Nur durch diese Gleichzeitigkeit entsteht das hörbare Übersteuern der Sounds. Die Lösung: Ein kleiner Zufallswert, der jeden Sound um ein paar Millisekunden verzögert und damit das nachbildet, was normalerweise passieren würde, wenn die Soundquellen eine nach der anderen in Hörreichweite gelangen.
• Über einen der nervigsten Fehler hatte ich schon einmal berichtet. Kurz: Bei OpenGL beziehen sich die Texturkoordinaten auf die Mitte des Pixels, wie man es von Malprogrammen gewohnt ist. Bei Direct3D beziehen sich die Texturkoordinaten auf die linke obere Ecke des Pixels, sind also um ein halbes Pixel verschoben. Im Ergebnis sieht alles verschwommen aus. Noch schlimmer wird das, wenn – wie es bei Glow der Fall ist – zwei Renderdurchgänge gemacht werden (der zweite für Post-Processing-Effekte und die Auflösungs-Unabhängigkeit). Bisher hatte ich nur eine „halbe“ Lösung für den zweiten Schritt, der erste erzeugte immer noch verschmierte Texturen. Meine Lösung: D3DXMatrixTranslation(). Diese Funktion wird sowieso benutzt, um das Bildschirmwackeln zu realisieren. Ich setze einfach immer ein halbes Pixel Verschiebung ein und spare mir damit Vertex-Shader-Umwege oder gar komplizierte Berechnungen mit jeder einzelnen Textur.

Hier erst einmal ein Bildschirmfoto von einer der ersten Versionen. Die EXE hat das Datum vom 20. März 2006.

Was man sehen kann: Die große weiße Box mit den vielen Farben stellt die Hauptfigur dar. Zu diesem Zeitpunkt kann sie schon hüpfen und sich seitlich bewegen. Die roten Tiles sind die ersten animierten Tiles im Spiel. Außerdem sehen wir zwei Herzen als Objekte sowie einen Radius-Sound, zwei Ebenen im Hintergrund und ein paar Partikeleffekte.

Was man nicht sehen kann: Zu diesem Zeitpunkt war noch eine Skriptsprache (Lua) mit eingebaut. Holger hat sie später wieder entfernt, weil dieses Feature aus Zeitgründen nicht umgesetzt werden konnte. Überhaupt war die Zeit unser größter Gegner, weshalb ihr auch vieles zum Opfer gefallen ist.

Ein halbes Jahr später war die Engine schon ansehnlich. Die eigene Soundengine funktionierte schon recht gut, Stevie konnte sich bewegen, der Hintergrund scrollte, Gegner und Plattformen bewegten sich durch das Bild.

Auf dem Bild erkennt man auch schön ein paar Objekte in ihrer ersten Version. Bis zu Version 1.0 wurden fast alle Grafiken auf dem Bild mehrmals überarbeitet. Die Eigenschaften von Stevie, etwa die Laufgeschwindigkeit und die Sprungweite, standen hier schon fest und wurden erst in der Version 1.5 geändert.

Erstaunlich wenig geändert wurde der Editor, zumindest bis zur aktuell in Arbeit befindlichen Version 1.666. Der Editor ist im Vergleich zu anderen im 2D-Bereich sehr intuitiv zu bedienen. Dennoch gab es schon sehr früh für die Black-Chronos-Leute eine sehr umfangreiche Bedienungsanleitung. Das nachfolgende Bild zeigt den Leveleditor in seiner derzeit aktuellen Form.

Sehr wichtig war uns eine saubere Gliederung und eine übersichtliche Bedienung. Diese orientierte sich ein wenig an 3D-Studio-Max und dem Unreal-Editor. Zwischen der Version 1.5 und 1.666 kamen dann noch einige Features hinzu und die Bedienung wurde noch weiter vereinfacht. Mehr zum Leveleditor gibt es dann in einem extra Beitrag.

Zugegeben, es schaut ein wenig so aus, als hätte ein dreijähriger in Photoshop herum gekritzelt. Es handelt sich hierbei um eine Szene, die es nie ins Spiel geschafft hat. Am Anfang sollte man einige Monster auf einem Friedhof verkloppen, um dann dank eines Priesters in die Hölle zu gelangen. Gestrichen wurde die Szene, weil wir für nur ein oder zwei Levels ein komplettes Set an Grafiken hätten erstellen müssen. Der Aufwand war in der vorgegebenen Zeit einfach nicht drin. Die abgebildete Katze sollte übrigens in einer mutierten Form ein erster Gegner werden.

Das nächste Bild zeigt bereits eine gestellte Testszene mit den ersten Grafiken des Spiels. Hier sieht man noch deutlich den untentschlossenen Mix aus Rendergrafik und Comic.

Das nächste Bild beinhaltet weitere Grafiken sowie zwei Gegner, die es nicht bzw. nicht in dieser Form in das Spiel geschafft haben. Das „kleine Mädchen“ im Bild ist die Jungfrau, welche wie alle Gegner später wesentlich größer war und auch keine Haare mehr hatte.

Das mit den Haaren hatte einen simplen Grund. Die Frisur der ersten Version hatte über 20.000 lange Haare. Alle Haare wurden für jede Bewegung physikalisch korrekt berechnet. Das sah verdammt geil aus, brauchte aber enorm viel Zeit. Das Rendern lagerte ich auf einen zweiten Rechner aus und bei der Jungfrau war der PC eine gute Woche nur damit beschäftigt, die Haare zu rendern. Damit eine größere und bessere Version nicht so lange braucht, verzichtete ich darauf und sparte somit sehr viel Zeit.

Der Rest ist Geschichte.