#38 Yo diría más las steam machines y cuando microsoft amenazó con vallar su windows y hacer que todas las aplicaciones fueran por su tienda. Valve le vio las orejas al lobo y quiso dinamizar y consolizar el mercado para ampliarlo y no depender de windows; el proyecto fue fallido, pero permitió poner en primer plano las limitaciones existentes y darles un toque a los fabricantes (amd estaba en plena transición de drivers y negocio sobre soluciones de software libre, sus drivers daban bastante pena y las cosas potentes y novedosas que se habían sacado de la chistera no les funcionaron por falta de soporte de desarrolladores y de sus propios equipos internos, les pilló en muy mal momento) y replantearse cómo animar a los desarrolladores

Eso es lo que ha llevado a donde estamos ahora: plataforma semiabierta con muchas ventejas y la más completa del mercado sobre SO completamente abierto y un hardware lo más abierto posible, que permite a la gente trastear y desarrollar un ecosistema de aplicaciones propias y optimizarlas sin ningún impedimento o cortapisas. Y eso sin forzar a nadie a elegir desarrollos nativos, con una capa de compatibilidad con windows que asegura que sea fácil y barato que tus juegos funcionen y que si quieres apoyar más directamente el hardware, tengas todas las facilidades para hacerlo (librerías, código, especificaciones abiertas, etc).

#169 en lo de que lo que hizo a Valve moverse fue el interés de Microsoft por empujar el uso de su tienda, totalmente de acuerdo.

Lo que me gusta de esa capa de compatibilidad, es que puede ser adaptada para juegos de hace 20 años, de hace 10, y actuales. Es una forma de mantener una biblioteca de juegos durante toda tu vida.

#174 Hay juegos de windows que no funcionan en windows y si en linux...

De todos modos, no es una bala mágica, muchos dependen de implementaciones específicas de ciertas cosas (o sea, se programaron con librerías que tenían bugs de forma que se aprovechaban de ellos o los ignoraban y seguían a sus cosas). Es imposible cubrir todos los posibles casos y hacer que todo funcione (en parte porque la solución sería parchear las aplicaciones que no funcionan bien, no poner mil excepciones en la emulación de esas librerías para cubrir todos los casos).


Fíjate la que se ha armado porque AMD en sus últimos drivers, para poder ampliar el número de juegos que soportan su FSR3 (que como los DLSS, necesita que sean incorporados dentro de los propios juegos, no son una simple "capa" de post procesado) se le ocurrió que los drivers podrían coger e inyectar ese código directamente en los juegos en tiempo de ejecución (así, sin necesidad de que los juegos soportaran FSR 3.0, podías tener FSR gratis). El problema es que ciertos medios y controles antipiratería validan que el ejecutable del juego sea íntegro y no haya sido modificado (para filtrar a los hackers que hacen trampas modificando el propio juego y demás) y esto ha cantado por todos lados y muchos han sido baneados... pero vamos, lo suyo sería eso, parchear el propio juego (algo así como lo que hace gog para que ciertos juegos antiguos puedan funcionar en equipos nuevos).

#187 eso implicaría trabajo por parte de las desarrolladoras, y visto como está la industria acaba siendo complicado.

Pero sí, sería lo mejor.

#27 Sí, el futuro no sé como será, pero en la actualidad las ofertas de trabajo indies o de empresas medianas y grandes con Godot son 1% tirando por lo alto frente a las otras.

Y no interpretarme mal, ojalá triunfe Godot, a más productos más competencia, y para el usuario eso es bueno.

#6 yo ya llevo 4 meses de trabajo a tomar por culo. He empezado en godot. No estoy comodo, pero no queda otra. El gasto emocional que dices es el peor. Aunque también me da tiempo a refactorizar ahora que tengo claro el foco de mi juego.

Y lo peor es que apenas empecé hace 2 años a aprender unity. En qué mal momento quise dejar el sidoso gamemaker por esta basura

#35 pues para recular ya han puesto que el editor requiere que estés conectado online siempre

#38 empiezan, y veremos hasta donde.

#38 Bueno, afortunadamente a no ser que te hayas metido en historias tipo objetos parametrizables, interfaz gráfico de shaders, etcétera, la lógica que hay detrás donde un nodo es un GameObject es muy similar.

También es un buen momento para plantearse colaborar, Godot parece bastante abierto a que si necesitas algo y lo programas se añada al engine principal.

#40 por lo general sí, todo parece muy sencillo hasta que te metes en el ajo y empiezas a ver las diferencias. La capa de networking de Godot está bien, pero veo que faltan muchas de las características que tenía netcode/fishnet en unity. No hay apenas información y la documentación es errónea, lo cual no ayuda. Lo bueno es que los shaders que tengo son en código y esos te los importas facilmente

Tampoco ayuda que intenten impulsar que uses gdscript pero no existan plugins oficiales para programar con IDEs externos, cuando su editor de código dista de ser potente careciendo de cosas elementales como refactor. Para godot la filosofia es que tienes que programar menos, y por tanto no necesitas tantas herramientas. Por tener no existe ni un REPL para debugger en gdscript. Al final la versión de .net está mucho mas preparada para esta tarea. Pero bueno ya veremos _al tiempo..._

#43 Sí a ver, también es mi primera impresión; también hay cosas en las que tengo mis dudas, pero a primera vista al menos me ha animado ver que la manera en la que estructuras las cosas es similar, con lo que el paso no tiene por qué ser tan traumático.

Con el tema shaders me pasa igual, y tengo la esperanza de que como soy muy de programar a mano todo, no habrá nada insalvable.

La otra opción es también echarle un vistazo a Unreal Engine, pero tras la puñalada me tira más el código abierto, y además lo mío son las 2D.

Eso sí, donde falta documentación o características, quizá sea el momento de hacerlas. Quizá es muy optimista respecto al tiempo disponible y demás, pero también es posible que con la gran migración que puede producirse a partir de ahora pase a haber mucha más gente mirando y programando el propio Godot.

#44 > Con el tema shaders me pasa igual, y tengo la esperanza de que como soy muy de programar a mano todo, no habrá nada insalvable.

Ese es el miedo que tengo. Tanto unity como godot se esfuerzan en que pierdas el tiempo diseñando haciendo clicks en cositas controles y ventanitas. Si tengo la oportunidad de huir de Unity es puramente porque evito ese patrón todo lo que pueda, al menos en las cosas mas core del sistema. Pero al menos Unity saben que la batalla de montar un editor de texto la tienen perdida y la integración con editores externos es perfecta. Godot tienen una opinión mas fuerte con esto viendose completamente desinteresados en tomar una posición oficial para brindar soporte a estas cosas.

De todas formas entiendo que son chorradas mías y la amplia mayoría de desarrolladores se encontrarán cómodos con ese editor, pero en mi caso vengo de tantos lenguajes distintos que siempre acabo usando Jetbrains para todos, y me incomoda que Godot se resista

> La otra opción es también echarle un vistazo a Unreal Engine, pero tras la puñalada me tira más el código abierto, y además lo mío son las 2D.


Si me voy a godot es para no volver a darle mi expertise de un sistema de programación de videojuegos a una empresa privada. Además que las fees de Unreal son incluso mas caras que si Unity añadiera el install fee.

Espero que este impulso lo haga crecer una barbaridad y el toolset crezca. Tienen que convertir su documentación en una wiki y por dios, dejar que todo el mundo pueda hacer repuntes auditados que puedan ir integrando con un grupo de moderadores.

#45

Ese es el miedo que tengo. Tanto unity como godot se esfuerzan en que pierdas el tiempo diseñando haciendo clicks en cositas controles y ventanitas. Si tengo la oportunidad de huir de Unity es puramente porque evito ese patrón todo lo que pueda, al menos en las cosas mas core del sistema.

Totalmente de acuerdo, por esa forma de trabajar tengo ciertas esperanzas. Y con el tema del IDE me pasa igual, aunque como no suelo usarlo con una integración muy fuerte creo que saldré del paso.

Si me voy a godot es para no volver a darle mi expertise de un sistema de programación de videojuegos a una empresa privada. Además que las fees de Unreal son incluso mas caras que si Unity añadiera el install fee.

Sí, supongo que la diferencia es que las de Unreal aunque más caras (en buena parte de los casos) son previsibles.

Pero hay un detalle que me escama, y es que Unreal Engine solo empezó a ser gratuito hasta cierto umbral cuando surgió la competición de Unity. Si como es bastante esperable Unity se va a tomar por saco, es muy posible que Unreal Engine acabe endureciendo las condiciones. Para hacerlo de manera tan rata como pretender cobrar de manera retroactiva necesitas a un ex-CEO de Electronic Arts, pero fíate tú. En todo caso podría significar que acabes limitado a ciertas versiones de Unreal con lo que tampoco es una inversión a largo plazo.

#35 Thank you for your honest and critical feedback

Qué cachondos, dicen que llueve ...