JavaHispano Podcast - 062 - Programación de Videojuegos

Publicado un nuevo número del podcast de javaHispano. En esta ocasión participaremos Fabian Nuñez, Luis Javier Lopez y Jorge Rubira. Los tres hemos participado de alguna manera en el desarrollo del framework de la JavaCup en alguna de las tres ediciones y hablaremos de ello. Fabian fué el creador del visor de la javaCup 2008 y sus preferencias son tareas gráficas, artísticas y de diseño. Luis trabajó como ingeniero de localización durante dos años y medio en Electronic Arts, autor del blog hardprogrammer y actualmente imparte un master de juegos para moviles. Jorge creó el primer framework de la javaCup para la 2007, colaboró con la revista Solo Programadores publicando screencast donde se explica como programar videojuegos.

Adicionalmente, realizaremos una introducción a los videojuegos, clasificacion de estos, explicaremos que existen otro tipo de juegos al margen de las consolas de juegos y daremos nuestra opinión sobre las preferencias al desarrollar un juego con pocos recursos económicos.

Por otra parte, hablaremos de técnicas o conceptos básicos que el programador de videojuegos 2D debe conocer: Sprites, planos de scroll (Scroll parallax), eliminar parpadeo (Doblebuffer), detección de colisiones (Bounding box o sphere), reproducción de música, detección de teclas.

Links de interés:

• Finales de la javaCup: 2007, 2008, 2009 
• Librería gráfica utilizada para javaCup: Slick
• Librería para reproducir audio en java: jLayer
• Blog de Luis. Videojuegos desarrollados por sus alumnos
• Blog de Jorge.

Ejemplos de algunas técnicas:

• Ejemplos de Sprites.
• Ejemplo de planos de scroll: Ejemplo1, Ejemplo2
• Ejemplo de doblebuffer.
• Lenguajes comentados para programar videojuegos comerciales: JME, XNA, C++, Flash, SDK iPhone, Android. (Existen más. Estos son solo los comentados)
• Videoconsolas y periféricos originales: WII, Microsoft Natal, Guitar Hero Batería y DJ,

Google intentara reemplazar el protocolo HTTP con SPDY

Como parte de la iniciativa de  Google “Let's make the web faster", desde hace algún tiempo están trabajando en un nuevo protocolo  llamado SPDY (se lee SPeeDY) que tiene el objetivo de reemplazar  HTTP por ser un protocolo que genera muchas latencias y que no se adapta a algunos de los requerimientos de las aplicaciones modernas.

En pocas palabras SPDY es  un protocolo que funcionara sobre SSL, permitirá un número ilimitado de  peticiones concurrentes  en la misma conexión TCP, eliminara headers innecesarios,  siempre comprimirá los headers que se envían desde/hacia el cliente y permitirá al servidor iniciar peticiones sin la necesidad de que exista una petición previa del cliente (server push real).

 Los objetivos principales de este protocolo es reducir en un 50% el tiempo de carga de una página web, evitar que los autores de contenidos web tengan que modificar algo, hacer que la web sea segura por defecto (SSL como protocolo de transporte)  entre otras.

Actualmente existe una implementación experimental de un servidor web que utiliza este protocolo y también una versión interna de Google Chrome  llamada Flip que permite comunicarse al servidor web utilizando SPDY. El código fuente de Flip ya está disponible como open source y dentro de poco harán lo mismo con el servidor que implementa SPDY.

Todos sabemos que gracias a varios productos y tecnologías de Google el mundo web ha mejorado muchísimo (el buscador, gmail, docs, chrome, gwt, clousure, gae, etc) y al parecer todavía no se les acaban las ideas para seguir haciendo que la web sea más rápida y mejor. A mi realmente me parece muy bien que se intente reemplazar HTTP que  es el único obstáculo restante  que limita la evolución de la web, aunque no será nada fácil ni pasara en un futuro cercano, obviamente desde un punto de vista paranoico: ahora si Google dominara el mundo ;-)    "eso si SPDY + Web2.0 = Web3.0"

JetBrains anuncia YouTrack 1.0, un sistema de "bug and issue tracking"

JetBrains acaba de anunciar la primera versión estable de su último producto: YouTrack, un sistema de "bug and issue tracking". La principal diferencia de esta herramienta con otras muchas similares que existen en la actualidad es que hace un uso intensivo del teclado, proporcionando un montón de funcionalidad basada en cadenas de texto (comandos) y nemotécnicos. Aquí tenéis unos ejemplos del tipo de cosas de las que hablo:

 

 

Este tipo de herramientas estilo "Emacs" pueden incrementar considerablemente la productividad de la gente que se pasa un montón de horas al día en ellas. Sin embargo, su curva de aprendizaje no suele compensar a la gente que las usa más eventualmente.

Sin duda, es una herramienta orientada a resultar atractiva a los usuarios de IntelliJ, un entorno de desarrollo donde también se hace uso intensivos de comando del teclado. El precio de este producto es de 1200 $.

¿Creéis que va a tener un impacto considerable este sistema de gestión de incidencias y bugs can basado en el teclado?

Apache Solr 1.4: motor de búsqueda 100% java

Apache ha publicado la versión 1.4 de Solr, un motor de búsquedas web hecho 100% en java. Está basado en Apache Lucene y puede ejecutarse en un contenedor web como Tomcat. Entre las características de este servidor destaca su servicios de administración, cache, replicación, índices, capacidad para procesar documentos de texto rico como Word y PDF...

En esta nueva versión se ha incrementado el rendimiento del indexado y la búsqueda; se ha simplificado las capacidades de replicación; se ha mejorado la integración con bases de datos; se ha añadido la capacidad para manipular documentos de texto rico, y se proporcionan múltiples plugins nuevos para extender su funcionalidad por defecto. 

JDeveloper vs NetBeans (y encuesta del mes)

Shay Shmeltzer ha publicado una entrada en su weblog donde analiza ciertos datos bastante sorprendentes relativos al uso de JDeveloper y NetBeans. Primero, según una encuesta realizada por SD Times, la cota del mercado de ambos entornos de desarrollo en 2008 era muy similar: 24,4% para el entorno apoyado por Sun, y 20,4% para el apoyado por Oracle.

Por otro lado, compara las tendencias que Indeed.com (un portal de ofertas laborales) ofrece para ambos entornos de desarrollo, donde se muestra que desde el año 2005 hasta el presente el entorno de Oracle siempre ha tenido una mayor demanda que el de Sun. 

 

Por último, compara el tráfico en los foros oficiales de Netbeans (de 10 a 15 nuevas entradas por día) y de JDeveloper (unas 80 nuevas entradas por día). Todos estos indicadores parecen mostrar que la base de usuarios de JDeveloper es bastante superior a lo que uno pudiera pensar.

Y como lo bueno de las estadísticas es que hay para todos los gustos... en la encuesta de este mes del portal estamos preguntando precisamente acerca de los entornos de desarrollo que usa cada usuario. En nuestra comunidad, desde luego que lo apuntado por Shmeltzer no se cumple: Netbeans y Eclipse son completamente dominantes, están cuello con cuello y cada uno parece tener en torno al 45% de la comunidad.

 

¿Qué lectura hacéis de los datos que proporciona Shmeltzer en su blog? En el caso de que éstos datos realmente reflejen el uso de ambos entornos de desarrollo ¿creéis que el futuro de Netbeans peligra si es adquirido por Oracle?. Personalmente, siempre había asumido que el futuro de Netbeans estaba asegurado porque tenía una base de usuarios muy superior a la de el entorno de Oracle... pero si esto no es así quizás Netbeans sea una víctima de la adquisición.