Gracias por el link!
Algunas preguntas mas:
Es este el foro mas poblado de españa?
Hay canales de irc en español de desarrollo de videojuegos?

Hola! Soy nuevo por aquí y quería saber un poco mas sobre la industria de videojuegos en España, puntualmente:

Qué comunidades online existen (además de Stratos) y cuales son las mas activas en el area de desarollo de Video Juegos?
Qué instituciones existen para agrupar a las empresas desarrolladoras?
Qué eventos se realizan anualmente donde se pueda concurrir a ver el estado de la industria y conocer a las empresas y sus productos?
Dónde se pueden obtener listado de empresas activas e informacion de contacto?
Qué instituciones ofrecen capacitación y formacíon para trabajar en esta industria?
Çómo puedo averiguar en que niveles esta el gobierno español involucrado en la industria y en que forma fomenta su crecimiento? (subsidios/promocion/beneficios/etc.)

Muchas Gracias!

nada va a sonar mas 8 bits que esto:

http://famitracker.shoodot.net/

Mi pregunta es: De que manera se aplican estos conocimientos a la programacion de videojuegos en motores graficos recientes? Actualmente estoy programando con unity engine y este maneja el codigo de forma bastante particular, centrandose en la programacion de scripts para acciones concretas. Cualquier comentario que se os ocurra al respecto, o links a documentacion relacionada, os lo agradeceri mucho.

UML (casos de uso, diagramas, etc) es extremadamente util para plasmar en formal visual el comportamiento de un programa, su manejo de datos y su interaccion con el usuario. Tambien provee una nomenclatura muy comoda para debatir conceptos con otros programadores.

El problema es que estas herramientas se quedan cortas en la mayoria de los videojuegos, dado que la interaccion del usuario (jugador) con el sistema (juego) es mas compleja e intrincada. Algunos aspectos de UML siguen siendo utiles para planear areas como inteligencia artificial, networking o bases de datos, pero creo que no existe ninguna empresa de desarrollo de VJ que utilice UML en su totalidad.

En videojuegos, hasta donde vi,  se suele utilizar mas patrones (design patterns) que otra cosa, pero creo que la realidad es que dado la naturaleza descartable de los mismos (y la dificultad de estipular plazos de entrega coherentes con algunos clientes), es mas productivo crear codigo deshechable que funcione que perder tiempo en perfeccionar una arquitectura.  
Esto lo pude corroborar charlando con ingenieros en sistemas que trabajaron en EA (y con otros en japon), donde la directiva es reusar lo minimo indispensable entre cada proyecto (partiendo de una base solida de middleware) y comenzar de eso, dado que esto facilita al planeamiento y estimacion de tiempos.. aun si es mas costoso.

[Algunos Problemas..]

Hola! Aca les paso como funciona mi sistema de undo/redo, citado de cuando lo postie en el foro de ADVA, esta en C++ pero nada impide hacerlo en java, C# u otro lenguaje (de hecho, el mas dificil es C++). Es muy practico, se usa muy poco codigo y no requiere escribir clases para cada comportamiento (template magic), pero puede llevar unas leidas entenderlo.
Lo utilice en proyectos importantes y doy fe que es muy practico, pero probablemente hay que pensar hacer las APIs para que sean compatibles. Espero que sea de utilidad!

La alternativa que planteo se basa en usar dynamic typing en los lenguajes que lo soportan, o variants/template magic en C++.
La idea es que, en vez de crear una clase por cada operacion, hay que hacer que cada comando recuerde una lista de llamadas a funciones/metodos con sus respectivos parametros. Si el codigo esta bien encapsulado, esto deberia funcionar en la mayoria de los casos (o todos). Ejemplo:

undo_redo->begin_comand()
undo_redo->add_do_method( sprite, &Sprite::set_pos, 20, 20 );
undo_redo->add_undo_method( sprite, &Sprite::set_pos, 5, 5);
undo_redo->end_command();

Y listo! Esto es muy comodo porque sirve para modificar codigo existente para que pueda hacer undo/redo, sin tener que reencapsular todo el codigo en clases o comandos.

Algunos Problemas..

Un problema comun al hacer un sistema de undo/redo es que hacer cuando hay que poner en un stream, nuevas instancias (o borrar existentes).
Lo mas comodo es guardar comandos trabajando sobre punteros, asi que lo ideal es no guardar comandos que "crean" instancias, sino crear las instancias de forma externa y luego usarlas en comandos, ejemplo:

Se intenta crear un sprite y ponerlo en el sprite_manager:

sprite = new Sprite;

undo_redo->begin_comand()
undo_redo->add_do_method( sprite_manager, &SpriteManager::add_sprite, sprite );
undo_redo->add_undo_method( sprite_manager, &SpriteManager::remove_sprite, sprite );
undo_redo->add_do_reference(sprite);
undo_redo->end_comand();

En C o C++ el comando tiene que guardarse el puntero a sprite, ya que si en algun momento el usuario decide hacer undo, y luego proceder de otra forma, la referencia al sprite se va a perder (a menos que sea un autopointer o un lenguaje dinamico) y debera ser borrado (con delete).

De forma opuesta sucede cuando se retira un sprite y se borra:

undo_redo->begin_comand()
undo_redo->add_do_method( sprite_manager, &SpriteManager::remove_sprite, sprite );
undo_redo->add_undo_method( sprite_manager, &SpriteManager::add_sprite, sprite );
undo_redo->add_undo_reference(sprite);
undo_redo->end_comand();

En este caso "sprite" se guarda como undo reference. Esto sucede porque las listas de undo/redo son te tamanio fijo (ejemplo, hasta 50 operaciones) y cuando los comandos llegan al final de la lista, son eliminados. De esta forma, un objeto que fue removido, es realmente eliminado cuando el comando se elimina.