Авторизация / Регистрация

[Nachtigall_renamed_643363_10082024]

Сообщение от Frosterman:

ейчас есть множество IT проектов которые оперируют намного большими объемами данных и контактируют с намного большим кол-вом пользователей. Причем нагрузка по сравнению со среднестатистической ммо отличается на множество порядков.

О каких проектах идёт реч?

[ksyon_renamed_585877_30012023]

Сообщение от Frosterman:

Я думаю тут всё упирается в целесообразность вложенных усилий и доступный бюджет. Сейчас есть множество IT проектов которые оперируют намного большими объемами данных и контактируют с намного большим кол-вом пользователей. Причем нагрузка по сравнению со среднестатистической ммо отличается на множество порядков. Просто у разработчиков игр в первую очередь совсем другие зоны внимания, куда и уходит львиная доля усилий и денег. Остальное делается по минимуму просто потому что это нужно сделать. А вот развитие евы в свое время уперлось именно в производительность и ССР вкладывало в её решение много денег. Одно только закупаемое оборудование чего стоило. Так что времени и денег у них было достаточно, но итоговый результат не то чтобы впечатлил. В конце концов мы пришли к замедлению времени и прочим костылям, т.е. это можно было сделать ещё тогда и в тех условиях. Поэтому в словах про рукожопов есть доля истины

Несколько тысяч игроков в одной битве не очень впечатлил? Ну я тогда даже хз) можно примеры более впечатляющих прожектов?

[Frosterman_renamed_702762_29082022]

Сообщение от Nachtigall:

О каких проектах идёт реч?

Наверное я буду не очень оригинален, но всё же напомню что существует такая штука как гугл Полно всяких статей в стиле "TOП-х Python-проектов" да и просто вики никто не отменял. Кстати в англоязычной версии статьи про питон есть отличный подраздел uses Я понимаю что сейчас начнётся нытье и стандартный прием тролля, поэтому всё же пробегусь по паре примеров своими словами. Ну допустим джанго, внезапно написанный на питоне и внезапно имеющий высокую популярность. Его использует тот же инстаграм, редит, ютуб и пр. крупные сайты. Внезапно даже в гугл движке поиска среди прочего до сих пор использует питон (не смотря на то что те активно продвигают свой Go). Из более интересных вещей (для меня) - тензорфлоу, опенцв и пр. проекты завязанные на дата лернинг. Вот как раз недавно возился с опенцв в связке с pil для распознавания образов на видео в 60фпс - я был удивлен, но получилось на коленке по быстрому слепить рабочий вариант который забирал видео с камеры, успевал обработать кадр, наложить поверх свою графику и вывести на отображение без каких либо лагов. Да ещё и сверху интерактивные действия пользователя. Очень мощная либа и отличный инструмент.

Добавлено через 1 минуту

Сообщение от ksyon:

Несколько тысяч игроков в одной битве не очень впечатлил? Ну я тогда даже хз) можно примеры более впечатляющих прожектов?

сразу видно когда читают текст в "женском стиле". Т.е. не читать вообще, а просто отреагировать на несколько слов выборочных слов которые зацепили в мозгу ассоциативную цепочку. Попробуй внимательно перечитать текст в том сообщении.

[ksyon_renamed_585877_30012023]

Сообщение от Frosterman:

сразу видно когда читают текст в "женском стиле". Т.е. не читать вообще, а просто отреагировать на несколько слов выборочных слов которые зацепили в мозгу ассоциативную цепочку. Попробуй внимательно перечитать текст в том сообщении.

Ты как моя девушка, я ей "сколько будет дважды два", а она мне в отвкт эмоциональную тираду на 5 минут))
Еще раз: рабочие примеры игровых проектов есть у тебя или нет?
Лекция по сегодняшним технологиям не нужна по вполне понятным причинам

[Nachtigall_renamed_643363_10082024]

Сообщение от Frosterman:

Полно всяких статей в стиле "TOП-х Python-проектов" да и просто вики никто не отменял. Кстати в англоязычной версии статьи про питон есть отличный подраздел uses

Python не является bottleneck'ом по этому нету смысла особо сравнивать проекты написанные только на нём.

Сообщение от Frosterman:

Ну допустим джанго, внезапно написанный на питоне и внезапно имеющий высокую популярность. Его использует тот же инстаграм, редит, ютуб и пр. крупные сайты. Внезапно даже в гугл движке поиска среди прочего до сих пор использует питон (не смотря на то что те активно продвигают свой Go). Из более интересных вещей (для меня) - тензорфлоу, опенцв и пр. проекты завязанные на дата лернинг. Вот как раз недавно возился с опенцв в связке с pil для распознавания образов на видео в 60фпс - я был удивлен, но получилось на коленке по быстрому слепить рабочий вариант который забирал видео с камеры, успевал обработать кадр, наложить поверх свою графику и вывести на отображение без каких либо лагов. Да ещё и сверху интерактивные действия пользователя. Очень мощная либа и отличный инструмент.

Ты сравниваешь яблоки с грушами. Мало того что тобой перечисленные проекты между собой сильно отличаются так еще и к ммо они не имеют никакого отношения.

Понятное дело что любой веб фреймворк должен позволять как можно большему кол-ву пользователей лазить по сайту и совершать разные действия, но технология лежащая в основе сильно отличается от ММОшной, так как веб сервер stateless потому что кроме сессии старается больше ничего не держать в памяти о пользователе. Любой запрос, например о содержимом корзины с покупками, получает данные из бд/кэша и не взаимодействует на прямую с другими пользователями сайта. Этот подход делает поддержку одновременно на много "дешевле" чем в ммо так как не нужно синхронизировать действия пользователей между собой.

Распознавание видео и рендеринг новых изображений абсолютно другая тема, так как хоть и создаёт большую нагрузку на процессор и сильно зависит от эффективности используемых алгоритмов, но при этом позволяет сильно увеличить производительность с помощью параллелизирования. Серьёзное железо с большим кол-вом памяти и ядер позволит параллельно обрабатывать разные области одного фрейма, так как их пиксели не зависят друг от друга ну и конечно разные фреймы тоже легко параллелизируются.

В ММО же, конкретно в еве, технические особенности абсолютно другие: пользователи могут совершать действия основываясь на целую кучу уникальных параметров своих персонажей, по этому не получится отделаться одной только сессией и быть , как в онлайн шопе. В еве эту часть отдельно дорабатывали и оптимизировали в последние годы. За подробностями читай дев блог(и) о "Brain in the Box".
Помимо этого игроки в худшем для сервера случае находятся все в одном гриде (инстансе) в скоупе которого синхронизируются многие свойства тысяч игроков (объектов), которые в свою очередь всеми силами взаимодействуют 1 на 1 (стрельба) но и 1 со всеми (аое дамаг/баффы). Как следствие такого рода задачи крайне трудно и скорее всего практически не возможно параллелизировать, так как данные зависят друг от друга и результаты расчета каждого треда пришлось бы синхронизировать друг с другом с огромными потерями производительности.
В конечном итоге серверная логика евы работает в одном потоке, полностью полагаясь на тактовую частоту процессора и полностью игнорируя все последние достижения в в процессорной архитектуре (многоядерность) и увеличенный размер кеша. Именно по этому им пришлось изобретать костыли с "замедлением времени" - ни что иное как command queue с некоторыми "магическими" особенностями - замедляется всё кроме отката ДД титанов, сидж таймера цитадели и прочего мне не известного.

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

[Frosterman_renamed_702762_29082022]

Сообщение от Nachtigall:

Ты сравниваешь яблоки с грушами. Мало того что тобой перечисленные проекты между собой сильно отличаются так еще и к ммо они не имеют никакого отношения.

Это был пример производительности языка и его актуальности использования в высоконагруженных проектах. А уж какие алгоритмы лепят разработчики в своих играх - это уже личная трагедия каждого.

Сообщение от Nachtigall:

Понятное дело что любой веб фреймворк должен позволять как можно большему кол-ву пользователей лазить по сайту и совершать разные действия, но технология лежащая в основе сильно отличается от ММОшной, так как веб сервер stateless потому что кроме сессии старается больше ничего не держать в памяти о пользователе. Любой запрос, например о содержимом корзины с покупками, получает данные из бд/кэша и не взаимодействует на прямую с другими пользователями сайта. Этот подход делает поддержку одновременно на много "дешевле" чем в ммо так как не нужно синхронизировать действия пользователей между собой.

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

Это конечно не полностью повторяет фреймворк веб сервера, но в общих чертах концепция использования одинакова. Просто данные в БД (наполнение сайта/ игровое окружение) не статичны, а постоянно обновляются. И вот тут как раз то узкое горлышко с которым ССР очень долго и очень дорого боролся - нагрузка на БД. Потому что она единая на всех и замедление select/update в неё под нагрузкой разом влияет на всех. По крайней мере так у них было раньше пока они не занялись кластеризацией. Да и серьёзный прирост в производительности они получили именно тогда, когда сначала почистили бд от мусора, а затем серьёзно обновили на неё железо. Все остальные оптимизации прибавляли крохи.

[Nachtigall_renamed_643363_10082024]

Сообщение от Frosterman:

Правильнее будет сказать игроки оказывают воздействие, а не синхронизированы.

Сообщение от Frosterman:

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

Это синхронизация клиентов. Она делает нагрузку на сеть, но не является проблемой для параллелизирования. Проблема в shared state и его синхронизации между тредами его изменяющими.

Сообщение от Frosterman:

И каждый клиент обновляет информацию только о своем игроке и его состоянии. В отдельном потоке, в отдельной сессии, с отдельным пингом и пр. [...] И обрабатывать логику для каждого клиента можно и нужно как раз в отдельном потоке.

К сожалению всё не так просто. Паралеллизация работает отлично только до тех пор пока данные обрабатываемые в каждом треде друг от друга не зависимы. Примеры подходящих данных: видео рендеринг, архивирование(в обе стороны), копирование данных итд.
Как только у тебя появляется shared state который нужно изменить в параллельных тредах (например хп цели в которую стреляют несколько игроков) то тебе нужно позаботиться о Lock'е, который заставит всех остальных подождать пока работает первый тред, иначе получится, так называемый, race condition (proof). Но при этом такой лок мало того что убивает профит от паралелизирования (треды ждут вместо работы) (proof) так еще и добавляется удар по производительности из за синхронизации памяти между тредами(proof).

Изучив всё вышенаписанное, можно на примере некоторых взаимодействий из флотового боя евы понять почему синхронизация серверных тредов будет мешать паралеллизации:
Группа игроков А стреляет в игрока Б, которого лечит группа игроков Ц. С точки зрения сервера ХП игрока Б будет shared state, который пытаются одновременно модифицировать игроки группы А и Ц. Любая параллелизация на этом этапе по сути упрется в lock, чтобы избежать race condition.
Дальше можно добавить еще одну переменную - группу стелс бомберов Д, сбросивших бомбы на игроков А, Б и Ц. Теперь серверу надо произвести геометрические расчеты радиуса поражения бомб и вычислить какие цели попадут под него и сколько дамага будет нанесенно. Результаты этих расчетов сильно повлияли бы все параллельные расчеты с участием групп А, Б и Ц и соответственно все эти треды нуждались бы в синхронизации своих shared states.

В реальности всё было бы ещё на много сложнее так как добавились бы АОЕ баффы, передвижения, появление новых объектов в гриде итд.
По этому все расчеты у ССП идут в одном треде в порядке поступления комманд. Если очередь комманд растёт быстрее чем серверный процессор успевает их обрабатывать то включается замедление времени, которое увеличивает таймера согласно определённому фактору.

Сообщение от Frosterman:

Отсечка на коллизии происходит на сервере в момент обновления данных в бд относительно текущего состояния взятого из того же БД.

То что для расчета коллизий и прочих расчетов сервер eve обращается к БД это очень маловероятно, так как обращение к БД как и любая другая IO операция в разы медленнее чем запрос к памяти и приводит к долгому простою процессора в ожидании данных. Скорее всего все нужные для расчетов данные у них уже кешированны в памяти и соответственно изменения состояния тоже вряд-ли сразу сохраняются в бд. Скорее всего сохранение происходит при смене сессии (когда появляется таймер сессии в углу экрана) и при логауте/таймауте сессии.