2D or 3D physics for a top-down 2D ARPG in Unity?

Started by
8 comments, last by dissid 9 years, 7 months ago

Hi,

I'm currently setuping my project in Unity. It will be a 2D action RPG.

Though all of the visual will be 2D sprites, I'm concerned that I want to implement features such as jumping over certain obstacles, have some bridges pass over the floor at different heights, and it currently feels like using 3D physics behind the scenes would be much simpler, despite the game being entirely 2D from a visual standpoint.

Anyone here tried doing anything a top-down game in Unity? What did you use and why?

Advertisement

You can use 2D graphics to emulate 3D objects, but it's really not going to work out for you if you're trying to use 2D physics to emulate 3D physics. Sounds like you already know the answer to your question.

That, and unless you're going crazy with the number of objects that interact with one another, the performance gap between 2D physics simulation and 3D physics simulation isn't big enough to justify shooting yourself in the foot over.

So, you assessment is that, regardless of the actual visual output (2d in this case), dropping the Z axis is not a sufficient performance-gainer to justify limiting myself.

That being said, it does come with an added complexity that I need to handle to process collisions.

I just feel choosing 3d for a 2d game feels like refusing to use a set of tools optimized for most of what I'm trying to do save for a few things, so I end up handling everything in a 'custom' way because of the few situations that would benefit from that support...

I'm by no means an expert in Unity so I'd like to recommend a little sodium chloride with this reply, but in my experience using 3D graphics for a top-down or side-scrolling (parallax) 2D game is unlikely to affect performance much. In fact, the effect would probably be an improvement. Here's my reasoning:

In any robust game engine or environment, graphics are usually mixed along alpha channels (etc.) during game play -- characters & obstacles layered on a separate background, etc. In 3D, this is complicated with the addition of a Z axis which requires additional depth management including clipping, occlusion, and so on.

At the same time, any 3D engine worth a spit will be efficient, meaning it will not waste too many cycles trying to figure out things like clipping when the graphics blocks are basically just flat planes perpendicular to the Z axis. In effect, the game is simply shifting around postcards on which you probably don't want to apply lighting effects, meaning much of the complexity of a full 3D environment is reduced.

Additionally, 3D engines tend to boast their polygon rendering abilities so you know roughly what kind of performance you're likely to get. And beyond this, 3D engines often make direct use of graphics hardware which can greatly increase both rendering speed and free up the main processor for other functions (handling A.I., collision detection, etc.) 2D engines usually use the main computer/device processor so they can boast greater compatibility, but at the cost of raw power and speed.

In Adobe Flash, for example, we have had robust 2D graphics since pretty much the inception. Many optimizations have been made to the software to make it efficient, and it was pretty darned good until Adobe introduced direct GPU support. As a result, frameworks like Starling popped up that boasted the same capabilities as Flash 2D but with the ability to handle a lot more while simultaneously freeing up the CPU. In other words, Starling is a 2D game engine that uses Flash's newer 3D capabilities, analogous to your question. The answer that Starling provides is quite clear: 2D games can realize significant performance enhancements (plus easier code/effects), by using a 3D engine.

Back to Unity, I'm fairly certain that the same GPU acceleration is used which would lead me to believe that you would be better off using the full 3D engine to create a 2D game; the performance improvements alone would be worth it. Also, as you mentioned, 3D engines tend to have a lot of functionality pre-built -- physics, collisions, etc. It's nice to know how these work but if you're more concerned with actually building the game, these topics are probably best saved until later.

My two cents smile.png

Thanks, but I think my concern doesn't really lie with performance, but rather, ease of use for game logic (handling collisions, etc.).

Assuming I want to have stuff like jumping and overpass bridges/mezzanines, I felt 3D makes it easier to handle, but that would also mean I need to attach 3d collision boxes to actual 2d sprites, which feels a bit counter-intuitive?

Try both, there's no wrong one.

Really, you're using Unity, it's really easy to try both approaches, you don't even need to remove one to create the other, just disable the 2D or 3D collision components and enable the others, you don't even have to replace code since each 3D collision callbacks has a different name in 2D (OnTriggerEnter and OnTriggerEnter2D, etc). Setup some test scenes with the things you have in mind (jumping over enemies, different heights, etc) and try them if you're not sure.

Anyway, for a 2D game I think I would go with 2D collision detection and use the z axis values or some flags to check if the collision should be considered or not, it doesn't look like too extra work and maybe you can prevent weird bugs related to the 3D collision volume that you wouldn't notice in a 2D view. Also, 3D and 2D physics use a different axis for gravity and that could lead to more weird bugs, so that's another reason I'll do it in 2D.


ust disable the 2D or 3D collision components

Wouldn't my code still run actual vector2D vs Vector3D ?

I'd still need to change the code to switch between the two, no?


Anyway, for a 2D game I think I would go with 2D collision detection and use the z axis values or some flags to check if the collision should be considered or not, it doesn't look like too extra work and maybe you can prevent weird bugs related to the 3D collision volume that you wouldn't notice in a 2D view. Also, 3D and 2D physics use a different axis for gravity and that could lead to more weird bugs, so that's another reason I'll do it in 2D.

Makes sense. I was going to do something along these lines in 2D.

Thanks.


ust disable the 2D or 3D collision components

Wouldn't my code still run actual vector2D vs Vector3D ?

I'd still need to change the code to switch between the two, no?

Even in 2D, Unity puts everything in a 3D world, so the game objects would have a position with x, y and z values in both cases (Vector3). You'll always see the 3 components in the editor, and if you change your scene view from 2D to 3D you'll see that the z value is being used.

Also, you can have one script that handles 2D collision and another that handles 3D collision so you don't need to change code, just enable/disable those too depending on what you're testing, and then call methods of another script that does the logic you want for a collision.


Also, you can have one script that handles 2D collision and another that handles 3D collision so you don't need to change code, just enable/disable those too depending on what you're testing, and then call methods of another script that does the logic you want for a collision.

Ok yes, that's what I meant.

Thanks.

Use 3d physics. 2d physics in Unity are more catered towards sidescrollers, for example gravity is either x or y axis so you would have to use kinematic rigidbodies and handle jumping yourself. Methods like transform.LookAt() don't work out of the box. etc. I made couple of top down prototypes a while ago, in the end I switched to 3d physics. The performance gain with 2d was so marginal it was not worth it even on mobile.

Also, there are things not available with 2d physics, like particle collision detection.

Thanks, but I think my concern doesn't really lie with performance, but rather, ease of use for game logic (handling collisions, etc.).

Assuming I want to have stuff like jumping and overpass bridges/mezzanines, I felt 3D makes it easier to handle, but that would also mean I need to attach 3d collision boxes to actual 2d sprites, which feels a bit counter-intuitive?

Forgot to mention that 3d physics with sprites felt a lot more comfortable to me, as you can give volume to the colliders.

This topic is closed to new replies.

Advertisement