After some feedback I have decided that I’d better add multiplayer to the current project sooner rather than later. I reasonably read up on general networking practices, but still have a few questions regarding the Unity system.
First of all, I just want to check that I understand things correctly.
I have game quite similar to an RTS (except it’s not ;-)) since I have multiple units that are controlled by the player through orders, and then by their own logic. They are then driven by physics rather than just repositioned.
After reading the docs, it seems like each unit should have a networkview monitoring the rigidbody, and use RPC calls for any other stat updates (health, etc.). RPC calls would also be used to set game states etc.
Now, the easiest way to implement this would be to have each client “own” its units and transmit their physics states to the other players. My concern is that this might be easy for a player to target for cheating.
So (at last) my question is: Would you consider this a problem, and if so what methods might be employed to counter this?
One obvious solution is to have the identity of the server random and secret among the players, and have it actually perform all the calculations for all players. However,I’m concerned it could be a performance problem if a weaker computer gets stuck with the server role.
Any ideas or hints would be very welcome! Maybe then I can avoid at least a few major disasters along the road.
You normally have a server which receives the RPC calls and “mirrors” them on the other clients. this server could check the RPC calls for consistency to ensure cheat freeness or punish cheaters (I prefer the later so they lose interest in playing when they don’t hit anything anymore and the like)
Right. With a simple FPS for example this is pretty straight forward (in theory).
But how about the actual synching between rigidbodies controlled? I assume only one client (or the server) would calculate the physics solution for one object, and share it with the others?
It is a core gameplay mechanic, so yes it needs state sync. Which returns us to the original question (but phrased in another way): Is it wise to have one computer calculate the physics of all units, or is it better to trust each client with calculating the physics for each of its units?
The latter alternative seems like it would be better from a performance standpoint, but less secure?
Performance wise it would be the best to let them do it. syncronization will most likely not work without beeing a serious network and ingame consistency killer I fear. (unless you have only few objects which do “simple” things so you can i)
The only solution to make it secure and local based is DX10 / cg 2.0 and GeForce 8000 series by letting the GPU do it like its done in Crysis. (and which is the reason why the XP / DX9 driven version has no physics in the multiplayer mode)
So (if I understand you correctly) you state that anything more than a few physics based objects can’t be reliably synced using the Unity network model?
this has nothing to do with unity networking. you can not sync more than a few with any networking due to the amount of data you need to sync and the frequency (at least 30-60 times a second, the 15 times a second frequency will not be enough unless you have a very slowly progressing world) at which you need to sync
Maybe I use the wrong terminology. I don’t mean an exact realtime sync, where the data is always identical on each client. I realize that is near impossible.
I thought the networkview on a rigidbody would do some of the messaging, prediction and checking for me, automagically? I assume this is incorrect?
If so I understand that using physics in the core mechanics in a multiplayer game is still tricky, and I will have to evaluate whether it’s worth it.
Keep in mind that every time a client sends an RPC, it goes through the server, so you can’t really make shortcuts when sending information. Remember that there is only one port, and it connects the server to the client.
Also, the clients can’t send an RPC with a NetworkPlayer, only the server can do this.
Using state synchronization does not do any prediction for you. Let’s say you have a cube moving slowly and evenly from left to right with state synchronization active - the owner of this object would see it moving smoothly, but the other players on the network would see it jittering on its path slightly, only changing its position when a new packet of information makes it to them. At times of heavy lag or lost packets, you’ll see things freeze and jump. Your sendrate for state synchronization is adjustable, but to make the smoothest visuals you’ll have to manually figure out a way of predicting where your moving objects should be next and animating them locally. Something you should know though is that a new packet sent by the owner of a given object will always override any transforms a client may have applied locally.
In my current project I have some primitive prediction that I do to smooth out my characters as they run around. Basically my logic goes something like this… If player X is NOT owned by me, and is currently playing a ‘run forward’ animation, move them forward at their normal run speed. So essentially, once a player starts moving, all other players on the network will automatically move them forward relative to however they last saw them oriented. The instant a packet arrives that disagrees with what this simple prediction is calculating, it will override it. So when running in a straight line it looks perfectly smooth, but there are slight jitters when running in a circle (especially a tight circle).
