Comments 17
Чаще всего поистине великолепные идеи убивает производственный ад и ошибки проектного управления.
Даже чаще, чем отвратные способы монетизации? У вас есть статистика?
Полезный материал, спасибо
Очень крутой и огромный материал. Спасибо, Константин.
Можете рассказать подробнее, как подключали гугл таблицы к SQL с 4 скриншота? Что можно почитать на эту тему?
Мы не то, чтобы подключали google таблицы к SQL серверу. Игра берёт в качестве входных файлов полотно JSON конифгов. Именно его и создают Гугл таблицы. Просто мы структурировали их по принципам SQL. Выделили внешние ключи, определили связи между таблицами и типы данных. Это скорее для удобства понимания и формирования структуры из данных конфигов в движке игры.
В одной из предыдущих игр мы экспортировали данные из Гугл таблиц в SQL, т.к. считать баланс игры в таблице удобнее. Для этого табличка генерировала sql-скрипт, очищающий соответствующую таблицу в базе данных и вставляющую новые строки для каждой сущности.
А существующие инструменты, помимо гугл таблиц, которые выгружают JSON и сразу генерят код C# для загрузки не рассматривали?
Нет, т.к. удобно сразу в гугл таблицах делать и баланс и контент.
Можете посоветовать, что посмотреть из подобных инструментов?
https://habr.com/ru/articles/665784/
вот тут человек перечислил популярные инструменты
Спасибо, отличный баланс, мы пользовались похожим подходом для многих проектов.
Те, кто сомневается, может попробовать с таблицы для локализаций - делается за пол часа и сразу готова к работе.
От себя могу добавить, что возможно удобнее будут строковые ключи как ID зданий.
Программисты могут поворчать, типа выше вероятность ошибок (это не так, числовые id тоже легко поломать из конфигов) но, как программист говорю, строковые id - это оптимальный компромисс между человекочитаемостью и использованием в коде.
Спасибо за статью, несколько вопросов/моментов:
Во время формирование JSON'ов довольно большой шанс ошибиться.
Как именно в итоге эти JSON'ы в билд попадают и есть ли возможность без обновления билда выкатить новый баланс?
Как это всё мапится на классы? При изменении структуры json'ов нужно каждый раз дёргать разработчиков, чтобы они парсеры/маперы допилили?
Часть этих (и других) проблем, например, Balancy решает.
1. Цель этой автоматизации как раз в том, чтобы один раз проверить структуру JSON-скриптов на ошибки и дальше понимать, что раз они генерируются автоматом, там уже исключён человеческий фактор. Я мало описал логику проверки, но помимо онлайн валидаторов, есть проверка, встроенная в саму таблицу. К примеру, это условное формативрование, которое подсветит ячейки, если данные введены в неверном формате или не указан один из обязательных параметров.
2. Сейчас скрипты переносятся руками: копируем и заменяем файлик в проекте. В планах продолжить разделение кода и настроек контента, подгружая все данные через Addressables. Это позволит упростить как сборки, так и доставку патчей.
3. Структура JSON-ов у нас меняется очень редко. Дизайнеры продумали механику, согласовали с продюсером, и она ушла в реализацию программистам. Мы стараемся делать так, чтобы программисты вообще никак не касались контента. Нужно что-то настроить? Ок, геймдизайнер придумал, значит настраивай сам. Программисты дают ему для этого инструментарий. В случае контента это просто загрузка конфигов, в случае диалог - это редактор нод в самом Unity, в случае левел-дизайна карты - это самостоятельно реализованный редактор. Т.е. логика у нас меняется очень редко, а контент геймдизайнеры могут менять постоянно и делать переборку Билла.
П.С. про Balancy я где-то слышал. Судя по списку отзывов, это всё мои коллеги. Думаю, поглядеть. Спасибо за наводку.
Технический геймдизайн. Конфиги, баланс и контент на примере PC стратегии