No importa qué tipo de juego vas a programar, siempre vas a necesitar un motor gráfico (a menos por supuesto que te propongas como meta un juego no gráfico). Hay juegos 2D, juegos 3D, con visión isométrica (como Diablo y Fallout). El punto de vista puede ser primera persona (tu personaje no se ve) o 3ra. persona (tu personaje se ve siempre). El juego puede ser de aventura, aventura con acción, puede ser un juego de rol, puede ser un shooter como Doom o Quake. (Ver esta lista de tipos de juegos). Siempre necesitarás una motor gráfico.

El motor grafico maneja el despliegue de los gráficos en la pantalla. Puede ser tan simple como desplegar una imagen estática, o tan complejo como generar una escena dinámicamente en 3d, con sombras, luces, la perspectiva correcta etcétera. En mi página sobre desarrollo de juegos hay una discusión sobre el tema para el que esté interesado.

La lista de motores gráficos es grande, pero para el desarrollador independiente con bajo presupuesto las opciones no son muchas. La idea aqui es no reinventar la rueda, programar un motor gráfico consume bastante tiempo y de lo que se trata es programar juegos, no motores gráficos. Yo cometí ese error y luego de varios años todavía no había terminado. El tiempo del programador independiente es limitado y hay que usarlo con inteligencia.

Si el juego que vas a desarrollar es 2D no parece haber mucha discusión, la mejor opción es SDL. Es simple como su nombre lo indica, multiplataforma y hay suficiente documentación disponible.

Si el juego es 3D la lista luego de eliminar todas las opciones con demasiadas desventajas queda reducida a Ogre e Irrlicht.  Ogre (wikipedia) es una plataforma madura y solida con mucho tiempo en el mercado. Pero la curva de aprendizaje es ruda al comienzo. Irrlicht es muy fácil de usar, tiene muchas características que Ogre no tiene (y viceversa) pero dicen que visualmente es pobre. Yo me decidí por Irrlicht, basicamente porque está hermosamente programado, por lo que sería una delicia modificarlo e incorporarlo en mi juego. Ogre está programado en C y es más difícil de incoporar como componente. Ogre al final del día es más poderoso, pero requiere mucho trabajo. Además por lo pronto la premisa basica de mi proyecto es terminar. E Irrlicht ofrece un camino claro para lograr ese objetivo aun cuando el resultado no va a ser el  técnicamente más avanzado.

Este post forma parte de una serie sobre los componentes de un MMO. Estoy poniendo como ejemplo Nunsoot, mi MMO. Más detalles aqui y aqui.

Decía en mi post anterior que voy a estar escribiendo sobre los componentes de mi MMO que ya tengo listos, mis ideas sobre lo que falta, su diseño, las tecnologías utilizadas y el por qué de todas mis decisiones. A continuación la lista. El área sombreada indica el nivel de avance para el día de hoy.

No todo está listo, lo que está listo no está 100% listo, ni esta lista es exhaustiva. Pero es un buen punto de partida para organizar el trabajo. Tengo intenciones de ir refinándola y corrigiéndola con el tiempo. Servirá como una guia para entender de lo que estaré hablando en los próximos meses e inclusive como un tutorial para el desarrollo del juego. Todos excepto los dos últimos puntos sirven por igual a cualquier tipo de juego de los clasificados como aventura, juegos de rol, juegos de acción aventura y similares. Los dos últimos puntos son particulares a los juegos multijugador en línea.

Este post forma parte de una serie sobre los componentes de un MMO. Estoy poniendo como ejemplo Nunsoot, mi MMO. Más detalles aqui y aqui.

Yo no creo que exista alguna persona que haya leído los 240 y pico de posts que hay en este sitio, ni nadie que esté dispuesto a leerlos (hay mucha paja uniforme e inteligentemente distribuida). Así que voy a decir esto como si fuera una novedad: hace algunos años (11 para ser exactos) yo estuve trabajando 30 horas semanales en un juego tipo adventure que en este momento se encuentra en el baúl de los zombies (una especie de cementerio de proyectos inconclusos). Por aquella época me leí cuanto libro sobre desarrollo de juegos, narrativa para videojuegos, etc., etc. Así que al leer este artículo sobre narrativa sentí una conmoción (algo así como el ooooooh que se oye en los stadiums).

El lector atento no dejará pasar lo de las 30 horas. ¿Además del trabajo que me daba de comer o era tiempo completo?. Además. Era mi pasatiempo. La semana tiene 80 horas útiles: ¿qué hace Ud. con las otras 40?. De cualquier modo, varias veces al año disparadores como este me motivan a preguntarme cómo esta mi proyecto actual. The side project como lo llaman en inglés. Un proyecto que no tiene nada que ver con el trabajo que lleva el plato a la mesa. En mi caso particular, y no es de extrañar que sea así, se trata del desarrollo de un juego. Siempre he tenido un proyecto actual, de esos. Inclusive desde antes, cuando estuve trabajando un juego tipo adventure en la Amiga, programado totalmente en assembler. Luego siguió el mencionado juego (que incluyó el desarrollo de un motor gráfico desde cero), un simulador de batallas espaciales, un generador de juegos de ficción (y un juego de ficcion interactiva completamente desarrollado en él) y el proyecto que he retomado ultimamente, un juego roguelike (resurgimiento, y actualizaciones). Los últimos meses he estado trabajando 12 horas al día en un proyecto con pentaho, y mi personaje en World of Warcraft me han dejado poco tiempo para la programación.  Pero eventualmente al tener un fin de semana libre, o cuando me quedan algunas horas de ocio (después de las 11 de la noche o un domingo a las 6 de la mañana) me pregunto cómo está mi side project. Mi roquelike sufrió un accidente, y desde hace tres meses no me sentido motivado a trabajar en él, así que es hora de buscar un side project al side project.

Todo esto conduce a que voy a comenzar una nueva burbuja, o quizás una no tan nueva. Desde el 2007 he estado trabajando de vez en cuando en un MMORPG. Así que voy a continuar ese proyecto. De hecho revisando su estado me estoy dando cuenta que realmente está tan avanzado como el roguelike. Porque yo trabajo como Nietszche. No es que me pongo a escribir  un libro desde la primera página hasta la última. Sino que escribo. Y escribo. Y escribo. Y escribo. Y escribo. Sin preocuparme mucho por la coherencia de lo que estoy escribiendo (programando). Y llegado el momento, cuando un libro deber ser parido, simplemente se trata de juntar todas las piezas y estructurarlas como un libro. Eso explica cómo es que Nietszche escribió la primera  parte del Zaratustra en 10 días.

Todo libro, cuento, historia, novela, relato tiene 5 partes: la princesa es feliz saltando y bailando por la campiña, viene un dragón y la encarcela en la más lugubre mazmorra en lo alto de una torre, aparece un principe que lucha contra el dragón, venciéndolo y librerando a la princesa, viviendo entonces juntos y felices para siempre. Mi MMORPG tiene listo básicamente las 3 primeras partes. Y ahí comienza el problema, terminar las 2 últimas. En los post sucesivos voy a estar escribiendo sobre las partes que están listas, mis ideas sobre lo que falta, su diseño, las tecnologías utilizadas y el por qué de todas mis decisiones. A todos estos post los voy a etiquetar con MMO y no MMORPG porque aplican a cualquier tipo de MMO, no particulamente a los RPGs. Ya en el pasado he escrito sobre este proceso en un blog especial para ello, así que, una vez más, se trata de juntas las piezas. Ya veremos los resultados.

La plataforma de Inteligencia de negocios Pentaho (español) tiene entre sus herramientas para la construcción de soluciones un ambiente de desarrollo basado en Eclipse llamado Design Studio. Esta herramienta facilita la programacion de archivos xml que definen reportes, vistas de análisis y otras soluciones gráficas. Olvídese Ud. de assembler x86, resolución de integrales, o el cálculo del spin negativo del átomo de litio: hacer que un xaction funcione no lo hace el que quiere: solamente el que tiene la paciencia sufiente para superar la curva de aprendizaje.

Ahora que he superado esa curva, encuentro los xactions poderosas armas de diseño equivalente a uno de esos programas en assembler de menos de 1024 bytes: poderosos, sorprendentes y hasta mágicos. Es increíble que con tan pocas líneas de código se logren tan maravillosos resultados.

Me recuerda un poco cuando estuve trabajando ActionScripts y programas swf. No es que fuese difícil utilizarlos, sino que nuestros viejos paradigmas nos impiden entender qué es lo que está pasando detrás de la cortina. Para trabajar con estos lenguajes-protocolos hay que tener fé: funcionan. No sabemos cómo ni por qué, pero funcionan. Hay sin embargo (en ambos tanto los xactions como el ambiente flex-flash-actionscript) peculiaridades que nos hacen sospechar que el que los diseñó no estaba muy consciente de cómo se debe (o cómo se diseña normalmente) una herramienta de desarrollo. O el diseñador se despojó de los viejos paradigmas o simplemente no los tenía. Un sencillo tag de xml puede cambiar el sentido de un programa, y descubrir las implicaciones del cambio puede resultar como tratar de entender los poemas de Nostradamus.

Sin embargo, Pentaho tiene muchas más ventajas que desventajas. Es una plataforma completa, amigable, y es software abierto. Es la mejor plataforma de BI con la que trabajado (después de Business Objects y Cognos)  y está disponible para descargar en sourceforge. Si Ud. necesita una solución de inteligencia de negocios no lo piense dos veces, seleccione Pentaho. Pero eso si, no intente hacer la implementación Ud. solo, busque apoyo. A menos que quiera enfrentarse a una manada de Murlocs en despoblado, solo y desarmado.