× PortadaNoticiasTrabajoColaboraciónEnlacesForosIRCFormaciónNosotros
Stratos: Developer's Meeting Point

Welcome to Stratos!

Acceder



Diferencias entre engines. (Autor : Daemon)
« 23 de Octubre de 2013, 11:24:07 am »
Hola,

estoy haciendo un pequeo sondeo de frameworks de desarrollo de videojuegos y me gustara preguntaros a aquellos que habis empleado varios, cuales son las diferencias ms 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, caractersticas y precio (sin tener en cuenta el soporte o servicios adicionales que ofrecen las compaas que estn detrs de dichos frameworks), pero tecnolgicamente qu los diferencia a unos de otros? Cules son sus puntos fuertes y dbiles?.

Creo que hacer este pequeo sondeo nos puede venir bien a muchos, o sea que los expertos, animaos a comentar :). Muchas gracias a todos aquellos que lo hagis.
Responder #1 por Daemon
« 23 de Octubre de 2013, 01:24:07 pm »
Continuando con la investigacin, dos artculos 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 ms destacable sobre el que tena cierta intuicin y que encuentra soporte en los artculos es que la caracterstica ms deseada de un framework para desarrollo de videojuegos es la posibilidad de integracin fcil con bibliotecas de 3s. Es algo que mirando un poco el mercado de los engines es lgico: 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 caracterstica la tienen estos frameworks?
Responder #2 por Juanchocosa
« 23 de Octubre de 2013, 01:27:34 pm »
Creo que para tomar una decisin primero deberas 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 fro, no creo que haya uno mejor que otro a secas. El contexto es importante.
Responder #3 por Daemon
« 23 de Octubre de 2013, 02:21:30 pm »
Gracias por la respuesta gh,

s, tienes razn en que la evaluacin/comparacin se debe realizar respecto a determinadas caractersticas. Pero mi primer punto es establecer qu caractersticas son consideradas ms importantes a la hora de escoger un framework. Una bsqueda 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 ms en el sentido evaluar a nivel tecnolgico cuales de estos frameworks os han resultado ms productivos, se han adaptado mejor a vuestra forma de trabajar y saber el porqu. Ya que estoy voy a poner una base de caractersticas para comparar, pero si alguien considera otras pues bienvenidas sern. Por ejemplo:

1.- Modelo de programacin que emplean las bibliotecas de dichos frameworks y cual consideris en vuestra experiencia que ha sido ms productivo para vosotros (Orientado a Objetos, Orientado a Aspectos, ...)
2.- Modelo de creacin de la IU y forma de integracin con la lgica de la aplicacin (MVVM, otras ...).
3.- Modelo para integrar "assets": modelos grficos/efectos/sonido/IA (quizs arquitectura dirigida a eventos, otras ...).
4.- Posibilidad y dificultad para hacer plugins con bibliotecas de 3.
5.- Posibilidad y dificultad de utilizar slo las bibliotecas que se necesiten, p.e. slo la fsica, slo el motor grfico, slo la IA...
5.- Disponibilidad de profilers para medir rendimiento/memoria y diagnosticar posibles problemas.
6.- "Bondad" del editor para manejar todo lo anterior.

« ltima modificacin: 24 de Octubre de 2013, 10:06:39 am por Daemon »
Responder #4 por TrOnTxU
« 23 de Octubre de 2013, 08:45:27 pm »
En mi opinin todo el "low-level" cuando ms DoD (Data Oriented Design) mejor:
1 - Mayor sencillez y claridad en el diseo (por norma general)
2 - Menor tiempo de compilacin
3 - Ms fcil hacer decoupling de sub-sistemas
4 - Mayor coherencia de cache (por tanto mayor velocidad de ejecucin)
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 ms "versatiles" (en mi opinin) 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 opinin (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 compresin, 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 pequeas" son ms faciles de mantener y se "cargan" ms rapidamente.
4 - Mayor facilidad de trabajo concurrente y "data merge".
5 - Menor problema para crear las herramientas en un lenguaje de ms alto nivel (C#, Python, ...) aunque el run-time siga siendo completamente C++.
6 - Ms fcil de mantener un runtime "independiente de la edicin" y de "bajo peso".

Para solventar el problema de comunicacin (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 opinin, pero tambin existe algun motor por ahi con una filosofia parecida y bastante eficiente (veas: http://www.bitsquid.se/ ).

Espero haber aportado algo.
Un saludo.

« ltima modificacin: 23 de Octubre de 2013, 09:05:49 pm por TrOnTxU »
Responder #5 por Daemon
« 24 de Octubre de 2013, 10:05:01 am »
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 programacin te parece mejor que otro. Podras desarrollar un poquito ms o poner algn caso sencillo que muestre lo que dices?

Otra de las cosas interesantes la encontr en la documentacin de bitsquid que has enlazado. Es la forma en que logran la cooperacin en tiempo real para la creacin de un juego, artistas includos:

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 colaboracin, que puedas desde el momento 0 unir los esfuerzos de lo que est haciendo el equipo, sean artistas, programadores, editores de niveles, hoy da me parece fundamental.

Por otro lado me he descargado los frameworks de mi listado inicial (aquellos que tienen una licencia de evaluacin o son gratutos) y les voy a echar un ojo para ver que tal. De todas formas sigo muy interesado en vuestras opiniones al respecto.
« ltima modificacin: 24 de Octubre de 2013, 10:09:32 am por Daemon »
Responder #6 por TrOnTxU
« 24 de Octubre de 2013, 11:51:23 am »
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 botn 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 ms detalle.

A parte, otro ejemplo que te puedo poner es un "Endless Runner/Flyer" donde utilizar estructuras simples que definan los "objetos dinmicos" 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).
Adems 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 implementacin genrica, aunque tambin funcional, no puede aprovechar.

Espero que te ayude.
Salu2
« ltima modificacin: 24 de Octubre de 2013, 11:58:57 am por TrOnTxU »


Stratos es un servicio gratuito, cuyos costes se cubren en parte con la publicidad.
Por favor, desactiva el bloqueador de anuncios en esta web para ayudar a que siga adelante.
Muchísimas gracias.