This is a summary of the "goal oriented game play" discussion
I initiated on the Airstrike
1. Airstrike levels
2. Airstrike level "incredients"
2.1 A goal
3. Gameplay types and player lives
4. To sustain player interest
5. See also
- Eero Tamminen
Airstrike has several things which can be used to implement Airstrike levels:
To be interesting, each of the levels should have the following elements:
The list is from the book associated with the "Game On" Art exhibition.
For deathmatch the goal would be to kill the other player (given number of times).
For co-operative mode, the goals could differ between each level. They could be moving or destroying objects. In later versions this could also including taking control of them or transferring them to somewhere else. Subgoals can be done by triggering other triggers.
For single player games the goal can also be to get points, to beat some highscore.
Obstacles are the other players, sprites that obstruct player's flying (either just by being inmovable or by following him) and things that directly or indirectly harm the player (e.g. missile vs. bonus that creates a missile aimed at player).
Resources are currently only fuel and bombs, but later on it could also be time (if there would be a time bonus that affects timer triggers), other kinds of weapons and better plane models.
Lack of an resource is also an obstacle.
Currently additional fuel can come from generators or bonuses, bombs come only from bonuses. There are additional "rewards" in form of other bonuses such as the one that clones the player sprite (on level 3) or generates harmless other sprites. "Reward" can be something like a visual or sound effect, or some kind of dynamics in the game (consider for example "Carmageddon", which basically is only fun because you can crash your car in a very elaborate way).
Another traditional reward is that the player can earn money for buying better weapons and aircraft (DOS "Scorched Earth" and Amiga/Atari "Supercars" are nice examples for this). For bying some kind of a "shop" (screen) is needed though.
Penalties can be added with triggers e.g. for destroying or approaching something or just being too late. For example, there can be a timer trigger that will activate a proximity trigger than will trigger a missile generator when player approaches a "goal" too late. There being more and more enemies is also a kind of a punishment.
Currently the game shows only information about level name, that bombs or fuel have ended and the reason for level ending, but there should be indications of the number of remaining lives, fuel, bombs and any cargo the sprite has.
The description for the level goal (end-condition) should also be shown at the level start, unless the goal is finding how to end the level.
Most interesting games are the ones that have an element of interaction with other players. Based on how players behave against each other the gameplay can be separated to three different types:
Number of lives player has are relevant only to the first two level types. Levels where players race against each other (goal: do N rounds through the level) would fit into both middle categories, but making fuel scarse enough would discourage players from fighting each other.
For example a level that works like the classic Breakout game would be in the friendly competition category, but without scoring it's rewards wouldn't be so obvious. If certain parts of the screen would be accessible only to one of the players, then it would be mandatory co-operation. Co-operation where other player(s) would need to be alert all the time, but wouldn't have anything to do most of the time, would be annoying. Therefore, all the players would need to have always something to do.
Airstrike doesn't (currently) support having different goals for different players. Players can be playing different sprites on a level though, this can make the mandatory co-operation more varied.
To sustain interest:
With the Ulf's new scripting support adding new levels is easy. Adding new objects is also quite easy to do with Povray, but some coding is needed for new (i.e. surprising) behaviour. Just adding an ogg file on repeat that can be specified per level should be quite trivial addition for background music, but performance-wise 'mod' files played with libmikmod would be even better.