Todo el mundo tiene sueños cuando es un niño. El mío era hacer un juego para mi primera consola de videojuegos: la Nintendo Game Boy. Hoy he cumplido ese sueño lanzando mi primer juego para Game Boy en un cartucho de verdad: “Sheep It Up!”. En este artículo mostraré las herramientas que he usado y algunos escollos que un recién llegado como yo tuvo que superar para hacer de este proyecto una realidad.
![Hacer un juego para Game Boy en el 2017 (Parte 1) [ENG]](https://cdn.mnmstatic.net/cache/2b/d5/media_thumb_2x-link-2872694.jpeg?1512980766)
Comentarios
Menuda matada. Meneo.
#1 No tanto. La CPU de la GB es de las más fáciles para programar.
Lo más puto son las VBlank de la GB. Un mal uso hace que en el emulador no se note.
En cartucho físico, puede mandar la LCD de tu GB al cuerno.
Me imagino que ese tipo ha aprendido más haciendo ese juego que en dos años trabajando en cualquier empresa actual. Ahora estamos muy acostumbrados a desperdiciar recursos. Muy interesante.
#7 obviamente ha aprendido más de desarrollo de juegos para GB de lo que aprenderá en cualquier empresa, puesto que hoy en día no hay ni una sola empresa que desarrolle nada para la GB ni para un hardware similar. Si se desarrolla para CPUs de características similares (8 o 16 bits, memoria muy limitada y clock de unos pocos MHz) en sistemas empotrados, pero no videojuegos.
Lo que es aprender a desarrollar a bajo nivel, con ensamblador para un CPU determinada, normalmente antigua y con un clock de un par de MHz, te lo enseñan en la universidad. En mi caso me enseñaron con una CPU de 32 bits en lugar de 8, lo cual facilita bastante las cosas. Pero aparte de esto, la base es la misma. El mérito está más en buscar y desgranar los manuales y las herramientas de desarrollo para la GB, y el tema de fabricar los cartuchos, que habrá que esperar a la parte 2 o 3.
Imagino que con "desperdiciar recursos" te refieres a programar a alto nivel, y si, hoy en día en la gran mayoría de empresas se desarrolla en alto nivel, porque es infinitamente más rápido y porque el hardware actual está para aprovecharlo. Desarrollar a bajo nivel no tiene porque traducirse en un mejor rendimiento, y nunca compensa el tiempo que hay que dedicarle. Incluso en software tan crítico como el kernel Linux, se está sustituyendo el poco código en ensamblador que queda por código en C, porque el ensamblador es mucho más difícil de mantener.
#11 Pero el autor programa en C también, no usó ensamblador. De buscarse las castañas, de programación, optimización y de electrónica ha aprendido bastante, y viendo la calidad de la "formación" que te encuentras en empresas y leyendo que el tipo no era experto en la materia no sé si ha aprendido más, pero probablemente sí que se ha sacado unas cuantas cosas de provecho.
#7 El sistema desperdicia recursos por ti. Si haces un juego actual no puedes evitar que Unity o UE te fastidien.
En mi opinión, lo que hace falta saber se aprende haciendo tu propio motor de juego. Entendiendo bien el proceso de los motores 2D/3D a la antigua usanza.
Hay profesionales del sector, de amplia experiencia, que creen auténticas barbaridades y luego el rendimiento se resiente. Y vemos juegos 2D sin partículas con relantizaciones o superproyectos como XCOM2 que son un auténtico desastre pese a ser juegos por turnos .
A mí me ha llegado un diseñador que había trabajado en varios proyectos con Sony Computer a explicarme que una imagen no importaba que fuera 1000x1000 porque la comprimía en JPEG. (JPEG comprime en disco, pero cuando la trata la GPU la vuelve a poner a su tamaño original, haciéndote trizas el rentimiento).
#7 Bueno, en todo desarrollo informático hay varios tipos recursos:
- Recursos de hardware (máquina exigida)
- Recursos humanos (desarrolladores)
- Recursos temporales (tiempo de desarrollo)
Programar en ensamblador optimiza el hardware, pero aumenta de forma exponencial las necesidades de recursos humanos o de tiempo. Usar lenguajes de alto nivel no aprovechará el hardware al 100%, pero permite optimizar los recursos humanos y de hora de programación.
Teniendo en cuenta que a día de hoy el hardware es el recurso más barato y sencillo de ampliar, lo lógico es centrar la optimización en los otros dos.
#32 desarrollar en ensamblador no implica que el resultado final sea más óptimo. De hecho en la mayoría de los casos es al contrario, un compilador casi siempre genera código más óptimo que un humano programando en ensamblador. Hay que ser un auténtico experto y conocerse de pe a pa todas las instrucciones de la CPU para la que programas, y aún así es difícil hacer código en ensamblador más eficiente que el que genera un compilador con los parámetros de optimización adecuados.
Y como bien dices, en los pocos casos que se consigue optimizar un poco el código, no compensa el tiempo de desarrollo, y sobretodo no compensa la dificultad de mantener el código. Por no hablar del tema de la portabilidad, un código en lenguaje de alto nivel se puede portar a otra CPU fácilmente, en cambio en ensamblador lo puedes tirar a la basura y empezar de nuevo.
En cualquier caso, en un juego moderno lo que más consumo de recursos genera con diferencia son los recursos (Imágenes, texturas, efectos de sonidos, música, fuentes, etc) y no el código. No se necesitan los mismos recursos para generar una imagen plana de 240*360 en 4 tonos de grises que en en Full HD o 4k con millones de colores y en 3 dimensiones. Esa es la gran diferencia, y no si se programa en ensamblador, en C++ o incluso en Java.
#29 ¿Cambiar cómo piensa una parte bastante representativa de la sociedad española? Jajajajajajaja…
Si te refieres a cómo se moderan dichos comentarios en Menéame, ahí sí, lo que se puede hacer es poner unas reglas más estrictas y a más moderadores para hacer que se cumplan. Pero, claro, esto va de ganar dinero, no de tener una comunidad decente.
#33 Dudo que mnm cambie la manera de pensar de la sociedad española, desde luego ni se me pasa por la cabeza plantear eso.
Ahi esta el problema, en el momento en que el objetivo es ganar dinero esto se va a la mierda. Por eso envios como el tuyo llegaran a portada de una manera un tanto "forzada" si se quiere mantener una cierta esencia de lo que fue mnm. Estan los subs, pero el problema es que tienen casi nula difusion.
Una de las cosas que mas me llamaba la atencion de mnm es como en ciertos envios muy especificos y tecnicos siempre veias comentarios del tema antes de que llegaran a portada. Ahora llegan a portada muy rapido e igual no da tiempo a nutrir ese envio con mas informacion adicional, pero desde luego, esta bien que se le visibilidad a este tipo de envio como el tuyo y que llegue a la portada general.
Los subs han atomizado mucho la informacion en mnm y a veces se hace imposible encontrar un sub que sirva y sobre todo es decepcionante ver como al enviar algo a un sub determinado, ni cristo bendito clica el link, ya ni hablemos de menearlo.
Muy interesante. Algunos comentarios: (no soy creador de juegos ni nada parecido pero sí he hecho videojuegos amateur des del 90 y pico) - para editar sprites, los herramientas de dibujo como la que sale en el artículo están tipo 20 años atrasadas. Les faltan capas, les faltan filtros, les falta casi todo y solo gustan a nostálgicos hardcore. Hoy en día es mejor empezar usando un software decente de ilustración o edición gráfica (illustrator/inkscape, photoshop/gimp) y luego importarlo al editor de bitmaps de gameboy o lo que sea.
- el tema de las variables de 8 bits, es un reto pero es el pan de cada día para muchos. A día de hoy el mundo sigue controlado por microcontroladores de 8 bits y los programadores se encuentran con el problema cada día, no pasa nada. Si no sabes como lidiar con números grandes en una cpu de 8 bits es bueno hacer un código en C y luego usar el disassembler para ver qué se ha generado y pillar ideas. También como alternativa a la coma flotante se puede usar coma fija con 16 bits y se pueden hacer maravillas sin gastar muchas instrucciones.
Estamos en un momento en el que es "habitual" que se desarrollen, por hobby, en este tipo de plataformas. Tienes software de fácil acceso y herramientas en C.
Sin ir más lejos hay tiendas activas de desarrollo en Spectrum, en el que compras juegos físicos que ha realizado la comunidad. Todo gracias a un transcompilador en C que te ahorra muchos problemas.
Es muy divertido, por supuesto. No hay nada más chulo que estar comiéndote la cabeza para ver cómo metes un sprite más.
En una asignatura de mi universidad, hace siglos, presenté como proyecto un juego en la Visual Memory de Dreamcast y me pusieron un cochino 6. Ahora es portada en Menéame, cómo cambian los tiempos. Envidia cochina.
Para mí tiene realmente mérito el que se pasa años de su vida desarrollando un Mario Bros para PC exactamente igual, hasta los temporizadores, que el original. O el que saca todas las físicas del Sonic de Megadrive y te realiza una guía para que puedas programar tu mismo Sonic. No quiero ni saber cómo se le ocurrió averiguar la aceleración de Sonic en los loops...
http://info.sonicretro.org/Sonic_Physics_Guide
#14 Y sobre todo la satisfacción de disponer de todo el hardware para hacer lo que quieras con él sin un sistema operativo que ponga límites y agregue lentitud.
#20 Pero eso es como disponer de todo el potencial de una pierna sin sistema nervioso que la "limite". ¿Cómo vas a usarla, accionando interrumptores y dándole descargas? No sería práctico.
De acuerdo en que no se optimiza el hardware todo lo que se debería, pero el sistema operativo o el alto nivel no son obstáculos sino herramientas potentes que permiten software más completo, rápido de desarrollar y de fácil actualización.
#14 ¿Hiciste un juego para VM? ¿Cómo lo flasheabas, desde un CD en la consola o directamente a la memoria con algún hardware? ¿Hay notas de tu proyecto o alguno similar? Me parece muy interesante y seguro que no suena nada fácil me gustaría saber más. ¡Y ese cochino 6 seguramente fue injusto!
#28 Dios mío, qué va... ¿qué han pasado, quince años?
Era bastante sencillo, pero no recuerdo los detalles.
El compilado lo saqué de un servicio online que montó alguien, me lo enviaba al email automáticamente. Lo abrías con la Dreamcast y lo instalaba en la VMU.
Los gráficos los hice con un programa que encontré por ahí, frame a frame con sus puntos negros y blancos.
La programación supongo que sería en C, porque en esa época estudiábamos PASCAL y C y hasta que terminé la carrera no me puse a aprender lenguajes más modernos.
#14 respecto a los de las físicas de Sonic, es muy sencillo: mediante ingeniería inversa.
El Sonic de la Megadrive es un juego de culto, y como cualquier juego de culto tiene una legión de fanáticos que lo jugarán hasta el último de sus días.
En este caso el juego está desarrollado para la Megadrive, que montaba la CPU 68k de Motorola, es una bastante CPU simple y sobretodo fácil de programar, ya que su juego de instrucciones es casi completamente ortogonal, y además hay un emulador muy completo que facilita mucho las cosas.
El caso es que unos fanáticos de Sonic hicieron un dump de la ROM y obtuvieron el código fuente del juego, el cual se puede descargar desde la web que has enlazado. De ahí sale lo de las físicas y todo lo demás, no es que lo hayan averiguado por su cuenta.
No sé por qué hay tanto rechazo a esta noticia, antes se mandaban más cosas de este tipo. Ahora todo es política y desgracias
#50 ¿Tanto rechazo? Solo tiene 4 negativos.
#52 Cuando lo escribí andaban discutiendo cómo había llegado a portada.
Resumiendo:
- Píllate el Developers Kit (es lo más rápido), se suele programar en C por lo visto.
- Cúrrate los gráficos y el sonido con cuidado porque la memoria es muy limitada.
- Píllate un cartucho EverDrive para testear el juego en un dispositivo real, por cierto son caros.
- El cartucho final lo explicará en la segunda parte del post-mortem como conseguirlo, no es sobreescribiendo uno existente adelanta.
Yo sinceramente estoy muy interesado en buscar el Developers Kit para la Mega Drive y Super Nintendo y hacer algo para el 2018!
#10 De Snes no tengo ni idea, de Megadrive sí y es bastante sencillo.
Ojo, todo en C. No sé si eres joven y ya te has criado bajo el paraguas de la JVM Para cualquier cosa retro, C (aunque creo que hay alguien haciendo algo en Kotlin)
La página de referencia que conozco es esta. Sobre todo su foro
http://gendev.spritesmind.net
Googleando, aquí tienes un hello world
https://www.bytesizeadventures.com/modern-mega-drive-programming-getting-started/
¡Ánimo!
#16 Soy algo viejuno, he empezado en esto desde hace relativamente poco (3 ó 4 años), con lo cual "la vieja escuela" no la controlo nada. Actualmente trabajo como desarrollador Unity - Arduino. No soy el mejor programador del mundo pero con tiempo y ganas hago todo.
Seguramente no sea coser y cantar pero bueno, sin prisas y en plan hobby puede ser una idea de pm hacer un juego de estos en los siguientes meses. Puedo hacerte un diario desarrollo para que veas mis batacazos si lo deseas
#31 Si consigues tiempo libre para hacerlo, te lo pasarás teta. Y vas a aprender mucho por el camino.
El diario... tal vez se pueda hacer algo así en menéame.
#16 El motor de la mayoría de juegos actuales se programa el C++, que tampoco es tanto cambio respecto al C.
#42 Sí, me refería al desarrollo de juegos, no de motores.
#42 Y una mierda. C++ es un mastodonte con una sintaxis ultrapipercargada.
Al final no sabes como se ejecutará un código u otro según el estado del código o de que si es martes o miércoles. O de como esté especificado en el estandard y/o el compilador.
Si compilar C++ de hace 10 años de proyectos libres puede ser una odisea. Por ejemplo, sheepshaver. O un triste roguelike en C++. No puede compilarlo, no.
Con C coges código del año 94, cualquier jueguillo de texto, comentas algunos extern porque oh sorpresa, ya forman parte de libc de cualquier UNIX y te compila.
C en platformas como plan9/9front tiene tanta dificultad como TCL o Perl. Incluso menos.
12 meneos,y en portada,ya esta la mafia de meneame en acción.
#2 mas bien que cada día menos gente entra a esta web
#3 Es normal, los comentarios cada vez son peores por lo general.
#4 Patata
#5 El veloz murciélago hindú comía feliz cardillo y kiwi.
#17 La cigüeña tocaba el saxofón detrás del palenque de paja.
#38 Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
#38 Qué bonitas historias.
#60 Pues espérate a que lleguemos al whisky, ya verás que figurota exhibiremos.
#5 No es que los comentarios sean peores en cuanto tus patatas, es que los comentarios son cada día más ignorantes, soberbios, egocéntricos, homófobos, xenófobos y machistas. Vamos, como en Forocoches.
/cc #4
#21 Totalmente de acuerdo, y no solo ha pasado en Meneame, sino en practicamente cualquier web donde los usuarios pueden dejar comentarios.
#26 Es el resultado de la masificación y que cualquiera pueda entrar, que nos llenamos de estupidez colectiva.
Abunda más la gente ignorante que la gente inteligente, así que los comentarios empiezan a llenarse de tonterías y los buenos se van a otro grupo más pequeño dejando a la masa con sus tonterías.
Pero teniendo en cuenta que esta es una web para distraerse ¿cuál es el problema?
#39 Se suele decir que la estupidez de un colectivo va definida por el minimo denominador.
Yo creo que hay gente pagada que va por las redes soltando bilis, a sabiendas de que habran seguidores "gratuitos".
Esto ya ha sido comprobado con los rusos y Trump / Brexit, y no me sorprenderia que aqui fuera lo mismo pero pagados por la Falange / PP / Ciudadanos.
#43 Yo creo más bien que la gente hace ese trabajo gratis, pero podría ser que cobrasen. A veces es solo que te quieres distraer un poco e inicias "una bronca" porque sí.
Desde luego que aquí la mayor parte de los comentarios son tonterías pero también es una página para distraerse, no para estar serios.
#46 Yo creo que hay pagados. Si los hubo en Brexit y Trump, tambien los tiene que haber aqui.
Solo tienes que ir a El PPais donde parece que Mariano y Rivera son los nuevo mesias, y todos los que digan lo contrario son hundidos a votos negativos.
#21 Y como se cambia eso?
Pregunto.
#21 vamos, como siempre pero con pluralidad
#4 y los trolls mas abundantes,parece forocoches patrocinado por orange.
#4 El subidón de "cuñaos - ciudadanos - viva España - Yo voté a Podemos pero ya no" que hubo hace 1 mes con todo el tema de Catalunya ha echado a mucha gente de esta web.
Sorprendente tambien que todos los cuñaos - ciudadanos de hace 1 mes tb han desaparecido. Prefieren centrarse en El PPais.
#2 No.
Ante envios realmente peculiares y positivos, la masa no entra al unisono.
Este es el tipo de envios caracteristicos de mnm, relacionados con trabajos didacticos o de ocio o ambas cosas, en temas prioritariamente informaticos (creo yo, sobre todo por el origen del creador de mnm y la filosofia de la pagina) o en cualquier otro tema cientifico que hace de esta web un sitio util para ver cosas que no sueles ver en los demas medios.
Igual la audiencia de mnm esta cambiando o esta menos enfocada en apoyar este tipo de envios. Sea el motivo que sea, se debe fomentar que salgan a portada cosas de este estilo.
No se los entresijos del algoritmo del karma, pero si se fomentan cosas de este estilo (interesantes por si mismas) con menos apoyo del que suelen tener otro tipo de envios, por mi perfecto.
Hay un momento que uno esta hasta los huevos de la mierda politica que tenemos en España.
Hay gente por ahí haciendo juegos y tutoriales de programación de juegos para Commodore 64 que no están nada mal.
http://www.retrogamescollector.com/the-bear-essentials-developing-a-commodore-64-game
#13 Y de paso con la 6502 puedes aprender para la Nintendo de paso. Siendo esta ultima más facil sobre todo en tema de vídeo (usa "mosaicos".)
#36 Lo es, lo es.
Es mucho más divertido hacer un emulador de GameBoy.
#27 Y más fácil.
Te ciñes al estandard, la pantalla de la gb es facil de manejar, la CPU está hipertrillada (a no ser que quieras emular la instrucciones una a una con su ciclo completo, es decir, con el uso de CPU y latencia simulada. Se puede pero es un coñazo).
Para gráficos y sonido, SDL.
Un juego es bastante más jodido. Sonido, música, artwork, programar y que entre en especificaciones que NO están pensadas de antemano muchas veces...
Suena raro, pero para un programador lo tiene más fácil creando un emulador que un juego para esa plataforma excepto de GBA para arriba si usa C, claro. Si usa ASM, el emulador le parecerá más propicio.
Me falta la parte 2 del artículo ¿alguien la ha podido localizar?
Por otro lado ¿hay ejemplos prácticos de desarrollos usando GBDK? Yo casi no he podido encontrar nada, y cuando llegas a la parte de sonido y memory banking apenas hay absolutamente nada.
O yo no sé buscar o en cuanto pasas del tutorial simple de iniciacion al desarrollo para GameBoy no hay mucho más.
Me ha llevado directo a mi infancia
Me pregunto si habrá otros tutoriales parecidos para la NES, o Mega Drive
"In reality". WTF.
Asombroso. Desde luego la creación de software no está lo suficientemente valorada.
También mi sueño, pero para el Spectrum.
Es más práctico hacer mods, si quieres crear un Rom de la nada muchos conocimientos de lenguaje de programación tienes que tener adquiridos.
Yo hacía scripts, mapeados, tiles-sprites, todo lo que se os ocurra.
Para los que votan negativo por no ser una noticia de política, ahí teneis pa que esteis contentos
Guía a Coleta Morada en su gesta para conseguir el voto y limpiar el país de corruptelas y mamandurrias! ¡Lucha en tu camino contra Mariano, Espe, Pantuflo, Marhuender, Pdr y demás casta! ¡Convence a los indecisos, baja a las cloacas y asalta los cielos!
#25 Yo sólo reclamo mi 0,20 de karma.
#34 Ya te queda menos para llegar a 20. Ánimo, tiene que ser super reconfortante.