Processus de développement d'un jeu massivement multi-

Le livre écrit par Jessica Mulligan et Bridgette Patrovsky [72] est une source assez représentative du processus industriel qui mène à la réalisation d'un jeu massivement multi-joueurs (ou de ce qu'il devrait être dans l'idéal selon les experts, tout du moins). Nous allons ici commenter certaines étapes de ce processus.

3.2.3.1 La conception fonctionnelle et technique

Les auteurs recommandent un développement qui suit un cycle de vie qu'on peut rapprocher du cycle incrémental, et pour faciliter et sécuriser le développement, recommandent l'utilisation ou le développement préalable d'outils logiciels dédiés d'un haut niveau d'abstraction, comme des moteurs d'intelligence articielle, graphiques ou réseau, dédiés à la gestion des dié- rentes fonctionnalités du jeu. La conception et le développement du game-play lui même suivent un cycle de vie de style cascade.

Avant que quoi que ce soit ne soit implémenté, il est recommandé de passer par une étape cruciale de conception. La conception des mécanismes, des règles du jeu et la conception technique sont réalisées en parallèle dans le même temps, et les concepteurs dans chaque domaine doivent collaborer étroitement : dans un jeu massivement multi-joueurs, il y a des interactions qui ne peuvent pas être réalisées techniquement, qui requièrent de considé- rables investissements en solutions d'hébergement et de déploiement, ou qui seront très délicates à mettre au point. Le but de cette première étape est de concevoir le game-play du jeu, dans ses aspects à la fois techniques et fonctionnels.

Pour que cette première étape soit un succès, il n'y a actuellement pas d'autre support que de bonnes pratiques de conduite de projet. Cependant, le travail créatif qui consiste à concevoir les aspects fonctionnels (les règles et la mécanique) d'un jeu demande des compétences très diérentes de celui qui consiste à concevoir le logiciel lui-même, en tenant compte des aspects techniques complexes qui y interviennent (réseau, concurrence, passage à l'échelle). Ce sont des domaines d'expertise totalement diérents. Pour que la communication soit ecace, il faut souvent l'intervention d'un concepteur

3.2. PROCESSUS ET DIFFICULTÉS DE MISE AU POINT 89 fonctionnel avec un solide bagage technique ou à l'inverse, d'un technicien ayant de bonne notions et une bonne expérience dans la conception de jeu.

De plus, même si l'équipe de développement comporte un de ces pré- cieux spécimens, ou en engage un pour la durée de cette première phase, ce que dicte l'expérience se résume souvent à : ce qui a marché pour un jeu précédent devrait marcher cette fois encore.

3.2.3.2 Le beta-test

La dernière étape de la réalisation d'un jeu, juste avant que le jeu ne soit déployé, est appelé le beta-test, et consiste à faire tester le jeu par des utilisateurs. C'est une étape héritée de l'histoire du développement de jeux- vidéo, datant de l'époque où les jeux étaient développés en peu de temps par une équipe réduite.

Après un alpha-test réussi qui consiste à tester le jeu à une petite échelle sur un réseau fermé et sans essayer de passer à l'échelle en nombre de joueurs, le jeu est testé par des joueurs dans des conditions réalistes de déploiement. Le principe du beta-test est de pousser le jeu à ses limites, en terme de performances et de ressources matérielles. Cette phase est aussi celle où les conséquences des inévitables réactions imprévisibles des joueurs vont être ob- servées. En bref, c'est l'étape lors de laquelle les conséquences d'une concep- tion insusante à faire correspondre les aspects fonctionnels et techniques vont se révéler.

3.2.3.3 Critique de ce mode de production

Entre les deux phases précédentes, il peut s'être passé des mois et parfois des années de développement très coûteux (le développement d'un jeu massi- vement multi-joueurs fait intervenir des équipes de tailles conséquentes). Le coût d'un retour en arrière pour ajuster les solutions techniques au game- play, ou pour revoir le game-play par rapport à des problèmes majeurs de jouabilité, peut être susant pour causer la banqueroute du projet.

Un bon moyen de minimiser ce genre d'erreur serait de réaliser un pro- totype pour tester la conception technique des interactions, et de l'utili- ser conjointement avec des outils de simulations de conditions critiques de

ressources matérielles (perte de message réseau, augmentation de latence, consommation de CPU...). Une telle approche permettrait d'aider à décou- vrir plus tôt dans le déroulement du projet quelles recettes techniques peuvent permettre de réaliser les fonctionnalités voulues. Cette approche permet éga- lement d'encourager les projets de jeux innovants du point de vue des in- teractions possibles, en démontrant précisément, lors de la première étape de conception, quelles fonctionnalités sont faisables, et d'observer si elles ont une bonne qualité de jouabilité dans des conditions réelles. Même s'il peut être dicile de simuler ou de prédire le comportement des joueurs lorsque le jeu sera enn terminé (les endroits du monde virtuel qu'ils choisiront pour se rassembler ou pour se battre, et donc les machines du serveur correspon- dant dans certains choix d'architecture par exemple), le fait de réaliser un prototype réduit grandement le risque d'un beta-test désastreux.

Cependant, le prototypage a encore une très mauvaise image dans l'indus- trie du jeu vidéo, parce qu'un bon prototype prend du temps, et parce que la plupart du temps, le code produit n'est pas exploitable après coup. Eectué souvent trop vite et dans l'urgence à des simples buts de démonstration, il manque de réutilisabilité. C'est donc considéré comme une perte de temps.