Récapitulons : Raydium est un moteur de jeu. Dans un moteur de jeu, on retrouve (entre autres) un moteur 3D, un moteur sonore, etc. mais aussi un moteur réseau, que l'on nomme vulgairement "netcode".
En général, on utilise un principe clients-serveur, ce qui signifie que chaque client possède une connexion à destination du serveur, et à l'inverse le serveur possède n connexions vers les différents clients. Pour faire une connexion réseau avec IP (pour que les connexions puissent être acheminées sur le net), on dispose de deux protocoles : TCP et UDP.

TCP est le plus courant sur le net (HTTP, FTP, SMTP, ...), et on dit qu'il est "connecté", c'est à dire qu'il offre les notions de connexion/déconnection, et les données sont protégées par le protocole (toute perte de données est détectée, et corrigée grace à une réémission). C'est très efficace, mais c'est lent. Par exemple, la machine de destination doit accuser de la réception des données (ACK) et donc renvoyer des données en échange. L'autre problème en ce qui nous concerne (les jeux vidéo) c'est le goulot d'étranglement que risque de créer ce protocole : dans un jeu, on envoie beaucoup d'informations (positions des différents joueurs, par exemple), et TCP fera tout pour que la totalité des données soit bien reçue, même s'il doit mettre en attente la suite des données.

Or dans un jeu, la seule chose qui compte, c'est de connaitre la position des joueurs maintenant ... et il est impensable d'attendre toutes les données (toutes les positions précédentes) pour connaitre la dernière position. Toute nouvelle donnée doit "périmer" les anciennes.
Le cas le plus simple pour démontrer ça, c'est d'imaginer un serveur disposant d'une bande passante dix fois supérieure à celle d'un client. Puisque le client est lent, le serveur va devoir mettre en attente les nouvelles données... et le client va recevoir l'information (les positions) de plus en plus "en retard" (lag).

Donc on en arrive à UDP : il est lui complétement déconnecté, son seul but est d'essayer d'envoyer des données. Pas de détection d'erreurs (paquets perdus), pas de notion de connexion (n'importe qui peut envoyer des données sur le port en attente du serveur, sans négociation préalable), ni de paquet (si l'information est trop grosse, à vous de la découper et de vous débrouiller pour que tout arrive dans le bon ordre), etc. (Attention, contrairement à la légende, UDP possède bien un petit contrôle d'intégrité, basé sur une CRC). Autre aspect : pas de "bourrage" possible. Si de nouvelles données arrivent et qu'il n'y a plus de place (bande passante trop faible), les nouvelles données écrasent les anciennes.
C'est l'anarchie, mais c'est beaucoup (beaucoup) plus rapide que TCP.

UDP est donc très utilisé pour les applications dans lequelles les données ne sont "pas trop importantes" (par rapport à la vitesse) : streaming vidéo et jeux vidéo, par exemple. (Certains seront peut être étonnés de savoir que DNS utilise uniquement de l'UDP).

Oui mais voilà, dans un jeu vidéo, il y'a certes des données "pas importantes" (positions des joueurs, encore une fois), mais aussi des données "importantes" : explosion d'une roquette à tel endroit, informations sur le joueur (équipe, couleur, score, ...) qu'il est hors de question de rater.

Il y'a deux solutions à ce problème (notez qu'il concerne la totalité des jeux dits "temps réel"). La première consiste à ouvrir deux canaux vers le serveur : l'un en TCP (truc importants), et l'autre en UDP (trucs pas important). Cette solution semble très intéressante, mais cache en fait de nombreux problèmes d'implémentation :
- énorme complexité de la synchro entre les deux canaux
- poids de TCP sur UDP (TCP a tendance à être prioritaire sur UDP)
- protocole plus complexe (deux ports au lieu d'un : firewalls, routage, statistiques, ...)

L'autre solution est plus longue, mais beaucoup plus souple à terme : reprogrammer certains comportements de TCP au dessus d'UDP :
- sécurité du transfert (données perdues détectées et ré-émises)
- notion de connexion ("le joueur 'truc' s'est déconnecté")
- timeout
- rang (le paquet 10 doit arriver avant le 11)
- ...

Résultat, on n'active ces systèmes que pour les paquets importants, et on utilise l'UDP "de base" pour le reste.

Quand j'ai commençé ce travail pour Raydium, je savais bien que ça allait être long, dur et pleins de pièges ... eh bien c'est l'une des seules fois ou je me suis trompé sur l'ampleur du travail : c'est un enfer, un cauchemard ! :)
Coder une couche réseau (de bas niveau, qui plus est), ça signifie que le débogage est quasi impossible, que le comportement de la couche réseau change du tout au tout en fonction de l'environnement (nombre de clients, débit total, débit de chaque client, ...) sans que l'on sache vraimment pourquoi, etc. Ajoutez la gestion d'un moteur physique sur le réseau, et vous avez de quoi rendre malade un codeur sur 5 générations.

M'enfin puisque c'est quand même vachement intéressant, petit à petit, la couche réseau de Raydium a avancé, corrigée bug par bug, fonctionnalité par fonctionnalité, pour enfin atteindre un stade intéressant : elle marchait en réseau local ! (le tout à du s'étaler sur deux ans, facilement).
Par contre, sur le net, les performances étaient médiocres, et tout s'écroulait (déco pour tout le monde) dès qu'un client LAN se connectait.

Le problème en lui même était simple, l'explication est plus complexe. En référence à ce qui est dit plus haut, la fonctionnalité la plus importante que doit offrir notre couche réseau basée sur UDP est la détection de paquets perdus. Pour détecter si un paquet est perdu, il faut mettre en place un système d'accusés de réception, et il faut se donner un délais maximal de retour de l'accusé de réception au delà duquel on considère le paquet comme perdu. Concrétement, ce délais (timeout) est le double de la moyenne pondérée du temps de retour des accusés de réception, doublée (la moyenne) pour chaque paquet perdu (c'est tout à fait le principe utilisé par les piles TCP).
Après pas mal de tests (et un peu de réflexion, aussi), nous nous sommes aperçus que les serveurs Raydium n'avait qu'un seul de ces délais, au lieu d'en avoir un pour chaque client connecté. Les clients connectés au travers d'un réseau local avait donc tendance à réduire très fortement le délais, "stressant" les clients connectés sur le net, qui se faisaient donc engueuler parcequ'il n'envoyaient pas les accusés de réception assez vite, engueulade qui consomait encore plus de bande passante, ... le cercle vicieux.
Après ré-écriture de cette partie du netcode, nous avons organisé un test. 3 joueurs, dont 2 sur le net (lignes ADSL), un client sur un réseau local (54 mbps), et le serveur (ligne ADSL 8/1 mbps), et pour la première fois, nous avons réussi à jouer à notre mini FPS dans ces conditions !

Du premier coup (fait rare), sans le moindre plantage, et avec un lag tout à fait acceptable !
Ajouté à la prédiction de trajectoires, à la physique réseau, la couche UDP de Raydium nous permet d'avoir un netcode (enfin) complet et fonctionnel sur le net :)

Référence sur le forum de Raydium : http://memak.raydium.org/viewtopic.php?t=175#1366

... ouais, alors le truc sympa mais usant sur un projet comme Raydium, c'est qu'il faut tout gérer soit même. Raydium est mon premier véritable logiciel libre, les projets précédents (et particulierement Metal Taste, un jeu de caisses en 2D à la Micromachines) n'étaient pas franchement OpenSource.
Et le truc super tuant, c'est que contrairement à ce qu'on s'imagine au début, les contributions d'autres personnes ne pleuvent pas. C'est même le désert.
En fait, le logiciel libre, c'est une grande jungle : la sélection naturelle appliquée au logiciel, en quelque sorte : seuls les gros projets intéressent les contributeurs, et ils deviennent encore plus gros, et ils intéressent encore plus, etc.
Alors ton petit logiciel qui peine à afficher quelques triangles sans ramer, laid dans le code, très laid dans le rendu, et avec 300 concurrents qui sont infiniment plus avancés, tout le monde s'en fout :) Et ça, tu le sait pas, au début.
Quand tu commences à prendre conscience de ça, tu changes de vision : le but n'est plus de séduire (les contributeurs), mais d'avancer. Et là, tu t'occupes de tout : tu analyses, tu planifies, tu codes (beaucoup... vraimment beaucoup), tu t'occupes du graphisme, de la musique, tu codes (encore) le site web, tu cherches des idées pour tester les nouvelles capacités que tu vient de coder, tu inscrit ton projet sur les sites liés au logiciel libre, tu t'acharnes sur les pires bugs (parce que si tu arrive pas à le corriger, ce *$#@ de bug, tu sait que tu as perdu 1 semaine de boulot).
Et c'est seulement après que tu commences à entendre parler de ton logiciel... souvent en mal dans un premier temps ("compile pas", "marche pas", "plante", ...), puis comme "quelque chose d'intéressant, mais ..." (on est déjà à quelques années après le début du projet, là).

A le lire comme ça, ça doit surement sembler assez terrible, mais c'est au contraire très motivant (même si c'est souvent un peu frustrant sur le coup de lire des choses négative sur un projet dans lequel on bosse tant). La sensation que l'on ressent lorsqu'un site parle pour la première fois de son projet est complétement indescriptible ("rhaaaaa mias ppourquio jez tremmble commme çaa").

Les premières contributions sont arrivées d'un pote, RyLe, en forcant un peu la main ("mais dit moi, tu t'y connait pas mal niveau son, ça t'intéresserait pas de coder la partie son de l'API ?"), puis une grosse partie de CQFD Corp. (notre "groupe" d'amis, pas forcément liés à l'informatique) a été impliquée dans le projet, au travers d'une réunion (extrait du Wiki) :

---------

A la suite d'une réunion réunissant près de 30 personnes, en mars 2003, après une démonstration des capacités de Raydium, le groupe a commencé un débat sur le jeu que chacun considèrait comme "idéal", dans le but de déterminer LE jeu qui allait utiliser Raydium (et le faire évoluer en un moteur de jeu, au passage).
Il y'avait ce soir là beaucoup de profils différents de joueurs, et des références telles que Interstate 76, Operation Flashpoint, Hunter, Ultima, Mad Max ont été citées.
Tard dans la nuit, un univers (qui se résume à ces quelques mots: désert, rouille, huile qui pue et engins bruyants) et le début de quelques règles étaient établies, et un nom émergea. (le nom final, c'est MeMak)

----------

Le forum a été ouvert tout de suite après, très dynamique, plein d'inscrits, des idées partout ... pendant quelques mois, puis à nouveau, le creux (classique, hein ? :).

S'impliquer dans un projet collaboratif, c'est plus compliqué qu'il n'y parait : il faut du temps, une grosse motivation, et surtout ne pas avoir peur de manquer de compétences (ça vient après, ça).
Déjà rodé à ce genre de déceptions, j'ai alors décidé de laisser aller les choses, sans énervement, sans acidité : j'ai continué à poster sur le forum, et surtout j'ai continué à bosser sur Raydium (le moteur 3D) ... MeMak (le jeu qui utilise Raydium) se lancera bien de lui même, me suis-je dit.
Puis petit à petit, des contributeurs (ou même des visiteurs réguliers) ont commencé à apparaître. De son coté, Raydium a vu arriver toujours plus de fonctionnalités (son support réseau et sa physique, par exemple), et les premières démos avec (des minis jeux de voiture, des mini FPS, ...), avec des gens volontaires pour tester tout ça, un ensemble de petites contributions (graphiques en particulier, musicales, mais mathématiques aussi :)

Voilà l'état actuel des choses : un projet effectif (Raydium), un but final (MeMak), quelques contributeurs, pas mal de ressources, quelques contacts (même un Ancien de chez Cryo, notez les majuscules :), des réunions régulières, des démos qui tournent bien dans les salons et festivals ("Nan maman je veux encore rester jouer un peu !", entendu des dizaines de fois :) , 4 ans de développement, 30 000 lignes de code (pour 600 000 caractères), 1.5 Go de données "fraîches", (ça butte, hein ? :) ...

Morale : Si un jour vous souhaitez vous impliquer dans un projet de ce genre, n'hésitez pas une seconde, c'est totalement et immanquablement passionnant.

Je l'ai déjà posté sur la tribune, mais je pense que c'est plus logique de le poser ici. Il s'agit d'un mail d'Adam Moravanszky, une énorme tête qui bosse chez Novodex (un moteur physique encore peu connu, mais au potentiel énorme) : http://q12.org/pipermail/ode/2004-December/014735.html

Ce mail est une réponse à des remarques sur la mailing list d'ODE, qui étaient plutôt acides envers le moteur physique de Doom3. Adam rétorque qu'en fait, ce moteur est en fait parfaitement adapté aux besoins du jeu, et n'est pas généraliste comme Havok, Novodex, Takomak ou ODE le sont, par exemple. Il tire cette déduction d'un exercice auquel il s'est livré : remplacer le moteur de Doom3 par d'autres (Novodex utilise beaucoup cette technique pour montrer les capacités de son moteur... ils ont même créé un langage dédié à ça). Cette intégration semble avoir été assez laborieuse, pour différentes raisons (paraphrases en vue) :
- le moteur de Doom3 n'a aucun problème avec les forces et les vitesses très importantes, alors que les autres moteurs tendent à l'explosion dans ces situations (cf l'exploitation de ces phénomènes dans les HL² done quick ;), ou "ratent" des collisions dans le meilleur des cas.
- Il dispose d'un système de manipulation des objets physiques. Imposer un déplacement et/ou une rotation d'un objet est toujours une chose très complexe pour les autres moteurs (utilisateur qui manipule un objet à bout de bras, ascenseur, "entité réseau" qui pousse le joueur, ...), qui est souvent assimilée à une "violation" de la physique, et il en résulte souvent un effet de tremblement assez caractéristique. Doom3 semble disposer de tout ce qu'il faut pour gérer ces cas.
- Une notion de sol directement intégrée au moteur et à la logique physique (pas de problème de "resting bodies").
- Le moteur semble très séquenciel (complexité linéaire), mais ne demande pourtant que très peu d'itérations. Adam parle même d'intelligence des objets physiques, par opposition aux moteurs traditionnels, qui font plutôt subir la physique aux objets.

En bref cela donne un moteur, qui certes n'est pas capable de faire autre chose que ce que fait Doom3, mais est complétement fiable (et rapide !) dans la réalisation de cette tâche.

"... an engine that was for once designed by game developers for their specific needs, rather than following the conventional design that originated in academia".
Et ça c'est cool ! (n'oubliez pas l'éternelle querelle entre les mathématiciens et les informaticiens, cf les critiques de la scène démo à l'époque ;)

Comme certains s'en souviennent peut-être, je m'occupe de l'écriture d'un moteur de jeux 3D (cf article sur les moteurs physiques). En conséquence, ce blog risque de devenir une sorte de journal de bord (qui a dit Dev-Diary ?) de ce projet, complément beaucoup moins technique du forum déjà existant pour le projet.

Nous (les divers participants à ce projet) avons déjà été conviés à quelques salons (Linux Party) et festivals (Scopitone) sur la région nantaise. Nous nous sommes aperçu assez vite de la difficulté que représentait l'explication à des gens non initiés des concepts de moteur 3D, de moteur de jeu, et des différentes notions engendrées (texture, mesh, rendu, framerate, ...), ainsi que ce qu'implique la création d'un jeu vidéo.
Nous avons donc décidé lors de nos réunions de préparation au festival Scopitone de cet été dernier (festival des arts numériques et du multimédia furieusement éclectique, pour faire très court) qui représentait pour nous un énorme événement de produire une vidéo explicative, destinée à vulgariser totalement le projet Raydium.

Je viens de terminer la "remasterisation" de cette vidéo, avec l'intégration des sous-titres, et j'en profite pour poster le lien ici. Cette vidéo ne va probablement rien vous apprendre, sinon qu'on oublie vite à quel point un jeu vidéo est quelque chose de complexe quand on le décortique un peu :)
Pour un travail réalisé sur 2 week-end avec 3 personnes (pour la version originale), le résultat est plutôt sympa, même si je regrette qu'on y trouve encore trop d'extraits de vieilles vidéos de Raydium. Ah oué, y'a aussi l'encodage qui a merdé copieusement à la fin de la vidéo, qui se met à ramer ... (why ?)

Vidéo de présentation de Raydium à Scopitone 2004, env. 20 minutes, 27 Mo, 352x288, pas de son.