Diferencias entre engines.

[Daemon]

Hola,

estoy haciendo un pequeño sondeo de frameworks de desarrollo de videojuegos y me gustaría preguntaros a aquellos que habéis empleado varios, cuales son las diferencias más destacables que vosotros veis entre los siguientes frameworks de desarrollo, así como cual os parece mejor y por qué:

* Project Anarchy - http://www.projectanarchy.com/download
* UDK - http://www.unrealengine.com/en/features/
* Unity - http://unity3d.com/pages/create-games?gclid=CMiiz_bZoLoCFXHJtAodtw8AKQ
* HeroCloud - http://www.heroengine.com/heroengine/why-heroengine/
* WaveEngine - http://waveengine.net/Download/Index

Creo que los motores de la anterior lista pueden ser comparables por su calidad, características y precio (sin tener en cuenta el soporte o servicios adicionales que ofrecen las compañías que están detrás de dichos frameworks), pero tecnológicamente ¿qué los diferencia a unos de otros? ¿Cuáles son sus puntos fuertes y débiles?.

Creo que hacer este pequeño sondeo nos puede venir bien a muchos, o sea que los expertos, animaos a comentar :). Muchas gracias a todos aquellos que lo hagáis.

[Daemon]

Continuando con la investigación, dos artículos que he encontrado y que me parecen interesantes:

http://www.gamasutra.com/blogs/MarkDeLoura/20090302/581/The_Engine_Survey_General_results.php
http://www.gamasutra.com/blogs/MarkDeLoura/20090316/903/The_Engine_Survey_Technology_Results.php

El punto más destacable sobre el que tenía cierta intuición y que encuentra soporte en los artículos es que la característica más deseada de un framework para desarrollo de videojuegos es la posibilidad de integración fácil con bibliotecas de 3ºs. Es algo que mirando un poco el mercado de los engines es lógico: cuando un estudio quiere desarrollar su juego, debe poder escoger componentes que le solucionen los problemas, ya sean propios, del framework o de un 3º. ¿Veis que esa característica la tienen estos frameworks?

[Juanchocosa]

Creo que para tomar una decisión primero deberías definir para que quieres usarlo.

Si tienes un listado de puntos que consideras importantes para tu proyecto, puedes evaluar los engines en consecuencia.

Así en frío, no creo que haya uno mejor que otro a secas. El contexto es importante.

[Daemon]

Gracias por la respuesta gh,

sí, tienes razón en que la evaluación/comparación se debe realizar respecto a determinadas características. Pero mi primer punto es establecer qué características son consideradas más importantes a la hora de escoger un framework. Una búsqueda por los foros me deja claro que el precio y el despliegue multiplataforma parece ser uno de los principales factores que tiene en cuenta la gente a la hora de decidir. Pero teniendo eso claro, mi pregunta iba más en el sentido evaluar a nivel tecnológico cuales de estos frameworks os han resultado más productivos, se han adaptado mejor a vuestra forma de trabajar y saber el porqué. Ya que estoy voy a poner una base de características para comparar, pero si alguien considera otras pues bienvenidas serán. Por ejemplo:

1.- Modelo de programación que emplean las bibliotecas de dichos frameworks y cual consideráis en vuestra experiencia que ha sido más productivo para vosotros (Orientado a Objetos, Orientado a Aspectos, ...)
2.- Modelo de creación de la IU y forma de integración con la lógica de la aplicación (MVVM, otras ...).
3.- Modelo para integrar "assets": modelos gráficos/efectos/sonido/IA (quizás arquitectura dirigida a eventos, otras ...).
4.- Posibilidad y dificultad para hacer plugins con bibliotecas de 3º.
5.- Posibilidad y dificultad de utilizar sólo las bibliotecas que se necesiten, p.e. sólo la física, sólo el motor gráfico, sólo la IA...
5.- Disponibilidad de profilers para medir rendimiento/memoria y diagnosticar posibles problemas.
6.- "Bondad" del editor para manejar todo lo anterior.

[TrOnTxU]

En mi opinión todo el "low-level" cuando más DoD (Data Oriented Design) mejor:
1 - Mayor sencillez y claridad en el diseño (por norma general)
2 - Menor tiempo de compilación
3 - Más fácil hacer decoupling de sub-sistemas
4 - Mayor coherencia de cache (por tanto mayor velocidad de ejecución)
5 - Mayor facilidad para mover sub-sistemas a multithreading, CPU-Helpers(como SPU) y/o GPGPU.

Las "capas superiores" que "atan" todos los sub-sistemas ... depende del tipo de juego.
Para algunos juegos son mejores basados en propiedades, otros orientado a objetos, etc.

Uno de los sistemas de gameplay más "versatiles" (en mi opinión) es el "Game Object Dynamic Components", como puede ser el del Unity3D o el de Insomniac https://d3cw3dd2w32x2b.cloudfront.net/wp-content/uploads/2011/06/6-1-2010.pdf.

Aunque yo personalmente en mi motor utilizo modelos de game objects diferentes por tipo de juego (el que creo que puede encajar mejor).


En cuanto a las "tools", va por gustos. En mi opinión (y tal como lo estoy implementando yo en el Typhoeus) mejor tener tools separadas, y no dependientes del "runtime". Y mantener dos tipos de datos:
1) Los intermedios o de trabajo (preferiblemete en formato texto tipo JSON o XML)
2) Los binarios finales compilados. Que pueden ser compartidos o diferentes entre varias plataformas (cada plataforma puede tener sus tipos de compresión, su endianess, etc.)

Para mi las ventajas sobre el modelo ÜberEditor (Unity3D, UnrealEd, etc.) son:
1 - Si "peta" el motor, no "peta" el editor.
2 - Si "peta" el editor de particulas, no "peta" el editor de materiales, etc.
3 - Las "herramientas pequeñas" son más faciles de mantener y se "cargan" más rapidamente.
4 - Mayor facilidad de trabajo concurrente y "data merge".
5 - Menor problema para crear las herramientas en un lenguaje de más alto nivel (C#, Python, ...) aunque el run-time siga siendo completamente C++.
6 - Más fácil de mantener un runtime "independiente de la edición" y de "bajo peso".

Para solventar el problema de comunicación (entre herramientas y con el runtime) lo mejor es usar sockets TCP/IP. Lo cual tambien permite actualizar el estado del juego directamente en la consola o en el smart-phone con un solo 'click' en una herramienta del PC de desarrollo.


Esto es solo mi opinión, pero también existe algun motor por ahi con una filosofia parecida y bastante eficiente (veasé: http://www.bitsquid.se/ ).

Espero haber aportado algo.
Un saludo.

[Daemon]

Gracias por la respuesta y los enlaces TrOnTxU.

Una de las cosas que me ha parecido interesante de lo que dices es que dependiendo del tipo de juego un paradigma de programación te parece mejor que otro. ¿Podrías desarrollar un poquito más o poner algún caso sencillo que muestre lo que dices?

Otra de las cosas interesantes la encontré en la documentación de bitsquid que has enlazado. Es la forma en que logran la cooperación en tiempo real para la creación de un juego, artistas incluídos:

http://www.bitsquid.se/presentations/collaboration.pdf
http://www.bitsquid.se/presentations/cutting-the-pipe.pdf

Al fin y al cabo el enfasis de un middleware se pone en el aumento de productividad que supone emplearlo y el tema de la colaboración, que puedas desde el momento 0 unir los esfuerzos de lo que está haciendo el equipo, sean artistas, programadores, editores de niveles, hoy día me parece fundamental.

Por otro lado me he descargado los frameworks de mi listado inicial (aquellos que tienen una licencia de evaluación o son gratuítos) y les voy a echar un ojo para ver que tal. De todas formas sigo muy interesado en vuestras opiniones al respecto.

[TrOnTxU]

Esos dos enlaces que has puesto, son muy buenos :)
De hecho, yo me basé en "Cutting the Pipe" cuando decidí "actualizar" el "tool-set" de mi engine. Y la verdad es que funciona de maravilla, con un super botón de "Compile And Reload" :D

En cuanto a los tipos de modelos de GameObjects, mirate este link del Uncharted 2 de Naughty Dog: http://www.slideshare.net/naughty_dog/statebased-scripting-in-uncharted-2-among-thieves
Si encuentras el Power Point (creo que esta en la pagina de Naughty) tambien tiene anotaciones y comentarios (yo lo tengo bajado).
Basicamente define como funciona el state scripting que se han montado en Scheme. Pero en las paginas 13, 14 y 15 tienes breves descripciones de varios modelos de game objects (Unreal, Property-Centric, y Uncharted2). En la pag. 12 hay links interesantes, y en concreto el libro del mismo Jason Gregory "Game Engine Architecture" tiene un par de capitulos en los que define los diferentes modelos con mucho más detalle.

A parte, otro ejemplo que te puedo poner es un "Endless Runner/Flyer" donde utilizar estructuras simples que definan los "objetos dinámicos" dentro de un "Buffer Circular" ofrece muchas ventajas.
Ya que sabes que vas a ir creando y destruyendo los Game Objects continua y ordenadamente (siempre hacia adelante, o de lado, se entiende).
Y sabiendo el indice de "start" y de "end" te permite no tener que recorrer toda la "lista" de objetos o crear estructuras de "particion espacial" para las colisiones (por ejemplo).
Además puedes dibujar ordenadamente por Z en el caso de que sea un "endless" en el que "avanzas hacia el fondo". Evitandote asi tener que reordenar la lista de meshes por profundidad, y lo puedes utilizar en los opacos, por ejemplo, para descartar pixeles con el zbuffer (moderando el pixel fill overdraw), o cualquier otra tecnica de este tipo.

Como ya se ha dicho antes, un buen conocimiento del contexto te ofrece grandes ventajas, que una implementación genérica, aunque también funcional, no puede aprovechar.

Espero que te ayude.
Salu2