KScoreManager design

I'm taking this to a separate thread, because what I'm going to say does not
really relate to the current KScoreDialog implementation.

Am Freitag 02 Oktober 2009 12:12:49 schrieb Dmitry Suzdalev:

> Guys in the blog comments say that this can be useful for Level packs
>  support. As I'm currently adding a level packs support to KAtomic, I could
>  potentially use this too (though KAtomic doesn't use a KScoreDialog atm).
>
> But in this case the API added by Felix needs to be generalized to some
>  more common concept.
>
> And this would require a very different implementation.
> Because LevelPacks consist of separate levels. So highscores are for each
> level in pack. So layout of widgets in score dialog will differ and
>  unerlying implementation must differ.
> KGoldRunner and KAtomic are examples of games with such highscore
>  structure. Both of them don't use KScoreDialog because currently it
>  doesn't fit their model.

I've taken a look at the KScoreManager stuff for the first time. (I have
followed the discussion about it at that time, but did not take part in it
because I was relatively new to KDE programming.)

First of all, it seems like much code has been copied and adapted from
KHighScore/KScoreDialog. There's nothing bad about that a priori, because this
code has proven its stability in plenty releases. But moving to a new API
gives the chance of cleaning up old stuff. In this particular case, much of
the code (also on the presentation layer) is tossing around QMap and QList
objects. I'd rather use a model/view approach here, which can reflect both the
score tables and the groups at once.

Something like a KScoreModel might also open the door to an arbitrary grouping
order (grouping by difficulty, by level, by level pack, etc.). See the
attached mockup of a KScoreModel with level packs and levels. The green part
of the model has a tree structure, while the blue part (which is found below
every leaf of the tree) has a table structure. The blue part directly
corresponds to what KScoreTable displays, while the green part might require
different interfaces. Everything of this should be doable with the generic
approach that the KScoreManager draft is taking on the UI side.

RFC.

Greetings
Stefan



_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

[Dmitry Suzdalev-2]

> First of all, it seems like much code has been copied and adapted from
> KHighScore/KScoreDialog. There's nothing bad about that a priori, because
>  this code has proven its stability in plenty releases. But moving to a new
>  API gives the chance of cleaning up old stuff. In this particular case,
>  much of the code (also on the presentation layer) is tossing around QMap
>  and QList objects. I'd rather use a model/view approach here, which can
>  reflect both the score tables and the groups at once.
This is a really nice initiative, I'm all for it! :)

> Something like a KScoreModel might also open the door to an arbitrary
>  grouping order (grouping by difficulty, by level, by level pack, etc.).
>  See the attached mockup of a KScoreModel with level packs and levels. The
>  green part of the model has a tree structure, while the blue part (which
>  is found below every leaf of the tree) has a table structure. The blue
>  part directly corresponds to what KScoreTable displays, while the green
>  part might require different interfaces. Everything of this should be
>  doable with the generic approach that the KScoreManager draft is taking on
>  the UI side.
With this model you attached I can see how it can be used in both types of the
games' highscores:

For the games like katomic, kgoldrunner, kshisen, kolf (kolf2?) which use
levelpacks, layout that you've attached is used.

For the games like kmines, kblocks, klines, kreversi, and many others which
use a system in which word "level" doesn't mean a separate realm in which user
plays, but means "level of difficulty" I can see the model you proposed in the
following way:

It would consist of a dummy level pack which consists of several levels which
in this case represent a difficulty levels "Easy, Medium, Hard" for instance.

I beleive that the api then should contain some method which would allow to
put the model/ui in either mode and contain some additional convenient api
which would allow a class user to know nothing about this dummy pack if he
wants to use highscores in a second mode.

And games should call this api method while initializing their highscore
system (i beleive the second method should be used by default - majority of
games in kdegames use this highscores type).

Well, these are some thougts :)

Btw, If we discuss this a bit more to the point when it starts to be
implemented, KAtomic could be the testing app for level packs feature as I'm
in a process of adding a levelpacks support to this game :)
(http://websvn.kde.org/branches/work/katomic-levelsets)

Dmitry.

PS. Sorry for my maybe cryptic English :)
_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

Am Freitag 02 Oktober 2009 15:16:28 schrieb Stefan Majewsky:
> Something like a KScoreModel might also open the door to an arbitrary
>  grouping order (grouping by difficulty, by level, by level pack, etc.).

I forgot something here: It will of course be obligatory to provide some
standard sortings (for example, KGameDifficulty could gain some method to
automatically setup its groups).

Greetings
Stefan


_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

[Parker Coates]

On Fri, Oct 2, 2009 at 09:16, Stefan Majewsky wrote:

> I'm taking this to a separate thread, because what I'm going to say does not
> really relate to the current KScoreDialog implementation.
>
> Am Freitag 02 Oktober 2009 12:12:49 schrieb Dmitry Suzdalev:
>> Guys in the blog comments say that this can be useful for Level packs
>>  support. As I'm currently adding a level packs support to KAtomic, I could
>>  potentially use this too (though KAtomic doesn't use a KScoreDialog atm).
>>
>> But in this case the API added by Felix needs to be generalized to some
>>  more common concept.
>>
>> And this would require a very different implementation.
>> Because LevelPacks consist of separate levels. So highscores are for each
>> level in pack. So layout of widgets in score dialog will differ and
>>  unerlying implementation must differ.
>> KGoldRunner and KAtomic are examples of games with such highscore
>>  structure. Both of them don't use KScoreDialog because currently it
>>  doesn't fit their model.
>
> I've taken a look at the KScoreManager stuff for the first time. (I have
> followed the discussion about it at that time, but did not take part in it
> because I was relatively new to KDE programming.)
>
> First of all, it seems like much code has been copied and adapted from
> KHighScore/KScoreDialog. There's nothing bad about that a priori, because this
> code has proven its stability in plenty releases. But moving to a new API
> gives the chance of cleaning up old stuff. In this particular case, much of
> the code (also on the presentation layer) is tossing around QMap and QList
> objects. I'd rather use a model/view approach here, which can reflect both the
> score tables and the groups at once.

That was one of the main reasons I lost motivation to work on it. It
quickly became obvious that this was one of those things that should
be implemented as a model/view. Or rather, I noticed that I was
hacking together my own awkward model/view system. Unfortunately I
didn't know Qt's ModelView framework (and still don't), so work
ceased. This definitely seems like the right way to go to me.

There's no need to be polite, so don't hesitate to shit on my design.
Class design isn't something I have a lot of experience in, so I
generally end up starting with a naive hack, get it somewhat working,
see the limitations, tear it apart, and repeat.

> Something like a KScoreModel might also open the door to an arbitrary grouping
> order (grouping by difficulty, by level, by level pack, etc.). See the
> attached mockup of a KScoreModel with level packs and levels. The green part
> of the model has a tree structure, while the blue part (which is found below
> every leaf of the tree) has a table structure. The blue part directly
> corresponds to what KScoreTable displays, while the green part might require
> different interfaces. Everything of this should be doable with the generic
> approach that the KScoreManager draft is taking on the UI side.

You model doesn't include difficulty. Do you think it should be the
topmost level or the bottommost. I'm thinking probably the latter.

It looks like you're all set. I remember reading that you had a
surplus of free time and a shortage of interesting projects, so I'm
sure you'll have no trouble getting this ready before the feature
freeze. ;)

Parker
_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

Am Freitag 02 Oktober 2009 15:56:40 schrieb Parker Coates:
> There's no need to be polite, so don't hesitate to shit on my design.
> Class design isn't something I have a lot of experience in, so I
> generally end up starting with a naive hack, get it somewhat working,
> see the limitations, tear it apart, and repeat.

Me too! :-)

> You model doesn't include difficulty. Do you think it should be the
> topmost level or the bottommost. I'm thinking probably the latter.

My model is only an example. The "level packs" and "levels" can be any
arbitrary structure. (Having said that, I'd put the levels above the
difficulty levels.)

> It looks like you're all set. I remember reading that you had a
> surplus of free time and a shortage of interesting projects, so I'm
> sure you'll have no trouble getting this ready before the feature
> freeze. ;)

Arghh.........

Greetings
Stefan


_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

[Dmitry Suzdalev-2]

On Friday 02 October 2009 17:52:52 Dmitry Suzdalev wrote:

> > First of all, it seems like much code has been copied and adapted from
> > KHighScore/KScoreDialog. There's nothing bad about that a priori, because
> >  this code has proven its stability in plenty releases. But moving to a
> > new API gives the chance of cleaning up old stuff. In this particular
> > case, much of the code (also on the presentation layer) is tossing around
> > QMap and QList objects. I'd rather use a model/view approach here, which
> > can reflect both the score tables and the groups at once.
>
> This is a really nice initiative, I'm all for it! :)
>
> > Something like a KScoreModel might also open the door to an arbitrary
> >  grouping order (grouping by difficulty, by level, by level pack, etc.).
> >  See the attached mockup of a KScoreModel with level packs and levels.
> > The green part of the model has a tree structure, while the blue part
> > (which is found below every leaf of the tree) has a table structure. The
> > blue part directly corresponds to what KScoreTable displays, while the
> > green part might require different interfaces. Everything of this should
> > be doable with the generic approach that the KScoreManager draft is
> > taking on the UI side.
>
> With this model you attached I can see how it can be used in both types of
>  the games' highscores:
>
> For the games like katomic, kgoldrunner, kshisen, kolf (kolf2?) which use
> levelpacks, layout that you've attached is used.
>
> For the games like kmines, kblocks, klines, kreversi, and many others which
> use a system in which word "level" doesn't mean a separate realm in which
>  user plays, but means "level of difficulty" I can see the model you
>  proposed in the following way:
>
> It would consist of a dummy level pack which consists of several levels
>  which in this case represent a difficulty levels "Easy, Medium, Hard" for
>  instance.
>
> I beleive that the api then should contain some method which would allow to
> put the model/ui in either mode and contain some additional convenient api
> which would allow a class user to know nothing about this dummy pack if he
> wants to use highscores in a second mode.
>
> And games should call this api method while initializing their highscore
> system (i beleive the second method should be used by default - majority of
> games in kdegames use this highscores type).
>
> Well, these are some thougts :)
>
> Btw, If we discuss this a bit more to the point when it starts to be
> implemented, KAtomic could be the testing app for level packs feature as
>  I'm in a process of adding a levelpacks support to this game :)
> (http://websvn.kde.org/branches/work/katomic-levelsets)
>
> Dmitry.
>
> PS. Sorry for my maybe cryptic English :)
>

_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

[Dmitry Suzdalev-2]

Arggh, sorry i've added an extra level  of quote marks :(

On Friday 02 October 2009 18:07:17 Dmitry Suzdalev wrote:
> First of all, it seems like much code has been copied and adapted from
> KHighScore/KScoreDialog. There's nothing bad about that a priori, because
>  this code has proven its stability in plenty releases. But moving to a new
>  API gives the chance of cleaning up old stuff. In this particular case,
>  much of the code (also on the presentation layer) is tossing around QMap
>  and QList objects. I'd rather use a model/view approach here, which can
>  reflect both the score tables and the groups at once.
This is a really nice initiative, I'm all for it! :)

> Something like a KScoreModel might also open the door to an arbitrary
>  grouping order (grouping by difficulty, by level, by level pack, etc.).
>  See the attached mockup of a KScoreModel with level packs and levels. The
>  green part of the model has a tree structure, while the blue part (which
>  is found below every leaf of the tree) has a table structure. The blue
>  part directly corresponds to what KScoreTable displays, while the green
>  part might require different interfaces. Everything of this should be
>  doable with the generic approach that the KScoreManager draft is taking on
>  the UI side.
With this model you attached I can see how it can be used in both types of the
games' highscores:

For the games like katomic, kgoldrunner, kshisen, kolf (kolf2?) which use
levelpacks, layout that you've attached is used.

For the games like kmines, kblocks, klines, kreversi, and many others which
use a system in which word "level" doesn't mean a separate realm in which user
plays, but means "level of difficulty" I can see the model you proposed in the
following way:

It would consist of a dummy level pack which consists of several levels which
in this case represent a difficulty levels "Easy, Medium, Hard" for instance.

I beleive that the api then should contain some method which would allow to
put the model/ui in either mode and contain some additional convenient api
which would allow a class user to know nothing about this dummy pack if he
wants to use highscores in a second mode.

And games should call this api method while initializing their highscore
system (i beleive the second method should be used by default - majority of
games in kdegames use this highscores type).

Well, these are some thougts :)

Btw, If we discuss this a bit more to the point when it starts to be
implemented, KAtomic could be the testing app for level packs feature as I'm
in a process of adding a levelpacks support to this game :)
(http://websvn.kde.org/branches/work/katomic-levelsets)

Dmitry.

PS. Sorry for my maybe cryptic English :)
_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

[Parker Coates]

On Fri, Oct 2, 2009 at 09:52, Dmitry Suzdalev wrote:

> Something like a KScoreModel might also open the door to an arbitrary
>>  grouping order (grouping by difficulty, by level, by level pack, etc.).
>>  See the attached mockup of a KScoreModel with level packs and levels. The
>>  green part of the model has a tree structure, while the blue part (which
>>  is found below every leaf of the tree) has a table structure. The blue
>>  part directly corresponds to what KScoreTable displays, while the green
>>  part might require different interfaces. Everything of this should be
>>  doable with the generic approach that the KScoreManager draft is taking on
>>  the UI side.
> With this model you attached I can see how it can be used in both types of the
> games' highscores:
>
> For the games like katomic, kgoldrunner, kshisen, kolf (kolf2?) which use
> levelpacks, layout that you've attached is used.
>
> For the games like kmines, kblocks, klines, kreversi, and many others which
> use a system in which word "level" doesn't mean a separate realm in which user
> plays, but means "level of difficulty" I can see the model you proposed in the
> following way:

You forgot Killbots. :'( Killbots is a bit awkward as it has multiple
game types (a.k.a. rulesets), but no difficulties or levels. In the
current KScoreDialog implementation, I simply make game types
equivalent to difficulty levels, but semantically they're probably
closer to level packs. But of course I wouldn't want the dialog
showing a bunch of level packs with only one level in each of them.
I'd forgotten how tricky this problem really is. :)

>
> It would consist of a dummy level pack which consists of several levels which
> in this case represent a difficulty levels "Easy, Medium, Hard" for instance.
>
> I beleive that the api then should contain some method which would allow to
> put the model/ui in either mode and contain some additional convenient api
> which would allow a class user to know nothing about this dummy pack if he
> wants to use highscores in a second mode.
>
> And games should call this api method while initializing their highscore
> system (i beleive the second method should be used by default - majority of
> games in kdegames use this highscores type).

Personally, I don't think we should restrict ourselves by overloading
the meaning of "level" in the table. Sure we don't currently have a
game that has level sets, levels and difficulties, but I think if
we're writing a new system, it only makes sense to maximise the
flexibility.

>
> Dmitry.
>
> PS. Sorry for my maybe cryptic English :)

Your English is fine. Your replying skills, though, could use some work. :P
_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

[Parker Coates]

On Fri, Oct 2, 2009 at 09:53, Stefan Majewsky wrote:
> I forgot something here: It will of course be obligatory to provide some
> standard sortings (for example, KGameDifficulty could gain some method to
> automatically setup its groups).

KScoreDialog currently allows one to assign weightings to the groups
to get them to sort in any arbitrary order.

But now that I think about it, each group already has an internal name
and a translated name used for display. Maybe it would just be
simplest to always sort by the internal name, so if you wanted to
force the difficulties to sort a certain way, you would just name the
groups "01_veryeasy", "02_easy", etc.  Oh wait, never mind. That won't
work because other types of groupings wouldn't sort alphabetically
when translated.

Parker
_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

Am Freitag 02 Oktober 2009 16:15:31 schrieb Parker Coates:
> You forgot Killbots. :'( Killbots is a bit awkward as it has multiple
> game types (a.k.a. rulesets), but no difficulties or levels. In the
> current KScoreDialog implementation, I simply make game types
> equivalent to difficulty levels, but semantically they're probably
> closer to level packs. But of course I wouldn't want the dialog
> showing a bunch of level packs with only one level in each of them.
> I'd forgotten how tricky this problem really is. :)

Here is another idea: The user (i.e., the user of the library = the game
developer) feeds some tree-style base model into the KScoreManager. This base
model may define level packs, difficulty leves, rulesets, whatever you desire.
The job of the KScoreManager is to populate this model with data. Referring to
my mockup, the base model is the green part (but KScoreManager filters out
items without any highscores).

Greetings
Stefan


_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

[Dmitry Suzdalev-2]

On Friday 02 October 2009 18:15:31 Parker Coates wrote:
> You forgot Killbots. :'( Killbots is a bit awkward as it has multiple
> game types (a.k.a. rulesets), but no difficulties or levels. In the
> current KScoreDialog implementation, I simply make game types
> equivalent to difficulty levels, but semantically they're probably
> closer to level packs. But of course I wouldn't want the dialog
> showing a bunch of level packs with only one level in each of them.
> I'd forgotten how tricky this problem really is. :)
I see. But I think the tricky part here is that it is really difficult to come
up with a highscore system that would suit every single game out there :)

There will always be exceptions.
So we might choose some common ground which can be customized by the games
itself.

> Personally, I don't think we should restrict ourselves by overloading
> the meaning of "level" in the table. Sure we don't currently have a
> game that has level sets, levels and difficulties, but I think if
> we're writing a new system, it only makes sense to maximise the
> flexibility.
Yeah, you are right here. This scheme would fit to be usable in killbots then?

I only wish that having packs/levels/difficulty_levels hierarchy wouldn't
cause bloat on the UI side, we must think carefully on how it'll look like and
consult UI team if we don't find an obvious solution at some stage.

> Your English is fine. Your replying skills, though, could use some work. :P
Haha, right, sorry about that.
If I'll make a 3 more replies to this mail I swear that I'll hide in bushes so
perfectly that you won't ever find me to express me your nays :-P

Cheers,
Dmitry.
_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

Am Freitag 02 Oktober 2009 16:30:43 schrieb Parker Coates:
> But now that I think about it, each group already has an internal name
> and a translated name used for display. Maybe it would just be
> simplest to always sort by the internal name, so if you wanted to
> force the difficulties to sort a certain way, you would just name the
> groups "01_veryeasy", "02_easy", etc.  Oh wait, never mind. That won't
> work because other types of groupings wouldn't sort alphabetically
> when translated.

I don't get the last sentence. In which way would sorting internal names be
locale-dependent?


_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

[Arturo Silva]

Hello,
I'm not sure if I should chime in since this discussions deals
primarily with internal code.  But at least on the UI side, would it
be possible/feasible to have the high scores list filterable by a
drop-down box, or a series of drop-down boxes (one for levels, one for
level set, and/or one for difficulty)?  I imagine this can give you
the flexibility you need in that window without the clutter of
multiple tabs and of coruse all the filters set to "All"  would simply
show the high score window as it is now.

The problem though with my idea (aside from dropdown boxes being
boring) however is that I'm not sure how the high scores are being
stored in the backend, and whether the storage format allows the high
score list to be filtered (or even sorted).

But even so, I thought I should just pop the question, even if I do
end up looking like a numbskull.  ;)

On Fri, Oct 2, 2009 at 10:02 AM, Stefan Majewsky <majewsky@...> wrote:
>
> Arghh.........

lol ^^
And i was just about to ask how it was going with Palapeli.... ^___^'



--Arturo
_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

On Fri, 2 Oct 2009 11:16:28 pm Stefan Majewsky wrote:
> Am Freitag 02 Oktober 2009 12:12:49 schrieb Dmitry Suzdalev:
> > And this would require a very different implementation.
> > Because LevelPacks consist of separate levels. So highscores are for each
> > level in pack. So layout of widgets in score dialog will differ and
> >  unerlying implementation must differ.
> > KGoldRunner and KAtomic are examples of games with such highscore
> >  structure. Both of them don't use KScoreDialog because currently it
> >  doesn't fit their model.
> >
Not quite true.  KGoldrunner's model can fit KScoreDialog and there is
(optional) code in it to use KScoreDialog.  There is just one set of high
scores per collection of KGoldrunner levels.  However, I choose not to
use KScoreDialog ATM, because I think the presentation can be
improved and (AFAIK) there is no way to preserve pre-existing high
score data during a changeover, nor to "seed" level collections at
distribution time with challenge-type scores for new players to aim at.

> I've taken a look at the KScoreManager stuff for the first time. (I have
> followed the discussion about it at that time, but did not take part in it
> because I was relatively new to KDE programming.)
>
> First of all, it seems like much code has been copied and adapted from
> KHighScore/KScoreDialog. There's nothing bad about that a priori, because
> this code has proven its stability in plenty releases. But moving to a new
> API gives the chance of cleaning up old stuff. In this particular case,
> much of the code (also on the presentation layer) is tossing around QMap
> and QList objects. I'd rather use a model/view approach here, which can
> reflect both the score tables and the groups at once.
>
> Something like a KScoreModel might also open the door to an arbitrary
> grouping order (grouping by difficulty, by level, by level pack, etc.). See
> the attached mockup of a KScoreModel with level packs and levels. The green
> part of the model has a tree structure, while the blue part (which is found
> below every leaf of the tree) has a table structure. The blue part directly
> corresponds to what KScoreTable displays, while the green part might
> require different interfaces. Everything of this should be doable with the
> generic approach that the KScoreManager draft is taking on the UI side.
>

In a relational database table, high scores would be represented by a key
that uniquely identifies a set of up to 10 high scores, a rank that identifies
a high score within a set and then the attributes of that high score.

Strictly speaking, there would be two tables, HighScoreSet and HighScore,
with a one-to-many relationship based on the set-identifier.  Before going any
further, I am in no way suggesting using a relational database management
system (RDBMS) to keep high scores.  That would be a *major* overkill and
source of bloat!  But I do think we could use some RDBMS ideas and indeed
KScoreDialog is tending that way already.

Firstly, HighScoreSet should use an (untranslated) surrogate key or keys,
which can remain the same regardless, whether the names or descriptions
of high-score sets change with time or get translated at run-time.  This same
key can also be used if we ever get as far as having world-wide high- scores
for some of our games.  For example, KGoldrunner has such a key for each
collection of levels, e.g. "CM" for "Curse of the Mummy", and it is used for
identifying files relating to level data, high scores, solutions, demos and
replays.

Unfortunately, when I compile KGr to use KScoreDialog, "CM"
appears in the side-tabs and there is not room for "Curse of the Mummy"
or its translation.  I would much prefer a paged display with a decent
sized header and next-previous buttons if people really want to flip
through high-score sets.

The debate about whether a high-score set corresponds to a set of
levels, single levels within sets of levels, difficulty ratings or rule sets
can be resolved by having a two-part key, in which the second part
is a level-identifier and is optional (default "" or 0).

An attribute of the HighScoreSet table would be the name or
description (translated) of the set, whether it is a collection of levels,
a difficulty rating or a set of rules.  KScoreDialog should not have to
care about this (nods to Stefan) any more than a RDBMS cares
whether data is the name of a company, a country or a person.  The
semantics are supplied by the application and the user.

We would also need a (translatable) sub-name as an attribute (default
value "").  I am guessing, but I think two keys and two names would
cover all the high-score sets we might need.  Finally we might have
an untranslated sort-order value, rather than bind it into one of the
other values.  So:

    HighScoreSet:
        id_1  mandatory
        id_2  optional, default "" or 0
        name_1  mandatory, translated
        name_2  optional, translated if present
        sort_order  optional, order is sort_order then id_1 then id_2

   HighScore:
        id_1  joins to HighScoreSet
        id_2  joins to HighScoreSet
        rank  value 1-10, identifies a high-score within a set
        person_name mandatory
        score mandatory
        etc. much as now implemented.

Using Stefan's example, these tables would contain data:

    "egypt",1,"Egypt level pack", "Level 1",""
    "egypt",2,"Egypt level pack", "Level 2",""
    "greek",1,"Greek level pack", "Level 1",""
    "greek",2,"Greek level pack", "Level 2",""

    "greek",2,1,"Felix",100, ...
    "greek",2,2,"Stefan",50, ...

There are two high-scores for "Greek level pack", "Level 2"
and none (yet) for the other three high-score sets.

I think we could get away with KScoreDialog storing only
the second set of data, with the application supplying the
HighScoreSet data, as and when required, with appropriate
translations.  One problem is if the dialog displays multiple
tabs or selectable high-score sets, how would it get the name
and sort-order data?

RDBMS's also contain meta-data, such as names and
attributes of tables and columns.  I think it would be nice
if applications could supply this, as well as having some
commonly occurring definitions "built in" to KScoreDialog.

For example, a major part of the high KGoldrunner scorer's
achievement is how many lives are left and what level she
or he has reached.  For KScoreDialog to display such
stuff, KGr would have to supply data-names (which might
also serve as column-headings), data-types (integer, etc.)
and values, of course.

Hope this is helpful, Ian W.
_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

Am Samstag 03 Oktober 2009 09:43:06 schrieb Ian Wadham:
> However, I choose not to
> use KScoreDialog ATM, because I think the presentation can be
> improved

Please tell me how the KScoreDialog to look like from your POV. I'm currently
envisioning to replace the score table in the middle by a QTableView.

> Unfortunately, when I compile KGr to use KScoreDialog, "CM"
> appears in the side-tabs and there is not room for "Curse of the Mummy"
> or its translation.  I would much prefer a paged display with a decent
> sized header and next-previous buttons if people really want to flip
> through high-score sets.

KScoreDialog already has the concept of allowing multiple dialogs. I
specifically think about the group/level/whatever ordering here. The current
tabbed approach is good for flat group lists (like difficulties), which KGr
could rather use a listview to select a level pack.

> RDBMS's also contain meta-data, such as names and
> attributes of tables and columns.  I think it would be nice
> if applications could supply this, as well as having some
> commonly occurring definitions "built in" to KScoreDialog.

This is also something which I find rather important. A big problem (from the
developer POV) with the current KScoreDialog is that you have to call three
KGameDifficulty functions (localizedLevelStrings, localizedLevelString, and
levelWeights), and pass the return values to the right KScoreDialog methods.
I'd rather like something like:

dialog->setGroupingModel(KGameDifficulty::groupingModel());

So all in all, I'm on your side here. The more tricky part will be how to
implement all of that with the goodness that Qt provides.

Greetings
Stefan


_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

Am Samstag 03 Oktober 2009 04:12:46 schrieb Arturo Silva:

> Hello,
> I'm not sure if I should chime in since this discussions deals
> primarily with internal code.  But at least on the UI side, would it
> be possible/feasible to have the high scores list filterable by a
> drop-down box, or a series of drop-down boxes (one for levels, one for
> level set, and/or one for difficulty)?  I imagine this can give you
> the flexibility you need in that window without the clutter of
> multiple tabs and of coruse all the filters set to "All"  would simply
> show the high score window as it is now.
>
> The problem though with my idea (aside from dropdown boxes being
> boring) however is that I'm not sure how the high scores are being
> stored in the backend, and whether the storage format allows the high
> score list to be filtered (or even sorted).

Filtering and sorting is not a big problem, that does not have much to do with
the storage format. The bigger problem is that KHighscore currently saves
exactly 10 highscores, which makes filtering quite pointless. I also do not
really like to save all highscores, because this could massively increase the
loading time of the score dialog.

> And i was just about to ask how it was going with Palapeli.... ^___^'

It's progressing very well (just have a look on Planet KDE). If you like to
leave your signature in the game, you can draw some puzzle table textures.
Eugene has already created one SVG texture, and I've selected some JPG
textures from a big GPL'd collection of seamless tiles. All of them are in the
subdirectory src/pics/. When you add your texture, also add it to the list in
CMakeLists.txt to install it, and use the right mouse button on the puzzle
table to select a texture.

Greetings
Stefan


_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

[Arturo Silva]

On Sat, Oct 3, 2009 at 5:55 AM, Stefan Majewsky <majewsky@...> wrote:
>
> Filtering and sorting is not a big problem, that does not have much to do with
> the storage format. The bigger problem is that KHighscore currently saves
> exactly 10 highscores, which makes filtering quite pointless. I also do not
> really like to save all highscores, because this could massively increase the
> loading time of the score dialog.
>

Ah, I had a creeping suspicion that it wasn't really saving all high
scores, so thanks for explaining that. :)

Although that does open up another line of questioning, in that if we
still only save 10 highscore slots, would that also negate the benefit
of modifying the ScoreManager?  And likewise, if we increase the score
slots to accommodate for the different level packs/difficulties/etc
(which will probably need more than 10 to stay relevant), that in
itself won't increase the loading times, no?

>
> It's progressing very well (just have a look on Planet KDE). If you like to
> leave your signature in the game, you can draw some puzzle table textures.
> Eugene has already created one SVG texture, and I've selected some JPG
> textures from a big GPL'd collection of seamless tiles. All of them are in the
> subdirectory src/pics/. When you add your texture, also add it to the list in
> CMakeLists.txt to install it, and use the right mouse button on the puzzle
> table to select a texture.
>

hehe, you learn something new everyday.  :)

http://planetkde.org/

Okay, will do!  ^^v
That was fast, btw! Thanks for working on that so quickly.  ^__^



--Arturo
_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

[Parker Coates]

On Sat, Oct 3, 2009 at 05:43, Stefan Majewsky wrote:
> Am Samstag 03 Oktober 2009 09:43:06 schrieb Ian Wadham:
>> However, I choose not to
>> use KScoreDialog ATM, because I think the presentation can be
>> improved
>
> Please tell me how the KScoreDialog to look like from your POV. I'm currently
> envisioning to replace the score table in the middle by a QTableView.

I too think a table view would probably be ideal. The current grid
layout of individual labels system isn't necessarily bad, but it isn't
 really how the user expects to see tabulated data.

On Sat, Oct 3, 2009 at 05:55, Stefan Majewsky <majewsky@...> wrote:
> Filtering and sorting is not a big problem, that does not have much to do with
> the storage format. The bigger problem is that KHighscore currently saves
> exactly 10 highscores, which makes filtering quite pointless. I also do not
> really like to save all highscores, because this could massively increase the
> loading time of the score dialog.

I think it's very important that we make the length of the score
list(s) settable. Ten is a great number for, say, KMines, but I think
for a game that tracks scores for every level in every level pack, we
might want to drop that number down to 5 or 3 or even 1 score per
level. I think there is a possibility of information overload,
otherwise.

Parker
_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

[Parker Coates]

On Sat, Oct 3, 2009 at 03:43, Ian Wadham wrote:
> However, I choose not to
> use KScoreDialog ATM, because I think the presentation can be
> improved and (AFAIK) there is no way to preserve pre-existing high
> score data during a changeover, nor to "seed" level collections at
> distribution time with challenge-type scores for new players to aim at.

Porting existing scores forward to a new system might be doable with
the kconf_update tool. [1] It's builtin functions are probably too
primitive, but it allows one to call external scripts. Writing a
Python (or Perl <cringe>) script to convert from on score system to
another shouldn't be too bad. Pre-seeded scores might be handled the
same way too.

Currently KScoreDialog uses the apps default config file for storing
the scores. What do people think about using a separate file instead?
I think this would make things simpler for users (or developers) who
would like to backup and restore their scores, or wipe their settings
while keeping the scores or vice versa. Highscore data really has
little to do with the app configuration and it's always kind of
bothered me that they're stored in the same file.

Parker
_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

On Sat, 3 Oct 2009 11:17:45 pm Parker Coates wrote:
> Currently KScoreDialog uses the apps default config file for storing
> the scores. What do people think about using a separate file instead?
>
DEFINITELY use a separate file!  And it is easy to do so and still keep
the KConfigGroup file-format.  Several KDE games use such files for
game-related data, which is what high scores really are.

> I think this would make things simpler for users (or developers) who
> would like to backup and restore their scores, or wipe their settings
> while keeping the scores or vice versa. Highscore data really has
> little to do with the app configuration and it's always kind of
> bothered me that they're stored in the same file.
>
Ditto from me.

Cheers, Ian W.

_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel