[Kde-games-devel] KDE HIG (was Re: KGameDifficulty)

[Mauricio Piacentini]

Nicolas Roffet wrote:

> (1): YES, the idea of KGameDifficulty was (and is) to provide an easy, 
> uniformed and standardized solution to manage the difficulty levels over all 
> KDE games. So I would NOT be very happy to make this solution too much 
> customisable so that the games don't look the same anymore...

Agreed, I see your point.

> (2): If for any reason, a game don't want to (or cannot) use this standard 
> solution, it's still possible to implement a special solution, for instance 
> with KStandardGameAction::chooseGameType(...), or without it. It's not much 
> work anyway. For some games with special needs, it's better to reimplement 
> everything. (For instance: KSpaceDuel need to define a difficulty level per 
> computer player and they can be more than one. It's a special case.)
> 
> (3): I'd like to see a standardized solution, but I'm opened about HOW it 
> should be. If we think it's not that good in the status bar, I'll be glad to 
> change this. And a change in the library would affect all the games (using 
> it) and they would still look the same to each other. :)

I think we now simply wait a bit for feedback. If there is none, we can 
decide ourselves what to do, and in this case probably keep it as it is 
right now.

> (4): I'd like the solution to be as easy as possible to use for the game 
> developper, so that he prefers to use it than to reimplement everything, 
> (what would not be a lot of work anyway, as I allready wrote in (2)!). So 
> it's important that the programmer don't have to do to much itself and that 
> the library does the maximum.

The change I mentioned in the API would cause the developer to add one 
additional line of code after the initialization. So in the case of 
KMines for example we already have the following code on mainwindow.cpp

KGameDifficulty::init(this, this, 
SLOT(levelChanged(KGameDifficulty::standardLevel)),
                          SLOT(customLevelChanged(int)));
     KGameDifficulty::setRestartOnChange(KGameDifficulty::restartOnChange);
KGameDifficulty::addStandardLevel(KGameDifficulty::easy);
KGameDifficulty::addStandardLevel(KGameDifficulty::medium);
KGameDifficulty::addStandardLevel(KGameDifficulty::hard);
KGameDifficulty::addCustomLevel(0, i18n("Custom"));

//And we would need to add
statusBar()->addPermanentWidget(KGameDifficulty::difficultySelector());

> (5): It's not a problem if the user hide the status bar or if the game don't 
> have any, because there is still the menu "Settings" to select the 
> difficulty.

Agreed, it is actually better this way. Maybe KMainWindow is being 
"smart" already.

> (6): If we can and need in the future to put a game difficulty selector widget 
> over a QGraphicsView or anything else (it could be a good idea), I'll be glad 
> to extend the API for this.

That is one of the reasons I proposed the change to the current 
automatic behavior of placing it in the statusBar, so the author could 
simply do

myQGVView->addWidgetItem(KGameDifficulty::difficultySelector());

in the near future, and no additional modifications to the libkdegames 
api would be needed (and no BC problems as well, do not know if it 
matters.) And at that point some applications could continue to use the 
statusBar() convention, if displaying on-canvas is not convenient or 
possible to them.

> (7): YES, I think it's a good idea to involve the usability team of KDE to 
> help us to here. Furthermore, I'd like to have standards & guidelines as I 
> already said during the last IRC meeting. We could start at the beginning 
> with KDE Games guidelines. But I understood that the problem was to agree 
> with each other...

This will always be a problem, but I guess we are handling it fine 
recently. In case of conflicts I think we should use what works for the 
KDE project as a whole, and if everything else fails we can resort to 
the "who does the work decides" motto :)

I think this is just the tip of something that can be very good for us, 
an effort to standardize common concepts in a way that is harmonic to 
the rest of the KDE project and makes our games very consistent. It will 
also save a lot of time in the future, as less code needs to be written, 
and less thinking about interface elements needs to be done. Having 
KGameTheme, KScoreDialog, KGameDifficulty and KGamePopupItem are very 
good steps in this direction, I think. There are some other stuff that 
we could also consider, such as:

a) Standard way to display the score (points)
b) Standard way to display time
c) Standard way to display remaining pieces
d) Standard way to display completed/remaining moves

Right now, each game displays this standard information in a slightly 
different way in the status bar. We could also make it standard, so (for 
example) we would always display the points first, then the time, etc. 
We could also document the usage of separators and other elements, so 
that the games really look very similar even in these small details, at 
least as far as the standard interface elements are concerned. Of 
course, in game displays are another topic, where artists have almost 
complete freedom to do whatever we want.
So I agree with you, there are the things we could have as game specific 
guidelines, as other modules would probably not be interested in them. 
The question is if it will be possible to do this in time for 4.0...

> (8): The idea to put the selector in the status bar was that it is already 
> like this in the game "bovo", and during the aKademy, Johann and I found that 
> this it was a nice idea. It's an information (current difficulty) and it's 
> editable so you can also directly and easily change it. 
> => Personly, I like this better like this than in the toolbar. It's my 
> opinion, but I ready to discuss about it. There may be better solutions. I'd 
> like the best (well at least a good) solution for KDE games!

We all do! Let us now wait for more opinions and then we can choose one 
way and stick with it for the whole 4.x series.

> (9): For information: these are the games of the game module that use or could 
> (or should?) use KGameDifficulty in the future:
>  - Bovo
>  - KBlackBox
>  - KGoldrunner
>  - KJumpingCube
>  - KMines
>  - KNetWalk
>  - KReversi
>  - KShisen (Shisen-Sho)
>  - KSquares
>  - KSudoku
>  - KWin4
> And there are also many games from playground that use or could use it. 
> That's a lot (almost 50% of the games) and it would be nice IMO if all these 
> games would behave the same, (like for instance the way we manage high 
> scores: all games behave the same). That's the goal I had (and still have).

Add KBlocks to the list as well as a candidate for using it, as soon as 
the game is ready.

> What do you think about it? As I said, I'm opened to make improvements to 
> reach this goal.

I understand your rationale completely. To me personally I just did not
agree immediately with using the statusBar for it, without some review
from usability team. But again it is not a big deal, and maybe even a 
matter of taste. If the usability people do not think it is a problem, 
then I would support leaving it there, and we can move on. I just 
thought we should discuss it with the experts in order to make informed 
choices that match the overall goal of the desktop environment.

Regards,
Mauricio Piacentini