Как реализовать мультиплеер на socket.io?

Question

[artem_music]

Добрый день, есть вопрос, как организуется поточность в мультиплеерных играх?

Например, есть два танка-объекта, управляемые двумя игроками. Как правильнее и удобнее реализовать мультиплеер? Когда передавать данные о действиях? На данный момент вижу два варианта логики:

• Навесить обработчики на кнопки клавиатуры - по каждому клику отправлять запрос серверу, который в свою очередь оповестит второго игрока о действиях первого.
  
• Проверка позиции всех игроков с определенным временным интервалом - то есть действие инициализируется сервером, а не действиями игрока.
  

В первом случае экономится трафик: нет действий со стороны игроков - нет трафика. Как сделать правильнее? Толкните пожалуйста в нужном направлении.

Answer 1

[lxfr]

При каких либо действиях лить данные о состоянии объектов в базу (какую вам виднее), при попадании данных в базу уведомлять всех подключенных клиентов об этих состояниях, на основе этих данных рендерить позиции. Перед сохранением в базу проверять на читы (а может ли такое состояние быть?).

Данные отправлять только при действиях, соответственно.

Comments

[artem_music]

А если будет одновременно 10-100-1000 игроков, и они одновременно будут делать какие-либо действия, база разве не заблокируется?

[Сергей]

Сразу видно ответ PHP-шника, так никто не делает в реалтайм-играх.

[lxfr]

artem_music: а вы видимо забыли что можно использовать nodejs и nosql базу, как вариант

[lxfr]

Сергей: а вы наверное кодите сразу на байт коде java и данные передаете не через сокеты а собираете пакеты вручную

[Сергей]

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

[lxfr]

Сергей: вся ваша аргументация "я гений а вокруг одни идиоты", ничего конкретного вы так и не смогли аргументированно оспорить, и с чего вы взяли что опыта нет, у вас просто ЧСВ завышенное, вот и всё

[Сергей]

Ну обижаться не стоит, просто глупости не надо писать про базы.

[lxfr]

Сергей: так вы написали глупость, напридумывали про какие-то обиды, вас ткнули носом в недостаточность аргументации, и вы по прежнему разводите демагогию, вместо ответа на конкретно поставленный вопрос: что не так в том, что было описано ранее, конкретно, и по пунктам.

[Сергей]

> При каких либо действиях лить данные о состоянии объектов в базу
1. Читаю: лить все изменения лить в базу sql/nosql для каждого действия.
На что автор вопрос резонно указывает что 10-100-1000 соединений ваша база не проглотит столько информации.
2. На что вы упорно советуете nosql и nodejs. Ок пусть nodejs, но если бы вы сталкивались бы вообще с созданием серверов в общем, и для игр в частности. То знали бы, что никакая база не может проглотить
поток действий и изменений игрового мира в реалтайм играх, ну если только вы в пошаговую не играете.

Делаем вывод, что вы не сталкивались с этим, а написать только свою теорию.

[lxfr]

artem_music:
вот вы пишите "А если будет одновременно 10-100-1000 игроков, и они одновременно будут делать какие-либо действия, база разве не заблокируется?"
Это разве не слова дилетанта, который боится 10 тысяч подключений? Это уже говорит о том, что вы себе плохо представляете как их подключить. Но ведь автор явно говорит что хочет использовать SOCKET.IO, и, вероятно, соотвествующую для этого базу, которая ничего блокировать не будет, а если и будет, то будет это делать только тогда, когда надо.

[lxfr]

Сергей: nosql и нода прекрасно тянут 10 тысяч соединений, вы не знали?

[Сергей]

Я посмотрю на вашу базу, которая будет обрабатывать изменения игрового мира от каждого нажатия кнопки от каждого из 10 тыс игроков. Удачи в профессии.

Answer 2

[Сергей]

Делать специализированный сервер.
Внутри него будуте объекты, отвечающие за:
1. Игровую ситуацию на поле (состояние поля).
2. Состояние игроков.

Игроки путем воздействия на объекты из п.2. Заставляют тех производить воздействие на объекты из п.1.
Объекты из п.1. генерируют соответствующие события для объектов из п.2, которые в свою очередь передают изменение своего состояния и состояния игрового поля удаленному клиенту.

Для реализации данной логики идеального подходит Erlang. :)

Comments

[lxfr]

И чем это отличается от того, что я выше описал? И да, Erlang не входит даже в десятку востребованных языков разработки.

[Сергей]

Ну если вы под "базой" понимаете бизнес логику игры, хранящуюся в памяти сервера, и обрабатывающую все изменения игрового мира (а не только хранение информации), то я с вами согласен. Но ваш контекст был -- только хранение, без обработки. Да я всякие nosql для такого дела не подходят, слишком большой оверхед на передачу туда и обратно. Одним словом - храните все в памяти.

[Сергей]

По поводу Erlang. По вашему если что-то делать, то нужно выбирать востребованый у других инструмент ? или очень хорошо подходящий под данную задачу ? я думаю второе.
а ваша nodejs мало того что не предназначена для параллельной работы, так и упадет там где Erlang будет жить спокойно.

[Сергей]

Писать на коленке сервисы на nodeja можно, для серьезной работы не пойдет.

[Сергей]

artem_music: для вас https://habrahabr.ru/post/302394/

[artem_music]

Сергей: спасибо!

Answer 3

[norlin]

я сейчас делаю прототип игры, используя следующую логику:
1. всё состояние игры хранится на сервере (положения объектов и т.д.)
2. каждый тик сервер отправляет на клиент пакет с данными об объектах, которые попадают в поле видимости данного клиента (в зависимости от его местоположения)
3. клиент в свой клиентский тик отрисовывает последние полученные данные
4. клиент слушает команды ввода и моментально отправляет их на сервер
5. сервер двигает объекты в соответствии с получаемыми командами
6. goto п.2

Ключевой момент - клиент не может сообщать серверу изменения состояний объектов. Клиент может сообщать только пользовательский ввод, а уж как на него реагировать – решает сервер.

Порядок пунктов у меня не совсем такой для серверного тика, по факту вот так:
серверный тик:
1. обновление состояния объектов в зависимости от комманд и прочих данных
2. проверка коллизий
3. обновление клиентов

Comments

[artem_music]

Понял, в голове теперь уложилось, спасибо!