L’apprentissage du langage SCOL a surtout été rallongé à cause du caractère fonctionnel du langage. Il est vrai qu’en sortant de l’Epita, on est plus porté sur la programmation traditionnelle en C/C++. Il a donc été nécessaire de passer un temps non négligeable du stage à comprendre, essayer puis maîtriser la plupart des possibilités offertes par le langage SCOL.
Il faut avoir une très bonne maîtrise de SCOL pour passer à la programmation modulaire distribuée en client/serveur du DMS. En effet, les choses se compliquent de plusieurs faits : cette architecture est censée être facile à utiliser au niveau le plus haut : l’utilisateur du module DMS (pour qui tout est simplifié à l’extrême, puisqu’idéalement il n’a pas besoin de connaissances en programmation pour utiliser les modules) et donc elle est relativement complexe à mettre en œuvre pour concevoir puis programmer un module ; ensuite les nombreuses nouvelles fonctionnalités offertes par cette architecture (telles que le téléchargement automatique et complètement transparent des ressources, tant au niveau des fichiers sources que des fichiers graphiques). Bref, l’ensemble produit un niveau de complexité effrayant de prime abord. De fait, il est en pratique impossible d’assimiler le contenu de la documentation sans se référer à l’expérimentation et à la consultation de sources de modules existants.
Une fois maîtrisés le SCOL et l’architecture DMS, l’utilisation de l’éditeur est un vrai jeu d’enfant. Enfin le serait s’il avait existé de la documentation sur la façon de lier les modules entre eux. En effet, lors de mon auto-formation, cette documentation n’avait pas encore été écrite et il fallait apprendre à utiliser l’éditeur sans aucune information pratique. Il fallait donc découvrir la façon d’intégrer un module, la façon de lui affecter une zone, ainsi que les différentes façons de le lier aux autres modules par les couples réflexe DMS – actions DMS. Evidemment, les dizaines de modules n’étaient pas mieux documentés et il fallait comprendre leur utilisation avec comme seule information les noms de leurs réflexes et actions.
La participation à la phase de pré-production du jeu Bürgermeister a été l’occasion de voir un projet de jeu naître et se définir au fur et à mesure que l’élaboration du game-design avançait. En effet le scénario n’était pas figé et évolué en bien pendant toute la durée du stage. Evidemment, la maquette demandée a suivi elle aussi les nombreux revirements de tendance tout au long de cette période. Cette maquette a impliqué non seulement l’utilisation de modules DMS existants (car sans se servir des matériaux existants le stage aurait été beaucoup trop court pour aboutir au même résultat) dans l’éditeur SCS, mais aussi la programmation d’un module DMS essentiel puisque toute l’équipe avait décidé d’avoir une vue depuis une caméra située légèrement haut dessus et derrière l’avatar du joueur et que les modules existants n’offraient pas cette possibilité. Cette maquette a aussi fait appel à des notions de synthèse puisqu’il a fallu tirer la quintessence du game-design pour que le résultat soit aussi proche que possible de ce que souhaitait l’auteur du scénario.
La conception et la programmation des deux modules pour le projet on-line Cryopolis 2 a en fait été déclenchée à cause d’une coïncidence fortuite : lors du développement du module permettant d’avoir une vue au-dessus de l’avatar de la maquette de Bürgermeister, j’ai eu l’occasion d’utiliser des fonctions particulières d’accès à la scène 3d. Et une semaine avant la mise en ligne officielle du site de promotion Cryopolis 2, il manquait à l’équipe de développement quelqu’un possédant justement ces connaissances. J’ai donc été " muté " pendant le temps de la conception et du développement de deux modules au projet Cryopolis, sous la direction de Laurent Doubre. Le principe de ces modules s’articulait sur les particularités du moteur 3d de SCOL, qui organise la scène 3d dans une hiérarchie de nœuds sous forme d’arbres : les deux modules devaient agir sur cette hiérarchie pour la modifier.
L’affectation au projet en post-production Scotland Yard a été décidée la encore au dernier moment, quelques semaines seulement avant la mise en presse pour la duplication du master. Ici, le but à atteindre était l’élimination du plus grand nombre de bugs possible en y passant le moins de temps possible. Et si c’était faisable, il fallait tenter de réduire la taille requise lors de l’installation du jeu, qui était démesurée par rapport aux besoins. En effet, les concepteurs des fichiers graphiques avaient oublié le facteur de granularité du disque dur qu’est le cluster, et avaient donc créé des milliers de minuscules fichiers au lieu d’un plus gros fichier ; ce faisant, le nombre de cluster utilisés était multiplié par 50. D’où une installation de 250Mo pour le jeu !
Enfin, l’étude réseau pour se prononcer sur la faisabilité physique du projet Bürgermeister a donné lieu à des résultats surprenants pour tout le monde. En effet, la capacité théorique d’un serveur SCOL/DMS avait été fixé à la hâte à des milliers d’utilisateurs simultanés. En fait il s’agissait de simples calculs qui ont mené à ce résultat qui est apparu erroné lors de l’étude, puisque même si effectivement le serveur supporterait techniquement cet énorme nombre de clients sur un réseau ultra-rapide, il a été clair au vu des résultats de cette étude que sur un débit lent de type Internet par modem ou même par ligne spécialisée, la qualité de service (par exemple le nombre de positions par seconde pour chaque avatar visible dans la scène 3d) était vraiment très faible dès que l’on dépassait la dizaine de connectés. Il a donc fallu imaginer de nouvelles techniques de distribution de l’information pour rendre possible le jeu Bürgermeister.