Идеальный подход к созданию многопользовательского игрового сервера для Android (игра с очень простой графикой)

Question

Идеальный подход к созданию многопользовательского игрового сервера для Android (игра с очень простой графикой)

1

Я работаю над Android-игрой, основанной на Playing Cards (точнее, Bridge), которую могут играть сразу четыре игрока. И будет доступен сервер через Интернет, к которому подключаются устройства, и сервер будет отслеживать ход игры.

Моя игра очень проста, когда дело доходит до графики, что я могу достичь пользовательского интерфейса без использования игрового движка.

Хотя я должен был создать игру (клиент) для Android, я хотел создать сервер, который может быть RE-USED в будущих портах игры, даже если он портирован на другие мобильные платформы или даже на рабочий стол.

Поэтому я подумал, что первый возможный кандидат на серверную архитектуру имеет RESTful Web Service, чтобы я мог использовать сервер с любым клиентом, пока клиентский конец программирования поддерживает методы HTTP.

Но позже я понял, что, поскольку в течение игрового сеанса будет постоянная связь между устройствами и сервером, было бы нормально иметь такой сервер, где соединение будет прекращено после ответа на запрос (я не уверен, что это правда)?

Или я должен использовать DatagramSocket и DatagramPacket способ Java для сборки сервера? (это обеспечит повторное использование сервера?)

Любые другие предложения или рекомендации?

Примечание. Я не новичок в Java или сетевом программировании на Java, но я новичок в разработке Android и создании сервисов RESTful.

Kushal 29 май 2012, в 15:08

Источник

Теги:

android

rest

sockets

2 ответа

3

Во время написания для Android не планируйте постоянное соединение. Соединения ломаются очень часто (и часто по уважительным причинам, например, переход от GSM к Wi-Fi). HTTP - отличный, популярный и проверенный выбор (вы получаете несколько более низких уровней стека на своем пути и можете сосредоточиться на обработке полезной нагрузки).

BTW: говорить, что "веб-служба RESTful" в этом контексте бессмысленна - вам нужен HTTP-сервер, который обслуживает данные и принимает команды, а не ментальную структуру для структурирования вашей логики игры в виде набора ресурсов с сохранением состояния.

fdreger 29 май 2012, в 11:07

Ещё вопросы

Elemental · Accepted Answer · 2012-05-29T11-47-00.000Z

Я думаю, что ваш HTTP-план подходит для этой ситуации, я не думаю, что вопрос о постоянстве соединения имеет значение для медленной игры, основанной на поворотах, такой как мост.

Редактирование: как было предложено tdreger, почти все Android-документы рекомендуют вам планировать рутинный сбой подключения и восстановление через другой канал, так что соединение html кажется наиболее устойчивым решением.

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

Я также считаю, что разработка Android будет проще, так как Android и приложения имеют сильную поддержку этих HTTP-подобных подключений.

Итак, я должен продолжить RESTful путь? Я не начал много копаться в создании RESTful-сервисов в Java, так как я решил сначала определить ситуацию до того, как я начну работать, а потом понял, что RESTful здесь не является решением.
Да, я думаю, что Restful - это способ действовать надлежащим образом, как говорит fdreger, ниже restful - это скорее стратегия, чем конкретная технология.