spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

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:


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

Zitat von »Nox«

*summt* premature optimization *pfeif*
KISS mein Lieber, KISS. Falls der dümmste Ansatz sich als wirklich unvorteilhaft rausstellt, kann man immernoch nachbessern.

Prinzipiell hast du damit recht! Und in meinem Fall erst recht Ich habe ja niemanden der mir mir Deadline im Rücken sitzt - von daher sollte ich wirklich mehr Learning-By-Doing und Trial-And-Error praktizieren ^_^