2.5D game vector choice

I'm developing 2.5D game (3D assets, 2D gameplay). Since gameplay takes place on horizontal plane, majority of game objects have y component equal to 0. Most of my algorithms work on Vector2s, since these calculations obviously make more sense (and are a little bit faster, I guess). This makes field for hard to catch bugs, since Unity allows transparent conversion from Vector3 to Vector2 via cutting off z component.

Since I'm still in a stage in which I can change calculations quite easily, my question is: which approach will cause me the least trouble?

• Current: Gameplay on XZ plane, custom conversion from Vector3.XZ to Vector2.XY
• Gameplay on XZ plane, calculations on Vector3.XZ (and making sure, that y is always 0 - otherwise some of calculations may be erroneous)
• Gameplay on XY plane (that may cause some problems in editor I guess) and automated conversion from Vector3.XZ to Vector3.XY
• Gameplay on XY plane, calculations on Vector3.XY (though I see no benefit over solution 2)

Or is there some other approach I may take?

• Your transforms position are still working with vector3, so doing things with 2D vectors seems rather unnecessary . I'd just work on XY plane and use Z for depth. It all seems familiar. If you decide to work with 2d vectors you'd still be working wit XY for the 3D position. unless you specify that y should be set to z. – Sidar Apr 25 '18 at 14:12
• @Sidar, editing scene will be a lot more painful in such case. My XY plane is horizontal. Unity's XY plane is vertical. – Spook Apr 25 '18 at 14:24
• I don't follow, what is preventing you from designing your levels in the X direction? – Sidar Apr 25 '18 at 15:00

I'm working on a game that has 3D presentation, but has many aspects that are 2D in terms of game mechanics. Specifically, the game board locations have heights, but I don't allow units to stack, etc. For me, height only matters for displaying & sometimes line of sight calculations.

I choose to use X & Y to represent the plane parallel to flat ground. When height is involved, it uses the Z coord.

Most of my core data structures keep all 3 coords. My reasoning is as follows:

• memory is plentiful enough on my target platform(s)
• the memory footprint for a primitive is negligible when compared to other assets
• it hasn't negatively impacted performance
• it's easier to ignore information I don't need than vice versa
• the consistency gives me one less thing to worry about when making new something new

When I need to restrict things to 2D for processing, I just pass the coords needed.

In general, my guiding recommendations are:

• don't optimize prematurely
• try to keep things as simple & consistent as possible

Making a game is hard enough the way it is. Don't create additional barriers for yourself worrying about an extra primitive field. Save your worry for things like duping textures unnecessarily.