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 (troisième partie)
(Article écrit par Derek De La Fuente et extrait de Joystick - décembre 1992)
|
|
Voici la troisième partie du journal de bord d'Andrew Braybrook sur le développement de son nouveau
jeu de tir, Uridium 2.
Septembre, deuxième semaine
Le moment du grand plongeon est arrivé, il est temps de découper le programme en deux parties. Je
dois pouvoir les charger séparément dans l'éditeur de liens, pour les tester et les déboguer
sans trop de galères. Ras le bol de charger le programme sur le PC pour le rebalancer sur Amiga.
Dans la version finale, le jeu chargera la partie relogeable à partir de la disquette puis la
placera en mémoire Fast ou en mémoire normale, selon la bécane. Ensuite je peux déplacer tout le
programme et ses données afin de faire de la place aux graphismes et aux sons échantillonnés qui
doivent se trouver en mémoire centrale. Toutes ces opérations m'ont pris deux jours et demi de temps,
la dernière phase était la plus compliquée.
Comment tester mon programme qui reloge la mémoire ? Celui-ci n'est supposé gérer que les fichiers
chargés directement à partir de la disquette, ce qui implique qu'il ne doit pas y avoir de débogueur en
mémoire. J'ai donc été obligé de construire une version hybride entre le débogueur et le programme
final. Je suis encore obligé de tricher un peu en intégrant les graphismes et les sons directement
plutôt que de les charger à partir de la disquette. Enfin bref, tout marche finalement.
Septembre, troisième semaine
Les premiers décors de fond, les premières cartes, viennent d'être réalisés à l'aide de notre
nouvel outil interne sur PC, notre éditeur de carte. Je ne construis jamais d'éditeur de cartes
à l'intérieur de mes programmes pour les retirer au dernier moment. Je déteste écrire des éditeurs
de cartes. Nous utilisons donc un éditeur de cartes maison général qui nous servira pour nos
prochains produits. Celui-ci est écrit sur PC et utilise le mode VGA qui est le mode le plus
standard incluant tous les autres modes courants, quelles que soient les bécanes.
Nous ne pouvons utiliser nos éditeurs de cartes Atari ST car le jeu utilise 32 couleurs ce qui est
plus que l'Atari ST ne peut supporter.
Malheureusement, le programmeur auteur de l'éditeur de cartes
a quitté la compagnie et son programme n'est pas terminé. Ce qui rend les choses encore plus intéressantes !
De nombreuses options ne sont pas encore intégrées et des bogues traînent dans les coins.
Jason, notre expert en son, a tenté de synthétiser de la voix ce week-end. Il vient de m'informer que
les échantillons de sons ont grossi pour atteindre maintenant 140 ko. C'est bien plus que
tout ce que j'ai pu mettre dans un jeu jusqu'à maintenant, je préférais les sons générés aux échantillons.
Bien sûr, certains sons ne peuvent être générés de cette façon et nous avons dû utiliser un compromis
entre les deux techniques.
Je viens de découvrir un bogue atroce dans le système de défilement : descendre de plus deux écrans
provoque une véritable explosion de l'écran, tout se mélange dans tous les sens. Incroyable que
ce bogue soit resté aussi longtemps sans que personne ne s'en aperçoive. J'ai mis du temps à localiser
le problème, maintenant le fichier est "en travaux".
La première carte est enfin terminée et vient d'être intégrée au jeu, ce qui met en avant un problème quant
à la génération des vaisseaux ennemis. Ils apparaissent à partir de coordonnées fixes, ce qui est suffisant
pour un jeu qui ne défile pas verticalement, et qui est un problème s'ils débarquent tout en haut de la carte
et foncent latéralement. Tous les évènement doivent se dérouler à l'écran visible sinon le joueur risque
de passer à côté de l'action.
Maintenant que la musique et les sons ont largement été testés, je peux me permettre de les virer de ma
version de travail d'Uridium 2, ce qui me libère 140 ko de mémoire. Je n'ai pas envie de rendre toute
l'équipe cinglée avec la même musique qui tourne plusieurs heures par jour. Même si le morceau est excellent.
Septembre, quatrième semaine
Les deux parties d'Uridium 2, la section Manta et celle où l'on dirige le robot, divergent de plus en plus :
graphismes de fond et sprites différents, je vais donc les séparer en deux programmes, en deux blocs
distincts. Cela fait de la place en mémoire normale, puisque les graphismes doivent se trouver à cet endroit,
quel que soit le nombre de gigaoctets de mémoire Fast dont dispose votre ordinateur.
Les échantillons de sons doivent se trouver dans cette partie de la mémoire eux aussi.
Je viens de me transformer en réparateur télé, mon moniteur n'arrêtait pas de déconner, et en particulier le
rouge qui se coupait souvent. A force de brancher et de débrancher les prises arrière pendant le développement
de Fire & Ice, pour passer de l'Atari STE à l'Amiga, les soudures sont devenues fragiles. Avec les 25 000
volts qui traînent autour du tube, j'ai plutôt intérêt à faire hyper gaffe.
J'ai apporté quelques modifications au programme, maintenant il accepte n'importe quel type d'extension
de mémoire. Retour au jeu lui-même, maintenant. Il est bon de régler quelques petits détails, si le joueur
appuie sur feu pendant que "Player 1 Ready" est affiché alors le jeu démarre tout de suite. Quand c'est le
joueur 1 qui joue, le score du joueur 2 est assombri et vice versa, ainsi, d'un coup d'oeil, les joueurs
savent où ils en sont.
La routine qui gère les missiles à têtes chercheuses a aussi été améliorée, maintenant ils ne tourneront plus
en rond comme des crétins si leur cible a disparu avant qu'ils ne la touchent. Je dispose maintenant de
véritables graphismes pour les séquences à l'intérieur du vaisseau, je n'aurai plus à utiliser les sprites de
Paradroid '90 pour tester mes routines. J'ai jeté un coup d'oeil à mon vieux programme sur C64 (Uridium premier
du nom) pour voir ce que je faisais avec les vaisseaux volants. Mon nouveau programme m'autorise beaucoup plus
de déplacements en formations de vaisseaux. A l'époque, j'avais laissé de côté la possibilité d'un mode
chasse pour les ennemis : un vaisseau se déplace et se cale face au vaisseau du joueur avant de tirer.
Maintenant c'est envisageable, et avec des déplacements beaucoup plus fluides.
Octobre, première semaine
Pour que le joueur en prenne encore plus dans la tronche, je réfléchis à l'élaboration de nouveaux
vaisseaux ennemis. J'ai beaucoup plus de liberté sur Amiga que sur C64, je peux animer plus d'objets
à l'écran et varier les méthodes et les tailles d'affichage. La première chose nouvelle que je désirais
intégrer était un vaisseau qui décolle des pistes. Il serait d'abord tranquillement installé, garé, et
décollerait pour éviter les tirs qui lui arrivent dessus.
Autres nouveautés ajoutées cette semaine, les tours laser cachées. Elles ne peuvent être touchées
que quand elles sortent pour tirer. Deux tours tirs trois balles en arc de cercle, et deux autres
qui tirent un cercle complet de projectiles. Dans un jeu comme Uridium, le joueur bouge sans arrêt plutôt
que d'être transporté tranquillement par un défilement latéral, du coup, les ennemis n'ont pas besoin
de trop se déplacer. Ce qui permet de ne pas trop surcharger les routines d'affichage qui proposent un
juste milieu entre le nombre d'objets à afficher et la rapidité pour le faire. Un 68000 ne prend presque
pas de temps pour exécuter une instruction, mais afficher un objet demande des centaines, voire des
milliers d'instructions et ça prend du temps cette fois.
Court passage technique spécial gros travaux
Le programme que je suis maintenant en train d'écrire ne concerne pas vraiment l'affichage rapide
d'objets qui, quand vous utilisez le Blitter, est quasiment au maximum de l'optimisation possible.
Le multitâche est un bon moyen de gérer le temps pour exécuter en priorité les évènements obligatoires et
laisser de côté ce qui n'est utile. Mais utiliser le multitâche dans un jeu pour ce qui concerne l'affichage
est loin d'être évident. Dans Uridium 2, je n'utilise cette technique que pour gérer le panneau des scores
des joueurs.
En mémoire, je dispose de trois écrans internes. Habituellement, on en utilise deux en affichant les
objets sur l'écran caché pendant que le joueur visualise et réagit au premier, puis en scindant
les deux écrans au moment de la synchronisation verticale. Ainsi, le joueur ne voit jamais la construction
de l'écran, il n'y a pas de clignotement. Il reste toujours un peu de temps entre le moment où l'écran
est fini d'être construit, et le moment où l'on attend la synchronisation verticale. J'utilise ce temps
pour travailler sur un troisième écran immédiatement. Ainsi, quand l'écran nouveau s'affiche, j'en ai
déjà le quart d'un autre de prêt.
Bien sûr, tout cela prend pas mal de mémoire, trois écrans, c'est lourd en place, et les manipulations
sont plus nombreuses.
Fin du court passage technique spécial gros travaux
J'ai convié mes testeurs pilotes à venir au bureau, Richard Harvey et Robert Orchard, pour qu'ils me
disent ce qu'ils pensent de l'évolution d'Uridium 2. Ils connaissent bien le produit, Robert est même
l'inventeur du nom du jeu. Habituellement, ils me crachent une liste de 26 critiques en quelques secondes,
et Robert a même réussi à faire voler le Manta vers l'arrière deux fois de suite. Ce n'était pas arrivé
depuis des mois. Nous avons essayé de le refaire par la suite et cela nous a pris des jours.
J'ai changé quelques paramètres de vitesse et d'accélération, on verra s'ils réussiront à le refaire
la prochaine fois. Je n'avais pas l'intention d'installer des ombres pour tous les vaisseaux ennemis,
pourtant cela fait beaucoup de différence, le jeu est bien plus agréable. J'ai donc modifié mon programme
de gestion des sprites pour qu'il gère les ombres aussi, ce qui implique de transformer tous les
sprites colorés en noir et de les afficher en dessous et à droite de l'objet principal. Il
faut absolument que je pense à nettoyer les moniteurs avant que quelqu'un d'autre ne débarque dans
le bureau avec un appareil photo.
A suivre...
|
