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

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

Страницы: 134 35 36 37 38 Следующая »
#510
11:22, 20 июня 2022

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

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

Это к моему утверждению, что вы все сваливаете в кучу.

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

#511
(Правка: 11:44) 11:31, 20 июня 2022

>GGMaster

т.к. его реализация похожа на ту что описываю я

В каком месте она похожа?

Но хорошо, уже задержки появились хотя бы:

несколько кадров
не троттлить управление, а отправку на сервер

Зачем обсчитывать действия, если если его исполнение занимает в 1000 раз меньше времени, чем время подтверждения этого действия?

то опять же, не каждый кадр, а в любой из кадров

Да все верно.

Actions | Делаем убийцу Diablo 1, нужны энтузиасты
#512
11:54, 20 июня 2022

FourGen
> В каком месте она похожа?
Ну вот опять...
А давайте с вами вместе, просто посмотрим, что написано в моем сообщении?
GGMaster
>У меня нет надежды, что вы сможете понять самостоятельно, потому выделю ключевые моменты:
>- Определять точку назначения каждый кадр
>- Отправлять на сервер не все значения
>Очень важный момент: не троттлить управление, а отправку на сервер!

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

>Но хорошо, уже задержки появились хотя бы:
Не "уже", а были изначально. Не задержки, а интервалы между отправкой актуальных данных.

FourGen
> Зачем обсчитывать действия, если если его исполнение занимает в 1000 раз меньше
> времени, чем время подтверждения этого действия?
Удобство пользователя.
Ах, да, я не учел, что вы опять не правильно поняли, что вам говорили:
FourGen
> Значит отправлять нужно ~15К событий движения в минуту на сервер. С этим понял.
Вот откуда вы это взяли?

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

>GGMaster

Вот откуда вы это взяли?

Так вам этот вопрос уже был задан много раз, вы на него так и не ответили.

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

Мы еще не выпили банку маны, а пришло еще 100 событий выпить банку маны. Что делать с этими данными?

Может вам нужны варианты ответов?
1) Накапливать
2) Игнорировать
3) Выбрать рендомное
4) Взять последнее
5) Свой вариант

Так же вы не ответили на вопрос:
Несколько кадров это сколько?
1) 1
2) 2
3) 5
4) 10
5) 1278
6) Свой вариант

В каком случае будет считаться, что игрок идет к точке несколько кадров?

#514
12:33, 20 июня 2022

FourGen
> Мы еще не выпили банку маны, а пришло еще 100 событий выпить банку маны. Что
> делать с этими данными?
банка манны фактические пьется из инвентаря, как использовать инвентарь я писал

#515
12:57, 20 июня 2022

>Mephistopheles

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

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

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

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

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

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

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

#518
(Правка: 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 секунд выходит.

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

#519
(Правка: 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 состояний в секунду.

#520
(Правка: 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 мб* пока игрок смотрит на застывший экран. Разделаются данные на требующие гарантированную доставки и на потоковые данные в которых важна актуальность

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>GGMaster

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

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

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