Welcome, Guest. Please Login or Register.  • Help
SMF Underground
+ SHMUP-DEV » SHMUP DEV FORUMS » Assistance
|-+ world or screen?

Pages: [1]   Go Down
0 Members and 1 Guest are viewing this topic. Topic Tools  
Read April 12, 2012, 04:38:40 PM #0
Apt Pupil

world or screen?

Hi there, LTRFTP

So I'm making a horizontal shooter in XNA. I'm using tiledLib for my game world and the Tiled Map Editor for level editing and enemy placements. There's a camera that scrolls through the level, and all game objects undergo a "world-to-screen" transformation in the draw method (object worldlocation - Camera.Position).

So here's what I don't understand: when I watch playthroughs of something like Blazing Star, it looks a lot like airborne entities are bound-to-screen, whereas ground-based enemies seem to be bound-to-world. I say that because players have absolutely no control over the camera, and its Y-axis almost never changes while airborne enemies are around.

Then I watch a ThunderForce IV playback and players seem to have frequent control of vertical camera scrolling - only airborne enemies are still being dealt with in world co-ordinates, simply because they go in and out of view with the rest of the "world".

So basically, I have two questions:

1. Should I handle ground-based and airborne entity co-ordinates differently? Should they be handled in world and screen co-ordinates respectively?

2. If everything should be in world co-ords, what's the best approach to giving them movement patterns?

I'll be honest: I'd love to deal entirely in world co-ordinates for all my game entities, but when it comes to feeding airborne enemies spline info in world coords, I just can't get my head around it. Not so much the theory, "send enemy in this direction for this duration" seems fine, in principle - but literally everything I've seen tutorial-wise deals with these things in terms of screen co-ords, which doesn't help, and the same applies for applying catmull-rom.

Programming isn't my strongest suit, and I've avoided asking for help up to this point, but I really feel like I've hit a brick wall. Any help or advice you could offer would be greatly appreciated.

Thanks for reading.

P.S. apologies for lengthy post
Offline  
Read April 13, 2012, 11:31:55 AM #1
LorenzoGatti

Re: world or screen?

In your game, if I understand correctly, everything is in world coordinates and you convert to screen coordinates for rendering purposes with a translation by the camera position: it is a sound and consistent design choice, especially considering that your level editor likes world coordinates.

1a) Airborne entities fly around in world coordinates, ground entities remain still.
There's no fundamental difference between initiating, as soon as the starting location approaches the player or the camera, behaviours of "fly forward in a wavy up and down pattern and exit the stage shooting forward" (each starship in a formation) and "turn towards the player while shooting aimed" (a fixed artillery piece).
1b) You have to move entities in world coordinates, but you also have screen coordinates (more precisely, position relative to screen borders and screen center) at your disposal: reference what makes sense and avoid making assumptions about camera movements (other than balancing movement speeds against normal scrolling speed, of course).
For example, a fixed movement path can be defined according to its own relative coordinates and instanced in absolute world coordinates, while circling the borders of the screen needs to look at border positions.
2a) Camera scrolling is not entity movement; nothing is actually "bound to screen" or "bound to world". Controlled or scripted scrolling is merely a special effect. I see no significant difference between Blazing Star and Thunder Force IV: both games have large levels with enemies that materialize when the player (or the screen) approaches them, with some scripted slower, faster or non-scrolling sections.
2b) The difference between scrolling the screen at a fixed speed, letting the player move freely but pushing him towards the middle if it would exit the viewport, and forcing a minimum "forward" player speed and having the view follow the player, is usually unimportant.
Fixed longitudinal scrolling, to maintain an even speed, and player-controlled transversal scrolling, to extend the playfield beyond the viewport's size, is a common combination.
Offline  
Pages: [1]   Go Up
Jump to:  

Page created in 0.148 seconds with 18 queries.