[Kde-games-devel] Restructuring and rewriting KGoldrunner

[Ian Wadham]

Hi guys,

Hope you all had a great Christmas and are enjoying a wonderful
New Year.  I certainly did ... and am ... :-)

This is just to let you know what I am doing with KGoldrunner and
to put out a few ideas for discussion.  I suppose people would call
it refactoring, but I am old-fashioned and don't really understand
what that term means, hence the subject line.

The new development I would like to do is outlined in the TODO file:

 http://websvn.kde.org/trunk/KDE/kdegames/kgoldrunner/TODO?view=markup

mainly in points 9 to 23.  However I have discovered that the code is
a veritable dog's breakfast (i.e. a mess).  It was the first program I wrote
in C++ and the starting version was a student exercise by Marco Krueger
of Berlin, the original author.  This is turning into a major rewrite of the
code, so I will be working over in branches/work/kgoldrunner.

Backward compatibility with game data and graphics themes will
be maintained, so please keep contributing games and artwork ... :-)
But if you wish to work on the source code, please let me know.

Whilst the main objective is to re-design and re-write the game
engine, I would also like to make the whole program as much
as possible Model-View-Controller (MVC).  So the game engine
will consist of classes descended from QObject (and ideally
nothing else) and will communicate to the view, sound-player
and controller code only by signals and slots.

At present (KDE 4.2 and before) the game engine is tightly coupled to
the animation, with four animation frames per grid square, each shifted
by a quarter of a grid square, regardless of speed (which can change
from level to level).  The main animation sequences consist of 8 frames
spread over 2 grid squares.

My idea is, when arriving in a grid square, to tell the view what kind
of animation is required (e.g. run left/right, climb up/down, etc.) and
give it a time in which to get to the next grid square.  The view can then
perform this move using as many frames as it likes, with whatever shift
and timing it likes, including repeating and shifting frames to smooth
the animation, as is done in Scavenger.  The present KGrSprite class
(thanks Mauricio!) is quite well suited to take on the required methods.

The approach would make it possible to theme animations and
even vary the aspect-ratio of cells (they would no longer have to be
square).  For example, the present scheme has only two frames for
falling (fall to the left and fall to the right) and a fall just repeats one
of these frames over and over, but a new theme (or updated existing
themes) could add frames for rotating while falling or for flailing
arms and legs.  OTOH, the hero could be a tank, with only one
frame per animation type (turret pointing up/down/left/right).

One of the biggest sources of bugs in the original, both during
development and after release, was that timers would go on
running when a level was paused, showing a message or just
terminated in one way or another.  In the new version, there will
be new classes KGrLevelPlayer and KGrEditor, which will be
instantiated only when a level is being played or edited.  All the
timer control will go via KGrLevelPlayer.  So when it dies, the
action dies automatically until the next level is displayed.

The level player will reference data-only-objects KGrGameData
and KGrLevelData, from which come the names, the rules, the
dimensions of the playing grid (which will no longer be fixed
at 28x20 cells), as well as the number of levels and the layout
of each level.  Note that the original Apple II grid was 28x16
cells and for the planned Scavenger game it is 24x15 cells. 

The level data will be turned into a KGrLevelGrid object that
keeps a record of what is in each cell and what access to
neighboring cells is possible from that cell.  This alone will
remove a huge amount of current procedural code which is
continually checking what is in neighboring cells and is rather
painstaking, verbose and error-prone.

KGrLevelPlayer will of course contain a KGrHero object and
a list of KGrEnemy objects, both classes completely rewritten,
but each equipped with a polymorphic KGrRuleBook object that
contains rules for Traditional, KGoldrunner or Scavenger play.

Most of the rules are represented as flags and constants with
appropriate  values, but there will be (at least) methods to
implement the three different algorithms used by the enemies
to chase the hero.

I have said "will" all through this, to keep the English simple,
but if anyone has any comments, suggestions, ideas or warnings
re what I am doing, please do not hesitate to email me, either
publicly or privately.

All the best, Ian W.