Визуальные сценарии против кодирования

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

другая вещь — это просто обычное кодирование, например, написание кода на C ++ в IDE
теперь я попробовал их обоих, но вопрос, который я пытался выяснить, заключается в том,
так как я попробовал оба из них, кажется, что визуальные сценарии стали проще и понятнее, по крайней мере, для меня, я чувствую, что имеет смысл, когда я соединяю узлы, сравнивая их с тем, когда я пишу код, что-то вроде «Контроллер плеера» Сколько времени мне понадобилось, чтобы написать вражеский контроллер!
написание кода для контроллера плеера в с ++ заняло у меня около 2 часов
в то время как мне потребовалось всего один час, чтобы соединить узлы, чтобы сделать контроллер плеера с использованием визуальных сценариев, но хотя это был простой и быстрый процесс, я не чувствовал себя хорошо, и начал больше думать о том, что будет преимуществом писать код на C ++, а не просто соединять узлы?
так вот вопрос:
Каковы преимущества написания кода?
Каковы преимущества использования визуального скрипта?
Каковы недостатки их обоих?
я знаю это
Преимущества Visual Scripting не так сложны, как написание кода на C ++

Также будет писать код быстрее, чем «уже созданные сценарии» (Visual Scripts)

Последний вопрос, если вам придется выбирать между тем, что вы бы выбрали Visual или писать код?

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

Надеюсь, на этот раз я не задавал «плохих» вопросов, которые приведут к слишком большому количеству отрицательных голосов 🙂 для меня это просто День благодарения;)

Обновить:
Вот еще немного информации о визуальных сценариях, которые я использую в движке Unreal. Я получил его с сайта Unreal Engine.
«Система визуальных сценариев Blueprints в Unreal Engine представляет собой законченную систему сценариев игрового процесса, основанную на концепции использования интерфейса на основе узлов для создания элементов игрового процесса из редактора Unreal. Эта система чрезвычайно гибкая и мощная, поскольку она позволяет дизайнерам использовать практически весь спектр концепций и инструментов, обычно доступных только программистам.
Используя Blueprints, дизайнеры могут создавать прототипы, реализовывать или изменять практически любой элемент игрового процесса, такой как:
Игры — настройка правил игры, настройка условий игры и т. Д.
Игроки — создавайте варианты с разными сетками и материалами или настройкой персонажа.
Камеры — создайте прототип новой камеры или динамически меняйте камеру во время игры.
Ввод — измените управление игроками или разрешите игрокам передавать ввод на предметы
Предметы — оружие, заклинания, пикапы, триггеры и т. Д.
Среды — создавайте рандомизированные реквизиты или процедурно сгенерированные предметы.
«Я не думаю, что есть такая вещь, как если вам нужно сделать что-то сложное, вам нужно написать код для этого (мое мнение)

3

Решение

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

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

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

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

7

Другие решения

Визуальные сценарии часто используются во многих игровых движках, таких как Unity, Construct 2, Unreal Engine и т. Д.

Это почему? Потому что это намного проще.
Код, написанный на VS, легче понять, часто один узел может заменить 100 строк нормального кода.
Чтобы добавить к этому, это намного более понятно, легче понять, что происходит.
Что еще более важно, это легко учиться, так что человек с небольшими знаниями может реально использовать его.
За такими сценариями происходит множество вещей, и вам на самом деле не нужно знать, что происходит, чтобы их использовать.

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

Например, в некоторых движках вы можете просто написать Player Jump или что-то вроде этого, и вам все равно, как это происходит, вам даже не нужно знать механику игры, механику физики и т. Д.

Если бы мне пришлось выбрать один, я бы выбрал в зависимости от проекта. Это тот же вопрос, что и:
Если бы вы могли создать игру в Game Engine или создать ее с нуля с помощью кода, какую бы вы выбрали?

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

Итак, Adv / Disadv:

VS:
+ Быстрое развитие
+ Простота в обслуживании
+ Легко обучаема
+ Легко работать в команде
+ Часто портативный
+ Спрятано много вещей, о которых вам не нужно заботиться
+ Гораздо понятнее
+ Часто не содержит «ошибок кода»
+ Неуклюжий (вы не забудете эту точку с запятой)
— Недостаток гибкости
— Вы действительно не знаете, что происходит
— Вы узнаете, как решить проблему, но не сможете сделать это вне конкретного движка.
— Часто намного медленнее, чем код
— Вы не можете делать обновления производительности
— Зависит от двигателя (каждый использует другой способ кодирования)
— Вы должны узнать, как работает каждый двигатель
— Если есть ошибка двигателя, вы не можете исправить, вы должны ждать патча
— Им часто платят, или у них нет возможностей
— Ах да, ограниченные возможности

Код:
+ Позволяет вам узнать, как на самом деле сделать что-то
+ Дать вам больше возможностей
+ Если вы научитесь кодировать, вы можете написать что угодно
(если вы изучаете скриптинг движка, вы ограничены им, вы не будете писать никаких других приложений, кроме игры)
+ В основном без ограничений (за исключением технических вещей)
+ Если вы выучите 1 язык, то гораздо проще понять любой другой современный язык.
+ Вы на самом деле контролировать то, что происходит
+ Дает вам истинные знания о том, как писать алгоритмы и программные вещи
+ Кодекс не зависит от компаний
+ Большинство вещей бесплатно
+ Это может быть НАМНОГО быстрее, чем скриптинг
— Труднее учить продвинутые вещи
— Сложнее поддерживать большие проекты
— Вы можете быть неуклюжим и уничтожать вещи
— Часто трудно понять другим
— Не так ясно, как визуальные сценарии
— В какой-то момент его трудно поддерживать
— Много платформенно-зависимых вещей
— Чтобы действительно что-то делать, нужно выучить довольно приличное количество вещей.

Выбор действительно зависит от ситуации, компании, предпочтений команды, сроков, платформы, целей и т. Д.

Я надеюсь, что вроде как разобрался с тобой :).

5

«Визуальное программирование» не является ни «новой» концепцией, ни новостью в программировании игр.

Это также очень широкое понятие: идея «визуального программирования» имеет множество применений во многих различных областях.

Вы упомянули «программирование игр». Другое — это «образование». Например:

Час кода: кодирование с Анной и Эльзой

3
По вопросам рекламы [email protected]