[Kde-games-devel] [GSoC 2012] KDE game using QML ("Qt Quick")

[Stefan Majewsky]

On Sun, Mar 11, 2012 at 8:32 PM, Supreet Pal Singh <supreetpal at gmail.com> wrote:
> I would appreciate a quick reply either directing me to the email address of
> the mentor

We don't have one at the moment. I wrote the idea, but will not have
time to mentor it. Since most of the project is not kdegames-specific
(e.g. QML use is very widespread among Plasma devs), we hope for a
mentor from some other area of the KDE community to step up when we
have a good proposal.

> or preferably some directions on how to go about the project.

Okay, that's going to be a long text.

Since you already have experience with QML, I'd suggest you think
about which game you want to do. Although it is very exciting to
create a new game from scratch, we had quite some bad experiences with
new games being written by GSoC students. It will therefore increase
your chances if you propose to port an existing game to QML.

All current games, along with their current graphics stack, are listed
on [1]. Maintainers can be seen in the list at [2]. We would very much
appreciate if the game to be ported would be one which uses
KGameCanvas at the moment. This framework can be understood as a very
simple replacement for QGraphicsView, and is considered deprecated, so
we would like to eliminate uses of it.

It will help your proposal if you know your way around the game on
which you plan to work. Most of our games have open bug reports and
feature requests on bugs.kde.org. Look for some junior job and submit
a patch at svn.reviewboard.kde.org if you like.

Since you need to present a tentative timeline for your project, I'll
give some remarks on that as well: Although I'm not that familiar with
QML, I expect that porting a normal-sized game should not take you
more than half of the GSoC time when you're already experienced with
QML.

That's why we want more out of this project: After having finished the
QML port, you should be prepared to give some recommendations on how
to adjust our libraries for usage with QML. Stuff like: "The way this
and that class works does not fit into the QML workflow, for this and
that reason." And perhaps even: "I suggest this and that change to the
library to make it integrate well with QML."

What's the reasoning behind this? In the 4.9 iteration, we're breaking
binary and source compatibility in libkdegames to do some major
cleanup. [3] While we're doing this, we're also keeping an eye on QML
preparedness. We do not expect the result (i.e. what will be released
with 4.9) to be QML-friendly already, but it should allow us (and
you!) to build first QML-based code upon it. By the time of the 5.0
release, when we have another opportunity for ABI breakage, we want to
know which changes need to be made.

So it really is a long text, with a lot of bla-bla-bla and
yadda-yadda-yadda which you probably don't even need to know about,
but it's always nice to have such a text available for reference. If I
forgot anything which is of interest, please do not hesitate to write
back. Please direct your answers to the mailing list instead of my
personal address, my availability is currently limited during the
workweek.

Greetings
Stefan

[1] http://techbase.kde.org/Projects/Games/Porting
[2] http://techbase.kde.org/Projects/Games/Maintainers
[3] http://community.kde.org/Games/API_cleanup