Как сделать игровые конфиги силами одного гейм-дизайнера

и не умереть под ворохом данных.

Привет! Меня зовут Сергей, я работаю гейм-дизайнером и люблю изобретать велосипеды. Так уж получается, что обычно я работаю в маленьких командах, даже когда в больших компаниях. И в маленьких командах почти невозможно отвлекать разработчиков на такую ерунду как админка для создания и хранения конфигов. Вот только игры надо как-то конфигурировать, где-то хранить все эти несметные тыщи игровых сущностей и желательно в человекочитаемом виде. Нужны конфиги! :(

Ну, например, у меня в игре есть 42 посоха, 11 зелий восстановления маны, 33 зелья лечения, 100 мечей ... и всё это с разными параметрами и собираются из фрагментов, каждый фрагмент обладает своими параметрами и добывается из сундуков, сундуки лежат в данжене, а данжен расположен на локации, в лесу потерянных гейм-дизайнеров. Все это добро надо как-то внятно описать, иметь возможность удобно редактировать (удобство редактирования это супер важно!) и интегрировать в игру.

Видел случай, когда ГД, бедолага, руками, путаясь в скобках, собирал json, а потом мы правили баланс и выяснялось, что нужно поправить примерно пару-тройку десятков файлов. К слову, именно у этого ГД я подсмотрел, а потом развил идею с конфигами в гуглодоках (Никита, привет!). Я слишком ленив для такой работы, хочется больше времени заниматься ГД, а не правкой бесконечной кучи файлов.

Знакомая для боль? Тогда читайте дальше, в общих чертах расскажу как я справляюсь с этой болью. Если же будет интерес, то расскажу в деталях и про сам подход и про подготовку к экспорту и про сам экспорт.

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

Про сам промежуточный формат и как он конвертится к json можно посмотреть в этой краткой инструкции. Совсем кратко я расскажу ниже.

Зачем изобретать свой формат, да еще похожий на почти всем известный другой формат? Для простоты сбора строк средствами табличек. Мой формат сильно проще, там нет разнообразия типов данных. Формат более человекочитаемый. Да, на конфиги таки часто приходится смотреть глазами и пытаться понять, почему эта фигня, которую ты городил последние пару часов, не работает.

Например, строка:

Будет конвертирована в json как:

Очевидно, что внутри гуглотаблички первую строку собрать сильно-сильно проще и она более человекочитаемая.

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

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

Если я хочу продавать меч тысячи истин не только за золотые, а за золотые, жабьи лапки и два хвоста крыс, то мне нужен список. Что бы не помечать отдельно когда список нужен, а когда нет, то проще всегда заворачивать словари в список, а программистов поставить перед фактом (аргументируя тем, что раз они не захотели писать админку для конфигов, то пусть и не возмущаются). У меня прокатило :)

Отдельно на конвертор в json можно посмотреть в моём репозитории. Там же есть наглядные примеры.

А вот так выглядит реальный конфиг (подразумеваю, что читатель уже заглянул в инструкцию). Это сундуки, самая простая реализация. Если будут желающие, могу рассказать идею подробней.

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

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

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

В моём случае с таблицами активно работают ПМ и тестировщик, не отвлекая меня, когда нужно внести изменение для тестов или для добавления нового контента.

Кстати, у меня экспорт настроен через телеграм бота . Это тоже есть в репозитории.

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

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

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

Конфиги надо готовить. Совсем простые, формата "ключ = значение" делать легко, достаточно двух колонок: в одной ключи, в другой, как не сложно догадаться, значения. Навороченные уже сложней, нужна структура, понимание как оно будет заворачиваться с промежуточный формат и как оно будет разворачиваться в конечный json.

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

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

Первая строка зарезервирована под заголовки либо служебные метки. В нашем случае, это системные метки "key" и "value", по ним конвертор понимает что из этого нужно сделать словарик, и будут экспортированы только эти два столбца.

В остальных столбцах может быть что угодно, например комментарии или расчеты. Столбцы с данными могут даже не находится рядом! В строках ниже идут данные, в key находятся название переменных, в value — значения. На выходе будет валидный json документ.

ВАЖНО! Между строками не должно быть пробелов. Они создадут пустые словари!

Можно заполнять таблицу по другому. В первой строке расположены ключи, в строках ниже — значения. В общем случае строк со значениями может быть много. Важный момент, в странице для экспорта ключи должны быть именно в первой строке! Если хочется дополнительных данных, то всегда можно завести дополнительные страницы с "калькуляторами", там делать все расчеты, а результат складывать во вкладку для экспорта.

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

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

ВАЖНО! В станице экспорта между строками не должно быть пробелов!

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

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

Каждая спец. способность состоит из имени абилки и силы её действия, записей может быть несколько. На каждую абилку придется заводить свою строку. Тут важно разделять предметы пустыми строками и следить чтобы запись для одного предмета не выползли в зону другого. Сами же абилки задаются вполне интуитивно, в первом столбце имя, во втором сила. А вот собираются в одну строку уже немного сложней (помним, у нас должна быть всего одна строка на один предмет). Для этого у меня подготовлены кастомные функции в гуглотаблицах, самая востребованная — toConfigBlock. Описание и примеры как она работает можно найти на странице калькулятора если ткнуть в формулу под заголовком extra_power.

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

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

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

У меня есть набор рекомендаций, которым я следую при работе с конфигами. Пройдусь по ним кратким списком:

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

Можно и не копировать, а создать свой, но советую таки скопировать, там уже подготовлена база, в том числе и из кастомных функций, которые знатно облегчают жизнь при работе со сложными конфигами. Каждая функция документирована. Не ленитесь залезть в редактор скриптов (Tools \ Script Editor) и посмотреть что там есть. Из одного документа в другой функции можно копировать либо подключать как библиотеку.

Внимательно посмотрите на файл с настройками для конфигов. Стоит начать со вкладки "read.me!" и пройтись по остальным вкладкам читая комментарии. Я старался подробно всё описать.

ВАЖНО! Названия страниц, которые экспортируются, должны начинаться с символа собаки "@", иначе они не будут забираться скриптом экспорта.

Итак, конфиг готов. Пойдем дальше!

Я делал по этой инструкции. Там всё просто.

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

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

Да, подразумеваю, что читатель либо немного знает питон либо под рукой есть тот кто его знает. Тут всё реально просто. Правда-правда!

ID таблицы можно найти в урле до этой самой таблицы, это многосимвольный фрагмент, что-то типа "1cbNBO69iUcX7CIx6E55Hy1XDdQ9IJp9mWF3u6g8CDpY"

Сложный вариант будет описан в следующих сериях :)

Это было кратко и сумбурно, но, надеюсь, понятен основной подход к созданию конфигов. Резюмирую в несколько строчек:

Спасибо за внимание! Надеюсь, было полезно :)

ЗЫ: Во избежание душевных травм заранее предупреждаю, я не настоящий сварщик, код пишу от любви к велосипедостроению и безысходности :)