- Вий
- Постоялец
Mephistopheles
> Нагрузка же растет не линейно
Как раз линейно.
Почему так: вот стоят в поле 2 армии по 50к игроков.
Каждый игрок видит скажем на Х метров вокруг (камера от 3 лица, сверху-сбоку), вот допустим игроки прям плотно стоят и на экран влезает 16х16 условных клеток куда могут встать игроки, итого на экране не влезает больше 256 игроков. Чтобы экраном шевелить, нужно подгрузить заранее чуть больше, скажем на 2 клетки в каждую сторону, это 400 игроков максимум. Вот данные про 400 игроков можно пересылать каждому игроку. Больше - не нужно, он их все равно не увидит, они далеко. И даже в таком сценарии уже глупость происходит потому что конечно таким плотным строем игроки в реальной игре ходить не будут.
Продолжаем считать трафик:
400 персонажей, у каждого 1 байт -смещение по Х от центра экрана игрока, 1 байт - по У, еще 2 - смещение цели действия, еще 1 байт - количество тиков в прошлое когда он начал действие, и 1 байт - код действия и 2 байта ид игрока. Итого 8 байт на игрока. 400*8=3200 байт - полное описание состояния, если игроки делают 60 APM то одно полное состояние в секунду и нужно слать. Выходит на игрока нужно 3200*8=25,600 бит в секунду. В 1 гигабит влезет 39062 таких игрока. Да, конечно, там заметная доля уйдет на заголовки, а гигабит недостижим и будет хорошо если 0.8 гигабита, но и игроки будут не так плотно стоять, их будет в 3-4 раза меньше на экране друг у друга, не будут они все делать 60 APM, в общем, со скрипом, но может получиться потянуть мир на 100к одновременно играющих игроков на 1 гигабитном канале.
Вий
> и 1 байт - код действия
а не маловато ли? в ммо действий тысячи, а у действий еще и параметры есть.
Вий
> и 2 байта ид игрока.
и этого тоже мало будет ты же 100000 онлайн хочешь. Не говоря что еще ид всяких нпц и активных обьектов, предметов на земле.
ну и заголовок еще пакета + версия
Вий
> смещение по Х от центра экрана игрока, 1 байт - по У
ты не учел угол поворота и высоту еще. И что это за стремная система с относительными координатами?) Звучит как бомба замедленного действия
Mephistopheles
Назови хотя бы 128 разных действий. Точка назначения в зависимости от действия может быть не точкой а параметрами.
Вий
> Вот данные про 400 игроков можно пересылать каждому игроку.
Это что за такая игра и такой ракурс, где можно увидеть только 400 игроков одновременно? А если их 40 000 на площади соберётся, то с крыши на эту толпу посмотреть никак?
гидралиск
А в какой мморпг можно? Покажешь скрины?
Вий
> Назови хотя бы 128 разных действий.
угараешь?)
открыл сорцы ла2 сервера и там в папке пакетов их 718 шт. И это в простецком ла2
Вий
> А в какой мморпг можно? Покажешь скрины?
погугли скрины с осад в ла2
Вий
> А в какой мморпг можно? Покажешь скрины?
Eve Online:
Ещё бы мнение эксперта по вот этому видео хотелось:
Кто-то атакует, кто-то хилит, кто-то накладывает бафы, при этом все периодически получают урон и на всех по 5-10 бафов...
Mephistopheles
> открыл сорцы ла2 сервера и там в папке пакетов их 718 шт.
Ну забери 2 бита из смещения цели в ид действия. Будет у тебя 1024. Когда кончатся зеберешь еще 2 бита.
NicoAZ
Смотрю много игроков в сцене, и интересно сколько данных отправляются каждому игроку?
Mephistopheles
> погугли скрины с осад в ла2
То что я нашел это все те же 200-300 игроков на экране
NicoAZ
> Eve Online:
А у них такой дизайн что все квадратично до конца, поэтому в одной системе не может быть неограниченно много игроков взаимодействующих друг с другом. У них кстати и 100к игроков никогда не было, не то что на одном сервере но и вообще.
Математика у них такая же работает. Корень из 400*100000 это 6324.
Смотрим исторические данные:
maximum of 2,670 players in the B-R5RB system at one time
Очень близко.
равен
> Что касается шифрования трафика - шифрование трафика в игровых проектах не нужно
Выдал кринжа. В наше время даже отдачу статики с веб-сервера шифруют, а тут решил игровой трафик не шифровать)
Он шифруется не только для того, чтобы нельзя было выдать себя за другого игрока.
Его шифруют, чтобы сильно усложнить написание читов и прочего софта, который прослушивает трафик, ну и конечно же исключить возможность явного перехвата трафика в публичной сети и узнать информацию о действиях игрока.
Кому это нужно и зачем - другой вопрос. Но в нормальных играх трафик шифруется.
Вий
> То есть запас по производительности огромный должен быть. Меня больше беспокоят syscall-ы и вот тут вероятно поможет liburing. Ему придется отдать ядро целиком, зато остальные 3 будут свободны от сисколлов.
Сделай уже игру) Какие-то оптимизации рандомные, в реальных проектах узким местом вообще не это является.
Вий
> Почему речь о rpi4 - потому что это хоть и слабое но реальное железо, которое передаётся в полное распоряжение. Для игрового сервера это важно - так программа будет вести себя предсказуемо.
Чел, просто возьми в аренду Dedicated server в какой-нибудь Selectel (Ru), Hetzner (EU), OVH (NA) или еще у десятка других. Цена одной машинки - 30-50 баксов в месяц. И будет у тебя нормальный сервак с 8-16 ядрами и 16-64 гб памяти (тут уж как повезет с тарифами).
Это, как бы копейки и на таком железе можно сотни игроков держать, которые генерят в тысячу раз больше денег.
При сотнях и тысячах CCU проблемы будут не в железе и оптимизации, а совершенно в другой сфере...
Storm54
> Это, как бы копейки и на таком железе можно сотни игроков держать
Ха ха ха, сотни игроков
Storm54
> Это, как бы копейки и на таком железе можно сотни игроков держать, которые генерят в тысячу раз больше денег.
Поддерживаю, онлайн 70 человек, сервера 70$ со всей инфрой, приносят 1000$. Не тысячи конечно, но и продукт у нас сделанный на коленке)
Storm54
> При сотнях и тысячах CCU проблемы будут не в железе и оптимизации, а совершенно в другой сфере...
Контент, комьюнити менеджмент, баланс экономики, девопс и вот это вот всё ботлнек реальный
Вий
> Ха ха ха, сотни игроков
Понимаю, что в твоей голове ужилась мысль, что даже на каком-то Raspberry Pi можно 100к CCU держать и на этом фоне сотни или одна-две тысячи игроков кажутся чем-то примитивным.
Вот только ты не учитываешь, что конечному пользователю куда важнее будет не то, сколько на физическом сервере соединений поддерживается, а то, насколько хорошо у него "идет" игра. Чаще всего проблема возникает на стороне клиента из-за стремненького интернета и тут не будет достаточно эффективно упаковать данные.
Я на первых версиях держал 2000 CCU на одном ядре в легкую, даже не задумывался, сколько еще вытянет по производительности (и это на i5-3550), вот только понадобилось добавить дельта-компрессию и скажите данных, что на порядки нагрузку увеличило за счет значительного уменьшения трафика для пользователей. Пользователям понравилось, но ни о каких мифических 100000 CCU на одном 8-16 ядерном сервере больше не может идти и речи, т.к. Zstd сжатие, плюс подготовка данных для дельта-компрессии все напрочь съедает.
Не думаю, что ты изобретешь что-то принципиально новое в этом плане, чтобы дать комфорт пользователям и "не платить" за агрессивную экономию трафика.
Тема в архиве.