Edevi, el blog de Manuel F. Lara

Puesto que dos meses y medio es poco tiempo para llevar a cabo un proyecto de esta envergadura, tengo que hacer uso de todas las herramientas y recursos externos que pueda para agilizar el desarrollo.

Algo que obviamente ayuda muchísimo es utilizar un motor externo. Para este proyecto voy a utilizar uno del que ya he hablado en alguna ocasión: Unity.

Unity es un motor cuyo entorno de desarrollo está disponible únicamente para Mac, aunque lo que hagas con él se puede exportar como aplicación para Mac, Widget de Dashboard (Mac), aplicación Web (Mac y Windows) o aplicación para Windows (sólo en Unity Pro). Usa OpenGL para todas las plataformas, aunque a finales de verano verá la luz Unity 2.0, que entre una serie de nuevas características realmente interesantes (terrenos, sistema GUI, sombras…) hay algo que ayudará mucho de cara a atacar el mercado Windows: un renderer basado en DirectX 9.

Sin embargo, el principal atractivo de Unity ya estaba disponible en su versión 1.0: su workflow.

• Importa archivos nativamente de cantidad de formatos: FBX (3D Max y otros), Maya, Cheetah3D, PSD, etc.
• Tiene un sistema de entidades cuyo comportamiento se programa mediante scripts independientes reutilizables y que pueden escribirse en C#, Javascript o Boo (un lenguaje similar a Python), y que utiliza el framework Mono de núcleo. De hecho, con Unity 2.0 tendrás a tu disposición toda la potencia de .NET 2.0.
• El IDE de Unity es, hablando claro, la leche. Es algo así como los editores de Torque (sin el de GUI, todo sea dicho) pero bien hechos y con más características. Hay que probarlo para darse cuenta realmente de lo mucho que ayuda. Vista de escena y de juego, inspector de propiedades de las entidades, jerarquía de nodos en la escena y más.

A todos los afortunados poseedores de un ordenador Mac les invito a que hagan uso del periodo de prueba de Unity porque realmente, vale la pena.

Ya he comentado antes que Unity es un entorno realmente productivo. Una de las features que más tiempo ahorran y más simplifican el código son las corutinas. Es algo que también tiene UnrealScript y podría decirse que es uno de los pilares de la programación en DIV/Fenix.

Digamos que tengo un item que quiero que al colisionar con un jugador, desaparezca suavemente aumentando su transparencia. Y que al cabo de un minuto vuelta a aparecer, de nuevo suavemente. Esto en un motor convencional requeriría tener varias variables de la clase Item para llevar la cuenta del tiempo que llevamos haciendo fading del objeto, el sentido del fading (está apareciendo o desapareciendo?) o el tiempo de espera hasta el respawn. Y además, todo ese código estaría mezclado con el resto de la lógica que queramos que ese item ejecute cada frame, en algún método como Update() o algo similar. Todo eso disparado por algún confuso sistema de detección de colisiones.
En Unity sería algo así:

La sentencia yield es equivalente a frame; en DIV/Fenix. En Python tiene el mismo nombre, y en UnrealScript no me acuerdo, pero en todos funciona prácticamente del mismo modo (el contexto en el que pueda usarse ya es otra historia). Básicamente significa “sal de esta función pero mantén el contexto de la misma en memoria, para en el siguiente frame, retomarla justo donde la acabo de dejar”. De este modo puedes definir en una función una serie de eventos o comportamientos que ocurrirán sucesivamente uno detrás de otro en tu simulación, en vez de ejecutarse todos secuencialmente pero en el mismo frame.
Al principio no le veía demasiada utilidad. Después de usarlos me doy cuenta del gran potencial que tienen, sobretodo en cuanto a productividad y mantenimiento del código.