Pull to refresh

Comments 16

Спасибо за статью.
Сам uScript не юзал, не было возможности. Как для меня он немного деревянно выглядит (визуально), возможно потому, что я привык к Unreal Blueprints.
Я решил написать свой плагин по визуальному программированию в юнити по типу Unreal Blueprints.

На данный момент плагин закончен на 90% и содержит в себе:
Функций: 3993
Типов переменных: 428
Энумераторов: 125

В нем только функции и переменные самого юнити. еще нужно добавить с IO, Collections и т. д.
Над оптимизацией еще нужно будет поработать.
Скрин.
Видео. Тут показан визуальный реалтайм дебаг скрипта.
Свой плагин пока никому не показывал.

Эта тема для меня очень интересна, по этому хотелось бы обсудить.
Выглядит нереально круто, конечно! Но вот, например, мы бы такую штуку не взяли, для нас это слишком громоздко и сложно. По этой причине не взяли antares universe. Вы, кстати, его смотрели? Он, вроде, еще более функциональный нежели uScript.
Посмотрел. Судя по видео тоже самое что и uScript. (принцип тот же)
А можно в нескольких словах, какая принципиальная разница между Unreal Blueprints и uScript?
uScript это тупо копия Kismet из UDK (Unreal engine 3)
pctuning.tyden.cz/ilustrace3/ulm/udk7/image005.jpg
www.worldofleveldesign.com/categories/wold-members-tutorials/petebottomley/images/012-udk-quick-time-events-with-kismet-11-large.jpg

Если по визуальной части…
В Unreal Blueprints как-то все по человечески сделано, видно типы переменных сразу (по цветам), пины подключаются адекватно и наглядно, а не через задницу как у uScript / Kismet, сразу видно где идет линк последовательности (Sequence) нодов, а где данные подключаются… Ну что еще сказать можно…
Т.е. вас не устроил стоковый скриптинг Unity3D (C#), вы прикрутили свой на lua. И он тоже вас не устроил, ибо со временем кода получилось много, и посему вы решили прикрутить визуалку.Интересно вот что: когда у вас схемы перестанут помещаться в экран вы тоже что-то поверх налепите?
Не понимаю причин вашего сарказма.

Стоковый скриптинг не подходит. Скриптование квестов и т.п. — задача гейм-дизайнера. Гейм-дизайнер не должен лазить в код. Редактировать исходники игры для добавления нового квеста — однозначно неверное решение.

А то, что схемы не влезают в экран — тоже не проблема. Есть скроллинг и зуминг.
>>А то, что схемы не влезают в экран — тоже не проблема. Есть скроллинг и зуминг.

Скроллинг и зуминг вас почему-то не устроил при использовании lua. Я просто лишь продолжил мысль.
Нас не устроил не объем кода, а отсутствие наглядности и легкочитаемости.
В этом и была суть первого комментария — когда пропадёт наглядность и «легкочитаемость» блок-схем, поверх них тоже будет что-либо водружено?
Небольшой некропостинг, но меня заинтересовал тот же вопрос товарища 6opoDuJIo. С момента написания статьи прошло достаточно много времени, поэтому хотелось бы узнать насколько оправдал себя uScript с точки зрения представленных преимуществ? История с переходом Lua не повторилась (не перестали ли умещаться схемы на экран)?
Редактировать исходники игры для добавления нового квеста — однозначно неверное решение.
Так у вас же и так при добавлении нового квеста происходит перекомпиляция проекта. Но с тезисом согласен: гейм-дазайнер не должен лазить в код.
Что там происходит за пределами диаграммы, не суть важно. Важно именно то, что у ГД в руках инструмент со схемами и стрелочками и кодить он не лезет ;)
А итоговые код оно генерирует оптимальный? Или оверхед слишком мал, чтобы об этом задумываться?
Код… Скажем так, весьма обфусцированный =) Но с первого взгляда не очень громоздкий.

А вообще — тут совсем не имеет значения, ведь речь идет о скриптинге ивентов, а не об апдейте, который крутится каждый фрейм для каждого из 10 тыс. объектов. Так что оверхед тут абсолютно не важен.
Благодарю, может тоже присмотримся к инструменту. Для кат-сцен самое оно.
Sign up to leave a comment.

Articles