[airstrike] Airstrike levels and goal oriented game-play

[Eero Tamminen]

Hi,

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.
> >
> > This is not so simple because of the way how Airstrike currently works.
>
> I know. That's the reason I didn't implement it in february.
>
> > This is from a mail last summer:
> >
> > On Sunday 14 August 2005 23:16, Ulf Ekström wrote:
> > > > 6) Currently game shows only information about level name, that
> > > > bombs or fuel have ended and reason for level ending, but there
> > > > should be indications about score and number of remaining lives,
> > > > fuel and bombs. (The tricky thing about adding these is that player
> > > > is an AI object, but it's biplane sprite that has these
> > > > properties...)
> > >
> > > Don't we also have some kind of "player" object?
> >
> > Yes, but number of "lives" is not associated with the "player", but the
> > generator generating the corresponding sprite types.  After player
> > generator has re-generated the indicated sprite-type given number of
> > times, it marks the player dead and stops.
> >
> > I mean:
> > - Player name and AI are stored with the "player" object
> > - Spritetype and number of sprites ("lives") for the *current level* is
> >   associated with the co. player generator.  The generator asks player
> >   object to set AI for the generated sprite
> > - Count of bombs and fuel are stored to the generated sprite
> > As a result:
> > - Sprite doesn't know about generator nor player
> > - Generator knows about player and the sprite
> > - Player knows about the AI and could know about the sprite
> >   (through AI setting)
> > - AI doesn't know about player or generator
> >
> > So, I don't know how to deal with showing "lives".  There would also
> > need to be an additional API to retrieve the information about bombs
> > and fuel from any sprite that player could control.
> >
> > Scores would also be problematic.  E.g. if bullet does something,
> > there's nothing linking the bullet hit back to AI or player object.
> >
> >
> > Comments?
>
> 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.


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

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?


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

There are actually three gameplay types:
1. Deathmatch: Both the goal and main challenge is surviving against
   the other 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
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.

I added notes about these to the www-page.


> What actions are to be rewarded with points? 
> And how many of them? A killed enemy could be worth 1 point or every
> hitpoint lost could be counted towards the score of the adversary.

Lets have only damage points, those can be delivered directly from one
friendly sprite to another. :-)

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


> All in all we need to decide how the game should work and then we can
> start implementing this. This does include rewriting what does not fit
> with the then decided way.

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

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


	- Eero