[airstrike] Airstrike levels and goal oriented game-play

[Eero Tamminen]

Hi,

On Wednesday 02 August 2006 11:52, Erik Auerswald wrote:
> > > 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?

Well, at least player object and main() do that.  However, currently
there seem to be only "player 1" and "player 2" AIs (sets of keys),
so the support is not complete.  Adding "player 3" and "player 4"
AIs would be trivial though.

Now the question is should Airstrike support 1-2 or 1-4 players?
Ulf?


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

For single player levels scores could be implemented easier as then
everything giving scores can be added together and shown as one item
on screen.  Some computer AI actions could then also increase the score,
but I don't think that's a problem for the (single) player. :-)


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

Sounds good to me.  I think for practical purposes >5 lives could be shown
as many/infinite lives.  (if the number of lives gets down to 5, then they
can be shown with separate sprites again)


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

I meant that althought the challenge in the level (is supposed to) come from 
the other players (shooting / crashing into you), the goal is designed so
that neither killing the other player(s) nor co-operation between them is
needed to achieve the goal.

The goal is the same for each players (e.g. do N laps around the level).


> > 3. Friendly competition: Both the goal and main challenge are not
> >    related to other players.  These levels work also as single player
> >    levels

Btw. E.g. collecting or shooting items from the screen would fall to
co-operation gameplay type as triggers can notice only that something
disappeared, not who was responsible.


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

The goal should be shown at the same time as level name, maybe in
smaller font.  Level "description" keyword would suit for this best I
think.  This description could be shown in level selector also if we
get something like that later on.


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

All sprites that player can control (e.g. biplane) have AI property
(set with the MSG_SET_AI message), so I don't think this is a problem.

Because different sprites can have different items to display, this
needs anyway some sprite specific code.


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

This can be added later (v1.1?) when planes can carry something.
I think having even the fuel, damage and bombs would enough for
starters.

(unfortunately I don't have yet time for coding on Airstrike, but discussion
doesn't take much time...)


	- Eero