This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: my two cents on networked games


Jim Kingdon wrote:
> 
> As nearly as I can tell, the remote protocol is not close to working.
> Even if normal playing a game can be fixed, most of the obscure
> features (e.g. hitting the "people" menu item) seem to not be
> implemented.  In general, there are multiple bugs, not just one or
> two, as far as I can tell/guess.

Umm, the People menu item is a local display control - how is this
relevant to networking?

> I tried to look at what would be involved in getting the tcltk code to
> drive multiple X displays the way that the old Xt code did.  The
> primitives seem to exist in tk (-screen option to the toplevel
> command).  Of course the xconq code would need to keep all the
> relevant data in structures, of which it could allocate one for each
> display.  Around the time I started looking around to figure out how
> close the code is to this, I got distracted and it seemed better to
> spout off than to just ignore the question.

The multiple X display idea is not really that great - it took quite
a bit of work to get it right.  The problem is that every minute bit
of interaction has to be handled by the single program, and after
you've done all that, you've ended up with something that only works
on LANs, is not cross-platform, can't use DRI or any of the local
speedup hacks, is not robust when someone wants to leave a game, etc.

In fact, the old version of Xconq is unique among X games in using
multiple displays.  Every other multiplayer game uses its own
networking protocol (and is able to get it to work well!).

Stan

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]