praetorianer777 Geschrieben 24. Februar 2014 Geschrieben 24. Februar 2014 Hallo zusammen ich wollte mal in die Runde fragen, wie Ihr eine Game-Serverlogik aufbauen würdet! Zum Hintergrund: ich und ein Freund wollten ein kleines Spiel in Java programmieren... man hat ein Pixel und kann damit über den Bildschirm huschen, also nix großes für den Anfang! Da wir das ganze natürlich auch über Internet machen wollten muss ein Server her! Nun zu meinen Fragen: Wir hatten uns das so überlegt, das auf dem Server folgende Sachen laufen: - Ein Thread um eingehende Verbindungen (TCP) anzunehmen, jede eingehende Verbindung wird an einen weiteren Thread übergeben (Threadpool), welcher dem Player zugeordnet ist - Ein Thread, welcher UDP-Pakete versendet, die Umgebungsrelevante Daten enthalten, z.B. Position der anderen Spieler - Ein Thread um UDP-Pakete anzunehmen, wird benötigt um Portnummer des Clients herauszufinden Alle Daten die vom Spieler gesendet werden, werden aktuell per TCP an den Server geschickt, und der Server schickt alle Daten (aktuell nur Positionen der Spieler) per UDP an alle raus! Erstmal bis hierhin ok, oder gibt es da Verbesserungsvorschläge? ======================================= Weiterhin haben wir das aktuelle Problem, das die Pixelpositionen nicht übereinstimmen und das ganze doch recht "laggt". Zumindest sieht die Bewegung der anderen Spieler nicht gerade flüssig aus... liegt das daran das der TCP-Part zu langsam ist? Eine vorerst letzte Frage: Wie würdet Ihr die Versendung der UDP-Pakete realisieren? Einfach einen Vector nehmen mit Spielerdaten und den dauerhaft rausballern? Würdet Ihr z.B. die Positionsdaten für jeden Spieler einzeln an alle Spieler senden oder eine Art Array, was die Daten aller Spieler enthält an jeden Spieler senden? Danke schonmal im Vorraus! MfG Zitieren
Jimbo0915 Geschrieben 27. Februar 2014 Geschrieben 27. Februar 2014 Naja, hab leider wenig Java Erfahrung, allerdings kann es hier schon einige Ursachen geben... Ob der TCP Overhead zu groß ist kann ich nicht sagen, halte ich aber eher für wenig wahrscheinlich. Abhängig von der Spieleranzahl würde ich z.B. nicht unbedingt einen Thread je Spieler benutzen, sondern evtl. ein Äquivalent zu den SocketAsyncEventArgs-Servern in C#. Dann Ist die Frage wie mit dem Buffer umgegangen wird. Reservierst du einen großen Block im RAM und arbeitest mit Offsets? Funkt der Garbage Collector hier rein? kA auf welchem Kenntnisstand Ihr diesbezüglich seid, ist sehr wahrscheinlich dass Ihr vom Server Design mehr versteht als ich und ich hier nichts sinnvolles beitragen kann. Ansonsten aber der Rat etwas konkretere Fragen oder mal nen CodeSample reinzustellen. LG TE Zitieren
speedi Geschrieben 5. März 2014 Geschrieben 5. März 2014 Weiterhin haben wir das aktuelle Problem, das die Pixelpositionen nicht übereinstimmen und das ganze doch recht "laggt". Zumindest sieht die Bewegung der anderen Spieler nicht gerade flüssig aus... liegt das daran das der TCP-Part zu langsam ist? Da müsste man jetzt dein Protokoll detaillierter kennen. Wenn deine Datenrate recht hoch ist und du Text-Basiert arbeitest kann es natürlich sein, dass das Parsing etwas performance frisst. Was auch sein kann: Sockets buffern. Das heißt Daten werden nicht unbedingt in dem Moment geschrieben, in dem du sie in den OutputStream des Sockets ballerst. Wenn du willst, dass sicher gesendet wird kannst du ein stream.flush() machen. Eine vorerst letzte Frage: Wie würdet Ihr die Versendung der UDP-Pakete realisieren? Einfach einen Vector nehmen mit Spielerdaten und den dauerhaft rausballern? Würdet Ihr z.B. die Positionsdaten für jeden Spieler einzeln an alle Spieler senden oder eine Art Array, was die Daten aller Spieler enthält an jeden Spieler senden? Ich persönlich würde bei UDP mit festen Sende-Raten arbeiten - da ja durchaus mal was verloren gehen kann und du keine Empfangsbestätigung hast. Auch würde ich schauen, dass die Packet möglichst klein sind. Letzte Anmerkung: Wenn ihr die akzeptierten Sockets des Servers von einem ThreadPool bearbeiten lasst, könnte es passieren, dass ihr im Threadpool bei vielen gleichzeitigen Verbindungen irgendwann keine freien Threads mehr habt. Wenn ihr also nicht aktiv dafür sorgt (z.B. durch nicht-blockierendes lesen) dass ein Thread wieder frei wird, habt ihr irgendwann ein Problem. Ich habe bei sowas bislang immer einfach für jede Verbindung wirklich einen eigenen Thread gemacht - ist aber vielleicht auch nicht die beste Lösung. Zitieren
praetorianer777 Geschrieben 5. März 2014 Autor Geschrieben 5. März 2014 Ahoi! danke erstmal für die Antworten @Jimbo0915 Ram ist genügend da, und da wir bisher gerade mal max. 5 Clients verbunden haben mach ich mir noch keine Gedanken das es an den Threads liegen kann :/ @speedi zum Thema Datenrate: wurde von mehreren Internetanschlüssen getestet, der Server steht in einem Rechenzentrum, da ist genug Power da Derzeit und der Einfachheit halber übertragen wir nur Text, der mit Trennzeichen versehen ist um die jeweiligen Daten zu separieren Die UDP-Pakete sind 1kb groß Zitieren
Klotzkopp Geschrieben 6. März 2014 Geschrieben 6. März 2014 Wie oft senden die Spieler ihre Daten an den Server? Wie hoch ist die Latenz zwischen Spielern und Server? Zitieren
praetorianer777 Geschrieben 6. März 2014 Autor Geschrieben 6. März 2014 aktuell senden wir nur Positionsdaten... diese werden an den Server gesendet sobald der Spieler sich bewegt, der schickt dann ein Paket mit den neuen Positionsdaten an alle Spieler raus und da wie o.g. bisher nur eine Hand voll Clients verbunden waren sollte sich das noch in einem überschaubaren Rahmen bewegen Zitieren
Klotzkopp Geschrieben 6. März 2014 Geschrieben 6. März 2014 D.h. du betrachtest die Bewegung nicht als Zustand mit einer Dauer, sondern als Folge von Bewegungsereignissen? Ok, dann lautet die Frage, in welchem zeitlichen Abstand liegen diese Ereignisse, wenn ein Spieler versucht, sich dauerhaft zu bewegen? Hast du da überhaupt irgendeine Zeitsteuerung? Oder sendest du einfach so schnell du kannst? Und was ist mit der Latenz? Mal nachgemessen? Zitieren
praetorianer777 Geschrieben 6. März 2014 Autor Geschrieben 6. März 2014 ja, pro bewegtes Pixel geht eine TCP-Verbindung zum Server, und von da per UDP an alle anderen Spieler... gesendet wird, sobald sich der Spieler um ein Pixel bewegt, und vom Server wird gesendet sobald eine Info per TCP eingeht Latenz mit normalen Ping liegt zumindest von mir daheim aus um die 60 ms Zitieren
Klotzkopp Geschrieben 6. März 2014 Geschrieben 6. März 2014 Und wie schnell bewegt sich ein Spieler so? In Pixel pro Sekunde? Zitieren
praetorianer777 Geschrieben 7. März 2014 Autor Geschrieben 7. März 2014 gute Frage, mit einem kurzen Tastendruck sind das schon 6 - 10 Pixel, richtig testen kann ich das aber erst heut Abend, wenn ich wieder daheim bin <:] Was würdest du eig. sagen, wie wäre es besser die Spielerpositionen vom Server raus zu feuern... Jede Spielerposition einzeln, oder pro UDP-Paket so viele Spieler reinpacken wies geht? Wenn das mal angenommen 100 Spieler wären wären das immerhin schon 100 UDP-Pakete die da mit einem Rutsch rausfliegen... und das dann mehrmals pro Sekunde Zitieren
Klotzkopp Geschrieben 7. März 2014 Geschrieben 7. März 2014 Dein Ansatz, jede kleinste Veränderung der Spielerposition an den Server zu melden, ist nicht zielführend. Schick in regelmäßigen Abständen die Spielerpositionen an den Server. Darüber hinaus schickst du sofort Daten, wenn sich die Bewegung eines Spielers ändert. Wenn der Spieler also eine Taste drückt, schickst du Daten über die Bewegung (Richtung, Geschwindigkeit) an den Server. Ebenso, wenn der Spieler die Taste loslässt. Die anderen Clients sind dafür verantwortlich, daraus eine flüssige Animation zu machen. Die regelmäßigen Positionsupdates dienen der Synchronisierung. Verzögerungen und Sprünge wirst du nie ganz verhindern können. Aber so hast du wenigestens eine obere Grenze bezüglich der Bandbreite. Zitieren
praetorianer777 Geschrieben 7. März 2014 Autor Geschrieben 7. März 2014 Ok danke erstmal! Was meinst du in welchen Abständen sollte ich das schicken? Die Framerate der Clients ist auf 60 fps begrenzt, soll ich da aller 10 fps was rausschicken? Zitieren
Klotzkopp Geschrieben 7. März 2014 Geschrieben 7. März 2014 Ich habe da keine Erfahrungswerte. Ins Blaue hinein würde ich mit 200 bis 250 ms anfangen, das wäre bei 60 fps alle 12 bis 15 Frames. Zitieren
praetorianer777 Geschrieben 7. März 2014 Autor Geschrieben 7. März 2014 Gut dann versuch ich das mal... und was sagst du zu meiner vorher gestellten Frage? Was würdest du eig. sagen, wie wäre es besser die Spielerpositionen vom Server raus zu feuern... Jede Spielerposition einzeln, oder pro UDP-Paket so viele Spieler reinpacken wies geht? Zitieren
Klotzkopp Geschrieben 7. März 2014 Geschrieben 7. März 2014 Was würdest du eig. sagen, wie wäre es besser die Spielerpositionen vom Server raus zu feuern... Jede Spielerposition einzeln, oder pro UDP-Paket so viele Spieler reinpacken wies geht?Alle auf einmal. Du willst die in den Clients möglichst gleichzeitig (im Sinne von "alle zwischen denselben 2 Frames") verarbeiten. Zitieren
Goulasz Geschrieben 7. März 2014 Geschrieben 7. März 2014 Forum - Gameplay Discussion - What is Desync? (A thorough explanation) - Path of Exile Achtung, das ist ein 30-seitiger Forenpost mit teilweise ziemlich abgefahrenen Architektur- und Codebeispielen zum Thema "Desync" im Action-RPG "Path of Exile". Hier ein reddit-Talk dazu: Some facts about desync : pathofexile Viel Spaß beim Lesen . Zitieren
praetorianer777 Geschrieben 7. März 2014 Autor Geschrieben 7. März 2014 Heilige Mutter Maria Gottes !? D: Sehr interessanter Link, vielen Dank! Ach und drolliges Profilbild :> Zitieren
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.