2
votes

I'm writing a game server and clients. The server generates a world and serves that up to various player clients. It is not massively multiplayer.

The client (at least for now) runs a fairly demanding software renderer, as well as doing the standard client side simulation (which is then subject to approval by the authoritative server), so any processing scalability available on this end would be good.

The server will also be processor intensive, and given the nature of the project, is likely to only become more so as the project progresses. The world is procedural and some of that happens during play; world options are set before a game begins, based on system capabilities at that time (ideally with minimal outside processes running). So scalability on the number of hardware threads is an absolute necessity for the server.

Again, as this is not an MMO, players will all have access to both client and server, so that they can set up their own servers. Many players will have only one machine on which to both host a server, and run the client, in order to be able to play with their friends. Based on this fact, which would serve me better?

  • A combined client and server process
  • Separate client and server processes

...And why?

PS. Even if some of the above complexity only comes to pass later, I need to get the architecture (in this regard) right, as early on as possible.

2

2 Answers

1
votes

Separation of concerns is always an important factor, so it's better to keep them as separate processes. It's also better for performance. If I only want to use the client functionality, there is no reason to also keep the server-related code in the same application. I will only launch it if I need it.

1
votes

I'd say the most important aspect to help you with decision is - are there any computation intensive tasks that are shared for both client and server? If you can do some computation for both client and server once instead of twice, then it makes sense to have one process (but this may be quite hard to implement). Otherwise i say separate it.

I see few advantages with separated processes:

  • when client crashes (i'd say more probable with complicated renderers and/or buggy graphics drivers) server stays up
  • accidentally(and/or angry QQ) exiting game won't kill the game for other players
  • (if needed) it's easier to bind server to few cores and client to others
  • you probably need to write dedicated server anyway (so it can be hosted on remote servers, possibly without graphics) and porting it to other OSes might be easier ...
  • makes the client code overall less complicated

(i may later add something to the list if i come up with it)