Hace unos años conocí a Rafael Muñoz, un desarrollador experto en videojuegos y especialmente en el desarrollo de Unity. Si no lo conocéis, os recomiendo encarecidamente que le sigáis por Twitter y si teneis algún tipo de duda en el uso de Unity, se conoce todo el entorno de una manera bastante profunda.
Después de charlar un rato, me dijo estas dos máximas
Se puede hacer unit testing en videojuegos
Y que se podía introducir reglas de negocio en los videojuegos. Yo que venía de desarrollar videojuegos, me quede un poco perplejo ante esas afirmaciones.
Entonces pasado un tiempo, unos amigos me regalaron este juego y mientras ellos jugaban yo revisaba que:
Estaba desarrollado con Monogame
Y por ende, era código en .NET y que ocurre con el código de .NET?
Que puede decompilarse.
Entonces mientras ellos echaban una partida al Magicka, yo también jugaba la primera partida de una manera completamente diferente, desgranando y “bicheando” un poco el código internamente
Y así con cada uno de los juegos indies que pasaban por mis manos. Lo primero que hacía era echarle un ojo al código.
ddddd
Especial mención a They are billions, que es el único juego que he visto que al menos han ofuscado su código un poco. A diferencia del resto de juegos que he visto.
ddddd
En cada uno de los juegos que revisaba, veía ciertas similitudes en la manera de estructurar el código, de como “organizan” todo. Y digo “organizan” porque no se ve ningún tipo de paradigma, ni de estructuración evidente, ni se llega ver que los desarrolladores lleguen a hacer un uso elevado de las features que tiene el lenguaje.
Un ejemplo muy claro es Ska Studios. Este estudio de desarrollo comenzó en la movida indie, en los comienzos de Xbox 360 creando diferentes juegos que son interesantes y divertidos.
Tales como Charlie Murder o Salt and sanctuary. Comparando estos dos.
Hay un salto temporal de 3 años de desarrollo. Que entendiendo como un estudio indie, probablemente se lanzará un juego y se pusieran en preproducción del siguiente o incluso a desarrollarlo.
Si decompilamos varios juegos. Se puede ver una estructura muy similar. Incluso reutilizan ciertos espacios de nombres, como MapEdit.
Se pueden ver perfectamente dos clases de particulas en este caso BloodTrail que tienen una estructura similar y la clase Base de particulas que usa, también es muy similar.
Teniendo eso en cuenta, un desarrollador con un poco de cabeza, hubiese creado una librería común, hubiese reutilizado de una manera completamente distinta las clases, teniendo en cuenta que son casi dos gotas de agua. No he podido analizar el código de otros juegos del estudio, aunque, viendo que son del mismo corte, sobreentiendo que también se verá este patrón en el código.
También se ve que en el caso de Salt and Sanctuary se puede ver que ha usado un servicio web y no ha sido ni siquiera por renombrarlo.
Entonces, después de varios juegos realizados, de estudiar el código de varios videojuegos. Volvía a poner en duda las premisas de mi colega Rafael Muñoz de que ni se pueda hacer UnitTesting al uso en videojuegos, ni se puedan usar reglas básicas de negocio en los videojuegos y en caso afirmativo, después de analizar mucho código de diferentes juegos indies, nadie parecía hacerlo.
Tal vez, si lo hicieran, los estudios indies serían más productivos desarrollando, solo supongo. Porque cuando se llevan buenas prácticas en el código de negocio, suele significar un proyecto que va un poco mejor que cuando no se hace.
Pero vamos a analizar por un momento si se puede o no se puede hacer esto.
Vamos a hacerlo con un clásico.
Con el juego de donde salen todos los estudios
Supongamos que todos los objetos interactivos en pantalla, podrían ser Entidades,
Toda la pantalla sería nuestra vista principal
Y en ella hay ciertos servicios y funcionalidades. Debemos comprobar colisiones, debemos tener una cámara eficiente, tenemos que ir pintando cada una de esas entidades. A que podemos asimilar esto?
No podríamos pensar que es un poco lo que nos plantea una arquitectura MVVM. Donde la vista sea esa Screen o Escena que siempre planteamos y dentro haya diferentes ViewModels
Y que cada uno de los servicios se apliquen.
Vamos a simplificarlo un poco, vamos a pasar al juego más primigenio.