Server-Client-System für Browsergame

Maliko

Bekanntes Mitglied
Moin,

ich plane gerade mit ein paar Leuten ein Grafisches Browsergame. Ich werde mich dabei um das Backend kümmern. Ich habe dabei gedacht ein auf Java-Basierendes Backend zu entwickeln, und das Frontend besteht aus einer HTML5-Javascript Lösung (die jemand anderes entwickelt). Jetzt frage ich mich nur gerade welche Technologie dafür am besten geeignet ist? TCP, UDP, Websocket? Stinknormaler REST-Server?

Ich persönlich würde eher zu Websocket tendieren da es erheblich schneller ist als REST und UDP hat den Nachteil dass Packetverluste nicht registriert werden, was wiederrum zu Fehlern führen könnte, aber was ist mit TCP?

Was meint ihr? Was würdet ihr für ein entsprechendes Backend für eine Technologie verwenden?
 
Kommt ganz darauf an was ihr fuer Anforderungen habt. Zum Beispiel, wieviele Anfragen werden auf dem Server geleitet? Fuer jeden Frame Drei oder jede Minute einmal Stand aktualisieren?

Netty waere eventuell auch eine interessante Sache die man sich ansehen sollte.
 
Aus dem Bauch heraus - ohne aber Ahnung davon zu haben - würde ich auch zu Websockets tendieren. Zumindest, wenn man eine möglichst synchrone Kommunikation haben will. Ist aber rein Bauchgefühl ohne wirklich es technisch untermauern zu können.
 
Kurz gesagt es soll sich um ein Rollenspiel mit Rundenkampfsystem handeln. Also nichts was echtzeitmäßig relevant ist. Sprich die Anfragen an den Server finden mit jeder Aktion statt + Hintergrundaktualisierungen wie Regeneration, Statusänderungen etc.

Netty waere eventuell auch eine interessante Sache die man sich ansehen sollte.
Das schaue ich mir mal an wenn ich wieder zuhause bin (bin derzeit noch im Büro).
 
„Netty“ arbeitet auch mit Http2 und WebSocket.
WebSocket gibt dir die Möglichkeit einen Kanal offen zuhalten über den der Server ohne Request Daten an den Client schicken kann.

Http1.1 hat das nicht, da kann der Server nur auf einen Request eine Antwort, Respons an den Client schicken.
 

Neue Themen


Zurück
Oben