Hey everyone,
I searched the forum and didn’t find much about this. I’m trying to figure out what the best way to implement shooting in a multiplayer FPS. I will use raycasting and not ‘physical’ bullets.
Just some thoughts: Do you send an RPC for every shot? Maybe just for the shots that actually hit something?
Anybody know how to go about this shooting in a multiplayer FPS?
Thanks a lot!
You send the client inputs to the server in a “fastest delivery” fashion, means you sequence each input with a number which is either ever increasing (32 bits usually is enough for “forever”, will give you a few days of playtime) or some what rapidly looping (say 10 bits) sequence, you then send the N latest inputs in an unreliable fashion. Then you just let the server act on each clients input and calculate everything. Sending an RPC for every shot is sure to make your game unplayable as unity RPCs are reliable and ordered and also quite heavy.
Thanks. So what you’re saying is basically send out the input (only) as an unreliable RPC, and then let the server calculate the rest - damage etc…
I would still need to send out things like the damage the weapon does (a property of the weapon). So this would be a part of that RPC?
Cheers
The damage of weapons, etc. can be calculated a-head of time or configured as settings on game objects, the server should already have the data for this on it - you should never let the client decide anything like that.
I see what you mean. Thanks!
fholm, I’m not entirely sure what you mean by RPCs making the game ‘unplayable’. If you can imagine, the ‘reliable’ part is completely necessary (although ‘ordered’ isn’t so important). I mean, if you send that over UDP and it’s dropped, the game state can quickly become out-of-sync between the clients, and that’s something you NEVER want to happen. And, additionally, if he’s using either PUN or Unity Networking, that’s the only option he really has.
That said, I’ve never had issues with using RPCs for that kind of situation making a network game lag too much, or use massive amounts of bandwidth either.
In short it’s probably not a huge issue. The only thing you wouldn’t want to use it for is state synchronization.
Most fast paced games become out of sync regardless. So you just compensate for it [updates syncing].
Well, that’s mainly only applicable when you’re talking about, say, movement (if a packet containing player position/rotation is dropped, it’s going to be corrected soon anyway, but that’s not the case with stuff like damage messages)
Damage for most units [other than say your own] can be an estimate - no need for extreme accuracy.
fholm talked about shots, not damage. They are completely different messages.
Well, except he’s talking about an FPS, not an RTS. So, yeah you only need mostly accurate health values for teammates (if you’re in team-based modes like Team Deathmatch or Capture The Flag), but generally the same code that would apply to teammates works for all players in the game regardless.
And yeah, stuff like animation data could certainly be sent unreliably (aside from damage messages). But, in the case of Unity Networking or Photon Unity Networking (which I’m assuming the OP is talking about since he refers to RPCs), you don’t have a choice, RPCs are your only option and they are always sent reliably.
Not in uLink 
Anyway, I get what you’re saying though. I think the amount of damage done by sending firing messages with reliable RPC’s is slightly overestimated by fholm, but he’s a super persnickity kind of programmer, and I can respect that.
I bought Foreign Legion: Multi Massacre as a case study for a shipped PUN game, it works as well as anything, I’ve played many hours and never noticed any severe de-syncs, even in poor network conditions. Granted, maybe there was some, but if I never noticed, the illusion was maintained, and that’s all that matters, right? I spoke to the developer a bit on google talk, every firing message (even full auto, 10x per second) is an individual reliable RPC.
Thanks PrimeDerektive! Probably also important that there be some kind of timestamp with the RPC, so maybe indeed if an RPC comes too late, it will be dropped (ie, if the player fires and the message arrives at the server 10 seconds later, don’t implement that shot). I assume games such as Foreign Legion: Multi Massacre have that. Think this would be useful for both reliable and unreliable.