Pull to refresh

Comments 9

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

Не смог понять разницу, ведь конфигурацию и ресурсы для игры на внешний сервер размещает точно так же команда разработчиков после тестирования. То есть у вас принципы апдейта не поменялись (разработка-тестирование-подготовка ресурсов для апдейта-апдейт), поменялся транспорт (вместо http get, ли что там было, у вас стали сообщения)? Или я что-то еще не знаю?

Дело в том, что при стандартном пайплайне публикации патча через Google/Apple есть этап review игры. Он может занять до недели времени, если не повезет. QA могут пропустить и блокер в балансе на поздних этапах игры и что-то еще. А вот правка баланса сначала в sandbox, проверка изменения и деплой на боевой сервер без ревью стора произойдет как только фикс будет утвержден QA командой.

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

тогда непонятно почему вы решили что Unity == Android? Ну либо в начале статьи об этом стоит написать, так как формально вы пишете тогда не про юнити, а про особенности релиза игр на определенных площадках.

PS: по секрету, если бы в первом абзаце я прочитал слово Android, то я просто закрыл бы статью и не тратил время..

Спасибо за замечание. Обязательно учту его

Отличная статья, подающая надежды))

Хотелось бы побыстрее узнать о связке с ECS, авторизацию, оптимизацию трафика и маппинге моделей =)

Автор, пиши еще!

Как организовать обработку данных на клиенте и связать с ECS геймплеем

А причем здесь ECS геймплей на клиенте? Используете ли вы ECS на сервере?

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

Самое загадочное в .net это масштабирование SignalR, какие лимиты, что будет если одинаковые хабы будут на разных машинах, нужно ли масштабировать хабы, а не группы внутри одного хаба, какие лимиты и как паралелить если допустим есть 1 супер большая группа. Как при этом работать с fallover допустим если образ SignalR развернут в docker compose в N сервисов с внутренней случайном балансировкой от докер композа.

Ни разу нигде в интернатах не встречал такую статью. Хорошо бы чтобы ктото на хабаре такую сделал на конкретном примере.

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

Sign up to leave a comment.

Articles