[Kde-games-devel] ksokoban

[Ian Wadham]

Hi Łukasz and Shlomi,

On 31/07/2012, at 1:51 AM, Kantacki wrote:
> Permissions granted
> 
> W dniu 2012-07-29 21:38, Shlomi Fish pisze:
>> On Sun, 29 Jul 2012 17:28:45 +0200
>> Łukasz Kalamłacki <kalamlacki at gmail.com> wrote:
>> 
>>> If you give me your sourceforge acount name I will grant permissions for
>>> you for modifing the code.
>> It's "shlomif".
>> 
>>> This is OpenSource, so when you have something to add then go ahead.
>>> What distribution did you use for compilation, I tested this on Debian
>>> Squeeze na Wheezy and in both cases compilation went fine.
>> I use Mageia Linux 3/Cauldron. Did you try doing "mkdir build; cd build ;
>> cmake .. ; make" and it worked?
>> 
>>> And the code which you mentioned is only for compatibility with MinGW32
>>> compiler, for short term is fine, so when you have better solution for
>>> WIN32 then go ahead with your modification.
>> No, it's not the #define GETUID() getuid() is used on UNIX systems, and as a
>> result caused the compatibility problem for me (because my UID changed). I did
>> not intend to put my #if 1 #define GETUID() 501 change in the commit, but I used
>> it to test the new system.

You guys seem to be having fun … :-)

Out of curiosity I installed Mercurial and cloned Shlomi's repository.  It compiled
and built OK, but I stayed within the source tree.  And then it ran and up popped
the ghost of the dear old KDE 3 KSokoban, complete with its purple background.

Here's how it is, though.  What you are offering is KDE 4 and Qt 4 enabled ---
that is good.  It looks, quacks and runs like KSokoban, but it is not the "whole
KSokoban and nothing but KSokoban".  Take a look at the two data.c files and
the file bin2c.c, in the levels/ and images/ directories.  The current build just
"#include"s the data.c files, but the original began by building bin2c.c, then
running the bin2c executable to *generate* the data.c files before the main
build began.  The data.c files are compressed binaries of the levels data and
image data (*.png files), in the form of compilable arrays of hex constants.

I am NOT suggesting that you should reproduce that behaviour.

In effect, the old code would "load" the levels and image files by building the
whole lot into the compiled executable of KSokoban.  That is what I meant by
saying it was going from London to Paris via Moscow.

Nowadays, and also back in KDE 3 days (and even KDE 1 and 2 days), we
would use QImage to load image files at run time and convert them to pixmaps.
And we would use KStandardDirs (locate/find functions) to find where image and
levels files have been installed before loading them.  What is more, since KDE 4,
we would use SVG graphics files and a choice of graphics themes, rendering
the SVG to the right size at run time (as the user resizes the main window) and
allowing themes to be easily switched at run time.  Most KDE games work this way.

KSokoban does have scalable graphics, but they are PovRay graphics and
I do not think anyone in KDE uses PovRay now.  So the KDE 3 KSokoban used
*.png files snapshotted from PovRay and relied on Qt's pixmap scaling features,
AFAICS.  Actually, the quality is quite reasonable, but starts to get fuzzy when I
maximise the main window on a 1440 x 900 display.  KSokoban comes from the
era when 640 x 480 was the latest and greatest.

If you would like to see exactly how things were in KSokoban before it was
dropped from KDE Games, see:

    http://websvn.kde.org/trunk/KDE/kdegames/?pathrev=660427

That winds the KDE Games repository back to about 5 or 6 years ago and
shows KSokoban still in it, with some of the KDE 3 to KDE 4 conversion
already done.  We abandoned it at that point, because it was not going to be
easy to meet the graphics requirements described above.  Note the contents
of the various CMakeLists.txt files in the KSokoban tree.  I guess you could
svn checkout revision 660427 of the KSokoban files if you wanted to go further
with the old KSokoban code, with all its "C-isms", weird hex literals and general
lack of comments --- not to mention direct use of fopen() and getuid().  It makes
me feel I am back in the 90s and the Qt library has not happened yet … :-)

Now lets have a look at Magazynier, see:

    http://websvn.kde.org/trunk/playground/games/magazynier/

I checked this out and compiled it within the SVN trunk environment of KDE Games.
It runs OK, but needs a little work.  It is already themeable.  It has a reasonable theme
(based on an ant pushing eggs into its nest) and a crude one (used for programming
and testing, no doubt).  I expect other themes could be added if we can lure back
some of our artists … :-)

The code uses recent KDE Games, KDE and Qt classes, so it is very compact.  The
graphics is already using QGraphicsView, QGraphicsScene and KGameRenderer,
so it is very fast and clear.  The main things that needed doing, as far as I could see
at a quick look, were more options for move-controls, a step-by-step animation for
long-distance moves and provision of animation for short moves and turns.  There
is a built-in A* algorithm for finding the shortest distance (using valid moves) from one
point to another, but the move occurs all in one jump.  The ant points different ways
(as would a fork-lift truck), but switches abruptly from one orientation to another
when you ask it to move or push.

The Magazynier code is not big on comments either, but I had no trouble reading
it, because it is using library classes well known in other KDE Games.  Also, it has
good separation of model, view and control and use of signals and slots.

Comparing the code statistics, there are 35 source code files in KSokoban, totalling
just over 5,000 lines as opposed to 15 files in Magazynier, totalling just over 2,000
lines.  I know which one I would rather be maintaining … :-)

So, Łukasz and Shlomi, if you really want to bring Sokoban back to KDE Games
and are prepared to look after it for a year or two, I suggest you go with Magazynier.
Also, as Albert remarked, you need to use KDE's standard repositories and tools,
not Mercurial, otherwise we will have difficulty reviewing and accepting your work.
KDE Games is still in SVN, but we are getting ready to move to git, where most of
KDE now is.

If you decide to work on Magazynier and polish it up for final entry to KDE Games,
you should also, out of courtesy, write to the two previous authors (whose names
and email addresses are in the source code) and ask for their blessing.

All the best, Ian W.

P.S. Why don't I pick up Magazynier myself?  I am tempted, but I am already looking
after four games and mentoring on Google Summer of Code.