About the use of Static Vector3 to detect mouse position

[RancorSnp]

Hi, so in the lecture it was mentioned that static Vector 3 is something we can use in this situation, because we are very confident that there will only ever be one instance of it at any give time, and so it is easier to make it this way.

This description does concern me a bit though, as I plan on making a multiplayer game based on this course. And yes, I know it is best to make a game multiplayer from the start rather than turn a single player experience into a multiplayer one later. But I do want to make sure I understand all of the code well before I take on making it multiplayer.

So my question is - is this a concern, and if so, what would be the best way to implement it to make the switch to multiplayer later on less painful.

[Pete_Baron]

I think it depends a lot on how you implement your multiplayer. If you intend to overwrite the input handler so that remote player moves appear to be Mouse Input on this local client, then no this isn’t safe. However that’s a very dodgy way to do things (if it’s not a mouse, it shouldn’t look like a mouse!) and I’d always recommend adding another layer above the mouse handler which branches:
local player = mouse input handler
remote player = remote input handler
Given that any PC can only have one mouse, it should in 99% of cases be entirely safe to make this assumption.

[CodeMonkey]

Like Pete mentioned it depends on how you implement Multiplayer and technically you could somehow create a “virtual mouse” for each player which would cause issues.
However the better approach for multiplayer would simply be just receive the order, so Player 2 clicks to move their Unit; Player 1 receives that target Grid Position, not the Mouse Input.
So the mouse input would only ever be local which would not cause issues with that class.