{"id":3824,"url":"\/distributions\/3824\/click?bit=1&hash=a0d33ab5520cacbcd921c07a49fc8ac5b78623b57936b992ce15c804b99210d4","title":"\u041a\u0430\u043a\u0443\u044e \u0440\u0435\u043a\u043b\u0430\u043c\u0443 \u043c\u043e\u0436\u043d\u043e \u0434\u0430\u0442\u044c \u043d\u0430 DTF \u0438 \u043a\u0442\u043e \u0435\u0451 \u0443\u0432\u0438\u0434\u0438\u0442","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c","imageUuid":"75ec9ef4-cad0-549d-bbed-1482dc44e8ee","isPaidAndBannersEnabled":false}
Инди
Andrew Fa

SETI | FPS Квест на Unity без кода - пост #5

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

Вводные

За плечами N лет в разного рода конструкторах и редакторах игр, в которых конструирование игровой логики сводилось к базовыми триггерам и событийным конструкциям из условных операторов. Начиная от VHE, WC3 WorldEditor и заканчивая Gamemaker и Construct 2. Кроме того - сомнительного качества бэкграунд кодинга на Delphi всяких патчеров и генераторов, двухнедельное увлечение питоном для написания телеграм-бота, ну и по мелочи веб-опыт в верстке и JS без каких-либо твердых вообще примеров.

Попытки начать что-то делать на Юнити как на 3d движке были неоднократные и ранее, однако каждый раз они упирались в необходимость что-то кодить. Сишарп мне не поддавался и каждый раз подход срывался. В какой-то момент я написал "клевый" эмбиент трек который спровоцировал меня еще раз попробовать ворваться в юнити, сделав простой квест бродилку с минимальным набором игровых механик - я тогда плотно сидел на всяких индиквестах накаченных с итча. В итоге появилась заготовка игрового мира, которая настолько лаконично получилась, что стало интересно - а получится ли без кодера со стороны довести её до ума, и не бросить. Я догадывался, что это возможно, но не знал как именно.

Я стал искать решения и нашел.

Playmaker

Я знал про блюпринт-системы и ранее, и уже сталкивался с ними где-то, но понял ничерта на тот момент. Кажется это был Godot.

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

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

По сути плеймейкер - это Finite-state machine, то есть модель конечного автомата(алгоритма), выполняемого при заданных условиях.

Если вы привыкли к работе с условными операторами и циклами, то использование системы конечных автоматов будет первое время для вас непривычно, потому что придется привыкнуть делению событий на составные части, так называемые "состояния". Суть их работы тоже можно описать структурой "если-то-иначе", но fsm - менее линейно на мой взгляд.

Разберу на примере.

Есть объект - записка. Или письмо какое-нибудь. Мы хотим дать игроку возможность прочитать его. Для игрока мы создаем автомат (fsm триггер, их у объекта может быть N штук). Дальше строим логическое рассуждение на языке автомата.

Нам нужно отследить событие, что игрок начал взаимодействие с предметом - с запиской. Для этого определяем событие в рамках нашего триггера, говоря как бы автомату "ждем, когда игрок нажмет клавишу E." Если это событие происходит, мы должны сообщить автомату, что состояние покоя завершилось и нужно перейти в другое состояние. Для этого используем отправку события "FINISHED".

Первое состояние автомата

После этого, игрок (не записка!) переходит в новое "состояние" - в новом состоянии нам нужно проверить, что происходит перед игроком, с чем он пытается взаимодействовать. Для этого используется метод Raycast.

Что такое рэйкаст - это когда мы "стреляем" лучом, который позволяет нам определить несколько параметров объекта, с которым он столкнется. Это некий невидимый проверочный луч.

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

Второе состояние автомата

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

Небольшая ремарка - данная логика не претендует на однозначность в плане эргономики: кто то может решить что в одном fsm с таким успехом можно было описать все взаимодействия с объектами после нажатия E. Да, можно. Но управлять и исправлять такую обросшую конструкцию менее эргономично на мой взгляд.

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

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

Третье состояние автомата

Четвертое состояние в моем случае - проверка языка игры. В глобальной переменной я храню строковое значение - RU или EN, и в зависимости от этого показываю результат на нужном языке. Логика простая - "Если строка глобальной переменной LANGUAGE равна RU то запускаем событие RUSSIAN, если нет, то запускаем событие ENGLISH."

Четвертое состояние автомата

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

На выходе мы получаем к этому моменту следующее - когда игрок нажимает Е наведя на объект с определенным названием, его обездвиживает и показывает записку.

Пятое состояние автомата

Теперь нужно сделать закрывание записки, когда мы еще раз нажали Е. Для этого у нас последним действием стоит ожидание нажатия Е, и если оно происходит мы переносимся по событию "CLOSE letters" в новое состояние, где собственно и закрываем отображаемое в канвасе письмо, возвращаем подвижность стандартному контроллеру игрока, и завершаем работу автомата, ссылая его на самое первое состояние.

Последнее состояние автомата

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

Тут случайный затекстуренный куб в виде письма)

Вариантов исполнения этой логики такими автоматами уйма, зависит от желания.

Если интересно будет, потом расскажу еще про какую-нибудь логику, реализованную через Playmaker FSM, на данный момент есть логики:

1) Открывания дверей на петлях (на заглавном скрине)

2) Кодовый замок для 6 значных кодов

3) Перетаскивание предметов с места на место

4) "Чтение" входящих сообщений\

5) Подсчет собранных предметов

6) Показатель запаса здоровья с регенерацией (и хромающей системой урона от падения).

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

0
30 комментариев
Написать комментарий...
A Kord

А по производительности как, нужен  топовый процессор? )

Все эти FSM на тыкательных мышкой механиках генерируют на полпроекта тяжелого мусора с рефлексиями, lua-парсерами-интерпретаторами и прочим, после чего игра утопает в бесконечных сборках мусора и неоптимизрованных миллионах Update.

Ответить
Развернуть ветку
Andrew Fa
Автор

пока никаких просадок фпс и лагов связанных именно с игровой логикой не заметил. Контроллер игрока использую стандартный, все остальное во многом событийное и разовое. Я собираю проект на "не игровом" ноутбуке, поэтому все лаги вижу очень очень быстро)
Да, скорее всего мусорные вещи есть, но это точно чище, чем если бы я сам говнокодил, надирая из интернета куски кода.)

Ответить
Развернуть ветку
Distortion

А Bolt пробовал? Unity не так давно купили его, теперь он полностью бесплатен и скоро должна выйти вторая версия, вроде всё с нуля перепишут для большей производительности, но заново переучиваться не нужно будет.

(Извиняюсь, если не совсем по теме написал, т. к. в геймдеве плохо шарю, но иногда пытаюсь разобраться.)

Ответить
Развернуть ветку
Andrew Fa
Автор

Неа, честно говоря не пробовал, хотя на глаза он мне попадался. 
Но если юнити его купили, они вероятно сделали ход конем в пользу преимущества конкуренции с ue4…

Ответить
Развернуть ветку
Andrey Popov

А почему тогда в итоге не unreal engine? в его основе же bluepint'ы - визуальное программирование. В то время как Unity внедрили playmaker задним числом, костыльно. Я помню, как он еще 3 года назад был просто сторонним ассетом.

Ответить
Развернуть ветку
Andrew Fa
Автор

он и сейчас сторонний ассет, они купили Bolt. Я почему то проспал этот момент, и уже стартанул с плеймейкером.
А не UE - там ниже чуть описал причины, но основные - это "незнакомость" среды разработки и недостаток мощностей железа. Юнити оказался с меньшим порогом входа, да и в нем всякого неизвестного еще хватает. 

Ответить
Развернуть ветку
123

А в чем смысл делать игру на unity, на визуальном скриптинге, когда есть движок, где эта система с 2014 года и реализована в разы лучше и который впринципе лучше? Если ты планируешь устраиваться в студию, то учи C#, на визуальном программировании ни одна студия игры не делает, а если ты для себя, то советую попробовать перейти на анрил  

Ответить
Развернуть ветку
Distortion

На визуальном делают, Blueprints в UE уже стали ходовыми в игровых студиях. Точно помню, что какая-то успешная VR игра была полностью на нём разработана и только ей дело не ограничивается. Поэтому Unity и подсуетились, выкупив разработчиков Bolt с потрохами – т. к. в будущем это неизбежно станет стандартом.

Ответить
Развернуть ветку
Andrew Fa
Автор

причин уйма.
1) объективно слабое железо.
2) графоний не преследую.
3) тонны бесплатного контента и понятная простая структура и иерархия его использования.
4) субъективная понятность именно этого движка ввиду определенного раннего знакомства с ним.
5) тонны туторов на любой вкус и цвет.
6) навык самостоятельного генерирования контента для именно этого движка
7) удобный и понятный плеймейкер
8) так склалось

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

Ответить
Развернуть ветку
Андрей Торчинский
 попадая в это состояние мы получаем имя объекта с которым взаимодействовали (все записки в игре у нас уникальные, и имена потому у них как у игровых объектов могут быть уникальными) и пишем его в переменную.
 Второй шаг - сравнение переменной с определенным названием. Если совпадает - идем в 4-ое состояние

Долго пытался понять зачем так сделано, но так и не понял. Обращаться к объекту по его имени это очень плохая практика и верный путь выстрелить себе в ногу.

По хорошему на каждой записке должен быть компонент, который хранит в себе содержание это записки. При попадании луча проверяется наличие компонента и если он есть, то говоришь ему «покажи мне содержание». И тогда ты по настоящему отвязан от объекта записки, тебе не важно как его зовут и был ли он недавно переименован.

И это мы ещё не говорим о том, чтобы всем запискам назначить отдельный слой и делать рейкаст только по этому слою, чтобы «не задевать» другие объекты и не делать лишние проверки.

В общем, автор молодец, что делится своими наработками и советами, но пока что советы по факту вредные.

Ответить
Развернуть ветку
Andrew Fa
Автор

"на каждой записке должен быть компонент"

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

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

Касательно вредности советов - не претендую совершенно на их однозначность, и уповаю исключительно на то, что описанная схема выполняет требуемую задачу. Да и в целом советы не раздаю, пост исключительно про начинку поделки, которую делаю, будучи полностью несведущим в программировании.

Ответить
Развернуть ветку
Андрей Торчинский
я стараюсь делать максимально масштабируемую логику

Именно поэтому жесткая привязка к имени объекта крайне плохое решение.

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

Нужен всего лишь 1 слой, условно "TextNotes". У всех записок будет один и тот же слой. При рейкасте указываешь, что луч должен учитывать только объекты на слое "TextNotes", всё.

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

Потому что Playmaker сильно ограничен в функционале. Он может идти как дополнение, которое облегчает работу конкретно с FSM, но всю логику ты на нем сделаешь, либо придется городить костыли типа проверки имени объекта. Если хочется нечто более похожее на блюпринты, то лучше бери Bolt, который теперь является встроенным пэкэджем и называется Visual Scripting. 

Ответить
Развернуть ветку
Andrew Fa
Автор

Теперь понял, спасибо

Ответить
Развернуть ветку
Izzi_99

Забавно, настолько иногда совпадают статьи с текущими делами) Я лично пытаюсь пока совсем простую логику собрать, из объект-действие-субъект, с вручную прописанными последствиями. Получается туго.

Ответить
Развернуть ветку
Andrew Fa
Автор

если расскажешь чуть подробнее что не получается, возможно смогу чего-то подсказать)

Ответить
Развернуть ветку
Izzi_99

Спасибо! Но я это делаю на Jave больше для изучения языка, чем для результата) 

Ответить
Развернуть ветку
Кибераслан Синглтон

реально интересно

Ответить
Развернуть ветку
Вадим Виноградов

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

Ответить
Развернуть ветку
Andrew Fa
Автор

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

Ответить
Развернуть ветку
Вадим Виноградов

А без порно за один вечер справился бы 
(¬‿¬ )

Ответить
Развернуть ветку
Andrey Popov

Нихрена не сложнее. Я сколько не пробовал программирование - как китайский изучать, честное слово. А на Clickteam с визуальным программированием игру спокойно сделал. И дальше планирую переходить на другие движки виз. программирования - Construct 3, например, мне понравился.
По мне языки программирования - это устаревший способ общения с компьютером. Точно также, как мы сейчас не используем перфокарты. Визуальное программирование удобней, это следующий шаг в создании программ и контента. В идеале через несколько десятков лет компьютеру можно будет давать голосом просто вводные данные, обрабатываемые нейросетью:
"сделай мне базовый платформер; так, а теперь, чтобы можно было отпрыгивать от стен; хорошо, но ограничь количество отпрыгов максимум двумя; отлично, давай добавим врагов, возьми анимации из вот этой папки; хорошо, враги погибают при напрыгивании на них героем сверху; а сделай-ка для ног главного героя IK"

Тогда создание игры как таковой полностью уйдет из поля "надо долго учиться" в "борьба идей и дизайна, а не навыков и возможностей".

Ответить
Развернуть ветку
Andrew Fa
Автор

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

Впрочем это вечный спор. Я вот сутки сейчас потратил чтобы разобраться как сделать на визуалке независимо открывающиеся двери. Как бы простая задачка, но думание никто не отменял совсем.)

Ответить
Развернуть ветку
Andrey Popov

Ну так не надо пиратить. Если мы как разработчики хотим получать хорошую поддержку движка - надо за неё заплатить. 1 раз 100$ в год заплатить за движок - не проблема. А то тот же Clickteam Fusion 2.5 не только не развивается, но даже баги фиксит с большим трудом через много месяцев может быть (если повезет). А всё потому, что у них модель монетизации движка - купил один раз и всё. Вот только пик продаж кликтима прошел лет 15-20. И у разработчиков тупо нет денег содержать команду программистов. Я уж лучше заплачу 100$, но буду знать, что всё работает, на любой баг мне тут же ответят, всё удобно, а новые фичи добавляются каждый месяц и хорошо работают друг с другом

Ответить
Развернуть ветку
Alexandre Varsteiner

Когда начинал юнити тоже пользовался плеймейкером. Не забудь что тебе надо писать ещё UI. Впрочем для него рекомендовал бы Doozy UI.
Но я с плеймекером провозился где то полгода, а потом был uscript, потому что ребята, которые сделали punch club, сказали, что сделали игру на нем. И после него понял, что мне посредники не нужны и начал писать код на c#.
Было криво косо, но все равно шустрее чем плеймейкер. А потом и с ним более менее разобрался. Сначала понимаешь синтаксис, а там может и к архитектуре подберешься.
Вообщем удачи с изучением.

Ответить
Развернуть ветку
Andrew Fa
Автор

про писать UI еще не понял, но за наводку спасибо большое, покурю что это и для чего. Пока что UI собрал на канвасе и плеймейкере.
uscript тоже рассматривал, но решил бдсмить по взрослому и потому остановился на плеймейкере.
Шарп несколько раз пробовал осваивать, курил уроки, писал какие-то пробные скрипты - но так как мыслю абстрактно, а не математически, изучение шло туже, чем проститутка без смазки. Потому решил что все знать невозможно, и решил идти нетривиальным путем.

Ответить
Развернуть ветку
Alexandre Varsteiner

Вот я о том, что собирать UI на плеймекере ещё то удовольствие. Как бы его собрать на коде, что делается быстрее и проще и то весело. А на плеймекере, ух.
В целом о том и говорю, что после практики на плеймекере, программирование на других средствах станет более понятно.
Чтобы в код въехать надо время.

Ответить
Развернуть ветку
Andrew Fa
Автор

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

Ответить
Развернуть ветку
Grim Ork

Моя первая игра, Sento Stream сделана была на Unity 5.3 и этом самом Playmaker. 
Ничего плохого про производительность и оптимизацию сказать не могу. Но вот архитектура проекта получилась лапшой, из-за чего разработка заняла больше года.
На каждый предмет приходилось собирать свою FSM, а вот если бы скриптами, то просто добавлял бы компоненты с поведением с сэкономил бы кучу времени.

Ответить
Развернуть ветку
Andrew Fa
Автор

да, я уже начинаю понимать что надо заранее всю архитектуру хорошенько продумать, чтобы не встрять потом.
Решил префабить какие-то общие вещи сразу с FSM, типа открывающихся дверей и тд.

Ответить
Развернуть ветку
Grim Ork

Да, без этого никак. 
В принципе, каждая отдельная FSM и является компонентом, поэтому можно кое-как рабочую архитектуру собрать. Там еще вроде FSM-шаблоны были для решения проблемы недостаточной абстрактности блюпринтов.
Просто с обычными скриптами намного больше способов наладить взаимодействие между разными объектами. А вот в блюпринтах даже банально событие с несколькими параметрами разных типов сделать очень сложно.

Ответить
Развернуть ветку
Читать все 30 комментариев
null