Главная » Хабрахабр » [Перевод] Как я (пере)делал «рогалик» за неделю

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

image

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

UI

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

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

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

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

Макет UI №2

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

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

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

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

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

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

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

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

Cogmind годами разрабатывался с предположением о том, что фон будет чёрным, поэтому в этом режиме анимации не всегда выглядят идеально. Однако фильтр низкого контраста сам по себе является довольно большим хаком. Все эти изменения внесены в Cogmind (который во многом выиграл от этого 7DRL). Хотя у меня определённо не будет времени на обновление огромного количества частиц, используемых оружием, я по крайней мере могу улучшить внешний вид UI. Я всё равно хотел сделать это рано или поздно, но в этом случае работа сместилась на время 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 является управление инвентарём, и я подумал, что здорово было бы его ограничить. Очень медленно! Поэтому дальше я подумал об упорядоченной «очереди» деталей, которые прикрепляются после утери предыдущих, но это казалось слишком сложным для того, что задумывалось как простая и сжатая игра.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Хотя в игре больше нет заголовков типов, детали автоматически сортируются, а слева показывается их 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 появились заполненные тайлы пола, потому что так игра выделялась на фоне остальных; кроме того, Каспер хотел поэкспериментировать, а я не был против, потому что в конце концов сработал бы любой подход). Как видно из показанного выше скриншота, полы тоже изменились — в них используются жирные точки вместо полноразмерных тайлов пола.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Все предметы двигательных установок из 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, который может атаковать цели сквозь стены, может иметь такие устройства). Например, у Aimbot есть Structural Scanner, чтобы у игрока был частый доступ к нему для распознавания скрытых дверей — не забывайте, их в POLYBOT-7 стало гораздо больше!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

«Чтение на выходные»: 25 материалов для начинающих любителей винила

Сегодня мы подобрали материалы из «Мира Hi-Fi» специально для начинающих и всех, кто хотел бы познакомиться с экосистемой винила, подобрать проигрыватель и разобраться с настройкой. Фото Best Picko / CC Выбор проигрывателя Назад к винилу — вперед к настоящему звуку. ...

[Перевод] Оптимизация рендеринга сцены из диснеевского мультфильма «Моана». Часть 2

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