Bon, allez ! Je m'y colle pour expliciter un peu. Ce que je vais dire, je l'ai testé: j'ai beaucoup réfléchi sur la question et je pense avoir avoir essayé l'ensemble des techniques susceptibles de permettre le support de plusieurs joueurs avec RM. Parce qu'on dit beaucoup trop d'idioties sur les orpg avec rgss. J'en profite pour tenter de dresser un état des lieux de ce qui se fait et de ce qui a été trouvé en la matière.

Je vais aborder les principaux problèmes successivement.

I) L'interraction de RM avec l'extérieur.

Un jeu multijoueur nécessite deux choses: un logiciel client (Rpg Maker) et un logiciel serveur (un script ruby, un programme plus complexe en C, Perl, Php, etc.).
La programmation du serveur ne pose pas de probleme: son rôle est de réceptionner les données envoyées par le client, de les traiter et de lui en envoyer des nouvelles.
La programmation du client est plus complexe du fait des limitations natives de Rgss et de RpgMaker.

a) Le bridage de Rgss

Rgss est une version modifiée de Ruby et non une simple bibliothèque comme on l'entend souvent dire. C'est-à-dire que c'est une compilation de Ruby embarquée dans un exécutable écrit en C++. En fait, nous avons un programme Game.exe qui charge une librairie RGSS300J.dll (par exemple) contenant l'interpréteur Ruby et dont les fonctions sont exportées dans Game.exe. D'autres fonctions et objets, non natives de Ruby, sont également codées, comme Bitmap, Input, etc. En outre, certaines fonctions de Ruby sont bridées: supprimées ou limitées. C'est notamment la fonction Kernel#require de Ruby qui permet de charger des fichiers externes (*.rb ou *.rbw) ou compilés (*.so pour les librairies unix). Dans VX la fonction a été masquée (rendue privée, plus précisément), mais un petit hack permet de la restaurer. Toutefois, on ne peut pas modifier ce qui n'a pas été codé: elle ne supporte pas l'importation de fichiers compilés. Or, de tels fichiers sont très utiles en ruby car ils permettent l'utilisation de librairies externes. Certes, on pourrait utiliser des fichiers décompilés, mais quoiqu'on fasse on se retrouve au bout de la chaine des require à devoir appeler un fichier compilé. Du coup, Rgss ne le supportant pas, ça plante. Donc exit les librairies online de ruby:

Un autre bride de RpgMaker est la perte du focus de la fenêtre. Vous avez pu le remarquer dès que l'on change de fenêtre, le jeu se met en pause. Plus précisément, il ne se raffraichit plus: Rgss arrête de s'exécuter et ne redémarre qu'au focus de la fenêtre. Cela gène considérablement les jeux online où la synchronisation entre les joueurs doit etre permanente.

b) Contourner ce bridage

Je pense que c'est la chose la plus intéressante de tout ce que l'on peut faire avec un script. Sans tomber dans le lyrisme informatique, c'est une sorte de combat entre le programmeur et sa machine. Bref. Comment, tout d'abord, faire communiquer Rgss avec le monde ? Les développeurs de Rgss ne nous ont pas complètement oublié: ayant besoin de faire appel aux librairies de Windows pour le programme en lui-même (accès au registre pour trouver les RTP, affichage de la fenêtre de jeu, etc.) ils ont laissé dans Ruby la classe Win32API. Celle-ci permet l'utilisation de fichiers *.dll externes. Un peu comme les fichiers *.so dont je parlais tout à l'heure. Windows utilise de nombreuses bibliothèques pour ses propres logiciels. Vous pouvez les trouver dans le dossier WINDOWS/System 32/*. Dans le lot, pas mal permettent un accès à internet. J'en ai pas mal utilisé dans mes différents scripts: FTP / HTTP / MYSQL, etc.
Vous avez beaucoup parlé des sockets dans la discussion. Ils sont eux aussi gérés par Windows dans la dll Winsock. Les sockets ont toujours beaucoup intéressé les scripteurs, en témoigne la foultitude de scripts qu'on peut trouver. C'est la solution la plus classique pour mettre un jeu en réseau: envoyer et recevoir des trames (bribes de chaines) du serveur.

II) La création d'un jeu online.

a) Possible en théorie

Il est possible de faire un jeu multijoueur avec RpgMaker. Aucun scripteur ne peut le contredire en théorie. Les méthodes par socket sont actuellement fonctionnelles, c'est-à-dire que l'on peut faire communiquer un serveur avec un jeu tournant avec Rgss. L'échange des trames se réalise correctement en réseau local ou distant (via le protocole TCP/IP ou le protocole UDP). Il existe de très nombreux essais se basant sur les sockets, notamment le fameux netplay des communautés anglophones, plus stable encore la PMO du français Tonyryu. Cependant, à l'heure actuelle, je n'ai jamais vu un seul jeu terminé supportant un mode multijoueur.

b) Beaucoup trop lent en pratique

Toutefois, le système, même s'il roule sous Ruby, n'est pas exécuté nativement par l'interpréteur. Chaque accès réseau passe par une dll externe qui s'occupe de la communication. Les fonctions de cette librairie sont invoquées par l'objet Win32API qui a le défaut d'être extrêmement lent. Le temps d'exécution que l'on gagne en utilisant un langage bas niveau donc plus rapide comme le C (qui code la dll) on le perd dans le chargement de l'API.
En créant le système de communication avec mysql, j'ai voulu accélérer les transferts en réduisant les étapes nécessaires aux sockets: connexion, envoi, transfert, écoute, transfert, réception, interprétation, confirmation. Dans mon script, il n'y a qu'une connexion, un envoi, une réception et l'interprétation. La connexion se fait principalement au chargement du jeu. L'envoi est moins complexe que l'envoi d'une trame car il se fait sous forme de requête SQL, ce qui est optimisé. La réception est peut-être un peu plus longue du fait de l'utilisation de boucles pour transcoder le résultat du C à une chaine Ruby (et donc par l'utilisation de nombreux pointeurs). Bref, le résultat s'il est meilleur n'est toujours pas satisfaisant.
Il faut naturellement écarter la technique du téléchargement de fichier, beaucoup trop lente.
Pour avoir un ordre d'idée, on va prendre un jeu à 5 joueurs, ce qui est minime. RM tourne à 40 frames par seconde. En gros l'interpréteur Ruby fait 40 tours en une seconde: rafraichissement graphique, du clavier et des données de jeu. Il faut multiplier par deux les connexions car il s'agit à la fois de recevoir et d'envoyer des informations. Ce qui fait 80 opérations par seconde (donc chacune doit s'exécuter en 0,0125 secondes). Bien sur, on ne peut faire ce rafraichissement non pas à chaque frame mais seulement 2 fois par seconde. Mais il ne faut pas oublier qu'il y a également 5 joueurs à gérer, pour chacun il faut télécharger les données et les transposer dans le jeu (mise à jour de la position, de la direction). En s'en sortant bien, on peut tirer à 50 opérations par seconde.

Mais ces communications ne doivent pas bloquer le jeu (la mise à jour graphique notamment). Par conséquent, il faut utiliser des Threads (exécution parallèle de code). Ceux-ci, même s'ils sont correctement gérés par Ruby, ne sont jamais très efficaces dans des langages interprétés car l'interpréteur a plus de boulot. Du coup, chaque opération nécessite plus de temps que si elle était gérée nativement.

Conclusion.

On ne peut pas être formellement certain de l'impossibilité de faire des jeux multijoueurs avec RpgMaker. Cependant, comme il a été dit précédemment, beaucoup de scripteurs s'y sont cassés les dents. Le principe est parfaitement fonctionnel mais il reste un très gros travail d'optimisation du système. A titre d'exemple, il faut réfléchir au gain de précieuses millisecondes. C'est un peu ce que j'ai tenté dans ma gestion mysql (on m'a pas mal reproché le fait que mon code soit incompréhensible): il faut optimiser jusqu'au nom des variables utilisées. Cette optimisation requiert une très grande maîtrise du Ruby et de la programmation en général. Pas question de croire que l'on peut développer un jeu multijoueur en sachant bidouiller des scripts). Pour connaitre votre niveau, essayez de créer un jeu fonctionnel en ayant effacé l'ensemble des scripts du jeu. Pas question non plus d'essayer de partir d'un script online: vous n'en comprendrez qu'à peu près le fonctionnement et il ne sera jamais totalement adapté à vos besoins.

Quoiqu'il en soit, il faut bannir toute idée de jeu massivement multijoueur dans la mesure où je ne pense pas que RpgMaker soit capable de gérer plus de 5 joueurs sur une meme carte. L'avenir le plus proche est l'échange de scores ou de variables au cours du jeu (pour cela je recommande mysql: promo... promo... )

Bonne soirée,

Berka