LOD pro tisíce animovaných postav v Unity stavte podle počtu vrcholů, ne trojúhelníků: u vertex animation textures se animace počítá na každý vrchol. Nižší úrovně připravte ručně, vrcholy nejnižší úrovně připojte k povrchu originálu a úroveň vybírejte pro každou postavu zvlášť. V naší tower defense hře pro PC to při 3 000 nepřátel zvýšilo FPS při záběru do davu z 62 na 120.

Postup se týká her, kde se na obrazovce pohybují tisíce postav najednou, tedy tower defense, strategií a survival her. Naše hra je postavená v Unity s ECS a najdete ji v referencích. LOD znamená level of detail: vzdálená postava se kreslí z jednodušší sítě. Obrázky jsou skutečné sítě našeho nepřítele kostlivce, ne záběry ze hry.

#Proč generovaný LOD davu nepomůže

Unity umí úrovně LOD vygenerovat při importu modelu (funkce Mesh LOD). Pro tisíce postav to má dva problémy.

První je vzhled. Automatické zjednodušení trhalo tenké končetiny a rozbíjelo UV, tedy mapování textury na síť.

Druhý je cena animace. Standardní kosterní animace jsou pro tisíce entit příliš drahé, proto se místo nich používají vertex animation textures (VAT). VAT je textura, kde každý sloupec patří jednomu vrcholu a každý řádek jednomu snímku animace. Shader si polohu vrcholu přečte z textury, takže cena animace závisí na počtu čtených vrcholů, a to i při kreslení stínů.

Horní hranici ukazuje test s vynucenou generovanou úrovní na všech postavách (Unity vygeneruje i úrovně 3 a 4, build, 1080p, 3 000 nepřátel, stíny zapnuté):

Prostor pro zrychlení je velký. Je třeba ho získat bez viditelných děr a skoků mezi úrovněmi.

#Počítejte vrcholy, ne trojúhelníky

Poloviční počet trojúhelníků sám o sobě nepomůže. LOD s polovinou trojúhelníků a 996 z původních 1 521 vrcholů ušetřil 1,9 ms na snímek, LOD s 217 vrcholy 6,4 ms. U každé úrovně sledujte oba počty.

Vrcholů bývá zbytečně mnoho. Vrchol se zdvojí na každém švu UV, protože jedna poloha pak potřebuje dvě souřadnice textury. Naše modely z AI generátoru měly UV rozsekané na stovky ostrovů: kostlivec měl 1 521 vrcholů, ale jen 608 různých kombinací polohy a normály.

#Krok 1: Snižte počet vrcholů v LOD 0

První úspora nestojí žádný detail. Spojte vrcholy se shodnou polohou a podobnou normálou (rozdíl do 25°), rozbalte UV znovu se švy jen na ostrých hranách (nad 70°) a texturu přepočítejte z původní po trojúhelnících. Kostlivec klesl z 1 521 na 1 090 vrcholů, u ostatních typů nepřátel to bylo o 19 až 29 % méně, při stejném tvaru.

Do VAT pak zapisujte jen sloupce vrcholů, které některá úroveň skutečně používá. Ušetřilo to 40 až 60 % paměti animací.

#Krok 2: LOD 1 ze zjednodušení se sdílenou texturou

LOD 1 je zjednodušený LOD 0 na přibližně 52 % trojúhelníků. Zjednodušujte po kouscích (každá kombinace kosti a souvislé části sítě) a vrcholy na hranicích kousků zamkněte. Hlavě dejte větší rozpočet, protože silueta hlavy je to, co oko v davu rozezná.

Důležité je ponechat texturu LOD 0. Úroveň s vlastní texturou nebo jiným tvarem je při přechodu vidět i při podobné siluetě.

Pod zhruba 50 % trojúhelníků zjednodušení z existujících vrcholů trhá tenké části a samostatné kousky. Níž je třeba jít jinak.

#Krok 3: LOD 2 jako nová síť připojená k originálu

Nejnižší úroveň je nová uzavřená síť. Originálu přidejte vrstvu tloušťky, proveďte voxel remesh a zjednodušte na cílový počet (u nás 200 až 460 trojúhelníků podle typu nepřítele). Výslednou síť obalte na povrch originálu a UV udělejte automaticky. Texturu zapečte z originálu ve stejné hustotě jako LOD 0, aby seděly i mipmapy.

Nová síť nemá váhy animace. Každý její vrchol proto připojte k nejbližšímu trojúhelníku originálu. Uložte si tři sloupce toho trojúhelníku a barycentrické váhy (podíly, které určují polohu bodu v trojúhelníku).

Sloupec připojeného vrcholu ve VAT je vážený součet poloh a normál těch tří vrcholů v každém snímku. Shader nic neřeší, připojený vrchol je obyčejný další sloupec.

pro každý snímek f:
    VAT[připojený, f] = w0 * VAT[a, f] + w1 * VAT[b, f] + w2 * VAT[c, f]

#Krok 4: Díry kontrolujte strojově

Obrázky z modelovacího nástroje díry spolehlivě neukážou. Kontrola stačí jednoduchá: vykreslete originál a kandidáta z 11 směrů v rozlišení 120 px a porovnejte siluety.

Za díru počítejte pixely originálu uvnitř obrysu kandidáta, které kandidát nepokryje, a pixely kandidáta více než 2 px mimo obrys originálu. U nás je limit 1 % děr a 4 až 6 % ztráty. Kontrola musí respektovat odstraňování zadních stěn podle materiálu. Limity jsme nastavili podle toho, kde byly přechody ve hře okem vidět.

#Krok 5: Vybírejte úroveň pro každou postavu zvlášť

Přepínání úrovně pro celou mapu najednou je vidět. Když vybíráte po entitách, přechody se rozloží a v davu zaniknou.

Celá mapa najednou

Po entitách

Upozornění k verzi: dokumentace Unity 6.2 uvádí, že Entities Graphics vždy používá LOD 0. Výběr po entitách podle vzorce níže používáme v Unity 6.6, před nasazením si ověřte chování vaší verze:

LOD = log2(d * C / D) * sklon + posun
C = prah * 2 * tan(fov / 2) / vyska_obrazu

Tady je d vzdálenost od kamery a D průměr světových hranic entity. Sklon a posun zvolte tak, aby úroveň 1 začínala na 93,3 a úroveň 2 na 167,9 metru (kamera s fov 30° a 1440 px). Globální práh LOD nastavte na výšku obrazu / 1440, potom vzdálenosti nezávisí na rozlišení.

Dvě chyby, na které si dejte pozor:

• Měřítko. Průměr D počítejte ze světových hranic, tedy s měřítkem prefabu. Sítě pro VAT bývají v malých jednotkách a prefab je zvětší 2krát až 4krát. Bez toho vám hra celou dobu kreslí LOD 0 a nic nehlásí. Správnost ověřte počtem trojúhelníků v běžném režimu oproti vynucenému LOD. Pootočení entity zvětšuje osově zarovnané hranice, proto u nás průměr násobíme koeficientem 1,22.
• Bakování. Křivka výběru se zapéká při bakování SubScene a změnu v síti bakování nezachytí. Po její úpravě vynuťte nové bakování SubScene.

#Výsledky a limity

Build pro macOS, 2560 × 1440, 3 000 nepřátel, stíny zapnuté, hra zastavená po prohře (animace VAT stále běží, takže měření platí pro grafiku):

Na Steam Decku (1280 × 800, 8 výpočetních jednotek RDNA 2) je to 75 až 80 FPS na celé mapě. Nejbližší záběr do davu má při vysoké kvalitě stínů 33 FPS, bez stínů 64. Stíny jsou tedy největší zbývající položka: LOD snižuje i jejich cenu, ale vypnutí stále udělá velký skok.

Co LOD neřeší: kontrola děr běží v T-póze, takže natažení sítě v extrémních pózách neodhalí. Jeden typ nepřítele ještě limit děr v LOD 2 překračuje. Výpočet pohybu hordy LOD neovlivní, ten řeší článek o navigaci hordy v Unity DOTS a reakce na výbuchy fake ragdoll.

Potřebujete pomoct s výkonem hry v Unity nebo simulací davu? Napište nám.

Stará 2D hra v Unity na vestavěném render pipeline vypadá na dnešním telefonu ploše: světlo chybí, glow buď není, nebo rozzáří celý obraz i s UI, a sprity rozhraní jsou rozmazané. V Unity URP to vyřešíte třemi věcmi: Bloomem s prahem 1 a HDR barvou jen na objektech, které mají zářit, 2D světly z 2D rendereru a UI s většími sprity, které respektuje bezpečnou oblast displeje.

Postup ukazujeme na naší hře Dreamica (App Store, Google Play). Je to pádová adventura, ve které prstem kreslíte čáry a jimi vedete bublinu se spícím dítětem přes čtyři světy. Původně vznikla v Unity 5.3, UI bylo v pluginu NGUI, glow obstarával plugin MK Glow a grafika byla připravená pro iPhone 7 s displejem 1334 × 750 pixelů. Hratelnost zůstala stejná, změnila se jen grafika.

Starou hru často otevřete kvůli obchodu, ne kvůli grafice. Google Play od srpna 2019 vyžaduje 64bitové verze a hra, která má jen 32bitový build, z něj vypadne. Přesně tak dopadla i Dreamica. Když už projekt převádíte do Unity 6, grafika je poměrně levný bonus.

#Proč nestačí starý celoobrazovkový glow

Starší glow pluginy fungují jako celoobrazovkový efekt. Rozzáří všechno světlé včetně ikonek tlačítek v menu. V Dreamice ikonky pod MK Glow v Unity 6 skoro zmizely. Oficiální balík Post Processing Stack v2 je náhrada jen pro vestavěný pipeline, v URP se už neaplikuje. Pokud chcete glow, který řídíte po materiálech, a k tomu dynamická 2D světla, přejděte na URP a použijte Bloom, který je v něm zabudovaný.

#Krok 1: Přepněte projekt na URP

Po přepnutí na URP narazíte ve staré 2D hře téměř jistě na dvě pasti. Obě se projevují tak, že obraz vypadá špatně nebo přesně jako předtím, přestože shadery jsou v pořádku.

#Šedá obrazovka: nastavte zásobník kamer

Pokud herní okno v Editoru ukazuje jen šedou plochu, ale scéna v editoru i jednorázový render kamery vypadají správně, chyba není v shaderech, ale ve skládání kamer. Staré hry mívají dvě kamery, jednu na svět a jednu na UI, a UI kamera maže jen hloubku. Tak se vrství kamery ve vestavěném pipeline a URP to nepodporuje. Potřebuje explicitní zásobník kamer (camera stack): jedna kamera je základní (Base), ostatní jsou překryv (Overlay) zařazený do jejího zásobníku. Nastavte ho v každé scéně, kde se kamery vrství.

#Sprity ignorují světlo: přepněte na 2D renderer

Sprity s osvětleným shaderem nereagují na žádné světlo, pokud běží běžný URP renderer. Ten 2D světla vůbec nepočítá. Přepněte na 2D renderer. Ani ten ale osvětlení nekreslí, dokud ve scéně není alespoň jedno 2D světlo. Když něco po změně vypadá přesně jako předtím, nejdřív zkontrolujte, který renderer běží.

#Částice a staré pluginy

Částice na starých shaderech se pod 2D rendererem kreslí černě nebo vůbec. Dejte jim nový jednoduchý shader.

Pozor i na Asset Store. Při obnovení assetů umí Editor sám aplikovat „aktualizaci“ starého pluginu, která přidá metadata a přejmenuje shadery. Materiály hledají shader podle jména, takže se potichu rozbijí. Po každém větším obnovení assetů ve starém projektu si ve verzovacím systému projděte všechny změněné soubory, i ty, na kterých zrovna nepracujete.

#Krok 2: Selektivní glow přes HDR barvu a Bloom s prahem 1

Cílem je, aby zářily vybrané objekty, v Dreamice nakreslená čára, lasery, jiskry, světlušky a runy, ale ne pozadí a UI. Bloom v URP rozmaže a přičte všechno, co je jasnější než jeho práh. Nastavte práh na 1 a materiálům, které mají zářit, vytlačte barvu nad 1.

shader čáry:
    barva = textura × barva vrcholu × odstín × intenzita    (intenzita = 6)

Bloom:
    práh = 1, síla = 0,3
    září jen to, co má po výpočtu jas nad 1

Pozadí a tlačítka mají barvy od 0 do 1, přes práh neprojdou a zůstanou ostrá. Tím zmizí i problém s vybělenými ikonkami. Podmínkou je kamera s HDR. Bez něj se barva ořízne na 1 a nezáří nic. 2D renderer přepínač HDR v inspektoru kamery neukazuje, proto ho zapněte skriptem.

Nízký práh, celý obraz

Práh 1, HDR materiál

Když je glow takto pod kontrolou, nemusí být volitelný. V Dreamice jsme přepínač glow z nastavení zrušili, glow je součást vzhledu.

#Emisní mapa: září jen část spritu

Pokud má zářit jen část spritu, přidejte mu emisní mapu (emission map): druhou, černobílou texturu, která říká, která část spritu září. Jen ta část dostane barvu nad 1, takže u runy svítí jádro, ne celý obrys.

#Pulzování v expozičních stupních

Pokud má záření pulzovat, nenásobte barvu lineárně. HDR materiál může mít jas kolem 2 na osmou a lineární násobení od 0 do 10 na něm není vidět vůbec. Pulz počítejte v expozičních stupních (EV), stejně jako posuvník intenzity ve výběru HDR barvy v Unity:

barva = odstín × 2 ^ ev,   ev kmitá mezi minimem a maximem

#Krok 3: Dynamické 2D světlo kolem hráče

K hráči dejte bodové 2D světlo a kolem něj měkkou záři. V Dreamice jedna sinusovka řídí zároveň jas záře, poloměr světla i jeho intenzitu, takže pulzují spolu. Barvu světla může určovat prostředí: v lese je bílá, v bažině oranžová, v zimě fialová, v pekle žlutá. Pozadí a překážky přepněte na osvětlené shadery, jinak na světlo nereagují.

Krátká světla oživí události. Když vystřelí veverka s dělem, rozsvítí se jantarové světlo s intenzitou 3, které za 0,3 sekundy zhasne, a jiskry z hlavně září. Zářit nemusí všechno: prach při zmizení žaludu je záměrně hnědý a nezáří.

#Stejný shader na navazujících plochách

Pokud na sebe navazují dvě pozadí, zdrojové obrázky mají stejný jas, a přesto je mezi nimi vidět šev, zkontrolujte shadery. V Dreamice mělo úvodní pozadí a nekonečné pozadí lesa každé jiný shader. Jeden odstín materiálu 0,733 ignoroval, druhý ho použil a ztmavil les na 73 %. Řešením je stejný shader na obou plochách.

Dva shadery

Jeden shader

#Záblesk: přechod na vrchol místo přičtení

Při přechodu do dalšího světa světlo a záře vzplanou: náběh 0,6 sekundy, krátké podržení, doznění 1,4 sekundy a záře se přitom jednou otočí. Pokud záblesk jen přičtete k pulzu, vrchol závisí na tom, v jaké fázi je sinusovka zrovna v tu chvíli, a každý záblesk je jinak silný. Plynule přejděte z pulzu na pevný vrchol:

váha = křivka záblesku (0 až 1)
hodnota = pulz + (vrchol - pulz) × váha

Přičtení

Přechod na vrchol

#Krok 4: Ostré UI pro dnešní displeje

UI kreslené pro iPhone 7 má malé sprity. Tlačítko v menu Dreamicy mělo sprite 128 × 64 pixelů a na telefonu s trojnásobnou hustotou bodů se roztahovalo na několikanásobek. Překreslete sprity ve větším rozlišení: nové tlačítko má 800 × 434, ukazatele postupu narostly z 200 × 26 na 800 × 104.

128 × 64

800 × 434

Pokud UI stojí na NGUI, zvažte přepis. Kotvy v NGUI se dopočítávají po částech během několika snímků, dlouhé řetězy kotev se občas ustálí špatně a měřítko se liší mezi Editorem, telefonem a iPadem. V Dreamice to opravy spolehlivě nevyřešily, proto jsme UI přepsali na uGUI a TextMeshPro. Postupujte obrazovku po obrazovce a starou verzi mějte zapnutou vedle jako předlohu. UI škálujte podle výšky vůči referenčnímu rozlišení (u nás 434 × 941 bodů) a respektujte bezpečnou oblast displeje, tedy výřez a zaoblené rohy. Po přepisu NGUI z projektu úplně odstraňte, ať v něm nezůstanou dva systémy UI.

#Limity: nekomprimované textury

Tento postup mění jen grafiku. Textury jsme v Dreamice záměrně nekomprimovali, protože jsme chtěli plnou ostrost. Cenou je velikost: už původní hra měla v Editoru 313 MB textur v paměti a v App Store má 299 MB. Komprese by podle našeho odhadu zmenšila textury přibližně na 40 MB. Pokud vám na velikosti hry záleží, je to první místo, kde ušetřit.

Jiný příklad Unity hry od prvního řádku kódu po vydání najdete v článku o hře Space Impact Watch, výkonu v Unity se věnuje článek o navigaci hordy v Unity DOTS. Pokud je hra ještě v Unity 4, neotevírejte ji přímo v Unity 6; bezpečný postup popisuje návod jak převést projekt z Unity 4 do Unity 6. Pokud máte starou Unity hru, která vypadla z obchodů, a chcete ji vrátit zpět, ozvěte se nám.

Když výbuch ve hře odhodí stovky nepřátel najednou, skutečný ragdoll pro každého z nich je příliš drahý. Fake ragdoll v Unity DOTS uděláte tak, že celé tělo nepřítele simulujete jako jeden bod s vlastní jednoduchou fyzikou a model jen otáčíte kolem středu těla. Pád a vstávání jsou obyčejné animační klipy, kosti se nesimulují vůbec.

Postup ukazujeme na tower defense hře pro PC, kterou děláme v Unity s ECS (více v referencích). Bomba nebo fireball tam vymršťuje desítky až stovky nepřátel najednou. Při 2 000 tělech ve vzduchu stojí simulace 0,53 až 0,59 ms na tik (tik je jeden krok herní simulace s pevnou délkou).

#Proč ne skutečný ragdoll

Skutečný ragdoll je deset a více fyzikálních těles spojených klouby na každou postavu. Při tisících postav na obrazovce to není reálné.

Druhý důvod je determinismus: ze stejného stavu musí vyjít stejný výsledek. V naší hře na tom stojí opakování prohrané vlny z kontrolního bodu a kontrolujeme to hashem stavu simulace po 1 800 ticích.

#Tělo jako jeden bod

Místo fyzikálního enginu použijte vlastní jednoduchou 2,5D fyziku: poloha na mřížce, výška nad zemí, balistický let, odraz od stěn a tření. V naší hře se takto pohybuje i bomba a nepřítel zasažený výbuchem se na chvíli stane stejným tělesem. Inspirací bylo, jak odlétají vojáci ve hře Diplomacy is Not an Option.

Simulace zná jen polohu, výšku a úhel natočení. Otáčení modelu do ní nezapisujte. Patří do dodatečné transformační matice entity, kterou balík Entities (ECS v Unity) podporuje pro nerovnoměrné měřítko (dokumentace).

#Fáze sraženého nepřítele

Sražený nepřítel projde třemi fázemi a pak se vrátí do davu:

při zásahu:
    spočítej rychlost odpalu (síla, vzdálenost od výbuchu, náhoda ze seedu)
    najdi dopad na průchozí buňku (viz níže)
    zapni stav "sražený", uvolni místo, které měl obsazené u cíle útoku
let:       těleso letí po parabole, model se otáčí kolem středu těla
dopad:     poloha podle natočení (záda nebo břicho), krátké doklopení
leh:       čeká pevný počet tiků
vstávání:  klip vstávání ze zad nebo z břicha, pak zpět do davu

Stav „sražený“ udělejte jako komponentu, kterou lze zapnout a vypnout bez přesouvání entity mezi chunky (paměťovými bloky, ve kterých ECS drží entity se stejnou sadou komponent). Navigace, odtlačování v davu i rozhodování o útoku pak sražené jednoduše přeskočí. Jak funguje navigace a odtlačování velkého davu, popisuje článek o navigaci hordy v Unity DOTS.

#Odpal: výš, ne dál

Nejjednodušší odpal je pod úhlem 45° ± 10°. Při síle bomby 18 m/s a gravitaci 20 m/s² vychází vrchol letu kolem 4 m. Tělo přeletí nízko nad davem a efekt se v něm ztratí.

Vyšší síla nepomůže, protože s ní roste i dolet. Rozdělte rychlost na dvě složky a každou násobte zvlášť: úhel 60° ± 5°, vodorovná složka × 0,85, svislá × 1,3. Vrchol je pak kolem 10 m, dolet zůstane kolem 15,5 m a let trvá přibližně 2 sekundy.

Směr se od výbuchu odchyluje o ± 15°, síla o ± 20 % a na okraji výbuchu klesá na polovinu. Náhodu neberte z globálního generátoru, ale z hashe seedu levelu, identifikátoru nepřítele a pořadového čísla výbuchu. Požadavky na sražení zpracovávejte seřazené, protože joby běžící na více vláknech je vytvoří v libovolném pořadí. Dva běhy téže vlny tak dají stejné oblouky.

Odhození je ano, nebo ne. Každý sražitelný nepřítel při zásahu aspoň upadne (rychlost je zdola omezená na 2 m/s), odolnost mění jen dolet. Imunitu dejte samostatným příznakem, v naší hře ho má největší typ nepřítele. Kdyby imunita vyplývala z odolnosti (při 0,95 vychází rychlost pod 2 m/s) a slabé odhození by se rušilo, byl by nepřítel imunní jen náhodou.

#Dopad na průchozí buňku

Nepřítel nesmí dopadnout do rokle, na útes ani do půdorysu věže. Průchodnost se určuje po buňkách mřížky a pro každou velikostní třídu nepřítele zvlášť.

#Odraz od stěn ve vzduchu nestačí

První, co napadne, je brát neprůchozí buňky jako stěny, od kterých se letící tělo odrazí. U útesu to vypadá přirozeně, u rokle ne: nad roklí je vzduch, ale buňka je neprůchozí, takže se tělo odrazí od neviditelného sloupu nad jejím okrajem. Navíc nic nezaručuje, že po odrazu skončí na dobrém místě.

#Predikce dráhy při odpalu

Spolehlivější je zjistit dopad hned při odpalu. Let nasimulujte dopředu stejným krokem jako skutečnou fyziku a zkontrolujte buňku dopadu pro velikostní třídu nepřítele. Pokud není průchozí, zkoušejte další varianty v pevném pořadí:

pro úhel v [0, +25, -25, +50, -50, ... , +175, -175]:
    pro násobek vodorovné rychlosti v [1, 0.7, 0.4, 0.1]:
        nasimuluj let
        pokud je buňka dopadu průchozí pro třídu nepřítele: použij tento směr a konec
pokud nic nevyšlo: vodorovná rychlost = 0 (výskok na místě)

Nejhorší případ je 60 simulací letu na jednoho nepřítele (15 směrů × 4 násobky). Svislá rychlost se nemění, takže výška letu zůstává stejná a zkracuje se jen dolet. Pokud nepřítele během letu zasáhne další výbuch, spusťte predikci znovu.

Aby tělo po dopadu neklouzalo ani neodskočilo, nastavte mu koeficient odrazu od země 0 a velké tření. Zůstane tam, kde predikce řekla.

#Rotace naplánovaná podle výšky letu

Nejjednodušší je točit model náhodnou rychlostí, například 180 až 540 °/s, a po dopadu ho za 0,2 s doklopit do nejbližšího lehu. Doklopení je ale vidět, když tělo dopadne téměř vzpřímeně. Dorovnávat rychlost otáčení v každém tiku tak, aby úhel při dopadu vyšel přesně vodorovně, pomůže jen částečně: i nízký odhoz se točí jako salto a otáčení nesouvisí s tím, jak vysoko tělo letí.

Lepší je naplánovat rotaci při odpalu z výšky letu:

výška = vz² / (2 g), čas letu z vz a výšky
cíl = nejbližší vodorovná poloha v náhodném směru (čtvrt otáčky ze stoje)
cíl += půlotáčka za každých 2,5 m výšky, nejvýš 3
rychlost otáčení = (cíl - aktuální úhel) / čas letu

Strana dopadu vyplývá z úhlu: obličejem k zemi znamená břicho, jinak záda. Podle ní se vybere klip vstávání. Ležící nebo vstávající nepřítel si při dalším zásahu ponechá aktuální úhel a neskočí zpět do vzpřímené polohy.

#Model položený na zem

Model se otáčí kolem středu těla, ale země je pod jeho nejnižším bodem a ten se při otáčení mění. Odhad posunu ze dvou konstant a sinu úhlu nesedí pro modely s rozhozenýma rukama v klipu pádu: v naší hře se model kostlivce (běžný nepřítel) zanořoval až 1,15 m pod zem a model nekromanta až 1,73 m.

Odhad

Změřeno

Spolehlivější je nejnižší bod změřit. Při zapékání (bake) animací spočítejte pro klip pádu nejnižší bod těla při 72 natočeních po 5° a za běhu z tabulky interpolujte. Nejhlubší zanoření tak klesne na 4 mm. Jedno minimum přes všechny snímky klipu ale nestačí: tělo by po dopadu viselo 0,15 až 0,28 m nad zemí, dokud ho klip vstávání nestáhne dolů. Tabulka proto musí mít rozměr snímky × natočení.

Při pomalé naplánované rotaci se ukáže ještě jeden efekt. Pokud model pokládáte nejnižším bodem na výšku letu, střed těla při přechodu ze stoje do vodorovné polohy klesne o rozdíl poloviny výšky a poloviny tloušťky postavy. Tělo pak na začátku letu stoupá jen pomalu a teprve potom zrychlí. Model proto zvedněte o rozdíl polovičního rozměru ve stoje a při aktuálním úhlu, nejvýš o výšku letu. Střed těla pak jde po parabole.

#Mrtví nepřátelé: tělo, decal a prach

Nepřítel zabitý výbuchem má odletět také. Vytvořte pro něj letící tělo: kopii entity bez herních komponent (životy, odměna, cíl). Tělo přeletí, dopadne, chvíli leží a zmizí. Na jeho místě zůstane decal mrtvoly (textura promítnutá na zem) jako ve Warcraftu 3 a obláček prachu. V naší hře je strop 1 000 letících těl a 1 500 decalů.

Decal je pohled shora na snímek z klipu pádu, natočený stejně jako ležící tělo, takže výměna těla za decal není vidět. První snímek klipu vstávání se nehodí, protože postavu ze zad už posadí. Obláčky prachu slučujte v buňce 1,5 m. Bomba do davu tak vytvoří pár větších mraků místo stovek malých.

#Pasti v Unity Entities

• Matice z bakeru zmizí. Pokud dodatečnou matici přidáte při bake, transformační systém ji při rovnoměrném měřítku odstraní a sražení se nehýbou. Při bake si proto vyžádejte nerovnoměrné měřítko. Tehdy se ale do stejné matice přesune celé měřítko prefabu, takže ho nepřepisujte samotnou rotací. Jinak má sražený nepřítel se zvětšením 2× poloviční velikost, i když vstane. Měřítko si uložte zvlášť a matici skládejte z měřítka a rotace.
• Výška kořene při importu klipů. U humanoid klipů se svislý pohyb kořene (root) zahodí a postavy při vstávání propadnou pod podlahu. Výšku kořene zapečte do pózy. Volbu ukotvit pózu na chodidla nepoužívejte, posune celé tělo o metr dolů.
• Matice v uzavřeném tvaru. Posun, rotace a zpětný posun jako tři násobení matic jsou v jobu měřitelně pomalejší než ručně napsaný vzorec pro výslednou matici.
• Burst se starou verzí. Po změně polí komponenty, kterou čte Burst job, může editor padat nebo hlásit nesmysly. Pomůže restart editoru.

#Výkon

Měřeno v Unity Editoru na M3 Pro, 10 000 kostlivců v benchmark scéně, síla odpalu 18. Časy jsou součet CPU času Burst jobů přes všechna vlákna, ne čas snímku. Graf a tabulka jsou bez predikce dráhy a tabulek dopadu.

• Simulace roste lineárně, zhruba o 0,25 ms na tisíc sražených. S predikcí dráhy a tabulkami dopadu je to při 2 000 sražených 0,58 až 0,59 ms, tedy mírně nad cílem 0,5 ms. Rozumný strop je proto 3 000 současně sražených, což je kolem 0,8 ms.
• Výbuch do skupiny 359 nepřátel u stěny stojí v systému požadavků na sražení 1,3 až 1,9 ms v jednom snímku. Většinu tvoří predikce dráhy.
• FPS z editoru se porovnat nedá, mezi dvěma běhy stejné konfigurace byl rozdíl až 80 FPS.

#Limity řešení

Příprava vizuálu stoupla v jiné testovací scéně až na 1,3 ms, pravděpodobně kvůli čtení tabulky dopadu pro každé tělo. Je to první kandidát na optimalizaci. FPS v buildu a zátěž při hromadném zabití 1 000 nepřátel najednou (cíl do 1,5 ms navíc na snímek) zatím nemáme změřené.

Pokud řešíte podobnou simulaci davu nebo efektů v Unity a potřebujete pomoc, napište nám.

Shmup (shoot 'em up, střílečka, ve které loď letí proti vlnám nepřátel) na Apple Watch naráží na tři věci: malý displej, prst, který zakryje polovinu hry, a různé velikosti hodinek. Řeší se třemi rozhodnutími: celá hra běží v pevné mřížce 84 × 48 bodů, kolize se počítají ručně obdélníky a levely jsou tabulky s časy, ne kód. Loď se ovládá korunkou Digital Crown a střílí sama.

Postup ukazujeme na hře Space Impact Watch, remaku střílečky Space Impact z telefonu Nokia 3310 z roku 2000, která běží na hodinkách i na iPhonu a iPadu. Příklady jsou ze SpriteKitu, 2D herního frameworku od Applu, ale principy platí pro každý shmup na malou obrazovku.

#Pevné virtuální rozlišení 84 × 48

Nejprve se rozhodněte, v jakých jednotkách bude hra počítat. Pokud použijete body obrazovky, svět bude na každé velikosti hodinek jinak velký. Lepší je zvolit malé virtuální rozlišení a všechno počítat v něm. V naší hře je to 84 × 48, přesně jako měl displej Nokie 3310. Pozice, rychlosti, velikosti spritů i dráhy nepřátel jsou v těchto jednotkách. Při startu scény se jednou spočítá, kolik bodů obrazovky má jeden virtuální pixel (šířka scény děleno 84), a vše se jím jen vynásobí.

Co tím získáte:

• Stejný vzhled na každém zařízení. Hra vypadá stejně na každé velikosti hodinek i na iPadu, mění se jen velikost bloku.
• Level design v malých celých číslech. Nepřítel letí ve výšce 13, raketa zatáčí v bodě x = 20.
• Jednoduchou grafiku. Sprity jsou jednobarevné a kreslené v desetinásobné velikosti, jeden virtuální pixel je ve zdrojovém obrázku blok 10 × 10. Barvu dostanou až ve hře. Na světlých levelech jsou černé na zeleném pozadí, na tmavých je to obráceně.

#Ovládání korunkou a automatická střelba

Na hodinkách prst zakryje polovinu hry, proto se loď neovládá dotykem. Pohyb řeší Digital Crown: otočení korunky posune loď nahoru nebo dolů. Přidejte nastavení citlivosti a možnost otočit směr.

Střelba je automatická, v naší hře každých 0,4 sekundy, od čtvrtého levelu každých 0,3. Displej slouží jen pro jedno gesto: přetažením doprava hráč použije jednu ze tří speciálních zbraní.

Na hodinkách je vibrace při zásahu stejně důležitá jako animace, malý výbuch na displeji si hráč snadno nevšimne. Haptiku volejte přes jedno rozhraní (zásah, smrt nepřítele, poražený boss), které každá platforma provede po svém: hodinky vibrací, iPhone vlastním způsobem. Verze pro telefon nemá korunku, místo ní má tlačítka na displeji, která používají stejné nastavení citlivosti i směru.

#Herní smyčka v jedné scéně

Celá hra může být jedna scéna s jednou smyčkou:

každý snímek:
    posuň všechny objekty
    zkontroluj kolize
    podle času v levelu přidej nové nepřátele

Věci přidávejte v pořadí, ve kterém se dají co nejdříve testovat:

• Střelba a pohyb hráče. Bez nich se nedá nic otestovat.
• Nepřátelé a kolize. Prvnímu nepříteli stačí letět rovně doleva a zemřít po jednom zásahu.
• Vibrace a animace zásahu. Na malém displeji bez nich hráč neví, že zasáhl.
• Pozadí a HUD. Životy, skóre, počet speciálních zbraní. Pokud HUD v některém levelu překáží, přesuňte ho dolů.

Na konci máte hratelnou smyčku se životy, skóre, výbuchy, pozadím a respawnem hráče. Pokud herní logiku držíte odděleně od vykreslování a vstupu, mohou ji sdílet verze pro hodinky i telefon.

#Kolize obdélníky místo fyzikálního enginu

SpriteKit má fyzikální engine a nabízí se použít ho i na kolize. Každý objekt dostane fyzikální tělo vytvořené z obrysu spritu, přesnou detekci kolizí a kategorii (hráč, nepřítel, střela, speciální zbraň) a engine sám hlásí dvojice, které se dotkly. Apple v dokumentaci k fyzikálním tělům uvádí, že těla z alfa kanálu textury jsou nejpřesnější a zároveň výpočetně nejdražší. V naší hře jsme to zkusili a vrátili jsme se k ruční kontrole.

Ruční kontrola je jedna funkce, která postupně projde dvojice skupin a porovná obdélníky:

pro každou dvojici skupin:
    (hráč a nepřátelé, hráč a střely, střely a nepřátelé, střely a střely)
    pro každý objekt A z první skupiny a objekt B z druhé:
        pokud se obdélník A překrývá s obdélníkem B:
            vyřeš zásah

Výhody: pořadí kontrol máte pod kontrolou a celé pravidlo „co se stane při zásahu“ je na jednom místě. Nepřesnost je malá, protože na mřížce 84 × 48 jsou sprity tak drobné, že obdélník a skutečný obrys se liší jen o pár virtuálních pixelů.

#Pooling jen tam, kde se vyplatí

Pooling znamená, že objekt po zániku nesmažete, jen ho skryjete a příště použijete znovu. Je lákavé poolovat všechno včetně výbuchů a power-upů. Má to ale cenu: každá kolize a každý update musí nejdřív ověřit, jestli je objekt vůbec živý. Stačí jedna zapomenutá kontrola a skrytý nepřítel zabije hráče nebo skrytá střela sestřelí raketu. Když jsme v naší hře pooling ze všeho odstraňovali, mazali jsme hlavně tyto kontroly.

Jednoduché pravidlo: poolujte to, čeho je hodně a vzniká to pořád stejně. Hráč si při startu vytvoří 21 střel a pak je jen recykluje. Nepřátelé a jejich střely se také znovu používají, výbuchy a power-upy vznikají a zanikají normálně.

#Levely jako tabulka časů

Level nemusí být kód, stačí seznam záznamů. Každý záznam říká, co se objeví, v které sekundě, v jaké výšce a jak se pohybuje. Pohyb je seznam bodů, kterými nepřítel letí stejnou rychlostí. Volitelně přibudou časy výstřelů, výpad bosse nebo generátor menších nepřátel.

každý snímek:
    čas = teď - začátek levelu - čas v pauze
    pro každý záznam v tabulce levelu:
        pokud záznam ještě nebyl použit a čas > záznam.čas:
            vytvoř objekt podle záznamu
            označ záznam jako použitý

Takto zapsaný level se snadno ladí: posunout vlnu o půl sekundy znamená změnit jedno číslo. Na časové ose je vidět i rytmus, o který jde: krátká vlna, pauza, jiný typ nepřítele, power-up před těžším úsekem.

Nevýhodu cítit při větších změnách. Nejhustší level naší hry má 71 řádků a taková tabulka se bez editoru čte špatně. Výhodnější je zapisovat levely jako vlny (skupina nepřátel s jedním vzorem pohybu), ne jako jednotlivé lodě.

#Nekonečný režim z jednoho pseudonáhodného čísla

Pro žebříček (v naší hře Game Center) potřebujete režim, který nekončí. Ručně psanou tabulku v něm nahradí generátor, který ji vyrábí za běhu. Vyrobí 20ciferné pseudonáhodné číslo a jednotlivé dvojice číslic rozhodnou o jedné vlně:

číslo = další pseudonáhodné 20ciferné číslo
typ = power-up, pokud číslice 4 až 5 > 90, jinak nepřítel
sprite = číslice 1 až 2 modulo počet druhů nepřátel
pauza před vlnou = číslice 3 / 2 sekundy (aspoň 1)
výška = číslice 7, přepočtená na výšku plochy
vzor pohybu = číslice 10 až 11 modulo 10
počet lodí ve vlně = číslice 17 / 2 + 1
rychlost = číslice 13 × (1 + pořadí vlny / 10), v rozsahu 20 až 50
každá třicátá vlna = boss, generování stojí, dokud boss žije

Seed generátoru (počáteční hodnotu) nechte ve hře pevný. Každý hráč pak dostane stejné pořadí vln a skóre v žebříčku se dá porovnávat.

Jak se takový režim vyvíjí, ukazuje simulace generátoru mimo hru (300 vln, stejný seed jako ve hře). První boss přijde po 29 vlnách, tedy po 74 nepřátelích a 3 power-upech, zhruba po 130 sekundách. Prvních 30 vln letí minimální rychlostí 20, protože jedna číslice je ještě menší než dolní hranice. Průměrná rychlost pak roste na 28,5, 37,5 a 41, od 120. vlny je většina nepřátel na maximu. Power-up je přibližně každá jedenáctá vlna.

Slabina je, že generátor nezná rytmus. Ruční level střídá tlak a oddech, generátor ne. Částečně to řeší pauza během bosse a růst rychlosti, ale ručně psané levely se hrají lépe.

#Limity tohoto přístupu

• Žádné automatické testy. Všechno se ověřuje ručně v simulátoru a na hodinkách.
• Globální stav. Většina stavu hry jsou globální proměnné jedné scény. Pro hru jen na hodinky je to pohodlné, při přidání verze pro iPhone už ne.
• Levely bez editoru. Tabulka časů se dobře ladí po malých krocích, při větších změnách by si zasloužila editor.

Pokud děláte hru na hodinky nebo jinou malou obrazovku a potřebujete s něčím pomoct, napište nám. Jak generujeme hlavolamy v jiné naší aplikaci, jsme popsali v článku o generátoru sudoku.

Sudoku s jediným řešením vygenerujete ve dvou krocích. Nejdřív vyplňte prázdnou mřížku 9×9 celou, backtrackingem s náhodným pořadím číslic. Potom z ní po jednom a v náhodném pořadí mažte políčka a po každém smazání solverem zkontrolujte, jestli má zadání stále právě jedno řešení. Pokud ne, číslici vraťte zpět. Na běžném procesoru to trvá v mediánu méně než milisekundu.

Postup se hodí pro každou hru nebo aplikaci, která potřebuje neomezený počet nových zadání bez ruční přípravy. Takto vznikají sudoku například v naší aplikaci s křížovkami a hlavolamy (App Store, Google Play).

#Proč právě jedno řešení

Pravidla sudoku zná každý: v každém řádku, sloupci a čtverci 3×3 je každá číslice 1 až 9 právě jednou. Méně se mluví o tom, že dobré zadání má jediné řešení. Teprve pak se dá vyřešit čistou logikou, bez hádání.

Má to i praktický důsledek. Hra si obvykle pamatuje jedno řešení a podle něj kontroluje výsledek a dává nápovědy. Pokud má zadání řešení dvě, hráč může dojít k tomu druhému, které je stejně správné, a hra mu ho neuzná.

#Krok 1: Napište rychlý solver

Solver je program, který sudoku vyřeší. Pracuje backtrackingem: vyplní políčko jednou z možných číslic, pokračuje dalším políčkem, a když narazí na spor, vrátí se a zkusí jinou číslici. Budete ho potřebovat dvakrát: na vyplnění prázdné mřížky a na kontrolu jednoznačnosti. Kontrola běží po každém smazaném políčku, tedy 40 až 70krát na jedno zadání, proto musí být rychlá. Rozhodují dvě věci:

• Bitové masky. Pro každý řádek, sloupec a čtverec udržujte 9bitové číslo s už použitými číslicemi. Kandidáti políčka, tedy číslice, které do něj ještě můžou přijít, jsou pak jedna operace: všechny číslice kromě těch, které jsou v jeho řádku, sloupci nebo čtverci. Počet kandidátů je počet jedničkových bitů a dá se předem spočítat do tabulky s 512 hodnotami.
• Nejdřív políčko s nejmenším počtem kandidátů. Nevybírejte první prázdné políčko zleva, ale to, které má nejméně možností (v literatuře heuristika MRV, minimum remaining values). Políčko s jediným kandidátem vyplňte hned, políčko bez kandidáta znamená slepou větev a vracíte se.

Na těžkých zadáních potřebuje kontrola jednoznačnosti s tímto pravidlem v mediánu 311 kroků. Pokud solver bere políčka postupně zleva doprava, v mediánu 28 579 kroků a v nejhorších 5 % případů přes 300 000. Rozdíl je zhruba 90násobný.

#Krok 2: Vyplňte celou mřížku

Plnou mřížku dostanete stejným solverem spuštěným na prázdné mřížce. Jediný rozdíl je, že kandidáty políčka zkoušíte v náhodném pořadí. První nalezené řešení je náhodná, platná, úplně vyplněná mřížka.

#Proč nestačí smazat náhodná políčka

Nejjednodušší nápad je smazat z plné mřížky N náhodných políček, například 40, 50 nebo 55 podle obtížnosti. Zadání vypadá v pořádku, jen často nemá jediné řešení.

Typický případ je na obrázku. Čtyři políčka v rozích obdélníku, který zasahuje do dvou čtverců, se dají vyplnit dvěma způsoby a zbytek mřížky to nijak nerozhodne. Řešitelé sudoku tento vzor znají jako deadly pattern. Na 1 000 zadáních pro každou obtížnost vypadá výsledek takto:

Těžké zadání z náhodného mazání má v průměru stovky řešení. Kontrola jednoznačnosti po každém smazání je proto nutná.

#Krok 3: Mažte s kontrolou jednoznačnosti

Projděte všech 81 políček v náhodném pořadí. Každé zkuste smazat a solverem spočítejte řešení, ale počítání zastavte u dvou. Víc vědět nepotřebujete: jedno řešení znamená, že políčko může zůstat prázdné, dvě znamenají, že ho musíte vrátit.

zadání = kopie plné mřížky
prázdných = 0
pro každé políčko v náhodném pořadí:
    pokud prázdných == cíl: konec
    číslice = zadání[políčko]
    zadání[políčko] = prázdné
    pokud počet_řešení(zadání, nejvýš 2) == 1:
        prázdných = prázdných + 1
    jinak:
        zadání[políčko] = číslice

Políčko, které jednou vrátíte, už nezkoušejte znovu. Další mazání zadání jen uvolňuje, takže pokud políčko nešlo smazat teď, nepůjde ani později.

#Krok 4: Nastavte obtížnost počtem prázdných políček

Nejjednodušší míra obtížnosti je počet smazaných políček. Tři úrovně, které používáme v naší hře:

Čím méně číslic zbývá, tím častěji by další smazání pokazilo jednoznačnost a políčko se musí vrátit. U těžké úrovně se jeden průchod občas zastaví dřív, než dosáhne 55 prázdných políček. Pak vygenerujte novou plnou mřížku a zkuste to znovu. Při měření na 1 000 těžkých zadáních stačil první průchod v 97,6 % případů a nikdy nebylo potřeba víc než 3 pokusy.

#Rychlost a spolehlivost generátoru

Generátor jsme spustili na 1 000 zadáních pro každou obtížnost (Node.js 22 na serverovém procesoru, telefon bude pomalejší):

Každé vygenerované zadání jsme navíc nezávisle zkontrolovali solverem. Všech 3 000 mělo jediné řešení.

#Kde počet prázdných políček nestačí

Počet vodítek je hrubá míra obtížnosti. Dvě zadání s 26 číslicemi můžou být různě těžká podle toho, jaké logické techniky vyžadují. Přesnější obtížnost by zadání vyřešila jako člověk a zaznamenala nejtěžší techniku, kterou musela použít. Pro mobilní hru, kde si hráč vybírá ze tří úrovní, počet vodítek stačí.

Pokud řešíte podobný problém, generujete hlavolamy nebo potřebujete mobilní aplikaci, napište nám. Jak vygenerovat osmisměrku s tajenkou, popisuje samostatný návod. Švédské křížovce s tajenkou se věnuje další návod.

Švédskou křížovku s tajenkou vygenerujete ve dvou fázích: nejdřív lokálním prohledáváním najděte masku, tedy rozmístění políček s legendami a políček na písmena, a potom ji vyplňte slovy ze slovníku jako úlohu s omezeními (CSP) s backtrackingem. Tajenku do mřížky předem nevkládejte. Teprve když je křížovka hotová, hledejte vtip, jehož pointa se v ní dá přečíst zleva doprava a shora dolů.

Takto vznikají švédské křížovky v naší aplikaci s křížovkami a osmisměrkami (App Store, Google Play). Jedna mřížka zabere několik až desítky sekund procesorového času, proto je generujeme předem na výkonnějším počítači a přibalíme je do aplikace. Osmisměrka se generuje úplně jinak a jednodušeji, postup je v článku Jak vygenerovat osmisměrku s tajenkou.

#Co musí švédská křížovka splňovat

Švédská křížovka nemá černá políčka. Každé políčko je písmeno, nebo legenda se šipkou doprava či dolů. Z toho plynou tvrdé podmínky:

• Každé písmeno patří vodorovnému i svislému slovu. Písmeno, které kříží jen jedno slovo, nejde zkontrolovat a v křížovce působí jako chyba.
• Každé slovo má aspoň dvě písmena a před ním je legenda. Proto jsou první řádek a první sloupec vždy tvořené jen legendami.
• Písmena tvoří jeden souvislý celek, žádné odtržené ostrovy.
• Každé slovo musí být ve slovníku a mít aspoň jednu legendu. Žádné slovo se v mřížce neopakuje.

K tomu měkká kritéria kvality: málo dvoupísmenných slov, žádné legendy, které nikam neukazují, a co nejméně velmi dlouhých slov, která se těžko plní. Problém je výpočetně těžký. Engel a kol. (2012) ukázali, že už samotné plnění masky slovy je NP-úplné.

#Proč nestačí plnit mřížku slovo po slově

První nápad je postupovat jako člověk s tužkou: rozdělit tajenku na slova, položit je do řádku jako v novinách, přes každé její písmeno vést křížící slovo a zbytek mřížky doplňovat greedy algoritmem. Greedy algorithm v každém kroku vybere možnost, která vypadá nejlépe právě teď, a rozhodnutí už nikdy nepřehodnotí. Kde nic nesedí, zůstane díra. A protože se greedy plnění neumí vrátit, špatných prvních deset slov zbytek mřížky už nezachrání.

Lepší heuristika výběru slov pomůže jen trochu. Můžete zkoušet délky křížících slov od středních, kolem pěti písmen, ke krajním. Nebo použít evoluční přístup: populace rozpracovaných křížovek, z každé pět potomků s jedním slovem navíc, hodnocení podle počtu zaplněných políček, počtu samohlásek a rovnoměrnosti písmen a do další generace postoupí jen ty nejlepší. Výsledky jsou o něco hustší, ale díry zůstanou, protože heuristika vidí jen nejbližší krok.

Řešení přináší bakalářská práce Jakoba Engela z TU Mnichov (2009), který je i prvním autorem zmíněného článku. Úlohu rozdělte na dvě nezávislé fáze: nejdřív najděte dobrou masku bez ohledu na slova, potom ji plňte. Engel na masku použil evoluční algoritmus. My používáme jednodušší lokální prohledávání s náhodnými otřesy, popsané v dalším kroku.

#Krok 1: maska přes hill climbing

Maska je mřížka, ve které je každé políčko buď legenda, nebo písmeno. K jejímu hledání stačí hill climbing: lokální prohledávání, které dělá malé změny a ponechá ty, které řešení nezhorší.

Začněte náhodně, s legendami asi na 22 % vnitřních políček. Každou masku ohodnoťte pokutou. Tvrdá porušení (příliš krátké slovo, písmeno bez křížícího slova, odtržený ostrov) ať stojí většinou 1 000 bodů, měkké nedostatky (dvoupísmenná slova nad rozpočet, legenda, která neukazuje na žádné slovo, shluky legend) 50 až 500.

Potom v cyklu změňte jedno políčko z legendy na písmeno nebo naopak, případně posuňte legendu o políčko šikmo. Změnu ponechte, pokud se pokuta nezvýšila, jinak ji vraťte. Polovinu změn zamiřte na políčka s nejvyšší pokutou, pak hrubé chyby zmizí rychle:

Hill climbing snadno uvízne v lokálním minimu. Když se za 2 000 kroků nic nezlepší, mřížkou „zatřeste“: v nejlepší dosud nalezené masce náhodně přehoďte pět políček a hledejte dál. V grafu jsou to špičky. Pokud ani po třech zatřeseních není maska lepší a nemá tvrdá porušení, skončete.

Výsledná maska má zbytkovou pokutu 200 za měkké nedostatky, ale žádné tvrdé porušení:

Pokuty za legendu bez slova a za odtržený ostrov se vyplatí mít v masce od začátku. Na velkém souboru hotových křížovek bez nich mělo 13,2 % legend, které neukazovaly na žádné slovo, a 23,5 % mřížek odtržený ostrov písmen. S nimi je to 5,0 % a 0 %.

#Krok 2: plnění slovy jako CSP

Z masky vznikne seznam slotů, tedy míst na slova se známou délkou a kříženími. Plnění je klasická úloha s omezeními (constraint satisfaction problem, CSP): každý slot je proměnná, jeho doména jsou slova, která se do něj vejdou, a omezení jsou shodná písmena v kříženích. Řeší se backtrackingem, tedy prohledáváním, které se ve slepé větvi vrátí o krok zpět a zkusí jinou možnost:

pro každý slot: doména = všechna slova dané délky
dokud nejsou všechny sloty vyplněné:
    vyber slot s nejmenší doménou (při shodě ten s nejvíc kříženími)
    pro každé slovo z domény, od nejlepšího:
        polož slovo
        zuž domény křížících slotů na slova se shodným písmenem
        pokud některá doména zůstala prázdná: vrať změnu, zkus další slovo
        jinak pokračuj dalším slotem
    pokud žádné slovo nevyhovuje: vrať se o slot zpět
po 50 000 krocích to vzdej

V literatuře se tyto heuristiky jmenují MRV (minimum remaining values, nejdřív slot s nejméně možnostmi) a forward checking (po každém položení zúžit domény sousedů, aby se slepá větev odhalila hned, ne o deset slov později). Slovník si předpočítejte podle délky, pozice a písmene. Slova se „Š na třetím místě“ jsou pak jeden průnik množin, ne průchod celým slovníkem.

Důležité je i pořadí slov. Přednost dejte slovům, která mají ve slovníku víc různých legend. Je to jednoduchý ukazatel běžného křížovkářského slova. Bez něj se mřížka zaplní neznámými zkratkami.

#Krok 3: tajenka až v hotové mřížce

Při plnění ještě nevíte, jaká bude tajenka. Přečtěte písmena hotové mřížky zleva doprava a shora dolů a hledejte vtip, jehož pointa je v tomto řetězci podposloupností. Písmena tedy jdou ve správném pořadí, ale nemusí být vedle sebe. Pokud se najde, rozmístěte písmena tajenky co nejrovnoměrněji po mřížce, aby se pointa nedala uhodnout z jednoho slova.

Toto pořadí (nejdřív mřížka, potom vtip) zásadně zvyšuje počet hotových křížovek. Jedna mřížka 12×12 se podle našeho měření v průměru hodí pro 86 vtipů ze slovenského seznamu (5 960 vtipů). Vždy se tedy najde takový, který ještě v dané velikosti nebyl použit.

#Proč nevkládat tajenku předem jako v novinách

V novinách je tajenka obvykle pohromadě, v jednom řádku a rozdělená na slova. Dá se toho dosáhnout dvěma způsoby a oba dávají velmi málo výsledků.

První způsob je vložit tajenku do mřížky předem. Pak se do ní musí vejít. Pointa má u nás v průměru 10,3 písmene a 2 slova. Takto vypadá podíl vtipů ze slovenského seznamu, které se do dané velikosti vůbec dají položit:

S tajenkou vloženou předem uspěje plnění u malých mřížek přibližně stejně často jako bez ní. U 15×15 to bylo 5 z 60 pokusů oproti 8 bez tajenky, u 18×18 ani jeden z 60. Každá taková mřížka navíc slouží jedinému vtipu a u malých velikostí se většina vtipů nedá ani položit.

Druhý způsob je nechat mřížku vzniknout volně a pointu v ní hledat jako souvislý úsek. Na vzorku 2 200 hotových slovenských křížovek (200 z každé velikosti od 8×8 po 18×18) se celá pointa jako souvislý úsek v jednom řádku nebo sloupci našla jen v 81 mřížkách (3,7 %). Když smí každé slovo pointy ležet jinde, je to 443 mřížek (20 %), a to ještě bez podmínky, že slova budou u sebe. Při čtení v pořadí se vtip našel v každé z nich. Za cenu tajenky roztroušené po mřížce dostanete řádově víc křížovek.

#Výkon generátoru a proč neběží v telefonu

Generátor běžel 60 pokusů pro každou velikost se slovenským slovníkem, v jednom vlákně (JavaScript v Node 22, serverový procesor Intel Xeon 2,8 GHz v cloudu). Pokus je jedna maska a jedno plnění. „Úspěšné plnění“ znamená, že CSP našel řešení do 50 000 kroků.

Co z měření plyne:

• Malá mřížka není snadná. V 8×8 je hodně krátkých slotů s velkým počtem křížení a málo volnosti, plnění uspěje jen v 5 % pokusů. Jedna vyplněná mřížka stojí v průměru asi 10 sekund procesorového času u 8×8, 4 sekundy u 12×12 a 18 sekund u 18×18.
• Většina pokusů skončí neúspěchem. Pokusy proto spouštějte paralelně na všech jádrech a berte první dost dobrý výsledek.
• V telefonu to nedává smysl. Hráč nechce při otevření obrazovky čekat desítky sekund a aplikace by musela nést celý slovník s legendami. Generátor v aplikaci navíc musí často pouštět ke slovu UI, jinak aplikace zamrzá.

#Generování ve velkém

Generátor proto patří na počítač s vícejádrovým procesorem. U nás má každé jádro vlastní vlákno se slovníkem načteným jednou při startu. Mřížka je hotová, když některé vlákno vrátí výsledek s dostatečně malým počtem nevyužitých políček. Nepřetržitý režim generuje dokola jednu křížovku z každé velikosti v každém jazyce. Takto vzniklo přes 14 000 křížovek ve čtyřech jazycích (slovenština, čeština, angličtina, němčina) a jedenácti velikostech od 8×8 po 18×18. Každý vtip je v dané velikosti a jazyce použitý nejvýš jednou.

Při takovém objemu rozhodují dvě věci:

• Formát. Úplný zápis má kolem 28 kB na křížovku a celý korpus 390 MB. Většina se dá dopočítat (souřadnice, typy políček, čísla legend). Kompaktní zápis s mřížkou jako jedním řetězcem má kolem 2 kB, celý korpus 15 MB a v instalačním balíčku aplikace asi 7 MB.
• Měření kvality. Podíl legend bez slova a mřížek s ostrovy měřte po každém generování a nechte kontrolu selhat, pokud se čísla zhorší.

#Co řešení nepokrývá

• Legendy bez slov. Průměrná křížovka má pořád 2,7 legendy, které nikam neukazují. Levý horní roh je takový vždy.
• Slovník bez frekvencí. Německý slovník z Wiktionary má u většiny slov jedinou legendu, takže řazení podle počtu legend skoro nerozlišuje a do mřížky se dostávají vzácná slova. Pomohl by frekvenční slovník, zatím ho nemáme.
• Tajenka není pohromadě. Kdo je zvyklý na tajenky z novin, může ji hledat v řádku. Je to kompromis, ne ideál.

Pokud řešíte podobný problém s generováním obsahu nebo potřebujete mobilní aplikaci, napište nám.

3D model telefonu vygenerujete v prohlížeči tak, že obdélník se zaoblenými rohy vytáhnete do hloubky a pak z něj booleovskými operacemi (CSG) vyříznete přední stranu, tlačítka, reproduktory a konektor. Celé zařízení pak popisuje pár čísel v milimetrech a nový model znamená změnit tato čísla, ne modelovat ve 3D programu.

Hodí se to všude, kde potřebujete hodně podobných zařízení nebo je má upravovat uživatel: konfigurátory, mockupy, náhledy produktů. Jako příklad z praxe slouží Ecranify, nástroj na 3D mockupy pro screenshoty do App Store a Google Play, ve kterém není ani jeden hotový 3D model. Níže je postup krok za krokem i s měřením, které ukazuje, kde se dá na výpočtu ušetřit nejvíc.

#Co budete potřebovat

• Three.js na scénu, kamery, světla a hlavně geometrii. Geometrie je v Three.js mesh, tedy síť trojúhelníků.
• Knihovnu three-bvh-csg na booleovské operace nad meshi. Zrychluje je prostorovým indexem (BVH, bounding volume hierarchy), díky kterému netestuje každý trojúhelník proti každému.
• Popis zařízení jako data, například JSON s rozměry těla, poloměrem rohů, velikostí bevelu a seznamem prvků na bocích. Všechny polohy zadávejte v milimetrech od středu zařízení.

#Krok 1: Vytáhněte obdélník do 3D

Nakreslete 2D obdélník se zaoblenými rohy ve skutečných rozměrech, například 163,4 × 78 mm, a vytáhněte ho (extruze) do hloubky 8,75 mm. Dostanete desku s ostrými hranami. Žádný telefon takové nemá, proto při vytahování zapněte i bevel, tedy zaoblení hrany. Three.js dělá obojí v jednom kroku.

Jen extruze

+ rohy a bevel

Pozor na jednu věc: bevel se přidává směrem ven. Pokud chcete přesný vnější rozměr, zmenšete 2D tvar i hloubku o velikost bevelu.

b = min(bevel, hloubka / 2)
tvar = zaoblený obdélník(šířka - 2b, výška - 2b, poloměr rohu - b)
tělo = vytáhni(tvar, hloubka - 2b, bevel b)

Hladkost oblouků (teselaci) určuje počet segmentů, na které se oblouk rozdělí. Víc segmentů znamená hladší tvar a víc trojúhelníků. Toto číslo později rozhodne o rychlosti celého výpočtu, proto se k němu vrátíme v kroku 7.

#Krok 2: Vyřízněte vanu pro displej

CSG (constructive solid geometry) skládá tělesa z jednodušších těles pomocí tří operací: sjednocení, rozdíl a průnik. Rozdíl funguje jako vrták: jedno těleso odebere materiál z druhého.

Displej telefonu není zarovnaný s rámem, sedí v mělké vaně. Tu vyrobíte tak, že uděláte druhou, o 1,4 mm menší kopii těla, necháte z ní jen přední část silnou 0,7 mm (průnik s velkým kvádrem) a tuto část odečtete od těla. Do vzniklé vany pak vložíte tmavou plochu displeje.

Řezné těleso

Po odečtení

Dva praktické detaily:

• Kvádr pro průnik musí být opravdu velký. Stačí mu ořezávat hloubku, ale v šířce a výšce musí přesahovat celé zařízení. Neodvozujte ho od hloubky: například 20násobek hloubky je u tenkého vysokého telefonu méně než jeho výška a nahoře a dole zůstane neořezaný rám.
• Zvětšete řezné těleso o pár promile. Když mají dvě tělesa přesně stejnou plochu, CSG si neví rady, která strana je uvnitř. Měřítko 1,002 tomu předejde a okem ho nevidíte.

#Krok 3: Boční prvky připravte jako vrtáky

Každý prvek na boku je stejný recept s jiným vrtákem. Tlačítko například vznikne ze tří těles: zaoblený obdélník o kousek hlubší než tlačítko se odečte od rámu, okraj otvoru dostane malé zkosení a do otvoru se vloží o něco menší těleso, které z rámu trochu vyčnívá.

Vrtáky

Výřez a tlačítko

Reproduktory jsou řada malých válců, konektor je zaoblený obdélník. Do každého otvoru vložte něco tmavého: tenký disk do mřížky, destičku do konektoru. Prázdná díra v tenké skořepině působí jako chyba, díra s tmavou výplní působí jako hardware.

pro každý prvek v seznamu prvků boku:
    vrták = tvar prvku (válec, zaoblený obdélník, ...)
    umísti vrták na hranu podle polohy v mm
    přidej vrták do seznamu řezů
    pokud má prvek výplň: přidej výplň do scény

Přidat tlačítko je pak zápis do dat. Prvků rychle přibývá: iPad Pro 13″ má 58 otvorů reproduktoru, 4 tlačítka, 2 antény a konektor, tedy přes 60 odečtení od jednoho těla.

#Krok 4: Přední detaily nevrtejte

Výřez pro kameru, ostrůvek v horní části displeje nebo indikátor domovské obrazovky jsou ploché. Řezat pro ně geometrii je zbytečná práce. Nalepte je jako decal, tedy obrázek promítnutý na povrch. Promítejte ho na skrytou rovinu přes celou přední stranu a polohu zadávejte ve stejných milimetrech jako všechno ostatní. Výjimkou je kulaté domovské tlačítko starších iPhonů. To má skutečnou hloubku, kterou je vidět z boku, a proto jde přes CSG.

#Krok 5: Přesuňte výpočet do Web Workeru

JavaScript v prohlížeči běží v jednom vlákně. Totéž vlákno počítá, kreslí stránku a reaguje na kliknutí. Dokud běží CSG, stránka stojí a nepomůže ani spinner, protože i ten potřebuje stejné vlákno.

Celé sestavení zařízení proto spusťte ve Web Workeru, tedy v samostatném vlákně na pozadí. Worker dostane popis zařízení, vrátí hotová pole vrcholů a stránka zůstane plynulá. Při změně parametru starý worker ukončete a spusťte nový, ať nedopočítává zastaralý stav.

Výsledek z workeru chvíli trvá, proto přidejte okamžitý náhled. Upravovaný prvek ukažte jako modrého průsvitného „ducha“, jednoduchý kvádr nebo válec s pár desítkami trojúhelníků, který jde postavit v hlavním vlákně hned. Když worker skončí, duch zmizí.

#Krok 6: Odečtěte všechny otvory najednou

Nejpřímočařejší způsob je odečítat prvky postupně: otvor 1 od těla, pak otvor 2 od výsledku a tak dále. Každé odečtení ale znovu postaví prostorový index celého těla, což je nejdražší část výpočtu. Při desítkách prvků čas roste velmi rychle.

Lepší je nejdřív posbírat všechny vrtáky pro dané těleso, spojit je do jednoho meshe a odečíst jednou.

řezy = []
pro každý prvek: přidej jeho vrták do řezy
spojený = spoj všechny řezy do jednoho meshe
tělo = tělo mínus spojený
pokud spojení selže: odečti řezy po jednom

Měření na zjednodušené kopii postupu (Three.js 0.170, three-bvh-csg 0.0.17, Node 22, cloudový server se 2 jádry Intel Xeon 2,1 GHz, medián z 5 běhů):

Jedna podmínka: spojení a jedno odečtení dá stejný výsledek jako postupné odečítání, jen pokud se vrtáky nepřekrývají. Prvky jsou na různých místech, takže to běžně platí. Pokud ale uživatel posune dva prvky na sebe, v místě překrytí může vzniknout drobná chyba.

#Krok 7: Počet segmentů mějte jako parametr

Teselace, která stačí na zobrazení, je pro CSG často zbytečně hustá. Při 64 segmentech na roh a 32 na bevel má tělo 68 108 trojúhelníků. Polovinu (32 a 16) na 2mm hraně nevidíte, ale tělo má jen 17 676 trojúhelníků a třetí řádek tabulky ukazuje, co to dělá s časem.

64 a 32 segmentů

32 a 16 segmentů

Malým prvkům s poloměrem do 2 mm (otvory reproduktoru, šroubky) dejte polovinu segmentů, náhledům v galerii ještě méně. Kvalitu proto nedávejte jako konstantu do kódu, ale jako parametr sestavení.

#Render na serveru bez grafické karty

Pokud potřebujete stejnou scénu vykreslit i na serveru, například jako zálohu exportu, běží v Chromu bez obrazovky (headless), který bez grafické karty kreslí softwarově. Tam se každá neefektivita znásobí. V Ecranify nejtěžší tablet bez zmíněných úprav narazil na limit 15 minut. Se spojenými řezy, menšími texturami, nižší teselací a cache hotové geometrie podle hashe popisu zařízení trvá render kolem půl minuty a opakovaný kolem 5 sekund. Podrobnosti i s interaktivními ukázkami jsou v anglickém článku na ecranify.com.

Pokud řešíte podobný problém s 3D v prohlížeči nebo potřebujete aplikaci na zakázku, napište nám.

Projekt z Unity 4 neotevírejte přímo v Unity 6 a hlavně v něm nic neukládejte. Unity 6 staré binární scény načte jen částečně a uložením ztrátu potvrdí; bezpečná cesta vede přes Unity 2019.4, které starý formát umí přečíst i zapsat jako text, a teprve potom do Unity 6.

Týká se to projektů, které mají scény a prefaby uložené v binárním formátu a skripty v UnityScriptu, jazyce podobném JavaScriptu, který Unity kdysi podporovalo vedle C#. Postup ukážeme na hře Onager, fyzikální hře s katapultem napsané v Unity 4.1.2 a v UnityScriptu. Projekt měl 126 skriptů, 75 scén a 78 prefabů, po převodu běží na Unity 6000.5 s URP (Universal Render Pipeline) a je zdarma na App Store i Google Play.

#Co se stane, když projekt otevřete v Unity 6

Nejjednodušší přístup je otevřít projekt v Unity 6 a přepnout serializaci na Force Text, tedy na ukládání assetů jako čitelný YAML. To ale není překlad souborů. Unity každý asset načte přes svůj importér a zapíše zpět jako YAML, takže všechno projde loaderem Unity 6. Ten u každé scény hlásí, že našel Transform bez GameObjectu, a „visící“ komponentu smaže. Uložení to udělá natrvalo.

Rozsah ztráty se dá změřit nástrojem binary2text, který je přiložený k editoru a čte serializovaný soubor bez importéru. V Onageru jsme jeho výpis porovnali s výsledným YAML a počítali jen komponenty, které zmizely z GameObjectů, jež přežily:

Bez ztráty nebyla ani jedna ze 75 scén. Zmizely celé kamery pro HUD a hlavní kamera dostala novou, výchozí. Důležité je, že škoda vzniká už při načtení, ne při uložení. Dokud projekt není převedený, nesmí ho Unity 6 uložit, ani jednu scénu, ani jeden prefab.

#Krok 1: Zaznamenejte původní stav

Než na cokoli sáhnete, vyfoťte si každou scénu a pro každou scénu si nástrojem binary2text uložte výpis původního souboru. Podle výpisu budete v kroku 3 kontrolovat kamery a v kroku 5 obnovovat HUD. Původní binární soubory nechte v historii gitu, nemažte je.

#Krok 2: Převod na text přes Unity 2019.4

Unity 2019.4 je poslední editor, který formát z Unity 4.1 umí přečíst i zapsat. Převod dělejte se zavřeným editorem v samostatné kopii repozitáře:

• Verze projektu. V souboru s verzí projektu nastavte původní verzi (u Onageru 4.1.2), aby editor zvolil cestu pro starý projekt. Unity ji při otevření přepíše, stačí, že platí při prvním importu.
• Prázdné balíčky. Vyprázdněte seznam závislostí balíčků. Jedna chyba kompilace znamená, že nebude fungovat žádná položka menu z editorových skriptů, a to vypadá, jako by se menu vůbec neobjevilo.
• Import od nuly. Smažte složku Library a nechte projekt naimportovat.
• Force Text a vynucené přepsání. Unity 2019.4 po změně na Force Text existující soubory samo nepřepíše. Je potřeba to vyvolat funkcí pro reserializaci assetů, a to jen assetů, ne i jejich meta souborů. Přepsání všech meta souborů způsobí, že Unity 6 potom importuje stále dokola.

Jedna past je v gitu. Pokud v nastavení atributů gitu označíte scény jako text s koncem řádku LF, git z binárních scén při ukládání do repozitáře vyhodí bajty, které vypadají jako konec řádku. V Onageru to poškodilo osm scén. Na assety Unity atribut pro konce řádků nedávejte, Unity stejně zapisuje LF.

#Krok 3: Výsledek ověřte v editoru, ne čtením YAML

Čtení převedených souborů vede k sebejistým a nesprávným závěrům. Zkrácené záznamy instancí prefabů vypadají jako ztráta, stejně jako kamera, která se jen přesunula do prefabu. Rozhoduje to, co Unity postaví v paměti. Každou převedenou scénu otevřete a její kamery porovnejte s výpisem originálu z kroku 1.

V Onageru mělo po převodu všech 75 scén stejné kamery i jejich pořadí. Ztratilo se jen to, co žádný dnešní editor nezná: 569 GUITexture, 179 GUIText a staré částicové systémy, které Unity odstranilo v roce 2018.

#Krok 4: UnityScript do C# se stejným GUID

Unity ukončovalo UnityScript postupně od verze 2017.2, takže ruční port do C# je jediná cesta. Scény odkazují na skripty přes GUID, jedinečný identifikátor, který Unity ukládá do meta souboru každého assetu, a hodnoty polí ukládají podle jména pole. Když to při portu dodržíte, všechny odkazy se připojí samy:

pro každý skript X v UnityScriptu:
  vytvoř C# skript s třídou přesně jménem X
  zkopíruj GUID z meta souboru starého skriptu do meta souboru nového
  veřejná pole: stejné jméno, stejný typ, i s překlepy
  nic nepřejmenovávej, dokud projekt neběží

V Onageru se takto po portu všech 126 skriptů připojilo 12 935 komponent v 73 scénách a v Inspectoru zůstaly všechny nastavené hodnoty.

Textovým hledáním v projektu se nedá zjistit, které skripty se používají. Binární prefab má GUID uložený jako bajty, ne jako text. V Onageru tak vypadalo nepoužívaných jednadvacet skriptů a všechny byly živé. Dejte si pozor i na pozůstatky starších pokusů o port: jeden prefab dřevěné kostky ukazoval na dva skripty z takového pokusu a jen kvůli němu chybělo 1 140 komponent. Pokud je potřeba v binárním souboru změnit GUID, vyměňte ho přímo v bajtech, šestnáct za šestnáct, aby se soubor neposunul.

#Krok 5: Obnovte HUD z původních binárních scén

GUITexture a GUIText v Unity 6 nejsou a s nimi zmizí celý HUD, který na nich stál. Kreslit ho znovu není potřeba. Původní binární scény z historie gitu binary2text přečte bez ohledu na to, jestli třídy ještě existují. Vytáhněte z nich každý obrázek a text HUD s texturou, barvou, pozicí a zarovnáním a skriptem je vraťte na stejné objekty ve scénách. V Onageru to bylo 577 obrázků a 180 textů.

Takto se zachrání i texty, které nikde jinde nejsou. V Onageru to bylo 111 textů: všechny titulky tutoriálů a celá tabule s kredity. Při psaní HUD od nuly byste si je museli vymyslet. Při přenosu barvy počítejte s jednou věcí, kterou dokumentace neříká: staré GUITexture barvu při vykreslení zdvojnásobovalo. Všech 577 obrázků mělo barvu přesně 0,5, takže šedá znamenala bílou.

#Po převodu: staré triky nahraďte

Staré projekty často obcházely omezení tehdejšího Unity a tyto obezličky se po převodu vyplatí předělat:

• Odraz v podlaze. Onager měl lesklou podlahu bez skutečného odrazu. Pod podlahou stál druhý, zrcadlově otočený svět: kopie každého objektu, jejíž pozici skript každý třetí snímek zkopíroval z originálu, v jednom levelu 50 až 70 klonů. Nahradit se to dá jednou kamerou navíc, která odraz kreslí v polovičním rozlišení. Odrážejí se pak i částice a trosky, což klonovaný svět neuměl.
• Míření. Pokud náhled dráhy předpovídá, kam střelu pošle síla přidaná v prvním fyzikálním kroku, střela dopadne jinam než značka. Spolehlivější je vypočítat rychlost jednou, náhled nakreslit přesně z ní a střele ji přiřadit přímo.
• Výkon. Měřte na slabém telefonu. Na Motorole G52 klesl Onager z 20 na 6 fps jen kvůli shaderu stěn, víc než rozlišení, stíny a odraz dohromady. Na nízkých a středních detailech proto mají stěny jednodušší materiál.

Pokud řešíte fyziku tisíců objektů v současném Unity, podívejte se i na falešný ragdoll pro tisíce nepřátel v Unity DOTS. Jak po převodu přidat staré 2D hře glow a 2D světla v URP, popisuje samostatný návod.

#Co postup nevyřeší

Komponenty, které dnešní Unity nezná, se nepřipojí. GUITexture a GUIText je třeba obnovit jako v kroku 5, staré částicové systémy se ztratí. Jména tříd a polí zůstanou přesně jako v původním projektu, i s překlepy a v jazyce, ve kterém je někdo kdysi napsal. Scény se na ně vážou jménem, takže přejmenování má smysl dělat jen přes editor, který odkazy přepíše sám.

Pokud máte starý projekt v Unity a potřebujete ho dostat do současné verze, napište nám.

Hordu tisíců nepřátel v Unity DOTS navigujte jedním flow fieldem pro celou mapu a několika levnými lokálními pravidly: odtlačování od sousedů a od stěn, cena cesty podle hustoty davu a stav „čekám“ v zácpě. V Unity Editoru na MacBooku s M3 Pro to drží kolem 9 600 nepřátel najednou při 90 FPS.

Problém vzniká v tower defense, strategických a survival hrách, kde k cíli jdou naráz tisíce jednotek. Klasické hledání cesty pro každou zvlášť je příliš drahé a bez lokálních pravidel se dav překrývá, lepí na stěny a zasekává v úžinách. Unity DOTS (Data-Oriented Technology Stack, tedy Entities, ECS a Job System) dává výkon na tisíce entit, samotnou navigaci ale neřeší. Postup níže používáme v naší tower defense hře pro PC (je v referencích). Obrázky jsou ze zjednodušené 2D simulace, která běží podle stejných pravidel, nejsou to záběry ze hry.

#Krok 1: Flow field místo cesty pro každého

Flow field je mřížka přes celou mapu, ve které každá buňka ví, kterým směrem se z ní jde k cíli. Nepřítel nehledá cestu, jen si přečte směr z místa, kde stojí. Cena je stejná pro 10 i 10 000 nepřátel.

Rozdělte mapu na buňky po 1 m (náš testovací level má 128 × 128) a pro každý cíl jednou spočítejte vzdálenost z každé buňky k cíli. Statické pole stačí spočítat v editoru při přípravě levelu a uložit do assetu.

Nejjednodušší verze je Dijkstra přes 8 sousedů a v každé buňce jeden z 8 směrů. Funguje, ale nepřátelé chodí po úhlopříčkách a v řadě se lepí na stěny.

8 směrů

Plynulé pole

Lepší výsledek dává plynulé pole. Vzdálenost spočítejte řešením eikonální rovnice (rovnice šíření vlny, jejímž řešením je nejkratší vzdálenost ve spojitém prostoru, ne jen po hranách mřížky) metodou fast sweeping, která mřížku opakovaně prochází ze čtyř rohů. Směr pak není směr buňky, ale gradient vzdálenosti v přesném místě nepřítele. K ceně buňky připočtěte přirážku za blízkost stěny, takže pole samo drží dav kousek od překážek.

#Krok 2: Samostatné pole pro každou velikost nepřítele

Velký nepřítel se nevejde všude tam, kam malý. Zaveďte velikostní třídy: každá má vlastní průchodnost (buňka musí být dost daleko od stěny) a vlastní pole pro každý cíl. Třídy držte jako data levelu, ne v kódu. U nás jsou tři.

#Krok 3: Odtlačování od sousedů

Flow field řekne směr, ale o sousedech neví nic. Základem je zjednodušený model boids (klasická pravidla hejna): každý nepřítel se odpuzuje od sousedů v okruhu 0,9 m. Sousedy hledejte ve spatial hashi, tedy v prostorové mřížce, kde každá buňka drží seznam jednotek v ní. Hash postavte každý tik znovu a seřaďte, aby bylo pořadí deterministické.

Samotné odpuzování nestačí. Při 3 000 nepřátelích mělo 83,7 % z nich nejbližšího souseda blíž než 0,8 m a nejmenší vzdálenost byla 4 cm, tedy dva nepřátelé skoro v sobě.

Vyšší váha odpuzování problém neřeší. Při váze 6 místo 1,5 klesl podíl těsných na 54,6 %, při 12 na 44,3 %, při 24 už nic (48,2 %). Dav navíc začne poskakovat, protože se sčítají neomezené tlaky od mnoha sousedů najednou.

Pomůže poziční korekce. Po pohybu rozsuňte každou překrývající se dvojici, každého o polovinu průniku, a posun za tik omezte na 0,15 m. Bez stropu korekce skáče stejně jako vysoká váha. Se stropem zůstane těsných 60,8 %, ale nejmenší vzdálenost stoupne na 28 cm a dav neposkakuje.

Jen odpuzování

Korekce překrytí

#Krok 4: Odtlačování od stěn

U stěny korekce mezi nepřáteli selhává. Pohyb do stěny je zakázaný (posun se rozloží po osách a složka do stěny se zahodí), takže přitlačený nepřítel nemá kam uhnout a korekce od souseda se ztratí. Z 938 překrývajících se nepřátel mělo nenulový tlak od stěny jen 35.

Přidejte proto odtlačování od nejbližších neprůchozích buněk ve 4 směrech i diagonálně. Dvě chyby, kterým se dá vyhnout:

• Vnitřní roh. Tlak od obou hran a od rohu se sečte a nepřítele to odhodí. Tlak od rohu přidávejte jen u vnějšího rohu.
• Skutečné stěny. Odtlačujte od skutečných stěn, ne od průchodnosti velikostní třídy. Pro velkého nepřítele je „stěna“ už metr před skutečnou. V ústí chodby tak tlak od rohu vyrovnal pohyb velkého nepřítele dopředu a celá skupina za ním zůstala stát.

#Krok 5: Cena podle hustoty davu a zpomalení

I s plynulým polem jde celý dav po nejkratší cestě těsně kolem rohu, bez ohledu na to, kolik nepřátel tam už je. Řešení nabízí Continuum Crowds (Treuille a kol., 2006): cena buňky roste s hustotou davu. Jednou za 10 tiků spočítejte nepřátele v buňkách, vyhlaďte to a přepočítejte pole jednoho cíle. U přeplněného rohu pak pole pošle nepřítele kolem, přes volnější buňky.

Bez hustoty

Cena podle hustoty

Druhá polovina je zpomalení. Nepřítel v husté buňce jde pomaleji, nejméně na 15 % rychlosti. Na 2 250 nepřátelích šli v řídkých buňkách průměrně na 94 % rychlosti, ve středně hustých na 71 % a v zácpě na 20 %. Ať zpomalení začíná dřív: s prahem volné hustoty 0,6 nepřítele na buňku místo 1 klesl podíl těsných v úžině na 36,7 %.

Praktická rada: pole, která vznikají až za běhu (například mapa hustoty), alokujte dřív, než je poprvé použije job. Job s ještě nevytvořeným polem shodí Unity Editor nativně, bez výjimky.

#Krok 6: Zácpa v úžině: čekat, ne tlačit

Když se dav nemá kam rozšířit, zbývá úžina. Nejjednodušší nápad je zahodit složku rychlosti směrem k sousedovi, kterého se nepřítel dotýká. Zadní pak stojí, místo aby uhnuli, a zácpu udržují.

Uhnout stranou, například o 35° na stranu s méně sousedy, je lepší, ale dav se začne míhat. Vyhlazení natáčení a nižší rychlost otáčení (180 místo 360 °/s) příznak jen tlumí. Příčina je jinde: při vyrovnané hustotě si nepřítel volí stranu každý tik jinak. Pomůže hystereze, tedy zvýhodnění předchozího rozhodnutí: strana z minulého tiku dostane při porovnání slevu 3 sousedů.

Výsledné řešení spojuje kontaktní omezení a tři stavy: jde, obchází, čeká. Složka rychlosti do dotýkajícího se souseda se zahodí, boční zůstane. Kdo nemá volnou stranu ani místo před sebou, čeká a netlačí.

pro každého nepřítele, každý tik:
    rychlost = směr z flow fieldu × rychlost × zpomalení podle hustoty
    rychlost += odpuzování od sousedů
    pokud se vpředu dotýká souseda:
        pokud je volná strana: obcházej (strana s hysterezí)
        jinak: čekej
    zahoď složku rychlosti do dotýkajících se sousedů
    posuň se, složku do stěny zahoď
pak pro všechny:
    rozsuň překrývající se dvojice (polovina průniku, nejvýš 0,15 m)
    odtlač od stěn

Na tři věci si dejte pozor:

• Trpělivost. Když se potkají dva nepřátelé v protisměru, ať čeká ten s vyšším ID. Řetěz sousedů ho ale může blokovat tisíce tiků, proto po limitu čekání zkusí nouzově uhnout.
• Nulová rychlost. Nepřítel s nulovou požadovanou rychlostí se ze stavu „čeká“ nikdy nevrátí a po vlně zůstane stát na volné ploše. Kdo se nechce hýbat, ať je vždy ve stavu „jde“.
• Úzký kužel. Souseda vpředu hledejte v úzkém kuželu s krátkou sondou. Při 45° posílalo nastavení do čekání nebo obcházení 55 až 60 % davu i na volné ploše, při 30° a kratší sondě 41 %.

#Krok 7: Předjíždění velkých nepřátel

Různě velké a různě rychlé typy nepřátel přinášejí další případy. Náš velký pomalý nepřítel má poloměr v davu 1,25 m a jde 1,1 m/s. Rychlý nepřítel za ním ho nedokázal předběhnout: boční sondy šikmo vpřed byly stále blíž k velkému než součet poloměrů, obě strany vyšly obsazené a rychlý čekal. Oprava: souseda, kterého nepřítel obchází, bere sonda v úvahu jen na jeho straně. Soused přesně vpředu neblokuje žádnou.

Velký nepřítel naopak odhazuje malé z cesty do stran, ve výseči ±45° před sebou. Neodhazujte ty, kteří jdou jeho směrem rychleji, než chce jít on, jinak odhodí i ty, kdo ho právě předbíhají.

#Krok 8: Sloty u cíle útoku

Pokud nepřátelé útočí zblízka, potřebují místo kolem cíle. Naše věž má 24 slotů po obvodu půdorysu 5 × 5 m, každý nepřítel zabírá jeden a ostatní čekají ve frontě.

• Obcházení po kruhu. Pokud nabízíte slot jen tehdy, když k němu vede přímá čára, zadní sloty zůstanou prázdné, protože zepředu čára k nim protíná věž. Ať nepřítel k volnému slotu obchází věž po oblouku.
• Bez vytlačování. Nevytlačujte nepřítele jdoucího ke slotu ve prospěch jiného žadatele, spouští to řetěz vytlačování.
• Bez odtlačování u slotu. Nepřítele přicházejícího vedle obsazeného slotu odtlačuje soused, takže skončí 13 cm od cíle nebo úplně mimo. Nepřátelé ve slotu a do 0,5 m od něj se navzájem neodtlačují.

#Výkon simulace a vykreslování

Benchmark v Unity Editoru (M3 Pro, kolem 9 600 jednoduchých nepřátel, dvě úžiny) dal 90 FPS při 1440p a 100 při 1080p. Rozlišení FPS skoro nemění, zrychlení času ano: při 10× klesne na 20 FPS, protože na jeden snímek připadá deset kroků simulace. Při normální rychlosti má simulace rezervu.

S detailním modelem nepřítele místo kapsle se úzké hrdlo přesune do vykreslování:

V simulaci se vyplatí tři věci:

• Dva průchody sousedů. Levný (dotyky, blokování) běží vždy, drahý (boční sondy, hustota stran) jen pro zablokované, což je ve volném proudu menšina. Vzdálenosti porovnávejte ve druhé mocnině, bez odmocniny.
• Jednoduché řazení. Synchronní seřazení spatial hashe trvalo při 3 000, 10 000, 20 000 a 50 000 záznamech 0,37, 1,49, 3,16 a 8,46 ms, verze v jobu 0,18, 0,93, 3,12 a 15,53 ms. Job není konzistentně rychlejší, jednoduché řazení stačí.
• Hash stavu. Při tiku 600 a 1800 spočítejte hash pozic a životů. Refaktor musí dát stejný hash, změna chování ho změní a umíte ji vysvětlit. Funguje to díky deterministickému pořadí ve spatial hashi.

#Limity řešení

• Dva plné protisměrné davy v jedné úžině se zaseknou natrvalo. Je to limit modelu bez fyziky.
• Čísla jsou z Unity Editoru na M3 Pro. Měření na Steam Decku a ve skutečném buildu zatím nemáme, jen odhad z veřejných benchmarků procesorů.

Pokud chcete zkusit vlastní dav, dokumentace Unity Entities je dobrý začátek. Podobný postup od nejjednoduššího řešení k funkčnímu najdete i v článku o generátoru sudoku. Jak nepřátele v takovém davu odhodit výbuchem bez drahého ragdollu pro každého, popisuje návod jak udělat fake ragdoll v Unity DOTS. Pokud řešíte podobnou simulaci v Unity a chcete pomoc, napište nám.

Osmisměrku s tajenkou vygenerujete tak, že do prázdné mřížky ukládáte náhodná slova ze slovníku, dokud v ní nezůstane volných přesně tolik políček, kolik písmen má tajenka. Ta pak vyplníte tajenkou zleva doprava a shora dolů. V telefonu to celé trvá pár milisekund a nepotřebuje backtracking, tedy vracení se k dřívějším rozhodnutím, když se generátor zasekne.

Osmisměrka je mřížka písmen, ve které hráč hledá a škrtá slova ze seznamu. Tajenka je text, který se přečte ze zbylých, nepřeškrtnutých písmen. Generátor proto musí složit mřížku, která je úplně plná a ve které po vyškrtání slov zůstane přesně tajenka. Postup níže je ten, kterým generujeme osmisměrky v naší aplikaci s křížovkami a osmisměrkami (App Store, Google Play).

#Pravidla mřížky

Než začnete, ujasněte si, co má hotová mřížka splňovat. V naší aplikaci platí:

• Slova vedou v osmi směrech: vodorovně, svisle a po obou úhlopříčkách, každým směrem i pozpátku.
• Dvě slova se mohou překrývat nejvýš v jednom písmenu.
• Žádné slovo nesmí procházet políčkem tajenky.
• Mřížka musí být plná. Prázdné políčko je chyba.
• Tajenka se čte zleva doprava a shora dolů ze všech nepřeškrtnutých písmen.

#Krok 1: Připravte slovník

Slovník rozdělte jednou na začátku do skupin podle délky slova. Výběr náhodného slova dané délky je pak jeden náhodný index. Kdybyste u každého slova filtrovali celý slovník, generování se znatelně zpomalí, protože do jedné mřížky se zkouší stovky slov.

Náš slovenský slovník má 16 713 slov s délkou od 3 do 21 písmen, nejvíc je sedmi- a osmipísmenných, český má 64 414 slov. Pár praktických rad:

• Nechte ve slovníku i vlastní jména a zkratky. V mřížce se pak objeví třeba HOUSTON nebo MAINE. Bez krátkých a „divných“ slov nejde mřížku dostatečně zahustit.
• Vulgarismy filtrujte samostatným seznamem, který jde vypnout, pokud hráč chce obsah pro dospělé.
• U více jazyků načtěte jen ten, ve kterém se hraje. Anglický slovník má přes 414 000 slov. Načtení všech čtyř jazyků naráz při startu aplikace zmrazí slabší telefon až na 11 sekund.

#Krok 2: Vyberte tajenku

Tajenka by měla mít aspoň tolik písmen, kolik je strana mřížky, a nejvýš o čtyři víc. Kratší v mřížce zanikne, delší vyžaduje příliš mnoho děr.

V naší aplikaci je tajenka pointa vtipu. Hráč škrtá slova a ze zbylých písmen si přečte, jak vtip končí. Tajenku skládáme z konce vtipu: odzadu přidáváme celá slova, dokud její délka nespadne do uvedeného rozsahu.

Obrázky níže používají anglický vtip „Two snakes walk into a bar. Turns out they were lizards.“ (Dva hadi vejdou do baru. Ukáže se, že to byly ještěrky.) na mřížce 10×10. Tajenka je WERELIZARDS, tedy 11 písmen. Slova v obrázcích jsou z anglického slovníku zúženého na běžná slova, aby se dala číst.

#Proč nezačínat tajenkou

První nápad je dělat to, co by člověk dělal tužkou: nejdřív rozházet písmena tajenky na náhodná políčka v pořadí čtení a potom kolem nich skládat slova.

Vypadá to rozumně, dokud nepřijde konec. Generátor si vybere prázdné políčko, zkusí přes něj dostat slovo ve všech směrech a posunech, a když mřížka zhoustne, zůstanou izolované díry. Jednu díru mezi dvěma písmeny tajenky nezaplní nic, protože nejkratší slovo má tři písmena a přes tajenku slovo vést nesmí.

Na vzorku 200 mřížek 10×10 tento přístup skončil s plnou mřížkou jen ve 28 % případů, v průměru zůstaly 1 až 2 díry. Opravovat je dodatečně je složité. Tajenku proto do mřížky nedávejte, dokud nejsou hotová slova.

#Krok 3: Plňte mřížku, dokud nezůstane přesně N děr

Plnění je jednoduchý greedy algorithm: každé slovo se položí hned, jak se vejde, a už se neodebírá. Generátor si pamatuje jen jedno číslo: kolik políček je ještě prázdných. Slovo položí jen tehdy, pokud by po něm nezůstalo méně prázdných políček, než má tajenka písmen (N).

prázdná = řádky × sloupce
dokud prázdná > N a pokusů < 2000:
    slovo = náhodné slovo zvolené délky
    opakuj nejvýš 50krát:
        začátek = náhodné políčko, směr = náhodný z 8
        pokud se slovo vejde podle pravidel mřížky:
            nová = počet prázdných políček, která slovo zaplní
            pokud prázdná - nová >= N:
                polož slovo
                prázdná = prázdná - nová
                pokračuj dalším slovem
pokud prázdná != N: mřížku zahoď a začni znovu

První slova padnou do prázdné mřížky volně:

Postupně slova začínají sdílet písmena. To je vítané, protože každé sdílené písmeno je jedno políčko, které není třeba zaplňovat:

Když počet prázdných políček klesne na N, plnění končí. Kde ty díry jsou, je jedno. Mohou být rozházené kdekoli, protože tajenka jimi nemusí vést žádnou cestou:

#Krok 4: Losujte délku slova s rozumem

Dlouhá slova dělají osmisměrku zajímavou, krátká ji dokážou dokončit. Délku proto losujte ze dvou normálních rozdělení (normálně rozdělená náhodná čísla dostanete třeba Box-Mullerovou transformací):

Délka je vždy aspoň 3 a nejvýš strana mřížky. K tomu dvě pravidla, bez kterých se generátor na konci zasekává:

• Na konci vynuťte přesnou délku. Když do cíle chybí 5 a méně políček, hledejte slovo přesně takové délky, jaká chybí (nejméně 3). Jinak se bude generátor donekonečna pokoušet o šestipísmenná slova, která se už nevejdou.
• Třípísmenná slova dávejte na příděl. První tři pokusy o mřížku nesmí obsahovat ani jedno, pokusy 4 až 6 jedno, další tři dvě a tak dál. Třípísmenná slova jsou ve slovníku často zkratky typu DNA nebo CPU a v osmisměrce působí lacině. Povolte je, až když to jinak nejde.

#Krok 5: Vlijte tajenku do děr

Projděte mřížku zleva doprava a shora dolů a do každého prázdného políčka zapište další písmeno tajenky. Protože děr je přesně N, tajenka se vejde beze zbytku.

Hráč vidí jen tohle:

#Když se mřížka nepovede

Pokud generátor ani po 2 000 pokusech nedosáhne přesně N prázdných políček, celou mřížku zahoďte a začněte znovu, nejvýš 100krát. Žádné opravování děr. Je to hrubé, ale u mřížek do 12×12 to stačí s rezervou. Větší mřížky potřebují víc pokusů, jak ukazuje tabulka níže.

#Úspěšnost a rychlost podle velikosti mřížky

Generátor běžel na 300 mřížkách pro každou velikost, se skutečnými vtipy a slovenským slovníkem (Node.js 22 na serverovém procesoru, telefon bude pomalejší; obrázky v článku jsou z anglického slovníku, čísla ze slovenského, protože je menší, a tedy přísnější test). „Na první pokus“ znamená, že první kolo plnění skončilo plnou mřížkou.

Co z toho plyne pro vlastní generátor:

• Průměrné slovo má 4,7 písmene, i když cíl je kolem 6. Dlouhá slova se do zahuštěné mřížky prostě častěji nevejdou.
• Asi 9 až 10 % políček sdílejí dvě slova. Není třeba to nastavovat, plyne to z pravidla „nejvýš jedno společné písmeno“.
• Úhlopříček bude méně, než čekáte. Směr se losuje rovnoměrně z osmi, takže by měly tvořit polovinu slov. V malé mřížce ale úhlopříčné slovo mnohem častěji vypadne za okraj. Na 8×8 tvoří úhlopříčky 24 % slov, na 15×15 už 33 %. Pokud chcete víc úhlopříček, dejte jim při losování směru vyšší váhu.

#Tip: stejná mřížka při každém spuštění

Na screenshoty do obchodů potřebujete, aby se vygenerovala vždy stejná mřížka. Místo běžného generátoru náhodných čísel použijte v takovém režimu jednoduchý lineární kongruenční generátor s pevným seedem (třeba odvozeným z jazyka). Pokud držíte veškerou aritmetiku v rozsahu, který čísla v JavaScriptu reprezentují přesně, výsledek je stejný na každém zařízení. Stejným trikem jsou vygenerované i obrázky v tomto článku.

Pokud řešíte podobný problém, generujete hlavolamy nebo potřebujete mobilní aplikaci, napište nám. Krátké ukázky z vývoje dáváme i na YouTube. Podobně krok za krokem je popsáno i to, jak vygenerovat sudoku s jediným řešením. Pokud potřebujete křížovku místo osmisměrky, podívejte se, jak vygenerovat švédskou křížovku s tajenkou.