Я работаю инженером-программистом в игровой компании, и наша команда разработчиков придумала новую игру для Android и iOS (казуальная изометрическая игра, такая как Gardenscapes). Наша команда должна настроить бэкэнд-систему для игры (да, это будет сетевая игра, в которой взаимодействие клиент-сервер происходит через вызовы REST). У нас есть опыт работы с унаследованными системами, но мы на самом деле не создавали системы, необходимые для игры и связанных с ней с нуля. В связи с этим мы обращаемся к сообществу в поисках необходимых руководящих принципов для создания такой системы подающей надежды командой, такой как мы ...
Я собрал несколько требований, которые, по моему мнению, должны были принять во внимание, чтобы принять решение о дизайне бэкэнда и выбранной платформе:
В игре будет изометрический геймплей и мета-геймплей. Как это
Изометрические, это потребует обновления в режиме реального времени. - Таким образом, мы должны добавить веб-сокет, который я считаю (любые предложения будут полезны). А также
это также означает, что будут фоновые работы, которые требуют
завершено сервером позднее.
Данные об игре (или рыночные данные) для игрового процесса будут
Управляется на сервере командой Live Ops. Итак, нам нужен инструмент администратора для этого. Есть, конечно, несколько объектов в игре и
безусловно, будут связаны друг с другом (в настоящее время это в основном
один ко многим, но в будущем может быть много к одному и
также многие ко многим). Итак, я думал, что MySQL будет лучшим
опция.
Ожидаемое общее количество установок вначале (первые 3 месяца)
на 1 миллион и в течение жизни он может доходить до 5 миллионов. DAU может быть около 100K. В игре тоже будет метагейм, так что
Ожидается, что игрок проведет 50% времени в мета-геймплее.
(в это время запросы не будут отправлены) и 50% в изометрии
игровой процесс (где будут запросы к серверу на обновления) в
данный сеанс. И продолжительность сеанса может быть около 30 минут. За
это, мы должны быть готовы к шардингу с самого начала? Если так,
Я хотел бы понять, что является предпочтительным (шардинг в приложении
слой против слоя БД) и причина этого.
У меня хороший опыт работы с рельсами (6 лет опыта работы) и приличный опыт работы с javascript на стороне сервера (NodeJS, express и некоторые модули, прикрепленные к ним)
Мой первоначальный наклон был к рельсам, так как я считаю, что это достаточно хорошо решает вышеуказанные проблемы (пожалуйста, поправьте меня, если я ошибаюсь!). Хотя мне очень понравился асинхронный стиль обработки в NodeJS (я разработал некоторые API-интерфейсы для этого), я не уверен, что у него есть многофункциональная инфраструктура MVC (я использовал единственный экспресс), такой как rails.
Большое спасибо за терпение, проявленное к вышеуказанному запросу!
В ожидании ваших ценных вкладов ...