The classic solution is to put all network activity in a separate thread, or to use a non-blocking approach.

Personally, I like the separate network thread - you can react to the thread terminating unexpectedly (catch exceptions) and allow your persistance mechanism to back up your gamestate.

I have NO knowledge of .NET or C#. I'm afraid it's old skool C / C++ for me.

When you create a thread (in C++ windows api) you specify a funtion pointer to a threadmain function. The OS level thread is created as a child of the process that created it (actually the process forms a primary thread when started, so you'll notice two threads in your debugger) and executes the threadmain function. Destroying the process should terminate the child threads, but may not close files, or perform any cleanup.

It's bad practice to uncleanly terminate a thread. It's much better (and safer) to have a state variable to trigger the thread to die properly and do whatever housekeeping it has to do.

I have a thread object, which for the sake of illustration consists of three virtual functions a single pure virtual, and a flag. There's initialise( ), run( ), and m_bQuit. The pure virtual is update( ).

The threadmain function takes a pointer to an instance of a thread object. It calls initialise( ), then run( ), then shutdown( ). run( ) enters a while(!m_bQuit) loop, which calls update( ). update( ) is implemented in derivations of the thread class.

An application wanting to stop a thread therefore sets its m_bQuit flag, and the thread will call its cleanup stuff in shutdown( ). Obviously, you can put a lot more control in than that, but it's the general idea. You'll need to implement a number of things on top of this - mutexes for making stuff threadsafe, and at least a waitForThread( Thread* pThread ) style function so you can block until a particular thread is done if you need to.

Most people don't embed GUI's directly into server apps, for various reasons, one of which is to avoid the kind of complexity and trouble you're running in to.

Quote:Original post by DwD
Mike;
I may be incorrect with this, but, I don't think I am embedding a GUI into the server. Rather, I am including a GUI with the server. I could exit the GUI and leave the server running in the background. I don't think I'll do this though. The reason I am including a GUI, is to make it simple for others to operate. The server will be distributed to end users with little or no ability to write a batch file and pass correct parameters. With a GUI, clearly explaining the required parameters, and with examples/default settings already in place, I'll spend less time supporting and answering questions. At least, this is my hope.

... and besides, its prettier ;-)

You should be able to do both. Write a completely seperate GUI app, which COMMUNICATES with your game server - don't actually have the GUI app BE the game server. There are many advantages to this, including performance issues.

Consider making your server completely data driven off data pulled from a database. Then you can throw togeather a very simple web app which allows a user to modify and adjust settings. Web apps are perfect for this situation for many reasons (distribution, commonly known UI, etc.).