Hi, ich arbeite an einem Multiplayer-RPG und habe meine Basics (Pathfinding, Collision, Rendering, Filehandling) nahezu abgeschlossen. Nun überlege ich, "wie" ich das ganze am sinnvollsten anordne.
1 Server, n Clients
Ich habe mich für ein übliches Server-Client-Konzept entschieden, wobei das Rendering (und predicted Bewegungen usw.) beim Client und alle Änderungen am Datenbestand (Schadensberechnung, "echte" Bewegung usw.) beim Server vorgenommen werden. Damit alle Parteien kommunizieren können, werde ich TCP verwenden und habe mir ein Framework gestrickt, mit dem ich Events ("Spieler A will sich nach XY bewegen" usw.) über TCP zur Gegenseite schickt. Dort können diese dann bearbeitet werden und erneut Events ("Spieler A bewegt sich nach XY mit dem Wegpunkten W1, ..., Wn" etc.) erstellt und versandt werden usw.
Multithreading, Gameloop und FPS-Rate
Meine Idee für den clientseitigen Game-Loop wäre:
- alle Events erstellen (z.B. wenn der Spieler auf eine Position geklickt hat und dort hin will)
- alle Events dem Netzwerk-Client geben, damit er sie versenden kann
- Objektaktionen (Bewegungsanimation usw.) fortführe und Rendering durchführen
- alle Events vom Netzwerk-Client holen (das sind die, die vom Server neu angekommen sind)
- alle Events behandeln (d.h. z.B. Wegpunkte einer Figur hinzufügen)
- FPS-Bremse
Dabei arbeitet der Netzwerk-Client mit einem eigenen Thread zum Sammeln der Events. Diese stellt er dann in einer thread-safen Queue zur Verfügung. Allerdings frage ich mich, ob durch das "alle Events vom Netzwerk-Client holen und behandeln" ich vielleicht Probleme bekommen könnte, wenn es zu viele sind, so dass die Framerate sinkt. Sollte ich dabei nur bis N Events holen und den Rest dort lassen? Oder bietet sich hier ein Thread an, der die Events parallel behandelt und bei jedem Event die View sperrt, aktualisiert und entsperrt; und ich beim Rendering entsprechend auf den Mutex dafür sperren und entsperren sollte?
Also der Art:
|
Quellcode
|
1
2
3
4
5
6
7
8
9
10
11
12
|
View lock
Event 7 bearbeitet
View unlock
View lock
Event 8 bearbeitet
View unlock
View lock
Rendering
View unlock
View lock
Event 9 bearbeitet
View unlock
|
Ich vermute das würde vielleicht einen ähnlichen Effekt haben, da die Reihenfolge der Threads nicht deterministisch ist, d.h. es könnte vielleicht trotzdem passieren, dass 100 Events behandelt werden und dann erst gerendert wird?
Ich hoffe ich habe mein Problem verständlich genug formuliert
Hat jemand eine Idee für mich?
LG Glocke