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

Spell of Mastery Progress

Replacing OOP with ECS for everything was easy.
I had to just replace `type` macro with `cls` macro.
But unlocking full expressiveness of ECS is far harder.
I have to rewrite core parts of the core code.
And most stuff depending on it, like rendering.
But existing rendering code was too clunky anyway,
like it had separate path for drawing terrain and units.

What do I mean by ECS features?

* Unrestricted site map size.
  I tried using actual octree voxels.
  But it was agonizingly slow.
  Compared to the bitmaps I'm using now.
  These don't allow raycasting but hash lookup is so much faster than trees.
  And my goal is supporting a 1024x1024x1024 site.
  since I want to check if I can unify the entire world map into a single
  seamless site.

* Uniformity between units and grid cells.
  Think floating island, which can be seen as both amalgamation of
  cells and a unit.
  Or proper cell animation, including running water and gas diffusion.

* General set theoretic queries.
  Haven't implemented these yet, since they are just too expensive
  for larger worlds.
  But cells as entities allow for efficient sparse grid.
  But I can still have these when the number of objects is a few thousand,
  like for important characters, but not every blade of grass.

In the end I came with architecture, wher each cell amalgamates properties from
both the terrain and the placed inside of it. That way I will have several solid
entities having intersecting cells and optionally sustaining damage or gaining
momentum.

Kinda ovekill for a turnbased XCOM clone, but collapsing platforms are a big
thing in XCOM style games. And I always the goal of having more environmental
puzzles and Shadow of Colossus style boss battles, where characters can climb
on top of a larger moving colossus. Then I already began transitioning to
a new tiling system, allowing for non-square structures. And the rendering code
had numerous issues relating to topologically sorting multicell units.

There was also issue with implementing mounted units and squad formations,
where squad acts as a single unit, but has properties of several units.
And say a squad of 5 could be able to carry a large object above their heads.
That is because I always wanted to have sokoban style puzzles.

More issues is that many cell tiles are non-uniform, so units entering them
should be offset a bit from the grid to look appropraite. The squad of 5 is
too large to fit single 64x32 gird tile, so these units have to be dispered a
bit into neighboring cells. That poses questions like combining the animation
and movement system with dispersing and offseting these units.

Normgroids say it is a stupid idea to turn game viewport/camera into an entity.
But then one may want to have features like camera following specific character,
or moving on specific path. And I also need these features for other entities.
Or you may have several preset cameras and switch between them. Like in a
multiplayer game. So it makes perfect sense for camer to be an entity even in
a 2d game.

All that requires a robust entity representation.

I can go endlessly about how ECS makes things easier, but I personally needed
that uniformity and set theoretic stuff the most. Even if for the most
important entities. The game became just too complex, when I implemented the
world view with separate world_unit type, and then cosmic_unit type, to allow
moving units between world and iterations of the same world. Since I wanted to
implement time travel. Suddenly ECS was that only one way to implement that.

So yeah, cache locality was not the reason I implemented ECS.
Most normies hate ECS becasue it is really confusing to construct ECS entities.
And the normgroid languages don't support them.
But my Symta is a dialect of Lisp, so nothing a good macro cant solve.