 |
Vendredi 23 mai 2025 - 12:35 |
| Translate |
|
| Rubriques |
| Réseaux sociaux |
|
| Liste des jeux Amiga |
|
| Trucs et astuces |
|
| Glossaire |
|
| Galeries |
|
| Téléchargement |
|
| Liens |
|
| Partenaires |
|
| A Propos |
|
| Contact |
|
|
|
Introduction
Fire And Ice fut le premier projet de la société Graftgold sur Amiga. Les Bitmap Brothers venaient de créer leur propre maison d'édition, Renegade, et nous étions en pourparlers avec eux pour publier quelques jeux.
Comme d'habitude, j'ai récupéré quelques captures d'écran sur Internet, alors merci aux auteurs de ces images de notre jeu pour les avoir produites. C'est bien que cette image GIF soit animée :
Paradroid 90 est sorti fin 1990 sur Atari ST et Commodore Amiga. Ce jeu utilisait le noyau/moteur 16 bits "OOPS" de Dominic Robinson, qu'il avait développé à l'origine pour le jeu de tir 3D Simulcra, et que nous avions utilisé pour le jeu de plates-formes Rainbow Islands. Cela nous a permis d'écrire un jeu principalement sur Atari ST, puis de le porter sur Amiga, en mode 16 couleurs, en trois semaines environ. Le noyau s'occupait des fonctionnalités communes telles que les entrées clavier, manette et souris, les interruptions, le débogage et l'affichage. L'avantage est que nous pouvions produire rapidement un jeu sur deux plates-formes similaires, mais l'inconvénient est que nous travaillions toujours avec les plus petits dénominateurs communs. Cela a particulièrement mis en évidence la faiblesse de l'Atari ST : pas de défilement latéral fluide géré par le matériel.
Entre-temps, Turrican 2 était sorti sur Amiga, montrant ce qu'il était possible de faire sur cette plate-forme. Il y avait beaucoup de sprites, un superbe fond de couleurs affiché via une liste Copper, un défilement fluide dans toutes les directions à 50 images par seconde, et un grand jeu avec beaucoup d'action.
Nous avons eu quelques conversations téléphoniques avec Julian Eggebrecht, le représentant de Factor 5, l'équipe qui a écrit Turrican 2. Ils avaient écrit leur propre système de développement ainsi que le jeu. Ils étaient impatients de nous parler de leur technique de défilement, qui utilisait la caractéristique unique du matériel Amiga : les plans de bits pour l'affichage peuvent commencer à n'importe quelle adresse de mot dans la mémoire. La plupart des écrans ont des adresses fixes ou limitées en mémoire pour l'écran.
Le problème pour l'Amiga était aussi que le processeur n'était pas assez rapide pour reconstruire un écran entier de données tous les 50e de seconde, même s'il était rapide. La magie du système de défilement de Factor 5 a été de réaliser que, lors d'un défilement fluide, une grande partie des données de l'écran reste inchangée. Seules les zones couvertes par les sprites logiciels, les caractères d'arrière-plan animés et le(s) bord(s) du défilement changent, donc si vous pouvez les mettre à jour efficacement, vous pouvez atteindre la vitesse magique de 50 images par seconde, comme en arcade.
J'ai passé une quinzaine de jours à implémenter la routine de défilement. J'ai dessiné un ensemble de blocs graphiques de test, juste quelques carrés numérotés, en fait. Le premier écran est d'abord construit en démarrant l'affichage un écran entier à côté de l'endroit où vous voulez vraiment l'afficher, puis en le laissant glisser jusqu'à l'endroit où il doit être, en construisant le bord latéral avant de l'écran. Les déchets qui se trouvaient à l'écran au départ sont éliminés du côté arrière. La routine de défilement est configurée pour tourner en boucle et construire les bords autant de fois que nécessaire, mais une fois que le jeu est lancé, elle contrôle le défilement et limite la vitesse à un maximum de quatre pixels par image, de sorte qu'un bord avant ne sera nécessaire que toutes les quatre images (les blocs ont une largeur de 16 pixels pour correspondre à l'étendue du défilement et à la gestion matérielle de 16 pixels par mot).
Pour commencer, j'ai utilisé le mouvement de la souris pour piloter la position de défilement. Cela m'a permis de vérifier les bords où le défilement doit s'arrêter, et j'ai pu déplacer l'écran lentement ou rapidement. Comme il n'y a pas de jeu à faire tourner, il y a beaucoup de temps processeur disponible.
Blocs d'arrière-plan animés
Le système d'affichage avait besoin de blocs d'arrière-plan animés. Ceux-ci permettent de mettre à jour efficacement les carrés de l'écran pour créer des zones en mouvement. J'ai donc dû établir des listes simples d'animations. Cela remonte à l'époque des caractères animés du C64, où chaque graphisme de 8x8 pixels était défini par 8 octets de données graphiques. À l'époque, il était nécessaire de mélanger les données graphiques entre trois ou quatre caractères consécutifs, alors qu'il ne serait pas efficace de mélanger les 128 octets par caractère des blocs 16x16. Comme les caractères sont créés par logiciel, il n'y avait pas de mode caractère sur Amiga, nous pouvions accéder aux données graphiques par une liste de pointeurs vers les caractères, donc l'animation était un simple cas de mélange de certains des pointeurs de sorte que le moteur de rendu des caractères soit simplement redirigé vers des graphismes différents.
Les graphismes animés dans Fire And Ice comprennent les cascades souterraines sous la jungle, l'écran d'entrée des initiales du meilleur score et les bulles montantes sous l'eau, mais pour un exemple extrême, John Lilley a opté pour des effets de fête psychédéliques sur tout l'écran d'achèvement du niveau.
Lorsque nous traçons des sprites logiciels dans le bitmap d'affichage, nous devons restaurer l'arrière-plan lorsque ces sprites se déplacent, c'est-à-dire à chaque image. Les routines de traçage de sprites doivent calculer la position sur l'écran où elles vont tracer les graphismes, de sorte qu'au bon moment, elles notent simplement le décalage dans l'écran, la largeur et la hauteur du tracé dans une liste de restauration. Deux images plus tard que les tracés, dans le cas d'un système à double tampon, la liste de restauration est analysée et les graphismes vierges sont copiés, voire transmis, du tampon de restauration au tampon d'affichage. Le tampon de restauration est une troisième copie de l'arrière-plan du personnage qui ne reçoit jamais de graphismes de sprites. Il doit également défiler en synchronisation avec les objets du jeu afin d'avoir les bons graphismes disponibles pour être copiés pour la restauration.
Première démo
La première démo que nous avons soumise à Renegade mettait en scène une créature rebondissante à la fourrure et aux oreilles battantes qui descendait peut-être du jeu C64 Gribbly's Day OUt. Les graphismes d'arrière-plan étaient assez montagneux et la créature sautait joyeusement dans tous les sens. Cette version du jeu doit encore exister sur une disquette quelque part... Pour l'instant, nous avons un extrait de magazine d'un contributeur inconnu dans les commentaires. Il m'a semblé naturel qu'un chien en peluche rebondissant, avec des envies de vol, vive dans un nid au sommet d'un arbre.
Renegade a fait savoir que le personnage était un peu trop "non conventionnel", pour ainsi dire, et qu'il voulait quelque chose de plus traditionnel dans ses mouvements.
Nous avons donné carte blanche à notre graphiste principal, Phillip Williams, pour animer un personnage de son choix. À ce stade, la palette complète de couleur pour le jeu, les niveaux et les sprites, n'avait pas été décidée, mais les couleurs choisies pour le personnage principal, ce qu'elles sont et combien elles sont utilisées, ont une grande influence sur les niveaux qui doivent encore être dessinés. Nous avions décidé d'utiliser le mode 16 couleurs car je n'étais pas sûr de pouvoir gérer le mode 32 couleurs. Vous perdez des cycles de processeur si le code est dans la mémoire vidéo, car la puce graphique doit voler des cycles pour récupérer les données de plus de quatre plans de bits. Bien que nous ne puissions pas vraiment quantifier cela, nous avions également à l'esprit que nous voulions toujours produire une version Atari ST du jeu. Nous avons divisé la palette en quatre groupes de quatre couleurs, en faisant des quatre dernières la gamme du bleu au blanc, de sorte que nous puissions faire correspondre les autres couleurs de sprites à ces quatre dernières pour l'effet de glace. L'agencement des couleurs de la palette est toujours important.
Phillip Williams a imaginé le petit personnage du coyote. Renegade est venu voir les nouveaux graphismes. Ils étaient satisfaits de la démarche plus conventionnelle du coyote. Ils ont suggéré qu'ils voulaient quelque chose pour rivaliser avec Sonic, et ils aimaient la palette de couleurs de Sonic, alors nous avons à nouveau ajusté notre palette.
J'avais une idée de l'usage que je voulais faire des sprites matériels, à savoir l'affichage des scores à l'écran. Tout d'abord, ils ne devaient être que des sprites en trois couleurs, je pouvais utiliser une liste Copper pour obtenir plus de couleurs, et deuxièmement, ils n'avaient pas besoin d'être tracés sur l'arrière-plan, ils étaient superposés dans leur propre couche. Nombreux sont ceux qui pensent que le personnage principal est le meilleur sujet pour les sprites matériels, mais il y a des cas où vous voudrez le faire interagir avec l'arrière-plan et passer derrière ou devant d'autres graphismes, ce que les sprites matériels ne peuvent faire qu'une seule fois en même temps. Dans nos logiciels, depuis l'époque des machines 16 bits, nous avons toujours implémenté des couches pour nos sprites logiciels afin de pouvoir contrôler quels graphismes sont tracés en premier ou en dernier. Cela nous a permis d'ajouter des objets de premier plan derrière lesquels les autres objets passaient, y compris M. Coyote.
Un vrai coucher de soleil
J'ai beaucoup aimé le fondu enchaîné de Turrican 2. J'ai remarqué qu'ils avaient intercalé les couleurs pour étendre le fondu sur une plus grande distance. Cela s'explique par le fait que la profondeur des changements de couleur était de 4 bits pour le rouge, le vert et le bleu, ce qui ne donne pas beaucoup de changements, seulement 16 valeurs différentes pour chacun d'eux. La puce graphique AGA avait 8 bits de rouge, de vert et de bleu, ce qui donne 16 fois plus de couleurs. J'y reviendrai plus tard.
J'ai fait quelques recherches sur ce qui se passe avec la lumière du soleil pour produire les rouges, les oranges et les jaunes des couchers de soleil spectaculaires. J'ai ensuite mis au point une routine pour simuler ces couleurs et déposer les résultats dans une liste Copper afin d'afficher les couleurs à l'écran pour chaque ligne de trame. Malheureusement, la profondeur des couleurs résultantes n'étant que de 4 bits, mes couchers de soleil étaient plutôt... "grumeleux". J'ai donc choisi de ne pas les utiliser et d'opter pour un effet "rideau" plus simple qui mélange simplement deux listes de couleurs sélectionnées à la main, l'une pour la lumière du jour et l'autre pour le coucher du soleil. Cela semble plutôt mécanique, mais la qualité des couleurs est meilleure. J'aurais aimé conserver la routine originale, car elle aurait été très belle sur le jeu de composants AGA, qui a étendu la profondeur des couleurs à 256 niveaux.
Lorsque nous avons réalisé les versions A1200 et CD32 de Fire And Ice, j'ai non seulement ajouté une couche de fond supplémentaire, mais j'ai également revu les listes de couleurs et ajouté la profondeur supplémentaire pour obtenir des fondus de couleurs vraiment fluides. Ces listes de couleurs ont toutes été saisies à la main en hexadécimal dans l'assembleur, et non dans un logiciel de dessin.
Bannière de l'écran inférieur
Nous avions limité la zone de défilement de l'écran à 192 pixels de haut afin d'être prêts pour une version NTSC, si nécessaire. Les téléviseurs NTSC ne disposent que de 525 lignes de balayage, ce qui correspond à 262 lignes de pixels, et certains processus doivent être exécutés pendant le temps d'arrêt de l'écran, comme les modifications apportées à la liste Copper. Néanmoins, j'ai agrandi l'écran avec le panneau de terre en bas. J'ai décidé de me faire plaisir en agitant les registres de défilement pour faire scintiller l'eau.
La première chose que j'ai découverte est que le temps est très limité et que vous ne pouvez pas faire faire au Copper un nombre infini de choses dans le temps limité dont il dispose dans le temps vide horizontal ("blanking"). Tout d'abord, il faut faire basculer les pointeurs des quatre plans de bits, puis mettre en place le registre de défilement fluide, et commencer à changer les couleurs. En fin de compte, il fallait une rangée de pixels pour la couleur du ciel et aucune autre couleur, car la configuration des 16 registres de couleurs prend du temps et les couleurs ne sont pas toutes prêtes au moment où l'affichage se produit. Il faut donc commencer par la couleur du ciel, car c'est la première que l'on voit, et ne pas utiliser les autres jusqu'à la ligne suivante. Le problème suivant survient à la ligne de flottaison, nous changeons le facteur de saut du plan de bits afin que les mêmes données soient réaffichées à l'envers. Ensuite, nous commençons à modifier les couleurs pour les rendre plus sombres et, sur chaque ligne de trame, nous modifions le registre de défilement fluide, qui est centré sur la position centrale, huit pixels, et nous exécutons une onde sinusoïdale à travers les lignes suivantes pour que l'eau se mette à osciller. Tout cela a ajouté environ 48 pixels supplémentaires à la hauteur totale de l'écran. Le manuel du matériel de l'Amiga contenait certaines règles concernant les points de départ et d'arrivée de l'écran, auxquelles il fallait se conformer.
Premiers niveaux
L'une des caractéristiques initiales de mon jeu devait être des créatures de feu qui vivaient dans des pots, puis sortaient et s'envolaient vers différents points du niveau et, si elles n'étaient pas arrêtées, déclenchaient des incendies. J'utilisais le système de patrouille-route de Paradroid 90 et j'avais ajouté une routine pour analyser le réseau afin que, lorsqu'une créature de feu émerge, elle choisisse un point cible sur le réseau et trouve le chemin le plus court autour du réseau jusqu'à la cible. Une fois qu'elle a allumé le feu, elle retourne dans un autre pot pour la nuit. Il s'agit en fait d'une fonction que j'avais initialement utilisée dans un jeu appelé Navigate, programmé en COBOL.
Le résultat des tests initiaux était que, comme les créatures de feu volent, il est difficile de les suivre à pied. Elles sont également hors champ et difficiles à surveiller, de sorte que le concept dans son ensemble était quelque peu bancal.
Nous avons donc implémenté les petits Incas qui tirent des fléchettes sur le joueur. Comme ils sont assez petits, nous pouvions en avoir plusieurs à l'écran en même temps, qui faisaient des choses différentes. Nous avons créé un roi Inca aux cheveux bouclés qui pouvait aussi générer de nouveaux Incas.
Pentes
Je voulais créer un système de surface au sol plus complexe que les simples surfaces horizontales sur lesquelles on peut marcher. Cela incluait des pentes et des murs qui pouvaient dévier les objets rebondissants, ainsi que des surfaces sur lesquelles on pouvait glisser.
J'ai conçu un système en deux parties pour enregistrer la pente ou la surface de chaque personnage. Tout d'abord, j'ai défini l'angle de la surface à l'aide de quatre bits, puis les quatre autres bits ont représenté le décalage de la surface vers le bas dans le personnage pour la marche. J'ai ensuite créé des graphismes pour toutes les combinaisons valides qui montraient simplement les définitions de la surface. Pendant les tests, j'ai mis en place une touche pour indiquer au traceur graphique d'utiliser la définition de la surface pour accéder aux graphismes de la surface au lieu des graphismes réels, afin de pouvoir vérifier que les surfaces étaient toutes cohérentes. Il ne faut pas laisser de trous dans lesquels les objets pourraient tomber ou s'échapper.
Nous avions décidé que le coyote devait tirer, cracher ou aboyer des boules de glace, plutôt que de porter une arme, ce qui m'a amené à calculer des angles de rebond et des accélérations de glissement pour la glace. Cela a donné lieu à toutes sortes d'expériences physiques amusantes lorsqu'une boule de glace roule dans une vallée et doit s'arrêter. Les faire s'arrêter lorsqu'elles se trouvent entre deux pentes opposées a pris quelques semaines pour en dégager les principes.
J'avais accepté que nous ne tournions pas à 50 images par seconde en raison de la quantité de tracés et de calculs physiques en cours. Je crois que Turrican 2 utilisait beaucoup de sprites matériels plutôt que logiciels, ce qui lui donnait un avantage. L'exécution de Fire And Ice avec ce que je considérais comme un nombre raisonnable d'objets entraînait régulièrement des dépassements, provoquant d'horribles saccades à l'oeil et à l'oreille. C'est à contrecoeur que j'ai limité le nombre d'objets à 25, sachant qu'il ne devrait jamais dépasser cette limite. Je n'ai jamais vu Turrican 2 dépasser ce nombre, c'était irritant !
Julian, Thomas et Holger sont venus d'Allemagne pour nous voir, sous prétexte qu'ils pourraient nous dire où nous nous trompions et faire tourner le jeu à 50 images par seconde. Après que je leur ai expliqué ce que nous faisions et comment, ils ont convenu que la charge processeur était trop importante pour 50 images par seconde. Nous leur avons expliqué les vertus d'un système à triple tampon mémoire, puis nous les avons regardés se retirer dans un coin pour une brève discussion avant de revenir et de dire tout simplement "Non". Pour mémoire, si l'entrée et l'affichage de la manette peuvent souffrir d'un décalage supplémentaire d'un cinquantième de seconde, une troisième mémoire tampon peut vous permettre de surmonter de courts pics d'activité, car elle vous offre jusqu'à un cinquantième de seconde supplémentaire de temps de traitement à répartir sur quelques images.
J'avais un ensemble de paramètres de mode de contrôle pour le coyote qui étaient liés aux données de niveau. Je pouvais ainsi rendre les niveaux de glace glissants et les niveaux sous-marins plus trépidants. Les autres méchants ont également utilisé certaines de ces valeurs, de sorte que tout s'est entremêlé.
Nous n'avions pas l'impression que le mode de contrôle était tout à fait correct, il semblait un peu lent pour certaines personnes. Renegade a organisé une rencontre avec Julian Rignall pour que je lui montre les progrès réalisés et que je lui dise ce qu'il pensait du mode de contrôle en général. Il en est ressorti que je devais accélérer les mouvements, l'accélération des sauts et la gravité, tout en fait. Une fois ceci fait, le coyote se déplaçait beaucoup mieux. Malheureusement... changer ces variables a provoqué toutes sortes de bouleversements parmi les différents méchants que j'avais mis au point. Alors que la gravité est partagée par tous les objets du jeu, les vitesses de saut initiales des méchants, par exemple, sont définies individuellement. Les sauts qui permettaient de franchir des espaces ne le faisaient plus. J'ai dû réajuster les paramètres de tous les méchants.
Mon conseil du jour est donc de mettre en place la physique de façon concrète dès le début. Pour rebondir sur ce point, je dirai que lors de la conception d'un jeu, il faut garder à l'esprit les dépendances : quelles parties dépendent de quelles autres. Modifier quelque chose qui n'a pas de dépendances n'aura pas de conséquences inattendues. Modifier quelque chose avec une myriade de dépendances peut renverser un empire. C'est pourquoi je déteste que mon code appelle du code externe, vous avez une dépendance sur quelque chose que vous ne pouvez pas contrôler, ni changer, mais que quelqu'un d'autre peut... dans le futur. J'utilise maintenant SFML, un ensemble de bibliothèques externes. Je suis heureux de signaler que la récente mise à jour vers la version 2.5.0 n'a pas provoqué de vague, tout mon code compile toujours et aucune dégradation de comportement n'a été remarquée.
Systèmes d'armes
Les améliorations des armes étaient la norme en 1992. Mais c'est toujours à double tranchant, car le joueur ne doit pas être obligé de les posséder pour progresser. Si aucune n'est disponible, le joueur doit quand même avoir une chance, les armes supplémentaires doivent seulement rendre les choses un peu plus faciles.
Nous pourrions planter des disques verts autour du niveau, marqués avec l'arme qu'ils donnent. Les armes supplémentaires sont généralement limitées en nombre de tirs. Il y a aussi des glaçons en forme de point d'interrogation qui donnent plusieurs disques, ce qui vous permet de choisir lequel ramasser. Ils peuvent être cachés jusqu'à ce que vous tiriez dessus. Les boules de cristal de glace contiennent également un nombre limité de disques. Mon arme préférée était le super-aboiement. Il y a aussi un bouclier de glace, un tir multiple et une grosse bombe de glace. Comme on ne peut pas compter sur leur quantité, ils n'ont pas d'effets très importants.
Les nuages
Les bombes à neige s'accumulent en collectant des flocons de neige. Ceux-ci sont produits lorsque vous tirez de la glace sur des nuages blancs. Ils commencent par pleuvoir, puis grêler, et si vous continuez à tirer, ils entrent dans un cycle de flocons de neige, que vous devez collecter en vous plaçant sous le nuage. Lorsque le nuage devient noir, sortez, il n'y aura plus de flocons de neige mais il y aura des éclairs. Cela peut tuer le coyote, les chiots à proximité, ou n'importe quel méchant d'ailleurs.
Ne confondez pas les nuages blancs avec les nuages sombres et dangereux des niveaux écossais.
Bombes à neige
Les bombes à neige sont représentées par des flocons de neige en haut à droite de l'écran, sous le nombre de vies, marquées d'un "L". Vous pouvez en garder jusqu'à huit. C'est par pure coïncidence le nombre que j'ai pu afficher dans les sprites matériels disponibles.
Pour lancer une bombe à neige, le coyote doit s'accroupir sur le sol, puis maintenir le bouton de tir enfoncé.
Les bombes à neige sont excellentes pour faire tomber les méchants volants, et bien sûr, elles figent tous les méchants à l'écran en même temps. Il vaut la peine d'en garder un stock pour les grands méchants.
Temps de décongélation
Les méchants sont mortels pour le coyote à moins qu'ils ne soient gelés en les frappant d'abord avec de la glace, parfois plusieurs fois. Lorsqu'ils sont gelés, ils deviennent bleus. Il n'y a qu'un temps limité pour frapper les méchants gelés avant qu'ils ne reviennent à la vie. Ce temps de décongélation se réduit au fur et à mesure que le jeu avance, car les terres se réchauffent. C'est à peu près la seule raison pour laquelle les terres se présentent dans l'ordre où elles sont !
Temps des niveaux
Le ciel passe du jour à la nuit et au jour sept fois avant que le coyote ne reçoive un avertissement de se dépêche. Le flocon de neige en haut à gauche perd un bras après chaque jour. La durée du jour et de la nuit se raccourcit au fur et à mesure que les terres progressent. La plupart du temps, cela n'entre pas en ligne de compte, car il y a suffisamment de temps, mais cela permet au joueur de se concentrer sur la tâche à accomplir.
Développement
En fait, nous avons développé les derniers niveaux en premier, sans le vouloir, simplement parce que nous avions des idées graphiques pour les niveaux les plus chauds. Lorsque nous avons développé le scénario du jeu, dans lequel le coyote doit voyager de son igloo dans l'Arctique jusqu'à proximité de l'équateur, nous avons été obligés de commencer par les niveaux les plus froids, et le premier niveau de l'Arctique est le plus difficile à jouer. Le simple fait de voir les nouveaux joueurs glisser de manière incontrôlée était une source d'inquiétude. Je me demande encore aujourd'hui si je n'aurais pas dû éviter de faire glisser le coyote, car cela ne semble pas totalement nécessaire. Les skieurs et les morses patinent, mais c'est à peu près tout. Il est un peu tard maintenant !
Niveaux de l'Arctique
Ayant décidé que Cool Coyote vivait dans l'Arctique, nous lui avons construit un igloo. J'ai demandé beaucoup de pentes glissantes pour lancer les skieurs. Nous avons également eu recours à la magie des échelles et des ponts de glace. J'avais prévu qu'ils se propagent également dans les autres niveaux, dans l'idée qu'au fur et à mesure que les terres se réchaufferaient, la glace fondrait plus rapidement. Ils réapparaissent dans les niveaux Inca.
Nous avons également développé les chiots ici. Ils veulent rester avec le coyote et le suivent docilement. Vous pouvez également leur inculquer la bravoure en tirant/aboyant. Cela leur permet de devancer le coyote et, comme ils peuvent écraser les méchants congelés sans être blessés par les méchants non congelés, ils peuvent s'avérer très utiles. Aboyer pour les faire passer devant le joueur est le moyen le plus sûr de les faire passer par les portes avant le coyote.
Les ponts de corde qui s'enfoncent sous le poids du joueur sont un clin d'oeil à Turrican. J'aurais préféré des ponts de corde qui s'enfoncent un peu plus, mais je n'ai pas trouvé de moyen agréable de le faire.
Niveaux écossais
Il y a beaucoup de choses bizarres qui viennent d'Écosse. Je me souviens d'un vieil épisode de The Goodies qui mettait en scène l'araignée cornemuseuse, alors j'en voulais absolument une. Je voulais aussi le haggis sauvage, le porridge, le monstre du Loch Ness et un château. Nous avions aussi des nuages d'orage, des lièvres, des aigles et des ours avec des boucliers.
Le sol n'est plus glissant, comme dans les niveaux de glace, et il est beaucoup plus facile de contrôler le coyote. Je trouvais que les méchants étaient un peu trop faciles à geler, alors nous avons donné un bouclier aux ours. Il y a une zone de collision supplémentaire devant les ours qui, si elle voit arriver un boulet de glace, dit à l'ours de lever son bouclier. Cela fonctionne bien, mais ces ours sont exaspérants. Vous devez soit sauter par-dessus eux et les frapper par-derrière, soit utiliser une arme spéciale qui peut les frapper par-derrière.
Les premiers haggis sauvages que vous trouverez vivent dans les arbres. Ils sautent un par un et s'enfuient. S'ils touchent le bord de l'écran, ils s'écrasent. La solidité du bord de l'écran (alias le bord du monde) a une signification importante dans la mesure où il doit absolument empêcher tout ce qui s'échappe, sinon le programme risque de récupérer des données erronées et de se planter. Le fait d'incarner ce bord du monde sous la forme d'un véritable mur contre lequel on peut se heurter m'a fait tiquer. Tous les autres méchants se retournent.
En fait, pour éviter toute fuite, j'avais deux colonnes de personnages muraux de chaque côté, deux rangées de pièces de plafond en haut, et deux pièces de sol en bas des cartes et j'ai dû arrêter le défilement de deux personnages à l'intérieur des bords de la carte pour ne pas les montrer. Rien ne sortait de mon écran ! J'ai fait cela parce que comme les méchants doivent vérifier les personnages autour d'eux de toute façon, avoir des blocages invisibles peut être fait gratuitement. A aucun moment je n'ai eu à dire : "faites demi-tour si X<2 ou X>4072 ou Y<2 ou Y>1076", ce qui prend un temps précieux.
À l'intérieur du château, il y avait des plates-formes dans les blocs de mur qui ne sortent et sur lesquelles on peut se tenir que lorsqu'on leur tire dessus. Elles se trouvent au-dessus de la piscine de porridge. Nous comptions sur le joueur pour essayer des choses et révéler l'astuce. Une fois qu'il a compris, il s'agit d'apporter un glaçon aux suivants en sautant de plate-forme en plate-forme pour éviter de baigner dans la bouillie bouillante.
Tous les jeux sont améliorés par les crocodiles, c'est ce que j'ai toujours dit. Comme nous le savons, ils ne peuvent pas ouvrir la bouche si vous êtes debout sur eux, alors attendez qu'ils ferment la bouche et sautez sur eux.
Le monstre du Loch Ness est une sorte de méchant de fin de niveau qui est presque à la fin, mais ce sont surtout des poissons qui sautent hors de l'eau. Ces poissons peuvent aussi avoir une pièce maîtresse, vous devez les geler pendant que vous sautez sur le dos de Nessie.
Niveaux sous-marins
Ces niveaux m'ont donné l'occasion de réajuster toutes les vitesses de mouvement et les accélérations pour obtenir des mouvements plus lents, en particulier la gravité. Je me suis rendu compte que nous ne pouvions pas utiliser les ponts et les échelles de glace sous l'eau, car ils n'auraient pas été à leur place avec l'eau de fonte dégoulinante sous l'eau. J'avais plusieurs mécanismes différents pour monter : il y avait les grosses bulles d'air libérées par les anémones de mer, et puis il y avait les palourdes. J'ai passé beaucoup de temps à essayer de les régler, presque autant de temps que beaucoup de gens ont mis à les maîtriser. L'astuce avec les palourdes est intégrée au mode de contrôle du coyote. Il a une traction vers le bas qui modifie la gravité lorsqu'il saute. Je l'ai ajouté car vous avez moins de contrôle lorsque vous sautez, mais il peut être utile d'esquiver des choses pour augmenter un peu la vitesse de descente, de la même manière que la hauteur de saut peut être augmentée avec un appui supplémentaire vers le haut de la manette. Le mode de contrôle de Rainbow Islands avait des attitudes intéressantes au niveau de la gravité et il n'y a pas grand-chose que l'on puisse faire avec une manette pour indiquer son intention de sauter un peu ou beaucoup, il faut donc improviser. Revenons donc aux palourdes : le ressort que vous pouvez obtenir des palourdes est proportionnel à la force avec laquelle vous atterrissez dessus. Si vous tirez vers le bas au bon moment, vous pouvez obtenir un peu plus de vitesse. Il s'agit ensuite d'aller, avec la manette, vers le haut au bon moment pour maximiser le saut au moment où la palourde s'ouvre. Un atterrissage très lent sur la palourde ne fait que la refermer.
J'ai toujours voulu que le coyote ait des accessoires, et le masque de plongée en était un. Nous avons réalisé que le paysage était plus accidenté et qu'il y avait beaucoup d'élévateurs, et que les chiots n'étaient pas assez intelligents pour utiliser des plates-formes basées sur des sprites. Nous n'avions pas non plus de masques de plongée assez petits pour eux. Le mode de contrôle du coyote était capable de gérer les pièces au sol du personnage et les surfaces de sprites plates, donc nous pouvions faire des plates-formes mobiles, c'est tout. Je joue à Ray-Man Legends et je ne peux qu'admirer la variété des surfaces mobiles et statiques que tous les objets peuvent traverser.
Phillip Williams commençait à prendre ses marques sur le plan graphique lorsque nous avons abordé les niveaux sous-marins. Il commençait également à se faire une idée du nombre d'images d'animation qu'il était autorisé à utiliser pour le niveau. Chaque objet du jeu est codé de manière personnalisée, avec son propre programme, ses propres animations et ses propres règles, rien n'est piloté par une table, donc s'il pouvait le dessiner, je pouvais le faire bouger. Les méchants se déplaçaient assez librement dans les niveaux, en particulier les poissons et les oiseaux. S'ils quittaient l'écran, ils étaient supprimés et recréés si leur position de départ se trouvait à nouveau sur le bord avant du défilement, ce qui permettait de s'assurer que rien n'apparaissait de nulle part en pleine lumière.
Phillip Williams travaillait sur un poisson animé avec une hélice qui avançait bien, puis il nous a montré quelques images du poisson en train de tourner pour faire face à l'autre côté, et cela ressemblait vraiment à un objet 3D solide. Il avait fait tout cela à la main, nous n'avions pas d'outils graphiques 3D pour l'aider. Je me souviens avoir été très impressionné par le fait qu'il ait réussi à créer cet objet avec un nombre limité de couleurs. J'étais plus qu'heureux d'économiser l'espace de l'animation pour l'exécution. Il a fait quelque chose de similaire pour le calmar. Nous avions beaucoup de bulles provenant d'objets. Certains de ces flux de bulles étaient des caractères animés, d'autres des sprites logiciels.
C'est en arrivant à ces niveaux que nous avons réalisés qu'ils étaient grands et qu'il était difficile de se rappeler où l'on allait. C'est alors que nous avons imaginé la mini-carte. Celle-ci doit examiner les blocs des personnages et sélectionner un pixel par 4x4 pixels dans chaque personnage pour l'afficher.
Nous avons également créé des flèches d'indication utiles qui apparaissent à de nombreux endroits lorsqu'il y a peu de mouvement, afin de donner un indice aux joueurs. J'ai fait preuve d'un peu de malice en créant des passages secrets dans certaines grottes, qui permettent d'accéder à des niveaux secrets ou simplement d'avancer. Il n'y a pas de grotte inutile dans le jeu. Il peut y avoir un trésor, ou un méchant que vous devez trouver, ou une sortie, même si elle est en grande partie invisible. Je pense que je pourrais avoir un petit sprite qui apparaîtrait de temps en temps là où il y a un point de passage secret si je recommençais le jeu, d'autant plus que je ne me souviens plus des itinéraires !
Il y a aussi des "yeux" dans divers endroits sombres. Ils n'ont aucune influence sur le jeu, mais ils regardent vers le joueur lorsqu'il se trouve à proximité.
Les tortues du jeu sont des plates-formes mobiles sur lesquelles vous pouvez sauter et atteindre des endroits que vous ne pourriez pas atteindre autrement. La plupart des gens remarquent que les tortues ne peuvent pas être gelées, mais ne réalisent pas que vous pouvez sauter sur leur dos et faire un tour.
Niveaux de la jungle
Je tenais à intégrer les chenilles, en guise de clin d'oeil à un vieux jeu d'arcade auquel j'ai passé beaucoup de temps à jouer au bar les vendredis soir. Je voulais qu'elles se séparent si on les frappait en leur milieu, mais cela ne correspondait pas à la façon dont le reste du jeu fonctionnait, et j'ai donc dû me contenter de les geler. C'est un objet en plusieurs parties, et je pouvais les faire longues ou courtes.
Phillip Williams a fait quelques tentatives pour réaliser une animation multicouche pour les chutes d'eau dans le niveau secret. Il a dû faire trois animations séparées et les superposer. Elles sont vraiment impressionnantes. Beaucoup de gens risquent de ne pas les voir s'ils ne sautent pas dans le terrier au deuxième niveau. Un autre pour le petit sprite de tentation qui indique que l'on peut descendre. Il y a quelques sauts délicats à négocier là-dessous. Il y a aussi des points à collecter et une vie à gagner.
Nous avons essayé de donner une impression de 3D aux scènes de la jungle en lançant des lances enflammées de l'autre côté de l'eau, ainsi que des morceaux provenant du volcan qui se déclenche périodiquement. Il est intéressant de noter qu'il ne figure pas sur la vidéo que j'ai regardée, donc apparemment on peut l'éviter ! C'est peut-être pour cela que c'est une bonne idée d'aller dans le terrier au début du niveau.
Le principal conseil pour ce niveau est de continuer à tirer car le danger vient de partout. Les niveaux en surface sont plats, ce qui s'explique par le fait que j'ai dû colorer la rivière avec le la fonction de fondu des couleurs du Copper. Laissez le chiot aller de l'avant et éliminez les méchants que vous avez gelés. N'utilisez pas les bombes à neige près du pont de paille au-dessus des pièges à mouches, comme sur la photo ci-dessus.
Niveaux Inca
Nous avons commencé avec ces niveaux. À l'époque, l'intrigue du jeu n'avait pas encore été pensée. Nous avions les serviteurs incas dans diverses incarnations marchant et sautant. J'ai dû penser à Indiana Jones, car je voulais faire un jeu de chariot de mine en cavale, avec le passage qui s'effondre derrière le chariot. Le réglage pour que le chariot se comporte correctement à la fin, à la bonne vitesse, a été un cauchemar. Lorsque nous avons réajusté les vitesses, tout a été chamboulé et j'ai dû le retravailler. Jason Page et Phillip Williams suggéraient des idées pour de nouvelles fonctionnalités. Je pense qu'ils ont joué à beaucoup plus de jeux de plates-formes que moi. C'est vraiment bien d'avoir davantage de suggestions, il vaut mieux avoir trop d'idées que pas assez.
J'avais envie d'avoir plus de petits méchants que moins de gros. Lorsque le jeu n'est que partiellement écrit, vous ne savez pas quelle taille il va prendre. Le nombre de blocs utilisés pour les décors est variable, mais en général, plus il y en a, mieux c'est, et cet espace est partagé avec toutes les animations des sprites. Il y a beaucoup de plates-formes en mouvement, des pendules qui tournent de différentes manières, d'autres qui tombent. Il y a aussi des plates-formes qui s'effondrent, des pointes, une grosse boule qui roule, des rochers portés par des oiseaux qui ne devraient pas être aussi forts...
Dans le temple Inca, il y a quelques éléments de décor qui obligent le joueur à être armé jusqu'aux dents. L'image ci-dessus montre un endroit où il faut faire le plein de flocons de neige provenant de plusieurs nuages. Un bonus agressif comme le super-aboiement est également recommandé, ou l'une des bombes de glace à tirs multiples, le bouclier ne sera pas d'une grande aide puisque vous êtes enfermé avec quelque chose, et c'est vous ou lui.
Niveaux bonus
Le nombre de mécanismes nécessaires à chaque niveau était élevé, chacun devant être programmé individuellement dans notre langage AMP (Alien Manoeuvre Program). J'avais envie de quelque chose d'un peu plus simple, et je voulais faire un clin d'oeil à mon autre jeu de plates-formes, Gribbly's Day Out.
Je voulais aussi quelque chose d'un peu plus farfelu, alors nous avons planté le décor dans des îles rocheuses dans le ciel. C'est vraiment un clin d'oeil au travail de Roger Dean, qui a sans doute aussi inspiré Avatar. Unobtainium, en effet !
Il y a de nombreux petits cadeaux dans tous les niveaux, mais ils peuvent aussi être ramassés par les méchants. Vous devez donc faire le tour le plus rapidement possible, car chaque cadeau rapporte plus que le précédent. Ensuite, vous pouvez décider d'éliminer les méchants en chemin pour les empêcher de ramasser les cadeaux. Puisqu'ils arrivent par le haut, il est logique d'atteindre le sommet du niveau pour arrêter les méchants. J'avais aussi des Gribblets là-dedans, qui rebondissaient comme ils se doivent.
Comme il s'agit de niveaux bonus, même si vous tombez des plates-formes inférieures, vous ne perdez pas de vie, c'est juste un peu d'amusement avant le niveau final. Il y a quelques vies "Bone-us" (NDT : "en anglais, "bone" signifit "os") à collecter qui devraient être utiles.
Niveaux égyptiens
Après avoir dessiné les créatures de feu et les pots dans lesquels elles vivent, j'étais déterminé à les utiliser, bien que dans un rôle plus mineur. Il s'agissait de graphismes assez larges avec un certain nombre d'images, ce qui signifie qu'ils prenaient beaucoup de mémoire et qu'il aurait été coûteux de les avoir à chaque niveau. Sans éditeur pour les itinéraires de patrouille suivis par les créatures de feu, les coordonnées de tous les points doivent être saisies à la main, ce qui devient également laborieux. Il faut trouver un équilibre entre le temps passé à entrer et à déboguer les données et le temps passé à programmer et à déboguer un éditeur, puis à entrer les données. À ce jour, je n'ai jamais écrit d'éditeur pour le jeu. John Cumming a écrit notre éditeur de fond en STOS sur Atari ST que nous avons utilisé pour Rainbow Islands, Paradroid 90 et ce projet. Je n'ai jamais eu d'éditeur de niveau pour aucun de mes jeux sur C64, tout était construit à partir de blocs plus petits. Certains des premiers jeux étaient listés sur papier.
Comme d'habitude, j'ai attendu que le développement soit presque terminé pour ajouter les sons. Il est préférable de les faire tous en même temps, et par la même personne. Il fallait également composer la musique. Nous avons inclus une option d'activation ou de désactivation de la musique, ce qui crée des problèmes supplémentaires. Les effets sonores sont en concurrence avec le lecteur de musique pour les quatre canaux sonores disponibles et pour votre attention. Lorsque la musique est désactivée, il faut qu'il y ait suffisamment de sons pour que l'ambiance sonore soit suffisamment complète, mais lorsque la musique est activée, vous ne voulez pas perdre la moitié des instruments au profit des sons, et vous ne voulez pas non plus que les sons soient couverts par la musique.
Jason Page a fait comme à son habitude un excellent travail, car il y a beaucoup d'effets sonores. Nous nous sommes retrouvés avec 15 musiques, 26 effets résidents pour tous les niveaux, puis les niveaux ont chacun leur propre lot d'effets, ce qui fait un peu plus de 50 effets supplémentaires. Nous avions l'habitude de donner une priorité à chaque effet, de sorte qu'un effet ne pouvait en interrompre un autre sur un canal particulier que s'il avait une priorité plus élevée. Cela permet de s'assurer que les effets importants sont entendus ou que les effets longs se terminent correctement.
Pour la musique de l'écran titre, nous voulions que le coyote joue du piano et aboie dans la musique dans laquelle Jason Page avait inclus ce son. Pour cela, la musique doit indiquer à l'animation du coyote quand aboyer. C'était une communication un peu étrange, puisque le lecteur de musique joue sur les interruptions et peut couper le cycle principal à n'importe quel moment. J'imagine qu'une variable globale assez basique a simplement crié "Maintenant !" lorsqu'un échantillon particulier a été joué. Bien des années plus tard, je jouais à Mario sur ma Wii U et nous avons vu les méchants se trémousser en rythme avec la musique et j'ai pensé : "C'est une bonne idée ! J'aurais aimé y penser".
Version A1200 AGA
Nous avons eu peu de temps pour nous préparer à l'Amiga A1200 à la fin du projet, et pour produire une version améliorée. La chose que je voulais faire le plus était de faire tourner le jeu à 50 images par seconde, ce dont le matériel était aisément capable. Les premières expériences ont montré que je pouvais modifier la définition d'une seconde de 50/2 à 50. Je devais ensuite ajuster les accélérations et les vitesses maximales du mode de contrôle, et réduire la gravité. Oh, la puissance.
Au niveau de la jungle, nous avons divisé l'arrière-plan original en deux couches afin de pouvoir faire défiler en parallaxe les arbres de l'autre côté de la rivière. J'ai dû gérer le changement de coordonnées des objets lancés de l'autre côté de la rivière, dont les bouts du volcan.
La séquence de fin de jeu a été complètement améliorée car nous avons pu créer un nouvel arrière-plan luxueux à l'intérieur de l'igloo. L'original était un groupe de caractères animés, juste pour montrer ce qu'il pouvait faire lorsqu'il n'y avait pas trop de sprites à tracer.
Version démo de Noël
Nous avons eu l'opportunité de produire une disquette de couverture pour Amiga Power. Comme c'était la période de Noël, nous avons créé un niveau d'après le niveau de neige original, et nous avons laissé Phillip Williams se débrouiller avec les planches graphiques. Le coyote s'est offert un beau manteau rouge de Père Noël et les pingouins ont des bonnets de fête. John Lilley a ajouté un radeau de Noël composé de cadeaux et nous avons dû intégrer une séquence de fin pour l'achèvement du niveau. Nous avons également dû ajouter une nouvelle bannière à un niveau en bas de l'écran.
On nous a prêté une CD32 et une manette afin de produire une version CD32 de Fire And Ice. Nous avions également un budget de développement pour payer six semaines de travail. Notre trousse de développement SNASM interfaçait l'assembleur de mon PC à l'Amiga via une carte d'extension, il n'allait pas s'interfacer avec la CD32. Nos six semaines allaient être consacrées à faire démarrer la version A1200 sur la CD32, à ajouter la gestion multi-boutons à la manette CD32, pour la toute première fois, et à jouer des morceaux de CD à partir du CD plutôt que d'utiliser la puce audio.
Nous devions graver un CD, ce qui prenait du temps à l'époque, et l'état du logiciel de gravure de CD était tel qu'il n'y avait pas de mémoire tampon, de sorte qu'il fallait s'assurer que le PC n'essayait pas de faire autre chose pendant qu'il créait un CD, sinon il se plantait.
Jason Page a créé un nouvel ensemble de musique sur CD. Il avait un meilleur équipement chez lui, alors il est resté à la maison pendant une semaine pour utiliser son matériel, dont un Korg M1, un Akai S950, un Roland JV880 et un Cheetah MS6. Nous utilisions des échantillons sur l'Amiga, mais la qualité était loin d'être celle d'un CD, et la musique était orchestrée par notre logiciel ; créer des pistes de CD complètes était une nouveauté pour nous. Le fait de jouer de la musique sur CD a libéré la puce audio pour qu'elle s'occupe uniquement des effets sonores. Comme Jason Page l'a fait remarquer, il a également inclus des effets sonores ambiants autour de la musique du CD. Le seul problème est que la lecture en boucle de la musique entraîne une pause, le temps que le laser du CD trouve le point de départ.
Ce jeu ressemblait beaucoup plus à un travail d'équipe que, par exemple, Paradroid 90, car la direction du jeu était définie par un plus grand nombre d'entre nous. Il m'a appris que les jeux de plates-formes ont besoin de beaucoup plus de variété que je ne le pensais. C'était bien de faire enfin un projet mené sur Amiga, et je suis particulièrement satisfait de l'aspect de la version A1200, et de la façon dont la version CD32 tourne aussi.
|
