Re: Demo Game Plan

[Christian Reiniger <warewolf@mayn.de>]

Adrian Ratnapala wrote:

> > Stage 2
> >         - Divide labour.  This should flow pretty easily from 1.
> >         - ? Quick  implementation plan.  Timeline?

No timeline. We won't be able to keep it anyway. But good "things to do
next" lists on a regular basis.

> > SPECIFICATION - sort of.
> > 
> > PDem - A simple 2d platform shooter, as a demo for PPlay.

Perhaps something Raptor-like (spaceship 2d shooter-scroller) would be
better for the start as it doesn't need such sophisticated collission
handling and AI and doesn't need gravity at all. And scrolling isn't
dependent from user input.

(I'll mainly note what things we'd need for that game)

> > 1) Traditional 2d platform structure.  Levels which character may
> >   move about, a health score which cuases death, monsters and traps
> >   etc.

Monsters need some AI. Spotting the player, aiming at him, chasing him.
Simple predefined paths won't work in a platform game.

> >   - Consequence:
> >         - Moving things must be supproted, as well as obstacles.
> >         - Colisions with non obstacles should be able to trigger
> >                 events such as damage.

Collision detection, distinguishing between "environment" (not damaging)
and opponents (damaging)

> > 2) The character and the monsters (and traps) must be able to shoot
> >   projectiles.

Object trajectories, autonomous movement along them.

> > 3) Many of the moving objects should have a natural tendancy to fall down.

Gravity. 

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

How will we handle input? (libgii?)

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

To do this properly we need both ppg2d support for Sprites (self-contained
2d images that know how to draw themselves) and "Game Objects" caring about
movement paths, collisions etc.
Eventually also some Screen Layer support in ppg2d (background layer,
platform layer, sprite layer)

> >         //we want to move.
> >         switch( collision = level->get_move_collision(some coords) {
> >         case painful_collsion:
> >                 get damaged;
> >                 move()
> >                 break;

It first gets damaged, then manages to move a bit and then it finally
breaks ;)

> > I'll stop now.  This is hardly a complete design, but I think I'll
> > get some more feedback before going further.

Ok. Here's a rough list of the code we'd need for that if we want to do it
properly:

ppg2d: much of the planned high-level layer
	2d images (for sprites; this includes animated images)
	Sprites
	eventually layers
	Offscreen buffers for smooth scrolling (virtual screen?)
	element-based world display thing (building the platforms etc;
           perhaps belongs to gamespace)
gamespace: The basics plus some simple specific modules
	simple 2d physics. Gravity, linear trajectories etc
	collision detection
	level management. Handling of Entities etc
other:
	Simple AI.
	input handling
	graphics (images, not code)
	levels
tools
	level editor

BTW: What about sound?

That's quite a lot of stuff. It will be much work and it will take long. On
the other hand it gives uns a very visible and practical "goal".
I personally tend towards making some demos first and step by step
design and implement the things listed above. For example a Bouncing
Penguin as Sprite demo etc.
We can take the above list as our main TODO: the things needed for a simple
game. When we have that stuff (minus the platformgame-specifics) PPlay will
be really useful.


	Christian

--

Drive A: not responding...Formatting C: instead