Client/Server game even in solo: any big problem?

Question

I'm making a game which have strong basic design based on multiplayer but also should provide a really interesting and self-sufficient solo game. A bit like a real-time strategy game. The events and actions taken shouldn't be as massive and immediate as in a FPS, so you can also think the networking like for an RTS. It's a PC game, targetting Windows, MacOSX and Linux (Ubuntu & Fedora). It's programmed in C++, using a variety of open source libraries, so I have great (potential) control over the performances.

So far I always considered that just making the game work with two applications, client & server, even in solo mode was ok.

However, as I'm in the process of starting the network code I'm having doubts about if it's a good idea. I'm not a specialist so I might be missing something in my analysis.

I see these pros and cons:

Pros:

• The game works only one way so if I fix a bug it should apply on all game modes, whatever the distance with the server is;
• Basic networking issues would be detected early, including behaviour with the protection softwares (firewall) installed (i am not specialist so this might be wrong);

Cons:

• I suppose that even if it should be really fast enough, networking client and server on the same computer would still be slower than no networking and message passing in (one) process memory.
• Maybe debugging would be more difficult? I don't have experience in this case but so far I assume that debugging with Visual Studio allows me to debug multiple process so it shouldn't be really different. Also, remote debugging.

My question is: is there a big disadvantage that I missed? Or maybe there are advantages that I missed and that should encourage me to just continue with only client-server game sessions?

Answer 1

There are two ways to look at this:

1. If you are decided as to the fact that you're going to be devoting a lot of time to this project, it would seem a good idea to build it multiplayer, client-server from the start. Changing a game design much later on to be multiplayer is a really bad idea, because it affects the entire dynamic, from the little things like latency right up to the high level design choices. The differences will lead to a completely different game, no doubt about that.

2. If you're not yet 100% sure that this is something you want to turn into the full-blown game that you envision, then be careful going down this route that (as it is not your specialty) is probably going to take up a whole lot of time that might be better spent hashing out the basic game dynamic to see if it's a viable project -- and then adding multiplayer. Also note that although you have the joys of BSD sockets under all your supported platforms (if you are using those directly), while that's meant to be largely identical from platform to platform, I would think that porting and bugfixing that code across all of those will probably be quite "fun".

Having said the above about porting, I sincerely hope you intend to write for one platform first, unless you write very portable code indeed. Getting a running game on one platform should be your first goal.

Re message passing: A socket is a socket. I've played a number of games in the last 15 years that ran TCP client and server processes on the same machine. Performance was, if anything, better because latency was reduced.

Re debugging: distributed debugging is ALWAYS harder -- no doubt about it. The best you can do in that regard is to inform yourself as to the best network debugging tools available that are within your price range. Also, I think you have already answered your own question about VS and process-specific debugging on your dev machine.

The main advantage in going client-server now is that you will be able to effectively account for latency as part of your game dynamic -- nothing to sniff at. Another is that you will be able to get feedback from others, affording a more objective view of the game as it develops.