I hadn't realized it, but internally, CombuPlatform.LoadScores() uses a 1-week time scope. Since none of the other APIs I see default to this, I think this should be set to AllTime instead for consistency. However, it did allow me to discover a problematic issue:
Since my leaderboard is set to only keep the player's highest score, if their top score is 100,000, but 1 month old, and then they play again today and get 999,999, their score won't show up on the leaderboard at all with a 1-week time scope. So even though they've played within the last week and gotten a very high score, it won't show up because they have a higher score that is outside the time scope. So there is basically no way for them to continue to participate in weekly scores unless they can top their own previous record.
It seems to me like the desired behavior would be, if their old record is outside of the time scope, then they get a new record with whatever their new score is for that week.
I realize this doesn't seem to fit the existing architecture of the database. However, I think the way most systems deal with this is by adding a "version" field to each score record. And this "version" number gets set at the time a record is recorded, and the value of the "version" is determined either by client-side code when the score is posted, or by server-side code that is controlled by some other means. But basically the way I would implement weekly leaderboards is to increment this "version" number every Sunday (or first day of the leaderboard week). Then every score record entered after that has the latest "version" number stored with it. Records with previous version numbers aren't included in a week-scope query. But if I wanted to do a month-long query, I could include the previous 4 version numbers in the query to get all the scores from the last month. Or no version-based filter if I want scores from all-time. And if a new score is posted that is less than a score by the same user with the same version number (meaning it was posted in the same week, or other time period), then the score isn't updated.
This also allows for when the game itself gets a major update that may change the possible scores (new rules, more or less bonuses, etc). So people on an older version of the game can still view and compete on leaderboards for that version, but not wind up competing with people playing on a newer version of the game that may make it possible to get very different scores.
Would adding versioning to the records be possible? I think it would greatly increase flexibility.
The interval is not a field of leaderboards nor it should be in their control since it's only a client-side filtering option.
The leaderboard score types "Increase the same score per user" and "Replace the best score per user" are not supposed to be used for time-scoped leaderboards, you should use those types only for AllTime scoped leaderboards. Well, unless you create a task on your server scheduled once per week that deletes the scores older than 7 days, this isn't something built-in but if your hosting provider gives you the possibility to schedule a call to a PHP script or if it's your own private/VPS server then I could help you to create such script.
For Week scope you can workaround by creating another leaderboard with "Replace the same score per user" and on client side you can post the score by summing the current match score to the existing score that you previously loaded with LoadScoresByUser passing eLeaderboardInterval.Week as interval. Please note that every time you call PostScore, it will update the date of the score to the current server date/time.
FRANCESCO CROCETTI @ SKARED CREATIONS
Thanks for the recommendations. I would also like to request the addition of "versioning" of score records, as is pretty common in some other leaderboard systems. It would make it much easier to handle the situation of when you make fundamental changes to how a game scores (maybe I make a particular item worth less than it was before for balancing purposes). Since not all players can be expected to upgrade to the new version at the same time (or ever), even clearing the leaderboards won't solve the problem since you'll still have users of the old version submitting new scores to them for possibly months after the update has been released, and those won't compare correctly to scores of players on the new version. And if players learn that by not updating the game they can get higher scores and stay at the top of the leaderboards above players on the new version, it may be a reason they never update.
One way would be to create entirely new leaderboards for the new version, but that has two problems:
1) It's a lot of error-prone work to create all-new leaderboards on the server and match those up to new code or data on the client side.
2) In cases like mine where leaderboards are for user-generated levels, I don't control the IDs of those boards, so there's not a way to create new ones.
Having a "version" value that can be a parameter of the score when posted would be much simpler and far less error prone.
Just a possible feature to consider for the future. Thanks for your time, and thank you again for the great system!
Well, I don't exactly like the idea of "versioning" because I personally find that it adds even more complexity to something that is already complex by its own (and completely changes the standard way that is currently used by hundreds of released products). May be I'll try to think at something about this, but I have really no idea at this moment about any ETA or even if it will be changed at any time (though you have the full source code of both server and client, so you're free to make any change or addition that you really need for your own product, probably the best way would be by creating your own add-on so that you can continue to get the standard updates [creating new fields in the core tables that will be used by your addons doesn't break the core system]).
And if players learn that by not updating the game they can get higher scores and stay at the top of the leaderboards above players on the new version, it may be a reason they never update.
This should be easily fixed by setting a specific version as MIN_CLIENT_VERSION in your config.php (click here for all the configuration constants), you should have CombuManager.instance.serverInfo.requireUpdate equals to true if the current client version if lesser than MIN_CLIENT_VERSION).
FRANCESCO CROCETTI @ SKARED CREATIONS
