Register Log in. My Profile points. Log out. New Games Most Popular Games. To play the plugin versions, The IE browser is required. All 2, Multiplayer Y8 Games Sort by: Popularity Rating Date. Mad Freeboarding Unity 3D. Sanctioned Renegades Unity 3D. Elite Marines Multiplayer Unity 3D. Crashdrive Unity 3D. Gears Of Ender Unity 3D. Ratz Instagib Unity 3D. Tank Treads Unity 3D. InvinciCar Online Unity 3D. Eliminator 2 Unity 3D. Air Strike Unity 3D. Surrounded by Death Unity 3D.
RopeRace Unity 3D. HalfLife-V Unity 3D. Grand Theft Unity 3D. Poco Poco Cheerocco Unity 3D. Bowling 3D Unity 3D.
Red Crucible 2 WebGL. Phys Runner Unity 3D. Clash of the Summoners Unity 3D. War Of Soldiers Unity 3D. Alienware: Online Unity 3D. Leader Strike WebGL. Beer Pong Online Unity 3D. Sanctioned Renegades Unity 3D. Basketball io WebGL. Splat Death Salad Unity 3D. Air Strike Unity 3D. Frontlines - War at dawn Unity 3D. Bootcamp Multiplayer Unity 3D. JiyoPets Unity 3D. Mad Freeboarding Unity 3D.
Crashdrive Unity 3D. Gears Of Ender Unity 3D. Tank Treads Unity 3D. Casual Karting Unity 3D. InvinciCar Online Unity 3D. Cabals Unity 3D. HavePublicAddress ; MasterServer. If the server is successfully initialized, OnServerInitialized will be called. For now, we are happy to get feedback telling us the server is actually initialized. All we need now is some form of input to let us actually start the server when we want to.
To test it out we create buttons using the Unity GUI. We only want to see these buttons if we have not started a server or joined one, so the button will show itself if the user is neither a client nor a server. Now it is time to test what we developed so far. When starting the project, all you should see now is a start server button 1A. If you press this button, a message should be shown in the console indicating you just initialized a server.
Afterwards the button should disappear 1B. This MasterServer is run by Unity and could be down due to maintenance. You can download and run your own MasterServer locally. Add to NetworkManager. We now have the functionality to create a server, but can not yet search for existing servers or join one of them.
To achieve this, we need to send a request to the master server to get a list of HostData. This contains all data required to join a server. Once the host list is received, a message is sent to the game which triggers OnMasterServerEvent. This function is called for several events, so we need to add a check to see if the message equals MasterServerEvent. If this is the case, we can store the host list.
To join a server, all we need is one entry of the host list. The OnConnectedToServer is called after we actually joined the server. We will extend this function at a later point. By extending the GUI with some additional buttons, the functions we just created can be called. There will be two buttons now at the start, one to start the server and another to refresh the host list. A new button is created for every server and it will connect the user to the corresponding room.
This is a good point to do another test 2A. One thing to note is that testing multiplayer takes a bit longer, particularly because you always require two instances of the game. To run two instances on the same computer this settings needs to be checked. Now we can test our new functionality in the Unity editor. After refreshing your list, another button should appear 2B allowing you to connect the two instances of your game 2C. Now we should be able to connect multiple players to one another, we can now extend the code with game mechanics.
Set up a simple scene with a floor plane, player and some lighting. Add a rigidbody to the player and freeze the rotations, so we will not get strange behaviour while moving. GetKey KeyCode.
W rigidbody. MovePosition rigidbody. S rigidbody. D rigidbody. A rigidbody. This will enable us to send data packages over the network to synchronize the player.
This means that synchronized data will be sent automatically, but only if its value changed. So for example if you move as a player, your position will be updated on the server. Add the player object to the hierarchy to make it a prefab, so we can instantiate it on the network.
In the NetworkManager-script add a public game object variable for the player prefab. In the new function SpawnPlayer , the prefab will be instantiated on the network, so all clients will see this object within their game. It requires a position, rotation and group, so I would suggest creating a spawn point. Instantiate playerPrefab, new Vector3 0f, 5f, 0f , Quaternion.
Time for another test! Create a new build and run two instances again. You will notice that you can control all players connected, not just your own. This shows one important aspect that will be used often when creating a multiplayer game: who controls what object? One way to fix this problem is to build in a check on the player code so it only receives input from the user that instantiated the object. Because we set reliable synchronization on the network view, data is sent automatically across the network and no other information is required.
Add the following if-statement to the Update :. Another solution could be to send all input to the server, which will then convert your data to actual movement and send back your new position to everyone on the network. The advantage is that everything is synchronized on the server.
This prevents players from cheating on their local client. A disadvantage of this method is the latency between the client and server, which may result in the user having to wait to see the actions he performed.
There are two methods of network communication. The first is State Synchronization and the other is Remote Procedure Calls, which will be covered in another paragraph. State Synchronization constantly updates values over the network. This approach is useful for data that changes often, like player movement.
In the function OnSerializeNetworkView the variables are sent or received and will synchronize them quick and simple. The observed field contains the component that will be synchronized.
The transform is automatically added to this field, which results in the position, rotation and scale being updated depending on the sendrate.
Drag the component of the player script in the observed field so we can write our own synchronization method. Add OnSerializeNetworkView to the player script. This function is automatically called every time it either sends or receives data. If the user is writing to the stream, it means he is sending the data. By using stream. Serialize the variable will be serialized and received by other clients.
If the user receives the data, the same serialization-function is called and can now be set to store the data locally. Note that the order of variables should be the same for sending and receiving data, otherwise the values will be mixed up.
Serialize ref syncPosition ; rigidbody. Make another build and run it. The results should be the same as before, but now we have granted ourselves control over the movement and how the synchronization works.
You might have noticed latency issues between the two instances due to the sendrate. The standard settings in Unity is that a package is being tried to send 15 times per second. For testing purposes, we will change the sendrate. Then, change the sendrate to 5, resulting is less data packages being sent. If you would do another build and test, the latency should be clearer. To smooth the transition from the old to the new data values and fix these latency issues, interpolation can be used. There are several options how this can be implemented.
For this tutorial, we will interpolate between the current position and the new position received after synchronization. OnSerializeNetworkView needs to be extended with to store all the required data: the current position, new position and delay between updates. Serialize ref syncPosition ;.
We had a check in Update whether the object is controlled by the player. We need to add the functionality that when this is not the case, we will use interpolation between the synchronized values.
Though the transitions look smooth, you notice a small delay between the input and the actual movement. This is because the position is updated after the new data is received. Until we invent time travel, all we can do is predict what is going to happen based on the old data. One method to predict the next position is by taking the velocity into account. A more accurate end position can be calculated by adding the velocity multiplied by the delay. Serialize ref syncPosition ; stream.
Serialize ref syncVelocity ;. After building and testing the game again, you will notice the transitions are still smooth and the latency between your input and the actual movement seem less. There are also a few corner-cases where behaviour might seem a little strange if the latency is too high. If the player starts moving, the other clients still predict you would stand still. Set the sendrate at network settings back to 15 updates per second for better results.
For our Kickstarter demo, we used a navmesh to walk around and this seemed to make interpolation and prediction better. The sendrate was set to 5 and as a user you could barely notice the delay.
This tutorial will not go any deeper into the integration of the navmesh, but for your future projects it might be worth to consider this approach. Another method of network communication is Remote Procedure Calls RPCs , which is more useful for data that does not constantly change. A good example what we used these for in our Kickstarter demo is dialog. In this paragraph we will change the color of a player over the network.
By adding [RPC] in front of the function, it can be called over the network. This approach is only able to send integers, floats, strings, networkViewIDs, vectors and quaternions. So not all parameters can be sent, but this can be solved. To send a game object, we should add a network view component to this object so we can use its networkViewID.
To send a color, we should convert it to a vector or quaternion. An RPC is sent by calling networkView. RPC , in which you define the function name and parameters. The last two also have the functionality to set is as buffered, this results in newly connected players receiving all these buffered values.
Because we send this data package every frame now, there is no need to buffer it. To integrate this functionality to our tutorial game, Update needs to call the function to check for input and change the material to a random color. The RPC function changes the color based on the input and if the player object is controlled by the user, he will send an RPC to all others on the network.
GetKeyDown KeyCode. Range 0f, 1f , Random. I hope this tutorial was a good introduction to implement networking to a Unity game. The subjects we have addressed are:. You can download the entire project here.
Houden jullie vast aan UnityNetworking voor de game? Je krijgt veel problemen met spelers die niet met elkaar kunnen verbinden. Hoi Mike, bedankt voor je suggestie. Dat gaan we nog zeker onderzoeken. Voor nu hebben we gekozen voor UnityNetworking vanwege de kleine schaal van de demo. Ok cool, makes sense.
0コメント