Я автор настольной игры о программируемых роботах «Битва Големов». Игры, обучающей детей от 6–7 лет. И я хочу рассказать, почему даже 6 простых команд, которые «понимают» роботы, стали для меня головной болью, как я решал проблемы игровой механики и почему в итоге правила игры «распухли» до 16 страниц, но это не страшно.
Начну c краткого описания игры, чтобы было понятно, с чем мне пришлось столкнуться. Игра про битвы роботов на арене в виде клеток, которым дети задают в закрытую программу‑алгоритм, выкладывая ее в виде карт команд. И потом исполняют ее одновременно по одной команде за раз.
Идея не сложная, механика программирования действий родилась достаточно давно, но... Почему же такая простая, казалось бы, механика может вызывать проблемы?
Первое — это набор команд. С одной стороны он должен быть небольшим, с другой стороны должен обеспечивать определенную свободу действий. Еще одним аргументом должно быть проецирование игрового процесса на реальную образовательную робототехнику.
Понятно, что роботы должны передвигаться, а так как игра про битвы, то сражаться и защищаться. Так как мы играем на поле из клеток, то две команды напрашиваются сами собой: «Вперед» и «Назад». Также роботы должны уметь поворачивать, поэтому еще две команды — это «Поворот Влево» и «Поворот Вправо».
И вот уже тут начинаются первые проблемы. На сколько градусов робот должен повернуться? Сможет ли робот ходить по диагонали (у нас поле из квадратных клеток и значит может быть 8 направлений перемещений на клетки вокруг той, на которой он стоит). Надо ли поворачивать робота за один раз только на один фиксированный угол или нужно будет сделать набор команд с разными значениями угла поворота. Будет ли робот поворачиваться на месте, или поворот будет сопровождаться перемещением?
Чтобы ответить на эти вопросы, вернемся к идее игры. Игроки задают фиксированное число команд в программе. В играх, которые были до моей, их число менялось от 4 до 10 и более, но в среднем было 5 команд за один раунд. Но... игры были гонками (до финиша или на собирание ресурсов) и основная задача была максимально оторваться от противника. Поэтому и число команд, и их разнообразие должны были позволять перемещаться быстро и по максимально непредсказуемой траектории. Я же делал рыцарский турнир, в котором игрок должен был побуждаться сражаться, а не бегать от соперника.
Это привело и к уменьшению игрового поля до 4×4 клетки (его можно расширить, но тут немного другая история) и уменьшению числа команд в программе до четырех. Для упрощения предсказания действий соперников (что важно в битве) поворот было решено сделать на месте и на 90 градусов. А чтобы роботы чувствовались неповоротливыми, было решено отказаться и от перемещений по диагонали и от перемещений вбок вправо и влево, а команда «Назад» заставляет робота пятиться, не меняя направление «взгляда».
Четыре команды перемещения робота у нас уже есть, но... Как я написал ранее, роботы всех игроков исполняют команды одновременно открываемой строки карт также одновременно. То есть если у нас будет ситуация как на рисунке, то наши роботы одновременно попытаются встать на одну и ту же клетку.
Решений два: или вводить порядок хода игроков или добавлять правила коллизий. То есть робот мог: а) попытаться встать на клетку, которая была уже занята другим роботом б) попытаться встать на клетку, на которую хотел встать другой робот.
Коллизионный механизм игры разрешал обе эти ситуации: если мы пытаемся переместиться на клетку, с которой другой робот также перемещается и на эту клетку никто не претендовал в итоге (а не забываем, что игра до 4 человек), то команда считается выполняемой. Если же по итогу исполнения на клетке оказывалось более одного игрока, то текущая команд игрока отменялась. Правило при этом действует только по направлению взгляда.
Все команды Перемещения при этом были равноправны. Правило коллизий также позволило прояснить ситуацию с краями поля, которые роботы не могут переступить и с препятствиями, которые игроки могли поставить на игровое поле (стены или камни) и которые нельзя было сдвинуть с занимаемой ими клетки.
Также это же правило срабатывало и для еще одного вида препятствий — бочек, которые игроки могли двигать перед собой. В этом случае робот и бочка считался за единый целый «блок» и проверялась возможность передвижения вперед или назад для объекта, который занимал две клетки. А что делать в такой ситуации?
По идее Бочку может сдвинуть и Синий и Красный роботы. Но с учетом правила коллизий они при одновременном перемещении окажутся на одной клетке и значит команда Вперед у обоих игроков не выполнится. Проще говоря «нельзя сдвинуть бочку более чем одним игроком». То же самое сработало бы, если бы Красный робот располагался на клетку выше. Тогда при движении вперед он бы попытался сместиться на клетку, куда сдвигалась бочка. Считаем, что так работают сенсоры роботов на препятствия.
Камни есть, бочки есть, перемещения есть, коллизии есть. Число таких команд (и их у нас четыре) ограничиваем по две штуки каждого вида, что позволяет с одной стороны достаточно свободно перемещаться, с другой стороны предостерегает игроков просто бегать по игровому полю. Благо число команд может быть уменьшено до трех изначально (когда «мозг» робота бронирован и не повреждается) или уменьшаться с 4 до 2 команд, если игрок выбрал управляющий компьютер без защиты. И докидываем одну карту с командой пустого цикла «Стоять на месте». Также прописываем правила коллизий бочек с другими роботами, краями и камнями.
Но у нас битва. Значит роботы должны атаковать и защищаться. Тут по игровой классике: у нас есть атака или защита и есть ее дальность и сила (число единиц атаки или защиты). Радостно добавляем эти две команды, прописываем два вида оружия с атакой на одну или две клетки и с изначальной силой в две единицы. И в бой?
Что будет, если у нас вторая строка команд будет как изображено на рисунке?
То есть Синий робот перемещается назад, а Красный в это время выполняет атаку на эту же клетку. Успеет ли Синий отойти или на него падет вся сила оружия Красного? Можно было бы применить те же правила коллизий, как для перемещений, но они не отрабатывают все возможные ситуации. Более того, проблема усугубляется тем, что мы ввели разрушаемые препятствия и атаку более чем на одну клетку вперед. Бочка разрушаема и затронет ли ее атака Красного, если у него оружие «бьет» на две клетки?
Голова идет кругом, поэтому вводим приоритеты видов команд. То есть команды Перемещения будут иметь приоритет выше, чем команды Действия, к которым отнесем «Атаку» и «Защиту». А значит сперва будет происходить перемещение всех роботов игроков, если у них открылась такая команда, а потом уже выполняться «Атака» и определяться уровень разрушений как роботов, так и игрового поля (или защиты от атаки). Не забываем, что в роли компьютера, который это все просчитывают, выступают сами юные игроки.
Также добавляем правило, что единицы атаки в зависимости от типа оружия или полностью вымещаются на клетку перед собой, или равномерно по распределяются по клеткам, куда достает оружие, но только если на самой первой клетке нет робота противника. Через него оружие не пробивает. И прописываем реакцию на «Атаку» для всех видов препятствий. По камням можно стучать сколько угодно, а вот бочки разрушаются и из них может что‑то выпасть, например Бомба, которая сразу же взрывается и наносит урон на 8 клеток вокруг клетки с разрушенной бочкой... Уф.... Защищаться же робот может от урона с любой из соседних клеток, в том числе и от взрыва бомбы.
Базово механика начала работать, но мы не ищем легких путей. Добавляем в игру новый вид препятствий - воду.
Задаем ее свойство наносить урон роботу, если он на наступает на клетку с ней. И реакцию как на команды Перемещения, так и Действия. В нашем случае Красный робот побил воду оружием в первой строке команд, а потом решил искупаться. Вода такая же клетка, поэтому упасть в нее одновременно два робота не смогут. А вот бочка при попадании в воду будет плавать. Но так как вода — это тоже клетка, но с особыми свойствами, то она не разрушаема и проницаема для оружия.
При попадании же в воду встает новая проблема: дать роботу утонуть окончательно (что делает воду просто мегачитерским способом быстро выйти из игры или считаем, что робот получает шанс и может выплыть. Если последнее, то куда? Выбор падает на второй вариант.
Добавляем правило, что, встав на клетку с водой робот может переместиться на любую свободную примыкающую к воде клетку, не меняя своего направления. Более того. если вода образует ручей/реку, то можно выплыть на любой свободной клетку непрерывного водного потока. Что Красный с удовольствием и делается. Заодно получаем способ быстрых перемещений по полю, хоть и за счет одной единицы здоровья (всего у робота их три, после четвертого повреждения он выбывает из игры).
А теперь представляем, что дальше мы добавляем в игру Цикл, повторяющий команду два раза и Условие, учитывающее наличие препятствий и других роботов перед ним перед исполнением команд перемещения и атаки. А после добавляем еще погодные условия. которые могут замораживать и растапливать воду. И добавляем зимнюю сторону игрового поля с гололедом и снежными заносами. И нам и этого мало: добавляем еще вирусы и компьютерные сбои. А вишенкой на торте добавляем линии и правила машинного зрения, заставляющих роботов перемещаться только по ним, игнорируя часть команд. И разрешаем ставить бочки в столбики. И использовать бочки как мосты на водных поверхностях. А еще вводим порталы.
Сложно? С одной стороны да, но все новые препятствия и нововведения действуют в рамках изначальных правил двух типов Команд (только добавляется третий вид — команды Бонуса) и реакции на них, правил коллизий и приоритетов. И даже в такой, казалось бы, усложненной форме механика игры продолжает работать и просчитываться даже школьниками начальных классов, не взрывая мозг и им и родителями с преподавателями. Да, отслеживать все перемещения становиться сложней, но и интересней. При этом игра остается динамичной и не скатывается в унылое перемещение роботов друг за дружкой по 5–10 команд последовательно и не растягивается на 40–90 минут, как в похожих играх.
И напоследок скажу, что в игре есть боты — роботы, которые управляются по специальной программе и которые делают игру веселей, если у вас мало соперников.
Вот такая игра у меня получилась в итоге к ее четвертой версии, с учетом того, что механику я дорабатывал и шлифовал с 2013 года, когда пришла в голову изначальная идея игры. И она оказалась не только рабочей, но и с заделом на будущее. Например, как насчет того, чтобы вместо команд задавать промт для ИИ чат‑бота, который можно поменять за небольшое время перед каждым раундом и потом исполнять команды от него? И даже в текущем варианте эта настольная игра интересна и как сама по себе, так и в дополнение к урокам информатики или кружкам робототехники.
