[Kde-games-devel] KGameDifficulty API notes and suggestions

[Dmitry Suzdalev]

On Tuesday 10 July 2007 23:54, Nicolas Roffet wrote:
> First of all: Thanks for your feedback!
You're welcome :)

> Yes, that's exactly the point. :)
> And also: I don't see yet a need to have to possibility to use the
> KGameDifficulty actions at a place not depending on the main window... Do
> you have ideas what game could need that and why?
Ah, I missed that you can change insertion place through mygameui.rc file. Ok 
then :)

> If there is a real need, we could add another constructor. But I would
> reluctantly remove the actual constuctor(s) because I think it's realy nice
> just to write (for instance) the following 2 lines of code to define the
> difficulty levels:
> 	m_difficulty = new KGameDifficulty(this, false, 4);
> 	connect(m_difficulty, SIGNAL(levelChanged(int)), this,
> SLOT(levelChanged(int)));
Well, how useful to see 4 for the reader of the code? I got your point, so 
perhaps we should replace that int by enum? Then it will be clearer. For 
example something like this:

enum DifficultyLevelsCount
{
     ThreeDifficultyLevels, // easy, normal, hard
     FourDifficultyLevels, /// etc
     FiveDifficultyLevels
// etc until how many we support
}

Yes, that's basicly the same, and perhaps naming isn't that great, but IMO it 
is much more clearer to read this:
new KGameDifficulty( this, false, KGameDifficulty::ThreeDifficultyLevels);

Moreover, this way will put clear restriction on how much predefined levels we 
support - so passing arbitrary int such as 99 won't work (without brute force 
of spell^W casts, of course).
And such code is pretty self documenting :)

I'd even go further (wrt qt lib guidelines), and replaced bool in constructor 
with simple enum too:
enum { RestartOnChange, NoRestartOnChange } // naming from head

Then
new KGameDifficulty( this,
                                  KGameDifficulty::NoRestartOnChange,
                                  KGameDifficulty::ThreeDifficultyLevels);

is even more understandable for code reader (while being more lengthy, yes)

> I thought about that also. Something like this
> 	m_difficulty = KStandardGameAction::difficulty(this, ..., ..., ...);
>
> And this would be in fact *much better* as this class should be a
> singleton, when I think about that... -> So I'll update the code with a
> real singleton pattern. :-) (I missed this by coding but now it's clear to
> me).
Perhaps you're right. But I see no problem with using "new KGD" as well :)

> But the nice think about it, is that the appellations are *standard* for
> all games using them. (And translators just need to translate them once).
> And often (80% of the cases?), you just need standard appellations
> like "Easy", "Medium", "Hard", ...
Yes, I agree here. But see above :)

> Yes, they are. Thanks a lot.
You're welcome. That's great we can cooperate in such a nice way to create 
something really useful by learning from eachother :)

> I personally prefer tabs. (There are the well-known pro and contra
> arguments...) That's why I used tabs in these new files. (In existent
> files, I try to follow the indentation rules...)
Well, I think it should be discussed in another thread.
We briefly chatted with Mauricio about this issue on irc and agreed that we 
should agree (heh) on at least:
- using tab vs spaces in kdegames
- level of indentation we should all use

This is for new code going into kdegames. Old code should be adopded while(if) 
editing.

It seems natural to pick these items from kdelibs coding guidelines.

But let's discuss that in another thread - i.e. if someone will have comments 
on this, please create new thead.

> But if you *really* want to remove them, I could survive...
Well, and I can survive with tabs if *you* really want them :-). So I guess we 
should just decide on some kdegames-wide policy.

> I would be happy, if you contribute to the code, so I don't want to bother
> you.
But keep an eye on my (possible) commits in case something might go wrong :).

Cheers,
Dmitry.