Vlákno názorů ke článku Entity Component System v C++20 od František Ryšánek - Děkuji za zajímavý článek, který jde příjemně pod...

Děkuji za zajímavý článek, který jde příjemně pod povrch - a za rozšíření obzorů (jsem hobbík).
Odpusťte mi povrchní komentář:

Jste-li jako programátor postaven před dostatečně složitý problém = systém k programátorskému pojednání, pravděpodobně pocítíte touhu, napsat si abstrakční vrstvu, která Vás oprostí od nutnosti modelovat data tupě "at compile time". Jinak řečeno, napsat si vlastní prostředí, které Vám umožní dále modelovat data a tvořit, bez úprav kompilovaných zdrojáků. Napsat si svůj vlastní domain-specific KV store / adresářový engine / grafovou databázi, odpoutanou od elementárního zemitého folklóru C/C++.

Pokud správně chápu, ECS je někde na půl cestě k plnotučné abstrakční vrstvě. Hovoříte k němu ve zdrojáku C++, ale jako páteř ECS používáte jakýsi "sjednocený prostý metamodel", ačkoli zároveň prokazujete respekt statickému typování (šablonám povinně udáváte typ každého "drobku", který do ECS hodláte vkládat).

Zajímavá záležitost. Chovám respekt k Vašemu "method artist" přístupu, k Vašemu smyslu pro ohavný detail (celá knihovna v headerech/šablo­nách, honba za constexpr, a jak jdete naproti efektivitě cache). Tohle se dneska moc nevidí a nenosí... Mít víc času, ponořil bych se do návazné četby k těmto postranním zápletkám. Opravdu se Vám to povedlo :-)

Co je na "at compile time" tupé?

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ěď

Děkuji za osobní reakci :-) Popravdě já jsem ke svému "názoru" naschvál nedal otazník - ale Vaše odpověď rozhodně potěšila.

V tuto chvíli píšu lehce mimo téma, že mi Youtube cca předevčírem nadhodil následující přednes:
https://www.youtube.com/watch?v=wo84LFzx5nI
Kupodivu clickbaitový titulek moc nesedí k osahu :-) Klikl jsem na to spíš znuděně a s odporem k k tomu klišé v titulku, a pak jsem se nestačil divit, jaký kus krásného dějepisu ta přednáška obsahuje. Jinak nic moc teoreticky hlubokého... a je tam i docela dlouhý kus věnovaný právě ECS a jeho roli ve hrách od Looking Glass, kde Casey Muratori nějaký čas pracoval. Až mi vrtalo hlavou, jestli mi YouTube to téma nahodil záměrně, se znalostí mé čerstvé brouzdací historie tady na rootu :-D Na soustředěné sledování je to video trochu rozvláčné, ale jako pozadí k manuální domácí práci posloužilo velmi dobře.

Děkuji za odkaz. Naprosto úžasný talk, velice poučné a inspirativní.

Díky moc.

Jako nehobík bych řekl, že touze napsat si nějakou takovou abstrakční vrstvu je záhodno odolat. Obzvlášť pokud řešíte nějaký dostatečně složitý problém.

O nějakých flexibilních strukturách za běhu se přemýšlí podstatně obtížněji, než o rigidnějších "compile-time" strukturách. Kompilátor křížený s dominou je skvělá věc, protože co nedovolí, to opravdu nemůže nastat. Čím víc můžu tvořit za běhu, tím míň o těch datech můžu předpokládat. Najednou už vůbec nemůžete modelovat a tvořit, protože nemáte tušení, co se vlastně děje.

Pro jednoduché a krátkodobé projekty je dynamický přístup super. Ale jak jde veliký projekt, který se nedá udržet v hlavě a navíc dlouhodobá údržba znamená že spoustu věcí zapomenete, tak se z takové abstraktní vrstvy spíš zblázníte. Proto máme třeba typescript, nebo typové anotace v pythonu.

To je pravda, na webech jsem taky přešel na typescript. Už jenom to, že vscode intellisence umí správně napovídat, ví co kam patří, podtrhne co kam nepatří, a dokonce copilot odhadne, co chci dál napsat (a napíše to za mě :)