I am working on a multiplayer RTS and am having difficulty deciding how to manage the games entities across all the clients. How I have the server/client implementation set up is like this: Game creator is the Host (Server runs in background on their computer) Players join this server via an IP address, or by LAN discovery. The server maintains all the entities for the game (units, buildings, projectiles, etc…) running update logic on them as if it was a single player implementation. My trouble comes in here though: what would be the best way to represent these entities on the clients? The client side doesn’t need to worry about update logic, only rendering and gathering commands from the player. My first thought was to have an exact copy of the servers entities on each client, and the server would send out game state snapshots to update these, but I feel as if that would be bloated since the clients don’t need to run any update logic on these entities. My second thought was to have two implementations of each entity; one for the server, the other for the client. The issue with this approach is obvious… two versions of each entity is hard to maintain, even harder if I ever make changes. Anyway, that is my challenge at the moment, and I would appreciate any insight you can give on ways you would do this, or have done this. Thanks!
Never made a multiplayer RTS but the way I’ve done it have a “puppet” version/switch on the object. Not necessarily a completely different class file, but simply turned “on” in puppet mode. The puppet simply has a small action queue and is used to draw the things for the clients.
The action queue is mostly used to smoothly transition from place to place. E.g. the server sends 3 x and y coordinated and the puppet walks to each of them in order to make it look smooth. (This is the only thing active in the puppets update() method).
it is quite easy.
Just split logic from the data(like in the mvc model).
so you can use the model class on the client and server and only the server uses the logic class.
Then the server can update the model on the client easily.
I have two classes: Actor on server side, Puppet on client side
There are different properties required, for example, Actors get a Brain for AI, a Scene reference, whereas puppets keep track of past moves for processing server location snapshots.
So it seems that the best way will ultimately involve multiple classes representing each entity. From what you have all said, and my research (Google!) I have decided to have the clients and server maintain the same exact list of entities, but I am removing all update and render logic from these entity classes. The server will have command modules to handle commands from the clients, and update modules; one for each entity type (as there update logic will be different) and the client will have rendering, input handling, and a module to handle snapshots from the server. I also want to implement a blackboard for the entities, but one step at a time!