[Kde-games-devel] Roadmap for GGZ in KDE 4

[Josef Spillner]

Playing KDE games on the GGZ Gaming Zone
   - Development Roadmap for KDE 4 -
========================================

1) Introduction

The GGZ Gaming Zone offers a unified way to play games online in
a community of players.

Since GGZ supports a number of different platforms, toolkits and programming
languages, a lot of development power is spent on the maintenance, whereas
GGZ developers usually like to concentrate on improving GGZ itself.
A few months ago, it turned out that the best way forward is to integrate
GGZ better into the respective platforms, especially where this is possible
(i.e. KDE, GNOME and Pygame).

Plans to support KDE games on GGZ have existed for a long time already.
The KDE 4 development makes it possible to finally make it happen. Games will
get access to network protocols, GGZ integration and common UI elements
needed for it.

Every game has two open connections when running on GGZ: one to the core
client application, and one to the game server. It is theoretically possible
to let the game itself be the core client, so that it will have one
connection to the main GGZ server in addition to the one to the game
server; however, this is not implemented for KDE games yet and will have
to wait until a later date. Therefore, the first phase of GGZ integration
(aka this planning text) will require a GGZ core client (e.g. kggz or ggz-gtk)
to launch the games.

2) Libraries

In the long term, four small libraries will be offered for KDE/Qt game
development based on GGZ. They will be presented here briefly.

- kggznet: Network protocol implementations
  This library provides the KGGZRaw and KGGZPacket classes for easy
  protocol handling for non-quantised and quantised protocols. They
  are offered as a convenience especially for games which want to be
  compatible to existing GGZ protocols, which use exactly those
  protocols (called 'easysock' and 'dio', respectively).
  KGGZRaw is also used internally by KGGZMod.
  Games are however free to use any other protocol mechanisms, especially
  for XML-based or line-based protocols.

  In the future, all protocol code within the games shall be automatically
  generated by the GGZComm protocol compiler. However, until this is ready
  for production, using KGGZRaw/KGGZPacket/QXmlSimpleReader/KMessage/...
  is recommended.

- kggzmod: GGZ client integration
  Using this library, the interaction between a GGZ core client and a
  game client can be managed. It was released first for GGZ 0.0.14 in a
  KDE 3 variant and was subsequently improved and based on KGGZRaw for
  the next GGZ release. However, the plan is to have this library in
  kdegames for KDE 4 so GGZ's kde-games package can depend on it and no
  duplicate development is performed.

  The main class is KGGZMod::Module, but several others exist to handle
  game state events, player statistics, seat changes and so on.

- kggzdmod: GGZ server integration
  This will be a library handling the interaction between a GGZ server and
  a game server. Since game servers are not written in KDE/Qt a lot,
  the library doesn't exist yet. It might be a Qt-ish wrapper around the
  existing ggzdmod library, or a re-implementation based on KGGZRaw similar
  to kggzmod.

- kggzgames: User interface elements for games
  There is currently only one dialog offered, namely the seats dialog which
  allows players to watch the game participants, including bot players
  and spectators, and their statistics. It also allows host players to
  replace participants with others or boot them (table management).

  There will be more dialogs in this library in the future. Examples include
  generalised highscore dialogs and team management.
  The KDE 3 version of it (part of GGZ 0.0.14) also contained a SVG class
  (now obsolete with Qt 4.2) and a convenience class for handling
  out-of-prefix installation of KDE games which are not part of KDE SVN.
  The latter class is expected to stay with GGZ, which is why only the
  seats dialog is currently useful for KDE 4.

3) Open ideas

While most parts of the access to GGZ are currently stateful, i.e. embedded
into the main GGZ protocol, several parts could be made stateless, simply
because they don't need authentication and are useful in contexts other than
running games. One example is the statistics/highscore/rankings reporting,
which is already available via the GGZ Community web interface, but could be
offered as an XML stream which could be read by additional kggzgames classes.

In order to handle 'embedded ggzcore' games (i.e. those who can connect to
the main GGZ server on their own), the GGZCore++ library currently part of
GGZ's kde-client package must be rewritten either as a proper Qt-ish wrapper
of ggzcore or as a reimplementation. Since no work has been done for it yet,
this functionality is not part of this plan yet.

4) Development

Development happens in GGZ SVN right now, in the playground/ggz-kde4
directory and in playground/build/cmake for the CMake integration.
Since the game startup of the (patched) KReversi works well, it
should be the right time to move the libraries over to KDE SVN and apply the
patch to KReversi so the network mode can be finished. A lot of this depends
on UI changes and not on GGZ functionality, so this work can be done in
parallel with further GGZ integration into other KDE games.

The proposed directory structure is:
- libkdegames/kggznet
- libkdegames/kggzmod
- libkdegames/kggzgames
- cmake/module/GGZ.cmake

It is recommended to move GGZ.cmake into the CMake distribution at some
point, but it will need to stay in sync between GGZ and KDE until then.
KDE mainly needs it to find ggz-config and other GGZ things, whereas GGZ will
need it for the kde-games package to find the kggznet/mod/games libraries
which will not be in GGZ SVN any longer once moved to KDE SVN.

5) Server

While GGZ operates a server or two, a growing number of players will require
a better server. Hosting GGZ servers is not hard, but there is more fun if the
communities are bigger, because based on experience players will then spend
more time online, and feature-driven development happens faster.
No definitive decision has been made regarding a stable server for the KDE
player community. It is recommended to use the existing GGZ servers until
around the KDE 4 beta release and see what the needs are.

Josef