Utilizo Godot profesionalmente durante más de un año.

Estoy de acuerdo con todo lo que dijiste, excepto por:

Para algunos, creo que deberíamos mantener la forma actual

Si tenemos esta oportunidad de oro, cambiemos el nombre de todo. Eso incluye Sprite2D y MeshInstance3D.

Siempre es mejor un refactor completo doloroso, que muchos refactores dolorosos parciales.

Hablando de cambio de nombre: https://github.com/godotengine/godot/issues/16863

@ jahd2602 No me importa de ninguna manera personalmente, podemos sondear eso en el peor de los casos.

Definitivamente puedo ver a la gente molesta con eso simplemente por el hecho de que es una inconsistencia, pero al menos podemos ver si son mayoría o minoría.

@Zylann Lo sé, si decidimos algo aquí, trasladaremos esto para allá.

Creo que la postura contra los espacios de nombres es miope. Tiene sentido desde la perspectiva del flujo de trabajo del motor en general, pero ignora la perspectiva de los fabricantes de herramientas. Godot Unit Testing (GUT) de bitwes, por ejemplo, se rompió debido a un conflicto de nombres en una de sus actualizaciones. Es probable que esto se haya podido evitar con un espacio de nombres GUT dedicado.

También me gustaría espacios de nombres para espera y prueba (WAT) para poder usar nombres de clases como Prueba (a la que se accede a través de WAT.Test) sin ejecutar otros marcos (como GUT si se usara GUT.Test) o solo el script del usuario. He intentado varias veces usar una clase WAT que contenía todos los scripts utilizados como subclases, pero eso es solo un infierno de referencia cíclica.

Si se nos anima a crear herramientas desde dentro del motor, entonces necesitamos las herramientas para crear esas herramientas en el motor, incluso si no son absolutamente necesarias para el flujo de trabajo del motor en sí.

En resumen, un sistema de espacio de nombres dedicado al que se puede acceder y definir desde el motor (o al menos el script del complemento) para que los fabricantes de herramientas no terminen caminando unos sobre otros o sus usos serían una bendición.

@CodeDarigan Entiendo que tiene beneficios y no los niego, pero creo sinceramente que los costos los superan.

Agregue a esto que prácticamente no tuvimos quejas significativas de los usuarios de GDScript, que prefieren el enfoque actual, por lo que los obligaría a un workfklow no deseado y a escribir más código en un lenguaje que está destinado a escribir cosas rápidas y sucias rápidamente. (Sin embargo, los usuarios de C # parecen quererlos).

Es por eso que quiero decir que pueden existir como metadatos para enlaces de lenguaje de script, e incluso podríamos agregarlos para GDNative C ++. Simplemente no los agregue para el motor central de C ++.

Navegación -> Nagivagion3D
¿Es esto un error tipográfico?

@nitodico de hecho

@reduz Estoy de acuerdo con @ jahd2602. Incluso si algunas cosas pueden ser obvias, en aras de la coherencia, deberíamos postfix con 2D o 3D.

Todavía estoy comenzando con Godot y los cambios propuestos me parecen sensatos: usar nombres sutilmente diferentes para la variante 2D o 3D de un nodo es algo que me ha causado un poco de confusión al aprender cuál es el final y pasar a Thing2D / Thing3D o Thing / Thing3D se siente como una mejora significativa en la claridad y la comprensión.

Por favor hágalo.

Tbh este cambio vendría de todos modos, así que es mejor hacerlo ahora y seguir adelante. Para 3d no hay tantos cambios, por lo que ahora el cambio hará menos daño que en uno, dos años después.

En cuanto a los materiales, sería bueno tener algún tipo de Legacy Material que solo use recursos mínimos, como difuso y especular, esto sería útil para juegos móviles en 3D.

También estoy a favor de cambiar el nombre de las cosas para que sean explícitamente 3D o 2D.

¿No sería posible que los nombres originales siguieran existiendo como alias de los nuevos? Se ocultarían del editor para que los nombres antiguos no se pudieran utilizar (o se colocarían bajo un encabezado "obsoleto"). De esa manera, el código antiguo seguiría funcionando, sin cambios y sin necesidad de lógica adicional para convertir nada.

Se podría agregar una advertencia para el código que usa los nombres de nodo en desuso y luego, en 4.1 o 4.2, se podrían eliminar.

Si hay dos versiones de un nodo, siempre agregaría el sufijo 2D / 3D.

Además, estaría feliz si Label -> TextLabel. Voy a agregar un nodo para poder mostrar algo de texto, así que escribo texto en la barra de búsqueda y, por supuesto, solo aparece RichTextLabel, lo que me recuerda que el nodo de texto estándar en realidad no tiene Texto en el nombre.

@ Janders1800 , así es como funciona ahora, cuantas menos funciones uses en SpatialMaterial, más pequeño será el sombreador que crea.

Soy una persona 2d, por lo que para los nodos con aplicaciones principalmente 2d, mantener los nombres de los nodos sin un sufijo si aún no tiene uno me parece bien. Esto parece una refactorización más dolorosa para los usuarios de 3D, pero tiene mucho sentido cuando ciertos nodos tienen solo una aplicación 2d o 3D en su mayor parte, que conservan el nombre más corto para su dominio previsto y tienen un sufijo en otro lugar. Cualquier otra cosa que pueda ser unificada sería bueno para ver unificada, específicamente Spatial .

Estoy a favor de usar incondicionalmente los sufijos 2D / 3D también.

Si bien es cierto que para algunos nodos parece una oportunidad perdida tener nombres más "naturales", la consistencia gana.

Lo que no me gusta del todo es que el StandardMaterial3D es el que no es ORM. Mi punto es que ORM está más respaldado por un estándar (al menos RM, que es lo que tiene en glTF).

Pero todavía no puedo sugerir un nombre mejor.

Quizás esta sea también una oportunidad para hacer algo sobre el 'lienzo'. Encontré ese concepto un poco confuso a veces.

Sé que es difícil, porque no tiene contraparte 3D: las escenas 3D viven en nodos Spatial , pero los lienzos pueden contener una combinación de Node2D sy Control s.

Sin embargo, sería genial si pudiéramos definir algún nombre que permitiera cambiar el nombre de CanvasItemMaterial a Material2D , mientras que mantiene su significado para los dominios 2D y GUI "puros".

No estoy necesariamente en contra del cambio de nombre, pero los nombres originales tienen sentido para mí, tal vez por mi experiencia.
El valor predeterminado en física o ingeniería es "3D". No dice "cuerpo cinemático 3D", dice "cuerpo cinemático", a menos que esté trabajando en otro espacio.
Sin embargo, estoy seguro de que no todos tienen los mismos antecedentes o incluso están de acuerdo en eso, ya que, después de todo, este es un motor de juego y no tiene que seguir estrictamente las convenciones de física o ingeniería.

para compatibilidad futura, en gdscript

un archivo gdscript ...

extiende espacial
class_name Node3D

Etcétera.

¿Ha pensado en cambiar el nombre de translation para nodos espaciales a position ?

@BeayemX Creo que la traducción es un término común para el espacio 3D, y la posición es común para los desarrolladores 2D: pensar:

No sé si 4.0 será lo mejor para los cambios de nombre de nodo, habrá muchas cosas con las que lidiar y hubo muchos cambios de 2 a 3, significa que se desaprobarán libros, videos, cursos.
Incluso la documentación no está completa, con cambios a mitad de la finalización, las correcciones ralentizarán mucho las cosas ...

Estoy a favor de cambiar el nombre de los nodos 3D como se sugiere aquí. Sin embargo, no sé qué tan problemático será para los creadores de tutoriales. Como mínimo, debería ser trivial refactorizar las bases de código existentes. En C # incluso podríamos abusar de ObsoleteAttribute en modo de depuración para hacerlo más fácil (aunque no estoy seguro si es una buena idea):
[Obsolete("Use Node3D", error: true)] class Spatial { /* Nothing here */ }

Espero que agreguemos espacios de nombres / categorías como se discutió en # 18711. Quiero separar la API de C # en espacios de nombres y quizás también en ensamblados para que los usuarios puedan elegir solo lo que necesitan.
Mi plan para 4.0 era codificar una tabla de espacios de nombres yo mismo si no hubiera otra opción, pero preferiría que en su lugar pudiera obtener esta información de ClassDB.

@ eon-s No creo que lo sea ... mientras que translation es técnicamente válido para representar coordenadas, Godot es el primer motor en el que veo que se usa un término diferente aquí, de lo contrario, siempre he visto position independientemente de 2D o 3D. También para mí translation está asociado con el movimiento y entra en conflicto con otro término relacionado con el lenguaje / transformación, lo que lo hace extraño. Esto también se mencionó en https://github.com/godotengine/godot/issues/16863 .

Por cierto, ¿por qué planeamos romper lo menos posible? Entiendo por qué la gente no quiere más fallas de compatibilidad, especialmente aquellos que hacen tutoriales; pero si no aprovechamos la 4.0 como una oportunidad para romper la compatibilidad, ¿cuándo lo haremos? # 16863 ya está acumulando muchas sugerencias.

@neikeq no puede esperar a 5.0? Dado que no se planean funciones nuevas o grandes, de lo contrario, la gente dejará de hacer cosas y comprar cursos para un motor que cambia partes importantes cada 1 o 2 años (para los creadores de tutoriales en video esto significa rehacer todo su trabajo) y con unos meses de tiempo de advertencia. ...

Estoy a favor de cambiar el nombre para tener un sufijo 2D / 3D consistente, y estoy de acuerdo con muchos en este hilo en que debería hacerse para todos los nodos para mantener la coherencia. Tener una convención de nomenclatura consistente es extremadamente útil para alguien que está aprendiendo el motor, o alguien que se mueve del lado 2D al 3D, o viceversa.

@ eon-s Sin duda, esperar hasta la versión 5.0 solo significa que habrá un volumen de trabajo aún mayor que debe actualizarse.

Por mucho que sea maravilloso tener tutoriales, votaría por hacer que el motor sea más comprensible en lugar de mantenerlo confuso por el bien de los tutoriales existentes. Es de esperar que se puedan utilizar scripts de fixit o alias opcionales (como se discutió anteriormente) para suavizar la ruta de actualización.

Aprecio la diferencia de nombres entre Node y Spatial porque los nodos de Node no tienen conocimiento del espacio, tener Node, Node2D y Node3D sería confuso. A menos que planee deshacerse de Node, entonces tendría mucho sentido.

Estoy a favor de tener solo un reino 2D o 3D teniendo que soportar tener un sufijo. Es 2D en este momento y la confusión entre 2D y 3D termina ahí.

No agregue el sufijo 3D. ¿Realmente vale la pena el dolor de cabeza por lo que agrega? ¿Vale la pena el costo? de actualizar todo o tener tutoriales obsoletos? ¿Tutoriales de youtube no modificables y desactualizados? Traerá más confusión.

@dpalacio Estoy usando Godot solo por unos meses, pero creo que es más claro y conciso usar Node3D, Node2D y Node debido a que Spatial actúa como Node3D y el Node no tiene información de espacio. Creo que agregar un sufijo para 3D será mucho más simple de entender, ya que se llamará "de manera opuesta". Sé que no es realmente opuesto, pero no sé cómo expresarlo mejor porque el inglés no es mi lengua materna. Poner 3d versus 2d explícitamente me parece genial. Creo que será mucho más fácil para los principiantes y aún más para las personas que están teniendo el primer contacto con un motor de juego. Los espacios de nombres también son geniales, principalmente para grandes proyectos y complementos. Los nombres en conflicto son un dolor de cabeza. Como principiante, creo que la ruptura de compatibilidad debe ser mínima y automática porque es difícil seguir cambiando proyectos entre versiones. Si tenemos muchos cambios, también necesitaremos una herramienta de conversión automática y documentación.

@neikeq sí, la categoría debería ser reemplazada por un espacio de nombres y deberíamos crear los adecuados.

Exactamente lo que estaba pensando cuando probé Godot. Mi TOC me dice que debería ser así.

¿Ha pensado en cambiar el nombre de translation para nodos espaciales a position ?

"posición" suena más como una posición absoluta en lugar de una posición relativa.
Llamarlo posición podría ayudar a los nuevos desarrolladores, pero eventualmente se darán cuenta de que debería llamarse traducción.

Estoy un poco indeciso con esta propuesta como alguien que escribe tutoriales de Godot y usa Godot para mis propios proyectos con todas las funciones.

Estoy totalmente a favor de cambiar los nombres de los nodos para mantener la coherencia, y estoy de acuerdo con otros en que la coherencia es importante, incluso si hace que las cosas sean un poco más complicadas. Preferiría agregar 3D o 2D al final / comienzo de los nodos si hace que las cosas sean más consistentes en la base del código y la documentación.

Aquí hay algunos nodos que me gustaría ver modificados para mantener la coherencia:

• MeshInstance -> MeshInstance3D (para mantener la coherencia con MeshInstance2D )
• GridMap -> TileMap3D o GridMap3D
• TileMap -> TileMap2D o GridMap2D
• YSort -> YSort2D o 2DSort (o algo para mostrar que es para 2D)
• ProximityGroup -> ProximityGroup3D
• GIProbe -> GIProbe3D (o algo para mostrar que es para 3D)
• ReflectionProbe -> ReflectionProbe3D (o algo para mostrar que es para 3D)
• SpatialMaterial -> PBRMaterial o Godot3DMaterial o StandardMaterial3D (solo ideas)
• Label -> TextLabel (Estoy de acuerdo con @MuffinManKen)

Aquí están mis pensamientos sobre esta propuesta, comenzando con los aspectos positivos:

Creo que este cambio hará las cosas más fáciles para aquellos que no tienen experiencia con Godot, pero solo se realizan aquellos que vienen después de estos cambios. Especialmente en el lado 3D, uno de los mayores problemas que encuentro es que puede ser difícil encontrar los nodos que necesita, y creo que cambiar el nombre de los nodos con un esquema de nombres coherente hará que esto sea mucho más fácil para todos.

Muchas de las veces que estoy ayudando a otros con Godot, encuentro que una de las formas más seguras de encontrar una solución es buscar en la documentación. Sin embargo, dado que los nombres de los nodos no siempre son consistentes, encontrar la página de documentación puede ser difícil para ciertos nodos, a menos que ya sepa el nombre del nodo que está buscando. Los cambios en esta propuesta facilitarían mucho la búsqueda del nodo correcto.

Otro beneficio que puedo ver con este cambio es que establece un estándar sobre cómo se deben nombrar los nodos, lo que podría ser útil para los creadores de complementos y futuras contribuciones de Godot Engine. Por ejemplo, si estoy creando un nodo de calcomanía (por ejemplo), entonces con este cambio sé que debería nombrarlo algo como Decal3D lugar de solo Decal .
Esto también podría ayudar con el nombramiento de clases definidas por GDScript / C #.

Esto también facilitaría un poco la escritura de tutoriales en el futuro, ya que ya no tendrá que explicar que Spatial es básicamente un Node2D en 3D.

Ahora para los negativos:

Uno de los mayores problemas que tengo con esta propuesta es que parece demasiado pronto, especialmente teniendo en cuenta cuánto Godot 3.0+ cambió las cosas no hace mucho tiempo. Creo que solo han salido unos pocos juegos con Godot 3.0+, y muy pocos juegos de Godot en 3D.
Muchos de los grandes e impresionantes juegos en 3D en el escaparate de Godot aún no se han lanzado, y hacer un gran cambio como este significa que esos proyectos también deberán actualizarse, lo que retrasará aún más algunos juegos de Godot en 3D realmente fuertes.

Además, todavía se están publicando tutoriales de Godot 3.0+. Especialmente en el lado 3D, las cosas están comenzando a ganar tracción. Si bien esto se debe en parte a que el lado 3D de Godot se vuelve más fuerte en Godot 3.0+, me temo que muchos de los materiales de tutoriales que los escritores están haciendo (o tienen en proceso) de repente necesitarán una nueva redacción masiva para tener en cuenta los cambios de nombre. Esto le quitará tiempo a la creación de nuevos tutoriales, ya que los tutoriales antiguos deberán eliminarse, rehacerse o reescribirse.

El cambio de nombre también haría que los recursos existentes que no son tutoriales, solo soluciones simples encontradas a problemas, de repente se desactualicen. Si bien podría decirse que el lado 2D de Godot es bastante fuerte y probablemente se pueda adaptar rápidamente, la comunidad que usa el lado 3D es notablemente más pequeña. Al cambiar los nombres de los nodos, me preocupa que esto obstaculice el crecimiento del usuario 3D de Godot y la capacidad de encontrar soluciones a los problemas relacionados con el 3D.

Estoy de acuerdo con @ eon-s: ¿estos cambios no pueden esperar un poco? Las cosas ya están cambiando bastante dramáticamente, al menos en la base del código, con Godot 4.0. Creo que agregar otro cambio masivo solo hará que el desarrollo sea más difícil y restablecerá una gran cantidad de progreso que la gente está haciendo con el lado 3D de Godot.

Una vez que salga Godot 4.0, creo que trabajar para cambiar el nombre de los nodos en la versión 4.1 o 5.0 sería excelente, pero en mi opinión, creo que agregar otro gran cambio como este hará más daño que ayuda.

Una cosa que podría mejorar esta transición es tener un alias / período de transición, tal vez de Godot 4.0 a Godot 4.1, por ejemplo. Esto no haría que los tutoriales y los recursos (especialmente los 3D) se queden obsoletos instantáneamente y les daría a todos la oportunidad de adaptarse a los próximos cambios y al mismo tiempo poder beneficiarse de los cambios en Godot 4.0.

El uso de un alias / período de transición permitiría realizar cambios que rompan la compatibilidad sin obligar repentinamente a todos a actualizar todos a la vez. Esto también permitiría que los cambios que rompan la compatibilidad se realicen con más frecuencia, ya que teóricamente, una vez que un sistema está en su lugar para las transiciones, podría usarse nuevamente para futuros cambios que rompan la compatibilidad. Esto facilitaría las cosas en el futuro con los cambios enumerados en # 16863.

TLDR: Estoy totalmente a favor de los cambios, creo que debería esperar hasta Godot 4.1 o se debería hacer un sistema / período de transición para que todos tengan tiempo de adaptarse a los cambios.

Independientemente de cómo termine esta propuesta: creo que Godot 4.0 será genial y estoy deseando que llegue 🙂

@reduz digo que lo

No soy un gran fanático de hacer que todos los nodos 3D terminen en "3D", pero claro, si todos quieren. Creo que está bien mantener diferentes nombres en lugar de tener siempre un sufijo (por ejemplo, TileMap y GridMap)

Preferiría mucho "posición" en lugar de "traducción". El último se puede confundir con la localización y los idiomas, y el primero es inmediatamente claro y amigable para los principiantes. Sin embargo, ¿no usa Godot "origen" en la mayoría de los lugares para esto?

También estoy de acuerdo con @neikeq en que vale la pena romper la compatibilidad si es un cambio beneficioso para nuevos proyectos. Personalmente, me encantaría ver implementada la gran mayoría de las cosas en # 16863.

(por cierto, ¿por qué existe Sprite3D cuando podría ser solo una malla cuádruple?)

@TwistedTwigleg Lea mi publicación, los proyectos 3.0 se abrirán bien en 4.0 si se agrega un sistema de compatibilidad interno.

Buen cambio, como programador, estoy feliz de ver el nombre de la contraparte lo más simétrico posible

¿Puede explicar con más detalle qué significan las texturas de estilo ORM?

@reduz es la única diferencia entre el material espacial estándar y el ORM, ¿que solo tiene un canal de textura (en lugar de 3 como está actualmente) con el ORM? ¿Seguirá teniendo acceso a los mismos parámetros (en metálico y rugosidad) como el especular y los multiplicadores? No se usa a menudo, pero a veces se usa para modificar.

Me gusta la idea, pero me pregunto si es excesivo tener 2 tipos de material para un cambio tan pequeño. En su lugar, ¿podría haber una palanca para cambiar entre 1 canal de textura para el modo ORM o 3 para el estilo existente, usando un solo material?

Recientemente también he estado poniendo el canal de profundidad (altura) en el canal alfa de mis mapas ORM para sacar más provecho de las texturas. Entonces puedes hacer la mayoría de las texturas usando solo 3 texturas ... albedo / normal / ORM (H). Esto podría valer la pena agregarlo de forma predeterminada (a menos que obtengamos una opción de 16 bits para mapas de altura, donde querría usar uno separado). Si 4.0 finalmente obtiene la teselación / desplazamiento, el canal de altura será mucho más importante de lo que es actualmente.

Y hablando de eso, también sería una buena oportunidad para cambiar el nombre del canal DEPTH a HEIGHT en 4.0 y hacer que use el inverso de lo que usa actualmente (es decir, el blanco es una superficie elevada y el negro está empotrado). Esto lo pondría en sintonía con otros renderizadores y motores de juegos y, lo que es más importante, con herramientas como Substance, Quixel y Marmoset.

Preferiría sufijos explícitos para nodos 2D y 3D, y ningún sufijo si no es aplicable. También me gustaría que los nodos "Control" se separen completamente para los nodos "Node2D" (ambos están agrupados actualmente en "CanvasItem").

Aproximadamente translation versus position , iría por el primero en 2D y 3D.

position parece más amigable, pero deja de tener sentido una vez que un antepasado tiene alguna rotación o escala.

En cuanto a la compatibilidad, la etapa de transición debería durar todas las versiones 4.x para dar suficiente tiempo a los tutoriales, usuarios y proyectos. Los nuevos nombres deben ser ciudadanos de primera clase y ser alentados, pero los viejos deben funcionar, con algún mecanismo en el editor para informar a la gente sobre el cambio.

Estoy absolutamente a favor de los cambios sugeridos siempre que se hagan de una manera que facilite a los usuarios finales actualizar el código existente, ya sea el suyo o el código de los tutoriales y la documentación existentes, a través de algún tipo de herramienta como se mencionó. Al carecer de una herramienta de este tipo, estaría de acuerdo en que estamos avanzando bastante poco después de los grandes cambios de la v2 a la v3.

@TwistedTwigleg con respecto al lanzamiento de juegos 3d, eso es porque estamos esperando 4.0 y Vulcan 😎

También revisaría Control nombres de nodos ... y documentación en línea.

A veces me pregunto cuál es la diferencia entre AcceptDialog y ConfirmationDialog , y lo mismo con PopupPanel , PopupDialog , PopupMenu ... espero que esto ayuda!

Como tutor y colaborador de documentos, diría que sigue adelante. No me importa producir más contenido si los cambios facilitan que todos aprendan y comprendan el motor en el futuro. Será mejor que haga este tipo de cambio lo antes posible.

Llegar tarde a la fiesta, pero algunas aclaraciones para mantener las cosas manejables:

• Comente solo sobre la propuesta de cambio de nombre de los nodos y sus implicaciones técnicas sobre cómo preservar la compatibilidad, el impacto en los proyectos existentes, tutoriales, creadores de contenido, etc.
• Este no es el lugar para discutir puntos específicos en la API que deben considerarse para cambiar el nombre. Si decidimos optar por este cambio de nombre masivo, revisaremos toda la API en una hoja de cálculo para asegurarnos de que tenemos nombres consistentes. Para cosas específicas como métodos, propiedades o clases que deberían ser renombradas más allá de lo que se discute aquí, vea # 16863.
• @RandomShaper @fracteed @fire @reduz Por favor, traslade la discusión sobre materiales estándar a un número

Hola,
¿Por qué no seguir la práctica de otras API y crear un decorador obsoleto / obsoleto para clases (o incluso métodos), es decir, los nombres antiguos son simplemente alias / punteros al nuevo? Esto detendría cualquier cambio importante y permitiría que los nombres se eliminen en la versión 5 para que menos personas se vean afectadas o incluso se den cuenta.

El uso de un decorador también podría brindar otros dos beneficios:

1. El IDE podría recoger fácilmente esta etiqueta y mostrarla en la ventana de selección de nodo, por ejemplo, en lugar de simplemente decir 'Espacial', podría leer 'Espacial (uso obsoleto Node3D)'.

2. El decorador podría convertirse en una advertencia incorporada que se muestra en el editor de código.

Además, no impide que nadie cree una herramienta de cambio de nombre ...

Algunos pensamientos:

Estoy de acuerdo con el cambio de nombre de los nodos, así como con algunos métodos y propiedades (vea la lista actual en # 16863) para mejorar la consistencia y hacer que la API sea más fácil de aprender y usar. Dejar clara la distinción 2D / 3D parece una buena idea, y si se hace, debería hacerse de manera consistente (por ejemplo, también MeshInstance3D como se mencionó). Sugiero que usemos una hoja de cálculo para enumerar todos los nodos actuales y cuáles deberían ser sus nuevos nombres en 4.0, y podemos intercambiar información sobre nodos específicos como TileMap / GridMap. Crearé esta hoja de cálculo en los próximos días si confirmamos que este es el camino que queremos seguir.

Sin embargo, debemos esforzarnos por limitar las fallas de compatibilidad tanto como podamos. Como mencionó Juan, podemos tener cambios de nombre de compatibilidad en las partes internas del motor para que las escenas antiguas se puedan cargar y convertir, pero eso no es suficiente.

Como mencionaron @RandomShaper y @chucklepie , deberíamos agregar alias obsoletos para todos los nodos, métodos, propiedades, constantes, señales, etc. que cambiamos de nombre, con un decorador de propiedades / metadatos que los señalaría como obsoletos y alentaría a los usuarios a cambiar su código. El uso de esta información en el IDE debería permitir a los usuarios seguir los tutoriales 3.x en 4.0 sin problemas, mientras aprenden fácilmente sobre los nuevos nombres a medida que avanzan.

Para hacerlo, necesitamos métodos auxiliares que nos permitan definir alias obsoletos al registrar enlaces. # 23023 es un primer intento de agregar una interfaz de este tipo, pero aún debe revisarse, fusionarse y tal vez expandirse si no es suficiente para lo que necesitaremos en 4.0. Esos alias obsoletos se pueden mantener durante todo el ciclo de lanzamiento 4.xy eliminarse en 5.0.
Me opondría a cualquier cambio de nombre que rompa la compatibilidad hasta que tengamos esta interfaz bien diseñada y fusionada, por lo que cualquier persona interesada en esto puede probar este PR y sugerir cambios si es necesario.

En cuanto al cuándo , insisto en que si queremos volver a romper la compatibilidad, esto es ahora. Esperar a 5.0 no tiene sentido, ya que volvería aún más contenido obsoleto una vez que lleguemos a 5.0, y no ayudaría a representar a Godot como una herramienta de desarrollo estable si rompemos la compatibilidad con (con suerte) muchos juegos geniales en desarrollo con Godot 4 .X.

La base de usuarios de Godot se duplica más o menos cada año, por lo que cada año que pasa hace que la refactorización sea menos realista, ya que finalmente la inercia de una gran base de usuarios supera los beneficios de romper la compatibilidad. Si otros motores como Unity o Unreal parecen relativamente estables en términos de API en comparación con Godot, no es porque no tengan cosas que les gustaría refactorizar o renombrar, sino porque no pueden permitírselo. Todavía podemos, por ahora, así que tenemos que aprovechar la oportunidad. Fue lo mismo para Godot 3.0 y la comunidad salió relativamente ilesa, aunque tenemos una pequeña proporción de usuarios que se apegan a 2.1 ya que no pueden permitirse la migración a 3.0. Para 4.0, el alcance de esos cambios debería ser mucho menor, y cualquier trabajo de migración debería ser sencillo, pero la comunidad se ha multiplicado mientras tanto, por lo que el impacto de cualquier ruptura de compatibilidad será tan grande o mayor que para 3.0 en términos de imagen / molestia acumulada del usuario :)

Soy un gran defensor de romper la compatibilidad.
Por qué no es un problema: si un desarrollador publica su juego en una versión anterior, luego sigue desarrollando en la versión anterior del motor, nadie está obligando al desarrollador a migrar a la nueva versión. Además: siga ofreciendo versiones anteriores para descargar exactamente para este propósito.
Se pueden iniciar nuevos proyectos en la nueva versión del motor y luego se trata de si el desarrollador tiene la paciencia para volver a aprender cómo funciona el motor.
Cuando se trata de mejorar la usabilidad del motor, la paciencia para volver a aprender nunca debería ser un problema, si el objetivo es convertirse en el motor más potente o fácil de usar.

En cuanto a los cambios de nombre, ayuda a reducir la curva de aprendizaje si hay patrones en el material que se debe aprender. Por ejemplo, Node2D vs Node3D, etc. para todos los demás nodos. Si parece un pato, ya sabes cómo va, lo más probable es que sea un pato o un nodo en este caso.
El cerebro humano funciona como una computadora cuántica de optimización, que aprende conectando los estados de energía más bajos de los sistemas entre sí para crear caminos lógicos entre las ideas. Si las ideas a aprender son similares, sus estados de energía más bajos están más cerca entre sí, lo que hace que sea más fácil conectarlos (y recordarlos), lo que explica por qué es más fácil para un estudiante comprender el 3D si se le ha enseñado 2D de antemano. . Si los nombres de los nodos reflejan la similitud entre ellos, también es más fácil aprender y comprender cómo se debe usar un nuevo tipo si hay conocimiento sobre un tipo similar.

Le digo que siga adelante, refactorice y rompa la compatibilidad de la forma que desee. Incluso si pierde pocos usuarios, obtendrá muchos más gracias a una mayor facilidad de uso y una curva de aprendizaje reducida.

En relación con esto, tome Blender 2.80, por ejemplo. Compare cómo se ve y se comporta ahora con lo que era antes. Es un cambio importante que obliga a muchos desarrolladores a volver a aprender cómo funciona el software. Ahora piensa cuántos usuarios tiene Blender. En comparación con Godot, son gigantes, pero de todos modos cambiaron drásticamente su software. ¿Por qué? Porque a largo plazo, siempre es más rentable reducir la curva de aprendizaje y mejorar la facilidad de uso, incluso si eso significa perder algunos usuarios que no tienen la paciencia para realizar la transición al nuevo flujo de trabajo.

A fin de cuentas, no estoy a favor de un cambio radical en este caso.

Puedo entender la frustración que siento con las convenciones de nomenclatura que han crecido orgánicamente, pero no veo ninguna que justifique del todo un cambio radical y de gran alcance.

Estoy totalmente a favor de desaprobar las API de las que deseamos alejarnos (y marcarlas en el momento de la compilación y en los documentos), pero lo ideal es que los nombres de los nodos antiguos sigan funcionando como antes.

Quizás, dentro de unos años, podamos preguntarnos si es hora de descontinuar los nombres de nodos heredados, ya que se ha vuelto completamente indoloro. Hasta entonces, mi sugerencia sería agregar nuevos nombres según lo desee (no tengo una opinión sólida al respecto) y evitar romper la compatibilidad con versiones anteriores.

@fracteed En realidad, tener profundidad en un canal de otra textura probablemente no sea una gran idea, porque el mapeo de paralaje hace muchos toques en esa textura, lo que obliga a obtener RGB innecesariamente cada vez. Si usa una única textura en escala de grises, Godot la comprimirá a la mitad del tamaño, lo que le ahorrará algo de ancho de banda.

Tener un modo ORM en el material estándar también puede ser una buena idea, es necesario comprobarlo.

@chucklepie El problema es que no todos los lenguajes admiten alias de clase como typedef. C # es uno de ellos.

@reduz ah, no me di cuenta de eso, es bueno saberlo. El problema más importante es cambiar el canal de profundidad a la altura de 4.0, por lo que es de esperar que considere cambiar eso.

editar. lo siento Akien, acabo de ver tu comentario después de publicar esto ...

@neikeq El problema es que no todos los lenguajes admiten alias de clase como typedef. C # es uno de ellos.

No sé cómo se implementa la biblioteca nativa de C ++, pero me refiero más a un mecanismo para hacer esta decoración en el nivel nativo de C ++ para que no importe cuál sea el enlace de lenguaje ascendente. Si eso no es posible, los enlaces para cada idioma podrían adaptarse fácilmente a la suite (por ejemplo, usando atributos en C #, etc.).

@ gerald1248 Lea mi publicación, en ninguna parte mencioné que se

Soy un gran admirador del

Navegación -> Nagivagion3D

rebautizar. ¡Apoyo esta petición!

@reduz dijo:
@TwistedTwigleg Lea mi publicación, los proyectos 3.0 se abrirán bien en 4.0 si se agrega un sistema de compatibilidad interno.

Mi mal, me perdí esa parte del post.

Un sistema de compatibilidad interno ayudaría con la migración, y definitivamente me coloca más en el lado de la cerca de "hacer el cambio", especialmente si se combina con algo como # 23023. Es bueno saber que hay algo planeado para los proyectos antes de este cambio y alivia muchas de las preocupaciones que tenía sobre esta propuesta.

@Norrox dijo:
@TwistedTwigleg con respecto al lanzamiento de juegos 3d, eso es porque estamos esperando 4.0 y Vulcan 😎

Eso es justo.
Especialmente dadas las mejoras en el lado 3D de Godot que vienen en Godot 4.0, esperar podría no ser algo malo para los proyectos pesados ​​en 3D.

la diferenciación 3d y 2d ya tiene una consistencia clara . Los nodos 3d son de color rojo claro, los nodos 2d son azules y los nodos de la interfaz de usuario son verdes. siempre habrá usuarios que tengan problemas con los nombres. es un problema interminable y es un problema multiplicativo según el tamaño de la comunidad.

con respecto a los cambios sugeridos en el OP: los nodos 2d ya tienen un sufijo "2D" aplicado, lo que _inherentemente significa que sus contrapartes son 3d_.

sin embargo, estoy a favor de cambios como Label a TextLabel . ( @MuffinManKen hace un gran punto)

Estoy totalmente a favor de básicamente todo lo que hay aquí, pero con respecto a la pregunta "Sprite2D / Sprite3D", sugeriría dejar Sprite como Sprite, si no por otra razón que el sufijo 2D agrega una cantidad extra de desorden, IMO.

Como dice @girng , la diferenciación 2D / 3D ya es bastante clara debido a la codificación de colores, por lo que no necesitamos hacer un gran esfuerzo para evitar confusiones. Desde la perspectiva de un desarrollador de Godot, personalmente no disfrutaría tener -2D agregado a todos los nodos no renombrados en mi proyecto. :D

¿Es útil esa codificación de colores para las personas con diversas formas de daltonismo?
Definitivamente no es útil cuando está escribiendo código (en lugar de agregar nodos desde el cuadro de diálogo).

@reduz gracias por tu respuesta. Me doy cuenta de que es para una versión principal y, por lo tanto, está completamente bien en un sentido medio. Personalmente, evitaría hacer cambios como estos incluso para una versión principal, pero sé que tienes una mejor comprensión de si esto sería un problema o no. Solo estoy mirando el historial de grandes cambios en las versiones principales (python2 a python3, por ejemplo) y, por lo general, prefiero vivir con inconsistencias (o nuevos nombres de nodos más nodos antiguos y obsoletos). De cualquier manera, amo a Godot y seguiré usándolo, sin importar los cambios importantes que pueda haber.

Pero, de nuevo, siéntase libre de sugerir si prefiere algo más explícito y haga todo siempre 2D / 3D.

explícito es mejor que implícito.

Sin embargo, @girng @AlexHoratio Los nodos que tienen un color diferente en el editor no son útiles cuando estás escribiendo código. Creo que aquí es donde surge la confusión.

(Todavía no veo por qué Sprite3D necesita existir, otros motores solo usan mallas cuádruples para el mismo propósito, sería más fácil si Sprite fuera exclusivamente un término 2D).

@gimg , @AlexHoratio No olvides que el 4,5% de la población también es daltónica: pegado_out_tongue:

Creo que cambiar el nombre es una buena idea.
La transición de 2D a 3D será mucho más sencilla. Al menos para las personas que comienzan con 2D (y probablemente también al revés)

está claro que hay un problema y la comunidad cree que es una buena idea. Soy parcial con Godot y estoy demasiado apegado emocionalmente. Estar en este estado genera pensamientos que realmente no tienen sentido para los demás, pero que tienen perfecto sentido para mí, de una manera hermosa . difícil de explicar. gracias por dejarme expresar mis pensamientos

Estoy de acuerdo con el consenso general aquí de que vale la pena cambiarles el nombre por coherencia. En este momento, puede dar la impresión externa de que un conjunto de nodos es de "primera clase" y el otro es de "segunda clase", o tal vez incluso hackeado para que exista basado en el primero.

Personalmente, creo que Sprite -> Sprite2D sería una desafortunada víctima de un cambio de nombre explícito completamente riguroso, pero supongo que siempre puedo cambiar el nombre manualmente a Sprite en cada escena que hago hasta que me canse de ella.

Creo que es desagradable que CanvasLayer y CanvasItem no estén agrupados, y que Node2D esté dentro de CanvasItem con Control, como otros han señalado.

Sé que @ akien-mga dijo que esto es solo para el cambio de nombre de los nodos, pero creo que al menos el debate sobre position vs translation entra en juego aquí. Creo que el propósito de cambiar el nombre de los nodos es algo plano si sus API son significativamente diferentes (salvo las diferencias entre los sistemas de coordenadas y similares), por lo que definitivamente deberían ser iguales, sean lo que sean. Votaría por "posición" como camino a seguir aquí, hubo un comentario acerca de que es engañoso en comparación con la "traducción". Yo diría que la "traducción" es engañosa porque implica una transformación o movimiento en lugar de ser simplemente coordenadas. La posición es intuitivamente relativa, en mi opinión (no enderezas tus sillas con respecto a las direcciones de la brújula, lo haces con respecto a las paredes de la habitación).

Creo que las variables deben ser nombradas posición para ambos, pero las funciones translate deben permanecer, cambiando las funciones move_local en Node2D a translate_local , la documentación incluso lo llama traducir. Mantendría el uso de move para los nodos relacionados con la física, para distinguir entre movimiento físico y traslación geométrica.

Gran parte de la segunda mitad de esto también es relevante para # 16863

También @reduz , creo que a medida que C # gane funcionalidad en el motor, más y más personas querrán espacios de nombres para C #, y una vez que estén en C #, puedo imaginar a muchos usuarios de gdscript queriendo usarlos y no tener que cambiar de idioma. por la funcionalidad. Sin embargo, creo que los espacios de nombres son completamente esenciales para el eventual soporte de C #, para gdscript los beneficios son mucho menos dramáticos, pero hará que los paquetes plug and play sean posibles sin la preocupación del usuario.

Solo pensé en una idea, si esto se implementara, podríamos tener una configuración de editor llamada "Nombres de nodo simples", lo que significa que los nodos recién creados carecen del sufijo en su nombre, por ejemplo, crear un nuevo "Whatever2D" establecería su name a "Whatever" pero los scripts en ese nodo todavía dirían "extiende Whatever2D", etc. Sería lo mismo que hacer un nodo y luego renombrarlo manualmente.

Esto evitaría el desorden de ver nombres predeterminados "2D" o "3D" en la Jerarquía si el usuario elige habilitarlo, pero aún así el código sería más consistente y explícito. Sin los nodos 3D que contienen "3D", esto sería confuso, pero tendría sentido con "3D" al final por defecto.

@aaronfranke Creo que es una idea bastante sólida. Parece un compromiso que permite mantener la base de código coherente y clara al mismo tiempo que permite a los usuarios mantener el exceso de desorden fuera de su jerarquía. Creo que muchas de las objeciones a la idea de cambiar el nombre provienen del efecto que tendrá en las jerarquías, en lugar de una objeción a los nombres en sí.

@aaronfranke Odiaría ser el que estropea una idea sensata, pero diferentes nombres de nodo entre diferentes sistemas harían imposible compartir archivos de script gd. Dado que todos los complementos se exportan como archivos y escenas gscript sin procesar, dejarían de funcionar si se desarrollaran en un sistema con diferentes asignaciones de nodos. Para evitar esto, todos los archivos gdscript y los archivos de escena deberían incluir asignaciones de nombres de nodo para traducir el archivo para el nuevo sistema. Estoy bastante seguro de que este tipo de gastos generales es un gran no para @reduz.

@aspenforest No creo que agregar un mapeo sea una gran sobrecarga, pero tal vez estoy siendo ingenuo ya que no conozco la arquitectura del motor

Lo que podría hacerse fácilmente con la idea de @aaronfranke es simplemente cambiar el nombre de los nodos en la creación. Similar a la configuración existente en ProjectSettings que cambia los nombres de los nodos recién creados a snake_case o spine-case (por lo que un nuevo nodo MeshInstance llamaría automáticamente mesh_instance lugar de MeshInstance ), se podría agregar otra configuración para los sufijos de nodos, lo que eliminaría el sufijo "2D" o "3D" de los nombres de los nodos (por lo que un nuevo nodo Sprite2D se nombra solo Sprite ).

Nadie se ha quejado nunca de que KinematicBody2D o Particles2D y similares tengan un sufijo "2D" innecesario, así que no veo por qué deberíamos agregar funciones para evitar la adición de un sufijo "3D" en sus contrapartes ... Si los usuarios realmente no quieren que estos sufijos estén allí en primer lugar, entonces esta propuesta tal vez debería descartarse, no solucionarse con una forma de cambiar el nombre de los nodos en el IDE por alguna razón cosmética ...

@ akien-mga esto no sería tanto "trabajar alrededor" de los nuevos nombres de los nodos, para mí es más la salsa en la parte superior, algo que solo no es hacky con un esquema de nomenclatura consistente. QUIERO los sufijos allí, para cuando estoy codificando, agregando nodos o buscando documentación. Pero una vez que están en una escena, sé lo que son, y muchas cosas obtendrán nombres personalizados de todos modos.

Si tuviera que elegir entre hacer que los nombres sean consistentes y obtener una función de editor para simplificar los nombres, elegiría lo primero, pero creo que @aaronfranke estaba entendiendo el hecho de que cualquier objeción a esta propuesta era fundamentalmente cosmética. y su sugerencia aborda que, si bien no cuesta nada de la consistencia subterránea, esta idea realmente se trata.

Definitivamente creo que agregar la función del editor sería su propio problema / pr, no algo necesario para incluir esto.

Inicialmente evité SpatialMaterial porque tenía un nombre extraño. Pero es una clase tan poderosa. En su lugar, comencé a aprender a codificar sombreadores con albedo + ao + normales mapeados triplanar. Luego descubrí que todo el trabajo que había hecho fue en vano, ya que podría haber hecho todo eso en SpatialMaterial y luego convertirlo en código y obtener un mejor resultado. Entonces necesita un nombre más amigable.

+1 para nombres explícitos 2D / 3D.

Tengo una pregunta sobre un nodo que supongo que puede estar marcado para desaprobación en el futuro, y la existencia de quién puedo imaginar podría ser confusa desde el punto de vista del nombre. Desde que cayó el nuevo sistema de animación, ahora tenemos dos nodos, uno llamado AnimationTree y AnimationTreePlayer que básicamente no tienen relación entre sí en absoluto. ¿Alguna idea sobre cuál podría ser la mejor manera de abordar esto?

@SaracenOne Este no es el lugar adecuado para hacer preguntas como esa. Perdón. Este hilo es solo para discutir el sufijo 2D / 3D.

Hay otro problema para discutir los cambios de nombre de manera más general https://github.com/godotengine/godot/issues/16863

Tuve un pensamiento que probablemente estaría más allá del alcance de la ruptura de compatibilidad aceptable para 4.0 y, por lo tanto, probablemente sea simplemente inviable / inaceptable, pero pensé que lo mencionaría para ver si alguien con más experiencia que yo me gustaría comentar.

Imaginé que todos estos nodos 2D / 3D podrían heredar de un solo tipo de nodo que sea 2D o 3D. La API para dicho nodo contendría todas las funciones que esperaría para cualquiera de las versiones, y su implementación dependería de si esta en particular era 2D o 3D.

En teoría, tal sistema podría:

1. Asegúrese de que estamos creando API consistentes entre sus contrapartes 2D / 3D. Esto es tanto un beneficio como un inconveniente como lo veo, ya que a pesar de esta consistencia, puede haber cosas que no es necesario incluir en uno, pero sí en el otro.
2. Facilite la interacción de los dos tipos diferentes o la creación de scripts personalizados que desea adjuntar a las versiones 2D y 3D de un nodo.

Sería bueno para evitar una situación en la que "SomeClass2D tiene implementadas x, y, z pero no hay nada como eso para SomeClass3D" y resuelve el problema de nombres de una manera diferente. Esto probablemente sea monumentalmente estúpido por algunas razones en las que no estoy pensando en este momento, pero pensé en tirarlo por ahí.

@vortexofdoom Eso ya es lo que pasa. Node2D es heredado por todos los nodos 2D y Spatial es heredado por todos los nodos 3D. La pregunta es cómo llamar a todo.

Y, lo que es más importante, tanto Spatial como Node2D heredan de Node .

Yo diría que todavía hay algo en la idea de @vortexofdoom que no está cubierto solo por la jerarquía de clases, pero no puedo determinar exactamente qué es.

Me pregunto: ¿cree que sería beneficioso agregar un sufijo - Res a todas las clases derivadas de Resource ?

@aaronfranke Me refiero a la idea de tener UNO de cada tipo de nodo (simplemente KinematicBody o Sprite), y el superior es una especie de Node2D3D que dicta su comportamiento. Lo siento si eso no fue explicado bien. Entonces, en lugar de tener una jerarquía 2D y una jerarquía 3D, tendríamos una jerarquía 2D / 3D. Por eso dije que sería una refactorización más grande de lo que probablemente sea aceptable.

_Podría_ funcionar si los tipos básicos no se pueden usar por sí solos, pero deben implementarse como 2D / 3D para que sean un nodo real, en cuyo caso volvemos al punto de partida en los nombres de los nodos, pero la herencia es más automáticamente directo y relacionado entre el 2D y el 3D y la interacción entre los sistemas sería aún mejor (creo).

@vortexofdoom Pero en realidad nada se comparte entre 2D y 3D. Pueden tener algunos de los mismos tipos de nodos y los mismos nombres de métodos, pero casi todas las implementaciones son completamente diferentes. Lo más compartido que podría esperar sería una interfaz, ya que su idea involucraría if (is2d) { do 2d stuff } else { do 3d stuff } y haría que los archivos de código fueran dos veces más largos y muy ilegibles sin ningún beneficio.

La viabilidad de clases únicas con comportamiento variable definitivamente depende de cuánto trabajo pesado podría hacer ese nodo 2D / 3D de nivel superior, enviando abstracciones más abajo. Combinar las clases tal como existen ahora definitivamente no valdría la pena, estoy seguro. Sin embargo, no me importaría el uso de interfaces para lograr la reorganización, todavía impondría al menos algún nivel de estandarización para los diferentes tipos.

La idea fue impulsada por un deseo ocioso de poder heredar de una versión general de un nodo para no tener que implementar todo dos veces en un proyecto en el que tenía una versión 2D y 3D ejecutándose en paralelo. En este momento, tendrías que heredar de node y hacer algo de conversión para hacerlo de cualquier manera, ya que node es el único ancestro común.

Creo que un Node2D3D (soy consciente de lo ridículo que suena) tendría algún valor, aunque solo sea como una forma de hacer que los dos sistemas de coordenadas funcionen mejor entre sí, pero eso se está acercando a una pregunta de diseño completamente diferente que este hilo. Perdón por desviarme.

@RandomShaper Definitivamente podría ver el beneficio de eso, especialmente si tenemos esa opción de nombres simples.

Dejo mis comentarios para la posteridad, pero me retracto de mi sugerencia a favor de un esquema estricto de nomenclatura 2D / 3D, dejando la jerarquía tal como está.

La razón es que cambiar el nombre de todos los nodos liberaría todos esos nombres de clase para el uso del usuario, lo que significa que podría implementar la funcionalidad que estaba buscando creando mi propio conjunto de clases como KinematicBody o CollisionObject que podría extraer la funcionalidad relevante y transmitirla.

Pero incluso fuera de ese caso límite, le permitiría crear clases como Area lugar de idear algo como RoomGroup como ejemplo rápido.

Estoy bastante contento de que se esté discutiendo esto. Espero que se haga.

No sé si se ha dicho, pero si se cambiará el nombre de las cosas para mantener la coherencia, también podría hacerlo con total coherencia (como sea humanamente posible) y también cambiar el nombre de ciertos métodos.

Ejemplo:

Geometry.get_closest_point_to_segment()    # <-- this is the 3D version
Geometry.get_closest_point_to_segment_2d()

Además de los nodos y los métodos, ¿qué pasa con las estructuras de datos? Supongo que Transform cambiará el nombre a Transform3D para alinearse con Transform2D , pero Basis probablemente no necesite ser Basis3D porque no hay Basis2D ya que todo está incluido dentro de Transform2D .

@RandomShaper

Me pregunto: ¿cree que sería beneficioso agregar un sufijo - Res a todas las clases derivadas de Resource ?

Parece un poco demasiado para el dinero. Prefiero votar para incluir Recursos en mi sugerencia (# 31054) para resaltar el código, tbh. Tenerlos en un color diferente reflejaría su tipo base tan pronto como termine de escribir el nombre de la clase (al igual que con los tipos integrados como Vectores y AABB).

¿Qué pasa con proyectos separados en 2D y 3D?

(En la sugerencia de imagen para reemplazar 2d con UI y 3d con Scene).

Cuando comienzas el proyecto, seleccionas en cuál trabajarás.
No se necesitan más sufijos (2D, 3D) en los nombres de las clases.

Entonces, de esa manera se están creando tipos de espacios de nombres, y no más mezclas entre esos tipos:

usando Godot2D;
usando Godot3D;

Cuando esté en un proyecto 3d o 2d, haga clic en la interfaz de usuario que tiene una ventana de la interfaz de usuario (2D) para editar la GUI, al hacer clic en Escena, está en la escena (2d o 3d depende del tipo de proyecto).

De esa manera mantenemos el modo 2d para la interfaz de usuario en cualquier proyecto, pero Scene abre una ventana 2d o 3d

En esta ventana solo estarán disponibles las entidades relacionadas con el tipo de proyecto (2d o 3d) o compartidas si se utilizan en ambos

Cuando está en el modo de interfaz de usuario, la adición de un nuevo nodo muestra esta ventana solo con los componentes relacionados con la interfaz de usuario.
Cuando en el modo Escena no se muestran los controles de la IU, solo las cosas que puede aplicar a la escena

@dmitryuck Para la imagen que publicaste, el botón 2D siempre es necesario, ya que incluso los juegos 3D necesitarán usar el modo 2D de Godot para interfaces de usuario y demás. Y es deseable poder mezclar 2D y 3D de todos modos. Técnicamente, los juegos 2D no necesitan usar el botón 3D, pero apenas es necesario ocultarlo.

Sugerí anteriormente que podemos hacer que los nombres de los nodos se cambien cosméticamente en la jerarquía para evitar sufijos visualmente innecesarios, pero sería mejor si el código siempre fuera explícito.

@aaronfranke He agregado una explicación un poco amplia de lo que quise decir en mi comentario anterior.

Creo que mostrar los nombres de los nodos de manera diferente según las circunstancias agregaría confusión.

Las personas deberían poder comprender los guiones y los árboles de escenas a primera vista. Creo que es imprescindible para la colaboración, tutoriales claros, etc.

@dmitryuck Sin embargo, algunos proyectos pueden requerir la mezcla de 2D y 3D, y algunos juegos tienen interfaces de usuario en 3D.

@Skaruts es posible cambiar a la vista 2d en una escena 3d implementando un componente como en este editor

El modo de interfaz de usuario, por supuesto, tiene que estar presente en ambos tipos de proyectos, pero puede ser una ventana separada con herramientas especialmente diseñadas para la interfaz de usuario, como una cuadrícula, ajustes mejorados, reglas, etc.

@reduz Cambiar el nombre es algo bueno, pero debería haber un período de transición largo, por ejemplo, de 4.0 a 5.0, ya que hay muchos tutoriales y respuestas obsoletos de https://godotengine.org/qa

@xxmatxx Preferiría que el cambio de nombre ocurriera con un período de
Además, me aseguraría de documentar bien los cambios y de que las personas que se están quedando atrapadas en Godot conozcan los cambios. Una advertencia en el editor que le informa que está utilizando la versión obsoleta de los nombres de los nodos también será útil en caso de que algunos se olviden de esto.

Estoy de acuerdo, cuanto más tarde, más tiempo tendrá la posibilidad de confundir a la gente. Los tutoriales y los documentos no se desactualizarán de inmediato si, como sugirió @AtomaFajrovulpo , durante un período de tiempo el editor aún permite las cosas obsoletas pero dispara una advertencia. Algo en esta línea supongo:

Node type 'Spatial' is deprecated and replaced by 'Node3D'. 

y

Method 'clip_polygon()' is deprecated and replaced by 'clip_polygon_3d()'. 

Ayer descubrí que las constantes no siguen el mismo caso. Por ejemplo, hay Color.black y Vector3.UP . ¿No debería hacerse coherente para 4.0?

@BenjaminNavarro El cambio de las constantes de color a mayúsculas también se discutió en la parte inferior de https://github.com/godotengine/godot/pull/14704.

Además, el cambio de nombre de método / señal / constante debe discutirse en # 16863, ya que este problema se trata específicamente de nombres de nodos.

@Calinou Gracias, estaba bastante seguro de que había otros problemas, pero no pude encontrarlos.

Preferiría cambiar el nombre en 4.0 y terminar con eso, sabiendo que vendrá más tarde, después de que el proyecto en el que estoy trabajando haya crecido más.

si un lanzamiento importante no es el momento para hacerlo, ¿cuál es?

SemVer: Dado un número de versión MAJOR.MINOR.PATCH, incremente:
Versión PRINCIPAL cuando realiza cambios de API incompatibles,
Versión MINOR cuando agrega funcionalidad de una manera compatible con versiones anteriores, y
PARCHE la versión cuando realiza correcciones de errores compatibles con versiones anteriores.

¿Hasta dónde llegarás con esto?

Entonces, ¿GridMap se convertirá en TileMap3D y, por ejemplo, en Tilemap Tilemap2D?

Además, node2D y node3D parecen un poco genéricos, ¿por qué no tener Spatial2D y Spatial3D entonces?

Creo que una gran diferencia de UX también sería tener control, node2D y espacial, cualquiera que sea su nombre, directamente accesible debajo del nodo en el cuadro de diálogo del nuevo nodo, aunque node2D y el control heredan de CanvasItem. No puede agregar un CanvasItem directamente a un árbol de todos modos, por lo que tal vez no debería estar visible en ese cuadro de diálogo.

Y en lo que respecta a los métodos, supongo que no es necesario agregar un sufijo 2D o 3D en ellos, ya que sabes cómo los llamas, ¿verdad?

Todavía espero hacer algunas actualizaciones útiles, como abordar la importación lenta de recursos y la optimización del rendimiento de los scripts de GD. En la actualidad, se tarda aproximadamente una hora en importar recursos de 1G. Si importa recursos 10G, debe sentarse frente a la computadora y dormir durante dos días. Sin embargo, el navegador del sistema de archivos del editor de recursos de la importación 700M-1G ahora está roto y no se mostrará nada. Lista de archivos, estas pueden ser las deficiencias del propio editor, por lo que creo que optimizar y resolver los problemas existentes es la mejor manera para Godot. Si solo puedo importar de 100 a 500 millones de recursos, entonces está destinado a que Godot no pueda desarrollar juegos grandes, pero mi camino ahora está bloqueado y no puedo seguir adelante. Espero que la próxima versión resuelva tales problemas, ¡le deseo a Godot cada vez mejor!

@ qq715152910 Por favor, no comente sobre hilos largos con información completamente no relacionada. Todos los que hayan comentado sobre este tema recibirán un ping y su comentario no tiene nada que ver con la propuesta de cambiar el nombre de los nodos. Como resultado, ocultaré tu comentario.

Daré nuestra opinión sobre algunos cambios de nombre que nos serían útiles (usamos C # principalmente)

El cambio de nombre que sugerimos encarecidamente:

1. Transform.origin -> transform.origin

(Hacer el acceso a una propiedad de transformación en minúsculas)

¿Por qué?
Por ejemplo, el espacial tiene la Transformación a la que podemos acceder, pero muchas veces escribimos "this.Transform.origin" para una mejor legibilidad, si cambiamos "Transform" a "transform", no necesitaríamos usar "this" all el tiempo. Ésa es nuestra opinión personal.

1. También apoyamos el cambio de "Etiqueta" a algo como "TextLabel". O al menos cuando buscamos por "texto" al agregar el nuevo nodo, debería aparecer "Etiqueta", ya que está totalmente relacionado.

2. Se debe acceder a las constantes para algunos colores predefinidos con Color en contraposición a Colors .

Para el resto de la propuesta de cambio de nombre, esperamos lo que la comunidad crea que es mejor.

AtlasTexture -> TextureAtlas

Se llama AtlasTexture porque sigue la convención habitual <Type>Texture donde <Type> puede ser Image , Viewport , Stream ,…

AtlasTexture -> TextureAtlas

Se llama AtlasTexture porque sigue la convención habitual <Type>Texture donde <Type> puede ser Image , Viewport , Stream ,…

Esto es lo que aparece cuando escribo "Atlas".

Esto es lo que sucede cuando escribimos Textura:

Editar: Entendemos por qué esa convención. En la segunda captura de pantalla, AtlasTexture está muy abajo con otras cosas que siguen la convención <Type>Texture . Después de eso, ese punto fue eliminado de nuestra publicación anterior. Para este caso en particular, todavía no es muy amigable con el autocompletado. Pero lo aceptamos. .

@bigmonte El Transform estructura se puede cambiar el nombre a Transform3D en Godot 4.0 de acuerdo con este tema, por lo que ya no necesitará this. para dejar claro que se trata de una propiedad.

EDITAR: https://github.com/godotengine/godot/pull/38430

Se debe acceder a las constantes para algunos colores predefinidos con Color a diferencia de Colors .

Yo fui el que propuso eso en primer lugar, y estoy totalmente en desacuerdo. Es mejor mantenerlos separados, ya que aumenta la capacidad de descubrimiento de los miembros estáticos de Color (actualmente Color8 , ColorN y FromHsv ) cuando se usa la función de autocompletar en varios IDE. También estoy considerando proponer un cambio de nombre de Color.red etc -> Colors.RED en GDScript para mayor coherencia.

Por cierto, creo que estabas buscando el número 16863.