Сервер для 2D real-time игры
 

Использую node.js + socket.io. Опыта до это вообще не имел, поэтому хочу послушать критики, так как уверен, что мой подход в разработке архитектуры сервера неверен.
В общем, как все работает:
1).Клиент каждый фрейм отсылает на сервак данные о нажатых клавишах.
2).Клиент слушает о приходе инфы с сервера касательно игровых объектов и делает следующее: старые данные пихает в P0, новые в P1.
3).Юзается линейная интерполяция по известным P1 и P0.
4).Сервак каждые 16 миллисек обрабатывает нажатие клавиш и игровую логику.
5).Сервак каждые 48 миллисек отправляет все игровые данные всем клиентам.

Как сие дело улучшить?

Ответ: Сервер для 2D real-time игры
 

Есть интересные туторы по player.io, может теория из них тебе пригодится http://www.ant-karlov.ru/PlayerIO-si...a-igrokov.html

Ответ: Сервер для 2D real-time игры
 

Кстати, можете объяснить зачем нужны все эти node.js и прочие если есть java ?

Ответ: Сервер для 2D real-time игры
 

Для явы нужна ява машина, а нод будет выполнятся на веб-сервере.

Ответ: Сервер для 2D real-time игры
 

С таким же успехом можно сказать: зачем ява, если есть плюсы?

Ответ: Сервер для 2D real-time игры
 

Потчи "верный"..

Если это нажатие WASD то у тебя два числа (вектор) направления. Слать нужно только когда они меняются. Например по стандарту вектор [ 0, 0 ], при нажатии D будет [ 1, 0 ], и только когда вектор меняется шли его.
Сервер же просто помнит направление перемещения, и если считает что юнит может двигаться - перемещает.
Если например нужно слать куда мы целимся, то тут слать нужно не чаще чем раз в 100/200 мс, это не критическая инфа, клиенты интерполируют.

Все зависит от механики перемещения и управления, опиши больше.

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

Если игра real-time с взаимодействием между игроками и зависимостью от положения, например FPS или шустрый Top Down, то прийдется учиться экстраполировать, иначе никто не будет попадать по врагам если у них лаг высокий.

Зависит от механики игры, но даже FPS так часто не нужно. Логику лучше считать максимум 20 раз в секунду, а если это не супер активный экшон, то вообще можно 10 раз в секунду.

Шли дельта данные позиций и т.п. также часто как и обновляешь их. При этом думай как пакуешь. JSON для начала ок, но потом нужно бинарно будет паковать.
Многие данные такие как присоединение игрока, или кто-то умер и т.п. не шли с данными обновления, а шли как независимые пакеты, простой event.

Опиши больше о игровой механики, т.к. обычно все зависит от нее.


И как твоя java решит вопросы заданные топик-стартером? Java в таких вещах сосет ты не представляешь как..

Ответ: Сервер для 2D real-time игры
 

Игра быстрая, вид сбоку, есть прыжки.
По второму пункту, да, я это и имел ввиду.
А можно подробнее об экстраполяции? Если игрок двигается только при нажатой клавише и прыжке, то экстраполировать получится только прыжки, да?
И ещё вопрос, касательно TCP. Насколько я знаю, браузеры в UDP не умеют, а значит, точно придется использовать TCP, который куда медленнее UDP. Сейчас сервер поднимаю на своем компе, инет совсем не сильный( 4 мбита прием, 0.5 отдача ). Средний пинг -- 40-60, но иногда скачет до 300. Связано ли это с TCP( как мне известно, он будет ждать до тех пор, пока пакет точно не отправится, что точно может поднять пинг ) и можно ли это пофиксить улучшением пропускной способности сервера?

Ответ: Сервер для 2D real-time игры
 

А moka вон чего делал: http://moka.co/beatemup/

Ответ: Сервер для 2D real-time игры
 

Зависит на сколько шустро перемещаются, если как в Tee World, то да, тут экстраполяция очень важна.

Наоборот. Экстраполировать движение проще, чем действие по нажатию, такое как прыжок или выстрел из рэйлгана.

В общем есть "сетевая политика", я 3 раза уже писал в разных местах на форуме. То что тебе нужно это чтоб сервер делал симуляцию игры, при этом эта симуляция будет сичтаться "главной", далее рассылая данные клиентам, они должны предсказывать данные в будущее о других клиентах, в будущение на продолжительность времени их пинга. Если пинг 200+ то никакая игра уже не будет нормально играться.
Предсказывать (экстраполировать) нужно так чтобы все клиенты старались иметь "идентичную" симуляцию с сервером в реальном времени. В вебе симулировать задержку просто - поставь таймеры при отправке пакета и при получении (до обработки пакетов), тестируй как со стабильной долгой задержкой (120 мс например), так и с "шумной" (100 +/- 80).
Экстраполяция - это предсказывание. Методов много, у тебя будут скорее всего spline'ы, я для простоты делал так: если прошлые данные, текущие, и я предсказываю точку где будет игрок исходя из этих данных, всякие бизье для твоего варианта хорошо подойдут.

Забей про это, просто забей. Т.к. на самом деле когда народ "доводит" их UDP до стабильного состояния (RUDP), то по производительности получается один хрен.
Если WebRTC - но это другая фигня.

Если ты делаешь игру на реакцию, и хочешь чтобы игрок с пингом 150+ не имел лагов, тут UDP не поможет. Ты ничего не можешь сделать с его интернетом, в Web'е это или Native'ное приложение. Почти все игры на мобилках (нативные) что имеют realtime мультиплеер, требуют играть по WiFi, и не разрешают 3G/4G, по очевидным причинам.

Следственно твоя игра должна ставить перед фактом - "говно интернет - не поиграешь".

На вопросы протокола на ранних стадиях вообще не задумывайся.

http://tanks.moka.co/ - работает ок, интерполяция, 20 UPS (Update Per Second).
http://moka.co/beatemup/ - тоже ок, чуток похуже т.к. нету сглаживаний перемещения и т.п. (намеренно) 10 UPS при этом весьма играбельно на 3G. Тут геймплей важен для такого. (открой 4 закладки игры).
http://boxes.moka.co/ - тут вообще нету цикла и физика считается на клиентах, сервер - обменная точка. Частота отсылки данных с клиента 10 UPS.

Ответ: Сервер для 2D real-time игры
 

Ява простая. Миллион библиотек.

В яве нету сокетов или что? :)
миллион фришек l2 написаны на яве. И как то работают с большим онлайном.

Что есть веб-сервер?

Ответ: Сервер для 2D real-time игры
 

node.js проще, в разы, и модулей на него ни сколько не меньше.

При чем тут это? У топик-стартера вопросы не по сети, а по логике.

И миллион фришек написаны на node.js.

radiobutton, иди оффтопь в другое место, тут человека интересует конкретные вопросы, а не твоя java. Будешь дальше офтопить, вынесу в другую тему.

Ответ: Сервер для 2D real-time игры
 

Я верно понимаю, что система на стороне клиента должна быть тогда такой:
1). Интерполируем каждый кадр от старых данных к новым.
2). Если в текущем кадре мы дошли до новых данных, а следующие ещё не пришли - экстраполируем, зная нажатые клавиши игроков.
Так, да?

Ответ: Сервер для 2D real-time игры
 

Если интерполяции будет тебе достаточно, то да, но тут тоже нужно иметь ограничение, например 300мс - это уже перебор. Обычно игры делают 1 секунду таймаут - если не было сообщений, заморозить все.

Я лично просто интерполировал и все, никаких заморочек с продолжением.


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

Ответ: Сервер для 2D real-time игры
 

Нет, ты

Ответ: Сервер для 2D real-time игры
 

Хм. Идеологически UDP лучше подходит для сетевой игры. Если пакет потерялся, фиг с ним. Иначе пока будем проверять, что он дошёл, и пересылать заново, информация устареет.