Et pourtant elle tourne

En vidéo, un petit exemple de ce que l'on peut faire avec un peu d'ocaml, et les librairies lablgl et ocamlsdl. Le code est composé d'un petit graphe de scènes purement fonctionnel (vu du dehors, du moins), qui permet de déterminer les transformations géométriques et de style des objets représentés. Un des nœuds se charge de compiler la géométrie pour obtenir de bonnes performances.

Blog en folie

Ouééé, je suis classé 19453ème sur Wikio! Pour la peine, je rajoute en bas à droite le classement, et un petit lien si quelqu'un a l'idée saugrenue de m'ajouter à son feed Wikio.

Description des zones

Tout en faisant un peu de nettoyage dans le code (principalement centré autour de des binders pour les requêtes SQL), je m'attaque à la description des zones, comme indiqué dans le post précédent. L'intention est d'envoyer une liste des objets utilisés dans la zone, avec le nom du fichier de ressources correspondant, suivi d'une liste des positions, orientations et échelles des objets dans la zone.

Pour l'instant, je vais me contenter de renvoyer la description entière de la zone lorsqu'elle est modifiée. Si sa fonctionnalité d'édition dynamique des zones prend, il me faudra probablement aller vers l'envoi des différences.

Presque Bérénice

Avec l'ajout du support pour les messages "whois" (identification des joueurs, qui permet l'affichage des noms dans le chat), la nouvelle mouture d'AdH a rattrapé l'ancienne, ce qui veut dire que l'on va enfin commencer à attaquer de nouvelles fonctionnalités (après un bon coup de nettoyage dans le code, quand même). Il ne reste qu'un seul bug ennuyeux, qui est que l'on ne peut voir les autres avatars qu'a partir du moment où ils commencent à bouger, et il faut que je trouve une manière élégante de corriger cela.

Pour la prochaine fonctionnalité, je me voyais bien m'attaquer à la création du monde. L'idée est de permettre à certains avatars de créer et de développer des zones, le tout depuis le jeu. Ces avatars pourraient à partir d'une bibliothèque d'objets et de quelques outils architecturaux créer des mondes entiers. La première raison pour une telle fonctionnalité est de n'avoir pas de génération de carte séparée: après tout, la représentation la plus proche de ce que verrons les joueurs est le jeu lui même! La deuxième raison est qu'une telle fonctionnalité, utilisée avec discernement, peut être formidable pour le gameplay, en proposant par exemple un niveau à partir duquel les joueurs, élevés au rang des dieux, peuvent créer de nouveaux mondes.

Un écosystème

Plus qu'un serveur causant à une base de données, c'est un écosystème entier qui peut se greffer sur l'architecture d'Adh. Maintenant que le système est au point (je viens de rajouter dans la base le support pour le déplacement des avatars), il est possible de connecter à peu près n'importe quel module additionnel sur la base pour aller y faire tout un tas de choses intéressantes. Il suffit de savoir causer le SQL.

On peut commencer simple, avec des systèmes de feed vers la base: par exemple, en envoyant la météo, afin de modifier l'environnement du jeu en temps réel. Ou encore, en permettant aux joueurs de recevoir des nouvelles depuis le forum d'un site web.

Après, on peut installer des feeds en sens inverse: faire remonter vers le site tout un tas de statistiques sur le monde, les derniers prix de marchandises, les actes de bravoure des joueurs...

Poussons plus loin, et ayons un système qui cause dans les deux sens! Pourquoi ne pas permettre aux joueurs d'accéder à leur personnage et d'effectuer des actions simples sans avoir à se connecter via le client lourd? Ainsi, le joueur pourrait aller enguirlander ses fermiers, commercer, ou encore préparer une autre conspiration, tout cela depuis le boulot / l'université / la salle info de l'école maternelle, à la pause déjeuner (et seulement à la pause déjeuner, n'est-ce pas, bande de petits canaillous?).

Mais ce n'est pas fini! Modifions la base pour permettre l'ajout de modules spécifiques qui iront modifier l'expérience de jeu. Il serait possible de développer un module d'artisanat, de combat, de sorts, de gestion de ses troupes, et beaucoup d'autres choses, de manière totalement indépendante. Par exemple, il suffit d'ajouter une simple table des ordres, et l'on peut avoir un module d'artisanat qui lit les ordres, et transforme les objets contenus dans l'inventaire de l'avatar. Une autre table d'ordres liée à un module de jeux de hasard, et voilà un casino!

Au final, ce code "hors serveur" doit surtout être utilisé pour les actions un peu particulières et qui n'arrivent pas trop souvent (l'on pourrait faire un module qui gère les déplacements, mais bonjour les performances!), mais permettrait d'ajouter assez facilement des tonnes de fonctionnalités pour un gameplay poussé.

Il n'y a plus qu'à s'y mettre!

Inventaire

J'ai étendu le principe développé dans le post précédent à l'inventaire. C'est assez similaire:

- L'inventaire est modifié
- Une trigger ajoute l'identifiant d'avatar à la liste des inventaires modifiés
- Une autre trigger réveille le serveur
- Le serveur récupère les nouveaux inventaires et les envoie à qui de droit

Il y a cependant une petite différence. Un des avantages du système est que je n'ai plus à me préoccuper de redistribuer les informations d'inventaire: même si l'on ajoute un composant totalement indépendant qui va modifier la base de données, toute modification sera immédiatement répercutée sur les utilisateurs. L'on peut donc par exemple penser à un système de commerce séparé, pourquoi pas dans un navigateur internet, qui irait en temps réel répercuter les actions dans le jeu. Ou pourquoi pas un composant "artisanat" qui permette de transformer certains matériaux en objets? Ou encore un composant "La main des Dieux" qui permette au maitre du jeu de faire apparaitre des artéfacts de quête dans le sac du joueur.

Un petit point d'optimisation ici est l'envoi juste avant la requête, dans une table temporaire, des avatars actuellement connectés. Ainsi, la requête est faite en joignant la table de l'inventaire, la table des avatars dont l'inventaire a été modifié, et la table des avatars actuellement connectés, de manière à n'envoyer vers le serveur que les inventaires qui doivent être réellement distribués (l'inventaire a été modifié ET le joueur est connecté). Si l'on a par exemple 1000 joueurs connectés, et que l'on modifie l'inventaire de 1000 joueurs, mais que seuls 50 d'entre eux étaient connectés, l'on envoie seulement vers le serveur 50 inventaires. L'écriture des données sur la table des avatars actuellement connectés est très rapide, puisque c'est une copie directe, et que l'on a donc pas besoin de faire une ribambelle d'INSERT qui ralentiraient le tout.

Des requêtes, et des requêtes

Je suis en train de rapidement rattraper le niveau de fonctionnalités de Bérénice, rajoutant les requêtes faites par le client. Ce soir, c'était la description des objets du monde. Très sommaire pour l'instant (id, nom, description), mais ça sera simple à enrichir.

Un problème intéressant que celui de ces requêtes est la synchronisation. A la connexion, le client envoie en effet un lot de requêtes au serveur pour récupérer les informations importantes sur l'avatar incarné, la liste des types d'objets, l'inventaire... Mais si par exemple l'inventaire est reçu avant la liste d'objets, les noms ne pourront pas être affichés. De même, si la requête de mon inventaire est traitée par le serveur plus rapidement que la demande d'incarnation de mon avatar, le serveur va trouver que je ne suis pour l'instant lié à aucun avatar, et va refuser ma demande.

Dans certains cas, il existe une solution élégante au problème Pour l'inventaire, par exemple, utiliser le numéro d'identification tant que l'on a pas d'informations sur le nom de l'objet. Quand la liste des noms d'objets arrive, renommer tous les objets de l'inventaire avec la nouvelle liste. Le message arrivera de toutes façons si vite que le joueur ne s'apercevra même pas que les noms étaient faux au départ! Cela améliore la robustesse de l'application, qui devient capable de gérer les messages dans un ordre moins strict.

Dans d'autres cas, il n'y a pas de solution miracle, et il va falloir synchroniser à la main... Et le client attendra donc qu'une requête ait été confirmée pour envoyer la suivante. Il n'y a plus qu'à trouver un design à peu près propre pour supporter cela.