From kde-games-devel Tue Apr 24 21:33:28 2012 From: Stefan Majewsky Date: Tue, 24 Apr 2012 21:33:28 +0000 To: kde-games-devel Subject: Re: [Kde-games-devel] What are the deliverables for KDE Games GSoC? Message-Id: X-MARC-Message: https://marc.info/?l=kde-games-devel&m=133530335304624 On Sun, Apr 22, 2012 at 5:14 AM, Ian Wadham wrote: > =A0- Re-implement an existing KDE Game using QML/Qt Quick: we are > =A0 =A0not looking for a completely new game nor a complete re-write of an > =A0 =A0existing KDE Game > =A0- The re-implementation should use as much as possible of existing C++ > =A0 =A0code in KDE Games and existing KDE Games libraries > > These last two points need a lot of clarification. =A0Stefan, 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. > =A0- from a complete re-write in QML, with classes we can add to our libr= ary; > =A0- through a complete re-write except for the "game engine", with class= es > =A0 =A0we can add to our library; > =A0- to what I have suggested above, maybe with mods to our KDE Games > =A0 =A0library 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.) _______________________________________________ kde-games-devel mailing list kde-games-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-games-devel