A día de hoy, la gente sigue creando nuevos videojuegos para consolas que llevan mucho tiempo descatalogadas, algo que en inglés se conoce como _homebrew_ y que muchas veces sirve para cumplir un sueño de la infancia creando un juego para la consola que tenías cuando eras pequeño.
Pero también se trata de un divertido desafío para cualquier persona que se dedique al diseño o desarrollo de videojuegos: El hardware retro tiene muchas restricciones que desafiarán tu creatividad. En los años 90, dichas restricciones eran todo un embrollo para los desarrolladores profesionales. Sin embargo, hoy en día contamos con mejores herramientas y la creación de juegos para esas consolas es mucho más accesible.
El año pasado escribí un artículo sobre [cómo hacer un juego para la Game Boy][1] y hoy quiero compartir mi experiencia a la hora de crear tres videojuegos para la videoconsola SEGA Mega Drive. Probablemente se trate de la videoconsola más fácil a la hora de hacer un videojuego homebrew, gracias a las potentes herramientas disponibles. Por ejemplo, conseguí crear un juego (muy básico) en 60 minutos que funciona en la consola.
Los juegos
El año pasado, con motivo del 30 aniversario de la Mega Drive, hice un videojuego titulado ['30 Years of Nintendon't.'][2]: obviamente un tributo a los mejores juegos de la videoconsola y a la agresiva estrategia de márketing que SEGA llevó a cabo en su momento (con el eslogan "Genesis Does what Nintendon't."). Genesis era el nombre con el que se conocía a la Mega Drive en Norteamérica.
En este juego eres un evangelista de la SEGA que debe convencer a otros jugadores a dejar sus videoconsolas NES y SNES porque la Mega Drive tiene mejores juegos. El juego fue publicado online de forma gratuita durante el 30 aniversario de la consola y se puede jugar aquí.
Desde entonces, también he creado otros dos (pequeños) juegos arcade para la videoconsola:
['Break An Egg'][6] (_Rompe un huevo_)
['MeteoRain'][8] (_Lluvia de meteoritos_)
Estos tres videojuegos están ahora disponibles en un cartucho publicado por Cote Gamers. Viene en una preciosa caja de plástico como los videojuegos vintage reales y trae una serie de postales de regalo.
¿Puedo usar Unity, Unreal Engine o Godot?
Siento decir que, desafortunadamente, dichos motores de juego no pueden exportar videojuegos a la SEGA Mega Drive (o por lo menos de momento). Pero no hay problema, puesto que existe otra herramienta que es tan útil como esos otros motores de juego más populares y que está hecha a medida para los juegos de Mega Drive: [SGDK][12]. Se trata de una herramienta que te permite escribir código para esta máquina en lenguaje C.
Es mucho más sencillo y rápido de aprender que el lenguaje Assembly que era obligatorio en los 90. Pero la cosa no acaba aquí y SGDK también viene con varias herramientas para facilitar la creación de los gráficos y de sonidos.
Puedes hacer tus propios gráficos con tu editor de gráficos en 2D favorito (desde Photoshop a GIMP o Asesprite) y se convertirán automáticamente al formato adecuado siempre y cuando respetes las limitaciones del hardware (hablaré de esto en más detalle más adelante).
Lo mismo vale para el sonido: puedes crear tus propios efectos de sonido en archivos .wav y para la música puedes utilizar varias herramientas de seguimiento. Además, SGDK tiene un potente "Sprite Engine" que simplificará la mayor parte de las tareas técnicas para reproducir imágenes en movimiento en la pantalla. ¿Cómo de fácil es todo esto en realidad? En este artículo te daré mi opinión personal sobre este asunto.
Aquí llega el "blast processing"
Como te diría cualquier programador de juegos vintage, escribir un programa en C en vez de Assembly tendrá un coste en el rendimiento de tu videojuego, y es verdad. Sin embargo, el coste cambia significativamente de una videoconsola retro a otra. Depende de la CPU que utilicen y también de la eficacia de los compiladores modernos a la hora de crear código para procesadores tan antiguos.
Afortunadamente, la Mega Drive utiliza un procesador Motorola 68000 que está bien adaptado para procesar las particularidades del lenguaje C. Esto resulta especialmente cierto si lo comparamos con otras CPUs como la 65819 de la SNES. Si bien se trata de un procesador bastante potente por sí mismo, la CPU de la SNES tiene problemas a la hora de ejecutar programas escritos en C a una velocidad razonable. Así que cuando se trata del desarrollo de videojuegos homebrew en lenguaje C, el "blast processing" ya no es simplemente un mito de márketing, sino toda una realidad.
¿Cómo de rápido se puede ejecutar tu código en C?
A modo de ejemplo personal, muestro un gif animado de mi juego 'MeteoRain' con 45 partes de meteoritos moviéndose sin problemas a 60fps:
Aquí otro ejemplo de una explosión a base de 40 partículas moviéndose a 60fps en mi videojuego 'Break An Egg':
Si echamos un vistazo a los videojuegos vintage, un buen ejemplo de la potencia de la CPU de la Mega Drive es 'Contra Hard Corps'. Si bien el juego fue desarrollado en Assembly y no en C (eran los 90), los desarrolladores fueron capaces de utilizar la gran potencia de procesamiento para mover muchos _sprites_ por la pantalla, creando jefes inolvidables con muchas partes en movimiento y grandes explosiones.
A modo de comparación, 'Contra III' para la SNES se vio limitado por la potencia de la CPU y en vez de mover muchos _sprites_ en la pantalla Konami tuvo que conformarse con otros efectos gráficos que eran exclusivos del chip de vídeo de la SNES, como la transparencia.
Si bien ambos juegos se pueden disfrutar al mismo nivel, son un buen ejemplo de las diferencias técnicas entre la SNES y la Mega Drive. Puedes leer más detalles sobre cómo Konami adaptó cada videojuego para su respectiva plataforma en el artículo _"Making of Contra III and Hard Corps"_ de la [Retro Gamer #176][14].
Limitaciones gráficas
Teniendo en cuenta que la potencia de procesamiento no es un problema, el principal escollo de la Mega Drive para desarrolladores homebrew son sus limitaciones gráficas, sobre todo el limitado número de colores que puede mostrar en pantalla.
Aunque la consola puede generar 512 colores únicos en total, solamente se pueden mostrar 64 colores al mismo tiempo en la pantalla. ¡Ay!. En comparación, la SNES puede mostrar 256 colores al mismo tiempo a partir de una paleta de 32768 colores únicos. Así que los artistas gráficos tenían que tener mucho talento para hacer que los juegos de la SEGA tuvieran un aspecto tan bueno como los de la competencia y en muchas ocasiones lo lograron.
Muchos de los videojuegos vintage de la Mega Drive se veían tan bien como los de la competencia a pesar de las limitaciones de color: es el caso de videojuegos como 'Comix Zone', 'The Story of Thor', 'Streets of Rage II', 'Ranger-X', 'Gunstar Heroes', 'Sonic 1-2-3', etc.
Pero en otras ocasiones los videojuegos de la Mega Drive tenían un aspecto bastante soso en comparación con las versiones para la SNES. Uno de los ejemplos más famosos es 'Street Fighter II', donde las limitaciones de color en la videoconsola hablan por sí solas:
Hacer un buen uso de las limitadas paletas de color disponibles (4 paletas de 16 colores para la Mega Drive vs. 16 paletas de 16 colores en la SNES) era todo un reto para los desarrolladores que normalmente contaban con un tiempo muy limitado para completar sus proyectos. Hoy en día, algunos miembros de la comunidad SEGA con mucho talento son capaces de arreglar algunos juegos para mejorar el uso que hacen de los colores. Por ejemplo, [Gabriel Pyron][15] está haciendo maravillas en juegos como 'Castlevania Blood Lines', 'Golden Axe', 'Outrun' o el anteriormente nombrado 'Street Fighter II’:
Teniendo eso en cuenta, puedes utilizar tu programa favorito de edición de gráficos para crear tus imágenes siempre y cuando tengas mucho cuidado a la hora de elegir los colores. Si no se corresponden con la paleta real de 512 colores establecida en el hardware, no es un problema: SGDK automáticamente convertirá tu imagen a la paleta de la Mega Drive. Pero cuando se trata del número total de colores utilizados y mostrados en la pantalla, eso ya es tu problema.
Hacer que las cosas se muevan
Para mostrar algo en la pantalla primero tienes que copiar los datos gráficos de la ROM a la RAM de vídeo. De hecho, el procesador gráfico no tiene acceso directo a los datos de la ROM, pero puede leer datos de la RAM. Así que para hacer el fondo o las animaciones de los _sprites_ tienes que copiar de forma regular los nuevos datos de la ROM a la RAM y la cantidad total de RAM de vídeo (VRAM) disponible es limitada: 64KB. No es mucho en comparación con tamaños de ROM de videojuegos que van de los 512KB a los 8MB.
Escollo #1: Transferencia de VRAM
Si estás creando un juego muy pequeño con pocos elementos gráficos, puedes simplemente cargarlos todos a la vez al arrancar el juego, pero la mayoría de los videojuegos necesitan tener los datos gráficos constantemente actualizados a la VRAM para mostrar muchas animaciones diferentes, ¡lo que normalmente se traduce en muchos problemas!
De hecho, la cantidad de datos gráficos que puedes enviar de la ROM a la VRAM por cada fotograma (a saber, 60 veces por segundo) es limitada. Para ser exactos, se trata de 7524 bytes por fotograma, lo que equivale a unos 7KB. Si quieres que se muestren _sprites_ animados gigantes además de fondos animados, como en 'Street Fighter II', vas a tener muchos problemas con esta limitación y es solamente el primer de los problemas.
Escollo #2: Limitaciones en los sprites
Con las consolas de 8/16 bits, otra dificultad reside en el número total de _sprites_ que puede mostrar el hardware. Normalmente existen dos límites: uno para el número total de _sprites_ en la pantalla y otro para el número total de _sprites_ en la misma línea horizontal. Para videoconsolas como la NES y la Master System, estas limitaciones son extremas: no más de 8 _sprites_ por línea horizontal y un número total de 64 _sprites_.
¿Significa que podemos mostrar 64 veces a Sonic o a Mario en la pantalla? No, de lo que estamos hablando aquí son de los _sprites_ de hardware que son más pequeños de lo que normalmente llamaríamos un _sprite_. Aquí va un ejemplo de 'Super Mario Bros' para la NES donde hace falta utilizar varios _sprites_ de hardware de 8x8 píxeles para mostrar un solo "_sprite_ de Mario".
Con las consolas de 16 bits, los límites en los _sprites_ se relajaron un poco. En el caso de la Mega Drive puedes mostrar 80 _sprites_ de hardware en total, pero un solo _sprite_ de hardware puede ser tan grande como 32x32 píxeles (en comparación con los 8x8 píxeles anteriores). A modo de ejemplo, dejo varios casos punteros de "_sprite_ de hardware" para la Mega Drive. ¿Te has dado cuenta de que Sonic se representa con solamente 2 _sprites_ de hardware, mientras que hacían falta 8 _sprites_ para Mario en la NES?
Escollo #3: Prioridades de los sprites
Como si eso no fuera lo suficientemente complicado, la Mega Drive tiene otra peculiaridad: la cadena de _sprites_. Cuando dos _sprites_ se solapan, la consola tiene que decidir cuál de los dos mostrar sobre el otro. En la Master System y en la mayoría de las consolas de Nintendo (NES, Game Boy, SNES), los _sprites_ se definen en una tabla grande y su orden en la tabla se utiliza para establecer la prioridad de representación. No hace falta decir que se trata de una herramienta de uso complejo, puesto que hace falta redefinir constantemente la tabla para modificar las prioridades de los _sprites_.
En el caso de la Mega Drive, SEGA optó por un sistema más flexible y sencillo. Al igual que en las otras videoconsolas, todos los _sprites_ cuentan con un número de índice en una tabla grande, pero no se utiliza para establecer la prioridad de los _sprites_. En cambio, cada _sprite_ tiene una referencia en relación al siguiente _sprite_ representado y al final la consola crea una cadena de _sprites_, comenzando con el _sprite_ 0.
Cada _sprite_ solamente tiene como referencia el siguiente _sprite_, lo que te permite modificar con más facilidad las prioridades de los _sprites_ sin tener que reordenar todos tus _sprites_ en la gran "tabla de referencia de _sprites_". Pero siendo sinceros, aunque sea más fácil de utilizar, sigue siendo una traba a la hora de hacer un videojuego donde las prioridades de los _sprites_ cambian a menudo, como puede ser en un juego de lucha (los _beat'em up_ en inglés).
La forma "fácil": el SGDK sprite engine
Hacer que aparezcan en la pantalla los _sprites_ y los fondos en movimiento es todo un reto con tales problemas. Todos los desarrolladores de los 90 lo tenían complicado y muchos de los desarrolladores homebrew siguen teniendo problemas.
Por ejemplo, Matt Philips sacó el brillante juego ['Tanglewood'][18] en 2018 utilizando solamente herramientas de los 90. Programó el videojuego en lenguaje Assembly y utilizo el kit de desarrollo de hardware oficial que había sido diseñado hace 30 años. Se trataba de una decisión voluntaria por su parte para tener una experiencia completa de cómo era el desarrollo de un juego vintage.
Pero para aquellos que no sean tan buenos ni tan pacientes como Matt Philips, las herramientas modernas probablemente sean de ayuda a la hora de tratar con las limitaciones técnicas del hardware.
Ya hemos mencionado cómo el lenguaje C es mucho más sencillo de utilizar que Assembly. Y también podemos decir que utilizar un emulador de la Mega Drive es muy preciso, como por ejemplo el ['Blast’em'][20]. Este emulador, en combinación con un cartucho Everdrive para probarlo en el hardware original hace que el desarrollo de un juego sea mucho más llevadero en comparación con utilizar un emulador de hardware in-circuit activado por un conjunto de herramientas basadas en DOS. Sin embargo, una vez más, el mayor regalo que pone sobre la mesa los tiempos en los que vivimos se llama SGDK.
De hecho, junto con otras opciones, SGDK también viene con un "Motor de _sprites_" bastante potente que te hará las cosas más fáciles. Se trata de un conjunto de opciones para lidiar con la visualización de los _sprites_ como lo harías en cualquier programa moderno.
Para empezar, ya no tendrás que preocuparte por el número de _sprites_ de hardware necesarios para cada fotograma de animación: SGDK lo hará automáticamente por ti. Además, cuando se trata de las prioridades de los _sprites_, no tendrás que definir manualmente la cadena de _sprites_ porque SGDK lo hará por ti utilizando un valor simple de "prioridades de _sprites_" que puedes asignar a cada _sprite_ como en cualquier programa moderno.
Por último, ¡SGDK también puede gestionar todas las transferencias de VRAM automáticamente! Sí, has oído bien: con el motor de _sprites_, no tienes que preocuparte de la VRAM para nada. Simplemente puedes indicar en SGDK que se muestre "la animación X en el sprite Y" y el programa hará todo el trabajo técnico y complejo por ti. Si alguna vez has tenido que lidiar con este tipo de cosas de forma manual, te parecerá magia, ni más ni menos.
Solamente la funcionalidad del motor de _sprites_ del SGDK es lo que hace de la Mega Drive la consola retro más sencilla a la hora de desarrollar videojuegos, sobre todo si tienes algo de experiencia con el software de programación de videojuegos de las plataformas modernas. SGDK es gratis y de código abierto, pero si quieres ayudar a su autor Stéphane Dallongeville para que siga creando magia en el mundo retro, puedes darle una ayuda en Patreon.
Audio
El audio en el hardware retro también es todo un reto por sí mismo y cada videoconsola es bastante diferente en este aspecto. En el caso de la Mega Drive cuenta con un procesador Z80 dedicado a esta tarea, puesto que está conectado directamente al hardware de audio. Así que para hacer los sonidos y la música en esta videoconsola primero tienes que escribir un "controlador de sonido": un programa para el procesador Z80.
En los 90, cada estudio de producción de videojuegos desarrolló su propio controlador de sonido, adaptándolo a cada videojuego. En los últimos años comerciales de la videoconsola, aparecieron algunos controladores estándar, como los GEMS de Sega of America que fueron utilizados en [cerca de cien juegos de desarrolladores occidentales.][23]
Crear un buen audio en las consolas de 8/16 bits no solo implica tener destrezas musicales, sino también destrezas de programación. Algunos videojuegos con buena música o buenos efectos de sonido fueron masacrados por tener un controlador de sonido malo.
El ejemplo más famoso es, de nuevo, 'Street Fighter II’. El controlador de sonido de este videojuego cuenta con bugs que distorsionan todas las voces en el juego. Muchos años más tarde. Stéphane Dallongeville (creador de SGDK. Recordemos que es un mago) reescribió el controlador de sonido con ingeniería inversa y arregló los bugs. Como resultado, ahora puedes jugar a 'Street Fighter II’ con un "¡Hadoken!" claro y alto. Aquí dejo un vídeo donde puedes apreciar la diferencia:
Volvamos al tema del desarrollo de videojuegos homebrew y a nuestro adorado SGDK. El programa viene con una variada selección de controladores de sonido, dependiendo de lo que necesites hacer en el juego. Por ejemplo, existe el controlador PCM para reproducir un solo efecto de sonido una vez con una calidad de sonido muy alta (como pueden ser las voces). Pero también tienes el controlador XGM. que puede reproducir una pista de audio y 4 efectos de sonido al mismo tiempo.
La mejor función es que puedes cambiar el controlador de sonido que utilizas durante el juego, dependiendo de tus necesidades. Por ejemplo, en '30 Years of Nintendon’t', las muestras de voz de la pantalla de inicio y de la pantalla de game over se reproducen utilizando el controlador PCM para una mayor calidad de sonido, pero durante el juego en sí, puesto que necesitaba tener varios efectos de sonido al mismo tiempo, utilicé el controlador XGM.
En cuanto a los audios, puedes usar herramientas modernas para su creación. En el caso de los efectos de sonidos, tal y como mencionaba anteriormente, puedes simplemente usar archivos .wav que se convertirán automáticamente al formato adecuado. En el caso de la música, la herramienta de referencia es [Deflemask][24], un tracker que puede crear música para el hardware de audio de varias videoconsolas de 8/16 bits.
No tengo mucha experiencia en cuanto a creación de música, puesto que las canciones que utilicé en mis videojuegos procedían de artistas chiptune con mucho talento: Minerscale (Break An Egg) y Warlord (MeteoRain). Ambos utilizaron Deflemask y exportaron sus creaciones al formato VGM que SGDK puede convertir para su utilización con sus propios controladores de sonido.
¿Hacer un juego para la Mega Drive en 60 minutos? ¡Desafío aceptado!
Las _game jams_ son una forma excelente de practicar tus destrezas en el diseño y desarrollo de videojuegos, poniendo a prueba tus capacidades a la hora de crear un juego de cero en un tiempo limitado (normalmente 48 o 72 horas).
En cuanto al tiempo, la _game jam_ más brutal probablemente sea la [0h Game Jam][25]. Tal y como implica su nombre, se lleva a cabo todos los años durante el cambio de horario de invierno. Tienes que empezar a crear tu juego a las 2 de la mañana de la noche en la que se atrasa el reloj y una vez que han pasado 60 minutos, tienes que publicar tu juego en Internet justo en el momento en el que el reloj pasa de marcar las 3 a marcar las 2 de la mañana.
El año pasado decidí participar en esta _jam_ poco después de haber completado '30 Years of Nintendon’t', por lo que ya tenía algo de experiencia a la hora de hacer un videojuego para la Mega Drive y ya apreciaba mucho la simplicidad del SGDK. ¿Pero SGDK puede facilitarme tanto las cosas como para hacer un juego homebrew de 16 bits en solo 60 minutos?
[Aquí tenéis la respuesta][26]:
Siendo sinceros, el resultado se queda bastante corto. El equilibrio del juego es desastroso y hay un bug muy grande en el generador de aleatorio que hace que el juego sea imposible de pasar después del quinto huevo. Tampoco tiene ni fondo ni sonido, etc. Pero se trata de un juego nuevo para la Mega Drive creado desde cero en 60 minutos y que funciona en la consola real. No sé qué pensarás tú, ¡pero para mí es todo un logro!
Además, pensé que la idea principal del juego tenía potencial, así que seguí trabajando en el juego durante muchas horas y acabé teniendo un juego arcade bastante divertido [al que puedes jugar aquí][28]. También está disponible en el [cartucho de '30 Years of Nintendon’t'][29] junto con un tercer juego que solamente está disponible en esta edición física: 'MeteoRain'.
Pasando de homebrew a indie
Aunque los juegos homebrew normalmente son un nicho para aficionados (como yo), algunas consolas siguen siendo una plataforma comercialmente viable para los estudios de programación independientes a día de hoy. Existen dos juegos recientes que son un buen ejemplo: por un lado, ['Tanglewood'][30] fue desarrollado en su totalidad en el lenguaje Assembly, tal y como se trabajaba en los 90, haciendo que el resultado final sea aún más impresionante.
Por otro lado, ['Xeno Crisis'][31] es un juego igual de impresionante que fue desarrollado utilizando SGDK y que se aprovechó de todas las ventajas en cuanto a confort y facilidades que ponen sobre la mesa las herramientas modernas.
Así que si te gustan los videojuegos retro, ¿Por qué no crear hoy tu primer juego para la Mega Drive? Al fin y al cabo, SGDK lo tienes a un solo clic.
Doctor Ludos es un diseñador de videojuegos indie/amateur y miembro de Ludoscience, un laboratorio de investigación científica dedicado al estudio de los videojuegos. Tiene un Patreon donde puedes apoyar su desarrollo de juegos y también edita una newsletter con sus lanzamientos. Puedes encontrar todos sus videojuegos retro aquí.
Foto | Pixabay
Traducción | Silvestre Urbón
Ver todos los comentarios en https://www.xataka.com
VER 12 Comentarios