Úvod do herních enginů a jejich architektura

Abstrakce HW

Jednotné rozhraní (API) umožňující spouštění stejného kódu na PC, konzolích, mobilních zařízeních i VR bez přepisování nízkoúrovňových volání.

Znovupoužitelnost

Není třeba znova programovat hotové věci. Matematika, fyzika, formáty textur a zvuk jsou vyřešeny a prověřeny v praxi.

Produktivita

Integrované vývojové prostředí (IDE) s vizuálními editory pro správu scén, animací, fyzikálních materiálů, shaderů a ladění za běhu.

1. Éra bez enginů

• Kód psaný přímo na míru dané hardwarové architektuře (Assembler, C).
• Přímý zápis do registrů a paměti grafických/zvukových čipů.
• Hry jako Doom (1993) využívaly specifické matematické triky: BSP stromy (Binary Space Partitioning) – rekurzivní binární dělení prostoru pro okamžité určení pořadí vykreslování stěn (zepředu dozadu) bez nutnosti náročného Z-bufferu.

2. Modulární systémy

• Jasná separace grafického renderovacího jádra od herní logiky.
• Vznik legendárních enginů: Quake Engine (id), Unreal Engine 1 (Epic), Source (Valve).
• Zahájení licencování jader jiným studiím (např. Half-Life na bázi Quake, Deus Ex na Unreal Engine 1, Titanfall & Vampire: Bloodlines na Source enginu).

3. Demokratizace & Visual IDE

• Nástup zdarma dostupných nástrojů s licenčními modely dle úspěchu (Unity, Godot, Unreal Engine).
• Zpřístupnění špičkových AAA technologií nezávislým (indie) tvůrcům.
• Kompletní vizuální editory a asset ekosystémy.

1. Geometrie & Sítě (Meshes)

• Vertexy & Buffery: Vrcholy definované 3D pozicí, normálou (směr povrchu), tangenty a UV souřadnicemi pro textury.
• Index Buffer: Pole indexů spojující vrcholy do trojúhelníků (triangles).
• Transformační matice: Převod z Local Space \(\to\) World \(\to\) View (Camera) \(\to\) Clip Space (MVP matice).

2. Materiály, Textury & Shadery

• Shadery: Programy běžící masivně paralelně na GPU (Vertex Shader počítá pozice, Fragment/Pixel Shader počítá barvu pixelu).
• PBR Materiály: Fyzikální parametry povrchu (Albedo/BaseColor, Roughness, Metallic, Normal mapa pro iluzi detailů).

3. Světla & Stíny (Shadow Mapping)

• Typy světel: Directional (slunce), Point (žárovka), Spot (kužel/baterka), Area lights.
• Shadow Maps: Render hloubky scény z pozice světla do textury \(\to\) porovnání vzdálenosti pixelu k určení, zda je ve stínu.

4. Draw Calls & Post-processing

• Draw Call: Příkaz CPU odeslaný GPU k vykreslení objektu (hlavní limit CPU výkonu, řeší se Batchingem a Instancingem).
• Post-processing: Filtry aplikované na hotový 2D snímek (Bloom, Tone Mapping, Color Grading, SSAO, Motion Blur).

1. Numerická integrace pohybu

Výpočet zrychlení, rychlosti a pozice ze sil podle 2. Newtonova zákona: \[\vec{a} = \frac{\sum \vec{F}}{m}\]

• Explicit Euler: \(\vec{x}_{t+\Delta t} = \vec{x}_t + \vec{v}_t \Delta t\) – jednoduchý, ale nestabilní a energeticky diverguje.
• Semi-implicit Euler: Nejprve spočte novou rychlost, z ní novou pozici. Standard pro většinu herních enginů.
• Verletova integrace: Počítá bez explicitní rychlosti z předchozích dvou pozic – ideální pro simulaci látek (Cloth) a provazů.

2. Detekce a řešení kolizí

• Broad Phase: Rychlé vyloučení vzdálených těles pomocí AABB obálek a prostorových stromů (BVH, SAP) v čase \(\mathcal{O}(N \log N)\).
• Narrow Phase: Přesný výpočet kontaktních bodů a hloubky průniku (algoritmy GJK, SAT).
• Solver & Constraints: Aplikace korekčních impulsů, tření (friction), odrazu (restitution) a vazeb kloubů (Joint / Ragdoll).

1. Propojení s C++ jádrem (Native Bindings)

• Engine Core (C/C++): Maximální rychlost, správa paměti, rendering a fyzika přímo nad hardwarem.
• Foreign Function Interface (FFI): Překlenovací vrstva (P/Invoke v .NET, PyBind, JNI, C API) umožňující skriptům volat C++ jádro a naopak.
• Marshaling: Přenos a konverze datových struktur mezi spravovanou (managed) pamětí skriptu a nativní (unmanaged) pamětí C++.

2. Modely provádění skriptů

• Interpreted & Bytecode VM (GDScript, Lua): Rychlé načítání, minimální paměť, bezpečný sandbox, snadný Hot-Reload za běhu.
• JIT & AOT (C# Mono / CoreCLR / IL2CPP): Překlad mezikódu (CIL) do nativního strojového kódu CPU před spuštěním či za běhu.
• Vizuální grafy (Blueprints): Interpretované virtuálním strojem nebo automaticky nativizované do C++ před kompilací.

Životní cyklus MonoBehaviour

• Awake() / Start(): Awake() se volá ihned při inicializaci prefabu (i neaktivního). Start() až před prvním snímkem.
• FixedUpdate(): Běží nezávisle na FPS s konstantním krokem (\(\Delta t = 0.02\,\text{s}\)). Může se zavolat 0×, 1× i vícekrát za render frame. Určeno pro Rigidbody síly.
• Update(): Volá se jednou za renderovací snímek s proměnným Time.deltaTime. Zde se čtou vstupy z klávesnice/myši.
• LateUpdate(): Spustí se až po dokončení všech Update(). Klíčové pro follow-kamery, aby nedocházelo k trhání (jittering).

Příklad: PlayerController.cs

using UnityEngine;

public class PlayerController : MonoBehaviour {
    [SerializeField] private Rigidbody rb;
    [SerializeField] private Transform camRig;
    private Vector3 moveInput;

    void Awake() {
      rb = GetComponent<Rigidbody>();
    }

    // 1. Čtení vstupu každý vykreslený snímek (Variable FPS, starý Input System)
    void Update() {
        moveInput = new Vector3(Input.GetAxis("Horizontal"), 0, Input.GetAxis("Vertical"));
    }

    // 2. Fyzika s fixním krokem (např. 50 Hz, deterministické)
    void FixedUpdate() {
        rb.AddForce(moveInput.normalized * 15f, ForceMode.Acceleration);
    }

    // 3. Zarovnání kamery až po pohybu všech objektů a fyziky
    void LateUpdate() {
        camRig.position = transform.position;
    }
}

Životní cyklus uzlů (Node)

• _ready(): Volá se po vložení do stromu zdola nahoru (potomci jsou připraveni dříve než rodič).
• _unhandled_input(event): Zpracuje vstupy pouze tehdy, pokud je neabsorbovalo UI (např. kliknutí na tlačítko v inventáři).
• _physics_process(delta): Synchronizováno s interním Physics Serverem (default 60 Hz). Deterministický pohyb a move_and_slide().
• _process(delta): Běží každý renderovaný snímek (variabilní delta). Vhodné pro vizuální efekty a UI logiku.
• call_deferred() & queue_free(): Bezpečné asynchronní modifikace scény a mazání uzlů na konci frame.

Příklad: player.gd (CharacterBody3D)

extends CharacterBody3D

const SPEED = 5.0
var move_dir := Vector3.ZERO

func _ready() -> void:
    # Uzel je plně inicializován ve stromu scén
    set_physics_process(true)

# 1. Čtení gameplay vstupu (pouze pokud nebyl zkonzumován UI)
func _unhandled_input(event: InputEvent) -> void:
    var input := Input.get_vector("ui_left", "ui_right", "ui_up", "ui_down")
    move_dir = Vector3(input.x, 0, input.y).normalized()

# 2. Fixní fyzikální krok (konstantní delta, 60 TPS)
func _physics_process(delta: float) -> void:
    velocity.x = move_dir.x * SPEED
    velocity.z = move_dir.y * SPEED
    if not is_on_floor():
        velocity += get_gravity() * delta
    move_and_slide()

# 3. Vizuální aktualizace renderu každý grafický snímek
func _process(delta: float) -> void:
    $VisualModel.rotate_y(2.0 * delta)

1. Variable TimeStep (\(\Delta t\))

Reálná doba trvání předchozího snímku ($t$ je čas): \[\Delta t = t_{\text{current}} - t_{\text{previous}}\]

Korekce rychlosti posunu ($\vec{p}$ je vektor pozice): \[\vec{p}_{\text{new}} = \vec{p}_{\text{old}} + \vec{v} \cdot \Delta t\]

// Příklad v C# (Unity):
void Update() {
    transform.position += transform.forward * speed * Time.deltaTime;
}

  // Příklad v Godotu
  func _process(delta: float) -> void:
    global_position -= global_transform.basis.z * speed * delta

2. Fixed TimeStep (Fyzika)

Fyzikální simulátory vyžadují přísně deterministické chování.

• Při variabilním \(\Delta t\) způsobuje velký propad FPS chyby numerické integrace (např. tunelování skrz zdi).
• Fyzika proto běží na pevné frekvenci (např. 50 Hz \(\to \Delta t = 0.02\text{ s}\)) nezávisle na renderovacích FPS.
• Pokud snímek trvá déle, engine v jednom snímku provede více kroků fyziky.

• Výhody: Nízké nároky na paměť VRAM, přirozená transparentnost, rychlé MSAA vyhlazování.
• Nevýhody: Velmi špatně škáluje s desítkami/stovkami dynamických světel.

• Výhody: Stovky dynamických světel na scéně bez ztráty FPS.
• Nevýhody: Vysoké paměťové nároky (VRAM bandwidth), složité řešení průhlednosti.

1. Virtual Geometry (UE5 Nanite)

Automatická mikro-polygonální geometrie streamovaná v reálném čase. Vykresluje pouze pixely odpovídající reálnému rozlišení obrazovky a eliminuje nutnost ruční tvorby LOD.

2. Real-time Ray Tracing & Lumen

Hardwarově akcelerovaný výpočet reálných odrazů a dynamického globálního osvětlení (GI). Nahrazuje staticky zapečené lightmapy (Lightmap) plně dynamickým modelem.

3. PBR (Physically Based Rendering)

Standardizovaný materiálový model založený na fyzice zachování energie (Albedo, Metallic, Roughness, Normal, Ambient Occlusion).

4. AI Super Sampling (DLSS / FSR / XeSS)

Interní renderování v nižším rozlišení (např. 1080p) a rekonstrukce obrazu do 4K pomocí neuronových sítí a temporálních vektorů na GPU.

Detekce kolizí

• Discrete Collision Detection (DCD): Testuje překryv těles v diskrétních časech \((t_0, t_1)\). Riziko prolétnutí rychlých objektů bez detekce kolize.
• Continuous Collision Detection (CCD): Počítá swept-volume objemy po trajektorii tělesa v čase.
• Raycasting: Vrhání paprsků z kamery či zbraně pro okamžitou detekci prvního zasaženého objektu.

Bez prostorových struktur vyžaduje testování kolizí \(N\) těles naivní složitost \(\mathcal{O}(N^2)\).

• Octree / Quadtree: Rekurzivní hierarchické dělení 3D prostoru na 8 krychlí (resp. 4 ve 2D).
• BVH (Bounding Volume Hierarchy): Hierarchie obalových těles (AABB kuliček a kvádrů) umožňující rychlé vyloučení vzdálených objektů.

Managed Memory (Unity C# / Godot C#)

• Alokace objektů probíhá na řízené haldě (.NET GC).
• Vysoká bezpečnost kódu (žádné use-after-free, memory leaks jsou vzácnější).
• Nevýhoda: Neřízené okamžiky čištění paměti.

Manual / Unmanaged (Unreal C++)

• Přímá správa paměti, Custom arena allocator.
• Reference counting a garbage collection přes UPROPERTY() a chytré ukazatele (TSharedPtr).
• Výhoda: Nulové nečekané záseky při správném návrhu.

Dědičnost a Náhodná paměť (Godot příklad)

Tradiční stromová hierarchie: Node \(\to\) CanvasItem \(\to\) CharacterBody2D \(\to\) Enemy.

# Godot GDScript - pole instancí
var enemies: Array[Enemy] = []

func _process(delta: float):
    for e in enemies:
        # Každý 'e' je pointer na náhodné místo v RAM!
        e.position += e.velocity * delta

• Monolitické objekty: Každý Enemy v paměti nese desítky položek (jméno, textury, AI stav, transform, script metadata).

Co je to „Pointer Chasing“?

• Cache Miss: Při iteraci procesor nemůže předvídat další adresu v paměti. L1/L2 Cache selže.
• Stall procesoru: CPU musí čekat 100–300 cyklů na načtení 64B řádku z hlavní RAM namísto okamžitého výpočtu.
• \(90\%\) výkonu CPU se ztratí čekáním na sběrnici RAM!

Data-Oriented přístup (Unity C# Příklad)

Data jsou uložena v souvislých polích (Contiguous Memory):

// 1. Komponenty = Čistá data bez metod (žádný overhead)
public struct Position : IComponentData { public float3 Value; }
public struct Velocity : IComponentData { public float3 Value; }

// 2. Systém = Logika iterující nad souvislým polem struktur
public partial class MovementSystem : SystemBase {
    protected override void OnUpdate() {
        float dt = SystemAPI.Time.DeltaTime;

        // Blesková iterace přes pole v L1 CPU Cache:
        Entities.ForEach((ref Position pos, in Velocity vel) => {
            pos.Value += vel.Value * dt;
        }).ScheduleParallel();
    }
}

Unity DOTS & Unreal Mass

void TakeDamage(float amount) {
    health -= amount;
    if (health <= 0) Die();
}

• Výhody: Maximální výkon, perfektní pro komplexní matematiku a AI, skvělé verzování v Gitu (diffy, mergování).
• Nevýhody: Vyšší práh vstupu pro level designéry a umělce.

[Event TakeDamage] ➜ [Subtract Health]
                          │
                          ▼
                   [Branch (<= 0)] ➜ [Die]

• Výhody: Bleskové prototypování, nemožnost udělat syntaktickou chybu, intuitivní pro designéry.
• Nevýhody: Náročnější verzování (binární soubory), riziko vzniku nepřehledného "Spaghetti kódu".

Formáty PNG/JPG jsou pro GPU nepoužitelné — musely by se celé dekomprimovat do obrovské nekomprimované VRAM (1 textura 4K = 64 MB). Blokové formáty (BC1–BC7 na PC/konzolích, ASTC na mobilech) komprimují bloky 4×4 pixelů v poměru 4:1 až 8:1 a GPU je čte přímo z VRAM bez nutnosti dekomprese do RAM.

Předpočítaná řada zmenšených verzí textury (\(1/2, 1/4, 1/8\dots\)) stojící pouze \(+33\%\) VRAM. Zabraňuje třepetání pixelů (aliasing / texture shimmering) a šetří propustnost GPU sběrnice načítáním miniaturních textur pro vzdálené polygony.

Překlad vyšších jazyků (HLSL/GLSL) do binárního GPU mezikódu (SPIR-V, DXIL). V moderních API (D3D12, Vulkan) se stavy pipeline předkompilují do PSO objektů, což zabraňuje zásekům při prvním spatření nového efektu ve hře (Shader Compilation Stutter).

Klasické diskrétní stupně (LOD0–LOD3) redukují počet polygonů vzdálených modelů. Moderní enginy (UE5 Nanite) přecházejí na mikro-polygonální geometrii (Meshlets), která plynule streamuje detail sítě odpovídající přesně hustotě pixelů na obrazovce.

UNITY 6

UNREAL ENGINE 5

GODOT 4

Hlavní výhody (Pros)

• Vysoká produktivita v C#: Moderní .NET CoreCLR / IL2CPP, rychlý vývoj a silný typový systém.
• Dominance v 2D, Mobile & VR: Bezkonkurenční optimalizace pro iOS, Android a Meta Quest.
• Bohatý Asset Store & Komunita: Statisíce hotových pluginů, modelů, shaderů a tutoriálů.
• Flexibilní architektura: Volitelný přechod z klasického OOP (MonoBehaviour) na vysoce výkonný DOTS (ECS).

Hlavní nevýhody (Cons)

• Fragmentace renderovacích pipeline: Přechod mezi Built-in, URP a HDRP způsobuje nekompatibilitu materiálů.
• Garbage Collection záseky: Správa paměti v C# vyžaduje pečlivý pooling, jinak hrozí periodické propady FPS.
• Uzavřený C++ zdrojový kód: Přístup ke zdrojovému kódu jádra vyžaduje nákladnou Enterprise licenci.
• Nestabilita API balíčků: Časté deprecations a experimentální stavy nových modulů v Package Manageru.

Hlavní výhody (Pros)

• Fotorealismus v základu: Nanite (neomezená geometrie bez ručních LODů) & Lumen (dynamické GI a odrazy).
• 100% přístup k C++ kódu: Kompletní zdrojový kód na GitHubu s možností přímých úprav a debugování.
• Bezkonkurenční Blueprints: Plnohodnotný visual scripting umožňující vytvořit kompletní hru i bez psaní C++.
• Kompletní sada AAA nástrojů: Niagara (částice), Chaos (fyzika), Control Rig (animace), Mass AI.

Hlavní nevýhody (Cons)

• Extrémní HW nároky: Vyžaduje špičkový vývojářský počítač (výkonné vícejádrové CPU, rychlé NVMe, 32GB+ RAM).
• Masivní velikost: Instalace >100 GB; finální herní balíčky mají běžně desítky až stovky gigabajtů.
• Strmá křivka učení: Komplexní C++ makra (UCLASS, UPROPERTY), dlouhé kompilace shaderů a C++ kódu.
• Nevhodný pro lehké 2D & casual mobily: Příliš velký engine overhead pro jednoduché a minimalistické hry.

Hlavní výhody (Pros)

• 100% Free & MIT Licence: Žádné licenční poplatky, žádné povinné odvody, úplné vlastnictví vytvořeného díla.
• Extrémně lehký (~60 MB): Rychlé spuštění, portable bez instalace, běží i na starším hardwaru.
• Prvotřídní dedikovaný 2D engine: Skutečný pixelový 2D renderer s vlastními souřadnicemi (nikoliv 3D projekce).
• Strom uzlů (Node Trees): Vše je uzel a vnořená scéna; maximálně intuitivní a modulární návrh.
• GDScript a C#: Jazyk navržený pro herní vývoj s rychlým hot-reloadingem.

Hlavní nevýhody (Cons)

• 3D grafika zaostává za AAA: Chybí ekvivalenty Nanite/Lumen, 3D renderer je vhodný spíše pro stylizované hry.
• Chybí přímý export na konzole: Kvůli open-source povaze nelze šířit uzavřená SDK (PlayStation/Xbox vyžaduje partnery).
• Menší ekosystém Assetů: Asset Library je podstatně menší než komerční obchody Unity a Unrealu.
• Méně pracovních nabídek: Většina velkých herních studií stále vyžaduje primárně Unity nebo Unreal C++.

Unity

• Personal edice je zdarma do limitu $200k ročních příjmů.
• Při překročení limitu povinnost platit Unity Pro $2,000+ / rok za každého vývojáře v týmu.

Unreal Engine

• Kompletní nástroje i kód jsou zdarma pro všechny.
• Epic si nárokuje 5 % z hrubých tržeb, ale až poté, co hra vydělá první $1,000,000 USD.

Godot Engine

• 0 % poplatků, navždy zdarma.
• Žádné sledování příjmů, žádné royalty podmínky, absolutní vlastnictví vytvořeného díla.