[Kde-games-devel] Status of KJumpingCube and KSokoban

[Ian Wadham]

Re Mauricio's review "Status of games in SVN" of 11/4/07, he said:

"kjumpingcube: works fine. Game window resizable using QPainter elements,
same as in KDE3. No SVG. No support for loadable themes. Looks and plays
the same as the KDE3 version, minus the blinking effect."

"ksokoban: not playable, crashes at startup. Apparently has no SVG support."

These two games compile OK in playground/games and perform as Mauricio
describes.  I have delved into the code a bit and played KJumpingCube a bit.

KJumpingCube has a few other minor errors, apparently due to incomplete
porting (e.g. allowing for the changes to QFrame in Qt4), but I think it could
be rescued before 1 June.  I would like to attempt that.

The question is whether it is worth SVGizing and themeing it.  The main widget
is just an array of top views of dice faces.  In KDE 3 they are flat squares 
separated by thin lines.  They should probably be given a more 3D look, maybe 
by using standard Qt widget style features, rather than going to SVG.  That 
way we could preserve the currently excellent resize performance.

I doubt too whether themes would be valuable here.  The game already
allows color choices for the players and that ought to be enough IMHO.
A die is a die is a die [1].  The KDE 3 choice of default colors and icon -
dark red and dark blue - makes visibility difficult and would have to go.

KSokoban (in KDE4) crashes because it compresses its levels data at
build time, re-writes it as a "data.c" module and compiles and links that
into the code.  ATM the code reads the levels data as if it is uncompressed,
with disastrous results.  Fudging the compile definitions makes the crash
go away, but then there is another crash when loading the image data
and converting to QPixmaps ...

The compression scheme seems to be a (complex) pre-KDE1 workaround
for not having an easy way to locate levels data and graphics data at
execution time.  We now have KStandardDirs.  I would suggest simply
reading levels from a data file and loading images direct from *.png files,
cutting out all that compression and "data.c" stuff, but that is probably
too much to do before 1 June.

Re the graphics, they scale very well and the resize is faster than with
SVG.  The underlying graphics are (scalable) povray 3D text-files, which
are still there in SVN and have been rendered as PNG files, also in SVN.

The background is actually a tiled picture of stars and nebulae and might
look a lot better if the "tiles" were larger and you could see some detail.

The stones use a povray texture of a decorative kind of stone, but the
texture is so detailed that it looks pixillated.  Some other texture might
look better.

So, should we tweak the existing graphics or go to SVG?  Note that
KSokoban continually resizes its elements to fit each level within the
background frame.  This would probably degrade performance if
done in SVG.  On the other hand, themeing in povray might be a
whole new learning experience for most of us - not to be undertaken
lightly ...

I would also like to attempt the rescue of KSokoban for KDE 4.1, so
please let me have your feedback re KJumpingCube for KDE 4.0 (above)
and KSokoban for KDE 4.1 - especially re graphics and whether to use
SVG in either case.

All the best, Ian W.

[1] Apologies to Gertrude Stein - and "die" is the little-known singular
of "dice", believe it or not.