Realmente me gusta tu publicación.

EDITAR:
Joder, se me pasó por alto este párrafo.

Tenga una forma de copiar los archivos en el proyecto en caso de que se desee una modificación en el nivel de origen. Solo entonces los archivos deben llevarse a la carpeta del proyecto. Los activos "clonados" podrían vivir en una carpeta oculta como .custom.

Así que básicamente has cubierto las preocupaciones que tenía. (lo siento)
Solo profundizo más en cómo imagino el flujo de trabajo + el comportamiento.

CORREO:
Sin embargo, en mi opinión, se pasa por alto un flujo de trabajo.
Utilizar los activos solo como recursos o como primeras piedras de construcción.
El enfoque actual realmente transparente y simple también le permite descargar un par de activos. eliminar algunos archivos. Luego, conserve algunos png y un script que tenga algunas de las funciones que desea. Actualmente es posible simplemente trabajar en ellos y modificarlos.

Si los activos estuvieran ocultos en una carpeta .local/godot/assets esta funcionalidad se perdería.

Propuesta

Los activos aún deben estar visibles y enumerados en el explorador de archivos del editor. Independientes si están dentro de la carpeta .local/godot/assets o de la propia carpeta del proyecto. Para que pueda navegar por los archivos y comprender cómo funciona en caso de que no haya documentación adecuada, o si desea aprender de ella.
Cada carpeta que sea 'un activo' también debe marcarse como una con algún tipo de icono para que tenga una visión general de qué es un activo y dónde se almacenan los archivos reales.
También debe haber una ventana de edición que enumere todos los activos. (en una mesa)

• Descargado enumera todos los recursos que se descargaron. Se pueden agregar a su proyecto con un clic de un botón. Pero aparte de eso, son los mismos que los activos en la librería de activos. Esta lista es la misma en cualquier proyecto y no tiene ningún efecto sobre el proyecto en sí. (Simplemente facilita tener una descripción general. También es fácil borrar esta lista y volver a descargar todos los activos al abrir un proyecto).
• Siempre activo (básicamente solo alterna "Usado en este proyecto (activo/inactivo)" para cada proyecto) Esos activos se agregan a CADA PROYECTO en su máquina (incluso los recién creados). (Tal vez el activo en sí necesita permitir eso). Esos están realmente orientados al Editor. Como un reloj en la esquina, soporte de git, listas de tareas pendientes o tener más recursos predeterminados: (un entorno personalizado, algunos temas más y un montón de sprites para trabajar al comienzo de cada proyecto)...
  Se pueden desactivar manualmente por proyecto.
  Sin embargo, todavía se enumeran en el sistema de archivos del proyecto y se comportan como cualquier otro plugin/assed. para que pueda navegar por sus archivos y ver cómo funcionan/qué hacen.
• Usado en este proyecto (activo/inactivo) , esto realmente muestra la carpeta vinculada en el sistema de archivos del proyecto. y "agrega" (todavía están dentro de la carpeta .local/godot/assets , pero se comportan como archivos locales del proyecto). archivos al proyecto.
  Aquí también puede elegir qué versión del Activo desea activar. Y cambiar la versión.

Tan pronto como desee editar/guardar/actualizar un archivo de un Activo, se le solicitarán dos opciones

Ahorra en .local/godot/assets

actualice el activo en .local/godot/assets lo que lo coloca en una versión de usuario personalizada.
Si el administrador de paquetes está basado en git, la versión de usuario personalizada podría ser una confirmación adicional. que obtiene commit --amend cada vez que guarda.
( 3.2.5/user por ejemplo) y también está disponible en todos sus otros proyectos. (al actualizar la versión en esos otros proyectos a su versión de usuario)
¿Por qué es útil?
Un tema de la tienda de activos es casi perfecto, pero odias el tipo de fuente...
cambie el tipo de fuente y guárdelo como una nueva versión de activo. Vuelva a revisar todos sus otros proyectos y cambie la versión de activos a /user . Ahora tu estás feliz.
Tal vez también podría haber un botón para publicar la versión de usuario del recurso.
Entonces, en la tienda de activos, otras personas tienen la opción de elegir también una versión de usuario con ajustes menores.
Solo como un intermediario para hacer un pr al repositorio de activos git. (o el autor del activo decide seleccionar los cambios de una versión de /user a una nueva versión en el maestro).

Hacer local para proyectar

copia los archivos de la carpeta .local/godot/assets en el proyecto actual... elimina cualquier comportamiento especial de activos (como la versión...) y ahora puede jugar con él como quiera. (también la carpeta pierde su apariencia personalizada como activo).

Esto permite que la tienda de recursos también cubra el caso de uso de las plantillas. Y es una opción perfecta para casi cualquier activo relacionado con el arte. Ya que puedes trabajar en los activos para hacerlos como los necesitas.
Siempre puede simplemente activar un montón de activos ya descargados (digamos algunos sprites de prototipos básicos) hacerlos locales y tenerlos importados.

pensamiento aleatorio

Esta podría ser incluso una buena solución para su propia biblioteca/colección de activos/recursos locales. Una carpeta en .local/godot/assets te permite agregar su contenido a cualquier proyecto de Godot con una buena interfaz de usuario de editor y sin buscarlo en el administrador de archivos de tu sistema operativo.

Estoy de acuerdo en que tanto AssetLib como la integración de asset lib (tanto en el editor como con GDScript) necesitan amor si seguimos impulsándolo como una alternativa a incluir cosas en el motor central.

Sin embargo, personalmente no estoy de acuerdo con la fuerza con la que se debe impulsar este complemento .

La primera pregunta que nos hacemos sobre un nuevo PR no debería ser ¿ podría ser un complemento? pero más bien , ¿se usará esto lo suficiente como para estar en el núcleo? .

Hay problemas con tener cosas en complementos:

• La gente necesita saber lo que está buscando en primer lugar. Godot está dirigido a principiantes . El software amigable para principiantes generalmente intenta tener todo lo que alguien va a necesitar (razonablemente), porque de lo contrario, primero deben aprender lo que se están perdiendo y cómo lo van a obtener.
  Hay una razón por la cual los principiantes usan Ubuntu, no Gentoo. Independientemente de lo bueno que hagas ese sistema de dependencia.
• La parálisis de decisión existe. Si hay una característica en Godot, genial, toma un segundo usarla. Si hay 5 complementos para él, ¿cuál voy a usar? Por ejemplo, hay más de 5 complementos de consola . ¿Cuál debería elegir un principiante, y por qué, y cuánto tiempo debería dedicar razonablemente a esta decisión?
• Los complementos se abandonan, tienen menos calidad, se retrasan cuando se actualizan. Hay aún menos razón para confiar en que un complemento aleatorio no explotará que para confiar en Godot, donde hay suficientes personas detrás de él.
• Ver Unidad . Sus activos son en su mayoría incluso pagados , y todavía apesta que para muchas cosas necesite complementos primero que eventualmente están mal integrados o se rompen en las actualizaciones, o se interrumpen, a pesar de que son pagados y generalmente pueden permitirse al menos algo de soporte.
• Documentación : No tenemos suficiente de esto de todos modos. Cada característica que no está en el núcleo, no puedo usarla en tutoriales/documentos oficiales. Es probable que las personas solteras al azar para los complementos no proporcionen documentos, o solo ejemplos breves, no la parte más valiosa de proporcionar demostraciones o tutoriales completos sobre cómo integrar esa función con otras sin problemas en un proyecto.

Ejemplos:

• Nodo de brazo de resorte. (https://github.com/godotengine/godot/pull/18822) Una adición razonablemente pequeña, separada en su propia clase, por lo que no debería romper las cosas, será utilizada por muchos juegos 3D, si no por todos los juegos de tercera persona . Respuesta: debería ser un complemento.
• Incluso para las cosas de RNG, se discutió tenerlo como complemento. Como si no, el 90% de los juegos necesitan un RNG en alguna parte.

Editar: para ser claros, estoy a favor de evitar la hinchazón. Pero esto es un equilibrio, y quiero expresar mi apoyo por no tener todo en los complementos. Cosas muy específicas del juego o que no se usan ampliamente, complementos propietarios, grandes dependencias, sí, por favor , ¡póngalos en Asset Lib!

@karroffel Esta es una excelente publicación y en general estoy de acuerdo con todo lo que dijiste. Sin embargo, me gustaría comentar sobre este punto:

Los activos se guardan con la versión asociada, todos almacenados en .local/godot/assets o algo así. Ya no son parte del proyecto en sí, sino que están disponibles en todo el sistema.

Esto es similar a cómo funciona el sistema pip de Python. Luego, la gente se dio cuenta de que la última versión de un paquete arruinó los otros proyectos que tiene en su sistema. virtualenv resuelve ese problema. En el ecosistema npm de Javascript, los módulos se instalan localmente en un proyecto de forma predeterminada y todo el sistema es una función opcional ( npm install --global ). Luego, verifica su package-lock.json en el control de código fuente para asegurarse de que todos en el equipo usen la misma versión de cada módulo npm y evitar conflictos.

Los paquetes de todo el sistema son buenos ya que reducen la sobrecarga en los sistemas de las personas. La fijación de versiones es buena porque ayuda al equipo a mantener un conjunto coherente de versiones y puede ayudarlo a identificar una colección completa de versiones que funcionan bien juntas.

Si vamos por la ruta de todo el sistema, sugeriría mantener la fijación de versiones. Por ejemplo:

.local/godot/assets/fsm/1.0
.local/godot/assets/fsm/1.1

El Proyecto A podría usar fsm-1.0 mientras que el Proyecto B usa fsm-1.1. El Proyecto C viene y podría reutilizar cualquiera de los dos. Los usuarios deberían poder especificar versiones específicas de complementos en sus archivos dependencies.json o parche mínimo, versiones menores o mayores.

Una vez que se descargan las dependencias, se puede generar un archivo dependencies-lock.json y verificarlo en el control de código fuente.

@mhilbrunner Definitivamente estoy de acuerdo, creo que la mentalidad de "esto debería ser un complemento" se presiona demasiado, exactamente esas situaciones provocaron esos pensamientos. Creo que cosas más comunes como el SpringArm son dignos de estar en el motor, así como el InterpolatedCamera , que Juan quiere eliminar, ¡es increíblemente útil y genial! Aunque esas cosas son solo unas pocas líneas de código, tardan un tiempo en hacerlo bien, por lo que "esto es demasiado pequeño" también es una mala justificación para avanzar hacia AssetLibrary.

Mis pensamientos se centraron principalmente en "Bueno, el líder del proyecto dijo que es así, entonces, ¿qué se puede hacer para mejorar la nueva situación?"

Me gustaría que la gran cantidad de funciones como complementos se redujera un poco, pero de cualquier manera, ¡creo que los cambios presentados ayudarían mucho!

@saltares Sí, ese fue mi pensamiento. Soy un gran admirador de la carga para Rust. Funciona más o menos igual. Las bibliotecas se instalan en una carpeta de todo el sistema en todas las versiones que alguna vez se necesitaron localmente. La descripción está en un archivo y una configuración específica está en un archivo .lock , ¡funciona bastante bien!

Me alegro de que esto haya provocado alguna discusión :blush:

Aquí está mi opinión sobre los puntos anteriores:

Empujando cosas fuera del motor

Empujar cosas fuera del motor es, en mi opinión, el camino a seguir. Hay demasiadas plataformas donde el tamaño de implementación importa (móvil, html5) y la hinchazón es una gran preocupación para un proyecto del tamaño de Godot, por lo que no podemos contentarnos con incluirlo todo.

La filosofía para mí debería ser que algo debería ser parte del motor solo si se cumplen TODOS los criterios a continuación:

1. Se usa con relativa frecuencia
2. es dificil hacerlo tu mismo
3. Solo hay una forma de hacer esta función.

Esto descarta el brazo de resorte, el terreno y espero que pueda ayudar, en el futuro, a eliminar funciones como la cámara interpolada, el vehículo, etc. que creo que deberían estar fuera del motor.

La principal preocupación sobre esto es que, si algo no es oficial, no se va a mantener. Aquí es donde ustedes están equivocados.

Nadie dijo que estas cosas no deberían ser oficiales, podemos tener un repositorio oficial para ellas y pueden ser extensiones propias. Las demostraciones se mantienen de esta manera y están actualizadas, por lo que no veo por qué no funcionaría para un repositorio de extensión oficial.

Las extensiones deben sentirse como parte del motor.

Con respecto a estos puntos:

• facilitar la extensión de nodos personalizados, permitir la herencia de scripts entre idiomas

Estoy muy en contra de esto. No hay beneficio práctico en absoluto al hacer esto, y el costo de implementación es muy alto. Lo siento chicos, sé que se siente como una buena característica, pero ponderar el costo/beneficio/riesgo es muy negativo.

También creo que es positivo que los nodos o recursos personalizados aparezcan como si NO fueran centrales, algo bueno para los usuarios finales. Los usuarios no son tontos y esta información no debe ocultarse para ellos.

Si se agrega un nuevo nodo desde una extensión y se hace con un script, esto debería mostrarse incluso en el cuadro de diálogo de creación.

• No se sugiere la herencia de secuencias de comandos al adjuntar una secuencia de comandos; la anulación es la opción predeterminada para esos casos.

Esto definitivamente debe hacerse y sería una adición muy bienvenida.

• agregue una gestión de dependencia adecuada con instalaciones de activos en todo el sistema. Mueva los complementos fuera del proyecto en sí mismo con una forma de recuperarlos para modificarlos

Mi sensación acerca de esto es que puede funcionar fantástico o resultar en un completo desastre y complementos que se rompen sin una razón obvia. Mirando cómo funcionan otros motores con esto, no me parece que tener una gestión de dependencias sea tan importante.

• permita que se haga referencia a los scripts por nombre de clase y espacio de nombres para evitar rutas muy largas en el caso de los activos.

Esto es algo que discutimos antes, pero la conclusión a la que llegamos fue que debería depender principalmente del lenguaje de script (y no proporcionado por el propio motor como un ScriptDB central), con una pequeña mejora de usabilidad en el nuevo diálogo de script en caso de que desee utilizar una clase global.

Mi sensación acerca de esto es que puede funcionar fantástico o resultar en un completo desastre y complementos que se rompen sin una razón obvia.

Supongo que los complementos nunca deberían actualizarse automáticamente en nuestro caso, sino que debería haber una lista de los instalados con la versión enumerada y la actualización manual, para que el usuario pueda solicitar la actualización y verificar de inmediato si algo se rompió.

Este comentario está separado en secciones colapsadas debido a su gran extensión.

¿Quieres una cámara? Godot tiene una cámara que puede seguir a un jugador, con poco o ningún código de tu parte. ¿Quieres hacer una animación en Godot? No solo puede hacer animaciones de personajes, ese mismo sistema puede (casi) reemplazar ese sistema de cinemáticas en el que trabajó tan duro, solo necesitando unas cinco o más líneas de código de su parte. El editor incluso se ha utilizado para crear otros editores como RPG in a Box. Es fantástico todo lo que puedes crear en Godot.

Ahora, con eso fuera del camino, espero que cualquiera que lea esto pueda entender lo que estoy pensando al entrar en esto mientras trato de responder a algunos de los puntos de reduz con respecto a sacar cosas del motor. (Esto no responderá a la sección "Las extensiones deben sentirse como parte del motor", ya que no tengo pensamientos sobre eso actualmente).

Empujar cosas fuera del motor es, en mi opinión, el camino a seguir. Hay demasiadas plataformas donde el tamaño de implementación importa (móvil, html5) y la hinchazón es una gran preocupación para un proyecto del tamaño de Godot, por lo que no podemos contentarnos con incluirlo todo.

Puedo estar de acuerdo en que la hinchazón es una preocupación, pero cuando veo lo que quieres eliminar hasta ahora, me pregunto si realmente vale la pena eliminar esas cosas. Incluso si elimina nodos como Vehicle, InterpolatedCamera, etc... ¿Cuánta diferencia en el tamaño del archivo hará eso realmente? ¿Tal vez medio megabyte? ¿Quizás un par de megabytes? Incluso si ahorra varios megabytes, ¿cuál es la diferencia entre una descarga de 35 MB y una descarga de 45 MB de todos modos? ¡Los activos del juego llenarán rápidamente ese vacío de 10 MB a pesar de todo! A menos que planee quitar la mitad del motor, no veo el punto.

Si realmente le preocupa ahorrar la mayor cantidad de espacio posible, ¿puedo sugerir que sea más fácil para el usuario final eliminar los nodos que no necesita del motor? Deje que las personas que van a usar el motor decidan si están de acuerdo con la hinchazón, no decida por ellos.

Ahora, por supuesto, no podemos simplemente incluir todas las sugerencias que se nos dan...

1. Se usa con relativa frecuencia
2. es dificil hacerlo tu mismo
3. Solo hay una forma de hacer esta función.

...y estas pautas son un excelente punto de partida para analizar qué debe permitirse en el motor. No hay duda de que los tres puntos ya se están considerando para cada solicitud de función que llega a través del rastreador de problemas.

algo debe ser parte del motor solo si se cumplen TODOS los criterios a continuación

Pero vamos. El destino de una característica o nodo no debería depender tanto de ser una característica central. Sus pautas sugeridas son excelentes, no me malinterpreten, pero no deberíamos usarlas como una lista de verificación. Eso es lo que hace YoYo Games cuando sugieres una función en sus foros, y es otra razón por la que me alejaron de su motor: ¿se puede hacer usando una extensión? ¿Sí? Entonces nuestra respuesta es hacer una extensión. Adivine cuántas solicitudes de características se han denegado porque podrían convertirse en extensiones, independientemente de cuán razonable sería que estuviera en el motor, cuán fácil en comparación sería implementar o cómo se siente la comunidad acerca de esa característica

Lo que estoy diciendo es que definitivamente puedes tener esas pautas en mente. Puede considerarlos cada vez que se sugiere una característica. Pero el hecho de que todas se apliquen NO debería ser el factor decisivo para que una característica se incluya. Sopesar la idea con respecto a esas pautas, considerar la importancia de cada una de esas pautas y aplicar peso a esos factores... Solo porque una idea no parece que se usa con demasiada frecuencia no lo convierte automáticamente en una mala idea (tenga en cuenta que es posible que no sepa la verdadera escala de cómo se usa, incluso con varios años de experiencia). El hecho de que una idea sea fácil de implementar no significa automáticamente que sea una mala idea. ¡Y el hecho de que podamos implementar una idea en más de una forma no significa que sea una mala idea! Sin mencionar que tal vez alguien sugiera la idea X porque cree que otras personas se beneficiarían de ella.

Recuerde que este es un motor que se anuncia a sí mismo como apto para principiantes, y cada vez que un principiante tiene que codificar algo no específico para su juego que no es parte del motor, o buscar en alguna biblioteca de activos para obtener el código que necesitan. , o tomar un camino largo para obtener lo que quieren del motor, podría alejarlos un poco más hacia otro motor, o, a veces, incluso alejarlos del desarrollo del juego en general.

tl; dr : las pautas son excelentes cuando se usan como pautas y no como listas de verificación.

La principal preocupación sobre esto es que, si algo no es oficial, no se va a mantener. Aquí es donde ustedes están equivocados.

Nadie dijo que estas cosas no deberían ser oficiales, podemos tener un repositorio oficial para ellas y pueden ser extensiones propias. Las demostraciones se mantienen de esta manera y están actualizadas, por lo que no veo por qué no funcionaría para un repositorio de extensión oficial.

Personalmente no estoy de acuerdo con esta idea. Además de lo que dije anteriormente (que eliminarlo del motor estándar no le ahorrará mucho espacio), tengo que preguntar si vamos a convertirlos todos a GDscript, o si vamos a requerir para volver a compilar el motor solo para obtener esos nodos.

• Si los mantenemos como C++ y requerimos una recompilación... ¿por qué? No hay una buena razón por la que se nos deba volver a compilar el motor a menos que estemos cambiando una parte central del mismo o agregando nuestra propia funcionalidad. Eso es solo tiempo adicional que se le quita al desarrollo, porque estamos esperando que termine el proceso de compilación, además de requerir que el usuario promedio instale otras herramientas que tal vez ni siquiera vuelva a usar solo para obtener algunos nodos propios. ¡Ahora eso suena como una hinchazón!

• Si los convertimos a GDscript, eso vendrá con todas las limitaciones de GDscript. Limitaciones como la posible sobrecarga de nodos secundarios adicionales (especialmente si le pide al usuario que importe este nodo propio como una escena), tener que usar rutas en lugar de nombres de clase para referirse a sus clases (aunque abordó esto, parece, pero siento que necesito mencionarlo), menor rendimiento (independientemente de cuán pequeña sea la diferencia, aún es menor), etc. Es un poco más ideal que C ++ porque ha pasado de volver a compilar a arrastrar y soltar, pero...

Cualquiera de las dos opciones también significa que los archivos de estos nodos deberán importarse al motor con cada nuevo usuario (para C++) o a la carpeta del proyecto con cada nuevo proyecto (para GDscript) que desee utilizarlos. No sé para todos los demás, pero eso me parece una molestia, y parece que haría que su primera directriz ("Se usa con relativa frecuencia") sea muy discutible. Trataré de explicar por qué pienso esto.

Al requerir un esfuerzo adicional para usar esos nodos, estoy bastante seguro de que la cantidad de usos de esta solución propia disminuirá, y esta solución propia realmente ya no se usará "con relativa frecuencia" donde pudo haber sido antes. Eso, a su vez, aumentará lentamente la cantidad de alternativas que recrean las mismas funciones cuando las personas dejen de aprender que existe una solución propia, cuando estoy bastante seguro de que preferiríamos las versiones existentes (en este caso, la nuestra) a ser mejorado, en lugar de tener uno nuevo creado con la función X añadida, uno nuevo con la función Y, y uno nuevo con ambas funciones pero no tan optimizado, y así sucesivamente... Está creando este mercado de alternativas cuando la gente No sé que hay una solución de primera parte. Está creando un lío .

Además, dices que se mantendrán. ¡Eso es genial! Pero, ¿quién los va a mantener? ¿Cuáles serán nuestras pautas para agregar cosas nuevas a este repositorio? ¿Y vamos a hacer el esfuerzo de garantizar que este repositorio de extensiones propias siempre funcione, ya sea con una versión estable o con una versión maestra? Básicamente, ¿vale la pena el esfuerzo de lo que efectivamente es un proyecto separado?

por cierto, prefiero implementar múltiples secuencias de comandos por soporte de nodo
en lugar de la herencia entre idiomas. El primero es solo un par de líneas.
de codigo..

El domingo 10 de junio de 2018 a las 13:51 PLyczkowski [email protected] escribió:

Mi sensación acerca de esto es que puede funcionar fantástico o resultar en un
completo desorden y complementos que se rompen sin una razón obvia.

Supongo que los complementos nunca deberían actualizarse automáticamente en nuestro caso, pero
en su lugar, tal vez debería haber una lista de los instalados con la versión enumerada
y actualización manual, por lo que el usuario puede solicitar la actualización y verificar de inmediato si
algo se rompió.

—
Estás recibiendo esto porque comentaste.

Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/godotengine/godot/issues/19486#issuecomment-396063688 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AF-Z21jtcnUhRyhdyEEnaM_hfTACsxOiks5t7U6HgaJpZM4UhqDC
.

Se han intentado varias secuencias de comandos por nodo un par de veces y siempre fallan.

lo que se intentó es el nodo multiscript, pero fue una molestia

El domingo 10 de junio de 2018 a las 15:01 Zireael07 [email protected] escribió:

Se ha intentado varias secuencias de comandos por nodo un par de veces y siempre
defecto.

—
Estás recibiendo esto porque comentaste.

Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/godotengine/godot/issues/19486#issuecomment-396068742 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AF-Z26u8Rqc1yL-BGX16CAx_iWsYEo1oks5t7V8CgaJpZM4UhqDC
.

Entiendo que los activos no deben tener el mismo aspecto que las cosas integradas. Pero también creo que deberían estar en una clase más alta que los scripts creados por usuarios. Deben tener una separación clara para que sea fácil reemplazar/actualizar activos sin tener que extraerlos de su proyecto.

Además, agregar una capa para los activos y permitir que se integren mejor con el motor para ampliarlo es una excelente manera de mantener el núcleo pequeño y limpio, mientras proporciona fácilmente nuevas funciones a través de la biblioteca de activos. Si los activos pueden registrar nuevos tipos no solo para nodos/recursos, sino también para ampliar las clases, de una manera que sea accesible globalmente (es decir, no dependiente de la ruta), sería un gran beneficio para los marcos construir sobre el motor.

Los marcos como Escoria podrían beneficiarse mucho de él, y podría haber otros marcos para cosas como juegos de rol, juegos de plataformas, novelas visuales, etc.

Todo lo que digo aquí es bastante abstracto, pero tener una separación clara de lo que está integrado, lo que es un activo de terceros y lo que es el código de usuario (independientemente de cómo se presente esta separación) hará que "mantenga el núcleo pequeño y proporcione extensiones "avanzar con mucha facilidad.

La herencia entre idiomas me parece una idea horrible.

En el trabajo que he estado haciendo con TypeDB en EditorData, he estado manteniendo un nombre de tipo con espacio de nombres para la ruta de archivo HashMap que se convierte en un diccionario en ProjectSettings tras la modificación. En mi rama, el analizador y el compilador de GDScript utilizan estos datos para crear nombres globales para los tipos. En este momento, tengo scripts de tipos personalizados que aparecen. Los scripts pueden acceder a ellos y heredarlos por nombre. Además, estos datos son accesibles para cualquier persona que pueda ver ProjectSettings. Por lo tanto, un CSharpScript visto por el Editor puede generar una asignación que se ingresa en el Diccionario de configuración del proyecto, lo que permite que los tipos declarados en C# sean accesibles para GDScript. Probablemente también haya una manera de envolver los datos del diccionario ProjectSettings en un objeto C# que devuelve objetos Script cuando se accede, de esa manera C# también podría acceder a los tipos GDScript por nombre.

Esta técnica mantiene los espacios de nombres compartidos fuera del núcleo y únicamente dentro del contexto del Editor, por lo que los idiomas que optan pueden preparar sus propios medios para acceder a los datos.

Sin embargo, me gusta la sugerencia de @karroffel de poder tener herencia de scripts en varios idiomas (ni siquiera sé si eso sería posible). De alguna manera duplican automáticamente los métodos que delegan las llamadas al script base y también definen las mismas propiedades/señales/constantes, etc.

A mí también me gustaría un acceso más simplificado al contenido de AssetLibrary, con la capacidad de mantener algunos complementos para el editor en general y otros complementos para un solo proyecto.

El sistema TypeDB que estoy creando también dará soporte al editor para...

1. Hacer que todos los scripts personalizados de uno aparezcan en CreateDialog
2. Haga que la extensión de un script de tipo personalizado lo extienda automáticamente al agregar un script al nodo
3. Haga que la eliminación de una secuencia de comandos que amplíe una secuencia de comandos de tipo personalizado restablezca la secuencia de comandos de tipo personalizado después de la eliminación (por lo que no puede eliminar una secuencia de comandos personalizada; en su lugar, debe usar el comando "Cambiar tipo" en el Editor).

Además, todos los cambios en la interfaz que estoy haciendo mantendrían los scripts de tipo personalizado claramente entendidos como scripts, además de mantener accesible el script en cuestión. Los usuarios siempre sabrán qué es una secuencia de comandos y les permitirán acceder a la secuencia de comandos, pero aún así los hace sentir como objetos en el motor hasta cierto punto. Incluso dentro de GDScript, no se accede globalmente a los nombres, como si fueran un tipo central, sino que se extraen de un diccionario global llamado Scripts . Hasta ahora lo tengo trabajando con scripts de tipo personalizado, pero me gustaría expandirme eventualmente para que el Diccionario registre escenas de tipo personalizado y cualquier script o escena típica disponible en el proyecto también, probablemente a través del sistema de importación si el lenguaje de script no lo hace. tener un medio simple de adquirir el nombre de tipo con espacio de nombres.

Como he sido parte del proceso de reflexión de esta propuesta, me gustaría señalar algunas cosas:

Mi visión de Godot

TLDR: Me imagino a Godot como una herramienta que puede ampliarse mucho con activos y complementos de una manera muy fácil, modular y amigable para principiantes.

Los motivos detrás del rechazo de mi SpringArm pr son más que razonables, y es por eso que @karroffel y yo discutimos sobre la dirección que podría tomar el motor para seguir siendo liviano y, al mismo tiempo, fácil de usar.

Lo que me encantaría ver es un motor central limpio, pequeño y rápido y un ecosistema bien integrado de complementos y complementos.
Como ArchLinux tiene más de un repositorio de paquetes, creo que sería genial si Godot tuviera un repositorio "oficial" (mantenido por Godot) para la funcionalidad central (y los nodos que ahora son centrales) y otro repositorio para la comunidad. En el "repositorio de extensiones" del núcleo de Godot, pondría todos los nodos que son difíciles de codificar pero que no se usan lo suficiente como para enviarse con la versión estándar del motor.
Nota al margen, lo que a menudo no se tiene en cuenta es que algunas características pueden ser fáciles de codificar, pero también pueden requerir mucha investigación antes de establecer estas pocas líneas.

Me imagino que los usuarios pueden descargar complementos y activos que se sienten como si estuvieran "extendiendo" el motor en sí: dependiendo de lo que estés descargando, tienes Godot-fps o Godot-platformer o Godot-racing.

Godot podría ser el primer motor en sentirse realmente como Unix y modular, superando incluso a Unity con sus extensiones de editor. Muchos de ustedes saben lo bien que se siente cuando su sistema Linux no es "esa distribución", es su propio sistema personalizado con sus funcionalidades muy personales.

Ventajas

TLDR: este enfoque permitiría que la administración de Godot administre por separado las características técnicas básicas y los complementos más fáciles de usar sin preocuparse demasiado por inflar el motor

Lo bueno de esta propuesta es también la separación de preocupaciones y el manejo del contribuyente. Siento que, por ahora, no está claro qué está bien estar en el núcleo y qué no. No hay una regla clara ni datos estadísticos para hablar. Algunos podrían decir que cierta característica es ampliamente utilizada y otros piensan que no lo es.

Dividir a Godot en diferentes "anillos" brinda la oportunidad de una gestión más detallada de las relaciones públicas y las funciones, y puede dar más tiempo a @reduz y a otros desarrolladores muy técnicos para que se centren en cosas técnicas extremas , mientras que otro equipo administraría el anillo de extensión. teniendo más en cuenta los comentarios de los usuarios y la usabilidad en lugar de tener que enfrentar la hinchazón del motor, ya que el "anillo de extensión" se hincharía a pedido.

Acerca de la herencia multilenguaje

A medida que Godot crece, la tienda de activos puede convertirse fácilmente en un desastre en llamas. La división estricta entre el lenguaje de secuencias de comandos puede literalmente destruir cualquier intento que la gente haga para vender activos y hacer crecer un ecosistema en la tienda de activos, matando muchas oportunidades para que los fabricantes de herramientas independientes fabriquen y vendan herramientas para Godot.
Los puentes lingüísticos deben ser más completos si queremos algún cambio para desarrollar un ecosistema vivo.
Por ahora, la herencia entre idiomas me parece genial, pero no soy lo suficientemente técnico como para decir nada sobre este asunto. Solo quiero señalar un problema que probablemente se presentará pronto, especialmente porque hay una gran comunidad alrededor de C#.

Nota sobre la usabilidad

He estado usando Godot durante casi un año, y últimamente siento que sucede que las personas que deciden sobre las funciones no usan el motor para nada más grande que pequeñas demostraciones. @LikeLakers2 señaló un problema que creo que comparten algunos de los usuarios que no están muy involucrados en el equipo central de desarrollo.

Creo que lo que se considera hinchado es un tema trivial en el esquema general de las cosas, no es como si la decisión que tomamos ahora sea lo que tendremos que cumplir durante toda la vida de Godot. Ser de código abierto nos permite hacer cambios cuando queramos, el único problema es que cuanto más esperemos, más pesada será la decisión de cambiar.

Ahora eso también es una discusión para otro día. Ahora mismo en el presente los hechos son,

1. Godot es un motor de juego compacto, rápido y portátil. Y me gusta mucho pero,....
2. El ejecutable de Godot ocupa alrededor de 45-60 MB dependiendo de varios factores. Pero la plantilla de exportación puede tener un tamaño de hasta 300 MB. Ahora que es un gran golpe para el primer punto.
3. Godot tiene muchas funciones increíbles que lo convierten en un placer para los principiantes, como seguimiento de cámara, Parallax BG y vehículos, esta es una gran ventaja sobre otros motores de juegos similares. Ya que hace que la creación de juegos sea mucho más simple en Godot. Y convierte a Godot en un hogar para muchos desarrolladores novatos, que no tienen las habilidades para escribir sus propias implementaciones para tales herramientas.

Ahora, ¿qué sucederá si eliminamos funciones que algunas personas consideran infladas? Bueno, el motor seguramente será más compacto, pero ¿es necesario? No veo ningún problema conmigo mismo descargando un motor de 100 MB si satisface mejor mis necesidades. Pero, ¿qué pasa con la exportación? ¿Un motor de 100 MB no exportará juegos más grandes?

Probablemente, sí, pero en un mundo donde las computadoras de escritorio no parecen usar nada menos que 256BG SSD + 1TB HDD e incluso los teléfonos tienen espacio a partir de un mínimo de 16GB, todo lo cual es más que probable que aumente , ¿sería eso? ¿MALO?
Quiero decir que no necesitamos eliminar nada todavía, solo necesitamos comenzar a administrar mejor algunas cosas y eso debería ser todo.
Las características deben tener algún tipo de lista de importancia para decidir si se supone que deben estar en el núcleo o no, pero eso no significa que se convierta en una ley, sino más bien en una regla general.

Y para los quisquillosos, podríamos eliminar algunas herramientas extremadamente inutilizadas, pero eso es todo. Las características no inflan un motor a menos que seamos descuidados. E incluso toda la hinchazón en Unity no ha impedido que la gente lo use, ¿verdad?
Y no quiero decir en absoluto que no debamos preocuparnos por la hinchazón, pero tener cuidado y ser paranoico son asuntos completamente diferentes.

En cuanto a la herencia multilingüe, realmente no veo un uso aquí. ¡Claro que deberíamos poder interactuar con scripts de múltiples idiomas pero herencia! Es probable que sea más trabajo del que podría imaginar con beneficios que simplemente no parecen valer la pena.
Mientras que, multi-script podría ser solo la solución para muchos problemas, desde la creación de complementos hasta una mejor modularidad. Aunque esa es mi perspectiva.

Hay algo que decir acerca de limitar la cantidad de tipos de nodos y recursos que vienen en el cuadro. Al guardar los activos menos utilizados en una descarga externa, 1. hace que sea mucho más fácil para las personas nuevas controlar el sistema simplemente "jugando" sin sentirse abrumados por la amplitud de funciones (parálisis de decisión), y 2. no termine creando tanto bagaje heredado si resulta que algunos de los activos de escenarios de casos de uso más limitados terminan teniendo un flujo de trabajo que no es tan bueno como algo que viene después con una API diferente.

Cuando esto último sucede con los integrados, te quedas con ellos. Cuando sucede con los activos descargables, los más populares tienden a convertirse en estándar de facto con el tiempo, pero no tienen su destino entrelazado permanentemente con el de Godot. Eso significa que pueden desvanecerse en la oscuridad sin tener que preocuparse tanto como por romper la compatibilidad central esperada.

El punto de herencia entre idiomas necesita alguna explicación. No solo lo considero una mala idea, sino que ni siquiera veo cómo es remotamente posible.

1. El ejecutable de Godot ocupa alrededor de 45-60 MB dependiendo de varios factores. Pero la plantilla de exportación puede tener un tamaño de hasta 300 MB. Ahora que es un gran golpe para el primer punto.

300 MB las plantillas de exportación? ¿Quieres decir con activos?

@neikeq , la cosa es que si todo su proyecto está en C # pero está usando un nodo personalizado descargado de AssetLibrary, entonces ese Nodo es solo un nodo normal, muy probablemente con solo un GDScript adjunto.

Si desea "extender" el nodo, ¡no puede hacerlo! Supongo que puede agregar un nodo secundario para agregar una nueva funcionalidad, pero de esa manera no es posible anular las cosas.

Implementación

Actualmente, los lenguajes de secuencias de comandos utilizan un patrón muy similar para las llamadas heredadas que podría generalizarse.

https://github.com/godotengine/godot/blob/76875ba145c5745033d0a1c9fda2f4349e2509b3/modules/gdnative/nativescript/nativescript.cpp#L696 -L712

https://github.com/godotengine/godot/blob/76875ba145c5745033d0a1c9fda2f4349e2509b3/modules/gdscript/gdscript.cpp#L638 -L651

https://github.com/godotengine/godot/blob/76875ba145c5745033d0a1c9fda2f4349e2509b3/modules/mono/csharp_script.cpp#L1175 -L1191

El patrón aquí es

Class *c = bottom;
while (c) {
    if (c->has_method(m)) {
        c->call(m);
        break;
    }
    c = c->base;
}

Por lo tanto, comienza en la parte inferior del árbol de herencia del script y luego intenta llamar a los niveles superiores si no se encuentra dicho método.

Si cada script tuviera un Ref<Script> parent_script en lugar de la estructura de herencia específica del idioma, esto podría generalizarse a

if (this_class->has_method(m)) {
    this_class->call(m);
} else {
    // method not declared here, go to base class
    parent_script->call(m);
}

Puede que esto no sea una buena idea después de todo, pero no tener la opción de anular cosas entre idiomas puede ser un problema con el tiempo si presionamos más a AssetLib.

@neikeq Mira esto,

@swarnimarun Esas son plantillas de exportación para todas las plataformas, todos los arcos compatibles, depuración y lanzamiento, su tamaño es completamente irrelevante para la "inflación" del motor. Podemos decidir admitir solo la versión Linux X11 de 64 bits y este archivo tendrá 20 MB...

@akien-mga No tenía la intención de llamarlo, inflado.
Pero un nuevo usuario lo descargará en tamaño completo, no tendrá la experiencia suficiente para saber que puede compilarlo por separado o descargarlo para una plataforma específica.

¿Cómo es irrelevante cuando esto es lo que proporcionamos a los usuarios principiantes?

@akien-mga: el tamaño de las plantillas de exportación es importante ya que su argumento para eliminar nodos fue

implementar cuestiones de tamaño (móvil, html5)

@swarnimarun @Zireael07 Sí, el tamaño de las plantillas de exportación importa individualmente , pero mi punto es que medir el tamaño de un conjunto de plantillas no nos da ninguna indicación. El tamaño de una plantilla (por ejemplo, la plantilla de lanzamiento de wasm, 3,4 MB comprimidos, o el APK de lanzamiento de Android, 23 MB comprimidos con armv7 y x86 libs) es mucho más relevante que "descargar todo lo necesario para desarrollar toma 350 MB" (+ tal vez 10 GB para Visual Studio si necesita construir algo...). Qué importa si qué tamaño tomará un juego mínimo en plataformas donde el tamaño importa (web, móvil).

Aunque creo que el tamaño de implementación es realmente importante, también creo que lo que debe tenerse en cuenta es el tiempo del desarrollador. Por ejemplo, Unreal tiene literalmente cualquier característica que pueda estar buscando, pero el hecho de que haya tantas hace que el proceso de desarrollo sea muy ineficiente porque cada vez que necesita hacer algo con él, primero debe averiguar qué funcionalidad incorporada. necesita usar y luego aprender a usarlo correctamente.

Esto es algo que realmente amo de Godot. Puede codificar su función de inmediato y luego alguien vendrá y le dirá "yo, ¿sabía que teníamos esta cosa incorporada que podría usar?"

El problema cuando un motor tiene demasiadas funciones juntas es que desarrollar con ese motor se convierte en una experiencia muy agotadora. Sí, es bueno tener todas las funciones que necesita, pero es un gran dolor revisarlas todas para descubrir lo que realmente necesita. Eso es hinchazón. Y es por eso que proponemos tener funciones bien integradas bajo demanda.

agregue una gestión de dependencia adecuada con instalaciones de activos en todo el sistema. Mueva los complementos fuera del proyecto en sí con una forma de recuperarlos para modificarlos.

Esto es lo mismo que perder la portabilidad. Mis complementos son parte de mi proyecto, lo necesito en cualquier computadora en la que esté trabajando y necesito la modificación concreta de cada complemento para cada proyecto... No veo ningún beneficio en tener mis complementos almacenados en .local/lo que sea . Esta es una especie de ofuscación de mis proyectos.

El sistema real de res://addons es bueno... gratis para el usuario y portátil alrededor de las computadoras. Si no hay quejas sobre este sistema, ¿es necesario cambiar eso? Hay muchas otras cosas de las que los usuarios realmente se quejan...

@Ranoller , en cualquier momento podrá copiar el complemento en la carpeta de su juego.
De todos modos, en ese caso, su proyecto.godot enumeraría su complemento como una dependencia y se descargaría a su nueva computadora con la versión correcta

¿Descargado? Mis plugins están dentro del proyecto que está dentro del pendrive, y son parte del repositorio git... No entiendo propuesta... Los plugins cambian igual que otro código... Cambio más código de plugins que gamecode, No quiero numerar los complementos por versión y trabajar fuera del proyecto... ¿Cada cambio de código de una línea necesitará cambiar manualmente cada complemento en cada computadora?... Realmente los complementos se sienten como parte del proyecto... Dar complementos desde el repositorio de git es una tontería para mí, pero realmente creo que no entiendo algo sobre eso...

@Ranoller, la idea es mover esos complementos fuera del proyecto que no necesita modificar . Por ejemplo, el InterpolatedCamera será solo un nodo que desea usar tal cual, no cambiar el código del mismo.

Lo mismo podría ser el caso con los complementos solo para editores, como las listas TODO o la integración de git, etc. Esas son cosas que desea usar pero no cambiar.

Esto se parece mucho a un administrador de paquetes y las bibliotecas funcionan en todos los idiomas que no son C y C ++. Tiene un archivo que especifica todas las dependencias y luego el administrador de paquetes buscará esas dependencias. Esto sucede incluso cuando cambia de PC: el administrador de paquetes descargará los paquetes que aún no existen.

Cuando desea modificar algo , trae el código al proyecto. Luego está en tu git y el proyecto con todo su código fuente, etc. Pero ese no es siempre el caso.

Mi propuesta es tener cosas fuera del proyecto por defecto hasta que realmente necesites modificar algo.

Actualmente, muchos activos son en su mayoría plantillas que necesita modificar, tener un sistema de este tipo podría cambiar eso, por lo que las cosas son más generales a través de las API, no a través de la modificación de la fuente.

@karroffel Pero, ¿cómo va a funcionar la herencia entre idiomas en cada idioma? Puede ser fácil para GDScript, que está estrechamente relacionado con el motor, pero es una historia completamente diferente para lenguajes de propósito general como C# u otros lenguajes agregados además de GDNative.
En serio, no puedo ver cómo se podría lograr esto, y mucho menos cómo no podría hacer más mal que bien.

En mi opinión, no es una buena idea modificar el contenido de un complemento del que depende su proyecto. Si se necesita alguna modificación, simplemente copie el contenido fuera de la carpeta de complementos y realice los cambios allí.

EDITAR: o "bifurcar" el complemento 😜

@neikeq Lo que modificas está dentro de tu proyecto. Cuando desea modificar un complemento, se copia dentro de su proyecto y solo se modifica localmente.

@karroffel Es posible que se necesite una idea de un complemento de proyecto y un complemento de editor para evitar confusiones, con una separación clara de los dos.

@QbieShay ¿Qué pasa si hay una actualización que modifica los archivos que modificó?

@neikeq La herencia de scripts no es LA SOLUCIÓN a este problema, solo sería una. Actualmente no existe una buena manera de anular la funcionalidad de un nodo con un script adjunto cuando desea utilizar un lenguaje de programación diferente.

Si tuviéramos una opción para anular los métodos en la API Script , ¡eso también sería bueno! (básicamente definiendo externamente nuevos métodos y anulando los métodos existentes).

@PLyczkowski esa es una sugerencia que también sería útil, pero lo que propongo no se limita a eso, y por una razón.

Tomemos el ejemplo InterpolatedCamera nuevamente. Nunca tocaré el código fuente, solo lo usaré. Tener la fuente en mi proyecto sería un desperdicio. Además, la mayoría de los proyectos que hago son todos en 3D, por lo que probablemente copiaría ese código en todos mis proyectos.

Por otro lado, una integración de git podría ser muy útil para agregar un comportamiento personalizado que es difícil de expresar con ganchos de git, por lo que se desea la personalización.

No hay una línea blanca/negra cuando algo debería estar dentro del proyecto y cuando fuera, editor o no.

@neikeq

¿Qué sucede si hay una actualización que modifica los archivos que modificó?

En ese caso, perdería la información de versión, por lo que ya no podrá actualizar fácilmente. Entonces deberías usar una herramienta como git para esos casos.

la idea es

• fuera del proyecto: más fácil de actualizar, más fácil de tener entre proyectos
• proyecto interno: personalizable, pierde el estado del activo, no hay actualizaciones automáticas

Básicamente, se convierten en archivos normales una vez que los copia en su proyecto.

Al leer esto, puedo decir que evitar la hinchazón y minimizar el tamaño del archivo de los juegos es válido. Sin embargo, permítanme arrojar algunas ideas aquí.

• Godot podría usar un sistema que elimine el juego del código usado por los nodos que no usa (es decir, la mayoría de los nodos 2D con muchos juegos 3D y la mayoría de los nodos 3D con muchos juegos 2D). Esto reducirá la presión de no aceptar nuevos tipos de nodos para mantener bajo el tamaño del archivo del juego. Los usuarios de Unity, por ejemplo, ya están usando algo similar para obtener excelentes resultados.
• Godot quizás podría tener un navegador de activos incorporado que se conecta a una página de complemento en el sitio de Godot. Usted elige los nodos personalizados que desea y se instalarán automáticamente en la ubicación correcta. Los complementos que no se usan se eliminan cuando se empaqueta el juego.
• Quizás incluso, los nodos personalizados populares podrían incluirse con las compilaciones de Godot (como lo hace Blender con los complementos). Los nodos personalizados también deben marcarse, ya que generalmente pueden ser de un nivel superior y, hasta cierto punto, pueden ser más una caja negra que los nodos más genéricos.

Mis 2 centavos de todos modos.

@Ace-Dragón

1. Creo que su primer punto sería genial para tener como una característica de todo el motor. Si su juego exportado no usa un nodo o si ninguno de los nodos que está usando en su proyecto usa un nodo, sería genial si fuera posible excluirlos automáticamente del binario final. Fuera de eso, actualmente solo tiene que confiar en los interruptores y volver a compilar el motor. :-/

2. Esto es básicamente lo que ya es la Biblioteca de activos. El problema es que no tiene ningún concepto de dependencias, coloca cosas directamente en el directorio de su proyecto y no tiene ningún medio para mantener un conjunto determinado de complementos en todo el sistema para cada proyecto que realice.

3. Los nodos personalizados siempre se marcan explícitamente, por lo que no debe preocuparse por eso (tienen un ícono de secuencia de comandos al lado porque usted crea nodos personalizados usando una secuencia de comandos para extenderlo). Debido a que son scripts, nunca se envían con el motor. Serían parte de un complemento de algún tipo, por lo que, en todo caso, es posible que tenga algo más como mi repositorio godot-next que es un repositorio de "extensiones de nodo" para recopilar cosas. Simplemente sería una capacidad más "oficial" más que nada (ese repositorio también podría usar mucho trabajo, jajaja).

Ok, lentamente pero atrapado... Si mantengo los complementos dentro del proyecto, podría trabajar en el código del complemento como en otros scripts sin perder la integración de git con el proyecto actual y sin perder la portabilidad... Pero si quiero convertir cualquiera de los complementos en una herramienta para otros desarrolladores o en una herramienta general para todos mis proyectos, lo comparto en forma de paquete externo que se puede actualizar con el repositorio externo de git de la herramienta y cambiar a otras personas con la biblioteca de activos... Si lo es, para mí está bien ... Si otro desarrollador usa la herramienta y necesita su versión personal, debe almacenarla dentro del proyecto y, en este caso, el complemento no se actualiza (no pierda su propio trabajo )... ¿Está?

@Ranoller Sí, creo que entendiste la esencia de su propuesta.

Algunos comentarios sobre lo que están discutiendo

1) Si este fuera un problema real que necesitaba solución, prefiero soportar múltiples scripts por nodo (que son solo un par de líneas de código), en lugar de la herencia entre idiomas (que es una locura). Todavía no creo que este sea un problema que deba resolverse.

2) No me gusta la idea de un administrador de paquetes y la instalación de complementos en todo el sistema. Creo que es una idea terrible y no se gana nada significativo con esto. He visto lo traumático que es incluso para los desarrolladores de Unity actualizar una versión de un activo en proyectos grandes y ver que todo se rompe y pasan días arreglándolo.

3) No me gusta la idea de la gestión de paquetes en sí. He visto a los usuarios de Unity robar lo que obtienen de la tienda de activos sin fin la gran mayoría de las veces. Con demasiada frecuencia, solo lo usan como base, luego trabajan en él y lo personalizan para sus propios usos, porque el activo que obtienes es solo el 60/70% de la forma en que quieres que esté... o simplemente querían ver cómo se hace y luego hacer lo suyo más tarde.

Creo que nada se gana en la vida real con las propuestas que se discuten, por lo que no planeo agregar mucho a esta discusión yo mismo.

¿Cuánto tamaño del motor podemos reducir si permitimos que las personas exporten sin elementos 3D de una manera simple? Muchos juegos (¿la mitad? ¿más de la mitad?) no requieren funciones 3D, pero aún se encuentran en el mismo binario. Sin embargo, sé que teóricamente se puede volver a compilar con una macro en cada plataforma, con un poco de inversión...
Además, siguiendo esta idea, si los módulos fueran solo bibliotecas dinámicas "internas" que son parte de las distribuciones del motor oficial, agregar más funciones al motor sería un problema menor en el sentido de que se pueden optar por no hacerlo muy fácilmente (solo que ), sin embargo, el uso de bibliotecas dinámicas como esta podría ser un poco restrictivo para algunas plataformas (móviles y HTML5 principalmente). Entonces, para los módulos, entendería que se prefiere GDNative (oh, espera ... tiene los mismos problemas ^^).

@reduz , ¿cómo funcionarían múltiples scripts? ¿Y cómo contribuiría a la extensión del motor? ¿Explicaste tu idea en un número existente? (pregunto porque probablemente sea demasiado explicarlo en este hilo)

agregue una gestión de dependencia adecuada con instalaciones de activos en todo el sistema. Mueva los complementos fuera del proyecto en sí mismo con una forma de recuperarlos para modificarlos

No. Me gustaría que estuvieran en el directorio del proyecto por razones de solidez. Pero tal vez con una forma de actualizar los seleccionados manualmente con el administrador de paquetes, y tal vez con el almacenamiento en caché de todo el sistema.

En cuanto a las preocupaciones sobre la hinchazón, agradecería tener más control sobre _modules_ en su lugar, y esto ya se votó en la encuesta de Patreon de enero de 2018:

Prioridad de hoja de ruta: Más opciones para optar por no compilar partes del motor para crear tamaños binarios más pequeños [Esperado para 3.1]

Es difícil comentar sobre esta propuesta ya que toca una variedad de cosas y la gente está comentando sobre diferentes aspectos y planteando diferentes temas.

En general, creo que la propuesta para el "administrador de dependencias" suena bien en papel, pero creo que la implementación no generará ningún beneficio que simplemente no traerá complementos de proveedores en la carpeta del proyecto. Requerirá incorporar un mecanismo complejo para la gestión de dependencias para resolver 1 caso de "más fácil de instalar". Este proyecto ya tiene más de 3000 números abiertos con un pequeño equipo de colaboradores. En mi opinión, introducir algo tan complejo como la gestión de dependencias es una jugada.

Estoy de acuerdo con @reduz en que el core debe ser minimalista. En mi opinión, todo lo que no pueda clasificarse como "básico" debe incorporarse de forma independiente. Como usuario, espero que Godot sea un _motor_ de juego multiplataforma. Si quiero el _marco del juego_ de godot (vehículos, cámaras interpoladas, terreno, controladores de jugadores, etc.), debería estar disponible como un complemento (¿o módulo?) de primera clase independiente del núcleo. Creo que mejorar la historia de los complementos ayuda con esto, pero un administrador de dependencia completo y un administrador de complementos automatizado parecen estar presionando para obtener un beneficio neto bajo.

Mi último comentario sería tener cuidado con atender a los "principiantes" y abandonar a los usuarios "poderosos". Godot ha llamado la atención de los usuarios más avanzados debido a sus potentes funciones (módulos, gdnative, gdscript, editor, etc.) y flexibilidad. Son este tipo de usuarios los que ponen a prueba a Godot, empujan sus límites, exploran su API y, a menudo, contribuyen al proyecto. Estos son los mismos usuarios que pueden crear enlaces simbólicos a un directorio en su sistema de archivos para reutilizar sus complementos en múltiples proyectos.

Si la idea es eliminar los nodos de nivel superior del núcleo, esos nodos deberían estar disponibles y fáciles de encontrar para descargarlos. Idealmente, podríamos mantenerlos como "oficiales", para que tengan una mejor visibilidad (al igual que los nodos en el motor). Luego, los activos oficiales podrían usarse en demostraciones y tutoriales sin muchos problemas.

La ventaja de subcontratarlos es que se pueden mejorar y lanzar sin tener que esperar una nueva versión del motor. Por lo tanto, los errores podrían corregirse de inmediato, ya que para una extensión es bastante más simple empaquetar una nueva versión.

Supongo que, al final, la gestión de paquetes sería bastante complicada la mayor parte del tiempo. Incluso en el caso de una nueva versión de un nodo personalizado que agregó a su proyecto, actualizarlo podría causar muchos otros problemas (incluso con semver, ya que es posible que haya solucionado un error que ahora está solucionado).

OTOH para algunos complementos del editor, podría tener sentido tenerlos fuera del proyecto y actualizarlos con frecuencia. El complemento de importación My Tiled es un ejemplo. Lo más probable es que no desee que se envíe con el juego y desee tener la última versión que admita más funciones y tenga correcciones de errores.

Esto se aplica aún más a otras extensiones de editor, como administradores de git y rastreadores de tiempo. Es posible que ni siquiera le importe si sus compañeros de equipo tienen el complemento de seguimiento de tiempo o no, no está relacionado con el proyecto. Sin embargo, debe colocar su carpeta addons y habilitarla en la configuración del proyecto, luego tenga cuidado de no comprometerlo con el resto del juego. Esos son probablemente la minoría de los complementos, pero aún tener complementos para todo el sistema que no están vinculados al proyecto tiene un caso de uso real.

Creo que el término medio sería crear un administrador de paquetes como una herramienta externa, no tenerlo integrado en Godot. Ni siquiera necesita ser oficial (aunque podría ser "respaldado"). Si se necesitan algunos cambios en el motor base para admitir esto (como tener complementos globales), entonces no sería un gran problema agregarlos, especialmente si son solo para editores.

Entonces aquellos que piensen que es beneficioso pueden usarlo. Si se generaliza y todos lo usan, tendremos tanto las estadísticas de uso como los comentarios sobre la usabilidad para decidir si integrarlo completamente en el motor base y cómo hacerlo.

Ahora, la herencia de escritura cruzada para mí es un no-no (si eso es posible). Multiscript es un poco extraño, pero reemplazaría efectivamente la herencia de scripts cruzados de una manera más limpia. Aunque plantea algunas preocupaciones, como: ¿cómo llamar a la función de otro script en el mismo objeto? Supongo que esa es otra discusión.

Hacer referencia a los scripts por su nombre OTOH suena muy bien. Idealmente, se podría hacer referencia a todos los recursos por su nombre para que las rutas no sean un problema a resolver si decide cambiar las cosas.

@vnen, el único problema que sigo viendo es la incompatibilidad entre complementos y proyectos. ¿Cómo abordaría ese problema?
Porque si hay una biblioteca de extensión oficial mantenida por Godot, cada nodo se envía en todos los idiomas posibles, o veo que la herencia entre idiomas es la única forma en que podemos mantener la facilidad de uso.

@vnen si hace referencia a todos los activos por nombre, será un desastre conflictivo. Eso es más adecuado para scripts, ya que solo los programadores tienen que crear nombres únicos para sus clases para escribirlos y usarlos (o más raramente, recursos). Para las otras cosas, si nos deshacemos de las rutas, necesitaría esto https://github.com/godotengine/godot/issues/15673 , a menos que también desee que los artistas, diseñadores, etc. tengan que nombrar todos sus activos de forma única (que todavía viene con el tema del cambio de nombre).

@Zylann @vnen El TypeDB que estoy escribiendo debería permitir a las personas registrar opcionalmente un nombre para cualquier activo, en teoría. Actualmente solo lo estoy usando para scripts y planeo hacerlo también para escenas de tipo personalizado, pero también podría modificarlo para que funcione con recursos. Actualmente, la lógica solo tiene un HashMap para secuencias de comandos y escenas, pero tal vez podría generalizar la lógica para manejar cualquier tipo de activo, todo en HashMaps categorizados.

Puedo respetar las preocupaciones de reduz con las cosas de todo el sistema, y ​​esas son ciertamente preocupaciones con complementos que modificarían las ofertas del motor, pero cuando se trata de funciones para el Editor específicamente, como lo describe vnen, definitivamente puedo ver que es útil en una forma relativamente segura. Si las personas están agregando complementos para otorgar al Editor más funciones, esas no son cosas que normalmente abrirán y modificarán. Simplemente lo usarán tal cual, o si hacen modificaciones, probablemente será para promocionar esos cambios para mejorar las herramientas. Después de todo, no los estás adaptando a un juego. Como tal, si es para un complemento como este, creo que deberíamos tener un medio para otorgar fácilmente esas funciones al motor cuando comienza un nuevo proyecto (de alguna manera).

Un posible método que podría facilitar las cosas sin necesidad de un administrador de dependencias sería simplemente no compartir dependencias entre complementos y, en cambio, duplicarlos dentro del proyecto, de esa manera el control de versiones no es un problema. Haría que un proyecto individual fuera potencialmente más grande, pero si se trata de contenido que es relevante para el juego y la gente estará jugando con él de todos modos, como dice reduz, entonces simplemente pueden mover las dependencias. Lo que necesitaríamos en ese caso es una forma para que los complementos declaren QUÉ dependencias de complementos externos tienen y brinden a los usuarios la opción de personalizar dónde buscan ese complemento dependiente. De esa manera, si eligen mover un complemento y hacer que otros complementos lo busquen en la misma ubicación, pueden personalizarlo. Pero luego, de forma predeterminada, todo funcionaría de inmediato al administrar sus propias dependencias. Este caso probablemente también sería más fácil de manejar con toda la propuesta de complementos como subproyectos (#19178).

Esto evitaría que tengamos dependencias globales que requieran un administrador de dependencias (problema número 3 de reduz). Y podríamos combinarlo con una función que permita a los usuarios crear una lista favorita de activos de la Biblioteca de activos que pueden elegir instalar automáticamente en sus proyectos cuando se crea un nuevo proyecto (para que todo se almacene localmente, pero sucede automáticamente y no tienen que salir manualmente, encontrar todos sus complementos preferidos y descargarlos e instalarlos manualmente). Esto solucionaría el problema de usabilidad con el que @karroffel quiere lidiar con respecto a extender fácilmente el motor con activos idénticos al crear un nuevo proyecto.

Para complementos más específicos del editor que no necesitarían ser duplicados, tal vez las personas podrían simplemente marcar esos complementos "favoritos" y tendrían enlaces simbólicos creados para ellos automáticamente, almacenando los complementos en una carpeta de usuario de algún tipo. Entonces, tal vez tenga "Favoritos del editor" y "Favoritos del proyecto" para "Quiero esto en cada proyecto, guárdelo en una ubicación compartida y haga un enlace simbólico" y "Quiero esto en cada proyecto, duplíquelo", respectivamente.

Combine eso con las cosas de TypeDB para nombrar scripts/personalizar tipos personalizados, y creo que solucionaría adecuadamente todos los problemas mencionados, excepto el problema de herencia de scripts entre idiomas/multiscript, que es algo completamente diferente.

Entonces, tal vez tenga "Favoritos del editor" y "Favoritos del proyecto" para "Quiero esto en cada proyecto, guárdelo en una ubicación compartida y haga un enlace simbólico" y "Quiero esto en cada proyecto, duplíquelo", respectivamente.

Tal vez entonces sea más conveniente tener "paquetes" de complementos: creados por el usuario aprobados oficialmente + locales creados por el usuario. Entonces, en lugar de "Favoritos del editor" y "Favoritos del proyecto", tenemos "Disparos en primera persona", "Juego de bloques Voxel" o simplemente "Mis cosas". Más o menos como, por ejemplo, los activos iniciales de Unity, pero no es necesario inflarlos con texturas, etc., los diferentes tipos de caras de mascotas de Godot deberían ser suficientes: D

Esto también funciona como un administrador de paquetes, donde el administrador de paquetes ahora es el paquete de complementos de selección humana.

@starry-abyss Los complementos que la gente crea ahora ya tienen el potencial de ser "paquetes" de otros complementos (el usuario o el desarrollador del complemento puede simplemente moverlos en sí mismos y fusionarlos). El objetivo aquí es tener una diferencia funcional entre las categorías en las que el editor realmente realiza operaciones de mejora de la usabilidad en nombre del usuario para que el usuario no tenga que hacer las cosas manualmente.

En este sentido, ya tenemos la característica de "paquetes de complementos de selección de humanos". El problema es automatizar tareas tediosas y mantenerlas personalizables con una productividad eficiente en todos los casos de uso.

@Zylann

si hace referencia a todos los activos por nombre, será un desastre conflictivo. Eso es más adecuado para scripts, ya que solo los programadores tienen que crear nombres únicos para sus clases para escribirlos y usarlos (o más raramente, recursos).

¿Es tan importante nombrar adecuadamente las cosas? Pero podrían ser UID, no me importa mucho siempre que no dependa de la ruta. Incluso la ruta es como un nombre, ya que los recursos se reasignan a su contraparte importada...

@QbieShay

el único problema que sigo viendo es la incompatibilidad entre complementos y proyectos. ¿Cómo abordaría ese problema?

Si esto es realmente un problema, entonces el script múltiple es probablemente la solución más simple. Se eliminó principalmente debido a la discusión en #8546, pero creo que esto se puede resolver sin mucho esfuerzo.

Creo que el problema de que varios complementos hagan lo mismo es virtual. Ya tenemos un sistema de estrellas en la librería de activos, este sistema es solo eso, un indicador de lo que se usa comúnmente y se prefiere.

Lo que se pasa por alto, pero en mi opinión es una de las razones por las que la gente pide adiciones en el motor central es esto: ¿Quién va a compilar esto para todas las plataformas?

Por supuesto, para un complemento gdscript esto no es un problema, pero para un complemento Cpp es un gran problema.

Si no resolvemos este problema, la discusión sobre lo que estará dentro del motor principal se transformará en qué complemento se marcará como oficial, y al marcar los complementos como oficiales arruinará el sistema estelar, porque la gente va simplemente destacar un complemento porque es solo uno oficial.

Entonces, en mi opinión, primero tenemos que resolver este problema, y ​​no tengo idea de cómo. ¿Es posible, por ejemplo, compilar para todas las plataformas a través de Linux? Si es así, podemos usar algo como Ubuntu Imager: https://www.maketecheasier.com/create-linux-distro/ para crear un entorno de Linux ya configurado para los creadores de complementos y los usuarios de GDNative.

¿Es posible, por ejemplo, compilar para todas las plataformas a través de Linux? Si es así, podemos usar algo como Ubuntu Imager: https://www.maketecheasier.com/create-linux-distro/ para crear un entorno de Linux ya configurado para los creadores de complementos y los usuarios de GDNative.

No (las compilaciones de macOS e iOS solo se pueden compilar realmente desde macOS), y no creo que sea una buena idea obligar a las personas a iniciar un sistema operativo Linux en vivo para poder cargar bibliotecas nativas de GDN a la biblioteca de activos.

Sin embargo, es posible compilar para todas las plataformas utilizando Travis CI y AppVeyor, que puede configurar de forma gratuita en los repositorios públicos de GitHub.

Si no resolvemos este problema, la discusión sobre lo que estará dentro del motor principal se transformará en qué complemento se marcará como oficial, y al marcar los complementos como oficiales arruinará el sistema estelar, porque la gente va simplemente destacar un complemento porque es solo uno oficial.

Bueno, el sistema de estrellas nunca se implementó, por lo que no puedes calificar nada. Para los complementos oficiales, no es que vayamos a elegir uno y marcarlo como oficial, somos nosotros los que los creamos y mantenemos.

Los nodos incorporados para cosas básicas son una de las mejores cosas del editor, si se van a eliminar nodos o recursos importantes, el Administrador de proyectos necesitará plantillas para descargar automáticamente los nodos comunes.

Esta propuesta también tiene el riesgo de encender el motor en otro motor "siempre en línea" y "tienda basura", si se hace, muchas otras cosas necesitarán obtener soporte oficial (corrección de errores) y disponibilidad (actualización de versión).

Y la tienda debe ofrecer paquetes oficiales para uso sin conexión (con compatibilidad con la tienda sin conexión en el editor).

si se hace, muchas otras cosas necesitarán obtener soporte oficial (corrección de errores) y disponibilidad (actualización de versión).

TBH, mantener las cosas en el motor o en la tienda es más o menos lo mismo. Los nodos de vehículos, por ejemplo, tienen pocos informes de errores porque casi nadie los usa, e incluso los errores que se informaron nunca se solucionaron. Considero que subcontratar esos nodos es mucho mejor porque es más fácil hacer que las personas intenten arreglar las cosas sin tener que meterse con la fuente del motor, por lo que hay más contribuyentes potenciales.

Si un nodo del motor tiene un problema, la gente abrirá un informe de error. Pero si se trata de un complemento con código GDScript, es bastante fácil para la persona cambiar el código y probarlo, lo que probablemente contribuirá con la solución a la comunidad. Realmente veo esto como una ganancia. Pero solo si esos nodos externos pueden tener una fácil integración, que no es el caso actualmente. Eso incluye buena visibilidad y documentación integrada.

Y la tienda debe ofrecer paquetes oficiales para uso sin conexión (con compatibilidad con la tienda sin conexión en el editor).

Sí, y también debería ser fácil instalar paquetes fuera de línea.

@reduz

No me gusta la idea de un administrador de paquetes y la instalación de complementos en todo el sistema. Creo que es una idea terrible y no se gana nada significativo con esto. He visto lo traumático que es incluso para los desarrolladores de Unity actualizar una versión de un activo en proyectos grandes y ver que todo se rompe y pasan días arreglándolo.

Está bien, pero ¿por qué ? ¿Cuáles son las limitaciones y los problemas reales que ve en él? Decir "No me gusta" sin decir por qué no va a convencer a la gente de que no es una buena idea; debería dar al menos alguna explicación además de las vagas razones mencionadas.

Está bien, pero ¿por qué? ¿Cuáles son las limitaciones y los problemas reales que ve en él? Decir "No me gusta" sin decir por qué no va a convencer a la gente de que no es una buena idea; debería dar al menos alguna explicación además de las vagas razones mencionadas.

Suponiendo un registro global de "complementos" en el sistema:

• Descargue el complemento v1.3 del sistema de complementos en línea. El complemento está instalado en ~/.godot o lo que no
• La versión se asocia con mi proyecto en ~/my-project en algún tipo de tienda local (archivo, sqlite, etc.)
• Actualicé a v1.4. Ahora mi administrador de complementos debe saber que 1.3 no es utilizado por ningún proyecto y limpiarlo. Entonces, el administrador tiene una funcionalidad adicional para rastrear las dependencias y qué proyectos tienen qué dependencias. Alternativamente, nadie agrega esta funcionalidad, por lo que mi máquina local se contamina con múltiples versiones del mismo complemento
• Decido que quiero mover mi proyecto a ~/big-project/game . Ahora necesito una forma de actualizar la referencia a mi proyecto en el registro de complementos. ¿Cómo puedo hacer eso? ¿Tengo que ejecutar el administrador de complementos por separado? Manager register new_proj_location ?
• Ahora se toma la decisión de almacenar las dependencias localmente al estilo requirements.txt python. Genial, problema resuelto. Excepto que volví a no saber qué proyectos dependen de qué paquetes globales, tengo que escanear el sistema en busca de proyectos de Godot o registrar cada proyecto para evitar acumular versiones.
• Bien, solo soluciono el problema. Limpie manualmente los paquetes muertos de vez en cuando. Así que estoy trabajando en VehicleBodyAddon para mi proyecto usando v1.5. Uf, hace F * M para el cálculo de aceleración, pero quiero hacer F * M * 5. Permítanme modificar rápidamente el código... Vaya, ahí van todos mis otros proyectos que ejecutan ese complemento.
• Permítanme crear un nuevo complemento que dependa del otro complemento. Hmmm, ahora necesito registrar que mi nuevo complemento personalizado depende del existente. Ahora necesito extender el administrador no solo para descargar complementos desde una ubicación remota, sino también para trabajar con rutas locales o repositorios git o algo así.

Asumiendo complementos "vendedores":

• Descargar complemento al directorio de complementos
• La actualización anula el complemento en el directorio

Entonces, el administrador tiene una funcionalidad adicional para rastrear las dependencias y qué proyectos tienen qué dependencias. Alternativamente, nadie agrega esta funcionalidad, por lo que mi máquina local se contamina con múltiples versiones del mismo complemento

Esto es exactamente lo que hace el comando gem de otros ruby, y nadie se queja porque tienen un comando para limpiar versiones antiguas de gemas (término de ruby ​​para complementos) que no tienen otras gemas que dependan de ellas. Además, ¿por qué necesitamos mantener la versión anterior cuando, si estamos actualizando, la nueva versión probablemente será compatible en su mayoría de todos modos? Empuje, el usuario puede obtener la versión anterior nuevamente si su programa depende absolutamente de la versión anterior, lo que probablemente no sucederá.

Decido que quiero mover mi proyecto a ~/big-project/game . Ahora necesito una forma de actualizar la referencia a mi proyecto en el registro de complementos.

No lo haces, de verdad. Estás pensando demasiado en esto cuando el administrador de complementos podría simplemente... usar la lista de proyectos del administrador de proyectos e ignorar cualquier ruta que no exista. Por supuesto, eso es solo si es absolutamente necesario realizar un seguimiento de los proyectos y sus requisitos, lo cual no veo necesario cuando podríamos mantener las últimas versiones de los complementos que hayamos descargado como , literalmente, cualquier otro complemento. gerente por ahí.

Ahora se toma la decisión de almacenar las dependencias localmente al estilo requirements.txt python. Genial, problema resuelto. Excepto que volví a no saber qué proyectos dependen de qué paquetes globales, tengo que escanear el sistema en busca de proyectos de Godot o registrar cada proyecto para evitar acumular versiones.

Un require.txt estilo Python sería una gran opción para este tipo de sistema adicional. De esa manera, si el proyecto realmente necesita una versión anterior (pero, de nuevo, de todos modos, a menudo querrá la última versión), podemos especificar eso, y si el administrador de complementos termina eliminando esa versión anterior, puede saber para volver a descargarlo más tarde.

Así que estoy trabajando en VehicleBodyAddon para mi proyecto usando v1.5. Uf, hace F * M para el cálculo de aceleración, pero quiero hacer F * M * 5. Permítanme modificar rápidamente el código... Vaya, ahí van todos mis otros proyectos que ejecutan ese complemento.

¿O usar una copia del complemento local para ese proyecto? Si realmente requiere un cambio que solo se aplica a un proyecto, y realmente no desea hacer una copia local del proyecto, simplemente cree un archivo .gd que lo amplíe y realice los cambios, y luego use ese nuevo archivo GD en lugar del del complemento.

Permítanme crear un nuevo complemento que dependa del otro complemento. Hmmm, ahora necesito registrar que mi nuevo complemento personalizado depende del existente. Ahora necesito extender el administrador no solo para descargar complementos desde una ubicación remota, sino también para trabajar con rutas locales o repositorios git o algo así.

Submódulos de Git. Otro requirements.txt (como lo que hace python). O simplemente dígale al usuario que requiere Add-on X. No es tan difícil como parece. La mayoría de los usuarios de Godot no son tontos. Saben lo que significa "Este complemento requiere: Complemento X Core, Complemento Y, Complemento Z".

@rminderhoud Si su recomendación es almacenar una copia de los complementos de un proyecto en cada proyecto según sea necesario (para que solo tenga la versión que necesita y sea libre de modificarla sin causar problemas), entonces tal vez mi sugerencia anterior podría tratar con el núcleo problema relacionado con este problema? Es decir, cree una utilidad dentro de EditorSettings que le permita al usuario especificar qué complementos desea que se instalen automáticamente cuando crea un nuevo proyecto.

Incluso podríamos crear una utilidad similar que permita a las personas formar enlaces duros a una ubicación de usuario: // para almacenar ciertos (especialmente para complementos que agregan funciones de editor). Si el usuario elige hacer eso de manera irresponsable y arruina su proyecto, será su propia decisión. El método predeterminado de simplemente copiar todos los activos durante la creación del proyecto podría ser muy útil.

Agregar un nuevo sistema de complementos no debería ser incompatible con respecto a res://complementos como lo es ahora... Y esto se debe a que:

El sistema real es genial...

Repito:

El sistema real es genial...

No hay quejas previas sobre ese punto.

Llego tarde a esta discusión, aquí hay algunas ideas sobre la propuesta:

• Personalmente, todavía no uso muchos 'activos' y creo que es fácil trabajar con la carpeta de complementos tal como está.
• Entiendo qué haría la herencia de secuencias de comandos en varios idiomas y qué problema resolvería (permitir que un desarrollador de C# se extienda desde una secuencia de comandos GDScript para agregar una funcionalidad personalizada usando C#) (no es que tenga ningún deseo de usarla) pero no estoy seguro qué script múltiple por nodo haría. Oh, entonces, en lugar de que el script C# se extienda desde el script GDScript, ¿sería capaz de llamarlo? ¿Qué guión sería el principal? ¿Cómo cambiaría el código C# lo que hace el script GDScript?
• Puede ser útil permitir que se haga referencia a los scripts por nombre de clase/espacio de nombres (TypeDB). Estoy bien con res://paths , pero es cierto que heredar de algo en complementos hace que los nombres de las rutas sean muy largos. No es un problema importante, pero es bueno tenerlo, probablemente sería necesario (o preferido) para la herencia entre idiomas.

Un diseño más simple para la gestión de activos que sugeriría es

• Tener un archivo dependencies.json (o simplemente guardar los datos en la configuración del proyecto) es útil, solo para saber qué versión del activo descargué y si hay una versión actualizada. Creo que es información necesaria.
• No, no permita que los activos puedan definir dependencias. No creo que los activos de Godot tengan una dependencia tan alta entre sí como los módulos npm. Deje que el desarrollador del activo indique en la documentación si realmente depende de otro activo y permita que el usuario lo instale manualmente. Esto simplificará las cosas y no tendremos que crear otra cosa de validación de dependencia que es código hinchado / más código para mantener.
• No, no guarde activos en una ubicación 'global'. Mantenerlos en la carpeta de complementos del proyecto ya es bueno. Les permite estar comprometidos con el control de código fuente con el proyecto y los hace fáciles de administrar. Incluso npm node_modules guarda los módulos de un proyecto dentro del proyecto.
• Ahora, mejore el navegador de activos para que pueda enumerar cuáles de los activos instalados se han actualizado y permitirle actualizarlos si lo desea.
• Ahora, tiene sentido poder tener complementos 'globales' para esos complementos que son solo mejoras del editor. Entonces, los complementos normales aún van a la carpeta de complementos del proyecto, pero para los complementos relacionados con el editor, tiene la opción de instalarlos globalmente. Esto también mueve ese código fuera de la carpeta de complementos del proyecto para que no entre en el paquete de lanzamiento. (Esto es similar a npm install -g para herramientas de desarrollo)

Así que solo algunas mejoras para ayudar a rastrear los activos actualizados y poder tener complementos del editor instalados globalmente.

Suponiendo que no manejemos las dependencias, creo que podría haber un problema de descubrimiento/facilidad de uso para los usuarios. Digamos que un nuevo usuario quiere probar un complemento o "paquete de activos" que tiene una dependencia. El paquete se muestra en la librería de activos, lo descarga, luego no funciona, probablemente con algún "script interno no se pudo cargar" o algo así. Eso es críptico.

• Cada desarrollador que se atreva a tener al menos una dependencia tendrá que configurar un código repetitivo para mostrarle al usuario que necesita instalar una dependencia (¡incluso si el paquete es solo una demostración para ese complemento!)
• ¿O hacer que el assetlib al menos indique eso?

También +1 para una fácil actualización de los activos, sin necesidad de buscarlos nuevamente en la biblioteca.

Es cierto, sin embargo, una vez que el usuario ve que no funciona, buscará inmediatamente la documentación y verá que necesita instalar los otros activos.

En este punto es sólo un problema imaginado. Y en la mentalidad de los mantenedores de proyectos que he visto, tiene sentido no implementarlo hasta que descubramos que realmente es un problema. Es decir. hay muchos activos que dependen de otros activos y los usuarios tienen muchos problemas con ellos.

Sin embargo, como una solución bien diseñada, estoy de acuerdo en que sería bueno tener y puede fomentar el desarrollo de un ecosistema de activos que se basen en/dependan de otros activos.

Agregue además las dependencias de última hora entre los activos debido a las actualizaciones (lo cual es común en los motores dependientes de activos de terceros), muchas versiones del mismo complemento deben mantenerse en la biblioteca.

@eon-s Entonces, ¿algo así como la sugerencia de @bojidar-bg?

Creo que el tema más importante discutido aquí es sobre el tema de incluir cosas en el motor central versus tenerlas como extensiones o extensiones oficiales.

Personalmente, me gusta mucho la idea de poder personalizar el motor y eliminar todo lo que no estoy usando. [¿Puede alguien indicarme cómo eliminaría todas las cosas en 3D, por ejemplo? ¿Y puedo deshabilitar la compilación de módulos que no uso? ¿Cómo?]

La cuestión es que, cuando alguien propone un nuevo tipo de nodo, por ejemplo. el Spring Arm mencionado o una nueva clase, por ejemplo. una mejor clase RNG, o si se van a eliminar algunos nodos centrales existentes, por ejemplo. el controlador del vehículo... esos son código C++. Si no están incluidos en el núcleo, ¿cómo se agregarán como extensiones? ¿Activos nativos de GDN? Eso sería un montón de dlls y bibliotecas compartidas para administrar/construir.

Como alguien que construye su propia compilación de Godot, en realidad preferiría tener una forma de instalarlos en mi carpeta de compilación de Godot. Por ejemplo, si fueran módulos, simplemente los clonaría en mi carpeta de módulos, o tal vez habría una herramienta que automatiza eso de alguna manera. Podrá seleccionar todos los módulos que desee utilizar de la lista de módulos oficiales, módulos de extensión oficiales y también de los enviados por los usuarios. Luego descárguelos (git clon) y luego puede continuar y construir su Godot personalizado. También podría ver cuáles se han actualizado y actualizarlos e instalar otros nuevos más tarde. (Esto se refiere al código C++).

Por lo tanto, supongo que primero necesitamos una biblioteca de activos mejor y más flexible (instalación de activos, dependencias, control de versiones, etc.) y una integración/extensión de complementos más sencilla (herramientas de edición, nodos personalizados programables, etc.) antes de intentar eliminar funciones del motor. .

Respondiendo a @chanon aquí.

No, no permita que los activos puedan definir dependencias. No creo que los activos de Godot tengan una dependencia tan alta entre sí como los módulos npm.

Pero ¿por qué? En ese momento, ¿por qué no dejar que los activos tengan este archivo de dependencias de todos modos, ya que no dañará nada? La razón por la que muchos módulos npm tienen dependencias es porque les ahorra a todos la molestia y reutiliza el código de otros módulos que el usuario ya podría haber instalado. Lo mismo ocurre con las gemas de Ruby, Python a través pip , incluso los administradores de paquetes en las distribuciones de Linux lo permiten. No veo por qué no deberíamos permitir dependencias en activos solo porque es posible que no se usen con tanta frecuencia.

Es cierto, sin embargo, una vez que el usuario ve que no funciona, buscará inmediatamente la documentación y verá que necesita instalar los otros activos.

No estoy de acuerdo con el sentimiento de esto. Habrá mucha gente que buscará la documentación primero, seguro, pero estoy bastante seguro de que incluso ellos se molestarán por tener que buscar todos y cada uno de los activos necesarios cada vez en la biblioteca de activos. Pero creo que también vale la pena mencionar que siempre hay un grupo de personas que parece que nunca buscan problemas en Google de antemano, y simplemente se quejan con los autores de los activos de que sus activos no funcionan.

Ni siquiera estoy de acuerdo con la idea de eliminar funciones simplemente porque se pueden hacer en GDScript. En pocas palabras, es la antítesis del objetivo de Godot de " nodos para todas sus necesidades " si va a obligar a una gran cantidad de usuarios a descargar o implementar una herramienta/característica/etc. que necesitan.

De hecho, una gran cantidad de nodos se incluyen en el segundo requisito de @reduz para ser incluidos en el motor, simplemente porque "Es difícil hacerlo usted mismo" es completamente arbitrario. Lo que puede ser simple para algunos es difícil para otros.

No creo que tener un repositorio oficial de extensiones vaya en contra de los "nodos para todas tus necesidades". El hecho de que no estén integrados en la descarga del ejecutable no significa que no se proporcionen. Además, la idea es que las necesidades base estén cubiertas y el poder de ampliarlas esté disponible para las necesidades específicas del juego.

Es bueno tener un controlador de personajes FPS listo para usar, pero es inútil para todos los que no hacen un juego FPS. Y al agregar cosas como esa, creas esencialmente todos los juegos que contienen muchas funciones que no necesitan, lo que aumenta el binario final (que es muy importante en los objetivos móviles y web). Debería haber una manera de eliminar las cosas no utilizadas de la exportación final, y proporcionarlas externamente según las necesidades es una forma (al menos parcialmente).

Estoy de acuerdo en que la dificultad es subjetiva. Hacer un nodo de brazo de resorte es fácil solo si ya conoce los fundamentos para implementarlo. De lo contrario, pasará bastante tiempo investigando, lo que anula el propósito de utilizar un motor de funciones completas. La mejor métrica (aunque todavía algo subjetiva) es "cuánto nivel bajo" es la función. Si necesita agregar funciones a los servidores físicos o visuales, es probable que deba proporcionarse en el motor. Si es solo una extensión de un nodo existente, tal vez se pueda subcontratar.

Sigo creyendo que es más beneficioso proporcionar nodos oficiales para descargar y recortar el núcleo. Con esto, podemos:

• Tener un pequeño ejecutable para editor y exportaciones.
• Proporcione más funcionalidad oficialmente, con más ayudantes específicos del juego.
• Actualice y corrija errores en las extensiones sin lanzar una nueva versión del motor. Esto significa que los nodos subcontratados pueden tener un ciclo de lanzamiento mucho más rápido y lanzar un parche tan pronto como se solucione un error.

Pero para eso todavía necesitamos hacer que los complementos sean ciudadanos de clase superior que los scripts de la tierra del usuario. El uso de nodos de extensión debería sentirse como usar los nodos principales, sin dejar de tener claro que no lo son.

Interesante discusión. Muchas buenas propuestas también.

Primero debo decir que aprecio la compacidad del binario final y estoy agradecido de que haya un motor hecho con ese objetivo en mente. Me alegra que la visión central aquí sea combatir activamente la hinchazón. Al menos para mí, prefiero tener a mano solo las herramientas que necesito para el trabajo.

Solo quería transmitir un guiño a algunas de estas ideas interesantes.

Especialmente el que se refiere a que más y más funciones se exportan a algo que toma la forma de módulos o complementos oficiales.

A partir de eso, me imagino que esto es como un núcleo y luego una biblioteca de módulos, con los esenciales instalados de manera predeterminada. Quizás muchos podrían optar por no participar a través de la configuración del editor. (Creo que Zylann estaba mencionando la exclusión de 3D para un juego 2D). Más allá de los valores predeterminados, los otros módulos podrían ubicarse e incluirse fácilmente.

Aunque me pregunto acerca de las dificultades de implementación, porque tendría que considerar qué sucede cuando uno podría querer eliminar un módulo que está activamente en el proyecto. Es posible que deba advertir al usuario que lo elimine de esas escenas/guiones antes de que pueda desactivarse... ¿o permanecerán como elementos desecho en el proyecto, que pueden revivir cuando se vuelva a agregar el módulo?

Probablemente no sea poca cosa de implementar, pero me gusta poder elegir la funcionalidad proporcionada, siempre que sea posible, lo que permite que la exportación del juego tenga solo lo que se necesita. Más control sobre eso suena valioso para mí.

Los otros pensamientos de Vnen sobre tener módulos con alguna clasificación especial entre integrados y los scripts también fueron buenos. Permitiría algunos otros tipos de particiones y comportamientos y opciones del editor sin interferir con las cosas buenas del diseño existente.

Algunos dijeron sí y otros no sobre la idea de hacer que los complementos se parecieran más a Godot, pero pueden imaginar que tal vez sea situacional. También podría imaginar que se hace dividiendo un poco el concepto. Proporcionando ambos.

También me interesaría ver qué se podría hacer con respecto a mantener las herramientas del editor fuera de la compilación final. He trabajado mucho tratando de mantener estas cosas separadas, porque los errores y el comportamiento destinado a las herramientas pueden colarse en el juego en sí. A veces destructivamente si está haciendo algo con la modificación de datos que se guardarán.

Al mismo tiempo, me parece bastante fantástico modificar fácilmente la funcionalidad dentro del editor usando el script de la herramienta, por lo que más atención allí también sería fantástico.

De todos modos, sigan con el buen trabajo de todos.

Solo otra idea loca:

¿Tal vez sería posible de alguna manera convertir automáticamente GDNative C ++ en un módulo (idealmente eliminando las capas indirectas creadas por GDNative)? Entonces podría complacer tanto a los defensores del enfoque de "todo en un ejecutable estático" como a los del enfoque de "eliminar características sin instalar el compilador".

Para aquellos en contra de eliminar los nodos, si los nodos que se eliminan se implementan en GDScript como complementos oficiales, ¿no sería mejor que lo que tenemos actualmente? Porque entonces los principiantes podrían mirar dentro del script para ver cómo funciona.

Me temo que eso dañaría el rendimiento ya que GDScript no es muy rápido.

El viernes 22 de junio de 2018 a las 23:10, Alan North [email protected]
escribió:

Para aquellos en contra de eliminar los nodos, si los nodos que se eliminan son
implementado en GDScript como complementos oficiales, ¿no sería mejor que
que tenemos actualmente? Porque entonces los principiantes podrían alcanzar su punto máximo dentro
el guión para ver cómo funciona.

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

@AlansCodeLog Si es absolutamente necesario eliminarlos y convertirlos en extensiones externas, sería bueno tener al menos una versión de GDScript, para que los usuarios no necesiten volver a compilar el motor (si son los archivos originales de C++) o instalar Mono ( si se convierte a GDNative). Sin embargo, parte de mi respuesta original (consulte la sección sobre un repositorio oficial de extensiones) involucraba mi preocupación de que incluirlas en las extensiones solo crearía este extraño tipo de mercado (a falta de una palabra mejor) si los usuarios dejan de recordar que hay un repositorio de extensiones. que contiene lo que necesitan, independientemente de cuán oficial o actualizada sea la versión oficial. Los nuevos complementos entrarían en la biblioteca de activos que tendrían "Nodo X con función X", "Nodo X con función Y", y así sucesivamente ("Nodo X" que representa el nodo que se convirtió en una extensión), creando un lío de complementos que afirman ayudar con los vehículos pero que no tienen ese nivel o escrutinio que podrían obtener más nodos oficiales.

@LikeLakers2

Pero ¿por qué? En ese momento, ¿por qué no dejar que los activos tengan este archivo de dependencias de todos modos, ya que no dañará nada?

No estoy en contra. Pero como parece que a reduz no le gusta, sugiero hacer una mejora simple como sugerí primero. Vea cómo funciona, luego podría agregar la capacidad para que los activos tengan dependencias más adelante. Solo una sugerencia de un paso a la vez.

Sin embargo, estoy en contra de la idea de instalar complementos del proyecto en una ubicación fuera de la carpeta del proyecto, ya que dificulta la administración. Solo los complementos del editor 'global' deben estar fuera de la carpeta del proyecto.

Después de pensarlo un poco más, en realidad, si se van a eliminar las funciones principales y la gente quiere tener acceso a esas funciones principales [que luego serían extensiones] en todos sus proyectos, entonces tiene sentido poder tener esas extensiones instaladas en una ubicación global con gestión de versiones para ellos. Pero la opción de descargar e instalar la extensión directamente en la carpeta del proyecto también debería permanecer en ese caso. (Nuevamente, es como la opción npm para instalar local o globalmente con -g)

Como dijo eon-s anteriormente, tiene sentido tener un mejor sistema de gestión de activos si las cosas se van a eliminar del motor central y convertirlas en activos. De lo contrario, se perdería la funcionalidad del motor, ya que los usuarios no podrían descubrir fácilmente la funcionalidad eliminada.

Estaba pensando en ese escenario ideal para

• Usuarios nuevos y personas que no compilan el motor: en la página de descarga del motor, tienen la opción de descargar el motor principal y también seleccionar qué extensiones oficiales o recomendadas desean incluir en la descarga del motor. ( Tenga en cuenta que esto no sería posible si las extensiones no se pueden guardar en una carpeta global. Los usuarios tendrían que encontrar extensiones después de crear un proyecto, lo que perjudica la capacidad de descubrimiento. ... Sin embargo, en un mundo ideal [imposible], el sitio web crear una compilación C++ personalizada a partir de extensiones/componentes seleccionados en el acto).
• Personas que compilan el motor: una herramienta que administra las descargas y versiones del código C++ de la extensión y las coloca en el lugar correcto en la carpeta de compilación para que se incluyan en las compilaciones del motor.

Como alguien que compila el motor, me gustaría que mis extensiones fueran módulos en lugar de GDNative (o GDScript más lento). Me estoy imaginando el nivel de modularidad en el que puedo elegir tipos de nodos específicos para incluir o no incluir en mi compilación, o incluso eliminar todas las cosas en 3D.

Si todas las extensiones de C++ van a ser nativas de GDN, eso pone la carga sobre el creador de la extensión de tener que compilar para todas las plataformas, lo que creo que podría disuadir a las personas de configurarlo para extensiones pequeñas y simples que pueden ser útiles, ya que se sentiría excesivo. hacer todo lo necesario para publicarlo, y también desaconseja separar la funcionalidad en muchos módulos pequeños. Tampoco me gusta el hecho de que se agregarán tantos archivos dll/biblioteca compartida al proyecto de salida.

Por otro lado, para las personas que no compilan el motor, GDNative es la única solución para agregar extensiones de C++.

Entonces, como sugirió Starry-Abyss, si GDNative pudiera adaptarse automáticamente a un módulo normal, sería genial.

Bien, cambié mi stand. Me gusta la idea de un motor sin sobredimensiones con capacidades en la misma liga que las potencias de la industria.

Tener todos los nodos adicionales separados permitirá muchas ventajas, especialmente la capacidad de elegir lo que quiere y lo que no.

Estas son algunas de mis sugerencias de cómo abordarlo,

1. Primero, podemos agregar la capacidad a la biblioteca de activos para tener activos que se pueden instalar en partes, en git se pueden separar por etiquetas o ramas.
   Entonces, ahora, si solo quisiera los nodos de funciones 2D, podría descargar solo eso, pero aún tengo un solo lugar para buscar actualizaciones.
2. En segundo lugar, podemos agregar la capacidad de agregar etiquetas a las actualizaciones de activos, como algunas pueden ser actualizaciones principales, algunas características y algunas rupturas de compatibilidad con versiones anteriores.
   El Administrador de activos puede usar esto automáticamente para actualizar complementos y solicitarle actualizaciones sobre el asunto. Como si le dijera que tiene actualizaciones principales esperando, o su próxima actualización va a romper la compatibilidad con versiones anteriores. ¿Quieres actualizar o no?
3. Tercero, para permitir tener múltiples versiones de un activo y luego, cuando una versión se vuelve demasiado antigua, el desarrollador del complemento/activo puede marcarlo como obsoleto, lo que se reflejará cuando abras Godot y te pedirá que elimines la versión anterior o no. .
4. Y por último, la capacidad de los complementos para solicitar otros complementos será como una dependencia, pero solo le dirá que necesita este complemento para ejecutar este complemento y, si no lo tiene, instálelo.
   Y si alguna vez el complemento se da cuenta de que ya no se puede encontrar, solicite volver a agregarlo o simplemente muestre un mensaje de error.

Con este método, no necesitaremos un administrador de dependencias, pero los desarrolladores serían responsables del trabajo. Si un complemento envejece y está usando un activo/complemento desactualizado, ambos desarrolladores pueden hablar y el desarrollador puede decidir qué hacer.
Podría portar su complemento rápidamente. Si es necesario o en algunos casos, el otro complemento puede eliminar incluso la etiqueta obsoleta.

Y como dijo @chanon , tendremos que hacer que los activos se descarguen como globales, que luego se pueden importar al proyecto como lo hizo Unity.
Y se debe permitir un mejor administrador de activos que nuestra implementación actual con mucha flexibilidad en la instalación del proceso de complemento.
Recomiendo tener la capacidad de agregar un complemento como GDNative y Module, lo que pondrá algo de carga en los desarrolladores de complementos, pero creo que esa es la única solución aceptable a menos que algo cambie radicalmente aquí.
Pero aún podemos agregar algunas funciones a GDNative para facilitar la creación de complementos. Como si poder construir para todas las plataformas a la vez sería mucho mejor.

Sobre el problema de la ruptura de dependencias y activos debido a la actualización de complementos,
por qué no (y disculpas si me perdí de alguien que ya sugirió esto)

1. hacer que el servidor mantenga todas las versiones cargadas

2. permitir complementos para especificar una versión específica de un complemento específico

3. trate de usar un sistema de control de versiones sensato para los complementos (Godot parece usar el
   Major.Feature.BugFix numeración de versiones, que me gusta)

4. Y lo más importante, ¿no actualiza automáticamente los complementos? (O al menos permitir que el
   usuario para seleccionar con qué tipo de actualizaciones están de acuerdo, por ejemplo, correcciones de errores y
   actualizaciones de funciones, pero no actualizaciones importantes).

@Two-Tone Entonces, ¿por qué incluso hacer que todo esté libre de hinchazón?

Tenemos esta discusión para hacer que el motor y todo el sistema estén lo más libres posible para que no haya versiones innecesarias volando.

Tiene razón al permitir que los usuarios decidan actualizar, pero las correcciones de errores deberían ser automáticas de forma predeterminada. Porque si tengo cien complementos, no los revisaré uno por uno para ver si hay actualizaciones de corrección de errores.
El resto puede depender del usuario, podemos tener una configuración para deshabilitar si es necesario.

Y la tienda debe ofrecer paquetes oficiales para uso sin conexión (con compatibilidad con la tienda sin conexión en el editor).

Sugeriría un paquete fuera de línea de unas pocas decenas de MB que contengan las demostraciones más importantes y los complementos más importantes que deberían ser muy fáciles de descubrir. Un enlace de fuente más pequeño en la página de descarga oficial, como el de las versiones anteriores de Godot, sería genial.

Probablemente, sí, pero en un mundo donde las computadoras de escritorio no parecen usar nada menos que 256BG SSD + 1TB HDD e incluso los teléfonos tienen espacio a partir de un mínimo de 16GB, todo lo cual es más que probable que aumente, ¿sería eso? ¿MALO?

En el segmento de portátiles portátiles y asequibles, eMMC está vivo y bien y el tamaño de 32 GB (con menos de 10 GB libres) no es tan raro.

Por cierto, en esa clase de computadoras portátiles, creo que el sistema de exportación de Android actual es utilizable, mientras que el planificado (https://github.com/godotengine/godot/issues/18865) no lo es. Entiendo los méritos del nuevo sistema y, en general, probablemente lo habría votado yo mismo (cuando vi el problema, ya no había concurso), pero debemos ser conscientes de que estamos perdiendo un caso de uso importante por el cambio.

@swarnimarun Puede haber un malentendido. Cuando digo "sistema" en ese comentario, me refiero al servidor que sirve los complementos, no al motor. Lo siento si eso es lo que te hizo tropezar.

Si no, entonces no veo cómo tratar de resolver los problemas de las personas con un sistema de dependencia para complementos es la antítesis de tratar de mantener el motor inflado. Un complemento guardado en un servidor en caso de que alguien lo necesite no contribuye a la sobrecarga ni a los gastos generales de mantenimiento y la mayoría son tan pequeños que el costo de almacenarlos no debería ser tan alto.

@ Two-Tone Sí, pensé que te referías a la computadora. Pero en el servidor está bien y ya se puede hacer, ya que Github permite hash que se pueden guardar incluso después de que se hayan realizado cambios, por lo que en el sistema actual, incluso después de actualizar el repositorio, debe actualizar el hash en la página de activos.

No solo github, incluso gitlab y otros también lo permiten. Si hay otros. Git admite que los hashes se guarden como ID de compromiso y, por lo tanto, las cosas se hacen de la manera en que se hacen.

Solo mis pocos centavos, bastante seguro de que la mayor parte de esto se ha dicho antes, así que dudo que esté aportando algo nuevo.

No creo en hacer las cosas como complementos por hacer las cosas como complementos. Entiendo el problema del tamaño, pero ya no vivimos en los años 80. Estamos hablando de que el motor sea de 50 Mb o 55 Mb, no de que el motor sea de 50 Mb o 500 Mb, el aumento de tamaño adicional de la función que se moverá a un complemento es insignificante en comparación con el tamaño de los activos de cualquier juego serio. Si el precio que pagamos es una integración más problemática, no vale la pena.

Hay muchos lugares donde los complementos tienen más sentido y con la maduración de la arquitectura como GDNative, definitivamente deberíamos hacer la pregunta "¿es mejor ser un complemento?" y, en muchos casos, diría que la respuesta es sí. Una cosa que me gusta de los complementos es que te permite, como desarrollador, más libertad en muchos aspectos. Pero también hay límites.

Mi experiencia de realidad virtual elude algunos de estos. Hay una razón por la que está tardando más de lo que me gustaría ponerlo en funcionamiento en el móvil. Debido a las demandas, especialmente en dispositivos móviles, de configurar las pantallas de varias maneras, debe cambiar la forma en que funciona el núcleo y resulta difícil capturarlo en un complemento.
OpenVR y OpenHMD hasta ahora han sido los más fáciles. Oculus He pasado por una solución alternativa que está mal vista, pero estoy contento con ella.
ARKit tiene que estar en el núcleo, no se puede resolver como un módulo, al menos no en nuestra estructura actual (Apple ni siquiera permite bibliotecas dinámicas en iOS, por lo que también existe).
GearVR y Daydream realmente necesitan estar en el núcleo, algo imposible para GearVR debido a que utiliza bibliotecas propietarias.
Hololens/Microsoft MR Voy por el camino de ver si puedo hacer de esta una opción de plataforma, Microsoft los ve de esa manera porque se supone que las aplicaciones se ejecutan entre los dos y están instaladas en Hololens como una aplicación holográfica únicamente.

Ahora AR y VR son funcionalidades de nicho que muy pocas personas usarán, por lo que son el tipo de cosas que deberían permanecer fuera del núcleo si es posible y estoy furiosamente de acuerdo con ese punto de vista. Pero no puedo decir lo mismo de otras cosas.

Vi la carrocería del vehículo mencionada en alguna parte, ¿en serio? ¿El kilobyte de código que ahorra al ponerlo en un complemento? La física es el tipo de cosas que creo que deberían ser totalmente compatibles con el núcleo en mi humilde opinión. Prefiero ver un conjunto completo de objetos físicos completamente integrados dentro del núcleo y luego tener que buscarlos en los complementos. Si bien un enfoque de interfaz similar a ARVRInterface que escribimos en GDNative probablemente crearía una integración sólida, sigo sintiendo que estamos haciendo la vida innecesariamente difícil.

En contraste con, digamos, los componentes del editor de terreno, ahora hay algo que veo como ideal para estar basado en complementos. Hay varias formas diferentes de abordar los terrenos según el tipo de juego que desee hacer, por lo que tener la opción de elegir entre diferentes complementos tiene sentido, y poder desarrollarlos independientemente del desarrollo en el núcleo, es aún más una razón.

Para resumir, donde los complementos tienen sentido, admita complementos, pero no se exceda.

Los nodos que pueden valer la pena convertir en complementos son los nodos de control que están hechos por nodos de control (los compuestos), dejando solo nodos simples para construir otros.

Los nodos con lógica compleja como Vehículo o incluso simples pero útiles como los de Posición, son buenos en el núcleo.

En mi opinión, ninguno de estos debe quitarse del motor. Nodos de control, nodos de física (como Vehículo) e incluso soporte de Terreno actualmente no existente:

Uso Godot porque es una aplicación integrada bastante autónoma.
Si en el futuro necesito descargar Godot, y luego buscar Vehículo, Nodos de control, Soporte de terreno, un editor de sombreado, un complemento Navmesh decente y más y más, usando el complemento actual y el sistema AssetLib , no gracias.

Si vamos por este camino, tanto la infraestructura de complementos como AssetLib necesitan una revisión de usabilidad.

Y, por cierto, me molesta mucho menos el gran tamaño de instalación de UE4 que si no viniera con soporte incorporado para vehículos, terreno o interfaz de usuario, que tiene, todo.

No estoy seguro de cuánto de esto ya se ha dicho, hilos grandes como este pueden ser difíciles de seguir, pero de todos modos:

Creo que deberíamos centrarnos en la mejor experiencia lista para usar . Tener que acceder a la librería de activos, incluso para los complementos "respaldados oficialmente", es bastante difícil de manejar.

El tamaño de exportación no debería empeorar la usabilidad del motor, en mi opinión. Si necesitamos reducir el tamaño de la exportación, cree alguna función para desactivar secciones del motor, como 3D en la exportación. Sobre todo porque personalmente no valoro plataformas como la móvil y sobre todo la web, y me duele ver el motor frenado por ellas en discusiones como esta. (Puedo ver la demanda de ellos, no me malinterpreten, aunque jodan la web)

Demonios, si estamos preocupados por el tamaño de descarga del editor , entonces debería haber descargas separadas del editor "baterías incluidas" y "mínimas". La forma en que se implementa la separación está sujeta a debate, pero debe estar bien integrada, pase lo que pase.

No he leído toda la discusión a fondo, pero me gustaría reajustarla un poco: no nos preocupa el tamaño. Claro, mantener el tamaño de exportación pequeño en algunas plataformas es importante, pero no es un factor decisivo cuando se implementan funciones en el motor. Como se mencionó, si algunas funciones deben condicionarse para permitir tamaños de exportación pequeños, es trivial. El tamaño de descarga para el motor en sí no importa.

Ahora que está resuelto, los principales factores que nos alientan a considerar mantener algunas cosas ("algunas" por determinar) fuera del motor son:

• Deuda técnica. Todo el código necesita ser mantenido. Un VehicleBody roto como el que tenemos desde 2014 no es particularmente útil, ya que no es lo suficientemente bueno para los juegos reales. Recientemente se mejoró usando Bullet, por lo que está mejorando, pero durante los últimos 4 años fue efectivamente un código muerto y una carga de mantenimiento innecesaria.
• Universalidad: Godot es un motor que te permite hacer cualquier tipo de juego, y las funciones que ofrece deberían permitirte hacer cualquier tipo de juego. No significa que deba ser exclusivo (no necesitas 2D y 3D al mismo tiempo en la mayoría de los juegos), pero las funciones deben satisfacer las necesidades comunes de la mayoría de los usuarios. Lo que significa que las funciones que proporcionamos deben ser de bajo nivel, y que las funciones de alto nivel específicas del juego se proporcionan la mayoría de las veces de forma externa.
• Flexibilidad: tener características de alto nivel mantenidas fuera del núcleo permite un proceso de iteración mucho más rápido para mejorarlas, bifurcarlas si es necesario, etc.

Si vamos por este camino, tanto la infraestructura de complementos como AssetLib necesitan una revisión de usabilidad.

Bueno, esa es la razón de ser de este tema, ¿no? :) El punto es que necesitamos una revisión de usabilidad para permitir un mejor flujo de trabajo en lugar de agrupar todos los casos de esquina en el motor central.

Bueno... si alguien necesita ideas para iniciar las funciones externas además del llamado VehicleBody, quiero recordar algunos nodos y clases perdidos de Godot 2 a 3: ParticlesAttractor2D (nodo) y EventStreamChibi (esta clase es perfecta para un activo externo ), sé que el atractor de partículas es incompatible con el sistema de partículas actual, pero... ¿Qué hay de recuperar la funcionalidad perdida de Godot en forma de activo externo (Ej, el antiguo sistema de partículas coexistiendo con el nuevo...). Tal vez alguien quiera mantener ese código en repositorios separados...

Los nuevos sistemas de @Ranoller siempre eliminan cosas viejas, es inevitable.
Se supone que las partículas de la CPU volverán con GLES2 (porque no es compatible con las de la CPU), pero tener atractores en la CPU pero no en la GPU no será bueno.
EventStreamChibi era un módulo, supongo que el nuevo sistema de audio puede brindar un mejor soporte para los archivos de seguimiento si se vuelve más flexible.

No creo que, incluso si nos preocupamos por la mantenibilidad, debamos separar las cosas todavía.
Podríamos pedirle a la gente que ayude con las cosas que están envejeciendo al publicarlas en un hilo especial y luego las personas pueden actualizar las funciones.
Con el tremendo crecimiento en la base de usuarios de Godot, estoy seguro de que encontraremos muchos muchachos dispuestos a actualizar las cosas y trabajar en las cosas que se vuelven viejas o en las características esenciales que faltan en partes del motor, por ejemplo, más articulaciones.

Si cree que es más fácil hacer que las personas trabajen en archivos de código separados, entonces está mal, la mayoría simplemente no sabrá acerca de esos archivos, ya que nunca obtendrá la misma exposición, el administrador de activos necesita funcionar, sí, pero tener funciones como complementos no funciona bien .
He visto a algunas personas cambiar de Unity a Godot porque está muy bien integrado y no ofrece funciones esenciales como complementos.
Y Unity se dio cuenta de que comenzó a trabajar para hacer que las cosas estuvieran más integradas y agregó los desarrolladores complementarios al equipo de desarrollo de Unity.

Si necesitamos descargar un motor de 30 MB y luego perder el tiempo descargando funciones separadas como complementos que podría olvidar agregar a mi proyecto, es posible que no los use en primer lugar. Lo cual es un problema para un principiante.

En cuanto a la deuda técnica, este es un problema con el que todo proyecto (FOSS o comercial) eventualmente tiene que lidiar. La verdad es que algunos desarrolladores finalmente se van y un área deja de recibir mucha atención (por lo que debe ponerse en modo de "mantenimiento" hasta que alguien esté interesado). Como mencioné, esto incluso sucede con las grandes aplicaciones comerciales. por lo que inevitablemente sucederá con Godot, sin importar cuánto recorte el motor.

La mejor solución en esa área es simplemente fomentar una escena de desarrollo que aliente a las personas a comenzar a contribuir a la fuente (y la escena de Godot ha estado haciendo un buen trabajo al observar todo el desarrollo voluntario, pero debe mantenerse durante cosas como asegurarse de que un colaborador de parches no espere demasiado para ver una revisión). Sin embargo, la eliminación de funciones porque el desarrollador se fue debe evitarse si es posible (porque una lista de funciones que fluctúe constantemente sería una excelente manera de convencer a las personas de que no usen Godot en absoluto). Más bien, la eliminación de características debería ocurrir principalmente porque está siendo reemplazada por algo mejor.

Sin embargo, la eliminación de funciones porque el desarrollador se fue debe evitarse si es posible (porque una lista de funciones que fluctúe constantemente sería una excelente manera de convencer a las personas de que no usen Godot en absoluto). Más bien, la eliminación de características debería ocurrir principalmente porque está siendo reemplazada por algo mejor.

Una vez más, la discusión va en la dirección equivocada, así que intentaré volver a encaminarla por el camino correcto. El tema no se trata tanto de eliminar cosas, sino de evitar que se agreguen cosas nuevas que podríamos terminar queriendo eliminar. Porque agregar cosas es muy fácil, pero no podemos eliminarlas sin romper la compatibilidad.

A medida que Godot crece, más y más colaboradores nuevos vienen con adiciones que pueden no encajar con la arquitectura o el diseño que queremos que siga el motor. Revisar todos esos cambios lleva mucho tiempo, y más aún decidir si se ajustan a lo que queremos. La fusión de estas nuevas características por parte de los nuevos contribuyentes dará como resultado un código que los mantenedores del motor no conocen bien o que pueden no aprobar por completo eventualmente, y es posible que los contribuyentes originales a menudo no se queden para refactorizarlo y asegurarse de que coincida con lo que queremos (ver por ejemplo, el nodo Tween, que es una gran característica pero con un diseño deficiente, y el autor original ya no existe, por lo que depende de nosotros repensarlo y reescribirlo, rompiendo la compatibilidad en el camino).

Entonces, el punto central de la propuesta de @reduz es que el número cada vez mayor de características que los nuevos contribuyentes querrán poner en el motor central sería, la mayoría de las veces, más adecuado como activos en la biblioteca de activos. El objetivo de este problema aquí es cómo garantizar que este flujo de trabajo sea lo más fluido posible.

No estamos tratando de reducir el código base de Godot, estamos pensando en cómo protegernos de que explote y se salga de control. (Porque los contribuyentes de una sola vez con un gran PR son mucho más frecuentes que los mantenedores del motor con un conocimiento profundo de la base de código completa y la visión que tenemos para el futuro del motor).

Entonces, el punto central de la propuesta de @reduz es que el número cada vez mayor de características que los nuevos contribuyentes querrán poner en el motor central sería, la mayoría de las veces, más adecuado como activos en la biblioteca de activos. El objetivo de este problema aquí es cómo garantizar que este flujo de trabajo sea lo más fluido posible.

Tengo que preguntar, ¿qué hará esto al convertirlos en activos en la biblioteca de activos, excepto hacer retroceder el problema un paso? Pasará de un código incluido con Godot que ya no se mantiene, a un código en un activo de Godot que ya no se mantiene. De cualquier manera, el contribuyente original probablemente dejará de mantenerlo en algún momento y eventualmente se romperá nuevamente.

@LikeLakers2 Bueno, el propósito es crear una vía fluida para que se agreguen nuevas contribuciones al motor (ya que la mayoría de las que están más relacionadas con los activos se rechazan por ahora). Si algún aspecto del motor no se mantiene, entonces no debería incluirse con el motor en primer lugar, ya que en ese momento es puramente inflado. Las cosas de esa naturaleza son especialmente adecuadas como complementos incluidos/actualizados externamente.

Si en el futuro necesito descargar Godot, y luego buscar Vehículo, Nodos de control, Soporte de terreno, un editor de sombreado, un complemento Navmesh decente y más y más, usando el complemento actual y el sistema AssetLib, no gracias.

Exactamente. Los complementos/AssetLib en general no funcionan bien ahora para esto, por lo que la conversación tiende a desviarse hacia ellos. No creo que nadie quiera sacar cosas en este momento, pero como se ha mencionado, el punto es no agregar demasiadas cosas nuevas.

Tengo que preguntar, ¿qué hará esto al convertirlos en activos en la biblioteca de activos, excepto hacer retroceder el problema un paso? Pasará de un código incluido con Godot que ya no se mantiene, a un código en un activo de Godot que ya no se mantiene. De cualquier manera, el contribuyente original probablemente dejará de mantenerlo en algún momento y eventualmente se romperá nuevamente.

Bueno, supongo que sería más fácil si pudieran administrarse más separados del motor. Blender hace algo como esto. Tienen complementos "oficiales" (no realmente oficiales, solo incluidos previamente), pero su código se guarda en un submódulo git separado, y cuando las personas que los enviaron no los mantienen (creo que tiene que volver a enviar con cada gran lanzamiento), se eliminan. Aunque, sinceramente, no me gusta mucho este enfoque, desearía que tuvieran un navegador de activos integrado para el 90 % de las cosas y que simplemente integraran el resto (cosas como exportadores).

Sin embargo, creo que la idea es que el motor tendría solo los componentes básicos incluidos, luego cosas como el nodo del vehículo podrían ser complementos oficiales, luego todo lo demás que es grande y podría implementarse de diferentes maneras deberían ser solo complementos regulares. , ¿Correcto?

Lo que no entiendo es cómo se implementarían los complementos oficiales. Pensé que actualmente no podíamos escribir nodos personalizados que pareciera que estaban integrados, ¿verdad? ¿Tenían que tener un script? ¿O es eso posible con un módulo c ++ o algo así (soy un novato c ++ aquí).

Y eventualmente también nos metemos en el problema de cómo tener un complemento que dependa de los nodos oficiales separados. Sin algún tipo de sistema de dependencia suena como un infierno.

Llegué tarde a la fiesta, pero dada la escala de mi proyecto actual, me encontré desarrollando _muchos_ complementos para Godot 3 y me veo desarrollando muchos más antes de que el proyecto esté terminado. Con cada complemento, trato de desarrollar tantos como puedo de una manera agnóstica del juego y abrirlos bajo la licencia MIT para que otros los usen. No voy a mentir. El sistema de complementos actual realmente no es tan malo en el gran esquema de las cosas... SIN EMBARGO , faltan un par de piezas que lo hacen casi inútil en muchos casos. Sin embargo, antes de llegar a eso, quiero decir un par de cosas sobre las ideas de @karroffel .

Primero, gracias por armar este número. Creo que tener esta discusión es importante, especialmente en el corto plazo. Dicho esto, creo que cada uno de los puntos de discusión que presentó en el OP son en su mayoría ortogonales con solo una superposición tangencial. Creo que podemos iterar mucho en una solución aquí sin tener que abordar todas las preocupaciones de una sola vez.

Esto me lleva a mis reparos _personales_ con el sistema de complementos actual y lo que creo que serían dos muy buenos puntos de partida para un mundo mejor de alguien que realmente desarrolla complementos de forma regular:

El mayor problema con el sistema de complementos actual es la falta de gestión de dependencias.

Esto ya se ha discutido mucho, pero la mayoría de las sugerencias son bastante duras y no son extremadamente compatibles con el sistema actual. Ahora bien, aún no me he familiarizado con el código base del módulo assetlib, pero creo que _debería_ haber una victoria fácil en este departamento. Actualmente, los repositorios de complementos de la tercera parte en Github cumplen con la siguiente estructura de carpetas:

addons/
    addon_name/
        plugin.cfg
        ...other files

Lo que propongo es extender el esquema plugin.cfg y agregar la capacidad de simplemente tener una lista de versiones de dependencia con una opción de hash de confirmación (o nombre de rama/etiqueta) para usar. Algo como lo siguiente funcionaría:

[plugin]
name="foo"
description="foobar"
author="blah"
version="1.0.0"
script="plugin.gd"

[dependency]
name="dep1"
path="github.com/foo/dep1"
hash="7fc2367508c41cfab86eaf7d84e04cd122978fdb"

[dependency]
name="dep2"
path="github.com/foo/dep2"
tag="v3.1.2"

[dependency]
name="dep3"
path="github.com/foo/dep3"
branch="big-refactor"

Luego, cuando la biblioteca de activos va a instalar el activo, primero descarga el proyecto en el directorio de complementos tal como lo hace actualmente, luego descarga cada dependencia (usando el hash correcto o la rama definida) y lo coloca en el directorio de complementos también. . Como primer paso, los conflictos de dependencia pueden ignorarse o dejar que el usuario elija cuál usar. Esta no es una solución _ideal_, pero creo que funcionará en la mayoría de los casos y al menos nos detendrá hasta que se realice una revisión más compleja de la librería de activos. (a menos que a alguien se le ocurra una manera simple de lidiar con los conflictos de dependencia).

Como un ejemplo del mundo real,
Tengo un activo para los árboles de comportamiento de Godot. Parte de este sistema es un nodo Blackboard similar a UE4 para almacenar datos globales o locales de nodo arbitrarios que se compartirán entre nodos. Esto se usa en el sistema BT para compartir el estado entre los nodos de comportamiento. Eso está muy bien, pero actualmente estoy desarrollando un sistema de diálogo y las herramientas que lo acompañan, y parte de este sistema requiere algún tipo de base de datos de variables para usar en las condiciones. También me gustaría reutilizar el componente de pizarra del sistema BT para el sistema de diálogo. De hecho, el componente Blackboard es lo más genérico posible, y los datos globales son un idioma bastante común en el desarrollo de juegos, por lo que incluso por sí solo podría ser un complemento bastante útil, ya que es uno que se vuelve a implementar básicamente en todos los proyectos de todos modos. .

Con un sistema de dependencia adecuado, podría dividir el componente Blackboard en su propio complemento y luego reutilizar este componente en todo el complemento BT, el complemento del sistema de diálogo y cualquier otro uso específico del juego que tenga para él. ¿Parece lo que quiero decir?

La necesidad de nodos multiguión

Este es otro tema candente en este número y, sinceramente, no tengo una muy buena manera de abordar esto sin cambiar la ideología fundamental de cómo se pretende usar Godot. Esto puede o no estar bien, pero sí... De todos modos, esto no es tanto un problema para los _autores_ del complemento como lo es para los _usuarios_ del complemento (aunque a menudo la misma persona;).

Al final, si podemos resolver estas dos cosas, creo que estaremos en un 90 %. El otro 10% no es tan importante en mi opinión y probablemente debería abordarse desde la perspectiva de la revisión de la arquitectura fundamental de los activos, que en mi opinión, puede esperar después de freír peces mucho más grandes.

Si no hay objeciones, probablemente intentaré implementar mi sugerencia con respecto a la gestión de dependencias en el código de assetlib en los próximos días.

la gestión de dependencias me parece genial. :smiley:

Lo único con lo que no estoy de acuerdo es con tener la versión de la dependencia
ser un listado opcional. Eso causará los problemas que Reduz mencionó que
sucede con el sistema de complemento de otro motor.

a menos que alguien pueda idear una manera simple de lidiar con los conflictos de dependencia de la parte superior de su cabeza

Creo que la solución para eso dependería de cómo un complemento llame al código desde
un complemento diferente. Si lo configuramos para que los scripts del complemento hagan
extends "dep2/folder/script.gd" , en la instalación podríamos simplemente cambiar dep2
a dep2-v3.1.2 . Para hashes podríamos usar los primeros 5 dígitos (a menos que
queremos carpetas con nombres que tengan al menos 42 caracteres). A las 5
dígitos, la probabilidad de colisión es increíblemente pequeña.

Estoy un poco cansado en este momento, así que podría estar perdiéndome algo, pero no veo
cualquier problema.

@jonbonazza si lo hace, intente no codificar el uso de Git en él. Aunque parece garantizado por aquí, algunas personas podrían preferir otros sistemas VCS (o no usar VCS en absoluto), por lo que tal vez debería ser un detalle que se maneje en el lado de la librería de activos.
Además, me pregunto si consideramos hacer algo para que sea más fácil tener complementos como sub-repos VCS en un proyecto. Se mencionó en algún momento pero no recuerdo si hubo un acuerdo.

Sí, creo que solo la identificación del activo y la versión deberían ser suficientes.

Especificar el repositorio/rama/etiqueta/hash de Git puede ser una forma opcional de especificar la dependencia, pero la forma principal debe ser por ID de activo.

No estoy seguro de si la biblioteca de activos tiene identificadores únicos legibles por humanos (slugs). Si no debería. Por ejemplo, los módulos npm tienen un nombre/id de módulo de texto que usa al instalarlos.

La especificación de dependencia entonces tal vez se vería como

[dependency]
asset_id="some_asset"
version="1.0.0"

@ Two-Tone Estaba tratando de no volverme demasiado loco con esto. Solo quería algo simple para detenernos hasta que se decida un mejor enfoque.

@Zylann Probablemente usaría el mismo enfoque que se usa actualmente en la librería de activos: descargar y extraer el archivo zip de github.

@chanon the asset lib funciona con github directamente, por lo que la única identificación que tenemos para las versiones es hash, rama y etiqueta.

¿Qué parte es demasiado loca? Tener versiones de dependencia obligatorias o mi solución.
por conflictos de dependencia? Uno es estándar en la mayoría de los lugares que tienen
gestión de dependencias y el otro es una simple edición de texto y carpeta
llamado. No creo que ninguna de esas cosas sea una locura.

El martes 3 de julio de 2018 a las 11:23 a. m., Jon Bonazza [email protected] escribió:

@Two-Tone https://github.com/Two-Tone Estaba tratando de no volverme demasiado loco
con este. Solo quería algo simple que nos sostuviera hasta que un mejor
se decide el enfoque.

@Zylann https://github.com/Zylann Probablemente usaría el mismo enfoque
que se usa actualmente en la librería de activos: descargar y extraer el zip
archivo de github.

@chanon https://github.com/chanon la biblioteca de activos funciona con github
directamente, por lo que la única identificación que tenemos para las versiones es hash de confirmación,
rama y etiqueta.

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

@Two-Tone lo siento, pero "demasiado loco" quise decir "demasiado complicado" ya que se supone que esto es una solución rápida para detenernos. Estoy de acuerdo en que, a largo plazo, es necesaria una resolución de conflictos adecuada, pero esperaba que pudiéramos salirnos con la nuestra en el ínterin.

Otra opción es simplemente renunciar a la librería de activos por completo y clonar las dependencias directamente en el proyecto, aunque dado que la estructura actual del proyecto del complemento de facto está enraizada en el directorio addons , esto realmente no funcionará. Necesitaríamos que la raíz del proyecto sea un nivel más profundo (es decir, excluyendo el directorio de complementos y arraigado en el nombre del complemento). Sinceramente, creo que este sería un cambio bienvenido de todos modos, ya que entonces podría usar submódulos de git para las dependencias.

@jonbonazza Ya veo. Su solución es algo que podría implementarse y funcionar de inmediato sin necesidad de modificar la biblioteca de activos. Entonces estoy de acuerdo en que es un buen primer paso. (No es que sea un mantenedor central que tenga alguna autoridad... solo que creo que es un buen primer paso).

Creo que si la base de datos de la Biblioteca de activos tiene un identificador de texto (slug) más información de versión agregada, eso podría agregarse como mi ejemplo anterior.

podrías usar submódulos de git para las dependencias.

@jonbonazza y ahí es donde surge nuevamente mi última pregunta, ya que no parece posible usar submódulos con una reproducción de complemento porque ese repositorio necesitaría incluir la jerarquía de archivos completa para que sea adecuado para la descarga, forzando .git carpetas para estar en la misma ubicación... pero incluso si eso fuera una cosa, recuerda que obligaría a las personas a proporcionar todas sus cosas a través de Git.

@chanon exactamente. Solo requeriría una pequeña cantidad de código adicional en un par de archivos. Honestamente, probablemente se podría desarrollar un complemento que podría hacer esto por usted en lugar de incorporarlo a la biblioteca de activos.

@Zylann sí, eso es a lo que me refería en mi comentario sobre los submódulos. Actualmente no es posible debido a las restricciones actuales en la estructura del proyecto, pero cambiar la biblioteca de activos para que sea más flexible en este sentido sería trivial.

EDITAR: También podría hacerse de una manera compatible con versiones anteriores.

De hecho, hice una propuesta con respecto a la estructura del proyecto hace un tiempo. Esa es en realidad mi principal queja sobre cómo funcionan los complementos ahora. No hay una buena manera de empaquetarlos. Ver #18131. Eso realmente debería cambiarse primero, en mi opinión, antes que nada, y cuanto antes mejor, para que haya menos personas que tengan que cambiar sus complementos.

¿Qué tiene de complicado? Uno es un requisito que se puede hacer cumplir con
una simple verificación y la otra es una simple coincidencia y reemplazo o
agregar/anteponer. Esto es más simple que agregar soporte de dependencia.

El martes 3 de julio de 2018 a las 12:11 p. m., Jon Bonazza [email protected] escribió:

@Two-Tone https://github.com/Two-Tone lo siento, pero "demasiado loco" quise decir
"demasiado complicado" ya que se supone que esto es una solución rápida para detenernos.
Estoy de acuerdo en que, a largo plazo, es necesaria una resolución adecuada de los conflictos, pero
Esperaba que pudiéramos salirnos con la nuestra mientras tanto.

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

@Two-Tone no puede simplemente cambiar el nombre de las carpetas porque los scripts en el código del complemento a menudo usan la ruta del complemento directamente. P.ej

extends "res://addons/foo/bar.gd"

@jonbonazza , agregaría, no son solo los scripts los que hacen eso, sino cualquier recurso que haga referencia a otro.

Luego, haga que la estructura de carpetas adicionales sea como dije pero obligatoria, luego en
tiempo de instalación solo use las funciones de buscar y reemplazar que la clase String
tiene en cada script para buscar

'extiende " res://nombre_complemento/ '

Y reemplazarlo con

'extiende " res://addonname-versionnumber/ '

Estos no son problemas difíciles en el código. Son realmente simples gracias a c++.
Estos son en su mayoría solo problemas de usuario para garantizar que estos problemas se solucionen
tenemos que ordenar algunas cosas. Si cargan un complemento y los usuarios encuentran que
está completamente roto porque el desarrollador no siguió estos increíblemente
reglas simples, entonces eso está en el desarrollador del complemento.

Y vamos a tener que imponer reglas para empezar, así que también podríamos
incluir estos o alguna forma de estos para asegurarnos de que lo estamos haciendo bien
desde el principio.

El miércoles 4 de julio de 2018 a las 12:48 p. m., Marc [email protected] escribió:

@jonbonazza https://github.com/jonbonazza Agregaría, no es solo
scripts que hacen eso, pero cualquier activo que haga referencia a otro.

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

Supongo que si el complemento rompe la compatibilidad después de una actualización, deberían proporcionar respaldos de desuso o hacer lo que dice @Two-Tone, rompiendo intencionalmente la ruta cambiando el nombre del complemento o una subcarpeta del mismo (eso sería el peor de los casos porque no es una situación agradable). Así lo hace el propio motor, y lo hacen otros. Escribir un complemento viene con la mentalidad completamente diferente de que otras personas/complementos que no conoces dependerán de él.

Lo que esto resuelve no es un problema de dependencia sino una solución a los conflictos de dependencia. Un complemento puede depender de la versión 1 de un complemento diferente y otro puede depender de la versión 2, sin esto o algo similar, tendríamos conflictos o tendríamos que restringir que el usuario pueda usar complementos que tienen dependencias conflictivas.

Y la solución para evitar que las actualizaciones rompan la compatibilidad es hacer cumplir que cada actualización debe tener un número de versión único. Sin embargo, eso podría comenzar a caer en la categoría "demasiado complejo", ya que tendría que analizar plugin.cfg y luego preguntarle al servidor de activos si ya existe un complemento con ese nombre y número de versión. Si lo hay, lanza un error. Si no, todo debería estar bien.

Y no estoy seguro si está hablando de secuencias de comandos en el complemento o secuencias de comandos que escribe el usuario, pero de cualquier manera estoy de acuerdo en que es un poco difícil de manejar, pero no debería ser un problema tan difícil.

La única solución que se me ocurre es extender gdscript para que el usuario pueda especificar en el script cuál es la versión del complemento que está usando, luego, a partir de ese momento, simplemente hacen extends "res://addonname/etc y hacen que el motor mismo maneje usando el camino correcto Eso, sin embargo, definitivamente cae en el tema "demasiado complejo" que mencionó @jonbonazza . Pero a corto plazo se puede omitir.

Hay otros problemas que eventualmente deberán resolverse. Por ejemplo, el usuario debe saber qué dependencias se están instalando, cómo manejar las múltiples carpetas en el navegador del sistema de archivos interno que proviene de resolver el problema del conflicto de dependencias, cómo tratamos los complementos que son una dependencia pero tienen una actualización (¿podemos aplicar la misma configuración que se usa para los complementos instalados manualmente, por ejemplo, la instalación automática de correcciones de errores o solo instalar actualizaciones cuando el complemento principal actualiza su lista de dependencias), y más, estoy seguro.

Puedo ver absolutamente por qué @reduz siente que la gestión de dependencias no es importante. Hay tantas variables que _necesitan_ ser consideradas y resueltas para que valga la pena incluirlas en Godot o, de lo contrario, terminaremos con un sistema que no es mejor que el que usan otros motores.

Honestamente, creo que el mejor curso de acción para una solución a corto plazo es cambiar la librería de activos para admitir (aunque no _requerir_ debido a la compatibilidad con versiones anteriores) la capacidad de servir proyectos que están una capa debajo del directorio addons . P.ej

godot-tools.level-streamer/
    project.cfg

En lugar de

addons/
    godot-tools.level-streamer/
        project.cfg

De esta manera, podemos especificar en la descripción del complemento que requiere algún otro complemento.

También nos permitiría usar fácilmente gitsubmodules en nuestro proyecto para complementos si así lo deseamos.

¿Qué hay de hacer eso para los departamentos (por ejemplo dep/ ) y luego tener los complementos instalados manualmente en el directorio raíz o en una carpeta definida por el usuario? De esa manera, las dependencias no saturan la raíz y los complementos pueden estar en cualquiera de los dos.

$UserSetLocation/
    godot-tools.level-streamer/
        project.cfg

deps/
    thing-level-streamer-uses/
        project.cfg

@ Two-Tone Pero, ¿qué sucede si su dependencia tiene una dependencia? ¿No debería la carpeta deps ser una subcarpeta del complemento en sí, de esa manera puede profundizar arbitrariamente según sea necesario?

Siento que se está pensando demasiado en todo este tema de la dependencia. ¿Tal vez deberíamos idear algunos sistemas simples y tener una discusión sobre cada uno, o una votación? No preveo que esta conversación termine de la forma en que se dirige actualmente.

Habiendo dicho eso...

@willnationsdev Eso podría funcionar, pero si muchos complementos se basan en la misma dependencia, entonces tiene varias copias de esa dependencia donde es posible que solo sea necesario... dos.

Sí, la gestión de dependencias no es algo sencillo. De lo contrario npm no necesitaría ser tan complejo como es y yarn no tendría que haber sido creado.

No creo que poner las dependencias como subcarpetas de activos sea una buena idea, ya que conduce a un camino que será muy complejo. Habrá casos en los que 2 o más activos tengan la misma dependencia y se necesite algún tipo de deduplicación. Además, creo que es mejor para el desarrollador del juego ver exactamente qué dependencias tiene el proyecto, en lugar de tener que revisar subcarpetas de subcarpetas para averiguar qué dependencias se están usando y/o duplicando n veces, ya que es una dependencia común.

En node.js web dev, por ejemplo, está bien ignorar lo que hay dentro de node_modules siempre que funcione, ya que solo se implementará en el servidor. Para un juego, empaquetará todo ese código/activos en un paquete de aplicación final y tener la misma dependencia duplicada n veces es bastante malo.

Estos problemas son la razón por la cual mis sugerencias iniciales decían que no permitiera que los activos definieran dependencias todavía, sino que solo tuviera una forma de enumerar las dependencias del proyecto y permitir que el usuario instale manualmente cualquier dependencia de los activos:
https://github.com/godotengine/godot/issues/19486#issuecomment-399559419

Si tenemos activos que definen dependencias, creo que todos deberían instalarse en el mismo nivel (en la carpeta res://addons ). Para los conflictos de versión de dependencia (dos activos dependen del mismo activo pero de diferentes versiones), creo que lo mejor sería una resolución simple, como optar siempre por la versión más nueva.

Por otro lado, si realmente queremos implementar la gestión de dependencias con deduplicación y resolución de conflictos de versiones al permitir que se instalen varias versiones del mismo activo, ¡también está bien! Como si fuera realmente sólido, podrá respaldar la expansión del ecosistema de activos a largo plazo. Sin embargo, de alguna manera no me gusta la idea de tener múltiples versiones del mismo activo en mi proyecto de juego. Y tomó npm tantas versiones hasta que lo hicieron bien (aunque todavía prefiero yarn ), así que no creo que esta tarea deba subestimarse.

No creo que poner las dependencias como subcarpetas de activos sea una buena idea, ya que conduce a un camino que será muy complejo.
Si tenemos activos que definen dependencias, entonces creo que deberían instalarse todos al mismo nivel (en la carpeta res://addons

Estoy de acuerdo con eso. También preferiría que los complementos existieran una vez en el proyecto en una ubicación estándar, no tantas veces como las versiones requeridas por otras fuentes y en varias carpetas. Las dependencias son una cosa, pero también podemos encontrar un término medio en lugar de ser lo más detallado posible, para mantener las cosas relativamente simples.

Estos problemas son la razón por la cual mis sugerencias iniciales decían que no permitiera que los activos definieran dependencias todavía, sino que solo tuviera una forma de enumerar las dependencias del proyecto y permitir que el usuario instale manualmente cualquier dependencia de los activos.

Para mí, si los activos definen dependencias, sería principalmente para que el usuario se informara más rápido que tener que mirar documentos o revisar todos los complementos antes de instalar. Y eventualmente, tenga la opción de descargar las dependencias al mismo tiempo, pero solo por conveniencia (especialmente cuando instala desde cero, necesitará instalarlas de todos modos). Probablemente no necesitemos resolver conflictos de dependencia también, al menos la herramienta de instalación podría informar al usuario si puede detectar uno.

Siento que se está pensando demasiado en todo este tema de la dependencia

@LikeLakers2 La gestión adecuada de dependencias y la prevención de conflictos es un tema importante y difícil. Se está discutiendo mucho por eso.

No preveo que esta conversación termine de la forma en que se dirige actualmente.

Tratar de impulsar esto sin resolver todos los problemas que trae la dependencia sería una muy mala idea y solo causaría muchos más problemas. Este es un tema difícil y llevará tiempo.

Para los conflictos de versión de dependencia (dos activos dependen del mismo activo pero de diferentes versiones), creo que lo mejor sería una resolución simple

@chanon Mis ideas son simples. ¿Qué tiene de complejo nombrar una carpeta y cambiar las rutas de archivo relevantes en los documentos de texto? Es un costo único para el usuario, hace evidente qué versión de lo que ha instalado y es bastante fácil de escribir.

como ir siempre por la versión más nueva

Eso hará que los complementos se rompan sin previo aviso a medida que sus dependencias se actualicen y cambien la forma en que funcionan. EG Plugin 1 y 2 ambos dependen de Dep 1, pero diferentes versiones. El complemento 2 depende de la última versión actual, pero el complemento 1 depende de una versión anterior que se comporta de manera diferente a la última versión. El complemento 1 ya no funciona según lo previsto o tiene errores con los que no se envió.

Probablemente no necesitemos resolver conflictos de dependencia también, al menos la herramienta de instalación podría informar al usuario si puede detectar uno.

@Zylann Luego tenemos el problema de que el usuario no puede instalar el complemento x porque usa una versión diferente de la misma dependencia. Eso no será visto como algo bueno por los usuarios.

Estoy de acuerdo con @willnationsdev y @LikeLakers2

Siento que se está pensando demasiado en todo este tema de la dependencia. ¿Tal vez deberíamos idear algunos sistemas simples y tener una discusión sobre cada uno, o una votación? No preveo que esta conversación termine de la forma en que se dirige actualmente.

Demasiado desprendimiento de bicicletas. Este es un motor de juego, no una plataforma de entrega de complementos de motor de juego. Solo dependencias de proveedores en cada uno de los directorios de complementos y llámalo un día. No hay estrés sobre el conflicto de versiones o la gestión o w/e a costa de alguna ineficiencia. Si el usuario del complemento está preocupado por el rendimiento, entonces debería estar en condiciones de considerar optimizaciones de rendimiento REAL como GDNative o módulos. Tampoco puedo imaginar por qué cualquier complemento tendría un gráfico de dependencia profundo. La única razón por la que puedo ver un complemento que depende de otro es si lo extiende de alguna manera: SweetFpsController -> SweetFpsController w/ flying . En ese caso, diría que depende de los dos proyectos o de sus usuarios reconciliar su acoplamiento en lugar de darle la responsabilidad al motor.

@Two-Tone si el complemento A necesita la versión 1 de X y el complemento B necesita la versión 2 de X, diría que Godot no debería intentar arreglarlo mágicamente. Aquí hay soluciones simples para esto:

• Normalmente, la versión 2 de X debería ser compatible con la versión 1, y así es como deberían ser las cosas para mantenerlo simple (recuerde cuando mencioné la mentalidad al desarrollar complementos).
• Si no puede usar la última versión de X, espere a que el complemento A lo admita y descargue la versión anterior (necesitamos la API de assetlib para manejar la obtención de diferentes versiones, no solo la última, eso no debería ser difícil de hacer). Es como mods, no tiene que ser perfecto.
• El creador de complementos de X lo carga como un complemento diferente (porque la API rompe la compatibilidad), tal como tuvimos que hacerlo cuando salió Godot 3. Entonces tendrá dos veces el mismo complemento, pero está bien porque son demasiado diferentes para ser realmente los mismos de todos modos, y las cosas que dependen de eso también funcionarán. Incluso puede ser simplemente un cambio de nombre de carpeta por parte del desarrollador del complemento, ni siquiera la necesidad de tener dos entradas de biblioteca de activos.

En el peor de los casos, tendría que hacer que esto funcione manualmente (y eventualmente la compatibilidad de relaciones públicas con el fabricante del complemento).

Si no es así, eso implicaría que se instalen dos versiones con rutas diferentes cada vez (arruinen todas las referencias en cada actualización), o que se agreguen cambios principales al motor para alterar el funcionamiento de las rutas (complicado).
Creo que si podemos obtener una administración de dependencia simple , ya será bastante bueno, ya que básicamente usaría la funcionalidad y la estructura que Godot ya tiene (por lo que también sería bastante simple de implementar), y haría automáticamente cosas que el usuario tiene actualmente. para hacer manualmente de todos modos.

No estoy considerando la administración de dependencias como algo que siempre debería funcionar y ser responsabilidad total del motor (como npm), porque eso sería mucho trabajo. Lo considero principalmente como una conveniencia para las cosas que actualmente tiene que hacer a mano con la funcionalidad existente, y los creadores de complementos pueden publicar su trabajo en función de ese sistema simple en mente.
Si alguien logra implementar bien un sistema que va mucho más allá de esto, entonces puede hacerlo más tarde, porque lo que describí anteriormente es factible antes y en su mayoría son mejoras simples en el assetlib y el editor solamente.

@Zylann ¿Cómo alguna de esas opciones es mejor que lo que sugerí? Y no hay nada mágico en buscar y agregar texto a una cadena específica.

La opción 1 obliga a los desarrolladores a intentar y asegurarse de que las actualizaciones de su versión no rompan ningún otro complemento que dependa de él, lo que les agrega mucho trabajo adicional. ¿Quién quiere desarrollar complementos para algo así?

La opción 2 obliga a los usuarios a no usar el complemento que desean porque tienen que esperar a que se actualice el complemento, si aún se está desarrollando activamente, o simplemente no usarlo en absoluto.

La opción 3, una vez más, dificulta las cosas para los desarrolladores de complementos.

Dos versiones con diferentes rutas no es un problema difícil. Si alguna vez se actualizan, verifique qué paquetes de instalación los tienen como dependencia, vuelva a ejecutar la búsqueda y reemplace (teniendo en cuenta el número de versión anterior) en todos los scripts para esos paquetes, luego finalmente descomprima la nueva versión.

Siento que la gente está tratando de hacer que esto sea más complicado de lo que debe ser.

La gestión adecuada de la dependencia y la prevención de conflictos es un tema importante y difícil. Se está discutiendo mucho por eso.

@ Two-Tone Lo que quise decir es que estás pensando demasiado en el tema, incluso para que sea un problema difícil. Gran parte de la conversación (incluidas mis respuestas, es cierto, así que discúlpenme porque esto va a sonar hipócrita) ha sido sobre lo que está mal con las ideas presentadas, no tanto sobre lo que se puede hacer para cambiarlo y hacerlo mejor. plan. Las ideas que se sugieren no solo pueden tener inconvenientes, ¿verdad? Parece que todo el mundo quiere lo que quiere y lo suyo también, lo que no ayuda en nada.

Tratar de impulsar esto sin resolver todos los problemas que trae la dependencia sería una muy mala idea y solo causaría muchos más problemas. Este es un tema difícil y llevará tiempo.

Sugerí pensar en algunas ideas simples con la implicación de que las resolveríamos y luego decidiríamos una vez que sintiéramos que tenemos un buen sistema. No pensé que tenía que señalarlo explícitamente, pero ahí lo tienes.

Estoy un poco molesto por el tiempo que ha durado esta conversación sin ningún progreso. Seriamente.

Dos versiones con diferentes rutas no es un problema difícil

Eso por sí solo no lo es, probablemente. Pero tener dos versiones del mismo complemento en un momento dado en Godot implica otras cosas que se vuelven confusas de resolver.

• Tus caminos ya no son lo que crees que son / se deben hacer cambios en el núcleo, lo cual es una preocupación para los desarrolladores principales en su mayoría
• Si el complemento expone un tipo personalizado, ¿cuál muestra el editor?
• Si el complemento es C#, ¿cómo lo compila sin que entre en conflicto con otras copias?
• Si el complemento registra cargas automáticas, ¿cómo las diferencia?
• Si el usuario crea datos que usan el complemento, ¿cuál usará?
• ¿Cuál mostrará la interfaz de usuario en el editor?

Creo que antes de que podamos encontrar soluciones simples para aquellas que se ajustan al motor (y puede haber más en las que no pensé), ya podemos mejorar las cosas existentes en el editor y la librería de activos sin romper la compatibilidad o introducir cambios básicos.

+1 en todo en este hilo: extender el módulo del complemento y aumentar el uso de la librería de activos es el camino a seguir

Después de haber probado y aprendido Unity, ahora tengo una idea más clara de cómo debería ser esto.

Primero, Unity ahora tiene un 'Administrador de paquetes' que usan para permitir que los usuarios seleccionen qué componentes del motor les gustaría instalar/desinstalar. Parece que también pueden usar esto para la Tienda de activos en el futuro.

Algo como esto realmente ayudaría a Godot a poder "reducir la hinchazón" mientras tiene "complementos oficiales". Unity todavía está súper hinchado incluso con su Administrador de paquetes, mientras que si Godot tuviera uno, podría volverse aún más pequeño. Sin embargo, el método de distribución "one exe" podría tener que desaparecer.

Además, los "módulos" normales tal vez deberían construirse como bibliotecas compartidas (archivos dll/.so) para que puedan seleccionarse para instalar/desinstalar en el administrador de paquetes.

Los proyectos y paquetes deben tener archivos de manifiesto que enumeren los paquetes de los que depende y Godot / el administrador de paquetes se aseguraría de que se instalen los paquetes necesarios.

Sería necesario un registro público de paquetes.

Esto permitiría a la comunidad ampliar fácilmente las capacidades de Godot y construir fácilmente sobre los trabajos de los demás. Creo que promovería mucho el desarrollo de la comunidad.

No estoy en desacuerdo con el mérito general de pasar al enfoque del Administrador de paquetes, todavía no me he decidido al respecto, pero quiero señalar que también tiene sus debilidades: un solo ejecutable puede estar mucho más integrado y bien. probado, al menos más fácilmente.

Con un administrador de paquetes, la superficie de prueba crece exponencialmente para cada complemento y versión. Esto no es tan malo si los complementos son en su mayoría pequeñas adiciones (como actualmente en AssetLib) que no se enganchan demasiado en el núcleo del motor, pero rápidamente lo es si divide las partes centrales del motor.

Unity ya tiene problemas, bloqueos y problemas de compatibilidad con diferentes versiones de sus paquetes, sus editores, o con algunas combinaciones de paquetes específicas instaladas (o no instaladas), o incluso con el orden en que se instalaron.

Esta es una gran cantidad de complejidad adicional que debe administrarse bien, para que no terminemos en un infierno de dependencia :)

Con respecto al infierno de dependencia, ¿por qué no tomar una página de algo como AppImage e intentar evitar problemas de dependencia haciendo que los distribuidores de complementos sean responsables de administrar las dependencias de activos/archivos? Así es como veo este problema...

Los complementos deberían (idealmente) ser elementos independientes de lógica (editores personalizados, nodos personalizados, bibliotecas vinculadas dinámicamente) o activos (modelos, materiales, fuentes, texturas, etc.) que deberían tener sus propios conjuntos de dependencias. Tratar de averiguar las dependencias compartidas es un enigma que, si bien a la gente le puede gustar, significa mucho más esfuerzo para mantenerlo. Si realmente permitiera las dependencias compartidas, tendría que abordar este problema de manera similar al tiempo de ejecución de Steam y mantener un montón de bibliotecas, complementos y activos diferentes como sus propios paquetes únicos. También necesitaría almacenar varios de los mismos paquetes en un servidor para varias versiones; sería una pesadilla de mantenimiento y no sorprende que las distribuciones modernas de Linux se estén alejando más o menos de los administradores de paquetes.

Un complemento podría ser esencialmente un único archivo tar de todos los elementos necesarios para que ese complemento funcione de forma aislada. Deberían funcionar de forma nativa por su cuenta con todas las dependencias archivadas en su interior también. Cuando Godot ve este archivo, busca un archivo de manifiesto dentro de la raíz de la carpeta archivada. Este manifiesto podría contener información básica (nombre, descripción, versión de Godot, ícono, autores) pero también debería contener cosas como: información de actualización (enlace para descargar la última versión, mantenida por desarrolladores de complementos) que Godot puede usar para actualizar automáticamente el plugin (con permiso de los usuarios), project_website (enlace al repositorio o sitio web para que los usuarios puedan encontrar rápidamente el origen de un paquete) y class_names (lista de clases dentro de este complemento que se puede ampliar, usar para secuencias de comandos). También podría apuntar a los complementos que usa como dependencias usan la ruta relativa a un archivo de complemento interno.

Si permitimos complementos dentro de complementos, los problemas de dependencia se resolverán (más o menos). Las versiones diferentes de la misma biblioteca estarán en rutas de directorio diferentes y podrían tratarse como 'rutas' diferentes en una bifurcación determinada. El problema con este sistema, por supuesto, es que termina teniendo mucha información duplicada en un disco determinado. Sin embargo, al empaquetar un juego, Godot idealmente podría pasar por todos los directorios de complementos y fusionar las referencias de archivos que coinciden a través de la suma de verificación (¿esto puede incluir estructuras de archivos representadas en tar?). De esta forma, si dos archivos son idénticos, Godot optimizará el binario de salida final fusionando la referencia en un solo archivo.

Estoy seguro de que esta es una solución demasiado ingenua para un problema tan complicado, pero estaba pensando en el sistema de complementos más recientemente debido a mi parche de fuente personalizado. Creo que la mejor experiencia de usuario es aquella en la que no tienen que preocuparse por las dependencias, y los desarrolladores son los que deberían preocuparse por administrar sus propias dependencias. Esto hace que sea más fácil de administrar para el usuario: un proyecto puede tener sus complementos representados como un solo archivo en el panel del sistema de archivos, puede hacer clic con el botón derecho y obtener opciones adicionales ( extract files (para desarrollo), update plugin (para actualizaciones sencillas), vaya al sitio web ( for easy community organization )) y también haga referencia a las clases dentro de un 'contenedor' determinado ( extends "[path-to-addon-tar]://ClassName" )

Solo mis 2 centavos al respecto, estoy seguro de que también hay algunos defectos en la forma en que lo estoy pensando, pero podría ser una solución interesante y también una forma decente de reducir la necesidad de mantenimiento para el equipo Godot.

Solo 2 centavos basados ​​en los 2 centavos anteriores (¿son 4 millas?):
Supongo que los archivos .tar serían un poco desconocidos para la mayoría de los usuarios (ejem, usuarios de Windows), por lo que podría ser mejor usar archivos .zip , ya que tienen un soporte algo más amplio.

Dicho esto, ¿qué pasa con la distribución de complementos en el propio formato .pck de Godot? Tengo algunas desventajas (como que la mayoría de las aplicaciones no lo reconozcan), pero esa podría ser una oportunidad para hacerlo más estándar y usado.

Supongo que los archivos .tar serían un poco desconocidos para la mayoría de los usuarios (ejem, usuarios de Windows), por lo que podría ser mejor usar archivos .zip, ya que tienen un soporte algo más amplio.

Dicho esto, ¿qué pasa con la distribución de complementos en el propio formato .pck de Godot? Tengo algunas desventajas (como que la mayoría de las aplicaciones no lo reconozcan), pero esa podría ser una oportunidad para hacerlo más estándar y usado.

Claro, principalmente quise decir .tar como un ejemplo de un tipo de archivo empaquetado genérico. Podría y probablemente debería usar el formato .pck de Godot.

¿Por qué no usar ZIP ya que ofrece compresión y es un formato estándar?

@Calinou Estoy de acuerdo. Si exigimos que se usen archivos .pck, entonces las personas tendrán que usar Godot Engine para empacar cosas en lugar de simplemente usar la herramienta de empaque preferida para agrupar su complemento para su uso. GitHub también descarga repositorios como archivos .zip y alberga la mayor colección de complementos de Godot con diferencia.

Estoy de acuerdo aquí. No creo que sea necesario crear otro tipo de archivo. Los archivos zip parecen funcionar muy bien, y la gente tiene la opción de instalar usando la interfaz de Godot a través de la biblioteca de activos, o pueden descargarlos manualmente. un archivo .pck no permite esa opción.

En mi mundo ideal, me gustaría tener dos botones de descarga en https://godotengine.org/download :

• Una descarga mínima y elegante que cumple con los tres requisitos de reduz, y
• Una descarga masiva con todos los complementos aprobados y mantenidos regularmente que han superado algunos controles de calidad, por lo que sé que su API funciona al menos tan bien con el núcleo como la API de la versión mínima.

Aún más ideales:
Seleccionar y mezclar. Al descargar el mínimo, puedo seleccionar la versión mínima + "Temas" del complemento. Que son colecciones de complementos comunes necesarios para casos de uso comunes. (por ejemplo: 2DPixelart, 3D FirstPersonShooter, 3D ThirdPerson, RTS, RPG, 2.5D game, 2DCutout, Rougelike, ManagementSim, Sidescroller, Eventpackage, Shaderpackage, Scriptpackage, Assetpackace, etc.). Entonces, cuando enciendo los motores, los complementos esenciales ya están instalados y listos para funcionar y sé que funcionan porque han sido aprobados.
Los usuarios más avanzados podrían desmarcar complementos individuales dentro de esas colecciones de temas si saben que no los necesitan, o combinar dos o más temas de complementos, o agregar complementos individuales adicionales a los temas del conjunto de complementos aprobados para crear un paquete personalizado.

Idealmente, el resultado sería que https://godotengine.org/download crea a partir de esas opciones _un enlace de descarga sobre la marcha_.

¿Por qué? Porque esto sería un gran ahorro de tiempo y garantía de calidad para las personas que trabajan en equipos o grupos, para educadores y profesores en escuelas que tienen que implementar en varias computadoras, para personas que siguen tutoriales y quieren la misma configuración que el tutor, para individuos que están felices de que haya un complemento oficial aprobado por el equipo de desarrollo para algo que se usa comúnmente, pero no para todos, por lo que no tienen que buscar en Github y Reddit durante días para encontrar lo que necesitan, sin saber cuál es el más compatible. opción de las 6 que encontraron.

Debería seguir existiendo una descarga mínima con un solo clic para aquellos que necesitan el tamaño pequeño, así como una descarga de funciones máximas a quienes no les importa el tamaño pero quieren las funciones máximas para ver lo que puede hacer el motor.

Una solución más simple sería solicitar la instalación de complementos adicionales [¿solo oficiales?] cuando se ejecuta el editor por primera vez. Actualmente tenemos la opción de abrir AssetLib si la lista de proyectos está vacía; ¿Por qué no tener una ventana emergente de diálogo para instalar complementos oficiales si ejecuta Godot por primera vez?

Cierre a favor de https://github.com/godotengine/godot-proposals/issues/142 , https://github.com/godotengine/godot-proposals/issues/577 y https://github.com/godotengine/ godot-proposals/issues/607 , ya que las propuestas de características ahora se rastrean en el repositorio de propuestas de Godot.

Edición de aaronfranke: consulte también https://github.com/godotengine/godot-proposals/issues/554