I. Introduction▲
Vous êtes bien avancé dans la création de votre jeu en ligne : la phase de conception devrait être achevée et le développement est en cours. Mais comment organiser ce développement pour aboutir à une version stable à proposer aux joueurs ?
Normalement vous disposez d'un cahier des charges décrivant un ensemble de fonctionnalités attendues pour la sortie du jeu et d'un planning dans lequel figure la tâche « développement » (ou l'ensemble de tâches dédiées au développement).
Au début du développement vous devriez donc avoir :
- le périmètre fonctionnel (ensemble des fonctionnalités, modules, etc. qui composent votre jeu) ;
- le planning prévisionnel.
Vos objectifs :
- respecter le planning, c'est-à-dire finir les développements à temps (cela n'arrive - presque - jamais) ;
- couvrir l'ensemble du périmètre défini : achever l'ensemble des développements à temps.
II. Phase 1 : développement▲
La première étape est forcément celle du développement initial, où vous et votre équipe allez créer l'ensemble des fonctionnalités définies dans le cahier des charges. Pendant cette phase, le jeu est disponible en général sur un serveur resté privé et dont l'accès est limité à l'équipe seule. Le développement est une tâche dont la durée dépend essentiellement du périmètre défini par le cahier des charges.
Cette phase de développement comporte des pièges ! Pendant toute la phase de développement, l'équipe n'a normalement aucun retour de la part des joueurs et est donc isolée. Si la durée de cette phase est trop longue (parfois plusieurs années…) les membres de l'équipe risquent de se démotiver et d'abandonner le projet (« on n'en voit pas le bout », « ah oui, mais maintenant je suis marié je n'ai plus le temps »).
Il est donc crucial d'avoir un périmètre fonctionnel raisonnable ! À quoi bon prévoir un jeu super complexe, avec des centaines de fonctionnalités dès son lancement, alors que vous n'êtes que deux développeurs ? Je pense que l'important est de sortir au plus vite une version stable et attrayante, du concret à fournir aux joueurs. J'ai déjà assisté à la mort de projets très bien avancés (plusieurs années) et pourtant jamais sortis au public, justement parce que le périmètre de base était probablement trop ambitieux. Il ne faut pas oublier que l'on parle bien de projets amateurs et qu'il est difficile de s'engager sur des mois et des mois de temps libre.
Pendant la phase de développement, partagez quelques informations avec vos futurs joueurs sur votre blog ou votre forum : cela permet d'avoir des retours et de susciter l'intérêt de votre communauté envers le projet.
Si vous vous rendez compte que le planning ne sera pas respecté, vous avez plusieurs possibilités :
- Réduire le périmètre pour économiser du temps de développement ;
- Revoir à la hausse la durée de la tâche de développement ;
- Trouver un développeur supplémentaire pour gagner en temps de développement.
Personnellement en cas de retard, je pense qu'il est plus sage de réduire le périmètre. En aucun cas il ne faut sacrifier la qualité des développements, car on le paie tôt ou tard. Enlever une fonctionnalité du périmètre original n'est pas une chose grave si elle n'est pas vitale au gameplay, elle apparaitra dans une mise à jour ultérieure. C'est aussi pendant la phase de développement que l'on peut se rendre compte que le chiffrage a été sous-estimé, d'où le besoin de réduire le nombre des développements (sous peine de sortir le jeu dans très longtemps, voire jamais).
Lorsque le développement est achevé, l'ensemble des fonctionnalités est disponible et il est temps de réaliser une version alpha (il est tout à fait possible de le faire sans le périmètre complet).
III. Phase 2 : alpha▲
La version alpha est une version interne à laquelle l'équipe seule a accès. Il est maintenant temps de tester de manière un petit peu plus poussée l'ensemble des fonctionnalités.
Normalement des tests unitaires sont réalisés au cours des développements : vous avez fini un module, vous le testez et vous validez le développement. Or il est possible qu'un module crée des régressions sur un autre module. Ainsi une fonctionnalité qui fonctionnait après son développement peut ne plus fonctionner à cause d'un autre développement, on appelle ceci une régression.
Si l'équipe met à jour un bogue, il convient (évidemment) de le corriger, par contre on ne touche normalement plus au périmètre : on n'ajoute pas de nouveau module.
Lorsque tout semble fonctionnel, vous pouvez envisager une version bêta.
IV. Phase 3 : bêta▲
Une version bêta est normalement (enfin !) ouverte aux joueurs et complètera les tests effectués lors de votre phase alpha.
Pourquoi faire une version bêta ? C'est assez simple, un utilisateur ne fera pas les mêmes tests que les développeurs, car un développeur esquivera instinctivement un certain nombre d'actions. Par exemple mettre des caractères interdits dans un champ de formulaire, cliquer où il ne faut pas, etc. Les joueurs vont probablement relever un certain nombre de bogues à corriger.
La version bêta permet également d'avoir un premier retour de la part des utilisateurs et de voir si le contenu séduit.
Je vous conseille de faire une version bêta restreinte : limiter le nombre d'utilisateurs. Pour choisir les heureux élus il y a plusieurs méthodes : inscription via e-mail et tirage au sort, inscription libre, mais limitée à 100 joueurs, sélection « à la main » des chanceux, etc.
La phase bêta donne logiquement lieu à une remise à zéro (« reset ») du jeu. À son lancement final, il convient de prévenir les joueurs pour qu'ils ne s'attachent pas trop à leur compte, mais privilégient bien la recherche de bogues et anomalies.
Pensez à proposer une structure de déclaration de bogues, que ce soit via un outil comme Trac, une adresse e-mail ou tout simplement votre forum. C'est une véritable chasse aux bogues qui va avoir lieu.
Vous devez mettre à jour la version bêta fréquemment avec les corrections des bogues déclarés, le but étant d'arriver à une version stable assez rapidement.
La version bêta vous permet également d'affiner le gameplay en prenant en compte les commentaires des premiers joueurs. Il ne s'agit pas vraiment de bogues, mais plus de feedback sur l'ergonomie, les mécanismes de jeu, l'équilibrage de plusieurs classes, etc. Impliquez vos bêtatesteurs, motivez-les, répondez à leurs questions.
Lorsque la totalité des bogues détectés est corrigée et que votre jeu dispose d'une version avec un périmètre fonctionnel satisfaisant, vous pouvez envisager le lancement de votre jeu. Vous pouvez aussi effectuer des phases de release candidate (RC) ou prérelease, sorte de version quasi finale à valider, mais je ne suis pas sûr que ce soit utile.
V. Phase 4 : version finale, release▲
Votre jeu est enfin prêt et les joueurs sont prêts à se ruer dessus (espérons-le). Organiser la sortie d'un jeu est un petit peu délicat, car elle doit idéalement être accompagnée d'une campagne de promotion.
Ce que je peux vous conseiller c'est de fixer une date à l'avance dès que vous savez que le jeu est prêt, et de la communiquer aux joueurs. Faire du buzz et du teasing, c'est à la mode et il semblerait que cela fonctionne bien. Cela vous permet aussi de préparer techniquement le jeu pour le jour J.
Une erreur à ne pas faire au moment du lancement est de surestimer votre serveur. Ce serait dommage d'avoir des problèmes le jour J parce qu'il y a trop de monde à la porte de votre jeu, surtout qu'à priori vous n'avez pas pu faire de tests de montée en charge concrète avant le lancement (sauf pendant la version bêta qui était probablement limitée en nombre de personnes). Lors de l'ouverture du jeu, vous pouvez fixer un nombre maximum de joueurs que vous augmenterez progressivement en surveillant la charge du serveur (gardez de la marge).
Il vaut mieux prévoir une date suivie de quelques jours où vous serez disponibles, car on ne sait jamais ce qui peut se passer (plantage du serveur, bogues critiques, etc.). Il faudra être très réactif et déployer un patch correctif rapidement en cas de problème bloquant.
Une fois votre version finale en ligne et ouverte aux inscriptions des joueurs, ce sont des mois de travail qui aboutissent enfin et vous allez rentrer dans le merveilleux monde de l'administration ! Un nouveau cycle de développement sera également à mettre en place (versioning, mises à jour, itérations, mises en production, etc.).