Multiplayer Networking

[jeremiew]

I just purchased your package today and love it, however I am attempting to use the Unity HLAPI for multiplayer networking and am seeing that your scripts don't included the necessary calls to "isMine" to not have the user's controls somewhat affect the models of the other players in their local instance.  Do you have a documented solution for this?

[Invector]

Currently we don't have support for multiplayer jeremiew, but there is several users using Photon and other system creating their own MP, I guess Photon is the more popular.

[jeremiew]

Thanks for the reply. I attempted to add support for Unity MultiPlayer networking but am failing miserably at this point.

Anyone else out there feeling generous enough to give me some pointers, direction or tips?

[Invector]

I just send an newsletter to everyone officially announcing the vForum, hopefully someone who already implement MP will read

[iztrahd]

Would just request that if you do decide to implement some sort of networking support that it would hopefully be kept as a modular implementation seeing as how people use different networking solutions and one of the strong aspects of this controller is that it does not contain too much aside from the core character controller... thus making it easy to implement / integrate with your own systems.  

On a further note, I just noticed that the asset description says "- Rigidbody, root motion and non-root motion controller"  I did not remember seeing this before (is it recent?).  I will take a look at it and see how the non-root motion setup works.  This may very well make networking with this asset much easier as both physics and root motion driven movement cause all sorts of issues in a server auth mp environment in Unity.  Depending on how the non-root motion controller is setup, I may actually look at replacing my custom controller in my current MP project with this one!

If so I will keep some progress updates posted to these forums.

[Invector]

Aug 1, 2016 20:56:48 GMT iztrahd said:

Would just request that if you do decide to implement some sort of networking support that it would hopefully be kept as a modular implementation seeing as how people use different networking solutions and one of the strong aspects of this controller is that it does not contain too much aside from the core character controller... thus making it easy to implement / integrate with your own systems.  

On a further note, I just noticed that the asset description says "- Rigidbody, root motion and non-root motion controller"  I did not remember seeing this before (is it recent?).  I will take a look at it and see how the non-root motion setup works.  This may very well make networking with this asset much easier as both physics and root motion driven movement cause all sorts of issues in a server auth mp environment in Unity.  Depending on how the non-root motion controller is setup, I may actually look at replacing my custom controller in my current MP project with this one!

If so I will keep some progress updates posted to these forums.

We're not thinking about multiplayer anytime soon (other priorities, like shooter, new features, integrations) but if we do, I'm thinking about have a separate add-on, because just like you say it's not everybody who needs MP messing around in the code.

The last update has some new non-root motion stuff, but the new upcoming v1.4 will have even more options like you can set up different values for each moveset, so you can for example use animations inplace for one move set and set up the values for movement and use another set with other values. 

[iztrahd]

Aug 1, 2016 23:17:03 GMT Invector said:

The last update has some new non-root motion stuff, but the new upcoming v1.4 will have even more options like you can set up different values for each moveset, so you can for example use animations inplace for one move set and set up the values for movement and use another set with other values. 

Seen a few posts about upcoming features in 1.4 and it sounds great  also excited to see what/how you've implemented the shooter stuff!

Was looking at the code last night and from what I saw the non-root motion stuff still uses rigidbody.addforce for movement so authoritative networking will still have issues, but in any case, glad to hear that if you do add something for it at a later date it will be modularized.  

Great asset, easily my fav third person controller so far. 

[uberwiggett]

I too just purchased both loco+melee, can't wait for the shooter pack :D, but I am also looking at implementing multiplayer. Tried using unity networking, but required changing monobehaviour to networkbehaviour in the character control script. Problem is, the char-con script isn't a monobehaviour! I'm pretty sure pun works in the same way, but I haven't looked yet. I'd be keen to know who else is using pun with this template so I can have a chat with them and find out what they did to get two or more people running around hacking and slashing.

[iztrahd]

Aug 16, 2016 9:33:58 GMT uberwiggett said:

I too just purchased both loco+melee, can't wait for the shooter pack :D, but I am also looking at implementing multiplayer. Tried using unity networking, but required changing monobehaviour to networkbehaviour in the character control script. Problem is, the char-con script isn't a monobehaviour! I'm pretty sure pun works in the same way, but I haven't looked yet. I'd be keen to know who else is using pun with this template so I can have a chat with them and find out what they did to get two or more people running around hacking and slashing.

Actually it is a MonoBehaviour...  vThirdPersonController extends from the vThirdPersonAnimator class which extends from vThirdPersonInput which extends from vThirdPersonMotor which extends from vCharacter... and vCharacter is a MonoBehaviour, thus every class in the chain, all the way to, and including vThirdPersonController is a MonoBehaviour by default.  

In this scenerio, if you change the vCharacter class to a NetworkBehaviour, then your vThirdPersonController will be a NetworkBehavior.

=== Wall of text below is related purely to networking issues with physics and root motion ===

A few things you will need to keep in mind when planning how to do your networking using physics based movement and maintaining server authority:  

Both rigidbody ie physics based movement and root motion introduce certain complications for networking in unity... you cannot deterministically compute the results of your input on both the client and server and expect the same results and correcting the differentiated results on the client with the servers results becomes problematic as Unity does not support certain aspects that are needed for that (mainly physics rewinding).  

Computing the results on both client and server is usually desired as it allows the clients controls to feel responsive and see instant results (does not have to wait for the input to travel to the server, get calculated, and have results sent back)... normally when you do this, if the results of the clients and servers calculations do not add up, you smoothly transition to the results returned by the server to correct the client and thus allow the server to maintain control to help avoid cheating.  Since Unity does not support physics rewinding you can't rewind the clientside physics movement and replay the instructions with the servers corrections so you kind of end up with a few options and have to pick the one that works best for you.

• perform calcs on both and correct client according to server as per normal flow but since you can't rewind/replay the physics you'll end up with a lot of snapping/teleporting/rubber-banding etc. Depending on clients latency, however, proper interpolation in the corrections between the two can help smooth a lot of this out.  Or...
  

• have the controller just send input to server as a move command, let server perform physics calculations and send back result, then move client player according to result... this can make your controls feel laggy and unresponsive (scaling with the clients latency) (note in this scenario you would set it up so that when you're client's player is instantiated it would change the rigidbody to kinematic - only the server should have a non-kinematic rigidbody on the player so that it can have complete control of the players movements)

• Implement a 3rd party physics library that supports rewinding/playback

Of the 3, I think the second is the route most will opt to go.

Root motion causes a similar issue, and all of the scenarios listed above would work there as well, albeit with the same drawbacks.  

I have seen some people mention implementing their own physics rewinding/playback setup on the forums (though I do not have a link atm) ie including timestamps with each instruction sent so they can match up the servers corrections with the appropriate moment on the client side then implementing their own logic to handle the rewinding and replaying of instructions from that point... this will get very complex very fast though, so that would be left to your level of comfort with coding.

Granted these issues only affect a server authoritative networking environment, if you are intending the game to be client authoritative then none of these are issues (you will then need to find other ways to deal with cheating if that is a concern, though I have seen some mention that if their game became popular enough to attract hacks to cheat the game, they would consider that a big success in and of itself lol)  

Keep in mind none of these will prevent someone from making a multiplayer physics based game in unity... I am simply pointing out some of the issues you will run into and need to plan for / find ways around when doing so.  Depending on the type of game, these issues may not even pose much of a concern for you.

[uberwiggett]

thanks for that, yeah I was meaning it wasn't a monobehaviour because where it normally says monobehaviour it actually references another vController script, as I'm new to network coding I wasn't sure how to modify it to allow the network behaviour. But following your path I see it's the character script that is the end result, will see if i can fiddle with that. Your write up is interesting, from what I've seen of ubisoft's siege, they've gone with the second option, a few times I've been killed in that game only to see the replay being way different to what I saw. That's just the server having a different view of what the client did. It can raise some sour feels but otherwise it seems the best option.

As I said, I am new to network coding, so I have very little clue as to how to adapt this particular template structure, but once melee 1.4 comes out i'll be focusing on a single player rpg, so might leave it till I have that built up, unless someone has an example for turning invector's template into multiplayer

[towerguardian]

I myself am looking into getting this to work with networking, I am going to be using Forge Networking.
Any tips from the developers would be great

[Deleted]

As well as towerguardian, I'm using Forge networking as well, also any word from dev would be great , though I know after shooter it might be compatible.

[thesourc]

With the basic controller; I just turned the controller, and the input script off on the character. Then attached a simple script to turn them on if it's the local player. 4 lines of code and the camera and player worked perfect in a network environment. I am hoping to get the shooter next week, and I hope it works about the same.


public class SetUpLocalPlayer : NetworkBehaviour {




// Use this for initialization
void Start () {
if (isLocalPlayer) {
GetComponent<vThirdPersonController> ().enabled = true;
GetComponent<vThirdPersonInput> ().enabled = true;



return;
}

}
void Update()

{

//animtions to steam over the network but only if this is our network

if (isLocalPlayer)

{

GetComponent<NetworkAnimator>().SetParameterAutoSend(0, true);

GetComponent<NetworkAnimator>().SetParameterAutoSend(1, true);

GetComponent<NetworkAnimator>().SetParameterAutoSend(2, true);

GetComponent<NetworkAnimator>().SetParameterAutoSend(3, true);

}

}

public override void PreStartClient()

{

GetComponent<NetworkAnimator>().SetParameterAutoSend(0, true);

GetComponent<NetworkAnimator>().SetParameterAutoSend(1, true);

GetComponent<NetworkAnimator>().SetParameterAutoSend(2, true);

GetComponent<NetworkAnimator>().SetParameterAutoSend(3, true);

return;



}

}

[mightofficiel]

it works with the shooter version ??

[wesleywh]

I have been working on a package over the weekend to add UNet (Unity Multiplayer Networking) support for the invector packages. You're all more than welcome to make pull requests if you find there are better ways of doing things that what I have come up with.

Checkout the package here:

invector.proboards.com/thread/1908/free-unet-multiplayer-script

This should work for all of the packages (basic, melee, shooter). Thought this is really only for movement and animations right now.