Suivez-nous sur X
|
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z,
ALL
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
A propos d'Obligement
|
|
David Brunet
|
|
|
|
Actualité : Dans les coulisses du développement d'Uridium 2 (première partie)
(Article écrit par Derek De La Fuente et extrait de Joystick - octobre 1992)
|
|
Andrew Braybook travaille sur la réalisation de son prochain jeu 16 bits, Uridium 2. A partir de ce
numéro, tous les mois, vous retrouverez le journal d'Andrew qui nous écrira toutes les difficultés
qu'il rencontre, et qui détaillera le travail qu'il développe pour son jeu. Considéré comme l'un
des meilleurs programmeurs de l'industrie des jeux vidéo, notamment grâce à Fire & Ice qui est sûrement
l'un des jeux de plates-formes les plus réussis sur Amiga ou Atari ST, Andrew nous prépare un jeu de tir
qui risque de captiver plus d'un joueur.
Quelques petites précisions avant tout. Le projet Amiga que l'on connaît maintenant sous le nom d'Uridium 2
est la suite d'un jeu sur Commodore C64 appelé à l'époque, vous l'avez deviné, Uridium. Ce jeu, sorti en
février 1986, offrait un défilement horizontal d'une rapidité sidérante pour servir l'un des meilleurs
jeux de tir de l'époque. Une suite, Uridium+, est sortie une année plus tard et les deux versions sont
apparues depuis lors sur de nombreuses compilations.
Graftgold, le label où travaille Andrew, a commencé à développer des jeux 16 bits pour Atari ST et Amiga en
1989 avec la conversion de Rainbow Islands, puis d'autres titres sont sortis : Simulcra, Super Off Road,
Paradroid'90, Realms et Fire & Ice. Pour répondre à la demande du public, Graftgold a commencé à travailler
sur Uridium 2, qui offrira tout ce qu'il y avait dans la version originale sur C64, plus bien d'autres
éléments. Laissons maintenant la plume à Andrew Braybook qui va nous décrire son travail dans les moindres
détails.
Andrew Braybrook et John W. Lilley (avec la tronche de Cool Coyote, le héros de Fire & Ice)
Nous avons démarré ce projet en plein milieu du développement de Fire & Ice ; à l'époque, le jeu n'était qu'une
ébauche, quitte à reprogrammer de nombreuses routines par la suite sans avoir à tout refaire quand même.
Déjà, j'avais le système de défilement et une routine qui permettait d'afficher des objets de différentes
tailles. C'est environ à cette époque que j'ai reçu des visiteurs étrangers, Julian Eggebrecht et Holger
Schmidt, venus de Düsseldorf. Ils étaient en fait à la recherche de tartes aux pommes faites maison, mais
ils ont tout de même jeté un coup d'oeil à mon programme pour voir s'il pouvait aider à accélérer le tout.
Ils avaient vu la démo de Fire & Ice à l'ECTS et voulaient essayer de le faire tourner en 50 images par
secondes. Nous sommes tombés d'accord pour dire que le système de détection des contours du décor prenait
trop de temps, mais qu'il serait vraiment dommage de le retirer. Bien sûr, il y a eu un échange technique,
montre-moi ta routine de défilement et je te montre la mienne ! La technique qu'ils ont utilisée pour Turrican
était différente de la mienne tout en utilisant le même principe. Leur système est-il meilleur ? Cela dépend
en fait de l'application que l'on recherche.
Ébauche d'Uridium 2 en 1987
Avançons donc jusqu'en mai 1992. Fire & Ice fait son chemin, il est donc temps de récupérer les morceaux
d'Uridium 2 qui traînent un peu partout. Une routine de défilement et quelques afficheurs de sprites rapides,
bons pour les animations de fond, mais peu adaptés pour faire tourner de nombreux objets isolés. Je veux
vraiment utiliser le mode 32 couleurs pour ce jeu, pas moins, et c'est un véritable défi. J'ai calculé que
l'avant-plan ne serait pas si terrible que ça à gérer, à condition que l'écran ne soit pas trop énorme.
Apidya semble faire du bon boulot dans ce domaine. Si j'utilise beaucoup de mémoire pour gérer ce problème
de gestion d'avant-plan, je devrais m'en sortir. Je n'ai pas vraiment besoin de beaucoup d'animations d'arrière-plan
dans ce jeu, si j'utilise donc un système plus proche de Turrican je devrais récupérer de la vitesse tout
en perdant des animations.
Comme Turrican dispose de beaucoup d'animations de fond, je pourrais peut-être même en rajouter par la suite,
il faudra juste sortir un peu plus de tartes aux pommes du frigo pour tenir le rythme !
John W. Lilley en plein travail : des documents, des photos de science-fiction sont
utilisés pour reproduire l'ambiance futuriste nécessaire à Uridium 2.
Bien, la routine
de défilement est maintenant réécrite et des modifications mineures ont été apportées aux routines d'affichages
afin de mémoriser l'endroit où les objets étaient affichés pour restaurer le fond par la suite. Avant,
je rétablissais l'écran directement à partir d'une carte de caractères, un peu comme dans un système basé sur
le texte. Pour retrouver l'ambiance du premier Uridium, j'ai ressorti mes vieilles sauvegardes du C64 pour
jeter un oeil au programme source. Je peux l'utiliser comme référence pour obtenir toutes les variations de
vitesses et les accélérations du mode de contrôle, et pour reprendre le système de rafraîchissement de la
mémoire. Tous les bouts de programmes étant assemblés en utilisant le macro assembleur Commodore sur C128.
Il me semble que l'assemblage complet prenait jusqu'à 30 minutes. Maintenant, sur mon PC 486 il me faut 30
secondes.
Uridium 2 dans sa version de 1992. Le jeu commence à prendre forme.
La première chose que j'intègre dans un jeu, c'est le mode de contrôle. C'est absolument vital, le mode
de contrôle est le lien entre le joueur et le jeu. Si cette partie est mauvaise le joueur ne se sentira
pas à l'aise avec le jeu. J'ai repris tous les paramètres du mode de contrôle dans l'original sur C64.
J'ai passé pas mal de temps à réexaminer le programme de contrôle qui était alors divisé en quatre parties
distinctes. Cela me paraît complètement cinglé, j'ai donc réécrit le tout en une seule routine avant de
comprendre pourquoi je l'avais faite comme ça à l'époque. Si vous programmez les mouvements gauche/droite
de façon totalement indépendante des mouvements haut/bas, vous pouvez les isoler pour appeler uniquement la
routine dont vous avez besoin. C'est ce qui se passe dans l'original. Une des améliorations que je veux
apporter dans Uridium 2 est la possibilité de faire voler deux vaisseaux, avec deux joueurs, ou un joueur
plus un vaisseau téléguidé ; ce qui implique une extension de la routine de contrôle ; il est donc préférable
d'y penser avant de l'écrire, plutôt que l'écrire et devoir tout modifier par la suite.
Les vaisseaux se déplacent l'un après l'autre ce qui évite tout conflit s'ils tentent d'aller chacun dans une
direction. La "caméra" suit le vaisseau qui se trouve à l'avant et se recentre sur le second si le premier
se fait détruire. Le second joueur n'a de l'influence que sur les déplacements haut, bas et feu et sa vitesse
est dictée par le premier vaisseau. Ce qui implique une certaine complicité entre les deux joueurs.
La planche de sprites.
Une fois que le mode de contrôle est écrit, le joueur veut pouvoir tirer, il faut donc écrire le générateur
de projectiles, avec leurs mouvements et leurs disparitions quand ils sortent de l'écran. Ce jeu demande
de nombreux projectiles à l'écran, spécialement quand deux joueurs se promènent et cartonnent en même temps.
Pas de programmation spéciale à effectuer, mais des routines rapides. Je veux installer de nombreuses armes,
les joueurs semblent réclamer ces possibilités en ce moment.
Une fois que les projectiles sont installés, il faut des objets à dégommer pour pouvoir tester les routines
convenablement. Plutôt que d'écrire tout le programme qui génère les vagues d'ennemis, je commence par placer
un curseur qui rapporte des points quand on lui tire dessus. Je l'ai aussi défini comme étant un projectile
ennemi pour tester la destruction du vaisseau du joueur. J'utilise toujours un curseur pour ce genre de débogage.
Chez Graftgold, on sait programmer mais personne ne sait laver les moniteurs.
Envoyez vos CV de spécialistes de "Bref, vitres, à l'alcooool".
L'autre amélioration que je veux apporter à Uridium 2 par rapport à l'original, est d'abandonner le système
de bonus machine-à-sous en le remplaçant par une section davantage dans le style de Paradroid où le vaisseau
Manta survole le dernier couloir, se transforme en robot géant et s'écrase sur la coque de l'énorme vaisseau.
La bataille continue alors à l'intérieur, le robot géant combattant contre les nombreux occupants du vaisseau.
Des réacteurs peuvent être détruits pour obtenir des points de bonus, les occupants du vaisseau vous attaquent
et vous devez vous échapper avant que votre armure ne soit complètement détruite.
Je vais utiliser les sprites matériels de façon intensive dans ce jeu, mais l'Amiga étant limité à quatre
sprites de 15 couleurs, et sachant que j'en utilise déjà un pour les étoiles, je dois donc utiliser les sprites
restant avec précaution. Je peux réutiliser les canaux des sprites pour de nombreux objets en bas de l'écran,
des problèmes apparaîtront uniquement s'ils s'alignent horizontalement. Je dois donc les programmer dans un
autre plan. Les sprites seront utilisés principalement pour les projectiles des ennemis, pour les explosions
et les vaisseaux qui ne seront dessinés qu'en 15 couleurs. Si les sprites s'alignent je passerai alors au Blitter
pour éviter les effets de clignotement. En stockant tous les sprites au format Blitter et en les convertissant
au format sprite au moment de les afficher, je suis sûr que les sprites excédentaires seront gérés par le Blitter.
Je vais réécrire les différentes routines d'affichage Blitter. Un affichage isolé ne fonctionnait pas, ce qui a
mis en évidence une erreur fondamentale. Toutes ces routines étaient un peu bancales, à force de les transporter
de programme en programme. Je dispose d'afficheurs simples pour les plans bitmap, d'afficheurs pour objet en
une seule couleur et d'autres afficheurs pour des objets isolés.
Le joueur pourra ramasser des missiles à têtes chercheuses. Voici quelques-uns des problèmes à
résoudre pour cette section : choix rapide de la cible à atteindre, et empêcher d'autres missiles de choisir
la même cible. Si une cible est détruite avant que le missile ne l'atteigne, celui-ci doit s'orienter sur
une autre cible et ne pas tourner en rond comme un crétin. De même, si un missile se fait détruire avant
d'atteindre sa cible, il faut signaler aux futurs missiles que cette cible est à nouveau libre. Je me demande
si le Pentagone a lui aussi le même problème.
Ensuite, j'ai programmé le deuxième mode de contrôle pour le robot, une fois qu'il est entré, à travers
le plafond, sur le pont du vaisseau. Ce mode de contrôle utilisera les huit directions possibles, comme
pour les droits de combats dans Paradroid'90. Je veux que le robot puisse reculer, si nécessaire, pour des
retraites plus dignes, et plutôt que d'avoir des têtes animées, j'ai opté pour des pieds contrôlés séparément.
Cela réduit le nombre d'images nécessaires pour animer le robot et permet d'avoir des mouvements de pieds proportionnels
à la vitesse de déplacement du robot. Comme pour les vaisseaux Manta, deux joueurs pourront être présents
à l'écran, l'un disposant d'un vaisseau téléguidé. J'aime bien commencer rapidement le programme de présentation
du jeu, histoire de faire croire aux gens que le jeu est presque fini. J'en ai profité pour intégrer le
tableau des meilleurs scores et le système d'entrée des initiales des joueurs. J'aime dessiner les polices
des textes moi-même. La police d'Uridium 2 est basée sur des textes des années 1970 en 3D, rendus en 19
couleurs. Actuellement, les lettres se chevauchent les unes les autres, je dois donc réécrire le système
de positionnement et de priorité quand elles se mettent à bouger. Et elles bougent beaucoup.
Voici donc tout ce que j'ai dû faire jusqu'au mois d'août. J'ai maintenant le squelette du jeu, je vais
donc essayer de décrire en détail tout ce qui se passe maintenant, semaine après semaine, en commençant par
la première semaine d'août.
Je ne suis pas très content des animations des robots pour l'instant. Ce qui rend les graphistes complètement
fous car ils doivent le dessiner et l'animer dans une direction, puis le tourner et le redessiner à cause
des changements de lumière pour les huit directions. Je me suis aperçu de ce problème lorsque j'ai essayé
d'en dessiner un moi-même, en reprenant des robots de livres japonais et en les imaginant vus d'au-dessus.
Dessiner un robot détaillé prend du temps, mais l'animer prend une éternité. Je me suis impatienté au bout de
deux rotations, et je me suis alors contenté d'afficher des flèches et des chiffres d'animations sous Deluxe
Paint pour les sauver et voir ce que cela donnait.
A suivre...
|
