New answers tagged server
The solution I prefer is to put all game-specific logic in the client. The server only acts as an I/O reflector to make sure all clients are up to date. One benefit of this approach is that the same server can serve different games, since it knows nothing about the content of any specific game. There are a few things that have to be done centrally, such ...
As others have said, the first step is separating logic that's shared from logic that's not. While it's great to draw that line wherever it's clear, your addendum illustrates that sometimes you don't have a clean line to split the code down. So, how do we solve cases where the client and server want to do semantically the same thing (play a sound), but take ...
Extract any shared code to a library which you maintain separately. Then implement your client and server as a separate applications which implement anything specific themselves and reference the library for any shared functionality.
The cleanest way is to create a "core" project that includes shared game code. You can use either interfaces or abstract classes to prepare your game code there and use inheritance  to extend/implement these classes in either the server or client side. That way you do not need any if statements to distinguish between client and server code. You should ...
Top 50 recent answers are included