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 _______________________________________________ kde-games-devel mailing list kde-games-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-games-devel