Aunque a priori parecerá una tontería, en la etapa del aprendizaje suele ser bastante complicado decantarse por un género determinado a la hora de realizar el primer juego. Este artículo pretende orientar un poco a todos aquellos que estén a punto de lanzarse a crear su primer juego, ofreciendo un pequeño análisis de cada uno de los géneros que son, más o menos, estándar en el mundo del videojuego. Como veréis, el objetivo será el de poner en práctica todos nuestros conocimientos teóricos para ir adquiriendo experiencia.

Resulta común entre los noveles, a la hora de plantear su primer juego, llenar la cabeza de ideas que se escapan totalmente de sus capacidades como programadores, grafistas o diseñadores. Antes de comenzar a perfilar "el mejor juego del mundo", hace falta que nos serenemos y pensemos fríamente en nuestras posibilidades como creadores. El primer título que desarrollemos es imperativo que vea la luz, esto es, que se logre acabar. Por lo tanto, hay que tomar una idea sencilla pero que cubra todos los aspectos teóricos que creamos que tenemos dominados. En la etapa de aprendizaje, lo que tenemos que hacer es aprender y, por lo tanto, no preocuparnos de si nuestro juego podrá competir "por algo". Hay que lograr ir poniendo en práctica todas y cada una de las cosas que creemos que hemos aprendido de tutoriales por Internet, en libros o por propia investigación personal. Recordad, que por mucho que leamos, por mucha base teórica que tengamos, lo importante es practicar de algún modo. La diferencia entre un programador que, además de documentarse, programa y otro que sólo se documenta, es abismal.

Por otro lado, deberemos de tener en cuenta que los juegos no son "prácticas" para ver qué hace o qué no hace esta o aquella rutina. Eso en el mundo de la "DemoScene" sí funciona pero en el del desarrollo de juegos no, porque un juego es algo mucho más complicado. En un juego debemos de dar coherencia a todo nuestro código. Un juego es un programa interactivo (una demo no lo es) y, por lo tanto, el director del mismo es el propio usuario no el programador. Debemos de saber cerrar nuestros primeros proyectos, que serán sencillos, para que, más adelante, y al haber cogido experiencia suficiente, los proyectos más complejos no se nos resistan.

Así pues, lo más importante en la etapa del aprendizaje es ir entendiendo los distintos mecanismos que hacen funcionar un juego. Esto lo lograremos llevando a la práctica todos nuestros conocimientos teóricos. No hace falta meterse a desarrollar juegos "grandes" (y el concepto de "grande", aunque varía entre diferentes personas, siempre es proporcional), sino realizar juegos pequeños acabándolos siempre.

A continuación, voy a proceder a analizar, muy por encima, los diferentes estilos o géneros de los que puede beber nuestro primer y básico desarrollo. Antes, sin embargo, haré una mención al tema de las 2D y las 3D.

Resulta un hecho innegable que si quieres vivir en el futuro del desarrollo de juegos, has de saber moverte en las tres dimensiones. Sin embargo, eso no es óbice para que pases por alto la representación en 2D, es decir, has de conocer con profundidad la programación en 2D. Los juegos han de justificar el uso de la tecnología por encima de toda regla y esto es algo que has de asumir como programador, grafista o diseñador. Por lo tanto, resulta imprescindible tener buenos conocimientos de ambos tipos de representación gráfica.

La programación en 3D es más complicada que la programación en 2D (a priori). Sin embargo, y tal como decía más atrás, de poco sirve ponerte a estudiar programación 3D como un loco si nunca has hecho nada en 2D. Es imprescindible conocer bien las 2D antes de lanzarse a trabajar en 3D. Realizar el primero de tus juegos en 3 dimensiones tan sólo traerá problemas y de lo que se trata es de que acabemos nuestro primer juego por sencillo que éste sea (insisto, queremos hacer juegos no rutinas gráficas). Desecha cualquier intento de realizar algo en 3D como primer desarrollo. Desecha también cualquier intento de crear una herramienta o engine en 3D si antes no has hecho alguna utilidad para el manejo de, por ejemplo, sprites o tiles en 2D. Sé inteligente y, sobre todo, paciente. No gastes tus energías y tiempo dando golpes al aire. Cuando hayas hecho suficientes juegos en 2D pequeños y estés seguro de que has adquirido esa experiencia tan necesaria, salta a las 3D (y cuando hayas dado el salto, nunca olvides justificar el uso de la tecnología).

Esta primera decisión creo que es vital. Todos solemos tener algún tipo de género por el que nos inclinamos y, cuando pensamos en hacer un juego que se nutra de él, lo solemos hacer pensando en algo realmente grande, estupendo, inmejorable. Que no haya nada que se le parezca en el mercado. Lógicamente, esa primera etapa de "furor" la tiene todo el mundo. Lo importante es saber contenerla y ponerla en práctica sólo cuando seamos capaces de acometerla. Decantarse por nuestro género preferido a la hora de hacer el primer proyecto puede ser muy peligroso. Si a nosotros nos gustan mucho los juegos de rol o de aventura, por ejemplo, seguro que pensamos de inmediato en un complejo guión, en personajes controlados por el ordenador realmente inteligentes, en escenarios que van cambiando dinámicamente, o en sistemas de atributos o combates de última generación con multitud de añadidos o extras. Todo esto es muy peligroso pues lleva consigo un más que probable abandono del proyecto.

En la etapa del aprendizaje, lo mejor que podemos hacer es elegir juegos de corte clásico que no tengan mucha complicación. Les añadimos algunas mejoras de cosecha propia y los hacemos. Cualquier juego, por sencillo que parezca, siempre tendrá algún tipo de complejidad que nos dé más trabajo del esperado y sobre el que merezca la pena indagar. Nunca penséis que porque vuestro juego no va a tener la categoría de ser vendido va a ser una pérdida de tiempo el hacerlo. Siempre, y esto es muy importante, se aprende algo nuevo con cualquier desarrollo. Por sencillo que sea el juego, siempre aprenderéis alguna técnica nueva o refinaréis todo aquello que ya creéis tener dominado (u os daréis cuenta de un error que no repetiréis en el futuro). Además, para qué nos vamos a engañar, la experiencia lo es todo y para coger experiencia haciendo juegos, no hay más remedio que hacerlos. Es de cajón.

Lo ideal, pues, es realizar proyectos cortos (unos dos o tres meses de tiempo de desarrollo; preferiblemente 2 meses). Si os pasáis un año o año y medio haciendo cosas de esta manera, que vayan aumentando en complejidad, aprenderéis muy rápido y estaréis, antes de lo que os imagináis, preparados para abarcar proyectos muy grandes. De nuevo, debéis de someteros a la máxima del desarrollo de juegos "Nunca intentes hacer el mejor juego del mundo a la primera" pero, ¡ojo!, haced todo dando siempre lo mejor de vosotros mismos (ahí es donde se encuentra la vocación y el talento que tanto hace falta en el desarrollo de juegos).

El género de los juegos de inteligencia o habilidad, es uno de los más antiguos que hay. El "paradigma" de éste tipo de juegos es la obra de culto "Tetris". La complejidad principal de este tipo de productos, se encuentra en el algoritmo que contiene el mecanismo o, mejor dicho, las reglas del juego. Sin embargo, estos algoritmos no suelen ser, en principio, excesivamente complicados. Basta con que nos fijemos en algún juego de habilidad que nos guste un poco para anotar en papel las reglas por las que se rige. Después, tan sólo deberemos de implementar esas reglas en un algoritmo (al que le podremos dedicar más o menos tiempo para optimizarlo o incluso para modificar sus reglas principales) y tendremos el juego. Así, por ejemplo, el juego del "Tetris" (que su funcionamiento será explicado en el número 10 de Macedonia), tiene un regla principal muy sencilla; ir colocando piezas en una tabla delimitada por filas y columnas (que no es más que una matriz de mxn casillas) de tal forma que logremos hacer filas que tengan todas sus columnas con elementos de alguna pieza. A partir de esta premisa, deberemos de desarrollar toda la lógica que rodea al programa (cómo representar internamente la tabla en donde se colocan las piezas, cómo representar las piezas o las colisiones entre la pieza que vamos moviendo y las que se encuentran ya alojadas en la matriz, la velocidad con la que van bajando las piezas, etc).

Como veis, en este tipo de desarrollos, hay un buen montón de aspectos que se desprenden de la premisa o regla principal de juego. Ofreciendo, siempre, buenos ejercicios para demostrar que somos capaces de trabajar con las estructuras de datos más apropiadas y eficientes.

La complejidad de la programación gráfica en estos juegos, es muy sencilla (lo que no quita que cada uno lo complique hasta donde quiera después) pero muy útil para afianzar conocimientos y adquirir seguridad en el desarrollo.

Este tipo de juegos requieren, sobre todo, una elevada calidad técnica. El hecho de manejar a algún tipo de "objeto" de forma rápida y dinámica, necesita de técnicas que aprovechen bien el hardware de la máquina. Todo esto reviste en un conocimiento moderadamente importante de temas específicos (como pueden ser el ensamblador) y en algoritmos o métodos de representación también muy eficientes. De todas formas, no es una idea descabellada hacer un arcade como primer juego. Basta con que nos propongamos hacer algo sencillo y abarcable y tendremos la seguridad de que habremos puesto en práctica un buen montón de conocimientos técnicos.

Un buen juego por el que empezar, podría ser un sencillo juego de naves tipo "Asteroids" o "Space Invaders" o un "shoot'em up" tipo "R-Type". Eso sin menospreciar otros proyectos como algún juego estilo al clásico "Green Beret". Todo este tipo de juegos arcade, pueden afianzar conocimientos que te servirán de base para poder hacer luego arcades de mayores proporciones.

En los juegos arcade, lo más importante es la parte destinada a la programación gráfica. Saber usar bien la máquina que posees para realizar algoritmos de dibujado hará que tu juego resulte interesante. Independientemente de esto, deberás de saber realizar un juego coherente, es decir, con fases equilibradas y divertidas. De nuevo, hay que volver al hecho de que los juegos no son sólo módulos de efectos especiales de programación. Los juegos han de ser algo que te haga pasar un rato divertido o emocionante por eso, se ha de utilizar siempre diseños interesantes de cara al jugador.

Los juegos de este tipo suelen reunir varias disciplinas de otros géneros. Una aventura gráfica o conversacional, no siempre tendrá el mismo tipo de realización "estándar". En un juego de rol ocurrirá lo mismo. Los añadidos que podamos darles a nuestras creaciones, deberán siempre estar supeditadas a la experiencia que tengamos como desarrolladores.

Quizás, si lo que más te interesa son las aventuras, lo mejor que puedas hacer es comenzar a realizar aventuras conversacionales. El por qué está bien claro. Las aventuras gráficas basan todo su potencial creativo y de desarrollo en pantallas bellamente ilustradas y personajes animados con lo que para un grupo de desarrollo novel, esto es algo que se escapa totalmente de sus posibilidades. La calidad de una aventura se mide, a fin de cuentas, por el argumento y el guión con el que cuente. Una conversacional es el medio más potente que existe para poner en práctica tus dotes como diseñador de aventuras pues te obliga a tener que crear un libro virtual sobre el que el lector pueda seguir la aventura. Todo el interés del juego se cierne en la calidad argumental del juego en sí, no en los gráficos del mismo. Por otro lado, una conversacional puede ser algo realmente complejo. A tú disposición tienes problemas tan interesantes como la creación de parsers, evolución dinámica del universo en el que juegas, personajes controlados por el ordenador que campan a sus anchas, etc. Obviamente, todos estos extras también pueden ser incorporados a las aventuras gráficas sin embargo, estamos en las mismas de antes. Mientras que las conversacionales no necesitan de gráficos para poder construirse, las gráficas se basan en éstos.

Otra de las ramas de la aventura es la de los juegos de rol. Este tipo de género es bastante confuso. Realmente beben de las aventuras ofreciendo al jugador, además de una historia y guión digno, situaciones de mayor libertad para que el jugador pueda realizar su cometido. Así, en un juego de rol, se puede mezclar el género arcade (combates), el estratégico (disposición de personajes, modo de acometer un combate, gestionar el inventario, etc.) y el aventurero (resolución de problemas lógicos, conversaciones, una historia que conocer, etc.). Los juegos de rol encierran, a priori, más complejidad de desarrollo que una aventura "convencional". En líneas generales, cualquier juego que lleve la coletilla de "aventura" siempre requerirá bastante más esfuerzo del que parece. Crear juegos en los que haya una historia, puzzles y guiones que te muevan a continuar jugando, requieren un esfuerzo de diseño extra y, por tanto, una madurez importante como creador de juegos.

No intentes embarcarte en una creación de este tipo de género a la primera, a no ser que tengas ya experiencia como programador de juegos o cuentes con algún tipo de herramienta que te haga la mayor parte del trabajo de programación (en Spanish Quest puedes obtener información sobre este tipo de herramientas y en esta misma sección de Macedonia, un completo curso sobre diseño y creación).

Los juegos de estrategia se presentan como candidatos ideales para acometer un primer o segundo proyecto ya que esconden una gran cantidad de desafíos, de diseño, para el desarrollador. Para empezar, obligan al programador a investigar estructuras de datos que estén siempre supeditadas al juego en sí. Aquí hay que trabajar siempre de acuerdo a la forma en la que podamos representar las reglas de juego del modo más eficiente. A decir verdad, los juegos de estrategia someten la tecnología al juego siempre. Además las reglas que puedan regir un juego de estrategia pueden ser perfectamente abordables por el grupo de programación. Obviamente, y al igual que pasa en cualquiera de los géneros anteriormente citados, deberemos de controlar nuestras emociones y proponer juegos que no se conviertan en un cúmulo de reglas que acaben por volver locos a nuestras, aún, poco ejercitadas cabezas de diseñadores. Podríamos, por ejemplo, pensar en un juego que utilice representación similar a la del original "Civilization" y cuyo cometido sea infinitamente más sencillo. Tan sólo poner en práctica algunos conceptos como la búsqueda del camino más corto, la creación de estructuras de datos que economicen en memoria para los mapas o unidades(en los juegos de estrategia hay que guardar amplias cantidades de información que, además, han de ser accesibles rápidamente) son motivos para plantearse acometer un proyecto de este tipo.

Los juegos de estrategia son, por tanto, candidatos ideales a abordar. No tienen por qué ofrecer gráficos vanguardista y en ellos se suelen poner en práctica multitud de disciplinas de la programación de juegos. Desde diseños robustos a estructuras de datos y algoritmos que luego nos valgan para otro tipo de desarrollos.

Los juegos de simulación son un género prohibitivo para cualquier novel. Los conocimientos técnicos necesarios para llevar proyectos de este tipo están fuera del alcance de cualquier principiante. El hecho de necesitar amplios conocimientos matemáticos resulta una criba que tan sólo se puede superar mediante la experiencia previa en la realización de juegos con un nivel de matemática más sencilla y con el posterior aprendizaje de representación tridimensional. Olvídate, al menos por el momento, de hacer un simulador.

Después de haber comentado, muy por encima, todos los géneros base existentes (está claro que hay muchas otras ramificaciones que no se han tenido en cuenta, más las ideas personales de cada creador) uno ha de decantarse por aquel que le permita poner en práctica todos los conocimientos teóricos que cree que posee o ha adquirido ya. Aunque el juego en cuestión no sea nuestro preferido. Vuelvo a reiterar que hasta que podamos hacer ese juego que tanto nos gusta, deberemos de aprender a programar juegos. Como en todo, aprender a programar juegos sólo se consigue programando juegos. Concentrémonos en la realización de pequeños desarrollos, añadámosles algún que otro toque de original de cosecha propia (que nos anime durante la etapa de desarrollo), y, lo más importante, acabémoslos. Sólo de esta forma lograremos ir madurando como desarrolladores.

Aprender a trabajar en equipo y a preguntar las dudas que nos puedan surgir a otra persona con mayor experiencia que nosotros, es algo que también se torna esencial en el aprendizaje. No debemos de encerrarnos en nosotros mismos, sino ir evolucionando en un ambientes en donde la colaboración sea parte importante. Recordad que, en el futuro, deberemos de trabajar con otras personas. No se trata de "saber más" se trata de ayudarnos y aprender los unos de los otros.