El diseñador se acerca al sitio del dibujante y le instruye en tono condescendiente: “Oye, la capa del personaje pónmela roja, no negra“.

Acto seguido se acerca a un programador y le explica: “Escucha, el personaje tiene que avanzar a 1.3 m/s cuando esté subiendo una cuesta, no a 6 de las unidades actuales, cualesquiera que sean éstas, que no lo sé.”

El dibujante se queda mirando desconsolado su paleta de colores temáticos, dentro de la cual ese rojo no tiene cabida alguna.

El programador comienza a sentir un tic nervioso en el párpado izquierdo cuando intenta evaluar mentalmente el alcance de la refactorización de todas las variables enteras involucradas.

El diseñador se vuelve a su sitio, ajeno al cambio que acaba de provocar en su estatus: en veinte segundos ha evolucionado de Diseñador a Dictador.

Una de las primeras dudas que se presentan cuando elaboramos una especificación funcional es hasta qué punto debemos concretar las funcionalidades que estamos describiendo. Además, ésta es una decisión crítica, porque puede afectar de manera decisiva al resto del equipo de desarrollo tanto a nivel humano (motivación) como técnico (carga de trabajo).

La única respuesta a esta pregunta es que el diseñador debe tomar decisiones de diseño.

Espera, Isilion. El diseño engloba todos los aspectos del producto. Eso equivale a decir que el diseñador decide todo, ¿no?

No. El diseño del juego determina todos los aspectos del producto, desde el más básico hasta el más nimio, pero no es necesario que sea el diseñador quien modele cada pequeño aspecto. Un equipo se compone de profesionales especializados cuyas aportaciones son imprescindibles para conseguir un acabado perfecto. Resulta mucho más útil transmitir a cada uno lo que esperamos de ellos, explicarle qué queremos conseguir. Cómo lo consiga cada uno es tarea suya. Ese será su granito de arena y su motivación.

Comunicación con los artistas

En un interesante comentario, Juan apuntaba el ejemplo de la introducción: “Oye, la capa del personaje pónmela roja, no negra“.

Quizá el personaje principal tenía una capa roja en tu cabeza, pero ¿realmente la necesitaba? Quizá para ti esa capa añade al personaje un cierto aire de superhéroe que ayuda a transmitir tu idea. Sin embargo, debemos ser conscientes de que el dibujante posiblemente sepa mucho más de temáticas de color y combinaciones que nosotros mismos.

Por otro lado ¿estás seguro de que la capa roja evoca en tu público objetivo las mismas sensaciones que en ti?

Aproximaciones sugeridas

Un buen método para transmitir nuestras ideas a los artistas es el descrito por los siguientes pasos:

1. Definición de límites: explicar quién es nuestro público objetivo.
2. Definición de objetivos: describir qué sensaciones pretendemos crear en nuestro público.
3. Ponderación de los elementos: concretar qué elementos son inamovibles y cuáles podemos dejar al criterio del artista.

Habitualmente nos resultará muy provechoso hablar un poco nuestros artistas, y dejarnos empapar por su cultura. Frecuentemente, él o ella conocerán herramientas o técnicas que nos serán desconocidas, pero resultarán las más apropiadas para conseguir el efecto que necesitamos. Por eso siempre debemos limitar nuestras restricciones a lo que sea verdaderamente imprescindible (“El protagonista es un bárbaro, así que debe llevar un hacha o una espada bien grande. Nada de rapieres ni main gauches“), para dar un mayor espacio creativo y evitar poner trabas inadvertidamente a esas técnicas o herramientas que desconocemos. Por supuesto, podemos ofrecer nuestras ideas a título orientativo, pero siempre evitando imponerlas.

Comunicación con los programadores

En un entorno ideal, no deberías tener la necesidad de dictar al equipo de programadores cómo tienen que implementar la parábola que describirá el proyectil arrojado por el personaje. El programador sabrá perfectamente cómo hacerlo, posiblemente mejor que tú mismo, e imponerle tu criterio sólo serviría para obligarle a restringir las posibles soluciones a un nivel de habilidad inferior a sus capacidades. Puede que tú también seas programador y que tengas tanta experiencia como él /ella o más, pero incluso en este caso, no es recomendable imponer una solución. Si aún así crees que debes hacerlo, pregúntate antes si eres consciente de todas y cada una de las repercusiones que tendrá esa decisión sobre el trabajo del programador y, en consecuencia, sobre el desarrollo del proyecto. Por ejemplo, estarías obligando a los programadores a usar unidades concretas, que quizá no fueran las más adecuadas para la plataforma tecnológica elegida.

Es responsabilidad de cada programador el decidir los detalles de la implementación y tú deberías darle todo el margen que te sea posible. Si las mecánicas de tu juego requieren una velocidad concreta, nunca digas un número exacto a no ser que sea absolutamente imprescindible. En vez de eso, ofrece una medida relativa al movimiento normal y deja que el programador decida el resto. De ese modo, si un programador decide que debe cambiar sus variables de tipo int por float, tus especificaciones seguirán siendo válidas.

Aproximaciones sugeridas

Supongamos la siguiente especificación base:

• El movimiento base del personaje en terreno llano es de 2 m/s. Sobre esta base se aplicarán los modificadores descritos más abajo en el mismo orden en el que se listan.
  
• Si el movimiento del personaje llega a cero (0) se detiene. Un movimiento negativo no tiene un efecto visible (no impulsa al personaje en dirección contraria).

Sobre esta base funcional, podríamos representar los diferentes tipos de movimiento del personaje a través de modificadores, valores relativos o diferentes niveles de lenguaje natural.

Los modificadores son números que se aplicarán sobre otros valores relativos o absolutos. Resultan útiles cuando hay muchas posibilidades en torno a pocos valores base. Al abstraer los modificadores, nos permite combinarlos entre ellos para ofrecer más posibilidades, pero aumentan la complejidad del diseño:

• + 50% cuando esté corriendo
• – 20% cuando esté subiendo una cuesta
• -10% en terreno pantanoso

Los valores relativos pueden imaginarse como un valor base con un modificador incorporado. Resultan útiles cuando hay pocas posibilidades en torno a un número cualquiera de valores base. Tienen la desventaja de no poderse combinar entre ellos, pero son muy sencillos de entender y evitan tener que hacer cálculos:

• 150% cuando esté corriendo
• 80% cuando esté subiendo una cuesta
• 90% en terreno pantanoso

El lenguaje natural nos permite dar al programador máxima libertad, pudiendo ser tan vagos o específicos como queramos. Cuando usamos lenguaje natural necesitamos especificar ciertos límites para evitar ser demasiado vagos. Este método es un arma de doble filo, ya que a pesar de ser extremadamente rápido, nos obliga a confiar en nuestra capacidad para discernir si los programadores van a entendernos sin necesidad de especificar detalladamente cada aspecto de la funcionalidad.

• El personaje avanzará más lento cuando esté subiendo una cuesta.
• El personaje avanzará más lento mientras más pronunciada sea la cuesta y se parará si se inclina demasiado.
  
• El personaje avanzará más lento mientras más pronunciada sea la cuesta y se parará en inclinaciones de 45º o más.

Aplicando las metodologías

Podemos resumir las metodologías planteadas en dos sencillas reglas:

1. Todas tus indicaciones deben estar orientadas hacia unas metas claras y definidas.
2. Debes asegurarte de que todos conocen esas metas. Si el programador escribió un programa que realiza correctamente una funcionalidad que entendió mal por alguna ambigüedad o laguna en el documento de diseño, posiblemente será más culpa tuya que suya. Si los demás conocen las metas del diseño es mucho más fácil que detecten cualquier incoherencia.

Anima, comenta, comparte tu ilusión con todos. Intenta no imponerte. Enriquécete con las ideas de los demás. Aprende de ellos y, sobre todas las cosas, escucha.