Odpověď na názor

Děkuji za uznání.

Nejsem si jist, jestli jsem úplně pochopil težiště dotazu, ale zkusím na něco reagovat.

ECS jsem si nevymyslel, tohle je celkem dobře probraná věc. Pro studium stačí začít na wikipedii: https://en.wikipedia.org/wiki/Entity_component_system

Ve zkratce ECS je v zásadě jednoúčelová databáze. ECS by se dal v relační databázi realizovat zřejmě jako tabulky propojené přes jeden cizí klíč typu sequence (Postgresql terminologie). Prakticky by to asi bylo pomalé, protože se to píše takhle speciálně jak jednoúčelová databáze. A pak už je to o tom, jaká se zvolí strategie v implementaci, co je cílem, kde chceme vytáhnout výkon.

Tato jednoúčelovost se hodí zejména tam, kde mám definované nějaké ability systému, a mám nějaké entity, kterým tyto ability přiřazuji. Speciální významy pak mohou mít kombinace abilit (komba). Jednotlivé ability nic nědělají, ale pokud na jedné entitě zkombinuju tyto dvě ability, stane se něco úžasného. Je to výborný základ pro hry, ale třeba i pro nějakou evidenci uživatelských rolí, vlastností objektů, atd. Co se třeba nedá dělat tak to jsou vztahy 1:N kdy třeba nějaká entita má jednu komponentu a k ní N variant jiné komponenty (i když by to šlo řešit právě přes čísla variant, ale to je trochu kanón na vrabce).

ECS je navržena jako in-memory databáze. Je tedy možné ji perzistovat na disku, ale automaticky to není zaručeno, vyžaduje to další programování. Šlo by použít reflexe nad komponentami, ale k tomu se dostaneme až v C++26. Nebo použít jiný jazyk, třeba Javu :) Nicméně perzistence ECS databáze u nějaké hry je v zásadě uložená pozice. A tím se asi věc zjednoduší (třeba důvod, proč je BG3 schopen uložit hru uprostřed souboje , dialogu nebo in-game cutscény - celý stav mají v nějaké takové databázi.

Co se týče implementace v C++20, tak to je zase moje doména. Osobně považuji dvacítku za revoluci (byť už by to chtělo přejít na 23 - bohužel překladače nejsou pořád úplně ready, ale je to lepší a lepší)

Použití šablon umožňuje dále systém customizovat. Například lze zvolit jiný způsob úložiště pro konkrétní typu komponenty - stačí pouze specializovat danou šablonu a začne to magicky fungovat. Lze nahradit i úložiště celého Registry

A v neposlední řadě je to o překladačích. Dávno je pryč doba, kdy překladače překládaly kód přesně 1:1. Jazyk se vyvíjí postupně do podoby, kdy budeme definovat požadavky na systém a okrajové podmínky chování ale výsledný kód může pro daný problém být úplně jiný, specifický, bude dělat to co potřebujeme, ale nebude přesně odpovídat tomu, co původní programátor zamýšlel. Překladač si prostě vyhodnotí, že něco se dá vynechat, někde se něco přepíše jinak, pro daný problém lépe vyhovujícím stylem. S příchodem umělé inteligence do překladačů teprve uvidíme věci. Každopádně platí, že čím víc dám překladači informací, tím víc prostoru má na optimalizace. Proto header only. Proto šablony. A pokud mu některé metody umožním i v constexpr, pak je to ještě lepší, dávám překladači svolení, že části, co se dají spočítat už během překladu se prostě během překladu spočítají a tím se zase ušetří výkon.

Takže snad to je uspokojivá odpověď