[Kde-games-devel] which libkdegames Highscore class for kgoldrunner

Jeremy Wick jwickers at gmail.com
Wed Aug 8 04:30:04 CEST 2007


Well, i have no idea how the current system is supposed to make sense,
so i was reluctant to change it.
IMO the "score" should be the time taken to solve a board. And it
should be in different tables according to rule / size. Makes much
more sense i think.

> The main point is to give the user some way to
> measure his performance, and for this we can easily discard things like
> different sliding rules (in KShisen) imo.

Well, the rules do affect the time needed to complete the board, thus
the performance. Besides i think that in the user POV it would be
frustrating: first to have an arbitrary number, second to notice than
a given rule set gives higher with or without being "easier".

Personally i would like to tell my friends that my best time on an
average boards is X minutes. Especially because there is a real world
equivalent, and people playing it would find my 360 pts performance ..
puzzling.
Also if somebody does another implementation (for Gnome for example)
it would be easier to compare too.

To simplify things, ze could drop the "difficulty" setting because i
am not so sure that there is a clear way to say that a board is "easy"
or "hard".
All the game engine can say is that it is "solvable" or not, then
difficulty depends on a lot of things related to the rules the user
enabled and the size of the board.
So i would rather merge difficulty and board size (like in KMines)

Then we could group high scores per rule sets, then per board size.
Perhaps it would be better to have rule sets rather than checkbox
options. For example we could have Classical, Chinese,
Classical+Gravity ... but with better names. Maybe the original
maintainer could tell the names of the original rules, i only know the
"Chinese" one because .. it is the one i see in China :)
Then grouping scores would be easy and sensible for the user.


On 8/8/07, Mauricio Piacentini <mauricio at tabuleiro.com> wrote:
> Jeremy Wick wrote:
> > I will try to find the time to adapt kshisen as well although i am not
> > sure of the result.
> > Because there are many options that would need different high score
> > tables (size of board, set of rules) this means a lot of tables.
> >
> > The "tabbed" dialog would be quite ugly.
> >
> > Any people have such case ?
>
> I just had a thought, not sure if it applies to this particular case.
> Currently the KShisen highscore is calculated based on some complex
> rules (size of table I believe is one of them.) The end result is then
> translated to a numeric value. In this case, I think we could still have
> one and only tab, for the 10 greatest numeric values, and the size of
> board and other component that was used to calculate each score could
> still be displayed in this single table.
> In other words, it is not really necessary to have different tabs for
> each game option as a rule, imo. On some games like KMines this makes
> sense, as we are only recording time, and this is the sole component of
> the score. In others we could factor the board/rules complexity into the
> total score value, I think. Or some could be ignored (different rules
> for example), at least as far as computing highscores is concerned.
> Remember that the highscores can be easily hacked anyway, as they are
> simple preference files. The main point is to give the user some way to
> measure his performance, and for this we can easily discard things like
> different sliding rules (in KShisen) imo.
>
> Regards,
> Mauricio Piacentini
> _______________________________________________
> kde-games-devel mailing list
> kde-games-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-games-devel
>


-- 
WICKERSHEIMER
Jérémy


More information about the kde-games-devel mailing list