¿De que serian capaces los programadores de los 90?

Archivado
Hoy me he planteado esta duda, y es que podrían lograr los grandes devs de los 90 con la tecnología actual. ¿Serian mejores que los actuales?



Esto me viene a raiz de un video que vi hace poco donde entrevistaban a el cofundador de ND sobre lo que fué crear Crash Bandicoot, y la verdad, me dejó roto. Ya no por la ilusion con la cual recordaba cada detalle (hablamos de algo hace 25 años), sino por la inventiva brutal que tenía esa gente. Comentaba como literalmente tuvieron que hackear la consola para realizar dicho juego, miles de artimañas para poder aprovechar el potencial de los CDs.

Otro ejemplo seria el del difunto Iwata, que cuenta la leyenda que a escasos dias de salir earthbound era injugable, y que en poco tiempo solucionó todos los bugs.

Hablo de gente que hacia maravillas con unos recursos muy escasos. El tema de hacer recolours de enemigos porque ocupaban menos espacio y asi poder aumentar la dificultad. Hacer que la consola solo cargue lo que se muestra en pantalla y no el mapa entero para ganar en tiempos de carga. O el empleo de fisicas revolucionario de half life.


Hoy por hoy tenemos estudios que hacen barbaridades técnicas (como las fisicas de la cuerda de TLOU2), pero claro, ellos usan maquinas muchisimo mas potentes de lo que usaron esta gente. ¿Creeis que serian los antiguos mejores que los actuales?
Ya hacían muchas barbaridades y aprovechaban incluso "fallos" de diseño del hardware en los tiempos de la NES y la GB
hoy en dia aun se siguen haciendo virguerias.

Si te interesa el tema, hace tiempo el antiguo director de traveller tales se abrio un canal en el que explica ese tipo de trucos que creaban en la epoca de megadrive para cpnseguir efectos teoricamente imposibles en un hardware:

https://youtu.be/nt-AxAqlrOo

Es fantastico su trabajo, no solo es interesante lo que cuenta sino que ademas sabe exponerlo bien para los que no sepan del tema.
Yo vi este video



Y es que cosas como estas solo lo hacen GENIOS. Que habran algunos aun rondando por la industria, pero me gustaria ver de que seria capaz por ejemplo este hombre
"Los programadores de ahora tenéis suerte. En mi época solo podías programar con unos y ceros. Y a veces no tenías ni ceros. Una vez tuve que programar una base de datos usando solamente unos".
Tampoco es comparable la complejidad de las arquitecturas actuales con las de años atrás. Prueba a leerte el manual de armv8a por ejemplo y hacer un pequeño bootloader y SO simple.
Se te olvida el gran John Carmack, cofundador de ID Software y el monstruo que se programo solito el motor grafico del DooM el cual nos dejo el culo torcido en la epoca.

ElSrStinson escribió:Otro ejemplo seria el del difunto Iwata, que cuenta la leyenda que a escasos dias de salir earthbound era injugable, y que en poco tiempo solucionó todos los bugs.


Aparte de que pillo el codido del Pokemon original y lo depuro el solo(el original era un caos ya que Satoshi era noob en programación) para poder sacar la version del Pokemon Stadium, todo un crack.

Salu2!! [oki]

Edit: Teneis el canal de Youtube de Marc Rollan " ElFuns", que es una enciclopedia del videojuego el chaval y se curra videos con las historias de desarrollos y tal, podeis echarle un ojo si interesa.
Sería inviable sacar un juego del calibre de TLOU 2 con la atención al detalle de Crash Bandicoot. ¿Por qué te crees que muchas desarrolladoras delegan en motores gráficos externos?
Estando en la era del reconocimiento visual,conducción autonoma. machine learning... Y comparas con optimizar un videojuego para que quepa en un CD [+risas]
amchacon escribió:Estando en la era del reconocimiento visual,conducción autonoma. machine learning... Y comparas con optimizar un videojuego para que quepa en un CD [+risas]


No es el hecho de caber en cds, ya que de hecho, al principio sobraba mucho espacio. Lo que me fascina es como vió el absurdo cuello de botella que habia (700mb de cd contra 1 mb de ram, creo que era), y buscó un modo de aprovechar esa memoria dividiendo el traspaso de datos en paquetitos, cosa que ahora es muy estandar, pero por aquella época parece que no tanto. El pensar en que vaya cargando solo lo que es visible en ese momento y no todo el mapa. El sutilmente eliminar una dimensión sin que te des cuenta (en el crash original pasa mucho, como los bandicootings, o niveles en 2,5D, que dan una falsa sensacion de profundidad)


Hablo de tener medios. Hoy en dia cualquiera puede acceder a un ordenador, y aprender a programar, pedir ayuda por internet... Esta gente en cambio no, y a base de puro ingenio sacaban las cosas adelante con semejantes resultados
@ElSrStinson

Hombre... Lo de cargar un juego por partes... Existe desde que el mundo es mundo....

Sorprendente era que en un ordenador de 8bits, y con 64k de RAM, estabas jugando un pantalla de un juego mientras en segundo plano se iba cargando la siguiente desde el casette.

Eso para mí en su día era magia negra no, lo siguiente.
eXpineTe escribió:@ElSrStinson

Hombre... Lo de cargar un juego por partes... Existe desde que el mundo es mundo....

Sorprendente era que en un ordenador de 8bits, y con 64k de RAM, estabas jugando un pantalla de un juego mientras en segundo plano se iba cargando la siguiente desde el casette.

Eso para mí en su día era magia negra no, lo siguiente.

El tema es que si el mapa eran 50mb y la ram de ps1 de 1 mb, tardaria 50 segundos en cargar el mapa. Así que decidió dividir el mapa en paquetitos de 0,5mb (creo que en el video dice 16kbs, pero para hacer una idea) para poder aprovechar el ancho de banda y cargar únicamente lo que es visible. Dicho de otro modo, no hablo de niveles divididos por fases y sus cargas, sino que si el mapa era de 500 metros y la pantalla te muestra 50, pues cargaba solo lo que se veia inmediatamente, y las zonas que dejabas atras las descargaba para dejar espacio a lo que venía despues. Dicho de otra forma, si pudieses alejar la camara, verias a crash, y un trozo de nivel alrededor, mientras que el resto está vacio, y se rellena a medida que crash está cerca.
(mensaje borrado)
ElSrStinson escribió:
amchacon escribió:Estando en la era del reconocimiento visual,conducción autonoma. machine learning... Y comparas con optimizar un videojuego para que quepa en un CD [+risas]


No es el hecho de caber en cds, ya que de hecho, al principio sobraba mucho espacio. Lo que me fascina es como vió el absurdo cuello de botella que habia (700mb de cd contra 1 mb de ram, creo que era), y buscó un modo de aprovechar esa memoria dividiendo el traspaso de datos en paquetitos, cosa que ahora es muy estandar, pero por aquella época parece que no tanto. El pensar en que vaya cargando solo lo que es visible en ese momento y no todo el mapa. El sutilmente eliminar una dimensión sin que te des cuenta (en el crash original pasa mucho, como los bandicootings, o niveles en 2,5D, que dan una falsa sensacion de profundidad)


Hablo de tener medios. Hoy en dia cualquiera puede acceder a un ordenador, y aprender a programar, pedir ayuda por internet... Esta gente en cambio no, y a base de puro ingenio sacaban las cosas adelante con semejantes resultados


Eso de que cualquiera puede programar.........
Cualquiera a lo mejor puede picar código y muchos les cuesta.
(mensaje borrado)
Pues harían lo mismo. Si no tienes necesidad de optimizar a X nivel, no lo haces. Y si tienes que hacerlo con un exclusivo de consola con un hardware cerrado, también lo hacen ahora.
Antes eran mucho mas normales los exclusivos, así que cuando programabas un juego lo hacías por un hardware único. Ahora el hardware no es único ni dentro de la misma marca (modelos slim, X, S...) Así que es imposible programar directamente los datos que entran en cada pata de un chip en concreto, tienes que pasar sí o sí por APIs y drivers.

Además está la piratería, muchas cosas de las que hacían los programadores antaño ahora no se pueden hacer porque implicarían puertas abiertas a la piratería y por lo tanto a la que alguien lo descubre... se cierra con una actualización del software.

Y esta es otra, ahora que hablamos de actualizaciones, no es que las llamadas al hardware sean "indirectas" y pasen por un driver, es que antaño el sistema operativo de las consolas era un papel de fumar, algo finísimo, que lo único que hacía era juntar software y hardware, y ahora los sistemas operativos de las consolas son monstruos que ocupan mas que muchos juegos.

Hay muchos programadores que hacen tantas o mas virguerías que los de antes, pero ahora todo es volumen, no calidad, así que de poco importa que tengas un juego con algo hecho casi con magia... A los 2 días algo con 3769 bugs lo tapará, porque importará mas sacar "grandes" productos inacabados que joyas de la creatividad.
seaman escribió:
ElSrStinson escribió:
amchacon escribió:Estando en la era del reconocimiento visual,conducción autonoma. machine learning... Y comparas con optimizar un videojuego para que quepa en un CD [+risas]


No es el hecho de caber en cds, ya que de hecho, al principio sobraba mucho espacio. Lo que me fascina es como vió el absurdo cuello de botella que habia (700mb de cd contra 1 mb de ram, creo que era), y buscó un modo de aprovechar esa memoria dividiendo el traspaso de datos en paquetitos, cosa que ahora es muy estandar, pero por aquella época parece que no tanto. El pensar en que vaya cargando solo lo que es visible en ese momento y no todo el mapa. El sutilmente eliminar una dimensión sin que te des cuenta (en el crash original pasa mucho, como los bandicootings, o niveles en 2,5D, que dan una falsa sensacion de profundidad)


Hablo de tener medios. Hoy en dia cualquiera puede acceder a un ordenador, y aprender a programar, pedir ayuda por internet... Esta gente en cambio no, y a base de puro ingenio sacaban las cosas adelante con semejantes resultados


Eso de que cualquiera puede programar.........
Cualquiera a lo mejor puede picar código y muchos les cuesta.


Cualquiera, mejor o peor, puede programar, y lo dice alguien que ha programado. No digo que sea facil (yo mismo soy un paquete), pero no es algo inalcanzable, y menos con la absurda cantidad de recursos que tienes, desde millones de cursos y tutoriales gratis, hasta placas para aprender a programar (como arduino)
ElSrStinson escribió:
seaman escribió:
ElSrStinson escribió:
No es el hecho de caber en cds, ya que de hecho, al principio sobraba mucho espacio. Lo que me fascina es como vió el absurdo cuello de botella que habia (700mb de cd contra 1 mb de ram, creo que era), y buscó un modo de aprovechar esa memoria dividiendo el traspaso de datos en paquetitos, cosa que ahora es muy estandar, pero por aquella época parece que no tanto. El pensar en que vaya cargando solo lo que es visible en ese momento y no todo el mapa. El sutilmente eliminar una dimensión sin que te des cuenta (en el crash original pasa mucho, como los bandicootings, o niveles en 2,5D, que dan una falsa sensacion de profundidad)


Hablo de tener medios. Hoy en dia cualquiera puede acceder a un ordenador, y aprender a programar, pedir ayuda por internet... Esta gente en cambio no, y a base de puro ingenio sacaban las cosas adelante con semejantes resultados


Eso de que cualquiera puede programar.........
Cualquiera a lo mejor puede picar código y muchos les cuesta.


Cualquiera, mejor o peor, puede programar, y lo dice alguien que ha programado. No digo que sea facil (yo mismo soy un paquete), pero no es algo inalcanzable, y menos con la absurda cantidad de recursos que tienes, desde millones de cursos y tutoriales gratis, hasta placas para aprender a programar (como arduino)

Lo que te está diciendo seaman es que "cualquiera no puede programar, puede picar código" y tú lo que estás nombrando también es picar código.

Programar como él se refiere no es sólo codificar, sino resolver problemas complejos. Cosas como se ha nombrado de Carmack en el hilo.

Recuerdo mi profesor de programación de primero que nos dijo "no tengo ni idea de ningún lenguaje de programación ni falta que me hace, yo os voy a enseñar a programar. A codificar ya aprenderéis solos"
Aporrea teclas hay millones, programadores como tal no hay tantos.

En los 80 y 90 para los medios que había, se hacían auténticos milagros.
Entro, suelto esto y os dejo disfrutarlo.
No se cuantas respuestas al hilo y todavía no se ha escrito la palabra clave del tema: COMPLEJIDAD. Cuanto más complejo es un desarrollo menos viable es, como decís, “hacer magia”. En los 90 un equipo de 20 personas te hacían un AAA pero ahora necesitas 2000.
Stylish escribió:No se cuantas respuestas al hilo y todavía no se ha escrito la palabra clave del tema: COMPLEJIDAD. Cuanto más complejo es un desarrollo menos viable es, como decís, “hacer magia”. En los 90 un equipo de 20 personas te hacían un AAA pero ahora necesitas 2000.


Esto.

Por otro lado tienes juegos como No Man's Sky que sin ser un triple A, hace cosas muy chulas desde el punto de vista técnico (pongo el ejemplo concreto porque el vídeo es largo, aunque lo recomiendo igualmente):
https://youtu.be/C9RyEiEzMiU?t=511
Soy programador de videojuegos y creo que estáis equivocados. A día de hoy se hacen virguerias ingeniosas de la misma manera que se hacían antes.

Por ejemplo: https://kotaku.com/horizon-zero-dawn-us ... 1794385026

Y ejemplos como ese hay miles. Por ejemplo (este es mío, que lo programe yo :D) en Hitman (2016) puedes tener decenas de muertos en un solo sitio y los guardias que los vean investigarán el lugar, los recogerán, los meterán en bolsas y se los llevarán. Debido a problemas de rendimiento, hacer que todos esos muertos sean visibles a la vez es imposible (se calcula independientemente por cada elemento visible para cada NPC vivo, y eso es muy costoso) pues por detrás hay un algoritmo "agrupando" los cuerpos cercanos y haciendo que solo uno de cada grupo sea visible a la vez, reduciendo el número de comprobaciones una barbaridad y permitiendo que el juego corra bien en una consola. Es solo un ejemplo sencillo, pero creo que vale para ilustrar lo que quiero decir.
Yo imagino que a dia de hoy la mayor limitacion es la potencia y no el espacio.

Lo tipico de que los juegos se cargan por zonas, que solo carga lo que se ve, que si trucos como lo que ha dicho Prospekt de acumular cosas como una sola para ahorrar en rendimiento.

Lo del espacio con los sprites recoloreados y demas, tambien tiene su merito de primeras, habia que echarle mucha imaginacion para saber como ahorrar espacio, como crear distintas cosas y demas.

Es como sin ir muy lejos que Super Mario Bros usa los arbustos como nubes y viceversa.

No se, supongo que dependera mucho del juego, si es el tipico juego que es una bestia grafica y que pide muchos recursos, pues seguramente si que puedan llegar y superar al nivel de los 90, pero si es un juego mas simple, pues seguramente lo tendran mas facil que un juego simple de aquella epoca.

Pero vaya, yo no soy programador ni tengo conocimientos tecnicos del tema, pero asumo que sera algo asi [+risas]
En general, ahora hay más y mejores informáticos porque hay más medios, lo que pasa que antes se podía destacar. Mirad a vuestro alrededor, las tecnologías que tenemos están ideadas por cientos o miles de personas. Ahora es muy difícil que se conozca a un "John Carmack" porque hay cientos de ellos en empresas.

Pero al igual que los hay iguales o mejores, también ha aumentado el número de peores ¬_¬, pero se debe a que el mundo tecnológico es infinitamente más amplio que hace 20, 30 o 60 años.

Los que suelen destacar hoy en día no son los "John Carmack" del sector. No conozco el mundo del desarrollo de videojuegos, pero imagino que entre las personas que están trabajando en el Unreal Engine (por poner un ejemplo) hay varios de ellos y ninguno tiene un canal en youtube o se les entrevista en revistas de videojuegos.

En cuanto al desarrollo en sí, yo creo que ahora existen muchas más capas que antes, y esa "magia" se encuentra en los motores gráficos y las API que se usan. Lo que no quita que en tiempo de diseño y programación, como dice @Prospekt, se hagan también auténticas maravillas.
Mira "demoscene 4kb intros" como por ejemplo esta del 2009.
Ahorrar memoria era un arte antes y lo sigue siendo ahora. Antes se hacía con lenguajes de bajo nivel y ahora no tanto... Pero cualquiera que quiera llevar al límite su juego, se las va a tener que ingeniar para hacerlo, tanto como hace 30 años. Saludetes!
Es un tema genial el que planteas. Esos sí que eran buenos programadores. Con la tecnología de ahora bueno... quizá no se vieran en la necesidad de hacer las artimañas que hacían antes. Pero al menos seguro que harían las cosas bien, para evitar usar recursos extremos para mover algo normal, algo que ahora ni se plantea. Ahora es: bah, que se compre un pc más potente que yo no me como más el coco
JAPosti escribió:Es un tema genial el que planteas. Esos sí que eran buenos programadores. Con la tecnología de ahora bueno... quizá no se vieran en la necesidad de hacer las artimañas que hacían antes. Pero al menos seguro que harían las cosas bien, para evitar usar recursos extremos para mover algo normal, algo que ahora ni se plantea. Ahora es: bah, que se compre un pc más potente que yo no me como más el coco

Me encanta cómo todo se resume en cuatro programadores vagos en los ojos de los que no saben.
También afecta mucho las herramientas de desarrollo. Cuanto más sencillas son para el humano peor son para la máquina. Engines como el Unreal o el Unity son monstruos. Si, facilitan mucho el trabajo, pero a costa de perder rendimiento con respecto a juegos con su engine propio y personalizado para determinada máquina.
largeroliker escribió:
JAPosti escribió:Es un tema genial el que planteas. Esos sí que eran buenos programadores. Con la tecnología de ahora bueno... quizá no se vieran en la necesidad de hacer las artimañas que hacían antes. Pero al menos seguro que harían las cosas bien, para evitar usar recursos extremos para mover algo normal, algo que ahora ni se plantea. Ahora es: bah, que se compre un pc más potente que yo no me como más el coco

Me encanta cómo todo se resume en cuatro programadores vagos en los ojos de los que no saben.


En mis tiempos los hombres eran hombres y los programadores se programaban sus propios drivers de impresora.
[poraki]

no me acuerdo de dónde es la frase, o si era así exactamente, pero siempre me ha hecho mucha gracia, lo de antes muy bien lo de ahora kk. XD [beer]
eXpineTe escribió:@ElSrStinson Sorprendente era que en un ordenador de 8bits, y con 64k de RAM, estabas jugando un pantalla de un juego mientras en segundo plano se iba cargando la siguiente desde el casette.


Por curiosidad, en que sistema se podia hacer eso???
Aunque ningun ordenador de 8bits era capaz de una multitarea real como la entendemos hoy... Gracias a las interrupciones cualquiera era capaz de hacer virguerias.

Este que digo en concreto era el juego dragons lair para el commodore 64. Según jugabas un nivel, continuaba cargando el siguiente desde cassette.

Muchas demos que se siguen haciendo en la actualidad hacen lo mismo desde diskettes, incluso derivando parte del proceso a la propia diskettes que, en este sistema, era un ordenador completo, con su CPU y su memoria. Gracias a esto, era casi más cara que el propio ordenador!
Los programadores de antes son los que han hecho los lenguajes de programación de ahora. Que podrian hacer ahora? Pues no se, enciende tu videoconsola y miralo. Gracias a que la programación ha avanzado se han conseguido dos cosas, una es que ahora sea mas facil programar y por lo tanto, sea mas facil encontrar programadores, la segunda es que los buenos programadores de hace 30 años, ahora pueden hacer cosas mucho mas complejas en menos tiempo.
A ver, que su trabajo sigue estando presente en muchos casos de hecho la gran mayoría seguirán vivitos y coleando, son 25 años o menos desde muchos juegos como Crash Bandicoot [carcajad]
Entonces un programador solía aprender desde muy joven pillando todos los libros y revistas que encontraba por auténtica vocación, echando montones de horas por pura afición. Hoy también hay muchos de esos aunque es un sector mucho más "poblado", pero siguen habiendo grandes programadores como los de la época. Dentro de 30 años seguro que sorprenden cosas que se hacen hoy [+risas]
Prospekt escribió:Soy programador de videojuegos y creo que estáis equivocados. A día de hoy se hacen virguerias ingeniosas de la misma manera que se hacían antes.

Por ejemplo: https://kotaku.com/horizon-zero-dawn-us ... 1794385026

Y ejemplos como ese hay miles. Por ejemplo (este es mío, que lo programe yo :D) en Hitman (2016) puedes tener decenas de muertos en un solo sitio y los guardias que los vean investigarán el lugar, los recogerán, los meterán en bolsas y se los llevarán. Debido a problemas de rendimiento, hacer que todos esos muertos sean visibles a la vez es imposible (se calcula independientemente por cada elemento visible para cada NPC vivo, y eso es muy costoso) pues por detrás hay un algoritmo "agrupando" los cuerpos cercanos y haciendo que solo uno de cada grupo sea visible a la vez, reduciendo el número de comprobaciones una barbaridad y permitiendo que el juego corra bien en una consola. Es solo un ejemplo sencillo, pero creo que vale para ilustrar lo que quiero decir.


Hay trucos ahora y siempre los habrá, eso es de cajón, no sólo en la programación de videojuegos.

Pero las virguerías que se hacían antes no se pueden hacer hoy, porque hoy día el juego tiene que correr por encima del SO, no corre directamente en "metal" como antes.

Creo que el último ejemplo de juego que va directamente en metal es el Super Smash Bros de 3DS. Si estás en una New no, pero si lo metes en una 3DS normal, el juego hace la consola rebootar en un modo "especial" sin SO, y el juego asumía el control de todas las funciones necesarias (wifi, lista de amigos etc.).
@Patchanka, los juegos, especialmente los triple A, se programan en C++ (incluso algunas partes en ensamblador), por lo que casi todos tocan cosas a muy bajo nivel (incluso los programadores de gameplay, no sólo los de engine o render). Además, trabajar a bajo nivel no significa necesariamente que vayas a tener que hacer más virguerias de las que se están hablando en este hilo.

Cosas como deferred rendering, implementar lenguajes de scripting propios para los diseñadores (con debugger!), utilizar técnicas como árboles de comportamiento o planificadores (y también crear un debugger para ellos), steering behaviors, motion matching... Todo eso son técnicas muy avanzadas que en mi opinión entran muy bien en la definición de "virguerias técnica" que se hacen hoy y que antes no se podían ni imaginar, y que da bastante igual si programas a más bajo o a más alto nivel, que implementarlas va a ser igual de complejo.

Otro ejemplo es The Last of Us 2. Técnicamente alucinante a cada paso que das.
Prospekt escribió:@Patchanka, los juegos, especialmente los triple A, se programan en C++ (incluso algunas partes en ensamblador), por lo que casi todos tocan cosas a muy bajo nivel (incluso los programadores de gameplay, no sólo los de engine o render). Además, trabajar a bajo nivel no significa necesariamente que vayas a tener que hacer más virguerias de las que se están hablando en este hilo.

Cosas como deferred rendering, implementar lenguajes de scripting propios para los diseñadores (con debugger!), utilizar técnicas como árboles de comportamiento o planificadores (y también crear un debugger para ellos), steering behaviors, motion matching... Todo eso son técnicas muy avanzadas que en mi opinión entran muy bien en la definición de "virguerias técnica" que se hacen hoy y que antes no se podían ni imaginar, y que da bastante igual si programas a más bajo o a más alto nivel, que implementarlas va a ser igual de complejo.


Yo creo que estamos usando la palabra "virguería" más en el sentido de "no seguir las reglas" que otra cosa. Antes, tú podías hacer casi todo lo que la potencia de tu máquina te permitiera, si estuvieras dispuesto a no usar los SDKs de los dueños de la plataforma y escribirlo todo desde cero. Hoy día, si necesitas usar (por poner un ejemplo chorra) los cuatro núcleos de la CPU de la máquina, pero el SO sólo te libera tres, pues te jodes (a no ser que pidas permisos a los dueños de la plataforma, pero a no ser que seas Rockstar y estés haciendo GTA VI en exclusiva, creo que será un poco difícil que te lo permitan...).

Todo eso que dices son cosas que, más que trucos, son necesidades para los tipos de juegos que tenemos hoy día. Si se pudieran hacer los juegos de hoy día en el Amiga, seguro que todo eso ya existiría entonces.
Lo dices como si los devs de los 90 hubieran muerto, cuando la mayoría siguen en activo casi con total seguridad.
39 respuestas
Archivado
Volver a Miscelánea