Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm working on a top-down shooter akin to DoDonPachi, Ikaruga, etc. The camera movement through the world is handled automatically with the player able to move inside of the camera's visible region.

Along the way, enemies are scripted to spawn at particular points along the path. While this sounds straightforward, I could see two ways to define these points:

  1. Camera's position: 'trigger' spawning as the camera passes by the points
  2. Time along path: "30 seconds in, spawn 2 enemies"

In both cases, the camera-relative positions would be defined as well as the behavior of the enemy.

The way I see it, the way you define these points will directly affect how the 'level editor', or what have you, will work.

Would there be any benefits of one approach over the other?

share|improve this question
up vote 7 down vote accepted

I would suggest placing the spawn positions actually ON the background map as nodes that are visible from some sort of map editor. You can represent a shmup spawn with two variables:

  1. Position they are first visible from, which is best visualized as a point
  2. Distance from bottom screen when you should spawn them.

Then you can visualize the distance from bottom of screen as a vertical line pointing downward from the spawn node (which could be visualied as a greyed out version of the enemy or some such). When the bottom of the screen touches that line it will spawn. This allows you to do all of enemy editing completely in some sort of visual editor, and give you an overview of the entire flow of the game.

share|improve this answer
Re 2) Of course, at export you'd have to reverse code this (ie per row, what spawn points should become active, as with this system you need to be aware of some spawn points before they become visible. A detail though, this is indeed the most logical way. – Kaj Aug 13 '10 at 23:44
As a note, make sure you're using an editor that lets you easily shift nodes in bulk. When setting up your shmup level you'll be inserting and removing enemies, and constantly tweaking timings in the middle of your level, and having to shift all your entities one at a time will kill you. – ZorbaTHut Aug 14 '10 at 0:42
I love this idea as it'll really make the editing a whole lot easier, which is always a plus – Chris Waters Aug 14 '10 at 4:22

Just a though, the camera's position to spawn would probably be more flexible since you could modify the path without having to worry about a large domino effect.

If you go with time spawns then it will be a huge pain to add or remove path because you will have to modify a lot of enemy spawns.

Another issue I see is tweaking the camera speed. Do you really want to go and have to tweak enemy spawns just because you've made the camera move a little faster or slower? Plus you would need to play through the level a horrible amount of times just to find spawn times or tweaks for them.

share|improve this answer

I'd strongly recommend not moving "the camera" at all; consider the player and enemies in the same fixed coordinate space at all times. Enemies and background scrolling should both be matched to an independent timeline. It makes all the math easier.

share|improve this answer
I half agree with you. Definately shmup physics are fake and based on the ship not actually moving forward. That said, the question is still valid as you do have a camera etc to consider – Iain Aug 15 '10 at 20:44
Indeed, it doesn't invalidate the question. It's still time versus (virtual) distance travelled. Whether you move the player forward or the background backward is merely a conceptual layer. Besides, decoupling them to make the math easier can make other things much harder, such as putting enemies in the background (turrets), having them avoid background objects, or having collidables in the background. – Kaj Sep 5 '10 at 5:18

I'd go for camera position. Using time will make it rather hard if you want to have an enemy path match up with some graphics in your map file (like enemies following a curved path). Also it allows you to speed up the scroll without changing spawnpoints.
The flipside is that speeding up the scroll will make enemies come faster. Which could be considered a plus (speedup would be difficulty up) or a negative (scroll speed influences pacing).

share|improve this answer

I am also working on a space shooter game. What i did is I used an empty gameobject called GameController. added a script component called GameController.cs which is controlling the spawning part like,

  • Store a list of spawning points [array]
  • Give each enemy a specific weight and points. weight controlling enemy spawning rate if an enemy has high weight got good possibility to pick in each level.
  • Then each time check Current level and Choice a random number, if number is less then weight, spawn that associate enemy. I hope it helped.

share|improve this answer

I would place them on the large map background and include their initial movement path on that map. That way I could change the camera path later in a meaningful way instead of needing to change both path and the timing separately.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.