Комментарии 20
Было интересно прочесть, особенно трюк с «машиной времени» на сервере, никогда не понимал как он работает.
Спасибо за перевод, отличная статья!
Спасибо за перевод, отличная статья!
пинг 150 — както жестоко.
ИМХО как не делай будет неиграбильно
ИМХО как не делай будет неиграбильно
Вы видимо забыли как играется на 600+ по EDGE.
У меня уже 3 месяца вообще общественная вафля со скачками пинга от 5 до 1500 и с периодическим падением инета до 10 секунд. Жизнь — боль. Но иногда играть в War Thunder даже не приносит боль, иногда.
У меня уже 3 месяца вообще общественная вафля со скачками пинга от 5 до 1500 и с периодическим падением инета до 10 секунд. Жизнь — боль. Но иногда играть в War Thunder даже не приносит боль, иногда.
Пинг 150 — это вполне норм еще. В зависимости от игры. В MechWarrior Online, помнится, это вообще норма была. Может и сейчас тоже. Там же в те времена был один товарищ, который ходил на тихоокеанские сервера и стримил бои с пингом в 1000. Весьма успешные бои, надо заметить. Комментировал он это обычно так: «It's not a ping. It's skill level»©
От игры зависит. Я например в дум2 через Zandronum спокойно до 180мс могу (да и всякие южноамериканцы с 260 тоже норм себя чувствуют).
Подход используется схожий с тем что здесь (положение игроков хранится за последние 70 тиков (1тик = 0.028с) и отматывается в соответствии с пингом того кто стрелял).
По теме хочется сказать что вопрос с «какой клиент что знает» лично я решал bitfield'ом на предмет «объект уже известен игроку с id #» и в соответствии с этим битфиелдом либо посылал только то что изменилось либо полную инфу об объекте (и ставил «известно игроку» в 1 по получении). Плюс полная инфа об объекте посылается раз в N секунд чисто на всякий случай или по запросу клиента.
Для игр с ограниченным количеством одновременно изменяющихся объектов (меньше 100-300) такой подход вполне сойдёт. Для 700+ уже придётся извращаться, ибо 60 раз в секунду обновлять инфу о 700 объектах уже 60*700 минимум. А ведь ещё данные есть :)
Подход используется схожий с тем что здесь (положение игроков хранится за последние 70 тиков (1тик = 0.028с) и отматывается в соответствии с пингом того кто стрелял).
По теме хочется сказать что вопрос с «какой клиент что знает» лично я решал bitfield'ом на предмет «объект уже известен игроку с id #» и в соответствии с этим битфиелдом либо посылал только то что изменилось либо полную инфу об объекте (и ставил «известно игроку» в 1 по получении). Плюс полная инфа об объекте посылается раз в N секунд чисто на всякий случай или по запросу клиента.
Для игр с ограниченным количеством одновременно изменяющихся объектов (меньше 100-300) такой подход вполне сойдёт. Для 700+ уже придётся извращаться, ибо 60 раз в секунду обновлять инфу о 700 объектах уже 60*700 минимум. А ведь ещё данные есть :)
двери только всякие так не обманиш.
сервер должен сказать её свежее состояние и можно ли открыть, например.
иначе выглядит весьма забавно.
сервер должен сказать её свежее состояние и можно ли открыть, например.
иначе выглядит весьма забавно.
Ну во-первых, в начале подключения к серверу, клиенту скидывается дельта от изначального состояния уровня, называемая snapshot.
А потом — открытие/закрытие двери это глобальное действие посылающееся всем клиентам. Учитывая что дверей на уровне не очень много, и открываются/закрываются они не все сразу одновременно 60 раз в секунду, это решается отправкой пакета по reliable каналу в момент изменения состояния. (а конкретно в названном порте Дума таким же образом посылаются все эффекты анимации секторов (статических частей геометрии уровня), и даже так траффик достаточно низкий).
«Можно ли открыть» как правило предсказывается клиентом, т.к. у двери есть конкретный набор характеристик, прописанный в уровне. Есть конечно заскриптованные, но задержка 50-250мс не очень заметна пользователю, а если движок свой, то даже заскриптованные двери можно предсказывать в клиенте.
А потом — открытие/закрытие двери это глобальное действие посылающееся всем клиентам. Учитывая что дверей на уровне не очень много, и открываются/закрываются они не все сразу одновременно 60 раз в секунду, это решается отправкой пакета по reliable каналу в момент изменения состояния. (а конкретно в названном порте Дума таким же образом посылаются все эффекты анимации секторов (статических частей геометрии уровня), и даже так траффик достаточно низкий).
«Можно ли открыть» как правило предсказывается клиентом, т.к. у двери есть конкретный набор характеристик, прописанный в уровне. Есть конечно заскриптованные, но задержка 50-250мс не очень заметна пользователю, а если движок свой, то даже заскриптованные двери можно предсказывать в клиенте.
дверь открывается — когда ты её открыл)по кнопке выстрелил, подбежал и прочее)
и очень странная ситуация бывает, когда при такой оптимизации, пробегаешь через фактически закрытую дверь(например её нельзя тебе открыть).
ну или она не открывается.
и очень странная ситуация бывает, когда при такой оптимизации, пробегаешь через фактически закрытую дверь(например её нельзя тебе открыть).
ну или она не открывается.
кстати, а толку то от дельты в начале, если положение лифтов, дверей и прочего постоянно меняется?
пинг 150 — както жестоко
В Rainbow Six: Siege до определенного момента от такого пинга только выиграть можно было. Например так.
Вот и в этом описании сетевого кода пропущен один очень важный аспект — безопасность. Доверие сервера клиенту
Или все-таки об этом подумали, но в статье описать забыли?
Чтобы минимизировать рывки, сервер всегда полагается на клиента при определении направления отскокаприводит к тому, что клиент этим доверием может злоупотреблять. А если может, то будет. Дальше будут безуспешные попытки блокирования инструментов влияния на клиента, боль, потеря интереса и смерть.
Или все-таки об этом подумали, но в статье описать забыли?
Мне одному кажется, что проблема то вовсе не в сетевом коде (хорошо, в основном, не в сетевом коде):
Каждый, кто работает в этой сфере, скажет вам: никогда не добавляй сетевой многопользовательский режим в уже готовую игру, никогда, пьяный ты клоун.
...
Моя игра DECEIVER скоро появится в Kickstarter.
Если с самого начала предполагалось делать игру сетевой, почему он раньше обо всём этом не подумал, ведь она ещё даже не вышла? Почему «так получилось, что бОльшая часть сетевого кода в буквальном смысле приклеена к этой игре скотчем»? Налицо полное отсутствие какого-либо проектирования, а с него и надо было начинать.
НЛО прилетело и опубликовало эту надпись здесь
Про 2048.
Мне это напомнило MVC паттерн. Так и есть. Вью — игровая сетка. Ее источник — данные в массиве. Контроллер — процесс взаимодействия пользователя с экраном.
Часть про дельта-компрессию состояния мира напомнила реализацию хранения состояния уровня в Braid.
Я понимаю плюсы хранения состояния в массивах — их можно очень быстро сравнить векторными инструкциями. Однако вот эта фраза заставила меня поднапрячься:
Для разработчика всякого бизнес-кода звучит, как какой-то жуткий хардкод. Я не вижу технической сложности сереализовать и сравнить дерево объектов(понятно, что это будет затратнее) и отослать клиенту дифф от предыдущего дерева.
Да и вообще, почему нужно слать «слепки» состояния всего мира 60 раз в секунду? Почему не слать пачки изменений конкретных объектов с привязкой к меткам времени?
Если здесь есть разработчики игр, может они ткнут меня носом в суровую реальность и расскажут почему автор всё сделал правильно?
Игра поддерживает до 2048 объектов.
Для разработчика всякого бизнес-кода звучит, как какой-то жуткий хардкод. Я не вижу технической сложности сереализовать и сравнить дерево объектов(понятно, что это будет затратнее) и отослать клиенту дифф от предыдущего дерева.
Да и вообще, почему нужно слать «слепки» состояния всего мира 60 раз в секунду? Почему не слать пачки изменений конкретных объектов с привязкой к меткам времени?
Если здесь есть разработчики игр, может они ткнут меня носом в суровую реальность и расскажут почему автор всё сделал правильно?
Да и вообще, почему нужно слать «слепки» состояния всего мира 60 раз в секунду? Почему не слать пачки изменений конкретных объектов с привязкой к меткам времени?
На сколько я понял, автор так и сделал. Для этого он и хранит предыдущие состояния всего мира, потом сравнивает с состоянием мира клиента и отправляет ему разницу.
По поводу «Игра поддерживает до 2048 объектов.» автор сам объясняет почему он так сделал.
Если 2048 объектов это теоретический максимум для его игры, то почему бы и нет. Такой способ реализовать быстрее. Однако я бы все-таки не советовал так хардкодить, если есть возможность и время сделать лучше.
Про разницу игровых состояний, сжатие данных и многое другое очень хорошо написал Гленн Фидлер. И автор любезно предоставил ссылку на его статьи: gafferongames.com
хорошая игрушка
Что за игра на скриншотах и видосиках ?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сетевой код для бедных