Structuring a 2D Fighter

[Geomaster (Dude)]

Hey, and thanks for reading in advance.

I’m getting the framework ready for a 2D fighting game I plan to devote more time to in the future (it’ll be easier to work on if the basics are already there). I know games like this are rare on the platform, but I decided to try my hand at one anyway. That said, there are a couple code-design issues I want to iron out before I start doing anything substantial.

1. These games need to be extremely responsive - this means the server involvement is minimal at best. When a player connects an attack, the other player has to be stunned and incapable of moving for a finite amount of frames. Should I have the client manage the states of the other player (I.E. forcibly playing hitstun animations and immobilizing them) and simply have the other client repeat the same procedures on itself? Should I have the server tell the other player to enter a stunned state?

2. I don’t typically have trouble with hit detection, but in many 2D fighters under the hood, each character has predefined areas on their body (hurtboxes, hurtcircles) that control where they can legally connect with an attack. These areas can often be moved, disabled, resized, or removed outright depending on the current state of each player. Could I even replicate this behavior without the server being a bottleneck?

3. I know any design for a game like this would mandate extremely poor server-side security for the sake of performance, but is there any way to soften the blow from the inevitable wave of cheating in a game like this?

[Monkepath]

@Geomaster

Should I have the client manage the states of the other player (I.E. forcibly playing hitstun animations and immobilizing them) and simply have the other client repeat the same procedures on itself? Should I have the server tell the other player to enter a stunned state?

This is risky to do without server-side simulation or checks due to exploiters, and since this game style would be otherwise pretty much impervious to exploits, it would be a shame to open up basically the entire combat framework to exploits. What you’re looking for here is lag compensation. Here and here are great articles on it from valve. I think a combination of client-sided movement prediction and latency compensation for hits would make the game smooth while having minimal hitreg issues from the client’s perspective. My game prototype currently uses PlayerPing to do this, which has turned out to be extremely precise from experience, and is supposedly very secure and exploit-proof.

@Geomaster

I don’t typically have trouble with hit detection, but in many 2D fighters under the hood, each character has predefined areas on their body (hurtboxes, hurtcircles) that control where they can legally connect with an attack. These areas can often be moved, disabled, resized, or removed outright depending on the current state of each player. Could I even replicate this behavior without the server being a bottleneck?

I think servers are more powerful than you give them credit for. The server shouldn’t be a bottleneck at all, especially if you’re using simplified hitboxes instead of exact geometry for hit detection. Basically every game with damage or collisions in it needs a hitbox system, and they don’t have lag issues due to hitboxes.

@Geomaster

I know any design for a game like this would mandate extremely poor server-side security for the sake of performance, but is there any way to soften the blow from the inevitable wave of cheating in a game like this?

If you simulate the hit events on the server (which should take a really tiny amt of time anyways), then it shouldn’t be exploitable other than the client sending wrong hit types or new hits or when they shouldn’t, which can be checked fairly quickly (if they could physically make the hit, if the cooldown has passed, can they make that move, does it match up with server simulation, etc).

[Geomaster (Dude)]

I see.

I don’t underestimate what the server can do, but I definitely think it’s not the fastest at actually, well, doing. Even a single frame can spell the difference between a loss and a win in a fighter, so I’m curious if real-world online fighting games use a similar model to the one you described.

So, what should ideally happen if I want to maximize responsiveness and player feedback? Should they throw a punch, the server validates that the punch hits, and then corresponding SFX/VFX occur alongside hitstun? Should the effects happen immediately and the only thing the server validates for is damage and hitstun?

I also suppose that - for lack of a third axis - I could somehow use Vector2s in hit detection, but I’m not sure what functionality that data type has (can you even create a Vector2 region)?

[Monkepath]

Everything the client does should be visually simulated on the client to give them instant feedback of course. You’re right to assume that server latency would be a problem for your game (the resources I posted should help with that), but some things must be calculated on the server to make the game secure (the actual processing time of the server shouldn’t be a problem for most games): I was only saying that the actual hit and the damage applied (the stuff that gets replicated to the opponent’s client) should be server-sided. You could make everything 2d while keeping the 3d look if you compressed all the hitboxes etc down to one plane, but I think keeping it all in 3d is easier and would probably be more accurate too (performance shouldnt be a problem).

[HarryZoeiroGamer (Harry)]

how is this going, any progress?

[omnerisk]

1. do serverside checks!!!
2. do serverside checks!!!
3. do serverside checks!!!