A több ezer animált karakter LOD-ját Unityben a csúcsok száma alapján építse fel, ne a háromszögek szerint: vertex animation textures esetén az animációt csúcsonként kell kiszámítani. Az alsóbb szinteket készítse el kézzel, a legalsó szint csúcsait kösse az eredeti felületéhez, a szintet pedig karakterenként válassza ki. PC-s tower defense játékunkban ez 3 000 ellenfélnél a tömegbe közelítve 62-ről 120-ra emelte az FPS-t.

Az eljárás azokra a játékokra vonatkozik, ahol egyszerre több ezer karakter mozog a képernyőn: tower defense, stratégiai és survival játékokra. A miénk Unityben, ECS-sel készül, és a referenciák között található. A LOD a level of detail rövidítése: a távoli karaktert egyszerűbb hálóból rajzoljuk. A képek csontváz ellenfelünk valódi hálóit mutatják, nem játékbeli felvételek.

#Miért nem segít a generált LOD egy tömegnél

A Unity a modell importálásakor képes LOD szinteket generálni (a Mesh LOD funkció). Több ezer karakternél ennek két gondja van.

Az első a kinézet. Az automatikus egyszerűsítés felszakította a vékony végtagokat és elrontotta az UV-t, vagyis a textúra leképezését a hálóra.

A második az animáció ára. A hagyományos csontvázas animáció több ezer entitásnál túl drága, ezért vertex animation textures (VAT) kerül a helyére. A VAT olyan textúra, amelyben minden oszlop egy csúcshoz, minden sor egy animációs képkockához tartozik. A shader a textúrából olvassa ki a csúcs helyzetét, így az animáció ára a kiolvasott csúcsok számától függ, az árnyékok rajzolásakor is.

A plafont egy teszt mutatja, ahol minden karakterre egy generált szintet kényszerítettünk (a Unity a 3. és 4. szintet is előállítja, build, 1080p, 3 000 ellenfél, bekapcsolt árnyékok):

A gyorsításra bőven van tér. Ezt látható lyukak és a szintek közti ugrások nélkül kell kihasználni.

#A csúcsokat számolja, ne a háromszögeket

A fele annyi háromszög önmagában nem segít. Egy LOD fele annyi háromszöggel és az eredeti 1 521 csúcsból 996-tal 1,9 ms-ot takarított meg képkockánként, egy 217 csúcsos LOD 6,4 ms-ot. Minden szintnél kövesse mindkét számot.

Gyakran fölöslegesen sok a csúcs. Minden UV-varratnál megkettőződik a csúcs, mert egy pozícióhoz ilyenkor két textúrakoordináta tartozik. Az AI-generátorból származó modelljeink UV-ja több száz szigetre volt vágva: a csontváznak 1 521 csúcsa volt, de csak 608 különböző pozíció-normál párosa.

#1. lépés: Csökkentse a csúcsokat a LOD 0-ban

Az első megtakarítás nem jár részletvesztéssel. Egyesítse az azonos pozíciójú és hasonló normálú csúcsokat (25° eltérésig), bontsa ki újra az UV-t csak az éles éleken (70° felett) varrattal, és a textúrát számolja át a régiből háromszögenként. A csontváz 1 521-ről 1 090 csúcsra csökkent, a többi ellenféltípus 19-29 %-kal, változatlan alakkal.

Ezután csak azoknak a csúcsoknak az oszlopait írja a VAT-ba, amelyeket valamelyik szint ténylegesen használ. Ez az animációs memória 40-60 %-át spórolta meg.

#2. lépés: LOD 1 egyszerűsítéssel, közös textúrával

A LOD 1 a háromszögek körülbelül 52 %-ára egyszerűsített LOD 0. Darabonként egyszerűsítsen (a csont és a háló összefüggő részének minden párosítása), és rögzítse a darabok határán lévő csúcsokat. A fejnek adjon nagyobb keretet, mert a fej sziluettjét ismeri fel a szem a tömegben.

Fontos megtartani a LOD 0 textúráját. Az önálló textúrájú vagy más alakú szint átmenetkor hasonló sziluett mellett is látszik.

A háromszögek nagyjából 50 %-a alatt a meglévő csúcsokból való egyszerűsítés felszakítja a vékony részeket és a különálló darabokat. Lejjebb másképp kell haladni.

#3. lépés: LOD 2 az eredetihez kötött új hálóként

A legalsó szint új, zárt háló. Vastagítsa meg az eredetit egy réteggel, futtasson voxel remesht, és egyszerűsítsen a célszámra (nálunk ellenféltípustól függően 200-460 háromszög). Az eredményt húzza rá az eredeti felületére, az UV-t pedig készítse automatikusan. A textúrát az eredetiből süsse a LOD 0-val azonos sűrűségben, hogy a mipmapek is egyezzenek.

Az új hálónak nincsenek animációs súlyai. Ezért minden csúcsát kösse az eredeti legközelebbi háromszögéhez. Mentse el a háromszög három oszlopát és a baricentrikus súlyokat (az arányokat, amelyek meghatározzák a pont helyét a háromszögön belül).

A kötött csúcs VAT-oszlopa minden képkockában a három csúcs pozíciójának és normáljának súlyozott összege. A shadernek semmi különöset nem kell tennie, a kötött csúcs csak egy újabb oszlop.

minden f képkockára:
    VAT[kötött, f] = w0 * VAT[a, f] + w1 * VAT[b, f] + w2 * VAT[c, f]

#4. lépés: Géppel ellenőrizze a lyukakat

A modellező eszköz képei nem mutatják megbízhatóan a lyukakat. Elég egy egyszerű ellenőrzés: renderelje az eredetit és a jelöltet 11 irányból 120 px-es felbontásban, és hasonlítsa össze a sziluetteket.

Lyuknak számítsanak az eredeti pixelei a jelölt körvonalán belül, amelyeket a jelölt nem fed le, valamint a jelölt pixelei az eredeti körvonalán több mint 2 px-lel kívül. Nálunk a határ 1 % lyuk és 4-6 % veszteség. Az ellenőrzésnek figyelembe kell vennie az anyagtól függő hátlap-eltávolítást. A határokat az alapján állítottuk be, hogy hol látszottak az átmenetek a játékban.

#5. lépés: Karakterenként válasszon szintet

Ha az egész térképen egyszerre vált a szint, az látszik. Entitásonkénti kiválasztásnál az átmenetek eloszlanak és eltűnnek a tömegben.

Egész térkép egyszerre

Entitásonként

Verziófigyelmeztetés: a Unity 6.2 dokumentációja szerint az Entities Graphics mindig LOD 0-t használ. Az alábbi képlet szerinti entitásonkénti kiválasztást Unity 6.6-ban használjuk, ezért előbb ellenőrizze a saját verziója viselkedését:

LOD = log2(d * C / D) * meredekseg + eltolas
C = kuszob * 2 * tan(fov / 2) / kepmagassag

Itt d a kamerától mért távolság, D pedig az entitás világbeli határainak átmérője. A meredekséget és az eltolást úgy válassza meg, hogy az 1. szint 93,3, a 2. szint 167,9 méternél kezdődjön (30°-os fov és 1440 px-es kamera). A globális LOD-küszöböt állítsa képmagasság / 1440 értékre, így a távolságok nem függenek a felbontástól.

Két hiba, amelyre figyeljen:

• Méretarány. A D átmérőt a világbeli határokból számolja, tehát a prefab méretarányával együtt. A VAT-hálók gyakran kis egységekben vannak, a prefab 2-4-szeresére nagyítja őket. Enélkül a játék végig LOD 0-t rajzol, és nem jelez semmit. Ellenőrizze a háromszögek számával normál módban egy kényszerített LOD-hoz képest. Az entitás elforgatása megnöveli a tengelyhez igazított határokat, ezért nálunk az átmérőt 1,22-es szorzóval számoljuk.
• Sütés. A kiválasztási görbe a SubScene sütésekor kerül rögzítésre, és a sütés nem veszi észre a háló változását. Módosítás után kényszerítse ki a SubScene újrasütését.

#Eredmények és korlátok

macOS build, 2560 × 1440, 3 000 ellenfél, bekapcsolt árnyékok, a játék game over után megállítva (a VAT-animációk továbbra is futnak, így a mérés a grafikára érvényes):

A Steam Decken (1280 × 800, 8 RDNA 2 számítási egység) ez 75-80 FPS a teljes térképen. A tömeghez legközelebbi nézet magas árnyékminőséggel 33 FPS, árnyékok nélkül 64. Az árnyékok jelentik tehát a legnagyobb megmaradt költséget: a LOD ezek árát is csökkenti, de a kikapcsolásuk még mindig nagy ugrást ad.

Amit a LOD nem old meg: a lyukellenőrzés T-pózban fut, így nem veszi észre az extrém pózokban fellépő nyúlást. Egy ellenféltípus LOD 2-ben még túllépi a lyukhatárt. A horda mozgásának számítására a LOD nincs hatással, erről a horda navigációja Unity DOTS-ban cikk szól, a robbanásokra adott reakciókról pedig a fake ragdoll.

Segítségre van szüksége Unity-játéka teljesítményével vagy tömegszimulációval kapcsolatban? Írjon nekünk.

Egy régi 2D Unity-játék a beépített render pipeline-on laposnak hat egy mai telefonon: nincs fény, a glow vagy hiányzik, vagy a teljes képet bevilágítja a UI-jal együtt, a felület sprite-jai pedig elmosódottak. Unity URP-ben ezt három dologgal oldja meg: 1-es küszöbű Bloommal és HDR színnel csak azokon az objektumokon, amelyeknek világítaniuk kell, a 2D renderer 2D fényeivel, valamint nagyobb sprite-okból álló UI-jal, amely figyelembe veszi a kijelző biztonságos területét.

A folyamatot a Dreamica nevű játékunkon mutatjuk be (App Store, Google Play). Ez egy zuhanós kalandjáték, amelyben ujjal vonalakat rajzol, és ezekkel vezet egy alvó gyereket szállító buborékot négy világon át. Eredetileg Unity 5.3-ban készült, a UI az NGUI pluginban futott, a glow-t az MK Glow plugin adta, a grafika pedig az iPhone 7 1334 × 750 pixeles kijelzőjére készült. A játékmenet ugyanaz maradt, csak a grafika változott.

Egy régi játékot gyakran az áruház miatt kell újra elővenni, nem a grafika miatt. A Google Play 2019 augusztusa óta 64 bites verziókat követel meg, és a csak 32 bites builddel rendelkező játék kikerül belőle. Pontosan ez történt a Dreamicával is. Ha a projektet úgyis átviszi Unity 6-ra, a grafika viszonylag olcsó bónusz.

#Miért nem elég a régi teljes képernyős glow

A régebbi glow pluginok teljes képernyős effektként működnek. Mindent bevilágítanak, ami világos, a menü ikonos gombjait is. A Dreamicában az MK Glow alatt Unity 6-ban az ikonok szinte eltűntek. A hivatalos Post Processing Stack v2 csak a beépített pipeline-hoz nyújt pótlást, URP-ben már nem érvényesül. Ha anyagonként vezérelhető glow-t és mellé dinamikus 2D fényeket szeretne, váltson URP-re, és használja a beépített Bloomot.

#1. lépés: Állítsa át a projektet URP-re

Az URP-re váltás után egy régi 2D játék szinte biztosan két csapdába fut bele. Mindkettő úgy jelentkezik, hogy a kép hibás, vagy pontosan olyan, mint korábban, pedig a shaderek rendben vannak.

#Szürke kép: állítson be camera stacket

Ha az Editor Game nézete csak szürke felületet mutat, de a Scene nézet és egy egyszeri kamerarender rendben van, a hiba nem a shaderekben, hanem a kamerák összerakásában van. A régi játékoknak gyakran két kamerájuk van, egy a világnak és egy a UI-nak, és a UI-kamera csak a mélységet törli. A beépített pipeline-ban így rétegezik a kamerákat, az URP viszont ezt nem támogatja. Explicit camera stack kell neki: az egyik kamera az alap (Base), a többi a stackjébe sorolt rátét (Overlay). Állítsa be minden jelenetben, ahol a kamerák egymásra kerülnek.

#A sprite-ok figyelmen kívül hagyják a fényt: váltson 2D rendererre

A megvilágított shaderes sprite-ok semmilyen fényre nem reagálnak, ha a hagyományos URP renderer aktív. Az a 2D fényeket egyáltalán nem számolja. Váltson a 2D rendererre. Ám ez sem rajzol megvilágítást, amíg a jelenetben nincs legalább egy 2D fény. Ha valami egy változtatás után pontosan ugyanúgy néz ki, mint előtte, először ellenőrizze, melyik renderer fut.

#Részecskék és régi pluginok

A régi shaderes részecskék a 2D renderer alatt feketén vagy egyáltalán nem jelennek meg. Adjon nekik új, egyszerű shadert.

Vigyázzon az Asset Store-ral is. Az assetek frissítésekor az Editor magától alkalmazhatja egy régi plugin „frissítését”, amely metaadatokat ad hozzá és átnevezi a shadereket. Az anyagok név szerint keresik a shaderüket, így csendben elromlanak. Egy régi projektben minden nagyobb assetfrissítés után nézze át a verziókezelőben az összes módosított fájlt, azokat is, amelyeken épp nem dolgozik.

#2. lépés: Szelektív glow HDR színnel és 1-es Bloom-küszöbbel

A cél az, hogy csak a kiválasztott objektumok világítsanak, a Dreamicában a megrajzolt vonal, a lézerek, a szikrák, a szentjánosbogarak és a rúnák, a háttér és a UI viszont ne. Az URP Bloom elmos és hozzáad mindent, ami világosabb a küszöbénél. Állítsa a küszöböt 1-re, és a világítani hivatott anyagok színét emelje 1 fölé.

vonal shadere:
    szín = textúra × csúcsszín × árnyalat × intenzitás    (intenzitás = 6)

Bloom:
    küszöb = 1, erősség = 0,3
    csak az világít, aminek a számítás után 1 fölötti a fényereje

A háttér és a gombok színe 0 és 1 között van, nem lépik át a küszöböt, és élesek maradnak. Ezzel a kifakult ikonok problémája is megszűnik. Feltétel a HDR-rel rendelkező kamera. Enélkül a szín 1-re vágódik, és semmi sem világít. A 2D renderer nem mutatja a HDR kapcsolót a kamera inspectorában, ezért kapcsolja be szkriptből.

Alacsony küszöb, teljes kép

1-es küszöb, HDR anyag

Ha a glow így kézben van, nem kell opcionálisnak lennie. A Dreamicában megszüntettük a glow kapcsolóját a beállításokban, a glow a megjelenés része.

#Emissziós térkép: a sprite-nak csak egy része világít

Ha a sprite-nak csak egy része világítson, adjon neki emissziós térképet (emission map): egy második, fekete-fehér textúrát, amely megjelöli, a sprite melyik része világít. Csak ez a rész kap 1 fölötti színt, így a rúnán a mag ragyog, nem a teljes körvonal.

#Lüktetés expozíciós lépcsőkben

Ha a ragyogás lüktessen, ne szorozza a színt lineárisan. Egy HDR anyag fényereje 2 a nyolcadikon körül lehet, és rajta egy 0 és 10 közötti lineáris szorzó egyáltalán nem látszik. A lüktetést expozíciós lépcsőkben (EV) számolja, ugyanúgy, mint a Unity HDR színválasztójának intenzitáscsúszkája:

szín = árnyalat × 2 ^ ev,   ev egy minimum és egy maximum között ingadozik

#3. lépés: Dinamikus 2D fény a játékos körül

Tegyen a játékosra egy 2D pontfényt, köré pedig lágy ragyogást. A Dreamicában egyetlen szinuszgörbe vezérli egyszerre a ragyogás fényerejét, a fény sugarát és intenzitását, így együtt lüktetnek. A fény színét a környezet is meghatározhatja: az erdőben fehér, a mocsárban narancssárga, télen lila, a pokolban sárga. A hátteret és az akadályokat állítsa megvilágított shaderekre, különben nem reagálnak a fényre.

A rövid fények életet visznek az eseményekbe. Amikor az ágyús mókus lő, felvillan egy 3-as intenzitású borostyánszínű fény, amely 0,3 másodperc alatt kialszik, és a csőből kiáramló szikrák világítanak. Nem kell mindennek világítania: a makk eltűnésekor keletkező por szándékosan barna, és nem világít.

#Ugyanaz a shader az egymáshoz illeszkedő felületeken

Ha két háttér illeszkedik egymáshoz, a forrásképek fényereje azonos, mégis látható köztük a varrat, ellenőrizze a shadereket. A Dreamicában a kezdő háttérnek és a végtelen erdei háttérnek más-más shadere volt. Az egyik figyelmen kívül hagyta az anyag 0,733-as árnyalatát, a másik alkalmazta, és 73 %-ra sötétítette az erdőt. A megoldás ugyanaz a shader mindkét felületen.

Két shader

Egy shader

#Felvillanás: áttűnés a csúcsra hozzáadás helyett

A következő világba lépéskor a fény és a ragyogás fellobban: 0,6 másodperc felfutás, rövid kitartás, 1,4 másodperc lecsengés, közben a ragyogás egyszer körbefordul. Ha a felvillanást egyszerűen hozzáadja a lüktetéshez, a csúcs attól függ, épp melyik fázisban van a szinuszgörbe, és minden felvillanás más erősségű. Ehelyett tűnjön át folyamatosan a lüktetésből egy rögzített csúcsra:

súly = felvillanási görbe (0-tól 1-ig)
érték = lüktetés + (csúcs - lüktetés) × súly

Hozzáadás

Áttűnés a csúcsra

#4. lépés: Éles UI a mai kijelzőkre

Az iPhone 7-re rajzolt UI sprite-jai kicsik. A Dreamica menügombjának sprite-ja 128 × 64 pixeles volt, és háromszoros pixelsűrűségű telefonon többszörösére nyúlt. Rajzolja újra a sprite-okat nagyobb felbontásban: az új gomb 800 × 434-es, a haladásjelzők 200 × 26-ról 800 × 104-re nőttek.

128 × 64

800 × 434

Ha a UI NGUI-ra épül, fontolja meg az újraírást. Az NGUI horgonyai darabonként, több képkockán át számolódnak ki, a hosszú horgonyláncok néha rossz helyen állnak be, a méretarány pedig eltér az Editor, a telefon és az iPad között. A Dreamicában a javítások ezt nem tették megbízhatóvá, ezért a UI-t újraírtuk uGUI-ra és TextMeshPro-ra. Haladjon képernyőről képernyőre, a régi verziót pedig tartsa mellette futva mintaként. A UI-t a magasság szerint skálázza egy referenciafelbontáshoz képest (nálunk 434 × 941 pont), és vegye figyelembe a kijelző biztonságos területét, vagyis a kivágást és a lekerekített sarkokat. Az újraírás után távolítsa el teljesen az NGUI-t a projektből, hogy ne maradjon benne két UI-rendszer.

#Korlátok: tömörítetlen textúrák

Ez a folyamat csak a grafikát változtatja meg. A Dreamicában szándékosan nem tömörítettük a textúrákat, mert teljes élességet akartunk. Az ára a méret: már az eredeti játéknak is 313 MB textúrája volt a memóriában az Editorban, az App Store-ban pedig 299 MB. Becslésünk szerint a tömörítés nagyjából 40 MB-ra csökkentené a textúrákat. Ha fontos a játék mérete, itt spóroljon először.

Egy másik Unity-játékot az első kódsortól a kiadásig a Space Impact Watch cikkünk mutat be, a Unity teljesítményéről pedig a horda-navigáció Unity DOTS-ban cikk szól. Ha a játék még Unity 4-ben készült, ne nyissa meg közvetlenül Unity 6-ban; a biztonságos utat az írja le, hogyan vigyen át egy Unity 4-es projektet Unity 6-ra. Ha van egy régi Unity-játéka, amely kikerült az áruházakból, és szeretné visszahozni, vegye fel velünk a kapcsolatot.

Ha egy robbanás a játékban egyszerre több száz ellenfelet repít el, mindegyiküknek igazi ragdollt adni túl drága. Fake ragdollt Unity DOTS-ban úgy készít, hogy az ellenfél teljes testét egyetlen pontként szimulálja saját egyszerű fizikával, a modellt pedig csak a test középpontja körül forgatja. Az esés és a felállás közönséges animációs klipek, csontokat egyáltalán nem szimulálunk.

A módszert egy PC-s tower defense játékon mutatjuk be, amelyet Unityben, ECS-sel fejlesztünk (bővebben a referenciáink között). Egy bomba vagy fireball ott egyszerre több tucat, akár több száz ellenfelet repít el. Ha 2000 test van a levegőben, a szimuláció tickenként 0,53-0,59 ms-ba kerül (a tick a játékszimuláció egy rögzített hosszúságú lépése).

#Miért nem igazi ragdoll

Egy igazi ragdoll karakterenként tíz vagy több, ízületekkel összekötött fizikai test. Több ezer karakternél a képernyőn ez nem reális.

A másik ok a determinizmus: ugyanabból az állapotból ugyanannak az eredménynek kell kijönnie. A mi játékunkban erre épül egy elvesztett hullám újrajátszása egy mentési pontból, és ezt a szimuláció állapotának hashével ellenőrizzük 1800 tick után.

#A test mint egyetlen pont

Fizikai motor helyett használjon saját, egyszerű 2,5D fizikát: pozíció a rácson, magasság a talaj felett, ballisztikus repülés, visszapattanás a falakról és súrlódás. A mi játékunkban a bomba is így mozog, és a robbanás által eltalált ellenfél egy pillanatra ugyanolyan testté válik. Az ötletet az adta, ahogyan a katonák repülnek a Diplomacy is Not an Option című játékban.

A szimuláció csak a pozíciót, a magasságot és az elforgatás szögét ismeri. A modell forgatását ne írja bele. Az az entitás kiegészítő transzformációs mátrixába tartozik, amelyet az Entities csomag (ECS a Unityben) a nem egyenletes skálázáshoz támogat (dokumentáció).

#A ledöntött ellenfél fázisai

A ledöntött ellenfél három fázison megy át, aztán visszatér a tömegbe:

találatkor:
    számold ki a kilövési sebességet (erő, távolság a robbanástól, véletlen a seedből)
    keress landolást járható cellán (lásd lent)
    kapcsold be a "ledöntve" állapotot, szabadítsd fel a helyét a támadás célpontjánál
repülés:   a test parabolán repül, a modell a test középpontja körül forog
landolás:  testhelyzet a szögből (hát vagy has), rövid ráborulás
fekvés:    rögzített számú ticket vár
felállás:  felállási klip hátról vagy hasról, aztán vissza a tömegbe

A „ledöntve” állapotot olyan komponensként készítse el, amely ki- és bekapcsolható anélkül, hogy az entitást chunkok között kellene mozgatni (a chunk az a memóriablokk, amelyben az ECS az azonos komponenskészletű entitásokat tárolja). A navigáció, a tömegben való taszítás és a támadási döntés így a ledöntötteket egyszerűen kihagyja. Hogy hogyan működik a navigáció és a taszítás nagy tömegben, azt a horda navigációjáról szóló cikk Unity DOTS-ban írja le.

#Kilövés: magasabbra, nem messzebbre

A legegyszerűbb kilövés 45° ± 10° szögben történik. 18 m/s bombaerőnél és 20 m/s² gravitációnál a repülés csúcspontja körülbelül 4 m. A test alacsonyan repül el a tömeg felett, és a hatás elvész benne.

Nagyobb erő nem segít, mert vele együtt nő a távolság is. Bontsa a sebességet két összetevőre, és mindegyiket külön szorozza: 60° ± 5° szög, vízszintes összetevő × 0,85, függőleges × 1,3. A csúcspont így körülbelül 10 m, a távolság marad nagyjából 15,5 m, a repülés pedig körülbelül 2 másodpercig tart.

Az irány ± 15°-kal tér el a robbanástól, az erő ± 20%-kal, a robbanás szélén pedig a felére csökken. A véletlent ne globális generátorból vegye, hanem a pálya seedjének, az ellenfél azonosítójának és a robbanás sorszámának hashéből. A ledöntési kéréseket rendezve dolgozza fel, mert a több szálon futó jobok tetszőleges sorrendben hozzák létre őket. Ugyanannak a hullámnak két futása így ugyanazokat az íveket adja.

A ledöntés igen vagy nem. Minden ledönthető ellenfél találatkor legalább elesik (a sebesség alulról 2 m/s-ra korlátozott), az ellenállás csak a távolságot változtatja. Az immunitást külön jelzővel adja meg, a mi játékunkban a legnagyobb ellenféltípusnak van ilyen. Ha az immunitás az ellenállásból következne (0,95-nél a sebesség 2 m/s alá esik), és a gyenge elhajítás törlődne, az ellenfél csak véletlenül lenne immunis.

#Landolás járható cellán

Az ellenfél nem landolhat szakadékban, sziklán vagy egy torony alapterületén. A járhatóságot rácscellánként és minden ellenfél-méretosztályra külön határozzuk meg.

#A levegőben falakról visszapattanás nem elég

Kézenfekvő ötlet a nem járható cellákat falként kezelni, amelyekről a repülő test visszapattan. Sziklánál ez természetesnek tűnik, szakadéknál nem: a szakadék felett levegő van, de a cella nem járható, így a test egy láthatatlan oszlopról pattan vissza a széle felett. Ráadásul semmi sem garantálja, hogy a visszapattanás után jó helyen ér földet.

#Pályaelőrejelzés a kilövéskor

Megbízhatóbb a landolást már a kilövéskor meghatározni. Szimulálja le előre a repülést ugyanazzal a lépéssel, mint a valódi fizikát, és ellenőrizze a landolási cellát az ellenfél méretosztályára. Ha nem járható, próbáljon további változatokat rögzített sorrendben:

a szögekre [0, +25, -25, +50, -50, ... , +175, -175]:
    a vízszintes sebesség szorzóira [1, 0.7, 0.4, 0.1]:
        szimuláld a repülést
        ha a landolási cella járható az ellenfél osztályának: használd ezt az irányt, és vége
ha semmi sem jött be: vízszintes sebesség = 0 (helyben ugrás)

A legrosszabb eset 60 repülésszimuláció ellenfelenként (15 irány × 4 szorzó). A függőleges sebesség nem változik, így a repülés magassága ugyanaz marad, csak a távolság rövidül. Ha repülés közben újabb robbanás éri az ellenfelet, futtassa újra az előrejelzést.

Hogy a test landolás után ne csússzon és ne pattanjon, adjon neki 0 talajvisszapattanási együtthatót és nagy súrlódást. Ott marad, ahol az előrejelzés mondta.

#A repülési magasságból tervezett forgás

A legegyszerűbb a modellt véletlen sebességgel forgatni, például 180-540 °/s-mal, és landolás után 0,2 s alatt a legközelebbi fekvő helyzetbe billenteni. A billentés azonban látszik, ha a test szinte függőlegesen ér földet. Ha a forgási sebességet minden tickben úgy igazítja, hogy a szög landoláskor pontosan vízszintes legyen, az csak részben segít: még egy alacsony dobás is szaltóként pörög, és a forgásnak semmi köze ahhoz, milyen magasan repül a test.

Jobb a forgást a kilövéskor a repülési magasságból megtervezni:

magasság = vz² / (2 g), repülési idő vz-ből és a magasságból
cél = legközelebbi vízszintes helyzet véletlen irányban (negyed fordulat állásból)
cél += fél fordulat minden 2,5 m magasságért, legfeljebb 3
forgási sebesség = (cél - aktuális szög) / repülési idő

A landolás oldala a szögből következik: arccal a föld felé has, egyébként hát. Ez alapján választódik ki a felállási klip. A fekvő vagy felálló ellenfél újabb találatkor megtartja aktuális szögét, és nem ugrik vissza függőleges helyzetbe.

#A modell a talajra helyezése

A modell a test középpontja körül forog, a talaj viszont a legalsó pontja alatt van, és ez a forgással változik. Az eltolás becslése két konstansból és a szög szinuszából nem illik azokhoz a modellekhez, amelyek az esési klipben szélesre tárják a karjukat: a mi játékunkban a csontváz modellje (gyakori ellenfél) akár 1,15 m-re, a nekromantáé akár 1,73 m-re süllyedt a föld alá.

Becslés

Mért

Megbízhatóbb a legalsó pontot megmérni. Az animációk sütésekor (bake) számolja ki az esési klipre a test legalsó pontját 72 elforgatásnál 5°-os lépésekben, futás közben pedig interpoláljon a táblázatból. A legmélyebb süllyedés így 4 mm-re csökken. Egyetlen minimum a klip összes képkockáján át azonban nem elég: a test landolás után 0,15-0,28 m-rel a talaj felett lebegne, amíg a felállási klip le nem húzza. A táblázatnak ezért képkockák × elforgatások méretűnek kell lennie.

A lassú, tervezett forgásnál még egy hatás előjön. Ha a modellt a legalsó pontjával a repülési magasságra teszi, a test középpontja az állásból vízszintesbe fordulás közben a fél magasság és a fél vastagság különbségével lesüllyed. A test ekkor a repülés elején csak lassan emelkedik, és csak utána gyorsul. Emelje meg ezért a modellt az állásbeli és az aktuális szögnél mért fél kiterjedés különbségével, legfeljebb a repülési magassággal. A test középpontja így parabolán halad.

#Halott ellenfelek: test, decal és por

A robbanásban meghalt ellenfélnek is el kell repülnie. Hozzon létre számára repülő testet: az entitás másolatát játékmenet-komponensek nélkül (életerő, jutalom, célpont). A test elrepül, földet ér, egy ideig fekszik, majd eltűnik. A helyén holttest-decal (a talajra vetített textúra) marad, mint a Warcraft 3-ban, és egy kis porfelhő. A mi játékunkban a felső határ 1000 repülő test és 1500 decal.

A decal felülnézet az esési klip egy képkockájáról, ugyanúgy elforgatva, mint a fekvő test, így a test decalra cserélése nem látszik. A felállási klip első képkockája nem jó, mert azon az alak a hátáról már felül. A porfelhőket vonja össze 1,5 m-es cellán belül. Egy bomba a tömegbe így néhány nagyobb felhőt hoz létre több száz apró helyett.

#Csapdák a Unity Entitiesben

• A bakerből származó mátrix eltűnik. Ha a kiegészítő mátrixot bake közben adja hozzá, a transzformációs rendszer egyenletes skálánál eltávolítja, és a ledöntött ellenfelek nem mozognak. Bake közben ezért kérjen nem egyenletes skálát. Ekkor viszont a prefab teljes skálája ugyanabba a mátrixba kerül, tehát ne írja felül puszta forgatással. Különben egy 2×-es méretű ledöntött ellenfél fele akkora lesz, felállás után is. A skálát tárolja külön, a mátrixot pedig skálából és forgatásból állítsa össze.
• A gyökér magassága a klipek importjakor. Humanoid klipeknél a gyökér (root) függőleges mozgása elvész, és a karakterek felálláskor átesnek a padlón. Süsse bele a gyökér magasságát a pózba. A póz lábfejhez rögzítésének opcióját ne használja, az egy méterrel lejjebb tolja az egész testet.
• Zárt alakú mátrix. Az eltolás, a forgatás és a visszatolás mint három mátrixszorzás egy jobban mérhetően lassabb, mint az eredő mátrix kézzel megírt képlete.
• Burst régi verzióval. Ha módosítja egy Burst job által olvasott komponens mezőit, az editor összeomolhat vagy értelmetlen hibákat jelezhet. Az editor újraindítása segít.

#Teljesítmény

Mérve a Unity Editorban M3 Prón, 10 000 csontvázzal egy benchmark jelenetben, 18-as kilövési erővel. Az idők a Burst jobok CPU-idejének összegei az összes szálon, nem a képkocka ideje. A grafikon és a táblázat pályaelőrejelzés és landolási táblázatok nélkül készült.

• A szimuláció lineárisan nő, ezer ledöntöttenként nagyjából 0,25 ms-mal. Pályaelőrejelzéssel és landolási táblázatokkal 2000 ledöntöttnél 0,58-0,59 ms, vagyis kicsivel a 0,5 ms-os cél felett. Észszerű felső határ ezért egyszerre 3000 ledöntött ellenfél, ami körülbelül 0,8 ms.
• Egy robbanás egy fal melletti 359 fős csoportba a ledöntési kérések rendszerében egyetlen képkockában 1,3-1,9 ms-ba kerül. Ennek nagy részét a pályaelőrejelzés teszi ki.
• Az editor FPS-értékei nem hasonlíthatók össze: ugyanannak a konfigurációnak két futása akár 80 FPS-sel is eltért.

#A megoldás korlátai

A vizuális előkészítés egy másik tesztjelenetben akár 1,3 ms-ra is nőtt, valószínűleg a landolási táblázat minden testnél történő olvasása miatt. Ez az első jelölt az optimalizálásra. Az FPS-t buildben és 1000 ellenfél egyidejű megölésének terhelését (cél: legfeljebb 1,5 ms többlet képkockánként) még nem mértük.

Ha hasonló tömeg- vagy effektszimuláción dolgozik Unityben, és segítségre van szüksége, írjon nekünk.

Egy shmup (shoot 'em up, lövöldözős játék, amelyben a hajó ellenséghullámok ellen repül) Apple Watchon három akadályba ütközik: kicsi a kijelző, az ujj eltakarja a játék felét, és az órák különböző méretűek. Ezt három döntés oldja meg: az egész játék egy rögzített 84 × 48 pontos rácson fut, az ütközéseket kézzel, téglalapokkal vizsgáljuk, a pályák pedig időpontokat tartalmazó táblázatok, nem kód. A hajót a Digital Crown korona irányítja, és magától lő.

A példák a Space Impact Watch játékból származnak, amely a Nokia 3310 telefonon 2000-ben megjelent Space Impact lövöldözős játék remake-je, és az órán kívül iPhone-on és iPaden is fut. A játék a SpriteKitre, az Apple 2D-s játékkeretrendszerére épül, de az elvek bármilyen kis képernyős shmupra érvényesek.

#Rögzített 84 × 48-as virtuális felbontás

Először döntse el, milyen egységekben számol a játék. Ha képernyőpontokat használ, a világ minden óraméreten másképp lesz nagy. Jobb egy kis virtuális felbontást választani, és mindent abban számolni. A mi játékunkban ez 84 × 48, pontosan akkora, mint a Nokia 3310 kijelzője volt. A pozíciók, sebességek, sprite-méretek és az ellenségek útvonalai ezekben az egységekben vannak megadva. A jelenet indulásakor egyszer kiszámoljuk, hány képernyőpont egy virtuális pixel (a jelenet szélessége osztva 84-gyel), és mindent csak ezzel szorzunk.

Amit ezzel nyer:

• Ugyanaz a megjelenés minden eszközön. A játék minden óraméreten és iPaden is ugyanúgy néz ki, csak a blokk mérete változik.
• Level design kis egész számokkal. Az ellenség 13-as magasságban repül, a rakéta az x = 20 pontban fordul.
• Egyszerű grafika. A sprite-ok egyszínűek, tízszeres méretben rajzolva, így egy virtuális pixel a forrásképen egy 10 × 10-es blokk. A színüket csak a játékban kapják meg: világos pályákon fekete a zöld háttéren, sötét pályákon fordítva.

#Irányítás a koronával és automatikus tüzelés

Az órán az ujj eltakarja a játék felét, ezért a hajót nem érintéssel irányítjuk. A mozgást a Digital Crown végzi: a korona elforgatása fel vagy le mozdítja a hajót. Adjon hozzá érzékenységi beállítást és az irány megfordításának lehetőségét.

A tüzelés automatikus, a mi játékunkban 0,4 másodpercenként, a negyedik pályától 0,3 másodpercenként. A kijelző csak egyetlen gesztusra szolgál: jobbra húzással a játékos bevet egyet a három különleges fegyver közül.

Az órán a találatkor érkező rezgés ugyanolyan fontos, mint az animáció, egy kis robbanást a kijelzőn könnyű nem észrevenni. A haptikát egyetlen felületen keresztül hívja meg (találat, ellenség megsemmisítése, legyőzött főellenség), amelyet minden platform a maga módján valósít meg: az óra rezgéssel, az iPhone a saját módján. A telefonos verzióban nincs korona, helyette a kijelzőn lévő gombok vannak, ugyanazzal az érzékenységi és iránybeállítással.

#Game loop egyetlen jelenetben

Az egész játék lehet egyetlen jelenet egyetlen ciklussal:

minden képkockában:
    mozgass minden objektumot
    vizsgáld az ütközéseket
    a pályán eltelt idő alapján adj hozzá új ellenségeket

Az elemeket abban a sorrendben adja hozzá, amelyben a legkorábban tesztelhetők:

• Lövés és a játékos mozgása. Nélkülük semmit sem lehet tesztelni.
• Ellenségek és ütközések. Az első ellenségnek elég egyenesen balra repülnie és egy találattól elpusztulnia.
• Rezgés és találati animációk. Nélkülük a kis kijelzőn a játékos nem tudja, hogy talált.
• Háttér és HUD. Életek, pontszám, a különleges fegyverek száma. Ha a HUD valamelyik pályán zavar, tegye alulra.

A végén játszható ciklusa lesz életekkel, pontszámmal, robbanásokkal, háttérrel és a játékos respawnjával. Ha a játéklogikát külön tartja a megjelenítéstől és a bemenettől, az órás és a telefonos verzió közösen használhatja.

#Téglalapos ütközés fizikai motor helyett

A SpriteKitnek van fizikai motorja, és kézenfekvőnek tűnik az ütközésekhez is használni. Minden objektum kap egy sprite-ja körvonalából készült fizikai testet, pontos ütközésérzékelést és egy kategóriát (játékos, ellenség, lövedék, különleges fegyver), a motor pedig magától jelzi az egymáshoz ért párokat. Az Apple a fizikai testekről szóló dokumentációban azt írja, hogy a textúra alfa-csatornájából készült testek a legpontosabbak, de egyben a legszámításigényesebbek is. A mi játékunkban kipróbáltuk, és visszatértünk a kézi vizsgálathoz.

A kézi vizsgálat egyetlen függvény, amely sorban végigmegy a csoportpárokon, és téglalapokat hasonlít össze:

minden csoportpárra:
    (játékos és ellenségek, játékos és lövedékek, lövedékek és ellenségek, lövedékek és lövedékek)
    az első csoport minden A objektumára és a második minden B objektumára:
        ha az A téglalap fedi a B téglalapot:
            kezeld a találatot

Az előnyök: a vizsgálatok sorrendje az Ön kezében van, és a teljes „mi történik találatkor” szabály egy helyen található. A pontatlanság kicsi, mert a 84 × 48-as rácson a sprite-ok olyan aprók, hogy a téglalap és a valódi körvonal csak néhány virtuális pixellel tér el.

#Pooling csak ott, ahol megéri

A pooling azt jelenti, hogy egy objektumot a megszűnése után nem töröl, hanem elrejti, és legközelebb újra felhasználja. Csábító mindent poolozni, a robbanásokat és a power-upokat is. Ennek azonban ára van: minden ütközésnek és minden frissítésnek először ellenőriznie kell, hogy az objektum egyáltalán él-e. Elég egy elfelejtett ellenőrzés, és egy rejtett ellenség megöli a játékost, vagy egy rejtett lövedék lelő egy rakétát. Amikor a mi játékunkban mindenhonnan eltávolítottuk a poolingot, főleg ezeket az ellenőrzéseket töröltük.

Egyszerű szabály: azt poolozza, amiből sok van, és ami mindig ugyanúgy jön létre. A játékos induláskor létrehoz 21 lövedéket, és utána csak újrahasznosítja őket. Az ellenségeket és lövedékeiket is újra felhasználjuk, a robbanások és a power-upok viszont normálisan jönnek létre és tűnnek el.

#Pályák időtáblaként

A pályának nem kell kódnak lennie, elég egy bejegyzéslista. Minden bejegyzés megmondja, mi jelenik meg, hányadik másodpercben, milyen magasságban és hogyan mozog. A mozgás pontok listája, amelyeken az ellenség állandó sebességgel repül át. Opcionálisan jöhetnek lövési időpontok, a főellenség rohama vagy kisebb ellenségeket kibocsátó generátor.

minden képkockában:
    idő = most - pálya kezdete - szünetben töltött idő
    a pályatáblázat minden bejegyzésére:
        ha a bejegyzés még nincs felhasználva és idő > bejegyzés.idő:
            hozz létre objektumot a bejegyzés szerint
            jelöld a bejegyzést felhasználtnak

Az így megírt pálya könnyen hangolható: egy hullámot fél másodperccel eltolni egyetlen szám módosítását jelenti. Az idővonalon látszik a ritmus is, amelyre törekedni érdemes: rövid hullám, szünet, másfajta ellenség, power-up egy nehezebb szakasz előtt.

A hátrány nagyobb változtatásoknál jön elő. A játékunk legsűrűbb pályája 71 soros, és egy ilyen táblázat szerkesztő nélkül nehezen olvasható. Jobb a pályákat hullámokként leírni (egy közös mozgásmintájú ellenségcsoport), nem egyes hajókként.

#Végtelen mód egyetlen álvéletlen számból

Egy ranglistához (nálunk Game Center) olyan mód kell, amely nem ér véget. Ebben a kézzel írt táblázatot egy generátor váltja fel, amely játék közben állítja elő. Egy 20 jegyű álvéletlen számot generál, és az egyes számjegypárok döntenek egy hullámról:

szám = következő 20 jegyű álvéletlen szám
típus = power-up, ha a 4-5. számjegy > 90, különben ellenség
sprite = 1-2. számjegy modulo ellenségfajták száma
szünet a hullám előtt = 3. számjegy / 2 másodperc (legalább 1)
magasság = 7. számjegy, a játéktér magasságára átszámolva
mozgásminta = 10-11. számjegy modulo 10
hajók a hullámban = 17. számjegy / 2 + 1
sebesség = 13. számjegy × (1 + a hullám sorszáma / 10), 20 és 50 között
minden harmincadik hullám = főellenség, a generálás áll, amíg él

A generátor seedjét (kezdőértékét) hagyja rögzítve a játékban. Így minden játékos ugyanazt a hullámsorrendet kapja, és a ranglista pontszámai összehasonlíthatók.

Hogy hogyan alakul egy ilyen mód, azt a generátor játékon kívüli szimulációja mutatja (300 hullám, ugyanaz a seed, mint a játékban). Az első főellenség 29 hullám után érkezik, vagyis 74 ellenség és 3 power-up után, nagyjából 130 másodpercnél. Az első 30 hullám a 20-as minimális sebességgel repül, mert egyetlen számjegy még az alsó határ alatt van. Az átlagsebesség aztán 28,5-re, 37,5-re és 41-re nő, a 120. hullámtól a legtöbb ellenség a maximumon repül. Nagyjából minden tizenegyedik hullám power-up.

A gyengeség az, hogy a generátor nem ismeri a ritmust. A kézzel írt pálya váltogatja a nyomást és a pihenőt, a generátor nem. A főellenség alatti szünet és a növekvő sebesség részben segít, de a kézzel írt pályák jobban játszhatók.

#A megközelítés korlátai

• Nincsenek automatikus tesztek. Mindent kézzel ellenőrzünk a szimulátorban és az órán.
• Globális állapot. A játékállapot nagy része egyetlen jelenet globális változója. Csak órás játéknál ez kényelmes, iPhone-verzió hozzáadásakor már nem.
• Pályák szerkesztő nélkül. Az időtábla kis lépésekben jól hangolható, nagyobb változtatásokhoz szerkesztő kellene.

Ha órára vagy más kis képernyőre készít játékot, és segítségre van szüksége, írjon nekünk. Arról, hogyan generálunk rejtvényeket egy másik alkalmazásunkban, a sudokugenerátorról szóló cikkünkben írtunk.

Egyértelmű megoldású sudokut két lépésben generálhat. Először töltsön ki teljesen egy üres 9×9-es rácsot backtrackinggel, a számjegyeket véletlen sorrendben próbálva. Ezután egyenként, véletlen sorrendben törölje a mezőket, és minden törlés után egy solverrel ellenőrizze, hogy a feladványnak még mindig pontosan egy megoldása van-e. Ha nem, tegye vissza a számjegyet. Egy átlagos processzoron a medián futásidő kevesebb mint egy milliszekundum.

A módszer minden olyan játékhoz és alkalmazáshoz illik, amelynek korlátlan számú új feladványra van szüksége kézi előkészítés nélkül. Gyakorlati példa a sudoku a keresztrejtvényes és fejtörős alkalmazásunkban (App Store, Google Play).

#Miért pontosan egy megoldás

A szabályokat mindenki ismeri: minden sorban, oszlopban és 3×3-as blokkban minden számjegy 1-től 9-ig pontosan egyszer szerepel. Ritkábban esik szó arról, hogy egy jó feladványnak egyetlen megoldása van. Csak így oldható meg tisztán logikával, találgatás nélkül.

Ennek gyakorlati következménye is van. A játék általában egy megoldást tárol, ehhez ellenőrzi az eredményt, és ebből ad tippeket. Ha a feladványnak két megoldása van, a játékos eljuthat a másikhoz, amely ugyanolyan helyes, a játék mégsem fogadja el.

#1. lépés: Írjon gyors solvert

A solver olyan program, amely megoldja a sudokut. Backtrackinggel (visszalépéses kereséssel) dolgozik: egy mezőbe beír egy lehetséges számjegyet, továbblép a következő mezőre, és ha ellentmondásba ütközik, visszalép, és másik számjegyet próbál. Kétszer lesz rá szükség: az üres rács kitöltéséhez és az egyértelműség ellenőrzéséhez. Az ellenőrzés minden törölt mező után lefut, feladványonként 40-70-szer, ezért gyorsnak kell lennie. Két dolog számít:

• Bitmaszkok. Minden sorhoz, oszlophoz és blokkhoz tartson egy 9 bites számot a már használt számjegyekkel. Egy mező jelöltjei, vagyis azok a számjegyek, amelyek még kerülhetnek bele, így egyetlen művelettel megvannak: minden számjegy, kivéve azokat, amelyek már szerepelnek a sorában, oszlopában vagy blokkjában. A jelöltek száma a beállított bitek száma, ez előre kiszámolható egy 512 elemű táblázatba.
• Először a legkevesebb jelöltű mező. Ne az első üres mezőt válassza balról, hanem azt, amelyiknél a legkevesebb a lehetőség (a szakirodalomban MRV-heurisztika, minimum remaining values). Az egyetlen jelöltű mezőt töltse ki azonnal, a jelölt nélküli mező halott ágat jelent, és vissza kell lépni.

Nehéz feladványokon az egyértelműség ellenőrzéséhez ezzel a szabállyal mediánban 311 lépés kell. Ha a solver balról jobbra sorban veszi a mezőket, mediánban 28 579 lépés, a legrosszabb 5%-ban pedig több mint 300 000. A különbség nagyjából 90-szeres.

#2. lépés: Töltse ki az egész rácsot

Teli rácsot ugyanaz a solver ad, ha üres rácson futtatja. Az egyetlen különbség, hogy a mező jelöltjeit véletlen sorrendben próbálja. Az első talált megoldás egy véletlen, érvényes, teljesen kitöltött rács.

#Miért nem elég véletlen mezőket törölni

A legegyszerűbb ötlet az, hogy a teli rácsból N véletlen mezőt töröljön, például nehézségtől függően 40, 50 vagy 55 mezőt. A feladvány rendben lévőnek tűnik, csak gyakran nem egyértelmű a megoldása.

A képen a tipikus eset látható. Egy két blokkra kiterjedő téglalap négy sarkában lévő mezőket kétféleképpen lehet kitölteni, és a rács többi része ezt semmivel sem dönti el. A sudokusok ezt a mintát deadly patternként ismerik. Nehézségenként 1000 feladványon az eredmény így néz ki:

A véletlen törléssel készült nehéz feladványnak átlagosan több száz megoldása van. Ezért minden törlés után szükség van az egyértelműség ellenőrzésére.

#3. lépés: Töröljön az egyértelműség ellenőrzésével

Járja be mind a 81 mezőt véletlen sorrendben. Mindegyiket próbálja kiüríteni, és számolja meg a megoldásokat a solverrel, de kettőnél álljon meg. Ennél többet nem kell tudni: egy megoldás azt jelenti, hogy a mező üres maradhat, kettő azt, hogy vissza kell tenni.

feladvány = a teli rács másolata
törölt = 0
minden mezőre véletlen sorrendben:
    ha törölt == cél: vége
    számjegy = feladvány[mező]
    feladvány[mező] = üres
    ha megoldások_száma(feladvány, legfeljebb 2) == 1:
        törölt = törölt + 1
    különben:
        feladvány[mező] = számjegy

Ha egy mezőt egyszer visszatett, ne próbálja újra. A további törlés csak lazítja a feladványt, így ha egy mezőt most nem lehetett kiüríteni, később sem lehet.

#4. lépés: Állítsa be a nehézséget az üres mezők számával

A nehézség legegyszerűbb mértéke a törölt mezők száma. A játékunkban használt három szint:

Minél kevesebb számjegy marad, annál gyakrabban rontaná el a következő törlés az egyértelműséget, és a mezőt vissza kell tenni. Nehéz szinten egy menet néha megáll, mielőtt elérné az 55 üres mezőt. Ilyenkor generáljon új teli rácsot, és próbálja újra. 1000 nehéz feladványon mérve az esetek 97,6%-ában elég volt az első menet, és egyszer sem kellett 3-nál több próbálkozás.

#A generátor sebessége és megbízhatósága

A generátort nehézségenként 1000 feladványon futtattuk (Node.js 22 szerverprocesszoron, a telefon lassabb lesz):

Emellett minden generált feladványt külön is ellenőriztünk a solverrel. Mind a 3000-nek egyetlen megoldása volt.

#Amikor az üres mezők száma nem elég

A megadott számjegyek száma a nehézség durva mértéke. Két 26 számjegyes feladvány különböző nehézségű lehet attól függően, milyen logikai technikákat igényel. Pontosabb besorolás az lenne, ha a program emberi módszerekkel oldaná meg a feladványt, és feljegyezné a legnehezebb szükséges technikát. Egy mobiljátékhoz, ahol a játékos három szint közül választ, a számjegyek száma elég.

Ha hasonló problémán dolgozik, rejtvényeket generál, vagy mobilalkalmazásra van szüksége, írjon nekünk. Hogy hogyan lehet szókeresőt generálni rejtett megfejtéssel, azt egy külön útmutató írja le. A megfejtéses svéd rejtvény generálásáról egy másik útmutató szól.

Svéd rejtvényt megfejtéssel két fázisban generálhat: először lokális kereséssel keresse meg a maszkot, vagyis a kérdésmezők és a betűmezők elrendezését, aztán töltse ki a szótár szavaival kényszerkielégítési feladatként (CSP), backtrackinggel. A megfejtést ne tegye be előre a rácsba. Csak amikor a rejtvény kész, keressen egy viccet, amelynek a csattanója balról jobbra és fentről lefelé olvasva kiolvasható belőle.

Így készülnek a svéd rejtvények a keresztrejtvényeket és szókeresőket tartalmazó alkalmazásunkban (App Store, Google Play). Egy rács néhány másodperctől néhány tíz másodpercig tartó processzoridőbe kerül, ezért a rejtvényeket előre, erősebb számítógépen generáljuk, és az alkalmazással együtt szállítjuk. A szókeresőt egészen másképp és egyszerűbben lehet generálni, erről a Hogyan generáljunk szókeresőt rejtett megfejtéssel című cikk szól.

#Minek kell megfelelnie egy svéd rejtvénynek

A svéd rejtvényben nincsenek fekete mezők. Minden mező vagy betű, vagy jobbra, illetve lefelé mutató nyíllal ellátott kérdésmező. Ebből kemény feltételek következnek:

• Minden betű egy vízszintes és egy függőleges szóhoz is tartozik. Az a betű, amelyet csak egy szó keresztez, nem ellenőrizhető, és hibának hat.
• Minden szó legalább kétbetűs, és kérdésmező áll előtte. Ezért az első sor és az első oszlop mindig csupa kérdésmező.
• A betűk egyetlen összefüggő területet alkotnak, leszakadt szigetek nélkül.
• Minden szónak szerepelnie kell a szótárban, és legalább egy meghatározással kell rendelkeznie. Egy szó sem ismétlődik a rácsban.

Ehhez jönnek a lágy minőségi szempontok: kevés kétbetűs szó, ne legyen sehová sem mutató kérdésmező, és minél kevesebb nagyon hosszú szó, mert ezeket nehéz kitölteni. A feladat számításilag nehéz. Engel és társai (2012) megmutatták, hogy már a maszk szavakkal való kitöltése is NP-teljes.

#Miért nem elég szóról szóra kitölteni a rácsot

Az első ötlet az, hogy úgy járjunk el, mint egy ember ceruzával: a megfejtést szavakra bontjuk, újságszerűen egy sorba rakjuk, mindegyik betűjén átvezetünk egy keresztező szót, a rács többi részét pedig greedy algorithm tölti ki. A greedy algorithm minden lépésben azt választja, ami éppen akkor a legjobbnak látszik, és a döntést soha nem vizsgálja felül. Ahol semmi sem illik, lyuk marad. Mivel a greedy kitöltés nem tud visszalépni, ha az első tíz szó rossz, a rács többi része ezt már nem hozza helyre.

Egy jobb szóválasztási heurisztika csak keveset segít. Kipróbálhatja a keresztező szavak hosszát a középsőktől, nagyjából öt betűtől haladva a szélsők felé. Vagy választhat evolúciós megközelítést: félkész rejtvények populációja, mindegyikből öt utód egy-egy újabb szóval, értékelés a kitöltött mezők, a magánhangzók száma és a betűk egyenletessége alapján, és csak a legjobbak jutnak a következő generációba. Az eredmények valamivel sűrűbbek lesznek, de a lyukak maradnak, mert a heurisztika csak a következő lépést látja.

A kiutat Jakob Engel 2009-ben, a Müncheni Műszaki Egyetemen írt szakdolgozata mutatja meg; ő a fent említett cikk első szerzője is. Bontsa a feladatot két független fázisra: előbb keressen jó maszkot a szavakra való tekintet nélkül, aztán töltse ki. Engel a maszkhoz evolúciós algoritmust használt. Mi egyszerűbb, véletlen rázásokkal kiegészített lokális keresést használunk, ezt a következő lépés írja le.

#1. lépés: a maszk hill climbinggel

A maszk olyan rács, amelyben minden mező vagy kérdésmező, vagy betű. A megtalálásához elég a hill climbing: olyan lokális keresés, amely apró változtatásokat végez, és azokat tartja meg, amelyek nem rontanak az eredményen.

Induljon véletlenszerűen, a belső mezők nagyjából 22%-án kérdésmezővel. Minden maszkot pontozzon büntetőpontokkal. A kemény szabálysértések (túl rövid szó, keresztező szó nélküli betű, leszakadt sziget) többnyire 1000 pontba kerüljenek, a lágy hiányosságok (a megengedett számon felüli kétbetűs szavak, semmilyen szóra nem mutató kérdésmező, egymás mellé zsúfolt kérdésmezők) 50 és 500 pont közé.

Ezután ciklusban alakítson egy mezőt kérdésmezőből betűvé vagy fordítva, esetleg toljon egy kérdésmezőt átlósan egy mezővel arrébb. A változtatást tartsa meg, ha a büntetés nem nőtt, különben vonja vissza. A változtatások felét irányítsa a legnagyobb büntetésű mezőkre, így a durva hibák gyorsan eltűnnek:

A hill climbing könnyen elakad egy lokális minimumban. Ha 2000 lépésen át semmi sem javul, „rázza meg” a rácsot: az eddigi legjobb maszkban fordítson át öt véletlen mezőt, és keressen tovább. A grafikonon ezek a csúcsok. Ha három rázás után sincs jobb maszk, és nincs benne kemény szabálysértés, álljon le.

A kész maszk maradék büntetése 200 a lágy hiányosságokért, de kemény szabálysértés nincs benne:

A szó nélküli kérdésmezőért és a leszakadt szigetért járó büntetés legyen a maszkban kezdettől fogva. Egy nagy, kész rejtvényekből álló gyűjteményben ezek nélkül a kérdésmezők 13,2%-a nem mutatott egyetlen szóra sem, és a rácsok 23,5%-ában volt leszakadt betűsziget. Velük ezek az értékek 5,0% és 0%.

#2. lépés: kitöltés szavakkal CSP-ként

A maszkból slotok listája lesz, vagyis ismert hosszúságú és ismert keresztezésű szóhelyek. A kitöltés klasszikus kényszerkielégítési feladat (constraint satisfaction problem, CSP): minden slot egy változó, a tartománya a belé illő szavak, a kényszerek pedig az egyező betűk a keresztezéseknél. Backtrackinggel oldható meg, vagyis olyan kereséssel, amely zsákutcás ágban egy lépést visszalép, és más lehetőséget próbál:

minden slotra: tartomány = az adott hosszúságú összes szó
amíg nincs minden slot kitöltve:
    válaszd a legkisebb tartományú slotot (egyezésnél a legtöbb keresztezésűt)
    a tartomány minden szavára, a legjobbtól kezdve:
        írd be a szót
        szűkítsd a keresztező slotok tartományát az egyező betűjű szavakra
        ha valamelyik tartomány kiürült: vond vissza, próbáld a következő szót
        különben folytasd a következő slottal
    ha egyik szó sem jó: lépj vissza egy slotot
50 000 lépés után add fel

A szakirodalom ezeket a heurisztikákat MRV-nek (minimum remaining values, először a legkevesebb lehetőséggel rendelkező slot) és forward checkingnek nevezi (minden beírás után szűkítsük a szomszédok tartományát, hogy a zsákutcás ág azonnal kiderüljön, ne tíz szóval később). Indexelje a szótárt előre hossz, pozíció és betű szerint. Így „a harmadik helyen Q betűt tartalmazó szavak” egyetlen halmazmetszetet jelentenek, nem a teljes szótár átnézését.

A szavak sorrendje is számít. Részesítse előnyben azokat a szavakat, amelyekhez a szótárban több különböző meghatározás tartozik. Ez egyszerű jele annak, hogy gyakori rejtvényszóról van szó. Enélkül a rács ismeretlen rövidítésekkel telne meg.

#3. lépés: a megfejtés a kész rácsban

Kitöltés közben még nem tudja, mi lesz a megfejtés. Olvassa ki a kész rács betűit balról jobbra és fentről lefelé, és keressen olyan viccet, amelynek csattanója ennek a karakterláncnak részsorozata. A betűk tehát a helyes sorrendben követik egymást, de nem kell egymás mellett lenniük. Ha talál ilyet, a megfejtés betűit ossza el a lehető legegyenletesebben a rácsban, hogy a csattanót ne lehessen egyetlen szóból kitalálni.

Ez a sorrend (előbb a rács, aztán a vicc) jelentősen megnöveli a kész rejtvények számát. Méréseink szerint egyetlen 12×12-es rácsba átlagosan 86 vicc illik a szlovák gyűjteményből (5960 vicc). Így mindig akad olyan, amelyet az adott méretben még nem használtunk.

#Miért ne helyezzük el előre a megfejtést, mint az újságokban

Az újságokban a megfejtés általában egy helyen, egy sorban és szavakra bontva áll. Ezt kétféleképpen lehet elérni, és mindkettő nagyon kevés eredményt ad.

Az első módszer, hogy a megfejtést előre elhelyezzük a rácsban. Ekkor bele kell férnie. A csattanóink átlagosan 10,3 betűből és 2 szóból állnak. Ekkora a szlovák gyűjtemény azon vicceinek aránya, amelyek egyáltalán elhelyezhetők az adott méretben:

Előre elhelyezett megfejtéssel a kis rácsok kitöltése nagyjából ugyanolyan gyakran sikerül, mint nélküle. 15×15-nél 60 próbálkozásból 5 sikerült a megfejtés nélküli 8-cal szemben, 18×18-nál 60-ból egy sem. Ráadásul minden ilyen rács egyetlen vicchez tartozik, és kis méretekben a viccek többsége el sem helyezhető.

A második módszer, hogy a rács szabadon alakul ki, és a csattanót összefüggő szakaszként keressük benne. 2200 kész szlovák rejtvényből álló mintán (mind a 8×8-tól 18×18-ig terjedő méretekből 200-200) a teljes csattanó összefüggő szakaszként egy sorban vagy oszlopban mindössze 81 rácsban fordult elő (3,7%). Ha a csattanó minden szava máshol lehet, 443 rácsban (20%), és ez még a szavak egymás mellett állásának feltétele nélkül. Olvasási sorrendben mindegyikben akadt vicc. A rácsban szétszórt megfejtés árán nagyságrendekkel több rejtvényt kap.

#A generátor teljesítménye, és miért nem fut a telefonon

A generátor méretenként 60 próbálkozást futtatott a szlovák szótárral, egy szálon (JavaScript, Node 22, Intel Xeon 2,8 GHz-es szerverprocesszor a felhőben). Egy próbálkozás egy maszk és egy kitöltés. A „sikeres kitöltés” azt jelenti, hogy a CSP 50 000 lépésen belül megoldást talált.

Mit mutatnak a mérések:

• A kis rács nem könnyű rács. A 8×8-as rácsban sok a rövid, sokszorosan keresztezett slot, és kevés a mozgástér, a kitöltés a próbálkozások mindössze 5%-ában sikerül. Egy kitöltött rács átlagosan körülbelül 10 másodperc processzoridőbe kerül 8×8-nál, 4 másodpercbe 12×12-nél és 18 másodpercbe 18×18-nál.
• A legtöbb próbálkozás kudarccal végződik. Ezért futtassa a próbálkozásokat párhuzamosan az összes magon, és vegye az első elég jó eredményt.
• A telefonon ennek nincs értelme. A játékos nem akar több tíz másodpercet várni a képernyő megnyitásakor, és az alkalmazásnak a teljes, meghatározásokat tartalmazó szótárt magával kellene vinnie. Az alkalmazáson belüli generátornak ráadásul gyakran át kell adnia a vezérlést a felhasználói felületnek, különben az alkalmazás lefagy.

#Generálás nagy mennyiségben

A generátor helye ezért egy többmagos processzorú számítógép. Nálunk minden mag saját szálat kap az indításkor egyszer betöltött szótárral. A rács akkor kész, amikor valamelyik szál elég kevés kihasználatlan mezőt tartalmazó eredményt ad vissza. Folyamatos üzemmódban körbe-körbe generál egy-egy rejtvényt minden méretben és minden nyelven. Így készült több mint 14 000 rejtvény négy nyelven (szlovák, cseh, angol, német) és tizenegy méretben 8×8-tól 18×18-ig. Minden vicc méretenként és nyelvenként legfeljebb egyszer szerepel.

Ekkora mennyiségnél két dolog számít:

• Formátum. A teljes rekord rejtvényenként körülbelül 28 kB, a teljes gyűjtemény 390 MB. Ennek nagy része kiszámítható (koordináták, mezőtípusok, kérdésmezők számai). A rácsot egyetlen karakterláncként tároló tömör formátum körülbelül 2 kB, a gyűjtemény 15 MB, az alkalmazás telepítőcsomagjában pedig nagyjából 7 MB.
• Minőségmérés. Minden generálás után mérje a szó nélküli kérdésmezők és a szigetes rácsok arányát, és az ellenőrzés jelezzen hibát, ha a számok romlanak.

#Amit a megoldás nem fed le

• Szó nélküli kérdésmezők. Az átlagos rejtvényben még mindig 2,7 kérdésmező mutat a semmibe. A bal felső sarok mindig ilyen.
• Gyakorisági adatok nélküli szótárak. A Wikiszótárból származó német szótárban a legtöbb szóhoz egyetlen meghatározás tartozik, így a meghatározások száma szerinti rangsor alig különböztet, és ritka szavak kerülnek a rácsba. Egy gyakorisági lista segítene, egyelőre nincs ilyenünk.
• A megfejtés nem egy helyen áll. Aki az újságokhoz szokott, egy sorban keresheti. Ez kompromisszum, nem ideális megoldás.

Ha hasonló, tartalomgenerálással kapcsolatos problémán dolgozik, vagy mobilalkalmazásra van szüksége, írjon nekünk.

3D telefonmodellt úgy generálhat a böngészőben, hogy egy lekerekített sarkú téglalapot kihúz a készülék mélységére, majd logikai műveletekkel (CSG) kivágja belőle az előlapot, a gombokat, a hangszórókat és a csatlakozót. Az egész készüléket ezután néhány milliméterben megadott szám írja le, és egy új modell ezeknek a számoknak a módosítását jelenti, nem modellezést egy 3D programban.

Ez mindenhol hasznos, ahol sok hasonló készülékre van szükség, vagy a felhasználónak kell őket módosítania: konfigurátorok, mockupok, termékelőnézetek. Gyakorlati példa az Ecranify, egy eszköz 3D mockupokhoz App Store és Google Play képernyőképekhez, amelyben egyetlen kész 3D modell sincs. Alább lépésről lépésre olvashatja a folyamatot, egy méréssel együtt, amely megmutatja, hol lehet a számításon a legtöbbet spórolni.

#Amire szüksége lesz

• Three.js a jelenethez, kamerákhoz, fényekhez és főleg a geometriához. A geometria a Three.js-ben mesh, vagyis háromszögek halmaza.
• A three-bvh-csg könyvtár a mesheken végzett logikai műveletekhez. Térbeli indexszel (BVH, bounding volume hierarchy) gyorsítja őket, így nem vet össze minden háromszöget minden másikkal.
• A készülék leírása adatként, például JSON a ház méreteivel, a sarkok sugarával, a bevel méretével és az oldalakon lévő elemek listájával. Minden pozíciót a készülék közepétől mért milliméterben adjon meg.

#1. lépés: Húzza ki a téglalapot 3D-be

Rajzoljon egy lekerekített sarkú 2D téglalapot valós méretben, például 163,4 × 78 mm-eset, és húzza ki (extrudálás) 8,75 mm mélységre. Éles élű lapot kap. Ilyen telefon nincs, ezért a kihúzáskor kapcsolja be a bevelt is, vagyis az él lekerekítését. A Three.js mindkettőt egy lépésben elvégzi.

Csak extrudálás

+ sarkok és bevel

Egy dologra figyeljen: a bevel kifelé adódik hozzá. Ha pontos külső méretre van szüksége, csökkentse a 2D formát és a mélységet a bevel méretével.

b = min(bevel, mélység / 2)
forma = lekerekített téglalap(szélesség - 2b, magasság - 2b, saroksugár - b)
ház = kihúz(forma, mélység - 2b, bevel b)

Az ívek simaságát (tesszelláció) az határozza meg, hány szegmensre bontjuk az ívet. Több szegmens simább formát és több háromszöget jelent. Ez a szám később az egész számítás sebességét meghatározza, ezért a 7. lépésben visszatérünk rá.

#2. lépés: Vágjon mélyedést a kijelzőnek

A CSG (constructive solid geometry) egyszerűbb testekből rak össze testeket három művelettel: unió, különbség és metszet. A különbség úgy működik, mint egy fúró: az egyik test anyagot vesz el a másikból.

A telefon kijelzője nem egy síkban van a kerettel, hanem egy sekély mélyedésben ül. Ehhez készítsen a házról egy második, 1,4 mm-rel kisebb másolatot, hagyja meg belőle csak a 0,7 mm vastag elülső részt (metszet egy nagy téglatesttel), és vonja ki ezt a részt a házból. A keletkezett mélyedésbe ezután tegyen egy sötét kijelzőfelületet.

Vágótest

Kivonás után

Két gyakorlati részlet:

• A metszethez használt téglatestnek tényleg nagynak kell lennie. Elég, ha a mélységet vágja, de szélességben és magasságban túl kell nyúlnia az egész készüléken. Ne a mélységből számolja: például a mélység 20-szorosa egy vékony, magas telefonnál kisebb, mint a magassága, és fent meg lent vágatlan keret marad.
• Nagyítsa meg a vágótestet néhány ezrelékkel. Ha két testnek pontosan azonos lapja van, a CSG nem tudja eldönteni, melyik oldal van belül. Az 1,002-es lépték ezt megelőzi, és szemmel nem látszik.

#3. lépés: Készítse elő az oldalsó elemeket fúróként

Minden oldalsó elem ugyanaz a recept más fúróval. Egy gomb például három testből áll: egy a gombnál kicsit mélyebb lekerekített téglalapot kivonunk a keretből, a nyílás széle kis letörést kap, a nyílásba pedig egy valamivel kisebb test kerül, amely kissé kiáll a keretből.

Fúrók

Kivágás és gomb

A hangszórók kis hengerek sorai, a csatlakozó egy lekerekített téglalap. Minden nyílásba tegyen valami sötétet: vékony korongot a rácsba, lapkát a csatlakozóba. Egy üres lyuk a vékony héjban hibának tűnik, a sötét kitöltésű lyuk hardvernek.

az oldalsó elemek listájának minden elemére:
    fúró = az elem formája (henger, lekerekített téglalap, ...)
    helyezd a fúrót az élre a mm-ben megadott pozíció szerint
    add hozzá a fúrót a vágások listájához
    ha az elemnek van kitöltése: add hozzá a kitöltést a jelenethez

Egy gomb hozzáadása így csak egy új bejegyzés az adatokban. Az elemek gyorsan szaporodnak: egy iPad Pro 13″ 58 hangszórólyukkal, 4 gombbal, 2 antennával és egy csatlakozóval rendelkezik, ez több mint 60 kivonás egyetlen házból.

#4. lépés: Az előlap részleteit ne fúrja

A kamera kivágása, a kijelző tetején lévő sziget és a kezdőképernyő-jelző lapos. Geometriát vágni hozzájuk felesleges munka. Helyezze fel őket decalként, vagyis felületre vetített képként. Vetítse egy rejtett síkra, amely az egész előlapot lefedi, és a pozíciót ugyanabban a milliméterben adja meg, mint minden mást. Kivétel a régebbi iPhone-ok kerek kezdőgombja. Ennek valódi mélysége van, ami oldalról látszik, ezért CSG-n megy keresztül.

#5. lépés: Tegye át a számítást Web Workerbe

A böngészőben a JavaScript egyetlen szálon fut. Ugyanez a szál számol, rajzolja az oldalt és reagál a kattintásokra. Amíg a CSG fut, az oldal megáll, és egy spinner sem segít, mert annak is ugyanez a szál kell.

Ezért az egész készülék összeállítását futtassa Web Workerben, vagyis egy külön háttérszálon. A worker megkapja a készülék leírását, kész csúcstömböket ad vissza, és az oldal folyamatos marad. Ha egy paraméter megváltozik, állítsa le a régi workert, és indítson újat, hogy ne számoljon végig egy elavult állapotot.

A worker eredménye eltart egy ideig, ezért adjon hozzá azonnali előnézetet. A szerkesztett elemet mutassa kék, áttetsző „szellemként”: egyszerű téglatestként vagy hengerként néhány tucat háromszöggel, amely a fő szálon azonnal felépíthető. Amikor a worker végez, a szellem eltűnik.

#6. lépés: Vonja ki az összes lyukat egyszerre

A legegyenesebb út az elemek egymás utáni kivonása: az 1. lyukat a házból, aztán a 2.-at az eredményből és így tovább. Minden kivonás azonban újraépíti az egész ház térbeli indexét, ami a számítás legdrágább része. Több tucat elemnél az idő nagyon gyorsan nő.

Jobb, ha előbb összegyűjti az adott test összes fúróját, egyetlen mesh-be egyesíti őket, és egyszer vonja ki.

vágások = []
minden elemre: add hozzá a fúróját a vágásokhoz
egyesített = egyesítsd az összes vágást egy mesh-be
ház = ház mínusz egyesített
ha az egyesítés nem sikerül: vond ki a vágásokat egyenként

Mérés a folyamat egyszerűsített másolatán (Three.js 0.170, three-bvh-csg 0.0.17, Node 22, felhőszerver 2 Intel Xeon 2,1 GHz-es maggal, 5 futás mediánja):

Egy feltétel: az egyesítés és egyetlen kivonás csak akkor adja ugyanazt az eredményt, mint a fokozatos kivonás, ha a fúrók nem fedik egymást. Az elemek különböző helyeken vannak, így ez általában teljesül. Ha viszont a felhasználó két elemet egymásra tol, az átfedés helyén apró hiba keletkezhet.

#7. lépés: A szegmensszámot tartsa paraméterként

A megjelenítéshez elég tesszelláció a CSG-hez gyakran feleslegesen sűrű. Saroknként 64 és a bevelen 32 szegmenssel a ház 68 108 háromszögből áll. A felét (32 és 16) egy 2 mm-es élen nem látni, de a ház így csak 17 676 háromszög, és a táblázat harmadik sora mutatja, mit jelent ez az időben.

64 és 32 szegmens

32 és 16 szegmens

A legfeljebb 2 mm sugarú kis elemek (hangszórólyukak, csavarok) kapják a szegmensek felét, a galéria előnézetei még kevesebbet. A minőséget ezért ne konstansként írja a kódba, hanem az összeállítás paramétereként adja meg.

#Renderelés szerveren videokártya nélkül

Ha ugyanazt a jelenetet szerveren is renderelni kell, például az exportok tartalékaként, az képernyő nélküli (headless) Chrome-ban fut, amely videokártya híján szoftveresen rajzol. Ott minden pazarlás megsokszorozódik. Az Ecranifyban a legnehezebb tablet a fenti módosítások nélkül elérte a 15 perces időkorlátot. Egyesített vágásokkal, kisebb textúrákkal, alacsonyabb tesszellációval és a kész geometria cache-ével, amelynek kulcsa a készülékleírás hashe, egy renderelés nagyjából fél percig tart, egy ismételt pedig körülbelül 5 másodpercig. A részletek interaktív példákkal az ecranify.com angol nyelvű cikkében olvashatók.

Ha hasonló 3D-s problémát old meg a böngészőben, vagy egyedi alkalmazásra van szüksége, írjon nekünk.

Egy Unity 4-es projektet ne nyisson meg közvetlenül Unity 6-ban, és főleg ne mentsen benne semmit. A Unity 6 a régi bináris jeleneteket csak részben tölti be, a mentés pedig véglegessé teszi a veszteséget; a biztonságos út a Unity 2019.4-en át vezet, amely a régi formátumot olvasni és szövegként visszaírni is tudja, és csak utána jön a Unity 6.

Ez azokra a projektekre vonatkozik, amelyek jeleneteit és prefabjait bináris formátumban tárolták, szkriptjeit pedig UnityScriptben írták, abban a JavaScripthez hasonló nyelvben, amelyet a Unity egykor a C# mellett támogatott. Példaként az Onagert használjuk, egy katapultos fizikai játékot, amely Unity 4.1.2-ben, UnityScriptben készült. A projektben 126 szkript, 75 jelenet és 78 prefab volt. Az átvitel után Unity 6000.5-ön fut URP-vel (Universal Render Pipeline), és ingyen elérhető az App Store-ban és a Google Playen.

#Mi történik, ha Unity 6-ban nyitja meg a projektet

A legegyszerűbb megközelítés megnyitni a projektet Unity 6-ban, és a szerializációt Force Textre állítani, vagyis az asseteket olvasható YAML-ként menteni. Ez azonban nem a fájlok fordítása. A Unity minden assetet a saját importerén keresztül tölt be, és YAML-ként írja vissza, így minden átmegy a Unity 6 betöltőjén. Ez minden jelenetnél egy GameObjecthez nem rendelt Transformot jelez, és törli a „lógó” komponenst. A mentés ezt véglegessé teszi.

A veszteség a binary2text eszközzel mérhető, amely a szerkesztővel együtt érkezik, és importer nélkül olvassa a szerializált fájlt. Az Onagernél a kimenetét összevetettük a keletkezett YAML-lel, és csak azokat a komponenseket számoltuk, amelyek a megmaradt GameObjectekről tűntek el:

A 75 jelenetből egy sem úszta meg veszteség nélkül. Teljes HUD-kamerák tűntek el, a fő kamera helyére pedig egy új, alapértelmezett kamera került. A lényeg: a kár már betöltéskor keletkezik, nem mentéskor. Amíg a projekt nincs átalakítva, a Unity 6 nem mentheti el, egyetlen jelenetet és egyetlen prefabot sem.

#1. lépés: Rögzítse az eredeti állapotot

Mielőtt bármihez hozzányúlna, készítsen képernyőképet minden jelenetről, és minden eredeti jelenetfájlról mentsen egy kiírást a binary2text eszközzel. Ezekhez a kiírásokhoz hasonlítja a kamerákat a 3. lépésben, és ezekből állítja vissza a HUD-ot az 5. lépésben. Az eredeti bináris fájlokat hagyja a git előzményeiben, ne törölje őket.

#2. lépés: Szöveggé alakítás Unity 2019.4-gyel

A Unity 2019.4 az utolsó szerkesztő, amely a Unity 4.1 formátumát olvasni és írni is tudja. Az átalakítást zárt szerkesztővel, a repó külön másolatában végezze:

• Projektverzió. A projekt verzióját tároló fájlban állítsa be az eredeti verziót (az Onagernél 4.1.2), hogy a szerkesztő a régi projektekre szolgáló utat válassza. A Unity megnyitáskor felülírja, elég, ha az első importnál érvényes.
• Üres csomagok. Ürítse ki a csomagfüggőségek listáját. Egyetlen fordítási hiba azt jelenti, hogy a szerkesztőszkriptek egyik menüpontja sem működik, és ez úgy néz ki, mintha a menü meg sem jelent volna.
• Import a nulláról. Törölje a Library mappát, és hagyja a projektet importálni.
• Force Text és kényszerített újraírás. A Force Textre váltás után a Unity 2019.4 magától nem írja újra a meglévő fájlokat. Ezt az assetek újraszerializálására szolgáló függvénnyel kell kiváltani, mégpedig csak az assetekre, a meta fájljaikra nem. Az összes meta fájl újraírása után a Unity 6 újra és újra importál.

Egy csapda a gitben van. Ha a git attribútumai a jeleneteket LF sorvégű szövegként jelölik, a git a repóba való felvételkor kiveszi a bináris jelenetekből a sorvégnek látszó bájtokat. Az Onagernél ez nyolc jelenetet rongált meg. A Unity assetjeire ne tegyen sorvég-attribútumot, a Unity úgyis LF-et ír.

#3. lépés: Az eredményt a szerkesztőben ellenőrizze, ne a YAML olvasásával

Az átalakított fájlok olvasása magabiztos, de hibás következtetésekhez vezet. A prefabpéldányok rövidített bejegyzései veszteségnek látszanak, ahogy az a kamera is, amely csak átkerült egy prefabba. Az számít, amit a Unity a memóriában felépít. Minden átalakított jelenetet nyisson meg, és a kameráit vesse össze az eredeti 1. lépésben mentett kiírásával.

Az Onagernél az átalakítás után mind a 75 jelenetben ugyanazok a kamerák maradtak, ugyanabban a sorrendben. Csak az veszett el, amit ma már egyetlen szerkesztő sem ismer: 569 GUITexture, 179 GUIText és a régi részecskerendszerek, amelyeket a Unity 2018-ban eltávolított.

#4. lépés: UnityScriptről C#-ra ugyanazzal a GUID-dal

A Unity a 2017.2-es verziótól fokozatosan vezette ki a UnityScriptet, így a kézi port C#-ra az egyetlen út. A jelenetek a szkriptekre a GUID-dal hivatkoznak, ez egy egyedi azonosító, amelyet a Unity minden asset meta fájljában tárol, a mezők értékét pedig a mező neve szerint tárolják. Ha a port során mindkettőt megtartja, minden hivatkozás magától visszakapcsolódik:

minden X UnityScript-szkripthez:
  hozz létre egy C#-szkriptet pontosan X nevű osztállyal
  másold át a GUID-ot a régi szkript meta fájljából az újéba
  publikus mezők: ugyanaz a név, ugyanaz a típus, elírásokkal együtt
  semmit ne nevezz át, amíg a projekt nem fut

Az Onagernél így mind a 126 szkript portja után 12 935 komponens kapcsolódott vissza 73 jelenetben, és az Inspectorban beállított összes érték megmaradt.

Szöveges kereséssel nem deríthető ki, mely szkriptek vannak használatban. A bináris prefab a GUID-ot bájtokként tárolja, nem szövegként. Az Onagernél így huszonegy szkript tűnt használatlannak, és mindegyik élt. Figyeljen a korábbi portkísérletek maradványaira is: egy fakocka prefabja egy ilyen kísérlet két szkriptjére mutatott, és egyedül miatta hiányzott 1140 komponens. Ha egy bináris fájlban GUID-ot kell cserélnie, cserélje közvetlenül a bájtokban, tizenhatot tizenhatra, hogy a fájl ne csússzon el.

#5. lépés: Állítsa vissza a HUD-ot az eredeti bináris jelenetekből

A GUITexture és a GUIText nincs meg a Unity 6-ban, és velük együtt eltűnik a rájuk épülő teljes HUD. Újrarajzolni nem kell. A binary2text a git előzményeiből származó eredeti bináris jeleneteket akkor is beolvassa, ha az osztályok már nem léteznek. Nyerjen ki belőlük minden HUD-képet és -szöveget textúrával, színnel, pozícióval és igazítással, és szkripttel tegye vissza őket a jelenetek ugyanazon objektumaira. Az Onagernél ez 577 kép és 180 szöveg volt.

Így azok a szövegek is megmenekülnek, amelyek sehol máshol nincsenek meg. Az Onagernél ez 111 szöveg volt: minden tutorialfelirat és a teljes stáblista. Ha a HUD-ot a nulláról írná meg, ki kellene találnia őket. A színek átvitelénél számoljon valamivel, amiről a dokumentáció hallgat: a régi GUITexture rajzoláskor megduplázta a színt. Mind az 577 kép színe pontosan 0,5 volt, vagyis a szürke fehéret jelentett.

#Az átalakítás után: cserélje le a régi kerülőmegoldásokat

A régi projektek gyakran megkerülték az akkori Unity korlátait, és ezeket a kerülőmegoldásokat az átalakítás után érdemes újraépíteni:

• Tükröződés a padlón. Az Onagerben fényes padló volt valódi tükröződés nélkül. A padló alatt egy második, tükrözött világ állt: minden objektum másolata, amelynek pozícióját egy szkript minden harmadik képkockában átmásolta az eredetiről, egy pályán 50-70 klón. Ez helyettesíthető egyetlen további kamerával, amely a tükröződést fél felbontásban rajzolja. Ekkor a részecskék és a törmelék is tükröződnek, amire a klónozott világ nem volt képes.
• Célzás. Ha a röppálya előnézete azt próbálja megjósolni, hová küldi a lövést az első fizikai lépésben hozzáadott erő, a lövés máshová esik, mint a jelölő. Megbízhatóbb egyszer kiszámolni a sebességet, az előnézetet pontosan abból rajzolni, és közvetlenül a lövéshez rendelni.
• Teljesítmény. Gyenge telefonon mérjen. Egy Motorola G52-n az Onager csak a falak shadere miatt 20-ról 6 fps-re esett, ez több volt, mint a felbontás, az árnyékok és a tükröződés együtt. Ezért alacsony és közepes részletességnél a falak egyszerűbb anyagot kapnak.

Ha a mai Unityben több ezer objektum fizikáját kell megoldania, nézze meg a több ezer ellenségre szabott hamis ragdollt a Unity DOTS-ban is. Hogy átállás után hogyan kaphat egy régi 2D játék glow-t és 2D fényeket URP-ben, azt egy külön útmutató írja le.

#Amit ez a módszer nem old meg

Azok a komponensek, amelyeket a mai Unity nem ismer, nem kapcsolódnak vissza. A GUITexture-t és a GUIText-et az 5. lépés szerint kell visszaállítani, a régi részecskerendszerek elvesznek. Az osztályok és mezők neve pontosan olyan marad, mint az eredeti projektben, elírásokkal együtt és azon a nyelven, amelyen valaki egykor megírta őket. A jelenetek név szerint kötődnek hozzájuk, ezért átnevezni csak a szerkesztőn keresztül érdemes, amely maga írja át a hivatkozásokat.

Ha van egy régi Unity-projektje, amelyet egy mai verzióra kell átvinni, írjon nekünk.

Több ezer ellenségből álló hordát Unity DOTS-ban egyetlen, az egész pályára kiterjedő flow fielddel és néhány olcsó helyi szabállyal irányítson: taszítás a szomszédoktól és a falaktól, a tömegsűrűségtől függő útköltség és egy „várok” állapot a dugóban. A Unity Editorban egy M3 Pro-s MacBookon ez nagyjából 9600 ellenséget bír egyszerre 90 FPS mellett.

A probléma tower defense, stratégiai és survival játékokban jelentkezik, ahol egyszerre több ezer egység tart egy cél felé. A klasszikus, egységenkénti útkeresés túl drága, helyi szabályok nélkül pedig a tömeg átfedi egymást, a falakhoz tapad és elakad a szűkületekben. A Unity DOTS (Data-Oriented Technology Stack, azaz Entities, ECS és Job System) megadja a teljesítményt több ezer entityhez, a navigációt viszont nem oldja meg. Az alábbi módszert a PC-re készülő tower defense játékunkban használjuk (szerepel a referenciáink között). A képek egy egyszerűsített, ugyanazokkal a szabályokkal futó 2D szimulációból származnak, nem a játékból.

#1. lépés: Flow field egységenkénti útvonal helyett

A flow field egy az egész pályát lefedő rács, amelyben minden cella tudja, merre kell belőle a cél felé menni. Az ellenség nem keres utat, csak leolvassa az irányt azon a helyen, ahol áll. A költség 10 és 10 000 ellenségnél is ugyanannyi.

Ossza fel a pályát 1 m-es cellákra (a tesztpályánk 128 × 128-as), és minden célhoz egyszer számolja ki minden cella távolságát a céltól. A statikus mezőt elég a szerkesztőben, a pálya előkészítésekor kiszámolni és egy assetben tárolni.

A legegyszerűbb változat a Dijkstra 8 szomszéddal, minden cellában a 8 irány egyikével. Működik, de az ellenségek átlósan mennek, és libasorban a falakhoz tapadnak.

8 irány

Sima mező

Jobb eredményt ad a sima mező. A távolságot az eikonál-egyenlet megoldásával számolja ki (hullámfront-egyenlet, amelynek megoldása a folytonos térben mért legrövidebb távolság, nem csak a rács élei mentén), a fast sweeping módszerrel, amely a rácsot ismételten mind a négy sarokból bejárja. Az irány így nem a cella iránya, hanem a távolság gradiense az ellenség pontos helyén. A cella költségéhez adjon felárat a fal közelségéért, így a mező magától távol tartja a tömeget az akadályoktól.

#2. lépés: Külön mező minden ellenségmérethez

A nagy ellenség nem fér be mindenhová, ahová a kicsi. Vezessen be méretosztályokat: mindegyiknek saját járhatósága van (a cellának elég messze kell lennie a faltól), és minden célhoz saját mezője. Az osztályokat pályaadatként tartsa, ne a kódban. Nálunk három van.

#3. lépés: Taszítás a szomszédoktól

A flow field megadja az irányt, de a szomszédokról semmit sem tud. Az alap egy egyszerűsített boids modell (a raj klasszikus szabályai): minden ellenség taszítja a 0,9 m-en belüli szomszédait. A szomszédokat spatial hashben keresse, vagyis egy térbeli rácsban, ahol minden cella a benne lévő egységek listáját tartja. A hasht minden tickben építse fel újra és rendezze, hogy a sorrend determinisztikus legyen.

A taszítás önmagában nem elég. 3000 ellenségnél 83,7 %-uk legközelebbi szomszédja 0,8 m-nél közelebb volt, a legkisebb távolság pedig 4 cm, vagyis két ellenség szinte egymásban állt.

A taszítás súlyának növelése nem oldja meg. 1,5 helyett 6-os súlynál a túl szorosan állók aránya 54,6 %-ra esett, 12-nél 44,3 %-ra, 24-nél már nem javult (48,2 %). Ráadásul a tömeg ugrálni kezd, mert sok szomszéd korlátlan lökései egyszerre adódnak össze.

A pozíciókorrekció segít. Mozgás után minden átfedő párt toljon szét, mindkettőt az átfedés felével, és tickenként korlátozza az eltolást 0,15 m-re. Korlát nélkül a korrekció ugyanúgy ugrál, mint a nagy súly. Vele a túl szorosak aránya 60,8 % marad, de a legkisebb távolság 28 cm-re nő, és a tömeg nem ugrál.

Csak taszítás

Átfedéskorrekció

#4. lépés: Taszítás a falaktól

A falnál az ellenségek közötti korrekció csődöt mond. A falba mozgás tilos (az eltolás tengelyenként bomlik fel, a falba mutató összetevő elvész), így a falhoz szorult ellenség nem tud kitérni, és a szomszédtól jövő korrekció elvész. 938 átfedő ellenségből csak 35-nél volt egyáltalán nyomás a fal felől.

Ezért adjon hozzá taszítást a legközelebbi járhatatlan cellák felől, 4 irányban és átlósan is. Két hiba, amelyet elkerülhet:

• Belső sarok. A két él és a sarok nyomása összeadódik, és elhajítja az ellenséget. Sarokból jövő nyomást csak külső saroknál adjon hozzá.
• Valódi falak. A valódi falaktól taszítson, ne a méretosztály járhatóságától. Egy nagy ellenség számára a „fal” már egy méterrel a valódi előtt kezdődik. Egy folyosó bejáratánál így a sarok nyomása kioltotta egy nagy ellenség előrehaladását, és a mögötte haladó egész csoport megállt.

#5. lépés: Sűrűségfüggő költség és lassítás

Sima mezővel is az egész tömeg a legrövidebb úton, szorosan a sarok mellett megy, függetlenül attól, hányan vannak már ott. Megoldást a Continuum Crowds (Treuille és mtsai, 2006) kínál: a cella költsége a tömegsűrűséggel nő. 10 tickenként számolja meg az ellenségeket cellánként, simítsa ki az eredményt, és számolja újra egy cél mezőjét. Zsúfolt saroknál a mező így körbeküldi az ellenséget, a szabadabb cellákon át.

Sűrűség nélkül

Sűrűségfüggő költség

A másik fele a lassítás. A sűrű cellában lévő ellenség lassabban megy, legfeljebb a sebessége 15 %-ára lassul. 2250 ellenségnél a ritka cellákban átlagosan a sebességük 94 %-ával haladtak, közepes sűrűségnél 71 %-kal, dugóban 20 %-kal. A lassítás kezdődjön korán: cellánként 1 helyett 0,6 ellenséges szabad sűrűségi küszöbbel a túl szorosan állók aránya a szűkületben 36,7 %-ra esett.

Gyakorlati tanács: a csak futásidőben létrejövő tömböket (például a sűrűségtérképet) foglalja le, mielőtt egy job először használná őket. Egy még létre nem hozott tömbbel ütemezett job natívan összeomlasztja a Unity Editort, mindenféle exception nélkül.

#6. lépés: Dugó a szűkületben: várni, nem tolni

Ha a tömeg sehová sem tud szétterülni, marad a szűkület. A legegyszerűbb ötlet az, hogy eldobjuk a sebesség azon összetevőjét, amely az érintett szomszéd felé mutat. A hátsók ekkor kitérés helyett megállnak, és fenntartják a dugót.

Oldalra kitérni, például 35°-kal a kevesebb szomszéd felé, jobb, de a tömeg villogni kezd. A fordulás simítása és alacsonyabb fordulási sebesség (360 helyett 180 °/s) csak tompítja a tünetet. Az ok máshol van: kiegyenlített sűrűségnél az ellenség minden tickben más oldalt választ. A hiszterézis segít, vagyis az előző döntés előnyben részesítése: az előző tick oldala az összehasonlításnál 3 szomszédnyi kedvezményt kap.

A végső megoldás érintkezési korlátot és három állapotot kapcsol össze: halad, kitér, vár. Az érintett szomszéd felé mutató sebességösszetevő elvész, az oldalirányú megmarad. Akinek nincs szabad oldala és maga előtt sincs helye, az vár, és nem tol.

minden ellenségre, minden tickben:
    sebesség = irány a flow fieldből × tempó × sűrűség szerinti lassítás
    sebesség += taszítás a szomszédoktól
    ha elöl szomszédhoz ér:
        ha van szabad oldal: kitér (oldal hiszterézissel)
        különben: vár
    eldobja az érintett szomszédok felé mutató sebességösszetevőt
    elmozdul, a falba mutató összetevőt eldobja
utána mindenkire:
    az átfedő párokat széttolja (az átfedés fele, legfeljebb 0,15 m)
    taszít a falaktól

Három dologra figyeljen:

• Türelem. Ha két ellenség szemből találkozik, a nagyobb azonosítójú (ID) várjon. Egy szomszédlánc azonban ezernyi tickig blokkolhatja, ezért a várakozási korlát után vészkitéréssel próbálkozik.
• Nulla sebesség. A nulla kívánt sebességű ellenség soha nem lép ki a „vár” állapotból, és egy hullám után a nyílt terepen állva marad. Aki nem akar mozogni, legyen mindig „halad” állapotban.
• Keskeny kúp. Az elöl lévő szomszédot keskeny kúpban, rövid szondával keresse. 45°-nál a beállítás nyílt terepen is a tömeg 55-60 %-át küldte várakozásba vagy kitérésbe, 30°-nál és rövidebb szondával 41 %-át.

#7. lépés: Nagy ellenségek megelőzése

A különböző méretű és sebességű ellenségtípusok újabb eseteket hoznak. A nagy, lassú ellenségünk sugara a tömegben 1,25 m, sebessége 1,1 m/s. A mögötte haladó gyors ellenség nem tudta megelőzni: az átlósan előre néző oldalsó szondák mindig közelebb voltak a nagyhoz, mint a sugarak összege, mindkét oldal foglaltnak bizonyult, és a gyors várt. A javítás: a megkerült szomszédot a szonda csak a saját oldalán veszi figyelembe. A pontosan előtte álló szomszéd egyik oldalt sem blokkolja.

A nagy ellenség viszont oldalra löki útjából a kicsiket, a maga előtti ±45°-os szektorban. Ne lökje el azokat, akik gyorsabban haladnak az ő irányában, mint amennyire ő akar, különben azokat is ellöki, akik éppen megelőzik.

#8. lépés: Slotok a támadás célpontja körül

Ha az ellenségek közelharcban támadnak, hely kell nekik a célpont körül. A tornyunknak 24 slotja van az 5 × 5 m-es alapterület kerületén, minden ellenség egyet foglal el, a többiek sorban várnak.

• Körben kerülés. Ha csak akkor kínál fel slotot, ha egyenes vonal vezet hozzá, a hátsó slotok üresek maradnak, mert elölről a hozzájuk vezető vonal átmetszi a tornyot. Az ellenség ívben kerülje meg a tornyot a szabad slotig.
• Kiszorítás nélkül. Ne szorítsa ki a slot felé tartó ellenséget egy másik jelentkező javára, mert kiszorítások láncolatát indítja el.
• Taszítás nélkül a slotnál. A foglalt slot mellé érkező ellenséget a szomszédja ellöki, így 13 cm-re a céljától vagy teljesen mellette köt ki. A slotban lévő és tőle 0,5 m-en belüli ellenségek nem taszítják egymást.

#A szimuláció és a renderelés teljesítménye

Egy benchmark a Unity Editorban (M3 Pro, nagyjából 9600 egyszerű ellenség, két szűkület) 1440p-n 90 FPS-t, 1080p-n 100-at adott. A felbontás alig változtat az FPS-en, az időgyorsítás viszont igen: 10×-nél 20 FPS-re esik, mert egy képkockára tíz szimulációs lépés jut. Normál sebességnél a szimulációnak van tartaléka.

Kapszula helyett részletes ellenségmodellel a szűk keresztmetszet a renderelésbe kerül át:

A szimulációban három dolog térül meg:

• Két szomszédkeresési menet. Az olcsó (érintkezések, blokkolás) mindig fut, a drága (oldalsó szondák, oldalak sűrűsége) csak a blokkoltaknál, akik szabad áramlásban kisebbségben vannak. A távolságokat négyzetesen hasonlítsa össze, gyökvonás nélkül.
• Egyszerű rendezés. A spatial hash szinkron rendezése 3000, 10 000, 20 000 és 50 000 bejegyzésnél 0,37, 1,49, 3,16 és 8,46 ms-ig tartott, a jobos változat 0,18, 0,93, 3,12 és 15,53 ms-ig. A job nem következetesen gyorsabb, az egyszerű rendezés elég.
• Állapothash. A 600. és az 1800. tickben számoljon hasht a pozíciókból és az életerőből. Egy refaktornak ugyanazt a hasht kell adnia, a viselkedés megváltozása megváltoztatja, és meg tudja magyarázni, miért. Ez a spatial hash determinisztikus sorrendjének köszönhetően működik.

#A módszer korlátai

• Két teli, egymással szemben haladó tömeg egy szűkületben végleg beragad. Ez a fizika nélküli modell korlátja.
• A számok a Unity Editorból származnak, M3 Pro-n. Steam Decken és valódi buildben még nincs mérésünk, csak becslésünk nyilvános processzor-benchmarkok alapján.

Ha saját tömeget szeretne kipróbálni, a Unity Entities dokumentációja jó kiindulópont. Hasonló utat a legegyszerűbb megoldástól a működőig a sudokugenerátorról szóló cikkünk is bemutat. Hogy egy ilyen horda ellenségeit hogyan repítheti szét egy robbanás anélkül, hogy mindegyikükre drága ragdollt szimulálna, azt a fake ragdoll Unity DOTS-ban útmutató mutatja be. Ha hasonló szimuláción dolgozik Unityben, és segítség kellene, írjon nekünk.

Rejtett megfejtésű szókeresőt úgy generálhat, hogy egy üres rácsba véletlenszerű szavakat tesz a szótárból, amíg pontosan annyi szabad mező marad, ahány betűs a megfejtés. Ezeket aztán kitölti a megfejtéssel balról jobbra és fentről lefelé. Telefonon ez néhány milliszekundum, és nem kell hozzá backtracking, vagyis visszalépés korábbi döntésekhez, amikor a generátor elakad.

A szókereső egy betűrács, amelyben a játékos egy lista szavait keresi meg és húzza ki. A megfejtés a kihúzás után megmaradó betűkből olvasható ki. A generátornak tehát teljesen kitöltött rácsot kell összeraknia, amelyben a szavak kihúzása után pontosan a megfejtés marad. Az alábbi módszerrel készülnek a szókeresők a keresztrejtvényes és szókeresős alkalmazásunkban (App Store, Google Play).

#A rács szabályai

Mielőtt nekikezd, döntse el, mit kell teljesítenie a kész rácsnak. Az alkalmazásunkban ezek a szabályok:

• A szavak nyolc irányban futnak: vízszintesen, függőlegesen és mindkét átló mentén, mindegyik irányban visszafelé is.
• Két szónak legfeljebb egy közös betűje lehet.
• Egyetlen szó sem haladhat át a megfejtés mezőjén.
• A rácsnak tele kell lennie. Az üres mező hiba.
• A megfejtést balról jobbra és fentről lefelé olvassuk az összes ki nem húzott betűből.

#1. lépés: Készítse elő a szótárt

A szótárt egyszer, az elején ossza csoportokba szóhossz szerint. Így egy adott hosszúságú véletlen szó kiválasztása egyetlen véletlen index. Ha minden szónál a teljes szótárt szűri, a generálás érezhetően lelassul, mert egy rácshoz több száz szót próbál ki.

A szlovák szótárunk 16 713 szót tartalmaz 3 és 21 betű között, a legtöbb hét- és nyolcbetűs. Néhány gyakorlati tanács:

• Hagyja a szótárban a tulajdonneveket és rövidítéseket is. Így a rácsban felbukkan például HOUSTON vagy MAINE. Rövid és „furcsa” szavak nélkül a rácsot nem lehet elég sűrűn kitölteni.
• A trágár szavakat külön listával szűrje, amelyet ki lehet kapcsolni, ha a játékos felnőtt tartalmat szeretne.
• Több nyelv esetén csak azt töltse be, amelyen épp játszanak. Az angol szótárban több mint 414 000 szó van. Ha az alkalmazás indulásakor mind a négy nyelvet egyszerre tölti be, egy gyengébb telefon akár 11 másodpercre is lefagy.

#2. lépés: Válassza ki a megfejtést

A megfejtésnek legalább annyi betűből kell állnia, amekkora a rács oldala, és legfeljebb néggyel többől. A rövidebb elveszik a rácsban, a hosszabb túl sok lyukat igényel.

Az alkalmazásunkban a megfejtés egy vicc csattanója. A játékos kihúzza a szavakat, és a maradék betűkből olvassa ki, hogyan végződik a vicc. A megfejtést a vicc végéről állítjuk össze: hátulról teljes szavakat fűzünk hozzá, amíg a hossza ebbe a tartományba nem esik.

Az alábbi képek a „Two snakes walk into a bar. Turns out they were lizards.” angol viccet használják (Két kígyó bemegy egy bárba. Kiderül, hogy gyíkok voltak.), 10×10-es rácson. A megfejtés WERELIZARDS, 11 betű. A képeken szereplő szavak az angol szótárból származnak, a gyakori szavakra szűkítve, hogy olvashatók legyenek.

#Miért ne a megfejtéssel kezdjen

Az első ötlet az, amit ceruzával csinálnánk: a megfejtés betűit olvasási sorrendben véletlenszerű mezőkre szórni, aztán köréjük építeni a szavakat.

Ez ésszerűnek tűnik, amíg el nem jön a vége. A generátor kiválaszt egy üres mezőt, megpróbál rajta keresztül szót elhelyezni minden irányban és eltolással, és amikor a rács besűrűsödik, elszigetelt lyukak maradnak. Egyetlen lyukat két megfejtésbetű között semmi sem tölthet ki, mert a legrövidebb szó hárombetűs, és a megfejtésen szó nem haladhat át.

200 darab 10×10-es rácson ez a megközelítés csak az esetek 28 %-ában adott teli rácsot, átlagosan 1-2 lyuk maradt. Utólag foltozni őket nehéz. Ezért a megfejtést addig ne tegye a rácsba, amíg a szavak el nem készülnek.

#3. lépés: Töltse a rácsot, amíg pontosan N lyuk marad

A kitöltés egy egyszerű greedy algorithm: minden szót azonnal letesz, amint elfér, és többé nem veszi ki. A generátor egyetlen számot követ: hány mező üres még. Csak akkor tesz le egy szót, ha utána nem marad kevesebb üres mező, mint ahány betűs a megfejtés (N).

üres = sorok × oszlopok
amíg üres > N és próbálkozás < 2000:
    szó = véletlen szó a választott hosszal
    legfeljebb 50-szer ismételd:
        kezdet = véletlen mező, irány = véletlen a 8-ból
        ha a szó elfér a rács szabályai szerint:
            új = hány üres mezőt töltene ki a szó
            ha üres - új >= N:
                tedd le a szót
                üres = üres - új
                folytasd a következő szóval
ha üres != N: dobd el a rácsot és kezdd elölről

Az első szavak szabadon kerülnek az üres rácsba:

Ahogy a rács telik, a szavak egyre többször osztoznak betűkön. Ez kifejezetten jó, mert minden közös betű eggyel kevesebb kitöltendő mezőt jelent:

Amikor az üres mezők száma N-re csökken, a kitöltés véget ér. Hogy hol vannak a lyukak, mindegy. Bárhol szétszórva lehetnek, mert a megfejtésnek nem kell rajtuk keresztül összefüggő utat alkotnia:

#4. lépés: Sorsolja okosan a szóhosszt

A hosszú szavak teszik érdekessé a szókeresőt, a rövidek segítenek befejezni. Ezért a hosszt két normális eloszlásból sorsolja (normális eloszlású véletlenszámokat például a Box-Muller-transzformáció ad):

A hossz mindig legalább 3 és legfeljebb a rács oldala. Ehhez két szabály kell, különben a generátor a végén elakad:

• A végén kényszerítse ki a pontos hosszt. Ha a célig 5 vagy kevesebb mező hiányzik, pontosan a hiányzó hosszúságú szót keressen (legalább 3). Különben a generátor a végtelenségig próbálkozik hatbetűs szavakkal, amelyek már nem férnek el.
• A hárombetűs szavakat adagolja. Egy rács első három próbálkozásában egy sem lehet, a 4-6. próbálkozásban egy, a következő háromban kettő, és így tovább. A hárombetűs szótári szavak gyakran rövidítések, például DNA vagy CPU, és a rejtvényben olcsón hatnak. Csak akkor engedje őket, ha másként nem megy.

#5. lépés: Öntse a megfejtést a lyukakba

Járja be a rácsot balról jobbra és fentről lefelé, és minden üres mezőbe írja a megfejtés következő betűjét. Mivel pontosan N lyuk van, a megfejtés maradék nélkül elfér.

A játékos csak ezt látja:

#Ha a rács nem sikerül

Ha a generátor 2000 próbálkozás alatt sem éri el pontosan az N üres mezőt, dobja el az egész rácsot, és kezdje elölről, legfeljebb 100-szor. Nincs lyukfoltozás. Ez durva megoldás, de 12×12-es rácsig bőven elég. Nagyobb rácsokhoz több próbálkozás kell, ahogy a lenti táblázat mutatja.

#Sikerarány és sebesség rácsméret szerint

A generátor méretenként 300 rácson futott, valódi viccekkel és a szlovák szótárral (Node.js 22 szerverprocesszoron, a telefon lassabb lesz; a képek az angol, a számok a szlovák szótárral készültek, mert az kisebb, így szigorúbb teszt). Az „első próbálkozásra” azt jelenti, hogy az első kitöltési kör teli ráccsal ért véget.

Mit jelent ez egy saját generátornál:

• Az átlagos szó 4,7 betűs, pedig a cél 6 körül van. A hosszú szavak egyszerűen gyakrabban nem férnek bele a sűrű rácsba.
• A mezők kb. 9-10 %-án két szó osztozik. Ezt nem kell beállítani, a „legfeljebb egy közös betű” szabályból adódik.
• Kevesebb átló lesz, mint amire számít. Az irányt egyenletesen sorsoljuk a nyolcból, így az átlóknak a szavak felét kellene kitenniük. Kis rácsban viszont az átlós szó sokkal gyakrabban lóg ki a szélén. 8×8-on az átlók a szavak 24 %-át adják, 15×15-ön már 33 %-át. Ha több átlót szeretne, adjon nekik nagyobb súlyt az irány sorsolásakor.

#Tipp: ugyanaz a rács minden futtatáskor

Az áruházi képernyőképekhez minden alkalommal pontosan ugyanarra a rácsra van szükség. Ebben a módban cserélje le a szokásos véletlenszám-generátort egy egyszerű lineáris kongruens generátorra rögzített seeddel (például a nyelvből származtatva). Ha minden számítás abban a tartományban marad, amelyet a JavaScript számai pontosan ábrázolnak, az eredmény minden eszközön azonos. Ugyanezzel a trükkel készültek a cikk képei is.

Ha hasonló problémán dolgozik, rejtvényeket generál, vagy mobilalkalmazásra van szüksége, írjon nekünk. Rövid videókat a fejlesztésből a YouTube csatornánkon is megosztunk. Ugyanígy lépésről lépésre olvasható az is, hogyan generáljunk egyértelmű megoldású sudokut. Ha szókereső helyett keresztrejtvényre van szüksége, olvassa el, hogyan generáljunk svéd rejtvényt megfejtéssel.