[Kde-games-devel] Re: GSoC Project: Multi-Player gaming in KDE games

[Josef Spillner]

:: Viranch Mehta Mittwoch 02 März 2011
> OK, so after kggz is imported, all that is to be done in the project is to
> provide relevant UI in all the kdegames? Because as far as I know, ggz IS
> the online gaming library.

It depends on what we want to aim at: More games having simple multiplayer 
features or some selected games having outstanding multiplayer features. IMO 
the latter choice is what should motivate us. But this is the harder part, 
because it requires you to work on the networking, integration and social 
aspects instead of using the existing APIs.

Here are some keywords which help to understand the anticipated stack from the 
bottom to the application level:

- Low-level networking primitives [kggznet]: These are in principle provided 
by Qt. However, with early Qt 4.x versions there were some issues which have 
resulted in workarounds. A "junior job" would be to see if they still exist, 
and file bug reports against Qt, or remove the workarounds. Apart from that, I 
consider this part of the library stable.

- Declarative protocol specifications for the low-level networking: Even if 
the low-level primitives work correctly, often networking bugs are introduced 
by the programmer who tries to manually create a state machine with protocol 
interaction links and constraints. Instead, most of this code (including error 
handling) can be generated. This part is provided by a GGZ-provided component 
called "protocol generator", although it is not tied to GGZ in any way. In 
fact, we could make it a separate project, but it is probably only worth it 
when somebody would invest effort into this tool.

- The "middleware" parts [kggz(d)mod, kggzcore]: This is where GGZ really is 
at home. It is about managing users, sessions, game engines, game clients and 
servers, scoring systems and so on. There has been already some experimental 
work of outsourcing the users + sessions part to Jabber so that GGZ could be 
reduced more to concentrate on the tasks which are not yet covered by any 
other open source project. (Telepathy comes in at this layer as well to put 
things into perspective and is related to outsourcing to Jabber.) Makes sense, 
but again, requires some effort.

- The "frontend" parts [kggzlib, kggzgames]: Something along the line of 
desktop-integrated social gaming. This layer has many sublayers ranging from 
simple and composite KDE/Qt widgets to dialogs and desktop workflows. It also 
has a sister layer on the web, although integrated into the desktop is of 
course the better choice.

If you think that you're up for these challenges, I'll be glad to assist you 
as much as possible. Just tell which of the layers in the stack is the most 
interesting to you.

We will have a KDE game meeting soon in which Stephan will make sure that I 
will contribute some code instead of just broadcasting theories :-)

> Also, is Josef on this ML or do I need to contact him separately?

Yup, I'm reading this mailing list. Alternatively, you may find myself lurking 
on IRC in #kdegames (not often, mostly in the evenings) or you can reach me 
without the usual mail delay at xmpp:josef at kdetalk.net.

Josef