[Kde-games-devel] Game status view

[Mauricio Piacentini]

Parker Coates wrote:
> example, most web browsers allow you to hide the status bar, but the
> user gets the exact same /functionality/ whether it's visible or not.
> Sure, you may no longer know where a link leads before clicking it and
> you won't know exactly when a page finishes loading,

...

> If this view of status bars is applied our games, it often seems like
> an unacceptable place to display important game information. Things
> like "time remaining", "lives remaining" or "mines remaining" can
> pretty vital to game play and it seems inappropriate to place them in
> an optional UI element.

I basically agree with your premise, I just not agree with the 
conclusion! In a game for example like KBlocks or KMines or KMahjongg, 
to me, knowing the current points or number of tiles removed or number 
of lines removed is not *required* to continue playing. In fact, as a 
player I do not mind about score or time at all, only when I am done. So 
the initial webbrowser analogy you used holds for me: without the status 
bar the game continues to be playable with the same functionality, I 
just do not know how many points or lives I have, much in the same way 
someone using Thunderbird can not see immediately the number of unread 
or total messages, or if something is still downloading.
For other people, or some games, knowing the time during gameplay is 
important. But more to this below:

> Anyway, my original reason for replying (before I got distracted by
> the above) was to warn developers that if decide to move data displays
> off the status bars and into the game scene, they need to take care to
> properly support the "-reverse" argument. Users of RTL languages won't
> be to impressed if your scene coordinates are all hardcoded for a LTR
> layout. Qt takes care of LTR/RTL for you when you use QWidgets and
> QLayouts, but the on scene items are your responsibility.
> 
> Left to Right: http://picasaweb.google.com/Parker.Coates/KDE/photo#5209729441999578738
> Right to Left: http://picasaweb.google.com/Parker.Coates/KDE/photo#5209729470280604626

This is one of the reasons I mentioned for not wanting to move 
everything to the canvas on desktop games, the unnecessary need to redo 
things that the user expects to be right on the desktop. This includes 
issues like RTL, cutomization of fonts, sizes, contrast (accessibility), 
color theme, antialias, subpixel aliasing, you name it. Qt and KDE gives 
us solutions for keeping things consistent if we use the standard UI 
elements metaphor. Again, only if applicable to the game, might not be 
the best solution for all, etc, etc.

Regards,
Mauricio Piacentini