Я вот чем больше изучаю другие движки тем больше склоняюсь к тому, что вот это разделение на клиентские и серверные энтити - это невероятная дурь и она не нужна абсолютно. Ничего кроме неудобства, дублирования кода и повышенного потребления памяти она не создает.
Движок никогда не работает в таком режиме, когда бы его два набора энтить оказались разделены реальным сетевым соединением, это всегда две разные копии игры на удалённых машинах, ну или хотя бы на одной, но через микрософтовский лупбэк. То есть нет никакого резона держать в рамках одной сессии два набора энтить. Это очень порочная практика, которая порождает массу проблем на самом деле, но мы уже настолько к ним привыкли, что даже не можем себе представить, что может быть как-то иначе. Ну например чисто серверная энтить по дефолту не имеет предиктинга. В лучшем случае он достается только игроку, хотя по идее должен быть у всех энтить абсолютно. То есть у нас либо один и тот же файл компилируется дважды, на клиенте и на сервере, либо вообще для клиента приходится городить какой-то отдельный урезаный огород, который бы выполнял функцию предиктинга. Если функционал серверной энтити поменяется - значит клиентскую тоже надо пересобрать как минимум. Наиболее отвратный пример такого подхода - голдсорсовский предиктинг оружия. Насколько я знаю его так никто и не освоил, в лучшем случае копипастой с похожего оружия. Народ просто не понимает что там и куда копировать, чтобы это работало. При том что наилучшие результаты предиктинга вообще-то достигаются при полной идентичности клиент-серверного кода, а единственное что меняется - это время с серверного на клиентское. Второй негативный момент - два набора энтить потребляют в несколько раз больше памяти. Зависит от организации этого набора. Может и в два, а может и в полтора. И на клиенте у нас всегда несовпадающий функционал, из-за чего даже трассу приходится дублировать. Причём это справедливо, даже если ты не просто пишешь новые энтити, а что-то делаешь в движке. Если ты что-то сделал на серверной части, у тебя сразу головная боль - надо чтобы на клиенте это тоже работало. Но два набора это не предел. Теперь когда мы передали энтити на клиент нам еще надо их нарисовать. Для чего выделяется очередной список либо из клиентских, либо из особых рендер_энтить. Что в свою очередь порождает проблему слабой контролируемости рендерера из сервера. Ну вы помните как скорость движения конвейера в рендерколор запихнули. И соответственно в движке ответный хак. Хотя оптимальным выходом была был виртуальная функция в классе энтити, ну что-то типа ChangeRendererParams и там для этой энтити бы применялись какие-то настройки. Аналогично и с отрисовкой. Иметь в классе энтити еще один виртуальный метод типа DrawModel. И там уже прекрасно себе настраивать кости или еще что-то специфичное выполнять. И всё это в рамках одной библиотеки. Зачем дизайнеру игрового кода вообще забивать себе голову клиент-серверной архитектурой, особенно если разрабатывается сингл?
А для сетевой модели в класс добавляются пара виртуальных же функций, типа ReadFromSnapshot и WriteToSnapshot, по аналогии с сейв-рестором. И оно там себе само прекрасно пишет и читает, минуя промежуточные стадии вроде entity_state_t. baseline при таком подходе создаётся вообще автоматически - клиент точно так же спавнит карту и читает на ней все энтити и к моменту прихода первой дельты у него уже есть с чем её сравнивать. То есть baseline вообще не надо никуда передавать. Чисто клиентские энтити в эту систему укладываются даже лучше чем в классическую. Нам достаточно будет добавить что-то типа настроечного флага FCAP_CLIENT_ENTITY и всё. В сингле её проспавнит сервер, в мультике - клиент, и в обоих случаях у нас будет с ней нормальная коллизия с предиктингом. Да, её нельзя удалять с карты, она будет занимать слот, но она будет его занимать в любом случае, если мы хотим её сохранить в сейв например. Просто она будет занимать какой-то отдельный массив, а при записи демки, к примеру. нам всё равно придется заново переслать эти энтити на клиент. То есть все вот эти уловки с отдельными массивами для специфических энтить, они только усложняют и запутывают всё дело, из-за неудачно выбранной архитектуры однажды.
Еще момент - двойной набор энтить предполагает и двойную её обработку, как на клиенте, так и на сервере. Причём фпс при таком подходе будет падать экспоненциально с ростом кол-ва энтить, как вы понимаете, при условии что на клиенте присутствует тот же предиктинг с коллизиями. Вообщем нет положительных сторон. Но мы уже привыкли что их два набора и не можем себе представить что возможно как-то иначе. Стереотип короче говоря.
Дядя Миша
А зачем? Вот почитает тебя какой ни будь Гуль, например, — и у него окончательно крышу сорвёт, уже не только в плоскую землю уверует, а число pi опровергать начнёт. Спросят, а кто же виноват, кто его так с ума свёл? А вот он! Это всё Дядя Миша, сидит в кустах с хитрой ухмылкой.
в данном контексте речь шла о линейности\нелинейности. А уж как правильно называется та или иная загогулина я навскидку вспомнить не смог. Вы так возмутились как будто я переодическую функцию назвал экспонентой. И вообще. Если кто-то чем-то недоволен, он может выразить своё возмущение прямо мне на яндекс.кошелёк в денежном эквиваленте.
Дядя Миша а исходит ли это в принципе из клиент-серверной архитектуры?
Всегда на что-то отдается больше предпочтение и соответственно проектируется. Хорошо, у нас единые энтити и на клиенте, и на сервере. Это будет работать в сингле, но что делать с мультиплеером? Делаем под мультиплеер и в итоге получаем все предиктинги и прочие лагокомпенсации, потому что игровой мир клиента не равен миру сервера.
я вот склоняюсь к тому, чтобы наружу вынести только скрипты, ну типо прогс.дат как в квейке или что-то вроде этого. А остальное всё в движок упрятать и пусть оно там уже будет. Никому это неинтересно.
Дядя Миша писал: Наиболее отвратный пример такого подхода - голдсорсовский предиктинг оружия. Насколько я знаю его так никто и не освоил, в лучшем случае копипастой с похожего оружия. Народ просто не понимает что там и куда копировать, чтобы это работало.
Дико плюсую, это как раз одна из самый геморойных частей кода HLSDK, очень долго с ней ковырялся.
А, ещё дико бесит прописывание "заглушек" на клиенте для методов серверных базовых классов. Думаю, потом просто неиспользуемые на клиенте методы изолирую от компиляции через #ifndef CLIENT_DLL, не знаю что еще с этим ужасом делать.
| IP: 
14-08-2019 08:34
1/х - это экспонента.
И вообще. Если кто-то чем-то недоволен, он может выразить своё возмущение прямо мне на яндекс.кошелёк в денежном эквиваленте.
