Il y a quelques mois (début mai exactement), Ray Muzyka, co-directeur général de BioWare et co-producteur exécutif de Baldur’s Gate II, s’est lancée dans une LONGUE tirade sur Gamasutra afin de nous faire partager le défi qu’a été le développement de cette suite. Nous vous en proposons la traduction ci-dessous. Passionnant !


Introduction :

Il y a un peu plus de deux ans, Baldur’s Gate est sorti. C’était l’aboutissement de près de 90 années-homme (ndlr : travail cumulé sur le jeu) de travail par un certain nombre de personnes inexpérimentées, mais très talentueuses et créatives chez BioWare. BioWare était un développeur de jeux canadien, qui n’avait qu’un seul titre (Shattered Steel) à son actif avant Baldur’s Gate. Publié par Black Isle Studios (la division RPG interne d’Interplay Productions), Baldur’s Gate était le prochain d’une série de RPG célèbres comprenant le vénérable Bard’s Tale et le très respecté Fallout, tous deux développés par Black Isle. Baldur’s Gate a battu les pronostics et a été un succès à la fois critique et commercial (il a reçu presque tous les prix du RPG PC de l’année et quelques prix du “Jeu de l’année”, et il s’est depuis vendu à environ 1,5 million d’exemplaires dans le monde).

Après le succès retentissant de Baldur’s Gate, BioWare a commencé le développement de Baldur’s Gate II et s’est attaché à prouver que la magie de Baldur’s Gate pouvait non seulement être répétée, mais qu’un grand jeu pouvait être encore amélioré.

Le défi

Construire une excellente suite n’est pas aussi facile qu’il n’y paraît. En créant BG2, nous savions que tout le monde examinerait le résultat avec beaucoup d’attention. Nous avons fait des comparaisons avec de nombreux grands jeux utilisant notre moteur BioWare Infinity, comme Baldur’s Gate, Icewind Dale et Planescape : Torment (ces deux derniers jeux ont été développés par les studios Black Isle de notre éditeur après avoir obtenu une licence du moteur Infinity de BioWare à cet effet).

En développant une suite, vous devez commencer avec la bonne philosophie : le but doit être de rendre le jeu meilleur, et pas seulement de refaire le même jeu. Vous devez également disposer d’un mécanisme permettant de quantifier vos erreurs précédentes et d’en tirer les leçons. Si vous ne vous efforcez pas de comprendre ce que vous avez fait de mal la dernière fois, vous n’arriverez probablement pas à le réparer la deuxième fois.

Chez BioWare, nous avons appris à faire des examens approfondis après chaque projet afin d’analyser leurs points forts et leurs points faibles en matière de développement. La meilleure façon de commencer une suite est de revoir et d’améliorer les processus utilisés dans le projet initial. Dans le cas du Baldur’s Gate original, nous avons estimé que nous n’avions pas assez de temps pour atteindre nos objectifs de conception ; nous développions simultanément le moteur Infinity de BioWare tout en créant le contenu de Baldur’s Gate. Cela a entraîné une pression extrême pour avoir des zones et une conception de jeu simples. Avec Baldur’s Gate II, nous avons décidé d’accorder aux concepteurs le temps nécessaire pour permettre au jeu d’atteindre son plein potentiel. Nous avions appris à revoir nos projets précédents, à tirer les leçons de nos erreurs et à appliquer ces solutions à tous les projets nouveaux et en cours.

Faire une liste de caractéristiques :

La création d’une liste de caractéristiques doit faire partie de toute phase de conception. Grâce à la licence AD&D attachée à Baldur’s Gate II, nous avons pu ajouter des milliers de fonctionnalités possibles au jeu. Dans ce cas, notre défi consistait à déterminer les fonctionnalités à ajouter. Nous avons utilisé deux méthodes : la première consistait à dresser une liste interne (générée par BioWare et notre éditeur Black Isle/Interplay) de ce qui était faisable et raisonnable compte tenu du moteur, et la seconde consistait à demander aux fans ce qu’ils voulaient voir. Heureusement dans le cas de BG2, un certain nombre de fans sur les newsgroups avaient déjà fait une grande partie du travail pour nous, et ont compilé une liste de ce qu’ils voulaient voir dans BG2. Cette liste nous a donné une idée de ce qu’attendaient nos principaux fans et nous a aidés à nous orienter dans la bonne direction. La liste des principales caractéristiques que nous avons finalement établie ressemblait à ceci.

  1. Résolution supérieure (800×600 et plus).
  2. Support 3D pour les cartes graphiques 3D.
  3. Dialogue sans pause en mode multijoueur.
  4. Panneaux déroulants dans l’interface.
  5. Multiples nouveaux kits de personnages (sous-classes) pour toutes les classes.
  6. Mouvement plus rapide des personnages.
  7. Double maniement des armes.
  8. Amélioration de l’animation des personnages (plus de détails et plus d’images).
  9. Inclusion de tous les monstres AD&D “célèbres”, y compris le plus célèbre de tous, le dragon.
  10. Sorts jusqu’au 9ème niveau.
  11. Journal simplifié, carte annotable.
  12. Mode Death Match.
  13. Interaction avec les personnages comme dans Final Fantasy.
  14. Romances de personnages.
  15. Chemins du mal et du bien définis pour permettre un jeu de rôle basé sur l’alignement.

Nous avons ajouté plusieurs caractéristiques au fur et à mesure du développement du jeu, notamment une nouvelle race (le demi-orque) et trois nouvelles classes (sorcier, moine et barbare), ainsi qu’une myriade de kits de personnages. Très peu de fonctionnalités ont dû être coupées ou n’ont pas été implémentées de manière à fonctionner aussi bien que nous l’espérions.


Le demi-orque était l’une des nombreuses nouvelles fonctionnalités ajoutées au fur et à mesure du jeu.

Une chose que nous n’avons pas faite a été de classer les caractéristiques du jeu en classes simples telles qu’essentiel, important, moins important, etc. Lorsqu’il s’agissait de prendre des décisions concernant les caractéristiques, nous avons choisi d’en garder autant que possible, mais nous n’avions pas de liste ni de mécanisme convenu pour résoudre les décisions. Heureusement, nous utilisions un moteur mature que nous avions développé, de sorte qu’il était relativement facile d’ajouter la plupart des fonctionnalités. Cependant, nous ne pouvons certainement pas prétendre que toutes nos décisions ont été éclairées.

Le deathmatch était une fonctionnalité qui aurait dû être supprimée dès le début, mais qui a persisté jusqu’à la fin du projet. Il est alors devenu évident que la date du projet devait être repoussée pour tenir compte du deathmatch. Étant donné que le code multi-joueurs était l’un des plus fragiles du moteur et que le deathmatch n’était pas très bien accueilli par l’assurance qualité, nous avons décidé à contrecœur de le supprimer.

Le dialogue sans pause a été l’élément le plus problématique. Au début du projet, il a été coupé en raison de contraintes de temps. Au début de l’année 2000, nous avons décidé de le réintégrer, car la quantité de dialogues dans le jeu rendait le multijoueur très frustrant. Avec le recul, c’était probablement la mauvaise décision. La plupart des dialogues avaient déjà été écrits en supposant que le jeu s’arrêtait en mode dialogue. Nous devions créer un système hybride où le dialogue important de l’intrigue serait encore en pause. Nos modifications du code multijoueur ont également créé plusieurs instabilités qui ont conduit à des nuits de travail très tardives pour les programmeurs.

Les leçons que nous avons apprises incluent la nécessité de dresser une liste des caractéristiques, de les classer par ordre d’importance et de noter quelles caractéristiques peuvent être supprimées si nécessaire. Nous avons également appris à ne pas prendre de décisions à la légère – l’annulation d’une décision de développement ne doit être envisagée que si elle est absolument essentielle et seulement après avoir été soigneusement étudiée.

Les lignes directrices en matière de dessins et modèles :

Une chose que nous ne voulions absolument pas faire avec Baldur’s Gate II était de faire les mêmes erreurs de conception que celles que nous avions commises avec le jeu original. Comme certains membres de notre équipe étaient tout neufs et que beaucoup de nos souvenirs (ceux des auteurs) semblaient plutôt flous, nous avons décidé d’établir un ensemble de “lignes directrices”. Bien que chaque département ait eu son propre ensemble de directives, la directive de conception des niveaux était de loin la plus importante, car c’était le domaine où il y avait le plus de possibilités d’amélioration dans Baldur’s Gate II. Vous trouverez ci-dessous une version tronquée de la directive utilisée par les concepteurs du jeu :

Règles de conception de base :

  1. Le joueur doit toujours avoir l’impression que ce sont ses actions qui le font réussir. Il doit avoir le sentiment qu’à travers ses décisions et ses actions intelligentes, il a résolu une énigme ou une bataille.
  2. Le joueur doit avoir le sentiment d’avoir un effet sur l’environnement. Ses actions font une différence TRÈS visible avec la façon dont les choses fonctionnent dans le monde du jeu. Ses actions ont des conséquences.
  3. Lors de la conception, il faut tenir compte du bien et du mal. Plusieurs parties doivent être marquées comme variant en fonction de l’alignement du joueur.

Conception de l’histoire : 

  1. L’histoire doit toujours mettre l’accent sur le joueur. Le joueur fait partie intégrante de l’intrigue, et tous les événements doivent tourner autour de lui.
  2. Il est important que le joueur soit tenu informé de la progression du méchant. Cela peut se faire par le biais de scènes coupées lors des transitions de chapitre, ou en l’intégrant dans l’intrigue principale de temps en temps.
  3. Il est important qu’il y ait un rebondissement dans l’histoire (ou même plus d’un rebondissement). C’est là qu’une révélation est faite au joueur qui l’amène à réévaluer ce qui se passe dans l’histoire. Tous les rebondissements doivent impliquer l’acteur principal. Les rebondissements que le joueur découvre par lui-même sont également meilleurs.
  4. Il est bon de garder la fin de l’histoire ouverte, surtout si une suite ou des packs d’extension sont prévus.

Conception de l’environnement :

  1. Le monde du jeu doit être divisé en chapitres. Chaque chapitre doit être de taille et de potentiel d’exploration identiques. Chacun de ces chapitres doit avoir un objectif assez évident, mais que le joueur peut atteindre de la manière qu’il veut.
  2. Certaines zones doivent être marquées comme zones centrales. Ces zones sont généralement des villes ou des endroits similaires où le joueur retournera souvent. Les zones centrales doivent changer en fonction de l’évolution de l’environnement. Lorsque le joueur effectue des actions dans d’autres zones, les zones centrales doivent être modifiées en conséquence.
  3. Le joueur doit toujours avoir le sentiment d’explorer des zones intéressantes. Cela signifie que les zones doivent toujours présenter un aspect artistique unique.
  4. Ce n’est pas une bonne idée que le joueur se déplace souvent d’une zone à l’autre. Cela devient ennuyeux. Les intrigues doivent rester dans les limites d’une seule zone.
  5. Il est bon de montrer au joueur des choses qu’il ne peut pas utiliser ou des endroits où il ne peut pas aller. Plus tard, ces objets ou ces lieux seront activés.

Esquisse de concept pour un temple dans Baldur’s Gate II.

Conception de systèmes de jeu :

  1. Un système de récompense bien pensé doit être créé. Le joueur doit être récompensé DEUX fois au cours du jeu. Ces récompenses peuvent prendre la forme d’XP, d’objets, de récompenses d’histoire, de nouveaux sorts, de nouveaux monstres, de nouveaux arts, de romances, etc.
  2. Il est important que le joueur soit en mesure de personnaliser son personnage. Il est important que le joueur puisse personnaliser son personnage. Cela signifie qu’il doit sentir que l’avatar qu’il joue est le sien.
  3. Il est important que le monde reflète les façons dont le joueur a personnalisé son personnage.

Directives de rédaction :

  1. Pas de grossièretés des temps modernes. Cela exclut les injures mineures, c’est-à-dire les blasphèmes de type “damn, hell, bitch, bâtard”.
  2. Chacun des nœuds de dialogue (paragraphe de dialogue) prononcés par un PNJ doit être limité à deux lignes. Ce n’est que dans de très rares circonstances que plus de deux lignes sont utilisées.
  3. Toutes les réponses des personnages doivent être d’une ligne lorsqu’elles apparaissent dans le jeu. Il ne devrait pas y avoir de raison qu’elles soient plus longues que cela.
  4. Essayez de ne pas utiliser d’accents dans les dialogues. Pour certains personnages (Elminster, types de marins), c’est correct, mais pour la plupart, il faut l’éviter.
  5. Lorsque vous utilisez les choix des joueurs, essayez de garder le chiffre visible à environ trois. Deux ou quatre, c’est bien, mais seulement si c’est vraiment nécessaire.
  6. Lorsqu’un PNJ parle directement au joueur principal, il faut le noter pour les besoins du script. D’autres dialogues doivent être inclus lorsqu’une personne autre que le joueur principal parle à ce personnage.
  7. Les dialogues aléatoires doivent être évités, ou du moins utilisés avec modération. Les roturiers ne devraient avoir que quelques lignes de dialogue aléatoires, mais il devrait y avoir plusieurs roturiers différents avec qui parler.

Il y a quelques points importants à souligner concernant ces lignes directrices. Premièrement, elles sont en cours d’élaboration et la version que vous voyez ici n’est pas celle que nous avons utilisée au début du processus de développement. Deuxièmement, nous les avons considérées comme un ensemble de lignes directrices, et non comme la loi absolue. Si une situation imposait de ne pas suivre ces lignes directrices, et que cela avait un sens, les concepteurs disposaient de la liberté nécessaire pour suivre leurs objectifs créatifs. Parfois, cela fonctionnait et parfois non.

Nous avons établi des tailles maximales pour les fichiers audio, et des tailles maximales (à la fois en surface et en nombre d’images de l’animation) pour les jeux d’orthographe.

Rétrospectivement, il aurait été très utile de disposer de cet ensemble de lignes directrices au début du projet, plutôt qu’à la fin. Un certain nombre de décisions qui ont été prises très tôt dans le développement de Baldur’s Gate II n’ont pas suivi les lignes directrices et ne pouvaient pas être annulées. Le plus remarquable est le chapitre 2 du jeu – il comprend un segment d’histoire similaire à ceux des autres chapitres, mais dans le chapitre 2, le joueur peut également accéder à toutes les sous-quêtes spécifiques à une classe. Ainsi, le chapitre 2 pouvait potentiellement éclipser tous les autres chapitres en termes de longueur, car les joueurs pouvaient passer 60 heures à faire des sous-quêtes. Nous devions placer les sous-quêtes à un point où tous les joueurs pouvaient y accéder de la même manière, mais le résultat final a été de gonfler la première section du jeu. Au final, nous n’avons rien pu faire pour corriger la disparité entre les chapitres, nous avons donc simplement contourné le problème.

Un autre problème majeur était lié aux contraintes de programmation qui avaient été établies dès le début du projet et qui n’étaient pas suivies dans tous les cas par les autres départements (design et art). Par exemple, nous avions établi des tailles maximales pour les fichiers audio, et des tailles maximales (à la fois en superficie et en nombre d’images d’animation) pour les jeux d’orthographe, ainsi qu’une taille maximale de six par six zones de 640×480 et un nombre maximal de caractères par zone. Dans certains cas, ces directives n’ont pas été suivies, ce qui a entraîné des ralentissements de la cadence d’images à certains moments du jeu. Cela a conduit à des efforts d’optimisation frénétiques pour accélérer le jeu vers la fin du cycle de développement, alors qu’il restait peu de temps pour identifier les zones problématiques et les corriger.

La leçon que nous avons tirée ici est qu’il faut établir des directives de développement, les suivre, mais aussi travailler continuellement à l’affinement de ces directives en fonction de l’évolution du jeu.

Améliorer le processus :

L’un des éléments les plus importants de tout processus de développement de jeux est le processus d’élaboration de l’art et du contenu. Le cheminement est le moyen par lequel les artistes et les concepteurs mettent leur contenu dans le jeu. Pour l’essentiel, le système de pipeline de Baldur’s Gate II est resté le même que celui du Baldur’s Gate original. Dans BG1, le contenu était plutôt nébuleux au départ, mais il s’est concrétisé à la fin du jeu. Avec Tales of the Sword Coast (l’extension de BG), nous avions encore 4 mois pour affiner l’ensemble du processus de création de contenu.

Concept art pour Baldur’s Gate II.

Il y a quatre divisions de base dans le système de Baldur’s Gate : les fonctions de programmation, les films, les animations de jeux et les niveaux de jeux. La plus grande et la plus complexe de ces divisions est le réseau de niveaux de jeu. En entrant dans BG2, nous avons suivi un processus en huit étapes pour créer les niveaux du jeu. Le processus de création d’un niveau de jeu était :

  1. Les concepteurs dessinent la carte d’une zone et en rédigent une description.
  2. Le concepteur dessine un concept isométrique du niveau.
  3. Des modèles sont créés pour le niveau.
  4. Les modèles sont placés dans le niveau et ensuite texturés.
  5. Le niveau est habillé avec des objets plus petits (barils et chaises). L’éclairage est fait pour le niveau, puis les derniers réglages sont effectués.
  6. La maquette est remise aux concepteurs afin que le découpage, la luminosité, la hauteur et la carte de recherche puissent tous être réalisés.
  7. Les créatures, les objets, les pièges et les déclencheurs sont tous ajoutés au niveau.
  8. Les scripts du niveau sont terminés.

À la fin du projet, nous avions constaté plusieurs faiblesses dans la procédure globale. Nous avons constaté qu’il nous fallait un meilleur moyen de documenter les changements apportés à un niveau de jeu pendant le développement. Nous avions essayé de garder nos documents Word aussi à jour que possible, mais avec le nombre de personnes impliquées et l’énormité du jeu, il était presque impossible de garder ces documents complètement fiables. Certaines personnes de cette large équipe ont travaillé indépendamment les uns des autres – les concepteurs n’ont parfois pas été en contact avec les artistes de manière adéquate, ce qui a entraîné l’absence d’éléments dans les zones de jeu et des conventions de dénomination différentes entre l’art et le design, ce qui peut constituer un énorme problème si l’on considère que BG2 comportait des centaines de zones et des milliers de créatures et de pièces graphiques uniques. L’amélioration de l’intégration entre les différentes disciplines (programmation, art, design, assurance qualité, audio, etc.) est désormais un objectif pour tous nos projets. Par exemple, dans Neverwinter Nights, nous disposions d’une base de données (appelée Event Editor) dans laquelle nous gardions la trace de toutes les modifications apportées à un niveau de jeu, de sorte que les développeurs des différentes zones puissent tous être informés simultanément de l’état spécifique du contenu du jeu.

Un autre oubli dans le processus de conception des niveaux de Baldur’s Gate II a été l’absence d’une phase de test précoce spécifique (en fait, la neuvième phase de développement de la zone). Un test précoce d’un niveau de jeu nous aurait permis d’apporter des modifications et des ajustements pendant le développement du niveau, alors qu’il était encore relativement facile à modifier, plutôt que de le faire lors du passage final des tests d’assurance qualité. Cela aurait permis de rationaliser le processus de test final. Au lieu de cela, nous n’avons pas commencé les tests avant que de grandes parties du jeu soient entièrement terminées. Pendant que Baldur’s Gate II était en cours de développement, nous avons ajouté un département interne d’assurance qualité  afin de faire plus de tests préliminaires. Nous pouvons maintenant faire passer les niveaux de jeu par ce département dès que nous avons une version de travail du niveau et l’affiner plus tôt que plus tard. Notre éditeur Black Isle/Interplay a également apporté un soutien important en matière d’assurance qualité, puisque certains testeurs ont visité BioWare au cours des derniers mois du projet et d’autres tests d’assurance qualité ont été effectués chez Black Isle/Interplay.

Il est intéressant de noter que nous avons fait un si bon travail pour automatiser le processus de développement des niveaux que nous avions peu de temps pour réviser un niveau de jeu au fur et à mesure des étapes. Un concepteur pouvait soumettre une description de niveau et la recevoir, prête à être scénarisée, un mois plus tard, mais il lui manquait certaines caractéristiques clés (presque toujours une porte). Nous devions alors déterminer si l’omission était suffisamment importante pour faire refaire le graphisme, ou si nous pouvions simplement modifier la conception du niveau pour qu’il corresponde au graphisme fini. Là encore, cela renvoie à la question de l’intégration des disciplines, un point sur lequel nous allons constamment travailler dans le cadre de nos projets RPG à grande échelle.

L’écran d’inventaire de Baldur Gate II.

Pendant le développement de Baldur’s Gate II, nous avons ajouté des producteurs délégués pour aider les trois producteurs à maintenir la communication entre les équipes et le suivi des tâches. À la fin de Baldur’s Gate II, un producteur délégué/concepteur a été affecté à la réalisation des builds du jeu et à la gestion des ressources gigantesques, et un autre producteur délégué a été chargé des milliers de bugs figurant sur une liste. Nous avons ajouté un troisième producteur délégué vers la toute fin du projet pour travailler sur les questions de compatibilité et pour aider à répondre aux questions techniques sur le courriel de support bginfo@bioware.com.

Nous avons appris à faire en sorte que tous les membres de l’équipe se parlent et travaillent en groupe, plutôt qu’individuellement !

Gérer le projet à mi-parcours :

Au cours du développement de tout jeu, aussi cool soit-il, il arrive un moment où les gens travaillent dessus depuis longtemps et commencent à s’en lasser. Cette période de calme plat à mi-projet doit être gérée très soigneusement, en prêtant attention aux personnes impliquées. Dans le cas de BG2, notre situation a été compliquée par le fait que nous avions un nouveau projet en cours de production, Neverwinter Nights (également avec Black Isle/Interplay comme éditeur), juste de l’autre côté du hall, et un autre nouveau projet cool sous la forme de notre Star Wars RPG (avec LucasArts comme éditeur) également en cours de réalisation.

Chez BioWare, nous aimons organiser des événements mensuels pour toute l’entreprise – comme aller au cinéma ou organiser un barbecue pour permettre aux gens de faire une pause en les sortant du bureau. C’est notre façon de montrer que nous sommes toujours dans ce métier pour le plaisir – nous faisons des jeux, et nous devrions nous amuser !

Pour l’équipe de Baldur’s Gate II en particulier, nous avons passé beaucoup de temps à parler avec les gens tout au long du projet, surtout à mi-parcours, afin de nous assurer que nous apportions un soutien suffisant aux personnes qui se battaient pour le jeu. Nous avons également déplacé certaines personnes – l’un des principaux avantages d’être un grand développeur est que nous avons plusieurs projets organisés en même temps, et à tout moment, il y a probablement quelques personnes qui ne seraient pas contre le fait de changer de jeu. De plus, certaines personnes sont des “débutants”, d’autres des “finissants” – il est important de comprendre chaque individu et d’adapter ses tâches à son style de travail.

La leçon que nous avons tirée est qu’il faut se méfier du projet en cours ; le moral peut chuter brusquement avant de remonter lorsque les gens voient la lumière au bout du tunnel.

Commencer la synthèse :

Dans un projet aussi riche en contenu que Baldur’s Gate II, nous n’avons pas vraiment eu à nous soucier de la réduction du contenu. Bien que nous ayons livré presque toutes les fonctionnalités que nous avions prévues au départ, nous avons commencé à couper les quêtes et les personnages bien avant la phase finale de test. Nous avons tout de même réussi à obtenir plus de 200 heures de jeu.

Rétrospectivement, nous aurions dû commencer ce processus plusieurs mois plus tôt. L’un des dangers du développement est que les développeurs de jeux ont tendance à toujours ajouter du contenu si on leur en donne le temps. Ils ne passent naturellement pas leur temps à limiter et à peaufiner le contenu ; au contraire, plus de temps signifie plus de choses. Il est sage d’utiliser cette liste de caractéristiques prioritaires pour affiner le travail (bien sûr, le nôtre était informel, ce qui le rendait un peu difficile).

Nous avons appris à regarder notre date butoir et à ajuster notre développement de contenu en conséquence. À bien des égards, la qualité est plus importante que la quantité. Même si Baldur’s Gate II était plus grand que Baldur’s Gate, le contenu réel était de bien meilleure qualité – nous n’avons réalisé que trop tard combien nous en avions fait davantage dans BG2 !

Test, test, test, test :

En raison de sa taille immense, Baldur’s Gate II a été le cauchemar des testeurs – ceci a été aggravé par le fait que nous n’avons pas fait assez de tests au fur et à mesure que les zones étaient développées. Baldur’s Gate II contient environ 290 quêtes distinctes – certaines sont très petites (20 minutes de long) tandis que d’autres sont assez grandes (quelques heures). Chaque quête a dû être testée à la fois en mode solo et en mode multijoueur.

Le hall principal de la Salle des Merveilles.

Pendant les tests, nous avons adopté une méthode de suivi des tâches et des bugs très solide qui nous a été présentée par Feargus Urquhart, le directeur des studios de Black Isle, ainsi que Chris Parker et Doug Avery, nos producteurs de Black Isle (qui ont tous aidé le projet de différentes manières). Nous avons placé un certain nombre de tableaux blancs dans les salles de la zone d’essai et de conception et nous y avons inscrit toutes les quêtes. Nous avons ensuite mis un “X” à côté de chaque quête. Nous avons divisé les concepteurs et les équipes d’assurance qualité en sous-groupes jumelés – chaque paire (un testeur et un concepteur) avait la responsabilité de vérifier et de corriger chaque quête de manière approfondie. Une fois qu’ils étaient certains que la quête était à l’épreuve des balles, son “X” était supprimé. Il a fallu environ deux semaines pour vider le tableau (lors du premier passage).

En plus des tests de la sous-quête, nous avons fait travailler une autre équipe d’assurance qualité de BioWare (composée non seulement de quelques personnes de l’assurance qualité, mais aussi de quelques programmeurs juniors et de quelques concepteurs) sur le jeu en mode multijoueur. Cette équipe est venue s’ajouter à l’équipe d’assurance qualité multijoueur d’Interplay qui travaillait sur place chez BioWare et à la trentaine de personnes d’assurance qualité qui travaillaient chez Interplay. L’expérience avec Baldur’s Gate II a renforcé le fait que les jeux de rôle ont vraiment besoin d’un engagement significatif en matière d’assurance qualité pour réussir.

Au final, nous avons trouvé et corrigé plus de 15 000 bugs dans Baldur’s Gate II. Grâce au travail acharné de tous ceux qui ont participé à l’assurance qualité de Baldur’s Gate II, nous avons pu envoyer un jeu gigantesque sans bugs importants.

La leçon : testez tôt ! Souvent, vous n’avez pas le temps à la fin pour tester correctement.

La dernière ligne droite :

Dans les derniers jours de travail sur  BG2, il y avait un sentiment étrangement serein dans le bureau. Nous n’avons pas ressenti la panique générale qui règne parfois à la fin d’un match, mais nous avons certainement vécu un stress considérable en réalisant 21 missions en trois jours. Après quelques longues nuits avec toute l’équipe jouant au jeu encore et encore, nous avons atteint un point où nous avions bâti un final parfait. Ensuite, il a été envoyé aux duplicateurs !

Nous avons appris à économiser de l’énergie pendant la phase finale – parce qu’on en a besoin à la toute fin.

Support post-jeu :

Le dernier domaine à mentionner concernant Baldur’s Gate II est le sujet du support post-jeu. Nous avons récemment réalisé que nous croyons en l’importance d’apporter un soutien personnel aux acheteurs de nos jeux. Bien que nous ayons toujours fourni ce soutien, ce n’est qu’après la sortie de BG2 que nous l’avons officialisé comme l’un des objectifs de BioWare. Un groupe de producteurs en ligne, géré par leurs producteurs, s’est récemment vu confier la tâche formelle de fournir très rapidement (le jour même ou aussi vite que possible) une assistance technique aux fans : leur but est de s’assurer que les personnes qui achètent nos jeux peuvent y jouer.

Nous pourrions nous appuyer sur les circuits standard d’assistance à la clientèle (et nous en avons bien sûr aussi sous la forme de CS de nos éditeurs Black Isle/Interplay et LucasArts), mais nous voulons aussi prendre le temps de nous mettre directement en rapport avec les acheteurs de nos jeux. Après tout, qui peut mieux résoudre les problèmes techniques que les personnes qui ont créé le jeu ? Le premier week-end suivant la sortie du jeu, nous avons oublié de confier à quelqu’un la tâche de surveiller les forums de discussion et les courriers électroniques de l’assistance (bginfo@bioware.com), si bien que les PDG conjoints de BioWare l’ont fait eux-mêmes. C’était très divertissant lorsque les gens se disputaient pour savoir si c’était vraiment nous qui étions sur les forums ou qui répondions à leurs courriels – ils ne pouvaient pas croire que nous prenions la peine de leur répondre en personne (nous l’avons fait).

Cependant, l’une des choses les plus importantes que nous avons apprises au cours de nos années dans l’industrie est l’importance de soutenir les fans qui achètent nos jeux. Cela signifie tout d’abord que nous devons livrer un produit sans bug, et ensuite être totalement disponibles pour aider les personnes qui ont des problèmes avec nos jeux – sur les forums, par le biais de courriels de contact, et partout ailleurs. Quel est l’intérêt de fabriquer des jeux si vous ne pouvez pas vous assurer que les gens peuvent y jouer ?

Résumé : Ce qui a bien fonctionné :

  • Une technologie de moteur stable.
  • Une équipe dédiée au projet.
  • Les vétérans reviennent pour améliorer un système qu’ils ont créé, en s’assurant de la familiarité avec le développement et le moteur.
  • Une bonne discipline de projet.
  • L’assurance qualité (AQ) dans le jeu final.

Résumé : Qu’est-ce qui aurait pu être mieux :

  • Fragmentation de la communication d’équipe.
  • Contenu gonflé (Jeu trop gros).
  • Absence d’assurance qualité précoce.
  • Livraison tardive des biens – audio et son.
  • Mauvaise coordination de la localisation (traduction).
  • Multijoueur – dialogue sans pause, personnages non protagonistes.

Conclusion :

En conclusion, nous aimerions remercier toutes les personnes qui ont travaillé sur Baldur’s Gate II, tant dans l’équipe de développement de BioWare que chez notre éditeur Black Isle Studios/Interplay. Comme tout grand jeu, BG2 a connu des hauts et des bas, mais au final, nous sommes tous très fiers du jeu que nous avons réalisé. Nous espérons que cette rétrospective vous donnera un bon aperçu de nos méthodes de développement et vous donnera des idées concrètes que vous pourrez appliquer à vos propres productions. En fin de compte, c’est le jeu qui compte : si vous avez fait un effort honnête, vous serez toujours satisfait du résultat.

Note de l’auteur : Un grand merci à toute l’équipe de Baldur’s Gate II pour avoir travaillé si dur, pour avoir été si agréable à travailler et pour avoir créé une superbe suite. Merci également à tous les autres membres de BioWare et à nos éditeurs Black Isle/Interplay et LucasArts pour leurs efforts exceptionnels sur tous nos autres projets en cours de développement – Neverwinter Nights, Baldur’s Gate II expansion pack, Star Wars RPG, et MDK2 : Armageddon.