koobas.hobune.stream
Creating a 2D game on the X-Z plane, any adverse effects or challenges with this?
After coming to the realization that some things I wish to do in a 2D RTS are easier to do on the X-Z plane instead of the default X-Y plane, I'm considering moving my game over to the other plane.
What I am wondering, past the scripting changes to accommodate the different plane, is what specific challenges will this cause for a 2D game (using 3d physics, not 2d physics)? I did a test and flipped some assets to the X-Z plane and things seemed to work just fine, though I am not sure what unique challenges I will end up facing are.
Edit: all our objects will have a 90 degree X-Axis rotation.
Edit2: Apparently a 90-degree x-axis rotation doesn't play well with pathfinding, and movement in general. I'll need to find a solution to have the sprites render on the X-Z plane instead of the X-Y plane.
For that application, 2D RTS, moving to the X-Z plane just makes sense.
What is your argument for using XZ instead of XY? I can't think of any.
Generally, it doesn't make any difference, if you sync up all your components, axis are just names. But keep in mind that all Unity components assume the XY plane. Locked scene camera points there, Mouse and screen events are using XY, 2D Physics and so one, why would you want to change all of those settings? If you need different gravity, just flip the Physics axis in the settings to make your objects fall along the Z axis. At least that is my recommendation, but maybe you have a very good reason to prefer standard world coordinates in 2D.
Nav meshes, pathfinding, and steering. Assets that do these things seem to prefer to X-Z plane over the X-Y plane. And as far as I can tell Unity's nav mesh doesn't even work on the X-Y plane. I'll be using the 3D physics engine anyways, so that's not much of a loss.
You're right, Navmesh is the one example that prefers XZ and isn't changed easily. If you're having trouble with rotated assets, maybe you can fix it by parenting your objects under an empty zero rotation GO. Then also assign your colliders and movement to that ins$$anonymous$$d of the actual model, which should just be visually only in that case.
It really doesn't matter. You can't go wrong with xz. That's what I also do at the moment, and as douglasg14b already stated, it is the best choice for when you work with navmeshes or common pathfinding systems. And if you are doing a 2D top down game like me, it feels more natural to have y as your up axis.
The only difficulties that came up were related to 2D lights and shadows. There are some very nice solutions for that in the assetstore, which sadly work with the common xy plane system only.
It's a matter of naming just as well as when you want to steer left you'd have to say "rotate by forward axis" instead of "rotate by up axis", not to mention translating forward, left etc. - they're all messed up. So here are some possible solutions: 1. Just suck it up and memorize how to use the messed up names. 2. Make the renderer object a child of an already rotated go. 3. Instead of using the sprite renderer you can make a quad with the sprite texture but you loose sprite traits like pivot etc. 4. The most elegant and straightforward solution: wait until Unity comes up with a really useful checkbox like "render in xz plane". Unfortunately this is also the most unrecommended solution.
Although all the answers of this commonly asked question starts with something suggesting you don't want to do that, as if users don't even know what they want, then what I consider more useless is the "flip x" and "flip y" checkboxes, as if the users couldn't do that in... Windows Paint.
And yes, I'm still searching for a way to make the Sprite Renderer render on xz.
