Dudas sobre programación de videjuegos (antiguamente)

En general se programaba de forma exactamente como ahora, un ordenador, un teclado ,un sdk, documentos tecnicos y un manual de asm

Lo mas normal eran los dev kit, aunque habian formas genericas

Si preguntas cuales, asi q recuerde, pues capcom uso las x68k, la teradrive tenia un sdk para desarrollar en megadrive, y ese PC lleva un x86 y dos

Sobre graficos, existen herramientas muy potentes en todos los ordenadores de la epoca.La misma teradrive traia un buen editor grafico por ejemplo

La Famicom es una de esas consolas chungas, xq nintendo sirmpre fue muy cerrada.Normalmente solo con devkit oficiales

De forma casera, el famicom basic y la sc-3000, son un genial ejemplo de desarrollo prehistorico

theelf escribió:En general se programaba de forma exactamente como ahora, un ordenador, un teclado ,un sdk, documentos tecnicos y un manual de asm

Lo mas normal eran los dev kit, aunque habian formas genericas

Si preguntas cuales, asi q recuerde, pues capcom uso las x68k, la teradrive tenia un sdk para desarrollar en megadrive, y ese PC lleva un x86 y dos

Sobre graficos, existen herramientas muy potentes en todos los ordenadores de la epoca.La misma teradrive traia un buen editor grafico por ejemplo

La Famicom es una de esas consolas chungas, xq nintendo sirmpre fue muy cerrada.Normalmente solo con devkit oficiales

De forma casera, el famicom basic y la sc-3000, son un genial ejemplo de desarrollo prehistorico

Ok ahora entiendo, yo me imaginaba por aquel entonces que todo se programaba en una consola especial, ejemplo una Nes especial para desarrolladores.

Para snes, por ejemplo, los de argonaut se fabricaron un interfaz curioso para programar en SFX. Era una tarjeta isa conectada a un PC, y que a su vez se conectaba a un cartucho con el chip SFX que iba conectado a la SNEs. En el pc tenían el SDK con el compilador de snes/sfx, que volcaba directamente el código en el cartucho y probar en la consola el resultado según iban haciendo pruebas, a modo de flashcart.

En PSX tengo vagos recuerdos de una tarjeta isa que se enchufaba al ordenador, yque tenía el HW de PSX para ayudar al ordenador a emular la consola mientras codificaban, pero no se donde lo lei .

La idea era conectar la consola al ordenador.

Después se programaba en el ordenador en el asm de la consola
y se volcaba a esta última.

Este sistema se utilizó también de ordenador a ordenador.
Opera Soft programaba en un sistema y generaba código ejecutable para otros ordenadores.

Incluso había un kit de dedarrollo en el que conectabas un PC con un Amstrad CPC y pasabas código del PC al Amstrad y así se podían hacer programas más grande (en el cpc no tenías que tener el compilador ocupando memoria).

En la actualidad si desarrollas para Android se hace más o menos lo mismo (salvo que uses motores como Unity, je). Conectar el móvil al ordenador y mandas el programas desde el PC (se tarda menos que usando el emulador).

Los gráficos normalmente se dibujaban en una hoja de cuaderno y después se metían pixel a pixel con programas tipo paint de win95 pero sin ratón je je.

Antes de la era PC, Atari inicialmente utilizaba ordenadores VAX. Suele haber bastante informacion de ex-empleados comentando sus experiencias.

Posteriormente para el desarrollo de juegos para la Atari 7800 crearon herramientas para el Atari ST:
http://www.atarimuseum.com/videogames/c ... 800/games/

Pero si quieres ver estampa tipicamente ochentera, me quedo con las imagenes de GCC, empresa que comenzo haciendo 'hacks' y que acabo desarrollando arcades y juegos de 2600/5200/7800 para Atari:
http://galleryszy.stevenanne.net/archiv ... ork_8.html
http://galleryszy.stevenanne.net/archiv ... ork_6.html
Mas ochentero imposible.

Y en un video de Imagic muestran como hacian los graficos para sus juegos en un Atari 800, no se si con un programa comercial o "hecho en casa":
http://www.youtube.com/watch?v=qmrZUNIDM2k




Ya un poco mas moderno. tambien hay entrevistas a ex-miembros de Gaelco, por si te interesa a nivel de arcade:
http://retrovicio.org/miscelanea/entrev ... -ag-gaelco
http://retrovicio.org/opiniones/entrevi ... er-fradera

En la época de los graficos basados en tiles (NES, Master System y adelante) ya existian ordenadores y software hecho para pixelart, que te convertían el dibujo en arrays de datos hexadecimales. El juego se programaba siempre en ensamblador.
Antes de eso, en los 70`s, los graficos eran mas simples y no se usaba ordenadores para diseñar graficos, simplemente se generaban los arrays a pelo o bien se hacían bocetos en cuadricula. Los graficos eran muy simples y no era demasiado dificil sacarlo.

Me encanta la información que estáis añadiendo, grande EOL. Que no pare la cosa !!

Te hablo desde el desconocimiento, pero te voy a indicar ciertos detalles de los que no se ha hablado todavía.

Según pienso yo, en los grupos de desarrollo de juegos, todo giraba en torno a los programadores. Esto es, había grafistas, músicos, etc. pero eran los propios programadores los que creaban sus herramientas para que estos pudieran trabajar cómodamente. Si un grafista tenia que crear o volcar sus diseños a datos (como dice berto), eran los programadores los que le hacían y mantenían la herramienta software que conseguía esto, y los mismos programadores sabían como se debían guardar los datos una vez pasado el diseño ya que sabían como se tenían que incorporar al juego.

Claro que también había unos programadores “jefes” (lo que hoy serían analistas) que eran los que montaban preparaban previamente todo el cotarro: cuanto ocupará el juego, que algoritmos/motores usar, como se organizan los datos/algoritmos en el juego final, optimización, compresión, etc. (motores sería por ejemplo el conjunto de algoritmos que definen el funcionamiento de las físicas del juego: gravedad, colisiones, etc.).

También es verdad que muchas de las herramientas, algoritmos y motores de los que hablo, se reutilizaban para varios juegos de la misma compañía (o las vendían/compraban entre compañías), así no había que crearlas de cero, y tenían la seguridad de que funcionaban bien porque ya estaban más que probadas en juegos anteriores. Esto lo deduzco porque hay muchos juegos con ciertos aspectos muy similares, como la forma de saltar, moverse, como se guardan los mapas internamente en el juego, etc.

Como te digo son deducciones mías, no se si sería exactamente así, pero creo que me aproximo un poco.

Siempre he deseado hablar con alguno de aquellos desarrolladores japoneses para preguntarle como funcionaba todo y como hacían tales maravillas en ensamblador

Esto no iria relacionado con el último capítulo de retroactivos?

hahaha icecaap, me ha encantado tu mensaje. Me has recordado a esos programas de Discovery que hablan de las construcciones de los egipcios, los dinosaurios o de que como evolucionarán las especies dentro de millones de años (¡Futuro Salvaje!). Que a pesar de ser sólo hipótesis, lo afirman todo con una convicción que asusta.

Pac-Boy escribió:hahaha icecaap, me ha encantado tu mensaje. Me has recordado a esos programas de Discovery que hablan de las construcciones de los egipcios, los dinosaurios o de que como evolucionarán las especies dentro de millones de años (¡Futuro Salvaje!). Que a pesar de ser sólo hipótesis, lo afirman todo con una convicción que asusta.

Y se me ha olvidado decir que los juegos antiguos en realidad son obra de los extraterrestres!!! No en serio.

Solo lo pongo como hipótesis porque realmente no sé como lo hacían!!!

No hay casi nada, ni información de como lo hacían, ni códigos fuentes en ensamblador de los juegos, ni diagramas, NADA (bueno alguna que otra cosa, como los bocetos de los personajes y tal, pero solo de los juegos más conocidos). Evidentemente son compañías privadas y se preocupaban de no sacar NADA a la luz, supongo que para que no le copien las ideas.

Y mira que he buscado (pero de juegos no tan conocidos), y he encontrado muy poco o nada. He preguntado a profesores de asignaturas de videojuegos y tampoco lo saben.

Como mucho sé de un libro/guía tipo "Making Of" del Landstalker en japonés, uno de los que me gustaría saber como se hizo, pero esta guía se vendió por ebay y no creo que la suban a internet.

Hombre, en relacion a la direccion de un proyecto, si que se podria hacer uso practica o directamente de los mismos sistemas que se usaran en los tiempos de snes o el boom de los retropcs (de empresas que tuviesen un buen sistema pues, como hoy en dia, habra empresas que sean un p. caos).

Me refiero con direccion a como organizar el trabajo, las labores e hitos, ordenar las tareas de tal forma que no se coloquen varias al mismo tiempo. Se podra pensar que "pero esta claro que el trabajo se hace entre varios y en todo momento habra tareas realizandose en paralelo, no?" Si pero hay que prevenir/tener en cuenta que puede darse el caso, bastante facil si se va a la brava (me vas a decir tu....como he de programar yo....y cuantas copas me....me da que eso era de otro tema xD), de estar haciendo al mismo tiempo dos tareas (por simplificar) que "casualmente" una de ellas requiera de la finalizacion y correcto funcionamiento de la otra...ups! entonces...si, toca detener una rama de trabajo hasta que la otra este lista y se tengan los recursos para poder continuar. Eso esta MAL! pero para eso alguien tiene que analizar y planificar y aun asi, como en todo desarrollo software, los imprevistos estan a la orden del dia y las fechas...siempre se quedan cortas

En relacion a programacion, partiendo de que lo mas habitual a dia de hoy es usar el paradigma de la programacion orientada a objetos, nos encontramos ante un planteamiento casi en su totalidad diferente al antiguo. Aparte de que antes podias con "cierta facilidad" aventurarte a crear tus propias herramientas, desde para edicion de graficos, de audio, carga de graficos/sprites,... y todo ello directamente contra el hard pero ahora mismo se suele requerir que todo sea portable y ejecutable en toda plataforma viviente e incluso online, a eso sumar carga de diferentes tipos de texturas, modelos poligonales, texturizado y renderizado tanto 2d como 3d, control de perifericos, juego online, bases de datos, etc etc etc...que te puedes hacer tus propias herramientas? si, que vas a usar librerias de terceros en muuuuuuchisimos puntos? tambien.

Antes era mas artesanal y en plan epoca de descubrimientos y experimentacion, gracias a lo cual se ha llegado hasta las herramientas que se tiene a dia de hoy. Era dificil antes hacer cosas muy buenas? si y tenias que conocer al dedillo el hard. Pero hoy si bien las herramientas son muuuuuucho mejores y automatizadas en muchos aspectos, nos encontramos con que el baremo de calidad ha subido..."un poquito"...y ya no vale hacer un super mario bros, tienes que hacer un galaxy o las criticas te caeran por doquier.

KFR escribió:...y todo ello directamente contra el hard pero ahora mismo se suele requerir que todo sea portable y ejecutable en toda plataforma viviente e incluso online, a eso sumar carga de diferentes tipos de texturas, modelos poligonales, texturizado y renderizado tanto 2d como 3d, control de perifericos, juego online, bases de datos, etc etc etc...que te puedes hacer tus propias herramientas? si, que vas a usar librerias de terceros en muuuuuuchisimos puntos? tambien.

Lo que pasa ahora es que hay un montón de herramientas al alcance de cualquiera, hay más información sobre la metodologías de trabajo y demás, todo en internet. Si te gusta una librería de Java para hacer noseque, te la bajas y la usas. Pero vamos que una cosa no quita a la otra, ahora también es difícil porque son juegos muy complejos, y hay muchas herramientas, pero algunas no son perfectas (la tienes que hacer tu).

Antiguamente todo esto estaba muy cerrado, a nivel de compañía, a lo mejor contactaban con universidades u otras compañías para recibir información o herramientas, y a lo mejor también habían libros sobre ello (pero no tantos como ahora).

Pero es eso, si es que ni sabemos que ordenadores usaban!! Aunque realmente da igual, lo más probable como han dicho es que se conectaba el ordenador a la consola para "volcar" el juego y ejecutarlo, el ordenador solo tenia que compilar a binario el fuente en ensamblador.

Por cierto, aquí hay unas lecciones del colega Maxim de SMSPower sobre como programar para la Master System en ensamblador, quizás sea muy parecido a lo que hacían en la época de los 8 bits para empezar un juego :

http://www.smspower.org/maxim/HowToProgram/Lesson1

http://www.smspower.org/maxim/HowToProgram/Lesson2

¿No sería una pasada ver el código fuente original del Sonic 1 o del Super Mario, así con sus “funciones”, comentarios de los programadores, etc.?

Funciones funciones...a lo que estamos acostumbrado a dia de hoy pues no seria parecido xD asm es otro mundo pero mas en relacion a la "calidad" del codigo, tanto antes como ahora es muuuuy habitual escuchar en entrevistas que el codigo al final termino siendo un caos (mismamente se comento en el Halo 1 y en relacion al prince of persia original creo recordar ). Porque entre prisas, pruebas, apaños para solucionar bugs, problemas imprevistos etc.. pues...al final la maxima es "el juego hay que terminarlo". Y si programacion espaguetti y de esa que duele verla, en lenguajes de alto nivel "duele" y duele de verdad trabajar con ella, en asm...no quiero ni pensarlo, eso estara a otro nivel

Edit: Segun parece fue con Halo 2...aunque me suena que del 1 tambien lei algo.

KFR escribió: Porque entre prisas, pruebas, apaños para solucionar bugs, problemas imprevistos etc.. pues...al final la maxima es "el juego hay que terminarlo".

hahaha yo estuve trabajando en un conocido videojuego y es INCREÍBLE lo que dejan pasar cuando llevan meses (por no decir otra cosa) de retraso y quieren lanzarlo ya.

Ademas añadiria un detalle muy importante y es que antes los equipos incluso de empresas potentes, tendian a ser bastante pequeños, y con bastante me refiero a incluso un unico programador o un par, al estilo de la escena indie actual y codigo hecho por ti mismo y que sabes que solo vas a tocar y retocar tu...uf, DANGER! CHURRO APPROACHING! Otra cosa no pero los programadores tienen manias mil y una y cuando curras en grupo estas "obligado" a hacer cosas limpias y practicas pero cuando haces algo solo para ti...no sueles ser tan..."limpio" y practico xD

KFR escribió:Funciones funciones...a lo que estamos acostumbrado a dia de hoy pues no seria parecido xD asm es otro mundo

Hey! Que "funciones" también había en asm a base de labels y saltos , por ejemplo, aquí está la funcion de descompresión de mapas del juegos como el Asterix de Master System, pues en la ROM está tal cual, pero sin los labels, solo saltos a las direcciones concretas:



Y lo de decir "en 6 meses tiene que estar acabado el juego/aplicación", sin hacer un estudio de estimación de costes/tiempo siempre ha pasado, o si no que se lo digan a tito Gates que lo hacía mucho

Y en muchos juegos de la época también se reflejaba eso, habían muchos que parece que están medio hechos y actualmente nos lo dicen a la cara y todo

Supongo que antes no había herramientas suficientes para llevar a cabo un buen trabajo en equipo, obviando que la sencillez de muchos juegos no lo exigían. No me imagino a los programadores de un juego de los 80' utilizando repositorios o preguntando en voz alta quién tiene abierto tal archivo.

icecaap escribió:Y lo de decir "en 6 meses tiene que estar acabado el juego/aplicación", sin hacer un estudio de estimación de costes/tiempo siempre ha pasado, o si no que se lo digan a tito Gates que lo hacía mucho

Yo siempre me imagino los desarrollos de los típicos juegos basados en películas (Disney, Harry Potter, etc.). Supongo que contratarán a un buen puñado de desarrolladores eventuales, porque a pesar de reciclar, los juegos están listos en poquísimo tiempo. Y con la presión de tener el juego listo para aprovechar el 'boom' de la película, el departamento debe ser un polvorín.

icecaap escribió:Hey! Que "funciones" también había en asm a base de labels y saltos

Si, cierto y conozco la forma de funcionar porque ando pooooooco a poco estudiando asm para z80 y hombre...funciones funciones...para mi son como los "go to" de otras lenguajes o lo que es lo mismo, una mierda pinchada en un palo en lo que a estructura y funcionalidad se refiere

Desde mi experiencia de 10 años ya haciendo "ingeniería inversa" a muchos juegos de RPG de SNES, tengo una ligera idea de cómo se programaban los juegos antes, y me lo llegó a confirmar un interesantísimo artículo que leí hace unos meses en el que el jefe de programación de Secret of Evermore hablaba de cómo se hizo el juego.
Más o menos, se hacía así:

* En primer lugar, nada de lo que se iba a programar se "compraba" a otros: ni físicas, ni "drivers" ni nada por el estilo, al menos entre los 4 juegos que yo he visto de Squaresoft, que a pesar de ser de la misma compañía, lo hacían grupos diferentes. En los 6 juegos (Chrono Trigger, Secret of Mana, Seiken Densetsu 3, Romancing Saga 3, Final Fantasy 6 y Treasure Hunter G), solo he visto en común ¡¡1 RUTINA!! y ni tan siquiera está programada igual (es decir, se nota claramente que la hicieron dos personas diferentes a pesar de ser el mismo algoritmo). Esta rutina era una rutina de descompresión de datos genérica.

* El director encargaba a cada grupo que se encargara de una cosa: unos diseñaban los mapas y los gráficos para ellos, otros diseñan personajes y mostruos y otros componen la música. Todo esto se hace en ordenadores dedicados a ello y no tiene relación en primer lugar con el código programado.

* Cada grupo de programación se encarga de programar en código los efectos gráficos (magias, efectos de lluvia, deformaciones y demás), los menús, las rutinas de audio (lo que vendrían a ser "drivers" de audio que se encargan de cargar en la APU las muestras de audio), las rutinas de video (acceso a VRAM, OAM para sprites y ceran el "driver" de video que se ejecuta en cada NMI, es decir, en cada VBlank) el motor de animación y el motor principal del juego.

* Cuando los gráficos se van definiendo en cuanto a tamaño de sprites, tamaño de mapas y demás, los grupos de programación van adaptando el código generado a las necesidades concretas: parámetros a pasar para las animaciones, parámetros para seleccionar músicas o sonidos, formato del script de texto y de comandos...

* Lo que programan los programadores son funciones grandotas que van llamando a otras menores para realizar el trabajo específico. Por ejemplo en el FF6 y en el RS3, el banco $C3 tenía TODO el código para los menús: cuando se pulsa el botón START, el motor principal del juego llama a la rutina $C3/0000 que toma el control para dibujar los menús, elegir las opciones que selecciona el usuario, cambiar items, equiparlos, etc. Estas rutinas modifican las variables globales que contienen el equipamiento, HP, MP, modificadores al estado, parámetros del personaje, etc, es decir, las mismas variables globales que se graban en SRAM para luego continuar la partida. En estos dos juegos, el banco $C5 contenía todo el driver de sonido, de modo que si hay que reproducir un sonido cuando mueves el cursor, las rutinas de $C3 llaman a la correspondiente en $C5 que hace que suene el sonido de aceptar, cancelar o simplemente el "cling" típico al mover el cursor.

* En cuanto al motor del juego, es un bucle infinito que va ejecutando 4 ó 5 rutinas una detrás de otra para que el juego funcione:
1) comprueba la posición del personaje y la acción que haya ejecutado (hablar con alguien, mirar un cofre, luchar)
2) comprueba si la acción va acompañada de un sonido
3) actualiza el sprite del personaje en la posición que corresponda de la animación
4) actualiza el estado de la inteligencia artificial (posición de enemigos, acciones que ocurren en paralelo, etc)
El motor del juego, en el caso del Secret of Evermore y según las palabras de su propio programador jefe, iba ejecutando los comandos que se metían en un lenguaje de scripting que ellos mismos habían creado para el juego. Este lenguaje, convertido en pseudo-código sería:

- <SET_GRAPHIC_MAP 0x54>
- <SET_TILEMAP 0x31>
- <SET_NPC 0x10>
- <SET_EVENT 0x07>
BUCLE
- <UPDATE_GRAPHICS>
- <UPDATE_NPC>
- <UPDATE_CHARACTERS>
- <CHECK_INPUT>
- <BRA BUCLE>
- <IF SALIDA_IZDA = 1 GOTO XXXXX>
- cosas a hacer si el personaje sale por la izquierda del escenario
XXXXXX
- <IF SALIDA_DCHA = 1 GOTO YYYYY>
- cosas a hacer si el personaje sale por la derecha del escenario
............

Por ejemplo, para una de las escenas del juego donde el personaje se mueve por la ciénaga, se cargan en VRAM los gráficos (bloque 0x54, que podría estar comprimido en ROM), carga la configuración del tilemap que contiene la posición en pantalla donde van esos gráficos (bloque 0x31 con la información de la posición de cada tile en pantalla), carga la lista de enemigos presentes o de otros personajes no manejados por el jugador (lista de enemigos 0x10) y crea la lista de eventos, es decir, las posiciones donde el jugador interactúa (lugares donde hay escondidos materiales para la alquimia, salidas del escenario, personajes con los que se habla) y luego entra en un bucle en el que se actualizan los gráficos del escenario (animación de la hierba, árboles...), los gráficos de los enemigos, los del personaje principal y el perro y por último, comprueba la pulsación del mando para saber dónde mover el personaje en el siguiente frame, o si se ha salido del escenario, etc...
Todo este script de comandos se codifica luego en hexadecimal y tiene esta forma:
- 0x00 0x54
- 0x01 0x31
- 0x02 0x10
- 0x03 0x07
- 0x10
- 0x11
- 0x12
- 0x13
- 0x80 0xFB

Así, las rutinas del motor lo que hacen es ir leyendo este código hexadecimal de esta forma:
* Leo un 0x00, así que sé que es la rutina que vuelca a VRAM los gráficos
* Al ejecutar esa rutina, necesito un parámetro para saber qué gráficos son los que vuelco a VRAM, y ese parámetro es 0x54, por lo que accedo a un array en ROM y en su posición 0x54 obtengo el puntero donde empiezan los datos gráficos en ROM (comprimidos o no)
* Luego leo un 0x01, que es la rutina que crea el tilemap de los gráficos
* Al ejecutar esa rutina, necesito un parámetro de nuevo para saber cuál es la composión exacta del tilemap, y ese byte es 0x31, por lo que accedo a otro array diferente en ROM donde obtengo el puntero a una tabla en ROM que es el tilemap
* Y así sucesivamente hasta que se acaba el script que es cuando se ha terminado el juego.

Este tipo de script de comandos puede estar separado del script de texto con todo el diálogo, como en el caso del Final Fantasy 6 o del Secret of Evermore, o bien mezclado todo en el mismo script, como en el Treasure Hunter G, o mitad y mitad, como en el RS3, que el script de comandos hace cosas genéricas y luego en cada escena le "pasa el control" al script de texto para decidir qué ocurre según los personajes que hayan en el grupo y qué cosas ha de decir cada uno.

En cuanto al lenguaje de programación, normalmente todas las rutinas se hacen en ASM, intentando que no sean muy largas para evitar complicarlas. Por ejemplo, en el Treasure Hunter G, el motor principal parece claramente creado en C, puesto que por aquella época ya era bastante popular y además se nota en la forma de pasar los parámetros a las rutinas. Sin embargo, cada rutina que ejecuta una pequeña acción en concreto, como descomprimir los gráficos, descomprimir los tilemaps, actualizar la posición de los sprites y tal, están claramente programadas en ASM, ya que la forma de pasarle los parámetros no es la misma que la de las funciones principales.

Espero que no os haya liado demasiado y que os haya parecido interesante

En este hilo se habla del tema, http://computeremuzone.com/forum/viewtopic.php?f=4&t=4553&st=0&sk=t&sd=a

Yo lo estuve mirando cuando buscaba información sobre el Infrey Quest, (Adventures of Pinnochio), y me enteré de que los programadores no sabían que el juego finalmente había salido. De hecho no sé si se lanzó oficialmente o solo volcó alguien la rom en algún momento.
Según comentan, usaban spectrum y amstrad como herramientas.

magno escribió:Desde mi experiencia de 10 años ya haciendo "ingeniería inversa" a muchos juegos de RPG de SNES, tengo una ligera idea de cómo se programaban los juegos antes, y me lo llegó a confirmar un interesantísimo artículo que leí hace unos meses en el que el jefe de programación de Secret of Evermore hablaba de cómo se hizo el juego.
Más o menos, se hacía así:

* En primer lugar, nada de lo que se iba a programar se "compraba" a otros: ni físicas, ni "drivers" ni nada por el estilo, al menos entre los 4 juegos que yo he visto de Squaresoft, que a pesar de ser de la misma compañía, lo hacían grupos diferentes. En los 6 juegos (Chrono Trigger, Secret of Mana, Seiken Densetsu 3, Romancing Saga 3, Final Fantasy 6 y Treasure Hunter G), solo he visto en común ¡¡1 RUTINA!! y ni tan siquiera está programada igual (es decir, se nota claramente que la hicieron dos personas diferentes a pesar de ser el mismo algoritmo). Esta rutina era una rutina de descompresión de datos genérica.

* El director encargaba a cada grupo que se encargara de una cosa: unos diseñaban los mapas y los gráficos para ellos, otros diseñan personajes y mostruos y otros componen la música. Todo esto se hace en ordenadores dedicados a ello y no tiene relación en primer lugar con el código programado.

* Cada grupo de programación se encarga de programar en código los efectos gráficos (magias, efectos de lluvia, deformaciones y demás), los menús, las rutinas de audio (lo que vendrían a ser "drivers" de audio que se encargan de cargar en la APU las muestras de audio), las rutinas de video (acceso a VRAM, OAM para sprites y ceran el "driver" de video que se ejecuta en cada NMI, es decir, en cada VBlank) el motor de animación y el motor principal del juego.

* Cuando los gráficos se van definiendo en cuanto a tamaño de sprites, tamaño de mapas y demás, los grupos de programación van adaptando el código generado a las necesidades concretas: parámetros a pasar para las animaciones, parámetros para seleccionar músicas o sonidos, formato del script de texto y de comandos...

* Lo que programan los programadores son funciones grandotas que van llamando a otras menores para realizar el trabajo específico. Por ejemplo en el FF6 y en el RS3, el banco $C3 tenía TODO el código para los menús: cuando se pulsa el botón START, el motor principal del juego llama a la rutina $C3/0000 que toma el control para dibujar los menús, elegir las opciones que selecciona el usuario, cambiar items, equiparlos, etc. Estas rutinas modifican las variables globales que contienen el equipamiento, HP, MP, modificadores al estado, parámetros del personaje, etc, es decir, las mismas variables globales que se graban en SRAM para luego continuar la partida. En estos dos juegos, el banco $C5 contenía todo el driver de sonido, de modo que si hay que reproducir un sonido cuando mueves el cursor, las rutinas de $C3 llaman a la correspondiente en $C5 que hace que suene el sonido de aceptar, cancelar o simplemente el "cling" típico al mover el cursor.

* En cuanto al motor del juego, es un bucle infinito que va ejecutando 4 ó 5 rutinas una detrás de otra para que el juego funcione:
1) comprueba la posición del personaje y la acción que haya ejecutado (hablar con alguien, mirar un cofre, luchar)
2) comprueba si la acción va acompañada de un sonido
3) actualiza el sprite del personaje en la posición que corresponda de la animación
4) actualiza el estado de la inteligencia artificial (posición de enemigos, acciones que ocurren en paralelo, etc)
El motor del juego, en el caso del Secret of Evermore y según las palabras de su propio programador jefe, iba ejecutando los comandos que se metían en un lenguaje de scripting que ellos mismos habían creado para el juego. Este lenguaje, convertido en pseudo-código sería:

- <SET_GRAPHIC_MAP 0x54>
- <SET_TILEMAP 0x31>
- <SET_NPC 0x10>
- <SET_EVENT 0x07>
BUCLE
- <UPDATE_GRAPHICS>
- <UPDATE_NPC>
- <UPDATE_CHARACTERS>
- <CHECK_INPUT>
- <BRA BUCLE>
- <IF SALIDA_IZDA = 1 GOTO XXXXX>
- cosas a hacer si el personaje sale por la izquierda del escenario
XXXXXX
- <IF SALIDA_DCHA = 1 GOTO YYYYY>
- cosas a hacer si el personaje sale por la derecha del escenario
............

Por ejemplo, para una de las escenas del juego donde el personaje se mueve por la ciénaga, se cargan en VRAM los gráficos (bloque 0x54, que podría estar comprimido en ROM), carga la configuración del tilemap que contiene la posición en pantalla donde van esos gráficos (bloque 0x31 con la información de la posición de cada tile en pantalla), carga la lista de enemigos presentes o de otros personajes no manejados por el jugador (lista de enemigos 0x10) y crea la lista de eventos, es decir, las posiciones donde el jugador interactúa (lugares donde hay escondidos materiales para la alquimia, salidas del escenario, personajes con los que se habla) y luego entra en un bucle en el que se actualizan los gráficos del escenario (animación de la hierba, árboles...), los gráficos de los enemigos, los del personaje principal y el perro y por último, comprueba la pulsación del mando para saber dónde mover el personaje en el siguiente frame, o si se ha salido del escenario, etc...
Todo este script de comandos se codifica luego en hexadecimal y tiene esta forma:
- 0x00 0x54
- 0x01 0x31
- 0x02 0x10
- 0x03 0x07
- 0x10
- 0x11
- 0x12
- 0x13
- 0x80 0xFB

Así, las rutinas del motor lo que hacen es ir leyendo este código hexadecimal de esta forma:
* Leo un 0x00, así que sé que es la rutina que vuelca a VRAM los gráficos
* Al ejecutar esa rutina, necesito un parámetro para saber qué gráficos son los que vuelco a VRAM, y ese parámetro es 0x54, por lo que accedo a un array en ROM y en su posición 0x54 obtengo el puntero donde empiezan los datos gráficos en ROM (comprimidos o no)
* Luego leo un 0x01, que es la rutina que crea el tilemap de los gráficos
* Al ejecutar esa rutina, necesito un parámetro de nuevo para saber cuál es la composión exacta del tilemap, y ese byte es 0x31, por lo que accedo a otro array diferente en ROM donde obtengo el puntero a una tabla en ROM que es el tilemap
* Y así sucesivamente hasta que se acaba el script que es cuando se ha terminado el juego.

Este tipo de script de comandos puede estar separado del script de texto con todo el diálogo, como en el caso del Final Fantasy 6 o del Secret of Evermore, o bien mezclado todo en el mismo script, como en el Treasure Hunter G, o mitad y mitad, como en el RS3, que el script de comandos hace cosas genéricas y luego en cada escena le "pasa el control" al script de texto para decidir qué ocurre según los personajes que hayan en el grupo y qué cosas ha de decir cada uno.

En cuanto al lenguaje de programación, normalmente todas las rutinas se hacen en ASM, intentando que no sean muy largas para evitar complicarlas. Por ejemplo, en el Treasure Hunter G, el motor principal parece claramente creado en C, puesto que por aquella época ya era bastante popular y además se nota en la forma de pasar los parámetros a las rutinas. Sin embargo, cada rutina que ejecuta una pequeña acción en concreto, como descomprimir los gráficos, descomprimir los tilemaps, actualizar la posición de los sprites y tal, están claramente programadas en ASM, ya que la forma de pasarle los parámetros no es la misma que la de las funciones principales.

Espero que no os haya liado demasiado y que os haya parecido interesante

Me ha parecido interesantísimo.

No sabía que en SNES habían llegado a programar en C, imaginé que no se hacía por rendimiento.

Gracias Magno.

Un Saludo.

naxeras escribió:No sabía que en SNES habían llegado a programar en C, imaginé que no se hacía por rendimiento.

Bueno, realmente no lo sé al 100%, pero sí es verdad que se nota en el paso de parámetros la acción de un lenguaje de alto nivel. Eso sí, solo lo he visto en las rutinas de control, digamos lo más "complejo" a la hora de mantener.

magno escribió:bla
bla
bla
...

¡Te habrás quedado agusto!

Más post de estos interesantes como el de Magno debería haber y menos fanboyismo asqueroso que inunda los foros.

Un Saludo.

Sega para programar en Megadrive utilizaban un X68000

Estoy de acuerdo con Naxeras,muy interesante,pensaba que los programaban todos en ensamblador.A si que dar las gracias a Magno yo tambien,aunque algunos tecnicismos no he entendido,pero muy buena explicacion que de forma general mas o menos se entiende.

magno escribió:Desde mi experiencia de 10 años

..........
..........
..........

ya que la forma de pasarle los parámetros no es la misma que la de las funciones principales.

Espero que no os haya liado demasiado y que os haya parecido interesante

Interesantísimo Magno, felicidades por el post! .

Coincido con #naxeras, hacen falta más post como este.