akdengi

Также захотелось перерисовать пару изображений на картах, начал.... очнувшись оказалось, что перерисовал все в едином стиле. Пришлось переверстывать и 56 карт тоже.

Осталось дождаться результатов краудфандинга.

Игру я делаю на 90% самостоятельно (жена только выверяла методику и проверит все, как редактор), поэтому меня ждут веселые 1.5 недели по вечерам по верстке всех компонентов (днем надо работу работать основную) помимо решения всех финансово-договорных вопросов.

Но оно того стоит, так как я вижу уже 8 с лишним лет, как дети с удовольствием играли и играют в предыдущие издания и сколько пользы, казалось бы, простая игра принесла в процесс обучения. Да и Битвы Роботов в Россию вернулись в прошлом году.

P.S. Эту версию я делал почти четыре года.

P.P.S. Полная версия есть в Tabletop Simulator.

Возвращаемся в D:\ComfyUI_windows_portable\ и устанавливаем нужные зависимости, запустив в командной строке:

А теперь важный момент — установка растеризатора, а точнее его бинарного ядра. Для этого оставаясь в той же директори, запускаем команду:

В 99% случаев у вас потом все заработает, если же нет, то попробуйте поставить wheel файл для более старой версии torch:

Если же после этого растеризация и создание текстур не заработают, то тогда вам придется собирать его и mesh генератор вручную, установив библиотеки разработчика C++, Cuda, заголовочные файлы Python и взяв в руки бубен. Если же вы вдруг решите все поставить под Linux, то вам придется собирать ядро растеризации и генератора сетки в любом случае — читайте внимательно инструкцию на github враппера.

Далее качаем саму модель Hunyan3D-2 в виде safetensor файла по ссылке и кладем ее в папку D:\ComfyUI_windows_portable\ComfyUI/models\diffusion_models\.

Если после этого запустить ComfyUI и попытаться открыть пайплайн генерации, то мы получим кучу предупреждений об отсутствующих нодах. Нам нужно установить расширение ComfyUI‑Essentials, если оно у вас не установлено ранее.

Это проще всего сделать через ComfyUI‑Manager. Для этого в командной строке снова переходим в папку D:\ComfyUI_windows_portable\ComfyUI\custom_nodes\ и там ставим расширение командой

Все. Можно запускать ComfyUI. После этого нужно открыть (или перенести в окно браузера) пайплайн генерации hy3d_example_01.json, который находится по пути D:\ComfyUI_windows_portable\ComfyUI\custom_nodes\ComfyUI-Hunyuan3DWrapper\example_workflows.

Нам высыпет кучу ошибок, поэтому вызываем менеджер кнопкой Manager в правом верхнем углу и выбираем пункт Install Missing Custom Nodes.

Отмечаем ComfyUI_essential и нажимаем на Install. Потом перезапускаем ComfyUI.

Теперь все должно запуститься и все ноды обнаружиться.

После нужно указать путь к модели, так как по умолчанию в примере он неверный. Щелкните на название модели в поле model и выберите ее из появившегося списка.

Можно нажать на генерацию и насладиться 3D моделью. Но можно и не насладиться. Если у вас не выводит текстурированную модель, то нужно удалить, вытащить на экран и заново связать две ноды: Hy3DExportMesh и Preview3D:

После генерации модели сохраняются как обычно в папке output в двух GLB файлах: просто геометрия и с текстурами. Для конвертирования можно использовать любой софт или сервисы, например я конвертировал в OBJ тут: https://convert3d.org/glb‑to‑obj

По скорости: на моей машине генерация 3D‑модели занимает порядка 200–220 секунд. Все зависит от числа полигонов и не рекомендуется делать его большим (по дефолту стоит 50 000 полигонов). Для сравнения ниже внешний вид модели при числе полигонов 300 000, 50 000, 10 000 и «шакальных» 1000 штук.

Я создавал 3D модели фигурок роботов для использования в версии моей настольной игры «Битва Големов» для Tabletop Simulator, который после экспорта в OBJ и вставки в него модели на 50 000 полигонов выдает ошибку. Поэтому я остановился на 10 000, благо игра сама оформлена в low-poly стиле.

Также вы можете включить параметр сглаживания сетки:

Модели нормально импортируются в тот же Blender и там дорабатываются. Маленькая хитрость — если экран 3D модели ничего не отображает, попереключайте режимы кнопками в левом верхнем углу ноды:

Итоговый результат в Tabletop Simulator на картинке:

Да, генерация еще не оптимальная и сильно зависит от качества исходного изображения и его сложности, так как картинка импортируется в низком разрешении. Есть вопросы к скорости и качеству текстуризации, но мы еще в начале пути 3D моделей и уверен дальше будет лучше.

И вот уже тут начинаются первые проблемы. На сколько градусов робот должен повернуться? Сможет ли робот ходить по диагонали (у нас поле из квадратных клеток и значит может быть 8 направлений перемещений на клетки вокруг той, на которой он стоит). Надо ли поворачивать робота за один раз только на один фиксированный угол или нужно будет сделать набор команд с разными значениями угла поворота. Будет ли робот поворачиваться на месте, или поворот будет сопровождаться перемещением?

Чтобы ответить на эти вопросы, вернемся к идее игры. Игроки задают фиксированное число команд в программе. В играх, которые были до моей, их число менялось от 4 до 10 и более, но в среднем было 5 команд за один раунд. Но... игры были гонками (до финиша или на собирание ресурсов) и основная задача была максимально оторваться от противника. Поэтому и число команд, и их разнообразие должны были позволять перемещаться быстро и по максимально непредсказуемой траектории. Я же делал рыцарский турнир, в котором игрок должен был побуждаться сражаться, а не бегать от соперника.

Это привело и к уменьшению игрового поля до 4×4 клетки (его можно расширить, но тут немного другая история) и уменьшению числа команд в программе до четырех. Для упрощения предсказания действий соперников (что важно в битве) поворот было решено сделать на месте и на 90 градусов. А чтобы роботы чувствовались неповоротливыми, было решено отказаться и от перемещений по диагонали и от перемещений вбок вправо и влево, а команда «Назад» заставляет робота пятиться, не меняя направление «взгляда».

Четыре команды перемещения робота у нас уже есть, но... Как я написал ранее, роботы всех игроков исполняют команды одновременно открываемой строки карт также одновременно. То есть если у нас будет ситуация как на рисунке, то наши роботы одновременно попытаются встать на одну и ту же клетку.

Решений два: или вводить порядок хода игроков или добавлять правила коллизий. То есть робот мог: а) попытаться встать на клетку, которая была уже занята другим роботом б) попытаться встать на клетку, на которую хотел встать другой робот.

Коллизионный механизм игры разрешал обе эти ситуации: если мы пытаемся переместиться на клетку, с которой другой робот также перемещается и на эту клетку никто не претендовал в итоге (а не забываем, что игра до 4 человек), то команда считается выполняемой. Если же по итогу исполнения на клетке оказывалось более одного игрока, то текущая команд игрока отменялась. Правило при этом действует только по направлению взгляда.

Все команды Перемещения при этом были равноправны. Правило коллизий также позволило прояснить ситуацию с краями поля, которые роботы не могут переступить и с препятствиями, которые игроки могли поставить на игровое поле (стены или камни) и которые нельзя было сдвинуть с занимаемой ими клетки.

Также это же правило срабатывало и для еще одного вида препятствий — бочек, которые игроки могли двигать перед собой. В этом случае робот и бочка считался за единый целый «блок» и проверялась возможность передвижения вперед или назад для объекта, который занимал две клетки. А что делать в такой ситуации?

По идее Бочку может сдвинуть и Синий и Красный роботы. Но с учетом правила коллизий они при одновременном перемещении окажутся на одной клетке и значит команда Вперед у обоих игроков не выполнится. Проще говоря «нельзя сдвинуть бочку более чем одним игроком». То же самое сработало бы, если бы Красный робот располагался на клетку выше. Тогда при движении вперед он бы попытался сместиться на клетку, куда сдвигалась бочка. Считаем, что так работают сенсоры роботов на препятствия.

Камни есть, бочки есть, перемещения есть, коллизии есть. Число таких команд (и их у нас четыре) ограничиваем по две штуки каждого вида, что позволяет с одной стороны достаточно свободно перемещаться, с другой стороны предостерегает игроков просто бегать по игровому полю. Благо число команд может быть уменьшено до трех изначально (когда «мозг» робота бронирован и не повреждается) или уменьшаться с 4 до 2 команд, если игрок выбрал управляющий компьютер без защиты. И докидываем одну карту с командой пустого цикла «Стоять на месте». Также прописываем правила коллизий бочек с другими роботами, краями и камнями.

Но у нас битва. Значит роботы должны атаковать и защищаться. Тут по игровой классике: у нас есть атака или защита и есть ее дальность и сила (число единиц атаки или защиты). Радостно добавляем эти две команды, прописываем два вида оружия с атакой на одну или две клетки и с изначальной силой в две единицы. И в бой?

Что будет, если у нас вторая строка команд будет как изображено на рисунке?

То есть Синий робот перемещается назад, а Красный в это время выполняет атаку на эту же клетку. Успеет ли Синий отойти или на него падет вся сила оружия Красного? Можно было бы применить те же правила коллизий, как для перемещений, но они не отрабатывают все возможные ситуации. Более того, проблема усугубляется тем, что мы ввели разрушаемые препятствия и атаку более чем на одну клетку вперед. Бочка разрушаема и затронет ли ее атака Красного, если у него оружие «бьет» на две клетки?

Голова идет кругом, поэтому вводим приоритеты видов команд. То есть команды Перемещения будут иметь приоритет выше, чем команды Действия, к которым отнесем «Атаку» и «Защиту». А значит сперва будет происходить перемещение всех роботов игроков, если у них открылась такая команда, а потом уже выполняться «Атака» и определяться уровень разрушений как роботов, так и игрового поля (или защиты от атаки). Не забываем, что в роли компьютера, который это все просчитывают, выступают сами юные игроки.

Также добавляем правило, что единицы атаки в зависимости от типа оружия или полностью вымещаются на клетку перед собой, или равномерно по распределяются по клеткам, куда достает оружие, но только если на самой первой клетке нет робота противника. Через него оружие не пробивает. И прописываем реакцию на «Атаку» для всех видов препятствий. По камням можно стучать сколько угодно, а вот бочки разрушаются и из них может что‑то выпасть, например Бомба, которая сразу же взрывается и наносит урон на 8 клеток вокруг клетки с разрушенной бочкой... Уф.... Защищаться же робот может от урона с любой из соседних клеток, в том числе и от взрыва бомбы.

Базово механика начала работать, но мы не ищем легких путей. Добавляем в игру новый вид препятствий - воду.

Задаем ее свойство наносить урон роботу, если он на наступает на клетку с ней. И реакцию как на команды Перемещения, так и Действия. В нашем случае Красный робот побил воду оружием в первой строке команд, а потом решил искупаться. Вода такая же клетка, поэтому упасть в нее одновременно два робота не смогут. А вот бочка при попадании в воду будет плавать. Но так как вода — это тоже клетка, но с особыми свойствами, то она не разрушаема и проницаема для оружия.

При попадании же в воду встает новая проблема: дать роботу утонуть окончательно (что делает воду просто мегачитерским способом быстро выйти из игры или считаем, что робот получает шанс и может выплыть. Если последнее, то куда? Выбор падает на второй вариант.

Добавляем правило, что, встав на клетку с водой робот может переместиться на любую свободную примыкающую к воде клетку, не меняя своего направления. Более того. если вода образует ручей/реку, то можно выплыть на любой свободной клетку непрерывного водного потока. Что Красный с удовольствием и делается. Заодно получаем способ быстрых перемещений по полю, хоть и за счет одной единицы здоровья (всего у робота их три, после четвертого повреждения он выбывает из игры).

А теперь представляем, что дальше мы добавляем в игру Цикл, повторяющий команду два раза и Условие, учитывающее наличие препятствий и других роботов перед ним перед исполнением команд перемещения и атаки. А после добавляем еще погодные условия. которые могут замораживать и растапливать воду. И добавляем зимнюю сторону игрового поля с гололедом и снежными заносами. И нам и этого мало: добавляем еще вирусы и компьютерные сбои. А вишенкой на торте добавляем линии и правила машинного зрения, заставляющих роботов перемещаться только по ним, игнорируя часть команд. И разрешаем ставить бочки в столбики. И использовать бочки как мосты на водных поверхностях. А еще вводим порталы.

Сложно? С одной стороны да, но все новые препятствия и нововведения действуют в рамках изначальных правил двух типов Команд (только добавляется третий вид — команды Бонуса) и реакции на них, правил коллизий и приоритетов. И даже в такой, казалось бы, усложненной форме механика игры продолжает работать и просчитываться даже школьниками начальных классов, не взрывая мозг и им и родителями с преподавателями. Да, отслеживать все перемещения становиться сложней, но и интересней. При этом игра остается динамичной и не скатывается в унылое перемещение роботов друг за дружкой по 5–10 команд последовательно и не растягивается на 40–90 минут, как в похожих играх.

И напоследок скажу, что в игре есть боты — роботы, которые управляются по специальной программе и которые делают игру веселей, если у вас мало соперников.

Вот такая игра у меня получилась в итоге к ее четвертой версии, с учетом того, что механику я дорабатывал и шлифовал с 2013 года, когда пришла в голову изначальная идея игры. И она оказалась не только рабочей, но и с заделом на будущее. Например, как насчет того, чтобы вместо команд задавать промт для ИИ чат‑бота, который можно поменять за небольшое время перед каждым раундом и потом исполнять команды от него? И даже в текущем варианте эта настольная игра интересна и как сама по себе, так и в дополнение к урокам информатики или кружкам робототехники.