How to handle movements of objects in a platformer with a cylindrical map?

I was wondering what would be the best approach for a game like Resogun:

In my opinion, the easiest approach is to:

• have a "Center Parent" for each moving object
  
  
• Offset the child object by the wanted radius
  
  
• Rotate the parent
  

=> The objects will move, though this will become super limited very quickly, especially if you want to do any sort of physics.

The 2nd approach is math:

Code (CSharp):

1. x = centerX + cos(angle)*radius;
2. x = centerY + sin(angle)*radius;

And this is what i want to use, however, am not certain about how to set it up, especially if i want to use rigidbodies and have some physical interactions.

any help please ?

Thanks

 

Holy crap, that looks great. It's Williams Defender all over again! I love it.

So Physics around such a tube would be problematic... but the actual work is precisely as you suggest above, with trig functions to project your position.

I made such a demo that sorta mimics Gyruss or Tempest motion, and the source is linked in the comments:

I suppose for Physics one way would be to run everything with Physics 2D somewhere else in a plane, just using invisible objects with colliders, then in your Update have all the visible objects project the physics objects to update their positions around the cylinder.

 

i know right! Resogun is probably the most arcade game i played this generation, shame its not available on Switch, it's perfect for a handheld device.

I've seen the 2D idea mentioned a lot, is it really that complex to "just" do it in 3D ? what's the "danger" of it ?

 

I doubt the above game uses physics to begin with, and personally I would NOT use physics and just use a) my own ballistics, and b) my own proximity-based collision, "oldskool" so to speak.

The "danger of 3D" as you put it is that it is a planar 2D game, wrapped around a cylinder. This means you can't trivially lock the Z axis in 3D... and in the general sense of velocity curving around a corner, the physics system knows nothing about that, so you would need to model it each frame yourself.

And then basically it sorta gets right back to "why use physics at all?" for this.

 

I see, you're right, any chance you came across any example of doing stuff on 2D but have "fake" graphics on 3D ? doesn't have to be related to this game idea at all, just wanna see how people handled that.

 

I could certainly imagine a system where all the physics stuff happens in a regular 2D plane (with some sort of trickery for the wrap-around at the edge) but then the camera looks in a completely different direction at a bunch of graphics-only objects that get moved every LateUpdate to match what's happening in the physics part. That seems like the obvious way to jury-rig an existing physics system to play on a non-Euclidean surface.

I don't think there would even be very much of a performance cost, as long as you're careful not to do any expensive rendering-related stuff in the off-screen physics portion or any expensive physics-related stuff in the on-screen portion.


Alternately, there might even be something you could do with the camera/rendering itself to make a flat plane look as if it were curved, even though everything has the same Z coordinate. But I couldn't tell you how, and I'm not certain it would be possible at all. (If this were a real-life physical camera, I would think you could do something with lenses, and I could probably even work out how to do the equivalent thing in a raycast-based renderer, but I don't think the same principles apply to a rasterization-based renderer.)

 

Um... did you see my Gyruss / Tempest video link above? Comes with full source code in my proximity_buttons project!

proximity_buttons is presently hosted at these locations:

https://bitbucket.org/kurtdekker/proximity_buttons

https://github.com/kurtdekker/proximity_buttons

https://gitlab.com/kurtdekker/proximity_buttons

https://sourceforge.net/projects/proximity-buttons/

 

This would technically be possible using a shader to twist the geometry into a world-space cylinder. You would still need to handle physics at the wrap-around point, though.

 

I thought of that too, the "subway surfer" approach, but after playing Resogun again, and taking a look at their photo mode, its obvious that they are not doing any shader trick.

 

oh! thanks!

 

Resogun doesn't need to take that approach -- they're a full 3D game and their physics is limited to explosion particles which aren't confined to the cylinder.

I think your simplest solution to have the cylinder and have physics is to take @Antistone's approach: create a flat 2D physics world that is then mapped onto a cylinder. This would intrinsically solve your constraint problem, but would not allow you to have full 3D physics in cylinder-space interact with your 2D physics.

 

Yeah i think you're right, i'll give that a go, thank you all!