Multiplayer test 2 (problems fixed!)

Short story

So I fixed the problem that I had with the PlayerCharacters so now everyone walks separately.

Diving deeper into the cause of the problem

When a player joins a new server and is the first one there It works perfectly as intended, they can control the Pawn/PlayerCharacter and just move around as it is the only controllable PlayerCharacter in the game, however, the issue starts when another player joins the same session.

The game is getting two inputs and so this also means the server is receiving two inputs from both players but the server does not know where to put the inputs because the PlayerCharacters are coded the same to receive an input like WASD.

Here's a simplified example

So if Player 1 was holding the W key and Player 2 was pressing the D key the Server sees that as one person pressing W and D at the same time So that's when both PlayerCharacters starts walking in the same direction.

Another part to explain is the looking system as well. Since the PlayerCharacter doesn't know who's who taking both mouse inputs to look around the screen. This a serious issue as well if one person's not moving their mouse, but the other player is that person that's not moving their mouse is also being forced to look around which is not good for an FPS shooter because the idea of a first-person shooter is to Be in control of a character with a gun in first-person view.

If that control is lost the project falls apart the purpose of the game falls apart and it just becomes broken.

camera bugging out - Made with Clipchamp.mp4

How I fixed this

I fixed this by adding an if statement to make sure that If the input that is being received is from the client that is controlling the PlayerCharacter on their game.

[This is a view of the function that gets called to allow the input to be received by the user on the player set up script]

[this is a line of code form the room manager script that calls the function to allow inputs to the user that owns the PlayerCharacter]

Hold on that's not an IF statement!

As this is true on the surface level of the code but lets take a deeper look an to what im talking about, So, what do I mean about an if statement that is not there?

Well, on the surface level, the casual looker would think yes, this is not an if statement above.

However, the code starts to be separated from this one line of code.

GameObject _player = PhotonNetwor. Instantiate.....

That is the difference between who is who and what that mean is both players will be separated and have their own identity, kind of like an ID. So, now our game can identify different players in one session. And also because of this, when it runs the line of code is local player, that checks, it does its own check to run that line of code for only that player that needs it.

If the other player is already logged in and spawned in, it does not need to run it. And that's where the If statements start to appear.

So, we've got two computers running the same code, but differently depending on its status in the game. This will prevent conflicts between inputs and any status change that is needed for a player.

Simplified example

If the check returns false then the PlayerCharacter won't accept the input resulting in nothing happening.

But if the check returns True then the PlayerCharacter will accept the input and output the action that was requested by the owner of that PlayerCharacter

Now that both players can move about at the same time and without interfering each other, I did a bit more testing around with it and found a slight issue that was easy to fix.

Minor bug with an easy fix

The issue was when another player walks into someone else their camera started to bug out.

This is Because of the ways that physics is made in unity You can constrain an object's physics so you could stop it from falling over or moving in a direction.

But because the rotation wasn't restricted on the y-axis, any time that the player bumps into someone at an angle it would cause them to spin But because of the way that the camera is coded, the camera wants to look at what the Player is trying to look at so if there's no mouse movement The camera does not move and the player character is forced to look into the same direction The the games physics engine wants the PlayerCharacter to rotate, but also the camera keep wants to keep facing forwards resulting in the screen starting to jitter.

The fix

So by restricting the y-axis rotation it stops this from happening completely and only makes rotations necessary when it needs to be made from the camera.

Small notes

Another thing is from the testing is awkward collisions from the map itself I don't really see this as an issue as this map is currently just a test map, but it's something I should take note of for future reference.

REFLECTION

So not much time was lost with this I'm still making very good progress now that I've got the basic movements in and looking around with also PlayerCharacters only receiving inputs from the user that controls it.

I Can finally move on to more of the FPS sort of stuff so like sinking damage data like guns when you shoot someone the target that is being hit should receive damage.

That is the next plan part of the project I am thinking about coding next, but overall I'm making really good progress and I have a really good feeling about this project.

<----- Previous log

Production logs

Next Log ----->

Page updated

Google Sites

Report abuse