Mine Bombers Remake mit Multiplayer-Implementierung (Android) / Sudo Null IT News

Bereits 1996 wurde das 2D-Arcade-Spiel Mine Bombers veröffentlicht: www.youtube.com/watch?v=iOHmVR0LINU

Ich erinnere mich, dass wir vier es stundenlang auf derselben Tastatur gespielt haben. Der Multiplayer-Modus war nur vom Hotseat-Typ, es gab kein Netzwerk.

Vor einem Jahr beschloss ich, einen Netzwerk-Multiplayer basierend auf dem Websocket-Protokoll zu erstellen und zu sehen, was passiert. Um ehrlich zu sein, gab es anfangs nicht einmal die Idee, ein Spiel für die Veröffentlichung auf dem Markt zu entwickeln.

Ich habe die Mechanik des Originalspiels beibehalten, auch die Pixelgrafiken belassen und versucht, mich nicht zu weit vom Original zu entfernen.
In meinem ersten Artikel wollte ich über die Backend-Architektur und das von mir implementierte Spielprotokoll sprechen.


Serverarchitektur

Ich habe Websockets als Hauptkommunikationsprotokoll gewählt.

Zum Zeitpunkt der Erstellung des Spiels hatte ich bereits Erfahrung mit dem Twisted-Python-Framework, also fiel die Wahl darauf.
Zufällig habe ich mich nie tiefer mit Threads befasst, das asynchrone Single-Threaded-Modell hat mich immer mehr beeindruckt (die erste Bekanntschaft damit war bereits 2003 – es war die Perl-POE-Bibliothek).

Um die Client-Server-Interaktion zu implementieren, habe ich mich für die Bibliothek entschieden Autobahndas eine Implementierung für Python hat – in Form eines Twisted-Moduls AutobahnPythonund für Java (siehe Client).

Redis hat zwei Rollen:

  • Speicherung von Inhalten und Spielerdaten
  • Weiterleiten von Nachrichten zwischen Prozessen über pubsub (Weitere Details unten)

Im Diagramm habe ich 3 Hosts als Beispiel für die Skalierung dieser Architektur gezeichnet. Im Moment ist alles auf dem gleichen Host. Im Falle einer Lasterhöhung ist es jedoch möglich, es auf andere Hosts zu verschieben.

Broadcast Server ist ein verdrehter Prozess, der die Warteschlange der Spieler verarbeitet, die Erstellung einer Spielsitzung initiiert und weitere Schnappschüsse der Spielwelt versendet, die von Arbeitern erstellt wurden.

Worker ist ein verdrehter Prozess, der die Spielszene (Welt) generiert, Spieleraktionen (Aktionen) akzeptiert und verarbeitet und Snapshots an den BroadcastServer sendet.

Broadcast-Server und Worker kommunizieren über Redis mithilfe des Nachrichtenmusters miteinander veröffentlichen-abonnieren. Um ihre Interaktion zu implementieren, wurde eine Bibliothek ausgewählt txredisapi. Es ermöglicht asynchrone Anfragen an Redis und ist als Twisted-Modul implementiert.

Jeder BroadcastServer kann mehrere Worker haben (obwohl jeder zwei im Diagramm hat – es kann eine unterschiedliche Anzahl von ihnen geben).

Registrar ist ein Webserver, der Spieler registriert, Spielsitzungen erstellt und als Front-End für Spieldaten fungiert. Um es zu implementieren, habe ich mich für ein Mikro-Framework entschieden Flasche.

Die Kommunikation zwischen dem Spielclient erfolgt über ein sicheres HTTPS-Protokoll.

Registrar Redis (RR) ist ein separater Redis-Server, Inhaltsspeicher: Artikelparameter, Levels, Spielerstatistiken. Es speichert auch Player-Sitzungen, die von BroadcastServer-Servern erstellt wurden.

Klient

Die Idee, ein Spiel zu kreieren, entstand insbesondere aus einem langjährigen Interesse an der Android-Plattform. Daher bestand das Problem der Plattformwahl als solches gar nicht.

Nachdem ich viele verschiedene Frameworks gegoogelt und ihre Vor- und Nachteile abgewogen hatte, entschied ich mich für die Bibliothek LibGDX.

An Portierungen auf andere Plattformen habe ich mich nicht beteiligt, obwohl die Bibliothek dies zulässt, sind solche Drängen bisher nicht aufgekommen.

Es wurde viel über libgdx auf Habré geschrieben und nicht nur, deshalb werde ich hier nicht auf die Beschreibung seiner API eingehen. Alle subtilen Punkte werden auf ihrem IRC-Kanal schnell gelöst (wenn es keine Probleme mit Englisch gibt).

Um den Websocket-Client zu implementieren, habe ich die Bibliothek verwendet AutobahnAndroid. Die API dieser Bibliothek ist ebenfalls recht einfach, es wird eine Verbindung mit dem Message-Handler in Form einer Switch-Anweisung hergestellt, bei der Daten basierend auf dem Nachrichtentyp verarbeitet werden.

Als Nachrichtenformat wird JSON verwendet. Um die Paketgröße zu reduzieren, werden Snapshots als größte Nachrichten mit gzip komprimiert.

Spielablauf

Beim Spielstart sendet der Client eine Autorisierungsanfrage „AUTH“ an den Registrar-Server und bei erfolgreicher Autorisierung wird eine Session im RR erstellt. Es erhält auch eine Liste mit Serveradressen (BroadcastServer) und einigen Spielinhalten (Bewertung usw. Spieleinstellungen).

Als nächstes wählt der Spieler einen Server aus der Liste aus:

Und die Art des Spiels, es gibt insgesamt 4:

Wenn das Gerät einen kleinen Bildschirm hat, ist es besser, auf einer kleinen Karte zu spielen (auf einer großen wird sie sehr klein sein). Ich habe den Kamerazoom nicht implementiert, da das Gameplay selbst darin besteht, alle Spieler auf dem Spielfeld zu verfolgen, und wenn sie hineingezoomt werden, verschwinden sie aus dem Blickfeld. Nun, aus Platzgründen auf dem Bildschirm.

Nach Auswahl des Spieltyps sendet der Client eine Anfrage an den ausgewählten BroadcastServer-Server, um sich mit der JOIN-Spielerwarteschlange zu verbinden, validiert wiederum die Sitzung des Spielers im RR und fügt sie, falls die Sitzung existiert, zur Spielerwarteschlange hinzu .

Der BroadcastServer verarbeitet periodisch die Warteschlange von Spielern und erstellt Spielsitzungen, indem er eine “CREATE GAME”-Anfrage an den ausgewählten Arbeitsprozess sendet. Der Arbeitsprozess erstellt eine Spielsitzung und sendet das Ergebnis als „GAME CREATED“-Nachricht. BroadcastServer sendet seine Antwort an die Spieler.

Es folgt eine Folge von Spielrunden (5), zwischen denen die Spieler im Laden einkaufen (das gesammelte Gold ausgeben).

Von Arbeitern erstellte Snapshots enthalten Änderungen an der Spielwelt und den aktuellen Status der Spieler. Der Client sendet nur “AKTION”-Nachrichten: Ändern der Bewegung des Spielers, Platzieren einer Bombe oder Aktivieren eines Artefakts. Dadurch wird die Möglichkeit des Betrugs ausgeschlossen, da der Client nicht für die Generierung der Szene verantwortlich ist.

Nach der letzten Runde sendet der Worker eine „GAME OVER“-Nachricht mit den Ergebnissen des Spiels und BroadcastServer sendet sie an die Spieler und aktualisiert auch die Statistiken im RR.

Innovationen

Alle Level im Spiel werden regelmäßig zufällig generiert. Es gibt keine vordefinierten Levels, obwohl die Idee zunächst war, einzigartige Levels zu erstellen und einen Editor zu erstellen. Dies ist einer der Punkte in der TODO-Liste, die in Zukunft implementiert werden können.

Eine der Neuerungen, die ich hinzugefügt habe, sind Bonuslevel, Labyrinthe mit Gold, sie sind ohne Mobs, was den Prozess des Goldsammelns einfacher und ruhiger macht, eine Art Pause. Jedes 5. Level im Spiel ist ein Bonus.

Screenshot des Bonuslevels Noch ein paar Screenshots

Auch im Spiel habe ich Artefakte wie In-App-Käufe hinzugefügt. Sie verbessern die Parameter des Spielers für einige Sekunden. Sie verursachen keine große Unausgeglichenheit im Spiel, da sie fast alle in einer Runde pro Spiel verwendet werden können (aber sie verschwinden nicht und können in jedem Spiel verwendet werden).

Ausgang

Um nicht gegen die Regeln von Habr zu verstoßen, erscheint der Name des Spiels und der Link dazu nirgendwo, ich kann es per PN senden, der Name des Spiels wurde geändert und sieht nicht aus wie das Original.

Ich habe kein Team, obwohl es Überlegungen dazu gab. Wenn Sie ein Spiel haben oder es gerade entwickeln und nicht wissen, wie man Multiplayer implementiert – schreiben Sie, wir können über dieses Thema sprechen.

Similar Posts

Leave a Reply

Your email address will not be published.