[Перевод] Как я (пере)делал «рогалик» за неделю
Неделя с 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 начинается немного раньше, чем сама неделя. В январе я прошёлся по нескольким дизайн-документам, время от времени открывая последний для внесения изменений, когда он становился хаотичным или я хотел внести значительное изменение для реорганизации всего в свежем документе, чтобы получить хорошее представление о текущем состоянии дизайна. В 2012 году у меня было много свободного времени на подобную работу, однако в этом году я был довольно сильно занят разработкой Cogmind и другими вещами, поэтому не мог необходимого времени на дизайн. К 7DRL я пришёл с технически завершённым высокоуровневым дизайн-документом, однако будь у меня чуть больше времени, я бы усовершенствовал его гораздо сильнее.
Перед 7DRL я также написал анонсы релизов в своём блоге и на itch.io. На самом деле я довольно медленно пишу, к тому же я знал, что у меня не будет времени на хорошие анонсы релизов в течение этой недели. В результате позже я внёс небольшие изменения в соответствии с изменившимся дизайном, но в основном анонсы остались такими же, позже я просто добавил несколько скриншотов. Кроме того, это было хорошей возможностью познакомиться с itch.io, с которым я раньше не имел дела. Было бы забавно как-нибудь всё испортить после завершения работы над 7DRL!
Перед началом недели я даже задизайнил вариант обложки с помощью неиспользованного тайлсета для Cogmind:
Дорелизный черновой дизайн коробки.
Это упростило создание дизайна коробки для POLYBOT-7 в конце недели, после того, как Каспер завершил тайлсет. Можно заметить схожесть:
Финальный дизайн коробки!
UI
Кроме работы над диздоками я также потратил немного времени в REXPaint, создавая макеты UI. Изначально я стремился к тому, чтобы уместить всё необходимое в сетку 106×30, и я тестировал интерфейс с самого начала, потому что знал, что ограничения могут повлиять на механику.
Этот первый макет я выбросил довольно быстро:
Макет 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 прямо из битового изображения.
Кроме того, это означало, что благодаря всего четырём разным размерам можно обеспечить поддержку всего диапазона разрешений. При базовом квадратном тайле карты размером 12×12 в разрешении 768p используется шрифт 24×24 (просто созданный с помощью 12×2), в самом популярном на сегодня разрешении 1080p используется шрифт 36×36 (12×3), а выше — размер 48 (12×4, 1440p) и 72 (12×6, 2160p). Текст использует ячейки половинной ширины, которым тоже нужны четыре размера с базовыми измерениями 6×12.
Мои заметки, написанные перед 7DRL. Я ношу с собой в кармане сложенные листы бумаги и набрасываю на них мысли. Мой сын решил позаимствовать этот лист и нарисовал что-то на обратной стороне.
Дизайн геймплея
Основной целью дизайна было создание быстрого игрового процесса в стиле Cogmind, который можно было оценить за «кофе-паузу», поэтому всё вращалось вокруг этой идеи. В игровом процессе должно приниматься меньше решений, поэтому многие системы взаимодействий необходимо было убрать. И не только системы, но даже и визуальные эффекты оружия, которые отвлекали и поэтому могли замедлить игрока. С учётом этого, за неделю я хотел исправить все медленные анимации или исключить большинство видов оружия, в которых они использовались.
Сравнение анимации электромагнитного импульса в Cogmind с более быстрой анимацией из POLYBOT-7. (Из соображений механики я хотел сохранить ЭМИ в игре, поэтому мне пришлось их ускорить.)
Ещё одним шагом по снижению количества принимаемых решений стало полное удаление инвентаря, хотя к такому решению я пришёл не сразу. Заметьте, что в макете №2 выше есть инвентарь, который я поначалу представлял себе как модальное окно, позволяющее собирать детали, а затем прикреплять их по собственному усмотрению. Очень медленно! Даже со всеми функциями автоматизации одним из самых медленных аспектов Cogmind является управление инвентарём, и я подумал, что здорово было бы его ограничить. Поэтому дальше я подумал об упорядоченной «очереди» деталей, которые прикрепляются после утери предыдущих, но это казалось слишком сложным для того, что задумывалось как простая и сжатая игра.
Потом меня озарило, что необходимости в инвентаре вообще нет — по сути «инвентарём» игрока будет мир, что упрощалось благодаря уже имеющейся возможности притягивать к себе лежащие вокруг детали. Это оказалось просто и обеспечивало интересные последствия для игрового процесса.
После прикрепления детали не могут удаляться по отдельности, потому что тогда автоматическое прикрепление деталей будет бессмысленным, потому что тогда игроки просто будут отсоединять ненужные, ведь остальные лежат поблизости (больше тягомотины!). Поэтому кроме потери из-за разрушения (медленно и ненадёжно), нам нужен и другой способ. И тут появляется ещё одна важная часть плана: механика «Очистки».
В Cogmind уже есть команда «go naked», уничтожающая все прикреплённые части, чтобы успеть сбежать в случае крайней необходимости. Поэтому преобразование её для POLYBOT-7 приведёт к гораздо лучшему игровому процессу. Вместо уничтожения всех деталей он может уничтожать случайную их половину и выбрасывать другую половину, оставляя вероятность сохранения потенциально полезных деталей и не создавая огромного количества деталей вокруг, заново забивающих все слоты. Эта механика позволит игрокам «перетасовывать» свою конфигурацию, когда 1) она становится совершенно несбалансированной и бесполезной, или когда 2) они находят какие-то хорошие предметы, которыми хотят воспользоваться.
Из разговоров с игроками в Cogmind (за неделю до этого я показал им общий план) стало очевидно, что наличие неограниченной «Очистки» не сработает и её легко будет обойти, поэтому перед каждым использованием я добавил «подзарядку», выполняемую вытягиваемой из игрока энергией. Это может быть интересным, потому что она будет гораздо быстрее при наличии большой энергии. Кроме того, после «Очистки» игрок становится слабее, что вынуждает его серьёзно оценивать ситуацию перед выполнением этого действия. Я расскажу об этом чуть позже, потому что с такой системой возникли проблемы и сейчас она работает иначе.
Также в следующем разделе я расскажу о других уникальных механиках.
Первым этапом недели 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, но сейчас демонстрирую большинство из этих функций с помощью тайлов, которые были созданы позже.)
Когда все эти предметы валяются поблизости (особенно в виде оставшихся после боя трофеев), и большая часть из них остаётся неиспользованной, нужен какой-то способ избавиться от всего этого хаоса:
- когда карта захламлена, становится сложно искать подходящую деталь
- из-за механики притягивания лишний мусор делает задачу притягивания нужных предметов ещё более сложной задачей
- практически всегда поблизости будет набор разнообразных деталей, что с лёгкостью позволяет избежать наличия пустых слотов (т.е. и проще выживать в целом)
В 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). Хотя этот «рубильник» переключить было просто, его не переключали уже много лет, так что, разумеется, он не был полностью функциональным… После исправления всех багов я также принял во внимание ориентированные двери — новую фичу, для быстрой реализации которой потребовались хаки, и несмотря
