 |
Vendredi 23 mai 2025 - 19:05 |
| Translate |
|
| Rubriques |
| Réseaux sociaux |
|
| Liste des jeux Amiga |
|
| Trucs et astuces |
|
| Glossaire |
|
| Galeries |
|
| Téléchargement |
|
| Liens |
|
| Partenaires |
|
| A Propos |
|
| Contact |
|
|
|
Introduction
Le processus de réglage d'un jeu est délicat. Si vous essayez de le faire vous-même, vous adapterez inévitablement le jeu à vos préférences individuelles. De plus, votre expérience croissante du jeu vous fera penser que le jeu est plus facile qu'il ne l'est. Il est essentiel d'inciter d'autres personnes à jouer également, mais pas trop, sinon elles s'y habitueront aussi.
Le réglage peut être effectué en même temps que les tests du jeu et la chasse aux bogues. Pendant ce temps, toute personne effectuant des tests du jeu va accumuler des connaissances sur le jeu et établir des façons d'y jouer.
Note : j'ai "emprunté" quelques captures d'écran sur Internet pour cet article à des fins d'illustration. J'espère que personne ne se souciera si j'ai utilisé votre capture d'écran de mes propres jeux. Merci.
Progression
Dans votre jeu, quel type de progression voulez-vous ou avez-vous besoin ? Vous voulez un jeu qui devient de plus en plus difficile au fur et à mesure que vous avancez ? Vous voulez que le jeu soit assez linéaire ?
Il existe plusieurs façons d'implémenter la progressivité dans un jeu. En général, les premiers jeux de tir en arcade répétaient simplement les mêmes séquences, mais peut-être que les envahisseurs dans Invaders étaient plus proches, les galaxiens dans Galaxian étaient un peu plus rapides ou avaient la gâchette plus facile. Cette progression est assez facile à intégrer dans les algorithmes. Les positions de départ et le nombre d'ennemis peuvent être utilisés, et le calcul des chances de tirer peut inclure le numéro de niveau.
Un jeu de réflexion commencerait facilement, puis introduirait des casses-tête plus sournois, des objets mieux cachés, plus d'étapes pour résoudre le casse-tête, ce genre de choses. Encore une fois, la taille compte, la zone de jeu pourrait être augmentée, par exemple.
Les jeux avec une histoire/un scénario n'ont pas nécessairement besoin de devenir plus difficiles ; la complexité de la compréhension de l'intrigue le gardera intéressant. Ces jeux doivent être difficiles à gérer, il y a tellement de façons pour les joueurs de ne pas s'engager dans l'intrigue. J'ai joué à Dear Esther l'autre jour. C'était assez linéaire, et j'admirais juste le décor. C'est un bon moteur 3D et il vous guide assez bien à travers l'histoire. La seule fois où je me suis retrouvé coincé, c'était quand j'essayais de marcher autour de la fosse souterraine de la cascade et que je glissais sans cesse vers le bas. Heureusement, il y a YouTube !
Identique ou similaire ?
La plupart des jeux d'arcade semblent se jouer de manière très similaire à chaque nouvelle partie. Certains sont identiques : nous avions l'habitude de compter les tirs dans Space Invaders et nous savions qu'au 23e tir, vous deviez tirer sur la soucoupe volante pour 300 points, et tous les 14e tirs suivants rapportaient toujours 300 points - ce n'est pas vraiment aléatoire du tout, mais si vous ne savez pas comment cela fonctionne, cela semblera aléatoire.
Personnellement, j'ai toujours été favorable à l'idée qu'un jeu soit différent à chaque nouvelle partie, mais de manière contrôlée. Par exemple : dans mon jeu Gribbly's Day Out, les Gribblets commencent tous à leur position désignée, mais peuvent ensuite choisir de sauter à une position au hasard. Au moment où le joueur les a trouvés, certains peuvent être assez loin de leur position de départ. Par ailleurs, les vaisseaux de Paradroid sont peuplés de chaque robot choisi au hasard parmi quatre types différents, dont certains sont également augmentés du numéro du vaisseau. Dans Uridium, certaines formations sont générées derrière le joueur, donc cela dépend de la direction dans laquelle vous volez à ce moment-là, et les Uridimines peuvent apparaître à tout moment. Pour moi, cela crée un meilleur jeu à long terme car vous ne savez pas exactement ce qui va arriver. Nous avons laissé la puce SID du C64 générer les nombres aléatoires, donc ils n'étaient pas reproductibles. Quoi qu'il en soit, ce que je veux dire, c'est que si la configuration du jeu est différente à chaque fois, votre niveau de jouabilité par niveau sera un peu plus flou et devrait être notée comme telle. Cela n'a pas d'importance non plus si, occasionnellement, un niveau plus difficile se faufile tôt.
Vous pourriez alors argumenter que mes jeux pourraient ne pas être adaptés aux compétitions car vous ne pourriez pas garantir une difficulté impartiale, mais dans l'ensemble, le hasard s'équilibre - la maison gagne toujours à la fin !
À l'ère d'Internet, si vous souhaitez synchroniser deux ou plusieurs ordinateurs connectés à distance, vous devez utiliser des nombres aléatoires prédéfinis pour vous assurer qu'ils se comportent tous de la même manière. Nous utilisons donc aujourd'hui à la fois des nombres aléatoires prédéfinis et non prédéfinis. Vous pouvez disposer d'un tableau de nombres non prédéfinis pour des choses qui n'ont pas d'importance, comme des fragments d'explosion qui n'interagissent avec rien, et utiliser des nombres prédéfinis pour générer des éléments de jeu qui doivent être identiques sur toutes les machines. Cela ne vous empêche pas d'envoyer le nombre aléatoire prédéfini d'une machine à l'autre pour obtenir un jeu synchronisé différent à chaque fois.
La poursuite de la perfection
Il va sans dire qu'un jeu doit pouvoir être joué jusqu'au bout. Il ne doit pas y avoir de bogues ou d'erreurs de positionnement qui empêcheraient le jeu de pouvoir être terminé. Il n'y avait pas de possibilité de mise à jour en ligne à l'époque, tout devait fonctionner avant que la première série de bandes magnétiques ne soit réalisée. Je veux aussi que cela soit très clair : les mises à jour gênent vos utilisateurs.
Évidemment, c'est bien de corriger ces bogues, mais il ne devrait pas y en avoir, et cela demande beaucoup de temps et d'efforts de la part de chaque utilisateur pour maintenir son logiciel à jour. J'obtiens ici un débit de 1,2 Mo/s. Visual Studio 2017, avec tous les accessoires, a pris presque une journée être téléchargé, sur chaque ordinateur...
L'époque des 8 bits
Quand j'ai quitté mon travail dans l'informatique pour écrire des jeux, je suis resté en contact avec mes amis restés là-bas et je leur rendais visite la plupart des week-ends avec une version en cours de développement du jeu que j'écrivais à l'époque. Il est inestimable de rechercher l'opinion générale des autres.
J'ai regardé quelques vidéos YouTube de certains de mes anciens jeux qui étaient en train d'être joué ou critiqué. Il est clair que beaucoup de ces joueurs/testeurs n'avaient pas les manuels d'instructions originaux fournis avec les jeux. Cela les conduit à être plutôt frustrés car ils ne savent pas quoi faire ou comment le faire. Les manuels sont importants et mériteraient leur propre article sur mon site. Les jeux d'arcade doivent attirer les gens pour qu'ils y jouent, ils peuvent donc avoir des séquences de démonstration ou d'instructions assez détaillées, mais en général, ces jeux essaient également de garder les choses assez simples car ils veulent seulement fournir une expérience de jeu de cinq ou dix minutes.
Les jeux vidéo peuvent être plus complexes, un jeu 8 bits peut prendre une ou deux heures pour être terminé dans son intégralité, une fois que vous avez appris à y jouer, étudié le manuel et vu tous les indices que nous avons pu inclure dans le texte. J'avais l'habitude d'écrire les manuels, y compris l'histoire de fond, pour mes jeux. Mon collègue de Graftgold, Steve Turner, faisait de même.
En regardant un gars jouer à Gribbly's Day Out sur YouTube, j'ai réalisé qu'il n'avait pas le manuel et malgré les instructions de "Sauver les Gribblets" au début, il ne savait pas ce qu'était un Gribblet. Il a commencé à voler n'importe où et à jouer avec la grille électrique, ce qui est un truc avancé presque inutile au début, et a ignoré les créatures sauteuses qu'il était censé sauver. Si j'avais mis une "photo d'un Gribblet" à côté du message, il aurait au moins su ce qu'il cherchait. D'un autre côté, dois-je avoir de la sympathie pour quelqu'un qui n'a pas le manuel ? Je suis tout à fait pour une bonne documentation officielle. De nos jours, il y a beaucoup de documentation non officielle en ligne et elle est simplement éparpillée un peu partout.
Quand j'ai regardé un autre gars jouer à Paradroid, il n'avait pas réalisé que si vous percutez un autre robot, ou rugissez "à pleines dents" contre lui, vous devez reculer quand il explose. Les explosions peuvent endommager les plus petits robots. Il y a des effets sonores qui font allusion aux dégâts, et si vous regardez la vitesse de rotation de l'icône du joueur, vous pouvez voir que vous subissez des dégâts. Il ne savait pas non plus ce qu'étaient les blocs de ré-énergisation, donc il ne savait pas qu'il pouvait récupérer son énergie.
Combien d'informations devez-vous donner au nouveau joueur ? Cela dépend de sa capacité à s'y retrouver dans le jeu pendant un certain temps et à le comprendre par lui-même. Encore une fois, la borne d'arcade ne se gêne pas pour collecter quelques pièces de 10 centimes le temps que nous nous habituons au jeu, tant que nous le faisons. Je ne passe pas des jours à réaliser les manuels et les histoires pour qu'ils soient ignorés ou, Dieu nous en préserve, pas payés.
Mes tests 8 bits
Mes quatre premiers jeux étaient des conversions des jeux ZX Spectrum de Steve Turner : 3D Space Wars, Seiddab Attack et Lunattack (deux fois). Pour la plupart, ces jeux étaient juste des tracés de graphismes aussi rapide que possible. Je ne me souviens d'aucune régulation de la vitesse dans la boucle de jeu principale, et dans 3D Space Wars, vous pouvez sentir le mode de contrôle trembler quand il y avait beaucoup de gros vaisseaux à l'écran. Les deux autres titres avaient davantage de graphismes à l'écran, notamment pour l'arrière-plan, donc la boucle principale était mieux régulée. Il serait intéressant de voir comment ils se comportent sur des ZX Spectrum et C64 super rapides.
J'ai mis un contrôleur de vitesse dans la version Dragon 32 de 3D Space Wars pour permettre au joueur un peu de contrôle, et le contrôleur était proportionnel, mais pas le clavier.
Un conseil de programmation : plutôt que de faire de vos modes de contrôle des constantes dans le code, mettez les valeurs dans des variables pour pouvoir les ajuster à la volée. De cette façon, vous pouvez régler le mode de contrôle en temps réel.
Steve Turner et moi avions aussi l'habitude de tester les jeux de l'autre. J'ai passé pas mal d'heures à jouer à Avalon, DragonTorc et AstroClone sur ZX Spectrum. Après chaque session, nous pouvions donner notre avis sur ce que nous pensions être trop difficile ou trop facile. Une fois que vous avez acquis une certaine expérience de votre propre jeu, vous connaissez tous les petits détails, les autres ne connaissent pas les algorithmes sous-jacents et en savent donc moins que vous. Par exemple, je savais que les sentinelles de Paradroid 90 tiraient quelques balles puis s'arrêtaient, pour recharger : je pouvais ainsi attendre qu'elles tirent une salve puis les attaquer. Les autres personnes ne s'en rendaient peut-être pas compte. C'est pourquoi il est vraiment important d'observer comment les autres jouent et de leur demander ce qu'ils pensent.
Lorsque vous laissez un éditeur jouer à votre jeu, il est préférable de vous assurer que vous êtes là pour lui montrer comment jouer en premier. Bien sûr, il aura du mal à y jouer, et il aura encore plus de mal à l'accepter s'il ne ressemble pas exactement au dernier titre à la mode. L'innovation peut être un gros mot pour eux. J'aime aussi que la majeure partie du travail soit faite pour qu'ils ne voient que le produit presque fini. Si vous montrez quelque chose trop tôt, l'impact total de tout ce que vous avez fait est perdu, et vous passerez des heures à modifier des éléments inutilement pour eux.
Je ne suis pas convaincu de l'intérêt de publier des versions préliminaires de jeux sur Steam ou d'autres plates-formes non plus. Oui, c'est sympathique d'avoir des retours mais encore une fois, c'est comme savoir à l'avance quel sera votre cadeau d'anniversaire et pouvoir jouer avec avant qu'il ne soit fini.
Ma préférence est de terminer la programmation et de fournir un niveau de démonstration, comme nous l'avons fait sur les disquettes de magazines. Ils ont toujours été produits à la dernière minute comme une version réduite du jeu fini. Nous supprimions la séquence de fin et la remplacions par un message de vente. Essayez simplement de mettre certains de vos meilleurs graphismes dans la démo.
Gribbly's Day Out
Mon jeu Gribbly's Day Out proposait seize niveaux. Je ne voulais pas qu'ils se jouent les uns après les autres, mais je voulais disposer d'un niveau d'entraînement facile pour commencer et un dernier niveau monstrueux pour conclure. Entre temps, j'ai arrangé les quatorze autres niveaux, en gros, par ordre de difficulté, mais... ensuite j'ai modifié l'algorithme de sélection du niveau suivant de sorte que plus vous sauvez de Gribblets, plus il peut choisir de niveaux pour le suivant.
Gribbly's Day Out sur C64
Lorsque j'ai mis en place les arrière-plans de niveaux de Gribbly, j'ai commencé à créer des trous plus petits et plus sournois pour faire passer le personnage de Gribbly. J'ai également mis en place quelques niveaux de tunnels avec plusieurs petits trous. Vous ne devez pas irriter le joueur en plaçant ensuite les huit Gribblets à l'autre bout du tunnel, c'est juste une torture, alors ne soyez pas trop méchant. Mettez aussi des Gribblets faciles à sauver. Cela donne au joueur le dilemme de sauver les plus faciles en premier, ou les plus difficiles.
J'avais l'habitude de m'entraîner pas mal sur les nouveaux niveaux. S'il y avait un espace trop étroit et que je ne pouvais passer qu'une fois sur quatre, il fallait l'élargir. On ne peut pas passer trop de temps à tester tous les espaces, car on s'y habitue. C'est là qu'intervient ma fidèle équipe de test. Une fois que j'étais assez satisfait d'un niveau, je pouvais la leur apporter et les laisser l'essayer. S'ils se plaignaient trop, je prenais note et je le modifiais pour la prochaine fois.
Les seuls autres paramètres qui changeaient à chaque niveau de Gribbly étaient l'instinct de retour à la maison de Seon, l'ennemi ultime, il devenait plus fougueux et le cycle de vie des autres ennemis s'accélérait, donc ils ne passaient pas autant de temps dans chaque forme. Le reste de la difficulté résidait dans la conception des cartes.
Paradroid
Les cartes de pont de chargement de Paradroid sont accessibles plus ou moins selon les choix du joueur, donc la séquence n'a plus d'importance. Le joueur commence toujours sur un pont plus facile. La difficulté du jeu vient alors de la taille des ponts et des robots qui y apparaissent. J'ai tendance à faire en sorte que les ponts de chargement contiennent généralement beaucoup de droïdes de combat, et le cyborg 999 était toujours sur le pont avec quelques gros acolytes. Les ponts ont tous des noms et certains laissent plus d'indices que d'autres sur le type d'opposition à attendre. L'ingénierie a des droïdes de maintenance, les ponts d'équipage ont des droïdes serviteurs.
Paradroid sur C64
Il n'y a pas de concept de vies supplémentaires dans Paradroid. Si vous avez pris le contrôle d'un plus gros robot, je devais m'assurer qu'il pourrait résister à quelques coups des grosses armes, et s'il se fait tirer dessus en dessous de vous, vous devriez vous enfuir rapidement. Puisque le jeu applique les mêmes règles au joueur qu'aux autres robots, là encore, il s'autoéquilibre.
Uridium
Pour Uridium, je voulais de l'arcade pure. Ayant 50 images par seconde et un joli aspect métallique multicolore, j'ai opté pour une progression linéaire simple. Il y avait des murs sur le premier pont sur lesquels on pouvait s'écraser, cela servait d'apprentissage "des règles" au joueur, et la plupart des cuirassés sont aussi longs qu'ils peuvent l'être.
Uridium sur C64
De même, les Uridimines progressent linéairement dans leurs chances de production, et je pouvais assez facilement ajouter plus ou moins de ports d'Uridimines dans les niveaux, vous pouviez vraiment en mettre autant que vous le vouliez quand vous le vouliez.
Les données pour les arrière-plans ont été conservées avec les données de formation pour ce niveau. De cette façon, je pouvais les mélanger assez facilement dans l'éditeur de sources et les organiser dans ce que je pensais être un ordre de difficulté. Cela m'a également permis d'insérer un autre niveau facile au début, juste pour donner aux joueurs le sentiment chaleureux qu'ils peuvent progresser.
Finalement, comme le contrôle du Manta lui permettait de voler sur le côté, j'ai pu commencer à utiliser des espaces vraiment étroits. C'est devenu comme celui de Gribbly. Pendant que je créais les données de la carte d'arrière-plan pour un niveau, il serait le premier vaisseau et je pourrais jouer dessus autant de fois que je le voulais, et sans aucune formation d'attaque. Cela m'a donné le temps de voir que le Manta pouvait aller d'un bout à l'autre du niveau. J'étais devenu un pilote compétent et je devais alors retirer un peu d'éléments. Mais au moment où le joueur arrive au niveau 15, il avait probablement joué aux niveaux précédents pendant un bon bout de temps, donc j'ai pensé que si je pouvais terminer le niveau, sans être forcément un bon joueur, alors beaucoup d'autres y arriveraient.
J'ai créé seize niveaux supplémentaires pour Gribbly's 2nd Day Out et Uridium Plus, et j'ai essayé de rendre les niveaux suivants un peu plus difficiles que dans l'original. Pour mémoire, j'ai fait Uridium deux fois pour atteindre Iron trois fois avant d'être battu, mais j'ai seulement fait Uridium Plus une fois, arrivant au niveau 10, pour la deuxième fois environ. Mon meilleur score sur Uridium était de 537 035.
Alleykat
Pour Alleykat, je voulais que le joueur puisse choisir les races avec lesquelles il voulait se confronter. De cette façon, s'il y avait un type de race qu'il n'aimait pas, il pouvait l'éviter complètement. Donc, d'une certaine manière, les courses se déroulaient comme les niveaux de Gribbly, mais vous n'étiez pas obligé de participer à toutes, même si vous le pouviez. Vous ne pouviez participer qu'aux courses que vous pouviez vous permettre, donc comme les frais de participation et les prix en argent augmentaient au fur et à mesure que les courses progressaient, vous ne pouviez pas passer directement aux courses difficiles, et vous deviez terminer les courses antérieures.
Alleykat
J'ai essayé de définir les valeurs de la plupart des arrière-plans de manière à ce qu'ils explosent avant que vous n'y arriviez (ce qui les éliminerait à coup sûr, tout en endommageant le joueur). Les décors de Skullnia sont cependant insensibles aux balles. Cela signifie que j'ai pu créer des pistes qui devaient être négociées plutôt que détruites, au moins pour le premier tour. Au fur et à mesure que la course avance, les autres vaisseaux commencent à retirer les éléments de décor pour vous.
Les arrière-plans réels sont générés par algorithme. Je pouvais définir la probabilité d'avoir un élément vierge et la probabilité d'avoir un élément d'arrière-plan haut ou bas à chaque obstacle. J'ai également pensé que je pouvais également définir la distance entre les obstacles. L'algorithme doit également garantir qu'au moins un élément d'arrière-plan franchissable se trouve dans chaque obstacle. Pour la dernière course, j'ai également veillé à ce qu'il y ait un gros crâne insensible aux balles dans la bouche duquel vous devez voler juste devant le joueur au départ.
Il y a également des pastilles d'énergie sur le sol dans les courses, encore une fois générées par algorithme au hasard, ce qui me permet d'en faire beaucoup ou peu dans chaque course. Ceux d'entre vous qui ont le manuel savent peut-être aussi que terminer une course avec une énergie au maximum (ou presque au maximum) vous donne un plus grand réservoir d'énergie pour la course suivante, ce qui signifie que vous pouvez subir plus de dégâts. Cela donne au joueur plus d'objectifs à atteindre. Le fait de recharger votre énergie au fur et à mesure que la saison des courses progresse vous donne un vaisseau plus fort à la fin. Avec plus de sprites, j'aurais peut-être pu le montrer à l'écran. Si seulement j'avais eu le multiplexeur de sprites à ce moment-là.
Morpheus
Le réglage de Morpheus était complètement différent. Les jeux précédents utilisaient beaucoup d'espace mémoire pour les cartes de jeu, et bien qu'Alleykat générait ses cartes, j'avais huit jeux de caractères de 2 ko pour prendre la place des cartes. Pour Morpheus, je voulais beaucoup de sprites. Les vagues d'attaque sont divisées en 50 niveaux, j'ai donc dû initialement inventer 50 séries de vagues d'attaque, puis essayer de les placer dans un semblant d'ordre de difficulté. J'avais également intégré au jeu un système de fonctionnalités de vaisseau très flexible afin que le joueur puisse utiliser un vaisseau bien armé et bien protégé, ou bien il ne l'aurait pas développé, ou il aurait pu le déséquilibrer avec de mauvais choix. Le succès dans le jeu nécessitait que le joueur développe le vaisseau avec de bons choix d'équipements et continue à le mettre à niveau au fur et à mesure que de meilleurs équipements deviennent disponibles. Je n'opterais probablement pas pour la coque géante, c'était pour démontrer que l'on peut aller trop loin.
Morpheus sur C64
Intensity
Chaque niveau d'Intensity est une bataille distincte. Il y a presque 80 niveaux dans le jeu, disposés dans un rectangle de 16x5. Vous commencez au milieu à gauche et devez vous rendre à l'extrémité droite. Les cinq brins horizontaux représentent différents niveaux de difficulté, la route alpha supérieure étant la plus difficile. Certains niveaux vous permettent de progresser vers la droite, d'autres ne permettent que de monter ou de descendre, donc le chemin n'est pas nécessairement simple pour arriver à la fin. Vous devrez certainement jouer plus de quinze niveaux. Les récompenses sont également plus élevées sur le brin alpha, mais vous avez besoin des meilleurs vaisseaux qui peuvent survoler des obstacles plus élevés.
Intensity sur C64
En plaçant soigneusement les trappes de sortie de l'équipage, vous pouvez forcer le joueur à continuer à déplacer le drone ou à faire face aux conséquences, ou à garder les sorties proches pour un niveau plus facile. Vous devez savoir quels éléments modifier pour créer des énigmes ou ajouter à la difficulté.
Nos tests 16 bits
Nos incursions dans le territoire de l'Atari ST et du Commodore Amiga nous ont obligés à former des équipes. Cela signifiait généralement le programmeur principal, plus deux ou trois graphistes et, vers la fin, l'expert en son et musique. Il y avait aussi Dominic Robinson avec la gestion système pour le système d'exploitation du jeu qu'il avait écrit, ce qui nous permettait d'écrire dans un environnement multitâche préemptif qui était léger pour les jeux.
Je ne vais pas parler de Rainbow Islands ici car nous ne l'avons pas peaufiné autrement que pour nous assurer que nous avions reproduit le jeu d'arcade le plus fidèlement possible. Nous avions beaucoup de documentation de Taito, qui donnait des informations très détaillées sur la vitesse et l'algorithme des commandes du joueur et des ennemis. Les arcs-en-ciel à eux seuls méritent d'ailleurs un article distinct.
Paradroid 90
Pour Paradroid 90, je concevais généralement l'agencement du vaisseau, car tout devait s'assembler sans chevauchement des ascenseurs sur la vue latérale, et les données de connexion devaient être introduites dans l'assembleur et déboguées. Nous avons conçu les niveaux sur un éditeur écrit en STOS pour l'Atari ST. J'ai demandé aux graphistes de concevoir certains des personnages d'arrière-plan pour créer des fonctionnalités et décorer les arrière-plans. J'ai fait moi-même certains des éléments d'arrière-plan simplement parce que, parfois, il est plus facile d'obtenir ce que je voulais.
Paradroid 90 sur Amiga
La conception des ponts de Paradroid 90 suivait la même idée que sur C64 : chaque pont avait un but et était peuplé en conséquence. Les ponts de chargement pouvaient être plus grands avec encore plus de robots dessus. J'ai réduit les types de robots car nous devions refaire des graphismes animés dans huit directions, et cela consommait beaucoup de mémoire. J'ai ensuite diversifié ce que je pouvais faire avec eux. Je pouvais avoir des sentinelles en patrouille sur des itinéraires courts spécifiques, et je pouvais avoir des sentinelles statiques qui garderaient des endroits, les rendant plus difficiles pour tendre des embuscades.
Au fur à mesure que chaque vaisseau prenait forme, nous pouvions les tester en tant que premier vaisseau et prouver que nous pouvions les jouer jusqu'au bout. La conception globale du jeu restait bien équilibrée. J'ai rendu l'intelligence artificielle de la séquence de transfert plus intelligente pour le rendre plus difficile pour le joueur. Les plus gros ponts ont permis de meilleures zones de rencontre, donc j'étais assez libre au niveau de la distribution de gros robots ennemis.
Bien que je puisse atteindre la fin standard du jeu en une (longue) séance, je n'ai pas réussi à battre le bateau pirate supplémentaire secret. Encore une fois, j'étais content que quelqu'un, quelque part, le batte. Quelqu'un ?
Fire And Ice
Fire And Ice était mon premier titre original en 16 bits, si l'on peut dire. J'avais moins de contrôle sur cette nouvelle création car les jeux de plates-formes ne sont pas mon fort. C'est bon de changer de genre pour garder l'esprit clair. Phillip Williams était l'artiste principal et s'intéressait beaucoup à la conception des sprites, des arrière-plans et des casses-tête, tout comme Jason Page. Ils apportaient volontiers des idées.
Fire And Ice sur Amiga
Chaque pays avait ses propres constantes de mouvement du personnage (le coyote) pour décider des accélérations, des vitesses de pointe, de la friction et de la traînée. À part les sections de glace et sous-marines, les valeurs étaient globalement les mêmes. Si je faisais une suite, j'essaierais peut-être le Japon, le Pérou, l'Australie et l'Antarctique, avec des ours polaires. J'aimerais aussi représenter le Pays de Galles d'une manière ou d'une autre.
Lorsque nous sommes passés aux graphismes 16x16 pixels, nous avions besoin d'un nouvel éditeur de cartes. Steve Turner en a écrit un sur PC. Les graphismes ont été réalisés avec Deluxe Paint, également sur PC. Phillip Williams a dessiné la plupart des graphismes originaux et j'ai programmé tous les ennemis. Je me souviens que nous n'étions pas satisfaits de la vitesse du coyote, alors je suis allé à Londres pour rencontrer Jaz Rignall et voir ce qu'il pensait de la démo. Le résultat de cette discussion a été que j'ai dû accélérer le coyote. Cela a changé la vitesse de saut, la gravité et les accélérations et vitesses latérales, en gros, tout cela était lié. Une fois satisfait, j'ai essayé de jouer à l'un des premiers niveaux développés et j'ai réalisé que les ennemis sauteurs étaient affectés par le changement de gravité et que je devais les recalibrer. Le prochain domaine connexe concernait tout l'armement dans ces niveaux de glace, tout cela avait besoin d'être ajusté aussi. Mieux vaut régler vos constantes physiques dès le début !
Heureusement, rendre le coyote plus rapide n'a pas gâché les intervalles de saut car sa portée de saut globale est restée similaire, sinon, nous aurions peut-être dû faire beaucoup d'ajustements de carte également. Fire And Ice ne nécessitent pas la précision au pixel près de, disons, Manic Miner, sinon nous aurions dû être encore plus prudents. Les vitesses de pointe du coyote étaient toutes en pixels entiers, les accélérations avaient une précision de 65 536 d'un pixel, tout comme les coordonnées. Les routines de tracé coupaient les positions des sous-pixels.
La majorité des ajustements de réglage provenaient de l'ajout de davantage d'ennemis jusqu'à ce qu'il y en ait trop, puis d'en retirer un ou deux par la suite. Les positions de départ des ennemis ont été entrées dans mon code en assembleur, pas dans l'éditeur de carte, donc j'ai gardé un strict contrôle sur celles-ci. De même, la force des gros chefs de fin de niveau doit être réglée avec soin. Je déteste rencontrer des chefs apparemment invincibles, surtout si vous ne voyez pas que vous progressez contre eux. J'aime bien les chars des chefs dans Flying Shark qui commencent à s'enflammer, cela permet de voir que vous les avez endommagés.
Nous avons fini par rendre les premières terres glacées aussi faciles que possible, la plupart des ennemis ne ripostent pas, simplement parce que le mode de contrôle est un peu difficile sur la glace, et je n'essayais pas de créer une séquence de tir. L'apport de l'équipe sur ce jeu a été vital au niveau de la variété. Phillip Williams et Jason Page en particulier ont eu beaucoup d'idées.
Uridium 2
Ce jeu fut le plus difficile de tous. Nous avons commencé avec une version à double plateau de jeu. Cela nous a donné sept couleurs pour la couche avant et trois pour la couche inférieure arrière, qui défilaient en parallaxe. Phillip Williams a créé un prototype de vaisseau qui avait l'air bon, bien qu'avec les choix de couleurs limités, il ressemblait à un gros dessin animé. Il a bien réussi la mise à l'échelle. Nous avons ensuite réalisé que la plupart des objets en mouvement devaient également disposer de ces sept mêmes couleurs, ce qui les faisait se fondre dans le décor. Réserver une ou plusieurs couleurs pour les obstacles était également peu pratique, tout comme réserver certaines couleurs pour les sprites.
Uridium 2 sur Amiga
J'avais du mal à obtenir de la part des collègues de bons graphismes que je pensais que nous devrions être capables de faire, étant donné que c'était notre premier jeu en 32 couleurs. Puisque les graphismes d'arrière-plan définissent toute l'arène du jeu, ils devaient être de qualité. A l'époque, d'autres sociétés rivales prirent le chemin des couleurs supplémentaires.
Ces graphismes devaient également être fonctionnels. On devait pouvoir voir sur quels éléments des cuirassés il ne fallait pas s'écraser. Cela pouvait être signalé par de grandes ombres projetées, ainsi que par leurs propres couleurs. Il s'avère que les choix de couleurs que j'ai faits sur C64 et la simplicité des graphismes étaient ce dont le jeu avait besoin, et tous les choix de couleurs supplémentaires brouillaient les pistes.
Je voulais aussi disposer de six styles différents pour les arrière-plans, mais nous avons eu du mal à en obtenir un seul. Si les obstacles en arrière-plan ne sont pas évidents à déceler, le joueur sera frustré de s'écraser dessus. Nous avons fait appel aux services de Stephen Rushbrook, qui n'habitait pas très loin.
Les graphismes d'arrière-plan ont été réalisés à partir de caractères de 16x16 pixels, dessinés avec Deluxe Paint, puis introduits dans l'éditeur de cartes du PC. Les cartes doivent être, au moins partiellement, assemblées par le graphiste car il doit concevoir les blocs et réaliser des constructions plus grandes. Personne d'autre ne peut les assembler toutes, c'est comme un puzzle personnalisé où toutes les pièces sont carrées. Vous n'avez que les pixels pour voir comment elles s'assemblent.
Si vous n'êtes pas l'artiste, vous pouvez utiliser deux blocs, puis vous pouvez assembler des éléments qui fonctionnent, mais si l'artiste change ensuite quelques blocs, votre mauvaise utilisation de ceux-ci pourrait casser l'emboîtement. C'est pourquoi j'étais le plus heureux sur C64 en faisant mes propres graphismes, cartes et programmation !
Bref, Stephen Rushbrook a très vite compris ce dont j'avais besoin. Il a commencé avec un ensemble graphique qui a fini par devenir le deuxième ensemble de quatre vaisseaux. Il avait des lignes très claires et des éléments muraux brillants, presque avec de la lueur. Cet ensemble était en fait destiné à être le premier ensemble, mais en raison de la demande des éditeurs pour des vaisseaux plus faciles à manoeuvrer, il a été remplacé.
C'est là que la jouabilité est ajustée. Vous ne pouvez pas nécessairement modifier les niveaux que vous avez créés pour les rendre plus faciles. Vous pourriez finir par rejeter certaines des fonctionnalités dessinées qui sont un peu trop difficiles, mais personne n'aime jeter du bon travail, alors vous le faites passer au niveau supérieur et essayez de dessiner ensuite quelque chose de plus facile à jouer à partir de zéro. Malheureusement, Renegade, notre éditeur, avait du mal à jouer les premiers niveaux et a donc continué à demander que le jeu soit plus facile au début.
Nous avons fini avec un nouveau premier ensemble de vaisseaux, qui avait l'air un peu plus intelligent que l'ancien premier ensemble, mais sans aucun mur sur les deux premiers niveaux, puis nous en avons ajouté sur le suivant. Comme nous avons conservé le prochain ensemble de quatre vaisseaux, le premier niveau de ceux-ci, qui devait être le niveau d'ouverture du jeu, devint à nouveau plus facile. D'une certaine manière, Uridium sans murs est comme un char sans munitions.
Quand nous sommes arrivés au quatrième ensemble de quatre vaisseaux, Stephen Rushbrook a proposé dans la foulée un ensemble de graphismes solides et quelques diaboliques tourelles laser. À ce stade, c'était mon tour d'essayer de rendre le jeu plus facile. Je testais tous les niveaux et avec le défilement horizontal et vertical, l'espace devenait plus grand. Un nouveau problème commençait à se poser : il était facile de se perdre dans les niveaux. Une personne plus maline que moi aurait pu mettre plus d'une piste d'atterrissage par niveau pour équilibrer cela, ou marquer utilement la ou les pistes d'atterrissage finales sur le radar, mais nous avons commencé à penser que la navigation allait devenir une partie plus importante du jeu. Il fallait donc être flexible avec la conception du jeu si des opportunités d'extension se présentaient.
Si vous avez une séquence de fin, vous avez tendance à vouloir vraiment que le joueur se donne la peine de la voir, donc les niveaux finaux ont tendance à être un peu plus difficiles qu'ils ne devraient l'être. Lorsque le temps de développement est écoulé, vous devez vous contenter de ce que vous avez. Tout ce que vous pouvez faire, c'est réorganiser un peu les choses. Vous ne voulez pas d'une partie vraiment difficile au milieu, puis que le jeu redevient plus facile : vous perdrez alors des joueurs qui abandonnent.
Je ne me souviens plus maintenant du nombre de vaisseaux que nous avons donnés sur les disquettes de démonstration de magazines, mais certaines personnes ont signalé qu'elles ne pouvaient pas gérer ces niveaux. Il n'y avait que des niveaux faciles aussi. À moins que votre jeu ne s'adapte aux performances du joueur, il n'y a aucun moyen de s'adapter aux capacités de chacun, et si vous essayez de vous adapter, vous vous retrouverez avec des joueurs qui savent qu'ils ne doivent pas trop se casser la tête, le jeu sera facile pour eux. De plus, personne n'a le droit de se vanter, cela ne fonctionnerait pas aux Jeux Olympiques : "J'ai décidé de ne pas courir trop vite, alors tout le monde a ralenti pour moi et j'ai eu la médaille d'or".
Le dernier mot
Il est très important de déterminer la jouabilité et la progression d'un jeu. Faites confiance à votre instinct. En tant que concepteur de jeu, vous avez un avantage sur la plupart des autres joueurs en apprenant à jouer au jeu en premier, et l'évaluation de la difficulté reste la même d'un niveau à l'autre. Assurez-vous simplement de pouvoir terminer tous les niveaux, de préférence en une seule session, mais au moins en les jouant un par un. Si vous perdez dix vies en terminant un niveau, c'est que c'est trop dur ! Avec un peu de pratique, vous devriez pouvoir terminer chaque niveau sans trop de difficultés. Laissez également d'autres personnes jouer, regardez-les, aidez-les et prenez note de leurs commentaires.
|
