Visual Scripting vs Coding

Question

Happy Thanksgiving, Прежде всего, я искал информацию, если Visual Scripting - это новая вещь, которая была создана для игровых движков. Позвольте мне показать вам некоторые примеры визуальных сценариев

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

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

Hour of Code: Coding with Anna and Elsa

Answer 3

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

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

Когда вы вводите обычный код, вам нужно знать, что вы делаете, он позволяет квалифицированному пользователю иметь гораздо большую гибкость и производительность (визуальный сценарий часто не хватает этого). Хотя организовать такие проекты гораздо сложнее, и код может легко выйти из-под контроля. Но да, производительность и гибкость, это ДЕЙСТВИТЕЛЬНО большая вещь.

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

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

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

Так Adv/Disadv:

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

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

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

Надеюсь, я как-то разобрался с вами:).