[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Demo Game Plan



MAILER-DAEMON@s369625.student.uq.edu.au writes:

This is one of the messages that got killed in my recent qmail
troubles.  This one needs resending.  You can see what it's
about from the Subject header field.

 > 
 > 
 > Stage 1:
 >         - Draft spec design.  Included below.
 >         - Argue about spec and design. (Argue, don't ignore please).
 >         - Fix design.
 > 
 > Stage 2
 >         - Divide labour.  This should flow pretty easily from 1.
 >         - ? Quick  implementation plan.  Timeline?
 > 
 > Stage 3
 >         - Code.  Debug.  Redisgin.  Crunch, Crunch.
 > 
 > 
 > I am assuming a 2d shooter here.  I suggested it before and
 > no one complained in time.
 > 
 > 
 > SPECIFICATION - sort of.
 > 
 > PDem - A simple 2d platform shooter, as a demo for PPlay.
 > 
 > 1) Traditional 2d platform structure.  Levels which character may
 >   move about, a health score which cuases death, monsters and traps
 >   etc.
 > 
 >   - Consequence:
 >         - Moving things must be supproted, as well as obstacles.
 >         - Colisions with non obstacles should be able to trigger
 >                 events such as damage.
 > 
 > 2) The character and the monsters (and traps) must be able to shoot
 >   projectiles.
 > 
 > 
 > 3) Many of the moving objects should have a natural tendancy to fall down.
 > 
 > 4) When the charaters moves over (or just to near) the screen's edge,
 >    then the screen must smooth scroll accordingly.
 > 
 > 5) The character must be able to do things like move and shoot
 >    according to real time user input.  Specifically:
 >         -       Keyboard.
 >         -       Nothing else for now.  (Even if the mouse in Abuse is cool.)
 >   
 > 
 > 
 > 
 > DESIGN:
 > 
 > Objects:
 > 
 > I just reread my old GameSpace doco so the design here is a
 > simplification and specialization of that.
 > 
 > Classes:
 >         Level.
 >         Sprite.
 >         Viewport.
 >         
 > 
 > Sprites:
 >    Everything on screen is a sprite, sprite hear is probably the
 >    wrong word since what I am thinking of are heaver than real a
 >    sprite.
 > 
 >    Sprites must have
 >         - A bounding box.
 >         - A draw method (even if it is a no op)
 >         - A position.  (In gameworld space)
 >         - A collision handler.
 > 
 > Level:
 >    The level contains the map, knows where things are and can do
 >    fast bounding-box level collision detection.  It must:
 >         ????? - Keep track of all the active sprite, this might mean
 >                 the level is responsible for calling their "act"
 >                 method, or whatever, or maybe that should be
 >                 done outside.
 >         - Detect BBox collisions and inform the sprites involved.
 > 
 > Viewport:
 >    The Viewport is responsible for keeping track of which sprites
 >    are visible at a given time and making sure they are drawn
 >    at the correct correct postion (in on screen space).
 > 
 > 
 > 
 > Procedural Structure:
 > 
 > //This might be a within method of the Level, who cares.
 > timed_event_loop{
 >         dispatch_events();   //may be implicit in real code.
 > 
 >         for(each registered active sprite (object?)){
 >                 sprite->act();
 >         }
 > 
 > }
 > 
 > 
 > ExampleSprite::act()
 > {
 >         .
 >         .
 >         .
 >         //we want to move.
 >         switch( collision = level->get_move_collision(some coords) {
 >         case painful_collsion:
 >                 get damaged;
 >                 move()
 >                 break;
 >         case mere_obstacle:
 >                 break;
 >         case NULL;
 >                 move();
 >         }
 >         .
 >         .
 >         .
 > }
 > 
 > 
 > 
 > 
 > I'll stop now.  This is hardly a complete design, but I think I'll
 > get some more feedback before going further.