A commonly asked question by programmers who start out trying to develop networked client/server games is whether to run two separate editors and debuggers; one for the client and one for the server. Not only is doing so annoying from a machine resource point of view, but it's also hard to remember to re-build both projects when making changes in one side. There are better ways to test a client/server architecture.

Easiest is if the client and server can be compiled and run in the same program. Then a simple "F5" will debug both the client and server at the same time.

At the code, you could structure your client and server code to be polled, in a sense, calling a single "server->step()" and "client->step()" call per time through the main loop. You might also want to separate out client->render(), if you want to be able to step several clients but only render one of them (useful when testing multi-player locally).

Your code might look something like:

  InputSystem * input = new InputSystem();
  SoundSystem * sound = new SoundSystem();
  GraphicsSystem * graphics = new GraphicsSystem();
  LogSystem * log = new LogSystem();
  NetworkSystem * serverNetwork = new NetworkSystem( GAME_PORT );
  NetworkSystem * clientNetwork = new NetworkSystem( 0 );

  Server * server = new Server();
  server->setLogSystem( log );
  server->setNetworkSystem( serverNetwork );
  server->started();

  Client * client = new Client();
  client->setInputSystem( input );
  client->setSoundSystem( sound );
  client->setGraphicsSystem( graphics );
  client->setLogSystem( log );
  client->setNetworkSystem( clientNetwork );
  client->started();

  while( running ) {
    input->dealWithOsEvents();
    client->step();
    server->step();
  }
Some people like factoring all the "set" calls into a single struct or hashtable called an "operating environment" for the different program components, and pass this environment to all components so they can call each other easily. You can then create two environments, one for the server, and one for the client, to mimic the actual behavior once the programs are compiled as two separate binaries.

Similary, maybe each major system needs to be stepped when in the main loop; that could be done with a stepping service that steps a list of steppables -- you get the idea.