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