Este texto está expuesto sin ánimo de desarrollar un método del diseño de videojuegos global, sino unas directrices particulares que pueden servir para concretar situaciones habituales en el diseño.

Antes de plantearse "nada" del video-juego, habría que preguntarse. ¿A qué quiero jugar cuando juegue con el videojuego?. Aún pareciendo obvia, esta pregunta encierra el 90% de las problemáticas posteriores. Como dato curioso, esta pregunta es contestada, muchas veces, con una rapidez si bien envidiable no menos inquietante, con el siguiente texto "Es Mata-mata con estrategia y aventura en 3d con 30.000 poligonos". Preguntar "¿A qué se juega?" y contestar con un "Es tal o tal cosa" ya es extraño pero mentar el numero de polígonos ya es kafkiano.

Pretender que la contestación sobreviva al final del proyecto es un lujo que solo desde la experiencia se puede salvar, pero aprovecharse de esta incertidumbre para "indefinir" una definición y hacerla así mas "abierta" y "sugerente" es suicida.

Así por ejemplo. el "Quake II" y "Half Life" aparentemente podría decirse que son de igual naturaleza sin embargo, la importancia de desde donde, cómo y cuándo disparas del HL contrasta con la trepidante necesidad de puntería de blancos móviles del Q2 y su potente sensación de arma en el juego (lo que hace, por ejemplo, que en red se jueguen de forma distinta).

En el desarrollo de un video-juego, uno se encuentra con dilemas a la hora de tener que sacrificar "tal o tal opción" frente otra que aparentemente le hacia ilusión que estuviese. Sin ser absolutamente resolutivo planteo el siguiente método de prioridades (según mi experiencia). Dicho de otra manera. Todos queremos el coche más bonito con motor mas potente mas barato y menos consumo, pero el órden en que coloquemos esta afirmación nos llevara desde maravilloso B.M.W. hasta Muscle car pasando por un utilitario.

Aquí va un orden.

El juego.

Los elementos fundamentales que componen la lógica de juego son sagrados frente a cualquier otro elemento.

Esta lógica de juego dictó con buen criterio que el "Age of Empire" subyugase sus gráficos a un mundo mallado en cuadricula o dicho de otra manera, para entendernos, todo ente de juego ocupa una o varias casillas pero nunca las comparte con otro. Ni en su movimiento existe la posibilidad de coexistir entre dos casillas luego los gráficos, mal que a veces pese, deben cumplir las mismas normas (con más o menos disimulo).Y a pesar del aparente gran sacrificio gráfico tenemos un gran juego que sin tal sacrificio dudosamente hubiese logrado serlo.

Otro ejemplo tenemos otro compromiso de lógica muy distinto en Comandos. Su mundo de lógica era sectorizado, lo que implicaba que todo ente existe en el mundo en 3 coordenadas y volumen moviéndose, así, en una realidad de juego continua. Siendo simplistas podríamos decir que son puntos en el espacio 3d infinitamente pequeños. Esto revierte directamente en una vistosidad de los gráficos ubicados en irregulares formas, sin quitar mérito a los grandes grafistas que los hicieron posibles.

Interface Lógico.

La comunicación de elementos de lógica, tanto máquina ->usuario como usuario ->maquina, es el segundo elemento más importante.(un ejemplo muy claro podría ser el cursor mundo) Es decir, todo lo que existe.

Todo lo que juega, explícita o implícitamente, tiene que ser comunicado al jugador de la forma más eficaz y todo aquello que el usuario desea comunicar (hacer), en el juego, debe ser facilitado mas allá de la intuición. En otras palabras:

• Si algo no es perceptible por el jugador más vale que no exista.
• Si algo no es factible para el jugador, más vale que no le apetezca hacerlo (o tú provocarle que no le apetezca).

A pesar de ser el punto mas valorado por el jugador, en desarrollo, no debe emerger mas allá del tercer puesto. De lo contrario, conseguirás 5 minutos de sensaciones y horas de desorientación. Un caso muy común es haber desarrollado un engine con tal o cual posibilidad y ante la dolorosa posibilidad, de que no se note, se le hace participe del juego sin que pinte nada.

Recuerdo varios casos (algunos nunca se terminaron) en que el programador estaba tan orgulloso de la física tan "real" puesta en el engine que todo rotaba colisionaba como en la vida real. El resultado era que el juego era inmanejable y salvo los cinco primeros minutos de curiosidad jugando con los objetos, el resto era una pesadilla. O imaginemos un juego de ajedrez en 3D primera persona, con los peones cada uno con caras distintas y batallando en un hermoso valle, donde apenas se distinguiese las casillas, con animaciones sorprendentes. Todo maravilloso. Sensación 10, enajenación 10. Y ahora a ver quién es valiente que le diseña un interface a semejante monstruosidad.

Features

Features de tecnología, para mayor gloria de producto en el marketing. (por ejemplo, manejar 40000 polígonos en tiempo real). Indudablemente, éste debe ser el esclavo de esclavos. El último en dictar criterio en un videojuego. En toda mi experiencia en el desarrollo de videojuegos nunca vi un juego hecho a base de features sin embargo, son moneda común de intercambio cuando se habla de un videojuego.

Es una realidad desorientadora encontrarte, en un documento de definición de juego, páginas enteras con afirmaciones pseudocientíficas y nada de juego. Y digo pseudocientifícas porque, a pesar de la promesa de exactitud, son altamente indefinidas (¿qué significa "mover" 40.000 polígonos?, ¿motion capture?, ¿Inteligencia Artificial?). Aunque la costumbre nos hace creer que sabemos de qué hablamos, la realidad es muy otra. Recuerdo cuando presentábamos un prototipo de tecnología hecho por Javier (Javier Arévalo) que contenía gran parte de las features 3D del momento Flares, iluminaciones de colores, mipmapping....etc y la gente ingenuamente decía "¡Ah qué bien! sólo os queda hacer el juego", sólo..., sólo... ¡casi nada!. Sólo el "jueguecito". Es maravilloso embellecer un juego con features como lo es embellecer un coche con una carrocería pero, si no hay coche, la carrocería poco podrá hacer.

Hoy por hoy, el trabajo de diseño de un videojuego está bastante distanciado de la programación. Otra cosa es que te atraigan ambos campos. En un paso posterior al diseño y especificaciones de juego viene el diseño de código. En este punto sí es interesante saber qué utilidades se van a usar como más apropiadas. En el apartado de lenguaje de programación está claro que el "C" es el rey, aunque sólo sea por aquellos que, como yo en mis tiempos, han tenido que programar casi todo en ensamblador. Y en mi caso particular tengo una clara preferencia por el C++ (como opción desarrollada del "C"). Pero me gusta aclarar que el lenguaje de programación condiciona menos de lo que puede aparentar (Lo digo desde haber programado en casi todos los ensambladores y lenguajes más conocidos). En resumen, todas las opciones de programación son buenas si están ajustadas a una necesidad y ninguna es mágicamente salvadora.

ÚLTIMA REVISIÓN EN FEBRERO DE 1999