Godot: Визуальные скрипты в стиле Event Sheet

Нельзя ли многое из этого облегчить, наполнив текущие визуальные сценарии дополнительными и лучшими функциями?

Многие примеры тривиальны в схеме UE4. «По нажатию клавиши W переместите этого актера вперед».
Вы можете построить большинство из них очень похожим образом в чертеже, и даже визуальные различия (которые будут единственными) будут минимальными.

Мы должны сосредоточиться на том, чтобы сделать имеющийся у нас Visual Script удобным для использования и работать интуитивно понятным и плавным образом, IMO. Как бы то ни было, Visual Script, который у нас уже есть, кажется немного забытым и, кажется, не пользуется особой любовью. Как наличие двух систем Visual Scripting вообще улучшит эту ситуацию?

Хорошая идея для плагина. Но официально поддерживать две системы визуальных сценариев было бы мучением и мало пользы.

@mhilbrunner, к сожалению, нет, Blueprints - это совершенно другой подход к визуальному написанию сценариев. Для вас они тривиальны, но осмелюсь сказать это на форуме clickteam или на форуме build. Эти ребята застряли на движках, которые они используют, из-за того, как сильно они любят этот подход, и поверьте мне — многие из них пробовали чертежи в Unity, unreal и других движках, включая godot. Они по-прежнему зациклены на конструкции 2 или слиянии кликов, потому что предпочитают листы событий чертежам. Они по-прежнему запрашивают доступ к листу событий на форуме Unity.
Визуальные сценарии Godot упоминались на их форумах, и пользователи до сих пор предпочитают листы событий. Я лично перешел на gdscript и предпочитаю использовать gdscript вместо blueprints, потому что gdscript по своим преимуществам ближе к спискам событий, чем blueprints.

Это как сказать кому-то, кто любит бананы, есть помидоры вместо этого - это дело вкуса :)

@groud Какое-то время я думал так же, но я даже не уверен, с чего начать - и даже в качестве плагина - кто-то должен будет поддерживать плагин.

@reduz, похоже, теплее заняты более важными вещами.

В любом случае, я публикую это здесь для документации — чтобы обрисовать в общих чертах систему листов событий — что она делает и чем она отличается от чертежей. Если кто-то еще заинтересован во внедрении этого в godot или в качестве дополнения, сообщите нам об этом. Я определенно буду закатывать рукава и помогать, распространять новости и получать отзывы от пользователей clickteam/construct.

Пока я даже не знаю, как правильно реализовать его интерфейс с классом GUI godot. Вы должны иметь возможность перетаскивать логические блоки между ячейками одного и того же столбца. Копировать/вставлять блоки/строки тоже - вкладывать строки и
другие уникальные вещи. Я не думаю, что это маленькая задача

@blurymind Да, и определенно спасибо за то, что указали на это и

devs: Как лучше всего добавить это с минимальной сложностью? Может быть, я найду время, чтобы изучить, как работают текущие визуальные сценарии. Интересно, можно ли в основном просто заменить пользовательский интерфейс Visual Scripting или сгенерировать GDScript или каким-либо другим способом сделать это динамически.

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

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

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

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

@groud , на самом деле это хороший момент. Какую часть текущей кодовой базы визуальных сценариев можно использовать повторно? Насколько это специфично для интерфейса nodegraph?

@blurymind Да, понял, работаю над таким списком для VS, и

Нужно исследовать NativeScript :)

Теперь у нас есть несколько вариантов языков сценариев (C++, C#, даже python). Почему бы также не иметь более одного варианта визуального сценария :)

Я предполагаю, что это также может зависеть от того, насколько гибок API Godot для создания визуальных интерфейсов сценариев.
Следует ли повторно использовать кодовую базу визуальных сценариев или следует написать полностью альтернативную кодовую базу с помощью Nativescript (c++)?
Можно ли это просто реализовать как дополнение gdscript?

Почему бы также не иметь более одного варианта визуального сценария :)

Потому что мы уже поддерживаем слишком много языков как встроенных. Большинство вариантов использования уже рассмотрены, поэтому нет особых причин добавлять новый язык для поддержки. У нас есть язык для базового программирования (GDscript), два для выступлений (C# и C/C++) и один для художников/дизайнеров игр (визуальные сценарии). Нет причин добавлять еще один язык в качестве встроенного только потому, что некоторые люди не справляются с изучением нового языка.

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

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

@groud Это хороший момент, но подумайте о соотношении программистов и художников в геймдеве. Некоторые из величайших и самых красивых ретро-2D-игр были созданы с помощью fusion 2 художниками, которые хотели создавать игры интуитивно понятным способом, соответствующим их образу мышления. Вот немного устаревший шоурил игр, сделанных Fusion:
https://www.youtube.com/watch?v=3Zq1yo0lxOU

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

Что ж, может быть, но многие ли из них понимают таблицы событий, но не понимают VisualScripting? Вы говорите, что «эти ребята застряли на движках, которые они используют, потому что им нравится этот подход, и поверьте мне — многие из них пробовали чертежи в Unity, unreal и других движках, включая godot», но на самом деле вы первый, кто это спросил.

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

Для меня мы уже охватили все варианты использования. По крайней мере, для современного и профессионального игрового движка. И поскольку мы ориентируемся не на детей или любителей, а на компании, не стоит тратить на это время. Fusion 2, Construct или даже RPGMaker ориентируются на другую аудиторию, даже если с их помощью были сделаны красивые игры, лишь крошечная часть из них являются профессиональными проектами.

@groud эту статистику трудно найти. Сколько используют текущий визуальный сценарий?

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

Если вы спросите меня, движок rpg maker на самом деле является редактором уровней. У него нет такого же уровня гибкости, как у Fusion и build2.

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

Является ли это

выглядеть так трудно понять, как это?

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

Говорю как человек, который пользовался обеими системами и сейчас их сравнивает - обе одинаково мощные, одна явно проще в освоении и вникновении
Попробуйте, пожалуйста. Вы можете бесплатно протестировать конструкт3 в своем веб-браузере здесь:
https://www.scirra.com/
Если у вас есть сын или младший брат или сестра, попросите их попробовать это, а затем попробуйте годо — посмотрите, что они могут сделать и сколько времени им потребуется, чтобы сделать это без инструкций — здесь есть потенциальный рынок для большего количества школ, чтобы принять годо. - сделать визуальные сценарии лучше для изучения концепций программирования, и мы получим более молодую демографическую группу, используя движок

Сколько используют текущий визуальный сценарий?

Понятия не имею, но пока мало верю. Похоже, что сейчас большинство людей используют GDScript, поскольку я не вижу много вопросов/контента, касающихся VisualScripting, на Facebook или Youtube. Добавлять листы событий, прежде чем убедиться, что VisualScripting не отвечает всем вариантам использования, было бы смелой ставкой. Давайте пока просто посмотрим, достаточно ли VisualScript, и если люди будут массово просить другую систему, мы можем добавить ее позже.

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

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

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

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

потому что его подход основан исключительно на государственной машине

Какие ? Я понятия не имею, почему ты так думаешь. VisualScripting не имеет ничего общего с конечными автоматами.

Что проще использовать на данный момент — Blueprints или Gdscript? Какова цель визуального скриптинга и кто является целевым пользователем

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

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

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

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

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

@groud, можем ли мы даже сгруппировать узлы VisualScript, как в блендере? Я не помню, чтобы видел это. Возможно, @mhilbrunner должен добавить его в свой список.
https://github.com/godotengine/godot/issues/12418
Еще один важный момент заключается в том, что возможность многократного использования логических блоков действий/условий более высокого уровня с помощью gdscript была бы очень полезной для системы листа событий или системы чертежей. В системе чертежей он уже есть, но я не вижу никаких плагинов, сделанных для него.

Опять же, конструкция 2 намного опережает нас. Их сообщество создало множество простых в установке плагинов, которые добавляют настраиваемые условия и действия, а их API для регистрации действия и условия очень прост.
https://www.scirra.com/forum/completed-addons_f153
https://www.scirra.com/manual/19/actions-conditions-and-expressions

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

лол, как это легче читать, чем gdscript

@groud, можем ли мы даже сгруппировать узлы VisualScript, как в блендере? Я не помню, чтобы видел это

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

лол, как это легче читать, чем gdscript

Дело не в этом.

@groud да, это так. зачем разработчику игр использовать листы событий, когда они гораздо более дезорганизованы / запутаны для чтения, чем простой код gdscript? это вся суть предложения этой функции, не так ли?

@groud да, это так. зачем разработчику игр использовать листы событий, когда они гораздо более дезорганизованы, чем простой код gdscript?

Нет, VisualScripting (или Event Sheets) и GDscript не предназначены для одних и тех же людей. VisualScripting (или листы событий) предназначены для художников или дизайнеров игр/уровней, в то время как gdscript требует опыта программирования.

Сравнивать Event Sheets и GDscript не имеет смысла.

Сравнивать Event Sheets и GDscript не имеет смысла.

Ну, вот в чем мы отличаемся :P, потому что я думаю, что сравнивать их более чем разумно. тем более, что gdscript делает все, что они делают, на гораздо более простом уровне.

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

с учетом сказанного: JIT-компилированный gdscript находится в дорожной карте и будет гораздо полезнее, чем листы событий или дополнения к визуальным сценариям (поскольку большинство разработчиков godot уже могут извлечь из этого большую пользу). и потенциальные варианты использования VS/Event Sheets в настоящее время довольно низки. так что все, о чем я прошу, будьте осторожны в отношении времени разработки, так как ваш недавний пост уже намекал на

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

Вы, очевидно, никогда не касались конструирования или объединения кликов, если вы хотите обсудить это - по крайней мере, используйте список событий некоторое время - сделайте с ним платформер.
Я связался с онлайн-демонстрацией конструкта3, которая не требует от вас регистрации учетной записи или входа в систему.
https://www.scirra.com/
это буквально три клика

Попробуйте лист событий, сделайте что-нибудь с ним. Затем используйте чертежи visualscript, которые есть у Godot.

Gdscript прост - да, я согласен и тоже люблю его. Джит-скомпилированный gdscript был бы потрясающим! Согласен, это и важнее.
Но это обсуждение совсем не об этих вещах

Ну, вот в чем мы отличаемся :P, потому что я думаю, что сравнивать их более чем разумно. тем более, что gdscript делает все, что они делают, на гораздо более простом уровне.

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

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

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

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

@blurymind, я восхищаюсь твоей энергией, и ты делаешь хорошие

@groud приводит хороший аргумент в их пользу, поскольку Marvel Heroes была AAA aRPG, и они использовали чертежи с Unreal .

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

• ограниченная рабочая сила разработчиков
• количество текущих выпусков уже
• неорганизованность/трудно читать (см. здесь )
• я чувствую, что большинство разработчиков Godot предпочли бы использовать gdscript
• gdscript уже так хорошо связан с godot
• при добавлении в core могут возникнуть новые проблемы, связанные с листами событий, которые могут устранить проблемы с gdscript.
• несправедливо по отношению к текущим 90% разработчиков godot, которые уже используют gdscript (если время разработки можно было бы использовать для gdscript, скомпилированного jit, который выполняет активные варианты использования)

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

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

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

На самом деле система листа событий может быть гораздо лучше объединена с gdscript, чем текущая система чертежей, где выражения выполняются с помощью графов с миллиардом узлов, а не с помощью простого ввода текстового поля. Если вы хотите сделать 1 + 1, используйте узел. Если вы хотите обратиться к простой переменной в выражении, используйте другой узел. В итоге вы получите беспорядок спагетти из миллиарда базовых узлов для простого выражения, которое можно было бы так же легко и гораздо яснее написать в крошечном текстовом поле с гораздо меньшими усилиями и многословием.

Текущий визуальный скрипт, который у нас есть, требует слишком много кликов, узлов и многословия, чтобы делать самые простые вещи. Это еще одна причина, по которой gdscript более прост - строка кода вместо 10 узлов и 100 соединений.

Это, по сути, еще одно преимущество системы листа событий — вы можете просто писать свои выражения внутри полей ввода блока кода. И в build2, и в fusion даже есть редакторы автозаполнения и выражений с легким доступом ко всем методам, которые есть у узла, со списком всех узлов, к которым у листа есть доступ в области видимости.

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

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

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

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

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

Кроме того, обсуждение JIT для GDscript является оффтопом. Достоинство функции может быть измерено только:

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

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

@mhilbrunner JIT для GDScript на самом деле произойдет, это уже включено в официальную дорожную карту: P. я просто сказал, что это может отнять у этого время разработки. и это трудно оправдать, поскольку 90% разработчиков godot уже используют gdscript (и многие люди думают, что это лучше, чем листы событий, и имеют свои собственные ощущения). извините, если я не правильно выразился. да, я знаю, что это не замена, но я больше говорю о времени разработки.

с учетом сказанного,

Ранее я использовал Action Game Maker и лист событий Game Maker, и я согласен с тем, что его проще использовать и понимать, чем VisualScript (вы читаете сверху вниз, а не по строкам), он не занимает столько места на экране и может реализовать конечный конечный автомат проще (путем фильтрации событий, которые могут быть запущены после завершения события).

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

Ну, я пользователь Godot около года. Мне нравится GDScript и его простой синтаксис.
Но я использую Construct более 8 лет и могу сказать, что никогда не видел более простого Visual Script, чем Event Sheets. Мне не нравится Blueprint, и я использовал некоторые другие стили VS Blue Prints, такие как Blender и Unity, и я не Не понимаю, как люди могут говорить, что Blue Print проще, чем Event Sheets. Может быть, это потому, что художники привыкли использовать узлы для настройки шейдеров и графики, они привыкли к этой эстетике. Но держу пари, если вы поместите систему листов событий в такой движок, как Unreal, люди будут отказываться от Blueprints.

Я работаю в школе, где детей и подростков обучают логике программирования. Для детей мы используем Construct 2, потому что им очень легко создавать что-то с помощью Event Sheets. Для подростков мы используем GDScript, и у нас с ним хорошие результаты. Когда вышел Godot 3.0, мы рассматривали идею отказаться от Construct 2 и использовать Godot VS, но мы отказались от этой идеи, потому что сейчас VS сложнее, чем GDScript, его очень сложно понять и использовать. Если бы у Godot было что-то вроде Event Sheet, мы бы сделали наш курс полностью основанным на Godot, потому что мы склонны отдавать предпочтение решениям с открытым исходным кодом в школе.

Другая польза, которую, я думаю, принесут Event Sheets, это увеличит базу пользователей Godot, так как на GDC мы видели, что средние и крупные студии предпочитают Godot, а маленькие предпочитают Unity и другие решения. Я думаю, что пользователи из Construct, Fusion и Game Maker начнут переходить на Godot.

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

В любом случае, мне нравится то, что делает Godot, и я люблю GDscript, я просто хотел поделиться своим опытом, так как я использую как Event Sheet, так и GDscript для обучения. Держите отличную работу!

Когда вышел Godot 3.0, мы изучали идею отказаться от Construct 2 и использовать Godot VS, но мы отказались от этой идеи, потому что сейчас VS сложнее, чем GDScript, его очень сложно понять и использовать.

Довольно интересный отзыв. :)
Дело в том, что листы событий в форме Construct2 намного менее низкоуровневы, чем VS или GDscript. Действительно, они могут помочь детям освоить программирование игр, но это не цель Godot. Я считаю, что такая система не должна поставляться как встроенная, а доступна через плагин. Я думаю, что этот комментарий от Reduz тоже выражает это.

@DrZanuff спасибо, что подняли этот действительно важный момент - что-то в том же духе также было отмечено каналом kidscancode на YouTube и @NinkuX - листы событий отлично подходят для школьной среды и отлично подходят для перехода к чему-то вроде gdscript. Чертежи, к сожалению, не

Возможно, Godot может подойти к этому так же, как это делают создатели игр — их визуальный код перетаскивания напрямую транслируется в код gml, который можно даже просмотреть в режиме реального времени. Таким образом, не-кодеры могут изучать gml, пока они используют визуальную систему сценариев движка — это точная стратегия, которую использует yoyo games, чтобы постепенно знакомить не-кодеров с gml.
https://docs2.yoyogames.com/source/_build/3_scripting/1_drag_and_drop_overview/changing_dnd.html

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

Даже в качестве дополнения - я продолжаю думать, что объекты листа событий godot в конце концов должны быть переведены в gdscript. Лист событий может быть инструментом для обучения непрограммистов использованию gdscript, предоставляя им простой интерфейс, который по-прежнему позволяет использовать gdscript для выражений и, в конце концов, в любом случае генерирует и предварительно просматривает gdscript.

В API Godot есть метод создания файлов gdscript и их прикрепления к узлам. Таким образом, лист событий может быть переведен в gdscript при запуске игры или даже при редактировании листа событий, как это делает создатель игры.

Дополнительным учебным пособием, которое используют как clickteam fusion, так и build2, является список меню, основанный на щелчках, со встроенными методами/членами узла.

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

В этом смысле реализация Godot системы Event Sheet может иметь в качестве основной цели познакомить не кодеров с gdscript и базовыми концепциями программирования, не запутывая их каким-либо синтаксисом — тогда Godot будет использоваться в большем количестве школ, обучающих программированию до подростков. По мере продвижения они будут изучать gdscript и API Godot, а не Construction2 или Game Maker.

Кажется, я плохо объяснил... :(

Когда я говорю «линии», я имею в виду визуальный сценарий, линии, соединяющие узлы.

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

Было бы неплохо изучить альтернативу такого типа

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

Если бы у нас была низкоуровневая реализация системы листа событий, было бы намного проще создавать и поддерживать для нее действия/условия более высокого уровня.
Я думаю, что даже в качестве аддона — я бы сначала сделал базовый аддон Event Sheet только с низкоуровневым доступом и интерфейсом — который следует архитектуре godot, не раздувая его какими-либо новыми методами. Затем отдельные необязательные надстройки для вещей более высокого уровня могут быть написаны поверх других плагинов.

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

Преподаю программирование детям от 7 до 17 лет. В настоящее время младшие ученики используют Cosntruct, а старшие используют Godot, но если бы все мои ученики могли использовать Godot, я был бы очень благодарен за то, что дети используют Godot с самого начала своего пути в этом мире разработчиков игр.

Это не только система листа событий. Также как работают plugins/behaviours/families, UID и свойства объектов.

Например, в C2 в одном объектном спрайте я могу иметь все игровые арты, включая статичные/анимации декораций, игрока, врагов и т. д., все с их столкновениями и т. д. и размещать в макете, выбирая, какой кадр при запуске и используя переменную экземпляра объекта с именем «type=», чтобы определить, является ли он врагом, игроком, объектом, разрушаемым и т. д., чтобы в событиях установить его поведение. Также для каждого спрайта у вас есть базовая программа рисования, свойства аниматора и т. д.

В Godot я попробовал пример Pong в визуальном сценарии, и когда я увидел, что он использует один спрайт для игрока и другой объект спрайта для столкновения, я подумал: ЧТО!? . Также C2 имеет «угадай форму многоугольника», которая одним щелчком мыши создает столкновение вашего спрайта, используя 8 точек. После этого вы можете добавить больше точек и настроить, чтобы быть более точным, или использовать некоторые плагины или приемы для получения точности до пикселя.

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

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

@matriax Я не думаю, что ты прав здесь.
У Godot гораздо более гибкая и простая архитектура, чем у Construct2.
Как уже отмечалось, спаривание объектов - это проблема в конструкции, среди многих других вещей - мы могли бы, например, иметь более четкий порядок событий, чем конструкция. Мы можем прикрепить листы событий к любому узлу, что обеспечивает лучшую организацию, чем у конструкции 2.
Для типов/семейств - в godot у нас есть "группы" - реализация групп godot на самом деле лучше, чем конструкция.
Для присоединения поведения к объектам — вы можете просто прикрепить дочерние узлы и использовать их как поведение корневого родительского узла, содержащего присоединенный лист событий. Это на самом деле лучше, чем Construct снова.
В godot вы должны сделать узел формы столкновения дочерним по отношению к узлу, у которого есть столкновение. Это не ракетостроение и на самом деле лучше для обучения детей программированию.

Некоторые вещи, которые вы запрашиваете, должны быть сделаны как надстройки и уже сделаны как надстройки (например, угадайте форму многоугольника)

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

Чтобы сделать godot таким же удобным для пользователя, как Construct 2, необходимо объединить усилия как основных разработчиков godot, так и его сообщества. Сообществу потребуется создать функциональность более высокого уровня с помощью надстроек листа событий. Пожалуйста, не пытайтесь сделать godot точно таким же, как и build2. Это во многом лучше.

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

Я имею в виду, что добавление системы листов событий на Godot без следования той же философии для выполнения всей работы простым способом, как в C2 / C3, будет пустой тратой времени. Как я уже сказал, иметь один объект для спрайтов/столкновений или всего игрового искусства вместо одного объекта для каждой вещи.

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

@matriax вам нужно изучить Годо, прежде чем делать такие заявления :)

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

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

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

Даже в качестве реализации аддона лист событий в godot не должен ничего делать, кроме как просто создавать еще один интерфейс для создания файлов gdscript imo.

@blurymind И снова то же самое, хорошо, забыл.

@matriax обратная связь - хорошая идея. Вы правы в этом вопросе.
Было бы хорошо спросить целевую группу людей, а не только кого-то в Интернете. Целевой группой могут быть молодые студенты и преподаватели — это действительно идеальная цель для системы регистрации событий.
учителя будут очень хорошо знать, с чем борются их ученики, и в то же время будут знать Godot и Construct. Студенты и непрограммисты могут дать хорошие отзывы

Если вы просто спросите на трекере godot здесь, вы получите в основном опытных программистов среднего уровня - людей, которые уже знают и любят gdscript, API движка и даже C++
Они будут реагировать защитно - как вы можете видеть в начале поста - думая, что то, что вы предлагаете, не то, что нужно им и нужно движку - естественно, потому что мы уже умеем писать код в gdscript и видим более важные цели для двигатель, чем этот. Это правда, что есть более важные цели.
Если вам повезет, некоторые из них до того, как прийти в godot, начали с слияния конструкт/гейммейкер/кликтим и будут знать, в чем его ценность для людей, которые еще не знают ни одного языка программирования.

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

Возвращаясь к ценности в этом - было бы замечательно, если бы Годо, может быть, когда-нибудь в будущем станет первым двигателем большего количества детей?
Почему бы не попробовать заменить Construct в школах :) Разработчикам Scirra сейчас слишком легко. Посмотрите, как они хвастаются сотрудничеством со школами
https://www.construct.net/gb/blogs/construct-official-blog-1/construct-3-a-year-in-review-947?utm_campaign=blog1postemailsub&utm_medium=email&utm_source=947&utm_term=txt4-read-laura_d% 2527s-post&utm_campaign=маркетинг&utm_source=sendgrid&utm_medium=электронная почта

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

Было бы здорово, если бы узел richtextlabel в godot мог использовать внутренние значки редактора godot.

Я сделаю еще один макет для редактора условий/действий, когда у меня будет время :)
Редактор действий/условий будет инструментом для редактирования ячеек/логических блоков. Я думаю о чем-то похожем на подход Construct2 с внутренним редактором кода godot в качестве редактора выражений.
Возможно, некоторые вспомогательные средства могут быть добавлены позже, например, те, что в конструкции 2 или слиянии.

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

@blurymind Хорошо , мне понравилась концепция.
Возможно, кнопки для добавления действий и условий должны быть без фоновой кнопки, как в конструкции 2.

И я думаю, что было бы неплохо отделить условие от действия.

Мне нравится, как это получается.

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

@DrZanuff Спасибо за отзыв
@ Zireael07 Спасибо :)
Да, именно — инструмент, который поможет нам полностью заменить Construct2 на Godot в школах, использующих оба движка для обучения программированию.
Под ним находится просто визуальный интерфейс для создания файлов gdscript — аналогично тому, как DnD используется в Game maker 2. Я не прошу каких-либо изменений в превосходной архитектуре godot.
Листы событий могут быть опцией визуального сценария в Godot, которая удобна для пользователей, не являющихся кодерами (чертежи - нет), и маленьких детей, изучающих концепции программирования - упрощая их в gdscript

Кстати, у Godot уже есть много элементов, чтобы сделать эту работу, но она не может быть точно такой же, как в Construct2. По мнению Годо, во многих отношениях будет лучше, если это произойдет. Лист событий Construct2 допускает некоторые действительно плохие методы организации кода и имеет некоторые ужасные ограничения/причуды. На самом деле мы можем сделать лучший лист событий, чем их, который будет таким же удобным для пользователя и лучше обучает программированию - без причуд.

На мой взгляд, большая часть работы связана с созданием интерфейса для редактирования листов событий. У меня есть еще несколько идей, как сделать это лучше, используя преимущества godot, но мне потребуется некоторое время, чтобы разработать доказательство концепции. что объясняет его. Иногда картинка стоит больше, чем слова. Аддон - больше, чем картинка

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

@mhilbrunner Конечно, вы можете - и мне действительно понравится, если вы, ребята, покопаетесь в этом. Просто нужно время, чтобы сделать его более презентабельным. :)

Я нахожусь в процессе интеграции графического интерфейса в редактор godot в качестве плагина gdscript - он еще недостаточно интерактивен :)

Опубликую его на github, когда я получу базовый графический интерфейс, работающий в интерактивном режиме для передачи идей дизайна :) Сегодня я получил графический интерфейс листа событий для загрузки в виде вкладки — вдохновленный плагином sketchfab:

Возможно, лист событий должен быть доступен из другого места?

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

• Ребята, вы знаете простой способ отображения значков узла godot внутри узла метки форматированного текста с помощью bbcode?
  В моем предыдущем макете я использовал теги [img], но это довольно плохой подход, так как мне потребуется загрузить все значки узлов, которые использует редактор godot, и сохранить их с помощью аддона.

• Я также изо всех сил пытаюсь понять, как зарегистрировать новый ресурс типа сценария таблицы событий через аддон API

@blurymind очень хорошо! Теперь это более читабельно. Нам нужно подумать, как список действий будет показан пользователю.

Одна вещь, которая мне нравилась в старой версии Construct Classic, — это возможность редактировать значения из листа событий, не открывая действие или условие, но дважды щелкнув значение, чтобы отредактировать его:

Если кто-то захочет это добавить (самостоятельно через плагин, аддон, gdnative и т.д.), то не беда, не фол. В противном случае я согласен, что визуальные сценарии можно улучшить, сделав это излишним. GDscript прост, очень прост. И, вероятно, полезнее для обучения детей, чем какие-то дерьмовые визуальные сценарии (даже основанные на чертежах). Если кому-то нужна конструкция, я говорю, поощряйте их продолжать использовать конструкцию. Godot не нужно эмулировать любую другую систему в своем ядре. Пусть программное обеспечение сохраняет свою направленность и не становится «мастером на все руки, но не мастером ни в чем» из-за рассеянного фокуса.

@spyres зависит от того, хотят ли
Лично я считаю, что мы можем полностью заменить конструкт в школах на годот.
Нынешняя система чертежей для этого не годится. Его сложнее использовать, чем gdscript, и, как упоминалось ранее, это не лучший способ познакомить кого-то с парадигмами программирования, потому что у него есть собственный набор правил.
Цель этого не в том, чтобы заменить gdscript или текущую систему чертежей, а, наоборот, дать детям возможность изучить gdscript, помогая им. Именно так yoyo games использует свою систему визуальных сценариев DnD, чтобы постепенно знакомить непрограммистов с Gml, кстати.
Я не думаю, что есть какой-то вред в том, чтобы иметь визуальную систему сценариев, которая более доступна для непрограммистов и лучше разработана для их перехода на gdscript. Почему ты?

Я пытаюсь сделать это как аддон, но я сталкиваюсь с некоторыми ограничениями с точки зрения отсутствия документации или API. Я хочу зарегистрировать новый тип ресурсов сценариев и добавить редактор списка событий на вкладку сценариев для редактирования файлов myscript.es.
Кто-нибудь знает, как это можно сделать, или есть пример того, как это делается?
Имея собственную вкладку, это уродливо, IMO, и не соответствует оригинальному дизайну редактора. Я хочу, чтобы мой аддон был интегрирован таким образом, чтобы он не уступал дизайну godot.

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

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

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

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

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

@spyres ты сам разработчик? Или учитель? Вы действительно использовали визуальный сценарий godot в своих собственных проектах? Если да, то как его можно улучшить, чтобы он стал лучшим инструментом для обучения людей программированию?

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

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

Я также согласен с @spyres, что Godot не обязательно ориентироваться на образовательный сегмент. Если Godot не подходит для обучения программированию (даже не геймдеву), пусть будет так. Это никогда не означало быть на первом месте. Но если кто-то может каким-то образом использовать/преобразовать godot в инструмент обучения программированию, у меня нет проблем с этим.

Тем не менее, я думаю, что этот список событий — интересная идея.

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

@zaniar @ni-code Вы правы. Это правда, что я лично больше заинтересован в создании визуального инструмента для написания сценариев, который был бы более эффективным и понятным, чем наш нынешний подход к плану, — который просто более приятен в использовании. Construct2 мне не нравится - так что неправда, что я хочу превратить Godot в него. Как я уже упоминал ранее, я нахожу его дизайн и причуды довольно плохими. Вот почему меня так расстраивает, что единственные места, где можно найти листы событий, не так хороши, как Годо.

Я искренне считаю, что даже если чертежи будут улучшены, они никогда не будут такими же четкими и быстрыми, как листы событий — в этом отношении листы событий — отличный инструмент для быстрого прототипирования, который часто недооценивают. Но заголовки, созданные Clickteam fusion, должны говорить сами за себя. Кому-то это может показаться игрушкой, но мне просто весело строить игровую логику таким образом :)

Как человек, который использовал и build2, и Fusion, мне нравится подход с листами событий, и я вижу в API Godot прекрасного кандидата на систему листов событий — без недостатков движков, которые его вдохновляют.
Дизайн вложения узлов Godot будет очень хорошо работать с этим, в сочетании с ясностью выражений gdscript.
Я не ожидаю, что это будет реализовано в godot, но я продолжу делиться здесь прогрессом плагина в надежде получить полезные отзывы и помощь с API. Некоторые из разработчиков здесь использовали Construct2 и очень хорошо знают Godot, поэтому в ходе обсуждения могут возникнуть хорошие идеи.

На самом деле у меня есть идея для системы списка событий, которая даст нам небольшое преимущество по сравнению с простым использованием gdscript — даже для опытных пользователей. Он должен использоваться с gdscript, а не вместо gdscript — не забывайте, что

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

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

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

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

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

Действительно ли 7-летняя детская демографическая группа требует такого дублирования?

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

Есть ли у github способ блокировать публикации людей, если они оскорбляют?

Ничего себе, хотя я, конечно, сомневался в некоторых идеях, я _никогда_ на самом деле обзывал . _Это_ довольно оскорбительно, я бы сказал.

Что даст дублирование функциональности конструкции в Godot, чего еще не обеспечивает э-э... конструкция.

Есть ли законный плюс в дублировании набора функций Construct (вероятно, в меньшей степени) в godot просто для того, чтобы привлечь 7-летних?

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

Есть ли какая-то законная причина предполагать, что дети не смогут перейти на gdscript или визуальный скрипт, когда перерастут конструкцию?

@spyres, вы используете в целом оскорбительные термины для описания людей, которые используют листы событий и листы событий.
Они не "детишки" и система не "дерганая". Имейте некоторое уважение к этим сообществам ради бога. Откуда такое элитарное отношение?

В Construct2 работает много очень опытных программистов javascript, что должно было быть очевидным для вас, если вы столкнулись с трудностями, чтобы действительно прочитать то, что я пишу, и перейти по ссылкам, которые я предоставил. Некоторые из дополнений, которые они сделали, интегрируют его с 3D-движками, такими как babylon и three.js, даже — так что да, опытные разработчики также любят использовать листы событий и создавать игры с их помощью.

Слияние Clickteam позволило играм значительно превзойти игры, созданные Godot, в Steam, Kickstarter и даже в магазинах приложений с точки зрения количества и доходов, которые они приносят. Это полностью основанный на списках событий движок, которым пользуются люди в возрасте от 10 до 80 лет. Это смесь всех возрастов. Некоторые из пользователей — кинорежиссеры, другие — художники — люди с работой, которые тратят деньги на лицензии, экспортеров и так далее. Черт возьми, я заработал больше денег, продавая вещи в их магазине активов, чем что-либо еще, связанное с godot.
Вот несколько примеров — режиссер Алонсо Мартин решил сделать игру:
https://www.kickstarter.com/projects/alonsomartin/heart-forth-alicia
Группа 7 лет делает игру
https://www.kickstarter.com/projects/galaxytrail/freedom-planet-high-speed-platform-game

посмотри сюда
http://indiegames.clickteam.com/
Эти семилетние точно знают, как делать игры и зарабатывать деньги, а
https://thinkgaming.com/app-sales-data/publisher/3107/scott-cawthon/

Моя точка зрения на продажу этого как лучшего инструмента для обучения программированию не должна быть причиной для неправильного обозначения этого. С более широкой демографией пользователей вы получите больше людей, делающих игры с движком. Разве это не должно быть очевидно? Почему это не очевидно :D

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

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

Вау! Несмотря на смену ворот...

Позвольте мне уточнить.

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

Вопросы, касающиеся реальных выгод, остаются прежними, хотя некоторые могут (по необъяснимым причинам) счесть их «оскорбительными».

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

Но эй, зачем останавливаться на достигнутом? Для обучения детей программированию существуют отличные инструменты (помимо конструкции) (например, Scratch , Styncl , code.org и т. д.). Почему бы не включить их и в Godot!

А может и нет... ;-)

Есть ли кто-нибудь, кто использовал визуальные сценарии Годо, и кажется, что он использует только визуальные сценарии Годо?

@Zonacas Я не думаю, что Visual Scripting Godot еще достаточно созрел для этого, но я могу ошибаться. Имейте в виду, что VS был выпущен всего около двух месяцев назад. :)

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

Привет всем, у меня есть обновление прогресса в моем аддоне для проверки концепции.

Вот вам свежая гифка:

Некоторая предыстория того, что он делает. В основном лист событий состоит из ячеек. Ячейка может быть либо для условий (геттеры/выражения), либо для действий (сеттеры, которые могут быть заполнены геттерами/выражениями).
Со стороны графического интерфейса ячейка события создается с помощью узла richtextlabel и bbcode, сгенерированного из gdscript. Когда вы дважды щелкаете по нему, RichTextLabel превращается в узел поля редактирования, содержащий фактическое выражение gdscript.

Таким образом, ячейка листа событий имеет 2 режима:

• режим редактирования — узел textEdit, который можно ввести с помощью gdscript.
  Единственное отличие состоит в том, что пользователю не нужно вводить If/else/while — это зависит от контекста родительского контейнера, как показано на снимке экрана. Каждая строка является новым условием, поэтому, если пользователь не начал строку с «или» или чего-то еще, синтаксический анализатор автоматически узнает, что новая строка имеет предлог «и».

При щелчке переключается в режим просмотра.

• режим просмотра — метка форматированного текста — при переключении в режим просмотра bbCode анализируется из gdscript, который находится в режиме редактирования, и представляется через интерактивную метку форматированного текста. Помимо интерактивности и простоты изменения, цель состоит в том, чтобы представить код gdscript более четким образом. Это означает показывать только имя и значок узла (а не весь путь) и избавляться от некоторых слов, когда это очевидно (например, get_ и set_). Поскольку каждая интерактивная часть на самом деле является тегом URL-адреса, например, при наведении курсора на имя узла пользователь может получить некоторую информацию, например полный путь к узлу.

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

Что дальше сделать, чтобы заставить это работать:

• Мне нужно найти способ перетаскивания ячеек, чтобы можно было легко изменить порядок событий.
• Также копирование и вставка в режиме предварительного просмотра.
• Далее мне нужно создать редактор выражений, который появляется при нажатии на определенный тип URL-адреса ячейки режима предварительного просмотра.
• выяснить, как обращаться с элементами-заполнителями. Я думал о размещении комментариев, но, к сожалению, godot не поддерживает встроенные комментарии: https://github.com/godotengine/godot/pull/18258, поэтому мне, возможно, придется вернуться к чертежной доске.

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

Спасибо всем за поддержку

Хорошая идея для плагина. Но официально поддерживать две системы визуальных сценариев было бы мучением и мало пользы.

XKCD: Стандарты

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

@Megalomaniak Это правда, и поверьте мне, когда я говорю, что если бы у меня было достаточно знаний об API Godot, я бы переписал это как gdnative addon. Но даже зайдя так далеко, я изо всех сил пытался, и мне действительно не хватает некоторых ключевых элементов, чтобы превратить это в реальный полезный инструмент. Я поднимал здесь вопросы, но пока мне толком никто не ответил и не показал примеров:

• Как зарегистрировать новый тип ресурса скрипта в редакторе godot и позволить пользователю прикрепить его к любому узлу? На данный момент аддон работает из корня сцены и его взломали.
• Как нам сделать так, чтобы godot открывал мой графический интерфейс листа событий — такой же интегрированный, как и текущая система чертежей?
• Как сделать так, чтобы узел editText действовал как редактор gdscript в godot — включить подсветку синтаксиса и автодополнение. Кроме того, как мы можем дать ему пользовательский контекст?

Это может сделать кто-то с очень низким уровнем знаний API. Таких вещей нет в документации - нет и существующих примеров.
У меня есть дизайнерские идеи, но пока нет полной картины, чтобы воплотить ее в жизнь.

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

Для подобных вещей я предпочитаю соблюдать пожелания разработчиков:

https://godot.readthedocs.io/en/3.0/about/faq.html

У меня есть отличная идея, которая сделает Godot лучше.

Ваша идея наверняка будет проигнорирована.

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

@spyres На самом деле я делаю это и ищу поддержки у других пользователей godot в API по поводу вещей, которые я не могу найти в документации, - пытаясь внести свой вклад в godot.
Что ты здесь делаешь?

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

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

Удачи вам с вашим дополнением. :ухмылка:

@spyres, а ты вообще что-нибудь сделал? Вы когда-нибудь создавали аддон для godot? Вы пользуетесь годотом?

Почему ты здесь? Вы не пытаетесь участвовать в обсуждении

@blurymind Вау, разные мнения тебя так сильно беспокоят? Как грустно тебе.

@spyres все здесь могут видеть ваше мнение - вы им

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

Как альтернативный рабочий процесс действительно интегрирован в ядро ​​godot? Угу, пожалуйста, нет. Я разделяю мнение разработчиков по этому поводу.

@spyres да, ты уже это сказал. Прокрутите вверх и прочитайте еще 5 раз. Есть один из вас .. но так много раз

@blurymind А

Я полагаю, _вы_ вообще ничего не повторили, правильно? (Кто ты, Зачем ты здесь, Оправдывайся, черт возьми!). :ухмыляясь:

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

да, это супер трогательно

@blurymind Спасибо, тогда всех

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

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

@spyres Пожалуйста, прекратите

@mhilbrunner Если мои разные мнения вас так огорчают, нажмите на мой аватар и выберите «заблокировать пользователя». Любая боль, вызванная чтением моих комментариев, немедленно прекратится. :смайлик:

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

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

Как сказал мудрец: «Не волнуйся, будь счастлив». :ухмыляясь:

Или "Это все веселье и игры, пока кто-нибудь не выбьет себе глаз!" (гм, подождите, я не думаю, что это была та цитата, которую я искал...)

УХ ТЫ. Скажу честно, это потрясающе!

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

Я ЛЮБЛЮ взаимодействие с GDScript, так как это была большая функция в студии разработчиков игр (взаимозаменяемость визуального и правильного сценариев), которая была невозможна с системой на основе узлов.

Как только это будет закончено, это поможет ТОННЕ людей

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

Отличная идея!

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

Блестящая идея, сотрудничайте с SnailOn.

1. Он гений.
2. Он использует Godot около 3 лет.
3. Он использовал двигатели Clickteam со времен TGF.
4. идеальный кандидат.

@boruok Я был поклонником yt-канала snailon с первых дней. 😄 Его уроки давно помогли мне освоить фьюжн. У него есть аккаунт на гитхабе? Я хотел бы понять его мнение о некоторых вещах.

Кстати, я должен признать, что я склоняюсь к более похожему на Fusion меню кликов, чем то, что Construct2 использует для принятия решения о том, как заполнить ячейки. На вспомогательное меню, представленное в обновлении 1, определенно повлиял дизайн Clickteam. В этом дополнении вы увидите, что я не создаю точную копию какого-либо движка, а скорее заимствую идеи, которые лучше подошли бы для годотского подхода к листу событий. Также есть немного Game maker — в том, как визуальный сценарий может плавно переключаться на реальный сценарий — что-то, что могут оценить более продвинутые пользователи.

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

Без встроенных комментариев сложно поддерживать простое переключение между gdscript и visualscript, но у меня есть несколько идей, как обойти это и поэкспериментировать, поэтому я работаю над этим.
Мне нужен какой-то способ определить в gdscript пустой заполнитель, где ожидается выражение.
Поскольку выражения будут возвращать тип значения, я решил просто использовать метод преобразования значения в godot для маркировки заполнителя:
float() ## this will turn into a bbcode item that expects an expression resulting in a float
Но это может быть несколько некрасиво, так как будет генерироваться множество ненужных методов преобразования типов переменных внутри окончательного сгенерированного gdscript.

Если бы godot мог делать встроенные комментарии, я мог бы проанализировать их с помощью метода, который вместо этого создает bbcode из gdscript. Это позволило бы мне накормить его дополнительной информацией

Лучший подход на самом деле состоит в том, чтобы просто сделать мой проклятый метод парсера gdscript для bbcode более умным, что я и пытаюсь сделать сейчас.

@blurymind я не знаю насчет git-аккаунта. Кстати, он снова открыл видео. Я отправил ему несколько сообщений через YouTube и Facebook. Будем надеяться, что он появится здесь.

@blurymind Поддерживаю на 100%!
(Заранее извините за английский)

Если мы дадим правильный взгляд на о странице за пределами того, что может быть использовано для троллей людей, это то , что мы можем видеть:

Разработчиков интересует (например):

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

Имея это в виду:

• Текущие визуальные сценарии можно использовать только в том случае, если вы знаете, как кодировать по-настоящему. И становится очень быстро запутанным, чем жесткий код. Кому это помогает? И чертежи тоже не так уж полезны, если у вас нет очень специфического технического образования.

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

• Зачем Godot обслуживать не кодеров?
  Я вижу много применений для многих людей, работающих над профессиональными проектами.
  Во многих проектах, малых, средних и больших, часть команды занимается кодированием, а другая занимается своими делами. Музыка и звуки, визуальные эффекты/анимация/SFX/UI, игровой дизайн, сценаристы и т. д.
  Иногда даже команды из одного человека или люди из других индустрий, такие как этот кинорежиссер, делают довольно успешную игру.
  Некоторые люди даже хотят заниматься программированием, но не кодируют по разным причинам.
  Например, такие проблемы, как дислексия, превращают код в кошмар, но программирование по-прежнему возможно с помощью более визуального подхода, такого как листы событий.
  Большую часть времени у этих людей есть другие дела, помимо написания кода, пока они производят вещи, необходимые для игры.
  Лист событий позволит графисту, звукорежиссёру или гейм-дизайнеру очень легко тестировать или реализовывать свою работу, не погружаясь в необработанный код.
  Это также позволило бы очень быстро создать прототип, чтобы проверить свою концепцию. Добавьте кучу стоковых изображений, нажмите здесь и там немного, и вы можете проверить, интересна ли ваша идея прямо сейчас. Даже хорошие кодеры и известные студии используют самые простые вещи, которые можно повторить в начале проекта.
  Больше отзывов и обсуждений обо всем этом здесь , и я полностью согласен с ОП.
  (Github не лучшее место для отзывов по этому поводу, люди, которые приходят сюда, обычно глубоко погружены в программирование и не видят необходимости, несмотря на то, что на самом деле их меньшинство.)

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

• Кстати, есть еще один инструмент под названием GDevelop, который использует листы событий, если вы хотите посмотреть больше примеров. Предыдущий интерфейс (версия 4) довольно приятный, текущий (v 5) довольно плохой, у приложения есть хорошие идеи, но есть недостатки, и его направление пока тоже немного неясно, но это может дать вам некоторые идеи или, по крайней мере, еще одна точка сравнения.

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

@TheGoklayeh Спасибо за добрые слова поддержки. Я точно знаю, что вы имеете в виду. Как отмечалось ранее здесь, успешный инди-слияние Clickteam сделал количество игр намного больше, чем успешных инди-игр, созданных Godot.
Публикуемые игры, количество продаж в Steam и мобильных устройствах, а также игры на кикстартере, достигшие цели.
Это должно быть достаточным доказательством того, что им пользуются профессиональные художники и дизайнеры, а не только «детишки».

Что касается новой IDE от Gdevelop, я думаю, что она отличная, но не полная. Один умный ход, который сделал главный разработчик, заключался в переносе ide на javascript, что сделало его очень доступным для разработчиков, не использующих C++. До сих пор я вносил в него небольшие исправления — просто чтобы играть и учиться. В эти выходные я попытаюсь сделать несколько шагов, чтобы интегрировать в него piskel 😃 — если все в порядке, возможно, появится встроенный пиксельный редактор.
Главный разработчик недавно объединил вклад другого разработчика, добавив поддержку драконьих костей из коробки. Если вы хотите, попробуйте новейшую версию с github, а не онлайн-демонстрацию. У него есть товар
https://github.com/4ian/GD/релизы

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

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

Это выглядит потрясающе! Спасибо за разработку/продвижение этого, blurymind.
Я занимался геймдевом около 23 лет, в основном перепробовал все — все популярные инструменты/движки геймдева, языки программирования и т. д., и я предпочитаю листы событий в конце дня, потому что это позволяет мне закончить игру. :)
Наличие нисходящего списка, разделенного между условиями и действиями, делает его более упорядоченным и кратким, чем любая другая система. Поскольку я больше ориентируюсь на визуальное восприятие, наличие жесткой вертикально-горизонтальной структуры позволяет мне легко перемещаться по программе/событиям.
Другие визуальные сценарии, требующие спагетти-связей, очень беспорядочны и отвлекают — визуальные детали разбросаны в шумной эстетике, которая нарушает концентрацию для людей с визуальным мышлением (тех же людей, для которых, как предполагается, предназначены визуальные сценарии).
Листы событий для меня самые лучшие. Я провел 23 года, используя все - blitzbasic, gamesfactory, unity, c++, javascript и т. д., и я уверен в этом - я люблю листы событий!!

Просто хотел вмешаться, редактирование стилей Blueprints / node чрезвычайно сложно организовать / избежать «кода спагетти». Всем, кто думает, что это то же самое, что и события в стиле Clickteam/Construct/GDevelop, я прошу прощения, но они радикально отличаются, и листы событий объективно лучше (игры основаны на правилах ЕСЛИ/ТО по своей природе, и вы можете гораздо легче переходить от событий к коду, но события в целом быстрее, чем кодирование логики игры).

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

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

Я думаю, что вы абсолютно правы. Как и @prominentdetail, я начал с

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

• Сообщество разработчиков, использующих листы событий, жаждет 3D-движка, использующего листы событий. Оба сообщества clickteam fusion пытались интегрировать это как аддон (firefly) и Construct (пробовали многочисленные плагины), но эти аддоны не предоставляли возможности редактирования 3D-сцены — это были хаки, чтобы заставить листы событий работать с 3D-движками — поставить поверх 2d Редактор движка не предназначен для 3D-игр. Вы можете построить 3D-сцену только с логикой событий, что затрудняет размещение объектов, материалов и т. д.
• И обучающиеся, и опытные программисты по-прежнему любят листы событий и используют их для прототипирования, а не только для обучения.
• Многие инди-команды успешно использовали (и до сих пор используют) листы событий для создания успешных игр — киктартер, стим и другие платформы — но очень немногие из них являются 3D-проектами из-за первого пункта.

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

Кстати, мне удалось собрать Piskel и интегрировать его с Gdevelop. Это занимало меня последние несколько недель. Можете попробовать, если хотите :)
Я также смотрел, как листы событий создаются в gdevelop.

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

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

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

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

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

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

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

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

Ну и что, что золотой середины достичь невозможно. Что-то просто вымрет. Что бы это ни было.

Лично я мог бы проголосовать за Blueprints, потому что у меня есть предыдущий опыт работы с ним, и я хотел бы, чтобы Unreal сравнивался с более крупной рыбой.
Но просто для сравнения, я освоил GDevelop менее чем за 15 минут. GDScript менее чем за несколько часов в отдельные дни, а Blueprint точно вдвое больше, чем GDScript.
Хотя это также показывает мой уровень опыта как программиста.

Я просто не могу решить. Вот см.

1. Единство: 4011
2. Нереально: 316
3. Гейммейкер: 274
4. Конструкция: 223
5. Годо: 75
   _Список из твита Reduz о количестве игр на движок в Global Jam._

Я хочу, чтобы Годо был на вершине. Так что, надеюсь, немного любви к VS поможет достичь этого.
Но Unreal + Godot + GameMaker + Construct по-прежнему не подходят. Но делает это номер 2 по крайней мере.

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

«EventSystem на каком-то уровне похожа на программирование с помощью Scratch. В то время как Blueprint совершенно уникален, но он более мощный, чем EventSystem, потому что EventSystems становятся более запутанными из-за глубины и имеют меньшую читабельность».

Что?? Совсем наоборот, если вы попробуете систему событий Construct, в частности, включая другие листы событий и используя группы.

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

@bigelod Правда, так говорить не следует. Я думал, что это похоже. Я написал этот комментарий в течение 2 часов, изучая EventSystems. Извините, это исправим.

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

@swarnimarun много лет назад я отправил листы событий разработчикам godot на этом самом трекере. Но тогда я не проделал большой работы, и уже было больше поддержки чертежей, потому что многие пользователи godot также были пользователями ex unity/Unreal. Чертежи уже выиграли и теперь находятся в Godot.

Теперь многие пользователи, которые на самом деле пришли из таких движков, как clickteam fusion, Game Maker и Construction, поддерживают листы событий и очень не любят использовать чертежи. Они скажут противоположное тому, что вы говорите, и объяснят то, что уже было объяснено — почему чертежи сбивают с толку по сравнению с листом событий и даже сценарием. Я тоже уже сделал.

Черт, даже глядя на другие форумы по движку визуального программирования, вы можете увидеть негативную реакцию на любой новый системный движок чертежей:
https://rpgmaker.net/forums/topics/23922/?post=857285#post857285

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

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

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

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

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

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

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

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

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

@prominentdetail поднимает очень хороший вопрос.
Чтобы добавить к этому, я просто скажу это:
У Godot есть возможность стать первым полноценным движком для 3D-игр, поддерживающим листы событий. Это по определению поднимет его над всеми другими движками листа событий на данный момент.
Как я упоминал ранее, это уже пытались сделать как в Clickteam fusion, так и в Construct — в виде плагинов, даже в гейммейкере. И это неуклюжий бардак, потому что редакторы этих движков не имеют 3D-возможностей.

Clickteam fusion - движок Firefly:
http://clickstore.clickteam.com/firefly
https://store.steampowered.com/app/267655/Firefly/
Его раскритиковали в Steam из-за ужасного глючного аддона.

конструкция2 - q3d
https://www.scirra.com/tutorials/9456/Building-your-first-3d-game-with-the-q3d-plugin

Только посмотрите, как сложно настроить простую 3D-сцену без редактора 3D-сцен.
https://youtu.be/VUGsTdBpRCQ?t=6m17s

ИМХО, гибрид звучит как отличный способ получить недостатки обоих.

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

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

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

Eventsheet может легко стать инструментом для изучения программирования, особенно с API Godot. Поскольку у Godot уже есть многие из тех же вспомогательных функций. Таким образом, реализация EventSheet действительно может использовать GDScript.
Потому что вы можете создать систему, которая преобразует EventSheet в GDScript и сохраняет в отдельной скрытой папке, которая обновляется во время компиляции и может использоваться движком. По крайней мере, это то, что я понял. Это может быть самым простым решением.

Хотя я вижу, что это просто не может заменить Visual Scripting/Blueprints, потому что это хорошо, это не очень наглядно, в основном код в колонке, облегчающий понимание.

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

В настоящее время, ожидая исправления стороны Visual Scripting, я мог бы попытаться создать что-то с этим, если найду время. Это может быть весело (поможет мне изучить API Godot), попытаться реализовать базовую версию EventSheet. Если я сделаю какой-либо прогресс, обязательно обновлю здесь.

Чем листы событий отличаются от gdscript/языков сценариев?

Для новичков (вещи, которые делают его более привлекательным, чем программирование):

• Существует некоторое визуальное представление логики — использование значков, цветов и как можно меньше текста.
• Условия изображаются в левом столбце, действия - в правом. При кодировании и условия, и действия находятся в одном столбце, что затрудняет для некоторых различие между ними при чтении логики другого человека.
• Вместо длинной строки текста методы отображаются в виде простых слов — на английском языке и синтаксические знаки удаляются, когда это возможно — удаление шума синтаксиса делает чтение более четким.
• Intelisense/автодополнение представляет пользователю весь API, чтобы он мог видеть все доступные сеттеры или геттеры и отфильтровывать те, которые им нужны, инвертировано в то, как это работает в кодировании IDE, где автозаполнение отображается после того, как вы начинаете печатать, и весь API до сих пор скрыт в документации движка. Он также имеет визуальные подсказки для поиска вещей (значки). Он показывает непосредственно тип возвращаемых или ожидаемых переменных.
• Логика группировки позволяет вам создать собственную папку, которую вы можете свернуть/развернуть и перемещать. Возможность сворачивать блоки логики, которые, как вы решили, должны быть сворачиваемыми, очень удобна, когда вы организуете свой код и хотите скрыть его части, над которыми вы не работаете.

Для более опытных пользователей:

• У вас есть возможность очень легко изменить порядок выполнения событий, перетаскивая заполненные ячейки. Что это значит? При кодировании в ide- мы можем сделать это с помощью Ctrl+X и Ctrl+V. В системе листа событий вы можете изменить порядок, просто перетащив логическую строку или ячейки из одной строки в другую.
• Уже установленную логику визуально легче найти и прочитать, чем код — опять же из-за визуальных подсказок и расположения левого и правого столбцов — поверх цветового кодирования. Это действительно здорово, когда вы что-то прототипируете.
• Лист событий может автоматически заботиться о путях узлов для пользователя по умолчанию, поэтому при объединении и листе событий вам не нужно будет обращаться к другим узлам (родительским или дочерним), выясняя их пути относительно чего-либо. У вас по-прежнему есть возможность гибкости кода, но система позаботится об этом за вас в случаях, когда узлы не будут динамически изменять свои отношения родитель-потомок.
  Все, что вам нужно сделать, чтобы добраться до узла, это выбрать его из вспомогательного меню. Это ускоряет работу
• Он по-прежнему очень похож на gdscript — потому что все выражения находятся в gdscript, но он дает вам некоторые дополнительные преимущества в производительности. Я думаю, что если все сделано хорошо, это то, что понравится пользователям gdscript, независимо от того, опытные они или нет.

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

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

Я немного отвлекся на некоторые вещи с javascript, и мне бы понравилось, если бы другие попробовали это :) Но я вернусь к этому.

Я согласен с @mhilbrunner в том, что это должна быть

@blurymind
Итак, вы сказали, что работаете над таким плагином?
как называется репо? это уже на вашем гитхабе?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В любом случае, я все еще выясняю, как это сделать, и, к счастью, godot
gdscript будет получать типизированный скрипт, который лучше подходит
для создания bbcode для моего листа событий.
например одна из прелестей
поля выражения в системе списка событий заключается в том, что оно дает вам
четкая индикация типа ожидаемой переменной и даже загорается в
зеленый, если он действителен (см. clickteam fusion).
В настоящее время я пытаюсь выяснить, как сделать поле выражения, которое может
возьмите gdscript, но также используйте вспомогательное меню, которое я сделал. Опять же, это просто эксперименты в том, как это может работать. Это далеко не все, что можно использовать в атм..

В среду, 30 мая 2018 г., 22:59 Дэйвен Бигелоу, уведомления@github.com написал:

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

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

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/godotengine/godot/issues/17795#issuecomment-393333602 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AGMbVT30aPs63RYwxtFqDTHWVqclenRBks5t3xZTgaJpZM4S8wyr
.

@blurymind Я рекомендовал делать это с C ++, он будет лучше подходить и будет более полным с использованием этого метода. Даже я, который начал использовать C++ несколько недель назад, теперь может использовать его, исправлять ошибки и добавлять новые функции. Так что это не так сложно, наверное, немного. Однако мне все еще нужно использовать stackoverflow.

Но если вы хотите остаться и использовать GDScript и просто создать прототип для других, чтобы преобразовать его в полноценный инструмент, я думаю, вам следует поделиться здесь репозиторием, каким бы неполным он ни был.
Я буду рад помочь. Мне очень нравится идея EventSystem. И VisualScripting в настоящее время сломан, поэтому мне нечего делать.

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

@swarnimarun есть ли модуль hello world, который создает новый пользовательский интерфейс или изменяет существующий?
Можете ли вы порекомендовать какие-либо хорошие учебные пособия по началу работы, которые помогли вам?

В любом случае, сейчас я думаю об изменении синтаксиса gdscript, который вспомогательное меню будет генерировать на типизированный gdscript:
https://github.com/godotengine/godot/pull/19264
Затем он преобразуется в bbcode, который отображает интерактивный интерфейс ячейки листа событий.

Я сделал эту блок-схему, чтобы объяснить, как это работает на данный момент.
https://www.draw.io/#Hblurymind%2FGodot-eventSheetPrototype%2Fmaster%2FEventSheetDiagramPlan.xml

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

И я считаю, что вы используете GDScript для всего программирования, или вы используете C++.
Потому что нет модулей, которые позволяют вам делать что-либо по умолчанию или при запуске. Вы должны учиться на том, что уже есть. И создать свой собственный.

Преобразование в типизированный GDScript должно быть простым, если вы используете GDScript, а если вы используете C++, потребуется небольшое портирование. И насколько я знаю, ПР должны слить в любой момент. Он был рассмотрен и кажется в порядке. Еще не пробовал, но очень взволнован.

И позвольте мне предположить, что в настоящее время вы используете GDScript с get_method_list() и get_property_list(). Но я бы порекомендовал вам также использовать сигналы и группы, сигналы — это механизм запуска событий Godot. Я действительно не знаю о EventSystem, но если вы хотите создать что-то подобное в Godot. Убедитесь, что вы используете Godot в полной мере.

И, наконец, если вам нужна помощь, просто напишите мне в Twitter или Discord. Я буду свободен в течение нескольких дней прямо сейчас.

@swarnimarun Я использую gdscript для написания аддона, в нем уже используются сигналы для таких вещей, как запуск событий.
Да, я также использую get_method_list() и get_property_list() для отображения вспомогательного меню.

У вас одинаковый ник в твиттере и дискорде?

На данный момент мой план состоит в том, чтобы прототипировать графический интерфейс в gdscript, так как я знаю больше, чем C++.
У меня тоже есть некоторый опыт в javascript, но здесь это мало поможет.

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

@blurymind Тогда это очень хорошо. Я не видел этого на гифках выше. Поэтому я предположил некоторые вещи.

Что касается моего никнейма, то на Discord — Swarnim. И я думаю, вы уже знаете мой твиттер.

@blurymind - Отличная работа. Я буквально только что начал изучать C++ из-за улучшения производительности в Godot по сравнению с GDScript (в 3-4 раза быстрее, в зависимости от вашей метрики — см. bunnymark ). Если это вообще возможно, я бы порекомендовал идти прямо к золоту и использовать для этого С++, даже если это означает обучение на рабочем месте - оно того стоит. Дайте мне несколько недель, чтобы я освоился с C++, и я тоже готов помочь, если хотите.

@colludium Скорость в 3-4 раза выше не стоит усилий по изучению C++. Если вы хотите научиться делать более оптимизированные игры, вместо этого изучите C# (он станет быстрее по мере развития в Godot). А также теперь, когда появляется типизированный GDScript, он сделает GDScript намного быстрее, чем раньше. Близко к С#, это поверь.

С++ - это боль. Поверьте мне. Указатель, ссылки и компиляция кода — это не что иное, как боль. Если только вы не хотите построить будущее в качестве разработчика игр для крупной компании, или учитесь в колледже, или если вы настолько умны, что полностью знаете GDScript, или находитесь на профессиональном уровне программиста.

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

@blurymind Хотел спросить, какую версию EventSystem вы используете в качестве базовой, потому что я хотел создать прототип системы в виде модуля C ++, поэтому я хотел бы, чтобы он был синхронизирован с вашим, по крайней мере, на базовом уровне.

@swarnimarun - спасибо за совет по поводу C++. Я просто программист-любитель, перешедший из JavaScript, поэтому переход с минимальной болью на максимальную производительность — это то, что я ищу. Я не знал о планируемых улучшениях, которые сделают GDScript намного быстрее, — приятно знать. Теперь у меня затруднительное положение - C# или гораздо более простой для изучения GDScript...

@colludium Скажем, что бы вы ни нашли проще, видя, что ваш фон - это Javascript, я рекомендую GDScript, поскольку он также имеет динамическую типизацию, а с входящей статической типизацией он должен быть идеальным компаньоном.
И позвольте мне сказать вам, если вы когда-нибудь подумаете, что C++ — это язык, который вы должны выучить, просто зайдите на страницу Rust vs C++ на каком-нибудь форуме.

@swarnimarun Я использую godot 3.0.2
Вот тестовое репо, в которое я добавил проект
https://github.com/blurymind/Godot-eventSheetPrototype
Каждый может делать форки или пулреквесты 👍

Пожалуйста, не стесняйтесь начать писать модуль C++. То, что у меня пока есть, — это только основной строительный блок интерфейса — контейнер логической ячейки.

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

Остальное — это просто статический интерфейс, предназначенный для создания снимков экрана.

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

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

@blurymind Наконец-то! кто-то, кто очень четко понял, что визуальные сценарии Godot Engine 3.x бесполезны (слишком сложны для новичков, бесполезны для экспертов).

Система событий GDevelop великолепна! это очень полезно, особенно для создания полных шаблонов 2D-игр, а затем для добавления более продвинутых функций с помощью GDScript. Это сделает Godot Game Engine более привлекательным, популярным и распространенным!

Я искренне люблю Godot Engine, но делать 2D-игры для мобильных устройств — не самое простое и быстрое решение. Он мог бы предложить гораздо больше с упрощенной системой/системой событий). В Godot есть отличный редактор анимации, он действительно хорош и функционален, ему нужна более удобная система только в том случае, если я хочу создать 2D-платформер без написания тысяч строк кода (что я считаю бесполезным для создания базового супер- шаблон стиля mario bros для NES).

Я считаю , что идея @blurymind это фантастика! сообщество Godot значительно выросло, и я доволен этим. Я не сомневаюсь, что система событий будет реализована в следующих релизах. Visual Scripting (повторюсь) в настоящее время абсолютно бесполезен (я даже не могу найти туториалов, и никто не использует его из того, что я вижу в сети).

Приветствую, и спасибо за вашу фантастическую работу!

@XenonCoder В конце вы делаете интересное замечание.

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

Это хороший пример того, как что-то трудно использовать по своей природе, а затем оно будет использовано как самосбывающееся пророчество, чтобы объяснить, почему этого не следует делать (например: «ВИДИТЕ! Никто не хочет визуальных сценариев!»). вместо того, чтобы признать, что это просто не было сделано привлекательным или удобным для новичков способом.

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

То же самое относится и к любому дополнению к движку, которое недостаточно документировано или снабжено примерами.

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

Игровой движок Godot просто фантастический! У него невероятный потенциал. Делать 2D-игры — это номер 1! В течение многих лет я экспериментировал со всеми существующими игровыми движками и фреймворками и могу с абсолютной уверенностью сказать, что Godot — это проект, который обещает великие дела.

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

Нужны туториалы, документация в целом, и прежде всего упрощенная система в стиле Build 3, GDevelop, Game Maker Studio 2. Изначально как аддон для достижения в основном 2D игр, в будущем он улучшается и официально внедряется. Я понимаю, что это непростая задача, это всего лишь идея сделать Godot Game Engine идеальным решением для энтузиастов, студентов и профессионалов видеоигр.

Спасибо вам всем.

Вокруг игровых движков формируются магазины. Стало нормальным - писать дополнения на коммерческой основе. Для Конструкта в том числе. Все последние значимые плагины C2 являются коммерческими. Это связано не только со становлением рынка, но и усложнением продуктов, большими затратами времени на тестирование и исправление ошибок совместимости.
Я думаю... Годо находится в другой нише, и если Хуан не напишет и не поддержит приложение упрощенного программирования, вряд ли кто-то другой доведёт эту работу до конца.

Я вырос на Klik 'n Play, The Games Factory и Multimedia Fusion, а сейчас пользуюсь Construct 2. Визуальные сценарии с листами событий полностью отличаются от использования узлов машины состояний в стиле чертежей, связанных друг с другом, и для людей, которые привыкли к листам событий, это самый простой и эффективный способ программирования. Я бы с радостью приветствовал способ написания сценариев в GoDot с листами событий.

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

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

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

Если есть интерес к этому как к правильному модулю С++ или надстройке gdnative - каждый может попытаться реализовать это.

Видя, как много людей этого хотят, ничто не сделает меня счастливее, чем то, что это станет частью godot — или, по крайней мере, будет работать как часть godot.

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

Чтобы добавить к этому обсуждению, я хотел бы представить всем здесь фантастический пример визуального скриптового движка, использующего подход визуального программирования, основанный на соединениях узлов, который в настоящее время не соответствует целевой демографической группе.
https://youtu.be/b8GZ21YCh50?t=4m12s
Это чем-то похоже на https://www.reddit.com/r/unrealengine/comments/4nt0up/need_help_debugging_this_blueprint/

Обратите внимание на альтернативы, которые предлагает Gamesfromscratch.

Одна вещь, которую я хочу избежать здесь в этом дизайнерском предложении, — это предварительное определение поведения, которое выходит за рамки того, что узлы уже делают в godot, а также создание множества вкладок и графического интерфейса.
Лист событий godot должен работать точно так же, как код gdscript, только более тактильно/визуально.
Он не должен пытаться создать простой в использовании игровой движок поверх godot, а скорее делать то, что у godot есть, более доступным и быстрым для сборки.

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

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

В среду, 1 августа 2018 г., 06:46 Эльмапул, уведомления@github.com написал:

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

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/godotengine/godot/issues/17795#issuecomment-409456475 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AGMbVdqoa3AdMNfiM986iwIpNeqzqjVLks5uMUCvgaJpZM4S8wyr
.

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

Это хорошая идея! Я никогда не понимал этих чертежей, но подход, основанный на событиях, хорошо известен, особенно в сообществах моддеров, таких как Warcraft III World Editor.

Примеры экранов:


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

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

@Wiadomy
это изображение слишком маленькое, чтобы что-то увидеть/читать

@Элмапул
Извините, что-то было не так. Обновлено.

@Elmapul, хотя мой концептуальный аддон еще не может выполнять вложение, лист событий, который я предлагаю, включает вложение. И gdevelop, и build поддерживают вложенность строк — вы можете попробовать прямо сейчас, если хотите :)

@blurymind наконец-то начал работать над реализацией
Это будет большая помощь. Чтобы я начал разрабатывать систему листов событий для Godot.
Потому что было бы неправильно использовать метод Construct или GDevelop, так как работа Godot совершенно другая, и у нас есть вещи, называемые сигналами, которые также необходимо интегрировать, а затем еще кое-что.

здесь есть некоторая информация о листах событий конструкции, если вам нужна общая информация: https://www.scirra.com/manual/74/events
разные компании реализуют свои листы событий немного по-разному, поэтому у каждой из них есть свои особенности.
Может быть, я смогу создать видео, в котором суммируются различные части метода построения (поскольку это, вероятно, лучший способ в настоящее время). Я не знаю никаких исследовательских работ, хотя было бы интересно найти.

@prominentdetail Спасибо за ссылку, похоже, мне придется посмотреть, как сделать события более простыми в использовании, например, систему конструкций.
Моя первая идея состояла в том, чтобы иметь что-то похожее на аддон от @blurymind, но теперь, скорее всего, у нас должен быть другой API для листа событий, который упрощает кодирование и не является версией GDScript в визуальной форме.

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

@swarnimarun действительно лучше всего использовать движки какое-то время и подумать о том, как это можно сделать более удачным способом. Construct classic и gdevelop — отличные примеры.

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

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

Если узел содержит встроенные методы, они должны быть доступны в меню, которое вы получите, нажав «Добавить встроенную функцию».

Я твердо уверен, что мы должны сделать его простым и быть оболочкой для типизированного gdscript, но если это невозможно или практично - может быть другой API. Было бы целесообразно изучить, как текущий визуальный сценарий, реализованный в godot, работает как абстракция.

Если вам интересно, как создаются пользовательские функции в конструкции, вот ссылка на их документ
https://www.scirra.com/tutorials/823/создание-функции
:)

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

@swarnimarun спасибо, что

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

@Jummit, за исключением того, что вы вполне можете, попробуйте Construct 2. Он не раздувается больше, чем стандартный код.

И он мог бы иметь всю функциональность GDscript? Тогда чего мы ждем? Давайте получим листы событий в Godot!

@Jummit godot имеет всю необходимую вам функциональность в виде «узлов».

«Узлы» в godot похожи на «Поведение» в конструкции2.
Поведение платформера в build2 похоже на менее мощный узел kintematicbody2d :)
Вам не нужно писать все с нуля.

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

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

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

@swarnimarun , я создал общий обзор различных конструкций: https://www.youtube.com/watch?v=ioz3gHtA-Lg
Это в основном для тех, кто не слишком знаком с конструкцией, чтобы почувствовать ее. Я, вероятно, упустил из виду некоторые вещи, так как не все распланировал, но это может дать некоторое базовое понимание. Вероятно, мне следует сделать несколько видеороликов, в которых я на самом деле больше занимаюсь разработкой, чтобы показать сторону рабочего процесса, а не болтать о разных вещах. Дайте мне знать, если вы хотите что-нибудь осветить или исследовать.

Это чертовски уродливо для меня. Я имею в виду сценарии в видео.

@Wiadomy , в использовании он намного лучше, чем в этом видео. Листы событий в конечном итоге всегда выглядят чище и читабельнее, чем любая система на основе узлов.

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

Этот проект уже мертв?

@ Amr512 Я не думаю, что он умер. Наверняка есть большое желание вывести этот функционал на godot.
@reduz недавно даже
https://twitter.com/reduzio/status/1085206844275081218

Хотя я некоторое время не работал над аддоном, я решил пойти и начать вносить свой вклад в сам gdevelop, чтобы узнать больше о том, как запрограммирован его лист событий, а также помочь сделать его лучшей альтернативой платному опции.
https://github.com/4ian/GDevelop/

Некоторые университеты начали использовать gdevelop для преподавания курсов программирования.
https://github.com/4ian/GDevelop/issues/882

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

@blurymind Я оставил
Мне очень нравится эта идея.

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

Правило = событие
Список событий = Схема

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

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

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

@Xrayez, можешь поделиться
Также, просто взглянув на скриншот, я думаю, что вы упускаете суть - должно быть только два столбца, а не три. Слева= условия, справа= действия. Также вы должны иметь возможность перетаскивать события между ячейками, а также перетаскивать строки и вкладывать их. Чтобы построить это, нам нужно использовать сортируемое дерево. Поиграйте с gdevelop и build, и вы лучше поймете, что делает эти листы событий такими красивыми.

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

class_name SchemeCondition extends Node

func is_met(object): # override
    return true

class_name SchemeAction extends Node

func perform(object): # override
    pass

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

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

Construct, Gdevelop, Stencyl, Game Maker, Playmaker, Bolt, Fungus для Unity, Blueprints в Unreal, Flow Graph и Schematyc в CryEngine и т. д.

Создается и используется множество инструментов для некодеров. Благодаря им сделано много хороших игр.
Например, Hollow Knight был сделан с плеймейкером.

У вас даже есть такие вещи, как Dreams, которые производят довольно много шума.

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

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

Это вроде того, что я думаю, может хорошо работать для godot.

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

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

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

В любом случае, если бы мои знания С++ были лучше, я бы попробовал :) Но я знаю javascript, поэтому вместо этого мой вклад идет в gdevelop.

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

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

На самом деле Construct 2 был моим самым первым знакомством со многими фундаментальными концепциями программирования в классе, который я проходил еще в старшей школе. Я чувствую, что это значительно упростило и ускорило процесс обучения для меня — как движка в частности, так и программирования в целом — и в то же время достаточно точно переведя реальный код, чтобы я не чувствовал себя полностью потерянным при переходе от листов событий. к обычным старым текстовым сценариям. Хотя я не могу быть уверен в этом на 100%, я действительно не думаю, что мог бы получить какое-либо из этих преимуществ в той же степени, если бы вместо этого использовались визуальные сценарии типа спагетти.

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

На самом деле, основная причина, по которой я изначально отказался от Construct 2, заключалась в том, что я уже хотел погрузиться в 3D. В конце концов я попробовал Unity, Unreal, Godot и Amazon Lumberyard, и в итоге остановился на Godot просто потому, что его было проще открывать и использовать, а процесс импорта — лучше. Но если бы у Godot была система в стиле списка событий, я бы, вероятно, сразу же выбрал Godot по умолчанию. Конечно, лично для меня сейчас это не имеет значения, но опять же, речь идет о том, чтобы сделать Godot как можно более дружелюбным к непрограммистам (т. е. к значительной части новых/начинающих разработчиков игр).

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

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

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

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

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

Я также начал с Construct 2 и обнаружил, что листы событий отлично подходят для решения 2.
проблемы:

• Подобно любому визуальному сценарию, вы раскрываете все возможности любого
  модуль/плагин/надстройка/функция, это очень полезно для изучения нового кода.
  Однако визуальные узлы довольно быстро превращаются в спагетти-код (я блендерщик,
  Я знаю о спагетти в композиторе и шейдерах).
• Лист событий похож на чванство для Rest API, вы начинаете с хорошо документированного
  код, который заполняет раскрывающееся меню листа событий, и вы получаете чистый графический интерфейс
  способ использования вашего кода, вы можете расширить его, запутавшись, и вы можете
  сгенерировать из него код (JS из Construct2), поэтому мой вопрос: Можем ли мы
  генерировать код из него?

Если да, я думаю, лист событий должен стать приоритетом для простоты использования для
всем и оптимизированной низкоуровневой генерации кода.
Если бы Godot можно было использовать для преобразования python/C#/... API в чистый набор
события, затем события пользовательской сборки, затем Godot генерирует из них код, вы
решение очень-очень сложной пользовательской проблемы: научиться программировать с помощью простого пользовательского интерфейса.

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

Ср, 8 апр 2020 в 7:44 PM Jay [email protected] писал:

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

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

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

Я начал использовать Construct 2 и в конечном итоге перешел к разработке плагинов с использованием JavaScript, поэтому листы событий занимают место в моем сердце. Они были простыми и интуитивно понятными для непосвященных, с большей частью волшебства от простой визуализации доступных методов (действий и условий) для каждого класса (плагина). Честно говоря, GDScript в VSCode и сейчас так же хорош, с полным набором функций IntelliSense и автозавершением, что упрощает жизнь. Хотя я был большим поклонником этой идеи 2 года назад, сейчас я передумал. Я бы предпочел, чтобы герои-разработчики Godot сосредоточили свое время и усилия на добавлении других улучшений движка.

Можем ли мы сгенерировать код из него?

Мне нужно было бы изучить это подробнее, но я искренне думаю, что это было бы довольно тривиально, и на самом деле это, вероятно, лучший способ сделать это. То есть, я думаю, что лучший способ справиться со стилем листа событий — это использовать его в качестве графического интерфейса для обычного файла gdscript. Действия, предпринятые в редакторе списка событий, просто отредактируют файл gdscript. Например, перемещение блока из одного места в другое в редакторе листа событий будет фактически выполняться как виртуальное вырезание + вставка в файл gdscript. И любой файл gdscript можно просмотреть и отредактировать либо в редакторе скриптов, либо в редакторе листа событий. Кажется, это лучший способ сделать это, как с точки зрения удобства использования, так и с точки зрения реализации. Тем не менее, я еще не очень хорошо разбираюсь в разработке двигателей, поэтому могу ошибаться.

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

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

Я тоже недостаточно хорошо знаком с Gdscript или Godot.
Но то, что я разработал как расширение VS Code, также идет в этом широком направлении.
(https://github.com/j2l/blocklight).
Визуальное понимание кода, играя с его куском и визуально
связывание переменных и результатов (узлы в большинстве визуальных скриптов или цвета
в моем расширении) является недостающим краеугольным камнем для многих.
На самом деле мы понимаем код, когда закончили его изучать, а должны
увидеть переменные и ссылки фрагментов, прежде чем получить все
код.
Дизайн перед кодированием :)

Ср, 8 апр 2020 в 8:08 PM Jay [email protected] писал:

Можем ли мы сгенерировать код из него?

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

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

Мне нравится идея, что он будет генерировать обычный файл Gdscript. Было бы очень здорово для обучения

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

Мне нравится идея, что он будет генерировать обычный файл Gdscript. Было бы очень здорово для обучения

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

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

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

Он научит вас порядку выполнения и чтению кода.

Посмотрите, что конвертирует в GML в Game Maker
https://docs2.yoyogames.com/source/_build/3_scripting/1_drag_and_drop_overview/changing_dnd.html

Действительно интересный блумминд! У меня была такая же идея, и я полностью ее поддерживаю.
Я все еще делаю расширения для Clickteam Fusion 2.5, но все, что я хочу добавить в Fusion, находится в Godot.
Все, что мне нужно, это добавить еще один слой абстракции (лист событий) в Godot, чтобы упростить разработку.
Я не читал всю ветку, но с моей точки зрения основное различие между визуальным скриптингом в Godot и листами событий в других игровых движках заключается в том, что визуальный скриптинг — это «просто» визуальное представление кода, а листы событий — это абстракция код с упрощенным видом. Это более удобочитаемо для человека, факторизует вещи, для которых требуется несколько строк кода в одной строке, а связывание сигнала/слотов выполняется автоматически.
На самом деле, добавление некоторых шаблонов (предопределенных сцен) к абстрактному встроенному объекту CF2.5 и использование GDScript сделает большую часть работы за меня, но список событий определенно сделает меня более эффективным в Godot, чем то, что я делаю в CF2.5. в настоящее время.

Действительно интересный блумминд! У меня была такая же идея, и я полностью ее поддерживаю.
Я все еще делаю расширения для Clickteam Fusion 2.5, но все, что я хочу добавить в Fusion, находится в Godot.
Все, что мне нужно, это добавить еще один слой абстракции (лист событий) в Godot, чтобы упростить разработку.
Я не читал всю ветку, но с моей точки зрения основное различие между визуальным скриптингом в Godot и листами событий в других игровых движках заключается в том, что визуальный скриптинг — это «просто» визуальное представление кода, а листы событий — это абстракция код с упрощенным видом. Это более удобочитаемо для человека, факторизует вещи, для которых требуется несколько строк кода в одной строке, а связывание сигнала/слотов выполняется автоматически.
На самом деле, добавление некоторых шаблонов (предопределенных сцен) к абстрактному встроенному объекту CF2.5 и использование GDScript сделает большую часть работы за меня, но список событий определенно сделает меня более эффективным в Godot, чем то, что я делаю в CF2.5. в настоящее время.

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

Спасибо
поддерживаю эту замечательную идею
Говорят, конструктив 2 уйдет на пенсию!
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505

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

Спасибо
поддерживаю эту замечательную идею
Говорят, конструктив 2 уйдет на пенсию!
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505

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

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

Ваш лучший выбор в качестве альтернативы с открытым исходным кодом — переход на gdevelop.
https://github.com/4ian/GDevelop

Эта заявка на выпуск, вероятно, скоро будет закрыта, поэтому, если есть интерес к этому листу событий в godot - нам, возможно, скоро придется переместить его в другое место :) (или в gdevelop)

Скорее всего, этот тикет скоро будет закрыт, поэтому, если есть интерес к этому листу событий в godot, нам, возможно, вскоре придется переместить его в другое место :)

Какие? Почему?

@TheGoklayeh Он может быть закрыт, так как мы переводим предложения функций в

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

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

Спасибо
поддерживаю эту замечательную идею
Говорят, конструктив 2 уйдет на пенсию!
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505

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

Это может разрушить их бизнес. и кликтим в придачу.

Спасибо
поддерживаю эту замечательную идею
Говорят, конструктив 2 уйдет на пенсию!
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505
Интересно, можно ли договориться с разработчиком конструкции 2, чтобы открыть исходный код системы событий и использовать ее в годоте, единстве и т. д.
Это потеря, что система событий конструкции 2 заброшена на полки неиспользованными

Это может разрушить их бизнес. и кликтим в придачу.

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

@TheGoklayeh Он может быть закрыт, так как мы переводим предложения функций в

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

Может ли кто-нибудь сделать это вместо меня? :)
Я как бы потерял надежду на то, что эта функция когда-либо появится в Godot изначально (а не в расширении). Спагетти-подход покорил пользователей и разработчиков Godot

@blurymind Если вы больше не поддерживаете это предложение, то я думаю, что лучше его закрыть. Кто-то еще, кто заинтересован в работе над подходом к листу событий, может затем открыть новое предложение на godot-proposals . (Из-за огромного объема требуемой работы я не думаю, что имеет смысл открывать предложение, если никто технически не в состоянии его выполнить.)

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

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

Это смешно.. но я думаю, что конструкция 3 достаточно сильна, чтобы сделать систему событий
Это лучше, чем ничего на данный момент

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

Честно говоря, мне нравится, как это делает GDevelop, но Godot, делающий сценарии событий, не то, что я поддерживаю сейчас (в эти дни).
Однажды я попытался реализовать его, и меня поразило осознание того, что у Godot есть чрезвычайно гранулярный/низкоуровневый API, который можно открывать непосредственно из системы визуальных сценариев.
Текущая система визуальных сценариев включена и почему я бы предпочел, чтобы она имела собственный уровень абстракции, но при этом была надежной.
Такую реализацию безумно сложно написать для сценария событий, если только вы не используете несколько DSL, таких как языки подсобытийных сценариев, где каждый используется для определенной части движка.

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

Я планирую постепенно развивать Visual Scripting в направлении, в котором он может иметь специализированные интерфейсы для всех частей Engine.
Представьте себе другой способ редактирования для каждого типа примитивного сложного узла, например, в Blueprints, имеющего узел выражения.
https://docs.unrealengine.com/en-US/Engine/Blueprints/UserGuide/MathNode/index.html

Но для ясности: я не против сценариев событий, я хотел бы, чтобы кто-то выступил с предложением, которое может охватывать некоторые конкретные системы Godot, и почему и как это может быть полезно. Лично я нахожу довольно удобным для программирования Behaviours то, как это делает GDevelop.
http://wiki.compilgames.net/doku.php/gdevelop5/behaviors
http://wiki.compilgames.net/doku.php/gdevelop5/behaviors/events-based-behaviors

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

Хотя то же самое можно сказать и о VisualScript, и с его помощью, вероятно, будет намного проще достичь модульности. Проблема будет заключаться в унификации и согласованности (Visual Shader и VisualScript используют совершенно разные кодовые базы, единственное сходство заключается в используемых узлах пользовательского интерфейса).
Тем не менее, мы, безусловно, можем попробовать использовать систему Event Script в виде плагина (плагин C++, надеюсь, это станет легко сделать после 4.0), который может поддерживаться сообществом и добавляться в Godot при необходимости. (Я склоняюсь к модульному игровому движку)

В любом случае это только мои 2cents.

Почему мой комментарий был помечен как оффтоп? Кто-то подвергает цензуре сообщество и кто? Это не сулит ничего хорошего. Помимо моего, есть и другие комментарии, которые более не по теме.

@prominentdetail Вот мое сообщение об уведомлении об

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

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

PS: это типичный этикет на GitHub; это не относится к этому репозиторию.

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

Попробовать стоило, и дискуссия наверняка была интересной :)

@blurymind, если вы все еще поддерживаете это предложение и готовы потратить время на то, чтобы написать его в формате, необходимом для GIP. Это стоит сделать ИМО.

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

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