1.6.1.4, 1.6.1.5, 1.6.1.6 WorldofTanks. BigWorld Technology. Технология BigWorld. Cell, CellApp

Чит Автор Тема: BigWorld Technology. Технология BigWorld. Cell, CellApp  (Прочитано 41 раз)

Оффлайн Delysid

  • VIP
  • *****
  • Сообщений: 2665
  • Чит карма: +64/-1
1.1 BigWorld CellApp
1.1.1 Применение.
Приложение Cell, или CellApp, представляет собой фактический процесс или исполняемый файл, работающий на компьютере CellApp.
CellApp управляет различными ячейками или экземплярами класса Cell. Ячейка - это геометрическая часть большого пространства или всего небольшого пространства.
BigWorld делит большие пространства на несколько ячеек для равномерного распределения нагрузки. Обычно он выделяет одну большую ячейку для каждого CellApp. При обработке небольших пространств, таких как динамически создаваемые миссии, BigWorld обычно выделяет несколько ячеек для каждого CellApp.
В BigWorld машины CellApp предназначены для запуска только BWMachined и одного CellApp на процессор, и ничего более.
1.1.2 Сущности
CellApps связаны с универсальным типом, сущностью. Каждый CellApp поддерживает список реальных и призрачных объектов в пределах досягаемости. CellApp также поддерживает список любых реальных объектов, которые должны периодически обновляться (например, 10 раз в секунду), и тех, которые поддерживают AoI.
Каждый объект понимает сообщения, связанные с его типом. CellApp доставляет сообщения объекта соответствующему объекту, и он должен их интерпретировать. Способ, которым это реализовано, состоит в том, чтобы каждый объект включал указатель на объект типа объекта. Этот объект имеет информацию, относящуюся к типу сущности, такую ​​как сообщения, которые может обрабатывать тип, и сценарий, связанный с ним.
Каждый тип сущности имеет свой собственный файл сценария. Сценарии выполняются в контексте определенной сущности (т. Е. Они имеют this или self) и имеют доступ к данным, которые другие сущности выбирают сделать доступными (данные сервера и клиента), а также к базовым элементам каждой сущности ( id, позиция,…).
Сценарии отвечают за обработку сообщений, отправляемых объекту. При изменении данных любого сервера или клиента эти изменения автоматически передаются заинтересованным лицам.
1.1.3. Реальные и Призрачные Сущности
Для эффективного обновления своего клиента каждый аватар хранит список объектов в своем AoI, который обычно представляет собой круг с радиусом 500 м. Одна проблема, которая возникает, состоит в том, что не все объекты могут контролироваться одной и той же ячейкой.
Однако было бы очень неэффективно, чтобы каждый объект по отдельности определял, какие объекты в соседних ячейках должны быть скрыты. Решение состоит в том, чтобы ячейки обычно управляли призрачными сущностями. Если сущность находится в пределах призрачного расстояния от границы ячейки, ячейка создает призрак сущности в этой соседней ячейке.
Термин «реальная сущность» введен для того, чтобы различать главные представления и (импортированных) призраков. На рисунке ниже показаны все объекты, поддерживаемые ячейкой 1:
Раз в секунду ячейка проходит через свои реальные объекты, чтобы проверить, следует ли ей добавлять или удалять призраков для них в соседних ячейках. Он отправляет сообщения соседу, чтобы добавить и удалить призраков.
1.1.4. Переход между пространствами
Самый простой способ перехода между различными пространствами - это просто «вытолкнуть», то есть удалить сущность из старого пространства и воссоздать ее в новом. Это просто как на клиенте, так и на сервере.
1.1.5. Список приоритетов свидетелей
Всякий раз, когда к объекту присоединен клиент, подобъект, известный как свидетель, связывается с объектом, чтобы поддерживать список объектов в его AoI. Свидетель создает пакеты обновления для отправки своему клиенту, и он должен отправлять наиболее важную информацию в качестве приоритета.
Клиент требует, чтобы позиция и другая информация других объектов, которые наиболее близки к нему, были наиболее точными и актуальными. Более близкие сущности должны обновляться чаще. Для этого свидетель сохраняет список объектов в своем AoI в качестве приоритетной очереди.
Чтобы создать пакет для отправки клиенту, соответствующая информация об объектах в верхней части списка добавляется в пакет до тех пор, пока не будет достигнут желаемый размер. Информация может включать положение и направление, а также события, которые объект обработал с момента последнего обновления. Для получения дополнительной информации см. История событий.
Более близкие объекты получают более частые обновления и получают большую долю доступной пропускной способности.
BigWorld регулирует пропускную способность нисходящего потока в соответствии с размером пакетов обновления и их частотой. Эти параметры указаны в файле конфигурации /server/bw.xml.
Список приоритетов AOI e0:
e1 Список событий обновления положения и направления на 10 м {прыжок, смена оружия…}
e2 Список событий обновления положения и направления на 20 м {прыжок, смена оружия…}
e3 Список событий обновления положения и направления на 30 м {прыжок, смена оружия…}
1.1.1.1. История событий
Каждая сущность хранит историю своих недавних событий. История включает в себя как события, которые меняют свое состояние (например, смена оружия), так и действия, которые этого не делают (например, прыжки и стрельба). Частые действия, такие как перемещение, которые влияют на изменчивые данные, не сохраняются в списке истории.
Когда объект использует свою очередь приоритетов для создания пакета обновления, он просматривает новые события верхних объектов (т. Е. Те, которые закрываются для него) и добавляет все сообщения, в которых он заинтересован. Для этого требуется сохранить временную метку (фактически последовательность номер) для последнего обновления каждого объекта в очереди приоритетов.
История событий такого типа довольно короткая (около 60 секунд), поскольку мы ожидаем, что каждый объект в очереди с приоритетами будет рассматриваться (примерно) каждые 30 секунд в худшем случае.
1.1.1.1.1 Уровень детализации
Очередь приоритетов обрабатывает регулирование данных для непрерывной информации. Для событий нам все еще нужно обработать случай, когда слишком много событий заполняет доступную полосу пропускания нисходящего потока для клиента.
Когда в AoI объекта много объектов, информация о каждом из них отправляется реже, но общее количество событий остается неизменным.
Для решения этой проблемы BigWorld использует систему уровня детализации (LOD) для обработки изменений, основанных на событиях. Его принцип заключается в том, что чем ближе объект к аватару, тем больше деталей он должен отправить своему клиенту.
Например, когда игрок изначально входит в AoI аватара, аватар не должен знать все подробности о другом игроке. Видимый инвентарь может потребоваться только в пределах, скажем, 100 метров. Более мелкие детали, такие как значок на одежде, могут понадобиться только в пределах 20 метров.
1.1.1.1.1.1 События без изменения состояния
В описании каждого типа сущности есть описание всех сообщений (событий, не меняющих состояние), которые он может генерировать, а также приоритет, связанный с каждым из них.
Когда аватар добавляет информацию об объекте, он добавляет только сообщения с приоритетом, превышающим текущий интерес аватара к объекту. Поэтому сообщения будут игнорироваться в зависимости от расстояния между аватаром и сущностью.
Например, тип разговора может быть слышен только в пределах 50 метров, или прыжок виден только в пределах 100 метров.
1.1.1.1.1.2 События, изменяющие состояние
GECOEngine не может игнорировать события изменения состояния, которые происходят вне диапазона, потому что, если объект впоследствии действительно подойдет достаточно близко, у клиента будет неправильная копия состояния объекта.
Например, клиент может интересоваться типом оружия, которое носит объект, но только когда оно находится в пределах 100 метров. Если сущность меняет свое оружие вне этого диапазона, то эта информация еще не отправлена ​​клиенту. BigWorld отправит его, только если объект находится в пределах досягаемости.
В отличие от событий без изменения состояния, в которых уровень приоритета может иметь любое значение, события с изменением состояния имеют дискретное или несмежное количество LOD состояний, указанных разработчиком.
Их можно рассматривать как кольца вокруг клиента. Каждое свойство типа объекта может быть связано с одним из этих колец. Для примера:
 <seatType> <Type> INT8 </Type> <Flags> OTHER_CLIENT </Flags> <Default> -1 </Default> <!-- See Seat.py --> <DetailLevel> NEAR </DetailLevel> </seatType>
Например, предполагаемый аватар A окружен четырьмя объектами одного типа с уровнями LOD на 20, 100 и 500 метров. Он будет обрабатывать каждый объект в соответствии с его расстоянием, как описано в таблице ниже:

Cущность Расстояние 20м 100m 500m
E1 15m y y y
E2 90m n y y
E3 400m n n y
E4 1000m n n n

Когда объект со связанным свидетелем попадает в кольцо LOD другого объекта, любое состояние, связанное с кольцом, которое изменилось с момента их последнего закрытия, отправляется клиенту.
использует временные метки для предотвращения очень частых обновлений. Временная метка хранится с каждым свойством каждого объекта. Эта временная метка указывает, когда это свойство было изменено в последний раз. Кроме того, для каждого объекта в AoI свидетеля отметка времени, соответствующая тому, когда этот объект последний раз покинул этот уровень, сохраняется для каждого кольца LOD.
Само по себе это не позволяет нам ограничивать эти данные. Чтобы достичь этого, нам нужно только применить коэффициент умножения к интересующему уровню аватара, когда он рассчитывается для других объектов. Умножение на коэффициент меньше единицы уменьшает количество отправляемых данных. В результате, чем больше кольцо, тем больше данных будет отправлено. чем меньше кольцо, тем меньше данных для отправки.
1.1.6. Сценарии и сущности
В следующих подразделах описано, как использовать сценарии для сущностей.
1.1.6.1. Классы сущностей
Класс сущности описывает тип сущности. Список ниже описывает его составные части:
XML-файл определения / скрипты / entity_defs / .def
Скрипт ячейки Python / Скрипты / клетка / .py
Базовый скрипт Python / Скрипты / базы / .py
Клиентский скрипт Python / Скрипты / клиент / .py
Файл определения XML можно рассматривать как интерфейс между сценариями Cell, Base и Client. Он определяет все доступные публичные методы и все свойства объекта. Кроме того, он определяет глобальные характеристики класса, такие как:
Требует ли организация изменчивых обновлений позиций.
Как объект создается на клиенте.
Базовый класс сущности, если есть.
Интерфейсы, реализованные объектом, если таковые имеются.
1.1.6.2. Пример файла определения сущности
Ниже приведен пример файла определения сущности /scripts/entity_defs/Seat.def.
 <root> <Properties> <seatType> <Type> INT8 </Type> <Flags> OTHER_CLIENT </Flags> <Default> -1 </Default> <!-- See Seat.py --> <DetailLevel> NEAR </DetailLevel> </seatType> <
 ownerID> <Type> INT32 </Type> <Flags> OTHER_CLIENT </Flags> <Default> 0 </Default> </ownerID> <channel> <Type> INT32 </Type> <Flags> PRIVATE </Flags> </channel> </Properties>
 <ClientMethods> <clientMethod1> <Arg> STRING </Arg> <!-- msg --> <DetailDistance> 30 </DetailDistance> </clientMethod1> </ClientMethods> <CellMethods> <sitDownRequest> <Exposed/>
 <Arg> OBJECT_ID </Arg> <!-- WHO --> </sitDownRequest> <getUpRequest> <Exposed/> <Arg> OBJECT_ID </Arg> <!-- WHO --> </getUpRequest> <ownerNotSeated> </ownerNotSeated> <tableChat>
 <Arg> STRING </Arg> <!-- msg --> </tableChat> </CellMethods> <LODLevels> <level> 20 <hyst> 4 </hyst> <label> NEAR </label> </level> <level> 100 <hyst> 10 </hyst> <label> MEDIUM
 </label> </level> <level> 250 <hyst> 20 </hyst> <label> FAR </label> </level> </LODLevels> </root>
1.1.6.3. свойства
Все свойства определены в файле XML,
наряду с их типом данных,
необязательное значение по умолчанию,
флаги, чтобы указать, как они должны быть реплицированы,
и необязательный тег DetailLevel для обработки LOD.
Все свойства сущности ячейки должны быть определены, даже если они являются частными для класса. Это связано с тем, что CellApp необходимо выгружать объекты в другие CellApp,
а наличие определенных типов данных всех свойств позволяет передавать данные максимально эффективно.
Примечание. По соображениям безопасности и эффективности, когда клиент изменяет общее свойство, это изменение не распространяется на сервер. Все коммуникации от клиента к серверу должны выполняться
с использованием вызовов методов.
Это связано с тем, что только при изменении или обновлении исходных данных можно распространять новое значение на данные копирования. И единственный способ, которым клиент может изменить исходные данные, - через rpc.
Когда скрипт Python изменяет значение свойства, сервер выполняет работу по распространению изменения этого свойства в правильные места.
Другими словами, когда свойство изменилось из собственного клиента объекта с помощью rpc или команды msg, сервер использует:
флаги OWN_CLIENT и ALL_CLIENTS, чтобы определить, следует ли отправлять обновление собственному клиенту объекта,
флаги OTHER_CLIENTS и ALL_CLIENTS, чтобы определить, следует ли отправлять обновление другим клиентам.
Флаг состоит из SourceProcess + Accessibility + PropagationProcess.
SourceProcess не должен совпадать с PropagationProcess.
SourceProcess находится в числе CELL, BASE или CLIENT,
Доступность относится к числу ОБЩЕСТВЕННЫХ, ЧАСТНЫХ ИЛИ ЗАЩИЩЕННЫХ.
PropagationProcess входит в число ALL_CLIENT, OWN_CLIENT, OTHER_CLIENT, BASE или NONE, если только хранится в SourceProcess без распространения.
То есть, ALL_CLIENT может рассматриваться как CELL__PUBLIC__ALL_CLIENT.
Следующие флаги используются в определении XML, чтобы определить, как должно реплицироваться каждое свойство.
ALL_CLIENT
Подразумевает флаг CELL_PUBLIC
Относится только к юридическим лицам со связанным клиентом,
IE., Сущность игрока Свойства, которые видны всем близлежащим клиентам, включая владельца.
Соответствует установке флагов OWN_CLIENT и OTHER_CLIENT.
БАЗА
Свойства, которые используются на базах.
CELL_PRIVATE
Свойства, которые содержат информацию о состоянии, которая является внутренней для объекта.
Они доступны владельцу и только в ячейке.
Они не будут призраками, и как таковые, сущности в других клетках не смогут их видеть.
CELL_PUBLIC
Свойства, которые видны другим объектам на сервере.
Они будут призраками, и любая другая близлежащая сущность сможет прочитать их, находятся ли они в одной и той же ячейке или нет (если они находятся на расстоянии AOI).
ПРИМЕЧАНИЕ. Определения свойств также могут включать тег DetailLevel. Это используется для обработки данных LOD. Подробнее об обработке LOD см. В документе Руководство по программированию сервера Прокси и проигрыватели → Управление сущностями .
1.1.6.4. Встроенные свойства
В дополнение к свойствам, определенным в файле XML, сценарии сущности ячейки также имеют доступ к нескольким встроенным свойствам, предоставляемым средой сценариев ячейки. Они включают:
id (только для чтения) Integer ID объекта.
spaceID (только для чтения) ID пространства, в котором находится объект.
транспортное средство (только для чтения) Некоторая другая сущность (или Нет), на которой едет сущность.
position (Чтение / запись) Положение объекта в виде набора из 3-х чисел.
Направление (чтение / запись) Направление объекта в виде кортежа, шага и рыскания.
isOnGround (Чтение / запись) Целочисленный флаг, содержащий 1, если объект находится на земле, или 0 в противном случае.
Можно переместить объект, изменив его свойство позиции. Однако для непрерывного движения рекомендуется метод moveToPoint. На spaceID и свойства транспортного средства влияют методы teleport и boardVehicle соответственно.
1.1.6.5. методы
Существуют различные разделы для методов клиента, ячейки и базы, и каждый метод содержит свое имя и список аргументов.
Клеточные и базовые методы также могут иметь тег. Это указывает, может ли клиент вызвать этот метод. Открытые методы в ячейке имеют неявный аргумент source, который является идентификатором объекта,
связанного с клиентом, вызвавшим метод.
Определения методов также могут иметь атрибут, который используется в отношении фильтрации уровня детализации.
1.1.6.6. Вызов методов клиента
У клиента есть ссылки на все объекты, которые находятся в его AoI. Сотовый компонент объекта может вызывать методы других клиентских объектов (включая свои собственные), которые существуют в этом AoI.
Сценарию ячейки доступны четыре свойства, облегчающие вызов клиентских методов. Это:
ownClient (или клиент)
otherClients
allClients
clientEntity
Метод, вызванный для одного из этих объектов, будет доставлен указанным клиентам.
Например, чтобы вызвать метод chat в клиентском скрипте для этого объекта, для всех соседних клиентов: self.allClients.chat( "hi!" ) .

1.1.6.7. Встроенные методы ячейки
Сценарий ячейки имеет доступ к многочисленным встроенным методам сценариев, некоторые из которых описаны в списке ниже:
уничтожить - уничтожает сущность.
addTimer - добавляет асинхронный таймер обратного вызова.
moveToPoint - перемещает объект по прямой линии к точке.
moveToEntity - перемещает объект в направлении другого объекта.
навигация - перемещает объект к точке, избегая препятствий.
отменить - Отмена контроллера (таймеры, движение и т. д.).
entityInRange - Находит сущности на заданном расстоянии от сущности.

1.1.6.8. Контроллеры
Контроллер - это объект C ++, связанный с сущностью ячейки. Обычно он выполняет задачу, которая будет неэффективной или трудной для выполнения из сценария.
 Он также обычно содержит информацию о состоянии, которую необходимо отправить по сети, если объект выгружен в другую ячейку.
Примеры реализуемых в настоящее время контроллеров:
TimerController - Предоставляет асинхронные синхронизированные обратные вызовы.
MoveToPointController - перемещает объект в позицию с заданной скоростью.
Поскольку контроллеры обычно выполняют операции асинхронно, они уведомляют объект сценария о завершении, вызывая именованный обратный вызов сценария.
Например, TimerController всегда вызывает обработчик события onTimer, а MoveToPointController всегда вызывает обработчик события onMove.

1.1.6.10. Пример файла сценария Сценарий объекта Cell - /scripts/cell/wotcheat.py Ниже приведен пример файла сценария сущности ячейки для объекта Seat:
 "This module implements the Seat entity." import BigWorld import Avatar # -----------------------------------------------------------------------
 # Section: class wotcheat # -----------------------------------------------------------------------
 class wotcheat ( BigWorld . Entity ): "A wotcheat entity." def __init__ ( self ): BigWorld . Entity . __init__ ( self ) def sitDownRequest ( self , source , entityID ):
 if self . ownerID == 0 and source == entityID : self . ownerID = entityID BigWorld . entities [ self . ownerID ] . enterMode ( Avatar . Avatar . MODE_SEATED , self . id , 0 )
 if self . channel : try : channel = BigWorld . entities [ self . channel ] channel . register ( self . ownerID ) except : pass def getUpRequest ( self , source , entityID ):
 if self . channel : try : channel = BigWorld . entities [ self . channel ] channel . deregister ( entityID ) except :
 pass BigWorld . entities [ self . ownerID ] . cancelMode () # The Avatar's cancelMode() method will in-turn call this # wotcheat's ownerNotSeated() method to release itself.
 def ownerNotSeated ( self ): self . ownerID = 0 def tableChat ( self , msg ): if self . channel : channel = BigWorld . cheatsecurity [ self . channel ] assert ( channel )
 assert ( self . ownerID ) channel . tellOthers ( self . ownerID , "[local] " + msg )

1.1.7. Направленные сообщения
Не все события распространяются через историю событий. Если событие предназначено для определенного игрока или небольшого количества игроков, то оно может быть доставлено почти сразу в следующем пакете.

1.1.8. Пересылка от призраков
Каждый призрак знает свою реальную ячейку, поэтому он может пересылать сообщения в свою реальную версию для обработки.
Большинство сообщений имеют тип извлечения , например, когда другой игрок прыгает - это зависит от аватара (через очередь приоритетов), чтобы решить, отправлять ли это своему клиенту и когда.
Меньшинство сообщений имеет разновидность толчка, например, когда игрок A хочет пожать руку игроку B. Для этого клиент A отправляет запрос рукопожатия в свою ячейку, который, в свою очередь,
 делает запрос аватару B в той же ячейке. ,
Аватар B может быть призраком, и в этом случае он перенаправляет запрос в свое реальное представление. Это общение происходит автоматически и прозрачно.

1.1.9. Разгрузка сущностей
Примерно раз в секунду каждая ячейка проверяет, следует ли разгрузить какие-либо объекты в другие ячейки. Каждая сущность рассматривается против границы текущей ячейки.
Граница искусственно увеличена (примерно на 10 метров), чтобы избежать гистерезиса. Если обнаруживается, что сущность находится за пределами текущей ячейки, она выгружается в наиболее подходящую.
Когда объект выгружается, объект реального объекта преобразуется в объект-призрак и наоборот, когда объект загружается.

1.1.10. Добавление и удаление ячеек
Когда ячейка добавляется в большое многоклеточное пространство во время выполнения, это делается путем постепенного увеличения ее площади, чтобы избежать большого всплеска в объектах, пытающихся изменить ячейки.
Точно так же для удаления ячейки ее площадь медленно уменьшается, пока не исчезнут все сущности.
1.1.11. Балансировки нагрузки
Границы ячеек перемещаются, чтобы отрегулировать долю нагрузки на сервер, за которую отвечает отдельная ячейка.
Основная (упрощенная) идея состоит в том, что если ячейка перегружена по сравнению с другими ячейками, то ее площадь уменьшается. И наоборот, если он недогружен, то его площадь увеличивается.

1.1.12. физика
Из-за таких факторов, как задержка, возникающая при прохождении через Интернет, большое количество желаемых игроков и ограничения пропускной способности, трудно (если не невозможно) добиться убедительной игры, в которой делается попытка полной обработки столкновений.
Для получения дополнительной информации см. Раздел «Руководство по программированию сервера» Прокси и проигрыватели → Управление сущностями.

1.1.13. Система навигации
Ключевые особенности навигационной системы:
Навигация как внутри, так и на открытом воздухе.
Плавный переход между внутренним и наружным регионами.
Динамическая загрузка графов navpoly.
Кэширование путей, для эффективности.
Подробнее см. Документ « Руководство по программированию сервера», раздел «Объекты и юниверс» → «Система навигации».

1.1.14. Триггеры диапазона и запросы диапазона
Часто возникает необходимость инициировать событие, когда объект (определенного типа) подходит достаточно близко к другому. Они называются Range Triggers.
Также необходимо найти все объекты, которые находятся в данной области. Это называется Range Query.
Чтобы выполнить запрос диапазона, программное обеспечение ищет только один из этих списков на расстоянии диапазона запроса, а затем выбирает объекты геометрически в диапазоне (это может быть достигнуто путем установки пересечения, которое должно <z и <y).
Чтобы выполнить триггер диапазона, объект, который интересуется конкретным диапазоном, вставляет триггеры высокого и низкого уровней в списки X и Z. Когда объект перемещается, списки и триггеры обновляются. Когда другие объекты перемещаются, списки обновляются. Если объект пересекает триггер или триггер пересекает объект, то программное обеспечение проверяет другое измерение, чтобы проверить, действительно ли это событие триггера.
Для большинства ситуаций этот алгоритм оказался очень эффективным.

1.1.15. Отказоустойчивость
CellApp разработан, чтобы быть отказоустойчивым. Процесс CellApp может внезапно остановиться или его компьютер может отключиться от сети, что окажет незначительное влияние на работу сервера.

1.2. CellAppMgr
CellAppMgr отвечает за:
Поддержание правильных смежностей между клетками.
Добавление новых аватаров в правильную ячейку.
Выступая в качестве глобального брокера идентификации сущностей.

1.2.1. Регистрация CellApp
Когда запускается новый CellApp, он находит местоположение CellAppMgr, передавая сообщение всем демонам BWMachined.
Если процесс BWMachined имеет CellAppMgr на своем компьютере, то его адрес возвращается CellApp. Как только CellApp обнаружит местонахождение CellAppMgr, CellApp зарегистрируется в нем.
В следующий раз, когда CellAppMgr потребуется создать больше ячеек, новый CellApp будет рассматриваться как потенциальный хост для него.
Точно так же, когда CellApp останавливается, он отменяет свою регистрацию в CellAppMgr, после того как все его ячейки постепенно удаляются.

 
Читеры, которые поблагодарили этот пост про игру World of Tanks: DRUNKCAT



0 Пользователей и 1 Гость просматривают эту тему.

Теги: