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

[Trever Fischer]

On Sun, 2012-04-22 at 13:14 +1000, Ian Wadham wrote:
> Hi guys, especially Stefan,
> 
> On Monday at 19:00 UTC the results of student applications for Google
> Summer of Code (GSoC) will be announced on the GSoC 2012 website.
> Then there begins a four-week "Community Bonding Period" in which
> "students get to know mentors, read documentation, get up to speed to
> begin working on their projects".
> 
> KDE Games students will need to become completely clear, in the next
> week or two, on what work they are to deliver --- and where and how.
> 
> Also we ourselves are in the process of moving to GIT and re-writing
> the libraries the students will be expected to use.
> 
> And there are various deadlines coming up in the KDE 4.9 release
> cycle during the GSoC period --- 24 April to 24 August.
> 
> Beta 1 tagging is on 24 May, before the students officially start
> development work (according to Google's schedule).  And there are
> soft and hard API freezes on 17 May and 25 June.
> 
> Personally, I think it would be unfair to expose students to all the
> hurly burly of changing libraries, moving to GIT and observing KDE
> release deadlines, though a little of it might be valuable work experience ;-)
> 
> There are two classes of GSoC project proposed for KDE Games:
> porting games to newer graphics libraries and implementing games
> in QML/Qt Quick.  For brevity I shall call these "porting" and "QML"
> projects.
> 
> Porting projects.  There are to be at least six games ported.  My ideas
> on delivery methods and deliverables are:
> 
>   - Work off SVN repository for now and for as long as possible (e.g.
>     even after the move to GIT unless the student prefers to work in GIT)
>   - Deliver changes by review board
>   - Review by KDE Games team ideally, or at least Stefan and me (as mentor)
>   - Commit by mentor OR only when the mentor says (depends on stage
>     of KDE release cycle: it would be nice if some ports could get into 4.9)
>   - Porting must be fully to KGameRenderer (KgRenderer?) and KgTheme
>     as appropriate, not just to QGraphicsView
>   - Set KGameRenderer strategy UseDiskCache=true, unless the graphics
>     files are very small
>   - Set KGameRenderer strategy UseRenderingThreads=false (I am worried
>     about students getting bogged down if anything goes wrong in threads)
> 
> QML projects.  There will be one game per project.  My ideas on delivery
> methods and deliverables are:
> 
>   - Work in playground/games repository (should this be in SVN or GIT?)
Probably Git. It'd be easier than worrying about converting it from SVN.

>   - Student has own KDE account for commits, subject to the usual approval
>   - Announce via review board when there is something committed for review
>   - Review by KDE Games team ideally, or at least Stefan and QML mentor
>     (the proposed QML mentors are from outside KDE Games)
>   - 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.
> 
> We need a mix of QML and C++, but which parts of the code should
> typically be implemented in QML and which in C++?  Ideas tossed
> around in the proposal evaluation stage seemed to range:
> 
>   - 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.

When I added QML support to libzeitgeist, I basically just wrapped
everything in a QObject, unless it was already a QObject, QGraphicsItem
or a QAbstractItemModel.

> 
> The above is my best guess at what is required for QML projects, but I do
> not know QML.  Ideas and precise requirements statements are welcome.

My approach to writing a QML app is to start with some raw QML and then
add C++ stuff as needed. This keeps the QML and C++ apis as close to
each other as possible with minimal overhead.

> 
> All the best, Ian W.
> KDE Games GSoC mentor for "porting" projects.
> 
> 
> 
> 
>