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 (cinquième partie)
(Article écrit par Derek De La Fuente et extrait de Joystick - février 1993)
|
|
Novembre, deuxième semaine
Nous avons testé Uridium 2 sur un Amiga 4000 pour contrer d'éventuels problèmes de compatibilité.
Apparemment, tout fonctionne parfaitement bien, rien à signaler de ce côté-là.
Il semblerait que toutes nos cartes de décors de fond aient des erreurs. Ce n'est pas encore visible
pour Uridium 2, mais pour les produits consoles que nous préparons. J'ai donc retravaillé mon programme
de création de cartes, puis j'ai repris les anciennes cartes pour les refiltrer et les remettre dans
le programme. Il ne devrait plus y avoir d'erreur maintenant.
Un nouveau graphiste indépendant a rejoint notre équipe, Stephen Rushbrook, il est en train de
dessiner une nouvelle flotte de vaisseaux ennemis, une nouvelle gamme davantage dans le style de
la version originale sur C64. Nous avons planifié l'évolution des graphismes au cours du jeu ;
au départ, tout semble très métallique et devient plus organique au fur et à mesure que le joueur
avance. La première carte créée par Stephen était un peu trop chargée au niveau du sol et provoquait
des ralentissements quand tout explosait en même temps.
Je suis en train de réfléchir à une chorégraphie qui se mettrait en place pendant le chargement du jeu.
Cela dépend de la taille de la séquence d'introduction que nous allons incorporer dans le jeu, il
y a déjà beaucoup de fichier à charger avant que l'ordinateur puisse faire quoi que ce soit à l'écran.
C'est la première fois que j'écris un jeu destiné à des bécanes avec 1 Mo de mémoire, et la première
tâche à accomplir consiste à mettre le programme principal en mémoire Fast qui, selon les machines,
peut se trouver n'importe où. Le code doit donc être entièrement relogeable.
Ensuite, il faut charger l'énorme fichier des échantillons avant que le moindre son ne sorte de la bécane.
Pour faire patienter le joueur, Jason Page a créé un mini échantillon et une petite musique qui sera
jouée pendant les chargements multiples. Il nous a fallu pas mal de temps pour découvrir pourquoi aucun
son ne sortait du moniteur. Le fichier son n'était pas mauvais, mais une erreur dans mon programme faisait
jouer la musique à un niveau sonore égal à zéro. Mark Bentley a réfléchi sur l'emploi du plan différentiel
à trois couleurs, celui qui est lié au plan de sept couleurs mais qui se trouve en dessous pour créer
des ailes à son dernier vaisseau croiseur. J'ai programmé le tout pour que ce plan se trouve au-dessus
et plus en dessous. Un coup de baguette magique de programmation et le tour est joué, le programme
est encore plus flexible.
Novembre, troisième semaine
Graeme Boxall de Renegade nous a rendu visite cette semaine. Il n'a pas été impressionné outre mesure
par les graphismes en sept couleurs. Il y a un certain manque au niveau des couleurs, Mark Bentley
m'a annoncé qu'il se mettrait en grève si on ne lui donnait pas plus de couleurs avec lesquelles s'amuser.
Ainsi, la version en deux plans d'Uridium 2 perd de plus en plus d'intérêt. Malheureusement, je n'ai pas
gardé l'ancienne version en 32 couleurs, et il est très difficile de se souvenir de tous les changements
que j'ai rajoutés. J'ai donc chargé les sources des deux versions en même temps, puis je me suis amusé
à passer de l'un à l'autre page par page pour voir les différences. Les différences me sautaient alors
aux yeux, je n'avais plus qu'à déterminer si cela provenait d'une amélioration ou bien si c'était dû à la
différence des modes graphiques.
Tout ce processus m'a demandé environ trois heures. A ce stade, il y a environ 30 000 lignes de codes
à vérifier.
J'ai fait une ou deux petites erreurs, mais il n'était pas difficile de les détecter. La partie
la plus délicate à étudier est celle qui concerne la mini carte affichée à l'écran, celle-ci implique
des changements conséquents dans la liste du Copper ; si la moindre erreur se glisse là dedans, le
programme plante lamentablement sans que je puisse avoir accès à mon programme de debogage. Il n'y a
plus qu'à faire des allers et retours dans le source jusqu'à ce que l'erreur soit supprimée.
Ce changement de direction artistique implique que les deux graphistes doivent retravailler toutes
leurs planches pour les passer en 32 couleurs. Mark Bentley a décidé de créér une toute nouvelle
palette ; ainsi, les anciens graphismes 32 couleurs devront être convertis, eux aussi, pour être adaptés
à cette nouvelle palette.
Steve Turner, le patron de Graftgold, toujours en plein boulot
Est-ce qu'il se rend vraiment compte du boulot qui l'attend. Cette nouvelle palette est un véritable
fouillis en ce qui me concerne. Mark Bentley est tout à fait satisfait, la palette possède tout un
tas de marrons sombres et de verts. Ce qui signifie que je ne peux plus faire de graphismes moi-même,
il est temps de laisser la place aux experts. Je réussirai quand même à convertir mes polices de caractères
et mes graphismes de titre, ce qui me remplit de joie d'avance.
Nous avons acheté des PC 486, tous les graphismes sont réalisés sur ces bécanes, en mode 256 couleurs,
même si nous n'en utilisons que 32. Cela nous évite tous les problèmes de transferts, quand l'Amiga
déclare qu'il y a une erreur sur une disquette MS-DOS alors que le PC accepte de la lire sans problème.
Deluxe Paint 2 semble avoir quelques problèmes avec les configurations de nos PC. Nous avons dû explorer
un petit peu les mémoires de nos bécanes ; après tout, s'il y a 4 Mo dans une machine, le programme ne
devrait pas nous déclarer qu'il lui manque de la mémoire. Après avoir passé des heures à chercher et à se
gratter la tête, j'en suis arrivé à la conclusion que ceux qui écrivent les manuels des PC
ne devaient pas vraiment savoir de quoi ils parlaient.
Novembre, quatrième semaine
Les nouveaux graphismes convertis en 32 couleurs n'ont plus qu'une barrière de filtres à passer.
Il n'y a plus qu'à bosser sur les 46 étapes d'animation de la boucle du vaisseau Manta puis nous
pourrons intégrer la totalité des nouveaux graphismes. Nous avons inventé une nouvelle arme,
une torpille qui pourra détruire les éléments au sol. Les bombes peuvent détruire les installations
au sol aussi, mais pas les autres armes ; ainsi, nous limitons le nombre d'explosions simultanées,
nous évitons les ralentissements. Les torpilles permettront aussi d'accéder à certaines zones en
détruisant des murs qui bloquent le passage.
J'ai passé peu de temps sur Uridium 2 cette semaine, Chris Wood est venu au bureau, il s'occupe
de la conversion de Fire & Ice sur PC, et j'ai dû répondre à tout un tas de questions compliquées.
Ces discussions avec Chris Wood m'ont fait réfléchir à un moyen plus efficace de déplacer des sprites
en les faisant serpenter à travers l'écran. Nous avons abandonné cette direction quand nous nous sommes
aperçus que nous avions besoin d'hyperboles cotangentes. Le 68000 n'aime pas trop ce genre de calculs.
Il est possible de simuler cet effet en utilisant des instructions toutes simples. Chaque élément du
serpent de sprites est, en fait, en position intermédiaire, entre deux autres sprites. Cela fonctionne
mieux si chaque extrémité du serpent bouge en permanence. Il y a un effet de retard puisque les éléments
sont déplacés de façon séquentielle; ainsi, quand un sprite est déplacé, celui qui le précède est déjà
dans sa nouvelle position mais celui d'après est toujours dans l'ancienne. L'effet est beaucoup plus
vivant, et cette technique pourrait bien être utile pour Uridium 2. Je n'ai pas pu résister à la
tentation de tester cet effet sur Fire & Ice en l'intégrant dans monde 5, dans le temple Inca pour
voir si cela fonctionnait. Et ça fonctionne en effet.
Décembre, première semaine
J'ai réalisé une disquette de démonstration de la toute dernière version d'Uridium 2 pour l'emmener
à Londres et la montrer à des musiciens professionnels qui veulent faire des musiques pour les
jeux vidéos. Le rendez-vous a failli se terminer en catastrophe, Graeme Boxall avait oublié l'un des
éléments principaux, nécessaire pour la version Amiga. Heureusement, nous avons trouvé un moyen de
remplacement au dernier moment. Nous verrons si cette rencontre portera ses fruits, ce qui n'est pas
évident, nous avons tous des agendas très chargés.
Toute l'équipe derrière Uridium 2
Cette semaine, j'ai décidé de m'attaquer aux routines qui gère les blocs destructibles afin des les
améliorer. Actuellement, il y a un objet invisible placé sous chaque objet destructible, ce qui fait
qu'il y a tout un tas d'objets qui ne font rien la plupart du temps, qui attendent juste d'être heurtés,
ce qui prend pas mal de temps machine. Une méthode plus efficace consisterait à conti-nuer à les mettre
dans une liste, mais de laisser le boulot de recherche aux bombes. Quand elles explosent, elles s'occupent
de voir s'il y a des objets destructibles autour afin de les supprimer de la liste. Ainsi, le joueur qui
redémarre avec un nouveau vaisseau alors qu'il vient de se faire détruire, retrouve les impacts qu'il
avait provoqués auparavant. C'est l'une des améliorations que je veux absolument apporter à la nouvelle
version. Sur l'ancienne version C64 tous les objets étaient restitués quand le joueur redémarrait.
Je dois écrire une routine de recherche des objets destructibles. J'ai jeté un oeil sur un bouquin de
programmation du Z80 pour voir comment ils procèdent. Je préfère utiliser mes méthodes personnelles.
La programmation doit rester le plus structurée possible, ce qui permet de faire des modifications
ultérieurement.
Dix minutes après avoir terminé la programmation de ma routine de recherche et de destruction des
objets de la liste, j'ai pensé à un autre moyen de procéder, encore plus efficace. Puisque la
carte est réactualisée à chaque fois qu'un bloc est détruit, pourquoi ne pas sauver la carte toute
entière. J'aurai besoin d'une carte pour chaque joueur, mais ce n'est rien en comparaison du gain
de temps obtenu, je n'ai plus à dire au programme où se trouvent les bloquent destructibles, ils
sont directement marqués. La programmation devient de plus en plus compliquée, et les périodes de
test sont de plus en plus importantes.
|
