Comments 6
UFO just landed and posted this here
Ни слова про читы? При таком подходе (в отсутствии серверного программиста или просто опытного специалиста) нередко вдруг оказывается так, что клиенту доверяется слишком многое, а потом удивительные вещи творятся… Как решает эту проблему подход с ECS? Происходит ли полностью независимая симуляция игрового мира на сервере только лишь с обработкой инпута игрока?
Я много лет разрабатываю онлайн игры и могу сказать, что подход с реюзаемостью кода между клиентом и сервером безусловно крайне полезен и позволяет сэкономить уйму времени. ECS же, в свою очередь, имеет свои минусы когда требуется нечто более сложное, чем сетевой шутер и логика обработки для определённых случаев должна затрагивать сразу множество компонент. Тут, однако, я не эксперт — мои эксперименты с ECS подходом не дали ожидаемых результатов и в ход пошло изобретение своих подходов. Собственно, ECS не обязателен для реюзания кода между клиентом и сервером, и подходы возможны разные. Если вам интересно, можете глянуть последний мой проект (ссылка на сайт студии в профиле) — там весь код (кроме движка) — с открытым кодом (пока без публичного Гитхаба, просто скачиваете и распаковывайте, игра идёт в комплекте с Roslyn'ом и имеет всё перекомпилировать и перезагружать на горячую). Реюзание кода позволяет реализовать независимую симуляцию игрового мира, включая перемещение персонажа (но тут в дело идёт lag prediction конечно же), использование предметов, менеджмент инвентаря, стрельба из оружия и т.п… Конечно, далеко не всё возможно таким способом симулировать — тогда в ход идёт маскировка лага — но в целом игра ощущается здорово если всё делать правильно. За счёт того, что всё основано на прозрачной репликации данных и автоматической сериализации RPC, приходится писать значительно меньше кода (так называемого водопроводного кода, особенно когда клиент и сервер на разных языках пишутся и требуется писать отдельные прослойки сетевых команд и т.п.).
Я много лет разрабатываю онлайн игры и могу сказать, что подход с реюзаемостью кода между клиентом и сервером безусловно крайне полезен и позволяет сэкономить уйму времени. ECS же, в свою очередь, имеет свои минусы когда требуется нечто более сложное, чем сетевой шутер и логика обработки для определённых случаев должна затрагивать сразу множество компонент. Тут, однако, я не эксперт — мои эксперименты с ECS подходом не дали ожидаемых результатов и в ход пошло изобретение своих подходов. Собственно, ECS не обязателен для реюзания кода между клиентом и сервером, и подходы возможны разные. Если вам интересно, можете глянуть последний мой проект (ссылка на сайт студии в профиле) — там весь код (кроме движка) — с открытым кодом (пока без публичного Гитхаба, просто скачиваете и распаковывайте, игра идёт в комплекте с Roslyn'ом и имеет всё перекомпилировать и перезагружать на горячую). Реюзание кода позволяет реализовать независимую симуляцию игрового мира, включая перемещение персонажа (но тут в дело идёт lag prediction конечно же), использование предметов, менеджмент инвентаря, стрельба из оружия и т.п… Конечно, далеко не всё возможно таким способом симулировать — тогда в ход идёт маскировка лага — но в целом игра ощущается здорово если всё делать правильно. За счёт того, что всё основано на прозрачной репликации данных и автоматической сериализации RPC, приходится писать значительно меньше кода (так называемого водопроводного кода, особенно когда клиент и сервер на разных языках пишутся и требуется писать отдельные прослойки сетевых команд и т.п.).
Пока мы делаем это руками и когда появляется новая фича, а мы забываем вырезать эти данные, то что-то идет не так. На самом деле это можно генерировать, пометив каким-нибудь атрибутом.Кстати, именно такой подход в своём проекте и использую: в описании класса-стейта данных необходимо пометить, какие поля (вернее C# свойства) реплицируются на клиент (опционально указать каналы передачи данных — reliable/unreliable, sequenced и т.п.; частота репликации тоже настраивается), дальше уже с помощью Roslyn движок сам генерирует нужный код уведомляющий сервер об изменении синхронизируемых свойств — все изменения передаются в систему репликации. Однако, конечно, тут есть ряд хитростей вроде того, что не все свойства должны реплицироваться — некоторые из них клиент-владелец персонажа может самостоятельно симулировать и лишь учитывать изменения от сервера (пример — стамина персонажа, её расход при беге и регенерация в покое; клиент может самостоятельно всё симулировать, а сервер в принципе может отправлять лишь изменения вроде «добавлено +30 стамины» (к примеру, был выпит energy drink)), в то время как другие клиенты всё-таки должны получать обновлённые значения таких свойств.
Ни слова про читы? При таком подходе (в отсутствии серверного программиста или просто опытного специалиста)
Читы бывают разные, если игрок через Artmoney-подобные программы ломанёт себе бесконечное здоровье, то, насколько я понял из статьи, это никак не повлияет на игровой процесс, ибо сервер всегда хранит эталон состояния игрового мира, и для других игроков он будет всё так же смертен.
ECS же, в свою очередь, имеет свои минусы когда требуется нечто более сложное, чем сетевой шутер и логика обработки для определённых случаев должна затрагивать сразу множество компонент.
ECS это в принципе спорный подход, особенно для шутрера, особенно для мобильного, но в статье это и не отрицают, каждый подход имеет свои плюсы и минусы, всё зависит от конкретных задач.
Читы — имею ввиду разнообразные хаки, когда сервер доверяет клиенту часть authority. Как я понимаю, ECS позволяет симулировать независимо все системы и подразумевается что пересылается только инпут. Однако возможно, что сервер принимает и более сложные входные данные и даёт какой-то authority клиенту (чтобы сделать игру приятней с точки зрения клиента т.к. полная authority модель чрезвычайно сложная — в плане необходимости писать lag prediction и lag reconciliation механизмы которые всё равно не будут работать идеально просто потому что сеть не работает идеально). Именно это я и хотел бы уточнить.
В последние годы очень много «hack-fest» инцидентов в многопользовательских играх произошло и происходит, причём даже в случае ААА игр, а не только инди (которые во многом ограничены тем что им предлагает используемая высокоуровненовая сетевая библиотека большинство из которых заточены на P2P сетевую модель). Сервер слишком много доверяет. Примеры типичных хаков — клиент может попытаться поменять позицию и сервер с этим согласится, клиент может выстрелить когда не хватает патронов, клиент может прислать сообщение что по кому-то произвёл выстрел и успешно попал/убил и т.п…
Проблема настолько распространённая и дикая что разработчикам (особенно инди с небольшими бюджетами) игр с authoritative server model приходится отбиваться от заявлений игроков что игра легко ломается и т.д… У нас например один игрок сообщил, что хотел бы да боится хостить свой сервер игры ибо «есть слухи что ваша игра моментально ломается простейшими средствами». И доказательства никакие не требуются, уже верят наслово именно по той причине, что в последние годы ситуация печальная даже для десктопных игр — когда PUBG и Fortnite судятся с читерами и выигрывают, когда многие ААА игры (особенно отметились Ubisoft но там конечно спасибо нужно отдать P2P модели которую они с фейлом несколько лет пытались использовать с целью снижения расходов на серверную инфраструктуру, в итоге одумавшись и занявшись «гибридным подходом») имеют на ютубе удивительные видео с хаками, что ещё могут обычные игроки ожидать, тем более от инди? (если любопытно, вот мой официальный ответ игрокам на эту проблему forums.atomictorch.com/index.php?topic=1147.0 )
В последние годы очень много «hack-fest» инцидентов в многопользовательских играх произошло и происходит, причём даже в случае ААА игр, а не только инди (которые во многом ограничены тем что им предлагает используемая высокоуровненовая сетевая библиотека большинство из которых заточены на P2P сетевую модель). Сервер слишком много доверяет. Примеры типичных хаков — клиент может попытаться поменять позицию и сервер с этим согласится, клиент может выстрелить когда не хватает патронов, клиент может прислать сообщение что по кому-то произвёл выстрел и успешно попал/убил и т.п…
Проблема настолько распространённая и дикая что разработчикам (особенно инди с небольшими бюджетами) игр с authoritative server model приходится отбиваться от заявлений игроков что игра легко ломается и т.д… У нас например один игрок сообщил, что хотел бы да боится хостить свой сервер игры ибо «есть слухи что ваша игра моментально ломается простейшими средствами». И доказательства никакие не требуются, уже верят наслово именно по той причине, что в последние годы ситуация печальная даже для десктопных игр — когда PUBG и Fortnite судятся с читерами и выигрывают, когда многие ААА игры (особенно отметились Ubisoft но там конечно спасибо нужно отдать P2P модели которую они с фейлом несколько лет пытались использовать с целью снижения расходов на серверную инфраструктуру, в итоге одумавшись и занявшись «гибридным подходом») имеют на ютубе удивительные видео с хаками, что ещё могут обычные игроки ожидать, тем более от инди? (если любопытно, вот мой официальный ответ игрокам на эту проблему forums.atomictorch.com/index.php?topic=1147.0 )
ECS это в принципе спорный подход, особенно для шутрера, особенно для мобильногоТем не менее, на этом подходе успешно построен Overwatch и это не перестаёт меня удивлять (всё-таки там множество уникальных ability персонажей которые так просто не закодить с обычным ECS подходом). Возможно нужно просто уметь грамотно готовить ECS. Увы, когда я разбирался последний раз с этим, видео об ECS в Overwatch с GDC (2017?) было доступно только в GDC Vault за 550 USD/год (и вроде бы ничего с тех пор не изменилось).
Я еще не посмотрел это видео, но возможно оно вам поможет www.youtube.com/watch?v=W3aieHjyNvw
Благодарю! Да, в итоге видео опубликовали в феврале 2019 и я его сразу же посмотрел. К сожалению, далеко не на все вопросы нашлись ответы (очень много граблей, которые просто невозможно разобрать за час). Но стало понятно, что этот подход удобен и эффективен только в определённых сценариях — собственно, о чём я и писал ранее.
Сейчас ECS активно продвигают в том же Unity, так что материалов много и более ясны плюсы-минусы. Но массового применения ECS пока не заметно (именно для игровой логики, а не только физики/рендеринга, для чего аналогичные data-oriented подходы уже много лет применяют в целях оптимизации доступа к памяти). Далеко не многие серьёзные игры можно разобрать на такие системы-конвейеры, способные обрабатывать массивы данных однообразного формата. Из AAA игр с данным подходом мне по-прежнему известен только Overwatch — и есть хороший вопрос, во что он в итоге развился за эти годы и какой процент их архитектуры организован как ECS.
Сейчас ECS активно продвигают в том же Unity, так что материалов много и более ясны плюсы-минусы. Но массового применения ECS пока не заметно (именно для игровой логики, а не только физики/рендеринга, для чего аналогичные data-oriented подходы уже много лет применяют в целях оптимизации доступа к памяти). Далеко не многие серьёзные игры можно разобрать на такие системы-конвейеры, способные обрабатывать массивы данных однообразного формата. Из AAA игр с данным подходом мне по-прежнему известен только Overwatch — и есть хороший вопрос, во что он в итоге развился за эти годы и какой процент их архитектуры организован как ECS.
Sign up to leave a comment.
Общая игровая логика на клиенте и сервере