Obligement - L'Amiga au maximum

Mercredi 20 octobre 2021 - 01:35  

Translate

En De Nl Nl
Es Pt It Nl


Rubriques

 · Actualité (récente)
 · Actualité (archive)
 · Comparatifs
 · Dossiers
 · Entrevues
 · Matériel (tests)
 · Matériel (bidouilles)
 · Points de vue
 · En pratique
 · Programmation
 · Reportages
 · Quizz
 · Tests de jeux
 · Tests de logiciels
 · Tests de compilations
 · Trucs et astuces
 · Articles divers

 · Articles in english


Twitter

Suivez-nous sur Twitter




Liste des jeux Amiga

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


Trucs et astuces

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


Glossaire

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


Galeries

 · Menu des galeries

 · BD d'Amiga Spécial
 · Caricatures Dudai
 · Caricatures Jet d'ail
 · Diagrammes de Jay Miner
 · Images insolites
 · Fin de jeux (de A à E)
 · Fin de Jeux (de F à O)
 · Fin de jeux (de P à Z)
 · Galerie de Mike Dafunk
 · Logos d'Obligement
 · Pubs pour matériels
 · Systèmes d'exploitation
 · Trombinoscope Alchimie 7
 · Vidéos


Téléchargement

 · Documents
 · Jeux
 · Logiciels
 · Magazines
 · Divers


Liens

 · Sites de téléchargements
 · Associations
 · Pages Personnelles
 · Matériel
 · Réparateurs
 · Revendeurs
 · Presse et médias
 · Programmation
 · Logiciels
 · Jeux
 · Scène démo
 · Divers


Partenaires

Annuaire Amiga

Amedia Computer

Relec


A Propos

A propos d'Obligement

A Propos


Contact

David Brunet

Courriel

 


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.

Uridium 2
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.

Uridium 2
É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 !

Uridium 2
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
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.

Uridium 2
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.

Uridium 2
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...


[Retour en haut] / [Retour aux articles]