[Kde-games-devel] To use kgame or not to use kgame

[Josef Spillner]

Hello Wolfgang,

Am Freitag, 17. Juli 2009 09:43:34 schrieb Wolfgang Rohdewald:
> I did not yet study the ggz documentation, so this might be a stupid
> question, but what additional value does kggz have over the pure ggz API?
> Is that documented somewhere? I would guess that kggz contains a GUI based
> on KDE, what else?

Thank you for this technically interesting question. The issue is very 
general: when you have a library in C with handcrafted C++ and Python 
bindings/replacements, and the C++ library gets an automatically generated 
Python binding, which one should one use?

Here's some background information in the specific case of kggz and ggz-
python:
- ggz-python covers three wrapper libraries for game clients, game servers and 
core clients, and uses Python sockets for networking
- ggz-python contains some GUI and mainloop integration code for game clients 
using Pygame, but not yet for PyQt/PyKDE
- kggz also covers three wrapper/standalone libraries, but in addition one 
more for GUI widgets and game client integration, and one more for networking 
based on Qt sockets because Qt alone isn't sufficient for networking
- kggz doesn't have Python bindings yet

If you also want to write a game server, the question becomes more interesting 
as usually Python developers don't have the need for Qt/KDE on the server side 
whereas C++ developers would find themselves lost without a basic set of 
application and communication libraries. I wrote kggzdmod (for game servers) 
specifically for Qt developers, in addition to ggzdmod++ for pure C++ game 
servers, but for Python game servers I'd say it's easire and more "Pythonic" 
to just use pyggzdmod.

> for games written in python like kmj I see those possibilities:
>
> 1. ignore kggz and directly use the ggz python bindings, rewriting
> those parts of kggz I need in python
> 2. write python bindings for kggz

My assumption is that once somebody unleashes the kdebindings Python scripts 
on libkdegames, you would get Python bindings for kggz, libkmahjongg etc. for 
free. Of course this might be an overly optimistic view. The right guy to talk 
to is Simon Edwards. I've had a chat with him recently about Python 3 support 
but unfortunately did not bring up the topic of libkdegames bindings.

> For libkmahjongg I chose option 1 because kmj has more complex requirements
> that might have been difficult to add on top of libkmahjongg.
>
> for kggz it probably depends on how much I would have to rewrite in python

If you want basic networking support as fast as possible, I would indeed 
recommend to use the existing ggz-python libraries right now with the option 
to switch to some sort of "pykggz" later without risking a restructuring of 
your application, as both libraries are centred on asynchronous callbacks. 
There's a python-ggz package available for Debian/Ubuntu. It is however 
missing from several other distribution despite having been released a 
gazillion months ago. Bug your distributor to get it in in this case.

I could help by creating a PyQt mainloop integration layer similar to the one 
for Pygame. Does that sound good enough? Do kmj/libkmahjongg use threads?

In any case, use ggzcomm-based declarative network protocol descriptions so 
that you can have your networking code autogenerated for any programming 
language and library.

But as soon as we want to have standard online gaming dialogues across all 
games, it becomes an issue if Python games create their own. Some of them are 
designed to provide contextless invocation based on a hidden singleton GGZ 
module so that one doesn't have to pass around objects. Using ggz-python for 
the lower levels and eventually calling py-libkdegames-kggzgames dialogues 
should work. Nevertheless, this concept is not used everywhere yet and hasn't 
been subject to critical API review yet.

Josef