Aunque desde hace varios días el registro en Win or Defeat era libre, hoy comunicamos de forma oficial la apertura de la beta pública. Hemos acelerado un poco el proceso, debido a que tenemos un especial interés en ir recibiendo feedback masivo de mejoras y nuevas funcionalidades deseadas. Tenemos ya muchas en mente, pero debido a la magnitud de la aplicación y otros factores, el avance de esas nuevas características no será inmediato. La depuración de todo el proyecto urge más, así que en unas semanas iremos ajustando cada parte de WoD, observando la coherencia lógica, la jugabilidad, el diseño…

¡Te esperamos!

Artículos recientes relacionados:

• Encarando un verano muy intenso
• Crystal Reversi, ya disponible en la AppStore
• Postmortem: Tinted Turns (iPhone)
• Independizando Somflee
• Cerrando un proyecto: Tinted Turns

Estas últimas semanas hemos realizado importantes avances, tanto en temas de funcionalidad e interfaz, como en temas de intelegencia artificial y procesos automáticos. Una de las características que tocaba redefinir concretando su funcionamiento era el sistema de patrocinadores. A nivel de estructura interna, no ha habido cambios drásticos, pero sí hemos añadido detalles para ajustar aún más el sentido de los mismos.

• WoDBot y usuarios reales. De forma inicial, todo el control / administración de los patrocinadores iba a ser llevado por nuestro bot. Eso era muy cómodo para contratar las campañas de publicidad de forma manual bajo precio fijo, impresiones…. pero la ficha de cada patrocinador se quedaría algo coja (o nos llevaría mucho trabajo cambiar manualmente los datos de cada patrocinador, cuando éste lo desee). Así, optamos por dar la posibilidad a los usuarios de que pudiesen crear (y editar) sus propios patrocinadores. (El proceso de creación / edición lleva un alto cargo en wodies (la moneda del juego) para entre otras cosas, evitar el spam masivo.
• Derivado del punto anterior, teníamos el problema de que los datos de cada juego (CS, DoD y T34) son accesibles sólo cuando el usuario está manejando su clan asociado. De tal forma, un usuario que tuviera un patrocinador creado, no podría ver las fichas en las que sale su patrocinador, si no maneja un clan para cada juego. La solución estuvo es dejar mostrar los datos (pero negando la interactividad con ellos), pasándolo al menu general de la aplicación.
• Tras esto, ampliamos la posibilidad de que un patrocinador sólo ejerciese en un juego, en lugar de en los 3 como hasta ahora. Ser un patrocinador activo en un juego, será más barato para el usuario que estar activo en los 3.

En cuanto a la parte no visual, también estamos haciendo ajustes, para controlar por ejemplo, qué pasa cuando un patrocinador no tiene créditos suficientes para dar a los clanes que patrocina. Un patrocinador paga una serie de créditos, de forma mensual, a cada clan que patrocina. Esta cantidad se resta de la cuenta del usuario que administra el patrocinador. Pero puede que el usuario no tenga crédito… y en este sentido…

• Varios días antes del pago a cada clan (se realiza cada 30 días naturales desde la fecha del acuerdo de patrocinio entre clan y patrocinador), se comprueba la solvencia del usuario, reservan los créditos que hacen falta para pagar a todos los clanes que patrocina una entidad. Si no hay dinero suficiente… saltan las alarmas….
• En el momento del pago… si no hay créditos en la reserva, se tira directamente de la cuenta de usuario. Si tampoco es suficiente, dependiendo de la cantidad debida… se rescinde el contrato al instante (WoDBot se encarga de los trámites) o se avisa a ambas partes de lo sucedido, dejando en manos del clan la decisión de abandonar o no el patrocinio.

Además se realizan otra serie de comprobaciones y cálculos, a fin de tener todo los procesos controlados relacionados con los patrocinadores, una entidad más del juego en el que basamos el modelo de negocio de WoD.

Por otro lado, se mantiene que el bot pueda manejar patrocinadores, estando reservado a empresas o anunciantes de mayor nivel o que deseen integrarse en el sistema sin llevar un control exhaustivo de lo que pasa en el juego.

Artículos recientes relacionados:

• Encarando un verano muy intenso
• Crystal Reversi, ya disponible en la AppStore
• Postmortem: Tinted Turns (iPhone)
• Independizando Somflee
• Cerrando un proyecto: Tinted Turns

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:

• Encarando un verano muy intenso
• Crystal Reversi, ya disponible en la AppStore
• Postmortem: Tinted Turns (iPhone)
• Independizando Somflee
• Cerrando un proyecto: Tinted Turns

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!

Artículos recientes relacionados:

• Encarando un verano muy intenso
• Crystal Reversi, ya disponible en la AppStore
• Postmortem: Tinted Turns (iPhone)
• Independizando Somflee
• Cerrando un proyecto: Tinted Turns

Comentado el aspecto lógico del juego en artículos anteriores de este post – mortem, toca revisar la parte técnica de Win or Defeat. Tecnologías, bases de datos, fundamentos técnicos… La base siempre ha sido la misma, pero según fue evolucionando la lógica, fue necesario optar por implementaciones más potentes. Así…

En la primera etapa del proyecto, todo el código fue desarrollado desde cero, con PHP, sin utilizar ningún tipo de framework o entorno. Puesto que urgía tenerlo cuanto antes, nos dividimos el trabajo en dos partes, haciendo reportes diarios de todo aquello que ibamos modificando. Al dar por finalizada esa parte, la estructura de la aplicación no era la adecuada, al menos para afrontar un proyecto de las dimensiones que tiene ahora. Al retomarlo y darle ese nuevo enfoque, nos dimos cuenta que habría que rehacer muchas cosas, desde el código de la parte front end, hasta las relaciones y tablas de la base de datos. ¿Cómo reestructurar entonces?

En este punto, comenzamos a analizar el futuro. Es decir, no se trataba simplemente de hacer algo funcional bien organizado, sino que esa organización, tanto de código como de datos, fuese muy flexible, reduciendo los costes de mantenimiento posterior lo más posible. Y, además, que las funcionalidades pudiesen ampliarse sin resultar una experiencia traumática. El resultado de la deliberación y, con vistas a que fuera un software corporativo, nació Earwyn. Ya no teníamos una prisa especial para terminar el juego, así que decidimos sacrificar varios meses (que se convirtieron en bastantes) ganando un mayor control sobre la aplicación… y la verdad es que a nivel de productividad, se nota mucho que un framework te de tantas facilidades: código más limpio, más ordenado, control de errores, logs… fue un trabajo impresionante, pero ha merecido la pena.

De php4 pasamos a php5 (entre otras cosas, por que Earwyn se diseñó para la versión 5 del lenguaje); de unas 20 tablas mySQL hemos pasado a 46 (y aumentando); de html usando tablas y embebido en los ficheros .php hemos evolucionado a diseño y datos separados, con plantillas xhtml / css2 sin código php; y nos hemos metido con AJAX.

Back end. La parte de los cron, jobs… también corre bajo PHP, aunque en determinados procesos hemos experimentado con algo de PERL y Python.

¿Por qué PHP? Tanto Thani como yo, teníamos una base sólida en esta tecnología… así que, simplemente, por el hecho de sentirnos más cómodos desarrollando. En cuanto al uso de mySQL, porque suele ser un complemento muy habitual de PHP (muy fácil de encontrar en las características de cualquier servidor) y es eficiente para el volumen de datos que pretendemos manejar. Si en unos años la cosa adquiere mucha más carga de datos… puesto que las operaciones se hacen a través de Earwyn, cambiando esa parte del framework, no tendríamos que tocar muchas cosas para que fuera compatible, por ejemplo, con Postgre. Sobre hacer uso de técnicas AJAX, vimos que era necesario actualizarse a las nuevas tendencias, además de dotar de espectacularidad, mejorando la experiencia de usuario en ciertas operaciones. Earwyn trae un motor de AJAX, pero también hemos utilizado librerías como jQuery o Prototype.

¿Flash? Tenemos en mente, para desarrollar más adelante, hacer un simulador virtual en flash de los partidos. De tal forma que además del resultado en texto (ambientado con CSS2) haya una animación que lo escenifique. Pero a falta de creativo web…

Servidor. Desde hace varios meses, el juego se aloja en un servidor compartido, alquilado a una compañía americana. Imaginamos que después de la beta abierta… habrá que plantearse migrar a un servidor dedicado, debido a que el volumen de datos (y la carga que conlleve al equipo) ya puede ser más que importante.

Y con esto y muchas horas…

Artículos recientes relacionados:

• Encarando un verano muy intenso
• Crystal Reversi, ya disponible en la AppStore
• Postmortem: Tinted Turns (iPhone)
• Independizando Somflee
• Cerrando un proyecto: Tinted Turns