Cómo escribir juegos para el ZX Spectrum. Capítulo 19

Índice de entradas

Esta serie de artículos han sido traducidos a partir del documento "How to Write ZX Spectrum Games" con permiso de su autor, Jonathan Cauldwell, un gran desarrollador de juegos para el Spectrum, os recomiendo visitar su Web donde está el texto original. El documento original, y por tanto esta traducción, tiene © Jonathan Cauldwell y solo puede duplicarse con permiso expreso por escrito de su autor.

---

Diseño de juegos

Cincuenta por cien Arte, Cincuenta por cien Ciencia

Ahora ya debes tener suficientes conocimientos para ser capaz de juntar las instrucciones para formar el motor de un juego. Felicitaciones, ahora conoces el cincuenta por ciento de la manera de escribir un juego. Este capítulo tiene como objetivo hacer frente a la otra mitad. Es fácil caer en la trampa de pensar que la escritura de un juego es tan simple como aprender cómo ordenar una enorme variedad de instrucciones en una secuencia coherente, con el fin de llevar a cabo un gran plan. El aspecto técnico es, por supuesto, esencial. Sin embargo, un buen desarrollador de juegos tiene que ser mucho más que un técnico especializado. Tiene que ser también un artista. Eso no significa que debas ser un artista de los gráficos, aunque estos deben ser agradables visualmente no es a lo que me refiero. Estoy, por supuesto, hablando sobre el arte del diseño de juegos.

Se podría optar por seguir el camino de la técnica, escribit tu código para deslumbrar a otros "techies" que saben cómo funciona el Spectrum y lo que puede hacer normalmente. Sin embargo eso es poco probable que impresione a todo el mundo. Para empezar, el juego puede parecer increíble pero podría ser aburrido de jugar y no mantener la atención más de cinco minutos. Lo que es más, no todos los fans del Spectrum conoce las limitaciones de la máquina. Si realmente deseas maximizar tu audiencia, necesitas apelar a los que no saben ni le importa lo que el Spectrum puede hacer. Considera esto: imagina que dos programadores de Commodore 64 liberan sus juegos el mismo día. Uno de ellos escribió un clon del Space Invaders, que sorprendió a los chicos mas técnicos de la escena de Commodore, y el otro escribió un juego técnicamente nada especial pero adictivo, diferente a todo lo que se ha visto antes. Como propietario de un Spectrum que tienes poco conocimiento de los límites de hardware del C64, ¿a cual sería más probable que echaras un vistazo? Los clones del Space Invaders pueden mostrar una increíble magia técnica para esa máquina, pero ¿no es probable que no veas nada que no hayas visto antes en algún otro formato? Consideremos ahora ese escenario al revés: ¿por qué un fan de Commodore, Amstrad, Acorn u Oric quiere descargar tu juego? ¿Que lo hace tan especial que no puedes encontrar algo similar o mejor en su máquina favorita?

Si deseas maximizar el interés, es buena idea ofrecer algo único.

Mecánicas de juegos

Escribir el código del programa es como hacer una gran construcción de Lego formada por miles de minúsculos ladrillos, las instrucciones individuales que dicen a la CPU qué hacer. La mecánica del juego es más afin a Duplo; piezas más grandes pero aún con infinitas maneras de reorganizarlas para alcanzar el efecto que deseas. Un enfoque para el diseño de juegos podría ser considerar los siguientes pasos.

En primer lugar, empieza por considerar el método de control del jugador. ¿Cómo se mueve? Piensa si se limita de alguna manera, y si es así, ¿cómo? ¿Será capaz de realizar acciones o completar tareas para aumentar o modificar su capacidad de maniobra de alguna manera? En líneas generales, cualquier método de control que puedas concebir probablemente ya se ha hecho antes, pero eso no debe impedir que te hagas estas preguntas y busques interesantes variaciones.

En segundo lugar, ten en cuenta las tareas que el jugador tiene que asumir. ¿Cuál es su objetivo? ¿Cómo alcanza la victoria? ¿Está disparando a cosas, procede a su recogida, las coloca en un lugar, previene que suceda algo? ¿Está moviendo cosas alrededor de la zona del juego con algún propósito? La respuesta a estas preguntas unidas con una técnica de control diferente es donde el juego puede empezar a diferenciarse de los innumerables juegos de plataformas, shoot-em-ups, juegos de laberinto o de puzle que hay desarrollados. Empieza de forma sencilla en un primer momento y ve añadiendo ideas a medida que avanzas. No tengas miedo de llegar a puntos donde ya no funciona, incluso si has pasado horas agonizando sobre tu código. Si una mecánica no funciona, no tiene cabida en tu juego.

El tercer paso es considerar los peligros que enfrentará el jugador. ¿Hay un tiempo límite? ¿Hay enemigos que se mueven por el juego? ¿Cómo se mueven, de manera predecible o de otra forma más interesante? ¿Son mortales al contacto o solo hacen que disminuya la energía del jugador? ¿Deben ser destruidos, deben evitarse o ambas cosas? ¿Cambian a medida que avanza el juego? ¿Se pueden utilizar de alguna manera?

Cuando hayas respondido a estas preguntas es necesario considerar si el jugador puede recoger pequeñas bonificaciones, o debe completar mini-tareas que le dan habilidades extra, aumentar su puntuación o su bonificación, aumentar vidas o ayudarlo de alguna otra manera. ¿Esto se debe lograr en un orden determinado para obtener una ventaja aún mayor? Puedes también explorar el camino contrario: ¿existen elementos que pueden ser recogidos que dificultan al jugador?, por ejemplo, con la inversión de sus controles o su fuerte desaceleración. Un error común (que he cometido yo mismo) es reducir las oportunidades de bonificación del jugador conforme el juego progresa. A medida que el juego se vuelve más difícil de jugar, generalmente es buena idea aumentar las bonificaciones con el fin de dar al jugador una oportunidad en el combate.

Si realmente quieres ir a la ciudad, es posible que desees añadir un poco más de profundidad. ¿Debe el jugador considerar una imagen más grande de la que ve en una sola pantalla? ¿Necesita pensar en algo mientras está esquivando, saltando o disparando? ¿Sus logros están llenando un mapa, o un cuadro? ¿Está jugando un juego gigante de tres en raya, de animal, vegetal o mineral, de batallas navales? ¿Puedes incluir elementos en el jardín mientras el jugador sigue su camino por su juego?

Juega mucho con tu juego mientras lo estás desarrollando y sigue haciéndote preguntas. Sé inseguro.

Cuando hayas hecho todo esto, es posible que desees considerar los gráficos, la historia o tal vez incluso la música. Evitar la tentación de comenzar con la historia cuando estás desarrollando un juego para una máquina de ocho bits que, simplemente, no tiene el manejo de gráficos o memoria suficientes para producir la atmósfera que haga justicia a una historia brillante. No vas a escribir el siguiente Grim Fandango. Adapta tu historia en torno al diseño del juego, y no al revés.

Por último, no importa lo bueno y original que sea tu juego, recuerda que no se puede contentar a siempre a todo el mundo. Simplemente disfruta de lo que estás haciendo, diviértete y no te lo tomes demasiado en serio.

¡Feliz desarrollo!