Développer son MMORPG - Choisir un language

Premier épisode d'une petite série qui durera ce qu'elle durera! A travers ces années à essayer un peu tout et n'importe quoi, voilà quelques idées sur le sujet des langages de programmation pour les MMO.

Les forums de développement de jeu regorgent de questions relatives aux langages qui sont les mieux adaptés à tel ou tel type de jeu. Lorsque l'on rajoute par dessus les besoins de performance et la complexité du développement d'un MMO, la question du langage devient particulièrement épineuse.

Avec AdH, on a un peu tout essayé: serveur en ocaml et c++, client en ocaml et c++, outils en ocaml, c++, java. Rajoutez quelques essais web avec PHP et .NET, une couche de SQL d'une épaisseur plus que changeante. Voilà donc ce qui a donné l'impression de marcher:

• Il n'y a pas de langage parfait, et entre deux choix raisonnables, le mieux est de choisir quelque chose qui soit bien connu par les membres de l'équipe, et qui soit suffisamment utilisé par ailleurs pour trouver tout un tas de ressources sur le sujet. Développer son Tetris ou son Pacman pour apprendre un nouveau langage, c'est une excellente idée. Démarrer un WOW-killer à cloche pied avec l'idée d'apprendre en route, beaucoup moins! Également, il est préférable d'éviter les langages trop ésotériques, et choisir des technologies stables, matures et pour lesquels il sera facile de trouver de l'aide.



• Choisir un langage, c'est aussi choisir un écosystème. Pour cette raison, il est important d'identifier les bibliothèques disponibles. Pour les graphismes, une implémentation OpenGL bas niveau ne suffit généralement pas: avez vous vraiment envie de développer un graphe de scène, d'écrire le code de chargement pour les objets 3D, ou de devoir convertir toutes vos images dans un seul format? Vous aurez suffisamment à coder comme ça pour vous embêter à écrire une couche de base de données, un moteur graphique, une couche réseau haut niveau, un bon support des threads, des bibliothèques pour charger et jouer les sons, charger les images, et j'en oublie.



• Un même langage pour le client et le serveur. C'est un point très discuté, et pour cause. Avec un serveur et un client qui ont fondamentalement des buts très différents (graphismes et sons, portabilité, performances brutes pour le client - réseaux, bases de données, montée en charge pour le serveur), il est tentant de choisir deux langages. Notre expérience est qu'avec deux langages et une petite équipe, on se heurte à tout une série de problèmes:
  
  
  
  • Souvent, les membres de l'équipe se spécialisent, et il est difficile de faire bouger des gens du serveur au client et vice-versa
  
  
  • Tous les utilitaires bas-niveau doivent être ré-écrits deux fois
  
  
  • La communication entre le client et le serveur devient plus complexe, il y a d'avantages de risques liés à la sérialisation des données
  
  
  • De manière générale, une perte de temps bien supérieure aux gains potentiels
  
  


• Un langage plus agile pour les outils. L'émergence de nouveaux langages de script tels Python, Ruby, Perl et autres peuvent fournir des opportunités pour développer rapidement des outils. La difficulté est de bien s'assurer qu'ils seront peu couplés avec l'application principale: par exemple, un éditeur de monde avancé aura probablement besoin des mêmes structures que le client et le serveur, et le choix d'un langage différent pourrait au final causer une perte de temps. En revanche, la création rapide de donnés, d'un panneau administratif, ou encore la génération de code, peuvent bénéficier des langages de script. Par exemple, dans AdH, le langage Ocaml est utilisé pour générer le code C++ de sérialisation des messages, ce qui a sauvé beaucoup de temps de développement.

Allez hop, maintenant on s'y met!