Middleware für skalierbare Multiplayergames

[antisteo]

Hallo,

gibt es gute Middleware, die speziell für Spiele ausgelegt ist? (also echtzeitfähig)
wenn möglich unter einer freien Lizenz.

Ich überlege schon seit Monaten, ob ich so eine Middleware eventuell entwickele, allerdings wollte ich vorher schauen, ob es schon ähnliche Projekte gibt.

Die Middleware sollte folgendes leisten:
- beliebig skalierbar durch Hinzuschalten vertrauenswürdiger Nodes
- sicherer Umgang mit nicht vertrauenswürdigen Clients
- Echtzeitfähigkeit
- Latenzen, die einem Spiel angemessen sind
- Nicht nur Request-Response, sondern auch Pushing

[kaiserludi]

Hast du dir schon Exit Games Photon angesehen?
http://exitgames.com/

PS: Ich bin verantwortlich für unter anderem die Entwicklung aller C++ Clients dort. Die wirst also keine wertneutrale Meinung von mir zu der Engine bekommen können, dafür aber falls nötig Support.

[antisteo]

Hast du dir schon Exit Games Photon angesehen?
http://exitgames.com/

PS: Ich bin verantwortlich für unter anderem die Entwicklung aller C++ Clients dort. Die wirst also keine wertneutrale Meinung von mir zu der Engine bekommen können, dafür aber falls nötig Support.

Unter welcher Lizenz steht es denn dann?

Außerdem vermisse ich ein simples "Getting Started" ähnlich einer readme.md auf github

Edit: Oh, ich sehe gerade, dass es nicht auf meinem Server und auch nicht auf meinem PC laufen wird.

[kaiserludi]

Kein Windows?
Dann käme noch cloud.exitgames.com in Frage. Dann musst du selbst keinen Server hosten.
Für Linux bieten wir allerdings derzeit auch keine Clients an, mangels Nachfrage.

Lizens ist propitär und kommerziell. Bis zu 100 (Photon Server) bzw. 20 (Photon Cloud) CCU (User, die gleichzeitig online sind) sind allerding gratis. Dazu gibts Rabatte für Indies. Der Highlevel Code ist OpenSource, Lowlevel ist ClosedSource.

Das Getting Started is online: unter doc.exitgames.com

[antisteo]

Das Getting Started is online: unter doc.exitgames.com

Hmm, so wirklich scheint es nix zu sein.

Gibt es denn noch andere Ansätze, eine Middleware für Spiele zu entwickeln?
(So in die Richtung von EJB, bloß ohne Transaktionen)

[Chromanoid]

Was suchst Du denn genau? Wie soll das ganze skalieren? Project Darkstar/Red Dwarf Server hat ja eben das versucht und ist im Grunde gescheitert. Geht es um ein Spiel mit Lobbyserver, eine persistente nahtlose Welt usw.? Bei Instanzbasierten Spielen kommt es ja vor allem auf das Matchmaking an (http://www.infoq.com/presentations/League-of-Legends ist dazu ganz interessant).

Hier mal eine Liste von Ende 2011 mit Serversystemen für virtuelle Welten (kaum Open Source dabei, da mich das bei meiner Recherche damals nicht interessiert hat):
Abyssal Engine http://www.abyssalengine.com
Badumna http://www.scalify.com
BigWorld Server http://www.bigworldtech.com
ElectroServer http://www.electrotank.com
Esenthel Engine http://www.esenthel.com
HeroEngine http://www.heroengine.com
NAOS Engine http://www.guildsoftware.com
Photon http://www.exitgames.com
PikkoServer http://www.muchdifferent.com
Player.IO http://www.playerio.com
PrimeEngine http://www.monumentalgames.com
ProudNet http://www.nettention.com
Realm Crafter http://www.realmcrafter.com
SmartFoxServer http://www.smartfoxserver.com
xSCAPE http://www.icarusstudios.com
Am interessantesten für Dich sollten Player.IO, Photon, SmartFoxServer, ElectroServer und evt. insbesondere vom Ansatz her PikkoServer sein.

RakNet und Konsorten sind da jetzt nicht bei, da sie nicht besonders MMOs berücksichtigen (diese Frameworks waren für meine Recherche nicht relevant).

Für meine Diplomarbeit habe ich mit Infinispan für's Skalieren und Netty fürs Kommunizieren mit dem Client gearbeitet. Damit kann man IMO schon ziemlich weit kommen.

[antisteo]

Im Prinzip suche ich eine Middleware, die meine Code-Snippets in einem verteilten System ausführt und sich dabei um die Skalierbarkeit und die Persistenz kümmert.
Clients sollen sich mit einem oder mehreren Interfaces (RMI-style) verbinden können, um mit der verteilsten Software zu kommunizieren.
Die verteilte Software sollte in der Lage sein, komplexe Simulationen (Wirtschaftskreislauf, Stadtverkehr) zu simulieren.

Im Prinzip sollten "Objekte" (Model) existieren (z.B. ein Landschaftssegment oder eine Truhe) und diese sollte mithilfe von Nachrichten oder Methodenaufrufen zu einem gewissen Verhalten gebracht werden (Controller).
Der Spieler will außerdem Veränderungen in dem ihm sichtbaren Bereich (View) gestreamt haben (Observer).
Das ganze sollte zumindest mehrkernig laufen (über mehrere Rechner dürfte unpraktikabel sein, es sei denn, man hat Infiniband) und idealerweise sollten die Objekte in einer Sandbox laufen, sodass auch Spieler ihren Code in das Spiel einbringen können.

[Chromanoid]

Der Red Dwarf Server hat das versucht anzubieten. Ich fürchte aber das Projekt ist ziemlich eingeschlafen.

Meinst Du Du kannst mit einem verteilten Nachrichtensystem Deine Prozesse abbilden, dann würde ich ein solches aufbauen. Worin möchtest Du denn am liebsten implementieren? Als Persistenzschicht kannst Du dann erst mal eine lokale DB nehmen.

Welche Echtzeitanforderungen hast Du denn? Terracotta könntest Du Dir auch mal anschauen, damit kann man Java Objekte zwischen mehreren Instanzen teilen.

[antisteo]

Der Red Dwarf Server hat das versucht anzubieten. Ich fürchte aber das Projekt ist ziemlich eingeschlafen.

Meinst Du Du kannst mit einem verteilten Nachrichtensystem Deine Prozesse abbilden, dann würde ich ein solches aufbauen. Worin möchtest Du denn am liebsten implementieren? Als Persistenzschicht kannst Du dann erst mal eine lokale DB nehmen.

Welche Echtzeitanforderungen hast Du denn? Terracotta könntest Du Dir auch mal anschauen, damit kann man Java Objekte zwischen mehreren Instanzen teilen.

Echtzeitanforderung wäre eine maximale Requestzeit eines kompletten Welt-Updates von maximal 50ms (Netzwerk eingerechnet)

Meine bisherigen Ideen sahen so aus:
- Die Anwendungslogik soll in JavaScript geschrieben sein (V8-Engine, womit die Middleware also in C++ geschrieben werden muss)
- Jedes Objekt ist jederzeit nach JSON serialisierbar (für Migration etc)
- Jedes Objekt kann eindeutig angesprochen werden
- Jedes Objekt läuft in einem eigenen Adressraum und kommuniziert mit Nachrichten
- Der Client kann sich mit diversen Objekten verbinden, mit denen er kommuniziert
Der aktuelle Knackpunkt an meinen Ideen ist, dass ich JavaScript-Funktionen (=Closures) nicht serialisieren bzw. migrieren kann. Ich wöllte die Closures am liebsten mit an den Client schicken können. Dazu bräuchte es aber verteilte Garbage Collection wie beim RMI.

Mit Java würde das alles gehen, allerdings funktioniert RMI nicht in der Dalvik VM, wodurch man sich also auch noch ein eigenes Netzwerkprotokoll ausdenken darf.

[Chromanoid]

Ich schreibe nachher noch mehr dazu: Für Netzwerk würde ich Dir kryonet empfehlen.

[Chromanoid]

Wenn Du clientseitig wirklich mit Java arbeitest, also nicht PhoneGap oder so nutzt, dann wäre es doch ziemlich unklug den Server nicht auch in Java zu entwickeln. Viele Datentypen, Mechanismen etc. wirst Du für Client und Server nutzen können. Für Java gibt es ziemlich viele Protokolle, hier eine ziemlich aktuelle Zusammenstellung: https://github.com/eishay/jvm-serializers/wiki ProtoStuff wäre, das was ich als nächstes mal ausprobieren will. Das scheint mir auch für euch ein ziemlicher Deckel für den Topf zu sein (mit der Unterstützung von JSon, Protobuf, Protostuffs eigenem Format und vieles mehr sollte man so ziemlich jedes System [Android wird extra erwähnt] egal welcher Programmiersprache ansprechen können). KryoNet ist halt echt nett zu bedienen, bietet aber kein eingebautes JSON Serialisieren an.

Für Pub/Sub könnte man sich mal verschiedene JMS Implementierungen anschauen. Vielleicht gibt es ja eine schnelle Implementierung, die mit Hashfunktionen für die Verteilung abeitet, das lässt sich dann wahrscheinlich am besten skalieren. Mit Infinispan geht Messaging so mittel (ist dafür nicht gedacht), selbst was mit z.B. JGroups zu bauen könnte evt. auch recht gut funktionieren. Hazelcast hat pub/sub eingebaut, ist sicher auch einen Blick wert (keine Ahnung ob die Topics wirklich verteilt arbeiten oder lediglich geklont werden). Terracotta kann sowas glaube ich auch.

Zwei Insipirationen für Dich (ausgeprägte Pub/Sub Architekturen):
Large-scale Messaging at IMVU
MMO 101: Building Disney's Server System

Die haben keine MOM benutzt und das wohl selbst implementiert. Aus Interesse habe ich eben mal gesucht und bin noch über den Data Distribution Service Spec der OMG gestolpert, allerdings bin ich kein Fan von CORBA und habe auf die Schnelle auch noch keine vertrauenserweckende reine Java Implementierung gefunden.

[Chromanoid]

Inwiefern willst Du Funktionen an den Client schicken? Sollen gewisse Funktionen clientseitig ausgeführt werden oder geht es Dir um vorher unbekannte Schnittstellen? Alles andere sollte sich mit java.lang.reflect.Proxy lösen lassen. Schau Dir mal das an: http://code.google.com/p/kryonet/#Remot ... Invocation

[antisteo]

Der Client soll normalerweise keinen Code zugeschickt bekommen. Es geht um Interfaces. (Ich werde, wie in gwX auch, mir ein Datenformat für die Darstellung eines Szenegraph-Ausschnitts und dessen Update-Streaming ausdenken und eine Menü-Markup-Sprache.)

Ich bin momentan stark am schwanken, aber Mono sieht ebenfalls verlockend aus. C# schreibt sich genau wie Java (ist sogar fast Syntax-Äquivalent, wenn man : durch extends und using durch include ersetzt) und hat ähnliche Eigenschaften wie Java. Unity ist ein Positiv-Beispiel für Mono. (Außerdem findet ein Team-Member aus dem gwX-Team, dass C# durchdachter als Java ist)

[Chromanoid]

Na dann solltest Du keine Probleme haben das ganze zwischen Android und Java zu teilen. Mit der Proxy-Klasse kannst Du Dir das selbst bauen oder einfach das o.g. RMI von KryoNet nutzen.

Für die JVM gibt's soweit ich das sehe eindeutig mehr Zeugs, wenn es um Serverkram geht. Mit Mono hab ich serverseitig noch nichts gemacht. Kannst Dir ja auch mal Scala anschauen. Wenn's um Speed geht, sollte die JVM vermutlich schneller sein (Ursprung meiner Vermutung http://benchmarksgame.alioth.debian.org/, mmh mono scheint dort nicht gut gepflegt zu sein).

[antisteo]

Ich frage einfach mal in die Runde:

Gibt es Personen im ZFX-Forum, die ein Interesse haben, dass eine derartige Middleware entwickelt und unter freier Lizenz veröffentlicht wird?
Wenn ja, würde ich das Projekt nämlich anfangen zu planen.

[Chromanoid]

Also wenn Du für die JVM entwickelst und das ganze eine gut Pub/Sub Architektur mit steuerbarer Verteilung der Topics/Nachrichten ist (z.B. durch eine eigene Hashfunktion), dann hätte ich Interesse.

[antisteo]

Also wenn Du für die JVM entwickelst und das ganze eine gut Pub/Sub Architektur mit steuerbarer Verteilung der Topics/Nachrichten ist (z.B. durch eine eigene Hashfunktion), dann hätte ich Interesse.

Nunja, von der Clientseite wird zumindest Dalvik unterstützt werden und eine weitere Desktop-Umgebung (C#, Java oder FreePascal; bin mir noch nicht sicher)

Was ist für dich JVM? Willst du den Server in der JVM ausführen oder willst du die Beans in Java schreiben?
Wenn du Code in Java schreiben willst, kannst du ikvm benutzen. Willst du die JVM als Plattform nutzen (weil du PaaS gemietet hast), dann dürfte es mit ikvmstub gehen, mal seh'n wie sich das einrichten lässt.
Wenn ich es mit Mono machen würde, wärst du, mit so einer Lösung zufrieden? http://www.mono-project.com/Java

[Chromanoid]

Ich will das System in meine Anwendung integrieren können, also keine klassische MOM. JVM bedeutet für mich, dass das Zeug auf PaaS Systemen läuft und ich keine weiteren Schritte ausführen muss, um meine Objekte versenden zu können. Also kein Generieren von Stubs oder sonstigen Klassen, das nervt mich tierisch bei CORBA, protobuf etc.

Da Du bei Mono Java sicher auch .Net/Mono Bibliotheken verwenden willst, bin ich mir nicht sicher wie gut das Zeug dann ohne Mono auf einer JVM läuft. Habe mir das jetzt auch noch nicht genauer angeschaut, aber ich glaube da gibt's evt. Probleme.

Ich persönlich versuche in meinen Projekten ausschließlich auf in Java geschriebene Open Source Bibliotheken zu setzen (serverseitig), die kann ich lesen, ggf. selbst Fehler beheben und praktisch überall deployen, daher ist mir das ganze komplett im klassischen Java Umfeld am liebsten. Ich würde es wahrscheinlich auch nur dann einsetzen.

[antisteo]

Ich will das System in meine Anwendung integrieren können, also keine klassische MOM. JVM bedeutet für mich, dass das Zeug auf PaaS Systemen läuft und ich keine weiteren Schritte ausführen muss, um meine Objekte versenden zu können. Also kein Generieren von Stubs oder sonstigen Klassen, das nervt mich tierisch bei CORBA, protobuf etc.

Da Du bei Mono Java sicher auch .Net/Mono Bibliotheken verwenden willst, bin ich mir nicht sicher wie gut das Zeug dann ohne Mono auf einer JVM läuft. Habe mir das jetzt auch noch nicht genauer angeschaut, aber ich glaube da gibt's evt. Probleme.

Ich persönlich versuche in meinen Projekten ausschließlich auf in Java geschriebene Open Source Bibliotheken zu setzen (serverseitig), die kann ich lesen, ggf. selbst Fehler beheben und praktisch überall deployen, daher ist mir das ganze komplett im klassischen Java Umfeld am liebsten. Ich würde es wahrscheinlich auch nur dann einsetzen.

Nunja, dich als potenziellen Mituser, Bugreporter, Bugfixer und evtl. Mitentwickler zu gewinnen wäre ein Plus für Java. Allerdings nur, wenn deine Teilnahme dann wirklich sicher ist. (Dann wirst du auch in die Planungsphase mit einbezogen)
Für mich ist der Mono/CLI-Krams recht neu, allerdings erscheint .Net etwas mächtiger als Java und ich war nie ein Fan von Java. (Jetzt, wo Oracle sich nicht mehr drum kümmert, erst recht)

Wie verbindlich bist du in der Hinsicht?

[offtopic]
Hast du den SecurityManager+Reflection-Exploit auf deinem PaaS schon mal ausprobiert? Damit würdest du kostenlos Server geschenkt bekommen, in die du nur eine Backdoor einbauen musst.
Außerdem gibt es ein Paper, wie man bei einem Bitflip im Speicher in PaaS-Lösungen mit 80%iger Wahrscheinlichkeit die JVM übernehmen kann. (unfixable, aber Bitflips sind selten) Das ganze funktioniert unter Ausbeutung des Typsystems von Java.
[/offtopic]