На кой чёрт вам понадобилось делать симуляции на клиенте?
Действительно есть ММО и MOBA игры, которые не используют симуляцию на клиенте (самым ярким примером можно привести Dota 2, где нет предсказания ввода — инпут отправляется на сервер, сервер производит симуляцию, результат (дельта изменений) присылается клиенту — по итогу в случае лага игра «застывает», произвести реверс игровой логики можно только создав карту и став хостом).
Роль симуляции на клиенте выше обозначил автор — это «предикшен локального клиента», то есть предсказание ввода — говоря проще, в играх с быстрым геймплеем (например шутер) клиент не ждет ответа от сервера, чтобы передвинуть сущность игрока или произвести выстрел, он самостоятельно просчитывает логику передвижения (физику) игрока, которая будет просчитана позже и сервером, когда запрос клиента дойдет до него.
При реверсе игр Apex Legend / PUBG можно в том или ином виде увидеть очередь инпутов, размер которой динамически изменяется в зависимости от состояния сети, и timeline произведенных предсказаний — если полученные от сервера данные не сошлись (клиент не просчитал определенные факторы, например оглушение) с данными в timeline, производится rollback — начиная с последнего полученного от сервера фрейма данных идет повторная симуляция вплоть до текущего фрейма клиента.
У нас был прототип — но делали не на Unity — использовали Unreal. Суть в том, что есть 2d мир и помимо твердых тел есть упругие тела, флюиды (только жидкости если точнее) и ткани (cloth) — физика таких тел представлена частицами (использовали LiquidFun). Что-то похожее на Terraria планировали, выживалку. По итогу физика была ядром механики и очень много съедала времени — довольно много чего испробовали — слать снапшоты было вообще не вариант. Пробовали локстепом сделать и передавать только инпут, пробовали как-то вычислительные шейдеры подключить — но по итогу так и не нашли способ.
Но видео рассказывает о Peer to Peer, где каждый клиент обязан симулировать всю физику (до конца так и не понял как они частицы симулируют). У нас простая интерполяция, мы других игроков двигаем не при помощи физики, зачем нам их инпут? У них понятно почему инпут, у них до этой модели вообще как я понял был локстеп, каждый клиент поддерживает симуляцию, у него нет сервера, который поможет. Если другие игроки взаимодействуют с миром — игрок не может это знать, будет рассинхрон — но это будет рассинхрон не из-за ошибки вычислений.
или на худой конец использование той же версии PhysX на сервере, что и на клиенте
Конкретно на этот вариант и надеялся. Я подумывал поэкспериментировать с этим, но пока только мысли — надеялся что у вас что-то подобное, когда спрашивал.
рандомные нативные краши
Да, этого крайне много в том же BulletSharp и на исправление уходит тонна времени.
Не рассматривали физику Unity ни в каком виде, т.к. на сервере у нас нет Unity.
Да, такой вариант разве что для прототипов может подойти, там много лишнего получается — хотя сейчас можно настраивать PlayerLoop (ScriptBehaviourUpdateOrder.UpdatePlayerLoop), экспериментальная штука, но все равно много лишнего.
она всё равно недетерминированная, так зачем мучиться? =)
Тут надо смотреть как быстро накапливается ошибка, насколько частые откаты. В случае детерминизма откаты будут во многом из-за получения станов, замедлений. В случае недетерминизма откаты будут чаще — соответственно больше затраты процессора на ресимуляцию, затраты по сути в самой затратной системе. Жаль Вы про это в статье не написали, буду ждать продолжение.
Спросил в надежде — может используете что-нибудь от Unity, нативно на клиенте и сервере, может что-нибудь уже можно применять для мультиплеера от них. Я пробовал BulletSharp, он недетерменированный, но это все решается (синхронизируется) — при компиляции из плюсов под нужную платформу можно убрать кучу ненужного функционала: ткани, канаты, сложные джоинты и т.д.
Для 2d мы пробовали Volatile — только из-за хранения истории его использовать смысла нет, это дело второстепенное; пробовали нативно Box2d — на iOS были большие проблемы с производительностью; по итогу написали свой, с применением ECS подхода — детерминированно, но простенько — без джоинтов, только коллизии, сенсоры и рейкасты.
Тут дело в том, что двусвязанный список не оперирует индексами, он использует связи. Все удобство и все свойства двусвязанного списка заключаются в использовании узла, который знает о соседних узлах, которые в свою очередь могут находиться в памяти где угодно. В Вашем случае у меня, например, есть объект D — но я не могу просто использовать этот объект D для работы, я обязан отобразить его на индекс, который скажет, где он располагается в data (struct node { size_t index; }) — это все к тому, что предложенная структура не является double linked list. Структура это не просто интерфейс, важно ее устройство.
Проблема дыр — это основная проблема Вашего способа — простое запоминание индексов дыр тут не поможет — для быстродействия это ничто, но в плане памяти — нужно помнить обо всех дырах, что в случае большого capacity очень накладно.
Соответственно структуру лучше выбирать, когда известна задача — статья больше полезна для разминки мозгов, за что автору спасибо.
На данную тему можно почитать статьи от marsermd. Если вкратце — сервер откатывается на тот такт, в который клиент произвел выстрел (для этого нужен физический движок, который умеет хранить историю), и выполняет raycast в прошлом.
Мое знакомство с реверсом началось с того, что я устал прокачивать навык метания ножа в игре Silent Storm (где навыки прокачиваются по мере их использования, как в The Elder Scrolls) и захотел автоматизировать этот процесс — в этом помогли общение на форумах и много самостоятельных исследований. Не могу вспомнить, чтобы книги поначалу как-то помогли — но после практики действительно позволяют углубить знания (как по мне, только после практики).
Помимо приведенных книг могу посоветовать канал Zer0Mem0ry.
Согласен, читы доставляют большие проблемы честным игрокам. В Dota 2, LoL, WoW это не супер сильно ощущается, а вот в шутерах это огромная проблема.
Игроки, которые хотят развиваться в жанрах, где читеры имеют слишком сильное преимущество и не дают нормально играть, обычно уходят в лиги (к примеру esea для CS:GO), где свои, довольно суровые античиты (что все равно не спасает), свой mm, а главное — у людей другое отношение к игре.
В итоге нечестному игроку придется заплатить не только за игру, а еще за платформу лиги + подписка на чит будет стоить уже других денег (а если его поймают, забанят не только аккаунт, а еще и железо — отмыть такой бан также стоит дополнительных затрат).
Оптимальная стратегия минимизирует как затраты на производство, так и разнообразие. У каждого свои интересы и предпочтения по геймплею — почему так популярны Dota 2, LoL и прочие MOBA?
Одна из причин — разнообразие. На примере Dota 2: можно в одном сражении взять однокнопочного Лиорика, в другой Инвокера с 10 способностями, а в третьей пикнуть Пуджа, фаниться и фидить на нем всю игру, словить 4 репорта и пойти играть лп.
Самое главное — полезность фичи, остальное уже вопрос ресурсов.
Вообще видел много постов на соответствующих форумах про баны за использование Cheat Engine — помню даже пост, где автор был возмущен тем, что получил бан за то, что CE был запущен — просто запущен, не был даже выбран процесс для анализа.
Хотя примечательно то, что в последнее время я действительно не встречал постов с жалобами / вопросами о наказании. Не могу сказать, что много ковырял Dota 2 с помощью CE — перед тем, как кинуться изучать игру, я почитал форумы и быстро вышел на Source2Gen. Cheat Engine я активно использовал ранее для изучения CS:GO — и получал баны (правда меня банили через 1,5-2 недели, примерно с таким же периодом получал баны на аккаунты с Dota 2, но не по причине использование CE — Ваш бан спустя 2 часа меня удивил).
То же самое можно сказать про использование отладчика (в моем случае x64dbg) — я применял его очень активно (как с использованием ScyllaHide, так и без, как в рейтинговых сражениях, так и в своем лобби), VAC закрывал на это глаза.
Я не видел информации, чтобы CE как то скрывал свою работу (как это делает ScyllaHide в x64dbg), возможно он стал перехватывать определенные системные вызовы (опять же, предположение). Стоит также сказать, что разработчики постоянно что-то меняют в античите — возможно, если бы я начал писать бота не пол года, а скажем 1-2 года назад, то плагин ScyllaHide был бы обязателен для отладки.
Подведу итог: не могу ответить на Ваш вопрос точно, лишь выскажу предположения:
CE начал перехватывать системные вызовы и заметать следы (что врят ли, не слышал такого).
Вы попали под период, когда разработчики действительно вели себя кровожадно, но в следствии большого кол-ва ложных срабатываний и жалоб были вынуждены ослабить хватку. (вероятнее всего. на это указывает бан в течении 2 часов — хоть это и не бан за внедрение/подмену/перехват кода, все равно довольно оперативно)
можно и не лезть в регистры, а тупо взять адрес любого стекового аргумента процедуры и ориентироваться по физическому стеку от него.
Согласен, как вариант.
Обращайте внимание на разницу между тегами source и code. Source вставляет блочный элемент с подсветкой синтаксиса, в то время как code вставляет строчный элемент (по сути просто моноширинным шрифтом). Соответственно, нет смысла вставлять несколько строк кода в тег code — он будет некрасиво смотреться, сливаясь с основным текстом. А вот source — наоборот.
Оформлял статью по заметке, соответственно лучше source использовать.
Замечу, что Titanfall Engine начал свое развитие с Source, должен был претерпеть изменения в процессе разработки Titanfall 1,2. Dota 2 же использует Source 2. Поэтому был удивлен таким сходством. Для меня это как сравнить Source 2 и Quake 3 (могу ошибаться, но родителем Source является Quake Engine) — целая Schema System против простенькой интроспективы для репликации:
К тому же, когда используют игровые движки, обычно их сетевую часть и модели использую, в сравнении с остальным функционалом, меньше всего и пишут свое решение (мои личные наблюдения).
Привет, спасибо за интересный вопрос. Я знаком лишь с системами для стриминга и записи экрана (например obs-studio), где получение картинки в игре реализовывается в основном перехватом функций графического API, обычно используется замена виртуальной таблицы (VMT Hook) или тот же Opcode Hook. Также внедряется библиотека, после внедрения создается канал (pipe) и идет общение между внедренным кодом и управляющей программой, своего рода локальный клиент-сервер. VAC ловит эту библиотеку, отправляет на анализ, сравнивает со списком разрешенных и не обращает на нее внимание (собственно несколько недель назад в кастомке Dota Auto Chess был введен античит — добавили сатиров, которые скрывают героев — в итоге те, кто стримил игру получили бан). С системами трансляции игр сталкиваться не доводилось, если говорить конкретно про вывод статистики (HUD) могу лишь подумать вслух, как бы я решал такую задачу — я бы делал оверлей с использованием Panorama, а статистику брал из исторических данных (Dota 2 предоставляет live Game State Integration data).
которым для меня являются аппаратные точки останова, так сложилось что ни разу не реализовывал
В таком случае советую Вам дополнительно изучить работу Page Guard и Forced Exception Hook — их тоже многие античиты игнорируют — правда с быстродействием могут быть проблемы, применять надо осторожно.
Да, по объему вышло немало — пришлось убрать применение PageGuard Hook и Forced Exception Hook. Следующую статью писать приятней — там по сути сплошное исследование, нет теории в таком объеме:)
Про применение 3D сканирования в полный рост добавить особо нечего — примерочные и создание виртуального аватара. Если говорить о других видах сканирования, то это сканирование для дальнейшего протезирование зубов — делается модель челюсти ->заготовка->протез, протез на челюсть крепится 4 или 6 болтиками, протезы поменьше — 1 или 2. Сам я занимаюсь сканированием головы — тут в теории виртуальные парикмахерские и морфинг — можно накладывать эмоции, играться с характеристиками (что будет, если увеличить нос, расстояние между глазами и подобное), предсказывать изменения лица с возрастом.
Роль симуляции на клиенте выше обозначил автор — это «предикшен локального клиента», то есть предсказание ввода — говоря проще, в играх с быстрым геймплеем (например шутер) клиент не ждет ответа от сервера, чтобы передвинуть сущность игрока или произвести выстрел, он самостоятельно просчитывает логику передвижения (физику) игрока, которая будет просчитана позже и сервером, когда запрос клиента дойдет до него.
При реверсе игр Apex Legend / PUBG можно в том или ином виде увидеть очередь инпутов, размер которой динамически изменяется в зависимости от состояния сети, и timeline произведенных предсказаний — если полученные от сервера данные не сошлись (клиент не просчитал определенные факторы, например оглушение) с данными в timeline, производится rollback — начиная с последнего полученного от сервера фрейма данных идет повторная симуляция вплоть до текущего фрейма клиента.
У нас был прототип — но делали не на Unity — использовали Unreal. Суть в том, что есть 2d мир и помимо твердых тел есть упругие тела, флюиды (только жидкости если точнее) и ткани (cloth) — физика таких тел представлена частицами (использовали LiquidFun). Что-то похожее на Terraria планировали, выживалку. По итогу физика была ядром механики и очень много съедала времени — довольно много чего испробовали — слать снапшоты было вообще не вариант. Пробовали локстепом сделать и передавать только инпут, пробовали как-то вычислительные шейдеры подключить — но по итогу так и не нашли способ.
Но видео рассказывает о Peer to Peer, где каждый клиент обязан симулировать всю физику (до конца так и не понял как они частицы симулируют). У нас простая интерполяция, мы других игроков двигаем не при помощи физики, зачем нам их инпут? У них понятно почему инпут, у них до этой модели вообще как я понял был локстеп, каждый клиент поддерживает симуляцию, у него нет сервера, который поможет. Если другие игроки взаимодействуют с миром — игрок не может это знать, будет рассинхрон — но это будет рассинхрон не из-за ошибки вычислений.
Конкретно на этот вариант и надеялся. Я подумывал поэкспериментировать с этим, но пока только мысли — надеялся что у вас что-то подобное, когда спрашивал.
Да, этого крайне много в том же BulletSharp и на исправление уходит тонна времени.
Да, такой вариант разве что для прототипов может подойти, там много лишнего получается — хотя сейчас можно настраивать PlayerLoop (ScriptBehaviourUpdateOrder.UpdatePlayerLoop), экспериментальная штука, но все равно много лишнего.
Тут надо смотреть как быстро накапливается ошибка, насколько частые откаты. В случае детерминизма откаты будут во многом из-за получения станов, замедлений. В случае недетерминизма откаты будут чаще — соответственно больше затраты процессора на ресимуляцию, затраты по сути в самой затратной системе. Жаль Вы про это в статье не написали, буду ждать продолжение.
Для 2d мы пробовали Volatile — только из-за хранения истории его использовать смысла нет, это дело второстепенное; пробовали нативно Box2d — на iOS были большие проблемы с производительностью; по итогу написали свой, с применением ECS подхода — детерминированно, но простенько — без джоинтов, только коллизии, сенсоры и рейкасты.
Проблема дыр — это основная проблема Вашего способа — простое запоминание индексов дыр тут не поможет — для быстродействия это ничто, но в плане памяти — нужно помнить обо всех дырах, что в случае большого capacity очень накладно.
Соответственно структуру лучше выбирать, когда известна задача — статья больше полезна для разминки мозгов, за что автору спасибо.
Мое знакомство с реверсом началось с того, что я устал прокачивать навык метания ножа в игре Silent Storm (где навыки прокачиваются по мере их использования, как в The Elder Scrolls) и захотел автоматизировать этот процесс — в этом помогли общение на форумах и много самостоятельных исследований. Не могу вспомнить, чтобы книги поначалу как-то помогли — но после практики действительно позволяют углубить знания (как по мне, только после практики).
Помимо приведенных книг могу посоветовать канал Zer0Mem0ry.
Игроки, которые хотят развиваться в жанрах, где читеры имеют слишком сильное преимущество и не дают нормально играть, обычно уходят в лиги (к примеру esea для CS:GO), где свои, довольно суровые античиты (что все равно не спасает), свой mm, а главное — у людей другое отношение к игре.
В итоге нечестному игроку придется заплатить не только за игру, а еще за платформу лиги + подписка на чит будет стоить уже других денег (а если его поймают, забанят не только аккаунт, а еще и железо — отмыть такой бан также стоит дополнительных затрат).
Одна из причин — разнообразие. На примере Dota 2: можно в одном сражении взять однокнопочного Лиорика, в другой Инвокера с 10 способностями, а в третьей пикнуть Пуджа, фаниться и фидить на нем всю игру, словить 4 репорта и пойти играть лп.
Самое главное — полезность фичи, остальное уже вопрос ресурсов.
Вообще видел много постов на соответствующих форумах про баны за использование Cheat Engine — помню даже пост, где автор был возмущен тем, что получил бан за то, что CE был запущен — просто запущен, не был даже выбран процесс для анализа.
Хотя примечательно то, что в последнее время я действительно не встречал постов с жалобами / вопросами о наказании. Не могу сказать, что много ковырял Dota 2 с помощью CE — перед тем, как кинуться изучать игру, я почитал форумы и быстро вышел на Source2Gen. Cheat Engine я активно использовал ранее для изучения CS:GO — и получал баны (правда меня банили через 1,5-2 недели, примерно с таким же периодом получал баны на аккаунты с Dota 2, но не по причине использование CE — Ваш бан спустя 2 часа меня удивил).
То же самое можно сказать про использование отладчика (в моем случае x64dbg) — я применял его очень активно (как с использованием ScyllaHide, так и без, как в рейтинговых сражениях, так и в своем лобби), VAC закрывал на это глаза.
Я не видел информации, чтобы CE как то скрывал свою работу (как это делает ScyllaHide в x64dbg), возможно он стал перехватывать определенные системные вызовы (опять же, предположение). Стоит также сказать, что разработчики постоянно что-то меняют в античите — возможно, если бы я начал писать бота не пол года, а скажем 1-2 года назад, то плагин ScyllaHide был бы обязателен для отладки.
Подведу итог: не могу ответить на Ваш вопрос точно, лишь выскажу предположения:
Согласен, как вариант.
Оформлял статью по заметке, соответственно лучше source использовать.
Код поднял настроение:)
К тому же, когда используют игровые движки, обычно их сетевую часть и модели использую, в сравнении с остальным функционалом, меньше всего и пишут свое решение (мои личные наблюдения).
Если не секрет, для чего использовали?
В таком случае советую Вам дополнительно изучить работу Page Guard и Forced Exception Hook — их тоже многие античиты игнорируют — правда с быстродействием могут быть проблемы, применять надо осторожно.