¡Feliz 2009!

Último día del año, y nuestro post número 100, sirven para felicitarte las fiestas y un próspero 2009. Por nuestra parte, esperamos seguir progresando hacia el éxito empresarial, trabajando duro en nuestros proyectos y metas. Además, tenemos la intención de volver a dar actividad al blog, que ha sufrido este mes una menor frecuencia de actualización, debido en parte a la concentración de esfuerzos en WoD. Como artículos inminentes, dejamos dos, la valoración de 2008 y la previsión de objetivos para el nuevo año.

¡Feliz 2009!

Artículos recientes relacionados:


El sistema multi – idioma de Earwyn / WoD

En la mayoría de aplicaciones, incluidas las basadas en entorno web, los detalles pueden complicar mucho el desarrollo / implementación de un proyecto. Cuanto más refinados están, más dificultades o trabas van apareciendo. E incluso algunas de ellas, se tornan insalvables. El sistema multi – idioma de Earwyn, que da soporte a Win or Defeat, es capaz de manejar un número ilimitado de idiomas conviviendo en el mismo servidor (o en diferentes, si se necesita), haciendo uso de base de datos, ficheros php, ficheros de texto…, pero para llegar a la versión actual, hubo que resolver varios problemas y optar por algunas soluciones a ellos.

La parte más básica del sistema que permite el multi – idioma no supuso mucha complicación. El sistema de plantillas reconoce tags asociados a literales, definidos en ficheros .php, donde a través de variables se declaran la traducción para ese idioma. Es decir…

  • Existe un fichero .php por cada idioma, llamado con el esquema cod.php, donde cod es el código de idioma. Earwyn sabe qué fichero cargar según el idioma marcado por el usuario, haciendo un include de él.

$GLOBALS["TXT_MY_TEXT"]=”Este es mi texto, definido en sp.php”;

  • En la plantilla .html escribimos algo como:

….<body>¡txt_my_text!</body>…

  • Y cuando la plantilla se carga, el framework sustituye el tag marcado entre exclamaciones por su texto equivalente, definido en el fichero de idioma incluido.

….<body>Este es mi texto, definido en sp.php</body>…

Todos los literales presentes en las plantillas, se traducen con este procedimiento. Pero un juego de idiomas también afecta a otros elementos, como literales más largos, mensajes y avisos del sistema, campos de la base de datos…. En muchas páginas, es corriente ver un formulario, en español, menos las opciones de un select, por ejemplo de países. Ese listado se genera a partir de leer una tabla, en la que se escribe el valor del campo en un idioma. Y no queda del todo bien leer todo en español menos ciertas partes. Para evitar este problema nuestra opción fue implementar un sistema de ficheros de texto asociado a los campos identificadores (id, campo clave), que tradujese en consecuencia. Es decir…

  • La tabla de países tiene un campo id, un número entero, único para cada registro.
  • Existe una carpeta, que a su vez contiene subcarpetas, donde según la naturaleza del dato se guardan los ficheros de texto asociados. En el caso de países, la carpeta es countries.
  • En esa carpeta existen tantos ficheros como países haya en la base de datos, nombrados como id.txt, donde id es el valor del campo id en la tabla. (1.txt, 2.txt, 3.txt…)
  • A través de Earwyn, cuando leemos la tabla y, por tanto, el id, leemos el fichero asociado, sacando el valor traducido para ese campo.

Para la traducción de entidades de la base de datos, usamos este método, siendo aplicable también a otros elementos. Cuando necesitamos un nuevo tipo de mensaje o entidad a traducir, creamos la carpeta con los ficheros de texto y usando las funciones del framework somos capaces de tener cualquier contenido en multi – idioma. Sin embargo, para el informe del resultado de un partido, estamos refinando más aún el proceso, al tratarse de algo especial, que contaremos más adelante.

En cuanto al proceso de inclusión de un nuevo idioma, es muy cómodo; basta traducir esos ficheros e indicarlo en la configuración del sitio.

Artículos recientes relacionados:


El simulador de partidos de WoD

Estos días venimos avanzando a buen ritmo, metiéndonos hoy a refinar el simulador de partidos y todos los procesos relacionados con él, siendo uno de los núcleos del juego e implicando muchos cálculos y complejidad técnica, pues debemos tener en mente gran variedad de aspectos y puntos variables. Y al final del partido, también debemos ser conscientes de las repercusiones en entidades como jugadores, clanes y usuarios.

Fijación de un partido. En el primer prototipo, la fecha era elegida de mutuo acuerdo por los participantes, dentro de unas horas y días preestablecidos. Con el fin de evitar colapsos en el sistema, optamos por que fuera el sistema quién fijara la fecha del partido, repartiendo horarios en función de la carga del servidor. (Es decir, el script se encarga de velar porque no se jueguen muchos partidos a la misma hora, distribuyéndolos en fechas diferentes). Otra dificultad referente a esto es la frecuencia con la que el cron job es lanzado. De forma básica, cada cierto tiempo en función de esos horarios, el cron se lanza, comprobando los partidos que hay pendientes por jugar, de los que hace la simulación. Puesto que según el juego al que pertenezca el partido a disputar (Counter, Day of Defeat ó Team Fortress) las reglas, puntuaciones, clases de jugadores… son diferentes, disponemos de un simulador específico para cada uno. Sin embargo, estos días estamos reestructurando la base, migrando la funcionalidad común a una librería que sirva de fundamento para los tres simuladores, implementando las características extra aparte.

El simulador. Las primeras versiones del simulador apenas controlaban el nivel del equipo y las habilidades de los jugadores en un modo generalizado, haciendo una estimación numérica sencilla. En la actualidad y, todavía con algunos detalles que implementar, el simulador ya puede llamarse tal, dependiendo de:

  • Mapa. Win or Defeat recrea los mapas de los juegos a través de un mapa 2D, implementado en una matriz, como si se tratara de un ajedrez. En ese mapa, se mueven los jugadores de un lado a otro e interactúan entre ellos (disparando, huyendo, matando, capturando banderas / cumpliendo objetivos, volviendo a la vida con el respawn…). Cada mapa tiene características diferentes: dimensiones, muros, paredes, dificultad…
  • Habilidades. Los jugadores tienen ciertas habilidades (puntería, juego en equipo, moral…) y juegan mejor o peor en función de ellas. Durante toda la partida, estas habilidades van sufriendo cambios, según se desarrolle el encuentro y sus acciones. (Por ejemplo, si un mismo jugadores es matado varias veces seguidas sin llevarse a nadie por delante, su moral bajará… del mismo modo que si dispara muchas veces acertando a la primera, su puntería sufrirá un pequeño aumento…)
  • Armas. El simulador tiene un control de las armas de cada juego. No sólo controla quién a matado a quién y dónde, sino también con qué arma. Por si fuera poco, el daño a los jugadores es sensible al arma. (Un rifle hace más daño que una pistola). Y, para el futuro, tenemos en mente tenerlo en cuenta a nivel de puntuación, sumando más puntos según que armas (puntuando más si se mata a cuchillo que con un rifle de francotirador).
  • Niveles. El nivel del equipo, la media general de las habilidades de los jugadores…. se sigue teniendo en cuenta, aunque con menos peso.

Como en otros artículos hemos comentado, la IA es de los puntos fuertes del juego, y de los más complejos. Y lo que queda…

Repercusiones. Al finalizar un partido, la mejor puntuación dice el clan ganador. Con la nueva dimensión social del juego, el sistema da más importancia cuando se ha ganado a un clan enemigo (y todavía más si se trata de un partido oficial y no de un amistoso). Además, se actualizan los puntos y créditos de clanes y usuarios, las estadísticas, los informes… Toda la simulación del partido es guardada en un fichero de texto, que se puede consultar desde la ficha de partido, observando toda la funcionalidad comentada. Una mejora (ya estamos en ello) es hacer compatible el informe con el sistema de plantillas, dotándolo de mayor potencia visual, acorde con el resto de la página.

pd.- seguimos necesitando socios… ¡únete! :P

Artículos recientes relacionados:


Kedada Stratera y otros eventos

El próximo Sábado día 13, en el lugar acostumbrado (Plaza de Callao) y a la hora habitual (18:00) comenzará una nueva kedada stratera, convocada desde los foros de la comunidad de desarrolladores de videojuegos stratos-ad. Hacía algún tiempo que no se planteaba esta reunión informal de strateros, así que será un placer volver a ver ciertas caras y conocer otras nuevas.

Por otro lado, seguimos moviendo hilos para organizar otro encuentro de desarrolladores, del estilo del primer Undead Meeting. A ver si vamos anunciando cosillas y sumando apoyos logísticos…

Para finalizar, recordamos el iniciador de mañana, en el que se hablará de inversiones y capital privado; y el workshop sobre Innovación y Emprendimiento del 11 de Diciembre.

Artículos recientes relacionados:


Oh my bug!, blog de programación

Hace algunas semanas un nuevo blog sobre programación, titulado Oh my bug!, inició su andadura por la blogosfera, arropado por una gran cantidad de usuarios y amigos. OMB! pretende ser un blog didáctico, técnico y divulgativo… donde los editores contamos cómo hacemos nuestros programas, compartimos experiencias sobre el código, tips con trucos concretos o completos tutoriales sobre creación de software variado.

Desde Undead apoyamos la causa, así como todo el anillo de bloggers (What the blogs!), participando en la redacción de OMB!. Hablaremos sobre programación de videojuegos, sin dejar de lado dosis de programación bajo php y desarrollo web. ¡Síguenos!

Artículos recientes relacionados: