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

[Richard Hartmann]

Rereading my own mail, it sounds a lot harsher than intended.
Actually, I intended 0 harshness :)

On Mon, Aug 18, 2008 at 00:15, Mauricio Piacentini <piacentini at kde.org> wrote:
> Richard Hartmann wrote:

> 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.

Ah, that is where it went. Does that mean it will be faster, from now
on? If yes: YAY!


> Don't assume there was no thinking involved, though.

I didn't. I meant that there was less thinking about to 'how does
this integrate into KDE at large' as opposed to 'how does this
integrate into this single game'. And I mean this in a positive
way. Getting the games to work on 4.x was the most important
thing (obviously). Now that this is achieved, polishing work can
be done.


> 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.

As per my bug report, the upper left notification will overlay
the first falling block. That is especially bad as the game starts
by itself so not only don't you know what block you are playing,
you might not even know _that_ you are playing.


> 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.

One will probably never fit all unless we are talking about very
basic things and even then a fullscreen KDE game might
some day break all the rules. Few should fit all, at some
point, though.


> 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.

Well, I have not worked in any KDE game myself, so yes, I _am_
lacking a substantial portion of knowledge about the process. From a
user's perspective, I have been following the games since the early
KDE 2 days, though.
I did not want to imply that all of this need to be done yesterday,
by the way. But I _do_ think that a bit of hard data can help to set
goals. When those goals are achieved, if ever, is another matter.
But to be aware what categories are there and into which $foo
falls is a Good Thing as it can (not must) show a direction into
which development can go.


> 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.

100% agreed on the second part. Yet, there is some common ground
for all the games. Menu arrangement should be one of them. The decission
if timed games start automagically could be another. In many other areas,
it is best to go as wild as possible, though :)


> What I mean is that I am against strict policies that restrict the
> developer and its creativity.

You will always have some rules that can not be broken. For
example, I doubt a GTK+ game would make it into KDE games.
I know what you mean, though. And I agree with it.


> 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.

Aye.


> 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.

Did anyone contact the usability guys and gals about this? I planned
to do so at some point, myself. But earlier might be better? Thoughts?


> 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.

Again, if you tried to write a second Plasma and ship that with KDE
base, it would most likely not work. Yet, I know what you mean &
agree.


> It is a
> developer-artist centric view, I admit, and makes other contributors
> like bug reporters feel like second-class citizens.

Only when you are told that knetwalk games need all pipes
connected instead of all computer screens lit up ;)


> But it does not have
> to be that way: most authors will gladly implement suggestions,

Indeed. That is why I go through the trouble of doing this work.
Believe me, it is quite time-consuming. But then, so is coding.


> 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.

That is always true. Especially if you are not in a position to give
an order to the coder. Barring a few special cases like DJB, Hans
Reiser, de Raadt etc, perhaps. But that is another topic :p


>Yes, contributing to open source projects seems to  also
> require diplomacy and political skills :)

Agreed.


Richard

PS: Rereading the current mail, I _do_ sound like a nit-picker ;)