Reputation: 449
My question is more related to validations of the movements in the game, the game is Checkers. I'm developing a Checkers game, in html, css, js, and nodeJS, the game will be multiplayer.
So my question is about the validation, what would be the best approach.
Right now all the validations (valid movement, etc) are done client side (of course must be server side).
My question is, what would be the best approach:
Having client side validation, if the validation is OK then send the validation to the server and validate it there if all is ok change turn for the next player, if not the server rejects the movement and the player have to do a valid movement.
No client side validation, just basics, all validation are done server-side.
Scenario 1: I think it's the best, because we don't rely that heavily on the server, if the movement client-side is wrong then it won't even send it to the server and if a player with bad intentions (modifying code) try to do bad movements there is the server with side validation.
Scenario 2: We rely more heavily on the server, it will consume more resources and will be slower for all online players overall, but it will be a little bit "faster" on the client side because there aren't as much validations as in scenario 1.
I think that Scenario 1 is the best approach because:
What's your opinion, or do you have a better approach?
Thanks all for reading.
Upvotes: 0
Views: 899
Reputation: 848
I usually prefer validation on server side for the following reasons:
tip: use socket.io, it is very easy to grasp, very reliable, supports server push messages
Upvotes: 0
Reputation: 823
This question is maybe a bit too open-ended and opinion-based for SO, but here goes:
Personally, I think having clients behave as "watchers" for the game server is ideal. The game server should be authoritative and do all the logic to ensure consistency.
I'm working on a networked JS game + engine right now and handle this as follows:
The server broadcasts 2 game states with timestamps to all clients. Each client then interpolates between state n
and n+1
. In that time, any user input is sent back to the server, which is then incorporated into states n+1
and n+2
which are sent on the next broadcast. When the clients reach n+1
in the interpolation, n+1
is corrected with the new pair of n+1
and n+2
.
This means clients can experience maximum of 1 tick's worth of lag if an event was fired at the beginning of an interpolation and not broadcast to the other clients until the next state broadcast. This can be about 200 ms before it gets noticeable, but that's pretty tolerable in my experience.
I came to this method thanks largely to this incredibly useful set of articles by Gabriel Gambetta:
I. Client-Server Game Architecture
II. Client-Side Prediction & Server Reconciliation
Obviously I can't include all of the articles, but the gist of what I wrote above is in this image from the first article:
Upvotes: 2
Reputation: 1495
I would say senario 1 is better.
You need to use both types of validations. As a user clicks, show movement on the client side by javascript validation, and in the background send movement code to the server for validation so that player sitting on another can see it. Anyways you will have to send data to the server so that other player can see the movement of the player.
Add client-side validation also to prevent unnecessary request to the server and it will also increase waiting time for the player.
Upvotes: 0