Le retour de Defender of the Crown dans nos chaumières
-Defender of the Crown est un jeu de stratégie pour un joueur écrit par Kellyn Beck. Il s'agit du premier titre de Cinemaware qui est sorti à l'origine pour l'Amiga en 1986. Il est ensuite sorti sur Amstrad CPC en 1989, édité par Ubi Soft.
Quand un des trois auteurs puis un deuxième atterrit sur un forum Amstrad CPC, c'est tout d'un coups un feu d'artifices d'informations et plus encore. Et cela s'est passé sur CPCRulez.fr. Si vous avez gardé votre âme d'enfant, il est temps que je commence à vous conter une bien belle histoire : il était une fois un méchant, un gentil et une belle princesse...
La version Amstrad CPC de Defender of the crown a été développée par 3 personnes en environ 6 mois :
- Brice Rive pour la partie programmation et la protection contre la copie (il est également l'auteur d'un émulateur Amstrad CPC pour MAC : CPC++);
- Laurent Boucher pour les graphismes essentiellement à coups d'OCP Advanced Art Studio;
- Grégory Clément pour la partie sonore.
Brice Rive et Laurent Boucher se sont connus en école d'informatique après le baccalauréat, tous deux déjà amateurs de programmation et d'électronique (qui leur servira comme on pourra le voir ci-dessous). Brice a ensuite travaillé sur trois autres jeux chez Ubi Soft pour la protection contre la copie : Skateball, Omeyad et le maître absolu. Accessoirement ces deux compères ont également oeuvré sur le jeu d'aventure E.X.I.T. sorti en 1988 toujours chez Ubi Soft, développé en 9 mois entre le printemps 1987 et le début 1988. Pendant le début du chantier, quelques heures par jour de travail, beaucoup de temps passé à scénariser. Très vite ils sont arrivés à des journées pleines et vers la fin (les dernières semaines), environ 20 heures de travail par jour. Leurs aventures de créateurs de jeux ont été possibles d'une part parce qu'ils s'entendaient bien, et d'autre part parce qu'il était toujours intéressant de constater que l'autre n'était pas toujours d'accord. Ils n'ont jamais eu peur de passer des heures à discuter jusqu'à se comprendre totalement. C'est ainsi qu'ils ont gagné chaque bataille de Ko. Il n'y avait pas de perdant. Tant qu'ils ne se comprenaient pas, ils discutaient. Une fois l'affaire tranchée, ils repartaient joyeusement chacun de leur côté pour travailler. A noter que cette méthode de travail peut sans doute s'appliquer également messieurs à toute vie en couple, prenez des notes !
Brice Rive a été appelé sous les drapeaux juste avant la sortie de Defender. Il a fait le forcing pour boucler le chantier avant d'endosser l'uniforme. Au début de ses classes, il a fait sauter les derniers bugs à partir d'une cabine téléphonique de sa caserne : Laurent à l'autre bout du fil sur Pyradev qui lisait l'écran à haute voix et Brice dictant les corrections ! Bonjour les sueurs froides chez Ubi, Laurent en tremble encore par jour de grand vent...
Parlons de la méthode de protection de Defender of the Crown, qui rendait impossible sa copie par une machine de série. Brice a utilisé une particularité du contrôleur de disquette, qui pouvait lire des formats qu'il ne pouvait pas reproduire, à moins d'être bidouillé. Bref, ils ont travaillé sur des machines "kitées". Lors de la sortie du jeu, la société chargée de la duplication les a contacté : ils n'arrivaient pas à copier le BAT ("bon à tirer"). Peu de temps après la sortie d'E.X.I.T. (un an avant Defender of the Crown), une nouvelle version de discology est apparu pouvant copier E.X.I.T. : trois semaines de vraie vie commerciale, c'est peu pour un travail de presque 9 mois (la protection n'avait pas été écrite par eux deux). Ils étaient payés tous deux en droits d'auteur, vous imaginez le résultat des ventes (pirater caymal, message subliminal), plus question d'avoir des royalties par la suite dans ces conditions.
Il y avait des outils pour copier les données sur les disquettes dans un format spécial. Chaque secteur avait un contenu bien défini : du code, des sprites, des ecrans, de la musique. Pas de répertoire évidemment, tout en accès direct. Il y avait de mémoire un secteur par piste, qui faisait tout le tour. Le contrôleur disquette sait le lire, mais pas l'écrire. C'est l'astuce. Sur leurs marchines de développement, un interrupteur et une résistance avaient été soudé entre un des contacts du port imprimante et une partie du lecteur de disquette. Le port imprimante, sous les ordres du BIOS maison, servait à dire au contrôleur d'arrêter d'écrire un secteur sous peine d'effacer le début. Ubi Soft ont ouvert bien grand leurs yeux lorsqu'ils l'ont vu la première fois, sur une seule disquette (secteurs de taille 6, soit 240Ko par face pour 40 pistes, soit 480 Ko de données non compressées). C'était un format compact... Au démarrage, Brice virait l'OS pour installer le sien, avec juste ce qu'il faut, pour optimiser l'utilisation de la RAM. Ils ont passé des nuits et des nuits à batailler pour économiser des Ko. Brice en voulait pour son code, et Laurent pour les images. Le cours de la pizza et de la Kro était à son plus haut point... Cerise sur le gateau, un dernier utilitaire bien pratique : upload et download de leurs travaux d'un CPC à l'autre avec un minitel (le modèle 1B dont le modem était réversible, 1200/75 ou 75/1200, doté d'une prise externe vers son modem interne). Et vive le port série ! Qui plus est l'application avait une espèce de tchat intégré, puisque le téléphone ne fonctionnait plus lors des tranferts via minitel. Le programme original de tranfert/chat a été retrouvé. Le montage était juste un prise sur le port imprimante qui partait avec trois fils vers la prise du minitel 1B, qui ne servait que pour son modem. C'est le même truc qui était utilisé pour télécharger des programmes par minitel sur certains serveurs. Du temps d'EXIT, point de Minitel, les disquettes de sauvegarde voyageaient à vélo (et les pigeons alors ?).
On peut remercier Brice Rive pour avoir fourni aux curieux le code source complet de l'application. Cela laisse entrevoir sait-on jamais une version internationalisée, avec des améliorations graphiques (écrans en overscan ?), notamment sur CPC+ avec sa palette améliorée, des corrections de bugs (au moins celui des princesses). Les données (musiques, écrans et sprites) sont toutes dans des formats speciaux lisibles par le jeu et des utilitaires écrits par Brice. Les sprites sont disponible au format OCP, les écrans dans une mosaïque au format GIF.
Comme bien souvent, le jeu n'utilisait que 64 Ko de RAM afin de supporter également les Amstrad CPC 464 et 664. Si Brice Rive avait pu utiliser 128 Ko, il aurait amélioré la jouabilité avec moins d'accès disque, l'animation des sprites pendant les joutes, corriger un bug qui diminue de beaucoup l'apparition des princesses (et qu'est-ce qu'une histoire sans princesse je vous le demande ?). A noter qu'il n'y a pas de cheat dans le jeu.
La version Amstrad CPC de Defender of the Crown a été faite sans l'aide de matériel issu d'un autre portage, pas de sources, pas de graphismes, juste en jouant des heures avec la version Atari ST, enfin tout de même sur la base d'un article (assez court) qui parlait du jeu, les développeurs originaux n'étant pas disponibles. Sur les 64 Ko de RAM, 32 sont utilisés pour le code, 32 pour la vidéo. Le tout développé uniquement sur Amstrad CPC avec le compilateur Pyradev (avec peut-être une photo future d'un de ces Amstrad CPC de développement customisé pour l'occasion plus tard).
Pour les graphismes, un hacker ST s'est chargé de les extraire (Tsuno, bien connu à l'époque), et une conversion a été effectué de cette extraction brute de forme, avec un résultat au début nécessitant pour le moins du travail pour arriver à quelque chose de satisfaisant. Laurent Boucher fait encore des cauchemars la nuit avec les couleurs Amstrad (petite exagération) au point qu'il est encore capable 24 plus tard de réciter par la palette et l'entrelaçage en mémoire... Le mauve était incontournable pour les formes, 3 intensités différentes pour aller du noir au blanc. Les dégradés rouge/orange étaient trop contrastés pour ça. Ils trouvaient naturellement leur place lorsque la scène était éclairée par un feu. Heureusement, il n'y a avait pas encore d'éclairage électrique au moyen-âge. Laurent Boucher a utilisé pas mal de de petits programmes maison pour découper les sprites et les retoucher en visualisant les animations. Les images de Defender n'étaient pas à priori pas compressées. En revanche sur EXIT, c'était compressé "à la main". Un truc de fou : un utilitaire enregistrait les actions nécessaires pour "dé-dessiner" chaque image, et le décompacteur embarqué lui, récitait à l'envers les données produites ! Des fichiers minuscules, un affichage fulgurant.
A noter qu'il existe une version récente sur Iphone/Ipad de Defender of the Crown.
_1.png)
_1.png)
_1.png)
_1.png)
_1.png)
