[Kde-games-devel] Restructuring and rewriting KGoldrunner

[Luciano Montanaro]

On Wed, Jan 21, 2009 at 5:37 AM, Ian Wadham <ianw2 at optusnet.com.au> wrote:
> 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.
>

Hi Ian, I just want to confirm I pretty much agree with your plan.
About theming, I feel one point that makes it awkward to make more
organic-looking levels is that the rendering is directed by the Game
canvas, while it would be optimal to have a call to the teme engine to
setup a level background given the tile matrix and the progressive
level number (and possibly the level set name).

Luciano

> All the best, Ian W.
>
>
>
>
>
>
>
> _______________________________________________
> kde-games-devel mailing list
> kde-games-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-games-devel
>



-- 
Luciano Montanaro

Anyone who is capable of getting themselves made President should on
no account be allowed to do the job. -- Douglas Adams