In this Unity MMO Tutorial, you’ll learn how to sync the movement of a custom character with uMMO.
uMMO is a framework for giving you the most flexible and maintainable tools to turn any working singleplayer mechanic into an (Open World) MMO game as fast and reliable as possible. You can get uMMO here. It’s an excelente choice for games made with Unity.
So why does uMMO work as it does? I wanted to to be as generic as possible with uMMO, thus giving you the opportunity to basically implement and sync any character. So if you look in the Asset Store, there are really a bunch of 3rd party character controllers you could use, all working slightly or fundamentally different than the next. Or would you like to use your own custom controller? Well, that should all be possible, that is in part why I built uMMO.
I was looking for a random character controller for this tutorial and found this one. It fits our purpose perfectly as it has some custom setup and it is free.
So we will take that as a basis for a multiplayer demo with a dedicated server and authoritative server. See what we will accomplish in the video below. In that demonstration 2 clients are connected (from our office in the Netherlands) to a remote dedicated server in Southern Germany:
I – Import
1. The first thing you should do is download that GitHub project and extract it somewhere on your hard disc. It comes with all the necessary files to open it as a Unity project.
2. Open it, preferably with Unity 2017.2 or higher.
3. Import the [download] uMMO 2.5 EA free demo OR – if you already purchased uMMO – import the EarlyAccess .unitypackage into the project and execute it to extract the uMMO files. If you want to see the end result in action, take a look at [download] uMMO 2.5 EA free demo + scene (uMMO customers need only to replace the DLL to switch off all limitations).
II – First Steps
1. Let’s get right to it – Instantiate the uMMO prefab by dragging and dropping it from /uMMO/Extension/prefabs/ into the scene.
2. Rename the “swat” player object into “uMMO_swat” (not a requirement, just so we can distinguish it from the original) and make it a prefab by dragging and dropping it into the project hierarchy view.
3. Drag and drop the script NetObject from /uMMO/Extension/Public/ onto the prefab (As you can already see, uMMO is largely maintained/configured only by the mouse ;).
III – Basic setup
1. Switch Transform Syncing Method to Developer Responsibility – We will add a plugin to synchronize the position and rotation of a NetObject ourselves.
2. Switch Animation Syncing Method to Sync Using DEFAULT uMMO Plugin. Enable syncing on all the Mecanim variables that appear.
Your NetObject configuration should look like this now:
3. Let’s create the transform syncing plugin:
- Open in the project hierarchy the folder /uMMO/Extension/prefabs/plugins/
Your scene in the Unity Editor should look like this:
Focus on this part: Prepare it by dragging PL_InterpolatePredictAndReconcile and dropping it onto the prefab instantiated in the scene:
- drag and drop PL_InterpolatePredictAndReconcile onto the “uMMO_swat” prefab in the scene, so that it becomes a child transform of it.
- Let’s inspect the plugin we just instantiated: Here, important values for the synchronization of the transform values of our player character are displayed, and they allow fine-tuning the experience of the player significantly! If you move your mouse on one of the values, most of them spawn a little popup window which explains their purpose and what will happen when you increase or decrease them. For the purpose of this tutorial let’s change 2 values as shown on the gif below:
Changing QoS_ChannelID to 0 increases the reliability of the transfer of data in that it is guaranteed that all data packets arrive in order. This is advantageous in our case of authoritative movement to decrease the number of corrections we need to do on the movement that results from our keystrokes.
(You can see all QoS (Quality of Service) channels if you click on the uMMO prefab in the scene, expand it for its children to be listed, then selecting “PL_NetworkManager_Default”. Or you can find/select it via the “NetworkManager” property of the uMMO prefab, as seen in the following gif. Anyway, nothing needs to be done here at this time, just to give you a greater perspective:)
Changing Extrapolation Limit to 0.05 fixes a bug which I tweeted about some time ago. See the tweet and the belonging media beneath:
Notice the client-side prediction which causes the char in remote view to not stop immediately. He continues in the same direction for a short while. This is both a bug AND a feature 😉In order to compensate for lag while moving, this prevents rubberbanding. #multiplayer pic.twitter.com/JWbP3BSWAa
So, this change will prevent that forward-predicting resulting in interpolating to an inaccurate position at the end of the video above. You can play with this value and tweak it a bit if it doesn’t suit you. At this time, it is only used on the client side so it is not relevant for the server.
(In instantiating the plugin instead of just having it deployed as default uMMO plugin on the NetObject (As we determined in this chapter III, step 1) we are thus able to customize certain plugin values without having to change them on the plugin instance which come with the uMMO package by default, so an update of uMMO will not overwrite them)
4. Now we have the transform synchronization for the most part covered. let’s do the same for the animations now:
5. For the (nearly) last step of this chapter, let’s make sure the prefab we saved in the project hierarchy for this object is updated with the latest steps of configuration we took.
- Click on the prefab in the scene hierarchy and in the object inspector click “Apply” in the prefab options like shown below.
- Assign (again: drag and drop) the prefab in the project hierarchy to the “Player prefab” slot of the NetworkManager (which is a transform child to the uMMO prefab instantiated in the scene).
Now it’s time for some of the advanced steps which we need to take in order to round up the configuration of this particular controller setup.
6. But first! – A little cleanup: Delete the “uMMO_swat” object from the scene, as right now, we will work on the prefab we instantiated in the project hierarchy, as that prefab is the thing that gets instantiated for every new player that joins the server. A player character instantiated in the scene by default serves no purpose in a multiplayer game. Save the scene.
(7. Optional step) As an optional step, we can now actually start the game – yes, with client and server. (Just know that we’re not done yet, so it will not yet work exactly as it should 🙂
In order to start, in the Editor main menu click “File”->”Build & Run”. What will happen now is that the scene gets compiled and we actually have 2 potential instances of it, namely the Unity Editor and the (e.g. Standalone) player we are in the process of compiling. Thus we can already anticipate, there are 2 platforms we need to have in order to play the game – server and client, and thus one player will be the client and the other will be the server. This is how you test what you have produced in uMMO.
The compilation process should be done by now. Start the scene in the Unity Editor as well. So we now have the 2 instances running. On one of them click “Dedicated Server”, on the other make sure the host location field is set to “localhost” or “127.0.0.1” both are interchangeable and actually represent the same thing – the local PC (because we are not connecting to some server on the internet but to the instance that will open a port on the local PC). Click “Client (C)”.
So now, you should see a player being spawned (at 0,0,0) on the server side (nothing yet on the client side because of a bug, nothing we won’t take care of in the next chapter though;). We can control the player on the server side… but that shouldn’t be the case. The player should be controllable on the Client only! That tells us that we aren’t quite done here.
IV – Advanced Configuration
1. First of all, some explaining is needed so you understand what we’ll do next. What do we want to accomplish? We want authoritative movement (a movement that is “okayed”/confirmed by the server before it sends it to everyone else). That way, cheating is made A LOT harder, for many kinds of cheating it is sudden death, so to speak. Speedhacking is the most important and obvious victim, it’s impossible to speedhack with authoritative movement. But also Aimbot is made MUCH harder, and while you can in theory still wallhack, uMMO has tools that can make this basically useless (we’ll talk about this another time).
So let’s check our networking configuration is indeed set up for authoritative movement. When we added the NetObject script to the object, at the same time, Unity added the UNET specific networking component Network Identity to it as well. Checking we are using authoritative movement is as easy as checking that Local Player Authority is unchecked. If that is the case, we’re good.
At this point, I am sorry to say that the tutorial is not over yet, but I have not had enough time to complete it. Be sure though that I will be adding to it very regularly (read: weekly) and thus, we’ll be close to completion.😉 Check here often so you learn more about what we’re doing!
You can read Part 2 here.
As mentioned above, you can download the full demo + scene here: [download] uMMO 2.5 EA free demo + scene (uMMO customers need only to replace the DLL to switch off all limitations).
If you want to stay up-to-date about uMMO, follow our Twitter account @SoftRare