Godot: Secuencias de comandos visuales de estilo de hoja de eventos

¿No podría aliviarse mucho de esto potenciando el Visual Scripting actual con más y mejores funciones?

Muchos de los ejemplos son triviales en el modelo de UE4. "Al presionar la tecla W, mover este actor hacia adelante".
Podría construir la mayoría de estos de una manera muy similar en el plano e incluso las diferencias visuales (que serían las únicas) serían mínimas.

Deberíamos centrarnos en hacer que el Visual Script que tenemos sea utilizable y funcione de una manera intuitiva y fluida, en mi opinión. Tal como está, el Visual Script que ya tenemos se siente un poco olvidado y no parece recibir mucho amor. ¿Cómo mejoraría esta situación tener dos sistemas de Visual Scripting?

Una buena idea para un complemento. Pero mantener oficialmente dos sistemas de secuencias de comandos visuales sería una molestia y una pequeña ganancia.

@mhilbrunner desafortunadamente no, Blueprints es un enfoque completamente diferente para la secuencia de comandos visual. Para ti son triviales, pero te reto a decirlo en el foro de clickteam o en el foro de construct. Esos muchachos están atrapados con los motores que usan debido a lo mucho que aman este enfoque y, créanme, muchos de ellos han probado los planos en Unity, unreal y otros motores, incluido Godot. Todavía están atascados con construct2 o clickteam fusion porque prefieren las hojas de eventos a los Blueprints. Todavía solicitan el enfoque de la hoja de eventos en el foro de Unity.
El scripting visual de Godot fue mencionado en sus foros y los usuarios aún prefieren las hojas de eventos. Personalmente hice la transición a gdscript y prefiero usar gdscript en lugar de blueprints, porque gdscript está más cerca de las ventajas de las hojas de eventos que los blueprints.

Es como decirle a alguien a quien le gustan los plátanos que coma tomates en su lugar, es cuestión de gustos :)

@groud Pensé lo mismo por un tiempo, pero ni siquiera estoy seguro de por dónde empezar, e incluso como complemento, alguien tendrá que mantener el complemento.

@reduz pareció sentirse más a

En cualquier caso, estoy publicando esto aquí como documentación, para delinear el sistema de hojas de eventos, qué hace y en qué se diferencia de los planos. Si alguien más está interesado en implementarlo en Godot o como complemento, háganoslo saber. Definitivamente me arremangaría y ayudaría, difundiría las noticias y obtendría comentarios de los usuarios de clickteam/construct.

Hasta ahora, ni siquiera sé cómo implementar correctamente su interfaz con la clase GUI de Godot. Debe poder arrastrar bloques lógicos entre celdas de la misma columna. Copiar/pegar bloques/filas también - anidar filas y
otras cosas únicas. No creo que sea una tarea pequeña.

@blurymind Sí, y definitivamente gracias por señalar esto y tomarse el tiempo para la redacción detallada. Todavía creo que esto sería mejor como complemento.

devs: ¿Cuál es la mejor manera de agregar esto con una complejidad mínima? Tal vez encontraré algo de tiempo para ver cómo funcionan las secuencias de comandos visuales actuales. Me pregunto si es posible en su mayoría simplemente reemplazar la interfaz de usuario de Visual Scripting o generar GDScript o alguna otra forma de hacer esto dinámicamente.

Sin embargo, todavía no he investigado nada de esto, por lo que se agradecen los consejos. :) ¡Sin punteros nulos, por favor!

@mhilbrunner quizás podamos abrir otro problema en el rastreador con una lista de cosas que necesita el sistema de planos en Godot para ser más intuitivo. Por favor enlace a él si lo hace

Mi publicación aquí es una propuesta para un enfoque alternativo, no para un cambio del implementado actualmente. Las hojas de eventos son demasiado diferentes de todos modos

Creo que dicha hoja de eventos podría implementarse a través de Nativescript, pero no veo ninguna razón por la que deba confiar en la misma base de código que visualscripting.

@groud ese es un buen punto en realidad. ¿Cuánto del código base actual de VisualScripting se puede reutilizar? ¿Qué tan específico es para la interfaz de nodegraph?

@blurymind Sí, te tengo, trabajando en una lista de este tipo para VS y lo haré, pero llevará algún tiempo.

Necesito investigar NativeScript :)

Ahora tenemos múltiples opciones para lenguajes de secuencias de comandos (C++, C#, incluso python). ¿Por qué no tener más de una opción para secuencias de comandos visuales? :)

Supongo que esto también podría depender de cuán flexible sea la API de Godot para construir interfaces de secuencias de comandos visuales.
¿Debería reutilizarse el código base de VisualScripting, o debería escribirse uno completamente alternativo con Nativescript (c++)?
¿Se puede implementar esto simplemente como un complemento de gdscript?

¿Por qué no tener más de una opción para secuencias de comandos visuales? :)

Porque ya admitimos demasiados idiomas integrados. La mayoría de los casos de uso ya están cubiertos, por lo que no hay muchas razones para agregar un nuevo lenguaje para mantener. Tenemos un lenguaje para programación básica (GDscript), dos para actuaciones (C# y C/C++) y uno para artistas/diseñador de juegos (guiones visuales). No hay razón para agregar otro idioma como integrado solo porque algunas personas no pueden manejar el aprendizaje de un nuevo idioma.

Honestamente, definitivamente no creo que esto deba agregarse al núcleo. Sería mejor agregarlo a través de un complemento como cualquier otro enlace de idioma. Ya tenemos suficiente trabajo para mantener los idiomas actuales.

Y no, no creo que podamos reutilizar el código de VisualScripting.

@groud Ese es un buen punto, pero considere la proporción de programadores a artistas en gamedev. Algunos de los mejores y más hermosos juegos retro en 2D han sido creados con fusion 2 por artistas que querían crear juegos de una manera intuitiva que se adaptara a su forma de pensar. Aquí hay un showreel un poco desactualizado de juegos hechos por Fusion:
https://www.youtube.com/watch?v=3Zq1yo0lxOU

Tienen muchos proyectos exitosos de kickstarter y juegos en Steam, juegos en muchas plataformas. A la gente le gusta usar este enfoque en la programación visual, incluso en equipos profesionales. No lo estaría presentando aquí si no viera el potencial de expandir la base de usuarios

Bueno, tal vez, pero ¿cuántos de ellos pueden entender las hojas de eventos pero no VisualScripting? Estás diciendo que "esos muchachos están atascados con los motores que usan debido a lo mucho que aman este enfoque y créanme, muchos de ellos han probado los planos en Unity, unreal y otros motores, incluido Godot", pero en realidad estás el primero en preguntar eso.

Si esta es una demanda popular, sí, podríamos agregarla al núcleo. Pero hasta ahora no lo es.

Para mí, ya cubrimos todos los casos de uso. Al menos para un motor de juego profesional y de última generación. Y como no nos dirigimos a niños o aficionados sino a empresas, no merece la pena dedicarle tiempo. Fusion 2, Construct o incluso RPGMaker se enfocan en otra audiencia, incluso si se han creado hermosos juegos con ellos, solo una pequeña parte de ellos son proyectos profesionales.

@groud estas estadísticas son difíciles de conseguir. ¿Cuántos están usando el guión visual actual?

También estoy destacando por qué el enfoque de la hoja de eventos tiene ventajas sobre los blueprints, como menos clics para que las cosas funcionen, una presentación más clara y una mejor transición de aprendizaje a gdscript.

El motor de creación de rpg es realmente un editor de niveles si me preguntas. No tiene el mismo nivel de flexibilidad que Fusion y construct2

Es más fácil explicarle a alguien cómo funciona una hoja de eventos, que explicar el mismo ejemplo en un plano, tienen que aprender muchos menos conceptos, no es necesario que les enseñen el tipo de conexiones entre nodos, tipos de entradas y salidas. - cómo configurar el flujo.
En cambio, los eventos fluyen de arriba hacia abajo, la izquierda es condición y la derecha es acción. No tienes que conectar nada.

Haz esto

parece tan difícil de entender como esto?

Claro, Godot usaría más bloques de eventos para lograrlo, pero aun así sería más claro que un gráfico de nodos.
Incluso gdscript me parece más claro que eso. Nuestro actual sistema de guiones visuales parece complicado a primera vista

Hablo como alguien que ha usado ambos sistemas y ahora los está comparando: ambos son igualmente poderosos, uno es claramente más simple de aprender y entrar
Pruébalo por favor. Puede probar construct3 en su navegador web de forma gratuita aquí:
https://www.scirra.com/
Si tiene un hijo o un hermano menor, pídales que lo prueben, luego intente con Godot. Vea qué pueden hacer y cuánto tiempo les toma hacerlo sin instrucciones. Existe un mercado potencial para que más escuelas adopten Godot aquí. - mejore las secuencias de comandos visuales para aprender conceptos de programación y obtendremos un grupo demográfico más joven usando el motor

¿Cuántos están usando el guión visual actual?

No tengo ni idea, pero creo que no mucho por ahora. La mayoría de la gente parece usar GDScript por ahora, ya que no veo muchas preguntas/contenido sobre VisualScripting en Facebook o Youtube. Agregar hojas de eventos antes de estar seguro de que VisualScripting no responde a todos los casos de uso sería una apuesta audaz. Veamos por ahora si VisualScripting es suficiente, y si la gente solicita masivamente otro sistema, podríamos agregarlo más adelante.

@groud sería genial si pudiéramos probar el guión visual de Godot en un entorno escolar, con los niños aprendiendo conceptos básicos de codificación.
Uno de los mayores puntos de venta de construct2 ha sido enseñar a los niños a codificar y han estado vendiendo una licencia educativa especial durante años.

Mi argumento es que el script visual en Godot en este momento no es muy atractivo para los no codificadores y realmente no ayuda a las personas a aprender a codificar, porque su enfoque es puramente centrado en la máquina de estado y los conceptos básicos de programación se complican aún más con nodegraph adicional. reglas céntricas en la parte superior.

Los programadores experimentados realmente no son la mejor audiencia para vender esto, porque verían la hoja de eventos como una simplificación de lo que ya tenemos: gdscript y verán los planos como una nueva herramienta que los diseñadores podrían usar como una máquina de estado.

Me encantaría intentar escribir un complemento de hoja de eventos básico en gdscript, realmente no tengo la experiencia suficiente para hacer un complemento de script nativo. Si eso es posible y tiene algunos consejos por dónde empezar, me encantaría escucharlos.
Tal vez si hay suficiente interés, alguien podría hacerlo en nativescript

porque su enfoque es puramente centrado en la máquina de estado

Qué ? No tengo idea de por qué pensarías eso. VisualScripting no tiene nada que ver con máquinas de estado.

¿Qué es más fácil de usar en este momento: Blueprints o Gdscript? Cuál es el objetivo de la secuencia de comandos visual y quién es el usuario objetivo

VisualScripting debería ser más simple que GDscript para artistas/desarrolladores de juegos. Tengo que admitir que no es realmente por ahora, probablemente un montón de nodos podrían simplificarse/hacerse más atractivos. Pero honestamente, te equivocas al pensar que las Hojas de Eventos son más fáciles de entender que VisualScript, para mí no lo son.

Lo único que realmente marca la diferencia en los ejemplos que muestra es el texto y los íconos que hacen que las cosas sean mucho más comprensibles. Son el texto y los íconos los que hacen que las cosas sean más explícitas y sencillas, no la organización vertical. VisualScripting sería tan comprensible si agregáramos dichos íconos, si hiciéramos una GUI mejor para las acciones más comunes y agrupamos las funciones en categorías pertinentes.

@groud es también el orden de ejecución y los tipos de conexiones. Hay muchos más conceptos a tener en cuenta en el gráfico de nodos que en la hoja de eventos. Incluso si agrega íconos a los nodos, todavía tiene que explicar que el orden de los eventos está dictado por las líneas blancas, también lo que significan los otros colores. Todavía terminas con un gráfico de espagueti que es más difícil de leer: tus ojos tienen que viajar por todo el lugar para descubrir qué está pasando en el gráfico de otra persona.

No eres el público objetivo adecuado: eres un programador experimentado de C++. Pruebe esto con personas que no sean programadores y comenzará a ver lo que quiero decir.

Vamos, eso no es tan difícil de entender, una vez más, no estamos apuntando a los niños.
Y con respecto a la organización del código, el problema es el mismo para las hojas de eventos. Si no se molesta en agrupar nodos y organizar su código, terminará con un código ilegible, ya sea debido a largas hojas de eventos o enormes gráficos de nodos.

@groud, ¿podemos incluso agrupar nodos de VisualScript como en Blender? No recuerdo haber visto eso. Quizás @mhilbrunner debería agregarlo a su lista
https://github.com/godotengine/godot/issues/12418
Otro punto importante es que la capacidad de crear bloques lógicos de acción/condición de nivel superior reutilizables a través de gdscript sería muy beneficioso para un sistema de hoja de eventos o el sistema de blueprint. El sistema de blueprint ya lo tiene, pero no veo ningún complemento creado para él.

Una vez más, construct2 está muy por delante de nosotros. Su comunidad ha creado muchos complementos fáciles de instalar que agregan condiciones y acciones personalizadas, y su API para registrar una acción y una condición es muy simple.
https://www.scirra.com/forum/completed-addons_f153
https://www.scirra.com/manual/19/acciones-condiciones-y-expresiones

Totalmente de acuerdo con blurymind
Para mí es mucho más fácil de entender el sistema de eventos Construct and Fusion, que además ofrece mucho más rapidez para desarrollar cualquier juego que un sistema lleno de líneas.

jajaja, ¿cómo es esto más fácil de leer que gdscript?

@groud, ¿podemos incluso agrupar nodos de VisualScript como en Blender? no recuerdo haber visto eso

No sé. Pero si no está implementado, creo que debería estarlo.

jajaja, ¿cómo es esto más fácil de leer que gdscript?

Este no es el punto aquí.

@groud sí lo es. ¿Por qué un desarrollador de juegos querría usar hojas de eventos cuando es mucho más desorganizado/confuso de leer que el simple código gdscript? ese es todo el quid de esta sugerencia de función, ¿no es así?

@groud sí lo es. ¿Por qué un desarrollador de juegos querría usar hojas de eventos cuando está mucho más desorganizado que el simple código gdscript?

No, no lo es, VisualScripting (o Event Sheets) y GDscript no se dirigen a las mismas personas. VisualScripting (u hojas de eventos) son para artistas o diseñadores de juegos/niveles, mientras que gdscript requiere experiencia en programación.

Comparar Event Sheets y GDscript no tiene sentido.

Comparar Event Sheets y GDscript no tiene sentido.

bueno, ahí es donde diferimos :P porque creo que es más que razonable compararlos. especialmente porque gdscript hace todo lo que ellos hacen, a un nivel mucho más simple.

Además, no estoy de acuerdo con "requiere experiencia en programación". si un diseñador de niveles está creando bloques de acciones _en una hoja de eventos o scripts visuales ya_, _ya tiene los bloques de construcción fundamentales_ para usar gdscript.

dicho esto: gdscript compilado con JIT está en la hoja de ruta, y sería mucho más beneficioso que las hojas de eventos o las adiciones de secuencias de comandos visuales (ya que la mayoría de los desarrolladores de Godot ya podrían beneficiarse enormemente de él). y los posibles casos de uso de VS/Event Sheets son bastante bajos actualmente. así que todo lo que pido, sea cauteloso con el tiempo de desarrollo principal, como ya se ha mencionado en su publicación reciente

@girng ¿En qué momento
Ni siquiera está en el mapa de carreteras, pero saltas sobre él como si estuviera aquí para desayunar. :pags
Explorar una idea no es lo mismo que exigir tiempo.

Obviamente, nunca has tocado construir o fusionar clickteam, si quieres tener una discusión al respecto, al menos usa la hoja de eventos por un tiempo, haz un juego de plataformas con él.
Me vinculé a una demostración en línea de construct3, que no requiere que registre una cuenta o inicie sesión.
https://www.scirra.com/
está literalmente a tres clics de distancia

Pruebe la hoja de eventos, haga algo con ella. Luego usa los planos de VisualScript que tiene Godot.

Gdscript es simple, sí, estoy de acuerdo y también me encanta. ¡Un gdscript compilado con jit sería increíble! De acuerdo, es más importante también.
Pero esta discusión no es sobre esas cosas en absoluto.

bueno, ahí es donde diferimos :P porque creo que es más que razonable compararlos. especialmente porque gdscript hace todo lo que ellos hacen, a un nivel mucho más simple.

Lo que no entiendes es que para muchas personas existe una barrera mental entre codificar y no codificar. Debo admitir que VS es un poco difícil de entender por ahora, pero en el futuro debería ser más fácil que GDScript, ya que se podría haber creado una gran cantidad de material de aprendizaje y se deberían realizar varias mejoras de VS.

Además, no estoy de acuerdo con "requiere experiencia en programación". si un diseñador de niveles ya está creando bloques de acciones en una hoja de eventos o secuencias de comandos visuales, ya tiene los bloques de construcción fundamentales para usar gdscript.

Sí, también estoy bastante de acuerdo como programador, pero esto no es lo que muestra la experiencia.
Unreal es el ejemplo perfecto: mucha gente usa blueprints con Unreal, especialmente en el área profesional, ya que permiten que los no programadores escriban código de una manera más acogedora. Incluso si no es tan diferente del código real (en mi opinión), hace las diferencias en la mente de las personas. Si los profesionales lo usan, significa que es una necesidad real, no un dispositivo que debamos dejar porque pensamos que son lo mismo. Por eso no tiene sentido compararlos, ambos deberían estar disponibles y funcionando correctamente.

De todos modos, voy a detener esta discusión aquí. El bikeshedding sobre VS o no VS ya ha sido tratado.

@blurymind admiro tu energía y tienes buenos puntos. He probado las hojas de eventos en construcción antes y eran geniales al principio, pero cuanto más avanzado se volvía mi juego, instantáneamente quería volver al código. así que sí, los he probado en el pasado.

@groud tiene un buen argumento sobre ellos, ya que Marvel Heroes era un aRPG AAA y usaban planos con Unreal .

No estoy en desacuerdo, tienen sus casos de uso, solo creo que será difícil de justificar, según los siguientes criterios:

• mano de obra de desarrollo limitada
• cantidad de problemas actuales ya
• desorganización/difícil de leer (ver aquí )
• Siento que la mayoría de los desarrolladores de Godot preferirían usar gdscript
• gdscript ya se relaciona tan bien con godot
• si se agrega a core , podrían surgir nuevos problemas relacionados con las hojas de eventos, lo que podría eliminar los problemas de gdscript
• no es justo para el 90% actual de los desarrolladores de Godot que ya usan gdscript (si el tiempo de desarrollo pudiera usarse para gdscript compilado con jit, que cumple con los casos de uso activos)

como un complemento que podría admitir completamente, pero mi corazón dice que podría no ser una buena idea si es oficialmente compatible

@girng gracias. Una vez más, esta no es una solicitud para reemplazar gdscript o visual script.
Es más una observación sobre el scripting visual en general y cómo el scripting visual de Godot en este momento no es realmente fácil de usar para los no programadores.

Gdscript puede vincularse a la perfección con cualquier sistema de secuencias de comandos visuales: hojas de eventos o planos.
Como se señaló en mi primera publicación, el enfoque de la hoja de eventos también usa expresiones, para las cuales ya se puede usar gdscript. Los bloques lógicos de nivel superior se pueden crear a través de gdscript y el sistema de complementos de godot también; se relaciona maravillosamente con un sistema de script visual.

De hecho, un sistema de hoja de eventos puede combinarse mucho mejor con gdscript que con el sistema blueprint actual, donde las expresiones se realizan con mil millones de gráficos de nodos en lugar de una simple entrada de campo de texto. Si quieres hacer 1+1- usa un nodo. Si desea abordar una variable simple en una expresión, use otro nodo. Terminas con un lío de espagueti de mil millones de nodos básicos para una expresión simple que podría escribirse con la misma facilidad y mucha más claridad en un pequeño campo de texto con mucho menos esfuerzo y verbosidad.

El script visual actual que tenemos requiere demasiados clics, nodos y verbosidad para hacer las cosas más simples. Esa es otra razón por la que gdscript es más sencillo: una línea de código en lugar de 10 nodos y 100 conexiones.

Esa es básicamente la otra ventaja de un sistema de hoja de eventos: simplemente puede escribir sus expresiones dentro de los campos de entrada del bloque de código. Tanto construct2 como fusion incluso tienen editores de expresión y autocompletar con fácil acceso a todos los métodos que tiene un nodo con una lista de todos los nodos a los que tiene acceso la hoja en el alcance.

Godot podría simplemente usar gdscript para expresiones cuando hace lo mismo, pero esas expresiones se colocan en una estructura de hoja de cálculo simple.

Imagine un método en Godot, como un bloque lógico. Al igual que su método, ese bloque toma los mismos parámetros, pero no necesita conectarlo a los nodos. Simplemente puede escribir algo de gdscript en su campo de entrada.
Los nodos en godot pueden actuar como comportamientos en construct2 y una hoja de eventos en godot sería mucho más flexible y poderosa que la de construct2. No tendrá ninguno de los inconvenientes que tiene su motor.

El enfoque de Construct para emparejar objetos es horrible, entre otras cosas, pero eso no tiene nada que ver con el diseño de la hoja de eventos.

El script visual actual que tenemos requiere demasiados clics, nodos y verbosidad para hacer las cosas más simples.

Ese no es un defecto inherente de VS, sino de su implementación actualmente limitada. Esto debe arreglarse, no usarse como argumento para implementar otro método de secuencias de comandos visuales junto a él. De lo contrario, el VS actual debe desecharse.

Además, discutir JIT para GDscript está fuera de tema. El mérito de una característica solo se puede medir por:

• su utilidad frente a otras características similares que pueden ser útiles para el mismo caso de uso
• su utilidad frente a la complejidad que trae a la mesa, la deuda técnica adicional y la carga de mantenimiento para Godot

Entonces, si esto debe hacerse o no, no tiene nada que ver con si implementamos o no JIT para GDScript. De lo contrario, deberíamos cerrar el 99% de todas las solicitudes de funciones hasta que se solucionen todos los errores importantes, es decir, para siempre. Esos son incluso más importantes que JIT para GDScript.

Sin embargo,

Dicho esto, @blurymind no puedo estar en desacuerdo con nada de lo que has dicho porque son puntos realmente buenos. ¿Tener hojas de eventos en Godot _sería una buena característica_? claro, pero ¿es algo que sucederá en la realidad pronto? no estoy realmente seguro. (solo un ávido usuario desde 2014, y esta es solo mi opinión)

Habiendo usado Action Game Maker y la hoja de eventos de Game Maker anteriormente, estoy de acuerdo en que es más fácil de usar y comprender que VisualScript (se lee de arriba a abajo, sin seguir las líneas), no ocupa tanto espacio en la pantalla y puede implementar finito máquina de estado más fácilmente (al filtrar qué eventos se pueden activar después de que finaliza un evento).

Sería una muy buena adición. Probablemente no lo use yo mismo, ya que GDScript es suficiente para mí, pero puedo imaginarme usándolo bien si GDScript no es una opción (que probablemente estén experimentando los principiantes y los no programadores).

Bueno, soy usuario de Godot desde hace aproximadamente un año. Me encanta GDScript y su sintaxis simple.
Pero he usado Construct por más de 8 años y puedo decir que nunca vi un Visual Script más fácil que Event Sheets. No me gusta Blueprint y usé algunos otros estilos de VS Blue Prints, como blender y Unity, y no No entiendo cómo la gente puede decir que Blue Print es más fácil que Event Sheets. Tal vez sea porque los artistas están acostumbrados a usar nodos para configurar sombreadores y gráficos, están acostumbrados a esta estética. Pero apuesto a que si pones un sistema de hoja de eventos en un motor como Unreal, la gente dejará Blueprints.

Trabajo en una escuela que enseña lógica de programación a niños y adolescentes. Para los niños, usamos Construct 2 porque les resulta dolorosamente fácil crear algo con Hojas de eventos. Para los adolescentes usamos GDScript y obtuvimos buenos resultados con él. Cuando salió Godot 3.0, estudiamos la idea de eliminar Construct 2 para usar Godot VS, pero abandonamos la idea porque ahora VS es más difícil que GDScript, muy complicado de entender y usar. Si Godot tuviera algo como Event Sheet, haríamos nuestro curso totalmente basado en Godot, porque tendemos a favorecer las soluciones de código abierto en la escuela.

Otro beneficio que creo que traería Event Sheets, aumentaría la base de usuarios de Godot, ya que en GDC vimos estudios medianos a grandes que prefieren Godot, pero los pequeños prefieren Unity y otras soluciones. Creo que los usuarios de Construct, Fusion y Game Maker comenzarían a migrar a Godot.

Bueno, como profesor, veo un gran valor en las Hojas de eventos, porque es muy fácil de entender y cuando los estudiantes pasan a GDscript, ya desarrollaron un pensamiento lógico y la estructura de las Hojas de eventos se parece más a un código que a Blue Prints.

De todos modos, me encanta lo que está haciendo Godot y me encanta GDscript, solo quería compartir mi experiencia, ya que uso tanto la hoja de eventos como GDscript para enseñar. Mantenga el gran trabajo!

Cuando salió Godot 3.0, estudiamos la idea de eliminar Construct 2 para usar Godot VS, pero abandonamos la idea porque ahora VS es más difícil que GDScript, muy complicado de entender y usar.

Esa es una retroalimentación bastante interesante. :)
El hecho es que las hojas de eventos, en la forma de Construct2, tienen un nivel mucho menos bajo que VS o GDscript. De hecho, pueden ayudar a los niños a iniciarse en la programación de juegos, pero no es el objetivo de Godot. Creo que dicho sistema no debe enviarse como integrado, sino que debe estar disponible a través de un complemento. Supongo que este comentario de reduz expresa esto también.

@DrZanuff, gracias por mencionar este punto realmente importante: el canal de YouTube kidscancode y similar : las hojas de eventos son excelentes para un entorno escolar y una gran transición a algo como gdscript. Los planos no son desafortunadamente

Tal vez Godot pueda abordar esto de la manera en que lo hace el creador de juegos: su código visual de arrastrar y soltar se traduce directamente en código gml que incluso se puede previsualizar en tiempo real. De esa manera, los no programadores pueden aprender gml mientras usan el sistema de secuencias de comandos visuales del motor: es la estrategia exacta que yoyo games emplea para que los no programadores se introduzcan gradualmente en gml.
https://docs2.yoyogames.com/source/_build/3_scripting/1_drag_and_drop_overview/ Changing_dnd.html

Tanto cuando usan gml para expresiones como cuando obtienen una vista previa de lo que está haciendo su programación visual

Incluso como un complemento, sigo pensando que los objetos de la hoja de eventos de Godot al final deberían traducirse a gdscript. La hoja de eventos puede ser una herramienta para enseñar a los no codificadores cómo usar gdscript, brindándoles una interfaz sencilla que aún permite el uso de gdscript para expresiones y, al final, genera y muestra una vista previa de gdscript de todos modos.

La API de Godot tiene un método para generar archivos gdscript y adjuntarlos a los nodos. Por lo tanto, una hoja de eventos puede traducirse a gdscript cuando se ejecuta el juego, o incluso mientras se edita la hoja de eventos, como lo hace el creador del juego.

La ayuda de aprendizaje adicional que emplean tanto clickteam fusion como construct2 es una lista de menú basada en clics de métodos/miembros de nodos incorporados

A medida que el alumno hace clic en cualquiera de los elementos de la lista, se agrega la sintaxis adecuada al campo de entrada. Cuando empiezan a aprender hacen clic, pero a medida que hacen clic aprenden y memorizan la sintaxis y los métodos. Luego en lugar de hacer clic, están escribiendo con autocompletado y sin darse cuenta han aprendido la api.

En ese sentido, la implementación de Godot de un sistema de hoja de eventos puede tener como objetivo principal introducir a los no programadores en gdscript y conceptos básicos de programación sin aturdirlos con ninguna sintaxis, luego colocará a Godot en más escuelas que enseñan programación a preadolescentes. A medida que avancen, aprenderán gdscript y la api de godot, en lugar de construct2 o game maker.

Creo que no me expliqué bien... :(

Cuando digo líneas, me refiero al scripting visual, a las líneas que conectan los nodos

El sistema de eventos de construcción y fusión es mucho más intuitivo, fácil y rápido para crear un juego, que el scripting visual de Godot.

Sería bueno explorar una alternativa de este tipo.

Las funciones de nivel superior de @groud en los planos de secuencias de comandos visuales de Godot también se pueden escribir como complementos, pero los planos seguirán teniendo la complejidad de diseño adicional que discutimos.
Se necesitaría mucho menos trabajo para crear y mantener funciones de nivel superior para el sistema de blueprint actual, que escribir la funcionalidad de hoja de eventos de funciones de nivel superior Y un sistema base de hoja de eventos completamente nuevo desde cero como un complemento.

Si tuviéramos una implementación de bajo nivel de un sistema de hoja de eventos, sería mucho más fácil crear y mantener acciones/condiciones de nivel superior para él.
Supongo que incluso como un complemento, primero haría el complemento base de la hoja de eventos con solo un acceso de bajo nivel y una interfaz, que sigue la arquitectura de Godot sin inflarla con ningún método nuevo. Luego, se pueden escribir complementos opcionales separados para cosas de nivel superior en la parte superior de otros complementos.

El repositorio de activos podría tener una sección especial para complementos de secuencias de comandos visuales

Enseño programación para niños de entre 7 y 17 años. Actualmente, los estudiantes más jóvenes están usando Cosntruct y los mayores están usando Godot, pero si todos mis estudiantes pudieran usar Godot, estaría realmente agradecido de que los niños usen Godot desde el comienzo de su viaje en este mundo de desarrolladores de juegos.

No es sólo el sistema de hoja de eventos. También es cómo funcionan los complementos/comportamientos/familias, los UID y las propiedades de los objetos.

Por ejemplo, en C2, en un sprite de objeto, puedo tener todo el arte del juego, incluidas estáticas/animaciones de decoración, jugador, enemigos, etc., todo con sus colisiones, etc., y colocarlo en el diseño seleccionando qué marco al inicio. y usando una variable de instancia en el objeto llamada "type=" para saber si es un enemigo, jugador, objeto, rompible, etc... para en eventos establecer su comportamiento. También para cada sprite tienes un programa básico de pintura, propiedades de animador, etc...

En Godot probé el ejemplo de Pong en secuencias de comandos visuales y cuando vi que usa un sprite para el jugador y otro objeto sprite para la colisión, y dije, ¿¡QUÉ!? . También C2 tiene una "forma de polígono adivinado" que con un clic hace que la colisión de tu sprite use 8 puntos. Después de eso, puede agregar más puntos y ajustar para ser más preciso o usar algunos complementos o trucos para obtener precisión de píxeles.

Quiero decir, si no aplica el sistema de hoja de eventos como en C2, pero no sigue la misma filosofía para que todo sea fácil de usar, será una pérdida de tiempo porque no funcionará. Y bueno, hacer todo esto en el motor Godot real puede ser un trabajo realmente loco.

En caso de seguir adelante, tal vez deberían pedir/contratar a los grandes de C2 como RexRainbow, R0j0hound, etc... que saben cuáles son las mejores y las peores cosas y hacer un sistema de hojas de eventos realmente bueno sin todos los errores de C2/C3. . Pero como dije, eso significará mucho trabajo y dinero.

@matriax No creo que tengas razón aquí.
Godot tiene una arquitectura mucho más flexible y directa que Construct2.
Como se señaló, el emparejamiento de objetos es un dolor en la construcción, entre muchas otras cosas: por ejemplo, podríamos tener un orden de eventos más claro que el de la construcción. Podemos adjuntar hojas de eventos a cualquier nodo, lo que permite una mejor organización que construir'2.
Para tipos/familias, en Godot tenemos "grupos", la implementación de grupos de Godot es en realidad mejor que la de construcción.
Para adjuntar comportamientos a objetos: solo puede adjuntar nodos secundarios y usarlos como el comportamiento del nodo principal raíz que contiene la hoja de eventos adjunta. Esto es en realidad mejor que Construir de nuevo.
En Godot, tienes que hacer que un nodo de forma de colisión sea un hijo del nodo que tiene la colisión. No es ciencia espacial y en realidad es mejor para enseñar a los niños sobre programación.

Algunas de las cosas que está solicitando deben hacerse como complementos y ya se han hecho como complementos (suponga que la forma del polígono, por ejemplo)

Implementar un sistema de hojas de eventos en Godot que se ajuste a la arquitectura actual de Godot resultaría en un mejor sistema de hojas de eventos/plataforma de aprendizaje que la construcción, porque Godot permite mucha más flexibilidad en los estilos de codificación y tiene una mejor arquitectura. Expandir ese sistema con una funcionalidad de nivel superior a través de complementos lo haría tan fácil de usar como el de construct2.

Hacer que Godot sea tan fácil de usar como Construct 2 necesitaría ser un esfuerzo conjunto, tanto de los desarrolladores principales de Godot como de su comunidad. La comunidad necesitaría crear la funcionalidad de nivel superior a través de complementos de hojas de eventos. Sin embargo, no intentes hacer que Godot sea exactamente igual que construct2. Es en muchos sentidos mejor.

@blurymind No estoy hablando de aplicar la misma arquitectura que en C2, eso no tiene sentido, tampoco sé todo lo que Godot ya tiene, como los grupos, los nodos secundarios, etc., dijiste.

Lo que quiero decir es que agregar un sistema de hoja de eventos en Godot sin seguir la misma filosofía para lograr todo el trabajo de una manera fácil como en C2/C3 será una pérdida de tiempo. Como dije, tener un objeto para sprites/colisiones o todo el arte del juego en lugar de un objeto para cada cosa.

Tal vez deberían preguntarle a la comunidad cuántas personas están usando el script visual real y cuántas personas preferirán el sistema de hojas de eventos para luego tomar una decisión.

@matriax necesitas aprender Godot antes de hacer tales afirmaciones :)

La propuesta aquí es para una hoja de eventos, no para una copia completa del motor de construct2.

Conociendo ambos motores, creo firmemente que una hoja de eventos se puede hacer de una manera centrada en Godot y haría que Godot sea una herramienta tan buena, si no mejor, para enseñar a los niños más pequeños sobre programación.

En ese sentido, una entidad de hoja de eventos sería igual a un archivo de script, similar a lo que hace DND en el creador de juegos, no es necesario cambiar nada en el motor o cómo funciona. Si desea otras características de construct2, puede hacer algunos complementos

Incluso como una implementación adicional, una hoja de eventos en Godot no debería hacer nada más que simplemente crear otra interfaz para generar archivos gdscript.

@blurymind Y de nuevo con lo mismo, ok, lo olvidé.

@matriax la retroalimentación es una buena idea. Tienes razón en ese punto.
Sería bueno preguntarle a un grupo objetivo de personas, no a cualquiera en Internet. Un grupo objetivo podría ser estudiantes y profesores jóvenes, que en realidad serían el objetivo perfecto para un sistema de hojas de eventos.
los maestros sabrán muy bien con qué luchan sus alumnos y, al mismo tiempo, conocerán a Godot y Construct. Los estudiantes y los no codificadores podrían dar buenos comentarios.

Si solo pregunta en el rastreador de Godot aquí, obtendrá la mayoría de los programadores experimentados o intermedios, personas que ya conocen y aman gdscript, la API del motor e incluso c ++
Reaccionarán de manera protectora, como puede ver al comienzo de la publicación, pensando que lo que está proponiendo no es lo que ellos necesitan y el motor necesita, naturalmente porque ya sabemos cómo escribir código en gdscript y vemos objetivos más importantes para el motor que este. Es cierto que hay metas más importantes.
Si tiene suerte, algunos de ellos habrían comenzado con la fusión construct/game maker/clickteam antes de llegar a godot, y sabrán cuál es su valor para las personas que aún no conocen ningún lenguaje de programación.

Alguien señaló que a los artistas 3D les gustan los planos, porque ya saben cómo hacer shaders. Ese es un muy buen punto: un artista 3D no es un programador, pero sigue siendo una persona técnica que ha aprendido los conceptos de un sistema de gráficos de nodos.

Volviendo al valor de esto, ¿no sería maravilloso si Godot, tal vez algún día en el futuro, se convirtiera en el primer motor de más niños?
¿Por qué no intentar reemplazar a Construct en las escuelas? :) Los desarrolladores de Scirra lo están teniendo demasiado fácil en este momento. Mira como se jactan de colaborar con colegios
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=marketing&utm_source=sendgrid&utm_medium=correo electrónico

En términos de probar la idea como un complemento, hice una interfaz gráfica de usuario de prueba de concepto WIP. No hace nada en este momento, es solo averiguar cómo podría funcionar la interfaz y vincularse con la arquitectura de Godot. No estoy seguro de cómo arrastrar para mezclar elementos dentro de las celdas y sangrar todavía

Sería genial si el nodo richtextlabel en Godot pudiera usar íconos internos del editor de Godot

Haré otra maqueta para un editor de condiciones/acciones cuando tenga tiempo :)
El editor de acciones/condiciones sería la herramienta para editar celdas/bloques lógicos. Estoy pensando en algo similar al enfoque de Construct2 con el editor de código interno de Godot como editor de expresiones.
Tal vez se podrían agregar algunas ayudas de ayuda más adelante, como las de construct2 o fusion.

Una vez que se crea una interfaz, el resto es simplemente guardar/almacenar los datos dentro de la escena y poder generar un gdscript limpio, pero es posible que me esté perdiendo algo.

@blurymind Genial , me gustó el concepto.
Tal vez los botones para agregar acciones y condiciones deberían estar sin el botón de fondo, como en la construcción 2

Y creo que sería bueno una línea para separar la condición de la acción.

Me gusta cómo está quedando esto.

Esa es una maqueta realmente ordenada. Al principio no entendí muy bien a qué te referías. Ahora está muy claro... ¿una especie de paso intermedio entre la programación y el tipo de secuencias de comandos visuales que ya tenemos?

@DrZanuff Gracias por los comentarios
@Zireael07 Gracias :)
Sí, exactamente: una herramienta que nos ayudaría a reemplazar Construct2 por completo con Godot en las escuelas que usan ambos motores para enseñar programación.
Debajo, solo hay una interfaz visual para generar archivos gdscript, similar a cómo se usa DnD en Game Maker 2. No estoy solicitando ningún cambio en la excelente arquitectura de Godot.
Las hojas de eventos pueden ser una opción de secuencias de comandos visuales en Godot que es fácil de usar para los que no codifican (los planos no lo son) y los niños pequeños que aprenden conceptos de programación, facilitándolos en gdscript

Godot ya tiene muchos de los elementos para hacer que esto funcione por cierto, pero no puede ser exactamente igual que en Construct2. A la manera de Godot, será mejor de varias maneras si sucede. La hoja de eventos de Construct2 permite algunas prácticas de organización de código realmente malas y tiene algunas limitaciones/peculiaridades terribles. De hecho, podemos hacer una hoja de eventos mejor que la de ellos que sea tan fácil de usar y enseñe mejor la programación, sin peculiaridades.

Tal como lo veo, gran parte del trabajo consiste en crear la interfaz para editar hojas de eventos. Tengo algunas ideas más sobre cómo mejorar esto aprovechando las ventajas de Godot, pero me llevará algún tiempo desarrollar la prueba de concepto. Eso lo explica. A veces una imagen vale más que las palabras. Un complemento - más que una imagen

Me encanta tu trabajo en esto. ¿Estaría dispuesto a que esté disponible en un repositorio mientras trabaja en él (si lo hace)? Me gustaría echarle un vistazo y hurgar en él y jugar.

@mhilbrunner Por supuesto que puedes, y de hecho me encantará si lo hurgas. Solo necesita algo de tiempo para hacerlo más presentable. :)

Estoy en el proceso de integrar la interfaz gráfica de usuario en el editor de Godot como un complemento de gdscript; aún no es lo suficientemente interactivo :)

Lo publicaré en github cuando tenga la interfaz gráfica de usuario básica funcionando de forma interactiva para comunicar las ideas de diseño :) Hoy obtuve la interfaz gráfica de usuario de la hoja de eventos para cargarla como una pestaña, inspirándome en el complemento de sketchfab:

¿Quizás se debería acceder a la hoja de eventos desde otro lugar?

Publicaré más capturas de pantalla actualizadas y eventualmente un enlace a github: actualicé mi primera publicación con algunas notas de planificación y enlaces a demostraciones en línea de otros motores de hojas de eventos.

• ¿Conocen una manera fácil de mostrar los íconos del nodo Godot dentro del nodo de etiqueta de texto enriquecido a través de bbcode?
  En mi maqueta anterior, usé las etiquetas [img], pero ese es un enfoque bastante pobre, ya que requerirá que descargue todos los íconos de nodo que usa el editor Godot y los almacene con el complemento.

• También estoy luchando por descubrir cómo registrar un nuevo recurso de tipo de script de hoja de eventos a través de la API del complemento

@blurymind muy bien! Ahora es más legible. Necesitamos pensar cómo se mostrará la lista de acciones al usuario.

Una cosa que me gustó del antiguo Construct Classic fue la opción de editar los valores de la hoja de eventos sin abrir la acción o la condición, pero haciendo doble clic sobre el valor para editarlo:

Si alguien quiere agregar esto (por su cuenta a través de un complemento, complemento, gdnative, etc.), entonces, no hay daño, no hay falta. De lo contrario, estoy de acuerdo en que las secuencias de comandos visuales se pueden mejorar haciendo que esto sea superfluo. GDscript es fácil, muy fácil. Y probablemente más útil para enseñar a los niños que algunas secuencias de comandos visuales (incluso basadas en planos). Si alguien necesita construir, entonces anímelos a seguir usando la construcción. Godot no necesita emular todos los demás sistemas en su núcleo. Deje que el software mantenga su enfoque y no se convierta en un "aprendiz de todo, maestro de nada" debido al enfoque difuso.

@spyres depende de si @reduz y el equipo de godot quieren apuntar a estudiantes más jóvenes en las escuelas.
Personalmente, creo que podemos reemplazar completamente la construcción en las escuelas con godot.
El sistema de planos actual no va a funcionar para eso. Es más complicado de usar que gdscript y, como se mencionó anteriormente, no es la mejor manera de presentarle a alguien los paradigmas de programación, porque tiene su propio conjunto de reglas.
El objetivo de esto no es reemplazar gdscript o el sistema blueprint actual, sino todo lo contrario, brindarles a los niños una forma de aprender gdscript ayudándolos. Así es como yoyo games usa su sistema de secuencias de comandos visuales DnD para introducir gradualmente a los no programadores a Gml por cierto.
No creo que haya ningún daño en tener un sistema de secuencias de comandos visuales que sea más accesible para los que no son programadores y que esté mejor diseñado para hacer la transición a gdscript. ¿Por qué?

Estoy tratando de hacerlo como un complemento, pero me encuentro con algunas limitaciones en términos de falta de documentación o API. Quiero registrar un nuevo tipo de recurso de secuencias de comandos y quiero inyectar mi editor de hojas de eventos dentro de la pestaña de secuencias de comandos, para editar archivos myscript.es.
¿Alguien sabe cómo se puede hacer esto, o tiene un ejemplo de cómo se hace?
En mi opinión, tener su propia pestaña es feo y no seguir el diseño original del editor. Quiero que mi complemento se integre de una manera que sea perfecta con el diseño de Godot.

@DrZanuff Godot tiene una forma de enumerar todos los métodos que existen en un nodo, pero todavía no estoy seguro de cómo filtrarlos a acciones o condiciones. Podría tener que encontrar una forma más centrada en Godot para hacer eso. Sigo explorándolo y estoy abierto a ideas :)

En cualquier caso, es posible que nunca tengamos un complemento completamente funcional. Esto es solo para explorar la idea de cómo podría hacerse de una manera centrada en Godot aquí, al menos por ahora.

La suposición de que la secuencia de comandos visual no puede (o no se mejorará) en gran medida o que los niños más pequeños no podrán usarla, o convertirse en gdscript desde la construcción) parece un poco tonta. Especialmente porque el guión visual es bastante nuevo.

Si la solución para niños muy pequeños _(que nunca he visto que los desarrolladores mencionen como un grupo demográfico primario para Godot)_ es tan grande, permítales usar construcción o alguna otra solución enfocada para niños y luego pasar a una programación real a través de GDscript cuando están listos.

Si desea crearlo como un complemento y respaldar ese complemento, entonces intimide por usted. Pero como algo duplicado, inflando el núcleo y (probablemente) desperdiciando tiempo de desarrollo oficial limitado con soporte futuro, integración, etc., no, gracias. _

@spyres, ¿ eres tú mismo un desarrollador? ¿O un maestro? ¿Ha utilizado realmente el guión visual de Godot en alguno de sus propios proyectos? Si es así, ¿cómo se puede mejorar para que sea una mejor herramienta para enseñar a la gente sobre programación?

@blurymind Creo que tu idea es buena. Además, parece que ya tienes una visión bastante sólida.

Pero creo que "reemplazar la construcción en las escuelas con Godot" no es una razón válida para tener esta característica. No recuerdo que Godot tenga la visión de reemplazar otro motor como Unity, Unreal, etc. Godot no está tratando de aplastar otras herramientas. Si el motivo es aumentar la productividad, estoy de acuerdo.

También estoy de acuerdo con @spyres en que Godot no tiene que apuntar al segmento educativo. Si Godot no es adecuado para ser una herramienta de enseñanza de programación (ni siquiera de desarrollo de juegos), que así sea. Nunca tuvo la intención de estar en primer lugar. Pero si alguien puede de alguna manera usar/transformar a Godot para que sea una herramienta de enseñanza de programación, no tengo ningún problema con eso.

Aún así, creo que esta hoja de eventos es una idea interesante para ver.

@blurymind Creo que te estás olvidando de que Godot no es una herramienta de enseñanza, Godot es un motor de juego. Si desea implementar algo como construir como un módulo externo, está bien y depende de usted, pero no intente transformar algo diseñado para el desarrollo de juegos en un juguete para niños. ¿Por qué tratar de transformar a Godot en una construcción si lo que realmente quieres es una construcción? ¿Por qué no usarlo en lugar de Godot?

@zaniar @ni-code Tienes razón. Es cierto que, personalmente, estoy más interesado en crear una herramienta de secuencias de comandos visuales que sea más eficiente y clara que nuestro enfoque de modelo actual, una que sea simplemente más agradable de usar. No me gusta Construct2, por lo que no es cierto, quiero convertir a Godot en él. Como mencioné anteriormente, encuentro que su diseño y peculiaridades son bastante malas. Es por eso que es tan frustrante para mí que los únicos lugares para encontrar hojas de eventos no sean tan buenos como Godot.

Honestamente, creo que incluso si se mejoran los planos, nunca serán tan claros y rápidos de construir como una hoja de eventos; en ese sentido, las hojas de eventos son una gran herramienta para la creación rápida de prototipos que a menudo se subestima. Pero los títulos creados por Clickteam fusion deberían hablar por sí mismos. Algunos pueden verlo como un juguete, pero para mí es divertido construir la lógica del juego de esta manera :)

Como alguien que ha usado tanto construct2 como Fusion, me encanta el enfoque de la hoja de eventos y veo en la API de Godot un hermoso candidato para un sistema de hojas de eventos, sin las fallas de los motores que lo inspiran.
El diseño de anidamiento de nodos de Godot funcionará muy bien con eso, combinado con la claridad de gdscript para las expresiones.
No espero que se implemente en Godot, pero continuaré compartiendo el progreso del complemento aquí, con la esperanza de obtener comentarios útiles y ayuda con la API. Algunos de los desarrolladores aquí han usado Construct2 y conocen muy bien a Godot, por lo que pueden surgir buenas ideas de la discusión.

De hecho, tengo una idea para el sistema de hoja de eventos que nos dará una ligera ventaja sobre el uso de gdscript, incluso para usuarios experimentados. Se supone que debe usarse con gdscript, no en lugar de gdscript, no olvide eso

Espero con ansias las inevitables mejoras de Visual Scripting que (porque están totalmente integradas/soportadas) serán más útiles (y probablemente más populares) que cualquier complemento "construct-lite" centrado en los niños.

@spyres Por favor, mantén el tono civilizado. No es necesario que le digas a los demás que sus suposiciones son " tontas " o que el complemento potencial en el que están invirtiendo (¡gratis!) va a ser una cosa "

Claro, la gente es libre de pasar su tiempo (inútil, creo que podría ser en última instancia) como lo deseen, por muy poco propicio que sea para el diseño central de Godot.

En interés de la civilidad (¡aunque "centrado en los niños " es incómodas , no enfocadas en el núcleo demográfico de Godot, algo que se espera no desperdicie el tiempo del desarrollador central , etc

¿Por qué molestarse en recrear la construcción dentro de Godot _cuando el motor de construcción real ya proporciona esa funcionalidad de manera robusta?_

¿El grupo demográfico de niños de 7 años realmente está pidiendo a gritos ese tipo de duplicación?

@mhilbrunner respondiendo su publicación se siente como responderle a un troll de 7 años :D
Eliminó la mayoría de mis publicaciones aquí, todas las negativas en realidad son suyas.
Parece que no tiene sentido discutir con él, porque en realidad no responde a las preguntas; le hice algunas preguntas válidas que podrían ayudarme a obtener algunos comentarios. Lo que obtuve a cambio es más de lo mismo

¿Github tiene una forma de bloquear a las personas para que no publiquen si son abusivas?

Guau, aunque ciertamente cuestioné algunas ideas, _nunca_ en realidad he _Eso_ es bastante abusivo, diría yo.

¿Qué proporcionaría la duplicación de la funcionalidad de la construcción dentro de Godot que no está bien proporcionada por er ... Construir.

¿Hay una ventaja legítima en duplicar el conjunto de características de Construct (probablemente de una manera menor) en Godot simplemente para atraer a los niños de 7 años?

¿Por qué no usarías simplemente construir? ¿Su configuración (que algunos parecen dispuestos a duplicar) es realmente tan deficiente?

¿Hay alguna razón legítima para suponer que los niños no pueden pasar a gdscript o secuencias de comandos visuales una vez que superan la construcción?

@spyres está utilizando términos generalmente ofensivos para describir a las personas que usan hojas de eventos y hojas de eventos.
No son "chiquillos" y el sistema no es "pantolo". Ten un poco de respeto por esas comunidades por el amor de Dios. ¿De dónde viene esta actitud elitista?

Construct2 tiene muchos programadores de javascript muy experimentados, lo que debería haber sido evidente para usted si se ha tomado la molestia de leer lo que escribo y seguir los enlaces que proporcioné. Algunos de los complementos que han creado lo integran con motores 3D como babylon y three.js incluso, así que sí, los desarrolladores experimentados también disfrutan usando hojas de eventos y hacen juegos con eso.

Los juegos creados por Clickteam Fusion superan en gran medida a los juegos creados por Godot en Steam, Kickstarter e incluso en las tiendas de aplicaciones en términos de número e ingresos que generan. Es un motor completamente basado en hojas de eventos, utilizado por personas de 10 a 80 años. Es una mezcla de todas las edades. Algunos de los usuarios son cineastas, otros son artistas, personas con trabajo que gastan dinero en licencias, exportadores, etc. Diablos, gané más dinero vendiendo cosas en su tienda de activos que cualquier otra cosa que tenga que ver con Godot hasta ahora.
Aquí algunos ejemplos - Alonso Martin, cineasta decide hacer un juego:
https://www.kickstarter.com/projects/alonsomartin/heart-forth-alicia
Un grupo de niños de 7 años hacen un juego.
https://www.kickstarter.com/projects/galaxytrail/freedom-planet-high-speed-platform-game

echa un vistazo aquí
http://indiegames.clickteam.com/
Esos niños de siete años si que saben hacer juegos y ganar dinero eh
https://thinkgaming.com/app-sales-data/publisher/3107/scott-cawthon/

Mi punto de vista de vender esto como una mejor herramienta para enseñar programación no debería ser una razón para etiquetarlo así. Con una demografía más amplia de usuarios, terminas con más personas creando juegos con el motor. ¿No debería ser obvio? ¿Por qué esto no es obvio? :D

¿Cuántas veces necesita que le repita que no estoy pidiendo una copia al carbón de Construct2? Es como si repitieras el mismo mensaje sin leer nada. Lo que propongo es una hoja de eventos centrada en Godot, no una copia de la que está en construct2

Ahora, ¿cómo me va a motivar la lectura de sus publicaciones sobre que el sistema es "inestable" para hacer un complemento gratuito para Godot? Piensa un poco en esto

¡Guau! A pesar de los cambios de portería...

Déjame aclarar.

Construct es bastante exitoso en lo que hace. Así que la necesidad (?!) de injertar/duplicar su conjunto de características (en su totalidad o en parte) en un motor completamente diferente (sin ningún beneficio perceptible) se me escapa.

Las preguntas relativas a los beneficios reales siguen siendo las mismas, aunque algunos podrían (inexplicablemente) encontrarlas "ofensivas".

¿La sugerencia de que un complemento injertado en un motor completamente diferente será de alguna manera mejor que usar la construcción? ¿De que tener algo incorporado (incluso a través de un complemento) es algo que esperaríamos que mucha gente usara en lugar de la solución robusta (es decir, la construcción)? Dudo que.

Pero bueno, ¿por qué parar ahí? Existen excelentes herramientas (más allá de la construcción) para enseñar programación a los niños (por ejemplo, Scratch , Styncl , code.org , etc.) ¿Por qué no incorporarlas también en Godot?

O tal vez no... ;-)

¿Hay alguien que haya usado el scripting visual de Godot y le parece tan bueno que solo está usando el scripting visual de Godot?

@Zonacas No creo que Visual Scripting de Godot esté lo suficientemente maduro para eso todavía, pero puedo estar equivocado. Tenga en cuenta que VS solo se ha lanzado durante dos meses en este momento. :)

@Zonacas intente mirar el canal VS en el servidor de discordia, he visto a uno o 2 autoproclamados no programadores a los que les gustó (pero también está lleno de programadores que dicen que no es bueno para los no programadores).

Hola a todos, tengo una actualización de progreso en mi complemento de prueba de concepto.

Aquí hay un nuevo gif para ti:

Algunos antecedentes sobre lo que hace: básicamente, la hoja de eventos está hecha de celdas. Una celda puede ser para condiciones (captadores/expresiones) o acciones (establecedores que se pueden alimentar con captadores/expresiones).
En el lado de la GUI, la celda de eventos se crea a través de un nodo richtextlabel y un código bb que se genera a partir de gdscript. Cuando hace doble clic en él, la etiqueta de texto enriquecido se convierte en un nodo de cuadro de edición que contiene la expresión gdscript real.

Entonces, una celda de hoja de eventos tiene 2 modos:

• modo de edición: nodo de edición de texto en el que se puede escribir con gdscript.
  La única diferencia es que el usuario no necesita escribir If/else/while; eso es sensible al contexto del contenedor principal, como se ve en la captura de pantalla. Cada línea es una nueva condición, por lo que si el usuario no ha comenzado la línea con "o" o algo más, el analizador automáticamente sabe que una nueva línea tiene el pretexto "y".

Cuando se hace clic, cambia al modo de visualización.

• modo de vista - etiqueta de texto enriquecido: al cambiar al modo de vista, se analiza un bbCode del gdscript que está en modo de edición y se presenta a través de una etiqueta de texto enriquecido interactiva. Además de ser interactivo y fácil de cambiar, el objetivo es presentar el código gdscript de una manera más clara. Esto significa mostrar solo el nombre y el ícono del nodo (no la ruta completa) y deshacerse de algunas palabras, cuando sea obvio (como get_ y set_). Dado que cada parte en la que se puede hacer clic es en realidad una etiqueta de URL, al pasar el cursor sobre el nombre de un nodo, por ejemplo, el usuario puede obtener información, como la ruta completa del nodo.

Acerca del menú Agregar nueva condición/acción:
Esto es lo que crea una nueva línea de código gdscript para una condición o una acción. Lo bueno de esto es que le permite navegar fácilmente por todos los nodos dentro de una escena y sus métodos; funciona de manera inversa a cómo funciona el autocompletado en el editor de gdscript. Muestra todos los nodos y todos sus métodos setter, getter o ambos. Luego puede limitarse a lo que desea a través de un filtro.
Si se llama desde una celda de condición, este menú muestra solo captadores, si se llama desde una celda de acciones, muestra los métodos setter y getter.

Qué sigue para que esto funcione:

• Necesito encontrar una forma de arrastrar celdas para poder cambiar fácilmente el orden de los eventos.
• También copiar y pegar en modo de vista previa.
• A continuación, tengo que crear un editor de expresiones que aparece cuando se hace clic en un tipo específico de URL de celda en modo de vista previa
• descubra cómo lidiar con los elementos de marcador de posición. Pensé en poner comentarios, pero desafortunadamente Godot no admite comentarios en línea: https://github.com/godotengine/godot/pull/18258, así que podría tener que volver a la mesa de dibujo en ese

La idea se está convirtiendo en algo más que una simple herramienta de enseñanza. Creo que puedo ofrecer algunas funcionalidades útiles que ahorran tiempo a las personas que ya conocen y aman gdscript, pero me llevará más tiempo desarrollar esto hasta el punto en que pueda presentarles cómo hacerlo.

Gracias a todos por el apoyo

Una buena idea para un complemento. Pero mantener oficialmente dos sistemas de secuencias de comandos visuales sería una molestia y una pequeña ganancia.

XKCD: Estándares

No veo por qué esto no puede ser un complemento/complemento real en lugar de solo una prueba de concepto. No todo tiene que estar incluido con el motor por defecto. Quiero decir, ¿no es por eso que se desarrolló GDNative?

@Megalomaniak Eso es cierto y créanme cuando digo que si tuviera suficiente conocimiento sobre la API de Godot, reescribiría esto como un complemento gdnative. Pero incluso para llegar tan lejos tuve problemas y en realidad me faltan algunos elementos clave para convertir esto en una herramienta útil real. He planteado las preguntas aquí, pero hasta ahora nadie me ha dado ninguna respuesta o mostrado ejemplos:

• ¿Cómo registramos un nuevo tipo de recurso de secuencia de comandos en el editor Godot y permitimos que el usuario lo adjunte a cualquier nodo? Por el momento, el complemento está operando desde la raíz de la escena y es hacky.
• Entonces, ¿cómo hacemos para que Godot abra mi guia de hoja de eventos, tan integrada como el sistema de planos actual?
• ¿Cómo hacemos que el nodo editText actúe como el editor gdscript de godot? Habilite el coloreado de sintaxis y el autocompletado. Además, ¿cómo le damos un contexto personalizado?

Alguien con un nivel de conocimiento muy bajo de la API puede hacer esto. Ese tipo de cosas no está en la documentación, tampoco hay ejemplos existentes.
Tengo las ideas de diseño, pero aún no tengo la imagen completa para llevarlo a cabo.

Hasta ahora, solo puedo seguir impulsando los conceptos de diseño y aprender más sobre la API, pero no puedo garantizar firmemente que esto se pueda convertir en un complemento que realmente funcione completamente. A la gente parece gustarle mucho hasta ahora

Para cosas como esta, prefiero honrar los deseos de los desarrolladores:

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

Tengo una gran idea que mejorará a Godot.

Su idea seguramente será ignorada.

Hagamos esto porque hará que Godot sea mejor.
Hagamos esto en Godot porque otro motor de juego lo hace.
Eliminemos esto porque creo que no es necesario.
Eliminemos el desorden y la hinchazón y hagamos que Godot se vea mejor
Agreguemos un flujo de trabajo alternativo para las personas que lo prefieran

@spyres De hecho, estoy haciendo esto y busco el apoyo de otros usuarios de Godot en la API sobre cosas que no puedo encontrar en la documentación, tratando de hacer una contribución a Godot.
¿Qué estás haciendo aquí?

Eres la única persona que pasa el pulgar hacia abajo y repite las mismas cosas en cada publicación. Eso es muy parecido a lo que hace un troll, ¿no le parece? Está desviando la conversación de la discusión de las ideas de diseño.

@blurymind La "contribución" de un hombre es la distracción de otro hombre (o motor). Lamento que el concepto de opiniones diferentes (incluso las de los desarrolladores que se sintieron lo suficientemente importantes como para publicar como parte de los documentos oficiales) le parezca tan objetable.

Mucha suerte con tu complemento. :sonrisa:

@spyres pero ¿realmente has hecho algo? ¿Alguna vez has creado un complemento para Godot? ¿Usas Godot?

¿Por qué estás aquí? No estás tratando de contribuir a la discusión.

@blurymind Wow, ¿realmente te molestan tanto las diferentes opiniones? Que triste por ti.

@spyres todos aquí pueden ver su opinión: está

Para ser claros, apoyo totalmente a cualquier persona que use su tiempo sin importar si desea crear algo como esto como un complemento que puede ser ignorado pacíficamente por personas como yo que no encuentran valor en ello.

¿Como un flujo de trabajo alternativo realmente integrado en el núcleo de Godot? Uf, por favor, no. Estoy con la opinión de los desarrolladores sobre ese tipo de cosas.

@spyres sí, ya dijiste eso. Desplácese hacia arriba y léalo 5 veces más. Hay uno de ustedes .. pero tantas veces

@blurymind ¿ Y de alguna manera parece molestarte? Wow, opiniones alternativas y tal.

Supongo que _usted_ no ha repetido nada en absoluto, ¿correcto? (¿Quién eres? ¿Por qué estás aquí? ¡Justifícate dagnabbit!). :sonriendo:

Supongo que los comentarios de la documentación oficial escritos por los desarrolladores causaron un poco de indigestión, ¿eh?

sí, es súper conmovedor

@blurymind ¡ Gracias, abrazos por todas partes entonces!

Sinceramente, le deseo la mejor de las suertes al implementar esto a través de gdnative, momento en el cual estará allí para aquellos (muy pocos, sospecho) que querrán algo no oficial como eso.

Sin embargo, si no puede obtener la información, la asistencia que necesita para que esto suceda, tal vez sea el momento de volver a evaluar cuánto significa realmente para usted la disponibilidad de este lenguaje alternativo.

@spyres Por favor, deja de enviar spam. No necesito estos correos electrónicos y notificaciones. Expresó su opinión, lo cual está bien, pero no necesita seguir repitiéndola.

@mhilbrunner Si mis diferentes opiniones lo angustian, haga clic en mi avatar y luego seleccione "bloquear usuario". Cualquier dolor causado por leer mis comentarios cesará de inmediato. :smiley:

@spyres He notado en publicaciones anteriores que este complemento tiene como objetivo usar gdscript, no servir como un idioma alternativo. Y sí, parece que nadie está moderando este rastreador.

Bueno, cuanto antes termines, más felices seremos todos, ¿verdad? Estoy seguro de que será genial para algunas personas que realmente lo quieran, al igual que muchos otros complementos. Es difícil ver que esto te cause demasiado dolor indebido, así que por favor cuídate y no dejes que la falta de información/progreso te desanime. Estoy seguro de que si hay una oleada abrumadora de apoyo público, pronto tendrá toda la información/ayuda que necesita.

En palabras de un sabio, "No te preocupes, sé feliz". :sonriendo:

O "¡Todo es diversión y juegos hasta que alguien dispara su ojo!" (um, espera, no creo que esa fuera la cita que estaba buscando...)

GUAU. Voy a ser honesto, ¡esto es increíble!

Cuando leí tu publicación por primera vez, estuve de acuerdo, pero estaba un poco preocupado de que hubiera una gran discusión, pero cuando viniste y demostraste que no eras tan ladrador ni mordedor y en realidad comenzaste a desarrollar un complemento, quedé impresionado.

ME ENCANTA la interacción con GDScript, ya que era una característica importante en Gamemaker Studio (intercambiabilidad de secuencias de comandos visuales y adecuadas) que no era factible con un sistema basado en nodos.

Una vez que esto termine, ayudará a MUCHAS personas.

He sido usuario de Construct durante los últimos 6 años y definitivamente puedo decir que es la mejor manera de abordar el scripting visual más rápido y simple.

¡Excelente idea!

Esto va a ser muy útil. ¡No puedo esperar hasta que se estrene!

Brillante idea, colaborar con SnailOn.

1. El es un genio.
2. Él usa Godot alrededor de 3 años.
3. Usaba motores Clickteam desde TGF
4. candidato ideal.

@boruok He sido fanático del canal YT de Snailon desde los primeros días. 😄 Sus tutoriales me han ayudado a aprender fusión hace mucho tiempo. ¿Tiene una cuenta de github? Me encantaría recoger su mente en algunas cosas.

Por cierto, debo admitir que me inclino por un menú de clic más parecido a Fusion que el que usa Construct2 para decidir cómo llenar las celdas. El menú de ayuda presentado en la actualización 1 definitivamente está influenciado por el diseño de Clickteam. En este complemento, verá que no estoy creando una copia al carbón de ningún motor, sino tomando prestadas ideas que funcionarían mejor para un enfoque godotesco de una hoja de eventos. También hay un poco de creador de juegos, en la forma en que la secuencia de comandos visual puede cambiar sin problemas a la secuencia de comandos real, algo que los usuarios más avanzados podrían apreciar.

Gracias a todos por seguir el progreso de este complemento. La reacción inicial es abrumadoramente positiva.
Esto me motiva enormemente a seguir impulsando la idea, al mismo tiempo que trato de mantenerla simple y elegante.

Sin comentarios en línea, es difícil mantener el cambio fácil entre gdscript y visualscript, pero tengo algunas ideas sobre cómo superar eso y experimentar, así que estoy trabajando en ese cajero automático.
Necesito alguna forma de definir en gdscript un marcador de posición vacío donde se espera una expresión.
Dado que las expresiones devolverán un tipo de valor, pensé en usar el método de conversión de valor en Godot para marcar el marcador de posición:
float() ## this will turn into a bbcode item that expects an expression resulting in a float
Pero eso podría ser algo feo, ya que generará muchos métodos de conversión de tipos de variables innecesarios dentro del gdscript generado final.

Si Godot pudiera hacer comentarios en línea, podría analizarlos en el método que crea bbcode desde gdscript. Esto me permitiría alimentarlo con información adicional.

El mejor enfoque realmente es simplemente hacer que mi maldito método de analizador gdscript a bbcode sea más inteligente, que es lo que estoy tratando de hacer ahora

@blurymind no sé sobre git-account. por cierto, abrió videos de nuevo. Le he enviado unos cuantos pm a través de youtube y facebook. Esperemos que aparezca aquí.

@blurymind ¡Apoyo esto al 100%!
(Perdón de antemano por el inglés)

Si le damos una mirada adecuada a la página acerca de más allá de lo que se puede usar para trolear a la gente, esto es lo que podemos ver:

Los desarrolladores están interesados ​​en (por ejemplo):

Su experiencia en el uso del software y los problemas que tiene (esto nos importa mucho más que las ideas sobre cómo mejorarlo).
Las características que le gustaría ver implementadas porque las necesita para su proyecto.
Los conceptos que eran difíciles de entender para aprender el software.
Las partes de su flujo de trabajo que le gustaría ver optimizadas.
Partes donde te perdiste tutoriales claros o donde la documentación no estaba a la altura.

Teniendo esto en cuenta:

• Las secuencias de comandos visuales actuales solo se pueden usar si sabe cómo codificar de verdad. Y se vuelve realmente más desordenado que el código duro. ¿A quién está ayudando? Y los planos tampoco son tan útiles, a menos que tenga una formación técnica muy específica.

• Las hojas de eventos de nivel superior funcionan bien. Como se ve con el éxito de todas las aplicaciones mencionadas anteriormente. Si están bien hechos, son realmente más simples de entender y usar para los no programadores.

• ¿Por qué Godot atendería a los no programadores?
  Veo muchos usos para esto para muchas personas que trabajan en proyectos profesionales.
  En muchos proyectos, pequeños, medianos y grandes, una parte del equipo hará la codificación y otra hará lo suyo. Música y sonidos, visuales/animaciones/SFX/UI, diseño de juegos, escritores, etc...
  A veces son incluso equipos de un solo hombre, o personas ajenas a la industria, como este cineasta, que hacen un juego bastante exitoso.
  Algunas personas incluso quieren programar pero no codificar por muchas razones diferentes.
  Por ejemplo, problemas como tener dislexia hace que el código sea una pesadilla, pero la programación aún sería posible a través de un enfoque más visual como las hojas de eventos.
  La mayoría de las veces, estas personas tienen otras cosas que hacer además de codificar mientras producen cosas necesarias en el juego.
  Una hoja de eventos permitiría a un grafista, un diseñador de sonido o de juegos probar o implementar su trabajo muy fácilmente sin sumergirse en el código sin procesar.
  También permitiría una creación de prototipos súper rápida, para probar la prueba de concepto. Lance un montón de imágenes de archivo, haga clic aquí y allá un poco y puede verificar si su idea es divertida en este momento. Incluso los buenos codificadores y los grandes nombres/estudios usan las cosas más simples posibles para iterar al comienzo de un proyecto.
  Más comentarios y discusiones sobre todo eso aquí , y estoy totalmente de acuerdo con el OP.
  (Github no es el mejor lugar para recibir comentarios sobre esto, las personas que vienen aquí suelen estar muy metidas en la codificación y no pueden ver la necesidad, a pesar de que en realidad son una minoría).

• Conclusión: Brindar a las personas herramientas simples pero eficientes para interactuar con Godot sería una bendición en muchos niveles diferentes para una gran cantidad de adultos serios que trabajan en proyectos profesionales.
  (No solo los niños y las escuelas, incluso si también los ayudaría).

• Por cierto, hay otra herramienta llamada GDevelop que usa hojas de eventos si quieres ver más ejemplos. La interfaz anterior (versión 4) es bastante agradable, la actual (v 5) es un poco mala, sin embargo, la aplicación tiene algunas buenas ideas, pero algunas desventajas, y su dirección aún no está clara, pero puede darle algunas ideas, o al menos otro punto de comparación.

Enhorabuena por el trabajo ya realizado, por mantenerte positivo y motivado a pesar de ciertas reacciones, y por creer en tu idea. Yo también confirmo que, de hecho, sería de gran utilidad y solucionaría problemas importantes para mí.

@TheGoklayeh Gracias por las amables palabras de aliento. Sé exactamente a que te refieres. Como se señaló anteriormente aquí, los juegos indie exitosos creados por Clickteam Fusion superan en gran medida a los juegos indie exitosos creados por Godot.
Juegos que se publican, número de ventas en Steam y dispositivos móviles y títulos de Kickstarter que cumplen su objetivo.
Eso debería ser prueba suficiente de que los artistas y diseñadores profesionales lo usan, no solo los "niños".

Sobre el tema del nuevo IDE de Gdevelop, creo que es genial, pero no está completo. Un movimiento inteligente que hizo el desarrollador principal fue portar el ide a javascript, haciéndolo muy accesible para que los desarrolladores que no son de C ++ puedan contribuir. De hecho, he estado contribuyendo con pequeñas correcciones hasta ahora, solo para jugar y aprender. Este fin de semana intentaré hacer algunos pasos para integrar Piskel en él 😃 - si todo está bien, podría tener un editor de píxeles integrado.
El desarrollador principal fusionó recientemente una contribución de otro desarrollador: agregó soporte de dragonbones listo para usar. Si lo desea, pruebe la versión más reciente de github, no la demostración en línea. tiene los bienes
https://github.com/4ian/GD/releases

También sigo progresando lentamente en este complemento. Algunas cosas necesitan ser refactorizadas antes de que pueda seguir adelante.

Tal vez sería una buena idea obtener aquí a todos los usuarios de fusion y los usuarios de construct2 que también usan godot. Muéstrales este hilo y obtén sus comentarios sobre el diseño.
Snailon aún no se ha puesto en contacto conmigo, pero sí, es un programador muy experimentado en lo que respecta a las hojas de eventos. No sabía que él también es un usuario de Godot.

¡Esto se ve increíble! Gracias por desarrollar/impulsar esto, blurymind.
He hecho desarrollo de juegos durante aproximadamente 23 años, básicamente probé todo: todas las herramientas/motores populares de desarrollo de juegos, lenguajes de programación, etc. y prefiero las hojas de eventos al final del día porque me permite terminar los juegos. :)
Tenerlo en un enfoque enumerado de arriba hacia abajo dividido entre condiciones y acciones lo hace más ordenado y conciso que cualquier otro sistema. Como estoy más orientado a lo visual, tener una estructura rígida que es vertical/horizontal me permite fluir a través del programa/eventos con facilidad.
Otras secuencias de comandos visuales que requieren conexiones de espagueti son muy desordenadas y distraen: los detalles visuales están dispersos en una estética ruidosa que rompe la concentración de las personas con mentalidad visual (las mismas personas a las que se supone que están dirigidas las secuencias de comandos visuales).
Las hojas de eventos son las mejores para mí. Llevo 23 años usando de todo: blitzbasic, gamesfactory, unity, c++, javascript, etc., y estoy seguro de esto: ¡me encantan las hojas de eventos!

Solo quería intervenir, la edición de Blueprints / estilo de nodo es extremadamente difícil de organizar / evitar el "código Spaghetti". Para cualquiera que piense que es lo mismo que los eventos de estilo Clickteam/Construct/GDevelop, lo siento, pero son radicalmente diferentes, y las hojas de eventos son objetivamente mejores (los juegos se basan en reglas SI/ENTONCES en la naturaleza, y puede hacer una transición mucho más fácil de eventos a código, pero los eventos en general son más rápidos que codificar la lógica del juego).

Estoy seguro de que hay momentos en los que la edición basada en nodos es útil, pero la edición basada en eventos se convertiría rápidamente en la opción preferida si se incluyera en Godot Visual Scripting básico.

@bigelod @prominentdetail gracias por proporcionar más comentarios sobre lo que hace que las hojas de eventos sean tan buenas, no solo para aquellos que están aprendiendo a programar, sino también para los programadores más experimentados.

Creo que tienes toda la razón. Al igual que @prominentdetail , comencé con hojas de eventos en fusión y luego pasé por muchos motores diferentes. Python aprendido, luego gdscript, luego javascript. Aún así, las hojas de eventos me atraen como una forma preferida de crear prototipos de juegos: es esa claridad adicional que agregan a la lógica del juego.

También estoy notando tendencias en el cajero automático de la comunidad de motores de juegos de hojas de eventos, que Godot realmente podría aprovechar para expandir su base de usuarios:

• La comunidad de desarrolladores que usan hojas de eventos anhela un motor 3D que use hojas de eventos. Ambas comunidades de Clickteam Fusion intentaron integrar eso como un complemento (firefly) y Construct (se probaron numerosos complementos), pero esos complementos no proporcionaron ninguna capacidad de edición de escenas en 3D; editor de motor no diseñado para juegos en 3D. Solo puede construir una escena 3D con lógica de eventos en ellos, por lo que es difícil colocar objetos, colocar materiales, etc.
• Tanto a los programadores principiantes como a los experimentados todavía les gustan las hojas de eventos y las usan para crear prototipos, no solo para enseñar.
• Muchos equipos independientes han usado con éxito (y aún usan) hojas de eventos para crear títulos exitosos (kicktarter, Steam y otras plataformas), pero muy pocos son proyectos en 3D debido al primer punto.

Ahora hacer que esto funcione como un complemento en Godot es complicado, debido a algunas cosas en el motor a las que no estoy seguro de cómo acceder. La implementación actual que tengo es rápida y desordenada y no hace nada más que demostrar partes de cómo se puede hacer la interfaz gráfica de usuario. Trataré de dejarlo en un estado más presentable y lo publicaré aquí.

En una nota al margen, logré empaquetar Piskel e integrarlo con Gdevelop. Esto me mantuvo ocupado en las últimas semanas. Puedes intentarlo si quieres :)
También he estado viendo cómo se hacen las hojas de eventos en gdevelop.

@blurymind Ok, digamos que traté de ignorar esta publicación aquí, porque no me gustó la idea de dos Visual Scripts.

Pero finalmente ha sido suficiente. Creo que finalmente es hora de comenzar una discusión. Creo que debe haber usado los documentos para construir la GUI. La maqueta es un trabajo bastante bueno, quería preguntar si hay un repositorio en el que podría ver un poco el código. Probablemente podría hacer algo para que sea más parecido a EventSystem y más viable.

Estaba planeando trabajar en el sistema Visual Scripting actual. Y cuando encontré GDevelop y me gustó, vine aquí a preguntar. Después de una hora de lectura, la conclusión es clara, necesitamos encontrar un término medio.

Mantener dos sistemas Visual Scripting diferentes simplemente no es posible, uno de ellos tiene que morir. Pero nadie, incluyéndome a mí, quiere separarse de la estructura de nodos Blueprints.
Pero este EventSystem es demasiado delicioso (al menos para la creación de prototipos básicos) como para no comerlo.

Quería que VisualScripting fuera más una herramienta de creación de prototipos. Las características limitadas no importan si realmente pueden aumentar la base de usuarios.
Más usuarios también equivalen a más donaciones si nadie lo ha notado antes, entonces debería considerarse.

Pero Blueprints es una herramienta a nivel de la industria, por lo que tiene sus usos y podría traer peces más grandes para Godot, lo cual también es importante para Godot. Y dije que tal vez no sepa mucho al respecto también.

Así que la pregunta es simple, ¿qué hacer? - Elegir ambos no es una posibilidad.
Pero un híbrido podría hacer que Godot sea más popular.
Como tiene experiencia con ambos estilos de Visual Scripting al menos más que yo (soy más un codificador que un artista, así que me gusta codificar a mi manera) ¿Por qué no intenta encontrar una solución?

Es probable que esto atraiga a más personas de las que solo EventSystem podría atraer. Y mantener vivo el sistema de nodos también será un buen movimiento.

Entonces, ¿qué pasa si no se puede lograr un término medio? Algo simplemente morirá. No importa lo que es.

Personalmente, podría votar por Blueprints porque tengo experiencia previa con él, y me gustaría que se compare con el pez más grande Unreal.
Pero solo para comparar, tomé GDevelop en menos de 15 minutos. GDScript en pocas horas en días separados y Blueprint el doble de GDScript seguro.
Aunque también muestra mi nivel de experiencia como programador.

Simplemente no puedo decidir. Aquí ver.

1. Unidad: 4011
2. Irreal: 316
3. Vigilante: 274
4. Construir: 223
5. Godot: 75
   _Lista del tweet de Reduz número de juegos por motor en Global Jam._

Quiero a Godot en la cima. Así que espero que un poco de amor VS ayude a lograrlo.
Pero Unreal + Godot + GameMaker + Construct aún no es suficiente. Pero lo convierte en el número 2 al menos.

Estoy muy confundido sobre qué planear para el futuro de Visual Scripting de Godot. Porque esperar en el sistema actual o tratar de mejorar algo que está roto sin pensar no va a ayudar.

"EventSystem es como programar con Scratch hasta cierto punto. Mientras que Blueprint es completamente único pero es más poderoso que EventSystem, hace que EventSystems se vuelva más confuso con la profundidad y tenga menos legibilidad".

¿¿Qué?? Es exactamente lo contrario si prueba el sistema de eventos de Construct, en particular, incluye otras hojas de eventos y usa grupos.

El mejor sistema de nodos siempre será un espagueti de código en comparación con un EventSystem promedio.

@bigelod Cierto, no debería decirse así. Pensé que era parecido. Escribí ese comentario durante un período de 2 horas mientras aprendía EventSystems. Lo siento, eso lo arreglará.

Sí, sé que lo mejor son los planos y es increíble tener algo así, pero un sistema de eventos agrega más cosas para principiantes. Y también ayuda en el aprendizaje de la programación.

@swarnimarun Hace muchos años,

Ahora, muchos usuarios que en realidad provienen de motores como ClickTeam Fusion, Game Maker y Construct apoyan las hojas de eventos y no les gusta mucho usar planos. Dirán lo contrario de lo que está diciendo y explicarán lo que ya se explicó: por qué los planos son confusos en comparación con una hoja de eventos e incluso con secuencias de comandos. Yo ya lo hice también.

Demonios, incluso al mirar otros foros de motores de programación visual, puede ver las reacciones negativas a cualquier nuevo motor de sistema de planos:
https://rpgmaker.net/forums/topics/23922/?post=857285#post857285

Ahora, al final del día, no veo una razón por la que ambos sistemas no puedan existir. Pueden trabajar juntos, de la misma manera que los blueprints pueden trabajar juntos con los nodos de gdscript.

De hecho, en un mundo ideal, desearía que las hojas de eventos se construyeran y crearan rápidamente prototipos con lógica granular y planos para organizarlos en máquinas de estado.
¿Por qué? Porque ambos sistemas tienen pros y contras.

Los planos de Godot pueden convertirse rápidamente en un desastre cuando comienzas a hacer una expresión simple con nodos. Esta misma expresión puede quedar mucho más clara en una hoja de eventos o en un guión.

Los proyectos de código abierto son democráticos: cuanto más apoya una comunidad una idea, más probable es que se convierta en realidad. Pero eso no significa que otra idea deba ser eliminada. Ambas ideas gustan o desagradan ampliamente.

Todos aquí deben darse cuenta de que tanto con las hojas de eventos como con los planos, estarán programando desde cero. Lo que es más importante es la claridad con la que el sistema les permite estructurar su lógica. Con los blueprints, el orden de ejecución puede convertirse en un lío, lo que dificulta la depuración. También requiere muchos más clics y pasos para configurar en comparación con una hoja de eventos. Este es mi argumento principal aquí, tanto para los desarrolladores profesionales como para los fanáticos de la programación visual. Pero tampoco olvidemos que es una cuestión de gusto personal. No voy a tratar de hacer que los desarrolladores de blueprint sean fanáticos de esto. En cambio, señalaré que a muchos desarrolladores de programación visual no les gustan los planos y prefieren las hojas de eventos.

La hoja de eventos puede usar gdscript para sus expresiones y de esa manera realmente ayudar a aquellos que vienen de un motor de tipo hoja de eventos a aprenderlo muy rápido.

Probablemente, los sistemas de eventos se pueden usar como una herramienta de creación de nodos personalizados.

Solo me gustaría plantear un punto sobre algo: sinceramente, no creo que las hojas de eventos sean solo para prototipos. Creo que parte del problema con la mentalidad de que las hojas pares son solo para la creación de prototipos se debe a que muchas de las herramientas que las usan impulsan el concepto de que facilita la creación de cosas sin saber cómo programar. Cualquiera que realmente use las hojas de eventos durante una cantidad considerable de tiempo sabe que es una forma real de programar que requiere comprender los conceptos fundamentales de programación, y que puede crear juegos completamente completos y ricos en funciones con ella.
Parte del problema es que las herramientas que usan hojas de eventos intentan minimizar la naturaleza técnica de las mismas en un intento de atraer a aficionados y personas que no tienen mucha experiencia en el desarrollo de juegos. En efecto, esto daña la imagen de las hojas de eventos y hace que parezca que no es tan capaz para otras personas que tienen más experiencia en el uso de otras herramientas. Luego, también hay muchas personas que usan hojas de eventos que no están seguras de lo que están haciendo porque les dijeron que no necesitan ningún conocimiento de programación, por lo que los ejemplos que las personas crean no lo representan tan bien. Eso no significa que no haya grandes ejemplos. Es solo que ha desarrollado una cierta idea preconcebida.

..Un híbrido podría ser una forma de romper esa idea preconcebida, permitiendo que las personas lo interpreten de una manera nueva que quizás tenga un tono más serio. Quizás tenga la oportunidad de resolver los problemas de los sistemas anteriores y hacer que el híbrido parezca mejor que los sistemas en los que se inspiró.

@prominentdetail plantea un muy buen punto.
Para agregarle solo diré esto:
Godot tiene la oportunidad de ser el primer motor de juego en 3D adecuado para admitir hojas de eventos. Esto, por definición, lo elevará por encima de todos los demás motores de hojas de eventos en este momento.
Como mencioné antes, esto se ha intentado antes tanto en Clickteam fusion como en Construct, como complementos, incluso en el creador de juegos. Y es un lío torpe allí porque los editores de esos motores no tienen capacidades 3D.

Fusión Clickteam - Motor Firefly:
http://clickstore.clickteam.com/firefly
https://store.steampowered.com/app/267655/Firefly/
Está siendo criticado en Steam, ya que es un complemento horrible con errores

construct2 - q3d
https://www.scirra.com/tutorials/9456/construyendo-tu-primer-juego-3d-con-el-complemento-q3d

Solo mire qué molestia es configurar una escena 3D simple sin tener un editor de escenas 3D
https://youtu.be/VUGsTdBpRCQ?t=6m17s

En mi humilde opinión, un híbrido suena como una excelente manera de obtener las desventajas de ambos.

El enfoque debe ser crear un prototipo de hoja de eventos para mostrar su valor y obtener comentarios.

Después de probar el sistema durante más de una hora, parece bastante capaz. Y la parte interesante es que probablemente se necesite tanto conocimiento de programación como GDscript para crear la mayoría de las cosas, además del movimiento o la mayoría de las cosas básicas para las que se han agregado funciones auxiliares.

Creo que las personas demasiado asustadas para probar la programación son probablemente las únicas que podrían necesitarla en presencia de GDScript.

Eventsheet puede ser fácilmente una herramienta para aprender a programar, especialmente con la API de Godot. Como Godot ya tiene muchas de las mismas funciones de ayuda. Entonces, implementar EventSheet podría realmente usar GDScript.
Porque básicamente puede crear un sistema que convierta EventSheet en GDScript y lo almacene en una carpeta oculta separada, que se actualiza en tiempo de compilación y puede ser utilizada por el motor. Al menos eso es lo que he descubierto. Esta podría ser la solución más sencilla.

Aunque puedo ver que simplemente no puede tomar el lugar de Visual Scripting/Blueprints porque es cierto, no es muy visual, en su mayoría código en la columna, lo que hace que sea más fácil de entender.

No entiendo por qué se publicita de la forma en que lo hace, a menos que alguien tenga conocimientos básicos de programación usando EventSheet y pueda resultar más complicado.

Actualmente, mientras espero que se solucione el lado de Visual Scripting, podría intentar crear algo con esto si tengo tiempo. Puede ser divertido (me ayudará a aprender la API de Godot) intentar implementar una versión básica de EventSheet. Si logro algún progreso, me aseguraré de actualizar aquí.

¿En qué se diferencian las hojas de eventos de gdscript/lenguajes de secuencias de comandos?

Para novatos (cosas que lo hacen más atractivo que programar):

• Hay alguna representación visual de la lógica: se usan iconos, colores y la menor cantidad de texto posible.
• Las condiciones se representan en la columna de la izquierda, las acciones en la derecha: en la codificación, tanto las condiciones como las acciones están en una columna, lo que dificulta que algunos distingan entre los dos al leer la lógica de otra persona.
• En lugar de una larga cadena de texto, los métodos se muestran como palabras simples; en inglés, y los signos de sintaxis se eliminan cuando es posible; eliminar el ruido de la sintaxis hace que sea mucho más claro de leer.
• Intelisense/autocompletar le presenta al usuario la API completa, para que pueda ver todos los configuradores o captadores disponibles y filtrar los que quiere, invertido a cómo funciona en la codificación IDE, donde se muestra el autocompletado después de comenzar a escribir y toda la API. todavía está oculto en la documentación del motor. También tiene pistas visuales para encontrar cosas (iconos). Muestra directamente el tipo de variables devueltas o esperadas
• La lógica de agrupación le permite crear su propia carpeta que puede contraer/descontraer y mover. La capacidad de colapsar bloques de lógica que decidiste que deberían ser colapsables es muy buena cuando estás organizando tu código y quieres ocultar partes de él en las que no estás trabajando.

Para usuarios más experimentados:

• Tiene la capacidad de cambiar muy fácilmente el orden de ejecución de eventos arrastrando y soltando celdas llenas. ¿Qué significa esto? Cuando mientras codificamos en un ide, podemos hacerlo con ctrl+x y ctrl+v. En un sistema de hoja de eventos, puede reordenar simplemente arrastrando y soltando una fila lógica o celdas de una fila a otra.
• La lógica ya establecida es visualmente más clara de encontrar y leer que el código, nuevamente debido a las pistas visuales y el diseño de las columnas izquierda y derecha, además de la codificación de colores. Esto es realmente genial cuando estás creando prototipos de algo.
• La hoja de eventos puede encargarse de las rutas de los nodos para el usuario automáticamente de forma predeterminada, por lo que al armar una hoja de eventos no tendrá que acceder a otros nodos (principales o secundarios) averiguando sus rutas relativas a algo. Todavía tiene la opción de flexibilidad de código, pero el sistema se encarga de esto por usted en los casos en que los nodos no cambiarán dinámicamente sus relaciones padre-hijo.
  Todo lo que tiene que hacer para llegar a un nodo es seleccionarlo en el menú de ayuda. Esto acelera las cosas
• Todavía es muy parecido a gdscript, porque todas las expresiones están en gdscript, pero le brinda algunas ventajas adicionales de productividad. Creo que si se hace bien, esto es algo que a los usuarios de gdscript les encantará, tengan experiencia o no.

Supongo que si tengo que resumir las ventajas:
para los novatos: el código es mucho más claro a primera vista, es más atractivo debido a cómo se les presenta la API del motor y la lógica que establecen tiene sugerencias visuales (iconos de nodos)

para los más experimentados, aún puede escribir gdscript en todos los campos de expresión, pero ahora también puede hacer que algunas partes del proceso sean más rápidas (como no es necesario navegar a otros nodos con código de escritura), la capacidad de arrastrar la lógica para cambiar su ejecución pedido o requisitos (no es necesario cortar y pegar)

Me desvié un poco con algunas cosas de javascript y me encantaría que otros probaran esto :) Pero volveré a eso

Estoy de acuerdo con @mhilbrunner en que debería ser su propio sistema, pero sería genial si fuera posible combinarlo con el sistema de blueprints, la forma en que puedes combinar gdscript con blueprints en un proyecto.

@blurymind
Entonces, ¿dijiste que estabas trabajando en un complemento como ese?
como se llama el repositorio ya está en tu github?

Puedo confirmar que eventshee es más fácil de entender, lo aprendí cuando tenía entre 10 y 11 años y tenía un inglés deficiente (no soy un hablante nativo), mientras que me llevó mucho más tiempo y conocimientos de inglés aprender a hacerlo. código.

algunas veces puede ser más rápido que escribir código, cuando te acostumbras puedes hacer clic tan rápido como piensas.

el único inconveniente que veo es que te vuelves perezoso cuando tienes que aprender código tradicional.

estaba empezando a trabajar en esto, pero su código parece ser más avanzado que el mío, me temo que no puedo ser útil, pero me gustaría intentarlo de todos modos

@Elmapul No creo que su repo ayude mucho.
Y la codificación es mucho más rápida en realidad si piensas así, significa que no eres realmente un buen programador que ha trabajado con lenguajes como Python.
Aunque EventSheet es más útil e indulgente para los principiantes, eso es todo.

Solo pensé en mencionar algo, ya que he incursionado en varias herramientas a lo largo de los años.
Soy un artista ante todo, así que paso la mayor parte de mi tiempo creando arte. Es a lo que dedico la mayor parte de mi tiempo y es a lo que mi mente se ha fortalecido para favorecer. Ha habido muchos casos en los que tomo descansos prolongados lejos de la codificación, mientras hago otras cosas artísticas, como freelance, etc.
Como artista, esto hace que sea difícil mantener la agudeza en cualquier herramienta de desarrollo de juegos en particular que requiera patrones de sintaxis específicos, patrones que debes seguir constantemente para mantener el control.
Entonces, como artistas, se espera que los artistas probablemente no tengan la misma consistencia y prioridad que el estilo de codificación basado en la sintaxis.
Las hojas de eventos son una forma de sortear ese obstáculo cada vez que te ausentas de la programación (porque, como artistas, se espera que no pases tiempo continuo simplemente programando). Las hojas de eventos son más fáciles de volver a usar porque requiere menos memoria de la estructura sintáctica y los patrones con los que se familiariza en la codificación.
Debido a esto, prefiero el eventsheeting porque puedo ser más productivo en lugar de tener que volver a aprender constantemente. Simplemente regreso después de usar mi mente en tareas y proyectos más artísticos; es un flujo mental más fácil.

... Entonces, básicamente, lo que quiero enfatizar es que sí, la codificación es más rápida si dedicas todo tu tiempo a esa ocupación y desarrollas las facultades mentales que favorecen esa línea de pensamiento. Simplemente lo escriben y se van, nunca se apartan de este estilo de vida/comportamiento. Para otros, esta nunca será una opción realista, porque han dedicado su vida a otras líneas de trabajo que han fortalecido un patrón diferente de comportamiento y práctica.
Así que sí... puedes ser como... oh lo que sea, apesta ser tú... lástima que no dediques tu tiempo a ser un programador de tiempo completo, etc., lo que alienaría a muchas personas que nunca estarán completas. programadores de tiempo o de mentalidad técnica. Y seguro que es el derecho del desarrollador hacerlo...
Pero si desea invitar a otros tipos de personas y hacer que más personas realmente usen la herramienta, independientemente de su potencial técnico, entonces ayuda estar más abierto a las cosas y tratar de ayudar a aquellos que no son capaces de igualar su sistema/flujo de trabajo preferido. , etc..
Solo sigo respondiendo, porque siento que la hoja de eventos ayuda mucho a progresar en el desarrollo de juegos, sin los efectos de abandono que ocurren cada vez que una persona se va y regresa, etc. Ya es menos lo que impide que una persona como yo se dé por vencida. , y simplemente regresando a su línea normal de trabajo. Entonces, al final, en realidad logro más, incluso si toma un poco más de tiempo o es un poco menos impresionante a nivel técnico.

@prominentdetail Para todos los efectos, Visual Scripting puede hacer exactamente eso, por lo que no debe preocuparse una vez que la implementación esté más completa, resolverá la mayoría de los problemas artísticos de recordar la sintaxis.

Utilicé Blueprints después de dejar la codificación durante un desgarro completo y todavía se sentía natural y adecuado en un par de minutos. Así que creo que la mayoría de la gente estará bien con eso.

No importa qué idioma conozca, la creación de secuencias de comandos visuales con eventos agrupados correctamente y opciones de acción será más rápida que el tiempo que lleva, a menos que esté escribiendo nombres de variables y tipos de datos muy cortos.

Dicho esto, si los eventos se asignaran a atajos de teclado, entonces sería más rápido "escribir" nuevamente, pero aún así son los eventos/acciones los que son más rápidos que el código estándar desde cero (ya que las acciones y condiciones a menudo representan una función completamente compleja , prefabricado y flexible para la mayoría de los usos).

Mi argumento sigue siendo que la hoja de eventos es más fácil de aprender que
planos y más rápido de configurar.

Además, es mejor en la transición.
gente nueva a lenguajes de script reales.

Si está bien diseñado, un sistema de hojas de eventos puede ser tan rápido como escribir
gdscript. Si miras mi gif de maqueta, es bastante similar a simplemente escribir
Código con autocompletado cuando se usa el filtrado del menú de ayuda.

De todos modos, todavía estoy averiguando cómo hacer esto y afortunadamente Godot
gdscript obtendrá secuencias de comandos escritas, lo que es más adecuado
para generar bbcode para mi hoja de eventos.
Por ejemplo una de las sutilezas
de un campo de expresión en un sistema de hoja de eventos es que le da una
indicación clara del tipo de variable que espera e incluso se enciende en
verde cuando sea válido (consulte las fusiones de clickteam).
Actualmente estoy tratando de descubrir cómo hacer un campo de expresión que pueda
tome gdscript pero también use el menú de ayuda que hice. Nuevamente, esto es solo experimentar cómo podría funcionar. Esto está lejos de ser un cajero automático utilizable.

El miércoles 30 de mayo de 2018 a las 22:59 Daven Bigelow, [email protected] escribió:

No importa qué idioma sepa, la creación de secuencias de comandos visuales con
las opciones de eventos y acciones agrupadas serán más rápidas que el tiempo que lleva
a menos que esté escribiendo nombres de variables y tipos de datos muy cortos.

Dicho esto, si los eventos estuvieran asignados a atajos de teclado, entonces sería
de hecho, será más rápido "escribir" de nuevo, pero aún así son los eventos/acciones los que
son más rápidos que el código estándar desde cero (ya que las acciones y condiciones a menudo
representan toda una función compleja, prefabricada y flexible para la mayoría de los usos).

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/godotengine/godot/issues/17795#issuecomment-393333602 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AGMbVT30aPs63RYwxtFqDTHWVqclenRBks5t3xZTgaJpZM4S8wyr
.

@blurymind Recomendé hacerlo con C ++, será más adecuado y más completo con ese método. Incluso yo, que comencé C ++ hace unas semanas, ahora puedo usarlo, crear correcciones de errores y nuevas funciones. Así que no es tan difícil, probablemente un poco. Sin embargo, todavía necesito usar stackoverflow.

Pero si está buscando quedarse y usar GDScript y simplemente crear un prototipo para que otros lo conviertan en una herramienta completa, creo que debería compartir el repositorio aquí, sin importar cuán incompleto sea.
Estaré encantado de ayudar. Me gusta mucho la idea de EventSystem. Y VisualScripting actualmente no funciona, así que no tengo mucho que hacer.

El problema es que el sistema de eventos puede ser complicado de implementar, en Godot probablemente lo estés implementando como un lenguaje de secuencias de comandos. Pero esa no es su intención, es un administrador de eventos, por lo que debería ser global o debería poder manejar toda la escena por sí solo, y luego usar grupos para separar el trabajo en secciones.
Todo esto es posible, y tampoco debería ser un problema implementarlo.

@swarnimarun, ¿hay un módulo de hola mundo que cree una nueva interfaz de modifique la existente?
¿Puedes recomendar algún buen tutorial de introducción que te haya ayudado?

En cualquier caso, ahora estoy pensando en cambiar la sintaxis de gdscript que generaría el menú de ayuda para escribir gdscript:
https://github.com/godotengine/godot/pull/19264
Luego, eso se convierte en bbcode que representa la interfaz de celda de la hoja de eventos interactivos

Hice este diagrama de flujo para explicar cómo funciona en este momento
https://www.draw.io/#Hblurymind%2FGodot-eventSheetPrototype%2Fmaster%2FEventSheetDiagramPlan.xml

@blurymind Recomiendo no buscar tutoriales, sino aprender de la práctica real o de otros desarrolladores.
Nadie realmente me ayudó. Tampoco necesité mucha ayuda. Soy bastante bueno para recoger cosas, así que todo salió bien. Aún así, solo estoy comenzando, eso se compara con los desarrolladores experimentados.

Y creo que está usando GDScript para hacer toda la programación, o está usando C++.
Porque no hay módulos que te permitan hacer nada por defecto o al empezar. Tienes que aprender de lo que ya está ahí. Y crea el tuyo propio.

La conversión a GDScript con tipo debería ser simple si está usando GDScript y si está usando C ++, se requerirá poca portabilidad. Y hasta donde yo sé, PR debería fusionarse en cualquier momento. Ha sido revisado y parece estar bien. Todavía no lo he probado, pero estoy muy emocionado.

Y déjame adivinar que actualmente estás usando GDScript con get_method_list() y get_property_list() probablemente. Pero te recomendaría usar señales y grupos también, las señales son el mecanismo de activación de eventos de Godot. Realmente no sé sobre EventSystem, pero si quieres crear algo así en Godot. Asegúrate de usar Godot al máximo.

Y, por último, si desea ayuda, envíeme un mensaje en Twitter o Discord. Voy a estar libre por unos días en este momento.

@swarnimarun Estoy usando gdscript para escribir el complemento, ya hay algún uso de señales en él para cosas como desencadenar eventos.
Sí, uso get_method_list() y get_property_list() para mostrar el menú auxiliar también

¿Tienes el mismo identificador en twitter y discord?

Por ahora, mi plan es hacer un prototipo de la interfaz gráfica de usuario en gdscript, ya que es lo que sé más que c ++.
También tengo algo de experiencia en javascript, pero eso no ayudará mucho aquí

El gdscript escrito es lo que generarán los menús de ayuda para el modo de expresión; simplemente es mejor para convertir a bbcode para representar la interfaz de usuario con una etiqueta de texto enriquecido

@blurymind Eso es muy bueno entonces. No vi eso en los gifs de arriba. Así que asumí algunas cosas.

En cuanto a mi identificador, el de Discord es Swarnim. Y creo que ya conoces mi twitter.

@blurymind - Excelente trabajo. Literalmente comencé a aprender C ++ debido a la mejora del rendimiento en Godot en comparación con GDScript (3 a 4 veces más rápido, según su métrica; consulte bunnymark ). Si es posible, recomendaría ir directamente a por el oro y usar C ++ para esto, incluso si significa aprender en el trabajo, valdrá la pena. Dame unas semanas para familiarizarme con C++ y estaré dispuesto a ayudarte también si lo deseas.

@colludium La

C++ es un dolor. Confía en mí. Pointer and Refs y el código de compilación no es más que dolor. A menos que quieras tener un futuro como desarrollador de juegos para una gran empresa o estés estudiando en la universidad o seas tan inteligente que conozcas completamente GDScript o estés en un nivel profesional como programador.

Si aún desea continuar, intente aprender a crear código GDScript dinámicamente mientras lo hace porque, como sabemos, crear un sistema de exportación para un idioma es una molestia, por lo que generar código GDScript directamente hará que todo sea mucho más fácil de hacer.
Y como una ventaja adicional, podrá hacer una vista para ver el código y ayudar a los novatos a aprender a codificar más rápido.

@blurymind Quería preguntar qué versión de EventSystem está usando como base porque quería crear un prototipo del sistema como un módulo de C++, así que me gustaría sincronizarlo con el suyo al menos en el nivel básico.

@swarnimarun - gracias por el consejo re: C++. Solo soy un programador aficionado que viene de JavaScript, por lo que lo que busco es una transición de mínimo dolor/máximo rendimiento. No estaba al tanto de las mejoras planificadas para hacer que GDScript sea mucho más rápido; es bueno saberlo. Ahora tengo un dilema: C# o el mucho más fácil de aprender GDScript...

@colludium Digamos que lo que sea que le resulte más fácil, al ver que su fondo es Javascript, recomiendo GDScript porque también tiene escritura dinámica, y con la escritura estática entrante debería ser el compañero perfecto.
Y déjame decirte si alguna vez piensas que C ++ es un lenguaje que deberías aprender, solo ve y revisa la página Rust vs C ++ de algún foro.

@swarnimarun Estoy usando Godot 3.0.2
Aquí está el repositorio de prueba al que agregué el proyecto
https://github.com/blurymind/Godot-eventSheetPrototype
Todos son libres de bifurcar o hacer solicitudes de extracción 👍

Por favor, siéntase libre de comenzar a escribir un módulo C++. Lo que tengo funcional hasta ahora es solo el bloque de construcción central de la interfaz: el contenedor de celdas lógicas.

El analizador bbcode (solo usa expresiones regulares) y la representación del menú de ayuda son las cosas que pueden serle más útiles, aunque personalmente estoy pensando en cambiar su forma de trabajar: se juntaron en mi tiempo libre entre el trabajo y otros proyectos. . La cosa es un lío en cuanto al código de cajero automático, por lo que tener programadores más experimentados sería de gran ayuda para mí.

El resto es solo una interfaz estática instalada para fines de captura de pantalla.

Una cosa que es muy importante hacer es crear algún tipo de diccionario editable que realice un seguimiento de todos los nodos en la escena y sus rutas, por lo que en lugar de rutas de nodos estáticas, el menú de ayuda debería generar gdscript que use rutas de un diccionario que los actualiza automáticamente y si el usuario elimina un nodo y la lógica de la hoja de eventos no lo encuentra, se puede volver a vincular

En cualquier caso, comparta si tiene algo, incluso si es básico. Intentaré aprender un poco más de C++ y unirme a ustedes para escribirlo como un módulo :)

@blurymind ¡Finalmente! alguien que entendió muy claramente que el scripting visual de Godot Engine 3.x es inútil (demasiado complejo para principiantes, inútil para expertos).

¡El sistema de eventos de GDevelop es magnífico! es muy útil especialmente para crear plantillas completas de juegos en 2D y luego agregar funciones más avanzadas a través de GDScript. ¡Esto hará que Godot Game Engine sea mucho más atractivo, popular y generalizado!

Sinceramente amo a Godot Engine pero hacer juegos 2D para dispositivos móviles no es la solución más fácil e inmediata. Podría ofrecer mucho más con un sistema simplificado/sistema de eventos). Godot tiene un excelente editor de animaciones, es realmente agradable y funcional, solo necesita un sistema más amigable si quiero crear un juego de plataformas en 2D sin tener que escribir miles de líneas de código (que me parecen inútiles para crear un súper básico). plantilla de estilo mario bros para NES).

Me parece que la idea de @blurymind es fantástico! la comunidad de Godot ha crecido enormemente y estoy feliz con eso. No tengo ninguna duda de que el sistema de eventos se implementará con los próximos lanzamientos. Visual Scripting (repito) es absolutamente inútil en la actualidad (ni siquiera puedo encontrar tutoriales, y nadie lo usa por lo que puedo ver en la web).

¡Un saludo y gracias por tu fantástico trabajo!

@XenonCoder Haces un punto interesante al final

Visual Scripting (repito) es absolutamente inútil en la actualidad (ni siquiera puedo encontrar tutoriales, y nadie lo usa por lo que puedo ver en la web).

Este es un buen ejemplo de cuando algo es difícil de usar por naturaleza, luego se usará como una profecía autocumplida para explicar por qué no se debe hacer (por ejemplo: "¡MIRA! ¡Nadie quiere secuencias de comandos visuales!"), en lugar de admitir que simplemente no se hizo de una manera atractiva o amigable para principiantes.

Es como un regalo a medias, porque sin el seguimiento, de hecho es inútil.

Lo mismo ocurrirá con cualquier adición al motor que no esté bien documentada o no se proporcione con ejemplos.

@bigelod Absolutamente de acuerdo contigo. Me alegro de que no hayas malinterpretado mis intenciones y hayas entendido perfectamente lo que quise decir.

¡Godot Game Engine es simplemente fantástico! Tiene un potencial increíble. Para hacer juegos 2D, ¡es el número 1! Durante años he experimentado con todos los Game Engine y frameworks existentes y puedo decir con absoluta certeza que Godot es un proyecto que promete grandes cosas.

Por ejemplo, el nuevo Visual Shader se ve muy bien y promete grandes cosas para el futuro. Hice algunas pruebas y me gusta mucho como idea. Pero para realizar la lógica de un videojuego, el Visual Scripting es una trampa.

Necesitamos tutoriales, documentación en general, y sobre todo un sistema simplificado al estilo Build 3, GDevelop, Game Maker Studio 2. Inicialmente como addon para lograr juegos principalmente 2D, en el futuro se mejora y se implementa oficialmente. Me doy cuenta de que no es una tarea fácil, es solo una idea para hacer de Godot Game Engine la solución ideal para entusiastas, estudiantes y profesionales de los videojuegos.

Gracias a todos.

Alrededor de los motores del juego se formaron tiendas. Se volvió normal: escribir complementos de forma comercial. Para Construir incluido. Todos los últimos complementos significativos de C2 son comerciales. Esto se debe no solo a la formación del mercado, sino también a la complicación de los productos, un gran gasto de tiempo para probar y corregir errores de compatibilidad.
Creo... Godot está en otro nicho, y si Juan no escribe y apoya la aplicación de programación simplificada, es poco probable que alguien más lleve este trabajo hasta el final.

Crecí con Klik 'n Play, The Games Factory y Multimedia Fusion, y actualmente uso Construct 2. La creación de secuencias de comandos visuales con hojas de eventos es totalmente diferente al uso de nodos de máquinas de estado al estilo de blueprints conectados entre sí, y para las personas que están acostumbradas a las hojas de eventos, es la forma más fácil y eficiente de programar. Me encantaría tener una forma de crear secuencias de comandos en GoDot con hojas de eventos.

Me encontré con algunas limitaciones en gdscript, la documentación y la API del complemento que me impiden ejecutar completamente mi visión de esto como un complemento. Incluso si lo llevo a un estado funcional, probablemente tendrá limitaciones.

Una cosa que me ayudará de inmediato a llegar allí es el gdscript opcional tipeado, razón por la cual dejé de trabajar en esto hasta que esté en Godot. Ahora que está fusionado, volveré a trabajar en esto como un complemento de prueba de concepto siempre que haya tiempo.

La idea es que se escriba el gdscript generado de la hoja de eventos. Los datos escritos le darán a la interfaz gráfica de usuario de la hoja de eventos datos contextuales adicionales sobre qué tipo de parámetros se esperan.

Si hay interés en esto como un módulo C++ adecuado o un complemento gdnative, todos son libres de intentar implementarlo.

En vista de cuántas personas lo quieren, nada me hará más feliz que hacer que esto sea parte de Godot, o al menos que funcione como parte de Godot.

Desafortunadamente, tengo un trabajo de tiempo completo que ocupa la mayor parte de mi tiempo en este momento :(
Lo siento por las actualizaciones lentas

Para agregar a esta discusión, me gustaría presentarles a todos aquí un ejemplo fantástico de un motor de secuencias de comandos visuales que utiliza un enfoque de programación visual basado en conexiones de nodos que actualmente está fallando en su grupo demográfico objetivo.
https://youtu.be/b8GZ21YCh50?t=4m12s
Es algo similar a https://www.reddit.com/r/unrealengine/comments/4nt0up/need_help_debugging_this_blueprint/

Tenga en cuenta las alternativas que presenta Gamesfromscratch

Una cosa que quiero evitar aquí en esta propuesta de diseño es predefinir el comportamiento que está fuera de lo que ya hacen los nodos en Godot, también creando muchas pestañas y gui.
Una hoja de eventos de Godot debería funcionar exactamente como el código gdscript, solo que de una manera más táctil/visual
No debería tratar de construir un motor de juego fácil de usar sobre Godot, sino hacer que Godot sea más accesible y rápido de armar.

¿Tal vez con un guión visual podría ser accesible incluso con pantallas táctiles?

De hecho, las secuencias de comandos visuales del estilo de la hoja de eventos son muy adecuadas para las funciones táctiles.
pantallas

El miércoles 1 de agosto de 2018 a las 06:46 Elmapul, [email protected] escribió:

¿Tal vez con un guión visual podría ser accesible incluso con pantallas táctiles?

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/godotengine/godot/issues/17795#issuecomment-409456475 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AGMbVdqoa3AdMNfiM986iwIpNeqzqjVLks5uMUCvgaJpZM4S8wyr
.

@blurymind si el sistema de complementos necesita mejoras para esto, abra un problema, ya se modificó porque otros complementos necesitaban algo en particular.

¡Es una gran idea! Realmente nunca entendí estos planos, pero el enfoque basado en eventos es bien conocido, especialmente en las comunidades de modding, como Warcraft III World Editor.

Pantallas de ejemplo:


Las categorías y la lista limpia de disparadores se ven geniales, al menos para mí. Es más fácil percibirlas que las pantallas del primer post.

Es casi lo mismo que dijiste, pero con la posibilidad de agregar condiciones como acciones y anidar más acciones en ellas.

@Wiadomy
esta imagen es demasiado pequeña para ver/leer nada

@Elmapul
Lo siento, algo andaba mal con eso. Actualizado.

@Elmapul si bien mi complemento de concepto aún no puede anidar, la hoja de eventos que propongo incluye anidamiento. Tanto gdevelop como build admiten el anidamiento de filas; puede probarlo ahora mismo si lo desea :)

@blurymind finalmente comenzó a trabajar en la implementación de la hoja de eventos, ¿conoce algún recurso que discuta su implementación en detalle, como un trabajo de investigación o un artículo sobre su funcionamiento e implementación?
Eso será de gran ayuda. Para comenzar a diseñar el Sistema de hojas de eventos para Godot.
Porque no sería correcto usar el método Construct o GDevelop ya que el funcionamiento de Godot es bastante diferente y tenemos cosas llamadas señales que también deben integrarse y luego algunas más.

hay información sobre la hoja de eventos de la construcción aquí si necesita información general: https://www.scirra.com/manual/74/events
Las diferentes compañías implementan sus hojas de eventos de manera un poco diferente entre sí, por lo que cada una tiene sus propias peculiaridades.
Tal vez pueda crear un video que resuma las diversas partes del método de construcción (ya que esa es probablemente la mejor manera actualmente). No conozco ningún trabajo de investigación, aunque sería interesante encontrarlo.

@prominentdetail Gracias por el enlace, parece que tendré que ver cómo hacer que los eventos sean más fáciles de usar como sistema de construcciones.
Mi primera idea era tener algo similar al complemento de @blurymind, pero ahora es más probable que tengamos una API diferente para la hoja de eventos que facilita la codificación y no es una versión de GDScript en forma visual.

Entonces, ¿qué piensan ustedes si el Sistema de eventos debería tener una API diferente para agregar facilidad de uso o simplemente ser un envoltorio para GDScript?

@swarnimarun realmente lo mejor que puede hacer es usar los motores por un tiempo y pensar en cómo se puede hacer esto de una manera más buena. Construct classic y gdevelop son excelentes ejemplos, en mi opinión.

Desde mi punto de vista, las señales en Godot son como eventos de función incorporados. Conectar señales ya es visual en Godot :)

Establecer una señal desde una hoja de eventos es solo una acción disponible en el menú de ayuda; bajo el capó, es solo un método de configuración. Entonces sería lo mismo que con gdscript.

Si un nodo contiene métodos integrados, debería estar disponible en el menú que aparecería al hacer clic en 'Agregar función integrada'

Creo firmemente que deberíamos mantenerlo simple y ser un contenedor para gdscript escrito , pero si eso no es posible o práctico, podría ser una API diferente. Valdría la pena investigar cómo el script visual actual implementado en Godot funciona como una abstracción.

Si se pregunta cómo se crean las funciones personalizadas en la construcción, aquí hay un enlace a su documento
https://www.scirra.com/tutorials/823/creating-function
:)

@blurymind En realidad, es mucho más fácil y mucho menos trabajo mantenerlo como un envoltorio para GDScript, pero la cuestión es que muchas de las funciones de Event Sheet se volverán más tediosas de esa manera, al menos así lo entiendo.
Así que creo que lo mantendré igual para los principiantes y luego agregaré cosas si es necesario.

@swarnimarun gracias por tomarse el tiempo para probar esto

Creo que el mayor problema es que VisualScript, como todos los demás lenguajes que puedes usar para crear scripts de Godot, trata de estar lo más cerca posible de la funcionalidad de GDscript, con funciones, variables, señales y todo lo demás. No podría lograr esto con un sistema de hoja de eventos, porque perdería mucha funcionalidad. (Sé que es posible, pero se hincharía rápido)

@Jummit, excepto que puede

¿Y podría tener toda la funcionalidad de GDscript? Entonces, ¿qué estamos esperando? ¡Consigamos hojas de eventos en Godot!

@Jummit Godot tiene toda la funcionalidad que desea en forma de 'Nodos'

'Nodos' en Godot son como 'Comportamientos' en construct2
El comportamiento del juego de plataformas en construct2 es como un nodo kintematicbody2d menos poderoso :)
No tiene que escribir todo desde cero.

Lo que es aún mejor es que puede anidar estos nodos en una relación padre-hijo, mientras que los comportamientos están restringidos para adjuntarse como módulos a un solo objeto de juego.

Creo firmemente que un Godot con una capacidad de hoja de eventos incorporada y algunos complementos adicionales de la comunidad pueden convertirse en un motor más rápido para la creación de prototipos que el construct2 o el 3.
Tiene mucho potencial que está sin explotar.

La rapidez de creación de prototipos en C2 está determinada en gran medida por la interactividad de las celdas: se pueden arrastrar, copiar y cambiar con teclas de acceso rápido, incluidos los objetos de condición, mientras que las listas desplegables eliminan casi por completo el error.

@swarnimarun , creé una descripción general genérica de varias construcciones: https://www.youtube.com/watch?v=ioz3gHtA-Lg
Es básicamente para cualquier persona que no esté demasiado familiarizada con la construcción para tener una idea de ella. Probablemente pasé por alto varias cosas ya que no planeé todo, pero podría proporcionar una comprensión básica. Probablemente debería hacer algunos videos en los que realmente desarrolle más, para mostrar el lado del flujo de trabajo en lugar de divagar sobre varias cosas. Avíseme si desea que se cubra o explore algo.

Eso es feo como f ** k para mí. Quiero decir, guiones en el video.

@Wiadomy es mucho mejor en uso que en ese video. Las hojas de eventos al final siempre se ven más limpias y legibles que cualquier sistema basado en nodos.

@Wiadomy , debido a la grabación de pantalla, tuve que usar un monitor y también mantener el tamaño del texto relativamente grande. Construir formatea el texto para que algunas cosas puedan amontonarse debido al espacio de la pantalla si escribe una expresión continua larga.
Para resolver algo de eso, puede alejar el texto y también usar otro monitor para liberar espacio para enumerar mejor los eventos.
También podría dividir un poco las expresiones para hacerlo más ordenado, pero este es un proyecto mío más antiguo y también un poco más experimental.
Además, se familiariza con las señales visuales y el patrón en la estructura de las hojas de eventos, por lo que resulta más fácil rastrear todas las partes de los eventos. Tener una estructura estándar como esta es muy útil para poder adaptarse a cualquier proyecto y hace que el flujo de trabajo sea muy rápido.

¿Este proyecto está muerto ahora?

@ Amr512 No creo que esté muerto. Ciertamente hay mucho deseo de llevar esta funcionalidad a Godot.
@reduz incluso se ha interesado recientemente en gdevelop en twitter
https://twitter.com/reduzio/status/1085206844275081218

Si bien no he trabajado en el complemento durante un tiempo, decidí ir y comenzar a contribuir con gdevelop, para obtener más información sobre cómo se programa su hoja de eventos, así como para ayudar a que sea una mejor alternativa a la paga. opciones
https://github.com/4ian/GDevelop/

Algunas universidades han comenzado a elegir gdevelop para impartir cursos de programación.
https://github.com/4ian/GDevelop/issues/882

Mi complemento buggy godot es actualmente solo para fines de presentación y necesita mucho trabajo antes de que pueda ser funcional. Cualquiera es libre de bifurcarlo e intentar impulsarlo más, por supuesto.
Una gran cosa que falta actualmente en mi complemento es un elemento gui de árbol clasificable para las filas de eventos. Tampoco hay funcionalidad para renderizar hojas de eventos en gdscript todavía, ni hay un editor de texto de expresión adecuado con autocompletado y coloreado de sintaxis (la idea es usar gdscript estándar para la sintaxis). Faltan muchos elementos clave que harían una hoja de eventos, pero el objetivo principal es presentar cómo se puede usar una hoja de eventos en combinación con gdscript para la sintaxis de expresiones. Creo que los dos harían una combinación muy poderosa para crear prototipos de juegos, incluso para desarrolladores experimentados.

@blurymind dejé un ticket en tu proyecto (errores en Godot 3.1beta3).
Me encanta la idea.

Me topé con este problema por accidente, no sabía que este material ya se usa comúnmente en otros motores / marcos, así que tuve que escribir el mío, se ve muy similar, ¿no crees? 👀

Regla = Evento
Hoja de eventos = Esquema

La implementación anterior usaba verificaciones de propiedad bastante "de bajo nivel" y acciones respectivas, pero pensé que este tipo de sistema es en realidad más útil para definir los "bloques de construcción" del juego al extender las secuencias de comandos base de condiciones/acciones que son más "de alto nivel". nivel" en abstracción. Esa es en realidad la razón por la que elegí la terminología "Regla" en primer lugar.

Debe tener la jugabilidad y el marco del juego ya establecidos para hacer uso de esto en toda su extensión, por lo que no sirve la experiencia lista para usar para escribir un juego sin codificación, pero en realidad lo complementa de una manera que permite le permite combinar la funcionalidad existente en una variedad de formas y organizarla de manera eficiente, simplemente componga nuevas reglas con diferentes condiciones y acciones utilizando sus GDScripts simples.

Y sí, permitir que los jugadores creen sus propios modos de juego/misiones/desafíos a través de modding es otra razón para usar dicho sistema.

@Xrayez, ¿puedes compartir el repositorio de git? Creo que tiene razón en que mi implementación es demasiado granular, pero es fiel a cómo funciona gdscript y la API de Godot.
Además, con solo mirar la captura de pantalla, creo que se está perdiendo el punto: debe haber solo dos columnas, no tres. Izquierda= condiciones, derecha= acciones. También debería poder arrastrar y soltar eventos entre celdas, y también arrastrar y soltar filas y anidarlas. Para construir esto, necesitamos usar un árbol ordenable. Juega con gdevelop y build, obtendrás una mejor idea de lo que hace que estas hojas de eventos sean tan agradables.

Tal vez mi implementación podría considerarse como algo similar a DSL, de modo que ahí es donde pueden surgir las diferencias. Muchas reglas son solo implementaciones en un espacio aislado de funciones diseñadas para requisitos de juego específicos. En esencia, las condiciones y acciones solo heredan estos pequeños scripts con los métodos que deben implementarse en las clases secundarias:

class_name SchemeCondition extends Node

func is_met(object): # override
    return true

class_name SchemeAction extends Node

func perform(object): # override
    pass

Las reglas son solo una colección de esas condiciones y acciones y se ejecutan en función de si se cumplen todas o algunas de las condiciones, de hecho, nada demasiado elegante.

Entiendo que a las personas que contribuyen e implementan cosas les gusta codificar y no todos ven el atractivo de la programación sin codificación, pero muchos otros están interesados ​​en ella.

Construct, Gdevelop, Stencyl, Game Maker, Playmaker, Bolt, Fungus for Unity, Blueprints en Unreal, Flow Graph y Schematyc en CryEngine, etc...

Se están fabricando y utilizando muchas herramientas para no programadores. Un montón de buenos juegos se hacen gracias a estos.
Hollow Knight se hizo con mediapunta, por ejemplo.

Incluso tienes cosas como Dreams haciendo bastante ruido.

Este tipo de herramienta traería mucha atracción y accesibilidad y, por lo tanto, nuevas personas a Godot.

Recientemente implementé una forma en gdevelop para agregar nuevas instrucciones a su hoja de eventos a través de un menú desplegable como este

Es una especie de lo que creo que podría funcionar bien para Godot.

Utiliza la etiqueta de texto enriquecido para representar cada celda, estas celdas están anidadas en la columna izquierda y derecha, que luego es un elemento secundario de una fila. Las filas son administradas por un árbol ordenable. Cada fila contiene gdscript real que un intérprete convierte en descripciones cortas simples con miniaturas y áreas en las que se puede hacer clic para ingresar expresiones.
Esto es realmente lo que hace el creador de juegos. Sus datos de programación visual se almacenan como gml reales.

La parte complicada que encontré cuando comencé a hacerlo como una extensión de gdscript fue hacer los campos de expresión. ¿Cómo ponemos un editor de código en un campo de entrada y dejamos que haga el autocompletado por nosotros? ¿Cómo le damos contexto de finalización y validación? Sin campos de expresión autocompletados validados, esto está muerto en el agua.

Tenemos todas las partes de la interfaz de usuario para construir esto en Godot, pero literalmente no tenemos un solo desarrollador experimentado que haga algo al respecto. No he visto ningún trabajo hecho hasta ahora.

De todos modos, si mi conocimiento de C++ fuera mejor, lo habría intentado :) Pero sé javascript, así que mis contribuciones van a gdevelop en su lugar

Me encantaría ver una solución basada en eventos en Godot. Probé Godot en el pasado, pero no podía sentirme cómodo con su flujo de trabajo. Mi mente es más adecuada para las hojas de eventos si voy a desarrollar un juego.

Ahora soy programador e incluso estoy empezando a entrar en el desarrollo de motores. Pero todavía puedo responder con bastante confianza por las hojas de eventos.

Construct 2 fue, de hecho, mi primera exposición a muchos conceptos fundamentales de programación, a través de una clase que tomé en la escuela secundaria. Siento que simplificó y aceleró enormemente el proceso de aprendizaje para mí, tanto el motor en específico como la programación en general, al mismo tiempo que se tradujo lo suficientemente cerca del código real para que no me sintiera totalmente perdido en la transición de las hojas de eventos. a la secuencia de comandos de texto antiguo normal. Si bien no puedo estar 100% seguro de esto, realmente no creo que podría haber obtenido ninguno de esos beneficios en la misma medida, si en su lugar hubiera sido el tipo de secuencias de comandos visuales tipo espagueti.

Pero estoy de acuerdo en que mantener dos sistemas de secuencias de comandos visuales diferentes probablemente sea una mala idea. Dicho esto, no creo que debamos quedarnos con el sistema actual solo porque es lo que ya tenemos. Creo que realmente deberíamos considerar cambiar al otro sistema, si los datos lo justifican. Es decir, creo que deberíamos tratar de tener una mejor idea de cuánto más accesible es el sistema de hojas de eventos en comparación con nuestro sistema actual. El objetivo de las secuencias de comandos visuales debe ser hacer que el motor sea más amigable para las personas que no están familiarizadas con las secuencias de comandos normales o que no confían en ellas. Un sólido sistema de secuencias de comandos visuales podría marcar una gran diferencia en lo accesible que es Godot, y podría significar obtener el apoyo y la adopción de muchas más personas, que de otro modo no habrían considerado a Godot.

En realidad, la razón principal por la que originalmente me alejé de Construct 2 fue simplemente porque ya quería entrar en 3D. Terminé probando Unity, Unreal, Godot y Amazon Lumberyard, y terminé optando por Godot simplemente porque se sentía más rápido de abrir y usar y el proceso de importación se sentía mejor. Pero si Godot tuviera el sistema de estilo de hoja de eventos, probablemente habría predeterminado inmediatamente a Godot. De acuerdo, realmente no hace una diferencia para mí ahora personalmente, pero nuevamente, se trata de hacer que Godot sea lo más amigable posible con los no programadores (es decir, una parte significativa de los desarrolladores de juegos nuevos/aspirantes).

No he leído las 112 publicaciones que ahora están ocultas, así que me disculpo si repetí o me perdí algo, pero estaría totalmente interesado en crear un prototipo de la idea o ayudar a probarla y considerarla.

Creo que realmente deberíamos considerar cambiar al otro sistema, si los datos lo justifican. Es decir, creo que deberíamos tratar de tener una mejor idea de cuánto más accesible es el sistema de hojas de eventos en comparación con nuestro sistema actual.

Ya tenemos muy pocos mantenedores para el actual sistema de secuencias de comandos visuales. No creo que se complete un cambio completo en nuestra vida :slightly_smiling_face:

Ya tenemos muy pocos mantenedores para el actual sistema de secuencias de comandos visuales. No creo que se complete un cambio completo en nuestra vida 🙂

Bueno, suponiendo que primero obtengamos un prototipo funcional de la hoja de eventos, entonces el código ya estaría casi terminado, y solo sería una cuestión de si queremos cambiar a ese sistema, ¿verdad?

También comencé con Construct 2 y descubrí que las hojas de eventos son geniales para resolver 2
problemas:

• Como cualquier secuencia de comandos visual, expones todas las posibilidades de cualquier
  módulo/complemento/complemento/función, esto es muy útil para aprender código nuevo.
  Sin embargo, los nodos visuales se convierten en código espagueti bastante rápido (soy un tipo de licuadora,
  Sé sobre espaguetis en compositor y shaders).
• La hoja de eventos es como swagger para Rest API, comienza con bien documentado
  código que llena el menú desplegable de la hoja de eventos y obtiene una GUI limpia
  manera de consumir su código, puede extenderse con ensuciarse, y, puede
  generar código a partir de él (JS de Construct2), de ahí mi pregunta: ¿podríamos
  generar código a partir de él?

En caso afirmativo, creo que la hoja de eventos debería convertirse en una prioridad, por su facilidad de uso para
todos y generación optimizada de código de bajo nivel.
Si Godot pudiera usarse para transformar una API python/C#/... en un conjunto limpio de
eventos, luego el usuario crea eventos, luego Godot genera código a partir de él, estás
resolviendo un problema de usuario muy, muy difícil: aprenda a codificar desde una interfaz de usuario simple.

Sé que la hoja de eventos no resuelve todos los problemas, pero al menos puedes codificar 500
eventos como lo que está haciendo en una hoja de cálculo sin perderse en visual
enlaces por todas partes.

El miércoles 8 de abril de 2020 a las 7:44 p. m., Jay [email protected] escribió:

Ya tenemos muy pocos mantenedores para el scripting visual actual
sistema. No creo que nunca se complete un cambio completo en nuestro
toda la vida 🙂

Bueno, suponiendo que obtengamos un prototipo funcional de la hoja de eventos, entonces el código
ya estaría hecho en su mayor parte, solo sería una cuestión de si
quieres cambiar a eso en su lugar, ¿verdad?

—
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/godotengine/godot/issues/17795#issuecomment-611096608 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/AAAP6LM4PU6RYLO5NK5IL23RLSZWHANCNFSM4EXTBSVQ
.

Empecé a usar Construct 2 y eventualmente pasé a desarrollar complementos usando JavaScript, por lo que las hojas de eventos tienen un lugar en mi corazón. Eran fáciles e intuitivos para los no iniciados, con la mayor parte de la magia de la fácil visualización de los métodos disponibles (acciones y condiciones) para cada clase (complemento). Honestamente, GDScript en VSCode es igual de bueno ahora, con intellisense completo y finalización automática que hacen que la vida sea muy fácil. Aunque era un gran admirador de esta idea hace 2 años, ahora cambié de opinión. Preferiría que los héroes de desarrollo de Godot concentraran su tiempo y esfuerzo en agregar otras mejoras al motor.

¿Podríamos generar código a partir de él?

Tendría que investigarlo más, pero honestamente creo que sería bastante trivial hacerlo y, de hecho, es probablemente la mejor manera de hacerlo. Es decir, creo que la mejor manera de manejar un estilo de hoja de eventos es básicamente hacer que actúe como una interfaz gráfica para un archivo gdscript normal. Las acciones realizadas en el editor de hojas de eventos simplemente editarían el archivo gdscript. Por ejemplo, mover un bloque de un lugar a otro en el editor de hojas de eventos básicamente sería como cortar y pegar virtualmente en el archivo gdscript. Y cualquier archivo gdscript se puede ver y editar en el editor de scripts o en el editor de hojas de eventos. Esta parece ser la mejor manera de hacerlo, tanto desde el punto de vista de la usabilidad como desde el punto de vista de la implementación. Dicho esto, todavía no tengo mucho conocimiento sobre el desarrollo de motores, por lo que puedo estar equivocado.

Preferiría que los héroes de desarrollo de Godot concentraran su tiempo y esfuerzo en agregar otras mejoras al motor.

Estoy bastante de acuerdo. Creo que la forma ideal de hacer esto sería que cualquier persona interesada intente obtener un prototipo que funcione, y luego, a partir de ahí, la comunidad puede intentar averiguar si vale la pena cambiarlo como el principal sistema de secuencias de comandos visuales o no. No pediría ningún tiempo de desarrollo principal sobre esta idea hasta que se tome una decisión o al menos cerca.

No estoy lo suficientemente en Gdscript o Godot también.
Pero lo que desarrollé como una extensión de VS Code también va de esta manera amplia
(https://github.com/j2l/blocklight).
Entender visualmente el código jugando con un trozo de él y visualmente
vincular las variables y los resultados (nodos en la mayoría de los scripts visuales o colores
en mi extensión) es la piedra angular que falta para muchos.
En realidad, entendemos el código cuando terminamos de aprenderlo, mientras que deberíamos
ver las variables y los enlaces de los fragmentos antes de obtener todos los
código.
Diseño antes de codificar :)

El miércoles 8 de abril de 2020 a las 8:08 p. m., Jay [email protected] escribió:

¿Podríamos generar código a partir de él?

Tendría que investigarlo más, pero sinceramente creo que sería bonito.
trivial hacerlo, y de hecho es probablemente la mejor manera de hacerlo. Es decir,
Creo que la mejor manera de manejar un estilo de hoja de eventos es básicamente
haga que actúe como una interfaz gráfica para un archivo gdscript normal. Comportamiento
tomado en el editor de hojas de eventos simplemente editaría el archivo gdscript. Moviente
un bloque de un lugar a otro en el editor de hojas de eventos básicamente
bajo el capó se está haciendo como un cortar + pegar virtual en el archivo gdscript. Y
cualquier archivo gdscript se puede ver y editar en el editor de scripts o en
editor de hojas de eventos. Esta parece ser la mejor manera de hacerlo, tanto desde un
desde el punto de vista de la usabilidad y desde el punto de vista de la implementación. Eso dijo que soy
Todavía no estoy muy bien informado sobre el desarrollo del motor, por lo que puedo estar equivocado.

—
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/godotengine/godot/issues/17795#issuecomment-611108712 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/AAAP6LN7GFGSBDZ537XXA6DRLS4Q5ANCNFSM4EXTBSVQ
.

Me encanta la idea de que generaría un archivo Gdscript normal. seria genial para aprender

Cuando comencé a crear juegos, el sistema de eventos de Klik & Play fue una excelente manera de familiarizarme con la lógica de programación, y todavía me encanta volver a utilizarlo.

Me encanta la idea de que generaría un archivo Gdscript normal. seria genial para aprender

Cuando comencé a crear juegos, el sistema de eventos de Klik & Play fue una excelente manera de familiarizarme con la lógica de programación, y todavía me encanta volver a utilizarlo.

Creo que es potencialmente una de sus mayores ventajas sobre el sistema spaghetti actual: debido a su diseño, facilitará a las personas el aprendizaje de la programación y la API de gdscript/godot.

Algunas personas aquí comentaron, pero ¿por qué molestarse en hacerlo? Es demasiado similar a la secuencia de comandos en la presentación.
Mi respuesta a eso es - precisamente. Aprendes espaguetis, te quedan espaguetis. Aprende la hoja de eventos, conocerá gdscript al ver lo que genera y usar esos campos de expresión.

Le enseñará sobre el orden de ejecución y cómo leer el código.

Vea lo que convierte a GML en el creador de juegos
https://docs2.yoyogames.com/source/_build/3_scripting/1_drag_and_drop_overview/ Changing_dnd.html

¡Blurymind realmente interesante! Tuve la misma idea y estoy apoyando completamente esto.
Todavía estoy haciendo extensiones para Clickteam Fusion 2.5 pero todo lo que quiero agregar en Fusion está en Godot.
Todo lo que necesito es poner una capa de abstracción más (hoja de eventos) en Godot para facilitar el desarrollo.
No leí todo el hilo, pero la principal diferencia desde mi punto de vista entre las secuencias de comandos visuales en Godot y las hojas de eventos en otros motores de juegos es que las secuencias de comandos visuales son "solo" una vista visual del código y las hojas de eventos son una abstracción de el código con una vista simplificada. Es más legible por humanos, está factorizando cosas que necesitan varias líneas de código en una línea y la vinculación de señal/ranuras se realiza automáticamente.
En realidad, agregar algunas plantillas (escenas predefinidas) para abstraer el objeto incorporado de CF2.5 y seguir usando GDScript haría la mayor parte del trabajo por mí, pero la hoja de eventos definitivamente me hará más eficiente en Godot que lo que estoy haciendo en CF2.5 ahora.

¡Blurymind realmente interesante! Tuve la misma idea y estoy apoyando completamente esto.
Todavía estoy haciendo extensiones para Clickteam Fusion 2.5 pero todo lo que quiero agregar en Fusion está en Godot.
Todo lo que necesito es poner una capa de abstracción más (hoja de eventos) en Godot para facilitar el desarrollo.
No leí todo el hilo, pero la principal diferencia desde mi punto de vista entre las secuencias de comandos visuales en Godot y las hojas de eventos en otros motores de juegos es que las secuencias de comandos visuales son "solo" una vista visual del código y las hojas de eventos son una abstracción de el código con una vista simplificada. Es más legible por humanos, está factorizando cosas que necesitan varias líneas de código en una línea y la vinculación de señal/ranuras se realiza automáticamente.
En realidad, agregar algunas plantillas (escenas predefinidas) para abstraer el objeto incorporado de CF2.5 y seguir usando GDScript haría la mayor parte del trabajo por mí, pero la hoja de eventos definitivamente me hará más eficiente en Godot que lo que estoy haciendo en CF2.5 ahora.

solía usar CF en los días en que se llamaba fusión multimedia, era bastante fácil de aprender como un niño que no hablaba inglés, y después de practicar con él, puedes ser muy rápido, dependiendo de lo que estés haciendo puede ser más rápido que escribir.
construct y CF son una referencia de cómo se ve una buena secuencia de comandos visual (gdevelop está llegando allí)

Gracias
apoyo esta maravillosa idea
¡Dicen que la construcción 2 se retirará!
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505

Me pregunto si es posible negociar con el desarrollador de la construcción 2 para abrir el sistema de eventos y usarlo en Godot, Unity, etc.
Es una pérdida que el sistema de eventos de construcción 2 se descuide en los estantes sin usar

Gracias
apoyo esta maravillosa idea
¡Dicen que la construcción 2 se retirará!
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505

Me pregunto si es posible negociar con el desarrollador de la construcción 2 para abrir el sistema de eventos y usarlo en Godot, Unity, etc.
Es una pérdida que el sistema de eventos de construcción 2 se descuide en los estantes sin usar

Dudo que podamos usar cualquier código de construct2 en godot: son una base de código completamente diferente.

Su mejor apuesta para una alternativa de código abierto es mudarse a gdevelop
https://github.com/4ian/GDevelop

Es probable que este ticket de problema se cierre pronto, por lo que si hay algún interés en esta hoja de eventos en Godot, es posible que pronto tengamos que moverla a otro lugar :) (o a gdevelop)

Es probable que este ticket de emisión se cierre pronto, por lo que si hay algún interés en esta hoja de eventos en Godot, es posible que pronto tengamos que moverla a otro lugar :)

¿Qué? ¿Por qué?

@TheGoklayeh Es posible que esté cerrado ya que estamos migrando propuestas de características a propuestas de godot .

Dicho esto, @blurymind podría editar la primera publicación para que coincida con la plantilla de la

Realmente necesitamos un motor 3D que utilice hojas de eventos.

Gracias
apoyo esta maravillosa idea
¡Dicen que la construcción 2 se retirará!
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505

Me pregunto si es posible negociar con el desarrollador de la construcción 2 para abrir el sistema de eventos y usarlo en Godot, Unity, etc.
Es una pérdida que el sistema de eventos de construcción 2 se descuide en los estantes sin usar

Eso podría arruinar su negocio. y clickteam además.

Gracias
apoyo esta maravillosa idea
¡Dicen que la construcción 2 se retirará!
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505
Me pregunto si es posible negociar con el desarrollador de la construcción 2 para abrir el sistema de eventos y usarlo en Godot, Unity, etc.
Es una pérdida que el sistema de eventos de construcción 2 se descuide en los estantes sin usar

Eso podría arruinar su negocio. y clickteam además.

Si algo los mata, clickteam sería debido a la falta de actualizaciones de su software (la última fue en 2019), Scirra sería por obligar a sus usuarios a cambiar a una licencia de alquiler de software que los obliga a pagar todos los años u obtener bloqueado. Ambas empresas tienen fallas y su comunidad no tiene control sobre lo que sucede con el software. Aquí es donde brilla el código abierto

@TheGoklayeh Es posible que esté cerrado ya que estamos migrando propuestas de características a propuestas de godot .

Dicho esto, @blurymind podría editar la primera publicación para que coincida con la plantilla de la

¿Puede alguien hacer eso en mi lugar? :)
Perdí la esperanza de que esta característica llegue a Godot de forma nativa (no una extensión). El enfoque de espagueti se ha ganado a los usuarios y desarrolladores de Godot.

@blurymind Si ya no apoya esta propuesta, creo que es mejor cerrarla. Alguien más que esté interesado en trabajar en un enfoque de hoja de eventos podría abrir una nueva propuesta en godot-proposals . (Debido a la gran cantidad de trabajo requerido, no creo que tenga sentido abrir una propuesta si nadie es técnicamente capaz de cumplirla).

Aún así, este hilo contiene mucha discusión valiosa, así que gracias de todos modos :slightly_smiling_face:

Creo que esta propuesta es muy tonta :)
¿Pero podemos crear el sistema de eventos con el motor de construcción 3?
Creo que el juego puede generar códigos y enviarlos en un archivo de texto al motor Godot a través de node.js

Esto es ridículo... pero creo que la construcción 3 es lo suficientemente fuerte como para hacer un sistema de eventos.
Esto es mejor que nada en este momento.

Sí, espero que al menos logremos tener una idea sobre dicho sistema en Godot, sus ventajas sobre el sistema de codificación visual actual y las opiniones sobre otros motores que lo usan.

Sinceramente, me gusta cómo lo hace GDevelop, pero Godot haciendo scripts de eventos no es algo de lo que esté a favor ahora (en estos días).
Traté de implementarlo una vez, y me di cuenta de que Godot tiene una API extremadamente granular/de bajo nivel para que se exponga directamente desde un sistema Visual Scripting.
El sistema de secuencias de comandos visual actual incluido y por qué preferiría que tuviera una capa de abstracción personalizada pero que aún fuera robusto.
Tal implementación es increíblemente difícil de escribir para el script de eventos a menos que vaya con múltiples lenguajes de script de sub-eventos como DSL, donde cada uno se usa para una parte específica del motor.

Un sistema generalizado de secuencias de comandos visuales que sea simple y fácil de usar sería bastante difícil de lograr y es lo que considero un "Proyecto Unicornio".
Como el aumento de la generalización conduciría muy probablemente a un aumento mucho mayor de la complejidad de dicho sistema.

Planeo llevar Visual Scripting gradualmente hacia una dirección en la que pueda tener interfaces especializadas para todas las partes del motor.
Imagine una forma diferente de editar para cada tipo de nodo complejo primitivo, como en Blueprints, con un nodo de expresión.
https://docs.unrealengine.com/en-US/Engine/Blueprints/UserGuide/MathNode/index.html

Pero para que quede claro, no estoy en contra de las secuencias de comandos de eventos, me gustaría ver a alguien que presente una propuesta que pueda cubrir algunos sistemas específicos de Godot, y por qué y cómo puede ser útil. Personalmente, lo encuentro bastante bueno para programar comportamientos, como lo hace GDevelop.
http://wiki.compilgames.net/doku.php/gdevelop5/behaviors
http://wiki.compilgames.net/doku.php/gdevelop5/behaviors/events-based-behaviors

No lo usaré para escribir un juego adecuado, pero si tenemos comportamientos simples con los que podemos desplegarnos y jugar, lo veo como una forma bastante divertida de optimizar el proyecto para que los niños aprendan a crear juegos.
O alguien que no está acostumbrado a programar usándolo para atascos de juegos.

Aunque se puede decir lo mismo sobre VisualScript y la modularidad probablemente será mucho más fácil de lograr con él. El problema sería la unificación y la consistencia (Visual Shader y VisualScript usan bases de código completamente diferentes, y la única similitud son los nodos de interfaz de usuario utilizados).
Aún así, seguramente podemos intentar tener un sistema de secuencias de comandos de eventos como un complemento (complemento de C ++, con suerte, se vuelve fácil de hacer después de 4.0) que la comunidad puede mantener y agregar a Godot cuando sea necesario. (Estoy algo inclinado hacia un motor de juego modular)

De todos modos, eso es solo mis 2 centavos.

¿Por qué mi comentario fue marcado como fuera de tema? ¿Alguien está censurando a la comunidad, y quién? Eso no presagia nada bueno. Hay otros comentarios además del mío que están más fuera de tema.

@prominentdetail Aquí está mi mensaje de aviso

Por favor, no trate problemas sin contribuir con nueva información significativa. Use el botón de reacción :+1: en la primera publicación en su lugar.

(Desearía que GitHub tuviera una forma de enviar mensajes privados, o al menos especificar un motivo personalizado para ocultar, para no tener que ensuciar el hilo de comentarios con esto).

PD: Esta es la etiqueta típica en GitHub; no es específico de este repositorio.

Apoyo esta propuesta, pero no creo que nadie dedique tiempo a implementarla.
No cuenta con el apoyo lo suficientemente fuerte de los desarrolladores que realmente pueden hacer que suceda.

Valió la pena intentarlo y la discusión fue interesante seguro :)

@blurymind si aún apoya la propuesta y está dispuesto a tomarse el tiempo para escribirla en el formato requerido para GIP. Vale la pena hacerlo en mi opinión.

La forma en que se agregan las cosas en Godot es cuando alguien interesado en una función se toma el tiempo para implementarla. Es muy aleatorio y esporádico. Pero confiamos casi por completo en los colaboradores que deciden al azar agregar funciones.

Entonces, solo porque el conjunto actual de desarrolladores activos no se haya interesado en su propuesta, no significa que alguien no vendrá y la implementará.