SC2GE
Добавлен Prot,
опубликован
SC2 - Редактор Объектов
Содержание:
Введение
Эта статья посвящена маленькому разделу – требованиям. Требования применяются во многих аспектах работы с редактором данных. Ими можно снабдить кнопки, способности, алгоритмы или эффекты, что позволит задать условия, при которых они будут работать.
Структура требований
Имя требования – название требования
Категории редактора - категория к которой принадлежит данное требование
Комментарий редактора, Название редактора, Описание редактора, Префикс редактора, Суффикс редактора – стандартные для многих объектов поля.
Требование + - поле, которое нас собственно и интересует – поле алгоритма работы требований.
Категории редактора - категория к которой принадлежит данное требование
Комментарий редактора, Название редактора, Описание редактора, Префикс редактора, Суффикс редактора – стандартные для многих объектов поля.
Требование + - поле, которое нас собственно и интересует – поле алгоритма работы требований.
Начнём с того, что данное поле может быть представлено в виде дерева или выражения.
Дерево является наглядным конструктором по типу триггеров и предназначено в первую очередь для новичков и для тех, кто незнаком с программированием. Давайте рассмотрим его для начала.
Дерево является наглядным конструктором по типу триггеров и предназначено в первую очередь для новичков и для тех, кто незнаком с программированием. Давайте рассмотрим его для начала.
В левом окне находится две основных категории – отобразить и использовать. Создатели игры используют категорию отобразить для задания условия отображения кнопок (когда их видно и когда не видно), а категорию использовать для задания условия работы кнопки, способности, алгоритма или эффекта.
В правой половине вы видите возможные типы условий, из которых и состоят требования. Одно требование может содержать условия, как отображения, так и использования, причём и там и там может быть по несколько условий.
Логические типы условий: больше, больше или равно, меньше, меньше или равно, равно, не равно, исключающее (или дивизион), модуль, сумма, нельзя, нечетное число и даже умножение.
Используя логические типы условий можно 2 и более условий объединить в одно логическое уравнение (или алгоритм кому как удобно называть)
Остальные типы условий можно разделить на 2 категории:
Остальные типы условий можно разделить на 2 категории:
1) Булевы типы условий: Единица разрешена, Разрешить алгоритм (алгоритм разрешен), Способность разрешена, Улучшение разрешено.
Данный тип проверяет, разрешено ли для игрока строительство/использование/изобретение заданной единицы/способности/улучшения. Естественно, этот параметр может быть только булевым, то есть либо «разрешено» либо «запрещено». После выбора данного типа у вас появится строка наименование, в которой вы можете выбрать проверяемый параметр: конкретную способность, улучшение, единицу или алгоритм.
Данный тип проверяет, разрешено ли для игрока строительство/использование/изобретение заданной единицы/способности/улучшения. Естественно, этот параметр может быть только булевым, то есть либо «разрешено» либо «запрещено». После выбора данного типа у вас появится строка наименование, в которой вы можете выбрать проверяемый параметр: конкретную способность, улучшение, единицу или алгоритм.
2) Реальные типы условий: Количество алгоритмов, Количество боевых единиц, Подсчет способностей (количество способностей), Улучшение количество (количество улучшений)
Данный тип требований проверяет, соответствует ли количество единиц/способностей/улучшений определённому значению.
Данный тип требований проверяет, соответствует ли количество единиц/способностей/улучшений определённому значению.
Состояния, в которых могут находиться условия:
В очереди – используется для всех типов контролируемых параметров, кроме алгоритма. Проверяется через способность единицы – очередь.
В процессе – создание, конструирование и производство. Для алгоритмов не применимо. То есть, эта проверка выполняется для игрока, игры или категории.
В процессе (боевая единица) – создание и т.п. Проверка осуществляется для конкретной единицы.
В процессе или лучше (боевая единица) – жутко кривой перевод скрывает за собой простую вещь – находится ли единица в процессе создания или создание уже выполнено. Возможно, я плохо искал, но мне не удалось найти ни одного работающего требования с таким условием (при этом созданный самостоятельно работает нормально).
Всего – служит для подсчета количества чего-либо в глобальном мире, например, количества зданий или уровней у героев.
Высшее значение – учитывается максимально возможное значение параметра.
Завершено – относится к улучшениям. Проверяет, завершено ли исследование данного улучшения. Может проверять наличие единиц или построек.
Завершено (единица) – аналогично предыдущему, но проверяет это для конкретной единицы. Используется с логическими условиями, имеет конкретные значения. То есть: уже выполнено, уже изучено, уже готово.
Следующая - проверяемый параметр поставлен в очередь постройки или изобретения.
Следующая (боевая единица) - то же самое, но в конкретной единице.
Следующая (боевая единица) - то же самое, но в конкретной единице.
Следующая или лучше (боевая единица) – проверяемый параметр поставлен в очередь или уже построен/изобретён в конкретной единице. Используется для проверки уровней способностей и улучшений.
Следующая или лучше – проверяемый параметр поставлен в очередь или уже построен/изобретён. Используется в основном для проверки улучшений.
Убит – проверяет жива ли единица.
Убито – количество убийств.
С этой формой может работать каждый. Она проста в усвоении и почти полностью совпадает с логикой триггеров как в Starcraft 2 так и в Warcraft 3.
Теперь рассмотрим более сложную форму:
Все значения остались прежними по своей сути, но поменяли свое местоположение.
Рассмотрим только верхнюю часть (нижняя аналогична).
После надписи Использовать – идет поле в которое вы сами (руками) или с помощью быстрых форм чуть ниже можете вводить необходимые для вас данные.
Клавиши быстрой вставки:
Алгоритм: && - «И», || - «ИЛИ», ! – «НЕ» (нельзя), $ - не чётное число
Сравнение: != - не равно, > - больше, < - меньше, >= - больше или равно, <= - меньше или равно, == - равно
Математика: + - «+», - - «-», % - модуль, / - дивизион, то есть деление.
Чуть ниже стоят уже рассмотренные нами типы, состояния и записи (значения).
Эта форма будет удобна для создания сложных многоуровневых требований.
Особо хочу заметить, что вы всегда можете переключиться на древовидную форму и посмотреть, тот ли результат вы получили, который записывали.
Еще говорят, что в данном поле можно использовать кастом скрипт, но я не проверял.
Эта форма будет удобна для создания сложных многоуровневых требований.
Особо хочу заметить, что вы всегда можете переключиться на древовидную форму и посмотреть, тот ли результат вы получили, который записывали.
Еще говорят, что в данном поле можно использовать кастом скрипт, но я не проверял.
Итак, мы разобрались с основными понятиями и структурой. Давайте перейдем к примерам.
Примеры использования требований.
Пример 1. Создание требования для отображения пассивной способности героя.
Мы рассмотрим 2 варианта создания такого требования.
1) С отображением неактивной иконки способности на панели команд с указанием требования.
2) С появлением только после изучения способности.
2) С появлением только после изучения способности.
Напомню – мы рассматриваем пассивную способность (просто так она у нас отображаться после выбора не будет)
Вариант 1
Создадим требование через команду меню правой клавиши *«добавить требование»* (или ctrl+=) с настройками: Расы - нет, технологии - нет. Имя и ИД - на ваш вкус.
Открываем поле Требование+
Наводим на значок папки Использовать и нажимаем правую мыши, выбираем Добавить узел требований
Наводим на значок папки Использовать и нажимаем правую мыши, выбираем Добавить узел требований
Нам нужно будет проверить количество изученных способностей, поэтому вершина айсберга - логическое больше или равно.
После того как мы создали логический узел требований, у нас появилась возможность добавить ещё один узел.
Так как способность у нас пассивная, то проверять мы будем количество Алгоритмов (все пассивки у нас алгоритмы). Алгоритм выбираем из тех, что идут в пассивные способности, состояние - Следующая или лучше (боевая единица).
Способность у нас уникальная и, поэтому сравнивать количество мы будем с константой, равной 1.
У вас должно было получиться вот это:
У вас должно было получиться вот это:
Или
CountBehavior(Rangeiattack,InProgressOrBetterAtUnit)[TechTreeCheat] >= 1А результатом наших действий в игре будет:
Вариант 2
Для упрощения вашей работы мы просто скопируем предыдущее требование.
Теперь в виде древа измените алгоритм (если мы говорим о другой пассивке), смените состояние на *завершено (боевая единица)* (хотя можете и не менять работать все равно будет).
Теперь в виде древа измените алгоритм (если мы говорим о другой пассивке), смените состояние на *завершено (боевая единица)* (хотя можете и не менять работать все равно будет).
Осталась самая малость, удалить больше или равно. А теперь, внимание, вопрос – как?
Сделать это в форме древа не получится (там можно удалить только комплекс целиком), переключитесь на вид выражение и измените
CountBehavior(Def3,CompleteOnlyAtUnit)[TechTreeCheat] >= 1На
CountBehavior(Def3,CompleteOnlyAtUnit)[TechTreeCheat] просто удалив сзади >= 1.
Сильно ли изменится внешний вид в игре? Видите на предыдущем скриншоте пустое место? После выбора способности он будет выглядеть так:
А до этого момента будет пустовать.
Ничего сложного.
Давайте перейдём на следующий уровень – создание Требования со многими условиями.
Ничего сложного.
Давайте перейдём на следующий уровень – создание Требования со многими условиями.
Пример 2. Требования со многими условиями. – Многоуровневая способность с пропуском уровней.
На зарубежных сайтах почему-то принято к каждому уровню добавлять алгоритм, который является проверкой к данному уровню (там ещё и валидаторы задействуют)
Мы сделаем проще и, на мой взгляд, красивее.
Мы сделаем проще и, на мой взгляд, красивее.
Дополнительно к алгоритмам показателей, которые влияют на героя введем 5й алгоритм – проверку уровня. Который так и будет называться уровень.
В алгоритме получения опыта мы за каждый уровень будем добавлять по 1-му алгоритму Level и таким образом на 3м уровне у нас будет уровень 3 и т.д. (не забываем что 5-ый показатель и вообще игроку не виден)
В алгоритме получения опыта мы за каждый уровень будем добавлять по 1-му алгоритму Level и таким образом на 3м уровне у нас будет уровень 3 и т.д. (не забываем что 5-ый показатель и вообще игроку не виден)
Давайте теперь пойдем от противного – создадим сначала сложное требование:
(CountBehavior(Heroabil,CompleteOnlyAtUnit)[TechTreeCheat] < 1 &&
CountBehavior(lev,CompleteOnly) == 1) ||
(CountBehavior(Heroabil,CompleteOnlyAtUnit)[TechTreeCheat] < 1 &&
CountBehavior(lev,CompleteOnly) == 3) ||
(CountBehavior(Heroabil,CompleteOnlyAtUnit)[TechTreeCheat] < 1 &&
CountBehavior(lev,CompleteOnly) == 5)Как это работает:
Если количество алгоритмов Heroabil < 1 (то есть способность не выучена) и Количество алгоритмов Lev == 1 (или 3 и 5), то способность можно выучить.
Вот так это будет выглядеть в виде дерева:
Если количество алгоритмов Heroabil < 1 (то есть способность не выучена) и Количество алгоритмов Lev == 1 (или 3 и 5), то способность можно выучить.
Вот так это будет выглядеть в виде дерева:
Можно сделать и по-другому, например – с пропуском одного уровня после изучения, но не более чем 3-го.
Тогда одна из наших строчек будет выглядеть вот так:
Тогда одна из наших строчек будет выглядеть вот так:
(CountBehavior(Heroabil,CompleteOnlyAtUnit)[TechTreeCheat] <
CountBehavior(lev,CompleteOnly) ) && CountBehavior(lev,CompleteOnly) > 3 &&
CountBehavior(Heroabil,CompleteOnlyAtUnit)[TechTreeCheat] < 1Цифры, естественно, заменить на нужные вам.
Ещё могу добавить, что требования можно использовать во всех объектах, у которых есть поле стоимость+ или поле требования (отдельно)
Ещё могу добавить, что требования можно использовать во всех объектах, у которых есть поле стоимость+ или поле требования (отдельно)
Требуйте и получайте! Удачи вам в игре и в Модинге.
Содержание
`
ОЖИДАНИЕ РЕКЛАМЫ...
Чтобы оставить комментарий, пожалуйста, войдите на сайт.
нет, вру, там в очереди или лучше.
Такой вопрос: а где писать (ручками на клаве) требованаие на вполне понятном игроку русском языке. Вроде бы это должно описываться в условиях дерева, но в статье об этом ни слова