Hi, 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. 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 virtual base class or separate program methods? Fulby

quote:Original post by Magmai Kai Holmlor
A single process is generally a superior solution (IMNSHO).

It''s this part of the system I''m most unsure about. What I consider the best solution at the moment is for the Manager to create threads for Network comms and any other processing that needs to be done while a Game is running, hide its GUI windows then 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?

quote:ITurn : interface to access the turn data. You could do something crude with a size_t and void* like IMediaSample, or something complicated mixing interfaces and templates.

ITurnRecipient: This is the interface that the game exposes to receive turns from unknown turn producers.

ITurnProducer: This is the connection point that producers must implement in order for turn recipient to register thier need to receive turns.

Thanks for the advice, I''m planning to keep the data passed to the Manager as something like a void* and uint because that''s all it needs, though I think a Turn class would be useful for Game development to formalise what data is being sent in the turn buffer.

The Turn class could include CompressToBuffer and UncompressFromBuffer functions. Each Game would add extra member variables to hold the necessary data, then write the Compress/Uncompress functions to translate between variable and buffer formats. It would keep the turn data creation code more organised and help prevent the programmer sending inappropriate data (enemy''s moves for instance) as the Turn class would need member variables for all data to be sent.

Fulby