2d top-down shooter game design question

[paul_nicholls]

Hi all,
I have a top-down 2d shooter game in mind where you fly around an 'arena' in a small ship as a member of 1 team vs 1 or more other teams (single player and possibly multi-player).

I am wondering which way to go with regards to displaying and controlling the user's ship.

As far as I can see, I have two options:


1. the user's ship stays still and the arena rotating/translating around it.
2. the user's ship rotates/translates around and the arena stays still.

Version 1. could be much easier to control the ship, but more programming would be involved (rotating/translating the arena around the ship), and I'm not sure if there is a chance the user may feel sick due to all the rotation/translating happening around them.

Version 2. would be easier to program - I could just have the arena made up of run-of-the-mill tiles and not have to rotate them, etc. But the user's ship would be harder to control in my mind, especially compared to the AI ships (they would make decisions relative to their heading like in version 1.).

Any ideas/hints/tips, etc. would be great :-)
cheers,
Paul

[Andreaz]

Another benefit with the #1 is that you can have a much larger arena, and i would go with this one.

If you use a 3d api for you'r 2D graphics you will get the rotating and translating for free with only a few lines of code.

You can do some nice zooming depending on the ship velocity aswell, this will make it easier to fly around.

[JSoftware]

What about translating the arena around and rotating the ship, ala GTA?

[paul_nicholls]

@Andreaz: I'm not sure why #1 would allow me to have a much larger arena, but it would allow the user to 'strafe' left/right more intuitively as well as move forwards and rotate more easily.

@JSoftware: isn't GTA a 3d game? would you have a screenshot of a 2d version or similar? If I went for #2, I think it would be much harder to control things like strafing, etc. and the user may get confused.

As you may have noticed, I'm starting to think that I should go for #1, mainly due to control concerns, but more opinions wouldn't hurt :)

So fire away people ;-)
cheers,
Paul

[User137]

Hi all,
I have a top-down 2d shooter game in mind where you fly around an 'arena' in a small ship as a member of 1 team vs 1 or more other teams (single player and possibly multi-player).

I am wondering which way to go with regards to displaying and controlling the user's ship.

As far as I can see, I have two options:


1. the user's ship stays still and the arena rotating/translating around it.
2. the user's ship rotates/translates around and the arena stays still.

Version 1. could be much easier to control the ship, but more programming would be involved (rotating/translating the arena around the ship), and I'm not sure if there is a chance the user may feel sick due to all the rotation/translating happening around them.

Version 2. would be easier to program - I could just have the arena made up of run-of-the-mill tiles and not have to rotate them, etc. But the user's ship would be harder to control in my mind, especially compared to the AI ships (they would make decisions relative to their heading like in version 1.).

Any ideas/hints/tips, etc. would be great :-)
cheers,
Paul
1.Yes, player's head will very likely get dizzy. Having the view a little more like camera that follows the ship just a little behind and smoother may help the issue. Technically, if you implement this with OpenGL (or maybe almost same with directx), there is no real difference in rendering. The smooth camera turning is hard. Sine/Cosine function with delta angle may come handy but is it enough?

2.Having world to not rotate is what i really recommend. It's the most clear approach, and in reality is much easier to control for player.

[Andreaz]

@Andreaz: I'm not sure why #1 would allow me to have a much larger arena, but it would allow the user to 'strafe' left/right more intuitively as well as move forwards and rotate more easily.

So fire away people ;-)
cheers,
Paul

Well basically as if the arena should not move, you are limited to what can fit on one display. But if you are scrolling the arena (meaning the camera have to zoom on the player) you can have a basicly endless playing field.

[tpascal]

If your game is tiled 2d and if the arena is several more than one screen in sizes which needs to be scrolled then i would use option #1, so the user ship can always be seen centered in the monitor and will have enough space around to see what is going on.

If the arena is just one screen size so it can be stand still then of course you have to move the ships.

If you are using a 3d api for doing 2d, that is using camera "eye" position, camera "At" position, and matrices for translate/rotate your "world" or your "ships" then i guess you are asking what you rotate/translate, the world or the ships?, visually they look exactly the same, and the math are basically the same too, but i think it is more intuitive if you have the world stand still, move all ships positions coordinates, and move the camera allways looking the user´s ship centered on top looking down so it is seen centered in the monitor.

Remember, in 3d apis the final scene seen depend of the world coordinates, the ships coordinates, the camera position and the camera lookat position, so even if you traslate/rotate the user ship but if you also translate/rotate the camera with same values always looking to the ship then it will look like the user ship dosent move and everithing else around move.


good look.


Tp.

[User137]

I recommend trying Subspace Continuum (yes it's been completely free for maybe 10 years)
http://www.subspacedownloads.com/
if you'd like to see a multiplayer game like this done in #2 way. I cannot imagine liking that at all if tiles rotated and player ship stood still.. it's just a call for headache and i've tried it with Delphi very long time ago and it was really hard to aim to fire. Rotating world is fine with fps perspective but top down.. no no.

Basically if the world around the ship rotates, you lose focus on enemies speed, position and direction.

[paul_nicholls]

@Andreaz: I am planning on having the arena larger than the screen so the camera will always be above the player's ship (in version #1 and #2) and the arena scrolling when necessary.


@tpascal: I was not planning on using a 3d api to do the 2d graphics - I am hoping to get the game to run on the GP2X handheld console as well (doesn't have OpenGL, etc.).

I know this may limit me somewhat with graphics quality (using a SDL software renderer), but on the 320x240 3.5" screen you shouldn't notice much. If I was going for a PC only version, then I would use OpenGL under SDL to make my life easier.

When I am talking about what to rotate/translate - the ship, or the arena, I mean that in version #1, the ship would be in the center of the screen, and not apear to move or rotate, but the area would move and rotate around the ship.

@User137: I just had a look at screenshot of Subspace Continuum and read the game play (http://www.subspacedownloads.com/index.php?act=what_is) - the powerball zone sounds very very similar to what I was going to make, and I had never heard of the game before!!! LOL!

cheers,
Paul

[tpascal]

When I am talking about what to rotate/translate - the ship, or the arena, I mean that in version #1, the ship would be in the center of the screen, and not apear to move or rotate, but the area would move and rotate around the ship.


Then yes, use option #1, almost all 2d scroll side type game i have seen does that, the player is cenetered in the monitor and the world scrolls, except when the player arrive to the world limits.

Note that even when the user ship most the time will be phisically draw at 160,120 in the monitor you still need to keep your ship coordinates in the world, and have to be updated as it is "moving" in the virtual world, those coordinates are used for colision with enemies ships and everithing else you normally do as if the ships is moving, so dont worry about the maths, it is exactly the same in both option #1 and #2, just in option #1 you use the user´s ship world coordinate to calc which part of the arena to draw.

good luck.

tp.

[paul_nicholls]

When I am talking about what to rotate/translate - the ship, or the arena, I mean that in version #1, the ship would be in the center of the screen, and not apear to move or rotate, but the area would move and rotate around the ship.


Then yes, use option #1, almost all 2d scroll side type game i have seen does that, the player is cenetered in the monitor and the world scrolls, except when the player arrive to the world limits.

Note that even when the user ship most the time will be phisically draw at 160,120 in the monitor you still need to keep your ship coordinates in the world, and have to be updated as it is "moving" in the virtual world, those coordinates are used for colision with enemies ships and everithing else you normally do as if the ships is moving, so dont worry about the maths, it is exactly the same in both option #1 and #2, just in option #1 you use the user´s ship world coordinate to calc which part of the arena to draw.

good luck.

tp.

Sorry if I wasn't quite clear enough, but the game isn't a side scroller, but a 360 degree scrolling 2d top view, and with #1, the arena would rotate/translate around the user's ship, with the user's ship appearing to not move in the view port. Not sure if this affects what you wrote :-)

With #2, the ship would rotate and move around the non-rotating arena (like Subspace Continuum I'm assuming - not played it yet), and the camera would be centered around the user's ship so the arena translates around the ship in the view port.

cheers,
Paul

[Ñuño Martínez]

@JSoftware: isn't GTA a 3d game? would you have a screenshot of a 2d version or similar? If I went for #2, I think it would be much harder to control things like strafing, etc. and the user may get confused. The first two GTA were 2D. Another game that uses a similar game arena are the Diablo series (at least the two first ones) and the classic Bitmap Brother's Xenon (only the first one).

[paul_nicholls]

Thanks everyone, I will try and whip up a prototype example of a controllable ship that can fly around a map, and you will be able to set either of the two 'modes' #1, or #2 to try it out.

I am looking forward to seeing which way you prefer for real :)

cheers,
Paul

[cronodragon]

In Sins of a Solar Empire, the ships move and rotate around the arena (a gravitational well). You can rotate the arena clicking on it and moving the mouse, and when you hover on a ship, it is centered and the mode is changed to an arena that moves around it, to return to the other mode you just click on the arena again. It's a cool system to track space ships.

Another feature is that you can zoom in/out the ships. When the camera gets too far, the units are shown as icons. When the zoom is nearer the ships are actual 3D models. You should give it a try to get some nice ideas.

[paul_nicholls]

In Sins of a Solar Empire, the ships move and rotate around the arena (a gravitational well). You can rotate the arena clicking on it and moving the mouse, and when you hover on a ship, it is centered and the mode is changed to an arena that moves around it, to return to the other mode you just click on the arena again. It's a cool system to track space ships.

Another feature is that you can zoom in/out the ships. When the camera gets too far, the units are shown as icons. When the zoom is nearer the ships are actual 3D models. You should give it a try to get some nice ideas.

Neat! thanks, I will try it out :)

cheers,
Paul

[ize]

Hi Paul. I'm not sure if you are still working on this, but i've only recently joined and slowly reading through the thousands of posts.



Version 2. would be easier to program - I could just have the arena made up of run-of-the-mill tiles and not have to rotate them, etc. But the user's ship would be harder to control in my mind, especially compared to the AI ships (they would make decisions relative to their heading like in version 1.).


I think this would be the easiest/best control method. As for it being harder to control, Asteroids springs to mind.

At the end of the day gamers always adapt to the control method for what they're playing.

[paul_nicholls]

Hi Paul. I'm not sure if you are still working on this, but i've only recently joined and slowly reading through the thousands of posts.



Version 2. would be easier to program - I could just have the arena made up of run-of-the-mill tiles and not have to rotate them, etc. But the user's ship would be harder to control in my mind, especially compared to the AI ships (they would make decisions relative to their heading like in version 1.).


I think this would be the easiest/best control method. As for it being harder to control, Asteroids springs to mind.

At the end of the day gamers always adapt to the control method for what they're playing.


Hi ize,
thanks for your input, all is welcome :-)
This project is in the back-burner for now though...

cheers,
Paul