LOD для тисяч анімованих персонажів у Unity будуйте за кількістю вершин, а не трикутників: у vertex animation textures анімація рахується для кожної вершини. Нижчі рівні підготуйте вручну, вершини найнижчого рівня приєднайте до поверхні оригіналу, а рівень вибирайте для кожного персонажа окремо. У нашій tower defense грі для ПК це при 3 000 ворогів підняло FPS у наближенні до натовпу з 62 до 120.

Це стосується ігор, де тисячі персонажів рухаються на екрані одночасно: tower defense, стратегій і survival. Наша гра зроблена в Unity з ECS і є в референціях. LOD означає level of detail: віддаленого персонажа малюють із простішої сітки. На зображеннях справжні сітки нашого ворога-скелета, а не кадри з гри.

#Чому згенерований LOD не допомагає натовпу

Unity вміє генерувати рівні LOD під час імпорту моделі (функція Mesh LOD). Для тисяч персонажів це має дві проблеми.

Перша: вигляд. Автоматичне спрощення рвало тонкі кінцівки й ламало UV, тобто прив'язку текстури до сітки.

Друга: ціна анімації. Звичайна скелетна анімація надто дорога для тисяч сутностей, тому замість неї використовують vertex animation textures (VAT). VAT є текстурою, де кожен стовпець належить одній вершині, а кожен рядок одному кадру анімації. Шейдер читає положення вершини з текстури, тож ціна анімації залежить від кількості прочитаних вершин, зокрема й під час малювання тіней.

Верхню межу показує тест із примусовим згенерованим рівнем на всіх персонажах (Unity генерує також рівні 3 і 4, build, 1080p, 3 000 ворогів, тіні ввімкнено):

Запас для прискорення великий. Його треба використати без помітних дірок і стрибків між рівнями.

#Рахуйте вершини, а не трикутники

Удвічі менше трикутників саме по собі майже не допомагає. LOD із половиною трикутників і 996 із початкових 1 521 вершин заощадив 1,9 мс на кадр, LOD із 217 вершинами 6,4 мс. На кожному рівні стежте за обома числами.

Вершин часто буває забагато. Вершина подвоюється на кожному шві UV, бо одне положення тоді потребує двох текстурних координат. Наші моделі з AI-генератора мали UV, порізані на сотні острівців: скелет мав 1 521 вершину, але лише 608 різних поєднань положення й нормалі.

#Крок 1: Зменште кількість вершин у LOD 0

Перша економія не коштує жодної деталі. Об'єднайте вершини з однаковим положенням і схожою нормаллю (різниця до 25°), розгорніть UV заново зі швами лише на гострих ребрах (понад 70°) і перерахуйте текстуру зі старої по трикутниках. Скелет зменшився з 1 521 до 1 090 вершин, інші типи ворогів на 19-29 %, за тієї ж форми.

Потім записуйте у VAT лише стовпці вершин, які справді використовує якийсь рівень. Це заощадило 40-60 % пам'яті анімацій.

#Крок 2: LOD 1 зі спрощення зі спільною текстурою

LOD 1 є LOD 0, спрощеним приблизно до 52 % трикутників. Спрощуйте частинами (кожне поєднання кістки та зв'язної частини сітки) і блокуйте вершини на межах частин. Голові дайте більший бюджет, бо силует голови око впізнає в натовпі.

Важливо залишити текстуру LOD 0. Рівень із власною текстурою або іншою формою видно під час переходу навіть за схожого силуету.

Нижче приблизно 50 % трикутників спрощення з наявних вершин рве тонкі частини й окремі шматки. Далі потрібен інший підхід.

#Крок 3: LOD 2 як нова сітка, приєднана до оригіналу

Найнижчий рівень є новою замкненою сіткою. Потовщіть оригінал шаром, пройдіть voxel remesh і спростіть до цільової кількості (у нас 200-460 трикутників залежно від типу ворога). Результат обтягніть на поверхню оригіналу, UV зробіть автоматично. Текстуру запечіть з оригіналу в тій самій щільності, що й LOD 0, щоб збігалися й mipmap.

Нова сітка не має ваг анімації. Тому кожну її вершину приєднайте до найближчого трикутника оригіналу. Збережіть три стовпці цього трикутника й барицентричні ваги (частки, які задають положення точки в трикутнику).

Стовпець приєднаної вершини у VAT є зваженою сумою положень і нормалей цих трьох вершин у кожному кадрі. Шейдер нічого особливого не робить, приєднана вершина лише ще один стовпець.

для кожного кадру f:
    VAT[приєднана, f] = w0 * VAT[a, f] + w1 * VAT[b, f] + w2 * VAT[c, f]

#Крок 4: Перевіряйте дірки автоматично

Зображення з програми для моделювання надійно дірок не покажуть. Достатньо простої перевірки: відрендеріть оригінал і кандидата з 11 напрямків із роздільністю 120 px і порівняйте силуети.

Діркою вважайте пікселі оригіналу всередині контуру кандидата, які кандидат не покриває, і пікселі кандидата більш ніж на 2 px поза контуром оригіналу. У нас межа 1 % дірок і 4-6 % втрат. Перевірка має враховувати відсікання задніх граней залежно від матеріалу. Межі ми встановили за тим, де переходи в грі було видно оком.

#Крок 5: Вибирайте рівень для кожного персонажа окремо

Перемикання рівня для всієї мапи одночасно помітне. Якщо вибирати для кожної сутності окремо, переходи розподіляються й губляться в натовпі.

Уся мапа одночасно

Для кожної сутності

Застереження щодо версії: документація Unity 6.2 зазначає, що Entities Graphics завжди використовує LOD 0. Вибір для кожної сутності за формулою нижче ми застосовуємо в Unity 6.6, тому заздалегідь перевірте поведінку своєї версії:

LOD = log2(d * C / D) * нахил + зсув
C = поріг * 2 * tan(fov / 2) / висота_кадру

Тут d означає відстань від камери, а D діаметр світових меж сутності. Нахил і зсув підберіть так, щоб рівень 1 починався на 93,3, а рівень 2 на 167,9 метра (камера з fov 30° і 1440 px). Глобальний поріг LOD встановіть на висоту кадру / 1440, тоді відстані не залежать від роздільності.

Дві помилки, яких варто уникати:

• Масштаб. Діаметр D рахуйте зі світових меж, тобто з масштабом prefab. Сітки для VAT часто мають малі одиниці, а prefab збільшує їх у 2-4 рази. Без цього гра весь час малює LOD 0 і нічого не повідомляє. Перевірте це за кількістю трикутників у звичайному режимі порівняно з примусовим LOD. Поворот сутності збільшує осьові межі, тому в нас діаметр множиться на коефіцієнт 1,22.
• Запікання. Крива вибору зберігається під час запікання SubScene, і запікання не помічає зміни в сітці. Після її редагування примусово перезапечіть SubScene.

#Результати й обмеження

Build для macOS, 2560 × 1440, 3 000 ворогів, тіні ввімкнено, гра зупинена після поразки (анімації VAT далі працюють, тож вимірювання дійсне для графіки):

На Steam Deck (1280 × 800, 8 обчислювальних блоків RDNA 2) це 75-80 FPS на всій мапі. Найближчий кадр у натовпі має 33 FPS із високою якістю тіней та 64 без тіней. Тіні, отже, найбільша стаття витрат: LOD знижує і їхню ціну, але вимкнення все одно дає великий стрибок.

Чого LOD не вирішує: перевірка дірок працює в T-позі, тож не помітить розтягнення в екстремальних позах. Один тип ворогів досі перевищує межу дірок у LOD 2. На обчислення руху орди LOD не впливає, про це стаття про навігацію орди в Unity DOTS, про реакції на вибухи fake ragdoll.

Потрібна допомога з продуктивністю гри в Unity або симуляцією натовпу? Напишіть нам.

Стара 2D-гра на Unity з вбудованим render pipeline на сучасному телефоні виглядає пласко: освітлення немає, glow або відсутній, або підсвічує весь кадр разом з UI, а sprite інтерфейсу розмиті. В Unity URP це вирішують три речі: Bloom з порогом 1 та HDR-колір лише на об'єктах, які мають світитися, 2D-світло з 2D renderer і UI з більшими sprite, що враховує безпечну зону екрана.

Покажемо це на нашій грі Dreamica (App Store, Google Play). Це пригода з падінням, у якій ви малюєте пальцем лінії й ведете ними бульбашку зі сплячою дитиною крізь чотири світи. Спочатку гру створили в Unity 5.3, UI працював на плагіні NGUI, glow давав плагін MK Glow, а графіку готували для iPhone 7 з екраном 1334 × 750 пікселів. Геймплей лишився тим самим, змінилася тільки графіка.

Стару гру часто відкривають через магазин, а не через графіку. Google Play з серпня 2019 року вимагає 64-бітні версії, і гра лише з 32-бітним build з нього зникає. Саме так сталося з Dreamica. Якщо ви все одно переносите проєкт на Unity 6, графіка стає відносно дешевим бонусом.

#Чому старого повноекранного glow недостатньо

Старші glow-плагіни працюють як повноекранний ефект. Вони підсвічують усе світле, зокрема іконки кнопок у меню. У Dreamica під MK Glow в Unity 6 іконки майже зникли. Офіційний пакет Post Processing Stack v2 замінює його лише для вбудованого pipeline, в URP він уже не застосовується. Якщо вам потрібен glow, яким можна керувати для кожного матеріалу, і динамічне 2D-світло, переходьте на URP і використовуйте вбудований у нього Bloom.

#Крок 1: Переведіть проєкт на URP

Після переходу на URP стара 2D-гра майже напевно натрапить на дві пастки. Обидві виглядають так, ніби картинка зламана або точно така сама, як раніше, хоча shader у порядку.

#Сірий екран: налаштуйте camera stack

Якщо вікно Game в Editor показує лише сіру площину, а вікно Scene і одноразовий рендер камери виглядають правильно, проблема не в shader, а в тому, як поєднуються камери. Старі ігри часто мають дві камери, одну для світу й одну для UI, причому камера UI очищає лише глибину. Так камери накладаються у вбудованому pipeline, і URP цього не підтримує. Йому потрібен явний camera stack: одна камера базова (Base), інші є накладками (Overlay) у її стеку. Налаштуйте його в кожній сцені, де камери накладаються.

#Sprite ігнорують світло: перейдіть на 2D renderer

Sprite з освітлюваним shader не реагують на жодне світло, якщо активний звичайний URP renderer. Він узагалі не обчислює 2D-світло. Перейдіть на 2D renderer. Але й він не малює освітлення, поки в сцені немає хоча б одного 2D-світла. Коли після зміни щось виглядає точно як раніше, спершу перевірте, який renderer працює.

#Частинки та старі плагіни

Частинки на старих shader під 2D renderer малюються чорними або не малюються зовсім. Дайте їм новий простий shader.

Обережно з Asset Store. Під час оновлення assets Editor може сам застосувати «оновлення» старого плагіна, яке додає метадані й перейменовує shader. Матеріали шукають shader за назвою, тож тихо ламаються. Після кожного більшого оновлення assets у старому проєкті перегляньте в системі контролю версій усі змінені файли, навіть ті, з якими зараз не працюєте.

#Крок 2: Вибірковий glow через HDR-колір і Bloom з порогом 1

Мета в тому, щоб світилися вибрані об'єкти, у Dreamica це намальована лінія, лазери, іскри, світлячки й руни, але не фон і UI. Bloom в URP розмиває й додає все, що яскравіше за його поріг. Встановіть поріг 1 і підніміть колір матеріалів, які мають світитися, вище 1.

shader лінії:
    колір = текстура × колір вершини × відтінок × інтенсивність    (інтенсивність = 6)

Bloom:
    поріг = 1, сила = 0,3
    світиться лише те, що після обчислення яскравіше за 1

Фон і кнопки мають кольори від 0 до 1, не проходять поріг і лишаються чіткими. Так зникає й проблема з вибіленими іконками. Умова: камера з HDR. Без нього колір обрізається до 1 і нічого не світиться. 2D renderer не показує перемикач HDR в інспекторі камери, тому увімкніть його скриптом.

Низький поріг, увесь кадр

Поріг 1, HDR-матеріал

Коли glow так контрольований, він не мусить бути опціональним. У Dreamica ми прибрали перемикач glow з налаштувань, glow є частиною вигляду гри.

#Карта емісії: світиться лише частина sprite

Якщо має світитися лише частина sprite, додайте йому карту емісії (emission map): другу, чорно-білу текстуру, яка позначає, яка частина sprite світиться. Лише ця частина отримує колір понад 1, тож у руни сяє серцевина, а не весь контур.

#Пульсація в ступенях експозиції

Якщо світіння має пульсувати, не множте колір лінійно. HDR-матеріал може мати яскравість близько 2 у восьмому степені, і лінійний множник від 0 до 10 на ньому взагалі не помітний. Рахуйте пульс у ступенях експозиції (EV), так само як повзунок інтенсивності у виборі HDR-кольору в Unity:

колір = відтінок × 2 ^ ev,   ev коливається між мінімумом і максимумом

#Крок 3: Динамічне 2D-світло навколо гравця

Додайте гравцеві точкове 2D-світло з м'яким ореолом навколо. У Dreamica одна синусоїда водночас керує яскравістю ореолу, радіусом світла та його інтенсивністю, тож вони пульсують разом. Колір світла може задавати середовище: у лісі білий, на болоті помаранчевий, узимку фіолетовий, у пеклі жовтий. Переведіть фон і перешкоди на освітлювані shader, інакше вони не реагують на світло.

Короткі спалахи світла оживлюють події. Коли стріляє білка з гарматою, спалахує бурштинове світло з інтенсивністю 3, яке гасне за 0,3 секунди, а іскри з дула світяться. Світитися має не все: пил, коли зникає жолудь, навмисно коричневий і не світиться.

#Однаковий shader на суміжних поверхнях

Якщо два фони стикуються, вихідні зображення мають однакову яскравість, а шов між ними все одно видно, перевірте shader. У Dreamica початковий фон і нескінченний фон лісу мали різні shader. Один ігнорував відтінок матеріалу 0,733, другий застосовував його й затемнював ліс до 73 %. Рішення: однаковий shader на обох поверхнях.

Два shader

Один shader

#Спалах: перехід до піку замість додавання

Під час переходу до наступного світу світло й ореол спалахують: наростання 0,6 секунди, коротке утримання, згасання 1,4 секунди, і ореол при цьому один раз обертається. Якщо просто додати спалах до пульсу, пік залежить від того, у якій фазі саме зараз синусоїда, і кожен спалах має іншу силу. Натомість плавно переходьте від пульсу до фіксованого піку:

вага = крива спалаху (від 0 до 1)
значення = пульс + (пік - пульс) × вага

Додавання

Перехід до піку

#Крок 4: Чіткий UI для сучасних екранів

UI, намальований для iPhone 7, має малі sprite. Кнопка меню в Dreamica мала sprite 128 × 64 пікселі й на телефоні з утричі більшою щільністю пікселів розтягувалася в кілька разів. Перемалюйте sprite у вищій роздільності: нова кнопка має 800 × 434, індикатори прогресу виросли з 200 × 26 до 800 × 104.

128 × 64

800 × 434

Якщо UI побудований на NGUI, подумайте про переписування. Якорі NGUI обчислюються частинами протягом кількох кадрів, довгі ланцюжки якорів іноді встановлюються неправильно, а масштаб різниться між Editor, телефоном та iPad. У Dreamica виправлення не зробили це надійним, тому ми переписали UI на uGUI і TextMeshPro. Рухайтеся екран за екраном, а стару версію тримайте запущеною поруч як зразок. Масштабуйте UI за висотою відносно референсної роздільності (у нас 434 × 941 точок) і враховуйте безпечну зону екрана, тобто виріз і заокруглені кути. Після переписування повністю видаліть NGUI з проєкту, щоб у ньому не лишилося двох систем UI.

#Обмеження: нестиснуті текстури

Цей підхід змінює лише графіку. У Dreamica ми свідомо не стискали текстури, бо хотіли повної чіткості. Ціна в розмірі: уже оригінальна гра мала в Editor 313 МБ текстур у пам'яті, а в App Store вона займає 299 МБ. За нашою оцінкою, стиснення зменшило б текстури приблизно до 40 МБ. Якщо розмір гри для вас важливий, економте спершу тут.

Інший приклад гри на Unity від першого рядка коду до релізу описано в статті про Space Impact Watch, а продуктивності в Unity присвячена стаття про навігацію орди в Unity DOTS. Якщо гра ще на Unity 4, не відкривайте її одразу в Unity 6; безпечний шлях описано в інструкції як перенести проєкт з Unity 4 на Unity 6. Якщо у вас є стара гра на Unity, яка зникла з магазинів, і ви хочете її повернути, напишіть нам.

Коли вибух у грі відкидає сотні ворогів одночасно, справжній ragdoll для кожного з них надто дорогий. Fake ragdoll в Unity DOTS робиться так: усе тіло ворога ви симулюєте як одну точку з власною простою фізикою, а модель лише обертаєте навколо центру тіла. Падіння та підйом є звичайними анімаційними кліпами, кістки не симулюються взагалі.

Підхід показуємо на tower defense грі для ПК, яку ми робимо в Unity з ECS (більше в референціях). Бомба або fireball там підкидає від десятків до сотень ворогів одночасно. Коли в повітрі 2 000 тіл, симуляція коштує від 0,53 до 0,59 мс на тік (тік є одним кроком ігрової симуляції фіксованої тривалості).

#Чому не справжній ragdoll

Справжній ragdoll означає десять і більше фізичних тіл, з'єднаних суглобами, на кожного персонажа. Для тисяч персонажів на екрані це нереально.

Друга причина в детермінізмі: з того самого стану має виходити той самий результат. У нашій грі на цьому тримається повтор програної хвилі з контрольної точки, і ми перевіряємо це хешем стану симуляції після 1 800 тіків.

#Тіло як одна точка

Замість фізичного рушія використайте власну просту 2,5D фізику: позиція на сітці, висота над землею, балістичний політ, відбиття від стін і тертя. У нашій грі так рухається й бомба, а ворог, у якого влучив вибух, на мить стає таким самим тілом. Натхненням було те, як відлітають солдати в грі Diplomacy is Not an Option.

Симуляція знає лише позицію, висоту й кут повороту. Обертання моделі в неї не записуйте. Воно належить до додаткової матриці трансформації сутності, яку пакет Entities (ECS в Unity) підтримує для нерівномірного масштабу (документація).

#Фази збитого ворога

Збитий ворог проходить три фази й потім повертається в натовп:

при влучанні:
    обчисли швидкість підкиду (сила, відстань від вибуху, випадковість із seed)
    знайди приземлення на прохідну клітинку (див. нижче)
    увімкни стан "збитий", звільни місце, яке він займав біля цілі атаки
політ:        тіло летить параболою, модель обертається навколо центру тіла
приземлення:  положення за кутом (спина або живіт), коротке докочування
лежання:      чекає фіксовану кількість тіків
підйом:       кліп підйому зі спини або з живота, потім назад у натовп

Зробіть стан «збитий» компонентом, який можна вмикати й вимикати без переміщення сутності між chunk (блоками пам'яті, у яких ECS тримає сутності з однаковим набором компонентів). Навігація, розштовхування в натовпі та рішення про атаку тоді просто пропускають збитих. Як працюють навігація й розштовхування великого натовпу, описує стаття про навігацію орди в Unity DOTS.

#Підкид: вище, а не далі

Найпростіший підкид іде під кутом 45° ± 10°. За сили бомби 18 м/с і гравітації 20 м/с² вершина польоту виходить близько 4 м. Тіло пролітає низько над натовпом, і ефект у ньому губиться.

Більша сила не допоможе, бо разом із нею зростає й дальність. Розділіть швидкість на дві складові й множте кожну окремо: кут 60° ± 5°, горизонтальна складова × 0,85, вертикальна × 1,3. Вершина тоді близько 10 м, дальність лишається близько 15,5 м, а політ триває приблизно 2 секунди.

Напрямок відхиляється від вибуху на ± 15°, сила на ± 20 %, а на краю вибуху вона падає вдвічі. Не беріть випадковість із глобального генератора, а виводьте її з хешу seed рівня, ідентифікатора ворога й порядкового номера вибуху. Обробляйте запити на збиття відсортованими, бо job на кількох потоках створюють їх у довільному порядку. Два проходи тієї самої хвилі тоді дають ті самі дуги.

Збиття працює за принципом так або ні. Кожен ворог, якого можна збити, при влучанні щонайменше падає (швидкість обмежена знизу 2 м/с), опір змінює лише дальність. Імунітет давайте окремим прапорцем, у нашій грі його має найбільший тип ворога. Якби імунітет випливав з опору (при 0,95 швидкість виходить нижче 2 м/с), а слабке відкидання скасовувалося, ворог мав би імунітет лише випадково.

#Приземлення на прохідну клітинку

Ворог не має приземлитися в ущелину, на скелю чи в контур вежі. Прохідність визначається для кожної клітинки сітки й окремо для кожного розмірного класу ворогів.

#Відбиття від стін у повітрі не вистачає

Перше, що спадає на думку, це вважати непрохідні клітинки стінами, від яких летюче тіло відбивається. Біля скелі це виглядає природно, біля ущелини ні: над ущелиною повітря, але клітинка непрохідна, тож тіло відбивається від невидимого стовпа над її краєм. До того ж ніщо не гарантує, що після відбиття воно опиниться в доброму місці.

#Передбачення траєкторії під час підкиду

Надійніше визначити приземлення одразу під час підкиду. Просимулюйте політ наперед тим самим кроком, що й справжню фізику, і перевірте клітинку приземлення для розмірного класу ворога. Якщо вона непрохідна, пробуйте інші варіанти у фіксованому порядку:

для кута в [0, +25, -25, +50, -50, ... , +175, -175]:
    для множника горизонтальної швидкості в [1, 0.7, 0.4, 0.1]:
        просимулюй політ
        якщо клітинка приземлення прохідна для класу ворога: візьми цей напрямок і кінець
якщо нічого не підійшло: горизонтальна швидкість = 0 (підскок на місці)

Найгірший випадок становить 60 симуляцій польоту на одного ворога (15 напрямків × 4 множники). Вертикальна швидкість не змінюється, тож висота польоту лишається тією самою, скорочується лише дальність. Якщо під час польоту ворога влучить ще один вибух, запустіть передбачення знову.

Щоб тіло після приземлення не ковзало й не відскакувало, задайте йому коефіцієнт відбиття від землі 0 і велике тертя. Воно лишиться там, де сказало передбачення.

#Обертання, сплановане за висотою польоту

Найпростіше крутити модель із випадковою швидкістю, наприклад від 180 до 540 °/с, а після приземлення за 0,2 с докотити її в найближче лежаче положення. Проте докочування видно, коли тіло приземляється майже вертикально. Підлаштовувати швидкість обертання щотіку так, щоб кут у момент приземлення виходив точно горизонтальним, допомагає лише частково: навіть низький кидок крутиться як сальто, а обертання ніяк не пов'язане з тим, як високо летить тіло.

Краще спланувати обертання під час підкиду з висоти польоту:

висота = vz² / (2 g), час польоту з vz і висоти
ціль = найближче горизонтальне положення у випадковому напрямку (чверть оберту зі стійки)
ціль += пів оберту за кожні 2,5 м висоти, не більше 3
швидкість обертання = (ціль - поточний кут) / час польоту

Сторона приземлення випливає з кута: обличчям до землі означає живіт, інакше спина. За нею вибирається кліп підйому. Ворог, що лежить або підводиться, при наступному влучанні зберігає поточний кут і не стрибає назад у вертикальне положення.

#Модель на землі

Модель обертається навколо центру тіла, але земля під її найнижчою точкою, а та змінюється з обертанням. Оцінка зсуву з двох констант і синуса кута не підходить для моделей із широко розкинутими руками в кліпі падіння: у нашій грі модель скелета (звичайний ворог) занурювалася в землю до 1,15 м, а модель некроманта до 1,73 м.

Оцінка

Виміряно

Надійніше найнижчу точку виміряти. Під час запікання (bake) анімацій обчисліть для кліпу падіння найнижчу точку тіла для 72 поворотів із кроком 5°, а під час гри інтерполюйте з таблиці. Найглибше занурення тоді зменшується до 4 мм. Проте одного мінімуму по всіх кадрах кліпу не досить: тіло після приземлення висіло б на висоті від 0,15 до 0,28 м над землею, доки кліп підйому не стягне його вниз. Тому таблиця має мати розмір кадри × повороти.

Повільне сплановане обертання виявляє ще один ефект. Якщо класти модель найнижчою точкою на висоту польоту, центр тіла під час переходу зі стійки в горизонталь опускається на різницю між половиною зросту й половиною товщини персонажа. Тіло тоді на початку польоту піднімається лише повільно й тільки потім прискорюється. Тому підніміть модель на різницю між половиною розміру в стійці та за поточного кута, але не більше ніж на висоту польоту. Тоді центр тіла йде параболою.

#Мертві вороги: тіло, decal і пил

Ворог, убитий вибухом, теж має відлетіти. Створіть для нього летюче тіло: копію сутності без ігрових компонентів (здоров'я, нагорода, ціль). Тіло пролітає, падає, якийсь час лежить і зникає. На його місці лишається decal трупа (текстура, спроєктована на землю), як у Warcraft 3, і хмарка пилу. У нашій грі ліміти становлять 1 000 летючих тіл і 1 500 decal.

Decal є виглядом згори на кадр із кліпу падіння, поверненим так само, як лежаче тіло, тож заміни тіла на decal не видно. Перший кадр кліпу підйому не підходить, бо в ньому персонаж уже сідає зі спини. Об'єднуйте хмарки пилу в межах клітинки 1,5 м. Бомба в натовп тоді створює кілька більших хмар замість сотень дрібних.

#Пастки в Unity Entities

• Матриця з baker зникає. Якщо додати додаткову матрицю під час bake, система трансформацій прибирає її за рівномірного масштабу, і збиті вороги не рухаються. Тому під час bake запросіть нерівномірний масштаб. Тоді, однак, увесь масштаб prefab переходить у ту саму матрицю, тож не перезаписуйте її самим обертанням. Інакше збитий ворог зі збільшенням 2× має половинний розмір навіть після підйому. Зберігайте масштаб окремо й складайте матрицю з масштабу та обертання.
• Висота кореня під час імпорту кліпів. У humanoid кліпах вертикальний рух кореня (root) відкидається, і персонажі під час підйому провалюються під підлогу. Запечіть висоту кореня в позу. Опцію прив'язати позу до стоп не використовуйте, вона зсуває все тіло на метр униз.
• Матриця в замкненому вигляді. Зсув, обертання й зворотний зсув як три множення матриць у job помітно повільніші за вручну написану формулу підсумкової матриці.
• Burst зі старою версією. Після зміни полів компонента, який читає Burst job, редактор може падати або видавати нісенітниці. Допомагає перезапуск редактора.

#Продуктивність

Виміряно в Unity Editor на M3 Pro, 10 000 скелетів у бенчмарк-сцені, сила підкиду 18. Часи є сумою процесорного часу Burst job по всіх потоках, а не часом кадру. Графік і таблиця без передбачення траєкторії й таблиць приземлення.

• Симуляція зростає лінійно, приблизно на 0,25 мс на тисячу збитих. З передбаченням траєкторії й таблицями приземлення це від 0,58 до 0,59 мс для 2 000 збитих, тобто трохи вище цілі 0,5 мс. Тому розумний ліміт становить 3 000 одночасно збитих, це близько 0,8 мс.
• Вибух у групу з 359 ворогів біля стіни коштує в системі запитів на збиття від 1,3 до 1,9 мс за один кадр. Більшу частину займає передбачення траєкторії.
• FPS з редактора порівнювати не можна: два проходи тієї самої конфігурації відрізнялися аж на 80 FPS.

#Обмеження рішення

Підготовка візуалу в іншій тестовій сцені зросла аж до 1,3 мс, імовірно через читання таблиці приземлення для кожного тіла. Це перший кандидат на оптимізацію. FPS у білді й навантаження під час масового вбивства 1 000 ворогів одночасно (ціль щонайбільше 1,5 мс додатково на кадр) ми ще не вимірювали.

Якщо ви працюєте над схожою симуляцією натовпу чи ефектів у Unity і потребуєте допомоги, напишіть нам.

Shmup (shoot 'em up, стрілялка, у якій корабель летить проти хвиль ворогів) на Apple Watch стикається з трьома проблемами: малий дисплей, палець, що закриває половину гри, і годинники різних розмірів. Їх вирішують три рішення: уся гра працює на фіксованій сітці 84 × 48 точок, колізії перевіряються вручну прямокутниками, а рівні є таблицями з часом, а не кодом. Корабель керується коронкою Digital Crown і стріляє сам.

Приклади взято з гри Space Impact Watch, ремейку стрілялки Space Impact з телефона Nokia 3310 2000 року. Гра працює на годиннику, а також на iPhone та iPad. Вона побудована на SpriteKit, 2D-фреймворку для ігор від Apple, але принципи підходять для будь-якого shmup на малому екрані.

#Фіксована віртуальна роздільна здатність 84 × 48

Спочатку вирішіть, у яких одиницях рахуватиме гра. Якщо взяти точки екрана, світ на кожному розмірі годинника буде різним. Краще вибрати малу віртуальну роздільну здатність і все рахувати в ній. У нашій грі це 84 × 48, точно як дисплей Nokia 3310. Позиції, швидкості, розміри sprite і траєкторії ворогів задані в цих одиницях. На старті сцени один раз обчислюється, скільки точок екрана має один віртуальний піксель (ширина сцени поділена на 84), і все просто множиться на це число.

Що ви отримуєте:

• Однаковий вигляд на кожному пристрої. Гра виглядає однаково на годиннику будь-якого розміру і на iPad, змінюється лише розмір блока.
• Level design у малих цілих числах. Ворог летить на висоті 13, ракета повертає в точці x = 20.
• Просту графіку. Sprite одноколірні й намальовані в десятикратному розмірі, тож один віртуальний піксель у вихідному зображенні є блоком 10 × 10. Колір вони отримують уже в грі: на світлих рівнях чорні на зеленому тлі, на темних навпаки.

#Керування коронкою і автоматичний вогонь

На годиннику палець закриває половину гри, тому корабель не керується дотиком. Рух забезпечує Digital Crown: поворот коронки зсуває корабель угору або вниз. Додайте налаштування чутливості й можливість інвертувати напрямок.

Стрільба автоматична, у нашій грі кожні 0,4 секунди, з четвертого рівня кожні 0,3. Дисплей потрібен лише для одного жесту: свайпом праворуч гравець застосовує один із трьох видів спецзброї.

На годиннику вібрація при влучанні так само важлива, як анімація, маленький вибух на дисплеї легко пропустити. Викликайте тактильний відгук через один інтерфейс (влучання, знищення ворога, перемога над босом), який кожна платформа реалізує по-своєму: годинник вібрацією, iPhone власним способом. Версія для телефона не має коронки, натомість має кнопки на дисплеї з тими самими налаштуваннями чутливості й напрямку.

#Game loop в одній сцені

Уся гра може бути однією сценою з одним циклом:

щокадру:
    перемісти всі об'єкти
    перевір колізії
    залежно від часу на рівні додай нових ворогів

Додавайте частини в такому порядку, щоб якомога раніше їх тестувати:

• Стрільба і рух гравця. Без них нічого не протестуєш.
• Вороги і колізії. Першому ворогу достатньо летіти прямо ліворуч і гинути від одного влучання.
• Вібрація і анімації влучання. Без них на малому дисплеї гравець не знає, що влучив.
• Тло і HUD. Життя, рахунок, кількість спецзброї. Якщо HUD на якомусь рівні заважає, перенесіть його вниз.

У результаті маєте ігровий цикл із життями, рахунком, вибухами, тлом і respawn гравця. Якщо тримати ігрову логіку окремо від рендерингу та введення, її можуть спільно використовувати версії для годинника й телефона.

#Колізії прямокутниками замість фізичного рушія

SpriteKit має фізичний рушій, і його кортить використати й для колізій. Кожен об'єкт отримує фізичне тіло з контуру свого sprite, точне виявлення колізій і категорію (гравець, ворог, куля, спецзброя), а рушій сам повідомляє пари, що торкнулися. Apple у документації про фізичні тіла зазначає, що тіла з альфа-каналу текстури найточніші й водночас найдорожчі для обчислень. У нашій грі ми це спробували й повернулися до ручної перевірки.

Ручна перевірка є однією функцією, яка по черзі проходить пари груп і порівнює прямокутники:

для кожної пари груп:
    (гравець і вороги, гравець і кулі, кулі й вороги, кулі й кулі)
    для кожного об'єкта A з першої групи та об'єкта B з другої:
        якщо прямокутник A перекривається з прямокутником B:
            обробити влучання

Переваги: порядок перевірок під вашим контролем, а все правило «що стається при влучанні» зібране в одному місці. Неточність мала, бо на сітці 84 × 48 sprite такі дрібні, що прямокутник і справжній контур відрізняються лише на кілька віртуальних пікселів.

#Pooling лише там, де він окупається

Pooling означає, що об'єкт після знищення ви не видаляєте, а ховаєте й наступного разу використовуєте знову. Кортить застосувати pooling до всього, разом із вибухами та power-up. Але це має ціну: кожна колізія і кожне оновлення спершу мусить перевірити, чи об'єкт узагалі живий. Досить однієї забутої перевірки, і прихований ворог уб'є гравця або прихована куля зіб'є ракету. Коли ми в нашій грі прибирали pooling з усього, видаляли переважно саме ці перевірки.

Просте правило: застосовуйте pooling до того, чого багато і що завжди створюється однаково. Гравець на старті створює 21 кулю і далі лише використовує їх повторно. Вороги та їхні кулі теж використовуються повторно, а вибухи й power-up створюються і зникають звичайним способом.

#Рівні як таблиці часу

Рівень не мусить бути кодом, досить списку записів. Кожен запис каже, що з'явиться, на якій секунді, на якій висоті і як рухатиметься. Рух є списком точок, через які ворог летить зі сталою швидкістю. За потреби додаються моменти пострілів, ривок боса або генератор менших ворогів.

щокадру:
    час = зараз - початок рівня - час на паузі
    для кожного запису в таблиці рівня:
        якщо запис ще не використано і час > запис.час:
            створи об'єкт за записом
            познач запис як використаний

Такий рівень легко налаштовувати: зсунути хвилю на пів секунди означає змінити одне число. На часовій шкалі видно й ритм, якого треба досягти: коротка хвиля, пауза, інший тип ворога, power-up перед складнішою ділянкою.

Недолік відчувається при більших змінах. Найщільніший рівень нашої гри має 71 рядок, і таку таблицю без редактора читати важко. Вигідніше записувати рівні як хвилі (група ворогів з одним шаблоном руху), а не як окремі кораблі.

#Нескінченний режим з одного псевдовипадкового числа

Для таблиці лідерів (у нашій грі Game Center) потрібен режим, який не закінчується. У ньому ручну таблицю замінює генератор, що створює її під час гри. Він генерує 20-значне псевдовипадкове число, і окремі пари цифр визначають одну хвилю:

число = наступне псевдовипадкове 20-значне число
тип = power-up, якщо цифри 4-5 > 90, інакше ворог
sprite = цифри 1-2 за модулем кількості видів ворогів
пауза перед хвилею = цифра 3 / 2 секунди (щонайменше 1)
висота = цифра 7, перерахована на висоту поля
шаблон руху = цифри 10-11 за модулем 10
кораблів у хвилі = цифра 17 / 2 + 1
швидкість = цифра 13 × (1 + номер хвилі / 10), у межах від 20 до 50
кожна тридцята хвиля = бос, генерація стоїть, поки бос живий

Залиште seed (початкове значення) генератора в грі фіксованим. Тоді кожен гравець отримає однакову послідовність хвиль, і результати в таблиці лідерів можна порівнювати.

Як розвивається такий режим, показує симуляція генератора поза грою (300 хвиль, той самий seed, що й у грі). Перший бос з'являється після 29 хвиль, тобто після 74 ворогів і 3 power-up, приблизно на 130-й секунді. Перші 30 хвиль летять із мінімальною швидкістю 20, бо одна цифра ще менша за нижню межу. Далі середня швидкість зростає до 28,5, 37,5 і 41, а від 120-ї хвилі більшість ворогів летить на максимумі. Power-up випадає приблизно кожну одинадцяту хвилю.

Слабке місце: генератор не знає ритму. Ручний рівень чергує тиск і відпочинок, генератор ні. Частково це компенсують пауза під час боса і зростання швидкості, але рівні, написані вручну, грати цікавіше.

#Обмеження цього підходу

• Немає автоматичних тестів. Усе перевіряється вручну в симуляторі й на годиннику.
• Глобальний стан. Більша частина стану гри є глобальними змінними однієї сцени. Для гри лише на годинник це зручно, а при додаванні версії для iPhone вже ні.
• Рівні без редактора. Таблицю часу легко налаштовувати малими кроками, але для більших змін їй бракує редактора.

Якщо ви робите гру для годинника чи іншого маленького екрана і вам потрібна допомога, напишіть нам. Як ми генеруємо головоломки в іншому нашому застосунку, ми описали в статті про генератор судоку.

Судоку з єдиним розв'язком генерується у два кроки. Спершу повністю заповніть порожню сітку 9×9 за допомогою backtracking, пробуючи цифри у випадковому порядку. Потім по одній і у випадковому порядку видаляйте клітинки й після кожного видалення перевіряйте за допомогою solver, чи має головоломка досі рівно один розв'язок. Якщо ні, поверніть цифру назад. На звичайному процесорі це займає в медіані менше мілісекунди.

Цей метод підходить для будь-якої гри чи застосунку, яким потрібна необмежена кількість нових головоломок без ручної підготовки. Приклад із практики: судоку в нашому застосунку з кросвордами та головоломками (App Store, Google Play).

#Чому рівно один розв'язок

Правила знають усі: у кожному рядку, стовпці та квадраті 3×3 кожна цифра від 1 до 9 трапляється рівно один раз. Рідше кажуть, що хороша головоломка має єдиний розв'язок. Лише тоді її можна розв'язати чистою логікою, без вгадування.

Це має й практичний наслідок. Гра зазвичай зберігає один розв'язок і за ним перевіряє результат та дає підказки. Якщо розв'язків два, гравець може дійти до іншого, такого ж правильного, і гра його не зарахує.

#Крок 1: Напишіть швидкий solver

Solver є програмою, яка розв'язує судоку. Він працює методом backtracking (перебір із поверненням): ставить у клітинку одну з можливих цифр, переходить до наступної клітинки, а коли натрапляє на суперечність, повертається й пробує іншу цифру. Він знадобиться двічі: щоб заповнити порожню сітку і щоб перевіряти єдиність. Перевірка запускається після кожної видаленої клітинки, тобто 40-70 разів на одну головоломку, тож вона має бути швидкою. Значення мають дві речі:

• Бітові маски. Для кожного рядка, стовпця й квадрата зберігайте 9-бітне число з уже використаними цифрами. Кандидати клітинки, тобто цифри, які ще можуть у неї потрапити, тоді обчислюються однією операцією: усі цифри, крім тих, що вже є в її рядку, стовпці чи квадраті. Кількість кандидатів дорівнює кількості одиничних бітів, і її можна заздалегідь обчислити в таблицю з 512 значень.
• Спершу клітинка з найменшою кількістю кандидатів. Беріть не першу порожню клітинку зліва, а ту, де найменше варіантів (у літературі евристика MRV, minimum remaining values). Клітинку з одним кандидатом заповнюйте одразу, клітинка без кандидатів означає мертву гілку, і ви повертаєтеся назад.

На складних головоломках перевірка єдиності з цим правилом потребує в медіані 311 кроків. Якщо solver бере клітинки по черзі зліва направо, в медіані 28 579 кроків, а в найгірших 5 % випадків понад 300 000. Різниця приблизно у 90 разів.

#Крок 2: Заповніть усю сітку

Повну сітку дає той самий solver, запущений на порожній сітці. Єдина відмінність: кандидатів клітинки ви пробуєте у випадковому порядку. Перший знайдений розв'язок і є випадковою, правильною, повністю заповненою сіткою.

#Чому не досить видалити випадкові клітинки

Найпростіша ідея: видалити з повної сітки N випадкових клітинок, наприклад 40, 50 або 55 залежно від складності. Головоломка виглядає нормально, тільки часто має не один розв'язок.

На зображенні типовий випадок. Чотири клітинки в кутах прямокутника, що зачіпає два квадрати, можна заповнити двома способами, і решта сітки цього не вирішує. Любителі судоку знають цей візерунок як deadly pattern. На 1 000 головоломках для кожної складності результат такий:

Складна головоломка з випадкового видалення має в середньому сотні розв'язків. Тому перевірка єдиності після кожного видалення обов'язкова.

#Крок 3: Видаляйте з перевіркою єдиності

Пройдіть усі 81 клітинку у випадковому порядку. Спробуйте спорожнити кожну й порахуйте розв'язки за допомогою solver, але зупиніть підрахунок на двох. Більше знати не треба: один розв'язок означає, що клітинка може лишитися порожньою, два означають, що її треба повернути.

головоломка = копія повної сітки
порожніх = 0
для кожної клітинки у випадковому порядку:
    якщо порожніх == ціль: кінець
    цифра = головоломка[клітинка]
    головоломка[клітинка] = порожньо
    якщо кількість_розв'язків(головоломка, не більше 2) == 1:
        порожніх = порожніх + 1
    інакше:
        головоломка[клітинка] = цифра

Клітинку, яку ви раз повернули, більше не пробуйте. Подальше видалення лише послаблює головоломку, тож клітинка, яку не вдалося спорожнити зараз, не спорожниться й пізніше.

#Крок 4: Задайте складність кількістю порожніх клітинок

Найпростішою мірою складності є кількість видалених клітинок. Три рівні, які ми використовуємо в нашій грі:

Що менше цифр залишається, то частіше наступне видалення зламало б єдиність і клітинку доводиться повертати. На складному рівні один прохід іноді зупиняється раніше, ніж досягне 55 порожніх клітинок. Тоді згенеруйте нову повну сітку й спробуйте знову. У вимірюванні на 1 000 складних головоломках першого проходу вистачило в 97,6 % випадків, і жодного разу не знадобилося більше 3 спроб.

#Швидкість і надійність генератора

Ми запустили генератор на 1 000 головоломках для кожної складності (Node.js 22 на серверному процесорі, телефон буде повільнішим):

Крім того, кожну згенеровану головоломку ми незалежно перевірили за допомогою solver. Усі 3 000 мали єдиний розв'язок.

#Коли кількості порожніх клітинок не досить

Кількість підказок є грубою мірою складності. Дві головоломки з 26 цифрами можуть бути різної складності залежно від того, яких логічних прийомів вони вимагають. Точніша оцінка розв'язувала б головоломку як людина й фіксувала найскладніший прийом, який довелося застосувати. Для мобільної гри, де гравець обирає один із трьох рівнів, кількості підказок достатньо.

Якщо ви розв'язуєте схожу задачу, генеруєте головоломки або вам потрібен мобільний застосунок, напишіть нам. Як згенерувати пошук слів із зашифрованим словом, описано в окремій інструкції. Сканворду із зашифрованим словом присвячена ще одна інструкція.

Сканворд (шведський кросворд) із зашифрованим словом можна згенерувати у дві фази: спершу локальним пошуком знайдіть маску, тобто розташування клітинок із питаннями і клітинок для літер, а потім заповніть її словами зі словника як задачу з обмеженнями (CSP) за допомогою backtracking. Не ставте зашифроване слово в сітку заздалегідь. Лише коли кросворд готовий, шукайте жарт, чию пуанту можна прочитати в ньому зліва направо і згори донизу.

Так створюються сканворди в нашому застосунку з кросвордами та пошуком слів (App Store, Google Play). Одна сітка коштує від кількох до кількох десятків секунд процесорного часу, тому ми генеруємо їх заздалегідь на потужнішому комп'ютері і додаємо до застосунку. Пошук слів генерується зовсім інакше і простіше, про це стаття Як згенерувати пошук слів із зашифрованим словом.

#Яким вимогам має відповідати сканворд

У сканворді немає чорних клітинок. Кожна клітинка є або літерою, або питанням зі стрілкою праворуч чи вниз. Звідси жорсткі умови:

• Кожна літера належить і горизонтальному, і вертикальному слову. Літеру, яку перетинає лише одне слово, неможливо перевірити, і в кросворді вона виглядає як помилка.
• Кожне слово має щонайменше дві літери, а перед ним стоїть питання. Тому перший рядок і перший стовпець завжди складаються лише з питань.
• Літери утворюють одну суцільну область без відірваних острівців.
• Кожне слово має бути у словнику і мати щонайменше одне визначення. Жодне слово в сітці не повторюється.

До цього додаються м'які критерії якості: мало двобуквених слів, жодних питань, що нікуди не вказують, і якомога менше дуже довгих слів, які важко заповнити. Задача обчислювально складна. Engel та ін. (2012) показали, що вже саме заповнення маски словами є NP-повною задачею.

#Чому не вистачить заповнювати сітку слово за словом

Перша ідея: діяти як людина з олівцем. Поділити зашифроване слово на слова, покласти їх у рядок, як у газеті, провести через кожну його літеру слово, що перетинає, а решту сітки заповнити за допомогою greedy algorithm. Greedy algorithm на кожному кроці бере варіант, який виглядає найкращим саме зараз, і ніколи не переглядає рішення. Де нічого не підходить, лишається дірка. А оскільки greedy-заповнення не вміє повертатися, погані перші десять слів решта сітки вже не виправить.

Краща евристика вибору слів допомагає лише трохи. Можна пробувати довжини слів, що перетинають, від середніх, близько п'яти літер, до крайніх. Або піти еволюційним шляхом: популяція недороблених кросвордів, від кожного п'ять нащадків з одним словом більше, оцінка за кількістю заповнених клітинок, кількістю голосних і рівномірністю літер, і до наступного покоління переходять лише найкращі. Результати стають трохи щільнішими, але дірки лишаються, бо евристика бачить лише найближчий крок.

Вихід дає бакалаврська робота Якоба Енгеля з Технічного університету Мюнхена (2009); він також перший автор згаданої статті. Розділіть задачу на дві незалежні фази: спершу знайдіть добру маску, не зважаючи на слова, потім заповніть її. Енгель для маски використав еволюційний алгоритм. Ми використовуємо простіший локальний пошук із випадковими струсами, описаний у наступному кроці.

#Крок 1: маска через hill climbing

Маскою називаємо сітку, в якій кожна клітинка або питання, або літера. Щоб її знайти, достатньо hill climbing: локального пошуку, який робить малі зміни і зберігає ті, що не погіршують результат.

Почніть випадково, з питаннями приблизно на 22 % внутрішніх клітинок. Кожній масці призначте штрафну оцінку. Жорсткі порушення (закоротке слово, літера без слова, що перетинає, відірваний острівець) нехай здебільшого коштують 1 000 балів, м'які недоліки (двобуквені слова понад ліміт, питання, що не вказує на жодне слово, скупчення питань) від 50 до 500.

Далі в циклі змінюйте одну клітинку з питання на літеру або навпаки, або зсувайте питання на клітинку по діагоналі. Залиште зміну, якщо штраф не зріс, інакше скасуйте її. Спрямуйте половину змін на клітинки з найбільшим штрафом, і грубі помилки зникнуть швидко:

Hill climbing легко застрягає в локальному мінімумі. Коли 2 000 кроків нічого не покращують, «струсніть» сітку: у найкращій досі знайденій масці перемкніть п'ять випадкових клітинок і шукайте далі. На графіку це піки. Якщо й після трьох струсів кращої маски немає, а поточна не має жорстких порушень, зупиніться.

Готова маска має залишковий штраф 200 за м'які недоліки, але жодного жорсткого порушення:

Штрафи за питання без слова і за відірваний острівець варто мати в масці від самого початку. На великому наборі готових кросвордів без них 13,2 % питань не вказували на жодне слово, а 23,5 % сіток мали відірваний острівець літер. З ними це 5,0 % і 0 %.

#Крок 2: заповнення словами як CSP

З маски виходить список слотів, тобто місць для слів із відомою довжиною і перетинами. Заповнення є класичною задачею задоволення обмежень (constraint satisfaction problem, CSP): кожен слот є змінною, його домен складають слова, які в нього вміщуються, а обмеження є однаковими літерами на перетинах. Розв'язується вона за допомогою backtracking, тобто пошуку, який у глухій гілці повертається на крок назад і пробує інший варіант:

для кожного слота: домен = усі слова цієї довжини
поки не всі слоти заповнені:
    вибери слот із найменшим доменом (за рівності той, що має найбільше перетинів)
    для кожного слова з домену, від найкращого:
        постав слово
        звузь домени слотів, що перетинають, до слів із тією самою літерою
        якщо якийсь домен спорожнів: скасуй, спробуй наступне слово
        інакше переходь до наступного слота
    якщо жодне слово не підходить: повернися на слот назад
після 50 000 кроків здайся

У літературі ці евристики називаються MRV (minimum remaining values, спершу слот із найменшою кількістю варіантів) і forward checking (після кожного кроку звужувати домени сусідів, щоб глуха гілка виявлялася одразу, а не на десять слів пізніше). Заздалегідь проіндексуйте словник за довжиною, позицією і літерою. Тоді «слова з Щ на третьому місці» є одним перетином множин, а не проходом усім словником.

Важливий і порядок слів. Надавайте перевагу словам, які мають у словнику більше різних визначень. Це простий сигнал поширеного кросвордного слова. Без нього сітка заповнюється маловідомими абревіатурами.

#Крок 3: зашифроване слово в готовій сітці

Під час заповнення ви ще не знаєте, яким буде зашифроване слово. Прочитайте літери готової сітки зліва направо і згори донизу і шукайте жарт, чия пуанта є підпослідовністю цього рядка. Тобто літери йдуть у правильному порядку, але не обов'язково поруч. Якщо такий жарт знайдено, розподіліть його літери по сітці якомога рівномірніше, щоб пуанту не можна було вгадати з одного слова.

Такий порядок (спершу сітка, потім жарт) суттєво збільшує кількість готових кросвордів. За нашими вимірюваннями одна сітка 12×12 у середньому підходить для 86 жартів зі словацького списку (5 960 жартів). Тож завжди знайдеться такий, що ще не використовувався в цьому розмірі.

#Чому не ставити зашифроване слово заздалегідь, як у газеті

У газетах зашифроване слово зазвичай стоїть в одному місці, в рядку і розділене на слова. Досягти цього можна двома способами, і обидва дають дуже мало результатів.

Перший спосіб: поставити зашифроване слово в сітку заздалегідь. Тоді воно має вміститися. Наші пуанти мають у середньому 10,3 літери і 2 слова. Ось частка жартів зі словацького списку, які взагалі можна покласти в сітку даного розміру:

Із заздалегідь поставленим зашифрованим словом заповнення малих сіток вдається приблизно так само часто, як без нього. Для 15×15 це було 5 із 60 спроб проти 8 без нього, для 18×18 жодної з 60. До того ж кожна така сітка слугує лише одному жарту, а в малих розмірах більшість жартів навіть не вдається покласти.

Другий спосіб: дати сітці утворитися вільно і шукати в ній пуанту як суцільний відрізок. На вибірці з 2 200 готових словацьких кросвордів (по 200 кожного розміру від 8×8 до 18×18) уся пуанта як суцільний відрізок в одному рядку чи стовпці знайшлася лише в 81 сітці (3,7 %). Якщо кожне слово пуанти може лежати деінде, таких сіток 443 (20 %), і це ще без умови, що слова стоять поруч. Якщо читати літери по порядку, жарт знайшовся в кожній із них. Ціною зашифрованого слова, розкиданого по сітці, ви отримуєте на порядки більше кросвордів.

#Продуктивність генератора і чому він не працює на телефоні

Генератор виконав по 60 спроб для кожного розміру зі словацьким словником, в одному потоці (JavaScript на Node 22, серверний процесор Intel Xeon 2,8 ГГц у хмарі). Спроба складається з однієї маски й одного заповнення. «Успішне заповнення» означає, що CSP знайшов розв'язок за 50 000 кроків.

Що показують вимірювання:

• Мала сітка не є легкою. У сітці 8×8 багато коротких слотів із великою кількістю перетинів і мало свободи, заповнення вдається лише в 5 % спроб. Одна заповнена сітка в середньому коштує близько 10 секунд процесорного часу для 8×8, 4 секунди для 12×12 і 18 секунд для 18×18.
• Більшість спроб закінчується невдачею. Тому запускайте спроби паралельно на всіх ядрах і беріть перший достатньо добрий результат.
• На телефоні це не має сенсу. Гравець не хоче чекати десятки секунд, відкриваючи екран, а застосунок мусив би містити весь словник із визначеннями. До того ж генератор у застосунку мусить постійно віддавати керування інтерфейсу, інакше застосунок зависає.

#Генерація у великих обсягах

Тому генератор має працювати на комп'ютері з багатоядерним процесором. У нас кожне ядро має власний потік зі словником, завантаженим один раз під час запуску. Сітка готова, щойно один із потоків поверне результат із достатньо малою кількістю невикористаних клітинок. У безперервному режимі генератор по колу створює один кросворд кожного розміру кожною мовою. Так з'явилося понад 14 000 кросвордів чотирма мовами (словацька, чеська, англійська, німецька) в одинадцяти розмірах від 8×8 до 18×18. Кожен жарт використовується не більше одного разу на розмір і мову.

За такого обсягу важать дві речі:

• Формат. Повний запис займає близько 28 кБ на кросворд і 390 МБ на весь корпус. Більшу частину можна обчислити (координати, типи клітинок, номери питань). Компактний формат, у якому сітка зберігається одним рядком, займає близько 2 кБ, 15 МБ на корпус і приблизно 7 МБ в інсталяційному пакеті застосунку.
• Вимірювання якості. Після кожної генерації вимірюйте частку питань без слова і сіток з острівцями, і нехай перевірка не проходить, якщо показники погіршуються.

#Чого цей підхід не охоплює

• Питання без слів. Середній кросворд досі має 2,7 питання, що нікуди не вказують. Лівий верхній кут завжди такий.
• Словники без частотності. Німецький словник із Вікісловника має для більшості слів одне визначення, тож сортування за кількістю визначень майже нічого не розрізняє, і в сітку потрапляють рідкісні слова. Допоміг би частотний словник, поки що його немає.
• Зашифроване слово не стоїть в одному місці. Хто звик до газет, може шукати його в рядку. Це компроміс, а не ідеал.

Якщо ви розв'язуєте схожу задачу з генерацією контенту або вам потрібен мобільний застосунок, напишіть нам.

Щоб згенерувати 3D-модель телефону в браузері, витягніть прямокутник із заокругленими кутами на глибину пристрою, а потім булевими операціями (CSG) виріжте передню панель, кнопки, динаміки й роз'єм. Увесь пристрій тоді описують кілька чисел у міліметрах, і нова модель означає зміну цих чисел, а не моделювання в 3D-програмі.

Це корисно всюди, де потрібно багато схожих пристроїв або де їх має налаштовувати користувач: конфігуратори, мокапи, прев'ю продуктів. Приклад із практики: Ecranify, інструмент для 3D-мокапів для скриншотів в App Store і Google Play, у якому немає жодної готової 3D-моделі. Нижче покроковий процес разом із вимірюванням, яке показує, де на обчисленнях можна заощадити найбільше.

#Що вам знадобиться

• Three.js для сцени, камер, світла і передусім геометрії. Геометрія в Three.js це mesh, тобто набір трикутників.
• Бібліотека three-bvh-csg для булевих операцій над mesh. Вона пришвидшує їх просторовим індексом (BVH, bounding volume hierarchy), тому не перевіряє кожен трикутник проти кожного.
• Опис пристрою як дані, наприклад JSON із розмірами корпусу, радіусом кутів, розміром bevel і списком елементів на боках. Усі позиції задавайте в міліметрах від центру пристрою.

#Крок 1: Витягніть прямокутник у 3D

Намалюйте 2D-прямокутник із заокругленими кутами в реальному розмірі, наприклад 163,4 × 78 мм, і витягніть його (екструзія) на глибину 8,75 мм. Отримаєте пластину з гострими гранями. Таких телефонів не буває, тому під час екструзії увімкніть ще й bevel, тобто заокруглення ребра. Three.js робить обидва кроки за один раз.

Лише екструзія

+ кути й bevel

Зверніть увагу: bevel додається назовні. Якщо потрібен точний зовнішній розмір, зменште 2D-форму та глибину на розмір bevel.

b = min(bevel, глибина / 2)
форма = заокруглений прямокутник(ширина - 2b, висота - 2b, радіус кута - b)
корпус = витягни(форма, глибина - 2b, bevel b)

Гладкість дуг (тесселяцію) визначає кількість сегментів, на які ділиться дуга. Більше сегментів означає гладшу форму й більше трикутників. Це число згодом визначить швидкість усього обчислення, тож ми повернемося до нього в кроці 7.

#Крок 2: Виріжте заглиблення для дисплея

CSG (constructive solid geometry) складає тіла з простіших тіл за допомогою трьох операцій: об'єднання, різниця й перетин. Різниця працює як свердло: одне тіло забирає матеріал з іншого.

Дисплей телефону не врівень із рамкою, він лежить у неглибокому заглибленні. Щоб його зробити, створіть другу копію корпусу, меншу на 1,4 мм, залиште з неї лише передню частину завтовшки 0,7 мм (перетин із великим паралелепіпедом) і відніміть цю частину від корпусу. Потім покладіть у заглиблення темну площину дисплея.

Різальне тіло

Після віднімання

Дві практичні деталі:

• Паралелепіпед для перетину має бути справді великим. Йому достатньо обрізати глибину, але за шириною й висотою він має перевищувати весь пристрій. Не виводьте його з глибини: наприклад, 20-кратна глибина для тонкого високого телефону менша за його висоту, і вгорі та внизу залишиться необрізана рамка.
• Збільште різальне тіло на кілька проміле. Коли два тіла мають точно однакову грань, CSG не може визначити, яка сторона всередині. Масштаб 1,002 цьому запобігає, і оком його не видно.

#Крок 3: Підготуйте бічні елементи як свердла

Кожен елемент на боці робиться за тим самим рецептом з іншим свердлом. Кнопка, наприклад, складається з трьох тіл: заокруглений прямокутник, трохи глибший за кнопку, віднімається від рамки, край отвору отримує невелику фаску, а в отвір вставляється трохи менше тіло, яке злегка виступає з рамки.

Свердла

Виріз і кнопка

Динаміки це ряд маленьких циліндрів, роз'єм це заокруглений прямокутник. У кожен отвір вставте щось темне: тонкий диск у решітку, пластинку в роз'єм. Порожня дірка в тонкій оболонці виглядає як помилка, дірка з темним заповненням виглядає як залізо.

для кожного елемента в списку бічних елементів:
    свердло = форма елемента (циліндр, заокруглений прямокутник, ...)
    розмісти свердло на ребрі за позицією в мм
    додай свердло до списку вирізів
    якщо елемент має заповнення: додай заповнення до сцени

Додати кнопку тоді означає додати запис у дані. Елементів швидко більшає: iPad Pro 13″ має 58 отворів динаміка, 4 кнопки, 2 антени й роз'єм, тобто понад 60 віднімань від одного корпусу.

#Крок 4: Не свердліть передні деталі

Виріз камери, острівець у верхній частині дисплея й індикатор домашнього екрана пласкі. Різати для них геометрію марна робота. Нанесіть їх як decal, тобто зображення, спроєктоване на поверхню. Проєктуйте його на приховану площину на всю передню панель і задавайте позицію в тих самих міліметрах, що й усе інше. Виняток: кругла кнопка «Додому» старших iPhone. Вона має справжню глибину, яку видно збоку, тому проходить через CSG.

#Крок 5: Перенесіть обчислення у Web Worker

JavaScript у браузері працює в одному потоці. Той самий потік рахує, малює сторінку й реагує на кліки. Поки працює CSG, сторінка зависає, і spinner не допоможе, бо йому потрібен той самий потік.

Тому запускайте всю збірку пристрою у Web Worker, тобто в окремому фоновому потоці. Worker отримує опис пристрою, повертає готові масиви вершин, і сторінка лишається плавною. Коли параметр змінюється, завершіть старий worker і запустіть новий, щоб він не дораховував застарілий стан.

Результат із worker з'являється не відразу, тому додайте миттєве прев'ю. Показуйте елемент, який редагується, як синього напівпрозорого «привида»: простий паралелепіпед або циліндр із кількома десятками трикутників, який можна збудувати в головному потоці одразу. Коли worker закінчить, привид зникне.

#Крок 6: Відніміть усі отвори одразу

Найпряміший спосіб: віднімати елементи по черзі, отвір 1 від корпусу, потім отвір 2 від результату й так далі. Але кожне віднімання заново будує просторовий індекс усього корпусу, а це найдорожча частина обчислення. З десятками елементів час росте дуже швидко.

Краще спершу зібрати всі свердла для даного тіла, об'єднати їх в один mesh і відняти один раз.

вирізи = []
для кожного елемента: додай його свердло до вирізи
об'єднаний = об'єднай усі вирізи в один mesh
корпус = корпус мінус об'єднаний
якщо об'єднання не вдалося: віднімай вирізи по одному

Вимірювання на спрощеній копії процесу (Three.js 0.170, three-bvh-csg 0.0.17, Node 22, хмарний сервер із 2 ядрами Intel Xeon 2,1 GHz, медіана з 5 запусків):

Одна умова: об'єднання й одне віднімання дає той самий результат, що й послідовне віднімання, лише якщо свердла не перекриваються. Елементи розташовані в різних місцях, тож зазвичай це так. Але якщо користувач посуне два елементи один на одного, у місці перекриття може з'явитися дрібний дефект.

#Крок 7: Тримайте кількість сегментів як параметр

Тесселяція, якої достатньо для показу, для CSG часто надто густа. З 64 сегментами на кут і 32 на bevel корпус має 68 108 трикутників. Половини (32 і 16) на ребрі 2 мм не видно, але корпус має лише 17 676 трикутників, і третій рядок таблиці показує, що це робить із часом.

64 і 32 сегменти

32 і 16 сегментів

Дрібним елементам із радіусом до 2 мм (отвори динаміка, гвинти) дайте половину сегментів, мініатюрам у галереї ще менше. Тому не задавайте якість як константу в коді, а робіть її параметром збірки.

#Рендер на сервері без відеокарти

Якщо ту саму сцену потрібно рендерити й на сервері, наприклад як резерв для експорту, вона працює в Chrome без екрана (headless), який без відеокарти малює програмно. Там кожна неефективність множиться. В Ecranify найважчий планшет без описаних змін упирався в ліміт 15 хвилин. Зі спільними вирізами, меншими текстурами, нижчою тесселяцією й cache готової геометрії за hash опису пристрою рендер триває близько пів хвилини, а повторний близько 5 секунд. Подробиці з інтерактивними прикладами є в англомовній статті на ecranify.com.

Якщо ви розв'язуєте схожу задачу з 3D у браузері або потрібен застосунок на замовлення, напишіть нам.

Не відкривайте проєкт з Unity 4 одразу в Unity 6 і тим паче нічого в ньому не зберігайте. Unity 6 завантажує старі бінарні сцени лише частково, а збереження робить втрату остаточною; безпечний шлях лежить через Unity 2019.4, яка вміє і прочитати старий формат, і записати його як текст, і лише потім на Unity 6.

Це стосується проєктів, у яких сцени й префаби збережено в бінарному форматі, а скрипти написано на UnityScript, схожій на JavaScript мові, яку Unity колись підтримувала поряд із C#. Як приклад візьмемо Onager, фізичну гру з катапультою, написану в Unity 4.1.2 на UnityScript. У проєкті було 126 скриптів, 75 сцен і 78 префабів. Після перенесення гра працює на Unity 6000.5 з URP (Universal Render Pipeline) і безкоштовно доступна в App Store і Google Play.

#Що станеться, якщо відкрити проєкт в Unity 6

Найпростіший підхід: відкрити проєкт в Unity 6 і перемкнути серіалізацію на Force Text, тобто на збереження асетів як читабельного YAML. Але це не переклад файлів. Unity завантажує кожен асет через свій імпортер і записує назад як YAML, тож усе проходить через завантажувач Unity 6. На кожній сцені він повідомляє про Transform без GameObject і видаляє «завислий» компонент. Збереження робить це остаточним.

Втрату можна виміряти інструментом binary2text, який постачається з редактором і читає серіалізований файл без імпортера. В Onager ми порівняли його результат з отриманим YAML і рахували лише компоненти, що зникли з GameObject, які вціліли:

Жодна з 75 сцен не пройшла без втрат. Зникли цілі камери для HUD, а головна камера отримала нову, стандартну. Головне: шкода виникає вже під час завантаження, а не під час збереження. Поки проєкт не конвертовано, Unity 6 не повинна його зберігати: жодної сцени, жодного префаба.

#Крок 1: Зафіксуйте початковий стан

Перш ніж щось змінювати, зробіть знімок екрана кожної сцени й збережіть для кожного оригінального файлу сцени дамп через binary2text. За цими дампами ви перевірятимете камери в кроці 3 і відновлюватимете HUD у кроці 5. Оригінальні бінарні файли залиште в історії git, не видаляйте їх.

#Крок 2: Конвертація в текст через Unity 2019.4

Unity 2019.4 є останнім редактором, що вміє і читати, і записувати формат Unity 4.1. Конвертуйте із закритим редактором в окремій копії репозиторію:

• Версія проєкту. У файлі з версією проєкту вкажіть початкову версію (для Onager 4.1.2), щоб редактор пішов шляхом для старих проєктів. Unity перезапише її під час відкриття, вона має діяти лише для першого імпорту.
• Порожні пакети. Очистіть список залежностей пакетів. Одна помилка компіляції означає, що не працюватиме жоден пункт меню з редакторських скриптів, і це виглядає так, ніби меню взагалі не з'явилося.
• Імпорт з нуля. Видаліть теку Library і дайте проєкту імпортуватися.
• Force Text і примусовий перезапис. Після перемикання на Force Text Unity 2019.4 сама не перезаписує наявні файли. Це треба викликати функцією ресеріалізації асетів, і лише для асетів, а не для їхніх meta-файлів. Перезапис усіх meta-файлів призводить до того, що Unity 6 потім імпортує без кінця.

Одна пастка в git. Якщо в атрибутах git позначити сцени як текст із закінченням рядка LF, git під час додавання до репозиторію викидає з бінарних сцен байти, схожі на закінчення рядка. В Onager це пошкодило вісім сцен. Не ставте на асети Unity атрибут закінчення рядків, Unity і так пише LF.

#Крок 3: Перевіряйте результат у редакторі, а не читанням YAML

Читання конвертованих файлів веде до впевнених і хибних висновків. Скорочені записи екземплярів префабів виглядають як втрата, так само як камера, яка лише переїхала в префаб. Важливо те, що Unity будує в пам'яті. Відкрийте кожну конвертовану сцену й порівняйте її камери з дампом оригіналу з кроку 1.

В Onager після конвертації всі 75 сцен мали ті самі камери в тому самому порядку. Втратилося лише те, чого не знає жоден сучасний редактор: 569 GUITexture, 179 GUIText і старі системи частинок, які Unity прибрала у 2018 році.

#Крок 4: UnityScript на C# з тим самим GUID

Unity поступово прибирала UnityScript починаючи з версії 2017.2, тож ручний порт на C# є єдиним шляхом. Сцени посилаються на скрипти через GUID, унікальний ідентифікатор, який Unity зберігає в meta-файлі кожного асета, а значення полів зберігають за назвою поля. Якщо дотриматися цього під час порту, усі посилання під'єднаються самі:

для кожного скрипту X на UnityScript:
  створи C#-скрипт із класом точно на ім'я X
  скопіюй GUID з meta-файлу старого скрипту до meta-файлу нового
  публічні поля: та сама назва, той самий тип, навіть з одруківками
  нічого не перейменовуй, поки проєкт не працює

В Onager так після порту всіх 126 скриптів під'єдналися 12 935 компонентів у 73 сценах, і всі значення, задані в Inspector, залишилися.

Текстовим пошуком у проєкті не з'ясувати, які скрипти використовуються. Бінарний префаб зберігає GUID як байти, а не як текст. В Onager так двадцять один скрипт здавався невикористаним, і всі вони були живі. Остерігайтеся й залишків попередніх спроб порту: один префаб дерев'яного блоку вказував на два скрипти з такої спроби, і лише через нього бракувало 1 140 компонентів. Якщо в бінарному файлі треба змінити GUID, замініть його прямо в байтах, шістнадцять на шістнадцять, щоб файл не зсунувся.

#Крок 5: Відновіть HUD з оригінальних бінарних сцен

GUITexture і GUIText в Unity 6 немає, і разом з ними зникає весь HUD, побудований на них. Малювати його заново не потрібно. binary2text читає оригінальні бінарні сцени з історії git незалежно від того, чи існують ще класи. Витягніть з них кожне зображення й текст HUD з текстурою, кольором, позицією й вирівнюванням і скриптом поверніть їх на ті самі об'єкти в сценах. В Onager це було 577 зображень і 180 текстів.

Так рятуються й тексти, яких більше ніде немає. В Onager це було 111 текстів: усі підписи туторіалів і увесь екран з титрами. Пишучи HUD з нуля, ви мусили б їх вигадати. Переносячи кольори, врахуйте те, про що мовчить документація: старий GUITexture подвоював колір під час малювання. Усі 577 зображень мали колір рівно 0,5, тобто сірий означав білий.

#Після конвертації: замініть старі обхідні рішення

Старі проєкти часто обходили обмеження тодішньої Unity, і ці обхідні рішення варто переробити після конвертації:

• Відображення в підлозі. Onager мав блискучу підлогу без справжнього відображення. Під підлогою стояв другий, дзеркальний світ: копія кожного об'єкта, позицію якої скрипт кожен третій кадр копіював з оригіналу, в одному рівні від 50 до 70 клонів. Замінити це можна однією додатковою камерою, яка малює відображення з половинною роздільною здатністю. Тоді відбиваються також частинки й уламки, чого клонований світ не вмів.
• Прицілювання. Якщо попередній перегляд траєкторії передбачає, куди пошле постріл сила, додана на першому фізичному кроці, постріл падає не там, де мітка. Надійніше обчислити швидкість один раз, намалювати перегляд саме з неї й призначити її пострілу напряму.
• Продуктивність. Вимірюйте на слабкому телефоні. На Motorola G52 Onager падав з 20 до 6 fps лише через шейдер стін, більше, ніж роздільність, тіні й відображення разом. Тому на низькій і середній деталізації стіни мають простіший матеріал.

Якщо ви розв'язуєте фізику тисяч об'єктів у сучасній Unity, подивіться також на фейковий ragdoll для тисяч ворогів в Unity DOTS. Як після перенесення додати старій 2D-грі glow і 2D-світло в URP, описано в окремій інструкції.

#Чого цей підхід не розв'язує

Компоненти, яких сучасна Unity не знає, не під'єднаються. GUITexture і GUIText треба відновити, як у кроці 5, старі системи частинок втрачаються. Назви класів і полів залишаться точно такими, як в оригінальному проєкті, з одруківками й тією мовою, якою їх колись хтось написав. Сцени прив'язуються до них за назвою, тож перейменовувати має сенс лише через редактор, який сам перепише посилання.

Якщо у вас є старий проєкт на Unity, який треба перенести на сучасну версію, напишіть нам.

Орду з тисяч ворогів в Unity DOTS ведіть одним flow field для всієї мапи та кількома дешевими локальними правилами: відштовхування від сусідів і від стін, вартість шляху залежно від щільності натовпу та стан «чекаю» в заторі. В Unity Editor на MacBook з M3 Pro це витримує близько 9 600 ворогів одночасно при 90 FPS.

Проблема виникає в tower defense, стратегіях і survival іграх, де до цілі одночасно йдуть тисячі юнітів. Класичний пошук шляху для кожного окремо надто дорогий, а без локальних правил натовп перекривається, липне до стін і застрягає у вузьких проходах. Unity DOTS (Data-Oriented Technology Stack, тобто Entities, ECS і Job System) дає продуктивність для тисяч сутностей, але саму навігацію не розв'язує. Описаний нижче підхід ми використовуємо в нашій tower defense грі для ПК (вона є в нашому портфоліо). Зображення взяті зі спрощеної 2D-симуляції, що працює за тими самими правилами, це не кадри з гри.

#Крок 1: Flow field замість шляху для кожного

Flow field це сітка на всю мапу, у якій кожна клітинка знає, в якому напрямку від неї йти до цілі. Ворог не шукає шлях, а лише зчитує напрямок у місці, де стоїть. Вартість однакова для 10 і для 10 000 ворогів.

Поділіть мапу на клітинки по 1 м (наш тестовий рівень має 128 × 128) і для кожної цілі один раз порахуйте відстань від кожної клітинки до цілі. Статичне поле достатньо порахувати в редакторі під час підготовки рівня і зберегти в асеті.

Найпростіший варіант це Дейкстра через 8 сусідів і в кожній клітинці один із 8 напрямків. Це працює, але вороги ходять по діагоналях і рядком липнуть до стін.

8 напрямків

Плавне поле

Кращий результат дає плавне поле. Відстань порахуйте розв'язанням рівняння ейконалу (рівняння поширення хвильового фронту, розв'язком якого є найкоротша відстань у неперервному просторі, а не лише вздовж ребер сітки) методом fast sweeping, який багаторазово проходить сітку з усіх чотирьох кутів. Тоді напрямок це не напрямок клітинки, а градієнт відстані в точному місці ворога. До вартості клітинки додайте надбавку за близькість до стіни, тож поле саме тримає натовп трохи далі від перешкод.

#Крок 2: Окреме поле для кожного розміру ворога

Великий ворог вміщається не всюди, куди малий. Запровадьте класи розміру: кожен має власну прохідність (клітинка має бути достатньо далеко від стіни) і власне поле для кожної цілі. Тримайте класи як дані рівня, а не в коді. У нас їх три.

#Крок 3: Відштовхування від сусідів

Flow field дає напрямок, але нічого не знає про сусідів. Основа це спрощена модель boids (класичні правила зграї): кожен ворог відштовхується від сусідів у радіусі 0,9 м. Сусідів шукайте в spatial hash, тобто в просторовій сітці, де кожна клітинка тримає список юнітів у ній. Будуйте hash щотіку заново й сортуйте, щоб порядок був детермінованим.

Самого відштовхування замало. При 3 000 ворогах у 83,7 % із них найближчий сусід був ближче ніж 0,8 м, а найменша відстань становила 4 см, тобто двоє ворогів майже один в одному.

Більша вага відштовхування проблему не розв'язує. При вазі 6 замість 1,5 частка надто тісних упала до 54,6 %, при 12 до 44,3 %, при 24 далі нічого (48,2 %). До того ж натовп починає підстрибувати, бо необмежені поштовхи від багатьох сусідів додаються одночасно.

Допомагає позиційна корекція. Після руху розсуньте кожну пару, що перекривається, кожного на половину перекриття, а зсув за тік обмежте 0,15 м. Без цього обмеження корекція стрибає так само, як висока вага. З ним надто тісних залишається 60,8 %, але найменша відстань зростає до 28 см і натовп не підстрибує.

Лише відштовхування

Корекція перекриття

#Крок 4: Відштовхування від стін

Біля стіни корекція між ворогами не спрацьовує. Рух у стіну заборонено (зсув розкладається по осях, а складова в стіну відкидається), тож притиснутому ворогу нікуди ухилитися, і корекція від сусіда губиться. Із 938 ворогів, що перекривалися, ненульовий поштовх від стіни мали лише 35.

Тому додайте відштовхування від найближчих непрохідних клітинок у 4 напрямках і по діагоналі. Дві помилки, яких можна уникнути:

• Внутрішній кут. Поштовхи від обох країв і від кута додаються й відкидають ворога. Додавайте поштовх від кута лише на зовнішньому куті.
• Справжні стіни. Відштовхуйте від справжніх стін, а не від прохідності класу розміру. Для великого ворога «стіна» починається вже за метр до справжньої. На вході в коридор поштовх від кута так урівноважив рух великого ворога вперед, і вся група за ним зупинилася.

#Крок 5: Вартість за щільністю та сповільнення

Навіть із плавним полем увесь натовп іде найкоротшим шляхом впритул навколо кута, незалежно від того, скільки ворогів там уже є. Рішення пропонує Continuum Crowds (Treuille та ін., 2006): вартість клітинки зростає зі щільністю натовпу. Раз на 10 тіків порахуйте ворогів у клітинках, згладьте результат і перерахуйте поле однієї цілі. Біля переповненого кута поле тоді відправляє ворога в обхід, через вільніші клітинки.

Без щільності

Вартість за щільністю

Друга половина це сповільнення. Ворог у щільній клітинці рухається повільніше, щонайменше на 15 % швидкості. На 2 250 ворогах вони в розріджених клітинках ішли в середньому на 94 % швидкості, у помірно щільних на 71 %, а в заторі на 20 %. Нехай сповільнення починається раніше: з порогом вільної щільності 0,6 ворога на клітинку замість 1 частка надто тісних у вузькому проході впала до 36,7 %.

Практична порада: масиви, що створюються лише під час виконання (наприклад, карта щільності), виділяйте раніше, ніж їх уперше використає job. Job із ще не створеним масивом обвалює Unity Editor на нативному рівні, без винятку.

#Крок 6: Затор у вузькому проході: чекати, а не тиснути

Коли натовпу нікуди розширитися, залишається вузький прохід. Найпростіша ідея це відкинути складову швидкості в бік сусіда, якого ворог торкається. Задні тоді стоять замість того, щоб ухилитися, і підтримують затор.

Ухилитися вбік, наприклад на 35° у бік із меншою кількістю сусідів, краще, але натовп починає мерехтіти. Згладжування повороту й нижча швидкість обертання (180 замість 360 °/с) лише приглушують симптом. Причина в іншому: при врівноваженій щільності ворог щотіку обирає інший бік. Допомагає гістерезис, тобто перевага попереднього рішення: бік із минулого тіку отримує під час порівняння знижку в 3 сусіди.

Остаточне рішення поєднує контактне обмеження і три стани: іде, обходить, чекає. Складова швидкості в сусіда, якого ворог торкається, відкидається, бічна залишається. Хто не має ні вільного боку, ні місця попереду, чекає і не тисне.

для кожного ворога, щотіку:
    швидкість = напрямок із flow field × швидкість × сповільнення за щільністю
    швидкість += відштовхування від сусідів
    якщо попереду торкається сусіда:
        якщо є вільний бік: обходь (бік із гістерезисом)
        інакше: чекай
    відкинь складову швидкості в сусідів, яких торкаєшся
    зрушся, складову в стіну відкинь
потім для всіх:
    розсунь пари, що перекриваються (половина перекриття, щонайбільше 0,15 м)
    відштовхни від стін

Зверніть увагу на три речі:

• Терпіння. Коли двоє ворогів зустрічаються лоб у лоб, нехай чекає той, у кого вищий ID. Ланцюг сусідів може блокувати його тисячі тіків, тому після ліміту очікування він пробує аварійно ухилитися.
• Нульова швидкість. Ворог із нульовою бажаною швидкістю ніколи не виходить зі стану «чекає» і після хвилі залишається стояти на відкритому місці. Хто не хоче рухатися, має завжди бути в стані «іде».
• Вузький конус. Шукайте сусіда попереду у вузькому конусі з короткою пробою. При 45° налаштування відправляло в очікування чи обхід 55 до 60 % натовпу навіть на відкритому місці, при 30° і коротшій пробі 41 %.

#Крок 7: Обгін великих ворогів

Типи ворогів різного розміру та швидкості додають нових випадків. Наш великий повільний ворог має радіус у натовпі 1,25 м і йде зі швидкістю 1,1 м/с. Швидкий ворог позаду не міг його обігнати: бічні проби навскіс уперед завжди були ближче до великого, ніж сума радіусів, обидва боки виявлялися зайнятими, і швидкий чекав. Виправлення: сусіда, якого ворог обходить, проба враховує лише з його власного боку. Сусід точно попереду не блокує жодного боку.

Великий ворог, навпаки, відкидає малих зі свого шляху вбік, у секторі ±45° перед собою. Не відкидайте тих, хто рухається в його напрямку швидше, ніж хоче йти він сам, інакше він відкине й тих, хто саме його обганяє.

#Крок 8: Слоти біля цілі атаки

Якщо вороги атакують зблизька, їм потрібне місце навколо цілі. Наша вежа має 24 слоти по периметру основи 5 × 5 м, кожен ворог займає один, а решта чекає в черзі.

• Обхід по колу. Якщо пропонувати слот лише тоді, коли до нього веде пряма лінія, задні слоти залишаються порожніми, бо спереду лінія до них перетинає вежу. Нехай ворог обходить вежу по дузі до вільного слота.
• Без витіснення. Не витісняйте ворога, що йде до слота, на користь іншого претендента, це запускає ланцюг витіснень.
• Без відштовхування біля слота. Ворога, що підходить поруч із зайнятим слотом, відштовхує сусід, і він опиняється за 13 см від цілі або зовсім осторонь. Вороги в слоті та в межах 0,5 м від нього не відштовхують одне одного.

#Продуктивність симуляції та рендерингу

Benchmark в Unity Editor (M3 Pro, близько 9 600 простих ворогів, два вузькі проходи) дав 90 FPS при 1440p і 100 при 1080p. Роздільна здатність майже не змінює FPS, а прискорення часу змінює: при 10× падає до 20 FPS, бо на один кадр припадає десять кроків симуляції. На звичайній швидкості симуляція має запас.

З детальною моделлю ворога замість капсули вузьке місце переміщується в рендеринг:

У симуляції окупаються три речі:

• Два проходи по сусідах. Дешевий (дотики, блокування) працює завжди, дорогий (бічні проби, щільність боків) лише для заблокованих, яких у вільному потоці меншість. Порівнюйте відстані в квадраті, без кореня.
• Просте сортування. Синхронне сортування spatial hash тривало при 3 000, 10 000, 20 000 і 50 000 записів 0,37, 1,49, 3,16 і 8,46 мс, версія в job 0,18, 0,93, 3,12 і 15,53 мс. Job не є стабільно швидшим, простого сортування достатньо.
• Hash стану. На тіках 600 і 1800 рахуйте hash позицій і здоров'я. Рефакторинг має дати той самий hash, зміна поведінки його змінює, і ви можете пояснити чому. Це працює завдяки детермінованому порядку в spatial hash.

#Обмеження підходу

• Два повні зустрічні натовпи в одному вузькому проході застрягають назавжди. Це обмеження моделі без фізики.
• Цифри отримано в Unity Editor на M3 Pro. Вимірювань на Steam Deck і в справжньому build у нас поки немає, лише оцінка з публічних benchmark процесорів.

Якщо хочете спробувати власний натовп, документація Unity Entities це добрий початок. Схожий шлях від найпростішого рішення до робочого описано і в нашій статті про генератор судоку. Як відкинути ворогів у такому натовпі вибухом без дорогого ragdoll для кожного, описано в інструкції як зробити fake ragdoll в Unity DOTS. Якщо ви працюєте над схожою симуляцією в Unity і хочете допомоги, напишіть нам.

Щоб згенерувати пошук слів із зашифрованим словом, кладіть у порожню сітку випадкові слова зі словника, доки не залишиться рівно стільки вільних клітинок, скільки літер у зашифрованому слові. Потім заповніть ці клітинки зашифрованим словом зліва направо і згори вниз. На телефоні це займає кілька мілісекунд і не потребує backtracking, тобто повернення до попередніх рішень, коли генератор застрягає.

Пошук слів (у Словаччині цю головоломку називають osemsmerovka, «восьминапрямка») це сітка літер, у якій гравець шукає і викреслює слова зі списку. Зашифроване слово складається з літер, що залишаються невикресленими. Тож генератор мусить побудувати повністю заповнену сітку, у якій після викреслення слів залишиться рівно зашифроване слово. Описаним нижче способом генерується пошук слів у нашому застосунку з кросвордами та пошуком слів (App Store, Google Play).

#Правила сітки

Перш ніж почати, визначте, яким умовам має відповідати готова сітка. У нашому застосунку:

• Слова йдуть у восьми напрямках: горизонтально, вертикально й по обох діагоналях, кожним напрямком також навпаки.
• Два слова можуть мати щонайбільше одну спільну літеру.
• Жодне слово не може проходити через клітинку зашифрованого слова.
• Сітка має бути повною. Порожня клітинка це помилка.
• Зашифроване слово читається зліва направо і згори вниз з усіх невикреслених літер.

#Крок 1: Підготуйте словник

Один раз на початку розкладіть словник на групи за довжиною слова. Тоді вибір випадкового слова заданої довжини це один випадковий індекс. Якщо для кожного слова фільтрувати весь словник, генерація помітно сповільниться, адже для однієї сітки пробуються сотні слів.

Наш словацький словник містить 16 713 слів довжиною від 3 до 21 літери, найбільше семи- і восьмилітерних. Кілька практичних порад:

• Залиште у словнику власні назви та абревіатури. Тоді в сітці з'являться слова на кшталт HOUSTON чи MAINE. Без коротких і «дивних» слів сітку не вдасться заповнити достатньо щільно.
• Фільтруйте лайку окремим списком, який можна вимкнути, якщо гравець хоче вміст для дорослих.
• Якщо мов кілька, завантажуйте лише ту, якою зараз грають. Англійський словник має понад 414 000 слів. Якщо під час запуску застосунку завантажити всі чотири мови одразу, слабший телефон зависне аж на 11 секунд.

#Крок 2: Виберіть зашифроване слово

Зашифроване слово має містити щонайменше стільки літер, скільки клітинок у стороні сітки, і щонайбільше на чотири більше. Коротше загубиться в сітці, довше потребуватиме забагато дірок.

У нашому застосунку зашифроване слово це кінцівка жарту. Гравець викреслює слова і з решти літер читає, чим закінчується жарт. Ми складаємо його з кінця жарту: додаємо цілі слова з кінця, доки довжина не потрапить у цей діапазон.

На зображеннях нижче англійський жарт «Two snakes walk into a bar. Turns out they were lizards.» (Дві змії заходять у бар. Виявляється, це були ящірки.) на сітці 10×10. Зашифроване слово WERELIZARDS, 11 літер. Слова на зображеннях узято з англійського словника, звуженого до поширених слів, щоб їх можна було прочитати.

#Чому не варто починати із зашифрованого слова

Перша ідея: робити так, як робила б людина олівцем. Розкидати літери зашифрованого слова по випадкових клітинках у порядку читання, а потім будувати навколо них слова.

Виглядає розумно, доки не настає кінець. Генератор вибирає порожню клітинку, пробує провести через неї слово в усіх напрямках і зсувах, а коли сітка стає щільною, залишаються ізольовані дірки. Одну дірку між двома літерами зашифрованого слова не заповнить нічого, бо найкоротше слово має три літери, а через зашифроване слово проходити не можна.

На вибірці з 200 сіток 10×10 цей підхід давав повну сітку лише у 28 % випадків, у середньому залишалося 1-2 дірки. Латати їх потім складно. Тому не ставте зашифроване слово в сітку, доки не готові слова.

#Крок 3: Заповнюйте сітку, доки не залишиться рівно N дірок

Заповнення це простий greedy algorithm: кожне слово кладеться, щойно вміщається, і більше не прибирається. Генератор пам'ятає лише одне число: скільки клітинок ще порожні. Слово кладеться тільки тоді, коли після нього не залишиться менше порожніх клітинок, ніж літер у зашифрованому слові (N).

порожні = рядки × стовпці
поки порожні > N і спроб < 2000:
    слово = випадкове слово вибраної довжини
    повторити щонайбільше 50 разів:
        початок = випадкова клітинка, напрямок = випадковий з 8
        якщо слово вміщається за правилами сітки:
            нові = кількість порожніх клітинок, які слово заповнить
            якщо порожні - нові >= N:
                покласти слово
                порожні = порожні - нові
                перейти до наступного слова
якщо порожні != N: викинути сітку й почати знову

Перші слова лягають у порожню сітку вільно:

Що щільніша сітка, то частіше слова ділять літери. Це добре, бо кожна спільна літера означає на одну клітинку менше для заповнення:

Коли кількість порожніх клітинок падає до N, заповнення закінчується. Де саме ці дірки, неважливо. Вони можуть бути розкидані будь-де, бо зашифроване слово не мусить утворювати через них жодного шляху:

#Крок 4: Вибирайте довжину слова з розумом

Довгі слова роблять головоломку цікавою, короткі допомагають її завершити. Тому вибирайте довжину з двох нормальних розподілів (нормально розподілені випадкові числа дає, наприклад, перетворення Бокса-Мюллера):

Довжина завжди щонайменше 3 і щонайбільше сторона сітки. Додайте два правила, без яких генератор наприкінці застрягає:

• Наприкінці задавайте точну довжину. Коли до цілі бракує 5 клітинок або менше, шукайте слово рівно такої довжини, якої бракує (щонайменше 3). Інакше генератор безкінечно пробуватиме шестилітерні слова, які вже не вміщаються.
• Видавайте трилітерні слова за нормою. Перші три спроби сітки не можуть містити жодного, спроби 4-6 одне, наступні три два і так далі. Трилітерні слова у словнику часто є абревіатурами на кшталт DNA чи CPU і в головоломці виглядають дешево. Дозволяйте їх, лише коли інакше не виходить.

#Крок 5: Залийте зашифроване слово в дірки

Пройдіть сітку зліва направо і згори вниз і в кожну порожню клітинку запишіть наступну літеру зашифрованого слова. Оскільки дірок рівно N, слово вміщається без залишку.

Гравець бачить лише це:

#Коли сітка не вдалася

Якщо генератор за 2 000 спроб не досягає рівно N порожніх клітинок, викиньте всю сітку і почніть заново, щонайбільше 100 разів. Жодного латання дірок. Це грубо, але для сіток до 12×12 цього вистачає із запасом. Більші сітки потребують більше спроб, як показує таблиця нижче.

#Успішність і швидкість залежно від розміру сітки

Генератор працював на 300 сітках для кожного розміру, зі справжніми жартами і словацьким словником (Node.js 22 на серверному процесорі, телефон буде повільнішим; зображення зроблено з англійським словником, цифри зі словацьким, бо він менший, а отже це суворіший тест). «З першої спроби» означає, що перше коло заповнення завершилося повною сіткою.

Що це означає для власного генератора:

• Середнє слово має 4,7 літери, хоча ціль близько 6. Довгі слова просто частіше не вміщаються в щільну сітку.
• Приблизно 9-10 % клітинок спільні для двох слів. Налаштовувати це не потрібно, це наслідок правила «щонайбільше одна спільна літера».
• Діагоналей буде менше, ніж ви очікуєте. Напрямок вибирається рівномірно з восьми, тож діагоналі мали б становити половину слів. Але в малій сітці діагональне слово значно частіше виходить за край. На 8×8 діагоналі становлять 24 % слів, на 15×15 уже 33 %. Якщо хочете більше діагоналей, дайте їм більшу вагу під час вибору напрямку.

#Порада: та сама сітка при кожному запуску

Для скриншотів у магазинах вам потрібна щоразу та сама сітка. У такому режимі замініть звичайний генератор випадкових чисел простим лінійним конгруентним генератором із фіксованим seed (наприклад, похідним від мови). Якщо вся арифметика залишається в діапазоні, який числа в JavaScript представляють точно, результат однаковий на будь-якому пристрої. Тим самим трюком згенеровано й зображення в цій статті.

Якщо ви розв'язуєте схожу задачу, генеруєте головоломки або вам потрібен мобільний застосунок, напишіть нам. Короткі відео з розробки ми публікуємо також на YouTube. Так само покроково описано, як згенерувати судоку з єдиним розв'язком. Якщо вам потрібен кросворд замість пошуку слів, подивіться, як згенерувати сканворд із зашифрованим словом.