В одній з попередніх публікацій я розповідав, що ми прикрутили до нашої гри мову Lua для скріптованія різних сценок. Однак, покористувавшись їм якийсь час, ми зрозуміли, що часом написання таких скриптів перетворюється в досить сложночітаемий і сложноотлажіваемий код.
Вступ. Отже, давайте для початку подивимося на те, що було. Нижче наведено реальний скрипт, який створює двох персонажів на екрані, який малює простенький діалог, що дає користувачеві вибір з 2х варіантів і розгалужених в цьому месте.Ісходнік LUA-скрипта vhs.HUD (0) vhs.SwitchZone ( «street») local c1 = CharacterGfx ( ) c1.create ( «c1», «char_big») c1.mirror (0) c1.setpos ( «n_2») c1.animate ( «f_idle»)
local c2 = CharacterGfx () c2.create ( «c2», «char_black») c2.mirror (1) c2.setpos ( «n_3») c2.animate ( «f_idle») c2.preset ( «opp_lmb»)
char.animate ( «idle») char.mirror (1) char.setpos ( «n_1»)
c1.say ( «I need your clothes, your boots and your motocycle») c1.wait_bubble () c2.say ( «Yep!») c2.wait_bubble ()
char.animate ( «f_idle») char.mirror (0)
vhs.ShowMultiAnswer ( «Try to catch me! (run away)», «No way! (start fight)», ») switch_answer case 2: vhs.StartFight (77,7) end,> В грі це виглядає так: 
Саме в такий момент нам гостро захотілося візуалізації.
Давайте відразу наведу скрін того, у що перетворився вищенаведений LUA-скрипт. (Картинка клікабельні)
Виглядає трохи громіздко, але зате відразу наочно. Коли, хто і де створюється, що робить, а головне видно розгалуження.
Ось, наприклад, в нашому випадку гравець може вибрати 1 відповідь з двох можливих. У грі це виглядає так:
А на схемі - так:
І відразу видно, що станеться при виборі відповіді №1 і відповіді №2. А якщо таких розгалужень буде більше - то тим більше схема не втратить наочності.
Принципи uScript. Давайте швидко пробіжить по тому, з чого складається схема. Власне, основні модулі (в термінології uScript вони називаються «nodes») - це подія (з нього зазвичай починається скрипт або ланцюжок), action і змінні.
У action'он є вхід (зазвичай 1) і вихід (и). Наприклад, у самого простого дії 1 вхід і 1 вихід. А у будь-нитка блоку умови - вже буде два виходи, наприклад.
Знизу блоку підключаються змінні. Трикутник означає, що в змінну буде зроблено запис (output).
Наприклад, в цьому прикладі ми створюємо персонажа (за допомогою блоку «Create char»), а потім виставляємо йому ж дзеркальність в «true» (за допомогою блоку «Mirror»):
До речі, всі змінні можуть мати назви (в нашому випадку «з1»). І все змінні одного типу з однаковою назвою будуть синхронізовані в межах одного скрипта (схеми). Тобто приклад вище абсолютно ідентичний такому:
Зроблено це щоб позбавити вас від необхідності тягти зв'язку через два екрани.
Крім того, якщо поставити галочку «expose to Unity», обрана змінна стане public і буде видно іншим скриптам (як візуальним, так і вашим рукописним). Масиви так само підтримуються.
Трохи практики. Всі модулі, які ви бачите на схемі - самописние. І були написані за 1 вечір. Давайте подивимося на їх код.Рассмотрім спочатку що-небудь дуже просте. Наприклад, action, який називається «Start fight». Він починає бій (по суті, викликає метод ігрової логіки) і приймає два параметри - айдішнік бою і айдішнік суперника.
Справа ви можете бачити блок з конфігурацією блоку, куди ви вбиваєте значення. У блоку 3 вхідних параметра - CharacterGfx (безпосередньо персонаж, якого ми програємо анімацію), Animation (назва анімації) і Mirror (необхідність зеркаленья). І у блоку є два виходи: Out (вихід відразу ж) і Finished (тільки коли анімація закінчиться).
При цьому змінна «Mirror» є енумератором з параметрами «так», «ні» і «не змінювати», яка подається у вигляді dropdown-списку у вікні властивостей.
Код особливо складніше не став:
using uScriptEventHandler = uScript_GameObject.uScriptEventHandler;
[FriendlyName ( «Finished»)] public event uScriptEventHandler Finished;
public enum BooleanSet ch.PlayAnimation (anim_name); if (mirror! = BooleanSet.NoChange) ch.SetMirror (mirror == BooleanSet.True); ch.OnAnimationEndedCallback + = () => Робиться це так само просто. замість рядки public bool Out if (Out! = null) Out (this, new System.EventArgs ()); Не обов'язково писати код самому. Все, що я привів вище - було написано нами, щоб зібрати все, що потрібно в одне зручне місце. Але це часто не обов'язково. У uScript є така річ, яка називається «reflection». На ділі це означає, що uScript автоматично сканує вашу сцену і витягує з неї всі об'єкти, а так само їх публічні методи і параметри, до яких може дотягнутися. І надає до них доступ.Напрімер, ось так виглядає блок-reflection на метод GetComponent () камери на сцені:
(Внизу ви можете бачити блок «properties», де задаються всі параметри методу)
Висновки. Тулза нам однозначно сподобалася і ми будемо юзати її далі. Взагалі, деякі люди примудряються за допомогою неї писати цілі гри, але це вже через чур.Насколько глибоко ми зможемо її заюзать поки не знаємо. Наприклад, ще не вирішили, переписувати чи логіку тригерів квестів з нашої lua-орієнтованої на візуальну.
Але ось для скріптованія кат-сцен і діалогів будемо юзати однозначно.
З мінусів можу виділити тільки один (який є наслідком плюса) - як я писав вище, uScript перетворює візуальні схеми в C # код. А отже кожна модифікація схеми зажадає перекомпіляції проекту.
В іншому - дуже раджу придивитися до цього інструменту, якщо ви хочете скріптовать подібну логіку. Так само, наскільки я знаю, цей інструмент активно використовують для написання AI.
До речі, якщо вам потрібна саме для скріптованія поведінки і взаємодії об'єктів на сцені (наприклад, тригери на зіткнення і т.п.), то придивіться до PlayMaker. Він більше орієнтований саме на подієву модель.
Всі статті серії:
Ідея, Вижен, вибір сеттинга, платформи, моделі поширення тощо Шейдери для стилізації картинки під ЕПТ / LCD Прикручуємо скриптова мова до Unity (UniLua) Шейдер для fade in по палітрі (а-ля NES) Проміжний підсумок (прототип) Поговоримо про піарі інді ігор 2D-анімації в Unity ( «як у флеші») Візуальне скріптованія кат-сцен в Unity (uScript)