Asteroids-style screen transitioning
Author
Apologies for the vague title, as I couldn't think of a better way to describe it. I'm also sorry if I posted this in the wrong forum.
I'm currently planning to create a game that makes use of a type of screen scrolling similar to that of Asteroids. This is an entirely new area for me to explore, and while I think I have a very basic idea of how to do it, I would love some input from more experienced developers.
To explain how exactly I'm picturing my game layout to be, I've included some lame MS Paint illustrations.
http://i47.tinypic.com/wlw49j.png
The blue triangle represents the player ship, while the red circles are enemies. The portion of the game area that's currently displayed is marked with a black rectangle. As the player ship moves around, the screen will follow it due to the full area size being larger than what the screen covers. This is simple enough for me to handle, but this is where it gets a bit tricky for me.
http://i50.tinypic.com/15f0scn.png
When the screen rectangle's coverage exceeds that of the complete area, it's supposed to kind of loop to the opposite side, so you get the illusion of a repeating world. This holds true for both the X and the Y axis, so in the worst case scenario, the screen will cover all 4 corners.
In addition, as I've attempted to display in the picture above, the enemy chooses the path closest to the player when attempting to fire at them, even if the player ship is technically on the other side of the screen. This part I'm basically lost on how to do, so I'm happy for any kind of help/feedback on the matter.
I'm developing this using C#, but any non-code related theory on the matter is very welcome.
Many thanks in advance for any help that may be provided. :)
I am assuming you are writing the engine from scratch. Off the top of my head I would think your could simply use the mod operator to determine what portion(s) of the background to draw. This assumes you are drawing/filling at the pixel level.
Alternatively, you could just use addition and subtraction and calculate how/where the window is outside of the world coordinates. Then simply build the window from these 'chunks'. Assuming you are using some sort of image class that can clip or extract regions. i.e. The window is built by extracting regions from a background image.
I think if I were going to design this I would write it where the window or player is always at the origin. Then I would simply translate the background to simulate motion. In the translation routine I would 'wrap' the world so as to make the world seem infinite. Or you could map the background image onto a sphere. Then you just spin the sphere.... probably overkill.
Anyway... just some ideas off the top of my head. I am sure someone else will have a better solution.
Quote:Original post by skauert
In addition, as I've attempted to display in the picture above, the enemy chooses the path closest to the player when attempting to fire at them, even if the player ship is technically on the other side of the screen. This part I'm basically lost on how to do, so I'm happy for any kind of help/feedback on the matter.
Decouple the coordinate system from the world (background). Make the player at the origin. This way you can use a vector to point at the origin (enemy). Once they get within a certain range they can fire (i.e. within +/- of the origin). You will still have to worry about numerical bounds for enemy's. A mod operation can take care of this. e.g. pos.x = (pos.x + vel.x * t) % world.x.
Now if the world is not infinite, and it truly wraps around (like a sphere or cylinder), then once an enemy reaches a bound simply wrap it around (At this point it will be out of view).
Author
What you've written makes sense. As this is my first time making something like this, I'll probably have to spend some time experimenting with how I'm going to base my engine around it. The sphere sounds like a really cool idea, but I don't know if it's possible to do with windows forms alone, as I'm not implementing this with DX/OGL. I'll probably either make a background that works well for looping, or have a black background and just dynamically generate background objects/particles, since I plan for the game to take place in outer space.
This will probably get me very far. Thanks a lot, smc. :)
EDIT: Oh, and just out of curiosity, what does the 't' variable represent in your movement algorithm?
This will probably get me very far. Thanks a lot, smc. :)
EDIT: Oh, and just out of curiosity, what does the 't' variable represent in your movement algorithm?
I would recommend contacting the author of Jumpman http://runhello.com/, since some levels feature the same sort of wrapping-world where you can see it repeating onscreen.. also if you do lean how it's done, please post as I'd love to know :)
Quote:Original post by skauert
EDIT: Oh, and just out of curiosity, what does the 't' variable represent in your movement algorithm?
t = time. I am assuming you are using position/velocity/acceleration based on time.
pos.x = (pos.x + vel.x * t) % world.x
There are other faster ways to do this, but this is simple and will not effect the performance of a simple 2d game.
Another idea for your background is to render using a tile map. Here is an example in words.
Let your window be 640x480. Create a background texture of the same size. Slice this into individual images of 32x32 or something similar. Now imagine you move your ship up. you could start rendering the bottom tiles on the top. Additionally, if this is a space image with only stars then you could randomize the ordering to get a nice variation. i.e. to remove obvious repetition. You could use a bigger image as well. If you use this method it may be easier to just embed the ship into world coordinates.
You could do the sphere, but it is more complex then it needs to be. Try and think how you can decouple the actual rendering engine from the display technology. Do this as far as you can in your rendering pipline. At the end you should be able to transform the output of your rendering engine to the actual display tech... i.e. a windows form in your case.
Keep it simple, expand on the idea after....
Have fun!
One thing I found useful when doing Asteroids is a "shadower" approach, where for an entity you consider it at multiple locations. If your world is, say, 640x480 and wraps round, and an item is at (320, 240), it's also valid to think of it as being at (-320, 240), or (960, 240); at the locations with plus or minus world width from the x position, and plus or minus world height from the y. Then, if you want to find the shortest direction to the player, you look for the shortest direction to any of the player's shadows.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
