Настроение:	contemplative
Entry tags:	computing

Spell of Mastery Progress

XCOM games have flying units, maintaining continuous altitude as a major feature.
Yet it was never obvious how to implement that in an easy to use way.
In fact, the entire idea of fully 3d isometric view if complicated.
XCOM solved it by just allowing the players to change cursor Z-level.
That cut everything above the current Z, everything look especially horrible.

Other games, like Magic & Mayhem limited the Z to just two levels.
4 levels if we consider flying units.
Recent games, like Cataclismo, use some crazy hacks and don't support flyers.
These also allow free camera movement, so player can move it inside the buildings.
Yet most games at best usually just keep the flyers at a separate layer.
These games also don't allow switching between layers. I.e. no flight spell.

Anyway, I have kinda solved it using my own set of hacks.
But I keep redesigning the flying units mechanics.
Since I want it to be simple enough and yet deep enough.
And it has to integrate seamlessly with other mechanics.

For example a heavy units like dragon should be able to squash weaker units.
By landing on them. Same way, heavy terrain blocks should squash them.
I also want for different units to have different altitude limit.
Flying units also have shadow blobs, which should be on the ground.
In addition there are squads mixing flying and non flying units.
Then there are flying units which carry non-flying units terrain on top.
And don't forget the multicell heightmapped units which can have holes.

Initially that resulted into absolutely mess of a code.
I had to chain several unit actions to just change the altitude,
while keeping in mind that is shouldn't mess up the topological sort.
It was unmaintainable, forcing me to I transition to ECS.
Now I'm rewriting every feature into a standalone component,
which keeps abstraction leaking to the minimum.

At least now I kinda understand how it all can be put together.