Schlagwort-Archive: Multiplayer

Wieder ist beinahe ein Jahr vergangen, seit ich den letzten Statusbericht zum SPACOLA-Remake abgeliefert habe, daher ist es nun ganz dringend an der Zeit, ein bisschen über die aktuellen Neuerungen seitdem zu plaudern. Bekanntlich habe ich eine ausgedehnte Winterpause eingelegt, so dass die Änderungen sich insgesamt in Grenzen halten, aber ein paar Fortschritte gab es durchaus. Die Entwicklung an dem Spiel verhält sich ein wenig wie ein Gletscher: Egal ob man sich heute, morgen, nächsten Monat oder nächstes Jahr danach erkundigt, wie weit das Spiel fortgeschritten ist, wird es immer so aussehen, als habe sich nichts bewegt – aber es bewegt sich doch! Und jede Änderung wird sogar schriftlich in meinem Devlog dokumentiert.

Smart-Aim

Die neueste Work-In-Progress-Version 0.92 bringt einige nette, aber hauptsächlich experimentelle Spielereien mit, die ich unbedingt ausprobieren wollte. Letztmalig kündigte ich die Möglichkeit eines Aimbots (Smart-Aim) für den Spieler an. Diesen habe ich nun tatsächlich eingebaut. Mit per Menü aktiviertem Smart-Aim muss der Spieler nur noch grob in die Richtung eines Gegners zielen und die automatische Zielhilfe passt den Schusswinkel bis zu einem gewissen Grad so an, dass ein Treffer garantiert ist. Wenn kein Treffer garantiert werden kann, greift die Zielhilfe dagegen nicht ein. Die Arbeit am im letzten Update-Artikel erwähnten Weapon-Interface ist vollständig abgeschlossen. Zusätzlich lassen sich nun ganz einfach per Mausrad die verschiedenen Waffen des Spielers durchschalten und im Spiel verwenden. Das muss nicht bedeuten, dass der Spieler im Endeffekt mehrere Waffen besitzt, aber er könnte theoretisch.

Eingabequellen

Nach dieser kleinen großen Baustelle eröffnete ich dann gleich die nächste, und so überarbeitete ich skrupellos die komplette Spielsteuerung. Meine Idee war die Entwicklung eines flexiblen InputReceiver-Interfaces, das es ermöglichen sollte, verschiedene Eingabequellen für Spieler-Inputs an die Spielerschiffe anzuschließen. Dies wird spätestens im Multiplayer-Modus ein sehr wichtiges Thema. Die konkreten InputReceiver-Implementierungen erzeugen getaktet (pro Update) einzelne „ControlActions“, also gekapselte Eingabedaten, die auf eine abstrahierte Maus und Tastatur anwendbar sind, um ein Spielerschiff und somit die Spielwelt zu beeinflussen. Genauer gesagt habe ich nun einen MouseInputReceiver, der (wie der Name schon sagt) direkt die Maus (und Tastatur) anzapft. Aber zusätzlich habe ich auch einen RemoteInputReceiver, der Benutzereingaben von anderen Mitspielern aus dem Netzwerk empfängt, einen ReplayInputReceiver, der Benutzereingaben aus einer persistierten Datenquelle einlesen und ausführen kann, und zuletzt einen BotInputReceiver, der in Echtzeit künstliche Benutzereingaben anhand eines vorgegebenen Regelwerks erzeugen kann. Moment … Replays? Bots?

Bots

Als ich über die technischen Möglichkeiten meiner dynamischen Gegner-KI, des fertigen Aimbots und der InputReceiver-Logik sinnierte, ist mir plötzlich aufgefallen, dass ich im Grunde schon die halbe Arbeit erledigt hatte, die nötig wäre, um einen kompletten Spieler-Bot zu entwickeln. Diese Idee hatte ich eigentlich schon zu Beginn des Projektes für Skirmish-Multiplayer-Spiele, wenn mal nicht genügend menschliche Mitspieler zur Verfügung stünden. Außerdem würde ein funktionaler Spieler-Bot mir die Arbeit beim Testen erleichtern, da ich nicht mehr gleichzeitig spielen und debuggen müsste, sondern mich auf das Wesentliche konzentrieren könnte. Allerdings fiel mir beim Implementieren auf, dass es wohl doch nicht so ein Spaziergang werden würde, wie ich zunächst dachte. Im Gegensatz zur Gegner-KI, die die Raumschiffe immer direkt steuern kann (drehen, beschleunigen, bremsen, schießen…), darf ein Spieler-Bot im Grunde nur Maus und Tastatur übernehmen, das Spieler-Raumschiff also indirekt mit simulierten Mausbewegungen und Mausklicks steuern. Mit Hilfe der InputReceiver war dies nun zumindest technisch kein Problem mehr. Aber natürlich musste die Logik dafür trotzdem erstmal geschrieben werden.

Nach einigen Tagen des Grübelns, Ausprobierens und auch Scheiterns hatte ich einen halbwegs glaubhaften Bot entwickelt, der in jedem Level losfliegen, bei Bedarf nützliche Powerups einsammeln, Gegner und Asteroiden beschießen und auch ins Ziel fliegen kann. Um das zu bewerkstelligen darf er im Grunde nur die Maus im Kreis bewegen, sowie die linke und die rechte Maustaste drücken. Er kann leider noch nicht ausweichen und ist auch sonst relativ blind und stur, aber er zielt immerhin ganz gut und gewinnt daher auch fast immer. Das Potenzial für Verbesserungen ist dafür enorm, z.B. müsste er verlorene Waren wieder einsammeln. Meine finalen Bemühungen, die Bewegungen des Bots realistischer zu machen, waren begrenzt erfolgreich. Dennoch ist das Ergebnis aus meiner Sicht schon beachtlich. Nebenbei fand ich eine deutlich bessere Methode, einen Abfangvektor zu einem beweglichen Zielobjekt im Level zu berechnen. Diese Methode habe ich mir sogar vorgemerkt, um sie bei der Gegner-KI einzubauen, als ich feststellte, dass das Ergebnis exakt genauso aussieht wie bei etlichen Gegnern im Originalspiel. Endlich war ich auf der richtigen Fährte, nachdem ich jahrelang keine Ahnung hatte, wieso meine KI sich immer irgendwie anders bewegt als im Original.

Replays

Gleich der nächste Knüller: Mit der Idee der InputReceiver konnte ich endlich Benutzereingaben im Spiel aufzeichnen und theoretisch jederzeit erneut ausführen. Fürs Aufzeichnen gibt es im Spiel nun einen ReplayRecorder, der die ControlActions pro Update ableitet und in einem Replay-Objekt speichert. Am Ende wird das Replay-„Tape“ finalisiert und kann im Speicher gehalten oder komprimiert in eine Datei gespeichert werden. Ein ReplayInputReceiver kann dieses Objekt wieder als Eingabequelle für den Spieler wählen. Vereinfacht gesagt, das komplette Gameplay eines Levels lässt sich aufnehmen und anschließend nochmal exakt identisch als Replay abspielen. Da die Aufzeichnung natürlich kein Film ist, sondern nur ein Protokoll aller Benutzereingaben auf einer Zeitachse, ist der Speicherbedarf geringer, aber das Replay anfällig für Veränderungen. Was ich damit meine, wird jetzt deutlich, wenn ich die nächste kleine große Baustelle erwähne, an der ich seit einigen Tagen arbeite.

Die Replays lassen sich zwar endlich perfekt aufnehmen und auch wieder abspielen, aber sie ergeben danach keinen Sinn mehr: Der Replay-Spieler macht zwar alles exakt so, wie das Tape es vorgibt, aber die Spielwelt eben nicht. Das Level sieht anders aus, die Gegner verhalten sich anders, nichts ist da wo es sein sollte. Folglich kracht der Spieler plötzlich wie ein Betrunkener überall dagegen, schießt meilenweit an den Gegnern vorbei, fliegt in die völlig falsche Richtung, und ist quasi nach wenigen Sekunden Gameover. Das Gameplay verlässt sich an sehr vielen Stellen auf Zufallszahlen, und auch die Levelgenerierung ist zufällig. Daran ist im Grunde gar nichts auszusetzen, da Spielentwicklung ganz ohne Zufallsgeneratoren kaum möglich wäre. Was mir nur noch fehlte, war der programmweite Einsatz von reproduzierbaren Zufallszahlen, die auf Basis eines gespeicherten Seeds funktionierten. Gleicher Seed bedeutete dann: Gleiches Level, gleiche Gegner, gleiches Verhalten, alles exakt gleich. Die Spielwelt musste vollständig deterministisch zufällig werden, und die Replays müssten den Seed speichern, der dann die Grundlage für das Replay bildet. Diese Umstellung ist leider sehr aufwändig und umfasst das Umschreiben vieler Bausteine der Levelgenerierung.

Spielereien

Nach diesem schwergewichtigen Problem möchte ich zum Schluss noch kleinere Physikspielereien erwähnen, die ich ins Remake eingebaut habe. Als kleine Option im Enhanced-Modus lassen sich die Stationen der Piraten quasi kugelsicher schalten, so dass die Geschosse des Spielers daran mit passendem Soundeffekt abprallen. Hierzu musste ich meinen Bounce-Code umschreiben, denn der sah bisher nur Kollisionen zwischen zwei beweglichen Objekten vor. Im Spezialfall einer Kollision zwischen einem unbeweglichen und einem beweglichen Objekt durfte eine Reaktion logischerweise nur auf das bewegliche Objekt erfolgen. Das Feuern auf die kugelsichere Station sieht schon recht witzig aus und die abgelenkten Kugeln fliegen einem um die Ohren. Ob das im fertigen Spiel Verwendung findet, steht natürlich auf einem anderen Blatt, aber es schadet nicht, wenn die Funktion schonmal eingebaut ist. Achja, eine weitere Option erlaubt jetzt das Zerstören der Stationen. Ich wollte einmal testen wie es aussehen könnte, wenn im Spiel ein großes Objekt gesprengt wird, und dabei kam diese kleine Funktion heraus. Es werden Unmengen an Explosionspartikeln erzeugt und die Station verabschiedet sich mit einem lauten Knall. Wie gesagt, natürlich nur eine Spielerei. Ergibt auch keinen Sinn, besonders dann nicht, wenn es die Zielstation war.

Eine letzte neue Option im Optionsmenü ist die Wahl der Spielgeschwindigkeit. Hierdurch lässt sich das Spiel mittlerweile erheblich verlangsamen. Für den Anfang kann man die Updaterate daher auf 1/2, 1/4, 1/8 oder 1/24 stellen. Dies ist allerdings nicht nur sinnlose Spielerei, sondern die erste Vorbereitung auf einen Rewrite der Spielengine, der früher oder später dringend nötig sein wird: Das völlige Entkoppeln von Update- und Drawrates, und die stufenlose Wahl der Spielgeschwindigkeit. Es muss also möglich sein, die Spielgeschwindigkeit z.B. drastisch zu reduzieren, aber trotzdem alle Spielobjekte weiter mit bis zu 72 fps flüssig zu bewegen. Denn aktuell bedeutet eine reduzierte Geschwindigkeit nur, dass die Spielwelt weniger oft aktualisiert wird, und dann spielt die Framerate eben keine Rolle. Das Spiel sieht dann leider nicht nach Zeitlupe aus, sondern nach Diashow.

Meilenstein

Es gibt da zwar noch so ein Thema, einen wichtigen Meilenstein, den ich unbedingt erläutern möchte, aber das werde ich demnächst in einem separaten Artikel abhandeln, da es sehr umfangreich wird.

Promo OXYD3D-Logo

Seit Jahren beschäftige ich mich auf meiner kleinen Webseite als großer Fan mit den Spielemeisterwerken von Meinolf Amekudzi und seiner Firma Dongleware, doch nie zuvor war es mir vergönnt, tatsächlich eine Neuigkeit direkt von dort zu vermelden. Vor kurzem hat Meinolf es in einem knappen Kommentar zu einem YouTube-Video von mir angedeutet, aber seit der Spielemesse Gamescom ist es offiziell: OXYD lebt! Meinolf arbeitet an einem echten Remake seiner bekannten Spielereihe. Seit OXYD magnum! Gold aus dem Jahr 1998 wird es erstmals wieder ein Originalspiel vom Schöpfer der Serie geben.

New versions of Oxyd® will be available in 2018. The new implementations will include a landscape designer, a WebRTC multiplayer mode, classic game restorations, a browser implementation, native mobile and desktop 3D apps and many more. Regards Meinolf.

Inzwischen gibt es einen Artikel auf heise.de (danke an Gerry für den Hinweis!), in dem über das geplante Remake berichtet wird. Dort ist unter anderem die Rede davon, dass es kostenlos im Browser spielbar sein wird, und dass es möglicherweise dieses Jahr noch online geht. OXYD soll einen Multiplayer-Modus mit bis zu 8 Spielern gleichzeitig bekommen. Außerdem will Meinolf sogar den Landschaftseditor beilegen, den er damals bewusst immer unter Verschluss gehalten hat (Wortlaut: „nicht käuflich, Anfragen zwecklos!“). Das wäre also ein echtes Novum. Aber der größte Knaller in meinen Augen ist, dass es so klingt, als wolle er sämtliche Original-Landschaften dem Remake beilegen (wenn Esprit damit ebenfalls gemeint ist, reden wir hier von über 600 Landschaften!).

Gamescom-Demo des OXYD Landscape Designers

Den Screenshot im heise-Artikel habe ich mir mal zur Analyse etwas näher angesehen. Dazu habe ich das Foto ganz unprofessionell entzerrt und geschärft, damit man es etwas besser erkennen kann. Dafür komme ich wahrscheinlich in Teufels Küche, aber das Risiko gehe ich jetzt einfach mal ein. Der auf dem Screenshot abgebildete Ausschnitt stammt übrigens aus dem klassischen OXYD, genauer gesagt Landschaft Numero 100 der Zweispieler-Link-Landschaften (also im Prinzip Landschaft 200). Da man rechts im Bild alle möglichen Steine auswählen kann, und außerdem die Landschaften untereinander aufgelistet werden, wird das wohl der Editor sein. Oben steht sowas wie „OXYD LandscapeDesigner“, darunter scheint ein Tab mit der Überschrift „Classic“ ausgewählt zu sein. Viel mehr kann ich nicht erkennen.

Die Tatsache, dass der Editor das Original-Tileset mit der Monochromgrafik der Atari ST Urversionen zeigt, freut mich ganz besonders. Diesen Grafikstil findet man heute nur noch sehr selten. Wenn also nicht nur der Editor so aussieht, sondern sich das Spiel auch mit dieser Grafik spielen lässt, wäre das eine Sensation für jeden echten Fan. Womöglich könnte es auch machbar sein, das Tileset mit einem simplen Mausklick z.B. auf die Farbversion der General Edition umzuschalten, oder auf die (eher gewöhnungsbedürftige) Grafik von Per.Oxyd. Je mehr Optionen die Fans bekommen, desto besser ist es. Ob das Remake auch mit den Magic-Steinen kommen wird?

Ausschnitt aus der Link-Landschaft #100 aus OXYD

OXYD oder OXYD3D? Angekündigt wurden eine Browserimplementierung (wie im Screenshot zu sehen), native Mobilversionen und „Desktop 3D-Anwendungen“. Offen bleibt, welche Desktop-Plattformen gemeint sein werden (alle?). Außerdem ist nicht sicher, ob der zur Gamescom demonstrierte Editor für ein klassisches 2D-Remake konzipiert ist, oder ob es hier doch um eine echte 3D-Fassung geht. Es gibt im Netz neue, offizielle Artworks, in denen es einmal einen normalen OXYD-Schriftzug und einen mit dem Text „OXYD3D“ gibt. Was auch immer am Ende herauskommt, ich bin sehr gespannt.

Ebenfalls unklar ist, unter wessen Dach das neue Remake eigentlich entsteht: Die Dongleware Verlags GmbH, die Application Systems Heidelberg, oder doch jemand ganz anderes? Es gibt Hinweise darauf, dass die Marke Oxyd schon seit 2013 nicht mehr bei Meinolf liegt, sondern bei der Hamburger Spieleentwicklerfirma Xyrality. Dort hat man für das Jahr 2014 ein Oxyd-Remake in Kooperation mit Meinolf für Tablets und Smartphones angekündigt. Inzwischen ist man dort wohl doch etwas in Verzug geraten:

We will also launch Oxyd – a puzzle game that was originally released for the Atari ST. We loved this classic game so much that we had to reincarnate it. So, together with the original creator, Meinolf Amekudzi, we’re developing a cool version for smartphones and tablets.

Unabhängig davon wem das Spiel letztlich gehören wird, welche Grafik es haben, und wieviele von den guten alten Landschaften es mitbringen wird, als alter Atari-Mausschubser bin ich sehr dankbar für ein echtes Lebenszeichen von der legendären Spielefirma Dongleware. Die Dongleware-Webseite wurde im Jahr 2002 geschlossen, und erst im Jahr 2012 – leider ohne jeden Hinweis auf die Spielehistorie – erneut geöffnet. Ich bin sehr froh darüber, dass Meinolf sich endlich wieder mit der Spieleentwicklung befasst. Ohne seine Spiele wäre ich sicher nie Programmierer geworden. Ein wenig Heldenverehrung gehört also dazu, wenn ich sage, dass ich mich wie verrückt auf das Ergebnis freue, und ich mich dann auch nicht mehr mit Enigma quälen muss. Denn wenn ich ehrlich bin, hat sich Enigma nie so wie das Vorbild angefühlt. Es war einfach nicht OXYD genug.

Weitere Quellen:
http://www.dongleware.com/index.php (Dongleware-Webseite)
https://mobile.twitter.com/oxydgames (Oxyd auf Twitter)
http://www.youtube.com/user/dongleware (Dongleware auf YouTube)
https://www.youtube.com/channel/UC_hzUVdY5yCheofCEdGQuYg (Oxyd auf YouTube)
https://www.facebook.com/oxyd.games/ (Oxyd auf Facebook)

Richtig, im Dezember hatte ich bereits zwei Beiträge zur Remake-Thematik veröffentlicht, aber ich muss meine kreative Zeit auskosten solange sie noch nachwirkt. Ich bin erstaunlicherweise noch nicht in den Entwicklungs-Winterschlaf gefallen, so wie sonst bei mir durchaus üblich. Im Gegenteil. Der kalte Januar ist noch lange nicht vorbei, und das Changelog für diesen Monat ist bereits das aktivste seit Bestehen des Projekts. Solange meine Motivation weiter ungebrochen ist, wollte ich etwaige Fans daran teilhaben lassen, denn die nächste faule Phase ist so sicher wie das Amen in der Kirche.

Den Schwerpunkt legte ich im Januar auf das Beischleppen von Ressourcendateien, damit ich wenigstens diesen Arbeitsschritt vielleicht irgendwann einmal endgültig abhaken könnte. In den vergangenen Wochen spielte ich daher viel SPACOLA – also die Originalversion. Inzwischen bin ich bei Level 57 von 64 angelangt. Auf dem Weg dorthin kamen hunderte von Screenshots zusammen, die ich mit Hilfe von GIMP bearbeitete. Weit über 120 Sprites sind seit Version 0.39 vom Dezember hinzugekommen, außerdem mindestens acht neue Soundeffekte. Was die Original-Sounds angeht, dürfte ich so ziemlich fertig sein. Viele neue Gegnertypen sind nun im Remake zumindest „enthalten“ (ohne ihre entsprechende KI).

Momentan stehe ich vor einem zusätzlichen Problem. Etwa ein Drittel der Gegner wird im Handbuch des Spiels dokumentiert. Bei einem weiteren Drittel kann ich mir deren Namen aus den internen Dateien des Spiels halbwegs zusammenreimen. Beim letzten Drittel der Gegner habe ich keine Ahnung, wie diese heißen könnten, ich kenne höchstens ihre Anfangsbuchstaben. Hier bin ich nun angelangt, so dass ich jetzt namenlose Spritesets habe, die ich so nicht ins Remake einbauen kann. Überhaupt, wenn ich schon beim Thema Handbuch bin: Ich bin unsicher, nach welchen Kriterien die Entwickler sich entschlossen, Gegner im Handbuch zu erwähnen, und andere wiederum auszulassen. So werden beispielsweise die mit Lenkraketen bewaffneten Cargoliners im Handbuch beschrieben, die sogar erst tief in der zweiten Hälfte des Spiels auftauchen, aber die tödlichen Peashooters (intern: „Pigs“), mit denen man es quasi ab der ersten Spielsekunde zu tun bekommt, werden gar nicht erwähnt. Diese gehören eigentlich zu den frustrierendsten Gegnern im Spiel, da sie sehr gut zielen.

Im letzten Drittel des Spiels bekommt man es mit zwei sehr exotischen „Gegnern“ zu tun: Der Defender, sowie die Kaulquappe aus dem OXYD-Vorgänger Esprit. Als ich noch ein Kind war, hatte ich mit dem hohen Schwierigkeitsgrad wirklich zu kämpfen. Sich den zahlreichen schwerbewaffneten Gegnern zu stellen, hatte oft ein frühes Gameover zur Folge, weshalb ich viele Levels nur bewältigen konnte, indem ich ziellos herumballerte und wie ein Irrer im Affenzahn zum Ausgang flog. Stehenbleiben war keine Option. Sobald ein Gegner auf dem Bildschirm auftauchte, hieß es schießen oder abgeschossen werden, weshalb ich auch keine nähere Bekanntschaft mit dem Defender oder der Kaulquappe machen konnte. Vor kurzem ist mir aufgefallen, dass diese Schiffe dem Spieler gegenüber gar nicht so feindlich auftreten. Der Name des Defenders trifft es ganz gut: Er umkreist den Spieler, und rammt sämtliche Piraten aus dem Weg. Zu Anfang fand ich das ganz nett. Nach einer Weile bemerkte ich aber, dass der Pilot des Defenders vielleicht auf den einen oder anderen Schnaps hätte verzichten sollen: Es kommt zu oft vor, dass er versehentlich den Spieler rammt und zerstört. Absicht oder nicht, sowas nervt ein wenig.

Die Kaulquappe ist jedoch durch und durch ein äußerst nützlicher Helfer. Sie fliegt los, sammelt verlorengegangene Waren ein, und bringt sie dem Spieler zurück. Ich war ziemlich baff als ich dieses Verhalten entdeckte. Dummerweise ist die Kaulquappe ein häufiger Kollateralschaden bei hitzigen Feuergefechten, so dass man auf diesen Vorzug schon sehr früh wieder verzichten muss. Ich schätze das ist Absicht. Was ich nun an SPACOLA extrem schade finde: Obwohl sich die beiden Entwickler des Originals so sehr Gedanken um ihr Spiel gemacht hatten, dass sie sogar hilfreiche Figuren einbauten, wird der Spieler nicht nur im Handbuch darüber völlig im Dunkeln gelassen, er bekommt nicht einmal während des Spiels die Zeit, diese Figuren kennenzulernen. Ich habe SPACOLA mit meinen 7 oder 8 Jahren vielleicht 5 mal durchgespielt, aber erst heute erfahren, dass es nicht nur Feinde im Spiel gibt. Nun, ich habe mit dem Remake jetzt sogar mal die Gelegenheit, ein paar vorsichtige Anpassungen vorzunehmen.

Ein kleines neues Feature, das es im Originalspiel nicht gibt: Mit TAB kann man zur Zeit die Kamera umschalten, so dass man z.B. zwischen eigenem Spielerschiff und Raumstation wechseln kann. Ist eigentlich nur ein Test, um zu sehen, was ich noch alles machen könnte. In die Einspielerkampagne des Hauptspiels wird diese Funktion definitiv keinen Einzug finden, aber im Multiplayer-Modus wird das absolut nötig sein, um seine Mitspieler im Auge zu behalten, bzw. um als Zuschauer nach dem Gameover wenigstens noch einen guten Blick auf das Geschehen zu haben.

Thema Multiplayer: Die ersten Vorbereitungen hierzu habe ich jetzt einfach mal getroffen. Spielen kann man so noch nicht, aber es gibt jetzt zumindest technisch die Möglichkeit, als Server zu hosten und auf Mitspieler zu warten, und die Clients können sich schon übers Netzwerk beim Server anmelden. Sogar entsprechende Performance-Tests habe ich schon durchgeführt, so wird mit dem Anmelden der Clients permanent der Ping gemessen, und einen Timeout-Mechanismus, der verlorengegangene Clients vom Server wirft, gibts auch schon. Ich schätze, in einer der nächsten Versionen werden sich Spieler im Multiplayermodus zumindest gegenseitig sehen können.