Okay, thanks for the reply :-)
Your reply on object state problems; yes, that is something to worry about, but don't you have the same problem with normal messages?
In Dukatiers (UDP network game) we had diamonds, which could be picked up. Player A picks up a diamond, and the object is removed locally and remotely by sending a command.
Well, that wasn't smart of me, because it introduced the problems you described (syncronisation) when the object had to be added again. Players who connected later on could crash randomly because of different object states.
The answer was by hiding/showing the diamond entities, not removing/adding the objects while the game was running.
Players who joined during a game had to load all the information on diamond locations (X,Y,Z,hidden/shown).
What I'm trying to say here: what is the syncronisation difference between sending network messages (current way of doing) and remoting? It's basicly this: instead of ME handling the object mutation, the module does it FOR me :-)
When you look at the network design, it's almost the same.
BlitzPlay for example, converts the data to a string, and back from a string to variables. This is still happening internally, only with the difference that it would also take care of placing the data in the right objects for me.
---------------------------------------------------
Optimisation:
Perhaps, with optimization, the module could check which parts of the objects are mutated, and only send this change through the network. Also with "unsharing" parts of the objects this could be reduced.
In fact, the whole bandwidth issue is the programmers' responsibility. I would only use it for players (X,Y,Z, playerStatus (int), character_face_look and some other commands.
Here, it doesn't make a difference (syncronisation) which method I use.
I would "unshare" object data like references to entities or other unnessesary stuff.
--------------
Your reply on object state problems; yes, that is something to worry about, but don't you have the same problem with normal messages?
In Dukatiers (UDP network game) we had diamonds, which could be picked up. Player A picks up a diamond, and the object is removed locally and remotely by sending a command.
Well, that wasn't smart of me, because it introduced the problems you described (syncronisation) when the object had to be added again. Players who connected later on could crash randomly because of different object states.
The answer was by hiding/showing the diamond entities, not removing/adding the objects while the game was running.
Players who joined during a game had to load all the information on diamond locations (X,Y,Z,hidden/shown).
What I'm trying to say here: what is the syncronisation difference between sending network messages (current way of doing) and remoting? It's basicly this: instead of ME handling the object mutation, the module does it FOR me :-)
When you look at the network design, it's almost the same.
BlitzPlay for example, converts the data to a string, and back from a string to variables. This is still happening internally, only with the difference that it would also take care of placing the data in the right objects for me.
---------------------------------------------------
Optimisation:
Perhaps, with optimization, the module could check which parts of the objects are mutated, and only send this change through the network. Also with "unsharing" parts of the objects this could be reduced.
In fact, the whole bandwidth issue is the programmers' responsibility. I would only use it for players (X,Y,Z, playerStatus (int), character_face_look and some other commands.
Here, it doesn't make a difference (syncronisation) which method I use.
I would "unshare" object data like references to entities or other unnessesary stuff.
--------------