КОНФИГИ Ч.1 АРХИТЕКТУРА
Я бы ставил конфиги на первое место по важности для любой игры.
Именно закладывание и продумывание всех нюансов этой части с архитектурной точки зрения, экономит больше всего времени при разработке.
Сделать хорошо сразу — сэкономить уйму времени на всех этапах разработки.
Конфиги решают всего одну проблему:
🔻 Создание/модификация параметров игры/приложения у пользователя без пересборки проекта
Дополнительные требования:
1️⃣ Удобство работы: понятный для непрограммистов софт, не требующий дополнительных знаний
2️⃣ Доступность: отсутствие необходимости платить и устанавливать доп. софт
3️⃣ Гибкость: может потребоваться задавать любые форматы данных в параметрах. От чисел и строк, до листов, формул и прогрессий.
4️⃣ Вариации для окружений: для каждого окружения разработки - своя вариация конфигов
5️⃣ Поддержка A/B тестов: возможность делать несколько вариаций значений одного параметра
6️⃣ Обновление в реальном времени
7️⃣ Частичная раскатка новых конфигов с возможностью отката
На проектах с которыми приходилось работать, я встречал реализации:
🔹 UI в unity, который отдает json, который статикой кладется в сервер и отдается клиентам на старте
🔹 ScriptableObject'ы в проекте
🔹 Поход клиента напрямую в google sheets, скачивание таблички и парсинг при каждом старте приложения
🔹 Использование сторонних SaaS решений
Все эти варианты имеют место быть, но каждый из них, так или иначе, не отвечает всем требованиям.
🤓 Разминка: для каждой из реализаций назовите номера требований, которые сложно будет реализовать?
Ответ:
🔹 UI в unity: не удобно (прогерам под каждое новое поле нужно делать изменения в коде), не доступно (потенциально в большой компании придется на каждого ГД по лицензии покупать). 1️⃣2️⃣
🔹 ScriptableObject'ы - вообще ни одно из требований удовлетворить не может. 1️⃣—7️⃣
🔹 Напрямую в google sheets: только 6️⃣, но у google есть лимиты на кол-во запросов в минуту + credential'ы нужно зашивать в билд, что не безопасно
🔹 SaaS решения: если хорошее решение то проблемы, скорее всего, будут только с 3️⃣4️⃣7️⃣.
В идеальном мире, я бы делал так:
🔸 Маленький проект на C# или скрипт на питоне, который умеет: ходить в google sheet, скачивать табличку, преобразовывать ее в json формат и считать хэш-сумму полученного файла
🔸 Машинка, которая слушает команды и запускает проект/скрипт. По факту любого бесплатного runner'a встроенного в любой remote git сервис
🔸 CDN (Content Delivery Network) мультирегиональный в который кладется финальный json и файлик с хэшом
🔸 Логика на клиенте, которая умеет формировать правильный адрес, чтобы забирать нужную версию конфигов.
Ну и логика сверки локального хэша конфигов и удалённого, для обновления
В Silverfox получилось сделать только так, на остальное не хватило времени и потребностей:
— Часть с созданием json'а была на сервере
— Связь с табоицей, парсинг и отдачей клиенту занимался сервер. От клиента только подключиться к правильной версии😎
А если сервера нет:
— Парсер встроить в клиент
— Класть финальный json ручками напрямую в Firebase
— Использовать Firebase Remote Config как CDN
🎉Тадам 🎉
Сложно? На самом деле черт страшен лишь на вид:
🔸 Для связи с google sheets есть хорошо задокументированная SDK
🔸 Парсер и схема структуризации таблиц уже готова
(не использовал, но писал подобное сам, потому что легко и быстро)
А как вы на проектах работаете с конфигами? — Пишите в комментах!
Вторая часть будет про версионирование🛞
#проект_с_нуля@UniArchitect
Я бы ставил конфиги на первое место по важности для любой игры.
Именно закладывание и продумывание всех нюансов этой части с архитектурной точки зрения, экономит больше всего времени при разработке.
Сделать хорошо сразу — сэкономить уйму времени на всех этапах разработки.
Конфиги решают всего одну проблему:
🔻 Создание/модификация параметров игры/приложения у пользователя без пересборки проекта
Дополнительные требования:
1️⃣ Удобство работы: понятный для непрограммистов софт, не требующий дополнительных знаний
2️⃣ Доступность: отсутствие необходимости платить и устанавливать доп. софт
3️⃣ Гибкость: может потребоваться задавать любые форматы данных в параметрах. От чисел и строк, до листов, формул и прогрессий.
4️⃣ Вариации для окружений: для каждого окружения разработки - своя вариация конфигов
5️⃣ Поддержка A/B тестов: возможность делать несколько вариаций значений одного параметра
6️⃣ Обновление в реальном времени
7️⃣ Частичная раскатка новых конфигов с возможностью отката
На проектах с которыми приходилось работать, я встречал реализации:
🔹 UI в unity, который отдает json, который статикой кладется в сервер и отдается клиентам на старте
🔹 ScriptableObject'ы в проекте
🔹 Поход клиента напрямую в google sheets, скачивание таблички и парсинг при каждом старте приложения
🔹 Использование сторонних SaaS решений
Все эти варианты имеют место быть, но каждый из них, так или иначе, не отвечает всем требованиям.
Ответ:
🔹 ScriptableObject'ы - вообще ни одно из требований удовлетворить не может. 1️⃣—7️⃣
🔹 Напрямую в google sheets: только 6️⃣, но у google есть лимиты на кол-во запросов в минуту + credential'ы нужно зашивать в билд, что не безопасно
🔹 SaaS решения: если хорошее решение то проблемы, скорее всего, будут только с 3️⃣4️⃣7️⃣.
В идеальном мире, я бы делал так:
🔸 Маленький проект на C# или скрипт на питоне, который умеет: ходить в google sheet, скачивать табличку, преобразовывать ее в json формат и считать хэш-сумму полученного файла
🔸 Машинка, которая слушает команды и запускает проект/скрипт. По факту любого бесплатного runner'a встроенного в любой remote git сервис
🔸 CDN (Content Delivery Network) мультирегиональный в который кладется финальный json и файлик с хэшом
🔸 Логика на клиенте, которая умеет формировать правильный адрес, чтобы забирать нужную версию конфигов.
Ну и логика сверки локального хэша конфигов и удалённого, для обновления
В Silverfox получилось сделать только так, на остальное не хватило времени и потребностей:
— Часть с созданием json'а была на сервере
— Связь с табоицей, парсинг и отдачей клиенту занимался сервер. От клиента только подключиться к правильной версии
А если сервера нет:
— Парсер встроить в клиент
— Класть финальный json ручками напрямую в Firebase
— Использовать Firebase Remote Config как CDN
🎉Тадам 🎉
Сложно? На самом деле черт страшен лишь на вид:
🔸 Для связи с google sheets есть хорошо задокументированная SDK
🔸 Парсер и схема структуризации таблиц уже готова
(не использовал, но писал подобное сам, потому что легко и быстро)
А как вы на проектах работаете с конфигами? — Пишите в комментах!
Вторая часть будет про версионирование
#проект_с_нуля@UniArchitect