client rules vs server rules
Author
Because of possible exploits in a multiplayer game, I think it would be logical to poll the server for game rule decitions. However, should there be exceptions to this rule? As an example: in Starcraft, units firing on units on a higher ground, will only hit 50 percent of times. Polling the server each time a unit is firing a shot in situations like this might result in a lot of unwanted server polls. On the other hand, if this is a client decition, a hacked client might recieve 100% chance to hit every time!
Nobody will probably ever use their time to hack a client that I've made, and KISS is telling me to keep it simple. What do you think?
Edit: I think it would be insane to always ask server for game rules. I seriously doubt that units have to ask the server when they're able to shoot again.
Quote:Original post by Nunyah
Edit: I think it would be insane to always ask server for game rules. I seriously doubt that units have to ask the server when they're able to shoot again.
Except that's what everyone does.
Polling is obviously not used. There's two ways to approach this:
- Client sends actions to server, server evaluates them, and sends results back. This is done asynchronously, so the time between action performed and response seen on client is delayed by round-trip time. Just about every MMO does this. Latency is masked with client-side animation interpolation.
- Clients are autonomous, they evaluate everything themselves. They send user input to other peers, which evaluates them fully. As such, every client runs the same input (from all users) using the same code. If one peer is hacked, the simulations will diverge, and it will be disconnected.
Quote:Nobody will probably ever use their time to hack a client that I've made
It's not just that. Hacking is actually a side-problem, and defending against that is a bonus. Real problems are about synchronizing multiple clients.
As a trivial issue, consider rounding errors. Even if two clients aren't hacked, they might run on different hardware. And in rare case, hit would evaluate to true on one, and false on another. So on one machine, unit would be killed, and on another it wouldn't.
Author
So if I understand it correct, would this be a somewhat correct way of doing it, using your first approach to my example? I need to stress that this code is very simplified to make sure I understand the point. Clientside is keeping its own calculations on when a unit is able to shoot, mainly to avoid server requests that would be denied anyhow. But for consistency, this is checked on server as well (which who has the final say).
I think my above example considers RTT as well, but I'm not sure..
// ClientSide// Player1 attacks Player2's unit on higher ground.public void Attack(MovingEntity entity){ if (AttackReady && IsWithinRange(entity)) { ServerEntityRequest(AttackRequest, this, entity); SetAnimation(Attack); }}selected_entity.Attack(targetEntity);// A few ms later..// ServerSide logic recieves the attack request.public void HandleRequest(Packet packet){ switch (packet.RequestType) { case AttackRequest: { if (packet.EntityOne.CanShoot && packet.EntityOne.IswithinRange(packet.EntityTwo)) { // entityTwo is on higher ground - 50% to hit. Calc response: unit hit! // send response to both players with entityTwo's new hit points as well as a request to show a EntityGotHitAnimation. SetEntityAttackCooldown(EntityOne, 1000); ... } } }}...// a few ms later..// Both clients recieves the server response to the attack, and updates the units accordingly and executes the appropriate animations.I think my above example considers RTT as well, but I'm not sure..
Exploits in major games are often a result of that when you have millions of people playing, they will eventually find every tiny little bug and exploit. Either that, or they understand the consequences but they take some of the load off the server just to handle more players with less hardware. Maple Story is a good example of this, and what can happen even with a lot of client-side protection.
An approach I've been using is to check everything client-side, but send it to the server with the assumption that it will be the same result the server gets. Then, if for some reason beyond the client's control, the server comes up with a different result than the client, then the server notifies the client and the client back-tracks to where it was before the unacceptable notice. The bad side is that this causes noticeable jumpiness when it does happen, but idea is that it should happen extremely rarely (unless, of course, the client is hacked).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
