Разделы

Новости
Об игре
Учебник
ЧаВо
Файлы
Галерея
Видео
Наши блоги
О сайте
Форум

Голосование

Моды для Bannerlord по вашему мнению - это...












Реклама




Пользователей
  • Всего: 27455
  • Последний: D071781
Сейчас на форуме
Пользователи: 6
Гостей: 250
Всего: 256

Реклама

Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Темы - Vanok

Страницы: [1] 2 3 ... 88
1

Коллектив разработчиков Last Oasis сообщил о скором прибытии второго сезона в свой проект. Этому событию оказалась посвященной довольно объемная запись в блоге игры в Steam. В первую очередь команда честно призналась в том, что изначально заложенные в игру идеи относительно поведения игроков попросту не заработали. "Ослики" сделали нужные выводы: основополагающими идеями по изменению сложившихся схем в игре стало изменение принципа спауна игроков на карте, значительно увеличение роли баз и исправление проблемы с монополией на таблички. Говоря о конкретных изменениях обновления, теперь стоит ожидать появления на картах множества крепких баз игроков, взламывать которые будет довольно сложным занятием (правда, взамен, за их содержание придется ежедневно платить ресурсами), упрощение создания ходунков и повышение наносимого им урона, появления возможность развивать технологии через торговлю, несколько новых видов построек, оружия и инструментов, расширение лимита клана до 50 человек, различные общие улучшения игры (например, более вместительные сундуки) и, наконец, повышения оптимизации игры.

Само собой, что все вышеописанное вызвало необходимость сделать полный вайп всех персонажей, а поэтому вернувшиеся в игру будут вынуждены начать прокачку заново. Кроме того, разработчики озвучили свои дальнейшие планы: в их задачи входит добавление различного контента, в том числе расширение PvE составляющей. Вернут ли эти действия интерес к проекту, пока что не ясно, но нельзя не отметить, что решения со стороны Donkey Crew наконец-то начали принимать правильную форму. Впрочем, других вариантов у команды и не было: в настоящий момент популярность игры скатилась до 500 человек в пике, что приводит к почти полному запустению шардов. Правда, такая ситуация не помешала команде анонсировать выход проекта на XBOX в первом квартале 2021 года, что вызвало удивление даже у самых оптимистичных фанатов проекта, ведь шансы на успех такого рода проекта на приставках довольно сомнителен, а затраченные на портирование ресурсы можно было пустить на еще более взвешенное развитие игры на PC.

2

Проект Blood of Steel нельзя назвать особо популярным среди сетевых проектов, но в своей нише его разработчики сумели достигнуть вполне достаточного уровня: не так давно игра смогла набрать 2000 одновременно играющих пользователей в пике, что очень даже неплохо для небольшой инди-команды. А поэтому, пока сохраняется живой интерес к проекту, коллектив YC Games продолжает активно развивать игру. Одним из важных событий стал запуск глобальной войны - нового масштабного режима. Суть действия, думаю, в целом понятна каждому, но я все же поясню детально: у нас имеются 2 фракции - крестоносцы и ханьцы, которые соперничают за обширные территории условного материка. Захватывая города, поселения и форпосты, а также выигрывая сражения, игроки усиливают выбранную фракцию, ну и само собой получают различные плюшки. Основная механика глобальной карты - это отряд. Каждый игрок может как создать свой отряд, так и вступить в другой, максимальное количество людей в отряде - 5 человек. Такие группы передвигаются по карте, совершая различные действий, причем в рамках сражения стоит учитывать такой параметр, как боевая мощь отряда. Хотя сами сражения происходят в почти неизменном виде, то есть в духе классической битвы легионов, боеспособность отряда влияет на выставляемые им войска, возможность подкреплений и т.п.

Но это далеко не единственное событие, которое можно встретить в игре. Так, например, в Greed of Guardian игроки должны в духе Full Invasion сдерживать орды ботов-противников, пытающихся добраться до отряда генерала. Цель режима простая: продержаться как можно дольше, уничтожая все более и более сложные волны. Единственный недостаток подобного рода мероприятий - это то, что попасть на них можно лишь в строго отведенное на это дни. Кроме того, нельзя забывать и про то, что команда поставила цель регулярно добавлять в игру новых персонажей. Так, относительно недавно в игру была введена Екатерина Великая с отрядом гусар. Довольно сомнительный с моей точки зрения выбор российского полководца, но решение в целом интересное.

4


[BL] cRPG II - Defend The Virgin

Официальный сайт: https://c-rpg.eu/
Автор файла: cRPG team

Defend The Virgin - это одиночная вариация грядущей реинкарнации одной из самых известных модификаций - cRPG. Нам предстоит нехитрое занятие: защищать невинную девушку от пребывающих орд противников. Каждая волна становится все более и более сложной, а поэтому рано или поздно ваш персонаж падет. Но с каждым пройденным этапом вы получаете деньги и опыт, которые в дальнейшем могут быть потрачены для улучшения главного героя и приобретения для него экипировки. И здесь в действие вступает главная фича cRPG: все манипуляции производятся через отдельный сайт, связывающий игру через аккаунт в Steam (версия из EGS не поддерживается) и позволяющая обмениваться данными на лету. Это предварительная версия будущего проекта, который будет ориентирован на сетевую игру, включая как PvE, так и PvP режим.

Мультиплеер пока что отсутствует в принципе.


5

Целый месяц ушел у турецкой команды Taleworlds на выпуск новой связки обновлений для Mount&Blade II: Bannerlord. Содержание патча 1.5.4, запущенного на стабильную ветку мы уже рассмотрели в прошлый раз - в ней нас ждут 5 новых сцен имперских деревень, новый набор мужских голосов, быстрый диалог с жителями поселений, доработанные линейки навыков метательного оружия, разбоя, тактики, разведки, стюарда и торговли, новые кланы и случайные квесты, а также ряд других исправлений. Подробнее по приведенной выше ссылке. Что касается 1.5.5, то его объем по части действительно заметных изменений примерно такой же: уменьшили частоту автосохранений и добавили надпись о произведенном "сэйве" (вполне возможно, это объяснит появившиеся несколько патчей назад подвисания игры при выхода из поселений), доработки некоторых сцен, для ряда оружия добавлен 20% штраф к скорости оружия при его использовании верхом, доработана система авторасчета сражений, легкие арбалеты теперь можно перезаряжать находясь верхом, добавлено еще 10 боевых перков в различные ветки, переработана ветка медицинских навыков, добавлена опция полного отключения рождения и смерти персонажей, введена функция хромых лошадей. По части сетевого режима было изменены параметры прицеливания у некоторого стрелкового оружия, введено несколько новых предметов экипировки и изменены параметры у ряда существующих, подправлены и замены перки у различных классов.

6
Автор: Дима Гончар

В RGL вы можете легко переопределить существующие ресурсы или создать новые в редакторе для вашего мода. Механизм переопределения работает путем замены существующих ресурсов на те, которые вы указали в каталоге ресурсов вашего модуля. Модуль сопоставляет ваши пользовательские ресурсы с теми, которые ранее были зарегистрированы другими модулями по их именам. Это происходит по порядку загрузки модулей.

Если Модуль A и Модуль B загружаются в дополнении к модулю Native, соответственно, список конечных ресурсов и их источников, будет следующим:



В настоящее время модифицируемые типы ресурсов это:
  • Материал
  • Меш
  • Текстура
  • Физическая форма

Иерархия папок


Система ресурсов обрабатывает некоторые папки в каталоге модуля специально в соответствии с их именами. Вот список этих папок и их значений:
  • Assets: Включает редактируемые файлы *.tpac, в которых хранятся метаданные каждого ресурса.
  • AssetSources: включает исходные файлы импортированных ресурсов (.psd, .fbx).
  • AssetPackages: включает файлы *.tpac только для чтения. Он генерируется, когда модуль упаковывается для клиентских сборок.
  • EmAssetPackages: включает файлы *.tpac только для чтения. Он генерируется, когда модуль упаковывается для сборки редактора.
  • DsAssetPackages: включает файлы *.tpac только для чтения. Генерируется, когда модуль упаковывается для сборки сервера.
  • RuntimeDataCache: включает автоматически сгенерированные данные, необходимые движку для каждого ресурса. Может быть удален, но при запуске может потребоваться время для создания с нуля.

Разрешения на модифицирование


Система ресурсов ищет разные папки в зависимости от версии исполняемого файла игры (game’s running executable). В зависимости от наличия этих папок система решает, можно ли изменить модуль или его можно использовать только в режиме чтения. Если вы хотите поделиться своим модулем, вы можете упаковать свои ресурсы и поделиться упакованными папками, не распространяя тысячи файлов и их источников. У вас есть три варианта упаковки ваших ресурсов:
  • Клиент: другие могут активировать ваш модуль для игры. Вы должны распространять папку AssetPackages.
  • Редактор: другие могут использовать ваш модуль в редакторе, но не могут его изменять. Используется, если вы хотите, чтобы другие извлекали модули из вашего модуля. Вы должны распространить папку EmAssetPackages.
  • Сервер: используется для сборки сервера. Все данные, не относящиеся к серверу, удаляются. Вы должны распространить папку DsAssetPackages.

Если вы хотите, чтобы другие люди смогли использовать ваш модуль, как и вы, с возможностью его изменения, вам нужно поделиться папками Assets, AssetSources и, возможно, RuntimeDataCache .

Переопределение материалов


Переопределение материалов может быть выполнено путем создания нового материала с тем же именем, что и материал, который вы хотите переопределить. Перейдите в каталог ресурсов вашего модуля и щелкните правой кнопкой мыши на empty place (пустое место) на панели браузера. Создайте новый материал и назовите его так же, как материал, который вы хотите переопределить.


Материал существующего меша, замещенный Модулем А

На этом этапе все ссылки на материалы в системе будут перенаправлены на ваш пользовательский материал.

Переопределение мешей


Модели можно импортировать из файлов нескольких форматов (например, Trf, Fbx). Ресурсы, импортированные из одного файла, группируются по их именам в соответствии с правилами именования ресурсов (asset naming convetions). Представьте себе файл fbx следующим образом:

    Model.fbx
        wall(Меш)
        wall.lod1(Меш)
        wall.lod3(Меш)
        bo_wall(Физическая форма)

Согласно условностям об именах ресурсов, первые три ресурса будут сгруппированы в один меш, в котором три субмеша имеют разные LOD`ы. В конце будут импортированы два ресурса из Model.fbx: wall (Меш) и bo_wall (Физическая форма).

Следуя этим правилам, вы можете экспортировать новый файл геометрии (например, fbx), который содержит группу мешей, имена которых начинаются на wall. В этом случае новый меш стены будет создан из этих субмешей, а существующий меш будет полностью заменен тем, который вы предоставили. Имя файла геометрии не учитывается. Стоит отметить, что переопределение меша происходит на уровне меша. Невозможно переопределить одиночный субмеш через переопределение модуля.


Существующий кубический меш с именем testbox переопределен Модулем А с помощью чайника.

Переопределение текстур


Переопределение текстур очень похоже на материалы. Вам необходимо импортировать новую текстуру с тем же именем, что и текстура, которую вы хотите переопределить. Вы также можете переименовать любую уже импортированную текстуру во что-то, что соответствует имени текстуры, которую нужно переопределить.


Существующая текстура альбедо с именем roman_ground_d переопределена Модулем А с белой текстурой

Переопределение физических форм


Для переопределения физических фигур необходимо импортировать физическую форму с тем же именем ресурса, который вы хотите заменить. Установите флажок Asset naming conventions (Правила наименования ресурсов), чтобы увидеть возможность импорта физических фигур.


Существующая форма тора заменена Модулем A с помощью специальной формы аквилы

7

Требования к производительности Mount & Blade Bannerlord


Одиночные сцены: очень высокая конфигурация/60 FPS/Gtx 1060.
Многопользовательские сцены: очень высокая конфигурация/60 FPS/Gtx 970.

Предупреждение: Не проверяйте окончательную производительность вашей сцены в редакторе сцен. Редактор имеет низкую производительность из-за того, что его можно редактировать во время выполнения. Также вам следует уточнить итоговую производительность у агентов в миссии.

Возможные "узкие места" в производительности


Отсутствующие окклюдеры
Окклюдеры - это физические объекты, которые определяют границы окклюзии для мешей. Если ограничивающая рамка (bounding box) объекта полностью закрыта окклюдером, эти объекты не отображаются. Окклюдеры значительно уменьшают проблемы с производительностью больших сцен. Во время выполнения (runtime) все окклюдеры рендерятся на другом экране, и значения глубины каждого пикселя на этом экране проверяются с помощью ограничивающей рамки каждого меша. В вашей сцене все строительные блоки и большие меши должны иметь окклюдеры. Если на вкладке «Visibility» (Видимость) включены параметры «Enable Occlusion Culling» (Включить отсеивание окклюзии) и «Show Occluders» (Показать окклюдеры), окклюдеры каждого меша визуализируются с помощью отладочных мешей. Если у какого-либо из больших мешей вашей сцены отсутствуют окклюдеры, вам следует связаться с командой ART.

Слишком много перерисовки точечного света и ненужные карты теней
Наш движок использует систему точечного освещения на основе сетки. Эта система делит экран на сетки фиксированного размера. Затем видимые точечные источники света регистрируются в каждой сетке, в которой пересекается ограничивающая рамка. Затем каждый затененный пиксель на экране использует все точечные источники света внутри своей плитки (tile) для затенения самого себя. Каждый точечный свет в вашей сцене должен иметь минимально возможный радиус. Кроме того, чтобы не увеличивать перерисовку, не следует использовать слишком много точечных источников света. Вы можете использовать средство отладки «Debug Tiled Lights», чтобы исправить такие проблемы, как слишком большое количество точечного света в узких местах или источники света с большим радиусом. Если есть какие-либо плитки сетки желтоватого или красного цвета, то они, вероятно, имеют низкую производительность. Эти области сцены следует отрегулировать, уменьшив либо радиусы точечного света, либо уменьшив количество точечного света.

Использование флоры во внешних областях
Трава, как флора, которую мы используем в наших сценах, имеет ограниченный диапазон обзора. Кроме того, мы можем отсеивать (не выполнять рендеринг) этой флоры в больших диапазонах. Тем не менее, эта флора будет иметь большое влияние на память в сценах, а также будет иметь небольшую стоимость отсеивания ЦП. Таким образом, для внешних областей, где трава не будет отображаться, вам не следует использовать слои ландшафта с высокой плотностью травы.

Слишком много мешей без LOD
Для современных графических процессоров с точки зрения производительности гораздо важнее плотность полигонов на пиксель, чем общее количество полигонов. В этом случае худшая ситуация - меши без LOD. Это можно проверить, переключившись в каркасный режим (wireframe mode). Каждый треугольник в сцене должен содержать достаточное количество пикселей внутри, а не наоборот. Вам следует связаться с командой ART, если вы найдете меш без LOD.

Множитель LOD ландшафта и плотность вершин
Всегда проверяйте плотность вершин вашего ландшафта. Во многих случаях разрешение местности можно уменьшить без каких-либо заметных изменений. Также старайтесь не использовать множитель LOD ландшафта для узлов ландшафта. Наличие большего количества узлов и использование только множителя LOD ландшафта в узлах с детальной кривизной повысит производительность вашей сцены.

8
Подробнее об игре | Видеоверсия

Большое спасибо Александру Суслову и Максиму Горбаню за активное участие в создание данной статьи.

История серии Mount&Blade как единой линейки игр имеет множество интересных деталей, облепивший турецкую игру с разных сторон. Основные направления, ответвления, борьба дополнений и модов за место под солнцем и другое. И одним из элементов этой истории является Огнем и Мечом - первое дополнение для Mount&Blade и по факту единственное официально значащееся как самостоятельная разработка сторонней студии. Можно сказать, это была проба пера: что если доверить создание самостоятельного проекта на базе оригинальной игры сторонним людям? На тот момент турки были полны амбиций, считая, что оглушительный успех их игры можно распространить и на смежные проекты - достаточно дать людям инструменты и информационную поддержку. Первой ласточкой на поприще такого формата работы стал именно Огнем и Мечом, созданный на территории СНГ благодаря стараниями небольшой украинской команды и серьезных людей из Snowball Interactive. Сейчас мы прекрасно понимаем, что опыт получился довольно специфичный, сопряженный с множеством проблемных моментов и неоднозначной реакцией публики, но при этом совершенно точно вошедший в историю. Да и сами турки после такого опыта кардинально пересмотрели свои планы, на долгое время отказавшись от идей раздавать движок каждому желающему мододелу. Кто знает, сколько еще коммерческих проектов мы получили, если бы не ОиМ. Но также надо понимать и то, что по своему игра получилась крайне необычной, с рядом интересных решений и потенциалом, способным заинтересовать даже современного игрока, а поэтому игнорировать ее попросту нельзя.

Одним из основоположников проекта является Максим Горбань, также известный под псевдонимом Maxim Suvorov. На момент начала работы над ОиМ, Максим получил опыт в создании XIII Век: Русич, а также работе над рядом модификаций для Mediedal 2: Total War. Человек, имевший опыт не только в модификациях, но и коммерческих проектов, безусловно, давал команде определенную фору, хотя говорить о том, что у проекта сразу все получилось, конечно же, нельзя. Остальная команда собиралась по принципу “с миру по нитке. Очень сильно, по словам Максима, помог форум “СиЧи” - тематического сайта, посвященного серии Total War и предыдущий опыт работы над модом для “Рима”. В итоге собрался небольшой коллектив, в который, помимо самого Максима, вошли 3D художник SHREDDER, мастер многостаночник Алексей Федорич ака Sigmar (модели, баланс, сборка, тестирование), автор сюжета Александр Трубников ака Monfore, опытный игродел Сергей Шатёрный, успевший в свое время поработать над Сталкером - его работа заключалась в оформлении архитектуры и программист Вячеслав Кушнерук aka SlavaHeart.

Работа над Огнем и мечом началась в начале 2009 года, незадолго после выхода оригинальной Mount&Blade и, само собой, еще до эпохи Warband. Учитывая предыдущий опыт авторов, с выбором тематики долго думать не пришлось: это должен был быть исторический проект, ориентированный на восточную часть Европы. С учетом того, что все авторы имели украинское происхождение, им хотелось добавить в проект казачьего колорита, а поэтому середина 17 века стала идеальным вариантом для творчества, способным раскрыть события в сразу нескольких направлениях, сопряженных с легендарным восстанием Богдана Хмельницкого. При этом немалую роль сыграл одноименный роман Генрика Сенкевича, который собственно и лег в основу сюжета игры. Внимательный поклонник творчества автора даже найдет схожести по части наименований сюжетных линий. Всего нас ждали 3 линии: польско-литовская, запорожская, а впоследствии и московская.Помимо основных действующих лиц присутствовали Шведы и Крымское ханство. Как поясняли в свое время разработчики игры, прежде всего, это время удачно подходит под саму механику M&B – огнестрел уже достаточно развит, чтобы быть чем-то большим, чем психологическим оружием, но холодное оружие продолжает доминировать на поле боя. К тому же, проект Армагана  – это кавалерийская игра, поэтому логичным было выбрать эпоху наиболее блистательных кавалеристов: крылатых гусар, запорожских казаков, рейтеров. Ну и, само собой, немалую роль в этом сыграли также легендарная RTS “Казаки” от GSC, любовь к истории со школы, пан Володыевский и все тот же мод на “Рим”.
 
Как я уже заметил ранее, на тот момент какой-либо опыт в выпуске платных дополнений для M&B отсутствовал, но при этом фанаты игры успели вдоволь насладиться дарами мододелов, создавших большое число разнообразных проектов и в значительной мере разбаловавших публику. Но авторы не унывали, надеясь на то, что их проект будет выгодно отличать наличие сюжетного повествования. Говоря о концепции проекта в целом, было принято решение сохранить общие элементы песочницы, правда на тот момент разделить эти два элемента на манер Viking Conquest еще не додумались, что в итоге вылилось в одну из проблем игры - неполноценный фриплей. Многие из фанатов M&B критиковали проект за отсутствие таких элементов, как игра за женского персонажа, свободное создание собственного королевства и т.п. В общем, несмотря на то, что сюжетная линия в целом серьезно помогла игре, уменьшение привычного для Mount&Blade функционала оказалось для многих игроков неприятной неожиданностью. Кстати, о сюжете: как пояснил Максим, это была основная фича с момента задумки. Разработчики даже никогда не обсуждали стоит ли выпускать продукт без цельной истории.

Впрочем, процесс разработки сам по себе бессмысленен без конечного результата. Для коммерческого продукта таким результатом должны были стать продажи, а они были невозможны без договоренностей с Taleworlds и печати дисков - цифровая индустрия в те времена находилась лишь в зачаточном состоянии. И здесь в игру вступила студия Snowball в лице Александра Суслова, имя которого появляется на Всадниках далеко не в первый раз. И тут нужно сделать небольшое отступление в сторону истории появления самой Mount&Blade на территории России, дабы понимать все дальнейшие события. Как пояснил сам Александр, еще в 2005 году он наткнулся на бету Mount & Blade и сразу решил, что это будущий бульдозер, который снесет рынок - игра выглядела совершенно безобразно даже для 2005 года, но игралась как RPG будущего. Где-то в это время выходили всякие Neverwinter Nights и они рядом с M&B смотрелись просто каким-то анахроничным приветом из прошлого. В то время Александр работал в одном из подразделений студии Snowball, который сами работники шуточно называли отделом пропаганды. Он отвечал за маркетинг и оценку коммерческого потенциала у различных  проектов. По словам Суслова, в M&B были только “Зендар, лошадь и три бандита”, но коммерческий потенциал там просто искрился, а поэтому сразу после знакомства с проектом с дикими воплями он побежал к Сергею Климову с требованием немедленно договориться о лицензии на издание игры. Сергей в свою очередь предложил написать Армаану Явузу, в результате чего родилось довольно своеобразное письмо в духе "и чтобы можно было грабить корованы", на которое Армаан очень вежливо и деликатно ответил. Оказалось, что права уже ушли Paradox, но вообще ему приятен такой интерес к проекту, а поэтому он выразил надежду когда-нибудь поработать в будущем.

Как мы помним, Mount&Blade так или иначе все равно была издана в 2008 году под наименованием "История героя". Проект полюбился населению СНГ и то начало требовать добавки. И тут совершенно неожиданно, но очень к месту самом конце 2008-ого с Snowball связался Максим Горбань с идеей сделать коммерческую версию мода "Огнем и мечом". Ну и, вы сами понимаете: поскольку контакты с TaleWorlds уже были налажены, совместными усилиями разработчика и продюсера удалось довольно быстро договориться о покупке лицензии на движок, правда только на территорию бывшего СССР и Восточной Европы. Snowball брал на себя оплату разработки, занимался маркетингом, закрывали те моменты в продакшене, на которых у "Сичи" не хватало ресурсов, например, интерфейс и внутриигровой арт. Кроме того, именно ребята из Snowball стали инициаторами добавления третьей сюжетной линию за русское царство, поскольку изначальный план покрывал только украинскую и польскую кампании и для чисто российского релиза это было не вполне благоразумно.

Впрочем, припоминая известную поговорку про “гладко было на бумаге”, надо сразу же отметить, что эйфория быстро прошла и наступила суровая реальность. Поскольку движок никогда не планировался для сторонней разработки, то практически никакой документации к нему наработано не было и вся работа велась с помощью “совета старейшин”: Максим описывал Александру встречающиеся проблемы, а тот шел с ними к главному программисту Taleworlds Джему Чименбичеру. Последний сверялся со своими тайными скрижалями и давал команде ответ или правил код движка. Это не спасло проект от огромного количества багов на релизе, но концепция и идея игры оказались настолько привлекательными, что на коммерческий успех проекта, как подытожил сам Александр, забагованность не повлияла. В любом случае, как заметил Максим, разработка была забегом по саду с граблями. Сичевики честно признались, что в тот момент успели наделать столько ошибок, сколько только могли.

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

Выход игры состоялся в декабре 2009 года и надо отметить, что игра была встречена довольно тепло, хотя при этом обнажилась и главная проблема игры, которая в дальнейшем преследовала ее длительное время и не была решена окончательно даже к настоящему времени: технические проблемы с прохождением кампании. Многочисленные баги, приводившие к невозможности продолжить сюжетную линию еще долго будут вспоминаться фанатами, но к чести разработчиков они приняли все возможные меры для минимизации проблемы. Сама идея делать сюжет “с рельсами” внутри песочницы - крайне нетривиальная задумка, даже сейчас, каждый этап сюжета может провалиться, просто потому что игрок уже уничтожил фракцию или сменил её. В любом случае, на момент своего первоначального выхода игра была мягко говоря сыра. Впоследствии это признали все, но на тот момент, во-первых, работало правило “на безрыбье и рак рыба”, а, во-вторых, ОиМ в озвученной терминологии раком вовсе не являлась, ведь, повторюсь, игра могла предложить интересный сюжет и множество положительных решений в области игрового процесса. В любом случае, еще до релиза стало понятно, что все запланированное к назначенному сроку реализовать было попросту невозможно, а поэтому выходов было только 2: переносить сроки или выпускать что есть с планами доделать сотворенное впоследствии. Что из этого вышло в итоге я расскажу чуть дальше, а пока закончим тему с релизом.

Так как права на лицензию, выданную Snowball, распространялись также и на восточную Европу, через некоторое время проект также был опубликован в Польше. Там игра получила достаточно большой успех, обеспечивший высокие продажи. Впрочем, форум Всадников Кальрадии помнит и критику в адрес игры, озвученную польским сообществом в целом и отдельными представителями движения создания модификаций в частности. Оно и понятно: игра на тот момент по сути оставалась такой же недоделанной, что и в СНГ. Требовалась масштабная доработка серии, дабы не ударить в грязь лицом. В итоге в мае 2010 года все же вышло золотое издание, ставшее настоящим подарком для фанатов игры. Суть золотого издания заключалась в приведении проекта в итоговое состояние путем подчистки многочисленных хвостов и доработки тех вещей, которые в свое время так и не были воссозданы в изначально запланированном виде. Как признались сами разработчики, во многом это была очистка их собственной кармы.

Ну а затем свет увидел Warband ("Эпоха турниров"), подаривший игрокам сетевой режим, а поэтому творческий союз решил приступить к созданию еще одного издания - уже на обновленном движке и с мультиплеером. Таким образом, в декабре 2010 года был запущен проект Огнём и мечом: Великие битвы. По сути это было целиком мультиплеерное дополнение к оригинальному проекту, переиначивающее сетевой режим Warband на свой лад, но были и другие изменения: подтянута графика, добавлена такая условная под-фракция шотландцев. Ну и, само собой, режим "Капитанов" - это главный взнос "Огнем и мечом" в серию Mount & Blade, в рамках которого проводилась плотная работа с турецком командой. На тот момент турки решили присоединиться к разработке в гораздо более активном формате и смогли внести свой вклад в улучшение качества продукта.

Steam версия вышла в 2011 году как знак того, что эпоха дисков ушла в прошлое, хотя некоторые разработчики даже скучают по ней. Проект ожидаемо вышел в линейке Paraodox, поскольку они обладали правами на всю серию, хотя сами в работе над игрой никак не участвовали. Ну а через некоторое время права вернулись к туркам, а поэтому издателями проекта стали значится именно они. Впрочем, другое было невозможным: на тот момент в системе было попросту невозможно указать несколько авторов или издателей. Кстати говоря, в том самом стимовом релизе была подправлена очередная пачка багов, снова пересобран интерфейс, изменены звуки - в таком виде игра и стабилизировалась.Что интересно, много лет спустя, в конце 2019 года - начале 2020-ого интерес к игре вновь вернулся, что прекрасно видно по его статистике в Steam.

Ну и в качестве вишенки на торте хочу представить позицию Александра Суслова относительно проекта. Привожу ее в оригинальном виде от первого лица: Я думаю, что главное значение ОиМ вовсе не в режиме "Капитанов" (он и так напрашивался и не мы, так кто-то другой бы его в игру вставил). Но "Огнем и мечом" показала пример другим моддерским командам, что можно не просто пилить проект для себя как хобби - но можно сделать это профессиональной деятельностью. Вышел "Наполеон", вышли "Викинги" - а затем вышел такой проект как Holdfast, который как бы "Наполеон", но уже почти без всякой привязке к Warband и на другом совсем движке (но от той же команды). И это классно, именно так и должны появляться новые звезды в геймдеве - Кодзима, конечно, гений, но новые жанры создают моддеры: так было с Counter-Strike, так было с Team Fortress, со всеми "Дотами", с батл-роялями. Я помню, что когда "Оим" только анонсировали, на "Всадниках" шли очень острые споры, что насколько же это грешно и чудовищно, что люди мод продают за деньги. Я и тогда искренне не понимал этого негодования, и сейчас не понимаю. Коммерческий проект может выйти хоть и кривым - ОиМ и "Викинги" тут конечно не дадут соврать, но со временем их починят, люди будут играть, у команды будут новые проекты. Вот например Максим сейчас работает дизайнером в Ubisoft, то есть является состоявшимся профессионалом в геймдеве - потому что получил этот опыт коммерческой разработки. Ведь коммерческий проект это всегда про дисциплину и нахождение баланса между желаниями / лимитами. В этом смысле очень жаль "Русь 13 век", которой этой дисциплины или воли к релизу как-то не хватило и проект в итоге остался если не совсем призраком, но шанс на успех точно упустил.

Что касается моего личного мнения, то, безусловно, я считаю, что Огнем и мечом в итоге все же достиг поставленной цели. Но нужно помнить и о цене этого достижения. Как мы видим, процесс создания первого производного проекта по Mount&Blade оказался не таким уж и простым: где-то сами турки не подготовили должной почвы, где-то у разработчиков сил и знаний не хватило, где-то издатель излишне поторопил, где-то просто звезды так сошлись, но все-таки игра была рождена на свет, а впоследствии доведена до вполне адекватного состояния. И, да, наравне с положительными моментами имеются и некоторые негативные последствия. Как мы увидели впоследствии, сами турки явно не ожидали настолько больших проблем с игрой и видимо поэтому в итоге приняли решение в дальнейшем вести все разработки исключительно под своим чутким руководством. Оно, конечно, в итоге все же было пересмотрено, но сколько других перспективных команд лишилось внимания со стороны турок? Кстати, именно поэтому лично я, при всем своем уважении к Александру, несколько скептически отношусь к его оценке реальных перспектив “Руси” в отношении коммерческого издания, но это уже совсем другая тема. По факту же, как ни крути, но “Огнем и мечом” стал таким же этапом развития серии, как и Viking Conquest или Napoleonic Wars. Да и к лицензированию движка турки тоже в итоге все же вернулись, в результате чего мы получили “На Карибы” и Gloria Sinica.Ну а что до самого Огнем и мечом, то изначальная команда разработчиков уже распалась, да и компания Snowball в том виде, в каком мы ее когда-то знали, перестала существовать, переродившись в итоге в Snowbird Game Studios, но дело их продолжает жить.

9
Автор мода: pipe dream
Тип: переработка карты
Сайт: https://www.nexusmods.com/mountandblade2bannerlord/mods/2265

Данный мод полностью заменяет оригинальную карту Кальрадию на историческую Европу, добавляю при этом такие государства, как Англия, Испания, Франция, различные итальянские королевства и немецкие княжества. В целом принадлежность поселений соотносится с периодом Столетней войны. Мод также затрагивает наименования лордов, но не меняет оригинальные цепочки юнитов, а поэтому полноценной переработкой данный проект называть нельзя. В целом это довольно сырой продукт, демонстрирующий результат базовой работы в инструментах мододела.

Оригинал мода на китайском. Версия с нашего сервера уже содержит вшитый англофикатор

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


(нажмите для открытия / скрытия)

10

Немного с запозданием, но все же информирую вас о появлении нового видеоролика с планами разработчиков Mount&Blade II: Bannerlord на ближайшие обновления. Оригинал заметки также представлен в текстовом виде в сообществе Steam и на официальном сайте игры. В этот раз команда решила рассказать нам о целом ряде изменений, наиболее важной деталью которого является значительная переработка системы дальнего боя. Как говорится в видеоролике, команда хочет сделать выбор оружия дальнего боя более осмысленным, введя различия между различными его видами. В первую очередь это связано с такой вещью, как прицеливание. Разработчики хотят его вариативным. Так, например, короткие луки будут "сводиться" максимально быстро и при этом ваш персонаж дольше будет удерживать максимально эффективный прицел, в то время как длинные луки и натягиваться дольше будут и уставать от них персонаж начнет раньше, что будет компенсировать значительно более высокий урон от одиночного выстрела. Такое изменение затронет не только луки, но и арбалеты и различное метательное оружие. Но не стоит думать, что вводимые отличия будут колоссальными: судя по представленным примерам, речь скорее о миллисекундах, что, наверное, было бы более актуальным для мультиплеера, где вопрос балансировки оружия дальнего боя уже давно стал крайне актуальным.

Что касается других новшеств, о которых решила рассказать нам команда, то это система образования, которая позволит обучать свое потомство, тем самым оказывая влияние на формирование характеристик у детей, новый функционал в виде метающих мелкие камни мангонелей (они будут эффективны против пехоты), долгожданное понятие хромоты у лошади (признаться честно, я все это время думал, что лошадь уже может стать хромой), радиальное меню для удобства играющих с геймпадов, но не только, изменения в системе вербовки пленников в виде штрафов для отряда и навыков по их компенсации, возможность следовать за другим отрядом через сочетание Alt + клик мышью и даже новая кольчужная броня у баттанийцев (в оригинале chainmail - с нетерпением жду когда кто-нибудь обзовет ее цепной почтой).

11
Автор: Alisacat007

Аудиосистема Bannerlord построена на фирменной аудиосистеме FMOD. Чтобы сохранить производительность звукового движка и сделать его доступным для всех, нам нужно было создать свой внутриигровой аудиопроигрыватель.

Ключевые элементы


В файл  ...\Modules\*ВАШ МОД*\ModuleData\module_sounds.xml вы прописываете названия своих звуковых файлов.
В папку  ...\Modules\*ВАШ МОД*\ModuleSounds вы помещаете свои новые аудиофайлы (.ogg, .wav).

В качестве примера можно посмотреть, как это реализовано у разработчиков в их модуле ‘Native’.

Базовое руководство


1. Скопируйте примеры файлов и папок из модуля ‘Native’в свой собственный модуль.
2. Добавьте свои новые звуки в папку ModuleSounds
3. Откройте файл module_sounds.xml в вашем модуле.
4. Просмотрите пример записи кода звуковых файлов в файле module_sounds.xml  модуля ‘Native’.
5. Добавьте новые строки в файл module_sounds.xml своего мода.
6. Воспроизведите для проверки новое звуковые записи из кода.

Двигаемся дальше


Using module_sounds.xml (Помощь в создании файла module_sounds.xml) :



,где :

‘name’ : любое уникальное имя, которое вы хотите. Это идентификатор вашего звука.
             Используется во время воспроизведения звука из кода.
             Используется для воспроизведения звука анимации, добавив к анимации свойство 'sound_code'.

‘is_2d’ : (Звук является 2d) Ставится значение "true" (верно), если пространственные свойства звука не будут использоваться. 3d звуки имеют свойства, как (position) расположение в пространстве, (velocity) скорость воспроизведения и т.д.

‘sound_category’ : Все звуки должны быть отнесены к определенной категории, чтобы они правильно воспроизводились.
                                             
Доступные категории:
mission_ambient_bed (Звук, движущийся в игре по кругу. Напр. ветер)
mission_ambient_3d_big (Звуки, которые должны быть слышны издалека. Напр. горящий замок)
mission_ambient_3d_medium (Звуки, которые должны быть слышны со среднего расстояния. Напр. удаленный костры)
mission_ambient_3d_small (Звуки, которые должны быть слышны поблизости. Напр. костры в лагере)
mission_material_impact (Звуки физических материальных воздействий. Напр. удар металлического меча о каменную стену)
mission_combat_trivial (Звуки несущественного урона. Напр. низкий/нет урона)
mission_combat (Звуки повреждений)
mission_foley (Взмахи оружия, звук шагов, звуки движения животных)
mission_voice_shout (Звуки голоса людей/животных, которые должны быть слышны издалека. Напр. боевые крики)
mission_voice (Звуки от людей/животных. Напр. хрюканье, удары по лицу)
mission_voice_trivial (Тихие вокализации, такие как лазание, прыжки)
mission_siege_loud (Звуки больших осад, которые звучат так, словно валун врезается в стену, катапульта стреляет, дверь ломается)
mission_footstep (Стандартные шаги людей и мелких животных)
mission_footstep_run (Более громкие шаги, которые можно услышать издалека. Напр. толпы)
mission_horse_gallop (Галоп лошадей и верблюдов)
mission_horse_walk  (Мягкий шаг лошадей и верблюдов)
ui (2D звуки для пользовательского интерфейса и уведомлений)
alert (Псевдо-3d звуки для оповещения игрока со средней дистанции)
campaign_node (Позиционные звуки для карты мира, ферм, морей, водопадов)
campaign_bed (2D окружающие звуки для карты мира, порывов ветра в пустыне, ветры на травяных пастбищах и т.д.)

‘path’ : Имя звукового файла для воспроизведения [обязательно с его расширением]. Путь (Path) указывается относительно папки ModuleSounds вашего модуля. Вы можете создавать подпапки.

Пример кода в звуковм файле




У вас есть два способа воспроизведения звука :
One Shot (Один выстрел). Лучшая производительность и меньше контроля за управлением. Выстрелил и забыл. Хорошо подходит для звуков, связанных с боем.
Creating and holding (Создание и удержание ссылки). Худшая производительность. Контролируйте каждый параметр звука всякий раз, когда вы хотите его произвести. Обновление состояния во время паузы.

12
Автор: Дима Гончар

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

Создание нового модуля


Модули находятся в папке «Modules» в корневой папке игры. Модуль должен содержать XML-файл с именем SubModule.xml. Этот файл содержит основную информацию, такую как узлы «Name», «ID» и «Version» (Имя, Идентификатор, Версия). Кроме того, можно определить зависимые модули внутри узла «DepenendedModules». Если вы хотите создать однопользовательский мод, он также должен содержать узел «SingleplayerModule». После этого модуль будет виден в загрузчике игры.

SubModules могут определять библиотеки DLL (англ. Dynamic Link Library — «библиотека динамической компоновки», «динамически подключаемая библиотека»), загружаемые во время работы игры. Эти DLL должны содержать класс, который наследуется от «MBSubModuleBase», а имя должно совпадать с узлом «SubModuleClassType» внутри xml. Этот класс будет создан, и будут вызываться определенные обратные вызовы, чтобы "od" мог регистрировать свое поведение в игре.

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

Иерархия модулей


Модули могут иметь несколько папок, содержащих разные типы контента:
  • bin: скомпилированную DLL следует поместить в папку «bin\Win64_Shipping_Client», чтобы игра могла найти и загрузить эту DLL.
  • Atmospheres: эта папка содержит различные шаблоны атмосферы, которые можно использовать в игре. Новая атмосфера может быть сохранена в любом модуле из Редактора.
  • AssetSources: эта папка содержит источники ресурсов. Редактор импортирует ресурсы в эту папку. Эта папка может быть отфильтрована перед публикацией мода. Для получения дополнительной информации о добавлении нового содержимого в модуль см. Добавление и переопределение ресурсов.
  • Assets: эта папка содержит данные ресурсов, полученные из источников контента. Она используется только на этапе разработки мода. Эта папка может быть отфильтрована перед публикацией мода.
  • AssetPackages: после того, как работа с содержимым модуля завершена, создатель содержимого должен запустить операцию Публикации, чтобы подготовить содержимое к выпуску. Эта база данных содержит «Опубликованные» ресурсы.
  • GUI (графический интерфейс): эта папка содержит любой новый элемент графического интерфейса, prefab (префаб) или brush (кисть), которые можно использовать в игре.
  • ModuleData: эта папка содержит многие важные XML-файлы для игровой логики. Файл «project.mbproj» управляет XML-файлами, которые будут загружены в папку. Эти xml-файлы варьируются от анимаций и устанавливается для фракций, предметов, предметов и т.д.
  • NavMeshPrefabs: группы граней навигационного меша можно сохранить в редакторе в качестве шаблонов, чтобы легко вставлять их в несколько сцен. Эта папка содержит эти файлы.
  • Prefabs: эта папка содержит XML-файлы префабов. Для получения дополнительной информации см. Объекты и префабы.
  • SceneObj: эта папка содержит данные сцены, которые убраны из любых Edit Data (данных редактирования). Сцены без ландшафта хранятся только в этой папке.
  • SceneEditData: содержит данные редактирования ландшафта для каждой сцены. Эта папка может быть отфильтрована перед публикацией мода.

13
Автор: Alisacat007

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



1. Scene Basic Information Tab (Вкладка "Основная информация о сцене")

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

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



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





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



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

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

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

14
Автор: Alisacat007

Колбэк (от англ. callback) - или функция обратного вызова в программировании — передача исполняемого кода в качестве одного из параметров другого кода. Обратный вызов позволяет в функции исполнять код, который задаётся в аргументах при её вызове. Этот код может быть определён в других контекстах программного кода и быть недоступным для прямого вызова из этой функции. Некоторые алгоритмические задачи в качестве своих входных данных имеют не только числа или объекты, но и действия (алгоритмы), которые естественным образом задаются как обратные вызовы.

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)), вы можете использовать этот колбэк, чтобы убедиться, что они не проникли в сцену.

15
Автор: Alisacat007

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

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


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

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

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

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

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



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

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

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

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

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

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



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) префаба беседы не должен меняться.

( NPC игрок)
В каждой сцене таверны должен быть 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 (Тип) : Тип области должен быть установлен из таблицы ниже :



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

16
Автор: Alisacat007

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

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



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



Задайте свое имя пути :



Постройте свой путь так, как вы хотите :



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



Вы можете перейти к этому объекту с помощью кнопки “Go to Entity” (“Перейти к объекту”) и изменить его параметр, такой как высота (height). Объект задать с именем “path_barrier_PATHNAME” :


17
Автор: Alisacat007

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

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


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

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

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

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

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

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

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

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

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




(Script Overview (Обзор скрипта))

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

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

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

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

ReferenceEntityTag (Справочный тег объекта) - это необязательный тег, когда префаб DestructionState имеет кадр, отличный от его родительского, или для копирования состояний анимации. Вы можете добавить дополнительный объект (с помощью скрипта 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 (Иерархия сегмента стены) :


(Wall Hierarchy Edited (Отредактированная иерархия стен))

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

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


(Wall Script (Скрипт стены))

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

Origin of wall and merlon pieces (Создание частей стены и мерлонов) :

Каждый мерлон представляет собой уникальный меш, который имеет свою исходную точку в нижней части стены (так же, как и вся стена).


(Wall Origin Merlon Hierarchy)


(Wall Origin Merlon)

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


(Wall Origin Debris Hierarchy)


(Wall Origin Debris)

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


(Debris Hierarchy)


(Debris)

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

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



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

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

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



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



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.

18
Автор: Alisacat007

Этот список контрольных точек (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 со скал или застревание их в труднодоступных местах (например, в рыночной будке) вне навигационного меша.


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

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


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


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”.
Убедитесь, что есть какое-то подсказки на то, где лагеря могут быть, чтобы у игрока был шанс найти их (особенно ночью).
Не ставьте их слишком близко друг к другу.


(Bandit Camps)

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

Tactical Region (Тактические регионы)


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

Tactical Positions (Тактические позиции)


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


(TacticalPosition)

Flee Positions (Позиции для отступления) :


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


(Flee Positions)

Debug Window (Окно отладки) :


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


(Debug Window)

Soft Border (Мягкая Граница) :


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


(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 (???)).


(Sounds)

Reverb (Реверберация) :
[Реверберация — это процесс постепенного уменьшения интенсивности звука при его многократных отражениях. Иногда под реверберацией понимается имитация данного эффекта с помощью ревербераторов. К реверберации примыкает явление акустического флаттера, или порхающего эха.]

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

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

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

Проложите траекторию движения прямо по реке. Дополнительные сведения см. В разделе Path Editing (Редактирование пути) :
http://docs.modding.bannerlord.com/editor/scene-editor/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 :
http://docs.modding.bannerlord.com/editor/scene-editor/prt/


(Lights)

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


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


(Atmosphere)

19
Автор: Alisacat007

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


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

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

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


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



Top of Hill, Defendable against all directions (Вершина холма, защищенная со всех сторон) :

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

_width : (ширина) что немаловажно, должна быть примерно равна радиусу вершины холма.
_slope : (склон) также важен для выбора между позициями, он исчисляется в градусах и его максимум наклона в 60 градусов распознается AI. AI должен примерно оценить крутизну позиции.
_isInsurmountable : Непреодолимая ни кем позиция.
_isOuterEdge : (Внешний край) false (отключенный параметр)
_tacticalPositionType : Возвышенность
_tacticalPositionMembership : Лес, ущелье или другая сложная местность.
_tacticalPositionSide : BehaviorSideNotSet (Возвышенность, у которой сторона действия противника не установлена).



Choke Points (Узкие места) :
Это для позиций с непроходимыми барьерами с обеих сторон. AI с более меньшим числом бойцов может попытаться удержать эти позиции, чтобы компенсировать их недостаток.

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



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

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



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


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

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



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



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



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


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

20
Автор: Alisacat007

Import Settings (Настройка импорта)


Divide Into Grid (Деление на сетки (меши) ) : делит мета-меши [сложносоставные модели] на отдельные меши и добавляет все сгенерированные секции мешей в sub-meshes.
Remove Redundant Vertices (Удаление избыточных вершин) : название подразумевает то, что оно делает.
Recompute Normals (Повторное вычисление нормалей) : при импорте мета-мешей вычисляет векторы нормалей для всех submeshes вместо того, чтобы импортировать их.
Normal Computation (Вычисление нормалей) : решает, будет ли векторное вычисление нормалей происходить в области лица (weighted (нагрузить)) или нет (default (по умолчанию)).
Recompute Tangents (Повторное вычисление касательных векторов) : при импорте мета-меша вычисляет касательные векторы (tangent vectors) для всех sub-meshes вместо того, чтобы импортировать их.
Whiten (Отбеливание) : линейная интерполяция между цветом вершины и белым цветом для каждого цветового канала.

Lod Meshes (Лоды мешей)


От переводчика: LOD (англ. Levels Of Detail  - уровни детализации) - приём в программировании трёхмерной графики, заключающийся в создании нескольких вариантов одного объекта с различными степенями детализации, которые переключаются в зависимости от удаления объекта от виртуальной камеры для уменьшения нагрузки на ваше железо.

Все активные sub-meshes мета-меша можно увидеть здесь. Свойства материала (material properties), параметры меша и метки (tags) могут быть изменены через интерфейс.



Unused Meshes (Незадействованные меши)


Этот раздел описывает ситуацию активности sub-meshes. Если флажок игнорировать (ignore) установлен, это означает, что соответствующая sub-mesh неактивна. После изменения статуса лода меша (lod meshes), пожалуйста, нажмите кнопку “Apply Ignores” (“Применить игнорирование”), чтобы ваши изменения состоялись и были сохранены.



Save (Сохранение)


Сохраняет все изменения, внесенные в мета-меш.

21
Автор: Alisacat007

Редактор скелета можно использовать для редактирования параметров костей, суставов и ragdoll-моделей после их импорта с помощью браузера ресурсов (resource browser).



Editing Bones and Joints (Редактирование костей и суставов)



Чтобы отредактировать кость или сустав, вы можете выбрать нужный элемент на панели outliner.
Это откроет окно Inspector of bones/joints (инспектор костей/суставов) для редактирования.
Все параметры визуализируются, и все изменения сразу же будут видны в предварительном просмотре.




Joint Properties (Общие свойства)



Axis lock (Блокировка осей) :
Блокировка оси ограничивает движение дочерней кости (child bone) в пространстве преобразования. Может настраиваться независимо для каждой оси.
None (Нет) : означает, что этот сустав не может двигаться по этой оси.
Free: (Свободно) : означает, что этому суставу позволено свободно двигаться, насколько он может двигаться по этой оси.
Limited (Ограничено) : означает, что этому суставу разрешено перемещаться на заданное расстояние по этой оси. (Axis Limit parameter (Параметр лимита оси))

Twist Lock (Блокировка закручивания) :
Блокировка закручивания ограничивает поворот дочерней кости на оси Z (оси вращения). Возможна независимая регулировка для обеих вращающихся сторон.
None (Нет) : означает, что этот сустав не может закручиваться.
Free: (Свободно) : означает, что этому суставу позволено свободно закручиваться столько, сколько он может.
Limited (Ограничено) : означает, что этому суставу разрешено закручиваться до определенного предела. (Twist Limit parameters (Параметр лимита поворота))

Swing Lock (Блокировка качания) :
Блокировка качания ограничивает вращение дочерней кости по осям X и Y. Может регулироваться независимо для обеих вращающихся сторон.
None (Нет) : означает, что этот сустав не может качаться.
Free (Свободно) : означает, что этому суставу позволено свободно качаться столько, сколько он может.
Limited (Ограничено) : означает, что этот сустав может качаться до определенного предела. (Swing Limit parameters (Параметр лимита качания))

Все эти параметры визуализируются в предварительном просмотре. Не стесняйтесь изменять их и просматривать получившийся эффект.

Bone Properties (Свойства костей)



Свойства костей могут быть использованы для изменения ragdoll и collision капсул.
Визуализация капсулы может быть включена в Display panel (панели дисплея).
Вы можете изменить радиус капсулы, положение 1 (верхняя часть капсулы), Положение 2 (нижняя часть капсулы) на Properties panel (панели свойств).


(ragdoll capsule)


(collision capsule)

Ragdoll Simulation (Ragdoll-моделирование)


Лучший способ визуализировать ваши изменения, это включить ragdoll-моделирование и посмотреть ваши изменения в режиме реального времени. Просто выберите скелет из outliner и нажмите кнопку Red "Simulation Enabled/Disabled". Это включит ragdoll-моделирование. Нажатие этой кнопки снова отключит ragdoll-моделирование и сбросит скелет обратно в T-Pose.


(ragdoll enabled)

Testing and Saving changes (Тестирование и сохранение изменений)




(ragdoll drag)

Вы можете выбрать кости и перетащить их с помощью мыши, чтобы проверить пределы и поведение ragdoll-модели.
После завершения настройки и тестирования вы можете сохранить все свои изменения в меню File > Save (Файл > Сохранить).
Сохранение изменит соответствующие файлы .tpac для каждого измененного скелета.

22
Автор: Alisacat007

В Редактор текстур можно войти через Editor > Window > Show Resource Browser > ..Search for Texture.. > двойной клик по нужной текстуре.



В Texture Inspector (Инспекторе текстур) (правая панель) вы можете включить/отключить смешивание MipMap, установив флажок на Use Mipmap Blending. Когда вы включите смешивание MipMap, вы увидите все уровни mip выбранной текстуры рядом друг с другом в окне предварительного просмотра.



При нажатии кнопки MipMap Blend Amounts откроется новое окно, в котором вы можете настроить количество смешивания для каждого уровня mip.



Затем вы можете выбрать кнопку MipMap Blend Color (1) и нажать кнопку Recompile (2), чтобы применить смешивание. Результат будет сразу же виден в окне предварительного просмотра, а также в игре.


23

Overview (Обзор)





Наш фирменный игровой движок использует стандартный металлический конвейер  PBR (metallic PBR pipeline) [концепция рендеринга, основанная на физических принципах] для создания материалов.

От переводчика: Я советую всем ознакомиться с интересной статьей по PBR на habr.com/

Новые материалы можно легко создать, перейдя в папку, щелкнув правой кнопкой мыши на пустом месте и выбрать из контекстного меню Create (создать) > Material (материал).

Редактор материалов можно открыть, дважды щелкнув на уже существующий материал в браузере ресурсов (resource browser).



Inspector (Контроль)


Shader (Шейдеры) :



Вы можете выбрать нужный шейдер из этого виджета выбора шейдеров.
Существует несколько в основном используемых шейдеров; наиболее важными из них являются pbr_metallic и pbr_shading.

pbr_shading :
Этот шейдер широко используется и существует в игре только потому, что наш движок не использовал конвейер затенения PBR (PBR shading pipeline) в первые годы разработки, большая часть контента не была создана для конвейера PBR, поэтому этот шейдер создан для поддержки нашего уже существующего контента и используется только на переходном этапе .
Новый контент не должен использовать этот шейдер, вместо него вы должны использовать pbr_metallic.

pbr_metallic :
Это то, что вы должны использовать большую часть времени. Этот шейдер использует стандартный металлический конвейер PBR, а входные данные совместимы с большинством программ для создания текстур.

Inputs (исходные ресурсы) :
Albedo (альбедо) и Normal (нормаль) : Они довольно стандартные, можно напрямую использовать выходные данные программ для создания текстур.
[ Альбедо - это текстура, которая содержит независимую информацию о цвете.
Нормаль - это технология, используемая для имитации неровностей поверхности на объекте. ]

Specular (спекуляр) : Эта текстура использует свои 4 канала для различных целей.
Красный канал (Red channel) содержит информацию металлической поверхности.
Зеленый канал (Green channel) содержит информацию о глянцевости (обратную шероховатости).
Синий канал (Blue channel) содержит Ambient Occlusion [ Это черное-белая текстура, в ней хранятся тени от рассеянного света. Они могут подчеркнуть рельеф изображенный на основной текстуре. Данную текстуру использовать не обязательно, но материал без нее может смотреться более плоским. ].
Альфа-канал содержит информацию о полупрозрачности (только для растительных шейдеров).

grass (трава) :
Этот шейдер является производным от pbr_metallic и должен использоваться только на мешах травы. Содержит специальные эффекты, такие как анимация ветра, анимация раскачивания, плавные LOD-преобразования, умножение цвета на местности и т.д.

flora_leaf (листья) :
Этот шейдер является производным от pbr_metallic и должен использоваться только на листовых частях деревьев / кустарников. Содержит специальные эффекты, такие как анимация ветра, анимация качания, умножение цвета на местности, плавные LOD-преобразования, полупрозрачность (Альфа-канал зеркальной текстуры) и т.д.

flora_bark (кора) :
Этот шейдер является производным от pbr_metallic и должен использоваться только на частях коры деревьев / кустарников. Содержит специальные эффекты, такие как анимация ветра, плавные LOD-преобразования и т. д.

Textures (Текстуры)





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

Diffuse2Map :
Эти исходные данные используется внутренним движком игры для создания специальных эффектов / блендингов (special effects / blendings), таких как Shield Banner Paintings (щит с геральдическим баннером).
Текстура баннера в этом слоте будет отображаться только там, где Diffuse 1 Texture содержит альфа-канал. Использование этой текстуры зависит от используемого шейдера.

DetailNormalMap :
Эти исходные данные используется для создания микродефектов [трещины, шрамы, выбоины и т.п. ] и дополнительных высокочастотных деталей поверх обычного нормального отображения. Масштаб этой текстуры можно настроить на панели настроек текстуры (Texture Settings panel).

HeightMap (карта высот) :
Эти исходные данные используется как при Parallax Occlusion Shading [используется для процедурного создания трёхмерного описания текстурированной поверхности с использованием карт смещения вместо непосредственного генерирования новой геометрии], так и при Displacement (смещении).

Decal(___)Map :
Эти исходные данные используются внутренним движком игры для создания визуальных эффектов на коже или на других объектах (например, кровь и грязь).

Texture Settings (Настройки текстур)





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

Areamap Scale (Масштаб карты местности) :
Используется внутренне для передачи параметров.

Specular Coef :
Металлический канал (Красный канал спекуляра) умножается на это значение в шейдере.

Gloss Coef (Коэффициент блеска) :
Глянцевый канал (Зеленый канал спекуляра) умножается на это значение в шейдере.

Ambient Occlusion Coef :
AO channel (синий канал спекуляра) умножается на это значение в шейдере.

Normal Depth (Глубина нормали) :
Нормали текстур X и Y каналов умножаются на это значение. Если вы установите значение, близкое к нулю, поверхность будет казаться более плоской, так как значения X и Y будут близки к нулю, и только направление Z будет внесено в отображение нормали.

Detail Normal Scale (Подробный масштаб нормали) :
Этот параметр задает, во сколько раз должны быть детализированы текстуры. Более высокие значения увеличивают частоту.

Parallax Mode :
Вы можете выбрать метод смещения, который будет использоваться для этого материала. Варианты - Parallax (параллакс) или Displacement (смещение). И то, и другое требует текстуры heightmap. Parallax использует метод Parallax Occlusion Mapping в шейдере, Displacement использует hardware tesselation (аппаратную тесселяцию).

Parallax Amount (Величина параллакса) :
Интенсивность эффекта вытеснения (displacement effect).

Parallax Offset (Смещение параллакса) :
Устанавливает среднее значение на желаемую высоту. (Значение 0,5 в heightmap (карте высот)).

Material Shader Flags





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

Некоторыми важными значениями являются :
use_detailnormalmap :
Этот флаг должен быть включен для использования функции Detail Normal Map.

alpha_test :
В качестве вырезанной текстуры используются альфа-значения Diffuse 1 textures. Альфа-порог можно задать на панели Transparency (прозрачности).

use_specular :
Этот флаг должен быть включен во всех случаях.

use_procedural_wind_animation :
Можно включить для создания очень простого и малозатратного синусоидального колебания эффекта ветра. В основном используется для палаток / флагов. (Не следует путать с функцией физики ткани (cloth physics)).

self_illumination :
Включает подсветку. Текстура освещения должна быть указана в разделе Diffuse 2. Параметры яркости можно отрегулировать в панели Vector Arguments.

use_specular_from_diffuse :
Никогда этим не пользуйтесь. Он используется только в фазе перехода на конвейер PBR (pbr pipeline) и только в этой игре по устаревшим причинам. Просто оттеняет серым diffuse (диффузную) текстуру и использует ее как спекуляр.

use_double_colormap_with_mask_texture :
Используется внутренне для создания группового цветового эффекта в одежде. Специальная текстура создается, чтобы указать, какие части одежды должны быть затронуты цветами в группе. Простая красно-зеленая текстура для первичных и вторичных цветов задается в Diffuse 2 texture. Первичные (Primary) и вторичные (Secondary) цвета задаются игровым кодом в качестве Factor Colors (цветового коэффициента).

Transparency (Прозрачность)





Здесь можно указать режим альфа-смешивания и пороговые значения Alpha Test (альфа-теста).
Здесь также можно включить функцию Multi Pass Alpha. Этот метод создания двойного меша с помощью альфа-теста (alpha test) и альфа-смешивания (alpha blend), чтобы создать громоздкие, но гладкие на вид меши alpha testes. (Альфа-тест в средних областях меша для плотного покрытия, но гладкие альфа смешанные градиенты по краям, такие как волосы).

Others (Другие)





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

Vector Arguments (Векторные параметры)





Эта панель содержит два векторных аргумента. Оба содержат по 4 фактических значения, в общей сложности 8.
Эти векторные аргументы  используются в качестве параметров для некоторых специальных шейдерных эффектов, таких как настройка яркости Self Illumination (собственного освещения), скорости и направления Texture Sweep (развертки текстуры) и т. д.
То, какие изменения с каким векторным аргументом действительно происходят, зависит от эффектов, для которых он используется.

Factor Colors (Фактор цвета)





Эти цвета умножаются на внутренний Factor Color на мешах, которые обычно изменяются с помощью игрового кода. Если вы действительно хотите, чтобы какая-то текстура была немного темнее, зеленее и т. д. вы можете умножить их с помощью этой панели.

Vertex Layout (Макет вершин)





Эта панель используется для указания Vertex Layout (макета вершин), который должен использовать Vertex Shaders.

Bump Map (карта рельефа) :
Должен быть включен в большинстве случаев (стандартный PBR требует этого).

Skinning and Skinning Precise :
Если ваш материал будет использоваться со skinned mesh, включите Skinning, если ваш skinned mesh довольно велик и имеет важные маленькие полигоны (например, глаза), включите Skinning Precise (Точный скиннинг). (Это отключает некоторые оптимизации, поэтому используйте их только в том случае, если это действительно необходимо).

Double UV :
Включите, если ваши пользовательские шейдеры требуют двойных UV каналов.

PostFX :
Используется внутри движка игры.

24
Автор: Alisacat007

Preparing Mesh (Подготовка мешей)


Система моделирования ткани использует альфа-каналы вершин мешей (alpha channels of vertices of meshes). Значения в альфа-канале представляют, насколько вершина может отойти от своего исходного положения.
0,1 альфа-канала означает, что вершина может быть перемещена на 0,1 единицы от своего исходного положения с помощью моделирования ткани. Если вы установите ноль в альфа-значение, это означает, что вершина будет зафиксирована на своем месте и не будет обновляться при моделировании.


(Shaded)


(Vertex Alpha)

Черные части управляются системой скининга (skinning system), в то время как белые части моделируются.
Стоит отметить, что вычисления скиннинга выполняются для всех вершин, независимо от того, фиксированы они или нет.
Позиции skinned vertices (очищенных вершин) используются в качестве опорных точек для моделируемых вершин (simulated vertices).
Вы можете представить, что смоделированная вершина (simulated vertex) может перемещаться только внутри сферы с радиусом R и центром C. Здесь в качестве радиуса используется альфа-канал цвета вершины (vertex color), а в качестве центра - skinned position.


(Shaded)


(Vertex Alpha)

Simulation Types (Типы моделирования)


Direct simulation (Прямое моделирование) :
При прямом моделировании вершины визуализируемой сетки (vertices of rendered mesh) моделируются непосредственно с помощью моделирования ткани.
Этот метод может быть использован для мешей с простой топологией (например, решетка, сетка и т.п.) и небольшим количеством вершин.
По мере увеличения числа вершин затраты на производительность моделирования будет больше.

Mapped simulation (Отображенное моделирование) :
В некоторых случаях ваш меш может не подходить для моделирования ткани. Некоторые примеры - это доспехи с двусторонними полигонами (double sided polygons), одежда с более чем одним слоем или меши с большим количеством полигонов. В таких случаях для моделирования может быть использована отдельный меш (separate mesh). Если используется отдельный моделируемый меш (separate simulation mesh), то вершины этого меша моделируются имитацией ткани. Вершины исходного меша (original mesh) будут сопоставлены с моделируемым мешем (simulated mesh) и перемещаться вместе с ней.





На приведенных выше изображениях меши с правой стороны используются для моделирования, а левые визуализируются в соответствии с моделируемыми результатами. Для достижения реалистичных результатов ваш моделируемный меш (simulation mesh) должен плотно сопоставляться с мешем рендеринга и никогда не должен его перекрывать. Другими словами, меш рендеринга никогда не должен проникать в меш моделирования. Если это так, то, поскольку расчеты коллизий выполняются для моделирования меша, вы можете увидеть артефакты коллизии (simulation mesh), такие как проникновение ног в броню.

Cloth Editor (Редактор Ткани)


Чтобы включить имитацию ткани для мешей (cloth simulation for a mesh), необходимо настроить некоторые игровые настройки. Редактор ткани (Cloth Editor) используется для настройки мешей для моделирования. Редактор ткани можно открыть из меню панели инструментов в Редакторе ( toolbar menu in editor).



Preview properties (Свойства предварительного просмотра)


Preview mesh (Предварительный просмотр мешей) :

Чтобы начать работу с мешами, вы должны зайти в Preview mesh menu (меню предварительного просмотра мешей) и выбрать sub meshes, которые будут моделироваться на Render mesh cloth properties panel (панели свойств ткани Render mesh). Если альфа-каналы меша окрашены правильно, то он должна начать моделироваться в окне предварительного просмотра.

Simulation mesh (Моделируемый меш) :
Если вы хотите использовать отдельный Simulation mesh, выберите его в Simulation mesh menu (меню моделирования мешей). Альфа-канал этого меша также должен быть окрашен, потому что это фактически моделируемый меш. В этом случае альфа-канал Preview mesh (предварительного просмотра  мешей) используется для определения того, будет ли вершина отображена в меше моделирования или она будет визуализирована с исходными данными скининга (rendered with original skinning data).
Альфа-значения больше нуля означают, что вершина должна быть сопоставлена с моделируемым мешем.
Вершины с нулевыми альфа-значениями будут использовать исходные данные скининга.
Поскольку моделируемый меш (Simulation mesh) имеет меньшее количество полигонов, чем оригинальный меш, это может быть использовано для повышения качества скиннинга (skinning) оригинального меша для non-simulated parts (немоделированных деталей).

Helper mesh (Вспомогательный меш) :
Вы можете выбрать вспомогательный меш для предварительного просмотра фактического моделируемого меша с произвольным мешем. Хорошим примером является выбор меша лошади для моделирования меша гривы коня.

Preview skeleton (Предварительный просмотр скелета) :
Если вы хотите работать с skinned mesh и просматривать оболочки коллизий и анимации, вы должны выбрать соответствующий скелет.

Preview body (Предварительный просмотр тела) :
Вы можете назначить уже имеющееся collision body в меню Preview body. Модифицированная collision bodies может быть выполнена из Cloth Bodies panel.

Preview animation name (Предварительный просмотр анимации) :
Вы можете потестить свою ткань с помощью анимации. Вы должны будете написать его имя в папке asset, а не в animations*.xml, а также его начальные и конечные номера кадров и продолжительность. Вы можете запускать и останавливать анимацию с помощью кнопки Toggle Animation (переключения анимации).

Scene update coef (Коэффициент обновления сцены) :
Замедленное движение можно смоделировать, уменьшив это значение. Значение по умолчанию равно 1, что означает, что все моделирования выполняются с нормальной скоростью.

Render mesh cloth properties (Рендеринг свойств мешей ткани) :
Вы можете выбрать, какие submeshes будут моделироваться, установив флажок рядом с каждой submesh. Различные материалы ткани могут быть назначены каждой submesh  в графе Cloth material.
Коэффициент максимального расстояния (Max distance multiplier) используется для масштабирования вершин мешей (scale vertex color paintings), которая контролирует, сколько вершин может отойти от своей первоначальной позиции.
Значение 0.5 вершины альфа (vertex alpha) с максимальное значение коэффициента расстояния 3.0 означает, что вершина сдвинется на 1,5 единицы от своей первоначальной позиции.
Если вы используете раздельный моделируемый меш, то максимальное значение расстояния и материал ткани моделируемого меша отменяют эти настройки. Все сабмеши (submeshes) будут использовать один и тот же материал, назначенный для моделируемого меша.

Simulation mesh cloth properties (Свойства ткани моделируемого меша) :
Если вы используете отдельный моделируеый меш, вы можете настроить его параметры здесь так же, как и свойства мешей рендеринга (render mesh properties), упомянутые выше. Выбранный здесь материал ткани и максимальное значение расстояния будут использоваться для всех submeshes рендеринга.

ВАЖНО! Вы должны сохранить свои настройки, нажав кнопку Save mesh settings (Сохранить настройки мешей).


Collision Bodies (Коллизии)


Коллизии можно создавать и изменять в окне Collision bodies. Его можно открыть через Edit > Edit collision bodies.



Оболочка\капсула (capsule) состоит из двух конечных точек. С ними можно работать отдельно, назначив кости и вес. Одна точка оболочки\капсулы затрагивает не более чем две кости. Как и при скиннинге мешей, вес (weights) используются для определения влияния этой кости на выбранную капсулу.

Cloth materials (Материал ткани)


Все параметры моделирования для настройки поведения ткани поставляются вместе с материалами тканей. Пресеты\настройки материалов ткани можно создавать и изменять в окне Material templates (Шаблоны материалов).



Это окно можно открыть в меню Edit (Правка) > Edit merial templates (Правка шаблонов материала). Материалы, показанные в этом окне, являются пресетами, поэтому изменение этих пресетов не влияет на конфигурацию существующих мешей ткани. Чтобы изменить параметры существующего меша ткани, вы можете нажать кнопку Change parameters (Изменить параметры) на панелях Simulation/Render mesh cloth properties (Моделирование/рендеринг свойств мешей) и настроить все параметры в окне Mesh specific parameters (конкретных параметров меша).





Эти конкретные параметры меша следующие :
Bending (Изгиб)
Stretching (Растяжение)
Shearing (Смещение)
Stiffness (Жесткость)

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

Anchor Stiffness (Жесткость) :
Этот параметр строго ограничивает свободу вершины (vertex). Он пытается поддерживать постоянные расстояния между моделируемыми и фиксированными вершинами. Вы можете попытаться увеличить это значение, если ваша сетка растягивается слишком сильно.

Damping (Затухание) :
Значения амортизации для вершин. Определяет долю скорости текущего кадра (frame) для перехода к следующему кадру.

Linear Inertia (Линейная инерция) :
Поскольку ваша моделируемая ткань выполняется в локальном пространстве, глобальные изменения кадра переносятся на ткань виртуально. Это значение определяет, какая часть ускорения объекта будет перенесена на ткань. Вы можете проверить это, добавив меш ткани в сцену и случайным образом потрясти ее сущность.

Air drag (Сопротивление воздуха) :
Для меша ткани, движущегося с постоянной скоростью, это значение определяет, насколько сильно сила сопротивления воздуха будет воздействовать на ее вершины.

Wind (Ветер) :
Вы можете контролировать, сколько силы ветра будет использовать ткань. Это значение является множителем для фактической силы ветра сцены. Если в сцене нет ветра, то увеличение этого значения не будет иметь никакого эффекта.

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

Iteration Frequency (Частота повторения) :
Определяет сколько раз меш ткани будет смоделирован за секунду. Вы можете оставить этот параметр со значением по умолчанию, если только ваш меш не имеет больших треугольников или он не движется так быстро, что капсулы коллизий (collision capsules) не смогут поймать смоделированные вершины. Увеличение этого значения приводит к более стабильному поведению при коллизиях, но производительность удара также линейно возрастает.

Precise Simulation (Точность моделированя) :
Мы меняем качество на производительность в игре, делая некоторые сжатия во время моделирования. В результате моделируемый меш может немного перейти в другое состояние, чем был в состоянии покоя. Если эта точность важна для вашего меша, вы можете включить эту опцию, чтобы получить более правильные качественные результаты.

Dummy Collision Particles (Фиктивные частицы коллизий) :
Если моделируемый меш имеет большие размеры треугольников по отношению к капсулам коллизий (collision capsules), капсулы могут не сталкиваться с мешем ткани должным образом. Чтобы преодолеть это, мы помещаем фиктивные вершины (dummy vertices) в каждый треугольник меша. Эти вершины не моделируются, а используются только на стадии коллизии. Эта опция наносит большой удар по производительности вашей системы компьютера, поэтому вам следует стараться избегать ее включения.

Cloth Content Files (Файлы контента тканей)


Наша система моделирования генерирует два файла с расширениями *.tcc и *.tcm. Файлы .tcc содержат предварительно обработанные данные, используемые при моделировании ткани, такие как индексы ограничений (constraint indices), длины ограничений (constraint lengths) и т. д. Файлы .tcm содержат данные преобразования мешей рендеринга в моделируемые меши. Вы должны сохранить оба этих файла в Plastic SCM, чтобы гарантировать, что никто не ждет завершения процесса их приготовления на этапе загрузки сцены. 

25
Автор: Alisacat007

Доступ к средству просмотра моделей можно получить из верхней строки Editor > Window > Show Model Viewer



На левой панели вы можете изменить атмосферу (Atmosphere), скрыть/показать землю ( hide/show ground) или добавить столько объектов, сколько захотите. Объекты могут быть либо людьми (Human), простыми мешами (Mesh) или чехлами\футлярами ??? (holster). Нажатие кнопки Добавить объект (Add Entity) откроет окно с моделями для выбора типа этого объекта.

         Transform (Преобразовывание) :

На этой панели можно задать местоположение, поворот и масштаб (Position, Rotation, and Scale) объектов.

         Animation (Анимация) :

На этой панели вы можете выбрать тип скелета и анимацию.
Вы также можете фильтровать анимации по их названию.
Система фильтрации (Filtering system) довольно сильна через весь движок, так что вы можете точно настроить свою фильтрацию.       

Примеры:
idle = будет фильтровать анимации, который содержит “idle”
.idle = будет фильтровать анимации, которая начинается с “idle”
idle. = будет фильтровать анимацию, которая заканчивается на “idle”
-idle =  будет фильтровать анимацию, которая не содержит “idle”

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

“idle -barmaid 2.” = будет фильтровать анимацию, которая содержит “idle”, и не содержит “barmaid”, а заканчивается на “2”. (например, “guard_idle_2”, который соответствует этому условию)
“idle hangout 7” = будет фильтровать анимацию, содержащую “idle”, “hangout” и “7”. (например “” anim_hangout_idle_7", который соответствует этому условию)

          Blend (Смешивание) :

 Вы также можете совмещать несколько анимаций с помощью панели смешивания (blend panel).

          Visual (Визуализация) :

С этой панели вы можете поместить любой mesh в любую часть человека, и вы можете выбрать пол (gender) этого человека.
hide body - спрятать тело.
hide hands - спрятать руки.
hide feet - спрятать ноги.

body parts (часть тела) - выбор меша для указанной части тела.



Страницы: [1] 2 3 ... 88

Список игр

Реестр других игр

Важное о модах

Наши моды
Русь 13 век
Мододельня
Форум модов
Обмен опытом

Блоги

111 блогов, 364 записей
Последние записи:

[23 Июль, 2019, 11:23]

[28 Март, 2019, 15:23]

[24 Октябрь, 2018, 10:44]

[22 Октябрь, 2018, 13:57]

[30 Август, 2018, 22:42]
Крупнейший сайт о стратегиях. Обзоры новинок.Активный ФОРУМ и встречи с разработчиками. Большая качалка МОДов для RTW и не только. Родной дом «Империи» и «Бонапарта». СиЧЪ Total War Все о Mount & Blade
Сайт "Всадники Кальрадии" не является СМИ. Администрация не несет ответственность за высказывания и публикацию каких-либо материалов, сделанные любыми пользователями форума, в том числе посредством личных и публичных сообщений. Материалы, размещенные на ресурсе третьими лицами, могут содержать информацию, не предназначенную для лиц, не достигнувших совершеннолетия. При обнаружении на ресурсе материалов, нарушающих законодательство Российской Федерации, необходимо обращаться к администрации.
Сайт работает на хостинге FASTVPS