[Kde-games-devel] What are the deliverables for KDE Games GSoC?

[Stefan Majewsky]

On Sun, Apr 22, 2012 at 5:14 AM, Ian Wadham <iandw.au at gmail.com> wrote:
>  - Re-implement an existing KDE Game using QML/Qt Quick: we are
>    not looking for a completely new game nor a complete re-write of an
>    existing KDE Game
>  - The re-implementation should use as much as possible of existing C++
>    code in KDE Games and existing KDE Games libraries
>
> These last two points need a lot of clarification.  Stefan, please help.

I think both points are essentially correct. I ^W We want true QML
ports which can be deployed in mobile environments where QtWIdgets is
not available (at least in the upcoming Qt 5 era). At the same time,
we want to maintain feature parity between the widget-based and
QMLized code bases.

This can realistically be achieved only by reusing the existing
UI-independent parts of the code (what one typically calls "business
logic", or "game logic" in this case) as much as possible.

Furthermore, I recommend that students and mentors in QML projects
keep two eyes on code base fragmentation: If the student essentially
forks the widget-based game and develops the QML-based game from this
point, we will end up with two practically unmergeable codebases. It
is best if the QML students adopt a mindset which is similar to that
of the porting projects, and consider their work a big patch for the
existing application, which is merged back into the original source
tree at the end of the summer.

Ideally, the resulting application code can be built both for the
desktop (with the traditional QtWidgets-based interface) and for
mobile (with the QML interface), just by toggling a switch in CMake.
This will make maintenance much easier.

>  - from a complete re-write in QML, with classes we can add to our library;
>  - through a complete re-write except for the "game engine", with classes
>    we can add to our library;
>  - to what I have suggested above, maybe with mods to our KDE Games
>    library classes to make them easier to use from QML.

Number 2 sounds good. It does not make sense to rewrite the game
logic, which is essentially the same regardless of the user interface
technology. The exception is that logic code might need some
adaptation in order to provide the interfaces which QML wants.

(Rule of thumb: QML can see anything which Qt's Meta Object system can
see: properties rather than getters and setters, QObject instances
rather than random C++ classes, and so on.)

The addition of new QML-based components in libkdegames is very much
desired, just like QtWidgets-based components are an important part of
the offering in the current libkdegames.

However, I want to explicitly encourage QML students to first strive
for an interface that works well for the specific game. When this goal
has been achieved, we have a solid basis from which we can determine
which parts of this interface can be generalized for use in other
games.

This policy is consistent with the current state of kdegames: Though
libkdegames offers shared UI components for common tasks, game
developers have always been very free to choose the interface which
suits the specific game best.

With the advent of QML, the development model, as well as the
interface design model, changes drastically. This means that we need
to reconsider which parts of the interface are provided by shared
components. For example, I would really like a shared component for
game boards with a fixed number of cells. I know from my experience
(KGameRenderedObjectItem as used in KDiamond, and Tagaro::Board as
used by static copy in Kolf) that doing this right with QGraphicsView
is very complicated. On the other hand, I arrived at a usable
prototype for such a component in only one hour using QML/Qt Quick.

In this case, QML makes generalization easier than QtWidgets (e.g.
QGV). It might also be the other way around: I expect to see more
fragmentation than before outside the game canvas, in the window
chrome, where the usual menubar-toolbar-statusbar triumvirate is
replaced by a bigger flexibility of approaches. Something like the
*bars might emerge again if it works well, but we need not force it
now.

As I said, the QML projects are explicitly about experimenting with
the new possibilities provided by QML and Qt Quick. The experiments
should lead to one stable game interface, and to the insight which
parts of this interface can be reused.

Greetings
Stefan

P.S. On the practical side of things, I recommend that the QML
students (and mentors) familiarize themselves with libkdeclarative and
Plasma's Qt Components implementation. These two components are the
basis for QML development within KDE. (But don't expect me to be able
to tell anything more specific about this topic right now; the very
same point is also on my todolist.)