2D shooter (ikaruga, etc... alike) are really played in screenspace?

Sorry if this is a dumb question, but I'm starting a space shoot'em up like ikaruga, etc... and have noticed that bullets, player, enemies do not move with scroll. Are this type of games representing everything in screen space?.

I mean, you can have an scrolling/rotating environment in the background, but are collisions, etc... just in screen space?.

Based on this, what do you think about this game flow:

1) Player is in screen coordinates 2) Enemies are world coordinates until they are awaken, at this point they are converted to screen coordinates (just using the current world scrolll position). 3) Enemy and player bullets are screen coordinates. 4) If we had obstacles in the world (say for example in a 2D game we have some tiles that represent obstacles) we would have to convert bullets, enemies, player to world to check collisions against the map.

Advantages: - Everything that moves is screen space, easy to check collisions among dinamic entities, etc...

Disadvantages: - We have to convert every entity into W开发者_运维问答orld coordinates to check against obstacles.

The other way around would be to have everything in world, and move player (starship), bullets, etc... by the same amount scroll moved and apply its own velocity.

Advantages: -Everything is screen space map/entities, so no conversion is needed.

Disadvantages: -We have to iterate through every entity to apply a fix to its position based on the scroll velocity to simulate things in screen space.

What do you think it is best solution?. I'm implementing first one right now.

Thanks in advance, hexDump.

I would stay away from using two different tracking systems. It would become a headache very quickly if you wanted to have obstacle intercept bullets/enemies.

When I setup my scroller I had a separate array for the bullets that I kept apart from standard game objects so that I could update each array with the necessary information. I kept my bullets in world space but had I wanted to appear to be in screen space I would simply not pass the world players movement transform into their update.

I would recommend an approach like this, keep similar objects grouped and tell then to react to different stimulis rather than keeping them in two different worlds and leaving it your subsystems (collision, rendering) to deal with those problems. Because you'll end up writing 2 version of every function in the subsystems.