Godot: Простой в использовании геймдизайнер для не программистов

визуальный сценарий планируется в какой-то момент

В среду, 14 января 2015 г., в 6:20, [email protected] написал:

Привет, разработчики Годо.

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

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

Мое предложение состоит в том, чтобы предоставить простой в использовании геймдизайнер/редактор с
интуитивно понятный графический интерфейс и предопределенный класс для облегчения задачи нового программиста. Более
программист означает больше пользователя (потому что пользователь Godot — программист игры).

Я знаю один игровой движок, который хорошо справляется с этой задачей. Написано на Руби,
родом из Японии и переведены на английский язык по всему миру. Это называется РПГ
Производитель VX Ace
http://www.rpgmakerweb.com/products/programs/rpg-maker-vx-ace. Несмотря на
слово RPG перед его названием, он способен создавать не-RPG
со встроенной системой Ruby Game Scripting System (RGSS).

https://camo.githubusercontent.com/72746b38bc6f990eb5f1b9bb242bdce347af3c72/687474703a2f2f67616d65736172656576696c2e636f6d2f77702d636f6e74656e742f75706c6f6164732f323031332f30312f7270676d616b6572322e6a7067

В следующем списке приведены примеры игр, созданных с помощью движка RPG Maker:

1. Алеф (приключенческая ролевая игра) http://www.pioneervalleygames.com/
2. Ламантины не обещаны (аркады) http://rpgmaker.net/games/5102/
3. Рагарокк - Бестиариум (Карточная игра) http://rpgmaker.net/games/5808/
4. Земля под атакой! (Стрелок) http://rpgmaker.net/games/6561/
5. Терра (VisualNovel) http://rpgmaker.net/games/3956/
6. Воспоминания о Мане (ролевой боевик)
   http://www.atelier-rgss.com/Project/Mana/Project_Mana_Story.html
7. Myhos - Начало (Ужасы) http://rpgmaker.net/games/6493/

Я хочу, чтобы движок Godot стал таким же популярным, как RPG Maker, потому что в нем много
больше возможностей, чем RPG Maker. Начинающему программисту просто нужен простой в использовании
интерфейс. В случае успеха студия Okam может стать следующим GOG или Steam
которые публикуют тысячи игр, созданных независимыми разработчиками.

С уважением, Райан

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/okamstudio/godot/issues/1220.

@RyanBram - Здесь я вовсе не пытаюсь опровергнуть идею - это, вероятно, может быть полезно в будущем, но я не уверен, что визуальные сценарии являются эффективным средством написания сценариев. Я не могу сказать наверняка, но я полагаю, что более сложные игры, которые вы разместили, скорее всего, были написаны текстом, а не визуально. Кажется, что визуальные сценарии — это то, что новые пользователи используют, конечно, но это задерживает их в изучении реальных инструментов, которые им понадобятся для правильного завершения своих проектов. Но это может сделать двигатель более доступным, так что я не знаю.

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

Похоже, что RPG maker больше использует подход «моддинга», и если Godot будет больше похож на RPG maker, люди, у которых есть намерения делать разные игры, отвернутся. Итак, вы в основном предлагаете сделать godot более похожим на GameMaker (что понятно, многие люди хотят делать игры, но не знают программирования), но есть ограничения :)
Что, вероятно, произойдет, так это то, что Godot получит редактор Nodal Behavior Graph, аналогичный тому, что есть у Leadwerks и BGE. Это очень хорошо работает с элементами графического интерфейса, остальные потребуют некоторых исследований и множества отзывов сообщества, чтобы сделать его максимально простым и мощным.

@SolarLune , можно создать игру в Godot и добавить сверху редактор, который позволяет модифицировать игру до мельчайших деталей (используя GraphNodes и остальную часть пользовательского интерфейса, с которым очень весело играть), и даже позволит написать некоторые дополнительный код GDscript сверху, я думаю, что это лучший подход, чтобы поставлять полную игру (RPG, FPS, RTS) отдельно и позволять настраивать каждый ее аспект. Конструкторы, сделанные в Годо.

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

В среду, 14 января 2015 г., в 16:23, [email protected] написал:

Создатель RPG, кажется, использует подход «моддинга», и, если годот
больше похожи на создателей RPG - людей, у которых есть намерения делать разные
такие игры отвернутся. Итак, вы в основном предлагаете
сделать godot более похожим на GameMaker (что понятно, многие люди
хочу делать игры но не разбираюсь в программировании) но есть предел :)
Что, вероятно, произойдет, так это то, что Godot получит Nodal Behavior Graph.
редактор, аналогичный тому, что есть у Leadwerks и BGE. Это очень хорошо работает с
Элементы графического интерфейса, остальное потребует некоторых исследований и большого количества сообщества.
обратной связи, чтобы сделать его максимально простым и эффективным.

@SolarLune https://github.com/SolarLune , можно создать игру
в Godot и добавить сверху редактор, позволяющий модифицировать игру на любой вкус
немного деталей (с использованием GraphNodes и остальной части пользовательского интерфейса) и даже позволит
напишите дополнительный код GDscript сверху, я думаю, что это лучший подход,
отправить полную игру (RPG, FPS, RTS) отдельно и разрешить настройку
каждый его аспект.

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-69974733 .

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

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

UE4 прямо сейчас не может делать все в Blueprints без безумной сложности, GameMaker ожидает, что вы будете использовать GML для максимальной гибкости (за счет использования блоков кода), а BGE требует написания сценариев на Python для максимальной мощности (за счет использования блоков кода). Нельзя сбрасывать со счетов полезность визуального редактирования для быстрого прототипирования и менее сложных логических ситуаций, но оно часто не может делать все, что можно сделать в коде.

визуальный сценарий планируется в какой-то момент

Спасибо за простой и положительный ответ.

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

В RPG Maker VX Ace большая часть расширенных функций кодируется вручную. Опытные программисты обычно предоставляют расширенный скрипт моддинга, значение которого может быть отредактировано в редакторе графического интерфейса обычным пользователем (имя персонажа, навык, портрет, спрайт и т. д.). Ruby Game Scripting System делает возможным исправление обезьян. Вот почему большинство скриптов, предоставленных продвинутым пользователем, не заменят исходный предопределенный класс разработчиками RPG Maker, чтобы избежать проблем с совместимостью.

Для сравнения:
Проекты KDE и GNOME никогда не намеревались заменить мощные команды оболочки в Linux, вместо этого проекты просто пытаются заполнить пробел между простотой использования и мощью Linux.

Я смеялся над идеей, что студия Okam похожа на Steam... :))

14.01.2015, 17:20, RyanBram написал:

Привет, разработчики Годо.

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

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

Мое предложение состоит в том, чтобы предоставить простой в использовании геймдизайнер/редактор с
интуитивно понятный графический интерфейс и предопределенный класс для облегчения задачи нового программиста.
Больше программистов — больше пользователей (потому что пользователи Godot — программисты игр).

Я знаю один игровой движок, который хорошо справляется с этой задачей. Написано на Руби,
родом из Японии и переведены на английский язык по всему миру. это
под названием RPG Maker VX Ace
http://www.rpgmakerweb.com/products/programs/rpg-maker-vx-ace.
Несмотря на слово RPG перед своим названием, он достаточно способен
создавать игры, не относящиеся к RPG, с помощью встроенной системы сценариев игр Ruby (RGSS).

https://camo.githubusercontent.com/72746b38bc6f990eb5f1b9bb242bdce347af3c72/687474703a2f2f67616d65736172656576696c2e636f6d2f77702d636f6e74656e742f75706c6f6164732f323031332f30312f7270676d616b6572322e6a7067

В следующем списке приведены примеры игр, созданных с помощью движка RPG Maker:

1. Алеф (приключенческая ролевая игра) http://www.pioneervalleygames.com/
2. Ламантины не обещаны (аркады) http://rpgmaker.net/games/5102/
3. Рагарокк - Бестиариум (Карточная игра) http://rpgmaker.net/games/5808/
4. Земля под атакой! (Стрелок) http://rpgmaker.net/games/6561/
5. Терра (VisualNovel) http://rpgmaker.net/games/3956/
6. Воспоминания о Мане (ролевой боевик)
   http://www.atelier-rgss.com/Project/Mana/Project_Mana_Story.html
7. Myhos - Начало (Ужасы) http://rpgmaker.net/games/6493/

Я хочу, чтобы движок Godot стал таким же популярным, как RPG Maker, потому что он
гораздо больше возможностей, чем RPG Maker. Начинающему программисту достаточно
простой в использовании интерфейс. В случае успеха студия Okam может стать следующей
GOG или Steam, которые публикуют тысячи игр, созданных независимыми разработчиками.

С уважением, Райан

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/okamstudio/godot/issues/1220.

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

15.01.2015, 3:44, Хуан Линецкий написал:

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

В среду, 14 января 2015 г., в 16:23, [email protected] написал:

Создатель RPG, кажется, использует подход «моддинга», и, если годот
больше похожи на создателей RPG - людей, у которых есть намерения делать разные
такие игры отвернутся. Итак, вы в основном предлагаете
сделать godot более похожим на GameMaker (что понятно, многие
люди
хочу делать игры но не разбираюсь в программировании) но есть предел :)
Что, вероятно, произойдет, так это то, что Godot получит Nodal Behavior Graph.
редактор, аналогичный тому, что есть у Leadwerks и BGE. Это работает очень хорошо
с участием
Элементы графического интерфейса, остальные потребуют некоторых исследований и тонны
сообщество
обратной связи, чтобы сделать его максимально простым и эффективным.

@SolarLune https://github.com/SolarLune , можно создать игру
в Godot и добавить сверху редактор, позволяющий модифицировать игру на любой вкус
небольшие детали (с помощью GraphNodes и остального пользовательского интерфейса) и даже
разрешить
напишите дополнительный код GDscript сверху, я думаю, что это лучше всего
подход,
поставлять полную игру (RPG, FPS, RTS) отдельно и позволять
настройка
каждый его аспект.

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-69974733 .

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-69978224 .

Я смеялся над идеей, что студия Okam похожа на Steam... :))

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

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

Отлично, если это будет доступно в Godot.

С уважением,
Райан

Привет Райан

Вы проверили Construct 2? Это один из моих любимых дизайнеров визуальных игр, и он чрезвычайно прост в использовании.

Визуальное программирование в Godot, я думаю, будет довольно сложно сделать (поскольку Godot работает как с 2D, так и с 3D, поэтому возможности намного шире).
Кроме того, он, вероятно, будет встроен гораздо позже, когда все основные блоки для движка будут на месте.

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

Привет Райан

Вы проверили Construct 2? Это один из моих любимых дизайнеров визуальных игр, и он чрезвычайно прост в использовании.

Я попробовал Construct 2. Это красиво и круто. Получившиеся игры еще и кроссплатформенные, так что это большой плюс. К сожалению, я до сих пор не могу найти ни одного учебника по созданию ролевых игр. На данный момент я могу остаться с RPG Maker VX Ace и попытаться портировать свою игру на многие платформы (включая Android) с помощью MKXP Project .

Спасибо, что поделился. Я с нетерпением жду визуального программирования в Godot.

С наилучшими пожеланиями,
Райан

Что касается визуального подхода к написанию сценариев, вы можете делать заметки из gdevelop, мультимедийного слияния и конструкции 2. Эти движки на 100 % полагаются на визуальные сценарии. Вам все еще нужно изучить некоторый синтаксис, где нужны выражения, но редактор выражений чрезвычайно упрощает поиск правильных команд. Эти три движка дают вам свободу создавать игры любого типа с визуальным сценарием — в отличие от создателей игр и создателей ролевых игр.

Rpg maker не очень хороший пример, так как он крайне ограничен.
Сценарии на основе узлов очень неэффективны с точки зрения использования пространства - вы будете перемещаться, увеличивать и уменьшать масштаб гигантского графа узлов. Сравните это с построением 2, где все изложено четко, компактно и легко читается — и вы выиграли.

BGE, вероятно, является худшим примером здесь, поскольку он пытается объединить подход, основанный на узлах, с логическими блоками. Я писал о том, почему это плохо:
http://blenderartists.org/forum/showthread.php?323905-comparing-BGE-logic-bricks-with-Scirra-Construct-event-sheet-for-prototyping

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

Я бы хотел, чтобы что-то подобное реализовано _только_ как дополнительный способ программирования. Визуальные сценарии, в отличие от кода, значительно снижают производительность. Это также значительно усложняет отладку и рефакторинг. Одно важное преимущество, о котором я могу думать (помимо привлекательности для непрограммистов), заключается в том, что визуальные сценарии имеют тенденцию быть отличным инструментом обучения, если они могут генерировать или, по крайней мере, отображать фактический код GDScript (код IE. орг). Я не думаю, что нужно было бы идти наоборот (IE. GDScript в Visual). Я думаю, это был бы отличный способ для школ использовать Годо в своих классах.

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

Код: Код обычно имеет определенные синтаксические правила, которым необходимо следовать. Я предполагаю, что это, как правило, главное, что отталкивает непрограммистов. IE. в GDScript у вас должно быть двоеточие в конце объявления функции, циклы if, for, while и т. д. Вы должны правильно делать отступы. Вы должны использовать ключевое слово var при объявлении переменной типа «var myInteger = 1». Для большинства языков, как правило, существует около 3 или 4 основных синтаксических правил, которым необходимо следовать, и, на мой взгляд, их не так уж сложно выучить. Написав несколько небольших сценариев, их может выучить даже художник. Я говорю это, потому что работаю с двумя очень талантливыми художниками, которые работали над всеми тремя играми Age of Empires с Ensemble Studios. Один написал довольно много кода на UnityScript, а другой теперь написал тонну кода на C#.

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

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

Я бы выбрал немного другой подход. Так как редактор godot загоняется сам на себя - аналогичный интерфейс редактора легко воссоздать на чистом GDscript.

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

Ядро конструктора может быть адаптировано к любому игровому жанру (FPS, RTS, GPS....) с загружаемым контентом и прочим, и если его поддерживает сообщество - будет легче внести свой вклад, потому что все это GDscript.
Маловероятно, что в ближайшее время в godot появятся визуальные скрипты, но это не мешает другим создавать конструктор поверх него. Я видел, как кто-то взял Blender 2.5 и сделал инструмент для проектирования интерьера.

Я думаю, что наличие нескольких редакторов может привести к фрагментации разработки Godot. Должен быть один хорошо спроектированный центральный проект для визуального инструмента написания сценариев, который строится поверх gdscript.

Не поленитесь и проведите исследование. Посмотрите на другие чисто визуальные скриптовые движки. Сравните их пользовательскую базу (насколько они популярны), сравните, насколько они гибкие — типы игр, которые были сделаны с ними — будь то на кикстартере, в Steam или на других платформах.
Посмотрите на их подход к дизайну.

Затем спроектируйте его на бумаге. Не просто копируйте подход узла. Использование узлов для шейдеров — это нормально, но когда дело доходит до логики, вы оказываетесь в адском беспорядке, который нужно прокручивать и пытаться разобраться.

поверь мне, я пробовал все. Плеймейкер Unity, Kismet Unreal, создатель rpg, трафарет и т. д. и т. д.
Construct2 выходит на первое место вместе с мультимедийным сплавом. Это самые популярные, с наиболее гибким подходом. И у них обоих есть магазин на рынке активов.
Они чрезвычайно гибкие, и если вы посмотрите на игры, сделанные с их помощью, вы увидите огромное разнообразие жанров.

Если вы станете еще умнее в этом, вы можете объединиться с Gdevelop — еще одним проектом с открытым исходным кодом, в котором уже есть визуальный редактор сценариев, который делает игры html5.
Посмотрите на его дизайн и исходный код.

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

Система визуального скриптинга должна быть разработана для художников, а не для программистов. Как бы я ни жаловался на свою абсолютную неприязнь к таким вещам, как PlayMaker на Unity, правда в том, что художники его любят. Вот почему у него почти 2000 отзывов и 5 звезд. Если голосование состоит в том, чтобы иметь что-то более похожее на сценарии Construct 2, то я голосую за то, чтобы вообще не иметь визуальных сценариев, поскольку я не верю, что это принесет какую-либо реальную пользу, поскольку: а) программисты могут программировать непосредственно на GDScript и б) многие художники будет мгновенно выключен им и просто пойдет в другое место. Я знаю, потому что два моих друга-художника, которые оба умеют программировать, смотрели на Construct 2 и высмеивали интерфейс программирования, который у него есть, поскольку это почти то же самое, что просто писать код.

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

Я согласен с вами, что он должен быть разработан для художников/дизайнеров.
Но не согласен с логикой, что слова = сложность.

Если вы посадите кого-нибудь, чтобы научить его использовать один из двух, будет и конструкция 2, которая окажется более простой из двух. Почему?
Потому что это понятнее, чем узлы. Гораздо яснее. У вас есть условия и действия. Вы кладете первую в левую сторону, а другую - в правую.
Чтобы добавить любой из двух, вам не нужно знать команды. Все они перечислены там, чтобы вы могли их добавить - ясно как день. У каждого есть значок, который является визуальной подсказкой.

Playmaker и другие системы, основанные на узлах, требуют гораздо большего изучения, потому что привязка узла к другому узлу требует, чтобы вы сначала поняли, можете ли вы соединить их. Это не просто условие --> действие. Узлы намного сложнее и лишены визуальных подсказок. Где вы увидели иконки в плеймейкере??
В нем гораздо проще ошибиться. Логику в нем читать намного сложнее.
https://www.scirra.com/tutorials/top
Я бы также сказал, что, поскольку C2 является более продуманным инструментом визуального программирования, у него гораздо большее сообщество активных пользователей, чем у плеймейкера, хотя на данный момент он ограничен 2D-играми. Гораздо больше видеоуроков в сети (больше людей понимают, как им пользоваться, чем плеймейкером), гораздо больше завершенных проектов, здоровая активная торговая площадка и форум, а самое главное — активное общение между разработчиками и пользователями. Так что разработчики знают, чего хотят художники-пользователи.

Пользователи Construct могут просто сделать снимок экрана своего листа событий, и становится ясно, как они это сделали. Зайди на форумы и посмотри сам. Я бы сказал, что у него гораздо больше пользователей, чем у плеймейкера.

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

Я вижу, что они вам нравятся, но, пожалуйста, попробуйте, пожалуйста, build2, прежде чем заявлять, что это движок программиста.
Посмотрите на их форум и базу пользователей. У него не меньше, если не больше, хорошая репутация, чем у плеймейкера. Ему удалось завоевать хорошую репутацию за счет того, что он был хорошо спроектирован сам по себе, а не за счет того, что он был плагином для уже успешного движка. Это чистый инструмент визуального программирования, который может использовать любой художник. Я художник и пробовал плеймейкер - это сложнее, чем конструкт2. Зайдите на форум C2 и попытайтесь убедить их, что playmaker проще в использовании — просто для смеха. :D
Вы сами не программист? Вы внесли в проекты github больше, чем я. Не означает ли это, что вы не должны делать утверждение, которое легче выучить?

Я понимаю вашу точку зрения с точки зрения программиста. Если бы мне пришлось выбирать между ними, я бы выбрал модель Construct. Однако, как я уже сказал, это худшее место для принятия такого решения, потому что, вероятно, большинство, если не все люди, которые читают списки рассылки GitHub, являются программистами.

Я провел большую часть своей карьеры с художниками, чем с программистами. Хотя я регулярно занимался обоими в течение последних 18 лет (и был увлечен обоими), я был профессиональным художником до того, как стал профессиональным программистом. Не то чтобы меня заботило, что у меня даже есть степень, моя степень связана с цифровой анимацией и визуальными эффектами. Насколько мне известно, рекламные ролики, над которыми я работал, до сих пор идут после нескольких лет в Канзас-Сити. Я работал над кадрами для Hallmark, Sprint, Radio Shack, Honda и некоторых других, о которых, вероятно, забыл. Я также получил массу удовольствия, работая над несколькими кадрами в «Строителе мира» с Брюсом Бранитом.

https://www.youtube.com/watch?v=QP3YywgRx5A
Натан Уорден в титрах это я

Я говорю это не для того, чтобы хвастаться, я говорю это, чтобы подчеркнуть свою точку зрения. Я могу ошибаться, но как художник, который провел много времени среди художников, я думаю, что знаю, что им нравится. Им не очень нравятся такие вещи, как Constructor. Они, как правило, чувствуют себя запуганными и выбирают совершенно другое приложение. У художников вообще совсем другое мышление, чем у программистов. Это похоже на то, когда я говорю со своим другом Эриком о технических вещах, которым я пытаюсь его научить, эти слова довольно часто вылетают из его рта: «Нейт, я очень визуальный человек, если ты не можешь мне это показать. визуально вы могли бы также говорить со стеной».

Есть причина, по которой художникам нравятся такие вещи, как графы шейдеров на основе узлов, а не системы линейных шейдеров. Они могут визуализировать происходящее. Я не думаю, что когда-либо слышал, чтобы художник жаловался на отсутствие системы линейных шейдеров в их любимом 3D-приложении, но они регулярно жалуются, когда у них нет системы шейдеров на основе узлов.

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

Итак, еще 2 причины, по которым система на основе узлов понравится художникам:

1) Визуально они выглядят намного привлекательнее.
2) Это вписывается в парадигму дизайна, к которой они уже привыкли. IE Shading и композитинг

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

Вы уверены, что знаете, что такое Construct2? Вы даже название не правильно пишете.
Он не называется "Конструктор".

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

Более важно, насколько это ясно, чем то, как это выглядит. Ясность того, что делает логика, важнее того, как выглядит редактор на первый взгляд. Construct2 не похож на код — текст написан простым английским языком, и очевидно, что делает действие или условие. Люди, использующие C2, как правило, тоже визуалы.

Список событий всегда будет выигрывать у узлов, как бы вы ни старались сделать так, чтобы он выглядел. Он может упаковать больше информации на экране с меньшим количеством панорамирования — более очевидно, что делает логика. А визуальные подсказки (иконки) гораздо легче найти глазу художника.
У узлов нет иконок и огромное ограничение текста.
Таким образом, во многих случаях узел даже не описывает четко то, что он делает, из-за того, насколько он ограничен по размеру, что вынуждает дизайн использовать непонятную терминологию вместо простого английского.

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

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

Я призываю дизайнеров/разработчиков/визуалов godot попробовать эти движки в небольшом проекте, а затем сделать выводы. Хватит этих сторонних историй. Нам нужны практические исследования и логически изложенные аргументы в пользу того, почему одно лучше другого. Хотите верьте, хотите нет, у визуалов тоже есть здравый смысл.

Не по теме:
На примере Fusion vs Aftereffects — люди предпочитают подход на основе узлов к композитингу, потому что использование слоев может стать очень громоздким в сложной сцене, где один и тот же эффект может быть продублирован на многих слоях. С узлами вы можете иметь больше гибкости с точки зрения компоновки и просто подключить один эффект ко многим слоям. Но узлы сложнее, чем слои.

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

И да, я сказал Construct неправильно, извините. Нет, я лично не пользовался. Но это не имеет значения, потому что парадигма сценариев, которую он использует, не является новой концепцией при любом натяжении воображения, поэтому мой аргумент даже не касается самого Construct. Речь идет об этом стиле написания сценариев, поскольку он относится к художникам, а не к программистам.

В системе на основе узлов у вас может быть несколько условий, событий и функций, содержащихся в каждом узле. Затем вы можете назвать узел, например, как Input. Внутри он будет содержать все входы джойстика, и пользователь скажет ему, какое событие использовать. IE. они бы указали событие, такое как «Пожар». Это событие вызовет переход к любому узлу, к которому они его подключили.

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

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

Однако, когда я сказал: «На первый взгляд это не должно выглядеть как код». Многие художники заботятся о том, на что они будут смотреть каждый день в течение неопределенного времени. Они отклонят все приложение, если оно не выглядит привлекательным или пугающим. Я бы сказал, что блочный стиль выглядит устрашающе и сбивает с толку типичного художника. Это похоже на что-то для программистов, и это так.

@blurymind ,

Узлы графа фактически пришли из концептуального UML. Вы делаете графическое представление кода так, чтобы его могла понять непрограммирующая аудитория (менеджеры проектов, потребители, художники). Это то, что использует UE4/Unity. Это то, о чем знают все в отрасли. Конструкторы обычно используют другой подход, и насколько этот подход хорош - не определяется количеством пользователей, которые его используют.

Всегда и везде есть кривая обучения, и Construct2 не исключение. Но давайте не будем навязывать Godot материал C2, не подкрепив аргументы. Лист событий будет становиться длиннее с более сложными играми и в конечном итоге будет занимать больше места, чем узлы графа. Только кнопка «Добавить действие» имеет свою собственную строку. Это в основном то, как программист интерпретирует блок кода. Так что это не так уж и плохо.

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

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

Но видите ли, просто глядя на ваш скриншот, я понятия не имею, что делает эта логика. Какого черта "firePrimary" и "fireSecondary"??
Теперь прокрутите вверх до снимка экрана, который я разместил для конструкции2.
В конструкции 2 условие слева будет читаться как «нажата буква «R» или что-то вкратце на простом английском языке — со значком клавиатуры рядом с ним!

Покажите их обоим художнику и спросите, что яснее.

Покажите нам более сложную настройку узла :) На скриншоте C2 показана вся логика игры. У вас только одно событие. Можете ли вы уместить ту же логику на одном скриншоте с узлами? Я так не думаю.

См. пример узла, скрывающего информацию.
Вы должны выбрать узел, чтобы увидеть, что установлено внутри него.
Он использует непонятную терминологию программиста, а не человеческий язык («Отправить событие», «Сохранить результаты», какого черта?).
Construct2 показывает все в одном месте и понятно не программистам. Смысл визуального программирования в том, чтобы избавиться от необходимости изучать терминологию.

Я не программист. У меня нет опыта написания реального кода. Тем не менее, я могу легко создать игру с помощью Construction2, а использовать узлы для меня намного сложнее, когда дело доходит до полной игры.

Я понимаю, что все всегда будут голосовать за то, что они уже умеют делать хорошо. Но, как вы признали, вы программист и фактически не использовали C2. И я продолжаю утверждать, что я художник без опыта кодирования, который использовал как узлы, так и подход C2.

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

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

@TheoXD
Я полностью согласен с вами, если я правильно вас понял. Было бы неплохо иметь оба в виде отдельного плагина/модуля. Таким образом, внизу будет настоящий GDScript, но вы можете визуализировать его, используя все, что захотите. Я думаю, это возможно. Подход, основанный на узлах, может потребовать некоторых флагов, таких как специальные комментарии для разделения узлов (например, #node name="Input" и #endnode), но это не так уж важно, поскольку это было бы автоматически, если бы вы начали с графа узлов. Я думаю, что блочный подход будет прямым.

Вы что-то подобное имели в виду?

Как я уже говорил выше, мне очень нравится метод block/Construct/code.org, так как он отлично подходит для обучения программированию. Я просто не думаю, что это хорошо подходит для людей, которые считают программирование неизбежным злом.

@blurymind
Причина, по которой это не имеет смысла, заключается в том, что вы не знакомы с этим. Когда я смотрю на изображение Construct выше, я также понятия не имею, что происходит, не потому, что оно плохое, а потому, что я не знаком с ним.

Что касается невозможности увидеть, что находится под узлом, пока вы не щелкнете по нему, после того, как вы настроили узел, нет реального смысла просеивать то, что вы уже знаете, там. Я уже знаю, что у меня есть левый и правый щелчок, и что они стреляют первичными и вторичными боеприпасами. Я уже знаю, что делают первичный и вторичный огневые узлы. Он не изменился с тех пор, как я его сделал, почему я должен видеть детали каждый раз, когда смотрю на него? Итак, теперь основная логика просто беспорядок. Это еще одна причина, по которой узлы более удобны для художников и не программистов. Они могут разбить свою конкретную логику на более общие фрагменты. Это позволяет им видеть общую картину и беспокоиться о деталях только тогда, когда это абсолютно необходимо.

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

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

(Еще одна вещь, которую вы не можете сделать с блоками, это сделать их похожими на корабль Самус, ха-ха)

Без каких-либо подсказок я просто поместил ваше изображение Construct2 на один экран и приведенный выше граф узлов на другой и спросил мою жену (которая определенно не программист): «Какой из них вы бы хотели использовать, если бы вам пришлось его использовать? каждый день?», и она указала на граф узлов и сказала: «Вот этот». Я знаю, что это не окончательно, но тот факт, что это менее пугающе, означает, что у меня гораздо больше шансов хотя бы начать научить ее этому. Если это выглядит пугающе, она может отключить свой мозг еще до того, как я уговорю ее сесть и изучить основы.

Не подталкивая его ни к тому, ни к другому, я также вчера спросил своего друга-художника (того самого, который работал над всеми тремя играми Age of Empires), который работает в игровой индустрии уже почти 20 лет (и кто использовал Construct2): то, что, по его мнению, предпочли бы другие художники, и он также назвал граф узлов.

В любом случае, мне очень нравится обсуждение, но нет смысла бить дохлую лошадь, ха-ха :)

Да, я тоже получаю удовольствие. Никаких неприятных ощущений :)

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

Вы снова даете нам истории от третьего лица, которые на самом деле не подтверждаются доказательствами. Приведи чувака сюда и попроси его рассказать нам, ПОЧЕМУ он предпочитает одно другому :)
Тогда у вас будет более сильный корпус. Я не получаю никаких логически разумных доводов в поддержку тезиса о том, что узлы пока более прямолинейны.

да, на первый взгляд он выглядит менее пугающим, потому что скрывает много информации. Ваши примеры намного проще, чем то, что показано на скриншоте, который я разместил. Это заблуждение.
Вот видео, которое показывает горячую настройку логики для платформера в C2.
https://www.youtube.com/watch?v=5RlSmkSbleI
пропустить первую минуту :P

Давайте не будем сравнивать яблоки с апельсинами.
Code.org — это радикально отличный подход от Construct2 — он больше похож на Stencyl и имеет один из недостатков узлов: ваши условия и действия не разделены четко — поэтому сложнее разобраться, что к чему можно привязать. Хорошо продуманные инструменты визуального программирования (Multimedia fusion, build2, gamedevelop) четко отделяют условия от действий для пользователя. Это значительно упрощает построение логики, поскольку они организованы для вас программным обеспечением, которое угадывает, что вам может понадобиться, и показывает это вам в нужное время. это также убережет вас от глупых ошибок.

С nodes/stencyl/code.org вам нужно выяснить, какая часть является условием, а какая действием. Требуется больше времени, чтобы правильно настроить условия. Какой тип информации выходит из узла? Несколько раз требуется больше узлов, чтобы настроить условие, — больше нужно научиться их подключать.
Давай, проведи свое исследование и попробуй немного другие инструменты. Видеть все не-узлы как одно и то же не помогает.

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

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

Как бы я ни хотел, чтобы эта проблема набрала более 100 комментариев, разработчики не будут читать их все, лучшее, что каждый из нас может сделать, это создать PDF-файл с предложениями и поделиться ими в списке рассылки. Я не понимаю, почему мы не можем иметь разные уровни абстракции, узлы Graph в качестве верхнего уровня, которые можно представить в виде дерева событий. Если это сработает, то не будет необходимости идти на компромисс.

" @blurymind -- || -- И вы оба признаетесь, что вы программисты." - Я не считаю себя только программистом, искусством тоже занимаюсь. Я использую свой опыт, чтобы смотреть на вещи с объективной точки зрения.

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

Вот несколько ссылок на некоторые из моих работ (ищите Натана Уордена в титрах)

World Builder (задействован примерно в половине кадров)
https://www.youtube.com/watch?v=VzFpg271sm8

Teddy Scares (участвовал в большинстве съемок)
https://www.youtube.com/watch?v=qCXIzS_iY0k

Hallmark Crown Center (Третий кадр с Сантой)
https://www.youtube.com/watch?v=biqBq3_Whqk

Вот рендер здания моего Луи. Если вы посмотрите World Builder, вы увидите некоторые иллюстрации, которые я выдрал из него и вставил в фильм.

А вот незаконченный рендер танка HK в стиле Терминатора 1, разбивающего Кристину Стивена Кинга. Обе эти модели сделаны мной, но я не думаю, что в кадре было что-то еще.

И многое другое, что я мог бы назвать, но я думаю, что дело сделано. :)

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

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

Я думаю, что это не очень хорошая идея по ряду причин.

-Недавно Unreal сделали свой движок бесплатным - он тоже мультиплатформенный. Это гораздо более зрелый движок, чем BGE/Godot. Таким образом, вы напрямую конкурируете с ними, копируя их подход к визуальному программированию.

-Узлы намного менее эффективны на экране, чем лист логики. Их труднее читать/следовать.

-Scirra объявил, что Construction3 будет мультиплатформенным - редактор будет работать на Windows, Linux и Mac.
Однако они не являются открытым исходным кодом.
https://www.construct3.com/

Это вызвало волну комментариев в сообществе scirra. Многим пользователям нужен ряд вещей, которые godot может предложить без визуального программирования:
- Собственные исполняемые файлы вместо контейнеров html5 - для лучшей производительности
- поддержка разработки 3D-игр с использованием стиля листа событий в конструкции для его программирования:
https://www.scirra.com/forum/construct-3_t90881

если бы они сделали простой и понятный 3D-редактор, такой как 2D-инструмент внутри C2, я бы полностью использовал его, черт возьми.

я попробовал единство, блендер, крутящий момент 3D, UDK, потому что они более разрекламированы и используются большинством так называемых известных разработчиков... и у них общие проблемы: они не удобны для пользователя (совсем), и если вы никогда раньше не использовал API для создания 3D-игр... ну, ты 3Doomed (плохая шутка, икно)

дело в том, что конструкция очень интуитивно понятна, как только вы охватываете основы и даете вам свободу создавать сложные 2D-игры, она дает вам различные пути для достижения одного и того же результата (не говоря уже о том, что система событий ИМЕЕТ СМЫСЛ для меня); это деталь, которую большинство других инструментов не могут покрыть или сделать плохо

если они сделают 3D-движок с тем же потоком и ощущением, что и я, используя C2; тогда почему бы не попробовать?

На данный момент у них огромная база пользователей (которым нравится стиль списка событий для визуального программирования, но им нужны эти функции), и некоторые из них готовы перейти на другой движок. У Godot есть большой потенциал, чтобы привлечь на борт множество новых инди-разработчиков — тех, кто предпочитает это узлам, тех, кто не использует движок Unreal, который теперь бесплатный и намного более зрелый, чем godot.

Если вы выберете его вместо узлов, вы станете первым движком, который поддерживает полную разработку 3D-игр с таким программным дизайном. Вы будете использовать новую пользовательскую базу вместо того, чтобы конкурировать с Unreal (бесплатно), Unity (доступна бесплатная версия).

Ну, это потрясающие кадры, но опять же, вы делаете это, чтобы придать себе больше авторитета.

Кадры и ссылки являются доказательством не моего авторитета, а доказательство того, что люди, с которыми я работал, и что я не просто выдумываю :) Сюда входят некоторые из моих хороших друзей, которые работали над некоторыми фильмами, о которых вы, возможно, слышали, например «Аватар», «Кинг-Конг», «Серенити» и такие сериалы, как «Остаться в живых», «Революция» и т. д. И некоторые другие мои друзья, проработавшие в игровой индустрии более 15 лет. Все они предпочитают рабочий процесс на основе узлов линейному рабочему процессу на основе листов. Я мог бы, вероятно, получить цитату от 3-4 из них, говорящих вам, что они предпочитают графы узлов логическим листам, если хотите?

Недавно Unreal сделали свой движок бесплатным — он тоже мультиплатформенный. Это гораздо более зрелый движок, чем BGE/Godot. Таким образом, вы напрямую конкурируете с ними, копируя их подход к визуальному программированию.

Рабочий процесс визуального скриптинга — это последнее, на что обращают внимание люди, сравнивая Godot с этими движками. Первое, что они заметят, это то, что Unreal поддерживает DirectX 12 и OpenGL 4 и что их демоверсии и примеры выглядят потрясающе, а затем они начнут смотреть на другие вещи. Главное преимущество Godot над этими компаниями заключается в том, что это программное обеспечение FLOSS, и любой, кто его использует, в равной степени является полноправным владельцем этого программного обеспечения.

Узлы намного менее эффективны с точки зрения экрана, чем лист логики. Их труднее читать/следовать.

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

Если вы выберете его вместо узлов, вы станете первым движком, который поддерживает полную разработку 3D-игр с таким программным дизайном.

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

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

Блоки действий, такие как Game Maker, интересны, но я думаю, что это больше
предназначен для замены программирования.

Подход Unreal больше похож на дополнение к программированию, поэтому
дизайнеры могут работать в игре сами и брать работу у
программист. Это гораздо полезнее в командах (художники и геймдизайнеры).
может использовать его нормально) и, безусловно, это подход, который я хотел бы добавить к
Годо, потому что для этого.

Из-за архитектуры Godot добавить его также было бы очень легко, поэтому я дам
это выстрел в 1.2

Во вторник, 3 марта 2015 г., в 16:37, Натан[email protected] написал:

Ну, это потрясающие кадры, но опять же, вы делаете это, чтобы дать
себе больше авторитета.

Кадры и ссылки являются доказательством не моего авторитета, а людей, которых я
работал, и что я не просто придумываю :) Это включает в себя некоторые из моих
хорошие друзья, которые работали над некоторыми фильмами, о которых вы, возможно, слышали, например
«Аватар», «Кинг-Конг», «Серенити» и такие шоу, как «Остаться в живых», «Революция» и т. д.
некоторые из моих других друзей, которые проработали в игровой индустрии более 15 лет
годы. Все они предпочитают рабочий процесс на основе узлов, а не линейный, основанный на листах.
рабочий процесс. Я мог бы, вероятно, получить цитату от 3-4 из них, говорящих вам, что
если хотите, они предпочитают графы узлов логическим листам?

Недавно Unreal сделали свой движок бесплатным — он тоже мультиплатформенный. Это
гораздо более зрелый движок, чем BGE/Godot. Так что вы конкурируете с ними
непосредственно при копировании их подхода к визуальному программированию.

Рабочий процесс визуального сценария — это последнее, чем будут заниматься люди.
глядя на сравнение Godot с этими двигателями. Первым делом они
обратите внимание, что Unreal поддерживает DirectX 12 и OpenGL 4 и что их демоверсии
и примеры выглядят потрясающе, тогда они начнут смотреть на другие вещи.
Главное, что у Годо есть над этими компаниями, это то, что это FLOSS.
программного обеспечения и что любой, кто его использует, в равной степени является полноправным владельцем
программное обеспечение.

Узлы намного менее эффективны с точки зрения экрана, чем лист логики. Им труднее
читать/следовать.

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

Если вы пойдете на это вместо узлов, вы будете первым двигателем, который
поддерживает полную разработку 3D-игр с таким дизайном программирования.

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

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-77017857 .

Я попробовал Playmaker и должен сказать, что он мне понравился больше, чем нереальный кисмет/чертежи.

В плеймейкере узлы похожи на контейнеры, в которые вы помещаете действия. Некоторыми из действий являются проверка условия, которое может привести к другому узлу.

Поскольку вы сами создаете контейнеры узлов и можете называть их, действия в них выполняются предсказуемым образом (сверху вниз) — с этим я могу жить. :)

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

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

Вот введение в то, как это работает:
https://www.youtube.com/watch?v=I9VwsVtbgFU&index=2&list=PLC759306A1E692A10

Он очень гибкий и позволяет пользователю легко добавлять игровые функции и делиться ими — легко переназначать.

Увлекательное обсуждение. Просто хочу указать на другой тип/форму визуального сценария, отличный от узлов и листа событий C2, но блоки сценария, которые подходят друг к другу, как кусочки головоломки. Используется в 2D движке Stencyl http://www.stencyl.com/

на основе MIT Scratch http://wiki.scratch.mit.edu/wiki/Wait_Until_()_(block )

а в Unity я лично использую Blox http://www.plyoung.com/blox/

Меня лично не устраивает похожее на царапины «визуальное» программирование. я
думаю, что это очень похоже на программирование.
То, как Unreal делает это, я думаю, дружелюбно для дизайнеров игр/уровней.

В субботу, 21 марта 2015 г., в 23:57, [email protected] написал:

Увлекательное обсуждение. Просто хочу указать на другой тип/форму визуального
сценарии, отличные от узлов, но блоки сценариев, которые подходят друг к другу, например
кусочки головоломки. Используется в 2D движке Stencyl http://www.stencyl.com/
[изображение: stencil_blocks]
https://cloud.githubusercontent.com/assets/8675463/6767767/d52e7b16-d013-11e4-878c-29002dc04f8e.PNG
на основе MIT Scratch
http://wiki.scratch.mit.edu/wiki/Wait_Until_()_(блок )
[изображение: скретч_пример]
https://cloud.githubusercontent.com/assets/8675463/6767792/57f50e5c-d014-11e4-8015-9228bb6001d8.PNG
а в Unity я лично использую Blox http://www.plyoung.com/blox/
[изображение: hello_blox]
https://cloud.githubusercontent.com/assets/8675463/6767796/7849f46a-d014-11e4-9244-9e45c601f883.PNG

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-84508001 .

_ОкамСтудио_

Хорошая точка зрения. Для меня блоки — это нечто среднее между строками кода и блок-схемами.

Мне не нравится скретч/трафаретный способ визуального программирования. Его макет
визуально труднее следовать, чем блоки и даже узлы build2. это
буквально собирая кусочки головоломки, и он страдает от проблемы
выяснить, какая деталь куда подходит. Их не просто поставить
вместе

В воскресенье, 22 марта 2015 г., в 5:46, [email protected] написал:

Хорошая точка зрения. Для меня блоки — это средний путь между строками кода и потоком.
графики.

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-84511415 .

хорошо, я не буду сейчас читать все, а только свои 2 цента на эту тему.

Движки, основанные на событиях, создаются для создания прототипов и небольших игровых проектов.
такие движки, как godot, созданы для всех видов проектов

Так что это две разные вещи с двумя разными подходами, они две
разные сборы

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

Для меня лучший подход - две параллельные пошлины.

22.03.2015 6:49 GMT-03:00 Тодор Имреоров, [email protected] :

Мне не нравится скретч/трафаретный способ визуального программирования. Его макет
визуально труднее следовать, чем блоки и даже узлы build2. это
буквально собирая кусочки головоломки, и он страдает от проблемы
выяснить, какая деталь куда подходит. Их не просто поставить
вместе

В воскресенье, 22 марта 2015 г., в 5:46, [email protected] написал:

Хорошая точка зрения. Для меня блоки — это средний путь между строками кода и потоком.
графики.

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-84511415 .

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-84575752 .

Давид Агиар де Акино Пайва

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

2015-03-26 13:15 GMT-03:00 Дэвид Пайва [email protected] :

хорошо, я не буду сейчас читать все, а только свои 2 цента на эту тему.

Движки, основанные на событиях, создаются для создания прототипов и небольших игровых проектов.
такие движки, как godot, созданы для всех видов проектов

Так что это две разные вещи с двумя разными подходами, они две
разные сборы

честно говоря, я не могу использовать их хорошо.

Для меня лучший подход - две параллельные пошлины.

22.03.2015 6:49 GMT-03:00 Тодор Имреоров, [email protected] :

Мне не нравится скретч/трафаретный способ визуального программирования. Его макет

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

Вс, 22 марта 2015 г., 5:46, [email protected]
написал:

Хорошая точка зрения. Для меня блоки — это средний путь между строками кода и потоком.
графики.

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
< https://github.com/okamstudio/godot/issues/1220#issuecomment -84511415
.

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-84575752 .

Давид Агиар де Акино Пайва

Давид Агиар де Акино Пайва

Привет, ребята! Хорошая дискуссия здесь :) Я хотел бы добавить кое-что.

Во-первых: я студент художественного факультета, но программирование — мое хобби. Я знаю Java, Python и (мой любимый) Golang. Но до того, как я научился программировать (около 3 лет назад), я перепробовал почти каждую программу, которая утверждает, что позволяет «создавать игры без программирования». Все эти претензии - ерунда.

Я пробовал (в произвольном порядке): Click & Play, GameMaker, The Games Factory, Multimedia Fusion, Construct 1, RPG Maker, Stencyl, BGE и некоторые другие, которых я даже не помню. И мое мнение: вы можете сделать игру без _написания_ кода, но не без _программирования_. Даже если вы используете листы событий или узлы, вам все равно нужно понимать _логику программирования_. Вы должны знать, что такое условие, событие, переменная, строка и т. д. Так что невозможно создать игру без программирования. Все эти визуальные методы кодирования — это просто другой способ выражения логики, который есть в традиционных языках программирования. Весь этот аргумент может показаться очевидным, но уверяю вас, я не был очевиден для меня в начале моего приключения в программировании.

Отсюда следует следующее мое соображение:

Лучший и наиболее интуитивно понятный визуальный язык программирования, который я нашел до того, как научился программировать, — это Scrach/Stencyl Puzzle/Blocks Way. Вот почему:

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

* Я думаю, что блоки Scrach / Stencyl являются наиболее наглядным и простым методом. Они широко используют цвет (а люди с визуальным мышлением любят цвета). Легко запомнить, что желтый = условные выражения и циклы, зеленый = математика, синий = переменные и т. д. Также он выглядит как настоящий код (в отличие от узлов), но более дружественный.

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

КСТАТИ. Я хотел бы воспользоваться этой возможностью и поблагодарить всех создателей и участников Godot. Вы отлично поработали :+1:

Кстати2. Прошу прощения за мой английский. Я стараюсь изо всех сил, но все еще делаю глупые ошибки :cry:

будь то конструкт2 или блокс - они мне приятнее, чем те графы узлов.

Если система использует ноды только как контейнеры для действий (как состояния) — как в Playmaker, то меня это устраивает.

Что хорошо и в blox, и в build2, так это то, что редактор показывает вам все доступные условия и действия. Он разделяет их для вас и помещает в категории. Это резкое изменение в представлении, которое позволяет не кодировщику сразу многое делать с движком - без необходимости знать имена команд для выполнения каких-либо действий.

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

В плеймейкере путем укладки действий внутри контейнеров узлов (состояние — содержит действия). В блоке — там, где у вас есть состояния, содержащие функции.

Они дают полный доступ к большинству функций Unity. Это действительно приятно для непрограммистов.
Blox получил дальнейшее развитие в «plygame» — еще один аддон для единства, в котором есть blox + некоторые специально созданные скрипты, к которым blox может получить доступ, чтобы создать целую игру в стиле rpg hack and slash.

Blox в единстве такой же, как блоки Skrach/Stencyl. Кажется, здесь много людей, которым нравится такой стиль программирования :)
https://www.youtube.com/watch?v=Nd6Qy5ZipSs&list=PLuaBtUXEKcdIAA7_yjFNcLXM5YOf3WE9k

Надеюсь, разработчики Godot попробуют.
Кстати, технология Skratch (https://scratch.mit.edu/) имеет открытый исходный код! И другие переняли его - не только трафарет. Google тоже очень заинтересовался этим:
https://developers.google.com/blockly/

предложение - Почему бы не попробовать взять лучшее из обоих миров! Ноды для конечного автомата - blox/scratch/stencyl для выражений.
В идеальном мире у вас были бы узлы, используемые в качестве контейнеров состояний, как в Playmaker. Но у контейнера состояния будет система blox/stencyl/scratch, подобная лего, которая позволяет пользователю легко настраивать логику — не нужно учиться писать выражения таким образом — они просто готовы к перетаскиванию.

http://wiki.scratch.mit.edu/wiki/Scratch_1.4_Source_Code

Один из разработчиков iCanScript сказал об их активе VS следующее:

Технический прогресс iCS2 отделяет его от продукта Unity, что значительно расширяет рыночные возможности. Конечная цель заключается в том, что iCS2 станет средством разработки, которое можно будет использовать для создания скриптов для других игровых движков, а также для стандартных приложений Windows/OSX/iOS/Android.
http://forum.unity3d.com/threads/icanscript-visual-script-modeling-engine-for-unity.280847/#post -2124402

что за беспорядок в узлах iCanScript!

В любом случае стоит попробовать, прежде чем судить. Может кто зайдет
связаться с его разработчиком?
Если бы у Годо была торговая площадка с возможностями для получения прибыли, как та,
Unity делает — возможно, это привлекло бы разработчиков Unity к созданию ресурсов для
годо тоже.

В субботу, 23 мая 2015 г., в 16:24, [email protected] написал:

Один из разработчиков iCanScript сказал об их активе VS следующее:

Технический прогресс iCS2 отделяет его от Unity.
продукт значительно >увеличивает рыночные возможности. Конечная точка зрения
заключается в том, что iCS2 будет средством разработки, которое >можно использовать для создания сценария
для других игровых движков, а также для стандартных >Windows/OSX/iOS/Android
Приложения.

http://forum.unity3d.com/threads/icanscript-visual-script-modeling-engine-for-unity.280847/#post -2124402

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-104895405 .

Я думаю, что список событий в Construction 2 действительно прост для понимания и программирования.

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

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

Подход Construct 2 кажется простым. Для меня это выглядит так:

1 событие: действие;

2 Событие: действие;
: Действие;

Это в основном программирование, но очень легко для понимания. Если бы они использовали просто язык вместо блока, я бы не возражал. Используя этот шаблон, мне легко создать логику.

Использование узлов может очень быстро выйти из-под контроля, поскольку вещи начинают распространяться, и вы тратите больше времени на поиск узлов, чем на код (как я понял из Unity и Playmaker).

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

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

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

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

В воскресенье, 24 мая 2015 г., в 3:58, [email protected] написал:

Я думаю, что лист событий Construction 2 действительно прост для понимания и
программа в.

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

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

Подход Construct 2 кажется простым. Для меня это выглядит так:

1 событие: действие;

2 Событие: действие;
: Действие;

Это в основном программирование, но очень легко для понимания. Если они
использовал бы только язык вместо блока, я бы не возражал. Используя это
Pattern легко создать логику для меня.

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

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

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

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

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-104985159 .

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

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

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

Вс, 24 мая 2015 г., 10:15, Хуан Линиецки, уведомления на адрес github.com
написал:

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

В воскресенье, 24 мая 2015 г., в 3:58, [email protected] написал:

Я думаю, что лист событий Construction 2 действительно прост для понимания и
программа в.

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

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

Подход Construct 2 кажется простым. Для меня это выглядит так:

1 событие: действие;

2 Событие: действие;
: Действие;

Это в основном программирование, но очень легко для понимания. Если
Oни
использовал бы только язык вместо блока, я бы не возражал. С использованием
это
Pattern легко создать логику для меня.

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

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

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

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

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
< https://github.com/okamstudio/godot/issues/1220#issuecomment -104985159
.

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-104985669 .

Подход Construct2 к программированию очень похож на подход в
Clickteam fusion, у которого тоже много пользователей. Легкость в этом исходит от
ряд вещей, хотя это похоже на программирование:

• Имея все возможные УСЛОВИЯ, перечисленные и доступные пользователю для выбора
  добавить, нажав/перетащив на простом английском языке - это бесценно
  потому что им не нужно учить волшебные слова. Они могут просто перетащить и
  бросить их.
• Имея все возможные ДЕЙСТВИЯ, перечисленные и доступные пользователю для выбора
  добавить, щелкнув / перетащив на простом английском языке - это неоценимо
  потому что им не нужно учить волшебные слова. Они могут просто перетащить и
  бросить их.
• то же самое происходит при выполнении любых выражений как при настройке, так и при
  действие или условие. Когда вы пишете выражения, редактор помогает вам
  с простым выпадающим списком вещей, которые можно получить из существующих объектов в
  место действия. Вам не нужно учиться, как добраться до этих свойств, поскольку они
  уже доступны в пару кликов.

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

Вс, 24 мая 2015 г., 10:17, Тодор Имреоров [email protected]
написал:

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

Вс, 24 мая 2015 г., 10:15, Хуан Линиецки < [email protected]

написал:

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

Вс, 24 мая 2015 г., 03:58, [email protected]
написал:

Я думаю, что лист событий Construction 2 действительно прост для понимания и
программа в.

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

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

Подход Construct 2 кажется простым. Для меня это выглядит так:

1 событие: действие;

2 Событие: действие;
: Действие;

Это в основном программирование, но очень легко для понимания. Если
Oни
использовал бы только язык вместо блока, я бы не возражал. С использованием
это
Pattern легко создать логику для меня.

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

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

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

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

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
< https://github.com/okamstudio/godot/issues/1220#issuecomment -104985159
.

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-104985669 .

Также посмотрите на это с точки зрения дизайнера, который хотел бы научиться кодировать сложную логику и в конечном итоге стать достаточно уверенным, чтобы научиться программировать. Я вижу, откуда вы исходите, поскольку вы видите, что система будет использоваться командой дизайнеров и программистов. Лично я хотел бы использовать Godot в одиночку, а не в команде с программистом, как многие инди-разработчики игр. Система событий снисходительна и кажется более организованной при использовании групп, когда у вас более 1000 событий.

Кроме этого, у меня нет проблем с системой узлов, и если godot удастся создать систему, которая будет лучше, чем текущая, я буду использовать ее до чертиков.

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

Учтите, что листы событий в build2/clickteam устраняют необходимость изучения
синтаксис - так что пользователю не нужно знать, куда положить вещи - то есть
очень очевидно. Условия слева, действия справа. Получатель чего-то
выполнение события также очень очевидно.
Детали Lego в скретч/стенсиле/единичном блоке не так очевидны, но все же
намного лучше, чем кошмар узлов, представленный в «iCanScript». ты смотрел
в их видеоуроке. Это супер запутанный дизайн визуального программирования
с довольно крутой кривой обучения. Я думаю, что даже если вы дадите его
программист, им будет трудно понять это

В воскресенье, 24 мая 2015 г., в 10:33, [email protected] написал:

Также посмотрите на это с точки зрения дизайнера, который хотел бы научиться
кодировать сложную логику и в конечном итоге стать достаточно уверенным, чтобы научиться программировать.
Я вижу, откуда вы пришли, поскольку вы видите, что система будет использоваться
команда дизайнеров и программистов. Я лично хотел бы использовать Godot как
одиночный пользователь, а не в команде с программистом, как во многих инди-играх
Разработчики. Система событий прощает ошибки и кажется более организованной при использовании
группы, когда у вас есть 1000+ событий.

Кроме этого, у меня нет проблем с системой узлов, и если godot удастся
создай систему лучше нынешней
Это.

Кроме того, если возможно, создайте функцию поиска, чтобы найти блоки/узлы кода.
без труда.

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-104988595 .

Они даже больше не продают «icanscript» в магазине активов единства.
Посмотрите там цифры продаж - какой из доступных визуальных программ
systems используется чаще всего и имеет завершенные проекты.

Я просто оставлю вас с этим видео:
https://www.youtube.com/watch?v=3Zq1yo0lxOU
В нем 167 игр, созданных с помощью clickteam fusion людьми, у которых нет
опыт программирования.

Также обратите внимание на успешные игры на кикстартере, созданные с помощью фьюжн.
https://www.kickstarter.com/projects/alonsomartin/heart-forth-alicia/description
https://www.kickstarter.com/projects/galaxytrail/freedom-planet-high-speed-platform-game/description
https://www.kickstarter.com/projects/2064021040/тини-трек

нужно также упомянуть Five Nights at Freddy's (сделано в clickteam fusion):
http://en.wikipedia.org/wiki/Five_Nights_at_Freddy%27s_%28video_game%29
эта игра является бестселлером. Вот вам цифры:
https://thinkgaming.com/app-sales-data/8779/five-nights-at-freddys/

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

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

Вс, 24 мая 2015 г., 10:42, Тодор Имреоров [email protected]
написал:

Учтите, что листы событий в build2/clickteam устраняют необходимость изучения
синтаксис - так что пользователю не нужно знать, куда положить вещи - то есть
очень очевидно. Условия слева, действия справа. Получатель чего-то
выполнение события также очень очевидно.
Детали Lego в скретч/стенсиле/единичном блоке не так очевидны, но
все же намного лучше, чем кошмар узлов, представленный в «iCanScript». Сделал
вы посмотрите на их видео-учебник. Это супер запутанный визуальный
дизайн программирования с довольно крутой кривой обучения. Я думаю, что даже если
вы отдадите это программисту, они не смогут понять это

Вс, 24 мая 2015 г., 10:33, [email protected]
написал:

Также посмотрите на это с точки зрения дизайнера, который хотел бы
научиться кодировать сложную логику и в конечном итоге стать достаточно уверенным, чтобы научиться
код. Я вижу, откуда вы пришли, поскольку вы видите, что система будет использоваться
команда дизайнеров и программистов. Я лично хотел бы использовать Godot
в одиночку, а не в команде с программистом, как многие инди
разработчики игр. Система событий прощает ошибки и кажется более организованной.
используя группы, когда у вас есть 1000+ событий.

Кроме этого, у меня нет проблем с системой узлов, и если godot удастся
создай систему лучше нынешней
Это.

Кроме того, если возможно, создайте функцию поиска, чтобы найти блоки/узлы кода.
без труда.

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-104988595 .

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

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

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

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

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

Ваше здоровье.

Я не возражаю против узлов, если они сделаны как в плеймейкере - как
контейнеры действий (состояния).
Узлы на самом деле не используются для установки действий или условий.

Однако если вы сделаете их похожими на «iCanScript», у вас будет полный беспорядок.

1. трудно сказать, в каком порядке выполняются события
2. Трудно понять, какой узел может быть подключен к какому узлу
3. для настройки одного действия требуется много узлов и шагов, чем для
   перетащите его и настройте в нем выражение (стиль construct2/clickteam
4. где вам помогут с синтаксисом - это отличный способ представить
   кого-то программировать, не требуя от них чтения тонны
   документации - для них все есть в выпадающем меню
   объект).

В воскресенье, 24 мая 2015 г., в 11:20, [email protected] написал:

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

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

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

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

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

Ваше здоровье.

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-104990083 .

Я голосую за @whoisda в том, что касается чего-то нового для/в Годо. Однако существует три школы визуального скриптинга: 1) узлы, 2) листы событий, 3) блоки. Из этих трех узлов, похоже, лидируют в 3D-средах. Говоря об этом, я где-то читал идею, предполагающую, что сценарии/программы выходят за рамки линейного (текст, блоки, список событий) или горизонтального (узлы) формата и программируются в 3D с использованием структур. Не знаю, как это сработает, но звучит заманчиво.

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

Узлы для создания конечного автомата.
Блоки или листы событий для создания действий внутри каждого узла (состояния).

В воскресенье, 24 мая 2015 г., в 13:56, [email protected] написал:

Я голосую за @whoisda https://github.com/whoisda в отношении чего-то
обновляется для/в Годо. Однако, кажется, есть три визуальных
Скриптовые школы: 1) узлы, 2) листы событий, 3) блоки. Из этих трех
узлы, кажется, лидируют в 3D-средах. Говоря о которых
Я где-то читал идею, предлагающую вырваться из
линейный (текст, блоки, список событий) или горизонтальный (узлы) формат и
программировать в 3D с использованием структур. Не уверен, как это будет работать, но звучит
очаровательный.

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-105001411 .

Было бы здорово, если бы мы могли использовать узлы и события вместе. Узлы могут быть состояниями, которые, если следовать простой логике, могут быть подключены к другим узлам или могут быть контейнерами для сценариев/блоков/листов событий, таким образом, у нас не будет очень больших узлов, и мы также можем сотрудничать в команде. Но это может быть слишком много для разработчика. Тем не менее, идея кажется очень хорошей.

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

Я лично хотел бы увидеть ЛЮБЫЕ первые шаги в визуальном программировании.
направление. Даже если разработчик сделает конечный автомат, работающий с gd
скрипты - это было бы удивительным началом, которое даже продвинутые программисты
был бы признателен.

Затем, возможно, после этого у нас может быть что-то визуальное, например, трафарет или
конструкция2 — это как код, но гораздо проще, чем код — внутри
состояния.

Так что на самом деле это два запроса функций!

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

В конце концов, главный разработчик знает, что лучше для дизайна godot.

Во вторник, 26 мая 2015 г., в 11:43, [email protected] написал:

Было бы здорово, если бы мы могли использовать узлы и события вместе. Узлы могут
состояния, которые, если следовать простой логике, могут быть подключены к другим узлам или
могут быть контейнерами для скриптов/блоков/листов событий, таким образом у нас не будет
очень большие узлы, а также могут работать в команде. Но это может быть слишком
многое для разработчика. Тем не менее, идея кажется очень хорошей.

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-105446984 .

я скоро проверю styencyl, потому что я не знаком с ним.
на данный момент из всего, что я видел/читал, я могу сделать вывод, что:

1) Чертеж: отлично подходит для дизайнеров игр/уровней, но не настолько хорош для
визуальное программирование
2) Stencyl: гораздо лучше подходит для визуального программирования, но непригоден для
геймдизайнеры/дизайнеры уровней

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

Во вторник, 26 мая 2015 г., в 6:10, Тодор Имреоров, [email protected]
написал:

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

Я лично хотел бы увидеть ЛЮБЫЕ первые шаги в визуальном программировании.
направление. Даже если разработчик сделает конечный автомат, работающий с gd
скрипты - это было бы удивительным началом, которое даже продвинутые программисты
был бы признателен.

Затем, возможно, после этого у нас может быть что-то визуальное, например, трафарет или
конструкция2 — это как код, но гораздо проще, чем код — внутри
состояния.

Так что на самом деле это два запроса функций!

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

В конце концов, главный разработчик знает, что лучше для дизайна godot.

Во вторник, 26 мая 2015 г., в 11:43, whoisda уведомления@github.com
написал:

Было бы здорово, если бы мы могли использовать узлы и события вместе. Узлы могут
состояния, которые, если следовать простой логике, могут быть подключены к другим узлам
или
могут быть контейнерами для скриптов/блоков/листов событий таким образом мы не будем
имеют
очень большие узлы, а также могут работать в команде. Но это может быть
слишком
многое для разработчика. Тем не менее, идея кажется очень хорошей.

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
< https://github.com/okamstudio/godot/issues/1220#issuecomment -105446984
.

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-105458142 .

http://www.emanueleferonato.com/wp-content/uploads/2011/12/stencyl05.png

Это канонический пример того, как выглядит трафаретный «код»? Если да, то это кажется ужасной идеей: похоже на стандартное кодирование в визуальных обертках для детского сада. Да ладно, Python уже достаточно прост, чтобы его могла прочитать моя жена, так почему бы не приложить усилия для изучения основ?

Если говорить о визуальном программировании, то то, что уже есть у Godot, намного лучше — графы шейдеров или графы анимации: код, завернутый в визуальные узлы.
https://frenchdog.files.wordpress.com/2009/09/specular_reflexion_vops.jpg — еще один пример программирования на основе визуальных узлов (Sidefx Houdini или XSI). Он взрослый и не похож на детскую игрушку, а также напоминает мне узлы Годо.

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

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

Разработчики Stencyl приняли технологию «скретч» с открытым исходным кодом. Это не их дизайн.
https://scratch.mit.edu/about/
http://en.wikipedia.org/wiki/Scratch_ (язык_программирования)
http://wiki.scratch.mit.edu/wiki/Scratch_1.4_Source_Code

Примеры использования Scratch другими игровыми движками, предназначенными для непрограммистов:

• Стенцил (самый популярный) http://www.stencyl.com/
  
• Ремесленная студия (http://craftstud.io/)
  
• гугл блокли (https://developers.google.com/blockly/)
• Наиболее близким к Godot является инструмент визуального программирования Unity «Blox»:
  
  https://www.youtube.com/watch?v=Nd6Qy5ZipSs&list=PLuaBtUXEKcdIAA7_yjFNcLXM5YOf3WE9k
  Вместо Lua он генерирует C#.
  полная документация здесь:
  http://www.plyoung.com/blox/
  и продается здесь: https://www.assetstore.unity3d.com/en/#!/content/12859

Опытным программистам это может показаться ужасной идеей, но это лучший способ научить непрограммистов писать код или просто дать им возможность программировать, не зная волшебных слов или синтаксиса. Скретч делает их доступными для перетаскивания, создавая правильную структуру с помощью визуальных подсказок. Пожалуйста, посмотрите плейлист видео «Unity Blox», который я разместил, чтобы увидеть его в действии. Более того, это неоднократно подтверждалось на практике. Это выглядит как самая безопасная ставка.

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

Использование обоих кажется лучшим подходом. Если не Unity blox, то даже если вы посмотрите на Playmaker, вы увидите, что узлы там действительно являются контейнерами — где действия могут быть сложены — очень похоже на sencyl. Вы перетаскиваете их из списка!

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

Тогда я не понимаю, на какую аудиторию рассчитан этот таргетинг. Нацелен ли Godot конкурировать с большими мальчиками на рынке (Unreal Engine, Unity и т. д.) или научить детей программировать/создавать игры, как это делает Scratch (https://scratch.mit.edu/)?

Я знаю, что такое узлы (ввод -> функция с параметрами -> вывод), с изложением не согласен.

Stencyl и Playmaker отлично подходят для обучения детей программированию, но они успешно используются непрограммистами (как студиями, так и инди) для создания успешных игр, которые продаются на разных платформах.
Если вы относите Unity к большим мальчикам, то вы должны знать, что большие мальчики также занимаются визуальным программированием.
http://www.hutonggames.com/showcase.html

Я думаю, что у godot есть много возможностей для использования большими мальчиками. Несколько функций, позволяющих небольшим/независимым компаниям, могли бы способствовать более быстрому внедрению движка. А природа с открытым исходным кодом и экономичное лицензирование очень выгодны для начинающих.

@blurymind
Я _не_ выступаю против визуального программирования. Я бы сказал, что у Godot уже есть то, что ему нужно (ShaderGraphs): тот же визуальный подход может быть расширен до логического программирования конечного автомата или общего программирования. Против чего я выступаю, так это против принятия еще одной визуальной парадигмы (~ скретч), которая не отпугнет детей.

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

Самое главное, что я хочу сделать здесь, это то, что:

• порядок выполнения действий должен быть понятен! Выполнение всей логики с узлами может очень быстро запутаться. Таким образом, узлы должны использоваться для состояний imo.
• Разработчики Playmaker очень умно предвидели эту проблему, и именно поэтому они сделали так, чтобы узлы были контейнерами действий, в которые — очень похоже на Stencyl — вы перетаскиваете доступные действия из списка:
  
  и складывайте события таким образом

В итоге вы получите очень чистую и эффективную настройку узла!

Я предлагаю разработчикам Godot также попробовать playmaker.
Замена стека событий логикой Stencyl сделает подход godot к нему намного более гибким/мощным!.

Это не должно быть только с помощью трафаретного подхода. Я думаю, вы можете позволить опытным программистам прикреплять gd-скрипты к узлам. Имея возможность использовать трафаретный подход для создания gdscripts, было бы неоценимо. Это пригласит много новых пользователей в сообщество godot.

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

Вы должны спросить себя: хотите ли вы, чтобы больше непрограммистов использовали Godot? Вы хотите, чтобы люди, не имеющие опыта работы с gdscript, могли сделать что-нибудь веселое?

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

• Узлы используются как конечный автомат, как в Playmaker! Программисты могут дать имя каждому узлу и прикрепить к нему gdscripts — с настроенными входом и выходом. Так что это совсем не для детей. На самом деле, это гораздо более гибкий подход для программистов, который гораздо менее запутан.
• Перетаскивание листа событий или интерфейса блоков в качестве альтернативного способа создания GDscript. Таким образом, вместо того, чтобы писать GdScript для присоединения к узлу, непрограммисты могут просто складывать действия из списка всех доступных событий в godot — так же, как Playmaker. Чтобы сделать еще один шаг вперед и внедрить инновации — вместо того, чтобы просто складывать действия, было бы еще лучше использовать блоки, подобные Stencyl.

Таким образом, у вас есть что-то полезное как для программистов, так и для непрограммистов. Они оба могут использовать конечный автомат (узлы), а непрограммистам не нужно сразу изучать gdscript и вместо этого использовать gdBlocks для генерации gdscript для узла (опять же — как в Playmaker).

@blurymind
Мне это больше нравится. Также это согласуется с графом узлов шейдера и текстом шейдера, который уже есть в Godot.

В SideFX Houdini есть что-то под названием VEX (https://goo.gl/TMWNKk) ("векторное выражение" - это c-подобный язык, предназначенный для векторной алгебры). Это несколько синоним gdScript. Также у него есть что-то, называемое «VOPs» (http://goo.gl/Qpn2OE) (операторы Vex) — по сути, визуальные оболочки подмножества VEX, которые очень похожи на изображение графа узлов LeadWerks, на которое вы ссылались выше. На самом деле, VOP при необходимости можно превратить в текст-скрипт (но не наоборот).

Сосуществование двух вполне естественно и позволяет даже непрограммистам создавать очень беспорядочный и неэффективный код;)

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

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

Но Godot не простой игровой движок (по крайней мере, по сравнению со Stencyl), поэтому я
не думайте, что упрощенное программирование будет таким полезным. Стенсил опирается на
много жестко запрограммированной игровой логики, которая просто не будет доступна в
Годо, и попытка сделать его доступным будет противоречить цели Годо
являющийся очень универсальным игровым движком.

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

26 мая 2015 г., 11:29, Владимир Лопатин < [email protected]

написал:

@blurymind https://github.com/blurymind
Мне это больше нравится. Также это согласуется с Shader node-graph vs.
Шейдер-текст, который уже есть в Godot.

У SideFX Houdini есть что-то холодное VEX (https://goo.gl/TMWNKk) ("вектор
выражение" c-подобный язык, предназначенный для векторной алгебры).
несколько синоним gdScript. Также у него есть что-то под названием «VOPs» (
http://goo.gl/Qpn2OE) (Vex Operators) — по сути визуальные обертки
подмножество VEX, которые очень похожи на граф узлов LeadWerks, который вы
упомянутые выше. На самом деле, VOPs можно превратить в скрипт, если это необходимо.
(но не наоборот).

Сосуществование двух вполне естественно и позволяет, даже
непрограммисты, чтобы создать очень грязный и неэффективный код;)

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-105543845 .

Как насчет объединения действий в Playmaker и блоков в Unity? Unity не очень простой движок.

Я думаю, что stencyl не очень хороший пример. Примеры лучше поискать в магазине ассетов Unity.

Я пытался понять плеймейкер, но не смог, как он должен работать?

Вт, 26 мая 2015 г., 12:16, Тодор Имреоров, [email protected]
написал:

Как насчет объединения действий в Playmaker и блоков в Unity? Единство не является
очень простой двигатель.

Я думаю, что stencyl не очень хороший пример. Лучше поискать
примеры в магазине активов единства.

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-105561760 .

проверял туториал плеймейкера, но похоже на stencyl в
ощущение, что он поставляется с миллионом предопределенных поведений

Во вторник, 26 мая 2015 г., в 12:19, Хуан Линиецки, [email protected]
написал:

Я пытался понять плеймейкер, но не смог, как он должен работать?

Вт, 26 мая 2015 г., 12:16, Тодор Имреоров < [email protected]

написал:

Как насчет объединения действий в Playmaker и блоков в Unity? Единство не является
очень простой двигатель.

Я думаю, что stencyl не очень хороший пример. Лучше поискать
примеры в магазине активов единства.

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
< https://github.com/okamstudio/godot/issues/1220#issuecomment -105561760
.

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-105563777 .

_ОкамСтудио_

Наиболее близким в Unity к чертежам U4 является uScript:
https://www.assetstore.unity3d.com/en/#!/content/1808

Кажется, что люди предпочитают Playmaker, а не usscript, так как легче понять установленную логику. Как видно из скриншотов, даже для простой логики это становится очень запутанным.

@reduz @okamstudio вот плейлист на playmaker:
https://www.youtube.com/watch?v=I9VwsVtbgFU&index=2&list=PLC759306A1E692A10
Я думаю, что вы должны использовать его на некоторое время. Вы можете создавать предопределенные поведения и сценарии, но плеймейкер также позволяет вам получить доступ к основным функциям движка и самостоятельно создавать такие поведения с нуля.

Да, плеймейкер — это конечный автомат, и единство имеет множество предопределенных вариантов поведения.
Годо тоже есть - они встроены в движок.
Я все еще верю, что вы действительно можете создать сценарий/поведение с нуля, используя блок клонирования Unity.

Я думаю, наконец, вам нужен программист, чтобы сделать нормальную игру, и эта идея
здорово, что геймдизайнер сам делает игру, но я думаю, что это много
работы, которая во многих случаях не пригодится. но если у нас больше
функция для самого редактора, как дизайнер платформера, который кто-то другой
упоминается в другом выпуске или другие полезные вещи, чтобы упростить пользовательский интерфейс
дружелюбнее.
26 мая 2015 г., 19:52, «Okam Studio» [email protected] написал:

проверял туториал плеймейкера, но похоже на stencyl в
ощущение, что он поставляется с миллионом предопределенных поведений

Во вторник, 26 мая 2015 г., в 12:19, Хуан Линиецки < [email protected]

написал:

Я пытался понять плеймейкер, но не смог, как он должен работать?

Вт, 26 мая 2015 г., 12:16, Тодор Имреоров <
уведомления@github.com

написал:

Как насчет объединения действий в Playmaker и блоков в Unity? Единство
не
очень простой двигатель.

Я думаю, что stencyl не очень хороший пример. Лучше поискать
примеры в магазине активов единства.

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
<
https://github.com/okamstudio/godot/issues/1220#issuecomment -105561760
.

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
< https://github.com/okamstudio/godot/issues/1220#issuecomment -105563777
.

_ОкамСтудио_

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-105565084 .

вот обзор в магазине активов единства для uScript:

Хороший инструмент, но его трудно освоить, если вы не программист... ответы на запросы о помощи на форумах очень медленные или вообще отсутствуют...

Что бы ни оказалось в Godot, я думаю, если это возможно, было бы неплохо разрешить одностороннее преобразование в GDScript. Это позволило бы дизайнерам, художникам и т. д. быстро настраивать вещи визуально, а затем позволяло бы кодерам в команде дополнительно настраивать и перерабатывать их без необходимости использовать щелчок.

@adolson Это была бы очень желанная функция :)

это можно сделать, а также можно сделать с помощью визуального редактора шейдеров
(который на самом деле генерирует код шейдера)
но я думаю, что сгенерированный код шейдера будет не так читаем, как вы могли бы
ожидать: Р

Во вторник, 26 мая 2015 г., в 18:33, Натан[email protected] написал:

@adolson https://github.com/adolson Это было бы очень желательно
особенность :)

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-105670945 .

@reduz Ожидаются некоторые метаданные.
Вот пример преобразования VOPs -> VEX, как указано выше:
:
А вот и полный листинг кода , который иначе в чистом VEX выглядит так:
@P += вектор({0,1,0}); // берем позицию и добавляем вектор (0,1,0)

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

@reduz Это правда. Я действительно не думал об этом. Вероятно, это будет не тот код, в котором большинство программистов хотели бы проводить свое время. Я мог видеть, как метки становятся именами переменных и тому подобное, но я не вижу слишком многого, чтобы смягчить проблему.

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

Вы, ребята, действительно перебрали гамму вариантов. Я использовал Construct 2, и хотя он аккуратный, вы никогда не сможете коснуться какого-либо кода, чтобы улучшить его, а возможности были довольно ограниченными. Обновление тайловой карты в основном избавилось от префабов и, следовательно, от инстансов. Больше всего мне понравился PlayMaker для Unity.

Что-то в этом было очень легко понять ваши возможности и то, что вам нужно было сделать. Это действительно привлекательный фактор, именно из-за этого мне нравится использовать визуальные скрипты. Я теряю из виду, что я делал или что мне нужно делать в текстовом коде, но наблюдение за тем, как все «соединяется», приносит мне наибольшую пользу. NateWardog опубликовал пример на скриншоте намного раньше, а blurrymind — совсем недавно.

Я говорю редуз, ты дерзай. На данный момент, если вы собираетесь беспокоиться, я бы выбрал 1.3 или более позднюю версию, и даже тогда в основном сосредоточился на ее интерфейсной стороне. Затем, когда он будет готов позже, сосредоточьтесь на том, чтобы заставить его выводить читаемый код, такой как Blueprint, что, я думаю, было бы очень сложно. Пожалуйста, не недооценивайте это!

Подписка. Меня это тоже очень интересует! Я знаю некоторые сценарии и не против их использования... но я предпочитаю подключать узлы, когда это возможно! Что-то вроде логических блоков в движке Blender Game Engine, которые действуют как визуальные ярлыки для скриптовых функций Godot в качестве альтернативы написанию их вручную... это была бы прекрасная функция, которую я активно жду.

визуальные сценарии действительно привлекают многих творческих людей или людей, которые не хотят изучать новый язык сценариев, такой как gd script. Я смотрел на создателя игр, который чертовски популярен, и самая главная причина — это визуальная механика сценариев.

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

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

В четверг, 14 апреля 2016 г., в 8:33, Реми Вершельде[email protected]
написал:

Редактировать: я вижу, вы изменили «RPG Maker» на «Game Maker», теперь он делает больше
смысл :p Удаление моего поста.

—
Вы получаете это, потому что подписаны на эту тему.
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/godotengine/godot/issues/1220#issuecomment -209770726

Не хочу, но должен сказать, но это очень узкий взгляд на инструменты визуального скриптинга, Сергей. Что касается игр, которые были полностью созданы с их помощью, некоторые движки полностью отказались от них, например Construct, поэтому вы не увидите ни одной игры на этом движке, созданной с использованием обычных сценариев. Другие (более вменяемые, имхо) движки имеют такие плагины, как Unity и UE4. Лично мне очень нравилось использовать и uscript, и PlayMaker в Unity вместе с моим обычным кодом, потому что, хотя некоторые вещи легче закодировать, многие легче написать визуально, особенно конечные автоматы, потому что визуальный скриптер, такой как PM, дает вам много обратной связи с breakpointsw, так намного проще смотреть на проект с более широкой точки зрения.

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

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

В четверг, 14 апреля 2016 г., в 9:09, Аарон М[email protected] написал:

Я не хочу этого говорить, но это очень узкий взгляд на визуальное
скриптовые инструменты, Сергей. Что касается игр, которые были полностью сделаны с их помощью,
некоторые движки полностью отказались от них, например Construct, так что вы
не увидит ни одной игры на этом движке, сделанной с помощью обычных скриптов. Другой
(более вменяемый, imo) движок имеет такие плагины, как Unity и UE4. Я лично
мне очень понравилось использовать как uscript, так и PlayMaker в Unity вместе с моим обычным
код, потому что, хотя некоторые вещи легче кодировать, многие легче
сценарий визуально, особенно конечные автоматы, потому что с визуальным
скриптер, такой как PM, он дает вам много отзывов с точками останова, это просто
так намного проще смотреть на проект с более широкой точки зрения.

—
Вы получаете это, потому что вы прокомментировали.
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/godotengine/godot/issues/1220#issuecomment -209776732

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

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

Если вы хотите улучшить программирование, сделайте инструменты лучше. Подсветка кода, завершение кода, проверка кода, шаблоны кода и т. д. Сделайте отладчик лучше и сделайте Liveprogramming.
Я всегда искал стабильную среду Liveprogramming, но до сих пор не нашел!

Если вы действительно хотите создать Visual Scripting, сделайте его как Stingray Engine. Вы можете создавать CodeBlocks в Visual и генерировать TextCode, который вы можете изменить позже, или написать TextCode, который вы сможете позже использовать в качестве Visual Blocks.

Я бы не сказал, что это бесполезно, но я бы сказал, что речь идет о 2
совершенно разные продукты.

Если вы управляете студией и делаете игры с участием, скажем, 20-80 человек,
вы ежемесячно тратите шестизначные суммы на производственные затраты, и вам нужен
движок для создания игр, вам нужен определенный продукт. В таком случае вы
не заботитесь об инструментах визуального скриптинга, вы заботитесь о других
вещи, например, насколько продуктивной будет ваша команда с инструментами движка
(поскольку, если они выйдут за рамки графика на один месяц, вы потеряете ~ 100 тысяч долларов). Те
в командах есть программисты, и они будут намного продуктивнее писать код
чем использование какого-либо визуального инструмента (поищите пример этого на Vicious Engine)

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

Это 2 разных продукта, и если спорить о том, какой из них дороже
имея, мы должны признать это. Я бы сказал, что визуальный сценарий
инструмент на самом деле не масштабируется до более чем 1 человека, делающего прототип. В виде
как только вы захотите сделать полноценную игру, или как только ваша команда вырастет до 2-3
народ, вам уже нужен настоящий язык программирования. Так что мне нравится первый
пример больше как общая цель (если только вы не хотите 3-й продукт, который
"движок, который вы можете использовать для создания полноценной инди-игры, которая приносит миллионы
без написания кода». Этого не существует).

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

14.04.2016 в 03:26 Сергей Лапин [email protected] написал:

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

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

В четверг, 14 апреля 2016 г., в 9:09, Аарон М[email protected] написал:

Я не хочу этого говорить, но это очень узкий взгляд на визуальное
скриптовые инструменты, Сергей. Что касается игр, которые были полностью сделаны с
их,
некоторые движки полностью отказались от них, например Construct, так что вы
не увидит ни одной игры на этом движке, сделанной с помощью обычных скриптов. Другой
(более вменяемый, imo) движок имеет такие плагины, как Unity и UE4. Я лично
мне очень понравилось использовать как uscript, так и PlayMaker в Unity вместе с моим обычным
код, потому что, хотя некоторые вещи легче кодировать, многие легче
сценарий визуально, особенно конечные автоматы, потому что с визуальным
скриптер, такой как PM, он дает вам много отзывов с точками останова.
просто
так намного проще смотреть на проект с более широкой точки зрения.

—
Вы получаете это, потому что вы прокомментировали.
Ответьте на это письмо напрямую или просмотрите его на GitHub
< https://github.com/godotengine/godot/issues/1220#issuecomment -209776732

—
Вы получаете это, потому что подписаны на эту тему.
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/godotengine/godot/issues/1220#issuecomment-209779422

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

Классная тема, много мнений 😁

Мой простой. Вы в порядке!

Любая из этих идей станет отличным дополнением к gdscript 😁

Я с нетерпением жду, чтобы попробовать их, когда они появятся.

Я думаю, что gdscript также мог бы быть более удобным для пользователя.

Некоторые узлы не полностью задокументированы. Многое без описания.
Godot может использовать некоторые вспомогательные функции для упрощения разработки. Gamemaker gml — хороший пример:
https://twitter.com/uheartbeast/status/724326557108461568

Я думаю, что документация является основным PITA здесь, и это все.
Сама разработка достаточно проста. Документация и учебные пособия
действительно нужны. Так что просто сделайте свой аккаунт на YouTube полезным (или блогом, или
просто напишите на форуме)
это очень поможет.

В понедельник, 25 апреля 2016 г., в 9:35, Тодор Имреоров, [email protected]
написал:

Я думаю, что gdscript также мог бы быть более удобным для пользователя.

Некоторые узлы не полностью задокументированы. Многое без описания.
Godot может использовать некоторые вспомогательные функции для упрощения разработки.
Gamemaker gml — хороший пример:
https://twitter.com/uheartbeast/status/724326557108461568

—
Вы получаете это, потому что вы прокомментировали.
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/godotengine/godot/issues/1220#issuecomment-214163012

Ну, у меня есть несколько мыслей на этот счет.
Вы можете упростить доступ к движку, включив что-то вроде визуального сценария, и это было бы хорошо для всех художников, которые хотели заняться созданием игр, но просто не имеют опыта программирования, но это привлекает совершенно другой набор людей, а именно , люди без каких-либо навыков. Люди, для которых переход на программирование в текстовом редакторе никогда не будет на повестке дня, даже если это означает, что конечная игра пострадает. Люди, которые думают, что единственное сложное в создании игры — это программирование, а с визуальным сценарием это ограничение внезапно снимается. Это тоже не редкость. Просто взгляните на все популярные движки, которые упрощают некоторые вещи для непрограммистов — тонны лопатообразных программ. Я не говорю, что вы не должны включать визуальные сценарии, потому что это означает, что мы рискуем получить shovelware, но что это должно быть реализовано таким образом, чтобы такие люди не думали, что они могут просто использовать Godotengine для создания shovelware.
Другая моя проблема заключается в том, что одна из вещей, в которых Godotengine хорош, и многим людям нравится эта функция, заключается в том, что она очень хорошо работает с git. Проблема с визуальным сценарием заключается в том, что он часто сохраняется в каком-то двоичном формате, и с ним сложно справиться, если вы используете какую-либо версию исходного кода. Если вам нужно реализовать визуальный сценарий, то его следует сохранить в текстовом виде. И если это невозможно, ну жестко. Я бы предпочел иметь файлы проекта в Godotengine в формате, совместимом с git, чем иметь визуальные сценарии, которые не очень хорошо работают с git.
И судя по всей работе, которая требуется для реализации системы визуального скриптинга, и тому факту, что вы можете делать определенные типы игр в Godotengine без визуального скриптинга без какой-либо потери функциональности, эффективности или производительности, что плохого в том, чтобы просто реализовать его как плагин? Я действительно не вижу причин, почему это должно быть основной частью двигателя.

Просто добавлю свои 2 цента о визуальном сценарии и о том, почему мне не нравится эта идея:

Я думаю, что возможность подключения узлов в любом файле gdscript намного лучше с точки зрения управления кодом и мастерства.

Например, с визуальным сценарием (или с использованием листа событий, подобного C2), что произойдет, если у вас есть более 1000 функций? Я считаю, что будет намного хуже ориентироваться во всем. Прямо сейчас я портирую свою RPG-игру HTML 5 в Godot (это более 10 тысяч строк кода и гораздо более 500 функций). _(В нем есть практически все функции Path of Exile, кроме анимации и многопользовательской игры)_

Для меня это было бы невозможно с визуальным сценарием. Я думаю, что мы и разработчики Godot здесь должны больше сосредоточиться на функциях / устранении ошибок, чем на визуальном листе событий кода. Но это только я :)

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

Лист событий в build2 поддерживает функции, и они работают точно так же, как и godots. Простое окно фильтра/поиска решит все проблемы, которые вы перечислили.

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

Чтобы организовать код визуального сценария в vonstruct2, вы помещаете его в группы, которые можно свернуть. Это то, чего не может сделать даже gdscript — вы не можете свернуть блоки кода. Таким образом, в некотором смысле список событий имеет преимущества перед редактором gdscript godots.

@reduz Я смотрел на Pure Data, и то, как они это делают, очень просто. Хорошо проверьте это

Как видите, ввод «Bang» превращает общий объект в объект Bang.

Что, если бы визуальные сценарии могли просто стать расширением GD Script. Просто поместите общий узел и введите Vector2 вместо ex, и он станет объектом Vector2. Таким образом, каждый класс/объект также является узлом.

Я думаю, что для запуска функций вы можете получить другой узел, который не является объектом, а скорее узлом процесса, и вы должны ввести что-то вроде Vector2.dot, и узел превратится в точечный узел с 2 входами и 1 выходом.

визуальный сценарий планируется в какой-то момент

Вы не подвели :) <3

Поскольку VisualScripting уже существует, следует ли закрыть этот вопрос?

да.

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

Отвечая не по теме на заявление 2015 года, давайте :)