Architecture logicielle

Pour le jeu, il faut concevoir dès le départ une architecture logicielle qui soit à la fois efficace et flexible (FOUTAISES !!).

On va utiliser pour cela le design pattern Modèle-Vue-Contrôleur :

• Modèle : le moteur proprement dit du jeu, avec les interfaces avec la base de données, la configuration du jeu, etc.
• Vue : une API publique pour permettre d’interagir avec le modèle, les aficionados pourront utiliser la vue.
• Contrôleur : une interface web (par défaut) pour interagir avec la vue, les aficionados pourront créer de nouveaux contrôleur (Web, Gtk, Qt, etc.)

• Modèle : Voir ailleurs.
• Vue : Après moultes discussions, on va plutôt s’orienter vers un serveur HTTP dédié avec du XML-RPC
  • shttpd, un serveur web “embeddable”.
  • pour le XML-RPC, voir après.
• Contrôleur : par défaut, une jolie interface web, probablement en PHP avec XML_RPC2.

Pour raccorder les deux, deux possibilités :

À travers un socket (réseau ou local). Avantages :

• Bas-niveau : rapide et optimisé

Inconvénients :

• Difficile d’accés pour les applis web

À travers couche XML-RPC ou SOAP nous pouvons délivrer tous les messages dans notre propre format XML.

Avantages :

• Plus web : peut fonctionner avec Javascript (AJAX), Flash, XUL, RoR, etc.

Inconvénients :

• Haut-niveau : plus lent, plus couteux en ressource

Note: rien n’empéche de faire une surcouhe XML à l’API socket. Profitant ainsi des avantages des deux dans chaque situation appropriées.

• http://www.xmlrpc.com/
• http://xmlrpcpp.sourceforge.net/
• http://xmlrpc-c.sourceforge.net/
• http://xmlrpc-epi.sourceforge.net/

Très intrusif...

L’API consiste à interroger des CGI qui au lieu de renvoyer une page XHTML renvoie un fichier XML. On peut prévoir une petite librairie pour forger les requêtes XHTML à envoyer au serveur pour les applications non-web.

Avantages :

• Pas besoin de déployer un truc SOAP, un simple serveur web suffit

Inconvénients :

• Aucun :) (j’en vois pas trop pour l’instant)