LOD pre tisíce animovaných postáv v Unity postavte podľa počtu vrcholov, nie trojuholníkov: pri vertex animation textures sa animácia počíta na každý vrchol. Nižšie úrovne pripravte ručne, vrcholy najnižšej úrovne pripojte k povrchu originálu a úroveň vyberajte pre každú postavu zvlášť. V našej tower defense hre pre PC to pri 3 000 nepriateľoch zvýšilo FPS pri zábere do davu z 62 na 120.

Postup sa týka hier, kde sa na obrazovke pohybujú tisíce postáv naraz, teda tower defense, stratégií a survival hier. Naša hra je postavená v Unity s ECS a nájdete ju v referenciách. LOD znamená level of detail: vzdialená postava sa kreslí z jednoduchšej siete. Obrázky sú skutočné siete nášho nepriateľa kostry, nie zábery z hry.

#Prečo generovaný LOD pri dave nepomôže

Unity vie úrovne LOD vygenerovať pri importe modelu (funkcia Mesh LOD). Pre tisíce postáv to má dva problémy.

Prvý je vzhľad. Automatické zjednodušenie trhalo tenké končatiny a rozbíjalo UV, teda mapovanie textúry na sieť.

Druhý je cena animácie. Štandardné kostrové animácie sú pre tisíce entít príliš drahé, preto sa namiesto nich používajú vertex animation textures (VAT). VAT je textúra, kde každý stĺpec patrí jednému vrcholu a každý riadok jednej snímke animácie. Shader si polohu vrcholu prečíta z textúry, takže cena animácie závisí od počtu čítaných vrcholov, a to aj pri kreslení tieňov.

Hornú hranicu ukazuje test s vynútenou generovanou úrovňou na všetkých postavách (Unity vygeneruje aj úrovne 3 a 4, build, 1080p, 3 000 nepriateľov, tiene zapnuté):

Priestor na zrýchlenie je veľký. Treba ho získať bez viditeľných dier a skokov medzi úrovňami.

#Počítajte vrcholy, nie trojuholníky

Polovičný počet trojuholníkov sám osebe nepomôže. LOD s polovicou trojuholníkov a 996 z pôvodných 1 521 vrcholov ušetril 1,9 ms na snímku, LOD s 217 vrcholmi 6,4 ms. Pri každej úrovni sledujte oba počty.

Vrcholov býva zbytočne veľa. Vrchol sa zdvojí na každom šve UV, lebo jedna poloha potom potrebuje dve súradnice textúry. Naše modely z AI generátora mali UV rozsekané na stovky ostrovov: kostra mala 1 521 vrcholov, ale len 608 rôznych kombinácií polohy a normály.

#Krok 1: Znížte vrcholy v LOD 0

Prvá úspora nestojí žiadny detail. Spojte vrcholy so zhodnou polohou a podobnou normálou (rozdiel do 25°), rozbaľte UV nanovo so švami len na ostrých hranách (nad 70°) a textúru prepočítajte z pôvodnej po trojuholníkoch. Kostra klesla z 1 521 na 1 090 vrcholov, u ostatných typov nepriateľov to bolo o 19 až 29 % menej, pri rovnakom tvare.

Do VAT potom zapisujte len stĺpce vrcholov, ktoré niektorá úroveň skutočne používa. Ušetrilo to 40 až 60 % pamäte animácií.

#Krok 2: LOD 1 zo zjednodušenia a so zdieľanou textúrou

LOD 1 je zjednodušený LOD 0 na približne 52 % trojuholníkov. Zjednodušujte po kúskoch (každá kombinácia kosti a súvislej časti siete) a vrcholy na hraniciach kúskov zamknite. Hlave dajte väčší rozpočet, lebo silueta hlavy je to, čo oko v dave rozozná.

Dôležité je ponechať textúru LOD 0. Úroveň s vlastnou textúrou alebo iným tvarom je pri prechode viditeľná aj pri podobnej siluete.

Pod zhruba 50 % trojuholníkov zjednodušenie z existujúcich vrcholov trhá tenké časti a samostatné kúsky. Nižšie treba ísť inak.

#Krok 3: LOD 2 ako nová sieť pripojená k originálu

Najnižšia úroveň je nová uzavretá sieť. Originálu pridajte vrstvu hrúbky, spravte voxel remesh a zjednodušte na cieľový počet (u nás 200 až 460 trojuholníkov podľa typu nepriateľa). Výslednú sieť oblepte na povrch originálu a UV spravte automaticky. Textúru zapečte z originálu v rovnakej hustote ako LOD 0, aby sedeli aj mipmapy.

Nová sieť nemá váhy animácie. Každý jej vrchol preto pripojte k najbližšiemu trojuholníku originálu. Uložte si tri stĺpce toho trojuholníka a barycentrické váhy (podiely, ktoré určujú polohu bodu v trojuholníku).

Stĺpec pripojeného vrcholu vo VAT je vážený súčet polôh a normál tých troch vrcholov v každej snímke. Shader nič nerieši, pripojený vrchol je obyčajný ďalší stĺpec.

pre každú snímku f:
    VAT[pripojený, f] = w0 * VAT[a, f] + w1 * VAT[b, f] + w2 * VAT[c, f]

#Krok 4: Diery kontrolujte strojom

Obrázky z modelovacieho nástroja diery spoľahlivo neukážu. Kontrola stačí jednoduchá: vykreslite originál a kandidáta z 11 smerov v rozlíšení 120 px a porovnajte siluety.

Za dieru počítajte pixely originálu vo vnútri obrysu kandidáta, ktoré kandidát nepokryje, a pixely kandidáta viac ako 2 px mimo obrysu originálu. U nás je limit 1 % dier a 4 až 6 % straty. Kontrola musí rešpektovať odstraňovanie zadných stien podľa materiálu. Limity sme nastavili podľa toho, kde boli prechody v hre okom viditeľné.

#Krok 5: Vyberajte úroveň pre každú postavu zvlášť

Prepínanie úrovne pre celú mapu naraz je viditeľné. Keď vyberáte po entitách, prechody sa rozložia a v dave zaniknú.

Celá mapa naraz

Po entitách

Upozornenie k verzii: dokumentácia Unity 6.2 uvádza, že Entities Graphics vždy používa LOD 0. Výber po entitách podľa vzorca nižšie používame v Unity 6.6, pred nasadením si overte správanie vašej verzie:

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

Tu je d vzdialenosť od kamery a D priemer svetových hraníc entity. Sklon a posun zvoľte tak, aby úroveň 1 začínala pri 93,3 a úroveň 2 pri 167,9 metra (kamera s fov 30° a 1440 px). Globálny prah LOD nastavte na výšku obrazu / 1440, potom vzdialenosti nezávisia od rozlíšenia.

Dve chyby, na ktoré si dajte pozor:

• Mierka. Priemer D počítajte zo svetových hraníc, teda s mierkou prefabu. Siete pre VAT bývajú v malých jednotkách a prefab ich zväčší 2-krát až 4-krát. Bez toho vám hra celý čas kreslí LOD 0 a nič to nehlási. Správnosť overte počtom trojuholníkov v bežnom režime oproti vynútenému LOD. Pootočenie entity zväčšuje osovo zarovnané hranice, preto u nás priemer násobíme koeficientom 1,22.
• Bakovanie. Krivka výberu sa zapeká pri bakovaní SubScene a zmenu v sieti bakovanie nezachytí. Po jej úprave vynúťte nové bakovanie SubScene.

#Výsledky a limity

Build pre macOS, 2560 × 1440, 3 000 nepriateľov, tiene zapnuté, hra zastavená po prehre (animácie VAT stále bežia, takže meranie platí pre grafiku):

Na Steam Decku (1280 × 800, 8 výpočtových jednotiek RDNA 2) je to 75 až 80 FPS na celej mape. Najbližší záber do davu má pri vysokej kvalite tieňov 33 FPS, bez tieňov 64. Tiene sú teda najväčšia zostávajúca položka: LOD znižuje aj ich cenu, ale vypnutie stále spraví veľký skok.

Čo LOD nerieši: kontrola dier beží v T-póze, takže natiahnutie siete v extrémnych pózach neodhalí. Jeden typ nepriateľa ešte limit dier v LOD 2 presahuje. Výpočet pohybu hordy LOD neovplyvní, ten rieši článok o navigácii hordy v Unity DOTS a reakcie na výbuchy fake ragdoll.

Potrebujete pomôcť s výkonom hry v Unity alebo simuláciou davu? Napíšte nám.

Stará 2D hra v Unity na vstavanom render pipeline vyzerá na dnešnom telefóne ploško: svetlo chýba, glow buď nie je, alebo rozžiari celý obraz aj s UI, a sprity rozhrania sú rozmazané. V Unity URP to vyriešite tromi vecami: Bloomom s prahom 1 a HDR farbou len na objektoch, ktoré majú žiariť, 2D svetlami z 2D renderera a UI s väčšími spritmi, ktoré rešpektuje bezpečnú oblasť displeja.

Postup ukazujeme na našej hre Dreamica (App Store, Google Play). Je to pádová adventúra, v ktorej prstom kreslíte čiary a nimi vediete bublinu so spiacim dieťaťom cez štyri svety. Pôvodne vznikla v Unity 5.3, UI bolo v plugine NGUI, glow obstarával plugin MK Glow a grafika bola pripravená pre iPhone 7 s displejom 1334 × 750 pixelov. Hrateľnosť ostala rovnaká, zmenila sa len grafika.

Starú hru často otvoríte kvôli obchodu, nie kvôli grafike. Google Play od augusta 2019 vyžaduje 64-bitové verzie a hra, ktorá má len 32-bitový build, z neho vypadne. Presne tak dopadla aj Dreamica. Keď už projekt prenášate do Unity 6, grafika je relatívne lacný bonus.

#Prečo nestačí starý celoobrazovkový glow

Staršie glow pluginy fungujú ako celoobrazovkový efekt. Rozžiaria všetko svetlé vrátane ikoniek tlačidiel v menu. V Dreamice ikonky pod MK Glow v Unity 6 takmer zmizli. Oficiálny balík Post Processing Stack v2 je náhrada len pre vstavaný pipeline, v URP sa už neaplikuje. Ak chcete glow, ktorý riadite po materiáloch, a k tomu dynamické 2D svetlá, prejdite na URP a použite Bloom, ktorý je v ňom zabudovaný.

#Krok 1: Prepnite projekt na URP

Po prepnutí na URP narazíte v starej 2D hre takmer isto na dve pasce. Obe sa prejavujú tak, že obraz vyzerá zle alebo presne ako predtým, hoci shadery sú v poriadku.

#Sivá obrazovka: nastavte zásobník kamier

Ak herné okno v Editore ukazuje len sivú plochu, ale scéna v editore aj jednorazový render kamery vyzerajú správne, chyba nie je v shaderoch, ale v skladaní kamier. Staré hry mávajú dve kamery, jednu na svet a jednu na UI, a UI kamera maže len hĺbku. To je spôsob, ako sa vrstvia kamery vo vstavanom pipeline, a URP ho nepodporuje. Potrebuje explicitný zásobník kamier (camera stack): jedna kamera je základná (Base), ostatné sú prekrytie (Overlay) zaradené do jej zásobníka. Nastavte ho v každej scéne, kde sa kamery vrstvia.

#Sprity ignorujú svetlo: prepnite na 2D renderer

Sprity s osvetleným shaderom nereagujú na žiadne svetlo, ak beží bežný URP renderer. Ten 2D svetlá vôbec nepočíta. Prepnite na 2D renderer. Aj ten však osvetlenie nekreslí, kým v scéne nie je aspoň jedno 2D svetlo. Keď niečo po zmene vyzerá presne ako predtým, najprv skontrolujte, ktorý renderer beží.

#Častice a staré pluginy

Častice na starých shaderoch sa pod 2D rendererom kreslia čierne alebo vôbec. Dajte im nový jednoduchý shader.

Pozor aj na Asset Store. Pri obnovení assetov vie Editor sám aplikovať „aktualizáciu“ starého pluginu, ktorá pridá metadáta a premenuje shadery. Materiály hľadajú shader podľa mena, takže sa potichu rozbijú. Po každom väčšom obnovení assetov v starom projekte si vo verziovacom systéme pozrite všetky zmenené súbory, aj tie, na ktorých práve nerobíte.

#Krok 2: Selektívny glow cez HDR farbu a Bloom s prahom 1

Cieľ je, aby žiarili vybrané objekty, v Dreamice nakreslená čiara, lasery, iskry, svätojánske mušky a runy, ale nie pozadie a UI. Bloom v URP rozmaže a pripočíta všetko, čo je jasnejšie ako jeho prah. Nastavte prah na 1 a materiálom, ktoré majú žiariť, vytlačte farbu nad 1.

shader čiary:
    farba = textúra × farba vrcholu × odtieň × intenzita    (intenzita = 6)

Bloom:
    prah = 1, sila = 0,3
    žiari len to, čo má po výpočte jas nad 1

Pozadie a tlačidlá majú farby od 0 do 1, cez prah neprejdú a ostanú ostré. Tým zmizne aj problém s vybielenými ikonkami. Podmienkou je kamera s HDR. Bez neho sa farba oreže na 1 a nežiari nič. 2D renderer prepínač HDR v inšpektore kamery neukazuje, preto ho zapnite skriptom.

Nízky prah, celý obraz

Prah 1, HDR materiál

Keď je glow takto pod kontrolou, nemusí byť voliteľný. V Dreamice sme prepínač glow z nastavení zrušili, glow je súčasť vzhľadu.

#Emisná mapa: žiari len časť spritu

Ak má žiariť len časť spritu, pridajte mu emisnú mapu (emission map): druhú, čiernobielu textúru, ktorá hovorí, ktorá časť spritu žiari. Len tá časť dostane farbu nad 1, takže pri rune svieti jadro, nie celý obrys.

#Pulzovanie v expozičných stupňoch

Ak má žiarenie pulzovať, nenásobte farbu lineárne. HDR materiál môže mať jas okolo 2 na ôsmu a lineárne násobenie od 0 do 10 na ňom nie je vidieť vôbec. Pulz počítajte v expozičných stupňoch (EV), rovnako ako posuvník intenzity vo výbere HDR farby v Unity:

farba = odtieň × 2 ^ ev,   ev kmitá medzi minimom a maximom

#Krok 3: Dynamické 2D svetlo okolo hráča

K hráčovi dajte bodové 2D svetlo a okolo neho mäkkú žiaru. V Dreamice jedna sínusovka riadi naraz jas žiary, polomer svetla aj jeho intenzitu, takže pulzujú spolu. Farbu svetla môže určovať prostredie: v lese je biela, v močiari oranžová, v zime fialová, v pekle žltá. Pozadia a prekážky prepnite na osvetlené shadery, inak na svetlo nereagujú.

Krátke svetlá oživia udalosti. Keď vystrelí veverica s delom, rozsvieti sa jantárové svetlo s intenzitou 3, ktoré za 0,3 sekundy zhasne, a iskry z hlavne žiaria. Žiariť nemusí všetko: prach pri zmiznutí žaluďa je zámerne hnedý a nežiari.

#Rovnaký shader na nadväzujúcich plochách

Ak na seba nadväzujú dve pozadia, zdrojové obrázky majú rovnaký jas, a predsa je medzi nimi viditeľný šev, skontrolujte shadery. V Dreamice malo úvodné pozadie a nekonečné pozadie lesa každé iný shader. Jeden odtieň materiálu 0,733 ignoroval, druhý ho použil a stmavil les na 73 %. Riešenie je rovnaký shader na oboch plochách.

Dva shadery

Jeden shader

#Záblesk: prechod na vrchol namiesto pripočítania

Pri prechode do ďalšieho sveta svetlo a žiara vzplanú: nábeh 0,6 sekundy, krátke podržanie, doznenie 1,4 sekundy a žiara sa pritom raz otočí. Ak záblesk len pripočítate k pulzu, vrchol závisí od toho, v akej fáze je sínusovka práve vtedy, a každý záblesk je inak silný. Plynulo prejdite z pulzu na pevný vrchol:

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

Pripočítanie

Prechod na vrchol

#Krok 4: Ostré UI pre dnešné displeje

UI kreslené pre iPhone 7 má malé sprity. Tlačidlo v menu Dreamice malo sprite 128 × 64 pixelov a na telefóne s trojnásobnou hustotou bodov sa ťahalo na niekoľkonásobok. Prekreslite sprity vo väčšom rozlíšení: nové tlačidlo má 800 × 434, ukazovatele pokroku narástli z 200 × 26 na 800 × 104.

128 × 64

800 × 434

Ak UI stojí na NGUI, zvážte prepis. Kotvy v NGUI sa dopočítavajú po častiach počas viacerých snímok, dlhé reťaze kotiev sa občas ustália zle a mierka sa líši medzi Editorom, telefónom a iPadom. V Dreamice to opravy spoľahlivo nevyriešili, preto sme UI prepísali na uGUI a TextMeshPro. Postupujte obrazovku po obrazovke a starú verziu majte zapnutú vedľa ako predlohu. UI škálujte podľa výšky voči referenčnému rozlíšeniu (u nás 434 × 941 bodov) a rešpektujte bezpečnú oblasť displeja, teda výrez a zaoblené rohy. Po prepise NGUI z projektu úplne odstráňte, nech v ňom neostanú dva systémy UI.

#Limity: nekomprimované textúry

Tento postup mení len grafiku. Textúry sme v Dreamice vedome nekomprimovali, lebo sme chceli plnú ostrosť. Cena je veľkosť: už pôvodná hra mala v Editore 313 MB textúr v pamäti a v App Store má 299 MB. Kompresia by podľa nášho odhadu zmenšila textúry približne na 40 MB. Ak vám na veľkosti hry záleží, je to prvé miesto, kde ušetriť.

Iný príklad Unity hry od prvého riadku kódu po vydanie nájdete v článku o hre Space Impact Watch, výkonu v Unity sa venuje článok o navigácii hordy v Unity DOTS. Ak je hra ešte v Unity 4, neotvárajte ju priamo v Unity 6; bezpečný postup opisuje návod ako previesť projekt z Unity 4 do Unity 6. Ak máte starú Unity hru, ktorá vypadla z obchodov, a chcete ju vrátiť späť, ozvite sa nám.

Keď výbuch v hre odhodí stovky nepriateľov naraz, skutočný ragdoll pre každého z nich je príliš drahý. Fake ragdoll v Unity DOTS spravíte tak, že celé telo nepriateľa simulujete ako jeden bod s vlastnou jednoduchou fyzikou a model iba otáčate okolo stredu tela. Pád a vstávanie sú obyčajné animačné klipy, kosti sa nesimulujú vôbec.

Postup ukazujeme na tower defense hre pre PC, ktorú robíme v Unity s ECS (viac v referenciách). Bomba alebo fireball tam vymršťuje desiatky až stovky nepriateľov naraz. Pri 2 000 telách vo vzduchu stojí simulácia 0,53 až 0,59 ms na tik (tik je jeden krok hernej simulácie s pevnou dĺžkou).

#Prečo nie skutočný ragdoll

Skutočný ragdoll je desať a viac fyzikálnych telies spojených kĺbmi na každú postavu. Pri tisíckach postáv na obrazovke to nie je reálne.

Druhý dôvod je determinizmus: z rovnakého stavu musí vyjsť rovnaký výsledok. V našej hre na tom stojí opakovanie prehratej vlny z kontrolného bodu a kontrolujeme to hashom stavu simulácie po 1 800 tikoch.

#Telo ako jeden bod

Namiesto fyzikálneho enginu použite vlastnú jednoduchú 2,5D fyziku: poloha na mriežke, výška nad zemou, balistický let, odraz od stien a trenie. V našej hre sa takto pohybuje aj bomba a nepriateľ zasiahnutý výbuchom sa na chvíľu stane takým istým telesom. Inšpiráciou bolo, ako odletujú vojaci v hre Diplomacy is Not an Option.

Simulácia pozná len polohu, výšku a uhol natočenia. Otáčanie modelu do nej nezapisujte. Patrí do dodatočnej transformačnej matice entity, ktorú balík Entities (ECS v Unity) podporuje pre nerovnomernú mierku (dokumentácia).

#Fázy zrazeného nepriateľa

Zrazený nepriateľ prejde tromi fázami a potom sa vráti do davu:

pri zásahu:
    vypočítaj rýchlosť odpalu (sila, vzdialenosť od výbuchu, náhoda zo seedu)
    nájdi dopad na priechodnú bunku (pozri nižšie)
    zapni stav "zrazený", uvoľni miesto, ktoré mal obsadené pri cieli útoku
let:       teleso letí po parabole, model sa otáča okolo stredu tela
dopad:     poloha podľa natočenia (chrbát alebo brucho), krátke doklopenie
ľah:       čaká pevný počet tikov
vstávanie: klip vstávania z chrbta alebo z brucha, potom späť do davu

Stav „zrazený“ spravte ako komponent, ktorý sa dá zapnúť a vypnúť bez presúvania entity medzi chunkmi (pamäťovými blokmi, v ktorých ECS drží entity s rovnakou sadou komponentov). Navigácia, odtláčanie v dave aj rozhodovanie o útoku zrazených jednoducho preskočia. Ako funguje navigácia a odtláčanie veľkého davu, popisuje článok o navigácii hordy v Unity DOTS.

#Odpal: vyššie, nie ďalej

Najjednoduchší odpal je pod uhlom 45° ± 10°. Pri sile bomby 18 m/s a gravitácii 20 m/s² vychádza vrchol letu okolo 4 m. Telo preletí nízko nad davom a efekt sa v ňom stratí.

Vyššia sila nepomôže, lebo s ňou rastie aj dolet. Rozdeľte rýchlosť na dve zložky a každú násobte zvlášť: uhol 60° ± 5°, vodorovná zložka × 0,85, zvislá × 1,3. Vrchol je potom okolo 10 m, dolet ostane okolo 15,5 m a let trvá približne 2 sekundy.

Smer sa od výbuchu odchyľuje o ± 15°, sila o ± 20 % a na okraji výbuchu klesá na polovicu. Náhodu neberte z globálneho generátora, ale z hashu seedu levelu, identifikátora nepriateľa a poradového čísla výbuchu. Požiadavky na zrazenie spracúvajte zoradené, lebo joby bežiace na viacerých vláknach ich vytvoria v ľubovoľnom poradí. Dva behy tej istej vlny tak dajú tie isté oblúky.

Odhodenie je áno alebo nie. Každý zraziteľný nepriateľ pri zásahu aspoň spadne (rýchlosť je zdola obmedzená na 2 m/s), odolnosť mení len dolet. Imunitu dajte samostatným príznakom, v našej hre ho má najväčší typ nepriateľa. Keby imunita vyplývala z odolnosti (pri 0,95 vychádza rýchlosť pod 2 m/s) a slabé odhodenie by sa rušilo, nepriateľ by bol imúnny len náhodou.

#Dopad na priechodnú bunku

Nepriateľ nesmie dopadnúť do rokliny, na útes ani do pôdorysu veže. Priechodnosť sa určuje po bunkách mriežky a pre každú veľkostnú triedu nepriateľa zvlášť.

#Odraz od stien vo vzduchu nestačí

Prvé, čo napadne, je brať nepriechodné bunky ako steny, od ktorých sa letiace telo odrazí. Pri útese to vyzerá prirodzene, pri rokline nie: nad roklinou je vzduch, ale bunka je nepriechodná, takže sa telo odrazí od neviditeľného stĺpa nad jej okrajom. Navyše nič nezaručuje, že po odraze skončí na dobrom mieste.

#Predikcia dráhy pri odpale

Spoľahlivejšie je zistiť dopad hneď pri odpale. Let nasimulujte dopredu tým istým krokom ako skutočnú fyziku a skontrolujte bunku dopadu pre veľkostnú triedu nepriateľa. Ak nie je priechodná, skúšajte ďalšie varianty v pevnom poradí:

pre uhol v [0, +25, -25, +50, -50, ... , +175, -175]:
    pre násobok vodorovnej rýchlosti v [1, 0.7, 0.4, 0.1]:
        nasimuluj let
        ak je bunka dopadu priechodná pre triedu nepriateľa: použi tento smer a koniec
ak nič nevyšlo: vodorovná rýchlosť = 0 (výskok na mieste)

Najhorší prípad je 60 simulácií letu na jedného nepriateľa (15 smerov × 4 násobky). Zvislá rýchlosť sa nemení, takže výška letu ostáva rovnaká a skracuje sa len dolet. Ak nepriateľa počas letu zasiahne ďalší výbuch, predikciu spustite znova.

Aby telo po dopade neskĺzlo ani neodskočilo, nastavte mu koeficient odrazu od zeme 0 a veľké trenie. Ostane tam, kde predikcia povedala.

#Rotácia naplánovaná podľa výšky letu

Najjednoduchšie je točiť model náhodnou rýchlosťou, napríklad 180 až 540 °/s, a po dopade ho za 0,2 s doklopiť na najbližší ľah. Doklopenie je však vidieť, keď telo dopadne takmer vzpriamene. Dorovnávať rýchlosť otáčania v každom tiku tak, aby uhol pri dopade vyšiel presne vodorovne, pomôže len čiastočne: aj nízky odhod sa točí ako salto a otáčanie nesúvisí s tým, ako vysoko telo letí.

Lepšie je naplánovať rotáciu pri odpale z výšky letu:

výška = vz² / (2 g), čas letu z vz a výšky
cieľ = najbližšia vodorovná poloha v náhodnom smere (štvrť otočky zo stoja)
cieľ += polotočka za každých 2,5 m výšky, najviac 3
rýchlosť otáčania = (cieľ - aktuálny uhol) / čas letu

Strana dopadu vyplýva z uhla: tvárou k zemi znamená brucho, inak chrbát. Podľa nej sa vyberie klip vstávania. Ležiaci alebo vstávajúci nepriateľ si pri ďalšom zásahu ponechá aktuálny uhol a neskočí späť do vzpriamenej polohy.

#Model položený na zem

Model sa otáča okolo stredu tela, ale zem je pod jeho najnižším bodom a ten sa pri otáčaní mení. Odhad posunu z dvoch konštánt a sínusu uhla nesedí pre modely s rozhodenými rukami v klipe pádu: v našej hre sa model kostry (bežný nepriateľ) zanáral až 1,15 m pod zem a model nekromanta až 1,73 m.

Odhad

Zmerané

Spoľahlivejšie je najnižší bod zmerať. Pri zapekaní (bake) animácií spočítajte pre klip pádu najnižší bod tela pri 72 natočeniach po 5° a za behu z tabuľky interpolujte. Najhlbšie zanorenie tak klesne na 4 mm. Jedno minimum cez všetky snímky klipu však nestačí: telo by po dopade viselo 0,15 až 0,28 m nad zemou, kým ho klip vstávania nestiahne dole. Tabuľka preto musí mať rozmer snímky × natočenia.

Pri pomalej naplánovanej rotácii sa ukáže ešte jeden efekt. Ak model kladiete najnižším bodom na výšku letu, stred tela pri prechode zo stoja do vodorovnej polohy klesne o rozdiel polovice výšky a polovice hrúbky postavy. Telo potom na začiatku letu stúpa len pomaly a až potom zrýchli. Model preto zdvihnite o rozdiel polovičného rozmeru v stoji a pri aktuálnom uhle, najviac o výšku letu. Stred tela potom ide po parabole.

#Mŕtvi nepriatelia: telo, decal a prach

Nepriateľ zabitý výbuchom má odletieť tiež. Vytvorte preň letiace telo: kópiu entity bez herných komponentov (životy, odmena, cieľ). Telo preletí, dopadne, chvíľu leží a zmizne. Na jeho mieste ostane decal mŕtvoly (textúra premietnutá na zem) ako vo Warcrafte 3 a obláčik prachu. V našej hre je strop 1 000 letiacich tiel a 1 500 decalov.

Decal je pohľad zhora na snímku z klipu pádu, natočený rovnako ako ležiace telo, takže výmena tela za decal nie je vidieť. Prvá snímka klipu vstávania sa nehodí, lebo postavu z chrbta už posadí. Obláčiky prachu zlučujte v bunke 1,5 m. Bomba do davu tak vytvorí pár väčších oblakov namiesto stoviek malých.

#Pasce v Unity Entities

• Matica z bakera zmizne. Ak dodatočnú maticu pridáte pri bake, transformačný systém ju pri rovnomernej mierke odstráni a zrazení sa nehýbu. Pri bake si preto vyžiadajte nerovnomernú mierku. Vtedy sa však do tej istej matice presunie celá mierka prefabu, takže ju neprepisujte samotnou rotáciou. Inak má zrazený nepriateľ so zväčšením 2× polovičnú veľkosť, aj keď vstane. Mierku si uložte zvlášť a maticu skladajte z mierky a rotácie.
• Výška koreňa pri importe klipov. Pri humanoid klipoch sa zvislý pohyb koreňa (root) zahodí a postavy pri vstávaní prepadnú pod podlahu. Výšku koreňa zapečte do pózy. Voľbu ukotviť pózu na chodidlá nepoužívajte, posunie celé telo o meter dole.
• Matica v uzavretom tvare. Posun, rotácia a spätný posun ako tri násobenia matíc sú v jobe merateľne pomalšie než ručne napísaný vzorec pre výslednú maticu.
• Burst so starou verziou. Po zmene polí komponentu, ktorý číta Burst job, môže editor padať alebo hlásiť nezmysly. Pomôže reštart editora.

#Výkon

Merané v Unity Editore na M3 Pro, 10 000 kostier v benchmark scéne, sila odpalu 18. Časy sú súčet CPU času Burst jobov cez všetky vlákna, nie čas snímky. Graf a tabuľka sú bez predikcie dráhy a tabuliek dopadu.

• Simulácia rastie lineárne, zhruba o 0,25 ms na tisíc zrazených. S predikciou dráhy a tabuľkami dopadu je to pri 2 000 zrazených 0,58 až 0,59 ms, teda mierne nad cieľom 0,5 ms. Rozumný strop je preto 3 000 súčasne zrazených, čo je okolo 0,8 ms.
• Výbuch do skupiny 359 nepriateľov pri stene stojí v systéme požiadaviek na zrazenie 1,3 až 1,9 ms v jednej snímke. Väčšinu tvorí predikcia dráhy.
• FPS z editora sa porovnať nedá, medzi dvoma behmi tej istej konfigurácie bol rozdiel až 80 FPS.

#Limity riešenia

Príprava vizuálu stúpla v inej testovacej scéne až na 1,3 ms, pravdepodobne pre čítanie tabuľky dopadu pre každé telo. Je to prvý kandidát na optimalizáciu. FPS v builde a záťaž pri hromadnom zabití 1 000 nepriateľov naraz (cieľ do 1,5 ms navyše na snímku) zatiaľ nemáme zmerané.

Ak riešite podobnú simuláciu davu alebo efektov v Unity a potrebujete pomoc, napíšte nám.

Shmup (shoot 'em up, strieľačka, v ktorej loď letí proti vlnám nepriateľov) na Apple Watch naráža na tri veci: malý displej, prst, ktorý zakryje polovicu hry, a rôzne veľkosti hodiniek. Riešia sa tromi rozhodnutiami: celá hra beží v pevnej mriežke 84 × 48 bodov, kolízie sa počítajú ručne obdĺžnikmi a levely sú tabuľky s časmi, nie kód. Loď sa ovláda korunkou Digital Crown a strieľa sama.

Postup ukazujeme na hre Space Impact Watch, remaku strieľačky Space Impact z telefónu Nokia 3310 z roku 2000, ktorá beží na hodinkách aj na iPhone a iPade. Príklady sú zo SpriteKitu, 2D herného frameworku od Apple, ale princípy platia pre každý shmup na malú obrazovku.

#Pevné virtuálne rozlíšenie 84 × 48

Najprv sa rozhodnite, v akých jednotkách bude hra počítať. Ak použijete body obrazovky, svet bude na každej veľkosti hodiniek inak veľký. Lepšie je zvoliť malé virtuálne rozlíšenie a všetko počítať v ňom. V našej hre je to 84 × 48, presne ako mal displej Nokie 3310. Pozície, rýchlosti, veľkosti spritov aj dráhy nepriateľov sú v týchto jednotkách. Pri štarte scény sa raz vypočíta, koľko bodov obrazovky má jeden virtuálny pixel (šírka scény deleno 84), a všetko sa ním len vynásobí.

Čo tým získate:

• Rovnaký vzhľad na každom zariadení. Hra vyzerá rovnako na každej veľkosti hodiniek aj na iPade, mení sa len veľkosť bloku.
• Level dizajn v malých celých číslach. Nepriateľ letí vo výške 13, raketa zatáča v bode x = 20.
• Jednoduchú grafiku. Sprity sú jednofarebné a kreslené v desaťnásobnej veľkosti, jeden virtuálny pixel je v zdrojovom obrázku blok 10 × 10. Farbu dostanú až v hre. Na svetlých leveloch sú čierne na zelenom pozadí, na tmavých sa to otočí.

#Ovládanie korunkou a automatická streľba

Na hodinkách prst zakryje polovicu hry, preto sa loď neovláda dotykom. Pohyb rieši Digital Crown: otočenie korunky posunie loď hore alebo dole. Pridajte nastavenie citlivosti a možnosť otočiť smer.

Streľba je automatická, v našej hre každých 0,4 sekundy, od štvrtého levelu každých 0,3. Displej slúži len na jedno gesto: potiahnutím doprava hráč použije jednu z troch špeciálnych zbraní.

Na hodinkách je vibrácia pri zásahu rovnako dôležitá ako animácia, malý výbuch na displeji si hráč ľahko nevšimne. Haptiku volajte cez jedno rozhranie (zásah, smrť nepriateľa, porazený boss), ktoré každá platforma vykoná po svojom: hodinky vibráciou, iPhone vlastným spôsobom. Verzia pre telefón nemá korunku, namiesto nej má tlačidlá na displeji, ktoré používajú rovnaké nastavenie citlivosti aj smeru.

#Herná slučka v jednej scéne

Celá hra môže byť jedna scéna s jednou slučkou:

každý snímok:
    posuň všetky objekty
    skontroluj kolízie
    podľa času v leveli pridaj nových nepriateľov

Veci pridávajte v poradí, v ktorom sa dajú čo najskôr testovať:

• Streľba a pohyb hráča. Bez nich sa nedá nič otestovať.
• Nepriatelia a kolízie. Prvému nepriateľovi stačí letieť rovno doľava a zomrieť po jednom zásahu.
• Vibrácie a animácie zásahu. Na malom displeji bez nich hráč nevie, že zasiahol.
• Pozadie a HUD. Životy, skóre, počet špeciálnych zbraní. Ak HUD na niektorom leveli prekáža, presuňte ho dole.

Na konci máte hrateľnú slučku so životmi, skóre, výbuchmi, pozadím a respawnom hráča. Ak hernú logiku držíte oddelene od vykresľovania a vstupu, môžu ju zdieľať verzie pre hodinky aj telefón.

#Kolízie obdĺžnikmi namiesto fyzikálneho enginu

SpriteKit má fyzikálny engine a ponúka sa použiť ho aj na kolízie. Každý objekt dostane fyzikálne telo vytvorené z obrysu spritu, presnú detekciu kolízií a kategóriu (hráč, nepriateľ, strela, špeciálna zbraň) a engine sám hlási dvojice, ktoré sa dotkli. Apple v dokumentácii k fyzikálnym telám uvádza, že telá z alfa kanála textúry sú najpresnejšie a zároveň výpočtovo najdrahšie. V našej hre sme to skúsili a vrátili sme sa k ručnej kontrole.

Ručná kontrola je jedna funkcia, ktorá po sebe prejde dvojice skupín a porovná obdĺžniky:

pre každú dvojicu skupín:
    (hráč a nepriatelia, hráč a strely, strely a nepriatelia, strely a strely)
    pre každý objekt A z prvej skupiny a objekt B z druhej:
        ak sa obdĺžnik A prekrýva s obdĺžnikom B:
            vyrieš zásah

Výhody: poradie kontrol máte pod kontrolou a celé pravidlo „čo sa stane pri zásahu“ je na jednom mieste. Nepresnosť je malá, lebo na mriežke 84 × 48 sú sprity také drobné, že obdĺžnik a skutočný obrys sa líšia len o pár virtuálnych pixelov.

#Pooling len tam, kde sa oplatí

Pooling znamená, že objekt po zániku nezmažete, len ho skryjete a nabudúce použijete znova. Je lákavé poolovať všetko vrátane výbuchov a power-upov. Má to však cenu: každá kolízia a každý update musí najprv overiť, či je objekt vôbec živý. Stačí jedna zabudnutá kontrola a skrytý nepriateľ zabije hráča alebo skrytá strela zostrelí raketu. Keď sme v našej hre pooling zo všetkého odstraňovali, mazali sme hlavne tieto kontroly.

Jednoduché pravidlo: poolujte to, čoho je veľa a vzniká to stále rovnako. Hráč si pri štarte vytvorí 21 striel a potom ich len recykluje. Nepriatelia a ich strely sa tiež znovu používajú, výbuchy a power-upy vznikajú a zanikajú normálne.

#Levely ako tabuľka časov

Level nemusí byť kód, stačí zoznam záznamov. Každý záznam hovorí, čo sa objaví, v ktorej sekunde, v akej výške a ako sa pohybuje. Pohyb je zoznam bodov, cez ktoré nepriateľ letí rovnakou rýchlosťou. Voliteľne pribudnú časy výstrelov, výpad bossa alebo generátor menších nepriateľov.

každý snímok:
    čas = teraz - začiatok levelu - čas v pauze
    pre každý záznam v tabuľke levelu:
        ak záznam ešte nebol použitý a čas > záznam.čas:
            vytvor objekt podľa záznamu
            označ záznam ako použitý

Takto zapísaný level sa ľahko ladí: posunúť vlnu o pol sekundy znamená zmeniť jedno číslo. Na časovej osi je vidno aj rytmus, o ktorý ide: krátka vlna, pauza, iný typ nepriateľa, power-up pred ťažším úsekom.

Nevýhodu cítiť pri väčších zmenách. Najhustejší level našej hry má 71 riadkov a taká tabuľka sa bez editora číta zle. Výhodnejšie je zapisovať levely ako vlny (skupina nepriateľov s jedným vzorom pohybu), nie ako jednotlivé lode.

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

Pre rebríček (v našej hre Game Center) potrebujete režim, ktorý nekončí. Ručne písanú tabuľku v ňom nahradí generátor, ktorý ju vyrába za behu. Vyrobí 20-ciferné pseudonáhodné číslo a jednotlivé dvojice číslic rozhodnú o jednej vlne:

číslo = ďalšie pseudonáhodné 20-ciferné číslo
typ = power-up, ak číslice 4 až 5 > 90, inak nepriateľ
sprite = číslice 1 až 2 modulo počet druhov nepriateľov
pauza pred vlnou = číslica 3 / 2 sekundy (aspoň 1)
výška = číslica 7, prepočítaná na výšku plochy
vzor pohybu = číslice 10 až 11 modulo 10
počet lodí vo vlne = číslica 17 / 2 + 1
rýchlosť = číslica 13 × (1 + poradie vlny / 10), v rozsahu 20 až 50
každá tridsiata vlna = boss, generovanie stojí, kým boss žije

Seed generátora (počiatočná hodnota) nechajte v hre pevný. Každý hráč potom dostane rovnaké poradie vĺn a skóre v rebríčku sa dá porovnávať.

Ako sa takýto režim vyvíja, ukazuje simulácia generátora mimo hry (300 vĺn, rovnaký seed ako v hre). Prvý boss príde po 29 vlnách, teda po 74 nepriateľoch a 3 power-upoch, zhruba po 130 sekundách. Prvých 30 vĺn letí minimálnou rýchlosťou 20, lebo jedna číslica je ešte menšia ako dolná hranica. Priemerná rýchlosť potom rastie na 28,5, 37,5 a 41, od 120. vlny je väčšina nepriateľov na maxime. Power-up je približne každá jedenásta vlna.

Slabina je, že generátor nepozná rytmus. Ručný level strieda tlak a oddych, generátor nie. Čiastočne to rieši pauza počas bossa a rast rýchlosti, ale ručne písané levely sa hrajú lepšie.

#Limity tohto prístupu

• Žiadne automatické testy. Všetko sa overuje ručne v simulátore a na hodinkách.
• Globálny stav. Väčšina stavu hry sú globálne premenné jednej scény. Pre hru len na hodinky je to pohodlné, pri pridaní verzie pre iPhone už nie.
• Levely bez editora. Tabuľka časov sa dobre ladí po malých krokoch, pri väčších zmenách by si zaslúžila editor.

Ak robíte hru na hodinky alebo inú malú obrazovku a chcete s niečím pomôcť, napíšte nám. Ako generujeme hlavolamy v ďalšej našej aplikácii, sme opísali v článku o generátore sudoku.

Sudoku s jediným riešením vygenerujete v dvoch krokoch. Najprv vyplňte prázdnu mriežku 9×9 celú, backtrackingom s náhodným poradím číslic. Potom z nej po jednom a v náhodnom poradí mažte políčka a po každom vymazaní solverom skontrolujte, či má zadanie stále práve jedno riešenie. Ak nie, číslicu vráťte späť. Na bežnom procesore to trvá v mediáne menej ako milisekundu.

Postup je vhodný pre každú hru alebo aplikáciu, ktorá potrebuje neobmedzený počet nových zadaní bez ručnej prípravy. Takto vznikajú sudoku napríklad v našej aplikácii s krížovkami a hlavolamami (App Store, Google Play).

#Prečo práve jedno riešenie

Pravidlá sudoku pozná každý: v každom riadku, stĺpci a štvorci 3×3 je každá číslica 1 až 9 práve raz. Menej sa hovorí o tom, že dobré zadanie má jediné riešenie. Až vtedy sa dá vyriešiť čistou logikou, bez hádania.

Má to aj praktický dôsledok. Hra si zvyčajne pamätá jedno riešenie a podľa neho kontroluje výsledok a dáva nápovedy. Ak má zadanie riešenia dve, hráč môže dôjsť k tomu druhému, ktoré je rovnako správne, a hra mu ho neuzná.

#Krok 1: Napíšte rýchly solver

Solver je program, ktorý sudoku vyrieši. Pracuje backtrackingom: vyplní políčko jednou z možných číslic, pokračuje ďalším políčkom, a keď narazí na spor, vráti sa a skúsi inú číslicu. Budete ho potrebovať dvakrát: na vyplnenie prázdnej mriežky a na kontrolu jednoznačnosti. Kontrola beží po každom vymazanom políčku, teda 40 až 70-krát na jedno zadanie, preto musí byť rýchla. Dve veci rozhodujú:

• Bitové masky. Pre každý riadok, stĺpec a štvorec si držte 9-bitové číslo s už použitými číslicami. Kandidáti políčka, teda číslice, ktoré doň ešte môžu prísť, sú potom jedna operácia: všetky číslice okrem tých, ktoré sú v jeho riadku, stĺpci alebo štvorci. Počet kandidátov je počet jednotkových bitov a dá sa vopred vypočítať do tabuľky s 512 hodnotami.
• Najprv políčko s najmenším počtom kandidátov. Nevyberajte prvé prázdne políčko zľava, ale to, ktoré má najmenej možností (v literatúre heuristika MRV, minimum remaining values). Políčko s jediným kandidátom vyplňte hneď, políčko bez kandidáta znamená slepú vetvu a vraciate sa.

Na ťažkých zadaniach potrebuje kontrola jednoznačnosti s týmto pravidlom v mediáne 311 krokov. Ak solver berie políčka postupne zľava doprava, v mediáne 28 579 krokov a v najhorších 5 % prípadov vyše 300 000. Rozdiel je zhruba 90-násobný.

#Krok 2: Vyplňte celú mriežku

Plnú mriežku dostanete tým istým solverom spusteným na prázdnej mriežke. Jediný rozdiel je, že kandidátov políčka skúšate v náhodnom poradí. Prvé nájdené riešenie je náhodná, platná, úplne vyplnená mriežka.

#Prečo nestačí vymazať náhodné políčka

Najjednoduchší nápad je vymazať z plnej mriežky N náhodných políčok, napríklad 40, 50 alebo 55 podľa obťažnosti. Zadanie vyzerá v poriadku, len často nemá jediné riešenie.

Typický prípad je na obrázku. Štyri políčka v rohoch obdĺžnika, ktorý zasahuje do dvoch štvorcov, sa dajú vyplniť dvoma spôsobmi a zvyšok mriežky to nijako nerozhodne. Riešitelia sudoku tento vzor poznajú ako deadly pattern. Na 1 000 zadaniach pre každú obťažnosť vyzerá výsledok takto:

Ťažké zadanie z náhodného vymazávania má v priemere stovky riešení. Kontrola jednoznačnosti po každom vymazaní je preto nutná.

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

Prejdite všetkých 81 políčok v náhodnom poradí. Každé skúste vymazať a solverom spočítajte riešenia, ale počítanie zastavte pri dvoch. Viac netreba vedieť: jedno riešenie znamená, že políčko môže ostať prázdne, dve znamenajú, že ho treba vrátiť.

zadanie = kópia plnej mriežky
prázdnych = 0
pre každé políčko v náhodnom poradí:
    ak prázdnych == cieľ: koniec
    číslica = zadanie[políčko]
    zadanie[políčko] = prázdne
    ak počet_riešení(zadanie, najviac 2) == 1:
        prázdnych = prázdnych + 1
    inak:
        zadanie[políčko] = číslica

Políčko, ktoré raz vrátite, už neskúšajte znova. Ďalšie mazanie zadanie len uvoľňuje, takže ak políčko nešlo vymazať teraz, nepôjde ani neskôr.

#Krok 4: Nastavte obťažnosť počtom prázdnych políčok

Najjednoduchšia miera obťažnosti je počet vymazaných políčok. Tri úrovne, ktoré používame v našej hre:

Čím menej číslic ostáva, tým častejšie by ďalšie vymazanie pokazilo jednoznačnosť a políčko sa musí vrátiť. Pri ťažkej úrovni sa jeden prechod občas zastaví skôr, než dosiahne 55 prázdnych políčok. Vtedy vygenerujte novú plnú mriežku a skúste to znova. Pri meraní na 1 000 ťažkých zadaniach stačil prvý prechod v 97,6 % prípadov a nikdy nebolo treba viac ako 3 pokusy.

#Rýchlosť a spoľahlivosť generátora

Generátor sme spustili na 1 000 zadaniach pre každú obťažnosť (Node.js 22 na serverovom procesore, telefón bude pomalší):

Každé vygenerované zadanie sme navyše nezávisle skontrolovali solverom. Všetkých 3 000 malo jediné riešenie.

#Kde počet prázdnych políčok nestačí

Počet vodítok je hrubá miera obťažnosti. Dve zadania s 26 číslicami môžu byť rôzne ťažké podľa toho, aké logické techniky vyžadujú. Presnejšia obťažnosť by zadanie vyriešila ako človek a zaznamenala najťažšiu techniku, ktorú musela použiť. Na mobilnú hru, kde si hráč vyberá z troch úrovní, počet vodítok stačí.

Ak riešite podobný problém, generujete hlavolamy alebo potrebujete mobilnú aplikáciu, napíšte nám. Ako vygenerovať osemsmerovku s tajničkou, opisuje samostatný návod. Švédskej krížovke s tajničkou sa venuje ďalší návod.

Švédsku krížovku s tajničkou vygenerujete v dvoch fázach: najprv lokálnym prehľadávaním nájdite masku, teda rozmiestnenie políčok s legendami a políčok na písmená, a potom ju vyplňte slovami zo slovníka ako úlohu s obmedzeniami (CSP) s backtrackingom. Tajničku do mriežky nevkladajte vopred. Až keď je krížovka hotová, hľadajte vtip, ktorého pointa sa v nej dá prečítať zľava doprava a zhora nadol.

Takto vznikajú švédske krížovky v našej aplikácii s krížovkami a osemsmerovkami (App Store, Google Play). Jedna mriežka stojí niekoľko až desiatky sekúnd procesorového času, preto ich generujeme vopred na výkonnejšom počítači a do aplikácie ich pribalíme. Osemsmerovka sa generuje úplne inak a jednoduchšie, postup je v článku Ako vygenerovať osemsmerovku s tajničkou.

#Čo musí švédska krížovka spĺňať

Švédska krížovka nemá čierne políčka. Každé políčko je písmeno alebo legenda so šípkou doprava či nadol. Z toho vyplývajú tvrdé podmienky:

• Každé písmeno patrí vodorovnému aj zvislému slovu. Písmeno, ktoré kríži len jedno slovo, sa nedá skontrolovať a v krížovke pôsobí ako chyba.
• Každé slovo má aspoň dve písmená a pred ním je legenda. Preto je prvý riadok a prvý stĺpec vždy celý z legiend.
• Písmená tvoria jeden súvislý celok, žiadne odtrhnuté ostrovy.
• Každé slovo musí byť v slovníku a mať aspoň jednu legendu. Žiadne slovo sa v mriežke neopakuje.

K tomu mäkké kritériá kvality: málo dvojpísmenových slov, žiadne legendy, ktoré neukazujú na nič, a čo najmenej veľmi dlhých slov, ktoré sa ťažko plnia. Problém je výpočtovo ťažký. Engel a kol. (2012) ukázali, že už samotné plnenie masky slovami je NP-úplné.

#Prečo nestačí plniť mriežku slovo po slove

Prvý nápad je postupovať ako človek s ceruzkou: rozdeliť tajničku na slová, položiť ich do riadku ako v novinách, cez každé jej písmeno preložiť krížiace slovo a zvyšok mriežky dopĺňať greedy algoritmom. Greedy algorithm v každom kroku vyberie možnosť, ktorá vyzerá najlepšie práve teraz, a rozhodnutie už nikdy neprehodnotí. Kde nič nepasuje, ostane diera. A keďže sa greedy plnenie nevie vrátiť, zlých prvých desať slov zvyšok mriežky už nezachráni.

Lepšia heuristika výberu slov pomôže len trochu. Môžete skúšať dĺžky krížiacich slov od stredných, okolo piatich písmen, ku krajným. Alebo použiť evolučný prístup: populácia rozpracovaných krížoviek, z každej päť potomkov s jedným slovom navyše, ohodnotenie podľa počtu zaplnených políčok, počtu samohlások a rovnomernosti písmen a do ďalšej generácie postúpia len najlepšie. Výsledky sú o niečo hustejšie, ale diery ostanú, lebo heuristika vidí len najbližší krok.

Riešenie prináša bakalárska práca Jakoba Engela z TU Mníchov (2009), ktorý je aj prvým autorom spomínaného článku. Úlohu rozdeľte na dve nezávislé fázy: najprv nájdite dobrú masku bez ohľadu na slová, potom ju plňte. Engel na masku použil evolučný algoritmus. My používame jednoduchšie lokálne prehľadávanie s náhodnými otrasmi, opísané v nasledujúcom kroku.

#Krok 1: maska cez hill climbing

Maska je mriežka, v ktorej je každé políčko buď legenda, alebo písmeno. Na jej hľadanie stačí hill climbing: lokálne prehľadávanie, ktoré robí malé zmeny a ponechá tie, ktoré riešenie nezhoršia.

Začnite náhodne, s legendami asi na 22 % vnútorných políčok. Každú masku ohodnoťte pokutou. Tvrdé porušenia (príliš krátke slovo, písmeno bez krížiaceho slova, odtrhnutý ostrov) nech stoja zväčša 1 000 bodov, mäkké nedostatky (dvojpísmenové slová nad rozpočet, legenda, ktorá neukazuje na žiadne slovo, zhluky legiend) 50 až 500.

Potom v cykle zmeňte jedno políčko z legendy na písmeno alebo naopak, prípadne posuňte legendu o políčko šikmo. Zmenu ponechajte, ak sa pokuta nezvýšila, inak ju vráťte. Polovicu zmien namierte na políčka s najvyššou pokutou, potom hrubé chyby zmiznú rýchlo:

Hill climbing ľahko uviazne v lokálnom minime. Keď sa 2 000 krokov nič nezlepší, mriežku „zatraste“: v najlepšej doteraz nájdenej maske náhodne prehoďte päť políčok a hľadajte ďalej. Na grafe sú to špičky. Ak ani po troch zatraseniach nie je lepšia maska a nemá tvrdé porušenia, skončite.

Výsledná maska má zvyškovú pokutu 200 za mäkké nedostatky, ale žiadne tvrdé porušenie:

Pokuty za legendu bez slova a za odtrhnutý ostrov sa oplatí mať v maske od začiatku. Na veľkom súbore hotových krížoviek bez nich malo 13,2 % legiend neukazujúcich na žiadne slovo a 23,5 % mriežok odtrhnutý ostrov písmen. S nimi je to 5,0 % a 0 %.

#Krok 2: plnenie slovami ako CSP

Z masky vznikne zoznam slotov, teda miest na slová so známou dĺžkou a kríženiami. Plnenie je klasická úloha s obmedzeniami (constraint satisfaction problem, CSP): každý slot je premenná, jeho doména sú slová, ktoré sa doň zmestia, a obmedzenia sú zhodné písmená v kríženiach. Rieši sa backtrackingom, teda prehľadávaním, ktoré sa pri slepej vetve vráti o krok späť a skúsi inú možnosť:

pre každý slot: doména = všetky slová danej dĺžky
kým nie sú všetky sloty vyplnené:
    vyber slot s najmenšou doménou (pri zhode ten s najviac kríženiami)
    pre každé slovo z domény, od najlepšieho:
        polož slovo
        zúž domény krížiacich slotov na slová so zhodným písmenom
        ak niektorá doména ostala prázdna: vráť zmenu, skús ďalšie slovo
        inak pokračuj ďalším slotom
    ak žiadne slovo nevyhovuje: vráť sa o slot späť
po 50 000 krokoch to vzdaj

V literatúre sa tieto heuristiky volajú MRV (minimum remaining values, najprv slot s najmenej možnosťami) a forward checking (po každom položení zúžiť domény susedov, aby sa slepá vetva odhalila hneď, nie o desať slov neskôr). Slovník si predpočítajte podľa dĺžky, pozície a písmena. Slová so „Š na treťom mieste“ sú potom jeden prienik množín, nie prechod celým slovníkom.

Dôležité je aj poradie slov. Prednosť dajte slovám, ktoré majú v slovníku viac rôznych legiend. Je to jednoduchý ukazovateľ bežného krížovkárskeho slova. Bez neho sa mriežka zaplní neznámymi skratkami.

#Krok 3: tajnička až v hotovej mriežke

Pri plnení ešte neviete, aká bude tajnička. Prečítajte písmená hotovej mriežky zľava doprava a zhora nadol a hľadajte vtip, ktorého pointa je v tomto reťazci podpostupnosťou. Písmená teda idú v správnom poradí, ale nemusia byť vedľa seba. Ak sa nájde, rozmiestnite písmená tajničky čo najrovnomernejšie po mriežke, aby sa pointa nedala uhádnuť z jedného slova.

Toto poradie (najprv mriežka, potom vtip) zásadne zvyšuje počet hotových krížoviek. Jedna mriežka 12×12 v našom meraní pasuje v priemere na 86 vtipov zo slovenského zoznamu (5 960 vtipov). Vždy sa teda nájde taký, ktorý ešte v danej veľkosti nebol použitý.

#Prečo nevkladať tajničku vopred ako v novinách

V novinách je tajnička zvyčajne pokope, v jednom riadku a rozdelená na slová. Dá sa to dosiahnuť dvoma spôsobmi a oba dávajú veľmi málo výsledkov.

Prvý spôsob je vložiť tajničku do mriežky vopred. Vtedy sa do nej musí zmestiť. Pointa má u nás v priemere 10,3 písmena a 2 slová. Takto vyzerá podiel vtipov zo slovenského zoznamu, ktoré sa do danej veľkosti vôbec dajú položiť:

S tajničkou vloženou vopred uspeje plnenie pri malých mriežkach približne rovnako často ako bez nej. Pri 15×15 to bolo 5 zo 60 pokusov oproti 8 bez tajničky, pri 18×18 ani jeden zo 60. Každá taká mriežka navyše slúži jedinému vtipu a pri malých veľkostiach sa väčšina vtipov nedá ani položiť.

Druhý spôsob je nechať mriežku vzniknúť voľne a pointu v nej hľadať ako súvislý úsek. Na vzorke 2 200 hotových slovenských krížoviek (200 z každej veľkosti od 8×8 po 18×18) sa celá pointa ako súvislý úsek v jednom riadku alebo stĺpci našla len v 81 mriežkach (3,7 %). Keď môže každé slovo pointy ležať inde, je to 443 mriežok (20 %), a to ešte bez podmienky, že slová budú pri sebe. Pri čítaní v poradí sa vtip našiel v každej z nich. Za cenu tajničky roztrúsenej po mriežke dostanete rádovo viac krížoviek.

#Výkon generátora a prečo nebeží v telefóne

Generátor bežal 60 pokusov pre každú veľkosť so slovenským slovníkom, v jednom vlákne (JavaScript v Node 22, serverový procesor Intel Xeon 2,8 GHz v cloude). Pokus je jedna maska a jedno plnenie. „Úspešné plnenie“ znamená, že CSP našiel riešenie do 50 000 krokov.

Čo z meraní vyplýva:

• Malá mriežka nie je ľahká. V 8×8 je veľa krátkych slotov s veľkým počtom krížení a málo voľnosti, plnenie uspeje len v 5 % pokusov. Jedna vyplnená mriežka stojí v priemere asi 10 sekúnd procesora pri 8×8, 4 sekundy pri 12×12 a 18 sekúnd pri 18×18.
• Väčšina pokusov skončí neúspechom. Pokusy preto spúšťajte paralelne na všetkých jadrách a berte prvý dosť dobrý výsledok.
• V telefóne to nemá zmysel. Hráč nechce pri otvorení obrazovky čakať desiatky sekúnd a aplikácia by musela niesť celý slovník s legendami. Generátor v aplikácii navyše musí často púšťať UI k slovu, inak aplikácia zamŕza.

#Generovanie vo veľkom

Generátor preto patrí na počítač s viacjadrovým procesorom. U nás má každé jadro vlastné vlákno so slovníkom načítaným raz pri štarte. Mriežka je hotová, keď niektoré vlákno vráti výsledok s dostatočne malým počtom nevyužitých políčok. Nepretržitý režim generuje dookola jednu krížovku z každej veľkosti v každom jazyku. Takto vzniklo vyše 14 000 krížoviek v štyroch jazykoch (slovenčina, čeština, angličtina, nemčina) a jedenástich veľkostiach od 8×8 po 18×18. Každý vtip je v danej veľkosti a jazyku najviac raz.

Pri takom objeme rozhodujú dve veci:

• Formát. Úplný zápis má okolo 28 kB na krížovku a celý korpus 390 MB. Väčšina sa dá dopočítať (súradnice, typy políčok, čísla legiend). Kompaktný zápis s mriežkou ako jedným reťazcom má okolo 2 kB, celý korpus 15 MB a v inštalačnom balíku aplikácie asi 7 MB.
• Meranie kvality. Podiel legiend bez slova a mriežok s ostrovmi merajte po každom generovaní a nechajte kontrolu zlyhať, ak sa čísla zhoršia.

#Čo riešenie nepokrýva

• Legendy bez slov. Priemerná krížovka má stále 2,7 legendy, ktoré neukazujú na nič. Ľavý horný roh je taký vždy.
• Slovník bez frekvencií. Nemecký slovník z Wiktionary má na väčšinu slov jedinú legendu, takže poradie podľa počtu legiend skoro nerozlišuje a do mriežky sa dostávajú zriedkavé slová. Pomohol by frekvenčný slovník, zatiaľ ho nemáme.
• Tajnička nie je pokope. Kto je zvyknutý z novín, môže ju hľadať v riadku. Je to kompromis, nie ideál.

Ak riešite podobný problém s generovaním obsahu alebo potrebujete mobilnú aplikáciu, napíšte nám.

3D model telefónu vygenerujete v prehliadači tak, že obdĺžnik so zaoblenými rohmi vytiahnete do hĺbky a potom z neho booleovskými operáciami (CSG) vyrežete prednú stranu, tlačidlá, reproduktory a konektor. Celé zariadenie potom popisuje pár čísel v milimetroch a nový model je zmena týchto čísel, nie modelovanie v 3D programe.

Hodí sa to všade, kde potrebujete veľa podobných zariadení alebo ich má upravovať používateľ: konfigurátory, mockupy, náhľady produktov. Ako príklad z praxe slúži Ecranify, nástroj na 3D mockupy pre screenshoty do App Store a Google Play, v ktorom nie je ani jeden hotový 3D model. Nižšie je postup krok za krokom aj s meraním, ktoré ukazuje, kde sa dá na výpočte ušetriť najviac.

#Čo budete potrebovať

• Three.js na scénu, kamery, svetlá a hlavne geometriu. Geometria je v Three.js mesh, teda sieť trojuholníkov.
• Knižnicu three-bvh-csg na booleovské operácie nad meshmi. Zrýchľuje ich priestorovým indexom (BVH, bounding volume hierarchy), vďaka ktorému netestuje každý trojuholník proti každému.
• Popis zariadenia ako dáta, napríklad JSON s rozmermi tela, polomerom rohov, veľkosťou bevelu a zoznamom prvkov na bokoch. Všetky polohy zadávajte v milimetroch od stredu zariadenia.

#Krok 1: Vytiahnite obdĺžnik do 3D

Nakreslite 2D obdĺžnik so zaoblenými rohmi v skutočných rozmeroch, napríklad 163,4 × 78 mm, a vytiahnite ho (extrúzia) do hĺbky 8,75 mm. Dostanete dosku s ostrými hranami. Žiadny telefón také nemá, preto pri vyťahovaní zapnite aj bevel, teda zaoblenie hrany. Three.js robí oboje v jednom kroku.

Len extrúzia

+ rohy a bevel

Pozor na jednu vec: bevel sa pridáva navonok. Ak chcete presný vonkajší rozmer, zmenšite 2D tvar aj hĺbku o veľkosť bevelu.

b = min(bevel, hĺbka / 2)
tvar = zaoblený obdĺžnik(šírka - 2b, výška - 2b, polomer rohu - b)
telo = vytiahni(tvar, hĺbka - 2b, bevel b)

Hladkosť oblúkov (teseláciu) určuje počet segmentov, na ktoré sa oblúk rozdelí. Viac segmentov znamená hladší tvar a viac trojuholníkov. Toto číslo neskôr rozhodne o rýchlosti celého výpočtu, preto sa k nemu vrátime v kroku 7.

#Krok 2: Vyrežte vaňu pre displej

CSG (constructive solid geometry) skladá telesá z jednoduchších telies pomocou troch operácií: zjednotenie, rozdiel a prienik. Rozdiel funguje ako vrták: jedno teleso odoberie materiál z druhého.

Displej telefónu nie je zarovno s rámom, sedí v plytkej vani. Tú vyrobíte tak, že spravíte druhú, o 1,4 mm menšiu kópiu tela, necháte z nej len prednú časť hrubú 0,7 mm (prienik s veľkým kvádrom) a túto časť odčítate od tela. Do vzniknutej vane potom vložíte tmavú plochu displeja.

Rezné teleso

Po odčítaní

Dva praktické detaily:

• Kváder na prienik musí byť naozaj veľký. Stačí mu orezávať hĺbku, ale v šírke a výške musí presahovať celé zariadenie. Neodvodzujte ho od hĺbky: napríklad 20-násobok hĺbky je pri tenkom vysokom telefóne menej ako jeho výška a hore a dole ostane neorezaný rám.
• Zväčšite rezné teleso o pár promile. Keď majú dve telesá presne rovnakú plochu, CSG si nevie rady, ktorá strana je vnútri. Mierka 1,002 tomu predíde a okom ju nevidno.

#Krok 3: Bočné prvky pripravte ako vrtáky

Každý prvok na boku je rovnaký recept s iným vrtákom. Tlačidlo napríklad vznikne z troch telies: zaoblený obdĺžnik o kúsok hlbší ako tlačidlo sa odčíta od rámu, okraj otvoru dostane malé skosenie a do otvoru sa vloží o niečo menšie teleso, ktoré z rámu trochu vytŕča.

Vrtáky

Výrez a tlačidlo

Reproduktory sú rad malých valcov, konektor je zaoblený obdĺžnik. Do každého otvoru vložte niečo tmavé: tenký disk do mriežky, platničku do konektora. Prázdna diera v tenkej škrupine pôsobí ako chyba, diera s tmavou výplňou pôsobí ako hardvér.

pre každý prvok v zozname prvkov boku:
    vrták = tvar prvku (valec, zaoblený obdĺžnik, ...)
    umiestni vrták na hranu podľa polohy v mm
    pridaj vrták do zoznamu rezov
    ak má prvok výplň: pridaj výplň do scény

Pridať tlačidlo je potom zápis do dát. Prvkov rýchlo pribúda: iPad Pro 13″ má 58 otvorov reproduktora, 4 tlačidlá, 2 antény a konektor, teda vyše 60 odčítaní od jedného tela.

#Krok 4: Predné detaily nevŕtajte

Výrez pre kameru, ostrovček v hornej časti displeja alebo indikátor domovskej obrazovky sú ploché. Rezať pre ne geometriu je zbytočná práca. Nalepte ich ako decal, teda obrázok premietnutý na povrch. Premietajte ho na skrytú rovinu cez celú prednú stranu a polohu zadávajte v rovnakých milimetroch ako všetko ostatné. Výnimkou je okrúhle domovské tlačidlo starších iPhonov. To má skutočnú hĺbku, ktorú vidno zboku, a preto ide cez CSG.

#Krok 5: Presuňte výpočet do Web Workera

JavaScript v prehliadači beží v jednom vlákne. To isté vlákno počíta, kreslí stránku a reaguje na kliky. Kým beží CSG, stránka stojí a nepomôže ani spinner, lebo aj ten potrebuje to isté vlákno.

Celé zostavenie zariadenia preto spustite vo Web Workeri, teda v samostatnom vlákne na pozadí. Worker dostane popis zariadenia, vráti hotové polia vrcholov a stránka ostane plynulá. Pri zmene parametra starý worker ukončite a spustite nový, nech nedopočítava zastaraný stav.

Výsledok z workera chvíľu trvá, preto pridajte okamžitý náhľad. Upravovaný prvok ukážte ako modrý priesvitný „duch“, jednoduchý kváder alebo valec s pár desiatkami trojuholníkov, ktorý sa dá postaviť v hlavnom vlákne hneď. Keď worker skončí, duch zmizne.

#Krok 6: Odčítajte všetky otvory naraz

Najpriamočiarejší spôsob je odčítať prvky postupne: otvor 1 od tela, potom otvor 2 od výsledku a tak ďalej. Každé odčítanie však znova postaví priestorový index celého tela, čo je najdrahšia časť výpočtu. Pri desiatkach prvkov čas rastie veľmi rýchlo.

Lepšie je najprv zozbierať všetky vrtáky pre dané teleso, spojiť ich do jedného meshu a odčítať raz.

rezy = []
pre každý prvok: pridaj jeho vrták do rezy
spojený = spoj všetky rezy do jedného meshu
telo = telo mínus spojený
ak spojenie zlyhá: odčítaj rezy po jednom

Meranie na zjednodušenej kópii postupu (Three.js 0.170, three-bvh-csg 0.0.17, Node 22, cloudový server s 2 jadrami Intel Xeon 2,1 GHz, medián z 5 behov):

Jedna podmienka: spojenie a jedno odčítanie dá rovnaký výsledok ako postupné odčítanie, len ak sa vrtáky neprekrývajú. Prvky sú na rôznych miestach, takže to bežne platí. Ak ale používateľ posunie dva prvky na seba, v mieste prekrytia môže vzniknúť drobná chyba.

#Krok 7: Počet segmentov majte ako parameter

Teselácia, ktorá stačí na zobrazenie, je pre CSG často zbytočne hustá. Pri 64 segmentoch na roh a 32 na bevel má telo 68 108 trojuholníkov. Polovicu (32 a 16) na 2 mm hrane nevidno, ale telo má len 17 676 trojuholníkov a tretí riadok tabuľky ukazuje, čo to robí s časom.

64 a 32 segmentov

32 a 16 segmentov

Malým prvkom s polomerom do 2 mm (otvory reproduktora, skrutky) dajte polovicu segmentov, náhľadom v galérii ešte menej. Kvalitu preto nedávajte ako konštantu do kódu, ale ako parameter zostavenia.

#Render na serveri bez grafickej karty

Ak potrebujete rovnakú scénu vykresliť aj na serveri, napríklad ako zálohu exportu, beží v Chrome bez obrazovky (headless), ktorý bez grafickej karty kreslí softvérovo. Tam sa každá neefektivita znásobí. V Ecranify najťažší tablet bez spomenutých úprav narazil na limit 15 minút. So spojenými rezmi, menšími textúrami, nižšou teseláciou a cache hotovej geometrie podľa hashu popisu zariadenia trvá render okolo pol minúty a opakovaný okolo 5 sekúnd. Podrobnosti aj s interaktívnymi ukážkami sú v anglickom článku na ecranify.com.

Ak riešite podobný problém s 3D v prehliadači alebo potrebujete appku na zákazku, napíšte nám.

Projekt z Unity 4 neotvárajte priamo v Unity 6 a hlavne v ňom nič neukladajte. Unity 6 staré binárne scény načíta len čiastočne a uložením stratu potvrdí; bezpečná cesta vedie cez Unity 2019.4, ktoré starý formát vie prečítať aj zapísať ako text, a až potom do Unity 6.

Týka sa to projektov, ktoré majú scény a prefaby uložené v binárnom formáte a skripty v UnityScripte, jazyku podobnom JavaScriptu, ktorý Unity kedysi podporovalo popri C#. Postup ukážeme na hre Onager, fyzikálnej hre s katapultom napísanej v Unity 4.1.2 a v UnityScripte. Projekt mal 126 skriptov, 75 scén a 78 prefabov, po prevode beží na Unity 6000.5 s URP (Universal Render Pipeline) a je zadarmo na App Store aj Google Play.

#Čo sa stane, keď projekt otvoríte v Unity 6

Najjednoduchší prístup je otvoriť projekt v Unity 6 a prepnúť serializáciu na Force Text, teda na ukladanie assetov ako čitateľný YAML. To nie je preklad súborov. Unity každý asset načíta cez svoj importér a zapíše späť ako YAML, takže všetko prejde loaderom Unity 6. Ten pri každej scéne hlási, že našiel Transform bez GameObjectu a „visiaci“ komponent zmaže. Uloženie to spraví natrvalo.

Rozsah straty sa dá zmerať nástrojom binary2text, ktorý je priložený k editoru a číta serializovaný súbor bez importéra. V Onagerovi sme jeho výpis porovnali s výsledným YAML a počítali len komponenty, ktoré zmizli z GameObjectov, ktoré prežili:

Bez straty nebola ani jedna zo 75 scén. Zmizli celé kamery pre HUD a hlavná kamera dostala novú, predvolenú. Dôležité je, že škoda vzniká už pri načítaní, nie pri uložení. Kým projekt nie je prevedený, nesmie ho Unity 6 uložiť, ani jednu scénu, ani jeden prefab.

#Krok 1: Zaznamenajte pôvodný stav

Skôr než na niečo siahnete, odfoťte si každú scénu a pre každú scénu si nástrojom binary2text uložte výpis pôvodného súboru. Podľa výpisu budete v kroku 3 kontrolovať kamery a v kroku 5 obnovovať HUD. Pôvodné binárne súbory nechajte v histórii gitu, nemažte ich.

#Krok 2: Prevod na text cez Unity 2019.4

Unity 2019.4 je posledný editor, ktorý formát z Unity 4.1 vie prečítať aj zapísať. Prevod robte so zatvoreným editorom v samostatnej kópii repozitára:

• Verzia projektu. V súbore s verziou projektu nastavte pôvodnú verziu (v Onagerovi 4.1.2), aby editor zvolil cestu pre starý projekt. Unity ju pri otvorení prepíše, stačí, že platí pri prvom importe.
• Prázdne balíky. Vyprázdnite zoznam závislostí balíkov. Jedna chyba kompilácie znamená, že nebude fungovať žiadna položka menu z editorových skriptov, a to vyzerá, ako keby sa menu vôbec neobjavilo.
• Import od nuly. Zmažte priečinok Library a nechajte projekt naimportovať.
• Force Text a vynútené prepísanie. Unity 2019.4 po zmene na Force Text existujúce súbory samo neprepíše. Treba to vyvolať funkciou na reserializáciu assetov, a to len assetov, nie aj ich meta súborov. Prepísanie všetkých meta súborov spôsobí, že Unity 6 potom importuje stále dokola.

Jedna pasca je v gite. Ak v nastavení atribútov gitu označíte scény ako text s koncom riadku LF, git z binárnych scén pri ukladaní do repozitára vyhodí bajty, ktoré vyzerajú ako koniec riadku. V Onagerovi to poškodilo osem scén. Na assety Unity atribút pre konce riadkov nedávajte, Unity aj tak zapisuje LF.

#Krok 3: Výsledok overte v editore, nie čítaním YAML

Čítanie prevedených súborov vedie k sebavedomým a nesprávnym záverom. Skrátené záznamy inštancií prefabov vyzerajú ako strata, rovnako ako kamera, ktorá sa len presunula do prefabu. Rozhoduje to, čo Unity postaví v pamäti. Každú prevedenú scénu otvorte a jej kamery porovnajte s výpisom originálu z kroku 1.

V Onagerovi mali po prevode všetkých 75 scén rovnaké kamery aj ich poradie. Stratilo sa len to, čo žiadny dnešný editor nepozná: 569 GUITexture, 179 GUIText a staré časticové systémy, ktoré Unity odstránilo v roku 2018.

#Krok 4: UnityScript do C# s rovnakým GUID

Unity ukončilo UnityScript postupne od verzie 2017.2, takže ručný port do C# je jediná cesta. Scény odkazujú na skripty cez GUID, jedinečný identifikátor, ktorý Unity ukladá do meta súboru každého assetu, a hodnoty polí ukladajú podľa mena poľa. Ak to pri porte dodržíte, všetky odkazy sa pripoja samy:

pre každý skript X v UnityScripte:
  vytvor C# skript s triedou presne menom X
  skopíruj GUID z meta súboru starého skriptu do meta súboru nového
  verejné polia: rovnaké meno, rovnaký typ, aj s preklepmi
  nič nepremenúvaj, kým projekt nebeží

V Onagerovi sa takto po porte všetkých 126 skriptov pripojilo 12 935 komponentov v 73 scénach a v Inspectore zostali všetky nastavené hodnoty.

Textovým hľadaním v projekte sa nedá zistiť, ktoré skripty sa používajú. Binárny prefab má GUID uložený ako bajty, nie ako text. V Onagerovi tak vyzeralo nepoužívaných dvadsaťjeden skriptov a všetky boli živé. Dajte si pozor aj na pozostatky starších pokusov o port: jeden prefab drevenej kocky ukazoval na dva skripty z takého pokusu a len kvôli nemu chýbalo 1 140 komponentov. Ak treba v binárnom súbore zmeniť GUID, vymeňte ho priamo v bajtoch, šestnásť za šestnásť, aby sa súbor neposunul.

#Krok 5: Obnovte HUD z pôvodných binárnych scén

GUITexture a GUIText v Unity 6 nie sú a s nimi zmizne celý HUD, ktorý na nich stál. Kresliť ho nanovo netreba. Pôvodné binárne scény z histórie gitu binary2text prečíta bez ohľadu na to, či triedy ešte existujú. Vytiahnite z nich každý obrázok a text HUD s textúrou, farbou, pozíciou a zarovnaním a skriptom ich vráťte na rovnaké objekty v scénach. V Onagerovi to bolo 577 obrázkov a 180 textov.

Takto sa zachránia aj texty, ktoré nikde inde nie sú. V Onagerovi to bolo 111 textov: všetky titulky tutoriálov a celá tabuľa s kreditmi. Pri písaní HUD od nuly by ste si ich museli vymyslieť. Pri prenose farby počítajte s jednou vecou, ktorú dokumentácia nehovorí: staré GUITexture farbu pri vykreslení zdvojnásobovalo. Všetkých 577 obrázkov malo farbu presne 0,5, čiže šedá znamenala bielu.

#Po prevode: staré triky nahraďte

Staré projekty často obchádzali obmedzenia vtedajšieho Unity a tieto obchádzky sa po prevode oplatí prerobiť:

• Odraz v podlahe. Onager mal lesklú podlahu bez skutočného odrazu. Pod podlahou stál druhý, zrkadlovo otočený svet: kópia každého objektu, ktorej pozíciu skript každý tretí snímok skopíroval z originálu, v jednom leveli 50 až 70 klonov. Nahradiť sa dá jednou kamerou navyše, ktorá odraz kreslí v polovičnom rozlíšení. Odrážajú sa potom aj častice a trosky, čo klonovaný svet nevedel.
• Mierenie. Ak náhľad dráhy predpovedá, kam strelu pošle sila pridaná v prvom fyzikálnom kroku, strela dopadne inde než značka. Spoľahlivejšie je vypočítať rýchlosť raz, náhľad nakresliť presne z nej a strele ju priradiť priamo.
• Výkon. Merajte na slabom telefóne. Na Motorola G52 klesol Onager z 20 na 6 fps len kvôli shaderu stien, viac než rozlíšenie, tiene a odraz dokopy. Na nízkych a stredných detailoch preto majú steny jednoduchší materiál.

Ak riešite fyziku tisícov objektov v súčasnom Unity, pozrite si aj falošný ragdoll pre tisíce nepriateľov v Unity DOTS. Ako po prevode pridať starej 2D hre glow a 2D svetlá v URP, opisuje samostatný návod.

#Čo postup nevyrieši

Komponenty, ktoré dnešné Unity nepozná, sa nepripoja. GUITexture a GUIText treba obnoviť ako v kroku 5, staré časticové systémy sa stratia. Mená tried a polí ostanú presne ako v pôvodnom projekte, aj s preklepmi a jazykom, v ktorom ich niekto kedysi napísal. Scény sa na ne viažu menom, takže premenovanie má zmysel robiť len cez editor, ktorý odkazy prepíše sám.

Ak máte starý projekt v Unity a potrebujete ho dostať do súčasnej verzie, napíšte nám.

Hordu tisícov nepriateľov v Unity DOTS navigujte jedným flow fieldom pre celú mapu a niekoľkými lacnými lokálnymi pravidlami: odtláčanie od susedov a od stien, cena cesty podľa hustoty davu a stav „čakám“ v zápche. V Unity Editore na MacBooku s M3 Pro to drží okolo 9 600 nepriateľov naraz pri 90 FPS.

Problém vzniká v tower defense, strategických a survival hrách, kde k cieľu ide naraz tisíce jednotiek. Klasické hľadanie cesty pre každú zvlášť je príliš drahé a bez lokálnych pravidiel sa dav prekrýva, lepí na steny a zasekáva v úžinách. Unity DOTS (Data-Oriented Technology Stack, teda Entities, ECS a Job System) dáva výkon na tisíce entít, samotnú navigáciu však nerieši. Postup nižšie používame v našej tower defense hre pre PC (je v referenciách). Obrázky sú zo zjednodušenej 2D simulácie, ktorá beží podľa rovnakých pravidiel, nie zábery z hry.

#Krok 1: Flow field namiesto cesty pre každého

Flow field je mriežka cez celú mapu, v ktorej každá bunka vie, ktorým smerom sa z nej ide k cieľu. Nepriateľ nehľadá cestu, len si prečíta smer z miesta, kde stojí. Cena je rovnaká pre 10 aj 10 000 nepriateľov.

Mapu rozdeľte na bunky po 1 m (náš testovací level má 128 × 128) a pre každý cieľ raz spočítajte vzdialenosť z každej bunky k cieľu. Statické pole stačí spočítať v editore pri príprave levelu a uložiť do assetu.

Najjednoduchšia verzia je Dijkstra cez 8 susedov a v každej bunke jeden z 8 smerov. Funguje, ale nepriatelia chodia po uhlopriečkach a v rade sa lepia na steny.

8 smerov

Plynulé pole

Lepší výsledok dáva plynulé pole. Vzdialenosť spočítajte riešením Eikonalovej rovnice (rovnica šírenia vlny, ktorej riešením je najkratšia vzdialenosť v spojitom priestore, nie len po hranách mriežky) metódou fast sweeping, ktorá mriežku opakovane prechádza zo štyroch rohov. Smer potom nie je smer bunky, ale gradient vzdialenosti v presnom mieste nepriateľa. K cene bunky pripočítajte prirážku za blízkosť steny, takže pole samo drží dav kúsok od prekážok.

#Krok 2: Samostatné pole pre každú veľkosť nepriateľa

Veľký nepriateľ sa nezmestí všade tam, kam malý. Zaveďte veľkostné triedy: každá má vlastnú priechodnosť (bunka musí byť dosť ďaleko od steny) a vlastné pole pre každý cieľ. Triedy držte ako dáta levelu, nie v kóde. U nás sú tri.

#Krok 3: Odtláčanie od susedov

Flow field povie smer, ale o susedoch nevie nič. Základom je zjednodušený model boids (klasické pravidlá kŕdľa): každý nepriateľ sa odpudzuje od susedov v okruhu 0,9 m. Susedov hľadajte v spatial hashi, teda v priestorovej mriežke, kde každá bunka drží zoznam jednotiek v nej. Hash postavte každý tik nanovo a zoraďte, aby bolo poradie deterministické.

Samotné odpudzovanie nestačí. Pri 3 000 nepriateľoch malo 83,7 % z nich najbližšieho suseda bližšie ako 0,8 m a najmenšia vzdialenosť bola 4 cm, teda dvaja nepriatelia skoro v sebe.

Vyššia váha odpudzovania problém nerieši. Pri váhe 6 namiesto 1,5 klesol podiel tesných na 54,6 %, pri 12 na 44,3 %, pri 24 už nič (48,2 %). Dav navyše začne poskakovať, lebo sa sčítajú neobmedzené tlaky od mnohých susedov naraz.

Pomôže pozičná korekcia. Po pohybe rozsuňte každú prekrývajúcu sa dvojicu, každého o polovicu prieniku, a posun za tik obmedzte na 0,15 m. Bez stropu korekcia skáče rovnako ako vysoká váha. So stropom zostane tesných 60,8 %, ale najmenšia vzdialenosť stúpne na 28 cm a dav neposkakuje.

Len odpudzovanie

Korekcia prekrytia

#Krok 4: Odtláčanie od stien

Pri stene korekcia medzi nepriateľmi zlyháva. Pohyb do steny je zakázaný (posun sa rozloží po osiach a zložka do steny sa zahodí), takže pritlačený nepriateľ nemá kam uhnúť a korekcia od suseda sa stratí. Z 938 prekrývajúcich sa nepriateľov malo nenulový tlak od steny len 35.

Pridajte preto odtláčanie od najbližších neprechodných buniek v 4 smeroch aj diagonálne. Dve chyby, ktorým sa dá vyhnúť:

• Vnútorný roh. Tlak od oboch hrán a od rohu sa sčíta a nepriateľa to odhodí. Tlak od rohu pridávajte len pri vonkajšom rohu.
• Skutočné steny. Odtláčajte od skutočných stien, nie od priechodnosti veľkostnej triedy. Pre veľkého nepriateľa je „stena“ už meter pred skutočnou. V ústí chodby tak tlak od rohu vyrovnal pohyb veľkého nepriateľa dopredu a celá skupina za ním zostala stáť.

#Krok 5: Cena podľa hustoty davu a spomalenie

Aj s plynulým poľom ide celý dav po najkratšej ceste tesne okolo rohu, bez ohľadu na to, koľko nepriateľov tam už je. Riešenie ponúka Continuum Crowds (Treuille a kol., 2006): cena bunky rastie s hustotou davu. Raz za 10 tikov spočítajte nepriateľov v bunkách, vyhlaďte to a prepočítajte pole jedného cieľa. Pri preplnenom rohu potom pole pošle nepriateľa okolo, cez voľnejšie bunky.

Bez hustoty

Cena podľa hustoty

Druhá polovica je spomalenie. Nepriateľ v hustej bunke ide pomalšie, najmenej na 15 % rýchlosti. Na 2 250 nepriateľoch išli v riedkych bunkách priemerne na 94 % rýchlosti, v stredne hustých na 71 % a v zápche na 20 %. Nech spomalenie začína skôr: s prahom voľnej hustoty 0,6 nepriateľa na bunku namiesto 1 klesol podiel tesných v úžine na 36,7 %.

Praktická rada: polia, ktoré vznikajú až za behu (napríklad mapa hustoty), alokujte skôr, ako ich prvýkrát použije job. Job s ešte nevytvoreným poľom zhodí Unity Editor natívne, bez výnimky.

#Krok 6: Zápcha v úžine: čakať, nie tlačiť

Keď sa niet kam rozšíriť, ostáva úžina. Najjednoduchší nápad je zahodiť zložku rýchlosti smerom k susedovi, ktorého sa nepriateľ dotýka. Zadní potom stoja namiesto toho, aby uhli, a zápchu udržiavajú.

Uhnúť nabok, napríklad o 35° na stranu s menej susedmi, je lepšie, ale dav sa začne mihotať. Vyhladenie natáčania a nižšia rýchlosť otáčania (180 namiesto 360 °/s) príznak len tlmia. Príčina je inde: pri vyrovnanej hustote si nepriateľ volí stranu každý tik inak. Pomôže hysteréza, teda zvýhodnenie predchádzajúceho rozhodnutia: strana z minulého tiku dostane pri porovnaní zľavu 3 susedov.

Výsledné riešenie spája kontaktné obmedzenie a tri stavy: ide, obchádza, čaká. Zložka rýchlosti do dotýkajúceho sa suseda sa zahodí, bočná ostane. Kto nemá voľnú stranu ani miesto pred sebou, čaká a netlačí.

pre každého nepriateľa, každý tik:
    rýchlosť = smer z flow fieldu × rýchlosť × spomalenie podľa hustoty
    rýchlosť += odpudzovanie od susedov
    ak sa vpredu dotýka suseda:
        ak je voľná strana: obchádzaj (strana s hysterézou)
        inak: čakaj
    zahoď zložku rýchlosti do dotýkajúcich sa susedov
    posuň sa, zložku do steny zahoď
potom pre všetkých:
    rozsuň prekrývajúce sa dvojice (polovica prieniku, najviac 0,15 m)
    odtlač od stien

Na tri veci si dajte pozor:

• Trpezlivosť. Pri opačne idúcej dvojici nech čaká ten s vyšším ID. Reťaz susedov ho však môže blokovať tisíce tikov, preto po limite čakania skúsi núdzovo uhnúť.
• Nulová rýchlosť. Nepriateľ s nulovou želanou rýchlosťou sa zo stavu „čaká“ nikdy nevráti a po vlne ostane stáť na voľnej ploche. Kto sa nechce hýbať, nech je vždy v stave „ide“.
• Úzky kužeľ. Suseda vpredu hľadajte v úzkom kuželi s krátkou sondou. Pri 45° posielalo nastavenie do čakania alebo obchádzania 55 až 60 % davu aj na voľnej ploche, pri 30° a kratšej sonde 41 %.

#Krok 7: Predbiehanie veľkých nepriateľov

Rôzne veľké a rôzne rýchle typy nepriateľov prinášajú ďalšie prípady. Náš veľký pomalý nepriateľ má polomer v dave 1,25 m a ide 1,1 m/s. Rýchly nepriateľ za ním ho nevedel predbehnúť: bočné sondy šikmo vpred boli stále bližšie k veľkému ako súčet polomerov, obe strany vyšli obsadené a rýchly čakal. Oprava: suseda, ktorého nepriateľ obchádza, berie sonda do úvahy len na jeho strane. Sused presne vpredu neblokuje žiadnu.

Veľký nepriateľ naopak odhadzuje malých z cesty do strán, vo výseku ±45° pred sebou. Neodhadzujte tých, čo idú jeho smerom rýchlejšie, ako chce ísť on, inak odhodí aj tých, čo ho práve predbiehajú.

#Krok 8: Sloty pri cieli útoku

Ak nepriatelia útočia zblízka, potrebujú miesto okolo cieľa. Naša veža má 24 slotov po obvode pôdorysu 5 × 5 m, každý nepriateľ zaberá jeden a ostatní čakajú v rade.

• Obchádzanie po kruhu. Ak ponúkate slot len vtedy, keď k nemu vedie priama čiara, zadné sloty ostanú prázdne, lebo spredu čiara k nim pretína vežu. Nepriateľ nech k voľnému slotu obchádza vežu po oblúku.
• Bez vytláčania. Nevytláčajte nepriateľa idúceho k slotu v prospech iného žiadateľa, spúšťa to reťaz vytláčaní.
• Bez odtláčania pri slote. Nepriateľa prichádzajúceho vedľa obsadeného slotu odtláča sused, takže skončí 13 cm od cieľa alebo úplne mimo. Nepriatelia v slote a do 0,5 m od neho sa navzájom neodtláčajú.

#Výkon simulácie a vykresľovania

Benchmark v Unity Editore (M3 Pro, okolo 9 600 jednoduchých nepriateľov, dve úžiny) dal 90 FPS pri 1440p a 100 pri 1080p. Rozlíšenie FPS skoro nemení, zrýchlenie času áno: pri 10× padlo na 20 FPS, lebo na jednu snímku pripadá desať krokov simulácie. Pri normálnej rýchlosti má simulácia rezervu.

S detailným modelom nepriateľa namiesto kapsuly sa úzke hrdlo presunie do vykresľovania:

V simulácii sa oplatia tri veci:

• Dva prechody susedov. Lacný (dotyky, blokovanie) beží vždy, drahý (bočné sondy, hustota strán) len pre zablokovaných, čo je vo voľnom prúde menšina. Vzdialenosti porovnávajte v druhej mocnine, bez odmocniny.
• Jednoduché triedenie. Synchrónne zoradenie spatial hashu trvalo pri 3 000, 10 000, 20 000 a 50 000 záznamoch 0,37, 1,49, 3,16 a 8,46 ms, verzia v jobe 0,18, 0,93, 3,12 a 15,53 ms. Job nie je konzistentne rýchlejší, jednoduché triedenie stačí.
• Hash stavu. Pri ticku 600 a 1800 spočítajte hash pozícií a životov. Refaktor musí dať rovnaký hash, zmena správania ho zmení a viete ju vysvetliť. Funguje to vďaka deterministickému poradiu v spatial hashi.

#Limity riešenia

• Dva plné protismerné davy v jednej úžine sa zaseknú natrvalo. Je to limit modelu bez fyziky.
• Čísla sú z Unity Editora na M3 Pro. Meranie na Steam Decku a v skutočnom builde zatiaľ nemáme, len odhad z verejných benchmarkov procesorov.

Ak chcete skúsiť vlastný dav, dokumentácia Unity Entities je dobrý začiatok. Podobný postup od najjednoduchšieho riešenia k funkčnému nájdete aj v článku o generátore sudoku. Ako nepriateľov v takom dave odhodiť výbuchom bez drahého ragdollu pre každého, opisuje návod ako spraviť fake ragdoll v Unity DOTS. Ak riešite podobnú simuláciu v Unity a chcete pomoc, napíšte nám.

Osemsmerovku s tajničkou vygenerujete tak, že do prázdnej mriežky ukladáte náhodné slová zo slovníka, kým v nej neostane voľných presne toľko políčok, koľko písmen má tajnička. Tie potom vyplníte tajničkou zľava doprava a zhora nadol. Celé to v telefóne trvá pár milisekúnd a nepotrebuje backtracking, teda vracanie sa k skorším rozhodnutiam, keď sa generátor zasekne.

Osemsmerovka je mriežka písmen, v ktorej hráč hľadá a škrtá slová zo zoznamu. Tajnička je text, ktorý sa prečíta zo zvyšných, neprečiarknutých písmen. Generátor preto musí poskladať mriežku, ktorá je úplne plná a v ktorej po vyškrtaní slov ostane presne tajnička. Postup nižšie je ten, ktorým generujeme osemsmerovky v našej aplikácii s krížovkami a osemsmerovkami (App Store, Google Play).

#Pravidlá mriežky

Skôr než začnete, ujasnite si, čo má hotová mriežka spĺňať. V našej aplikácii platí:

• Slová idú v ôsmich smeroch: vodorovne, zvisle a po oboch uhlopriečkach, každým smerom aj pospiatky.
• Dve slová sa môžu prekrývať najviac v jednom písmene.
• Žiadne slovo nesmie prechádzať políčkom tajničky.
• Mriežka musí byť plná. Prázdne políčko je chyba.
• Tajnička sa číta v poradí zľava doprava a zhora nadol zo všetkých neprečiarknutých písmen.

#Krok 1: Pripravte slovník

Slovník rozdeľte raz na začiatku do skupín podľa dĺžky slova. Výber náhodného slova danej dĺžky je potom jeden náhodný index. Ak by ste pri každom slove filtrovali celý slovník, generovanie sa citeľne spomalí, lebo slov sa do jednej mriežky skúša stovky.

Náš slovenský slovník má 16 713 slov s dĺžkou od 3 do 21 písmen, najviac je sedem- a osempísmenových. Pár praktických rád:

• Nechajte v slovníku aj vlastné mená a skratky. V mriežke sa potom objaví napríklad HOUSTON alebo MAINE. Bez krátkych a „divných“ slov sa mriežka nedá dostatočne zahustiť.
• Vulgarizmy filtrujte samostatným zoznamom, ktorý sa dá vypnúť, ak hráč chce obsah pre dospelých.
• Pri viacerých jazykoch načítajte len ten, v ktorom sa hrá. Anglický slovník má vyše 414 000 slov. Načítanie všetkých štyroch jazykov naraz pri štarte aplikácie zamrazí slabší telefón aj na 11 sekúnd.

#Krok 2: Vyberte tajničku

Tajnička by mala mať aspoň toľko písmen, koľko je strana mriežky, a najviac o štyri viac. Kratšia v mriežke zanikne, dlhšia vyžaduje príliš veľa dier.

V našej aplikácii je tajnička pointa vtipu. Hráč škrtá slová a zo zvyšných písmen si prečíta, ako vtip končí. Tajničku skladáme z konca vtipu: odzadu pridávame celé slová, kým nespadne do uvedeného rozsahu.

Obrázky nižšie používajú anglický vtip „Two snakes walk into a bar. Turns out they were lizards.“ (Dva hady vojdú do baru. Ukáže sa, že to boli jaštery.) a mriežku 10×10. Tajnička je WERELIZARDS, teda 11 písmen. Slová v obrázkoch sú z anglického slovníka zúženého na bežné slová, aby sa dali čítať.

#Prečo nezačínať tajničkou

Prvý nápad je robiť to, čo by človek robil ceruzkou: najprv rozhodiť písmená tajničky na náhodné políčka v poradí čítania a potom okolo nich skladať slová.

Vyzerá to rozumne, kým nepríde koniec. Generátor si vyberie prázdne políčko, skúsi cezeň dostať slovo vo všetkých smeroch a posunoch, a keď mriežka zhustne, ostanú izolované diery. Jedna diera medzi dvoma písmenami tajničky sa nedá zaplniť ničím, lebo najkratšie slovo má tri písmená a cez tajničku slovo ísť nesmie.

Na vzorke 200 mriežok 10×10 tento prístup skončil s plnou mriežkou len v 28 % prípadov, priemerne ostali 1 až 2 diery. Opravovať ich dodatočne je zložité. Tajničku preto do mriežky nedávajte, kým nie sú hotové slová.

#Krok 3: Plňte mriežku, kým neostane presne N dier

Plnenie je jednoduchý greedy algorithm: každé slovo sa položí hneď, ako sa zmestí, a už sa neodoberá. Generátor si pamätá iba jedno číslo: koľko políčok je ešte prázdnych. Slovo položí len vtedy, ak by po ňom neostalo menej prázdnych políčok, než má tajnička písmen (N).

prázdne = riadky × stĺpce
kým prázdne > N a pokusov < 2000:
    slovo = náhodné slovo zvolenej dĺžky
    opakuj najviac 50-krát:
        začiatok = náhodné políčko, smer = náhodný z 8
        ak sa slovo zmestí podľa pravidiel mriežky:
            nové = počet prázdnych políčok, ktoré slovo zaplní
            ak prázdne - nové >= N:
                polož slovo
                prázdne = prázdne - nové
                pokračuj ďalším slovom
ak prázdne != N: mriežku zahoď a začni odznova

Prvé slová padnú do prázdnej mriežky voľne:

Postupne slová začínajú zdieľať písmená. To je vítané, lebo každé zdieľané písmeno je jedno políčko, ktoré netreba zapĺňať:

Keď počet prázdnych políčok klesne na N, plnenie končí. Kde tie diery sú, je jedno. Môžu byť roztrúsené kdekoľvek, lebo tajnička sa nimi nemusí dať nijako prejsť:

#Krok 4: Losujte dĺžku slova s rozumom

Dlhé slová robia osemsmerovku zaujímavou, krátke ju dokážu dokončiť. Dĺžku preto losujte z dvoch normálnych rozdelení (normálne rozdelené náhodné čísla dostanete napríklad Box-Mullerovou transformáciou):

Dĺžka je vždy aspoň 3 a nanajvýš strana mriežky. K tomu dve pravidlá, bez ktorých sa generátor na konci zasekáva:

• Na konci vynúťte presnú dĺžku. Keď do cieľa chýba 5 a menej políčok, hľadajte slovo presne takej dĺžky, aká chýba (najmenej 3). Inak sa bude generátor donekonečna pokúšať o šesťpísmenové slová, ktoré sa už nezmestia.
• Trojpísmenové slová dávajte na prídel. Prvé tri pokusy o mriežku nesmú obsahovať ani jedno, pokusy 4 až 6 jedno, ďalšie tri dve a tak ďalej. Trojpísmenové slová sú v slovníku často skratky typu DNA alebo CPU a v osemsmerovke pôsobia lacno. Povoľte ich, až keď to inak nejde.

#Krok 5: Vlejte tajničku do dier

Prejdite mriežku zľava doprava a zhora nadol a do každého prázdneho políčka zapíšte ďalšie písmeno tajničky. Keďže dier je presne N, tajnička sa zmestí bezo zvyšku.

Hráč vidí len toto:

#Keď sa mriežka nepodarí

Ak generátor ani po 2 000 pokusoch nedosiahne presne N prázdnych políčok, celú mriežku zahoďte a začnite znova, najviac 100-krát. Žiadne opravovanie dier. Je to hrubé, ale pri mriežkach do 12×12 to stačí s rezervou. Väčšie mriežky potrebujú viac pokusov, ako ukazuje tabuľka nižšie.

#Úspešnosť a rýchlosť podľa veľkosti mriežky

Generátor bežal na 300 mriežkach pre každú veľkosť, so skutočnými vtipmi a slovenským slovníkom (Node.js 22 na serverovom procesore, telefón bude pomalší; obrázky v článku sú z anglického slovníka, čísla zo slovenského, lebo je menší a teda prísnejší test). „Na prvý pokus“ znamená, že prvé kolo plnenia skončilo plnou mriežkou.

Čo z toho vyplýva pre vlastný generátor:

• Priemerné slovo má 4,7 písmena, hoci cieľ je okolo 6. Dlhé slová sa do zahustenej mriežky jednoducho častejšie nezmestia.
• Asi 9 až 10 % políčok zdieľajú dve slová. Netreba to nastavovať, vyplýva to z pravidla „najviac jedno spoločné písmeno“.
• Uhlopriečok bude menej, než čakáte. Smer sa losuje rovnomerne z ôsmich, takže by mali tvoriť polovicu slov. V malej mriežke však uhlopriečne slovo oveľa častejšie vypadne za okraj. Na 8×8 tvoria uhlopriečky 24 % slov, na 15×15 už 33 %. Ak chcete viac uhlopriečok, dajte im pri losovaní smeru vyššiu váhu.

#Tip: rovnaká mriežka pri každom spustení

Na screenshoty do obchodov potrebujete, aby sa vygenerovala vždy tá istá mriežka. Namiesto bežného generátora náhodných čísel použite v takom režime jednoduchý lineárny kongruenčný generátor s pevným seedom (napríklad odvodeným z jazyka). Ak držíte všetku aritmetiku v rozsahu, ktorý desatinné čísla v JavaScripte reprezentujú presne, výsledok je rovnaký na každom zariadení. Rovnakým trikom sú vygenerované aj obrázky v tomto článku.

Ak riešite podobný problém, generujete hlavolamy alebo potrebujete mobilnú aplikáciu, napíšte nám. Krátke ukážky z vývoja dávame aj na YouTube. Podobne krok za krokom je opísané aj to, ako vygenerovať sudoku s jediným riešením. Ak potrebujete krížovku namiesto osemsmerovky, pozrite si, ako vygenerovať švédsku krížovku s tajničkou.