Разработка MVP Mobile Gaming Platform

Цена договорная • наличный расчёт, безналичный расчёт, электронные деньги
14 сентября 2014, 22:17 • 6 откликов • 47 просмотров
Business opportunity
Современные игры предлагают широкий спектр различных способов соревнований между игроками, начиная от таблиц рейтингов и заканчивая соревнованиями в реальном времени через интернет, используя особенности игрового пространства. Однако система, при которой игроки бы делали взносы для участия в совместной игре, и получали за результаты какую-то часть от призового фонда – не является распространенной и интегрированной в игровой процесс.
Вместе с тем, такая возможность может быть широко востребована, поскольку финансовая составляющая может как добавить игре новое качество и служить дополнительным стимулом для игрока (добавляется новая механика), так и мотивацией для игрока за рамками игры (получение новых источников дохода, монетизация своих игровых навыков).
Данная игровая механика также интересна разработчикам игр, как средство вовлечения игроков, однако гейм дизайнеры должны рассчитать корректный игровой баланс с учетом нового фактора. Поскольку финансовый фактор является одним из доминирующих для игроков, неосмотрительное его применение скорее всего разрушит игровой баланс существующих игр.
Поскольку взносы не являются ставками, данная практика не попадает под определение азартной игры, и не подлежит государственному регулированию в большинстве развитых стран.

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

Solution concept
Сервис состоит из трех основных компонентов:
Веб интерфейс игрока для
регистрации и управления данными игрока
внесения средств для участия в соревнованиях
выведения средств накопленных в результате соревнований
просмотра статистики соревнований
API координации с провайдером игры для
регистрации соревнования и его правил
регистрации игроков для участия в соревновании
регистрации завершения соревнования и его результатов
возможности API могут полностью повторять возможности интерфейса игрока, для встраивания соответствующих функций в игровой процесс
Средства администрирования и поддержки для
подключения и управления провайдерами игр
управления работой системы и ее параметрами
оказания технической поддержки для игроков и провайдеров игр
диагностики и выполнения технического обслуживания системы

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

Non-functional requirements
Система должна обеспечивать следующие характеристики:
Надежность
Система должна быть постоянно доступна для выполнения функций API координации с провайдером игры и Веб интерфейса игрока. При необходимости технического обслуживания допускается отключение системы не чаще, чем раз в сутки на срок не более чем 2 часа.
Система не должна допускать случайную утерю данных, полученных в процессе работы.
Безопасность
Система должна обеспечивать средства безопасности необходимые для предотвращения несанкционированного захвата данных игрока третьими лицами.
Система должна обеспечивать средства безопасности необходимые для предотвращения несанкционированного захвата контроля над идентичностью провайдера игры, а также искажения параметров или результатов соревнования.
Система должна обеспечивать индустриальные стандарты безопасности при хранении и использовании чувствительных данных игроков, связанных с их платежными средствами и системами проведения платежей.
Нагрузочная способность
Система должна обеспечить одновременное участие в соревнованиях 50 провайдеров и 50000 игроков с деградацией показателей производительности функций игрока и API не более чем на 30%

Solution architecture and technical design strategy
Логическая структура системы состоит из следующих сервисов:
Game provider REST API
Выполняет функции интеграции с игровыми провайдерами
Web interface
Выполняет функции интерфейса игрока и администратора
Database services
Обеспечивает хранение и целостность данных системы
Integration services
Обеспечивает интеграцию системы со службами выполнения платежей, выполняет регулярные автоматические служебные задачи для поддержки функционирования системы

Рекомендую физическая реализацию системы с использованием облачных средств, предоставляемых продуктами Microsoft Azure, или Amazon Cloud services.
Физическая структура системы представлена следующими компонентами:
Web hosts – 2 и более, количество управляется динамически, в зависимости от текущей нагрузки.
REST service hosts – 2 и более, количество управляется динамически, в зависимости от текущей нагрузки.
Storage services – набор сервисов реляционного и/или не реляционного типа для хранения данных системы. Количество и состав сервисов будет определен на этапе детального проектирования технического решения.
Worker hosts – 2 и более, количество определяется степенью загруженности сервисов.

Предложенная инфраструктура развёртывания в облаке должна содержать необходимое количество load balancer-ов, для равномерного распределения внешней нагрузки между узлами системы. В случае MS Azure этот сервис предоставляется автоматически, в случае Amazon cloud его необходимо дополнительно подключать и настраивать.
Минимальное количество узлов каждого типа – 2, для обеспечения необходимого уровня защиты системы от сбоев.