Template:PatchDiff/March 6, 2026 Patch/hl2/resource/closecaption german.txt
39143914"wood.scraperough" " "
39153915"plastic_box.scraperough" " "
39163916
3917N/A"#commentary\cn_002_ramming_with_the_buggy.mp3" "[ Jay Stelly ] Unser Physiksystem basiert auf starren Körpern, d. h., es unterstützt weder Verformung noch Zerstörung von Objekten. Wenn ein physikalisches Objekt getroffen wird, kann es sich, falls erlaubt, bewegen. Ansonsten passiert nichts. Wenn Sie also den Buggy gegen ein Glasfenster fahren, müssen wir trickreich vorgehen, damit das wie erwartet funktioniert. Da die Fenster am Ort festgesetzt sind, prallt der Buggy in der Physiksimulation tatsächlich vom Fenster ab. Das Physiksystem benachrichtigt allerdings das Spielsystem, dass eine Kollision aufgetreten ist. Das Spielsystem behandelt die Zerstörung, zerbricht also das Fenster in Glassplitter und benachrichtigt das Physiksystem, diese zu simulieren. Wichtig ist dabei, dass das Spielsystem auch das Physiksystem darüber informiert, dass der Status des Buggys an den Ort vor der Kollision zurückgesetzt werden muss. Dies stellt sicher, dass das nächste Mal, an dem die Physik simuliert wird, der Buggy frei durch das jetzt zerstörte Fenster fahren kann. Dieser Prozess führt in der Physik des Buggys für einen Frame zu einem Ruckler, da es kurz anhält und zum Zeitpunkt vor dem Aufprall zurück teleportiert wird. Es tut uns leid, wenn dieses Wissen Half-Life 2 für Sie absolut unspielbar macht. Jedoch hatten wir uns damals, zum Zeitpunkt unserer Spieltestbeobachtungen, zu diesem temporären Hilfsmittel entschieden – es macht den Aufprall spürbarer."
3918N/A"#commentary\cn_007_dynamic_mixing.mp3" "[ Kelly Bailey ] Während des Gameplays werden viele Klänge gleichzeitig abgespielt. Einige davon sind selbstverständlich wichtiger als andere und wir müssen die Lautstärken zueinander relativ festlegen, um sicherzustellen, dass die wichtigen hervorstechen. In einem Film wird die Soundmischung in der Nachbearbeitung durchgeführt. In einem Spiel aber geschieht dies in Echtzeit in Reaktion auf die Handlungen des Spielers. Deshalb können wir nicht vorhersagen, welche Klänge gleichzeitig abgespielt werden. Daher werden alle Klänge in Typen gruppiert und mit einer Priorität versehen. Während des Gameplays überwacht das Soundsystem alle aktiven Klänge und verringert die Lautstärke anderer Klänge, wenn ein Klang höherer Priorität abgespielt wird. Diese Mischung ist anpassbar. Wenn Schüsse in einer Szene lauter sein müssen, können wir diese in eine höhere Priorität verlegen. Wenn ein spezifischer Sprachdialog klar gehört werden muss, können alle anderen Klänge leiser gemacht werden. Wir tun dasselbe mit der Musik. Es ist ein subtiles, aber kritisches System und es verhindert, dass die Klanglandschaft zu ereignisreich ist."
3919N/A"#commentary\cn_014_exposition_board.mp3" "[ Danika Rogers ] Wir wollten diesen dichten visuellen Erzählstrang hierhin versetzen, da dieser Ort den Spielern am explizitesten dazu ermuntert, einen Raum zu erkunden. Obgleich dies hauptsächlich zum Aufbau der Hintergrundwelt diente, bemühten wir uns, die Beziehung zwischen Eli und Breen hervorzuheben und dem zentralen Konflikt der Welt einen Kontext zu geben."
3920N/A"#commentary\cn_020_box_car_joe.mp3" "[ Laura Dubuk ] Diese kleine Szene wurde ursprünglich mit zwei menschlichen Charakteren erstellt. Später in der Entwicklung ersetzten wir einen davon jedoch mit einem Vortigaunt. Wir wollten zeigen, dass Vortigaunts mit Menschen koexistieren und sich ebenfalls der Combine entgegenstellen können. Wir stellten auch ihre Fähigkeit zur Heilung des Spielers vor, obwohl wir im weiteren Verlauf des Spiels keinen durchgehenden Vorteil aus dieser Fähigkeit zogen. Vortigaunts wurden zu einem nützlichen narrativen Werkzeug, um Dialoge kurzzuhalten, da ihr Schwarmbewusstsein ihr vollständiges Wissen zur Welt und den Zielen des Spielers rechtfertigte. Dies bedeutete, dass sie nie Fragen stellen mussten – womit wir die Herausforderung des Schreibens von Dialogen für unseren stummen Protagonisten einfach umgehen konnten."
3921N/A"#commentary\cn_030_buggy_physics.mp3" "[ Charlie Brown ] Die Physik des Buggys benötigte einige Versuche. Wir wollten, dass er schnell ist, obwohl seine Höchstgeschwindigkeit bei etwa 56 km/h liegt. Deshalb mussten wir etwas schummeln, damit das funktioniert. Wir haben zusätzliche vertikale Kraft zum Turbosprung hinzugefügt sowie ein leichtes Zurückschleudern, wenn man die Handbremse für eine Schleuderwende anlegt. Ohne machte der Buggy einfach keinen Spaß, wegen der niedrigen Geschwindigkeit. Des Weiteren war die Welt voll unvorhersehbarem, von der Physik gesteuertem Chaos – Spieler verursachten mit dem Buggy alle möglichen Kollisionen, weshalb wir sicherstellen mussten, dass sie es immer herausschafften. Das benötigte sehr viele Experimente und Spieltests. Letztlich entschieden wir uns für eine ganz schön alberne, unrealistische Simulation, die den Buggy nachsichtiger machte und schwerer zum Überschlagen brachte. Die Schwerkraft des Buggys ist sehr niedrig, und die Räder drehen sich eigentlich nicht, obwohl es danach aussieht. Es war unser erster Versuch, ein physikalisch simuliertes Fahrzeug zu kreieren, und wir haben viel davon gelernt. Dank dessen war es uns möglich, das Autofahren in Episode 2 viel einfacher zu realisieren."
3922N/A"#commentary\cn_031_the_bridge.mp3" "[Charlie Brown] Die Inspiration für diesen Brückenabschnitt stammt von der Brücke des Deception Pass im Bundesstaat Washington. Wir hatten den Abschnitt ursprünglich als reines Navigationsrätsel erbaut und ihm schrittweise mehr Gameplay hinzugefügt. Es wurde auch zum primären Testfall dafür, wie Spieler an Kanten vorbei reiben. Wir erhöhten die Reibung in unserem Bewegungssystem auf subtile Weise, wenn sich Spieler dem Rand oder der Kante einer Oberfläche nähern. Spieler haben das noch nie bemerkt — wahrscheinlich, weil es auf natürliche Weise ihrem Ziel entspricht, am Rand oder an der Kante anzuhalten, um nach unten zu schauen. Wir bewegen uns in der Nähe eines Abhangs generell langsamer und vorsichtiger. Und das ist entscheidend für diesen Teil des Spiels. Dies ist uns bekannt, weil wir genau das zu einem bestimmten Zeitpunkt während der Entwicklung versehentlich zerstört hatten und plötzlich all unsere Spieltester wiederholt zu Tode stürzten."
3923N/A"#commentary\cn_032_coast.mp3" "[Chris Green] Wir wollten für den Buggy viel offenen Platz im Spiel, aber wir brauchten dennoch einen Weg, die Bewegungen der Spieler einzuschränken. Wir wählten eine Küstenlinie als natürliche Grenze entlang einer Seite der Karte, die dennoch viel offenen Raum gewährleistete. Dies half auch dabei, die Auswirkungen des Ressourcenabbaus durch die Combine visuell deutlich zu machen. Unsere Tester versuchten jedoch immer, ins offene Meer zu schwimmen, also fügten wir Blutegel hinzu, um sie davon abzuhalten. Die Blutegel konnten dabei kein echter, vermeidbarer Feind sein, den Spieler bekämpfen konnten. Sie sind also ein bisschen magisch. Und Spieler verstanden im Allgemeinen, dass sie mit dem Versuch, die Blutegel zu bekämpfen, die Grenzen des Spiels überschritten. Daher steckten wir nicht viel mehr in ihre Entwicklung."
3924N/A"#commentary\cn_033_grenade_house.mp3" "[Dave Riller] In vielen Half-Life-Spielen geht es darum, Spielern an jeder Ecke neue Kampferlebnisse zu bieten, auch wenn sie sich nur wenig von dem vorherigen Kampf unterscheiden. Nicht alle müssen eine auf Fähigkeiten basierende Herausforderung darstellen; manchmal sollen Spieler einfach nur Spaß haben. Das Granatenhaus ist ein anschauliches Beispiel. Um den Moment unterhaltsamer zu gestalten, lassen wir Spieler Granaten auf Gegner über ihnen statt unter ihnen werfen. Der unbegrenzte Granatenvorrat ist eventuell eine etwas ungeschickte Methode, um Spieler dazu zu ermutigen, sich auf das Szenario einzulassen. Ihre Unverwundbarkeit erlaubt ihnen jedoch auch dann noch auf das darüberliegende Stockwerk zu klettern, wenn alles andere in die Luft gesprengt wurde."
3925N/A"#commentary\cn_034_buggy_training_course.mp3" "[David Sawyer] Im Trainingsbereich können Spieler mit dem Buggy herumspielen. Als Half-Life 2 veröffentlicht wurde, war dieses Niveau der physikalischen Simulation in einem Fahrzeug noch neu, also wollten wir den Spielern reichlich Gelegenheit geben, damit zu experimentieren. Zusätzlich hatten Spieler gerade die engen Grenzen von Ravenholm verlassen, und wir hielten das schnelle Durchqueren eines weitläufigen Raums in einem Fahrzeug für eine gute, kontrastreiche Belohnung, bei der sich Spieler sicher fühlen konnten. Wir sorgten dafür, dass sie einen Turbosprung benötigen, um aus dem Startbereich herauszukommen. Das war gleichzeitig ein Test, um sicherzustellen, dass sie ein gewisses Maß an Komfort beim Fahren erreicht hatten und den Buggy nicht zurückließen."
3926N/A"#commentary\cn_035_ambush.mp3" "[David Sawyer] Eine Herausforderung eines Ego-Shooters im Half-Life-Stil ist, dass Spieler ständig auf neue Bereiche stoßen. Sie müssen also in unbekannten Umgebungen kämpfen, in denen sie nicht wissen, wie sie sich dem Kampf nähern sollen. Wir verwenden viele verschiedene Methoden, um dem Spieler bei diesem Problem zu helfen, und dieser Hinterhalt ist ein Beispiel dafür. Bei der Ankunft kämpft man zwischen den Häusern gegen eine Gruppe von Combine. Während des Kampfes und der anschließenden Erkundung hat man dann die Möglichkeit, das Layout der Arena kennenzulernen. Und wenn man anschließend diesen Dachboden erkundet, spawnen wir eine zweite Welle von Combine. Jetzt hat der Spieler den Vorteil, dass er das Layout kennt, sodass er bei der Verteidigung gegen Hinterhalte taktischere Entscheidungen treffen kann."
3927N/A"#commentary\cn_036_bugbait_training.mp3" "[David Sawyer] Das Training für die Verwendung der Käfer-Köder wirkt deshalb so unbeholfen, weil uns die Zeit davonlief. Aber Spieler mussten deren Verwendung verstehen, damit das Design von Nova Prospekt funktionierte. Generell versuchen wir, einem Training genügend Würze und Kontext zu verleihen, damit es sich nicht wie ein Training anfühlt, sondern wie eine neue, spannende Entdeckung. Hier ist uns das nicht ganz gelungen. So offensichtlich es auch scheinen mag, Spieler verstanden die Funktion der Käfer-Köder nicht intuitiv. Man befindet sich zu diesem Zeitpunkt schon tief im Spiel – Spieler haben somit viel Erfahrung im Umgang mit Gegnern. Bevor wir also ein Training hinzufügten, betraten die ersten Spieletester, die Käfer-Köder sammelten, das nächste Level und schossen instinktiv auf den ersten Ameisenlöwen, weil das bis dahin funktioniert hatte. Half-Life läuft nach dem Motto „Erst schießen, dann Fragen stellen“. Als Spieler Nova Prospekt erreichten, dachten sie nicht daran, Combine-Soldaten mit Käfer-Ködern zu bewerfen, sondern verließen sich auf ihre üblichen Waffen. Wir brauchten dieses Training also nicht nur, um zu zeigen, wie Käfer-Köder funktionieren, sondern auch, um zu demonstrieren, dass sich Ameisenlöwen in der Nähe des Spielers aufhalten würden, ohne anzugreifen."
3928N/A"#commentary\cn_037_vortigaunt_extraction.mp3" "[ Dhabih Eng ] Diese Arena war aus mehreren Gründen ein kniffliges Designproblem. Erstens ist der Soldat ein reiner Nahkampfgegner, daher konnten wir nicht zulassen, dass der Spieler Orte erreicht, an denen der Soldat ihm nicht folgen kann. Wir haben mit einigen Fernkampfangriffen experimentiert, aber die Ergebnisse gefielen uns nicht – sein Schleim-Spucken-Angriff zum Beispiel sah am Ende lächerlich aus. Der einzige überlebende Fernkampfangriff ist seine Fähigkeit, physische Objekte auf den Spieler zu schleudern. Aber dazu müssen sich die Objekte in Reichweite befinden, was nicht immer gewährleistet ist. Die zweite Herausforderung bestand darin, sicherzustellen, dass der Vortigaunt die Leiche des Soldaten erreichen kann, egal wo er stirbt. Dies war unerlässlich, da das Spiel nicht fortgesetzt werden kann, wenn der Vortigaunt den Käfer-Köder nicht extrahieren kann."
3929N/A"#commentary\cn_038_dropship_deployment.mp3" "[ Doug Wood ] Soldaten aus den Landungsschiffen einzusetzen war knifflig, da NPCs dafür in einem kompakten Objekt erscheinen mussten. Um sie ins Freie zu bringen, wo sie normal navigieren können, wurde eine Animation abgespielt, in der sie aus dem Container springen, sobald sie erscheinen. Als das funktionierte, stießen wir auf ein weiteres Problem – versierte Spieler warteten einfach außerhalb des Containers und erschossen die Soldaten, während sie aufstiegen. Um dem entgegenzuwirken, fügten wir dem Container einen Geschützturm hinzu. Dieser verhindert zwar nicht vollständig, dass ein Spieler auf die Soldaten schießen kann, insbesondere wenn er eine indirekte Waffe wie eine Granate oder etwas Ähnliches verwendet, aber es fühlte sich realistisch an und war eine logische, strategische Gegenmaßnahme."
3930N/A"#commentary\cn_039_laser_guided_rpg.mp3" "[ Eric Smith ] Die Lasersteuerung des RPG bereitete uns große Kopfschmerzen, weil sie schwer zu erklären war. Viele Spieletester feuerten das RPG ab und gingen sofort in Deckung, wodurch sie die Flugbahn der Rakete nicht sehen konnten. Schlimmer noch, sie bemerkten nicht, wenn die Rakete sich umdrehte und auf sie zuflog. Wir versuchten es mit verschiedenen HUD-Elementen und Laserpunktanzeigen, stellten jedoch fest, dass die meisten Spieler diese übersahen und sich stattdessen auf den Gegner konzentrierten. Wir nahmen so viele kleine Verbesserungen vor wie möglich, wie die Hervorhebung der Funktion in Odessas Rede und die Verbesserung der Audio- und Bildqualität rund um die direkte RPG-Schussabfeuerung des Schraubers. Obwohl diese Änderungen einigen Spielern halfen, erreichten wir nie einen Punkt, an dem wir sicher waren, dass nahezu alle Spieler die Funktion verstanden. Wir dachten darüber nach, sie ganz zu streichen, aber das hätte Kämpfe mit Schraubern viel weniger interessant gemacht. Die Lasersteuerung zwang Spieler, den Schrauber während des Flugs der Rakete im Blick zu behalten, aber das bedeutete auch, dass der Schrauber den Spieler sehen konnte, was mehr Spannung erzeugte."
3931N/A"#commentary\cn_040_performance_constraints.mp3" "[Eric Smith] Für die letzte Arena in Lost Coast hatten wir uns ein großes Finale vorgestellt, in dem der Spieler und eine Gruppe von Zivilisten im Kampf gegen Wellen von Combine-Soldaten antreten. Der Kampf sollte in einer Schlacht mit Hubschraubern gipfeln, doch leider führte der Rechenaufwand für Soldaten und Verbündete dazu, dass das Gefecht immer weiter reduziert werden musste, um unser Leistungsbudget zu decken. Zu dem Zeitpunkt, als nur noch ein Trupp von Soldaten zur selben Zeit beteiligt war, war die Entwicklung schon weit fortgeschritten. Da es zu spät war, umfangreiche Änderungen an der Arena vorzunehmen, um noch mehr Gegner aufnehmen zu können, mussten wir den Ablauf des Kampfes neu gestalten und die Anzahl der Soldaten auf ein Minimum reduzieren."
3932N/A"#commentary\cn_041_lighthouse_gunship.mp3" "[ Ido Magal ] Es hat einige Arbeit gekostet, das Hubschrauberszenario so umzusetzen, wie wir es uns vorgestellt hatten. Wir wollten, dass es sich wie in einem Film abspielt. In einem Film würde der Schrauber die Bewegungen des Protagonisten voraussehen und durch die Fenster feuern, während er den Leuchtturm erklimmt. Um dies im Spiel zu simulieren, versahen wir die Treppe mit durch Bewegung ausgelösten Meldern, die den Hubschrauber anweisen, seine Flugroute anzupassen, wenn sich der Spieler nach oben bewegt. Die Auslöser ermöglichen auch Zielscheiben auf den Fenstern, die dem Spieler am nächsten sind. Es handelt sich dabei um unsichtbare Spielobjekte, die die gegnerische KI sofort als feindlich wahrnimmt und den Hubschrauber veranlasst, auf die Fenster zu feuern. Diese Mischung aus KI und Scripts ist für die Kämpfe in Half-Life von zentraler Bedeutung. Die KI verwaltet das allgemeine, adaptive Verhalten der NSCs, während die Scripts die individuellen Anforderungen jedes Szenarios anpassen."
3933N/A"#commentary\cn_042_crane.mp3" "[ Jakob Jungels ] Der Kran erforderte viel Feinabstimmung. Ein Objekt, das so viel physikalische Kraft erzeugen musste, war angesichts der Einschränkungen unserer starren Körperphysik und Zerstörungstechnologie immer riskant. Beispielsweise hätte der Magnet nie die Erwartungen der Spieler an ein Objekt mit so viel Masse vollständig erfüllt. Aber da der Kran stationär war, konnten wir alles in seiner Reichweite sorgfältig auswählen und nach Bedarf fein abstimmen. Glücklicherweise schienen die meisten Spieler seine Ecken und Kanten nicht zu bemerken, wahrscheinlich weil die Interaktion in einer relativ realistischen physikalischen Umgebung so neu für sie war."
3934N/A"#commentary\cn_043_flashlight_power.mp3" "[ Jeff Lane ] Die Entscheidung, dass sich in Half-Life 2 das Sprinten und die Taschenlampe die Energie des HEV-Schutzanzugs teilen, war umstritten. Da nur ein kurzer Geschwindigkeitsschub ausgelöst werden sollte, wurde anfangs die Energiequelle des Anzugs nur für Sprints verwendet. Die Taschenlampe hingegen konnte unbegrenzt benutzt werden. Beim Testen des Spiels wurde jedoch ein Problem festgestellt: Spieler verließen oft dunkle Bereiche, ohne zu bemerken, dass ihre Taschenlampe noch an war. In hell erleuchteten, offenen Bereichen wie der Küste reichte unser Leistungsbudget nicht aus, um die Taschenlampe dauerhaft eingeschaltet zu lassen. Daher mussten wir sie ohne Eingreifen des Spielers ausschalten. Die Begrenzung der Leistung schien uns dabei die einfachste Lösung. Sie hatte auch den Vorteil, dunkle Bereiche spannender zu gestalten. Die Herausforderung bestand dann in der strategischen Verwendung vorhandener Ressourcen. Der Schutzanzug besaß bereits Energie, und wir wollten die Benutzeroberfläche nicht mit einer neuen Ressource nur für die Taschenlampe belasten. Wir spielten mit der Idee, dass andere Spielerfähigkeiten die Energie des Anzugs verwenden, und hielten es für interessant, wenn die Spieler Kompromisse zwischen ihnen eingehen mussten. Dies ist ein gutes Beispiel dafür, dass es beim Spieldesign oft darum geht, zwischen unvollkommenen Lösungen zu wählen. Wir waren nicht begeistert von der Idee, dass sich das Sprinten und die Taschenlampe eine Ressource teilen, aber wir wollten auch nicht, dass mehrere Ressourcen die Benutzeroberfläche überladen. In Episode 2 hatten wir nicht geplant, ein weiteres Objekt hinzuzufügen, das die Energie des Anzugs verbraucht, also entschieden wir uns letztlich, der Taschenlampe eine eigene Ressource zu geben."
3935N/A"#commentary\cn_044_open_world_loot.mp3" "[ Jeff Lane ] Die offene Landschaft von Lost Coast brachte ein neues Problem bzgl. der Verteilung von Belohnungen mit sich. In einem Half-Life-Spiel belohnen wir Spieler normalerweise für die Erkundung von Orten. Wenn sie den Weg vorwärts sehen, aber abseits des Pfades etwas Interessantes bemerken, lohnt es sich, dies zu untersuchen. Als wir anfingen, die Karten von Lost Coast zu testen, versteckten wir die Belohnungen in den Ecken der Außenbereiche. Dies führte jedoch zu einem weniger guten Spielererlebnis mit dem Buggy. In den weiten, offenen Flächen gibt es überall kleine Bereiche, an denen etwas von Interesse versteckt sein könnte, und die Spieler blieben ständig stehen und stiegen aus dem Buggy, um diese zu untersuchen. Es wurde mühsam und das Level machte nicht mehr so viel Spaß. Also entfernten wir die verstreuten Belohnungen. Nun hatten wir jedoch ein neues Problem: Wie zeigen wir Spielern, wann es sich lohnt, aus dem Buggy auszusteigen? Nach einigem Nachdenken stellten wir eine Regel auf: Jeder von Menschen errichtete Bereich würde immer mit Spielinhalten und einer Belohnung für die Erkundung einhergehen, während Bereiche in der Natur leer sein würden. Wir konnten es Spielern nicht direkt so sagen, aber es passte gut zu ihren natürlichen Annahmen und wir haben es in Bereichen wie diesem konsequent verstärkt."
3936N/A"#commentary\cn_045_gas_station.mp3" "[Jeff Lane] Wir hatten große Pläne für diese Begegnung. Wir überlegten, eine Tankstelle zu bauen, an der der Spieler kämpfen musste und wahrscheinlich die Benzintanks und alles andere in Brand gesetzt hätte. Vor unserem inneren Auge fuhr der Spieler mit Vollgas von einem riesigen Feuer davon. 2003 waren jedoch unser Budget und unsere Leistung stark eingeschränkt, und die Tankstelle musste dementsprechend schrumpfen und vereinfacht werden, um in die großen Level von Lost Coast zu passen. Unsere Pläne für ein dynamisches Feuersystem kamen daher nicht zustande, und die Tankstelle zu errichten, ergab keinen Sinn mehr. Es gibt immer eine Grenze beim Arbeitsaufwand für eine einzelne Begegnung. Am Ende sind die einzigen Überreste unserer ursprünglichen Vision die explosiven Benzintanks."
3937N/A"#commentary\cn_046_buggy_introduction.mp3" "[John Cook] Wir wollten etwas Interessanteres für die Einführung des Buggys, als den Spieler einfach einsteigen und wegfahren zu lassen. Der Kran hat dabei geholfen. Es war entscheidend für Spieler zu lernen, wie sie den Buggy wieder aufrichten können, wenn er umgekippt war. Diese Sequenz zwang sie in diese Situation. Training unter Druck ist immer schwierig, aber wir wollten den Schwarm Ameisenlöwen als Grund hervorheben, warum Spieler im Buggy bleiben sollten. Also hielten wir die Bedrohung durch die Ameisenlöwen aufrecht und stellten ein paar Zivilisten mit montierten Gewehren zur Unterstützung zur Verfügung. Als kleinen Bonus haben Spieler dabei das Gefühl, vom Kran angehoben zu werden — kurz bevor sie einen bedienen können."
3938N/A"#commentary\cn_047_crossbow.mp3" "[ John Cook ] Dies ist die erste Gelegenheit für den Spieler, an die Armbrust im Spiel zu gelangen. Rückblickend ist es überraschend, dass wir sie nicht gesperrt haben. Es ist nämlich gut möglich, dass der Spieler einfach daran vorbeifährt. Um die Wahrscheinlichkeit zu verringern, richteten wir die Straßensperre und den Aussichtspunkt so ein, dass die Spieler ermutigt werden, aus dem Buggy auszusteigen und die Armbrust und die Gegenstandskiste zu entdecken. Beim Testen hat sich gezeigt, dass fast jeder Spieler anhielt und die Waffe einsammelte. Aber dies ist ein Fall, in dem der Unterschied zwischen einem Test und tatsächlichem Spielen eine Rolle spielt. Ein Spieletester, der seit Beginn von Lost Coast spielt, ist möglicherweise nicht so ermüdet vom Erkunden wie jemand, der sich vom Anfang des gesamten Spiels durchgespielt hat. Also platzierten wir in einem vorherigen Level eine weitere Armbrust auf dem Weg des Spielers in Nova Prospekt."
3939N/A"#commentary\cn_048_rollermines.mp3" "[Josh Weier] Kugelminen wurden entwickelt, um Feinde zu erschaffen, die Spieler beim Fahren des Buggys bedrohen können. Da Spieler im Buggy im Grunde eine vollständig physisch simulierte Entität sind, hielten wir es für interessant, auch einen physisch simulierten Feind zu haben. Der Schnitter hatte uns bereits gezeigt, wie dieser Ansatz zu vielen interessanten Interaktionen führen kann. Also bauten wir die Kugelmine, deren Bewegung ausschließlich dadurch angetrieben wird, dass sie selbst Drehkraft erzeugt. Wir arbeiteten so lange an ihrem Verhalten, bis es Spaß machte, sie mit dem Buggy zu überfahren. Kugelminen sind für den Buggy nicht sonderlich gefährlich, aber wenn man einen Stapel anfährt, können sie zu einem Problem werden, besonders in der Nähe einer Klippe. Wir sorgten auch dafür, dass sie gut funktionieren, wenn der Spieler zu Fuß unterwegs ist, sodass Leveldesigner ein paar zusätzliche Begegnungen aus ihnen herausholen konnten."
3940N/A"#commentary\cn_049_sandtrap_thumper.mp3" "[ Laura Dubuk ] Die explosiven Fässer werden Spielern zur Bekämpfung von Feinden zur Verfügung gestellt und stehen gleichzeitig im Schutz von Rammen. Wir verwenden sie außerdem als Hinweis auf eine bevorstehende Begegnung mit einer Löwenwache, bei der Spieler zum Sieg oft ähnliche Taktiken anwenden. Optionale Methoden, wie Sprengstoffe mit dem Gravitron zu explodieren, vergisst man leicht, wenn man sie nicht regelmäßig anwendet. Das breite Spektrum an Angriffsoptionen gibt Spielern keine Garantie, dass sie diese Möglichkeiten in letzter Zeit genutzt haben. Also hier schlagen wir subtil vor, dass sie diese wieder in Erwägung ziehen und sich daran erinnern, bevor sie einem Feind gegenüberstehen."
3941N/A"#commentary\cn_050_coast_kickoff.mp3" "[Marc Laidlaw] Diese Zwischenszene entstand erst spät in der Entwicklung, um Ravenholm mit Lost Coast zu verbinden. Fällt Ihnen ein Trend auf? Viele Verbindungen von Versatzstücken in unseren Spielen kommen erst spät zustande. In diesem Fall hieß das, wo immer möglich, Abstriche zu machen. Wir hatten nicht einmal die Zeit, Alyx auf dem Monitor zu animieren. Es ist immer eine Herausforderung, solche Szenen interessant zu gestalten, und bei dieser gelang es uns einfach nicht. Aber dieser Fall ist ein gutes Beispiel dafür, was passiert, wenn NPCs wie Wegweiser behandelt werden, ohne ihnen oder der Szene Charakter zu verleihen. Das Ergebnis ist ein Moment, den man als Spieler sofort wieder vergisst und in dem die Schwächen des Spiels zum Vorschein kommen. Aber das liegt in der Natur der Entwicklung — man hat nur begrenzt Zeit und muss diese sinnvoll einsetzen. Kleiners und Elis Labor waren viel wichtiger, also haben wir uns in unseren Bemühungen darauf konzentriert."
3942N/A"#commentary\cn_051_odessa_cubbage.mp3" "[Marc Laidlaw] Odessa Cubbage ist ein Beispiel für einen kurz auftretenden Charakter, der gut funktionierte. Er ist ein unterhaltsamer Typ, mit unterhaltsamen Details, der in seiner eigenen kleinen Blase lebt. Da er diese nicht verlässt, kann er übertrieben sein, um aufzufallen. Sein Modell stammte aus einem ausgeschnittenen und wiederverwendeten Abschnitt des Spiels, und wir benannten ihn nach dem Titel einer Spam-E-Mail, die wir erhalten hatten. Das Modell war ursprünglich ein norwegischer Fischer und passte nicht ganz als Engländer, also verpassten wir ihm einen Schnurrbart. So wurde Odessas Charakter geboren. Letztlich ist er ein Scharlatan, an dem alles falsch ist — sein Akzent, sein Schnurrbart, alles. Er würde sich niemals selbst in Gefahr bringen, was ihn perfekt macht, um Gordon das Rollenspiel in die Hand zu geben und ihm ausschweifend zu erklären, wie man es benutzt."
3943N/A"#commentary\cn_052_28_transitions_later.mp3" "[Marc Laidlaw] Nachdem wir einige Level mit dunklen Tunneln als Übergangsräume aneinandergereiht hatten, wurde uns klar, dass wir die Erwartungen der Spieler untergraben konnten, indem wir ein weiteres Level einbauten, das wie ein Übergang aussah, aber stattdessen etwas anderes enthielt. Wie viele Spieler sahen wir 2002 das Spiel 28 Days Later, waren begeistert und wollten sofort eine eskalierende Zombie-Begegnung in einem unserer dunklen Tunnel inszenieren. Diese kam schnell zusammen und wir waren mit dem Ergebnis zufrieden. Jahre später trafen wir Alex Garland, den Autor des Films. Er hatte Half-Life 2 gespielt und es hatte ihm sehr gefallen. Er war sehr erfreut, dass sein Film diesen Abschnitt inspiriert hatte."
3944N/A"#commentary\cn_053_finest_mind_of_his_generation.mp3" "[Marc Laidlaw] Hier ist eine weitere kleine Zwischenszene, die am Ende gut funktioniert hat. Die einzige Voraussetzung für diesen Moment war, dem Spieler klarzumachen, sich vom Sand fernzuhalten. Bei früheren Szenen haben wir uns immer darauf konzentriert, sie einfach funktionsfähig zu machen, aber als wir zu dieser Szene kamen, fühlten wir uns wohler und fingen an, den Prozess zu genießen, zusätzliche Gedanken in diese Begegnungen zu implementieren. Dabei haben wir die Charaktere dazu gebracht, nicht nur als Wegweiser zu dienen, sondern etwas Interessanteres und Unterhaltsameres zu schaffen. Nach der Veröffentlichung gewann Lazlo eine riesige Fangemeinde und erinnerte uns daran, wie schwer es ist, vorherzusagen, was Spielern ans Herz wächst."
3945N/A"#commentary\cn_054_bridge_playtesting.mp3" "[ Matt Boone ] Der Abschnitt mit der Brücke war immer ein Höhepunkt bei unseren Spieletests. Tester reagierten durchweg intensiv darauf. Ihre Anspannung war in ihren Bewegungen sichtbar, während sie sich langsam über die Träger bewegten. Mit der Zeit haben wir mehr Herausforderungen in die Überquerung eingebaut, und die Spieletests wurden immer unterhaltsamer anzusehen. Vom Zug, der über die Brücke rumpelte und Spieler schüttelte, bis zu der überraschenden Kopfkrabbe in der Hütte, die auf halbem Weg wie ein sicherer Hafen aussah. Wir hatten zwar ein etwas schlechtes Gewissen, weil wir den sichtbaren Stress der Spieletester genossen, aber wir waren keine Monster: Nachdem die Spieler es über die Brücke geschafft hatten, atmeten sie erleichtert auf, deaktivierten den Combine-Schild und merkten dann, dass sie über die Unterseite zurückkehren mussten. Da wir befürchteten, dass sie sich auf der zweiten Reise langweilen könnten, beschlossen wir, einen Hubschrauber hinzuzufügen, um ihnen Gesellschaft zu leisten."
3946N/A"#commentary\cn_055_thumper_final_stage.mp3" "[ Matt Boone ] Uns gefiel die letzte Stufe der Rammen, in der ihr Zweck umgekehrt wird. Anstatt nun als Sicherheitsinstrument zu dienen, blockieren sie die Ameisenlöwen des Spielers. Allerdings hätten wir vorher wahrscheinlich ein gründlicheres Training für die Rammen einbauen sollen. Während Spieler in den vorherigen Levels von Lost Coast die Rammen nur bis zu einem gewissen Maße verstehen müssen, stand zu diesem Zeitpunkt im Geschehen mehr auf dem Spiel, weil die Spieler gleichzeitig zum ersten Mal Käfer-Köder ausprobieren mussten. Spieler, die nicht wissen, dass die erste Ramme ihre Ameisenlöwen daran hindert, weiterzukommen, verstehen möglicherweise auch nicht, wie Käfer-Köder funktionieren. Wenn sie diese auf Soldaten im ersten Bunker werfen und keine Ameisenlöwen erscheinen, schließen sie daraus möglicherweise, dass Käfer-Köder unzuverlässig sind oder nicht wie erwartet funktionieren, und greifen stattdessen wieder auf ihre Waffen zurück."
3947N/A"#commentary\cn_056_buggy_tools.mp3" "[Matt Wright] Unsere Absicht war, den Buggy zu mehr als nur einem Fortbewegungsmittel zu machen. Also beschlossen wir, eine Waffe daran anzubringen. Wir entschieden uns für die Tau-Kanone, eine Waffe aus Half-Life 1, die uns gefiel, für die wir aber in Half-Life 2 keinen Platz gefunden hatten. Die Tau-Kanone kann durch Wände schießen, was zu Schwierigkeiten beim Leveldesign führt. Deshalb haben wir sie auf den Küstenbereich beschränkt. Sobald man Waffen einführt, deren Geschütze Wände durchdringen, wird das Leveldesign viel schwieriger. Außerdem haben wir eine Munitionskiste auf der Rückseite des Buggys angebracht, sodass Spieler überall in Lost Coast über unbegrenzte SMG-Munition verfügen. Das war besonders hilfreich für unsere Spieltester, die mit den unendlichen Ameisenlöwen zu kämpfen hatten."
3948N/A"#commentary\cn_057_antlion_guard.mp3" "[ Matt Wright ] In seltenen Fällen konnten Spieler den Ameisenlöwen in dieser Arena nicht töten. Dies passierte, wenn ihnen die Munition ausging und sie alle verfügbaren physischen Objekte verwendet hatten, sodass keine Munition mehr für die Gravitationskanone übrig war. Um dieses Problem zu beheben, brachten wir als Sicherheitsmaßnahme einen Zivilisten auf dem Turm über dem Tor an, der den Ameisenlöwen töten konnte, wenn der Spieler keine Möglichkeit mehr zur Verfügung stand."
3949N/A"#commentary\cn_058_terrain_and_performance.mp3" "[ Mike Dussault ] Unser Leistungsbudget war oft eine erhebliche Einschränkung, wenn es um Kämpfe ging, und noch mehr bei Kämpfen auf Geländeoberflächen. Wenn sich NSCs bewegen, führen sie viele kleine räumliche Sondierungen durch, um festzustellen, ob sie ihren gewählten Weg sicher beschreiten können. Stellen Sie sich vor, Sie können nichts sehen und schwenken ständig einen Stock vor sich hin und her, um zu prüfen, ob der Weg frei ist. Die Leistungskosten dieser Sondierungen steigen mit der Komplexität der Weltgeometrie. Unser Geländeverschiebungssystem erstellt unebene Oberflächen mithilfe vieler Polygone – weit mehr als die perfekt ebenen Böden, die man anderswo zu dieser Zeit fand. Das bedeutete, dass NSCs in Lost Coast bewegten, ressourcenintensiver waren als in anderen Bereichen, und diese Einschränkung diktierte den Umfang vieler Begegnungen in diesem Abschnitt des Spiels."
3950N/A"#commentary\cn_059_area_portals.mp3" "[ Mike Dussault ] Eine Leistungsherausforderung, der wir uns in Coast gegenübersahen, war die Handhabung eines großen, offenen Geländes mit Gebäuden, die hoch detaillierte Innenräume hatten – oder zumindest waren sie für die 2003 üblichen Standards sehr detailliert. Wir wollten so viel wie möglich von unserem Budget für die Darstellung des Außenbereichs verwenden, ohne Ressourcen für die Innenräume der Gebäude zu verlieren. Aber wenn wir nicht alle Fenster und Türen vernageln wollten, konnte der Spieler immer noch hineinsehen. Um dieses Problem zu lösen, entwickelten wir die Funktion der Portale, die wir in jedes offene Fenster und jede offene Tür setzten. Diese Portale berechnen vorab ein flaches Bild des Gebäudeinneren. Wenn ein Spieler in einiger Entfernung ist, zeigen sie dieses vorab berechnete Bild über dem Fenster oder der Tür an, sodass wir das Rendern des tatsächlichen Innenraums überspringen konnten. Wenn sich der Spieler nähert, überblenden wir sanft zwischen dem Bild des Portals und dem tatsächlichen Inneren des Gebäudes. Bei sorgfältiger Verwendung halfen uns die Portale, unsere Leistungsziele in Lost Coast zu erreichen – zusammen mit der gelegentlichen Tür, die sich hinter einem schloss."
3951N/A"#commentary\cn_060_buggy_removal.mp3" "[Miles Estes] Den Punkt, an dem der Spieler den Buggy zurücklassen soll, mussten wir sehr deutlich machen. Überall in Lost Coast hatten die Spieler den Buggy verlassen und kehrten dann zu ihm zurück. Wir stellen also fest, dass Spieltester versuchen würden, ihn mitzunehmen, wenn es auch nur im Entferntesten möglich erschien. Diese kleine Garagenszene dient in erster Linie dazu, deutlich zu signalisieren, dass der Spieler zu Fuß weiterspielen muss."
3952N/A"#commentary\cn_061_d2_coast_04.mp3" "[ Randy Lundeen ] Diese Karte war der erste Bereich von Lost Coast, noch bevor es den Kran und andere Elemente gab. Der trockengelegte Meeresboden und die verrosteten Schiffe waren einige der ersten künstlerischen Elemente, die wir entwickelt hatten. 2003 präsentierten wir die Karte in unserer E3-Demonstration, obwohl damals noch vieles bzgl. Gameplays in Arbeit war. Als wir dann begannen, den gesamten Abschnitt für Lost Coast aufzubauen, wurde diese Demonstration zu einer nützlichen Vision für uns, auf die wir hinarbeiten konnten."
3953N/A"#commentary\cn_062_transition_tunnels.mp3" "[ Randy Lundeen ] Für Lost Coast mussten wir eine Methode für Levelübergänge entwickeln. Um von einem Level zum nächsten zu gelangen, mussten wir alles im Übergangsbereich speichern und es nach dem Laden im nächsten Level wiederherstellen. Entscheidend war auch, dass wir alles speicherten und wiederherstellten, was für den Spieler im Übergangsbereich sichtbar war, auch wenn es außerhalb des Bereichs selbst lag. Deswegen versuchten wir, Übergangsbereiche so klein und geschlossen wie möglich zu halten. In den meisten Teilen des Spiels funktioniert ein kleiner Bereich gut für diesen Zweck. Aber für das Gelände von Lost Coast benötigten wir eine andere Lösung. Nach einigen Experimenten entschieden wir uns für dunkle Tunnel. Diese konnten nicht nur wiederverwendet werden, sondern ermöglichten es uns auch, am Ende Licht hinzuzufügen, um die Tatsache zu verschleiern, dass wir das, was vor dem Spieler liegt, nicht rendern konnten, weil es sich in einem anderen Level befand."
3954N/A"#commentary\cn_063_sniper_alley.mp3" "[ Robin Walker ] Dieser Spielbereich wurde spät in der Entwicklung hinzugefügt. Wir verlegten Elis Labor und Ravenholm vor die Lost Coast. Obwohl Sie vielleicht meinen, das Spiel sei linear erstellt worden, haben wir es tatsächlich in drei Gruppen aufgeteilt und parallel an verschiedenen Bereichen gearbeitet. Der erste Durchlauf jeder Gruppe konzentrierte sich darauf, den Kern ihres Bereichs fertigzustellen, bevor sie mit dem Rest fortfuhren. Nach der Fertigstellung einer groben Version des Spiels kehrten wir zu jedem Bereich zurück und feilten daran. Wir fügten so etwa erfolgreiche Elemente von anderen Bereichen hinzu und entfernten andere, die nicht funktionierten. In einigen Fällen, wie in Ravenholm, wurden ganze Bereiche verlegt. Nachdem Ravenholm verlegt wurde, benötigten wir einen neuen Bereich, der diesen mit der Küste verband. Das ist der Bereich, den Sie jetzt gerade betreten. Aufgrund des Zeitdrucks wurde dieser kleine Bereich mit bestehenden, erprobten Gameplay-Elementen wie Scharfschützen und Combine-Soldaten erstellt."
3955N/A"#commentary\cn_064_battery_finding.mp3" "[ Robin Walker ] Die erhöhte Anzahl an Objekten in den Spielbereichen von Half-Life ermöglichte es uns, Spieler nach einem bestimmten Gegenstand suchen zu lassen, insbesondere, wenn rationale Gründe den Fund rechtfertigen. Spieler können entweder den Gegenstand durch Beobachtung oder Deduktion lokalisieren oder den Bereich mit schierer Gewalt durchsuchen. Da wir bereits einige Modelle für Autos und Batterien entworfen hatten, war es natürlich, für Spieler einen Schrottplatz zur Erkundung zu kreieren. Wir versteckten an einigen unerwarteten Orten auch einige Extrabatterien, an die Spieler mit brachialer Gewalt gelangen konnten. Auch dieses gegenstandsbasierte Rätsel erforderte eine Zusatzversicherung für den Fall, dass Batterien verloren gehen. Wenn Sie möchten, können Sie alle Batterien über die Klippe werfen, um zu sehen, was passiert."
3956N/A"#commentary\cn_065_boathouse.mp3" "[ Scott Dalton ] Wir konnten in Half-Life 1 viel aus Szenarios herausholen, in denen KI-Gegner gegeneinander kämpften. Es bereitete den Spielern Freude, den Gegnern beim Kämpfen zuzusehen und erleichterte die Beobachtung ihres Verhaltens. Die erste Begegnung zwischen Ameisenlöwen und Combine-Soldaten war so gestaltet, dass sie ermöglichte, etwas mit dem Buggy zu rammen und die Funktion der Ramme hervorzuheben. Unser Ziel war es, dass Spieler durch die Beobachtung der Soldaten verstehen, wie sie Ameisenlöwen mit der Ramme vertreiben können. Wir wollten mit den Soldaten demonstrieren, wie wichtig es war, sich in der Nähe der Ramme aufzuhalten, um die Ameisenlöwen zu bekämpfen."
3957N/A"#commentary\cn_066_buggy_theft.mp3" "[ Scott Dalton ] Als wir das Ende der Lost Coast erstellten, entschieden wir uns, den Buggy des Spielers durch die Combine stehlen zu lassen. Es war nicht wirklich logisch, jedoch stellten wir nach zahlreichen Spieltests fest, dass Spieler stark an ihrem Buggy hingen. Wir wollten deshalb diese emotionale Verbindung ausnutzen. Sobald wir den Diebstahl implementierten, schrien die Spieltester die Combine an, weil diese ihren Buggy gestohlen hatten – ein Riesenerfolg. Die Soldaten, die von den Felsen herabschossen, waren nur dazu da, um die Spieler dazu zu bewegen, hochzuschauen. Dadurch wurde das Landungsschiff mit dem Buggy ausgelöst. 20 Jahre später können wir kaum glauben, wie absurd das alles ist."
3958N/A"#commentary\cn_067_snipers.mp3" "[ Ted Backman ] Das Team von Half-Life 2 war nie sonderlich groß. Deshalb suchten wir stets nach Möglichkeiten, neues Gameplay ohne hohe Produktionskosten für Elemente zu entwickeln. Ein hervorragendes Beispiel dafür ist der Scharfschütze. Es gibt kein reales Modell dafür, lediglich einen Laserstrahl. Also benötigte er weder ein Artwork noch eine Animation. Wenn er stirbt, wird lediglich eine Ragdoll für einen Combine-Soldaten hervorgerufen, die aus dem Fenster fällt. Trotz der Einfachheit haben wir es geschafft, ein einzigartiges Gameplay dafür zu kreieren. Besonders beeindruckte uns die Interaktion des Scharfschützen mit der Physik der Objekte in der Spielwelt. Spieler sind daran gewöhnt, explosive Objekte in der Nähe von Gegnern auszunutzen. Daher fanden wir es passend, dass ein Gegner diese Dynamik auf den Kopf stellt, sobald der Spieler sich in Deckung befindet."
3959N/A"#commentary\cn_068_buggy_model.mp3" "[ Ted Backman ] Das Modell des Buggys durchlief viele Iterationen, bevor es seine endgültige Version erreichte. Wir haben Designs ausprobiert, die sowohl unseren künstlerischen als auch unseren physikalischen Simulationsanforderungen entsprachen, sind dann aber auf ein unerwartetes Problem gestoßen: Vielen Spieletestern, sogar erfahrenen Spielern von Ego-Shootern, wurde beim Fahren des Wagens übel. Bei unseren Optimierungen stellten wir fest, dass eine Änderung des Buggy-Modells half, denn je mehr das Modell die Welt verdeckte, desto mehr Spieler empfanden Übelkeit. Also entfernten wir Teile des Modells, vor allem an der Karosserie, bis den Spielern nicht mehr übel wurde. Insbesondere die Möglichkeit, den Boden durch das fehlende Fahrgestell sehen zu können, machte einen spürbaren Unterschied."
3960N/A"#commentary\cn_069_antlion_design.mp3" "[ Ted Backman ] Beim anfänglichen Design für das Spiel hatten wir Pläne für mehrere Arten von Aliens, von denen die Combine nur eine war. Eines der anderen war ein religiöses Volk von insektenartigen Wesen, zu dem auch die Ameisenlöwen gehörten. Später, als wir Lost Coast entwickelten, begannen wir, sie eher als Schädlinge zu betrachten, die zusammen mit Kopfkrabben und anderen Kreaturen durch die Xen-Portale kamen. Obwohl sie eigentlich nicht von Xen stammen, befallen sie alle Ecken jeder Welt, die sie betreten – ähnlich wie Kakerlaken."
3961N/A"#commentary\cn_070_explosive_barrels.mp3" "[ Brian Jacobson ] An dieser Stelle führen wir explosive Fässer ein, ein Klassiker aus Ego-Shootern, aber mit einer neuen Wendung: Der zweite Pistolenschuss setzt das Fass in Brand und löst eine zeitgesteuerte Detonation aus. Ein dritter Schuss lässt das Fass sofort detonieren. Auf diese Weise können Spieler die Explosion je nach Situation entweder verzögern oder sofort auslösen. Spieler können eine Klette mit einem explosiven Fass füttern und dann zweimal darauf schießen, um mehrere von ihnen gleichzeitig zu erledigen. Die verzögerte Explosion sorgt auch für interessantere Kettenreaktionen zwischen mehreren Fässern. Explodierende Fässer sind ein Fan-Favorit der Serie. Aber auch intern waren viele Leveldesigner überzeugt, das Spiel könne nie genug solcher Fässer haben."
3962N/A"#commentary\cn_071_ragdoll_magnets.mp3" "[ Dario Casali ] Die Physik von Half-Life 2 gab uns eine Reihe von Werkzeugen, Kämpfe spannender zu gestalten. Wenn Gegner den Spieler beispielsweise verfehlen, lenken wir ihre Schüsse subtil auf zerbrechliche Objekte in der Nähe, was für Chaos sorgt und das Gefühl erzeugt, als ob man sich in einem Actionfilm befindet. Wir haben die Physik auch für Hinweise eingesetzt, wie die sogenannten „Ragdoll-Magnete“, durch die Leichen der Gegner auf interessante und dramatische Weise fallen – beispielsweise bei Felsvorsprüngen oder auf der Fahrbahn eines Zugs."
3963N/A"#commentary\cn_072_helicopter_peekaboo.mp3" "[ Dave Riller ] Wir wollten den Combine-Kampfhubschrauber als zentralen Antagonisten im gesamten Kapitel entwickeln und so zu einem eigenständigen Charakter machen. Wenn Sie sich diesen Kommentar anhören, können Sie auch seinen Motor hören und, wenn Sie jetzt nach oben schauen, können Sie ihn entlang der Bahngleise und in die Ferne fliegen sehen. Dieser erste Blick ist eine kleine Vorahnung, deren Präsenz mit der Zeit deutlicher wird – bis Sie schließlich gegen ihn antreten."
3964N/A"#commentary\cn_073_iterative_passes.mp3" "[ David Speyrer ] Einige Kapitel des Spiels, die man zu Fuß erkunden kann, wie die Abschnitte der Kanäle und Ravenholm, wurden in mehreren Durchgängen von verschiedenen Leuten entwickelt. Wir fanden heraus, dass die Weitergabe der Karten an Kollegen mehr Abwechslung im Spiel und mehr interessante Momente erschuf, da jedes Team den Karten eine einzigartige Note verlieh. In den Kanälen wurden im ersten Durchgang das Design und der Weg des Spielers sowie die Grundzüge des Spiels und einige wichtige Eckpunkte festgelegt. Der teamweite Alpha-Spieltest stellte jedoch fest, dass dieser Abschnitt nicht sehr spannend, sondern etwas eintönig war. In unserem zweiten Durchgang kehrten wir zur Karte zurück und konzentrierten uns ausschließlich darauf, mehr Spannung zu erzeugen, indem wir entsprechende Szenarien enger aneinander reihten."
3965N/A"#commentary\cn_075_pistol_design.mp3" "[ Josh Weier ] Die Standardpistole leistet die meiste Arbeit im Spiel. Sie ist nicht nur die erste Fernkampfwaffe, deren Gebrauch Spieler erlernen, sondern garantiert auch, dass man während des gesamten Spiels aus sicherer Entfernung mit der Physik und zerstörbaren Objekten interagieren kann. Damit sie reaktionsschneller und unterhaltsamer zu bedienen ist, verfügt die Pistole über eine einzigartige Nachfeuermechanik. Die Waffe feuert so schnell, wie der Spieler auf die Eingabetaste klicken kann. Man spürt also eine sofortige Reaktion auf die Eingabe und je schneller man klickt, desto schneller kann man schießen."
3966N/A"#commentary\cn_076_shatterglass.mp3" "[Josh Weier] Bei der Entwicklung der frühen Levels, in denen Spieler noch nicht so viele Werkzeuge besitzen, stellten wir fest, dass es genauso spannend ist, stattdessen neue technische Eigenschaften und Objekte ins Rampenlicht zu stellen. Dazu gehört das zerbrechliche Glas, das man hier sieht. Für den zerstörerischen Effekt wurde das Glas in ein Raster aus kleinen Quadraten unterteilt, sodass wir verfolgen konnten, welche intakt oder kaputt waren. Wir konnten außerdem größere Löcher erschaffen, sobald nicht mehr genügend Quadrate miteinander verbunden waren. Jedes Quadrat wurde mit einer einzigartigen Textur gerendert, die auf dem Status der benachbarten Quadrate beruht. So entstanden die scharfen, gezackten Kanten zwischen zerbrochenem und intaktem Glas. Glasscherben sind heute in Spielen die Norm, aber als wir Half-Life 2 entwickelten, hatten wir dies noch nicht oft gesehen und waren sehr zufrieden mit dem Grad der Klangtreue und Dynamik, die das Spiel dadurch erhielt."
3967N/A"#commentary\cn_077_lambda_caches.mp3" "[ Laura Dubuk ] Technisch gesehen befindet sich der erste Lambda-Behälter in Kleiners Labor. Aber dies ist der erste von vielen, den der Spieler selbst entdeckt. Wir fügten Lambda-Behälter hinzu, um Spieler zum Erkunden zu animieren und ihnen Hinweise zu geben, wo versteckte Ressourcen zu finden sind. Die Idee dahinter war, dass sie von der Widerstandsbewegung platziert wurden. In Half-Life war der Inhalt der Behälter durch das Leveldesign vorgegeben. In Half-Life 2 haben wir adaptive Behälter eingeführt, die Spielern alles geben, was ihnen gerade fehlt, basierend auf den vom Leveldesigner festgelegten Ressourcenzielen."
N/A3917"#commentary\cn_001_physics_sound.mp3" "[ Jay Stelly ] Damit sich die Physik für Spieler richtig anfühlt, müssen auch die von der Physik erzeugten Geräusche richtig klingen. Wir alle erwarten bestimmte Geräusche, wenn Objekte und Materialien miteinander interagieren, auch wenn wir dies nicht immer aktiv wahrnehmen. Uns war bewusst, dass wir nicht jedes Geräusch nachbilden konnten. Daher wollten wir uns auf die Details konzentrieren, die am meisten dazu beitragen, dass unsere Physik realistisch klingt. Wir begannen mit Geräuschen pro Objekt für Kollisionen und Stöße. Dadurch besaß ein Objekt, etwa eine Holzkiste, individuelle Geräusche, wenn es mit anderen Objekten oder Objektarten kollidierte. Als Nächstes begannen wir, diese Geräusche dynamisch zu modifizieren, basierend auf den Eigenschaften des physikalischen Ereignisses, wie dem Gewicht oder Volumen und der Stärke der Interaktion. Dies funktionierte hervorragend bei Kollisionen. Bei anderen Interaktionen, wie etwa aneinander reibenden Objekte, funktionierte es jedoch nicht so gut. Eine Holzkiste macht ein anderes Geräusch, wenn sie an einer Wand schleift, als wenn sie gegen die Wand geworfen wird. Ich kann guten Gewissens behaupten, dass niemand die Nuancen der physikalischen Eigenschaften einer Holzkiste umfangreicher erforscht hat als wir. Um in diesen Interaktionen das gewünschte Ergebnis zu erzielen, implementierten wir Kollisionsgeräusche für jedes Material – Metall gegen Holz, Metall gegen Metall und so weiter. Diese Geräusche wurden außerdem dynamisch unter Berücksichtigung von Details wie der Härte des Materials oder der Metallart angepasst. Um mit diesem System den richtigen Klang zu erzielen, waren unzählige kleine Anpassungen erforderlich, doch dafür mussten wir das Ganze erst in Aktion sehen. Wir haben auch mit individuellen Geräuschen für rollende Objekte experimentiert, das haben wir am Ende jedoch verworfen, weil wir mit den Ergebnissen nicht zufrieden waren."
N/A3918"#commentary\cn_002_ramming_with_the_buggy.mp3" "[ Jay Stelly ] Unser Physiksystem basiert auf starren Körpern, das heißt, es unterstützt weder Verformung noch Zerstörung von Objekten. Wenn ein physikalisches Objekt getroffen wird, kann es sich, falls erlaubt, bewegen. Ansonsten passiert nichts. Wenn also der Buggy gegen ein Glasfenster fährt, müssen wir zu einem Trick greifen, damit das wie erwartet funktioniert. Da das Fenster fest verankert ist, prallt der Buggy in der Physiksimulation vom Fenster ab, aber das Spielsystem wird benachrichtigt, dass eine Kollision aufgetreten ist. Das Spielsystem ist für Zerstörung zuständig, es bricht also das Fenster in einzelne Glassplitter und lässt sie vom Physiksystem simulieren. Wichtig ist dabei, dass das Spielsystem dem Physiksystem auch sagt, dass der Buggy an den Ort vor der Kollision zurückgesetzt werden muss. Dadurch wird sichergestellt, dass das nächste Mal, wenn die Physik simuliert wird, der Buggy frei durch das jetzt zerstörte Fenster fahren kann. Dieser Prozess führt in der Physik des Buggys für einen Frame zu einem Ruckler, da er kurz anhält und zum Zeitpunkt vor dem Aufprall zurückteleportiert wird. Es tut uns leid, wenn dieses Wissen Half-Life 2 für Sie absolut unspielbar macht. Aber nachdem wir damals die Spieltests beobachtet haben, kamen wir zu dem Entschluss, dass uns der Ruckler gefällt – er macht den Aufprall spürbarer."
N/A3919"#commentary\cn_003_ramming_zombies_with_the_buggy.mp3" "[ Jay Stelly ] Als Menschen haben wir bestimmte Erwartungen an unsere physikalische Welt, wie bereits einige Male in diesen Kommentaren erwähnt. Eine dieser Erwartungen ist, dass Zombies durch die Luft geschleudert werden müssen, wenn man ihn mit einem Auto umfährt. Jedoch ist dieser Effekt im Spiel nicht so einfach wie in der realen Welt. Aus Leistungsgründen verwenden Feinde wie Zombies während des Gameplays eine vereinfachte Kollisionsbox. Hierbei handelt es sich um eine Box, die eng um den Zombie liegt, ohne dass ein Teil des Modells herausragt. Wenn der Zombie aber stirbt, wird er zu einer Ragdoll mit genaueren Kollisionsboxen für jeden Körperteil, obwohl die Simulation dann viel aufwendiger ist. Diese Änderung bei der Kollisionsrepräsentation macht Kollisionen zwischen Buggy und Zombies deutlich komplexer – wir reden hier von mehr als nur einem Ruckler für einen Frame. Wenn der Buggy zunächst mit dem Zombie kollidiert, berührt er die vereinfachte Kollisionsbox des Zombies. Das Spiel tötet dann den Zombie, konvertiert ihn in eine Ragdoll, die vom Physiksystem simuliert wird. Jetzt, mit präziserer Kollision pro Körperteil, kann es sein, dass der nächste Körperteil mehrere Zentimeter vom Buggy entfernt ist. Das heißt, der Zombie beginnt bei der nächsten Simulation des Physiksystems aufgrund der Schwerkraft zu fallen, da er nicht mehr angeschoben wird. Obgleich es nur einen kurzen Moment dauert, bevor der Buggy den Zombie erneut erreicht, machte diese kleine Diskrepanz das Umfahren von Zombies unbefriedigend. Sie fielen oft aus dem Sichtfeld des Spielers heraus. Um das zu beheben, speicherten wir die Stoßkraft, die beim Aufprall mit dem Buggy auf die Kollisionsbox des Zombies wirkt, und wendeten nach der Kollision dieselbe Stoßkraft auf die Ragdoll an. Wir fügten auch eine geringfügige Aufwärtskraft zur Ragdoll hinzu, die diese geringfügig in die Luft schleudert. Mit diesen leichten Anpassungen falten sich Zombies zuverlässig beim Aufprall über den Buggy, was eher den Erwartungen der Spieler entspricht."
N/A3920"#commentary\cn_004_buggy_sound_engine.mp3" "[ Kelly Bailey ] Der Sound für den Buggy war eine Herausforderung, da wir wollten, dass er sich wie ein wirklich kraftvolles und schnelles Fahrzeug anhört, obwohl die Karten nicht groß genug dafür waren und der Buggy nicht wirklich aus dem ersten Gang rauskommt. Die Höchstgeschwindigkeit liegt bei etwa 56 km/h. Zu unserer Verteidigung müssen wir sagen, dass 56 km/h immer noch recht schnell ist, gerade damals im Jahr 2004. Neben der Geschwindigkeit waren die Fahreingaben recht einfach. Mit einer Tastatur als beabsichtigtes Eingabegerät war die Spielsteuerung gewissermaßen binär – entweder beschleunigt der Buggy oder nicht. Er dreht sich in eine Richtung oder nicht. Im Grunde mussten wir also eine Soundkomplexität erstellen, die in der realen Welt nicht wirklich existiert. Wir erstellten also einen Pseudomotor für den Sound des Buggys. Er verfügte über eine eigene Gangschaltung und wir kombinierten die Eingaben des Spielers mit den Daten der Physiksimulation. Wir maßen das Drehmoment jedes simulierten Rads, ob sich dieses drehte oder kollidierte, und erstellten eine Reihe von Soundschleifen, die sorgfältig ineinander übergingen, während der Pseudomotor den Gang wechselte und auf die Raddaten reagierte. Wir probierten einfach verschiedene Lösungen aus, fügten mehr Komplexität hinzu und feilten so lange daran, bis der Buggy mehr Spielspaß bot und den Spieler gewissermaßen mit dem Gefühl von Geschwindigkeit belohnte. Die meisten Spieler haben nie was dazu gesagt, andere meinten, dass der Buggy gut klingt, und für uns war das ein großer Erfolg, wenn man den Wahnsinn bedenkt, der unter der Haube schlummert."
N/A3921"#commentary\cn_005_buggy_sound_design.mp3" "[ Kelly Bailey ] Das Sounddesign für den Buggy basierte auf einigen Samples eines alten 1968er Camaro. Wir wählten dieses Auto, da es einen fantastischen V8-Motor mit riesigen Kolben hat. Und es gibt keinen wirklich vergleichbaren Klang, der diesen kräftigen, rohen Sound hat, nach dem wir gesucht hatten. Das Getriebe verursacht bei Beschleunigung auch dieses wirklich wundervolle mechanische Heulen. Und diese Kombination passte hervorragend zu dem binären System, mit dem wir es zu tun hatten. Das Getriebe des Pseudomotors war also nicht einem echten Auto nachempfunden. Stattdessen war es ein einfaches System, das den Spieler dafür belohnte, aufs Gaspedal zu drücken. Es ist also wie eine Art Dauerschleife, die immer lauter wird, konstant Spannung aufbaut und den Gang wechselt, sobald der Sound neu gestartet werden muss. Da dem Spieler auf unseren kleinen Karten schnell der Platz ausgehen würde, musste die Beschleunigung nur für kurze Zeit Spaß machen."
N/A3922"#commentary\cn_006_automating_dsp.mp3" "[ Kelly Bailey ] Alle Sounds, die der Spieler hört, müssen unsere digitale Signalverarbeitung durchlaufen, auch DSP genannt. Dabei geht es nur darum, wie Audio abgewandelt wird, damit es zur Umgebung des Spielers passt. Beispielsweise klingt derselbe Ton in einem Parkhaus anders als in einer kleinen Kammer oder draußen. In Half-Life 1 platzierten wir überall in der Welt manuell unsichtbare Knotenpunkte, um diese DSP-Einstellungen für jeden Bereich zu definieren. Für Half-Life 2 war uns aber bewusst, dass eine manuelle Platzierung einfach zu viel Zeit in Anspruch nehmen würde, schließlich sollte es ein größeres Spiel werden und wir hatten nur eine einzige Person im Team, die für den Sound verantwortlich war. Deshalb erstellten wir ein System, das die DSP-Einstellungen automatisch in Echtzeit um den Spieler herum festlegte. Dafür analysiert es den Raum um den Spieler herum, ermittelt sein Volumen und schaut sich die Materialien an, aus denen die Umgebung zusammengesetzt ist. Das System stimmt diesen Bereich dann mit einem der 25 von Hand erstellten DSP-Grundtypen ab. Wir passen dann einige Parameter an und erstellen ein vollständig detailliertes DSP-System, das die Klänge modifiziert, die der Spieler hört."
N/A3923"#commentary\cn_007_dynamic_mixing.mp3" "[ Kelly Bailey ] Während des Gameplays werden viele Sounds gleichzeitig abgespielt. Einige davon sind selbstverständlich wichtiger als andere und wir müssen die Lautstärken in Relation zueinander festlegen, um sicherzustellen, dass die wichtigen in den Vordergrund treten. In einem Film wird die Soundabmischung in der Nachbearbeitung durchgeführt. In einem Spiel aber geschieht dies in Echtzeit in Reaktion auf die Handlungen des Spielers. Wir können nicht vorhersagen, welche Sounds gleichzeitig abgespielt werden. Daher werden alle Sounds in Typen gruppiert und mit einer Priorität versehen. Während des Gameplays überwacht das Soundsystem alle aktiven Sounds und verringert die Lautstärke, wenn ein Sound mit höherer Priorität abgespielt wird. Diese Abmischung ist anpassbar. Wenn Schüsse in einer Szene lauter sein müssen, können wir diesen eine höhere Priorität zuweisen. Wenn ein bestimmter Dialog klar verständlich sein muss, können alle anderen Klänge leiser gemacht werden. Genau das machen wir auch mit Musik. Es ist ein subtiles, aber wichtiges System und es verhindert, dass die Klanglandschaft zu überladen wirkt."
N/A3924"#commentary\cn_008_soundscapes.mp3" "[ Kelly Bailey ] In Half-Life 1 wurden Umgebungsgeräusche von Hand platziert und individuell angepasst. Für Half-Life 2 wollten wir aber mehr Umgebungsgeräusche mit höherer Qualität, ohne dass wir sie alle manuell setzen müssen. Deshalb haben wir ein System entwickelt, das wir Klanglandschaftssystem nennen. Eine Klanglandschaft ist im Grunde ein kleines Programm, das steuert, welche Umgebungsgeräusche abgespielt werden, woher sie kommen und wie sie sich in einer bestimmten Umgebung verhalten, wie summende Fliegen, Windrauschen, Vogelgezwitscher, ferne Zughörner oder Kampfgeräusche. Das Klanglandschaftssystem kann diese Klänge dann randomisiert auswählen und abspielen. Es ist also essenziell, den Übergang sauber zu gestalten, während der Spieler sich in den Umgebungen bewegt. Klanglandschaften können auch selber Klanglandschaften enthalten. Dies ermöglicht uns, wiederverwendbare Soundsammlungen zu erstellen. Beispielsweise könnten ferne Kampfgeräusche aus Schüssen mit Handfeuerwaffen, fernen Explosionen oder einem vorbeifliegenden Hubschrauber bestehen. Diese Klanglandschaften werden dynamisch aus einzelnen Sounds zusammengestellt und abgespielt. Dies hilft uns dabei, den künstlichen Klang einzelner, sich wiederholender Audiospuren zu vermeiden. Insgesamt hat das Klanglandschaftssystem Großes geleistet für den Sound von Half-Life 2 und es ist für jeden Klang verantwortlich, den man hört und der nicht direkt aus dem Gameplay entsteht."
N/A3925"#commentary\cn_009_audio_over_distance.mp3" "[ Kelly Bailey ] Die riesigen Bereiche in den Küstenkarten zwangen uns, eine Audiolösung für die Änderung von Klängen über große Entfernungen zu finden. Beispielsweise kann ein Feind in diesen Karten locker mehr als 100 Meter entfernt sein. Und ihre Waffen könnten aus der Entfernung anders klingen als von Nahem. Wir entschieden uns, unsere Sounds als einzelne Stereodatei abzuspeichern, mit den nahen Klängen im linken Kanal und den fernen Klängen im rechten Kanal. Während des Abspielens wird der Klang zwischen beiden Kanälen basierend auf der Entfernung des Spielers zur Klangquelle überblendet oder die Proportion des hörbaren Klangs geändert. Es war eine einfache Lösung, die reibungslos funktionierte und uns bei Speichereinschränkungen half. Sie können das Resultat unserer Arbeit direkt in Aktion hören. Achten Sie darauf, wie sich die Schussgeräusche von Combine-Soldaten ändern, während Sie näher an sie heranfahren."
N/A3926"#commentary\cn_010_flying_vehicle_audio.mp3" "[ Kelly Bailey ] Die großen fliegenden Feinde im Spiel stellen eine einzigartige akustische Herausforderung dar. Im Kampf sind sie viel beweglicher als andere Feinde und entfernen sich oft weit vom Spieler. Außerdem sind sie sehr gefährlich, wenn sie den Spieler entdecken. Diese Faktoren veranlassten uns, eine speziell auf Okklusion ausgerichtete Audiolösung zu finden. Mit anderen Worten, wann der Spieler Feinde und wann diese den Spieler sehen können. Wir wollten, was die Geräusche betrifft, deutlich unterscheiden, wann eine Sichtlinie erreicht wird. Die Motorgeräusche eines fliegenden Fahrzeugs bestehen aus mehreren Soundschleifen, die wir gleichzeitig abspielen. Einige dieser Schleifen werden vom DSP-System auf der Grundlage des Raums verarbeitet, in dem man sich gerade befindet, während andere direkt und unverarbeitet abgespielt werden. Das DSP-System sorgt für einen stärkeren Umgebungsechoeffekt. Wenn ein Flugobjekt sich hinter einem anderen Objekt befindet und den Spieler nicht sehen kann, erhöhen wir den Prozentsatz der die DSP-Verarbeitung durchlaufenden Schleifen, und es hört sich so an, als sei das Flugobjekt etwas weiter entfernt. Wenn der Feind dann hinter einem Objekt auftaucht und den Spieler sehen kann, spielen wir einen größeren Teil des direkten Sounds ab. Im Großen und Ganzen hat man dadurch das Gefühl, dass das Geräusch entweder weit entfernt und richtungslos ist oder sich in direkter Sichtlinie befindet. Man hört also, wenn der Hubschrauber hinter einem Gebäude auftaucht. Idealerweise kann man einen deutlichen Unterschied feststellen."
N/A3927"#commentary\cn_011_bullet_audio.mp3" "[ Kelly Bailey ] Wenn wir eins mit Sicherheit sagen können, dann, dass im Spiel unzählige Kugeln am Spieler vorbeifliegen. Deshalb haben wir viel Zeit damit verbracht, die perfekte Audiolösung dafür zu finden. Leider schlagen Kugeln im Spiel praktisch sofort ein, weshalb es uns nicht möglich war, einen Sound an die Flugbahn der Patronen zu heften. Nach einigen Experimenten fanden wir die folgende Lösung: Wenn wir den Punkt auf der Flugbahn der Kugel finden, der dem Ohr des Spielers am nächsten ist, können wir die exakte Zeit und Position der Kugel berechnen, bei der sie theoretisch am Spieler vorbeifliegen würde. Wir spielen dann zwei verschiedene Sounds ab, um einen Dopplereffekt zu simulieren – einen für das Heranfliegen und einen für das Wegfliegen der Kugel. Wir verzögern den Sound beim Wegfliegen basierend auf der berechneten Zeit, zu der die Kugel vorbeifliegen würde."
N/A3928"#commentary\cn_012_staircase.mp3" "[ Aaron Seeler ] Es gibt Situationen im Spiel, die aus einfachen und sehr direkten Designzielen entstanden sind. Diese Treppe beinhaltet zwei davon. Das erste Ziel war, die Zitadelle hervorzuheben, wenn sie erwacht, um dem Spieler zu zeigen, dass er den Schwarm aufgestachelt hat. Das zweite Ziel war, unser Ragdoll-System zu demonstrieren. Auch wenn es mittlerweile Standard ist, war es 2004 eine Neuheit, zu sehen, dass Körper realistisch fallen. Und die Treppe war die perfekte Bühne dafür."
N/A3929"#commentary\cn_013_alyx_and_mossman.mp3" "[ Bill Fletcher ] In unseren frühen Plänen für die Handlung von Half-Life 2 wollten wir uns der Herausforderung stellen, nicht zu sehr in das Spieltypische abzudriften. Es sollte nicht bloß um einen eindeutig guten Spieler gehen, der eindeutig böse Feinde besiegt. Nein, wir wollten die Charaktere und ihre Beziehungen hervorheben. Wir hielten es für interessant, die Familie als zentrale dynamische Einheit von Half-Life 2 zu gestalten. Die Spannung zwischen Alyx und Mossman entsprang dieser Idee, und wir fanden das gut, weil es nachvollziehbar war – etwas, was Spieler verstehen und nachfühlen konnten."
N/A3930"#commentary\cn_014_exposition_board.mp3" "[ Danika Rogers ] Wir wollten diese dichte visuelle Exposition hier platzieren, da dieser Ort den Spielern sehr explizit dazu anhält, den Raum zu erkunden. Obwohl dieses Brett hauptsächlich dazu dient, die Welt zu erklären, bemühten wir uns, die Beziehung zwischen Eli und Breen hervorzuheben und dem zentralen Konflikt der Welt einen Kontext zu geben."
N/A3931"#commentary\cn_015_city_17_awakens.mp3" "[ David Sawyer ] Der frühe Bahnhofsabschnitt wurde so gestaltet, dass die Stadt dem Spieler gegenüber gleichgültig erscheint, als wäre Gordon nur ein weiterer anonymer Bürger, der den man unterdrücken kann. Während der Razzia und der Jagd über die Dächer identifiziert die Stadt den Spieler jedoch als Anomalie und beginnt, zu erwachen. Mit dem Spieler als Aggressor richtet die Stadt jetzt ihre volle Aufmerksamkeit auf ihn. Die Lautsprecheranlage der Sicherheitsüberwachung, die Spieler zum ersten Mal während der Razzia hören, trägt entscheidend dazu bei, dieses Gefühl zu erzeugen. Wenn Spieler genau hinhören, erhalten sie viele Informationen zur bewussten Wahrnehmung der Stadt. Auch wenn Spieler nicht darauf achten, vermitteln die Klänge dennoch genau die emotionale Botschaft, auf die wir es abgesehen hatten."
N/A3932"#commentary\cn_016_elis_lab.mp3" "[ Dhabih Eng ] Wir erstellten Elis Labor nach der Vorlage von Dr. Kleiners Labor, was uns ein besseres Verständnis für die Erstellung und das Design effektiv choreografierter Szenen gab. Das ermöglichte es uns, ein komplexeres Szenario zu erschaffen, das mehr Gelegenheiten hatte, auf den Spieler zu reagieren. Mehrere Charaktere im selben Raum, die alle ihr eigenes Ding drehen, machten die Inszenierung komplizierter. Es waren viele Iterationen und Spieltests notwendig, bis es reibungslos lief. Unsere Erfahrung hat gezeigt, dass Spieler in der Regel bei dieser Szene mitspielen möchten. Sie benötigen lediglich ausreichend subtile Hinweise darauf, wo wir sie haben wollen. Ebenso konnten wir, falls die Spieler durch irgendwas abgelenkt wurden, die Szene sanft pausieren, bis sie zurückkommen."
N/A3933"#commentary\cn_017_feel_free_to_look_around.mp3" "[ Dhabih Eng ] Das Bedürfnis von Spielern, ihre Umgebung zu erkunden, mit den narrativen Zielen der Szene in Einklang zu bringen, war stets eine Herausforderung. Wir wollten den Raum mit interessanten Dingen füllen. Jedoch würden viele Spieler diese nicht erkunden, bis sie sich sicher waren, dass sie nichts von den Charakteren verpassen. Deshalb war es wichtig, dass Eli die Spieler während der Szene anwies, sich umzuschauen – ein Signal dafür, dass es sicher ist, die Umgebung zu erkunden. Von hier aus konnten wir verschiedene individuelle Miniszenen basierend auf dem Interesse des Spielers auslösen."
N/A3934"#commentary\cn_018_interstitial_scenes.mp3" "[ Eric Kirchmer ] Während der Spieltests fanden wir oft Bereiche, in denen Spieler das Ziel aus den Augen verloren, was nicht ungewöhnlich bei einem Spiel wie Half-Life ist. Um dem entgegenzuwirken, fügten wir kleinere Zwischenszenen ein, um Spielern auf dem Weg zu helfen, ihr Ziel im Auge zu behalten. Nachdem wir den Großteil unserer größeren choreografierten Szenen wie Kleiners Labor abgeschlossen hatten, war die Zusammensetzung dieser kleineren Szenen recht einfach. Wir stellten fest, dass es in solchen Momenten besser war, Charaktere zu nutzen, als sich auf passives Storytelling oder irgendwelche Hinweise im Pause-Menü zu verlassen."
N/A3935"#commentary\cn_019_overwatch.mp3" "[ Josh Weier ] Während der Entwicklung generierten wir mit einem kostenlosen Text-to-Speech-Tool die Stimme der Sicherheitsüberwachung. Kurz vor der Veröffentlichung fiel uns aber auf, dass wir nicht die Nutzungsrechte dafür hatten. Also hielten wir ein Vorsprechen ab, um jemanden zu finden, der der gewünschten Qualität des generierten Dialogs entsprach. Es dauerte nicht lange, bis wir Ellen McClain fanden, die exakt das lieferte, wonach wir gesucht hatten. In ihren Aufnahmen spielten wir ihr die generierten Dialoge vor, damit sie sie in ihrem eigenen Stil nachstellen konnte. Anfangs war sie etwas sarkastisch, schließlich wurde von ihr erwartet, so roboterhaft zu spielen. Jahre später aber, als sie für ihre ikonische Rolle als GLaDOS in Portal zurückkehrte, fand sie einen Weg, diesen Ton kreativ in ihre Performance zu integrieren."
N/A3936"#commentary\cn_020_box_car_joe.mp3" "[ Laura Dubuk ] Diese kleine Szene wurde ursprünglich mit zwei menschlichen Charakteren erstellt. Später in der Entwicklung ersetzten wir einen davon jedoch mit einem Vortigaunt. Wir wollten zeigen, dass Vortigaunts mit Menschen koexistieren und sich ebenfalls den Combine entgegenstellen können. Wir zeigten auch, dass sie den Spieler heilen können, auch wenn wir im weiteren Spielverlauf nicht das volle Potenzial dieser Fähigkeit ausgeschöpft haben. Vortigaunts wurden zu einem nützlichen narrativen Werkzeug, um Dialoge kurzzuhalten. Ihr Schwarmbewusstsein war eine gute Rechtfertigung dafür, dass sie immer alles über die Welt und die Ziele des Spielers wussten. So mussten sie nie Fragen stellen, was sehr praktisch ist, wenn man Dialoge um einen stummen Protagonisten herum schreibt."
N/A3937"#commentary\cn_021_mossman.mp3" "[ Marc Laidlaw ] Judith Mossman basierte ursprünglich auf einem Charakter, den wir für einen bestimmten Abschnitt von Half-Life 1 geplant hatten. Dieser Abschnitt wurde jedoch aus dem Spiel entfernt und später für Uplink wiederverwendet, jedoch ohne den Charakter. Wir halten sie für den kompliziertesten Charakter in Half-Life 2. Es war schwer zu sagen, was die Spieler von ihr halten würden, auch vor Nova Prospekt, denn die Quellen, denen der Spieler vertraut, sind sich selbst nicht einig: Eli mag sie, Alyx nicht. Uns war klar, dass es ein Limit dafür gibt, wie kompliziert wir Beziehungen gestalten können, aber wir hatten das Gefühl, dass Spieler die Dynamik zwischen Stiefmutter und Tochter verstehen würden. Egal, ob man Mossman zustimmt oder nicht, sie tut etwas Heldenhaftes. Sie riskiert ihr Leben als Doppelagentin, um die Informationen zu bekommen, die sie benötigt, um Eli und Alyx zu schützen. Nur Gordon hatte sie dabei nicht bedacht."
N/A3938"#commentary\cn_022_hands_free.mp3" "[ Matt Wright ] Zu der Zeit, als Half-Life 2 rauskam, gaben die meisten Ego-Shooter Spielern direkt zu Beginn eine Schuss- oder Nahkampfwaffe. Wir entschieden uns bewusst dagegen. Ohne Waffe war es viel einfacher, den Spielern auf neuartige Weise beizubringen, mit der Welt zu interagieren und sie in unsere Handlung einzuführen. Wir wollten, dass der Spieler sich von einem Gejagten in einen Aggressor verwandelt, und das haben wir erreicht, indem wir ihn im richtigen Moment bewaffnen. Wenn der Spieler eine Waffe bekommt, ist das das Zeichen, dass er nicht mehr Weglaufen muss. Es heißt, manchmal ist der beste Weg zu gewinnen, gar nicht zu kämpfen. Aber das stimmt nicht. Der beste Weg zu gewinnen, ist, sich ballernd auf etwas zu stürzen."
N/A3939"#commentary\cn_023_metrocop_scene.mp3" "[ Mike Dussault ] Dies ist eine weitere Szene, die so gestaltet wurde, dass klar wird, die Metrocops sind die Bösen. Nur dass dieses Mal der Spieler eine Waffe hat und endlich etwas dagegen tun kann. Dieses \"Etwas\" kommt aus der Mündung einer Schusswaffe. Wir wussten, dass wir Spielern das Gefühl geben mussten, dass sie gerecht handeln, und dieser Moment war perfekt. Die Metrocops sind, anders als die Combine im Spiel, nach wie vor Menschen. Deshalb mussten wir uns besonders Mühe geben, um sicherzustellen, dass die Handlungen der Spieler sich wie Gerechtigkeit anfühlen und nicht nur wie Rache."
N/A3940"#commentary\cn_024_moving_the_gravity_gun.mp3" "[ Ted Backman ] Als wir den ersten Prototyp des Gravitrons entwarfen, planten wir, dem Spieler diesen in der Mitte des Spiels auszuhändigen. Jedoch erkannten wir während der Testphase die Stärke des Designs und entschieden, dass das Gravitron und vor allem die Möglichkeit, Sägeblätter in Zombiegesichter zu schleudern, viel früher im Spiel erscheinen sollten. Das bedeutete, dass Elis Labor auch viel früher erreichbar sein musste. Das war eine erhebliche Änderung, die aber wichtig für den Erfolg von Half-Life 2 war. Es war eine gute Erinnerung daran, dass die Story einer Geschichte und das Gameplay miteinander verknüpft sind. Keine Komponente sollte die andere überschatten, sie müssen gleichberechtigt zusammenwirken."
N/A3941"#commentary\cn_025_buggy_birds.mp3" "[ Adrian Finol ] Bei einem denkwürdigen Coast-Spieltest kehrte ein Spieler nach der Erkundung eines Hauses zum Fahrzeug zurück und sah einen Vogel vorbeifliegen. Er jagte den Vogel davon und sagte, er solle sich von seinem Buggy fernhalten. Er beschwerte sich dann, dass Vögel in der echten Welt oft sein Auto verdrecken. In unserer Besprechung nach dem Spieltest erkannten wir, dass wir zum ersten Mal Objekte hatten, die vom Spieler getrennt existierten und die Spieler als wichtig betrachteten. Wir sahen dies als Anlass für Verbesserungen und kreierten deshalb ein System, das die größte Angst dieses Spieltesters Wirklichkeit werden ließ. Wenn der Spieler seinen Buggy eine Weile aus den Augen lässt, erscheint an einer zufälligen Stelle am Fahrzeug eine Möwe. Und mit der Zeit erzeugt die Möwe auf dem Fahrzeug unter sich Grafiken von Vogelmist und macht so lange damit weiter, bis der Spieler zurückkehrt. Dann fliegt sie weg. Natürlich wollten Testspieler ihren Buggy wieder säubern, deshalb fügten wir die Möglichkeit hinzu, den Buggy zu waschen, indem man durch seichtes Wasser fährt. Es war spät genug in der Entwicklung, dass wir bereits die Technologie dafür hatten, deshalb war es einfach zu implementieren. Dies war so ein Fall, bei dem wir wussten, die allermeisten Spieler werden das nie bemerken. Aber wenn wir solche winzigen Details ohne großen Aufwand und in ausreichender Zahl implementieren können, wird den meisten Spielern mindestens ein Beispiel irgendwann auffallen."
N/A3942"#commentary\cn_026_bridge_gunship.mp3" "[ Adrian Finol ] Wir waren besonders glücklich mit dem Kampf gegen den Schrauber, obwohl er aufgrund der Levelgeometrie etwas knifflig war. Da sich der Spieler unter der Brücke befindet, kann sich der Schrauber vollständig um den Spieler herum bewegen und sich zu jeder Zeit in allen drei Dimensionen oberhalb oder unterhalb positionieren. Die Brückenträger boten dabei ausreichend Deckung, wodurch der Beschuss für ein unterhaltsames und dynamisches audiovisuelles Spektakel sorgte."
N/A3943"#commentary\cn_027_floor_is_lava.mp3" "[ Adrian Finol ] Wenn man das Gameplay um allgemein bekannte Konzepte wie \"Der Boden ist Lava\" aufbaut, wird es leichter verständlich. Uns hat gefallen, wie unser Physiksystem einen hohen Grad an kreativer Freiheit bei der Problemlösung ermöglicht. Manche Spieler bauten Brücken aus allen möglichen Gegenständen, während andere einfach nur ihre zwei Lieblingsmetallplatten verwendeten. Einige folgten vorsichtig dem Pfad über die Felsen und sorgten sich darum, nicht runterzufallen. Andere machten sich direkt auf den Weg zum Ausgang über Objekte, die nur gerade so aus dem Sand ragten. Einige Spieler betrachteten es als Fehlschlag, wenn sie Ameisenlöwen anlockten, während andere Spaß daran hatten, sich auf die Felsen zurückzuziehen, um sich zu erholen. Uns hat auch gefallen, dass es eine Art Navigationsrätsel war, auf Wunsch des Spielers aber auch zu einer Arena werden konnte. Manche sprangen einfach direkt in den Sand und kämpften sich den Weg zum Ziel frei."
N/A3944"#commentary\cn_028_opportunistic_moments.mp3" "[ Ariel Diaz ] Einige denkwürdige Momente entstehen, wenn verschiedene Spielsysteme miteinander interagieren, manchmal muss man aber auch realisieren, dass diese Momente nur selten auftreten. In solchen Fällen wünschen wir uns immer, dass mehr Spieler sie erleben können. Es ist immer ein Balanceakt: Je mehr Spieler etwas unserer Erwartung nach erleben werden, desto mehr Mühe können wir uns damit geben. Wenn es sich aber zu künstlich anfühlt, kann der Moment erzwungen rüberkommen an, und dann reagieren die Spieler negativ darauf. Die filmreife Zerstörung des Schraubers ist ein solches Beispiel, bei dem wir ein wenig mehr Mühe reingesteckt haben, um einen denkwürdigen Moment zu schaffen, ohne es zu offensichtlich zu machen. Das Design dieses Bereichs und des Flugpfades des Schraubers machen es wahrscheinlich, dass Spieler und Schrauber sich genau an der richtigen Stelle befinden, wenn er zerstört wird, sodass der Schrauber abstürzt und die Autos trifft. Wenn nicht, wird er auf die übliche Art zerstört. Das ist zwar \"typisch Videospiel\", aber es schien die Testspieler nicht zu stören."
N/A3945"#commentary\cn_029_assault_on_nova_prospekt.mp3" "[ Ariel Diaz ] Mit einer unendlichen Armee von Ameisenlöwen, die entlang der Küste eine befestigte Combine-Basis angreifen, war es schwierig, kein von der Landung in der Normandie inspiriertes Level zu erstellen. Unser ursprünglicher Prototyp hatte entlang des Weges hoch zu Nova Prospekt Schützengräben und tödliches Maschinengewehrfeuer zwang Spieler und ihre Ameisenlöwen dazu, dort Schutz zu suchen. Es war aufregend, Maschinengewehrsalven und Ameisenlöwen zu haben, die über die Gräben springen. Unglücklicherweise haben wir es aber nicht geschafft, dass dieses Level im Performance-Budget bleibt. Letztlich entschieden wir uns deshalb, dieses Konzept zu verwerfen und ein vollständig anderes Layout zu wählen. Jedoch behielten wir die Gewehre, da die von ihnen ausgehende Gefahr die Spieler dazu anhielt, sich auf ihre Ameisenlöwen zu verlassen."
N/A3946"#commentary\cn_030_buggy_physics.mp3" "[ Charlie Brown ] Für die Physik des Buggys mussten wir viel herumprobieren. Wir wollten, dass er sich schnell anfühlt, obwohl seine Höchstgeschwindigkeit bei nur knapp 56 km/h liegt. Deshalb mussten wir etwas schummeln, damit das funktioniert. Wir haben zusätzliche vertikale Kraft zum Turbosprung hinzugefügt sowie ein leichtes Zurückzucken, wenn man die Handbremse zum Driften anzieht. Ohne machte der Buggy einfach keinen Spaß, wegen der niedrigen Geschwindigkeit. Des Weiteren war die Welt voll mit unvorhersehbarem Physik-Chaos – Spieler würden zwangsläufig alle möglichen Unfälle mit dem Buggy bauen, weshalb wir sicherstellen mussten, dass aus jeder Situation auch wieder rauskommen. Dafür waren viele Experimente und Spieltests nötig. Letztlich entschieden wir uns für eine ziemlich alberne, unrealistische Simulation, durch die der Buggy nachsichtiger wurde und sich nicht leicht überschlug. Der Schwerpunkt des Buggys ist sehr niedrig, und auch wenn es aussieht, als würden die Räder sich viel drehen, tun sie das nicht. Es war unser erster Versuch, ein physikalisch simuliertes Fahrzeug zu kreieren, und wir haben viel dabei gelernt. Das hat uns sehr beim Muscle-Car in Episode 2 geholfen."
N/A3947"#commentary\cn_031_the_bridge.mp3" "[ Charlie Brown ] Die Inspiration für diesen Brückenabschnitt stammt von der Brücke des Deception Pass im Bundesstaat Washington. Wir hatten den Abschnitt ursprünglich als reines Navigationsrätsel erbaut und ihm schrittweise mehr Gameplay hinzugefügt. Es wurde auch zum primären Testfall für die Kantenreibung unserer Spieler. Unser Bewegungssystem erhöht auf subtile Weise die Reibung beim Verlangsamen, wenn sich Spieler dem Rand einer Oberfläche nähern. Die Spieler haben das nie bemerkt — wahrscheinlich, weil es ohnehin ihre Absicht ist, an einem Abgrund anzuhalten, um nach unten zu schauen. Menschen bewegen sich an einem Abhang generell langsamer und vorsichtiger, und genau das ist entscheidend für diesen Teil des Spiels. Wir wissen das, weil wir dieses System an einem bestimmten Punkt der Entwicklung versehentlich kaputtgemacht haben und plötzlich all unsere Testspieler ständig in den Tod gestürzt sind."
N/A3948"#commentary\cn_032_coast.mp3" "[ Chris Green ] Wir wollten für den Buggy viel offenen Platz im Spiel, aber wir brauchten dennoch einen Weg, die Bewegungen der Spieler einzuschränken. Ein Küstenstreifen funktioniert als natürliche Grenze entlang einer Seite der Karte, ohne dass es sich beengt anfühlt. Das half auch dabei, die Auswirkungen des Ressourcenabbaus durch die Combine visuell deutlich zu machen. Unsere Tester versuchten jedoch immer, ins offene Meer zu schwimmen, also fügten wir Blutegel hinzu, um sie davon abzuhalten. Die Blutegel durften aber kein echter Feind sein, den Spieler umgehen oder bekämpfen können. Sie haben also etwas Magisches an sich. Die Spieler haben dann auch schnell verstanden, dass sie die Grenzen des Spiels überschreiten, also mussten wir da nicht viel mehr Entwicklungszeit investieren."
N/A3949"#commentary\cn_033_grenade_house.mp3" "[ Dave Riller ] Bei einem Half-Life-Spiel geht es oft darum, Spielern an jeder Ecke neuartige Kampferlebnisse zu bieten, auch wenn sie sich nur wenig von dem vorherigen Kampf unterscheiden. Nicht immer muss das ganze Können des Spielers herausgefordert werden, manchmal sollen sie einfach nur Spaß machen. Das Granatenhaus ist ein anschauliches Beispiel. Um für etwas Abwechslung zu sorgen, lassen wir die Spieler Granaten auf Gegner werfen, die über ihnen statt unter ihnen sind. Die unbegrenzte Granatenkiste ist vielleicht eine etwas faule Methode, die Spieler dazu zu ermutigen, sich auf das Szenario einzulassen. Weil sie aber unzerstörbar ist, können sie auch dann noch ins obere Stockwerk klettern, wenn alles andere in die Luft gejagt wurde."
N/A3950"#commentary\cn_034_buggy_training_course.mp3" "[ David Sawyer ] In diesem Trainingsabschnitt können Spieler mit ihrem Buggy herumspielen. Als Half-Life 2 veröffentlicht wurde, war dieses Niveau der physikalischen Simulation in einem Fahrzeug noch neu, also wollten wir den Spielern reichlich Gelegenheit geben, damit zu experimentieren. Zusätzlich hatten Spieler gerade die engen Grenzen von Ravenholm verlassen, und wir hielten das schnelle Durchqueren eines weitläufigen Gebiets in einem sicheren Fahrzeug für einen guten Kontrast dazu. Wir sorgten dafür, dass man nur mit einem Turbosprung aus dem Gebiet rauskommt. Das war gleichzeitig ein Test, um sicherzustellen, dass die Spieler sich mit dem Buggy ausreichend vertraut gemacht hatten und damit sie ihn nicht zurücklassen."
N/A3951"#commentary\cn_035_ambush.mp3" "[ David Sawyer ] Eine Herausforderung bei einem Ego-Shooter wie Half-Life ist, dass Spieler ständig in immer neue Gebiete vorstoßen. Sie müssen also in unbekannten Umgebungen kämpfen, in denen sie nicht wissen, wie sie an den Kampf herangehen sollen. Wir haben viele verschiedene Methoden, um dem Spieler bei diesem Problem zu helfen, und dieser Hinterhalt ist ein Beispiel dafür. Bei der Ankunft kämpft man zwischen den Häusern gegen eine Gruppe von Combine. Während des Kampfes und der anschließenden Erkundung hat man dann die Möglichkeit, das Layout der Arena kennenzulernen. Und wenn man anschließend diesen Dachboden erkundet, spawnen wir eine zweite Welle von Combine. Jetzt hat der Spieler den Vorteil, dass er das Layout kennt, sodass er bei der Verteidigung gegen die Angreifer taktischere Entscheidungen treffen kann."
N/A3952"#commentary\cn_036_bugbait_training.mp3" "[ David Sawyer ] Das Training für die Verwendung des Käfer-Köders wirkt deshalb so unbeholfen, weil uns die Zeit davonlief. Aber Spieler mussten verstehen, wie man ihn benutzt, damit das Design von Nova Prospekt funktioniert. Generell versuchen wir, einem Training genügend Würze und Kontext zu verleihen, damit es sich nicht wie ein Training anfühlt, sondern wie eine neue, spannende Entdeckung. Hier ist uns das nicht ganz gelungen. Es wirkt vielleicht offensichtlich, aber Spieler haben Köder nicht intuitiv verstanden. Man befindet sich zu diesem Zeitpunkt schon tief im Spiel und Spieler haben bereits viel Erfahrung im Umgang mit Gegnern. Bevor wir also das Training eingebaut hatten, betraten die ersten Spieletester, die Käfer-Köder gesammelt hatten, das nächste Level und schossen instinktiv auf den ersten Ameisenlöwen, weil das bis dahin immer die Lösung war. Half-Life läuft nach dem Motto \"Erst schießen, dann Fragen stellen\". Als Spieler Nova Prospekt erreichten, dachten sie nicht daran, Combine-Soldaten mit Käfer-Ködern zu bewerfen, sondern verließen sich auf ihre üblichen Waffen. Wir brauchten dieses Training also nicht nur, um zu zeigen, wie Köder funktionieren, sondern auch, um zu demonstrieren, dass sich Ameisenlöwen in der Nähe des Spielers aufhalten können, ohne anzugreifen."
N/A3953"#commentary\cn_037_vortigaunt_extraction.mp3" "[ Dhabih Eng ] Diese Arena war aus mehreren Gründen ein kniffliges Designproblem. Erstens ist die Wache ein reiner Nahkampfgegner, daher konnten wir nicht zulassen, dass der Spieler Orte erreicht, an denen die Wache ihm nicht folgen kann. Wir haben mit einigen Fernkampfangriffen experimentiert, aber die Ergebnisse gefielen uns nicht – sein Schleim-Spuckangriff zum Beispiel sah am Ende lächerlich aus. Der einzige Fernkampfangriff, der es geschafft hat, ist seine Fähigkeit, physische Objekte auf den Spieler zu schleudern. Aber dazu müssen sich auch Objekte in Reichweite befinden, was nicht immer gewährleistet ist. Die zweite Herausforderung bestand darin, sicherzustellen, dass der Vortigaunt die Leiche der Wache erreichen kann, egal wo sie stirbt. Dies war unerlässlich, da das Spiel nicht fortgesetzt werden kann, wenn der Vortigaunt den Käfer-Köder nicht extrahiert."
N/A3954"#commentary\cn_038_dropship_deployment.mp3" "[ Doug Wood ] Soldaten mit Landungsschiffen abzusetzen war knifflig, da NPCs dafür in einem festen Objekt spawnen mussten. Um sie ins Freie zu bringen, wo sie normal navigieren können, wurde eine Animation abgespielt, in der sie aus dem Container springen, sobald sie spawnen. Als das funktionierte, stießen wir auf ein weiteres Problem – kluge Spieler warteten einfach außerhalb des Containers und erschossen die Soldaten während ihrer Ausstiegsanimation. Um dem entgegenzuwirken, fügten wir dem Container einen Geschützturm hinzu. Das war keine perfekte Lösung, Spieler konnten immer noch indirekte Waffen wie Granaten oder Ähnliches gegen die aussteigenden Soldaten einsetzen, aber das fühlte sich wieder realistisch an und war eine logische, strategische Gegenmaßnahme, auf die man in so einer Situation kommen kann."
N/A3955"#commentary\cn_039_laser_guided_rpg.mp3" "[ Eric Smith ] Die Lasersteuerung der RPG bereitete uns große Kopfschmerzen, weil sie den Spielern schwer zu erklären war. Viele Testspieler feuerten die RPG ab und gingen sofort in Deckung, wodurch sie die Flugbahn der Rakete nicht sehen konnten. Schlimmer noch, sie bemerkten nicht, wenn die Rakete sich umdrehte und auf sie zuflog. Wir versuchten es mit verschiedenen HUD-Elementen und Laserpunkten, stellten jedoch fest, dass die meisten Spieler diese übersahen und sich stattdessen auf den Gegner konzentrierten. Wir nahmen so viele kleine Verbesserungen vor wie möglich: Wir haben die Funktion in Odessas Rede eingebaut und versucht, audiovisuell hervorzuheben, wie der Schrauber direkt RPG-Schüsse abwehrt. Obwohl diese Änderungen einigen Spielern halfen, erreichten wir nie einen Punkt, an dem wir zuversichtlich waren, dass nahezu jeder die Funktion verstehen würde. Wir dachten darüber nach, sie ganz zu streichen, aber das hätte Kämpfe gegen Schrauber viel weniger interessant gemacht. Die Lasersteuerung zwang Spieler, den Schrauber während des Flugs der Rakete im Blick zu behalten, aber das bedeutete auch, dass der Schrauber den Spieler sehen konnte, was mehr Spannung erzeugte."
N/A3956"#commentary\cn_040_performance_constraints.mp3" "[ Eric Smith ] Für die letzte Küsten-Arena hatten wir uns ein großes Finale vorgestellt, in dem der Spieler und eine Gruppe von Bürgern im Kampf gegen Wellen von Combine-Soldaten antreten. Der Höhepunkt des Kampfes sollte eine Hubschrauberschlacht sein, doch leider führte der Rechenaufwand für Soldaten und Verbündete dazu, dass das Gefecht immer weiter reduziert werden musste, um unser Performance-Budget einzuhalten. Als dann nur noch ein Trupp von Soldaten gleichzeitig anwesend sein konnte, war die Entwicklung schon so weit vorangeschritten, dass es zu spät war, die Arena noch mal anzupassen, um mehr Gegner unterzukriegen. Wir mussten den Kampfablauf neu designen, um die Anzahl der Soldaten auf ein Minimum zu beschränken."
N/A3957"#commentary\cn_041_lighthouse_gunship.mp3" "[ Ido Magal ] Es hat viel Arbeit gekostet, das Hubschrauberszenario so umzusetzen, wie wir es uns vorgestellt hatten. Wir wollten, dass es sich wie in einem Film abspielt. In einem Film würde der Schrauber die Bewegungen des Protagonisten voraussehen und durch die Fenster feuern, während er den Leuchtturm erklimmt. Um dies im Spiel zu simulieren, platzierten wir Bewegungsmelder bei den Treppen, die dem Hubschrauber sagen, dass er seine Flugroute anpassen muss, wenn sich der Spieler nach oben bewegt. Die Auslöser aktivieren auch Zielscheiben in den Fenstern, die dem Spieler am nächsten sind. Dabei handelt es sich um unsichtbare Spielobjekte, die die gegnerische KI sofort als Feinde wahrnimmt und den Hubschrauber veranlasst, auf die Fenster zu feuern. Diese Mischung aus KI und Scripting bildet den Kern der Kämpfe in Half-Life. Die KI steuert das allgemeine, adaptive Verhalten der NPCs, während das Scripting die individuellen Anforderungen jedes Szenarios berücksichtigt."
N/A3958"#commentary\cn_042_crane.mp3" "[ Jakob Jungels ] Der Kran erforderte viel Feinabstimmung. Ein Objekt, das so viel physikalische Kraft erzeugen musste, war angesichts der Einschränkungen unserer Physik mit starren Körpern und Zerstörung immer riskant. Beispielsweise hätte der Magnet nie die Erwartungen der Spieler an ein Objekt mit so viel Masse vollständig erfüllt. Aber da der Kran stationär war, konnten wir alles in seiner Reichweite sorgfältig auswählen und nach Bedarf justieren. Glücklicherweise schienen die meisten Spieler seine raueren Seiten nicht zu bemerken, wahrscheinlich weil sie es einfach nicht gewohnt waren, etwas derart Großes mit einer annähernd realistischen Physik zu steuern."
N/A3959"#commentary\cn_043_flashlight_power.mp3" "[ Jeff Lane ] Die Entscheidung, dass sich in Half-Life 2 das Sprinten und die Taschenlampe die Energie des HEV-Schutzanzugs teilen, war umstritten. Da nur ein kurzer Geschwindigkeitsschub ausgelöst werden sollte, wurde anfangs die Energiequelle des Anzugs nur für Sprints verwendet. Die Taschenlampe hingegen konnte unbegrenzt benutzt werden. Beim Testen des Spiels gab es aber ein Problem: Spieler verließen oft dunkle Bereiche, ohne zu bemerken, dass ihre Taschenlampe noch an war. In hell erleuchteten, offenen Bereichen wie der Küste reichte unser Performance-Budget nicht aus, um die Taschenlampe dauerhaft eingeschaltet zu lassen. Daher mussten wir sie ohne Wissen des Spielers ausschalten. Die Energieeinschränkung schien uns dabei die einfachste Lösung. Sie hatte auch den Vorteil, dass sie dunkle Bereiche spannender macht. Die Herausforderung lautete also: Welche Ressource sollte sie benutzen? Der Schutzanzug besaß bereits Energie, und wir wollten das UI nicht mit einer neuen Ressource nur für die Taschenlampe überladen. Wir hatten die Idee, dass auch andere Fähigkeiten die Energie des Anzugs nutzen könnten, und fanden die daraus entstehenden Kompromisse sehr interessant. Dies ist ein gutes Beispiel dafür, dass es beim Spieldesign oft darum geht, zwischen unvollkommenen Lösungen zu wählen. Wir waren nicht begeistert von der Idee, dass Sprinten und Taschenlampe dieselbe Ressource nutzen, aber wir wollten auch nicht das UI mit Ressourcen zumüllen. In Episode 2 hatten wir nicht vor, noch etwas hinzuzufügen, das Anzugenergie nutzt, also entschieden wir uns letztlich, der Taschenlampe eine eigene Ressource zu geben."
N/A3960"#commentary\cn_044_open_world_loot.mp3" "[ Jeff Lane ] Die offene Landschaft der Küste brachte ein neues Problem bezüglich der Verteilung von Belohnungen mit sich. In einem Half-Life-Spiel belohnen wir Spieler normalerweise für die Erkundung von Orten. Wenn sie den Weg vorwärts sehen, aber abseits des Pfades etwas Interessantes bemerken, lohnt es sich, dies zu untersuchen. Als wir anfingen, unsere Küstenkarten zu testen, versteckten wir die Belohnungen in den Ecken der Außenareale. Dies führte jedoch zu einem weniger guten Spielererlebnis mit dem Buggy. In den weiten, offenen Flächen gibt es überall kleine Bereiche, an denen vielleicht etwas von Interesse versteckt sein könnte, und die Spieler blieben ständig stehen und stiegen aus dem Buggy, um nachzusehen. Es wurde mühsam und das Level machte nicht mehr so viel Spaß. Also entfernten wir die verstreuten Belohnungen. Nun hatten wir jedoch ein neues Problem: Wie zeigen wir Spielern, wann es sich lohnt, aus dem Buggy auszusteigen? Nach einigem Nachdenken stellten wir eine Regel auf: Jeder von Menschen errichtete Bereich würde immer mit Spielinhalten und einer Belohnung für die Erkundung einhergehen, während Bereiche in der Natur leer sein würden. Wir konnten es Spielern nicht direkt so sagen, aber es passte gut zu ihren natürlichen Annahmen, und dieses Gefühl haben wir mit solchen Bereichen konsequent verstärkt."
N/A3961"#commentary\cn_045_gas_station.mp3" "[ Jeff Lane ] Wir hatten große Pläne für diese Begegnung. Wir überlegten, eine Tankstelle zu bauen, an der der Spieler kämpfen musste und wahrscheinlich die Benzintanks und alles andere in Brand gesetzt hätte. Vor unserem inneren Auge fuhr der Spieler mit Vollgas von einem riesigen Feuer davon. 2003 waren jedoch unser Budget und unsere Performance stark eingeschränkt, und die Tankstelle musste dementsprechend schrumpfen und vereinfacht werden, um in die großen Level der Küste zu passen. Unsere Pläne für ein dynamisches Feuersystem kamen daher nicht zustande, und die Tankstelle zu errichten, ergab keinen Sinn mehr. Man kann eben nicht unendlich viel Arbeit in eine einzelne Begegnung stecken. Am Ende sind von unserer ursprünglichen Vision nur die explosiven Benzintanks geblieben."
N/A3962"#commentary\cn_046_buggy_introduction.mp3" "[ John Cook ] Wir wollten etwas Interessanteres für die Einführung des Buggys, als den Spieler einfach einsteigen und wegfahren zu lassen. Der Kran hat dabei geholfen. Es war entscheidend für Spieler, zu lernen, wie sie den Buggy wieder aufrichten können, wenn er umgekippt war. Diese Sequenz zwang sie in diese Situation. Training unter Druck ist immer schwierig, aber wir wollten den Ameisenlöwenschwarm als Grund hervorheben, warum Spieler im Buggy bleiben sollten. Also hielten wir die Bedrohung durch die Ameisenlöwen aufrecht und stellten ein paar Bürger mit montierten Gewehren zur Unterstützung zur Verfügung. Als kleinen Bonus bekommen Spieler dabei das Gefühl, vom Kran angehoben zu werden — kurz bevor sie selber einen bedienen können."
N/A3963"#commentary\cn_047_crossbow.mp3" "[ John Cook ] Dies ist die erste Gelegenheit für den Spieler, an die Armbrust im Spiel zu gelangen. Rückblickend ist es überraschend, dass wir das Aufsammeln optional gemacht haben. Es kann nämlich sein, dass der Spieler einfach daran vorbeifährt. Um dem entgegenzuwirken, haben wir die Straßensperre und den Aussichtspunkt so eingerichtet, dass die Spieler ermutigt werden, aus dem Buggy auszusteigen und die Armbrust und die Kiste zu entdecken. Beim Testen hat sich gezeigt, dass fast jeder Spieler anhielt und die Waffe einsammelte. Aber dies ist ein Fall, in dem der Unterschied zwischen einem Test und tatsächlichem Spielen eine Rolle spielt. Ein Testspieler, der seit dem Anfang der Küste spielt, ist möglicherweise nicht so müde vom Erkunden wie jemand, der seit dem Anfang des Spiels dabei ist. Also platzierten wir in einem späteren Level eine weitere Armbrust direkt auf dem Weg des Spielers in Nova Prospekt."
N/A3964"#commentary\cn_048_rollermines.mp3" "[ Josh Weier ] Rollminen wurden entwickelt, damit es Feinde gibt, die Spieler beim Fahren des Buggys gefährlich werden können. Da Spieler im Buggy im Grunde eine vollständig physikalisch simulierte Entität sind, hielten wir es für interessant, auch einen physikalisch simulierten Feind zu haben. Der Schnitter hatte uns bereits gezeigt, wie dieser Ansatz zu vielen interessanten Interaktionen führen kann. Also bauten wir die Rollmine, deren Bewegung ausschließlich dadurch angetrieben wird, dass sie selbst Drehkraft erzeugt. Wir arbeiteten so lange an ihrem Verhalten, bis es Spaß machte, sie mit dem Buggy zu überfahren. Rollminen sind für den Buggy nicht sonderlich gefährlich, aber in Massen können sie zu einem Problem werden, besonders in der Nähe einer Klippe. Wir sorgten auch dafür, dass sie gut funktionieren, wenn der Spieler zu Fuß unterwegs ist, sodass Leveldesigner ein paar zusätzliche Begegnungen aus ihnen herausholen konnten."
N/A3965"#commentary\cn_049_sandtrap_thumper.mp3" "[ Laura Dubuk ] Die explosiven Fässer sind dazu da, Spielern beim Kampf gegen Ameisenlöwen zu helfen, ohne den Schutzbereich der Rammen zu verlassen. Wir verwenden sie außerdem als Hinweis auf eine bevorstehende Begegnung mit einer Löwenwache, bei der Spieler oft auf ähnliche Taktiken zurückgreifen. Optionale Spieleraktionen, wie Sprengstoff mit dem Gravitron zu detonieren, vergisst man leicht, wenn man sie nicht regelmäßig anwendet. Bei dem breiten Spektrum an Angriffsoptionen gibt es keine Garantie, dass die Spieler diese Optionen in letzter Zeit auch tatsächlich genutzt haben. Das hier ist unser subtiler Hinweis, sie wieder in sein Repertoire aufzunehmen, bevor man gegen die Wache antritt."
N/A3966"#commentary\cn_050_coast_kickoff.mp3" "[ Marc Laidlaw ] Diese Zwischenszene entstand erst spät in der Entwicklung, um Ravenholm mit der Küste zu verbinden. Fällt Ihnen ein Trend auf? Viele Verbindungselemente in unseren Spielen kommen erst spät zustande. In diesem Fall hieß das, Abstriche zu machen, wo immer es ging. Wir hatten nicht einmal die Zeit, Alyx auf dem Monitor zu animieren. Es ist immer eine Herausforderung, solche Szenen interessant zu gestalten, und bei dieser gelang es uns einfach nicht. Aber dieser Fall ist ein gutes Beispiel dafür, was passiert, wenn NPCs wie Wegweiser behandelt werden, ohne ihnen oder der Szene Charakter zu verleihen. Das Ergebnis ist ein Moment, den man als Spieler sofort wieder vergisst und in dem die Schwächen des Spiels zum Vorschein kommen. Aber das liegt in der Natur der Entwicklung — man hat nur begrenzt Zeit und muss diese sinnvoll einsetzen. Kleiners und Elis Labor waren viel wichtiger, also haben wir uns darauf konzentriert."
N/A3967"#commentary\cn_051_odessa_cubbage.mp3" "[ Marc Laidlaw ] Odessa Cubbage ist ein Beispiel für einen kurz auftretenden Charakter, der gut funktioniert hat. Er ist ein unterhaltsamer Typ, mit unterhaltsamen Details, der in seiner eigenen kleinen Blase lebt. Da er sein Szenario nicht verlässt, konnten wir mit ihm übertreiben, damit er hervorsticht. Sein Modell stammte aus einem ausgeschnittenen und wiederverwendeten Abschnitt des Spiels, und wir benannten ihn nach dem Titel einer Spam-E-Mail, die wir erhalten hatten. Das Modell war ursprünglich ein norwegischer Fischer und passte nicht ganz zu einem Engländer, also verpassten wir ihm einen Schnauzer. So wurde Odessas Charakter geboren. Letztlich ist er ein Scharlatan, an dem alles falsch ist — sein Akzent, sein Schnurrbart, alles. Er würde sich niemals selbst in Gefahr bringen, was ihn perfekt macht, um Gordon die RPG in die Hand zu geben und zu erklären, wie man sie benutzt."
N/A3968"#commentary\cn_052_28_transitions_later.mp3" "[ Marc Laidlaw ] Nachdem wir für einige Level dunkle Tunneln als Übergange benutzt hatten, hatten wir die Idee, die Erwartungen unserer Spieler zu untergraben, indem wir noch einen Tunnel bauen, der diesmal aber kein Übergang ist. Wie jeder andere auch haben wir 2002 den Film 28 Days Later gesehen, waren total begeistert und wollten sofort eine eskalierende Zombie-Begegnung in einem unserer dunklen Tunnel inszenieren. Das ging dann auch schnell und wir waren mit dem Ergebnis zufrieden. Jahre später trafen wir Alex Garland, den Drehbuchautor des Films. Er hatte Half-Life 2 gespielt und es hatte ihm sehr gefallen, also haben wir ihm erzählt, dass sein Film diesen Abschnitt inspiriert hatte."
N/A3969"#commentary\cn_053_finest_mind_of_his_generation.mp3" "[ Marc Laidlaw ] Hier ist eine weitere kleine Zwischenszene, die am Ende gut funktioniert hat. Die einzige Voraussetzung für diesen Moment war, dem Spieler klarzumachen, sich vom Sand fernzuhalten. Bei früheren Szenen haben wir uns immer darauf konzentriert, sie einfach funktionsfähig zu machen, aber als wir zu dieser Szene kamen, fühlten wir uns wohler und fingen an, den Prozess zu genießen, zusätzliche Gedanken in diese Begegnungen zu implementieren. Dabei haben wir die Charaktere dazu gebracht, nicht nur als Wegweiser zu dienen, sondern etwas Interessanteres und Unterhaltsameres zu schaffen. Nach der Veröffentlichung gewann Lazlo eine riesige Fangemeinde und erinnerte uns daran, wie schwer es ist, vorherzusagen, was Spielern ans Herz wächst."
N/A3970"#commentary\cn_054_bridge_playtesting.mp3" "[ Matt Boone ] Der Abschnitt mit der Brücke war immer ein Höhepunkt bei unseren Spieltests. Tester haben immer gut darauf reagiert. Ihre Anspannung war in ihren Bewegungen sichtbar, während sie sich langsam über die Träger bewegten. Mit der Zeit haben wir mehr Herausforderungen in die Überquerung eingebaut, und die Spieltests wurden immer unterhaltsamer anzusehen. Vom Zug, der über die Brücke rumpelte und Spieler schüttelte, bis zu der überraschenden Kopfkrabbe in der Hütte, die auf halbem Weg wie ein sicherer Zufluchtsort aussah. Wir hatten zwar ein etwas schlechtes Gewissen, weil wir den sichtbaren Stress der Testspieler genossen, aber wir waren keine Monster: Nachdem die Spieler es über die Brücke geschafft hatten, atmeten sie erleichtert auf, deaktivierten den Combine-Schild und merkten dann, dass sie über die Unterseite wieder zurückmussten. Da wir befürchteten, dass sie sich auf der zweiten Überquerung langweilen könnten, beschlossen wir, einen Hubschrauber hinzuzufügen, um ihnen Gesellschaft zu leisten."
N/A3971"#commentary\cn_055_thumper_final_stage.mp3" "[ Matt Boone ] Uns gefiel, wie die Rammen am Ende gegen den Spieler arbeiteten. Anstatt nun als Sicherheitsinstrument zu dienen, blockieren sie die Ameisenlöwen des Spielers. Allerdings hätten wir vorher wahrscheinlich ein gründlicheres Training für die Rammen einbauen sollen. Während Spieler in den vorherigen Levels der Küste die Rammen nur bis zu einem gewissen Maße verstehen müssen, stand zu diesem Zeitpunkt mehr auf dem Spiel, weil die Spieler gleichzeitig zum ersten Mal Köder ausprobieren mussten. Spieler, die nicht wissen, dass die erste Ramme ihre Ameisenlöwen daran hindert, weiterzukommen, verstehen möglicherweise auch nicht, wie Köder funktionieren. Wenn sie diese auf Soldaten im ersten Bunker werfen und keine Ameisenlöwen erscheinen, schließen sie daraus möglicherweise, dass Köder unzuverlässig sind oder nicht wie erwartet funktionieren, und greifen stattdessen wieder auf ihre Waffen zurück."
N/A3972"#commentary\cn_056_buggy_tools.mp3" "[ Matt Wright ] Unsere Absicht war, den Buggy zu mehr als nur einem Fortbewegungsmittel zu machen. Also beschlossen wir, eine Waffe daran anzubringen. Wir entschieden uns für die Tau-Kanone, eine Waffe aus Half-Life 1, die uns gefiel, für die wir aber in Half-Life 2 keinen Platz gefunden hatten. Die Tau-Kanone kann durch Wände schießen, was zu Schwierigkeiten beim Leveldesign führt. Deshalb haben wir sie auf den Küstenbereich beschränkt. Sobald man Waffen einführt, die Wände durchdringen, wird das Leveldesign viel schwieriger. Außerdem haben wir eine Munitionskiste auf der Rückseite des Buggys angebracht, sodass Spieler überall an der Küste über unbegrenzte MP-Munition verfügen. Das war besonders hilfreich für unsere Testspieler, die mit den endlos spawnenden Ameisenlöwen zu kämpfen hatten."
N/A3973"#commentary\cn_057_antlion_guard.mp3" "[ Matt Wright ] In seltenen Fällen konnten Spieler die Löwenwache in dieser Arena nicht töten. Dies passierte, wenn ihnen die Munition ausging und sie alle verfügbaren physischen Objekte verwendet hatten, sodass keine Munition mehr für das Gravitron übrig war. Um dieses Problem zu beheben, brachten wir als Sicherheitsmaßnahme einen Zivilisten auf dem Turm über dem Tor an, der die Wache töten konnte, wenn dem Spieler keine andere Möglichkeit mehr blieb."
N/A3974"#commentary\cn_058_terrain_and_performance.mp3" "[ Mike Dussault ] Unser Leistungsbudget war oft eine erhebliche Einschränkung, wenn es um Kämpfe ging, und noch mehr bei Kämpfen auf Geländeoberflächen. Wenn sich NPCs bewegen, führen sie viele kleine räumliche Sondierungen durch, um festzustellen, ob sie ihren gewählten Weg sicher beschreiten können. Stellen Sie sich vor, Sie können nichts sehen und schwenken ständig einen Stock vor sich hin und her, um zu prüfen, ob der Weg frei ist. Die Performance-Kosten dieser Sondierungen steigen mit der Komplexität der Weltgeometrie. Unser Gelände-Displacement-System erstellt unebene Oberflächen mit vielen Polygonen – weit mehr als die perfekt ebenen Böden, die man anderswo zu dieser Zeit fand. Das bedeutete, dass die NPCs an der Küste ressourcenintensiver waren als in anderen Bereichen, und diese Einschränkung diktierte den Umfang vieler Begegnungen in diesem Abschnitt des Spiels."
N/A3975"#commentary\cn_059_area_portals.mp3" "[ Mike Dussault ] Eine Performance-Herausforderung, der wir uns in der Küste gegenübersahen, war die Handhabung eines großen, offenen Geländes mit Gebäuden, die hoch detaillierte Innenräume hatten – oder zumindest waren sie für 2003 sehr detailliert. Wir wollten so viel wie möglich von unserem Budget für das Rendern dieses Areals verwenden, ohne Ressourcen für die Innenräume der Gebäude zu verlieren. Aber wenn wir nicht alle Fenster und Türen vernageln wollten, konnte der Spieler immer noch hineinsehen. Um dieses Problem zu lösen, entwickelten wir die Area Portals, die wir in jedes offene Fenster und jede offene Tür setzten. Diese Portale berechnen vorab ein flaches Bild des Gebäudeinneren. Wenn ein Spieler in einiger Entfernung ist, zeigen sie dieses vorab berechnete Bild über dem Fenster oder der Tür an, sodass wir das Rendern des tatsächlichen Innenraums überspringen konnten. Wenn sich der Spieler nähert, wechseln wir sanft zwischen dem Bild des Portals und dem tatsächlichen Inneren des Gebäudes. Bei sorgfältiger Verwendung halfen uns die Portale, unsere Performance-Ziele für die Küste zu erreichen – zusammen mit der gelegentlichen Tür, die sich hinter einem schließt."
N/A3976"#commentary\cn_060_buggy_removal.mp3" "[ Miles Estes ] Den Punkt, an dem der Spieler den Buggy zurücklassen soll, mussten wir sehr deutlich machen. Überall an der Küste hatten die Spieler den Buggy verlassen und kehrten dann zu ihm zurück. Wir mussten feststellen, dass Testspieler versuchen würden, ihn mitzunehmen, wenn es auch nur im Entferntesten möglich erschien. Diese kleine Garagenszene dient in erster Linie dazu, deutlich zu signalisieren, dass der Spieler zu Fuß weiterspielen muss."
N/A3977"#commentary\cn_061_d2_coast_04.mp3" "[ Randy Lundeen ] Diese Karte war der erste Bereich der Küste, noch bevor es den Kran und andere Elemente gab. Der trockengelegte Meeresboden und die verrosteten Schiffe waren einige der ersten künstlerischen Elemente, die wir entwickelt hatten. 2003 präsentierten wir die Karte in unserer E3-Demonstration, obwohl damals noch ein Großteil des Gameplays in Arbeit war. Als wir dann begannen, die gesamte Küste aufzubauen, wurde diese Demonstration zu einer nützlichen Vision für uns, auf die wir hinarbeiten konnten."
N/A3978"#commentary\cn_062_transition_tunnels.mp3" "[ Randy Lundeen ] Für die Küste mussten wir eine Methode für Levelübergänge entwickeln. Um von einem Level zum nächsten zu gelangen, mussten wir alles im Übergangsbereich speichern und es nach dem Laden im nächsten Level wiederherstellen. Entscheidend war auch, dass wir alles speicherten und wiederherstellten, was für den Spieler im Übergangsbereich sichtbar war, auch wenn es außerhalb des Bereichs selbst lag. Deswegen versuchten wir, Übergangsbereiche so klein und geschlossen wie möglich zu halten. In den meisten Teilen des Spiels funktioniert ein kleiner Bereich gut für diesen Zweck. Aber für die Küste benötigten wir eine andere Lösung. Nach einigen Experimenten entschieden wir uns für dunkle Tunnel. Diese konnten nicht nur wiederverwendet werden, sondern ermöglichten es uns auch, am Ende Licht hinzuzufügen, um die Tatsache zu verschleiern, dass wir das, was vor dem Spieler liegt, nicht rendern konnten, weil es sich in einem anderen Level befand."
N/A3979"#commentary\cn_063_sniper_alley.mp3" "[ Robin Walker ] Dieser Spielbereich wurde spät in der Entwicklung hinzugefügt, nachdem wir Elis Labor und Ravenholm vor die Küste verlegt hatten. Obwohl man denken könnte, das Spiel sei linear erstellt worden, haben wir es tatsächlich in drei Gruppen aufgeteilt und parallel an verschiedenen Bereichen gearbeitet. Der erste Durchlauf jeder Gruppe konzentrierte sich darauf, den Kern ihres Bereichs fertigzustellen, bevor sie mit dem Rest fortfuhren. Nach der Fertigstellung einer groben Version des Spiels kehrten wir zu jedem Bereich zurück und feilten daran. Wir fügten so etwa erfolgreiche Elemente von anderen Bereichen hinzu und entfernten andere, die nicht funktionierten. In einigen Fällen, wie in Ravenholm, wurden ganze Bereiche verlegt. Nachdem Ravenholm verlegt wurde, benötigten wir einen neuen Bereich, der diesen mit der Küste verband. Das ist der Bereich, den Sie jetzt gerade betreten. Aufgrund des Zeitdrucks wurde dieser kleine Bereich mit bestehenden, erprobten Gameplay-Elementen wie Scharfschützen und Combine-Soldaten versehen."
N/A3980"#commentary\cn_064_battery_finding.mp3" "[ Robin Walker ] Die erhöhte Anzahl an Objekten in den Spielbereichen von Half-Life 2 ermöglichte es uns, Spieler nach einem bestimmten Gegenstand suchen zu lassen, insbesondere, wenn der Gegenstand an einem plausiblen Ort zu finden ist. Spieler können entweder den Gegenstand durch Beobachtung oder Deduktion lokalisieren oder den Bereich auf Teufel komm raus durchsuchen. Da wir bereits einige Modelle für Autos und Batterien entworfen hatten, bot es sich an, einen Schrottplatz zu bauen, den die Spieler erkunden können. Wir versteckten an einigen unerwarteten Orten auch einige Extrabatterien, die Spieler finden konnten, wenn sie einfach auf gut Glück suchen. Auch dieses gegenstandsbasierte Rätsel erforderte eine Zusatzversicherung für den Fall, dass Batterien verloren gehen. Wenn Sie möchten, können Sie alle Batterien über die Klippe werfen und schauen, was passiert."
N/A3981"#commentary\cn_065_boathouse.mp3" "[ Scott Dalton ] Wir konnten in Half-Life 1 viel aus Szenarios herausholen, in denen KI-Gegner gegeneinander kämpften. Es bereitete den Spielern Freude, den Gegnern beim Kämpfen zuzusehen, und erleichterte die Beobachtung ihres Verhaltens. Die erste Begegnung zwischen Ameisenlöwen und Combine-Soldaten war so gestaltet, dass man mit dem Buggy etwas umnieten konnte und gleichzeitig die Funktion der Ramme hervorgehoben wurde. Unser Ziel war es, dass Spieler durch die Beobachtung der Soldaten verstehen, wie sie Ameisenlöwen mit der Ramme fernhalten können. Wir wollten mit den Soldaten demonstrieren, wie wichtig es war, sich in der Nähe der Ramme aufzuhalten, um die Ameisenlöwen zu bekämpfen."
N/A3982"#commentary\cn_066_buggy_theft.mp3" "[ Scott Dalton ] Als wir das Ende der Küste erstellten, entschieden wir uns, dass die Combine den Buggy des Spielers stehlen sollten. Das ergab eigentlich keinen Sinn, jedoch stellten wir nach zahlreichen Spieltests fest, dass die Spieler sehr an ihrem Buggy hingen. Wir wollten diese emotionale Verbindung ausnutzen. Sobald wir den Diebstahl implementierten, schrien die Testspieler die diebischen Combine an – ein Riesenerfolg. Die Soldaten, die von den Felsen herabschossen, waren nur dazu da, um die Spieler dazu zu bewegen, hochzuschauen. Dadurch wurde das Landungsschiff mit dem Buggy ausgelöst. 20 Jahre später können wir kaum glauben, wie absurd das alles ist."
N/A3983"#commentary\cn_067_snipers.mp3" "[ Ted Backman ] Das Team von Half-Life 2 war nie sonderlich groß. Deshalb suchten wir stets nach Möglichkeiten, neues Gameplay ohne hohe Produktionskosten für Assets zu entwickeln. Ein hervorragendes Beispiel dafür ist der Scharfschütze. Es gibt kein reales Modell dafür, lediglich einen Laserstrahl. Also benötigte er weder ein Artwork noch eine Animation. Wenn er stirbt, wird lediglich eine Ragdoll für einen Combine-Soldaten hervorgerufen, die aus dem Fenster fällt. Trotz der Einfachheit haben wir es geschafft, ein einzigartiges Gameplay dafür zu kreieren. Besonders beeindruckte uns die Interaktion des Scharfschützen mit der Physik der Objekte in der Spielwelt. Spieler sind daran gewöhnt, explosive Objekte in der Nähe von Gegnern auszunutzen. Daher fanden wir es passend, dass ein Gegner diese Dynamik auf den Kopf stellt, sobald der Spieler sich in Deckung befindet."
N/A3984"#commentary\cn_068_buggy_model.mp3" "[ Ted Backman ] Das Modell des Buggys durchlief viele Iterationen, bevor es seine endgültige Version erreichte. Wir haben Designs ausprobiert, die sowohl unseren künstlerischen als auch unseren physikalischen Simulationsanforderungen entsprachen, sind dann aber auf ein unerwartetes Problem gestoßen: Vielen Testspielern, sogar Ego-Shooter-Veteranen, wurde beim Fahren des Wagens übel. Bei unseren Optimierungen stellten wir fest, dass eine Änderung des Buggy-Modells half, denn je mehr das Modell die Welt verdeckte, desto mehr Spieler empfanden Übelkeit. Also entfernten wir Teile des Modells, vor allem an der Karosserie, bis den Spielern nicht mehr übel wurde. Insbesondere die Möglichkeit, den Boden durch das fehlende Fahrgestell sehen zu können, machte einen spürbaren Unterschied."
N/A3985"#commentary\cn_069_antlion_design.mp3" "[ Ted Backman ] Beim anfänglichen Design für das Spiel hatten wir Pläne für mehrere Arten von Aliens, von denen die Combine nur eine waren. Eines der anderen war ein religiöses Volk von insektenartigen Wesen, zu dem auch die Ameisenlöwen gehörten. Später, als wir die Küste entwickelten, begannen wir, sie eher als Schädlinge zu betrachten, die zusammen mit Kopfkrabben und anderen Kreaturen durch die Xen-Portale kamen. Obwohl sie eigentlich nicht von Xen stammen, befallen sie alle Ecken jeder Welt, die sie betreten – ähnlich wie Kakerlaken."
N/A3986"#commentary\cn_070_explosive_barrels.mp3" "[ Brian Jacobson ] An dieser Stelle führen wir explosive Fässer ein, ein Klassiker aus Ego-Shootern, aber mit einer neuen Wendung: Der zweite Pistolenschuss setzt das Fass in Brand und löst eine zeitgesteuerte Detonation aus. Ein dritter Schuss lässt das Fass sofort detonieren. Auf diese Weise können Spieler die Explosion je nach Situation entweder verzögern oder sofort auslösen. Spieler können eine Klette mit einem explosiven Fass füttern und dann zweimal darauf schießen, um mehrere von ihnen gleichzeitig zu erledigen. Die verzögerte Explosion sorgt auch für interessantere Kettenreaktionen bei mehreren Fässern. Fans der Serie lieben explosive Fässer. Aber auch intern waren viele Leveldesigner überzeugt, das Spiel könne nie genug solcher Fässer haben."
N/A3987"#commentary\cn_071_ragdoll_magnets.mp3" "[ Dario Casali ] Die Physik von Half-Life 2 gab uns eine Reihe von Werkzeugen, um Kämpfe spannender zu gestalten. Wenn Gegner den Spieler beispielsweise verfehlen, lenken wir ihre Schüsse subtil auf zerbrechliche Objekte in der Nähe, was für Chaos sorgt und das Gefühl erzeugt, als ob man sich in einem Actionfilm befindet. Wir haben die Physik auch für Hinweise eingesetzt, wie die sogenannten \"Ragdoll-Magnete\", durch die Leichen der Gegner auf interessante und dramatische Weise fallen – beispielsweise bei Felsvorsprüngen oder auf der Fahrbahn eines Zugs."
N/A3988"#commentary\cn_072_helicopter_peekaboo.mp3" "[ Dave Riller ] Wir wollten den Combine-Kampfhubschrauber zum zentralen Antagonisten im gesamten Kapitel und damit zu einem Charakter für sich machen. Wenn Sie sich diesen Kommentar anhören, können Sie auch seinen Motor hören, und wenn Sie jetzt nach oben schauen, können Sie ihn entlang der Bahngleise und in die Ferne fliegen sehen. Dieser erste Blick ist eine kleine Vorahnung, deren Präsenz mit der Zeit deutlicher wird – bis Sie schließlich gegen ihn antreten."
N/A3989"#commentary\cn_073_iterative_passes.mp3" "[ David Speyrer ] Einige Kapitel des Spiels, zum Beispiel die Zu-Fuß-Abschnitte der Kanäle und von Ravenholm, wurden in mehreren Durchgängen von verschiedenen Teams entwickelt. Wir fanden heraus, dass das Spiel abwechslungsreicher wird und mehr interessante Momente bietet, wenn man einen Bereich an Kollegen abgibt, da jedes Team den Karten eine einzigartige Note verleiht. In den Kanälen wurden im ersten Durchgang das Design und der Weg des Spielers sowie die Grundzüge des Spiels und einige wichtige Eckpunkte festgelegt. Der teamweite Alpha-Spieltest stellte jedoch fest, dass dieser Abschnitt nicht sehr spannend, sondern etwas eintönig war. In unserem zweiten Durchgang kehrten wir zur Karte zurück und konzentrierten uns ausschließlich darauf, mehr Spannung zu erzeugen, indem wir entsprechende Szenarien enger aneinanderreihten."
N/A3990"#commentary\cn_075_pistol_design.mp3" "[ Josh Weier ] Die Standardpistole leistet die meiste Arbeit im Spiel. Sie ist nicht nur die erste Fernkampfwaffe, mit der Spieler umzugehen lernen, sondern garantiert auch, dass man während des gesamten Spiels aus sicherer Entfernung mit der Physik und zerstörbaren Objekten interagieren kann. Damit sie reaktionsschneller und unterhaltsamer zu bedienen ist, verfügt die Pistole über eine einzigartige Refire-Mechanik. Die Waffe feuert so schnell, wie der Spieler auf die Taste klicken kann. Man spürt also eine sofortige Reaktion auf die Eingabe und je schneller man klickt, desto schneller kann man schießen."
N/A3991"#commentary\cn_076_shatterglass.mp3" "[ Josh Weier ] Bei der Entwicklung der frühen Level, in denen Spieler noch nicht so viele Werkzeuge besitzen, stellten wir fest, dass es genauso spannend ist, stattdessen neue technische Eigenschaften und Objekte ins Rampenlicht zu stellen. Dazu gehört das zerbrechliche Glas, das man hier sieht. Für den Zerstörungseffekt wurde das Glas in ein Raster aus kleinen Quadraten unterteilt, sodass wir verfolgen konnten, welche intakt oder kaputt waren. Wir konnten außerdem größere Löcher erschaffen, sobald nicht mehr genügend Quadrate miteinander verbunden waren. Jedes Quadrat wurde mit einer einzigartigen Textur gerendert, die auf dem Status der benachbarten Quadrate beruht. So entstanden die scharfen, gezackten Kanten zwischen zerbrochenem und intaktem Glas. Glasscherben sind heute in Spielen die Norm, aber als wir Half-Life 2 entwickelten, hatten wir dies noch nicht oft gesehen und waren sehr zufrieden mit dem Grad an Realismus und Dynamik, die das Spiel dadurch erhielt."
N/A3992"#commentary\cn_077_lambda_caches.mp3" "[ Laura Dubuk ] Streng genommen befindet sich das erste Lambda-Lager in Kleiners Labor. Aber dieses ist das erste von vielen, das der Spieler selbst entdeckt. Wir fügten Lambda-Lager hinzu, um Spieler zum Erkunden zu animieren und ihnen Hinweise zu geben, wo versteckte Ressourcen zu finden sind. Die Idee dahinter war, dass sie von der Widerstandsbewegung platziert wurden. In Half-Life war der Inhalt der Mun-Behälter durch das Leveldesign vorgegeben. In Half-Life 2 haben wir adaptive Behälter eingeführt, die Spielern alles geben, was ihnen gerade fehlt, basierend auf den vom Leveldesigner festgelegten Ressourcenzielen."
39683993"#commentary\cn_078_scanners.mp3" "[ Kerry Davis ] Scanner stellten eine knifflige Herausforderung für das Spieldesign dar. Obwohl uns gefiel, wie ihre dystopische Präsenz dazu beitrug, die Combine-Besatzung als einen repressiven Überwachungsstaat darzustellen, wollten wir nicht, dass sie auf den Spieler schießen. Unserer Meinung nach machte es keinen Spaß, auf den Himmel zu zielen, um einen kleinen, beweglichen Gegner mit Höhenvorteil zu treffen. Da uns ihre Rolle in der Geschichte gefiel, beschlossen wir, dass Scanner im Kampf hauptsächlich als Augen dienen und Gegner in der Nähe auf die Anwesenheit des Spielers aufmerksam machen. Wir untermalten diese Funktion mit den Soundeffekten der Soldaten. Darüber hinaus konnten sie den Spieler nur mit hellen Lichtern blenden und gelegentlich einen Sturzflug machen, nachdem sie ausreichend Schaden erlitten hatten."
3969N/A"#commentary\cn_079_surface_properties.mp3" "[ Ariel Diaz ] Es werden benutzerdefinierte Schrittgeräusche abgespielt, wenn der Spieler den rutschigen Schlamm überquert. Dabei handelt es sich um ein System namens „Oberflächeneigenschaften“, das anhand der Art des Materials Geräusche und andere Effekte festlegt, die auftreten sollen, wenn man im Spiel auf bestimmte Überflächen tritt oder darauf schießt. Zu Beginn der Entwicklung hatten wir einen Effekt, der die Bewegung des Spielers verlangsamte, wenn er über Schlamm lief. Dieser wurde jedoch aus der ausgelieferten Version entfernt, da wir ihn für zu strapaziös hielten."
3970N/A"#commentary\cn_080_combat_entrances.mp3" "[ Dario Casali ] Es ist immer eine etwas verlegene Situation, wenn man um eine Ecke in ein neues Gebiet läuft und dort Gegner vorfindet. Es macht die Welt weniger lebendig und verwandelt sie in einen Schießstand. Daher wollten wir Gegner auf interessantere und dynamischere Weise in Kampfgebiete einführen, um ihre Planung und Absichten zu vermitteln – ganz so, als ob diese Soldaten schon einen Plan für Gordon hatten, bevor er auftauchte. Die Metrocops in dieser Szene springen über gescriptete Sequenzen in den Bereich hinunter und später im Spiel verwenden wir das Abseilen auf ähnliche Weise. Es spielt keine Rolle, woher sie in Wirklichkeit kommen, denn Spieler schließen aus ihren Vermutungen. Wir wollten, dass hinter Kämpfen eine Geschichte steckt: ein Hinterhalt, eine Überraschung, eine Angriffswelle, ein Angriff – all diese Szenarien verwenden weitgehend dieselbe gegnerische KI, aber sie fühlten sich für die Spieletester alle anders an."
3971N/A"#commentary\cn_081_mounted_gun_gallery.mp3" "[Dave Riller] In dieser Szene passiert einiges: Der Turm, der auf die zerbrechlichen Kisten dahinter feuert, weist Spieler darauf hin, nicht direkt auf die Bedrohung einzugehen und stattdessen die Kanalisation zu nutzen, um sie zu besiegen. Und wenn sie den Turm erreichen, nutzen Spieler ihn gerne als Schießstand, um eine Welle von Combine-Soldaten und im Sturzflug angreifende Scanner zu bekämpfen. Außerdem wird hier der Combine-SPz eingeführt, der die Spieler antreibt und später im Kapitel erneut auftaucht."
3972N/A"#commentary\cn_082_barnacle_bowling.mp3" "[ Josh Weier ] Dies ist ein gutes Beispiel dafür, wie eine Reihe von Designelementen in einer Matrix von Interaktionen zusammenkommen, um ein unvergessliches Szenario für den Spieler zu schaffen. Wir haben Kletten, unsere Physiksimulation, rutschigen Schlamm und nicht zuletzt: explosive Fässer. Sie sind all diesen Dingen schon einzeln begegnet, aber sie passen auf natürliche Weise zusammen und schaffen einen Moment, den wir „Kletten-Bowling“ nennen."
3973N/A"#commentary\cn_083_barnacle_introduction.mp3" "[Mike Dussault] Da Kletten bei der ersten Begegnung verwirrend sein können, wollten wir sie so vorstellen, dass Spieler ihr Verhalten aus sicherer Entfernung erlernen können. Wir entschieden uns dafür, das mit einer Raubtier- und Beute-Szene im Stil einer Naturdoku zu tun. Aber wie immer waren bei solchen Szenen viele Wiederholungen erforderlich, bis Spieler sie zuverlässig erkennen konnten."
3974N/A"#commentary\cn_084_physics_in_puzzles.mp3" "[ Eric Smith ] Oft werden einfachere Mechaniken, die man früher im Spiel findet, zu Übungszwecken aus komplexeren übernommen. Die wippende Brücke hier ist das erste physikbasierte Gerät im Spiel und wurde von einem späteren, komplizierteren Rätsel mit einer Waschmaschine in den Kanälen abgeleitet. Das Wippen verwendet dieselben Prinzipien von Masse und Rampen, aber Spieler können direkter damit interagieren, was ihnen hilft, die Physik des Spiels zu verstehen und spätere Rätsel leichter zu lösen. Dieses Rätsel unterstreicht auch die analoge Natur des Physiksystems, wobei sowohl die Platzierung der Betonblöcke als auch das eigene Gewicht des Spielers in die Lösung einfließen."
3975N/A"#commentary\cn_085_combine_attack_helicopter.mp3" "[ Brian Jacobson ] Die Spieler konnten bereits zuvor einen Blick auf ihn erhaschen, aber hier stellen wir den Hauptboss des Kapitels „Kanäle“ richtig vor: den Kampfhubschrauber der Combine. Dieser Hubschrauber zerstört gnadenlos die Deckung des Spielers und zwingt ihn, sich vorwärtszubewegen, da er sonst Gefahr läuft, niedergeschossen zu werden. Wir wollten, dass diese Sequenz spannend und bedrohlich wirkt. Der Helikopter scheint viel zu stark für eine direkte Konfrontation. Diese Intensität sollte durch die Kanäle bis zum finalen Showdown im Reservoir aufrechterhalten werden. Um das zu erreichen, schränkten wir die Bewegung des Helikopters anhand bestimmter Gameplay-Ziele stark ein. Auf dieser Karte, die als Sprint von Deckung zu Deckung unter Feuer konzipiert ist, haben wir eine ringförmige Bahn am Himmel über der Arena erstellt. Der Schrauber fliegt immer zu dem vom Spieler am weitesten entfernten Punkt auf seiner Bahn, wodurch er sichtbar bleibt und wir leichter Deckung an den richtigen Stellen platzieren können."
3976N/A"#commentary\cn_087_explosive_barrel_factory.mp3" "[David Speyrer] Dieser Raum ist mit einer absurden Anzahl explodierender Fässer gefüllt. Dies löste innerhalb des Teams eine gutmütige Debatte darüber aus, wie weit die Plausibilität unserer Welt überschritten werden kann. Realistisch gesehen ist selbst ein explodierendes Fass zu viel — in der realen Welt sollten Fässer nicht explodieren, selbst wenn man darauf schießt."
3977N/A"#commentary\cn_088_rising_water.mp3" "[ Dhabih Eng ] Die schwimmende Brücke und die Holzspulen führen hier das Konzept des Auftriebs als Hilfsmittel für den Spieler ein. In diesem Fall handelt es sich nicht wirklich um ein Puzzle, sondern nur um ein bisschen Spaß für den Spieler, der mit der Spielphysik interagiert. Später greifen wir dieses Gameplay-Element in den Kanälen wieder auf, um eine Rampe für das Luftboot zu bauen."
3978N/A"#commentary\cn_089_manhack_matt.mp3" "[ John Morello ] Wir nannten diesen Typen „Schnitter Matt“. Wir wollten Spielern das Gefühl vermitteln, dass Hunderte Zivilisten die verborgenen Winkel und Ecken von City 17 bewohnten. Zu diesem Zeitpunkt des Spiels haben Spieler schon eine Weile keinen Zivilisten mehr gesehen, und wir wollten die Bedeutung der Schnitter erklären – dem ersten physikbasierten Gegner. Im ursprünglichen Konzept gab es in der Stadt eine Videospielhalle, in der Spieler Schnitter herumfliegen konnten, um virtuelle Zivilisten anzugreifen. Später entdeckten die Spieler, dass die Schnitter, ebenso wie die Zivilisten, innerhalb der Spielwelt tatsächlich vorkommen. Als die Besetzung durch die Combine sich immer weiter ausbreitete, fanden wir die Idee einer Videospielhalle zu merkwürdig und entfernten sie."
3979N/A"#commentary\cn_090_fighting_motion_sickness.mp3" "[ David Speyrer ] Bei den ersten Spieltests wurde vielen Spielern beim Fahren des Luftboots schlecht. Bei dem Versuch, dies zu beheben, entdeckten wir mehrere Faktoren, die dazu beitrugen. Wir fanden heraus, dass es half, die Beeinträchtigung der Sicht durch das Luftboot zu reduzieren, also überarbeiteten wir das Modell mehrmals. Auch die Beibehaltung einer konstanten Bildrate half, also war es wichtig, die Systemleistung in diesen Abschnitten im Auge zu behalten. Der allerwichtigste Faktor war jedoch, das Rollen der Sicht zu vermeiden und einen stabilen Horizont beizubehalten, egal, was das Luftboot tat. Einer der Programmierer im Team war extrem anfällig für Reisekrankheit und bot mutig an, mehrere Spieletests durchzuführen, um unsere Fortschritte bei der Lösungssuche zu bewerten. Ich bin ziemlich sicher, dass er sich nach den Spieltests mindestens einmal übergeben musste, und seine edle Aufopferung wurde sehr geschätzt."
3980N/A"#commentary\cn_091_headcrab_canisters.mp3" "[Jeff Lane] Gebrauchte Kopfkrabbenbehälter findet man später in Ravenholm, also haben wir beschlossen, sie hier zu zeigen, um zu veranschaulichen, wie sie von der Combine verwendet werden. Laut der Geschichte stattete die Combine die Xen-Fauna mit Waffen aus, um sie gegen die Menschen einzusetzen. Eingegrabene Kopfkrabben wurden als neue Begegnung für diesen Abschnitt hinzugefügt. Er wurde um einen größeren Bereich erweitert, der eine Baracke zeigt, die durch einen Kopfkrabbenangriff nahezu vollkommen zerstört wurde."
3981N/A"#commentary\cn_092_airboat_intro.mp3" "[ John Morello ] Das ist der Zeitpunkt, an dem der Spieler im Spiel sein erstes Fahrzeug erhält: das Luftboot. Wir wollten für Spieler einen sicheren Ort kreieren, um mit dem Luftboot so lange man will fahren zu üben, bevor man weitergeht. Die Arena ist mit vielen Gelegenheiten für Sprünge und Tricks gespickt. Auch ist sie mit toxischem Schleim gefüllt, um Spieler länger im Luftboot zu halten und sie daran zu hindern, das Fahrzeug zurückzulassen und zu Fuß weiterzulaufen."
3982N/A"#commentary\cn_093_zombie_surprise.mp3" "[ Jeff Lane ] Es gibt in diesem Kanalisationsrohr einen frechen Jumpscare. Spieler wandern hier rein, konzentriert und neugierig, und dann taucht plötzlich ein Unterwasserzombie auf, der viele Spieltester gehörig erschreckt hat. Einer fiel sogar aus seinem Stuhl, was wir als Erfolg betrachten."
3983N/A"#commentary\cn_094_airboat_time.mp3" "[ Dave Riller ] Es war eine Herausforderung, die richtige Balance zwischen Zeit im Fahrzeug und Zeit zu Fuß zu finden. Spieler, die mit Vollgeschwindigkeit fahren, können die Welt schnell durchqueren. In frühen Spieltests hatten Spieler deshalb das Gefühl, dass sie viele Erkundungsmöglichkeiten verpassten und die Spieldetails kaum wahrnahmen. Die Erkundung und Untersuchung der Welt sind wesentliche Bestandteile von Half-Life. Aus diesem Grund wollten wir nicht, dass Fahrzeuge dies zerstören. Deswegen haben wir immer wieder Stellen geschaffen, an denen Spieler aussteigen und kleine Bereiche mit hoher Detailtiefe erkunden müssen. Des Weiteren entwickelte sich das Physiksystem stetig weiter, was die Möglichkeit bot, diese zu nutzen. Die Stellen, an denen man sich vom Luftboot entfernen muss, führten zu einer Entdeckung von physikalischen Möglichkeiten, wie Kisten ins Wasser fallen zu lassen oder Fässer zu kombinieren, um eine Rampe hochzuheben. Spieler können so auf unterschiedliche Weise mit Wasser und der Physik interagieren."
3984N/A"#commentary\cn_095_floating_supplies.mp3" "[ Josh Weier ] Im Alphaspieltest waren die Kanäle voll mit schwimmenden Munitionsbehältern, die Spieler mit dem Luftboot aufbrechen konnten, um hilfreiche Gegenstände einzusammeln. Die Mechanik war recht spieltypisch, half jedoch, den Spielfluss beizubehalten und die Spieler unterwegs mit dem Nötigsten zu versorgen. Um diese Prämisse plausibel zu halten, wollten wir eine Geschichte davon erzählen, wie diese schwimmenden Munitionsbehälter es überhaupt so bequem auf den Pfad des Spielers geschafft haben. Die Szene mit Bürgern, die Behälter fallen ließen, half uns dabei, diese Geschichte zu verkaufen und gleichzeitig die Kanäle lebendig zu halten. Es ermöglichte auch Spielern, sich heldenhafter und wichtiger zu fühlen, da so viele Charaktere einen unterstützen."
3985N/A"#commentary\cn_096_grenade_intro.mp3" "[ Brian Jacobson ] Wir hatten diese Combine-Basis sowohl als Trainingsbereich als auch als Spielplatz für Granaten konzipiert und sie hier in Vorratskisten mit unendlicher Kapazität eingeführt. Dies signalisiert, dass Spieler die Granaten sicher und nach Belieben verwenden können, ohne befürchten zu müssen, dass ihnen der Vorrat ausgeht. Sie können sich also austoben. Der Kampf an dieser Stelle verwendet umfangreiche Markierungen, um die Soldaten-KI in Deckung zu lenken und Spielern eine gute Gelegenheit zu bieten, Granaten einzusetzen. Am Ende des Bereichs hilft derselbe unendliche Granatenvorrat bei der Entscheidung über die Platzierung des Turms, da ein direkter Angriff sonst viel schwieriger ist. Den Granaten wurde ein helles rotes Licht und eine Partikelspur hinzugefügt, wodurch es für Spieler wesentlich einfacher ist, ihrer Flugbahn zu folgen, egal ob sie sie werfen oder einem Shuss eines Combine-Soldaten ausweichen."
3986N/A"#commentary\cn_097_puzzle_layers.mp3" "[ Dave Riller ] Da Spieler sich der Absicht der Designer oft nicht bewusst sind – unserer Meinung nach ein Vorteil – reagieren sie auf unsere Rätsel auf alle möglichen überraschenden Arten. Selbst scheinbar einfache Rätsel können auf dem Weg zum Erfolg unzählige Fehlschläge mit sich bringen. Das war bei diesem Rätsel zum Öffnen der Kanaltore der Fall und erforderte viele unterschiedliche Hinweise. Das Funken sprühende Rad vermittelt, dass das Tor geöffnet werden kann, aber eine andere Methode erforderlich ist. Ein paar Krähen lenken den Blick des Spielers auf die Lösung – in diesem Fall ein Bündel schwingender Träger. Da Granaten bereits ausführlich veranschaulicht wurden, wollten wir ursprünglich, dass die Spieler eine davon werfen, um die hölzerne Stützstruktur zu zerstören, aber das war nicht offensichtlich genug. Wir fügten explodierende Fässer als viel klareren Hinweis hinzu. Aber selbst, nachdem sie das Rätsel gelöst hatten, erkannten einige Spieler nicht, dass das Tor jetzt offen war, was dazu führte, dass sie das Innere der Basis endlos auf der Suche nach einem anderen Ausgang erkundeten. Also mussten wir sie an ihr ursprüngliches Problem erinnern, das kaputte Tor. Wir fügten Rauch, eine Alarmhupe und ein rotierendes Licht hinzu und sahen bei den Spieletests endlich zuverlässig gute Ergebnisse."
3987N/A"#commentary\cn_101_357_intro.mp3" "[ Josh Weier ] Anders als andere normale Handfeuerwaffen verfügt die Magnum über eine langsamere Feuerrate. Sie fügt Feinden und Gegnern maßvoll und kalkuliert katastrophalen Schaden zu. Frühe Versionen der Magnum hatten ein randomisiertes Streumuster, das sich beim Drücken des Abzugs so gewichtig und sensibel anfühlte, wie wir das bei einer größeren Pistole erwarteten. Jedoch führte dies zu enttäuschenden Momenten, an denen der Spieler einen Schuss sorgfältig ansetzte und aufgrund der geringeren Genauigkeit verfehlte. Deshalb sorgten wir dafür, dass die erste Kugel 100 % genau war und jeder nachfolgende Schuss weniger genau wurde, sobald man mit dem Schießen begann."
3988N/A"#commentary\cn_102_helicopter_bombing_run.mp3" "[ Brian Jacobson ] Dies ist ein weiteres Beispiel für unsere Anstrengungen, für die Fahrt im Luftboot gefährliche Momente zu kreieren. Der Hubschrauber versucht, vor dem Spieler zu bleiben und Bomben abzuwerfen. Wenn der Spieler sich zurückzieht, wechselt er in den Schwebemodus und greift den Spieler an. In einem Spieltest fiel eine Bombe genau zwischen die Fugen des Rohrs und kreierte so einen filmreifen Moment. Der Spieltester reagierte so positiv, dass das Team sich dafür entschied, den Moment so zu programmieren, dass er jedes Mal auftrat. Dieser Prozess wurde ein Teil unseres organischen Designprozesses: Immer mal wieder passiert zufällig etwas so Cooles in einem Spieltest, dass wir einen Weg finden, diesen Moment zuverlässiger zu ermöglichen."
3989N/A"#commentary\cn_103_smokestack_collapse.mp3" "[ Doug Wood ] Für den Fall, dass wir ein kinoreifes Actionspiel wie Half-Life entwickeln, wollten wir schon immer große, spektakuläre Zerstörungssequenzen kreieren, konnten dies bisher jedoch nicht erreichen. Die Physik von Half-Life 2 ermöglichte es, kleine Objekte wie Kisten in kleine Stücke zu zerbrechen. Folglich dachten wir an etwas Größeres. Wir versuchten es direkt mit einem Fabrikschornstein, der in kleine Stücke zerbrach, bevor er fiel. Dann experimentierten wir mit den Massen, bis es sich besser anfühlte, feilten am Modell und fügten viel Rauch und Sound hinzu, um den Effekt realistischer zu gestalten. Und voilà, da hatten wir unseren großen, spektakulären Zerstörungsmoment. Die Physik ermöglichte es uns gerade so, dies so umzusetzen, dass es nach unseren modernen Standards interessant klingt, aber für uns damals fantastisch war. Da die Simulation bei jeder Ausführung einzigartig war, mussten wir sicherstellen, dass der Pfad des Spielers nicht von großen Geröllbrocken versperrt wurde. Nach dem Erfolg dieser Sequenz waren wir auf der Suche nach noch realistischeren filmreifen Physik-Zerstörungseffekten, wie in Episode 2 zu sehen."
N/A3994"#commentary\cn_079_surface_properties.mp3" "[ Ariel Diaz ] Wenn der Spieler den rutschigen Schlamm überquert, werden spezielle Schrittgeräusche abgespielt. Dabei handelt es sich um ein System namens \"Oberflächeneigenschaften\", das anhand der Art des Materials Geräusche und andere Effekte festlegt, die auftreten sollen, wenn man drauftritt oder -schießt. Zu Beginn der Entwicklung hatten wir einen Effekt, der die Bewegung des Spielers verlangsamte, wenn er über Schlamm lief. Dieser wurde jedoch aus der fertigen Version entfernt, da wir ihn für zu lästig hielten."
N/A3995"#commentary\cn_080_combat_entrances.mp3" "[ Dario Casali ] Es ist immer etwas merkwürdig, wenn man um eine Ecke in ein neues Gebiet läuft und dort direkt Gegner stehen sieht. Es macht die Welt weniger lebendig und verwandelt sie in einen Schießstand. Daher wollten wir Gegner auf interessantere und dynamischere Weise in Kampfgebiete einführen, um mehr Intention und Planung zu suggerieren – ganz so, als wären diese Soldaten bereits auf Gordon vorbereitet, bevor er auftaucht. Die Metrocops in dieser Szene springen über geskriptete Sequenzen in den Bereich hinunter und später im Spiel verwenden wir das Abseilen auf ähnliche Weise. Es spielt keine Rolle, woher sie in Wirklichkeit kommen. Den Teil denken sich die Spieler selbst. Wir wollten, dass hinter Kämpfen eine Geschichte steckt: ein Hinterhalt, eine Überraschung, eine Angriffswelle, eine Erstürmung – all diese Szenarien verwenden weitgehend die gleiche Gegner-KI, aber sie fühlten sich für die Testspieler alle anders an."
N/A3996"#commentary\cn_081_mounted_gun_gallery.mp3" "[ Dave Riller ] In dieser Szene ist viel los: Der Turm, der auf die zerbrechlichen Kisten dahinter feuert, weist Spieler darauf hin, nicht direkt auf die Bedrohung einzugehen und stattdessen die Kanalisation zu nutzen, um sie zu besiegen. Und wenn sie den Turm erreichen, nutzen Spieler ihn gerne als Schießstand, um eine Welle von Combine-Soldaten und herabstürzende Scanner aufs Korn zu nehmen. Außerdem wird hier der Combine-SPz eingeführt, der die Spieler antreibt und später im Kapitel erneut auftaucht."
N/A3997"#commentary\cn_082_barnacle_bowling.mp3" "[ Josh Weier ] Dies ist ein gutes Beispiel dafür, wie eine Reihe von Designelementen in einer Matrix von Interaktionen zusammenkommen, um ein unvergessliches Szenario für den Spieler zu schaffen. Wir haben Kletten, unsere Physiksimulation, rutschigen Schlamm und nicht zuletzt: explosive Fässer. Sie sind all diesen Dingen schon einzeln begegnet, aber sie passen auf natürliche Weise zusammen und schaffen einen Moment, den wir \"Kletten-Bowling\" nennen."
N/A3998"#commentary\cn_083_barnacle_introduction.mp3" "[ Mike Dussault ] Da Kletten bei der ersten Begegnung verwirrend sein können, wollten wir sie so vorstellen, dass Spieler ihr Verhalten aus sicherer Entfernung kennenlernen können. Wir entschieden uns dafür, das mit einer Raubtier-und-Beute-Szene im Stil einer Naturdoku zu tun. Aber wie immer waren bei solchen Szenen viele Iterationen erforderlich, bis wir sicher sein konnten, dass die Spieler sie auch sehen."
N/A3999"#commentary\cn_084_physics_in_puzzles.mp3" "[ Eric Smith ] Oft werden einfachere Mechaniken, die man früher im Spiel findet, zu Übungszwecken aus komplexeren herausgenommen. Das Wippenrätsel hier ist das erste physikbasierte Konstrukt im Spiel und wurde von einem späteren, komplizierteren Waschmaschinen-Rätsel in den Kanälen abgeleitet. Die Wippe verwendet dieselben Prinzipien von Masse und Rampen, aber Spieler können direkter damit interagieren, was ihnen hilft, die Physik des Spiels zu verstehen und spätere Rätsel leichter zu lösen. Dieses Rätsel unterstreicht auch die analoge Natur des Physiksystems, wobei sowohl die Platzierung der Betonblöcke als auch das eigene Gewicht des Spielers in die Lösung einfließen."
N/A4000"#commentary\cn_085_combine_attack_helicopter.mp3" "[ Brian Jacobson ] Die Spieler konnten bereits zuvor einen Blick auf ihn erhaschen, aber hier stellen wir den Hauptboss des Kanal-Kapitels richtig vor: den Kampfhubschrauber der Combine. Dieser Hubschrauber zerstört gnadenlos die Deckung des Spielers und zwingt ihn, sich vorwärtszubewegen, da er sonst Gefahr läuft, niedergeschossen zu werden. Wir wollten, dass diese Sequenz spannend und bedrohlich wirkt. Der Helikopter scheint viel zu stark für eine direkte Konfrontation. Diese Intensität sollte durch die Kanäle bis zum finalen Showdown im Reservoir aufrechterhalten werden. Um das zu erreichen, schränkten wir die Bewegung des Helikopters stark ein, damit sie zum Gameplay passen. Auf dieser Karte, die als Sprint von Deckung zu Deckung unter Feuer konzipiert ist, haben wir eine ringförmige Bahn am Himmel über der Arena erstellt. Der Schrauber fliegt immer zu dem vom Spieler am weitesten entfernten Punkt auf seiner Bahn, wodurch er sichtbar bleibt und wir leichter Deckung an den richtigen Stellen platzieren können."
N/A4001"#commentary\cn_087_explosive_barrel_factory.mp3" "[ David Speyrer ] Dieser Raum ist mit einer absurden Anzahl explosiver Fässer gefüllt. Dies löste innerhalb des Teams eine gutmütige Debatte darüber aus, wie weit die Plausibilität unserer Welt überschritten werden kann. Realistisch gesehen ist schon ein explodierendes Fass zu viel — in der realen Welt sollten Fässer nicht explodieren, selbst wenn man darauf schießt."
N/A4002"#commentary\cn_088_rising_water.mp3" "[ Dhabih Eng ] Die schwimmende Brücke und die Holzspulen führen hier das Konzept des Auftriebs als Hilfsmittel für den Spieler ein. In diesem Fall handelt es sich nicht wirklich um ein Rätsel, sondern nur um ein bisschen Spaß für den Spieler, der mit der Spielphysik interagiert. Später greifen wir dieses Gameplay-Element in den Kanälen wieder auf, um eine Rampe für das Luftboot zu bauen."
N/A4003"#commentary\cn_089_manhack_matt.mp3" "[ John Morello ] Wir nannten diesen Typen \"Schnitter Matt\". Wir wollten Spielern das Gefühl vermitteln, dass Hunderte Zivilisten die verborgenen Winkel und Ecken von City 17 bewohnten. Zu diesem Zeitpunkt des Spiels haben Spieler schon eine Weile keinen Zivilisten mehr gesehen, und wir wollten die Bedeutung der Schnitter erklären – dem ersten physikbasierten Gegner. Im ursprünglichen Konzept gab es in der Stadt eine Spielhalle, in der Spieler Schnitter herumfliegen konnten, um virtuelle Zivilisten anzugreifen. Später entdeckten die Spieler, dass die Schnitter, ebenso wie die Zivilisten, innerhalb der Spielwelt tatsächlich vorkommen. Als die Besetzung durch die Combine immer mehr Form annahm, fanden wir die Idee einer Spielhalle unpassend und entfernten sie."
N/A4004"#commentary\cn_090_fighting_motion_sickness.mp3" "[ David Speyrer ] Bei den ersten Spieltests wurde vielen Spielern beim Fahren des Luftboots schlecht. Bei dem Versuch, dies zu beheben, entdeckten wir mehrere Faktoren, die dazu beitrugen. Wir fanden heraus, dass es half, die Beeinträchtigung der Sicht durch das Luftboot zu reduzieren, also überarbeiteten wir das Modell mehrmals. Auch die Beibehaltung einer konstanten Bildrate half, also war es wichtig, die Systemleistung in diesen Abschnitten im Auge zu behalten. Der allerwichtigste Faktor war jedoch, das Rollen der Sicht zu vermeiden und einen stabilen Horizont beizubehalten, egal, was das Luftboot tat. Einer der Programmierer im Team war extrem anfällig für Bewegungskrankheit und bot mutig an, mehrere Spieltests durchzuführen, um unsere Fortschritte bei der Lösungssuche zu bewerten. Ich bin ziemlich sicher, dass er sich nach den Spieltests mindestens einmal übergeben musste, und seine edle Aufopferung wurde sehr geschätzt."
N/A4005"#commentary\cn_091_headcrab_canisters.mp3" "[ Jeff Lane ] Gebrauchte Kopfkrabbenbehälter findet man später in Ravenholm, also haben wir beschlossen, sie hier zu zeigen, um zu veranschaulichen, wie sie von der Combine verwendet werden. Laut der Geschichte verwendete die Combine die Xen-Fauna als Waffe gegen die Menschheit. Eingegrabene Kopfkrabben wurden als neue Begegnung für diesen Abschnitt hinzugefügt. Dieser vergrößerte Bereich soll eine Barackensiedlung zeigen, die von den Kopfkrabben zerstört wurde."
N/A4006"#commentary\cn_092_airboat_intro.mp3" "[ John Morello ] Das ist der Zeitpunkt, an dem der Spieler sein erstes Fahrzeug im Spiel erhält: das Luftboot. Wir wollten für Spieler einen sicheren Ort kreieren, um mit dem Luftboot so lange zu üben, wie man will, bevor es weitergeht. Die Arena ist mit vielen Gelegenheiten für Sprünge und Tricks gespickt. Außerdem ist sie mit toxischem Schleim gefüllt, damit Spieler länger im Luftboot bleiben und nicht das Fahrzeug zurücklassen und zu Fuß weiterlaufen."
N/A4007"#commentary\cn_093_zombie_surprise.mp3" "[ Jeff Lane ] Es gibt in diesem Abwasserrohr einen frechen Jumpscare. Spieler wandern hier rein, konzentriert und neugierig, und dann taucht plötzlich ein Unterwasserzombie auf, der viele Testspieler gehörig erschreckt hat. Einer fiel sogar aus seinem Stuhl, was in unseren Augen ein voller Erfolg war."
N/A4008"#commentary\cn_094_airboat_time.mp3" "[ Dave Riller ] Es war eine Herausforderung, die richtige Balance zwischen Zeit im Fahrzeug und Zeit zu Fuß zu finden. Spieler, die mit Vollgeschwindigkeit fahren, können die Welt schnell durchqueren, und in frühen Spieltests hatten wir das Gefühl, dass Spieler viele Erkundungsmöglichkeiten verpassten und die Details kaum wahrnahmen. Die Erkundung und Erforschung der Welt sind wesentliche Bestandteile von Half-Life, und das wollten wir nicht mit Fahrzeugen kaputtmachen. Deswegen haben wir immer wieder Stellen geschaffen, an denen Spieler aussteigen und kleine Bereiche mit hoher Detailtiefe erkunden müssen. Des Weiteren entwickelte sich das Physiksystem stetig weiter, was uns immer neue Möglichkeiten bot. Diese Stellen ohne Luftboot boten Gelegenheiten, die Physik entdecken, wie Kisten ins Wasser fallen zu lassen oder Fässer zu kombinieren, um eine Rampe anzuheben. Spieler konnten so auf unterschiedliche Weise mit Wasser und der Physik interagieren."
N/A4009"#commentary\cn_095_floating_supplies.mp3" "[ Josh Weier ] Im Alpha-Spieltest waren die Kanäle voll mit schwimmenden Mun-Behältern, die Spieler mit dem Luftboot aufbrechen konnten, um hilfreiche Gegenstände einzusammeln. Die Mechanik war recht spieltypisch, half jedoch, den Spielfluss beizubehalten und die Spieler unterwegs mit dem Nötigsten zu versorgen. Um diese Prämisse plausibel zu halten, wollten wir eine Geschichte darüber erzählen, warum diese schwimmenden Kisten überhaupt so bequem auf dem Pfad des Spielers liegen. Die Szene mit Bürgern, die Kisten fallen ließen, half uns dabei, diese Geschichte zu verkaufen und gleichzeitig die Kanäle lebendig zu halten. Es ermöglichte auch Spielern, sich heldenhafter und wichtiger zu fühlen, da so viele Charaktere einen unterstützen."
N/A4010"#commentary\cn_096_grenade_intro.mp3" "[ Brian Jacobson ] Wir hatten diese Combine-Basis sowohl als Trainingsbereich als auch als Spielplatz für Granaten konzipiert und sie hier in Mun-Behälter mit unendlicher Kapazität eingeführt. Dies signalisiert, dass Spieler die Granaten sicher und nach Belieben verwenden können, ohne befürchten zu müssen, dass ihnen der Vorrat ausgeht. Sie können sich also austoben. Die KI lenkt die Soldaten in diesem Kampf ständig in Deckung und bietet Spielern so eine gute Gelegenheit, Granaten einzusetzen. Am Ende des Bereichs hilft derselbe unendliche Granatenvorrat, mit dem Turm fertigzuwerden, da ein direkter Angriff sonst viel schwieriger ist. Den Granaten wurden ein helles rotes Licht und eine Partikelspur hinzugefügt, wodurch es für Spieler wesentlich einfacher ist, ihrer Flugbahn zu folgen, egal ob sie sie werfen oder den Granaten der Combine-Soldaten ausweichen."
N/A4011"#commentary\cn_097_puzzle_layers.mp3" "[ Dave Riller ] Da Spieler sich der Absicht der Designer oft nicht bewusst sind – unserer Meinung nach ein Vorteil –, reagieren sie auf unsere Rätsel auf alle möglichen überraschenden Arten. Selbst scheinbar einfache Rätsel können auf dem Weg zum Erfolg unzählige Fehlschläge mit sich bringen. Das war bei diesem Rätsel zum Öffnen der Kanaltore der Fall und es erforderte viele unterschiedliche Hinweise. Das Funken sprühende Rad vermittelt, dass das Tor geöffnet werden kann, aber eine andere Methode erforderlich ist. Ein paar Krähen lenken den Blick des Spielers auf die Lösung – in diesem Fall ein Bündel schwingender Träger. Da Granaten bereits ausführlich veranschaulicht wurden, wollten wir ursprünglich, dass die Spieler eine davon werfen, um die hölzerne Stützstruktur zu zerstören, aber das war nicht offensichtlich genug. Wir fügten explodierende Fässer als viel klareren Hinweis hinzu. Aber selbst, nachdem sie das Rätsel gelöst hatten, erkannten einige Spieler nicht, dass das Tor jetzt offen war, was dazu führte, dass sie das Innere der Basis endlos auf der Suche nach einem anderen Ausgang erkundeten. Also mussten wir sie an ihr ursprüngliches Problem erinnern, das kaputte Tor. Wir fügten Rauch, eine Alarmhupe und ein rotierendes Licht hinzu und sahen bei den Spieltests endlich zuverlässig gute Ergebnisse."
N/A4012"#commentary\cn_098_metrocop_strafing.mp3" "[ Doug Wood ] Das ursprüngliche Design der Luftboot-Level zielte darauf ab, die Spieler mit engen Manövern unter dem Druck der Metrocops herauszufordern. Der konstante Beschuss der Metrocops sollte die Spieler dazu bringen, einen Slalomlauf zu absolvieren, um den Schüssen auszuweichen. Doch im Rahmen unseres Review-Prozesses, intern \"Overwatch\" genannt, waren einige Testspieler frustriert, weil sie beschossen wurden und keine Möglichkeit zur Gegenwehr hatten. Sie wollten, dass sich das Luftboot kraftvoll und unaufhaltsam anfühlt. Basierend auf diesem Feedback haben wir die Level neu ausgerichtet, um den Schwerpunkt auf Stärke statt auf Herausforderungen zu legen. Statt Angriffen auszuweichen, ging es nun um rasante Kämpfe, Geschwindigkeit und das Durchbrechen von Barrieren."
N/A4013"#commentary\cn_100_mounted_gun.mp3" "[ Jeff Lane ] Die montierten Waffen wurden hinzugefügt, um Spieler auf die Wirksamkeit der Waffe gegen den Kampfhubschrauber für den finalen Kampf im Reservoir vorzubereiten. Dies war notwendig, da der Hubschrauber bis zu diesem Zeitpunkt durch die Waffen des Spielers unverwundbar war und wir einen Hinweis darauf geben mussten, dass er mit größeren Waffen beschädigt werden könnte. Dies war in den Spieltests aufgrund des Drucks, unter dem Spieler in diesem Moment standen, nur bedingt effektiv. Das veranlasste uns dazu, Partikeleffekte und Geräusche zu entwickeln, die den Spielern vermitteln würden, dass sie wirklich Schaden anrichten."
N/A4014"#commentary\cn_101_357_intro.mp3" "[ Josh Weier ] Anders als andere normale Handfeuerwaffen verfügt die Magnum über eine langsamere Feuerrate. Sie fügt Gegnern auf kalkulierte Art katastrophalen Schaden zu. Frühe Versionen der Magnum hatten ein randomisiertes Streumuster, das sich beim Drücken des Abzugs so gewichtig und unempfindlich anfühlte, wie wir das bei einer größeren Pistole erwarteten. Jedoch führte dies zu enttäuschenden Momenten, an denen der Spieler einen Schuss sorgfältig ansetzte und aufgrund der geringeren Genauigkeit verfehlte. Deshalb sorgten wir dafür, dass die erste Kugel 100 % genau war und jeder nachfolgende Schuss weniger genau wurde."
N/A4015"#commentary\cn_102_helicopter_bombing_run.mp3" "[ Brian Jacobson ] Dies ist ein weiteres Beispiel für unsere Bemühungen, für die Fahrt im Luftboot gefährliche Momente zu kreieren. Der Hubschrauber versucht, vor dem Spieler zu bleiben und Bomben abzuwerfen. Wenn der Spieler sich zurückzieht, wechselt er in den Schwebemodus und greift den Spieler an. In einem Spieltest fiel eine Bombe genau zwischen die Fugen des Rohrs und kreierte so einen filmreifen Moment. Der Testspieler reagierte so positiv, dass das Team sich dafür entschied, den Moment so zu programmieren, dass er jedes Mal auftrat. Dieser Prozess wurde ein Teil unseres organischen Designprozesses: Immer mal wieder passiert zufällig etwas so Cooles in einem Spieltest, dass wir einen Weg finden, diesen Moment öfter eintreten zu lassen."
N/A4016"#commentary\cn_103_smokestack_collapse.mp3" "[ Doug Wood ] Für den Fall, dass wir ein kinoreifes Actionspiel wie Half-Life entwickeln, wollten wir schon immer große, spektakuläre Zerstörungssequenzen kreieren, konnten dies bisher jedoch nicht erreichen. Die Physik von Half-Life 2 ermöglichte es, kleine Objekte wie Kisten in kleine Stücke zu zerbrechen. Folglich dachten wir an etwas Größeres. Wir versuchten es direkt mit einem Fabrikschornstein, der in kleine Stücke zerbrach und einstürzte. Dann experimentierten wir mit den Massen, bis es sich besser anfühlte, feilten am Modell und fügten viel Rauch und Sound hinzu, um den Effekt realistischer zu gestalten. Und voilà, da hatten wir unseren großen, spektakulären Zerstörungsmoment. Die Physik machte es gerade so möglich. Nach modernen Standards mag das drollig wirken, aber für uns war es damals fantastisch. Da die Simulation bei jeder Ausführung einzigartig war, mussten wir sicherstellen, dass der Pfad des Spielers nicht von großen Geröllbrocken versperrt wurde. Nach dem Erfolg dieser Sequenz waren wir auf der Suche nach noch realistischeren Physik-Zerstörungseffekten, wie sie dann in Episode 2 zu sehen waren."
N/A4017"#commentary\cn_104_washing_machine_puzzle.mp3" "[ David Speyrer ] Wir haben das Physikrätsel mit der Waschmaschine erst spät in der Entwicklung hinzugefügt, nachdem Spieltests gezeigt hatten, dass die Spieler eine Pause vom unerbittlichen Druck des Hubschraubers benötigten. Tempokontraste wie diese können die Höhepunkte betonen, indem sie den emotionalen Zustand des Spielers zurücksetzen und Erschöpfung oder sogar Langeweile verhindern. Es war ein positives Zeichen, dass Spieler so stark auf all die Arbeit reagierten, die wir geleistet hatten, um den Hubschrauber wirklich bedrohlich zu machen. Wenn der Stressfaktor allerdings konstant hoch ist, setzt Müdigkeit ein, die sich schnell eher wie Monotonie als wie Aufregung anfühlt. Ursprünglich bewegten sich Spieler schnell durch diesen Bereich, aber aufgrund des schönen Sonnenlichts und der Beschaffenheit des Kanals entschieden wir, dies war der richtige Ort, die Action zu unterbrechen und den Spielern ein kleines Rätsel an die Hand zu geben. Das Rätsel selbst, bei dem erstmals Gewichte und Flaschenzüge verwendet wurden, führte schließlich zu anderen Physiknavigationsrätseln an anderen Stellen im Spiel."
N/A4018"#commentary\cn_105_airboat_changeup.mp3" "[ Jeff Lane ] Das Feedback vieler Testspieler war, dass sie sich ein abwechslungsreicheres Gameplay mit dem Luftboot wünschten. Bis zu diesem Punkt im Spiel hatten Spieler keine wirkliche Möglichkeit, sich gegen den Hubschrauber und andere Feinde zu wehren. Es war also ein guter Zeitpunkt, eine neue Waffe einzuführen und das Tempo zu verringern, um die Bühne für Kommendes vorzubereiten. In den folgenden Bereichen haben wir Zielübungen hinzugefügt, um die Leute mit ihrer neuen Waffe vertraut zu machen. Zusätzliche physikalische Kraft auf die Luftboot-Geschützprojektile bedeutete, dass Ziele durch die Luft geschleudert wurden und sich das Luftboot-Geschütz viel mächtiger anfühlte als alles in der Ausrüstung des Spielers. Aber trotz allem hielten viele Tester den Hubschrauber immer noch für unverwundbar. Unsere Versuche, zu zeigen, dass der Hubschrauber zuvor durch die montierten Combine-Geschütze Schaden genommen hatte, waren wohl nicht offensichtlich genug. Um das zu verbessern, taten wir das Naheliegendste: Wir haben den Hubschrauber direkt vor den Tunnel gesetzt, in dem man das Geschütz erhält, und extrem deutlich gemacht, dass man auf ihn schießen soll. Und es hat funktioniert."
N/A4019"#commentary\cn_106_donkey_kong_barrel_ramp.mp3" "[ Eric Smith ] Dieser spezielle Bereich, die Abflussrampe, war ursprünglich nur ein interessanter Teil der Levelarchitektur. Doch beim Testen merkten wir schnell, wie viel Spaß es machte, mit dem Luftboot hier hoch und runter zu flitzen. Also fügten wir weitere Elemente hinzu, um das Erlebnis zu verbessern. Dazu gehörten beispielsweise Metrocops, die Fässer auf den Spieler herabwerfen – eine kleine Anspielung auf den Arcade-Klassiker Donkey Kong."
N/A4020"#commentary\cn_107_lambda_cache_interlude.mp3" "[ Danika Rogers ] Ein Half-Life-Spiel ist letztlich ein lineares Erlebnis, aber wir suchen immer nach Möglichkeiten, den Weg des Spielers zu unterbrechen und nicht-lineare Abläufe zu schaffen. Dieses Lambda-Lager, das durch einen Zombie- und Kopfkrabben-Hinterhalt ersetzt wurde, war völlig optional und wurde nur hinzugefügt, um diesem Abschnitt der Reise durch die Kanäle etwas weniger linear zu machen."
39904021"#commentary\cn_108_skybox_time_of_day.mp3" "[ Eric Kirchmer ] In diesem Kapitel änderten sich die Farben der Skybox und des Nebels graduell. Dies bedeutet, dass der Verlauf der Zeit während der Reise durch die Kanäle visuell repräsentiert wurde. Zwei Farbwerte des Nebels in entgegengesetzten Richtungen halfen dabei, die Illusion einer indirekten Sonneneinstrahlung zu erzeugen. Es wurde zu diesem Zeitpunkt deutlich, dass der Sonnenuntergang immer näherrückt. Das kulminiert in der Helikopterkampfarena mit dem Untergang der Sonne und Ravenholm sichtbar in der Skybox."
3991N/A"#commentary\cn_109_helicopter_megabomb_origin.mp3" "[ Brian Jacobson ] Der Megabombenangriff des Helikopters beruhte auf einem Fehler, bei dem der Programmierer versehentlich die Abklingzeit des Fallenlassens von Bomben entfernt hatte. Das führte dazu, dass der Helikopter Hunderte Bomben gleichzeitig abwarf. Das sah so cool aus, dass wir uns dazu entschieden, uns das für die letzte Bombenattacke aufzusparen."
3992N/A"#commentary\cn_124_pick_up_that_can.mp3" "[ Charlie Brown ] Die Kontextualisierung von Tutorials (die Erstellung eines Handlungsszenarios für diese) ermöglichte es uns, mehr zu erreichen, als nur das Spiel anzuhalten und dem Spieler etwas beizubringen. Es ist uns möglich, dem Moment einen narrativen Charakter zu verleihen. Spieler können hier nicht nur lernen, wie man Gegenstände wirft, sondern auch entscheiden, wie sie auf narrative Vorgaben reagieren wollen. Nachdem sie beobachtet haben, wie Metrocops Bürger nur so nebenbei misshandeln, fühlt es sich richtig an, die Spieler in eine ähnliche Lage zu versetzen. Wenn sie eine Meinung dazu haben, wie Bürger darauf reagieren sollten, können sie diese nun zum Ausdruck bringen. In Spieltests kamen Spieler entweder der Aufforderung nach, die Dose aufzuheben, oder weigerten sich. Einige versuchten jedoch, die Konfrontation insgesamt zu vermeiden. Andere fügten sich zunächst, rächten sich jedoch, nachdem sie sich gedemütigt fühlten. Durch die Einschränkung des Moments, sowohl für Spieleraktionen als auch für die Auswahl der Spieler, konnten wir auf jede beliebige Spielerwahl angemessen reagieren."
3993N/A"#commentary\cn_125_promises.mp3" "[ Danika Rogers ] Im Half-Life-Spiel war es früh unser Ziel, dem Spieler ein Gefühl dafür zu vermitteln, was er später erwarten kann. Alle großartigen Unterhaltungsmedien, von Filmen bis zu Fernsehshows und Büchern, tun dies auf die eine oder andere Weise. Videospiele sind da nicht anders. Die Versprechen in einem Half-Life-Spiel können unterschiedliche Formen annehmen. Manche sind einfach, um etwas Interessantes zu zeigen. Andere haben mehr Tiefe, wie die Interaktionen der Metrocops. Indem wir den Spieler in eine hilflose Position versetzen, bereiten wir den Moment vor, an dem er endlich zurückschlagen kann."
3994N/A"#commentary\cn_126_exploration.mp3" "[ David Sawyer ] Nachdem der Spieler von den Metrocops durch den Bahnsteig gescheucht wird, wollten wir dem Spieler eine Gelegenheit zur Erkundung geben. Dieser Platz bot mehrere Möglichkeiten, um mit Bürgern, Metrocops, Scannern und der Infrastruktur der Stadt zu interagieren. Wir wollten, dass diese Interaktionen die Welt ohne den Bedarf nach expliziten Tutorials vorstellen. Wir arbeiteten kontinuierlich daran, bis dies natürlich funktionierte, ohne echtes Training."
3995N/A"#commentary\cn_128_strider.mp3" "[ Doug Wood ] Dieser einfache Moment verspricht, dass Sie später im Spiel einem riesigen Ding begegnen werden. Selbst eine so unkomplizierte Szene wie diese musste wiederholt getestet werden und durchlief mehrere Iterationen, da Ziel für Half-Life darin bestand, dem Spieler nicht die Kontrolle zu entziehen. Wie Sie sich vorstellen können, sind viele kleine Anpassungen erforderlich, um sicherzustellen, dass so viele Spieler wie möglich zur richtigen Zeit am richtigen Ort sind. Der Straßenverlauf und die Metrocop-Szene sind alle so eingestellt, dass sie den Blick des Spielers lenken und den Strider perfekt einrahmen, wenn er erscheint."
3996N/A"#commentary\cn_129_physics_simulation.mp3" "[Jay Stelly] Obwohl wir Half-Life 2 mit einer funktionsfähigen Physiksimulation eines Drittanbieters begannen, brauchten wir Jahre zusätzlicher Arbeit an der Simulation und ihrer Integration, bis wir das Gefühl hatten, die Ambitionen unserer Designer erfüllen zu können. Wir wussten, dass es eine Herausforderung sein würde, ein lieferbares Qualitäts- und Leistungsniveau aufrechtzuerhalten, aber das subtilere Problem bestand darin, herauszufinden, was und in welchem Umfang simuliert werden sollte. Wir konnten nicht alles simulieren, und selbst wenn dies möglich gewesen wäre, gibt es Gründe im Spieldesign, dies nicht tun. In vielen Fällen verbiegen wir die Simulation absichtlich zur Verbesserung des Spielerlebnisses. Diese Anpassungen bleiben normalerweise unbemerkt, da sie den Absichten der Spieler entsprechen. Beispielsweise deaktivierten wir Kollisionen zwischen Spielern und großen Objekten, damit man sich in engen Bereichen umdrehen kann. Wir optimierten auch den alternativen Feuermodus des Combine-Gewehrs, um die Combine-Kugel sanft auf Gegner zu lenken und sie effektiver zu machen."
3997N/A"#commentary\cn_134_the_citadel.mp3" "[ Eric Kirchmer ] Wir wollten, dass Spieler zuerst die Zitadelle sehen, um ihre überwältigende Präsenz in der Stadt zu unterstreichen. Sie repräsentiert die vollständige und absolute Macht der Combine über die Menschheit. Sie dient auch als klar erkennbares Ziel – selbst am Anfang der Reise ist dem Spieler klar, wo sie enden wird. Trotz ihrer enormen Größe wurde sie oft von Spieltestern übersehen. Es ist schwierig, einem Spieler über einen Computerbildschirm ein Gefühl von Tiefe und für das Ausmaß zu vermitteln. Wenn Sie jemals ein VR-Spiel gespielt haben, werden Sie sicherlich bemerkt haben, dass sich dieses Gefühl für das Ausmaß deutlich natürlicher anfühlt. In diesem Fall jedoch war die Position der Zitadelle nicht wirklich hilfreich, da sie über dem Spieler schwebte. Dies könnte daran liegen, dass viele Ego-Shooter Spielern beibringen, nach vorn bzw. auf ihre Füße zu blicken. Um die Sichtbarkeit der Zitadelle für Spieler zu erhöhen, ließen wir Vögel auf die Struktur zufliegen – ein subtiler Trick, der den Blick von Spielern erfolgreich zum gewünschten Objekt führte."
3998N/A"#commentary\cn_135_close_captions.mp3" "[ Yahn Bernier ] Während der Entwicklung von Half-Life 2 kamen Leute mit dem Wunsch nach Barrierefreiheit auf uns zu und ermutigten uns dazu, über das von uns für Half-Life 1 entwickelte Untertitelsystem hinauszugehen. Sie fragten nach vollständigen Untertiteln für Hörgeschädigte, die alle Spielklänge und Dialoge aufzeichneten. Dies stellte eine deutlich größere Herausforderung dar als ursprünglich angenommen. Half-Life 2 produziert eine Vielzahl von Geräuschen und es war essenziell, diese für die Untertitel für Hörgeschädigte zu kategorisieren. Folglich war die Priorisierung der Schlüssel zum Erfolg: Dialoge sollten hervorstechen und es musste klar sein, wer spricht. In einigen Bereichen spielten Umgebungsgeräusche eine wichtige Rolle für die Stimmung, jedoch weniger als ein in der Nähe schießender Gegner. Unsere Leveldesigner verwendeten auch viele Geräusche in unterschiedlichen Kontexten wieder, sodass ein Klang in einem Gebiet Untertitel für Hörgeschädigte benötigen konnte, aber nicht in einem anderen. Am Ende erhielt jedes Geräusch im Spiel eigene Untertitel für Hörgeschädigte, die in einer Art Miniaturversion von HTML formatiert waren und uns mehr Kontrolle über den visuellen Stil jedes Untertitels gaben. Die Untertiteldateien waren ebenso wie die Audiodateien zu groß, um sie im Arbeitsspeicher halten zu können. Aus diesem Grund entwickelten wir ein asynchrones Zwischenspeichersystem, um diese effizient handhaben zu können."
3999N/A"#commentary\cn_157_kleiners_lab.mp3" "[ Marc Laidlaw ] Kleiners Labor war der erste Handlungsstrang, an dem wir mit der Arbeit begannen. Deshalb dauerte es auch am längsten, es zu realisieren. Das Labor führte Spieler nicht nur in das Spiel ein, sondern wurde auch zu einer verbindenden Vision für die Entwickler hinsichtlich der Geschichtserzählung. Als wir mit der Entwicklung unserer Charaktere und der narrativen Übermittlung von Informationen mit dem Spieler im Zentrum begannen, stellten sich zahlreiche Fragen, die erhebliche Risiken für das Spiel aufwarfen. Ist es Spielern möglich, die wichtigsten Informationen aus jeder Szene zu extrapolieren? Ist es uns möglich, sie dazu zu bewegen, sich mit diesen Charakteren zu identifizieren? Wie können wir Spieler mit wechselndem Interesse an der Handlung unterstützen? Wie hoch wären die Produktionskosten einer solchen Szene? Und wie viele würden wir benötigen? Wir konnten diese und viele weitere Fragen erst beantworten, nachdem wir einen ausreichenden Anteil der Szene erstellt und diese mit vielen Spieltestern getestet hatten. Im Gegensatz zu vielen anderen Problemen, mit denen wir konfrontiert waren, konnten wir diese Fragen erst nach Abschluss umfangreicher Arbeiten beantworten. Unsere Gameplay-Ideen konnten wir häufig mit niedrig-qualitativen Prototypen testen, jedoch fühlten sich Spieler nicht in unsere Geschichte hineingezogen, wenn die Charaktere nur graue Blöcke waren. Wie wahrscheinlich war es also, dass sie sich für die Charaktere interessieren würden, sobald diese vollständig ausgebaut waren?"
4000N/A"#commentary\cn_160_animation.mp3" "[ Miles Estes ] Die Erstellung von glaubhaften menschlichen Bewegungen aus vielen einzelnen Animationsebenen für unsere Charaktere erforderte zur Verbesserung viele technologische Wiederholungen. Selbst einfache Aktionen wie Umdrehen, um sich etwas anzuschauen oder zu einer Stelle zu gehen, waren komplizierter, wenn sie mit dem Bedürfnis nach dynamischer Reaktion auf den Spieler und der Anforderung nach choreografierten Befehlen verbunden waren. Wenn sich beispielsweise ein Charakter umdreht, um etwas anzusehen, musste dies vollständig auseinandergenommen werden, damit der Charakter eine Kombination aus Augen, Kopf, Schultern, Oberkörper oder vollständigem Körper verwenden konnte, um sich dem Ziel zuzuwenden. In Half-Life 1 waren die Menschen in zwei Hälften aufgeteilt, was ihnen ermöglichte, in eine Richtung zu gehen und gleichzeitig in eine andere Richtung zu blicken. Dieser Ansatz war jedoch zu abstrakt für die Charaktere von Half-Life 2. Unsere Animatoren kreierten stattdessen Laufanimationen in allen acht Kompassrichtungen, die dann während der Laufzeit nahtlos ineinander überblendet wurden."
4001N/A"#commentary\cn_161_faceposer.mp3" "[ Yahn Bernier ] Das Hauptwerkzeug, das wir mithilfe des Choreografie-Systems erstellten, war FacePoser, ein ungenau benanntes Programm, das es unseren Animatoren ermöglichte, die gesamte Struktur unserer Szenen auf einer Zeitleiste darzustellen. Die Zeitleiste enthielt eine Reihe von choreografierten Befehlen für Akteure, neben allen notwendigen Informationen über sie zur Ausführung dieser Befehle. Durch die Überlagerung dieser Befehle auf der Zeitleiste konnten die Animatoren einfach beschreiben, wie ein Akteur beispielsweise auf etwas blickt, während er mit einem anderen Akteur spricht und dabei gleichzeitig eine andere Richtung einschlägt. Die Zeitleiste war jedoch keine fixe, lineare Sequenz. Die Akteure folgten zwar ihren Befehlen, konnten aber dynamisch auf ihre Umgebung reagieren. Ein Akteur könnte z. B. länger benötigen, um an einen Ort zu gelangen, wenn der Spieler im Weg steht, oder länger warten, um etwas zu sagen, wenn ein anderer Akteur vom Spieler aufgehalten wird. FacePoser ermöglichte es uns, Szenen zügig zu durchlaufen und zu verbessern sowie verschiedene Layouts, die Art der Kommunikation und das Timing zu überprüfen. Diese Möglichkeit, schnell Experimente durchzuführen und anzupassen, war kritisch, um die richtige Mischung für unsere Charakter- und narrativen Ziele zu finden."
4002N/A"#commentary\cn_163_antlions.mp3" "[ Kerry Davis ] Da der Spieler mit dem Buggy die Küste entlangfährt, benötigten wir einen allgegenwärtigen Feind, der berechtigterweise überall auftauchen und als konstante Bedrohung dienen konnte, um den Spieler in der Nähe oder im Buggy zu halten. Die perfekte Lösung waren aus dem Sand auftauchende Ameisenlöwen. Anders als humanoide Feinde waren sie dank ihrer hohen Mobilität in der Lage, kurzfristig mit dem Buggy Schritt zu halten. Außerdem war es ein befriedigendes Erlebnis, sie zu überfahren."
4003N/A"#commentary\cn_164_thumpers.mp3" "[ Adrian Finol ] Es ist von großer Bedeutung, dem Spieler das Gefühl zu vermitteln, dass er, wann immer möglich, etwas über sich herausgefunden hat. Dies führt zu einer lebendigeren Welt, statt eine Reihe von Gameplay-Elementen für den Charakter aneinanderzureihen. Sollte es akzeptabel sein, dass ein Prozentsatz von Spielern ein Element vollständig verpasst, können wir einen subtileren Ansatz wählen. Wir wählten diesen Ansatz für die Rammen und entwarfen Szenen, in denen Spieler wahrscheinlich mit dieser interagieren würden, ohne dazu gezwungen zu sein. Viele audiovisuelle Hinweise und Reaktionen der Ameisenlöwen halfen dem Spieler, die Situation zu verstehen. Das war keine Garantie, dass alle Spieler es herausfinden würden. In Spieltests fanden es aber die meisten heraus."
4004N/A"#commentary\cn_165_d2_coast_09.mp3" "[ Aaron Seeler ] Unser Spielcode war spät in unserer Entwicklung von Lost Coast dem Leveldesign so weit voraus, dass unsere Gameplay-Programmierer nach weiterem Code zum Schreiben und neuen Aufgaben suchten, um Half-Life 2 zur Veröffentlichung zu verhelfen. Dies war hauptsächlich auf die Anforderungen an die Levels für Lost Coast zurückzuführen, da sie aufgrund des schieren Maßstabs und der Reichweite des genutzten Terrains viel von unseren Leveldesignern abverlangten. Deshalb designten unsere Gameplay-Programmierer kleine Begegnungen. Später, als unsere Leveldesigner aufgeholt hatten, kreierten sie mit diesen ein Level, das aus drei separaten Begegnungen der Programmierer zusammengesetzt war, und konnten alle notwendigen Arbeiten abschließen, um das Spiel für die Veröffentlichung vorzubereiten."
4005N/A"#commentary\cn_166_final_scene.mp3" "[ Bill Van Buren ] Die Entscheidung, den Spieler für die letzte Konfrontation in Breens Büro in eine Kapsel zu sperren, ermöglichte es uns, uns auf Charaktere zu konzentrieren, auf die wir sonst den Fokus nicht hätten legen können. In dieser Szene erreicht jeder Charakterhandlungsstrang seinen Höhepunkt. Die Einschränkung des Spielers zu diesem Zeitpunkt ermöglichte es uns, durch Kombination des Dialogs mit den herausragenden Leistungen der Synchronsprecher und Animationen einen wahren emotionalen Höhepunkt zu schaffen. Die Szene war aus dem Blickwinkel der Produktion eine Herausforderung: Sie benötigte die richtige Mischung aus Blockieren und Bewegungen, gepaart mit effektivem Timing und emotionaler Synergie sowie die Verknüpfung aller einzelnen Animationen mit den separat aufgenommenen Leistungen der Synchronsprecher. Es bedurfte einer sorgfältigen Abstimmung, bevor wir eine gewisse Dramatik erreichen und den Eindruck erwecken konnten, dass alle Charaktere tatsächlich miteinander verbunden waren."
4006N/A"#commentary\cn_167_end_game_scramble.mp3" "[ Dave Riller ] Ursprünglich war eine größere Choreografie für das Ende des Spiels geplant. Das Choreografie-Team war jedoch äußerst beschäftigt mit der riesigen Menge an Arbeit für die Erzählung der Geschichte, die noch im gesamten Spiel benötigt wurde. Um Ihnen ein wenig Arbeit zu ersparen, baten wir den Verschwörerzirkel für das Zitadellen-Gameplay, stattdessen eine Herausforderung für das Gameplay für das Ende des Spiels zu entwickeln. Es spielte dabei keine Rolle, ob es sich um ein Puzzle, einen Kampf oder etwas anderes handelte. Dies führte zu einem Endbosskampf mit Breen, der die Spielmechanik des existierenden Super-Gravitrons nutzte und nur ein wenig benutzerdefinierte Choreografie benötigte, um in einer kurzen Zeit ein fertiges Produkt zu erstellen."
4007N/A"#commentary\cn_169_citadel_entrance.mp3" "[ Jeff Lane ] Die Route zur Zitadelle wurde rückwärts erstellt: Die innere Geometrie wurde als Teil eines Artwork-Prototyps erstellt, um das Aussehen zu optimieren. Wir wussten, dass der Spieler über ein Abwasserrohr in unserer Streetwar-Karte hineingelangen würde. Aus diesem Grund mussten wir einen Bereich mit Rutschen und Sprüngen zum Eingang der Zitadelle kreieren, der diese miteinander verband."
4008N/A"#commentary\cn_177_breen_monologue.mp3" "[ Marc Laidlaw ] Kreative Arbeiten entstehen nicht in einem Vakuum, da wir alle von anderen Dingen inspiriert werden. Breens Monolog hier auf den Monitoren der Zitadelle wurde von einem früheren, von uns allen geliebten Spiel inspiriert: Thief 2. Darin verspottet der Antagonist den herumschleichenden Spieler. Die Durchführung war zwar anders, aber die Kerninspiration ist weiterhin vorhanden. Die herausragende Leistung des verstorbenen Robert Culp ist es, die diesen Moment so richtig zur Geltung bringt. Seine Darbietung war perfekt. Seine Interpretation von Breens Monolog war so feinsinnig, dass sie dem Charakter auf dem Papier ein einzigartiges Leben einhauchte. Eine Aufnahmesitzung mit Robert Culp war unglaublich einfach, da er das Skript hatte und der Toningenieur nur aufnehmen musste. Das war’s. Die Lektion, die wir hier betonen, ist, mit talentierteren Leuten als Sie zu arbeiten, von denen Sie sicherlich etwas lernen werden. Lassen Sie sich nicht von einer festen Vorstellung davon leiten, wie die Zeilen übermittelt werden sollten oder wie ein bestimmter Moment ablaufen sollte. Kollaborieren Sie stattdessen mit talentierten Leuten und vertrauen Sie darauf, dass sie es besser machen werden."
4009N/A"#commentary\cn_178_dissolved_weapons.mp3" "[ Quintin Doroquez ] Alle Combine-Waffen waren darauf ausgelegt, sich aufzulösen, nachdem Combine-Soldaten in Ragdolls verwandelt wurden. Erstens wollten wir verhindern, dass Spieler diese Waffen aufheben und verwenden. Zweitens führte dies zu einer Verbesserung der Leistung auf diesen Karten. Zusätzlich wurde ein Ragdoll-Manager hinzugefügt, der die fallenden Soldaten-Ragdoll-Leichen entfernt, sobald der Spieler fortfährt."
4010N/A"#commentary\cn_179_elevator_fight.mp3" "[ Brian Jacobson ] Obwohl wir wollten, dass der Spieler sich allmächtig fühlt, konnten wir der Versuchung nicht widerstehen, einen harten Kampf zum Aufzugsschacht hinzuzufügen. Der Kampf um die Ankunft des Aufzugs gestaltete sich als schwieriger, als wir es ursprünglich für diesen Teil des Spiels vorgesehen hatten. Während der Spieltests wurde er einfacher, jedoch hatten wir nicht ausreichend Zeit, um den Kampf auf das richtige Maß auszubalancieren. Obwohl der Spieler nie wirklich ernsthaft gefährdet ist, macht die schiere Anzahl an Soldaten diese Begegnung zum ultimativen Kampf."
4011N/A"#commentary\cn_180_replacing_the_prefabs.mp3" "[ Jeff Lane ] Die Combine-Energiebälle sind sehr einfach aufgebaut: sie bestehen aus einem Kraftfeld, das ständig hüpfende Objekte enthält. In Spieltests führten die umherspringenden Energiebälle jedoch zu wiederholten Fehlern. Außerdem entwickelten sie ein unerwünschtes Eigenleben und „entkamen“ dem Kraftfeld, das sie eingegrenzt halten sollten. Aufgrund der Einschränkungen unserer damaligen Prefab-Technologie war es notwendig, die Energiebälle mehrfach manuell zu erstellen: an jedem Ort jedes Zitadellen-Levels, das diese enthielt, neu."
4012N/A"#commentary\cn_181_strider_fight.mp3" "[ Ted Backman ] In einem der Prototypen der Zitadelle konnten Spieler einen Strider mit dem Super-Gravitron greifen. Im Kampf gegen den Strider ging es lange Zeit darum, nahe genug heranzukommen, um ihn mit dem Super-Gravitron zu fassen. Gegen Ende der Entwicklung entschieden wir jedoch, dass die Möglichkeit, Strider mit dem Super-Gravitron zu greifen, diese schwächte, insbesondere nach all den Kämpfen gegen sie während Street War. Aus diesem Grund ersetzen wir diese Begegnung durch eine, in der Spieler einen Strider mit Combine-Bällen töten. Modell-Teile wurden hinzugefügt, um den Strider zu zerreißen und zu sprengen, statt dessen Körper herumzuzerren. Dies ist das einzige Mal im Spiel, in dem ein Strider diesen Effekt hat."
4013N/A"#commentary\cn_182_getting_in_the_pod.mp3" "[ Dhabih Eng ] Die hier beginnende Kapselaufstiegssequenz erforderte unsere volle Kontrolle über die Szene und den Spieler. Dies steht im Widerspruch zu unserem normalen Bedürfnis, dem Spieler so viel Kontrolle wie möglich zu geben. Wir haben jedoch das Gefühl, dass der Kompromiss es für diesen letzten Schritt wert war. Zu diesem Zeitpunkt war der Spieler derart mächtig, dass es schwierig war, ihn zu kontrollieren. Aus diesem Grund mussten wir ihn außer Gefecht setzen. In der Szene gibt es noch immer Charaktere, die mit dem Spieler kommunizieren und seine Aufmerksamkeit auf sich lenken. Wir erzählen auch auf dem Weg etwas über die Umgebung. Die hier beginnende Zugfahrt durch die Zitadelle zeigt einige Gegner, für die wir zwar Artwork hatten, aber aus dem Hauptteil des Spiels entfernt werden mussten. Aus der Sicherheit Ihrer gemütlichen Kapsel können Sie die Manufaktur der Stalker beobachten und einen kurzen Blick auf den Krabben-Synth werfen."
4014N/A"#commentary\cn_183_turrets.mp3" "[ Mike Dussault ] Türme waren ein hilfreiches Designmittel, wenn Spieler Käfer-Köder besaßen, um zu verhindern, dass Ameisenlöwen direkt auf sie zulaufen. So konnten wir Situationen schaffen, in denen Spieler nicht einfach zum Fortfahren Käfer-Köder werfen konnten. Sie mussten die Türme umgehen, um sie zerstören zu können, damit ihnen die Ameisenlöwen folgen konnten. Außerdem sah es gut aus, wenn der Turmbeschuss die Ameisenlöwen niedermähte."
4015N/A"#commentary\cn_184_grenade_puzzle.mp3" "[ Aaron Seeler ] In vielen Spielen blieben Spieler stecken, da sich die Kiste mit den unbegrenzten Granaten auf dem Pfad hinter ihnen befand. Zu diesem Zeitpunkt im Spiel hatten Spieler bereits gelernt, Kisten mit unbegrenzter Munition mit Rätsellösungen zu assoziieren. Beim Anblick einer Kiste mit Granaten würden Spieler sofort erkennen, dass sie zur Lösung des Problems Granaten einsetzen müssen. Wir wollten, dass sie erst einmal etwas nachdenken müssen. Letztlich wiesen wir durch die Platzierung von Granaten auf einem Schreibtisch hinter einem Fenster subtil auf ihre Verfügbarkeit hin. Hierdurch entdeckten wir in einem Spieltest auch einen Fehler, durch den Spieler die Granaten durch das Glas hindurch aufsammeln konnten, wenn sie nur nah genug herangingen."
4016N/A"#commentary\cn_236_ravenholm_development_2.mp3" "[ Tom Leonard ] Wenn Fans mit uns über Half-Life 2 sprechen, ist Ravenholm oft der Bereich, der am meisten in Erinnerung geblieben ist. Dank der vielen Entwicklungsdurchläufe und der Materialdichte in Ravenholm konnten mehr Teammitglieder darin repräsentiert werden als überall sonst. Ravenholm ist der Bereich, in dem wir herausfanden, wie wir unsere künstlerische Pipeline auf die Szenenmodelle und die gewünschte Stimmung anwenden können, wie die Physik und das Gameplay mit dem Gravitron zusammenwirken, wie Kopfkrabben und Zombies sich für Half-Life 2 weiterentwickeln müssen und vieles mehr. Wenn wir jetzt darauf zurückblicken, bestätigt es unseren Glauben daran, Einzelne dazu zu ermächtigen, sich mit ihren Visionen über ein zentralisiertes Design hinwegzusetzen. Das dichte und hocheffiziente Gameplay und die künstlerische Umsetzung von Ravenholm basieren auf vielen kleinen Beiträgen Einzelner, die ihre Vision mit ihren eigenen einzigartigen Fähigkeiten weiter vorantreiben konnten."
4017N/A"#commentary\cn_237_playtester_archetypes.mp3" "[ Tom Leonard ] Für die Entwicklung von Half-Life 2 spielten kontinuierliche Verbesserungen und regelmäßige Spieltests eine entscheidende Rolle. Jede Woche beobachteten wir still Spieler beim Durchspielen unserer aktuell in der Entwicklung befindlichen Bereiche und notierten uns, was funktionierte und was nicht. Wir testeten mit Spielern verschiedener Spielstärken, um sicherzustellen, dass wir keine Entscheidungen trafen, die nur für einige Spieler funktionierten. Im Laufe der Zeit lernten wir, basierend auf der aktuellen Entwicklungsstufe, spezifische Spieltester auszuwählen. Im ersten Schritt setzen wir erfahrene Spieler ein, üblicherweise Teammitglieder, die keine Schwierigkeiten mit groben, unfertigen Bereichen hatten und in der Lage waren, ihren Gedankengang zu erläutern. Zum Testen des Kampfs fanden wir Spieler aller Spielstärken, insbesondere solche, die die Werkzeuge kreativ einsetzten. Am Ende der Entwicklung, beim Feinschliff der Bereiche, konzentrierten wir uns auf Anfänger – Leute, die selten Spiele spielten oder nicht mit Ego-Shootern vertraut waren. Obwohl sie das Spiel nicht unbedingt kaufen würden, lernten wir oft etwas Wichtiges beim Zuschauen solcher Spieler. "
4018N/A"#commentary\cn_256_citizen_squads.mp3" "[ Ken Birdwell ] Bei unseren ersten Tests mit Straßenkämpfen zwischen Combine und Zivilisten sind wir auf ein Problem gestoßen – ohne Grenzen konnte sich die Kampf-KI um einiges vom Spieler entfernen. Soldaten konnten sich also zurückziehen, um nachzuladen oder in Deckung zu gehen, und die KI für Zivilisten nahm die Verfolgung auf. Wir wollten jedoch die Handlungen der Zivilisten besser auf die Ziele des Spielers abstimmen. Sie sollten stets wissen, wohin der Spieler sich bewegen und welche Feinde er angreifen wollte. Wir entwickelten daraufhin eine Truppe von Zivilisten. Die KI sorgte dafür, dass sich diese Truppe mit dem Spieler bewegte und dieselben Feinde angriff. Gleichzeitig stellte sie eine grundlegende Schnittstelle für Befehle des Spielers dar. Zu Beginn verfügten wir über ein komplexes Befehlssystem, doch dies stellte sich als unhandlich heraus und wir schraubten es dementsprechend zurück."
4019N/A"#commentary\cn_257_ai_behaviors.mp3" "[ Mike Dussault ] Zu der für Half-Life 2 entwickelten KI-Technologie gehört auch das Verhaltenssystem. Dieses war Teil des KI-Spielcodes, der in bestimmten Situationen das Verhalten von NPCs bestimmte. Wir hatten zum Beispiel ein Führungsverhalten, mit dem ein NPC den Spieler leiten konnte, und ein Folgeverhalten, mit dem ein NPC dem Spieler oder einem anderen NPC folgen konnte. Verhaltensweisen arbeiteten parallel zum grundlegenden Verhalten von NPCs. So wusste ein Sanitäter, der das Folgeverhalten nutzte, um mit dem Spieler Schritt zu halten, immer, wie er auf Feinde schießen, Granaten ausweichen oder Erste Hilfe anbieten konnte."
4020N/A"#commentary\cn_271_3d_skybox.mp3" "[Jay Stelly] Teil unserer Entwicklungen war es immer, eine Welt zu rendern, die sich größer anfühlt, als es unsere Kartenbeschränkungen zulassen. In Half-Life 1 verwendeten wir kubische Umgebungskarten, damit die Spieler über den spielbaren Bereich hinaus sehen konnten. In Half-Life 2 wollten wir jedoch, dass dieser Blick in die größere Welt dynamisch ist und nicht nur eine statische Textur besitzt. Unsere Kartengrößenbeschränkung lag bei etwa einer halben Meile in jeder Dimension, aber wir erkannten, dass wir eine viel größere Außenwelt erstellen könnten, wenn wir sie in einem kleineren Maßstab speichern würden. Also erfanden wir die sogenannte 3D-Skybox. Die 3D-Skybox ist eine kleine Box, die in der eigentlichen Spielkarte versteckt ist und Geometrie im Maßstab 1:16 enthält. Darin entspricht ein Referenzpunkt einem entsprechenden Ursprung in der Hauptkarte. Wenn wir dann den Raum jenseits des spielbaren Bereichs rendern, verwenden wir die Geometrie aus der 3D-Skybox, die an diesem Referenzpunkt positioniert und 16-mal vergrößert wird. Es war eine Herausforderung, Licht und Nebel beim Übergang von der Hauptkarte zur Skybox nahtlos ineinander übergehen zu lassen, aber es hat funktioniert. Das Ergebnis war, dass die Welt deutlich größer und immersiver wirkte als in Half-Life 1."
4021N/A"#commentary\cn_279_combine_gunship.mp3" "[ Ken Birdwell ] Das Kampfhubschraubermodell war ein interessantes Problem. Wir hatten bereits ein Hubschrauberflugmodell und nicht wirklich Zeit, etwas völlig Neues zu bauen. Also haben wir das Flugmodell des Hubschraubers so lange optimiert, bis es sich anders genug anfühlte, und dann den natürlichen Animationszustand des Kampfhubschraubers aus den Werten abgeleitet, die aus dieser Simulation hervorgingen. Wir haben auch versucht, es so wahrheitsgetreu wie möglich zu halten. Es gibt insbesondere eine Grenze dafür, wie weit er seinen Kopf drehen kann, um seine Kanone auszurichten. Wenn er weiter zielen will, muss er seine Flugroute anpassen, um die Kanone zum Anschlag zu bringen – es ist nicht erlaubt, einfach zu schummeln. Ein weiteres wichtiges Merkmal war sein Motorengeräusch. Wir haben eine räumliche Klangdarstellung, sodass der Spieler ungefähr sagen kann, wo er sich befindet. Aber das Kampfhubschraubermodell ist ein sich schnell bewegendes Objekt, und es befindet sich in der Luft, weit entfernt von allen nahegelegenen Bezugspunkten. Daher kann es schwierig sein, genau zu sagen, wie weit der Hubschrauber entfernt ist und wie schnell er sich bewegt. Um das zu beheben, haben wir dem Motorengeräusch einen Dopplereffekt hinzugefügt, der die Tonhöhe je nach Geschwindigkeit des Kampfhubschraubers relativ zum Spieler ändert. Es ist ein subtiler Effekt, aber er ist äußerst effektiv, um Spielern unterbewusst zu helfen, die Position und Richtung des Kampfhubschraubers wahrzunehmen. Wichtige Informationen, die dem Spieler mitteilen, dass er vom Hubschrauber gejagt wird."
4022N/A"#commentary\cn_285_reference_maps.mp3" "[Randy Lundeen] Da unsere Charaktere beginnend mit Half-Life 1 bis zu Half-Life 2 immer lebensnaher wurden, wollten wir, dass sich die Spielwelt genauso realistisch anfühlt. In Half-Life 1 war es aufgrund der Einschränkungen von Ego-Shootern oft einfacher, sich auf stilisierte oder abstrakte Umgebungen zu stützen. Aber mit Half-Life 2 haben wir uns vorgenommen, eine Umgebung zu schaffen, die sich in der Realität verankert ist, was bedeutete, dass wir uns auf viele kleine Details konzentrieren mussten, die wir vorher nicht hatten. Einer unserer wichtigsten Schritte bestand darin, Referenzkarten zu erstellen, um zu standardisieren, wie wir die Proportionen der realen Welt im Spiel abbilden. Auf diesen Karten wurden Details wie Wand- und Türmaße, Türklinkenhöhen, Innenbeleuchtung, Möbelmaßstab und der allgemeine Maßstab gängiger Objekte festgelegt. Wir erstellten standardisierte Texturen für Leveldesigner, komplett mit Maßstabs- und Beleuchtungswerten, sodass die Layouts von Anfang an einheitlich waren. In diesen Referenzkarten wurde nicht nur die physische Welt eingerichtet, sondern auch festgelegt, wie sich der Spieler darin bewegen würde — wie hoch er springen konnte, wie tief er sich ducken konnte und welche Abmaße Räumlichkeiten wie Lüftungsschächte haben. Basierend auf diesen Karten waren wir in der Lage, die Geometrie unserer Welt konsistent zu halten und überall im Spiel für Räume mit realistischer Größe zu sorgen."
4023N/A"#commentary\cn_286_response_rules.mp3" "[ Scott Dalton ] Wir wussten schon früh, dass wir viel dynamischen Dialog im Spiel haben wollten. Daher benötigten wir ein entsprechend effektives System, das es den Sounddesignern ermöglichte, Zeilen hinzuzufügen und zu optimieren, ohne Programmierer einzubeziehen. Außerdem mussten Dialoge eng an das aktuelle Gameplay angepasst und Wiederholungen minimiert werden. Mit diesen Anforderungen entwickelten wir das Response-Rules-System. Immer wenn ein Charakter außerhalb einer choreografierten Szene spricht, bestimmt dieses System, welche Zeile gesprochen wird. Anstatt Zeilen direkt aufzugreifen, markiert die KI den Charakter bei relevanten Ereignissen mit „Gelegenheiten zum Sprechen“. Zu diesen Ereignissen gehören die Entdeckung des Spielers, eine Verletzung, der Gebrauch der letzten Kugel einer Waffe, eine Begegnung mit übermächtigen Feinden usw. Jedes Ereignis sendet dem Response-Rules-System ein Datenpaket über den aktuellen Stand des Spiels, und das System gibt die am besten passende Dialogzeile zurück (insofern vorhanden). Dank dieser Einstellung konnten unsere Sounddesigner eine detaillierte Entscheidungsmatrix für Dialoge erstellen. Ein Charakter kann auch je nach Situation andere Dialogoptionen haben. Der Text während des Nachladens unter Beschuss unterscheidet sich also vom Text nach dem Kampf, wenn nur noch ein Verbündeter übrig ist oder wenn ein Strider in Sicht ist. Als wir Half-Life 2 auslieferten, hatten wir das Gefühl, dass wir das Potenzial dieses Systems noch längst nicht ausgeschöpft hatten. Es wurde zu einem Kernmerkmal von Alyx aus Episode 1 und trieb dynamische Dialoge in unseren späteren Spielen voran, darunter die Klassen von TF2 und die Besetzung von Left 4 Dead."
4024N/A"#commentary\cn_287_audio_caching.mp3" "[Yahn Bernier] Ein weiteres Problem war die enorme Menge an Audiodaten im Spiel. 2003 war Speicherplatz sehr begrenzt und mit all den Gameplay-Geräuschen, der Musik und den Dialogen hatten wir einfach zu viel Audio, um es speichern zu können. Nichtsdestotrotz musste das entsprechende Gameplay-Audio sofort abgespielt werden, da es Spielern wichtige Informationen vermittelte. Also entwickelten wir einen Audio-Cache, in dem nur die ersten 125 Millisekunden jeder Audiodatei gespeichert wurden. 125 Millisekunden waren unsere beste Schätzung dafür, wie lange es dauerte, bis wir eine Audiodatei von der Festplatte streamen konnten. Während des Gameplays spielten wir dann den Anfang des jeweiligen Audios aus unserem Audio-Cache ab und warfen gleichzeitig die gesamte Audiodatei von der Festplatte dazu. Die Datei aus dem Cache konnte so nahtlos in die Datei der Festplatte übergehen und das gesamte Audio ohne Unterbrechung für den Spieler abspielen. Zusätzlich gab es noch einige kleinere Funktionen. So wurde z. B. aktuelles Audio vollständig im Speicher gespeichert, damit anderes, das System stärker belastenderes Audio nicht ständig geladen werden musste. Heutige Engines verwenden denselben Ansatz und nicht nur, was das Audio angeht."
N/A4022"#commentary\cn_109_helicopter_megabomb_origin.mp3" "[ Brian Jacobson ] Der Megabombenangriff des Helikopters beruhte auf einem Fehler, bei dem der Programmierer versehentlich die Abklingzeit des Fallenlassens von Bomben entfernt hatte. Das führte dazu, dass der Helikopter Hunderte Bomben gleichzeitig abwarf. Das sah so cool aus, dass wir uns dazu entschieden, uns das für den letzten Bombenangriff aufzusparen."
N/A4023"#commentary\cn_110_helicopter_final_battle.mp3" "[ Dave Riller ] Wir haben diesen Bereich als Arena für den finalen Showdown zwischen dem Spieler und dem Combine-Kampfhubschrauber entworfen. Hier hat der Spieler die Chance, den unerbittlichen Feind, der ihn seit seiner Flucht aus Kleiners Labor in den Untergrund verfolgt, endgültig auszuschalten. Dieser Bereich wurde oft überarbeitet. Wir benötigten ausreichend Platz für rasante Fahrzeugkämpfe, einen reibungslosen Bewegungsfluss mit klaren Wegoptionen und eine zuverlässige Performance. Außerdem wollten wir eine klare Optik, die für den Kampf geeignet ist – auffällig, aber nicht zu laut –, und gleichzeitig dafür sorgen, dass der Anblick nach der Zerstörung des Hubschraubers im Gedächtnis bleibt."
N/A4024"#commentary\cn_111_airboat_wreckage.mp3" "[ David Speyrer ] Ursprünglich sollte das Luftboot beim Sprung über den Damm zerstört werden, sodass der Spieler zu Beginn dieses Levels inmitten der Trümmer seines geliebten Luftboots stand. Bei einem teamweiten Spieltest waren die Spieler aber enttäuscht, das Fahrzeug zu verlieren, in dem sie so viel Zeit verbracht hatten. Es gab viele interne Diskussionen darüber, ob dieses Verlustgefühl eine wertvolle Erfahrung war oder nicht. Letztendlich entschieden wir uns, das Luftboot intakt zu lassen, um dem Spieler die Möglichkeit zu geben, es eines Tages wiederzufinden. Manche sagen, das Luftboot wartet immer noch irgendwo da draußen."
N/A4025"#commentary\cn_112_arena_exit_gate.mp3" "[ Quintin Doroquez ] Der Radmechanismus zum Öffnen des Ausgangstors wurde extra hinzugefügt, um den Spieler zu zwingen, den Helikopter zu besiegen, bevor er weiterkommt. Wir bezeichnen solche Elemente oft als \"Gating\" – wir verwenden dabei Designelemente, um Spieler am Weiterkommen zu hindern, bis sie eine notwendige Aufgabe erledigt haben. Hier handelt es sich im wahrsten Sinne des Wortes um ein \"Gate\", also Tor."
N/A4026"#commentary\cn_113_blocking_tutorials.mp3" "[ Adrian Finol ] Manchmal müssen wir sichergehen, dass der Spieler etwas gelernt hat. Die Standardmethode — zumindest in der Spieleentwicklung, nicht im Leben — besteht dabei darin, ihn hinter einer Art Tor gefangen zu halten, wo der Spieler sein Wissen unter Beweis stellen muss, um weitermachen zu können. Wir versuchen, diese Tore als etwas Natürliches zu tarnen, damit es sich nicht so anfühlt, als wäre das Spiel zum Stillstand gekommen. Natürlich können Zeit, Ressourcen oder die Umwelt das schwierig machen. In diesem Fall mussten wir den Spielern beibringen, wie man Objekte bewegt, also schien ein einfaches Stapelrätsel die beste Lösung zu sein. Wir haben komplexere Designs getestet, aber am Ende waren sie weniger effektiv darin, dem Spieler das zu vermitteln, was er eigentlich lernen sollte."
N/A4027"#commentary\cn_114_natural_storytelling.mp3" "[ Bill Van Buren ] Um unsere Ziele hinsichtlich des Aufbaus der Welt und des Storytellings im gesamten Bahnhof zu erreichen, brauchten wir eine natürliche Möglichkeit, Dialoge abzuliefern, ohne dass diese zu \"spielerisch\" wirkten oder Tutorials erforderlich waren. Uns fiel auf, dass Spieler oft auf NPCs zugingen, um sie genauer zu betrachten, also nutzten wir dies als eine Gelegenheit für die NPCs, den Spieler zu begrüßen und ihre Texte zu sagen. Dadurch blieben die Interaktionen unaufdringlich, was wichtig war, da die Zivilisten nicht gerade allzu fröhlich oder lebhaft sind. Die Einfachheit dieses Ansatzes entsprach auch einem der zentralen Storytelling-Ziele von Half-Life: die Erzählung auf die Interessen der Spieler abzustimmen. Manche Spieler möchten in jedes Detail eintauchen, während andere einfach nur wissen möchten, wie es weitergeht. Den Spielern die Kontrolle darüber zu geben, wie viel von der Story sie erleben – ohne dass dies den Fortschritt behindert –, ist ein Ziel, das wir in Half-Life-Spielen stets beibehalten. Und je einfacher ein Feature zu implementieren ist, desto öfter können wir es einbauen."
N/A4028"#commentary\cn_115_trainstation.mp3" "[ Charlie Brown ] Der Anfang eines Half-Life-Spiels spielt eine große Rolle: Wir müssen den Spielern eine neue Welt vorstellen und ihnen gleichzeitig beibringen, wie sie mit ihr interagieren. Die Spieler müssen schnell verstehen, was passiert, wer die Hauptcharaktere sind, welchen Bedrohungen sie ausgesetzt sind und wie sie in das Ganze passen. Und vor allem muss das Spiel Spaß machen und so interaktiv wie möglich sein. Um dies zu erreichen, sind viele Iterationen und Spieltests erforderlich, insbesondere der kleinen Momente, die das Gesamtbild des Spiels ausmachen. In diesem Abschnitt beleuchten wir einige Schlüsselmomente, Probleme beim Spieldesign und einige Spieltests, bei denen die Dinge nicht ganz nach Plan liefen."
N/A4029"#commentary\cn_116_physics_objects.mp3" "[ David Sawyer ] Man kann sich heute vielleicht kaum noch daran erinnern, aber als Half-Life 2 herauskam, waren kleine Objekte in Spielen, wie dieser Müll, in der Regel statisch – das heißt, sie bewegten sich nicht wirklich, oder wenn doch, dann nur auf sehr einfache Art. Wenn man Glück hatte, zerbrachen sie in Sprites, wenn man sie traf. Eines der Ziele dieses ersten Bahnhofsabschnitts bestand darin, den Spielern wirklich klarzumachen, dass solche Dinge in Half-Life 2 tatsächlich physikalisch simuliert wurden. Sie konnten aufgehoben, fallen gelassen, geworfen, zerbrochen, von anderen Kräften bewegt werden, was immer man wollte. Hier fangen wir mit einer Kleinigkeit an, indem wir zeigen, dass durch die Ankunft des Zuges Müll aufgewirbelt wird – oder genauer gesagt, durch eine unsichtbare Druckwelle, die ausgelöst wird, wenn der Spieler den Zug verlässt."
N/A4030"#commentary\cn_117_blocking_tutorials_3.mp3" "[ Eric Smith ] Der zweite Fehler in diesem Tutorial ist, dass wir dem Spieler versehentlich etwas beibringen, das wir nicht beabsichtigt hatten. Dies lässt sich ohne umfangreiches Testen nur schwer vermeiden, da das Spiel einem ständig etwas beibringt, auch wenn es nicht beabsichtigt ist. Ein extremes Beispiel dafür behandeln wir später im Bahnhof. Manche solcher Fälle müssen unbedingt behoben werden, beispielsweise wenn der Spieler den falschen Umgang mit einer Waffe oder die falsche Interaktion mit einem gängigen Spielelement lernt. Dieser Fall war jedoch subtiler. Während wir den Spielern das Bewegen von Objekten beibrachten, brachten wir ihnen auch bei, Physikobjekte zu stapeln, um einem Raum zu entkommen. Normalerweise ist das in Ordnung, nur dass wir dieses Rätsel später im Spiel nicht einsetzen. Etwas Irrelevantes beizubringen, überfrachtet nur den mentalen Werkzeugkasten und erschwert es Spielern, sich später nützliche Dinge zu merken. Schlimmer noch, das Stapeln von Objekten, um dem Spielraum zu entkommen, wurde später zum Problem, dem wir an mehreren Stellen aktiv entgegenwirken mussten. Bei so vielen physikbasierten Objekten im Spiel war es keine wirkliche Option, dieses Verhalten zu verhindern, ohne überall Decken zu installieren. Am Ende hofften wir einfach darauf, dass Spieler diese frühe Lektion nicht überdenken würden, und die Spieler in späteren Spieltests nicht weiterkamen, stellten wir sicher, dass wir sie nicht daran erinnerten."
N/A4031"#commentary\cn_118_welcome.mp3" "[ Gabe Newell ] Ich bin Gabe Newell. Willkommen zurück bei Half-Life 2. Zwanzig Jahre sind seit der Veröffentlichung vergangen. In diesem Jubiläumsupdate haben wir versucht, möglichst viele Wünsche der Community zu erfüllen. Und obwohl dies vielleicht nicht der wichtigste Wunsch der Fans ist, höre ich oft, wie sehr sich die Leute einen Kommentarmodus wünschen. Daher freuen wir uns sehr, ihn endlich zu ermöglichen. Es war nicht nur eine Herausforderung, sich an viele Details der Entwicklung von Half-Life 2 zu erinnern, sondern es war auch nicht einfach, jahrzehntealten Computercode zu knacken und sich zu fragen, was man sich damals nur dabei gedacht hat. Neben dem Entwicklerkommentar haben wir auch eine Reihe alter Fehler behoben und versucht, alles besser zu hinterlassen, als wir es vorgefunden haben. Und dieses Mal haben wir wenigstens den Luxus zu wissen, wie es am Ende ausgeht. Um einen Kommentar anzuhören, platzieren Sie Ihr Fadenkreuz auf das schwebende Kommentarsymbol und drücken Sie die BENUTZEN-Taste. Um einen Kommentar zu stoppen, fahren Sie mit dem Fadenkreuz über das rotierende Symbol und drücken Sie erneut die BENUTZEN-Taste. Ich freue mich über Feedback. Sie erreichen mich unter gaben@valvesoftware.com. Danke und viel Spaß!"
N/A4032"#commentary\cn_119_metrocop_shoving_citizens.mp3" "[ Josh Weier ] Wir haben gerade erst ein paar Meter hinter uns und schon haben wir Probleme zu lösen. Wir führen den Metrocop ein – einen Feind, den die Spieler irgendwann töten sollen – und geben einen kleinen Einblick in die Welt, in die die Spieler gerade treten. Es ist ein einfacher, klarer Moment, der die Beziehung zwischen den Metrocops und den Bürgern und damit auch dem Spieler zeigt. Gleichzeitig wollten wir die Existenz der Physiksimulation untermauern und zeigen, wie NPCs beiläufig mit Objekten in der Welt interagieren können. Zu sehen, wie zum Beispiel ein Koffer gegen einen anderen stößt und sich verschiebt, war damals ziemlich neuartig. Diese Momente am Bahnhof, wo wir mehrere Ziele kombinierten, waren die erfolgreichsten – sie fühlten sich natürlich an, als würde das Spiel nicht pausieren, nur um den Spielern etwas beizubringen."
N/A4033"#commentary\cn_120_fall_damage.mp3" "[ Kerry Davis ] Den Spielern beizubringen, wie sie bestimmte Dinge tun sollen, ist für das Spiel von entscheidender Bedeutung. Damit sie aber sichere Entscheidungen treffen können, müssen sie auch die subtileren Regeln verstehen. Dieser kurze Moment deckt zwei davon ab: Erstens zeigt er, wie weit der Spieler fallen kann, ohne Schaden zu nehmen. Zweitens führt er einen Teil des \"Vokabulars\" des Spiels ein – also wie das Spiel mit einem kommuniziert. Spieler haben oft Angst davor, beim Fallen Schaden zu nehmen, aber sie haben auch Angst davor, einen Schritt zu machen, den sie nicht mehr rückgängig machen können. Hier signalisiert also eine einladende Kiste, auf der man landen kann, dass das Fallen sicher ist und dass es hier weitergeht. Und wenn die Kiste zerbricht, untermauert das unsere Physiksimulation und ist wahrscheinlich das erste Mal, dass die Spieler sehen, dass größere Objekte zerbrechen können."
N/A4034"#commentary\cn_121_sweeping_vortigaunt.mp3" "[ Laura Dubuk ] Ein weiterer Schlüsselmoment des Storytellings und eine weitere Anspielung auf das Physiksystem: Hier zeigen wir, wie die Vortigaunts in diese neue Welt passen, was eine große Veränderung gegenüber ihrer Rolle als Feinde in Half-Life 1 darstellt. Wie so viele Momente im Bahnhof entstand der fegende Vortigaunt aus unserer ständigen Suche nach Möglichkeiten, Charaktere auf natürliche Weise mit dem Physiksystem interagieren zu lassen. Warum sollten wir den Spielern jetzt einfach erzählen, dass Vortigaunts freundlich sind, wenn man ihnen zeigen kann, wie er lässig den Boden fegt und ein paar simulierte Objekte umstößt? Nichts signalisiert so sehr \"Hey, erschießt mich diesmal nicht\" wie jemand, der bereit ist, aufzuräumen."
N/A4035"#commentary\cn_122_blocking_tutorials_2.mp3" "[ Robin Walker ] In diesem Tutorial gibt es zwei bemerkenswerte Fehler. Erstens können Spieler es unspielbar machen, indem sie alle Kisten aus dem Fenster werfen, was natürlich nicht so toll ist. Dadurch bleiben sie stecken und können nicht weiterspielen. Das war für uns ein Bug, der unbedingt behoben werden musste. Eine einfache Lösung wäre gewesen, die Fenster- oder Kistengröße so anzupassen, dass der Spieler hindurchpasst, nicht aber die Kisten. Das Problem war, dass wir das erst spät in der Entwicklung bemerkt haben und selbst eine so einfache Änderung unvorhersehbare, spielentscheidende Folgen haben kann – und das auch noch kurz vor der Veröffentlichung. Außerdem war dieses Problem rein theoretisch. Wir hatten noch nie gesehen, dass Testspieler das tatsächlich tun. Unsere Spieltests für diesen Designraum verliefen reibungslos, die Spieler lernten, was sie brauchten, und machten weiter. Eine so späte Änderung des Raumdesigns hätte diesen Erfolg auf unvorhersehbare Weise gefährden können. Daher entschieden wir uns für eine konservativere statt einer eleganten Lösung. Wenn Sie neugierig sind, werfen Sie einfach alle Kisten aus dem Fenster und sehen Sie, was passiert."
N/A4036"#commentary\cn_123_playground.mp3" "[ Brian Jacobson ] Als wir darüber diskutierten, wie wir unsere Physiksimulation in der Stadtumgebung in Szene setzen könnten, erschien uns ein Spielplatz als naheliegend. Und für Spieler, die Dr. Breen aufmerksam zugehört haben, ist er auch eine Erinnerung an den Preis, den die Menschheit für ihre Kapitulation vor den Combine zahlen musste. Wir wählten einige Spielplatzstrukturen mit interessantem Physikpotenzial aus und begannen, sie zu optimieren. Selbst mit der fortschrittlichen Physiksimulation von damals erforderten solche Strukturen immer Handarbeit, da wir vollständig simulierte Objekte hatten, die mit nicht oder nur teilweise simulierten Objekten wie dem Spieler oder der statischen Umgebung interagierten. Man könnte leicht annehmen, dass eine Simulation einen Großteil der Implementierungsarbeit übernehmen kann, aber selbst heute, zwanzig Jahre später, ist das selten der Fall. Als wir spät in der Spielentwicklung am Spielplatz arbeiteten, konnten wir die Reibung auf der Rutsche nicht richtig hinbekommen und beschlossen, die Leiter zu zerstören, damit die Spieler nicht hinaufklettern können. Man kann aber trotzdem einfach vorne hochgehen. Wie so oft, haben wir die Entschlossenheit der Spieler also unterschätzt."
N/A4037"#commentary\cn_124_pick_up_that_can.mp3" "[ Charlie Brown ] Die Kontextualisierung von Tutorials – also die Erstellung eines Handlungsszenarios für sie – ermöglichte es uns, mehr zu erreichen, als nur das Spiel anzuhalten und dem Spieler etwas beizubringen. Es ist uns möglich, dem Moment einen narrativen Charakter zu verleihen. Spieler können hier nicht nur lernen, wie man Gegenstände wirft, sondern auch entscheiden, wie sie auf narrative Vorgaben reagieren wollen. Nachdem sie beobachtet haben, wie Metrocops Bürger ohne mit der Wimper zu zucken misshandeln, fühlt es sich richtig an, die Spieler in eine ähnliche Lage zu versetzen. Wenn sie eine Meinung dazu haben, wie Bürger darauf reagieren sollten, können sie diese nun zum Ausdruck bringen. In Spieltests kamen Spieler entweder der Aufforderung nach, die Dose aufzuheben, oder weigerten sich. Einige versuchten jedoch, die Konfrontation insgesamt zu vermeiden. Andere fügten sich zunächst, rächten sich jedoch, nachdem sie sich gedemütigt fühlten. Durch die Einschränkung des Moments, sowohl was die Aktionen der Spieler als auch den Raum selbst angeht, konnten wir auf jede ihrer Entscheidungen angemessen reagieren."
N/A4038"#commentary\cn_125_promises.mp3" "[ Danika Rogers ] Am Anfang eines Half-Life-Spiels ist es eines unserer Ziele, dem Spieler ein Gefühl dafür zu vermitteln, was er später erwarten kann. Alle großartigen Unterhaltungsmedien, von Filmen über Fernsehserien bis hin zu Büchern, tun dies auf die eine oder andere Weise. Videospiele sind da nicht anders. Die Versprechen in einem Half-Life-Spiel können unterschiedliche Formen annehmen. Manche sind einfach, um etwas Interessantes zu zeigen. Andere haben mehr Tiefe, wie die Interaktionen mit den Metrocops. Indem wir den Spieler in eine hilflose Position versetzen, bereiten wir den Moment vor, an dem er endlich zurückschlagen kann."
N/A4039"#commentary\cn_126_exploration.mp3" "[ David Sawyer ] Nachdem die Metrocops die Spieler durch den Bahnhof scheuchen, wollten wir ihnen eine Gelegenheit zur Erkundung geben. Dieser Platz bot mehrere Möglichkeiten, um mit Bürgern, Metrocops, Scannern und der Infrastruktur der Stadt zu interagieren. Wir wollten durch diese Interaktionen die Welt ohne explizite Tutorials erklären und verfeinerten sie, bis sie ganz natürlich und ohne echtes Training funktionierten."
N/A4040"#commentary\cn_127_early_game_exploration.mp3" "[ David Speyrer ] Wahrscheinlich haben Spieler bis zu diesem Punkt nicht zu sehr über den Weg nachgedacht, den sie einschlagen, da er bislang sehr eindeutig erscheint. Wir wollten sie jedoch an diesem Ort zum Erkunden ermutigen. Das bedeutet, dass der weitere Weg weniger offensichtlich sein musste und das Gefühl vermitteln sollte, sich verlaufen zu haben – oder schlimmer, verwirrt zu sein. Diese Art von Änderungen ist schwierig, insbesondere dann, wenn der Spieler noch dabei ist, die Anleitungshinweise des Spiels zu lernen. Dies wurde durch Kraftfeld-Kontrollpunkte komplizierter, weil NPC-Zivilisten sich frei durch sie bewegen konnten, Spieler aber nicht. Viele Testspieler glaubten, dass es einen Weg geben muss, an ihnen vorbeizukommen. Durch intensives Testen konnten wir den beabsichtigten Weg mithilfe von Beleuchtung, Layout und einer Holzkiste (die schon mal als Signal für den richtigen Weg herhalten musste) sichtbarer machen – alles subtile Zeichen, die den Spieler leiten sollen."
N/A4041"#commentary\cn_128_strider.mp3" "[ Doug Wood ] Dieser einfache Moment ist ein Versprechen, dass man diesem riesigen Ding später im Spiel begegnen wird. Selbst eine so unkomplizierte Szene wie diese musste wiederholt getestet werden und durchlief mehrere Iterationen, da das Ziel für Half-Life darin bestand, dem Spieler nicht die Kontrolle zu entziehen. Wie man sich vorstellen kann, sind viele kleine Anpassungen erforderlich, um sicherzustellen, dass so viele Spieler wie möglich zur richtigen Zeit am richtigen Ort sind. Der Straßenverlauf und die Metrocop-Szene sind alle so eingestellt, dass sie den Blick des Spielers lenken und den Strider perfekt einrahmen, wenn er erscheint."
N/A4042"#commentary\cn_129_physics_simulation.mp3" "[ Jay Stelly ] Obwohl wir Half-Life 2 mit einer funktionsfähigen Physiksimulation eines Drittanbieters begannen, waren Jahre zusätzlicher Arbeit an der Simulation und ihrer Integration notwendig, bis wir das Gefühl hatten, die Ambitionen unserer Designer erfüllen zu können. Wir wussten, dass es eine Herausforderung sein würde, ein lieferbares Qualitäts- und Leistungsniveau aufrechtzuerhalten, aber das subtilere Problem bestand darin, herauszufinden, was simuliert werden sollte und in welchem Umfang. Wir konnten nicht alles simulieren, und selbst wenn dies möglich gewesen wäre, gibt es Gründe im Spieldesign, dies nicht tun. In vielen Fällen verbiegen wir die Simulation absichtlich zur Verbesserung des Spielerlebnisses. Diese Anpassungen bleiben normalerweise unbemerkt, da sie den Absichten der Spieler entsprechen. Beispielsweise deaktivierten wir Kollisionen zwischen Spielern und großen Objekten, damit man sich in engen Bereichen umdrehen kann. Wir optimierten auch den alternativen Feuermodus des Combine-Gewehrs, um die Combine-Kugel sanft auf Gegner zu lenken und sie effektiver zu machen."
N/A4043"#commentary\cn_130_physics_simulation_2.mp3" "[ Jeff Lane ] Bereiche, in denen das Spieldesign oder andere Einschränkungen die Physiksimulation beeinflussten, erforderten oft zusätzliche Anpassungen, damit die Simulation nicht abstürzt. Beispielsweise experimentierten wir früh damit, die Spielersimulation zu verstärken, das heißt, die Spielerbewegungen stärker in die physikalische Simulation der Welt einzubinden. Wir wussten, dass sich die Bewegungen dadurch möglicherweise weniger präzise anfühlen, hofften aber, dass dies zu einigen neuen Erfahrungen führen könnte. Nachdem wir die Bewegungen jedoch an die weniger simulierte Version angepasst hatten, stießen wir auf ein großes Problem: Die für die Bewegung des Spielers mit seiner üblichen Geschwindigkeit erforderliche physikalische Kraft war so hoch, dass schon das bloße Zusammenstoßen mit anderen simulierten Objekten zum Tod führen konnte. Wir probierten herum, fanden aber letztendlich keine Lösung, die uns gefiel, und kehrten zur weniger simulierten Bewegung zurück. Dies war jedoch nicht gerade der einfachere Weg – es brachte neue Herausforderungen hinsichtlich der Interaktion des weniger simulierten Spielers mit den stärker simulierten Objekten im Spiel mit sich. Aber so konnten wir das gewünschte präzise Bewegungserlebnis kreieren."
N/A4044"#commentary\cn_131_playtesting.mp3" "[ John Morello ] Spieltests sind ein zentraler Bestandteil unserer Spieleentwicklung – wir können nie genau vorhersagen, wie die Spieler reagieren oder was sie aus unserem Spiel herausholen. Wir testen also, um zu lernen und uns hoffentlich zu verbessern. Während eines Spieltests leiten wir den Spieler nicht an und sprechen auch nicht mit ihm, selbst wenn er nicht weiterkommt – da es äußerst unwahrscheinlich ist, dass wir nach der Veröffentlichung des Spiels noch neben ihm sitzen. Unser Ziel ist es, dass die Tester völlig vergessen, dass sie einen Spieltest spielen, und spielen, als wären sie zu Hause. Jede Unterbrechung birgt das Risiko, die Daten zu verfälschen. Daher greifen wir nur ein, wenn ein Fehler den Fortschritt blockiert oder, seltener, wenn das Verhalten der Spieler so verwirrend ist, dass wir nachfragen müssen, was sie denken."
N/A4045"#commentary\cn_132_playtesting_anecdote_1.mp3" "[ Matt Boone ] Bei einem unvergesslichen Spieltest wurden wir daran erinnert, dass wir nie sicher sein können, was die Spieler denken oder was sie aus ihren Erfahrungen gelernt haben. Ein Tester, von Anfang an gespielt hatte und nicht weiterkam, als er eine Tür öffnen wollte, verbrachte mehrere Minuten damit, zwischen dem Spiel und den Tastatureinstellungen hin- und herzuwechseln. Als wir ihn fragten, was er macht, sagte er, dass er das Inventar sucht, weil er dachte, dass er einen Gegenstand, den er zuvor aufgesammelt hatte, zum Aufschließen der Tür verwenden könnte. Wir hatten zwar gesehen, wie er mehrere Gegenstände einsammelte und fallen ließ, aber er hatte nicht verstanden, was da vor sich ging. Der Tester glaubte, dass ein Gegenstand durch Drücken der Taste \"Verwenden\" in das Inventar verschoben wird, weil der Gegenstand direkt nach unten fällt. Wir wussten, dass es sich nur um Schwerkraft handelte, aber die Annahme war nicht abwegig, denn in einigen Adventures dieser Zeit wurden Gegenstände auf diese Weise in ein unsichtbares Inventar verschoben. Wir erklärten, dass es kein Inventar gab, und der Test wurde fortgesetzt. Später haben wir überlegt, ob wir irgendwie auf das Problem eingehen sollten, aber da kein anderer Testspieler dieses Problem hatte und alle unsere möglichen Lösungen zu schwerfällig wären, haben wir beschlossen, dass es sich um einen Ausreißer handelte, den wir ruhig ignorieren können. Allerdings diente es als gute Erinnerung daran, wie selbst die subtilsten, unscheinbarsten Details einen Spieler in die Irre führen können."
N/A4046"#commentary\cn_133_cratebaby.mp3" "[ Scott Dalton ] Diese kleine Babypuppe hat einen langen Werdegang hinter sich. Während der langen Monate interner Tests hat ein Teil des Teams die Puppe in eine Herausforderung verwandelt - eine Möglichkeit, den 47sten Durchlauf des Spiels ein wenig lustiger zu gestalten. Sie legten die Puppe in eine nahe gelegene blaue Kiste und prüften, wie weit sie sie durch das Spiel tragen konnten. Nach der Veröffentlichung von Half-Life 2 begann auch die Community, das Kistenbaby zu tragen, und fügte dem Ganzen ihre eigenen Geschichten und Regeln hinzu. Ein paar Jahre später, während der Arbeit an Episode 2, war dies die Inspiration für den Erfolg \"Apollo Zwerg\", bei dem die Spieler einen Gartenzwerg namens \"Gartenzwerg Chompski\" durch das gesamte Spiel tragen mussten. Chompski feierte sogar ein Comeback in Left 4 Dead 2, und zwar mit dem Erfolg \"Zwergenbergung\", bei dem die Spieler ihn durch die Kampagne \"Dunkler Karneval\" tragen mussten. Diese Art von Interaktion mit den Spielern gehört zu den lohnendsten Teilen der Spieleentwicklung. Wir haben bei der Entwicklung immer Theorien im Kopf, aber man weiß nie wirklich, wohin sich die Dinge entwickeln, bis die Spieler sie in die Hände bekommen."
N/A4047"#commentary\cn_134_the_citadel.mp3" "[ Eric Kirchmer ] Wir wollten, dass Spieler zuerst die Zitadelle sehen, um ihre überwältigende Präsenz in der Stadt zu unterstreichen. Sie repräsentiert die vollständige und absolute Macht der Combine über die Menschheit. Sie dient auch als klar erkennbares Ziel – selbst am Anfang der Reise ist dem Spieler klar, wo sie enden wird. Trotz ihrer enormen Größe wurde sie oft von Testspielern übersehen. Es ist schwierig, einem Spieler über einen Computerbildschirm ein Gefühl von Tiefe und für das Ausmaß zu vermitteln. Wenn Sie jemals ein VR-Spiel gespielt haben, werden Sie sicherlich bemerkt haben, dass die Größenverhältnisse sich da deutlich natürlicher anfühlen. In diesem Fall jedoch war die Position der Zitadelle nicht wirklich hilfreich, da sie über dem Spieler schwebte. Dies könnte daran liegen, dass viele Ego-Shooter Spielern beibringen, starr nach vorn bzw. auf ihre Füße zu schauen. Um die Sichtbarkeit der Zitadelle für Spieler zu erhöhen, ließen wir Vögel auf die Struktur zufliegen – ein subtiler Trick, der den Blick von Spielern erfolgreich zum gewünschten Objekt führt."
N/A4048"#commentary\cn_135_close_captions.mp3" "[ Yahn Bernier ] Während der Entwicklung von Half-Life 2 kamen Leute mit dem Wunsch nach Barrierefreiheit auf uns zu und ermutigten uns, über das für Half-Life 1 entwickelte Untertitelsystem hinauszugehen. Sie fragten nach vollständigen Untertiteln für Hörgeschädigte, die alle Spielklänge wiedergaben, nicht nur Dialoge. Dies stellte eine deutlich größere Herausforderung dar als ursprünglich angenommen. Half-Life 2 produziert eine Vielzahl von Geräuschen und es war essenziell, diese für die Untertitel zu kategorisieren. Folglich war die Priorisierung der Schlüssel zum Erfolg: Dialoge sollten hervorstechen und es musste klar sein, wer spricht. In einigen Bereichen spielten Umgebungsgeräusche eine wichtige Rolle für die Stimmung, jedoch nicht so sehr wie ein in der Nähe schießender Gegner. Unsere Leveldesigner verwendeten auch viele Geräusche in unterschiedlichen Kontexten wieder, sodass ein Klang in einem Gebiet Untertitel benötigen konnte, aber nicht in einem anderen. Am Ende erhielt jedes Geräusch im Spiel eigene Untertitel, die in einer Art Miniaturversion von HTML formatiert waren und uns mehr Kontrolle über den visuellen Stil jedes Untertitels gaben. Die Untertiteldateien waren ebenso wie die Audiodateien zu groß, um sie im Arbeitsspeicher halten zu können. Aus diesem Grund entwickelten wir ein asynchrones Zwischenspeichersystem, um sie effizient handhaben zu können."
N/A4049"#commentary\cn_136_the_raid.mp3" "[ David Sawyer ] Der folgende Abschnitt, in dem die Metrocops die Wohnung durchsuchen, während der Spieler sich darin befindet, erforderte viele Iterationen, bis wir zufrieden waren. Normalerweise gestalten wir Half-Life so, dass die Spieler ihr eigenes Tempo bestimmen können, da sie sich auf unterschiedliche Weise durch das Spiel bewegen. Manche Spieler rennen und ignorieren alles, was nicht bedrohlich erscheint, während andere methodisch alles angehen. Wenn wir also ein bestimmtes Tempo erzwingen müssen, ist es immer eine Herausforderung, sicherzustellen, dass die Spieler dieses Tempo wahrnehmen und ganz natürlich mitmachen. Da wir das zum ersten Mal gemacht haben, mussten wir viel Arbeit investieren, um den Spielern klar zu machen, dass sie schnell agieren müssen und keine Zeit für Erkundungen haben."
N/A4050"#commentary\cn_137_materials_and_shaders.mp3" "[ Gary McTaggart ] Half-Life 2 erschien inmitten eines bedeutenden Wandels in der 3D-Grafik, in dem die Branche von Texturen zu Materialien und Shadern überging. In Half-Life 1 hatte jede Oberfläche eine Textur – im Wesentlichen ein Bild, das auf die Polygone der Oberfläche gelegt wurde. Aber in Half-Life 2, nur fünf Jahre später, hatte jede Oberfläche sowohl ein Material als auch einen Shader. Der Shader war ein Stück Code, das die Art und Weise anpasste, wie die Oberfläche gerendert wurde. Das Material definierte Eigenschaften für das physikalische Verhalten der Oberfläche und ihre Reaktion auf Gameplay-Funktionen. Es enthielt auch Verweise auf Texturen und andere Parameter, die der Shader zum Rendern verwenden konnte. Dadurch hatten Künstler und Designer viel mehr Kontrolle über das Aussehen und das Verhalten der Dinge. Dies hatte jedoch einen Nachteil: Half-Life 1 konnte auf einem Computer mit nur einer CPU ausgeführt werden, aber Half-Life 2 benötigte eine GPU, da die für Materialien und Shader erforderlichen Berechnungen speziell für GPU-Hardware entwickelt wurden. Die lichtbrechende Glastür hier ist ein klares Beispiel für einen speziellen Shader, aber eigentlich verfügt jede Oberfläche in der Szene über einen Shader irgendeiner Art."
N/A4051"#commentary\cn_138_the_raid_2.mp3" "[ Miles Estes ] Wir mussten nicht nur dafür sorgen, dass der Spieler sich gezwungen fühlt, weiterzugehen, sondern auch, dass die Razzia selbst idiotensicher war. Es durfte für den Spieler keine Möglichkeit geben, sie zu umgehen oder an den Metrocops vorbeizukommen. Die eigentliche Herausforderung bestand nicht darin, dass die Spieler versuchen würden, die Szene zu umgehen, sondern darin, dass viele in Panik geraten und in beliebige Richtungen rennen würden, sobald sie zum ersten Mal merkten, dass sie in Gefahr sind. Diese Situation erfordert einen Balanceakt: Wir wollten eine rasante Flucht, das Gefühl von echter Gefahr, aber wir wollten auch, dass die Spieler es beim ersten Versuch schaffen und das Gefühl haben, dass sie gerade noch rechtzeitig entkommen sind. Um dies zu erreichen, haben wir den Weg, der vor ihnen liegt, klar und deutlich an den Weg angelehnt, den sie gerade durch das vorherige Stockwerk genommen hatten. Eine Reihe sorgfältig platzierter Trigger kontrollierte die Bedrohungen, die vor und hinter ihnen auftauchten, um den Druck aufrechtzuerhalten und den Spielern dennoch genug Zeit zu geben, ihren Verfolgern voraus zu sein."
N/A4052"#commentary\cn_139_health_and_no_hud.mp3" "[ Dave Riller ] Die Verfolgungsjagd über dem Dach stellte eine einzigartige Design-Herausforderung dar. Sie sollte kein echtes Hindernis für das Gameplay darstellen und unsere Idealvorstellung war, dass die Spieler sie beim ersten Versuch schaffen. Trotzdem wollten wir ein Gefühl echter Gefahr erzeugen, sodass sich die Spieler ernsthaft bedroht fühlten, wenn sie nicht in Bewegung blieben. Die Herausforderung bestand darin, dass die Spieler ohne Schutzanzug technisch gesehen kein Head-up-Display oder HUD haben – also keine Möglichkeit, Schaden oder verbleibende Gesundheit anzuzeigen. Nach einigen Experimenten entwickelten wir für diesen Abschnitt ein spezielles Gesundheitssystem, bei dem ein rotes Leuchten um den Bildschirm herum Schaden anzeigte. Die Spieler reagierten wie erhofft und interpretierten es als Zeichen, in Bewegung zu bleiben, und die Verfolgungsjagd verlief wie geplant. Um das Ganze abzurunden, sorgten wir dafür, dass sich die Gesundheit schnell regenerierte, sodass das Leuchten nicht lange anhielt. Dies bestärkte die Spieler darin, dass Laufen tatsächlich die richtige Entscheidung war, und stellte sicher, dass sie am Ende nicht von einer zufälligen Kugel niedergestreckt wurden, nur weil sie vorher getrödelt oder gezögert hatten."
N/A4053"#commentary\cn_140_playtesting_anecdote_2.mp3" "[ Jakob Jungels ] Im nächsten Abschnitt musste der Spieler niedergeschlagen werden, damit Alyx ihn retten kann. Da Zeit und Ressourcen begrenzt waren, vereinfachten wir die Begegnung so weit wie möglich. Wir nutzen bestehende Systeme und ließen es wie eine normale Kampfsequenz ablaufen, mit einem benutzerdefinierten Ereignis, das ausgelöst wurde, wenn der Spieler \"starb\". Nach einigen Spieletests zur Feinabstimmung des Timings widmeten wir uns wieder anderen Dingen. Kurz vor Veröffentlichung stießen wir jedoch auf ein Problem mit einem Testspieler, der ständig speicherte und sofort Schnellladen drückte, wenn er dachte, er hätte verloren. Als er von einem Metrocop getroffen wurde, lud er neu, bevor Alyx eingreifen konnte. Er wiederholte dies mehr als zehnmal, bis wir etwas gesagt haben. In dieser Entwicklungsphase, der finalen Fehlerbehebungsphase, mussten wir uns darauf beschränken, nur spielentscheidende Probleme zu beheben, da selbst kleine Änderungen dazu führen konnten, dass etwas Wichtigeres kaputtging. Wir wussten, dass dies ein seltener Sonderfall war, da die meisten Testspieler keine Probleme damit hatten, also haben wir simple Maßnahmen ergriffen. Wir haben die Verzögerung zwischen dem Niederschlag und Alyx' erstem Satz verkürzt und die Ausblendfarbe von Schwarz auf Weiß geändert. Dies war jedoch nicht besonders hilfreich, da die Spieler noch nicht oft genug gestorben waren, um Schwarz mit Tod zu assoziieren. Wir haben überlegt, Schnellladen für die wenigen Sekunden der Szene zu deaktivieren, befürchteten jedoch, dass dies zu einem Fehler führen könnte, der Schnellladen dauerhaft deaktivieren würde."
N/A4054"#commentary\cn_141_character_reactions.mp3" "[ Ariel Diaz ] Es war eine ständige Herausforderung, herauszufinden, worauf die Charaktere reagieren sollten – und wie. Im Grunde wollen wir immer, dass das Spiel auf die Eingaben der Spieler reagiert. Allerdings kann jede Reaktion des Spiels vom Spieler als Belohnung angesehen werden. Durch das, worauf die Charaktere reagieren und was sie ignorieren, lernen die Spieler, welche Art von Eingaben das Spiel erwartet. Daher haben wir darauf geachtet, dass wir auf Dinge reagieren, die wir fördern wollen, wie zum Beispiel, dass die Spieler mit den Geräten im Labor herumspielen, und dass wir Verhaltensweisen ignorieren, die wir weniger wollen, wie zum Beispiel, dass die Spieler Kleiner immer und immer wieder mit einer Kiste ins Gesicht hauen. Das mein ich ernst, wir haben einem Spieletester fünf Minuten lang dabei zugesehen."
N/A4055"#commentary\cn_142_choreography.mp3" "[ Bill Fletcher ] Das System, das wir für das Storytelling von Half-Life 2 entwickelten und iterierten, hieß intern \"Choreo\", kurz für Choreografie. Schon früh fanden wir es hilfreich, uns vorzustellen, wir würden ein Theaterstück schreiben, bei dem einer der Schauspieler das Drehbuch nicht kennt. Wir brauchten ein System, mit dem wir alle anderen Schauspieler steuern konnten, um sie auf der Bühne zu bewegen, ihre Darbietungen zu zeigen und ihren Text zu sprechen. Um dies zu bewerkstelligen, mussten die anderen Schauspieler unsere Regieanweisungen nahtlos mit dynamischen Reaktionen auf die Position und das Verhalten des Spielers verbinden. Das Timing war natürlich eine große Herausforderung, da jeder Teil der Szene länger oder kürzer werden oder sogar pausiert werden musste, je nachdem, was der Spieler gerade tat."
N/A4056"#commentary\cn_143_phoneme_extraction.mp3" "[ Bill Fletcher ] Ein weiteres wichtiges Tool, das wir in FacePoser integriert haben, war der Phonem-Editor. Er verarbeitete die Dialogzeilen der Synchronsprecher und extrahierte Phoneme, um einfache Lip-Sync-Animationen für unsere Charaktere zu generieren. Für die Heldencharaktere nutzten unsere Animatoren diesen Editor als Ausgangspunkt, um hochwertige, individuelle Animationen für jede Dialogzeile zu erstellen, einschließlich vollständiger Gesichtsanimation. In einer dynamischen Choreo-Szene wussten die Animatoren jedoch nicht genau, was der restliche Körper des Sprechers tun würde. Dies erforderte eine sorgfältige Überlagerung der Choreo-Befehle und -Timings in FacePoser, während die Fähigkeit des Sprechers, dynamisch auf die Spieler zu reagieren, erhalten blieb."
N/A4057"#commentary\cn_144_delivery.mp3" "[ Ken Birdwell ] Es bedurfte vieler Iterationen und Spieletests, um die richtige Balance zwischen Informationen und emotionaler Bindung in unseren großen Choreo-Szenen zu finden. Jede Szene enthielt eine Menge Informationen, die wir den Spielern vermitteln mussten, aber wir konnten die Charaktere nicht einfach nur schwadronieren lassen – die Spieler würden sie dann eher als Wegweiser und nicht als Personen wahrnehmen. Wir mussten uns die Zeit nehmen, die Charaktere miteinander interagieren zu lassen, damit der Spieler ihre Beziehungen beobachten kann. Gleichzeitig mussten wir die Welt erweitern und den Spielern ein Gefühl dafür geben, was alles geschehen ist, während sie weg waren. All dies musste sorgfältig passieren und nicht zu lange dauern – wir wollten, dass das Spiel auch für Spieler funktioniert, die von der Story nicht so sehr gefesselt sind. Animationen wurden zu einem mächtigen Werkzeug, um die emotionalen Verbindungen zwischen den Charakteren zu vermitteln, und konnten oft schnell die Tiefe eines Moments darstellen, ohne zu übertreiben. Humor war ein weiteres gängiges Mittel, um eine Situation aufzulockern und die Spieler zu entspannen, wenn es etwas zu ernst wurde."
N/A4058"#commentary\cn_145_alyxs_kiss.mp3" "[ Ken Birdwell ] Es ist ein kleiner Moment, aber Alyx' Kuss auf Elis Wange war wichtig. Schließlich bitten wir die Spieler später, Eli zu retten, und wir möchten, dass er ihnen am Herzen liegt. Um diese emotionale Verbindung aufzubauen, mussten wir die Wärme und Zuneigung zwischen Alyx und Eli zeigen. Wir wollten es nicht mit Dialogen übertreiben oder ein zu großes Spektakel daraus machen – es musste sich echt anfühlen, nicht gespielt – und wir haben die Feinheiten dieses Moments so lange überarbeitet, bis er genau richtig war."
N/A4059"#commentary\cn_146_storytelling.mp3" "[ Bill Van Buren ] Bei Half-Life 1 war es uns wichtig, ein Gefühl der Immersion in die Geschichte zu schaffen. Das führte dazu, dass wir uns selbst die Vorgabe machten, den Spielern nie – oder zumindest sehr selten – die Kontrolle zu entziehen und den Avatar des Spielers stumm zu halten. Diese Einschränkungen machten das Storytelling manchmal schwieriger, aber wir hielten es für wichtig, sie für Half-Life 2 beizubehalten. Wir hofften, dass wir durch das Beibehalten dieser Prinzipien einen Anreiz haben würden, eine tiefere, interaktivere Geschichte zu entwickeln."
N/A4060"#commentary\cn_147_archetypes.mp3" "[ Bill Van Buren ] Wir wollten durch unsere Charaktere erzählerische Verbindungen zwischen Half-Life 1 und Half-Life 2 schaffen. Unsere Idee war es, Charaktere zu entwerfen, die sich wie Repräsentationen der Archetypen von Half-Life 1 anfühlten, sodass sie den Spielern vertraut vorkommen – fast so, als wären sie ihnen irgendwann in Half-Life 1 begegnet und sie würden sich nur nicht mehr genau erinnern. Dr. Kleiner basierte auf dem Wissenschaftlermodell, das wir für das ikonischste hielten, und seine Persönlichkeit wurde weitgehend von Hal Robins geprägt, dessen Stimme und Darstellung die Wissenschaftler von Half-Life 1 definiert hatten. Eines Tages, als wir gerade dabei waren, uns diesen Charakter auszumalen, fiel uns Dr. Kleiners Gesicht ins Auge, als wir zufällig mit einem Buchhalter aus einem Büro auf einer anderen Etage unseres Gebäudes zusammen im Aufzug waren. Als wir ihn ansahen, war klar: Das ist Dr. Kleiners Gesicht. Zum Glück war er hilfsbereit, als wir ihn fragten, ob wir ihn für eine Videospielfigur fotografieren dürften."
N/A4061"#commentary\cn_148_tone.mp3" "[ Bill Van Buren ] Es war entscheidend, den richtigen Ton für unsere Charaktere und ihre Dialoge zu finden. Wir wollten einen respektvollen, fast schon angenehmen Stil bei der Interaktion mit den Spielern erreichen, gleichzeitig aber alles vermeiden, was zu unterwürfig wirkt. Dieses Gleichgewicht war besonders bei Alyx schwierig, die den Spieler unterstützen musste, ohne die Härte ihres eigenen Charakters zu verlieren – etwas, das für uns entscheidend war, damit die Spieler sie respektieren. Ihre Beziehung zu Eli war ein zentraler Faktor für die Motivation der Spieler, daher war es wichtig, dass die Spieler sie mochten und ihr helfen wollten. Außerdem wollten wir die Wärme und Kameradschaft zwischen den Verbündeten des Spielers mit der Feindseligkeit gegenüber Breen und den Combine in Kontrast setzen, um bei den Spielern ein Gefühl der Wut für die bevorstehenden Kämpfe zu wecken."
N/A4062"#commentary\cn_149_voice-actors.mp3" "[ Bill Van Buren ] Um in Half-Life 2 lebendigere und vielschichtigere Charaktere zu schaffen, mussten wir unsere Arbeit mit den Synchronsprechern ändern. Während es bei Half-Life 1 reichte, ein Skript mit einem Minimum an Anweisungen durchzugehen, um einen Großteil der NPC-Dialoge zu vertonen, beschlossen wir für Half-Life 2, den Schauspielern mehr Gelegenheit zu geben, sich an der Gestaltung der Charaktere zu beteiligen und sie zum Leben zu erwecken. Wir gaben den Schauspielern mehr Kontext, zeigten ihnen die Spielwelt, die Umgebungen ihrer Charaktere und die anderen Charaktere, mit denen sie interagierten. Wir suchten nach Schauspielern, die all diese Informationen aufnehmen und in ihre Darbietungen einfließen lassen konnten, wodurch aus den Charakteren mehr wurde, als wir uns anfangs vorgestellt haben. Wir hielten mehrere Sessions mit den Hauptdarstellern ab, damit sie ihre Figuren verinnerlichen und ausbauen konnten. Bei Szenen, in denen die Charaktere miteinander interagieren, haben wir einem Schauspieler oft Auftritte von anderen Schauspielern in der Szene vorgespielt, um ein besseres Gefühl für die Verbindung und den Flow zu schaffen. Obwohl wir im Studio mit einem Skript und einem Plan für die Aufnahme ankamen, war uns wichtig, dass die Schauspieler sich frei fühlten und ihre eigenen Ideen für die Charaktere und Darstellungen einbringen konnten. Es war ebenfalls wichtig, dass die Animatoren bei Aufnahmen dabei waren, da sie dafür verantwortlich waren, den Dialog der Figur mit den Bewegungen und der Mimik zu einer Szene zusammenzufügen. Oft stellten die Animatoren fest, dass sich ihre Pläne für den Ablauf einer Szene nach der Zusammenarbeit mit dem Synchronsprecher stark veränderten."
N/A4063"#commentary\cn_150_citizens.mp3" "[ Bill Van Buren ] Als es an die Gestaltung der menschlichen Bürger von City 17 und der Außenwelt ging, entschieden wir uns für eine Vielzahl von Ethnien, Altersgruppen und Geschlechtern. Dies bot nicht nur einen erzählerischen Kontext für die Versklavung der gesamten Menschheit durch die Combine, sondern es war uns auch wichtig, dass jeder, der das Spiel spielt, sich im Widerstand wiederfindet und alle Menschen auf der Erde sich gegen die Combine vereinen. Obwohl wir durch unseren Alltag und unsere Beziehungen eine Reihe von Personen gefunden haben, die uns bei der Erstellung der Bürger als Referenz dienten, griffen wir schließlich auf Anzeigen in der Seattle Times zurück, um die gewünschte Bandbreite an Gesichtern zu erreichen, die wir uns vorgestellt hatten."
N/A4064"#commentary\cn_151_alyx.mp3" "[ Dhabih Eng ] Das Design von Alyx war eine große Herausforderung – wir wollten, dass die Spieler sie respektieren und mögen. Eli zu retten war ein zentrales Ziel der Spieler in der Spielmitte, und wir wussten, dass wir sie leichter für das Ziel begeistern würden, wenn sie sich auch für Alyx und ihre Beziehung zu ihrem Vater interessieren. Wir haben Alyx absichtlich so gestaltet, die Dialoge geschrieben und eine Sprecherin gecastet, dass sie in der von den Combine kontrollierten Welt klug, fähig und sympathisch rüberkommt, während sie gleichzeitig attraktiv und charismatisch wirkt. Wir wollten die Objektivierung, Übertreibung und Hyper-Sexualisierung, die in vielen Spielen der 2000er-Jahre zu finden war, vermeiden, da das unsere Ziele für ihren Charakter untergraben hätte."
N/A4065"#commentary\cn_152_lab_interactivity.mp3" "[ Dhabih Eng ] In unseren Choreo-Szenen ist der Spieler eine Zeit lang gefangen, sodass wir uns auf die Charaktere und die Erzählung konzentrieren können. Um den verschiedenen Spielern gerecht zu werden – einige sind sehr in die Geschichte vertieft, andere können nicht länger als eine Sekunde stillstehen –, brauchten wir einen ständigen Strom interessanter Details auf dem Bildschirm. Wir streuten erzählerische Elemente in die Umgebung ein und sorgten dafür, dass einige interaktiv waren, quasi wie Spielzeug, mit dem die Spieler rumspielen konnten. In einigen Fällen haben wir weitere Geschichten in diese Elemente eingebaut, wie den Mini-Kaktus-Teleporter, der auf den bevorstehenden Teleporterausfall anspielt. Es war eine Gratwanderung – zu viele visuelle Reize könnte die Spieler vom Wesentlichen der Szene ablenken. Letztendlich gingen wir bei Kleiners Labor mit der Interaktivität auf Nummer sicher, denn es war die erste große Choreo-Szene. Später, in Elis Labor, haben wir das Thema vertieft und dafür gesorgt, dass die Charaktere selbst darauf achten, womit die Spieler rumhantieren."
N/A4066"#commentary\cn_153_gestures.mp3" "[ Doug Wood ] Jeder unserer Charaktere hatte eine Bibliothek mit einfachen Animationen, den sogenannten Gesten, die wir einfach über andere Körperbewegungen legen konnten. Ursprünglich war dies als Produktionserleichterung geplant, damit wir die Animationen im gesamten Spiel wiederverwenden konnten, aber wir stellten fest, dass sie noch mehr Nutzen hatten. Menschen wiederholen oft bestimmte Bewegungen, und diese können ein Zeichen für ihre besondere Persönlichkeit sein. Das Ergebnis war, dass unsere Gesten-Bibliothek die Essenz jedes Charakters einfing und unserem Animationsteam half, ein einheitliches Verständnis für diese Charaktere zu entwickeln. Dies machte es für unsere Animatoren sehr viel einfacher, die Arbeitslast eines Charakters unter sich aufzuteilen, was bei der Produktion oft erforderlich war."
N/A4067"#commentary\cn_154_interactive_storytelling.mp3" "[ Erik Johnson ] Als wir mit der Entwicklung von Half-Life 2 begannen, waren Storys in Spielen entweder sehr gut und linear oder weniger gut und interaktiv. Uns war bewusst, dass Spieler zwar hervorragende Storys aus anderen Spielen kannten, aber noch nie in der Lage waren, bei ihrer Entfaltung dabei zu sein, mit ihnen zu interagieren und beliebige Teile genauer zu betrachten. Obwohl uns dieses Ziel faszinierte, sahen wir zu diesem Zeitpunkt keine Möglichkeit, dies zu verwirklichen, da uns das Know-how und die Technologie dafür fehlten. Für Half-Life 1 entwickelten wir verschiedene Technologien für die Story. Aber meist mangelte es an der gewünschten Interaktivität und Qualität. Daher wurde Kleiners Labor zu unserem Testlabor für interaktives Storytelling."
N/A4068"#commentary\cn_155_monitors.mp3" "[ Ido Magal ] Wir verwenden Monitore in Half-Life 2 und in den Episoden so häufig für das Storytelling, dass wir uns sogar selbst darüber lustig machen. Das Problem ist, dass sie einfach zu praktisch sind. Sie eignen sich fantastisch, um die Welt zu erweitern, indem sie Ereignisse zeigen, die anderswo stattfinden, und sie bieten eine einfache Möglichkeit, Charaktere sprechen zu lassen, ohne dass man erklären muss, wie sie alle zum Spieler gelangen. Jeder, der schon einmal eine Geschichte geschrieben hat, vor allem eine mit einem großen Ensemble, weiß, wie frustrierend es ist, wenn man versucht, logische Gründe für das Zusammentreffen aller Charaktere an einem Ort zu finden. In diesem Fall waren wir sehr zufrieden damit, wie der Monitor es Alyx ermöglichte, sich wegzuteleportieren und dann schnell in Elis Labor aufzutauchen, wodurch sich alles real und verbunden anfühlte."
N/A4069"#commentary\cn_156_scene_interactivity.mp3" "[ Jeff Lane ] An bestimmten Stellen in unseren Choreo-Szenen müssen die Spieler aktiv werden. Diese Momente geben ihnen nicht nur etwas zu tun und halten sie bei Laune, sondern dienen auch einigen wichtigen anderen Zwecken. Erstens ermöglichten sie den Spielern, sich zu sammeln, wenn sie durch etwas anderes in der Umgebung abgelenkt wurden. Die Szene konnte so lange \"pausiert\" werden, bis die Spieler ihre Aufgabe erledigt hatten, um sicherzugehen, dass sie wieder bei der Sache waren. Gleichzeitig konnten wir die Spieler dort positionieren, wo wir sie brauchten, was nützlich war, um die Szene zu strukturieren und sicherzustellen, dass sie etwas Wichtiges sahen. In einigen Fällen konnten wir diese Momente doppelt nutzen, indem wir den Spielern etwas beibrachten – hier lernen sie etwa, mit Steckern und Steckdosen umzugehen, eine Fähigkeit, die sie für spätere Rätsel im Spiel benötigen."
N/A4070"#commentary\cn_157_kleiners_lab.mp3" "[ Marc Laidlaw ] Kleiners Labor war der erste Storytelling-Abschnitt, an dem wir gearbeitet haben. Deshalb dauerte es auch am längsten. Das Labor führte Spieler nicht nur in das Spiel ein, sondern wurde zur Vision für die Entwickler hinsichtlich des Storytellings. Als wir mit der Entwicklung unserer Charaktere und der narrativen Vermittlung von Informationen mit dem Spieler im Zentrum begannen, stellten sich zahlreiche Fragen, die erhebliche Risiken für das Spiel aufwarfen. Ist es Spielern möglich, die wichtigsten Informationen aus jeder Szene zu extrapolieren? Ist es uns möglich, sie dazu zu bewegen, sich mit diesen Charakteren zu identifizieren? Wie können wir Spieler mit mehr oder weniger Interesse an der Story abholen? Wie hoch wären die Produktionskosten einer solchen Szene? Und wie viele würden wir benötigen? Wir konnten diese und viele weitere Fragen erst beantworten, nachdem wir einen ausreichenden Anteil der Szene erstellt und diese mit vielen Testspielerngetestet hatten. Im Gegensatz zu vielen anderen Problemen, mit denen wir konfrontiert waren, konnten wir diese Fragen erst nach Abschluss umfangreicher Arbeiten beantworten. Unsere Gameplay-Ideen konnten wir häufig mit sehr einfachen Prototypen testen. Aber wenn die Spieler sich nicht für die Story begeistern können, wenn die Charaktere nur graue Blöcke sind, wie wahrscheinlich ist es dann, dass es mit den finalen Charaktermodellen anders sein wird?"
N/A4071"#commentary\cn_158_characters.mp3" "[ Marc Laidlaw ] In Half-Life 1 waren die Sicherheitsleute und Wissenschaftler eher Archetypen als Individuen. Sie waren Abstraktionen von Charakteren, die der damaligen Grafikqualität entsprachen. Mit der Verbesserung der Technologie in Half-Life 2 sahen wir jedoch die Möglichkeit, über diese Abstraktionen hinauszugehen. Die verbesserte Grafikqualität der Charaktermodelle in Verbindung mit Verbesserungen bei der Animation gab uns das Vertrauen, dass wir uns auf die Erstellung individueller Charaktere konzentrieren konnten – Menschen, die den Spielern wirklich am Herzen liegen würden. Wir erlaubten uns, echte Dialoge zu schreiben und sie von den Charakteren so vortragen zu lassen, dass sie realistisch genug wirkten, damit die Spieler sie nicht als Spielfiguren in einem Videospiel betrachteten und so hoffentlich unsere Erzählung voranbrachten. Im Jahr 2001, nach einigen Jahren der Entwicklung, wurden wir durch \"Ico\" von Japan Studio inspiriert. Das Spiel, das von einem Animator geleitet wurde, beeindruckte uns durch die Tatsache, dass es sich auf Charaktere als wichtige Verbindung zum Spieler stützte, und gab uns den Mut, weiterzumachen."
N/A4072"#commentary\cn_159_writing.mp3" "[ Marc Laidlaw ] Zu Zeiten von Half-Life 1 bestand das Ziel von Ego-Shootern noch weitgehend darin, einen offensichtlich bösen Feind zu bekämpfen und zu besiegen. Es war schwer, die Spieler dazu zu bringen, sich für die Charaktere zu interessieren, wenn sie so unrealistisch waren wie in Half-Life 1. Mit den geplanten Verbesserungen der Charakterdarstellung in Half-Life 2 wollten wir versuchen, die Charaktere in den Mittelpunkt der Story zu stellen. Unser Ziel war es, dass die Motivationen der Spieler mit denen unserer Charaktere übereinstimmen – dass die Spieler sich für diese Menschen, ihre Hoffnungen und Ängste interessieren und ihnen Erfolg wünschen. Mit diesem Gedanken im Hinterkopf konnten wir unseren Ansatz für Charaktere und Dialoge erarbeiten. Wir haben eine Reihe von Charakteren geschaffen, die sich gegenseitig mögen und schätzen, in der Hoffnung, dass die Spieler dasselbe empfinden würden. Diese Charaktere sollten so interagieren, dass sie sich wie eine Gruppe alter Freunde fühlen, die den Spieler als einen von ihnen sehen, der nur eine Weile weg gewesen ist. Wenn die Charaktere realistische emotionale Beziehungen zueinander zeigen, so glaubten wir, könnten wir auch eine emotionale Verbindung zum Spieler aufbauen."
N/A4073"#commentary\cn_160_animation.mp3" "[ Miles Estes ] Um menschliche Bewegungen aus vielen einzelnen Animationsebenen glaubhaft mit unseren Charakteren wiederzugeben, waren viele technologische Iterationen notwendig. Selbst einfache Aktionen wie das Umdrehen, um sich etwas anzuschauen oder zu einer Stelle zu gehen, waren komplizierter, wenn sie mit dem Bedürfnis nach dynamischer Reaktion auf den Spieler und der Anforderung nach Choreo-Befehlen verbunden waren. Wenn sich beispielsweise ein Charakter umdreht, um etwas anzusehen, musste dies vollständig auseinandergenommen werden, damit der Charakter eine Kombination aus Augen, Kopf, Schultern, Oberkörper oder vollständigem Körper verwenden konnte, um sich dem Ziel zuzuwenden. In Half-Life 1 waren die Menschen in zwei Hälften aufgeteilt, was ihnen ermöglichte, in eine Richtung zu gehen und gleichzeitig in eine andere Richtung zu blicken. Dieser Ansatz war jedoch zu abstrakt für die Charaktere von Half-Life 2. Unsere Animatoren kreierten stattdessen Laufanimationen in allen acht Kompassrichtungen, die dann während der Laufzeit nahtlos ineinander überblendet wurden."
N/A4074"#commentary\cn_161_faceposer.mp3" "[ Yahn Bernier ] Das Hauptwerkzeug, das wir mithilfe des Choreografie-Systems erstellten, war FacePoser, ein Programm mit unzutreffendem Namen, das es unseren Animatoren ermöglichte, die gesamte Struktur unserer Szenen auf einer Zeitleiste darzustellen. Die Zeitleiste enthielt eine Reihe von choreografierten Befehlen für Akteure, neben allen notwendigen Informationen zur Ausführung dieser Befehle. Durch die Überlagerung dieser Befehle auf der Zeitleiste konnten die Animatoren einfach beschreiben, wie ein Akteur beispielsweise auf etwas blickt, während er mit einem anderen Akteur spricht und dabei gleichzeitig eine andere Richtung einschlägt. Die Zeitleiste war jedoch keine fixe, lineare Sequenz. Die Akteure folgten zwar ihren Befehlen, konnten aber dynamisch auf ihre Umgebung reagieren. Ein Akteur könnte z. B. länger benötigen, um an einen Ort zu gelangen, wenn der Spieler im Weg steht, oder länger warten, um etwas zu sagen, wenn ein anderer Akteur vom Spieler aufgehalten wird. FacePoser ermöglichte es uns, Szenen zügig zu durchlaufen und zu verbessern sowie verschiedene Layouts, die Art der Kommunikation und das Timing zu überprüfen. Diese Möglichkeit, schnell zu experimentieren und Anpassungen vorzunehmen, war entscheidend, um unsere Charakter- und Story-Ziele zu erreichen."
N/A4075"#commentary\cn_162_choreo_commands.mp3" "[ Yahn Bernier ] Diese Debugging-Visualisierung zeigt zwei der häufigsten Choreo-Befehle, die Akteure in Szenen erhalten, intern als \"Schau-auf\" und \"Geh-zu\" bezeichnet. Akteure sollten etwa auf Ziele schauen – gelegentlich mehrere gleichzeitig – und sich dann auf das konzentrieren, was für ihren aktuellen Status am sinnvollsten war. Gleichzeitig konnten sie den Geh-zu-Befehl erhalten, zu einer bestimmten Stelle zu gehen und in eine spezifische Richtung oder auf ein spezifisches Objekt zu schauen. Selbst diese scheinbar einfachen Befehle waren sehr komplex. Eine Szene verlangte etwa von einem Akteur, dass dieser während des Tippens auf der Tastatur mit dem Spieler spricht und gleichzeitig auf ein Objekt in der Hand des Spielers schaut. Da wir nicht vorhersagen konnten, wo sich der Spieler während des Abspielens befindet, mussten wir für Szenen wie diese jedes Element in separate Teile und Ebenen aufteilen. Diese konnten wir dann basierend auf den Aktionen des Spielers während des Abspielens wieder zusammensetzen und bei Bedarf unterbrechen."
N/A4076"#commentary\cn_163_antlions.mp3" "[ Kerry Davis ] Da der Spieler mit dem Buggy die Küste entlangfährt, benötigten wir einen allgegenwärtigen Feind, der überall auftauchen und als konstante Bedrohung dienen konnte, um den Spieler nah am oder im Buggy zu halten. Die perfekte Lösung waren aus dem Sand auftauchende Ameisenlöwen. Anders als humanoide Feinde waren sie dank ihrer hohen Mobilität in der Lage, kurzzeitig mit dem Buggy Schritt zu halten. Außerdem fühlte es sich toll an, sie zu überfahren."
N/A4077"#commentary\cn_164_thumpers.mp3" "[ Adrian Finol ] Es ist wichtig, dem Spieler, wann immer möglich, das Gefühl zu geben, dass er selbst etwas rausgefunden hat. Dadurch fühlt sich die Welt lebendiger an, anstatt nur eine Reihe von Gameplay-Elementen zu sein, die für den Spieler aufgebaut wurden. Wenn wir riskieren können, dass ein kleiner Anteil der Spieler ein Element komplett übersieht, können wir sogar einen subtileren Ansatz wählen. Wir wählten diesen Ansatz für die Rammen und entwarfen Szenen, in denen Spieler wahrscheinlich mit ihnen interagieren würden, ohne dazu gezwungen zu sein. Viele audiovisuelle Hinweise und Reaktionen der Ameisenlöwen halfen dem Spieler, die Situation zu verstehen. Es gab keine Garantie, dass alle Spieler es herausfinden würden, aber in den Spieltests hatten die meisten damit kein Problem."
N/A4078"#commentary\cn_165_d2_coast_09.mp3" "[ Aaron Seeler ] Unser Spielcode war spät in der Küsten-Entwicklung dem Leveldesign so weit voraus, dass unsere Gameplay-Programmierer nach weiterem Code zum Schreiben und neuen Aufgaben suchten, um Half-Life 2 bis zur Veröffentlichung zu unterstützen. Dies war hauptsächlich auf die hohen Anforderungen der Küsten-Level zurückzuführen, da sie aufgrund des schieren Maßstabs des genutzten Terrains viel von unseren Leveldesignern abverlangten. Deshalb designten unsere Gameplay-Programmierer kleine Begegnungen. Später, als unsere Leveldesigner aufgeholt hatten, kreierten sie mit diesen ein Level, das aus drei separaten Begegnungen der Programmierer zusammengesetzt war, und konnten alle notwendigen Arbeiten abschließen, um das Spiel für die Veröffentlichung vorzubereiten."
N/A4079"#commentary\cn_166_final_scene.mp3" "[ Bill Van Buren ] Die Entscheidung, den Spieler für die letzte Konfrontation in Breens Büro in eine Kapsel zu sperren, ermöglichte es uns, uns auf Charaktere zu konzentrieren, auf die wir sonst den Fokus nicht hätten legen können. In dieser Szene erreicht jeder Charakterhandlungsstrang seinen Höhepunkt. Die Einschränkung des Spielers zu diesem Zeitpunkt ermöglichte es uns, durch Kombination des Dialogs mit den herausragenden Leistungen der Sprecher und Animationen einen wahren emotionalen Höhepunkt zu schaffen. Die Szene war aus dem Blickwinkel der Produktion eine Herausforderung: Sie benötigte die richtige Mischung aus Blockieren und Bewegungen, gepaart mit effektivem Timing und emotionaler Synergie sowie die Verknüpfung aller einzelnen Animationen mit den separat aufgenommenen Darbietungen der Sprecher. Es bedurfte einer sorgfältigen Abstimmung, bevor wir eine gewisse Dramatik erreichen und den Eindruck erwecken konnten, dass alle Charaktere tatsächlich miteinander verbunden waren."
N/A4080"#commentary\cn_167_end_game_scramble.mp3" "[ Dave Riller ] Ursprünglich war eine größere Choreografie für das Ende des Spiels geplant. Das Choreo-Team war jedoch äußerst beschäftigt mit der riesigen Menge an Arbeit für die Erzählung der Geschichte, die noch im gesamten Spiel benötigt wurde. Um Ihnen ein wenig Arbeit zu ersparen, baten wir das Zitadellen-Gameplay-Team, stattdessen eine Herausforderung für das Gameplay für das Ende des Spiels zu entwickeln. Es spielte dabei keine Rolle, ob es sich um ein Puzzle, einen Kampf oder etwas anderes handelte. Dies führte zu einem Endbosskampf mit Breen, der die Spielmechanik des existierenden Super-Gravitrons nutzte und nur ein wenig spezielle Choreografie benötigte, um in kurzer Zeit ein fertiges Produkt zu erstellen."
N/A4081"#commentary\cn_168_combine_portal_effects.mp3" "[ Gary McTaggart ] Ein wichtiger Teil unseres Entwicklungsprozesses ist, dass jedes Teammitglied seine Fähigkeiten zu jedem Teil des Spiels beitragen kann. Nachdem das Gameplay des finalen Kampfes stand, halfen Künstler und Programmierer für visuelle Effekte dabei, die Präsentation des Portals zur Combine-Heimatwelt und den Effekt der angehaltenen Zeit ganz am Ende des Spiels zu verbessern. Für den Effekt des Combine-Portals wurde ein refraktiver Shader verwendet, ähnlich dem, den wir für Wasser verwendet haben."
N/A4082"#commentary\cn_169_citadel_entrance.mp3" "[ Jeff Lane ] Die Route zur Zitadelle wurde rückwärts erstellt: Die innere Geometrie wurde als Teil eines Artwork-Prototyps erstellt, um das Aussehen zu optimieren. Wir wussten, dass der Spieler über ein Abwasserrohr in unserer Straßenkrieg-Karte hineingelangen würde. Aus diesem Grund mussten wir einen Bereich mit Rutschen und Sprüngen zum Eingang der Zitadelle kreieren, der diese miteinander verband."
N/A4083"#commentary\cn_170_citadel_steep_landing.mp3" "[ Randy Lundeen ] Die Zitadelle entstand erst sehr spät in der Entwicklung und wir hatten anfangs keine klare Vision für ihr Gameplay. Das ist nicht ungewöhnlich – obwohl das Gamedesign normalerweise unseren Prozess bestimmt, erfordern wichtige kreative Entscheidungen, die wir früh treffen, wie die Existenz der Combine-Zitadelle, spezifische Designarbeit, um in das finale Produkt zu passen. Nach dem Höhepunkt der Schlacht im vorherigen Kapitel dachten wir, dass eine andere Atmosphäre für das Finale hier in der Zitadelle lohnender wäre. Selbst wenn wir die Spannung hochdrehen wollten, war es zu riskant, zu diesem späten Zeitpunkt neue Mechaniken und NPCs einzuführen. Unser erster Plan war, ein passives narratives Spektakel daraus zu machen – eine Zugfahrt durch das Herz der Combine-Kriegsmaschine, die in Breens Büro endet. Nachdem wir diesen Plan entwickelt hatten, verbrachten wir einige Tage damit, Prototypen für die Mechanik des Super-Gravitrons zu entwickeln. Wir dachten, wir könnten am Ende des Spiels die Wünsche der Spieler erfüllen, und sie allmächtig machen, ohne die Gesamtbalance des Spieldesigns zu stören. Die Ergebnisse waren sofort vielversprechend und führten zu einer kurzfristigen Neugestaltung, um den Super-Gravitron zu integrieren. Anstelle von herkömmlichen Endgame-Herausforderungen wollten wir, dass sich der Spieler gottgleich fühlt - er sollte Gegner nach Belieben packen und Konsolen von den Wänden reißen können. Letztendlich verbindet die Zitadelle diese beiden Konzepte und wechselt zwischen Spektakel und unbändiger Macht."
N/A4084"#commentary\cn_172_lightmap_pass.mp3" "[ Mike Dussault ] Das Innere der Zitadelle ist geometrisch relativ schlicht gehalten, jedoch sollten das Combine-Metallmaterial und die dramatische Beleuchtung einen Eindruck von der Unermesslichkeit der Struktur vermitteln. Die Lightmap-Auflösung wurde bei wichtigen, interessanten Oberflächen erhöht und bei anderen reduziert, die vollständig in den Schatten oder weit entfernt erscheinen sollten. Aufgrund der Größe der Zitadellenräume führten unnötig große Lightmap-Oberflächen auch zu erheblichen Performance-Kosten. Am Ende der Entwicklung führten wir eine umfangreiche Analyse der Zitadellenlevel durch, um das visuelle Interesse und die Performance zu optimieren. Dies wurde durch eine neue Funktion des Hammer-Level-Editors erleichtert, die die Oberflächen mit ihrer Luxel-Dichte anzeigte."
N/A4085"#commentary\cn_173_super_gravity_origins.mp3" "[ Brian Jacobson ] Zu diesem Zeitpunkt in der Entwicklung waren wir uns über das Design des Gravitrons einig. Wir wollten, dass Spieler sich allmächtig fühlen, und begannen, an einer extremeren Version zu arbeiten. Es dauerte nicht lange (etwa einen Tag für die Entwicklung des Prototyps), bis wir etwas gefunden hatten, was wir mochten, und es wurde zum Kern des Gameplays in der Zitadelle. Nach Abschluss der Entwicklung unserer Physik-Engine war es uns möglich, neue und aufregende Möglichkeiten zu entdecken, bisherige Grenzen zu überwinden und unsere Vorteile aus den daraus gewonnenen Erkenntnissen zu ziehen. Aus unserem Prototyp-Objekt, einer ultraschweren, in unserer Physiksimulation Hunderte Kilogramm wiegenden Wassermelone, wurde letztlich der Combine-Ball im Spiel."
N/A4086"#commentary\cn_174_combine_energy.mp3" "[ Brian Jacobson ] Was in Prototyp-Form als Wassermelone begann, entwickelte sich schließlich zu einem Energieball, nachdem die Geräusche für Aufprall und Explosion weniger nach Obst und Gemüse klangen, sondern mehr nach dem, was wir hier im Spiel haben. Als wir anfingen, Level zu entwickeln, die nicht auf Wassermelonen basierten, wurde uns klar, dass wir den Energieball nicht nur als lustige Möglichkeit zum Töten von Soldaten verwenden konnten, sondern auch als Puzzle-Element zum Ein- und Ausschalten verschiedener Geräte. Zu einem deutlich späteren Zeitpunkt in der Entwicklung gefiel uns das damals vorhandene Alternativfeuer der AR2 nicht mehr, und da dem Team der Combine-Ball gefallen hat, haben wir ihn schließlich direkt in das AR2-Alternativfeuer integriert. Wir blicken immer wieder zurück und sind überrascht, wie oft Dinge, die im Spiel unabhängig voneinander sind, später zusammenkommen und Probleme lösen."
N/A4087"#commentary\cn_175_combine_wall_and_balls_training.mp3" "[ Ido Magal ] In Spieltests bemerkten die Spieler nicht, dass die Combine-Bälle die Soldaten auflösten und warum sie verschwanden. Wir versuchten zunächst, dieses Problem zu lösen, indem wir die Bälle bevorzugt in Richtung Gegner hüpfen ließen, um die Wahrscheinlichkeit zu erhöhen, dass sie sie auflösen. Wir erkannten schließlich, dass die Spieler den Effekt nicht bemerkten, weil er immer während intensiver Kämpfe auftrat und Menschen unter Stress nur sehr begrenzt in der Lage sind, neue Dinge aufzunehmen. Als kurzfristige Lösung fügten wir einen simplen Trainingsraum mit einem Kraftfeld hinzu, der nur durch das Greifen des Combine-Balls geöffnet werden kann. Dieser Raum wurde eigens geschaffen, um zu trainieren, wie Combine-Bälle Kraftfelder deaktivieren, und dass das Werfen der Bälle auf Soldaten diese auflösen würde. In den Spieltests war dies jedoch nur mäßig erfolgreich. Trotz unserer Bemühungen fiel es einigen Spielern schwer, die auflösende Wirkung der Geschosse zu erkennen. Uns lief die Zeit davon, also beschlossen wir, dass wir damit leben könnten, wenn nicht alle Spieler den Grund für ihren Erfolg erkannten, solange sie sich immer noch mächtig fühlten."
N/A4088"#commentary\cn_176_weapon_strip.mp3" "[ Josh Weier ] Nachdem wir das Super-Gravitron eingeführt hatten, wollten wir nicht, dass Spieler zu ihren konventionellen Waffen zurückkehren. Deshalb haben wir sie einfach desintegriert. Es half auch, einen mysteriösen Gegner wie die Combine als Gegner zu haben, da es naheliegt, dass sie einen Desintegrator besitzen. Warum auch nicht? Und falls man seine Ausrüstung mitten im Level doch wieder benötigt ... Was sagt man dazu? Sie haben sogar einen Reintegrator."
N/A4089"#commentary\cn_177_breen_monologue.mp3" "[ Marc Laidlaw ] Kreative Arbeiten entstehen nicht in einem Vakuum, da wir alle von anderen Dingen inspiriert werden. Breens Monolog hier auf den Monitoren der Zitadelle wurde von einem früheren, von uns allen geliebten Spiel inspiriert: Thief 2. Darin verspottet der Antagonist den herumschleichenden Spieler. Die Durchführung war zwar anders, aber die Kerninspiration ist auf jeden Fall da. Die herausragende Leistung des verstorbenen Robert Culp ist es, die diesen Moment so richtig zur Geltung bringt. Seine Darbietung war perfekt. Seine Interpretation von Breens Monolog war so feinsinnig, dass sie dem Charakter auf dem Papier ein einzigartiges Leben einhauchte. Eine Aufnahme mit Robert Culp war unglaublich einfach. Er hatte das Skript und der Toningenieur musste nur auf Aufnehmen drücken. Das war's. Die Lektion hier ist, dass man immer mit Leuten arbeiten sollte, die talentierter sind als man selbst, von denen man lernen kann. Man sollte nicht mit einer festen Vorstellung davon reingehen, wie die Zeilen rübergebracht werden sollten oder wie ein bestimmter Moment ablaufen sollte. Stattdessen sollte man mit talentierten Leuten zusammenarbeiten und darauf vertrauen, dass sie es noch besser machen."
N/A4090"#commentary\cn_178_dissolved_weapons.mp3" "[ Quintin Doroquez ] Alle Combine-Waffen waren darauf ausgelegt, sich aufzulösen, nachdem Combine-Soldaten zu Ragdolls wurden. Erstens wollten wir verhindern, dass Spieler diese Waffen aufheben und verwenden. Zweitens führte das zu einer Verbesserung der Performance auf diesen Karten. Zusätzlich wurde ein Ragdoll-Manager hinzugefügt, der die Ragdoll-Leichen der gefallenen Soldaten entfernt, sobald der Spieler weitergeht."
N/A4091"#commentary\cn_179_elevator_fight.mp3" "[ Brian Jacobson ] Obwohl wir wollten, dass der Spieler sich allmächtig fühlt, konnten wir der Versuchung nicht widerstehen, einen harten Kampf beim Aufzugsschacht einzubauen. Der Kampf vor der Ankunft des Aufzugs gestaltete sich als schwieriger, als wir es ursprünglich für diesen Teil des Spiels vorgesehen hatten. Während der Spieltests wurde er einfacher, jedoch hatten wir nicht ausreichend Zeit, um den Kampf auf das richtige Maß auszubalancieren. Obwohl der Spieler nie ernsthaft in Gefahr ist, macht die schiere Anzahl an Soldaten diese Begegnung zum ultimativen Kampf."
N/A4092"#commentary\cn_180_replacing_the_prefabs.mp3" "[ Jeff Lane ] Die Combine-Energiekugeln sind sehr einfach aufgebaut: Sie bestehen aus einem Kraftfeld, das die ständig hüpfenden Objekte enthält. In Spieltests führten die umherspringenden Energiekugeln jedoch wiederholt zu Fehlern. Sie entwickelten ein unerwünschtes Eigenleben und \"entkamen\" dem Kraftfeld, das sie eigentlich festhalten sollten. Aufgrund der Einschränkungen unserer damaligen Prefab-Technologie war es notwendig, die Energiebälle mehrfach manuell zu erstellen: an jedem Ort und in jedem Zitadellen-Level, in dem sie vorkamen."
N/A4093"#commentary\cn_181_strider_fight.mp3" "[ Ted Backman ] In einem der Prototypen der Zitadelle konnten Spieler einen Strider mit dem Super-Gravitron greifen. Im Kampf gegen den Strider ging es lange Zeit darum, nahe genug heranzukommen, um ihn mit dem Super-Gravitron zu fassen. Gegen Ende der Entwicklung entschieden wir jedoch, dass die zu schwach wirken würden, wenn man sie mit dem Super-Gravitron greifen könnte, insbesondere nach all den Kämpfen gegen sie während des Straßenkriegs. Aus diesem Grund ersetzen wir diese Begegnung durch eine, in der Spieler einen Strider mit Combine-Bällen töten. Modell-Teile wurden hinzugefügt, um den Strider zu zerreißen und zu sprengen, statt seinen Körper herumzuzerren. Dies ist das einzige Mal im Spiel, dass ein Strider diesen Effekt hat."
N/A4094"#commentary\cn_182_getting_in_the_pod.mp3" "[ Dhabih Eng ] Die hier beginnende Kapselaufstiegssequenz erforderte unsere volle Kontrolle über die Szene und den Spieler. Dies steht im Widerspruch zu unserem normalen Bedürfnis, dem Spieler so viel Kontrolle wie möglich zu geben. Wir hatten jedoch das Gefühl, dass der Kompromiss für diesen letzten Schritt es wert war. Zu diesem Zeitpunkt war der Spieler derart mächtig, dass es schwierig war, ihn zu kontrollieren. Aus diesem Grund mussten wir ihn außer Gefecht setzen. In der Szene gibt es noch immer Charaktere, die mit dem Spieler kommunizieren und seine Aufmerksamkeit auf sich lenken. Wir erzählen sogar unterwegs über die Umgebung eine Geschichte. Die hier beginnende Zugfahrt durch die Zitadelle zeigt einige Gegner, für die wir zwar Artwork hatten, dir aber aus dem Hauptteil des Spiels entfernt werden mussten. Aus der Sicherheit Ihrer gemütlichen Kapsel können Sie die Manufaktur der Stalker beobachten und einen kurzen Blick auf den Krabben-Synth werfen."
N/A4095"#commentary\cn_183_turrets.mp3" "[ Mike Dussault ] Türme waren ein hilfreiches Designmittel, wenn Spieler Köder besaßen, um zu verhindern, dass Ameisenlöwen direkt auf sie zulaufen. So konnten wir Situationen schaffen, in denen Spieler nicht einfach Köder werfen konnten, um weiterzukommen. Sie mussten die Türme umgehen, um sie zerstören zu können, damit ihnen die Ameisenlöwen folgen konnten. Außerdem sah es gut aus, wenn der Turmbeschuss die Ameisenlöwen niedermähte."
N/A4096"#commentary\cn_184_grenade_puzzle.mp3" "[ Aaron Seeler ] In vielen Spieltests blieben Spieler stecken, da sich die Kiste mit den unbegrenzten Granaten auf dem Pfad hinter ihnen befand. Zu diesem Zeitpunkt im Spiel hatten Spieler bereits gelernt, Kisten mit unbegrenzter Munition mit Rätsellösungen zu assoziieren. Beim Anblick einer Kiste mit Granaten würden Spieler sofort erkennen, dass sie zur Lösung des Problems Granaten einsetzen müssen. Wir wollten, dass sie erst einmal etwas nachdenken müssen. Letztlich wiesen wir durch die Platzierung von Granaten auf einem Schreibtisch hinter einem Fenster subtil auf ihre Verfügbarkeit hin. Hierdurch entdeckten wir in einem Spieltest auch einen Fehler, durch den Spieler die Granaten durch das Glas hindurch aufsammeln konnten, wenn sie nur nah genug herangingen."
N/A4097"#commentary\cn_185_allied_turrets_balancing.mp3" "[ Adrian Finol ] Es war eine Herausforderung, diesen Kampf rund um die verbündeten Türme zu balancen. Die Türme sind hier das neue Element. Wenn die Spieler sie ignorieren, fühlt sich das Gameplay langweilig an, weil so viel von dem, was vorher kam, ähnlich ist. Wir wollten den Einsatz der Türme erzwingen und ihre strategische Platzierung belohnen, aber das war sehr zweigeteilt – perfekte Platzierung machte den Kampf einfach, während schlechte Platzierung ihn sehr schwierig machte. Feintuning und die angepasste Logik der Soldaten-KI halfen dabei: Die Soldaten wurden besser darin, Türme zu zerstören, indem sie Granaten warfen oder sie flankierten. Durch diese Änderungen ging es im Kampf weniger um eine perfekte Aufstellung als vielmehr um die aktive Aufrechterhaltung der Türme, da sie irgendwann alle zerstört werden würden. Die Spieltests fielen sehr unterschiedlich aus. Einige Spieler fanden den Kampf zu schwer, während andere ihn als ihren Lieblingskampf bezeichneten. Da uns die Zeit davonlief, haben wir ihn schließlich etwas leichter gemacht und so veröffentlicht, obwohl wir mit der endgültigen Balance nicht zufrieden waren."
N/A4098"#commentary\cn_186_meeting_mossman.mp3" "[ Ariel Diaz ] Den Spieler und Alyx nach dem Verrat wieder mit Mossman zu vereinen, war schwierig, da viele Spieler Mossman sofort erschießen wollten. Das konnten wir nicht zulassen, da wir keine Zeit hatten, alternative Handlungsstränge zu entwickeln. Allerdings wollten wir auch nicht offensichtlich machen, dass wir diese Option verhindern, also wollten wir die Wahrscheinlichkeit verringern, dass die Spieler es versuchen. Das kugelsichere Glas verschafft Zeit für einen Dialog zwischen Alyx und Mossman, in dem deutlich wird, dass Alyx nicht glaubt, dass es richtig ist, Mossman zu erschießen."
N/A4099"#commentary\cn_187_eli_in_pod_choreography.mp3" "[ Ken Birdwell ] Wir haben die Dialoge für diese Szene geschrieben und aufgenommen, während wir noch an Nova Prospekt arbeiteten. Zu diesem Zeitpunkt wussten wir, dass Alyx und Gordon aus dem Gefängnis teleportiert werden sollten, aber die Details waren noch nicht ausgearbeitet. Daher mussten die Dialoge allgemein genug sein, um zu dem zu passen, was wir letztendlich entwickeln würden. Das führte dazu, dass wir uns weniger auf die Handlungen des Spielers konzentrierten, sondern mehr auf Alyx' Verletzlichkeit und ihre Verbindung zu ihrem Vater. Wir hofften, dass die Emotionen die Szene stärker prägen würden als die Story an sich. Letztendlich wollten wir, dass sich die Spieler für diese Charaktere interessieren – dass sie das priorisieren, was Alyx wichtig ist."
N/A4100"#commentary\cn_188_mossman_and_eli.mp3" "[ Bill Van Buren ] Diese Choreo-Szene erforderte viele Iterationen. Wir wollten mitten in der Szene eine unerwartete Wendung einbauen, ohne die Kontrolle der Spieler einzuschränken. Es erforderte ein feines Gleichgewicht, diese unerwartete Wendung deutlich zu machen und gleichzeitig sicherzustellen, dass sie nicht unterbrochen werden konnte. Wenn die Spieler Alyx zur Konsole folgten, mussten sie verstehen, was passierte, als sie sich umdrehten. Wenn sie zurückblieben und Mossman beobachteten, mussten sie verstehen, was passierte, ohne das Gefühl zu haben, dass sie es verhindern sollten. Es erforderte umfangreiche Feinabstimmungen und Spieltests, um das richtige Timing zu finden, aber letztendlich setzten wir auf eine Kombination aus Ablenkung, der schnellen Darstellung des entscheidenden Moments und einer abschließenden Erklärung im Nachhinein."
N/A4101"#commentary\cn_189_nova_prospekt_entry.mp3" "[ Danika Rogers ] Der Spieler hat gerade zwei kampflastige Level hinter sich, also wollten wir die Dinge entschleunigen, sobald er im Inneren ist. Diese frühen Level waren als Tempowechsel gedacht, um dem Spieler die Möglichkeit zu geben, die Innenräume von Nova Prospekt zu erkunden. Nebenbei begannen wir, das Turm-Gameplay einzuführen, zunächst als Feind für den Spieler und später als Werkzeug, das er benutzen kann. Ein Großteil dieses Levels wurde durch die Wiederverwendung von Prototypen und Grafiken erstellt, die zu einem früheren Zeitpunkt des Projekts entstanden, als wir uns auf die Gestaltung des Aussehens von Nova Prospekt konzentrierten."
N/A4102"#commentary\cn_190_turret_training_exit.mp3" "[ Doug Wood ] Dieser Müllhaufen und das Durcheinander auf der Treppe sollen die Spieler davon abhalten, einen Turm mitzunehmen. Es würde zwar nichts kaputtmachen, wenn sie es täten, aber wir wollten es weniger wahrscheinlich machen. Es ist keine ideale Designstrategie, es den Spielern zu erschweren, den Turm mitzunehmen, aber es war besser als nichts. Viele Testspieler gaben schließlich auf und legten den Turm beiseite, als sie das Gefühl hatten, das Spiel wolle ihnen etwas mitteilen."
N/A4103"#commentary\cn_191_allied_antlions.mp3" "[ Eric Kirchmer ] Mit einer endlosen Armee von Ameisenlöwen, die Türme und Soldaten angreifen, mussten wir uns Zeit nehmen, um die Rolle des Spielers in den Kämpfen von Nova Prospekt festzulegen. Der Spieler hatte es bereits mit vielen Soldaten der Combine zu tun, also beschlossen wir, dass sich der Kampf hier eher wie ein Puzzle und ein Spektakel anfühlen sollte, als eine Kampfherausforderung. Deshalb haben wir Szenarien geschaffen, die stabil blieben, bis der Spieler eingriff. Durch das direkte Töten von Feinden konnte der Spieler das Gleichgewicht zugunsten der Ameisenlöwen verschieben – aber wir wollten, dass sich der Einsatz von Ködern besonders lohnt. In vielen Szenarien aktivierten wir, wenn der Spieler Köder auf Feinde warf, zusätzliche Ameisenlöwen-Spawner, die einen schnellen Ansturm neuer Ameisenlöwen auf den Kampf auslösten. Das daraus resultierende Gemetzel war die Belohnung, die den Einsatz von Ködern so befriedigend machte."
N/A4104"#commentary\cn_192_laser_mines.mp3" "[ Erik Johnson ] Es hat uns großen Spaß gemacht, diese Laser-Tretminen in Nova Prospekt einzubauen. Sie waren eine Waffe aus Half-Life 1, die wir in Half-Life 2 nicht mehr unterbringen konnten, aber immerhin fanden sie ihren Platz als Puzzle-Element. Uns gefiel, wie sie als eine Art persönlicher Moraltest dienten, wenn der Spieler eine Ameisenlöwen-Armee hatte. Manche Spieler warfen sofort Köder über die Tretminen und schickten Ameisenlöwen auf das Problem, während andere ihre kleinen Kumpels zurückhielten, bis sie die Tretminen mit anderen Werkzeugen sicher entfernt hatten. Wir haben dabei niemanden verurteilt."
N/A4105"#commentary\cn_193_final_turret_arena.mp3" "[ Erik Johnson ] Wenn wir ein Gameplay-Element erstellten, wie z. B. die Nutzung von Türmen durch Verbündete, bauen wir oft zuerst einen Prototyp, der den Endpunkt abbildet. Wir iterieren diesen Prototyp, bis die Spieltests zeigen, dass er funktioniert. Dann arbeiten wir rückwärts und fügen vorhergehende Szenarien hinzu, um das Element einzuführen und die Fähigkeiten der Spieler zu verbessern. Auf diese Weise stellen wir sicher, dass der endgültige Spielbogen ansprechend ist, bevor wir viel Zeit investieren. Das bedeutet auch, dass wir zu dem Zeitpunkt, an dem wir Trainingsszenarien erstellen, genügend Spieltests beobachtet haben, um zu wissen, welche Techniken angelernt werden müssen und welche die Spieler ganz natürlich begreifen. Dieses letzte Turmszenario war unser Ziel, da es die Verteidigung des Spielers gegen Feinde aus mehreren Richtungen betonte und eine dynamische Platzierung und Aufnahme der Türme erforderte."
N/A4106"#commentary\cn_194_one_way_drops.mp3" "[ Jakob Jungels ] Spieler wissen nie, was vor ihnen liegt, aber sie kennen die Umgebung hinter sich. Daher ziehen sie sich häufig auf vertrautes Terrain zurück, wenn sie auf einen Gegner treffen. Bei einer Arena, in der der Spieler angreifen soll – insbesondere bei einem Feind mit besonderen geometrischen Anforderungen wie der Ameisenwache – brauchen wir also eine Möglichkeit, diesen Rückzug zu verhindern. Häufig wird der Spieler daher gezwungen, die Arena durch eine Art \"Einbahnstraße\" zu betreten – etwas, das Ihnen wahrscheinlich schon ein paar Mal aufgefallen ist."
N/A4107"#commentary\cn_195_npcs_on_elevators.mp3" "[ Jay Stelly ] Wir verbringen oft viel Zeit damit, Probleme zu lösen, die den Spielern vielleicht gar nicht auffallen. Viele davon sind subtile Design-Herausforderungen, während andere auf die Interaktion mehrerer Systeme zurückzuführen sind. Beispielsweise war es ein komplexes Problem, NPCs in Aufzügen fahren zu lassen, da verschiedene Systeme beteiligt waren – die Entscheidungsfindung der NPC-KI, die Navigationsplanung und die Bewegungssimulation, um nur einige zu nennen. Darüber hinaus hatte der Aufzug selbst seine eigenen Simulationsanforderungen, die nichts mit den NPCs zu tun hatten. Eine der subtileren Herausforderungen ergab sich daraus, dass wir NPCs langsamer simulieren als Aufzüge. Das bedeutete, dass NPCs in einem abwärtsfahrenden Aufzug simuliert wurden – um sicherzustellen, dass sie richtig im Aufzug standen – und dann wurde der Aufzug selbst einige Male simuliert, wobei er sich jedes Mal weiter den Aufzugsschacht hinunterbewegte und den NPC unmerklich zurückließ. Kurz darauf wurde der NPC ein zweites Mal simuliert und landete erneut auf dem Boden des Aufzugs. Sie können sich vorstellen, dass es schwer war, Alyx ernst zu nehmen, wenn sie ständig schrittweise nach unten fiel, während sie mit einem sprach."
N/A4108"#commentary\cn_196_looktargets.mp3" "[ John Cook ] Eines der wichtigsten Werkzeuge in unserem Design-Toolkit ist das \"Looktarget\" – ein unsichtbarer Punkt im Raum, der aktiviert wird, wenn der Spieler ihn ansieht. Designer können festlegen, wie genau der Spieler ihn ansehen muss, wie lange er hinschauen muss und andere Bedingungen. Einmal aktiviert, löst das Looktarget verschiedene Ereignisse im Spiel aus. Beispielsweise könnte Alyx warten, bis der Spieler sie ansieht, bevor sie einen Dialog spricht; ein Spektakel könnte erst beginnen, wenn es sichtbar ist; oder ein Combine-Landungsschiff könnte überfliegen, wenn der Spieler in seine Richtung blickt. Nachdem wir Looktargets implementiert hatten, fanden Designer unzählige Möglichkeiten, sie zu nutzen, um das Gameplay für die Spieler zuverlässiger zu gestalten, insbesondere da sich manche Looktargets mit sehr unterschiedlichen Geschwindigkeiten oder auf schwer vorhersehbare Weise bewegen."
N/A4109"#commentary\cn_197_nova_prospekt_yard.mp3" "[ John Morello ] Die Kämpfe auf Nova Prospekt wurden weitgehend von unseren frühen Beobachtungen der Ameisenlöwen im Kampf gegen die Combine-Soldaten inspiriert. Die hohe Mobilität der Ameisenlöwen und ihre Nahkampfangriffe passten gut zu den tödlichen Fernkampfwaffen der Soldaten und ihrer Verwundbarkeit im Nahkampf. Ameisenlöwen sehen unter Beschuss großartig aus, mit Partikeleffekten, die überall herumfliegen, und wenn sie schließlich einen Soldaten erreichen, ist der daraus resultierende Ragdoll-Effekt unglaublich befriedigend."
N/A4110"#commentary\cn_198_vent.mp3" "[ John Morello ] Das wissen wahrscheinlich alle, aber wo es einen Luftschacht gibt, muss auch eine Kopfkrabbe drin sein. Wir machen diese Regeln nicht, sie kommen, wie die Schächte selbst, direkt von oben."
N/A4111"#commentary\cn_199_kitchen.mp3" "[ Kerry Davis ] Unter Spieleentwicklern ist es lange Brauch, dass es in allen Videospielküchen eine Gasexplosion geben muss."
N/A4112"#commentary\cn_200_alyxs_tool.mp3" "[ Laura Dubuk ] Das Multifunktionswerkzeug von Alyx war unglaublich nützlich, weil wir sie so als Schlüssel benutzen konnten. Oft mussten wir den Spieler davon abhalten, weiterzugehen, bis wir bereit waren, und ihr Werkzeug ermöglichte es ihr, Dialoge zu führen und gleichzeitig den Weg freizumachen. Wahrscheinlich haben wir uns ein bisschen zu sehr darauf verlassen, aber es war schwer, ihr zu widerstehen. Man muss immer einen Kompromiss eingehen – wenn wir Alyx zum Öffnen eines Raums verwenden, anstatt eine eigene Lösung zu entwickeln, sparen wir Zeit, die wir für andere, oft wichtigere Teile des Spiels verwenden können."
N/A4113"#commentary\cn_201_mossmans_betrayal.mp3" "[ Marc Laidlaw ] Unser ursprünglicher Plan für Judith Mossmans Geschichte war, dass sie den Spieler an dieser Stelle verrät. Aber als wir zu dieser Szene kamen und andere Teile des Spiels entwickelt hatten, hatten wir das Gefühl, dass sie eher versuchen würde, Eli zu beschützen. Wir stellten uns vor, dass sie es sich noch einmal überlegt und erkennt, dass sie Gordon nicht wirklich verraten kann. Wir hatten Ideen, um diesen Wandel später zu verdeutlichen, aber letztendlich haben wir ihren Handlungsbogen nie abgeschlossen. Wir mochten die Zweideutigkeit von Mossman, aber die Spieler schienen sie nicht zu mögen – sie hassten sie fast durchweg. Das könnte allerdings ein Erfolg sein. Wir haben hart daran gearbeitet, die Sympathie der Spieler für Alyx aufzubauen, und Alyx war auch nicht gerade ein Fan von Judith."
N/A4114"#commentary\cn_202_d2_prison_05_start.mp3" "[ Yahn Bernier ] Da der Spieler eine große Anzahl von Objekten bewegen kann, stießen wir oft auf Herausforderungen, insbesondere angesichts der Einschränkungen der CPUs von 2003. Eine Einschränkung bestand darin, dass unser KI-Navigationssystem dynamische Physikobjekte wie diese Metallbetten nicht erkannte. Unser NPC-Bewegungssystem konnte zwar Physikobjekte während der Bewegung erkennen und vermeiden, aber bei Navigationsabfragen zur strategischen Planung vor der Bewegung waren sie praktisch unsichtbar. Dies lag hauptsächlich an Performance-Einschränkungen – wir konnten uns keine komplexeren Lösungen leisten. Wir standen auch vor Designherausforderungen ohne klare Lösungen, beispielsweise wie ein Soldat reagieren sollte, wenn ein Spieler einen Korridor vollständig mit großen Gegenständen blockiert. Um dies zu beheben, gaben wir NPCs zusätzliche Kraft, um Gegenstände herumzuschieben. Wir entschärften das Problem dann durch Leveldesign, indem wir die Korridore verbreiterten und genügend Freiraum für Requisiten schufen, die irgendwo darin landen konnten. Dieses Set-up birgt ein hohes Risiko: Die Kombination aus Soldaten, die sich hinter Betten verstecken, und Ameisenlöwen, die zu Nahkampfangriffen ansetzten, ermöglichte ungünstige Interaktionen zwischen dem NPC-Bewegungssystem und den Betten."
N/A4115"#commentary\cn_203_alyx_as_companion.mp3" "[ Miles Estes ] Dieser Abschnitt wurde unbeabsichtigt zu einem Prototyp für das, was Episode 1 schließlich ausmachen sollte: Alyx als Begleiterin, die sich flüssig auf einem Weg bewegt, der dynamische Kämpfe mit geskripteten Choreos verbindet. Wir hatten noch kein klares Modell dafür, wie sie dem Spieler in diesen Szenarien zur Seite stehen würde, aber selbst aus diesem kurzen Abschnitt haben wir viel gelernt, obwohl wir nicht die Zeit für ausreichend Iterationen hatten."
N/A4116"#commentary\cn_204_laundry.mp3" "[ Mike Dussault ] Wenn der Spieler dieses Level erreicht hat, die Wäscherei, sind wir zuversichtlich, dass er Köder gut einsetzen kann, um Kampfszenarien zu lösen. Daher wollten wir den Einsatz ein wenig erhöhen, indem wir ein Szenario kreierten, das den Spieler dazu ermutigt, sich noch mehr zu engagieren, indem er den Köder mit seinem gesamten Waffenarsenal kombiniert."
N/A4117"#commentary\cn_205_side_zombie.mp3" "[ Quintin Doroquez ] Dieser Giftzombie war bei den Spieltests immer ein Highlight. Die Spieler, die sich so auf Combine-Soldaten, Ameisenlöwen und Türme konzentrierten, hatten schon lange keinen Giftzombie mehr gesehen, sodass sein plötzliches Auftauchen im Dunkeln oft für einen Schockmoment sorgte."
N/A4118"#commentary\cn_206_flares.mp3" "[ Quintin Doroquez ] Dieser Abschnitt ist ein schöner Gegenpol zum vorherigen Turmsegment, was Produktionskosten und Iterationen angeht. Er wurde erst sehr spät entwickelt, konnte aber schnell umgesetzt werden, da die KI für Alyx und den Combine-Soldaten bereits ausgereift war. Uns gefielen besonders die Dunkelheit und die Fackeln und wir speicherten es als etwas ab, das wir weiter ausbauen wollten. Später haben wir es bei der Planung der dunklen Abschnitte in Episode 1 wieder aufgegriffen."
N/A4119"#commentary\cn_207_magic_wall.mp3" "[ Robin Walker ] Wie in vielen unserer Kampfarenen brauchten wir eine Art Tor, um Spieler daran zu hindern, weiterzugehen, bevor sie den Kampf beendet hatten. Leider hatten wir keine Zeit mehr und mussten weiter am Bahnhof arbeiten, also haben wir uns diesen magischen Schwachsinn ausgedacht: eine Wand, die einfach explodiert, nachdem der zweite Hubschrauber besiegt wurde, und den Weg nach vorne freimacht. Wir gingen davon aus, dass die meisten Spieler es nicht bemerken würden, da sie mit dem Kampf gegen die Hubschrauber beschäftigt wären, und unsere Spieltests hatten gezeigt, dass sie den Kampf in der Regel alle beendet hatten, bevor sie diesen Punkt erreichten. Bei genügend Explosionen in der gesamten Arena fühlte sich die zerstörte, brennende Wand ziemlich natürlich an, also haben wir auf der anderen Seite ein paar einfache Gas-Rätsel eingebaut, um sie zu rechtfertigen. Aber nein, wir sind nicht gerade stolz darauf."
N/A4120"#commentary\cn_208_ragdoll_vortigaunt.mp3" "[ Scott Dalton ] Man kann in diesem toten Vortigaunt eine Menge Schmerz erkennen – den Schmerz unserer Leveldesigner. Unsere damaligen Entwicklungstools erlaubten es uns nicht, einer Ragdoll direkte Posen zu geben, das heißt, wenn ein NPC stirbt und automatisch wie eine Ragdoll zu Boden fällt, hatten wir keine Kontrolle darüber, in welcher Pose er letztendlich landete. Hätten die Animatoren etwas Zeit gehabt, hätten sie uns eine Einzelbildanimation in ungefähr der gewünschten Pose liefern können, aber wir waren spät dran und unser kleines Animationsteam war bereits überlastet. Also positionierte ein Leveldesigner den Vortigaunt über diesem Stuhl, ließ ihn sterben, während das Level geladen wurde, und wartete ab, welche Pose die Ragdoll einnehmen würde. Dann bewegte der Designer die Vortigaunt ein wenig und versuchte es erneut. Wir können uns nicht mehr genau daran erinnern, wie viele Versuche nötig waren, aber es waren viel, viel mehr, als man denken würde."
N/A4121"#commentary\cn_209_nova_prospekt_process.mp3" "[ Eric Smith ] Wie Ravenholm wurde auch Nova Prospekt ursprünglich mit einem deutlich anderen Gameplay entwickelt als das, womit es letztendlich veröffentlicht wurde. Die erste Version konzentrierte sich auf den Kampf zwischen Spieler und Combine-Soldaten, ohne Beteiligung von Ameisenlöwen. Anders als in anderen Bereichen des Spiels, in denen Gameplay und Grafik gemeinsam weiterentwickelt wurden, erhielt Nova Prospekt schon früh eine große Kunstspritze. Dies führte zu einer Reihe von wiederverwendbaren, ausgefeilten Abschnitten der Levelgeometrie, die bereits mit Grafiken versehen waren. Der Zusammenbau von Nova Prospekt aus diesen Teilen funktionierte gut, da sich das Layout des Gefängnisses von Natur aus wiederholte. Als wir dann später mit Ameisenlöwen und Ködern zurückkehrten, mussten wir die Geometrie umgestalten, um sie an das neue Gameplay anzupassen."
N/A4122"#commentary\cn_210_d2_prison_04.mp3" "[ Eric Kirchmer ] Während der Entwicklung erstellten unsere Künstler kleine vertikale Ausschnitte von Umgebungen, die wir \"Kunst-Zoos\" nannten. Diese Zoos zeigten, wie wir mit Texturen und Requisiten Gameplay-Szenen schaffen konnten, die unseren visuellen Zielen entsprachen. Beim Erstellen des Gameplay-Tracks des Gefängnisses ermöglichte uns das sich wiederholende Layout jedoch einen direkteren Einsatz der Kunst. Diese Karte wurde ursprünglich als primärer Kunst-Zoo für Nova Prospekt erstellt, wurde aber nach dem Testen verschiedener Gameplay-Prototypen – darunter auch solcher, die schließlich zu Ködern führten – Teil der eigentlichen Levelarchitektur."
N/A4123"#commentary\cn_211_autosave_dangerous.mp3" "[ Dave Riller ] In Half-Life 1 gab es im gesamten Spiel eine Reihe von automatischen Speicherpunkten, die von den Leveldesignern von Hand platziert wurden und ausgelöst wurden, wenn der Spieler einen bestimmten Moment oder eine bestimmte Position im Spiel erreichte. Dadurch wurde sichergestellt, dass das Spiel automatisch gespeichert wurde, während man sich durch die Korridore von Black Mesa bewegte. In Half-Life 2 brauchten wir ein neues Tool. Das Problem trat in einigen der komplexeren Arenen auf, die wir gebaut hatten. Manche dieser Begegnungen dauerten ziemlich lange und beinhalteten mehrere Gegnergruppen. Andere waren lange, ausufernde Mischungen aus Erkundung und Kampf ohne klare Trennung zwischen beidem. Wir wollen keine automatischen Speicherungen, bei denen der Spieler direkt nach dem Laden des Spiels stirbt, da dies zu einer Todesschleife führen könnte – wer damals Gamer war, weiß, wovon ich rede. Sofern wir also nicht absichtlich Pausen in den Spielablauf jeder Arena einbauten, gab es nicht immer einen sicheren Ort für automatische Speicherungen. Nach einigen Experimenten implementierten wir die Funktion \"Autosave Dangerous\". Dies war ein Leveldesigner-Tool, das eine automatische Speicherung mit einem zugehörigen Zeitrahmen kombinierte. Wenn es vom Leveldesigner ausgelöst wurde, speicherte es das Spiel sofort, hielt den Speicherstand jedoch zurück, sodass er erst mal nicht geladen werden konnte. Blieb der Spieler dann eine bestimmte Zeit lang am Leben, wurde der Speicherstand bestätigt und als aktuellster automatischer Speicherstand verwendet. Dies ermöglichte es Leveldesignern, einen automatischen Speicherstand an einem sinnvollen Ort oder zu einer sinnvollen Zeit in einer Arena zu platzieren und eine Zeit, beispielsweise 30 Sekunden, anzugeben. Wenn der Spieler dann noch 30 Sekunden am Leben war, wurde der automatische Speicherstand verwendet."
N/A4124"#commentary\cn_212_we_dont_go_to_ravenholm.mp3" "[ Dario Casali ] Als wir unsere Arbeit an Ravenholm abgeschlossen hatten, wurden wir das Gefühl nicht los, dass der Übergang von Elis Labor einfach nicht funktionierte. Er war viel zu abrupt – Elis Labor war direkt mit den Straßen der Stadt verbunden, in der Sie gleich sein werden, und der Abschnitt, in dem Sie sich befinden, existierte nicht. Wir hatten am Ende von Elis Labor gerade dieses Versprechen gegeben: \"Da geh'n wir nicht mehr hin.\" Und uns gefiel, was wir da aufgebaut hatten. Aber als der Spieler Ravenholm erreichte, wurde er sofort in den Kampf gegen Zombies geworfen, ohne dass sich Spannung aufbauen konnte. Also bauten wir diesen Abschnitt und die darauffolgenden engen Korridore, um das auf eine Weise zu beheben, mit der wir zufrieden waren. Wir haben das Tempo gedrosselt, uns auf Grafik und Beleuchtung konzentriert und Sie darauf vorbereitet, zu erleben, warum wir nicht mehr nach Ravenholm gehen."
N/A4125"#commentary\cn_213_lever_shenanigans.mp3" "[ Dario Casali ] Trotz all unserer Bemühungen, im Kopf der Spieler eine Verbindung zwischen diesem Hebel und dem äußeren Elektrozaun herzustellen, legten manche Tester den Hebel immer noch um, ohne zu wissen, was sie getan hatten. Sie irrten sogar umher, legten den Hebel wieder um und irrten weiter umher. Da uns nicht mehr viel Zeit blieb, die Verbindung klarer zu machen, entschieden wir uns, den Hebel einfach abbrechen zu lassen. Dies verhinderte, dass Spieler ihren Fortschritt rückgängig machen konnten, und verstärkte das Gefühl, Ravenholm sei ein unzuverlässiger und verfallener Ort."
N/A4126"#commentary\cn_214_town_arenas.mp3" "[ Dario Casali ] An diesem Punkt in Ravenholm hat der Spieler alle ihm zur Verfügung stehenden Gameplay-Elemente kennengelernt und kann deren Interaktionen vorhersagen. Dies ermöglicht uns, komplexere Set-ups zu erstellen, die eine größere Bedrohung darstellen und mehr Freiheiten in der Herangehensweise der Spieler an jedes Szenario bieten. Diese Arena ist ein absichtlich verschlungener Raum, den die Spieler erkunden müssen, und wir nutzen diese Erkundungszeit, um die Kampfintensität langsam zu steigern. Je schneller die Spieler erkunden, desto schneller steigern wir die Intensität. Diese freie Form des Designs machte es schwierig, den Abschnitt zu optimieren, da die Spieler eine große dynamische Bandbreite an Spielweisen zeigten."
N/A4127"#commentary\cn_215_mines.mp3" "[ Dario Casali ] Die komplexe Route, die der Spieler nimmt, um sicher durch diesen Minenschacht zu navigieren, gibt ihm jede Menge Zeit, zu sehen, was ihn unten erwartet. Und Überraschung: Es sind Kopfkrabben. Ehrlich gesagt, sind es oft Kopfkrabben. Aber in diesem Fall sind es giftige Kopfkrabben, die an sich schon lustig sind, aber ein echter Kracher werden, wenn man sie mit schnellen Kopfkrabben kombiniert. Diese beiden Arten bilden eine großartige Kombination: Keine von beiden ist für sich genommen besonders gefährlich, aber zusammen sind sie unglaublich tödlich. Einmal vergiftet, genügt ein einziger Schlag einer schnellen Kopfkrabbe, um den Spieler zu töten. Biologen nennen so etwas Symbiose. Zumindest glauben wir das."
N/A4128"#commentary\cn_216_poison_headcrabs.mp3" "[ David Speyrer ] In diesem Raum tauchen ungewollt Giftkopfkrabben auf. Wir haben viel Zeit darauf verwendet, sie später im Level richtig vorzustellen, aber als wir sahen, wie gut sie beim Testen ankamen, hat uns die Begeisterung gepackt und wir hatten sie bald über das ganze Level verteilt. Als wir merkten, dass sie vor ihrer Einführung aufgetaucht waren, war es für eine Überarbeitung eigentlich zu spät. Glücklicherweise eignet sich ein enger Raum voller Giftkopfkrabben gut als Training, da durch ihr Design ein häufiges Problem beim Kampftraining vermieden wird. Normalerweise sind Spieler gestresst und können frustriert werden, wenn sie wiederholt sterben, ohne zu verstehen, warum. Und tatsächlich stießen wir auf dieses Problem, als wir versuchten, dem Spieler sowohl die Giftkopfkrabben als auch ihre Quelle, den Giftzombie, gleichzeitig vorzustellen. Giftkopfkrabben können den Spieler jedoch nicht alleine töten. Ein Raum voller Giftkopfkrabben ist also zwar stressig, vermeidet aber zumindest vollkommenen Frust."
N/A4129"#commentary\cn_217_poison_zombie_introduction.mp3" "[ David Speyrer ] Den Spieler in einem engen Raum einzusperren und ihm gleichzeitig die Sicht nach draußen zu ermöglichen, erhöht die Wahrscheinlichkeit, dass er etwas bemerkt, das wir ihm zeigen möchten. Hier ziehen wir die Aufmerksamkeit des Spielers mit einem Schrei auf uns, bevor der Giftzombie selbst sichtbar wird. Ursprünglich war dies auch die erste Begegnung mit Giftkopfkrabben, aber wie bereits in einem früheren Kommentar erwähnt, waren wir viel zu enthusiastisch bei der Verbreitung der Giftkopfkrabben im Level und haben ihre gemeinsame Einführung hier verdorben. Letztendlich funktionierten diese ersten Begegnungen jedoch sowieso besser separat."
N/A4130"#commentary\cn_218_final_arena.mp3" "[ Eric Smith ] Als wir die erste Version von Ravenholm fertiggestellt hatten, sollte dieses Dach der krönende Abschluss sein. Wie auch andere Orte in Ravenholm war es zu Beginn ein Ort, der sich ausschließlich darauf konzentrierte, interessant auszusehen. Wir hielten es für wichtig, dass der Spieler, wenn er Ravenholm verlässt, einen Moment Zeit hat, um auf die Stadt zurückzublicken, die er gerade überlebt hat, und einen Blick darauf zu erhaschen, wohin er als Nächstes geht. Es gab mehrere Gameplay-Gruppen, die versuchten, hier einen Kampf zu entwickeln, aber die enge Geometrie und die Performance-Beschränkungen bedeuteten, dass wir nie wirklich ein Finale schaffen konnten, mit dem wir zufrieden waren. Ähnlich wie die Half-Life-Saga selbst schien es, als sei Ravenholm dazu bestimmt, kein richtiges Ende zu haben."
N/A4131"#commentary\cn_219_tables_and_bodies.mp3" "[ Ido Magal ] Gegen Ende der Entwicklung von Ravenholm, als alle wichtigen Teile vorhanden waren, gingen wir durch und versuchten, jeden leeren Platz mit etwas Interessantem zu füllen. Dabei mussten wir darauf achten, das zu verwenden, was wir bereits hatten, und nichts Neues zu schaffen, da wir nicht riskieren konnten, noch mehr Fehler einzuführen. Oftmals, wie in diesem Raum, versuchten wir, neue Gameplay-Moment hinzuzufügen und gleichzeitig den Bereich mit mehr Details und Storytelling zu versehen. Kleine Szenen wie diese ermöglichen es einem aufmerksamen Spieler, darüber nachzudenken, was er sieht und was es für seine nächsten Begegnungen bedeuten könnte."
N/A4132"#commentary\cn_220_physics_object_consistency.mp3" "[ Kerry Davis ] Alle Physikobjekte haben eine Vielzahl von Parametern, die ihr Verhalten definieren: ihre Masse, die Menge an Schaden, die sie erleiden, bevor sie zerbrechen, in was sie zerbrechen und so weiter. Während der Entwicklung wurden diese Parameter von den Leveldesignern für jedes Objekt festgelegt, und so funktionierten die meisten Dinge im Spiel. Doch später in der Entwicklung merkten wir, dass wir uns selbst ein Problem geschaffen hatten – es gab Tausende von Physikobjekten im Spiel und keine Methode, um ihre Konsistenz zu gewährleisten. Infolgedessen konnte ein Karton in einem Level durch einen einzigen Pistolenschuss zerbrechen und in einem anderen völlig unverwundbar sein. Intern bezeichneten wir diese Inkonsistenzen im Allgemeinen als \"Verbrechen\" der Leveldesigner. Um diese zu beheben und für Gerechtigkeit zu sorgen, entwickelten wir ein System, das die Konsistenz aller Physikobjekte basierend auf ihrem visuellen Modell erzwang. Da der Großteil des Spiels bereits fertig war, mussten wir den Leveldesignern erlauben, dieses System in seltenen Ausnahmefällen, in denen sie etwas Verbrecherisches tun mussten, um ihr Design zu bewahren, explizit zu deaktivieren. Intern bezeichnen wir diese Designer als \"Wiederholungstäter\", von denen einige ihr Leben als Kriminelle bei Valve bis zum heutigen Tag fortsetzen."
N/A4133"#commentary\cn_222_fast_zombie_introduction.mp3" "[ Randy Lundeen ] Dieser Bereich wurde ursprünglich für die E3 2003 gebaut und zeigte den Spieler im Kampf gegen eine Truppe Combine-Soldaten. Als wir ihn wieder nutzten, um den schnellen Zombie vorzustellen, versuchten wir, so viel wie möglich von der vorherigen Arbeit beizubehalten. Wir wollten eine ikonische Mondlichtaufnahme, in der Zombies wie Werwölfe am Mond vorbeispringen, um die Aufmerksamkeit des Spielers zu erregen. Sobald dieser Moment vorbei ist, bringen wir den ersten schnellen Zombie zum Bereich des Spielers und lassen ihn auf ihn los. Es waren viele Iterationen nötig, um die richtige Lichtbalance zu finden, damit die Szene gut aussieht und gleichzeitig die Gameplay-Ziele erfüllt."
N/A4134"#commentary\cn_223_ravenholm_gameplay_focus.mp3" "[ Mike Dussault ] Nachdem wir viele Spieltests von Ravenholm beobachtet hatten, wussten wir, dass sich das Kern-Gameplay des Levels um das Gravitron und die Physik drehte. Mit diesem Wissen ausgestattet, dachten wir, wir könnten den Übergang nach Ravenholm angemessen gestalten und dem Spieler helfen, etwas über das bevorstehende Erlebnis zu erfahren. Das passiert oft – wir bauen ein Level, finden heraus, was funktioniert, und entwerfen dann den Prolog dazu. Die folgende Reihe von Räumen haben wir mit diesem Gedanken gebaut. Die Brutalität der Werkzeuge, die wir dem Spieler zur Verfügung stellen, schien uns dabei zu helfen, die angestrebte Stimmung zu erzeugen und den Ton von der Sicherheit von Elis Labor zu etwas Dunklerem und Beängstigenderem zu verlagern."
N/A4135"#commentary\cn_224_player_tools.mp3" "[ Steve Bond ] Zu diesem Zeitpunkt im Spiel haben die Spieler bereits viel Erfahrung mit der Physik von Half-Life 2 gemacht, aber sie haben gerade das Gravitron erhalten, das eine völlig neue Möglichkeit bietet, mit den Physikobjekten im Spiel zu interagieren. Wir haben verschiedene Physikobjekte, mit denen der Spieler spielen kann, iteriert – Dinge wie Sägeblätter, Katapulte, Sprengkanister, Fallen, Speere und so weiter. Wir haben uns auf diejenigen konzentriert, die gut mit der Physikwaffe funktionierten, und die entfernt, die nicht funktionierten. Dann haben wir die Munitionsgegenstände aus den Levels entfernt, sodass der Spieler auf diese Gegenstände angewiesen war, um zu überleben."
N/A4136"#commentary\cn_225_contrived_setups.mp3" "[ Kerry Davis ] Beim Training mit dem Gravitron und den Physikobjekten gibt es einen ziemlich deutlichen Kunstgriff. Der Spieler zieht mit dem Gravitron ein Sägeblatt aus der Wand, und wie aufs Stichwort stolpert ein Zombie um die Ecke und bettelt geradezu darum, mit einem Sägeblatt beworfen zu werden. Dann kriecht der Spieler unter einer sich drehenden Klingenfalle hindurch, um sie auszuschalten, und plötzlich erscheinen drei Zombies, die den Spieler provozieren, die Falle wieder einzuschalten. Wir hatten nicht viel Zeit, diesen Abschnitt zu überarbeiten, also brauchten wir Set-ups, die für alle Spieler funktionierten, und keine offeneren, die davon abhingen, dass sie die \"richtige\" Bewegung machten. Obwohl diese Art von Design die Kreativität der Spieler potenziell einschränken kann, stellten wir in diesem Fall fest, dass es ihnen anscheinend nichts ausmachte, wenn wir ihnen einen kleinen Anstoß gaben."
N/A4137"#commentary\cn_226_misteaching_flinches.mp3" "[ Kerry Davis ] Ein weiterer denkwürdiger Spieltest und ein Beispiel für die Gefahr, Spieler falsch zu unterweisen, ereignete sich in Ravenholm. Eines unserer Designprinzipien ist, dass das Spiel so viel wie möglich auf den Spieler reagiert. Beim Design des Gravitrons lag es also auf der Hand, dass etwas passieren sollte, wenn der Spieler es auf einen Zombie richtet und abdrückt. Es war einfach genug, den Zombie mit einem kleinen Stromschlag zu belegen, der eine Zuck-Animation auslöste, die sich gut anfühlte. Später sahen wir uns einen Spieltest an, bei dem der Tester diese Interaktion sofort nach seiner Ankunft in Ravenholm entdeckte und als Feedback interpretierte, dass das Gravitron dem Zombie wehtat ... was es auch tat, nur nicht sehr stark. Also schoss er so lange auf den Zombie und versetzten ihm Stromschläge, bis er starb. Das ist eine langsame, spaßfreie und unmenschliche Art, Zombies zu bekämpfen, besonders wenn man von Sägeblättern und Sprengstoffkanistern umgeben ist. Wir haben unsere Lektion gelernt und die Zuck-Animation entfernt, obwohl dies den Verlust der Interaktion zwischen Zombie und Gravitron bedeutete. In diesem Fall war es besser, diese einfache Interaktion wegzulassen, als den falschen Eindruck zu erwecken, das Gravitron sei ein effektives Mittel zur Zombiebekämpfung. Selbst einfache Prinzipien können also Kompromisse erfordern, wenn man ins Detail geht."
N/A4138"#commentary\cn_227_fire_trap.mp3" "[ Steve Bond ] Diese Feuerfalle war ursprünglich gedacht, um das Feuersystem zu veranschaulichen, bevor ein Leveldesigner sie als Gameplay-Element für Ravenholm umfunktionierte. Während der Entwicklung wäre sie aufgrund der Overdraw-Effekte der transparenten Sprites mehrmals fast gestrichen worden, da sie die Performance auf schwächeren PCs beeinträchtigte. Schließlich fand ein Programmierer die Falle so wichtig für das Gameplay, dass es sich lohnte, die Performance-Probleme zu lösen und sie ins Spiel zu integrieren."
N/A4139"#commentary\cn_228_hallway_cupboards.mp3" "[ Yahn Bernier ] Diese mit Gerümpel vollgestopften Gänge waren eine einfache Lösung für unser Bedürfnis, den Spieler zu verlangsamen. Da wir so viel wie möglich von der bestehenden Geometrie erhalten wollten und die Hauptfeinde langsame Zombies waren, war es schwierig, die Spieler davon abzuhalten, einfach durchzusprinten. Glücklicherweise lieferte uns Grigori als verrückter Bewohner von Ravenholm eine plausible Rechtfertigung – es macht durchaus Sinn, dass er das Treppenhaus mit Sachen vollstopfte, um auf den Dächern in Sicherheit zu sein. Letztendlich waren Grigoris und unsere Lösung ein und dieselbe: Wirf einfach ein paar Möbel in den Weg – denn wenn das die Zombies aufhält, wird es wahrscheinlich auch den Spieler verlangsamen."
N/A4140"#commentary\cn_229_pacing_switch.mp3" "[ Steve Bond ] Nachdem die Spieler das Training nun durchlaufen haben, können wir das Tempo von düsteren, klaustrophobischen Räumen zu mehr kampfbetonten Action-Arenen zu verlagern. Sobald der Spieler mit den verschiedenen physikalischen Werkzeugen der Umgebung vertraut ist, können wir diese in offene Räume integrieren und ihm die Freiheit geben, seine eigene Herangehensweise zu wählen."
N/A4141"#commentary\cn_230_car_crushers.mp3" "[ Steve Bond ] Diese Autozerquetscher erforderten einige Anpassungen und eine Menge Arbeit an unserem Physik-Schadenssystem. Es ist immer eine Herausforderung, wenn große Physik-Objekte mit NPCs interagieren. Wenn die Physik den NPC zum Beispiel schieben kann, kann es passieren, dass er an eine Stelle gedrückt wird, wo er nicht hingehört, und sich nicht mehr befreien kann. Das ist kein großes Problem, wenn es sich um eine Kopfkrabbe handelt, die sich einfach aus einer kniffligen Situation befreien kann, aber für einen Zombie könnte das bedeuten, dass er festsitzt und hilflos in der Lücke zappelt, in die er gezwängt wurde. Das macht die Survival-Horror-Stimmung, die wir hier anstreben, irgendwie zunichte."
N/A4142"#commentary\cn_231_car_crusher_lifts.mp3" "[ Eric Smith ] Auch das Anheben des Spielers durch die Autozerquetscher war nicht ganz einfach. Der Spieler wird immer sowohl durch das Physiksystem als auch durch das Bewegungssystem des Spiels simuliert. Jedes Mal, wenn wir den Zustand des Spielers aktualisieren, vergleichen wir die Ergebnisse beider Systeme und entscheiden, welches \"richtig\" ist, dann synchronisieren wir sie und wiederholen den Vorgang. Auf diese Weise können sich die beiden Systeme gegenseitig beeinflussen, zum Beispiel wenn der Spieler auf einer Wippe steht, lässt die Physik das Brett nachgeben, oder wenn er auf dem Autozerquetscher steht, hebt es ihn hoch. Dieser Ansatz mit zwei Systemen ist zwar komplexer, aber leichter abzustimmen als der Versuch, sowohl die Physik als auch die Spielerbewegung in einem einzigen System zu behandeln. Durch die Trennung der beiden Systeme konnten wir das Bewegungssystem so abstimmen, dass es sich gut anfühlte, und mussten die beiden Systeme nur dann miteinander in Einklang bringen, wenn die Physik den Spieler beeinflusste."
N/A4143"#commentary\cn_232_paint_cans.mp3" "[ Steve Bond ] Nachdem es uns gelungen war, das Gravitron und das Physik-Gameplay zum Kern des Ravenholm-Erlebnisses zu machen, begannen wir, die Level durchzugehen, und nach Objekten zu suchen, die wir möglicherweise übersehen hatten, als wir mit den wirklich aggressiven Dingen wie Sägeblättern und explodierenden Kanistern beschäftigt waren. Eines der Objekte, die wir gefunden haben, war die Farbdose, und es war eine leichte Aufgabe, die Erwartungen unserer Spieler zu erfüllen, indem wir Farbe auf die Zombies spritzen ließen, wenn man eine Farbdose auf sie warf."
N/A4144"#commentary\cn_233_bringing_physics_to_the_enemies.mp3" "[ Tom Leonard ] Die Physikfallen in Ravenholm gehörten zu den ersten Gameplay-Elementen, mit denen wir wirklich zufrieden waren, aber es fehlte ihnen an Handlungsfreiheit für den Spieler. Erst die Sägeblätter halfen uns herauszufinden, was Ravenholm wirklich ausmachte. Mit Sägeblättern konnte der Spieler die Physik zu den Zombies bringen, anstatt die Zombies in die Physik zu führen. Nachdem wir dieses Verständnis hatten, entwickelte sich Ravenholm rasant weiter. Wir durchkämmten die Karte ständig auf der Suche nach allem, insbesondere allem Ungewöhnlichen, das der Spieler in ein Werkzeug oder eine Waffe verwandeln konnte."
N/A4145"#commentary\cn_234_ravenholm_development.mp3" "[ Tom Leonard ] Wir haben schon früh während der Produktion von Half-Life 2 mit der Entwicklung von Ravenholm begonnen, sodass es mehr als einen vollständigen Entwicklungszyklus durchlaufen hat. Die erste Version entstand noch vor dem Gravitron und konzentrierte sich auf traditionelle Zombie-Kämpfe mit Waffen und einigen Physikfallen. Wir hatten sogar vor, Ravenholm auf der E3 2002 vorzustellen, aber das Spiel wurde schließlich ein Jahr später, im Jahr 2003, veröffentlicht. Zu diesem Zeitpunkt hatten wir bereits viel in die Grafik von Ravenholm investiert, was wir normalerweise vermeiden, bis das Gameplay vollständig ausgereift ist. Als wir uns dann mit der Gravitron-Mechanik erneut Ravenholm zuwandten, arbeiteten wir mit einer Vielzahl bereits vorhandener Level-Geometrien, die für ein ganz anderes Gameplay-Ziel entworfen worden waren."
N/A4146"#commentary\cn_235_grigori_plaza.mp3" "[ Steve Bond ] Dieser offene Platz ist einer der Bereiche, der in unserem ersten Entwicklungsdurchlauf mit allen Details ausgearbeitet wurde. Als wir zu ihm zurückkehrten, wollten wir so viel von der vorhandenen Grafik wie möglich erhalten und gleichzeitig einen neuen Pfad für den Spieler entwerfen, der alle drei Dimensionen nutzt. Die Spieler sollten durch Fenster, über Dächer und zwischen Gebäuden auf und ab gehen. Es war nicht viel Platz, also mussten wir so viel wie möglich aus ihm herausholen. Und da der Bereich ursprünglich nur für visuelle Zwecke gedacht war, kam das Gameplay zu kurz. Die Testspieler waren viel zu schnell damit fertig, also mussten wir dafür eine Lösung finden. Außerdem war unser Performance-Budget für das Rendering bereits erschöpft, sodass nur noch wenig Platz für Neues blieb. Die Herausforderung bestand darin, kleine Ergänzungen zu finden, um den Spieler zu verlangsamen, indem wir Bedrohungen in Ecken und in jeden Winkel des Levels einbauten."
N/A4147"#commentary\cn_236_ravenholm_development_2.mp3" "[ Tom Leonard ] Wenn Fans mit uns über Half-Life 2 sprechen, ist Ravenholm oft der Bereich, der am meisten in Erinnerung geblieben ist. Dank der vielen Entwicklungsdurchläufe und der Materialdichte in Ravenholm konnten mehr Teammitglieder darin repräsentiert werden als überall sonst. Ravenholm ist der Bereich, in dem wir herausfanden, wie wir unsere künstlerische Pipeline mit der gewünschten Kulisse und Atmosphäre verbinden können, wie die Physik und das Gameplay mit dem Gravitron zusammenwirken, wie Kopfkrabben und Zombies sich für Half-Life 2 weiterentwickeln müssen und vieles mehr. Wenn wir jetzt darauf zurückblicken, bestätigt es uns in unserem Glauben, dass individuelle Visionen über zentralisiertem Design stehen sollten. Das dichte und hocheffiziente Gameplay und die künstlerische Umsetzung von Ravenholm basieren auf vielen kleinen Beiträgen Einzelner, die ihre Vision mit ihren eigenen einzigartigen Fähigkeiten weiter vorantreiben konnten."
N/A4148"#commentary\cn_237_playtester_archetypes.mp3" "[ Tom Leonard ] Für die Entwicklung von Half-Life 2 spielten kontinuierliche Verbesserungen und regelmäßige Spieltests eine entscheidende Rolle. Jede Woche beobachteten wir still Spieler beim Durchspielen unserer aktuell in der Entwicklung befindlichen Bereiche und notierten uns, was funktionierte und was nicht. Wir testeten mit erfahreneren und weniger erfahrenen Spielern, um sicherzustellen, dass wir keine Entscheidungen trafen, die nur für einige Spieler funktionierten. Im Laufe der Zeit lernten wir, basierend auf der aktuellen Entwicklungsstufe, spezifische Testspieler auszuwählen. Im ersten Schritt setzen wir erfahrene Spieler ein, üblicherweise Teammitglieder, die keine Schwierigkeiten mit groben, unfertigen Bereichen hatten und in der Lage waren, ihren Gedankengang zu erläutern. Zum Testen von Kämpfen suchten wir nach allen möglichen Spielern, insbesondere solchen, die die Werkzeuge kreativ einsetzten. Am Ende der Entwicklung, beim Feinschliff der Bereiche, konzentrierten wir uns auf Anfänger – Leute, die selten Spiele spielten oder nicht mit Ego-Shootern vertraut waren. Obwohl sie nicht zwangsläufig zur Zielgruppe gehörten, lernten wir oft etwas Wichtiges, indem wir ihnen zusahen."
N/A4149"#commentary\cn_238_the_real_final_arena.mp3" "[ Tom Leonard ] Relativ spät in der Entwicklung von Half-Life 2, als wir das gesamte Spiel auf letzte Verbesserungsmöglichkeiten überprüften, entschieden wir, dass wir tatsächlich ein richtiges Finale für Ravenholm wollten. Der Kampf auf dem Dach war nicht genug. Nach einigen Gesprächen entschieden wir uns, diesen letzten Kampf durch den Friedhof mit Grigori an der Seite des Spielers hinzuzufügen. Das war entwicklungstechnisch riskant, aber wir waren überzeugt, dass das Spiel es benötigte. Da wir uns dem Ende der Produktion näherten, konnten wir mit einem ausgereiften Satz Gameplay-Werkzeugen arbeiten. Aber noch wichtiger war, dass wir zu diesem Zeitpunkt unser eigenes Spiel gut kannten. Bei der Entwicklung eines Spiels lernt man oft, was man eigentlich erschafft. Warum macht unser Spiel Spaß? Was ist anders? Was sind die wichtigsten Elemente? Während wir das Spiel entwickelten und den Testern beim Spielen zusahen, erhielten wir Antworten auf diese Fragen und wurden dadurch bessere Spieleentwickler. Der Friedhof entstand also schnell und erforderte weit weniger Iterationen als frühere Bereiche des Spiels."
N/A4150"#commentary\cn_239_cities.mp3" "[ Eric Kirchmer ] Spielern das Gefühl einer großen Stadt zu geben, ohne eine solche Stadt tatsächlich zu rendern, war eine von vielen Herausforderungen in diesem Bereich, da unser Leistungsbudget einfach nicht dafür ausreichte. Wir konzentrierten uns deshalb auf dicht gedrängte Miethäuser, Tiefgaragen, U-Bahn-Tunnel, unterirdische Kanäle und so weiter. Also Orte in Städten, an denen man den Horizont nicht sieht. Diese ergänzten wir dann mit Aussichtspunkten, an denen Spieler einen weitläufigen Überblick über das gesamte Gebiet bekamen. Hier konnten wir unser gesamtes Performance-Budget für die Aussicht ausgeben und mussten nichts für Gegner-KI oder Kämpfe zurückhalten."
N/A4151"#commentary\cn_240_strider_4.mp3" "[ Eric Smith ] Obgleich diese Produktionskarte speziell für den Strider entwickelt wurde, verwendeten wir eine Original-Entwicklungskarte zum Testen der dafür vorgesehenen KI. Es hat sich bewährt, eine solide Testkarte für KI zu haben, da wir so neue Gameplay-Ideen schnell austesten und direkt anpassen konnten. Wenn Fehler oder Designprobleme auftraten, konnten wir diese so schneller isolieren, korrigieren und verbessern. Sobald die KI-Funktionen ausgereift waren, verschoben wir sie für die Leveldesigner zu den Produktionskarten. Die Strider-Testkarte verfügte über Ruinen zerstörter Gebäude mit endlos spawnenden Bürgern an verschiedenen Positionen und auf unterschiedlichen Ebenen, um einen fortlaufenden Strom an Zielen zu generieren. Dieser Aufbau ermöglichte es uns, die KI des Striders zu verfeinern und Änderungen an seinen Kampfhaltungen durchzuführen, um ihn interessanter und fesselnder zu gestalten, auch wenn wir uns lediglich zurücklehnten und ihnen zuschauten."
N/A4152"#commentary\cn_241_perf_arena.mp3" "[ Aaron Seeler ] Diese Arena stellte uns vor eine große Herausforderung: Performance. Aufgrund ihrer schieren Größe kombiniert mit der Strider- und der Bürger-KI sprengte sie die Grenzen unserer Möglichkeiten. Als wir Half-Life 2 zur Xbox portierten, war es uns nicht möglich, diese Arena ohne einige Anpassungen am Design zu veröffentlichen. Unsere ursprüngliche Vision für das Spielererlebnis mit weniger Tools und weniger Platz zu erreichen, war ein schwieriger Balanceakt."
N/A4153"#commentary\cn_242_space_re-use.mp3" "[ Chris Green ] Es hatte mehrere Vorteile, zu diesem Bereich zurückzukehren. Erstens, der offensichtliche Vorteil: Die Produktionskosten für neue Bereiche waren stets hoch. Deshalb war es ein Gewinn, mehr Gameplay zu bestehenden Bereichen hinzufügen zu können. Aber für einen harten Kampf wie diesen, wo der Spieler sich mehreren Stridern gegenübersieht, hat die Wiederverwendung Extravorteile. Da Spieler schon einmal in dieser Arena waren, haben sie bereits ein Gefühl für das Layout. Dieses Mal müssen sie sich von hinten nach vorn bewegen, jedoch folgt der Pfad größtenteils der ursprünglichen Route. Diese Familiarität hilft Spielern, wenn sie durchgehen und Ressourcen für den Kampf sammeln müssen. Der Zustand der vom Krieg zerstörten City 17 gab uns auch die Flexibilität, entlang des Pfades die Deckung anzupassen und kleinere Hindernisse hinzuzufügen und die Umgebung dynamisch und überraschend zu halten."
N/A4154"#commentary\cn_243_tenements_and_courtyards.mp3" "[ Danika Rogers ] Wir haben viele kleine Tricks verwendet und verschiedene Funktionen gebaut, um Spielern den Eindruck einer Stadt im Kriegszustand zu geben. Viel Arbeit wurde darauf aufgewendet, einen Blick auf Scharmützel und den Klang fernen Kampfes zu geben. Looktargets halfen dabei, dass jedes Mal etwas passierte, wenn Spieler durch ein Fenster schauten. Tools wie \"Tracer Makers\" ermöglichen es Designern, falsches Kreuzfeuer zwischen zwei Punkten zu kreieren. Gepaart mit Audio-Tools schaffte dies die Illusion von zwei gegnerischen Gruppen, die sich beschießen, ohne KI nutzen zu müssen. Wir entwickelten auch für Gruppen von Bürgern kleine Geschichten, von denen der Spieler im Verlauf des Levels mehrmals flüchtige Einblicke erhielt. All diese Momente waren fein abgestimmt. Durch Spieltests stellten wir sicher, dass so viele Spieler wie möglich diese erlebten."
N/A4155"#commentary\cn_244_hopper_mine_training.mp3" "[ Dario Casali ] Diese Wellblechplatte wurde absichtlich über dem Loch platziert, um die Spieler zu ermutigen, zum Gravitron zu wechseln und das Hindernis zu entfernen. Das ist eine kleine Manipulation unsererseits, denn wir haben festgestellt, dass die Spieler viel besser mit Hüpfminen umgehen können, wenn sie sofort versuchen, das Gravitron zu benutzen, und die Metallplatte erhöht die Wahrscheinlichkeit, dass sie sie bereit haben. Wir haben mehrere Minen in dem Loch platziert, damit die Spieler mehrere Gelegenheiten haben, mit ihnen zu interagieren, was die Wahrscheinlichkeit erhöht, dass sie alternative Wege zur Beseitigung der Minen entdecken. Außerdem ist es das erste Mal, dass wir das Training durchführen, während der Spieler eine ganze Truppe von Bürgern bei sich hat, also haben wir diese Gelegenheit genutzt, um auch einige Dialogzeilen über die Hüpfminen einzubauen."
N/A4156"#commentary\cn_245_dog_combat.mp3" "[ Eric Kirchmer ] Dog ist ein wirklich unterhaltsamer Charakter und wir haben immer nach Möglichkeiten gesucht, ihn an der Seite des Spielers in den Kampf einzubinden. Die richtigen Kampfszenarien für ihn zu finden – also die passende Umgebung, neue Gegner-KI und möglicherweise sogar neue Gegner –, sprengte jedoch schnell den Rahmen des Projekts. Um ein Kampfszenario zu schaffen, das Dog gerecht wird und sich vor dem Rest des Spiels nicht verstecken muss, fühlte es sich fast so an, als würden wir ein neues Spiel im Spiel entwickeln. Wir wussten, dass er nicht einfach zu einem Soldaten rennen und zuschlagen kann – das würde niemanden beeindrucken. Er brauchte größere Bedrohungen, die seiner Größe entsprachen, und interessante Möglichkeiten, mit ihnen zu interagieren. Letztendlich entschieden wir uns für eine große Choreo-Szene, die Dog einen spektakulären Kampf gab, ohne dass wir aufwendiges Gameplay-Design einbauen mussten."
N/A4157"#commentary\cn_246_strider_2.mp3" "[ Eric Kirchmer ] Die Überarbeitung des Striders hat uns hier endlich eine Erfahrung beschert, mit der wir zufrieden waren, da die Spieler von Deckung zu Deckung rennen mussten, um dem Feuer des Striders auszuweichen, während sie nach Raketen suchen. Wir wollten, dass die Spieler das Gefühl haben, in letzter Sekunde auszuweichen, also passten wir das Schussmuster des Striders so an, dass es die drohende Gefahr ankündigte. Wir haben auch ein System von Wegen für den Strider entwickelt, zwischen denen er dynamisch wechselt, um den Spieler zu verfolgen oder eine Sichtlinie herzustellen. Auf diese Weise konnten die Leveldesigner die Wege des Striders sorgfältig auf die Deckung des Spielers abstimmen, um ein ausgewogenes Spielerlebnis zu gewährleisten. Die Positionierung der Beine des Striders wurde vollständig durch Code gesteuert und seine unvorhersehbaren Bewegungen bedeuteten, dass wir oft Feinabstimmungen vornehmen mussten, um sicherzustellen, dass er bei Bedarf zuverlässig gegen ein Auto oder einen Container tritt."
N/A4158"#commentary\cn_247_manhack_tunnels.mp3" "[ Eric Smith ] Bei der Entwicklung des KI-Verhaltens für einen NPC haben wir festgestellt, dass es für den KI-Programmierer nützlich ist, eine Testkarte zu haben, auf der er experimentieren kann. Diese Karte entwickelte sich oft zu einer Umgebung, die speziell dafür entworfen wurde, die einzigartigen Fähigkeiten des NPCs zu demonstrieren. Später, wenn die KI für die Leveldesigner bereit war, diente die Testkarte als wertvoller Bezugspunkt. Ohne sie konnten die Designer versehentlich Szenarien erstellen, die eine ansonsten interessante KI weniger ansprechend machten. In einigen Fällen konnten wir diese Testkarten direkt in das Spiel einbauen. Dieser kleine Abschnitt zum Beispiel war ursprünglich ein Tunnel, der für die Entwicklung der Schnitter-KI verwendet wurde."
N/A4159"#commentary\cn_248_sniper_streets_2.mp3" "[ Erik Johnson ] Kugeln in Half-Life 2 folgen eigentlich keiner Flugbahn – sie erreichen ihr Ziel sofort. Aber beim Scharfschützen mit seiner niedrigen Feuerrate und der hohen Aufmerksamkeit des Spielers bei jedem Schuss wollten wir die Flugbahn der Kugel simulieren. Dieser Ansatz funktionierte auch besser mit dem Laservisier, bei dem das Visier ausgeht und die Kugel kurz darauf landet, abhängig von der Entfernung zum Scharfschützen. Diese Änderung brachte jedoch ein neues Problem mit sich: Wir wollten nicht, dass die Spieler einfach die Straße entlang sprinten, um Schüssen auszuweichen. Also musste der Scharfschütze ein bewegliches Ziel anvisieren und vorhersagen, wo die Kugel einschlagen würde. Die zukünftige Position des Spielers vorherzusagen war knifflig, da Spieler die Richtung viel schneller ändern können, als dies in der realen Welt möglich wäre. Also fügten wir zusätzliche Checks hinzu, um Verhaltensweisen wie schnelles Drücken der Spieler der Tasten nach links und rechts beim Laufen zu erfassen."
N/A4160"#commentary\cn_249_triangle_plaza.mp3" "[ Ido Magal ] Dieser Plaza-Kampf war ein komplexes Set-up, bei dem das Angriffsverhalten mit zwei zusammenlaufenden Kampflinien, eine für jedes Kraftfeld, genutzt wurde. Wenn die Soldaten von hinter den Feldern kommen, verhindern ihre Kampflinien, dass sie einzeln auf die Plaza stürmen. Wenn der Kampf eskaliert und sich die Soldaten sammeln, bewegen sich die Kampflinien auf das Zentrum der Plaza zu, was dazu führt, dass die Soldaten den Spieler überwältigen, wenn sie nicht abgewehrt werden."
N/A4161"#commentary\cn_250_sniper_streets_3.mp3" "[ Jakob Jungels ] Eine Funktion, die wir in diesen Straßen ausprobiert haben, war Unterdrückungsfeuer. Viele Spieler, die sich am Ende der Straße verschanzt hatten, feuerten eine Salve auf das Fenster des Scharfschützen, um zu sehen, ob es Wirkung zeigte. Also experimentierten wir damit, das Laservisier kurz ausgehen zu lassen, um den Spielern einen Moment Zeit zu geben, ihre Position zu ändern. Nach mehreren Spieltests stießen wir jedoch auf zwei Probleme: Erstens störte es das spannende Bewegungs- und Versteckspiel, das wir mit dem Scharfschützen erzeugen wollten. Das Sprinten während des Schießens unterschied sich nicht wesentlich von anderen Aktionen, die wir in City 17 vom Spieler verlangten. Das zweite, subtilere Problem bestand darin, dass Spieler, die zuerst das Unterdrückungsfeuer entdeckten, davon ausgingen, es sei erforderlich, und schnell Munition verbrauchten. Wenn ihnen auf halbem Weg die Munition ausging, gaben sie oft auf, weil sie dachten, sie hätten versagt. Wenn sie es schafften, standen sie häufig ohne Munition da. Spieler, die das Szenario durch Schleichen abschlossen, verbrauchten dagegen fast gar keine Munition. Diese Ressourcenlücke zwischen den Ansätzen machte es nahezu unmöglich, die Munition für die folgenden Abschnitte zu balancen. Deshalb haben wir Unterdrückungsfeuer am Ende wieder rausgenommen."
N/A4162"#commentary\cn_251_assault_behavior.mp3" "[ John Cook ] Das komplexeste Verhalten, das wir für Half-Life 2 entwickelt haben, war das Angriffsverhalten, das in diesem Abschnitt des Spiels zum Einsatz kommt. Es ermöglichte den Leveldesignern, Kampfszenarien mit Combine-Soldaten und Bürgern zu erstellen, Schlachtlinien zwischen ihnen zu ziehen und den Verlauf der Schlachten basierend auf den Aktionen des Spielers zu steuern. An einem Angriff beteiligte NPCs versuchten, je nach Position der Schlachtlinie kluge Schusspositionen zu finden und Deckung zu suchen. Wenn der Spieler eine Straße entlangging, konnte er die Schlachtlinie nach vorne schieben, wodurch verbündete Bürger vorrückten, während feindliche Soldaten zurückwichen. Alternativ musste der Spieler möglicherweise Combine-Türme erledigen oder einen Soldaten hinter einer Barrikade ausschalten, um die Schlachtlinie nach vorne zu bewegen."
N/A4163"#commentary\cn_252_bank_roof_mortar.mp3" "[ John Morello ] Als wir das Level bis zu diesem Punkt gebaut hatten, war es offensichtlich, dass es dem Spieler Spaß machen würde, den Mörser zu benutzen. Ich schätze, das hätte uns schon früher einfallen sollen. \"Glaubst du, die Spieler hätten Lust, Sprengstoff in den Himmel zu ballern und auf Gegner regnen zu lassen? Ja, das glaube ich auch.\" Jedenfalls wurden die Spieler so oft vom Mörser beschossen, da wäre es eine nette Belohnung den Combine etwas von ihrer eigenen Medizin verabreichen zu können. Aber sobald wir darüber nachdachten, wurde uns klar, wie viel Arbeit das bedeuten würde – was, um fair zu sein, bei der Spielentwicklung ganz normal ist. Der Mörser bräuchte Animationen und Effekte, da der Spieler direkt danebensteht, und es wäre eine Menge Arbeit gewesen, eine ordentliche Anzahl von Gegnern auf der Plaza zu implementieren, gegen die man ihn einsetzen könnte. Aber noch grundlegender: Wir hatten kein Interface für eine so einzigartige Waffe. Wie sollten die Spieler zielen und schießen? Es ist kein gutes Gefühl, so viel Zeit in eine Sache zu stecken, die nur kurz im Spiel relevant ist. Deshalb haben wir beschlossen, diese Zeit lieber woanders zu investieren. Tut mir leid! Vielleicht lösen wir das Design-Rätsel des Mörsers in einem zukünftigen Teil der Half-Life-Reihe."
N/A4164"#commentary\cn_253_strider.mp3" "[ Kerry Davis ] In diesem Bereich vor der Bank haben wir den Strider realisiert. Als wir das erste Mal die Konzeptzeichnungen sahen, wussten wir, dass wir ihn ins Spiel integrieren wollten, aber es gab jede Menge Fragen zur praktischen Umsetzung. Wir hatten noch nie etwas so Großes durch unsere Spielwelt bewegt, und in diesem Maßstab musste es gefährlich sein. Aber wie sollten die Spieler es tatsächlich bekämpfen? Wie bei all unseren Gegnern stellte sich immer die Frage, wie wir das Gameplay verbessern würden. Welche Tools bräuchten Leveldesigner, um Szenarien mit ihm zu erstellen? Das waren die Fragen, auf die wir bei unseren Experimenten mit dieser Karte Antworten suchten."
N/A4165"#commentary\cn_254_sniper_streets.mp3" "[ Eric Kirchmer ] In diesen Straßen voller Scharfschützen haben wir sowohl den Feind als auch den Kern der Erfahrung, die wir den Spielern bieten wollten, entwickelt. Wir wussten, dass der Scharfschütze auf Dinge in der Nähe des Spielers schießen sollte, also konzentrierten wir uns zunächst darauf, eine Vielzahl interessanter Ziele zu finden, die er treffen konnte. Wir fanden, dass es gut funktionierte, wenn wir die Sicht des Spielers als Faktor bei der Auswahl der Objekte nutzten. Durch das ständig eingeschaltete Laservisier des Scharfschützen hatten die Spieler einen ständigen Indikator für dessen Aufmerksamkeit, sodass es sich sehr reaktionsschnell anfühlte, wenn der Scharfschütze auf ein Ziel zielte, auf das der Spieler gerade schaute. Das sorgte für großartige Spannungsmomente."
N/A4166"#commentary\cn_255_citizen_squad_details.mp3" "[ Matt Wright ] Nachdem wir die Bürgertruppe etabliert und Szenarien darauf aufgebaut hatten, eröffneten sich uns weitere interessante Möglichkeiten. Die Testspieler interessierten sich zunehmend für bestimmte Truppmitglieder, also entwickelten wir sie weiter. Truppmitglieder sammelten bessere Waffen ein, wenn sie welche fanden, gaben dem Spieler bei Bedarf Munition, und Sanitäter heilten den Spieler, wenn nötig. Wir mussten außerdem sicherstellen, dass die Truppe mit einem Spieler mithalten konnte, der oft unvorhersehbare Wege einschlug. Außerhalb der Kamera konnte die Truppe auf verschiedene Weise \"schummeln\" – sie regenerierte Gesundheit zwischen Kämpfen, bewegte sich schnell, um aufzuholen, und teleportierte sich sogar, wenn nötig."
N/A4167"#commentary\cn_256_citizen_squads.mp3" "[ Ken Birdwell ] Bei unseren ersten Tests mit Straßenkämpfen zwischen Combine und Bürgern sind wir auf ein Problem gestoßen: Ohne Grenzen konnte sich die Kampf-KI sehr weit vom Spieler entfernen. Soldaten konnten sich also zurückziehen, um nachzuladen oder in Deckung zu gehen, und die KI für Bürger nahm die Verfolgung auf. Wir wollten jedoch die Handlungen der Zivilisten besser auf die Ziele des Spielers abstimmen. Sie sollten stets wissen, wohin der Spieler sich bewegen und welche Feinde er angreifen wollte. Wir entwickelten daraufhin eine Truppe von Bürgern. Die KI sorgte dafür, dass sich diese Truppe mit dem Spieler bewegte und dieselben Feinde angriff. Gleichzeitig stellte sie eine grundlegende Schnittstelle für Befehle des Spielers dar. Zu Beginn verfügten wir über ein komplexes Befehlssystem, doch dies stellte sich als unhandlich heraus und wir schraubten es dementsprechend zurück."
N/A4168"#commentary\cn_257_ai_behaviors.mp3" "[ Mike Dussault ] Zu der für Half-Life 2 entwickelten KI-Technologie gehört auch das Verhaltenssystem. Dieses war Teil des KI-Spielcodes, der in bestimmten Situationen das Verhalten von NPCs bestimmte. Wir hatten zum Beispiel ein Führungsverhalten, mit dem ein NPC den Spieler leiten konnte, und ein Folgeverhalten, mit dem ein NPC dem Spieler oder einem anderen NPC folgen konnte. Verhaltensweisen arbeiteten parallel zum grundlegenden Verhalten von NPCs. So wusste ein Sanitäter, der das Folgeverhalten nutzte, um mit dem Spieler Schritt zu halten, immer, wie er auf Feinde schießen, Granaten ausweichen oder Medikit anbieten konnte."
N/A4169"#commentary\cn_258_occlusion.mp3" "[ Brian Jacobson ] In Half-Life 1 und einem Großteil von Half-Life 2 bestand die Welt hauptsächlich aus geschlossenen Tunneln und Korridoren, die gut mit einer binären Raumpartition oder einem BSP-Baum funktionierten. Im Wesentlichen ermöglichte uns diese Technologie, die Geometrie schnell zu sortieren und zu bestimmen, was im Blickfeld des Spielers sichtbar sein könnte. Die offenen Bereiche an der Küste und in anderen Außenbereichen passten jedoch nicht zu diesem Ansatz, sodass wir neue Technologie benötigten. \"Area Portals\" waren eine Möglichkeit, die es uns ermöglichte, die Welt in diskrete Teile zu zerlegen, die durch Portale – also Türen und Fenster, keine \"Aperture Science\"-Portale – getrennt waren. Wir entwickelten außerdem ein zusätzliches Okklusionssystem, das im Wesentlichen besagte: \"Wenn der Spieler nicht durch, über oder um ein großes Objekt herum sehen kann, rendere nicht, was sich auf der anderen Seite befindet.\" Das mag selbstverständlich erscheinen, aber es erfordert einige Arbeit, um sicherzustellen, dass die Berechnung dessen, was sich auf der anderen Seite des großen Objekts befindet, nicht langsamer ist, als einfach alles zu rendern. Um diese Berechnung zu beschleunigen, platzierten die Leveldesigner große Okklusionsvolumina innerhalb wichtiger Geländeformen und großer okkludierender Objekte wie Gebäuden. Während des Renderings konnten wir dann die Grenzen der Entitäten anhand dieser Volumina testen, um zu vermeiden, dass etwas gerendert wurde, das der Spieler nicht sehen konnte."
N/A4170"#commentary\cn_259_detail_objects.mp3" "[ Brian Jacobson ] Nachdem wir die Außenbereiche fertiggestellt hatten, war klar, dass sie in irgendeiner Form detailreich sein mussten, also fügten wir kleine Blatt-Elemente, wie Gras und Sträucher, auf dem gesamten Displacement-Gelände hinzu. Aber wir wussten, dass wir es uns nicht leisten konnten, oder besser gesagt, dass wir nicht die Zeit hatten, sie alle von Hand zu platzieren. Also haben wir das Detailobjektsystem entwickelt, das automatisch kleine Blatt-Elemente auf der Grundlage des Displacement-Materials erzeugt. Jedes Material gibt die Art des zu platzierenden Grüns zusammen mit einer Reihe von Parametern an. Bei der Kompilierung der Karte berechnet das System zufällige Punkte auf der Oberfläche und wählt Blattwerk aus, das dort platziert wird. In Anbetracht der Performance-Beschränkungen gab es immer noch einen ziemlich komplexen manuellen Erstellungsprozess für die Blättertexturen, der es uns ermöglichte, sie alle in einem einzigen Durchgang zu rendern."
N/A4171"#commentary\cn_260_displacements_1.mp3" "[ Charlie Brown ] Nach der Veröffentlichung von Half-Life 1 wollten unsere Leveldesigner und Künstler eine bessere Lösung für Außenbereiche. Also bauten wir die erste Version unseres Geländesystems. Es basierte auf unterteilten Vierecken. Stellen Sie sich dazu ein flaches Quadrat vor, das in ein Raster unterteilt ist, wobei jeder Punkt auf dem Raster nach oben oder unten verschiebbar ist. Leveldesigner konnten mehrere Quadrate anlegen und dann mit einem Pinselwerkzeug Hügel und Täler formen, indem sie die Rasterpunkte anpassten. Zum Rendern verwendeten wir eine spezielle Mischtextur, die zwei unterschiedliche Texturen kombinierte. Jeder Rasterpunkt gab an, wie viel von jeder Textur verwendet werden sollte, wodurch fließende Übergänge zwischen Oberflächen wie Sand, Gras, Erde und Kies möglich wurden. Diese Art von Geländesystem war damals in Spiele-Engines nichts Ungewöhnliches und wir dachten naiverweise, es würde unseren Spieledesignern genügen."
N/A4172"#commentary\cn_261_displacements_2.mp3" "[ Charlie Brown ] Nachdem das ursprüngliche Geländesystem erstellt war, erwarteten wir, dass die Leveldesigner es für die Außenbereiche verwenden würden. Stattdessen begannen sie zu experimentieren und fügten Details an unerwarteten Stellen hinzu. Sie benutzten die unterteilten Quads auf Mauern, um zerstörte Kanten zu schaffen, rundeten Straßenränder ab und versuchten sogar, Rohre zu bauen. Der Erfolg war unterschiedlich, da das Geländesystem für Landschaften und nicht für Architekturelemente konzipiert war. Also kehrten wir zu den Code-Minen zurück und wandelten das höhenbasierte Geländesystem in ein vollständiges 3D-Displacement-System um. Anstatt die Gitterpunkte nur nach oben oder unten zu verschieben, konnten die Designer sie nun in jede Richtung bewegen. Dies ermöglichte es ihnen, allen Arten von Oberflächen zusätzliche Details hinzuzufügen, indem sie überblendete Texturen verwendeten, um die Übergänge zwischen den Displacement-Quads und der BSP-Geometrie zu glätten. Dies erforderte jedoch zusätzlichen technischen Aufwand, um eine konsistente Beleuchtung zwischen den beiden Renderern zu gewährleisten, sonst wären die Kanten merklich unpassend gewesen. Aber nachdem all dies erledigt war, schienen die Leveldesigner zufrieden zu sein, und wir dachten naiverweise, dass es dieses Mal wirklich reichen würde."
N/A4173"#commentary\cn_262_displacements_3.mp3" "[ Charlie Brown ] Nachdem das allgemeine Displacement-System fertig war, beließen es die Leveldesigner nicht dabei, der Welt Details hinzuzufügen, sondern kehrten zu ihrem ursprünglichen Ziel zurück, großflächige Außenareale zu erstellen. Dies führte zu einer weiteren Runde von Updates, um die Performance zu balancen und sicherzustellen, dass das System sowohl feine Details als auch größeres Gelände bewältigen konnte. Auch die Texturen mussten verbessert werden, insbesondere um komplexe Strukturen wie überhängende Klippen zu unterstützen, die mit dem ursprünglichen höhenbasierten System nicht möglich waren. Aber Designer ruhen sich bekanntlich nie auf ihren Lorbeeren aus und begannen damit, Displacements zu nutzen, um Höhlen und Tunnel zu erschaffen. Diese Ergänzungen sahen zwar toll aus, erforderten aber noch mehr technische Anpassungen. Schließlich gelang es uns, die konkurrierenden Anforderungen aller Einsatzmöglichkeiten von Displacement-Systemen zu bewältigen, und sie wurden in große Teile unserer Spielwelt integriert. Rückblickend sind sie ein verständliches Beispiel dafür, wie sich Technologie und Gamedesign gemeinsam weiterentwickeln. Es ist ein Henne-Ei-Problem: Wir können nicht alle Auswirkungen einer Technologie auf das Spiel vorhersehen, aber wir können die Technologie auch nicht entwickeln, ohne zu wissen, was sie leisten soll. Also müssen wir, einfach etwas bauen. Wir beginnen mit einer Ausgangsvermutung und schauen, wohin uns das führt."
N/A4174"#commentary\cn_263_particles.mp3" "[ Chris Green ] Für die Source-Engine haben wir in die Erweiterung der Partikel- und Spezialeffekttechnologie investiert. Dies ermöglichte realistischere und komplexere Partikelbewegungen sowie komplexere Formen und Shader-Effekte. Insbesondere die Erweiterung unserer Partikelfunktionen um \"Bumpmapping\" hat deren volumetrisches Erscheinungsbild deutlich verbessert. Während spätere Versionen der Source-Engine einen leistungsstarken Partikelsystem-Editor enthielten, basierte die ursprüngliche Version von Half-Life 2 auf handgefertigten Effekten – jeder einzelne erforderte die sorgfältige manuelle Erstellung durch einen Programmierer, was ein ziemlich arbeitsintensiver Prozess war."
N/A4175"#commentary\cn_264_cubemaps.mp3" "[ Chris Green ] Mit der Einführung von Materialien und Shadern brauchten wir eine Lösung für reflektierende Oberflächen wie Glas und Stahl. Diese Oberflächen mussten wissen, was sie reflektieren sollten, aber 2003 war das noch nicht in Echtzeit möglich. Deshalb entwickelten wir das \"Cubemap\"-System für vorkalkulierte Reflexionen. Eine Cubemap besteht aus sechs Bildern im Inneren eines Würfels, die die Umgebung in jeder Richtung erfassen – wie ein Panoramafoto, das einen von allen Seiten umgibt. Die Leveldesigner platzierten unsichtbare Markierungen in den Leveln und während der Kartenkompilierung generierten wir an jeder Markierung eine Cubemap. Beim Rendern einer reflektierenden Oberfläche suchten wir dann im Spiel die nächstgelegene vorkalkulierte Cubemap, um die Reflexion zu erzeugen."
N/A4176"#commentary\cn_265_water_shader.mp3" "[ Gary McTaggart ] Der komplexeste Shader, den wir für das Spiel erstellt haben, war der Wasser-Shader, der die neu verfügbaren programmierbaren Grafikkarten voll ausnutzte. Bei vorhandenem Wasser wurde die Szene dreimal gerendert: zuerst die Unterwasserwelt für die Brechung, dann eine reflektierte Ansicht und dann die Teile über der Wasseroberfläche. Beim Rendern der Wasseroberfläche haben wir die refraktiven und reflektierenden Ansichten vermischt und mithilfe der fresnelschen Formeln bei Glanzwinkeln mehr Reflexion gezeigt. Auch die Bodentiefe unter der Wasseroberfläche haben wir verfolgt, um sie in flachen Bereichen transparenter und weniger refraktiv zu machen. Zusätzlich mussten wir zwei alternative Techniken für Rendering von Wasser für Grafikkarten der unteren Preisklasse entwickeln: Karten der mittleren Preisklasse zeigten eine weniger detaillierte Reflexion ohne Brechung oder Transparenz, während Karten der unteren Preisklasse nur eine teilweise transparente Oberfläche renderten."
N/A4177"#commentary\cn_266_normal_maps.mp3" "[ Gary McTaggart ] Half-Life 2 wurde zu einer aufregenden Zeit für Grafik entwickelt, als die ersten programmierbaren Shader-unterstützten Grafikkarten auf den Markt kamen. Mithilfe dieser Technologie haben wir als eines der ersten Spiele \"Normal Maps\" implementiert, eine Technik, die die Beleuchtung von Oberflächengeometrie verbessert. Die \"Normal Map\" beschreibt die Rauheit der Oberfläche und ermöglicht es, jeden Pixel eines Polygons auf eine Weise zu beleuchten, die Oberflächen unebener und detaillierter erscheinen lässt, als es in Half-Life 1 je möglich war."
N/A4178"#commentary\cn_267_rendering_systems.mp3" "[ Gary McTaggart ] Anfang der 2000er konnten wir uns keinen Allzweck-Renderer mit dem Leistungsumfang einer modernen Engine leisten. Stattdessen erforderten CPU-, GPU- und Speicherbeschränkungen hochspezifische Lösungen für die Rendering-Herausforderungen, damit wir das letzte bisschen Leistung aus der Hardware der Spieler herausholen konnten. Aus diesem Grund verfügt Half-Life 2 tatsächlich über drei verschiedene Rendering-Engines: eine für die Weltgeometrie, eine andere für Außengelände und eine dritte für dynamische Entitäten wie Charaktere und Objekte. Diese drei Renderer mussten eine komplizierte Matrix von Features unterstützen – Kollisionen, Raytraces, Decals, Offline-Beleuchtung, Sichtbarkeitsberechnungen und mehr. Darüber hinaus musste jeder Renderer DirectX 7, 8 und 9 unterstützen. Die Unterschiede zwischen diesen DirectX-Versionen waren erheblich und erforderten oft unterschiedliche Ansätze bei der Datenspeicherung und beim Rendering. Sie verwendeten sogar unterschiedliche Programmiersprachen! Insgesamt hatten wir im Grunde neun verschiedene Renderer, von denen jeder einzigartige Lösungen benötigte. Sie alle einheitlich aussehen zu lassen, war eines der schwierigsten technischen Probleme, mit denen wir während der Entwicklung konfrontiert waren."
N/A4179"#commentary\cn_268_dynamic_shadows.mp3" "[ Gary McTaggart ] Da Charaktere und physikalische Objekte unser Fokus waren, hielten wir ein dynamisches Schattensystem für notwendig, um sie in ihrer ganzen Pracht darzustellen. Im Jahr 2003 hatten GPUs noch keine der speziellen Schattenfunktionen, die sie heute haben, also war die Performance ein kniffliges Problem. Unsere Lösung sah ungefähr so aus: Wir ließen jedes Bild einzeln laufen. Zuerst suchten wir alle Objekte im Sichtfeld, die Schatten werfen könnten. Dazu mussten wir herausfinden, welche Objekte sich im Sichtfeldkegel oder leicht dahinter befanden, um Entitäten zu erfassen, die sich außerhalb des Bildschirms befanden, deren Schatten aber möglicherweise auf dem Bildschirm erscheinen könnten. Dann renderten wir eine schwarze Schattenversion jedes dieser Objekte in eine einzelne Schattentextur. Für dieses Rendering verwendeten wir das Modell mit der niedrigsten Detailstufe für das Objekt, um so schnell wie möglich zu sein. Schließlich verwendeten wir die Schattentextur, um jeden der Schatten in das Sichtfeld des Spielers zu übertragen und die bereits gerenderten Pixel abzudunkeln. Wir haben jeden Schatten in dieser Schattentextur sorgfältig ausgeschnitten, um sicherzustellen, dass sie sich im Falle einer Überlappung mehrerer Schatten korrekt überlagern. Es ist schön, zurückzublicken, wie wir diese Dinge gemacht haben, aber letztendlich geht es uns heute viel besser, da die GPU-Hardware dieses Problem viel einfacher macht."
N/A4180"#commentary\cn_269_combinatorial_shader_explosion.mp3" "[ Gary McTaggart ] Das Rendering wurde während der Entwicklung von Half-Life 2 durch die Einführung von Hardware-Shadern – kleinen Codeteilen, die steuern, wie jeder Pixel einer Oberfläche gerendert werden soll – deutlich komplexer. 2003 waren Shader weitaus eingeschränkter als heute: Shader aus der Zeit von Half-Life 2 hatten keine Bedingungen und waren hinsichtlich der Codegröße stark beschränkt. Das bedeutete, dass es keine \"if/else\"-Verzweigungslogik zur Anpassung an unterschiedliche Bedingungen und keine großen Shader mit breitem Funktionsumfang gab. Außerdem war das Kompilieren der Shader zu langsam, sodass wir sie vorkompilieren mussten. Um innerhalb dieser Beschränkungen zu arbeiten, mussten wir jede mögliche Shaderkombination berechnen und jede einzeln als eigenen Shader speichern. Wenn beispielsweise ein Shader eine Oberfläche basierend auf einer einzelnen Lichtquelle beeinflusste, brauchten wir eine weitere Shaderversion für zwei Lichter, eine für drei und so weiter. Und wenn dieser Shader auch eine \"Normal Map\" unterstützte, brauchten wir zwei Versionen pro Licht, eine mit \"Normal Map\" und eine ohne. Mit Funktionen wie \"Texture Blending\", \"Vertex Tinting\", \"Specular Highlights\", \"Alpha Testing\" und verschiedenen anderen Lichtarten, wie Richtungslicht, Punktlicht und Spotlight, explodierte unsere Shader-Anzahl. Zum Release verfügten wir über Tausende einzelner Shader. Kurz darauf veröffentlichten wir Lost Coast mit HDR-Unterstützung, wodurch sich die Shader-Anzahl noch einmal verdoppelte. Als das Kompilieren der Shader auf den lokalen Entwickler-Rechnern zu lange dauerte, verteilten wir die Shader-Kompilierungen mithilfe von VMPi über das gesamte Netzwerk. Wir verfügten außerdem über einen dynamischen Shader-Kompilierungsmodus, der für die Entwicklung von Shadern nützlich war, die zwar eine schnelle Umsetzung ermöglichten, jedoch zu Frame-Einbrüchen beim Kompilieren eines Shaders führten."
N/A4181"#commentary\cn_270_gpu_wild_west.mp3" "[ Jay Stelly ] Während der Entwicklung mussten wir zahlreiche Entscheidungen treffen, die von unserer Wahl der Mindestanforderungen beeinflusst wurden – der leistungsschwächsten CPU- und GPU-Kombination, die den Kunden dennoch ein gutes Erlebnis bieten würde. Anfang der 2000er-Jahre gab es eine viel größere Vielfalt an GPUs als heute mit großen Unterschieden, nicht nur was Geschwindigkeit angeht, sondern auch in den grundlegenden Rendering-Ansätzen. Damals hatten wir jedoch keine echten Daten über die Hardware unserer Kunden. Welche CPUs und GPUs hatten sie? Wie viel RAM? Welche Windows-Version? Wir wandten uns an Microsoft in der Hoffnung, sie könnten uns vielleicht sagen, wie viele DX7- oder DX8-Karten verwendet werden. Leider hatten auch sie die Daten nicht. Da uns klar war, dass wir ohne dieses Wissen Gefahr liefen, falsche Entscheidungen zu treffen, entwickelten wir ein Analysetool, mit dem Spieler uns ihre Hardwarespezifikationen melden konnten, und integrierten es in die frühe Version von Steam. Die Daten waren so nützlich, dass wir beschlossen, sie zu veröffentlichen und im April 2003 die Steam-Hardwareumfrage zu starten. Seitdem hilft sie uns – und hoffentlich auch anderen Entwicklern –, fundierte Entscheidungen zu treffen."
N/A4182"#commentary\cn_271_3d_skybox.mp3" "[ Jay Stelly ] Unser Ziel war es immer, eine Welt zu rendern, die sich größer anfühlt, als es unsere Kartenbeschränkungen zulassen. In Half-Life 1 verwendeten wir kubische Umgebungskarten, damit die Spieler über den spielbaren Bereich hinaussehen konnten. In Half-Life 2 wollten wir jedoch, dass dieser Blick in die größere Welt dynamisch ist und nicht nur eine statische Textur besitzt. Unsere Kartengrößenbeschränkung lag bei etwa einer halben Meile in jeder Dimension, aber wir erkannten, dass wir eine viel größere Außenwelt erstellen könnten, wenn wir sie in einem kleineren Maßstab speichern würden. Also erfanden wir die sogenannte 3D-Skybox. Die 3D-Skybox ist eine kleine Box, die in der eigentlichen Spielkarte versteckt ist und Geometrie im Maßstab 1:16 enthält. Darin entspricht ein Referenzpunkt einem entsprechenden Ursprung in der Hauptkarte. Wenn wir dann den Raum jenseits des spielbaren Bereichs rendern, verwenden wir die Geometrie aus der 3D-Skybox, die an diesem Referenzpunkt positioniert und 16-mal vergrößert wird. Es war eine Herausforderung, Licht und Nebel beim Übergang von der Hauptkarte zur Skybox nahtlos ineinander übergehen zu lassen, aber es hat funktioniert. Das Ergebnis war, dass die Welt deutlich größer und immersiver wirkte als in Half-Life 1."
N/A4183"#commentary\cn_272_missing_material.mp3" "[ Jay Stelly ] Schon früh bei der Entwicklung unseres Low-Level-Grafikcodes stellten wir fest, dass es schwierig sein würde, Polygone zu erkennen, die aufgrund einer fehlenden Textur nicht gerendert wurden. In diesem Fall war dort, wo das Polygon sein sollte, normalerweise nur Schwarz zu sehen, was in dunkleren Szenen leicht unbemerkt bleiben konnte. Um diesen Fehler zuverlässiger zu erkennen, erstellten wir eine optisch unverwechselbare Fehlertextur, die automatisch generiert wurde, wenn eine Textur nicht geladen werden konnte. So entstand die mittlerweile ikonische lila-schwarze Schachbretttextur, die weit über Half-Life 2 hinaus ein Eigenleben entwickelt hat."
N/A4184"#commentary\cn_273_air_resistance.mp3" "[ Jay Stelly ] Eine wichtige Funktion, die wir unserer Physik-Engine für Half-Life 2 hinzufügen mussten, war der Luftwiderstand. Damals implementierten Engines normalerweise eine allgemeine Dämpfungsfunktion, um bewegte Objekte abzubremsen. Dies entfernte jedoch lediglich Energie auf symmetrische Weise. Um eine glaubwürdigere Bewegung zu erzeugen, entschieden wir uns stattdessen, den Luftwiderstand zu simulieren. Dadurch konnten wir ein asymmetrisches Verhalten erzielen, bei dem das Objekt je nach der in Bewegungs- oder Rotationsrichtung ausgerichteten Oberfläche unterschiedlich stark gebremst wurde. Diese Funktion war entscheidend, um Explosionen und vom Gravitron geschleuderte Objekte glaubwürdig aussehen zu lassen. Sich schnell bewegende und schnell drehende Objekte gehören zu den aufwendigsten Simulationen in der Physik-Engine von Half-Life 2, daher verbessert der Luftwiderstand auch die CPU-Performance in Fällen wie Explosionen. Er ist auch entscheidend für die Darstellung unterschiedlicher Materialien und Objektmassen. Dichtere Objekte können Luft leichter beiseiteschieben, und das ist sichtbar. Dieser Effekt trägt in der Simulation dazu bei, den Dichteunterschied zwischen Kartons und Holzbrettern deutlicher zu machen, und sorgt dafür, dass die Objekte in der Welt von Half-Life 2 viel überzeugender wirken."
N/A4185"#commentary\cn_274_early_tech_planning.mp3" "[ Ken Birdwell ] Die Veröffentlichung eines Spiels lehrt uns viel. Wir erfahren endlich, welche Entscheidungen gut waren und welche wir beim nächsten Mal vermeiden sollten. Als wir nach Half-Life 1 zusammenkamen und darüber sprachen, welche Art Fortsetzung wir bauen sollten, mussten wir zuerst eine große Menge an Spielerfeedback verarbeiten. Basierend auf diesem Feedback erstellten wir eine Liste der Dinge, auf die sich Half-Life 2 konzentrieren sollte. Wir versuchten nicht, ein bestimmtes Spielerlebnis zu entwerfen, sondern hielten es für sinnvoller, die Frage aus technischer Sicht anzugehen. Die Sicherheitsleute und Wissenschaftler von Black Mesa hatten einwandfrei funktioniert. Was würde entstehen, wenn wir die Charaktere ausbauen würden? Wir mochten unsere interaktive Art, Geschichten zu erzählen. Was könnten wir bauen, das uns ein interaktives Erlebnis mit noch mehr Vielfalt bietet? Die Erkundungen und Interaktionen in Black Mesa waren für die Spieler faszinierend. Vielleicht würde ein Physiksystem uns erlauben, dies noch weiter zu entwickeln? In allen diesen Bereichen haben wir versucht, uns vorzustellen, wie die beste Version davon in einigen Jahren aussehen könnte. Davon ausgehend haben wir versucht, eine Reihe technologischer Schritte abzuleiten, die uns das ermöglichen würden."
N/A4186"#commentary\cn_275_character_lighting.mp3" "[ Ken Birdwell ] Im ersten Jahr der Entwicklung hatten wir große Probleme damit, unsere Charaktere so realistisch wie möglich zu gestalten. Es gab tatsächlich eine ganze Reihe unterschiedlicher Probleme, die ganz spezielle technologische und künstlerische Verbesserungen erforderten. Das erste große Problem war die Beleuchtung. Damals gab es bei der Beleuchtungstechnologie in Spielen viele Abkürzungen, einige aus Performance-Gründen, viele jedoch aufgrund von Missverständnissen über die Funktionsweise von Beleuchtung. Damit die Charaktere damals gut aussahen, mussten Modelle und Texturen bereits einen Großteil der Beleuchtungseffekte enthalten, wie Schatten oder Glanz. Die Charaktere sahen cool aus, sie sahen aber auch aus wie Videospielcharaktere. Wir begannen, Alyx auch so zu entwickeln, weil das die gängige Praxis war. Wir verwendeten die integrierten Lösungen und beleuchteten sie wie eine Filmschauspielerin. Im Grunde so, als hätte sie ständig Scheinwerfer um sich herum, die dafür sorgen, dass sie immer gut aussieht. Aber das funktionierte nicht wirklich. Die Vielfalt der Lichtumgebungen und die dynamische Natur von Videospielen führten dazu, dass Alyx in einigen Umgebungen großartig aussah, in anderen aber wieder unrealistisch. Wir versuchten, ihre Beleuchtung zu verbessern, damit sie besser funktioniert, aber wir hatten bald das Gefühl, in einer Sackgasse zu stecken. Also mussten wir von vorne anfangen und einen neuen Ansatz wählen. Alles wurde von Grund auf neu entwickelt und die alte Beleuchtung und die Texturen wurden entfernt. Wir konzentrierten uns nicht darauf, wie Alyx bei idealer Beleuchtung aussehen sollte, sondern darauf, wie Dinge in der realen Welt funktionierten. Es mag offensichtlich erscheinen, aber so wurde in Videospielen nicht gearbeitet. Außerhalb des Renderers betrachtet, sahen die Modelle und Texturen tatsächlich schlechter aus als die vorherigen Versionen. Wir schafften es aber, alle Abkürzungen und Missverständnisse darüber, wie Licht, Textur und Grafikkarten funktionieren, methodisch zu bearbeiten und alles wieder zusammenzusetzen. Als wir uns Alyx nach all dem endlich im Spiel ansehen konnten, mit ihren neuen Modellen und Texturen, in einer dynamischen Umgebung, in der sie immer optisch konsistent blieb, sah sie einfach super aus. Vollkommen nahtlos und Teil der Welt von Half-Life 2."
N/A4187"#commentary\cn_276_gamma_correction.mp3" "[ John Morello ] Unsere Spiel-Engine verfügt über ein Rendering-System, das den gesamten Zustand des Spiels erfasst und für jeden Pixel auf Ihrem Bildschirm einen Farbwert berechnet, um diesen Zustand darzustellen. Aber auch Code und Software von anderen Instanzen sind an der Berechnung dieser Pixel beteiligt. Unter anderem die Software und Hardware in Grafikkarte und Monitor. An einem Punkt während der Entwicklung waren wir mit dem Aussehen unserer Charaktere unzufrieden. Insbesondere fanden wir, dass sie wachsartig oder kränklich aussahen. Ihre Haut war falsch. Wir verbrachten einige Zeit damit, unsere Beleuchtung zu optimieren, aber wir konnten weder unsere Charaktere noch unsere Welt richtig aussehen lassen. Glücklicherweise hatten wir noch einen voll funktionsfähigen Software-Renderer, mit dem wir das Spiel ohne Grafikkarte ausführen konnten, denn dies war eine Ära, in der viele Spieler noch keine hatten. Und als wir uns das Spiel mit diesem Renderer ansahen, bemerkten wir, dass unsere Beleuchtung nicht das gleiche Problem hatte. Also durchkämmten wir unseren Code und versuchten herauszufinden, wo unser Rendering-Code etwas falsch machte, wenn er mit einer Grafikkarte arbeitete. Nachdem uns dies nicht gelungen war, sprachen wir mit den GPU-Herstellern und baten sie, noch einmal zu überprüfen, ob sie mit den Pixelwerten, die wir ihnen übermittelten, nichts falsch machten. Das war der Beginn einer langen Reise. Nach fast zwei Jahren Hin und Her mit den GPU-Herstellern konnten wir sie davon überzeugen, dass sie die Gammakorrektur in der Low-Level-Mathematik ihrer Karten falsch machten. Währenddessen mussten wir sogar ein System entwickeln, das die Farbwerte eines einzelnen Pixels über unsere gesamte Rendering-Pipeline hinweg validierte. Aber am Ende bekamen wir endlich neue Treiber von ihnen zurück und unsere Charaktere sahen sofort so aus, wie sie sollten, und passten zum Software-Renderer."
N/A4188"#commentary\cn_277_facial_technology.mp3" "[ Ken Birdwell ] Wir wollten, dass sich die Spieler für unsere Charaktere interessieren, und um das zu erreichen, mussten wir viel Technologie in die Gesichter unserer Charaktere investieren. Es ist allgemein bekannt, dass Menschen darauf programmiert sind, Gesichtern Aufmerksamkeit zu schenken und unbewusst alle möglichen Informationen davon abzulesen. Die Messlatte ist also extrem hoch, und wenn wir diese nicht erreichen, würden wir die Spieler wahrscheinlich von unseren Charakteren abstoßen, anstatt sie ihnen näherzubringen. Wir begannen mit ausgiebiger Recherche. Das war nicht ermutigend. Die besten Beispiele, die wir finden konnten, waren nicht annähernd in Echtzeit lauffähig, und die besten Echtzeitbeispiele erreichten nicht annähernd die gewünschte Qualität. Wir wollten, dass es so gut aussieht wie ein Animationsfilm. Unsere Bilder benötigten aber oft Stunden, um zu rendern, und waren gänzlich linear und von bis zu hundert Animatoren erstellt. Sie mussten allerdings dynamisch sein, ein Charakter könnte z. B. versuchen, einen Dialog über eine Mimik auszudrücken, die sich aus den Aktionen des Spielers ergibt und von nur einer Handvoll Künstlern erstellt wurde. Diese Anforderungen führten uns schließlich zu Dr. Paul Ekmans Facial Action Coding System, einem System zur Taxonomisierung menschlicher Gesichtsbewegungen, das in den 1970er Jahren entwickelt wurde. Es gab uns ein Vokabular zur Beschreibung von Gesichtsbewegungen in unseren Tools und Codes und ein Ziel, das wir beim Design der Gesichter unserer Charaktere anstreben konnten. Unter diesen Rahmenbedingungen begannen wir einen mehrjährigen Prozess der Iteration beim Bau von Gesichtern und Köpfen für unsere Charaktere. Während andere versucht hatten, Teile von Ekmans Arbeit zu übernehmen, wollten wir versuchen, alles zu verwenden. Das bedeutete, dass wir viel Zeit damit verbrachten, herauszufinden, wie wir alles innerhalb unserer engen Performance-Beschränkungen umsetzen konnten. Aber wir verbrachten auch viel Zeit damit, uns einfach Menschen und Gesichter anzusehen und zu versuchen, die zusätzlichen Merkmale zu finden, die den größten Mehrwert bringen würden, wie Hautelastizität und Zahnschattierung. Obwohl wir am Ende nicht alles umsetzen konnten, gelang es uns, die Teile zu bekommen, die unserer Meinung nach am wichtigsten für eine überzeugende Gesichtsdarstellung unserer Charaktere waren."
N/A4189"#commentary\cn_278_eye_shader.mp3" "[ Ken Birdwell ] Die Augen waren ein weiterer wichtiger Aspekt, um die Gesichter der Charaktere überzeugend aussehen zu lassen. Menschen können Augen hervorragend lesen. Ein Teil des Gehirns ist dafür zuständig, dass man anhand der Spiegelungen in den Augäpfeln erkennen kann, wohin jemand blickt. Aber es gibt jede Menge Feinheiten, die wichtig sind. Augen sind keine Kugeln. Die Augenlider wölben sich, wenn man die Augen bewegt. Augenbewegungen können die Wahrscheinlichkeit erhöhen, dass jemand blinzelt. Die Augen sind nicht direkt hinter der Pupille ausgerichtet, sondern leicht verschoben. All diese kleinen Details mögen unbedeutend erscheinen, aber wenn sie fehlen, wirken Charaktere unrealistisch. Wir haben lange an den Augen gearbeitet und unser Augenmodell und den Funktionsumfang Stück für Stück verbessert. Manche Dinge erforderten externe Schnittstellen, etwa welche Dinge in der Umgebung interessant anzusehen waren. Andere liefen automatisch auf einer unterbewussten Ebene in der KI ab, wie das Blinzeln – eine offensichtliche Anforderung, die an der falschen Stelle oder zur falschen Zeit jedoch subtil verwirrend sein kann. Besonders große Auswirkungen hatten die Augenreflexionen. Sie machen letztlich nur einen winzigen Teil der Fläche auf dem Bildschirm aus, aber der Unterschied war enorm. Wir wussten, dass wir endlich fertig waren, als wir den Punkt erreichten, an dem ein Charakter mit ausgeschaltetem Augen-Shader wie eine Puppe aussah. Der Charakter wirkte menschlich, aber auf eine schwer zu beschreibende Weise nicht überzeugend. Als wir den Shader jedoch einschalteten, fühlte es sich plötzlich so an, als würde uns ein Mensch ansehen."
N/A4190"#commentary\cn_279_combine_gunship.mp3" "[ Ken Birdwell ] Der Hubschrauber war ein interessantes Problem. Wir hatten bereits ein Hubschrauber-Flugmodell und nicht wirklich Zeit, etwas völlig Neues zu bauen. Also haben wir das Flugmodell des Hubschraubers so lange optimiert, bis es sich anders genug anfühlte, und dann den natürlichen Animationszustand des Schraubers aus den Werten abgeleitet, die aus dieser Simulation hervorgingen. Wir haben auch versucht, es so wahrheitsgetreu wie möglich zu halten. Es gibt insbesondere eine Grenze dafür, wie weit er seinen Kopf drehen kann, um seine Kanone auszurichten. Wenn er weiter zielen will, muss er seine Flugroute anpassen, um die Kanone zum Anschlag zu bringen – er kann nicht einfach schummeln. Ein weiteres wichtiges Merkmal war sein Motorengeräusch. Wir haben eine räumliche Klangdarstellung, sodass der Spieler ungefähr sagen kann, wo er sich befindet. Aber der Schrauber ist ein sich schnell bewegendes Objekt, und er befindet sich in der Luft, weit entfernt von allen nahe gelegenen Bezugspunkten. Daher kann es schwierig sein, genau zu sagen, wie weit der Hubschrauber entfernt ist und wie schnell er sich bewegt. Um das zu beheben, haben wir dem Motorengeräusch einen Dopplereffekt hinzugefügt, der die Tonhöhe je nach Geschwindigkeit des Schraubers relativ zum Spieler ändert. Es ist ein subtiler Effekt, aber er ist äußerst effektiv, um Spielern unterbewusst zu helfen, die Position und Richtung des Schraubers wahrzunehmen. Wichtige Informationen, die dem Spieler mitteilen, dass er gejagt wird."
N/A4191"#commentary\cn_280_risk.mp3" "[ Ken Birdwell ] Der Rückblick auf Half-Life 2 nach 20 Jahren ist ernüchternd und zeigt, wie furchteinflößend der Großteil der Entwicklung war. Spielentwicklung ist hart – man bekommt nie wirklich das, was man erwartet. Es ist schwierig, die Risiken einzuschätzen, bevor man anfängt, auf ihnen aufzubauen. Ein Beispiel dafür ist unsere Gesichtsanimationstechnologie. Wir waren erst nach drei oder vier Jahren Arbeit zuversichtlich, dass es tatsächlich funktionieren würde. Aber wir konnten nicht warten, bis diese funktionierte. Im ersten Jahr begannen wir sofort, alle möglichen anderen Entscheidungen in Bezug auf unser Spieldesign, unsere Asset-Produktion und unsere anderen Technologien zu treffen. Alles basierend auf der Annahme, dass unsere Gesichtsanimationen am Ende technisch und qualitativ funktionieren würden. Wenn nicht, wären auch viele unserer anderen Entscheidungen ein Reinfall gewesen. Und das gleiche Risikoprofil gilt für andere große Entscheidungen, die wir früh getroffen haben. Wir konnten nicht warten. Wir mussten einfach weitermachen und hoffen, dass unsere Vermutungen in einigen Jahren zutreffen würden. Und das ist furchterregend."
N/A4192"#commentary\cn_281_hugs_and_pickups.mp3" "[ Ken Birdwell ] Selbst kleine Dinge zum Laufen zu bringen, kann manchmal ein Albtraum sein. Wenn man etwa einen Charakter dazu bringen möchte, einen anderen zu umarmen oder einfach nur einen Gegenstand von einem Tisch aufzuheben, kann das eine Menge Probleme verursachen. Noch schlimmer ist, dass in unserer dynamischen Umgebung, in der sich die Charaktere und Gegenstände nicht in voreingestellten Positionen befinden und der Spieler herumläuft und im Weg ist, ein gewisses Maß an Synchronisation erforderlich ist, das ziemlich knifflig sein kann. Das alles wird noch dadurch erschwert, dass Menschen bei so was machen, ohne groß nachzudenken. Wenn man zu einem Tisch geht, um eine Tasse aufzuheben, trifft man alle möglichen körperlichen Vorbereitungen, um seine Füße und Hände in die richtige Position zu bringen. Alles ist bereit, wenn man es braucht. Wenn Menschen sich umarmen, tun sie es beide gleichzeitig und passen sich ständig an die Bewegungen des anderen an. Damit das auch im Spiel funktioniert, war viel Synchronisationsarbeit erforderlich, um die Charaktere aufeinander und auf ihre Umwelt aufmerksam zu machen. Und gleichzeitig mussten sie auch mehr über ihre Zukunftspläne erfahren. Es ist verlockend, das Beispiel mit dem Aufheben einer Tasse in einzelne Schritte aufzuteilen – zum Tisch gehen, Tasse betrachten, Tasse aufheben –, weil es so viel einfacher ist und die Schritte wiederverwendbar sind. Aber so funktionieren Roboter, keine Menschen. Unsere Charaktere mussten wissen, dass sie zu einem Tisch gehen, um eine Tasse aufzuheben, damit sie an mehreren Teilen gleichzeitig arbeiten und sicherstellen konnten, dass ihre Hand die Tasse sofort greift, wenn sie dort ankommen. Mit zwei Charakteren ist es noch eine viel größere Abstimmung. Beide müssen sich einig sein, wo und wann es passieren soll, und alles muss nahtlos an Ort und Stelle passieren. Obwohl solche Momente einer einfachen Interaktion zwischen unseren Charakteren in den verschiedenen Welten oft kurz sind, waren sie entscheidend, um sie wie glaubwürdige Menschen erscheinen zu lassen."
N/A4193"#commentary\cn_282_ropes.mp3" "[ Mike Dussault ] Was uns in allen Referenzbildern auffiel, die wir für City 17 gesammelt hatten, war, dass überall Kabel und Drähte waren, die einen großen Teil der häufig auftretenden Details im Bild ausmachten. Wir liebten den Anblick dieser älteren, europäischen Städte, die in das behelfsmäßige Netz des modernen Lebens verstrickt sind. Wir hatten das Gefühl, dass wir eine Lösung für Kabel, Seile und ähnliche Elemente benötigten, und wir wollten, dass sie dynamisch sind. Unsere Leveldesigner wollten unbedingt Steckerrätsel erstellen, und indem sie an jeden Stecker ein Kabel anschlossen, konnten die Spieler die Mechanik besser verstehen. Zu Beginn der Produktion bauten wir ein Seilsystem und iterierten daran während der Entwicklung. Im Hintergrund besteht jedes Seil aus mehreren Segmenten, die zwischen den beiden Endpunkten gespannt sind und sich unabhängig voneinander bewegen können. Jedes Segment wirkt wie eine Feder und reagiert auf Kräfte im Spiel, wie einen leichten Wind oder das Vorbeifliegen eines Combine-Kampfhubschraubers. Beim Rendern wird jedes Segment der Kamera zugewandt gezeigt und mit Bumpmapping versehen, was entscheidend ist, um den Seilen ein realistisches, abgerundetes Aussehen zu verleihen."
N/A4194"#commentary\cn_283_vmpi.mp3" "[ Mike Dussault ] Während der Entwicklung stieg die Frustration über unsere langsamen Iterationen im Gameplay, vor allem weil die Kartenkompilierung, die zur Vorberechnung von Beleuchtung und Sichtbarkeit erforderlich war, Stunden dauerte. Im Jahr 2000 waren Computer viel langsamer als heute und hatten jeweils nur einen einzigen CPU-Kern. Inspiriert von SETI@Home, einem verteilten Programm, das PCs weltweit nutzte, um Radiowellen auf Anzeichen außerirdischen Lebens zu analysieren, bauten wir VMPi, unser eigenes verteiltes System, das den Vorgang der Kompilierung von Karten auf mehrere Computer verteilte. Heute laufen diese Arten von verteilten Systemen auf riesigen GPU-Clustern, aber damals ließen wir es einfach auf allen Computern in unserem Büro laufen. Um damit klarzukommen, dass sich unser Beleuchtungscode genauso schnell entwickelte wie unsere Karten, verteilte VMPi auch neue .exe-Dateien an alle Computer. Rückblickend war dies ein ziemlich riskantes Sicherheitskonzept, einfach schlecht. IT-Leute haben Albträume von solchen Szenarien. Wir schickten einfach eine beliebige ausführbare Datei an alle unsere PCs und sie führten sie aus. Es war der absolute Wahnsinn. Aber es hat für uns funktioniert und die Iterationsgeschwindigkeit unserer Karten deutlich erhöht, sodass es sich letztlich als unverzichtbares Werkzeug herausstellte."
N/A4195"#commentary\cn_284_field_of_view.mp3" "[ Kerry Davis ] In Half-Life 1 verwendeten wir ein 90-Grad-Sichtfeld, was damals für Ego-Shooter ziemlich normal war. Während der Entwicklung von Half-Life 2 waren wir damit jedoch unzufrieden. Da der Fokus unseres Spiels auf den Charakteren liegt, hatten wir große Anstrengungen in detaillierte Gesichts- und Körperanimationen gesteckt, aber das 90-Grad-Sichtfeld erlaubte es den Spielern einfach nicht, nah genug heranzukommen, um diese Details voll zu erfassen. Also begannen wir mit einem engeren Sichtfeld zu experimentieren und landeten schließlich bei 75 Grad. Sowohl für uns als auch für die Spieler war einige Umstellung erforderlich und es war ein zusätzliches Sichtfeld für die Ansichtsmodelle nötig, die die Waffe des Spielers darstellen und am unteren Bildschirmrand gehalten werden. Die Modelle wurden ursprünglich für 90 Grad konzipiert, daher sahen sie bei 75 Grad verzerrt aus. Aber diese Änderung erfüllte den gewünschten Zweck: unsere Charaktere in den Mittelpunkt des Spiels zu rücken."
N/A4196"#commentary\cn_285_reference_maps.mp3" "[ Randy Lundeen ] Da unsere Charaktere beginnend mit Half-Life 1 bis zu Half-Life 2 immer lebensnaher wurden, wollten wir, dass sich die Spielwelt genauso realistisch anfühlt. In Half-Life 1 war es aufgrund der Einschränkungen durch die Ego-Perspektive oft einfacher, sich auf stilisierte oder abstrakte Umgebungen zu stützen. Aber mit Half-Life 2 haben wir uns vorgenommen, eine Umgebung zu schaffen, die in der Realität verankert ist, was bedeutete, dass wir uns auf viele kleine Details konzentrieren mussten. Einer unserer wichtigsten Schritte bestand darin, Referenzkarten für standardisierte Proportionen im Spiel zu erstellen. Auf diesen Karten wurden Details wie Wand- und Türmaße, Türklinkenhöhen, Innenbeleuchtung, Möbelgröße und allgemein die Größe gängiger Objekte festgelegt. Wir erstellten standardisierte Texturen für Leveldesigner, komplett mit Maßstabs- und Beleuchtungswerten, sodass die Layouts von Anfang an einheitlich waren. In diesen Referenzkarten wurde nicht nur die physische Welt eingerichtet, sondern auch festgelegt, wie sich der Spieler darin bewegen würde — wie hoch er springen konnte, wie tief er sich ducken konnte und welche Abmaße Räumlichkeiten wie Lüftungsschächte haben. Basierend auf diesen Karten waren wir in der Lage, die Geometrie unserer Welt konsistent zu halten und überall im Spiel für Räume mit realistischer Größe zu sorgen."
N/A4197"#commentary\cn_286_response_rules.mp3" "[ Scott Dalton ] Wir wussten schon früh, dass wir viele dynamische Dialoge im Spiel haben wollten. Daher benötigten wir ein entsprechend effektives System, das es den Sounddesignern ermöglichte, Zeilen hinzuzufügen und zu optimieren, ohne die Programmierer einzubeziehen. Außerdem mussten Dialoge eng an das aktuelle Gameplay angepasst und Wiederholungen minimiert werden. Mit diesen Anforderungen entwickelten wir das Response-Rules-System. Immer wenn ein Charakter außerhalb einer choreografierten Szene spricht, bestimmt dieses System, welche Zeile gesprochen wird. Anstatt Zeilen direkt aufzugreifen, markiert die KI den Charakter bei relevanten Ereignissen mit \"Gelegenheiten zum Sprechen\". Zu diesen Ereignissen gehören die Entdeckung des Spielers, eine Verletzung, das Verschießen der letzten Kugel einer Waffe, eine Begegnung mit übermächtigen Feinden usw. Jedes Ereignis sendet dem Response-Rules-System ein Datenpaket über den aktuellen Stand des Spiels, und das System gibt die am besten passende Dialogzeile zurück (sofern vorhanden). Dank dieser Einstellung konnten unsere Sounddesigner eine detaillierte Entscheidungsmatrix für Dialoge erstellen. Ein Charakter kann auch je nach Situation andere Dialogoptionen haben. Der Text während des Nachladens unter Beschuss unterscheidet sich also vom Text nach dem Kampf, wenn nur noch ein Verbündeter übrig ist oder wenn ein Strider in Sicht ist. Als wir Half-Life 2 auslieferten, hatten wir das Gefühl, dass wir das Potenzial dieses Systems noch längst nicht ausgeschöpft hatten. Es wurde zu einem Kernmerkmal von Alyx in Episode 1 und trieb dynamische Dialoge in unseren späteren Spielen voran, darunter für die Klassen in TF2 und die Charaktere in Left 4 Dead."
N/A4198"#commentary\cn_287_audio_caching.mp3" "[ Yahn Bernier ] Ein weiteres Problem war die enorme Menge an Audiodaten im Spiel. 2003 war Arbeitsspeicher sehr begrenzt und mit all den Gameplay-Geräuschen, der Musik und den Dialogen hatten wir mehr Audio, als wir im RAM speichern konnten. Nichtsdestotrotz musste das entsprechende Gameplay-Audio sofort abgespielt werden, da es Spielern wichtige Informationen vermittelte. Also entwickelten wir einen Audio-Cache, in dem nur die ersten 125 Millisekunden jeder Audiodatei gespeichert wurden. 125 Millisekunden waren unsere beste Schätzung dafür, wie lange es dauerte, bis wir eine Audiodatei von der Festplatte abrufen konnten. Während des Gameplays spielten wir dann den Anfang des jeweiligen Audios aus unserem Audio-Cache ab und warfen gleichzeitig die gesamte Audiodatei von der Festplatte dazu. Die Datei aus dem Cache konnte so nahtlos in die Datei der Festplatte übergehen und das gesamte Audio ohne Unterbrechung für den Spieler abspielen. Zusätzlich gab es noch einige kleinere Funktionen. So wurde zum Beispiel aktuelles Audio vollständig im Arbeitsspeicher gespeichert, damit anderes, das System stärker belastenderes Audio nicht ständig geladen werden musste. Heutige Engines verwenden denselben Ansatz, und das nicht nur für Audiodateien."
40254199
40264200}
40274201}