Комментарии 6
НЛО прилетело и опубликовало эту надпись здесь
Ни слова про читы? При таком подходе (в отсутствии серверного программиста или просто опытного специалиста) нередко вдруг оказывается так, что клиенту доверяется слишком многое, а потом удивительные вещи творятся… Как решает эту проблему подход с 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.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Общая игровая логика на клиенте и сервере