A la hora de crear el servidor, siempre surge la siguiente pregunta: ¿cómo voy a gestionar las conexiones y eventos de los distintos clientes en paralelo? ¿un hilo de ejecución por cada cliente, un hilo por partida, o una thread pool?

Thread pool o "piscina de hilos"

Y la respuesta a estas preguntas es que con el framework RedDwarf, debes olvidarte de ello. RedDwarf te proporciona un motor el cual, efectivamente, es multitarea y multihilo. Pero este núcleo se esconde para proporcionar al programador un entorno que parece monohilo, como si éstos no existieran. Si quieres, puedes olvidarte de todo lo aprendido en el pasado acerca de los hilos, o mejor aún, puedes no aprenderlo para invertir tu tiempo en la verdadera lógica de tu juego.

Por detrás, RedDwarf funciona siguiendo el patrón de diseño Thread Pool, en el cual se crean un número fijo de hilos o “trabajadores” al que se le envían tareas como paquetes de trabajo. La piscina gestionará las tareas y repartirá el trabajo entre los hilos disponibles.  Esto es muy importante ya que esta piscina de hilos determinará automáticamente y en función de las capacidades de nuestra CPU el número de hilos a crear para la ejecución de tareas en paralelo. Vamos, que RedDwarf sacará todo el provecho de tu máquina sin que te tengas que preocupar de programar algo que, seguramente, te traería muchos dolores de cabeza. A esto hay que sumar que si un día decides ejecutar tu servidor en otro PC diferente, la piscina de hilos se adaptará a la nueva CPU al arrancar el servidor. Como muchos frameworks para otro tipo de cosas (Grand Central Dispatch, de Apple o Qt por ejemplo, de Nokia, también libre) han ido marcando, el futuro de la programación en paralelo son las tareas, no los hilos. Os dejo un video que lo explica muy bien, aplicado en Grand Central Dispatch. Aprovecho para recordar que en el Podcast 4 hablé de GCD en la sección de tecnología.

Vale, perfecto y maravilloso. ¿Pero cómo se utiliza esta piscina en un servidor que utilice RedDwarf? El gestor al que nos tendremos que dirigir será TaskManager (Gestor de tareas, no podía tener un mejor nombre), el cual nos permitirá programar tareas para su ejecución basándonos en un tiempo máximo de espera. Un ejemplo sería: “TaskManager, por favor, comienza a prepararme un café de aquí a un segundo” o también, por supuesto, “ahora mismo”. Otra utilidad que nos ofrece es la de programar tareas periódicas, que tengan que repetirse cada cierto tiempo (en un MMORPG, un buen ejemplo sería el amanecer y el anochecer, ejecutados cada 24 horas). Nosotros definiremos las tareas implementando la interface Task, la cual nos obligará a incorporar un método run() a nuestra clase. La piscina de hilos ejecutará este método el cual, al finalizar, indicará que se ha completado la tarea (fijaos en la imagen de arriba).

Resumiendo:

• Acceso al TaskManager: AppContext().getTaskManager();
• Servicios del TaskManager: schedulePeriodicTask() y scheduleTask()
• Definición de taras: interface Task

¡Espero que os haya parecido interesante!

Links: RedDwarf, ProjectDarkstar

Voy a analizar 5 áreas distintas en las que este framework nos facilita la vida: comunicación, hilos, acceso concurrente, persistencia y, por último, escalabilidad. En cada una, explicaré las herramientas de las que podemos hacer uso para ahorrarnos horas y horas de desarrollo, testeo y debug al desarrollar cualquier juego online multijugador.

Comunicación

La comunicación en un videojuego online a través de internet suele ser un tema muy delicado. Una mala implementación hará que el lag se apodere de nuestro juego. Puedes hacerte varias preguntas sobre qué tecnología utilizar: ¿Sockets, RMI,…? ¿No sería más fácil centrarnos en la lógica de nuestro juego? Además, la mayoría de los juegos online se basan en un login, enviar mensajes (atacar, moverse, chat, etc) y una desconexión o logout. Sólo implementar la base para que esto funcione costaría mucho trabajo. RedDwarf nos permite abstraernos de TODA la mecánica de la comunicación por red.

Se basa en tres interfaces por el lado del servidor:

• AppListener: puerta principal para inicializar el servidor y hacer login.
• ClientSessionListener: para atender las peticiones, eventos y mensajes de un cliente.
• ClientSession: para enviar mensajes a un cliente.

Y una clase y una interfaz en el cliente:

• SimpleClient: para hacer login y logout y para enviar mensajes. Representa la conexión de salida.
• SimpleClientListener: recibir mensajes y notificaciones como login y logout fallidos/no fallidos. Representa la conexión de entrada.

La siguiente imagen ilustra el funcionamiento de la comunicación cliente-servidor:

Pero esto no es todo. ¿Qué pasa cuando queremos enviar y recibir mensajes de un grupo de usuarios del juego, pero no de todos? Por ejemplo, un chat de clan, recibir mensajes sólo del área visible del mapa, un juego online basado en diferentes partidas (como un servidor de partidas de poker), etc… Para eso existen los Channels o canales. Los canales se crean en el servidor, el cual puede subscribir/eliminar clientes de un canal, mientras que todo lo que sea enviado al canal por alguien será recibido automáticamente por los clientes suscritos.

Página oficial RedDwarf.

Fuente: ProjectDarkstar/Learn

Si leísteis el artículo anterior de esta serie, os acordaréis que faltan ciertas áreas que no se ven muy cubiertas por esta serie de motores o componentes comerciales: la concurrencia, la conectividad, la persistencia, y muy importante, la escalabilidad. ¿No hay componentes (frameworks) que nos simplifiquen todo esto? ¿frameworks que nos den lo que prácticamente todos los MMORPG necesitan en estas áreas comunes ya hecho y programado? Yo conozco uno, y he alucinado: RedDwarf.

Hasta hace unos pocos días, RedDwarf, como parece que será finalmente el nombre elegido, se llamaba Project Darkstar. Se trata de un proyecto que se inició en el año 1999, y que ha sido desarrollado hasta ahora por Sun Microsystems. La causa del cambio de nombre ha sido el abandono del proyecto por parte de Sun, debido a la compra de esta compañía por parte de Oracle. Ya que se trata de un proyecto abierto, la comunidad está en proceso de relanzarlo. Pero expliquemos mejor qué es esto.

RedDwarf cubre todos los aspectos que he nombrado anteriormente, aspectos complejos comunes a todos los MMORPGs. Para el desarrollador, el problema de la concurrencia quedaría totalmente subsanado: no existen los hilos al usar framework, ni la sincronización, el programador sólo piensa en tareas que RedDwarf se encargará de ejecutar cuando pueda creando los hilos que crea necesarios dependiendo del sistema (núcleos de CPU, etc). Tampoco tienes que encargarte de las comunicaciones: la base ya está programada, y de la forma más eficiente posible. Toda la comunicación entre los clientes y el servidor ha sido simplificada al máximo mediante conceptos como “Channels” o canales de subscripción. Y qué pasa con la persistencia, culpable de los rollbacks (perder cosas cuando te caes del servidor o el servidor se cae) del resto de MMORPGs por una programación no tan óptima: arreglada por completo, no existen los rollbacks ni los “server save”, el servidor siempre está guardado.  Ah, espera, falta la escalabilidad: tan fácil como conectar una nueva máquina, no haría falta reprogramar nada de nada (aunque esto último estaban a punto de conseguirlo en el momento en el que Oracle anunció que dejaba de apoyar al Project Darkstar).

Este proyecto, en la versión 0.9.11 es totalmente funcional, de hecho existen empresas que han desarrollado juegos online comerciales utilizándolo. Las posibilidades son tremendas, y la comunidad lo sabe, por lo que muy seguramente RedDwarf, como ahora ha sido bautizado, tenga un buen futuro. Si os interesa, deberíais acudir a la página de  Project Darkstar para buscar información, ya que el traslado a RedDwarf comenzó hace sólo 6 días. Por último comentar que estoy migrando un juego de mus online a este framework, y espero poder contaros más al respecto, aunque puedo decir ya que es tremendamente fácil utilizarlo y simplifica muchísimo el desarrollo de este tipo de sistemas.

Como visteis en el primer artículo, me interesan mucho los MMORPG, y muchas veces pienso en intentar trastear para crear algo. Pero el desarrollo de MMORPG no es nada fácil: entran en juego multitud de áreas de la informática, y es necesario tener mucha habilidad en todas ellas para crear algo utilizable. Como la mayoría sabemos, un MMORPG suele estar alojado en un servidor al que se conectan multitud de clientes que toman parte en un mismo juego, del cual pueden desconectarse para luego conectarse otro día sin perder la turbo-espada que consiguieron. Así que tenemos:

• Concurrencia: el servidor debe procesar tareas en paralelo por cada jugador, lo que precisa de programación multihilo, y la sincronización entre estos hilos lo cual complica la programación.
• Conectividad: En un MMORPG, la respuesta al usuario debe ser rápida o aparecerá el lag, por lo que es posible que deban utilizarse técnicas complejas para simular la respuesta instantánea del servidor y no saturar la conexión si queremos ser capaces de soportar muchos usuarios. Por ejemplo, es posible que el juego en nuestro pc, cuando queramos avanzar hacia adelante con nuestro personaje, nos haga creer que hemos avanzado sin esperar a que el servidor le diga “Sí, puedes ir para adelante”. Luego si resulta que el servidor le dice que no puede, veremos una especie de rebote de nuestro personaje hacia una posición anterior (efectos del lag).
• Persistencia: si queremos que los jugadores no pierdan lo que consiguen entre conexiones al juego, necesitamos algún lugar donde guardar su estado. Normalmente se utilizan bases de datos.
• Gráficos: los jugadores cada vez son más exigentes con los gráficos, tienes que ser un experto en DirectX, OpenGL, e infinidad de herramientas de modelado 3D.
• Físicas: Si quieres que tu mundo se parezca al mundo real… tendrás que implementar las leyes que rigen nuestro mundo. Estaría bien que repasaras lo que estudiaste sobre la gravedad, las colisiones entre sólidos rígidos. Ufff…. suena jodido.
• Audio: y encima contratar a músicos que creen la música para tus escenarios, o buscarte en internet ruidos que se parezcan a las pisadas sobre un suelo de madera. Ah, y sobre un suelo de hormigón, y sobre el barro…
• Escalabilidad: Vaya, tu juego va tan bien que ya vas por los 1000 usuarios, pero el servidor ya no es capaz de funcionar bien y se te quejan por el lag. Tienes que añadir un nuevo servidor. Muchos juegos lo que hacen es crear un nuevo servidor con el mismo juego, pero digamos “paralelo”, en realidad no es el mismo mundo. Seguro que se os ocurren ejemplos (OGame, el propio Tibia…). Pero esto, claramente, no es lo ideal. Si quieres poder aumentar la capacidad de un solo “mundo” o “juego”, tienes que conseguir que tu programa se distribuya entre distintos ordenadores el solito. ¿Parece que se complica verdad?

Creo que ya se entiende mejor el título del post: desarrollar un MMORPG es una tarea muy, muy complicada y que requiere de muchas horas de trabajo y esfuerzo, ademas de mucha experiencia y dominar muchos temas distintos. Ya no basta con un MMORPG en 2D como el Tibia, ahora como no saques un WoW o Lineage, te será difícil conseguir usuarios. Pero… ¿puede esto cambiar en el futuro?

Sin duda, sí, es el camino que se ha seguido desde el principio: motores gráficos, motores físicos… todos hemos escuchado hablar de ellos. Al final, no son más que piezas ya hechas, altamente reutilizables, para hacer cosas comunes a la mayoría de juegos: en muchos de ellos necesitas calcular una colisión entre objetos, la fuerza de la gravedad, los tiros parabólicos… por no hablar de los destellos al disparar un arma, los reflejos de luz, etc. Por poneros unos ejemplos, como motor gráfico tendríamos el Unreal Engine y como físico el PhysX. Ya tenemos la física y los gráficos “cubiertos”. ¡Pero todavía nos falta cosas! Atentos a la próxima edición.

¿Qué es un proxy?

Básicamente un proxy es un PC intermediario gracias al cual, en este caso, conseguimos conectarnos a internet. Seguro que muchos ya habréis oído hablar sobre proxys, ya sea porque haya uno en vuestro lugar de estudio o en el trabajo. Las razones para incluir un proxy son muchas; es gracias a los proxys que no podemos utilizar redes P2P como emule o jugar a minijuegos en los ordenadores del trabajo o colegio. Al configurar un proxy en nuestro ordenador, todo el tráfico de internet debe pasar por él. Eso le permite controlar este tráfico, pudiendo capar P2P, ciertas páginas web o incluso puede ser utilizado con fines menos honestos como fisgonear datos privados. En una segunda o tercera parte hablaré sobre cómo saltarse un proxy.

¡¡Ya se ve la solución!!

Ahora bien, si tenemos un ordenador con conexión a internet que queremos compartir, podemos aprovechar los proxys: pasamos todo el tráfico al PC que tiene internet como si fuese un proxy, y el se encarga de él. Lo único que necesitamos es configurar este PC correctamente y también hacer algunos cambios en los ordenadores que vallan a conectarse a él. Existe un programa muy bueno que convierte a un PC en un proxy en cuestión de unos pocos clicks: se llama AnalogX.

Instalando y configurando

La instalación de AnalogX es muy, muy sencilla. Es el típico “next, next, next, next…”. Lo importante es, cuando esté instalado, hacer click en su icono en la barra de herramientas y darle a Configure. Hay que asegurarse que todos los servicios estén en On.

Ahora viene la configuración, la parte algo más complicada si no estamos acostumbrados a las IPs y tal. En el PC que hace de proxy y está conectado a internet, vamos a inicio->ejecutar… y escribimos cmd. Escribimos ipconfig /all y apuntamos la dirección IP, la máscara de subred y los servidores DNS. En los PCs que van a conectarse al proxy, hacemos click derecho en el icono de conexión, le damos a estado y luego a propiedades. Aquí elegimos Protocolo TCP/IP y le damos a propiedades. Seleccionamos Usar la siguiente dirección IP e introducimos los siguientes datos:

• Como dirección IP, la misma que el PC proxy sumándole uno al último número (basta con que el último número sea diferente)
• Como máscara de subred, la del PC proxy
• Como Puerta de enlace, la IP del PC proxy
• Como servidores DNS, los del PC proxy

Aceptamos y, lo último que nos queda por hacer, acudimos a las opciones de Internet Explorer y en la ficha Conexiones le damos a Configuración de LAN. Aquí activamos la opción Utilizar un servidor proxy y rellenamos como sigue, teniendo en cuenta que como dirección, tenemos que poner la dirección IP del PC proxy (puerto 6588).

Hay que configurar de la misma manera Firefox, Chrome y cualquier programa que se conecte a internet para que use el proxy. El caso es que si se configura IE, muchos de ellos funcionarán automáticamente. Y listo, debería funcionar!!

Espero que os ayude, en la próxima parte comentaré como recuperar contraseñas WiFi WEP si se nos ha olvidado o cómo testear la seguridad de nuestra red WiFi.

¿¿Pero cómo lo hacemos??

Aunque me gustaría mucho, todavía no tengo buenos conocimientos de desarrollo web, así que lo primero que le pregunté a google fue “grabar audio en PHP”. Esto es un poco burrada, dado que el código PHP de una página web es siempre ejecutado por el servidor que aloja a la misma, por lo que no puede acceder al hardware (en este caso el micrófono) de la máquina cliente. Había que mirar otras opciones.

Y entonces fue cuando leí la opción de usar Flash. Pensé que tenía sentido, al fin y al cabo para escuchar los podcasts, podemos hacer click en el botón y escuchar sin descargar nada ni salir del navegador. Así que de la misma manera debería permitirnos añadir el fabuloso botón REC para dejar podcomentarios por aquí y por allá.

Flash

Pues bueno, parecía que se vislumbraba ya una posible forma de crear este botón, pero hay más peros. Cuando hacemos click en el botón PLAY para escuchar un podcast, estamos utilizando flash player para reproducir un archivo mp3 sin tener que esperar a descargarlo entero. Flash Player permite que veamos la aplicación que reproduce este mp3, pero ahora queremos que esta aplicación grabe uno. Y eso no es posible sin utilizar un servidor flash, servidor el cual dota a estas aplicaciones de muchísimas opciones más. Y entre ellas se encuentra la posibilidad de grabar audio a través del micrófono.

Servidor Flash

Me ha costado bastante tiempo entender el porqué de la necesidad del servidor flash, y no se si lo he entendido del todo bien. Tampoco supe del todo bien cómo funcionaba en general este servidor hasta que encontré el esquema de la derecha. La aplicación flash sigue siendo servida por el servidor web, pero cuando ésta lo requiere, se conecta al servidor flash. Flashcomguru aclara bastantes dudas.

Adobe distribuye, aunque no gratis,  Flash Media Server. Pero existe un proyecto de servidor flash sobre Java de código libre llamado Red5, totalmente gratuito y con bastantes tutoriales.

¿Alguien interesado?

Youtube ha anunciado que dejará de dar soporte a internet explorer 6, y por ahora si entras con dicho navegador, obtendrás una advertencia de que actualices tu navegador a uno más moderno. Parece ser que el explorador más usado de todos los tiempos va a ser jubilado, de lo que se alegrarán muchos programadores web.