Bannerlord Missions

Тема в разделе "Bannerlord Missions (Миссии Bannerlord'а)", создана пользователем Дима Гончар, 28 окт 2020.

Статус темы:
Закрыта.
  1. Дима Гончар

    Дима Гончар Главный администратор Команда форума

  2. Дима Гончар

    Дима Гончар Главный администратор Команда форума

    Источник перевода - https://rusmnb.ru/index.php?action=article;topic=23485.0

    TACTICAL POSITIONS AND TACTICAL REGIONS(ТАКТИЧЕСКИЕ ПОЗИЦИИ И ТАКТИЧЕСКИЕ РАЙОНЫ)

    Это запрограммированные объекты, которые позволяют ИИ (искусственный интеллект) узнать об особенностях местности. Они работают не как осады, ИИ не всегда будет использовать тактические позиции или регионы, в которые вы можете их разместить. Они могут использовать их только в условиях, которые благоприятствуют их использованию.

    В зависимости от перемещения игрока и рандомизации пути спавна (spawn) существует очень большое количество сценариев, которые могут возникнуть во время сражений. Из-за этого лучше иметь как можно больше тактических позиций и регионов, как только возможно.
    Их отсутствие или отсутствие меток некоторых тактических позиций не приведет к очевидным ошибкам, как в осадах, но приведет к менее интересным сражениям, потому что ИИ не будет знать о них.

    TACTICAL POSITIONS (ТАКТИЧЕСКИЕ ПОЗИЦИИ)

    High Ground, Slope facing direction (Возвышенность, чей склон направлен в какую-то сторону):
    • _width: ИИ будет пытаться сформировать строй на всю ширину если проход слишком узкий, а у AI слишком много войск. Или если проход слишком широк, а войск у ИИ недостаточно, то он может решить, что это плохо подходящая позиция.
    • _slope: Параметр также важен для выбора между позициями, он выражается в градусах, а максимальный наклон в 60 градусов распознается ИИ. Следует приблизительно оценить крутизну позиции.
    • _isInsurmountable: (false) Не применяется.
    • _tacticalPositionType: Возвышенность
    • _tacticalPositionMembership: Лес, ущелье или другая сложная местность.
    • _tacticalPositionSide: BehaviorSideNotSet (Возвышенность, у которой сторона действия противника не установлена).
    [​IMG]


    Top of Hill, Defendable against all directions (Вершина холма, защищенная со всех сторон):
    Этот сценарий для высоких наземных позиций на вершине холмов, легко защищаемых со всех сторон. ИИ может удерживать эти позиции независимо от направления подхода противника. ИИ будет размещать себя на вершине холма в соответствии с позицией противника. Направление не имеет значения.
    • _width: (ширина) что немаловажно, должна быть примерно равна радиусу вершины холма.
    • _slope: (склон) также важен для выбора между позициями, он исчисляется в градусах и его максимум наклона в 60 градусов распознается ИИ. ИИ должен примерно оценить крутизну позиции.
    • _isInsurmountable: Непреодолимая ни кем позиция.
    • _isOuterEdge: (Внешний край) false (отключенный параметр)
    • _tacticalPositionType: Возвышенность
    • _tacticalPositionMembership: Лес, ущелье или другая сложная местность.
    • _tacticalPositionSide: BehaviorSideNotSet (Возвышенность, у которой сторона действия противника не установлена).
    [​IMG]


    Choke Points (Узкие места):
    Это для позиций с непроходимыми барьерами с обеих сторон. ИИ с меньшим числом бойцов может попытаться удержать эти позиции, чтобы компенсировать их недостаток.
    • Направление (Direction) - самая важная часть. Позиция для защиты будет смотреть вперед позиции (зеленая стрелка в редакторе).
    • _width: ИИ будет пытаться сформировать строй на всю ширину если проход слишком узкий, а у ИИ слишком много войск. Или если проход слишком широк, а войск у ИИ недостаточно, то он может решить, что это плохо подходящая позиция.
    • _slope: (склон) также важен для выбора между позициями, он исчисляется в градусах и его максимум наклона в 60 градусов распознается ИИ. ИИ должен примерно оценить крутизну позиции.
    • _isInsurmountable: false (Не применяется) В настоящее время этот сценарий ничего не делает для узких мест, но разработчики хотят добавить проверку как спереди, так и сзади для одной и той же узкости. Так как если _isInsurmountable присвоить значение true, то узкость может быть использована против врагов и спереди и сзади, вместо добавления двух узких мест с противоположными направлениями.
    • _isOuterEdge: (Внешний край) false (отключенный параметр)
    • _tacticalPositionType: Chokepoints (сужение)
    • _tacticalPositionMembership: Лес, ущелье или другая сложная местность.
    • _tacticalPositionSide: BehaviorSideNotSet (Возвышенность, у которой сторона действия противника не установлена).
    [​IMG]


    Cliff Positions (Позиции на скалах):
    Эти тактические позиции сами по себе бессмысленны. Они должны быть помещены в иерархию объектов за тактическими позициями узких мест. Если они размещены за узким проходом и AI применит его, то сценарий будет использоваться только до положения обрыва.
    • Позиции утесов должны быть позициями, которые противник не сможет достичь, когда узкость удерживается другими защитниками.
    • Когда они прорвутся, то стрелки и лучники переместятся в эту позицию.
    • Направление позиции обрыва будет определять, где группа лучников будет строиться при использовании этой позиции.
    • _width: ИИ будет пытаться сформировать строй на всю ширину если проход слишком узкий, а у ИИ слишком много войск. Или если проход слишком широк, а войск у ИИ недостаточно, то он может решить, что это плохо подходящая позиция.
    • _slope: Склон не важен.
    • _isInsurmountable: false (Не применяется)
    • _isOuterEdge (Внешний край): false (отключенный параметр)
    • _tacticalPositionType: Chokepoints (сужение)
    • _tacticalPositionMembership: Лес, ущелье или другая сложная местность.
    • _tacticalPositionSide: BehaviorSideNotSet (Возвышенность, у которой сторона действия противника не установлена).
    [​IMG]


    TACTICAL REGIONS (ТАКТИЧЕСКИЕ РЕГИОНЫ)

    Они предназначены для разметки областей в сценах. Задается только радиус, и сама область имеет круглую форму. Очевидно, что сцены будут иметь регионы с полностью заданной/случайной формой лесами, сложными ландшафтами и открытыми местами. Поэтому следует определить несколько тактических регионов с различными круговыми областями, при необходимости их можно добавить. Радиус и площадь круга каждого региона могут быть приблизительными, не обязательно им быть точными.

    Forest Areas (Лесистые районы)
    ИИ может использовать позиции в лесных районах, если противник имеет большее количество дальнобойных и кавалерийских подразделений, потому что лучники и кавалерия менее эффективны в лесах.
    Любой другой регион, который является невыгодным для дальнобойных подразделений и кавалерии может быть предоставлен как лесной регион.
    И он не обязательно должен быть лесом с деревьями, это может быть городской рынок с большим количеством препятствий и укрытий или что-то подобное.
    [​IMG]


    Difficult Terrain (Труднопроходимая местность)
    Это включает в себя скалистую местность, а также болота, ей могут быть даже рыночные площади или какое-либо другое место с множеством препятствий на земле.
    Любую область, которая не препятствует дальнему огню (например, леса), но препятствует и замедляет кавалерию, следует отмечать как труднопроходимую местность.
    ИИ будет использовать позиции внутри труднопроходимой местности, если у противника превосходящее количество кавалерии.
    [​IMG]


    Open Areas (Открытые территории)
    Позиции, позволяющие быстро двигаться кавалерии и вести сильный огонь лучникам. Этот тип региона предназначен для размещения подходящих полей боя. ИИ может выбрать защиту в этих открытых регионах, если у него есть большее или равное количество стрелков и кавалерии.
    [​IMG]


    TACTICAL REGIONS AND POSITIONS COMBINATIONS (КОМБИНАЦИИ ТАКТИЧЕСКИХ РАЙОНОВ И ПОЗИЦИЙ)

    Тактические позиции также могут быть отнесены к объектам тактического региона. Их _tacticalRegionMembership должен быть правильно выбран. В этой ситуации, ИИ поймет, что, например, узкость находится также и в лесном регионе и при правильных условиях, может предпочесть тактику Choke Points (Узких мест) тактике лесистых районов.
     
    Последнее редактирование: 7 ноя 2020
    Doder нравится это.
  3. Дима Гончар

    Дима Гончар Главный администратор Команда форума

    Источник перевода - https://rusmnb.ru/index.php?action=article;topic=23486.0

    Этот список контрольных точек (checkpoints) должен помочь вам в создании деревенских сцен и дать вам представление о том, на что мы обращаем внимание при создании деревенских сцен.

    Navigation Mesh (Навигационные меши)

    • Навигационный меш состоит из треугольников и четырехугольников. Он используется AI для поиска пути. Глобальная система освещения (global illumination system) также использует его для поиска видимых мест сцены.
    • Имейте в виду, что грани навигационного меша не должны быть слишком далеко от реальной физики для него. Расстояние должно быть не более 1,5 м.
    • Персонажи в деревне должны быть помечены специальными идентификаторами, которые указывают на создание точки спауна этих персонажей, и на передвижение их внутри сцены.
    • Чтобы заставить персонажей (agents) перемещаться по дорогам деревни, мы маркируем их идентификатором ID 2.
    • Обратите внимание, что все точки спауна (появления) должны быть заданы всем персонажам, имеющими ID 2 в этом навигационном меше.
    • Для животных нужно использовать маркировку идентификатора ID 3. Как правило, эти животные находятся в пределах отдельных островков, окруженных рвами. Тогда они будут бродить только внутри этих островков.
    • Все остальные персонажи должны иметь идентификатор ID 0.
    • Помните, что персонажи должны использовать идентификатор навигационного меша ID 1, чтобы создать реалистичный путь движения на дорогах. Дизайнер, создающий сцены, должен поместить объект с деактиватором навигационного меша (название пишется как - Navigation_Mesh_Deactivator). Его можно разместить в любом месте сцены. Его цель - отключить лица с маркировкой ID 0 в гражданских режимах. Переменная DisableFaceWithID скрипта должна быть равна 1.
    • Для животных переменная “DisableFaceWithIDForAnimals” в том же скрипте должна быть равна 3.
    • Убедитесь, что модели персонажей примерно равны по своим размерам и за пределами деревни, где будут маневрировать войска.
    • Убедитесь, что нет отключенных (disconnected) навигационных мешей.
    • Чем лучше сделан навигационный меш, тем лучше будет работать на нем AI. Всегда помните о том, что в деревне может произойти крупное сражение. Поэтому старайтесь избегать наличия большого количества закрытых помещений, таких как свинофермы, только с одним входом (например: переставьте несколько заборов, чтобы создать больше входов).
    • Избегайте создавать очень большие территории, доступные для игрока, но не понятные для AI. Ведь тогда игроки смогут безнаказанно расстреливать юнитов AI из-за пределов навигационного меша.
    • Используйте “_barrier_ai_x” , чтобы предотвратить падение юнитов AI со скал или застревание их в труднодоступных местах (например, в рыночной будке) вне навигационного меша.

    [​IMG]
    (Навигационный меш)

    Spawn Points (Точки спауна)

    Как уже отмечалось ранее, все точки спауна должны быть размещены поверх навигационного меша (ID 2) и внутри мягких (soft) границ. Помните, что некоторые сборные конструкции (например, стулья и скамейки) даются с уже прикрепленными к ним точками спауна. Если точки спауна несовместимы с деревенской миссией, они, скорее всего, приведут к сбою игры или вызовут ошибки. Одним из примеров является “sp_blacksmith_with_smithing_machine”. Самое главное в точках спауна - это их метки (tags). Они решают, какой тип NPC будет там появляться. Ради вашего же блага, не играйте с этими тегами слишком много и оставляйте их такими, какие они есть уже в сборных конструкциях.

    [​IMG]
    Entry Points (Точки входа)

    Player Spawnpoint (Точка спауна игрока):
    • Prefab: sp_player.
    • Убедитесь, что она расположен в таком месте, откуда ее можно увидеть или, по крайней мере, есть четкий путь, ведущий к ней. Не ставьте ее слишком далеко.
    • Под точкой спауна должен находится навигационный меш.

    Battle Spawnpoints (Точки спауна в бою):
    • Prefab: sp_battle_set.
    • Убедитесь, что точки спауна атакующих и защитников не слишком близко расположены друг к другу или, по крайней мере, не в пределах прямой видимости.
    • Убедитесь, что точка спауна подкреплений убрана из поля зрения врага насколько это возможно, но при этом не слишком далеко от линии фронта.
    • Убедитесь, что вокруг всех точек спауна есть свободное пространство для правильного появления войск.

    Conversation Spawnpoints (civilian) (Точки спауна для беседующих гражданских персонажей):
    • Prefab: sp_player_conversation.
    • Эти точки спауна определяют, где игрок и его собеседник появляются, когда вы попадаете в деревню через кнопку “Talk to Notable” ("Поговорить со старостой") с карты мира.
    • Убедитесь, что с них открывается красивый вид, но делайте их относительно близко к центру деревни.

    Animation Points (civilian) (Анимационные точки для гражданских персонажей):
    • Prefab: sp_npc_x.
    • Они используются обычными сельскими жителями. Вы можете использовать до 40 позиций.Они определяют точки спауна в сценах, где жители деревни будут появляться и ходить.
    • Убедитесь, что они удобно расположены по всей деревне и в окрестностях.
    • Сначала сельчане будут думать, каким путем идти.
    • Если тропинки слишком длинные, вы можете обнаружить, что ваши жители все время думают куда им идти, а на самом деле никто ничего не делает. Старайтесь избегать больших расстояний и ставьте точки спауна рядом с основными путями.
    • Размещение большего или меньшего количества точек спауна не влияет на то, сколько жителей будет населять эту сцену.

    Rural Noteable Spawnpoints (Точки спауна старост):
    • Prefab: sp_notable_x.
    • Количество таких точек должно быть около 6.
    • Это точки спауна для старост (дающих задания) и лордов.
    • Убедитесь, что они находятся в деревне на видном месте и, как правило, в местах, где будут болтаться старосты/лорды.
    • Вы можете проверить это в Debug Window (окно отладки) (это будет в документации), чтобы убедиться, что вы правильно разместили эти точки.
    • Перейдите на вкладку “Scene Entity Check Tab” (“Проверка объектов сцены”), поставьте галочку в поле “NPCs” и посмотрите.

    Bandit Camps (Лагеря бандитов):
    • Prefab: common_area_x.
    • Каждая деревенская сцена имеет 3 бандитских лагеря за пределами деревни, используемых для сюжетных квестов.
    • Используйте те же точки спауна, что и для обычных жителей деревни (~15 на лагерь). Постарайтесь, чтобы они не занимались такими делами, как сельское хозяйство.
    • Вы также можете использовать точки спауна патрулей: sp_guard_patrol_simple, sp_guard_patrol.
    • Все точки спауна в этом радиусе будут порождать бандитов вместо жителей деревни.
    • Вы можете увеличить радиус, масштабируя prefab общей области.
    • Используйте ранее рассмотренные Animation Points в качестве точек спауна бандитов, например: sp_npc_wait_wall, lookout, sp_npc_argue_set, sp_npc_wait.
    • Убедитесь, что есть какое-то подсказки на то, где лагеря могут быть, чтобы у игрока был шанс найти их (особенно ночью).
    • Не ставьте их слишком близко друг к другу.

    [​IMG]
    (Bandit Camps)

    Animal Spawnpoints (Точки спауна животных):
    • Prefab: sp_animalName.
    • Используйте“DisableWandering” (“Отключить блуждание”) в скрипте AnimalSpawnSettings, чтобы животные не ходили по вашей сцене.
    • В целом лучше поставить его для всех больших животных, таких как коровы и свиньи.

    Tactical Region (Тактические регионы)
    • Prefab: TacticalRegion.
    • Используется, чтобы сообщить AI, где находятся более крупные регионы (леса, холмы и т.д.).
    • AI будет позиционировать себя внутри этого радиуса или избегать его.
    • Не злоупотребляйте им, придерживайтесь ~5 (убедитесь, что есть некоторое разнообразие).

    Tactical Positions (Тактические позиции)
    • Prefab: TacticalPosition.
    • Используется, чтобы сообщить AI, где есть соответствующие более мелкие позиции (например, узкие проходы между зданиями, скалы для лучников и так далее).
    • AI будет планировать свое поведение в соответствии с поворотом Prefab и шириной, заданной сценарием.
    • Вы можете использовать их довольно часто.
    • Чем больше уклон, тем “лучше” положение.

    [​IMG]
    (TacticalPosition)

    Flee Positions (Позиции для отступления):
    • Позиции, к которым будут отступать бегущие войска, а также кони без всадников.
    • Убедитесь, что они находятся внутри Soft Border и что под ними есть navmesh (навигационный меш).

    [​IMG]
    (Flee Positions)

    Debug Window (Окно отладки):
    • Prefab: SpawnPointDebugView.
    • Существует встроенный инструмент отладки, который можно включить, добавив вышеупомянутый prefab к сцене. Поместите prefab в любом месте сцены и активируйте окно с помощью флажка в его скрипте.
    • Этот prefab открывает небольшое окно отладки в редакторе, которое помогает вам убедиться, что вы соответствуете требованиям для миссии (например, точки спауна, navmesh).
    • На вкладке “Scene Entity Check Tab” (“Проверка объекта сцены”) вы можете подсчитать свои Entry Points (точки входа) и убедиться, что вы разместили достаточное их количество (или же слишком много).
    • На вкладке “Navigation Mesh Check Tab” (“Проверка навигационного меша”) вы можете убедиться, что все ваши точки входа правильно подключены к навигационному мешу.

    [​IMG]
    (Debug Window)

    Soft Border (Мягкая Граница):
    • Prefab: border_soft.
    • Они определяют красные границы сцены.
    • При размещении они образуют многоугольник, где 2 ребра соединяются между ближайшими двумя пограничными объектами (но никогда не более двух).
    • Чтобы проверить текущие границы, перейдите в “Visibility Window” (“окно видимости”) → “Visibility Masks” (“маски видимости”) и включите “Borders” (“границы”).
    • После их пересечения у игрока есть несколько секунд, чтобы вернуться обратно в границы карты. Этим нельзя злоупотреблять.

    [​IMG]
    (Borders)

    Sounds (Звуки):
    Master Ambient Sound (Основные звуки окружающей среды):
    • Prefab: x_ambient_sound.
    • Обязательно выберите основной звуковой фон (master ambient sound).
    • Вы можете разместить его prefab в любом месте.
    • Убедитесь, что у него включен параметр “Is Master Sound”.
    • Убедитесь, что на нем не включен параметр “Is Triggered”.

    Additional Ambient sounds (Дополнительные звуки окружающей среды):
    • Применяется для больших площадей (например, лесов).
    • Должен быть включен параметр “Is Triggered”.
    • Чтобы увидеть, как далеко эти звуки распространяются, в окне “Visibility Window” (“видимость”) включите “Sound Entities” (“звуковые объекты”) в группе “Visibility Masks” (“маски видимости“).
    • Чтобы изменить территорию их охвата, вы можете масштабировать их, как и другие объекты редактора (используя клавишу “b” или gizmo (???)).

    [​IMG]
    (Sounds)

    Reverb (Реверберация):
    • Для каждого варианта использования существуют разный prefab: reverb_x.
    • Добавляет эффект реверберации к любому звуку, порожденному внутри его границы.
    • Обычно они используются для тесных или подземных участков местности.
    • Вы можете разместить их в узких переулках между высокими зданиями, скалами, в пещерах или в густых лесах.
    • Должен быть включен параметр “Is Triggered”.

    Detail (Деталь):
    • Используется для мелких деталей.
    • Убедитесь, что параметр “Is Triggered” отключен.
    • Поместите их prefab туда, где вы хотите, чтобы они играли.

    Moving sounds on paths (for rivers and such): Звуки движения на дорогах (для рек и тому подобного)
    Иногда полезно перемещать звуки вдоль всей береговой линии или на самой реке. Приведенная ниже техника более удобна для работы и более точна, чем, например, размещение нескольких звуковых объектов вдоль вашей реки.

    • Проложите траекторию движения прямо по реке. Дополнительные сведения см. В разделе Path Editing (Редактирование пути).
    • Добавьте звук в сцену.
    • Разместите любой дополнительный звук окружающей среды, как описано выше.
    • Добавьте скрипт path_converger в объект вашего звука окружающей среды.
    • Введите имя вашего пути к “path_converger”.
    • Теперь звук будет следовать по траектории движения в соответствии с положением камеры.
    Sounds in the Engine (Звуки в движке):
    Вы можете проверить файл "MODDING_TOOLS_DIRECTORY/Sounds/GUIDs.txt" для просмотра списка звуков в игре. Эти имена могут быть использованы в скрипте звуковых объектов.

    Lights (Огни):

    • Используйте хотя бы один envmap_prop в вашей сцене.
    • Для более темных областей, таких как пещеры, используйте пропсы local_envmap_prop.
    • Он будет влиять на освещение в данной области в зависимости от значений его скрипта “ReflectionCapturer” (“Захват отражения”).
    • Убедитесь, что деревни и бандитские лагеря хорошо освещены.
    • Будьте особенно внимательны в conversation points (Точки спауна для беседующих персонажей).
    • Используйте факелы и другие предметы.
    • Убедитесь, что факелы внутри зданий и других темных областей имеют включенный параметр “alwaysBurn” (“всегда гореть”) в скрипте LightCycle (Световой Цикл).
    • Старайтесь избегать размещения “artificial lights” (“искусственного освещения”) без модели фактического источника.
    • Вы можете сделать окружающее освещение в вашей сцене с помощью системы GI. Это сделает окружающее освещение гораздо более реалистичным. Для получения дополнительной информации см. GI System.

    [​IMG]
    (Lights)

    Atmosphere (Атмосфера)

    • Убедитесь, что ваша сцена работает и хорошо смотрится со всеми атмосферами TOD_x и во все времена года! (поскольку она будет протестирована с ними).
    • Выберите “Color Grade” (“класс цвета”), который подходит для вашей сцены (мы предлагаем использовать те, для которых предназначена ваша сцена, например: “color_grade_empire_soft”).

    [​IMG]
    (Atmosphere)
     
    Последнее редактирование: 7 ноя 2020
    Doder нравится это.
  4. Дима Гончар

    Дима Гончар Главный администратор Команда форума

    Источник перевода -https://rusmnb.ru/index.php?action=article;topic=23487.0

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

    Characteristics (Характеристики)

    Это ScriptComponent (компонент сценария), который может быть применен к любому объекту в сцене, если этот объект имеет collision body (коллизии).

    Если не дать никакой дополнительной информации, script (сценарий) просто заставит объект исчезнуть после уничтожения. Он также появится снова, когда миссия будет окончена.

    Скрипт может быть использован для уничтожения объектов в одном или более состояниях, с дополнительным звуком, частицами и динамическими объектами, появляющимися в каждом состоянии.

    Любой существующий prefab (префаб) скрипта DestructibleComponent (осадные башни, ворота, баллисты и т.п.) будет продолжать работать, даже если вы удалите этот скрипт. Только их больше нельзя будет разрушить.

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

    Разрушенные префабы всегда можно настроить и улучшить позже, не нарушая каких-либо сцен, потому что они не являются частью неповрежденного объекта (они создаются во время выполнения).

    Example Script of Siege Tower (Пример скрипта осадной башни)

    [​IMG]
    (Script Overview (Обзор скрипта))

    DestructionStates (Состояние разрушения) могут быть одним или несколькими префабами. Разделены «,» (запятой).

    DestroyedByStoneOnly (Разрушаем только камнями). Выставленное значение True (верно) означает, что только снаряды из мангонелей или требушетов могут повредить этот объект. Значение False (Ложь) означает, что этому объекту может повредить что угодно.

    CanBeDestroyedInititally (Может быть уничтожен изначально), определяет, может ли этот объект быть уничтожен уже при загрузке сцены. Это контролируется с карты кампании на основе процента разрушений от бомбардировок. Обычно это верно только для настенных зубцов. Но его также можно использовать для эстетических объектов, чтобы сцена выглядела более разрушенной с самого начала. Объекты, подлежащие уничтожению, выбираются случайным образом.

    MaxHitPoint (Максимальное здоровье) - это начальные очки жизни этого объекта. Каждый раз, когда миссия перезагружается, текущее количество жизни объекта также будет сброшено на максимальное количество хитпоинтов.

    ReferenceEntityTag (Справочный тег объекта) - это необязательный тег, когда префаб DestructionState имеет положение (frame), отличное от его родительского, или для копирования состояний анимации. Вы можете добавить дополнительный объект (с помощью скрипта DestructibleComponent) с правильным положением и снабдить его справочным тегом, чтобы возникший префаб DestructionState использовал это положение. Если ReferenceEntity отсутствует, то будет использоваться положение объекта со скриптом DestructibleComponent. Справочный объект (ReferenceEntity) также может быть использован в специальных скриптах, таких как castlegate (анимация открытия/закрытия), чтобы получить состояние анимации от справочного объекта (ReferenceEntity) и применить его к вновь созданному поврежденному объекту.

    OriginalStateTag (Тэг исходного состояния) требуется только в том случае, если у вас есть несколько DestructionStates. Обычно, когда объект уничтожается, мы скрываем этот объект, к которому применен компонент скрипта, и порождаем новый объект из состояния DestructionState (без родителя). Но для некоторых объектов (таких как ворота) мы не хотим скрывать весь объект целиком, потому что он должен продолжать функционировать как ворота, пока не будет полностью разрушен. Используя OriginalStateTag, мы скроем только тот объект, к которому применен этот тег, а остальная часть иерархической структуры (частицы, точки опоры и т.д.) все равно будет видна. Любой DestructibleComponent, имеющий более одного destructionState, будет порождать поврежденные префабы как дочерние объекты.

    HeavyHitParticlesTag (Тэг тяжело пораженных частиц) - это тег, который можно применить к любым дочерним объектам, имеющим систему частиц (particle-system). Эти частицы взорвутся один раз, когда определенное количество урона будет получено за один удар. Эта система частиц обычно используется во всех состояниях разрушения (она не является частью скрытых / порождаемых объектов).

    HeavyHitParticlesThreshold (Предельное значение частиц сильного удара) - минимальный урон, который требуется получить за один удар, чтобы вызвать триггер взрыва (trigger particles) с тегом HeavyHitParticlesTag.

    Effects (Эффекты)

    Как правило, мы стараемся, чтобы спауна префабов было как можно меньше из соображений производительности, а также во избежание дублирования объектов. У вас есть доступ к следующим функциям для добавления эффектов :

    • При спауне префаба повреждения: все системы частиц на каждом объекте в иерархии будут автоматически взорваны один раз.
    • При спауне префаба повреждения: все динамические тела на каждом объекте в иерархии автоматически получат импульс от последнего удара, который разрушил предыдущее состояние.
    • При спауне префаба повреждения: все остальные меши на каждом объекте в иерархии останутся на своих местах, если у них нет флажка, что это динамическое тело (dynamic body-flag).
    • Часть иерархии объектов: частицы сильного удара должны быть разделены между всеми состояниями разрушения и воспроизводятся всякий раз, когда DestructibleComponent получает урон HeavyHitParticlesThreshold.
    • Вы можете воспроизводить свои анимации на компонентах DestructibleComponents, у которых есть скелет (например, ворота замка поврежденные тараном). Прогресс анимации будет передаваться вновь созданным поврежденным объектам.
    • Вы можете добавить сценарий типа AmbientSoundEmitter в префаб повреждения и получить звуковое сопровождение. Оно будет автоматически воспроизводиться при спауне объекта.
    • Помимо использования нескольких состояний, вы также можете добавить несколько дочерних объектов с помощью DestructibleComponents (например, крыши тарана, которую можно разрушить по отдельности). Имейте в виду, что любое повреждение, наносимое дочернему элементу DestructibleComponent, также применяется ко всем родительским элементам в иерархии. В настоящее время мы не знаем, как их большое количество в сцене влияет на производительность.
    Tip (Совет):
    При любом ударе оружием уже будут воспроизводиться стандартные эффекты частиц и звуки ударов в зависимости от типа материала (дерево, камень и т.д.), Так что не сходите с ума с дополнительными эффектами.

    Warning (Предупреждение):
    Любой динамический меш, летающий в воздухе после спауна поврежденного объекта, является временным и не должен иметь физического контакта с игроком! Он не должен влиять на игровой процесс, потому что мы не синхронизируем его для игроков в многопользовательской игре.

    Examples (Примеры)

    Пример 1: Стена с разрушающимися зубцами:
    Что касается стен, то мы можем уничтожить только ее зубцы и ничего больше. Они могут быть повреждены только мангонелями/требушетами, и они получают только один удар, прежде чем будут уничтожены.

    Hierarchy of WallSegment (Иерархия сегмента стены):
    [​IMG]
    (Wall Hierarchy Edited (Отредактированная иерархия стен))

    Вот как выглядит наша иерархия сцен для одной стены. European_castle_wall_a_l3 - это объект со скриптом WallSegment. Ему все равно, есть у него разрушаемые дети\подобъекты или нет. Каждый зубец стены - это отдельный дочерний объект, который имеет свой собственный скрипт DestructibleComponent. Как только они будут уничтожены, все они породят один и тот же префаб разрушения. Каждый зубец имеет объект debris_holder, который является пустым объектом. Он просто содержит тег ReferenceEntityTag и правильный кадр для создания префаба разрушения (важно из-за изгиба мешей: местоположение и вращение могут измениться по сравнению с родительским).

    Script example of a single merlon (Пример скрипта одиночного мерлона\зубца):
    [​IMG]
    (Wall Script (Скрипт стены))

    У каждого мерлона есть точно такой же скрипт. Все они будут порождать префаб “мусора” (“debris” prefab), когда будут уничтожены. Мы решили заставить их уничтожаться после одного попадания из мангонеля, поэтому у них очень маленькие очки жизни (hitpoints). DestroyedByStoneOnly заставляет их игнорировать урон от всех других видов оружия (стрелы, мечи, топоры и т. д.). Из-за CanBeDestroyedInititally эти мерлоны имеют шанс уже быть сломанными при входе в играемую миссию. Мерлоны нуждаются в объекте ReferenceEntity, чтобы определить положение спавна для сломанных префабов.

    Origin of wall and merlon pieces (Создание частей стены и мерлонов):
    [​IMG][​IMG]
    Каждый мерлон представляет собой уникальный меш, который имеет свою исходную точку в нижней части стены (так же, как и вся стена).

    [​IMG][​IMG]
    Каждый мерлон имеет один и тот же разрушенный префаб местного происхождения. debris_holder имеет ReferenceEntityTag.


    [​IMG][​IMG]
    Каждый дочерний элемент префаба мусора (debris) является объектом с флагом «dynamic» и имеет коллизию. При спауне он автоматически получит последний импульс, который получил DestructibleComponent при уничтожении.

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

    The different destruction states of a siege barricade (Различные состояния разрушения осадной баррикады):

    [​IMG]

    В настоящее время эти различные состояния не имеют никаких особых частиц или динамических объектов, но они могут быть легко добавлены позже. Объекты с флагом “dynamic” body (“динамического” тела) и системы частиц будут автоматически запускать триггер при спауне.

    Tip (Совет):
    У каждого этапа разрушенной баррикады также есть свое уникальная коллизия. Это позволяет людям легче пускать стрелы через более поздние разрушения, а также перелезать через state_5.

    Hierarchy of siege barricade in scene (Иерархия осадной баррикады в сцене):
    [​IMG]

    Siege Barricade script component (Компонент скрипта осадной баррикады):
    [​IMG]

    siege_barricade_a - это пустой меш. Он просто содержит скрипт siege_barricade_a_state1 - это фактический меш + тело и имеет тег “original_state”. Когда баррикада получит достаточный урон, siege_barricade_a_state1 станет невидимым, следующий префаб повреждения будет порожден и добавлен в siege_barricade_a как дочерний. Это важно, потому что DestructibleComponent должен быть проинформирован о попаданиях, и он может сделать это только в том случае, если у него есть (видимая) коллизия на себе или на дочернем объекте.

    Последнее состояние (state_5 в данном случае) будет порождено, когда объект будет иметь 0 здоровья (т.е. полностью уничтожен). Остальные состояния будут использоваться между MaxHitPoints и 0.

    Когда миссия перезагружается (здоровье сбрасывается до MaxHitPoint), исходный объект (объект с тегом «original_state») снова становится видимым.

    Каждый префаб DestructionState имеет одинаковые координаты и разворот, поэтому нам не нужно использовать ReferenceEntity.
     
    Последнее редактирование: 7 ноя 2020
    Doder нравится это.
  5. Дима Гончар

    Дима Гончар Главный администратор Команда форума

    Источник перевода -https://rusmnb.ru/index.php?action=article;topic=23488.0

    Barrier Builder - это инструмент, который помогает сценоделу создавать невидимые барьеры над стенами, чтобы предотвратить падение персонажей.

    Usage (Инструкция по применению)

    • Создать путь можно с помощью кнопки Add Path на панели инструментов:
    [​IMG]


    • Задайте имя пути:
    [​IMG]


    • Постройте свой путь так, как вы хотите:
    [​IMG]


    • Установите флажок “Enable Barrier Build” на панели inspector, он создаст для вас объект барьера:
    [​IMG]


    • Вы можете перейти к этому объекту с помощью кнопки “Go to Entity” (“Перейти к объекту”) и изменить его параметр, такой как высота (height). Объект задать с именем “path_barrier_PATHNAME”:
    [​IMG]
     
    Последнее редактирование: 7 ноя 2020
    Doder нравится это.
  6. Дима Гончар

    Дима Гончар Главный администратор Команда форума

    Источник перевода - https://rusmnb.ru/index.php?action=article;topic=23489.0

    Каждая сцена имеет свои основные необходимые параметры, чтобы работать без сбоев, и имеет дополнительные возможности, чтобы дать лучший опыт игроку. Сценоделы могут проверить эти потребности с помощью “Spawn Point Debug Tool”, чтобы быть уверенными, что их сцена не рухнет.

    1. Town Center Scene (Сцена в центре города)

    Игрок будет спаунится на префабе «sp_player_outside», если он / она входит в город впервые.
    Из-за этой функции префаб “sp_player_outside” необходимо размещать далеко от входа в город.
    В противном случае игрок будет появляться на “sp_player”, и эта точка спауна может быть рядом с входными воротами.
    Сцена в центре города имеет следующие обязательные персонажи :

    Player Spawn Point (Точка спауна игрока):
    Когда игрок входит в центр города из верхней правой панели в сцене карты, игрок и разговаривающие с ним NPC появляются в префабе “sp_player_conversation”.
    Сцена должна иметь этих префабов больше одного для увеличения вариантов мест появления.
    Предупреждение: Масштаб префаба разговора не должен меняться.

    Traders (Торговцы):
    Торговцы, такие как оружейники, кузнецы и торговцы лошадьми, обязательны для сцен в центре города. Если сцена имеет более одного рыночного места, то вполне нормально иметь более одного NPC-торговца. Торговцы на рынках могут иметь свои собственные комплекты префабов. Эти комплекты можно рассматривать как набор префабов с некоторыми точками спауна в них. Например, для оружейника в комплекте оружейника может быть 3 таких точки, но единовременно должна быть только одна точка спауна этого оружейника [что бы не двоился\троился один и тот же персонаж в данный момент времени]. Этот NPC будет обходить эти точки случайным образом, одним словом, NPC может пойти к своему торговому столу и начать торговать или пойти в заднюю часть своего магазина и посидеть на стуле в течение некоторого времени.

    Совет: Дизайнер может изменить время ожидания между этими действиями с параметрами “MinWaitInSeconds” и “MaxWaitInSeconds” (-1: forever).

    Notable Parent Prefab (Префабы нотаблей):
    В сцене должны присутствовать некоторые старосты. Чтобы их было легко найти, точки спауна старост должны быть размещены недалеко от центра города. У каждого старосты есть свой собственный тег точки спауна, и свои уникальные помощники (helper characters).

    [​IMG]

    У всех старост есть один родительский префаб с именем “sp_notables_parent” (, где parent - родитель). У каждого старосты есть 1 дочерний комплект, так что родительский префаб имеет 5 дочерних комплектов.

    Сценоделы должны разместить этот родительский префаб на видном месте в центре города. Кроме того, префаб должен быть легко виден игроку. После начала миссии логика игры активирует комплект старост (notable set) в соответствии с старостами, стоящими в центре города.

    В комплектах старост каждый староста будет иметь уникального персонажа-помощника и его точку спауна. (телохранители для главаря банды, нотариус для торговца…).

    На скриншоте ниже. В сцене имеется 2 родительских префаба (parent prefab). После начала миссии активируется один префаб для главаря банды и его телохранителей. Другой префаб активируется для торговца и его нотариуса.

    Совет: В каждом населенном пункте может быть не более 6, а в каждой деревне не более 3-х старост. Таким образом, сценодел должен учесть это и разместить не менее 8 родительских префабов для сцен в центре города и разместить не менее 5 родительских префабов для деревенских сцен. А также в центре города есть 3 мастерских. У каждой мастерской должен быть 1 родительский префаб. Итак, для сцен в центре города необходимо добавить 8 + 3 (из мастерских) ~ 10 родительских префабов.

    Предупреждение: Все точки в комплектах старост имеют повороты в соответствии с их анимацией захвата движения, поэтому не поворачивайте точки, иначе анимация не будет синхронизироваться.

    [​IMG]

    Guards (Стража):
    Есть несколько праздно стоящих охранников и несколько патрулирующих. Патрулирующие охранники запрограммированы на перемещение из одной точки в другую, активируя следующую точку и деактивируя текущую.

    Passages (Переходы):
    Сцена центра города должна включать в себя все переходы к другим сценам, таким как таверна, арена, тронный зал…

    Battle Sets (Боевые отряды):
    В городских сценах боевые отряды используются только для зачистки пустыря. Поэтому они не должны располагаться слишком далеко друг от друга и должны быть расположены так, чтобы представлять битву между бандами, а не битву между целыми армиями.

    Townsfolk (Горожане):
    NPC постоянно перемещаются по городу. Чтобы разнообразить сцену, сценодел может захотеть использовать дополнительные префабы. Например, если в сцене есть “sp_npc_repair_set” (, где repair - ремонт), один NPC подойдет к этой точке и начнет стучать молотком, в то время как другой NPC будет жаловаться другу на ситуацию или в сцене могут быть нищие, просящие помощи у горожан.

    2. Tavern Scene (Сцена в таверне):

    Player Spawn Point (Точка спауна игрока):
    Точка спауна игрока, “sp_player”, должна быть расположена рядом с проходом в центре города. Сцена должна включать в себя по крайней мере один префаб “sp_player_conversation” или более.

    Предупреждение: Масштаб (scale) префаба беседы не должен меняться.

    Game Host (азартный игрок)
    В каждой сцене таверны должен быть NPC-азартный игрок, предлагающий сыграть. Стул под таким NPC должен иметь теги “gambler_npc” и “npc_wait”. Стул, на который ГГ сядет, что бы присоединиться к игре, должен иметь теги “gambler_player” и “reserved”.

    3. Lords Hall Scene (Сцена тронного зала)

    Player Spawn Point (Точка спауна игрока):
    Точка спауна игрока для сцены тронного зала такая же, как и для сцены в таверне. Точка спауна игрока должна быть размещена рядом с переходом в центр города.

    4. Village Scene (Деревенская сцена)

    Player Spawn Point (Точка спауна игрока):
    Деревенская сцена не имеет префаба “sp_player_outside”. Префаб “sp_player” нельзя размещать далеко от центра деревни и, в тоже время, очень близко. При спауне игрок должен издалека видеть идущих жителей деревни. Когда игрок входит в деревню через верхнюю правую панель сцены карты (меню деревни), игрок и говорящие с ним NPC будут созданы в префабе “sp_player_conversation”. Сцена должна иметь эти префабы более одного, чтобы увеличить вырианты места появления игрока.

    Предупреждение: Масштаб (scale) префаба беседы не должен меняться.

    Notables (Старосты):
    В сцене должны присутствовать старосты. Чтобы их было легко найти, точки спауна должны быть размещены недалеко от центра деревни.

    Villagers (Жители деревни):
    У жителей деревни есть много дополнительных занятий в центре деревни, таких как сбор винограда, ремонт чего-то или уход за лошадью. Активность их должна быть сбалансирована между физической и социальной деятельностью. Сельский NPC может пойти и очистить стены, а затем сесть и поболтать с другими крестьянами.

    Common areas (Пустыри):
    В каждой деревне есть 3 пустыря, которые не находятся в центре села. Внутри пустыря можно использовать любой тип точек спауна. Префабы "common_area_NUMBER” должны быть размещены для указания области. К этим префабам прилагается скрипт с именем “CommonAreaScript”. У этого скрипта следующие параметры:

    AreaRadius (Радиус пустыря): Сценодел может изменить этот параметр скрипта, чтобы увеличить или уменьшить пустырь.
    AreaIndex (Индекс пустыря): Уже установлен в префабах для трех пустырей.
    Type (Тип): Тип области должен быть установлен из таблицы ниже:

    [​IMG]

    Battle Spawnpoints (Точки спауна в бою):
    Если игра открывает сцену в боевым режиме, будут инициированы Battle sets (боевые отряды), и на каждом появятся войска. Боевые отряды необходимо размещать далеко друг от друга и с учетом размера обороняющейся и атакующей сторон.
     
    Последнее редактирование: 7 ноя 2020
    Doder нравится это.
  7. Дима Гончар

    Дима Гончар Главный администратор Команда форума

    Источник перевода - https://rusmnb.ru/index.php?action=article;topic=23490.0

    Constructor (Конструктор):
    В конструкторе необходимо присвоить значения по умолчанию его общедоступным переменным (переменным, которые могут быть изменены создателем сцены). В конструкторе компонент скрипта (script component) не назначается ни объекту, ни сцене. Кроме того, вы не должны писать какую-либо логику, которая имеет побочный эффект, потому что, даже если он создан, компонент скрипта может быть удален после открытия сцены из-за обновления системы уровней (level system).

    On Pre Init (При предварительной инициализации):
    Это вызывается после того, как компонент скрипта назначается его объекту-владельцу в сцене. Как только вы перейдете в этот колбэк, вы можете быть уверены,что определенные пользователем переменные из этого экземпляра скрипта установлены. Однако другие компоненты скриптов других объектов могут быть еще не назначены. Таким образом, в предварительной инициализации не должно быть никакого логического кода, который полагается на другие компоненты скрипта. Например, в pre-init ManagedObject регистрируется в массиве управляемых объектов в текущем экземпляре миссии.

    On Init (При инициализации):
    Это вызывается после загрузки миссии и инициализации всех скриптовых компонентов объектов. Вы можете использовать любой тип логического кода внутри этого колбэка. Скрипты, созданные во время выполнения, также получают этот колбэк.

    On Editor Init (При инициализации редактора):
    Редактированная версия на инициализации. Вызывается при загрузке сцены из редактора. Помните, что в редакторе нет ни миссии, ни игрового состояния.

    On Tick (Пометка):
    Это вызывается для каждого компонента скрипта в каждом кадре миссии из одного и того же потока.

    On Editor Tick (При редактировании отметки):
    Редактируемая версия помечена.

    Is Only Visual (Только визуально):
    Если у вас есть компонент скрипта , который является только визуальным и не имеет никакого логического кода, который должен быть запущен на выделенном сервере, вы должны включить галочку true в этой функции. Это гарантирует, что этот тип скриптов не будет выполняться на выделенном сервере.

    On Editor Variable Changed (При изменении переменной редактора):
    Это вызывается в редакторе всякий раз, когда пользователь изменяет общедоступную переменную в этом компоненте скрипта. Этот обратный вызов может использоваться для любого изменения состояния визуальной логики, если сценоделу нужна мгновенная обратная связь в редакторе сцен.

    OnRemoved (При удалении):
    Вызывается при удалении объекта или компонента скрипта. Если у вас есть какие-либо выделенные объекты, которые хранятся где-то еще (например, статические контейнеры (static containers)), вы можете использовать этот колбэк, чтобы убедиться, что они не проникли в сцену.
     
    Последнее редактирование: 7 ноя 2020
    Doder нравится это.
  8. Дима Гончар

    Дима Гончар Главный администратор Команда форума

    Источник перевода - https://rusmnb.ru/index.php?action=article;topic=23491.0

    Вступление
    Инструмент, который имеет префаб с именем “SpawnPointDebugView”, может быть добавлен в сцену. Prefab имеет прикрепленный скрипт “SpawnPointDebugView”, и этот инструмент можно открыть с помощью inspector toggle (переключатель инспектора). Инструмент имеет 3 вкладки: “Scene basic information tab”, “Scene entity check tab” и “Navigation mesh check tab”.

    [​IMG]

    1. Scene Basic Information Tab (Вкладка "Основная информация о сцене")
    Эта вкладка пытается определить тип сцены, чтобы найти необходимые элементы; если обнаруженный тип неверен, сценодел может переопределить тип с помощью кнопок переключения ниже.

    2. Scene Entity Check Tab (Вкладка "Проверка объектов сцены")
    Эта вкладка рассчитывает количество точек спауна и предупреждает художника, если их количество не входит в критерии сцены. Щелчок по кнопке “Count Entities”(“Подсчитать объекты”) и переключение категорий заполнит таблицу вычислений.. Переключатель “DONT USE”(“НЕ ИСПОЛЬЗОВАТЬ”) обозначит устаревшие объекты, которые сцена не должна включать. Последний столбец таблицы показывает, сколько агентов будет создано в текущих точках спауна.

    [​IMG]

    В конце каждой строки есть кнопка, которая может перечислить все игровые префабы с тегом нажатой кнопки. При нажатии на кнопку откроется новое окно со списком всех префабов с этим определенным тегом.

    [​IMG]

    [​IMG]

    3. Navigation Mesh Check Tab (Вкладка "Проверка навигационных мешей")
    Этот инструмент будет отмечать точки спауна, которые не находятся на навигационном меше или на навигационном меше, который будут отключен ‘Navigation Mesh Deactivator’(‘Деактиватором навигационного меша’). Если в сцене нет ‘Navigation Mesh Deactivator’, идентификатор деактивации будет равен 0, а вкладка проверки объекта сцены будет предупреждать сценодела о необходимости его размещения в сцене.
    Нажатие кнопки “CHECK” (“Проверить”) и переключение категорий покажет отладочные линии на недопустимых точках спавна с цветом категории. Инструмент проверки навигационных мешей показывает точки спауна в соответствии с уровнем сцены. Каждый переключатель активирует 2 кнопки с именами “Previous” (“предыдущий”) и “Next” (“следующий”). Нажатие этих кнопок заставит камеру редактора фокусироваться на неуместных точках спавна одну за другой.

    [​IMG]

    Эта вкладка также может проверять точки, которые не привязаны к миссии, но эта функция работает только в миссиях.

    Совет: Чтобы проверить точки, выходящие за пределы миссии, инструмент может быть активирован в миссии, если в текущей сцене есть префаб инструмента “SpawnPointDebugView” , вызываемый консольной командой “debug.mission_spawnpoint_count_and_mesh_checker_ui”.

    Предупреждение: Если вы видите несколько кнопок вкладок, значит в сцене более одного префаба “SpawnPointDebugView”. Удалите их.
     
    Последнее редактирование: 7 ноя 2020
    Doder нравится это.
Статус темы:
Закрыта.