Godot: C# como lenguaje de programación

En mi opinión, agregar más funciones a GDscript sería una mejor manera de abordar la creación de scripts.

Para mí, la principal razón para elegir a Godot sobre otros motores de juegos es el esquema de secuencias de comandos simplificado. Godot no se ofrece a aprender un nuevo lenguaje de programación. Ofrece aprender Godot y su lenguaje de secuencias de comandos como una herramienta combinada para el desarrollo de juegos. Este es un enfoque menos intimidante que ofrecer a los recién llegados que aprendan C++ o cualquier otro lenguaje de programación para secuencias de comandos.

Gracias por abrir este número, creo que este es un tema en el que hay una gran diferencia entre la mejor opción racional y lo que pedirá la mayoría.

La razón más importante por la que existe más de un motor es que, además de factores unidimensionales como el rendimiento en tareas generales o la accesibilidad de las interfaces, existen factores multidimensionales como el rendimiento en situaciones específicas (no hay un ganador obvio si compara un motor optimizada para juegos en 3D y una optimizada para juegos en 2D) o usabilidad para grupos específicos de usuarios (una interfaz que es amigable para principiantes generalmente tiene que ocultar funciones avanzadas).
Entonces, para encontrar un lugar entre otros motores, un motor debe elegir una "filosofía".

Ahora, un lenguaje de secuencias de comandos es una parte integral de un motor, por lo que la filosofía del lenguaje debe encajar con la filosofía del motor, o al menos no debe contradecirla.

Entonces, ¿cuál es la filosofía de Godot? Veamos algunos hechos:

• Comparado con Godot, todos los demás motores principales están inflados.
  La descarga de Godot es menor a 20 MB, toda la "instalación" es un ejecutable que tiene menos de 50 MB de tamaño. Lumberyard, por otro lado, tiene un tamaño de descarga inicial de aproximadamente 5,5 GB, actualmente mi carpeta de instalación tiene un tamaño de 15,3 GB. La razón principal de esto es la filosofía de Amazon con respecto a las dependencias. Esa descarga inicial contiene 10,5 GB de imágenes integradas de 42 dependencias, y si ha trabajado antes con los servicios web de Amazon, sabe que el SDK de AWS no es tan diferente en ese aspecto, por lo que no es una cuestión de necesidad o habilidad, es una cuestión de elección. Por ejemplo, mientras que Lumberyard incluye boost y Lua, Godot contiene sus propias versiones de los contenedores STL más importantes y usa GDScript en lugar de lua, lo que reduce el tamaño, elimina las dependencias y hace que el código sea mucho más legible y accesible.
• El código fuente de Godot es muy accesible.
  Eso comienza con la elección del sistema de compilación (SCons) que usa python como lenguaje de compilación. La mayoría de los demás proyectos utilizan sistemas de compilación existentes con lenguajes de compilación patentados o escriben su propio sistema de compilación patentado, lo que tiene un impacto negativo en la legibilidad del código de compilación.
  El código fuente en sí también está por encima del promedio en ese aspecto. Me tomó casi el mismo tiempo descubrir cómo escribir un solo nodo de Unreal Blueprint en C++ que escribir el código para mi primera solicitud de extracción a Godot. Eso no quiere decir que el código C++ de Unreal fuera ilegible, simplemente no es tan limpio como el de Godot, ya que usa más macros y requiere que el usuario comprenda más del código del proyecto predeterminado de Unreal que Godot.
• Godot promueve los principios KISS y OO.
  Para ilustrar eso, veamos algunos objetos simples en Unity. El primer concepto al que te enfrentas en Unity es el de GameObjects con componentes adjuntos. "composición sobre herencia", como suele llamarse (prefiero la formulación de Michael J. Dickheiser "Contención versus herencia" de "C++ para desarrolladores de juegos", que no suena como un grito de guerra y promueve la reflexión sobre el tema) es un patrón exitoso por la flexibilidad que ofrece. Sin embargo, esa flexibilidad tiene un costo. Si todo en su juego es un GameObject, realmente no puede obtener una referencia a "el jugador", porque no hay un jugador, solo hay un GameObject que puede o no tener un componente de jugador adjunto (o más bien esos varios componentes que hacen subir el jugador).
  Los desarrolladores de Unity vieron el mismo problema, a veces solo desea crear un botón, no un GameObject con el componente Button. Entonces, lo que hicieron es esto: te permitieron crear "un botón" a través de la interfaz del editor que en realidad crea un GameObject con un componente de botón adjunto. Además de eso, enrutaron a los miembros más importantes de GameObject a través de cada Componente, de modo que ahora puede usar una referencia a un Botón tal como usaría una referencia a un GameObject. Puede pedirle a un Botón su posición, puede pedirle una lista de sus componentes, aunque el Botón es en realidad un componente, no el objeto al que está adjunto.
  Así que ahora tenemos una mezcla de las dos formas más populares de describir el mundo de un juego: basado en la composición y en objetos simples. Pero cuando observa los proyectos de principiantes (e incluso algunos proyectos avanzados), encontrará que Unity también facilita la tercera forma de interpretar el mundo de un juego: la programación procedimental.
  En Unity, cada objeto es siempre parte de una "escena". A diferencia de Godot, ese término describe una parte del juego de alto nivel (descargo de responsabilidad: ahora Unity tiene un SceneManager que se encuentra encima de las escenas, pero mi punto sigue siendo válido), lo que significa que si un enemigo quiere dispararle al jugador, simplemente puede busque su escena actual para el jugador e interactúe con él. Esa es la idea central de la programación de procedimientos: tiene una secuencia de comandos que alteran el estado del entorno sin tener en cuenta la propiedad. Por supuesto, técnicamente sigue siendo programación orientada a objetos, pero como cada objeto puede esperar ser parte de la misma escena, puede escribir código que se comporte como código global. Por ejemplo, si desea crear una instancia de un objeto, todo lo que tiene que hacer es llamar a "Instanciar (templateObject)" y se instanciará una copia de templateObject y se agregará a la escena. No es necesario preguntar a qué escena agregar el objeto porque siempre hay una escena de la que todo forma parte actualmente.
  Entonces, Unity promueve una mezcla de composición, pensamiento orientado a objetos y programación procedimental.

Godot, por otro lado, promueve el pensamiento orientado a objetos, ya que, por ejemplo, cada objeto de tu juego se puede construir como una escena propia. Esas escenas pueden iniciarse por sí mismas, lo que le permite probarlas, modificarlas por sí mismas, etc. Eso a su vez requiere que construya esas escenas de una manera que no requiera acceder al entorno. Por ejemplo, si un enemigo quiere interactuar con el jugador, es mucho más factible usar señales para decirle a la escena subyacente que se solicita una interacción o simplemente requerir que la escena le dé al enemigo una referencia al jugador. Todavía puedes buscar al jugador en la escena del juego, pero si lo haces, la escena enemiga no podrá ejecutarse por sí sola, por lo que el diseño simplemente no se ajusta a las herramientas.

Entonces, ¿cómo hace esto una diferencia con respecto a la elección de los lenguajes de secuencias de comandos?
C# es para los lenguajes lo que Unity es para los motores. La filosofía de C# siempre ha sido que si alguna característica sería buena para agregarla al lenguaje. Solo mire la lista de funciones que se agregaron con cada versión: https://en.wikipedia.org/wiki/C_Sharp_ (programming_language)#Features_added_in_versions
Ahora puede argumentar que tener una función no es algo malo, ¿verdad? No tienes que usarlo, solo déjalo si no te gusta. Desafortunadamente, eso no es cierto para un idioma. Con la importancia de Internet hoy en día, los idiomas ya no son herramientas, son culturas. Tarde o temprano tendrá que buscar ayuda en Google, usará módulos u objetos creados por otros, usará nuevas funciones integradas por la comunidad en el motor y, tarde o temprano, eso requerirá que use funciones de lenguaje que nunca pretendió. usar.
Además, si trabaja en equipo, aprenderá a apreciar el uso de un lenguaje que promueve un estilo de codificación común y no le ofrece docenas de formas de escribir el mismo código.

Ahora puede preguntarse si quiero decir que un idioma con menos funciones siempre es mejor que uno con más funciones. Por supuesto que ese no es el caso. Comparemos cómo Java resolvió el problema.
C# le permite escribir código no administrado. Simplemente use la palabra clave adecuada y puede usarla directamente en el mismo archivo. También le permite escribir código funcional usando LINQ, que se lee como código SQL y se comporta como código funcional. Para comprender completamente lo que hace un archivo, es posible que necesite saber bastante sobre paradigmas de programación.
Si está escribiendo Java, también puede usar programación funcional, solo tiene que escribirlo en un archivo separado, usar un compilador diferente y llamarlo "programación Clojure". Si prefiere combinar programación funcional y orientada a objetos, puede llamarlo "programación Scala". La parte importante es que todavía está escribiendo código para JVM que puede interactuar fácilmente con código de otros lenguajes de JVM.
Los lenguajes .NET tienen la misma capacidad, solo que no se usa en la filosofía C#. Podrían haber decidido apegarse a uno o dos paradigmas de programación en C# y crear un nuevo lenguaje para agregar nuevos paradigmas, pero en cambio optaron por "un lenguaje para conquistarlos a todos", lo cual está totalmente bien, es genial tener un idioma así. Solo debe ser consciente de esa filosofía y las opciones que tiene como programador.

Para resumir: de todos los lenguajes que tenemos, creo que C# es el que peor se adapta a Godot. Es una opción natural para Unity, pero si tiene todas esas opciones, ¿por qué elegir un lenguaje que promueva la mezcla y combinación de paradigmas en un motor que promueva principios limpios de OO y programación KISS en cada una de sus partes?

Entonces, si cree que C# sería una buena adición a Godot, entonces NO estoy en desacuerdo con usted; simplemente digo que existen alternativas que son incluso mejores, que deberían evaluarse primero y que se olvidarían de inmediato una vez que se implemente C#.

@hubbyist

En mi opinión, agregar más funciones a GDscript sería una mejor manera de abordar la creación de scripts.

Seguro que eso puede pasar, no creo que sea incompatible con las otras propuestas.

Para mí, la principal razón para elegir a Godot sobre otros motores de juegos es el esquema de secuencias de comandos simplificado. Godot no se ofrece a aprender un nuevo lenguaje de programación. Ofrece aprender Godot y su lenguaje de secuencias de comandos como una herramienta combinada para el desarrollo de juegos. Este es un enfoque menos intimidante que ofrecer a los recién llegados que aprendan C++ o cualquier otro lenguaje de programación para secuencias de comandos.

Pero Godot ya se puede usar desde C++, por lo que nada cambiaría realmente (siempre que se mantenga GDScript), excepto que la codificación en C++ sería más fácil para aquellos que quieran hacerlo (actualmente, escribir módulos requiere compilar todo Godot, y no está integrado en el flujo de trabajo).

@Warlaan buen análisis. Si leíste mi publicación, tampoco estoy de acuerdo con que C# sea una buena elección para Godot, por eso propuse expandir las capacidades de C++ ya existentes para hacer posible su uso como lenguaje de secuencias de comandos, siendo GDScript el lenguaje predeterminado para la mayoría de los usuarios.

Los usuarios deberían poder escribir prácticamente en GDScript, sin embargo, no es razonable pensar que un juego grande se escribiría en GDScript. En mi opinión, no hay nada que impida que Godot sea adecuado para juegos grandes, excepto el rendimiento de GDScript, porque el motor está muy bien diseñado y ya tiene un rendimiento bastante bueno (y Vulkan probablemente lo mejorará aún más).

En mi opinión, el rendimiento no atrae a la mayoría de los usuarios de Godot, pero podría atraer a más profesionales a Godot, lo que significa más contribuciones, lo que significa un mejor Godot para todos.

@paper-pauper Entendí que estamos del mismo lado. Cuando escribí "si crees que C# sería una buena adición" me estaba dirigiendo a "tú, el lector anónimo", no a ti personalmente. ;-)
Y sí, cualquier nuevo lenguaje de secuencias de comandos desviará la atención de GDScript. Dudo que la comunidad se ocupe de más de un idioma, tarde o temprano algunas funciones no estarán disponibles o no estarán disponibles en ninguno de ellos, tal vez incluso hasta el punto de que uno de los idiomas se elimine.

También estoy de acuerdo en que los únicos problemas reales aquí son los tiempos de compilación de C++ y el rendimiento de GDScript.
El argumento de que la gente ya conocía C# es simplemente incorrecto en mi humilde opinión. He estado trabajando profesionalmente con C# durante aproximadamente 4 años (principalmente trabajando con C++ y SQL) y lo único que he aprendido en ese tiempo es que lo más probable es que nunca pueda decir que realmente conozco ese idioma. Después de todo, con C# 6 y las propuestas para 7, la cantidad de características sigue creciendo.
Entonces, cuando hablamos de "conocer C #", todo lo que realmente podemos referirnos es conocer la sintaxis más básica que incluso el peor principiante debería poder volver a aprender en unos pocos días. Recientemente di una conferencia sobre diferentes motores de juegos a una clase de diseñadores de juegos que antes usaban exclusivamente Unity y ninguno de ellos comentó mal sobre la sintaxis de GDScript mientras que, de hecho, varios que habían renunciado a la programación ahora están nuevamente motivados.

Así que sí, una solución que acelere GDScript y haga que C++ sea menos engorroso de compilar y usar también sería mi favorita.

Mucha gente que "conoce" C# no usa muchas de sus características que lo diferencian de Java. Solo eche un vistazo a la gran cantidad de scripts de Unity que no van mucho más allá de las subclases.

Solo por esta razón, soy muy escéptico acerca de las ventajas prácticas que ofrecería C#. Son agradables en muchos contextos, pero no en el desarrollo de juegos. Además, C++1x ya ofrece muchas de esas cosas (incluida la inferencia de tipos, los iteradores y algunas herramientas funcionales básicas) sin gastos generales.

Además, es posible que la sobrecarga generada por el CLR (o incluso la JVM) pueda hacer que Godot funcione _peor_, aunque veo algunas ventajas en el uso del recolector de basura de la JVM (¿alguien sabe más sobre la administración de memoria de Godot)?

Leí en foros sobre personas que no usan Godot debido a GDScript. Creo que es de mente cerrada, porque no tiene nada de malo, excepto el hecho de que tiene una mala selección de bibliotecas, lo cual traté de abordar en otro ticket, el n.° 3943, al sugerir una solución que no tiene gastos generales y es multiplataforma. apoyo.

Sin tener que implementar un JIT de C++ a través de LLVM, hay una solución que se ejecuta en código nativo y no requiere jugar con las fuentes de Godot: la vinculación dinámica.

El primero permitiría el código nativo sin tener que volver a compilar Godot desde cero: simplemente lo compila como un archivo .so y luego lo agrega a su ruta de carga, luego lo usa desde GDScript sin sobrecarga (ya que son todas llamadas a funciones).

Esto debería ser muy fácil de hacer (¿a través de libdl?) Pero, por lo que entendí, no se hace debido a preocupaciones entre plataformas.

Además, existe la idea de compilar GDScript en C++, como lo hace ENIGMA con su lenguaje. Esto no es fácil, pero obviamente ofrece el mejor rendimiento.

¿Alguien sabe más sobre la gestión de memoria de Godot?

De los documentos :

Si una clase hereda de Reference, las instancias se liberarán cuando ya no estén en uso. No existe un recolector de basura, solo un simple recuento de referencias. De forma predeterminada, todas las clases que no definen la herencia amplían la Referencia. Si no se desea esto, entonces una clase debe heredar Object manualmente y debe llamar a instance.free(). Para evitar ciclos de referencia que no se pueden liberar, se proporciona una función de referencia débil para crear referencias débiles.

Solo para notar...

Una gran ventaja de GDscript es que es un lenguaje que está completamente bajo el control de Reduz y los otros desarrolladores, la forma en que funciona para los desarrolladores de Godot no depende de un equipo externo y, como tal, puede desarrollarse de una manera específica para el el diseño del motor y tener lo que los usuarios están solicitando.

Otra cosa es que, si bien GDscript no es un lenguaje de alto rendimiento real en este momento, es probable que haya muchas áreas en las que el rendimiento se puede mejorar en gran medida al mismo tiempo que se conserva su simplicidad y naturaleza de escritura dinámica.

Luego está el hecho de que GDscript no requiere ningún conocimiento de compilación y que no necesitas nada fuera del editor incorporado de Godot (lo que hace que el flujo de trabajo sea agradable y ordenado, sin mencionar que es fácil y rápido).

Solo una pregunta, ¿cómo funciona internamente el intérprete de GDscript? ¿Analiza cada línea en tiempo de ejecución como el antiguo lenguaje básico o convierte todo el script en tablas de código de bytes y luego ejecuta el código de bytes?

@rebeldex

https://github.com/godotengine/godot/blob/master/modules/gdscript/gd_compiler.cpp
https://github.com/godotengine/godot/blob/master/modules/gdscript/gd_parser.cpp

¡No creo que haya lenguajes serios que funcionen como BASIC! :)

¡Hola!
Aquí está la historia de GDScript:
///////////////////////////
Historia
Inicialmente, Godot fue diseñado para admitir múltiples lenguajes de secuencias de comandos (esta capacidad aún existe en la actualidad). Sin embargo, solo GDScript está en uso en este momento. Hay un poco de historia detrás de esto.

En los primeros días, el motor usaba el lenguaje de programación Lua. Lua es rápido, pero crear enlaces a un sistema orientado a objetos (mediante el uso de respaldos) fue complejo y lento y requirió una enorme cantidad de código. Después de algunos experimentos con Python, también resultó difícil de integrar.

El último lenguaje de secuencias de comandos de terceros que se usó para los juegos enviados fue Squirrel, pero también se eliminó. En ese momento, se hizo evidente que Godot funcionaría de manera más óptima si usaba un lenguaje de secuencias de comandos integrado, ya que se superaban las siguientes barreras:

• Godot incrusta scripts en los nodos, la mayoría de los lenguajes no están diseñados con esto en mente.
• Godot usa varios tipos de datos incorporados para matemáticas 2D y 3D, los lenguajes de script no proporcionan esto y vincularlos es ineficiente.
• Godot usa hilos en gran medida para levantar e inicializar datos de la red o el disco, los intérpretes de scripts para lenguajes comunes no son amigables con esto.
• Godot ya tiene un modelo de gestión de memoria para recursos, la mayoría de los lenguajes de script proporcionan el suyo propio, lo que resultó en errores y esfuerzos duplicados.
• El código vinculante siempre es desordenado y da como resultado varios puntos de falla, errores inesperados y falta de mantenimiento general.

Finalmente, GDScript se escribió como una solución personalizada. El lenguaje y el intérprete terminaron siendo más pequeños que el propio código vinculante para Lua y Squirrel, e igualmente funcionales. Con el tiempo, tener un lenguaje integrado ha demostrado ser una gran ventaja
/////////////////////////

En mi opinión, C++ puede ser mejor. Hay algunas soluciones como:
https://github.com/RuntimeCompiledCPlusPlus/RuntimeCompiledCPlusPlus
Incluso el script Angel normalmente puede ser como un tiempo de ejecución compilado.
En secuencias de comandos, me encanta python porque siempre me gustan las soluciones que combinan juegos y simulaciones científicas (python tiene muchas bibliotecas científicas). ¡Así que me quejo! en otro número por qué Godot tiene su propia biblioteca de física: https://github.com/godotengine/godot/issues/4217
Hay algunos problemas con lenguajes como C#: https://github.com/godotengine/godot/issues/2790

Buen hallazgo, @alabd14313 : eso resolvería casi la mayoría de los problemas, dejando solo a GDScript.

Lo de RCCPP, es una muy buena idea. Creo que si Godot lo admitiera en el modo editor y luego lo deshabilitara en las compilaciones, habría un rendimiento máximo y los tiempos de iteración serían bastante rápidos. Escuché que otros motores como Unreal Engine hacen algo similar con C++, y creo que sería bastante bueno si Godot permitiera una codificación C++ similar a las secuencias de comandos.

Parece que los autores saben lo que hacen, porque en esta página enumeraron la mayoría de las alternativas a su enfoque (incluido el que mencioné, el LLVM JIT).

Creo que este enfoque tiene más sentido, porque Godot está escrito en C++ (y no creo que eso vaya a cambiar nunca, considerando que C++ será aún mejor en unos años), ya tiene una API de C++ y C++ en funcionamiento. tiene prácticamente el máximo rendimiento deseable sin gastos generales y no habría tiempos de ejecución ni administradores de memoria adicionales. Espero que los desarrolladores le echen un vistazo.

Estoy un poco sorprendido de descubrir que este hilo que afaik se inició como una reacción a la propuesta de agregar C# como lenguaje de secuencias de comandos aún no contiene un solo argumento PARA C#, incluso después de que seis personas hayan expresado su opinión.
Tal vez la decisión de agregar C# no sea tan premeditada como supuse por los rumores que escuché.

@Warlaan , ¿qué sucederá si publica esta URL en un grupo de Facebook? :)

Cambie el título a algo como "C++ como lenguaje de secuencias de comandos".
C ++ 17 tiene más características:
http://blog.mattnewport.com/por qué-c17-es-el-nuevo-lenguaje-de-programación-para-juegos-que-quiero/
Admiro a los desarrolladores de Godot y les agradezco su trabajo. pero me resisto a las bibliotecas Box2D/LiquidFun/Bullet. De esta forma, los desarrolladores pueden concentrarse en la canalización, no en componentes como la física. Con C++ pueden concentrarse en el rendimiento, no en mantener y actualizar gdscript. Teóricamente, RCCPP puede implementar algunas características nuevas como el modo de herramienta de una mejor manera. Tal vez...

@reduz mencionó hace unos meses que quería implementar scripting visual, algo así como planos irreales. Con RCCPP, el flujo de trabajo entre C++ (para programadores) y Visualscripting (para diseñadores de niveles y artistas) se puede implementar como:
Introducción a la programación en C++ en UE4
C++ y planos
Entonces, en un grupo, los programadores pueden desarrollar nuevas clases de planos para artistas y los artistas las usan en lugar de codificar directamente.

@Warlaan En mi humilde opinión, es porque gran parte de la charla de C# fue impulsada por personas que quieren que Godot sea una estafa de Unity, pero afortunadamente muchos aquí se dan cuenta de que Godot es algo propio y ya está por delante de Unity en muchos aspectos y no sería justo dejar que se vea afectado por los mismos problemas.

@alabd14313 Cambiaría el título, pero tal vez sea mejor crear un número separado y mantenerlo por el bien de la posteridad para que pueda vincularse cuando alguien proponga C# (como suele ser el caso).

Tengo dudas sobre el scripting visual, para ser honesto, pero si se puede implementar como un módulo, ¿por qué no? Por supuesto, creo que tener secuencias de comandos visuales (diseñadores y novatos), GDScript (personas que pueden programar o están dispuestas a aprender) y C ++ (programadores) harían de Godot un programa bastante equilibrado adecuado para todos los niveles de habilidad, pero haciendo que la codificación C ++ sea menos engorroso y permitir una interfaz más fácil con bibliotecas de terceros debería tener una prioridad más alta, en mi humilde opinión, porque puede atraer a muchos usuarios profesionales (y, en consecuencia, colaboradores).

En mi humilde opinión, la secuencia de comandos visual no está lo suficientemente refinada como para tener sentido. Es excelente para comercializar y convencer a los principiantes de la programación, pero según mi experiencia, la fase de aprendizaje durante la cual los principiantes prefieren los diagramas de flujo es muy corta.
Para todo lo que no sean las secuencias de llamadas más básicas, los sistemas que conozco (Unreal, Cryengine, Fungus, Stingray) simplemente no son útiles. Me refiero a que esta captura de pantalla , por ejemplo, es del video publicitario oficial del motor Stingray. Eso es lo que yo llamo código espagueti. Y los ejemplos oficiales en el motor Cry no se ven mejor, aunque se puede decir por la cantidad de elementos de comentarios que se hizo un gran esfuerzo para hacer que el gráfico fuera legible, o más bien intentarlo.
Si cree que no es tan malo, permítame recordarle que si viera ese código en un lenguaje basado en texto, cada línea de conexión que comienza fuera de la pantalla sería una variable con un nombre (con suerte) significativo.

Los gráficos de flujo son algo útiles cuando se trata de sombreadores/materiales, ya que se pueden mostrar resultados intermedios, pero incluso allí el sistema sufre mucho por el hecho de que una ecuación corta como
flotante x = (ab)*(a+b)/(1-(a+b))
llena fácilmente una pantalla completa cuando se hace como un gráfico, ya que cada multiplicación, suma o diferencia es un nodo con dos entradas y una salida. Son al menos 10 nodos para la fórmula anterior, y si no quiere causar un caos de conexiones, tendrá que duplicar los nodos a y b.

Los sistemas de gráficos de flujo que tenemos hoy (al menos los que conozco) eliminan la opción de dar nombres significativos a los valores, porque en lugar de poner un resultado en una variable con nombre intermedio, simplemente lo conectas al siguiente nodo. Eso hace que el código de autodocumentación sea casi imposible y requiere que se esfuerce mucho más en la documentación.
Lo que esos sistemas agregan es la opción de colocar nodos donde quieras, lo que en mi experiencia da como resultado un código menos legible la mayoría de las veces en lugar de uno que es más fácil de leer.

Y, por favor, no hables de los diagramas de flujo como si no estuvieran codificando. Son tanto código como cualquier otro lenguaje de programación. No están escribiendo, eso es todo.

Las secuencias de comandos visuales son para que los diseñadores y artistas realicen cambios sin tener que aprender a codificar. Algunos artistas también pueden hacer juegos interactivos simples con él. Tiene su objetivo donde definitivamente es útil, solo que no es para programadores.

@Warlaan Bueno, depende de cómo defina "programación". Ciertamente, la secuencia de comandos visual es similar a definir algoritmos, por lo que no está lejos de la programación, pero la programación también se trata de otras cosas.

Sin embargo, hay algunas buenas implementaciones de programación visual. PureData es uno y también está GDevelop , un programa de creación de juegos FLOSS bastante bueno (lástima que no sea más popular). En resumen, aunque personalmente no me gusta (por algunas de las razones que mencionaste), también es cierto que ambos podemos programar, por lo que para nosotros la programación visual es lenta y engorrosa para lograr resultados comparativamente pobres.

Aún así, estoy de acuerdo con @reduz en que algunas personas ven un atractivo en ello. No son las personas que estarían dando vueltas por hilos como estos, pero también hacen juegos. Creo que podrían traer algo a Godot.

La razón por la que los diagramas de flujo funcionan bien para la edición de sombreadores es que es muy visual (tiene nodos que le permiten cargar imágenes, seleccionar colores, etc... sin tener que escribir manualmente las rutas de archivo y los valores). Tampoco tiene ningún temor de asegurarse de que la sintaxis sea correcta y que las funciones estén escritas correctamente. Tampoco es necesario resolver tareas tan complejas como trabajar con una matriz (todo está calculado para usted).

La metodología de Godot para la edición de sombreadores termina siendo un buen enfoque porque separa limpiamente los componentes de vértice, fragmento y luz y también brinda una guía clara sobre con qué tipo de datos está trabajando (ya sea información normal o información de la cámara).

Ahora, con las secuencias de comandos visuales, creo que podría ser útil incluso para cosas moderadamente complejas si los nodos están en un nivel lo suficientemente alto en términos de mecánica de juego (hacen cosas más complejas y tienen varias entradas) y si hay nodos que le permite ejecutar un script o crear una expresión/ecuación (que a su vez se puede usar para manipular valores de formas complejas). Los problemas que he visto con otros sistemas de nodos visuales de este tipo es que intentan estar lo más cerca posible de la programación literal (es decir, tener un montón de funciones de bajo nivel como nodos en lugar de ser más como una versión nodal de ladrillos lógicos de Blender o arrastrar y soltar de GameMaker).

Claro, todavía no permitirá algo tan detallado y avanzado como lo que puede hacer con secuencias de comandos puras, pero aún tendría un uso para cosas tan simples como tipos de objetos dentro de un juego (que no necesitan una lógica muy compleja ) o si necesita hacer algo rápidamente.

Estoy de acuerdo en que algunas personas ven un atractivo en él, y también estoy de acuerdo en que no es para programadores (son solo nuestras definiciones de "programador" las que difieren ;-)), así que sugiero que dejemos la discusión así, ya que está un poco fuera de tema.

Otra característica útil de C++ es su tipo estático. Las funciones "auto" y "decltype" pueden detectar el tipo de un objeto. El editor y la finalización del código pueden ser más fáciles. En lugar de centrarnos en el editor de código interno, podemos usar otro IDE externo. Por ahora, creo que codelite y qtcreator tienen un mejor estado en la finalización del código. Los bloques de código tienen algunos problemas con las palabras clave de c++11. También eclipse-cdt tiene una buena finalización de código. Un complemento para qtcreator es una buena idea (como unreal-visual studio y Unity-Monodevelop). El IDE externo se puede identificar con una ruta del sistema en la configuración de Godot (como /use/bin/qtcreator), no es necesario compilarlo y empaquetarlo con Godot (a diferencia del paquete Unity, tiene monodesarrollo incorporado).
Hay otras herramientas como cppcheck y valgrind que tienen complementos en qtcreator.
Si quieres tener un adelanto de lo que es RCCPP:
manifestación

Me encantaría ver un lenguaje de secuencias de comandos basado en C++ para Godot, pero implementar todas las funciones de C++ sería engorroso, como la programación de plantillas. Debe haber algunas limitaciones para este tipo de lenguaje de script (STL) y no se deben usar plantillas. Además, RTTI podría causar problemas de rendimiento.

Me encanta GDscript, mi única queja al respecto es la contaminación del espacio de nombres de las variables, cuando se trata de scripts grandes, las definiciones de variables antes de ready() pueden volverse muy complicadas y propensas a errores en el código debido a que se comparten variables entre funciones del mismo archivo de script. .

Mis 3 centavos. (uh... terminó en 20, pero déjalo ser...)

Como @ alabd14313 mencionó anteriormente, "está en el punto donde está" debido a la evolución a lo largo de los años que llevó a Godot a la forma que tiene hoy.
No importa si la naturaleza hace esto o los humanos, corregir las cosas en el momento de la creación parece ser la mejor manera de desarrollarse, y debo admitir que gracias a esto, disfruto mucho de Godot tal como es y donde la evolución lo trajo.

Tiene todas las piezas necesarias.

Nodos que pueden combinarse en objetos más complejos, guardarse como escena y luego reutilizarse nuevamente como un objeto "simple" en otra escena que es una característica increíble y mega flexible, en realidad, limitada solo por la imaginación y los límites de la creatividad del usuario.

Fácil de usar y aprender GDScript, lo suficientemente potente como para controlar todos los nodos de la forma en que los codificadores estamos acostumbrados a hacerlo: escribiendo líneas de código.
Además de hacerlo de una manera rápida y sencilla (completar código/documentación de compilación/información sobre herramientas útiles aquí y allá) sin necesidad de compilar, simplemente escriba, pruebe, ajuste y, de nuevo, pulíelo a la perfección.

La implementación en múltiples plataformas REALMENTE con un solo clic (sin mencionar la implementación en Android a través de wifi/adb, la edición de vida, la depuración, etc. es solo una obra maestra del arte, no... ¡Es más, es una magia!)

Además, todas estas familiaridades con herramientas de uso común como blender, etc.
(importar cosas y funciona de inmediato, todo está donde y como debe estar)

Y, finalmente, admito que, en algún momento, incluso la ultra creatividad puede no ser suficiente cuando se trata de hacer algo un millón de veces en un bucle y que quepa en 1 fotograma. Ahí es donde entran las cosas de C. Si conoce C, lo necesita, nada le impide crear un complemento, un nodo personalizado propio, etc., que hace exactamente lo que desea.

Tiene casi todo, y con el tiempo, creo que lo tendrá todo.
(Es decir, las cosas que hoy "aún no están implementadas" y uno tiene que hacerlo "de alguna manera" o "manos desnudas" (léase: usar una herramienta externa para ello), por ejemplo, ajustar algo manipulado en 3D de una manera fácil (tengo que usar blender )

Godot es asombroso y una cosa mágica, perfectamente perfecto en su camino a donde va.Necesita ajustes y agregar cosas aquí y allá, pero eso es todo.

Guiones visuales?
Oh. Podría obligarnos a los codificadores a cambiar la forma de pensar "un poco" de una manera inusual, además, no creo que pueda ser tan flexible y legible como el código normal.
Imagina que codificas y tienes una línea simple como esta (abc/def) * ghi
luego la forma rápida, como de costumbre (?) para ahorrar tecleo, marcas parte de algo, pegas aquí, cortas allá, pegas de nuevo y en 5 segundos y pocas pulsaciones, terminas con "simple" (porque sabes lo que hace) una línea como ((((abc/def+((abc/def)_ghi^4))_ghi)+(abc/def_(100))_ghi)+abc)
Es común, tal vez muchos de nosotros lo hacemos de esta manera de una manera súper rápida.
Ahora imagina hacerlo de manera visual...
Podría ocupar toda la pantalla, mucho trabajo del mouse y no se vería tan legible como debería.
(por supuesto, esas líneas tampoco parecen fáciles después de un año, pero para eso están los comentarios)

¿Qué pasa si alguien tiene 100 de esas líneas una debajo de la otra?
Visualmente podría conseguir un campo de fútbol para mostrarlo. Qué tal analizarlo, cambiarlo, eso es un lío y un gran dolor de cabeza.
Por supuesto, los codificadores pueden hacer esto porque, no es un lenguaje utilizado, hacer que alguien sea un codificador, sino una forma específica de pensar, crear algoritmos, manipular datos como partes pequeñas y como un todo.
El lenguaje, sin importar si es C, Python, PHP, Java o Visual scripting, es solo una herramienta para escribir los pensamientos.
Y aquí, en mi humilde opinión, la escritura normal con el teclado es la forma más rápida y legible para escribirlo.
Por otro lado, si alguien no puede codificar, ¿esperas que revele repentinamente el genio algorítmico y la percepción para no perderse dentro de su propia idea y representación visual de la misma, considerando que cuando pensamos en el juego, hablamos de algo más complejo que dos bolas golpeando? unos a otros con la física.

Entonces, ¿para quién sería realmente Visual Scripting?
¿Para hacer la vida de los codificadores más difícil o para limitar Godot al nivel - motor para "juegos simples" para principiantes?

Gente, hay una larga discusión sobre Visual Scripting en #1220. Por favor, no volvamos a discutir los mismos temas aquí.

Gente, hay una larga discusión sobre Visual Scripting en #1220. Por favor, no volvamos a discutir los mismos temas aquí.

La mayoría de las publicaciones aquí fueron tan largas que tal vez me hicieron perderme mientras leía.
Lo siento :relajado:

@RebelliousX Incluso con RTTI, C ++ aún tendría un rendimiento mucho mejor que GDScript. Aunque es cierto que las plantillas pueden ser un problema.

La solución propuesta por @reduz en el n.° 3936 ya haría que la codificación en C++ sea bastante trivial: simplemente lo hace con su editor y compilador de elección y vincula la API de Godot. Si esto se implementa, incluso si la creación de scripts en C ++ sería buena, no sería muy diferente a escribir código en C ++ y luego llamarlo desde GDScript, en términos de rendimiento. En resumen, creo que centrarse en # 3936 (que es una solución simple) mejoraría mucho:

• Rendimiento (ya que escribir partes en C++ sería extremadamente fácil)
• Disponibilidad de bibliotecas de terceros (ya que los envoltorios se pueden distribuir más fácilmente, pero no tan fácilmente como #3943)
• Base de usuarios y colaboradores (muchos programadores de C++ adoptarían a Godot)

Luego, podría centrarse en la escritura estática en GDScript y optimizar el intérprete (a través de un JIT o compilando GDScript en C ++), pero esto puede venir más adelante si se facilita la escritura de módulos.

Solo quiero mencionar un par de puntos que se han colado en esta discusión pero que aún no se han abordado:

• Algunos de nosotros estamos hablando de mejorar el sistema existente (GDScript como lenguaje de secuencias de comandos, C++ como lenguaje de back-end) al facilitar el desarrollo de C++ y aumentar el rendimiento de GDScript. Otros hablan de usar C++ (o Java / C# / ...) como lenguaje de programación. Puede parecer que no hay una diferencia real entre habilitar el desarrollo rápido de C++ y convertirlo en un lenguaje de secuencias de comandos, pero con gusto explicaré cómo experimenté y observé el efecto negativo de los lenguajes de secuencias de comandos potentes en la calidad del diseño del juego. Y a menos que esto se convierta en el tema de discusión, con mucho gusto lo haré en los foros o en algún otro lugar donde no secuestre este hilo.
• @RebelliousX : cuando habla de "espacio de nombres variable", "scripts grandes" y "compartir variables entre funciones", parece que no ha entendido completamente la naturaleza orientada a objetos de GDScript (sin ofender). Cada archivo GDScript es una clase, por lo que los conflictos de nombres entre variables (miembros) deberían ocurrir exactamente con la misma frecuencia que en cualquier otro lenguaje orientado a objetos. No está compartiendo variables entre secuencias de comandos, está escribiendo varias funciones que pueden acceder al estado del objeto que lo abarca.

@Warlaan Sobre el primer punto, creo que podría publicar aquí, ya que está relacionado con el tema.

@Warlaan sin ofenderse. Sé que GDscript es una clase propia y sé que las variables son como variables miembro normales en la clase C++, pero parece que no entendiste mi punto por completo. Lo entenderás cuando tengas un script con más de 1000 líneas de código. Lo que quiero son referencias o punteros, en lugar de crear miríadas de variables miembro, simplemente páselas entre las funciones miembro. Es más seguro de esa manera.

Me gusta C#, pero veo pros y contras.

Ventajas:

• Buen soporte de herramientas (seamos realistas, ¿programarías en C# sin Visual Studio o MonoDevelop?)
• Adecuado para proyectos a gran escala.
• Ampliamente utilizado y maduro, hay toneladas de hilos de soporte en Internet.
• Buen rendimiento, compensación entre C++ y lenguajes de secuencias de comandos al mismo tiempo que es multiplataforma
• Relativamente fácil de vincular a C++

Contras:

• Basura recolectada: los proyectos de juegos a gran escala también deben implementar estrategias de asignación para evitar que las patadas de GC sucedan con demasiada frecuencia, esto puede ser desagradable
• No tan integrado como GDScript (¿finalización de la ruta del nodo? ¿Variables miembro del script en los nodos? ¿Modelo de asignación de memoria?)
• El tiempo de ejecución es pesado y .NET framework aún más. Al igual que en Unity, las bibliotecas estándar deben reasignarse a las de Godot.
• No es la mejor opción para la escritura real, en el sentido de hacer las cosas rápido y sucio. C# es más detallado y restrictivo que GDScript.
• Aún no hay pautas con respecto al desarrollo de Godot. El lenguaje es genérico y puede hacer muchas cosas, y como dijo Warlaan, los desarrolladores tienen diferentes culturas (literalmente podría tener un codificador WPF probando Godot y preguntándose por qué no hay una forma MVVM de crear GUI: p)

La mayor parte de esto también se aplica a Java.
Tal vez me olvidé de otras cosas porque aquí es tarde.

Ok, esta es mi experiencia con respecto a los lenguajes de secuencias de comandos ricos en funciones, resp. una falta total de un lenguaje de secuencias de comandos según su definición de "lenguaje de secuencias de comandos". Trataré de ser breve. ;-)

He trabajado como decano de ingeniería en School4Games en Berlín, Alemania, durante varios años. En esa escuela no tenemos una facultad para el diseño de juegos "puro", pero nuestro curso de diseño de juegos se llama "desarrollo de juegos" e incluye suficientes lecciones de programación para enseñar a los diseñadores de juegos cómo desarrollar sus propios prototipos y comprender las posibilidades y los límites. de las arquitecturas de hardware y software comunes.
Entonces, los estudiantes a los que enseño son personas que a veces tienen un gran interés en la programación, pero ninguno de los cuales solicitó convertirse en programador.
Cada semestre tienen que formar equipos y desarrollar un juego. Dado que casi todos los futuros empleadores potenciales de nuestros estudiantes usan Unity, ha sido un requisito para los dos primeros semestres trabajar con ese motor.

Ahora vayamos al grano con respecto al efecto de los lenguajes de secuencias de comandos:
Estos estudiantes se dividieron en dos grupos. Uno que trata de evitar la programación o ha perdido la esperanza (lo que significa que asistirá a clases de programación, pero no pedirá ayuda si tiene problemas, pero se da por vencido en silencio) y uno que se sumerge en la programación tan profundamente que salta directamente a los temas que por lo general, no te preocuparías al escribir prototipos de juegos. Por ejemplo, uno de mis alumnos del primer semestre publicó recientemente un tutorial sobre cómo escribir un Singleton en C# usando genéricos para que pueda convertir una clase de componente de Unity en un singleton al heredar de la clase genérica del tutorial. El punto interesante no es tanto que haya podido escribir ese artículo, después de todo, por supuesto, recibió ayuda de sus maestros y hay bastantes recursos sobre el tema en Internet. El punto interesante es que un estudiante que solicitó un curso que se centra principalmente en el diseño de juegos en lugar de la programación estaría interesado en un tema de programación tan específico. El código de ese tutorial nunca cambiará debido a cambios en el diseño del juego, es una construcción de programación pura.
Algo similar sucedió con otro estudiante que usó una clase similar para transportar información de una escena de juego a otra. Se sorprendió bastante cuando le mostré que podía hacer lo mismo con un miembro estático público, lo que demuestra que estaba buscando soluciones completas y complicadas antes de comprender por completo todos los elementos básicos.

Entonces, si se saltó adelante, esto resume el texto hasta el momento: si bien es posible escribir código simple en lenguajes ricos en funciones, he observado varias veces que es probable que las personas descarten soluciones simples donde existen alternativas complicadas.

Esto no se debe sólo a los prejuicios. Seguro, eso es probablemente un factor. Si ve que el código en los tutoriales, ejemplos u otras clases en su proyecto parece complicado, puede concluir que el suyo también debería verse complicado. Pero creo que la verdadera razón es que en la programación tiene sentido intentar crear un código a prueba de errores. Es un deseo natural escribir código que no se rompa tan pronto como se usa en un lugar diferente o tan pronto como recibe una entrada diferente. Y eso requiere que averigües qué opciones hay para las que podrías tener que prepararte.
Creo que esta sensación de tener que revisar cada eventualidad es lo que divide a mis alumnos en aquellos que se ahogan en la gran cantidad de características de C# y aquellos que se meten de lleno y pierden el enfoque en el lenguaje.

Zylann mencionó la frase "rápido y sucio". A menudo usamos esos dos términos como una frase, pero cuando lo piensas, en realidad son dos factores diferentes. Si es posible o no codificar rápidamente es bastante medible. Si el código resultante está sucio o no, por otro lado, depende de muchos factores, el más importante es la cantidad de características que tiene el lenguaje utilizado.
Por ejemplo, crear un nodo de nivel superior y usarlo como singleton en Godot está totalmente bien, ya que GDScript no ofrece las funciones necesarias para implementar el patrón de la misma manera que lo haría en lenguajes como C#. Claro, usar la función de carga automática sería mejor ya que ese es el primer lugar donde otros desarrolladores buscarían singletons (y hace que la sintaxis sea un poco más agradable), pero si un equipo decide implementarlo de esa manera, dudo que haya mucho de un argumento. Imagine, por otro lado, que alguien implementó un singleton en Unity simplemente agregando un miembro estático público a una clase. Es igual de rápido, en cierto modo es incluso lo mismo (ambas son instancias de clase en el lugar más público), pero dado que C# ofrece la opción de hacer que el constructor sea privado, acceda al singleton a través de una propiedad con inicialización perezosa, etc. espera que lo haga, de lo contrario, el código se percibirá como muy sucio si no está roto.

Ahora, el hecho de que los estudiantes de diseño de juegos se sumerjan en temas como estos puede ser un indicio vago de cuál es mi punto, pero creo que puedo ilustrarlo aún mejor al hablar sobre la situación en mi primer trabajo en un gran desarrollador de MMO F2P. El equipo al que me uní es uno de los desarrolladores de juegos más experimentados de Alemania. Su jefe de desarrollo ha estado creando sus propios motores internos desde 1995 y, aunque acababa de ser comprado por otra empresa, seguía siendo uno de los desarrolladores más exitosos en ese momento.
Cuando me uní al equipo, estaban usando la tercera versión del motor interno, que no tenía un lenguaje de secuencias de comandos. Habían implementado uno antes, pero en esa versión del motor volvieron a no tener ningún lenguaje de secuencias de comandos ya que había problemas con la calidad del código que entregaban los diseñadores del juego. En otras palabras, dado que el lenguaje de secuencias de comandos era demasiado poderoso, se tomó la decisión de cambiar la barrera entre los programadores y los diseñadores de juegos hasta el punto en que los diseñadores de juegos solo editarían niveles y cambiarían configuraciones en las hojas de configuración mientras los programadores hacían toda la programación. Noté que esta es más o menos la misma situación en la que terminan mis estudiantes (y parece que terminan muchos estudios profesionales que trabajan con Unity).
Ahora, ¿por qué me importaría? Si esto sucede una y otra vez, ¿no prueba eso que es una forma exitosa de trabajar? Mi respuesta es no, porque hubo problemas, tanto técnicos como en el diseño del juego, que podrían explicarse fácilmente por el hecho de que la comunicación entre programadores y diseñadores de juegos se reducía a escribir tareas en una dirección y exponer configuraciones en la otra. Desde la perspectiva de los diseñadores del juego, las funciones se convirtieron en cajas negras que se podían habilitar y deshabilitar, pero en ese lado del equipo no había nadie que pudiera discutir o incluso crear prototipos de alternativas.
Los programadores, por otro lado, fueron empujados casi naturalmente a una mentalidad de back-end. La mentalidad de KISS "rápida y sucia" se había ido, porque ninguno de nosotros podía predecir cómo se utilizarían las características que creamos. Recuerdo vívidamente cómo una vez que la base de datos se rompió porque un diseñador de juegos había implementado una búsqueda de huevos de Pascua, lo que provocó que los inventarios crecieran mucho más de lo que solían ser. Esa fue la última vez que asumí que los requisitos de una función probablemente se mantendrían igual.

Es por eso que creo que tener un lenguaje de secuencias de comandos de características bajas como un área definida para el código del juego es extremadamente importante y por qué creo que no tenerlo tiene un efecto negativo en el diseño del juego.

• Escribir código rápido significa ignorar características convirtiéndolo en código "rápido y sucio".
• El deseo de escribir código limpio divide a los desarrolladores en aquellos que no codifican y aquellos que dedican más tiempo a pensar en la codificación y menos al juego.
• Eso, a su vez, divide a todo el equipo en una mitad que trabaja en el diseño del juego sin conocer el código base y otra que trabaja en las características sin saber cómo se van a utilizar, sin dejar a nadie que pueda idear características del motor basadas en el juego. diseñar o sugerir un diseño de juego basado en características que podrían implementarse fácilmente.

No es posible imaginar el desarrollo de juegos hoy en día sin usar bibliotecas de clases preconstruidas, después de todo, eso es lo que hace que los motores con conjuntos de herramientas como Godot, Unity, Unreal, etc. sean tan exitosos. Pero la diferencia entre todos estos motores es dónde se traza la línea entre la programación y el diseño del juego y la brecha que se crea entre los dos lados.
Y basándome en mis observaciones, creo que la elección del lenguaje de programación es uno de los factores más importantes que pueden crear esa brecha o cerrarla.

Por cierto, la razón por la que me he involucrado tanto en Godot es que estoy trabajando para establecerlo como el motor obligatorio para el primer semestre. Solo para que sepas que no solo estoy hablando sino también sacando mis consecuencias. ;-)

@RebelliousX Tengo que admitir que todavía no entiendo muy bien a qué te refieres. Pero como dijiste que lo que querrías son referencias o punteros, ¿podrías abrir una nueva solicitud de función y publicar un ejemplo de código para tu problema allí? Para ser honesto, todavía parece que su problema es de arquitectura de código en lugar de una falta de características del lenguaje.

Debería haber agregado que KISS se beneficia principalmente de equipos pequeños. Godot está tan repleto de funciones que un desarrollador puede hacer un juego. Pero tan pronto como un proyecto tiene más desarrolladores, las cosas "rápidas y sucias" se vuelven menos probables y se dejan para la creación de prototipos o arreglos temporales, entonces se deben configurar reglas/directrices. Entonces, realmente depende de quién está usando el motor y para qué.

Godot en general también tiene más limitaciones de las que pensamos. No puede hacer singletons o variables globales de "c-estilo estático" por una razón: pérdidas de memoria y compatibilidad con subprocesos. GDScript no tiene tantas características como Python por una razón: se enfoca en las tareas y el rendimiento del desarrollo de juegos. El sistema de escenas también está orientado a objetos por una razón: puede hacer "cajas" independientes que se pueden probar y reutilizar :)

Este tema trata sobre cómo agregar compatibilidad con un módulo C# (o Java), pero no veo ningún código de ejemplo. Probemos algo sobre la marcha :)

using GodotEngine;

// Inherit a node type
public class Spikeball : RigidBody2D {

    // Exported variables
    [Export] public float damage = 60f;
    [Export] public float rotationSpeed = 2f;

    // Notice the naming convention. Should Godot API follow languages or should languages follow Godot?

    void _Ready() {
        SetProcess(true);
        // Should we use the generic system?
        Connect("BodyEnter", this, "_OnBodyEnter")
        // Or use C# features?
        this.bodyEnterEvent += _OnBodyEnter;
    }

    void _Process(delta) {
        var sprite = (Sprite)GetNode("Sprite");
        sprite.SetRot(sprite.GetRot() + delta*rotationSpeed);
        // Or we can have properties
        sprite.rot = sprite.rot + delta*rotationSpeed;
    }

    public void _OnBodyEnter(PhysicsBody2D body) {
        // We cannot invent C# members on the fly, so we can do this if the other script is in C# too.
        // ScriptInstance GetScript();
        var health = body.GetScriptInstance() as IHaveHealth;
        if(health != null) {
            health.TakeDamage(damage);
        }
        // But what if the other is GDScript?

        // A generic approach would look like this, a bit like SendMessage in Unity3D
        // object Call(string funcname, object arg1, ...); // where object can be seen as Variant
        body.GetScriptInstance().Call("TakeDamage", damage);

        // Same thing if we want to get a script variable
        var category = (string)body.GetScriptInstance().Get("category")
        Console.Print(category);
    }

}

¿Qué piensas?
Luego, este archivo podría compilarse como un activo DLL (o ejecutarse sobre la marcha). Pero hablando de esto, ¿necesitaríamos generar un csproj como Unity?

@Warlaan gracias por compartir tu experiencia. Corrígeme si me equivoco (fue una publicación larga), pero ¿estás diciendo que ofrecer un lenguaje con menos funciones es mejor por el bien de los programadores, para que puedan concentrarse en desarrollar sus juegos en lugar de sobrecodificar?

Si es así, esta es una observación muy sutil. Creo que los desarrolladores de Godot tienen que hacer lo mejor para su base de usuarios: saben lo que es mejor.

Y yo mismo hoy me preguntaba si algunas personas aquí (incluido yo mismo) no están pidiendo sutilmente Urho3D , mientras que otros están pidiendo GDevelop . Godot es claramente una herramienta en el medio del camino entre esos dos (pero perfectamente adecuado para profesionales, más como Urho3D), y creo que debería seguir siéndolo, pero Unity siempre lo ensombrecerá porque mucha gente aquí venir de eso

No creo que sea justo esperar que Godot sea una copia de Unity: Godot tiene claramente un mejor diseño y, hasta donde yo sé, un mejor rendimiento. Pero algunas personas piensan que GDScript no es adecuado para un desarrollo "serio" y que nunca lo será porque es un tiempo de ejecución personalizado, a pesar de que la versión anterior de Mono que usa Unity también es, en cierto modo, un tiempo de ejecución "personalizado". Y además, cuando escribe C# en Unity, escribe código que funciona solo en Unity en su mayor parte y sigue sus patrones de diseño, por lo que también podría usar otro lenguaje.

Creo que las personas que quieren C# están equivocadas, pero en mi opinión, un buen compromiso sería ofrecer:

1) Mejor rendimiento (escritura estática, tal vez un JIT)
2) Mejor soporte para bibliotecas de terceros (a través de FFI y una integración C++ más sencilla)

para GDScript. El resto se puede hacer en C++, incluida la escritura de módulos que implementan otros lenguajes de secuencias de comandos (que no necesitan ser propios; todos pueden escribir un módulo C#, si lo desean).

@Zylann No veo ninguna ventaja en escribir ese código en lugar del C++ equivalente, sinceramente, y el código C++ tendrá un mejor rendimiento.

@paper-pauper, la ventaja de escribir este código es la misma que GDScript: no necesita volver a compilar el motor para cada plataforma a la que desea exportar, y ... bueno, puede elegir el idioma (y el rendimiento es no es el único punto, como mencioné anteriormente). Estoy de acuerdo en que, actualmente, la experiencia con GDScript es superior y C++ es la mejor opción para obtener un rendimiento puro. Pero hay personas que simplemente no quieren hacer C++, por muy bueno que sea.
No estoy personalmente interesado en Godot+C#, solo estoy evaluando lo que sucede si lo agregas a Godot. Y no es tan sencillo :p

Después de leer el gran libro Game Scripting Mastery (no puedes encontrar muchos libros sobre el tema, excepto el libro que no es de juegos sobre compiladores Red Dragon). Mi conclusión es que GDscript es adecuado, es tan fácil seguir agregando funciones a un lenguaje de secuencias de comandos que hace que pierda su poder. Lo más importante es implementar un lenguaje de script no inflado y lo más general posible para que sea adecuado para diferentes proyectos. Del mismo libro, dice que Unreal está usando C++ con LLVM.

Otra idea que podría ser más liviana que implementar un tiempo de ejecución separado: ¿qué hay de adaptar un transpiler como TypeScript (que es muy similar a C#, sin el tiempo de ejecución) para emitir GDScript en lugar de JavaScript? Esto no tiene que estar incluido en Godot, de hecho, podría ser un módulo de terceros. Al menos ofrecería escritura estática (en tiempo de compilación) y varias bibliotecas, con el mismo rendimiento que GDScript (porque sería GDScript).

Me gusta TypeScript, pero no veo el punto de agregar tal complicación. Si alguien hace eso, tendrá que mantenerlo para que sea compatible con las versiones más nuevas de TS. Además, TS es un superconjunto de JS, entonces, ¿podría transpilar JS a GDScript? Y luego, tendríamos algunas personas con errores en el transpilador pensando que es un error en el motor.

Sigo pensando que una mejor idea es tener una versión estática de GDScript que pueda recurrir más fácilmente a JIT y aún así estar estrechamente relacionado con el motor y con el propio GDScript actual.

El objetivo de C# es usar un lenguaje establecido que también podría usarse fuera de Godot. TypeScript puede ajustarse a esto, pero no estoy convencido de que sea más fácil hacer un transpiler TS que incrustar un tiempo de ejecución Mono.

Para mí, como dije en IRC, la mejor opción sería la capacidad de hacer módulos enlazados dinámicamente. Entonces puede trabajar en C++ más fácilmente y también puede haber módulos de terceros con diferentes lenguajes, como uno para C# y otro para C++ como lenguaje de scripting. Aumentaría la capacidad de hacer crecer los recursos de Godot sin tener que inflar el binario del motor principal.

@vnen

Para mí, como dije en IRC, la mejor opción sería la capacidad de hacer módulos enlazados dinámicamente. Entonces puede trabajar en C++ más fácilmente y también puede haber módulos de terceros con diferentes lenguajes, como uno para C# y otro para C++ como lenguaje de scripting. Aumentaría la capacidad de hacer crecer los recursos de Godot sin tener que inflar el binario del motor principal.

Oh, estoy 100% de acuerdo; de hecho, expresé una opinión similar en el n.° 3936. Lo estaba descartando porque mencionamos el tiempo de ejecución de C# como un inconveniente :)

Para mí, ese módulo C# de ejemplo de @Zylann es encantador, cambiaría de Unity ahora mismo si estuviera disponible; no se trata del mayor rendimiento de C++ o la 'facilidad' de GDScript, se trata de estar cómodo.

Todavía soy muy nuevo en Godot y apenas he tenido la oportunidad de hacer un juego de prueba, por lo que es posible que no consideren válida mi opinión, pero para mí, GDScript es el mayor obstáculo, no en cómo se supone que debe funcionar con Nodes. y Escenas: lo entiendo (¡y es bastante bueno!).

Pero para mí, es literalmente la sintaxis de GDScript lo que es realmente desagradable, por no mencionar que falta mucho el editor de código: me encantaría usar VS porque ya conozco todos los accesos directos.
Tengo años de escribir C# en mis manos y, sinceramente, me siento como un niño tratando de escribir en GDScript.

¿Qué se perdería al permitir que los desarrolladores escriban cómodamente? No necesito la plétora que es Mono o la fantasía como Linq, solo quiero estar cómodo mientras escribo mi código.
Me conformaría con una sintaxis similar a C# para GDScript, al menos la opción de usar paréntesis, punto y coma y tipos explícitos. Personalmente, no soporto los tipos implícitos, me vuelven loco.
Creo que GameMaker permite variaciones en la sintaxis para adaptarse a diferentes datos demográficos.

Esto es, por supuesto, solo mis 2 centavos de varias horas con Godot - siéntete libre de estar en desacuerdo (como estoy seguro de que la mayoría de ustedes lo hará).

Además, creo que me estoy perdiendo algo: ¿qué tiene GDScript exactamente que a todos les gusta tanto?
No estoy tratando de ofender, simplemente no lo veo todavía.
Estoy bastante familiarizado con Perl, así que conozco el poder de los tipos implícitos y todo eso, pero tiene que haber más que eso, ¿verdad?

@Pikl :

Además, creo que me estoy perdiendo algo: ¿qué tiene GDScript exactamente que a todos les gusta tanto?
No estoy tratando de ofender, simplemente no lo veo todavía.

El punto sobre GDScript no es mucho sobre la sintaxis (que es Pythonesque) sino más sobre qué tan integrado está con el motor. Puede sonar pedante, pero la sintaxis es la menor de las preocupaciones cuando se cambia a otro sistema. Lo más importante es la API. Incluso si agregamos C# en este momento, probablemente te sientas incómodo con el nuevo paradigma, ya que la forma en que lo haces en Unity no es la misma que lo haces en Godot.

Lo siento, pero si agregáramos idiomas para asistir a la zona de confort de cada programador, pasaríamos la eternidad haciendo precisamente eso. Si bien podría tener sentido atraer a los usuarios de Unity con el menor estrés (ahora mismo estamos tratando de hacer una guía de Godot para los usuarios de Unity), no creo que Godot deba adaptarse para funcionar como Unity. De lo contrario tendríamos que hacer lo mismo con los usuarios de Unreal, Urho3D, GameMaker, etc.

Esto no quiere decir que C# no esté sucediendo (podría serlo si fuera factible y fuera del interés del motor), es solo que estos argumentos también se aplicarían a muchos otros lenguajes y motores.

@Pikl En primer lugar, gracias por proporcionar el primer argumento a favor de C#. Ahora déjame explicarte por qué creo que tu opinión no es válida. ;-PAGS

Echemos un vistazo más de cerca al comienzo del ejemplo de código de Zylann:

    using GodotEngine;

    public class Spikeball : RigidBody2D {

    [Export] public float damage = 60f;
    [Export] public float rotationSpeed = 2f;

Como regla general, cada palabra clave y cada carácter que no es una palabra clave tiene un significado. Si no es así, no debería estar allí.
Empieza con
using GodotEngine;
lo que significa que este código se refiere a funciones importadas del paquete "GodotEngine". Dado que cada script en Godot se refiere a esas funciones y no hay otros paquetes para importar, no tiene sentido agregar esa línea, así que eliminémosla.

A continuación tenemos
public class Spikeball : RigidBody2D {
Todo en GDScript es público, ¿por qué mencionarlo?
class Spikeball : RigidBody2D {
Cada archivo GDScript contiene una clase con el mismo nombre que el script. Esa no es solo una convención de codificación como en otros idiomas, se define así, entonces, ¿cuál es el punto de repetir el nombre de la clase?
: RigidBody2D {
Ahora que : es la única "palabra clave" significativa en esta línea, reemplácela con algo un poco más legible.
extends RigidBody2D {
Cualquier codificador con un poco de experiencia usará sangría para marcar las diferentes áreas del código. Eso significa que el código dentro de la clase se puede identificar por las llaves que lo rodean Y por la sangría, razón por la cual los desarrolladores de Python decidieron hacer que la sangría fuera obligatoria y deshacerse de las llaves ahora redundantes.
En nuestro caso, la sangría ni siquiera es necesaria en el nivel de clase, ya que cada archivo de script se define como una clase (a menos que esté usando subclases que están marcadas con sangría).
extends RigidBody2D

A continuación tenemos las líneas de exportación.

    [Export] public float damage = 60f;
    [Export] public float rotationSpeed = 2f;

Los caracteres [] marcan atributos que se definen en clases del mismo nombre, que es un mecanismo que no existe en Godot, por lo que simplemente usa palabras clave en su lugar.

    export public float damage = 60f;
    export public float rotationSpeed = 2f;

De nuevo, todo es público:

    export float damage = 60f;
    export float rotationSpeed = 2f;

y no necesita especificar el tipo de datos.

    export var damage = 60f;
    export var rotationSpeed = 2f;

Las exportaciones son una excepción porque el inspector necesita saber qué widget mostrarle, por lo que el tipo es realmente solo una información adicional para la palabra clave de exportación.

    export(float) var damage = 60f;
    export(float) var rotationSpeed = 2f;

Así que la diferencia entre este código C#

    using GodotEngine;

    public class Spikeball : RigidBody2D {

    [Export] public float damage = 60f;
    [Export] public float rotationSpeed = 2f;

y este código GDScript

extends RigidBody2D

export(float) var damage = 60f;
export(float) var rotationSpeed = 2f;

es simplemente que se eliminaron todos los caracteres y palabras clave que no describían las opciones que tiene en Godot.
Supongo que ahora está bastante claro lo que le gusta a la gente de GDScript. No estás obligado a escribir cosas sin sentido o redundantes y la sintaxis refleja las opciones que tienes en lugar de insinuar opciones o características del lenguaje que no existen en Godot.

Viniendo de un entorno de C++/C#/TorqueScript, debo decir que el paradigma de Godot tarda unos días en acostumbrarse, pero una vez que su simplicidad hace "clic", puede pasar de la idea a la ejecución tan rápido como puede escribir.

@vnen :

es solo que estos argumentos también se aplicarían a muchos otros lenguajes y motores

Bastante justo, no estoy conteniendo la respiración ni espero ser acomodado, este no es mi territorio.

en este momento estamos tratando de hacer una guía de Godot para usuarios de Unity

¿Quizás podría ayudar con eso? He estado usando Unity durante varios años y lo conozco bastante bien en comparación con cualquier otro motor. Sería una buena rata de laboratorio para esta guía.

@Warlaan :

Supongo que ahora está bastante claro lo que le gusta a la gente de GDScript. No estás obligado a escribir cosas sin sentido o redundantes y la sintaxis refleja las opciones que tienes en lugar de insinuar opciones o características del lenguaje que no existen en Godot.

Eso tiene mucho sentido: va junto con la ideología de Perl de reducir la cantidad de pulsaciones de teclas necesarias para escribir un script. Pero en realidad, la cantidad de pulsaciones de teclas que escribiría para ese ejemplo sería la misma: uso el autocompletado de VS al máximo y rara vez tengo que escribir más de 3 caracteres para cualquier palabra clave, tipo o nombre de variable antes de presionar espacio o abrir soporte para completarlo. Y en cuanto a los caracteres adicionales 'innecesarios' reales allí, prefiero tenerlos allí, esa es solo una preferencia de azúcar sintáctica.
Godot tiene autocompletar pero es lento, lleva tanto tiempo que a menudo he escrito toda la línea de código antes de que aparezca la mayor parte del tiempo.

Entonces, lo que a la gente le gusta de GDScript es que se reduce al mínimo posible y proporciona la funcionalidad exacta que está disponible para su uso y nada más, además de reducir las pulsaciones de teclas.

Lo entiendo, pero no hace nada para ayudarme a disfrutarlo más; simplemente no me siento cómodo escribiendo GDScript, aunque puedo leerlo perfectamente bien. No estoy luchando por aprenderlo, simplemente no me gusta, parece.
Tal vez unas cuantas horas más haciendo un clon de Space Invaders ayudaría a convencerme: quiero que me guste GDScript más que a mí.

Idea tardía:
¿Es posible usar solo C++ en Godot? Sinceramente, creo que preferiría aprender C++ y usarlo sobre GDScript.

¿Quizás podría ayudar con eso? He estado usando Unity durante varios años y lo conozco bastante bien en comparación con cualquier otro motor. Sería una buena rata de laboratorio para esta guía.

@StraToN hizo una publicación en el grupo de Facebook pidiendo este tipo de ayuda. Póngase en contacto con él (no estoy seguro de si hay alguien más trabajando en eso también).

@neikeq ¡ Gracias, listo!

@Warlaan Entiendo su comparación de código, pero para mí prueba principalmente que C # tiene más funciones y, como tal, es más detallado.

Necesita using porque hay espacios de nombres para evitar la colisión de nombres con muchas clases (lo que ya me sucede en mi propio proyecto de juego).
Necesita public porque existe una noción de encapsulación para evitar errores del codificador con el tiempo.
Tiene [SomeClass] porque podemos ampliar las anotaciones integradas para adaptarse a las diferentes necesidades del proyecto y mejorar las herramientas.
En cuanto a llaves... No veo una ventaja, excepto para definir ámbitos.

Estas características están aquí por una razón. Entre ellos, diría escalabilidad. ¿Desarrollarías un enorme juego 3D multiplataforma con todo el código base en GDScript? Bien tu puedes. Pero muchos usuarios preferirán C++, C# o Java, debido a las ventajas que mencioné (y hablo únicamente del lenguaje, no del marco).

Pero al mismo tiempo, no hay ningún proyecto de juego "enorme" que sepa que se haya desarrollado con Godot, así que no hay tantos ejemplos: p
Además, veo algunas características negativas en C# (advertencia: opinión personal más adelante):

Puede tener variables estáticas. Esto está mal, muchos errores provienen de estados globales/singletons. A diferencia de la carga automática, no están vinculados a ningún ámbito de escena.
Puede escribir mal un punto y coma al final de una sentencia while() o if(), haciéndolo inútil y difícil de encontrar.
Puede sobrecodificar. Estoy de acuerdo en que, cuando se usa de manera incorrecta, el código C# puede volverse muy complicado, mientras que otro código más simple haría lo mismo. Pero depende de la gente/experiencia.

Oh. No mencioné preload() . Esto simplemente no puede llegar a C#/Java, a menos que confíes en los trucos del compilador: p

¿Alguien ya empezó a experimentar con un módulo Mono?

Para agregar mi opinión más humilde, como alguien que es un desarrollador de C#, a esto...

No creo que haya mucho valor en agregar C # a Godot, ya que aún tendría que aprender las clases de Godot para hacer cualquier cosa y lo único que realmente ganaría al agregar C # es el estilo C más familiar (para muchos). sintaxis y escritura estática.
Lo de la sintaxis es discutible, Python tiene la reputación de ser fácil de aprender para los principiantes y dado que GDScript es muy similar a Python, creo que lo mismo es válido para él.
Los programadores algo experimentados no deberían tener problemas para captar esa sintaxis de todos modos, es consistente y tiene considerablemente menos trampas que la sintaxis de estilo C de forma más libre.

Ahora, la escritura estática, por otro lado, puede tener algún valor, además de ayudar con el rendimiento, también puede ayudar con la velocidad de desarrollo en algún aspecto. A las herramientas de autocompletado les encanta que les digan qué tipo de función/método espera y devuelve, pero solo las sugerencias de tipo pueden lograrlo.
Sin embargo, esto podría agregarse a GDScript, sin necesidad de ningún idioma adicional.

Además, implementar C# probablemente no sería tan fácil y se gastaría una cantidad considerable de tiempo y esfuerzo en llevar el motor al estado en el que se encuentra actualmente, pero ahora con C# en la parte superior o en lugar de GDScript.

Como comentario final, que sé que algunas personas se equivocarán, tengo que decir lo siguiente:

Ha sido mi observación que algunos programadores que podrían no tener una base tan sólida como deberían tener en nuestro oficio tienen la tendencia de aferrarse a las cosas que saben con toda la fuerza disponible para ellos.
Me parece que este fenómeno está especialmente extendido en las comunidades de desarrollo de C#, aunque esto podría ser solo mi sesgo.
Si alguna de las personas que leen esto cree que podría encajar en esa descripción, solo puedo recomendarle que salga de esta caja familiar y comience a aprender algo nuevo, no es una tarea tan desalentadora como podría pensar y una vez que tenga una empresa comprensión de esa cosa nueva, probablemente también habrá aumentado su comprensión de lo que ya sabía. Vale la pena.

Me encantarían los tipos estáticos, pero si eso sucediera, ¿cómo lidiarías con los genéricos? ¿Simplemente usaría un tipo dinámico en esa instancia o le gustaría poder usar restricciones? - solo permite ints y bools, por ejemplo.

Los espacios de nombres serían muy bienvenidos, me sorprende que aún no existan en GDScript.

La opción de usar llaves en lugar de dos puntos para los métodos también sería genial, sé que no son necesarios, pero me gusta tenerlos allí: es como leer un libro sin puntos, es discordante.

Las sugerencias de tipo podrían cerrar la brecha que impide que la finalización del código funcione por completo. Una vez trabajé en un proyecto usando Lua, y ellos también querían tener esto. La investigación me llevó aquí: https://github.com/andremm/typedlua/blob/master/examples/http-digest/http-digest.tl#L48
Esto es en lo que puede convertirse un parámetro de función, si te sumerges demasiado en las sugerencias de tipo xD
Pero creo que debería haber una compensación. Solo vea cómo lo hacen TypeScript o Haxe (ambos permiten mezclar variantes y escribir). Además, la sugerencia de tipo ya existe en Godot. Solo se usa en export() :)

¿Alguien ya empezó a experimentar con un módulo Mono?
@Zylann

Echa un vistazo a GodotSharp . El estado actual en el repositorio aún no se puede utilizar. En mi repositorio local, logré implementar suficientes cosas (solo Vector2 y Matrix32 están disponibles como tipos básicos) para traducir la demostración 2D/plataforma a C#, excepto para la creación de instancias de enemigos y viñetas, que se realiza desde GDScript ya que las referencias aún no funcionan.
Este es un ejemplo de la clase de jugador: https://github.com/neikeq/GodotSharp/blob/master/platformer_cs/Player.cs

@Pikl

Idea tardía:
¿Es posible usar solo C++ en Godot? Sinceramente, creo que preferiría aprender C++ y usarlo sobre GDScript.

Sí, es posible, pero actualmente no es tan fácil y/o conveniente y tienes que volver a compilar Godot desde cero. Muestre algo de soporte para #3936 si está interesado en que C ++ sea un ciudadano de primera clase, para que pueda usarse junto con GDScript (o exclusivamente) sin mucho trabajo.

@Zylann Pikl preguntó sobre cómo cambiar la sintaxis de GDScript para que se asemeje a la de C# para que sea más fácil de leer para los desarrolladores de Unity. Eso es lo que estaba comentando. Sí, C# tiene más funciones, que es la única razón por la que las palabras clave y los caracteres que eliminé estaban allí en primer lugar. Y es por eso que agregarlos solo por el hecho de tener un código GDScript que se parece al código C# no solo es innecesario, en mi humilde opinión, está mal, ya que estaría usando una sintaxis que insinúa características del lenguaje que GDScript no tiene.

@Pikl No se trata de la cantidad de pulsaciones de teclas, se trata de la cantidad de opciones y el significado implícito de los caracteres adicionales. GDScript simplemente no tiene algunas de las funciones que legitimarían las palabras clave adicionales. Por ejemplo, cada variable, clase y función tendría que estar precedida por la palabra clave "público", ya que el modificador de visibilidad predeterminado de C# no es público (excepto para los espacios de nombres; cambia según el caso de uso... otra situación en la que Microsoft decidió que KISS es solo una banda de los años 80) y como en GDScript todo es público.

Entonces, ¿por qué no agregar C# con todas sus características?
Como Zylann ya mencionó, el efecto de agregar C# a Godot no es tan sencillo de predecir. Si aún no lo ha hecho, le agradecería que leyera mi larga publicación en este hilo (https://github.com/godotengine/godot/issues/5081#issuecomment-225226235). Como desarrollador, siempre hubiera pedido lenguajes más potentes. En mi tiempo libre, actualmente estoy mirando Kotlin solo porque paper-pauper lo mencionó en la primera publicación.
Pero desde que tuve la oportunidad de observar el efecto de los lenguajes de programación en el resultado y el comportamiento de los desarrolladores de juegos, me di cuenta de lo importante que es elegir un lenguaje adecuado en lugar de uno poderoso.
Como expliqué en la publicación vinculada, estoy seguro de que C# tiene una influencia notable en la cultura de la comunidad de Unity, que ve a los programadores como personas que

• escribir cosas para la tienda de activos
• escribir tutoriales
• corregir errores.

En mi experiencia, no hay mucha cultura de programación de juegos en Unity. Tan pronto como te encuentras con cualquier tipo de problema, comienzas a buscar patrones o activos preconstruidos para resolverlo. En realidad, hay un número significativo de personas que eligen sus patrones incluso antes de saber nada sobre un proyecto, y ese tipo de inflexibilidad mental afecta los resultados del juego.

Y ese es solo mi contraargumento favorito, hubo varios otros buenos en las primeras publicaciones. ;-)

El problema con JVM es que es demasiado pesado. ¿Alguien echó un vistazo a Avian ? ¿Qué tan compatible es con el mundo Java?

@neikeq Eso no significa que tenga un peor rendimiento: AFAIK, la JVM tiene un mejor rendimiento que el CLR, y también un recolector de basura mucho más adecuado para el desarrollo de juegos. También está instalado en la mayoría de las computadoras, sin importar si son Windows, Mac o GNU/Linux.

También tiene una mayor riqueza de bibliotecas FLOSS de mayor calidad y, independientemente de lo que digan algunas personas, mejor soporte multiplataforma.

Diría que entre los dos, JVM es claramente mejor para el desarrollo de juegos (pero lo evitaría tanto como CLR de todos modos).

Avian parece interesante. No tengo experiencia con él, por lo que no puedo responder a su pregunta, y me temo que su compatibilidad podría resultar tan problemática como la versión Mono de Unity, lo que hace que sea realmente incómodo usar bibliotecas de terceros a menos que por casualidad encuentre uno para una de las versiones .NET proporcionadas.

Pero sería bueno tener una implementación de Java liviana como una opción adicional además de GDScript y C++ para los casos en los que necesita tiempos de respuesta rápidos y puede sacrificar la calidad del código (como atascos de juegos o creación rápida de prototipos de nuevas ideas de back-end).

Se tiene en cuenta a @neikeq Avian para proporcionar secuencias de comandos de Java para proyectos de C++, por lo que es realmente un buen candidato. Puede ser muy pequeño (algo así como 100kb si no recuerdo mal). Escuché sobre algunos juegos libGDX que estaban usando Avian para lanzar puertos de iOS... jMonkey Engine también está usando Avian en iOS). En general, Avian viene sin el paquete completo que normalmente viene con JVM como las clases sun/oracle. Sin embargo, no creo que sea un problema, ya que las clases Java 'originales' no son adecuadas para los juegos, es por eso que las bibliotecas como libGDX proporcionan su propia implementación en vectores o estructuras de datos ... y al final creo que lo haríamos necesita volver a implementar esas clases también. (Sin embargo, es fácil incrustar varias partes de las clases originales de Java, pero cuanto más incluimos, más grande será Avian)

@ paper-pauper Quise decir de gran tamaño, suponiendo que se incluirá con el juego. Pero como dijiste, está instalado en la mayoría de las computadoras, y considerando la popularidad de frameworks como libGDX, podría ser la mejor opción.
Mi problema con C++ como alternativa a GDScript es que su sintaxis es horrible. Eso es un asesino de la productividad. Está bien para el desarrollo de motores y módulos, pero no escribiría un juego completo con él. Habiendo dicho eso, estoy a favor de #3936 y tener algo como lo que hace Unreal, pero no lo vería como un lenguaje de "scripting" alternativo.

@ kubecz3k ¿Admite otros lenguajes JVM? por ejemplo: Kotlin

@neikeq sí, hasta donde yo sé, es totalmente compatible con el código de bytes de Java, por lo que es compatible con cualquier lenguaje preparado para jvm (kotlin, scala, jpython, etc.)
Creo que podríamos hacer algunas preguntas en el grupo aviar de Google: https://groups.google.com/forum/#!forum/avian
parece estar bastante activo

+1 para no ver a C ++ como un lenguaje de secuencias de comandos alternativo. Como dije antes, es bueno que Godot tenga un lenguaje optimizado para secuencias de comandos y otro para desarrollo de back-end en lugar de tener un lenguaje que es un poco "meh" en ambas áreas.

Eso no quiere decir que la compatibilidad con bibliotecas dinámicas y un desarrollo C++ más rápido no fueran algo que me encantaría ver.

Pero para no ser demasiado entusiasta con Avian, aquí hay una publicación de blog del desarrollador principal de libGDX en la que explica por qué libGDX no está usando Avian para los puertos iOS. http://www.badlogicgames.com/wordpress/?p=3925 (desplácese hacia abajo hasta la parte Avian)
No soy un programador/hacker jvm (pero el autor sí lo es, ya que también estaba trabajando en RoboVm (otro jvm más que compró y cerró Microsoft)), así que no sé cuánto de esto realmente se transformaría en el situación en la que Avian se usa solo como un lenguaje de secuencias de comandos (sin alimentar el motor central)

La mayoría de ustedes son probablemente programadores con más experiencia que yo, pero ahí están mis 2 centavos. Hace un año, apoyaría a C#. Pero aprendí la sintaxis de GDScript muy rápido. Al final del día, aún necesita aprender la API y eso es probablemente lo que requiere más tiempo para aprender. Así que sí, no necesito C#. @Warlaan sacó muchas buenas razones en contra de C#. La implementación de C# también llevaría mucho tiempo. También significaría más errores. Sí, tenemos una gran comunidad que contribuye a la base del código, pero todavía tenemos solo una @reduz . Creo que el tiempo necesario para implementar C# debe invertirse en las funciones que realmente necesitamos. ¿Cuántos desarrolladores de Godot están satisfechos con GDScript? Sí, podría ser más rápido, pero no tengo ningún otro problema con eso. Preferiría tener un lenguaje de secuencias de comandos increíble que dos no tan buenos. Incluso Unity se está quedando atrás con el viejo Mono.

Lo que me gustaría tener es escritura estática en GDScript. No C++ como lenguaje de secuencias de comandos, no C#. Centrémonos en GDScript y hagámoslo aún mejor de lo que es ahora.

Dado que el motor en el que lideré el desarrollo durante 14 años se mencionó en el hilo Visual Scripting, pensé en agregar mis 2 centavos aquí ya que estábamos desarrollando un nuevo motor escrito completamente en nuestro propio lenguaje similar a C#.

Escribimos nuestro propio compilador (también escrito en nuestro propio idioma después de arrancarlo en C++) que se compilaba en código C++ (casi C puro) que luego se alimentaba a los compiladores de todas las plataformas compatibles (XBox/PS/PC/Wii/ etc.). Escribimos nuestro propio recolector de basura generacional para poder ajustar su rendimiento según sea necesario; hacerlo de esta manera significaba que se usaba en todo el motor, lo que significaba que estaba bien probado y perfilado. Y dado que estábamos realizando compilaciones cruzadas en C++, podíamos escribir fácilmente código C++ en funciones 'nativas' que podían llamar a las API del sistema según fuera necesario o incluir operaciones específicas de la plataforma (SIMD).

Realmente no puedo imaginar lo frustrante que debe ser para Unity haber tenido que fusionar un montón de código C++ con Mono, lo que probablemente explica por qué se está quedando atrás, como señaló @GlaDOSik . Sin embargo, ciertamente no era algo que ninguno de nosotros estuviera interesado en hacer.

Nuestro objetivo principal era unificar los lenguajes utilizados entre el motor, el editor y las herramientas, y el código del juego en un solo idioma. Anteriormente, el motor y las herramientas eran completamente C ++ y se usaba un lenguaje de secuencias de comandos visual (al menos parecía código C) para todos los juegos que preferían los diseñadores de niveles, pero molestaba a la mayoría de los programadores de juegos que estaban escribiendo la mayoría. del código También nos permitió adaptar el lenguaje a las cosas que podríamos necesitar para el desarrollo del juego (como la compatibilidad con la máquina de estado).

_Sin embargo, no puedes complacer a todos._ Si tuviera que trabajar o tratar de ayudar a alguien a depurar un desagradable lío de "código" basado en nodos de espagueti blueprint/etc, me gustaría sacarme los ojos como represalia. Esperaría que un artista que intenta leer código C++ haga lo mismo. Lo que puedes hacer es perder _mucho_ tiempo discutiendo sobre cuál es la _mejor_ solución y aún más tratando de complacer a todos. En algún momento, solo necesita concentrarse en crear las herramientas más productivas que pueda para las personas adecuadas y, a veces, eso significa que algunas personas pueden tener que aprender algo nuevo.

"Si no es C++, es lento" parece ser el mantra a menudo, pero diría que la mayoría de los juegos _enviados_ están escritos con algo diferente a C++ para el código de juego en estos días. En realidad, no he visto a nadie publicar problemas de rendimiento específicamente de GDScript, aunque ciertamente tendría curiosidad por saber de ellos qué fue lento.

En cuanto a mi introducción a GDScript, fue algo como esto:

• Dios mío, ¿como Python? Eso es una locura, ¡los espacios en blanco no deberían importar!
• Hmm, no soy fanático del estilo "minúsculas" (veo que no puedes complacer a todos).
• Bueno, está bien, esto es realmente genial y está bien pensado.
• Sí, esto está muy bien integrado con el editor, ¡ciertamente podría ver que es muy productivo con esto para el código del juego y algunos complementos del editor!

Parece que se ha puesto mucho esfuerzo y tiempo en GDScript, y parece ser la herramienta adecuada. ¡Así que realmente solo quería felicitar a aquellos que trabajaron para hacerlo!

@Ziflin ¡Hola! Me alegro de conocerte aquí, Vicious fue uno de los primeros motores de juegos que usamos profesionalmente (aunque fuimos contratados con @punto- para hackearlo y solucionar problemas con él más que para usarlo).

El lenguaje de secuencias de comandos visual fue realmente una pesadilla, pero el código fuente estaba realmente bien hecho, limpio y organizado. Después de trabajar con Torque, fue una dicha. Aprendí mucho trabajando con él. Sony hizo un gran trabajo vendiéndolo en Latinoamérica porque todo el mundo lo estaba usando aquí hace una década...

Creo que el momento más sorprendente que recuerdo de trabajar con él fue tropezar accidentalmente con un fragmento de código que enumeraba los idiomas, y había un comentario "Portugués no compatible".

Nos reíamos mucho y hacíamos bromas, y el productor del juego (que estaba detrás de nosotros y no lo notamos) temblaba de miedo y dijo: "¿Espera qué? Todo lo que queda ahora es traducir el juego al portugués". , ¿Esto es una broma verdad?"

Pero solo usamos chino para el portugués, todo funcionó bien y el juego se envió. ¡Me alegra saber que todavía lo están desarrollando!

(cita de @Ziflin ) En realidad, no he visto a nadie publicar problemas de rendimiento específicamente de GDScript, aunque sin duda tengo curiosidad por saber qué fue lento.

Personalmente he llegado a un cuello de botella de CPU/Gdscript en este proyecto: http://godotdevelopers.org/index.php?topic=15519.0

Escribí algo de inteligencia artificial básica y pseudofísica básica de la vieja escuela en GDscript para controlar cada uno de los 8 autos.
No lloré en público sobre este problema de rendimiento porque todavía había algunos pequeños espacios para la optimización.
Pero si quisiera agregar más autos, me habría visto obligado a eliminar Gdscript para C ++ ( editar: lo que me gustaría evitar ya que realmente no quiero tener que compilar una y otra vez).

Además, creo que encontré el mismo cuello de botella de CPU/Gdscript el año pasado con este otro proyecto que usaba GDscript para IA básica para cada error (animales): http://ludumdare.com/compo/ludum-dare-32/? acción=vista previa&uid=50893
Cuanto más añadía bichos (animales), menor era el rendimiento.

Podría compartir mi experiencia al respecto si alguien quiere.

@SuperUserNameMan Adelante, pero creo que este otro ticket que abrí #5049 (que habla específicamente sobre el rendimiento de GDScript) es más adecuado para eso.

@paper-pauper: no estoy seguro de poder contribuir con el n.º 5049 (que se trata más de agregar JIT, de lo que podría simplemente agregar un pulgar hacia arriba). La experiencia que podría compartir es más sobre qué tipo de cuello de botella he alcanzado, cuáles fueron los síntomas específicos, cómo tuve que trabajar, cómo optimicé y qué "beneficios de diseño de Godot" tuve que sacrificar.

@SuperUserNameMan Todavía no he pensado mucho en implementar JIT a través de la inferencia de tipos, pero para eso la VM debe admitir primero la escritura estática

Estaría más interesado en escuchar a qué tipo de código AI se refiere.
Mi idea preconcebida sería que cualquier código que pueda causar problemas de rendimiento cuando se ejecuta en solo 8 entidades probablemente no sea realmente un código de juego y, como tal, debería colocarse en una clase de C++ de todos modos, por eso pregunto.

@reduz Jaja, bueno, ¡aparentemente es un mundo pequeño! Y sí, la secuencia de comandos visual se salió de control (realmente estaba destinado a ser solo para lidiar con disparadores y pequeños fragmentos de lógica de eventos). Vicious cerró sus puertas a principios de este año, pero fue muy divertido trabajar allí.

@ paper-pauper, revisaré el otro tema que mencionaste. Realmente no quise que la gente comenzara a publicar problemas de rendimiento en este hilo.

Si GDScript fuera a agregar escritura estática, _puede_ ser más fácil tener una opción para convertirlo directamente a C++, lo que evitaría una sobrecarga adicional de las transiciones IL->C++ y mantendría el tiempo de ejecución pequeño (sin compilador JIT, etc.). Luego, puede crear prototipos en GDScript o hacer modificaciones con él, pero luego también puede convertirlo automáticamente a C ++ para obtener una velocidad adicional cuando sea necesario para las compilaciones finales.

Hacer eso también mantendría los IDE existentes (VC ++, etc. y el editor Godot) que la gente estaba acostumbrada a usar. De hecho, solo usamos VC++ para depurar nuestro lenguaje y nuestro compilador generó directivas #LINE en los archivos .cpp para que pudiera recorrer fácilmente el código original y establecer puntos de interrupción. Entonces, en teoría, podría crear prototipos y depurar con GDScript normal en el editor, pero durante las compilaciones habilitadas para 'GDScript-> C++' aún podría usar su IDE/depurador de C++ y establecer puntos de interrupción/depuración en los archivos gdscript. Para nosotros, los archivos C++ generados eran temporales y solo los examinábamos si había un problema de generación de código.

De todos modos, sólo un pensamiento. El hecho de que ahora tenga un buen lenguaje de secuencias de comandos es definitivamente una ventaja y ciertamente hace que sea posible hacer cosas como modificaciones creadas por el usuario, creación rápida de prototipos y agregar nuevas funciones al lenguaje.

De hecho, no entendí que se suponía que debía publicar mis problemas de rendimiento en este hilo tampoco. Aquí era más adecuado: https://github.com/SuperUserNameMan/kart-zero/issues/1

@Ziflin En realidad, lo que discutimos en otros números es primero, agregar una API C mínima para escribir módulos/scripts de Godot usando C simple a través de una API mínima que expone toda la API de reflexión de Godot, esto resolvería un problema común que tenemos con respecto a la distribución de enlaces. a diferentes tipos de bibliotecas sin tener que recompilar Godot

Ejemplos de esto son los que quieren vincular la API de Steam, ODBC, SQLite, Kinect, etc. Todo lo cual requiere escribir módulos en C++. Hacer esto con una API de C resuelve el problema de la vinculación dinámica con C++ (que es muy limitado debido a que cada compilador o versión del compilador tiene su propia ABI y los problemas de discrepancia de tamaño de símbolo que pueden ocurrir entre las versiones de Godot). C no tiene ninguno de esos problemas.

Una vez que eso funcione, debería ser realmente fácil compilar GDScript en C y cargarlo en tiempo de ejecución cuando el juego se ejecuta o se exporta.

@reduz Ah genial. Entonces, ¿básicamente estás hablando de poder escribir un DLL de 'complemento' que pueda exponer lo que quiere a GDScript? (¿o entendí mal?)

Una vez que eso funcione, debería ser realmente fácil compilar GDScript en C y cargarlo en tiempo de ejecución cuando el juego se ejecuta o se exporta.

¿Funciona esto para alguien que quiere escribir un dll que tiene, digamos, varios tipos nuevos derivados de nodos de C++?

Sin embargo, es un poco triste que el nuevo soporte de 'módulos' de C++ parezca ser suficiente para solucionar algunos de los problemas con las DLL.

¿Por qué no utilizar un lenguaje de secuencias de comandos integrado como lua o Ruby?

@jersten porque lee los documentos: http://docs.godotengine.org/en/latest/reference/gdscript.html

@Ziflin , sí, pero tendrá que usar la API C a través de la reflexión (aunque puede solicitar punteros de función a través de la reflexión, por lo que debería ser lo suficientemente rápido ...). El objetivo sería principalmente tener una forma fácil de cargar archivos DLL que evite el problema de ABI, y también una forma sencilla de compilar GDScript en C y cargarlo como un archivo .so.

Voy a aportar mis 2 centavos aquí por lo que vale. Nunca codifiqué en C# sino solo en Java. Si bien personalmente preferiría Java debido a que lo usé y me gustó, en realidad doy soporte a C# sobre Java. C# es lo que usan los desarrolladores de juegos de Unity, por lo que tenerlo haría que Godot fuera parte de este ecosistema de desarrollo independiente que creó Unity. Además, Java ni siquiera es una buena opción si desea un lenguaje JVM. Hay otros lenguajes mejores que se compilan en JVM.

Creo que la gente no entiende el punto de todos modos. C#/Java != lenguaje de secuencias de comandos. GDScript es suficiente; bastante fácil de aprender, etc.

Agregar un lenguaje como Java (¡¿crear una JVM para qué propósitos?! ¿¡Sintaxis?! ¿Requerir una JVM con una versión específica para funcionar?!?) o C# (Implementar mono y arruinar el motor; ¿o construir uno propio?) envenenaría el motor .

Si hay un problema con GDScript, debe señalarse; y luego intentó ser arreglado.

Estoy en desacuerdo. Siento que C# atraería a muchos desarrolladores de Unity o desarrolladores que están familiarizados con lenguajes similares a C, lo que ofrece una buena alternativa a Python como GDScript. La pieza final del rompecabezas sería una secuencia de comandos visual que atraería a los artistas que no están acostumbrados a la codificación. Esto debería cubrir a casi todos.
Además, no importa lo que codifiques, aún necesitas aprender las clases y funciones de Godot, que serían las mismas en cualquier idioma.

Para todas las personas que argumentan C# porque los desarrolladores de Unity lo conocen, consideren esto: muchos desarrolladores de Unity no saben una mierda sobre cómo programar en C#. Lo que saben es cómo usar la API de Unity, que resulta que tiene enlaces C#. Los traes a Godot, incluso si es C#, de todos modos no sabrán qué diablos están haciendo y estarán tan perdidos como si les proporcionaran un lenguaje de programación diferente.

Incluir cualquier idioma adicional es solo más gastos generales y más que el proyecto debe mantener que no debería tener que hacerlo.

Estuve pensando mucho en esto, y mi principal preocupación acerca de admitir algo como C# es que la mayoría de las personas que lo usarían serían usuarios de Unity que llegarían a Godot. Claramente, no incluiríamos C# con las plantillas oficiales, y dudo mucho que ellos mismos construyan el módulo...
Podría terminar siendo un gran esfuerzo para apoyar un idioma que sería utilizado por unos pocos.

Creo que hay un malentendido:

• Ven GDScript y piensan que GDScript está a la par con C#; perdiendo el punto fundamental de que C# no es un lenguaje de secuencias de comandos.
• Debido al hecho anterior, cuando alguien dice "Java o C#"; lo que realmente están pidiendo es una reescritura del motor en C#/Java o agregar algunos enlaces para admitir esos lenguajes (jaja, no).

Ya que estoy asumiendo lo último; la depuración en C#/Java es una pesadilla en múltiples plataformas; ya que ambos lenguajes no son independientes de la plataforma (inb4 hay tiempos de ejecución en prácticamente todos los sistemas operativos); se convierte en "Escribir una vez, depurar en todas partes" (esta es la razón por la cual los juegos escritos en Monogame salen primero en Windows y luego en Linux/Mac porque los desarrolladores tienen que depurar para esas plataformas). Esta es la razón por la que las actualizaciones de JVM rompen las aplicaciones.

Agregar soporte para esos idiomas no agrega valor al motor.

Si el argumento es "moar Unity devs"; luego se debe hacer la documentación para ayudar a los desarrolladores de Unity en la transición; que las diferencias de diseño, etc.

Es por eso que dije al final que no importa qué idioma uses, aún necesitarás aprender las clases de la API de Godot y todo eso. No es que los desarrolladores de Unity vayan a ser expertos en insta porque conocen C#. Supongo que es más un "aura de bondad" para Godot si es compatible con C#. La gente siente que sabe más y, de repente, Godot es más accesible y ya no da tanto miedo. Lo negativo número 1 sobre Godot de los usuarios que no son de Godot es que tiene su propio lenguaje de programación. Como usuario de Godot, sé que BS porque GDScript es un lenguaje divertido y simple, pero para los extraños puede parecer poco atractivo.
No puedo hablar desde el punto de vista de los desarrolladores, pero tal vez sea más esfuerzo de lo que vale, a menos que los desarrolladores obtengan algo de la implementación de C#, entonces vale la pena. Al final, es la decisión de los desarrolladores líderes y lo que sea que decidan, lo aceptaré. Estoy seguro de que será una buena decisión.

Estoy de acuerdo contigo en que GDScript es un poco desagradable porque es prácticamente un lenguaje desconocido. Pero, después de leer por qué se eliminaron Lua y Python y los beneficios de agregar GDScript, estaba menos preocupado.

Otra cosa que podría ser relevante: hay otro motor con licencia MIT que ya es compatible con C# y es más similar a Unity, Atomic Game Engine . Sugiero que todas las personas que necesitan desesperadamente algo lo más parecido posible a Unity lo prueben.

Solo agregaré mis 2 centavos aquí. Para mí, la gran ventaja de C# es el rendimiento, aunque sigue siendo más fácil trabajar con él que con C++. GDScript, al estar tipeado dinámicamente y todo, es muy rápido de escribir, pero nunca será ultrarrápido de ejecutar (aunque podría optimizarse bastante, lo cual está planeado). Los módulos de C++ son muy rápidos, pero es un poco incómodo trabajar con ellos; C ++ no es exactamente un lenguaje amigable, y tener que volver a compilar el motor para usarlos no es realmente óptimo. Para mí, C# es una especie de compromiso: mucho más rápido que GDScript y, con el soporte adecuado, es mucho más fácil trabajar con él que con los módulos de C++.

Dicho todo esto, no tiene que ser C#. Cualquier otra cosa que tenga un efecto similar estaría bien, en lo que a mí respecta, ya sea compilado estáticamente/JIT GDScript, o algo más como Swift o algo así. C# puede ser el mejor para 'propósitos de marketing'; incluso sin una API similar, los desarrolladores de otros motores/marcos probablemente se sentirían más cómodos con ella. GDScript modificado puede ser más fácil de implementar y probablemente se integraría mucho mejor.

Sé que el hilo es muy largo ahora, pero lea todas las publicaciones anteriores antes de publicar algo por su cuenta. El argumento de que C# iba a atraer a la gente y era muy conveniente para los usuarios de Unity no se vuelve más válido si se menciona una docena de veces más.

Vea aquí por qué imho C# es excelente para Unity y malo para Godot, vea aquí por qué imho agregar C# conducirá a un código sucio, no solo en sus propios proyectos sino también en tutoriales en línea, la próxima tienda de activos, etc. y vea aquí por qué imho el el argumento de que las personas tenían que aprender muchas cosas nuevas al cambiar de C# a GDScript no es válido.

Permítanme agregar un comentario sobre el argumento de que C# traería gente nueva.
¿Por qué queremos que más personas usen Godot? Entiendo perfectamente que los proyectos de código abierto necesitan una comunidad que

• agrega características
• corrige errores
• crea activos reutilizables
• hace sugerencias para nuevas características
• encuentra errores o problemas con el flujo de trabajo
• escribe tutoriales

pero todo lo anterior necesita gente que entienda y aprecie la idea central del motor. Las personas que agregan funciones innecesarias a una biblioteca no ayudan y ha habido más de un proyecto que sufrió tales funciones, a veces hasta el punto en que el proyecto se abandonó o se dividió.
Unity sufre especialmente de las personas que escriben tutoriales a pesar de que realmente no entienden lo que están haciendo, lo que en gran parte es culpa de C#.

Si las personas ni siquiera están dispuestas o no pueden aprender un lenguaje tan simple como GDScript, entonces es muy cuestionable si se tomarán el tiempo para comprender completamente la filosofía de diseño detrás de Godot antes de comenzar a contribuir activamente con la comunidad. ("Contribuir activamente" significa cualquier cosa, desde enviar solicitudes de extracción hasta publicar su opinión sobre Godot en Facebook).

Godot no es un motor comercial. Unity tiene interés en atraer a tantas personas como sea posible porque todos son clientes potenciales y publicidad del motor. Sin duda, sería bueno tener una gran comunidad de usuarios que aprecien a Godot tal como es, pero no tiene sentido sacrificar algunas de las cualidades de Godot para atender a una comunidad más grande.

La gente de

EDITAR: eliminó un lenguaje innecesariamente duro ;-)

@trollworkout Sin ofender, pero realmente no entendiste mi punto y tengo la sensación de que tampoco pensaste en lo que dijiste.

1. Sí, la gente no quiere perder el tiempo. Las especificaciones completas de GDScript: algunas pantallas. Libros que explican C#: por lo general, al menos 500 páginas. Pasé unos días aprendiendo GDScript y estoy bastante seguro de que no tiene una sola característica que no conozca. He trabajado tanto profesionalmente como en mi tiempo libre con C# durante años (usando Window Forms, WPF, XNA y Unity) y todavía encuentro fragmentos de código que usan funciones que no entiendo completamente. Preguntar por C# porque era menos una pérdida de tiempo realmente no tiene sentido.
2. "los principiantes terminarán aprendiendo cualquier idioma en el que estén escritos los fragmentos de código que usan"; consulte el punto 1. La noción de que podría aprender C# a partir de fragmentos de código está lejos de ser verdad. Las cosas que puedes aprender de esa manera son tan básicas que no te llevará más de unos días "aprender" un idioma diferente. Tú mismo dijiste que aprendiste GDScript de esa manera.
3. "C# hará que Godot forme parte de este ecosistema de desarrollo independiente". ¿Y qué se supone que significa eso?
   ¿Podrías usar fragmentos de código de Unity en C#-Godot? No.
   ¿Podrías reutilizar activos de Unity en C#-Godot? No.
   ¿Podrías leer los tutoriales de Unity y aplicarlos palabra por palabra a C#-Godot? No.
   Entonces, ¿qué es este "ecosistema de desarrollo independiente" al que te refieres?

Como dijo Paper-Pauper, hay muchos motores y bibliotecas para elegir.
¿Quieres un sistema de componentes como el de Unity? Mira Atomic Game Engine.
¿Quiere seguir usando C# en un motor pero quiere deshacerse del sistema de componentes? Mire CryEngine / Luberyard.
¿Quieres seguir usando C# pero quieres deshacerte del motor? Mira MonoJuego.

La idea de que agregar C# a Godot estaba ayudando a los principiantes es errónea, ya que tú mismo dijiste que aprendiste a escribir scripts en Godot mirando fragmentos de código. Si así es como aprende a trabajar con un motor, ¿no le gustaría un lenguaje que le diga implícitamente cómo funciona el motor en lugar de uno que esté diseñado para miles de casos de uso diferentes?

Solo agregaré mis 2 centavos aquí. Para mí, la gran ventaja de C# es el rendimiento, aunque sigue siendo más fácil trabajar con él que con C++. GDScript, al estar tipeado dinámicamente y todo, es muy rápido de escribir, pero nunca será ultrarrápido de ejecutar (aunque podría optimizarse bastante, lo cual está planeado). Los módulos de C++ son muy rápidos, pero es un poco incómodo trabajar con ellos; C ++ no es exactamente un lenguaje amigable, y tener que volver a compilar el motor para usarlos no es realmente óptimo. Para mí, C# es una especie de compromiso: mucho más rápido que GDScript y, con el soporte adecuado, es mucho más fácil trabajar con él que con los módulos de C++.

Todos los problemas que mencionó con C ++ que mencionó son válidos y podrían solucionarse a través de # 3936. Ya hemos discutido esto muchas veces, pero solo en aras de la claridad, aquí están los problemas con GDScript que podemos reconocer objetivamente:

1. Soporte deficiente para bibliotecas de terceros
2. Bajo rendimiento

Ser capaz de escribir partes en C ++ soluciona fácilmente ambos. C# (u otro lenguaje) también los arreglaría, pero con un tiempo de ejecución adicional, peor rendimiento y soporte multiplataforma y se necesita mucho trabajo adicional (mientras que Godot ya está escrito en C++). Entonces, la elección racional es usar lo que ya está allí (C ++) y mejorarlo y, por supuesto, solucionar esos problemas con GDScript.

Rápidamente leí este hilo y vi que GDScript to C estaba previsto.

Si esta es la forma elegida, sería bueno considerar incrustar el compilador tcc C en el editor para compilar el C generado. Tiene un tiempo de compilación muy rápido, es muy pequeño y fácilmente incrustable. Tal vez esta sería la mejor manera de acelerar las cosas.

TCC se distribuye bajo la Licencia Pública General Menor de GNU.

(fuente)

Esto lo hace probablemente inadecuado para incluirlo en Godot. También parece que ya no se mantiene.

@Warlaan No tengo que pensar demasiado. En este punto, todos dijimos lo mismo unas 10 veces, ya creo que sabemos bastante bien dónde estamos todos. Aparte de mis 2 centavos y algunas ideas, no tengo mucho más para contribuir ya que no soy un desarrollador y no conozco muy bien el motor. Dejaré que hablen los que saben mejor. Solo quería expresar mi apoyo y eso es todo.
Sin relación:
Pero sí, con respecto al punto 2, por el que armaste mucho alboroto, tuviste que editar tu comentario. ¿Entonces estás diciendo que no puedes aprender un idioma basado en ejemplos? Creo que ASUME que las personas no pueden aprenderlo a menos que lean manuales de 500 páginas en los que se conoce C # porque usted dice la razón 1 para rechazarlo. Bueno, yo soy la prueba viviente de que estás equivocado. ¿Cómo crees que aprendí GDScript? Con la API y ejemplos de demostraciones y haciendo preguntas. Tenga en cuenta que tenía 0 conocimientos de Python antes de comenzar, por lo que todo era bastante extraño. Como nota al margen, me pregunto cuántas personas compran manuales de libGDX frente a cuántas personas realmente buscan en Google "cómo hacer X en libGDX", probablemente por qué la tienda de activos es tan ruda en Unity. Y con eso terminé por el momento porque no tengo nada más que decir.

( @Calinou : Bellard permitió que una bifurcación de TCC se convirtiera en BSD o MIT. Pero la última vez que lo comprobé, el desarrollador de la bifurcación no había publicado el código fuente. Entonces, ¿quizás Bellard aceptaría permitir que la comunidad de Godot vuelva a otorgar licencias a TCC también?)

No estoy seguro de que TCC sea tan bueno como GCC o Clang como compilador: su tamaño es compatible con muchas arquitecturas y para una generación de código bastante optimizada (mejor rendimiento).

¿Qué pasa con Godot dependiendo opcionalmente de GCC o Clang para compilar C? Están instalados en las máquinas de la mayoría de las personas que construirían los juegos de todos modos (por lo que el tamaño no es realmente una preocupación), y es la forma en que lo hacen otros lenguajes que compilan en C (como Chicken ). También son compatibles con C++, en caso de que sea necesario.

Si se hacen dependencias opcionales, aquellos que no tienen GCC o Clang instalados (lo cual es extraño para un desarrollador que se supone que debe crear un juego para distribución, pero de todos modos) pueden usar el intérprete de GDScript tal como está ahora.

Sugerí usar TCC como JIT para GDScripts. Así que la característica más importante fue la velocidad de compilación. Y creo que los resultados ya podrían ser mucho más rápidos que la solución actual.

La mayoría de la gente quiere C / C ++ para el rendimiento y Lua / Javascript para ser más fácil y rápido de escribir, entonces, ¿por qué no tener lo mejor de ambos mundos?

Nim - http://nim-lang.org/

Eficiente como C, expresivo como Python y flexible como Lisp

Ventajas:

• Compila en C, C++, Obj-C o JS ( http://nim-lang.org/docs/backends.html )
• (Python / Pascal) como ( https://learnxinyminutes.com/docs/nim/ )
• GC o Manual ( http://nim-lang.org/docs/gc.html )
• Se puede usar en otro lugar que no sea Godot
• Multiplataforma (windows, linux, osx, mobile)
• Ayuda a convertir código C en Nim
• Admite bibliotecas C
• Compilador modificable
• MIT con licencia
• Fuente abierta
• tipo seguro

Contras:

• Requiere un compilador C/C++ en la computadora del desarrollador -> gcc , vcc , llvm_gcc , icc , clang o ucc _(no es realmente una estafa, en mi opinión)_
• pequeña comunidad
• Aún no es 1.0

La lista TODO de Nim es pequeña, está cerca de 1.0:
https://github.com/nim-lang/Nim/blob/devel/todo.txt

como dijo paper-pauper (sobre tener un compilador en la computadora del desarrollador):

Están instalados en las máquinas de la mayoría de las personas que construirían los juegos de todos modos.
https://github.com/godotengine/godot/issues/5081#issuecomment-227706106

https://hookrace.net/blog/lo-que-es-especial-de-nim/
https://hookrace.net/blog/what-makes-nim-practical/

https://github.com/nim-lang/Nim/wiki/Nim-for-C-programmers
https://github.com/nim-lang/Nim/wiki/Nim-for-Python-Programmers

No es mi solución favorita, pero si debe seguir ese camino, le sugiero que use Haxe ( haxe.org ) en lugar de Nim.

No puedo comentar sobre la licencia de Haxe (el compilador en sí usa "GPLv2 +", la biblioteca estándar usa MIT), pero todos los demás factores lo convierten en una opción superior en mi humilde opinión.
Es una plataforma probada (actualmente en la versión 3.2.1) a diferencia de Nim que aún no es la versión 1.0, pero lo que para mí es mucho más importante es que la sintaxis es mucho más cercana a otros lenguajes conocidos. Al leer los ejemplos de Nim, me parece que los desarrolladores detrás de ese lenguaje intentaron encontrar soluciones inusuales y/o feas.

Pero como mencioné, no es mi solución favorita y he aquí por qué:
Los lenguajes intermedios como Nim o Haxe tienen muchas "dependencias semánticas". No me refiero a las dependencias de bibliotecas o ejecutables que deben estar presentes, me refiero a que se relacionan con otros idiomas. Ahora bien, como dije antes, los idiomas ya no son herramientas, son culturas. E incluso si solo los ve como herramientas, tienen diferentes dominios centrales para los que fueron creados. Por ejemplo, tiene mucho sentido que el comando "eco" imprima texto en la salida estándar cuando se ingresa en la entrada estándar. Solo es consecuente usar el mismo comando en un script por lotes. Siguiendo esa lógica, es comprensible que PHP use el mismo comando. Usarlo en un lenguaje de propósito general como Nim no tiene sentido, ya que básicamente todos los demás lenguajes de propósito general tienen métodos llamados algo con "escribir" o "imprimir" en el nombre.
No tengo idea de por qué Nim todavía usaría "eco" como nombre para ese comando, pero este es el tipo de cosas que puedes observar mucho con Haxe y que esperaría de Nim en el futuro si no es que ya en el primer lanzamiento. . Por ejemplo, la biblioteca estándar de Haxe contiene un método substr(int, int) y un método substring(int, int). Uno de los dos devuelve la subcadena del primer al segundo índice, el otro devuelve la subcadena del primer índice con la longitud del segundo argumento. La razón por la que ambos existen es que, como el idioma se puede usar para reemplazar idiomas de diferentes tipos, tiene usuarios que provienen de diferentes plataformas y, a menos que haya alguien con una mano muy fuerte que decida qué se incluye en esa biblioteca de código abierto y qué no. fácilmente terminará con tal mezcla de estilos de codificación.

Es muy importante elegir las herramientas adecuadas para el trabajo adecuado. Los lenguajes como Haxe (o C# para el caso) intentan brindarle un lenguaje que se adapta a todos, por lo que la mayoría de las veces termina usando "solo una herramienta" que, lamentablemente, se parece a esto .

Me gustaría agregar mis 2 centavos después de trabajar con Godot por un tiempo.
Lo que me gustaría ver (y también he estado viendo, con... un éxito limitado) es C++ como un lenguaje de primera clase en Godot.
Escribiendo la lógica pesada de computación (resolución de colisiones, física, transformaciones e IA) en C++ y guionando los nodos usando GDScript (disparadores, condiciones, animaciones y sonidos).

GDScript ES bastante fácil de aprender, colocando a Godot un poco más cerca de Gamemaker que de Unity en ese sentido.
Pero después de escribir 3 juegos pequeños y jugar con un montón de demostraciones, debo decir que a GDScript le falta algo más que juegos muy básicos.

Los archivos de código se vuelven demasiado largos y el editor de código carece de muchas funciones útiles que se encuentran en otros IDE, como: colapsar ámbitos, regiones, saltar al inicio/final del ámbito actual.

GDScript también carece de un montón de características básicas de los lenguajes de procedimientos tales como: adecuado para _ _ bucles, adecuada _ _ do ... while bucles (que soporta los bucles el interruptor de casos ... _, _ _ operador ternario , _ enumeraciones _.
_ No hay conciencia de la relación clase-escena _ por lo que si no está preconstruido, es una clase "externa" y debe cargarse previamente.

Además, dada la naturaleza de GDScript, no hay referencias a funciones ni plantillas.
No es nada espectacular, pero es muy molesto.

Ojo776; GDscript solo no se puede usar para más que juegos simples si decide ignorar las otras características (como usar nodos y devoluciones de llamada donde sea posible) en lugar de ceñirse exclusivamente a funciones como _get_overlapping_bodies()_

La razón es que dichas devoluciones de llamada y el uso de nodos es mucho más rápido que tratar de hacer todo con un script grande y muy pocos nodos. El árbol se hace más grande, pero no es un problema con el sistema de creación de instancias de escena de Godot.

Por ejemplo, los objetos que necesitan una velocidad constante de rotación pueden usar una animación para eso en lugar de configurar la rotación manualmente usando GDscript, las cosas que dependen del tiempo pueden usar nodos de temporizador, etc. Creo que una forma inmediata (y sencilla) de permitir juegos más rápidos sería elegir entre más tipos de nodos (cada uno con sus propias devoluciones de llamada y conexiones).

Los archivos de código se vuelven demasiado largos

¿Te refieres a guiones como este? https://github.com/Algorithmus/CastlevaniaClone/blob/master/game/players/player.gd
¿Crees que C# puede evitar que esto suceda? Personalmente no lo hago. En realidad, hace que sea más fácil refactorizar y detectar errores antes en estos scripts largos debido a las herramientas (sí, cuando las personas se refieren a C#, a menudo se refieren implícitamente a VS) y la tipificación estática, aunque los errores de ruta de nodo serían indetectables hasta que se ejecute el juego. Pero aparte de eso, un buen diseño y uso de nodos puede simplificar mucho los scripts.

el editor de código carece de muchas funciones útiles que se encuentran en otros IDE, como: colapsar ámbitos, regiones, saltar al inicio/final del ámbito actual.

Estos se pueden agregar en el futuro si lo solicita, aunque puede usar un editor externo sin problema (https://atom.io/packages/lang-gdscript), Godot incluso tiene servicios de autocompletado.

Si realmente haces un juego ENORME, es probable que quieras extender Godot usando C++.
En realidad, encuentro esto un poco desalentador actualmente debido al proceso de reconstrucción del motor, pero hay razones para ello .

No hay conciencia de la relación clase-escena.

¿Qué quieres decir? Sabes que puedes poner un guión en la raíz de una escena, ¿verdad? Además, los editores de C# no pueden adivinar qué hay en la escena en la que se usan, mientras que GDScript sí puede.

Además, dada la naturaleza de GDScript, no hay referencias a funciones ni plantillas.

Hay funcref y signal si busca algo similar a lambdas y eventos, y las plantillas no son importantes porque el lenguaje es dinámico. Los lenguajes dinámicos a menudo prefieren usar el tipo pato en lugar de interfaces y genéricos. Además, la composición sobre la herencia funciona muy bien si quieres cosas reutilizables.

GDScript también carece de muchas características básicas de los lenguajes de procedimiento.

Estoy un poco de acuerdo. Algunos de ellos han sido solicitados pero no recuerdo los problemas, tendrás que buscar. Por ejemplo, me gustaría ver un for que pueda iterar en algo más que rangos de enteros y contenedores (¿flotantes?), así que uso while . Eso es de hecho un poco molesto, pero nada demasiado grave.

¿Te refieres a guiones como este? https://github.com/Algorithmus/CastlevaniaClone/blob/master/game/players/player.gd

Debo decir que incluso si el archivo es largo, he visto cosas mucho peores y todavía es bastante legible a pesar de que el código es bastante procedimental. Ahora finalmente entiendo por qué una sintaxis simple es mejor para GDScript: es la mejor para la lógica de juego promedio, que es principalmente if s y llamadas a funciones.

Me gustaría ver a alguien argumentar que el mismo archivo escrito en C# es más fácil de leer o escribir, u ofrece ventajas prácticas además del rendimiento (que es peor que el de C++ de todos modos). Creo que C# sería una exageración para este tipo de secuencias de comandos, que son más complicadas que las secuencias de comandos que se utilizan en algunos juegos 2D profesionales.

Estoy un poco de acuerdo. Algunos de ellos han sido solicitados pero no recuerdo los problemas, tendrás que buscar. Por ejemplo, me gustaría ver un for que pueda iterar en algo más que rangos de enteros y contenedores (¿flotantes?), así que uso while. Eso es de hecho un poco molesto, pero nada demasiado grave.

¿Podría profundizar un poco más en la parte for y algunos ejemplos de lo que se refiere en pseudo-GDScript?

@paper-pauper las cosas que le faltan a GDScript no están relacionadas con C#, pero por ejemplo for i in range(-PI, PI) no funciona en GDScript, así como for i=0, i < size and stuff, ++i . También me gustaría escribir ternario en lugar de tener que escribir un si de tres líneas. Pero como dije, ya hay problemas en el rastreador y no me impedirá usar GDScript: p

Pero incluso si todos sus scripts tienen un máximo de 200 líneas y están relativamente bien diseñados, si tiene miles de ellos en su juego, tendrá problemas para mantener y refactorizar esa base de código: y esto no es tanto por el idioma, pero debido a las herramientas : una gran parte de la popularidad de C# se debe a que Visual Studio es un IDE excelente para él. Estoy bastante seguro de que si Godot integra las herramientas adecuadas (ir a definición, clase confiable/función/cambio de nombre de miembro, encontrar todas las referencias, etc.), trabajar en enormes bases de código GDScript será mucho más fácil. En términos más generales, esto es lo que me gustaría ver en Godot, cómo puede escalar bien para juegos GRANDES, porque hasta ahora no vi ninguno (incluidos mis propios proyectos).

for i in range(-PI, PI)

Eso hace que mi cabeza gire sobre su eje hasta que llega a una división por cero y empieza a destruir la entropía. Espero que ningún idioma implemente una declaración tan impredecible. ¿Qué hace? Iterar sobre números enteros entre -PI y PI (es decir, -3, -2, ..., 2, 3), o entre múltiplos de PI (es decir, -PI y 0), o itera sobre flotantes que algunos pasos predeterminados de vudú como 0.176 o ln(2) que algún programador de lenguaje encontró más apropiado?

@akien-mga lo siento. Debería haber agregado un argumento de paso xD, pero todavía no funciona. Aquí está el problema que hice para él https://github.com/godotengine/godot/issues/4164

Estoy de acuerdo en que lo que Godot extraña es herramental. El principal problema es la naturaleza pato-escribiendo de GDScript, lo que dificulta saber qué es qué y, por lo tanto, dificulta realizar algunas acciones como "buscar referencias" o "ir a la definición".

Está planeado agregar sugerencias de tipo a GDScript, pero dado que esto será opcional, no estoy seguro de cuánto se puede mejorar. Sin duda contribuirá mucho a la finalización del código y puede facilitar el trabajo en mejores herramientas.

@vnen Un modo EMACS para GDScript en (M)ELPA ya sería un paso en la dirección correcta, en mi libro :)

Ah, sí, casi me olvido de estos dos problemas que, curiosamente, en realidad me retrasaron en la práctica:

• Los argumentos no forman parte de la firma de una función. Eso significa que no puede anular funciones.
  En la práctica, tener function doFoo(a,b,c,d) y function doFoo(a,b) en la misma clase resultará en una falla de compilación. Terminé renombrándolos a doFoo4(a,b,c,d) y doFoo2(a,b) y refactorizando un montón de archivos de script.
• Dado que no hay soporte para enumeraciones, todos los indicadores y códigos de retorno son, por necesidad, enteros, por lo que debe adivinarlos y muchos aún no están documentados en este momento.

PD: Obviamente, las funciones no se llamaron literalmente doFoo . ;)

EDITAR: @Ace-Dragon: Otros motores me han enseñado que los nodos/componentes/etc. integrados complejos. puede cambiar y cambiará, rompiendo el juego en el proceso. Es por eso que, aparte de las devoluciones de llamada de activación básicas (colisiones, valores, temporizadores), prefiero evitar confiar demasiado en ellas.
Tampoco soy un gran admirador del paradigma de ranura de señal, por lo que tiendo a evitarlo si es posible. Por otra parte, también prefiero los hilos a las rutinas, llámame ludita :)

@Zylann : ~1200 LOC?... pffft No, estoy hablando del verdadero negocio... 20k+ LOC por archivo. Un desarrollador de juegos de rol que usa Unity, que permanecerá sin nombre (no, no trabajo para ellos), habitualmente tiene clases con 25k+ loc. Luego vuelven a hacer todas sus funciones estáticas y usan C# como si fuera C. :temeroso:

Lo siento por el fuera de tema.

@ eye776 No se me ocurre ningún lenguaje dinámico que permita anular (en algunos casos se puede falsificar con argumentos predeterminados), pero sería una buena idea tenerlo en GDScript.

Y los cambios revolucionarios en el motor se pueden detectar y revertir fácilmente en un programa libre como Godot, por lo que no deberían ser una preocupación.

@ eye776 Tampoco he visto lenguajes dinámicos con anulación de funciones. GDScript tiene parámetros predeterminados, por lo que se pueden usar en su lugar.

Además, ¿quién es el loco que hace 20K+ LOC en un solo archivo? El problema aquí no radica en la herramienta... En toda la fuente de Godot no hay un solo archivo que pueda encontrar con 10K LOC.

En lo que estoy de acuerdo es en darle a C++ un poco más de amor. Pero para los usos que citó anteriormente, solo estoy de acuerdo con AI. Y también generación procesal, por citar uno más. Ahora, si estás rehaciendo la física del motor, el renderizado, etc., entonces digo que ya ni siquiera estás usando Godot, solo hiciste una bifurcación. Si no puede confiar en los tipos incorporados, ¿para qué necesita el motor?

Por supuesto, GDScript no es perfecto (ningún idioma lo es). Tampoco está tallado en piedra. Enumeraciones, cambio/caso y operaciones ternarias son algunas probables adiciones en el futuro (ya hay problemas abiertos al respecto). El hecho de que no tenga algo en este momento, no significa que nunca lo tendrá.

Finalmente, las "dudas" realmente no ayudan. Lo que necesitamos son puntos de referencia y casos de uso. Ya hay juegos bastante complejos escritos en GDScript, así que no veo lo que realmente falta.

@vnen solo por diversión: godot/drivers/gles2/rasterizer_gles2.cpp es 11K LOC :p (es el más grande que encontré, pero es una rara excepción).

@vnen

Si no puede confiar en los tipos incorporados, ¿para qué necesita el motor?
Bueno, como un contexto multiplataforma de calidad para empezar. Pero eso no significa que escribiré mis propias clases de sprite o modelo.

Godot me quemó una vez en marzo (v 2.0.1). Estaba jugando con una cámara y un personaje en tercera persona e intenté usar la propia física de Godot para el movimiento (arrastre y fuerzas) y lo hice funcionar.
La siguiente actualización de la versión menor (v 2.0.2) básicamente rompió la velocidad del personaje (2-3 veces más rápido) para los mismos valores exactos.
Descubrí que era mejor mantenerlo cinemático y hacer mi propia "física".

Además, sin relación con Godot, me quemé muchas veces confiando en cosas automatizadas como los guiones gráficos de XCode.
Dejé de ser cortejado por el brillo y rezo para que el código que genera automáticamente el IDE a mis espaldas no se meta con el mío.

De todos modos, lamento mucho haber descarrilado el hilo.

@ eye776 ¿

¿Mono o CoreCLR? ¿Y por qué?

Mononucleosis infecciosa:

• MIT con licencia
• estable
• posibilidad de ser abandonado
• buena documentacion

NúcleoCLR:

• MIT con licencia
• todavía no es 1.0 (actualmente es RC2)
• pequeña
• mala documentacion

Usamos Mono porque se implementa en dispositivos móviles y web. creo que aqui esta
cero posibilidades de que sea abandonado porque es mucho más portátil. mi corazonada
es que ambas bases de código eventualmente se fusionarán.

El jueves 4 de agosto de 2016 a las 13:45, Hubert Jarosz [email protected]
escribió:

¿Mono o CoreCLR? ¿Y por qué?

Mononucleosis infecciosa:

• MIT con licencia
• estable
• posibilidad de ser abandonado
• buena documentacion

NúcleoCLR:

• MIT con licencia
• todavía no es 1.0 (actualmente es RC2)
• pequeña
• mala documentacion

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

Además de lo que @reduz mencionó anteriormente, la API está encapsulada, por lo que no es demasiado difícil cambiar a CoreCLR más adelante si es necesario.

CoreCLR: todavía no es 1.0 (actualmente es RC2)

Alcanzó 1.0 estable el 14 de junio.

Mono: posibilidad de ser abandonado

¿Basado en que?

Mono: buena documentación

Ah ah ah

¿Basado en que?

¿Por qué Microsoft desarrollaría tres pilas de .NET? No es bueno en cuanto a recursos. (.NET Framework, Mono, .NET Core)

Ah ah ah

Revisé ambos documentos sobre la interoperabilidad de C++/C# (lo que necesitamos para Godot) y está bastante bien documentado en Mono. En coreCLR, tuve que analizar parte de su código y pedir ayuda a los desarrolladores para que mi aplicación funcionara.

La guía de referencia tiene demasiadas funciones sin documentar, enlaces rotos...

En teoría soy parcial aquí... Pero espero que mis argumentos sean objetivos...

• No veo ninguna disminución en el desarrollo de Mono: https://github.com/mono/mono/graphs/contributors
• El desarrollo para Mono en Windows nunca fue tan fuerte como lo es hoy (una especie de prueba (sin vincular toneladas de confirmaciones) https://github.com/mono/mono/pull/3231 Miguel dice "ya que ahora tenemos mantenedores reales") Haciendo punto anterior aún más claro
• La API integrada en Mono está probada en batalla (no solo Unity, hay muchos otros usuarios privados)
• Mono HOY se ejecuta en PS4, Android, Windows, iOS BITCODE (se invirtieron años de trabajo en esto), AppleTV y muchas más plataformas...

Entonces, en mi humilde opinión, si desea entregar esto en un futuro cercano (menos de 3 años) y en la mayoría de las plataformas de juegos ... Elija Mono.

Hola,

Algunos comentarios:

• Además de las plataformas enumeradas por David Karlas, también estamos agregando compatibilidad nativa con WebAssembly, XboxOne, UWP y Win64.
• La muestra que se comparte también se puede hacer con métodos virtuales (despacho más rápido) o se puede hacer con eventos de C#.
• Históricamente, C# ha estado al frente de muchas innovaciones del lenguaje, extrayendo buenas ideas de cualquier lugar. Ha popularizado y traído al mercado masivo muchas ideas de la investigación del lenguaje y que ahora damos por sentado, cosas como iteradores, genéricos no borrados, lambdas, programación asíncrona, propiedades, invocación de plataforma, pero es uno de los lenguajes que son desarrollado más activamente
• En general, Unity no muestra un C# moderno, ya que utilizan un tiempo de ejecución más antiguo. Es de esperar que esto cambie pronto. Dicho esto, el Mono actual es compatible con todas las funciones nuevas de C#, entre las que se encuentran la programación "asincrónica", que es ideal para el código del juego, ya que puede escribirlo de forma lineal y el compilador reescribe automáticamente su código como una máquina de estado, como las corrutinas o la avanzada. versión de "rendimiento" como se usa en Unity.
• Los contextos de sincronización significan que puede escribir código asíncrono que se ejecuta dentro de un contexto específico. Por ejemplo, es posible que tenga una ejecución ligada al juego, o la ejecución ligada a IO, o la ejecución ligada al subproceso principal frente al segundo plano, todo es parte del sistema.
• Durante la implementación, tiene la opción de compilación JIT o compilación estática (AOT) con o sin LLVM, por lo que prácticamente es tan rápido como C ++, además del hecho de que C # realiza verificaciones de límites de matrices (dicho esto, si usa nativo amortiguadores, recupera su rendimiento, a expensas de la seguridad)
• En los últimos años, dado el fuerte enfoque de Mono en dispositivos móviles, el GC de Mono se ha ajustado no para servidores, sino para cargas de trabajo interactivas. Nuestro nuevo GC es generacional con pequeños viveros que se pueden recolectar muy rápidamente y no requieren escanear todo el montón.

En cuanto a por qué Microsoft está desarrollando varios CLR (tenemos tres: CoreCLR para cargas de trabajo JIT; familia CoreRT, para compilación estática en UWP; Mono para cargas de trabajo móviles) es porque todos tienen propósitos ligeramente diferentes. Las partes internas están convergiendo donde sea posible, por ejemplo, Mono ahora ha reemplazado alrededor del 60 % del código principal con código que se comparte directamente con el resto de .NET. Solo es cuestión de averiguar qué carga de trabajo se adapta mejor a sus necesidades.

Puede comenzar con una máquina virtual hoy y cambiar a otra en el futuro. Actualmente, Mono tiene una superficie de API más grande, funciona en dispositivos móviles, se optimizó para cargas de trabajo interactivas y admite más arquitecturas (como ARM64).

La buena noticia es que cambiar una VM por otra, o admitir ambas, requiere un par de días de trabajo, por lo que no se encierran en una implementación específica.

@migueldeicaza ¡Bienvenidos! Impresionante que hayas decidido participar en nuestra discusión y que estés interesado en Godot :+1: Espero que te quedes con nosotros por un tiempo :)

Gracias por el buen desglose @migueldeicaza! Tengo dos preguntas rápidas para ti o para otros desarrolladores de Mono.

1) ¿Cuál es la configuración actual para depurar Mono incrustado en Windows con Visual Studio? Unity tiene su complemento, pero no he podido encontrar nada más que complementos que se conectan a máquinas Linux/OSX.

2) ¿Cuál es la forma recomendada de manejar la recompilación en tiempo de ejecución (compilar, descargar y volver a cargar, por ejemplo, un ensamblaje para el juego o complementos de herramientas en el editor)? Desafortunadamente, C# (muy) no expone un método Assembly.Unload() y tratar con AppDomains y problemas cruzados de AppDomain parece ser demasiado molesto para esta situación.

Como referencia, Unity no solo usa Mono - https://github.com/xamarin/urho (enlaces C#/Mono para el motor Urho3D) - ese tiene una licencia MIT, por lo que podemos buscar fácilmente su solución.

Mis dos centavos:

C# es muy superior para la programación de juegos que otros lenguajes de nivel similar, ya que admite tipos de valores personalizados. Esta es una característica extremadamente importante para el rendimiento, que Java (y JVM en general) literalmente no tiene alternativa.

Usted obtiene:

• Tipos matemáticos asignados a la pila, que admiten operaciones matemáticas y objetos temporales sin asignaciones de almacenamiento dinámico.
• Recopilaciones continuas optimizadas y aptas para caché.
• Genéricos que utilizan tipos de valor (incluidos los tipos primitivos)

Además de eso, C# tiene otras características que te hacen la vida más fácil. No veo ningún mérito en usar Java en lugar de C# cuando C# simplemente supera a Java en casi todo lo que importa en la programación de juegos.

Hola a todos,
No he leído todo lo anterior (simplemente demasiado :))
pero tuve algunas vacaciones, así que hice un módulo prototipo para Godot que actúa como msDotNetHost, por lo que puedo proporcionar algunos hallazgos por los que he pasado, tal vez sean útiles. lamentablemente, mis vacaciones terminaron y tengo que codificar dinero nuevamente :), pero es/fue divertido :)

estado actual es:
o) el módulo amplía la clase de nodo para exponer los eventos de nodo a netCode
(init, tree_entered, ready, process, fixedprocess....)),
o) "módulo contenedor/host de red" hecho (utilizando el mecanismo de host dotNet de Microsoft)
está encapsulado en una biblioteca dinámica, por lo que un cambio a Mono debería ser fácil más adelante
o) los métodos dotNet están enlazados y llamados (init, tree_entered, ready, process, fixedprocess....)
o) la clase de nodo está envuelta y vinculada a netAssembly (código escrito manual para creación de prototipos)
o) las llamadas a godot (desde netCode) funcionan a través de un mecanismo de vinculación autoescrito
(de dll a godot-exe) por lo que el exe no necesita exportar funciones.
o) debido al uso de msDotNet, está vinculado a Windows en un futuro próximo.

mi hoja de ruta para incluir .Net sería:

1. módulo para Godot usando el mecanismo de hospedaje microsoft .Net (hecho)
2. wrappin godotClases
   (mi estado actual: escribiendo un generador de contenedor, que analiza el código de Godot C++,
   el análisis está hecho, la generación está en curso)
3. sacar el proyecto del estado de prototipo (completar los bordes, probarlo...)
4. escriba el mecanismo de alojamiento Mono, para deshacerse de los enlaces de Windows
5. de alguna manera habilite Visual Studio para depurar mono, para deshacerse de xamarin/monodev (como unity vs-plugin)
6. diviértete con cientos de nuevos desarrolladores de godot .net :)

algunas preguntas:

1. Me pregunto si podría reutilizar el mecanismo de enlace utilizado para gdscript. pero no tengo tiempo para evaluarlo todo, ¿hay algún buen tutorial o algunos consejos importantes para mí?

2.
Actualmente genero un contenedor que envuelve todos los métodos de Godot en funciones para que puedan llamarse fácilmente a través del límite de dll y el límite de c ++ / netCode. (mecanismo de enlace autoescrito para netCode)
No quiero cambiar el código de Godot (excepto el código de mi módulo) para seguir siendo compatible.
también estático, no estático, virtual no virtual me hizo llorar, por eso elegí este camino.
¿Alguna solución mejor para esto?

algunos pensamientos adicionales:

Microsoft .Net frente a Mono:

Creo que no importa si usa mono o msDotNet, porque en la mayoría de los casos, el código dotNet se ejecuta sin cambios en ambos. El único esfuerzo para admitir ambos es escribir un "host" para cada uno de ellos (es la parte más pequeña de un "GodotDotNet"). Elegí msDotNet para la creación de prototipos.
bueno, mono admite muchas plataformas msDotNet solo windows, entonces, ¿por qué admitir/usar msDotNet?
La respuesta: productividad, depuración

msDotNet:
Especialmente al escribir/prototipar el DotNetModule, necesito/quiero compilar y depurar RÁPIDAMENTE, significa que su depurador debe saltar a netCode desde C++ y viceversa.
Elijo VisualStudio, porque puede depurar ambos. PERO solo si usas msDotNet.
¡Al hacerlo, cambia una parte de netCode, presiona ejecutar y en 1 segundo! esta compilado y funcionando!!! incluyendo la posibilidad de depurar en godot. (Si no has cambiado algo en Godot, entonces tienes que esperar normalmente de 30 segundos a 1 minuto... ¡Malditos tontos lentos! :))

Mononucleosis infecciosa:
Mono debe ser el objetivo final, no hay discusión sobre eso (independencia de la plataforma), pero:
si uno usa mono, tiene un gran problema cuando se trata de depurar: ¡mono tiene su propio mecanismo de depuración!
para mí es un gran éxito para la productividad, porque a menos que escriba un complemento de monodepuración para visualstudio (unity hizo esto) no puede depurar el código de red alojado en mono en visual studio y depurar en código c ++ (hay soluciones de pirateo pero ...).
Intenté configurar una solución basada en Mono, pero terminé usando ambos en paralelo, VisualStudio (para c ++) y xamarin/monodev (netcode).

Conclusión:
estado del prototipo: msDotNet
lateron: mono, para usuarios que no están interesados ​​en depurar en godot/c++ e independencia de plataforma
después de eso: cree un vs-plugin para depurar mono

c# frente a java:
la respuesta es clara C#! java es para scritpkids! (oh, ¿qué piensa el codificador c ++ sobre los desarrolladores c # :))
no, esto era una broma :)
No entiendo la discusión... cuando se implementa el sistema .net, puede usar todos los idiomas que admitan dotNet, incluidos ambos idiomas y más.
este no es el caso si el sistema java es compatible...

@Ziflin :
Pregunta 1:
también hizo esa búsqueda ... solo monoRemotedebugger es la (no) solución atm :(
mi recomendación es, como se indicó anteriormente: use microsofts dotNet hosting para la creación de prototipos
luego, en algún momento posterior, cambie a mono.
alternativa:
inicie xamarin en su modo pirateado, déjelo escuchar localhost, establezca los puntos de interrupción, luego inicie su proyecto en comparación con lo probado, funciona, pero ...
para mi no es solucion! ¡Quiero un mecanismo de "ejecutar y depurar en 1 segundo" y esto con 1 clic!
No tengo mucho tiempo en mi tiempo libre, por lo que la productividad es mi objetivo principal.

Pregunta 2:
no sé mono tan bien todavía, pero creo que tienes que hacerlo en C++, implementar alojamiento mono, administrarlo desde "afuera" en C++.

Los enlaces C# oficiales de https://github.com/neikeq/GodotSharp/

cool tnx, entonces sé cómo paso algunos de mis próximos días festivos;)

Hola, me acabo de encontrar con godotSharp, pero se ha caído.

esto es droped.

La versión oficial que escuché en IRC fue algo así como:

@neikeq no le gusta enviar código sin terminar, así que trabaja en su sucursal local

Bueno, es bueno saberlo, estaba a punto de hacer mi propio módulo, pero supongo que también podría hacerlo para Godot 2.2 o 3.0.

No habrá lanzamiento 2.2, los desarrolladores de Godot movieron todas las funciones 2.2 a 3.0.

Esta es la primera vez que comento. Vine de Unity y el cambio a GDscript ha sido un sueño. Aprendí el idioma en menos de un día. Me encanta lo bien que se implementa el lenguaje en el motor y mi productividad ha aumentado considerablemente.

Mi principal preocupación es que con la compatibilidad adicional con C#, GDscript se quedará atrás o verá menos desarrollo después de una avalancha de desarrolladores de Unity. C# es un buen lenguaje pero no es mi favorito personal

También me preocupa ver a Godot tratando de parecerse más a otra locomotora en lugar de valerse por sí mismo. Unity es una historia de éxito fabulosa, pero no es el mejor motor que he usado. Está hinchado y con errores. Una vez que eliminó todo mi proyecto sin confirmación. Lidiar con errores y cosas que no funcionaban como deberían fue una lucha constante. No puedo contar cuántas veces tuve que reconstruir por completo una escena en la que estaba trabajando porque las cosas no funcionaban bien. Una vez copié y pegué todo el contenido de una vieja escena con errores en una nueva escena para que funcionara de repente a pesar de que ambas escenas eran idénticas. Perdí semanas cazando errores de física que aparecían y desaparecían mágicamente.

Me gusta mucho que Godot sea ligero y fácil de entender. Trabajar con Godot ha sido como usar un instrumento musical bien afinado. Después de casi un año de trabajar en él, sé cómo hacer todo lo que necesito hacer, incluso si no lo he hecho antes. Solo espero que la afluencia de usuarios de Unity no dirija la dirección del motor más hacia Unity. Si quisiera Unity, entonces estaría usando Unity.

@zaywolfe Su preocupación ha sido expresada varias veces por otros usuarios. No tienes nada de qué preocuparte. GDScript seguirá siendo el lenguaje principal en Godot.

No me gusta GDScript . Entiendo que se inspiró en Python, pero me siento muy débil. C ++ o Java incluido (listo para usar) sería una gran idea en mi opinión. Personalmente, me disgusta usar GDScript en el desarrollo, hasta el punto de cuestionar si dejar Godot y regresar cuando se implementó un lenguaje nuevo (o alternativo). Lo sentimos, pero si desea conocer los datos concretos de un programador, los tiene.

Además, me gustaría mencionar que a veces incluso uso Godot para algunos prototipos de software simples. Por lo tanto, un lenguaje de programación profundamente integrado posiblemente abriría puertas para el desarrollo de software dentro del motor. Eso sería realmente un asesino de Unity. (Si, por supuesto, se eligió Java o C ++)

¡Gracias a los desarrolladores leales por su arduo trabajo, los admiro a todos y espero con ansias los futuros lanzamientos actualizados!

@VenHayz No sé si lees la documentación de Godot, pero ya puedes escribir tus juegos en C++, desde la primera versión de Godot - http://docs.godotengine.org/en/stable/reference/custom_modules_in_c++.html

¿Qué pasa con el uso de microsoft .net core? es multiplataforma y centrado en el rendimiento, así como también es de código abierto y se desarrolla activamente

hola solo paso un chico al azar

Quería que supieras que no estoy usando Godot porque no me gusta el lenguaje de script que usas.

Si agrega Java o C#, instalaré y usaré Godot justo después de su anuncio :)

@RUSshy adiós entonces, te lo pierdes, godot es increíble, GDScript es genial, si eres un verdadero programador, te tomará literalmente dos horas saber más que suficiente para comenzar cualquier proyecto. Los verdaderos programadores deben dominar muchos lenguajes, puedes apegarte a tu Java/C# y ser un tipo "aleatorio" que pasa como aficionado para siempre. No estoy tratando de ser grosero, solo expongo hechos. Si no le gusta algo de este motor, contribuya con algún código, es gratis a diferencia de la mayoría de los otros motores.

Dios del marketing favorece a C#. :risa:

@RebelliousX Elegir Java o C# significa que tendrá MUCHAS bibliotecas disponibles para usar

Limitarse al lenguaje de script hecho en casa es simplemente inútil, su nuevo conocimiento no será aplicable en ningún otro lugar y no podrá encontrar toneladas de bibliotecas, o no podrá reutilizar su conocimiento o los recursos de aprendizaje existentes.

La elección es una locura hoy en día, no seas de mente cerrada

@RUSshy ¿Estás bromeando? Yo (y varios otros) escribimos literalmente páginas de explicaciones sobre los beneficios de GDscript sobre C# y ¿crees que podrías resolver la discusión con un breve párrafo sin leer nada de lo que se dijo antes?

"No seas de mente cerrada" - gran idea, ¿qué tal si empiezas por ser de mente abierta acerca de GDscript?
"su nuevo conocimiento no será aplicable en ningún otro lugar" - eso es simplemente falso. No podrá compensar la falta de conocimiento copiando y pegando un código que no entendió.
"no podrá encontrar toneladas de bibliotecas": aprenda la diferencia entre un lenguaje de secuencias de comandos y un lenguaje de back-end. O, idea loca, lee lo que escribí al respecto.

En serio, la audacia de algunas personas...

Se ha dicho varias veces en varios lugares que se está trabajando en un módulo de integración de C#. Va tan rápido como la cantidad de tiempo que la gente tiene para hacerlo. La única forma de hacerlo más rápido es contribuir a esa integración :)

@Warlaan sobre el segundo punto: si escribió un montón de código en C# antes, no puede reutilizarlo a menos que lo transfiera todo. Tampoco necesita comprender el código de una biblioteca para poder usarla. El punto es que, si necesita algo que estaba en C# antes (un solo archivo o un conjunto de bibliotecas, fuente potencialmente cerrada), debe portar todo, incrustar un tiempo de ejecución de C# o encontrar una implementación de C. Eso no es imposible, pero requiere mucho tiempo.
Sin embargo, eso no significa que Godot no pueda usar muchas librerías existentes... C/C++ también tiene toneladas de ellas.

Esto corre el riesgo de convertirse en una guerra de llamas.
El registro es tan largo que la gente repetirá las mismas preguntas o el mismo tema en lugar de leerlo.
Tampoco queda mucho material técnico por discutir.

El futuro de Godot en términos de secuencias de comandos ya está bastante claro:

• GDScript permanecerá como el idioma principal y hay planes o ideas para optimizarlo (pero este no es el lugar adecuado para discutir eso).
• A partir de la versión 3.0, se admitirá C# como alternativa a las secuencias de comandos. Proporcionaremos archivos binarios separados para evitar forzar el tamaño adicional causado por el tiempo de ejecución mono a las personas que no lo usarán.
• DLScript también está trabajando. Permitirá a las personas usar bibliotecas compartidas para secuencias de comandos. Estas bibliotecas se pueden escribir en cualquier idioma que admita enlaces c y bibliotecas compartidas (espere lenguajes como Rust y D). Sin embargo, aún no está claro si estará listo para 3.0 (a menos que esté desactualizado).
• ¡No olvide que también habrá Visual Scripting en 3.0!

Si alguien planea contribuir con algo más, este tampoco será el lugar adecuado para discutir eso.

Creo que este tema puede y debe cerrarse.

Acordado.

¿Podría proporcionar un enlace a los códigos fuente de integración de C#?

https://github.com/neikeq/GodotSharp

¿Qué tan funcional es la integración de GodotSharp? ¿Está listo para usar para la prueba?
¿Se puede usar con la compilación fuente de Godot Master?

@nictaylr Actualmente no se está construyendo con el maestro. Si desea probarlo, debe usar 2.2-legacy. Funciona muy bien con esa versión.

Estoy trabajando para tenerlo listo para una versión alfa 3.0 en abril.

Idea aleatoria, pero después de pensar profundamente en C++ con Godot, pensé en algo posiblemente mejor. El lenguaje D. Se encuentra dentro de una cuota de idioma posiblemente de "bajo nivel", con interfaz para C y (algo) de soporte para C ++. Tiene clases, y es muy moderno. Si bien suena aterrador, se parece mucho a GDScript , y pude ver que se usa para impulsar proyectos muy grandes. Es lo suficientemente potente como para competir con C y C++ (gcc/g++) con un compilador llamado GDC. (DMC también se puede usar para compilar, pero GDC compila directamente en gcc) vea más sobre GDC aquí

De todos modos, solo una sugerencia rápida o tal vez para obtener ideas.

@VenHayz Estoy trabajando en un módulo que permite el uso de bibliotecas compartidas para scripts. Ya me esforcé un poco para hacer que C++ sea más fácil de usar con él. También puede usar D para crear esas bibliotecas. Si estás interesado en hacer enlaces D, contáctame en IRC o Discord.

@karroffel eso es realmente genial. No tengo experiencia con la escritura de bibliotecas y API (referencia a su mención de "enlaces"), aunque probablemente podría investigarlo por un día y hacerlo; Soy orgullosamente un aprendiz rápido. Me gustaría ponerme en contacto contigo en Discord, si no te importa. Mi discordia: _hasCat#3941

@VenHayz No puedo agregarte, no estás permitiendo que otros te agreguen. Karroffel#8409 o únete al servidor de Godot

@neikeq ¿Es su repositorio de GodotSharp la base de código que se utiliza para el soporte de C# en Godot 3.0? Solo pregunto porque estoy tratando de tener una idea aproximada de las funciones que estarán disponibles y, de ser así, investigaré esa base de código. ¡Gracias!

me veo bien, está desactualizado? nueva caracteristica ? o está listo para usar en la construcción de desarrollo?

¿Cómo puedo compilar godosarp de fuente para mí?

@nictaylr Deberá usar la rama heredada 2.2 como una compilación de desarrollo.

Creo que leí lo suficiente para averiguar si alguien más mencionó esto.

Personalmente, simplemente no quiero aprender otro idioma que no pueda usar en ningún otro lugar. No planeo hacer mucha programación en 3D, solo algunas cosas aquí y allá.

Sí, hay muchos argumentos en contra, pero... es un proyecto de código abierto. No hay necesidad de odiar a alguien que contribuya con un nuevo lenguaje de programación.

Imagina llevar cerveza a una fiesta infantil. ¿Dirías que "no hay necesidad de odiar a alguien que contribuye con una nueva bebida"? Existe una buena posibilidad de que agregar C# perjudique el desarrollo de GDscript. Sé que todos están decididos a mantener GDscript como el idioma principal de Godot, pero todavía me molesta cuando se ha explicado varias veces por qué agregar nuevas funciones tiene desventajas y la gente todavía pregunta "¿cuál es el daño?".

También pedir C # en lugar de GDscript porque "no quieres aprender" es un argumento realmente estúpido. De todos los lenguajes que conozco en el desarrollo de juegos, GDscript tiene la menor cantidad de funciones y C# tiene la mayor cantidad. Si no quieres aprender, deberías estar agradecido por GDscript.

Realmente no quiero calentar esta discusión una y otra vez, así que si alguien quiere comentar sobre este hilo POR FAVOR LÉALO DESDE EL ARRIBA.

También pedir C # en lugar de GDscript porque "no quieres aprender" es un argumento realmente estúpido.

No me importaría aprender C# porque podría usarlo en otro lugar.

Cierra el hilo, se está poniendo malo.

Es cierto que este hilo ha cumplido su propósito, cerrémoslo.