Java - Online game, should the game happen in the server or the client?

Question

I'm implementing a multiplayer option for a chess game I made, but I'm starting from zero to do both client and server. A friend said to me to make the game happen in the server, and the client only gets the data and shows in the GUI. Does this means that I have to implement the game in the server (without GUI); and in the client project, just the GUI, actionListeners and stuff, so that, for example, when I click on a piece and then click where I want it to go, the server will "make" the move (set new position etc) and then send this information back to the client so that it can print? Is this the best approach?

By the way, my server can (will) host several games (each time 2 sockets connect it creates a game thread). Oh and also, after finishing the game, I want to implement a little chat in-game. Don't know if this information changes something...

Answer 1

Longer answer is that you really have a lot of flexibility in how you want to do this. The "traditional" way of doing this is the model-view-controller pattern, where you separate the model (game state) from the view (what the board looks like), and a controller (your server code) handles interaction between the two.

The question is where to place each section of code.

One option is to place have the client do the heavy lifting with the server acting as a middleman between clients and communicating updates. This has the advantage that servers don't need to do as much work, but results in a client that can be easily modified for cheating.

The other option is to place most of the important code on the server and simply have each client be a "dummy" display that just shows whatever the server sends and just send the bare minimum amount of information to the server for the server to determine what was done. This is more hackproof, but places greater load on the server.

You can also do a hybrid model where the both the client and the server share the load of sanity checking, so the load on either isn't quite as severe. I think that this is a pretty good option, even though it violates the "pure" MVC pattern.

What works "best" for you might depend on the kind of load you expect on your server. For a small number of connections, "pure" MVC with "dumb" clients might work. Client makes move, server verifies that the move is valid, and if so, sends updates to both clients. If your framework starts to get overwhelmed you might want to consider putting some checking code in the client though.

None of this affects having multiple pairs of clients or a chat. You should be able to implement each of those parts separately, and if done correctly piecing the modules together shouldn't be bad.