Demo Game Plan

[Adrian Ratnapala <s369625@student.uq.edu.au>]

Christian Reiniger writes:
 > I just noticed that I haven't responded to your latest Demo Game Plan mail,
 > Adrian. Shame on me. Well, the short summary is: I agree ;)
 > Can you take care of the further planning for that, i.e. fleshing out the
 > design, what's needed etc and posting the plans from time to time? We
 > really should get that going...
 > 

OK.   Actually I have been quite remiss about this because I haven't
been reading enough mail and replying even less.

I've been working on the Demo.  I even have code.  I haven't committed
it, and won't until its starts looking like C++ instead of C++-like
pseudocode (i.e I'll wait till it compiles). BTW: I have been
using C++ features heavily, including the STL (since this is not
a program which is pushing resource limits).


Here is what it looks
like:

Modules (each with a C++ namespace):
        Control:  main loop, events etc.
        GFX: the only one which is supposed to know about pg2d.
             (well, not yet, but maybe we should make that so).
        Agent: monsters, player etc.
        World: maybe should be renamed "level".
          + the main file and a utils lib.

GFX:
   Exports two main things, Sprites and Views.  A the only View
at the moment is the main viewport, but radar screens etc. would
be view (as if you would have them in a platformer:) ).  They
are responsible for converting from world-to screen coordinates.

   Sprites:  At present each agent has its own private sprite object.
(The sprites can shared raster data though).  It might make sense
to let agents share sprites instead, not sure.  Sprites hold
raster data for each frame of animation.  And know their position
in world coordinates.  They export their position & current raster
frame to the View, which does the actual rendering.  Views know
only about the sprites which exist in them, not the Agents owning
said sprites (hmm, only works with the unshared-sprite model).


Agents:
   Have Act() functions which do all the moving around, cause
collisions etc.  The semantics of the game is mostly interactions
between Act() functions and collision handlers.

CONTROL:        
main loop:
   1) event-grab and dispatch (currently hard coded GII).
        The dispatch is just a case statement, unlike a widget set
        there is no calling of event handler methods or anything.
        This is intentional, only the "control" module should know
        about the semantics of keystrokes etc.  So control will call
        functions like "Agent::TurnLeft" instead of
        "Agent::HandleLeftArrow".  Most of the the "Agent::TurnLeft"
        style functions will simply alter the state of the agent,
        actual action will happen later.

   2) call world.Act()
        which will in turn call the Act() method of all the agents.
           which will indirectly end up calling any appropriate
           collision detectors/handlers and whatever.
             

   3) call viewport.Draw()


> 
 > 	Christian
 > 
 > --
 > 
 > Drive A: not responding...Formatting C: instead
 > 
 > ---------------------------------------------------------------------
 > To unsubscribe, e-mail: penguinplay-unsubscribe@sunsite.auc.dk
 > For additional commands, e-mail: penguinplay-help@sunsite.auc.dk
 >