Bug 172089

Summary: Faster time doesn't guarantee a higher score due to low resolution in score calculation
Product: [Applications] knetwalk Reporter: Parker Coates <coates>
Component: generalAssignee: Ashwin Rajeev <ashwin_rajeev>
Status: ASSIGNED ---    
Severity: normal CC: ashwin_rajeev, BugZilla, hatto, hhaak, kde-games-bugs, walch.martin
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Unspecified   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: Screenshot of high score dialog.
Screen shot showing the issue
Bug is not as rare as one might think

Description Parker Coates 2008-10-03 16:36:46 UTC 
Version:           3.0.0 (using Devel)
Installed from:    Compiled sources

I just ran into a situation where two games were given the same score, even though one had a faster time. Both games were perfect (zero move penalty), so one would assume a faster game would result in a higher score. See the attached screenshot, where this issue occurred three different times.

Obviously, this is an issue with the level of resolution in the score calculation. If the timer is accurate to a second, then a one second difference should result in at least one point difference in score.

There are a few ways this could be fixed legimately. My proposal is as follows, but others are certainly valid.

The current solutions currently favours errorless solutions over fast ones (which I think is good). As a result, anyone seriously trying to set high scores is going to be routinely playing perfect games. So why not adjust to score calculation to consider move penalty /then/ time instead of a weighting of the two. For example, "score = -10000 * movePenalty - timeInSeconds". If this was done, the "score" itself need not be user visible. The score dialog could simple show columns for "Move Penalty" and "Time" in that order, which would match the "sorting order".

The major downside is that this would make new and old style scores incompatible, but I believe this has to be fixed some time.
Comment 1 Parker Coates 2008-10-03 16:39:56 UTC 
Created attachment 27674 [details]
Screenshot of high score dialog.

Different games given the same score cause unpredicably score sorting.
Comment 2 Jon Rose 2008-11-06 15:28:18 UTC 
I think the scoring system is fine.  Your problem is that you aren't that great at the game.  My scores are all timed below 1:08 and every score with a better time has a better score of one or two. 

For any scoring system that the faster you are the higher the score, you are going to have some point where the score won't change when the time changes only a second or two.
Comment 3 Matthew Woehlke 2009-12-14 22:44:04 UTC 
> Your problem is that you aren't that great at the game.

Well, that seems rather rude.

Personally, I favor a solution that doesn't change the existing scoring. WCTS, I suspect Jon is otherwise right; there is a threshold at which time-based scoring won't show a point difference. What about simply adding time as a secondary sort key? (With appropriate logic for a quicker completion bumping an old score with a greater time but same point value, of course.)
Comment 4 Parker Coates 2009-12-15 01:10:10 UTC 
> Personally, I favor a solution that doesn't change the existing scoring.

Because the current system stores the move penalty and times, it would be possible to change the score calculation entirely without losing any data. An update script could simply use the old data and the new equation produce new scores. There might be a few corner cases (like those above) where the ordering of the scores changes, but I don't see that as a major problem.

> WCTS,

I have no idea what that acronym means. :) The best Google could give me is "What canst thou say".

> I suspect Jon is otherwise right; there is a threshold at which time-based scoring won't show a point difference.

See my proposal in the original report. Using such a system we can still easily distinguish between a game that was 3 hours and one that was 3 hours and 1 second.

> What about simply adding time as a secondary sort key? (With appropriate logic for a quicker completion bumping an old score with a greater time but same point value, of course.)

With KDEGames' current highscore system, there is only one sort key, and that is score. If a game requires more complex behaviour, the expectation is that they will calculate an internal score, which is used for sorting, but hide it from the interface so it appears the the sorting is being done by the properties actually shown in the dialog.
Comment 5 Parker Coates 2011-05-03 01:27:46 UTC 
*** Bug 272279 has been marked as a duplicate of this bug. ***
Comment 6 Harry 2011-06-13 00:40:00 UTC 
Hi,

I have a similar problem at the other end:
My high scores are now in a range of 4-5 seconds with zero penalty in every difficulty setting. This leaves not much space for improvement. Usually there are 1-3 "outstanding" high scores and the other ranks are within 1 or 2 seconds.

Suggested solution:
One to three additional digits for the time and the score (hope these aren't integers). The additional digits for the score would also solve the former stated problem.
Comment 7 Ashwin Rajeev 2013-03-17 13:11:52 UTC 
I have a less complicated solution.
Let the score be time taken to complete, that also means one with less score gets on top.
Each penalty move will add 10 to score
Comment 8 Christoph Feck 2013-08-11 12:44:17 UTC 
Created attachment 81637 [details]
Screen shot showing the issue

It can even happen that you cannot enter the high score list because of this bug.
Comment 9 Hatto Von Hatzfeld 2020-09-20 08:54:16 UTC 
Created attachment 131798 [details]
Bug is not as rare as one might think

In a user defined (customized) setting the bug may occur more often.
Comment 10 Hatto Von Hatzfeld 2020-09-20 08:57:05 UTC 
Comment on attachment 131798 [details]
Bug is not as rare as one might think

In a user defined (costumized) game setting the bug may occur more often. So it is desirable to fix it.