Серверная архитектура для многопользовательской игры?
Я планирую создать небольшую многопользовательскую игру, которую можно запустить как java-апплет или флеш файл в веб-браузере. Я раньше не программировал сервер, поэтому мне интересно, какая у меня архитектура сервера.
Мне будет легко создавать файлы perl/php на сервере, которые контакты java/flash связывают, чтобы обновить позицию/действия игрока и т.д. Но я рассматриваю вопрос о том, должен ли я получить выделенный веб-узел, какую ОС использовать, какую базу данных и т.д. Кроме того, необходимо учитывать количество используемой полосы пропускания и масштабируемость.
Другим вариантом может быть использование облачной системы хостинга (в отличие от выделенного сервера), поэтому они позаботятся о добавлении дополнительных машин по мере роста игры. До тех пор, пока каждый сервер запускает основные файлы perl/php для обновления базы данных, он должен работать нормально.
Еще одним вариантом может быть использование механизма приложений Google.
Любые мысли о архитектуре сервера, выборе OS/базы данных и мой метод использования скриптов perl/php/python для программирования на стороне сервера является хорошим, будет оценен!
Ответы
Ответ 1
Вам нужно разъяснить больше об игре и больше думать об архитектуре, а не о конкретных деталях реализации.
Основной вопрос заключается в том, будет ли ваша игра находиться в режиме реального времени, на основе поворота или с длинной задержкой (например, по электронной почте). Еще один вопрос: хотите ли вы заморозить состояние для последующих перезагрузок.
Я настоятельно рекомендую заранее выяснить, будут ли размещены все игроки в одной игре на одном сервере (например, 1000 из 4 игроков по сравнению с 4 матчами по 1000 игроков в каждой). Если возможно, пойдите с первым и придерживайте всех, кто находится в одной игре под одним и тем же сервером. У вас будет достаточно сложное время для синхронизации нескольких клиентов с одним сервером, а не с несколькими серверами, против которых синхронизируются игроки. В противном случае определение последовательности является проблематичным.
По возможности, каждый клиент связывается с сервером, а затем сервер распределяет обновления клиентам. Таким образом, у вас есть одно "официальное состояние", и вы можете выполнять различные разрешения конфликтов, фантомы и т.д. Peer to peer дает лучшую производительность в более быстрых играх (например, FPS), но вводит массу проблем.
Я не могу для жизни меня видеть какую-либо убедительную причину, чтобы сделать это, и perl или PHP. Ваша игра не основана на Интернете, зачем писать ее на веб-ориентированном языке? Используйте хороший старый J2EE для сервера и обменивайтесь данными со своими клиентами через XML и AJAX. Если возможно, запустите реальное приложение Java на клиентах, а не на сервлетах. После этого вы можете использовать JMS, который отнимает у вас огромную нагрузку, абстрагируя много деталей связи для вас.
Ответ 2
Для архитектуры вашего сервера вы можете посмотреть код трех колец. Они написали несколько очень масштабируемых игр на Java (как на стороне клиента, так и на стороне сервера).
Ответ 3
Я бы также отговаривался от использования PHP, также HTTP-это лучшая идея, поскольку она без гражданства и разговорчивости. Я некоторое время работал в компании, которая в настоящее время разрабатывает действительно массовую многопользовательскую игру. Back-end - это простой JVM (подключается через tomcat несколькими клиентами и с мобильных телефонов по одному на каждого клиента). Поэтому я знаю, что чем меньше данных вы передаете меньшим буферам, которые вам нужны на сервере, тем больше клиентов на одной машине, а также более быстрые ответы. Также рассмотрите безопасность, https стоит довольно дорого, особенно если вам нужно передавать графику и звуки. Биннарный протокол с клиентским контейнером, отличным от браузера, сделает все возможное (хорошим выбором является протокол переключения для времени отладки разработки). Может быть, звучит сложно, но это не так.
@Sarah хороший намек, спасибо тоже;)
