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

Дисклеймер

Меня зовут Константин Сахнов. Я делаю игры 17 лет, управляю игровой студией, работал геймдизайнером, продюсером, директором отдела, департамента, студии. Иногда я поддаюсь соблазну поделать что-то руками: писать код на python, рисовать интерфейсы, писать конфиги, считать математику. И да, я полностью осознаю, что задача руководителя - собрать нужных людей, создать условия и организовать работу. Но работа руками помогает мне не забывать главного: мы делаем не только бизнес, мы делаем игры.

Материал написан для начинающих специалистов.

Задача

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

Я преподаю в нескольких ВУЗах России, в частности в Университете Иннополис (программа "Управление разработкой компьютерных игр"), где обучаю студентов созданию концептов и прототипов. Мы создаём прототипы игр с будущими геймдизайнерами, чтобы тестировать механики и гипотезы. И один из инструментов, который я очень люблю - движок для визуальных новелл Ren'Py. В нём есть полноценный питон, 2D рендер и базовая логика. На практике оказалось, что он неплохо подходит для прототипирования некоторых 2D игр, особенно с выборами и диалогами. Есть и другие специализированные инструменты, более удобные для создания платформеров, пиксеальрт игр и т.д. Для этой статьи это не принципиально. Ну и, конечно, всегда есть универсальные движки типа Unity, которые тоже позволяют прототипировать, однако имеют чуть больший порог входа для ГД.

Проектирование экономики

Не буду повторяться, вот здесь писал о том, как подойти к проектированию игровой экономики:

• Игровая экономика Premium игр на примере PC 4х стратегии

• Проектирование экономики F2P игр на основе продуктовых метрик

Мы рассмотрим тему на примере моей игры "Азраил, вестник смерти".

Игровая логика

Азраил представляет собой RPG с элементами ситибилдера на движке Ren'Py. Игра изначально задумывалась для обучения продвижению, создания инфраструктуры бизнеса и творческой реализации.

Первый шаг - игровой цикл. Наша задача - понять место экономики в игровом процессе.

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

Чтобы построить ретранслятор, нужно много ресурсов. Где из взять? Застраивать планеты добывающими строениями. По сути, это ситибилдер.

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

Однако, для строительства большинства зданий также необходим нано-рой. Это основная игровая валюта, "золотые монеты" мира древних богов Азраила.

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

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

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

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

Программная логика

Как руководителю мне важно, чтобы геймдизайнеры:

1. Имели представление о технических возможностях: что делать легко, что долго;

2. Были автономны: контент и базовую логику его поведения можно делать без программистов.

Хочешь принципиально новую логику? Пиши ТЗ.

Вот так будет выглядеть наша экономика в коде:

На схеме выше есть базовый класс ResourceContainer. Единственное, что он умеет, хранить в себе ресурсы с лимитами или без.

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

И вот он уже ложится в основу ключевого субъекта экономики - постройки (класс Building). Постройка имеет статус: работает, выключена, строится, поломана и т.д. С ней можно проводить манипуляции. А главное она является основным участником экономического цикла.

Помимо построек в игре есть источники ресурсов (ResourceSource), также основанные на ResourceChanger. Они решают сразу массу задач. Нужно создать генератор пустоты, который будет производить энергию? Пишем источник. Нужно сделать реликвию, которая будет постоянно производить что-то? Пишем источник. Нужен контракт на поставку или обмен ресурсов? Пишем источник. И так далее: любые кастомные операции с ресурсами, пролонгированные во времени.

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

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

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

Конфиги

Когда реализована логика можно писать конфиги. Весь контент в игре отделён от программной логики, что является базовым правилом разработки. Классы в Азраиле, которым нужен контент, обычно наследуют супер-класс JSONLoadable, который может подгружать все свойства из JSON конфигов, при создании объекта.

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

Единственное исключение - кастомная логика. Отдельные предметы, постройки, боевые способности могут вести себя нестандартным путём. Если бы мы писали на Unity или UE, мы бы всё же вынесли эту логику за пределы кода с помощью болта / блюпринтов. Однако, в случае Ren'Py и python мы просто создали файлик с кастомными функциями и прописали объектам в конфигах, какую функцию и когда следует вызывать.

Программист пишет логику и сообщает ГД имя функции.

В конфиге ГД прописывает название функций на разные события: action (взаимодействие с предметом), drop, on_remove и т.д. Так у предмета loot_nano_swarm_sphere указано при взаимодействии вызвать функцию (call_function) с именем item_function_loot_nano_swarm_sphere.

Не очень изящно, но универсально.

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