Diseñador, no dictador

el-gran-dictador-chaplin.jpgEl 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.

Advertisements

About Isilion

Musician, neophyte humanist, home-philosopher, avid reader and impassioned conversationalist. I like coffee and people and dislike shouting and anger.

11 responses to “Diseñador, no dictador”

  1. javi says :

    buen artículo, sí señor 🙂

  2. zonya says :

    en el sector en el que me muevo, el de la comunicacion y la formacion, los problemas vienen en el maravilloso triangulo programador – diseñador – copy.
    y ahora voy a llorar: siempre sale perdiendo el copy 😦 el texto es lo primero que todo el mundo decide sacrificar para beneficiar al diseño y a la programacion. cuando en verdad no se trata de hacer un triangulo isosceles, sino un equilatero. por ello es importante la comunicacion entre departamentos, conocer lo que hace el de al lado y saber cual es tu lugar.
    y un consejo que me dio mi jedi: nunca des nada por hecho y explica las cosas “a lo barrio sesamo”. es una buena manera de evitar malentendidos.

    bZoZ!

  3. Isilion says :

    Tu Jedi es una persona sabia. Yo siempre digo que en el trabajo me gustan las explicaciones foolproof. Cuando de tus palabras depende el tiempo de otras personas tienes que esforzarte por evitar los errores o ambigüedades.

    Con respecto a que siempre sale perdiendo el texto, estoy de acuerdo, pero no en todos los ámbitos es algo malo. Durante el desarrollo de un juego el texto es simplemente una herramienta para que todos puedan saber qué piensa otra persona y recordarlo leyéndolo cuando les sea necesario. En algunas ocasiones me he visto obligado a modificar un documento de diseño para incluir modificaciones de diseño que se han producido posteriormente, durante la implementación. Esto salvaguarda la corrección del texto y su función referencial, pero a veces es inútil desde el punto de vista de desarrollo, porque en ciertos casos, ese documento ya no servirá para el futuro, ya que lo que describía ya se ha implementado.

    En cualquier caso, siempre es extremadamente útil conocer el día a día de tus compañeros y colaboradores. Entender las cosas y ponerte en la piel de los demás te evita enfados innecesarios y es un escudo contra la desmotivación.

  4. Ludo says :

    Es un placer verte de nuevo en la carretera Isilion… gran articulo si señor!

  5. Juan P. says :

    Yo siempre hablo de sensaciones, de qué quiero transmitir al jugador, y esa misma visión es la que intento hacer visualizar a los miembros del equipo. Por eso, lo que busco es, más que mi visión del personaje (capas rojas y tal), es esa misma visión en la mente del equipo. Que cada cual añada su granito de arena en ese aspecto. Hablemos de sensaciones, no de cosas puntuales. De lo que debemos transmitir, no de lo que “yo” quiero transmitir (en otras áreas que no son diseño de juego, que para eso cuentas con un equipo de profesionales).
    puedes orientar, pero no restringir la creatividad de los demás. Porque incluso los programadores tienen creatividad.

  6. Isilion says :

    Esa es justo la aproximación que yo creo que es más correcta, muy bien plasmado.

    Con respecto a la programación, en contra de lo que se suele pensar, es una profesión que conlleva un altísimo grado de creatividad; el hecho de que sea una ingeniería, donde te explican la mejor manera de hacer algo no significa que alguien no haya tenido que crear esas soluciones, habitualmente de maneras que te dejan atónito. Además, cada día en la vida de un programador está plagado de “¿Y ahora cómo hago esto?”‘s, lo cual, necesariamente, te obliga a estar buscando soluciones creativas que se ajusten a las restricciones del sistema particular y único en el que estás trabajando en este momento.

%d bloggers like this: