[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.