Design for a game with Gtkmm as GUI and GLibmm for threads

[Niko Demmel <niko demmel gmx de>]

I am programming a little game, mainly to get a better understanding of
thread, network, AI and gui programming in c++.

So I was thinking about the general design of the game and with certain
things I'm not sure whether I should do it the way I want to.

My idea was the following:

I want portability and am not so much interested in nice graphics, so as
GUI i chose Gtkmm. A drawable is sufficient for graphic output.

Then I have a multithreaded approach where there is a GUI thread, a
thread for game logic, possibly later, maybe one for networking and even
AI. The idea is that every thread runs a Glib::MainLoop and the threads
communicate through signals and Glib::Dispatchers.

Here I've encountered the first problem: you can't have parameters for
your Dispatcher signals... I'm allready working on a solution: A new
Dispatcher class template that can take 1, 2, 3... parameters and is
used in the same fashion as Glib::Dispatcher (I'm kinda mixing ideas of
libsigcx into the Dispatcher concept of glibmm. Maybe if I do a good job
this could be reuseable).

The second problem is how to integrate e.g. the execution of game logic
into the MainLoop of the game logic thread (for the GUI thread there is
no such problem, obviously). I want to do as many game logic iterations
as possible(or as neccesary??)  but still be able to respond to signals
from other threads, e.g. requesting data or providing input.
One idea is to use a timeout handler. This would allow fine tuning of
how often the game logic iterations should be executed by adjusting the
timeout time. Would it e.g. be possible to set a 0 second timeout to
acheive the maximum "throughput" of iterations, or would that "clog up"
the thread so that other signals are processed unreliably?
The other idea is to write my own MainLoop class that uses the MainLoop
functionality but has an extra call for processing the game logic
between the iterations of the MainContext. This solution seems a bit
messy and I'd like to go with the first one

Is there any better solution to the first or second problem?


Then I stopped and thought whether it at all is recommendable to run
GLib::MainLoops in all the threads.

Contras are:
    * overhead of the mainloop (both memory and coputational time), not
sure how much that is... might be neglegible for my purposes... (which
sort of signals will the a main loop in an extra thread reveive? Any at
all apart from the ones I send through dispatchers or timeouts [there
will be idle signals aswell i guess])
    * if stuff like game logic can't easily be integrated, then its no
use having a MainLoop

Pros are:
    * no need to code my own main loop. The Glib one has been tested
lots, so should be good.
    * the dispatcher interface of the components is quite general with
sigc++ slots allowing easy integration of new components
    * what is more it might even be possible to easily connect two
components on two different machines and thus implement networking. E.g.
have the gamelogic running on a server to which different GUI or AI
clients can connect via TCP. (I've stumbled across the postyyyman
library which does that, it seems. Haven't examined it closely yet)


So would like to get some feedback on what others think about my ideas,
so I don't go off programming all this to realize that it doesn't
actually work very well.

Thank you!
Regards
Niko