[Kde-games-devel] Generalizing interfaces and interaction with QGraphicsItems across form-factor boundaries

[Aaron J. Seigo]

On Monday, August 16, 2010, Stefan Majewsky wrote:
> I would like to invite you to thinking about, discussing and designing a
> general set of interface components for games which can be used on mobile
> devices instead of the usual WIMP controls. The ultimate goal is a UI

random thoughts:

* what kind of role could gluon play?

* is most of the issue about menubars / toolbars, along with alternative input 
systems for games like kgoldrunner?

for menubars/toolbars, then yes, something like XMLGUI could be good, and it 
would probably be easier to make it game specific as the requirements are 
simpler / more straightforward than trying to generalize it to "all possible 
applications"

for input, i think gluon has been working on that. on touch devices, games 
like kpat or mahjong play well. games like kgoldrunner not so much, but a 
virtual joystick or even using the accelerometers would be an option.

to keep it generic enough to work on different devices, i can see the need 
for:

* a "show the management chrome" event. this may be a special hardware button 
on some devices (while the game will play full screen the rest of the time), 
or a hotspot on screen, or a key combo or ... by keeping that a platform 
detail, the games can work without caring about it and just using that generic 
facility

* chrome manager: give a list of actions and some structure for them, display 
them in a platform relevant manner. i really don't have much insight into what 
the needs will be here, specifically, but looking at the games it seems like 
it's mostly a fairly stock set of things like "new game", "configuration", 
"set up network play", "give me a hint". things like hints may appear on-
screen in a standard location all the time even on touch devices, while the 
others may only be shown when the "show the chrome" event occurs

* abstracting out input. this is something that i'd suggest borrowing from 
gluon as a lot of work has been done here.

other than that, laying down some basic ground rules for game UI would be 
helpful: all items must be scalable; density of items that must be controlled 
by touch must not exceed a certain threshold (so that they can scaled up large 
enough on smalls screens), right / middle clicking are not allowed as valid 
input mechanisms, etc.

> Not only am I interested in your thoughts on how such interfaces (or
> library classes) might look like, I'd also like to know whether there are
> existing components which might be reused. From what I know about Plasma
> (and that's admittedly not as much as I would like), Plasma is too
> high-level for what I need. It's not about creating applets for different
> services, but about arranging buttons and score displays. But please,
> correct me if I'm wrong.

as Marco noted, while some parts are indeed not relevant for games, some parts 
such as the Svg painting and caching system or the DataEngine/Service 
framework are generally useful.

it's also possible to write games as plasmoids and run them in a window. bonus 
is that we'd get the ability to house all games in a plasma shell, which could 
be nice on mobile/touch devices for integration purposes. for games that are 
already QGraphicsView based, this should be relatively trivial. for others, it 
could be a lot of work.
 
the benefit of this would be that all kdegames would be able to use things 
like the Svg theming system and the Plasma themable versions of pushbuttons 
and what not for free.

i'm not sure if there's enough value there to do this, but there could be.

if a DataEngine/Service was written for the highscores thing, then it would 
also be possible to provide regular plasmoids that show top ten lists or alert 
the user of people looking for games to play without having a game actually 
loaded. a little "looking for games" plasmoid that sits in my panel which i 
could turn on and say "tell me when someone wants to play BattleShip" would be 
awesome, for instance.

this really wouldn't help the primary purpose of "making and displaying a 
game" but it could improve the overall experience for the user while giving 
access to some nice bits and nobbles in libplasma to kde games.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-games-devel/attachments/20100817/8020fd8e/attachment.sig