Программирование сервера - Простая многопользовательская игра - Какой протокол и технологии?

Question

У меня годовой опыт написания клиентского кода, но я не имею опыта работы с сервером. Я хочу немного ограничить вопрос, поэтому я упросту то, чего я пытаюсь достичь.

Я хочу написать код сервера, чтобы два клиента (браузер или iPhone / Android) могли подключиться, когда два игрока подключились, они увидят таймер обратного отсчета до нуля. Часы будут синхронизированы на сервере, а клиенты будут уникально идентифицированы.

Проблема здесь в том, что слово «подключиться» используется людьми для многопользовательских игр? Открыть сокет TCP для двусторонней связи? Вы можете сказать, что я не совсем уверен, о чем говорю. Я надеялся использовать AppEngine, но не уверен, подходит ли он, так как он основан на запросах.

У меня есть некоторый опыт работы с Java, и хотя Erlang звучит как лучший выбор, это то, с чем я просто хочу поиграть и поторопиться, чтобы Java была проще. Мне просто нужно знать лучший способ подключения игроков и т. Д.

Спасибо

Гав

Answer 1

Предлагаю рассматривать настольные и мобильные системы как равных клиентов. Какие варианты тогда?

• Вы пишете сокет-сервер, который будет принимать соединения от клиентов. Но тогда вам также нужно написать некоторый сокет-клиент, даже 2x - для настольного компьютера и для мобильной ОС. И пользователю придется установить этот клиент.

• Вы запускаете веб-сервер (какую бы технологию вы ни выбрали). Он представит некоторые веб-сервисы, которые будут одинаково доступны как для настольных, так и для клиентских ОС. Но все же вам нужно написать клиентское приложение (снова 2x).

• Вы запускаете веб-сервер и делаете все функции доступными по стандартному протоколу HTTP. Таким образом, вам даже не понадобится клиент - почти на каждом настольном компьютере или мобильной ОС установлен хотя бы какой-нибудь веб-браузер. JavaScript обеспечит динамическое обновление вашего тикера.

Answer 2

Есть хорошая серия статей о Сетевом взаимодействии для игровых программистов от того, кто этим занимается.

Answer 3

Вы правы в том, что модель J2EE выходит из строя с требованиями почти в реальном времени или для нескольких игроков. Вы хотите рассмотреть проект игрового сервера RedDwarf. Он делает для игр то же, что и сервлеты для логики busienss, и с открытым исходным кодом.

http://www.reddwarfserver.org

Предлагаю рассмотреть настольный и мобильный системы как равные клиенты. Какие варианты тогда?

RedDwarf имеет подключаемый слой trabsport и может поддерживать любой тип клиента.

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

Однако, если этого не произойдет, вам понадобится что-то более технологичное.

Да, и для чего это нужно, что вы делаете, если вы хотите написать сервер с нуля, тогда НЕ используйте «ServerSocket». Это требует потока для каждого соединения и никогда не будет масштабироваться. Используйте NIO или NIO framewoprk, например, Netty.

Answer 4

Я реализовал приложение клиент / сервер несколько лет назад с java и ServerSocket (http://java.sun.com/j2se/1.4.2/docs/api/java/net/ServerSocket.html). У вас также есть версия SSL.

Итак, вы создаете ServerSocket и ждете соединения. Когда клиент подключен, вы создаете поток, который будет обсуждать с этим клиентом протокол, который вы создали.

http://www.developer.com/java/ent/article.php/1356891/A-PatternFramework-for-ClientServer-Programming-in-Java.htm

Если найден этот маленький каркас:

http://www.bablokb.de/jcs/jcs.html

Одна из самых сложных вещей - это создать свой протокол. Хороший способ узнать, как его создать, - это понять, как работает FTP (или HTTP ...).

Answer 5

Я ни в коем случае не эксперт по сетевому взаимодействию, но если вы не возражаете потерять несколько пакетов (или проверить ошибки в программном обеспечении) и хотите быстрое, бережное общение, вы можете использовать UDP, Я думаю, что большинство чувствительных ко времени программ передачи данных и потокового мультимедиа используют этот протокол, чтобы избежать задержек и уменьшить размер пакета.