Template:PatchDiff/March 6, 2026 Patch/hl2/resource/closecaption french.txt
39153915"wood.scraperough" " "
39163916"plastic_box.scraperough" " "
39173917
N/A3918"#commentary\cn_001_physics_sound.mp3" "[ Jay Stelly ] Pour que la physique du jeu paraisse réaliste, les bruitages associés au système devaient l'être également. Même si nous ne le remarquons pas activement, nous avons tous une idée plus ou moins précise des bruits que produisent les interactions entre divers objets et matériaux. Tout en sachant que nous ne pourrions pas être exhaustifs, nous voulions nous concentrer sur les détails qui contribueraient le plus au réalisme de nos bruitages physiques. Nous avons commencé par créer des bruitages de collision et d'impact relatifs aux objets. Pour vous donner un exemple, nous avons attribué aux caisses en bois des sons personnalisés en cas de collision avec d'autres objets ou catégories d'objets. Ensuite, nous avons entrepris de modifier ces sons de manière dynamique en fonction des caractéristiques de l'événement physique, comme les masses impliquées ou la force de la collision. Le résultat était excellent pour les collisions, mais insatisfaisant pour les autres types d'interactions telles qu'un frottement entre deux objets. En réalité, une caisse en bois ne produit pas le même son lorsqu'elle est frottée contre un mur et lorsqu'elle est jetée contre ce même mur. Je peux vous assurer que personne n'a jamais étudié les nuances des propriétés physiques d'une caisse en bois autant que nous l'avons fait. Pour obtenir les résultats que nous recherchions, nous avons alors créé des bruitages de collision relatifs aux matériaux impliqués : métal contre bois, métal contre métal, etc. Nous les avons, eux aussi, modifiés de manière dynamique en fonction de détails comme la solidité du matériau ou le type de métal. Pour peaufiner ce système, nous avons dû procéder à d'innombrables et infimes ajustements que nous ne pouvions identifier qu'en cours de partie. Nous avons également testé des sons personnalisés pour les objets roulants, mais cette fonctionnalité a été supprimée car nous n'étions pas satisfaits des résultats."
N/A3919"#commentary\cn_002_ramming_with_the_buggy.mp3" "[ Jay Stelly ] Notre moteur physique étant basé sur des corps rigides, il ne prend pas en charge la déformation ou la destruction d'objets. Quand un objet simulé physiquement est touché par quelque chose, il peut être déplacé si ses paramètres l'y autorisent, mais il ne se passe rien d'autre. Ainsi, lorsque vous foncez dans une vitre avec le buggy, nous devons ruser pour obtenir le résultat voulu. Puisque la fenêtre est fixe, la simulation physique fait rebondir le buggy contre le verre, mais informe notre système de jeu qu'une collision a eu lieu. Celui-ci, qui prend en charge la destruction, brise la vitre et ordonne au moteur physique de commencer à simuler les éclats de verre. Mais surtout, il lui demande également de rétablir l'état du buggy tel qu'il était avant la collision. Ceci permet de garantir qu'à la prochaine simulation physique, le véhicule passera librement à travers la fenêtre désormais détruite. Le temps d'une image, ce processus provoque une saccade de la physique du buggy, car il s'arrête brièvement et est téléporté à la position qu'il occupait à l'instant précédent l'impact. Nous sommes désolés, si Half-Life 2 vous paraît injouable depuis que vous avez appris cette information. Mais à l'époque, après avoir observé des playtests, nous étions contents de cette saccade éphémère. Nous trouvions même qu'elle renforçait la sensation d'impact."
N/A3920"#commentary\cn_003_ramming_zombies_with_the_buggy.mp3" "[ Jay Stelly ] En tant qu'êtres humains, nous avons des attentes vis-à-vis du fonctionnement de notre monde physique, comme cela a déjà été mentionné plusieurs fois dans ce commentaire. L'une d'entre elles étant que si vous percutez un zombie avec votre véhicule, il doit être projeté en l'air. Toutefois, il est plus difficile d'obtenir cet effet dans le jeu que dans le monde réel. Pour des raisons de performances, les ennemis comme le zombie utilisent une boîte de collision simplifiée. Celle-ci est parfaitement ajustée au modèle du zombie, dont aucune partie ne dépasse. Mais quand le zombie meurt, il se change en poupée de chiffon dont chaque membre est doté de boîtes de collision plus précises, même si leur simulation est plus coûteuse en ressources. Lorsque vous foncez dans un zombie avec le buggy, ce changement dans la représentation des collisions ajoute un niveau de complexité dépassant la simple saccade de l'image. Quand le buggy heurte le zombie pour la première fois, il touche sa boîte de collision simplifiée. Le jeu tue le zombie et le transforme en ragdoll, que le moteur physique entreprend de simuler. Les boîtes étant désormais plus précises et liées aux membres du zombie, la partie la plus proche de celui-ci peut se trouver à plusieurs centimètres du buggy. Par conséquent, à la prochaine simulation du moteur physique, le zombie n'étant plus poussé par le véhicule tombera sous l'effet de la gravité. Il ne s'écoule qu'un court instant avant que le buggy ne heurte à nouveau le zombie, mais ce décalage mineur suffisait à diminuer la satisfaction ressentie en fonçant sur ces ennemis, car ils tombaient très vite hors du champ de vision du joueur. Afin d'y remédier, nous avons enregistré la force encaissée par la boîte de collision lors du premier choc avec le buggy et avons appliqué une force égale à la poupée de chiffon après conversion. Nous avons également ajouté une faible poussée verticale à cette dernière pour la propulser légèrement. Grâce à ces ajustements, les zombies heurtés se pliaient correctement sur l'avant du buggy, ce qui correspondait davantage aux attentes des joueurs."
N/A3921"#commentary\cn_004_buggy_sound_engine.mp3" "[ Kelly Bailey ] La sonorisation du buggy n'a pas été simple, car nous voulions donner l'impression d'un véhicule très puissant fonçant à toute vitesse, alors que nos cartes ne sont pas assez vastes pour ça et que le buggy roule toujours en première sans jamais dépasser les 55 km/h. Pour notre défense, cela reste relativement rapide, surtout en 2004. En plus de cette problématique de vitesse, les commandes de conduite sont relativement basiques. Au clavier, elles sont même binaires : soit le buggy accélère, soit il n'accélère pas ; soit il tourne entièrement dans une direction, soit il ne tourne pas. En résumé, nous devions concevoir une piste audio complexe pour représenter une simulation qui ne l'était pas. Nous avons donc élaboré un faux moteur pour assurer la sonorisation du buggy. Il dispose de son propre système de transmission, et nous combinons les commandes saisies par le joueur aux données de la simulation physique. Nous mesurons le couple de chaque roue simulée, qu'elle tourne dans le vide ou soit en contact avec une surface, et créons toute une gamme de boucles audio. Ensuite, nous passons soigneusement de l'une à l'autre quand le faux moteur change de vitesse et réagit aux données des roues. Nous avons expérimenté, ajouté davantage de complexité, puis peaufiné le système jusqu'à ce qu'il rende le buggy plus agréable à conduire et, en quelque sorte, récompense le joueur pour ce sentiment de vitesse. La plupart des joueurs n'ont fait aucun commentaire à ce sujet, hormis le fait qu'ils trouvaient le son du buggy réussi. Étant donnée la folie de ce qui se passe sous le capot, nous considérons cela comme un succès."
N/A3922"#commentary\cn_005_buggy_sound_design.mp3" "[ Kelly Bailey ] Le design sonore du buggy est inspiré d'une vieille Camaro de 1968. Nous avons choisi cette voiture, car elle est équipée d'incroyables moteurs V8 avec d'énormes pistons dont le son profond, quasi viscéral, est unique en son genre et conforme à ce que nous recherchions. Sa transmission produit également un superbe gémissement mécanique lorsqu'elle arrête d'accélérer. Cette association nous paraissait particulièrement adaptée au système de commandes binaire avec lequel nous devions composer. Ainsi, la transmission du faux moteur n'a pas été conçue d'après une véritable voiture, mais en tant que simple système visant à récompenser le joueur lorsqu'il relâche l'accélérateur. Ce système tourne en boucle : il produit un bruit croissant, faisant continuellement monter la tension, puis change de vitesse lorsque la boucle sonore doit recommencer. Puisque nos cartes sont relativement petites et que le joueur vient rapidement à manquer d'espace, l'objectif était simplement de rendre l'accélération fun sur une courte durée."
N/A3923"#commentary\cn_006_automating_dsp.mp3" "[ Kelly Bailey ] Tous les sons que le joueur entend sont traités par notre système de traitement numérique du signal (\"Digital Signal Processing\" ou DSP). Pour faire court, cela désigne la manière dont le signal audio est modifié pour refléter l'environnement dans lequel évolue le joueur. Par exemple, un même son sera entendu différemment dans un parking souterrain, dans une petite pièce ou à l'extérieur. Pour Half-Life 1, nous avions placé manuellement des nœuds invisibles afin de définir des paramètres de DSP pour chaque zone de notre monde. Pour Half-Life 2, nous savions que ce placement manuel serait bien trop chronophage, d'autant plus que nous voulions construire un espace de jeu plus vaste et que notre équipe audio ne comprenait toujours qu'une seule personne. Nous avons donc conçu un système capable de déterminer automatiquement et en temps réel les paramètres de DSP autour du joueur. Pour ce faire, le système analyse l'espace autour du joueur, évalue le volume dans lequel il se trouve et examine les matériaux composant cet environnement. Il associe ensuite cet espace à l'un des 25 types de DSP de base définis manuellement, puis nous réglons quelques paramètres et créons le DSP détaillé qui modifie le son qu'entend le joueur."
N/A3924"#commentary\cn_007_dynamic_mixing.mp3" "[ Kelly Bailey ] Dans le jeu, de nombreux sons sont joués constamment. Tous n'ayant évidemment pas la même importance, le volume de chaque son doit être ajusté en fonction des autres afin de garantir que le plus important se démarque. Pour un film, le mixage du son s'effectue en post-traitement, mais pour un jeu, tout se passe en temps réel et dépend des actions du joueur. Nous ne pouvons donc pas prédire quels sons seront joués simultanément. Pour régler ce problème, nous les catégorisons par type et leur attribuons une priorité. Dans le jeu, le système audio surveille tous les sons actifs et baisse le volume de toute une catégorie si un son prioritaire est joué. Ce mixage peut être ajusté. Si des coups de feu doivent être forts pour une scène, nous pouvons temporairement leur accorder une plus grande priorité. Si nous voulons qu'une ligne de dialogue spécifique puisse être entendue clairement, nous pouvons forcer une baisse de volume pour tous les autres sons. C'est également ce que nous faisons pour la musique. Il s'agit d'un système subtil, mais crucial, qui empêche tout simplement une surcharge de l'environnement sonore."
N/A3925"#commentary\cn_008_soundscapes.mp3" "[ Kelly Bailey ] Dans Half-Life 1, les sons ambiants étaient placés manuellement, puis ajustés individuellement. Pour Half-Life 2, nous voulions que nos environnements contiennent des sons ambiants plus nombreux, de meilleure qualité et dont le placement nécessiterait moins d'efforts. Nous avons donc créé un système de \"paysage sonore\", c'est-à-dire un petit programme contrôlant quels sons ambiants sont joués, d'où ils proviennent, puis leur comportement dans un environnement spécifique. Le bourdonnement des mouches, le vent qui souffle, les oiseaux, un train qui passe, des combats au loin... Le système de paysage sonore peut ensuite sélectionner et jouer ces sons aléatoirement, et surtout assurer des transitions fluides lorsque le joueur change d'environnement. Un paysage sonore pouvant en contenir d'autres, nous avons créé des collections de sons réutilisables. La collection \"combat au loin\", par exemple, était constituée de tirs d'arme légère, d'explosions lointaines ou d'un passage d'hélicoptère. Ces paysages sonores s'assemblent ensuite de manière dynamique et jouent de nombreux sons individuels, ce qui permet d'éviter l'aspect artificiel d'une piste unique jouée en boucle. Dans l'ensemble, le système de paysage sonore constitue une pièce maîtresse de Half-Life 2, car il est responsable de chaque son que vous entendez qui ne découle pas directement du gameplay."
N/A3926"#commentary\cn_009_audio_over_distance.mp3" "[ Kelly Bailey ] Les grands espaces des cartes de la Côte nous ont conduits à chercher une solution audio pour représenter la manière dont la distance modifie le son. Il est, en effet, important de pouvoir différencier les coups de feu tirés par un ennemi situé à 100 mètres de vous de ceux tirés par un ennemi proche. Nous avons décidé de stocker nos sons dans un seul fichier stéréo : les sons proches dans le canal gauche et les sons distants dans le canal droit. Ensuite, durant la lecture, nous effectuons un crossfade, c'est-à-dire que nous modifions, entre ces deux canaux et en fonction de la distance qui sépare le joueur de la source du son, les proportions sonores de ce que vous entendez. Cette solution simple et efficace nous a permis de contourner des restrictions de mémoire. Pour l'entendre en action, rien de plus facile : il vous suffit de conduire en direction d'un soldat du Cartel et d'écouter l'évolution du bruit des coups de feu."
N/A3927"#commentary\cn_010_flying_vehicle_audio.mp3" "[ Kelly Bailey ] Les gros engins volants représentaient un défi audio sans précédent. En combat, ils sont bien plus mobiles que les autres ennemis et ont tendance à s'éloigner du joueur. Ils sont également très dangereux dès qu'ils ont une ligne de tir. Tous ces facteurs nous ont conduits à concevoir notre solution audio autour de l'occlusion, c'est-à-dire quand vous pouvez voir l'ennemi et quand l'ennemi peut vous voir. Nous voulions créer une distinction sonore nette pour signaler que l'ennemi vous a dans sa ligne de mire. Les bruits de moteur des engins volants sont constitués de plusieurs boucles sonores jouées simultanément. Certaines sont traitées par le système de DSP en fonction de l'espace dans lequel vous vous trouvez, tandis que d'autres sont jouées directement, brutes. Le système de DSP ajoute une sorte d'écho environnemental aux sons qu'il traite. Lorsqu'un ennemi volant est caché derrière un obstacle et ne peut pas vous voir, nous augmentons le pourcentage de boucles traitées par le DSP, et l'ennemi semble alors se trouver un peu plus loin. Ensuite, lorsque ce même ennemi surgit de derrière l'obstacle et peut vous voir, nous privilégions le son brut. Dans l'ensemble, ce traitement du son permet de donner l'impression que l'ennemi est loin et n'a pas de cible précise, ou, au contraire, qu'il se trouve dans votre ligne de mire. Normalement, vous pouvez entendre cette différence lorsque l'hélicoptère surgit derrière un bâtiment."
N/A3928"#commentary\cn_011_bullet_audio.mp3" "[ Kelly Bailey ] S'il y a une chose dont nous pouvions être sûrs, c'est que de nombreuses balles allaient frôler le joueur au cours du jeu. Nous avons donc passé un certain temps à essayer d'en parfaire le traitement audio. Malheureusement, les balles sont pour ainsi dire instantanées. Nous ne pouvions pas leur associer un son et nous baser sur leur mouvement pour gérer la spatialisation. Après quelques expérimentations, nous sommes parvenus à une solution : en déterminant, sur la trajectoire de la balle, le point le plus proche de l'oreille du joueur, nous calculons le moment et la position exacte de la balle à l'instant où elle passera théoriquement ce point. Nous jouons alors deux sons différents pour créer un faux effet Doppler : le premier pour la balle qui approche, le second pour la balle qui s'éloigne. Ensuite, nous retardons le son d'éloignement en fonction du moment, calculé précédemment, lors duquel la balle frôlera le joueur."
N/A3929"#commentary\cn_012_staircase.mp3" "[ Aaron Seeler ] Certaines situations dans le jeu sont le résultat d'objectifs relativement simples, et ces escaliers en remplissent deux. Le premier consistait à présenter la citadelle en plein éveil, pour que le joueur comprenne qu'il vient de donner un coup de pied dans la fourmilière. Le second était de mettre en avant notre système de physique ragdoll. C'est désormais habituel, mais en 2004, il était encore inédit de voir des corps rebondir de manière réaliste, et ces escaliers nous offraient une occasion parfaite de le montrer."
N/A3930"#commentary\cn_013_alyx_and_mossman.mp3" "[ Bill Fletcher ] Dans nos premières ébauches de scénario pour Half-Life 2, nous voulions relever le défi d'une approche narrative moins explicitement centrée sur le jeu. Ne pas simplement raconter l'histoire manichéenne du gentil joueur terrassant des ennemis maléfiques, mais une histoire faisant la part belle aux personnages et à leurs relations. Nous pensions qu'il serait intéressant d'explorer la thématique de la famille comme unité dynamique centrale de Half-Life 2. C'est d'ailleurs de cette idée qu'est née la tension entre Alyx et Mossman : nous pensions que les joueurs pourraient la comprendre, s'identifier à ce ressenti, et cela nous plaisait."
N/A3931"#commentary\cn_014_exposition_board.mp3" "[ Danika Rogers ] Nous avons décidé de placer ce gros morceau de narration visuelle ici, car c'est l'endroit du jeu que les joueurs sont le plus explicitement encouragés à explorer. Bien que l'objectif principal était d'étoffer l'univers, nous avons fait en sorte de souligner la relation entre Eli et Breen afin de mettre en contexte le conflit central qui agite leur monde."
N/A3932"#commentary\cn_015_city_17_awakens.mp3" "[ David Sawyer ] La première section dans la gare était conçue pour donner une impression d'indifférence de la ville envers le joueur, comme si Gordon n'était qu'un citoyen anonyme parmi d'autres, prêt à être asservi. Mais pendant le raid dans l'immeuble et la poursuite sur les toits, la ville identifie le joueur comme une anomalie et commence à s'agiter. À présent, le joueur est devenu l'agresseur, et la ville lui accorde toute son attention. Le système de communication de la milice, entendu pour la première fois durant le raid, jouait un rôle crucial dans la transmission de ce message. Les joueurs attentifs pouvaient en retirer de nombreuses informations sur la prise de conscience de la ville. Pour les autres, le traitement audio parvenait tout de même à communiquer le message émotionnel que nous visions."
N/A3933"#commentary\cn_016_elis_lab.mp3" "[ Dhabih Eng ] Nous avons imaginé le laboratoire d'Eli à partir de celui du Dr Kleiner, ce qui nous a permis de mieux comprendre comment mettre en place et concevoir des scènes Choreo efficaces. Par conséquent, nous avons pu créer un scénario plus complexe et incluant davantage d'occasions de réagir aux actions du joueur. La mise en scène a été délicate, du fait des multiples personnages vaquant à leurs occupations à travers la pièce, et il a fallu passer par de nombreuses itérations et playtests pour obtenir un résultat satisfaisant. Notre expérience a démontré que, la plupart du temps, les joueurs voulaient suivre le déroulé de la scène. Ils avaient simplement besoin d'indices subtils pour savoir où nous voulions les conduire. De la même manière, s'ils étaient distraits par quelque chose, la scène devait s'interrompre subtilement en attendant qu'ils reviennent."
N/A3934"#commentary\cn_017_feel_free_to_look_around.mp3" "[ Dhabih Eng ] Trouver le juste équilibre entre les envies d'exploration du joueur et les objectifs narratifs d'une scène a toujours été un défi. Nous voulions remplir cette salle d'éléments intéressants à observer, mais de nombreux joueurs ne commençaient pas à explorer avant d'être certains de n'avoir raté aucune des prestations de nos personnages. Pour cette raison, il était important qu'Eli l'encourage à jeter un œil autour de lui au milieu de la scène, signalant ainsi qu'il pouvait explorer sans crainte. Ensuite, nous pouvions déclencher de courtes scènes en fonction de ce qui attirait l'attention du joueur."
N/A3935"#commentary\cn_018_interstitial_scenes.mp3" "[ Eric Kirchmer ] Au fur et à mesure des playtests, nous avons fréquemment constaté que les joueurs perdaient de vue leur objectif dans certaines zones, ce qui est plutôt habituel dans un jeu comme Half-Life. Pour y remédier, nous avons ajouté des petites scènes servant à guider les joueurs le long du chemin et à leur rappeler l'objectif. Après avoir terminé le gros du développement de nos scènes Choreo principales, comme le labo de Kleiner, assembler ces scènes secondaires était relativement simple. Nous avons découvert que l'utilisation de personnages pour créer ces moments était bien plus efficace que de se reposer sur une narration passive, voire sur un quelconque rappel intégré au menu de pause."
N/A3936"#commentary\cn_019_overwatch.mp3" "[ Josh Weier ] Pendant le développement du jeu, nous avons utilisé un outil de synthèse vocale gratuit pour générer la voix de la milice, mais alors que la sortie du jeu approchait, nous avons réalisé que nous ne disposions pas des droits pour l'utiliser dans le jeu. Nous avons donc auditionné des acteurs de doublage pour trouver une personne possédant les qualités qui nous plaisaient dans les lignes générées. Nous avons très vite arrêté notre choix sur Ellen McClain, dont le phrasé était exactement ce que nous recherchions. Lors des sessions d'enregistrement, nous lui avons fait écouter les dialogues générés par la synthèse vocale afin qu'elle s'en inspire. Au départ, elle était un peu dubitative, puisque nous lui demandions de simuler une élocution robotique. Mais quelques années plus tard, quand elle est revenue pour son rôle culte de GLaDOS dans *Portal*, elle avait trouvé un moyen d'intégrer ce ton à son jeu de manière créative."
N/A3937"#commentary\cn_020_box_car_joe.mp3" "[ Laura Dubuk ] Cette saynète intégrait initialement deux personnages humains, mais nous en avons finalement remplacé un par un Vortigaunt. Nous voulions montrer que les Vortigaunts coexistaient avec les humains et luttaient eux aussi contre le Cartel. Nous avons également introduit leur capacité à soigner le joueur, même si nous n'avons pas pleinement tiré parti de cette fonctionnalité dans le reste du jeu. Les Vortigaunts sont devenus un outil narratif particulièrement utile pour garantir des dialogues brefs : dotés d'une conscience collective justifiant leur parfaite connaissance de l'univers et des objectifs du joueur, ils ne posaient pas de questions et nous n'avions ainsi pas besoin de leur écrire de dialogues."
N/A3938"#commentary\cn_021_mossman.mp3" "[ Marc Laidlaw ] Judith Mossman est inspirée d'un personnage que nous avions créé pour un chapitre de Half-Life 1, qui a finalement été supprimé du jeu de base et réutilisé dans Uplink, mais sans le personnage. À nos yeux, il s'agit du personnage le plus complexe de Half-Life 2. Nous étions conscients de marcher sur des œufs en essayant de guider l'opinion du joueur sur Mossman, même avant Nova Prospekt, car ses sources de confiance sont en désaccord : Eli l'apprécie, mais pas Alyx. Nous savions également qu'il y avait une limite à la complexité que nous pouvions intégrer aux relations entre nos personnages, mais nous estimions que les joueurs comprendraient la dynamique belle-mère/belle-fille. Que vous soyez d'accord ou non avec Mossman, son comportement est héroïque. Elle a pris le risque de devenir une agent double pour obtenir les informations dont elle avait besoin pour protéger Eli et Alyx. Simplement, elle n'avait pas anticipé l'arrivée de Gordon."
N/A3939"#commentary\cn_022_hands_free.mp3" "[ Matt Wright ] À l'époque où Half-Life 2 est sorti, la plupart des FPS fournissaient immédiatement une arme au joueur, mais nous avons fait le choix inverse. Sans arme, il est plus facile de présenter notre histoire au joueur et de le former aux manières novatrices dont il peut interagir avec le monde. Nous voulions qu'il passe de fugitif à assaillant, et en lui procurant une arme au bon moment, cette transition se faisait naturellement. Lorsque le joueur obtient enfin une arme, il en a assez de fuir. On dit que le meilleur moyen de gagner est parfois de tourner le dos au conflit, mais nous savons tous que ce n'est pas vrai. Le meilleur moyen de gagner, c'est de courir droit sur l'ennemi en lui tirant dessus."
N/A3940"#commentary\cn_023_metrocop_scene.mp3" "[ Mike Dussault ] Voici une autre scène conçue pour établir clairement le fait que les métroflics sont les méchants, sauf que cette fois, le joueur possède une arme et un moyen de répliquer, en attaquant l'ennemi. Par ce moment, entre autres, nous voulions susciter un sentiment de légitimité chez le joueur. Les métroflics étant toujours humains, contrairement au reste du Cartel, nous avons estimé devoir faire le maximum pour veiller à ce que les actions du joueur apparaissent motivées par un sentiment de justice et non par la simple colère."
N/A3941"#commentary\cn_024_moving_the_gravity_gun.mp3" "[ Ted Backman ] Quand nous avons conçu le premier prototype du pistolet anti-gravité, nous pensions le présenter au joueur vers le milieu du jeu. Mais à mesure que les playtests avançaient, nous avons compris la force de son design et réalisé que nous devions introduire cette arme, et surtout la capacité de lancer des scies au visage des zombies, bien plus tôt. Cela signifiait que le laboratoire d'Eli devait également apparaître plus tôt que prévu. Il s'agissait d'un changement majeur, mais déterminant pour assurer le succès de Half-Life 2. Ce genre de détail nous rappelle que la narration et le gameplay sont interconnectés, et que l'un ne doit pas prendre le pas sur l'autre : les deux doivent évoluer de concert."
N/A3942"#commentary\cn_025_buggy_birds.mp3" "[ Adrian Finol ] Lors d'un playtest de la Côte, un joueur retournant à son véhicule après avoir exploré une maison a vu un oiseau passer non loin. Il s'est mis à crier sur l'animal, lui ordonnant de ne pas s'approcher du buggy et se plaignant des oiseaux qui venaient régulièrement souiller sa voiture dans le monde réel. Après le playtest, en discutant des résultats, nous avons réalisé que c'était la première fois qu'un objet totalement distinct du joueur suscitait une réaction. Y voyant une piste à explorer, nous avons conçu un système pour provoquer la situation que craignait ce testeur. Si le joueur s'éloigne du buggy assez longtemps sans le regarder, nous faisons apparaître une mouette sur une position aléatoire de la carrosserie. Avec le temps, des traces de guano apparaissent également. Enfin, quand le joueur revient, la mouette s'envole. Naturellement, les playtesteurs voulaient pouvoir laver leur véhicule : il suffit pour cela de conduire le buggy dans des eaux peu profondes. Puisque nous en étions à un stade relativement avancé du développement et disposions déjà des technologies nécessaires, cette fonctionnalité a pu rapidement être mise en œuvre. Nous savons que seul un maigre pourcentage de joueurs s'en apercevront, mais si nous parvenons à intégrer ce genre de détails efficacement et en nombre suffisant, la plupart des joueurs devraient en découvrir au moins un."
N/A3943"#commentary\cn_026_bridge_gunship.mp3" "[ Adrian Finol ] Nous étions particulièrement satisfaits du combat contre l'hélico, même si sa mise place a été complexifiée par la géométrie du niveau. L'affrontement se déroulant sous le pont, l'appareil peut se déplacer librement tout autour du joueur et profiter des trois dimensions pour se placer au-dessus ou en dessous de lui selon la situation. Les poutrelles offrant de nombreuses possibilités de s'abriter sont autant d'occasions pour les tirs de l'hélico de produire des effets visuels et sonores divertissants et dynamiques."
N/A3944"#commentary\cn_027_floor_is_lava.mp3" "[ Adrian Finol ] Les phases de gameplay élaborées autour de concepts compris du plus grand nombre, comme \"le sol est de la lave\", rendent l'entraînement plus facile. Nous aimions la manière dont notre moteur physique offrait aux joueurs une grande liberté dans leur approche. Certains construisaient des passerelles en plaçant de nombreux objets, quand d'autres se contentaient d'utiliser deux plaques de tôle. Certains suivaient prudemment le chemin dans les rochers par peur de tomber, d'autres se dirigeaient directement vers la sortie, perchés sur des objets dépassant tout juste du sable. Les styles de jeu étaient variés : des joueurs considéraient avoir échoué si les fourmis-lions apparaissaient et rechargeaient instantanément la partie, tandis que d'autres se repliaient joyeusement sur les rochers le temps de récupérer. Nous aimions également le fait que cette séquence, qui fonctionnait bien en tant qu'énigme de navigation, pouvait être transformée en arène de combat si les joueurs souhaitaient foncer dans le sable et se battre jusqu'à la sortie."
N/A3945"#commentary\cn_028_opportunistic_moments.mp3" "[ Ariel Diaz ] Certains moments inoubliables du jeu découlent d'interactions entre différents systèmes, mais parfois, nous réalisons qu'ils ne surviendront sans doute que rarement. Dans ces cas-là, nous souhaitons généralement qu'un maximum de joueurs vive ces moments. Cela crée une tension, car plus nous savons que les joueurs seront confrontés à une situation, plus nous pouvons y consacrer d'efforts. Mais si le résultat semble trop artificiel, le moment risque de paraître forcé et d'entraîner des réactions moins positives. Pour la destruction cinématique de l'hélico, entre autres, nous avons dû intervenir légèrement afin d'augmenter les chances de provoquer un moment marquant sans que cela paraisse trop évident. Entre la disposition de la zone et la trajectoire de vol de l'appareil, il est probable que le joueur et l'hélico se trouvent dans la bonne position lors de sa destruction. Si c'est le cas, nous déclenchons le crash de l'hélico dans les voitures. Sinon, il s'écrase de manière classique. C'est complètement artificiel, mais quand cela se passait correctement, les playtesteurs semblaient apprécier le spectacle."
N/A3946"#commentary\cn_029_assault_on_nova_prospekt.mp3" "[ Ariel Diaz ] Avec une armée de fourmis-lions réapparaissant à l'infini en bord de mer et prenant d'assaut une base fortifiée du Cartel, il était difficile de ne pas concevoir un niveau inspiré du débarquement de Normandie. Dans notre premier prototype, des mitrailleuses forçaient le joueur et ses fourmis-lions à emprunter des tranchées pour rejoindre Nova Prospekt. Entre les tirs de mitrailleuse et les fourmis-lions bondissant au-dessus des tranchées, la scène était palpitante. Malheureusement, cela ne rentrait pas dans notre budget de performances et nous avons dû abandonner cette idée en faveur d'une configuration totalement différente. Nous avons toutefois conservé les mitrailleuses, car leur dangerosité s'est révélée être capitale pour encourager les joueurs à utiliser leurs fourmis-lions."
N/A3947"#commentary\cn_030_buggy_physics.mp3" "[ Charlie Brown ] Nous avons longtemps tâtonné pour développer la physique du buggy. Nous voulions qu'il procure une sensation de rapidité, mais avec une vitesse de pointe dépassant tout juste les 55 km/h, nous avons dû tricher un peu. Nous avons renforcé la poussée verticale du saut et ajouté un peu de puissance à l'arrière pour que l'utilisation du frein à main permette de déraper. Sans ça, la lenteur du buggy rendait la conduite ennuyeuse. En outre, le monde étant rempli d'éléments physiques imprévisibles, les joueurs allaient forcément être confrontés à des collisions chaotiques et nous devions nous assurer qu'ils pourraient toujours repartir. Cela a nécessité un grand nombre d'expérimentations et de tests. Au final, nous avons conçu une simulation peu réaliste, presque ridicule, pour que le buggy soit plus facile à manier et plus difficile à retourner. Son centre de gravité est extrêmement bas et, contrairement à ce que l'on pourrait croire, ses roues ne tournent pas beaucoup. Il s'agissait de notre première tentative de simuler physiquement un véhicule, et nous avons énormément appris de cet exercice, ce qui nous a permis de rendre la muscle car de l'Épisode 2 est bien plus agréable à conduire."
N/A3948"#commentary\cn_031_the_bridge.mp3" "[ Charlie Brown ] Ce pont est inspiré du pont de Deception Pass, qui se trouve à proximité des bureaux de Valve. Initialement, cette section a été conçue comme une énigme de navigation pure à laquelle nous avons progressivement intégré des éléments de gameplay. Elle est également devenue notre principale zone de test du coefficient de friction du joueur sur les rebords. Dans notre système de déplacement, nous augmentons subtilement la friction appliquée à la décélération du joueur lorsque celui-ci approche de l'extrémité d'une surface. Les joueurs n'ont jamais remarqué cet effet, probablement parce qu'il s'aligne sur leur objectif de s'arrêter près du bord pour regarder en bas, et correspond à la tendance naturelle des êtres humains à se déplacer lentement et prudemment lorsqu'ils approchent d'un précipice. Il s'agit toutefois d'une fonctionnalité cruciale pour cette section du jeu. Nous pouvons l'affirmer, car le jour où nous l'avons cassée accidentellement pendant le développement, tous nos playtesteurs ont subitement commencé à tomber dans le vide."
N/A3949"#commentary\cn_032_coast.mp3" "[ Chris Green ] Nous voulions consacrer au buggy une vaste zone ouverte, mais nous devions tout de même trouver un moyen de restreindre les déplacements du joueur. Choisir un littoral permettait d'imposer une frontière naturelle d'un côté de la carte tout en présentant un terrain étendu et dégagé. Cela aidait également le joueur à visualiser les effets de l'extraction des ressources terrestres par le Cartel. Comme plusieurs playtesteurs avaient essayé de nager dans la mer, nous avons ajouté des sangsues pour les en dissuader. Elles sont un peu magiques, car nous ne pouvions pas en faire de réels ennemis que les joueurs s'imagineraient pouvoir combattre ou éviter. En général, ils comprenaient d'eux-mêmes qu'ils avaient atteint les limites du jeu, alors nous ne les avons pas développées plus que ça."
N/A3950"#commentary\cn_033_grenade_house.mp3" "[ Dave Riller ] Les jeux Half-Life consistent en grande partie à proposer un maximum d'expériences de combat novatrices, même si celles-ci ne varient que légèrement des précédentes. Toutes n'ont pas à mettre les compétences du joueur à l'épreuve. Parfois, elles peuvent simplement lui permettre de s'amuser et de se défouler un peu. Cette maison remplie de grenades en est un parfait exemple, la subtilité étant que nous avons inversé la configuration habituelle : au lieu de lâcher des grenades sur des ennemis situés à un niveau inférieur, le joueur doit les lancer au-dessus de sa tête. La réserve illimitée de grenades l'encourage, un peu maladroitement, à s'impliquer dans le scénario, mais son invulnérabilité garantit également que le joueur pourra toujours accéder à l'étage supérieur, même s'il a fait exploser tout le reste."
N/A3951"#commentary\cn_034_buggy_training_course.mp3" "[ David Sawyer ] Nous avons conçu cette section pour que le joueur s'entraîne à piloter son buggy. Quand Half-Life 2 est sorti, un tel niveau de simulation physique pour un véhicule était novateur, et nous souhaitions accorder au joueur un maximum de possibilités d'en faire l'expérience. Comme il vient de quitter les étroites ruelles de Ravenholm, nous voulions également le récompenser en lui permettant d'explorer à toute vitesse un vaste espace, en sécurité dans un véhicule. Le seul moyen de quitter la zone est d'effectuer un saut : nous pouvions ainsi vérifier que le joueur avait acquis un certain degré de confort au volant du buggy, tout en nous assurant qu'il ne partirait pas sans."
N/A3952"#commentary\cn_035_ambush.mp3" "[ David Sawyer ] Dans un FPS comme Half-Life, le joueur s'aventure constamment dans des espaces qu'il ne connaît pas. Autrement dit, en cas d'affrontement, il se trouve généralement dans une zone inconnue et n'a aucune idée de la manière dont il doit aborder le combat. Nous utilisons diverses méthodes pour aider le joueur à résoudre ce problème, et cette embuscade en est un exemple. En arrivant ici, le joueur doit affronter un groupe de soldats du Cartel. Le combat et la phase d'exploration qui s'ensuit lui permettent d'apprendre la configuration de l'arène. Plus tard, lorsqu'il vient explorer ce grenier et que nous faisons apparaître une seconde vague d'ennemis, le joueur dispose désormais d'un avantage : il connaît le terrain, et cela lui permet d'effectuer des choix tactiques pour se défendre contre ses assaillants."
N/A3953"#commentary\cn_036_bugbait_training.mp3" "[ David Sawyer ] Cette initiation sur l'utilisation des appâts est maladroite, mais nous manquions de temps et avions besoin que les joueurs comprennent le concept pour que le design de Nova Prospekt fonctionne. En général, nous essayons d'ajouter suffisamment de variété et de contexte aux initiations pour donner l'impression au joueur qu'il découvre naturellement un élément nouveau. Ici, toutefois, nous n'y sommes pas vraiment parvenus. Cela peut sembler évident, mais les joueurs ne comprenaient pas intuitivement comment utiliser l'appât. À ce stade du jeu, ils sont habitués à affronter des ennemis. Avant l'ajout de cette initiation, les premiers playtesteurs obtenaient l'appât, accédaient au niveau suivant et, suivant la méthode appliquée jusqu'ici, tuaient instinctivement la première fourmi-lion qu'ils croisaient (il faut dire que Half-Life encourage généralement l'approche \"tirer d'abord, poser les questions ensuite\"). De même, en arrivant à Nova Prospekt, les joueurs ne pensaient pas à lancer des appâts sur les soldats du Cartel et se reposaient sur leurs armes habituelles. Cette initiation était donc impérative, non seulement pour enseigner le fonctionnement de l'appât, mais également pour montrer que les fourmis-lions pourraient évoluer à proximité du joueur sans l'attaquer."
N/A3954"#commentary\cn_037_vortigaunt_extraction.mp3" "[ Dhabih Eng ] La conception de cette arène présentait deux défis. Tout d'abord, le garde pouvant uniquement attaquer au corps-à-corps, nous ne pouvions pas laisser le joueur atteindre des positions où l'ennemi ne pourrait pas le suivre. Nous avons bien essayé de lui donner quelques attaques à distance, mais nous n'étions pas satisfaits des résultats (son crachat de substance visqueuse, par exemple, était ridicule). La seule à avoir survécu est sa capacité à lancer des objets sur le joueur, mais il doit pour cela se trouver à portée d'objets divers, ce qui n'est pas garanti. Deuxièmement, nous devions nous assurer que le Vortigaunt pourrait toujours atteindre la dépouille du garde, quel que soit l'emplacement de sa mort. C'était une condition essentielle, car le jeu ne peut pas continuer si le Vortigaunt n'arrive pas à extraire l'appât."
N/A3955"#commentary\cn_038_dropship_deployment.mp3" "[ Doug Wood ] Réussir le déploiement des soldats depuis les vaisseaux s'est révélé être délicat, car cela nécessitait de faire apparaître les PNJ à l'intérieur d'un autre objet solide. Nous avons créé une animation qui se lance dès leur apparition pour qu'ils bondissent hors du transporteur avant de commencer à se déplacer normalement. Une fois ce travail accompli, nous avons rencontré un autre problème : les joueurs se sont vite rendu compte qu'ils pouvaient simplement attendre devant l'appareil et abattre les soldats durant leur animation de sortie. Nous avons donc équipé le vaisseau d'une tourelle pour couvrir leur sortie. Cette méthode n'empêche pas totalement les joueurs de prendre l'avantage, surtout s'ils utilisent des armes indirectes comme des grenades, mais elle nous paraissait une contre-mesure réaliste, conforme à ce qu'une personne réfléchissant stratégiquement aurait pu imaginer dans le monde réel."
N/A3956"#commentary\cn_039_laser_guided_rpg.mp3" "[ Eric Smith ] Enseigner aux joueurs le fonctionnement du système de guidage laser du lance-roquettes s'est révélé être un véritable casse-tête. De nombreux playtesteurs se mettaient directement à couvert après avoir tiré une roquette, ce qui signifie qu'ils ne pouvaient pas suivre sa trajectoire. Pire, ils ne réalisaient pas qu'elle changeait de direction pour revenir vers eux. Nous avons essayé d'intégrer divers éléments d'ATH et indicateurs laser, mais la plupart des joueurs n'y faisaient pas attention, car ils restaient concentrés sur l'ennemi. Nous avons effectué un maximum d'améliorations mineures : Odessa insistant sur cette fonctionnalité dans son discours, des effets audio et visuels indiquant que l'hélicoptère abat les roquettes tirées directement sur lui, etc. Si ces modifications ont bien aidé quelques playtesteurs à appréhender le système, nous ne sommes jamais arrivés au point où la plupart des joueurs semblaient l'avoir compris. Nous avons même envisagé de supprimer cette fonctionnalité, mais l'affrontement contre l'hélico aurait perdu une grande partie de son intérêt. En effet, le guidage laser force le joueur à garder l'appareil en vue pendant toute la durée de vol de la roquette, ce qui implique qu'il se trouve lui aussi dans la ligne de mire de l'hélico, et cela crée une tension que nous souhaitions conserver."
N/A3957"#commentary\cn_040_performance_constraints.mp3" "[ Eric Smith ] Pour l'ultime arène de la Côte, nous avions imaginé une conclusion grandiose, lors de laquelle le joueur aurait résisté à des vagues de soldats du Cartel aux côtés d'un groupe de citoyens avant d'affronter un hélico. Malheureusement, les coûts de calcul liés à la présence de soldats et d'alliés se déplaçant sur le terrain nous ont contraints à réduire continuellement l'envergure de l'affrontement pour rentrer dans notre budget de performances. Quand nous en sommes arrivés à n'afficher qu'une seule escouade de soldats à la fois, nous en étions déjà à un stade avancé du développement. Il était trop tard pour apporter des modifications importantes à l'arène et y accueillir plus d'ennemis, alors nous avons retravaillé le déroulement du combat pour limiter le nombre de soldats."
N/A3958"#commentary\cn_041_lighthouse_gunship.mp3" "[ Ido Magal ] Il a fallu beaucoup de travail pour que cette scène avec l'hélico se déroule comme dans un film, conformément à ce que nous avions imaginé. Dans un film, l'appareil anticiperait les déplacements du protagoniste, tirant à travers les fenêtres à mesure que celui-ci gravirait le phare. Pour simuler cette anticipation dans le jeu, nous avons mis en place une série complexe de déclencheurs le long de l'escalier. Lorsqu'ils repèrent le joueur montant les marches, ils informent l'hélico qui choisit une nouvelle trajectoire de vol en fonction de l'altitude du joueur. Les déclencheurs activent également des cibles sur les fenêtres les plus proches du joueur (des objets invisibles que l'I.A. ennemie identifie immédiatement comme hostiles) et ordonnent à l'hélico de tirer sur les fenêtres. Ce mélange d'I.A. et de scripts est un élément central des scénarios de combat de Half-Life. L'I.A. se charge du comportement général et adaptatif des PNJ, tandis que les scripts personnalisent les exigences particulières de chaque scénario."
N/A3959"#commentary\cn_042_crane.mp3" "[ Jakob Jungels ] Nous avons passé beaucoup de temps à peaufiner la grue pour obtenir un résultat satisfaisant. Avec les contraintes imposées par nos technologies de destruction et de physique des corps rigides, créer un élément nécessitant de générer autant de force physique était forcément hasardeux. Par exemple, il n'y avait aucune chance pour que l'aimant réponde pleinement aux attentes des joueurs pour un objet d'une telle masse. Cependant, la grue étant statique, nous pouvions sélectionner minutieusement les éléments à sa portée et les ajuster selon nos besoins. Heureusement, la plupart des joueurs n'ont pas semblé remarquer ces artifices, probablement parce que la possibilité d'interagir avec un tel élément dans un environnement physique vaguement réaliste était déjà une nouveauté en soi."
N/A3960"#commentary\cn_043_flashlight_power.mp3" "[ Jeff Lane ] Pour Half-Life 2, nous avons pris la décision controversée d'alimenter le sprint et la lampe torche en puisant dans l'énergie de la combinaison CEH. À l'origine, seul le sprint en consommait. C'était logique, puisqu'il ne devait être qu'une courte pointe de vitesse. La lampe torche, elle, pouvait être utilisée indéfiniment. Lors des playtests, toutefois, nous avons constaté un problème : les joueurs, consciemment ou non, quittaient souvent des zones obscures sans éteindre leur torche. Dans les zones ouvertes et éclairées, comme la Côte, notre budget de performances ne permettait pas cette utilisation continue de la lampe, et nous avons dû trouver un moyen de l'éteindre sans que le joueur intervienne. Limiter son utilisation nous paraissait une solution simple, qui avait l'avantage de renforcer la tension dans les zones sombres. Une autre question s'est alors posée : quelle ressource utiliser pour l'alimenter ? Nous avions déjà l'énergie de la combinaison, et nous ne voulions pas encombrer l'interface en ajoutant une jauge spécifique à la torche. Nous avons donc envisagé d'alimenter d'autres capacités du joueur avec la combinaison, car la perspective de devoir faire des compromis pour les utiliser nous semblait intéressante. Cet exemple illustre parfaitement le fait que le game design consiste régulièrement à choisir entre plusieurs solutions imparfaites. Nous n'aimions pas l'idée que le sprint et la lampe torche partagent une même ressource, mais nous ne voulions pas en créer d'autres et encombrer l'interface. Dans l'Épisode 2, n'ayant aucune intention d'ajouter d'autres capacités puisant dans l'énergie de la combinaison, nous avons finalement décidé d'offrir à la torche sa propre source d'alimentation."
N/A3961"#commentary\cn_044_open_world_loot.mp3" "[ Jeff Lane ] Le niveau de la Côte étant un espace ouvert, un nouveau problème s'est posé : comment répartir le matériel à donner aux joueurs ? Dans un jeu Half-Life, nous récompensons généralement l'exploration. Si vous distinguez le chemin à emprunter pour progresser, mais remarquez quelque chose sur le côté, prenez le temps de fouiller l'endroit et vous trouverez certainement quelque chose d'intéressant. Pour les premiers playtests des cartes de la Côte, nous avions placé les récompenses dans des recoins extérieurs, mais cela nuisait à l'expérience de pilotage du buggy. Il y avait tant d'espaces ouverts qu'un grand nombre de petites zones semblaient susceptibles de contenir du butin, et les joueurs s'arrêtaient sans cesse pour descendre du véhicule et les explorer. Le niveau en devenait pénible, alors nous avons supprimé ces récompenses éparpillées. Seulement, cela a soulevé un autre problème : comment aider les joueurs à déterminer les situations valant la peine de descendre du buggy ? Après réflexion, nous avons établi une règle : toutes les constructions humaines contiendraient des éléments de gameplay et des récompenses d'exploration, mais les zones naturelles resteraient vides. Nous ne pouvions pas le dire explicitement aux joueurs, mais cela s'alignait généralement avec leurs hypothèses naturelles, que nous avons sans cesse renforcées par le biais de zones comme celle-ci."
N/A3962"#commentary\cn_045_gas_station.mp3" "[ Jeff Lane ] Nous avions de grands projets pour ce combat. Nous voulions construire une station-service dont les pompes pourraient prendre feu au cœur de l'action et enflammer le reste des bâtiments. Nous imaginions le joueur s'éloignant de l'incendie au volant de son buggy. Mais en 2003, les contraintes de budget et de performances étaient rudes, et nous avons dû sans cesse simplifier la station-service pour l'adapter aux vastes niveaux de la Côte. Nos projets de création d'un système de feu dynamique n'ont jamais vu le jour, et le construire n'avait plus d'intérêt. Il y a toujours une limite à la quantité de travail justifiable pour un seul combat. Au final, les seuls vestiges de notre vision initiale sont les pompes à essence explosives."
N/A3963"#commentary\cn_046_buggy_introduction.mp3" "[ John Cook ] Nous voulions présenter le buggy de manière plus intéressante qu'en laissant simplement le joueur monter à bord et partir avec. La séquence de la grue nous a permis d'atteindre cet objectif, ainsi qu'un autre encore plus important : apprendre au joueur à remettre le véhicule sur ses roues lorsqu'il se retourne. Il est toujours délicat de s'entraîner sous la pression, mais nous voulions insister sur le danger que représente l'invasion de fourmis-lions pour souligner l'importance de rester dans le buggy. Nous avons donc entretenu cette menace et ajouté quelques citoyens sur les mitrailleuses pour venir en aide au joueur. Petit bonus : grâce à cette séquence, le joueur fait l'expérience d'être soulevé par une grue juste avant d'avoir à en manœuvrer une."
N/A3964"#commentary\cn_047_crossbow.mp3" "[ John Cook ] Le joueur a ici une première occasion d'obtenir l'arbalète, et avec le recul, il est étonnant que nous n'ayons pas fait de son obtention un prérequis pour quitter la zone, car il est tout à fait possible de passer à côté. Afin de réduire les probabilités que cela arrive, nous avons mis en place le barrage et le point d'observation pour encourager les joueurs à sortir du buggy, ce qui augmente leurs chances de repérer l'arbalète et la caisse de munitions. Lors des playtests, quasiment tous les joueurs se sont arrêtés pour ramasser l'arme, mais il s'agit d'une situation où la différence entre un playtest et une véritable partie peut être cruciale. Un playtesteur qui joue depuis le début de la Côte sera vraisemblablement moins lassé par l'exploration qu'une personne jouant depuis le début du jeu. Nous avons donc décidé de placer une deuxième arbalète quelques niveaux plus tard, à Nova Prospekt, directement sur le chemin du joueur."
N/A3965"#commentary\cn_048_rollermines.mp3" "[ Josh Weier ] Nous avons créé les lamineurs car nous avions besoin d'un ennemi capable de menacer le joueur lorsqu'il se trouve au volant du buggy. Le joueur dans le buggy étant une entité entièrement simulée physiquement, nous aimions l'idée de lui opposer un ennemi qui le serait également. L'exemple du robot-lame avait déjà prouvé que cette approche pouvait engendrer des ennemis créant de multiples interactions intéressantes. Nous avons donc conçu le lamineur, une boule dont les déplacements sont intégralement provoqués par le couple qu'elle génère sur elle-même, et avons ajusté son comportement jusqu'à ce qu'il devienne amusant de lui foncer dessus. Les lamineurs ne sont pas particulièrement dangereux pour le buggy lorsqu'ils sont seuls, mais peuvent rapidement le devenir si vous les laissez s'accumuler, surtout au bord d'une falaise. Nous avons également veillé à ce qu'ils fonctionnent correctement lorsque le joueur se déplace à pied, ce qui a permis à nos level designers de les réutiliser dans d'autres situations."
N/A3966"#commentary\cn_049_sandtrap_thumper.mp3" "[ Laura Dubuk ] Ces barils explosifs, mis à disposition des joueurs pour combattre les fourmis-lions tout en restant dans le périmètre de protection du marteleur, permettent également de préparer l'affrontement à venir contre un garde fourmi-lion, que de nombreux joueurs remportent avec une stratégie similaire. Les actions facultatives, comme le fait de lancer des explosifs avec le pistolet anti-gravité, s'oublient facilement si elles ne sont pas utilisées fréquemment. Les joueurs disposant d'un vaste éventail d'options offensives, rien ne garantit qu'ils auront utilisé celle-ci récemment. Par conséquent, nous leur suggérons subtilement d'y repenser avant d'affronter le garde."
N/A3967"#commentary\cn_050_coast_kickoff.mp3" "[ Marc Laidlaw ] Cette saynète a été ajoutée vers la fin du développement pour relier Ravenholm à la Côte. Vous remarquerez peut-être une certaine tendance : dans nos jeux, la plupart des éléments connecteurs sont créés assez tard. Dans ce cas précis, nous avons dû brûler pas mal d'étapes, au point que nous n'avons même pas eu le temps d'animer Alyx sur l'écran. Rendre ce genre de scène intéressante est toujours un défi, et ici, nous avons échoué. C'est un très bon exemple de ce qui arrive lorsque les PNJ sont traités comme de simples vecteurs de messages, qu'on ne leur confère aucune personnalité et qu'ils n'apportent rien à la scène. Il en résulte un moment oubliable, qui ne parvient pas à masquer que cette scène n'existe que pour servir de transition entre deux zones du jeu. Mais c'est un problème inhérent au développement d'un jeu : il faut faire bon usage du temps qui nous est imparti, car il est limité. Les laboratoires du Dr Kleiner et d'Eli étaient beaucoup plus importants, et c'est là que nous avons consacré notre temps et nos efforts."
N/A3968"#commentary\cn_051_odessa_cubbage.mp3" "[ Marc Laidlaw ] Le personnage d'Odessa Cubbage est un parfait exemple de caméo que nous estimons réussi. C'est un type amusant qui vit dans sa bulle, et puisqu'il ne quitte jamais son scénario, nous pouvions facilement exagérer ses traits pour qu'il se démarque. Nous avons commencé par son modèle, emprunté à une section finalement supprimée du jeu, et l'avons nommé d'après l'objet d'un spam que nous avions reçu. À l'origine, le modèle était un pêcheur norvégien, mais il ne correspondait pas vraiment au personnage anglais que nous avions en tête. Alors, nous lui avons ajouté une moustache et c'est ainsi qu'Odessa est né. En définitive, il n'est qu'un charlatan. Tout est faux, chez lui : son accent, sa moustache... Et puisqu'il ne se mettrait jamais en danger de lui-même, il est parfaitement logique qu'il confie le lance-roquettes à Gordon et lui montre comment s'en servir."
N/A3969"#commentary\cn_052_28_transitions_later.mp3" "[ Marc Laidlaw ] Après avoir relié plusieurs niveaux à l'aide de tunnels obscurs faisant office d'espaces de transition, nous nous sommes rendu compte que nous pouvions jouer avec les attentes des joueurs en intégrant un autre tunnel qui aurait l'apparence d'une transition, mais qui renfermerait en réalité autre chose. Comme tout le monde, nous avions vu 28 jours plus tard en 2002 et l'avions adoré. Nous avons tout de suite voulu créer un affrontement intense avec des zombies dans l'un de nos tunnels. Nous l'avons rapidement mis en place et nous étions satisfaits du résultat. Des années plus tard, nous avons rencontré Alex Garland, le scénariste du film. Puisqu'il avait joué à Half-Life 2 et aimé le jeu, nous lui avons avoué que son œuvre avait inspiré cette section."
N/A3970"#commentary\cn_053_finest_mind_of_his_generation.mp3" "[ Marc Laidlaw ] Voici une autre saynète que nous trouvons assez réussie. Nous n'avions ici qu'un seul objectif : apprendre au joueur à ne pas marcher sur le sable. En concevant les scènes précédentes, nous cherchions principalement à les rendre fonctionnelles, mais au moment de réaliser celle-ci, nous étions plus à l'aise et commencions à apprécier le fait d'y réfléchir un peu plus. Cela nous permettait de traiter les personnages comme des individus, et non de simples vecteurs de messages, et de créer des situations plus intéressantes et divertissantes. Après la sortie du jeu, Laszlo a gagné un nombre de fans hors du commun. Comme quoi, il est extrêmement difficile de prédire ce qui retiendra l'attention des joueurs."
N/A3971"#commentary\cn_054_bridge_playtesting.mp3" "[ Matt Boone ] Lors des playtests, la séquence du pont était toujours un moment fort, car elle provoquait systématiquement de vives réactions parmi les joueurs. La tension qu'ils ressentaient en progressant lentement sur les poutrelles était visible dans leurs mouvements. Avec le temps, nous avons intégré d'autres épreuves à la traversée, et observer les playtests est devenu encore plus divertissant : le passage d'un train sur le pont, faisant trembler le joueur, le crabe de tête occupant la cabane à mi-chemin, qui semblait pourtant être un refuge... Nous nous sentions un peu coupables d'apprécier ainsi leur stress manifeste, mais nous n'étions pas des monstres : après avoir traversé le pont, les playtesteurs poussaient un soupir de soulagement, désactivaient le bouclier du Cartel, puis réalisaient qu'ils allaient devoir retraverser en sens inverse. Afin qu'ils ne s'ennuient pas lors de ce deuxième trajet, nous avons ajouté un hélico pour leur tenir compagnie sur les poutrelles."
N/A3972"#commentary\cn_055_thumper_final_stage.mp3" "[ Matt Boone ] Nous aimions beaucoup la dernière phase des marteleurs, où leur utilisation doit être inversée. Ils ne servent plus d'outil pour se mettre en sécurité, mais de bloqueurs pour l'armée de fourmis-lions du joueur. En revanche, nous aurions probablement dû intégrer une initiation plus complète avant d'atteindre cette zone. Il était tout à fait acceptable que les joueurs n'aient qu'une compréhension partielle des marteleurs dans les niveaux précédents, sur la Côte, mais désormais, les enjeux sont plus importants, car ils doivent également essayer les appâts pour la première fois. Les joueurs qui ne se rendent pas compte que ce premier marteleur empêche leurs fourmis-lions d'avancer risquent également de mal comprendre le fonctionnement des appâts. S'ils en lancent un sur les soldats du premier bunker et qu'aucune fourmi-lion n'apparaît, ils pourraient en conclure que l'outil n'est pas fiable ou ne fonctionne pas comme prévu, et décident d'utiliser leurs armes habituelles."
N/A3973"#commentary\cn_056_buggy_tools.mp3" "[ Matt Wright ] Pour que le buggy ne soit pas uniquement un moyen de transport, nous avons décidé de fixer un canon Tau, une arme de Half-Life 1 que nous aimions, mais que nous n'avions pas réussi à réutiliser dans Half-Life 2. Nous avons limité sa présence à la Côte, car le canon Tau peut tirer à travers les murs, et que cette fonctionnalité rend la conception de niveau beaucoup plus délicate. À l'arrière du buggy, nous avons également mis à disposition du joueur une caisse de munitions illimitées. Un ajout particulièrement apprécié par certains playtesteurs que les fourmis-lions surgissant du sable à l'infini mettaient en difficulté."
N/A3974"#commentary\cn_057_antlion_guard.mp3" "[ Matt Wright ] Dans de rares cas, les joueurs pouvaient se retrouver dans l'impossibilité de tuer le garde fourmi-lion. Cela arrivait notamment lorsqu'ils tombaient à court de munitions et, ayant mal utilisé les objets physiques placés dans l'arène, n'avaient plus rien à lancer avec le pistolet anti-gravité. Pour y remédier, nous avons affecté un citoyen à la tourelle montée au-dessus de la porte. En dernier recours, si le joueur est coincé dans l'arène, il peut compter sur lui pour abattre le garde."
N/A3975"#commentary\cn_058_terrain_and_performance.mp3" "[ Mike Dussault ] Notre budget de performances représentait généralement une contrainte pour les combats, et plus particulièrement sur les terrains en relief. Lorsqu'un PNJ se déplace, il effectue une multitude de petites sondes spatiales pour déterminer sa capacité à emprunter un itinéraire (imaginez une personne aveugle agitant constamment sa canne devant elle pour vérifier que la voie est libre). Évidemment, le coût en performances de ces sondes augmente avec la complexité de la géométrie du monde. Pour créer des surfaces irrégulières, notre système de terrain utilise un grand nombre de polygones, bien plus que pour les sols parfaitement plats qu'on peut trouver ailleurs. Cela signifie que les déplacements des PNJ consommaient davantage de ressources sur la Côte que dans d'autres zones. Cette contrainte, naturellement, a conditionné l'échelle d'un certain nombre d'affrontements dans cette partie du jeu."
N/A3976"#commentary\cn_059_area_portals.mp3" "[ Mike Dussault ] Sur la Côte, le traitement des vastes espaces ouverts comprenant des bâtiments aux intérieurs hautement détaillés (du moins selon les standards de 2003) présentait un autre défi en termes de performances. Lorsque le joueur évoluait à l'extérieur, nous voulions affecter un maximum de budget au rendu de cet espace sans gaspiller de ressources à calculer ce qui se trouvait dans les bâtiments. Seulement, à moins d'en murer tous les accès, le joueur pouvait toujours voir à l'intérieur. Pour y remédier, nous avons créé les \"Area Portals\", qui permettent de précalculer une image plate représentant l'intérieur d'un bâtiment, et en avons placé un sur chaque fenêtre ou porte ouverte. Dans le jeu, lorsque le joueur se trouve à une certaine distance, l'Area Portal affiche cette image sur l'ouverture qu'il recouvre, ce qui nous dispense d'effectuer le rendu de l'intérieur. Quand il s'approche, nous procédons à une transition fluide entre l'image de l'Area Portal et le véritable contenu de la pièce. L'utilisation minutieuse des Area Portas (et, occasionnellement, de portes qui se ferment toutes seules derrière vous), nous a permis d'atteindre nos objectifs de performances."
N/A3977"#commentary\cn_060_buggy_removal.mp3" "[ Miles Estes ] Lorsque nous avons atteint le point où nous voulions que le joueur abandonne le buggy, il a fallu le signaler très explicitement. Tout au long du niveau, on ne cesse de quitter le véhicule pour y revenir un peu plus tard, et nous avons constaté que les playtesteurs essayaient de le conserver dès qu'ils pensaient que c'était possible. Cette courte scène du garage existe principalement pour signifier clairement au joueur que le reste du trajet se fera à pied."
N/A3978"#commentary\cn_061_d2_coast_04.mp3" "[ Randy Lundeen ] Cette carte est la toute première zone que nous avons créée pour la Côte, avant même d'imaginer la grue et les autres éléments. Ce bras de mer asséché et les bateaux rouillés étaient parmi les premiers éléments de direction artistique que nous avons développés. Des années plus tard, nous avons présenté la carte lors de notre démonstration à l'E3 2003, mais le gameplay était encore en cours d'élaboration. Par conséquent, lorsque nous avons commencé à concevoir le reste de la section côtière, cette démo nous a servi de vision sur laquelle baser notre travail."
N/A3979"#commentary\cn_062_transition_tunnels.mp3" "[ Randy Lundeen ] Pour la conception de la Côte, nous avons dû développer un nouveau moyen d'assurer les transitions entre les niveaux. Pour passer d'un endroit à un autre, nous devons tout sauvegarder dans l'espace de transition lorsque le joueur quitte le premier niveau, puis le restaurer dans le niveau suivant après le chargement. Il est également essentiel que nous sauvegardions et restaurions tous les éléments visibles par le joueur dans la zone de transition, même s'ils se trouvent hors de celle-ci. C'est pourquoi nous concevions des espaces de transition aussi petits et fermés que possible. La plupart du temps, une petite pièce faisait parfaitement l'affaire, mais sur la Côte, nous avons dû trouver une autre solution. Après quelques expérimentations, nous avons arrêté notre choix sur des tunnels sombres. En partie parce qu'ils étaient réutilisables de manière crédible, mais aussi parce que nous pouvions ajouter une lumière éclatante à leur extrémité et ainsi dissimuler notre incapacité à effectuer le rendu de ce qui se trouvait au-delà, puisque ces éléments existaient dans un niveau complètement différent."
N/A3980"#commentary\cn_063_sniper_alley.mp3" "[ Robin Walker ] Cette section du jeu a été ajoutée à un stade avancé du développement, après que nous avons décidé de vous faire passer par le laboratoire d'Eli et Ravenholm avant d'arriver sur la Côte. Contrairement à ce que vous pourriez imaginer, nous n'avons pas construit le jeu de manière linéaire. Nous avons formé trois groupes pour travailler en parallèle sur différentes sections, en commençant par le milieu du jeu. Chaque groupe s'est d'abord concentré sur les éléments principaux de sa section avant de passer à la suite. Plus tard, une fois que nous disposions d'une version brute du jeu entier, nous avons retravaillé chaque section pour les peaufiner, en ajoutant des éléments ayant fait leurs preuves dans d'autres parties du jeu et en supprimant ceux qui ne fonctionnaient pas. Nous avons parfois déplacé des sections entières. C'est notamment le cas de Ravenholm, que nous avons ensuite dû relier à la Côte à l'aide d'une nouvelle zone, dans laquelle vous venez d'arriver. Limités par des contraintes de calendrier, nous avons conçu cette courte section à partir d'éléments de gameplay déjà éprouvés, comme les snipers et les soldats du Cartel."
N/A3981"#commentary\cn_064_battery_finding.mp3" "[ Robin Walker ] Les espaces de jeu de Half-Life 2 présentant une grande densité d'objets, nous pensions qu'il serait intéressant de demander aux joueurs d'en chercher un spécifique, surtout si son emplacement découlait d'une certaine logique. Ainsi, les joueurs avaient le choix entre observer attentivement la zone pour déduire la position de l'objet, ou la fouiller méthodiquement jusqu'à tomber dessus. Puisque nous disposions déjà de modèles de voitures et de batteries, créer une petite casse que les joueurs pourraient explorer nous semblait naturel. Nous avons également caché quelques batteries dans des endroits inattendus à destination des joueurs optant pour la fouille méthodique (parfois plus brutale). Comme toute énigme reposant sur des objets, celle-ci nécessitait un mécanisme de secours au cas où les joueurs perdraient les batteries. Vous pouvez essayer de les jeter toutes du haut de la falaise pour voir ce qui se passe."
N/A3982"#commentary\cn_065_boathouse.mp3" "[ Scott Dalton ] Dans Half-Life 1, nous avions découvert que l'intégration de scénarios présentant des combats entre des ennemis différents pouvait être intéressante. Une telle situation est non seulement amusante à observer, mais il est également bien plus facile d'étudier le comportement d'un ennemi lorsqu'il ne vous prend pas pour cible. Ce premier affrontement entre fourmis-lions et soldats du Cartel a été conçu pour permettre au joueur de foncer dans les ennemis avec le buggy, mais il sert également à présenter le marteleur. En montrant les soldats s'en servir pour repousser les fourmis-lions, nous espérions que les joueurs en comprendraient l'utilité. Nous étions satisfaits de la manière dont les soldats mettent en valeur l'importance de rester à proximité du marteleur lorsqu'ils combattent les créatures extraterrestres."
N/A3983"#commentary\cn_066_buggy_theft.mp3" "[ Scott Dalton ] Alors que nous terminions la conception de la Côte, nous avons décidé d'envoyer le Cartel voler le buggy du joueur. Aucune raison logique ne justifie cela, mais après avoir observé tant de playtesteurs développer un fort attachement à leur véhicule, nous voulions jouer avec ce lien émotionnel. Après avoir ajouté cet événement, nous avons vu des joueurs insulter le Cartel pour avoir volé leur buggy, ce que nous avons perçu comme un signe de réussite. Le soldat tirant depuis le haut de la falaise sert uniquement à faire lever les yeux au joueur, dont le regard déclenche l'apparition du vaisseau emportant le buggy. Quand on y repense, 20 ans plus tard, nous sommes frappés par le ridicule de cette situation."
N/A3984"#commentary\cn_067_snipers.mp3" "[ Ted Backman ] L'équipe de développement de Half-Life 2 n'ayant jamais été très fournie, nous cherchions constamment à créer du nouveau gameplay sans faire exploser le budget alloué à la production d'assets. Le sniper en est un parfait exemple. Il s'agit d'un simple rayon laser qui n'est associé à aucun modèle, et n'a donc nécessité aucun travail artistique ou d'animation. Lorsqu'il meurt, un corps de soldat du Cartel apparaît et tombe par la fenêtre. Malgré cette simplicité, nous en avons tiré beaucoup de gameplay unique. Nous étions particulièrement satisfaits de son interaction avec les objets physiques du jeu. Les joueurs étant habitués à exploiter les objets explosifs proches des ennemis, il nous paraissait approprié d'introduire un ennemi capable d'inverser cette dynamique lorsque les joueurs se mettent à couvert."
N/A3985"#commentary\cn_068_buggy_model.mp3" "[ Ted Backman ] Le modèle du buggy a connu de nombreuses variantes avant que nous n'obtenions une version finale satisfaisante. Nous avons essayé plusieurs designs répondant aussi bien à nos envies artistiques qu'à nos besoins de simulation physique, mais nous avons dû faire face à un problème inattendu : de nombreux testeurs, même parmi les joueurs de FPS aguerris, souffraient de cinétose en le pilotant. Après quelques ajustements de la simulation, nous avons découvert que modifier l'apparence du modèle permettait de réduire cette gêne. Plus le modèle masquait l'environnement, plus le mal des transports se faisait ressentir. Nous avons donc commencé à l'épurer, enlevant des pièces de carrosserie une par une jusqu'à ce que les joueurs cessent de se sentir malades. Nous avons notamment remarqué une différence de taille lorsque nous avons retiré des morceaux du châssis pour laisser la possibilité de voir le sol."
N/A3986"#commentary\cn_069_antlion_design.mp3" "[ Ted Backman ] Dans nos premiers travaux conceptuels pour Half-Life 2, nous avions prévu de créer plusieurs races extraterrestres, le Cartel n'étant que l'une d'entre elles. Les fourmis-lions faisaient partie d'une autre espèce insectoïde religieuse. Plus tard, lorsque nous avons développé la Côte, nous avons commencé à les voir davantage comme des nuisibles arrivés sur Terre en empruntant les portails de Xen, comme les crabes de tête et d'autres créatures. Ils ne sont pas originaires de Xen, mais lorsqu'ils s'introduisent sur un monde, ils en infestent chaque recoin tels des cafards."
N/A3987"#commentary\cn_070_explosive_barrels.mp3" "[ Brian Jacobson ] Ici, nous présentons notre vision de cet élément incontournable du FPS qu'est le baril explosif : le deuxième tir de pistolet met le feu au baril, provoquant une détonation à retardement, tandis que le troisième tir le fait exploser instantanément. Vous pouvez ainsi décider du moment de l'explosion en fonction de la situation. Certains joueurs, par exemple, peuvent se débarrasser rapidement d'un groupe de bernacles en lançant un baril vers l'un d'entre eux avant de tirer deux fois dessus. L'explosion à retardement permet également de créer des réactions en chaîne avec plusieurs barils. Les fans de la série ne sont d'ailleurs pas les seuls à apprécier cette mécanique ; nos level designers ont adoré en placer un peu partout."
N/A3988"#commentary\cn_071_ragdoll_magnets.mp3" "[ Dario Casali ] Grâce au moteur physique de Half-Life 2, nous avons pu utiliser de nombreux outils pour rendre les combats plus palpitants. Par exemple, lorsque les tirs ennemis passent à côté du joueur, nous les redirigeons discrètement vers des objets destructibles à proximité, ce qui ajoute au chaos et renforce le sentiment d'être au cœur de l'action. Nous avons également profité de la physique pour ajouter des indices et créer ce que nous appelons des \"aimants à ragdoll\", disséminés tout au long du jeu pour que les corps des ennemis chutent de manière intéressante et spectaculaire, en tombant d'un rebord ou devant un train, par exemple."
N/A3989"#commentary\cn_072_helicopter_peekaboo.mp3" "[ Dave Riller ] Nous avons voulu développer la présence de l'hélicoptère d'attaque du Cartel tout au long de ce chapitre pour en faire un antagoniste central, si bien qu'il est devenu un personnage à part entière. Ici, si vous écoutez bien et regardez vers le ciel, vous pouvez entendre son moteur et le voir survoler les rails avant de disparaître au loin. Cette première apparition offre un léger aperçu de ce qui va suivre, puisque cet hélico implacable va devenir de plus en plus présent jusqu'au moment où vous allez devoir l'affronter."
N/A3990"#commentary\cn_073_iterative_passes.mp3" "[ David Speyrer ] Certains chapitres du jeu, comme les sections des Canaux et de Ravenholm que vous devez traverser à pied, ont été développés en plusieurs passes par différents groupes de conception. Nous avons constaté que cette manière de faire favorisait la diversité de l'expérience et la densité de moments intéressants, chaque groupe apportant ses propres touches. Pour la séquence à pied dans les canaux, la première passe a établi la direction artistique et l'itinéraire du joueur, ainsi que les grandes lignes de l'expérience et quelques temps forts. Il est cependant ressorti du playtest de l'Alpha, impliquant toute l'équipe, que l'expérience manquait de tension et était trop monotone. Dans notre seconde passe, nous avons retravaillé cette carte en cherchant exclusivement à créer cette tension et à augmenter grandement la densité d'actions."
N/A3991"#commentary\cn_075_pistol_design.mp3" "[ Josh Weier ] Le pistolet standard est un véritable pilier du gameplay : il s'agit non seulement de la première arme à distance que le joueur apprend à utiliser, mais également d'un moyen d'interagir avec la physique et les objets destructibles en toute sécurité pendant l'intégralité du jeu. Afin de rendre son utilisation plus réactive et amusante, le pistolet bénéficie d'une mécanique de cadence de tir unique liée à la vitesse de clic du joueur. Ainsi, chaque pression de la commande de tir provoque une réponse instantanée, et plus le joueur est capable d'appuyer rapidement, plus il pourra tirer vite."
N/A3992"#commentary\cn_076_shatterglass.mp3" "[ Josh Weier ] En concevant les premiers niveaux, où les mécaniques à la disposition du joueur sont moins nombreuses, nous avons constaté que c'était le moment idéal pour mettre en lumière les nouvelles fonctionnalités techniques, comme c'est le cas ici avec le verre cassable. Pour obtenir cet effet, nous avons découpé la vitre en une grille de petits carrés, que nous pouvions différencier selon qu'ils étaient intacts ou brisés, puis casser en plus grandes sections une fois qu'un certain nombre de carrés n'étaient plus liés entre eux. Chaque carré était rendu avec une texture unique dépendant de l'état des carrés voisins, ce qui permettait de créer des bords irréguliers entre le verre intact et le verre brisé. De nos jours, le verre cassable est assez commun, mais à l'époque où nous développions Half-Life 2, c'était encore inhabituel et nous étions particulièrement ravis du degré de fidélité et de dynamisme que cela apportait au jeu."
N/A3993"#commentary\cn_077_lambda_caches.mp3" "[ Laura Dubuk ] Techniquement, la première cache lambda se situe dans le labo du Dr Kleiner, mais celle-ci est la première que le joueur trouve par lui-même. Nous avons créé les caches lambda pour encourager l'exploration et indiquer au joueur l'emplacement de ressources cachées par la Résistance dans le cadre de leur rébellion souterraine. Dans Half-Life 1, le contenu des caisses de munitions était prédéterminé par les level designers, mais pour Half-Life 2, nous avons mis en place des caisses d'objets adaptatives, qui fournissent au joueur ce dont il manque actuellement en fonction des cibles de ressources prédéfinies par les level designers."
N/A3994"#commentary\cn_078_scanners.mp3" "[ Kerry Davis ] Les scanners représentaient un véritable défi de game design. Bien que satisfaits de leur présence dystopique, traduisant l'état de surveillance oppressive impliqué par le Cartel, nous ne voulions pas qu'ils tirent sur le joueur. Nous ne pensions pas pouvoir rendre divertissant le fait de viser le ciel pour tirer sur un petit ennemi mobile ayant toujours l'avantage de la hauteur. Puisque nous adorions leur rôle narratif, nous avons décidé que les scanners seraient essentiellement les yeux du Cartel et alerteraient les ennemis proches de la présence du joueur, une fonctionnalité que nous avons renforcée par des effets sonores provenant des soldats. Au-delà de ça, ils peuvent uniquement harceler le joueur avec des lumières vives et, occasionnellement, plonger en piqué pour exploser après avoir subi une certaine quantité de dégâts."
N/A3995"#commentary\cn_079_surface_properties.mp3" "[ Ariel Diaz ] Quand le joueur marche dans la boue, on peut entendre un bruit de pas spécifique. C'est le fruit d'un système de propriétés des surfaces qui se base sur le type de matériau pour déterminer les sons et autres effets provoqués lorsqu'on marche ou que l'on tire dessus. Au début du développement, nous appliquions un effet ralentissant les déplacements du joueur lorsque celui-ci marchait sur une surface boueuse, mais nous l'avons supprimé avant la sortie du jeu car nous le trouvions trop punitif."
N/A3996"#commentary\cn_080_combat_entrances.mp3" "[ Dario Casali ] Arriver dans une nouvelle zone et y voir des ennemis attendre sans bouger est toujours un peu étrange, cela donne l'impression d'explorer un stand de tir, et non un monde vivant. Nous voulions que les ennemis entrent dans les espaces de combat de manière plus intéressante et dynamique, comme s'ils avaient un plan pour traquer Gordon et que leurs déplacements étaient organisés, intentionnels. Dans cette scène, les métroflics sautent dans la zone via des séquences scriptées, tout comme ils descendront en rappel plus tard dans le jeu. Savoir d'où ils viennent réellement n'a pas d'importance, car les joueurs s'inventeront leurs propres explications. Nous avons découvert que les combats étaient plus intéressants lorsqu'ils racontaient une histoire par leur configuration : une embuscade, une surprise, un assaut massif... Tous ces scénarios utilisent sensiblement la même I.A. pour les ennemis, mais les playtesteurs ressentaient tout de même une différence."
N/A3997"#commentary\cn_081_mounted_gun_gallery.mp3" "[ Dave Riller ] Dans cette scène, on peut remarquer plusieurs éléments intéressants : en voyant la tourelle tirer sur les caisses destructibles, on incite le joueur à ne pas foncer droit sur la menace, mais à la contourner par les égouts. Une fois qu'il a atteint la tourelle, il peut l'utiliser pour résister à une vague de soldats du Cartel et de scanners. Nous en profitons également pour introduire le véhicule blindé du Cartel qui force le joueur à avancer et qui reviendra un peu plus tard dans le chapitre."
N/A3998"#commentary\cn_082_barnacle_bowling.mp3" "[ Josh Weier ] Voici un exemple particulièrement satisfaisant de la manière dont on peut associer plusieurs éléments de design dans une matrice d'interactions afin de créer un scénario marquant pour le joueur. Ici, nous avons des bernacles, notre système de simulation physique, une surface boueuse glissante et, cerise sur le gâteau, des barils explosifs. Vous avez déjà croisé tous ces éléments séparément, mais vous pouvez désormais les associer naturellement pour créer ce moment que nous avons appelé le \"bowling des bernacles\"."
N/A3999"#commentary\cn_083_barnacle_introduction.mp3" "[ Mike Dussault ] La première rencontre avec les bernacles pouvant être assez déroutante, nous voulions que le joueur puisse étudier leur comportement depuis une distance raisonnable. Nous avons donc mis en scène ce spectacle naturel d'un prédateur capturant sa proie. Comme toujours avec ce genre de scène, de nombreuses itérations ont été nécessaires pour que le joueur en profite correctement."
N/A4000"#commentary\cn_084_physics_in_puzzles.mp3" "[ Eric Smith ] Il arrive souvent que des mécaniques simples rencontrées en début de jeu soient tirées d'autres mécaniques plus complexes pour servir d'entraînement. La première énigme du jeu se reposant sur la physique, celle de la balançoire à bascule, est en réalité une variante de celle de la machine à laver, plus élaborée, qui intervient ultérieurement dans les canaux. La balançoire utilise les mêmes principes de masse et de rampe, mais de manière plus simple. Le fait de pouvoir interagir directement avec les éléments aide le joueur à comprendre la physique du jeu et facilite la résolution des futures énigmes. Cette énigme met également en avant la nature analogique du système de physique, car sa résolution prend en compte le placement des briques de ciment et le poids du joueur."
N/A4001"#commentary\cn_085_combine_attack_helicopter.mp3" "[ Brian Jacobson ] Vous l'avez déjà aperçu plus tôt, mais c'est ici que nous introduisons officiellement le boss principal du chapitre des Canaux : l'hélicoptère d'attaque du Cartel, qui détruit sans relâche les abris du joueur et le force à avancer s'il ne veut pas être abattu. Nous voulions créer une séquence pleine de tension, avec un hélicoptère bien trop puissant pour une confrontation directe, et conserver cette intensité pendant toute la traversée des canaux jusqu'à l'affrontement final dans le réservoir. Pour y parvenir, nous avons fortement limité les déplacements de l'hélicoptère en fonction d'objectifs de gameplay spécifiques. Sur cette carte, où le joueur doit courir d'un abri à l'autre sous les tirs nourris de l'hélico, nous avons créé un itinéraire prenant la forme d'un anneau dans le ciel. L'hélicoptère se déplace toujours jusqu'au point de cet anneau le plus éloigné du joueur tout en restant visible, ce qui nous a facilité la tâche pour placer précisément des abris aux endroits opportuns."
N/A4002"#commentary\cn_087_explosive_barrel_factory.mp3" "[ David Speyrer ] Cette salle, remplie d'un nombre absurde de barils explosifs, a suscité au sein de l'équipe un petit débat sur la plausibilité de notre monde. Honnêtement, si l'on cherche du réalisme, un seul baril explosif est probablement déjà un de trop. Dans le monde réel, les barils ne sont pas censés exploser, même si vous leur tirez dessus."
N/A4003"#commentary\cn_088_rising_water.mp3" "[ Dhabih Eng ] Dans cette salle, le pont flottant et les bobines en bois permettent de présenter le concept de flottabilité en tant qu'élément utile pour le joueur. Ici, il ne s'agit pas tant d'une énigme que d'un moyen amusant pour le joueur d'interagir avec le moteur physique, mais nous revisiterons cet élément de gameplay ultérieurement dans les canaux afin de lever une rampe pour l'hydroglisseur."
N/A4004"#commentary\cn_089_manhack_matt.mp3" "[ John Morello ] Nous avons surnommé cet homme \"Manhack Matt\" (Matt aux robots-lames). Nous voulions donner aux joueurs l'impression que des centaines de citoyens vivent cachés dans les recoins de Cité 17. Lorsqu'il arrive ici, le joueur n'a plus croisé de citoyen depuis un moment, et nous voulions expliquer l'importance du robot-lame, le premier ennemi reposant sur la physique que nous avions créé. Dans le concept initial, nous avions imaginé une salle d'arcade dans laquelle les joueurs pouvaient piloter des robots-lames et attaquer des citoyens virtuels. Plus tard, ils découvriraient que les robots-lames étaient réels, tout comme les citoyens. Au fur et à mesure, nous avons davantage détaillé l'occupation du Cartel et l'idée d'une salle d'arcade ne collait plus vraiment, alors nous avons fait le choix de la supprimer."
N/A4005"#commentary\cn_090_fighting_motion_sickness.mp3" "[ David Speyrer ] Lors des premiers playtests, de nombreux joueurs ont souffert de cinétose, ou mal des transports, en pilotant l'hydroglisseur. Nous avons découvert plusieurs facteurs contribuant à résoudre ce problème, comme limiter l'intrusion du véhicule dans le champ de vision, ce qui nous a conduits à retravailler le modèle pour le réduire à l'essentiel. Une fréquence d'images constante était également très utile, il nous a donc fallu garder un œil sur les performances durant ces passages. Le plus important, toutefois, était d'éliminer le roulis afin de stabiliser l'horizon quelle que soit la position de l'hydroglisseur. L'un de nos programmeurs, particulièrement sujet à la cinétose, s'est courageusement proposé pour effectuer plusieurs playtests afin d'évaluer notre progression. Je suis presque certain que cette personne a vomi au moins une fois après une session de playtest, et nous lui sommes extrêmement reconnaissants pour son noble sacrifice."
N/A4006"#commentary\cn_091_headcrab_canisters.mp3" "[ Jeff Lane ] Plus tard, à Ravenholm, on peut voir des bombes à crabes de tête usagées. Nous avons donc décidé de les faire apparaître ici pour présenter la manière dont ils sont utilisés par le Cartel. Pour faire court, le Cartel a transformé la faune de Xen en armes contre les humains. Des crabes de tête enfouis ont été ajoutés à cette section, développée en une zone plus vaste, pour montrer un bidonville dans lequel les citoyens ont été décimés par une attaque de monstres."
N/A4007"#commentary\cn_092_airboat_intro.mp3" "[ John Morello ] Le joueur découvre ici l'hydroglisseur, le premier véhicule du jeu. Nous voulions créer une zone sans danger, dans laquelle les joueurs pourraient s'entraîner à piloter l'hydroglisseur aussi longtemps qu'ils le souhaiteraient. L'arène est parsemée d'éléments permettant d'effectuer des sauts ou des figures et nous l'avons remplie de substance toxique pour encourager les joueurs à rester à bord du véhicule tout en les empêchant de l'abandonner pour continuer à pied."
N/A4008"#commentary\cn_093_zombie_surprise.mp3" "[ Jeff Lane ] Cette canalisation vous réserve une surprise un peu taquine. Les joueurs s'aventurent dans l'obscurité, concentrés et curieux, quand un zombie sort soudainement de l'eau ! La plupart des testeurs se sont fait avoir, et l'un d'eux en est littéralement tombé de sa chaise. Pour nous, c'était un véritable succès."
N/A4009"#commentary\cn_094_airboat_time.mp3" "[ Dave Riller ] Trouver le juste équilibre entre le temps passé dans les véhicules et à pied nous a demandé un peu de travail. Les joueurs conduisant à toute vitesse traversaient le monde rapidement, et dans les premiers playtests, nous avions le sentiment qu'ils rataient des occasions d'explorer et de s'intéresser aux détails du jeu. L'exploration et l'observation de l'environnement sont des valeurs essentielles de Half-Life, et nous ne voulions pas que la présence des véhicules modifie cet aspect du jeu. Nous avons donc ajouté régulièrement des endroits où les joueurs peuvent s'arrêter pour explorer de petites zones riches en détails divers. De plus, à mesure que notre moteur physique évoluait, nous avons exploité de nouvelles manières de l'utiliser. Ces petites pauses sur le chemin de l'hydroglisseur nous ont permis d'introduire des découvertes liées à la physique, comme le fait de jeter des caisses dans l'eau ou de rassembler des barils pour surélever une rampe. Ainsi, les joueurs avaient l'occasion d'interagir avec l'eau et la physique de manières inédites."
N/A4010"#commentary\cn_095_floating_supplies.mp3" "[ Josh Weir ] Lors des playtests de l'Alpha, les canaux étaient parsemés de caisses flottantes que les joueurs pouvaient détruire avec l'hydroglisseur pour ramasser le matériel qu'elles contenaient. La mécanique, assez peu réaliste, fluidifiait malgré tout le gameplay en permettant de se réapprovisionner sans s'arrêter. Nous voulions rendre ce principe plus plausible en expliquant que ces caisses, idéalement placées sur le chemin du joueur, n'étaient pas là par hasard. Cette scène montrant des citoyens jetant des caisses de matériel depuis un pont renforce la crédibilité de cette mécanique tout en rendant les canaux plus vivants. Voir tant de personnages chercher à les aider procurait également aux joueurs un sentiment d'importance et d'héroïsme."
N/A4011"#commentary\cn_096_grenade_intro.mp3" "[ Brian Jacobson ] Nous avons conçu cette base du Cartel comme un terrain d'entraînement ludique consacré à l'utilisation des grenades, que nous présentons ici dans des caisses de munitions inépuisables pour indiquer au joueur qu'il peut les lancer librement sans craindre d'en manquer. Lors du combat, tout est fait pour que l'I.A. des soldats cherche à se mettre à couvert afin d'offrir au joueur des opportunités d'utiliser les grenades. À la fin de la zone, cette même technique de grenades inépuisables permettra de se débarrasser d'une tourelle beaucoup plus facilement qu'en passant par un assaut frontal. Nous avons ajouté une lumière rouge et une traînée de particules aux grenades, tant pour aider les joueurs à suivre la trajectoire de leurs projectiles qu'à esquiver ceux lancés par les soldats du Cartel."
N/A4012"#commentary\cn_097_puzzle_layers.mp3" "[ Dave Riller ] La plupart des joueurs ignorant totalement les intentions des game designers (ce qui nous semble être une bonne chose), ils ont tendance à réagir de manière surprenante à nos énigmes. Même celles qui paraissent toutes simples peuvent occasionner d'innombrables échecs avant l'épiphanie. C'était notamment le cas de cette énigme permettant d'ouvrir les portes du canal, dont la conception a nécessité l'intégration de plusieurs couches d'indices. Les étincelles qui jaillissent du volant de manœuvre indiquent que la méthode d'ouverture classique ne fonctionne plus, et qu'il va falloir en trouver une autre. Quelques corbeaux attirent le regard du joueur vers la solution, à savoir un assemblage de poutres sur un balancier. Les grenades ayant été présentées juste avant, nous voulions initialement que le joueur en lance une pour détruire la structure en bois soutenant le tout, mais ce n'était pas assez évident. Nous avons donc ajouté un indice beaucoup plus flagrant sous la forme de barils explosifs. Cependant, même après avoir résolu l'énigme, certains joueurs ne se rendaient pas compte que les portes étaient désormais ouvertes, et ils erraient sans fin à l'intérieur de la base à la recherche d'une sortie qui n'existait pas. Afin de leur rappeler le problème original, nous avons ajouté de la fumée, une alarme et une lumière tournoyante au niveau de la porte cassée. Avec tout ça, nous avons enfin commencé à constater des résultats satisfaisants lors des playtests."
N/A4013"#commentary\cn_098_metrocop_strafing.mp3" "[ Doug Wood ] Le design initial des niveaux mettant en scène l'hydroglisseur impliquait de réussir des manœuvres serrées sous la pression des métroflics, dont le mitraillage constant avait pour but d'inciter les joueurs à slalomer entre les tirs à pleine vitesse. Cependant, au cours de notre processus d'évaluation (appelé \"Overwatch\" en interne), certains playtesteurs ressentaient de la frustration à force de se faire tirer dessus sans pouvoir répliquer. Ils voulaient que l'hydroglisseur procure un sentiment de puissance inarrêtable. Prenant en compte ces retours, nous avons retravaillé ces niveaux pour accentuer la notion de puissance plutôt que la difficulté, laissant de côté le gameplay à base d'esquive pour un rythme de combat effréné, de la vitesse et des barricades à faire exploser."
N/A4014"#commentary\cn_100_mounted_gun.mp3" "[ Jeff Lane ] Nous avons ajouté des fusils d'assaut fixes à cet endroit pour permettre aux joueurs d'en constater l'efficacité contre l'hélicoptère d'attaque avant l'affrontement final dans le réservoir. Jusque là, l'hélico était invulnérable, et nous voulions suggérer aux joueurs qu'ils ne pourraient riposter qu'en utilisant des armes plus lourdes. Lors des playtests, cette solution s'est révélée d'une efficacité toute relative, car il s'agit d'une séquence sous haute pression. Nous avons donc développé des effets de particules et sonores pour mettre en évidence les dégâts subis par l'hélicoptère."
N/A4015"#commentary\cn_101_357_intro.mp3" "[ Josh Weier ] Bien plus lente que celle du simple pistolet, la cadence de tir du Magnum appelle à une utilisation plus mesurée et calculée, mais infligeant des dégâts considérables à la cible. Les premières versions de cette arme comportaient une dispersion aléatoire mineure, que nous estimions convenir au poids et à la gâchette moins sensible d'un revolver plus puissant. Cependant, cela entraînait parfois des situations frustrantes quand des joueurs, ayant pourtant pris soin d'aligner leur tir, rataient leur cible à cause de ce malus de précision. Pour y remédier, nous avons accordé à la première balle une précision absolue, qui diminue à chaque tir à mesure que vous videz votre chargeur."
N/A4016"#commentary\cn_102_helicopter_bombing_run.mp3" "[ Brian Jacobson ] Voici un autre exemple de création d'obstacles lors de la conduite de l'hydroglisseur. L'hélicoptère cherche à rester devant le joueur pour larguer des bombes, mais si ce dernier s'arrête ou fait demi-tour, il passe en vol stationnaire et commence à lui tirer directement dessus. Lors d'un playtest, une bombe est tombée par hasard pile dans l'espace entre deux tuyaux, ce qui a donné lieu à un beau moment cinématique. Le playtesteur concerné ayant réagi positivement, nous avons décidé de scripter cet événement pour qu'il survienne à chaque fois. Cette méthode a pleinement intégré notre processus de conception organique : de temps en temps, il se passe un truc cool pendant un playtest et nous trouvons un moyen pour qu'il se produise plus fréquemment."
N/A4017"#commentary\cn_103_smokestack_collapse.mp3" "[ Doug Wood ] Quand nous avons développé le jeu d'action cinématique qu'est le premier Half-Life, nous voulions produire de grandes et spectaculaires séquences de destruction, mais nous ne sommes jamais véritablement parvenus à atteindre cet objectif. Le moteur physique de Half-Life 2, qui permettait de réduire des caisses et autres petits objets en morceaux, nous a donné l'idée d'aller beaucoup plus loin : la destruction d'une grande cheminée industrielle. Nous avons donc expérimenté avec les masses jusqu'à obtenir un résultat satisfaisant, retravaillé le modèle et ajouté des tas d'effets fumigènes et sonores pour rendre le tout plus convaincant... Et voilà, nous avions notre spectaculaire séquence de destruction. Au final, elle a été rendue possible de justesse par notre moteur physique d'une manière qui paraîtrait sans doute étrange selon les critères modernes, mais qui était vraiment géniale à l'époque. Étant donné que chaque simulation aboutissait à un résultat différent, nous avons dû prendre des mesures pour éviter que la chute de débris ne vienne totalement bloquer la progression du joueur. Le succès de cette séquence nous a motivés à produire les effets de destruction physique cinématiques beaucoup plus réalistes que l'on peut voir dans l'Épisode 2."
N/A4018"#commentary\cn_104_washing_machine_puzzle.mp3" "[ David Speyrer ] Nous avons imaginé l'énigme de la machine à laver à un stade avancé du développement, après avoir constaté lors des playtests que les joueurs avaient besoin d'un temps de répit pour échapper quelques instants à la pression de l'hélicoptère. Cette variété dans le rythme permet d'accentuer les moments forts en réinitialisant l'état émotionnel du joueur et en évitant la fatigue, voire l'ennui. Cette forte réaction des joueurs à nos efforts pour faire de l'hélicoptère une véritable menace était une bonne chose, mais si nous ne faisions rien pour gérer la pression, la lassitude risquait de s'installer et de transformer cette séquence palpitante en corvée monotone. Initialement, les joueurs devaient traverser cette zone rapidement, mais entre la belle lumière et l'arrangement du canal, nous avons estimé que l'endroit était idéal pour accorder un peu de calme au joueur le temps de résoudre une énigme. Celle-ci, qui était la première à tirer parti des masses et poulies, a inspiré d'autres énigmes de navigation physique dans le reste du jeu."
N/A4019"#commentary\cn_105_airboat_changeup.mp3" "[ Jeff Lane ] Les playtesteurs nous avaient expliqué qu'ils voulaient un gameplay plus diversifié lors des séquences en hydroglisseur. Jusqu'ici, le joueur n'avait pas vraiment la possibilité de riposter contre l'hélicoptère et les autres ennemis, c'était donc le moment idéal pour ajouter une arme, introduisant de fait un changement de rythme, et préparer le terrain pour ce qui suivrait. Dans les zones suivantes, nous avons ajouté des cibles d'entraînement pour laisser le temps au joueur de se familiariser avec son nouveau jouet. Les projectiles du fusil d'assaut de l'hydroglisseur bénéficiant d'une force physique si puissante qu'ils font s'envoler les cibles, cette arme paraît immédiatement supérieure au reste de l'arsenal du joueur. Pourtant, lors des playtests de combat contre l'hélicoptère, de nombreux playtesteurs le pensaient toujours invincible. Ils n'avaient pas remarqué nos efforts précédents pour illustrer les dégâts subis par l'hélicoptère, dans la séquence où ils pouvaient utiliser le fusil d'assaut fixe du Cartel. Pour y remédier, nous avons choisi la solution la plus évidente en plaçant l'hélicoptère directement à la sortie du tunnel où vous obtenez cette nouvelle arme, pour montrer clairement que vous pouvez et devriez lui tirer dessus. Et ça a fonctionné."
N/A4020"#commentary\cn_106_donkey_kong_barrel_ramp.mp3" "[ Eric Smith ] Initialement, cette rampe de drainage n'était rien d'autre qu'un détail intéressant dans l'architecture du niveau, mais lors des playtests, nous avons tout de suite vu qu'il était amusant de gravir la pente avec l'hydroglisseur pour redescendre de l'autre côté. Nous avons alors ajouté d'autres éléments pour rehausser l'expérience, dont des métroflics poussant des barils explosifs en direction du joueur, petit hommage au jeu d'arcade culte Donkey Kong."
N/A4021"#commentary\cn_107_lambda_cache_interlude.mp3" "[ Danika Rogers ] Un jeu Half-Life est une expérience fondamentalement linéaire, mais nous cherchons systématiquement à perturber l'itinéraire du joueur pour briser la linéarité d'un niveau. Cette cache lambda, remplacée par une embuscade avec un zombie et un crabe de tête, était entièrement optionnelle et conçue dans le seul but d'ajouter de la variété à cette section des canaux."
N/A4022"#commentary\cn_108_skybox_time_of_day.mp3" "[ Eric Kirchmer ] Tout au long de ce chapitre, les couleurs de la skybox et du brouillard changent progressivement afin de représenter visuellement le passage du temps à mesure que le joueur avance dans les canaux. L'utilisation de deux valeurs de couleur opposées permet de renforcer l'illusion d'un angle oblique du soleil. Ici, on peut voir que le crépuscule est proche. Tout cela culmine dans l'arène de combat contre l'hélicoptère, où le coucher de soleil et Ravenholm sont visibles dans la skybox."
N/A4023"#commentary\cn_109_helicopter_megabomb_origin.mp3" "[ Brian Jacobson ] Ce largage massif de bombes par l'hélicoptère est le résultat d'un bug : un programmeur avait accidentellement supprimé le délai de largage et l'hélico pouvait lâcher des centaines de bombes à la fois. C'était tellement génial visuellement que nous avons décidé de garder cette attaque dans la version finale du bombardement."
N/A4024"#commentary\cn_110_helicopter_final_battle.mp3" "[ Dave Riller ] Nous avons conçu cette zone comme une arène pour l'affrontement final contre l'hélicoptère d'attaque du Cartel. Les joueurs ont enfin l'occasion d'éliminer l'ennemi qui les pourchasse sans relâche depuis qu'ils ont pris la fuite dans les égouts après avoir quitté le laboratoire du Dr Kleiner. Nous avons testé de nombreuses versions de cette zone avant d'en être pleinement satisfaits. Il fallait à la fois un espace suffisamment vaste pour combattre à toute vitesse avec l'hydroglisseur, des options d'itinéraire facilement identifiables pour garantir des déplacements fluides, et des performances stables. En termes de clarté visuelle, nous voulions que la zone soit adaptée au combat, c'est-à-dire marquante sans être surchargée, tout en offrant un panorama inoubliable une fois l'hélicoptère détruit."
N/A4025"#commentary\cn_111_airboat_wreckage.mp3" "[ David Speyrer ] À l'origine, le saut permettant de franchir le barrage entraînait la destruction de l'hydroglisseur, si bien que le joueur commençait ce niveau au milieu des débris. Lors d'un playtest avec toute l'équipe, plusieurs personnes ont été déçues de perdre le véhicule qu'elles avaient piloté pendant si longtemps. Nous avons beaucoup débattu en interne pour savoir si ce sentiment de perte apportait ou non de la valeur à l'expérience. Au final, nous avons décidé d'épargner l'hydroglisseur pour laisser la possibilité au joueur de le retrouver un jour. D'aucuns racontent qu'il est toujours là, quelque part, et qu'il attend votre retour."
N/A4026"#commentary\cn_112_arena_exit_gate.mp3" "[ Quintin Doroquez ] Cette mécanique du volant de manœuvre à tourner pour ouvrir la porte de sortie a été ajoutée spécifiquement pour forcer les joueurs à abattre l'hélicoptère avant de poursuivre leur progression. Nous utilisons fréquemment ce genre d'éléments de design pour empêcher les joueurs d'avancer avant d'avoir accompli une certaine tâche."
N/A4027"#commentary\cn_113_blocking_tutorials.mp3" "[ Adrian Finol ] Parfois, il faut s'assurer que le joueur a appris quelque chose, et la méthode standard pour y arriver (dans les jeux vidéo, pas dans la vie !) consiste à le piéger derrière une sorte de barrière pour le forcer à utiliser ses connaissances afin de progresser. Nous essayons de dissimuler ces barrières aussi naturellement que possible pour ne pas donner l'impression que le jeu est mis en pause. Bien sûr, le temps, les ressources disponibles et le contexte environnemental peuvent rendre la chose plus compliquée. Dans le cas qui nous intéresse, nous voulions apprendre aux joueurs à déplacer des objets et nous les avons incités à empiler des caisses. Nous avons testé des mécaniques plus complexes, mais elles se sont révélées être moins efficaces pour apprendre aux joueurs ce que nous voulions qu'ils retiennent."
N/A4028"#commentary\cn_114_natural_storytelling.mp3" "[ Bill Van Buren ] Afin d'atteindre nos objectifs narratifs et de construction d'univers à travers la gare, il nous fallait trouver un moyen d'inclure des dialogues sans recourir à des initiations scriptées ni renforcer le sentiment d'être dans un jeu vidéo. Quand nous avons remarqué que les joueurs avaient tendance à s'approcher des PNJ par curiosité, nous en avons profité pour les faire réagir à la présence du joueur. Les citoyens n'étant ni très enjoués ni dynamiques, cela nous a permis de garantir une sobriété essentielle dans les interactions. La simplicité de cette approche correspondait également avec l'un des principaux objectifs narratifs de Half-Life : distiller la narration en fonction de l'intérêt que lui portent les joueurs. Si certains aiment se pencher sur le moindre détail, d'autres veulent simplement savoir où aller. Permettre aux joueurs de contrôler la quantité de narration à laquelle ils accèdent sans jamais bloquer leur progression est un objectif que nous cherchons toujours à atteindre dans Half-Life. Et plus une fonctionnalité est simple à mettre en place, plus nous pouvons l'utiliser."
N/A4029"#commentary\cn_115_trainstation.mp3" "[ Charlie Brown ] Le début d'un jeu Half-Life est très important : il doit présenter un nouveau monde aux joueurs tout en leur apprenant à interagir avec. Les joueurs doivent comprendre rapidement ce qu'il se passe, qui sont les acteurs principaux, à quelles menaces ils seront confrontés et la place qu'ils occupent dans cet ensemble. Et surtout, cela doit être aussi amusant et interactif que possible. Y parvenir demande de multiples itérations et tests, en particulier pour tous ces petits moments qui contribuent à façonner le cadre plus global du jeu. Dans cette section, nous allons présenter certains passages clés, des problèmes de game design et quelques tests lors desquels tout ne s'est pas déroulé comme prévu."
N/A4030"#commentary\cn_116_physics_objects.mp3" "[ David Sawyer ] Tout le monde ne s'en souvient pas forcément, mais à l'époque où Half-Life 2 est sorti, les petits objets, comme les détritus au sol, étaient presque toujours statiques. Ils ne bougeaient pas, ou seulement de manière très simple. Parfois, ils pouvaient se désintégrer en quelques sprites lorsque vous les frappiez. L'un de nos objectifs, avec cette première scène dans la gare, était de faire comprendre clairement aux joueurs que tous ces éléments étaient simulés de manière réaliste dans Half-Life 2. Qu'ils pouvaient être ramassés, lâchés, lancés, brisés, déplacés par d'autres forces, etc. Ici, nous commençons avec des petits objets en montrant qu'ils sont soufflés par l'arrivée du train ou, plus précisément, par un volume invisible déclenché par le joueur en sortant du train."
N/A4031"#commentary\cn_117_blocking_tutorials_3.mp3" "[ Eric Smith ] Le deuxième problème est un exemple parfait d'apprentissage trompeur : nous apprenons accidentellement au joueur quelque chose que nous n'avions pas prévu. Ce genre d'erreur est difficile à éviter sans tests poussés, car le jeu vous enseigne toujours quelque chose, même si ce n'est pas intentionnel. Nous reviendrons sur un exemple extrême un peu plus loin dans la gare. Certains cas d'apprentissage trompeur peuvent avoir des répercussions critiques, par exemple, si le joueur apprend à utiliser une arme ou à interagir avec un élément ordinaire du jeu d'une mauvaise façon. Dans le cas présent, c'était plus subtil. En plus d'apprendre au joueur à déplacer des objets, nous lui apprenons à les empiler pour quitter une zone. En temps normal, ce ne serait pas un problème... sauf que nous ne réutilisons pas cette mécanique dans le reste du jeu. Le fait d'apprendre une fonctionnalité inutile encombre l'esprit et rend plus difficile la mémorisation d'éléments utiles. Pire, le fait de pouvoir empiler des objets pour quitter un lieu posait des problèmes auxquels nous avons dû remédier activement dans d'autres zones du jeu. Avec autant d'objets physiques, bloquer cette mécanique sans ajouter des plafonds partout n'était pas vraiment envisageable. En fin de compte, nous avons espéré que les joueurs ne penseraient pas trop à cette mécanique, et lorsque des playtesteurs se sont retrouvés coincés plus tard dans le jeu, nous nous sommes bien gardés de le leur rappeler."
N/A4032"#commentary\cn_118_welcome.mp3" "[ Gabe Newell ] Je suis Gabe Newell, et je suis très heureux de vous revoir dans Half-Life 2, 20 ans après sa sortie. Pour célébrer cet anniversaire, nous avons souhaité satisfaire un maximum des requêtes de la communauté. Bien que celle-ci ne soit pas au sommet de la liste, j'ai entendu de nombreux joueurs exprimer leur souhait de profiter d'un mode Commentaires, et c'est avec plaisir que nous exauçons enfin cette demande. Il n'a pas été toujours facile de se rappeler un certain nombre de détails du développement du jeu, sans parler de replonger dans des lignes de code datant d'il y a deux décennies en se demandant ce qu'on pouvait bien avoir en tête lorsqu'on les a écrites. Nous en avons profité pour corriger quelques vieux bugs et peaufiner un peu ce qui pouvait l'être. Cette fois, au moins, nous avons le luxe de savoir à quoi ressemble le résultat final. Pour écouter un commentaire, placez votre viseur sur l'un de ces symboles flottants et appuyez sur la touche d'utilisation. Pour arrêter le commentaire, placez votre viseur sur le symbole en train de tourner et appuyez de nouveau sur la touche d'utilisation. N'hésitez pas à me faire part de vos remarques en écrivant à gaben@valvesoftware.com. Merci, et amusez-vous bien !"
N/A4033"#commentary\cn_119_metrocop_shoving_citizens.mp3" "[ Josh Weier ] Nous avons fait à peine quelques pas que nous avons déjà un problème à régler. Ici, nous vous présentons le métroflic, un ennemi que nous vous demanderons plus tard de tuer, et nous vous donnons un bref aperçu du monde dans lequel vous venez d'entrer. Il s'agit d'une scène simple permettant d'illustrer la relation entre les métroflics et les citoyens, dont le joueur, par extension, fait partie. Dans le même temps, nous avons décidé de renforcer la présence de la simulation physique de base, en montrant que les personnages non jouables (PNJ) peuvent interagir avec les objets dans le monde. À l'époque, voir une valise en percuter une autre et la renverser était plutôt novateur, par exemple. Ces moments dans la gare, où nous avons combiné plusieurs objectifs, étaient les plus réussis : ils arrivaient naturellement, sans donner l'impression de mettre le jeu en pause pour enseigner une leçon au joueur."
N/A4034"#commentary\cn_120_fall_damage.mp3" "[ Kerry Davis ] Enseigner aux joueurs à effectuer certaines actions est essentiel, mais pour prendre des décisions rapides et éclairées, ils doivent également comprendre des règles plus subtiles. Ce court passage en présente deux. Premièrement, il révèle la hauteur depuis laquelle le joueur peut tomber sans subir de dégâts. Deuxièmement, il introduit un élément appartenant au \"vocabulaire\" du jeu, qui correspond à la manière dont celui-ci lui transmet des informations. Les joueurs s'inquiètent souvent de subir des dégâts de chute, mais également d'avancer dans une direction sans pouvoir revenir en arrière. Ici, nous avons donc placé une caisse sur laquelle ils peuvent atterrir, afin d'indiquer que la chute n'est pas dangereuse et qu'il s'agit bien du chemin à emprunter. Et lorsque la caisse se brise, cela renforce non seulement la simulation physique, mais c'est aussi la première fois que la plupart des joueurs constatent que les objets de cette taille peuvent être détruits."
N/A4035"#commentary\cn_121_sweeping_vortigaunt.mp3" "[ Laura Dubuk ] Dans cet autre moment clé de narration, qui met à nouveau en avant le moteur physique, nous dévoilons la place qu'occupent les Vortigaunts dans ce nouveau monde par rapport à leur rôle d'ennemis dans Half-Life 1. Comme pour d'autres scènes dans la gare, nous avons voulu montrer des PNJ interagissant naturellement avec d'autres objets. Pourquoi se contenter de dire aux joueurs que les Vortigaunts ne sont pas hostiles alors qu'on peut en montrer un balayant le sol et déplaçant plusieurs objets simulés ? Aucun joueur, en voyant un personnage faire le ménage paisiblement, ne va se dire qu'il s'agit là d'un ennemi à abattre."
N/A4036"#commentary\cn_122_blocking_tutorials_2.mp3" "[ Robin Walker ] Cette initiation comporte deux problèmes majeurs. Premièrement, les joueurs peuvent briser le game design en jetant toutes les caisses par la fenêtre. Ils se retrouvent alors coincés et ne peuvent pas progresser, ce que nous considérons comme un bug critique. Une des solutions potentielles aurait été de modifier la taille des fenêtres afin que le joueur puisse passer par l'ouverture, mais pas les caisses. Seulement, le développement en était déjà à un stade avancé lorsque nous avons repéré ce problème, et même un changement mineur peut avoir des conséquences imprévisibles et casser le jeu. Nous ne pouvions pas nous le permettre, surtout juste avant la sortie. De plus, ce problème était purement théorique : nous n'avons vu aucun testeur procéder ainsi. Tous nos tests de cet espace se sont déroulés sans accroc : les joueurs apprenaient la mécanique en question et passaient à la suite. Modifier le design de la pièce à un stade aussi avancé risquait de perturber cette réussite. Nous avons donc trouvé une autre solution en privilégiant la prudence à l'élégance. Si cela vous intrigue, essayez de jeter toutes les caisses par la fenêtre et observez ce qui se passe."
N/A4037"#commentary\cn_123_playground.mp3" "[ Brian Jacobson ] Quand nous avons réfléchi aux moyens de mettre en lumière notre simulation physique de l'environnement urbain, l'aire de jeux nous est apparue comme un choix naturel. Pour les joueurs qui ont écouté le Dr Breen, cette zone rappelle également le coût de la capitulation de l'humanité face au Cartel. Nous avons sélectionné quelques structures au potentiel physique intéressant et nous les avons animées. Même avec la simulation physique avancée dont nous disposions à l'époque, de telles configurations ont nécessité un calibrage manuel, car nous devions faire interagir des objets intégralement simulés avec d'autres partiellement ou non simulés, comme le joueur ou les environnements statiques. On pourrait facilement imaginer que c'est la simulation qui prend en charge la majorité de l'implémentation, mais même aujourd'hui, 20 ans plus tard, ce n'est que rarement le cas. Lorsque nous travaillions sur l'aire de jeux, à un stade avancé du développement, nous ne sommes pas arrivés à obtenir une sensation de friction satisfaisante sur le toboggan, alors nous avons simplement cassé l'échelle pour que le joueur ne puisse pas monter. Cependant, comme dans la vraie vie, il est possible de le remonter à l'envers. Après tout, les joueurs trouvent toujours un moyen de contourner ce que nous mettons en place."
N/A4038"#commentary\cn_124_pick_up_that_can.mp3" "[ Charlie Brown ] Contextualiser les initiations en les intégrant au scénario nous permet d'enseigner une notion au joueur sans mettre le jeu en pause et en ajoutant une valeur narrative. Ici, nous apprenons au joueur à lancer des objets tout en le plaçant dans une situation à laquelle il peut choisir de réagir comme il le souhaite. Après avoir observé les métroflics maltraiter les citoyens sans raison, il se retrouve dans une position similaire. S'il pensait que les citoyens auraient dû réagir d'une certaine manière, il a maintenant la possibilité de l'exprimer. Lors des tests, la plupart des joueurs ont simplement effectué l'action demandée ou ils ont refusé de ramasser la cannette. Certains ont essayé d'éviter totalement la confrontation. D'autres ont commencé par s'exécuter, puis ont décidé de riposter après s'être sentis humiliés. En restreignant ce moment, à la fois en matière d'interactions possibles et d'espace, nous pouvions généralement réagir de manière appropriée au choix du joueur, quel qu'il soit."
N/A4039"#commentary\cn_125_promises.mp3" "[ Danika Rogers ] Dans Half-Life, l'un de nos objectifs est de faire des promesses au joueur dès le début du jeu, afin de lui donner une idée de ce à quoi il peut s'attendre pour la suite. Films, séries ou livres, toutes les bonnes œuvres de divertissement le font d'une manière ou d'une autre, et les jeux vidéo n'échappent pas à la règle. Dans Half-Life, ces promesses peuvent prendre différentes formes. Certaines sont simples, comme lorsque nous offrons un bref aperçu d'un élément intrigant, et d'autres sont plus complexes, comme les interactions avec les métroflics. En plaçant le joueur dans une position d'impuissance face à ces personnages, nous préparons le terrain pour le moment futur où il pourra enfin riposter."
N/A4040"#commentary\cn_126_exploration.mp3" "[ David Sawyer ] Après avoir été conduit par les métroflics à travers la gare, nous voulions donner au joueur la possibilité d'explorer son environnement. Cette place offre plusieurs opportunités d'interactions avec des citoyens, des métroflics, des scanners ou des infrastructures de la ville. Nous voulions ainsi donner un peu plus de consistance au monde sans avoir à passer par des initiations explicites et nous les avons peaufinées pour qu'elles fonctionnent naturellement."
N/A4041"#commentary\cn_127_early_game_exploration.mp3" "[ David Speyrer ] Jusqu'à cette ruelle, le joueur n'a normalement pas eu à réfléchir beaucoup à son itinéraire, car il était plutôt simple et clairement indiqué. Mais ici, nous voulions encourager l'exploration, ce qui implique de rendre la progression moins évidente. Forcément, cela peut entraîner le sentiment d'être perdu ou désorienté. Ce type de changement peut être complexe à gérer, surtout au début du jeu, alors que le joueur apprend toujours à repérer les indices pour s'orienter. Dans le cas présent, c'est encore plus compliqué en raison des champs de force qui font office de points de contrôle et permettent aux PNJ de circuler, mais restreignent les déplacements du joueur. De nombreux playtesteurs étaient convaincus qu'il existait un moyen de les contourner. Finalement, des tests poussés nous ont permis de déterminer le niveau d'indications idéal pour guider subtilement le joueur dans la ruelle en utilisant la lumière, la disposition des éléments et une caisse en bois, un objet que les joueurs ont déjà associé à l'itinéraire à suivre."
N/A4042"#commentary\cn_128_strider.mp3" "[ Doug Wood ] Ce bref instant est une promesse : vous recroiserez cette chose énorme plus tard au cours du jeu. Même une scène aussi simple que celle-ci nécessite de nombreux tests et itérations, car dans Half-Life, nous avons pour objectif de ne jamais retirer le contrôle au joueur. Comme vous pouvez l'imaginer, nous avons dû procéder à des tas de petites modifications pour nous assurer qu'un maximum de joueurs regardent au bon endroit au bon moment. Du tracé de la rue à la position des métroflics, tout a été réfléchi pour guider le regard et cadrer parfaitement le strider lorsqu'il apparaît."
N/A4043"#commentary\cn_129_physics_simulation.mp3" "[ Jay Stelly ] Même si nous avions commencé Half-Life 2 avec un modèle de simulation physique externe fonctionnel, il nous a fallu plusieurs années de travail supplémentaires, à la fois sur la simulation en elle-même et sur son intégration dans le jeu, avant de pouvoir répondre aux ambitions de nos designers. Nous savions dès le départ que l'obtention d'un niveau de qualité et de performances suffisant pour que le jeu soit sortable représenterait un défi, mais déterminer quels objets simuler, et dans quelle mesure, était une question encore plus délicate. Nous ne pouvions pas tout simuler, et même si nous l'avions pu, nous savions que ça n'aurait pas forcément été bénéfique pour le game design. Nous avons fait de nombreuses entorses délibérées à la simulation pour améliorer l'expérience du joueur. En général, ces ajustements passent inaperçus, car ils s'alignent avec ses intentions. Par exemple, nous avons désactivé les collisions entre le joueur et les grands objets pour qu'il soit possible de tourner dans des espaces étroits. Nous avons aussi modifié le tir alternatif des fusils du Cartel pour guider légèrement les projectiles vers les ennemis, ce qui les rend plus efficaces."
N/A4044"#commentary\cn_130_physics_simulation_2.mp3" "[ Jeff Lane ] Les zones où le game design et d'autres contraintes impactaient la simulation physique ont généralement nécessité davantage de précision pour éviter que la simulation ne se brise. Par exemple, au début du développement nous avons essayé de renforcer la simulation de l'entité joueur, en conférant à ses déplacements un poids beaucoup plus important dans la simulation physique du monde. Nous savions que cela risquait d'affaiblir la précision des déplacements, mais nous espérions que cela nous mènerait à créer des expériences novatrices. Toutefois, après avoir calibré les déplacements pour obtenir un résultat s'approchant de la version simplifiée, nous avons rencontré un problème majeur : la force physique requise pour que le joueur se déplace à sa vitesse habituelle était si importante que la moindre collision avec un autre objet simulé pouvait être mortelle. Nous avons essayé plusieurs configurations, mais nous n'avons pas trouvé de solution satisfaisante et nous sommes revenus à des déplacements moins simulés. Ce n'était pas non plus la voie de la facilité, car cela introduisait de nouveaux défis dans la manière dont le joueur, moins simulé, interagissait avec les objets plus simulés du jeu. Mais cela nous a permis de proposer une expérience de déplacement aussi précise que nous le souhaitions."
N/A4045"#commentary\cn_131_playtesting.mp3" "[ John Morello ] Les playtests sont un élément central de notre processus de création de jeux. Nous ne pouvons jamais prédire totalement la manière dont les joueurs réagiront, ou ce qu'ils retireront de ce que nous avons conçu. Alors, nous effectuons des tests pour apprendre et, le cas échéant, nous améliorer. Lors d'un playtest, nous ne parlons pas au joueur et ne le guidons pas, même s'il se retrouve coincé (car il est extrêmement improbable que nous puissions le faire pour chaque joueur après la sortie du jeu). Notre objectif est que les testeurs oublient qu'ils sont là pour tester le jeu, et qu'ils jouent comme s'ils se trouvaient sur leur canapé. La moindre interruption risque de fausser les données, c'est pourquoi nous intervenons uniquement lorsqu'un bug bloque la progression ou, plus rarement, si le comportement du playtesteur est tellement déconcertant que nous avons besoin de comprendre ce qui l'a amené à agir ainsi."
N/A4046"#commentary\cn_132_playtesting_anecdote_1.mp3" "[ Matt Boone ] Une session de playtest nous a rappelé que nous ne pouvions jamais être certains de ce que pensent les joueurs ni quelles leçons ils retirent de leur expérience. Le playtesteur, qui s'était retrouvé coincé devant une porte après avoir joué depuis le début du jeu, a passé plusieurs minutes à faire des allers-retours entre le jeu et la configuration du clavier. Quand nous lui avons demandé pourquoi, il nous a répondu qu'il cherchait la touche permettant d'afficher son inventaire, pensant pouvoir ouvrir la porte à l'aide d'un objet ramassé plus tôt. Nous l'avions effectivement vu ramasser et relâcher plusieurs objets, mais il avait mal interprété ce qui se passait. Le testeur croyait qu'appuyer sur la touche d'utilisation en tenant un objet lui permettait de ranger celui-ci dans son inventaire, car l'objet relâché tombait droit vers le sol. Nous savions qu'il s'agissait seulement de la gravité, mais son interprétation n'était pas délirante : à l'époque, dans certains jeux d'aventure, on pouvait faire glisser les objets de cette manière pour les ranger dans un inventaire invisible. Nous lui avons expliqué qu'il n'y avait pas d'inventaire, et le test s'est poursuivi. Plus tard, nous nous sommes demandé s'il fallait se pencher sur la question, mais comme aucun autre testeur n'avait eu cette réaction et que toutes nos solutions potentielles étaient plus lourdes à mettre en place, nous avons décidé qu'il s'agissait d'un cas isolé que nous pouvions nous permettre d'ignorer. Cela nous a toutefois rappelé que chaque détail, jusqu'au plus subtil, peut induire le joueur en erreur."
N/A4047"#commentary\cn_133_cratebaby.mp3" "[ Scott Dalton ] Ce poupon a une longue histoire. Durant les nombreux mois de tests internes, certains membres de l'équipe l'ont utilisé comme un défi, histoire de s'amuser un peu au bout de leur 47e partie consécutive. Ils déposaient le poupon dans la caisse bleue et essayaient de le transporter le plus loin possible dans le jeu. Quand Half-Life 2 est sorti, la communauté s'est également mise à transporter le poupon dans sa caisse tout en ajoutant ses propres histoires et ses propres règles. Quelques années plus tard, quand nous travaillions sur l'Épisode 2, c'est ce qui nous a inspiré le succès \"Le nain-fusée\", pour lequel les joueurs doivent transporter un nain de jardin surnommé \"Gnome Chompski\" pendant l'intégralité de l'Épisode. Chompski est même revenu plus tard dans Left 4 Dead 2 et le joueur doit transporter la figurine durant toute la campagne \"Lugubre carnaval\" pour le succès \"Nain libre\". Ce genre d'interactions avec les joueurs sont l'un des aspects les plus gratifiants du développement d'un jeu. Nous le concevons avec des théories à l'esprit, mais on ne sait jamais vraiment ce qui peut se passer jusqu'au moment où le jeu arrive entre les mains des joueurs."
N/A4048"#commentary\cn_134_the_citadel.mp3" "[ Eric Kirchmer ] Nous voulions que la première vue de Cité 17 s'offrant au joueur fasse ressortir la Citadelle et sa position dominante sur la ville, pour représenter le pouvoir total qu'exerce le Cartel sur le reste de l'humanité. Nous voulions également offrir une sorte d'objectif : dès le début, vous pouvez voir où vous mènera votre aventure. Pourtant, malgré sa taille gigantesque, de nombreux playtesteurs ne la remarquaient pas. Il n'est pas toujours facile de percevoir la profondeur sur un écran d'ordinateur. Si vous avez déjà joué à des jeux en réalité virtuelle, vous aurez sûrement remarqué que cette notion vous paraissait plus naturelle. Quoi qu'il en soit, dans ce cas précis, la position de la Citadelle surplombant le joueur n'aidait pas non plus, probablement parce que les jeux de tir à la première personne nous conditionnent à regarder droit devant ou à nos pieds. Pour augmenter la probabilité que les joueurs remarquent la Citadelle, nous avons ajouté des oiseaux volant vers le bâtiment. Nous avons constaté que cette astuce discrète nous aidait à guider le regard du joueur."
N/A4049"#commentary\cn_135_close_captions.mp3" "[ Yahn Bernier ] Au cours du développement de Half-Life 2, nous avons été approchés par des personnes sensibilisées à l'accessibilité, qui nous ont encouragés à aller plus loin que le système de sous-titres que nous avions créé pour Half-Life 1. Ils voulaient un système intégral retranscrivant non seulement les dialogues, mais également les sons du jeu. Ce défi s'est révélé être bien plus difficile à relever que nous l'avions anticipé. Half-Life 2 contient un grand nombre de sons divers, et pour les sous-titrer, il était crucial de les catégoriser. Il fallait en outre établir des priorités : les dialogues et l'identité du locuteur devaient impérativement se démarquer. Les sons d'ambiance, comme les bruits d'un combat distant, étaient importants pour établir l'atmosphère de certains niveaux, mais beaucoup moins quand un ennemi tirait à quelques pas de vous. Comme nos concepteurs de niveaux avaient également l'habitude de réutiliser des sons dans des contextes différents, un même son pouvait avoir besoin d'être sous-titré par endroits, mais pas à d'autres. Au final, chaque son du jeu a eu droit à ses propres données de sous-titres dans un format qu'on pourrait décrire comme une version réduite de HTML qui nous a permis de contrôler le style visuel de chaque sous-titre. Comme pour les fichiers audio, les données de sous-titres étaient trop volumineuses pour être conservées en mémoire, alors nous avons créé un système de cache asynchrone pour les gérer efficacement."
N/A4050"#commentary\cn_136_the_raid.mp3" "[ David Sawyer ] La section suivante, lors de laquelle les métroflics font une descente dans l'appartement dans lequel se trouve le joueur, a nécessité de nombreux ajustements. De manière générale, nous concevons Half-Life de manière à laisser les joueurs avancer à leur rythme, car si certains ont tendance à courir en ignorant tout ce qui ne ressemble pas à une menace, d'autres vont méthodiquement s'intéresser à chaque détail. Pour cette raison, lorsque nous devons imposer un rythme spécifique, le défi est toujours de veiller à ce que les joueurs le comprennent et le suivent naturellement. Comme cette section est la première de ce type, nous avons dû déployer de gros efforts pour indiquer clairement au joueur qu'il n'a pas le temps d'explorer la zone et doit au contraire avancer rapidement."
N/A4051"#commentary\cn_137_materials_and_shaders.mp3" "[ Gary McTaggart ] Half-Life 2 est sorti au milieu d'une période où s'opérait un changement majeur en matière de graphismes 3D, alors que l'industrie passait des textures aux shaders et matériaux. Dans Half-Life 1, chaque surface avait une texture, c'est-à-dire une image plaquée sur les polygones de la surface. Mais pour Half-Life 2, à peine cinq ans plus tard, chaque surface avait à la fois un matériau et un shader. Le shader était un bloc de code permettant de personnaliser la manière dont était rendue la surface, tandis que le matériau définissait les propriétés de son comportement physique et ses réactions au gameplay. Il contenait également des références aux textures et autres paramètres utilisées par le shader pour le rendu. En d'autres termes, les artistes et les game ou level designers bénéficiaient d'un contrôle accru sur l'apparence et le comportement des différents éléments. Cependant, cette évolution impliquait une contrainte majeure : alors qu'Half-Life 1 pouvait tourner sur un ordinateur équipé d'un simple processeur (CPU), les calculs requis par les matériaux et les shaders dans Half-Life 2 avaient été conçus spécifiquement pour être utilisés avec un processeur graphique (GPU). Cette porte en verre est un parfait exemple de shader personnalisé, mais en réalité, chaque surface visible à l'écran est dotée d'un shader."
N/A4052"#commentary\cn_138_the_raid_2.mp3" "[ Miles Estes ] En plus de veiller à ce que le joueur se sente contraint d'avancer, nous devions nous assurer que le joueur ne pourrait pas éviter les métroflics ni se cacher pour faire marche arrière. Le véritable défi n'était pas tant les joueurs qui chercheraient volontairement à ne pas jouer le jeu, mais tous ceux qui risqueraient de paniquer et de courir dans toutes les directions après avoir compris qu'ils étaient menacés pour la première fois. Ce moment repose sur un équilibre délicat : nous voulions provoquer une fuite palpitante et une sensation de réel danger, mais également que les joueurs parviennent à s'enfuir dès leur premier essai en ayant le sentiment de s'en être sorti de justesse. Pour y parvenir, nous avons fait en sorte que la voie à suivre soit claire et évoque le chemin emprunté à l'étage précédent. Une série de déclencheurs soigneusement placés contrôlent l'apparition des menaces devant et derrière les joueurs, permettant de maintenir la pression tout en laissant le temps aux joueurs de conserver leur avance sur leurs poursuivants."
N/A4053"#commentary\cn_139_health_and_no_hud.mp3" "[ Dave Riller ] La séquence de poursuite sur les toits posait un défi unique en termes de conception. Nous ne voulions pas en faire un véritable obstacle au gameplay, et le joueur devait idéalement pouvoir s'en sortir dès sa première tentative. En revanche, nous tenions à créer une situation de réel danger où le joueur se sentirait suffisamment menacé pour ne jamais s'arrêter. Le joueur, sans combinaison CEH, était techniquement dépourvu d'affichage tête haute (ATH) et ne savait donc ni s'il subissait des dégâts ni la quantité de santé dont il disposait. Le défi consistait donc à trouver un moyen de lui communiquer ces informations. Après plusieurs expérimentations, nous avons créé un système de santé spécifique à cette section en ajoutant une lumière rouge sur les contours de l'écran pour indiquer les dégâts subis. Les joueurs ont réagi comme nous l'espérions, y voyant une incitation à continuer d'avancer jusqu'à ce que la poursuite se termine comme prévu. De plus, nous avons accéléré la régénération de santé pour que l'effet lumineux ne dure pas, ce qui conforte le joueur dans sa décision de courir tout en évitant qu'il soit abattu par une balle perdue juste avant la fin du niveau à cause d'un arrêt ou d'une hésitation survenue plus tôt."
N/A4054"#commentary\cn_140_playtesting_anecdote_2.mp3" "[ Jakob Jungels ] Dans la prochaine section, nous avions besoin que le joueur perde connaissance afin qu'Alyx vienne le sauver. Le temps et les ressources étant limités, nous avions simplifié l'affrontement au maximum en réutilisant des systèmes existants, en laissant la séquence se dérouler comme un combat ordinaire et en y ajoutant un événement personnalisé déclenché à la \"mort\" du joueur. Nous avons procédé à quelques playtests pour ajuster le timing et nous sommes passés à la suite. Cependant, peu avant la sortie du jeu, nous avons rencontré un problème avec un playtesteur qui effectuait constamment des sauvegardes rapides et rechargeait sa partie dès qu'il pensait avoir échoué. Quand un métroflic le frappait, il rechargeait rapidement avant qu'Alyx ait le temps d'intervenir, ce qu'il a fait plus de dix fois avant que nous lui demandions d'arrêter. À ce stade du développement, dans la dernière phase de correction des bugs, nous devions nous concentrer sur les problèmes critiques, car la moindre modification risquait d'entraîner des problèmes plus importants. Puisqu'il s'agissait d'un cas isolé, nous nous sommes contentés de petits changements discrets. Nous avons raccourci le délai entre la \"mort\" du joueur et la première ligne de dialogue d'Alyx, et avons remplacé le fondu au noir par un fondu au blanc (ce qui ne s'est pas révélé très utile, puisqu'à ce stade du jeu, les joueurs n'avaient pas encore pu associer le noir à la mort). Nous avions envisagé de désactiver le chargement rapide pendant les quelques secondes que dure cette scène, mais nous craignions que cela entraîne un bug désactivant le chargement rapide de manière permanente."
N/A4055"#commentary\cn_141_character_reactions.mp3" "[ Ariel Diaz ] Déterminer les éléments auxquels les personnages devaient réagir (et comment) était un défi constant. Pour nous, il était essentiel que le jeu réagisse aux actions du joueur, mais celui-ci est susceptible d'interpréter toute réponse du jeu comme une récompense. Ainsi, ce à quoi réagissent et ce qu'ignorent les PNJ permet d'enseigner au joueur ce que le jeu attend de lui. Nous avons donc favorisé les réactions aux comportements que nous voulions encourager, comme le fait de tester les appareils dans le laboratoire, et ignoré ceux que nous préférions éviter, comme utiliser une caisse pour frapper Kleiner à répétition. Ce n'est pas une blague. Nous avons vraiment observé un playtesteur le faire pendant cinq bonnes minutes."
N/A4056"#commentary\cn_142_choreography.mp3" "[ Bill Fletcher ] En interne, le système que nous avons conçu et utilisé pour donner vie à la narration de Half-Life 2 était appelé Choreo, pour \"choreography\" (en français, \"chorégraphie\"). Nous sommes très tôt partis de l'idée que nous écrivions une pièce dont l'un des acteurs ne connaissait pas le script. Nous avions besoin d'un système capable de contrôler tous les autres acteurs pour qu'ils se déplacent sur scène, jouent leur rôle et récitent leur texte. Pour atteindre ce résultat, les autres acteurs devraient pouvoir allier naturellement obéissance à nos instructions de jeu et réactions dynamiques aux déplacements et au comportement du joueur. La gestion du timing allait représenter un défi majeur, car n'importe quelle partie de la scène pourrait être potentiellement prolongée, raccourcie, voire mise en pause en fonction des actions du joueur."
N/A4057"#commentary\cn_143_phoneme_extraction.mp3" "[ Bill Fletcher ] L'éditeur de phonèmes est un autre outil majeur que nous avions intégré à FacePoser. Il traitait les dialogues des acteurs de doublage et en extrayait les phonèmes afin de générer des animations de synchronisation labiale basiques pour nos personnages. Celles-ci servaient ensuite de références à nos animateurs pour créer des animations faciales intégrales personnalisées de haute qualité pour chaque ligne de dialogue des personnages principaux. Toutefois, pour les scènes Choreo dynamiques, les animateurs ne pouvaient pas prédire ce que ferait le reste du corps du PNJ. Il fallait donc structurer soigneusement les commandes de Choreo et les timings dans FacePoser, tout en conservant la capacité des PNJ à réagir de manière dynamique aux actions du joueur."
N/A4058"#commentary\cn_144_delivery.mp3" "[ Ken Birdwell ] Il a fallu de nombreux ajustements et playtests pour trouver le bon équilibre entre partage d'informations et création de liens émotionnels dans nos scènes Choreo majeures. Chacune d'entre elles est l'occasion de transmettre une grande quantité d'informations, mais nous ne pouvions pas nous contenter de longs dialogues d'exposition, ou les joueurs auraient considéré nos personnages non plus comme des individus, mais comme de simples vecteurs d'informations. Nous devions laisser le temps aux personnages d'interagir entre eux et permettre au joueur d'observer leurs relations. En même temps, nous devions développer notre monde et donner au joueur une idée des événements survenus en son absence. Tout cela devait être fait avec soin et sans s'étirer trop longuement, pour ne pas perdre les joueurs moins investis dans le récit. L'animation est devenue un puissant outil pour communiquer les relations émotionnelles entre personnages, capable de transmettre la gravité de l'instant sans exagération. L'humour a également servi par sa capacité à désamorcer les situations un peu trop pesantes."
N/A4059"#commentary\cn_145_alyxs_kiss.mp3" "[ Ken Birdwell ] Il ne dure qu'un instant, mais le baiser d'Alyx sur la joue d'Eli joue un rôle essentiel. Plus tard, nous allons demander au joueur de sauver Eli, et nous voulons qu'il accorde de l'importance à son sort. Pour créer ce lien émotionnel, nous devions montrer que la relation entre Alyx et son père est douce et affectueuse, mais nous ne voulions pas en faire trop avec des dialogues ou en nous attardant sur ce geste. Ce lien devait paraître sincère, pas exagéré. Après un certain nombre de modifications subtiles, nous avons fini par atteindre l'effet recherché."
N/A4060"#commentary\cn_146_storytelling.mp3" "[ Bill Van Burren ] La création d'un sentiment d'immersion était l'un des principes fondamentaux de notre approche narrative pour Half-Life 1. Pour y parvenir, nous nous étions imposé comme contraintes de ne jamais (ou du moins le plus rarement possible) retirer le contrôle au joueur et de ne jamais faire parler son avatar. Ces contraintes nous ont parfois posé des problèmes, mais nous avons estimé qu'il était important de les conserver pour Half-Life 2. Nous espérions que cela nous obligerait à repousser nos limites pour explorer une narration plus profonde et interactive."
N/A4061"#commentary\cn_147_archetypes.mp3" "[ Bill Van Buren ] Nous voulions créer des liens narratifs entre Half-Life 1 et Half-Life 2 par le biais de nos personnages. L'idée était de concevoir des individus évoquant les archétypes présents dans Half-Life 1 pour provoquer un sentiment de familiarité chez les joueurs, comme s'ils les avaient déjà rencontrés dans le premier jeu sans vraiment s'en souvenir. Dr Kleiner est basé sur le modèle de scientifique qui nous paraissait le plus représentatif, et sa personnalité a été façonnée en grande partie par Hal Robins, dont la voix et le jeu d'acteur avaient déjà donné vie aux scientifiques de Half-Life 1. Un jour, nous avons pris l'ascenseur avec un comptable d'une entreprise installée à un autre étage de notre bâtiment. Nous l'avons regardé et avons tout de suite pensé : \"C'est le visage du Dr Kleiner\". Nous lui avons demandé si nous pouvions le prendre en photo pour en faire un personnage de jeu vidéo et, fort heureusement, il s'est montré coopératif."
N/A4062"#commentary\cn_148_tone.mp3" "[ Bill Van Buren ] Il était crucial de trouver le ton juste pour les dialogues entre nos personnages. Nous voulions des interactions respectueuses, voire aimables avec le joueur, tout en évitant de verser dans la servilité. Cet équilibre s'est révélé être particulièrement complexe à trouver avec Alyx, qui devait être un soutien efficace sans pour autant compromettre sa force de caractère, un aspect que nous estimions essentiel pour qu'elle suscite le respect. Sa relation avec Eli étant au cœur des motivations du joueur, il fallait que ce dernier l'apprécie et veuille l'aider. Nous souhaitions également créer une camaraderie chaleureuse entre les alliés du joueur, contrastant avec l'hostilité de Breen et du Cartel, afin de provoquer un sentiment d'indignation vertueuse en prévision des batailles à venir."
N/A4063"#commentary\cn_149_voice-actors.mp3" "[ Bill Van Buren ] Afin de créer des personnages sensibles et multidimensionnels pour Half-Life 2, nous devions évoluer dans notre manière de collaborer avec les acteurs de doublage. La plupart des dialogues des PNJ de Half-Life 1 avaient été enregistrés avec un simple script agrémenté de quelques indications, mais pour sa suite, nous avons décidé d'impliquer davantage les comédiens pour définir leurs personnages avant de leur donner vie. Nous leur avons fourni beaucoup plus de contexte sur le scénario et leur avons présenté l'univers du jeu, les environnements dans lesquels évolueraient leurs personnages ainsi que les autres PNJ avec lesquels ils interagiraient. Nous avons recruté des acteurs capables d'intégrer et de synthétiser toutes ces informations dans leur performance afin de sublimer leurs personnages au-delà de ce que nous avions imaginé. Nous avons effectué plusieurs sessions d'enregistrement avec les comédiens principaux pour leur permettre d'assimiler et de développer leurs personnages sur la durée. Pour les scènes impliquant plusieurs PNJ, nous donnions généralement la réplique aux comédiens en utilisant les performances de leurs homologues, afin de renforcer l'interaction et la fluidité. Nous arrivions au studio avec un script et un plan pour la session du jour, mais laissions chaque comédien proposer ses idées pour son personnage et sa performance. La présence d'animateurs lors des sessions de doublage s'est également révélée cruciale, car ils devaient ensuite associer les dialogues à des actions et expressions physiques pour réaliser les scènes Choreo. Leurs plans pour le déroulement d'une scène avaient tendance à évoluer après une séance de travail avec les comédiens."
N/A4064"#commentary\cn_150_citizens.mp3" "[ Bill Van Buren ] Lorsque nous avons commencé à concevoir les citoyens de Cité 17 et du monde hors des limites de la ville, nous avons choisi d'inclure une diversité d'origines ethniques, d'âges et de genres. Cela avait évidemment un intérêt narratif, puisque nous sous-entendions ainsi que le Cartel avait réduit l'humanité entière en esclavage, mais nous tenions également à ce que tous les joueurs puissent se sentir représentés dans la Résistance, qui unissait tous les habitants de la Terre contre le Cartel. Nous avons trouvé dans nos relations personnelles et professionnelles plusieurs candidats pouvant servir de références visuelles, mais nous avons également eu recours aux petites annonces du Seattle Times pour recruter un éventail de visages aussi divers que possible."
N/A4065"#commentary\cn_151_alyx.mp3" "[ Dhabih Eng ] Nous avons apporté un souhait tout particulier au personnage d'Alyx, nous voulions qu'elle suscite à la fois le respect et l'affection du joueur. Vers la moitié du jeu, le sauvetage d'Eli est un objectif majeur, et nous savions que les joueurs se sentiraient plus concernés s'ils étaient également attachés à Alyx et à sa relation avec son père. Du design du personnage au casting vocal en passant par l'écriture de ses dialogues, nous avons intentionnellement cherché à faire d'Alyx un personnage intelligent, compétent et auquel on peut s'identifier dans un monde contrôlé par le Cartel, tout en la rendant attirante et charismatique. Nous voulions éviter l'objectification et l'hypersexualisation que l'on trouvait dans de nombreux jeux des années 2000, car nous estimions que cela nuirait aux objectifs que nous nous étions fixés avec ce personnage."
N/A4066"#commentary\cn_152_lab_interactivity.mp3" "[ Dhabih Eng ] Lors de nos scènes Choreo, nous enfermons le joueur quelques instants pour nous concentrer sur les personnages et le récit. Afin de satisfaire différents types de joueurs, entre ceux qui s'investissent à fond dans l'histoire et ceux incapables de rester immobiles plus d'une seconde, nous avons jugé bon d'afficher à l'écran tout un tas de détails intéressants. Nous avons distillé des éléments narratifs à travers l'environnement en veillant à ce que certains soient interactifs. Bref, nous avons donné au joueur des jouets avec lesquels s'amuser. Dans certains cas, nous avons intégré une couche de narration à ces éléments. Par exemple, le mini-téléporteur de cactus évoque le dysfonctionnement du téléporteur qui surviendra peu après. Tout cela repose sur un équilibre délicat, car un trop-plein de détails visuels pourrait détourner le joueur du véritable intérêt de la scène. Au final, le laboratoire de Kleiner étant la première scène Choreo majeure, nous nous sommes contentés d'un degré d'interactivité raisonnable. Plus tard, dans le laboratoire d'Eli, nous avons exploré plus avant les possibilités et fait en sorte que les personnages eux-mêmes réagissent aux éléments avec lesquels interagit le joueur."
N/A4067"#commentary\cn_153_gestures.mp3" "[ Doug Wood ] Chacun de nos personnages disposait d'une bibliothèque d'animations simples appelée \"Gestures\" (\"gestes\"), que nous pouvions facilement ajouter en complément d'autres mouvements corporels. Ces animations, initialement prévues pour être réutilisées tout au long du jeu afin de réaliser des économies de production, nous ont finalement été bien plus utiles. Les humains répètent souvent certains mouvements, qui peuvent devenir des marqueurs caractéristiques de leur personnalité. Notre bibliothèque de gestes a donc fini par contenir l'essence de chaque personnage, ce qui a aidé nos animateurs à uniformiser leur compréhension de chacun d'entre eux. Pour les besoins de la production, ils devaient souvent se partager la charge de travail sur un personnage, et cela leur a grandement facilité la tâche."
N/A4068"#commentary\cn_154_interactive_storytelling.mp3" "[ Erik Johnson ] Quand nous avons commencé à développer Half-Life 2, la composante narrative dans les jeux vidéo était généralement soit riche et linéaire, soit simple et interactive. Les joueurs avaient déjà découvert des récits de grande qualité dans d'autres titres, mais toujours en tant que simples spectateurs, incapables d'interagir avec l'histoire ou d'en examiner chaque détail. Bien qu'enthousiasmés par cet objectif, nous ne savions pas encore s'il nous serait possible de l'atteindre ni de quelle technologie nous aurions besoin pour y parvenir. Nous avions conçu plusieurs outils de narration pour Half-Life 1, mais le récit restait majoritairement présenté au joueur et n'avait ni l'interactivité ni la richesse que nous recherchions. Le laboratoire du Dr Kleiner nous a donc servi de banc d'essai pour concevoir le bon fonctionnement de notre narration interactive."
N/A4069"#commentary\cn_155_monitors.mp3" "[ Ido Magal ] Dans Half-Life 2 et ses épisodes, nous avons beaucoup utilisé les écrans pour servir la narration, à tel point que nous avons fini par nous en moquer nous-mêmes. Le problème, c'est qu'ils sont beaucoup trop utiles ! Ils sont incroyables pour étendre l'univers en montrant des événements qui se déroulent dans un autre lieu, et fournissent une excuse simple pour faire intervenir des personnages sans avoir à expliquer comment ils sont arrivés là où se trouve le joueur. Quiconque a déjà écrit une histoire, surtout impliquant un grand nombre de personnages, connaît la frustration d'avoir à chercher des raisons naturelles et crédibles pour que tous ses personnages se retrouvent au même endroit au même moment. Dans le cas présent, nous étions particulièrement contents de pouvoir utiliser l'écran pour qu'Alyx se téléporte et réapparaisse quelques instants plus tard dans le laboratoire d'Eli, renforçant l'impression que tout est réel et connecté."
N/A4070"#commentary\cn_156_scene_interactivity.mp3" "[ Jeff Lane ] Dans nos scènes Choreo, nous demandons parfois au joueur d'effectuer une action. En plus de l'impliquer dans l'histoire, ces moments servaient quelques objectifs essentiels. Tout d'abord, ils laissaient le temps au joueur de rattraper son retard s'il s'était laissé distraire par son environnement. La scène pouvant aisément être \"mise en pause\" jusqu'à ce qu'il termine sa tâche, cela nous permettait de veiller à ce qu'il soit de retour et concentré. Dans le même temps, cela nous permettait de placer le joueur à l'endroit où nous le souhaitions, ce qui était utile pour cadrer la scène et nous assurer qu'il puisse voir un élément important. Dans certains cas, nous en profitions également pour entraîner le joueur : ici, il apprend à interagir avec les câbles et les prises, ce qui lui servira à résoudre des énigmes dans la suite du jeu."
N/A4071"#commentary\cn_157_kleiners_lab.mp3" "[ Marc Laidlaw ] Le laboratoire du Dr Kleiner est la première séquence de narration sur laquelle nous avons travaillé, et celle que nous avons passé le plus de temps à peaufiner. En plus de lancer le joueur dans le jeu, elle a servi à fédérer l'équipe de développement autour d'objectifs narratifs communs. Quand nous avons commencé à concevoir nos personnages et à mettre en place le récit autour du joueur, de nombreuses questions ont été soulevées et toutes impliquaient des risques majeurs pour le jeu. Les joueurs pourraient-ils retirer de cette scène les informations importantes ? Arriverions-nous à les faire s'attacher aux personnages ? Comment faire pour contenter des joueurs qui n'auraient pas tous le même niveau d'investissement dans le récit ? Quel serait le coût de production d'une telle séquence ? Combien d'autres en faudrait-il ? Pour répondre à ces questions, nous devions d'abord concevoir une part conséquente de la scène et la présenter à de nombreux playtesteurs. C'était très frustrant, mais contrairement à la plupart des problèmes auxquels nous pouvions être confrontés, obtenir des réponses fiables à ces questions nécessitait d'effectuer un travail considérable. Un certain nombre d'idées de gameplay peuvent être testées avec des prototypes basse fidélité, mais si un joueur ne s'investit pas dans notre récit quand les personnages ne sont que de simples blocs gris, comment pouvons-nous être sûrs qu'il le fera une fois ces mêmes personnages entièrement modélisés ?"
N/A4072"#commentary\cn_158_characters.mp3" "[ Marc Laidlaw ] Dans Half-Life 1, les agents de sécurité et les scientifiques étaient des archétypes plus que des individus. Des représentations abstraites de personnages, définies par le niveau de fidélité visuelle que nous étions capables d'obtenir à l'époque. Mais avec l'évolution de notre technologie pour Half-Life 2, nous avons estimé pouvoir aller plus loin. Les améliorations apportées aux graphismes de nos modèles et animations de personnages nous ont permis de créer des personnages individuels, auxquels les joueurs pourraient réellement s'attacher. Nous nous sommes autorisés à écrire de vrais dialogues, que les personnages prononceraient de façon suffisamment réaliste pour éviter que les joueurs ne les voient comme de simples pions et qui, avec un peu de chance, serviraient notre narration. En 2001, deux ans après le début du développement, nous avons été confortés dans notre décision par Ico, de Japan Studio. Le jeu, réalisé par un animateur, nous a bluffés par la manière dont il se repose sur ses personnages pour établir une connexion avec le joueur, et nous y avons puisé le courage de poursuivre sur cette voie."
N/A4073"#commentary\cn_159_writing.mp3" "[ Marc Laidlaw ] À l'époque de Half-Life 1, dans les FPS, les joueurs avaient généralement pour objectif d'affronter et de vaincre un ennemi clairement maléfique. Il était difficile de les faire s'intéresser à des personnages aussi rudimentaires graphiquement que ceux de Half-Life 1. Avec les améliorations prévues dans le réalisme des personnages pour Half-Life 2, nous avons pris le pari d'en faire le moteur principal de notre récit. Notre but était d'aligner les motivations du joueur sur celles de nos personnages afin qu'il s'intéresse à eux, à leurs espoirs et à leurs peurs, et veuille les voir réussir. C'est ainsi que nous avons pu définir notre approche des personnages et des dialogues. Nous voulions créer un ensemble de personnages qui s'apprécieraient et se soucieraient les uns des autres, dans l'espoir que le joueur ressente ce même attachement. Des personnages qui interagiraient de manière à inclure le joueur, comme un groupe de vieux amis retrouvant l'un des leurs après une longue absence. Nous estimions que si nos personnages partageaient clairement des liens émotionnels réalistes, il nous serait possible d'établir ces mêmes liens avec le joueur."
N/A4074"#commentary\cn_160_animation.mp3" "[ Miles Estes ] La conception de mouvements humains crédibles pour nos personnages à partir de nombreuses couches d'animation distinctes a nécessité beaucoup d'itérations. Même les actions les plus simples, comme se tourner pour regarder quelque chose ou marcher vers une position spécifique, ont été complexifiées par le besoin de s'adapter au joueur de manière dynamique et de répondre aux exigences des commandes Choreo. Par exemple, il a fallu décomposer intégralement le mouvement effectué pour se tourner et regarder quelque chose, afin de permettre à un PNJ d'utiliser toutes les combinaisons possibles de ses yeux, de sa tête, de ses épaules, de son buste ou de son corps pour faire face à l'élément ciblé. Dans Half-Life 1, le corps des personnages humains était séparé à la taille, ce qui leur permettait de marcher dans une direction tout en regardant vers une autre. Cette approche était toutefois trop limitée pour Half-Life 2. Nos animateurs ont donc créé, pour chacune des huit directions de la boussole, des animations de marche pouvant ensuite se combiner subtilement pendant la partie."
N/A4075"#commentary\cn_161_faceposer.mp3" "[ Yahn Bernier ] Le principal outil que nous avons conçu pour alimenter le système Choreo était le mal nommé FacePoser, un programme qui permettait à nos animateurs d'étaler la structure intégrale de nos scènes sur une frise. Celle-ci incluait une série de commandes Choreo à destination des acteurs, ainsi que toutes les informations nécessaires pour qu'ils les exécutent. En étalant ces commandes sur la frise, les animateurs pouvaient facilement décrire qu'un acteur aurait possiblement besoin de faire face à un élément, de parler en direction d'un autre et de marcher vers un emplacement différent, le tout simultanément. Mais la frise n'était pas une séquence linéaire et figée, car les acteurs allaient non seulement devoir obéir à leurs commandes, mais également réagir de manière dynamique à leur environnement. Par exemple, un acteur pourrait être ralenti dans son déplacement si le joueur se trouvait sur son chemin, ou bien il devrait attendre avant de dire sa réplique si un autre acteur a été retardé. Grâce à FacePoser, nous pouvions rapidement modifier des scènes et essayer différentes configurations, interprétations de dialogues et timings. Cette capacité d'expérimentation et d'ajustement nous a permis de déterminer les performances idéales pour atteindre nos objectifs en termes de personnages et de narration."
N/A4076"#commentary\cn_162_choreo_commands.mp3" "[ Yahn Bernier ] Sur cet affichage de débogage, on peut voir les deux commandes Choreo les plus fréquemment reçues par les acteurs d'une scène, que nous appelons les \"look-at\" (direction du regard) et \"move-to\" (direction du déplacement). Les acteurs se voient attribuer une ou plusieurs cibles à regarder, puis essaient de se concentrer sur la plus logique selon leur situation actuelle. En parallèle, ils peuvent recevoir une commande de déplacement, qui leur indique de rejoindre une position donnée et de se tourner vers une direction ou un objet spécifique. Ces commandes, simples en apparence, impliquaient toutefois une grande complexité. Imaginons, par exemple, une scène où un acteur parle en tapant au clavier tout en regardant un objet tenu par le joueur. Puisque nous ne pouvions pas prédire les déplacements du joueur, nous devions décomposer chaque élément de la scène en plusieurs morceaux et couches, afin que le tout puisse ensuite être réassemblé en fonction des actions du joueur, et interrompu si nécessaire."
N/A4077"#commentary\cn_163_antlions.mp3" "[ Kerry Davis ] Pour contraindre le joueur à rester à proximité de son buggy pendant sa traversée de la Côte, nous avions besoin d'un ennemi omniprésent, pouvant apparaître n'importe où de manière justifiée et représentant une menace constante. Les fourmis-lions surgissant du sable étaient la solution idéale. Extrêmement mobiles, elles sont capables de suivre le buggy sur de courtes distances, contrairement aux ennemis humanoïdes. Et cerise sur le gâteau, leur rouler dessus est particulièrement satisfaisant."
N/A4078"#commentary\cn_164_thumpers.mp3" "[ Adrian Finol ] Dès que l'occasion se présente, il est important de donner aux joueurs l'impression d'avoir compris quelque chose par eux-mêmes. Cela renforce le sentiment que le monde est vivant et ne se résume pas à une série d'éléments de gameplay créés à leur intention. Si nous pouvons accepter le risque qu'un certain pourcentage de joueurs passe totalement à côté d'un élément, nous pouvons adopter une approche plus subtile. C'est ce que nous avons fait avec les marteleurs, des dispositifs conçus pour être découverts, mais avec lesquels il n'y a aucune obligation d'interagir. Nous avons ajouté un certain nombre d'indices visuels et sonores, ainsi que les réactions des fourmis-lions, pour aider les joueurs à appréhender la situation. Cela ne garantit pas que tous comprendront ce qui se passe, mais les playtests ont montré que la plupart y arrivaient."
N/A4079"#commentary\cn_165_d2_coast_09.mp3" "[ Aaron Seeler ] Vers la fin du développement de la Côte, notre code de jeu avait tellement d'avance sur notre level design que nos programmeurs gameplay cherchaient à écrire davantage de code et à s'occuper de nouvelles tâches pour aider à sortir Half-Life 2. Cela s'expliquait en grande partie par les exigences des niveaux de la Côte, dont la simple échelle et l'utilisation de vastes terrains représentaient un lourd fardeau pour nos level designers. Par conséquent, nos programmeurs gameplay ont commencé à concevoir des combats à petite échelle. Plus tard, quand nos level designers ont pu rattraper leur \"retard\", ils ont créé ce niveau en combinant trois affrontements distincts des programmeurs et en accomplissant tout le travail de finition nécessaire."
N/A4080"#commentary\cn_166_final_scene.mp3" "[ Bill Van Buren ] Enfermer le joueur dans une nacelle pour l'ultime confrontation dans le bureau de Breen représentait un compromis, mais cela nous a permis de mettre en avant les personnages d'une manière qui nous était impossible autrement. Cette séquence apportant une conclusion aux arcs narratifs de tous les personnages, contraindre le joueur à adopter ce point de vue nous permettait de créer une situation riche en émotions, où les dialogues, les performances des acteurs et les animations culminaient en une apothéose. En termes de production, c'était un véritable casse-tête : nous devions définir les blocages et déplacements appropriés pour garantir un timing efficace, une synergie et une connexion émotionnelle à partir d'animations individuelles et de performances vocales qui avaient été enregistrées séparément. De nombreux ajustements ont été nécessaires avant d'obtenir une synergie dramatique et l'impression d'une véritable connexion entre les personnages."
N/A4081"#commentary\cn_167_end_game_scramble.mp3" "[ Dave Riller ] À l'origine, nous avions prévu d'inclure une scène scriptée bien plus importante à la fin de Half-Life 2, mais notre équipe Choreo était déjà très occupée par l'énorme quantité de travail narratif requis sur le reste du jeu. Afin de les soulager un peu, nous avons demandé à l'équipe responsable du gameplay de la Citadelle de créer une épreuve de leur choix pour conclure le jeu : une énigme, un combat ou que sais-je encore. C'est ainsi, en exploitant les mécaniques de jeu du super pistolet anti-gravité et quelques éléments scriptés, qu'ils ont imaginé et pu livrer le combat de boss contre Breen en très peu de temps."
N/A4082"#commentary\cn_168_combine_portal_effects.mp3" "[ Gary McTaggart ] La possibilité pour chaque membre de l'équipe de mettre ses compétences au service de n'importe quelle partie du jeu est un élément essentiel de notre processus de développement. Une fois la boucle de gameplay du combat final établie, les graphistes et programmeurs d'effets visuels ont magnifié l'exposition du portail vers le monde du Cartel et l'effet de temps figé présenté à la fin du jeu. Pour obtenir l'effet du portail, nous avons utilisé un shader de réfraction similaire à ce que nous avions déjà utilisé pour l'eau."
N/A4083"#commentary\cn_169_citadel_entrance.mp3" "[ Jeff Lane ] Nous avons conçu le trajet vers la Citadelle à rebours : les décors intérieurs étaient initialement des prototypes graphiques destinés à en parfaire l'apparence. Sachant que le joueur arriverait depuis les égouts après avoir quitté notre carte de combat urbain, nous avons dû créer une section pleine de glissades et de sauts pour entrer dans la Citadelle et relier les deux niveaux."
N/A4084"#commentary\cn_170_citadel_steep_landing.mp3" "[ Randy Lundeen ] La Citadelle a été conçue à un stade très avancé du développement, et au départ, nous n'avions pas d'idée précise du gameplay que nous voulions y proposer. Ce n'est pas si rare : bien que le game design soit généralement au cœur de nos efforts, l'intégration au produit final de certains choix créatifs majeurs effectués très tôt, comme l'existence de la Citadelle du Cartel, passe par un travail de conception spécifique. Après la bataille épique du chapitre précédent, nous estimions qu'il serait plus intéressant de changer de ton pour le bouquet final. Même si nous voulions augmenter les enjeux, il était trop tard pour créer de nouvelles mécaniques et de nouveaux PNJ. C'était trop risqué. Notre plan initial était d'en faire un spectacle narratif passif, un voyage au cœur de la machine de guerre du Cartel qui s'achèverait dans le bureau de Breen. Toutefois, après avoir élaboré ce plan, nous avons passé quelques jours à travailler sur les mécaniques du super pistolet anti-gravité, estimant que, pour la fin du jeu, nous pouvions exaucer le souhait des joueurs en les rendant surpuissants sans perturber l'équilibre global du design. Les premiers résultats étant prometteurs, nous avons effectué un travail de refonte rapide pour introduire cette nouvelle arme. Au lieu des traditionnelles épreuves de fin de jeu, nous voulions que le joueur se sente tout-puissant, qu'il puisse saisir les ennemis à volonté, arracher les consoles des murs, etc. En définitive, la Citadelle allie ces deux concepts et alterne entre spectacle et déchaînement de puissance."
N/A4085"#commentary\cn_172_lightmap_pass.mp3" "[ Mike Dussault ] Géométriquement, l'intérieur de la Citadelle est relativement simple, mais les matériaux métalliques du Cartel et les éclairages dramatiques renforcent l'immensité de la structure. Nous avons augmenté la résolution des lightmaps (textures de lumière) sur les surfaces importantes et intéressantes, et l'avons réduite sur les surfaces distantes ou peu éclairées. Dans les vastes espaces de la Citadelle, des surfaces de lightmap inutilement grandes consomment énormément de ressources. Vers la fin du développement, nous avons passé les niveaux de la Citadelle au peigne fin pour optimiser ces valeurs, tant dans un intérêt visuel que pour des questions de performances. Ce travail a été facilité par un nouvel outil, intégré à l'éditeur de niveaux Hammer, qui permettait d'afficher les surfaces avec leur densité de luxels."
N/A4086"#commentary\cn_173_super_gravity_origins.mp3" "[ Brian Jacobson ] À ce stade du développement, nous étions pleinement convaincus par le design du pistolet anti-gravité. Désirant offrir au joueur un sentiment de toute-puissance, nous avons commencé à plancher sur une version améliorée. Après une bonne journée de prototypage, nous étions déjà satisfaits de notre nouvelle arme et l'avons intégrée au cœur du gameplay de la Citadelle. Notre moteur physique étant achevé, nous étions libres d'en repousser les limites pour trouver de nouvelles manières de s'amuser avec. L'objet avec lequel nous avions testé le prototype, une pastèque pesant plusieurs centaines de kilos dans notre simulation physique, a servi de base pour les boules du Cartel présentes dans le jeu final."
N/A4087"#commentary\cn_174_combine_energy.mp3" "[ Brian Jacobson ] Ce qui n'était initialement qu'un prototype aux allures de pastèque a fini par devenir une boule d'énergie, après que nous avons retravaillé ses sons d'impact et d'explosion pour obtenir le résultat que l'on entend dans le jeu. Quand nous avons commencé à expérimenter avec des niveaux ne tournant plus autour d'un gros fruit, nous nous sommes rendu compte que nous pouvions utiliser ces boules d'énergie non seulement pour tuer des soldats, mais également en tant qu'élément d'énigme pour alimenter divers équipements. Bien plus tard au cours du développement, n'étant pas satisfaits de la méthode de tir alternatif de l'AR2, nous l'avons remplacée par une boule du Cartel. Avec le recul, nous sommes toujours surpris de constater à quel point des éléments du jeu fonctionnant indépendamment les uns des autres ont finalement été assemblés pour résoudre des problèmes."
N/A4088"#commentary\cn_175_combine_wall_and_balls_training.mp3" "[ Ido Magal ] Lors des playtests, les joueurs ne remarquaient pas que les boules d'énergie du Cartel dissolvaient les soldats et ne comprenaient pas pourquoi ils disparaissaient. Nous avons d'abord tenté d'y remédier en faisant rebondir les boules en direction des ennemis pour augmenter les probabilités de désintégration. Finalement, nous nous sommes rendu compte que les joueurs ne remarquaient pas cet effet parce qu'il se produisait toujours dans le feu de l'action, et que nos capacités à apprendre quelque chose sous la pression sont très limitées. Dans un dernier effort, nous avons ajouté une salle d'entraînement calme et présentant un champ de force ne pouvant être désactivé qu'avec une boule du Cartel. L'objectif de cette installation était d'apprendre au joueur comment les boules pouvaient désactiver les champs de force et désintégrer les soldats, mais lors des playtests, cela n'a que moyennement fonctionné. Malgré tous nos efforts, certains joueurs n'arrivaient toujours pas à percevoir l'effet des projectiles. Par manque de temps, et comme les playtesteurs affirmaient quand même se sentir tout-puissants, nous avons fini par décider que ce n'était pas si grave si tous les joueurs ne comprenaient pas toutes les subtilités de leur réussite."
N/A4089"#commentary\cn_176_weapon_strip.mp3" "[ Josh Weier ] Après avoir introduit le super pistolet anti-gravité, nous ne voulions pas que les joueurs le laissent de côté pour utiliser leurs armes classiques, c'est pourquoi nous les avons désintégrées. Avoir pour antagoniste principal du jeu un ennemi surnaturel et impénétrable tel que le Cartel était un atout : nous n'avions même pas besoin de justifier l'existence du désintégrateur. Et si, pour quelque raison que ce soit, nous avions besoin de vous rendre votre arsenal au beau milieu du niveau, il nous suffisait de vous présenter une autre technologie du Cartel : le réintégrateur."
N/A4090"#commentary\cn_177_breen_monologue.mp3" "[ Marc Laidlaw ] Aucun travail créatif ne s'effectue en vase clos, car nous nous inspirons tous d'autres créations. Le monologue de Breen diffusé sur les écrans de la Citadelle est en partie inspiré d'un jeu que nous avions tous adoré : Dark Project 2 : L'Âge de métal, dans lequel l'antagoniste provoque le joueur pendant qu'il se faufile. L'exécution est complètement différente, mais le principe reste le même. En revanche, cet enregistrement n'aurait jamais pu être si impactant sans l'incroyable performance du regretté Robert Culp. Son interprétation était parfaite. Il a insufflé dans chaque ligne de Breen une subtilité et une élégance qui ont véritablement donné vie au personnage. On ne pouvait pas faire plus simple qu'une session d'enregistrement avec Robert Culp : on lui donnait le script, l'ingénieur du son lançait l'enregistrement, et le tour était joué. S'il fallait en tirer une leçon, ce serait de toujours travailler avec des gens plus doués que vous et dont vous apprendrez forcément quelque chose. Ne partez pas avec une idée préconçue de la manière dont un dialogue devrait être prononcé, ou dont un certain moment devrait se dérouler : collaborez avec des individus talentueux et faites-leur confiance pour sublimer vos créations."
N/A4091"#commentary\cn_178_dissolved_weapons.mp3" "[ Quintin Doroquez ] Toutes les armes du Cartel étaient paramétrées pour se désintégrer lorsque les soldats étaient transformés en poupées de chiffon par le pistolet anti-gravité, d'une part pour que les joueurs ne puissent pas les ramasser et les utiliser et, d'autre part, pour améliorer les performances sur ces cartes. Nous avons également ajouté un gestionnaire de ragdolls pour retirer les corps désarticulés des soldats après le passage du joueur."
N/A4092"#commentary\cn_179_elevator_fight.mp3" "[ Brian Jacobson ] Même si nous souhaitions que le joueur se sente tout-puissant, nous ne pouvions pas résister à la tentation d'ajouter un combat exigeant dans la cage d'ascenseur. Cet affrontement, qui dure jusqu'à l'arrivée de l'ascenseur, est un peu plus difficile que nous l'avions prévu initialement pour cette partie du jeu. Il a été simplifié lors des playtests, mais nous n'avons pas eu le temps d'en faire suffisamment pour l'équilibrer autant que nous l'aurions voulu. Le joueur n'est jamais véritablement en danger, mais le nombre de soldats présents rend la bataille plus impressionnante qu'elle ne l'est réellement."
N/A4093"#commentary\cn_180_replacing_the_prefabs.mp3" "[ Jeff Lane ] La configuration des boules d'énergie du Cartel est relativement simple, puisqu'il s'agit d'un champ de force retenant des objets rebondissant continuellement. Pourtant, lors des playtests, nous avons rencontré de multiples bugs qui voyaient des boules d'énergie s'échapper du champ de force que nous avions créé pour les maintenir en place. En raison des limites imposées par notre technologie préfabriquée de l'époque, nous avons dû les reconstruire manuellement à de multiples reprises, pour chacun de leurs emplacements dans tous les niveaux de la Citadelle qui en contenaient."
N/A4094"#commentary\cn_181_strider_fight.mp3" "[ Ted Backman ] L'un des tout premiers prototypes de la Citadelle incluait la possibilité d'attirer le strider avec le super pistolet anti-gravité, si bien que pendant longtemps, le combat contre cet ennemi consistait à s'en approcher suffisamment pour y parvenir. Vers la fin du développement, estimant que cela nuisait à la sensation de puissance émanant du strider, surtout après en avoir affronté plusieurs dans les rues de Cité 17, nous avons remplacé ce combat par un autre lors duquel vous devez l'abattre avec des boules d'énergie. Nous avons modifié le modèle de ce strider pour qu'il puisse être démantelé au lieu de se changer en ragdoll. Ce strider est le seul du jeu à bénéficier de cet effet."
N/A4095"#commentary\cn_182_getting_in_the_pod.mp3" "[ Dhabih Eng ] Pour réaliser cette séquence d'ascension dans une nacelle, nous devions prendre le contrôle total de la scène et du regard du joueur. C'est complètement contraire à nos principes habituels, mais pour cette ultime étape, nous estimions que cela en valait la peine. À ce stade, le joueur est tellement puissant qu'il est difficile de contrôler ses mouvements. Nous l'avons donc empêché d'agir. Il reste tout de même impliqué et au centre de l'attention, car les autres personnages de la scène lui parlent. Nous en avons également profité pour distiller des éléments de narration sur le chemin. Le long de ce rail qui traverse la Citadelle, vous pouvez apercevoir des adversaires pour lesquels nous avions conçu des visuels, mais qui n'ont finalement pas été utilisés. Depuis le confort de votre nacelle, vous pouvez admirer le processus de transformation des stalkers, ainsi qu'un aperçu des crabes synths."
N/A4096"#commentary\cn_183_turrets.mp3" "[ Mike Dussault ] Les tourelles étaient un outil de conception très utile pour les passages où le joueur disposait d'appâts, car elles pouvaient empêcher les fourmis-lions de les approcher de front. Cela nous a permis de créer des situations où le joueur ne pouvait pas se contenter de lancer des appâts pour avancer, mais devait contourner et détruire les tourelles pour que ses fourmis-lions puissent le suivre. De plus, voir les fourmis-lions se faire massacrer par les tourelles était toujours spectaculaire."
N/A4097"#commentary\cn_184_grenade_puzzle.mp3" "[ Aaron Seeler ] Lors des playtests, de nombreux joueurs se sont retrouvés bloqués au niveau de cette énigme, car la caisse de grenades illimitées était placée un peu plus tôt sur leur itinéraire. Arrivés à ce stade du jeu, les joueurs ont appris à associer les caisses de munitions illimitées aux solutions des énigmes. S'ils voient une caisse de grenades à un endroit, ils savent immédiatement qu'ils en ont besoin pour résoudre l'énigme qui se présente à eux. Mais nous voulions d'abord qu'ils réfléchissent un peu. Finalement, nous avons ajouté un indice subtil en plaçant des grenades sur le bureau visible à travers la fenêtre, afin de rappeler leur existence. Cela nous a également aidés à découvrir un bug lorsqu'un playtesteur s'est approché pour y jeter un œil et a pu récupérer les grenades à travers la vitre."
N/A4098"#commentary\cn_185_allied_turrets_balancing.mp3" "[ Adrian Finol ] Équilibrer ce combat autour des tourelles alliées était un défi, car elles représentent ici l'élément nouveau. Si le joueur les ignore, le gameplay semble redondant et en grande partie similaire à celui des niveaux précédents. Nous voulions encourager l'utilisation des tourelles et récompenser leur placement stratégique, mais c'était une méthode extrêmement binaire : un placement parfait rendait le combat plutôt simple, tandis qu'un placement raté le rendait extrêmement difficile. En ajustant et personnalisant la logique de l'I.A. des soldats, ceux-ci sont devenus plus doués pour neutraliser les tourelles en lançant des grenades ou en les contournant pour les renverser. Grâce à ces modifications, le combat ne consistait plus à placer parfaitement les tourelles, mais à les replacer continuellement, car les soldats finissaient toujours par en neutraliser certaines. Les playtests ont donné lieu à des résultats très variés : certains joueurs estimaient que le combat était trop difficile, et d'autres affirmaient que c'était leur préféré. Par manque de temps, nous l'avons légèrement simplifié avant la sortie, mais nous n'étions pas vraiment satisfaits de l'équilibrage final."
N/A4099"#commentary\cn_186_meeting_mossman.mp3" "[ Ariel Diaz ] Après la scène de trahison, organiser les retrouvailles de Gordon et Alyx avec Mossman n'a pas été facile, car beaucoup de joueurs voulaient simplement l'abattre à vue. Nous ne pouvions pas les laisser faire, car nous n'avions pas le temps de développer de scénario alternatif. Cependant, ne voulant pas non plus les en empêcher de manière trop évidente, nous avons cherché à réduire les probabilités que les joueurs essaient de la tuer. Grâce à cette vitre blindée, ils n'ont pas d'autre choix que d'assister au dialogue entre Alyx et Judith, au cours duquel il devient évident qu'Alyx ne pense pas qu'abattre Mossman soit une bonne solution."
N/A4100"#commentary\cn_187_eli_in_pod_choreography.mp3" "[ Ken Birdwell ] Nous avons écrit et enregistré les dialogues de cette scène pendant la conception de Nova Prospekt. À ce stade, nous savions qu'Alyx et Gordon se téléporteraient hors de la prison, mais les détails de cet événement n'étaient pas encore définis. Les dialogues devaient donc rester suffisamment vagues pour correspondre à ce que nous finirions par concevoir. Pour cette raison, nous nous sommes davantage concentrés sur la vulnérabilité d'Alyx et sa relation avec son père plutôt que sur les actions du joueur. Nous espérions que l'émotion, plus que la narration en elle-même, porterait la scène. Au bout du compte, notre but est que le joueur se soucie de ces personnages et veuille privilégier ce qui est important pour Alyx."
N/A4101"#commentary\cn_188_mossman_and_eli.mp3" "[ Bill Van Buren ] Cette scène Choreo est passée par de nombreuses itérations. Nous voulions introduire un retournement de situation au milieu de la scène sans pour autant retirer le contrôle au joueur. Il a fallu trouver un équilibre délicat pour que ce rebondissement soit clair, mais ne puisse pas être interrompu. Si les joueurs suivaient Alyx jusqu'à la console, il fallait qu'ils puissent comprendre la situation au moment de se retourner. S'ils restaient à l'écart pour observer Mossman, il fallait qu'ils comprennent ce qu'elle faisait, mais n'aient pas l'impression d'avoir à l'en empêcher. Trouver le bon timing a nécessité de nombreux playtests et ajustements, mais nous y sommes parvenus en détournant l'attention du joueur, en veillant à ce que le moment crucial soit court et en apportant une explication une fois l'événement passé."
N/A4102"#commentary\cn_189_nova_prospekt_entry.mp3" "[ Danika Rogers ] Les joueurs sortant tout juste de deux niveaux remplis de combats, nous voulions ralentir la cadence une fois à l'intérieur. Ces premiers niveaux ont été conçus comme un changement de rythme afin de laisser les joueurs explorer les couloirs de Nova Prospekt à leur guise. Nous en avons profité pour introduire le gameplay à base de tourelles, d'abord en tant qu'ennemies du joueur, puis comme outils à leur disposition. Une bonne partie de ce niveau repose sur des prototypes et des espaces graphiques créés plus tôt dans le développement du projet, alors que nous nous efforcions de définir l'apparence de Nova Prospekt."
N/A4103"#commentary\cn_190_turret_training_exit.mp3" "[ Doug Wood ] Nous avons ajouté tout ce bric-à-brac devant la porte et dans les escaliers pour dissuader les joueurs d'emporter une tourelle avec eux. Ce n'est pas grave s'ils le font, mais nous voulions l'éviter autant que possible. Rendre son transport peu pratique n'était pas une stratégie de conception idéale, mais c'était mieux que rien. De nombreux playtesteurs, sentant que le jeu essayait de leur dire quelque chose, ont fini par laisser leur tourelle de côté."
N/A4104"#commentary\cn_191_allied_antlions.mp3" "[ Eric Kirchmer ] Après avoir intégré une armée de fourmis-lions réapparaissant à l'infini pour attaquer les tourelles et les soldats, il a fallu déterminer le rôle à conférer au joueur dans Nova Prospekt. Puisque nous l'avions déjà opposé à un grand nombre de soldats du Cartel, nous avons décidé que les affrontements de cette zone tiendraient davantage de l'énigme et du spectacle que du combat pur. Sur cette base, nous avons créé des situations où le combat restait équilibré jusqu'à ce que le joueur intervienne. En tuant directement des ennemis, il pouvait faire pencher la balance à l'avantage des fourmis-lions, mais nous voulions avant tout récompenser l'utilisation des appâts. Ainsi, dans plusieurs scénarios, lancer un appât sur les ennemis déclenche un déferlement de fourmis-lions qui se joignent à la bataille. Le carnage qui en résulte, particulièrement satisfaisant, fait office de récompense."
N/A4105"#commentary\cn_192_laser_mines.mp3" "[ Erik Johnson ] Nous étions vraiment contents de pouvoir ajouter ces mines laser à Nova Prospekt. Nous n'avions pas trouvé comment inclure cette arme de Half-Life 1 dans Half-Life 2, mais nous lui avons au moins trouvé une utilité comme élément d'énigme. Nous aimions également le fait qu'elles servent, en quelque sorte, à tester la moralité du joueur possédant une armée de fourmis-lions. Certains n'hésitaient pas à lancer un appât derrière les mines, utilisant ainsi leurs sbires pour les déclencher, tandis que d'autres ordonnaient à leurs petits compagnons d'attendre en sécurité pendant qu'ils désamorçaient les explosifs à l'aide d'autres outils. Nous ne jugeons personne."
N/A4106"#commentary\cn_193_final_turret_arena.mp3" "[ Erik Johnson ] Lorsque nous concevons l'arc d'un élément de gameplay, comme l'utilisation des tourelles alliées, nous commençons souvent par développer un prototype représentant l'extrémité de cet arc. Nous ajustons ensuite ce prototype au fur et à mesure des playtests jusqu'à ce qu'il fonctionne comme nous le souhaitons. Puis, nous travaillons à rebours et ajoutons les scènes précédentes pour introduire l'élément et apprendre au joueur à s'en servir. En procédant ainsi, nous pouvons nous assurer que l'arc final sera intéressant avant de consacrer un temps considérable au reste. Cela signifie également qu'au moment de créer l'initiation, nous avons déjà pu observer suffisamment de playtests pour savoir ce que les joueurs comprendront d'eux-mêmes et ce que nous devons leur enseigner. Pour cette scène finale, notre objectif était d'encourager le joueur à placer et déplacer les tourelles de manière dynamique pour se défendre contre des ennemis arrivant de plusieurs directions."
N/A4107"#commentary\cn_194_one_way_drops.mp3" "[ Jakob Jungels ] Les joueurs ne savent jamais ce que leur réserve la zone suivante, mais celle qu'ils viennent de quitter leur est familière et il n'est pas rare qu'ils s'y replient lorsqu'ils se trouvent confrontés à un ennemi. Parfois, nous concevons une arène et souhaitons que le combat s'y déroule, notamment contre les ennemis impliquant que le décor respecte certains critères, comme le garde fourmi-lion. Nous devons alors empêcher le joueur de battre en retraite. Pour ce faire, une solution simple est de le faire sauter dans l'arène depuis une position surélevée, sans aucune possibilité de remonter (un artifice que vous avez peut-être déjà remarqué à plusieurs reprises)."
N/A4108"#commentary\cn_195_npcs_on_elevators.mp3" "[ Jay Stelly ] Nous passons souvent un temps considérable à résoudre des problèmes que les joueurs n'auraient probablement jamais remarqués. S'il s'agit généralement de subtiles questions de conception, d'autres problèmes découlent de plusieurs systèmes interagissant entre eux. Par exemple, faire prendre l'ascenseur à des PNJ représentait un défi complexe, car cela impliquait divers systèmes comme le comportement décisionnel, le planificateur de trajectoire et la simulation des déplacements de l'IA des PNJ. Nous devions également prendre en compte les contraintes de simulation de l'ascenseur lui-même, sans aucun lien avec les PNJ. Un autre défi, plus subtil, venait du fait que nous simulions les PNJ à une cadence plus lente que les ascenseurs. Dans un ascenseur qui descend, par exemple, le PNJ était d'abord simulé (pour veiller à ce qu'il se tienne correctement sur le sol de l'ascenseur), puis l'ascenseur était simulé à quelques reprises, chaque fois un peu plus bas dans sa cage, laissant le PNJ léviter subtilement. L'instant d'après, le PNJ était simulé une deuxième fois et se retrouvait à nouveau les pieds collés au sol de l'ascenseur. Comme vous pouvez l'imaginer, il était difficile de prendre Alyx au sérieux quand elle chutait constamment par petits incréments tout en continuant à vous parler."
N/A4109"#commentary\cn_196_looktargets.mp3" "[ John Cook ] L'un de nos outils de conception essentiels est la fonction Looktarget : un point invisible dans l'espace qui s'active quand le joueur le regarde. Les designers peuvent définir, entre autres conditions, la précision du regard du joueur ou sa durée. Une fois activé, le Looktarget peut déclencher divers événements. Par exemple, Alyx peut attendre que vous la regardiez avant de prononcer une ligne de dialogue, un spectacle commencer uniquement lorsqu'il apparaît dans votre champ de vision, ou un vaisseau du Cartel survoler votre position lorsque vous regardez plus ou moins dans sa direction. À partir du moment où nous avons intégré les Looktargets, les designers ont trouvé d'innombrables moyens de les utiliser pour adapter le gameplay à tous les joueurs, car ceux-ci ne progressent pas tous à la même vitesse et peuvent se déplacer parfois de manière imprévisible."
N/A4110"#commentary\cn_197_nova_prospekt_yard.mp3" "[ John Morello ] Pour les combats dans la cour de Nova Prospekt, nous nous sommes largement inspirés de nos observations précédentes des affrontements entre les fourmis-lions et les soldats du Cartel. Les créatures, extrêmement mobiles et attaquant au corps à corps, s'opposent parfaitement aux soldats, qui se battent à distance et sont vulnérables en combat rapproché. Le rendu visuel des fourmis-lions se faisant tirer dessus est superbe, avec des particules volant dans tous les sens, et lorsqu'elles s'abattent enfin sur un soldat, l'effet de ragdoll provoqué est incroyablement satisfaisant."
N/A4111"#commentary\cn_198_vent.mp3" "[ John Morello ] Vous le savez probablement, mais s'il y a un conduit, il doit y avoir un crabe de tête à l'intérieur. Nous n'y sommes pour rien. Comme les conduits, ce type de règle vient d'en haut."
N/A4112"#commentary\cn_199_kitchen.mp3" "[ Kerry Davis ] Chez les développeurs de jeu vidéo, il existe une coutume très répandue : toute cuisine doit proposer une explosion de gaz."
N/A4113"#commentary\cn_200_alyxs_tool.mp3" "[ Laura Dubuk ] L'outil multifonction d'Alyx était extrêmement utile, car il pouvait obliger le joueur à l'attendre pour progresser. Nous avions souvent besoin de bloquer la progression du joueur jusqu'à ce que nous soyons prêts, et son outil multifonction lui permettait de parler tout en ouvrant la voie. Nous en avons sans doute légèrement abusé, mais il était difficile de résister à la tentation. De plus, utiliser Alyx pour coincer le joueur dans une salle au lieu de concevoir une solution personnalisée nous faisait gagner du temps que nous pouvions consacrer à d'autres aspects du jeu, généralement plus importants."
N/A4114"#commentary\cn_201_mossmans_betrayal.mp3" "[ Marc Laidlaw ] À l'origine, nous avions prévu que Judith Mossman trahirait le joueur à cet endroit. Mais lorsque nous avons commencé à travailler sur cette scène, après avoir développé d'autres parties du jeu, nous avons estimé qu'il serait plus crédible que son but soit en réalité de protéger Eli. Nous l'avons imaginée revoir sa position et réaliser qu'elle ne pouvait pas trahir Gordon. Nous avions des idées pour expliquer ce changement d'attitude un peu plus tard, mais au final, nous n'avons jamais achevé son arc narratif. Nous aimions l'ambiguïté de Mossman, mais ce n'était manifestement pas le cas des joueurs : presque tous la détestaient. Cela dit, on pourrait tout de même y voir une réussite. Après tout, nous avons tout fait pour que le joueur s'attache à Alyx, qui n'est pas non plus une grande fan de Judith."
N/A4115"#commentary\cn_202_d2_prison_05_start.mp3" "[ Yahn Bernier ] La possibilité pour le joueur de déplacer un grand nombre d'objets nous a souvent posé des difficultés, notamment en raison des contraintes imposées par les processeurs en 2003. L'une de ces contraintes était que le système de navigation de nos I.A. n'avait pas conscience des objets physiques, comme ces lits métalliques. Notre système de déplacement des PNJ pouvait détecter et éviter ces objets, mais ils étaient pour ainsi dire invisibles lors des requêtes de navigation nécessaires à la planification stratégique de ces déplacements. Cela était principalement dû à des limitations de performances : nous ne pouvions pas nous permettre de système plus complexe. D'autres défis de conception n'avaient pas de solution évidente. Par exemple, comment devrait réagir un soldat confronté à un joueur bloquant entièrement un couloir avec de gros objets physiques ? Nous avons commencé par conférer aux PNJ assez de force pour déplacer ces objets, puis avons atténué le problème dans la conception même des niveaux, en élargissant les couloirs et en veillant à laisser suffisamment d'espace vide à l'intérieur pour y manier les accessoires. Ici, la configuration est risquée : l'association des soldats se cachant derrière les lits et des fourmis-lions chargeant pour attaquer au corps-à-corps avait de fortes chances de donner lieu à des interactions bizarres entre le système de déplacement des PNJ et les lits."
N/A4116"#commentary\cn_203_alyx_as_companion.mp3" "[ Miles Estes ] Cette séquence est accidentellement devenue un prototype de ce que nous allions finalement proposer dans l'Épisode 1, à savoir Alyx en tant que compagnon, évoluant le long d'un itinéraire mêlant combats dynamiques et chorégraphies scriptées. Nous n'avions pas encore de modèle clair quant à sa place aux côtés du joueur dans ces scénarios, mais cette courte séquence nous a tout de même beaucoup appris, et ce malgré le peu de temps que nous avions pour la peaufiner."
N/A4117"#commentary\cn_204_laundry.mp3" "[ Mike Dussault ] Nous étions à peu près certains qu'au moment où les joueurs atteindraient ce niveau, que nous appelons Laverie, ils sauraient utiliser les appâts pour résoudre les situations de combat. Nous voulions donc augmenter les enjeux et créer un scénario qui les encouragerait à s'impliquer davantage en associant les appâts au reste de leur arsenal."
N/A4118"#commentary\cn_205_side_zombie.mp3" "[ Quintin Doroquez ] Lors des playtests, ce zombie empoisonné donnait toujours lieu à des moments marquants. Les joueurs, concentrés sur les soldats du Cartel, les fourmis-lions et les tourelles, n'ont plus vu un tel ennemi depuis un certain temps. Son apparition soudaine dans l'obscurité crée souvent un choc."
N/A4119"#commentary\cn_206_flares.mp3" "[ Quintin Doroquez ] En termes de coûts de production et d'itérations, cette séquence constitue un bon contrepoint avec celle des tourelles. Nous l'avons conçue très tard, mais rapidement, car les I.A. d'Alyx et des soldats du Cartel étaient déjà au point. L'idée des fusées éclairantes dans l'obscurité nous plaisant beaucoup, nous l'avons conservée pour l'explorer plus en détail. Plus tard, nous l'avons retravaillée lorsque nous avons imaginé les séquences dans le noir de l'Épisode 1."
N/A4120"#commentary\cn_207_magic_wall.mp3" "[ Robin Walker ] Comme pour la plupart de nos arènes de combat, nous avions besoin de bloquer la progression des joueurs pour les empêcher d'avancer avant la fin de l'affrontement. Malheureusement, par manque de temps et parce que nous devions commencer à travailler sur la gare, nous nous sommes rabattus sur une solution magique un peu facile : lorsque le deuxième hélico est abattu, un mur explose et dévoile le chemin à emprunter. Pour nous rassurer, nous nous disions que la majorité des joueurs ne s'en rendraient pas compte, trop occupés à affronter les hélicos, d'autant que la plupart des playtesteurs avaient déjà fini le combat avant d'atteindre ce point. Les multiples explosions dans l'arène rendant plus naturelle la présence de ce mur détruit et en flammes, nous avons ajouté de l'autre côté quelques énigmes simples à base de gaz. Le moins qu'on puisse dire, c'est que nous ne sommes pas vraiment fiers du résultat."
N/A4121"#commentary\cn_208_ragdoll_vortigaunt.mp3" "[ Scott Dalton ] La vision de ce Vortigaunt mort nous évoque une grande douleur... celle de nos level designers. À l'époque, nos outils de développement ne nous permettaient pas de placer directement un ragdoll. Autrement dit, lorsqu'un PNJ mourait et tombait comme une poupée de chiffon, nous n'avions aucun contrôle sur la position finale de son cadavre. Si nos animateurs avaient eu du temps à y consacrer, ils auraient pu nous fournir une animation d'une seule image reprenant à peu près la position que nous souhaitions, mais nous étions en retard et notre petite équipe d'animation était déjà surchargée. Par conséquent, un level designer a placé le Vortigaunt au-dessus de ce fauteuil, l'a paramétré pour mourir pendant le chargement du niveau, et a attendu de voir dans quelle position s'arrêterait le ragdoll. Ensuite, il a légèrement déplacé le Vortigaunt et réessayé. Nous ne pourrions pas vous dire précisément combien de tentatives ont été nécessaires pour obtenir ce résultat, mais quel que soit le nombre que vous avez en tête, sachez que c'est beaucoup, beaucoup plus."
N/A4122"#commentary\cn_209_nova_prospekt_process.mp3" "[ Eric Smith ] Tout comme Ravenholm, Nova Prospekt a initialement été conçue pour un gameplay totalement différent de ce qu'il était à la sortie du jeu. La première version présentait essentiellement des combats entre le joueur et des soldats du Cartel, sans aucune intervention des fourmis-lions. Contrairement à d'autres zones du jeu dont le gameplay et les graphismes évoluaient en parallèle, l'aspect artistique de Nova Prospekt a été développé très tôt. Nous disposions donc d'un ensemble de décors peaufinés, réutilisables et dont les graphismes avaient déjà été finalisés. Puisqu'il s'agit d'une prison, dont l'aménagement est naturellement répétitif, l'assemblage de Nova Prospekt à partir de ces éléments s'est déroulé sans accroc. Plus tard, lorsque nous avons introduit les fourmis-lions et les appâts, nous avons dû retravailler la géométrie des décors pour les adapter au nouveau gameplay."
N/A4123"#commentary\cn_210_d2_prison_04.mp3" "[ Eric Kirchmer ] Au cours du développement, nos graphistes créaient de petites tranches verticales d'environnement que nous appelions des \"zoos artistiques\". Ces zoos permettaient d'établir comment utiliser les textures et accessoires pour élaborer des espaces de jeu répondant à nos objectifs visuels. Lorsque nous avons conçu le parcours de gameplay de la prison, en revanche, son agencement répétitif nous a permis d'utiliser les graphismes plus directement. À l'origine, cette carte avait été conçue en tant que zoo artistique principal pour Nova Prospekt, mais après l'avoir utilisée pour tester divers prototypes de gameplay (dont ceux qui ont ensuite mené à la création des appâts), nous l'avons finalement intégrée à l'architecture finale du niveau."
N/A4124"#commentary\cn_211_autosave_dangerous.mp3" "[ Dave Riller ] Dans Half-Life 1, les level designers avaient placé tout au long du jeu un ensemble de points de sauvegarde automatique qui se déclenchaient lorsque le joueur atteignait un certain moment ou lieu dans le jeu. Ainsi, le jeu sauvegardait automatiquement à votre place tandis que vous progressiez dans les couloirs de Black Mesa. Pour Half-Life 2, nous avons dû créer un nouvel outil pour répondre à une problématique rencontrée dans certaines de nos arènes les plus complexes. Certains affrontements pouvaient durer longtemps et comporter plusieurs vagues d'ennemis, d'autres alternaient des séquences d'exploration et de combat sans proposer de coupure nette. Nous ne voulions pas de sauvegardes automatiques pouvant placer le joueur en danger de mort dès le chargement du jeu, car cela risquait de l'enfermer dans une boucle mortelle (si vous avez joué à de nombreux jeux de cette époque, cette situation vous évoque forcément de mauvais souvenirs). Ainsi, à moins d'ajouter délibérément des pauses dans le déroulement de chaque arène, il n'était pas toujours possible de placer un point de sauvegarde automatique. Après quelques expérimentations, nous avons mis en place une fonctionnalité appelée \"Autosave Dangerous\" (sauvegarde automatique dangereuse). Il s'agissait d'un outil à destination des level designers associant un point de sauvegarde automatique à un intervalle de temps défini. Une fois atteint, ce système créait automatiquement une sauvegarde, mais la gardait de côté, sans possibilité de la charger. Si le joueur restait en vie jusqu'à la fin du délai imparti, la sauvegarde était validée. Cela permettait aux designers de déterminer un endroit ou un moment raisonnable dans une arène, d'y placer un point de sauvegarde et de définir une durée, par exemple 30 secondes. Si le joueur était toujours en vie après ces 30 secondes, la sauvegarde automatique pouvait être utilisée."
N/A4125"#commentary\cn_212_we_dont_go_to_ravenholm.mp3" "[ Dario Casali ] Alors que nous achevions notre travail sur Ravenholm, nous sentions que la transition depuis le laboratoire d'Eli ne fonctionnait pas. Elle était bien trop brutale. Le labo était alors directement relié aux rues de la ville, que vous découvrirez bientôt, et la section dans laquelle vous vous trouvez actuellement n'existait pas. \"On ne va plus là-bas.\" Nous venions de faire cette promesse à la fin du labo d'Eli, et nous étions satisfaits de ce que nous étions parvenus à mettre en place, mais lorsque le joueur débarquait à Ravenholm, il devait directement combattre des zombies sans qu'aucune tension n'ait le temps de monter. Nous avons donc créé cette section et les étroits couloirs qui vont suivre pour installer cette tension comme nous le voulions. En ralentissant le rythme et en nous concentrant sur les graphismes et l'éclairage, nous vous avons préparés à découvrir pourquoi on ne va plus à Ravenholm."
N/A4126"#commentary\cn_213_lever_shenanigans.mp3" "[ Dario Casali ] Malgré tous nos efforts pour aider les joueurs à faire le lien entre ce levier et la clôture électrifiée à l'extérieur, certains playtesteurs l'abaissaient sans comprendre ce qu'ils venaient de faire. Certains allaient même jusqu'à déambuler dans la zone, revenaient activer le levier, puis repartaient errer un peu plus. Ne pouvant pas consacrer plus de temps à rendre ce lien encore plus évident, nous avons simplement décidé de casser le levier. Cela permettait d'éviter que les joueurs sapent leur progression, tout en renforçant l'idée que Ravenholm est une zone instable et délabrée."
N/A4127"#commentary\cn_214_town_arenas.mp3" "[ Dario Casali ] Arrivé à ce stade de Ravenholm, le joueur connaît tous les éléments de gameplay disponibles et peut prédire leurs interactions. Cela nous a permis de construire des situations plus complexes et plus menaçantes, tout en accordant davantage de liberté au joueur dans son approche. Dans cette arène délibérément labyrinthique, nous profitons du temps qu'il va devoir consacrer à explorer la zone pour augmenter progressivement l'intensité du combat. Plus l'exploration est rapide, plus l'intensité augmente rapidement. En raison de son design libre, il n'a pas été facile d'ajuster les différents aspects de cette zone, car les joueurs l'abordaient de manière très variée."
N/A4128"#commentary\cn_215_mines.mp3" "[ Dario Casali ] L'itinéraire complexe que doit emprunter le joueur pour descendre dans ce puits de mine lui donne largement assez de temps pour voir ce qui l'attend en bas. Et surprise, ce sont des crabes de tête. Bon, pour être honnête, c'est souvent le cas. Seulement, cette fois, il y a aussi des crabes de tête empoisonnés, qui sont tout de suite moins amusants lorsqu'ils sont accompagnés de crabes de tête rapides. En effet, ces deux bestioles s'associent parfaitement : seules, elles sont quasiment inoffensives, mais ensemble, elles deviennent particulièrement létales. Une fois le joueur empoisonné, le moindre coup porté par un crabe de tête rapide suffit à le tuer. C'est ce que les biologistes appellent la symbiose. Enfin, je crois."
N/A4129"#commentary\cn_216_poison_headcrabs.mp3" "[ David Speyrer ] Cette salle introduit involontairement les crabes de tête empoisonnés. Nous avons passé beaucoup de temps à peaufiner leur véritable introduction un peu plus loin dans le niveau, mais après avoir vu à quel point ils fonctionnaient bien lors des playtests, nous nous sommes laissé porter par notre enthousiasme et en avons placé un peu partout dans Ravenholm. Quand nous avons réalisé qu'ils apparaissaient avant leur introduction officielle, il était trop tard pour y remédier. Par chance, cette petite salle est parfaite pour apprendre au joueur à affronter ces créatures, car leur design évite un problème récurrent dans les entraînements au combat. Les joueurs peuvent se frustrer quand ils meurent de façon répétée sans comprendre pourquoi, et fatalement, c'est ce qui se passait quand nous essayions de leur apprendre à affronter simultanément les crabes de tête empoisonnés et leur porteur, le zombie empoisonné. Seuls, toutefois, ces crabes ne peuvent pas tuer le joueur. Une salle qui en est remplie reste donc stressante, mais ne provoque pas de frustration."
N/A4130"#commentary\cn_217_poison_zombie_introduction.mp3" "[ David Speyrer ] Confiner le joueur dans un espace restreint tout en lui offrant une vue sur l'extérieur augmente les chances de lui faire remarquer ce que nous voulons lui montrer. Ici, nous attirons son attention avec un gémissement avant que le zombie empoisonné entre dans son champ de vision. À l'origine, cet affrontement devait également être la première rencontre entre le joueur et les crabes de tête empoisonnés, mais comme nous l'avons expliqué dans un commentaire précédent, nous avons fait preuve d'un excès d'enthousiasme en multipliant la présence de ces petites bêtes à travers le niveau et avons accidentellement saboté leur introduction conjointe dans cette scène. En fin de compte, cependant, ces premières rencontres fonctionnent mieux séparément."
N/A4131"#commentary\cn_218_final_arena.mp3" "[ Eric Smith ] Quand nous avons terminé notre première passe de travail sur Ravenholm, ce toit devait accueillir le combat final du niveau. Comme d'autres zones de Ravenholm, il s'agissait à l'origine d'un espace visuellement très intéressant. Nous voulions que le joueur prenne le temps, juste avant de la quitter, d'observer la ville à laquelle il venait de survivre, tout en ayant un aperçu de sa prochaine destination. Plusieurs groupes de game designers ont essayé d'élaborer un combat ici, mais en raison de la géométrie restreinte et des limitations de performances, nous n'avons pas réussi à obtenir l'apothéose que nous recherchions. À l'image de la saga Half-Life dans son ensemble, Ravenholm semblait destinée à ne jamais connaître de véritable conclusion."
N/A4132"#commentary\cn_219_tables_and_bodies.mp3" "[ Ido Magal ] Vers la fin de la production de Ravenholm, une fois les éléments majeurs bien en place, nous avons passé le niveau au crible pour trouver le moindre espace vide et y ajouter quelque chose d'intéressant. Nous devions impérativement puiser dans la matière dont nous disposions déjà, car introduire de la nouveauté risquait de générer de nouveaux bugs. Nous avons principalement essayé de créer des moments de gameplay tout en étoffant la narration environnementale, comme dans cette pièce. Les petites scènes comme celle-ci permettent aux joueurs attentifs de réfléchir à ce qu'ils voient, et à ce que cela peut augurer pour la suite de leur aventure."
N/A4133"#commentary\cn_220_physics_object_consistency.mp3" "[ Kerry Davis ] Tous les objets physiques sont dotés d'un éventail de paramètres déterminant leur comportement : leur masse, la quantité de dégâts qu'ils peuvent subir avant de casser, comment ils vont se briser, etc. Comme une majorité des éléments du jeu, ces paramètres ont été spécifiés pour chaque objet au cours du développement par les level designers. Plus tard, cependant, nous avons réalisé que nous n'avions mis en place aucune méthode pour garantir une quelconque cohérence entre les milliers d'objets physiques présents dans le jeu. En d'autres termes, un carton destructible en un seul tir de pistolet dans un niveau pouvait être invulnérable dans un autre. En interne, nous appelions généralement ces incohérences des \"crimes de design\". Afin d'y remédier, et pour que justice soit faite, nous avons conçu un système permettant d'assurer une certaine cohérence entre tous les objets physiques en fonction de leur modèle visuel. La majeure partie du jeu ayant déjà été conçue, nous avons dû autoriser les level designers à déroger à ce système dans les rares cas où ils avaient besoin de préserver ce qu'ils avaient créé. Encore aujourd'hui, certains de ces récidivistes poursuivent leurs activités criminelles au sein de Valve."
N/A4134"#commentary\cn_222_fast_zombie_introduction.mp3" "[ Randy Lundeen ] À l'origine, cette zone a également été conçue pour être présentée à l'E3 2003, mais le joueur y affrontait une unité de soldats du Cartel. Quand nous avons décidé de plutôt l'utiliser pour introduire le zombie rapide, nous avons cherché à conserver un maximum du travail déjà effectué. Nous voulions créer un plan emblématique, avec des zombies bondissant au clair de lune tels des loups-garous pour attirer l'attention du joueur. Une fois ce moment passé, le premier zombie rapide apparaît dans l'espace du joueur et lui fonce dessus. De nombreuses itérations ont été nécessaires pour que l'éclairage mette la scène en valeur sans nuire aux objectifs de gameplay."
N/A4135"#commentary\cn_223_ravenholm_gameplay_focus.mp3" "[ Mike Dussault ] Après avoir observé de nombreux playtests de Ravenholm, nous savions que le gameplay du niveau était axé autour du pistolet anti-gravité et de la physique. Sachant cela, nous avons estimé pouvoir créer une transition vers Ravenholm, enseigner des astuces au joueur et lui donner une idée de l'expérience qu'il s'apprêtait à découvrir. Cela arrive souvent : nous construisons la trame du niveau, déterminons ce qui fonctionne le mieux, puis nous créons le prologue. C'est sur ce plan que nous nous sommes basés pour concevoir les salles suivantes. La brutalité des outils que nous fournissons au joueur a participé à créer le changement de ton que nous recherchions, en passant de la sécurité du laboratoire d'Eli à une ambiance plus sombre et effrayante."
N/A4136"#commentary\cn_224_player_tools.mp3" "[ Steve Bond ] À ce stade du jeu, les joueurs ont déjà une certaine expérience de la physique de Half-Life 2, mais ils viennent tout juste de recevoir le pistolet anti-gravité, qui leur permet d'interagir de manière inédite avec les éléments du jeu. Nous avons expérimenté avec tout un tas d'objets, comme les scies circulaires, les catapultes, les bonbonnes explosives, les pièges, les pieux, etc., pour peaufiner ceux qui se prêtaient le mieux à l'utilisation du pistolet anti-gravité et retirer les autres. Nous avons ensuite réduit les possibilités de ramasser des munitions afin de pousser le joueur à utiliser ces objets pour survivre."
N/A4137"#commentary\cn_225_contrived_setups.mp3" "[ Kerry Davis ] Une bonne partie des séquences d'entraînement au maniement du pistolet anti-gravité et des objets physiques sont cousues de fil blanc. Le joueur utilise sa nouvelle arme pour arracher une scie circulaire plantée dans un mur ? Un zombie choisit précisément ce moment pour apparaître, comme s'il demandait à se faire découper. Le joueur s'accroupit pour désactiver une lame tournante ? Trois zombies débarquent, l'incitant à réactiver le piège. Nous n'avions pas beaucoup de temps pour peaufiner cette section, c'est pourquoi nous avons créé des situations pouvant fonctionner pour tous les joueurs, et non pas des événements plus ouverts nécessitant qu'ils adoptent le \"bon\" comportement. Cette méthode de conception peut limiter la créativité des joueurs, car nous leur forçons un peu la main, mais dans ce cas précis, nous avons constaté que cela n'avait pas vraiment l'air de les déranger."
N/A4138"#commentary\cn_226_misteaching_flinches.mp3" "[ Kerry Davis ] Ravenholm a été le théâtre d'un autre playtest mémorable constituant un parfait exemple du danger lié aux apprentissages imprévus. Nous voulions que le jeu réagisse au maximum aux actions du joueur, c'était l'un de nos principes de conception. Ainsi, lorsque nous avons imaginé le pistolet anti-gravité, il nous paraissait évident que si le joueur le pointait en direction d'un zombie et pressait la détente, il devait se passer quelque chose. Nous avons fait en sorte que l'arme envoie une petite décharge et inflige juste assez de dégâts au zombie pour provoquer son animation de tressaillement. L'effet était à la fois réactif et satisfaisant. Plus tard, nous avons assisté à un playtest lors duquel le joueur a découvert cette interaction dès son arrivée à Ravenholm et en a déduit que le pistolet anti-gravité infligeait des dégâts au zombie... ce qui était techniquement le cas, mais à un degré très faible. Ce joueur a donc continué à tirer sur le zombie de manière répétée, l'électrocutant en boucle jusqu'à le tuer. Quand vous êtes entouré de scies circulaires et de bonbonnes explosives, c'est une méthode à la fois lente, fastidieuse et inhumaine de combattre des zombies. Ayant appris notre leçon, nous avons supprimé l'animation de tressaillement, même si cela impliquait de perdre cette interaction entre l'arme et le zombie. Il était préférable d'accepter cette perte plutôt que de donner la fausse impression qu'on pouvait affronter efficacement ces ennemis avec le pistolet anti-gravité. Dès que vous entrez dans les détails, même les principes les plus simples nécessitent parfois de faire des compromis."
N/A4139"#commentary\cn_227_fire_trap.mp3" "[ Steve Bond ] Ce piège de flammes devait initialement servir à mettre en avant notre système de feu, jusqu'à ce qu'un level designer le transforme en élément de gameplay pour Ravenholm. Il a failli être supprimé plusieurs fois au cours du développement, car le recouvrement de pixels impliqué par les sprites transparents entraînait des pertes de performances sur les PC d'entrée de gamme. Finalement, un programmeur a estimé que sa plus-value pour le gameplay valait les efforts nécessaires pour résoudre ces problèmes de performances et nous permettre de le conserver dans le jeu."
N/A4140"#commentary\cn_228_hallway_cupboards.mp3" "[ Yahn Bernier ] Ces couloirs remplis de bric-à-brac étaient une solution toute simple à notre besoin de ralentir la progression du joueur. Entre la contrainte de conserver au maximum la géométrie existante et des zombies se déplaçant lentement comme ennemis principaux, il n'était pas facile d'empêcher les joueurs de foncer à travers Ravenholm. Heureusement, la présence de ces obstacles était aisément justifiable par l'existence d'un habitant complètement fou, Grigori : il est parfaitement raisonnable de penser qu'il ait pu obstruer les escaliers pour rester en sécurité sur les toits. Au final, la solution de Grigori et la nôtre se rejoignaient : balancer un tas de meubles dans le passage. Après tout, si c'est assez efficace pour bloquer des zombies, ça l'est probablement aussi pour ralentir le joueur."
N/A4141"#commentary\cn_229_pacing_switch.mp3" "Maintenant que les joueurs ont terminé la section d'initiation, nous pouvons commencer à changer le rythme en passant des espaces moroses et claustrophobes à des arènes orientées sur le combat. Et puisqu'ils se sont habitués aux divers outils physiques de l'environnement, il est désormais possible de les intégrer à des espaces ouverts afin de laisser les joueurs choisir l'approche qui leur correspond le mieux."
N/A4142"#commentary\cn_230_car_crushers.mp3" "[ Steve Bond ] Ces voitures broyeuses ont nécessité plusieurs ajustements et beaucoup de travail sur notre système de dégâts physiques. Les interactions entre de gros objets et des PNJ représentent toujours un défi. Par exemple, si la physique peut pousser un PNJ, il existe une possibilité qu'il se retrouve dans un endroit où il n'est pas censé aller. Cela ne pose pas de problème avec un crabe de tête, qui peut simplement s'échapper en bondissant, mais si le PNJ en question est un zombie, il risque de rester coincé et de se débattre de manière grotesque en cherchant vainement à vous atteindre. Et cela ne correspond pas tout à fait à l'ambiance \"survival horror\" que nous voulions créer."
N/A4143"#commentary\cn_231_car_crusher_lifts.mp3" "[ Eric Smith ] Il n'a pas été simple de faire en sorte que les voitures broyeuses puissent soulever le joueur. Le joueur est simulé en permanence à la fois par le moteur physique et par le système de déplacement du jeu. À chaque actualisation de son état, nous comparons les résultats obtenus par les deux systèmes et décidons celui qui est \"corrrect\", puis nous les synchronisons et recommençons. Les deux systèmes peuvent ainsi s'influencer mutuellement : si le joueur monte sur une balançoire à bascule, le moteur physique fait s'abaisser la planche ; s'il se tient sur une voiture broyeuse, il le soulève. Cette méthode à deux systèmes, bien que plus complexe, était plus facilement ajustable que si nous avions essayé de traiter la physique et les déplacements du joueur conjointement. En les séparant, nous pouvions régler le système de déplacement avec précision pour qu'il fonctionne parfaitement tout seul, et ne concilier les deux que lorsque la physique affectait le joueur."
N/A4144"#commentary\cn_232_paint_cans.mp3" "[ Steve Bond ] Une fois le pistolet anti-gravité et la physique placés au cœur du gameplay de Ravenholm, nous avons commencé à fouiller les niveaux à la recherche d'objets que nous aurions potentiellement négligés, concentrés jusque-là sur des éléments agressifs comme les scies circulaires ou les bonbonnes explosives. C'est comme ça que nous sommes tombés sur les pots de peinture, notamment. En éclaboussant les zombies lorsque vous leur en jetez un à la figure, ils nous ont facilement permis de renforcer les attentes du joueur."
N/A4145"#commentary\cn_233_bringing_physics_to_the_enemies.mp3" "[ Tom Leonard ] Les pièges physiques de Ravenholm faisaient partie des premiers éléments du niveau dont nous étions réellement satisfaits, mais le joueur n'avait aucun contrôle dessus. Les scies circulaires nous ont alors permis de réaliser le vrai potentiel de Ravenholm : grâce à elles, le joueur pouvait utiliser la physique contre les zombies et non plus se contenter de guider les zombies vers les pièges physiques. Une fois que nous avons compris cela, Ravenholm a rapidement évolué. Nous ratissions continuellement la carte à la recherche du moindre élément, si possible insolite, pouvant être utilisé comme un outil ou une arme par le joueur."
N/A4146"#commentary\cn_234_ravenholm_development.mp3" "[ Tom Leonard ] Le développement de Ravenholm ayant commencé très tôt dans la production de Half-Life 2, le niveau a connu de nombreuses itérations. Dans la première version, il n'y avait pas encore de pistolet anti-gravité, et le gameplay consistait principalement à combattre des zombies à l'aide d'armes traditionnelles et de quelques pièges physiques. Nous avions même prévu de présenter Ravenholm à l'E3 en 2002, mais le jeu n'a finalement été dévoilé que l'année suivante. À ce stade, nous avions déjà beaucoup investi dans l'aspect visuel du niveau, ce que nous évitons généralement de faire avant d'en avoir parfaitement établi le gameplay. Ainsi, quand nous avons retravaillé Ravenholm autour de la mécanique du pistolet anti-gravité, nous avons dû composer avec une architecture de niveau préexistante conçue en grande partie pour un gameplay totalement différent."
N/A4147"#commentary\cn_235_grigori_plaza.mp3" "[ Steve Bond ] Cet espace ouvert est l'une des zones que nous avions détaillées dès la première phase de développement. Lorsque nous l'avons retravaillée, nous voulions conserver autant d'éléments graphiques que possible tout en concevant un nouvel itinéraire de joueur tirant parti des trois dimensions, qui passerait par les fenêtres, sur les toits, d'un bâtiment à l'autre... L'espace disponible étant relativement restreint, il a fallu optimiser le parcours. Et puisque la zone était initialement portée par ses graphismes, le gameplay y était minimal et les playtesteurs avaient tendance à la traverser à toute vitesse, un problème qu'il nous fallait résoudre. Et pour couronner le tout, elle éprouvait déjà les limites de notre moteur de rendu, ce qui laissait peu de place pour des nouveautés. Nous avons donc cherché à ralentir la progression du joueur par petites touches, en ajoutant des menaces dans les moindres recoins du niveau."
N/A4148"#commentary\cn_236_ravenholm_development_2.mp3" "[ Tom Leonard ] Quand des fans viennent nous parler de Half-Life 2, Ravenholm est généralement le chapitre dont ils ont le plus de souvenirs. Grâce à ses multiples phases de développement et à la densité de matériaux qu'elle contient, davantage de membres de l'équipe sont représentés à Ravenholm que dans n'importe quelle autre zone. C'est là que nous avons compris comment appliquer notre pipeline artistique aux scènes et au ton que nous voulions obtenir, comment combiner la physique et le gameplay grâce au pistolet anti-gravité, comment faire évoluer les crabes de tête et les zombies, et bien plus encore. Avec le recul, cela renforce notre conviction que la responsabilisation individuelle prime sur la conception centralisée. Ravenholm, zone dense et extrêmement efficace dans son exécution artistique comme dans son gameplay, est la somme de nombreuses contributions mineures de la part d'individus ayant compris qu'ils pouvaient l'améliorer ne serait-ce qu'un peu grâce à leurs capacités personnelles."
N/A4149"#commentary\cn_237_playtester_archetypes.mp3" "[ Tom Leonard ] Les itérations et les playtests fréquents étaient les pierres angulaires de la production de Half-Life 2. Chaque semaine, nous observions un playtesteur traverser de bout en bout la section sur laquelle nous travaillions, et nous prenions des notes sur ce qui marchait ou pas. Nous nous efforcions de sélectionner des joueurs de tous niveaux pour veiller à ce que les décisions prises fonctionnent auprès du plus grand nombre. Avec le temps, nous avons appris à sélectionner des types de testeurs spécifiques en fonction de la phase de développement dans laquelle nous nous trouvions. Au départ, nous choisissions des joueurs expérimentés, généralement des membres de l'équipe, capables à la fois de traverser des zones en cours de développement et d'expliquer leur réflexion et leurs choix. Pour tester le combat, nous cherchions des joueurs de niveaux hétérogènes, de préférence créatifs dans leur utilisation des outils. Enfin, une fois les différentes sections peaufinées, nous sélectionnions des débutants, qui jouaient rarement aux jeux vidéo ou n'étaient pas familiers des FPS. Même lorsqu'ils ne correspondaient pas au profil de joueur susceptible d'acheter le jeu, nous apprenions toujours quelque chose d'utile en les observant. "
N/A4150"#commentary\cn_238_the_real_final_arena.mp3" "[ Tom Leonard ] Vers la fin du développement, alors que nous passions en revue l'intégralité du jeu à la recherche de points à améliorer, nous avons décidé que nous voulions finalement offrir une véritable conclusion à Ravenholm. L'affrontement sur le toit ne suffisait pas. Nous avons donc choisi d'ajouter cet ultime combat à travers le cimetière aux côtés de Grigori. C'était une décision risquée en termes de développement, mais que nous estimions nécessaire pour le jeu. Puisque nous approchions du terme de la production, nous disposions d'un ensemble d'outils de gameplay éprouvés et, plus important encore, nous comprenions désormais notre propre jeu. Développer un jeu revient souvent à découvrir ce que vous êtes en train de créer. Pourquoi notre jeu est-il amusant ? En quoi est-il différent ? Quels sont ses éléments les plus importants ? En progressant dans le développement et en observant des playtesteurs en action, nous avions obtenu des réponses à ces questions et nous nous étions améliorés. Ainsi, la création du cimetière a été rapide et a nécessité beaucoup moins d'itérations que la plupart des zones précédentes."
N/A4151"#commentary\cn_239_cities.mp3" "[ Eric Kirchmer ] L'un des défis majeurs posés par cette section du jeu était de faire en sorte que le joueur ait l'impression d'évoluer dans une ville tentaculaire, alors que nos budgets de performances ne nous permettaient clairement pas d'en bâtir une. C'est pourquoi nous nous sommes concentrés sur des immeubles, des parkings souterrains, des tunnels de métro, des ponceaux et autres espaces similaires. Des lieux urbains communs, mais qui empêchent généralement de voir l'horizon. Nous avons ensuite enrichi ce style de level design à l'aide de points d'observation, des zones offrant un vaste panorama au joueur, où nous pouvions consacrer l'intégralité de notre budget de performances à la vue sans avoir à gérer des PNJ ou des combats."
N/A4152"#commentary\cn_240_strider_4.mp3" "[ Eric Smith ] Cette carte a été conçue pour le strider lors de la phase de production, mais pendant le développement, nous en utilisions une autre pour tester son I.A. Disposer d'une carte de test fiable pour une I.A. a toujours été important à nos yeux, car cela nous permettait d'expérimenter et de peaufiner facilement de nouvelles idées de gameplay. Nous pouvions également isoler et résoudre plus rapidement les bugs et autres problèmes de conception. Une fois l'I.A. fonctionnelle, nous l'intégrions aux cartes de production pour que les level designers puissent s'en servir. La carte de test du strider incluait des silhouettes grossières de bâtiments en ruines, ainsi que des points d'apparition de citoyens inépuisables situés à diverses positions pour assurer un flux de cibles constant. Cette configuration nous a permis d'améliorer l'I.A. et les changements de posture du strider afin de le rendre le plus intéressant possible à affronter ou à observer de loin."
N/A4153"#commentary\cn_241_perf_arena.mp3" "[ Aaron Seeler ] Cette arène représentait un sérieux défi en termes de performances. Sa taille, l'I.A. du strider et celle des citoyens poussaient notre moteur dans ses retranchements. Quand nous avons effectué le portage de Half-Life 2 sur Xbox, nous avons dû apporter quelques ajustements. Préserver l'intention initiale et proposer la même expérience de jeu avec moins d'outils et d'espace était un exercice particulièrement délicat."
N/A4154"#commentary\cn_242_space_re-use.mp3" "[ Chris Green ] Le fait de revenir dans cette zone présentait de nombreux avantages. Commençons par le plus évident : les coûts de production sont systématiquement plus élevés pour une nouvelle zone. Pouvoir rajouter des éléments de gameplay à une zone existante est toujours bénéfique. Et pour un combat aussi difficile que celui-ci, qui demande d'affronter plusieurs striders à la fois, cette réutilisation était encore plus intéressante : puisque les joueurs ont déjà traversé cette arène, ils ont déjà une idée de sa configuration. Cette fois, ils la parcourent en sens inverse, mais ce nouvel itinéraire est globalement le même que l'original. Cette familiarité est particulièrement utile lorsque les joueurs doivent se déplacer afin de ramasser des ressources pour le combat. Le fait que Cité 17 soit en état de guerre nous donnait également la flexibilité nécessaire pour modifier les abris, ajouter de petits obstacles sur le trajet et proposer un environnement dynamique et surprenant."
N/A4155"#commentary\cn_243_tenements_and_courtyards.mp3" "[ Danika Rogers ] Il nous a fallu recourir à un certain nombre de petites astuces et concevoir diverses fonctionnalités pour donner aux joueurs l'impression d'évoluer dans une ville en guerre, notamment en leur offrant des aperçus d'escarmouches ou en leur permettant d'entendre de lointains bruits de combat. Les \"Looktargets\" nous servaient à introduire de petits événements chaque fois que le joueur regardait à travers une fenêtre, tandis que nos designers utilisaient des outils comme les \"Tracer Makers\" (générateurs de traceurs) pour créer de faux tirs de balles traçantes entre deux points. Associés à des outils audio, cela nous permettait de simuler des combats entre deux groupes d'ennemis sans avoir à utiliser la moindre I.A. Nous avons également élaboré des petits scénarios liés à des groupes de citoyens que le joueur peut apercevoir à plusieurs reprises à mesure qu'il progresse dans le niveau. Tous ces moments ont été peaufinés lors des playtests pour veiller à ce qu'un maximum de joueurs les découvre."
N/A4156"#commentary\cn_244_hopper_mine_training.mp3" "[ Dario Casali ] Nous avons délibérément placé cette planche métallique sur le trou afin d'encourager les joueurs à utiliser leur pistolet anti-gravité pour retirer l'obstacle. Nous avions constaté que cet entraînement était bien plus efficace lorsque les joueurs essayaient immédiatement d'utiliser leur pistolet anti-gravité sur les mines, et la présence de cette plaque de tôle augmentait grandement les probabilités qu'ils l'équipent. Nous avons disposé plusieurs mines dans le trou pour offrir aux joueurs plusieurs occasions d'interagir avec et augmenter leurs chances de découvrir des méthodes alternatives pour s'en débarrasser. De plus, c'est la première fois que nous soumettons les joueurs à un entraînement alors qu'ils sont suivis par une escouade de citoyens, nous en avons donc profité pour inclure quelques lignes de dialogue mentionnant les mines."
N/A4157"#commentary\cn_245_dog_combat.mp3" "[ Eric Kirchmer ] Chien est un super personnage, et nous avons cherché différentes manières de le faire combattre aux côtés du joueur. Cependant, concevoir un combat à son échelle nécessitait un environnement approprié, une nouvelle I.A. pour les ennemis, voire de nouveaux ennemis. Autant dire que cela dépassait rapidement le cadre du projet. Pour créer un scénario de combat faisant honneur à Chien et rivalisant avec le reste de Half-Life 2, nous devions presque construire un nouveau jeu dans le jeu. Nous ne pouvions pas simplement l'utiliser pour foncer sur un soldat et le frapper : cela n'aurait pas été impressionnant et n'aurait suscité aucun émerveillement. Il avait besoin d'une menace à sa hauteur et de moyens intéressants pour l'affronter. En fin de compte, nous avons décidé de créer une grande scène chorégraphiée pour donner à Chien l'occasion de briller au combat tout en éliminant le besoin de concevoir un gameplay personnalisé complexe."
N/A4158"#commentary\cn_246_strider_2.mp3" "[ Eric Kirchmer ] Les différentes itérations requises pour parfaire le gameplay du strider nous ont permis de proposer l'expérience que nous recherchions, où les joueurs doivent foncer d'un abri à l'autre en évitant les tirs ennemis tout en cherchant des roquettes. Afin qu'ils aient régulièrement l'impression de s'être mis à couvert à la dernière seconde, nous avons ajusté le schéma des tirs en rafale de l'ennemi pour transmettre un sentiment de danger imminent. Nous avons également conçu un système de rails que le strider devait suivre pour traquer le joueur ou trouver une ligne de tir. Les level designers ont ensuite soigneusement aligné les rails du strider sur les abris à disposition du joueur afin d'équilibrer l'expérience. Le positionnement des pattes du strider étant entièrement géré par le code, nous avons dû modifier un certain nombre d'éléments pour veiller à ce qu'il renverse systématiquement des voitures ou des transports de troupes lorsque c'était nécessaire."
N/A4159"#commentary\cn_247_manhack_tunnels.mp3" "[ Eric Smith ] Développer le comportement de l'I.A. d'un PNJ était toujours plus simple lorsque le programmeur de l'I.A. pouvait expérimenter sur une carte de test, qui évoluait souvent en un environnement spécifiquement conçu pour mettre en valeur les capacités uniques du PNJ en question. Ensuite, lorsque l'I.A. était prête à être utilisée par les level designers, la carte de test devenait une référence précieuse. Sans elle, les designers pouvaient accidentellement créer des scénarios n'exploitant pas pleinement les caractéristiques de l'I.A. Dans certains cas, nous avons pu intégrer ces cartes de test directement dans le jeu. Cette courte section, par exemple, était initialement une série de tunnels que nous avons utilisés pour développer l'I.A. des robots-lames."
N/A4160"#commentary\cn_248_sniper_streets_2.mp3" "[ Erik Johnson ] Dans Half-Life 2, les balles ne suivent pas une véritable trajectoire de vol, elles atteignent instantanément leur cible. En revanche, le sniper disposant d'une faible cadence de tir et le joueur étant attentif à chacun de ses tirs, nous voulions simuler la trajectoire de ses balles. De plus, cette méthode fonctionnait bien avec la visée laser : celle-ci se décale légèrement au moment du tir et la durée qui s'écoule avant que la balle touche sa cible dépend de la distance à laquelle se trouve le tireur. Cependant, ce changement entraînait un nouveau problème : afin d'éviter que les joueurs se contentent de sprinter pour esquiver les tirs, il fallait que le sniper soit capable de suivre une cible mouvante et de prédire où devait arriver sa balle. Anticiper la position future du joueur était délicat, car un changement de direction peut se faire beaucoup plus brièvement dans le jeu que dans le monde réel. Nous avons donc ajouté des vérifications supplémentaires pour détecter différents comportements comme, par exemple, les joueurs appuyant rapidement à gauche et à droite en courant."
N/A4161"#commentary\cn_249_triangle_plaza.mp3" "[ Ido Magal ] Cet affrontement sur la place est une situation complexe, où le comportement Assaut est utilisé avec deux lignes de bataille convergentes, une pour chaque champ de force. Quand les soldats apparaissent derrière ces champs de force, ces lignes les empêchent de foncer seuls vers la place. À mesure que le combat se déroule, le nombre de soldats augmente et les lignes de bataille commencent à progresser vers le centre de la place, et les ennemis peuvent submerger le joueur s'ils ne sont pas repoussés."
N/A4162"#commentary\cn_250_sniper_streets_3.mp3" "[ Jakob Jungels ] L'une des fonctionnalités que nous avons tenté d'intégrer à cette section était le tir de suppression. De nombreux joueurs, retranchés à l'extrémité de la rue, tiraient des rafales en direction de la fenêtre du sniper pour voir si cela avait un effet quelconque. Nous avons donc essayé de faire vaciller le laser quelques instants pour laisser le temps aux joueurs de se déplacer. Après quelques playtests, cependant, nous avons rencontré deux problèmes. Tout d'abord, cela perturbait nos objectifs de gameplay : nous voulions créer de la tension en forçant le joueur à courir pour se cacher du sniper. Or, le pousser à tirer en sprintant était peu ou prou ce que nous lui demandions de faire dans le reste de Cité 17. Le second problème, plus subtil, était que les joueurs découvrant directement le tir de suppression partaient du principe qu'il était indispensable à la traversée du niveau. Ceux qui tombaient à court de munitions à mi-chemin abandonnaient souvent, pensant avoir échoué, et la plupart de ceux qui arrivaient jusqu'au bout avaient vidé leurs chargeurs. À l'inverse, les joueurs terminant ce scénario avec une approche furtive ne tiraient presque aucune balle. Avec une telle différence dans l'utilisation des ressources, il était quasiment impossible d'équilibrer la quantité de munitions disponibles pour les sections suivantes. Par conséquent, nous avons décidé de ne pas l'intégrer à la version finale du jeu."
N/A4163"#commentary\cn_251_assault_behavior.mp3" "[ John Cook ] Le comportement le plus complexe que nous avons conçu pour Half-Life 2 est \"l'Assaut\", utilisé au cours de cette séquence du jeu. Il permettait aux level designers de créer des scénarios de combat impliquant des soldats du Cartel et des citoyens, d'établir des lignes de bataille entre ces deux factions et de contrôler l'évolution des combats en fonction des actions du joueur. Selon l'emplacement des lignes de bataille, les PNJ impliqués dans un Assaut cherchent des positions de tir ou des abris. La progression du joueur le long d'une rue peut faire bouger la ligne de bataille, ce qui provoque l'avancée des citoyens alliés et le repli des soldats ennemis. Dans d'autres cas, pour que cette ligne avance, le joueur doit renverser des tourelles du Cartel ou éliminer un ennemi derrière une barricade."
N/A4164"#commentary\cn_252_bank_roof_mortar.mp3" "[ John Morello ] Quand nous en sommes arrivés à construire cette partie du niveau, il était évident qu'il serait sympa pour les joueurs de pouvoir utiliser le mortier. À vrai dire, il est étonnant que nous n'y ayons pas pensé plus tôt. \"À ton avis, tirer des explosifs dans le ciel et les regarder s'abattre sur les méchants, ça pourrait plaire aux joueurs ? ... Ouais, je pense aussi.\" Bref, après tout ce temps passé à se faire pilonner, offrir au joueur une occasion de répliquer en attaquant le Cartel avec ses propres armes nous paraissait une récompense appropriée. En revanche, dès que nous avons commencé à étudier cette idée, nous nous sommes rendu compte de la quantité de travail que cela impliquerait. Bon, pour être honnête, quand on développe un jeu vidéo, c'est le genre de réflexion que l'on se fait au quotidien. Si le joueur devait s'en approcher, le mortier aurait besoin d'effets et d'animations, et il faudrait consacrer des efforts pour augmenter le nombre d'ennemis sur la place en contrebas afin qu'ils servent de cibles. Plus important encore, nous n'avions pas prévu d'interface pour cette arme unique. Comment les joueurs pourraient-ils viser et tirer avec ? Passer un temps aussi considérable sur un seul moment du jeu n'étant ni très agréable ni justifiable, nous avons décidé que nos efforts seraient mieux employés ailleurs. Désolé ! Peut-être parviendrons-nous à résoudre ce dilemme du mortier dans un futur épisode de la série Half-Life, qui sait ?"
N/A4165"#commentary\cn_253_strider.mp3" "[ Kerry Davis ] C'est dans cette arène, devant la banque, que nous avons fini par trouver que faire du strider. Quand nous avons vu les illustrations conceptuelles de cet ennemi pour la première fois, nous avons tout de suite su que nous voulions l'intégrer au jeu, mais pour que cela fonctionne dans la pratique, il nous fallait résoudre plusieurs problèmes. Nous n'avions jamais fait se déplacer un objet de cette taille dans notre univers, et puisqu'un ennemi aussi grand se devait d'être dangereux, comment les joueurs allaient-ils pouvoir l'affronter ? Quelle expérience de jeu allions-nous pouvoir proposer avec le strider ? De quels outils les level designers auraient-ils besoin pour créer des scénarios lui faisant honneur ? Toutes nos expérimentations sur cette carte avaient pour but de répondre à ces questions."
N/A4166"#commentary\cn_254_sniper_streets.mp3" "[ Eric Kirchmer ] C'est dans ces rues truffées de snipers que nous avons développé à la fois ce type d'ennemi et le cœur de l'expérience que nous espérions proposer. Nous savions que nous voulions voir les snipers tirer sur des objets proches du joueur, nous avons donc commencé par leur chercher des cibles variées et intéressantes. Pour cette étape, adopter le point de vue du joueur s'est révélé efficace. La visée laser du sniper étant toujours activée, les joueurs sont informés en permanence de ce qui retient l'attention du sniper. Ainsi, voir le laser se déplacer vers la cible du regard du joueur paraissait extrêmement réactif et donnait lieu à d'incroyables moments de tension."
N/A4167"#commentary\cn_255_citizen_squad_details.mp3" "[ Matt Wright ] Après avoir rassemblé des citoyens dans cette escouade, nous avons commencé à élaborer des scénarios articulés autour d'elle et découvert que cela ouvrait des possibilités intéressantes. Les playtesteurs ont commencé à s'attacher à des membres spécifiques de l'unité, alors nous avons approfondi leur design, leur permettant de ramasser des armes plus efficaces que les leurs, de donner des munitions au joueur ou de le soigner en cas de besoin. Nous devions également nous assurer que l'escouade pouvait suivre un joueur empruntant régulièrement des itinéraires imprévisibles. Ainsi, lorsqu'ils se trouvent hors caméra, ses membres peuvent \"tricher\" de diverses manières : leur santé se régénère entre les combats, ils se déplacent rapidement pour rattraper le joueur et ils peuvent même se téléporter, le cas échéant."
N/A4168"#commentary\cn_256_citizen_squads.mp3" "[ Ken Birdwell ] Nos premiers tests d'affrontements de rue opposant des citoyens aux soldats du Cartel ont révélé un problème : sans limites imposées, les PNJ pouvaient s'éloigner considérablement du joueur. Si des soldats se repliaient pour recharger ou se mettre à couvert, les citoyens pouvaient les poursuivre. Il nous fallait un moyen d'aligner les actions des citoyens sur les objectifs du joueur, afin qu'ils soient conscients de ses déplacements et des ennemis contre lesquels il souhaitait se battre. Cela nous a conduits à créer une escouade (appelée \"unité\" dans le jeu) accompagnant le joueur. Les citoyens de l'escouade se déplaçaient avec le joueur et attaquaient les mêmes ennemis que lui. Au départ, nous avions conçu un système de commandes plus complexe, mais il est vite devenu trop lourd à utiliser, alors nous l'avons simplifié pour obtenir l'interface présente dans le jeu."
N/A4169"#commentary\cn_257_ai_behaviors.mp3" "[ Mike Dussault ] L'une des technologies d'I.A. que nous avons développées pour Half-Life 2 est le système de comportement, des bouts de code de gameplay liés à l'I.A. servant à guider les PNJ dans des situations spécifiques. Par exemple, nous avions un comportement \"Guider\" permettant à un PNJ de guider le joueur, et un comportement \"Suivre\" permettant à un PNJ de suivre le joueur ou un autre personnage. Ces comportements fonctionnaient en parallèle des actions de base des PNJ. Ainsi, un infirmier dans l'escouade utilisant le comportement \"Suivre\" pour rester aux côtés du joueur pouvait toujours tirer sur les ennemis, esquiver les grenades ou proposer une trousse de secours."
N/A4170"#commentary\cn_258_occlusion.mp3" "[ Brian Jacobson ] Dans Half-Life 1 et une grande partie de Half-Life 2, le monde était majoritairement constitué de tunnels et de couloirs, qui fonctionnaient bien avec une partition binaire de l'espace, ou un arbre BSP. Pour faire court, cette technologie nous permettait de faire rapidement le tri dans la géométrie afin de déterminer ce qui pouvait apparaître dans le champ de vision du joueur. Seulement, cette approche ne convenant pas aux zones ouvertes de la Côte et des autres sections extérieures, nous avons eu besoin de nouvelles technologies. Les \"Area Portals\" (portails de zone), par exemple, nous ont permis de tailler notre monde en sections distinctes, séparées par des portails (des portes et des fenêtres, pas ceux d'Aperture Science). Nous avons aussi développé un système d'occlusion supplémentaire fonctionnant essentiellement sur le principe suivant : \"Si le joueur ne peut pas voir les éléments situés derrière un gros objet en regardant à travers, par-dessus ou autour, il est inutile d'en effectuer le rendu\". Cette solution peut sembler évidente, mais elle a nécessité beaucoup de travail, car nous devions veiller à ce que le calcul de ce qui se trouve derrière le gros objet soit plus rapide que d'effectuer le rendu intégral. Afin d'accélérer ces calculs, les level designers ont donc placé de grands volumes d'occlusion dans les principaux reliefs du terrain et les gros objets masquants, comme les bâtiments. Nous pouvions ensuite tester les limites des entités par rapport à ces volumes pour éviter de calculer le rendu des éléments que le joueur ne pouvait pas voir."
N/A4171"#commentary\cn_259_detail_objects.mp3" "[ Brian Jacobson ] Une fois nos sections extérieures opérationnelles, il était évident qu'elles manquaient cruellement de détail. Nous avons donc ajouté de petits éléments de végétation, comme de l'herbe et des arbustes, sur le terrain généré. Nous savions cependant que nous ne pouvions pas nous permettre (autrement dit, nous n'avions pas le temps) de les placer manuellement un par un. Nous avons donc conçu un système générant automatiquement ces petits éléments en fonction du terrain. Chaque terrain définit le type de végétation à placer ainsi qu'un ensemble de paramètres associés. Lors de la compilation des cartes, le système calcule des points aléatoires à la surface et sélectionne les éléments à placer. Étant données les contraintes de performances, il a tout de même fallu passer par un processus relativement complexe de création manuelle des atlas de texture de la végétation afin d'en effectuer le rendu en une seule passe."
N/A4172"#commentary\cn_260_displacements_1.mp3" "[ Charlie Brown ] Après la sortie de Half-Life 1, nos level designers et nos graphistes ont demandé une solution plus efficace pour les environnements extérieurs, ce qui nous a poussés à concevoir la première version de notre système de terrain, basé sur des quads subdivisés. Imaginez un plan carré divisé en un maillage dont chaque point peut être déplacé sur son axe vertical. Les designers pouvaient placer plusieurs carrés et utiliser un pinceau pour façonner des collines et vallées en ajustant la hauteur des points du maillage. Pour le rendu, nous utilisions une texture spéciale constituée d'un mélange de deux textures différentes. La quantité de texture à utiliser était indiquée pour chaque point du maillage afin d'assurer des transitions fluides entre différentes surfaces comme le sable, l'herbe, la terre et le gravier. Ce genre de système de terrain n'était pas courant dans les moteurs de jeu de l'époque, et nous pensions naïvement que cela suffirait à nos game designers."
N/A4173"#commentary\cn_261_displacements_2.mp3" "[ Charlie Brown ] Une fois le système de terrain initial conçu, nous nous attendions à ce que les level designers l'utilisent pour travailler sur les espaces extérieurs, mais ils ont commencé à faire des expériences en ajoutant des détails à des endroits inattendus. Ils se sont servis des quads subdivisés pour créer des rebords endommagés au sommet des murs, arrondir des trottoirs et même tenter de construire des tuyaux. Leurs efforts n'ont rencontré qu'un succès mitigé, le système ayant été conçu pour façonner des paysages, et non des détails architecturaux. Nous avons donc retravaillé le code et transformé ce système de terrain basé sur la hauteur en un système de déplacement 3D complet. Ainsi, les designers pouvaient désormais déplacer les points du maillage dans toutes les directions, et non plus uniquement sur l'axe vertical. Ils ont alors pu détailler tous types de surfaces en utilisant des mélanges de textures pour fluidifier les transitions entre les quads de déplacement et la géométrie BSP. Cela nécessitait toutefois un travail technique supplémentaire pour assurer un éclairage cohérent entre les deux systèmes de rendu, sans quoi la transition aurait été visible. Une fois cette mission accomplie, les level designers semblaient satisfaits et, toujours aussi naïfs, nous pensions que cela suffirait."
N/A4174"#commentary\cn_262_displacements_3.mp3" "[ Charlie Brown ] Disposant désormais d'un système de déplacement général, les level designers ne se sont pas contentés d'ajouter des détails au monde, mais ont repris leurs objectifs initiaux, à savoir bâtir des sections extérieures à grande échelle. Cela a entraîné une nouvelle série de mises à jour visant à équilibrer les performances, pour vérifier que le système était capable d'assumer à la fois les petits détails et le terrain plus vaste. Il a aussi fallu améliorer les textures, notamment pour les structures complexes comme les falaises surplombantes, que le système original, basé sur la hauteur, ne permettait pas. Les designers, qui ne sont pas du genre à se reposer sur leurs lauriers, ont également utilisé les déplacements pour créer des grottes et des tunnels. Tous ces ajouts avaient beau être réussis, ils nécessitaient encore davantage d'ajustements techniques. Au final, nous avons réussi à concilier les exigences contradictoires relatives à toutes les façons dont ces déplacements étaient utilisés, et à les intégrer à de grandes parties du monde de notre jeu. Rétrospectivement, les déplacements sont un exemple flagrant de comment la technologie et le game design évoluent de concert. C'est le paradoxe de l'œuf et de la poule : nous ne pouvons pas prévoir tous les impacts qu'une technologie aura sur le jeu, mais nous ne pouvons pas non plus concevoir cette technologie sans savoir à quels besoins elle devra répondre. Alors, comme toujours, puisqu'il faut bien commencer quelque part, nous formulons une hypothèse solide et nous voyons où elle nous mène."
N/A4175"#commentary\cn_263_particles.mp3" "[ Chris Green ] Pour le moteur Source, nous avons investi dans le développement de notre technologie de particules et d'effets spéciaux. Cela nous a permis d'obtenir des mouvements de particules plus réalistes et élaborés, ainsi que des effets de formes et de shaders plus complexes. L'ajout d'un bumpmapping à nos effets de particules a notamment eu un impact énorme sur leur apparence volumétrique. Si un puissant éditeur de système de particules a été ajouté aux itérations ultérieures du moteur Source, la version originale, utilisée pour Half-Life 2, reposait sur une méthode de travail beaucoup plus exigeante et chronophage : chaque effet était méticuleusement codé à la main par un programmeur."
N/A4176"#commentary\cn_264_cubemaps.mp3" "[ Chris Green ] En plus des matériaux et des shaders, nous avions besoin d'une solution pour les surfaces réfléchissantes comme le verre et l'acier. Il fallait que ces surfaces \"sachent\" ce qu'elles devaient refléter, mais en 2003, effectuer ce rendu en temps réel était impossible. Nous avons donc développé un système de cartes d'environnement cubique (ou cubemaps) pour gérer les reflets précalculés. Un cubemap est constitué de six images placées à l'intérieur d'un cube et capturant l'environnement dans toutes les directions, comme une photo panoramique qui vous envelopperait de tous les côtés. Nos level designers ont placé des marqueurs invisibles à travers les différents niveaux et, durant la compilation des cartes, nous avons généré un cubemap à l'emplacement de chaque marqueur. Ainsi, pour rendre une surface réfléchissante en jeu, nous localisons le cubemap précalculé le plus proche afin de créer le reflet voulu."
N/A4177"#commentary\cn_265_water_shader.mp3" "[ Gary McTaggart ] De tous les shaders créés pour ce jeu, celui utilisé pour l'eau était le plus complexe, car il exploitait pleinement toutes les capacités des dernières cartes graphiques programmables. Nous devions effectuer trois fois le rendu de chaque scène contenant de l'eau : une première pour la réfraction du monde sous-marin, une autre pour la vue reflétée à la surface, et une dernière pour tout ce qui se trouvait au-dessus de l'eau. Lors du rendu de l'eau, nous fusionnions les vues réfractées et reflétées, en utilisant les coefficients de Fresnel pour afficher davantage de reflets aux angles d'incidence. Nous relevions également la profondeur sous la surface de l'eau pour la rendre plus transparente et moins réfléchissante dans les zones peu profondes. De plus, nous avons dû créer deux techniques de rendu de l'eau supplémentaires : les cartes graphiques de milieu de gamme affichaient des reflets peu détaillés, sans réfraction ni transparence, tandis que les cartes graphiques bas de gamme ne pouvaient afficher qu'une surface partiellement transparente."
N/A4178"#commentary\cn_266_normal_maps.mp3" "[ Gary McTaggart ] Nous avons développé Half-Life 2 pendant une ère passionnante en matière de graphismes, car les premières cartes graphiques programmables compatibles avec les shaders arrivaient tout juste sur le marché. Grâce à cette technologie, notre jeu a été parmi les premiers à utiliser des cartes de normales, une technique améliorant l'éclairage des surfaces géométriques. Les cartes de normales traduisaient correctement la rugosité des surfaces, permettant d'éclairer chaque pixel d'un polygone de telle manière qu'elles apparaissaient plus inégales et plus détaillées que tout ce que nous avions pu afficher pour Half-Life 1."
N/A4179"#commentary\cn_267_rendering_systems.mp3" "[ Gary McTaggart ] Au début des années 2000, nous n'avions pas les moyens d'utiliser un moteur de rendu polyvalent disposant des vastes capacités d'un moteur moderne. Les contraintes de CPU, de GPU et de mémoire nécessitaient d'apporter des solutions hautement spécifiques aux défis de rendu afin d'exploiter au maximum les performances du matériel des joueurs. Au final, Half-Life 2 utilise trois moteurs de rendu différents : un pour la géométrie du monde, un autre pour les environnements extérieurs et un dernier pour les entités dynamiques, telles que les personnages et les objets. Ces trois moteurs devaient gérer une matrice de fonctionnalités complexe : collisions, projectiles, projections de textures, éclairage hors ligne, calculs de visibilité et bien plus encore. Et pour couronner le tout, ils devaient tous trois être compatibles avec DirectX 7, 8 et 9, des versions très différentes, nécessitant souvent des stockages de données et stratégies de rendu distinctes. Elles utilisaient même des langages de programmation différents ! Au total, nous avions pour ainsi dire neuf moteurs de rendu nécessitant chacun des solutions uniques, et assurer un résultat cohérent est l'un des défis techniques les plus complexes que nous ayons eu à relever au cours du développement."
N/A4180"#commentary\cn_268_dynamic_shadows.mp3" "[ Gary McTaggart ] Vu l'importance que nous voulions donner aux personnages et objets physiques, nous estimions avoir besoin d'un système d'ombre dynamique pour créer un rendu qui leur fasse honneur. En 2003, les GPU ne disposant pas encore des fonctionnalités spécifiques pour le rendu des ombres qu'ils ont aujourd'hui, les performances représentaient un problème épineux. Nous avons fini par trouver une solution, exécutée à chaque image. Pour commencer, nous devions répertorier tous les objets pouvant avoir une ombre visible. Cela impliquait de déterminer quels objets étaient présents dans le champ de vision, ou légèrement en dehors, afin de repérer les entités situées hors de l'écran, mais dont les ombres pouvaient tout de même être visibles. Ensuite, nous générions un rendu en ombre noire pour chacun de ces objets et les regroupions en une seule texture d'ombre. Dans un souci de rapidité, nous utilisions le modèle le moins détaillé de l'objet pour générer ce rendu. Enfin, nous utilisions la texture d'ombre pour étirer chacune des ombres dans le champ de vision du joueur en assombrissant les pixels déjà rendus. Nous les découpions soigneusement une par une pour veiller à ce qu'elles se recouvrent correctement dans l'éventualité où plusieurs ombres se superposeraient. C'est amusant de se replonger dans les méthodes que nous utilisions à l'époque, mais nous sommes beaucoup plus heureux aujourd'hui, grâce aux composants graphiques modernes qui ont largement simplifié la gestion de ce problème."
N/A4181"#commentary\cn_269_combinatorial_shader_explosion.mp3" "[ Gary McTaggart ] Au cours du développement de Half-Life 2, les techniques de rendu se sont complexifiées avec l'ajout des shaders matériels, qui sont des petits morceaux de code contrôlant la manière dont chaque pixel d'une surface doit être rendu. En 2003, la technologie des shaders était bien plus limitée qu'aujourd'hui : il n'y avait pas de conditionnelles et la taille du code était très restreinte. Nous ne pouvions donc pas utiliser de logiques de branchement if/else ajustables en fonction de certaines conditions, ni de shaders volumineux disposant d'un ensemble de fonctionnalités. De plus, la compilation des shaders nécessaires prenait tellement de temps que nous devions les précompiler. Pour travailler avec ces limitations, nous devions calculer chaque combinaison de shaders possible et l'enregistrer individuellement en tant que shader à part entière. Par exemple, si l'un de nos shaders affectait une surface à partir d'une source de lumière unique, nous avions besoin d'une autre version du shader pour deux sources de lumière, d'une autre pour trois, etc. Et tout cela était combinatoire, car si ce shader utilisait également une carte de normales, il nous fallait deux versions par lumière : une avec carte de normales et une sans. Ajoutez à cela des fonctionnalités comme la fusion de textures, la colorisation des vertex, la lumière spéculaire, le test alpha, ainsi que divers types d'éclairage (directionnel, point de lumière, projecteurs), et notre nombre de shaders a explosé. À la sortie de Half-Life 2, nous avions des milliers de shaders individuels. Peu après, quand nous avons sorti Lost Coast en ajoutant la prise en charge de la technologie HDR, ce nombre a encore doublé. Quand la compilation des shaders sur les machines locales des développeurs a fini par prendre trop de temps, nous avons commencé à la distribuer sur l'ensemble du réseau avec VMPi. Nous avions également un mode de compilation dynamique des shaders, utile pour en développer, qui offrait des résultats rapides au prix d'un débit d'images saccadé lorsqu'un shader devait être compilé."
N/A4182"#commentary\cn_270_gpu_wild_west.mp3" "[ Jay Stelly ] Au cours du développement, nous avons dû prendre de nombreuses décisions influencées par notre choix de configuration minimale, c'est-à-dire l'association CPU/GPU la moins puissante capable de garantir une bonne expérience de jeu. Au début des années 2000, il existait une diversité de GPU bien plus vaste qu'aujourd'hui, dont les différences ne se limitaient pas uniquement à la vitesse, mais aux méthodes fondamentales de rendu. Seulement, à l'époque, nous n'avions pas de réelles données sur le matériel de nos utilisateurs. Quels CPU et GPU possédaient-ils ? De combien de RAM disposaient-ils ? Quelle version de Windows utilisaient-ils ? Nous avons contacté Microsoft dans l'espoir qu'ils puissent nous renseigner, par exemple, sur le nombre de cartes DX7 ou DX8 utilisées. Malheureusement, ils n'avaient pas non plus ces éléments. Comprenant que nous risquions de prendre de mauvaises décisions sans ces informations, nous avons développé un outil d'analyse permettant aux joueurs de nous transmettre leur configuration matérielle et l'avons intégré à la première version de Steam. Ces données étaient tellement utiles que nous avons décidé de les rendre publiques en lançant notre Enquête sur le matériel en avril 2003. Depuis, cela nous a aidés (ainsi que d'autres développeurs, je l'espère) à prendre des décisions informées."
N/A4183"#commentary\cn_271_3d_skybox.mp3" "[ Jay Stelly ] Nous avons toujours eu besoin d'un rendu donnant l'illusion d'un monde plus vaste que les limitations de notre carte ne le permettaient. Dans Half-Life 1, nous avions utilisé une texture cubique pour permettre aux joueurs de voir au-delà de la zone de jeu. Pour Half-Life 2, cependant, nous ne voulions pas nous contenter d'une texture statique, mais proposer une vue dynamique du monde extérieur. La taille de notre carte était limitée à environ 800 mètres dans chaque dimension, mais nous avons découvert que nous pouvions créer un monde extérieur beaucoup plus vaste si nous le stockions à échelle réduite. Nous avons donc inventé une technologie que nous avons appelée la Skybox 3D. Il s'agit d'une petite boîte dissimulée au sein de la vraie carte du jeu, contenant une représentation géométrique à échelle 1/16. À l'intérieur se trouve un point de référence associé à une origine placée sur la carte principale. Lorsque nous effectuons le rendu de l'espace situé au-delà de la zone de jeu, nous utilisons la géométrie de la skybox, positionnée en fonction de ce point de référence et dont l'échelle est multipliée par 16. Assurer la transition fluide de l'éclairage et du brouillard entre la carte principale et la skybox n'a pas été facile, mais nous avons fini par y parvenir. Résultat, le monde extérieur paraît beaucoup plus vaste et immersif qu'il ne l'était dans Half-Life 1."
N/A4184"#commentary\cn_272_missing_material.mp3" "[ Jay Stelly ] Lors du développement de notre code graphique, nous avons rapidement réalisé qu'il serait difficile de repérer les polygones non rendus en raison d'une texture manquante. Lorsque c'était le cas, on ne voyait que du noir là où le polygone aurait dû se trouver. Dans les scènes les plus sombres, cela passait facilement inaperçu. Afin de déceler plus efficacement ce bug, nous avons créé une texture d'erreur, facilement reconnaissable et générée automatiquement à chaque fois qu'une texture ne se chargeait pas correctement. C'est ainsi qu'est née la désormais célèbre texture en damier noir et violet, dont l'existence a depuis largement dépassé le cadre de Half-Life 2."
N/A4185"#commentary\cn_273_air_resistance.mp3" "[ Jay Stelly ] Pour Half-Life 2, nous avons dû ajouter une fonctionnalité majeure à notre moteur physique : la résistance de l'air. À l'époque, les moteurs physiques exécutaient habituellement une fonction d'amortissement général pour ralentir les objets en mouvement, mais cela ne faisait que dissiper l'énergie de manière symétrique. Afin de créer des mouvements plus vraisemblables, nous avons fait le choix de simuler la résistance de l'air. Cela nous a permis d'obtenir un comportement asymétrique, c'est-à-dire que l'intensité du ralentissement d'un objet se mouvant dans l'air dépendait de la surface orientée dans la direction du déplacement ou de la rotation. Cette fonction était indispensable au réalisme des explosions et des objets projetés par le pistolet anti-gravité. Les objets se déplaçant ou tournoyant rapidement font partie des éléments les plus coûteux à simuler pour le moteur physique du jeu, si bien que la résistance de l'air améliore également l'efficacité du processeur lors des explosions. Elle favorise aussi la représentation des différents matériaux et de la masse des objets : plus ceux-ci sont denses, plus ils repoussent l'air facilement, et cela se voit. Avec cet effet, par exemple, la différence de densité entre les cartons et les planches en bois est évidente, et c'est ce qui nous a permis de rendre les objets du monde de Half-Life 2 beaucoup plus convaincants."
N/A4186"#commentary\cn_274_early_tech_planning.mp3" "[ Ken Birdwell ] La sortie d'un jeu est toujours source de nombreux apprentissages, car on découvre enfin quels choix ont été les bons, et ceux qu'il ne faudra pas reproduire la fois suivante. Ainsi, après le premier Half-Life, quand nous avons pris le temps de réfléchir à la suite que nous allions pouvoir créer, nous avons examiné tout un tas de retours que nous avaient faits les joueurs. À partir de ces commentaires, nous avons essayé de dresser une liste de points sur lesquels se focaliserait Half-Life 2. Nous n'avons pas cherché à concevoir une expérience spécifique pour le joueur, nous avons préféré aborder la question d'un point de vue technologique. Les agents de sécurité et les scientifiques de Black Mesa avaient bien fonctionné ; jusqu'où pourrions-nous aller en insistant à fond sur les personnages ? Nous étions satisfaits de notre narration interactive ; qu'allions-nous pouvoir inventer pour en inclure davantage et de manière plus diversifiée ? Les joueurs avaient été convaincus par l'exploration et les interactions au sein de Black Mesa ; peut-être qu'un moteur physique nous permettrait de pousser cet aspect encore plus loin ? Nous avons tenté d'imaginer à quoi pourrait ressembler la meilleure version de chacun de ces domaines à l'avenir et nous sommes partis de ces idées pour développer un ensemble de technologies qui pourraient nous permettre d'y arriver."
N/A4187"#commentary\cn_275_character_lighting.mp3" "[ Ken Birdwell ] Pendant la première année du développement, nous n'arrivions pas à rendre nos personnages aussi réalistes que nous le voulions. C'était lié à un certain nombre de problèmes différents dont la résolution a systématiquement nécessité des évolutions artistiques et technologiques spécifiques. Le premier problème majeur était l'éclairage. Au début des années 2000, les technologies d'éclairage dans les jeux vidéo souffraient de nombreuses lacunes, parfois pour des questions de performances, mais souvent en raison d'une mauvaise compréhension de leur fonctionnement. À l'époque, pour obtenir des personnages visuellement réussis, il fallait créer les modèles et textures en y intégrant directement des solutions d'éclairage, comme les ombres ou la brillance. Les personnages avaient l'air cool, mais ils avaient aussi l'air de personnages de jeu vidéo. Au départ, nous avons adopté cette approche pour concevoir Alyx, car c'était ce que tout le monde faisait. Nous avons utilisé les solutions intégrées et éclairé Alyx à la manière d'une star de cinéma, comme si un système d'éclairage la suivait partout en veillant à ce qu'elle paraisse toujours réaliste. Mais ça ne marchait pas vraiment. Entre la diversité des environnements lumineux et la nature dynamique des jeux vidéo, elle était crédible dans certains environnements, mais elle finissait toujours par paraître terriblement non réaliste. Nous avons bien essayé de modifier son système d'éclairage pour en améliorer les capacités, mais nous étions dans une impasse. De retour à la case départ, nous avons décidé de tenter une nouvelle approche. Nous avons tout jeté pour recréer Alyx, l'éclairage et les textures en repartant de zéro, en nous concentrant non pas sur l'apparence que nous voulions lui donner sous un éclairage idéal, mais sur la manière dont ces systèmes fonctionnent dans le monde réel. Ça peut paraître évident, mais ce n'était pas la méthode habituelle, du moins dans les jeux vidéo. Observés hors du moteur de rendu du jeu, ces nouveaux modèles et textures paraissaient moins réussis que leurs versions précédentes. Pourtant, nous sommes parvenus à combler méthodiquement toutes nos lacunes et idées fausses sur le fonctionnement de la lumière, des textures et des cartes graphiques pour parvenir à résoudre nos problèmes. Après toutes ces étapes, quand nous avons enfin pu observer Alyx dans le jeu, avec ses nouveaux modèles et textures, et dans un environnement lui offrant une cohérence visuelle à chaque instant, elle était parfaite. Pleinement intégrée au monde de Half-Life 2."
N/A4188"#commentary\cn_276_gamma_correction.mp3" "[ John Morello ] Notre moteur de jeu dispose d'un système de rendu qui prend en compte l'état du jeu dans son intégralité et calcule une valeur de couleur pour chaque pixel visible à l'écran afin de représenter cet état. Cependant, du code et des logiciels externes sont également impliqués dans le processus de calcul de ces pixels. Le logiciel et le matériel de votre GPU et de votre écran, par exemple. À un certain stade du développement, nous n'étions pas satisfaits de l'apparence de nos personnages. Nous trouvions qu'ils avaient le teint cireux, maladif, que quelque chose n'allait pas avec leur peau. Nous avons passé du temps à ajuster notre éclairage, mais nous n'arrivions pas à obtenir le résultat recherché : quand les personnages rendaient bien, le monde nous déplaisait, et inversement. Par chance, nous avions également un moteur de rendu logiciel complet qui nous permettait de lancer le jeu sans GPU, car à cette époque, beaucoup de joueurs n'en avaient toujours pas. En étudiant le jeu sur ce moteur de rendu, nous avons remarqué que le problème d'éclairage disparaissait. Après avoir passé notre code au peigne fin pour essayer d'y trouver la cause de ce problème, sans succès, nous avons contacté les fabricants de GPU pour leur demander de vérifier s'ils ne commettaient pas une erreur avec les valeurs de pixels que nous leur transmettions. Cela a été le début d'une longue aventure... Il a fallu près de deux ans d'échanges avec ces fabricants avant que nous parvenions à les convaincre qu'ils effectuaient incorrectement la correction gamma dans les calculs mathématiques de bas niveau sur leurs cartes. Entre temps, nous avions même dû construire un système qui validait les valeurs de couleur d'un pixel individuel tout au long de notre pipeline de rendu. À terme, les fabricants nous ont enfin transmis de nouveaux pilotes, et l'apparence de nos personnages s'est immédiatement améliorée."
N/A4189"#commentary\cn_277_facial_technology.mp3" "[ Ken Birdwell ] Pour que les joueurs s'attachent à nos personnages, nous savions qu'il nous faudrait consacrer d'importants moyens technologiques à la création de leurs visages. Les humains accordent une grande attention aux visages et sont capables, inconsciemment, de déduire toutes sortes d'informations simplement en les regardant. La barre était donc placée très haut, et si nous ne pouvions pas l'atteindre, nous risquions au contraire de créer une distance entre les joueurs et nos personnages. Nous avons donc effectué de nombreuses recherches, et ce n'était pas franchement encourageant. Nous avons trouvé de nombreux exemples, mais nous n'avions pas la moindre chance de réussir à simuler les meilleurs d'entre eux en temps réel. Quant aux meilleurs de ceux qui pouvaient l'être, ils étaient loin d'atteindre la qualité que nous recherchions. Nous voulions obtenir un résultat digne d'un film d'animation, mais ceux-ci sont linéaires et réalisés par des équipes pouvant comprendre une centaine d'animateurs travaillant souvent plusieurs heures sur chaque image. Nous n'avions qu'une poignée d'artistes et il nous fallait des animations dynamiques, avec des personnages devant parfois parler tout en affichant une expression faciale résultant d'une action du joueur. Toutes ces conditions nous ont menés au système de codage d'action faciale (\"Facial Action Coding System\") du Dr Paul Ekman, un système de classification des mouvements du visage humain établi dans les années 1970. En partant de ce cadre, nous avons entamé un processus de plusieurs années visant à développer la manière dont nous concevions les visages et les têtes de nos personnages. Là où d'autres s'étaient inspirés d'une partie des travaux d'Ekman, nous voulions en utiliser la totalité. Nous avons donc passé un temps considérable à essayer de concevoir chaque élément en tenant compte des fortes contraintes de performances qui nous étaient imposées. Mais nous avons également passé beaucoup de temps à observer des gens et des visages pour déterminer les caractéristiques qui nous apporteraient un maximum de valeur ajoutée, comme l'élasticité de la peau ou l'ombrage des dents. Au bout du compte, même si nous n'avons pas pu accomplir tout ce que nous souhaitions, nous avons réussi à définir les éléments que nous estimions indispensables à l'obtention de performances faciales convaincantes pour nos personnages."
N/A4190"#commentary\cn_278_eye_shader.mp3" "[ Ken Birdwell ] Pour obtenir des visages convaincants, il nous fallait impérativement réussir les yeux. Les humains sont excellents pour lire les regards. Une partie de notre cerveau y est dédiée, au point que les reflets sur les globes oculaires nous permettent de savoir dans quelle direction regarde une personne. Cependant, il y a toutes sortes de subtilités à prendre en compte. Les yeux ne sont pas vraiment des sphères. Les mouvements de la cornée déforment les paupières. Les mouvements oculaires peuvent augmenter les chances de cligner des yeux. Les yeux ne sont pas alignés juste derrière la pupille, mais légèrement sur le côté. On pourrait penser que ces petits détails sont insignifiants et passeraient inaperçus, mais leur absence nuit à la crédibilité du personnage. Nous avons longtemps travaillé sur les yeux, peaufinant petit à petit notre modèle de globe oculaire et notre ensemble de fonctionnalités. Certaines choses nécessitaient des interfaces extérieures, par exemple pour déterminer les éléments de l'environnement susceptibles d'attirer le regard, quand d'autres étaient automatiques, traitées à un niveau inconscient de l'I.A., comme le fait de cligner des yeux. Une caractéristique évidente, mais qui devient subtilement déroutante à la moindre erreur. Les reflets dans les yeux avaient également un impact énorme, alors qu'ils n'occupent qu'une place minuscule à l'écran. Un jour, nous examinions un personnage dont le shader des yeux était désactivé, et il ressemblait à une poupée. Humanoïde, certes, mais peinant à convaincre pour des raisons indescriptibles. Quand nous l'avons activé, en revanche, nous avons subitement eu l'impression d'être face à un humain qui nous regardait. Ce jour-là, nous avons compris que nous avions atteint notre objectif."
N/A4191"#commentary\cn_279_combine_gunship.mp3" "[ Ken Birdwell ] Cet hélico soulevait un problème intéressant. Nous disposions déjà d'un modèle d'hélicoptère et n'avions pas vraiment le temps d'en construire un nouveau. Nous avons donc ajusté le modèle existant jusqu'à ce qu'il paraisse suffisamment différent, puis avons basé ses animations organiques sur les valeurs obtenues à partir de cette simulation. Nous avons également essayé de le rendre aussi fidèle à la réalité que possible. Par exemple, l'angle de rotation du canon est limité. Si l'hélico n'est pas face à sa cible, il doit modifier sa trajectoire de vol pour placer son canon dans l'axe. Il ne peut pas tricher. L'autre caractéristique principale était le son de son moteur. Grâce à la spatialisation sonore, le joueur peut approximativement deviner la position de l'engin, mais celui-ci, en plus d'être rapide et mobile, se déplace dans les airs, loin de tout autre point de référence. Résultat, il est parfois difficile d'estimer précisément la distance à laquelle il se trouve et sa vitesse de déplacement. Pour y remédier, nous avons ajouté un effet Doppler au son du moteur pour en modifier l'intensité d'après la vélocité relative de l'hélico par rapport au joueur. Il s'agit d'un effet subtil, mais extrêmement efficace, qui vous aide inconsciemment à percevoir l'emplacement et l'orientation de l'appareil. Deux informations cruciales quand l'hélico est en train de vous traquer."
N/A4192"#commentary\cn_280_risk.mp3" "[ Ken Birdwell ] C'est assez impressionnant de se rappeler, 20 ans plus tard, à quel point le développement de Half-Life 2 a pu être terrifiant. Développer un jeu vidéo est difficile. On aimerait pouvoir valider les risques avant d'en rajouter une couche, mais ce n'est jamais vraiment possible. Prenons notre technologie d'animation faciale, par exemple. Nous avons travaillé dessus entre trois et quatre ans avant d'être certains qu'elle allait fonctionner, mais le reste ne pouvait pas attendre que nous ayons terminé. Dès la première année, nous avons commencé à faire toutes sortes de choix relatifs au game design, à la production d'assets et à nos autres technologies, en partant du principe que notre animation faciale finirait par fonctionner aussi bien du point de vue de la qualité que des performances. Si nous n'y étions pas arrivés, un grand nombre de ces choix n'auraient pas fonctionné non plus. Et ce type de risque s'applique également à d'autres décisions majeures que nous avons prises dès le départ. On ne peut pas attendre. On peut simplement créer en espérant, d'ici quelques années, voire nos hypothèses confirmées. C'est terrifiant."
N/A4193"#commentary\cn_281_hugs_and_pickups.mp3" "[ Ken Birdwell ] Le développement de fonctionnalités en apparence mineures peut parfois devenir un cauchemar. Faire en sorte que deux personnages s'enlacent ou, plus simple encore, que l'un d'eux prenne un objet sur une table, peut entraîner de nombreux problèmes. C'est pire dans notre environnement dynamique, où le joueur et les objets ne se trouvent pas dans une position prédéfinie, et où les déplacements du joueur peuvent créer un obstacle. Atteindre le niveau de synchronisation requis par ces petites actions est extrêmement délicat, notamment parce que les humains les accomplissent sans réfléchir. Quand vous vous approchez d'une table pour y prendre une tasse, vous effectuez toutes sortes de préparatifs avec votre corps. Ainsi, le moment venu, vos pieds et vos mains se trouvent dans la position idéale pour accomplir le geste confortablement. Quand vous voulez enlacer quelqu'un, la personne concernée se déplace également vers vous, et chacun ajuste constamment ses mouvements en fonction de l'autre. Coordonner ce genre d'interaction dans le jeu nécessite d'importants efforts de synchronisation pour que chaque personnage soit conscient de l'autre et de son environnement. Et dans le même temps, ils doivent être conscients de leurs plans futurs. On pourrait être tenté de décomposer un geste en étapes distinctes, par exemple : marcher jusqu'à la table, s'orienter face à la tasse, prendre la tasse. En effet, procéder ainsi est bien plus simple et permet de créer des étapes réutilisables. Mais seuls les robots fonctionnent ainsi, pas les humains. Nos personnages avaient besoin d'être conscients de leur intention de se déplacer vers la table pour prendre une tasse, car ils devaient pouvoir accomplir simultanément plusieurs étapes de préparation afin d'arriver devant la tasse en ayant la main dans la bonne position pour s'en saisir. Une interaction avec deux personnages implique encore plus de négociation. Les deux doivent s'accorder sur la position et le moment de cette interaction, et tout doit se mettre en place de manière fluide. Ces interactions simples entre nos personnages dans leur environnement, bien que souvent de courte durée, sont cruciales pour en faire des individus crédibles."
N/A4194"#commentary\cn_282_ropes.mp3" "[ Mike Dussault ] L'un des éléments que nous avions remarqués, dans toutes les images de références que nous avions rassemblées pour Cité 17, était l'omniprésence de fils et de câbles qui contribuaient largement à la grande quantité de détails visibles. Nous aimions particulièrement l'apparence de ces vieilles villes européennes empêtrées dans la toile désordonnée de la modernité. Nous devions trouver une solution pour intégrer des câbles, cordes et éléments similaires, et nous les voulions dynamiques. Nos concepteurs de niveaux souhaitaient créer des mécaniques à base de câbles et de prises pour aider les joueurs à mieux appréhender ces éléments. Très tôt dans la production, nous avons conçu un système de câbles dont nous nous sommes servis tout au long du développement. En réalité, chaque câble est constitué de plusieurs segments étirés entre deux extrémités et pouvant bouger indépendamment les uns des autres. Chaque segment agit comme un ressort et réagit aux différentes forces du jeu, comme un léger coup de vent ou le survol d'un hélicoptère du Cartel. Une fois rendu, chaque segment est présenté face à la caméra et fait l'objet d'un placage en relief, ce qui est crucial pour donner aux câbles une apparence arrondie et réaliste."
N/A4195"#commentary\cn_283_vmpi.mp3" "[ Mike Dussault ] Au cours du développement, nous étions de plus en plus frustrés par la lenteur de notre itération de gameplay, notamment parce que la compilation des cartes, indispensable au précalcul de l'éclairage et de la visibilité, prenait des heures. Au début des années 2000, les ordinateurs étaient bien plus lents qu'aujourd'hui et ne possédaient qu'un seul cœur de processeur. Nous nous sommes inspirés de SETI@Home, un programme utilisant des PC du monde entier pour analyser des signaux radio en vue de détecter des signes de vie extraterrestre, pour créer VMPi, notre propre système distribué répartissant le processus de compilation des cartes entre plusieurs ordinateurs. De nos jours, ce type de système distribué fonctionne sur d'énormes clusters de calcul GPU, mais à l'époque, nous nous contentions de le faire tourner sur tous les ordinateurs de nos bureaux. Pour faire face à l'évolution de notre code d'éclairage, qui rivalisait de vitesse avec celle de nos cartes, VMPi distribuait également de nouveaux fichiers .exe sur tous les ordinateurs. Rétrospectivement, c'était un concept affreux en termes de sécurité. De quoi donner des sueurs froides à n'importe quel spécialiste informatique. Nous transférions simplement un fichier exécutable à tous nos PC de travail, qui les exécutaient. C'était de la folie pure. Mais ça a fonctionné, et en augmentant fortement notre vitesse d'itération des cartes, c'est devenu un outil majeur."
N/A4196"#commentary\cn_284_field_of_view.mp3" "[ Kerry Davies ] Dans Half-Life 1, nous utilisions un champ de vision (ou FOV) de 90 degrés, ce qui, à l'époque, était plutôt standard pour un jeu de tir à la première personne. Mais lors du développement de Half-Life 2, nous n'en étions plus satisfaits. Notre jeu accordant une grande importance à ses personnages, nous avions créé des animations de corps et de visages détaillées, qu'un FOV de 90 degrés ne permettait pas aux joueurs d'apprécier pleinement parce qu'ils ne pouvaient pas s'en approcher suffisamment. Nous avons donc commencé à expérimenter avec des FOV plus restreints, et avons fini par opter pour 75 degrés. Cela a nécessité quelques ajustements, à la fois pour nous et pour les joueurs, ainsi qu'un FOV supplémentaire pour les armes du joueur, visibles au bas de l'écran. Ces modèles, initialement conçus pour un FOV de 90 degrés, apparaissaient déformés à 75. Ce changement nous a toutefois permis de faire ce que nous souhaitions : mettre nos personnages au centre du jeu."
N/A4197"#commentary\cn_285_reference_maps.mp3" "[ Randy Lundeen ] Nos personnages étant devenus plus réalistes entre Half-Life 1 et Half-Life 2, nous souhaitions la même évolution pour notre univers. À l'époque de Half-Life 1, les limites inhérentes aux jeux à la première personne étaient telles qu'on pouvait plus facilement se reposer sur des environnements stylisés ou abstraits. Pour Half-Life 2, en revanche, nous voulions créer un cadre qui paraîtrait ancré dans la réalité, ce qui implique de préciser de nombreux petits détails qui n'existaient pas auparavant. La création de cartes de référence, qui nous ont permis d'harmoniser la manière dont nous allions retranscrire en jeu les proportions du monde réel, a été une étape importante. Ces cartes nous ont servi à définir des détails comme les dimensions des murs et des portes, la hauteur des poignées, les éclairages intérieurs, l'échelle du mobilier et l'échelle générale des objets classiques. Nous avons créé des textures standardisées pour les level designers, avec des valeurs d'échelle et d'éclairage, pour que leurs plans soient cohérents dès le départ. En plus de préparer le monde physique, ces cartes de référence définissaient également la manière dont le joueur allait se déplacer : sa hauteur maximale de saut, dans quelle mesure il pourrait s'accroupir, la taille d'espaces comme les conduits d'aération... En utilisant ces cartes comme bases, nous avons pu conférer une cohérence géométrique à notre univers et garantir des espaces de taille réaliste tout au long du jeu."
N/A4198"#commentary\cn_286_response_rules.mp3" "[ Scott Dalton ] Comme nous avions décidé très tôt que le jeu devait comporter de nombreux dialogues dynamiques, il nous fallait un système pour les gérer efficacement. Nous voulions que ce système permette aux sound designers d'ajouter et de modifier des lignes sans intervention des programmeurs, propose des dialogues correspondants à l'état du jeu, et limite au maximum les répétitions. Conformément à ces exigences, nous avons créé le \"Response Rules System\". Quand un personnage parle en dehors d'une scène scriptée, ce système détermine la ligne prononcée. L'I.A. des personnages, plutôt que de choisir des lignes directement, signale des \"occasions de s'exprimer\" chaque fois qu'un événement important survient : s'il aperçoit le joueur, s'il est blessé, s'il tire la dernière munition de son chargeur, s'il fait face à des ennemis trop puissants, etc. Pour chacune de ces occasions, un paquet de données sur l'état actuel du jeu est transmis au \"Response Rules System\", qui renvoie la ligne de dialogue la plus appropriée, le cas échéant. Cette configuration a permis à nos sound designers de créer une matrice décisionnelle détaillée consacrée aux dialogues. Par exemple, un même personnage annonçant qu'il recharge son arme pourra piocher parmi différents ensembles de lignes selon qu'il se trouve sous le feu ennemi ou que le combat est terminé, qu'il ne reste qu'un seul allié debout ou qu'un Strider approche. Quand Half-Life 2 est sorti, nous avions tout juste effleuré la surface du potentiel de ce système. Il est devenu un élément central pour Alyx dans l'Épisode 1, puis a servi à traiter les dialogues dynamiques dans nos jeux suivants, y compris les différentes classes de TF2 et les personnages de Left 4 Dead."
N/A4199"#commentary\cn_287_audio_caching.mp3" "[ Yahn Bernier ] Nous avons fait face à un autre problème concernant la quantité de données audio dans le jeu. Nous avions trop de sons de gameplay, de musiques et de dialogues pour tout stocker en mémoire (en 2003, il s'agissait d'une denrée rare). Mais comme vous pouvez l'imaginer, nous avions besoin de pouvoir jouer des sons instantanément, surtout s'ils étaient liés au gameplay. Nous avons donc créé un cache audio, qui ne stockait que les premières 125 ms de chaque fichier audio, et l'avons gardé en mémoire. Ces 125 ms correspondaient à notre estimation de la durée nécessaire pour jouer un fichier audio à partir du disque. Ensuite, chaque fois qu'un son était joué dans le jeu, nous en lancions le début à partir du cache audio et amorcions simultanément le chargement du fichier complet à partir du disque. Le temps que le son du cache se termine, le reste du fichier était chargé et nous pouvions jouer le reste de l'audio. Ce cache présentait également quelques petites fonctionnalités supplémentaires, comme la possibilité de garder les sons récents en mémoire dans leur intégralité afin que les plus fréquents n'aient pas à être rechargés en permanence. Désormais, les moteurs de jeu utilisent une stratégie similaire non seulement pour les sons, mais pour tous les types d'assets."
N/A4200
39184201}
39194202}