   Shoot'em up Spawning technique
  Hello everyone,I am currently developing a small Shoot'em up game with xna. There is a player who goes upwards(at least it looks like it) all the time and then enemies comes down the screen and the player has to kill them(and evade). Pretty classic.I need a smart way to implement the spawning. I have as I see it two options.1. Have spawns(a group of enemies) that spawns after a certain elapsed time(they start outside the screen) and then moves with waypoints, around the screen until, if they are not killed, they exit the screenbounds.Disadvantage: The time, adding new spawns could be difficult to get precise.2. The second option is to have all the gameobjects(enemies) spawned from start, as the game progresses they all move (with waypoints) downwards, and as they enter the screenbounds they become visible. The big advantage would be that I could create a level-editor that scrolls in y axis, and position all the enemies, precicely where I want them.Disadvantage: Updating all the enemies position takes system resources, looping through all gamecomponents ....What do you think? Has anyone done this before and would like to share their techniques.Thank you for reading!   
  Here's the method I used for my shoot'em up a long time ago (Used DirectDraw at the time, to give you an idea how long ago it was).  It's basically a modified version of your second idea.I initially loaded all the enemies for the level into a queue in the order they would appear to the player as he advanced through the level.  Each enemy stored their 'trigger' point on the map, which was just a single X value, as the Y position of the player didn't affect when an enemy would appear on screen. It was a side scroller, not a top-down scroller, but that doesn't matter.Because they were ordered properly, I only ever checked the next enemy in the queue for spawning as the player advanced through the level.  When his trigger point was reached by the player, I pulled him out of the queue and into the active list of enemies.  This active list was what I used for gameplay activities.  None of the enemies sitting in the queue went through the AI or rendering loops.  The active list was rarely more than a dozen or so enemies in size at any given time.As long as you separate your graphics/models from your enemy instances, this should pose no memory issues.  IE if you have a dozen enemies in your level that all use the same graphic/model, you should only load that graphic/model once.  Each enemy should just point to the graphic/model they use.   ;Quote:Original post by Raskell Great info! I use a spritesheet for all the enemies, thus only a sourcerectangle differ one enemy graphic object fron another.I'l look into the queue idea, seems brilliant.Ill have to change the trigger Y value to something else though, sort of the same thing but since the player can move in that direction but your point is good. Ill just have to have another counter for how far "up" on the map that the player has moved.   ;  Im developing a shooter too, I'm using while loops to init the data.  I dont want to bore anyone with the code too much but heres a couple or two a ideas for the data:Now I need some code for beziers...[Edited by - BadgerManufactureInc on June 27, 2009 3:27:11 PM];  I have just started a thread on this too, check it out if you like.   ;Quote:Original post by Todilo1. Have spawns(a group of enemies) that spawns after a certain elapsed time(they start outside the screen) and then moves with waypoints, around the screen until, if they are not killed, they exit the screenbounds.That's how I did it. I stored instances of an EnemySpawn class, that contained the spawning time, location, enemy type, speed, and the waypoints it should follow.Quote:Disadvantage: The time, adding new spawns could be difficult to get precise.Build in fast-forward functionality so you can quickly test later waves. I never did this so testing a full level was a chore. And that will result in lower quality level ends.Quote:2. The second option is to have all the gameobjects(enemies) spawned from start, as the game progresses they all move (with waypoints) downwards, and as they enter the screenbounds they become visible. The big advantage would be that I could create a level-editor that scrolls in y axis, and position all the enemies, precicely where I want them.This approach is more or less the same as your first idea. The difference is this: the first approach stores only a minimum of data, and 'inflates' to a real enemy when it's time has come. This approach already stores the full enemy. After all, you can write an editor and place enemy spawn-points, as if they were enemies, just as well.I do recommend writing an editor, especially if you intend to add lots of enemies. Writing spawn data by hand is tedious and requires a lot of testing. ;)Checking only the first instance in the spawn queue is a good idea. Be sure to check the next also if the first has reached it's spawn time - the next one might need to be spawned at the same time.EDIT: You could embed the editor into the game itself, as a sort of edit-mode. That could save you some time from writing a full-fledged separate program.[Edited by - Captain P on June 27, 2009 3:21:30 AM];  Just a quick thought, but if you want to have your level editor (as well as prespawn all enemies) you could have a range in which only then do enemies get processed by the engine.Then have your level editor keep them in an array sorted based on which enemies should be approached first. Then you keep track, say the first 10 have already been signaled as enemies within range to start processing, you only need to check if the 11th is within that range, if so start checking up until you find an enemy out of range, and add all the ones before that one to the ones which should be getting processed.Interesting way to do it and save performance, let me know how it goes if you end up trying this :)   ;  @Captain P Quote:I never did this so testing a full level was a chore. And that will result in lower quality level ends.@rcookQuote:Just a quick thought, but if you want to have your level editor (as well as prespawn all enemies) you could have a range in which only then do enemies get processed by the engine.It's much simpler than you seem to think: all you need is a variable that freezes a wave type creation if it's mid-animation or recently created:   while(wave_type_'x'_is_animating)   {freeze_creation_of_wave_type_+'x'+for_animation=1;}   if freeze_creation_of_wave_type_+'x'+for_animation==1   {dont create_another_wave_of_type_'x';};  @BadgerManufactureInc: can you explain more clearly? Both your post and your example code are rather unclear imho. I don't see how your wave freezing is a solution to easily testing later waves...Either way, now that I think about it, it's not too bad to just create all enemies up-front. The more expensive resources (sprites) would be shared between them anyway so the actual enemy instances probably won't consume much memory.   ;  You should have a branch of code that creates the data on the fly if you want to have random elements to their attack, which you may not want. However that doesnt mean that you cant make them consistent if you make them on the fly.On the fly:-Easier to make random if wanted-Can be make consistent ie predictable spawningLevel editor:-Easier to visualise at first-Can be make consistent ie predictable spawningmy alien data array will have 10 waves max ie 100 aliens or similar.[Edited by - BadgerManufactureInc on June 28, 2009 6:54:09 PM]