Войти
ПроектыФорумСобираю команду

Делаем убийцу Diablo 1, нужен геймдизайнер (35 стр)

Страницы: 134 35 36 3763 Следующая »
#510
12:57, 20 июня 2022

>Mephistopheles

банка манны фактические пьется из инвентаря, как использовать инвентарь я писал

А сколько раз можно выпить банку маны у вас в секунду? От чего это значение зависит? От количества пришедших событий мыши выпить банку маны?

#511
13:00, 20 июня 2022

GGMaster
> - Определять точку назначения каждый кадр
> - Отправлять на сервер не все значения
> Очень важный момент: не троттлить управление, а отправку на сервер!

Вот тут и кроется принципиальная разница: с какой целью локально применять новую точку назначения каждый кадр, если на клиенте показывается не состояние мира в настоящий момент времени, а с задержкой 50 мс? Задержка в 50 мс вводится специально, чтобы все игроки с хорошим пингом видели идеально совпадающую картинку без рывков и телепортов. И вот применить локально новую точку назначения получается можно только через 50 мс после того как она появилась. Но если эту точку применить сразу, а не через 50 мс, то у всех игроков будут проявляться артефакты, рывки и телепорты. Получается, что применять локально надо ровно то что было отправлено на сервер. А у сервера ограничен канал, уменьшение частоты отправки запросов от клиента на сервер приведёт к возможности увеличить количество игроков на сервере. Если слать 15000 запросов в секунду, на сервере не получится обслуживать даже 40 игроков. В смысле это будет физически невозможно.

#512
13:14, 20 июня 2022

>Вий
Я даже не уверен, что среднестатистическое оборудование до дедика будет способно обрабатывать 15К запросов в секунду, хотя может и ошибаюсь, но судя по тестам роботов, крайне сомнительно и не думаю, что сильно много больше.

#513
(Правка: 13:26) 13:19, 20 июня 2022

Но самое интересное происходит на сервере: именно оттуда рассылается новая команда описывающая движение персонажа, и рассылать ее надо всем кто этого персонажа видит. При клеточке в 100х50 пикселов и экране full hd видит игрок 414 клеточек, в пределе в каждой стоит персонаж другого игрока. Значит смену направления движения надо разослать 414 раз. Даже просто на udp заголовки при 15000 управляющих воздействиях в секунду уйдёт 15000*28*414 или 173 мегабайта в секунду. Это 1.4 гигабита/с бесполезной информации про 1 игрока. Наш сервер такое не выдержит!
Просто чтобы про одного игрока рассылать такое надо в 14 раз реже слать. Но у нас не 1 игрок, мы хотим хотя бы 10000, так что нам надо в 140000 раз реже слать, это раз в 10 секунд выходит.

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

#514
(Правка: 14:06) 13:45, 20 июня 2022

Посчитанные выше размеры - это просто сумма размеров udp заголовков, по 1 заголовку на запрос. Заголовок крошечны, 28 байт.

1. Конечно надо в одном пакете присылать не только заголовок но и сами данные. Сейчас у меня выходит так: 20 бит координата игрока глобальная, 11 бит координата точки назначения относительная, 20 бит индекс персонажа, 12 бит поколение персонажа, 32 бита метка времени, 8 бит команда. Итого 20*2+11*2+20+12+32*2+8 или 166 бит, то есть 21 байт. Я бы закладывался на MTU 576, туда влезет состояние 26 игроков. Экономия? На игрока приходится 23 байта вместо 28 посчитанных ранее, рассылать можно не с частотой 0.107 раза в секунду а аж 0.136.

2. При таких частотах уже стоит посмотреть на tcp, там заголовок больше, но ждать ещё 7 секунд при потере пакета клиенту будет вконец скучно.

3. Состояние игроков можно при транспортировке зажать получше: перейти к относительным меткам времени, скажем по 11 бит, относительным координатам персонажей, не 20 а 12 бит, на пакет персонажей выйдет экономия порядка 9*2+22*2=62 бита, это 104 бита на игрока, 13 байт. Выйдет около 0.219 состояний в секунду.

#515
(Правка: 14:02) 13:57, 20 июня 2022

Вий
> Вот тут и кроется принципиальная разница
Разница с чем? С твоей реализацией? Так я тебе об этом с самого начала говорю. - что за срыв покровов?

FourGen
>Так вам этот вопрос уже был задан много раз, вы на него так и не ответили.
Тут есть проблема - у меня совершенно нет желания отвечать на вопросы которые я уже отвечал.
Вот например мое вчерашнее сообщение
> частоту отправки *как уже писал* сейчас определить нельзя - нужно тестировать и искать баланс.

FourGen
> Мы еще не выпили банку маны, а пришло еще 100 событий выпить банку маны. Что делать с этими данными?
Если отталкиваться прям от D1, то там применение банок мгновенное и без к.д., - нет состояния "Мы еще не выпили банку маны". т.е. если мы за 1 кадр выпьем 2+ банки, то выпить и сообщить нужно о каждой.

FourGen
> Несколько кадров это сколько?
Пока есть рассчитанный путь, но не завершен новый расчет.

FourGen
> В каком случае будет считаться, что игрок идет к точке несколько кадров?
Если есть путь, а расчет для нового пути не был завершен по каким либо причинам.

Вий
> udp заголовки при 15000 управляющих воздействиях в секунду уйдёт
Ох, ну ты то куда, мы ж уже это обсуждали...
Что-ж вас носом то тыкать нужно:
Вот мое сообщение двух дневной давности #441:
> 1. У клиента нельзя отнимать управление регистрируя не все события.
> 2. Плохо делать управление ватным
> 3. Нужно делить данные на те что нужно гарантированно отправить и на те, что нужно отправлять потоком актуальные значения.
> Где тут про то что нужно отправить все 15000 позиций на сервер?

Вий
> Но у нас не 1 игрок, мы хотим хотя бы 10000, так что нам надо в 140000 раз реже слать, это раз в 10 секунд выходит.
> Теперь у вас есть шанс понять суть проблемы и можно обсудить способы ее решения.
О, так я достучался выходит?
GGMaster
> EVE online буквально замедляет время, ты так же планируешь делать?

Ой, а помнишь что ты мне на это ответил?
Вий
> Это вызвано тем, что сервер написан на питоне, который работает очень медленно и сервер не справляется с обработкой взаимодействий большого количества игроков в реальном времени
Постой, но ты же вроде бы не на питоне пишешь? т.е. ты меня ложно успокоил в этом сообщении #465?

Вий
> сумма размеров udp заголовков
Ой, и тут достучался до тебя?
А раньше то было
Вий
> В моей схеме связь полнодуплексная и при этом по tcp
Еще 3 дня назад тебе писал
> Ты просто на фундаментальном уровне не понимаешь, как подходить к проектированию игрового сервера. Ни кто и ни когда не отправляет *махом по 10 мб* пока игрок смотрит на застывший экран. Разделаются данные на требующие гарантированную доставки и на потоковые данные в которых важна актуальность

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

#516
(Правка: 15:53) 14:19, 20 июня 2022

0.219 состояний это 100 мегабитный канал. Ну ок, переходим на 1 гигабитный, это дорого, но наверняка игроки будут собираться в такую дорогую конфигурацию даже не каждый месяц. И вот уже мы обеспечиваем 2.19 управляющих воздействий в секунду. Победа?

Если в игровом мире не гигантская равнина, а разные препятствия, деревья, камни, стены, то нагрузка быстро снижается, я бы предположил что даже в толпе будет 1/2 свободного места, так что можно в целом надеяться на 4 управляющих воздействия в секунду в дикой толпе игроков. Ну точно победа?

А нет, вот тут пишут что надо время замедлять. Зачем?

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

А вот в варианте когда сервер отправляет текущие позиции персонажей клиент будет получать позиции с сервера с отставанием в стабильные 1/4 секунды + лаг. Потому что рассылка всех позиций будет при полной загрузке сети идти по кругу и один круг будет занимать 1/4 секунды.

#517
(Правка: 18:05) 16:21, 20 июня 2022

Вий
> стоит посмотреть на tcp
а чего на него смотреть, для fast paced не годится

> перейти к относительным меткам времени, скажем по 11 бит, относительным координатам персонажей
тут уже один шаг до дельта-компрессии

еще так и не понял, будет предикшн или нет?
без предикшна видел одну браузерку, но там тик 8мс пришлось ставить на серваке, иначе пресловутое "ватное" управление

#518
19:21, 20 июня 2022

#!
Предикшн чего?

#519
19:26, 20 июня 2022

>GGMaster

частоту отправки *как уже писал* сейчас определить нельзя - нужно тестировать и искать баланс

Понял надо искать баланс. Я все же сторонник не его поиска, а четких и понятных данных и по мере возможностей эти данные должны быть сведены к минимуму, если в них нет необходимости. Но я понял, главное это не забирать управление у пльзователя, что бы можно было выполнять неограниченное количество действий за любой промежуток времени. С этим так же не соглашусь. Все же буду делать кривое управление, где продолжительность каждого действия четко определена и контролируется.

#520
(Правка: 19:34) 19:29, 20 июня 2022

Вий
> Предикшн чего?
движения, тут уже проскакивало что хорошо бы клиент двигался не дожидаясь ответа от сервера

если нет коллизий, то несложно делается

в #492 от 563
> когда кликнули на клиенте - персонаж (рассчитал на клиенте и сразу пошел в точку)

#521
20:21, 20 июня 2022

#!
Тут 2 разных процесса:
Для случая когда данные приходят достаточно быстро (50 мс и быстрее) можно вместо показа на каждом клиенте совей кривой версии происходящего везде показывать одну серверную с небольшим отставанием, не ощущаемым как ватное управление.

В этом случае предикшн бы только добавлял артефакты, которых без него бы не было

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

#522
20:23, 20 июня 2022

Вий
> везде показывать одну серверную с небольшим отставанием, не ощущаемым как
> ватное управление.
В факторке это плохо работает. Пвп в факторке совсем неиграбельное.

#523
20:27, 20 июня 2022

samrrr
> В факторке это плохо работает
А там управление мышкой или непосредственное?

#524
20:42, 20 июня 2022

Вий
> А там управление мышкой или непосредственное?
??? обычное. как в любом шутере.

Страницы: 134 35 36 3763 Следующая »
ПроектыФорумСобираю команду