[airstrike] two player mode now working

[Eero Tamminen]

Hi,

> > What about the trigger thing I mentioned earlier?  Would it be another
> > parameter for spawn, or a separate thing completely?  In first case
> > trigger keyword argument could be the triggering distance and delay
> > could act as a rate limiter value.
>
> maybe
>
> trigger
> {
> 	x = 23
> 	y = 343
> 	radius = 50
> 	spawn{ .. }
> }

Sounds good! :-)

> But the we still have problems if we want to trigger only on some 
> sprite types..

I think that should be easy to add later on if it's needed.
I don't see need for that at the moment.


> > One possibility would be if the generator would keep the first
> > generated (when level file is read) object, the sprite struct would
> > have a new "clone" method (copy constructor if I still remember my C++
> > terminology :-)), and generator would then just clone the first copy
> > when it generates a new object.
>
> I don't like this so much, I would prefer that sprite_t is only for
> "live" sprites.

The clone thing could still be nice.  Some things could e.g. split up in
middle flight in response to messages from other objects. In message
handler they would just get impulses to different directions.


> I'll see if I can find a better solution. 
>
> > > ai1 = player1_ai
> > > ai2 = cpu_ai
> > >
> > > sprite{ type = biplane
> > > 	ai = ai1
> > > 	..
> > > }
> >
> > What about player names and number of players?  Would there be always
> > e.g. four players on screen and the rest would be computer players?
>
> Depends on the level I guess. We could add a parameter nr_players to the
> level section, and then the engine should set the ai's correspondingly,
> according to what the user chooses in-game?

On many games you can specify who starts from which starting position.

Maybe we could instead have:
	ai = {
		# which player / computer ai this is
		type = player1_ai
		# name is needed for the messages and high-score...
		name = "Red Baron"
		# this is generator count
		lives = 3
	}
	starting_position {
		x = XXX
		y = YYY
		vx = XXX
		vy = YYY
	}
?

The parser would add each instance of "ai" and "starting_position" to their
own lists. "ai" things would be generators.  On each respawn event they
would pick the current "starting position" and advance the "current" pointer
to next starting position.  Or if user wants planes to start always from the
same position, then the "ai" would pick a "starting position" with the same
index as it has ("fixed_starting_positions" variable could be used for
this).

When "ai" (re-)generates a new instance of a plane, it takes it's initial
position and speed from the starting position struct.

Hmm.  This way "ai" definitions could actually be completely separate from
the level specifications unless you want a possibility to change the number
of lives and player names per level.  :-)

	- Eero