Итеративный подход

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

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

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

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

Перейдём к большей конкретике. В разработке игры это всё означает, что приступая к более менее полноценному прототипу мы фокусируемся на том, чтобы там работала какая-то самая стержневая механика и определимся с основными проблемами, которые требуют решения на ранних этапах. То есть, проектируя таким образом Super Mario, нам нужен условный объект-персонаж, который умеет прыгать и бегать в стороны, вот с его отображением и написанием кода прыжков-движения мы и будем разбираться. Для Quake нам понадобится создать контроллер с видом от первого лица и реализовать возможность создавать пули по нажатию кнопки (которые поначалу даже никуда не будут лететь, просто создаваться). Для тактической стратегии - логику поведения фигурок-юнитов на поле сражения, возможность их двигать и атаковать ими.

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

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

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

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

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

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

Прототипирование Microspace project в Godot engine

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

Microspace project

Концепция игры жанра jrpg, в сеттинге сюрреалистического космоса. В качестве героев выступают разумн...

habr.com

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

В качестве движка был выбран Godot engine, а конкретнее версия 3.2.1, язык GDScript и gles3 рендер. В целом данный проект относится к категории достаточно код-интенсивных, всё-таки это далеко не аркада, где можно обойтись вобще без программирования. Выбор GDScript'а не особо принципиален, просто на нём быстрее писать внутри редактора, без открытия лишних окон, а так - вся логика без каких-то особых проблем переносится на тот же C#. Gles3 тоже не принципиален, но я взял более мощный рендер в качестве целевой платформы, а на упрощённом всегда можно собрать отдельную версию, только потребуется переработать частицы.

Началось всё с набросков карты сектора и написания контроллера, чтобы добавить модель кораблика и полетать по получившемуся "космосу" (попутно придумалась музыкальная композиция для глобальной карты):

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

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

Подготавливая приблизительные иконки с персонажами/предметами для инвентаря я, уже заранее думая об удобстве будущего их использования, завёл пару текстурных атласов в формате png, размерами 512 на 512. Таким образом в каждом можно держать по 64 иконки размерами 64 на 64. Godot, кстати, сам умеет сшивать несколько выбранных картинок в атлас, но у меня почему-то эта его функция не срабатывает, поэтому набросал заготовки атласов в графическом редакторе.

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

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

В следующем ролике уже можно более явно разглядеть очертания планируемой концепции, хотя кроме моментов самого процесса тут есть перебивки на работу в редакторе:

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

Архитектура приложения

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

Собственно, про некоторые особенности движка Godot я рассказывал вот в этой статье:

Godot, 1000 мелочей

Недавно открыл для себя Godot engine, опенсурсный игровой движок. Делюсь некоторыми приёмами и замет...

habr.com

А внутренняя архитектура прототипа космической jrpg следующая: есть основная 2д сцена - стартовый экран, куда попадает пользователь. При выборе уровня к корню стартовой сцены крепится сцена космического сектора, в которую дочерним объектом подцепляется звездолётик и на него навешиваются слушатели некоторых сигналов. Сама стартовая сцена при этом скрывается, но её скрипт обрабатывает сигналы от кораблика - столкновение с врагом, открытие инвентаря, попадание в зону планеты. Когда игрок открывает инвентарь, то стартовая сцена снова показывается, но отображает не менюшку входа в игру, а другую свою панельку - окошко инвентаря.

1 - двухмерная сцена стартового экрана, 2 - скрытие первой сцены, прикрепление сцены трёхмерного мира и добавление внутрь неё сцены-кораблика, 3 - отображение сцены мира с вложенным в неё кораблём

А - показана только сцена мира, Б - поверх сцены мира отображается стартовая сцена с окном инвентаря, в то время как её окно с начальным меню скрыто

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

1 - столкновение с врагом, 2 - стирание мира, 3 - подключение боевой сцены, 4 - установка параметров и отображение сражения

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

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

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

Где брать идеи

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

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

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

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

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

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

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

В плане разработки стоит сосредоточиться на том, что вы реально сможете сделать сами, хотя планировать и задумывать можно и довольно сложные конструкции. Но лучше быть реалистами и именно в реализацию на практике брать что-то, хотя бы частично и в общих чертах, достигаемое. То есть не говорить что "вот был бы у меня движок А, а не Б", или "вот сделают мне ролики и крутые модели, тогда я и сваяю нетленку". А просто взять и что-то сделать. Хотя бы в тетрадке нарисовать, хотя бы приблизительно, хотя бы общий план. Нарисовать одного персонажа, а не триста. Написать не рассказ, но диалог. Это всё вроде бы мелкие и незначительные шаги, но они раз за разом формируют новые условия, от которых можно оттолкнуться ещё дальше, ещё дальше и ещё дальше.

Вот нам нужна игра про партию героев, которые сражаются с врагами, исследуют различные города, имеют систему развития, разные предметы... Начните с одного героя. Одного врага. Сражение с одной только опцией - удар. Вместо города несколько примитивов изображающих дом. Отображение пустого окошка с информацией о герое. И так далее. Потом героев станет два. В статистике появится имя. Врагов станет двое. Кроме ударить, появится вторая опция, пусть она даже сначала не работает. Коробок-домов станет несколько. Появится отображение содержимого сумки, пусть сначала только одна ячейка. Затем героев станет три, и можно будет менять их местами. Враги станут попадаться группами по 2 или 3. Появятся ещё боевые опции. Появится вторая область с "домиками", до которой можно добраться. Итак далее.

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

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

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

На этом я и закончу статью, спасибо за внимание.

Итеративный геймдизайн, Godot и мир маленьких планет