[Kde-games-devel] Game status view

[Parker Coates]

On Sun, Jun 8, 2008 at 17:21, Mauricio Piacentini <piacentini at kde.org> wrote:
> This is a camp that can better be described
> as: Games in kdegames ideally need to use the same metaphor used by
> other applications, including visible menus, toolbar, statusbar. In
> other words, automatically match and leverage the "desktop" APIs used by
> all KDE apps.

I consider myself to be in this camp, with status bars as the one
exception. I've always considered the status bar as an extra. Status
bars are often optional, and as a result they usually contain only
optional information. (Or maybe it's the other way around.) For
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, but web browsing
is still very much doable without this information. In fact for most
basic users, you could probably hide the status bar without them
really noticing.

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. Of course, as Stefan mentioned the status bar
also has issues with readability. This is often not a big deal, but in
time-based games, the milliseconds wasted finding the relevant number
the status bar can be critical. But of course, I realise that for the
most part, this is an issue of personal preference and I certainly
would never tell another game developer was wrong choosing the status
bar.

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

As to the amount of space in scene status displays use, in Killbots I
got fancy and dynamically position the status displays to maximise the
space available for the main game grid. I know this doesn't apply to
most games and some might argue that it has a negative effect on
usability, but I was thought is was pretty neat, so I went with it.

Status on the side:
http://picasaweb.google.com/Parker.Coates/KDE/photo#5209729425462840034
Status on the top:
http://picasaweb.google.com/Parker.Coates/KDE/photo#5209729435583189138

As a result, the function that lays out my QGraphicsScene every time
the view size changes is 140 lines. Overkill? Probably.

Parker