How did the devs implement having different floors to move to and from?

[YaboiBob]

I just started learning Unity and of course the first thing I wanted to make was multiplayer Xenonauts lol. Me and my buddies are big fans of the game and I thought it would be a cool project to create a simplified wargame version.
While drawing out the design I started wondering how exactly these games handle elevation and different floors? Especially when you are not going 2d isometric but 3d with an isometric viewing angle.
Apparently Unity's built in NavMesh isn't that good for this usecase? Did the devs use a 3d grid for this game? 

[asdfcyber]

The location of an Entity is stored as an Address object, which contains coordinates as i, j and floor (all integers) so you could call it a grid. Moving an entity from A to B is then as simple as setting the location to B. Unity is only used for rendering in this game, so this is all implemented outside of Unity. There's nothing stopping you from doing something like this in Unity though.

By the way, don't underestimate the effort of making a game, especially if you want to make it multiplayer.

[Bobit]

Unity Navmesh is totally inappropriate for turnbased games. Instead make your own A* algorithm and render it however you want (have gamelogic position as a Vector3 separate from model/engine position). That part will be easy.

Multiplayer is hard, but at least you don't have to deal with non-deterministic desync, and can just have the server puppet the clients using them for only input/output.

Another hard issue is projectile physics. Other than that XCOM-likes are relatively easy to program, it's just hard to design the spawning/AI algorithms, and there's a ridiculous amount of UI.

DM me for my discord username if you want to ask programming questions. Can't promise I will respond or won't say "you need to rethink this" so you can decide whether it's worth asking.

Edited February 15, 2023 by Bobit