Unity Playmaker | FSM на пальцах или как устроен Плеймекер
Чтобы делать полноценные игры без программирования с помощью Unity Playmaker нужно немного разобраться как он работает и почему концепция конечного автомата это чертовски удобно. Поэтому ловите небольшой туториал с разбором основного принципа создания игр без программирования в Unity.
FSM и с чем его едят.
FSM (ФСМ) — это то, с чем вам придется работать при создании игр с помощью Playmaker в Unity, если вы не хотите использовать классическое программирование. Проще говоря FSM это тот же самый скрипт, только визуальный.
FSM расшифровывается как Finite State Machine — вычислительная модель, описывающая автомат с конечным числом состояний, иногда можно встретить FSA как обозначение, но в плеймейкере такого нет. Почитать об истории этой вычислительной модели (которая к слову лежит в основе большинства техники, что вы используете) можно в англоязычной википедии.
Что такое FSM в Unity Playmaker? Это скрипт визуального программирования, суть которого заключается в определении возможных состояний объекта и связей между ними.
Как читать FSM в Playmaker
Разберем пример, как «читается» обычный FSM.
Состояние 1 (еще его называют стейт aka состояние автомата): на столе возникла булка с кремом и ждет пока её кто-нибудь съест. Сейчас булка находится в состоянии ожидания. С ней ничего не происходит кроме этого ожидания. Это её базовый, стартовый стейт.
Состояние 2: Кот подходит и слизывает крем. Проверяем что это за кот — наш или соседский. Если кот наш, то ничего не делаем, если кот соседский, то переходим в другое состояние.
Состояние 3: Мы знаем что к булке с кремом подходил кот, и что этот кот оказался соседским. Проверим на всякий случай какой был у булки крем, который слизал соседский кот — если крем был вкусный ванильный — то переходим в Состояние 4. Если же крем был из жмыха соплей умирающего дракона — то переходим в Состояние 5.
Состояние 4: Мы знаем, что соседский кот слизал с нашей булки ванильный крем, и поэтому единственное действие в этом состоянии — включить сирену на всю улицу, потому что никто кроме нашего собственного кота не может пробовать ванильный крем. Все. На этом сценарий заканчивается и мы слышим сирену.
Состояние 5: Соседский кот слизал ядовитый крем из жмыха соплей дракона, а значит единственное действие здесь — это отнять у кота одну его котячью жизнь.
Всё, сценарий работы ФСМ готов. В двух последних случаях, мы можем сослаться на первое состояние булки, чтобы она снова лежала на столе и ждала действий с собой, и тогда у нас будет возможность целых 9 раз дать коту слизать драконий жмых, прежде чем усатый отдаст концы.
Именно так работает визуальный скриптинг с помощью FSM в Unity Playmaker — мы навешиваем на объект компонент FSM и задаем состояния, в которых этот объект может пребывать, ссылаясь при этом на какие-либо сторонние объекты (к примеру мы можем проверить, является ли хозяином соседского кота конкретный человек).
FSM выполняется каждый игровой такт (или если быть точным — каждый фрейм) — это значит, что игра каждый фрейм проверяет у объекта его состояние, и если условия позволяют сменить это состояние — то тут же его меняет. Обычные скрипты также работают основываясь на игровых фреймах и ожидающие «событий».
Разберем на примере
Как уже было сказано, основная сущность внутри FSM в Unity Playmaker — это стейт, или же состояние. Но помимо этого есть еще не менее важная сущность — это Событие. Или если использовать привычное название — эвент.
Все ФСМ начинаются с базового события, которое называется START — это внешний эвент, если угодно — глобальный, который происходит как бы извне с объектом. Когда объект создается на сцене в Unity — у него инициируется событие Start и объект переходит в самое первое свое состояние. Обычно здесь указываются все стартовые параметры объекта например.
Событие это та сущность, которая определяет некое действие. Скажем, в приведенном примере, когда в первом состоянии булка дождалась кота и он лизнул булку — происходит Событие — Эвент — и оно инициирует новое состояние.
Как только условия в первом стейте выполнены — можно переходить следующему. Следующий стейт может реагировать на несколько событий, и в зависимости от выполненных условий в этом состоянии, он может переходить к разным состояниям.
Может получиться так, что этот объект, участвует в сценарии, который был инициирован где-то извне, и к этому объекту обращаются как бы извне — скажем, булку порезали на двое. В этом случае событие приходит извне, и объекту нужно на него отреагировать. Для этого можно задать внешний эвент в этом же FSM и тогда булка перейдет в новое состояние, отвечающее тому, чего требует условия извне.
Такие внешние события могут быть изолированными, а могут возвращать булку к исходному состоянию, с которого все начиналось — в нашем случае булка поделенная две части, продолжит ждать когда с нее слижут крем.
За счет понимания этого принципа и строится работа с FSM в Плеймейкере (да и где угодно)— именно так можно собирать любую игровую логику и создавать игры без программирования в Юнити используя только визуальный скриптинг. Количество связей между состояниями и самих состояний — неограниченное множество. Желающие пробовать эволюционно новый подход создания серьезных игр без программирования могут пошариться по ссылке в моём профиле и откопать бесплатную версию плеймейкера отлично подходящую для изучения основ и принципов.
Если знаю блюпринты, сложно будет разобраться?
не особо. Процесс немного отличается от блюпринтов насколько я знаю, но в целом логику понять очень быстро можно. Как только начинаешь рассуждать "игровыми кадрами" и состояниями - все очень быстро становится на свои места. Главное выкупить логику, что каждое состояние может давать какой-то результат или действие с игровым объектом (расчет позиции к примеру). К примеру есть действия которые можно отметить как Every Frame - тогда объект будет находиться в этом состоянии каждый кадр и дальше перейдет только при определенном условии (скажем мы делаем состояние у объекта в котором каждый кадр проверяем целочисленную переменную здоровья, не стала ли она равна 0. Если стала - то делаем переход объекта в новое состояние, и в новом состоянии уже запускаем проигрывание анимации смерти например).
А есть что-нибудь такое же для анрил энжин?
Blueprints же. Я с плеймейкера и болта перелез на принты довольно легко
увы нет( это писано с нуля на основе собственного разбора темы, а я адепт юнити, за анрил не шарю к сожалению
Но статья очень годная и понятная, спасибо
Ох, помнится в школьные годы, с чего то похожего и начался интерес к геймдеву - с редактора карт Warcraft III. Но кодом там можно было наворотить большего, чем просто подобной конструкторной визуализацией.