Por qué los juegos antiguos usaban sus propios motores

carra

Jaja estaba contestando en el hilo de Argentum, y en lo que he tardado en escribir mi tocho me han cerrado el hilo. Así que escribiré por aquí lo que iba a decir.

Había una pequeña discusión en ese hilo del por qué los programadores de juegos antiguos usaban sus propios motores. Algunos decían que es porque no había disponibles motores como los de ahora, y otros que simplemente es porque antes la gente sabía programar mucho más que ahora.

Llevo haciendo juegos y programas de audio/video más de 20 años (desde la época del 286 en MS-DOS), así que me siento en la obligación de contestar.

[WARNING]: Post bastante largo

Lo primero que hay que entender es cómo eran esos juegos antiguos, y cómo eran los entornos en los que se programaban y las máquinas donde se ejecutaban. Por supuesto, esto depende de hace cuántos años hablemos. Hasta los primeros Windows todavía eran muy comunes los juegos en modo MS-DOS, ya que esto permitía al programador acceder directamente al hardware y usar ensamblador.

Se necesitaba hacer todo esto porque en aquellas máquinas el rendimiento era mucho más limitado. Aunque por otra parte el programa se simplificaba ya que mientras MS-DOS te da total libertad para organizar tu programa, Windows obliga a crear ventanas, usar librerías (GDI, DirectX...) y basar el programa en mensajes. Esto nos obliga a escribir mucho código adicional, y además la estructura del programa será bastante más complicada en comparación.

Por otra parte no usar Windows también tenía desventajas. Al acceder directamente al hardware lo tienes que hacer todo tú mismo. Pero además, como no dispones de drivers ni librerías estandar, lo que estés haciendo no tiene por qué funcionar en todos los PCs. Dependiendo de la tarjeta de video y de audio las cosas se tienen que hacer de forma diferente. Es por eso que en los menús de juegos de MS-DOS lo primero que sueles necesitar hacer es elegir qué modo de video y qué tarjeta de sonido vas a usar.

Ya os podeis imaginar que al tener que hacer las cosas a tan bajo nivel uno mismo (video, audio, joysticks, teclado, timing...) era normal que los programadores de juegos tuvieran bastante conocimiento de sus máquinas. También era habitual encontrar en revistas de la época, como Programación Actual, artículos y CDs que te explicaban cómo programarte tú mismo cosas como cargadores de imágenes, pequeños renderers 2D y 3D, secuenciadores de sonido para crear música básica tipo tracker, etc.

Además, tened en cuenta que los juegos de esa época como es lógico eran mucho, mucho menos complejos que los de ahora. Eso hacía que en muchos casos aún fuera posible desarrollar un juego completo, con calidad comercial, con sólo 1 o 2 personas. Como ellos mismos lo hacían todo, y normalmente podían programarse un pequeño motor en no demasiado tiempo (o incluso ya lo tenían de proyectos anteriores), no había tanta necesidad de motores.

Una vez que fue haciéndose dominante el desarrollo en Windows (más complejo y más estandarizado), y que fue aumentando la complejidad de los juegos especialmente por el 3D, comenzaron a surgir motores ya que el costo de desarrollar un motor de este tipo empezaba a ser prohibitivo. Sin embargo aún tardarían unos años en extenderse. El primer Unreal Engine, por ejemplo, no se lanzó hasta el 98.

Bueno lo dejo, ahí tenéis mi granito de arena :wink:

31
Encofrado

Me lo he leído enterito, muy muy interesante la verdad. Lo que no sabía era eso que comentas de que, cuando ibas a arrancar un juego de MS-DOS te pedía elegir que configuración de vídeo y/o sonido, fuese debido a que los programadores lo hicieron pensando en X en un principio, pero luego tuviesen que ser capaces de hacerlo correr en Y.

En cuanto a que antes se programaba mucho más que ahora, aunque a alguien no le guste admitirlo, es así. Volviendo al punto que he comentado antes, antiguamente no existían motores que te permitiesen exportar o tener una configuración para TODO un ecosistema (grupo PC's, grupo smartphones, etc.), porque seguramente en la época no existía la estandarización que tenemos ahora (p. ej. frameworks, webs generadoras de código, etc.), por lo que antes las cosas también tardarían mucho más en salir al público.

Buen hilo carra, me ha hecho recordar la época del 486 (el primero que yo tuve), los cajones de disquetes (PC Futbol madre mía :joy: ), y el introducir los comandos en la consola para arrancar según que juegos :thumbsup:

2 1 respuesta
kidandcat

Genial el hilo! lo he buscado pero no he conseguido encontrar un post donde Juan Linietsky explicaba que el origen de Godot viene de cuando el programaba videojuegos y se lo hacia él mismo todo, conforme pasaba el tiempo tenía cada vez más utilidades que reusaba, y así terminó con lo que ahora es Godot (obviamente después de publicarlo la comunidad ha contribuido un montón)

1
B

#1 a mayor complejidad en el hardware mayor complejidad en el software, la vía para ser competitivo es la especialización (desarrolladoras de engines).

Obviando los grandes estudios... a día de hoy, usar motores de terceros es el recurso para ser competitivo en relación a calidad/coste.

1 respuesta
carra

#2 Sí, así era. En el tema gráfico la cosa estaba un poco más estandarizado: Por ejemplo las tarjetas VGA, eran muy muy comunes cuando empecé, y además normalmente eran retrocompatibles con CGA y EGA. Cuando aparecieron las SuperVGA, también eran retrocompatibles con VGA. Sin embargo, no todos los monitores tenían disponibles los mismos modos de video.

El tema del audio era bastante más peliagudo. Había gente que sólo tenía el altavoz del PC. Las tarjetas gráficas no tenían nada que ver en funcionamiento una con otra: la forma de funcionar de una Sound Blaster no tenía nada que ver con la de una AdLib. Y por razones de memoria y CPU, era imposible tener una canción pregrabada como ahora en WAV o MP3, con lo cual había que programar cada una de estas tarjetas para que hiciera la secuenciación y configurara los instrumentos de tal manera que sonara nuestra canción.

carra

#4 Jeje, veo que no soy el único que conoce épocas pretéritas :grin:. Bienvenido!

Sí, de hecho en su momento también tuve un Atari ST. Aunque en él no llegué a programar más que en Basic. En ordenadores antiguos, de cara a ejecutar un juego, o bien no había sistema operativo o bien lo que había era un soporte muy básico para llamar a funciones hardware, lo que viene siendo una BIOS. De hecho esto también es muy similar a cómo se programaban las consolas clásicas (que además en muchos casos usaban como CPU el Z80 o derivados, como por ejemplo Game Boy y Master System).

1 1 respuesta
B

#6 en el caso del CP/M era modular para portabilizar.

  • CCP (shell, línea de comandos)
  • BDOS (el núcleo del sistema operativo)
  • BIOS (interfaz adaptada al hardware del equipo)

Para ganar RAM se eliminaba el CCP y se usaba una versión recortada del BDOS.

1 1 respuesta
carra

#7 Es interesante, la verdad es que no conozco mucho del funcionamiento de CP/M. Pero he visto videos de 8BitGuy en los que explica técnicas parecidas para ganar RAM en el Commodore 64.

A los que solo conozcais máquinas recientes igual os suena raro, pero en muchos ordenadores y consolas de los 80 y alguno de los 90, la memoria RAM no se medía en gigas. Ni siquiera en megas. Eran kilobytes, y no muchos. El Commodore 64, por ejemplo, se llamaba así porque su RAM era de 64KB. Consolas como la NES tenían bastante menos aún.

3
B

Muy buen hilo, no quiero desviarlo a "es mejor usar un motor comercial o no" o "son los videojuegos arte", pero el diseño/desarrollo de videojuegos es una disciplina principalmente artística, y la técnica empleada define en gran medida el proceso de creación y por ende el resultado final. Qué quiere decir esto, que usar Unity o Unreal no es trivial, es una decisión que va a definir el proceso y el resultado final del juego en gran medida.

Evidentemente, se puede recrear cualquier juego en Unity, Unreal, o el motor que quieras, pero no es lo mismo recrear que crear desde cero, ya que en el proceso de creación vas a tener que tomar decisiones de diseño que se verán influenciadas decisivamente por la tecnología que estés usando.

Que sea más rápido, que haya más comunidad para resolver dudas técnicas, etc., no son los únicos factores a tener en cuenta a la hora de utilizar un motor, y, para enlazar todo esto un poco con el tema del hilo, es una pena que por la complejidad creciente del hardware y de los SO se hayan ido perdiendo esas formas más directas de trabajar con el hardware, por poner un ejemplo sencillo que a día de hoy se replica con shaders y con técnicas un poco engorrosas, está el palette swapping o cycling.

1 respuesta
B

Por cierto, muy relacionado con esto:

https://jonathan-cauldwell.itch.io/multi-platform-arcade-game-designer
Multi-Platform Arcade Game Designer
Simply put, the most powerful user-friendly tool there is for creating games for 8-bit computers. Supported formats include the ZX Spectrum, MSX, Amstrad CPC, BBC Model B, Dragon 32/64, Acorn Atom, Enterprise and VZ200 with more on the way.

1 1 respuesta
carra

#9 Buena aportación sodAp, has tocado algunos puntos de los que no he hablado.

Y relacionado con eso también está el hecho de que un motor propio puede llegar a ser mucho más flexible. En Unity por ejemplo, hacer un juego basado en física (por ejemplo Angry Birds) es muy sencillo, se agregan componentes de sólidos rígidos, se ajusta la gravedad y hecho. Pero si quieres hacer un juego con una física "poco realista" porque quieres jugabilidad tipo arcade, tienes que andar con muchos apaños y tal vez no quede como tú lo quieres.

El palette swapping es una de las cosas que dan por saco a quien trate de programar un emulador. Y también el acceso directo a la memoria de video, que en los PCs actuales no existe y requiere crear una textura que se actualiza cada frame.

#10 Muy bueno, no lo conocía!

El que me impactó en su día fue este creador de juegos para la Game Boy original:

1 1 respuesta
B
#11carra:

Pero si quieres hacer un juego con una física "poco realista" porque quieres jugabilidad tipo arcade, tienes que andar con muchos apaños y tal vez no quede como tú lo quieres.

Esto es algo que mucha gente no entiende, cuando haces juegos 2D arcade, es muy fácil que Unity se convierta en tu enemigo y el desarrollo en una lucha contra el motor.

1 respuesta
B

El desarrollo y mantenimiento de un engine multiplataforma necesita inversiones de tiempo/coste elevadas.

HeXaN

A día en un juego AAA se pica código como cabrones, eh. Que no tengas que pelearte constantemente a bajo nivel no lo hace ni mejor ni peor.

kesada7

#12 No tiene por que si sabes lo que quieres y lo que haces, es decir, si quieres un juego de plataformas 2D tipo mario pues no utilices las físicas de unity y create tus propias clases de física. Aún así Unity te sigue aportanto cosas como programar en un lenguaje de alto nivel, te aporta exportar en multiplataforma, te aporta integrar miles de apis y plugins de terceros de forma sencilla como para hacer por ejemplo monitización o Ads, estádisticas, las herramientas de texturas, animaciones integradas... Al finla en este ejemplo lo único que no quieres utilizar es el motor de físicas 2D de unity porque es cierto que a la larga te puedes estar más peleando para arreglar cosas que hacerlas tu de 0.

1 respuesta
B

#15 no niego nada de esto, el problema es que no todas las características que mencionas son igual de importantes ni son exclusivas de Unity, que al final muchas veces parece que la mejor manera o la única manera viable o incluso de hacer juegos comerciales sea usando Unity, cuando hay infinidad de ejemplos de juegos indie de éxito que utilizan otros motores o incluso un motor propio.

No quiero convertir esto en el debate sobre si Unity si o Unity no, yo no estoy en contra de que la gente lo use, pero hay que tener en cuenta que a lo mejor hay proyectos que no requieren todas esas features que citas y pueden compensarlas con otras ventajas que sean más aplicables al proyecto en cuestión.

#15kesada7:

Al finla en este ejemplo lo único que no quieres utilizar es el motor de físicas 2D de unity.

No, de todo lo que has dicho quizá no quiera utilizar absolutamente nada porque no necesite integrar miles de apis ni plugins, ni ads, ni necesite o quiera utilizar las herramientas de animación y texturas porque tenga formas más simples y directas de trabajar a mi manera, quizá solo quiera hacer un juego para PC, etc, hasta llegar al punto en que no tenga absolutamente ningún sentido pelearme con Unity para hacer unas físicas arcade.

En otras palabras, a veces Unity no es la herramienta más adecuada para la tarea que se tiene entre manos, de la misma manera que no todo el mundo necesita el mismo coche o la misma televisión o el mismo mueble. Hay gente a la que le va bien comprarse una estantería de Ikea pero hay gente que la necesita a medida por las razones que sean. Si yo quiero una silla normal para el comedor es mejor que me compre una silla normal en lugar de comprarme una silla gamer que tiene muchas más características y "es más cómoda", excepto por la simplicidad de una silla normal que puedo meter debajo de la mesa.

2 respuestas
Wasd

Las cosas ahora son mucho más complejas, y por eso hay muchas más abstracciones. Si todo el conocimiento de hace 20 años tuviese que sumarse al conocimiento requerido hoy día para hacer un videojuego, los cerebros explotarían o la gente se vería capaz de hacer un juego indie a los 60 años.

Todo se resume en: subirse a hombros de gigantes para ver más lejos.

#16 creo que tu ejemplo no es del todo acertado.

no todo el mundo necesita el mismo coche

correcto. Pero sea cual sea el coche que te compres tendrá ruedas, motor, volante, asientos... etc. Hacerte tu el motor de juegos es hacerte tú todas esas piezas. Creo que la clave está en poder salirte de las reglas del motor cuando lo necesites, y por supuesto eso implica un conocimiento superior, pero de ahí a programarte tu la, yo que sé, importación de modelos 3D, o exportación a android y iOS... hay un trecho. Ahora hay tantos añadidos al proceso de desarrollo de un videojuego que no veo rentabilidad ninguna en hacerte tú el motor. Es como decirles a los de marketing que por qué utilizan las redes sociales, SEO y SEM para publicitar el juego pudiendo salir con un megáfono a la calle.

Eso no significa que hacerse uno mismo el motor esté mal, pero probablemente no te permitirá ser competitivo a medio/largo plazo si tu objetivo es rentabilizar y tirar el producto para adelante. Otra cosa es hacerlo por amor al arte, que me parece perfecto.

1 respuesta
B

#17 es que ahí estás extendiendo la analogía mucho más de lo que puede dar de sí. Subirse a hombros de gigantes significa principalmente aprender de lo que ya se ha hecho, no significa que todos tengamos que usar las mismas herramientas exactamente o los mismos productos tal como nos los venden en la tienda.

#17Wasd:

Es como decirles a los de marketing que por qué utilizan las redes sociales, SEO y SEM para publicitar el juego pudiendo salir con un megáfono a la calle.

Esto si que me parece una comparación totalmente desacertada porque para empezar ni siquiera son incompatibles, y yo no estoy diciendo que no se use tecnología o métodos actuales o que no se use la distribución digital ni nada parecido, estoy diciendo que Unity no es la mejor opción para el 100% de los proyectos del planeta de aquí al fin de la historia, que es lo que parece que defiende mucha gente. Habrá mucha gente a la que le venga bien, a otra no, y ya he dicho que el usar Unity no es solo una cuestión práctica, influye a nivel creativo.

#17Wasd:

Eso no significa que hacerse uno mismo el motor esté mal, pero probablemente no te permitirá ser competitivo a medio/largo plazo si tu objetivo es rentabilizar y tirar el producto para adelante. Otra cosa es hacerlo por amor al arte, que me parece perfecto.

El tema es que luego hay indies que usan su propio motor y les va perfectamente. Hay juegos como factorio, o cualquiera de Positech, Zacthronics, Jonathan Blow, y muchos más. Spelunky, Super Meat Boy, Papers Please, Braid, Dead Cells, Rogue Legacy, y un largo etc no se hicieron con Unity.

kesada7

#16

#16sodAp:

No quiero convertir esto en el debate sobre si Unity si o Unity

No hay problema en debatir mientras sea de forma sana :smiley: Al final este hilo es para hablar un poco de esto sino ya estaría muerto xD.

Vale cuando dije Unity en realidad me refería al debate de motor propio vs motor de terceros por lo que realmente quería decir es Unity -> Motor de terceros, no tiene por que ser unity en sí, sino unreal, godot, construct, game maker, etc aunque a nivel de industria al final solo se usan 2 y sabemos cuales son. (Que sí que hay juegos indies de exito con otros motores pero si buscas trabajo de game dev en un motor de terceros de cuales son?)

#16sodAp:

No, de todo lo que has dicho quizá no quiera utilizar absolutamente nada porque no necesite integrar miles de apis ni plugins, ni ads

Vale en ese caso no, al final obviamente la respuesta es: depende de tus necesidades. Pero en la mayoría de los casos un proyecto va a tener x necesidades que o utilizar un solución que ya existe o te la tienes que hacer tú y al final todo se resume en tiempo y dinero.

De hecho cada vez hay más empresas que están migrando sus juegos de sus motores propios a motores de terceros como Unity/Unreal porque mantener un motor propio es suuuuuper costoso y tienes que tener un equipo de developers solo para mantenerlo actualizado y para que si puedes por un precio muchísimo más barato usar un motor ya hecho que está en constante actualización.

Al final es especialización, modular, y no tener que reinventar la rueda en programación sino ir mejorando esa rueda ya hecha.

carra

Un apunte: Aunque parezca que las 2 opciones que hay son usar un motor o hacerlo todo tú, hay algunas opciones intermedias. Puedes no usar motor, pero usar librerías para ciertas partes en concreto. Por ejemplo yo puedo usar una librería física como Box2D, una librería que me maneje la interfaz gráfica como Qt, y del resto encargarme yo. A mi me quedaría entonces la tarea de organizar la estructura básica del programa, que debe encargarse de hacer de "pegamento" entre todos los componentes.

Cuando usamos un motor, en cambio, ese motor tiende a ocuparse de todo por nosotros pero a cambio nos obliga a adaptarnos a él y nos "encorseta" en todos los aspectos del desarrollo. Tienes que usar SU manera de definir las propiedades físicas. SU lenguaje de script. SU esquema de eventos y respuestas. Esto quizá parezca que no es para tanto, pero si a medias de desarrollar vuestro juego en Unity queréis cambiaros a Unreal Engine, seguramente vais a tener que modificar bastantes cosas.

De manera general, hacer un juego con un motor viene siendo como desarrollar software usando un framework.

2 2 respuestas
B

La ventaja de usar un motor de terceros, como pueda ser Godot, gamemaster, unity, unreal o el que sea. Es que personas que no podrían de otra manera hacer un juego, lo hagan. Esa es una de ellas.

Otro tema es el ahorrar tiempos y costes. A mayor duración del proyecto, más coste del producto y tus posibles clientes puede que esperen demasiado y se olviden por el juego. o salga otro que lo eclipse.

Si eres una empresa grande con capital para trabajar en tu propio motor y necesidades. Pues si, es la mejor manera de sacarle el 100% a tu juego.

1 respuesta
EnderFX

#20 Siendo el símil válido, creo que la diferencia es abismal entre uno u otro.

Sin utilizar un framework (Express en Node, Djando en Python, Symfony en PHP, etc.) yo puedo montarme algo básico y que tire bastante bien: pongamos que tiro en NodeJS y uso la librería http-server, me monto un mongodb o postgres con sequelize para ORM, y 4 cosas más. Si bien hay muchas cosas que gestionar a mano, yo te digo que con 5-6 librerías te hago una aplicación web sencillita con su oauth y su API RESTful.

Si intentara hacer ya no un equivalente a Unity/UDK, pero algo con un resultado gráfico decente, a no ser que vayas a hacer 2D (y creo que un proyecto no muy grande) es bastante difícil que consigas algo parecido.

Lo digo porque a un nivel alto/medio es bastante sencillo entender cómo funciona una arquitectura cliente-servidor como es HTTP y el desarrollo web. Las capas de abstracción y de complejidad de motores como Unity son tremendas. Desde la gestión de los polígonos, texturas, materiales, shaders, iluminación y todas las instrucciones que hay que generar para la GPU y CPU, el scripting, la edición del audio y sfx, sistemas de partículas, UI, animaciones con sus capas y blend trees...

En las consolas antiguas, no solo por la ausencia del 3D (ya que en PS2/PS3 entiendo que ya los motores se impondrían, si no antes, al menos reutilización masiva de la parte gráfica) si no por el hardware, era humanamente posible hacer un juego con 3-4 personas con un compilador y las herramientas necesarias. Por ejemplo, intentar entender cómo funciona la GameBoy con su pseudo-Z80 es bastante sencillo, desde entender la mayoría de instrucciones, el mapeado en memoria de todos los componentes y cómo se dibujan los sprites en la pantalla a partir de los bytes que hay en memoria.

Con menos de 20 o 25 instrucciones sacabas el estado de todos los botones de la consola en ensamblador, a registros o memoria. Tírate ahora con instrucciones de 64 bits a leer qué botones estarán pulsados no ya en un pc, si no en una PS3/PS4/similar.

Además de que no renta: la mayoría de ese código no es que sea boilerplate, es fundamental, pero a nivel de negocio, en este caso, contenido de juego, no aporta nada. Quieres tener los mejores gráficos por el menor precio, pero para poder mejorar un UE5/Unity gráficamente y que sea sencillo de usar vas a tener que invertir MILLONES, y aunque tus devs fueran la hostia, ¿cuánto mejor se va a ver que UE5, si pudieras cuantificar? ¿5-10%?

LOL! TOO LONG; DIDN'T READ
Vamos, para mí es un tema de complejidad. No es lo mismo pintar el sprite de Wario que hacer ray-tracing con millones de triangulos.

Vamos, lo que dice #1. Al final la magnitud de un motor ahora mismo es... bastante mayor, en varios órdenes, que la de un framework web, por ejemplo.

#21 y que encontrar programadores de C# para Unity y de C++ para UE4/5 será mucho más fácil que encontrarlos que piquen para QtreEngine en Haskell

1 2 respuestas
carra
#22EnderFX:

Lo digo porque a un nivel alto/medio es bastante sencillo entender cómo funciona una arquitectura cliente-servidor como es HTTP y el desarrollo web. Las capas de abstracción y de complejidad de motores como Unity son tremendas. Desde la gestión de los polígonos, texturas, materiales, shaders, iluminación y todas las instrucciones que hay que generar para la GPU y CPU, el scripting, la edición del audio y sfx, sistemas de partículas, UI, animaciones con sus capas y blend trees...

Como tú bien dices, de la complejidad depende todo. Para hacer un juego como GTA5, puedes necesitar usar el 95% de las capacidades que ofrece Unreal. Para hacer Animal Crossing, igual más de la mitad de las características ni las vas a tocar. Sin embargo, el motor tiene que estar preparado siempre para el caso más complicado posible.

Lo que quiero decir, es que mucha de esa abstracción a menudo es innecesaria y te la tienes que comer para usar ese motor, sólo para a otros les sirva. En GTA5, a lo mejor necesito shaders dinámicos y generar modelos 3D a partir de nubes de puntos. A quien crea un juego indie 3D, le gustaría poder quitar de enmedio todo lo que le estorba y que lo poco que él necesita hacer se haga de manera mucho más sencilla y eficiente.

Pero claro, esto no es nuevo. Eso va a ocurrir siempre, y de hecho se va haciendo peor con cada generación. Es el precio que tenemos que pagar porque se puedan hacer cosas más complejas.

1 1 respuesta
EnderFX

#23 El ejemplo perfecto lo tienes en que hay auténticas joyas hechas con Game Maker, que es un motor digamos muy sencillo - dentro de todo lo que tiene - y 2D.

1
Flashk

Todo se reduce a algo muy básico: no reinventar la rueda.

Los motores gráficos son a la programación de videojuegos lo que los frameworks como Spring al desarrollo de (por ejemplo) servicios, tal y como como comenta #20, y a a un nivel de complejidad superior, como indica #22. Básicamente, como desarrollador, no deberías tener que preocuparte por temas transversales, sino por lo que realmente estás haciendo.

Los frameworks (y los motores gráficos) no surgen porque si. Surgen porque una o varias personas se acaban dando cuenta de que cada vez que hacen un desarrollo nuevo, tienen que volver a crear de nuevo cosas que ya han hecho, o incluso copiando y pegándolas de anteriores proyectos; y por si fuera poco, según aparecen nuevas tecnologías, drivers y demás, también tienen que incluirlas.

Entonces, es cuando a alguien se le ocurre la genial idea de simplificar todo en una serie de librerías y herramientas de desarrollo sobre las mismas para que todo sea más reutilizable y sencillo. Al final es algo que a la larga compensa, si pongamos, inventando un número, cada vez que hago un nuevo juego tengo que invertir 1000h en preparar su motor gráfico, y hago 5 juegos, he tenido que dedicar 5000h al final, a lo que hay que sumarle las horas de desarrollo del propio juego en si. Si decido invertir 2000h en montar un buen motor gráfico reutilizable, esas 1000h en cada desarrollo me las ahorro. Al cabo del tercer juego ya tengo amortizadas las horas. Y si el motor es bueno, incluso puedo venderlo a otra gente que lo necesite.

Por lo tanto, los juegos antiguos usaban sus propios motores, por dos razones:

  • En primer lugar, porque no había motores gráficos como los de ahora.
  • En segundo lugar porque como han dicho en otros post, las tecnologías avanzan, cada vez hay mayor complejidad. Posiblemente al principio, en unas pocas decenas de horas los programadores de antaño podían montarse un motor gráfico personal que les sirviera para sus propósitos; pero con el paso del tiempo, esas decenas pasarían a ser centares o incluso miles de horas.

Hace poco, como un mes o así, vi un vídeo de Peter Molyneux, en el que hablaba de los juegos que había hecho. Entre otras cosas, comentó que Black & White tardó tanto en desarrollarse entre otras razones, porque tuvieron que hacerse su propio motor gráfico, corregir bugs sobre dicho motor e ir ajustándolo; en definitiva, reconoció que hoy en día resultaría mucho más fácil hacerlo porque no habrían perdido tanto tiempo en ello.

3
P

Coincido mas con sodap en su enfoque

Pero la mayoria de la gente que aboga por Unity etc.....es porque solo tienen en mente el "tener el juego en pim pam pum" me refiero a hacerlo rapido y sin comerse mucho el tarro......

A algunos programadores, nos gusta el "reto" de hacer las cosas "desde 0" porque esa es la razon.-.... el reto de construir algo por ti mismo, peleandote y exprimiendote la imaginacion para lograr un resultado de 10 en el que tu y tu mente han producido esa genialidad....... es como la gente que va al Ikea o al bazar y compra una tumbona por 20 euros..... mientras que lo otro.....es ese video de ese tio que hace un armazon con lapices de colores, le mete resina, lo pule y al final es un pedazo de tumbona de diseño hecha por el mismo con la diferencia que uno ha ido a lo facil y menos trabajoso....y el otro se lo ha currado a base de bien con sus manitas y su lijadora......

y tambien que la mayoria de la gente es comoda y no tiene ganas de aprender ni un lenguaje ni nada...... quieren algo rapido y calidad profesional pero sin estrujarse la cebolleta lo mas minimo (y ahi es donde interviene la tienda de assets y el tio diciendo "mira mi falcon 3.0 sobrevolando la selva amazonica con todos sus putos arboles incluidas las hojas y las raices (que no se ven porque estan debajo del plano cubierto con tierra vegetal simulada.......16 millones de mosquitos tiene tambien......cada mosquito 20.000 poligonos...... pero como tengo un Ryzen de 16 procesos y 256 Gb de ram fijate que bien lo mueve eh?......vete mirando mientras yo llamo a Nvidia a ver si ha salido la nueva grafica GTX de 32 Gb de Ram DDR10 Crossfire....))

yo por ejemplo...... si quisiese podria meterme con Unity o Unreal....... pero estoy haciendo mi juego en 2D con C++ y echandole imaginacion al tema porque lo encuentro mas entretenido

1 respuesta
B

#26 cuantos juegos has acabado "con c++ echándole imaginación al tema"?

Se puede ver alguno?

2 respuestas
carra

#27 Ufff el tema de los proyectos inacabados... jajaja
Recordemos nuestro lema "taberna: 200% de devlogs abandonados" :rofl::rofl:

1
HeXaN

#27 Tampoco hace falta que metas el dedo en la llaga.

1 respuesta
Jastro

las herramientas estan para usarlas.

Si a alguien no le gusta usar una vitroceramica para cocinar y prefiere encender el fuego con piedras y palos de madera. Su manera de hacer las cosas es igual de valida que quien usa la vitro. Al final la comida se cocina igual.

Burlarse de gente porque hace las cosas de una manera de otra, es de ser de imbecil.

4 1 respuesta

Usuarios habituales