The Space scene contains a PlayerControls script which takes input from the keyboard and sends it to the server. It’s still barely noticeable, but ideally the camera position/rotation needs to be slightly elastic. The only issue is if the camera is fixed relative to your ship (which it currently the case), because a tiny change in the ship rotation leads to a large movement of the background at the edge of the screen. That’s not a problem at all for the other ships, as it’s not noticeable in a game like this with slow controls. This will fix all positional discontinuities (nothing will pop to a new position) but there will still be first-order discontinuities (velocity will pop). ![]() This will predict the position/rotation in the frames following an update, and blend out previous prediction errors over blendTimeMax (set it the same as your time between updates). SyncRotationFrom += syncRotSpeed * ltaTime SyncPositionFrom += syncVelocity * ltaTime Update the from and to values by velocity. ![]() Transform.rotation = Quaternion.Euler(0.0f, 0.0f, newRot) Transform.position = Vector3.Lerp(syncPositionFrom, syncPosition, blend) įloat newRot = Mathf.LerpAngle(syncRotationFrom, syncRotation, blend) SyncRotationFrom = Īnd here’s the update code to calculate the transform every frame: void Update()įloat blend = Mathf.Min(1.0f, syncBlendTime / blendTimeMax) I’ve seen a few people asking about how this works, so here’s the serialisation code: void OnSerializeNetworkView(BitStream stream, NetworkMessageInfo info)įloat rotSpeed = rigidbody2D.angularVelocity The ships use some simple prediction to minimise the effects of lag. This is very efficient as there is only one synchronised object per player. The parent PlayerShips are the only things in the game that use the NetworkView state synchronisation (which automatically updates position and rotation 15 times/second). The clients have already been told which modules make up all the ships, so they create them all locally and attach them as children of the ships. The server keeps track of which object belongs to which player. The server owns all network-instantiated objects, and nothing is network-instantiated on a client. With that in mind, the only objects created with a Network.Instantiate() are the parent ship objects, one for each player. the modules) to an object with a Rigidbody and the physics interactions Just Work (certainly well enough for my purposes). I very much like the fact that you can just add a selection of children with box colliders (i.e. Space network synchronisationĮach player’s ship consists of a parent object with a PlayerShip script and a Rigidbody 2D, and a bunch of children (one for each attached ship module). You can however make some kind of GameManager object in your scene.This is part 2 of how my spaceship building/fighting game is structured. ![]() In which case, you wouldn't have access to instance variables like networkview. In this case you'd be treating Table_Manager like a static class. Your desired strategy of calling the method: Table_("Table_Manager",RPCMode.All,25) will not work. Once you're sure a NetworkView is attached to the same GameObject as your script, you can either use the built in shortcut of workview (which will automatically retrieve the NetworkView attached to the same GameObject), or you can use this.GetComponent() to get the NetworkView component attached to the current GameObject.Įither way, you'll be retrieving the same NetworkView, and utilizing it for its RPC functionality. If you're only using it for RPC, you can set the Observed to none and change the State Synchronization to Off. Or you can just manually add the NetworkView component yourself. This will ensure that whenever your script is added to a GameObject, a NetworkView component will also be added to that GameObject. You can add the following attribute at the beginning of your script class:
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |