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

[Stefan Majewsky]

Sorry for not responding so long, I have several real life issues limiting my 
KDE time.

On Tuesday 17 August 2010 20:33:20 Aaron J. Seigo wrote:
> random thoughts:
> 
> * what kind of role could gluon play?

After a first evaluation, not a big one (unfortunately, I have put big hopes 
to use their libraries). My review is on kde-games-devel [1].

> * 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"

Probably yes. It probably will have to turn out whether what we produce will 
be useful for the non-games apps, too.

> 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.

So getting touch and accelerometers and stuff to work is not that difficult as 
I expected at first? I do not have any devices which I can use for testing, so 
I cannot tell.

> 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. [...]

That's the plan. For desktop games, the chrome would always be there (unless 
in fullscreen mode, if there is one), while it would be hidden on mobile 
platforms.

> * 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.
> 

> 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.

Interestingly, I have just now written kdegames' own SVG rendering, painting 
and caching system, with all bells and whistles. (Ask api.kde.org for 
KGameRenderer.) The use case is different: 
* Plasma uses a theme composed of multiple SVG files, AFAIK to be able to 
fallback to the default theme when some of these SVG aren't available. OTOH 
our games use a single SVG theme which contains all visual components.
* Plasma::Svg seems to be the lowest granularity of theme components. 
KGameRenderer has the KGameRendererClient which is attached to a single SVG 
element, and receives a new pixmap automatically, should the need arise.
* While Plasma renders (AFAIK) nearly its complete UI from these themes, games 
consist of a relatively small number of sprites. Progress bars etc. are (if at 
all) simple QWidgets. Of course, if we want to move everything into the themed 
game view, we will have to theme these elements, but I think that QML is a 
much more likely candidate there.

> 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.

Most of our games are QGV-based (a current dataset is at [2]), but quite some 
of them do funny things with the view to implement the scaled contents. This 
makes it at least non-trivial to port them to a view-less environment like a 
plasmoid.

> 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.

Yes. I hope to brainstorm with Josef, our GGZ guru, on the networking and 
highscore stuff.

Greetings
Stefan

[1] http://kde.markmail.org/message/bnibfxyxulqrcpn5
[2] http://techbase.kde.org/Projects/Games/Porting