GSoC: KDE Games powered by Telepathy

[David Edmundson]

On Tue, Feb 21, 2012 at 9:34 AM, Daniele E. Domenichelli
<daniele.domenichelli at gmail.com> wrote:
> On 20/02/12 22:11, Stefan Majewsky wrote:
>>
>> Hi,
>>
>> on the GSoC ideas page, under "Telepathy", I saw a project to use
>> KDE-Telepathy to set up a multiplayer game in kdegames. It has a
>> "NOTE: We need to discuss this with KDE Games."
>>
>> As the de-facto libkdegames maintainer, I'd like to inform you that I
>> very much welcome this idea. I just removed the old KGGZ framework
>> from libkdegames, because it relies on a server infrastructure that
>> probably does not even work anymore, and I'd like to have a working
>> multiplayer solution very much.
>>
>> The best target for a KDE-Telepathy student would probably be KSirk,
>> because it already uses Jabber to set up a connection. It would be
>> great to port this in order to remove the giant heap of code that's
>> used for the Jabber connection.
>>
>> Because of real-life commitments, I will very likely not be available
>> as a mentor, but I volunteer for co-mentoring on this project from the
>> kdegames side of things, if desired.
>>
>> Greetings
>> Stefan
>
>
> Hi Stefan,
>
> I'm really glad you like the idea, I've been planning to write on the
> kde-games mailing list about this, but I didn't have time to do it.
> I had a look at KSirk code long time ago (actually 2 years ago when I was
> trying to write a project for GSoC when I was a student) and I think that
> porting it to use telepathy shouldn't be hard to do, because using telepathy
> you have "Tubes" that are a very easy mechanism for connecting applications:
> Streamtubes give you a QSocket that you can use exactly like a normal socket
> and DBusTubes give you a peer-to-peer QDBusConnection that is slightly
> different from a connection to DBus server, but can be used almost in the
> same way.
>
> If I remember correctly, in KSirc you already have a protocol that you use
> over TCP/IP or over Jabber, therefore a streamtube is probably the best
> option. You just need some code to choose the contact and connect and then
> you just need to use the QSocket that is created by the streamtube. The same
> is probably valid for Kbattleship (but I didn't check the source code)
>
> This makes, in my opinion, the project a little too short, that's why I was
> suggesting to add some more stuff to the project, like implementing
> multiplayer in some game that doesn't have it yet, or some kind of library
> to measure latency, or something else.
> What were the features offered by the KGGZ framework? we could use that as a
> model for writing the library...

> Maybe I'm wrong, but I think it is better to have a bigger project that we
> realize during the implementation that it cannot be finished, rather than a
> project that is finished after one month.

You have to be a bit careful on that. At the end of the 3 months you
have to sign off wether the student has "finished the project", and
they have to submit their code to Google. Whilst having stuff that
only takes a month is a bad idea, having a plan that realistically
takes more than 3 months risks simply getting abandoned and never
merged, I can list several projects where that has happened.



>
> What do you think?
>
> Cheers,
>  Daniele
>
> P.S. Your help in co-mentoring this project is very welcome!
> P.P.S. I'm CC'ing the kde-telepathy mailing list, as there might be someone
> else interested in the discussion
> _______________________________________________
> KDE-Telepathy mailing list
> KDE-Telepathy at kde.org
> https://mail.kde.org/mailman/listinfo/kde-telepathy