[Kde-games-devel] Yet another 'the games do not follow the same style' mail

[Mauricio Piacentini]

Richard Hartmann wrote:
> I suspect many people did not give too much thought on how other
> games do things. kblocks has notifications in the top left, kfourinline
> has them in the lower left. Most games overlay the middle, some use
> popup boxes. I doubt there was too much deliberate process involved,
> more a "i need to do x, y is a way to do x" semi-random process.
> Feedback from my bug reports is positive so I think most will
> welcome this effort.

Bugs.kde.org is moving right now, I see you have filed several bug 
reports, and I will get to mine when it comes back.
Don't assume there was no thinking involved, though. In the case of 
KBlocks, the best location for the types of notifications we use is top 
left, and we decided to let each game select the best location based on 
its characteristics. Some games can not use KGamePopupItem at all as 
they are not based in QGraphicsView, for example. One size will not fit 
all games here at this point in time, it might on the future.

> I would define the classes before, not afterwards. Don't file what is
> there. Think about what the categories are and go from there.

This shows imo a lack of understanding of how the process of developing 
these games worked so far during the past 10 years, and how it continues 
to work. Sure, we can gang and change/improve things as a team, as we 
have done in the past, but there is still lots of legacy and some 
hardly-maintained code. Suggesting changes is  good, but no one will 
magically fix it until we find a way to motivate developers to work on 
them.

>> For example, if we noticed that most of the timed games start a new
>> game like this, and quite a few of the untimed games start a new game
>> like that, then maybe we could classify games as either "timed" and
>> "untimed" and come up with a consistent game starting method for each
>> class.

I like consistency, and this was something we were discussing during the 
usability workshop at Akademy. But I also like to let people work 
motivated and experiment (specially in kdegames) with different ways to 
do things. This is how several of our new features started, such as the 
SVG-izification of all games, the discovery of KGameCanvas and the move 
to add themes via a theme selector. Someone starts to do something 
slightly different as it looks like it could be best for one game, and 
over time the successful experiments are carried away to other games, 
and moved to libkdegames eventually.

What I mean is that I am against strict policies that restrict the 
developer and its creativity. Some things are a matter of taste, for 
example the discussion about which card sets we should ship. People will 
just have to agree on the disagreement, and the best we can do is to 
ship several themes, a sane default, add KNS and make our apps highly 
configurable. This is something I think separates KDE from other 
projects that have more strict policies for some of these issues, I 
think. The idea of sane and minimal defaults and giving people the way 
to customize the games looks like a winner to me.


Take the issue of how to start a game. Sure, we can do better, but we 
need to research what and how. I mean actually do the research and 
tabulate stuff, not just talk about it. We had some experiments like the 
KWelcomeScreen initiative. Some take time to mature, however, and 
discussion and feedback is a good way to improve things. But at the end 
it is up to the game author to decide, right? "He who does the work 
decides" is the ultimate KDE development mantra. It is a 
developer-artist centric view, I admit, and makes other contributors 
like bug reporters feel like second-class citizens. But it does not have 
to be that way: most authors will gladly implement suggestions, 
specially the ones that are backed by some research and data, and are 
put on a "here is a suggestion on how to improve things" light. I feel 
that the "here is something that I think you did wrong and needs to 
change" speech a bit less effective when dealing with voluntary 
developers. Yes, contributing to open source projects seems to  also 
require diplomacy and political skills :)

Regards,
Mauricio Piacentini