Lecciones gratuitas de GameDevLessons.com, por Chris DeLeon

Vol 6 - 10 de Septiembre, 2009

¡Hola!

Soy Chris DeLeon (acerca de mi), y gracias por acompañarme en mi boletín mensual de desarrollo de videojuegos, vol. 6. Estos boletines son una de las formas en las que espero ayudar a empezar a nuevos desarrolladores, mientras ayudo a los que ya están en ello a llevar su trabajo en nuevas direcciones.

I.) Ediciones anteriores, suscripción

II.) Principiante - Los caminos del autodidacta

Puedes aprender por ti mismo

Hay un proceso para ello

Libros

Sitios web

Documentación de lenguajes de programación/API

Foros/compañeros

Librerías de código

Ejemplos de código

Practica

Tus archivos de proyectos anteriores

III.) Nivel medio - Definiendo al diseñador de videojuegos

Habilidades sociales

Es muy raro que repita puesto

No sólo ajustes

No sólo diseño de niveles

Inventando una disciplina para cada juego

Ejemplo simple

Conexión con juegos más grandes

Las franquicias caracterízan la innovación

IV.) Avanzado - Tipos de dificultad

¿Por qué hablar de la dificultad?

¿Tipos de dificultad?

La importancia de los juegos difíciles

Fuentes de dificultad no ajustable

¿Qué es justo?

Nota especial acerca de la dificultad inicial

V.) Ponte en acción - No seas un burro

Te presento al burro

Demasiadas ideas, insuficiente acción

Como diferenciar las malas de las buenas

Como saber como diferencir las malas de las buenas

Lo más rápido y lo más fácil - Porque las primeras ideas siempre son las más pobres

Sobreproducción

Solución

VI.) Donaciones

VII.) El próximo boletín

Edición especial - Una entrevista con Warren Robinett

I.) Ediciones anteriores, suscripción

Para leer ediciones anteriores, o suscribirte: http://gamedevlessons.com/?page=free (Cada boletín está en inglés, con un enlace a la traducción al español, si está disponible)

Si encuentras este enlace en algún otro lugar que no sea tu correo electrónico, y te gustaría que te informara cuando salgan las nuevas ediciones, únete a mi lista de correo (libre de spam). Sólo te llevará un minuto, nunca te enviaré más de un correo al mes (sólo para anunciar estos boletines), y si cambias de opinión puedes darte de baja en cualquier momento.

Los boletines no pretenden ser acumulativos - así que no tendrías por qué leer las ediciones anteriores para entender este - pero los diferentes temas tratados en cada uno pueden serte de ayuda. En particular, si eres un recien llegado a mis boletines, recomiendo Boletín Vol. 1 por su introducción a la programación de una forma no técnica, así como por sus enlaces a recursos gratuitos para editar imágenes, audio, modelar en 3D, y otros recursos necesarios en el desarrollo de videojuegos.

II.) Principiante - Los caminos del autodidacta

Puedes aprender por ti mismo

Puedes aprender por ti mismo la mayoría de las habilidades que necesitas para hacer juegos.

...dice el tio que dedica con devoción la mayor parte de su tiempo libre enseñando a hacer videojuegos.

Lo que más me gusta hacer es ayudar a la gente que ya sabe como hacer videojuegos a aprender a hacerlos mejor. Los proyectos específicos y consejos en diseño de juegos que ofrezco no son de mucha utilidad a no ser que ya puedas hacer videojuegos, y una gran parte de eso es el saber como programar. Al compartir materiales e información gratuita para ayudarte a aprender por ti mismo, estoy aumentando el número potencial de desarrolladores con los que puedo trabajar en los desafios que me resultan más interesantes.

Hay un proceso para ello

En una reciente tira cómica de xkcd (N. del T. en inglés) hace un estupendo trabajo al resumir de forma muy concreta el "conocimiento informático".

Ser bueno con los ordenadores no significa saberlo todo. Es el saber como buscar o averiguar lo que no sabes. De forma similar, aprender por ti mismo como hacer videojuegos es, con mucho, un tema relativo a saber que recursos tienes disponibles, y como utilizarlos de la mejor forma para acelerar tu progreso.

Hay unos cuantos recursos, aparte de Google, a considerar en este caso. Los principales recursos que tienes disponibles para tu aprendizaje autodidacta son Libros, Sitios web, Documentación de lenguajes/API, Foros/compañeros, Librerías de código, Código de ejemplo, y tus propios proyectos anteriores.

Libros

Hay libros sobre cualquier tema, para cualquier especialidad.

Aquí hay algunos libros electrónicos gratuitos sobre lenguajes de programación (N. del T. en inglés, aunque ya os proporciono la traducción de google, que también se aplica a los libros en línea, no descargables. En español no hay tanta oferta, puedes probar en http://www.galeon.com/neoprogramadores/booksprg.htm).

A pesar de que están disponibles en internet de forma gratuita, igualmente recomiendo salir a comprar uno real. O buscar uno en la biblioteca.

Depender desde el principio de demasiados recursos digitales crea hábitos descuidados que evitan aprender mejor, como copiar y pegar código en vez de habituarse a escribirlo. Leer una pantalla de ordenador también cansa más, sobretodo si acabas haciéndolo por la noche antes de irte a la cama. Los recursos digitales son increibles para buscar información - se pueden realizar búsquedas en ellos sin problemas y al instante - pero comparados con el papel aun no son lo suficientemente buenos para el tipo de exposición prolongada que se necesita para desarrollar un riguroso entendimiento de las habilidades fundamentales.

El coste puede ser un factor, ya que los libros buenos en estos temas pueden estar con facilidad en el rango de los 50€-100€, pero es importante pensar que (a.) el coste por hora es bastante bajo, (b.) el coste total es ridículo en comparación a pagar por clases, y (c.) es imposible estimar el valor de la expresión "Este contenido, editado profesionalmente, fue el que me permitió aprender esto" (yo mismo he podido decir esta última frase con unos cuantos libros con los que crecí).

(Llamadme antiguo, pero una copia impresa de Alicia en el país de las maravillas es infinítamente más fácil de leer que una versión en PDF, sin importar lo bien formateada que pueda estar (N. del T. libro en inglés).

Sitios web

Los sitios web son recursos increibles para dar respuesta a preguntas específicas, y encontrar enlaces a otros recursos útiles como ejemplos de código. Tal y como se explica arriba, creo que son inferiores a la hora de cubrir conceptos básicos (ver las notas antes de la sección de libros).

Documentación de lenguajes de programación/API

APIs, o "Application Programming Interfaces" (interfaz de programación de aplicaciones), son enormes directorios de múltiples ramas con información indicando las funcionalidades y formas de uso de un lenguaje de programación. Los lenguajes más modernos que el C/C++, especialmente los lenguajes de programación que se usan en el contenido online, tienen extensas APIs, como Java API (no recomiendo usar Java para programar juegos, pero su API es clásica) y aquí está el API para ActionScript 3 (ActionScript 3 es el 1º lenguaje que recomiendo para hacer juegos para la web).

Hay ahí más información de la que una persona sería capaz de leer en su vida, y un buen 95% probablemente no es para nada relevante para lo que necesitas a la hora de hacer un videojuego. Estas referencias son útiles para tenerlas a mano, y pueden ser determinantes para aclarar algunos detalles acerca de que puedes esperar en términos de control de errores y casos límite. Pero una vez más, los recursos digitales son sólo una buena forma de buscar respuestas específicas a problemas que te encuentres, o para encontrar otros recursos.

Pero aprender a programar empezando con el API sería como aprender escritura creativa en un lenguaje extranjero usando su diccionario.

Foros/compañeros

Igual que cuando vas a clases, si tienes una pregunta, es muy probable que otros en tu aula, aprendiendo lo mismo que tu, también tengan esa misma pregunta.

Al contrario que en las clases, en este caso el "aula virtual" tiene cientos de miles de personas, y hay un registro detallado de cada pregunta que se ha hecho en la última década o incluso antes.

Si estás atascado en algo - y sé que parece obvio, pero haría mal si no lo repitiera - haz una búsqueda en internet o recorre un foro web relativo al tema para encontrar una respuesta. Si no puedes encontrar nada, entonces sigue con la analogía de las clases - haz un favor a cientos de miles de personas en la siguiente década hablando del tema en foros en alguna web donde otros como tu encontrarán la respuesta.

Librerías de código

En programación, una librería es un conjunto de códigos empaquetados que alguien escribió para manejar funcionalidad específica. Esto podría incluir operaciones de red, mostrar texto, reproducir sonidos, manipular/cargar/mostrar imágenes, simulación física, etc.

Una buena librería de programación puede ocuparse de asuntos sobre los que no tengas ni la más remota idea, de una forma que será (a.) rápido (b.) fácil (c.) y te hace dependiente de esa librería, ya que te deja sin pistas acerca de como resolver algo sin usarla. Si tu objetivo es aprender sobre algo en particular, como programación gráfica o código de red, el punto (c) puede ser un problema. En muchos casos, una librería se usará para hacer algo que gente muy inteligente ha solucionado tras décadas de investigación y perfeccionamiento. En ese caso, esa librería te ahorrará literalmente años de frustración, y te dejará por tanto centrarte en lo que haces con los gráficos, con la red y con la física para hacer que tu juego destaque del resto.

Código ejemplo

¡Premio!

Encontrar buenos ejemplos de código fuente puede ser la diferencia entre "disparar a ciegas" acerca de como se montan las cosas, y trabajar con confianza en que lo que estás iniciando funcionará. También es realmente valioso al principio porque empezar con código que sabes que funcionará te ayudará a determinar si tu entorno de desarrollo está bien instalado y configurado - si falla con código ejemplo que venga de una fuente fiable, sabrás que tu proyecto, entorno o compilador no está bien configurado. Es una forma mejor que romperte la cabeza cambiando cosas en tu código preguntándote porqué no funciona.

Encuentra código de ejemplo. Lee código de ejemplo. Compila código de ejemplo. Teclea código de ejemplo. Modifica código de ejemplo. Intenta comentar varias líneas del codigo de ejemplo para ver como afecta y que ocurre. Añade comentarios a código de ejemplo.

Busca código de ejemplo que sea apropiado para tu nivel de comprensión. Si no es muy largo y no lo entiendes del todo aún, verifica que compila en tu entorno e imprímelo para tener junto a tu material de aprendizaje para revisar de vez en cuando.

Practica

Los buenos programadores son muchísimo más rápidos y más eficientes que los menos buenos.

Cuando decimos "bueno" nos referimos al total de años de experiencia, cuantos lenguajes de programación se sabe, o en cuantos proyectos se ha estado involucrado. "Bueno" se refiere a lo rápido que uno puede sintetizar el código necesario para resolver un problema, lo bien que alguien puede generar código que esté estructurado y con la mente puesta en futuras necesidades/legibilidad/adaptación, y lo fácil que una persona puede digerir e interpretar código de otros.

Algunos se manejan de forma fluida en programación como en su lenguaje materno. Otros lo usan como si fuera un lenguaje secundario que recuerdan vagamente de cuando lo aprendieron hace muchos años en la escuela/instituto.

Yo asocio esa diferencia a la comodidad obtenida después de incontables horas de práctica. El tipo de uso que va más alla de cumplir con los desarrollos que alguien te pide. El tipo de experiencia que se obtiene al investigar o aplicar conocimientos para resolver problemas, o crear un proyecto en el que el programador está involucrado personalmente.

En un extremo del espectro, está la forma en la que alguien con cero conocimientos en programación, pero acceso a internet, puede reunir código que no entiende para hacer que algo ocurra. En el otro extremo del espectro, hay alguien que se ocupará de cualquier problema que se le ponga delante, quizás empleando ocasionalmente un tiempo para documentarse o copiar algo de su basta librería de archivos en proyectos pasados.

Reitero esta distinción por una importante razón:

1.) Te interesará, positivamente, indudablemente, estar en el segundo grupo. Querrás ser el tipo de persona que domina sus cosas.

2.) No hay duda, ninguna de hecho, acerca de como puedes terminar o no en ese grupo, en vez de en el primero: práctica.

Tus archivos de proyectos anteriores

Tus archivos de proyectos anteriores son como código de ejemplo. La diferencia principal es que entiendes todo lo que tiene. Porque eres responsable de los porqués y cómos, y sabes exactamente donde encontrar cada cosa.

Durante tiempo y tiempo, mi montaña de código de proyectos anteriores ha sído la fuente de mi confianza al afrontar nuevos proyectos. Dado que he hecho algo igual en un proyecto anterior, o algo parecido, no hay duda en mi mente de que sé como hacerlo, y probablemente puedo hacer que funcione de nuevo sin perder mucho tiempo. En vez de gastar tiempo de desarrollo pensando como hacer algo, puedo partir de mi anterior solución, y emplear ese tiempo buscando una forma de mejorarlo.

La única forma de conseguir esa montaña de código de proyectos anteriores es (y aquí viene de nuevo) práctica. Con tu propio tiempo.

Si se hace en el tiempo para cumplir con un trabajo de clase, no será muy diferente del tiempo u objetivos que ha tenido cualquier otro programador durante su aprendizaje académico.

Si se hace en el tiempo para cumplir con objetivos comerciales, es seguramente con código que será propiedad de la empresa y no serás libre de reusarlo.

Practica.

Con tu propio tiempo.

III.) Nivel medio - Definiendo al diseñador de videojuegos

Habilidades sociales

En las grandes compañías, donde podemos encontrar un alto grado de especialización en cualquier área, hay una pregunta resonando por todas partes, por parte de artistas, programadores, empresarios, expertos en audio y similar: "¿Qué hace realmente un diseñador de juegos?"

La respuesta implícita es "nada". No dibujan las imágenes, no codifican la funcionalidad del juego, no negocian la financiación, y no hacen efectos de sonido.

La falta de claridad acerca de lo que hace un diseñador de juegos puede ser un gran problema para alguien que esté haciendo un proyecto en solitario - es muy posible que uno se involucre tanto creando imágenes, código, y sonidos como para darse cuenta de las consideraciones de diseño.

Para la gente de fuera de nuestra industria e intereses, cuando oyen "diseñador" piensan "diseñador gráfico", como el tipo de persona con amplios conocimientos sobre tipos de letra y experto en hacer folletos. Los diseñadores de juegos no suelen entrar en ese tipo de diseño.

Tanto si tienes experiencia en diseño de juegos como si no, tanto si te es familiar el significado del rol como si no, os animo a seguir leyendo. Mi punto de vista acerca del rol puede ser complementario a lo que ya sabes, o quizás ayudarte a explicarlo a otros.

Es muy raro que repita puesto

Tanto los diseños empleados en Solar SFUN, Topple, iZombie Death March (las docenas de juegos independientes gratuitos que he hecho antes) como por mis contribuciones a los títulos de EA Medal of Honor Airborne y Boom Blox, todos se componen de diferentes tipos de ideas, trabajos y resultados. Si nos centrásemos estrictamente en juegos de puzzle, juegos de deporte, o juegos de disparos en primera persona, podríamos presentar una lista más exacta de lo que significa el diseño de videojuegos para esos géneros - ¿pero como es posible que diferentes trabajos en diferentes tipos de juegos quepan bajo el mismo paraguas de "diseño de videojuegos"?

No sólo ajustes

La parte más visible del trabajo de un diseñador de videojuegos es el ajuste y balance. Consiste en modificaciones en valores: para la altura de los saltos, velocidad del movimiento, tiempo de recarga, grado de atención de los enemigos, probabilidad de aparición de las piezas en un puzzle, coste de mejora de personaje, y otros números que afectan a la jugabilidad. Si se configura incorrectamente, los valores pueden hacer que un buen juego sea lento, frustrante, injusto, aburrido, o demasiado simple.

Los números suelen escogerse por una combinación de suposición educada (establecer valores iniciales por convención o asuntos estéticos), ajustes amplios y brutos sobre importantes variables (salud del jugador, coste de unidad en un ejército basada en otro tipo de unidad, otros factores que afectan por completo a todo el juego/nivel), y por último pequeños ajustes a través de varias iteraciones en un conjunto escogido de números hasta que las cosas encajen bien.

He visto a desarrolladores de complejos juegos de estrategia usar hojas de cálculo y modelos lineales para aproximar el balance entre ejércitos - y he hecho algo parecido cuando desarrollé TriChromic.

Mientras las hojas de cálculo pueden generar valores iniciales con eficiencia, no sustituyen la iteración dentro del juego. En un juego con cualquier elemento en tiempo real, el cuanto tardan las unidades en rotar, apuntar y reproducir animaciones puede ser un factor, igual que la forma en la que un artista modela/anima una unidad cuando toma varias acciones (dependiendo de como se maneja la detección de colisiones). Incluso en un juego de estrategia por turnos, donde estos factores están igualados, es difícil para una hoja de cálculo tener en cuenta las complejas dinámicas que varios grupos de unidades pueden desarrollar en proximidad y en distintos escenarios.

La parte que diferencia a un diseñador de la jugabilidad de ser simplemente testeadores con acceso a los archivos de datos: determinar que valores son los que deben ser ajustados. El diseñador de videojuegos también tiene que considerar soluciones a problemas que pueden involucrar cambios fundamentales en la funcionalidad. Por ejemplo, si el problema identificado es que el jugador puede morir muy rápido por ataque enemigo, en vez de incrementar la salud del jugador o decrementar el daño enemigo, la solución del diseñador puede ser añadir un breve tiempo de invulnerabilidad para que el jugador se recupere, destacando que esta solución da lugar a momentos excitantes ya que el jugador puede ser más rudo cuando se enfrente a grupos de atacantes. (Nuevas variables para ajustar, introducidas por esa característica: ¿cuanto tiempo debería durar la invulnerabilidad?)

No sólo diseño de niveles

El otro aspecto claramente visible de lo que hace un diseñador de videojuegos es en la forma de arquitectura de niveles y colocación de objetos/enemigos. Hay más en el diseño de niveles que configurar emboscadas, construir circuitos de obstáculos, y colocar decoraciones modeladas por los artistas. En alguos juegos - sobretodo juegos de puzzles o juegos de acción procedurales - el diseño de niveles consiste en algo completamente distinto: manejar probabilidades.

(Para dos ejemplos de juegos de acción procedurales, mira mis viejos juegos gratuitos Burn 2 - mira el archivo Burn 2 Readme.txt para los controles - o Battleship 88. Estos juegos llevan "diseño de niveles", aunque no hay niveles prediseñados en ninguno de los dos. Los niveles están generados aleatoriamente usando un rango de posibilidades premeditadas.)

Para juegos en géneros menos establecidos, o para juegos que desafían convenciones establecidas, hay una pregunta más grande acerca de qué se califica como éxito en un nivel, que tipo de estructuras son navegables en un nivel y lo similar que debe ser el jugar un nivel de una vez a otra.

De la misma forma que un músico que pone 20 canciones en un album no está tan interesado en qué canciones están ahí, como en el orden en el que van y como esa composición afecta a la experiencia de un oyente cuando lo escucha por primera vez, los diseñadores de juegos no pueden pensar sólo en diseño de niveles aislados. Deben considerar como el orden y la variedad puede afectar el ritmo, la historia, y las necesidades de contenido para desarrollar por el equipo.

Aquí tienes más información gratuita sobre diseño de niveles (en el Vol 5).

Inventando una disciplina para cada juego

No es una coincidencia que muchos diseñadores de videojuegos versátiles (no confundir con gente identificada especialmente como "diseñadores de niveles" o con habilidades limitadas a un género concreto) expresen un interés en filosofía. No se trata de filosofía en el sentido de lo que los Idealistas Alemanes dicen acerca de los antiguos Griegos, si no filosofía en el sentido de metacognición - pensar críticamente acerca del pensamiento crítico, y planear acerca de la planificación, es decir pensar en como un jugador puede pensar acerca de la forma de resolver (o de disfrutar) un nivel/puzzle/objetivo.

Los diseñadores de videojuegos disfrutan cambiando entre incontables posibilidades en la búsqueda de patrones válidos, para crear términos y etiquetar y categorizar. Como una broma filosófica evolucionada en los campos de bilogía, física, químina, ciencia computacional, leyes, medicina y matemáticas, una mayor parte del diseño de videojuegos es inventar una disciplina mientras se hace contenido para el proyecto actual. A menudo son estudios rápidos, impacientes por profundizar en nueva información, aplicarla, y luego olvidarla rapidamente para llenar sus cabezas con nuevos sistemas. (Compara esto con el aprendizaje acumulativo de especialistas en disciplinas más consistentes como programación, negocios, o arte digital aplicado).

¿Cuales son los términos y conceptos relevantes necesarios para discutir y dar forma a la dirección del juego? ¿Qué decisiones afectarán las opciones de futuras decisiones, y en qué orden se pueden tomar las decisiones para minimizar tirar por la borda otras consideraciones relevantes?

Ejemplo simple

En el 2004 hice un pequeño juego llamado "Una de estas cosas no se parece a las demás" (en inglés, y aquí la traducción de google) para mi puesto en el carnaval de primavera de mi fraternidad (en la universidad). Lo pongo aquí para que sirva como ejemplo simple.

La jugabilidad en ese juego consiste en presentar cuatro imágenes a la vez, y el usuario debe indicar cual de las cuatro es diferente a las demás. Sólo hay una respuesta válida, que debe ser identificada por el usuario en un tiempo límite, y la máquina está preprogramada para saber cual es la respuesta correcta (no hay explicación o justificación). El juego estaba disponible para visitantes públicos de todas las edades, que se acercaban durante unos minutos, a un mueble de tipo kiosko, donde estaba montado todo.

¿Simple, verdad?, inmediatamente me empezaron a llegar sugerencias de cosas por amigos bienintencionados. Muchas de esos conjuntos sugeridos no eran válidos.

Y hé aquí el porqué: a pesar de que la meta fundamental, la interacción, y el contenido es simple, hay aún un modo correcto e incorrecto de pensar en un conjunto de 4 imágenes para usar para una de esas cosas que no es como las demás.

Piensa en este conjunto:
Pato Pez
Águila Pingüino

Digamos que alguien sugiere este conjunto, pensando en que se seleccione el pez, ya que es el único que no es un pájaro. ¡Esta pregunta es injusta! ¿Ves porqué?

El problema es que, como podrás haber supuesto, el águila tampoco es como los demás, ya que es el único de la lista que no pasa una cantidad de tiempo significativa en el agua.

O que tal este conjunto:

Este conjunto tampoco es justo. ¿Puedes ver más de una razonable respuesta?

Miralos escritos:

Toothpaste (dentrífico) Mouthwash (enjuague bucal)
Toothbrush (cepillo dental) Triangle (Triángulo)

Esta vez el problema no es el objeto en cuestión. El triángulo es claramente el único en la lista que no está relacionado con la higiene dental, y es el único objeto abstracto.

El problema es que no se dedique suficiente atención a las palabras, o a detalles de la composición en cada imagen. Mouthwash (enjuague bucal) es la única palabra en la lista que no empieza por T. El cepillo es la única imagen que no tiene un fondo blanco. Llegados a este punto, hay al menos tres válidas conclusiones que podrían funcionar como respuestas correctas, haciendo la cuarta opción (el dentrífico) diferente a las demás por no ser una respuesta factible. Este tipo de rompecabezas, especialmente bajo límite de tiempo, lleva a los jugadores a un estado de frustración, al no poder entender en qué pensaba el diseñador para determinar que criterio es más importante.

Conexión con juegos más grandes

De la misma forma que se pueden identificar que consideraciones nos valdrán para separar contenído válido del inválido, desafíos justos de los injustos, los objetos y niveles para juegos de tiempo real pueden ser creados según un conjunto de principios. ¿Cuanto hace falta que se introduzca el jugador en un nivel para que ocurra la primera secuencia de acción? ¿Cuantos enemigos a la vez debería haber en una estancia de un tamaño determinado? ¿Con que frecuencia deberían introducirse nuevos objetos? ¿A que ritmo es justo ir incrementando la dificultad? y ¿que cantidad de veces puede el juego reutilizar elementos y configuraciones para ser consistente, y ahorrarnos costes sin parecer cutre y repetitivo?

Las franquicias caracterízan la innovación

En un género establecido, como un FPS con marines espaciales, un Survival Horror en tercera persona, o un puzzle de bloques, el primer objetivo de un diseñador de videojuegos debe ser investigar qué se ha hecho antes por otros competidores en ese área para aprender de sus experiencias y mejorar sus errores. Es un desafío muy distinto cuando tenemos que crear el 25º juego de futbol en una serie, intentando innovar lo suficiente para satisfacer a los críticos y atraer a antiguos jugadores sin alinear la base de fans.

Para que quede claro, el diseño para una secuela todavía consiste en simplificar un complejo espacio de posibilidades en un sistema manejable de términos y conceptos, para usarlo como base de diseños expandidos y desarrollo de contenido.

IV.) Avanzado - Tipos de dificultad

¿Por qué hablar de la dificultad?

Cuando un desarrollador casi ha terminado su juego, lo habrá jugado miles de veces, o quizás más, y habrá practicado sus controles y sus puzzles desde la primera vez que tomaron forma. Lo que parece apropiado como desafío para un jugador nuevo, puede ser aburrido para el diseñador del juego, y lo que entretiene al diseñador será exagerádamente difícil para un nuevo jugador. Al hacer la dificultad del juego, es importante asegurarse no sólo de prestar atención al grado de dificultad, sino que este se ajusta correctamente a diferentes tipos.

Si el origen de la dificultad para un nuevo jugador no está identificado con claridad antes de que el jugador pueda empezar a resolver cosas, no habrá ningún ajuste o variable que podamos regular para compensarlo, lo que es peor, intentar resolver las cosas de la forma incorrecta introducirá otros problemas en el valor de entretenimiento del juego.

¿Tipos de dificultad?

A pesar de que esta sección está enfocada en mostrar las formas en las que un juego puede, por error, tener el tipo equivocado de dificultad, resulta útil nombrar unos cuantos ejemplos de tipos de dificultad para poder tener una visión clara sobre los orígenes del "desafío"-

Myst es un juego difícil.

Street Fighter II es un juego difícil.

Final Fantasy es un juego difícil.

Cualquiera familiarizado con estas franquicias reconoce que estas son tres declaraciones muy diferentes. Repasando:

En la mayoría de los casos, Myst hace que sea fácil hacer lo que quieres hacer, pero difícil el averiguar "qué" hacer.

Street Fighter II hace que sea facil averiguar lo que quieres hacer, pero difícil el hacerlo.

Final Fantasy consume tiempo, y lo fácil que quieras que resulte depende del tiempo que quieras emplear en subir de nivel.

La importancia de los juegos difíciles

Antes de que nos sumerjamos en las diferentes formas en las que los videojuegos pueden ser "difíciles", merece la pena clarificar porqué es deseable hacer que un juego sea "difícil" de alguna forma. Al hacer el videojuego más fácil, es importante no pasarse y olvidar que el juego tiene que plantear un desafío.

El movimiento que llevó a las grandes publicaciones a escribir historias para un nivel de comprensión bajo se está extendiendo a la industria del videojuego. El argumento, que tiene cierto sentido económico, es que el contenido se hace para llegar al mayor número de personas posible, y cuando con unos ajustes se puede conseguir llegar a la gente mayor, a la gente joven, a la gente menos paciente, y a la gente ocupada, tanto los desarrolladores como los jugadores se benefician.

El problema, si puedo usar una hiperbole, es que ocurren cosas muy distintas entre una piscina infantil y una piscina olímpica.

Lo que me preocupa es que cuando un juego difícil puede entrenar a una persona para afinar su habilidad aplicando estrategia, determinación, práctica, paciencia, cooperación y lograr dominar la frustración, un juego fácil enseña a cualquiera que el éxito es sólo cuestión de estar con lo mismo el tiempo suficiente. (He tocado este tema antes, unas cuantas lecciones atrás en El valor oculto en los videojuegos.)

Fuentes de dificultad no ajustable

Y ahora, echaremos un vistazo a las diversas formas en las que un juego puede ser difícil injustamente. Muchas de estas fuentes de dificultad no pueden ser resueltas ajustando puntos de daño, potencia o velocidad. Corregir esto suele requerir repensar las cosas y rediseñarlas. Ignoraremos los casos extremos de las fuentes de dificultad identificadas antes - que resulte demasiado confuso lo que se debe hacer, que sea demasiado difícil ejecutar movimientos importantes, o que se requiera demasiado tiempo en tareas repetitivas y necesarias para poder vencer en el juego - porque ya han sido comentados.

Examinar sin enseñar En las escuelas no hacen exámenes antes de enseñar el temario. Hacer esto frustra y enoja a la gente. Y al contrario que el temario escolar, no hay probabilidades de que alguien sepa los entresijos de como funciona tu videojuego hasta que se lo digas. Sería útil e ideal pensar en introducir las mecánicas de juego siguiendo los pasos: introducción, estudio de la oportunidad, y luego test/desafío. Como mínimo esa enseñanza introductoria es esencial si queremos que alguien pueda llegar a dominarlo.

Esperar que nos lean la mente Si algo parece tener múltiples soluciones, pero el puzzle o la batalla está concebida de forma que sólo puede ser completado tal y como el diseñador lo pensó, el juego está creando la situación en la que el jugador se cabreará y dirá "esto debería funcionar". La apariencia de múltiples soluciones deberían traducirse en múltiples soluciones, o debería replantearse cuidadosamente las posibilidades para llevar al usuario hacia la solución deseada.

La victoria recae en comportamiento emergente inexplicable La mayoría de los juegos con controles incluso moderadamente complejos tienen algunas combinaciones inintencionadas para saltar un poco más alto, correr un poco más rápido, mover piezas de puzzle mientras otras están callendo, etc... En Doom y Goldeneye 007, es posible correr sobre un 40% más rápido moviéndose lateralmente ("strafing") y hacia delante - los vectores de velocidad se suman. Estos y otros pequeños trucos para ahorrar tiempo/salud pueden parecer tan naturales a los diseñadores como las interacciones principales después de muchas horas de práctica, pero tienen que ser introducidas explícitamente al jugador si son necesarias para tener éxito.

Curvas de dificultad inexperádamente empinadas Asumiendo que tu juego no resulta ser el primero al que juegue una persona, casi con seguridad recorrerá una parte tranquilamente sin ser vencido hasta su primera derrota. Si hace falta repetir muchas veces el cruzar ese primer obstáculo, tu juego volverá a la estantería, probablemente para siempre. Un jugador en esta situación, pasando de no repetir nada a repetir la misma sección muchas veces sin progresos, es muy probable que le eche la culpa a los desarrolladores por realizar malos ajustes u ofrecer instrucciones inadecuadas, en vez de pensar que es debido a un problema con su propia habilidad.

Pobre intuitividad Intuitividad es un término de diseño que se refiere a la forma en la que la estructura, estilo o forma de algo sugiere su uso adecuado a un usuario. Una agarradera sugiere "tirar", un dial sugiere "girar", un botón sugiere "pulsar", y un suelo lleno de picas sugiere no-me-toques-o-morirás. El ejemplo clásico de intuitividad apropiada en videojuegos son los puntos débiles de los jefes finales - áreas que brillan en rojo u otras áreas particularmente vulnerables (cerebros, ojos...) que están justo donde se puede atacar al jefe.

Un diseño pobre en la intuitividad se convierte en un problema cuando el personaje al que el jugador debe hablar está en medio de una multitud sin destacar visualmente en la escena (puede ser un problema de ubicación), o cuando resulta difícil diferenciar una puerta que puedes abrir de una que no hasta que pruebas en las dos (se podrían quitar las manillas en las puertas que no pueden ser abiertas), o cuando el jugador no puede identificar si un muro es frágil para romperlo (suele ser indicado por grietas, desconchados, decoloración significativa...).

Puzzles de intuición Un puzzle de intuición es un desafío que no ofrece un resultado visual cuando estás apunto de resolverlo, de forma que resolverlo requiere un cambio no trivial en como se piensa, un salto entre los datos proporcionados y la solución. En la vida real estos aparecen como acertijos, en la escuela aparecen como pruebas avanzadas. En un videojuego toman la forma en la necesidad de que te des cuenta de que el espejo no es realmente un espejo sino una ventana, que los malos pueden ser lanzados contra pinchos y así usarlos como puente o que las flechas se convertirán en flechas de fuego cuando las dispares atravesando una antorcha.

Cuando sea posible, proporciona intuitividad (mira el punto anterior) como un objetivo gigante de hielo cerca de la antorcha, o una pista sutil, como dejar que el jugador vea a uno e los malos andando sobre los pinchos sin hacerse daño, estas cosas pueden hacer la diferencia entre que el jugador se sienta inteligente dejando que se de cuenta y piense que es su idea, o que el jugador se quede atascado.

¿Qué es justo?

Al final, el videojuego es algo hecho para los jugadores, y será jugado sin explicación o demostración.

En consecuencia, la mejor forma de comprobar si es justo es sentar unos cuantos testeadores, por separado, que no hayan trabajado en el juego, y que no hayan visto a nadie jugándolo. Si puede pasar la parte en cuestión con un poco de práctica y sin pistas o explicaciones externas, probablemente es justo.

Si no pueden, entonces investiga si podría ser una de las causas de dificultad que acabamos de comentar; si no está relacionado con estas, considera reajustar alguna de las variables involucradas. Entonces encuentra un grupo fresco de testeadores - como en la caza, es importante que la presa no sepa por donde vienes.

Nota especial acerca de la dificultad inicial

Hay una regla famosa, de los viejos tiempos de Atari, que dice que es imposible hacer tu primer nivel demasiado fácil o demasiado corto. Por pura virtud de la mente del jugador adaptándose a nuevas configuraciones, nuevos controles, nuevos personajes, nuevas dinámicas, y nuevo audio, el cerebro recién llegado está sobrecargado y desafiado sin que haga falta añadir dificultad a la jugabilidad. Al final se sobreponen a la sobrecarga, buscando una respuesta acerca de si su inversión en tiempo merecerá la pena. Mientras tanto, es crucial llevarlos rápidamente desde esa configuración corta, fácil y sencilla a una jugabilidad real, para no perder la atención del jugador creando la impresión de que la actividad del juego es muy superficial.

Es fácil perder al jugador abrumándolo con un examen de rendimiento demasiado pronto. Esto puede asustar a los que prueben el juego haciéndoles creer que no pueden controlar la dificultad del juego.

Es fácil perder al jugador aburriéndolo ignorando el nucleo de la jugabilidad por demasiado tiempo. Esto puede perder a los que prueben el juego por una sensación de que el juego no es muy convincente.

Mientras tanto, la inmediata recompensa de progreso sirve como un aperitivo hacia el plato principal del juego.

Es imposible hacer tu primer nivel demasiado fácil o demasiado corto.

V.) Ponte en acción - No seas un burro

Te presento al burro

"Si no estás seguro de la opción a escoger entre dos alternativas para hacer algo, hazlo de las dos formas posibles y mira cual es mejor."

-John Carmack

El burro de Buridan (tradicionalmente conocido como "Asno de Buridan") es una parábola filosófica en la que un burro, enfrente a dos balas de paja, es incapaz de decidir cual escoger para comer. Paralizado por la indecisión, el burro muere de hambre, justo al lado del doble de la comida que necesita.

Demasiadas ideas, insuficiente acción

Mucha más gente tiene las habilidades relativas a la realización de juegos - programación, arte digital, escritura de historias - que el número de personas involucradas en la realización de juegos. El problema en muchos casos no es la falta de ideas para videojuegos, es que se tienen demasiadas ideas para videojuegos, y no se está seguro acerca de como eliminar las malas y dejar las buenas.

Sin ser capaz de diferenciar las malas de las buenas, ¿como puede alguien saber en qué conceptos debería empezar? ¿Cual será el uso más efectivo de su tiempo?

Igual que intentar colar demasiado por un embudo, el camino del cerebro a las manos se atasca con la incertidumbre acerca de como reducir las posibilidades.

Como diferenciar las malas de las buenas

Puedo darte mi respuesta a esta pregunta, pero no te será de mucha ayuda.

Lo que es una buena idea para mi está basado en los videojuegos que conozco mejor, las ideas que más me apasionan, los tipos de trabajos que en mi experiencia personal me han llevado a ver con más claridad.

Lo que queremos saber es "¿qué es una buena idea para ti?", y sólo hay una forma de saberlo...

Como saber como diferenciar las malas de las buenas

Hacer juegos que acaban siendo pobres es la forma en la que aprendes qué ideas son malas para ti.

Hacer juegos que acaban saliendo bien es la forma en la que aprendes qué ideas son buenas para ti.

Realmente no hay una forma mejor de saberlo. Nadie puede saberlo por ti.

No puedes saber por adelantado hasta que ya has hecho algunos juegos como tener un sentido de tu forma de trabajo, lo que te dirige, la forma en la que ves las cosas mientras trabajas en ello, y como la gente que respetas responde a diferentes aspectos de tu trabajo.

Coje una de tus ideas de videojuegos que puedas crear rápida y fácilmente. Si no puedes decir con seguridad cual de tus ideas es la más rápida/fácil, suelen ser las más pequeñas y simples, o simplemente coge una al azar. ¿Por qué la que puedas crear más rápidamente y fácilmente? Mira la vieja regla de Atari para la dificultad inicial.

Luego, haz ese juego.

Lo más rápido y lo más fácil - Porque las primeras ideas siempre son las más pobres

Casi sin excepción, sea cual sea la idea que una persona decide hacer primero será siempre pobre, da igual lo que intente. Esto es particularmente cierto si alguien está haciendo un juego por su cuenta, en vez de hacer equipo con alguien que tenga más experiencia.

Más claro: la mayoría de primeros proyectos serán, con total seguridad, malos.

Eso es cierto aunque el proyecto tenga potencial para ser bueno si se hace después de acumular más experiencia. Los desarrolladores principiantes necesitan salir fuera del sistema. Cuanto antes lo hagan, antes podrán aplicar las lecciones aprendidas en ese proceso a un segundo proyecto de juego. Entonces es posible enterrar ese primer trabajo mortecino bajo una pila de nuevos y mejores trabajos, como el resto de nosotros, los que llevamos ya un tiempo, hemos hecho.

Ver a la gente comenzar su juego soñado como su primer juego es descorazonador. Es un plan seguro para fracasar y quemarse. Nunca tendrá la suficiente calidad para que te sientas bien lanzándolo, pero la incapacidad para finalizar el primer proyecto (y el efecto asociado a relacionar desarrollo de juegos con arruinar un proyecto soñado) puede distraer e impedirte regresar al desarrollo de juegos. Lo he visto ocurrir a docenas y docenas de colegas estudiantes que tenían ilusión por desarrollar videojuegos.

(El que el primer juego de un desarrollador será malo, y debería ser tirado, era el punto 1 de 3 en una vieja presentación que monté en el 2006 para principiantes en el desarrollo de videojuegos. Échale un ojo a los puntos 2 y 3, para enfrentarte a esos desafíos.)

Sobreproducción

A pesar de que la fama de Carmack como un programador legendario significa que sus citas se aplican típicamente a la programación de videojuegos, cada pequeña parte de ellas es relevante para el arte, diseño y audio. Mi mejor trabajo vino de cuando creé el 50% o más de niveles o características que pretendía mantener, y luego me deshice de la parte más floja de lo que hice (sobre 1/3). Algunas ideas excitantes no funcionaban tan bien dentro del juego, y es difícil saberlo con anterioridad. Este modelo de sobreproducción promueve el tomar riesgos y aprovechar oportunidades, intentando ideas que puede que no funcionen, porque hay pocas opciones para retroceder.

El 60% del trabajo de cualquiera es, obviamente, mejor que el otro 40% de su trabajo.

La idea de la sobreproducción es un poco como hacer prototipos, excepto que en vez de centrar toda tu energía en una cosa como una prueba de concepto, divides tu energía intentando unas cuantas opciones distintas a la vez. Si tu gastases tu tiempo haciendo 9 niveles hasta la mitad, cuando sólo necesitas 6, bocetar 4 variaciones de un icono cuando sólo necesitas uno, o intentar unas pocas variaciones del núcleo de la jugabilidad o la velocidad de juego, antes de decidirte por una, con estas cosas eliminas un montón de suerte de la ecuación. Hay cosas que no podemos saber hasta que las intentemos y las veamos funcionando en la pantalla con un mando en la mano, y esas son las cosas que hacen que un videojuego sea diferente.

No sólo se ha de ir más allá en la programación, también hay que hacerlo en la creación de contenido, lo que nos lleva también a hacerlo con la creación de juegos. Mis mejores juegos gratuitos descargables no son los únicos seis proyectos en los que he trabajado - han sido posibles en el contexto de los muchos otros juegos gratuitos descargables que he creado. Mis 42 experimentos de jugabilidad favoritos no son los únicos 42 que he hecho, para que existan he tenido que emplear 7 meses haciendo un total de 219.

En la industria musical, uno de los patrones típicos, de donde sale un disco fantástico e irrepetible, es cuando el primer lanzamiento importante de un grupo se empaqueta con 18 de las mejores canciones que han tocado, de entre docenas, incluso cientos. Cuando su próximo CD sale, están compitiendo contra el mejor material que han acumulado en los años previos a hacerse famosos.

Incluso los mejores futbolistas no consiguen un gol siempre que lo intentan, cada obra que escribió Shakespeare no fue impresionante (algunas de ellas se consideran bastante malas), y cada juego que un desarrollador hace no será su mejor trabajo. Pero al haberlo creado aumenta el conjunto de ideas, conceptos y código que podría emplearse en nuevos proyectos. Al haberlo creado se incrementa el cúmulo de experiencias con variedad, extensión, y subproductos tangibles, donde un desarrollador puede rebuscar y repasar para identificar sus mejores trabajos.

Solución

Es difícil diferenciar que idea parece mejor, ve por las más rápida. Si no puedes diferenciar cual es la más rápida, coge una al azar, lanza una moneda si es necesario. Si tienes tiempo, dinero, pasión, y el estomago para ello, cóme las dos balas de paja, empezando por cualquiera.

Come la paja. No tengas hambre.

Si estas sentado pensando hacer videojuegos y aun no los has hecho, tanto si sigues mis lecciones como si no, tanto si piensas que tienes tiempo o no, ve y haz el videojuego más fácil y rápido que puedas. ¿Necesitas más ayuda para empezar? Mira esto las otras lecciones gratuitas, para obtener más información y enlaces a recursos. Da igual que excusa tengas en mente, otros miles de lectores están pensando lo mismo - si encuentras la forma de ponerte en marcha y motivarte lo suficiente, estarás inmediatamente por delante de miles de aspirantes a desarrolladores.

VI.) Donaciones

Estas lecciones gratuitas están desarrolladas como un regalo a la comunidad, y me gustaría continuar desarrollándolas, pero me lleva bastante tiempo prepararlas. Si crees que estas lecciones te resultan valiosas, y puedes permitirte hacer una pequeña donación de 10$ (el precio de un libro pequeño), 30$ (el precio de una sesión de asesoramiento en grupo), o incluso unos pocos dólares (para mostrar tu apoyo, y motivarme), lo apreciaría muchísimo y me ayudaría a continuar dedicando el tiempo necesario para mantener la calidad como una prioridad en estas lecciones. PayPal hace que las transacciones sean seguras y sencillas - ni siquiera necesitas tener una cuenta en PayPal si tienes acceso a una tarjeta de credito:

VII.) Próximo boletín

Edición especial - una entrevista con Warren Robinett

Hace poco he tenido la oportunidad de entrevistar a la leyenda del videojuego Warren Robinett (desarrollador de Adventure para Atari, y cofundador de "The Learning Company"). Me hubiese gustado incluir algunas notas de esa entrevista en este boletín, pero la transcripción y edición de la charla informal consume más tiempo del que esperaba. Estará lista para el boletín del mes que viene - ¡confiad en mi!

Chris DeLeon

chris@gamedevlessons.com

PD Estoy escribiendo estos boletines para ayudar a la gente, y quiero que su contenido llegue al máximo número de personas posible. Por favor pasa este enlace si sabes de alguien al que le podría ser útil; http://gamedevlessons.com/lessons/carta5.html Enviar el enlace es mejor que copiar el texto entero y enviarlo, ya que de esta forma siempre verán la última versión con preguntas y respuestas o correcciones.

Nota sobre la traducción: este boletín ha sido creado originalmente en inglés y para una audiencia anglosajona por Chris DeLeon. He procurado adaptar, en la medida de lo posible, el texto a una audiencia hispano parlante, y en particular, Española. En sus comentarios Chris habla de la industria del videojuego en el mundo anglosajón, aunque no se apliquen por igual en nuestro caso creo que son bastante útiles.

Aparte del sitio web de Gamedevlessons también podrás encontrar estas traducciones en mi propia página web, en http://www.proyecto-iris.com, donde siempre mantendré una sección dedicada a estos boletines para ayudar en su difusión.

Andrés de Pedro