Blog De Jose Alfonso Suárez > Programadores y horarios. El karma del programador
Muy buen articulo de José Alfonso Suárez sobre la figura a del programador y sus hábitos y por qués de su conducta y forma de vida. Interesante lectura sobre todo para los no programadores 
En la web de los chicos de Anait Games me encuentro con el siguiente articulo que merece la pena que os leáis. Se trata de un pequeño experimento social que han realizado lo desarrolladores de un juego, Game Dev Tycoon, juego que precisamente simula un estudio desarrollo de juegos y sus procesos (si habeis jugado al Game Dev Story en iOS o Android sabreis como es este juego), quienes han subido una versión modificada a las redes de descarga para estudiar la reacción de los jugadores al encontrarse con que sus creaciones son pirateadas salvajemente lastrando así los beneficios que deberían obtener en la partida.
Sin más os dejo con el enlace al articulo:
Os dejo por aquí un interesante post-morten del clásico y legendario DooM de la mano de Tom Hall y John Romero donde cuentan detalles de la creación de uno de los juegos que más ha influido en las generaciones actuales.
GDC Vault – Classic-Game-Postmortem – DooM
Betabeers es un evento sobre desarrollo en general que se lleva celebrando ya durante 2 años en varias ciudades españolas y en algunas fuera de España. Es un evento donde se tratan tanto tecnologias como proyectos que se van presentando al publico y donde sobre todo se puede hacer networking y conocer gente afin a gustos e intereses profesionales.
La proxima edicion de Betabeers Madrid van a dar una charla sobre Corona SDK, un popular motor de desarrollo de juegos para moviles en la linea de Unity3D. Parece ser que habra tambien un sorteo de licencias de este motor, valoradas en más de 300€.
La inscripcion a Betabeers es totalmente gratuita pero es necesario confirmar asistencia dado que el aforo es limitado.
Informacion del evento:
Aprovecho tambien para informaros que si estais interesados podeis hablar con el organizador para presentar y exponer proyectos, juegos incluidos, o incluso solicitar gente. Todo ello desde la propia pagina de Betabeers.
Nos vemos alli 
Un año más se celebro el evento sobre informática y videojuegos retro por excelencia, RetroMadrid. Este año ha sido mi 3ª vez y desde luego ha sido la mejor de las 3. El evento, como el año pasado, se ha celebrado en las instalaciones de Matadero, en Legazpi.
Este año la afluencia de gente ha sido todavía mayor que el año pasado, resultado un poco agobiante moverse por el recinto, aunque es un punto bueno ya que significa que el evento cada vez atrae a más gente. Como otros años, el recinto estaba repartido en varias áreas como la de los clásicos Sinclair Spectrums, Amstrad CPCs o los Commodores 64, Commodore Amiga y Amiga PCs, que comparten misma área demostrando su poderío videojueguil con juegos clásicos así como con desarrollos actuales para tales maquinas, trabajos como los que realizan los chicos de RetroWorks por ejemplo, o los Amiga PC concretamente luciendo palmito demostrando su poderío multimedia que tan antaño los hizo famosos frente a las maquinas de la época. No solo podíamos ver modelos convencionales de dichas maquinas si no alguna modificación curiosa como la versión LEGO de un Commodore 64 que fabrico uno de los presentes.
Trabajando en MonoGame sobre Windows nos encontramos con que el proyecto que se genera con la plantilla de proyecto que ofrecen para Visual Studio es un proyecto de Aplicación de consola en vez de Aplicación para Windows. Esto es por que MonoGame genera la ventana del programa mediante el framework de OpenTK (Open Tool Kit Library) generando así una ventana externa, esto es similar a lo que hace XNA mediante la API de Windows. El problema que esto conlleva es que al ejecutar el juego nos aparecerá la ventana de consola, que MonoGame utiliza como salida de depuración, y la ventana del juego. El problema es que icono del proyecto se aplica a la ventana propia de la aplicación, la consola de texto, y no a la ventana del juego, la que genera OpenTK.
Lo primero que se nos ocurriría seria configurar el proyecto de Visual Studio como proyecto de Aplicación para Windows desde la ficha de propiedades del proyecto. Esto funciona ya que aunque no agreguemos un formulario WinForm al proyecto MonoGame sigue funcionando sin problemas, OpenTK genera la ventana igualmente, pero al ser una ventana ajena al propio proyecto de Visual Studio el icono no se asigna, provocando que tanto la ventana como la instancia en la barra de tareas aparezca sin icono asignado (aparecerá el icono por defecto para los ejecutables del sistema). Sin embargo esto es fácil de solucionar mediante unas pocas llamadas a la API de Windows en la inicialización de nuestro proyecto.
Lo primero que haremos sera configurar el icono como recurso incrustado (embebed resource) en el inspector de Visual Studio:
Agregamos después la referencia al ensamblado System.Drawing al proyecto:
Lo siguiente es agregar las declaraciones de la API de Windows necesarias para nuestro propósito en el código de la clase principal del proyecto, por defecto Game1:
// Configuramos el codigo de forma que solo se compile para la plataforma Windows:
#if WINDOWS
[System.Runtime.InteropServices.DllImport("User32.dll", EntryPoint = "FindWindow")]
public static extern Int32 FindWindow(String lpClassName, String lpWindowName);
[System.Runtime.InteropServices.DllImport("user32.dll", EntryPoint = "SendMessageA")]
public static extern Int32 SendMessage(Int32 hWnd, Int32 Msg, Int32 wParam, Int32 lParam);
private const Int32 WM_SETICON = 0x0080;
private const Int32 ICON_SMALL = 0;
private const Int32 ICON_BIG = 1;
#endif
Una vez agregado el código anterior solo debemos realizar la inicialización desde el metodo Initialize (recomiendo hacerlo antes de cualquier otra llamada en el código del método Initialize):
// Cambiamos titulo a la ventana de OpenTK:
this.Window.Title = "MonoGame test";
#if WINDOWS
// Obtenemos los datos del icono embebido en la aplicación:
System.Reflection.Assembly assembly = System.Reflection.Assembly.GetExecutingAssembly();
System.IO.Stream stream = assembly.GetManifestResourceStream(assembly.GetName().Name + ".Icon.ico");
System.Drawing.Icon icon = new System.Drawing.Icon(stream);
// Asignamos el icono del programa a la ventana de OpenTK:
// this.Window.Handle en MonoGame no devuelve idenficador de la ventana, así que usaremos FindWindow de
// la API de Windows para localizarla mediante el titulo que le asignamos antes:
SendMessage(FindWindow(null, this.Window.Title), WM_SETICON, ICON_SMALL, icon.Handle.ToInt32());
#endif
Ahora si ejecutamos el proyecto veremos que la ventana de MonoGame se muestra con el icono al igual que la instancia del programa en la barra de tareas.
Espero que este truco os pueda resultar de utilidad.
Salu2…
Una de las cosas que siempre se me han resistido a la hora de intentar hacer un juego plataformas 2D, y como a mi a mucha más gente, es el implementar correctamente las colisiones y su respuesta (el detectar paredes o suelos y saber ubicar correctamente el objeto cuando colisiona con el entorno).
Cierto es que hoy día existen muchas alternativas para evitar programarte un sistema de colisiones y respuesta para un juego de plataformas. Existen varios motores de físicas 2D para múltiples plataformas y lenguajes, Box2D por ejemplo, que lo implementan varias herramientas de desarrollo de juegos como Stencyl y que es muy popular en juegos Flash, o Farseer Physics Engine para XNA, que se ha usado en varios proyectos de XBox360 y Windows Phone y que están portando a MonoGame. El problema, al menos con Farseer Physics Engine que es al que le dedique tiempo en su momento, es que me resulto extremadamente complejo de implementar y configurar todos los parámetros y propiedades que tiene así como lograr ajustar la escala de medida del sistema de físicas con la escala en pixeles en pantalla para poder dibujar un sprite acorde con su representación física. En definitiva, una API muy poco amigable para la mayoría de la gente.
En mi ultima incursión con MonoGame para tratar de llevar a cabo un prototipo del Proyecto TLSA basado de lo ultimo que tenia programado en XNA para Windows Phone 7, decidi volver a intentar desarrollar desde cero el sistema de colisiones que hice para el proyecto GreyInfection. El resultado es un sistema muy sencillo y muy básico de colisiones entre cajas (colisiones perpendiculares, nada de ángulos ni rotaciones), sin simulación de gravedad ni fuerzas, con su sistema de respuesta para que un objeto móvil sepa responder a una colisión con otro objeto de la escena. El sistema incluye también un trazador de rayos, para calcular trayectorias para disparos o bien para localizar objetivos en un rango de visión por ejemplo. Este sistema serviría tanto para juegos de plataformas como juegos de vista superior, en definitiva, cualquier juego 2D que necesite calcular colisiones y determinar su respuesta.
El proyecto, publicado en mi repositorio de GitHub, incluye un ejemplo practico donde se ve el sistema en acción, con el código comentado.
2DCollisionSample en GitHub: https://github.com/VisualStudioEX3/2DCollisionSample
El código esta programado de forma que no debiera ser un problema para portarlo a otros lenguajes y frameworks.
Salu2…
P.D.: Si este sistema te parece excesivamente sencillo y buscas implementar algo más avanzado echa un ojo a los turoriales de Metanetsoftware, creadores del juego N, con código fuente y demostraciones en vivo de las tecnicas:
N tutorial A – Basic Collision Detection and Response
N tutorial B – Grid-Based Collision Detection and Raycasting
