Diseñar es hacer las cosas bien

Diseñar algo consiste básicamente en pensar en todos los posibles escenarios que pueden darse en un entorno concreto e ingeniárnoslas para que todos los caminos conduzcan hacia un objetivo predefinido.

Las reglas básicas del diseño son aplicables a todos sus campos: simplicidad, consistencia y una buena composición suelen ser garantía de buenos resultados en un juego, como también lo eran antes de la invención de los ordenadores.

Algunas de estas reglas son las siguientes:

• El diseño ha de servir al contenido, y debe elaborarse en función a éste
• El diseño debe estar bien organizado y estructurado
• Debe existir contraste entre los elementos, ayudando a diferenciarlos en unidades y subunidades
• Los elementos clave deben enfatizarse
• Un buen diseño a menudo tiende a la simplicidad
• La consistencia debe ser un criterio prioritario

Desde mi punto de vista, y simplificándolo al máximo, el diseño de cualquier programa se puede dividir en dos niveles, interno y externo, en cada uno de los cuales se pueden aplicar los criterios anteriores:

• El interno corresponde a las mecánicas del programa, lo que hace éste y cómo lo hace
• El externo corresponde a los elementos a través de los cuales el usuario interacciona con el programa (envía información y la recibe)

Diseño interno o de las mecánicas del juego

El diseño interno de un programa es todo aquél que no se ve, pero se percibe a través de la interfaz. Es la lógica que conduce al juego. A la hora de escribir estas mecánicas conviene tener en cuenta estas reglas básicas:

• Antes de sentarte a programar o de implicar a otros asegúrate de que tu idea es factible
• No estás diseñando un juego para ti, sino para tu público objetivo. Puede que el juego te resulte aburrido. Ten por seguro que muchos otros profesionales no siempre realizan su trabajo en el ámbito que les gustaría o con los clientes que desearían. Averigua cuál es el perfil de tu público y cada vez que vayas a introducir una funcionalidad piensa si será de su agrado.
• Divide y vencerás. Si el sistema que estás diseñando es demasiado grande, trata de dividirlo en partes independientes que trabajen interaccionando entre ellas y diséñalas como si fueran pequeños juegos separados.
• Piensa en las consecuencias. Apenas tengas las mecánicas básicas de tu juego, intenta discernir cuántos recursos necesitarás. Pensar en cuántos modelos, animaciones, sonidos o efectos especiales necesitarás te dará una visión más realista de la factibilidad del proyecto y a veces te hará desestimar opciones sin tener que llegar a constatar empíricamente que no eran factibles, ahorrando tiempo y esfuerzo a todo el equipo
• Pedir prestado no es un delito. Si has visto algo que funciona excelentemente en otro juego, no es un problema que lo utilices. Tendrás un problema cuando nueve de cada diez mecánicas de tu juego sean iguales a las de otro, pero nadie se preocupará si haces que tu barra de salud funcione igual que todas las barras de salud del mercado (a no ser que el centro de tu juego consista únicamente en interaccionar con una barra de salud).
• Cíñete a los requisitos. A medida que se diseña se tiende a abstraer más de lo necesario, con el objetivo de reutilizar las mecánicas en otros entornos. A pesar de que esto es una buena práctica, no puedes perder de vista que tienes unos objetivos y un tiempo limitado para cumplirlos. Piensa bien cómo los vas a satisfacer y, si puedes, imagina un ciclo de ejecución de la mecánica al completo. Un buena práctica es ir dibujando un esquema del proceso a medida que lo vas ejecutando en tu cabeza, apuntando los valores de todos los parámetros involucrados (por ejemplo, potencia de ataque, puntos de vida, probabilidades de fallo…). Si lo haces así, tus diseños serán mejores y más sólidos.
• Justifica tus decisiones. Cuando alguien vea tu diseño seguramente creerá encontrar fallos en él. Algunas veces, esos fallos serán reales, pero otras los errores no serán tales, sino que responderán a necesidades de diseño que sólo tú conoces. El proceso de identificar un supuesto error, que llegue hasta ti, que lo justifiques, que alguien lea la justificación (que no tiene por qué ser pequeña) y que la apruebe, puede ser bastante largo. Pon solución a este problema antes de que suceda, explicando donde sea aplicable que aunque la solución más evidente parece ser A, has constatado que no es válida y por eso has elegido B. No es necesario que expliques por qué no es válida en demasiada profundidad. Habitualmente quien lea el documento sabrá que no es un error y que tú ya has pensado en eso, lo cual evitará por norma general el malentendido, aunque suele ser buena idea incluir una referencia explicando dónde se puede encontrar la explicación detallada (quizá en otro capítulo, en otro documento o en unos anexos)
• Haz copias de tu trabajo antes de tomar decisiones críticas. Si descubres que ese sistema de combate que ha modificado las mecánicas de medio juego no es adecuado por algún motivo, necesitarás poder volver rápidamente al momento en el que lo introdujiste. Si estás utilizando sistemas como un SVN, será suficiente con que guardes todo en el repositorio. Si trabajas con métodos más tradicionales, lo más conveniente suele ser hacer una copia de todos los archivos y etiquetarla, para que en el futuro la podamos identificar. A pesar de que esto parece muy evidente, es un problema que sucede frecuentemente y al cual se le da poca importancia. Hasta que sucede.

Diseño externo o de la interfaz de usuario

Tomando prestadas las palabras de Moix,

“No debemos perder de vista una cosa: que nos sea posible manejar miles de colores, centenares de letras, docenas de efectos especiales, y que los podamos combinar de un millón de maneras, no significa que debamos hacerlo. Nuestros trabajos y/o publicaciones no tienen que parecer un catálogo de colores de pintura o un cartel de circo (a menos que sean un catálogo de colores de pintura o un cartel de circo)”

Joel Spolsky escribe en un magnífico artículo de Diseño de Interfaces:

Una interfaz de usuario está bien diseñada cuando el programa se comporta exactamente como el usuario piensa que lo haría.

Si no fuera así, el usuario tendría que estar luchando con los controles, cuando lo que quiere hacer es jugar. Aunque es posible que la interfaz reaccione incluso mejor de lo que el usuario esperaba, si le obligamos a pasar por un proceso demasiado diferente del que creía que iba a encontrar, sin guiarle a través de él, le provocaremos frustración.

¿Me lo puedes resumir?

Si haces un buen diseño al principio, el resto consistirá en darle pequeños empujoncitos al proyecto para que se vaya ajustando a lo que tenías planeado. Si no habías previsto todos los escenarios, tendrás que dividir tus esfuerzos entre cambiar tu diseño para contemplar las nuevas posibilidades, lo cual seguramente obligará a todos a que rehagan lo que les dijiste que hicieran.

¿Imaginas a alguien construyendo una casa sobre la marcha, sin haber pensado antes cuánto peso tendrán que soportar los cimientos cuando esté acabado?

Intenta pensarlo todo, y cuando lo hayas hecho, deja que pasen unos días y vuelve a pensarlo. Coméntalo con toda la gente que puedas (pero procura que no trabajen para la competencia).

Fuente: Ludosofía