What should the client and server handle for a fighting game?

Help and Feedback Scripting Support
#1

Just have a quick question about something. I’m attempting to make a fighting game that’s kind of the same style as Black Magic or like Soul Combat although I’m not sure what I should make the client and server do.

I know the client shouldn’t do anything important because exploiters but I feel like there’s a lot of things that would be easier to do on the client anyways my question is for a fighting game what should the client handle and what should the server handle?

I’m assuming the client should just do user input and any kind tweens or effects if the input needs it and then the server does pretty much everything else?

1 Like
#2

I’m taking it that you are referring specifically to combat.

There are multiple ways to go about this, but the most optimal system would be the following:

Use the client to handle effects, and anything visual that needs to be responsively seen to get good action feedback. Handling effects on the server can be lag producing in large amounts, and will not be responsive to the player, as they need to replicate.

In terms of the actually damage detection, perform checks on the client to detect a hit when the desired input is pressed, to confirm a hit. If a hit was connected, send a message to the server, which should then recheck the hit to make sure it wasn’t just a exploiter firing the event( this is called a sanity check ), and deal damage if the hit wasn’t faulty.

4 Likes
#3

What’s the point in having the client check for the hits? The server is going to end up checking anyway, why don’t you just check from the server in the first place?

#4

Checking on the client first improves performance, as you only need to ask the server to check, if a hit is confirmed. Firing a RemoteEvent every single time a certain input key is pressed, would not make for a happy server. It’s best to limit the amount of work the server has, to keep lag to the minimum.

2 Likes
#5

oof… does that mean this is bad?

local controls = {
	["1"] = function(Input) --special move 1
		local inputFunction = repStorage:WaitForChild("Functions").Input:InvokeServer(Input)
		for i,v in pairs(inputFunction) do 
			print(i,v)
		end		
	end,
	["2"] = function(Input) --special move 2

	end,
	["3"] = function(Input) --special move 3
		
	end,
	["4"] = function(Input) --special move 4
		
	end,
	["5"] = function(Input) --special move 5
		
	end,
	["E"] = function(Input) --light combo
		
	end,
	["R"] = function(Input) --heavy combo
		
	end,
	["F"] = function(Input) --hit up
		
	end,
	["Q"] = function(Input) --block
		
	end,
	["T"] = function(Input) --taunt
		
	end,
}
#6

It’s definitely not optimal, but it would work okay as long as you use server debounces, and don’t have code that uses a lot of resources on the other end. A better system would be to perform client checks first, though.

1 Like
#7

Using raycasts as an example, do you think it would be a good idea to do the raycast on the client then do a magnitude check on the server? If the player is under 3 or so studs away from the position the client says they were hit, then it registers it as a hit. Because I feel like if the server was just checking the exact same spot, it wouldn’t work most of the time especially if it barely hit them. So a magnitude check can allow for a bit of flexibility.

1 Like
#8

Yes. This is exactly what you would want to do. Perform the hit check calculations on the client, and then make sure that the hit isn’t bogus on the server, by checking magnitudes, and by other things such as making sure the hit position isn’t facing the opposite direction the player is facing, which would be impossible.

2 Likes