Aplicación Práctica - Fundación - Este artículo describe cosas que tienes que pensar al planear tus diseños (Cacheado)


Este artículo describe las cosas a pensar cuando planees tus diseños. Por ahora ya sabes lo que quiere tu programa, ahora es tiempo de ver como. Muchas de estas cosas se cubren en buenos libros o artículos sobre la arquitectura de un juego o el diseño; en este artículo he traducido los conceptos generales sobre "Cómo hacerlo con Ogre".

Olvida las aplicaciones de Demostración


Como dije en la intro, las aplicaciones de demostración son un muy buen ejemplo de la funcionalidad y demuestran las características, pero son al mismo tiempo una idea básica para una aplicación práctica. Los desarrolladores de Ogre te diran lo mismo: úsalos si quieres pero son sólo para las Demo...

Un problema mayor es el limitado manejo de la entrada en Ogre, lo cual, de acuerdo con Sinbad, será separado enteramente(si no eliminado completamente) para Ogre 1.1, sino antes. [Nota: Esto ya se hizo. En la versión Ogre 1.4, OIS ha reemplazado al viejo sistema, del que hablábamos en las primeras líneas.] El sistema de entrada está limitado al ratón y al teclado, así que si quieres, por ejemplo, soporte para un stick o gamepad en tu juego, necesitarás enrollar tu propio bucle principal. Recomiendo pjcast's OIS: su trabajo es fabuloso y lo he probado personalmente para Win32 y Linux (FC4), y tiene soporte completo para sticks y force feedback. Encuéntralo en www.wreckedgames.com o en SourceForge en http://sf.net/projects/wgois.

El framework de ejemplo también hace algunas premisas sobre la implementación de tu bucle principal (con llamadas a FrameStarted y FrameEnded). Otra vez, los desarrolladores de Ogre todo el tiempo que Ogre va primero y es principalmente una librería de renderizado 3D. Nada más.

Debería añadir en este punto que eres bienvenido a implementar FrameListener para tu aplicación, o capturar los eventos FrameStarted y FrameEnded, incluso si ejecutas tu propio bucle principal. La razón para esto es que estas son las características de Ogre, no sólo las características del Ejemplo de Aplicación, y sus eventos.

Una razón para no implementar múltiples framelisteners, mientras estamos sobre este tema, es que no garantizas el orden en que serán llamados. El contenedor en Ogre::Root que toma nota de los framelisteners registrados esta implementado usando un conjunto STL, que no garantiza guardar los listeners en el orden en el que fueron registrados. Si tu aplicación depende de un cierto orden de ejecución, entonces deberías usar solamente un único frame listener, o ninguno e implementar la lógica de tu juego en el bucle principal antes de la llamada a renderOneFrame().

Configuración de la Aplicación


La caja de diálogo (o la caja de texto interactiva en Linux si eliges la plataforma SDL) que lanza tu configuración al comienzo de cada demo. Para demos es conveniente. Pero no lo necesitas. Puedes usarlo si quieres, y tiene un soporte limitado para alterar la interfaz de sus elementos, pero la mayoría de los juegos proporcionan su propia UI para la configuración de video (además de configuración para los controles de entrada y audio). Deja que sea la GUI de tu juego la responsable de guardar los detalles de la configuración y que se los proporcione a Ogre al comienzo. Te mostraremos como insertar esta misma información en Ogre en un artículo posterior.

Si continuas o no usando los archivos de configuración de texto limpios como en la demo landscape "de terreno" es cosa tuya. Yo te recomiendo que no los uses. Permite a tu aplicación usar un único "config.ini" y lee las opciones de configuración general desde él, y proporciona sus valores a Ogre (y a otros subsistemas) al comienzo. Comprime en ZIP el resto de tu aplicación, organizándolo como necesite tu aplicación, como se describe debajo (Empaquetado de recursos).

Empaquetado de Recursos


Un Recurso es algo que tu juego consume o referencia durante la ejecución. Los archivos de modelos, los archivos de script, etc. Encontrarás que los esquemas de empaquetado de Ogre son archivos ZIP... ordinarios. Estos ZIP pueden manipularse con WinZIP (o zcat o "tar -zxvf"). Eres libre de implementar tu propio sistema de flujo de recursos.

Bucle Principal


Cada juego tiene un bucle principal. Los tuyos no serán diferentes. Tu juego introduce el bucle principal después de que todos los subsistemas se hayan inicializado, y este bucle es ejecutado hasta que le dices que pare, en cualquier punto tus subsistemas son descargados y limpiados (en el orden inverso del que fueron cargados) y la aplicación termina.

Tu bucle principal será responsable de reaccionar a dos cosas: la entrada local (eventos HID) y entrada en red (eventos remotos). Tu juego debería tratar los dos de la misma manera; esto hará la implementación del soporte de red mucho más fácil.

El mejor modo de tratar todas las entradas de una manera homogénea es abstraer los eventos en "acciones" (y resistir el deseo de proporcionar un estilo a lo DirectInput "ActionMap" para tus juegos a menos una muy buena razón - el soporte de joystick es una muy buena razón). Lo que significa que tu bucle principal debería procesar los eventos como "objeto A dispara arma C" en vez de "botón de teclado F fue pulsado" o "botón de ratón 2 fue soltado". Tendrás que traducir los evento HID o de Red en esta "acción" antes de actuar.


Una vez que tu bucle principal tiene algo sobre lo que actuar, comenzarás a procesar los efectos de algunas acciones: mueve un objeto en el gráfico de la escena, comienza a ejecutar (paso por paso) una secuencia de explosión, juega con el audio cue de la explosión, etc. Esto se cubrirá más tarde, pero por ahora es bastante saber que al final de cada iteración de tu bucle principal, llamarás al método "renderOneFrame" en el API de Ogre para renderizar el cambio de estado de la escena 3D. Si has estado usando el ExampleApplication y el modo de ExampleFrameListener para hacer las cosas, entonces tendrás que hacer una llamada a "startRendering" que deberías olvidar ahora inmediatamente. Tu sencillo programa ejecutará el bucle principal tan rápido como le sea posible, y le dirá a Ogre que renderice el siguiente frame, y vuelva a comenzar.

La Próxima Vez


En la siguiente instalación veremos la inicialización de tu juego y los subsistemas.