mmmm, patrones ... este puede ser un tema "delicado". Voy a intentar dar mi opinión, justificandola, lo más brevemente posible y intentando no provocar :P

Si te refieres a implementar el patrom mvc, con su clase para cada parte, de la forma más "estricta", lo hice en un par de proyectos hace tiempo. Pero era hace mucho, y eran proyectos más sencillos.

En proyectos más complejos, para mi, la idea de separar el acceso a las partes "low-engine" así tiene sentido:
+ Modelo: Content, GameState, ...
Vista: Renderer, AudioEngine, User Input, Rumble or feedback controller, ...
Controlador: IA, EventSystem, ScriptSystem, Fisicas, ... ?

Aunque reconozco que nunca he sido muy bueno en esto de la abstracción.
En teoria esto te permite poder, por ejemplo, cambiar la "vista" sin que afecte a la "jugabilidad".
Pero mi primera pregunta es: ¿realmente lo vas a hacer?

Si lo que tienes es un "Renderer" OGL, y quieres hacer otro DX9, por ejemplo, tienes varias opciones:
1) Te creas la clase vista, como una capa de abstracción sobre el renderer, y ahi cambias las llamadas al nuevo Renderer.
2) Creas el nuevo Renderer y susutiuyes todas las llamadas a mano
3) Derivas de una interfaz el renderer y asi puedes elegir el renderer en runtime.
4) Lo anterior pero con un par de "trucos" con los #defines para fijar un Renderer en compile-time y "saltarte los virtuales".
5) ...

Pero como ves, en mi opinión la distribucion mvc en juegos/engines es más "conceptual" que "real".

Para mi, el "patrón" que funciona son los Managers. Dividir el juego/engine en tantos sub-sistemas "autonomos" como necesites, y crear capas por encima para atarlos.

En la capa más abstracta de jugabilidad no se puede "generalizar" ya que cada juego se implementa mejor de una manera. Aqui podriamos hablar de "controlador" por ejemplo.
Aun así uno bastante "generico" seria tener un GameWorldManager que tiene la lista de "entidades", que a su vez tiene "referencias" a objetos de los diferentes subsistemas (render, audio, fisicas, ...).
Aunque, por ejemplo, un juego de cartas, con una "entidad para cada carta" puede que igual no seria lo más apropiado (en mi ponión ... aunque poder, se puede hacer).

Lo importante en esta "distribución", es tener un buen subsistema de paso de mensajes y/o eventos entre los diferentes subsistemas. Esto te permite "abstraer" el contenido de los mensajes, y permitir que sistemas que "no se conocen" (por decirlo de alguna manera) intercambien mensajes entre ellos.
Esto si que, en mi opinión, permite un "verdadero decoupling" de las partes/sistemas, y una posible mayor "reusabilidad", e "independencia entre los subsistemas".

Hablando del "modelo":
- Hay que tener en cuenta que el Content cambia, pero es mejor que sea "data-drive", sino imprescindible. El código deberia centrarse en un ContentManager, y los Resources o Assets que maneja.
- El GameState es importante tenerlo "separado", o "listo para serializar", independientemente del "código de control o lógica de juego". Ya que muchas veces es lo necesario para: grabar partida, network-replication, repeticiones, juegar con el tiempo (como el prince of persia), etc, etc, etc


Además pienso, que (a nivel de juegos) es mejor pensar en datos y transformaciones, antes que en "patrones de diseño OOP". Pero es mi opinión.

Buenol al final lo de breve parece que ha sido anecdótico  :-[
Un saludo.

Francisco, animo con ello, ni leas al personal de aqui, esto es un nido defrustraos que no han tenio los cojones suficientes de hacer realidad lo que deseaban.

Me entra la risa cuando entro aqui y la gente habla con si fueran gurus del tema.

Jajajaja, de tranquis ... :)

Pues la verdad es que tiene muy buena pinta :)

Siento no poder ayudarte con lo de los precios :(

Ya contarás como va!

Un saludo.

Para mi lo mejor de Unity3D es:

- Multiplataforma  (ya veo que estais en ello :) )

- Sistema de Game Object Components (en C# es muy fácil de hacer con herencia).

- Poder "editar de manera visual" los componentes de los GameObject.

- Crear nuevos componentes, es tan facil como derivar un objeto. Las "miembros" públicos se serializan siempre, lo que sirve para cargar/guardar automaticamente y se muestran en el inspector para su edición. (Esto también es fácil y sencillo, solo hay que tirar de reflexion al cargar/salvar y al "seleccionar" un gameObject, lo que muestra en el "inspector" su "contenido en componentes").
Como contrapartida se puede hacer con "Propiedades" en vez de con "Miembros Públicos" que es lo "típico" que inspecciona el "PropertyGrid".

- Scripts para modifcar la "Pipeline de Importación" de manera "relativamente sencilla" (bastante más que los importadores de XNA).

- Ampliación del "Editor". Crear nuevos menus, poder interaccionar con la mayoria de las interfaces de acceso del editor, etc.

- Provee "Abstracción de plataforma", para la mayoria de "requerimientos" de TRC/Lotcheck, y "classes especificas" para las "features" especificas de plataforma ("Acelerometro", "Wii Balance Board", etc).

- La "pro" ya tiene muchas cosas integradas: Umbra, el nuevo "Beast", Physix, ...



Y lo peor:

- Mono en consolas NO MOLA. El gc es una *****, he visto un artículo interesante sobre hacer un gc incremental para Mono http://static.usenix.org/event/vm04/wips/goh.pdf, pero tampoco me lo he mirado mucho, y no sé si te puede valer de algo, pero en fin ...

- La implementación del "Dynamic Game Object Component System" es "extradamente" OOP, cosa "reforzada" por el echo de los compoenetes MonoBehaivour, que "exportan" una interfaz puramente OOP.  Esto no seria malo, si no fuese por dos razones: dispositivos con caches pequeñas, y/o con PowerPC. Las cache misses van a ser un problema en todos los dispositivos con cache pequeñas, pero el "polimorfismo" da mayores signos de "ineficiencia" en PowerPCs, que en x86 o ARM.
Hay una implementación "muy curiosa", que utiliza Insomniac a partir para el "Resistance 1" y que se "establece" en el "Resistance 2". Es tremendamente más efectivo, DOD (aunque la interfaz puede parefcer OOP), cache friendly, multi-processor scalable, y permite offloads a SPUs.  http://www.insomniacgames.com/wp-content/uploads/2011/06/6-1-2010.pdf
Està en C++, y yo he probado implementar alguna cosa, aunque ahora tengo un sistema de GameObjects "light monolithic / static defined components" como el de Uncharted 2.
De todas formas, una de las cosas más interesantes, es el uso de las "Roster Pool", que yo he incluido en varios sistemas de nuestro engine (aunque en nuestro está en C++, la idea es muy parecida en C#).

- Dificil integración en algunos casos de un Sistema de Control de versiones para el manejo del "Content". El suyo propio no está mal, pero no es la panacea.



No sé si añadiria algo más, de todas formas es solo mi opinión.

Un saludo, y suerte! :D


PS: En cuanto a precios, no sé que decirte, pero varia bastante dependiendo de lo "cerrado" que puedas entregar el SDK o engine, cuando más código fuente tengas que pasar, más deberia de valer la licencia (por obvias razones).

La idea de XBLIG estaba bien en su momento. Y parecia que por una parte te daba acceso a aprender a desarrollar para 360, y por otra te permitia "comercializar" tus productos para ella, y distribuirlos de forma digital, además estarian en el Live para descargar con la "misma importancia" que los juegos Live de desarrolladores oficiales.

Pero, creo que esto no se ha cumplido por diversas razones:

1) No "aprendres" realmente a "manejar" la consola.
Con la Yaroze ( todavia la tengo en casa :) ) programabas en C, tenias unas "librerias de ayuda", pero si te ponias podias sacar dirreciones de memoria de todo, y hacerte tus propias libs. Y además era el "procedimiento adecuado" para tomar contacto con la consola, si más tarde te ponias a hacer un juego con "licencia oficial" podrias "aprovechar" practicamente todo.
XNA es algo parecido, ya que tb hay juegos de Live de desarrolladores oficiales echos con XNA, pero la diferencia básica está en la limitación (exclusiva de los Indies) del código nativo "no firmado". Mientras no puedas correr código nativo, pelearte con la EDRAM, utilizar SIMD, intentar reducir los cache misses en código crítico, etc. en mi opinión, realmente, no estás aprendiendo casi nada específico del dispositivo.

2) No hay TRC !!!!
Se que a mucha gente le da "grimilla" los TRC, TCR, lotchecks, y toda la pesca, ... pero "ni tanto ni tan calvo".
La opción de que la "comunidad" se autoevaluara, puntuara, etc., creo que no ha dado el resultado esperado ni de lejos.
Han prevalecido "intereses particulares" a veces de manera dañina para la comunidad y para la "imagen" del XBLIG delante de los usuarios. Que al final son los que deciden gastarse el dinero. (gracioso simil con el estado economico internacional actual).

3) Como es lógico, no ha se le ha dado la "misma importancia" al "Live Oficial" que al Indie.
Y es lógico por varias razones que yo no me puedo atrever a contradecir.

4) Ha habido un pequeño efecto retroalimentación negativo
Que implica varias decepciones desde prácticamente todos los "agentes" implicados.
- Desarrolladores con "poca o ninguna publicidad", y notas negativas en la "comunidad" que "pierden mucho" con un juego. El siguiente juego será peor (en el sentido de dedicarle menos tiempo y esfuerzos), o no se hará, porque no se puede estar continuamente "perdiendo dinero".
- Con juegos peores, los usuarios "tachan" de malos todos los juegos de XBLIG, y por tanto, de manera injusta, se "bombardean" los posibles "beneficios" que podrian regresar a los desarrolladores indies, para poder seguir "pagando más juegos" (recordemos que a final de mes hay que comer, por muy Indie que seas).
- En todo esto, a M$ le viene bien que hayan indies, porque tienes suscripciones anuales de los "developers", los royalties de las ventas (por pocas que sean), publicidad del rollo "que bueno que soy con los desarrolladores independientes", promocionas XNA, .NET y C#, etc. Pero tampoco es la "monda lironda", ya que la "monda lironda" a dia de hoy sigue siendo vender los 17.5 Millones de unidades en "formato fisico" de una "trilogia re-vende consolas".
- De forma que "incentiva" el desarrollo con el "sueña, desarrolla, crea, y olvidate" o como se llame en inglés. Que por otra parte, para mi, era de lo mejorcito de XBLIG.
- Al final nada es lo que parece y parece justo lo que no es.


En mi opinión ya se veia desde hace tiempo que la cosa no cuajaba, yo creo que se podia haber intentado "mejorar" pero eso depende mucho de los "intereses" de "otra gente".
Sigo pensando que hay, han habido y habrán "mercados mejores" para el "desarrollador Indie".

Un saludo.

De todas formas es interesante, parece que .NET, Mono y C# se "estableciendo" para desarrollar juegos  :D

Lo cual es un fastidio total, el garbage collector de c# siempre te toca los pies y el juego te da unos subidones en esos momentos que pa qué

Ohhh  Oo, uno de los "mios", ... ¡imposible!

¡¡Muerte al heap dinámico en los lenguajes de script de runtime!!

Jajajaja, es broma ...  :P

EDIT: Por cierto, ¿no hay runtimes de Mono que tengan la posibilidad de lanzar el garbage collector de forma incremental, como Lua?

Jajaja, está muy "fresco".  :D

Es un SDK de mucho mas nivel. Es como un XNA para Vita y otros dispositivos. Utiliza C#, el editor esta basado en Monodevelop y todo corre por encima de Mono (luego ellos ya tendran algo que coge eso y lo hace interactuar con las tripas de la Vita o de otros dispositivos, pero el desarrollador eso ni lo ve ni lo toca creo).

Es mas o menos lo mismo que hace Unity3D.

Gracias Vicente, me has ahorrado la descarga/instalación  ^_^'

Me parece una buena idea, sobretodo para "acercar la tecnologia" como ya lo hizo en su dia XBLIG.

Sin embargo no creo que me lo instale, como ya he dicho otras veces no me "emociona" Mono para runtime, y además creo que tener que utilizar un lenguaje y un "engine" diferente para cada dispositivo (XNA, PlaystationSuite, Objc en iOS, java para Android, etc.) es un "poco locura" a la hora de los "ports".

De todas formas es interesante, parece que .NET, Mono y C# se "estableciendo" para desarrollar juegos  :D ¿no lo vaticino alguien ya con el had/jad engine? :P
Yo sigo con mi "vieja escuela", "mis punteros locos" y esos "casts" que a tantos asustan ...  0:-) ... ¿será que me hago mayor?

No veo muy claro que tipo de SDK es.

¿Se supone que es algo "cerrado" como XNA?
¿Una toolchain de compilación?
¿Se programa en C/C++?

A parte, se supone que las tablets y moviles Sony son Android, ¿no es más fácil adaptar el motor OGLES que tengas para iOS u otro Android?

En cuanto a PS-Vita y PS3.
El ps3-sdk tiene la PSGL, que es un OGLES1.1 con un par de añadidos especificos, y los shaders (en un principio) los metes en Cg (lo que tiene NVidia RSX). Si quieres más "caña" te puedes meter en gcm, crear display list en paralelo, parchear fragment shaders desde las spus, blah,blah. Pero lo más rápido de portar, si tienes algo en OGLES es la PSGL.

Supongo que el sdk de Vita (viendo la trayectoria de los sdks de sony para sus consolas), tendra una version de opengl (sceGL, psGL, loquesea) y, por otra parte, una libreria de bajo nivel para manjear directamente las display lists.


Hasta aqui, lo que yo veo es ... igual no hay tanto problema en "portar" un juego sencillo (o un motor) a PS3, PS-Vita, ...
El problema a veces, es obtener la licencia de desarrollo (las maquinas de debug no son tan caras). Sobretodo para estudios pequeños.

Sin embargo lo veo a veces más problema de poder acceder a la tecnologia, de forma "didática", que de buscar mercado.
Si eres un estudio pequeño (de una o varias personas), realizar un juego para PS3 (aunque sea distribución digital), dada la "calidad" de producto necesaria (asi como pasar las TRC) son palabras mayores. Que poder hacer se puede, pero generalmente son gente "veterana", bien preparada y que con un poco de suerte para "colar el producto".

Además, si suponemos que a Sony no le interesa tener "gente sin controlar husmeando en su tecnologia", abrirán muy poco el SDK, o lo harán funcionar dentro de una "maquina virtual" o un "medio seguro de ejecución" para evitar más "hackeos", etc.

No sé, es una divagación personal, en fin .. tendré que sacar tiempo (ahora voy liado) y echarle un ojo al SDK para salir de dudas.

Un Saludo.

esto es parte del código que uso para dibujar un control como el que tu quieres, y que puedes ver aqui  Editor, en particular dibuja las tres lineas de abajo donde van a apareciendo los circulitos rojos.

No habia visto que ya tenias la linea del tiempo. Queda genial!  ^_^
Tendré que mirarme yo tb de hacer una para el editor de animaciones ;)

Hola a todos, soy un poco novato en esto, mi idea es generar una linea de tiempo tipo editor de video donde poder insertar marcas que luego al leerlas mande unos comandos via rs232, tendria distintas pistas que serian canales con un maximo de 500 y el largo de la linea de tiempo seria el equivalente a 30 minutos, pudiendo hacer zoom para ver mas detalle.

Respira ... en una frase has echo un documento de diseño ^^

No tengo demasiado claro lo que pides, ni de que va el programa.

Pero para tener una "linea de tiempo con zoom", creo que quieres decir un sistema de GUI que te permita crear controles "personalizados", y que te permite mostrar "¿una señal de video?".
Elige uno: Qt, .NET, wxWidgets, ...
Dependiendo de las plataformas y el lenguaje que escojas acabaras con uno o con otro.

Lo de la comunicación RS-232 no lo veia desde hace mucho tiempo, pero en fin, depende del sistema operativo, tendrás una manera u otra de acceder a él. Creo que .NET tambien tenia un interfaz, pero no me acuerdo.

En fin, suerte ^^

A raiz de este post he estado revisando la herramienta, porque tenia que actualizar alguna cosa.
Como sé que hacer la herramienta es un "peñazo", te he preparado una version de la mia. Y he incluido un ejemplo sencillo en C++ de como gastarla.
La herramienta es .NET no sé que version para windows. O sea que si no te funciona tendrás que ponerte el último framework.

El ejemplo está exportado como plataforma: STD_CPP_LE (Standard C++ Little Endian) y ASCII (realmente un ISO-899.. nosequé).
Si no vas a compilar para plataformas Big Endian no tienes problemas.

http://mural.uv.es/vibrun/locale_stratos.zip

Espero que te ayude. Ya me dices que te parece.

Salu2

EDIT: El Italiano no está traducido ^^, que nadie se ralle ni se enfade  0:-)

Estoy de acuerdo con EX3 y con FANatiko. Carga los textos cuando selecciones el idioma, y referencia los textos desde un array, o con una clase que lo controle, por ejemplo:

Código [Seleccionar] Expand


class LocaleManager
{
  public:
...
    void load_language(const char *path);
    const char* get_string(unsigned int id);
...
};


Una de las formas de "automatizar" el proceso de relacionar/actualizar las cadenas y mantener los datos de texto, es crearte una herramienta que te cree un formato binario propio con los textos por una parte y un header de C++ por otra. Aunque, realmente se suelen crear un binario por idioma.

Uno de mis sistemas preferidos (que me ha funcionado desde moviles java de antaño,  pasando por ds, wii, ...) esta basado en un solo xls (pero puedes trasladarlo a xml si lo ves mas sencillo).
La primera fila del XLS contiene las cabeceras de las columnas
La primera columna un ID. Este id tiene que respetar las normas de nomenclatura de las "variables" en c++, porque lo meteremos despues en un enum en un header.
Despues puedes poner alguna columna especial. Yo por ejemplo utilizaba la segunda columna como numero maximo de caracteres, de forma que al "compilar" el XLS con la aplicacion se comprobaba que ninguna traduccion superaba ese maximo.
El resto de columnas corresponden a los idiomas.
Cada fila entonces sera (por ejemplo):

Código [Seleccionar] Expand

ID | [COLUMNAS ESPECIALES] | ES | EN | FR | DE | IT |...

Para "parsear" el XLS puedes utilizar cualquier cosa, yo personalmente utilizaba una modificacion en C# de un codigo que encontre en codeproject.
La idea es que la herramienta lee el XLS y genera un header (".h") parecido a esto:

Código [Seleccionar] Expand

// ... header guard, etc.
namespace Locale
{
enum Enumerations
{
  TITLE_ID = 0,
  NEW_GAME_ID = 1,
  CONTINUE_GAME_ID = 2,
  ...
};
}

Por otra parte, la herramienta debe generar un binario por cada idioma (por ejemplo: es.locale.bin, en.locale.bin, ...), aunque luego podrias empaquetar en un archivo más grande si utilizas lzma, zlib o lo que sea.

Para usarlo, seria remplazar (por ejemplo):

Código [Seleccionar] Expand


...
mainMenu.set_title( "EL JUEGAZO" );
mainMenu.add_option( "Nueva Partida", &new_game_callbak );
mainMenu.add_option( "Continuar Partida", &continue_game_callbak );
...


por

Código [Seleccionar] Expand


...
mainMenu.set_title( g_localeMngr.get_string( Locale::TITLE_ID ) );
mainMenu.add_option( g_localeMngr.get_string( Locale::NEW_GAME_ID), &new_game_callbak );
mainMenu.add_option( g_localeMngr.get_string( Locale::CONTINUE_GAME_ID ), &continue_game_callbak );
...


Hay estudios (y con juegazos en el mercado) que prefieren que la herramienta directamente edite el archivo "fuente", de una manera parecida a como lo harias por ejemplo con excel.

Para hacer esto es bastante facil con WindowsForms, el dataGrid, y algo de serializacion XML, y en poco tiempo puedes tener un programa de este tipo funcionando. Pero al final la parte de generar el header y los binarios es la misma.

En cuanto los binarios, solo tener en cuenta que deben estar ordenadas las cadenas, conforme el orden de las filas, para que coincidan con los indices del enum. Si utilizas ASCII o UTF-8 no tendrás problemas con el endianess. Debes tener una tabla con la direccion donde empieza cada cadena, esto lo puedes precalcular y guardar en el binario, o crear la tabla durante la carga del binario (ten en cuenta que seguramente tendras un caracter de final de cadena que puedes utilizar para avergiuar la longitud de cada cadena).

Otras opciones se podrian realizar con std::maps, o con hashtables, etc. Pero esta es relativamente sencilla y efectiva.


Me ha quedado un tostón, como siempre ^^
Espero que te sirva de algo al menos.

Un saludo.

No entiendo que quieres hacer exactamente.

¿Quieres un hacer un movieClip (fla o swf) que cargue "dentro de él" otro swf?

Vamos, lo tipico, no? Tienes un frame mas grande (p.e: 800x600) con la cabecera de tu pagina, publi, etc, y dentro tienes otro movieclip (p.e: 640x480) con el juego, no?

No recuerdo muy bien como lo hacia (hace mucho tiempo que no toco AS), pero tenias que crear un movieclip vacio en el swf del "frame principal", y luego creo que habia un load para cargar el swf a partir de una cadena de texto con la ruta. Recuerdo que era bastante facil.

Los problemas que puedes tener son comunicarte con el swf "child", o que al hacer pruebas no te funcione, por los permisos de acceso de tu swf (creo que habia que activar algo para que pueda leer de disco duro si estas haciendo pruebas en local).


Siento no poder ayudarte más,

Un saludo.

No conocia esto del Xamarin, y le echado un ojo a la pagina web y tiene buena pinta.

De todas formas despues de mi "experiencia" con el colector de basura de la maquina mono de novell en la wii, me da un miedo tremendo .NET para runtime. (Para offline tools lo gasto a "mansalva", que ahorra mogollon de curro ^^ )

De echo (y aunque no venga a cuento) estoy pensando desertar de Lua y probar algun lenguaje de script sin heap dinamico de memoria (rollo Pawn/Small-C o alguna implementacion "casera" rollo el DC de Naughty Dog en Uncharted).


Aun asi tiene buena pinta, y es una buena solucion para mantener compatibilidades windows phone / android / iphone ... curioso, si señor ^^