I originally posted this topic in General Programming but didn''t get much of a response and having read a bit on Software Engineering I think I may get more advice here. I''m currently designing a Game Manager which would manage several multiplayer turn based network games as well as messages between players. I have some queries which I hope more experienced people can help me with. The idea is for the Manager to log on to a central server, download any new game turns and player messages, and run the appropriate game when the player selects a game turn. When the player has entered his next move, the game exits and sends the player''s move to the Manager which uploads the data to the server for processing. I''d like the Manager to place as little restriction on how a Game is written as possible. The Game and Manager need to communicate though and I''m not sure what the best method for this is. Features I''d like the solution to have: The Manager should need to know as little about the game as possible, so for instance loading the saved game from the HD and understanding the turn format should be part of the Game not the Manager. The Manager should notify the Game in progress if a new player message arrives. Possibly, the Manager should pass window messages to the Game (minimise, close, etc) and/or from the Game to the Manager. The two main possibilities I''ve come up with are: * A CGame virtual base class, which each Game derives from and forms the interface between the Game and the Manager. The Manager would create a new CGame instance for the appropriate Game, passing information to it. It would probably pass a window handle, the game''s ID and a buffer with the new turn in it. The Game would then use the window handle to create whatever display it wanted (windows dialog, DirectX, etc). The Manager would still need execution time to process window message and network systems, and I''m unsure of the flow of program execution. Would the Manager pass control to the Game and the Game call Manager functions when it had the time, or would the Manager repeatedly call a Process function for the Game? The first option sounds a lot better to me, or the Manager could create threads to handle window and network messages while the Game ran in the main thread. A variation of this would be to use a C function instead of a base class. Either way the Games could be statically linked or put in DLLs so new Games could be added without modifying the Manager. * A separate program with some way to communicate with the Manager. Initialisation and return data could be passed in a temp file, with shared memory or a socket connection providing communications while the Game is active (or use the socket for everything). Each Game program would need to follow the same protocol for command line options, socket set up, communication, shut down and temp file read/write actions so that it would be compatible with the manager. One of the long term goals is to make several Games which are subgames of a larger game. I think writing it as a class is a better method for that than using a separate program, but I''m not sure and don''t want to make the wrong decision and find out several months from now . Has anyone done a similar project and/or have advice on how to proceed? What information which has to be agreed between the Manager and Game? So far I''ve got: Window Handle (maybe) Turn data (in buffer or file) Game ID (may be part of turn data) Process ID of Manager (maybe) Communications method during play Command line options for separate program Games What are other pros and cons of the abstract base class or separate program methods? ---------------------------------------- What I consider the best solution at the moment is a single program with the abstract base class for the engines. The Manager would create threads for Network comms and any other processing that needs to be done while a Game is running, then hide its GUI windows and run the Game in the main thread. Each Game would be a class derived from a CGame base class. This base class would include: * Initialisation code which sets data the Game needs, i.e. the turn buffer, game number, window handle and semaphores/events for notifications. * A pure virtual Run/Proceed/Execute function which is the Game''s entry point. * Functions for getting the exit result and turn data from the Game once it is closed (caused by the Run function returning). I think the Manager and Game could communicate through a semaphore/event and a shared std::list. The Manager would add messages to the list using the event for access control, then the Game would poll the list regularly removing messages from it. The Manager threads could then pass on messages like "new player message" , "close game" or "minimise". Is the overall system workable and is there a better way to do it? Fulby

What your building is anaglous to the tiered applications more common in web based systems. By breaking down each module into its own process, you insulate them from a critical failure which could bring down the entire system, this tradesoff on performance and simplicity.

The design as you''ve laied out is the tradaitional server-client network topology. The Game Manager which you call it is the Master Server which spawns, mediates and records games (in this case client sessions).

Since your doing a multiplayer game, you should know enough about network programming. The Master Server exposes data channels ( sockets ) which the clients connect too and instantaie game instances locally after downloading the approrirate data. Messages are rotued through the Master Server to their destination. Data is persisted upon the client exit, by uploading the client state data too the Master Server which then usually pipes that too the database. An issue is one of security. You can simulate the game logic on the Master Server and pipe the result too the clients to prevent client side hacking. This will also oblivate the need for uploading data too the Master Server.

If you follow the above advice, each game logic instnace can reside on the server. This creates another tier in your network hiearchy, such as Master Server -> Game Logic Server -> Clients. The Game Logic Server can access the DB directly so no need to upload the data back to the Master Server.

Hope this helps, Good Luck!

-ddn