Almlys.org

A veces ves cosas como estas: "Myst V va sortir al mercat emprant el motor ODE".

Siempre alguien salta diciendo, pero seras subnormal, eso solo es una libreria física, blah, blah, blah... Ambas cosas son ciertas, yo a la librería física la llamo también engine, y a la de sonido, a la de red, etc.. A todo lo llamo "motor". Es como si el motor de un juego fuera todo un conjunto de motores. Sea o no sea correcta la terminología, es la que yo uso y punto. Francamente un juego determinado, dependiendo de los requisitos que estos demande como mínimo tendra:

• Motor de render, gráfico, 3d, etc... - Su función: Cargar, gestionar, trabajar, manipular una escena, que a su vez no son más que cientos de triangulos, y representar en tiempo real una o varias vistas capturadas por una camára determinada.
• Motor físico: Mantiene el estado físico de todos los objectos de una escena, y realiza todas las tareas de simulación. Aquí existe un gran debate de si el 'sttepping' del motor físico se debe integrar dentro del ciclo de render de la aplicación, o debe de mantener-se en un hilo a parte. (Esto para aquellos motores donde la física sea responsabilidad del cliente y no el server, sin hablar de simulación distribuida por p2p).
• Audio: Muy sencillo, poder poner música, emitir sonidos desde puntos específicos de nuestra escena, si dos objetos chocan pues que suene un efecto sonoro, etc...
• Networking: Poder hacer que dos personajillos cutrillos hechos a base del tutorial del SimplePerson de Blender puedan campar libremente por la escena controlados desde dos clientes. Como lo hagas al final, la has cagado, te puedo decir por experiencia que lo vas acabar reescribiendolo todo. Esto también pasa cuando mandas la ingeniería del software a tomar por el saco cuando es la primera cosa que hay que tener presente.
• Libreria de I/O del teclado, ratón, joystick, etc: Bueno, las cosas no se mueven solas
• Motor de Lógica: Un sistema de scripting, que controla todo lo que pasa en la escena. (Por ejemplo Python). Lo bueno es poner esto en funcionamiento, porqué se me ocurren formas muy guarras de hacerlo, que vete a saber como dejan la eficiencia.
• Algo más: Si me estoy dejando cosas, lo se, una interfaz gráfica 2D, la gestión de los recursos que en este caso le pasamos la pelota al motor gráfico, etc, etc, etc...

Luego acabas con un monstruo que no se aguanta por ningún lado, con un derroche de memoria brutal. El problema de usar subsistemas separados, es cada uno trata los datos de la escena de una forma u otra y acabas teniendo casi los mismos datos replicados por cientos de estructuras de datos de diferentes tipos para cada librería. Total instalamos más RAM y miramos para otro lado