Dificultades para empezar, o "10 motivos por los que XNA apesta"

Tras el parón no intencionado de Eternal Showdown, y la pérdida de interés, he decidido comenzar lo que será el último intento de hacer un juego por mi cuenta.

Mi intención, como suele ser habitual, es centrarme en el desarrollo del juego y dejar los gráficos a un lado, intentando que sean aceptables y que no se inmiscuyan demasiado con el resto de la lógica. Ah, y todo en 3D.

Como ya sabrán los lectores, he hecho un jueguecillo más o menos completo en C# bajo Managed DirectX, el Little Racers, y he hecho dos o tres intentos de juego con el nuevo Framework XNA de Microsoft.

Mi intención inicial (y así empecé ayer) era hacer este nuevo juego bajo XNA, pero hoy he decidido que, simplemente, le pueden dar por culo a esa mierda. Así de simple.

Los motivos son varios y los cuento a continuación:

1. Dificultad para cargar nuevos objetos en tiempo de ejecución: El sistema utiliza (y en según qué casos obliga a utilizar) el llamado "Content Pipeline" para manejar los elementos artísticos del juego (gráficos, sonidos, etc.). Esto funciona de modo similar al código fuente de la aplicación: Se procesa en tiempo de compilación para mejorar el rendimiento en la ejecución.
   También permite introducir contenido en la Xbox 360 que en principio ésta no podría entender, por estar limitada en número y tipos de formato admitidos.
   La idea en sí no es mala, pero en algunos casos es obligatorio utilizarlo (en las texturas, por ejemplo, no es necesario, de ahí que pudiese hacer jueguecillos en 2D. Pero resulta que en los modelos 3D sí que lo es).
   Las consecuencias obvias de esto es que cualquier juego que quisiese permitir contenido modificado o personalizable (por ejemplo, añadir nuevas armas) no tiene en este momento dicha posibilidad.
   Al parecer existen ciertas ñapas para solucionar esto (básicamente, compilar el contenido a añadir), pero no son más que eso, ñapas.
   


2. Incapacidad para funcionar directamente con Windows Forms: En Managed DirectX, como en el DirectX de toda la vida, es posible combinar DirectX con el interfaz de ventanas de Windows. Esto es casi esencial para hacer editores, ya que evita el tener que reinventar la rueda programando un GUI en DirectX, además de que suelen ser bastante limitados y poco eficientes.
   De nuevo, esto puede deberse a la incapacidad de la Xbox 360 de mostrar dichos formularios. Y, de nuevo, existen ñapas para hacerlo funcionar, pero no son más que ñapas...
   


3. Se ha parado el soporte de Managed DirectX por culpa de XNA: XNA funciona de forma muy diferente a MDX pese a que las funciones básicas de dibujado y gestión de primitivas son muy similares. En esto XNA, al ser posterior a MDX, tiene la interfaz un poco más depurada y en muchos casos es incompatible (por ejemplo, en XNA está sobrecargada la multiplicación de vectores pero en MDX no).
   Aunque se puede seguir usando la versión 1.1 de MDX, el trabajo con vectores y demás resulta más engorroso que en XNA.
   


4. No se puede manejar el ratón en modo exclusivo: El modo de ratón exclusivo de DirectInput consiste en que la aplicación toma el control del ratón, dejando a Windows sin él de forma temporal (desaparece el cursor). Esto evita problemas de que se salga el cursor de la ventana si estamos en ese modo, y también que el ratón se considere detenido si llega a los bordes de la pantalla.
   XNA no permite este modo, y la ñapa correspondiente para evitar ambos problemas consiste en centrar de forma forzosa el puntero del ratón en cada frame, y ocultar el cursor a mano.
   


5. No es 100% compatible hacia atrás: Pese a que está basado en DirectX 9 , no permite utilizar el Fixed Function Pipeline, lo que obliga a utilizar Shaders hasta para la GUI. Cierto es que trae un Shader que funciona del mismo modo (un Shader 2.0 si no me equivoco), pero aún está por ver si ofrece el mismo rendimiento.


6. No permite utilizar gamepads que no sean el de la Xbox 360: De nuevo por asegurar la compatibilidad con Xbox 360, me imagino.


7. Mal documentado: Managed DirectX tenía una documentación mala, pero XNA le supera. Puede suceder que programas una ñapa para hacer tal o cual cosa, y luego resulta que XNA podía hacerlo pero en ningún sitio te lo decía


8. Poco feedback: Aunque en los foros hay bastante actividad, lo que son versiones de XNA tan sólo ha habido 3: la primera era más una preview que otra cosa, la segunda era la beta y la tercera un parchecillo que corregía los primeros bugs encontrados.
   De poco me sirve que en los foros me comenten la ñapa que soluciona el problema, yo quiero que el soporte para cargar .X on the fly esté en el Framework oficial. Y ya he dado mi voto en la sección correspondiente.


9. Parones en Xbox360: Al parecer el recolector de basura en Xbox360 es peor que el que tiene la máquina virtual de Windows, y cuando hace falta liberar memoria, se sufren parones considerables


10. Es necesario instalar el Framework de XNA en el cliente: Para ejecutar las aplicaciones creadas con XNA, es necesario instalar un runtime en los clientes. Esto también sucede, tristemente, en MDX, pero no por eso deja de ser un punto en contra.

En total, creo que son 7 los errores que se deben directa o indirectamente al querer hacer que el sistema sea compatible con Xbox 360. Una pena, y espero que en el futuro corrijan las cosas en lo posible (a diferencia de MDX, aquí parece que hay gente de Microsoft trabajando en algo... aunque no sé muy bien en qué). Aún están a tiempo.

Por mi parte, y como comentaba al principio, voy a pasar de XNA como mínimo hasta que arreglen lo de cargar modelos de fichero, ya que resulta bastante importante para el juego que quiero hacer (que comentaré en otro post porque este ya es bastante larguito). De momento sigo sin decidirme a qué hacer, no tengo la más mínima intención de implementar un motor 3D sobre MDX. He buscado y buscado motores en C#, pero hay muy pocos y menos aún que merezcan la pena.

Aún me quedan un par que probar, y espero que cumplan con lo que necesito (que es tan sencillo como poder mostrar elementos en 3D con shaders propios, y algún que otro componente de GUI, de forma sencilla). Si no, tendré que sopesar el programar en C# (más velocidad de programación, pero hay que hacer un motor 3D) frente a hacerlo en C++ (hay motores 3D a patadas, pero la programación será más lenta).

PD: Parece que existen interfaces de motores hechos en C++ para poder usarlos con .NET. Supongo que es la mejor solución, de momento probaré con Irrlicht a ver qué tal se porta.