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::restart
OnChange);
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::difficul
tySelector());
> (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::difficultySelec
tor());
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
_______________________________________________
kde-games-devel mailing list
kde-games-devel kde.org
https://mail.kde.org/mailman/listinfo/kde-games-devel
|