Les prototypes sur Dreamcast

On ne le sait pas forcément mais la conception d'un jeux vidéo et ce qui l'entoure est bien plus complexe que ce nous pensons. Entre le premier prototype d'un jeu et sa version commercialisée, il s'en passe des choses. Je vais essayer de vous résumer brièvement la succession des différentes versions avant de rentrer un peu plus loin dans la technique.

On peut estimer qu'il sortait entre 300 et 500 prototypes d'un studio ; une industrie dans l'industrie !

  • Tout d'abord, le studio gravait leur beta (master) depuis leur devkit à l'aide d'un GD-Writer.

  • Ces masters étaient ensuite envoyés chez l'éditeur pour duplication et chez Sega pour le contrôle des standards qualité. On retrouve souvent la même écriture sur différents titres d'un même éditeur. Bien souvent, c'était l'œuvre d'un stagiaire qui passait ses journées à dupliquer les prototypes.

  • Les éditeurs envoyaient les duplicatas aux différents acteurs de l'industrie, acheteurs des grandes enseignes et journalistes notamment.

Attention, tout cet article repose uniquement sur ma compréhension du milieu, sur certains témoignages que j'ai recueilli au fil des années. Je suis peut-être en dehors de la réalité sur bon nombre d'aspects et d'étapes mais cela commence à devenir plus clair. Ne vous fiez pas à mes dires et si vous avez des informations complémentaires, n'hésitez pas !

Quelques termes spécifiques pour le matériel

  • GD-R : Il s'agit du nom des disques gravables au format Dreamcast. On retrouve cette inscription sur la gauche ou la droite de ces CD (abréviation de GIGABYTE DISC RECORDABLE). Ils sont principalement orange. Il arrive de trouver également des GD-R avec la mention "Katana", qui était le nom de code de la console. La surface de lecture est bleue, un moyen de les authentifier.

  • Comme ils ne sont pas pressés, le risque de détérioration ou de disque rot est plus important que sur les jeux pressés du commerce.

  • CD-R : Il s'agit des CD que nous employons tous [pour graver nos jeux :)]. Certains studios ont utilisé ce type de disque pour graver leurs prototypes. Le plus connu "serait" celui de Castelvania, vendu dans les années 2000. Mais n'est-ce qu'une légende urbaine ? Il ne sont en aucun cas officiels. Les prototypes homebrew sont eux sur CD-R . Les assets (fiche produits, screenshots, packshots, éléments d'iconographie à détourer, etc.) se trouvaient naturellement copiés sur ce genre de support.

photo ebay

  • les Silvers : Ils n'ont rien à voir avec les prototypes. Je trouvais sympa de vous en parler. Ceux sont des GD-R de pré-production. On pourrait les comparer à des échantillons. Ces disques ne possèdent aucun label. Selon les quelques informations en notre possession, Sega et les éditeurs tiers, lors de la production des jeux, avaient le droit à 50 disques d'échantillonnage, afin de tester l'optimisation du jeu en condition réelle. S'ils dépassaient ce quota, ils devaient payer des frais supplémentaires. Ces disques finissaient par être employés comme version promotionnelle avant la sortie du jeu.

  • Dreamcast System Disc 2 : il s'agit d'un CD-Boot qui permet de lire les prototypes (GD-R) sur une Dreamcast standard ! Sans ce disque, il est impossible de lancer une Beta, sauf à posséder un Dev-Kit. Une manipulation permet d'accéder à des options secrètes, il suffit de brancher une manette sur le port D et de maintenir le bouton Y pendant le démarrage. Ils étaient nominatifs, SEGA connaissait chaque propriétaire. A l'heure où j'écris cette article (septembre 2020), ils sont toujours impossibles à dumper...

  • GD-Writer Katana (HKT-0400 ) : cet accessoire devait être relié au kit de développement de la Dreamcast. Il permettait de graver une version de jeu en cours de développement sur un GD-R vierge.

  • Le kit de développement Katana : je pense que je n'ai pas grand chose à vous apprendre dessus. Son nom est suffisamment explicite. C'est une sorte de station de débogage. Pour le faire fonctionner, il doit être relié à un pc sur lequel plein de programmes de développement doivent être installés, dont le SDK.

  • Si je ne dis pas de bêtises, le jeu se faisait sur le pc puis on le poussait sur le devkit afin de voire comment il réagissait sur un hardware capable d'imiter le hardware d'une console du commerce tout en ayant la puissance de faire tourner un code encore non-optimisé.

  • Je vous laisse regarder cette vidéo que j'avais fait il y a quelques années.

  • Le GD-R Duplicator (GD-X ) : on devait sans doute les utiliser chez les éditeurs, ou chez Sega. Ils servaient à dupliquer les GD-R gravés depuis le GD-R Writer.  Ils ressemblent au dev-kit katana.

  • A titre personnel, il est sur ma liste de recherche depuis 5 ans...

photo ebay

photo google

Du jargon en veux-tu, en voilà !!!

  • Un build : il s'agit de la construction d'un prototype à un moment donné du développement, on assemble toutes les parties qui constituent un jeu et cela donne une version du jeu. Un jeu durant sa création aura une multitude de builds différents, chacun avec des portions plus ou moins avancées.

  • La version d'un prototype : C'est ce qui permet de différencier les builds. La plupart des studios employaient la même numérotation, par exemple de 0.1 pour la première à 1.0 pour a finale. On pouvait bien sûr dépasser le "1" mais rarement  de beaucoup. Une version "1.000" ou plus est généralement la marque que le jeu est dans sa version finale, c'est-à-dire identique à celle du commerce. La version peut correspondre au pourcentage du jeux en  développement, par un exemple une version 0.8 signifie bien souvent un jeux à 80 % de son développement. Certains studios avaient leur propre système de numérotation (22b, ou version 5.51 ). Il faut toujours des exceptions !

  • Un Master : On emploie ce therme principalement pour désigner une version "Finale" d'un jeu ou de la version qui va être massivement dupliquée. On peut également appeler "Master" tout prototype gravé à l'aide d'un GD-Writer. On peut donc avoir des Master en alpha, en beta par exemple (j'y reviendrai plus en détails après...)

  • La date : c'est la date de gravure du GD-R et non pas la date du build.

Quelques phases de développement d'un jeu

  • Tech démo : simple présentation du jeu pour se faire une idée du concept, un niveau ou un environnement par exemple,

  • Alpha : première monture du jeu avec une progression dans son développement, le rendant jouable le plus souvent, même de façon sommaire,

  • Beta : le contenu est complet mais le jeu est à optimiser. C'est la phase de détection des bugs, le beta-test,

  • Release candidate : La phase de beta test est passée, il faut le soumettre à l'approval du constructeur. Soit il passe le test, soit il retourne en correction. Il peut donc y avoir plusieurs release candidates 1 puis 2 voire 3 jusqu'à avoir corrigé les problèmes. Mais c'est rare d'en arriver là car le risque d'avoir à décaler le lancement du jeu est grand.

  • La preview : on est sur quelque chose qui tient la route, les différences avec une version finale sont minimes. On procède aux derniers ajustements. Cette version est destinée à être montrée à l'extérieur. En général, il s'agit de la beta ou d'une version limitée de la beta. C'est ce que les journalistes utilisent pour les previews des jeux.

  • La review : on est pratiquement sur une version finale à quelques détails prêts. Ca peut être une release candidate. C'est ce que les journalistes utilisent pour les tests des jeux.

  • Final : le jeu comme on le retrouvera dans le commerce.

Voilà pour les termes les plus souvent utilisés. On peut retrouver du "pré-alpha", du "pre-review". Dernièrement, j'ai trouvé une beta avec l'inscription "check text", sans doute quelques choses en rapport avec la traduction.

Il faut également savoir que chaque studio fonctionnaient différemment. Il n'y avait pas de process défini et imposé par le constructeur . Il est donc parfois difficile de s'y retrouver.
 

Qu'est ce qu'un debug menu ?

 Il peut également s'agir d'options de dev à déverrouiller grâce à des combos de boutons. Comme des cheats codes.

Il y a celui qui permet de trouver les différent bugs comme par exemple celui d'Agartha. Je l'appellerai le debug menu de "conception". On peut y contrôler le framerate, les contours des objets etc. .

 

Un de mes builds de V-Rally et celui de "Stunt GP" possèdent un debug menu permettant de tester diverses choses avant la validation du choix final. Par exemple changer le champ de vision, modifier la force de freinage des véhicules. Je l'appellerai le debug menu de "Et si ...".

Enfin, j'ai pu trouver des debug menus permettant de finir le jeux plus rapidement. On peut se téléporter à l'endroit que nous voulons ou devenir invincible. Nous sommes là sur un debug menu de "triche". Mon prototype de "Dinosaure" dispose de ce genre d'options.

Les debug menus peuvent être présents à toutes les étapes de développement d'un jeu, et même dans sa version finale ! En fouillant les fichiers de certains jeux commerciaux, certains bidouilleurs ont pu le débloquer. Ils ne sont donc pas forcément effacés mais simplement verrouillés.

La méthode conventionnelle d'ajouter un debug menu dans un prototype est de le mettre au menu Start du jeu. Mais comme encore une fois, rien n'est défini, ces menus peuvent être bien cachés. Pour y accéder, il faudra parfois faire une combinaisons de touches à un moment donné en plein jeu. J'ai vu des debug menus bien cachés !!!!

Les Standards, Kesako ?

Les standards sont des obligations que Sega imposait aux studios pour le jeu comme par exemple :

  • Le temps d'affiche du logo, qui devait apparaître tant de secondes, sa taille, etc.

  • Tout ce qui était "interruptions" : comme le jeu gère l'ouverture de la console en plein jeu, ajouter ou retirer une maette, une carte mémoire, la façon de sauvegarder, etc.

Il en existe plein.

Sega possédait une branche ou certains employés vérifiaient les prototypes que les studios et éditeurs leur envoyaient.

Ne pas respecter ces normes imposées engendrait des coups supplémentaires pour les studios et des retards de plusieurs mois pour corriger, renvoyer un nouveau build et repasser par ce bureau de conformité.

Collectionner le DEV ?

C'est mon ressenti personnel, l'histoire que j'ai avec la face cachée du jeux vidéo depuis que je m'y suis aventuré .

Un prototype nous explique indirectement comment un jeu a été conçu. On peut suivre étape après étape son développement.

Des prototypes, des dev kits peuvent contenir de véritables trésors. On peut y retrouver des morceaux du code source, des niveaux inédits, des modèles de monstres non utilisés et j'en passe. Le plus intéressant demeure évidemment les jeux annulés (unreleased).

Il est important de les préserver en les copiant, ainsi que de les partager dans la mesure du possible. Les mettre en ligne pourra servir à la communauté dans la recherche historique mais également donner, pourquoi pas, des informations supplémentaires pouvant faire avancer le hack, la bidouille. On peut ainsi donner les moyens à d'autres de faire avancer les choses .

Rendre disponible un jeux annulé à tout à chacun est rendre hommage à ce jeu qui n'a pas pu sortir pour d'obscures raisons bien souvent financières. Y jouer est une manière  de remercier toutes les personnes s'étant impliquées dans le projet qui n'a pas pu voir le jour. Nous donnons une seconde vie, devrais je dire une première vie à un unreleased .

Pour rendre en ligne un jeux annulé, il faut le faire respectueusement en essayant d'avoir l'accord de son créateur.  Je n'ose pas imaginé travailler des années sur un jeu et de ne pas avoir la satisfaction personnelle du produit fini. Cela doit être une énorme frustration. C'est pour cela qu'on se doit de leur rendre hommage.

Il ne faut pas acheter du DEV pour acheter du DEV et pavaner avec. Il faut se mettre dans la tête que c'est peut-être le dernier prototype existant sur Terre. Dans ce cas , nous nous devons d'en faire bon usage et d'en faire profiter le plus de monde possible. On peut apporter une pierre à l'édifice de l'histoire du jeu vidéo et peut être que grâce à nous d'autres pourront le faire par la suite.

Collectionner dans ce milieu est complètement différent que de collectionner des jeux en versions du commerce. La notion de rareté disparait puisque tout est rare. La notion de "mettre le prix pour tel ou tel titre parce qu'il s'appelle Zelda, Resident Evil ou Megaman " n'a plus raison d'être. Il n'y a plus de notion de valeur suivant les différent critères que nous connaissons, c'est au bon vouloir de l'acheteur. On sort  du schéma classique.

Il sera plus intéressant de posséder une Alpha d'un .jeu de seconde zone que de trouver une version Finale de Shenmue. Ce n'est plus l'objet ou le jeu qui importe, mais la différence de contenu, son état de développement.

Remerciement à la plume d'un ami qui souhaite rester anonyme.

This site was designed with the
.com
website builder. Create your website today.
Start Now