Ist ein Echtzeit-Multiplayer-Spiel mit Google App Engine machbar?

8

Ich entwickle derzeit ein Echtzeit-Multiplayer-Spiel und habe verschiedene Cloud-basierte Hosting-Lösungen evaluiert. Ich bin mir nicht sicher, ob App Engine meinen Anforderungen entspricht, und wäre für jede Rückmeldung dankbar.

Im Wesentlichen möchte ich, dass das System so funktioniert: Spieler A berechnet Runde n und erzeugt am Ende dieser Runde einen Hash aus dem Spielstatus. Er sendet dann seine Befehle für diese Runde und den Hash, als HTTP-POST an den Server. Spieler B macht das Gleiche parallel.

Während der Server den POST von einem Player aus behandelt, schreibt er zuerst den empfangenen Hash-Code in den Memcache. Wenn der Hash des anderen Spielers noch nicht im Memcache ist, wartet er und überprüft periodisch den Memcache auf den Hashwert der anderen Spieler. Sobald sich beide Hashes im Memcache befinden, vergleicht es sie auf Gleichheit. Wenn sie gleich sind, sendet der Server die Befehle jedes Spielers an die jeweils andere als HTTP-Antwort.

Eine solche Runde sollte etwa eine halbe Sekunde dauern, also zwei Anfragen pro Spieler pro Sekunde.

Natürlich funktioniert diese Vorgehensweise nur, wenn mindestens zwei Instanzen der Anwendung ausgeführt werden, da zwei Anfragen parallel bearbeitet werden müssen. Außerdem muss der Speicher-Cache über alle Instanzen konsistent sein, ziemlich zuverlässig sein und sofort aktualisiert werden.

Ich kann XMPP nicht benutzen, weil ich möchte, dass mein Spiel in eingeschränkten Netzwerken läuft, also muss es auf Port 80 beschränkt sein.

Gibt es eine Möglichkeit zu erzwingen, dass zwei Instanzen der App immer ausgeführt werden? Gibt es offensichtlich offensichtliche Mängel in meinem Design? Glauben Sie, dass eine solche Architektur in App Engine funktionieren könnte? Wenn nicht, welche Cloud-basierte Lösung würden Sie vorschlagen?

    
Markus Roth 18.02.2011, 18:51
quelle

1 Antwort

13

Ich glaube, das könnte funktionieren. Die wichtigste API, die Sie kennen lernen sollten, ist wahrscheinlich die Channel-API . Dies würde die Kommunikation zwischen dem Client und dem Server ermöglichen.

Das nächste Thema, um das wir uns kümmern müssen, wäre Memcache. Im Allgemeinen ist es zuverlässig, aber im engeren Sinne sollen wir annehmen, dass Memcached-Daten jederzeit verschwinden können.

Wenn Sie sich entschließen, dass Sie nicht riskieren, die Daten so zu verlieren, müssen Sie sie im Datenspeicher beibehalten, was bedeutet, dass Sie experimentieren müssen, um sicherzustellen, dass Sie 2 Züge pro Runde aushalten können. Ich denke, das ist möglich, aber nicht trivial. Wenn du 1 Zug alle 3 Sekunden gesagt hättest, würde ich sagen "kein Problem". Aber mehrere Aktualisierungen für eine Entität pro Sekunde beginnen, gegen die praktische Grenze für Schreibvorgänge pro Sekunde zu stoßen, besonders wenn sie transaktional sind.

Wenn mehrere Instanzen ausgeführt werden, ist das kein Problem - Sie können dafür sorgen, dass Instanzen bei Bedarf warm bleiben.

    
Peter Recore 18.02.2011, 19:14
quelle