Por qué los juegos antiguos usaban sus propios motores

HeXaN

#30 Es una cuenta trol así que tampoco le haría mucho caso.

1
B

#29 hará 5 años o más que habla de un juego 2D programado en c++. Era algo de un tablero con hexágonos, batalla interestelar por turnos creo.

Supongo que el motor de sprites lo tendrá encaminado, sólo curiosidad.

kesada7

1 1 respuesta
kidandcat

#33 aro aro

A ver quien es el machote que se hace su motor gráfico, yo le doy 30 años y no saca ni la mitad de esto: https://youtu.be/qC5KtatMcUw?t=439

2 respuestas
carra

#34 Eso está claro! De ahí lo que decíamos antes de la complejidad. Por eso tenemos que comparar peras con peras y manzanas con manzanas. Un juego AAA o un motor de juegos mainstream tienen detrás el trabajo de cientos de personas durante varios años.

Pero aún así tienes a algunos desarrolladores amateur o indie que con solo OpenGL y C++ te montan cosas como esta:

¿Que no es ni la mitad de espectacular? Evidentemente. Pero está muy por encima del típico juego indie. Y el mérito que tiene es que ese nivel está más allá de lo que solemos pensar que se puede hacer sin usar motores.

1 1 respuesta
r2d2rigo

#34 hoy en dia un equipo indie puede hacer perfectamente un juego con una calidad visual espectacular siempre y cuando tenga un art style muy definido y se atenga a rajatabla a hacer el motor minimo para realizar ese juego, el scope creep siempre esta a la vuelta de la esquina y puede tirarlo todo por la borda. Mira https://gist.github.com/raysan5/909dc6cf33ed40223eb0dfe625c0de74#small-size-studios-indie-studios y https://gist.github.com/raysan5/909dc6cf33ed40223eb0dfe625c0de74#one-man-custom-engines para ver varios ejemplos. Obviamente si lo que quieres es brilli brilli y texturas 8k pues tira por UE5.

#35 para ser un poco tocapelotas, ese video muestra solo un renderer, que en mi opinion es de lo mas "accesible" respecto a recursos y facilidad de desarrollo cuando quieres empezar a programarte tu propio motor. Luego hay muchisimo mas trabajo detras que descubres cuando empiezas a rascar, como es el input, audio, herramientas/pipeline, logica, gestion de recursos...

1 respuesta
kidandcat

#36 Si te pones a usar librerías como SDL, no estas usando un motor existente porque estas usando herramientas específicas para cada función, eso es prácticamente lo mismo que usar un motor...

"Second question, what parts of the engine usually rely on external libraries/middleware? It also depends on the company resources but usually audio-system, physics, rendering, networking, ui-system, terrain-system, vegetation-system and some other pieces"

Aquí en teoría estamos debatiendo que la gente antes programaba todo de cero.

Que yo no le quito el mérito a nadie, a mi por ejemplo me flipa lo que han hecho en el No Mans Sky, esos cambios de entorno entrando y saliendo de los planetas sin ningún tipo de carga es un pasote.

1 respuesta
r2d2rigo

#37 no, no lo es.

Motor (Unity, UE) > Framework (XNA, Cocos2D) > Middleware (FMOD, Havok) > Libreria (SDL, SFML)

"Programarte todo de 0" no significa "aqui tienes el manual del codigo maquina de la plataforma que vas a usar, tira millas", significa que te has montado una solucion completamente personalizada aposta para tu juego, bien sea juntando librerias/middlewares o usando un framework como punto de partida.

1 respuesta
kidandcat

#38 Permiteme resumirte tu frase, asi te la analizas tu solito:

"Programarte todo de 0" no significa ".....", significa que te has montado una solucion ... personalizada ... para tu juego ... usando un framework como punto de partida.

Emm no, programarte todo desde cero significa otra cosa, ahora, si quieres darle otro significado . . .

carra

Como estáis diciendo, puede haber muchas opiniones de lo que es "partir de cero". Al final todo nuestro código se está ejecutando sobre alguna plataforma externa, a no ser que estés haciendo el boot inicial de la máquina tú mismo. Por eso mismo, hoy en día partir absolutamente de cero es algo que prácticamente ya no sería posible. Incluso un simple programa en Windows pelado ya tiene acceso mediante la propia API del sistema a cosas como DirectX, OpenGL, etc. En cambio, en MS-DOS o en ordenadores antiguos el sistema prácticamente no hacía nada por ti. Cambiar el modo de video, escribir texto en consola, acceso básico a archivos y poco más.

Y ojo porque para esto nos influye incluso la elección de qué lenguaje de programación estamos usando. En C# por ejemplo, aunque no uses ninguna librería, la propia máquina virtual de .Net ya nos incorpora muchas DLLs y librerías.

Sin embargo por experiencia propia, usar SDL o similares no se puede comparar a usar un motor. Es como comparar batir un huevo con la batidora eléctrica o batirlo a mano con una espumadera. En los dos casos usamos una herramienta, pero mientras que en un caso la herramienta básicamente lo automatiza todo, en el otro sólo nos da lo más básico de lo básico y el resto nos lo curramos nosotros como más nos guste.

2 meses después
Soltrac

Unrelated a #1. Dices que llevas más de 20 años...

Amigo, y 30....que la selección de VGA CGA y EGA me cogió muy pequeñito.

Sorry por el necropost anyway. Los feelings

1 respuesta
carra

#41 Jeje hombre, es verdad que jugando y usando ordenadores llevaba más tiempo. Pero programando no tanto! :sweat_smile:

B

.

1 respuesta
carra

#43 Pues pinta bien. Y aunque solo sea prepararse el esqueleto del juego, e integrarse todas estas librerías con SFML, ya hay curro ahí. Me han hecho gracia las balas de cañón del Mario puestas ahí jeje

1
Kaledros

Nunca he visto a un solo artista preguntarse si vale la pena usar Blender (o Aseprite, o el programa que sea) o crearse su propia herramienta desde cero. Lo mismo con los músicos o los diseñadores, de todos los aspectos relacionados con el gamedev sólo he visto a programadores preguntarse si es mejor usar un motor o crearlo. No digo que esa duda no sea válida (de hecho en algunos casos es hasta necesaria), me produce curiosidad, simplemente.

Encofrado

Imagino que porque por ejemplo, por el lado de los 3d artist, se dedicarán a hacer lo suyo y ya, aunque he visto en el canal de discord donde estoy a gente que se hace sus addons y los cuelga para que la gente los pruebe y también recibir feedback.

Aunque lo que planteas es interesante y daría para hilo, probablemente casi todo se reducirá a "no reinventes la rueda, usa lo que ya existe".