Two weeks ago I experimented with packaging the KDE Games for MeeGo and tried the results on the give-away Lenovo Ideapad from the MeeGo conference last november in Dublin with the MeeGo Netbook 1.1 installation. To find out that most games are quite usable even with only the touch-screen as input device, while some are not, but almost all are in desperate need for proper fullscreen support, for a full fun experience.
Remembering about the then upcoming KDE Games sprint Blue Wonder 2011 last weekend I quickly decided I should join this and start to do something about that (especially as Dresden is only a 2 h train ride away from Berlin and this also meant visiting my former home town and most fellows from the KDE developer community in Dresden). Thanks to Josef Spillner for being a host (and a good one) for me on that short notice 🙂 Thanks also to my fellow workers Jon and Mathias at Openismus, they lent their Ideapads to me for the sprint.
While my plan was to work, for having a template, on my favourite game Palapeli, the really nice jigsaw puzzle game from Stefan Majewsky, I quickly was occupied with trying all the games, to gather some general information what works and what does not work. Do you know how many KDE games there are, only in the module kdegames? I did not, and was surprised about the number! That was my little blue wonder, and so I followed the sprint’s topic and may have played^Winvestigated all the games more than half a day in total 🙂 (had to leave out ksirk and granatier for packaging problems)
So from my notes with regard to touch-screen input I found…
… these 15 games working out-of-the-box: Bovo, kdiamond, kfourinline, kigo, kiriki, kjumpingcube, klickety, klines, kmahjongg, konquest, kpat, kreversi, kshisen, ksquares, lskat.
They all only take either a LMB click (press&release at once) events on some coordinate or a LMB press, move, LMB release sequence as input. Which a tap or a swipe on the touchscreen is mapped to 1:1, besides by covering slightly more of the screen with the finger and the rest of the hand than the mouse cursor does.
… these 4 games working basically, but could gain from more support of touchscreens: kbreakout, kblackbox, killbots, ksudoku. The last three miss the highlighting of the rows/columns as triggered by hovering with the mouse, while kbreakout works but feels like that is only by accident. Beware: kbreakout will steal you more time than you planned to play it. It really works too well in fact 🙂
… these other games to need work to be usable with a touchscreen:
Bomber, Granatier, Kapman, katomic, kbattleship, kgoldrunner, kmines, knetwalk, kolf, kollision, ksirk, ktron, ktuberling. What their (partially slight) problems are and how these could be approached will be hopefully topic of a future post.
With regard to making full use of the available screen, there was work to be done for almost all. Being developed along all the other work-oriented KDE programs it seemed obvious that for consistency they also get the usual menubar, the usual toolbar and the usual statusbar. Which all three steal much space in the vertical. Now are most screens more wide than high, while most games which are resembled by the KDE game programs have a rather quadratic form factor. The result: big unused spaces to the left and to the right, e.g. with KPatience:
Just see how much bigger the actual content gets if the window bar and the menu bar are removed:
The button to toggle between fullscreen and normal window you see in the toolbar in the screenshots is not part of the current program, I created an experimental patch to add this button to almost all games, which for now is only applied to the sources used to build the MeeGo packages of the KDE Games on the Public/Community MeeGo Build Service. I would like to improve this by having that button aligned to the right side of the toolbar, as it rather acts on a different level than the other buttons (I also wonder how much overlapping with the functionality of the windowmanager is here. What is the semantical difference between maximized window and fullscreen?).
Now imagine that toolbar also being disappeared, only sliding in on demand, e.g. by tapping on the upper boarder of the screen, like it is done to get the MeeGo Netbook 1.1 system bar. I think of something like Okular has when in presentation mode. The buttons of the toolbar could also be shown as overlays on a tap in some free space, if there is plenty of that in the game board. And then there are gestures, but those are yet to arrive in the Qt API IIRC, so not yet considered.
To have proper support for going fullscreen is especially needed for small-size form factors like netbooks and handhelds, with and without touch-input (but then even more, given your fingertip is quite large, unless you use a sharpener, well, don’t! 😉 ). But also for bigger screens it can be quite a pleasure to see just the actual content and not all the clutter around it, which is usually of zero interest when you work on the content. I still remember when something like two decades ago (was it Word Perfect? MS Word?) I really enjoyed the fullscreen option where everything but the virtual paper was removed from the screen, so the actual content could be rendered with as much pixels as the physical screen has, and the screen was as pure as could be. Similar to what these days programs like FocusWriter are also specialising on.
Update: See the blog posts from Peter Penz and Martin Gräßlin from the day before on a related discussion about what to do with the menu bar, i.e. how to fix the cluttering it creates and how to gain the screen estate it takes.
Kudos to the developers of KDE Games and the artists responsible for the pretty graphics, the KDE Games are really some nice shiny diamonds. And addictive, as my flat-mate just proved when I showed to her what I worked on last week-end 🙂
Thanks also to the organizers of the sprint, Josef and Stefan, as well as to the supporters, as represented by the KDE e.V.
Attracted by virtual constructs 