Jan Matoušek · FIT ČVUT · 8. 10. 2026

Architektura, návrhové vzory, entity, kompozice a ECS.

Autorské ukázky kódu jsou fragmenty a pseudokód určené k výkladu. Nejsou vydávány za spustitelný projekt. Historická tvrzení zůstávají tvrzeními přednášky.

Může-li se něco pokazit, pokazí se to. – Edward Aloysius Murphy Jr.

The software needs to be built in such a way that it is able to adapt to unexpected changes in features. – Martin Fowler

Architektura software je promyšlený přístup k návrhu software, který umožňuje jej rozvíjet a reagovat na nečekané změny.

Obsah hry.

Herní mechaniky a systémy.

Zacílení hry (cílová skupina, způsob hraní hry).

Platformy, hardware, operační systémy, aplikační rozhraní.

Vývojářský tým, rozpočet na vývoj…

Volba nevhodné (nebo žádné) architektury prodraží implementaci změn.

class OldSoldier : public NPC {
    public:
        OldSoldier() : NPC("Hans", 100, ...) {}
}

NPC * old_soldier = new OldSoldier();

Zvolíme vhodnou abstrakci a přesuneme detaily do datových souborů:

[ { type: "npc", source: "hans.json", pos: ... } ]
...
{ name: "Hans", hp: "100", ... }

LoadSceneFromFile('level.json');

if(player_pressed_movement_keys()) {
  move_player();
}
else if(player_pressed_light_switch) {
  handle_light_switch();
}
else if ...

Využijeme OOP, zavedeme moduly.

for(auto system : systems) {
  system->tick();
}

for(nYPos = 0; nHeight > nYPos; nYPos++) {
    pAddress = (unsigned char *)(0xC000+((nY/8u)*80u)+((nY%8u)*2048u)+nX);
    memcpy(pAddress, pSprite, nWidth);
    pSprite += nWidth;
    nY++;
}

Zavedeme vrstvy / služby, které lze měnit.

auto drawing = Engine->GetDrawingService();
drawing->addSprite(...);
...
drawing->finish();

Typické rizikové situace:

Zdvojnásobení velikosti týmu.

Nečekaný odchod klíčového člena týmu.

Čitelný a přehledný kód (a nejen ten) je základ.

Dokumentace.

Nově příchozí vývojáři se potřebují zorientovat a co nejdříve začít pracovat.

Stávající vývojáři potřebují zaznamenat a vysvětlit svá rozhodnutí a různé podivnosti v kódu, datech, procesech, dokumentech…

Každé architektonické opatření něco stojí a to, co získáme, nemusí vyvážit náklady.

Vytváření abstrakcí a datových formátů versus dělba práce.

Vytváření objektů a modulů versus jejich počet.

Vytváření vrstev versus režie komunikace mezi nimi.

Obsáhlost dokumentace versus pracnost její údržby.

Elegance versus run-time režie.

Neexistuje univerzálně vhodná architektura.

Pracujeme s omezeným prostorem nečekaných změn a architekturu volíme podle něj.

Živá databáze

Ve hře se nacházejí herní entity, které mohou vznikat a zanikat.

Tyto herní entity interagují mezi sebou.

Hra komunikuje s okolním prostředím, zejména s hráčem.

Hra = databáze + interakce + komunikační rozhraní.

Propojení služeb

Jádrem hry je její simulace.

Aby hra fungovala, potřebuje řadu podpůrných služeb.

Hra = simulace + služby (vykreslování, zvučení, vstup, síť, logování atd.)

K architektuře her jako celku se vrátíme někdy příště.

Obecné řešení problému využívané při návrhu počítačových programů.

Problémem se zde nemyslí algoritmus.

Typické řešené problémy:

Úspora kódu.

Čitelnost kódu.

Udržovatelnost kódu.

Rozšiřitelnost kódu.

Oddělení zodpovědností.

Úspora zdrojů počítače (procesor, paměť, datové sběrnice…).

Tyto problémy často nejsou zřejmé na začátku vývoje, chceme jim ale předejít.

Návrhové vzory vypozorovány v praxi a popsány jako good/best practices → rozšíření návrhových vzorů do praxe.

Pojem design pattern poprvé použil Christopher Alexander v 1966; avšak v kontextu architektury a urbanismu, nikoliv software.

Poprvé v kontextu software Ward Cunningham a Kent Beck, v 1987 na konferenci OOPSLA. Předpřipravené vzory pro začátečníky v jazyce Smalltalk.

V roce 1991 vznikla skupina Gang of Four (GoF) – Erich Gamma, Richard Helm, Ralph Johnson a John Vlissides.

void Game::run() {
    while (true)
    {
        processInput();
        update();
        render();
    }
}

Přesná realizace tohoto vzoru závisí na použité platformě.

Jaké problémy má výše uvedený kód?

Prostředí hry obsahující herní entity

Je oživena herní smyčkou

Entity můžeme reprezentovat různými způsoby (viz dále)

(Velmi) naivní příklad:

struct Ball {
    int x, y, vx, vy;
};
struct Scene {
    Paddle player, otherPlayer;
    Ball ball;
    ScoreDisplay scoreDisplay;
};

Jaký má tento příklad problém a jaký problém by mohl řešit?

class Scene {
public:
    virtual void processInput() = 0;
    virtual void update() = 0;
    virtual void render() = 0;
}
void Game::run() {
    while (true)
    {
        currentScene->processInput();
        currentScene->update();
        currentScene->render();
    }
}

Jak řešit přepínání scén? A jaké problémy přetrvávají?

class Entity { ... };
class Paddle : public Entity { ... };
class Scene {
    std::vector<std::unique_ptr<Entity>> entities;
}

Na entitách využíváme polymorfismus. Podle použitého jazyka může mít různou realizaci (dědičnost a virtuální metody v C++, enums a/nebo dyn traits v Rust, tagged unions a/nebo function pointers v C…).

Jaké vzniknou problémy?

for(auto & entity : entities) {
    entity->draw();
}

Rozpočet snímku (příklad):

16 ms celkem (60 fps)

10 ms vykreslování na GPU

5 ms simulace

1 ms režie engine

Existují různá řešení, lze je kombinovat.

Původní rozpočet 16 ms je zaokrouhlený příklad; přesná perioda 60 Hz je 16,67 ms. Uvedených 5 ns na volání je předpoklad ukázky, nikoli naše měření.

class Component { ... };
class RenderableMesh : public Component { ... };
class Entity { std::vector<std::unique_ptr<Component>> components; };

Problém? Dynamické vazby, pomalé dohledávání potřebných komponent.

class Entity {
    std::unordered_map<std::type_index, std::unique_ptr<Component>> components;
    template<typename A>
    A& getComponent() { return dynamic_cast<A>(components.at(typeid(A))); }
};

Problém (např. v Unity)? Zůstává míchání datových komponent a skriptů chování, skákání po ukazatelích (nelokalita paměti, častý cache miss), prostorová režie velkého množství hash map.

Které komponenty používá který systém?

Každý druh komponenty se nachází v samostatné mapě indexované identifikátorem entity.

std::unordered_map<int, Position> positions;
std::unordered_map<int, Light> lights;
...

Každý systém potom prochází příslušné hash mapy, např.:

void lighting_system(...) {
    for(auto & [ entity_id, light ] : lights) {
        auto posIt = positions.find(entity_id);
        if(posIt == positions.end()) continue;
        auto & position = posIt->second;
        ...
    }
}

Problém: Nehráčská postava přinese kufr,

položí jej na stůl a odejde.

V kufru jsou různé věci.

Některé mechaniky vyžadují nalezení herních entit v blízkosti nějakých souřadnic.

Pro velké množství entit nebo velké množství hledání naivní postup nestačí – 𝑂(𝑛2)

Základní princip: Rozděl a panuj.

Existuje velké množství řešení:

Mřížky

Spatial hashing

Octree, quadtree

Bounding volume hierarchy

KD tree, BSP tree

Detaily necháme na jindy (přednáška o světech velkých a malých).

Mohli bychom používat adresy / pointery. Problémy?

Invalidace odkazů při přesunech paměti (např. při realokaci pole).

Skákání po pointerech, časté cache miss.

Problematické určení platnosti, pokud odkazovaný objekt zanikne.

– Šlo by používat kombinace shared a weak pointerů.

Mít očíslované entity je pragmatičtější přístup.

Je potřeba řešit, zda řada čísel musel musí být souvislá.

Pokud ano, jak entity při změnách přečíslovávat.

Pokud ne, zda nám čísla rychle nedojdou.

S tím trochu souvisí object pooling (příště).

Scéna je během hry málokdy statická, entity vznikají a zanikají.

Načtení / uvolnění levelu.

Spawning nepřátel, střílení a dopady projektilů…

Problémy se vznikem entit:

Přidělení identifikátoru, dynamická alokace, realokace polí…

Napojení vazeb

Výlučný přístup ke scéně, vhodný okamžik přidání

Zánik entit:

Zrušení vazeb

Výlučný přístup ke scéně, vhodný okamžik odebrání