FavoriteLoadingAdd to favorites

This is a follow-up for the first part of this tutorial which you can find here.

So, we left off at part 1, deciding to go for authoritative movement, by making sure the Local Player Authority option on the NetworkIdentity is unchecked.

Buckle up! From here on out it gets a tiny amount more technical, but follow this guide and you’ll understand what to do and equally important: why to do it.

Authoritative Movement

So to know how uMMO in connection with authoritative movement (i.e. server authority) works, we need to reccap how authoritative movement works in principle (on a very basic level with 1 button press = 1 step forward in a 2D grid):

As we can see, we start out at (0,0) and with a press of the button “w” we move forward to (1,0). The button press is executed locally but at the same time, the information of the button press is also sent to the server. The server executes the same action and sends back the result. Now, if we had to wait for the server response, it would take a long time from pressing a button to seeing the position of our character change. Because we execute the same action locally, for the player pressing the button, it looks like the action is executed immediately and flawless, no delay/lag, no rubber banding. The server then sends back the information where the player is located on his side after executing the button press.  This is where we need to be. And this is how uMMO does it.

Authoritative Movement: Input Processing

So seems like we need to execute the same Input on the local client and on server. But which input? Slightly more complex character controllers have often times more than one script receiving/using input from the operating system. Another thing you might be asking yourself: Do I need to send the input to the server myself?
Nope. uMMO completely does it for you. The only thing we need to do for that is a slight change in the code, nothing earth-shattering though. We’ll simply link the Input API from Unity over to uMMO’s own functions so that in addition to the usual behavior of reading Input, that same input is sent across the network to the uMMO server so that both are put in a position to execute the same input.

One of the scripts on our SWAT character player is “PlayerController.cs”. Let’s open it now with an IDE and make the necessary changes.

Change (differences in bold)

[RequireComponent(typeof(CharacterController))]
public class PlayerController : MonoBehaviour
{

to

[RequireComponent(typeof(CharacterController))]
public class PlayerController : SoftRare.Net.PlayerAction
{

Now we have activated the uMMO input processing API for this script. We can now exchange every occurrence of Input with uMMOInput, to effectively bridge the common Unity API with the uMMO API with respects to input processing.

Keep on changing

float inputX = Input.GetAxis("Horizontal");
float inputY = Input.GetAxis("Vertical");

into

float inputX = uMMOInput.GetAxis("Horizontal");
float inputY = uMMOInput.GetAxis("Vertical")

Change

anim.SetBool("Punching", Input.GetButton("Fire1"));

to

anim.SetBool("Punching", uMMOInput.GetButton("Fire1"));

You get the idea. There are a few more occurrences of Input in that file, replace them with uMMOInput just as above. And that’s about it, nothing more complicated to do really with respects to coding in this whole tutorial. Nevertheless, independent from the fact whether you did these small changes or not, you can at this point go ahead and replace that whole file with something I prepared for you: PlayerController.cs . You should do this in any case, there are just a few slight changes in there necessary for running the scene, but not worth explaining in the scope of this tutorial.

Please do the same as above for the script PlayerMouseLook.cs (it is used on the 1stPerson and 3rdPersonCamera component which are children of our player character transform).

Now that is done, the next step is telling uMMO which are the functions where you just replaced Input with uMMOInput: In uMMO’s authoritative movement plugin (InterpolatePredictAndReconcile) we point directly to those functions (basically FixedUpdate and Update) and thereby make uMMO’s authoritative magic work.

Let’s dissect this for a second: we are telling the plugin responsible for transform changes which functions it should call (functions in which we replaced Input with uMMOInput earlier) in order to make update the characters on all platforms simultaneously, thereby synchronizing each of it’s steps, no matter whether local client, remote client or server.

Nearly done. Unfortunately, there are no real “milestones” in this way. It does not until all the components are in the place where they need to be.

Authoritative Movement: Spawn Cases

So the philosophy behind UNet and thus also uMMO is that you configure the same prefabs for spawning on all peers and the server. Meaning if you make a player character prefab, it will be that prefab being spawned on your own client, same on the other clients, and same on the server. But obviously, in all three cases different functionality has to be slightly different, and again different if you look at server authority vs. local player authority. Thus we will need to make sure that the scripts we use for controlling the player are executed on the same player prefab.

Now to make sure that keyboard/mouse button presses are indeed executed on the correct prefab on client AND on the server, but NOT on “remote” clients (clients which only instantiate your player to see what you’re doing). So without uMMO we would script something like

IF IamThePlayer THEN
useScript(x,forPurposeA)
ELSE IF SpawnedOnRemoteClient THEN
useScript(y,forPurposeB)
ELSE IF SpawnedOnServer THEN

Whatever forget this crap 😀 In uMMO we do it with some simple assignments and drag and drop which is much more serves our ability to keep clear overview and maintainability of the project and we don’t change our scripts into a spaghetti meal. Activate the Spawn Case module like that:

Let’s examine this module we switched on:

It is named “Handle Scripts Based on Spawn Case” and it is used widely in uMMO to make sure that you are executing certain scripts in certain spawn cases. So a spawn case is, a character is spawned on your local machine after you connected with a server. Or it is spawned in someone else’s game but representing YOUR character, thus it is moving when you move, and where you move.

It offers 3 attributes and in the example above 2 of those are expanded, which makes visible that we’re dealing with lists, and lists of scripts to be precise.

Client Local Player Scripts
In this list, we put scripts which are ONLY active when we are a client and the prefab we instantiated is our own player character (think about a character controller).

Client Remove Player Scripts
In this list we put scripts which are ONLY active when we are a client and the prefab we instantiated is NOT our own player character (this about a script which spawns an “Attack” button on remote player characters).

Server Player Scripts
In this list, we put scripts which are ONLY active on a server platform and represent a player character of a client who joined.

Let’s look at the scripts added to our player character: mainly PlayerController, (which needs) CharacterController. As we just learned we need both scripts in cases of the local player and the server, for the same movement to be executed with the same input.

Let’s make that happen, you’ll see it is easy with uMMO:

So basically what we are doing is just dragging and dropping scripts on the same game object into the correct lists and uMMO knows that if there is any situation which does not fit the lists where that script is in, it will be removed from the prefab. Thus if the prefab is spawned on a remote client – a client we should not control because it is controlled either by someone in the same house, or someone halfway across the world – the essential player controller scripts are not added to that character in that spawn case.

4 tiny steps to accomplish and we are 100% done.

1. Cameras
Look at the camera objects that are set as children of our main character prefab. Click on 3rdPersonCamera. It has the script PlayerMouseLook.cs which we edited a moment ago. Then click on 1stPersonCamera, it has the same script added. We only need it executed on one of those. Disable it by clicking on the checkbox next to the script name.

2. Area-of-Interest plugins

In uMMO adding area of interest (only broadcasting to the player what is in his immediate environment, thereby saving lots of network resources + other benefits) is exceptionally easy and works – again – through drag and drop 😉

3. Think about the remote players

When developing, I discovered that I often forget about the remote players because including them in testing takes more time and this is done less often. So when making this tutorial, it happened again. In the current state, if we only connect 1 player, all works. But if we connect a 2nd player, the cameras that get spawned with every player are active for yourself, AND for the 2nd player, which gives you pretty strange effects. We’ll use the spawn case feature again to remedy this:

4. Last and least

Let’s spawn a little bit where there are some objects in the scene, thus move to the center of the demo map with the Unity Editor scene camera. And place some (at least one) Network start locations in the air. You do that by creating an empty game object where you want your spawn location to be. Click on that game object. And after that in the main menu go to “Component” -> “Network” -> “NetworkStartPosition”. Rename the game object to something which more describes it’s purpose like “Network Spawn Position”. Repeat creating these spawn positions as often as you like, but for the purpose of this tutorial, one is already enough.

Let’s test what we made. Testing in uMMO is easy. The quickest way is building a standalone player. In the mail menu Click “File” -> “Build And Run”. If you didn’t do that up until now the editor asks you choose a location for the build. That creates an instance of our demo game where you can choose to make it either “server” or “client”. In the Editor start the scene and make it the opposite. Move the player with W, A, S, D and jump with Space.

Then you can navigate on the hard disk to where you saved the standalone player and execute the .exe file. Make that instance another client. Now you should have 2 players connected to a server which can both move and see the other move. If you encounter any issues or it’s not working as you would expect download the result of this tutorial here: [download] Unitypackage, [download] Standalone player (uMMO customers need only to replace the DLL to switch off all limitations. You can get uMMO here). Then you can dissect what you might have missed or done differently.

Still not getting to the root of a particular problem or wanting to comment? Contact me through  softrare.eu/contact.html . I hope you enjoyed this tutorial, I wish you great success for your project!

If you want to stay up-to-date about uMMO, follow our Twitter account @SoftRare.





Source link

NO COMMENTS

LEAVE A REPLY