Il va sans dire que je me jette sur l'occasion pour vous décrire mon activité principale du week-end : la résolution d'un tour de jeu de Gloire et Pouvoir :-). Et d'ailleurs, ca tombe bien, c'est ce soir.

Mais avant de commencer, je crois qu'un peu d'histoire éclairerait les choses et notamment certains "choix techniques" qui pourraient sembler peu judicieux aujourd'hui.

A l'époque où j'ai commencé à réfléchir à la réalisation du jeu, je ne connaissais pas le PHP. De plus, je n'imaginais pas qu'il y aurait plus d'une ou deux parties (et encore, l'une après l'autre). Le seul langage de script que le maîtrisais était l'ASP et fort peu (aucun ?) d'hébergeurs gratuits le proposaient.
J'ai donc choisi d'utiliser Visual Basic dans sa version de l'époque (V6). Ce choix n'est pas le fruit du hasard : pour un logiciel de gestion (lecture/ecriture en base de données et petites règles de gestion et de calcul) la productivité qu'autorisait cet outil était imbattable.
Ce moteur se chargeait ensuite de générer automatiquement les pages HTML statiques que j'envoyais manuellement sur le site hébergé gratuitement sur Free.
Les ordres étaient reçus par mail et analysés par le moteur.

Devant le travail de correction des mails que je recevais (très rarement correctement formattés), je me suis lancé dans l'apprentissage de PHP et ai modifié le site pour faciliter la saisie des ordres et, tant qu'à faire, supprimer la phase manuelle de mise à jour du site. A été mis en place un système de synchronisation des bases de données de mon moteur et du site. Synchronisation toujours d'actualité d'ailleurs.
Le succès relatif du jeu arrivant, je me suis retrouvé rapidement à passer plus de 4 à 5 heures chaque semaine à lancer une à une les résolutions des parties. J'ai donc modifié le moteur pour qu'il exécute ces dernières automatiquement les unes après les autres.

Aujourd'hui, fort (ou plutôt faible) de cet historique, la résolution consiste pour moi à :

  • fermer l'accès à la saisie des ordres sur le site (et accessoirement aux nouvelles inscriptions) jusqu'à ce que la synchronisation vers le site soit terminée (1 clic),
  • lancer la synchronisation vers le moteur pour récupérer : les ordres, les login (ne pas perdre les nouvelles inscriptions), les seigneurs (les joueurs en attente d'une nouvelle partie y sont répertoriés) (1 clic)
  • Vérifier que l'ensemble des données ont bien été rapatriées. La méthode de synchronisation consiste à faire une dump (une copie) des tables nécessaires dans un fichier, de le rapatrier automatiquement via FTP et d'importer ces tables dans la base de données du moteur
  • lancer la résolution des parties (1 clic)
  • Vérifier sur 2 ou 3 parties qu'aucun bug n'est apparu (et éventuellement le corriger, remettre la base de données en état et recommencer la résolution, mais cela est rarissime aujourd'hui)
  • Initialiser les nouvelles parties en vérifiant rapidement qu'il n'y ait pas de comptes multiples (cela arrive tout de même de temps en temps mais là encore, cela reste rare) (quelques clics)
  • Synchroniser la base de données du site (1 clic)
  • Ré-ouvrir l'accès aux ordres et aux inscriptions (1 clic)
  • Lancer l'envoi automatique des mails de compte-rendu (cette tâche monopolise l'ordinateur durant une bonne demi-heure
  • Envoyer sur le site dédié aux aides de camps les informations leur permettant de venir en aide aux joueurs qui ne recevraient pas ou perdraient les fichiers de compte-rendu (1 clic)
En fonction des semaines, il arrive que la synchronisation ne puisse se dérouler normalement (voilà 4 semaines que, pour je ne sais quelle raison, cela arrive un peu trop fréquemment à mon goût). Dans ce cas, j'en suis pour plusieurs heures de récupération et/ou envoi artisanal des données (entendez par là, téléchargement des tables avec phpMyAdmin ).

Voici la raison pour laquelle la résolution des tours est dépendante de ma disponibilité.

A l'avenir, je songe à placer le moteur sur le serveur hébergeant le site. Ceci permettrait d'éviter la phase de synchronisation si coûteuse en temps (70% du temps du processus complet) et autoriserait de stocker aisément les bilans sur le site (les mails serviraient alors juste à alerter les joueurs de la disponibilité de ceux-ci).
Le moteur est déjà migré (pas encore testé) vers la technologie ASP.NET (toujours un choix dicté par la productivité et la performance de l'environnement, la facilité de migration de VB à C#); mais un hébergement de type mutualisé (comme aujoud'hui) et peu coûteux ne suffirait plus. C'est bien d'un serveur dédié dont nous aurions besoin et le prix d'une telle location multiplierait par 5 ou 6 le coût annuel. Le budget de l'Association de Soutien à Gloire et Pouvoir n'y suffit pas aujourd'hui.