4 ms·

Ah - sorry if I wasn't clear. My point is that if you're implementing a turn-based multiplayer game like this, your game logic preferably shouldn't be on the cl

Ah - sorry if I wasn't clear. My point is that if you're implementing a turn-based multiplayer game like this, your game logic preferably shouldn't be on the client at all. By "concessions" I mean you might have little things like starting the animation for a move immediately rather than waiting for the server to acknowledge receipt, but the ideal turn-based board game client is one that knows nothing about the rules of the game it's playing - just how to parse and render the moves and state it gets from the server.

nurettin 6y ago
No I would very much prefer client side validations instead of hogging the server every time client requires a feedback that concerns the rules. For example: Playing backgammon, you choose a piece, you get highlights on where it can go. That requires the full working ruleset on the client side. There is no case to be made for requiring this feedback from the server no matter how confident you are that your server can handle it or how good client's internet connection is.
- filleduchaos 6y ago
  Multiplayer backgammon doesn't require a full working ruleset on the client side at all. Like I mentioned, these are _turn-based games_. To an extent, you're thinking about them like they're real time, and that's where the problem is. With backgammon (as with Ludo, which I'm building at the moment, so I have direct experience with this) you _have_ to roll the dice on the server or else the enterprising player is just going to game them. And if you're returning the value of the rolled die from the server, you can simply return the set of legal moves as well.
  - nurettin 6y ago
    You could return the set of moves, or you could -not- do that, and just run the state machine in the client. That way, you don't have to complicate the server by making it calculate future moves and write yet another client which is purposefully less featured, but still intelligent enough to parse the returned moves and map them to whichever piece is selected and you have less code to maintain. You can keep on gambiting around the problem with "concessions" which is easily solved by activaing code you've already written on the client side but that's no more than a mental exercise and has little to do with efficiency in problem solving.
- dmurray 6y ago
  It only requires the client have a list of currently legal moves, not the complete ruleset. Though I generally agree with you, it's convenient and not at all an antipattern to have some of the rules logic in the client - for example, you might have no other reason to generate an exhaustive list of legal moves server side.

nurettin 6y ago

No I would very much prefer client side validations instead of hogging the server every time client requires a feedback that concerns the rules. For example: Playing backgammon, you choose a piece, you get highlights on where it can go. That requires the full working ruleset on the client side. There is no case to be made for requiring this feedback from the server no matter how confident you are that your server can handle it or how good client's internet connection is.

filleduchaos 6y ago
Multiplayer backgammon doesn't require a full working ruleset on the client side at all. Like I mentioned, these are _turn-based games_. To an extent, you're thinking about them like they're real time, and that's where the problem is. With backgammon (as with Ludo, which I'm building at the moment, so I have direct experience with this) you _have_ to roll the dice on the server or else the enterprising player is just going to game them. And if you're returning the value of the rolled die from the server, you can simply return the set of legal moves as well.
- nurettin 6y ago
  You could return the set of moves, or you could -not- do that, and just run the state machine in the client. That way, you don't have to complicate the server by making it calculate future moves and write yet another client which is purposefully less featured, but still intelligent enough to parse the returned moves and map them to whichever piece is selected and you have less code to maintain. You can keep on gambiting around the problem with "concessions" which is easily solved by activaing code you've already written on the client side but that's no more than a mental exercise and has little to do with efficiency in problem solving.
dmurray 6y ago
It only requires the client have a list of currently legal moves, not the complete ruleset. Though I generally agree with you, it's convenient and not at all an antipattern to have some of the rules logic in the client - for example, you might have no other reason to generate an exhaustive list of legal moves server side.