Space Shooter, how to handle enemy waves

This topic is 2553 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

For my next Flash game, I plan on making a vertical shooter/shoot em up game. My idea for the game is pretty simple, with an interesting art style, but pretty typical in game play and features. However, one thing I have always wondered about, is how exactly do space shooters handle the enemy waves? Each unit generally has its own statistics that are static and generally attack in the same way, but the individual movement patterns and timing changes from level to level.

I was wondering, from peoples experience/thoughts how do games handle the waves of enemies exactly? Something like a "timeline" for each level, that places enemy emitters at certain locations at certain times (or events) with given parameters to adjust the movement of the emitted enemies? Because thats the best that I can come up with, unless someone has a better idea!

Thanks

Share on other sites
Yeah, a timeline structure would be good. Something like this:

var attack_timeline:Array = [ {duration:123, type:"wave",aliens:24} , {duration:43.2,type:"sweep",aliens:19} , {duration:12,type:"wave",aliens:12} ];

You could either store the duration of an attack before the next one or the time the attack would take place, or the distance travelled by the user where the attack would take place or a hotspot which would trigger an attack.

If you want to be especially jammy you could read this info in from an XML file.

Think about all the data that your game needs then think about how you would store it in arrays and structures and so forth. You could set up all these structures before you have even programmed anything!

In terms of programming the wave. You just assign the attack-type to the alien. Then the alien will follow a set time-line like you said depending on it's attack type.
e.g.
alien[25].attackmode = "wave"

Share on other sites
I'm working on something similar at the moment, so I'll give you an overview of what I'm doing so far. Hopefully it will help or give you some ideas. My level files are Lua scripts that get loaded and run by the game. The level script looks something like this:

 function run() setup() wave1() boss() wait("all_enemies_dead") local script2 = script("script2") wait("script_finished", script2) end local function setup() -- do some level specific setup stuff background{ type="scrolling", image="background0" } end local wave1() for i=1,10 do spawn{ type="Enemy0", path="path0", ... -- other args } wait("milli", 400) end end local boss() spawn { "boss0", x = 0, y = 0 } end 

When the wait() function is called, the script will halt until the condition specified is met. The script is entered by calling the run() function. Wave 1 will spawn 10 Enemy0 instances and wait 400 milliseconds between them. I've noticed you might want wait conditions other than time too. It might be useful to wait until all enemies have been killed (either by the player or from going off screen). That can be useful for boss fights, which typically last until either the player or boss is dead.

As you mentioned, each unit has its own behaviour and some properties that can be configured by the arguments passed to it when it's spawned (such as setting the path for it to follow).

In shmups, you'd often see the same enemy patterns come at you multiple times, so I have a way to start sub scripts (script2 above). This allows me to define waves that I can reuse multiple times. Sub scripts are the same thing as the main level script, and run in parallel with all other scripts (note: not actually concurrently, it's all single threaded. I loop over each active script and run it until it halts by issuing a wait command, The game will then only resume a script when its wait condition has been met).

You don't have to be using a scripting language either, the same concepts obviously apply if you load the data from XML or whatever you'd like to use.

Share on other sites
For my Shump, I basically had a stage configuration file that defined when the enemies would be released, and from what location. So, as the stage went along, the main loop would check the EnemiesOnStage list, and when the time hit the time to release an enemy, it would move that enemy to the OnScreen List, and begin to render and act on that enemy.

1. 1
2. 2
Rutin
22
3. 3
4. 4
JoeJ
16
5. 5

• 14
• 29
• 13
• 11
• 11
• Forum Statistics

• Total Topics
631775
• Total Posts
3002284
×