Más sabe el diablo por viejo…

Más sabe el diablo por viejo…

En tecnología | 2015.07.10 | por | Comentarios ( 0 )

Dice el refrán que el saber viene con la edad, a través de la experiencia. A lo largo de los años que llevo haciendo videojuegos he tenido que lidiar con bastantes motores y en esta entrada voy a comentaros algunas de mis experiencias y opiniones sobre varios de ellos.

Bueno, no me voy a remontar a los tiempos de cintas y cartuchos, no creo que eso sirviera de mucho y tampoco estaríamos hablando de «motores» tal y como los entendemos actualmente. Sin embargo es cierto que han pasado unos cuantos años desde que trabajé en serio con Vision Engine, Source, C4 o Multiverse. Por ejemplo, la compañía que desarrollaba Multiverse cerró y el motor es ahora open source, Havok compró Trinigy y ahora son los propietarios de Vision Engine, y no se puede comprar una licencia de C4 en el momento en el que estoy escribiendo esto (creo que es algo temporal, es un motor excelente).

Source es el motor de Valve y con él se han hecho Half-Life, Left 4 Dead, Portal y DOTA 2. Es muy modular, con las ventajas e inconvenientes que eso conlleva. La versión con la que trabajé tenía el código plagado de comentarios tipo «//hack, do NOT touch this«, lo que significa que había cosas metidas con calzador y sujetas con pinzas. No era estable, fallaba de formas caprichosas y costaba un ojo de la cara. Para rematar la faena estaba pensado para hacer juegos en primera persona y el nuestro era en tercera. Un auténtico Cristo de los Dolores. El jefe del estudio quería usar Source por la publicidad que le daría al proyecto usar un motor conocido, famoso. Me costó mucho convencerle para que cambiásemos de motor, pero cuando lo conseguí el desarrollo mejoró mucho. Como pasar de la noche al día. Cambiamos Source por C4, en cuyo código no había trampa ni cartón, era muy estable y potente, tenía un modelo de iluminación extraordinario y materiales modernos con parallax mapping y todo. Y si os fijáis en la web de C4, veréis que el tipo que ha diseñado ese motor es toda una eminencia en la programación de gráficos, 3D, iluminación y materiales. Sin embargo, para aprovechar un código tan bueno hay que estar a la altura; cualquier modificación del código fuente del motor requiere un nivel excelente en programación, y es C++. Así que por estupendo que sea el motor tampoco es para todos los públicos. Eso sí, si queréis un ejemplo de buenas prácticas y programación eficiente en C++, echad un vistazo al código de C4.

Años después el modelo de negocio de Source cambió, añadieron nuevas versiones de las herramientas del motor (más modernas y estables) y actualmente podéis usar la versión más moderna de Source para hacer vuestros juegos. Ha mejorado mucho, la verdad, y hay mogollón de ejemplos en Internet. No os olvidéis de que Valve es propietaria de Steam: usar su motor puede ayudaros a publicar en su plataforma.

Sobre Trinigy’s Vision Engine lo que puedo contar son historias de terror. Hace ya unos años que Havok se hizo cargo de este motor, así que las versiones más modernas son mucho mejores que la que tuve que usar yo, que conste. El proyecto que usaba Vision consistía en mostrar un monasterio medieval de tres formas distintas: con una «visita virtual interactiva», en un vuelo controlado de la cámara mostrando los detalles más importantes, y en un modo «caza del tesoro». Como podéis ver no era precisamente un videojuego; años después se empezó a llamar «Serious Games» a este tipo de aplicaciones que usan tecnologías de los videojuegos, pero esa es otra historia…

El caso es que el monasterio en cuestión era real y lo habían escaneado con laser para generar un modelo 3D con una brutalidad de detalle. Los artistas se pasaron meses limpiando la geometría escaneada, generando texturas y materiales, sudando tinta china. Cuando su parte estuvo lista le tocó el turno a los programadores; la teoría era sencilla: crear un nivel de juego con el monasterio escaneado, poner «hot spots» en las zonas de interés y que cuando el jugador/visitante apuntase a esos puntos aparecieran ventanitas con fotos e información de cada cosa. Además estaba el modo de vuelo controlado, en el que la cámara seguiría un camino definido por waypoints, y ahí empezó la broma. Al empezar a desarrollar este modo, cuando cargábamos el nivel con la cámara que iba a ir volando, el mundo salía al revés. Parecía que estuviera rotado 180º, con el suelo arriba y el cielo abajo, pero no. Resulta que el mundo estaba invertido en el eje vertical y en un eje horizontal. O sea, escalado a -1 en dos ejes. Como el nivel era básicamente el modelo escaneado en 3D podía ser un problema del modelo o sus transformaciones, o bien un problema de la cámara. Pero aparentemente (y según el mismo Vision Engine) todo era correcto. Y eso es un problema de los gordos, aunque bastante común. Cuando todo es correcto y no hay ningún error pero el resultado es diferente de lo esperado hay que encontrar la lógica del problema, y nunca es evidente. En este caso podíamos modificar la posición y rotación de la cámara, transformar el modelo, cambiar los atributos del nivel… La solución más sencilla fue modificar la matriz de proyección de la cámara. En realidad el mundo estaba al revés (en tiempo de ejecución) pero la cámara lo mostraba del derecho, así que arreando.

El siguiente problema apareció cuando quisimos hacer que la cámara volase de un punto a otro, siguiendo una lista de puntos de ruta sin saltos bruscos, pero que además la cámara apuntase a ciertas zonas en el proceso. La primera opción sería hacer una lista de estructuras de datos que almacenasen las posiciones y orientaciones de la cámara. Lógico, coherente. No funcionó, la cámara no se orientaba correctamente hacia donde debía. Con el tiempo muy justo para entregar el proyecto, en vez de pelearnos con ese sistema lo que hicimos fue crear dos rutas: una para las posiciones de la cámara y otra para un objeto invisible (un «dummy» o «helper«) al que la cámara debía apuntar en todo momento. Así que en vez de pelearnos por programación para resolver el problema, hicimos un sistema más sencillo y ajustamos en el editor de niveles las posiciones de los waypoints de la cámara y su invisible objetivo. Desde la perspectiva de un programador no fue lo más elegante, pero sí lo más sencillo, rápido y fácil de modificar.

Ahora toca hablar de Multiverse, y los recuerdos me llegan en tropel. El proyecto en cuestión era «un MMO para aprender y enseñar español». Dicho finamente, una plataforma online de e-learning integrada en un mundo 3D. Empezamos usando Multiverse porque la decisión sobre el motor a utilizar «vino de arriba»; era gratis cuando yo llegué al estudio, ya tenían firmado un convenio de colaboración. La principal ventaja de Multiverse era su portabilidad, porque estaba hecho en Java y Python, pero precisamente por eso el rendimiento del cliente en aquellas versiones era bastante pobre. Añadir al cliente capas de interfaces y sistemas de inventario para que alumnos y profesores pudieran compartir documentos (lecciones, deberes, fotos…) no ayudaba precisamente a mejorar el rendimiento. Pero lo hicimos, vaya, y a quienes lo hicimos nos concedieron el premio FICOD 08 «por desarrollar mejoras en las tecnologías que permiten crear mundos virtuales».

Mi principal preocupación con Multiverse era la visibilidad del código. Los scripts de Python tenían que estar en el cliente, a la vista de cualquiera, así que era muy fácil modificarlos y «hacer trampas». Ese fue el principal motivo por el que al final dejamos Multiverse; probamos BigWorld y HeroEngine, y al final el proyecto se completó con este último y se convirtió en «HiHOLA!«.

La idea detrás de Multiverse era muy buena: un sistema de servidores, cada uno con su mundo o juego, y cualquiera con el cliente de Multiverse en su ordenador podría acceder a todos ellos (si tenía permiso, claro). Si os interesa echarle un vistazo a esta plataforma podéis descargarla completa y gratis desde su web; tened en cuenta que para generar contenidos 3D hace falta 3ds Max 2011 32 bit (no versiones más modernas), y que el servidor está hecho para correr en Ubuntu. Puede ser interesante para proyectos de fin de carrera, para trastear o para aprender cómo funciona un sistema así, pero yo no lo usaría para hacer juegos comerciales según está. Hay alternativas menos… dolorosas para hacer juegos online, ahora os comento un par: BigWorld y HeroEngine.

En dos ocasiones distintas separadas por unos años he tenido que probar BigWorld. Es un motor excelente, el único con particionamiento dinámico del mundo de juego para equilibrar las cargas de proceso y red. BigWorld permite tener mundos gigantescos con mogollón de usuarios a la vez y es bastante fácil hacer todo tipo de vehículos, incluso tripulados por varios jugadores. Técnicamente es fantástico y el cliente tiene buena potencia gráfica. Las dos veces que lo evalué el único problema fue el precio de licenciarlo: DEMASIADO CARO, con mayúsculas. Con el tiempo intentaron abrirse mercado entre los desarrolladores independientes sacando una versión limitada por $300 pero la reputación estaba ganada y el daño estaba hecho. En las horas bajas de BigWorld la compañía Wargaming, cuyos famosos juegos «World of Tanks» y «World of Warplanes» usan este motor… bueno, pues compró la compañía que desarrolla el motor, y nunca más se supo de las versiones indie. Si tenéis un cerro de dinero y queréis hacer el juego online más supermasivo de la historia, mi consejo es que pidáis una versión de evaluación de BigWorld. Para desarrolladores independientes y estudios pequeños puede quedar bastante fuera de presupuesto, pero si lo podéis pagar y el proyecto lo vale, merece la pena.

HeroEngine lo conocí cuando trabajaba en Salamanca, así que con Anmynor han sido dos los proyectos en los que lo he usado. Del primero al segundo las condiciones de la licencia cambiaron bastante, y hoy en día es bastante más económico que hace unos años. Hay dos precios disponibles: $75.000 más un 7% de los beneficios o bien $99 al año más un 30% de los beneficios. La versión más barata no incluye acceso al código fuente, que conste: el juego se desarrolla mediante scripts y herramientas precompiladas, usando las características que el motor trae por defecto, que son suficientes para la mayoría de juegos online que queráis hacer. Tiene una arquitectura peculiar, y el lenguaje de los scripts es suyo propio. Echad un vistazo a su wiki de referencia para ver a qué me refiero.

En cualquier caso, si queréis hacer un juego online o MMO os recomiendo que echéis un buen vistazo a ambos. Si vuestro presupuesto es ajustado, la opción más evidente es HeroEngine/HeroCloud.

Sé que habrá gente que opinará que con Unreal o Unity se puede hacer un MMO, y no es mentira pero tampoco es totalmente cierto. Con ambos se puede hacer el cliente del juego, pero la parte del servidor ya es otro asunto. Quienes han hecho juegos así (online/MMO con clientes hechos en Unity o Unreal) han usado software de terceros para hacer los servidores y gestionar todo el tema de redes y conexiones. Uno de estos es SmartFoxServer, compatible con muchos motores de juegos y tecnologías. Pero por un lado hay que integrar el sistema de red en el cliente de juego, algo que ya traen de serie BigWorld y HeroEngine, y por otro lado están los costes de licencia (3.500€ por juego y servidor con SmartFox X2) y el precio, mantenimiento y conexiones de los servidores, que van aparte. Así que por precio y dificultad, mi consejo es el siguiente:

Si quieres hacer un juego online/MMO que puede hacerse en BigWorld/HeroEngine,
no te compliques y usa uno de estos dos.

Ahora bien, si el juego no es online/MMO podemos entrar en «la guerra de los fanboys» y no estoy por la labor. Hay gente que defiende Unity o Unreal a capa y espada, y le sacan faltas al otro sin reconocer los defectos que pueda tener el que más les gusta. No me parece que sea una actitud productiva, la verdad, y ambos motores son muy buenos. Hace poco tiempo que ambos han cambiado sus modelos de licencia y pueden conseguirse gratis. Como ya expliqué en otra entrada, no creo que un motor sea universalmente mejor que el resto, y en el caso de Unreal y Unity lo mantengo con más firmeza si cabe. Para muestra, un botón:
El Marketplace de Unreal tiene menos contenido que el Asset Store de Unity, cierto es, pero también es cierto que muchos de los extras que hay para Unity son incompatibles entre sí y combinarlos trae más problemas que soluciones. Podríamos revisar las características de cada uno y encontrar ventajas e inconvenientes, pero al final veríamos que están bastante igualados. Por ejemplo, estoy preparando un curso sobre PBR (Physically-Based Rendering) y los ejemplos de integración los hago en Unity simplemente porque a día de hoy tiene más cantidad de usuarios. Sin embargo me costaría lo mismo hacerlo en Unreal, y si hay demanda haré una versión del mismo curso para Unreal. Con los juegos es lo mismo: si el proyecto encaja en el motor, adelante con ello.

Me ha quedado un poco largo pero espero que os haya gustado y que a algunos os sea útil la parrafada :D

Comparte:
  • Facebook
  • Twitter
  • Meneame
  • LinkedIn
  • BarraPunto
  • Bitacoras.com
  • email
  • Google Bookmarks
  • Print

Escribe un comentario

* Invitados: son necesarios nombre, correo y comentario.