[Kde-games-devel] A new highscore manager - KScoreManager

[Matt Williams]

On Tuesday 29 April 2008 09:04:37 Dmitry Suzdalev wrote:
> On Tuesday 29 April 2008 05:37:18 Matt Williams wrote:
> > Comments? Complaints? Insults?
>
> Matt, it's really cool you've got to this! :)
>
> Once I collected some suggestions about possible rewrite of our highscore
> API in an effort of rewriting it, but I still hadn't the time and
> motivation to continue that work (unfortunately).
> So, can you please-please-please take a look at the page where I summarized
> all the input I received in that thread.
> It's located here:
>
> http://techbase.kde.org/Projects/Games/Ideas#Reworked_highscore_system

Thanks for that. I knew someone had done a good bit of reseach into this a 
while back but I couldn't find the email. Many of the points there are 
cosmetic and will be fixed easily but the others seem like good ideas too.

> If I would speak as a KAtomic maintainer, I would say that most important
> thing there is to add support for the second type of highscores (which we
> currently have in katomic, kolf, kshisen). KAtomic still lacks highscore
> dialog support because of that.

Could you possibly elaborate on this a bit? If I understand you correctly, you 
would essentially want to group the scores for each level with 
setScoreGroup() so that score for level 1 are only judged against other 
scores for level 1, but that is having the downside that you could end up 
with 30 tabs in the dialog making it very messy? How would you imagine scores 
collected for these games should be displayed in the UI?

> Also, I think that Albert would be very happy to see i18n thing sorted out.
> (I see you've already addressed it - cool!)
>
> Now i've some comments for your current patch if you don't mind :)
>
> - IMO, if you make class a singleton anyway, no need to make all functions
> static. Do them as usual, but make self() public. Then the class can be
> used as KScoreManager::self()->someFunction(). It's quite allright. it
> shows its singleton nature. Otherwise you're just emulating namespace...

Okay, fair enough. I was going for the syntactic sugar approach but I guess it 
could be misunderstood. If the user wants, they could always store a pointer 
to the singleton with:

KScoreManger* m_scoremanager;

m_scoremanager = KScoreManger::self();
m_scoremanager->someFunction();

Okay, I'll make that change.

> And also add const modifier to functions as needed.

Thanks for reminding me, yes.

> - Rename askName() to setAskName()
> - Rename lessIsMore() to setLessIsMore()

I was thinking about these and I kept on changing it. In my opinion 
askName(true) and setAskName(true) aren't all that different but I suppose 
that the latter doesn't suggest that's it's actually going to ask the player 
for their name _now_. Okay, I'll make the change.

> - Getters for the above two?

Like what I said to Parker about the other getters, I can't really see the 
need for getters. These are setting properties for the class which aren't 
going to be changed and also I don't see a need for the user of the class to 
know whether the name is going to be asked for. Either they've set tit to be 
asked or not.

> - Use KGLOBAL_STATIC for implementing singleton (when you'll come to *.cpp)

Sure thing.

> Thanks for your work on this!

No worries :)

Regards,
Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-games-devel/attachments/20080429/7feb82e5/attachment.pgp