[airstrike] Airstrike levels and goal oriented game-play

[Erik Auerswald]

Hi,

On Tue, Aug 01, 2006 at 08:36:37PM +0300, Eero Tamminen wrote:
> On Tuesday 01 August 2006 19:06, Erik Auerswald wrote:
> > > On Tuesday 01 August 2006 16:00, Erik Auerswald wrote:
> > > > All the other points need to be addressed in some way. IMHO the
> > > > logical next step would be to add ingame info on fuel, lives, bombs
> > > > and score.
> > >
> > Every biplane could have it's own set of bombs, fuel and damage
> > displays (the same way a missile has a target lock indicator).
> > Depending on the AI (player 1 or 2) the displays could be on the
> > left or right of the screen. Additional displays (from cloned biplanes) 
> > could be stacked on top and fall down whenever a biplane with gauges
> > below dies.
> 
> Airstrike supports upto 4 players, so maybe the displays need to be
> in each corner of the screen, but otherwise sounds good.

Is airstrike supposed to support 4 human players?

> > That would be a start. For lives and score more needs to be done.
> 
> I don't think scores make so much sense in the game:
> - there's already quite a bit of stuff shown on screen without the score
> - tracking which player initiated something giving scores is really hard
> - I like concrete goals more than score
> I'd like Airstrike to be so much fun that the main thing getting people
> (back) to it wouldn't be beating their and others old scores. :-)

I agree that we don't need scores, I just did not want it to be
forgotten and it's mentioned in the todo list.

> Doing lives is easy.  Just change player_generator_message() to call
> something updating the lives count on screen whenever the count changes.
> I'm not sure whether lives should be shown as a number or just suitable
> number of co. sprites.  How do you show infinite number of lives for levels
> where lives are irrelevant to the level goals?

I'd say use small plane sprites to show the number of lives. The current
live should be represented by a sprite as well, infinite lives could be
represented by displaying no plane-lives sprite.

> > Shall every level define the number of initial lives (as is done now)?
> > Shall a player start the game with a set number of lives that is not
> > replenished at level start?
> 
> Hm.  Currently each of the levels can have *very* different goals, the
> engine would allow implementing e.g. something like Breakout game as one
> of the levels.
> 
> Lives make most sense in deathmatch levels, on levels with other goals
> lives can be irrelevant.  For example level could be such that the main
> obstacle for reaching the level goal is amount of fuel.   Then the number
> of lives is irrelevant to attaining the level goal and it can be ignored.

I'm fine with lives associated to the current level.

> There are actually three gameplay types:
> 1. Deathmatch: Both the goal and main challenge is surviving against
>    the other player

Here the "frag limit" could be represented by the number of lives left
for each player.

> 2. Hostile competition: the goal is not related to the other player(s), but
>    the main challenge comes from them, they shoot and obstruct you

Every player has a different goal to complete the level? After
completing his goal by one player what happens? I don't quite understand
the gameplay of this.

> 3. Friendly competition: Both the goal and main challenge are not
>    related to other players.  These levels work also as single player
>    levels
> 
> Lives are relevant only to the first two level types.  Race like levels
> (goal: do N rounds through the level) would fit both into types 2&3, but
> making fuel scarse enough would discourage players from fighting each other.
> Breakout level would probably be type 3.

This seems OK.

> Btw. At the level start, the level goal should be also displayed
> even if it's just "find how to end the level".

Yes, this needs to be done. Maybe the next thing to implement are
multiline messages?

> If we disregard the scores, showing the player sprite properties is the
> hardest thing.
> 
> The AIs can in principle be transferred from one sprite to another, but
> tying this to the AI (name) like you suggested above gets around this issue. 

The problem is the clone bonus, because it can result in several
biplanes controlled by one player (and the player may choose to keep the
new plane as the old one was damaged).

Bombs, fuel and damage are properties of the sprite, not the AI.
Tying the display to the AI is only used so that the player knows what
displays are his.

> Whenever a state  (relevant to the user) of a sprite controlled by an AI
> changes,  it can call an API like:
>   set_info(const char *ai_name, int fuel, int damage, info);
> 
> Where "info" is either a callback for showing the sprite payload, or
> a list of images to show as payload.
> 
> The show_payload_cb() callback would be called with co-ordinates for
> a payload gfx the sprite will output on screen.  Either:
> - the gfx size is pre-determined and the callback is called
>   (with successive co-ordinates that are wrapped if there are too many items
>   to fit into a row) until it returns e.g. zero, or
> - the callback outputs all the items the sprite has as it's payload

Yeah, something like this has to be done.

> Note that it was though that later on the sprites player controls could also
> pick up stuff and drop it somewhere (think of "spacetaxi" or "paperboy"),
> so this would need at some point be able to show arbitrary objects the 
> sprite "has".

I'd say for any arbitrary object in the game there should be a small
sprite to represent the object in the HUD. A plane carrying an object
would display the small image next to it's stats.

Erik