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

[David Edmundson]

On Fri, Apr 27, 2012 at 4:37 PM, Trever Fischer
<tdfischer at fedoraproject.org> wrote:
> 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.
>
+1 to this, within reason. As soon as you start planning some of the
tasks will become obvious. Then it can be tweaked as you go along.

What I (personally) don't want to see in the QML port is interfaces
that look completely different to desktop apps, using QML to draw menu
bars and alike.

What's the plan for mentoring, student each or some sort of collective pool?

How should we all communicate, should we just use the main ML (I've
only just joined it, sorry). We should possibly have some sort of
online IRC meeting to get to know each other.

David Edmundson

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