thombruce / verse

🚀 A universe in progress
Other
8 stars 0 forks source link

Z-Axis Gravity #23

Open thombruce opened 1 year ago

thombruce commented 1 year ago

This is an interior and planetary consideration.

Since the intention is to make a top-down game, it doesn't make sense to apply gravity along the Y axis as is default in Rapier2d.

I believe this is the default value for Rapier2d:

gravity: Vect::Y * -9.81 * 10.0,

For 3D, it seems to be... Vect::Y * -9.81. I do not know why 2D is multiplied by 10 and 3D isn't.

That said, it might make sense to apply gravity along the Z-axis. I already have conceptions about handling the third dimension in this 2D orthographic world. We can just stack the third dimension into the Z-axis and items will be drawn correctly above or below one another. So why not realistically stack them according to their heights? And why not let gravity act along this dimension - think, for example, the player may drive a vehicle off a multi-storey carpark. We could get the velocity of the falling object from the gravity and calculate the damage on impact with the ground...

...but how would we handle impact? The 2-dimensional colliders are modelled for the X and Y dimensions, and this remains necessary.

Perhaps we could attach a component to impact tiles and write a system to have them either break on impact (glass, thin fabric, ice) or negate the fall of the object acting under gravity.

Alternatively... Could we mix use of the 2D orthographic camera with use of the Rapier3D physic engine? We'd still have to apply colliders - I don't know if these can be infinitely thin, but they wouldn't have to be so long as we're maintaining an appropriate distance between layers.


This all sounds... too intensive?

I genuinely don't know. I have no idea what the comparable computation cost is.


Could we also in theory configure the gravity value per planetary sphere of influence? ... Technically yes, but it would need to be updated every tick in order to point in the right direction. gravity takes a vec { x: X, y: Y } which determines the direction from an X and Y value. And given that it would be updated every tick, we could take into account the effects of other local gravitational bodies too in order to determine the direction of the gravitational center.

That would work.

The alternative is to... almost do exactly the same, just not with the help of Rapier.

thombruce commented 1 year ago

And while we're on the subject of gravity, while I expect most spacecraft will have artificial gravity... there's really nothing to stop us saying some don't, or having artificial gravity systems fail, therefore having ships the player would have to float around (environments where, once again, gravity is set to Vec2::ZERO). Not sure if this has any gameplay value, but it's a thought.

thombruce commented 1 year ago

And while we're on the subject of gravity... I'm pretty sure I've had the orbital gravity situation figured out for a little bit.

Once again, we model the gravity in that situation within a circle of influence as though the planets were 3-dimensional spheres, but we could raise the resultant Z value for the ship to the power of zero (we get either a positive or negative 1). This would give us a faux-3D orbit around a 2D object, which is how we avoid the player crashing into the planet.