Как я (пере)делал «рогалик» за неделю

Неделя с 4 по 11 марта была просто безумной.

Всё было не так плохо, как я ожидал, исходя из своего опыта 2012 года (на этот раз мне на самом деле удавалось спать по добрых 7-8 часов за ночь!), скорее всего, потому, что я стал гораздо более опытным, чем тогда, и имел в своём распоряжении гораздо больше инструментов. Желание создать что-то потрясающее заставило меня потратить более 80* часов работы на POLYBOT-7, мою игру для Seven-Day Roguelike Challenge этого года. (*Это только за неделю, сюда не включено время на подготовку перед 7DRL !)

Количество задач и решений, проносившихся через мою голову в течение этой недели, было просто выматывающим. Иногда это утомляло, но в то же время потрясающе находить хаки, позволяющие реализовать так много функций и контента за такой короткий промежуток времени. Очень. Много. Хаков. Огромный технический долг! В процессе написания большей части кода я ощущал досаду, но у меня не было выбора — или выбрать кратчайший маршрут, или рисковать завершить всё провалом. Первые несколько дней код был слегка чище, но с приближением дедлайна я начал делать по-настоящему безумные вещи.

Иногда этот проект был тяжеловат для меня, потому что годы «нормальной» работы над roguelike приучили меня записывать абсолютно всё, что я делаю или планирую, а также долго думать в поисках наилучшего решения. Мне пришлось преодолеть эту привычку и просто работать — не писать о работе, а делать её прямо сейчас! Мне приходилось напоминать себе об этом всю неделю.

Эта статья является подробным постмортемом, описывающим разработку POLYBOT-7. В ней рассматривается как весь процесс в целом, так и размышления, которыми я руководствовался, принимая решения.

Концепция — что и зачем?

Изначально мои амбиции по отношению к 7DRL были немного меньше. Целью было создание простого демейка моей игры Cogmind с отсечением от неё всего лишнего и разработкой чисто боевого roguelike. При этом большая часть работы заключалась в преобразовании интерфейса в более сжатый вид с меньшим количеством информации, но вдвое увеличенными шрифтами и тайлами. Это могло стать образцом, который я мог бы показывать людям, заинтересованным в общей тематике или стиле Cogmind, но не имевшим достаточно большого экрана для отображения игры. Эту версию концепта я прозвал «Bigmind».

Однако после обдумывания идея начала казаться мне скучной. Это же 7DRL! Он должен быть посвящён экспериментам и интересным новым roguelike!

Мне пришлось стать более радикальным, и в то время я как раз набрасывал заметки о новых функцях Cogmind, одной из которых был совершенно секретный режим Katamari Challenge Mode. Я хотел выпустить его с большим обновлением Challenges в этом году — по сути, игрок должен играть роль магнита для находящихся рядом предметов.

Внезапно это показалось мне отличной базовой механикой, которую можно использовать в 7DRL, не говоря уже о том, что идеальный дизайн потребовал бы кучи других изменений, по сути, создания значительно отличающейся игры внутри того же мира. 7DRL оценил бы по достоинству эту идею гораздо больше, чем простой соревновательный режим Challenge Mode, поэтому она стала новым направлением разработки.

В целом предложенные изменения значительно изменили игровой процесс Cogmind. Вы можете прочитать список похожих и отличающихся в этой игре функций в оригинальном анонсе POLYBOT-7, хотя некоторые из них я подробнее рассмотрю ниже.

Разумеется, были и другие причины, по которым я выбрал Cogmind в качестве начальной точки. Не последняя из них заключалась в том, что мне не пришлось слишком долго планировать и готовиться, и я мог сосредоточиться только на разработке геймплея или контента, а не основ. Без сомнений, для этого лучше всего подошёл POLYBOT-7.

Один из лучших способов работы для 7DRL — ограничение масштаба проекта, но ещё один из лучших способов — основываться на существующей игре или, по крайней мере, на мощном движке или фреймворке. Я хорошо знаком с исходниками моих игр и движка, проработав над ними долгие годы, а отсутствие необходимости изобретать велосипед очень подошло мне, потому что я не очень хорош в технической части — на самом деле, я работаю довольно медленно, что плохо при работе в тесных временных рамках.

Исходный код моих ранних проектов многие годы порождал новые проекты. Я редко начинаю проекты с нуля, вместо этого просто изменяя код.

(Тем не менее, помните, что 7DRL можно использовать так, как вы хотите, поэтому, возможно, вашей целью будет не завершение потрясающей игры, а просто построение движка или создание нового фреймворка, о котором вы всегда мечтали.)

Однако не всё было так радужно! Частично причиной моего не столь хорошего результата стало то, что в начале недели у меня не было готового дизайна. В 2012 году перед началом моего первого 7DRL я уже всё подготовил — проверил всю математику, формулы и интервалы данных, оставалось только перенести всё это в код и ASCII. Для POLYBOT-7 у меня были только наброски планов, в которых отсутствовали детали, и это стало проблемой, потому что возникающие новые детали могут довольно просто создавать эффект домино. Так и произошло. В результате мне пришлось вносить серьёзные изменения и дополнения, чтобы отрегулировать системы, которые я недостаточно хорошо продумал заранее.

Однако самым серьёзным недостатком было то, что бОльшую часть недели я провёл за размышлениями, а не реализацией. Для максимальной эффективности неделя 7DRL должна быть посвящена созданию, а не обдумыванию (создание хорошего дизайна может занять больше, чем неделю, в основном потому, что идеям обычно нужен инкубационный период, чтобы проверить, пройдут ли они проверку временем или существует решение получше). Как бы то ни было, я едва справился, главным образом благодаря наполненным адреналином хакам в коде.

Этап перед 7DRL

Подготовка к 7DRL начинается немного раньше, чем сама неделя. В январе я прошёлся по нескольким дизайн-документам, время от времени открывая последний для внесения изменений, когда он становился хаотичным или я хотел внести значительное изменение для реорганизации всего в свежем документе, чтобы получить хорошее представление о текущем состоянии дизайна. В 2012 году у меня было много свободного времени на подобную работу, однако в этом году я был довольно сильно занят разработкой Cogmind и другими вещами, поэтому не мог необходимого времени на дизайн. К 7DRL я пришёл с технически завершённым высокоуровневым дизайн-документом, однако будь у меня чуть больше времени, я бы усовершенствовал его гораздо сильнее.

Перед 7DRL я также написал анонсы релизов в своём блоге и на itch.io. На самом деле я довольно медленно пишу, к тому же я знал, что у меня не будет времени на хорошие анонсы релизов в течение этой недели. В результате позже я внёс небольшие изменения в соответствии с изменившимся дизайном, но в основном анонсы остались такими же, позже я просто добавил несколько скриншотов. Кроме того, это было хорошей возможностью познакомиться с itch.io, с которым я раньше не имел дела. Было бы забавно как-нибудь всё испортить после завершения работы над 7DRL!

Перед началом недели я даже задизайнил вариант обложки с помощью неиспользованного тайлсета для Cogmind:

Дорелизный черновой дизайн коробки.

Это упростило создание дизайна коробки для POLYBOT-7 в конце недели, после того, как Каспер завершил тайлсет. Можно заметить схожесть:

Финальный дизайн коробки!

UI

Кроме работы над диздоками я также потратил немного времени в REXPaint, создавая макеты UI. Изначально я стремился к тому, чтобы уместить всё необходимое в сетку 106x30, и я тестировал интерфейс с самого начала, потому что знал, что ограничения могут повлиять на механику.

Этот первый макет я выбросил довольно быстро:

Макет UI №1 (только HUD)

Вертикальные полосы слишком непонятны и плохо читаются, к тому же не оставляют места для дополнительных чисел. Затем я понял, что можно оставить для себя место над списком деталей, удалив четыре заголовка/строки, используемые только для разделения типов. Я в любом случае смогу добавить ASCII/тайл для каждой части рядом с каждой строкой, и они автоматически отсортируются, поэтому строгой необходимости в этих заголовках нет. Затем появился первый серьёзный макет (с примечаниями), хотя, как видно ниже, было очень плохой идеей создавать ASCII предмета, закрывающий левый разделитель UI! (Я попробовал это как эксперимент, чтобы сэкономить как можно больше горизонтального пространства UI)

Макет UI №2

Также важно рассмотреть способы изменения общего внешнего вида, чтобы создать как можно более отличающийся от стиля Cogmind интерфейс. Один из простейших способов сделать это — изменение цветов, поэтому я (и отдельно от меня Каспер) конечно же в первую очередь решили отойти от зелёного и попробовать выбрать другой основной цвет UI, а именно оранжевый. Золотой на чёрном — это любопытная тема, как можно увидеть на этом вдохновляющем скриншоте DynaHack.

Образец скриншота DynaHack с изменённой цветовой схемой.

Я изучил эту идею в REXPaint, но, к сожалению, с точки зрения UX в целом оранжевый оказался не совсем подходящим для механики POLYBOT-7. В Cogmind основной фичей является разрушение предметов, и вся цветовая схема тяготеет к тому, что зелёный считается «хорошим», а другие эффекты и состояния используют собственные логические цвета. В большинстве своём всё незелёное обычно требует более пристального внимания. При этом также сохраняется стандарт перехода «зелёный -> жёлтый -> оранжевый -> красный» для индикаторов урона и меток, а эта тема постоянно применяется в различных частях интерфейса. При изменении основного цвета такое интуитивное понимание будет нарушено, что приведёт к меньшей понятности UI.

Так родился достойный конечный макет HUD с четырьмя дополнительными строками сверху:

Макет UI №3 (только HUD, окончательная версия)

Позже я внёс другие изменения, но в целом всё осталось таким. Как бы то ни было, поскольку макет из REXPaint чётко излагает всё, то реализация стала достаточно простой и эта предварительная работа оказалась очень полезной.

Вместо того, чтобы снова использовать высококонтрастный стиль с чёрным фоном, я перешёл к теме с низким контрастом, в которой слегка более тёмный текст находится поверх немного более яркого фона. Под конец прошлого года я добавил в свой движок «фильтры рендеринга» (они описаны в моём блоге), которые позволили переключаться в низкоконтрастный вид простым изменением параметра конфигурации. В то время я не знал, что буду использовать их здесь — система должна была просто давать возможность игрокам в Cogmind настраивать интерфейс, но всё-таки она пригодилась и в джеме!

Эта строка в файле конфигурации не позволяет переднему слою быть слишком ярким, а также придаёт зелёный оттенок всему фону.

Однако фильтр низкого контраста сам по себе является довольно большим хаком. Cogmind годами разрабатывался с предположением о том, что фон будет чёрным, поэтому в этом режиме анимации не всегда выглядят идеально. Хотя у меня определённо не будет времени на обновление огромного количества частиц, используемых оружием, я по крайней мере могу улучшить внешний вид UI. Все эти изменения внесены в Cogmind (который во многом выиграл от этого 7DRL). Я всё равно хотел сделать это рано или поздно, но в этом случае работа сместилась на время 7DRL.

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

Пример второго решения. Заметьте, что до исправления анимация выполняет линейную интерполяцию до чёрного цвета, а не до нужного (то есть сначала становится чёрной, а потом переключается на нужный цвет). После исправления она выглядит гораздо лучше (как и должна), потому что изначально знает нужный цвет.

Перед началом работы я также много думал о шрифтах. Я хотел чего-то простого — как с точки зрения внешнего вида, так и реализации, поэтому для текста и карты я выбрал Terminus, потому что это красивый и pixel-perfect моноширинный шрифт, доступный практически в любом размере. Но поскольку я не хотел создавать огромный интервал размеров, как это было Cogmind (работа над этим занимает кучу времени), я запретил режиму карты (и HUD) расширяться вертикально и зафиксировал их на размере в 30 строк. Однако ширину можно изменять, что приводит на некоторых экранах к сужению текста. Тем не менее, это гораздо более приятный вариант, чем масштабирование, позволяющий тексту и тайлам сохранять свой внешний вид pixel-perfect прямо из битового изображения.

Кроме того, это означало, что благодаря всего четырём разным размерам можно обеспечить поддержку всего диапазона разрешений. При базовом квадратном тайле карты размером 12x12 в разрешении 768p используется шрифт 24x24 (просто созданный с помощью 12*2), в самом популярном на сегодня разрешении 1080p используется шрифт 36x36 (12*3), а выше — размер 48 (12*4, 1440p) и 72 (12*6, 2160p). Текст использует ячейки половинной ширины, которым тоже нужны четыре размера с базовыми измерениями 6x12.

Мои заметки, написанные перед 7DRL. Я ношу с собой в кармане сложенные листы бумаги и набрасываю на них мысли. Мой сын решил позаимствовать этот лист и нарисовал что-то на обратной стороне.

Дизайн геймплея

Основной целью дизайна было создание быстрого игрового процесса в стиле Cogmind, который можно было оценить за «кофе-паузу», поэтому всё вращалось вокруг этой идеи. В игровом процессе должно приниматься меньше решений, поэтому многие системы взаимодействий необходимо было убрать. И не только системы, но даже и визуальные эффекты оружия, которые отвлекали и поэтому могли замедлить игрока. С учётом этого, за неделю я хотел исправить все медленные анимации или исключить большинство видов оружия, в которых они использовались.

Сравнение анимации электромагнитного импульса в Cogmind с более быстрой анимацией из POLYBOT-7. (Из соображений механики я хотел сохранить ЭМИ в игре, поэтому мне пришлось их ускорить.)

Ещё одним шагом по снижению количества принимаемых решений стало полное удаление инвентаря, хотя к такому решению я пришёл не сразу. Заметьте, что в макете №2 выше есть инвентарь, который я поначалу представлял себе как модальное окно, позволяющее собирать детали, а затем прикреплять их по собственному усмотрению. Очень медленно! Даже со всеми функциями автоматизации одним из самых медленных аспектов Cogmind является управление инвентарём, и я подумал, что здорово было бы его ограничить. Поэтому дальше я подумал об упорядоченной «очереди» деталей, которые прикрепляются после утери предыдущих, но это казалось слишком сложным для того, что задумывалось как простая и сжатая игра.

Потом меня озарило, что необходимости в инвентаре вообще нет — по сути «инвентарём» игрока будет мир, что упрощалось благодаря уже имеющейся возможности притягивать к себе лежащие вокруг детали. Это оказалось просто и обеспечивало интересные последствия для игрового процесса.

После прикрепления детали не могут удаляться по отдельности, потому что тогда автоматическое прикрепление деталей будет бессмысленным, потому что тогда игроки просто будут отсоединять ненужные, ведь остальные лежат поблизости (больше тягомотины!). Поэтому кроме потери из-за разрушения (медленно и ненадёжно), нам нужен и другой способ. И тут появляется ещё одна важная часть плана: механика «Очистки».

В Cogmind уже есть команда «go naked», уничтожающая все прикреплённые части, чтобы успеть сбежать в случае крайней необходимости. Поэтому преобразование её для POLYBOT-7 приведёт к гораздо лучшему игровому процессу. Вместо уничтожения всех деталей он может уничтожать случайную их половину и выбрасывать другую половину, оставляя вероятность сохранения потенциально полезных деталей и не создавая огромного количества деталей вокруг, заново забивающих все слоты. Эта механика позволит игрокам «перетасовывать» свою конфигурацию, когда 1) она становится совершенно несбалансированной и бесполезной, или когда 2) они находят какие-то хорошие предметы, которыми хотят воспользоваться.

Из разговоров с игроками в Cogmind (за неделю до этого я показал им общий план) стало очевидно, что наличие неограниченной «Очистки» не сработает и её легко будет обойти, поэтому перед каждым использованием я добавил «подзарядку», выполняемую вытягиваемой из игрока энергией. Это может быть интересным, потому что она будет гораздо быстрее при наличии большой энергии. Кроме того, после «Очистки» игрок становится слабее, что вынуждает его серьёзно оценивать ситуацию перед выполнением этого действия. Я расскажу об этом чуть позже, потому что с такой системой возникли проблемы и сейчас она работает иначе.

Также в следующем разделе я расскажу о других уникальных механиках.

Начало UI

Первым этапом недели 7DRL было упражнение по усечению и реконструкции существующего UI наиболее эффективным образом.

Лучшим подходом будет «в первую очередь UI», потому что он позволит мне работать над отображением контента игры (изначально аналогичного Cogmind Beta 5) и останется известной переменной, ускоряя процесс разработки.

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

Схема UI Cogmind по умолчанию. Стрелки показывают, как в POLYBOT-7 консоли перемещались из области видимости или сужались.

Снова хаки? Да, конечно. Проще, чем альтернативы? Разумеется. Также я заблокировал команды, которые взаимодействовали с содержимым этих окон.

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

Одним из самых интересных хаков является журнал сообщений. POYLBOT-7 нужен свой журнал сообщений, но в игре недостаточно места для постоянного его отображения, как в Cogmind, поэтому я использовал тандем из двух решений…

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

Пример сообщений, прокручивающихся вверх по карте.

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

Поэтому я пришёл к идее простого использования «полного журнала сообщений» Cogmind. В оригинальной игре при нажатии F4 журнал сообщений разворачивается до самого низа экрана и отображает гораздо больше сообщений.

В POLYBOT-7 нажатие на «m» перемещает журнал сообщений так, что левый верхний угол имеет координаты (-1,-1) относительно экрана (чтобы скрыть его заголовок/границы) и расширяет свою высоту так, что внутренняя часть закрывает карту. При закрытии журнала клавишей «m», Escape или щелчком мыши он снова сжимается и перемещается из области видимости.

Довольно удобно, что мы позволили этому отдельному окну журнала сообщений продолжать своё существование за пределами экрана, правда?

Вот, как выглядел процесс, когда я настроил только некоторые из окон; заметьте, как развёрнутый журнал открывается немного за пределами экрана (позже я отключил встроенные номера ходов, потому что они занимали ценное место в журнале P7):

Изначально журнал сообщений разворачивался только на половину ширины карты, как и в Cogmind, но позже я увеличил его до ширины карты и полностью закрыл её — так в нём получается больше места, а сообщения проще читать, потому что они занимают меньше строк!

Открытие развёрнутого журнала сообщений поверх карты. Стоит заметить, что позже я решил оставить его границы видимыми, потому что с учётом способа работы шрифтов это выглядело лучше (в противном случае буквы отображались бы прямо рядом с краем экрана).

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

У меня не было достаточно времени, чтобы сделать удобное меню опций, но для roguelike необходим экран справки (к тому же, его не так сложно сделать), плюс в нём дублируется игровое меню с кнопками. Окончательная версия после перехода на новый шрифт и размеры терминала:

Как видно из предыдущей схемы расположения, окна «Scan» и «Volley» (соответственно используемые для получения краткой информации об объекте под курсором и подробностей атаки) убраны из области видимости, но содержащаяся в них информация слишком ценна, поэтому необходимо её куда-нибудь выводить.

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

«Информационная полоса» под списком деталей, в которой отображается краткая информация о разных объектах/состояниях.

Я не сразу добавил эту функцию интерфейса (заметьте, что её не было на первоначальных макетах), но позже, проведя небольшое тестирование, я осознал, что пожертвовав потенциальным слотом для предмета, получу гораздо больше!

Здесь показан полный код информационной полосы. Он довольно запутан, это быстрый хак, как и почти всё, что я делал в течение недели. Он копирует текст из других консолей и переформатирует его необходимым образом, чтобы отобразить в новой области.

Механика

Потратив первую пару дней на реализацию плана UI, я перешёл к следующему этапу — реализации всей новой механики…

Сначала я принялся за одну из основных новых функций: притягивание деталей. Заставить работать её было не так сложно, потому что в Cogmind долгое время была специальная функция с похожим эффектом, поэтому я мог просто адаптировать этот код. Из позиции игрока выполняется поиск Дейкстры, находящий все детали в радиусе (4), и каждая из них использует код поиска пути, стремясь приблизиться к игроку по одному шагу за ход.

В Cogmind всегда было важно тактическое позиционирование, но из-за этой функции оно стало ещё более необходимым, потому что для оптимальной игры нужно было также учитывать расположение объектов, в том числе и возможную выпадающую из врагов добычу. Если она будет слишком близко, то заполнит пустые слоты слабыми деталями!

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

Притягивание ближайших деталей и их прикрепление.

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

Когда все эти предметы валяются поблизости (особенно в виде оставшихся после боя трофеев), и большая часть из них остаётся неиспользованной, нужен какой-то способ избавиться от всего этого хаоса:

1. когда карта захламлена, становится сложно искать подходящую деталь
2. из-за механики притягивания лишний мусор делает задачу притягивания нужных предметов ещё более сложной задачей
3. практически всегда поблизости будет набор разнообразных деталей, что с лёгкостью позволяет избежать наличия пустых слотов (т.е. и проще выживать в целом)

В Cogmind для этой цели используются переработчики, собирающие трофеи в утилизационные установки, но в POLYBOT-7 я твёрдо решил использовать только боевых ботов. Поэтому я снова переработал существовавшую систему Cogmind, и реализовал самоуничтожение предметов. В Cogmind эта механика используется только в особых случаях, но здесь я хотел, чтобы она была универсальной.

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

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

Очевидно, что поблизости всё равно должны лежать хорошие детали, который игрок мог бы найти, так что у них нет таймера, пока игрок не начнёт их притягивать. И чтобы не позволять игроку слишком долго «таскать детали» по карте в качестве запасных, для всех активно притягиваемых деталей таймеры убывают в два раза быстрее.

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

Ещё одним серьёзным стратегическим изменением в геймплее было удаление типов слотов. Благодаря этому дизайн двинулся по неисследованному альтернативному пути, который я рассматривал в 2012 году. По-моему, он оказался довольно подходящим с учётом других новых механик POLYBOT-7, в частности, притяжения деталей. Получившиеся очень гибкие конфигурации P7 делали прохождение более хаотичными и интересными.

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

Реализация этого оказалась гораздо менее мучительной, чем я представлял, с учётом того, что в Cogmind существует фундаментальное предположение принадлежности слотов к разным типам! Внутри кода слоты по-прежнему должны иметь тип, необходимо только убрать или изменить ограничения ввода и вывода, чтобы игнорировать его. С технической точки зрения, каждый раз, когда игрок получает новый слот, он имеет тип «оружие», несмотря на то, что для игрока это неочевидно, потому что в слот оружия можно поместить что угодно.

Ещё одним важным принципом упрощения взаимодействия с предметами и управления конфигурацией игрока было разрешение смешивания разных видов двигательных установок (в отличие от Cogmind, где одновременно могла быть активен только один вид двигательной установки). Смешение было реализовать довольно просто, но в целом система двигательных установок при сохранении старой механики с одновременным использованием нескольких видов установок стала очень корявой. Не было никакой возможности обойти эту проблему, поэтому пришлось переделывать механику движения с нуля!

Изначально в дизайн-документе это изменение находилось в списке «было бы здорово, но у меня на это не будет времени», поэтому я заволновался, когда посередине пути выяснил, что придётся создавать новую систему двигательных установок! Чтобы стать качественной, система желательно должна пройти тестирование и множественные итерации, поэтому очевидно, что для 7DRL это не подходило.

Ну, чему быть, того не миновать, поэтому одним утром я просто закатал рукава и сделал всё полностью заново. Я не буду вдаваться здесь в подробности, только скажу, что очень помогло снижение количества вариантов до трёх видов движителей. (Я всё равно намеревался убрать полёт, потому что он больше не подходил к игре с упором на бои, и колёса, потому что они казались инородными и не могли попасть в свою нишу.)

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

Моя подготовка к реализации двигательных установок. Механика движителей POLYBOT-7 полностью основана на кратких математических вычислениях «на салфетке», а не на анализе и тестировании электронной таблицы.

К счастью, мне совершенно не пришлось вносить изменения в систему — исходя из практики, она оказалась довольно сбалансированной! Мне даже не потребовалось изменять ни один из шаблонов данных предметов, из которых получилось 54 новых предмета для двигательных установок. Какое облегчение!

Отсутствие небоевых ботов, кроме проблемы с захламлением пространства, привело ещё к одному побочному эффекту POLYBOT-7: в игре не было инженеров, восстанавливающих стены. Разумеется, это не такая большая проблема, как захламление, но безудержное разрушение в полностью разрушаемом мире могло иметь некоторые непредусмотренные последствия, от которых я хотел избавиться. Плюс, восстановление карты выглядит здорово, поэтому я его реализовал.

"Gauntlet" восстанавливает свою структуру.

Было бы здорово, если бы анимации стали быстрее — на самом деле это самая медленная часть игры (которую, как вы помните, я хотел сделать быстрой), но я работал быстро и не хотел, чтобы анимации были без звуковых эффектов (с учётом того, что всё остальное озвучено...), а единственные подходящие звуки имели такую длительность… поэтому я сопоставил с ними длительность анимаций. По крайней мере, это происходит только тогда, когда после предыдущего цикла была уничтожена какая-то часть рельефа.

Некоторые действия имеют предупреждающие звуки, чтобы игроки могли отреагировать на восстановление уровня, например, переместившись на другую сторону стены, чтобы заблокировать преследователей/нападающих. Оглядываясь назад я вижу, что над всей системой нужно ещё долго работать.

Эстетика

Выше я упоминал важность поиска способов создания уникального внешнего вида POLYBOT-7, чтобы отделить его от Cogmind. Стиль его игрового процесса очень отличается, поэтому в идеале внешний вид должен отличаться как можно сильнее. У нас уже есть новые размеры UI, пиксельные шрифты большего размера и изменения цветов, но есть и другие способы решения поставленной перед нами задачи.

Самый простой и очевидный — использование ориентированных стен на основе линий. К счастью, в Cogmind остался код, реализующий такой стиль (изначально оставшийся со времён исходного кода X@COM). Хотя этот «рубильник» переключить было просто, его не переключали уже много лет, так что, разумеется, он не был полностью функциональным… После исправления всех багов я также принял во внимание ориентированные двери — новую фичу, для быстрой реализации которой потребовались хаки, и несмотря на это, мне не удалось полностью усовершенствовать её (система восстановления карты не всегда правильно воссоздаёт двери).

Ой, когда я наконец устранил все проблемы с дверями, появились неисправные тайлы за пределами области видимости! Типичный геймдев… Несколько дополнительных сложностей возникло из-за того, что мне нужно было, чтобы система памяти карты правильно обрабатывала ориентации. (Про тайлы: хотя я обычно работаю в ASCII, мне пришлось проверять, работает ли ориентация для режима тайлов, поэтому на этом этапе у меня всё ещё были старые тайлы Cogmind.)

В качестве побочного эффекта простой реализации ориентированных стен игрок может получать больше информации о том, что происходит за стеной, хотя в мире роботов это можно объяснить какой-нибудь логикой, поэтому я оставил всё как есть. Однако мне потребовалось потратить какое-то время на обновление системы, чтобы она игнорировала соединения со скрытыми коридорами/дверями, которые в противном случае рендерились бы бессмысленно. К концу 7DRL оставалась по крайней мере одна аномалия, на которую ушло бы гораздо больше времени, поэтому я ничего с ней не сделал: скрытые коридоры, соединяющиеся в углу комнаты, раскрывают своё расположение. Система ориентации и так уже стала довольно сложной, и учёт особых случаев потребовал бы гораздо больше работы, чем реализованные мной простые правила.

Поведения ориентированных стен

Как видно из показанного выше скриншота, полы тоже изменились — в них используются жирные точки вместо полноразмерных тайлов пола. Это позволяет ещё сильнее выделяться тайлам переднего плана, а также сохраняет более традиционный внешний вид roguelike (в 2015 году в Cogmind появились заполненные тайлы пола, потому что так игра выделялась на фоне остальных; кроме того, Каспер хотел поэкспериментировать, а я не был против, потому что в конце концов сработал бы любой подход).

Каспер согласился поучаствовать со мной в 7DRL и создать тайлсет, поэтому нам для него требовался новый стиль. Поначалу мы думали сделать для него базовый размер 24x24, и в начале недели Каспер создал на основе этого размера несколько концептов, которые мы вставили в игру, чтобы посмотреть, как это будет выглядеть.

На скриншоте показано смешение концептов нового стиля тайлсета 24x24 (помечен стрелками) с новым текстом (остальное — это старые тайлы, не преобразованные для тестирования). Как вы видите, здесь есть сплошные клетки пола, от которых позже избавились.

Основная проблема заключалась в том, что я создал текст, увеличив масштаб шрифта Terminus 6x12 (для хорошей читаемости при всех нужных размерах), поэтому его внешний вид не соответствовал более мелкопиксельным тайлам, и общий внешний вид выглядел неестественно. Поэтому мы подумали, что лучше будет вернуться к использованию тайлов 12x12 и просто увеличить их масштаб, чтобы они соответствовали тексту и придавали всему интерфейсу громоздкий вид. Я предложил вид ровно сбоку и как можно более «плоский» (Каспер всё равно уже решил, что хочет работать с меньшим количеством оттенков).

В основном плоский тайлсет POLYBOT-7, за исключением роботов, в которых используется два оттенка.

Как вы видите в показанном выше готовом стиле, как и в режиме ASCII, в тайлсете используются ориентированные двери и стены, а «земля» (заполненное пространство между стенами) преобразована в простой квадрат. Это создаёт отличающийся от Cogmind внешний вид и снижает требования к тайлам до минимума, чтобы Каспер успел закончить работу (или хотя бы потратить больше времени на то, что по-настоящему важно!).

Ещё одним довольно большим изменением стала замена цветовой схемы предметов. Я быстро протестировал множество различных схем. Такое изменение не обязательно требовалось, чтобы отдалиться от Cogmind, а было скорее экспериментом по упрощению UI.

Быстрое тестирование разных цветовых схем предметов в песочнице (во всех случаях белым показаны неопределённые объекты). Победил №3.

DТакже важно было сравнить, как будут выглядеть схемы в списке деталей, где их тайлы тоже появляются (это было довольно плохое сравнение, потому что контент неодинаков, а распределение плохое, но мы торопились!)

В результате мне понравилась простота чисто синих оттенков. Они не очень часто используются в интерфейсе и хорошо соответствуют «зелени UI». Хотя это была более-менее монохромная схема, яркие оттенки синего можно было использовать для выделения ценных деталей, чтобы они сразу бросались в глаза. И у оттенков синего есть хороший связанный с ними диапазон цветов, от лазурного до небесного и бирюзового.

Стоит однако заметить, что изначально игрок тоже был синим, и когда его окружали предметы, это могло сбивать с толку, поэтому в последний момент я заменил его цвет на зелёный — этот цвет больше нигде на карте не использовался (потому что нейтральные боты из Cogmind здесь убраны). Тогда же я заменил цвет модулей апгрейда на зелёный, потому что они 1) очень важны по сравнению со всем остальным на карте и 2) уникальны для персонажа игрока, поэтому использование для них одинакового цвета выглядит логичным.

Генерирование карты

На генерирование карты я потратил целый день. К концу дня мой стол выглядел так:

Мой стол после обдумывания различных схем карты POLYBOT-7.

Во всех картах используется мой алгоритм туннелирования из Cogmind, хотя и с другими параметрами. Модули слотов (способ получения новых слотов деталей) на самом деле находятся среди этих параметров, существуя в виде префабов, которые произвольно располагаются в разных местах относительно входов/выходов с карты.

Пример карты 100x100 с примечаниями. Игрок попадает на карту с одной из красных точек и должен выйти через другую. В этой конкретной схеме используется четыре распределённых комнат модулей слотов, а не обычные три, а в POLYBOT-7 намного больше скрытых дверей и коридоров, чем в Cogmind. Также в нём очень мало крупных комнат.

Я особенно боялся провалить эту фазу разработки, потому что для создания хорошего набора карт нужно много времени, и для их переделки времени больше не будет. При создании схем я основывался на том, что узнал из исследования карт Cogmind, а также на планах о том, что контент POLYBOT-7 должен менять всё (следующий этап процесса, который я рассмотрю ниже). Честно говоря, мне не нужно было тратить так много времени на генерирование карт и всё было бы в порядке, но я хотел больше вариативности, чтобы повысить реиграбельность и сохранить сложность игры. Размер и схема карты критически важны для баланса, и я решил, что нужно увеличивать размер карты на каждой глубине, то есть для каждого этажа потребовалось несколько разных схем. Поэтому это заняло много времени.

Тестирование генерирации схемы для карты 80x80 (второй этаж).

Тестирование генерации схемы для карты 100x100 (третий этаж).

Тестирование генерации для одного стиля схемы (у каждого этажа есть несколько стилей) для карты 125x125 (четвёртый этаж).

Именно во время работы над генерацией карт я внёс огромное изменение в направление развития игры: постоянные апгрейды. В отличие от эволюционной системы Cogmind, в которой игрок просто должен достичь выхода, чтобы восстановить целостность ядра и получить увеличение характеристик, в POLYBOT-7 он подбирает случайные модули апгрейда, дающие постоянные преимущества наподобие сопротивления урону, дополнительной ёмкости для энергии/вещества, увеличение точности или радиуса видимости и т.д. Я очень хотел исследовать эту механику P7, но изначально в диздоке она находилась в списке «наверно, на это не будет времени». Я и не догадывался, что посреди недели мне придётся использовать эту идею, чтобы сбалансировать дизайн.

Когда я пришёл к ней, в условиях новой механики входы и выходы было очень сложно располагать так же, как в Cogmind, потому что карты P7 должны были стать меньше, но все апгрейды характеристик были локальными относительно к этажу, то есть мне не обязательно было прятать выходы далеко! Игроки могут очень быстро находить выходы, и это нормально, потому что они захотят исследовать этаж в поисках новых апгрейдов, при этом стараясь не потерять в процессе изучения слишком многого. В этом и заключается основная сложность игрового процесса.

Более того, для получения этих апгрейдов нужно атаковать диспетчеры (Dispatchers) (основные источники врагов, разбросанных по этажу), что позволяет сосредоточиться на боевой стороне игры — или рискуй, сражаясь за апгрейды, или сразу убегай. Кроме того, сам по себе сбор постоянных апгрейдов является интересной частью игры, несмотря на то, что его почти нет в Cogmind. Поэтому было любопытно поэкспериментировать с ним в антураже, похожем на Cogmind.

В Cogmind стратегии скрытности/скорости возникают естественным образом из самой механики — игрок пытается избегать врагов (или убегать от них) в процессе поиска выходов, но здесь это невозможно, и теперь механика POLYBOT-7 делает гораздо больший упор на бои как основу процесса. К сожалению, это также означало, что придётся проделать ещё больше работы над контентом — создать все апгрейды.

Контент

Хотя для 7DRL я подготовил достаточно хорошее расписание работы, к счастью в этом расписании было предусмотрена пара лишних дней на «баланс и интересности», потому что, как оказалось, мне пришлось тратить посреди недели их на более необходимые вещи, связанные с контентом. По исходному плану я должен был в основном сосредоточиться на создании в POLYBOT-7 уникальных механик, сохраняя как можно больше предметов из Cogmind. Но по множеству причин это оказалось неподходящим, как тематически, так и с точки зрения механики. Лучше всего было бы добавить кучу нового контента… поэтому в результате посреди недели я адски работал над этой незапланированной частью проекта. Ближе к последней паре дней она выглядело бледно и я даже думал, что не успею! В конце концов мне пришлось сокращать всё, что можно, и работать очень быстро.

Вне зависимости от нового контента всё было необходимо переработать под новый размер карт. В Cogmind одновременно видна область текущей карты размером 50x50, и все его механики и контент разработаны, исходя из таких размеров. Замечающие игрока и даже стреляющие в него из-за края экрана враги — это плохой дизайн, которого нужно было избегать всеми силами. В то же время, желательно наличие предметов и систем, максимально использующих преимущества доступной видимой области, поэтому эта область играет важнейшую роль в дизайне.

Чтобы сохранить как можно больше баланса без излишнего труда и тестирования, проще всего при работе с имеющимися данными было взять все связанные с дальностью значения и снизить их на 40%, чтобы отразить изменение области видимости с 50 до 30. Это стало первым изменением: я в буквальном смысле просто скопировал данные о дальности оружия и умножил их все на 0,6, а потом скопировал результаты обратно.

Но снижение на 40% дало значительное косвенное влияние на время стрельбы. Чуть ранее, чтобы переписать систему двигательных установок, я немного увеличил скорость движения и вычислил, что на практике (на основании общей массы выгрузки) игрокам для перемещения на одну единицу пространства обычно потребуется от 0,75 до 2,5 ходов — благодаря этому игроки не могут двигаться слишком быстро относительно карты с уменьшившимися размерами. И относительно этого, снова для того, чтобы сохранить знакомый по опыту с Cogmind баланс, следующей целью будет подбор таких затрат на время стрельбы, чтобы у врагов было примерно такое же количество возможностей стрельбы в быстрого или медленного игрока, как и в Cogmind. Цифры получились следующими — 3 хода на выстрел из одного оружия, 4,5 хода на залп из двух. Дальнейшее тестирование показало, что это работает неплохо, так что настройка больше не потребовалась.

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

Работа над предметами потребовала гораздо большего, чем просто изменения дальности:

• Все предметы двигательных установок из Cogmind (110 штук) были убраны и заменены 46 новыми (хотя некоторые названия остались прежними, характеристики изменились).
• Набор источников питания был упрощён, убраны 23 источника и добавлен новый набор из 9 источников, большинство из которых используют враги (вместо обычных источников питания).
• Было создано 14 модулей апгрейдов (по крайней мере для половины из них код поведения был взят из Cogmind, а для второй половины код добавить было довольно просто благодаря похожей модели).
• Вспомогательные предметы были переработаны — убрано большинство, имеющее чисто небоевые эффекты, у остальных упрощена схема наименований. В целом, P7 содержит на 182 меньше вспомогательных предметов, чем Cogmind.
• Названия и прогресс оружия тоже были упрощены. Кроме того, добавлено 21 новое оружие, большинство из которых должно использоваться врагами. Множество оружия из Cogmind (примерно 200) было удалено, и, как сказано выше, при этом процессе я избавлялся от большинства оружия с медленной анимацией. Единственным исключением стала микроядерный заряд, крутость которого недостаточно проявилась в Cogmind, поэтому я воспользовался POLYBOT-7, чтобы показать его во всём величии, создав для него улучшенную пусковую установку. Также значительно было преобразовано множество типов оружия из Cogmind, чтобы превратить их в улучшенные версии более раннего оружия и изменить их анимации для соответствия их новой группе.
• В целом, POLYBOT-7 содержит всего 412 предметов, в то время, как Cogmind — 900

Покончив с предметами, мне нужно было переходить к роботам, свойства которых в основном определялись их предметами. Все роботы были созданы с нуля, но в большинстве случаев при разработке их дизайна я пользовался в качестве шаблонов роботами из Cogmind. Общая идея заключалась в том, что вражеские роботы используют слабые детали, поэтому хотя игрок может присоединить к себе и использовать всё, что угодно, часто лучше при возможности избегать трофейных деталей (трудности возникают тогда, когда вокруг валяется куча трофейных деталей, которые автоматически заполняют слоты! Это в какой-то степени не даёт игроку использовать «безопасную» тактику боёв в дверных проёмах). Также в их источниках питания нет ёмкости для хранения энергии, поэтому если для получения питания игрок будет полагаться только на других ботов, то у него останется меньше резервов для поддержки универсальных конструкций своего робота.

Кроме того, я дал некоторым роботам предметы, которыми они на самом деле не пользуются, но которые могут пригодиться игроку. Эта стратегия дизайна намного чаще используется в Cogmind, чем в P7, но в некоторых случаях она помогает. Например, у Aimbot есть Structural Scanner, чтобы у игрока был частый доступ к нему для распознавания скрытых дверей — не забывайте, их в POLYBOT-7 стало гораздо больше! (К тому же, тематически это имеет смысл — Aimbot, который может атаковать цели сквозь стены, может иметь такие устройства).

Полные данные роботов!

После завершения работы над роботами (видите? — работа движется в очень правильном порядке), наконец, настало время Dispatchers, фокусной точки большой части боя, а значит, и игрового процесса, в том числе и сложности! По сути, Dispatchers — это гарнизоны (Garrisons) из Cogmind, но с другим поведением (активизация на основании близости игрока, создание отрядов с заданными промежутками времени до уничтожения, после отключения оставляют после себя модули). Но так как они оказались важной частью игрового процесса, в результате потребовалось много работы по их балансировке, особенно расстояния, на котором они должны срабатывать и количества выпускаемых ими ботов. За последнюю пару дней я несколько раз изменял эти параметры. Однако их боты не всегда атакуют игрока напрямую! Это могло бы быть очень скучно, поэтому некоторые из них стоят на месте и защищают Dispatcher, а другие направляются в точку, в которой игрок привёл к срабатыванию Dispatcher, но с технической точки зрения они никогда не ищут игрока непосредственно, как некоторые отряды в Cogmind.

Более-менее завершив с контентом, я перешёл к балансировке карты в целом. На это я потратил много времени: постоянно загружал случайные карты, отдалял их и изучал распределение предметов, патрулей, охранников, диспетчеров и т.д., а также настраивал множество чисел/коэффициентов создания врагов, чтобы создать что-то, похожее на сбалансированный игровой процесс.

Исследуем контент на части карты, в том числе и маршруты патрулей (показаны цветными линиями).

POLYBOT-7 должен был стать достаточно коротким: всего пять этажей, но кроме уникальных схем карт я нашёл ещё один относительно незатратный способ повышения реиграбельности для тех, кому игра понравилась — добавление после выигрыша режима «New Game+». Многие определяющие сложность переменные можно просто изменять в зависимости от количества побед игрока, так зачем же останавливаться на простом NG+? Я решил добавить пять последовательных режимов New Game, каждый сложнее предыдущего. Изменяемые параметры:

• Количество изначально находящихся на карте патрулей
• Размер патруля
• Дистанция, на которой срабатывают Dispatchers
• Количество роботов, выпускаемых в группе
• Изменение весов типов выпускаемых роботов
• Добавление вероятности того, что выпущенные роботы будут дополнены поддерживающим Blastbot (использует ракеты) или Forcebot (защищает союзников силовым щитом)
• Промежуток между выпуском роботов (он был реализован, но я не увидел необходимости изменять его, поэтому он остался постоянным: 100 ходов)
• Коэффициент получаемых с уничтоженных роботов трофеев

Другие изменения при NG+, не связанные с геймплеем:

• У каждого есть уникальное название: "Alpha," "Beta," и так далее
• В каждом свой уникальный цвет стен
• Множитель очков увеличивается с каждым режимом, давая огромное количество бонусных очков для всех действий, за которые начисляются очки, даже если игрок не выиграл

Чтобы упростить реализацию, я сделал так, чтобы после проигрыша в любом прохождении NG+ игрок терял выигрышную серию и вынужден был начинать с начала и «обычного прохождения». По сути, это как permadeath из roguelike, но для серии побед в New Game. Это не лучшее решение, но мне приходилось торопиться! Оглядываясь назад, я думаю, что лучше бы один проигрыш возвращал игрока назад к предыдущему режиму NG+ (если он уже выиграл хотя бы больше одного последовательного прохождения), чтобы терялся не такой большой прогресс.

Примечание: один из лучших игроков в Cogmind уже выиграл в P7 самом-самом-самом последнем режиме NG+++++, добившись окончательной победы!

В последний момент

Всё время, запланированное на балансировку, было съедено добавлением контента, поэтому на «правильный» баланс почти ничего не осталось. Было слишком мало времени, чтобы выполнять все необходимые вычисления, и хотя мне понравилось писать совершенно новый контент с самого нуля и использовать формулы для балансировки его под новый формат, это всё-таки 7DRL — планы должны быть хотя бы наполовину реалистичными.

С учётом этого, я был сильно впечатлён и обрадован тем, как хорошо всё обернулось, потому что у меня хватило времени только на самые экстренные заплатки, и за последние часы дедлайна я внёс довольно сильные улучшения. Разумеется, это ни в коем случае не уровень баланса Cogmind, но за пару быстрых прохождений я обнаружил самые серьёзные проблемы, которые нуждались в срочном решении.

Кроме снижения количества роботов (сначала их было слишком уж много!), я добавил на карту кучу оружия, по сути хаком вставив их в обычную систему распределения предметов: минимум 15% всех отдельных предметов стали создаваться в виде оружия. Обычно распределение предметов выглядит не так, но после того, как при тестовых прохождениях у меня регулярно заканчивалось оружие, я использовал систему вывода отладки распределения предметов в Cogmind, чтобы исследовать обычную вероятность создания оружия и заметил, что на большинстве этажей значения на удивление малы.

Окончательное (после балансировки) распределение предметов на каждом этаже, как обычных, так и прототипов, по слотам/типам.

Кроме того, таким же образом я принудительно разместил на каждом этаже пусковые установки (на больших этажах их больше), потому что пусковые установки — это ВЕСЕЛО. Кроме того, иногда у игроков в POLYBOT-7 не находится свободных слотов для сбора найденных/желанных предметов (не забывайте, что в игре нет никакого инвентаря!), поэтому несмотря на большое количество валяющихся вокруг интересных штук, не все из них на самом деле будут использоваться, то есть можно спокойно добавить их больше, не сделав при этом игру слишком лёгкой.

Также в виде гарантированных заготовок было добавлено больше оружия и других хороших предметов, а именно, «оружейные комнаты» и так называемые «комнаты сборок». Это комнаты, в которых лежат завалы деталей, а именно только оружия (опять-таки, чтобы можно было с ним поиграться) и только сбалансированного набора предметов для всего спектра слотов. Нашедшие такие комнаты игроки могут выполнить «очистку», сбросив все свои предметы и получив хорошую новую сборку предметов. В «комнатах сборок» гарантированно присутствуют источник питания, двигательная установка, вспомогательные устройства и оружие.

Специальные комнаты-заготовки с примечаниями. Заметьте, что у таких комнат часто имеются двойные двери, чтобы их легко можно было опознать снаружи.

Сейчас я думаю, что переборщил с оружием (теперь оно валяется повсюду), но большее количество вариантов выбора всегда имеет свои преимущества, поэтому лучше перебор, чем недобор! Для достижения идеального баланса у меня не было достаточно времени. В конце концов, мне пришлось делать всё это в последние часы.

Ещё одна из базовых механик, которая изменилась в последнюю минуту — это таймер очистки. Поначалу мне казалось, что стратегически будет интереснее устройство, для своей зарядки вытягивающее при каждом ходе энергию из игрока. Такое поведение добавит необходимость принятия решения о времени очистки, потому что за этим действие последует снижение производства энергии до момента полной зарядки. Но я понял, что в целом это не особо желательно, потому что очистка и так уничтожает случайные детали и может привести игроков в ситуацию неопределённости, поэтому нет смысла пинать его, когда у него и так проблемы! Поэтому я заменил эту механику на простой 100-ходовый таймер — это более предсказуемо и интересно.

Таймер очистки в действии. Выполняет обратный отсчёт и постоянно притягивает оставшиеся поблизости предметы, только чтобы снова выполнить очистку.

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

Добавления в HUD в последний момент: количество собранных слотов и идентификатор этажа! (Вместо чисел у этажей соответствующие буквы: A/B/C/D/S)

Кроме полезности для игрока, индикаторы HUD делают скриншоты намного более информативными, когда игроки ими делятся, что позволяет избежать множества простейших вопросов и придаёт обсуждениям больше контекста. Это одно из преимуществ стиля UI в Cogmind: практически всё, что необходимо знать, видно на одном экране. Кроме того, это позволяет быстрее набрать скорость после возврата к незавершённому прохождению.

Конец

Хотя в своём часовом поясе я закончил всё вовремя, я продолжал работать с Каспером, а ему нужен был остаток его воскресенья, чтобы завершить тайлсет, поэтому я не публиковал игру до следующего утра, когда у меня появилась возможность проснуться и упаковать все его тайлы в игру.

И она наконец готова!

Даже несмотря на то, что работал над своим проектом почти всю неделю нон-стоп, это была на удивление бодрящая неделя, в течение которой мне не казалось, что приходится спешить. Прошло так много времени с тех пор, как я делал что-то, кроме работы над Cogmind, поэтому я забыл удовольствие от чистой разработки времён моих хобби-игр. В коммерческом продукте всё должно быть задокументировано, отточено и собрано с тщательно подобранными спецификациями, а для POLYBOT-7 я просто смог отдаться потоку работы. К такому свободному подходу поначалу было сложно приспособиться, но он определённо показался мне гораздо более продуктивным.

Вскоре после релиза мне сообщили, что в игре по-прежнему есть интерфейс взлома гарнизона при нажатии на Dispatcher. Я убрал возможность хакинга при столкновении, но забыл, что обработка нажатий мыши выполняется в другой части кода! Это значило, что игроки могли взламывать Dispatcher, который создавал лестницу к этажу со странным названием G (первая буква Garrison), и с технической точки зрения это была настоящая ссылка на карту гарнизона, однако я удалил все данные гарнизона, поэтому попытка войти просто приводила к сбою игры. Я очень быстро добавил исправленную версию, чтобы люди не могли попасть в эту чёрную дыру (не говоря уже о том, что дизайн интерфейса взлома для POLYBOT-7 не менялся).

Открываемый багом интерфейс взлома теоретически позволял выйти в Dispatcher.

К слову о багах: на протяжении времени разработки я нашёл довольно много их в Cogmind, и даже в самом движке. Ничего серьёзного, но здорово было избавиться и от них тоже.

В целом я нахожу концепцию POLYBOT-7 очень интересной, но 7DRL позволил только частично раскрыть её потенциал. Одна из идей, которая может сильно повысить фактор интересности — это «комнаты комплектов». В сущности, это комнаты, в которых содержатся все детали для превосходной сборки, сбалансированной относительно конкретного стиля или оружия, которые заставят при нахождении такой комнаты немедленно выполнить очистку, чтобы превратиться в машину для убийства. На самом деле, добавленные в последнюю минуту «комнаты сборок» были упрощённой реализацией концепции комнат комплектов, но с полностью случайными деталями. Однако в отличие от комнат сборок комнаты комплектов должны быть скрыты за тайными дверями, требующими для обнаружения сканеров или удачного случайного выстрела. С технической точки зрения в игре только одна комната комплектов, которую я быстро набросал на последнем этаже. Будет здорово, если вы сможете её найти.

Реакция игроков

Большое количество игроков Cogmind скачало игру и она им понравилась. Один даже сказал, что она помогла ему лучше понять Cogmind! Похоже, что и не знающие о Cogmind игроки получили от неё удовольствие.

За первые 8 дней игра была запущена 437 раз (не отдельными игроками, число которых меньше), а скачана… 882 раз. Очевидно, что многие люди скачали её, чтобы сыграть позже. (Я знаю, что некоторые скачивали её несколько раз, потому что я обновлял игру, но не в 2-3 раза больше на одного игрока. Было бы интересно собрать статистику и списки лидеров, как я делал это в Cogmind, но пока я должен сосредоточиться на моём основном проекте!

Хотя POLYBOT-7 и не является демо, она достаточно похожа на Cogmind, чтобы служить ему рекламой, особенно на платформе itch.io, которую я раньше не использовал. (В то же время связь POYLBOT-7 с Cogmind — это косвенный способ найти последнюю на itch.io.) По популярности игра была в топе категории Strategy, а также получала первое место среди большинства выбранных мной тегов, например «пиксель-арт», «пошаговая» и… «roguelike». Она была достаточно популярной, чтобы оказаться в топ 20 игр на itch.io (на котором в тот момент было чуть больше 100 000 игр), а на следующий день она оказалась на заглавной странице.

POLYBOT-7 в рекомендованном на заглавной странице itch.io.

Разумеется, популярность — это всего лишь количество переходов на страницу, поэтому мне помогло то, что я публиковал анонсы на множестве сайтов, плюс солидный летспеер Nookrium, игравший в другие мои игры, в первый день выпуска показал также и P7.

Я продолжал следить за продажами Cogmind: значительного влияния не было, но после выпуска на 7DRL добавление в вишлист на Steam увеличилось по сравнению с предыдущей неделей на 29,4% (20 долларов — это немного дороже, чем бесплатно, плюс игра находится в раннем доступе).

Как бы то ни было, я выпущу ещё один релиз с исправлением нескольких небольших ошибок, а затем положу игру на полку до следующего раза, когда, возможно, удастся её ещё немного отполировать. Думаю, после Cogmind мне стоит взяться за проект поменьше, и POLYBOT-7 уже выглядит как интересная возможность развития во что-то серьёзное за 6 месяцев…

Автор: PatientZero

Источник