Hello there :)
Some time ago, I posted a question about entity naming for network replication. I thought the answers solved all my networking problems, but I've stumbled upon some more design issues.
So now, how do you guys correctly replicate entities and their state over a network ?
I'm concerned with the entire entity life time - that is, creation, initialization, updating and destruction. Also, I'm hoping for a clean solution (meaning not too much extra or ugly game logics code)
Currently, I've got a networked naming system in place, which can translate entity pointers over the network. Furthermore, I have a reflection system written, which can access member variables of an arbitrary class instance by the network name and the variable name.
Now, I had two different designs in mind for the replication system.
The first one was to send each relevant game state change as an "net action" to all clients. This works pretty well for things like regular position updates, but doesn't work too well for entity instantiation and initialization. Also, I guess the number of action types required may get quite high for many different entity classes. Finally, it results in ugly, lengthy game logic code.
The second one was to use the reflection system to just send entity variables on random (perhaps with some priorizing). This would allow for much cleaner game logic code, since it can be automated. However, it still leaves the problem with entity instantiation, initialization and destruction.
Any input on this topic would greatly be appreciated,
Cheers,
- Wernaeh
1
Network replication
Started by Wernaeh, Apr 27 2006 05:47 PM
1 reply to this topic
#2
-
- Members
-
- 584 posts
Senior Member
Posted 29 April 2006 - 01:34 PM
I'm not going to directly answer your question but I'll talk about what I've done in the past.
In previous games I've worked on there were serveral approaches. The first on it to make messages that carry the state changes to your distributed objects. The second is to store previous state and send updates when it changes. And the third way is to use a combination of the two.
Entity creation. When a player connects it first recieved information about its own state after this the server then sends events for anything within its interest area. The create events contained a pointer to the Entity that had been reconstructed using serialisation/reflection.
Entity destruction. Pretty simple. If an entity dies or goes out of interest the client receives a destroy event which removes it from the environment.
In games like quake the entire games state of all the clients isnt huge and is stored over time. This means you can perform a simple diff on the data and send the info in a single message. Since the state is being stored anyway for prediction/processing events this can be a simple solution if your data is small enough.
A more complex approach and one thats more commonly used these days is to have remote methods (RMI) and smart properties (that can automatically dead reckon and be rate controlled). I suggest you look at unreal scripting as thats the model that they use.
Methods are then used when you need discrete events such as a message being displayed. I wrote my own RMI in C++ using an approach similar to boost::bind, but using the reflection to serialise the parameters and function.
Smart properties can be used when you have a continuous value that needs updating. This a can either be reliable such as health or unreliable such as position. For unreliable, you could do with an occasional sync just to make sure things dont deviate too much.
Even with this the chances are you're going to get sync issues. It may be worth having a sync event if you can tell things have got out of sync for any period of time.
I'm not sure if thats exactly what you're looking for but if you can post more specific questions I can try answer them
In previous games I've worked on there were serveral approaches. The first on it to make messages that carry the state changes to your distributed objects. The second is to store previous state and send updates when it changes. And the third way is to use a combination of the two.
Entity creation. When a player connects it first recieved information about its own state after this the server then sends events for anything within its interest area. The create events contained a pointer to the Entity that had been reconstructed using serialisation/reflection.
Entity destruction. Pretty simple. If an entity dies or goes out of interest the client receives a destroy event which removes it from the environment.
In games like quake the entire games state of all the clients isnt huge and is stored over time. This means you can perform a simple diff on the data and send the info in a single message. Since the state is being stored anyway for prediction/processing events this can be a simple solution if your data is small enough.
A more complex approach and one thats more commonly used these days is to have remote methods (RMI) and smart properties (that can automatically dead reckon and be rate controlled). I suggest you look at unreal scripting as thats the model that they use.
Methods are then used when you need discrete events such as a message being displayed. I wrote my own RMI in C++ using an approach similar to boost::bind, but using the reflection to serialise the parameters and function.
Smart properties can be used when you have a continuous value that needs updating. This a can either be reliable such as health or unreliable such as position. For unreliable, you could do with an occasional sync just to make sure things dont deviate too much.
Even with this the chances are you're going to get sync issues. It may be worth having a sync event if you can tell things have got out of sync for any period of time.
I'm not sure if thats exactly what you're looking for but if you can post more specific questions I can try answer them
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users
