El hilo del ocaso de Unity

[swapd0]

Que moñas que es la gente, a ver si programan más en C con las SDL

[josepzin]

Ahí, ahí, pero la gente se ha vuelto muy vaga y quieren que un maker les haga todo el trabajo.

[TRaFuGa]

Le voy a pedir a ChatGPT que me cree un maker con el que pueda trabajar...y una vez lo tenga, le pediré que haga los juegos!

[Drumpi]

(...)
Con el tema de cambio de motor, totalmente de acuerdo con hardyx, pero con una excepción, una vez que aprendes Game Desing y conoces un motor, cambiar a otro cuesta mucho menos ya que suelen tener elementos comunes y definiciones "equivalentes", pasa lo mismo cuando cambias de un lenguaje de programación a otro (me pasó con el testing en PHP, cuando llegué a hacerlo en React que no lo había visto en la vida, el sistema era el mismo, por lo que no me costó mucho aprender esa nueva forma de hacerlo).
(...)

Estoy de acuerdo con la parte que he omitido. De hecho, el modelo de Unity era ese: más ganabas, más pagabas, pero claro, era responsabilidad de la empresa de desarrollo decir a cuánto ascendían las ganancias, y ahí cualquiera podía hacer trampas: "sí, he vendido 300000 unidades, pero si descuento las unidades gratuitas, las de prensa y lo que hemos gastado este año en cafés viendo si las cifras subían, hemos ganado en total 100€".
Y sí, han perdido confianza.

Ahora bien, eso de que "cambiar de motor es sencillo" no lo tengo yo tan claro.
Por un lado, cambiar de lenguaje, aunque sean muy similares, siempre trae consigo una serie de herramientas que uno tiene y el otro no. Yo aprendí Java, y luego tuve que aprender C#, y aunque básicamente son iguales, hay muchas cosas en C# que no había ni olido en Java, como LinQ o el binding de variables, y sólo con eso me ahorro el tener que crear funciones para listas o andar actualizando la interfaz constantemente.
Por otro lado, al igual que existen los "false friends" en inglés (palabras en inglés, que suenan como otras en español, pero tienen un significado totalmente distinto...), también puede suceder con funciones en los lenguajes. Yo tengo que hacer constantemente doble y triple check para saber si el valor de tamaño declarado al crear un array tiene en cuenta el valor 0 o 1 a la hora de contar, según el lenguaje (y todavía me peleo con el do...while o el repeat...until o cualquier combinación).

Incluso dentro del mismo lenguaje: fíjate que llevo años haciendo WebApis para APPs móviles, y ahora tengo que hacer webs en .NET Core, que también tienen controllers, models y vistas... y mi tutor se empeña en que no debo mezclar conceptos, aunque se llamen igual.
Por eso digo, cógelo con pinzas.

Como contraejemplo, diré que el aprender a usar los procesos de DIV, me sirvió de mucho a la hora de enfrentarme a las instancias de Unity, que vienen a ser lo mismo, pero sin un "frame" que me las sincronicen.

Que moñas que es la gente, a ver si programan más en C con las SDL

Ahí, ahí, pero la gente se ha vuelto muy vaga y quieren que un maker les haga todo el trabajo.

Llevo años oyendo a programadores con mucha más experiencia que yo, diciéndome que deje de reinventar la rueda.
Y cuando hay un programa que gestiona los objetos por mi, que incorpora un motor de scroll ya hecho, y todas las funciones para detectar y hacer funcionar las colisiones... es decir, el 90% del código que se repite de un proyecto a otro, y ahora salís a decir que hay que ser flojo...
¡Iros a programar en ASM en una Atari 2600!



PD: ¿Por qué SDL y no OpenGL?

[swapd0]

¿Porque se supone que necesitas sonido en un juego?

[Drumpi]

¿Porque se supone que necesitas sonido en un juego?

No seas moñas y usa OpenAl u otras libs de sonido, y create tus rutinas de I/O

No, en serio, me estoy planteando probar a hacer algo con 3D y no sé si hacerlo con SDL u OpenGL... o si eso es demasiado bajo nivel. Quiero ver si se puede pasar XNALara a algo que no sea XNA, y creo que es más fácil empezar por algo ya medio hecho que empezar de cero ¿no?

[selecter25]

Te quitan 2 cosas, te "devuelven" 1 y parecen hasta buenos, "os hemos escuchado", xDD.

Lo que no dicen es que han quitado Unity Plus y han dejado solo el Pro. Antes por 400$ (Plus) tenías ciertos beneficios para devs pequeñitos, entre los que entraba quitar el splash logo de Unity de tu juego. Ahora si no quieres que tu juego lo muestre, te toca pagar 1800$ por la Pro, menudos genios.

[masteries]

Que moñas que es la gente, a ver si programan más en C con las SDL

Como todo lo hago en C, y a veces hay algo de ensamblador por debajo...
y estructuro el código para que todo funcione como Fénix/Bennu,
que para hacer juegos (y otros programas en Tiempo-Real)
es una manera comodísima de programar y organizar las cosas.

De hecho, si recuerdo bien, los integrantes clásicos de ID software (no el ID moderno)
lo han hecho todo en C, desde el primer Doom hasta el último.

[zhorro]

bueno, pa la obra me pidieron el diplomado de hormigonado en concreto

concreto de especifico o concreto de cemento?

[futu-block]

si...


y los demas, no darsela de tan chulo y programadores, no sabeis el calvario que es programar en binario con un telegrafo T_T

[josepzin]

Programar en binario usando el telégrafo es lo mas facil del mundo, solo tienes que darle como loco a la palanquita.

[fbustamante]

Eso, menos samba y más programar.



(Ya se que lo habíais puesto, pero esta es la versión resumida y ahora se ve. )

[swapd0]

Viendo la imagen es para hacer single-button-games para la gente mayor y te forras, suponiendo que sean capaces de descargar la aplicacion

[Drumpi]

Te quitan 2 cosas, te "devuelven" 1 y parecen hasta buenos, "os hemos escuchado", xDD.

Lo que no dicen es que han quitado Unity Plus y han dejado solo el Pro. Antes por 400$ (Plus) tenías ciertos beneficios para devs pequeñitos, entre los que entraba quitar el splash logo de Unity de tu juego. Ahora si no quieres que tu juego lo muestre, te toca pagar 1800$ por la Pro, menudos genios.

Cuando yo hice el Máster, con la v4 había cosas a las que no tenías acceso, como el occlusion culling, el Level Of Detail, o bakear las luces de una sala (una función que "pintaba" las luces y sombras en las texturas del escenario, y luego simplificaba las luces que recibía el prota según la zona). Todo eso se hizo gratis en la v5, por lo que no entiendo por qué han mantenido las cosas gratis, y han penalizado tan severamente los juegos sin licencia con éxito.
Si necesitan dinero, pueden volver a eliminar funcionalidad para atraer a más gente a su versión de pago mínima: una versión recortada gratis, una versión con muchas utilidades desbloqueadas por 30€-60€ al año, y mantener las licencias plus y pro. Yo creo que por ese precio, mucha gente que usa la gratis se apunta a la básica, igual que mucha gente que pirateaba se pasó a Netflix.

Yo creo que les hace falta dinero: Unity ha crecido más de lo que esperaban y no tienen recursos para dar tanto soporte... aparte que UE5 salió hace relativamente poco y les está comiendo mucha cuota de mercado.

Como todo lo hago en C, y a veces hay algo de ensamblador por debajo...
y estructuro el código para que todo funcione como Fénix/Bennu,
que para hacer juegos (y otros programas en Tiempo-Real)
es una manera comodísima de programar y organizar las cosas.

Esto es interesante ¡Cuénta más! por favor.

De hecho, si recuerdo bien, los integrantes clásicos de ID software (no el ID moderno)
lo han hecho todo en C, desde el primer Doom hasta el último.

Sí, ya ¿Hasta qué año? ¿Hasta el 2007, cuando hacer un juego medianamente grande es imposible hacerlo de cero sin una librería o un motor?
De hecho ¿el motor Source no nació de las herramientas de diseño que se usaron para hacer versiones de Doom o Quake de esos años, más o menos?

Eso, menos samba y más programar.

Jo ¿Y cómo comunico mis juegos con carpetas de red sin Samba?

[masteries]

Esto es interesante ¡Cuénta más! por favor.



Sí, ya ¿Hasta qué año? ¿Hasta el 2007, cuando hacer un juego medianamente grande es imposible hacerlo de cero sin una librería o un motor?
De hecho ¿el motor Source no nació de las herramientas de diseño que se usaron para hacer versiones de Doom o Quake de esos años, más o menos?

Empiezo por Doom; hasta Doom 2016 sé que está escrito en C+OpenGL y C+Vulkan;
el motor gráfico y de modelos (que tienen esqueleto claro) se escribió desde 0

todavía participó Carmack en este desarrollo, supongo que haciendo las funciones de
director de orquesta, e implementando aquellas partes en las que hacía falta una experiencia
en motores gráficos como la que tiene este señor.

También transmitió el mensaje de que la librería Vulkan te permite hacer cosas con el hardware
que tanto OpenGL como DirectX no te dejan, como crear nuevas fuentes de interrupción a nivel
interno en la tarjeta gráfica... bueno no hace falta decir mucho sobre lo bien que funciona
el motor de Doom 2016 bajo Vulkan; con un i5 de tercera generación y una RX 480 de 4GB;
a 1080p con todo en Ultra el juego se mantiene en más de 160 fps, abrasándose la RX 480
(siempre puedes activar el sincronismo vertical y quedarte con los fps que marque el
refresco vertical de tu monitor).


Así mismo se quejó de que con OpenGL no lograba sacarle el rendimiento que esperaba
al hardware de vídeo puntero en ese momento, pues no le dejaba plantear el funcionamiento
del dibujado en pantalla con las propiedades que Vulkan le estaba ofreciendo.



------------------------------


Ahora vamos a esto:

"Como todo lo hago en C, y a veces hay algo de ensamblador por debajo...
y estructuro el código para que todo funcione como Fénix/Bennu,
que para hacer juegos (y otros programas en Tiempo-Real)
es una manera comodísima de programar y organizar las cosas."


Te cuento de forma muy resumida:

Dado que le estamos dando duro a las máquinas antiguas; encuentras
funciones de vídeo para ellas; pero no dejan de ser algo relativamente básico,
te permiten dibujar sprites en pantalla y se encargan de gestionar los accesos
al cartucho cuando el frame del sprite cambia...


y ya está, no hay más; ni gestión de mapeados, ni durezas del mapa, ni colisiones entre sprites,
ni gestión del orden de dibujado, ni un mecanismo ni siquiera básico para que organices las funciones
que proporcionan funcionalidad a los sprites...


Todo eso te lo tienes que hacer a mano; así que después de mucho currar durante meses
en un motor 2D multiplataforma, pues tengo un repertorio de funciones como:

Identificador = EntitySpawn(tipo de entidad, posición x en el mapa, posición y en el mapa);

Identificador funciona como en Fénix/Bennu; te proporciona acceso a las variables internas
del proceso, que puede ser un sprite o no: Identificador.xworld , Identificador.yworld, Idenficador.layer,
identificador.health... y así


EntityRemove(Identificador);

Para eliminar un proceso de la lista de funciones tick a ejecutar.

Luego hay una lista de tick functions que se ejecutan al final,
dado que cada tipo de entidad declarada tiene asignada su función,
lo que viene a ser el process() de Fénix/Bennu

Y ya al final de todo, la lista de dibujado; ahora mismo dispongo de 6 capas
de dibujado; cada proceso tiene asignada una capa (layer) distinta.

En esa lista de dibujado también están los tiles de los planos de scroll;
en Atari STE y Megadrive, los planos de scroll son persistentes,
en el STE es un frame buffer del que debes limpiar los sprites, o parte
de los sprites si corresponde.

En MD la información sobre la posición de los tiles es persistente,
y o bien la actualizas (escribiendo y borrando valores de la tabla,
y si es necesario también escribes nuevos tiles encima de tiles
que ya no se muestren en pantalla).


En N64 tanto el mapeado como los sprites funciona todo igual,
todo son sprites o texturas colocadas sobre superficies definidas
por cuatro vértices; así que en cada pasada redibujas todo.
Con lo potente que es su adaptador de vídeo y CPU para dibujado 2D,
pierdes más tiempo en limpiar sprites del frame buffer,
que en redibujarlo todo.

El concepto de tablas con información de tiles para el mapeado
e información de los sprites es muy del mundo arcade de 16 bits;
y de MD y SNES; las máquinas de años posteriores perderían esas
capacidades hardware, pues son potentes, pero te limitan bastante
en lo que puedes llegar a hacer, pues están orientadas sólo a juegos 2D
y encajan mal con otros planteamientos de juego.