Schlagwort-Archive: Framerate

Berichte über das Ende von SuccessDenied sind stark übertrieben. Ich hatte in letzter Zeit weder besonders viele Themen über die ich schreiben wollen würde, noch war ich überhaupt in der Stimmung, etwas zu schreiben. Beruflich bin ich zur Zeit unabkömmlich. Hinzu kommt, dass ich seit meiner letzten Erkältung vor über fünf Wochen zwar längst nicht mehr krank bin, aber leider auch nicht richtig gesund. Wieder einmal schleppe ich einen wirklich besonders hartnäckigen, unproduktiven Husten mit mir herum. Mehrmals täglich inhaliere ich daher mit meinem Kompressor-Druckluftinhalator Kochsalzlösung mit Mucosolvan, schmiere mich mit Mentholsalbe ein, trinke Hustenlöser, nehme Tropfen ein – die ganze übliche Palette eben, ohne dass irgendetwas davon irgendwie helfen würde. Mit meinen guten Genen bin ich schon sehr gesegnet.

Aber: Wenn die Gesundheit eines Tages zurückkehrt, bin ich sicher, dass ich auch meine gute Laune zurückerhalten werde. In der Zwischenzeit ein kleines Update zum SPACOLA Eclipse Remake-Projekt. Das Projekt steht ganz und gar nicht still, sondern wird wöchentlich mit Änderungen und Neuerungen versehen. Die aktuelle WIP-Version 0.57 vom Juli bringt wieder viele kleine neue Funktionen mit, und sogar eine größere. Aber auch ein paar Änderungen der vorhergehenden Versionen dürfen hier nicht unerwähnt bleiben. Der nüchterne Screenshot soll einen Einblick in das Debug-Menü geben, das ich um einige Einträge erweitert habe. Beim Testen sind die vielen Kommandos äußerst hilfreich, sonst spielt man sich dumm und dämlich, wenn man zum 50. Mal dieselbe Stelle im Code geändert hat.

spacolaeclipse57

Remake-Technik

Die 2D-Grafikengine zeigt jetzt bei Bedarf ein paar Dinge an, die das Original nicht hatte: Sektorgrenzen, Hüllkreise, Objekttypen, Spielernamen (für den Multiplayer-Modus), außerdem natürlich die Partikeleffekte, Interpolation und Pixelvergrößerung. Mal davon abgesehen, erlaubt es das Remake, einige Limitierungen des Originals aufzuheben, die damals vermutlich aus Performancegründen nötig waren. Beispielsweise Objekte, die sich zu weit vom Spieler entfernt hatten, wurden im Original aus dem Spiel genommen. Heute könnte man diesen Löschmechanismus herausnehmen und dadurch eine persistentere Spielwelt bekommen. Der Dongleware-Fadein/Fadeout-Effekt, den ich vor ungefähr 4 Jahren mühsam implementiert hatte, war leider fehlerhaft. Inzwischen ist er eine absolut pixelgetreue Nachbildung.

Maforianer-Gegner fertig

Es hat lange gedauert und mir sind dabei viele graue Haare gewachsen: Der Maforianer, einer der ersten drei Gegner, ist mehr oder weniger komplett fertig. Das Bewegungsmuster dieses Gegners ist vermutlich eines der einfachsten im Spiel, aber bei weitem nicht so leicht nachzuimplementieren, wie man meinen möchte. Inzwischen bin ich an einem Punkt angelangt, wo mein Ansatz der Vorlage nahe genug kommt, so dass man es vorerst so lassen könnte. Dadurch bin ich auch auf die Spur eines neuen mathematischen Ansatzes für die Schiffsnavigation der Gegner gekommen – und habe zufällig auch die Lösung für das Problem mit dem Magnetismuseffekt gefunden. In der Folge bewegen sich die Gegner jetzt realistischer, und die Anziehung von Containern, Waren und Piraten sieht viel besser aus als vorher. Der Maforianer hetzt jetzt dem Spieler permanent hinterher, jagt ihm nach Möglichkeit die Lieferwaren ab und flieht damit zu seiner Piratenstation. Es ist noch nicht alles hundertprozentig, aber es ist besser als nichts. Fehlen für den ersten Level also nur noch zwei weitere Gegner, mal sehen wann mir das gelingt.

Abspann

Im Remake kann man sich – genau wie im Original – das „Zertifikat“, also die Siegerurkunde ausdrucken lassen, sobald man den letzten Level gewonnen hat. Zusätzlich gibt es im Remake nun einen echten Abspann (die Closing Credits), in dem viele beteiligte Personen genannt und Danksagungen zum Ausdruck gebracht werden. Diese kleine Erweiterung wollte ich in jedem Fall im Remake drin haben, denn sie macht ja schließlich auch nichts kaputt. Mir fällt tatsächlich nun außerhalb des laufenden Spiels nichts mehr ein, das ich noch nicht fertig habe. Eigentlich eine gute Nachricht.

Timings

Timings sind mir seit einigen Monaten ein großes Ärgernis gewesen. Nachdem ich am Anfang meistens gesagt habe „Diese oder jene Animation läuft ungefähr 4 Sekunden“ und das dann auch so eingebaut habe, ging ich nun endlich dazu über, die exakte Anzahl Frames zu zählen. Wenn dann beispielsweise 270 Frames herauskommt, muss ich das wiederum umrechnen auf die Zielframerate von aktuell 50 fps. Das wären dann etwa 187 Frames, damit die Animation genauso lange läuft. Ähnlich verhält es sich mit den Konstanten für Gegnerverhalten: Wenn ein bestimmter Gegner 120 Frames braucht, um sich um 180 Grad zu drehen, dann braucht derselbe Gegner im Remake dafür nur noch 83 Frames. Und da sich die Framerate beliebig einstellen lassen wird, muss diese Berechnung wiederum variabel sein. Zusammengefasst habe ich viel Zeit damit verbracht, die Dinge, die eigentlich schon fertig waren, nun auch bezüglich der Original-Timings anzupassen.

Gegner-Deployment und -Redeployment

Das Deployment und Redeployment von Gegnern ist nun wesentlich näher am Original. Alle paar hundert Frames wird ein Gegner in der Station generiert. Dann beginnt dieser sich zu drehen, und zum Spieler auszurichten. Wenn die Ausrichtung stimmt, gibt er Schub und beginnt die Jagd. Dafür gibt es eine Gegner-Warteschlange, die sich aus den Anweisungen der Gegnerkonfigurationen im Levelskript zusammensetzt, und es gibt die Redeployment-Warteschlange für Gegner, die gestohlene Ware abgeliefert haben. Leider verstehe ich den Zusammenhang mit den Levelskripten noch nicht so ganz, daher ist die Unschärfe hier sehr groß. Ich kann aktuell nur nachbilden was ich sehe, und viel sehe ich nicht.

Es sind wie gesagt viele Kleinigkeiten, die nach und nach besser werden. Das Ziel für den ersten komplett spielbaren Level ist schon sichtbar, jetzt heißt es dranbleiben und das Tempo steigern. Die zwei verbliebenen Gegnertypen (für Level 1) werde ich wohl in Kürze angehen müssen, und mich zur Not auch damit anfreunden, wenn das Ergebnis dann nicht perfekt wird.

Junge pickelgesichtige minecraft-zockende Gamer verstehen nur wenig von ihrem eigenen … nunja … „Fachgebiet“. Das musste ich jedenfalls vor kurzem feststellen. Was ich zuerst für einen traurigen Einzelfall hielt und ignorierte, begegnete mir in den letzten Wochen so häufig, dass ich die Angelegenheit genauer analysieren musste. Ich habe die Probe gemacht und einige Meinungen zu dem Thema eingeholt. Man berichtete mir von ähnlichen Beobachtungen, was meine These bestätigte. Es scheint fast so als würde es bei dieser neuen Generation von Gamern überall laggen – vor allen Dingen im Gehirn.

Junge razermaus-schwingende headset-tragende Gamer sind zu blöd zwischen ruckeliger Grafik und einem Lag zu unterscheiden. Aber wir uncoolen Oldschooler kennen den Unterschied zum Glück noch, und müssen die Begriffe daher nicht wie Opfer hilflos durcheinanderwerfen. Daher keine Sorge: Mit Hilfe meiner fettkrassen Lehrstunde werden diese armen Seelen vielleicht nicht dumm sterben müssen. Also zumindest nicht ganz so sehr wie zuvor.

Beginnen wir mit einer einfachen Definition der beiden Fachbegriffe. Da ist zunächst der (oder das) sogenannte Lag. Ein Lag entsteht durch einen Engpass bei der Datenübertragung in einem Netzwerk. Er zeigt sich etwa als zeitliche Verzögerung zwischen Aktion des Spielers auf der Tastatur und entsprechender Reaktion der Spielfigur auf dem Bildschirm eines Spieleclients. Wahlweise könnte er auch als Input-Lag gemeint sein, wenn beispielsweise die Mausbewegung spürbar nachzieht. Beides habe ich in diesem Zusammenhang kennengelernt. So ein Lag bewegt sich in einem Bereich von wenigen hundert Millisekunden bis mehreren Sekunden. Ein Lag lässt sich dadurch an einem hohen Ping messen.

Kennen junge Gamer übrigens auch nicht: Netzwerkkarte, BNC-Stecker und T-Stück

Ruckelnde Grafik entsteht vorwiegend wenn die Hardware, die für das Rendern des Bildes zuständig ist, die benötigten Grafikoperationen nicht ausreichend schnell durchführen kann, bis das Bild gezeichnet werden soll. Es entsteht ein zeitlicher Rückstand, der nur kompensiert werden kann, wenn darauf folgende Bilder übersprungen werden (Framedrop). Das Bild ruckelt oder „stottert“. Die Bewegungen sind nicht flüssig, sondern abgehackt, wie ein Daumenkino. Manche sprechen im Extremfall auch von „Diashow“. Der Effekt wird verstärkt oder abgeschwächt, je nachdem wieviele Objekte auf dem Bild gerade zu sehen sind. Ruckelnde Grafik äußert sich in einer niedrigen Framerate, also alles zwischen 0 fps und 25 fps.

Bei einem Lag ist die entscheidende Komponente das Netzwerk und die Netzwerkhardware, etwa wenn im Hintergrund zuviele Downloads/Uploads laufen, und die restliche Bandbreite nicht mehr für die Datenübertragung im Spiel ausreicht. Dagegen ist es bei ruckelnder Grafik die CPU oder die Grafikkarte, beispielsweise weil die Auflösung zu hoch eingestellt ist und so die Kapazität der Hardware übersteigt.

Wir merken uns: Lag – hoher Ping. Ruckelnde Grafik – niedrige FPS. Lag – Spielfiguren reagieren verzögert auf Eingaben oder teleportieren plötzlich wie Zauberer in der Spielwelt herum. Ruckelnde Grafik – Diashow-Effekt, Animation der Spielgrafik ist abgehackt und nicht flüssig.

Wir folgern daraus: „Lag“ ist der falsche Begriff für das was diese Konsumenten DRM-verseuchter Spielekost meinen. Eigentlich meinen sie etwas, das man als „Ruckeln/Ruckler“, „Framedrop“, „low FPS“ oder „scheiß Framerate“ bezeichnen könnte. Es gibt sicher noch bessere Begriffe. Man denke nur mal an die Probleme mit den „Mikrorucklern“ bei einer SLI/Crossfire-Konfiguration von Grafikkarten, die man vor einigen Jahren noch von NVidia und ATI kannte. Niemand wäre auf die Idee gekommen, das Problem „Mikrolag“ zu nennen. Es sind eben keine Lags. Ein Lag ist was anderes.

Das Spiel ruckelt und der unaufgeklärte Gamer flucht: „Wieso laggt das denn so?“. Solche Szenen gehören mit diesem großartigen Artikel hoffentlich bald der Vergangenheit an. Ich bin zuversichtlich, die Welt damit ein bisschen besser und ein bisschen schlauer gemacht zu haben. In der nächsten Folge erkläre ich dann, warum HTML keine Programmiersprache ist. Achja: Dieser Artikel kann Spuren von Satire und Islamkritik enthalten!

Zur Zeit gibt es leider gar nicht soviel Neues zu berichten, daher gebe ich einfach mal einen kurzen Update-Bericht zum besten, über mein kleines Hobby-Spieleentwicklungs-Projekt Spacola Eclipse, dem Java-Remake des Ur-Spacola von 1991. Ich will ja nicht, dass noch Leute denken, dass das Projekt gestorben wäre, was es definitiv nicht ist. Hier kamen bisher eigentlich drei Probleme zusammen: Zum einen wenig Zeit. Dann noch eine komplett unkreative Phase, die mich immer sofort ins Schwitzen brachte, wenn ich die Entwicklungsumgebung auch nur versehentlich mit der Maus streifte.

Zuletzt war da ja noch die Sache mit der Neuimplementierung des kompletten Grundgerüstes, die ich vor einigen Monaten ankündigte. Das Spiel war in seiner Form einfach nicht mehr erweiterbar, weil ich einen Turm auf einem Fundament aus Designfehlern baute, der ins Wanken geriet, sobald man den Code anfassen wollte. Daher hab ich kurzerhand einfach alles abgerissen. Tja, und dann war das Spiel natürlich kaputt. Blöde Sache.

Diese Woche habe ich angefangen einige neue Designs für das Spiel zu basteln, darunter Splashscreens, ein neues Titelbild, und ein witziges Logo für eine fiktive Softwarefirma. Und auf einmal war die unkreative Phase weg. Ich habe mir das Trümmerfeld, das sich mal Quellcode nannte, vorgenommen, und beinahe innerhalb einer Nacht das neue Grundgerüst fertiggestellt, mit seiner eigenen kleinen komplett monochromen 2D-Grafikengine. Dazu viele nette Gimmicks, z.B. eine FrameStopWatch-Klasse, die nur dafür zuständig ist, die Framerate und die Anzahl der Spielweltupdates zu überwachen und dynamisch an die Leistung des Rechners anzupassen.

Endlich ist das Grundgerüst richtig objektorientiert und das Programm besteht nun aus deutlich mehr Klassen als vorher, so dass jede Klasse ihre eigene ganz spezielle Aufgabe übernimmt. Nun, bei aller Geilheit für Objektorientierung, optisch hat sich an dem Spiel logischerweise fast gar nichts geändert, außer, dass es jetzt eben in der Theorie deutlich effizienter bzw. schneller läuft. Erwähnenswert ist vielleicht noch, dass ich die hässliche Java-Kaffeetasse durch ein provisorisches Icon ersetzt habe. Spielbar ist es daher noch nicht, aber immerhin bewegt sich schon wieder was: