[Kde-games-devel] KDE Games Report from Akademy 2008
Matt Williams
matt at milliams.com
Sat Aug 16 19:48:49 CEST 2008
Greetings all
As you should all be aware, last week was Akademy and this year it was
fantastic to see so many KDE Games guys there, expecially those who hadn't
been to Akademy before. On Tuesday we had a BoF (birds of a feather) meeting
which ended up lasting almost 3 hours where we discussed a lot of the issues
affecting KDE Games. This meeting effectively replaced our monthly meeting
for August and since obviously not everyone was present I wanted to make sure
everything we discussed was made public to all you guys.
On Wednesday we had a status report BoF from Josef but I'll let him update
people on that if he wants.
What follows is a rough summary of the issues we talked about, both in and out
of the BoF. There is a record of this on Techbase at [1]. I will edit this
page myself to link to any relevant action items.
== Packaging Recommendations ==
Prior to the BoF a few people had been talking to the distro packagers about
the way they go about packaging KDE and KDE Games. It seems it s becoming
more common to package each game into a different RPM/deb/whatever and then
to provide meta-packages which will include a number of these. There is also
the issue that for a default desktop installation a distro will choose only a
small number of games (4, say). We, as a project, want to make the packager's
job as easy as possible and so we came up with the idea of categorising our
games into a number of 'packages'. These packages are logical groupings of
games so that without having to review all the games themselves, the
packagers can easily know which games are well suited to a default
installation, which would be appropriate as desktop games etc. And so the
categories we came up with were as follows:
Minimal
This group will contain only the very minimal games that any user would
expect to have on their desktop. This means, e.g., KMines, KPat, KMahjongg
etc. This should probaby not contain more than about 5 games.
Extended
This group will be all the high quality games which we would expect to
have a large user base. e.g. games like KSudoku, KBattleShip, KBreakout
etc. Those games which are quite specific to a certain user base or which
would not qualify as casual desktop games would not be included in this
category
Extra
These would be the games in extra gear which we consider to be useful
additions to the distro.
Friends
This would simply be a mention of those 'games' outside kdegames which we
consider to be games. This would be things like StepGame, Blinken etc.
These categorisations would not be reflected in the structure in SVN, they
would merely be recommendation to the packagers.
The groups would be compiled in a list in a file called README.PACKAGERS in
kdegames root. This list has not yet been created and we will likely need a
bit of discussion to decide which games should go where.
Action needed:
* Create the list and decide which games should be in which category (all
KDE Games members)
* Create the README.PACKAGERS file
== Bugs Mailing List ==
It was suggested that in order for all KDE Games members to keep track of the
areas of KDE Games that need help (outside of their own game) that we should
create a mailing list to which all new bugs (and perhaps bug edits) should be
CC'd.
The mailing list will likely be called something like kde-games-bugs at kde.org.
Once it is set up, I will let everyone know.
Action needed:
* Request the new mailinglist and ensure all bugs are CC'd to it. (Matt
Williams)
== Bug Fixing/Triaging Days ==
We thought about organising a KDE Games bug fixing and triaging day like what
the Bug Squad do each week. It would make sense to contact them to see if
they could help out with this. It would involve going through all the bugs in
the bug tracker and removing those which refer to old games, closing those
which are fixed, requesting more information on those that are not and fixing
those which we can.
Should wait at least until the new mailing list is set up.
== New Developer Mentoring ==
Dealing with new developers was discussed and we decided that given KDE Games'
excellent position as one of the main modules that people can most easily get
involved with we should do more to make it easier for people to get into the
KDE spirit/community. We're going to try to organise ourselves a bit more to
create a specified point of contact or two who will be there to guide new
developers through the process of creating and submitting patches, finding
bugs for them to fix in order to introduce them to the KDE Games code base
and getting involved in our community.
For this I will create a page on Techbase where we can collate who the
contacts are as well as useful resources for new developers.
Action needed:
* Create Techbase page and find people willing to be official mentors (Matt
Williams)
== New Game Criteria Checklist ==
This concerns the rules for allowing new games to enter the kdegames module
and for allowing a game to pass into a release. The current process of going
through kdereview works well and the requirements for that (documentation,
i18n etc.) all still apply to games but we would like to introduce a number
of further criteria for new games to ensure they of a high enough quality. We
want to make these criteria explicit so that developers creating a new game
can check against the list so that they know what is expected of them. This
list will consist of things like theming, using libkdegames classes where
appropriate, GHNS etc.
The list will be available on Techbase.
Action needed:
* Create list of criteria (all KDE Games members)
* Create page (Matt Williams)
== Rules for Unmaintained Games ==
As a release approaches we will need to make sure all games in the module are
tested to ensure they meet the release-ready criteria which coincides with
the new game criteria above. We will need to make sure that all games are
actively maintained and have no large unfixed bugs.
We will be taking a stronger approach to games which have unfixed bugs with no
maintainer. In this case we will move the game back to playground.
In the case that there is a maintainer but they are too busy to fix the bugs
or add essential new features, the game will be moved to extragear where they
are not bound by the kdegames release schedule so they can work on fixing the
bugs and adding the features in their own time.
However, given all this, we'd like to see KDE Games as a community taking a
certain amount of responsibility for the games in our module. That means
making an effort to fix bug in games that are not yours, especially if that
game is in danger of being removed. The new bugs mailing list will help us
with this.
Action needed:
* Full testing of all games before a release (all KDE Games members)
* Take care of all games, not just your own (all KDE Games members)
* Be strict when it comes to buggy/unmaintained games (Matt Williams)
* Organise people to be testers to make sure we have full coverage (all KDE
Games members)
== Usability ==
It was discussed that the biggest usability problem that we face is a lack of
consistency betwen games. This is in both the visual UI and the workflow of
playing a game. A certain amount of this can be standardised be putting stuff
in libkdegames and encouraging games to use it (see game criteria checklist
above).
Once we have polished the games as much as we can (or maybe before), we plan
on working with the wonderful usability people to help us make our games
better.
Action needed:
* Create a Project User Research Template for KDE Games as a whole as well
as for a number of individual games. See [2] for more info (all KDE Games
members)
* Decide on standards for certain things. e.g. how to start a new game (all
KDE Games members)
== Accessibility ==
We need to think about making our games more accessible. For the most part
this means considering making your games playable entirely through the
keyboard. It was decided that we would not make this a project priority since
we have other things to work on and we have very little knowledge about what
is really needed to make a game accessible.
Action needed:
* None for now unless someone is an accessibility expert
== KDE Games Developer Meeting ==
A few of us talked about having a developer meeting sometime in the next year.
This is a meeting where we all go somewhere to meet in person for a few days
and discuss and hack on KDE Games. This idea is still in a very early stage
but it is worth discussing possible locations and times.
The thought has just occurred to me that it might even be worth synchronising
this with a kdeedu meeting since our two projects have a lot to offer each
other.
Action needed:
* Discuss (all KDE Games members)
== kdegameslibs Module ==
Vladimir and Aliona presented Step and StepGame and the problem of the more
game-like applications in kdeedu not wanting to depend on kdegames as a
whole. It was decided that the best solution was to create a new module (on
the same level as kdelibs, kdegames, kdepimlibs etc.) called kdegameslibs
which would contain any common libraries needed by kdegames and kdeedu. This
would not involve moving all of the current internal libkdegames into the new
module, only the stable (ABI, API), maintained and essential parts would be
moved.
It has not yet been decided exactly what would be moved across but it would
likely include the theming stuff, my (currently non-existent) new highscore
stuff, popup item and similar. I would be the module maintainer and release
manager.
Action needed:
* Talk to release-team about creating the new module (Matt Williams)
* Decide on the part that should be moved in (all KDE Games members,
particularly those who are maintaining a part of the current libkdegames)
If you got this far through this email I applaud you for your commitment! Any
comments are welcome, particularly from those not able to attend Akademy.
Regards,
Matt Williams
[1] http://techbase.kde.org/Projects/Games/Akademy_2008_Notes
[2] http://techbase.kde.org/Projects/Usability/Project_User_Research_Template
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-games-devel/attachments/20080816/88548afb/attachment.pgp
More information about the kde-games-devel
mailing list