I’m trying to understand the recommended/best practices when it comes to division of labor between clients and server in a multi-player/networked jME game. I read this article which was an OK start but am looking for clarification on a few details.
Prior to reading the article, I would have imagined that the role of a headless server would be to act as a central point for maintaining and/or orchestrating certain app/world state. That is, you have Players 1, 2, 3, …, n all within close proximity to one another. Player 2 presses a key to jump. Their client processes this and they see their avatar on screen jump. Their client also sends a notification (say, a PlayerJumpedEvent) to the server, who in turn broadcasts that event out to the other connected players. The clients for these other players receive this broadcast event and process them accordingly (each player sees Player 2’s avatar jump, etc.). Something along those lines.
But after reading that article I get the sense that all of that is not the case, and that the server is somehow responsible for maintaining a central “source of truth” of the scene graph. Or something.
Can anyone provide me with, say, bulleted lists of typical responsibilities for both clients and server? I know each game is different but I’m sure there are some standards/best practices here.
You are still thinking of the “scene graph” as “game objects”. It isn’t. The game objects are the game objects. They exist in the game world. The “scene graph” is just one possible view of that game world.
This separation between “view” and “data” (AKA: Model in MVC terms) is usually important but especially so in a networked game.
In that case, the server is controlling the game objects. It somehow notifies that client of the state of those game objects and the client will update its view of the game objects. In theory, this view could be 3D, 2D, a text representation, whatever… the server doesn’t really care.
For simple coop! games played in a friendly cooperative context (eg only friends)
→ Do whatever you want wherever, do everything that makes sense on the server, to prevent issues with multiple incoherent worldstates. (eg the classical desync in WC3 where all players differ so greatly in state, that noone knows who is winning.
→ Especially physics is a case here that can be highly simplified for the server and run mostly on clients, as they can trust each other
Great example is older Arma games, played in coop missions, were the Game could simulate up to several hundred NPC’s , by assingin each client a few squads an do the AI there.
Great counter example is Arma in a Team vs Team context, that gives cheaters a real upper hand, as the server trusts those. DayZ Parachuting Cow Attack! - YouTube (Leading to kinda funny hacks as this (dayz uses same engine) ro just assholes crashing your server/instakillin everyone.
For games with random persons (eg say counterstrike) where a cheater might exist
→ Validate everything on the server, no shortcuts anywhere.
→ Client is only for rendering, and might so stuff the server does as well, to give a lagfree feeling, by approximating what the server might say, but the server is the truth here.
Good example here would be Counterstrike, that (tries) actualy even simulates the physic on the server, and additionally, tries to not send to much information to clients. E.g if a client is behind a corner for some other client, do not send the actual position to the client, to reduce the benefit of wall hacks.
An bad example would be: Unreal Tournament III 05 02 2014 - Cheater speedhack - YouTube There was an overly simplified calculation used in older UT engines, that basically assumed as long as you move slower than the maximum possible speed you are fine. Problem was, that maximum speed is pretty high without cheating, if a explosion just pushed you with high speed into some direction.
Thanks to both @pspeed & @Empire_Phoenix for the thoughtful responses. It will take me a few days to read through these links but I’ll followup after I get done with them - thanks again!