Présentation

Récemment, les histoires sur les jeux classiques ont reçu un bon accueil au GDC, mais il y avait très peu d'histoires sur les outils pour leur développement. Dans cette série d'articles, nous tenterons de combler cette lacune en interviewant des personnes qui ont joué un rôle important dans l'histoire des outils de développement de jeux.

Dans les deux premières parties de la série, nous avons parlé avec John Romero (à propos de TEd Editor) et Tim Sweeney (à propos de Unreal Editor) .

Lors de la rédaction du troisième article, j'ai eu l'honneur de parler avec Chris Norden des outils qu'il a développés pour l'hybride FPS / RPG appelé Deus Ex . J'ai discuté avec Chris à San Francisco au GDC 2018.

Avant la tempête ionique: origine et miroir

David Lightbone: Comment avez-vous commencé sur Deus Ex à Ion Storm?

Chris Norden: En 1994, j'ai travaillé comme programmeur Origin à Austin. Mon premier projet rémunéré était Jane's Combat Simulations AD-64D Longbow de Jane's Combat Simulations. C'était à l'origine un jeu d'arcade appelé Chopper Assault. Avec Andy Hollis, j'ai travaillé dessus pendant deux ans.



Après la sortie du jeu, la dernière chose que je voudrais faire est de faire un autre simulateur militaire, car je n'aime absolument pas tout ce qui est militaire. De temps en temps, j'ai parlé à Warren Spector, qui a également travaillé chez Origin. Il aimait beaucoup les jeux de rôle. Je me suis dit: "J'aime aussi ces jeux, je veux travailler sur quelque chose comme ça!"

En 1996, Warren a démissionné d'Origin et est devenu le chef des studios Looking Glass à Austin, dont personne ne connaissait l'existence à l'époque. Ce studio a créé des ports pour les jeux Mac, tels que le Links 386 Pro . Elle était également en train de développer son propre jeu de golf appelé British Open Championship Golf.

Origin développait toujours Ultima Online. Elle était surnommée Multima, et il semble avoir utilisé le moteur Ultima VII. J'ai fait quelques expériences avec lui jusqu'à ce que je quitte Origin et que je rejoigne Warren dans Looking Glass.

[Note de l'auteur: le studio principal de Looking Glass était à Cambridge, Massachusetts, près de Boston]

Warren a écrit un document de conception et pendant un certain temps, nous avons travaillé sur un jeu de rôle avec l'abréviation AIR (d'Austin Internet Role-Playing), qui était censé être un projet en ligne. Nous voulions faire quelque chose en 3D, car alors que les accélérateurs 3D commençaient tout juste à apparaître. Nous avons obtenu un prototype de Voodoo 1 et écrit un petit moteur sur GLide.

Nous avons établi un partenariat avec le bureau de Cambridge de Looking Glass. Après avoir sorti le British Open, j'ai aidé Mark LeBlanc et Doug Church avec un moteur Thief appelé Dark Engine .

Pour des raisons financières et autres, Looking Glass ne se sentait pas très bien à l'époque. La société avait des jeux incroyables, mais ils se sont mal vendus. Par conséquent, après environ un an, il a été décidé de fermer le bureau d'Austin.

[Note de l'auteur: Chris a tout à fait raison sur les jeux - Ultima Underworld, System Shock et Terra Nova ont été très bien accueillis par les critiques, ils étaient parmi les meilleurs jeux des années 1990]

Au moment de la fermeture du bureau, nous étions peu nombreux: Warren, moi, Al Yarusso, Harvey Smith, Steve Powers. Nous voulions tous toujours travailler sur ce jeu de rôle. Après la fermeture du bureau, nous nous sommes entretenus pendant environ six mois, en espérant que nous pourrions créer une nouvelle entreprise et faire quelque chose. Nous avions un très bon document de conception, nous avons commencé à le «vendre» aux éditeurs et à communiquer avec différentes personnes. Je ne me souviens même pas de tous les éditeurs que nous avons contactés. L'une de ces personnes était John Romero et Tom Hall, qui, avec Eidos, ont travaillé pour créer un nouveau studio à Dallas appelé Ion Storm.


Je connaissais John depuis les premières années d'Id. En 1991, à Dallas, MTV a organisé une énorme fête de navire dédiée à Wolfenstein 3D. Il y avait deux machines VR Virtuality Arcade Machine . À cette époque, j'étais enfant et je me suis dit: "Dieu, c'est la chose la plus cool du monde!" J'ai rencontré John à l'époque où il vivait dans le style "Je suis trop riche pour m'inquiéter de quoi que ce soit".

John est une personne merveilleuse, j'ai travaillé avec lui à Monkeystone Games, j'ai aidé à développer le jeu pour Gameboy Advance, mais c'est une autre histoire.

[Note de l'auteur: le jeu s'appelait Hyperspace Delivery Boy. Pour Gameboy Advance, il était censé être publié par Majesco , mais au dernier moment, la société a refusé de le publier.]

Nous avons parlé avec Romero et Tom Hall, et ils sont: "Warren, tu es cool, faisons ce jeu!". Et Warren a répondu: «Il y a un hic. Nous ne déménagerons pas à Dallas. Nous ne déménagerons pas en Californie. Nous ne bougerons nulle part. Nous garderons le studio à Austin. Nous resterons donc complètement autonomes. Vous me donnerez un contrôle complet sur tout. Vous me donnerez de l'argent et tout ira bien. » Ils ont répondu: «D'accord, cela nous convient. Résolu. "

[Note de l'auteur: il s'agit évidemment d'une version trop simplifiée des négociations, mais elle donne une idée de ce qui s'est passé]

Warren avait à l'époque un excellent document de conception pour le jeu de dépannage, qui s'est progressivement transformé en document de conception Deus Ex.

Nous avons donc fondé Ion Storm Austin à six. À cette époque, j'étais le directeur technique, le chef du service informatique, «Homo Arom», le service de sécurité et l'ingénieur principal. Nous n'avions pas assez de gens pour faire toutes ces choses. Il était donc nécessaire de mener rapidement des entretiens et de recruter du personnel.

L'équipe était minuscule. Nous avions trois ingénieurs: moi-même, Scott Martin et Al Yarusso. Sheldon Pacotti a été embauché comme scénariste. Nous avions deux équipes de conception de trois personnes chacune. L'un était dirigé par Robert White, le second par Harvey. Il semblait y avoir six autres artistes dirigés par Jay Lee.

Oh, et j'ai également engagé Alex Brandon parce que j'étais un grand fan de sa musique pour Unreal. Maintenant, nous sommes de grands amis. Je l'ai présenté à sa future épouse, car nous étions amis au lycée. C'est un gars formidable: un excellent musicien et connaissant bien les détails techniques.

Ensuite, nous avons embauché un administrateur, et c'est tout. Et puis nous avons été confrontés à un travail infernal pendant deux ans et demi! [rires]

Choisir entre les moteurs Unreal et Quake

JL: Donc, alors que le reste de Ion Storm fonctionnait avec le moteur Quake, vous avez choisi Unreal. Pouvez-vous expliquer comment vous avez pris cette décision?

KN: Peu importe à quel point je respecte le moteur Quake, je savais qu'à ce moment-là, nous n'aurions aucun soutien. Nous avons créé un jeu très spécifique dans lequel nous voulions pouvoir tout faire. Quake était un tireur, et rien de plus. Si nous avions essayé de faire autre chose que FPS, cela aurait demandé beaucoup de travail et nous n'aurions pas reçu le soutien d'Id. Ils ont simplement gravé un CD avec le code, l'ont donné aux développeurs et les ont laissés seuls.

JL: Dans mon interview avec Tim Sweeney, il a appelé le modèle de licence de moteur Quake de l'époque «une opération xcopy d'un quart de million de dollars».

KN: Oui, tout à fait raison! Je suis d'accord, le moteur était incroyable. À cette époque, il a fait une révolution, mais nous savions qu'une équipe de trois ingénieurs ne serait pas en mesure de réécrire le moteur et ne pourrait pas écrire le vôtre. Nous n'aurions tout simplement pas assez de temps.

À un moment donné, j'étais un grand fan de la scène de démonstration d'Amiga, C64 et PC. J'ai commencé à regarder un jeu vidéo appelé Unreal et j'ai pensé: «Oh mon dieu, oui, il y a un éclairage RVB et une 3D complète. Le moteur utilise MMX, SSE et 3DNow. Il a l'air très cool! " Mais nous n'avons pas pu trouver d'informations détaillées sur lui, nous avons donc prévu un voyage à Digital Extremes à Londres (Canada). Nous avons rencontré Tim et son équipe, ils nous ont montré toutes les fonctionnalités du moteur. J'ai également rencontré Carlo Vogelsang , avec qui je travaille maintenant avec Sony - il est dans le département Playstation. Il a écrit le Galaxy Audio Engine: presque tout dans l'assembleur, un gars super-hardcore. Le moteur avait un système de particules appelé Fire. Tout cela était à l'intérieur du moteur. J'ai pensé: "Les gars, j'aime votre approche."


À cette époque, ils se sont concentrés sur la création d'outils super pratiques que personne n'avait fait auparavant. Les outils Quake étaient bons, mais pour les utilisateurs non techniques, ils ne semblaient pas très conviviaux. Nous avions des concepteurs qui n'avaient pas de compétences en ingénierie, et ils devaient trouver comment utiliser ces programmes.

Nous avons donc décidé: «Ces gars-là ont de bons outils, tout le monde nous aide beaucoup, il y a beaucoup de gars de la vieille école qui ont écrit des trucs hardcore dans les années 80. Comment les licences sont-elles organisées? " Ils ont répondu: "Nous n'avons jamais fait cela auparavant, pour nous, c'est quelque chose de nouveau." Je pense qu'à cette époque, ils ne comprenaient pas comment créer un modèle de licence. Nous avons dit: "Nous avons Warren Spector, et il veut créer un jeu sur votre moteur." Quand ils ont entendu cela, il est devenu clair qu'ils voulaient vraiment travailler avec nous.

Honnêtement, je ne me souviens pas des détails de notre contrat de licence. Tim se souvient probablement. Je ne me souviens pas combien nous avons payé, mais je ne pense pas tellement. "

JL: Probablement comparable au nombre d'ID qui demandaient Quake à ce moment-là?

KN: Je pense moins! Et c'était un autre avantage. Leur moteur était relativement nouveau, mais nous n'étions pas les premiers licenciés. L'un des premiers était Wheel of Time et Klingon Honour Guard.

[Note de l'auteur: vous pouvez en savoir plus sur l'historique des licences Unreal Engine dans mon interview avec Tim Sweeney à propos d'Unreal Editor ]

Par conséquent, nous avons décidé de le choisir. Les développeurs nous ont donné le code source et ont dit: "Nous vous soutiendrons dès que possible." Nous avons toujours parlé face à face. Si nous avions une question, nous envoyions un email: il n'y avait pas de système de support technique.

Nous avons eu beaucoup de problèmes car ils n'avaient jamais fait cela auparavant. Nous leur avons envoyé beaucoup de code et de questions, eu une longue correspondance et reçu des mises à jour. Mais je pense que c'était la bonne décision. Je pense que si nous choisissions Quake, le jeu serait beaucoup plus difficile à créer.

De plus, je suis devenu membre du groupe consultatif Unreal Tech. Nous avons eu l'idée de la première réunion technique, au cours de laquelle les dirigeants de toutes les entreprises qui sont devenues titulaires de licence (il y en avait quatre à l'époque) se sont réunis, ont discuté des moyens d'améliorer le moteur, réprimandé Tim pour les aspects gênants, triés avec de l'alcool et de la nourriture, eh bien, tout est comme habituellement. Je reste en contact avec toutes ces personnes.

JL: Avez-vous partagé quelque chose avec d'autres membres du groupe consultatif Unreal Tech?

KN: Je pense que nous avons principalement partagé les améliorations de l'éditeur Unreal. Le moteur était excellent, mais il avait encore un long chemin à parcourir. Puis, lorsque nous avons pu embaucher encore plus de designers et d'artistes, ils ont également commencé à faire des suggestions pour améliorer les processus de travail. Nous les avons implémentés nous-mêmes, ou les avons envoyés à l'équipe Unreal, ou avons demandé à l'équipe Unreal s'ils pouvaient le faire plus rapidement que nous.

Nous avons apporté de nombreuses modifications à l'éditeur principal, mais la plupart d'entre elles ne concernaient que notre jeu. Nous avons partagé certaines des améliorations, mais la plupart des autres développeurs ont été impliqués dans des jeux complètement différents.

J'ai dû écrire un tas de systèmes qui, je pense, étaient les premiers du genre. Au moins, je ne les ai jamais vus. Par exemple, un système de mixage d'animation; c'est essentiellement ce que l'on appelle aujourd'hui les cibles de morphing ou les formes de mélange. Je ne me souviens pas que quelqu'un ait fait ça dans les jeux à ce moment-là. Il a peut-être déjà été mis en œuvre quelque part, mais avant l'utilisation généralisée d'Internet, le partage d'informations était très difficile.

JL: Pouvez-vous parler des modifications que vous avez apportées à l'éditeur Unreal?

KN: L'un des systèmes, qui pour une raison quelconque n'était pas dans l'éditeur à l'époque, est la visualisation des cannelures de caméra.

Dans les premières versions d'UnrealEd, vous deviez faire glisser la caméra et définir les points de son chemin. Dans ce cas, on pouvait voir les points, mais pas les connexions entre eux, qui déterminaient le chemin de la caméra.


JL: C'est comme un jeu point à point, mais sans chiffres!

KN: Exactement! La spline avait des points d'arrêt et les concepteurs ne pouvaient pas toujours comprendre à quoi ressemblerait le chemin. Ils voulaient savoir très précisément comment la caméra se déplacerait en cours de route. J'ai donc ajouté ce système, et ils l'ont aimé.

C'était très simple. Je veux dire la simplicité du code: dessinez les axes de coordonnées à chaque point de contrôle principal, puis dessinez le point de contrôle pour voir réellement où il est allé. Cela a vraiment aidé le concepteur et créer un tel système était très simple. Je ne sais pas pourquoi nous avons dû l'ajouter. Je suppose que Tim ne pensait pas qu'elle serait vraiment nécessaire.

DL: C'est drôle parce que si vous vous souvenez de la première démo du jeu Unreal au public, la première chose que les gens ont vue était une caméra volant autour du château, c'est-à-dire qu'il était peu probable qu'Epic ait créé des chemins de caméra.


KN: Je pense que la raison en était que bon nombre de leurs concepteurs de niveau étaient des super-techniciens et ils étaient habitués à simuler de telles choses dans leur tête. Mais l'industrie du jeu vidéo a progressivement évolué, il était donc nécessaire de créer des outils pour des personnes ayant différents niveaux d'expérience. Tous les concepteurs n'étaient pas ingénieurs, et encore plus aujourd'hui! C'était l'exception plutôt que la règle. Par conséquent, l'outil aurait dû devenir pratique et simple.

Au fait, je ne sais toujours pas pourquoi Pion est désigné par la tête d'un dinosaure.

JL: [rires] Oui, Tim et moi en avons discuté dans une interview! Au fait, avez-vous regretté les décisions technologiques que vous avez prises?

KN: Nous avons trop utilisé UnrealScript. C'était une des erreurs. UnrealScript était très flexible, mais trop lent. Nous avions besoin d'écrire beaucoup plus en C natif qu'en UnrealScript.

True North et faux pépins

[Note de l'auteur: à ce stade de l'interview, j'ai ouvert Deus Ex Editor (version pour UnrealEd), ainsi que la documentation Deus Ex SDK]

JL: Le programme d'installation du SDK Deus Ex possède un dossier Docs contenant quelques fichiers de documentation que vous, Robert White, Sheldon Pacotti, Al Yarusso et Scott Martin semble sponsoriser. Pouvez-vous dire qui étaient ces gens et sur quoi ils ont travaillé?

KN: Al était impliqué dans l'éditeur de dialogue. Scott a travaillé sur l'IA. J'ai fait ... tout . [rires] Entre autres choses, j'étais directeur adjoint et programmeur principal. Mais nous avons fait un peu de tout, car dans l'ensemble du projet, du début à la fin, il n'y avait que trois ingénieurs.


Chris Norden (en bas à gauche), El Yarusso (à droite et en haut de Chris, avec une horloge à la main), Robert White (dans la rangée du milieu, légèrement à droite du centre, portant des lunettes de soleil), Sheldon Pacotti (en bas à droite) et Scott Martin (dans le deuxième rangée, à droite, également dans les lunettes de soleil)

DL: Il y a une section dans la documentation pour l'éditeur qui dit "Unreal n'a pas de support natif pour les escaliers verticaux, mais ils sont ajoutés à Deus Ex." Pouvez-vous nous en dire plus à ce sujet?

KN: Les escaliers sont une histoire intéressante, car nous devions nous déplacer dans le niveau, et dans les jeux de tir à la première personne de cette époque, les escaliers inclinés et les ascensions douces étaient traditionnellement utilisés pour cela.

L'un des décrets de Warren (parce que le design est la loi!) A déclaré qu'un joueur devrait être en mesure de terminer n'importe quelle mission de quelque manière que ce soit. L'idée clé du jeu était que si vous le souhaitez, vous pouvez le parcourir en entier, sans jamais tirer. En fait, nous n’avons pas tout à fait réussi - il y a plusieurs zones où vous devez tirer plusieurs fois, mais nous étions très proches.

DL: Je pense que les développeurs ont réussi les suites.

KN: Oui, probablement.

Ainsi, le joueur aurait dû être en mesure de passer tout le match sans tirer. De plus, il pouvait parcourir tout le match sans rien faire d' autre que tirer. Le joueur pouvait parcourir l'intégralité du jeu afin qu'il ne soit jamais détecté par l'ennemi. Il était possible de le parcourir de manières complètement différentes.

JL: Le manque d'escaliers verticaux était-il l'un des sujets dont vous avez discuté avec Tim lors des réunions du groupe consultatif Unreal Tech?

KN: Pour répondre, je dois trouver et regarder dans le code du script s'il dit "Va te faire foutre, Tim!" [rires], parce que c'est exactement ce que nous faisions quand nous étions en colère - nous avons écrit des commentaires afin de nous en souvenir plus tard.

Lorsque nous avons commencé à réfléchir à la façon d'ajouter le support pour les échelles verticales, nous avons d'abord pensé «créons la géométrie, puis nous pourrons peut-être faire des tours physiques délicats afin que le joueur puisse saisir les barres avec une animation synchronisée». Mais après que nous ayons décidé - eh bien, c'est tout l'enfer, trop compliqué.

JL: [rires]

KN: Nous avons dû le faire très rapidement, car les concepteurs ont exigé de créer cette mécanique.

Par conséquent, en conséquence, j'ai dû aller dans des bidouilles infernales. Le moteur avait le concept de «groupes de textures». Il s'agit essentiellement d'une étiquette de chaîne attribuée à certains types de textures pour les rendre plus faciles à trier. Nous pourrions les demander en code. Nous avons donc pensé: "pourquoi les artistes ne font-ils pas simplement des textures pour pouvoir les grimper?" Après cela, nous les avons simplement ajoutés au groupe de textures, effectué une diffusion de rayons pour les reconnaître, puis simplement avec certaines restrictions, nous avons collé le joueur dans la direction de son mouvement. Cela fonctionnait bien, mais pas toujours parfait, car lorsque le joueur montait au sommet de la texture, le faisceau n'y émettait plus, et nous devions pousser le joueur vers le haut et sur la plate-forme. Autrement dit, la solution est imparfaite, mais en conséquence, cela a fonctionné. C'était un hack bon marché et facile.

Les lecteurs d'aujourd'hui pourraient penser: pourquoi n'y avait-il pas d'escalier dans le moteur, est-ce même logique? Mais à cette époque, il n'y avait rien. Ce n'étaient que des fragments BSP, nous n'avions pas de maillages statiques, il n'y avait rien de tel.


JL: UnrealEd avait un générateur d'escalier en colimaçon très cool [rires], mais il n'y avait pas d'escalier vertical.

KN: Oui, c'est vrai ... Il semble que nous ayons grondé les concepteurs pour l'utiliser, car cela créait des trous dans BSP. L'escalier avait l'air magnifique s'il n'y avait rien à proximité. Mais dès que vous commencez à faire des tranches angulaires dans le BSP, vous pouvez obtenir de petits trous dans le BSP à travers lesquels vous pouvez passer, mais les trous eux-mêmes ne sont pas visibles. Cette fonction a causé beaucoup de douleur et nous avons interdit son utilisation. Elle avait l'air bien, mais était cassée ...

DL: La documentation décrit également une classe appelée DeusExLevelInfo qui contient des informations sur la carte (par exemple, est-elle multi-utilisateur), le nom de l'auteur de la carte, le lieu où la mission a été terminée, le numéro de mission, etc. Mais je voudrais vous poser des questions sur TrueNorth.

KN: [rire] C'était un type BAM d'Unreal: moteur de mesure d'angle binaire!

JL: Quels sont ces chiffres fous?!

KN: À l'époque, les opérations en virgule flottante étaient très coûteuses. Le fer était faible, mais pas assez de mémoire. 360 degrés n'étaient pas décrits par un nombre à 8 bits, ce qui fournirait 255 unités de précision, soit environ 1,4 degré par unité, ce qui ne serait pas suffisant. Tim a utilisé un nombre de 16 bits pour les orientations, ce qui a fourni une plus grande précision.

Pour un programmeur, tous ces chiffres sont assez simples. Ce ne sont que des pouvoirs de deux, pas de problèmes, vous pouvez les calculer tous dans votre tête. Mais les designers et les artistes avaient des problèmes. Par conséquent, nous avons proposé de petites simplifications pour aider les développeurs à s'en souvenir.

[Pendant que nous travaillions avec l'éditeur, Chris est allé à la classe Décorations]



KN: Les décorations étaient aussi un énorme cours. Toutes les mailles avec lesquelles vous pouvez interagir sont de la décoration. Autrement dit, presque tout dans le jeu!

JL: Dans la section Décorations de la documentation, il est écrit: "Nous vous avertissons que si vous modifiez certains des champs non répertoriés ci-dessous, l'éditeur peut se bloquer." Je ne me souviens pas pourquoi cela s'est produit?

KN: [rires] Honnêtement, je ne me souviens pas. Je pense que parce que la décoration était une classe si grande et qu'il y avait tellement de fonctions épiques qui interagissaient avec le moteur d'une manière étrange, qu'au lieu d'expliquer à un concepteur qui ne comprend pas les subtilités techniques pourquoi un certain domaine peut conduire à un comportement inattendu, nous ils ont dit "ne l'utilisez pas, sinon l'éditeur plante".

JL: [rires]

KN: Quelque chose comme des tactiques effrayantes. Lors des réunions de programmeurs, nous nous sommes demandé: comment expliquer aux utilisateurs que cela entraînerait des dommages à la chaîne BSP, et que vous deviez faire ceci et cela? Disons-leur simplement que l'éditeur va planter.

Je devrais étudier à nouveau le code, mais il semble que nous soyons même coupables de cacher des échecs délibérés à certains endroits afin d'effrayer les utilisateurs qui sont trop arnaqués.

JL: Continuons. La section ParticleGenerator dit: «L'une des principales fonctions est qu'il peut être activé et désactivé à l'aide de déclencheurs et de déclencheurs.» Autrement dit, dans la version du moteur Unreal avec laquelle vous avez travaillé, il était impossible d'activer et de désactiver les particules?

KN: A cette époque, non. Si vous avez inséré un système de particules, il était présent en permanence et ne s'est jamais éteint. Il me semble que c'est un oubli étrange.

Sinon, le système de particules Unreal était génial. La plupart ont été écrits en assembleur. C'était procédural et très bien écrit par rapport à tout le reste. Les designers l'ont adorée. En fait, même trop. Il était possible de tuer toute la fréquence d'images, et ils sont devenus fous, ajoutant de plus en plus de couches transparentes.

À cette époque, nous devions encore prendre en charge le rendu logiciel, alors que le rendu matériel n'était pas encore répandu. Tim avait des compétences de programmation incroyables et a écrit un excellent logiciel de rendu, il était super.

[En regardant différents objets dans le jeu, j'ai remarqué une catégorie avec un nom inhabituel dans le panneau Propriétés]

DL: Qu'est-ce que cette propriété Odeur?

KN: Les animaux avaient besoin d'un parfum pour prendre une trace. En fait, les chiens peuvent suivre les nœuds d'odeur. Si je me souviens bien, alors en parcourant les niveaux, le joueur pouvait laisser des nœuds d'odeur qui étaient actifs depuis un certain temps. Par conséquent, nous l'avons fait pour que les chiens puissent le sentir.

DL: Autrement dit, si vous vous cachez derrière une boîte, les gens ne vous trouveront pas, mais les chiens peuvent ...

KN: Précisément parce que c'est ce qui se passe en réalité, et nous pensions que ce serait un aspect de gameplay intéressant. Cependant, il semble qu'il ait finalement été éliminé. Puisqu'il n'y avait pas de rétroaction graphique, ce concept était difficile à expliquer au joueur.



[ Intro, — , . ]

: . . ...



KN: Non, les miroirs étaient réels! Ils étaient très lents, nous avons donc demandé aux concepteurs de les utiliser rarement, cependant, ce sont de vrais miroirs.

En fait, quand j'ai écrit le code laser ... [rires]

DL: [rires] Je vois où tu veux en venir ...

KN: ... J'ai dû vérifier les miroirs. J'ai eu un niveau de test où j'ai testé le code pour tous les appareils. Lorsque j'ai écrit le code du pointeur laser, j'ai créé une boule disco à miroir réfléchissant, puis j'ai construit une pièce avec des miroirs aux deux extrémités. J'ai pris le pointeur laser, je l'ai pointé sur la boule disco, et ça a marché!

Bien sûr, la fréquence d'images est tombée en dessous de nulle part, car j'ai dû tracer toutes les lignes ...

Voir l'outil Light Wave: LWO23D Command Line

[Note de l'auteur: LWO signifie Lightwave Object. Il s'agit du format de géométrie 3D du progiciel Lightwave 3D de Newtek , également basé au Texas, comme l'équipe Deus Ex à l'époque]



Capture d'écran de Tack's Deus Ex Lab

JL: Pourquoi votre équipe a-t-elle décidé d'utiliser Lightwave?

KN: Nos artistes le connaissaient bien. Nous avons donc dû nous adapter.

JL: Expliquez-nous pourquoi vous avez écrit l'exportateur en tant qu'outil de ligne de commande.

KN: À cette époque, et même maintenant, j'écris souvent de petits outils de ligne de commande pour automatiser les tâches. Je suis programmeur à l'ancienne et je n'aime pas les complications inutiles. Je n'aime pas du tout C ++. Je n'aime pas les motifs. Je n'aime pas tout ce qui prend du temps.

Lorsque j'écris des outils en ligne de commande, je crée un fichier de commandes Win32, je me débarrasse de tout ce qui est intégré, je commence par un fichier vide, avec int main() , et je continue simplement. Il s'agit d'une solution rapide et portable qui ne pose aucun problème.

DL: Je pense que l'exportation de maillages statiques était un processus assez standard. Mais dites-nous comment vous avez exporté l'animation.



Capture d'écran de Tack's Deus Ex Lab

KN: Il n'y avait pas d'animation squelettique dans le jeu. Je ne connais pas un seul moteur de l'époque où il est implémenté. Par conséquent, tout a été fait en mélangeant des sommets. Le dépouillement était très cher à l'époque. Pas de GPU, tout devait être calculé sur le CPU et évité de toute façon les calculs en virgule flottante.

À l'intérieur de Lightwave, les concepteurs ont créé une animation squelettique, puis ont affiché ses images clés. Il fallait créer une pose en T, car pour mélanger des animations il fallait partir d'une base commune. Autrement dit, pour le bon mélange, les animations étaient essentiellement des décalages par rapport à la pose en T. Le mélange a été effectué côté moteur.

JL: Donc, dans Unreal, tout a fait la même chose?

KN: Probablement oui. Je ne pense pas que Tim ait ajouté une animation squelettique à la prochaine version.

Têtes parlantes: ConvEdit et Lipsink

[Maintenant, nous ouvrons le dossier ConvEdit]


JL: Parlez-nous de ConvEdit

KN: C'était une idée originale d'Al, il l'a écrite en Visual Basic.

JL: Comme UnrealEd à cette époque.

Oui, à cette époque, il n'y avait pas beaucoup d'opportunités pour une implémentation simple de l'interface. Il y avait Delphi et plusieurs autres cadres d'interface utilisateur. Si vous ne les utilisiez pas, vous deviez tout écrire en natif, par exemple, sur l'API Win32, GDI et tout ça. C'était un énorme problème.

C'est-à-dire que Visual Basic, qui semble aujourd'hui plutôt primitif, était à l'époque très bon - un cadre visuel simple avec son propre langage de programmation similaire à Basic, le prédécesseur de C #. Il nous a permis de créer des prototypes de fonctions et d'écrire des outils très rapidement.

[Remarque: Si vous êtes intéressé par la façon dont Visual Basic a été utilisé dans les outils de développement de jeux de cette époque, lisez mon interview avec Tim Sweeney à propos de Unreal Editor ]

Il était principalement utilisé par Sheldon. Il avait besoin d'outils pour contrôler la caméra, d'outils pour contrôler les sons. Il voulait utiliser de nombreux outils cinématographiques que personne n'avait utilisés auparavant. J'ai d'abord appris ce qu'est le zoom à la tribune, en travaillant sur ce jeu avec Sheldon.

Je pense qu'aujourd'hui encore cet outil est encore utilisé.

Soit dit en passant, Sheldon souffrait du syndrome du poignet tunnel (RSI, traumatismes répétés), alors le phoque est devenu une torture pour lui. Il a presque complètement travaillé sur Deus Ex en utilisant la transcription vocale dans Dragon Dictate, ce qui à l'époque était bien pire qu'aujourd'hui. Sheldon a même dû porter des orthèses, car le syndrome était très fort.




JL: Wow! Je ne savais pas. Le jeu avait de nombreux dialogues et un tas de branches ...

KN: Une énorme quantité de données, même pour une mission.

Sheldon voulait avoir un contrôle fort sur le jeu et de nombreux dialogues interactifs. Il voulait que le joueur fasse un choix significatif. Lui et Warren détestaient devoir cliquer sur les dialogues sans choix. Ils voulaient que le joueur interagisse avec les personnages et choisisse des choses importantes, afin que le jeu pose des drapeaux et se souvienne de la façon dont il interagissait avec les personnages et se comportait pendant le passage.

JL: Dès la première visite virtuelle de Deus Ex, je me souviens du briefing d'Anna Navarre à son bureau. Comme d'habitude dans n'importe quel jeu vidéo, j'ai commencé à courir dans le bureau en faisant toutes sortes de bêtises jusqu'à ce que les PNJ terminent leur dialogue. Soudain, elle a arrêté son dialogue, s'est tournée vers moi et m'a demandé: "Qu'est-ce que tu fous?"

KN: [rires]

DL: Pendant une seconde, je me suis figé et je me suis demandé: "Est-ce vraiment ce qui s'est passé?" Ce fut un événement si important pour moi en termes d'immersion dans le jeu. Pas un seul match avant que celui-ci ne se soit jamais rencontré. Je soupçonne que cela est en partie dû à l'éditeur de conversation.

KN: Un des commandements de Warren était: "Si un joueur est dans le bureau de quelqu'un, se comporte comme des animaux et casse des choses, alors le personnage doit dire quelque chose!" Il ne doit pas ignorer le joueur, car c'est irréaliste. "

JL: Y avait-il des aspects liés à la cinématique pour lesquels il s'est avéré particulièrement difficile de créer des outils?

KN: Nous avons eu beaucoup de dialogues, et ils ont tous été exprimés. Nous avons passé des semaines dans un studio d'enregistrement pour enregistrer des dialogues avec des acteurs. Cela signifiait que nous devions penser à synchroniser le mouvement des lèvres (lèvresyne). Je me suis dit: "Comment créer un lipSink pour autant de dialogues?" Après tout, nous avions non seulement un tas de phrases, mais aussi plusieurs langues.

A cette époque, il n'y avait pas beaucoup d'outils pour aider au plâtrage. La plupart des développeurs ont effectué un prétraitement: ils ont exécuté la boîte de dialogue dans l'outil, affiché un fichier de données, puis l'ont lu. Mais j'ai décidé: "Nous n'aurons pas le temps pour ça, et si vous devez réenregistrer la voix, alors vous devrez tout refaire."

J'ai donc commencé à penser qu'il devait y avoir un moyen de le faire en temps réel en utilisant l'analyse sonore dynamique. Au collège, j'ai étudié le génie électrique et j'ai décidé de le découvrir moi-même, sans en parler à personne.

JL: [rires]

KN: J'ai pensé: "Voyons si je peux faire ça et surprendre tout le monde." Encore une fois, je ne pense pas que quiconque ait fait quelque chose comme ça auparavant, mais aujourd'hui, cette technique est partout.

A cette époque, de tout ce que j'ai vu, le plus proche d'un tel système était Half-Life. Les développeurs ont utilisé la technique de suivi d'enveloppe, qui était littéralement la suivante: ouvrez et fermez la bouche en fonction du volume du son. Le système fonctionnait, mais il ne semblait pas très réaliste.

JL: En fait, c'était un «coup de mâchoire».

KN: Oui, exactement, exactement.

Je me souviens avoir déjà discuté avec Gabe Newell de la façon dont ils ont accompli cette tâche, et il a dit: "Oh, utilisez simplement l' enveloppe suivante , et c'est assez. Tout le reste sera trop compliqué. »

Puis je suis rentré chez moi et j'ai commencé à estimer les calculs mathématiques, puis j'ai écrit un système qui effectuait la FFT ( transformée de Fourier rapide ). Je le répète, alors que les calculs en virgule flottante étaient très chers, et j'ai probablement écrit une approximation entière les simulant.

Elle a analysé en temps réel un court enregistrement audio et extrait les principales composantes de fréquence, puis les a liées à six à sept phonèmes différents.

En secret, j'ai demandé à l'un des artistes de simuler plusieurs formes de mélange (formes de mélange): j'avais besoin de "oh", "a", des lèvres fermées et autres. Il a demandé pourquoi, et j'ai répondu qu'il a simplement fait cela et m'a donné les données.



Transformée de Fourier rapide (image Wikipedia) et série de phonèmes Preston Blair

JL: [rires] Cela semble être le match parfait pour le mélange d'animations que vous avez utilisé dans Deus Ex.

KN: Oui, exactement, parfait.

Alors, il m'a donné les données, j'ai écrit des calculs mathématiques et comme je pouvais, manuellement, j'ai joint les formulaires. Je n'ai fait aucune recherche sérieuse et le système était assez cher en termes de performances.

J'ai créé un niveau de test avec une énorme tête au milieu et je lui ai donné quelques lignes. J'ai vérifié la phrase en allemand, en anglais, en français et tout s'est parfaitement synchronisé. J'ai pensé: «Bon sang, c'est incroyable! Cela a vraiment fonctionné! "

J'ai trouvé Warren et lui ai dit: "Je veux te montrer quelque chose de cool." On dirait qu'il était stupéfait. [Rires] Il m'a demandé: «Mais qu'est-ce qui se passe, pouvons-nous mettre cela dans le jeu? C'est juste génial! "

En conséquence, nous avons sorti un jeu avec ce système, mais pour des raisons de performance, j'ai dû le réduire beaucoup, à cause de quoi la qualité visuelle a diminué. Mais mon premier niveau de test était super. Je crois toujours que c'était le tout premier système de synchronisation labiale en temps réel. Je ne me souviens pas que quelqu'un ait fait ça avant.

Peut-être valait-il la peine de le breveter. Mais je ne crois pas aux brevets logiciels parce que je pense que c'est une pratique vicieuse ...

J'ai également eu une grosse dispute avec l'un des directeurs artistiques de Dallas, qui voulait utiliser ce système dans Anacronox. Elle aurait dû sortir avant notre match. J'ai dit: "Cela ne me dérange pas de partager, mais je veux que Deus Ex soit le premier jeu dans lequel il apparaît." Il a dit: "Non, tu dois nous le donner!" Il nous a pratiquement crié dessus dans le hall. J'ai répondu: «Non, je ne devrais pas» et Warren m'a soutenu. Il se trouve que nous avons d'abord sorti le jeu, donc ce n'était pas important de toute façon. En fait, je pense qu'en conséquence, ils ont mis en œuvre indépendamment leur propre version du système, parce que nous ne voulions pas le donner. C'était peut-être égoïste, mais je voulais que nous obtenions notre diplôme en premier afin de pouvoir démontrer cette fonctionnalité.

Tout le reste produit par Ion Storm a été développé à Dallas: Dominion: Storm Over Gift 3 , Daikatana , Anacronox - tout a été fait à Dallas. Seul Deus Ex a été créé à Austin, et il n'y avait que notre équipe, personne d'autre. Nous étions dans une bulle, assez isolée du bureau de Dallas, et cela a été fait exprès. Nous ne voulions pas jouer avec un tas ... Je vais être honnête, avec un tas de toutes leurs ordures. Cette séparation était complètement intentionnelle et très importante pour nous. Notre équipe et leurs équipes n'ont pas échangé de technologies, pas de vrais contacts.

Conclusion

DL: Donc, pour résumer, je veux demander: si vous pouviez donner des conseils aux développeurs d'outils en lisant cet article, que diriez-vous?

KN: Écoutez votre client. N'écrivez jamais d'outils dans le vide. En tant qu'ingénieur, vous pouvez penser: "Je peux utiliser cet outil de cette façon, et cette méthode est la plus efficace, donc je vais l'écrire comme ça."

Mais vous vous trompez presque toujours. Vous devriez écouter les designers et les artistes car leur flux de travail est très différent. Ils fonctionnent complètement différemment des autres. L'outil ne sera pas utilisé par vous, le plus souvent c'est pour eux.

DL: Avez-vous déjà rencontré une telle mentalité dans les équipes avec lesquelles vous avez travaillé? Et comment avez-vous géré cela?

KN: Il suffit de dire aux programmeurs: «Pourquoi pensez-vous que l'utilisateur a ce problème? Pensez-vous que le problème est dans le code? Ou peut-être que le problème est la structure de l'écran? La police est-elle trop petite? Mauvaise couleur de bouton? Peut-être que vous faites quelque chose de non standard? "

Parce que si vous regardez la plupart des outils de conception professionnelle, ils sont généralement assez cohérents. Il existe des guides de conception sur la façon dont les choses devraient fonctionner.

L'équipe créative doit pouvoir utiliser ces outils. Il ne faut pas qu'ils aient à lire la documentation. Dans un monde idéal, tout devrait être évident.

Aujourd'hui, il existe des concepteurs UX / UI, mais à l'époque il n'y en avait pas, nous avons donc dû créer la conception de l'interface nous-mêmes, mais avec les commentaires des utilisateurs.

Alors, asseyez-vous à côté des utilisateurs et voyez comment ils utilisent l'outil. Nous avons regardé comment ils fonctionnaient dans Lightwave. Lorsque nous avons écrit la première version de l'outil, nous nous sommes assis à proximité, sans demander quoi faire, et nous les avons regardés, en prenant des notes, telles que "il y avait des problèmes avec cela" ou "ils doivent constamment monter dans le menu pour trouver cela", ou "peut-être" cela vaut la peine d'en faire un raccourci clavier. " Il suffit de les regarder, d'apprendre et de s'adapter.

Autrement dit, vous devriez vraiment penser au flux de travail des concepteurs. Il est nécessaire de minimiser les mouvements inutiles, de minimiser l'exploration dans le menu, d'essayer d'ajouter des touches de raccourci. Nous avons activement promu les raccourcis clavier pour toutes les fonctions, car ils accélèrent le flux de travail. Dans le processus d'apprentissage de l'outil, vous accélérez considérablement le travail à l'aide de touches de raccourci et vous n'avez pas besoin de monter dans le menu.

Inutile de tomber dans le piège classique des ingénieurs: «Je sais mieux, j'ai noté l'instrument, je sais comment ça marche. Si vous ne pouvez pas l'utiliser, alors vous n'êtes qu'un idiot. » C'est la pire chose qui puisse arriver lors du développement d'un outil.

JL: Excellent conseil. Merci beaucoup Chris!