Konkret standen wir vor zwei Problemen:

1. Die Waffe darf nicht zu stark sein.
2. Es muss Spaß machen, sie zu benutzen.

Mit der Stärke hatten wir es anfangs etwas übertrieben. Pistolenkugeln und Feuerbälle können immer nur dem Gegner schaden, den sie direkt treffen. Der Blitz dagegen radierte alles aus, was in seiner Reichweite lag, und das meist sogar bei der ersten Berührung. Die Ladezeit war sehr kurz, die Durchschlagskraft nahezu unbegrenzt und die Reichweite und der allgemeine Radius gigantisch (im Bild gelb). Als einzige Limitierung blieb die verfügbare Menge, aber auch da waren wir relativ großzügig.

In der aktuellen Version haben wir zuerst Obergrenzen festgelegt: 99 Pistolenkugeln, 75 Feuerbälle und maximal 50 Blitze kann unser Held ansammeln. Das hat zwei Effekte für den Spielfluss. Zum einen kann es nun viel eher passieren, dass eine Munitionsart tatsächlich verbraucht wird und der Spieler gezwungen ist, eine andere Waffe zu verwenden. Zum anderen wird der Spieler die Obergrenze in dem Moment bemerken, in dem er eine Munitionsart nicht mehr einsammeln kann, diese Verschwendung bedauern und bewusster immer genau diejenigen Waffen verwenden, für die gerade Munition zur Verfügung steht. Ich zumindest spiele so. Alles in allem wird so das Phönomen reduziert, dass Spieler stur bei einer Waffe und Strategie bleiben, die sich einmal bewährt hat. Die Einschränkung der verfügbaren Ressourcen sorgt so für mehr Abwechslung.

Im nächsten Schritt haben wir uns die Reichweite des Blitzes angesehen und dabei einen Fehler bemerkt: Irgendwann im Laufe der Entwicklung wurde dem Blitz ein zusätzliches blaues Leuchten spendiert. Da die Kollisionsmaske aber direkt aus den Grafiken erzeugt wird, wurde das Leuchten Teil der tödlichen Reichweite (im Bild gelb). Das blieb meist unbemerkt, in Grenzsituationen fiel jedoch auf, dass Gegner auch dann getroffen wurden, wenn sie noch ein Stück von eigentlichen Blitzstrahl entfernt waren.

Die Lösung war dank der vorausschauenden Arbeit meines Vorgängers wieder einmal bemerkenswert simpel: Zu jeder Animationsphase wurde eine Maske angelegt (im Bild rot), als PNG-Datei dazu kopiert und das war’s auch schon.

Als nächstes störte uns, dass fast alle Gegner schon beim ersten Treffer das Zeitliche segneten – und das auch noch bei allen gleichzeitig. Die Konsequenz war also, die Stärke der Waffe zu reduzieren und mehr Gegnern zu „erlauben“, einen Blitztreffer zu überstehen.

Das führte sofort zum nächsten Problem: Sehr schnelle Gegner wie der Mork schafften es, so schnell an unseren Helden heran zu kommen, dass keine Zeit zum Nachladen blieb. Solche Details führen zumindest bei mir zu frustriertem aber natürlich unnützem Herumgedrücke auf der Feuertaste und letztlich dazu, die entsprechende Waffe zu meiden. Also was tun? Die Lösung: Alle normalen Gegner (nicht die Bosse) machen kehrt und flüchten, sobald sie von einem Blitz getroffen werden (zumindest diejenigen, die es überleben). Das wirkt auch optisch sehr cool. Die Waffe fühlt sich auf einen Schlag viel mächtiger an, ohne wirklich durchschlagkräftiger zu sein (wir hatten sie im Gegenteil ja sogar abgeschwächt).

Die Flucht ist auch logisch gut zu begründen: Viele Gegner in Glow können nur im Nahkampf angreifen – sie treten, stechen oder schlagen. Wenn sie von einer Fernwaffe getroffen werden, müssen sie wissen, dass sie keine Chance haben und es besser wäre, in Deckung zu gehen und auf einen günstigeren Moment zu warten.

Die anderen beiden Fernwaffen haben wesentlich kürzere Ladezeiten, sind aber auch wesentlich weniger durchschlagkräftig und erlaubt keinen Rückzug auf eine sichere Distanz. Deshalb drehen die Gegner bei diesen Treffern nicht um sondern werden nur kurz abgebremst. Auch das wirkt sehr cool – wie ein Hollywood-Effekt.

I want both and I think this is my problem. I want to code, to paint and to make the project better and better. This is an infinite loop, I know. It’s always possible to make something better, to replace a sound, find a better fitting texture or a better compression algorithm, no matter how often the very same part was replaced before. From this point of view I don’t want to finish the project. In the moment it’s finished there is nothing more to do, nothing to improve, nothing to learn.

On the other side, it makes me happy if at least some people like what I do. In this case this implies finishing the game. An unfinished game can not be played.

Good news: The demo version (4 levels, 1 boss enemy) is almost finished. It will be released before christmas. This time we mean it.

Compare this image with the image in the previous post. No, thats not part of the final game. It’s just a litte joke a coder have while discovering all these little funny parameters in the Microsoft APIs. ;-)

Als Informatiker begeistert mich die unglaublich sauber implementierte Objektsstruktur am meisten. Jedes Objekt im Spiel hat im C++-Quelltext ein Äquivalent im Sinne der Objektorientierung. Stevie wird verletzt, indem seine Methode Player->Hurt(2) mit der Stärke der Verletzung aufgerufen wird. Ein Gegner stirbt? Enemy->Die(). Eine Tür ist zu öffnen? Einfach das passende Door->Unlock() absetzen.

Diese Methodenaufrufe schreien geradezu nach einem Event-System und tatsächlich wurde damals damit begonnen, ein solches zu implementieren. Leider war gerade das ein Punkt, der gegen Ende der geplanten Entwicklungszeit abgekürzt werden musste. Deshalb war im Spiel von 2007 nicht viel von dieser Ereignisbehandlung zu spüren. Stevie konnte Hebel umlegen und der Hebel öffnete eine Tür oder schaltete eine Blitzfalle aus. Der Tod eines Bossgegners beendete den aktuellen Level. Und das war es schon fast. Wie schade, dachte ich mir, und begann damit, an der Umsetzung weiterer Ideen zu arbeiten. Zum Beispiel:

• An einer bestimmten, vom Leveldesigner festgelegten Stelle tauchen hinter Stevie plötzlich neue Gegner auf und nehmen ihn überraschend in die Zange.
• Das Einsammeln eines Schlüssels löst einen Alarm aus und ruft einen besonders hartnäckigen Gegner herbei.
• Eine Tür schließt sich hinter dem Spieler wieder, um ihm dabei zu helfen, in größeren Labyrinthen nicht unendlich im Kreis zu laufen.
• Vor Stevies Nase knallt plötzlich eine Kiste oder sogar eine große Statue auf den Boden.
• Ein längerer Fahrstuhl wird erst durch die Anwesenheit des Spielers aktiviert und fährt genau im richtigen Moment los.
• Harmlos aussehende, inaktive Fallen werden bei Annäherung plötzlich aktiv und erschrecken den Spieler.
• In bestimmten Situationen, zum Beispiel wenn ein größerer Gegner stirbt, sterben auch alle verbliebenen kleinen Gegner im Umkreis.

Und so weiter. Der Fantasie der Leveldesigner (ihr erinnert euch, wir werden den Editor mitliefern) sind nur wenige Grenzen gesetzt. Es ist sogar möglich, solche Ereignisse an die Spielfigur Stevie Speed zu senden, so dass er zum Beispiel von selbst ein Stück läuft oder automatisch die Waffe wechselt.

Ein Trigger, der einen Gegner direkt hinter Stevie erscheinen lässt, sieht im Editor beispielsweise so aus:

Auslöser können sein:

• Hebel werden bewusst betätigt. Der Spieler muss Stevie vor den Hebel bewegen und ihn mit der Alt-Taste umlegen. Den Hebel, nicht Stevie. Hebel können allerdings nur einmal aktiviert werden. Das ist eine Designentscheidung von uns, um die Sache für den Spieler nicht unnötig kompliziert zu machen.
• Radius-Auslöser wie der oben im Bild sind im Spiel unsichtbar und werden ausgelöst, sobald sich Stevies Mittelpunkt innerhalb des Kreises befindet. Funktioniert ansonsten wie ein Hebel.
• Bei jedem anderen Objekt können an bestimmte Auslöser-Kommandos zusätzliche Kommando-Ketten gehangen werden. Zum Beispiel können zwei Gegner so verkettet werden, dass im Todesfall des einen Gegners sofort ein zweites Die()-Kommando an einen anderen Gegner gesendet wird.

Mögliche Kommandos sind:

• Die() sorgt dafür, dass das Zielobjekt, an das dieses Kommando gerichtet war, verschwindet. Die meisten Objekte verschwinden in diesem Fall ganz unspektakulär. Sie sind einfach weg. Gegner und auch unser Stevie sterben natürlich wesentlich spektakulärer und lösen sich in Feuer und Rauch auf.
• Hurt() verletzt einen Gegner. Da die Verletzungsstärke im Editor nicht als Parameter übergeben werden kann, wird dem Gegner in diesem Fall immer ein Lebenspunkt abgezogen.
• Activate() gilt nur für Objekte, die auf das Drücken der Alt-Taste reagieren, zum Beispiel Hebel. Das Kommando löst das selbe Ereignis aus wie das Drücken der Taste.
• Lock() schließt Türen und schaltet Blitzbarrieren ein.
• Unlock() öffnet dementsprechend Türen und Barrieren und entsperrt Lifte.
• ToggleInventory() und einige weitere Toggle-Kommandos öffnen das Inventar, das Menü, schalten das Spiel in den Pause-Modus und einiges mehr.
• Außerdem gibt es noch einen ganzen Satz Kommandos, mit denen sich die Spielfigur steuern lässt: Loslaufen, stoppen, springen, zur nächstbesseren Waffe wechseln. Der Spieler hat allerdings das Recht, jederzeit einzugreifen. Es gibt bewusst kein Kommando, um dem Spieler die Kontrolle zu entziehen.

Eine Art Enable()-Kommando (ich bin mir bei der Benennung noch nicht ganz sicher) fehlt aktuell noch. Es soll wie oben beschrieben dafür sorgen, dass Kisten und Gegner aus dem Nichts erscheinen können. Meine aktuellen Versuche sehen noch so aus, dass ich versucht habe, das schon existierende Unlock-Kommando für Gegner (die bisher nichts mit Unlock anfangen konnten) zu implementieren. Mit durchwachsenem Erfolg. Was passiert in einer hardwarenahen Sprache wie C++, wenn ein Objekt zerstört wurde (ein Gegner ist gestorben), aber andere Objekte verweisen noch immer auf diesen nun ungültig gewordenen Pointer (der Tod eines Bossgegners soll den Tod aller übrig gebliebenen kleinen Gegner auslösen)? Das Spiel stürzt mit Zugriffsverletzungen ab. Abfangen wie in C# oder Java kann man diese Fehler nicht, dafür ist C++ nicht konstruiert. Also was tun?

Mein Plan: Zuerst einmal schaffe ich ein neues Kommando für das Erscheinen von bis dahin unsichtbaren Objekten. Dann muss in einem zweiten Schritt das Eventsystem so umgebaut werden, dass es nicht mit C-Pointern arbeitet, die wie erlebt schwer zu beherrschen sind, sondern mit Objekt-IDs. Sprich: Mit den eindeutigen, in Textform vorliegenden Kennzeichnern der Objekte (z.B. EnemyRinger_7). Diese IDs werden zum Glück automatisch vergeben. Der Vorteil dieser Methode ist gleichzeitig der einzige Nachteil: In dem Moment, in dem ein Ereignis ausgelöst wurde, muss erst aufwendig nach dem Objekt mit der angegebenen ID gesucht werden. Das kostet im Vergleich wesentlich mehr Rechenzeit als das simple Auswerten eines Pointers, geht aber trotzdem noch so schnell, dass es der Spieler nicht merken sollte.

Und wozu der Aufwand? Wir wollen euch den Editor geben und ihr sollt damit so kreativ wie möglich sein können, ohne dass euch das Spiel abstürzt, nur weil ihr etwas kreativer mit den Triggern wart als wir. Deswegen der Aufwand.

Größe: 212 Megabyte

Inhalt: 3660 Dateien, 256 Ordner

Für ein Jump ’n’ Run ist das schon einiges und es wird sicher noch mehr.