Esta es una traducción al español del artículo titulado Level 2: Game Design / Interation and Rapid Prototyping publicado en el blog Game Design Concepts.

 

La última sesión preguntamos: ¿qué es un juego? El día de hoy vemos una pregunta relacionada: ¿qué, exactamente, es el diseño de juego? La sesión anteior hicimos un juego sencillo. Esta vez veremos el proceso de como hacer juegos en general. Aunque es posible hacer un juego de carrera hasta el final en 15 minutos, necesitaras de un poco mas de tiempo si estas pensando en hacer el siguiente Settlers of Catan o World of Warcraft.

 

Anuncios del Curso

 

Algunas cosas administrativas que han surgido desde el lunes:

 

• Primero, quisiera disculparme con aquellos que se registraron por el mal comportamiento del wiki. Estaba enviando anuncios de actualizaciones cada hora... ¡y hubo un montón de actualizaciones! Intenté apagar esas actualizaciones, así que espero que no recibas más "wiki-spam" pero si aún sigues recibiéndolo, puedes apagarlo manualmente yendo a tu configuración y cambiando las notificaciones a "Nunca".
• Desde las 5AM hora GMT de esta mañana, los foros de discusión han sido levantados y están funcionando. Espero ver una buena discusión. Varios spambots trataron de registrarse, así que tuve que chequear cada cuenta del foro contra los registros del curso. Si recibiste un correo con que tu cuenta fue rechazada, significa que no pude conseguirla en los registros del curso: simplemente intenta nuevamente. Si no has podido crear una cuenta para el foro, puedes hacerlo más fácil para utilizando en los foros el mismo correo que utilizaste para registrarte al curso... y si no quieres hacer eso, al menos pon alguna información que te identifique (como tu nombre y ubicación) para que te pueda encontrar en la lista. Gracias.
• Finalmente, a aquellos que hayan enviado un correo de registro después de comenzado el curso (eso es, tu correo fue enviado después del lunes a mediodía, hora GMT), me disculpo por no poderlos agregar. Los correos de registro han tomado mucho de mi tiempo previo al inicio del curso, y si acepto registros tardíos no tendré el tiempo de hacer otras cosas para el curso. Estés registrado o no, este blog es libre y abierto al público (tal como la fuente de Twitter), y espero que aún me sigas y saques mucho de esta experiencia.

 

Diseño de Juegos

 

Utilizaremos mucho la palabra "diseño" en este curso, y desafortunadamente es un término que está un poco sobreutilizado, así que aclararé lo que significa aquí. Como lo dice en Challenges, el diseño de juegos es la creación de reglas y contenido de un juego. No involucra programación, arte o animación, o marketing, o cualquiera de la multitud de tareas requeridas para hacer un juego. Todas estas tareas se pueden agrupar y llamar "desarrollo de juegos" y el diseño de juegos es una parte del desarrollo.

 

Desafortunadamente, he visto el término "diseño" utilizado (particularmente en los programas universitarios) para referirse a todos los aspectos del desarrollo. Cuando se usa en la industria del videojuego (o en la industria de los juegos de mesa), "diseño de juegos" tiene un significado muy específico, y ese significado es el que utilizaremos durante este curso.

 

Múltiples Tipos de Diseño de Juegos

 

Como fue mencionado en Challenges, existen muchas tareas asociadas con el diseño de juegos: diseño de sistemas, diseño de niveles, diseño de contenido, diseño de interfaces de usuario, construcción de mundos y escritura de historias. Podrías llenar varios cursos de 10 semanas con cualquiera de estos temas, así que este curso de verano <i>no</i> será un tratado completo del rango entero del diseño de juegos. Veremos ligeramente las interfaces, de la escritura y del contenido cuando sea relevante, pero la mayoría de este curso en enfoca en diseño de sistemas (algunas veces llamado también "diseño de sistemas base" [N.T. se traducirá correctamente así?]).

 

El diseño de sistema es acerca de definir las reglas básicas para un juego. ¿Cuáles son las piezas? ¿Qué puedes controlar? ¿Qué acciones puedes tomar en tu turno (si, en efecto, hay "turnos")? ¿Qué pasa cuando tomas cada acción, y cómo afecta el estado del juego? En general, el diseño de sistemas es la creación de tres cosas:

 

• Reglas de inicio. ¿Cómo comienza el juego?
• Reglas de progreso del juego. Una vez que inicia el juego, ¿qué puedes hacer los jugadores?, y ¿qué pasa cuando hacen cosas?
• Reglas de resolución. ¿Qué pasa si algo causa que el juego termine? Si el juego tiene un resultado (tal como ganar o perder), ¿cómo se determina ese resultado?

 

Si ves al Three to Fifteen del lunes, notarás que esas reglas tan simples contienen todas estas partes. La creación de esas reglas es el diseño de sistemas, y es con lo que estaremos más tiempo durante este verano.

 

¿Qué es un diseñador de juegos?

 

Como habrás notado, el diseño de juegos es un campo increíblemente amplio. Nosotros los diseñadores profesionales a veces nos cuesta explicar lo que hacemos a nuestros familiares y amigos. Parte de la razón de esto es que hacemos muchas cosas. He aquí algunas de las analogías que he visto cuando se trata de explicar qué es lo que se siente ser un diseñador de juegos:

 

• Los diseñadores de juegos son artistas. El término "arte" es es tan dificil de definir como lo es el término "juego"... pero si los juegos pueden ser una forma de arte (al menos, tal como lo vimos en la definición de Costikyan), entonces los diseñadores serían artistas.
• Los diseñadores de juegos son arquitectos. Los arquitectos no construyen estructuras físicas; crean planos. Los diseñadores de videojuegos también crean "planos" que son referidos como "documentos de diseño". Los diseñadores de juegos de mesa crean "planos" también, en la forma de prototipos, los cuales son después producidos en masa por los publicadores. [N.T. ¿Forma correcta de decir publisher?]
• Los diseñadores de juegos son anfitriones de fiesta. Como diseñadores, invitamos a los jugadores en nuestro espacio y hacemos lo mejor posible para darles un buen tiempo.
• Los diseñadores de juegos son investigadores científicos. Como lo diré más adelante, creamos juegos de una manera que se acerca mucho al método científico.
• Los diseñadores de juegos son dioses. Creamos mundos, y creamos las reglas físicas que gobiernan esos mundos.
• Los diseñadores de juegos son abogados. Creamos un conjunto de reglas que otros deben seguir.
• Los diseñadores de juegos son educadores. Como ya lo veremos más adelante cuando comencemos a leer Theory of Fun, el entretenimiento y la educación están altamente relacionados, y los juegos son (al menos algunas veces) divertidos porque involucran aprender nuevas habilidades.

 

Si el diseño de juegos son todas estas cosas, ¿en dónde cabrían en un curriculum universitario? Podría justificarse en la escuela de educación, o arte, o arquitectura, o teología, o gerencia de recreación, o leyes, o ingeniería, o ciencias aplicadas, o media docena de otras cosas.

 

¿Es un diseñador de juegos todas estas cosas? ¿Ninguna de ellas? Está abierto a discusión, pero creo que el diseño de juegos tiene elementos de muchos otros campos, pero es sigue siendo un campo por sí solo. ¡Y puedes ver qué amplio es el campo! A medida que el campo del diseño de juegos avance, quizás veamos el día en el que los diseñadores de juegos estén tan especializados que el "diseño de juegos" sea como el campo de la "ciencia" -- lo estudiantes necesitarán escoger una especialidad (química, biología, física, etc.) en vez de solamente "graduarse en Ciencias".

 

Hablando de Ciencia...

 

¿Cómo se diseña un juego? Existen varios métodos.

 

Históricamente, la primera metología de diseño se conoce como el método cascada: primero diseñas otodo el juego en papel, luego lo implementas (usando programación en el caso del videojuego, o creando el tablero y las piezas para uno no digital), luego lo pruebas para asegurarte de que las reglas funcionen apropiadamente, agregas un detalle gráfico para hacer que se vea bien, y luego lo publicas.

 

[Ilustración] <- Falta traducción

 

El método cascada se llama así porque, como el agua en una cascada, sólo puedes moverte en una dirección. Si estás ocupado haciendo el arte final del juego y se te ocurre que una del as reglas necesita ser cambiada, qué mal -- la metodología no incluye una manera de regresar a la etapa de diseño una vez que hayas terminado.

 

En algún punto, a alguien se le ocurrió que era una buena idea de tener al menos una posibilidad de volver y arreglas las cosas de pasos anteriores, y creó lo que se conoce algunas veces como el método iterativo. Como en cascada, primero diseñas el juego, luego lo implementas y luego te aseguras de que funciona. Pero después de esto agregas el paso extra de evaluar el juego. Juégalo, decide qué es bueno y qué necesita ser cambiado. Y luego haces una decisión: estás listo, o vuelves a la etapa de diseño, encuentras la manera de arreglas los problemas identificados, y luego evalúas nuevamente. Continúa haciendo esto hasta que el juego esté listo.

 

[Ilustración] <- Falta traducción

 

Si esto te suena familiar, es porque se parece más o menos al Método Científico:

 

1. Hacer una observación ("Mi experiencia en jugar y hacer juegos me ha mostrado que algunos tipos de mecanismos son divertidos.")
2. Hacer una hipótesis. ("Yo creo que este conjunto particular de reglas que estoy escribiendo hará un juego divertido.")
3. Crear un experimento que pruebe o rechace la hipótesis. ("Hagamos una sesión de pruebas de este juego y veamos si es divertido o no.")
4. Hacer el experimento. ("¡Juguemos!")
5. Interpretar los resultados del experimento, hacer un nuevo conjunto de observaciones. Volver al primer paso.

 

Con los juegos no digitales (cartas y tableros), este proceso funciona bien, porque puede ser hecho rápidamente. Con los videojuegos, existe un problema: la implementación (ej. programar y depurar) es costosa y toma tiempo. Si toma 18 meses escribir el código del juego la primera vez y solo tienes 2 años, no vas a tener mucho tiempo de probar y modificar el juego.

 

En general, mientras más veces iteres, mejor el juego final será.

 

Por lo tanto, cualquier proceso de diseño de juegos debería involucrar la iteración (esto es, ir por un ciclo entero de diseño, implementación y evaluación) tanto como sea posible, y cualquier cosa que te permita iterar más rápidmente usualmente llevará a un mejor juego al final. Por esto, los diseñadores de videojuegos por lo general se encontrarán prototipando el juego en papel primero, y luego solamente involucran a los programadores cuando estén seguros de que las reglas básicas sean divertidas. A esto lo llamamos prototipado rápido.

 

[Ilustración] <- Falta traducción

 

Iteración y Riesgo

 

Los juegos tienen muchos tipos de riesgos asociados con ellos. Está el riesgo de diseño, el riesgo de que el juego no será divertido y que a la gente no le gustará. Está el riesgo de implementación, que es la posibilidad de que el equipo de desarrollo no sea capaz de construir el juego, incluso si las reglas son sólidas. Está el riesgo de mercado, que es el chance de que juego sea maravilloso pero aún  así nadie lo compre. Y así sucesivamente.

 

El propósito de la iteración es reducir el riesgo de diseño. Mientras más veces iteres, más podrás estar seguro de que las reglas de tu juego serán efectivas.

 

Todo esto viene a un punto importante: mientras más grande sea el riesgo de diseño de tu juego (eso es, si tus reglas no son probadas), más iteraciones vas a necesitar. Un método iterativo no es crítico para juegos en los que la mecánica son copiadas en gran parte de otro juego exitoso; las secuelas y los sets de expansón de juegos populares son ejemplos de situaciones en los que una aproximación con Cascada puede funcionar bien.

 

Una vez dicho eso, muchos diseñadores de juegos tienen aspiraciones de hacer juegos que son nuevos, creativos e innovadores.

 

Por qué este curso es no-digital...

 

Algunos de ustedes quieren hacer juegos de mesa de todos modos, así que no les importa cómo se hacen los videojuegos. Pero aquellos que quisieran hacer videojuegos, probablemente se hayan preguntado por qué van a estar haciendo juegos de mesa y de cartas durante tanto tiempo en este curso. Ahora ya lo sabes: porque iterar es más rápido y barato con papel y cartón. Recuerda del lunes: puedes hacer un juego de mesa en 15 minutos. Programar ese juego te tomará mucho más tiempo. Cuando sea posible, haz el prototipo en papel primero, porque un prototipo de papel en 15 minutos y una sesión de pruebas de una hora te pueden ahorrar meses de programación.

 

Luego en este curso, discutiremos detalladamente los métodos de prototipos en papel, tanto para juegos de mesa tradicionales como para varios tipos de videojuegos.

 

Existe otra razón por la que nos concentraremos principalmente en juegos no digitales en este verano, particularmente juegos de mesa y de cartas. Este es un curso en diseño de sistemas, esto es, crear las reglas del juego. En juegos de mesa, las reglas están dispuestas claramente. Puede que haya algunos componentes físicos, por supuesto, pero la experiencia de juego está casi en su totalidad determinada por las reglas y las interacciones del jugador. Si las reglas no son irresistibles, el juego no será divertido, así que trabajar con este medio hace una conexión clara entre las reglas y la experiencia del jugador.

 

Eso no es verdad en los videojuegos. Muchos videojuegos tienen tecnología impresionante (tal como motores físicos realísticos) y gráficos y sonidos, lo cual puede ocultar el hecho de que la jugabilidad es horrible. Los videojuegos también tardan mucho tiempo en realizarse (debido a la programación y a la creación de recursos gráficos y auditivos), haciendo que sean una opción impráctica para un curso de diez semanas.

 

La conexión entre las reglas y la experiencia del jugador es también poco clara en los juegos de rol de mesa. Tengo entendido que muchos de ustedes han expresado interés principalmente en diseño de RPGs, así que puede parecerles extraño esto. Sin embargo, ten en cuenta que un RPG es esencialmente un ejercicio de contar cuentos colaborativamente (con un sistema de reglas que pone límites de lo que se puede y no se puede hacer). Como tal, un sistema maravilloso puede ser arruinado por jugadores que tienen pocas habilidades para contar historias o habilidades de improvisación, y un sistema debil puede ser rescatado por jugadores talentosos. Como tal, nos mantendremos alejados de estos géneros de juegos, al menos en las etapas iniciales.

 

Intentándolo

 

Agarra ese juego de 15 minutos que hiciste la última vez y juégalo, si ya no lo has hecho. Mientras juegas, pregúntate: ¿es esto más divertido o menos divertido que jugar tus juegos publicados favoritos? ¿por qué? ¿qué podrías cambiar de tu juego para hacerlo mejor? No tienes que jugar el juego hasta completarlo, sino lo que te tome para notar la sensación general de cómo se juega.

 

Después de jugarlo una vez, haz al menos un cambio. Pueden ser las reglas para moverse, o agregar nuevos jugadores para interactuar. Puede que cambies algunos de los espacios en el tablero. Lo que sea que hagas, sea la razón que sea, haz un cambio y vuelve a jugarlo. Nota las diferencias. ¿El cambio mejoró el juego, o lo empeoró? ¿Te ha hecho pensar este cambio en otros cambios que podrías hacer? Si el juego empeoró, ¿cambiarías de vuelta la regla, o lo cambiarías de una manera distinta?

 

Estaremos viendo el proceso de prueba de juego más adelante en este curso. Por ahora, Quiero que todos superen ese miedo: "¿qué pasa si juego mi juego y apesta?" Con el juego que diseñaste en la primera lección, las probabilidades son muy altas de que tu juego realmente apeste (seriamente, ¿esperabas hacer el próxim Gears of War en 15 minutos?). Esto en absoluto te hace un "mal diseñador" -- pero debería dejarte claro que mientras más tiempo inviertas en un juego y más iteraciones hagas, mejor se va a poner.

 

Lecciones aprendidas

 

La gran lección aprendida hoy es que mientras más iteres el juego, mejor se pone. Los grandes diseñadores no diseñan grandes juegos. Usualmente diseñan juegos realmente malos, y luego los iteran hasta que los juegos se vuelven buenos.

 

Esto tiene dos corolarios:

 

• Quieres tener un prototipo jugable de tu juego tan pronto como sea posible en el desarrollo. Mientras más rápido puedas probar tus ideas, más tiempo tendrás para hacer cambios.
• Dado el mismo tiempo, un juego más corto y simpe ofrecerá una mejor experiencia que juego largo y complicado. Un juego que toma 10 horas para jugar hasta completarlo te va a dar menos iteraciones que un juego que puede ser jugado en cinco minutos, Cuando comencemos el Proyecto de Diseño más adelante en este curso, ten esto en cuenta.

 

Juegos para la Casa

 

Antes de la próxima lección, lee lo siguiente. Estaré referenciando estos en ese contenido cuando hablemos de los elementos formales de los juegos:

 

• Challenges for Game Designers, Capítulo 2 (Átomos). Esto actuará como puente entre la lección pasada cuando hablamos de un vocabulario crítico, y la próxima en la que comenzaremos a explorar el concepto de "juego" en sus componentes.
• Herramientas Formales Abstractas de Diseño, por Doug Church. Este artículose basa en el de Costikyan, I Have No Words, ofreciendo unas herramientas adicionales con las que podemos analizar y diseñar juegos. Aunque utiliza muchos ejemplos de videojuegos, piensa en cómo los conceptos fundamentales del artículo pueden aplicarse a otros juegos también.