Godot: Diseñador de juegos fácil de usar para no programadores

el scripting visual está planeado en algún momento

El miércoles 14 de enero de 2015 a las 6:20 a. m., RyanBram [email protected] escribió:

Hola, desarrolladores de Godot.

En primer lugar, quiero agradecerles a todos ustedes por crear un gran motor de juego.
con licencia muy permisiva. Su esfuerzo ayudará a muchos desarrolladores y
estudiantes con presupuesto ajustado para cumplir su sueño.

Con el estado actual de Godot, los juegos de código abierto tendrán un futuro más brillante.
Desafortunadamente, la mayoría de los motores de juegos de código abierto están diseñados con avanzados
pensando en el usuario con pocos conocimientos de programación. Todavía no puede llegar
un creador de juegos para principiantes.

Mi sugerencia es proporcionar un diseñador/editor de juegos fácil de usar con
Interfaz gráfica de usuario intuitiva y clase predefinida para facilitar la tarea del nuevo programador. Más
programador significa más usuario (porque el usuario de Godot son programadores de juegos).

Conozco un motor de juego que hace bien este trabajo. Está escrito desde Ruby,
originario de Japón y traducido al inglés en todo el mundo. se llama juego de rol
Hacedor VX Ace
http://www.rpgmakerweb.com/products/programs/rpg-maker-vx-ace. A pesar de
la palabra RPG delante de su nombre, es lo suficientemente capaz de crear
juego con su Ruby Game Scripting System (RGSS) incorporado.

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

La siguiente lista es un ejemplo de juegos hechos con el motor RPG Maker:

1. Aleph (Aventura RPG) http://www.pioneervalleygames.com/
2. Sin manatíes prometidos (Arcade) http://rpgmaker.net/games/5102/
3. Ragarokk - Bestiarium (Juego de cartas) http://rpgmaker.net/games/5808/
4. ¡Tierra bajo ataque! (Disparos) http://rpgmaker.net/games/6561/
5. Terra (Novela visual) http://rpgmaker.net/games/3956/
6. Memories of Mana (RPG de acción)
   http://www.atelier-rgss.com/Proyecto/Mana/Proyecto_Mana_Story.html
7. Myhos - El comienzo (Horror) http://rpgmaker.net/games/6493/

Deseo que el motor Godot se vuelva tan popular como RPG Maker, porque tiene mucho
más funciones que RPG Maker. El programador principiante solo necesita un fácil de usar
interfaz. Si fue un éxito, Okam Studio puede convertirse en el próximo GOG o Steam
que publican miles de juegos creados por desarrolladores independientes.

Saludos, Ryan

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/okamstudio/godot/issues/1220.

@RyanBram : no estoy tratando de rechazar la idea, en absoluto, aquí; probablemente podría ser útil en el futuro, pero no estoy seguro de que las secuencias de comandos visuales sean un medio efectivo de secuencias de comandos. No puedo decirlo con seguridad, pero me imagino que los juegos más complejos que publicaste probablemente estaban escritos en texto, no visualmente. Parece que el scripting visual es algo que usan los nuevos usuarios, sin duda, pero eso les retrasa en el aprendizaje de las herramientas reales que necesitarán para completar correctamente sus proyectos. Pero podría hacer que el motor fuera más accesible, así que no lo sé.

También debería ser posible para los usuarios crear un sistema de programación visual todo en Godot con GDScript en lugar de algo que debe integrarse en el motor, ¿verdad? Aunque no estoy seguro de eso.

El fabricante de juegos de rol parece tener un enfoque más de "Modding", y si Godot se parece más a un fabricante de juegos de rol, las personas que tienen intenciones de hacer diferentes tipos de juegos se alejarán. Entonces, lo que básicamente estás sugiriendo es hacer que Godot se parezca más a GameMaker (lo cual es comprensible, muchas personas quieren hacer juegos pero no saben programar), pero hay limitaciones :)
Lo que probablemente sucederá es que Godot obtendrá el editor Nodal Behavior Graph, similar a lo que tienen Leadwerks y BGE. Esto funciona muy bien con elementos GUI, el resto requeriría un poco de investigación y toneladas de comentarios de la comunidad, para que sea lo más fácil y poderoso posible.

@SolarLune , es posible crear un juego en Godot y agregar un editor en la parte superior que permita modificar el juego en cada pequeño detalle (usando GraphNodes y el resto de la interfaz de usuario, muy divertido para jugar), e incluso permitiría escribir algunos código GDscript adicional en la parte superior, creo que este es el mejor enfoque, para enviar un juego completo (RPG, FPS, RTS) por separado y permitir ajustar cada aspecto del mismo. Constructores hechos en Godot.

@SolarLune : las secuencias de comandos visuales son útiles cuando trabaja junto con un
programador, que puede hacer bloques para que los juegues. Esta
enfoque en Unreal es útil. No creo que sea posible reemplazar
programación por completo (a menos que seas masoquista), pero podría funcionar para
algunas personas también hacen bloques de plantillas para no programadores.

El miércoles 14 de enero de 2015 a las 4:23 p. m., TheoXD [email protected] escribió:

El fabricante de juegos de rol parece adoptar un enfoque más de "Modding", y si Godot lo hace
se parecen más a los creadores de juegos de rol: personas que tienen intenciones de hacer diferentes
tipo de juegos se alejarán. Entonces, lo que estás sugiriendo básicamente es
hacer que Godot se parezca más a GameMaker (lo cual es comprensible, muchas personas
quiero hacer juegos pero no sé programar) pero hay un límite :)
Lo que probablemente sucederá es que Godot obtendrá un gráfico de comportamiento nodal
editor, similar al que tienen Leadwerks y BGE. Esto funciona muy bien con
elementos GUI, el resto requeriría un poco de investigación y toneladas de comunidad
retroalimentación, para hacerlo lo más fácil y poderoso posible.

@SolarLune https://github.com/SolarLune , es posible construir un juego
en Godot y agrega un editor en la parte superior que permite modificar el juego para cada
pequeños detalles (mediante el uso de GraphNodes y el resto de la interfaz de usuario), e incluso permitiría
escriba un código GDscript adicional en la parte superior, creo que este es el mejor enfoque,
para enviar un juego completo (RPG, FPS, RTS) por separado y permitir ajustes
cada aspecto de la misma.

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-69974733 .

Bueno, por lo que sé, Godot ya tiene un código de interfaz de usuario basado en nodos (para el árbol de animación y ahora el editor de sombreado visual) que puede, en el futuro, usarse para crear un tipo de árbol 'lógico'.

Sin embargo, habrá que tener en cuenta que GDscript seguirá siendo el camino a seguir si desea la máxima flexibilidad y hacer que los nodos lógicos sean útiles requeriría un nodo de secuencia de comandos para la ejecución de GDscript (para cosas más complejas y avanzadas).

UE4 en este momento no puede hacer todo en Blueprints sin una complejidad increíble, GameMaker espera que use GML para obtener la máxima flexibilidad (mediante el uso de bloques de código), y BGE requiere secuencias de comandos en Python para obtener la máxima potencia (mediante el uso de bloques de código). No se puede descartar la utilidad de la edición visual para la creación rápida de prototipos y situaciones lógicas menos complejas, pero a menudo no puede hacer todo lo que se puede hacer en el código.

el scripting visual está planeado en algún momento

Gracias por la respuesta simple y positiva.

A todos, gracias por comentar esta sugerencia. Creo que un editor fácil y visual nunca es lo suficientemente capaz como para reemplazar la codificación manual. Sugiero esta función como complemento para la codificación regular, no para reemplazar su posición.

En RPG Maker VX Ace, la mayoría de las funciones avanzadas se codifican a mano. Los programadores avanzados generalmente proporcionan un script de modding avanzado cuyo valor puede ser editado en el Editor GUI por un usuario ocasional (nombre del personaje, habilidad, retrato, sprite, etc.). El sistema Ruby Game Scripting hace posible la aplicación de parches mono. Esta es la razón por la que la mayoría de las secuencias de comandos proporcionadas por usuarios avanzados no reemplazarán la clase predefinida original de los desarrolladores de RPG Maker para evitar problemas de compatibilidad.

Para comparacion:
Los proyectos de KDE y GNOME nunca pretenden reemplazar los poderosos comandos de Shell en Linux, sino que los proyectos solo intentan llenar el vacío entre la facilidad de uso y el poder de Linux.

Sonreí sobre la idea de que Okam Studio fuera como Steam... :))

El 14/1/2015 a las 17:20, RyanBram escribió:

Hola, desarrolladores de Godot.

En primer lugar, quiero agradecerles a todos ustedes por crear un gran juego.
motor con licencia muy permisiva. Tu esfuerzo ayudará a muchos
desarrolladores y estudiantes con presupuesto ajustado para cumplir su sueño.

Con el estado actual de Godot, los juegos de código abierto serán más brillantes
futuro. Lamentablemente, la mayor parte del motor de juego de código abierto está diseñado
pensando en usuarios avanzados con pocos conocimientos de programación. Eso
todavía no puede llegar a un creador de juegos para principiantes.

Mi sugerencia es proporcionar un diseñador/editor de juegos fácil de usar con
Interfaz gráfica de usuario intuitiva y clase predefinida para facilitar la tarea del nuevo programador.
Más programador significa más usuario (porque el usuario de Godot son programadores de juegos).

Conozco un motor de juego que hace bien este trabajo. Está escrito desde Ruby,
originario de Japón y traducido al inglés en todo el mundo. Está
llamado RPG Maker VX Ace
http://www.rpgmakerweb.com/products/programs/rpg-maker-vx-ace.
A pesar de la palabra RPG delante de su nombre, es lo suficientemente capaz de
cree juegos que no sean RPG con su Ruby Game Scripting System (RGSS) incorporado.

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

La siguiente lista es un ejemplo de juegos hechos con el motor RPG Maker:

1. Aleph (Aventura RPG) http://www.pioneervalleygames.com/
2. Sin manatíes prometidos (Arcade) http://rpgmaker.net/games/5102/
3. Ragarokk - Bestiarium (Juego de cartas) http://rpgmaker.net/games/5808/
4. ¡Tierra bajo ataque! (Disparos) http://rpgmaker.net/games/6561/
5. Terra (Novela visual) http://rpgmaker.net/games/3956/
6. Memories of Mana (RPG de acción)
   http://www.atelier-rgss.com/Proyecto/Mana/Proyecto_Mana_Story.html
7. Myhos - El comienzo (Horror) http://rpgmaker.net/games/6493/

Deseo que el motor Godot se vuelva tan popular como RPG Maker, porque tiene
muchas más funciones que RPG Maker. El programador principiante solo necesita un
interfaz fácil de usar. Si fue un éxito, el estudio Okam puede convertirse en el próximo
GOG o Steam que publican miles de juegos creados por desarrolladores independientes.

Saludos, Ryan

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/okamstudio/godot/issues/1220.

Unreal en realidad tiene plantillas para proyectos, ya sea que desee hacer un
secuencias de comandos visuales o un tipo de flujo de trabajo de secuencias de comandos completo... e incluso el
Se puede acceder a los bloques de código para la edición visual a través de Visual Studio y ser
personalizado... :)

El 15/01/2015 a las 03:44, Juan Linietsky escribió:

@SolarLune : las secuencias de comandos visuales son útiles cuando trabaja junto con un
programador, que puede hacer bloques para que los juegues.
Esta
enfoque en Unreal es útil. No creo que sea posible reemplazar
programación por completo (a menos que seas masoquista), pero podría funcionar para
algunas personas también hacen bloques de plantillas para no programadores.

El miércoles 14 de enero de 2015 a las 4:23 p. m., TheoXD [email protected] escribió:

El fabricante de juegos de rol parece adoptar un enfoque más de "Modding", y si Godot lo hace
se parecen más a los creadores de juegos de rol: personas que tienen intenciones de hacer diferentes
tipo de juegos se alejarán. Entonces, lo que estás sugiriendo básicamente es
hacer que Godot se parezca más a GameMaker (lo cual es comprensible, muchos
personas
quiero hacer juegos pero no sé programar) pero hay un límite :)
Lo que probablemente sucederá es que Godot obtendrá un gráfico de comportamiento nodal
editor, similar al que tienen Leadwerks y BGE. esto funciona muy bien
con
elementos GUI, el resto requeriría algo de investigación y toneladas de
comunidad
retroalimentación, para hacerlo lo más fácil y poderoso posible.

@SolarLune https://github.com/SolarLune , es posible construir un juego
en Godot y agrega un editor en la parte superior que permite modificar el juego para cada
pequeños detalles (mediante el uso de GraphNodes y el resto de la interfaz de usuario), e incluso
permitir
escriba un código GDscript adicional en la parte superior, creo que este es el mejor
Acercarse,
enviar un juego completo (RPG, FPS, RTS) por separado y permitir
ajustando
cada aspecto de la misma.

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-69974733 .

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-69978224 .

Sonreí sobre la idea de que Okam Studio fuera como Steam... :))

También sonreí de manera positiva.
Porque sería genial para mí como jugador si hubiera una empresa tan grande como Steam con toneladas de catálogo de juegos, abiertos y libres de DRM, creados por miles de grandes desarrolladores de juegos.

Unreal en realidad tiene plantillas para proyectos, ya sea que desee hacer un
secuencias de comandos visuales o un tipo de flujo de trabajo de secuencias de comandos completo... e incluso el
Se puede acceder a los bloques de código para la edición visual a través de Visual Studio y ser
personalizado... :)

Genial si estará disponible en Godot.

Saludos,
Ryan

Hola Ryan

¿Has probado Construct 2? Es uno de mis diseñadores de juegos visuales favoritos y extremadamente simple de usar.

La programación visual en Godot, creo que será algo difícil de hacer (como Godot hace tanto 2d como 3d, el alcance es mucho más grande).
Además, es probable que se integre mucho más tarde, cuando todos los bloques subyacentes del motor estén en su lugar.

Sé que reduz tiene su propia hoja de ruta para esto, pero espero que no priorice esto sobre otras actualizaciones del editor/motor. Prefiero que Godot sea utilizado por programadores principiantes o semi competentes que por no programadores. Pero así soy yo.

Hola Ryan

¿Has probado Construct 2? Es uno de mis diseñadores de juegos visuales favoritos y extremadamente simple de usar.

Probé Construct 2. Es agradable y asombroso. Los juegos resultantes también son multiplataforma, por lo que es una gran ventaja. Desafortunadamente, todavía no puedo encontrar ningún tutorial para crear juegos RPG fácilmente. Por ahora, puedo quedarme con RPG Maker VX Ace e intentar portar mi juego a muchas plataformas (incluido Android) con la ayuda de MKXP Project .

Gracias por compartir. Espero con ansias la programación visual en Godot.

Atentamente,
Ryan

Para el enfoque de secuencias de comandos visuales, puede tomar notas de gdevelop, fusión multimedia y construcción 2. Esos motores se basan 100% en secuencias de comandos visuales. Todavía necesita aprender algo de sintaxis donde se necesitan expresiones, pero el editor de expresiones hace que sea extremadamente fácil encontrar los comandos correctos. Estos tres motores le brindan la libertad de crear cualquier tipo de juego con secuencias de comandos visuales, a diferencia del creador de juegos y el creador de juegos de rol.

Rpg maker no es realmente un buen ejemplo, ya que es extremadamente limitado.
Las secuencias de comandos basadas en nodos son muy ineficientes en términos de uso del espacio: se desplazará y acercará y alejará a través de un gráfico de nodo gigante. Compare eso con el constructo 2, donde todo se presenta de manera clara y es claro y fácil de leer, y obtuvo un ganador.

BGE es probablemente el peor ejemplo aquí, ya que intenta combinar un enfoque basado en nodos con bloques lógicos. Escribí sobre por qué esto es malo:
http://blenderartists.org/forum/showthread.php?323905-comparing-BGE-logic-bricks-with-Scirra-Construct-event-sheet-for-prototyping

Si realiza secuencias de comandos visuales, no lo haga a medias con un editor genérico basado en nodos. Si desea que más personas que no sean programadores usen su motor, haga algo con un mejor diseño, como construct2 o multimedia fusion.

Me gustaría ver algo como esto implementado _solo_ como una forma secundaria de programación. Las secuencias de comandos visuales, a diferencia del código, ralentizan la productividad en un orden de magnitud bastante grande. También tiende a hacer que la depuración y la refactorización sean mucho más difíciles. La única ventaja importante que se me ocurre (además de que es atractiva para los que no son programadores) es que las secuencias de comandos visuales tienden a ser una gran herramienta de enseñanza si pudiera generar, o al menos mostrar, código GDScript real (IE. code. org). No creo que tenga que ser al revés (IE. GDScript a Visual). Creo que esta sería una excelente manera para que las escuelas adopten a Godot en sus clases.

Aquí hay dos diferencias principales entre el código y las secuencias de comandos visuales que creo que son las más importantes en cuanto a la accesibilidad. Esto viene de alguien que no tocará las secuencias de comandos visuales con un poste de diez pies, pero entiendo que atrae a algunas personas :)

Código: el código tiende a tener reglas de sintaxis específicas que deben seguirse. Supongo que esto tiende a ser lo principal que apaga a los no programadores. ES DECIR. en GDScript debe tener dos puntos al final de la declaración de una función, bucles if, for, while, etc. Debe sangrar correctamente. Debe usar la palabra clave var al declarar una variable como "var myInteger = 1". Para la mayoría de los idiomas, tiende a haber alrededor de 3 o 4 reglas de sintaxis primarias que tienden a seguirse y, en mi opinión, no son tan difíciles de aprender. Después de escribir un puñado de pequeños guiones, incluso un artista puede aprenderlos. Digo esto porque trabajo con dos artistas muy talentosos que trabajaron en los tres juegos de Age of Empires con Ensemble Studios. Uno ha escrito bastante código en UnityScript y el otro ahora ha escrito una tonelada de código en C#.

Visual: tiende a obtener un menú desplegable para el método, la variable, la declaración, etc. Sin embargo, aún debe saber qué funciones, propiedades, etc. está buscando y qué hacen e incluso, a veces, cómo funcionan. Aún debe resolver el problema. Aún debe usar variables y realizar un seguimiento de lo que están haciendo a lo largo de su secuencia de comandos. Todavía puede tener errores lógicos tan fácilmente como escribir código.

Creo que ser capaz de escribir el código es, en última instancia, una forma muy superior de avanzar desde el punto de vista de la productividad. Sin embargo, ninguno de los dos te hará mejor/peor programador. Creo que las secuencias de comandos visuales son una muy buena herramienta de enseñanza, pero si no sabes (o no quieres aprender) cómo estructurar las cosas correctamente y, especialmente, cómo resolver problemas, las secuencias de comandos visuales no te ayudarán ni un poco.

Yo tomaría un enfoque ligeramente diferente. Dado que el editor de godot se controla a sí mismo, es fácil recrear una interfaz de editor similar en GDscript puro.

Así que mi propuesta sería hacer un constructor escrito completamente en Godot y enviarlo por separado. Esto permitiría a programadores y no programadores trabajar en el mismo proyecto mientras usan diferentes herramientas. El único problema es que los no programadores a veces tendrán que lidiar con ambas herramientas al mismo tiempo, pero bueno, he visto cosas peores xD Gridmap editor, shader editor, animation editor, code editor - se pueden recrear, mientras que el importador collada, convexo generador, exportadores - no tan fácilmente. Todavía se siente como reinventar la rueda, pero puede simplificar muchas cosas.

El núcleo de constructor podría adoptarse para cualquier género de juego (FPS, RTS, GPS...) con contenido descargable y otras cosas, y si se mantiene en la comunidad, será más fácil contribuir, porque todo es GDscript.
No es probable que haya secuencias de comandos visuales en Godot en el corto plazo, pero eso no impide que otros creen un constructor encima. He visto a alguien tomar Blender 2.5 e hizo una herramienta para diseñar interiores.

Creo que tener varios editores podría fragmentar el desarrollo de Godot. Debe haber un proyecto central bien diseñado para una herramienta de secuencias de comandos visuales que se base en gdscript.

No seas perezoso y haz tu investigación. Mire otros motores de secuencias de comandos puramente visuales. Compara su base de usuarios (qué tan populares son), compara qué tan flexibles son, los tipos de juegos que se crearon con ellos, ya sea en Kickstarter, Steam u otras plataformas.
Mire su enfoque de diseño.

Luego diséñalo en papel. No se limite a copiar el enfoque de nodo. Usar nodos para sombreadores está bien, pero cuando llega a la lógica, terminas con un gran lío para desplazarte e intentar averiguarlo.

confía en mí, lo intenté todo. Creador de juegos de Unity, Kismet de Unreal, creador de juegos de rol, stencyl, etc., etc.
Construct2 viene a la cabeza, junto con la fusión multimedia. Esos son los más populares, con el enfoque más flexible. Y ambos tienen una tienda de mercado de activos.
Son extremadamente flexibles y, si observas los juegos creados con ellos, hay una gran variedad de géneros.

Si te vuelves aún más inteligente al respecto, podrías asociarte con Gdevelop, otro proyecto de código abierto que ya tiene un editor de secuencias de comandos visuales que crea juegos html5.
Mire en su diseño y código fuente.

Si tuviéramos que votar en este hilo, estoy bastante seguro de que sería el lugar completamente equivocado porque principalmente los programadores se presentarían para votar.

Un sistema de secuencias de comandos visuales debe diseñarse para artistas, no para programadores. Por mucho que pueda quejarme de mi absoluto disgusto por cosas como PlayMaker en Unity, la verdad es que a los artistas les encanta. Por eso tiene casi 2000 reseñas y tiene 5 estrellas. Si el voto es tener algo más parecido a las secuencias de comandos de Construct 2, entonces mi voto es no tener secuencias de comandos visuales en absoluto, ya que no creo que sea de ningún beneficio real ya que A) Los programadores pueden programar directamente en GDScript y B) Muchos artistas se apagará instantáneamente y simplemente se irá a otro lado. Lo sé porque mis dos amigos artistas, que saben programar, estaban mirando Construct 2 y burlándose de la interfaz de programación que tiene, ya que es casi lo mismo que escribir código.

Un lenguaje de secuencias de comandos visual debe ser muy visual, no muchas palabras. No debería parecer código a primera vista. Debe adaptarse a las "personas visuales", de lo contrario, no tiene sentido hacerlo en primer lugar. Los artistas están acostumbrados a los gráficos de nodos, y tienden a gustarles, ya que les dan una idea visual de lo que está haciendo su programa. Nuevamente, no me gustan los gráficos de nodos porque no los soporto, pero soy programador y mi voto realmente no debería contar en esta área.

Estoy de acuerdo contigo en que debería estar diseñado para artistas/diseñadores.
Pero no estoy de acuerdo con la lógica de que las palabras = complejidad.

Si sienta a alguien para enseñarle a usar uno de los dos, construct2 aparecerá como el más fácil de los dos. ¿Por qué?
Porque es más claro que los nodos. Mucho más claro. Tienes condiciones y acciones. Pones el primero en el lado izquierdo y el otro en el lado derecho.
Para agregar cualquiera de los dos, no es necesario que conozca los comandos. Todos están enumerados allí para que los agregue, claro como un día. Cada uno viene con un icono, que es una pista visual.

Playmaker y otros sistemas basados ​​en nodos requieren mucho más aprendizaje, porque conectar un nodo a otro requiere que primero entiendas si puedes conectar los dos. No es simplemente condición--> acción. Los nodos son mucho más complejos y carecen de sugerencias visuales. ¿Dónde viste los íconos en Playmaker?
Es mucho más fácil cometer un error en él. Es mucho más difícil leer la lógica en él.
https://www.scirra.com/tutorials/top
También diría que debido a que C2 es una herramienta de programación visual mejor diseñada, tiene una comunidad de usuarios activos mucho más grande que la de Playmaker, aunque en este momento está limitada a juegos 2D. Una cantidad mucho mayor de tutoriales en video en la web (más personas entienden cómo usarlo que el creador de juegos), proyectos mucho más completos, un mercado y un foro activos y saludables, y sobre todo una comunicación activa entre desarrolladores y usuarios. Para que los desarrolladores sepan lo que quieren los usuarios artistas.

Los usuarios de Construct pueden simplemente tomar una captura de pantalla de su hoja de eventos y está claro como el día en que lo hicieron. Ir a los foros ver por ti mismo. Yo diría que tiene muchos más usuarios que Playmaker.

Yo diría que se necesita menos trabajo para configurar la lógica que en cualquier sistema basado en nodos.

Puedo ver que te gustan, pero al menos intenta construir2 antes de declarar que es el motor de un programador.
Mire su foro y su base de usuarios. Tiene tanto, si no más, buena reputación que el mediapunta. Se las arregló para obtener esa buena reputación al estar bien diseñado, por sí solo, no al ser un complemento para un motor ya exitoso. Es una herramienta de programación visual pura que cualquier artista puede usar. Soy un artista y probé playmaker, es más difícil que construir2. Vaya al foro de C2 e intente convencerlos de que el creador de jugadas es más fácil de usar, solo para reírse. :D
¿No eres tú mismo un programador? Has contribuido a los proyectos de github más que yo. ¿No significa eso que no debería hacer la declaración que es más fácil de aprender?

Entiendo tus puntos desde la perspectiva de un programador. Si tuviera que elegir entre los dos, también elegiría el modelo Construct. Sin embargo, como dije, este es el peor lugar para tomar esta decisión porque probablemente la mayoría, si no todas, las personas que leen las listas de correo de GitHub son programadores.

He pasado más de mi carrera con artistas que con programadores. Si bien he hecho ambas cosas regularmente durante los últimos 18 años (y me apasionan ambas), fui artista profesional antes de ser programador profesional. No es que me importe que tenga un título, mi título es en Animación Digital y Efectos Visuales. Que yo sepa, los comerciales en los que trabajé todavía se reproducen después de varios años en Kansas City. He trabajado en tomas para Hallmark, Sprint, Radio Shack, Honda y algunos otros que probablemente me estoy olvidando. También me divertí mucho trabajando en algunas tomas de "World Builder" con Bruce Branit.

https://www.youtube.com/watch?v=QP3YywgRx5A
Nathan Warden en los créditos soy yo

No digo esto para presumir, lo digo para demostrar algo. Podría estar equivocado, pero como artista que ha pasado mucho tiempo con artistas, creo que sé lo que les gusta a los artistas. No suelen gustarles mucho cosas como Constructor. Tienden a sentirse intimidados y eligen una aplicación completamente diferente. Los artistas en general tienen una mentalidad muy diferente a la de los programadores. Es como cuando hablo con mi amigo Erik sobre las cosas técnicas que estoy tratando de enseñarle, estas palabras salen de su boca con bastante frecuencia: "Nate, soy una persona muy visual, si no puedes mostrármelo visualmente podrías estar hablando con la pared".

Hay una razón por la que los artistas disfrutan cosas como los gráficos de sombreado basados ​​en nodos en lugar de los sistemas de sombreado lineal. Pueden visualizar lo que está pasando. No creo haber escuchado nunca a un artista quejarse de no tener un sistema de sombreado lineal en su aplicación 3D favorita, pero se quejan regularmente cuando no tienen un sistema de sombreado basado en nodos.

Hay una razón por la que los artistas prefieren aplicaciones como Fusion a After Effects. En casi todos los casos, elegirán algo basado en nodos en lugar de lineal porque es más visual.

Entonces, 2 razones más por las que un sistema basado en nodos atraerá a los artistas:

1) Visualmente se ven mucho más atractivos.
2) Se ajusta al paradigma de diseño al que ya están acostumbrados. Sombreado y composición de IE

Eso es realmente a lo que se reduce. Si el artista va a echar un vistazo y pasar al siguiente motor de juego porque el otro tiene programación basada en nodos, entonces Godot no debería tener scripts visuales en absoluto, porque probablemente no habrá más que un puñado de personas. quién lo usará y solo significa más mantenimiento de código a partir de ese momento.

¿Seguro que tienes alguna idea de lo que es Construct2? Ni siquiera estás escribiendo su nombre correctamente.
No se llama "Constructor".

Estoy completamente en desacuerdo con que deberíamos ir con nodos porque "no debería parecer un código a primera vista".

Es más importante cuán claro es que cómo se ve. La claridad de lo que hace la lógica es más importante que la apariencia del editor a primera vista. Construct2 no parece un código: el texto está escrito en inglés simple y es obvio lo que hace una Acción o una Condición. Las personas que usan C2 tienden a ser en su mayoría personas visuales también.

Una hoja de eventos siempre ganará contra los nodos, independientemente de cómo intente que se vea. Puede empaquetar más información en la pantalla con menos movimiento panorámico: es más obvio lo que hace la lógica. Y las señales visuales (iconos) son mucho más fáciles de encontrar por el ojo del artista.
Los nodos no tienen íconos y tienen una gran limitación de texto.
Entonces, en muchos casos, un nodo ni siquiera describe claramente lo que hace, debido a lo limitado que es en tamaño, lo que obliga al diseño a usar terminología oscura en lugar de un lenguaje sencillo.

Otro punto:
Una hoja de eventos se lee y ejecuta de arriba a abajo. Esto es obvio y predecible.
Con una red de nodos, tus ojos viajarán por todo el lugar, se dividirán en ramas. Se vuelve mucho más complicado.

Las historias de opinión en tercera persona sobre los primeros vistazos y no la experiencia real del usuario no deberían tener ningún peso aquí. También soy una persona muy visual, pero que ya ha usado muchos motores de secuencias de comandos visuales. Es un verdadero dolor de cabeza ver a la gente discutir sin usar los motores reales durante un tiempo, por ejemplo, con un proyecto pequeño.

Insto a los diseñadores/desarrolladores/personas visuales de Godot a que prueben estos motores en un proyecto a pequeña escala y luego lleguen a conclusiones. Basta de estas historias de terceros. Necesitamos una investigación práctica y un caso lógicamente establecido de por qué uno es mejor que el otro. Lo creas o no, las personas visuales también tienen algo de sentido común.

Sin relación:
En el ejemplo de Fusion vs Aftereffects, las personas prefieren un enfoque basado en nodos para la composición, porque el uso de capas puede volverse muy engorroso en una escena complicada donde el mismo efecto se puede duplicar en muchas capas. Con los nodos, puede tener más flexibilidad en términos de composición y simplemente conectar un efecto a muchas capas. Pero los nodos son más complicados que las capas.

Estoy de acuerdo contigo en casi todos los puntos, pero esos puntos siguen siendo desde la perspectiva de un programador. Si tuviera que usar un sistema de secuencias de comandos visuales todo el día, elegiría el que se parece más al código normal. Es por eso que soy un gran fanático de enseñar a los niños que quieren aprender a programar usando code.org. Soy realmente un gran admirador del estilo. Es bueno para enseñar a las personas que "quieren" programar cómo programar.

Y sí, dije Construir mal, lo siento. No, personalmente no lo he usado. Sin embargo, no importa porque el paradigma de secuencias de comandos que utiliza no es un concepto nuevo en ningún sentido de la imaginación, por lo que mi argumento ni siquiera se trata de Construct en sí. Se trata de ese estilo de secuencias de comandos en lo que respecta a los artistas, no a los programadores.

En un sistema basado en nodos, puede tener varias condiciones, eventos y funciones contenidas dentro de cada nodo. A continuación, puede nombrar el nodo como Entrada, por ejemplo. En su interior contendrá todas las entradas del joystick y el usuario le dirá qué evento usar. ES DECIR. especificarían un evento como "Fuego". Ese evento causaría una transición al nodo al que lo conectaron.

Aquí hay un ejemplo simple que podría tener en un arma que simplemente manejaría el disparo. Tenga en cuenta que si bien es simple, también es poderoso y no se parece en nada a un código:

En una nota final, puede hacer que las secuencias de comandos basadas en bloques o las secuencias de comandos basadas en nodos se vean bastante bien desde el punto de vista de la interfaz, por lo que no perderé el tiempo discutiendo ese punto.

Sin embargo, cuando dije "No debería parecer un código a primera vista". Muchos artistas se preocupan por lo que van a mirar todo el día, todos los días, durante un período de tiempo indefinido. Rechazarán una aplicación completa si no parece atractiva o si parece intimidante. Yo diría que la base de bloques parece intimidante y confusa para un artista típico. Parece algo para programadores, y lo es.

@blurymind ,

Los nodos gráficos en realidad provienen de UML conceptual. Usted hace una representación gráfica del código de una manera que la audiencia que no programa (gestores de proyecto, consumidores, artistas) pueda entender. Esto es lo que usa UE4/Unity. Esto es algo de lo que todos en la industria son conscientes. Los constructores suelen adoptar un enfoque diferente, y lo bueno que es este enfoque no se define por la cantidad de usuarios que lo usan.

Siempre hay una curva de aprendizaje en todas partes, y Construct2 no es una excepción. Pero no fuercemos cosas de C2 en Godot sin respaldar los argumentos. La hoja de eventos será más larga con juegos más complejos y terminará desperdiciando más espacio que los nodos gráficos. Solo el botón "Agregar acción" tiene su propia fila. Es básicamente cómo un programador interpretaría un bloque de código. Así que no es tan malo.

Personalmente, no veo por qué no podemos tener ambos, pero los desarrolladores ya tienen suficiente para hacer, por lo que no sucederá pronto. Es por eso que propuse un enfoque diferente que evolucionará más rápido, más o menos impulsado por no programadores en cooperación con programadores.

Aquí hay un mejor ejemplo para mostrar que puede tener más de un evento por nodo. También tenga en cuenta que cada nodo (o estado) no bloquea, por lo que permitirá que otros gráficos de nodos se ejecuten simultáneamente:

Pero mira, con solo mirar tu captura de pantalla no tengo idea de qué hace esa lógica. ¿Qué diablos es "firePrimary" y "fireSecondary"?
Ahora desplácese hacia arriba hasta la captura de pantalla que publiqué de construct2.
En construct2, la condición de la izquierda se leerá "en "R" presionada" o algo que está en inglés simple y corto, ¡con un ícono de teclado al lado!

Muéstreselos a un artista y pregúntele cuál es más claro.

Muéstranos también una configuración de nodo más elaborada :) La captura de pantalla de C2 muestra la lógica completa del juego. El tuyo es sólo un evento. ¿Puedes encajar la misma lógica en una captura de pantalla con nodos? No lo creo.

Ver el ejemplo de nodo está oscureciendo la información.
Tienes que seleccionar un nodo para ver lo que está configurado dentro de él.
Está utilizando terminología de programador oscura en lugar de lenguaje humano ("Enviar evento", "Almacenar resultados", ¿qué demonios?).
Construct2 muestra todo en un solo lugar y es comprensible para los que no son programadores. El objetivo de la programación visual es deshacerse de la necesidad de aprender terminología.

No soy programador. No tengo ninguna experiencia en la escritura de código real. Sin embargo, puedo hacer un juego con construct2 fácilmente y para mí usar nodos es mucho más difícil, cuando se trata de un juego completo.

Entiendo que todos siempre votarán por lo que ya saben hacer bien. Pero como admitió, usted es un programador y en realidad no ha usado C2. Y mantengo la declaración de que soy un artista sin experiencia en codificación, que ha utilizado tanto los nodos como el enfoque C2.

Te estoy dando buenos argumentos lógicos sobre por qué usar uno sobre el otro.
Me estás dando declaraciones como "los nodos son más visuales" y "nodos de usos irreales". Esas son declaraciones de opinión. Y ambos admiten ser programadores.

Decir que no estoy respaldando mis argumentos es solo una confirmación de que no desea investigar construct2 o considerar su diseño como una alternativa a los nodos. Lamentablemente, es una pérdida de tiempo convencerte de lo contrario.

@TheoXD
Estoy bastante de acuerdo contigo si te estoy leyendo bien. Sería bueno tener ambos como complemento/módulo por separado. Entonces, debajo estaría GDScript real, pero podrías visualizarlo usando lo que quieras. Creo que esto es posible. El enfoque basado en nodos puede necesitar algunos indicadores como comentarios especiales para separar los nodos (es decir, #node name="Input" y #endnode), pero no es tan importante ya que sería automático si comenzara con el gráfico de nodos. Creo que el enfoque de bloque sería sencillo.

¿Es algo así lo que quisiste decir?

Como dije anteriormente, me gusta mucho el método block/Construct/code.org ya que funciona muy bien para enseñar programación. Simplemente no creo que sea una buena opción para las personas que ven la programación como un mal necesario.

@blurymind
La razón por la que no tiene sentido es porque no estás familiarizado con él. Cuando miro la imagen de Construir arriba, tampoco tengo idea de lo que está pasando, no porque sea malo, sino porque no estoy familiarizado con él.

En cuanto a no poder ver lo que hay debajo de un nodo hasta que haga clic en él, una vez que haya configurado un nodo, no tiene sentido examinar lo que ya sabe que está allí. Ya sé que tengo clic izquierdo y derecho y que disparan munición primaria y secundaria. Ya sé lo que hacen los nodos de fuego primario y secundario. No ha cambiado desde que lo hice, ¿por qué tengo que ver los detalles cada vez que lo miro? Entonces, ahora la lógica subyacente es solo desorden. Esta es otra razón por la que los nodos son más amigables para artistas y no programadores. Pueden dividir su lógica específica en partes más generales. Lo hace para que puedan obtener una vista general y solo preocuparse por los detalles cuando sea absolutamente necesario.

Estoy viendo un proyecto real para un juego móvil publicado en este momento y casi todos los gráficos de nodos tienen de 2 a 4 nodos como máximo, por lo que es difícil mostrarle una configuración más elaborada cuando normalmente no necesita una configuración elaborada.

Si quieres más detalles, esto es de la misma aplicación que fue escrita por una persona que no es programadora. Este es uno de los gráficos más complejos del juego. Controla el movimiento del jugador principal:

(Esa es otra cosa que no puedes hacer con los bloques es que se vean como la nave de Samus, jaja)

Sin ninguna indicación, solo puse la imagen de Construct2 en una pantalla y puse el gráfico de nodo anterior en la otra y le pregunté a mi esposa (que definitivamente no es programadora): "¿Cuál te gustaría usar si tuvieras que usarlo?" todos los días?", y señaló el gráfico de nodos y dijo: "Este". Sé que eso no es definitivo, pero el hecho de que sea menos intimidante significa que tengo muchas más posibilidades de comenzar a hacer que ella lo aprenda. Si parece intimidante, es posible que apague su cerebro antes de que yo haga que se siente para aprender los conceptos básicos.

Sin empujarlo hacia uno u otro, ayer también le pregunté a mi amigo artista (el mismo que trabajó en los tres juegos de Age of Empires), que ha estado en la industria de los juegos durante casi 20 años (y que ha usado Construct2) lo que cree que preferirían otros artistas y también dijo el gráfico de nodos.

De todos modos, realmente disfruto la discusión, pero no tiene sentido vencer a un caballo muerto, jaja :)

Sí, yo también lo disfruto. Sin malos sentimientos :)

Impresionante Samus Ship por cierto. Cuantas más imágenes publiques, más apoyarás mi caso de que los nodos son visualmente más difíciles de seguir, ya que pueden dividirse en ramas e ir en direcciones locas.
Para mí, la complejidad añadida de tener que seguir líneas y flechas entre bloques siempre me ha parecido un trabajo extra. Supongo que debería darle a los nodos otra oportunidad uno de estos días. Si es hacia donde se dirigirá Godot.

Nuevamente, nos está dando historias en tercera persona que no están realmente respaldadas por evidencia. Consigue al tipo aquí y haz que nos diga POR QUÉ prefiere uno sobre el otro :)
Entonces tendrás un caso más fuerte. No estoy obteniendo ningún punto lógicamente sano que respalde la tesis de que los nodos son más sencillos hasta ahora.

sí, parece menos intimidante a primera vista porque oculta mucha información. Sus ejemplos son mucho más simples que lo que se muestra en la captura de pantalla que publiqué. Esto es engañoso.
Aquí hay un video que muestra cómo configurar la lógica para un juego de plataformas en C2.
https://www.youtube.com/watch?v=5RlSmkSbleI
saltar el primer minuto :P

No comparemos manzanas con naranjas.
Code.org es un enfoque radicalmente diferente de Construct2: se parece más a Stencyl y tiene una de las desventajas de los nodos: sus condiciones y acciones no están claramente separadas, por lo que es más difícil averiguar qué puede adjuntar a qué. Herramientas de programación visual bien diseñadas (Multimedia fusion, construct2, gamedevelop) todas las condiciones separadas de las acciones claramente para el usuario. Esto hace que sea mucho más fácil construir la lógica, ya que el software los organiza para usted y adivina lo que podría necesitar y se lo muestra en el momento adecuado. también le impide cometer errores tontos.

Con nodes/stencyl/code.org tienes que averiguar qué pieza es una condición, cuál es una acción. Se necesita más información para configurar las condiciones de la manera correcta. ¿Qué tipo de información sale de un nodo? Algunas veces se necesitan más nodos para configurar una condición, más aprender a conectarlos.
Vamos, investiga y usa las otras herramientas por un momento. Ver todos los que no son nodos como más de lo mismo no ayuda.

@blurymind , su caso está respaldado hasta ahora por la cantidad de usuarios que usan Construct2, que generalmente es el resultado del modelo comercial del software y lo buenos que son en marketing. La preferencia personal (sus argumentos lógicos) no es suficiente para forzar el flujo de trabajo de C2 en Godot. Pero es una buena referencia.

Si le mostraras a alguien cómo te gustaría construir tu juego (relación objeto-objeto) en papel o pizarra, ¿cómo se lo mostrarías? ¿Escribiendo un árbol de eventos? No. Dibujaría una vista conceptual con nodos y líneas, luego pensaría en ellos como clases, agregaría funciones, miembros...
Estoy de acuerdo en que la tabla de eventos se parece más a un código, solo interpretado por un programador, y puede hacer que los usuarios quieran aprender programación real a medida que avanzan. He notado que también tiene cierta terminología y curva de aprendizaje, no puedes negarlo. Pero el reconocimiento de formas y la agrupación de objetos es algo real. Estudio un curso sobre visualización de datos y, además de lo aburrido que puede llegar a ser, en realidad tiene buenos puntos.

Por mucho que me gustaría ver que este problema obtenga más de 100 comentarios, los desarrolladores no los leerán todos, lo mejor que cada uno de nosotros puede hacer es crear un PDF con propuestas y compartirlas en la lista de correo. No veo por qué no podemos tener diferentes niveles de abstracción, nodos gráficos como nivel superior, que se pueden representar en forma de un árbol de eventos. Si esto funciona, entonces no habrá necesidad de comprometerse.

" @blurymind -- || -- Y ambos admiten ser programadores". - No me considero solo un programador, también hago arte, ¿sabes? Uso mi experiencia para mirar las cosas desde un punto de vista objetivo.

No estoy seguro de si se lo perdió, pero tampoco soy solo un programador, sino también un artista profesional. Creo que la mayoría de los programadores realmente se beneficiarían saltando al arte por un tiempo. Hace que programar ciertas cosas tenga mucho más sentido y también ayuda a salvar la rivalidad entre programador y artista, jaja :) Sé que esto es más ideal y no tan práctico para la mayoría de la gente.

Aquí hay algunos enlaces a algunos de mis trabajos (busque a Nathan Warden en los créditos)

World Builder (involucrado en aproximadamente la mitad de las tomas)
https://www.youtube.com/watch?v=VzFpg271sm8

Teddy Scares (participó en la mayoría de las tomas)
https://www.youtube.com/watch?v=qCXIzS_iY0k

Hallmark Crown Center (El tercer tiro con Santa)
https://www.youtube.com/watch?v=biqBq3_Whqk

Aquí hay una representación del edificio de mi Louie. Si miras World Builder, verás algunas de las ilustraciones que extraje y puse en la película.

Y aquí hay una representación inacabada de un tanque HK estilo Terminator 1 aplastando a Christine de Stephen King. Ambos modelos están hechos por mí, pero no creo que haya nada más en la toma.

Y muchos más que podría nombrar, pero creo que el punto está hecho. :)

Bueno, esas son imágenes fijas increíbles, pero nuevamente estás haciendo esto para darte más autoridad. Esto no ayuda a respaldar lógicamente la idea de que los nodos son mejores que la hoja de eventos :)

Si vas con nodos, serás como cualquier otro maldito motor de juego 3D que use programación visual.

Creo que esta no es una gran idea por varias razones.

-Recientemente, Unreal hizo que su motor fuera gratuito, también es multiplataforma. Es un motor mucho más maduro que BGE/Godot. Entonces estás compitiendo con ellos directamente al copiar su enfoque de la programación visual.

-Los nodos son mucho menos eficientes en pantalla que una hoja lógica. Son más difíciles de leer/seguir.

-Scirra anunció que construct3 será multiplataforma: el editor funcionará en Windows, Linux y Mac.
Sin embargo, no son de código abierto.
https://www.construct3.com/

Esto creó una ola de comentarios en la comunidad scirra. Muchos de los usuarios quieren una serie de cosas que Godot puede ofrecer sin la programación visual:
-Archivos exe nativos en lugar de contenedores html5 - para un mejor rendimiento
-soporte para el desarrollo de juegos en 3D, utilizando el estilo de hoja de eventos en construcción para programarlo:
https://www.scirra.com/forum/construct-3_t90881

si hacen un editor 3D simple y comprensible como la herramienta 2D dentro de C2, lo usaría totalmente

Probé Unity, Blender, Torque 3D, UDK, porque son los más publicitados y los que usan la mayoría de los llamados desarrolladores famosos... y comparten los mismos problemas: no son fáciles de usar (en absoluto) y si nunca usé una API de creación de juegos 3D antes... bueno, estás 3Doomed (mal chiste ikno)

la cosa es que la construcción es muy intuitiva una vez que cubres lo básico y te da libertad para hacer juegos 2D complejos, te da varios caminos para lograr el mismo resultado (sin mencionar que el sistema de eventos TIENE SENTIDO para mí); cuál es el detalle que la mayoría de estas otras herramientas no cubren o lo hacen mal

si hacen un motor 3D con el mismo flujo y sentimiento que tengo usando C2; entonces ¿por qué no darle una oportunidad?

Tienen una gran base de usuarios en este momento (a los que les encanta el estilo de hoja de eventos para la programación visual, pero quieren estas funciones) y algunos de ellos están listos para dar un salto a otro motor. Hay un gran potencial aquí para que Godot incorpore muchos nuevos desarrolladores independientes, los que prefieren esto a los nodos, los que no usan el motor Unreal, que ahora es gratuito y mucho más maduro que Godot.

Si opta por él en lugar de los nodos, será el primer motor que admita el desarrollo completo de juegos en 3D con ese diseño de programación vis. Accederá a una nueva base de usuarios, en lugar de competir con Unreal (gratis), Unity (versión gratuita disponible)

Bueno, esas son imágenes fijas increíbles, pero nuevamente estás haciendo esto para darte más autoridad.

Las imágenes fijas y los enlaces no son prueba de mi autoridad, sino de las personas con las que he trabajado y de que no me lo estoy inventando :) Esto incluye a algunos de mis buenos amigos que trabajaron en algunas películas de las que tal vez hayas oído hablar. Avatar, King Kong, Serenity y programas como Lost, Revolution, etc. Y algunos de mis otros amigos que han trabajado en la industria de los videojuegos durante más de 15 años. Todos los cuales prefieren un flujo de trabajo basado en nodos sobre un flujo de trabajo lineal basado en hojas. Probablemente podría obtener una cotización de 3-4 de ellos que le digan que prefieren los gráficos de nodos a las hojas lógicas si lo desea.

Recientemente, Unreal hizo que su motor fuera gratuito, también es multiplataforma. Es un motor mucho más maduro que BGE/Godot. Entonces estás compitiendo con ellos directamente al copiar su enfoque de la programación visual.

El flujo de trabajo de secuencias de comandos visuales es lo último que la gente verá cuando compare a Godot con esos motores. Lo primero que notarán es que Unreal es compatible con DirectX 12 y OpenGL 4 y que sus demostraciones y ejemplos se ven impresionantes, luego comenzarán a buscar otras cosas. Lo más importante que Godot tiene sobre esas compañías es que es software FLOSS y que cualquiera que lo use es igualmente propietario total del software.

Los nodos son mucho menos eficientes en pantalla que una hoja lógica. Son más difíciles de leer/seguir.

Si bien es obvio por su declaración que no ha utilizado una buena configuración basada en nodos, si está preocupado por cosas como la eficiencia de la pantalla, entonces no debería usar secuencias de comandos visuales de todos modos, debería usar las secuencias de comandos reales que ya está disponible :) Te garantizo que cualquier cosa que los scripts visuales puedan ofrecerte en términos de espacio de pantalla, los scripts regulares también pueden hacerlo, como colapsar regiones de código.

Si opta por él en lugar de los nodos, será el primer motor que admita el desarrollo completo de juegos en 3D con ese diseño de programación vis.

Hay una razón por la cual los motores como Unreal, que dedican mucho tiempo, dinero e investigación a las necesidades de sus clientes, no optan por esa forma de secuencias de comandos visuales y eligen nodos en su lugar.

Mi opinión al respecto es que todo depende del enfoque que se pretenda
resuelto

Los bloques de acción como Game Maker son interesantes, pero creo que son más
diseñado hacia una sustitución de la programación.

El enfoque de Unreal es más como un complemento a la programación por lo que
los diseñadores pueden trabajar ellos mismos en el juego y quitarle trabajo a los
programador. Esto es mucho más útil en equipos (artistas y diseñadores de juegos).
puede usarlo bien) y definitivamente es el enfoque que me gustaría agregar a
Godot porque para esto.

Debido a la arquitectura de Godot, también sería muy fácil de agregar, así que daré
es un tiro en 1.2

El martes 3 de marzo de 2015 a las 4:37 p. m., Nathan [email protected] escribió:

Bueno, esas son imágenes increíbles, pero nuevamente estás haciendo esto para dar
usted mismo más autoridad.

Las fotos y los enlaces no son prueba de mi autoridad, sino de las personas que he
trabajé y que no me lo estoy inventando :) Esto incluye algunos de mis
buenos amigos que trabajaron en algunas películas de las que quizás hayas oído hablar como
Avatar, King Kong, Serenity y series como Lost, Revolution, etc... Y
algunos de mis otros amigos que han trabajado en la industria de los videojuegos durante más de 15
años. Todos los cuales prefieren un flujo de trabajo basado en nodos sobre uno lineal basado en hojas
flujo de trabajo. Probablemente podría obtener una cotización de 3-4 de ellos diciéndote que
¿Prefieren los gráficos de nodos a las hojas lógicas si lo desea?

Recientemente, Unreal hizo que su motor fuera gratuito, también es multiplataforma. Es un
Motor mucho más maduro que BGE/Godot. Así que estás compitiendo con ellos.
directamente al copiar su enfoque de la programación visual.

El flujo de trabajo de secuencias de comandos visuales es lo último que va a hacer la gente
mirando al comparar a Godot con esos motores. Lo primero que harán
El aviso es que Unreal es compatible con DirectX 12 y OpenGL 4 y que sus demostraciones
y los ejemplos se ven asombrosos, luego comenzarán a buscar otras cosas.
Lo más importante que tiene Godot sobre esas empresas es que es FLOSS.
software y que cualquier persona que lo use es igualmente propietario total del
software.

Los nodos son mucho menos eficientes en pantalla que una hoja lógica. son mas dificiles de
leer/seguir.

Si bien es obvio por su declaración que no ha usado un buen nodo
configuración basada en, si está preocupado por cosas como la eficiencia de la pantalla, entonces
no debería usar secuencias de comandos visuales de todos modos, debería usar el real
secuencias de comandos que ya está disponible :) Te garantizo que nada
secuencias de comandos visuales puede ofrecerle en términos de espacio de pantalla secuencias de comandos regulares
puede hacerlo también, como colapsar regiones de código.

Si opta por él en lugar de los nodos, será el primer motor que
admite el desarrollo completo de juegos en 3D con ese diseño de programación vis.

Hay una razón por la cual motores como Unreal, que gastan mucho tiempo, dinero
y la investigación de las necesidades de sus clientes no van con esa forma de
secuencias de comandos visuales y eligió nodos en su lugar.

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-77017857 .

Le di una buena oportunidad a Armador de Jugadas y debo decir que me gustó, más que kismet/blueprints de Unreal.

En Playmaker, los nodos son como contenedores en los que colocas acciones. Algunas de las acciones son la comprobación de una condición que puede conducir a otro nodo.

Dado que usted mismo crea los contenedores de nodos y puede nombrarlos, las acciones en ellos se ejecutan de manera predecible (de arriba a abajo); es algo con lo que puedo vivir. :)

Además, las acciones que coloca dentro de un nodo son en realidad scripts de Unity estándar con entradas visuales. Entonces, las personas podrán escribir sus propios scripts y agregarlos como acciones personalizadas.

Mire a Playmaker e implemente un sistema basado en nodos que sea más parecido a él, en lugar de Unreal.
Su ventaja es, por supuesto, que podemos hacer más con menos nodos, son más fáciles de leer y depurar, y son más predecibles.

Aquí hay una introducción de cómo funciona:
https://www.youtube.com/watch?v=I9VwsVtbgFU&index=2&list=PLC759306A1E692A10

Es muy flexible y le permite al usuario agregar y compartir fácilmente la funcionalidad del juego, fácil de reutilizar.

Discusión fascinante. Solo quiero señalar otro tipo/forma de secuencias de comandos visuales que no sean nodos y la hoja de eventos de C2, sino bloques de secuencias de comandos que encajan como piezas de un rompecabezas. Usado en motor 2d Stencyl http://www.stencyl.com/

basado en MIT Scratch http://wiki.scratch.mit.edu/wiki/Wait_Until_ ()_(block)

y en Unity yo personalmente uso, Blox http://www.plyoung.com/blox/

Personalmente, no estoy convencido con la programación "visual" similar a un rasguño. I
creo que es más o menos como la programación.
Creo que la forma en que Unreal hace esto es amigable para los diseñadores de juegos/niveles.

El sábado 21 de marzo de 2015 a las 23:57, todheil [email protected] escribió:

Discusión fascinante. Solo quiero señalar otro tipo/forma de visual
secuencias de comandos que no sean nodos, sino bloques de secuencias de comandos que encajan entre sí como
piezas de rompecabezas. Usado en motor 2d Stencyl http://www.stencyl.com/
[imagen: stencyl_blocks]
https://cloud.githubusercontent.com/assets/8675463/6767767/d52e7b16-d013-11e4-878c-29002dc04f8e.PNG
basado en MIT Scratch
http://wiki.scratch.mit.edu/wiki/Wait_Until_ ()_(bloque)
[imagen: scratch_example]
https://cloud.githubusercontent.com/assets/8675463/6767792/57f50e5c-d014-11e4-8015-9228bb6001d8.PNG
y en Unity yo personalmente uso, Blox http://www.plyoung.com/blox/
[imagen: hola_blox]
https://cloud.githubusercontent.com/assets/8675463/6767796/7849f46a-d014-11e4-9244-9e45c601f883.PNG

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-84508001 .

_OkamStudio_

Buen punto. Para mí, los bloques son el punto medio entre las líneas de código y los diagramas de flujo.

No me gusta la forma de programación visual scratch/stencyl. Su diseño es
visualmente más difícil de seguir que los bloques de construcción2 e incluso los nodos. Está
literalmente armando una pieza de rompecabezas y sufre el problema de
averiguar qué pieza encaja en cada lugar. No son sencillos de poner
juntos

El domingo 22 de marzo de 2015 a las 5:46 a. m., todheil [email protected] escribió:

Buen punto. Para mí, los bloques son el camino intermedio entre las líneas de código y el flujo.
cartas

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-84511415 .

ok, no leeré todo ahora, pero solo mis 2 centavos sobre este tema.

Se crean motores basados ​​en eventos para hacer prototipos y proyectos de juegos pequeños.
motores como godot estan creados para realizar todo tipo de proyectos

Entonces son dos cosas diferentes con dos enfoques diferentes, son dos
diferentes peajes

para ser honesto, no puedo usarlos bien. (peajes basados ​​en eventos)

Para mí, el mejor enfoque son dos peajes paralelos.

2015-03-22 6:49 GMT-03:00 Todor Imreorov [email protected] :

No me gusta la forma de programación visual scratch/stencyl. Su diseño es
visualmente más difícil de seguir que los bloques de construcción2 e incluso los nodos. Está
literalmente armando una pieza de rompecabezas y sufre el problema de
averiguar qué pieza encaja en cada lugar. No son sencillos de poner
juntos

El domingo 22 de marzo de 2015 a las 5:46 a. m., todheil [email protected] escribió:

Buen punto. Para mí, los bloques son el camino intermedio entre las líneas de código y el flujo.
cartas

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-84511415 .

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-84575752 .

David Aguiar de Aquino Paiva

lo único que sería útil es el sistema de unidad de "comportamiento",
básicamente es un script que hace algo, así que esto en Godot sería
se traduce como la posibilidad de agregar más de un script por nodo.
Por supuesto, podría crear un nodo y simplemente clonarlo, pero un script sería un
recurso y luego sería simplemente cargarlo en un nodo y agregar un comportamiento (por
ejemplo, un script de salto)
En el editor pudimos ver las exportaciones categorizadas bajo el nombre del script.

2015-03-26 13:15 GMT-03:00 David Paiva [email protected] :

ok, no leeré todo ahora, pero solo mis 2 centavos sobre este tema.

Se crean motores basados ​​en eventos para hacer prototipos y proyectos de juegos pequeños.
motores como godot estan creados para realizar todo tipo de proyectos

Entonces son dos cosas diferentes con dos enfoques diferentes, son dos
diferentes peajes

para ser honesto, no puedo usarlos bien.

Para mí, el mejor enfoque son dos peajes paralelos.

2015-03-22 6:49 GMT-03:00 Todor Imreorov [email protected] :

No me gusta la forma de programación visual scratch/stencyl. Su diseño es

visualmente más difícil de seguir que los bloques de construcción2 e incluso los nodos. Está
literalmente armando una pieza de rompecabezas y sufre el problema de
averiguar qué pieza encaja en cada lugar. No son sencillos de poner
juntos

El domingo 22 de marzo de 2015 a las 5:46 a. m., todheil [email protected]
escribió:

Buen punto. Para mí, los bloques son el camino intermedio entre las líneas de código y el flujo.
cartas

—
Responda a este correo electrónico directamente o véalo en GitHub
< https://github.com/okamstudio/godot/issues/1220#issuecomment-84511415
.

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-84575752 .

David Aguiar de Aquino Paiva

David Aguiar de Aquino Paiva

¡Hola chicos! Buena discusión está aquí :) Me gustaría agregar algo.

Lo primero: soy estudiante de arte pero la programación es mi hobby. Sé Java, Python y (mi favorito) Golang. Pero antes de aprender a codificar (hace unos 3 años), probé casi todos los programas que afirman que permiten "crear juegos sin programación". Todas estas afirmaciones son tonterías.

Probé (sin ningún orden en particular): Click & Play, GameMaker, The Games Factory, Multimedia Fusion, Construct 1, RPG Maker, Stencyl, BGE y algunos otros que ni siquiera recuerdo. Y mi opinión es: Puedes hacer un juego sin _escribir_ código pero no sin _programar_. Incluso si está utilizando hojas de eventos o nodos, aún necesita comprender la _lógica de la programación_. Tienes que saber qué es condicional, evento, variable, cadena, etc. Por lo tanto, es imposible crear un juego sin programación. Todos esos métodos visuales de codificación son solo una forma diferente de expresar la lógica que se encuentra en los lenguajes de programación tradicionales. Todo este argumento puede parecer obvio, pero te aseguro que no lo era para mí al comienzo de mi aventura con la programación.

De aquí se sigue mi siguiente consideración:

El mejor y más intuitivo lenguaje de programación visual que había encontrado antes de aprender a codificar es Scrach/Stencyl puzzle/blocks way. Este es el por qué:

• esta solución es la más cercana a la programación tradicional. De hecho, es algo así como azúcar de sintaxis para el código subyacente (básicamente, así es como funciona Stencyl). en bonitas estructuras como funciones. Para mí _esto_ es un lío
  Recuerda que esta es solo mi opinión.

*Creo que los bloques Scrach/Stencyl son el método más visual y fácil de seguir. Usan mucho el color (y a las personas con mentalidad visual les gustan los colores). Es fácil recordar que amarillo = condicionales y bucles, verde = matemáticas, azul = variables, etc. También parece código real (en contraste con los nodos) pero más amigable.

Finalmente, no creo que la programación visual deba ser una prioridad en el corto plazo. Hay muchas cosas más importantes que hacer (hoja de ruta completa + documentación) y supongo que implementar cualquiera de estos sistemas no sería rápido ni fácil. Godot es en mi humilde opinión muy fácil de trabajar como lo es ahora. Contiene muchas herramientas que el artista puede usar en cooperación con los desarrolladores del juego (editor de sombreado visual, editor de animación, nodo de mapa de mosaico).

POR CIERTO. Me gustaría aprovechar esta oportunidad y gracias a todos los creadores y colaboradores de Godot. Hiciste un excelente trabajo :+1:

Por cierto2. Lo siento por mi Inglés. Estoy haciendo lo mejor que puedo pero sigo cometiendo errores tontos :cry:

ya sea construct2 o blox, cualquiera de los dos es mejor para mí que esos gráficos de nodos.

Si el sistema usa nodos solo como contenedores para acciones (como estados), como está en Playmaker, entonces estaré de acuerdo.

Lo bueno de blox y construct2 es que el editor le muestra todas las condiciones y acciones disponibles. Los separa para usted y los pone en categorías. Ese es un cambio dramático en la presentación que permite que alguien que no sea programador haga mucho con el motor de inmediato, sin necesidad de saber los nombres de los comandos para hacer las cosas.

si usa nodos para la programación visual, el mayor desafío sería comunicar al usuario en qué orden se ejecutan los eventos. En Unity, tanto el mediapunta como el blox lo hacen de manera muy limpia.

En playmaker apilando acciones dentro de contenedores de nodos (estado - contiene acciones). En blox, donde tiene estados que contienen funciones.

Dan acceso completo a la mayoría de las funciones de Unity. Esto es realmente bueno para los no programadores.
blox se ha desarrollado aún más en "plygame", otro complemento de unidad que tiene blox + algunos scripts personalizados a los que blox puede acceder para crear un juego completo de estilo rpg hack and slash.

Blox en unidad es lo mismo que los bloques Skrach/Stencyl. Parece que hay mucha gente aquí a la que le gusta ese estilo de programación :)
https://www.youtube.com/watch?v=Nd6Qy5ZipSs&list=PLuaBtUXEKcdIAA7_yjFNcLXM5YOf3WE9k

Espero que los desarrolladores de Godot lo prueben.
¡Por cierto, la tecnología Skratch (https://scratch.mit.edu/) es de código abierto! Y otros lo han estado adoptando, no solo stencyl. Google también se ha interesado mucho en él:
https://developers.google.com/blockly/

propuesta - ¿Por qué no intentar tener lo mejor de ambos mundos? Nodos para una máquina de estado: blox/skratch/stencyl para expresiones.
En un mundo ideal, tendría nodos que se utilizarían como contenedores de estado, como en Playmaker. Pero el contenedor de estado tendría blox/stencyl/skratch como un sistema lego que le permite al usuario configurar fácilmente la lógica, no es necesario aprender a escribir expresiones de esa manera, solo están listos para arrastrar y soltar.

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

Uno de los desarrolladores de iCanScript dijo esto sobre su activo VS:

El avance técnico de iCS2 lo separa de ser un producto exclusivo de Unity, lo que aumenta significativamente las oportunidades de mercado. La visión final es que iCS2 será una ayuda de desarrollo que se puede utilizar para crear secuencias de comandos para otros motores de juegos, así como para aplicaciones estándar de Windows/OSX/iOS/Android.
http://forum.unity3d.com/threads/icanscript-visual-script-modeling-engine-for-unity.280847/#post -2124402

¡Qué lío de nodos es iCanScript!

En cualquier caso, vale la pena intentarlo antes de juzgarlo. Tal vez alguien pueda entrar
contacto con su desarrollador?
Si Godot tuviera un mercado con oportunidades de ganancias, como el
unity lo hace, tal vez eso atraería a los desarrolladores de unity a crear activos para
dios también.

El sábado 23 de mayo de 2015 a las 4:24 p. m., todheil [email protected] escribió:

Uno de los desarrolladores de iCanScript dijo esto sobre su activo VS:

El avance técnico de iCS2 lo desvincula de ser solo un dispositivo Unity
producto significativamente >aumentando las oportunidades de mercado. La visión final
es que iCS2 será una ayuda de desarrollo que >puede usarse para crear scripts
para otros motores de juegos, así como estándar >Windows/OSX/iOS/Android
aplicaciones

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

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-104895405 .

Creo que la hoja de eventos de la construcción 2 es realmente fácil de entender y programar.

Como artista que pasa la mayor parte del tiempo creando gráficos para vivir, aprender un nuevo idioma es muy difícil y requiere mucho tiempo. La gente dice que puedes aprenderlo en unos pocos meses, pero cuando solo tienes 2 horas al día para ti, puedes elegir aprender desde cero o crear usando un lenguaje simple. Además, ser una persona visual, el scripting visual tiene más sentido.

Hice programación en la escuela y puedo leer y entender el código fácilmente, pero escribirlo lleva tiempo. También estoy tratando de aprender python, que es más fácil, pero aún me llevará meses crear algo con él.

El enfoque de Construct 2 parece simple. Para mí se parece a:

1 Evento: Acción;

2 Evento: Acción;
: Acción;

Es básicamente programación pero de una forma muy comprensible. Si hubieran usado solo lenguaje en lugar de bloqueo, no me habría importado. Usar este patrón es fácil de crear una lógica para mí.

El uso de nodos puede salirse de control muy rápidamente a medida que las cosas comienzan a extenderse y pasas más tiempo buscando los nodos que codificando (como entendí de Unity y Playmaker).

Por lo tanto, si está tratando de implementar un script visual, piense muy seriamente en construir un sistema de eventos.

También puede crear el sistema de secuencias de comandos visuales como una extensión descargable para personas como nosotros, de modo que aquellos que prefieren la programación no tengan que descargar esa carga útil adicional.

Gran trabajo con Godot esperando crear grandes juegos en él.

Mi problema con el enfoque de Construct es que se siente como programar,
no parece ser tan diferente
Desde la perspectiva del equipo, me gusta más el enfoque de proyecto de Unreal porque
es más amigable para los diseñadores que no tienen idea de programación

El domingo 24 de mayo de 2015 a las 3:58 a. m., whoisda [email protected] escribió:

Creo que la hoja de eventos de la construcción 2 es realmente fácil de entender y
programa en

Como artista que pasa la mayor parte del tiempo creando gráficos para vivir,
aprender un nuevo idioma es muy difícil y requiere mucho tiempo. La gente dice que puedes
aprenderlo en unos meses pero cuando solo tienes 2 horas al día para
usted mismo puede optar por aprender desde cero o crear utilizando un
lenguaje sencillo Además, ser una persona visual, el scripting visual hace más
sentido.

He hecho programación en la escuela y puedo leer y entender el código fácilmente.
pero escribirlo lleva tiempo. También estoy tratando de aprender Python, que es más fácil.
pero aún llevará meses crear algo con él.

El enfoque de Construct 2 parece simple. Para mí se parece a:

1 Evento: Acción;

2 Evento: Acción;
: Acción;

Es básicamente programación pero de una forma muy comprensible. Si ellos
si hubiera usado solo lenguaje en lugar de bloque, no me habría importado. Usando esto
patrón es fácil crear una lógica para mí.

El uso de nodos puede salirse de control muy rápidamente a medida que las cosas comienzan a extenderse y
pasas más tiempo buscando los nodos que codificando (como yo
entendido desde unidad y mediapunta).

Entonces, si está tratando de implementar una secuencia de comandos visual, dé una muy
Pensamiento serio para construir un sistema de eventos.

También puede crear el sistema de secuencias de comandos visuales como descargable
extensión para gente como nosotros para que aquellos que prefieren la programación no tengan que
descarga esa carga adicional.

Gran trabajo con Godot esperando crear grandes juegos en él.

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-104985159 .

Pero tu es la perspectiva de un programador - alguien que ya sabe cómo
codificar.
Es mejor mirar las estadísticas en este caso: el número de
usuarios no programadores que construct2 tiene sobre la otra programación visual
los editores deben hablar por sí mismos.

También vale la pena analizar la variedad de juegos creados en un estilo de programación visual sobre otro.

Unreal tiene una gran cantidad de proyectos realizados en kismet, pero es un motor mucho más antiguo que construct2 y muchos de ellos son solo juegos de disparos en primera persona.

El domingo 24 de mayo de 2015 a las 10:15, Juan Linietsky [email protected]
escribió:

Mi problema con el enfoque de Construct es que se siente como programar,
no parece ser tan diferente
Desde la perspectiva del equipo, me gusta más el enfoque de proyecto de Unreal porque
es más amigable para los diseñadores que no tienen idea de programación

El domingo 24 de mayo de 2015 a las 3:58 a. m., whoisda [email protected] escribió:

Creo que la hoja de eventos de la construcción 2 es realmente fácil de entender y
programa en

Como artista que pasa la mayor parte del tiempo creando gráficos para vivir,
aprender un nuevo idioma es muy difícil y requiere mucho tiempo. la gente dice que tu
poder
aprenderlo en unos meses pero cuando solo tienes 2 horas al día para
usted mismo puede optar por aprender desde cero o crear utilizando un
lenguaje sencillo Además, ser una persona visual, el scripting visual hace más
sentido.

He hecho programación en la escuela y puedo leer y entender el código fácilmente.
pero escribirlo lleva tiempo. También estoy tratando de aprender Python, que es
más fácil
pero aún llevará meses crear algo con él.

El enfoque de Construct 2 parece simple. Para mí se parece a:

1 Evento: Acción;

2 Evento: Acción;
: Acción;

Es básicamente programación pero de una forma muy comprensible. Si
ellos
si hubiera usado solo lenguaje en lugar de bloque, no me habría importado. Utilizando
esta
patrón es fácil crear una lógica para mí.

El uso de nodos puede salirse de control muy rápidamente a medida que las cosas comienzan a extenderse y
pasas más tiempo buscando los nodos que codificando (como yo
entendido desde unidad y mediapunta).

Entonces, si está tratando de implementar una secuencia de comandos visual, dé una muy
Pensamiento serio para construir un sistema de eventos.

También puede crear el sistema de secuencias de comandos visuales como descargable
extensión para gente como nosotros para que aquellos que prefieren programar no tengan
a
descarga esa carga adicional.

Gran trabajo con Godot esperando crear grandes juegos en él.

—
Responda a este correo electrónico directamente o véalo en GitHub
< https://github.com/okamstudio/godot/issues/1220#issuecomment-104985159
.

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-104985669 .

El enfoque de programación de Construct2 es muy similar al de
Clickteam fusion, que también tiene muchos usuarios. La facilidad para ello proviene de una
varias cosas, aunque es similar a la programación:

• Tener todas las CONDICIONES posibles enumeradas y disponibles para que el usuario seleccione
  para agregar haciendo clic/arrastrando en lenguaje sencillo inglés - esto es invaluable
  porque no tienen que aprender las palabras mágicas. Pueden simplemente arrastrar y
  Sueltalos.
• Tener todas las ACCIONES posibles enumeradas y disponibles para que el usuario seleccione para
  agregar haciendo clic/arrastrando en lenguaje inglés simple - esto es invaluable
  porque no tienen que aprender las palabras mágicas. Pueden simplemente arrastrar y
  Sueltalos.
• Lo mismo ocurre al hacer cualquier tipo de expresiones tanto en la configuración como en la
  acción o una condición. Cuando escribes expresiones, el editor te ayuda
  con una lista desplegable fácil de cosas para obtener de los objetos existentes en el
  escena. No tiene que aprender cómo llegar a esas propiedades ya que
  ya están disponibles en un par de clics.

Quizás el mejor aspecto de esto es que enseña a los no programadores sobre
teoría de programación sin la curva de aprendizaje de aprender una nueva programación
idioma.

El domingo 24 de mayo de 2015 a las 10:17, Todor Imreorov [email protected]
escribió:

Pero tu es la perspectiva de un programador - alguien que ya sabe
cómo codificar
Es mejor mirar las estadísticas en este caso: el número de
usuarios no programadores que construct2 tiene sobre la otra programación visual
los editores deben hablar por sí mismos.

El domingo 24 de mayo de 2015 a las 10:15, Juan Linietsky < [email protected]

escribió:

Mi problema con el enfoque de Construct es que se siente como programar,
no parece ser tan diferente
Desde la perspectiva del equipo, me gusta más el enfoque de proyecto de Unreal porque
es más amigable para los diseñadores que no tienen idea de programación

El domingo 24 de mayo de 2015 a las 3:58 a.m., whoisda [email protected]
escribió:

Creo que la hoja de eventos de la construcción 2 es realmente fácil de entender y
programa en

Como artista que pasa la mayor parte del tiempo creando gráficos para vivir,
aprender un nuevo idioma es muy difícil y requiere mucho tiempo. la gente dice que tu
poder
aprenderlo en unos meses pero cuando solo tienes 2 horas al día para
usted mismo puede optar por aprender desde cero o crear utilizando un
lenguaje sencillo Además, ser una persona visual, el scripting visual hace más
sentido.

He hecho programación en la escuela y puedo leer y entender el código.
fácilmente
pero escribirlo lleva tiempo. También estoy tratando de aprender Python, que es
más fácil
pero aún llevará meses crear algo con él.

El enfoque de Construct 2 parece simple. Para mí se parece a:

1 Evento: Acción;

2 Evento: Acción;
: Acción;

Es básicamente programación pero de una forma muy comprensible. Si
ellos
si hubiera usado solo lenguaje en lugar de bloque, no me habría importado. Utilizando
esta
patrón es fácil crear una lógica para mí.

El uso de nodos puede salirse de control muy rápidamente a medida que las cosas comienzan a extenderse
y
pasas más tiempo buscando los nodos que codificando (como yo
entendido desde unidad y mediapunta).

Entonces, si está tratando de implementar una secuencia de comandos visual, dé una muy
Pensamiento serio para construir un sistema de eventos.

También puede crear el sistema de secuencias de comandos visuales como descargable
extensión para gente como nosotros para que aquellos que prefieren programar no tengan
a
descarga esa carga adicional.

Gran trabajo con Godot esperando crear grandes juegos en él.

—
Responda a este correo electrónico directamente o véalo en GitHub
< https://github.com/okamstudio/godot/issues/1220#issuecomment-104985159
.

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-104985669 .

Mírelo también desde la perspectiva de un diseñador al que le gustaría aprender a codificar una lógica compleja y, finalmente, tener la confianza suficiente para aprender a codificar. Veo de dónde viene, ya que ve que el sistema será utilizado por un equipo de diseñadores y programadores. Personalmente, me gustaría usar Godot como un solo usuario y no en un equipo con un programador como muchos desarrolladores de juegos independientes. El sistema de eventos perdona y se siente más organizado usando grupos cuando tienes más de 1000 eventos.

Aparte de esto, no tengo ningún problema con el sistema de nodos y si Godot logra crear un sistema que sea mejor que el actual, lo usaré como una mierda.

Además, si es posible, cree una función de búsqueda para encontrar bloques/nodos de código fácilmente.

Tenga en cuenta que las hojas de eventos en construct2/clickteam eliminan la necesidad de aprender
sintaxis, por lo que el usuario no tiene que saber dónde poner las cosas, es decir
muy evidente. Condiciones a la izquierda, acciones a la derecha. El orden de
la ejecución del evento también es muy obvia.
Las piezas de Lego en scratch/stencyl/unity blox no son tan obvias, pero siguen siendo
mucho mejor que la pesadilla de los nodos presentada en "iCanScript". Miraste
en su video tutorial. Es un diseño de programación visual súper complicado.
con una curva de aprendizaje bastante empinada. Yo creo que aunque se lo des a un
programador tendrán problemas para resolverlo

El domingo 24 de mayo de 2015 a las 10:33 a. m., whoisda [email protected] escribió:

Míralo también desde la perspectiva de un diseñador al que le gustaría aprender
para codificar lógica compleja y, finalmente, obtener la confianza suficiente para aprender a codificar.
Veo de dónde viene, ya que ve que el sistema será utilizado por un
equipo de diseñadores y programadores. Personalmente me gustaría usar a Godot como
un solo usuario y no en un equipo con un programador como muchos juegos independientes
desarrolladores El sistema de eventos es indulgente y se siente más organizado usando
grupos cuando tienes más de 1000 eventos.

Aparte de esto, no tengo ningún problema con el sistema de nodos y si Godot logra
crear un sistema que sea mejor que el actual voy a usar la mierda de
eso.

Además, si es posible, cree una función de búsqueda para encontrar bloques/nodos de código
fácilmente.

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-104988595 .

Ya ni siquiera venden "icanscript" en la tienda de recursos de Unity.
Mire las cifras de ventas allí: ¿cuál de los programas visuales disponibles
Systems es el que más se usa y tiene proyectos completos.

Los dejo con este video:
https://www.youtube.com/watch?v=3Zq1yo0lxOU
Tiene 167 juegos hechos con clickteam fusion - por personas que no tienen
experiencia en programación.

Mire también los exitosos juegos de kickstarter hechos en fusión.
https://www.kickstarter.com/projects/alonsomartin/heart-forth-alicia/description
https://www.kickstarter.com/projects/galaxytrail/freedom-planet-high-speed-platform-game/description
https://www.kickstarter.com/projects/2064021040/tiny-trek

también necesito mencionar Five Nights at Freddy's (hecho en clickteam fusion):
http://en.wikipedia.org/wiki/Five_Nights_at_Freddy%27s_%28video_game%29
ese juego es un best seller. Aquí hay algunas cifras para usted:
https://thinkgaming.com/app-sales-data/8779/cinco-noches-en-freddys/

La idea de un marco de programación visual debería ser capacitar a un artista para crear un juego sin necesidad de un programador; en el proceso, aprenda un poco sobre programación.

Si crea uno en el que aún se requiere el programador, entonces realmente no ha creado un marco de programación visual, acaba de crear una máquina de estado que los programadores pueden configurar para que la usen los diseñadores, para cosas simples en el juego, pero no para la lógica central del juego. Así que realmente no vas a crear algo que sea tan bueno y completo como las otras herramientas de programación visual mencionadas aquí. No estás capacitando a los artistas para que establezcan la lógica e invitándolos a aprender conceptos básicos de programación. Los mantiene dependientes de los programadores y en la oscuridad de esos conceptos.

El domingo 24 de mayo de 2015 a las 10:42, Todor Imreorov [email protected]
escribió:

Tenga en cuenta que las hojas de eventos en construct2/clickteam eliminan la necesidad de aprender
sintaxis, por lo que el usuario no tiene que saber dónde poner las cosas, es decir
muy evidente. Condiciones a la izquierda, acciones a la derecha. El orden de
la ejecución del evento también es muy obvia.
Las piezas de Lego en scratch/stencyl/unity blox no son tan obvias, pero son
todavía mucho mejor que la pesadilla de los nodos presentada en "iCanScript". Hizo
miras su video tutorial. Es un visual super enrevesado.
diseño de programación con una curva de aprendizaje bastante empinada. creo que aunque
se lo das a un programador, tendrán problemas para resolverlo

El domingo 24 de mayo de 2015 a las 10:33 a. m., whoisda [email protected]
escribió:

Míralo también desde la perspectiva de un diseñador al que le gustaría
aprenda a codificar lógica compleja y, finalmente, obtenga la confianza suficiente para aprender a
código. Veo de dónde viene, ya que ve que el sistema será utilizado por
un equipo de diseñadores y programadores. Personalmente me gustaría usar Godot
como un solo usuario y no en un equipo con un programador como muchos indie
desarrolladores de juegos El sistema de eventos es indulgente y se siente más organizado.
usando grupos cuando tienes más de 1000 eventos.

Aparte de esto, no tengo ningún problema con el sistema de nodos y si Godot logra
crear un sistema que sea mejor que el actual voy a usar la mierda de
eso.

Además, si es posible, cree una función de búsqueda para encontrar bloques/nodos de código
fácilmente.

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-104988595 .

No creo que sea prudente presionarte para que uses un sistema que funciona excelentemente para otro motor de juego si esa no es la dirección que quieres tomar.

En la misma nota, me gustaría ver una forma más intuitiva de implementar un script visual. No usar los nodos desordenados o los bloques de toma de tiempo (creador de aplicaciones de Android) o programar demasiado el sistema de eventos (que prefiero sobre todo lo demás). Algo que toma lo mejor de todos ellos.

Tal vez consulte a un diseñador de usabilidad para despejar algunos caminos y ver algunos números.

Al final, sería genial ver un método exclusivo de Godot que convierte a Godot en un gran motor que permite tanto a una persona principiante diseñar su primer juego en una semana como a un equipo de desarrollo que colabora para crear un juego AAA.

Me encantaría ver un sistema que me ayude a crear juegos maravillosos sin cambiar de motor ni aprender idiomas tan a menudo.

Salud.

No me importan los nodos si se hacen como los de playmaker - como
contenedores de acción (estados).
Los nodos no se utilizan realmente para establecer acciones o condiciones.

Sin embargo, si los hace como "iCanScript", tiene un completo desastre.

1. es difícil saber en qué orden se ejecutan los eventos
2. Es difícil averiguar qué nodo se puede conectar a qué nodo
3. se necesitan muchos nodos y pasos para configurar una sola acción que para
   arrástrelo y suéltelo y configure una expresión en él (estilo construct2/clickteam
4. donde te ayudan con la sintaxis - esa es una gran manera de presentar
   a alguien a programar sin requerir que lea toneladas de
   documentación - todo está allí para ellos en el menú desplegable de la
   objeto).

El domingo 24 de mayo de 2015 a las 11:20 a. m., whoisda [email protected] escribió:

No creo que sea prudente presionarlo para que use un sistema que funciona
excelentemente para otro motor de juego si esa no es la dirección que
querer tomar.

En la misma nota, me gustaría ver alguna forma más intuitiva de que un visual
Se implementa scripting. No usar los nodos desordenados o tomarse el tiempo
bloques (creador de aplicaciones de Android) o un sistema de eventos de aspecto demasiado programado (que yo
prefieren sobre todo lo demás). Algo que toma lo mejor de todos ellos.

Tal vez consulte a un diseñador de usabilidad para despejar algunos caminos y ver algunos
números.

Al final, sería genial ver un método exclusivo de Godot que haga
Godot es un gran motor que permite tanto a un principiante de una sola persona diseñar su
primer juego en una semana y un equipo de desarrollo colaborando juntos para
crear un juego AAA.

Me encantaría ver un sistema que me ayude a crear juegos maravillosos.
sin cambiar motores y aprender idiomas cada tanto.

Salud.

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-104990083 .

Voto por @whoisda con respecto a algo que se está innovando para/en Godot. Sin embargo, parece haber tres escuelas de Visual Scripting: 1) nodos, 2) hojas de eventos, 3) bloques. De estos tres nodos parecen estar liderando el campo en entornos 3D. Hablando de eso, he leído en alguna parte una idea que sugiere secuencias de comandos/programación de un formato lineal (texto, bloques, hoja de eventos) u horizontal (nodos) y programa en 3D usando estructuras. No estoy seguro de cómo funcionaría eso, pero suena fascinante.

Las escuelas de scripting visual mencionadas han sido probadas en la práctica y
ya tiene usuarios. Sugiero combinar los diseños de Playmaker y
bloque en unidad.

Nodos para crear una máquina de estado.
Bloques u hojas de eventos para crear las acciones dentro de cada nodo (estado).

El domingo 24 de mayo de 2015 a la 1:56 p. m., todheil [email protected] escribió:

Voto por @whoisda https://github.com/whoisda con respecto a algo
siendo innovado para/en Godot. Sin embargo, parece haber tres Visual
Escuelas de scripting: 1) nodos, 2) hojas de eventos, 3) bloques. de estos tres
los nodos parecen estar liderando el campo en entornos 3D. Hablando de que
He leído en alguna parte una idea que sugiere la creación de secuencias de comandos/programación a partir de un
formato lineal (texto, bloques, hoja de eventos) u horizontal (nodos) y
programa en 3D utilizando estructuras. No estoy seguro de cómo funcionaría, pero suena
fascinante.

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-105001411 .

Sería genial si pudiéramos usar nodos y eventos juntos. Los nodos pueden ser estados que, si siguen una lógica simple, pueden conectarse a otros nodos o pueden ser contenedores para scripts/bloques/hojas de eventos. De esta forma, no tendremos nodos muy grandes y también podremos colaborar como equipo. Pero esto podría ser demasiado para el desarrollador. Aún así, la idea parece ser muy buena.

Es algo así en Armador de Jugadas: a la gente parece gustarle mucho.
A mucha gente aquí también parece gustarle stencyl - la tecnología es
código abierto y disponible en el sitio web scratch github. lo compartí en un
Publicación anterior.

Personalmente, me encantaría ver CUALQUIER primer paso en la programación visual.
dirección. Incluso si el desarrollador crea una máquina de estado que funciona con gd
scripts: ese sería un comienzo increíble que incluso los programadores avanzados
apreciaría.

Entonces tal vez después de eso podamos tener algo visual como stencyl o
construct2 - que es como el código - pero mucho más fácil que el código - dentro del
estados

¡Así que en realidad estas son dos solicitudes de funciones!

• Uno para una máquina de estado (nodos)
• otro para un marco de secuencias de comandos visuales que reemplaza el aprendizaje de gdscript
  con codificación de arrastrar y soltar. Pero también es un buen paso hacia el aprendizaje.
  gdscript.

Al final, el desarrollador principal sabe qué es lo mejor para el diseño de Godot.

El martes 26 de mayo de 2015 a las 11:43 a. m., whoisda [email protected] escribió:

Sería genial si pudiéramos usar nodos y eventos juntos. Los nodos pueden
estados que si siguen una lógica simple se pueden conectar a otros nodos o
pueden ser contenedores para scripts/bloques/hojas de eventos de esta manera no tendremos
nodos muy grandes y también pueden colaborar en equipo. Pero esto podría ser demasiado
mucho para el desarrollador. Aún así, la idea parece ser muy buena.

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-105446984 .

Comprobaré styencyl pronto porque no estoy familiarizado con él.
en este punto de todo lo que vi/leí, puedo deducir que:

1) Blueprint: es genial para los diseñadores de juegos/niveles, pero no tan bueno para
programación visual
2) Stencyl: Es mucho mejor para la programación visual, pero inutilizable para
diseñadores de juegos/niveles

Mi experiencia en la creación de juegos siempre fue en equipos, por lo que puedo ver 1) como
muy útil, pero eso también me hace parcial. ¿Hay tanta gente
interesado en la programación visual como en Stencyl?

El martes 26 de mayo de 2015 a las 6:10 a. m., Todor Imreorov [email protected]
escribió:

Es algo así en Armador de Jugadas: a la gente parece gustarle mucho.
A mucha gente aquí también parece gustarle stencyl - la tecnología es
código abierto y disponible en el sitio web scratch github. lo compartí en un
Publicación anterior.

Personalmente, me encantaría ver CUALQUIER primer paso en la programación visual.
dirección. Incluso si el desarrollador crea una máquina de estado que funciona con gd
scripts: ese sería un comienzo increíble que incluso los programadores avanzados
apreciaría.

Entonces tal vez después de eso podamos tener algo visual como stencyl o
construct2 - que es como el código - pero mucho más fácil que el código - dentro del
estados

¡Así que en realidad estas son dos solicitudes de funciones!

• Uno para una máquina de estado (nodos)
• otro para un marco de secuencias de comandos visuales que reemplaza el aprendizaje de gdscript
  con codificación de arrastrar y soltar. Pero también es un buen paso hacia el aprendizaje.
  gdscript.

Al final, el desarrollador principal sabe qué es lo mejor para el diseño de Godot.

El martes 26 de mayo de 2015 a las 11:43 a. m., whoisda [email protected]
escribió:

Sería genial si pudiéramos usar nodos y eventos juntos. Los nodos pueden
establece que si sigue una lógica simple se puede conectar a otros nodos
o
pueden ser contenedores para scripts/bloques/hojas de eventos de esta manera no lo haremos
tener
nodos muy grandes y también pueden colaborar en equipo. Pero esto podría ser
también
mucho para el desarrollador. Aún así, la idea parece ser muy buena.

—
Responda a este correo electrónico directamente o véalo en GitHub
< https://github.com/okamstudio/godot/issues/1220#issuecomment-105446984
.

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-105458142 .

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

¿Es este un ejemplo canónico de cómo se ve el "código" de stencyl? Si es así, entonces parece una idea horrible: parece una codificación estándar en envoltorios visuales para jardín de infantes. Vamos, Python ya es lo suficientemente fácil para que mi esposa lo lea, entonces, ¿por qué no hacer un esfuerzo para aprender los conceptos básicos?

Si hablas de programación visual, entonces lo que Godot ya tiene es mucho mejor: gráficos de sombreado o gráficos de animación: código envuelto en nodos visuales.
https://frenchdog.files.wordpress.com/2009/09/specular_reflexion_vops.jpg : otro ejemplo de programación visual basada en nodos (Sidefx Houdini o XSI). Es maduro y no parece un juguete para niños, también me recuerda a los nodos de Godot.

Me gustó el enfoque de construct2, pero después de mirar más desde cero, parece una mejor opción por varias razones:

• El diseño de programación parece ser más popular que el de construct2.
• Ya se ha establecido como una herramienta para ayudar a enseñar a las personas un lenguaje de programación.
• Es de código abierto y otros lo han rediseñado para su motor en el pasado.

Los desarrolladores de Stencyl adoptaron la tecnología "scratch" de código abierto. No es su diseño.
https://scratch.mit.edu/about/
http://en.wikipedia.org/wiki/Scratch_ (lenguaje_de_programación)
http://wiki.scratch.mit.edu/wiki/Scratch_1.4_Source_Code

Ejemplos de Scratch utilizados por otros motores de juegos dirigidos a personas que no son programadores:

• Stencyl (el más popular) http://www.stencyl.com/
  
• Craftstudio ( http://craftstud.io/ )
  
• bloque de Google ( https://developers.google.com/blockly/ )
• Lo más cercano a Godot es el activo de programación visual "Blox" de Unity:
  
  https://www.youtube.com/watch?v=Nd6Qy5ZipSs&list=PLuaBtUXEKcdIAA7_yjFNcLXM5YOf3WE9k
  En lugar de Lua, genera C#.
  su documentación completa está aquí:
  http://www.plyoung.com/blox/
  y se vende aquí: https://www.assetstore.unity3d.com/en/#!/content/12859

Puede parecer una idea horrible para los programadores experimentados, pero es la mejor manera de enseñar a los no programadores cómo escribir código o simplemente capacitarlos para programar sin conocer las palabras mágicas o la sintaxis. Scratch los hace disponibles para arrastrar y soltar, forzando una estructura correcta con pistas visuales. Mire la lista de reproducción de videos de "Unity Blox" que publiqué para verlo en acción. Más que nada, se ha demostrado en la práctica una y otra vez. Parece la apuesta más segura.

Estoy de acuerdo con @reduz en sus puntos de que uno es bueno en el diseño de niveles y el otro en secuencias de comandos visuales y ya no estoy discutiendo sobre el uso de uno sobre el otro.

Usar ambos parece ser el mejor enfoque. Si no es Unity blox, incluso si miras a Playmaker, verás que los nodos son realmente contenedores allí, donde se pueden apilar las acciones, de manera muy similar a stencyl. ¡Los arrastras y los sueltas de una lista!

"pero es la mejor manera de enseñar a los no programadores cómo escribir código o simplemente empoderarlos para programar sin saber las palabras mágicas"

Entonces no entiendo a qué público se dirige este objetivo. ¿Godot pretende competir con los grandes del mercado (Unreal Engine, Unity, etc.) o enseñar a los niños a programar/crear juegos como lo hace Scratch (https://scratch.mit.edu/)?

Sé qué son los nodos (entrada -> función con parámetros -> salida), no estoy de acuerdo con la presentación.

Stencyl y Playmaker pueden ser excelentes para enseñar a los niños a programar, pero los no programadores (tanto de estudios como independientes) los han utilizado con éxito para crear juegos exitosos, que se venden en diferentes plataformas.
Si clasifica a Unity como los grandes, entonces debe saber que los grandes también hacen programación visual.
http://www.hutonggames.com/showcase.html

Creo que Godot tiene muchas funciones preparadas para ser utilizadas por los grandes. Algunas características que permiten a los más pequeños/indies podrían ayudar con una adopción más rápida del motor. Y la naturaleza de código abierto y las licencias lean son muy lucrativas para empezar.

@blurymind
Yo _no_ argumento en contra de la programación visual. Diría que Godot ya tiene lo que necesita (ShaderGraphs): el mismo enfoque visual podría extenderse a la programación lógica de máquina de estado o programación general. Contra lo que discuto es contra la adopción de otro paradigma visual (~scratch) que no asuste a los niños.

como se señaló antes, no es solo para niños. Pero si incluso los niños pueden entenderlo y usarlo, entonces creo que es algo bueno. No es algo de lo que avergonzarse.

El punto más importante que quiero hacer aquí es que:

• ¡El orden de ejecución de las acciones debe ser claro! Hacer toda la lógica con nodos puede volverse muy complicado muy rápidamente. Por lo tanto, los nodos deben usarse para los estados de la OMI.
• Los desarrolladores de Playmaker anticiparon muy inteligentemente ese problema y es por eso que lo han hecho para que los nodos sean contenedores de acciones en los que, de manera muy similar a Stencyl, arrastras y sueltas las acciones disponibles de una lista:
  
  y apilar eventos de esa manera

¡Lo que termina es una configuración de nodo muy limpia y eficiente!

Sugiero que los desarrolladores de Godot también prueben a Playmaker.
¡Reemplazar la pila de eventos con la lógica de Stencyl haría que el enfoque de Godot fuera mucho más flexible/poderoso!.

No tiene que ser solo a través de un enfoque stencyl. Creo que puede permitir que los programadores experimentados adjunten scripts gd a los nodos. Tener la opción de usar un enfoque stencyl para crear gdscripts sería invaluable en mi opinión. Invitará a muchos nuevos usuarios a la comunidad de Godot.

@blurymind
Bueno, pero eso es algo diferente. Fácil de usar no significa que deba verse como si fuera para niños.
El orden de ejecución y el filtrado asistido de entradas/salidas adecuadas para un nodo determinado son problemas comunes para los flujos de trabajo basados ​​en nodos. Diferente software lo resuelve de manera diferente.

Tienes que preguntarte: ¿quieres que más no programadores usen Godot? ¿Quiere hacer posible que las personas que no tienen experiencia con gdscript hagan algo divertido?

Si la respuesta es sí, entonces la mejor manera de hacerlo es dándoles un enfoque de secuencias de comandos visuales.
No estoy sugiriendo hacer que los nodos parezcan algo hecho para niños.
¡Lo que estoy sugiriendo es dividir esto en dos proyectos!

• Nodos utilizados como una máquina de estado, ¡como en Playmaker! Los programadores pueden nombrar cada nodo y adjuntarle gdscripts, con la entrada y la salida que configuran. Así que esto no es para niños en absoluto. De hecho, este es un enfoque mucho más flexible para los programadores que es mucho menos complicado.
• Una hoja de eventos de arrastrar y soltar o una interfaz de bloques como una forma alternativa de generar un GDscript. Entonces, en lugar de escribir un GdScript para adjuntarlo a un nodo, los no programadores pueden simplemente apilar acciones de una lista de todos los eventos disponibles en Godot, al igual que Playmaker. Para ir un paso más allá e innovar, en lugar de simplemente apilar acciones, sería aún mejor usar bloques similares a Stencyl.

De esta manera tienes algo que es útil tanto para programadores como para no programadores. Ambos pueden usar la máquina de estado (nodos) y los no programadores no tienen que aprender gdscript de inmediato y usar gdBlocks en su lugar para generar un gdscript para un nodo (nuevamente, como en Playmaker).

@blurymind
Me gusta más ese. También es consistente con Shader node-graph vs Shader-text que ya está en Godot.

SideFX Houdini tiene algo llamado VEX (https://goo.gl/TMWNKk) ("expresión vectorial", un lenguaje similar a c que está destinado al álgebra vectorial). Es algo así como gdScript. También tiene algo llamado "VOP" (http://goo.gl/Qpn2OE) (Operadores Vex): esencialmente envoltorios visuales de un subconjunto de VEX, que se parece mucho a la imagen del gráfico de nodo de LeadWerks a la que hizo referencia anteriormente. De hecho, los VOP se pueden convertir en el script de texto, si es necesario (pero no al revés).

La coexistencia de los 2 es bastante natural y permite, incluso a los no programadores, crear código muy desordenado e ineficiente;)

Personalmente, me gusta el enfoque Blueprint porque es muy diseñador de juegos.
gusta, pero insisto en que podría ser parcial.

Descargué Stencyl hace dos horas y jugué con él. yo podría ser
equivocado, pero creo que Stencyl es una buena herramienta para aprender porque no solo el
La parte de programación se simplifica pero la parte del motor también. la combinación es
bueno porque es un enfoque de programación simple para un motor de juego simple.

Pero Godot no es un motor de juego simple (al menos en comparación con Stencyl), así que
no creas que la programación simplificada sería tan útil. Stencyl confía en
un montón de cosas de lógica de juego codificadas que simplemente no estarán disponibles en
Godot, e intentar que esté disponible contradirá el objetivo de Godot de
siendo un motor de juego de propósito muy general.

El enfoque de nodos y gráficos es más interesante en mi opinión porque es
un nivel más bajo y una forma más flexible de hacer las cosas.

El martes 26 de mayo de 2015 a las 11:29, Vladimir Lopatin < [email protected]

escribió:

@blurymind https://github.com/blurymind
Me gusta más ese. También es consistente con Shader node-graph vs.
Shader-text que ya está en Godot.

SideFX Houdini tiene algo frío VEX (https://goo.gl/TMWNKk) ("vector
expresión" un lenguaje tipo c que está destinado a álgebra vectorial). Es
algo sinónimo de gdScript. También tiene algo llamado "VOP" (
http://goo.gl/Qpn2OE) (Operadores Vex): envoltorios esencialmente visuales de un
subconjunto de VEX, que se parece mucho al gráfico de nodo de LeadWerks que
mencionado anteriormente. De hecho, los VOP se pueden convertir en el script, si es necesario.
(pero no al revés).

La coexistencia de los 2 es bastante natural y permite, incluso
no programadores, para crear un código muy desordenado e ineficiente;)

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-105543845 .

¿Qué pasa con el apilamiento de acciones en Playmaker y blox en Unity? Unity no es un motor muy simple.

Creo que stencyl no es un muy buen ejemplo. Es mejor buscar ejemplos en la tienda de recursos de Unity.

Traté de entender a Playmaker pero fallé, ¿cómo se supone que funciona?

El martes 26 de mayo de 2015 a las 12:16 p. m., Todor Imreorov [email protected]
escribió:

¿Qué pasa con el apilamiento de acciones en Playmaker y blox en Unity? La unidad no es un
motor muy sencillo.

Creo que stencyl no es un muy buen ejemplo. es mejor buscar
ejemplos en la tienda de recursos de Unity.

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-105561760 .

revisé el tutorial de playmaker, pero parece ser similar a stencyl en
el sentido de que viene con un millón de comportamientos predefinidos

El martes 26 de mayo de 2015 a las 12:19, Juan Linietsky [email protected]
escribió:

Traté de entender a Playmaker pero fallé, ¿cómo se supone que funciona?

El martes 26 de mayo de 2015 a las 12:16 p. m., Todor Imreorov < [email protected]

escribió:

¿Qué pasa con el apilamiento de acciones en Playmaker y blox en Unity? La unidad no es un
motor muy sencillo.

Creo que stencyl no es un muy buen ejemplo. es mejor buscar
ejemplos en la tienda de recursos de Unity.

—
Responda a este correo electrónico directamente o véalo en GitHub
< https://github.com/okamstudio/godot/issues/1220#issuecomment-105561760
.

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-105563777 .

_OkamStudio_

Lo más cercano en Unity a los planos de U4 es uScript:
https://www.assetstore.unity3d.com/en/#!/content/1808

La gente parece preferir Armador de Jugadas a Gusto, ya que es más fácil entender la lógica que se ha configurado. Como puede ver en las capturas de pantalla, se vuelve muy complicado incluso para la lógica simple.

@reduz @okamstudio aquí hay una lista de reproducción en playmaker:
https://www.youtube.com/watch?v=I9VwsVtbgFU&index=2&list=PLC759306A1E692A10
Creo que deberías usarlo por un tiempo. Puede realizar comportamientos y secuencias de comandos predefinidos, pero el creador de jugadas también le permite acceder a las funciones principales del motor y crear tales comportamientos desde cero usted mismo.

Sí, el creador de jugadas es una máquina de estados y la unidad viene con muchos comportamientos predefinidos.
Godot también los tiene, están integrados en el motor.
Sigo creyendo que en realidad puedes crear un script/comportamiento desde cero usando el stencyl clone blox de unity.

Creo que por fin necesitas un programador para hacer un juego adecuado y esta idea
es genial que el diseñador del juego haga el juego por sí mismo, pero creo que es mucho
de trabajo que no viene bien en muchos casos. pero si tenemos mas
característica para el editor en sí mismo como el diseñador de plataformas que otra persona
mencionado en otro número u otras cosas útiles para facilitar la interfaz de usuario
más amigable
El 26 de mayo de 2015 a las 19:52, "Okam Studio" [email protected] escribió:

revisé el tutorial de playmaker, pero parece ser similar a stencyl en
el sentido de que viene con un millón de comportamientos predefinidos

El martes 26 de mayo de 2015 a las 12:19 p. m., Juan Linietsky < [email protected]

escribió:

Traté de entender a Playmaker pero fallé, ¿cómo se supone que funciona?

El martes 26 de mayo de 2015 a las 12:16, Todor Imreorov <
[email protected]

escribió:

¿Qué pasa con el apilamiento de acciones en Playmaker y blox en Unity? la unidad es
No un
motor muy sencillo.

Creo que stencyl no es un muy buen ejemplo. es mejor buscar
ejemplos en la tienda de recursos de Unity.

—
Responda a este correo electrónico directamente o véalo en GitHub
<
https://github.com/okamstudio/godot/issues/1220#issuecomment-105561760
.

—
Responda a este correo electrónico directamente o véalo en GitHub
< https://github.com/okamstudio/godot/issues/1220#issuecomment-105563777
.

_OkamStudio_

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-105565084 .

Aquí hay una revisión en la tienda de activos de Unity para uScript:

Buena herramienta, pero difícil de aprender si no eres programador... las respuestas a las solicitudes de ayuda en los foros son muy lentas o no existen en absoluto...

Lo que sea que termine en Godot, creo que, si es posible, sería una buena idea permitir la conversión unidireccional a GDScript. Esto permitiría configurar rápidamente las cosas visualmente, por parte de diseñadores y artistas y demás, y luego permitiría a los codificadores del equipo modificarlo y volver a trabajarlo sin tener que usar el pointy-clicky.

@adolson Esa sería una característica muy deseada :)

esto podría hacerse, y también podría hacerse con el editor de sombreado visual
(que, de hecho, genera código de sombreado)
pero creo que el código de sombreado generado no será tan legible como podría
esperar :P

El martes 26 de mayo de 2015 a las 6:33 p. m., Nathan [email protected] escribió:

@adolson https://github.com/adolson Eso sería muy deseado
característica :)

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-105670945 .

@reduz Se esperan algunos metadatos.
Aquí hay un ejemplo de conversión de VOP -> conversión VEX, como se indicó anteriormente:
:
Y aquí está la lista completa del código , que, de lo contrario, en VEX puro se ve así:
@P += vector({0,1,0}); // tomar posición y agregar vector (0,1,0)

Como puede ver, la cantidad de metadatos es significativa, pero no es difícil separar los 2, posiblemente analizarlos de forma semiautomática o totalmente automática.

@reduz Eso es cierto. Realmente no estaba pensando en eso. Probablemente no sea el tipo de código en el que la mayoría de los programadores querrían pasar su tiempo. Podría ver que las etiquetas se conviertan en nombres de variables y demás, pero no puedo ver mucho más para mitigar el problema.

Si bien no puedo hablar por todos, si veo un código desordenado, puedo tomar algunas partes de él, pero generalmente me siento inclinado a reescribirlo. Entonces, si ese es el caso, esto no valdría la pena para mí personalmente.

Ustedes realmente revisaron la gama de opciones. Utilicé Construct 2 y, aunque está limpio, nunca puedes tocar ningún código para refinarlo y las opciones eran bastante limitadas. La actualización del mapa de mosaicos básicamente eliminó los prefabricados y, por lo tanto, también la creación de instancias. El que realmente me gustó fue PlayMaker para Unity.

Algo sobre eso fue muy fácil de mantener el control de su alcance y lo que tenía que hacer. Este es un factor realmente atractivo, la razón por la que me gusta usar guiones visuales es precisamente por esto. Pierdo de vista lo que estaba haciendo o lo que necesito hacer en el código textual, pero ver cómo todo se 'conecta' tiene el mayor beneficio para mí. NateWardog publicó un ejemplo en una captura de pantalla mucho antes y blurrymind mucho más recientemente.

Digo reduz, ve por ello. Por ahora, si te vas a molestar, elegiría 1.3 o posterior e incluso entonces me concentraría principalmente en el lado frontal. Luego, cuando esté listo más adelante, concéntrese en lograr que genere un código legible como lo puede hacer Blueprint, lo que imagino que sería un gran desafío. ¡Por favor, no subestimes este!

suscribiendose ¡Estoy muy interesado en esto también! Conozco algunas secuencias de comandos y realmente no me importa usarlas... ¡pero prefiero conectar nodos cuando sea posible! Algo así como los ladrillos lógicos en Blender Game Engine, que actúan como atajos visuales para las funciones de script de Godot como una alternativa a escribirlas a mano... esa sería una característica encantadora y una que estoy esperando activamente.

Visual Scripting realmente atrae a muchas personas creativas o personas que no quieren aprender un nuevo lenguaje de scripting como gd script. Estaba viendo que el creador de juegos es tan popular y la única razón más dada es la mecánica de secuencias de comandos visuales.

Las secuencias de comandos visuales son tediosas, estúpidas y difíciles de usar.
Nunca veo una buena implementación. Las personas visuales deben dibujar gráficos. I
sé que muchas personas simplemente no pueden escribir,
pero esto no les hará ningún bien. Persona que no programa no significa
persona analfabeta

No conozco ninguna herramienta de construcción de lógica visual, que fue el sistema principal para
lógica de juego en cualquier motor.
La forma visual apesta en muchos aspectos. Las personas visuales suelen considerar
programación como "cosas tecnológicas"
significa algo en real de plomería y trabajo duro, y quiere estar por encima
eso. Esta actitud
generalmente se debe a algunos problemas intelectuales. no creo que esta gente
puede ser el público objetivo
básicamente limitan su creatividad.

El jueves 14 de abril de 2016 a las 8:33, Rémi Verschelde [email protected]
escribió:

Edit: Veo que cambiaste "RPG Maker" por "Game Maker", ahora hace más
sense :p Eliminando mi publicación.

—
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/godotengine/godot/issues/1220#issuecomment-209770726

No quiero, pero tengo que decirlo, pero esa es una visión muy limitada de las herramientas de secuencias de comandos visuales, Sergey. En cuanto a los juegos que se han creado completamente con ellos, algunos motores los han optado por completo, como Construct, por lo que no verá ningún juego fuera de ese motor hecho con secuencias de comandos regulares. Otro motor (más cuerdo, en mi opinión) tiene complementos como Unity y UE4. Personalmente, me gustó mucho usar tanto uscript como PlayMaker en Unity junto con mi código normal porque, si bien algunas cosas son más fáciles de codificar, muchas son más fáciles de crear visualmente, en particular las máquinas de estado porque con un scripter visual como PM te brinda muchos comentarios con breakpointsw es mucho más fácil ver el proyecto desde una vista más amplia.

Lo real acerca de las secuencias de comandos visuales en general, es un intento inútil de
hacer que la programación sea accesible para los no programadores, lo cual es totalmente incorrecto
Acercarse.
La programación visual es más difícil que la programación de texto normal. Para hacerlo
más fácil tienes que escribir muchos bloques para cada caso en la vida en tradicional
camino y
que estas personas los usen. Estos demostraron ser menos efectivos que pedirle a un
buen programador para escribir código. El dicho "programar no es una profesión,
todos pueden hacerlo" está mal. Todos los intentos de programar sin
La programación es un desperdicio.

En cuanto a la máquina de estado, estaba pensando en implementar esto en algún momento
hace, pero eso no ayudará al programa de imágenes altas.
Esto se puede hacer fácilmente para su juego usando el script de herramientas y el editor de nodos,
que es una herramienta poderosa, muchas personas la usan para herramientas de juego, como
Editores de diálogos de juegos.

El jueves 14 de abril de 2016 a las 9:09 a. m., Aaron M [email protected] escribió:

No quiero tener que decirlo, pero esa es una visión muy limitada de lo visual.
herramientas de secuencias de comandos, Sergey. En cuanto a los juegos que se han hecho íntegramente con ellos,
algunos motores han optado por ellos por completo, como Construct, por lo que
no verá ningún juego fuera de ese motor hecho con secuencias de comandos regulares. Otro
(más cuerdo, en mi opinión) el motor tiene complementos como Unity y UE4. yo personalmente
Me gustó mucho usar uscript y PlayMaker en Unity junto con mi habitual
código porque mientras algunas cosas son más fáciles de codificar, muchas son más fáciles de
script visualmente, particularmente máquinas de estado porque con un visual
scripter como PM, le brinda muchos comentarios con puntos de interrupción, es solo
mucho más fácil ver el proyecto desde una vista más amplia.

—
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/godotengine/godot/issues/1220#issuecomment-209776732

Slap, tienes razón. Pero olvidas que la programación visual o los bloques de programación tienen una tasa de fallas muy baja. Es por las limitaciones.
Es básicamente lo mismo cuando tomas un lenguaje de programación muy limitado. No puedes cometer muchos errores.

¡Creo que este debería ser el objetivo a lograr, no la cuestión de si Visual- o Text-Scripting!

Si quieres mejorar la programación, mejora las herramientas. Resaltado de código, finalización de código, validación de código, plantillas de código, etc. Mejore el depurador y haga Liveprogramming.
Siempre busqué un entorno Liveprogramming estable, ¡pero hasta ahora no lo encontré!

Si realmente quiere hacer Visual Scripting, hágalo como Stingray Engine. Puede crear CodeBlocks en Visual y generar TextCode que luego puede modificar, o escribir TextCode que luego puede usar como Visual Blocks.

No diría que es inútil, pero diría que estamos hablando de 2
productos completamente diferentes.

Si tienes un estudio y haces juegos con, digamos, 20 u 80 personas,
usted está gastando 6 cifras en costos de producción cada mes, y necesita un
motor para hacer tus juegos, quieres un determinado producto. En ese caso, usted
no te importan en absoluto las herramientas de secuencias de comandos visuales, te preocupas por otras
cosas, como qué tan productivo será su equipo con las herramientas del motor
(ya que si superan el cronograma durante un mes, te quedas sin ~ $ 100k). Aquellos
los equipos tienen programadores, y serán mucho más productivos escribiendo código
que usar alguna herramienta visual (busque Vicious Engine para ver un ejemplo de eso)

Por otro lado, si tienes una buena idea y realmente no sabes cómo
escribe código, quieres otro producto, algo para hacer un prototipo rápido que
puede mostrar y eventualmente dar a los programadores para hacer el verdadero
juego.

Son 2 productos diferentes, y si discutimos sobre cuál vale más
tener, tenemos que reconocer eso. Diría que el guion visual
La herramienta realmente no se amplía a más de 1 persona que hace un prototipo. Como
tan pronto como quieras hacer un juego completo, o tan pronto como tu equipo crezca a 2-3
Gente, ya necesitas un lenguaje de programación real. pues me gusta el primero
ejemplo más como un objetivo general (a menos que desee un tercer producto, que es
"el motor que puedes usar para crear un juego independiente completo que genere millones
sin escribir ningún código". Eso no existe).

Pero podemos tener ambos, y no desanimaría a ninguno. una visual
herramienta de secuencias de comandos nos ayudaría a largo plazo, al crear usuarios principiantes
que eventualmente trabajará en la industria y estará en posiciones para decidir
Usa Godot para un juego real, y eso es bueno. Además, el CTO de Square Enix
nos preguntó si el motor tenía un lenguaje de creación de prototipos visuales, lo que significa
también hay un nicho en las grandes empresas para ese tipo de cosas, probablemente
que valoran la I+D+i y tienen largas etapas de
preproducción/creación de prototipos/experimentación con nuevas ideas, etc. (también dijo
nos dijo que nuestros juegos parecían juegos de consola y preguntó (dos veces) qué país
fuimos a para aprender a hacerlos :p ).

El 14 de abril de 2016 a las 03:26, Sergey Lapin [email protected] escribió:

Lo real acerca de las secuencias de comandos visuales en general, es un intento inútil de
hacer que la programación sea accesible para los no programadores, lo cual es totalmente incorrecto
Acercarse.
La programación visual es más difícil que la programación de texto normal. Para hacerlo
más fácil tienes que escribir muchos bloques para cada caso en la vida en tradicional
camino y
que estas personas los usen. Estos demostraron ser menos efectivos que pedirle a un
buen programador para escribir código. El dicho "programar no es una profesión,
todos pueden hacerlo" está mal. Todos los intentos de programar sin
La programación es un desperdicio.

En cuanto a la máquina de estado, estaba pensando en implementar esto en algún momento
hace, pero eso no ayudará al programa de imágenes altas.
Esto se puede hacer fácilmente para su juego usando el script de herramientas y el editor de nodos,
que es una herramienta poderosa, muchas personas la usan para herramientas de juego, como
Editores de diálogos de juegos.

El jueves 14 de abril de 2016 a las 9:09 a. m., Aaron M [email protected] escribió:

No quiero tener que decirlo, pero esa es una visión muy limitada de lo visual.
herramientas de secuencias de comandos, Sergey. En cuanto a los juegos que se han hecho completamente con
ellos,
algunos motores han optado por ellos por completo, como Construct, por lo que
no verá ningún juego fuera de ese motor hecho con secuencias de comandos regulares. Otro
(más cuerdo, en mi opinión) el motor tiene complementos como Unity y UE4. yo personalmente
Me gustó mucho usar uscript y PlayMaker en Unity junto con mi habitual
código porque mientras algunas cosas son más fáciles de codificar, muchas son más fáciles de
script visualmente, particularmente máquinas de estado porque con un visual
scripter como PM te da muchos comentarios con breakpointsw es
sólo
mucho más fácil ver el proyecto desde una vista más amplia.

—
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente o véalo en GitHub
< https://github.com/godotengine/godot/issues/1220#issuecomment-209776732

—
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/godotengine/godot/issues/1220#issuecomment-209779422

Simplemente me estás hablando de punto slapin, quiero decir, nunca dije nada sobre diseñadores o simplificación, sino sobre facilidad de uso incluso para programadores, que he experimentado su utilidad. No es como si pudieras decirme que es una pérdida de tiempo cuando tengo la experiencia anecdótica que muestra exactamente lo contrario. Prefiero que la opción esté disponible junto con el guión, estás actuando como si solo pudiera elegir uno u otro y me veo obligado a dárselo a mi artista. No es el caso en absoluto.

Impresionante hilo, muchas opiniones 😁

El mío es sencillo. ¡Estás bien!

Cualquiera de estas ideas será una gran adición a gdscript 😁

Estoy deseando probarlos cuando aparezcan.

Creo que a gdscript también le vendría bien un poco de amor para ser más fácil de usar.

Algunos nodos no están completamente documentados. Muchos no tienen descripciones.
Godot podría hacer uso de algunas funciones auxiliares para simplificar el desarrollo. Gamemaker gml es un buen ejemplo:
https://twitter.com/uheartbeast/status/724326557108461568

Creo que el tema de la documentación es PITA importante aquí, y eso es todo.
El desarrollo en sí es bastante simple. La documentación y los tutoriales.
son realmente necesarios. Así que solo haz que tu cuenta de youtube sea útil (o blog, o
simplemente publicar en el foro),
eso será de mucha ayuda.

El lunes 25 de abril de 2016 a las 9:35 a.m., Todor Imreorov [email protected]
escribió:

Creo que a gdscript también le vendría bien un poco de amor para ser más fácil de usar.

Algunos nodos no están completamente documentados. Muchos no tienen descripciones.
Godot podría hacer uso de algunas funciones auxiliares para simplificar el desarrollo.
Gamemaker gml es un buen ejemplo:
https://twitter.com/uheartbeast/status/724326557108461568

—
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/godotengine/godot/issues/1220#issuecomment-214163012

Bueno, tengo varias ideas sobre esto.
Puede hacer que un motor sea más fácil de abordar al incluir algo como secuencias de comandos visuales, y eso sería bueno para todos los artistas que querían comenzar a crear juegos pero que simplemente no tienen experiencia en programación, pero eso invita a otro conjunto de personas, a saber , personas sin habilidades de ningún tipo. Las personas para las que cambiar a la programación en un editor de texto nunca estará en su agenda, incluso si eso significa que el juego final se verá afectado. Gente que piensa que lo único difícil de hacer un juego es la programación, y que con el scripting visual, de repente, se levanta esta restricción. Esto tampoco es raro. Solo mire todos los motores populares que hacen que ciertas cosas sean más fáciles para los no programadores: toneladas de shovelware. No digo que no debas incluir secuencias de comandos visuales porque significa que corremos el riesgo de obtener shovelware, pero debe implementarse de una manera que disuada a este tipo de personas de pensar que pueden usar Godotengine para hacer dicho shovelware.
Mi otro problema es que una de las cosas en las que Godotengine es bueno, y a mucha gente le gusta esta función, es que funciona muy bien con git. El problema con las secuencias de comandos visuales es que a menudo se guardan en algún formato binario, y es una pesadilla manejarlo si usa algún tipo de revisión del código fuente. Si tiene que implementar secuencias de comandos visuales, debe guardarse de una manera compatible con el texto. Y si eso es imposible, pues duro. Prefiero tener archivos de proyecto en Godotengine en un formato que sea compatible con git que tener secuencias de comandos visuales que no funcionen bien con git.
Y a juzgar por todo el trabajo que se requiere para implementar un sistema de secuencias de comandos visuales, y el hecho de que puedes hacer ciertos tipos de juegos en Godotengine sin secuencias de comandos visuales sin pérdida de funcionalidad, eficiencia o rendimiento, ¿qué tiene de malo implementarlo como un complemento? Realmente no veo ninguna razón por la que tenga que ser una parte central del motor.

Solo para agregar mis 2 centavos sobre secuencias de comandos visuales y por qué no me gusta la idea:

Creo que la capacidad de conectar nodos en cualquier archivo gdscript es mucho mejor, en términos de gestión de código y competencia.

Por ejemplo, con secuencias de comandos visuales (o usando una hoja de eventos similar a C2), ¿qué sucede si tiene más de 1000 funciones? Será mucho peor, creo, navegar a través de todo. Estoy transfiriendo mi juego RPG de acción HTML 5 ahora mismo a Godot (que tiene más de 10k + líneas de código y muchas más de 500 funciones). _(Básicamente tiene todas las características que tiene Path of Exile, excepto las animaciones y es multijugador)_

No hay forma de que esto sea posible para mí con secuencias de comandos visuales. Creo que nosotros, y los desarrolladores de Godot aquí, deberíamos centrarnos más en las características/eliminación de errores que en una hoja de eventos de código visual. Pero así soy yo :)

Editar: como han dicho otros, tal vez para proyectos más pequeños, supongo ... pero nada grande, simplemente no puedo ver que sea útil

La hoja de eventos en construct2 admite funciones y funcionan igual que godots. Un simple cuadro de filtro/búsqueda resolverá todos los errores que enumeró.

Pero los desarrolladores de Godot no quieren hacer un enfoque de hoja de eventos, incluso si es un cajero automático popular. Tengo la impresión de que es más probable que obtenga algo parecido al enfoque irreal del plano. De esa manera, los programadores se beneficiarán de un editor de máquina de estado agregado a su arsenal.

Para organizar el código de secuencias de comandos visuales en vonstruct2, lo coloca en grupos que se pueden colapsar. Esto es algo que incluso gdscript no puede hacer: no puede colapsar bloques de código. Entonces, de alguna manera, la hoja de eventos tiene ventajas sobre el editor gdscript de Godots.

@reduz Estaba mirando Pure Data y la forma en que lo hacen es muy simple. Bueno mira esto

Como puede ver, escribir "Bang" convierte el objeto genérico en un objeto Bang.

¿Qué pasaría si las secuencias de comandos visuales pudieran convertirse simplemente en una extensión de GD Script? Simplemente coloque un nodo genérico y escriba Vector2 para ex y se convertirá en un objeto Vector2. Entonces, esencialmente, cada clase/objeto también es un nodo.

Para ejecutar funciones, creo que puede obtener otro nodo que no sea un objeto sino un nodo de proceso y escribiría algo como Vector2.dot y el nodo se convertirá en un nodo de punto con 2 entradas y 1 salida.

el scripting visual está planeado en algún momento

No decepcionaste :) <3

Dado que ya existe VisualScripting, ¿debería cerrarse este problema?

Si.

"También sonreí de manera positiva.
Porque sería genial para mí como jugador si hubiera una empresa tan grande como Steam con toneladas de catálogo de juegos, abiertos y libres de DRM, creados por miles de grandes desarrolladores de juegos".
solo mira gog, es una tienda que vende juegos gratuitos de drm.

Respondiendo fuera de tema a una declaración de 2015, vamos :)