<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On 16/02/2012, at 9:46 AM, Stefan Majewsky wrote:</div><blockquote type="cite"><div>Right now we have two highscore systems in libkdegames:<br><br>* KHighscore/KScoreDialog manages a simple list of the top-ten scores<br>(per category, e.g. difficulty level). Used by most games.<br><br>* KExtHighscore, the vastly more powerful brother of KHighscore,<br>records statistics for each player, e.g. win/lose counts and longest<br>streaks. Used only by KReversi.<br></div></blockquote><div><br></div>Two or three years ago there was lengthy discussion of these two</div><div>systems and the consensus was that KExtHighscore is "over engineered"</div><div>and that KHighscore/KScoreDialog, with some enhancements, should be</div><div>preferred and become the standard.  AFAICR some, but not all, of those</div><div>enhancements were done.</div><div><br><blockquote type="cite"><div>* KGoldRunner implements functionality similar to KScoreDialog, but<br>seems to refrain from using KScoreDialog directly in order to support<br>legacy highscore data.<br></div></blockquote><div><br></div>Supporting previous high score data is not the only reason.</div><div><br></div><div>Certainly I think KHighscore/KScoreDialog *should* protect previous</div><div>high score data through a new release and installation of KDE.  It is</div><div>annoying for a game player to lose high-score data when he or she</div><div>upgrades KDE.</div><div><br></div><div>I now think converting old KGoldrunner highscore files to KHighscore</div><div>format is a dead issue, because KGr has been hacked around so</div><div>many times during the KDE 4 era that I, for one, have lost the high</div><div>score files I used to have and it takes hours and hours to re-establish</div><div>them.  Also it seems, KGoldrunner aficionados are more into the</div><div>challenges of playing and re-playing particular levels and level</div><div>sets than going for high scores.</div><div><br></div><div>BTW I do not think it is a good idea for all ten highscores for every</div><div>variant of every game (even the blank highscores) to be cluttering</div><div>up $KDEHOME/share/config/gamenamerc.</div><div><br></div><div>I have a few other stylistic concerns with KHighscore/KScoreDialog</div><div>(see attached screenshot).</div><div><br></div><div>  1. I think it should use a less bland-looking widget: at least as good</div><div>      as a QTreeWidget or some such in appearance.</div><div><br></div><div>  2. I find the display of blank highscores superfluous and ugly.</div><div><br></div><div>  3. The use of # in the rank is also superfluous and ugly IMHO.</div><div><br></div><div>  4. We should have a bolder, larger and more rewarding title</div><div>      and the option of a sub-title.</div><div><br></div><div>  5. The tabs at the side do not accomodate long level set names.</div><div><br></div><div>  6. When you use Show High Scores, the tabs at the side and the main</div><div>      list of scores do not reflect the game you are actually playing (I was</div><div>      playing Pillars layout in the attached screenshot, but the high scores</div><div>      for Clubs are displayed).</div><div><br></div><div> 7. Maybe the tabs should be abandoned and there should be some</div><div>     other way to get to scores for variants you are not actually playing,</div><div>     such as a "Show All High Scores" button in the dialog or a drop-down</div><div>     list or KCombobox.</div><div><br><blockquote type="cite"><div>Is this all? If so, I'll follow the traces of KScore2 for the<br>highscore part, and implement a more flexible successor for<br>KScoreDialog that can safely use legacy score data and support<br>grouping that is more complex than one level. I'll probably also<br>implement similar, but separately available functionality for game<br>statistics. (The only merge point is the interface, then.) Do you have<br>anything to add on these thoughts?<br></div></blockquote><br></div><div>See above.  KGoldrunner is actually ready for KHighscore/KScoreDialog</div><div>via a compile-time option.  I occasionally re-build with that option, in case</div><div>KHighscore/KScoreDialog has changed, but have been disappointed</div><div>so far.</div><div><br></div><div>It's great work you are doing, Stefan, addressing some of these long</div><div>standing issues in libkdegames.</div><div><br></div><div>All the best,</div><div>Ian W.</div><div><br></div><div><img height="403" width="366" apple-width="yes" apple-height="yes" id="a21a7af2-7326-4029-b201-3f18a1e1854e" src="cid:172001B1-767D-478D-899E-FFE2C32360C0@home"></div><br></body></html>