Perlenspiel Logo

Lehr und Kunst mit Perlenspiel (2012)

Expuesta el 5 de Marzo de 2012 como conferencia principal de la Cumbre Educacional en la Game Developer's Conference de 2012 en San Francisco.

La exposición original incluyó varias muestras de trabajos de estudiantes. Algunas de ellas disponibles en la web de Perlenspiel.

§

El título de esta conferencia es “Lehr und Kunst mit Perlenspiel”.

Lehr und Kunst resulta ser el lema Alemán del Worcester Polytechnic Institute, donde soy Profesor de Prácticas en el programa Interactive Media and Game Development.

Lehr comparte raíz con la palabra Inglesa learning.1 El WPI traduce oficialmente esta palabra como teoría.

Kunst es traducido como práctica, como en la artesanía o el arte.

Esta, lo prometo, será la única ocasión en la que la palabra “arte” aparezca en esta conferencia.

§

Recuerdo mi primer semestre como estudiante de último curso en el instituto.

Era el momento de empezar a pensar en la universidad. El momento de decidir a dónde ir y qué estudiar.

No tenía ni idea de qué quería hacer con mi vida.

Me gustaba leer, dibujar, pintar y hacer películas cuando podía permitírmelo.

Me gustaban los ordenadores, también, a pesar de no haber utilizado uno nunca, a excepción de los computadores de juguete que me había construido yo mismo.

Pero mi mayor pasión, tanto entonces como ahora, era la música.

Recuerdo ir a la oficina del orientador vocacional y llevarme a casa catálogos de las academias de música del área de Boston.

El Longy School, el Berklee School, el Conservatorio de Boston, los departamentos de música de las grandes universidades.

Me sentí atraído por el NEC, el Conservarorio de Música de Nueva Inglaterra, pasando las páginas texturizadas de su catálogo lujosamente editado y leyendo las descripciones de los cursos.

Soñando despierto, me imaginé a mí mismo aceptando un riguroso y probado programa basado en siglos de tradición, guiado por músicos y compositores de gran renombre mundial.

Dominando las complejidades de la armonía y el contrapunto, navegando las últimas sonatas de Beethoven y Schubert, vistiendo un esmoquin e interpretando recitales a la vuelta de la esquina del Symphony Hall.

Pero cuando pasé a la página de requisitos de admisión, se me cayó el alma a los pies.

Ninguna academia de música respetable admitía a nadie sin una audición.

Y aunque tenía alguna habilidad como pianista autodidacta, apenas podía leer una nota.

La página de matrícula era igualmente excluyente.

Acabé yendo a una universidad estatal barata para estudiar diseño gráfico, en base a una muestra de de películas de 16mm pintadas a mano, y de alguna manera me gradué con un título de Lengua Inglesa.

Cuarenta años más tarde, tras una larga y curiosa carrera, me encuentro en la cara opuesta de mi fantasía universitaria.

Mientras hablo, estudiantes de último curso de instituto pasan las páginas de catálogos, fantaseando sobre cómo sería convertirse en estudiante de diseño de juegos digitales.

¿Cómo son nuestros cursos en sus ensoñaciones?

No importa lo que imaginen, una cosa es cierta.

No será como ir a una academia de música.

No habrá audiciones. Poca o ninguna experiencia es requerida en cualquier escuela de juegos que conozca.

Tampoco tendrán que observar-leer nada. No tenemos ninguna forma de leer mecánicas de juego. Muchos de nosotros probablemente no podríamos ponernos de acuerdo sobre qué es una “mecánica de juego” en cualquier caso.

Tampoco se enfrentarán a un riguroso y probado programa. Lo sé, porque yo busqué uno.

Al ser nombrado para el WPI, la primera cosa que hice fue tratar de averiguar cómo estaba enseñando diseño de juegos digitales otra gente.

Descubrí lo que muchos de los aquí presentes saben de sobra.

No hay textos estándar, herramientas ni programas de estudio.

Gradus ad Parnassum

No tenemos ningún libro como Gradus ad Parnassum, publicado en 1725 por Johan Fux, que sintetiza la pedagogía musical de tres siglos en un método paso a paso para enseñar el contrapunto y la fuga.

El Gradus sirvió como libro de texto a Bach en el siglo dieciocho, a Haydn y Beethoven en el diecinueve, a Hindemith y Strauss en el veinte.

Las técnicas en las que fue pionero todavía son utilizadas a día de hoy.

También carecemos de un motor común, o instrumento si prefieren llamarlo así, que pueda ser utilizado para expresar, practicar y componer juegos.

Tenemos muchos teclados, pero ningún piano.

Esta fantasía mía, esta ensoñación del diseño de juegos siendo enseñado con el austero refinamiento de la buena música podría resultarles pomposa.

Quizás incluso un poco elitista.

Pero es que la idea tiene un precedente de élite.

Das Glasperlenspiel

En 1943, mientras la Segunda Guerra Mundial se acercaba a su clímax en Europa, un anciano Alemán afincado en Suiza publicó la última novela de su carrera.

Esta obra maestra en dos volúmenes fue posteriormente citada por un comité que la galardonó con el Premio Nobel de Literatura.

El autor era Herman Hesse, y la novela era Das Glasperlenspiel, El Juego de los Abalorios.

Situada en una Europa más pacífica a cientos de años en el futuro, El Juego de los Abalorios describe una academia de élite dedicada al diseño y estudio del último reto intelectual, una especie de super-Scrabble que combina música, matemáticas, lingüística, meditación e incluso caligrafía en un ritual competitivo que requiere toda una vida para ser dominado.

Las reglas del Juego de los Abalorios nunca son explicadas por completo. Las descripciones de Hesse son elípticas, cautivadoras, y han fascinado a generaciones de lectores.

Una rápida búsqueda en la Web revela numerosos intentos de diseñar un juego viable basado en el esbozo de Hesse. Músicos y artistas también han sido inspirados por la envergadura enciclopédica del juego y su elegancia formal.

Al menos una religión menor parece haberse fundado bajo sus principios.

La visión de Hesse sobre el diseño de juegos como una noble disciplina ha sido desde hace mucho una inspiración para mí.

Pero su visión fue de poca ayuda allá por 2009, cuando se me dieron unas pocas semanas para desarrollar un curso de diseño de juegos digitales.

Antes de este encargo, había pasado 27 años en la industria del videojuego diseñando una ecléctica serie de títulos que iban desde aventuras textuales y gráficas a rail shooters2 en full-motion-video3 y juegos indecentes para teléfonos móviles, culminando en una muñeca parlante de Dora adolescente que fue notoriamente condenada por ser demasiado delgada.

Nunca me paré a pensar demasiado cómo hacía lo que estaba haciendo.

Simplemente lo hacía lo mejor que podía, tratando de no avergonzarme a mí mismo, y esperando hacerlo mejor la próxima vez.

Pero ahora tenía que proponer un plan de estudios, deberes, y exámenes, y un criterio de evaluación. Tenía que pasar por un profesor real.

De modo que estudié los cursos ofrecidos por otras escuelas. Leí todos los libros de texto importantes sobre el tema, tal como están.

Encontré unas pocas cosas que me gustaron de verdad.

Challenges for Game Designers  Game Design Workshop  The Art of Game Design

El primer libro usa métodos y material de los juegos en papel para introducir conceptos esenciales para los juegos digitales. Ofrece un enfoque práctico y directo que encuentro muy atractivo.

El segundo título desarrolla las oportunidades y los escollos del diseño con una particular claridad.

Y el tercer libro acentúa el proceso creativo en sí mismo, considerando no sólo cómo crear juegos, sino también por qué.

Piecepack

También me gustó la idea de los piecepack, como por ejemplo este vendido por Mesomorph Games. Un piecepack es un conjunto de componentes para juegos de mesa genéricos, dados, fichas y cosas así. Es lo más parecido a un kit de creación de juegos que he podido encontrar.

Consideré la posibilidad de usar un juego de piezas para mis clases del curso. Pero había dos problemas.

Primero, el WPI ya tiene un excelente curso sobre diseño de juegos de mesa.

Uno de nuestros profesores de física, el Dr. George Phillies, también resulta ser una autoridad en juegos bélicos clásicos de mesa. Posee la mayor colección privada del mundo.

Mi segundo problema era más fundamental.

Por favor, discúlpenme esto. Voy a revelar uno de mis más profundos prejuicios.

Allá por los comienzos de los '80, entré en el negocio de los juegos digitales como editor técnico de ANALOG Computing, una revista dedicada a los ordenadores domésticos Atari.

Reseñaba lenguajes de programación y hardware mientras escribía programas de utilidades, demos y juegos. Mi código fuente era impreso en la revista para que los aficionados lo escribieran a mano.

Fui contratado por Infocom para escribir intérpretes en lenguaje ensamblador 6502 para sus juegos de aventuras. Más tarde, como implementador, pasé años escribiendo decenas de miles de líneas de código en ZIL, un lenguaje específico basado en MDL y Lisp.

Me encargué en persona prácticamente de todo el código en SCUMM del Loom de Lucasfilm.

Aunque soy principalmente conocido como diseñador, tengo fluidez en varios lenguajes de programación, y me he ganado la vida escribiendo el código de la mayoría de los juegos que llevan mi nombre.

Para mí, los juegos digitales están hechos de código.

He contratado a algunos diseñadores de juegos a lo largo de los años.

Si ponen a dos diseñadores por lo demás con el mismo talento y credenciales frente a mí, siempre elegiré al que sepa escribir código.

Decidí que la actividad fundamental de mis estudiantes debería ser, debe ser, expresar ideas de juego en código.

Ahora tenía que elegir un motor.

Miré AGS, Flash, Flixel, GameMaker, Inform, Kodu, Love, PyGame, Scratch, Source, Torque, UDK y Unity.

Miré especialmente en profundidad el Processing del MIT, que tiene muchas cualidades admirables.

Pero ninguno de ellos me parecía del todo bien.

Algunos usan lenguajes de scripting privados que no se encuentran en ninguna otra parte. Otros son adecuados sólo para construir un tipo de juego particular. Muchos tienen enormes APIs,4 pipelines,5 quisquillosos, o documentación menos que adecuada.

Nuestros cursos universitarios en el WPI duran sólo siete semanas. No quería que mis estudiantes pasaran la mayoría del curso poniéndose al día.

Quería que crearan montones de juegos, no sólo uno o dos.

Peor todavía. El WPI no tiene prerrequisitos para el curso. No había garantías de que todos mis estudiantes fueran ingenieros. Un tercio de los estudiantes de nuestro programa de juegos son artistas con muy poca o ninguna experiencia en escribir código.

Lo que nos lleva a dos problemas insalvables más: Gráficos y sonido.

No quería que algunos estudiantes se encargaran de hacer todo el código mientras otros se peleaban por los recursos y el pipeline. Ya teníamos muchos cursos como ese.

Se suponía que este debía ser un curso sobre diseño de juegos, no producción de juegos.

Quería que todo el mundo tuviera la oportunidad de expresar ideas de juego en código.

Quería un motor lo suficientemente simple como para que cualquiera lo dominara en un par de semanas, pero lo suficientemente profundo como para realizar diseños significativos.

Un motor que usara un lenguaje de scripting bien documentado y habitual en la industria y que fuera inherentemente valioso de aprender.

Un lenguaje soportado por un entorno de desarrollo profesional como Eclipse, con puntos de interrupción y debugging y perfiles.

Un lenguaje que quedara bien en un currículum.

Pero también necesitaba un motor que no requiriera recursos ni pipeline.

Un motor tan transparente que los estudiantes pudieran sentarse y empezar a hacer trabajos útiles sólo tras unas pocas mañanas de estudio, tocando las ideas como notas en un piano.

Lo que quería era un clavejuego.6

¡Vaya! No hay Steinways o Bosendorfers en este negocio.

Si quería un clavejuego, iba a tener que construirlo yo mismo.

Este es el momento de la conferencia donde se supone que presiono la barra espaciadora y triunfalmente revelo mi (citando al programa) “siniestro método para lanzar a los estudiantes al crisol del diseño de juegos” con “una maligna elegancia digna del nombre Profesor Moriarty”.

(Puedo o no saber algo sobre cómo enseñar diseño de juegos, pero seguro que sé un par de cosas sobre cómo escribir propuestas para conferencias).

Permítanme contarles algo sobre la educación del Profesor Moriarty.

Mis pensamientos en esas locas semanas previas a mi primera clase fueron algo así.

Los compositores seleccionan y ordenan notas. Los pintores mezclan pigmentos. Los escultores modelan arcilla.

¿Cuál es la sustancia de trabajo de los juegos digitales? ¿En qué medio se realizan generalmente? ¿Cuál es nuestro lienzo?

La respuesta obvia es: una pantalla.

Vale. ¿De qué está hecha una pantalla?

Independientemente del hardware o el género, prácticamente todos los juegos contemporáneos en el fondo se llevan a cabo en una rasterización7 en 2 dimensiones de cuadros de colores.

Los sistemas operativos modernos y motores de juego han eliminado por completo la necesidad de definir los píxeles individuales en una pantalla.

Pero para nosotros los veteranos que se curtieron a finales de los '70 y principios de los '80, el hacer juegos trata sobre cambiar el color de píxeles individuales.

Les comunico entonces que una comprensión profunda de los juegos digitales y las herramientas usadas para crearlos requiere familiarizarse con el trabajo en píxeles.

Un monitor moderno de alta definición incorpora más de dos millones de píxeles. Eso parecía un poco pesado.

Mona Lisa in pixels    Mondrian   Rasterización de 32 x 32 píxeles

De modo que decidí limitar la rasterización de mi clavejuego a una escala muy muy inferior: sólo 32 x 32 píxeles, el tamaño de un icono medio de Windows.

Abacus and mosaic

Se me ocurrió que los píxeles gigantes en su trama se parecían a las cuentas de un ábaco, o a las teselas de un mosaico.

Mondrian

Piet Mondrian: Composición: Damero, colores claros (1916)

Consideré llamar Mondrian a mi clavejuego, en honor a Piet Mondrian, el artista Neerlandés famoso por sus pinturas de grandes cuadrados de colores.

Desafortunadamente, Mondrian.com, .net y ,org ya estaban cogidos.

Entonces recordé a Herman Hesse, y El juego de los Abalorios.

Perlenspiel LogoPerlenspiel

La versión original de Perlenspiel era una aplicación nativa de Windows, escrita en C++ y con scripts en Lua.

La versión actual, la 2.1, está basada en HTML5. Funciona sin instalación en cualquier navegador que lo admita, y está hospedado completamente en la nube.8

El diseño de este motor es tan simple como parece.

Una página web de Perlenspiel se divide en dos áreas.

Grid

En el centro de la página está la cuadrícula, un rasterizado rectangular de píxeles de gran tamaño, o cuadrados de color sólido.

A cada cuadrado en la cuadrícula se le llama cuenta. Originalmente iba a hacer que parecieran auténticas cuentas de cristal, pero he llegado a apreciar la austeridad Europea de los cuadrados.

También hay un cuadro de texto sobre la cuadrícula llamada línea de estado. Puede usarse para comunicar mensajes cortos a los jugadores: el título del juego, mejores puntuaciones, límites de tiempo o instrucciones simples.

Por sí mismo, Perlenspiel es de género agnóstico. No está creado para soportar ningún tipo particular de juego o estilo o interactividad.

Su comportamiento está completamente controlado por Javascript.

Javascript resulta ser el lenguaje de programación más extendido del mundo. Controla el aspecto y el comportamiento de casi todos los billones de páginas de la World Wide Web.

Javascript es tan real como los lenguajes de computación pueden llegar a ser. Está exhaustivamente documentado, y es soportado correctamente por docenas de herramientas de desarrollo profesional, incluyendo Eclipse.

Javascript queda muy bien en un currículum.

El mismo motor Perlenspiel está escrito en Javascript.

Cuando un jugador mueve y pulsa el ratón robre la cuadrícula, desliza la rueda del ratón, o presiona una tecla del teclado, el motor le dice a tu script lo que el ratón y el teclado están haciendo.

Tu script puede responder haciendo que el motor cambie la apariencia de una o más cuentas, reproduzca sonidos, o muestre un mensaje en la línea de estado.

Engine

Este intercambio conducido por eventos entre el motor y el script es lo que crea toda la experiencia de juego.

This event-driven interchange between the engine and script creates the entire game experience.

Llamadas de evento de Perlenspiel

  • PS.Init ()
  • PS.Click (x, y, data)
  • PS.Release (x, y, data)
  • PS.Enter (x, y, data)
  • PS.Leave (x, y, data)
  • PS.KeyDown (key, shift, ctrl)
  • PS.KeyUp (key, shift, ctrl)
  • PS.Wheel (dir)
  • PS.Tick ()

Todas las funciones del motor y las variables comparten el prefijo PS.

PS.Init() es llamada una vez, cuando un juego empieza. Se usa esta llamada para establecer las dimensiones iniciales de la cuadrícula y realizar cualquier otro ajuste necesario para que empiece tu juego.

PS.Click() es llamada cuando se presiona un botón del ratón sobre una cuenta. Los parámetros x e y especifican la columna y la fila de la cuenta sobre la que se hizo clic. El parámetro data se explicará en un momento.

PS.Release() es llamada cuando se suelta un botón del ratón sobre una cuenta.

PS.Enter() es llamada cuando el cursor del ratón entra en una cuenta. PS.Leave() es llamada cuando el cursor se desplaza fuera de una cuenta.

PS.KeyDown() es llamada cuando se mantiene pulsada una tecla, y PS.KeyUp() cuando esa tecla se suelta.

Por último, PS.Wheel() es llamada cuando la rueda de ratón es desplazada hacia adelante o hacia atrás.

Además de estos eventos generados por el jugador, Perlenspiel tiene un reloj individual que puede ser usado para crear eventos programados y animaciones.

Se inicia el reloj llamado a PS.Clock() con la frecuencia deseada, expresada en centésimas de segundo. Después de esto, la función de script PS.Tick es llamada con la frecuencia especificada.

¡Y eso es todo!

Componer un juego de Perlenspiel no consiste en nada más que en responder a estas nueve llamadas a eventos con comandos que cambian la apariencia de la cuadrícula, las cuentas o la línea de estado, o reproducen sonidos.

Hay sólo dos comandos para controlar la cuadrícula en sí, ambos prefijados con PS.Grid.

PS.GridSize() cambia las dimensiones de la cuadrícula a cualquiera desde una única cuenta gigante hasta un máximo de 32 x 32 cuentas. La cuadrícula puede ser redimensionada en cualquier momento, incluso en mitad del juego.

Se controla el color de fondo de la cuadrícula y la página web circundante con PS.GridBGColor().

Comandos de cuenta de Perlenspiel

  • PS.BeadColor (x, y, rgb)
  • PS.BeadAlpha (x, y, alpha)
  • PS.BeadBorderWidth (x, y, width)
  • PS.BeadBorderColor (x, y, rgb)
  • PS.BeadBorderAlpha (x, y, alpha)
  • PS.BeadGlyph (x, y, glyph)
  • PS.BeadGlyphColor (x, y, rgb)
  • PS.BeadFlash (x, y, flag)
  • PS.BeadFlashColor (x, y, rgb)
  • PS.BeadData (x, y, data)
  • PS.BeadAudio (x, y, audio, volume)
  • PS.BeadFunction (x, y, exec)
  • PS.BeadTouch (x, y)
  • PS.BeadShow (x, y, flag)

Los comandos para controlar las cuentas individualmente son un poco más extravagantes. Hay un total de 14, todos con el prefijo PS.Bead.

PS.BeadColor() pone una cuenta en cualquier color de entre 16 millones.

PS.BeadAlpha() controla la transparencia alpha de una cuenta contra el color de fondo de la cuadrícula.

Cada cuenta tiene un borde sólido opcional, de hasta 8 píxeles de ancho. Los tres commandos PS.BeadBorder() permiten controlar la anchura, el color y la transparencia del borde de cada cuenta individualmente.

Las cuentas pueden contener un glifo o símbolo opcional, que puede ser cualquiera de los millones de caracteres UTF-8. El par de comandos PS.BeadGlyph() permiten decidir qué glifo se muestra así como su color.

Por defecto, las cuentas “brillan” momentáneamente cuando se cambia su color. El comando PS.BeadFlash() permite desactivar o desactivar este efecto de brillo, y controlar el color del destello.

Cada cuenta puede ser asociada con cualquier valor arbitrario de Javascript – cualquier número, cadena, conjunto, objeto o función. PS.BeadData() permite asignar este valor a una cuenta, el cual aparece entonces en el parámetro data de las llamadas a evento que les mostré antes. Esta característica facilita la creación de clases de cuentas.

Las cuentas pueden tener adjunto un sonido, el cual se reproduce cuando la cuenta es pulsada con el ratón, y también una función definible por el usuario, la cual es llamada cuando la cuenta es pulsada.

Se puede simular el efecto de pulsar una cuenta sin que el jugador la toque en realidad llamando a PS.BeadTouch().

Finalmente, se puede hacer que las cuentas estén activas o inactivas con PS.BeadShow().

Cada uno de los comandos de cuenta comienza con dos parámetros, x e y, que especifican la fila y la columna empezando desde cero de la cuenta que se quiere cambiar.

Si se usa la constante PS.ALL en cualquiera de los parámetros, todas las cuentas de la fila o columna especificadas son afectadas. Si se usa PS.ALL en ambos parámetros, todas las cuentas de la cuadrícula son afectadas.

PS.StatusText() y PS.StatusColor() cambiar el texto y el color de la línea de estado.

Por defecto, el texto de estado va difuminándose lentamente cuando es cambiado. Se puede activar o desactivar este efecto con PS.StatusFade().

Perlenspiel está equipado con una biblioteca basada en cloud de unos 400 efectos de sonido y notas musicales, que van desde clicks y pops genéricos hasta un clavecín completo, un xilófono y un piano de 88 notas.

Comandos de audio de Perlenspiel

  • PS.AudioLoad (audio, path)
  • PS.AudioPlay (audio, volume, func, path)
  • PS.AudioPause (channel)
  • PS.AudioStop (channel)

Estos cuatro comandos permiten cargar, reproducir, pausar y parar estos sonidos. Todos los sonidos están disponibles para su vista anticipada en la web de Perlenspiel.

Finalmente, hay una ventana de depuración bajo la cuadrícula que se puede abrir para mostrar diagnósticos dentro del juego, así como un puñado de utilidades para calcular valores de color, generar números aleatorios, y extraer datos de píxeles desde archivos de imagen.

Setter and getter   Este colocador también es un conseguidor.

En Perlenspiel, los colocadores también son los conseguidores. Esto significa que los comandos devuelven valores que representan el estado actual de los elementos relacionados de la cuadrícula.

Por ejemplo, si se llama a PS.BeadColor() con o sin un parámetro de color, devuelve el color de la cuenta en la posición especificada.

Todos los otros comandos de Perlenspiel funcionan de la misma manera.

§

Desde otoño de 2009, he impartido cuatro cursos de Diseño de Juegos Digitales I en el WPI.

Durante este período, mis estudiantes compusieron unos 250 juguetes, dispositivos y juegos en el clavejuego Perlenspiel.

El plan de estudios de siete semanas constaba de catorce clases de dos horas.

En la 1ª Clase, explicaba la estructura y objetivos del curso, presentaba Das Glasperlenspiel de Hesse, y pedía a los estudiantes que leyeran la introducción de 50 páginas de la novela con la esperanza de que ellos, también, se inspiraran con su visión.

Esta tarea era siempre impopular. A los estudiantes de videojuegos no les gusta leer. Ya no mando esta lectura.

Después levantaba un pequeño cuaderno de notas Moleskine cuadriculado e informaba a los estudiantes de que se les pediría que llevaran un diario creativo mientras trabajaban en sus proyectos, y que tendrían que entregarlo a final de curso para calificarlo.

Esta tarea también era impopular. A los estudiantes de juegos no les gusta escribir. Todavía mando hacer el diario, pero ya no me molesto más en calificarlo.

Finalmente presentaba el clavejuego Perlenspiel, con su anodino rasterizado de píxeles gigantes, y anunciaba que lo usarían para completar seis proyectos durante las siguientes siete semanas: un juguete, un rompecabezas y cuatro juegos.

Las reacciones de los estudiantes iban desde el desconcierto al alivio llegando al entusiasmo.

Los estudiantes desconcertados eran los más numerosos.

Pensaban que iban a pasarse el curso inventando personajes chulos, escribiendo historias relacionadas con la amnesia o el apocalipsis, creando variaciones novelescas de sierras mecánicas y pistolas de clavos, y animando zombies, robots y vampiros en 3D.

Los estudiantes aliviados pensaron que iban a pasarse el curso haciendo brainstorming con los estudiantes desconcertados. Pensaron que escribirían hojas de cálculo y documentos de diseño, y que no llegarían a diseñar demasiado.

Los estudiantes entusiasmados eran los que ya estaban haciendo extraños jueguecillos en su tiempo libre.

La 1ª Clase también incluía una charla con algunas definiciones básicas para juego, juguete, juego y rompecabezas.

Tom Sawyer

Mis definiciones anidadas estaban inspiradas por Las Aventuras de Tom Sawyer,9 en la que Mark Twain comenta memorablemente que “Trabajo es cualquier cosa que el cuerpo esté obligado a hacer, y juego es cualquier cosa que el cuerpo no esté obligado a hacer”.

  • El juego es una acción superflua.
  • Un juguete es algo que permite el juego.
  • Un juego es un juguete con reglas y un objetivo.
  • Un rompecabezas es un juego que puede ser resuelto.

Entonces presentaba un breve resumen sobre cómo funciona el motor Perlenspiel, parecido al que les acabo de hacer.

Dirigía a todo el mundo a una web donde podrían leer sobre Perlenspiel, estudiar algunos ejemplos de código simples, y descargar los archivos necesarios para usarlo.

Les daba las URLs de ebooks y Webs que describían Javascript.

Finalmente, pedía a cada miembro de la clase, ingenieros y artistas por igual, que compusieran un juguete o dispositivo en Perlenspiel para la próxima clase, tres o cuatro días después.

No ofrecía ninguna indicación sobre programación o Javascript.

No les enseñaba ningún proyecto creado por las clases anteriores.

Pero les daba permiso para que se ayudaran los unos a los otros, siempre que se acreditara.

Pasábamos la 2ª Clase mirando y analizando los juguetes que todos habían contruido.

Entonces dividía la clase en equipos de proyecto de dos estudiantes, con un estudiante de arte en cada equipo siempre que fuera posible.

La primera tarea de equipo era hacer un prototipo de rompecabezas en Perlenspiel.

Estos eran los requerimientos del proyecto:

  • Tenía que ajustarse a mi definición de rompecabezas (un juego que puede ser resuelto).
  • Tenía que diseñarse para un sólo jugador.
  • Tenía que ser re-jugable para aquellos que ya lo hubieran acabado, y seguir siendo divertido. Esto significa que la actividad (física y/o mental) necesaria para resolver el rompecabezas debía ser significativamente diferente cada vez que se jugara.
  • Tenía que estar completamente auto-documentado. No deberían ser necesarias instrucciones o explicaciones fuera de pantalla para usarlo.

Un prototipo del rompecabezas se presentaba en la siguiente clase. No tenía que estar pulido, pero tenía que funcionar suficientemente bien como para que otra gente pudiera probarlo.

La 3ª Clase era un estudio de prueba de juegos. Los equipos se emparejaban aleatoriamente para jugar los rompecabezas de otros durante diez minutos, haciendo preguntas y tomando notas. Después los equipos cambiaban de sitio.

Esto se repetía tres veces durante el transcurso de la clase, de modo que todos los equipos jugaran tres rompecabezas distintos, y sus juegos fueran probados por tres equipos diferentes.

Se le pedía a los equipos que usaran sus notas para completar y pulir sus rompecabezas a tiempo para la 4ª Clase, la cual se empleaba en criticar los rompecabezas terminados.

Las siguientes cuatro tareas eran proyectos de juego, cada uno de ellos ocupando períodos de dos clases.

El primer período se dedicaba a probar el juego, el segundo a presentarlo y criticarlo.

El primer proyecto de la serie era un juego sencillo para un sólo jugador.

El segundo proyecto era para un juego para dos jugadores. El juego podía ser competitivo o cooperativo, pero tenía que funcionar usando el teclado y/o ratón de un único ordenador.

Para cuando hubieron completado los juegos para 2 jugadores, los equipos habían estado trabajando con Perlenspiel cerca de un mes. Decidí que era hora de empezar a apretar.

Para la tarea del tercer juego, les dí una lista de restricciones de diseño.

Todos los juegos tenían que ajustarse a los siguientes requisitos:

  • Los juegos debían tener un título.
  • El juego debía ser para un sólo jugador.
  • Debían usarse efectos de sonido y/o música.
  • Si se usaba una pantalla de título, no se permitían historias ni instrucciones de juego.
  • Tenía que estar completamente auto-documentado. No deberían ser necesarias instrucciones o explicaciones fuera de pantalla para jugarlo.

Además de estos requisitos generales, cada equipo tenía que elegir tres restricciones cualesquiera de las siguientes cinco:

  • La cuadrícula no podía exceder las 16 cuentas en cualquier dimensión.
  • No se permitían glifos.
  • No se permitía temporizador (es decir, ninguna llamada a PS.Clock).
  • No se permitían entradas desde el teclado.
  • No se permitían palabras inteligibles en cualquier lenguaje en ninguna parte, a excepción del título del juego en la línea de estado.

Para el cuarto y último encargo de juego, apreté los tornillos incluso más.

  • La cuadrícula no podía exceder las 16 cuentas en cualquier dimensión.
  • Debía ser para un sólo jugador.
  • No se permitían glifos.
  • El juego debía usar o bien la entrada del ratón o las cuatro teclas de dirección y/o WASD como única entrada del jugador (pero no ambas).
  • Debían usarse efectos de sonido y/o música.
  • Tenía que estar completamente auto-documentado.
  • La entrega final debía ser suficientemente completa para funcionar, estable y pulida como para añadirla al currículum.

Además de los requisitos anteriores, el gameplay – es decir, las acciones y consecuencias en el juego, no sólo su representación – tenía que ejemplificar uno de los siguientes temas abstractos:

  • Destino.
  • Transformación.
  • Reaparición.
  • Armonía.
  • Victoria pírrica.

§

En caso de que usted decida utilizar Perlenspiel en su laboratorio, hay algunas cosas que debería tener en cuenta.

Debido a que la visualización es tan restrictiva, los mejores estudiantes no gastarán tiempo en forzar los límites para descubrir qué pueden sacar de él, del motor y del profesor.

En la primera versión de Perlenspiel, no había límites físicos en las dimensiones de la cuadrícula o el tamaño de la pantalla. PS.Grid() aceptaría cualquier valor que resultara en un tamaño de cuenta de al menos un píxel.

Unos pocos de los más listillos explotaron esta capacidad para producir juegos de baja resolución convencionales, similares a aquellos que solíamos hacer para consolas antiguas y portátiles.

Usaban las cuentas como elementos de imagen, no como elementos de juego.

En un caso extremo, un grupo de ingenieros aprovecharon Perlenspiel para recrear la apariencia de una Gameboy. Podías desplazarte por ahí para ver el mapa de un juego de Mario, basado en los datos originales.

Podías incluso mover a Mario por el mapa.

Otra cosa con la que tener cuidado son las cinemáticas.10 Incluso con un límite de 32 x 32 cuentas, algunos estudiantes no podían resistir la tentación de preparar sus historias con cinemáticas no interactivas.

Y antes o después, un equipo de tíos listos usarán los glifos de las cuentas para poner a prueba sus aptitudes con una aventura textual.

El más memorable de estos fue un juego endiabladamente divertido llamado Eres Británico, ¿Qué Harás?.11

Eres Británico resultó ser un momento de enseñanza maravilloso. Era la primera vez que muchos de mis estudiantes veían en su vida una aventura textual.

¡La clase se reía a carcajadas mientras jugábamos juntos! Suscitó una de las reacciones más positivas entre todos los proyectos de Perlenspiel.

Cuando nos hubimos terminado nuestro fish and chips, señalé que las aventuras textuales representaron una vez la tecnología punta de los videojuegos, y que, por un tiempo, fue incluso posible ganarse la vida escribiéndolos.

Les dije que recordaran Eres Británico la próxima vez que tuvieran algo divertido, extraño o reflexivo que quisieran expresar en un juego, pero no tuvieran los recursos para producirlo.

§

El clavejuego Perlenspiel y mi plan de estudios para utilizarlo fueron experimentales.

En cierta medida, resultaron ser un éxito.

Las evaluaciones del curso de los estudiantes fueron unánimemente positivas. Todos saben lo importante que es eso.

Muchos estudiantes me dijeron que fue una de las mejores experiencias de su carrera académica.

Sin embargo, recordando el experimento mientras escribía esta conferencia y montaba el vídeo, me dí cuenta de que no había construido el clavejuego que pretendía.

Pensé que estaba construyendo un motor para enseñar diseño de juegos digitales.

Lo que en realidad hice fue construir un motor para aprender a enseñar diseño de juegos digitales.

El pasado Diciembre, después de que la cuarta sección del curso estuviera terminada y evaluada, y todos se fueran a casa por vacaciones, decidí empezar a rediseñar el curso basándome en lo que había aprendido. Empecé con el examen final.

Había estado concluyendo el curso con un examen escrito, en el que pedía las definiciones de los términos de diseño sobre los que había hablado. Cosas como “juego significativo” y “potencialidades”.

Para otoño de 2012, decidí reemplazar el examen en papel por una sesión presencial en clase en la que jugábamos a un pequeño juego que los estudiantes no habían visto antes, donde les pedía que identificaran los elementos de diseño que estaban presentes en la experiencia.

Obviamente el juego tenía que estar escrito en Perlenspiel.

Las únicas cosas que había construido con el motor eran demos técnicas. Nunca lo había usado de verdad para hacer un juego completo y pulido.

El día después de navidad, con una taza humeante de alegría festiva, se me presentó una idea adecuada, y empecé a escribir el código. Pensé que habría terminado antes de Año Nuevo.

Casi tres semanas después, el juego estaba casi terminado.

Había olvidado lo difícil que es escribir para píxeles simples sin sprites, o planos complejos, o movimiento de pantalla, o un sistema de animaciones, o cualquiera de las comodidades que todos hemos llegado a dar por sentadas.

Por primera vez, me dí cuenta de lo mucho que les había estado pidiendo a mis estudiantes cuando les dije que escribieran seis juegos en siete semanas, y de lo mucho por lo que habían pasado para satisfacerme.

Perlenspiel demostró a este viejo profesor lo duro que trabajarían los estudiantes si se les retaba de forma lúdica y con firmeza.

da Vinci   Welles

Leonardo da Vinci escribió una vez, “El Arte vive de límites, y muere de libertad”.

Y Orson Welles dijo, “El enemigo del arte es la ausencia de límites”.

(Sí, lo sé. Dije “arte” otra vez).

Perlenspiel es de código abierto. Todo lo que se necesita para empezar está disponible en www.perlenspiel.org.

. . .

Traducción: Daniel Alonso Martínez (a 12/04/2013)

1. “Learning” se traduciría como “aprendizaje”. (N. del T.)

2. Un rail shooter es un tipo de videojuego que presenta una perspectiva en primera persona pero en el que el movimiento de cámara no es controlado por el jugador, quien suele manejar algún tipo de dispositivo para disparar a objetivos visibles. (N. del T.)

3. El full-motion-video se caracteriza por hacer uso de material visual grabado de antemano. (N. del T.)

4. Una API o Interfaz de Programación de Aplicaciones es un conjunto de procedimientos y funciones agrupados en una biblioteca que puede ser utilizada por varios programas. (N. del T.)

5. Un pipeline en computación es una arquitectura que transforma un flujo de datos en procesos secuenciales en los que cada la entrada de una fase es la salida de la fase anterior. Es muy utilizada en intérpretes de comandos. (N. del T.)

6. El autor utiliza el término “gameclavier” que resulta de la unión de dos palabras: “game”, en castellano “juego”, y “clavier”, traducido como “clave” o “clavicémbalo”. Se ha respetado esta unión en la traducción. (N. del T.)

7. La “rasterización” es el método por el cual una información gráfica se transforma en imágenes visibles en un dispositivo de salida, como por ejemplo un monitor. (N. del T.)

8. Al tratarse de un término relativamente moderno, el uso de los términos “nube” y “cloud” en el ámbito informático es indistinto. (N. del T.)

9. El título original de la novela es “The Adventures of Tom Sawyer”. (N. del T.)

10. Se ha traducido el término inglés “cut scene” como “cinemática”. En el caso de los videojuegos, se refiere a aquellas secuencias no interactivas utilizadas para presentar personajes y situaciones. (N. del T.)

11. El título original es “You Are British, What Will You Do?”. (N. del T.)

. . .