Template:PatchDiff/March 6, 2026 Patch/hl2/resource/closecaption polish.txt
39153915"wood.scraperough" " "
39163916"plastic_box.scraperough" " "
39173917
N/A3918"#commentary\cn_001_physics_sound.mp3" "[ Jay Stelly ] Aby fizyka była dla gracza realistyczna, dźwięki generowane przez tę fizykę również musiały brzmieć prawdziwie. Jako ludzie jesteśmy przyzwyczajeni do odgłosów wydawanych przez przedmioty i materiały podczas różnych interakcji, nawet jeśli nie zwracamy na to uwagi. Wiedzieliśmy, że nie możemy uwzględnić wszystkiego, ale chcieliśmy skupić się na szczegółach, które w największym stopniu przyczyniały się do realistycznego brzmienia naszej fizyki. Zaczęliśmy od dźwięków poszczególnych obiektów podczas kolizji i uderzeń. Dzięki temu obiekt, taki jak drewniana skrzynia, mógł mieć niestandardowe dźwięki podczas zderzenia z innymi obiektami lub klasami obiektów. Następnie zaczęliśmy dynamicznie modyfikować te dźwięki w oparciu o charakterystykę zdarzenia fizycznego, takie jak masa obiektów i siła samego zderzenia. Działało to świetnie w przypadku kolizji, ale nie sprawdzało się w innych interakcjach, takich jak ocieranie się obiektów o siebie. Jak wiadomo, drewniana skrzynia wydaje inny dźwięk, gdy ociera się o ścianę, a inny, gdy jest o nią rzucana. Przyznam, że chyba nikt nie przeprowadził więcej badań nad niuansami właściwości fizycznych drewnianej skrzyni niż my. Aby uzyskać pożądany efekt tych interakcji, wykorzystaliśmy dźwięki zderzeń dla poszczególnych materiałów – metal o drewno, metal o metal i tak dalej. Dźwięki te były również dynamicznie modyfikowane w oparciu o szczegóły, takie jak twardość materiału lub rodzaj metalu. Aby system ten brzmiał prawidłowo, konieczne było wprowadzenie niezliczonych drobnych poprawek, które mogliśmy rozpoznać dopiero po uruchomieniu całości. Eksperymentowaliśmy również z niestandardowymi odgłosami toczących się obiektów, ale ostatecznie zrezygnowaliśmy z tego elementu, ponieważ nie byliśmy zadowoleni z rezultatów."
N/A3919"#commentary\cn_002_ramming_with_the_buggy.mp3" "[ Jay Stelly ] Nasz system fizyki opiera się na ciałach sztywnych, co oznacza, że nie obsługuje on żadnych deformacji ani zniszczeń obiektów. Jeśli obiekt fizyczny zostanie przez coś uderzony, może się poruszyć, jeśli jest to dozwolone w kodzie gry, ale w przeciwnym razie nic się nie dzieje. Kiedy więc przejeżdżasz łazikiem przez szklane okno, musimy zastosować pewien trik, aby wszystko działało zgodnie z oczekiwaniami. Ponieważ okno jest nieruchomym obiektem, symulacja fizyczna spowoduje odbicie od niego łazika, ale powiadomi nasz system gry, że doszło do kolizji. System gry zajmuje się zniszczeniem, więc rozbija okno na odłamki i nakazuje systemowi fizycznemu rozpoczęcie ich symulacji. Co najważniejsze, gra nakazuje również systemowi fizyki przywrócenie łazika do stanu sprzed zderzenia. Dzięki temu podczas następnej symulacji fizycznej pojazd będzie swobodnie przejeżdżać przez zniszczone okno. Proces ten powoduje jednoklatkowe zacięcie w fizyce łazika, ponieważ zatrzymuje się on na chwilę i jest teleportowany z powrotem do momentu przed zderzeniem. Przepraszamy, jeśli po ujawnieniu tej informacji Half-Life 2 stał się całkowicie niegrywalny. Jednak po obejrzeniu testów gry zdecydowaliśmy, że podoba nam się to chwilowe opóźnienie – jest to dodatkowe wrażenie w chwili zderzenia."
N/A3920"#commentary\cn_003_ramming_zombies_with_the_buggy.mp3" "[ Jay Stelly ] Jako istoty ludzkie mamy pewne oczekiwania wobec świata fizycznego, o czym wspomnieliśmy już kilkakrotnie w tym komentarzu. Jednym z tych oczekiwań jest to, że zombie potrącony samochodem powinien wystrzelić jak z procy w powietrze. Jednak uzyskanie takiego efektu w grze nie jest tak proste, jak w prawdziwym świecie. Ze względu na wydajność, przeciwnicy tacy jak zombie używają podczas rozgrywki uproszczonego hitboksa, czyli pola kolizji. Jest to pole, które ściśle przylega do zombie, nie wystając poza model. Jednak gdy zombie ginie, włącza się efekt ragdoll z bardziej dokładnymi polami kolizji dla poszczególnych kończyn, choć taka symulacja jest bardziej zasobożerna. Ta zmiana w przedstawianiu kolizji stanowi dodatkową komplikację gdy łazik uderza w zombie, wykraczając poza zwykłe zacięcie jednej klatki. Łazik, zderzając się z zombie, dotyka jego uproszczonego pola kolizji. Następnie gra zabija zombie i aktywuje ragdoll, który zaczyna symulować system fizyki. Teraz, dzięki dokładniejszym kolizjom poszczególnych kończyn, najbliższa część zombie może znajdować się kilka centymetrów od łazika. W efekcie, podczas kolejnej symulacji systemu fizycznego, zombie upada pod wpływem grawitacji, gdyż łazik już go nie popycha. Chociaż od uderzenia do ponownego dotknięcia mija tylko chwila, ta niewielka rozbieżność sprawiała, że taranowanie zombie było niezadowalające — często znikały one z pola widzenia gracza. Aby to naprawić, zapisaliśmy siłę, z jaką łazik uderzał uproszczone pole kolizji zombie, i zastosowaliśmy ją do aktywowanego efektu ragdoll. Dodaliśmy również niewielką siłę skierowaną do góry, aby nieco podrzucić potrąconego. Dzięki tym poprawkom po zderzeniu z łazikiem zombie zwykle padały na przód pojazdu, co lepiej odpowiadało oczekiwaniom graczy."
N/A3921"#commentary\cn_004_buggy_sound_engine.mp3" "[ Kelly Bailey ] Udźwiękowienie łazika było wyzwaniem, ponieważ chcieliśmy, aby sprawiał wrażenie naprawdę potężnego pojazdu, który jedzie z ogromną prędkością, mimo że mapy nie są wystarczająco duże, aby to umożliwić, a łazik tak naprawdę cały czas jedzie na jednym biegu. Jego maksymalna prędkość wynosi około 55 km/h. Na naszą obronę – 55 km/h to całkiem sporo jak na 2004 rok. Poza prędkością mamy jeszcze proste prowadzenie pojazdu. Jeśli za sterowanie odpowiada klawiatura, opcje gracza są w zasadzie binarne – buggy albo przyspiesza, albo nie, skręca w jedną stronę lub nie. Musimy więc stworzyć całą tę złożoność dźwiękową, aby przedstawić symulację, w której ta złożoność w zasadzie nie istnieje. Zbudowaliśmy więc atrapę silnika dla udźwiękowienia łazika. Ma ona własną skrzynię biegów, a my łączymy polecenia gracza z danymi z symulacji fizycznej. Mierzymy moment obrotowy każdego symulowanego koła, niezależnie od tego, czy się kręci, czy ma kontakt z podłożem, i tworzymy zestaw zapętlonych dźwięków, a następnie ostrożnie mieszamy je ze sobą, gdy atrapa silnika zmienia biegi i reaguje na dane z kół. Po prostu próbowaliśmy różnych rzeczy. Dodaliśmy więcej złożoności. Dorzuciliśmy kilka drobnych poprawek, aż łazik przyjemniej się prowadziło, a szybka jazda była satysfakcjonująca. Większość graczy nie wspomniała nic poza tym, że łazik brzmi dobrze, a dla nas to sukces, biorąc pod uwagę liczbę szalonych mechanizmów działających pod jego maską."
N/A3922"#commentary\cn_005_buggy_sound_design.mp3" "[ Kelly Bailey ] Projektowanie dźwięku łazika oparto na próbkach ze starego Camaro z 1968 roku. Wybraliśmy ten samochód ze względu na niesamowite silniki V8 z ogromnymi tłokami. Nie ma drugiego takiego mocnego, rozpoznawalnego dźwięku i tego właśnie szukaliśmy. Skrzynia biegów wydaje również naprawdę wspaniały mechaniczny odgłos, gdy wóz przestaje przyspieszać. Ta kombinacja wydawała się naprawdę odpowiednia dla zasadniczo binarnego systemu sterowania, z którym musieliśmy pracować. Fałszywa skrzynia biegów nie była więc wzorowana na prawdziwym samochodzie. Zamiast tego zaprojektowaliśmy prosty system, nagradzający gracza za przytrzymanie pedału gazu. To coraz głośniejsze zapętlenie, stale budujące napięcie i zmieniające biegi, gdy dźwięk jest odtwarzany od nowa. Ponieważ gracz może szybko pokonać nasze relatywnie małe mapy, zadbaliśmy o to, by przyspieszanie było przyjemne przez ten krótki czas."
N/A3923"#commentary\cn_006_automating_dsp.mp3" "[ Kelly Bailey ] Wszystkie dźwięki, które słyszy gracz, są przepuszczane przez nasz system cyfrowego przetwarzania sygnałów (DSP), który służy do modyfikacji dźwięku, by odzwierciedlić otoczenie gracza. Na przykład, ten sam dźwięk będzie brzmiał inaczej w garażu, małym pomieszczeniu i na zewnątrz. W Half-Life 1 ręcznie umieściliśmy niewidoczne węzły w całym świecie, aby zdefiniować ustawienia DSP dla każdej przestrzeni. W przypadku Half-Life 2 wiedzieliśmy, że samodzielne umieszczanie węzłów będzie zbyt czasochłonne, ponieważ chcieliśmy stworzyć większą grę, a w zespole nadal mieliśmy tylko jedną osobę odpowiedzialną za dźwięk. Stworzyliśmy więc system, który automatycznie określa ustawienia DSP wokół gracza w czasie rzeczywistym. Robi to, analizując przestrzeń, w której znajduje się odbiorca, oceniając poziom otaczającej głośności i badając materiały, z których składa się środowisko. Następnie system dopasowuje tę przestrzeń do jednego z 25 ręcznie utworzonych podstawowych typów DSP, a my dostosowujemy niektóre parametry i tworzymy w pełni szczegółowy DSP, który modyfikuje dźwięki słyszane przez gracza."
N/A3924"#commentary\cn_007_dynamic_mixing.mp3" "[ Kelly Bailey ] Podczas rozgrywki wiele dźwięków jest odtwarzanych jednocześnie, ale niektóre z nich są oczywiście ważniejsze od innych i musimy ustawić różne poziomy głośności, by te kluczowe były wyróżnione. W filmie miksowanie dźwięku odbywa się na etapie postprodukcji. Jednak w grze odbywa się to w czasie rzeczywistym, w odpowiedzi na działania gracza, więc nie możemy z góry przewidzieć, które dźwięki będą odtwarzane jednocześnie. Zaradziliśmy temu, grupując wszystkie dźwięki według typów i nadając im priorytet. Podczas rozgrywki system audio monitoruje wszystkie aktywne dźwięki i jeśli jest tam odgłos o wyższym priorytecie, reszta grupy jest przyciszana. To miksowanie można regulować. Jeśli w jednej scenie strzały muszą być głośne, możemy nadać im wyższy priorytet. Jeśli konkretna linia dialogowa musi być wyraźnie słyszalna, można wymusić ściszenie pozostałych dźwięków. To samo robimy z muzyką. Jest to subtelny, ale bardzo ważny system, który zapobiega kakofonii."
N/A3925"#commentary\cn_008_soundscapes.mp3" "[ Kelly Bailey ] W Half-Life 1 dźwięki otoczenia były umieszczane ręcznie i indywidualnie dostrajane. W przypadku Half-Life 2 chcieliśmy uzyskać więcej odgłosów otoczenia w stworzonych środowiskach, które miałyby wyższą jakość i wymagałyby mniejszego nakładu pracy przy rozmieszczaniu. Dlatego stworzyliśmy system, który nazwaliśmy pejzażem dźwiękowym. Ten mały program kontroluje, które odgłosy otoczenia są odtwarzane i skąd pochodzą, oraz jak zachowują się w konkretnym środowisku. Na przykład brzęczenie much, szum wiatru, śpiew ptaków, pociąg w oddali, odległa walka. Pejzaż dźwiękowy mógł losowo wybierać i odtwarzać te dźwięki i, co bardzo ważne, zapewniać płynne przejście, gdy gracz porusza się po mapie. Pejzaże dźwiękowe mogą również zawierać w sobie inne pejzaże, co pozwala nam tworzyć zestawy dźwięków wielokrotnego użytku – na przykład odległa walka może obejmować odgłosy broni ręcznej, dalekie eksplozje, przelatujący helikopter. Pejzaże mogły być dynamicznie składane i odtwarzane z wielu pojedynczych odgłosów, co pomaga uniknąć sztuczności pojedynczej pętli dźwięków. Ogólnie rzecz biorąc, system pejzaży odwalił kawał roboty dla udźwiękowienia Half-Life 2 i odpowiadał za praktycznie każdy słyszalny odgłos, który nie jest bezpośrednio związany z rozgrywką."
N/A3926"#commentary\cn_009_audio_over_distance.mp3" "[ Kelly Bailey ] Duże przestrzenie na mapach Wybrzeża skłoniły nas do poszukiwania rozwiązania, uwzględniającego zmiany dźwięku w zależności od odległości. Na przykład na tych mapach wróg może znajdować się w odległości ponad 100 metrów, więc wystrzał z broni powinien brzmieć inaczej, niż z bliska. Zdecydowaliśmy się zapisać nasze dźwięki w jednym pliku stereo – te bliskie w lewym kanale, a dalekie w prawym. Podczas odtwarzania stosujemy płynne przenikanie, czyli zmieniamy proporcje dźwięku słyszanego w obu kanałach w zależności od odległości gracza od źródła. To proste rozwiązanie się sprawdziło i pomogło uporać się z ograniczeniami pamięci. Można to łatwo usłyszeć w praktyce – wystarczy zauważyć, jak zmienia się odgłos wystrzałów żołnierzy Kombinatu, gdy się do nich zbliżamy."
N/A3927"#commentary\cn_010_flying_vehicle_audio.mp3" "[ Kelly Bailey ] Wielcy latający wrogowie w grze to wyjątkowe wyzwanie dla projektu udźwiękowienia. Podczas walki są dużo bardziej ruchliwi niż inni przeciwnicy i często oddalają się od gracza. Są też naprawdę niebezpieczni, jeśli widzą swój cel. Te czynniki sprawiły, że skupiliśmy się na rozwiązaniu dźwiękowym związanym z przesłonięciem, czyli określeniem, czy gracz widzi wroga, a wróg gracza. Chcieliśmy uzyskać wyraźne rozróżnienie dźwiękowe między sytuacjami, w których uda się nawiązać kontakt wzrokowy. Dźwięki silników latających pojazdów składają się z wielu zapętlonych odgłosów, które odtwarzamy jednocześnie. Niektóre pętle są przetwarzane przez system DSP w oparciu o przestrzeń, w której się znajdujecie, zaś inne aktywują się bezpośrednio, bez przetwarzania. System DSP dodaje więcej efektu echa otoczenia, gdy przepuszczamy przez niego dźwięk. Kiedy obiekt latający jest zasłonięty i nie może was zobaczyć, zwiększamy częstotliwość pętli przetwarzanych przez DSP, przez co odgłos wydaje się bardziej odległy. Kiedy wróg wyłania się zza przeszkody i może was dostrzec, odtwarzamy więcej bezpośrednich odgłosów. Tak tworzymy wrażenie, że dźwięk jest albo odległy i bezkierunkowy, albo dociera bezpośrednio wzdłuż linii wzroku. Można to usłyszeć, gdy helikopter wyłania się zza budynku – zwróćcie uwagę na tę różnicę."
N/A3928"#commentary\cn_011_bullet_audio.mp3" "[ Kelly Bailey ] Jednego jesteśmy pewni – gracza będzie mijać mnóstwo pocisków, więc poświęciliśmy sporo czasu na dopracowanie odpowiedniego efektu dźwiękowego. Niestety, pociski w grze docierają do celu natychmiast, więc nie możemy po prostu dołączyć do nich świstu i polegać na ich ruchu, by ustalić pozycję. Po kilku eksperymentach opracowaliśmy rozwiązanie: określając najbliższy punkt trajektorii kuli względem ucha gracza, obliczamy dokładny czas i pozycję, w której teoretycznie przelatuje obok niego. W tym momencie odtwarzamy dwa różne dźwięki, aby symulować efekt Dopplera – jeden dla zbliżającego się pocisku, a drugi dla oddalającego się. Opóźniamy oddalający się odgłos w oparciu o obliczony czas jego przelotu."
N/A3929"#commentary\cn_012_staircase.mp3" "[ Aaron Seeler ] W grze pojawiają się sytuacje wynikające z prostych i dość oczywistych założeń projektowych, a te schody są przykładem dwóch z nich. Pierwszym było ujęcie budzącej się Cytadeli, by pokazać graczowi, że przebudził uśpionego kolosa. Drugim było zaprezentowanie systemu ragdoll. Chociaż obecnie jest to standard, w 2004 roku realistyczne przewracanie się ciał nadal było czymś nowym, a schody stanowiły idealną scenę do pokazania tej koncepcji."
N/A3930"#commentary\cn_013_alyx_and_mossman.mp3" "[ Bill Fletcher ] W naszych wczesnych planach dotyczących fabuły Half-Life 2 chcieliśmy stworzyć coś mniej skupionego na samej rozgrywce. Nie chodziło tylko o historię o zwycięstwie oczywiście dobrego gracza nad oczywistymi złoczyńcami. Zamiast tego postanowiliśmy skupić się na postaciach i ich relacjach. Uznaliśmy, że najciekawszym elementem Half-Life 2 będzie rodzinna dynamika. Z tego pomysłu zrodziło się napięcie między Alyx i Mossman i spodobało nam się, ponieważ wydawało się, że jest to bliska relacja, którą gracze zrozumieją i mogą się z nią utożsamiać."
N/A3931"#commentary\cn_014_exposition_board.mp3" "[ Danika Rogers ] Umieściliśmy tu wizualną historię pełną detali, ponieważ to w tym miejscu gra w najbardziej oczywisty sposób zachęca odbiorców do zbadania otoczenia. Chociaż naszym głównym zadaniem jest budowanie świata, staramy się też podkreślić relacje między Eliem i Breenem, nadając kontekst głównemu konfliktowi fabularnemu."
N/A3932"#commentary\cn_015_city_17_awakens.mp3" "[ David Sawyer ] Początkowa sekcja dworca została zaprojektowana tak, by miasto wydawało się obojętne wobec gracza, jakby Gordon był kolejnym bezimiennym, anonimowym obywatelem do zniewolenia. Jednak podczas nalotu na kamienicę i pościgu po dachach miasto identyfikuje gracza jako anomalię i zaczyna się burzyć. Gdy gracz jest agresorem, miasto skupia na nim swoją uwagę. Megafony Nadzoru, po raz pierwszy słyszane podczas nalotu, odegrały kluczową rolę w przekazaniu tej wiadomości. Jeśli gracze słuchają uważnie, mogą uzyskać wiele informacji dotyczących świadomości miasta. A nawet jeśli nie zwracają uwagi, udźwiękowienie nadal wyzwala emocje, na których nam zależało."
N/A3933"#commentary\cn_016_elis_lab.mp3" "[ Dhabih Eng ] Laboratorium Elia zbudowaliśmy po laboratorium doktora Kleinera, co pozwoliło nam lepiej zrozumieć, jak tworzyć i projektować odpowiednią choreografię scen. Tak udało się stworzyć złożony scenariusz, dający graczowi więcej możliwości reakcji. Obecność wielu postaci wykonujących różne czynności w pomieszczeniu utrudniała inscenizację i wymagała wielu iteracji oraz testów, aby wszystko działało jak trzeba. Doświadczenie pokazało, że gracze zwykle wczuwali się w scenę – potrzebowali jedynie subtelnych wskazówek, by wiedzieć, czego oczekujemy. A jeśli coś ich rozproszyło, scena musiała delikatnie zwolnić tempo i poczekać na ich powrót."
N/A3934"#commentary\cn_017_feel_free_to_look_around.mp3" "[ Dhabih Eng ] Zrównoważenie chęci gracza do eksploracji z celem narracji zawsze stanowiło wyzwanie. Chcieliśmy, aby pomieszczenie było pełne interesujących rzeczy do obejrzenia, ale wielu graczy nie badało go, dopóki nie upewnili się, że nie przegapią żadnego z działań postaci. Dlatego Eli mówi graczowi, by rozejrzał się w połowie sceny – to sygnał, że eksploracja jest dozwolona. Od tego momentu mogliśmy aktywować różne niestandardowe scenki w oparciu o to, co wzbudziło zainteresowanie gracza."
N/A3935"#commentary\cn_018_interstitial_scenes.mp3" "[ Eric Kirchmer ] Podczas testów często znajdowaliśmy miejsca, w których gracze tracili z oczu cel, co nie jest rzadkością w grach takich jak Half-Life. By temu zaradzić, dodaliśmy mniejsze sceny pośrednie, które wskazują graczom ścieżkę i cel. Po zakończeniu większości prac nad większą choreografią, taką jak laboratorium Kleinera, połączenie tych mniejszych scen było stosunkowo proste. Odkryliśmy, że wykorzystanie postaci w takich momentach działało znacznie lepiej, niż poleganie na pasywnej narracji lub przypomnieniach wyświetlanych w menu pauzy."
N/A3936"#commentary\cn_019_overwatch.mp3" "[ Josh Weier ] W procesie tworzenia wykorzystaliśmy darmowe narzędzie zamieniające tekst na mowę, by wygenerować głos Nadzoru. Jednak przed premierą okazało się, że nie mamy praw do korzystania z tego rozwiązania. Zorganizowaliśmy przesłuchania aktorów głosowych, by znaleźć kogoś, kto odtworzy to, co podobało nam się w wygenerowanych kwestiach. Szybko znaleźliśmy Ellen McClain, której aktorstwo idealnie wpisało się w oczekiwania. Podczas sesji odtwarzaliśmy jej wygenerowane kwestie, by mogła je naśladować w swoim stylu. Początkowo była nieco sarkastyczna, gdyż prosiliśmy o naśladowanie robotycznych wypowiedzi. Jednak kilka lat później, kiedy powróciła do swojej kultowej roli GLaDOS w *Portal*, kreatywnie włączyła tę intonację do swoich dialogów."
N/A3937"#commentary\cn_020_box_car_joe.mp3" "[ Laura Dubuk ] W tej krótkiej scenie pierwotnie występowały dwie postacie ludzkie, ale w trakcie prac jedną z nich zastąpiliśmy Wortygontem. Chcieliśmy pokazać, że obcy współistnieli z ludźmi i też przeciwstawiali się Kombinatowi. Daliśmy im także możliwość leczenia gracza, choć nie wykorzystaliśmy w pełni tej funkcji w całej grze. Wortygonty stały się użytecznym narzędziem narracji, skracającym dialogi, ponieważ ich zbiorowy umysł uzasadniał pełną wiedzę o świecie i celach gracza. Dzięki temu nigdy nie musieli zadawać pytań, co pozwoliło nam zgrabnie ominąć problem pisania dialogów dla milczącego bohatera."
N/A3938"#commentary\cn_021_mossman.mp3" "[ Marc Laidlaw ] Judith Mossman oparliśmy na bohaterce, która miała pojawić się we fragmencie Half-Life 1, ale został on wycięty z podstawowej wersji i wykorzystany w Uplink, już bez niej. Uważamy ją za najbardziej złożoną postać w Half-Life 2. Wiedzieliśmy, że będziemy balansować na granicy, jeśli chodzi o odczucia graczy, jeszcze przed dotarciem do Nova Prospekt, ponieważ zaufane źródła informacji nie są zgodne – Eli ją lubi, ale Alyx nie. Zdawaliśmy sobie sprawę, że złożoność relacji postaci jest ograniczona, ale uznaliśmy, że dynamika stosunków macochy z córką będzie zrozumiała dla graczy. Nieważne czy zgadzacie się z Mossman, czy nie, ostatecznie dokonuje heroicznych czynów. Zostaje podwójną agentką, by zdobyć informacje i chronić Elia oraz Alyx. Ale nie uwzględniła w planie Gordona."
N/A3939"#commentary\cn_022_hands_free.mp3" "[ Matt Wright ] Przed premierą Half-Life 2 większość strzelanek od razu dawała graczowi broń palną lub białą, ale my zdecydowaliśmy się zacząć od pustych rąk. Bez broni łatwiej było nauczyć gracza nowych sposobów interakcji ze światem i wprowadzić go w fabułę. Chcieliśmy, by przeszedł transformację z uciekiniera do napastnika, a wyposażenie go w broń w odpowiednim momencie to naturalny rozwój sytuacji. Kiedy w końcu otrzymuje oręż, przestaje uciekać. Ponoć czasami, aby wygrać, wystarczy odejść ale wiemy, że to nieprawda. Najprostszą drogą do zwycięstwa jest bieganie i strzelanie do woga."
N/A3940"#commentary\cn_023_metrocop_scene.mp3" "[ Mike Dussault ] To kolejna scena, która ma pokazać, że metrogliniarze są źli – tyle że tym razem gracz ma broń i w końcu może coś z tym zrobić. To „coś” wylatuje z lufy. Gracz musiał poczuć, że jest po dobrej stronie, a ta chwila to podkreśla. Metrogliniarze nadal są ludźmi, w przeciwieństwie do reszty Kombinatu, więc postaraliśmy się, by działania gracza były postrzegane jako wymierzenie sprawiedliwości, a nie tylko wyładowanie gniewu."
N/A3941"#commentary\cn_024_moving_the_gravity_gun.mp3" "[ Ted Backman ] Kiedy powstał pierwszy prototyp działa grawitacyjnego, planowaliśmy dać je graczowi w połowie gry. Jednak w trakcie testów zauważyliśmy potencjał tego pomysłu i zrozumieliśmy, że działo grawitacyjne, a co ważniejsze, możliwość wystrzeliwania pił w głowy zombie, powinna pojawić się wcześniej. Dlatego laboratorium Elia zostało przeniesione do wcześniejszego etapu. Ta kluczowa zmiana wpłynęła na sukces Half-Life 2. Wskazuje, że fabuła i rozgrywka są ze sobą powiązane i żadna z nich nie może mieć pierwszeństwa – muszą współgrać."
N/A3942"#commentary\cn_025_buggy_birds.mp3" "[ Adrian Finol ] Podczas jednego z pamiętnych testów Wybrzeża gracz wrócił do swojego pojazdu po zwiedzaniu domu i przypadkiem zobaczył przelatującego ptaka. Krzyknął do niego, by trzymał się z dala od łazika, narzekając, że ptaki często brudzą jego samochód w prawdziwym życiu. Przedyskutowaliśmy tę sytuację, bo po raz pierwszy mieliśmy do czynienia z obiektami niezależnymi od gracza, na które naprawdę zwrócił uwagę. Uznaliśmy to za okazję do dalszych eksperymentów i stworzyliśmy system odpowiadający za moment, którego obawiał się tester. Kiedy łazik na dłużej znika z pola widzenia, w losowym miejscu na karoserii pojawia się mewa. Z upływem czasu pozostawia ślady odchodów na pojeździe i odlatuje dopiero, gdy wróci gracz. Oczywiście testerzy chcieli umyć wóz, więc dodaliśmy tę funkcję poprzez wjechanie do płytkiej wody. Było to na późnym etapie rozwoju, więc mieliśmy już odpowiednią technologię do wdrożenia tego pomysłu. Wiemy, że tylko niewielki procent graczy to odkryje, ale jeśli uda nam się skutecznie wprowadzić takie detale i będzie ich wystarczająco dużo, większość odbiorców spotka się z co najmniej jednym z nich."
N/A3943"#commentary\cn_026_bridge_gunship.mp3" "[ Adrian Finol ] Byliśmy zadowoleni z walki z kanonierką, choć jej przygotowanie było trudne ze względu na geometrię poziomu. Znajdując się pod mostem, kanonierka mogła swobodnie poruszać się wokół gracza, wykorzystując wszystkie trzy wymiary, aby w różnych momentach ustawiać się nad i pod nim. Dźwigary zapewniały osłonę przed pociskami, dzięki czemu ostrzał z powietrza tworzył ciekawy i dynamiczny efekt wizualny oraz dźwiękowy."
N/A3944"#commentary\cn_027_floor_is_lava.mp3" "[ Adrian Finol ] Rozgrywka oparta na znanych koncepcjach, takich jak „podłoga to lawa”, ułatwiła tłumaczenie mechaniki. Podobało nam się, że system fizyki dawał graczom dużą swobodę twórczą w radzeniu sobie z wyzwaniami. Niektórzy budowali przejścia z wielu przedmiotów, inni skupiali się na użyciu tylko dwóch ulubionych kawałków blachy. Jedni ostrożnie szli po skałach, obawiając się upadku, zaś drudzy kierowali się bezpośrednio do wyjścia, przechodząc po obiektach tuż nad piaskiem. Style gry były zróżnicowane — niektórzy gracze uważali przywołanie mrówkolwów za porażkę i natychmiast wczytywali zapis, inni wspinali się z powrotem na skały, by odzyskać siły. Cieszył nas też fakt, że gra stała się łamigłówką nawigacyjną, ale mogła zmienić się w arenę, jeśli gracze tego chcieli. Niektórzy po prostu skakali na piasek, by wywalczyć sobie drogę do końca poziomu."
N/A3945"#commentary\cn_028_opportunistic_moments.mp3" "[ Ariel Diaz ] Niektóre pamiętne momenty wynikają z interakcji wielu systemów, ale zdajemy sobie sprawę, że takie chwile zdarzają się rzadko. Często chcieliśmy, by więcej graczy mogło ich doświadczyć. Pojawia się tu pewien dylemat: gdy wiemy, że gracze na coś trafią, możemy w to włożyć więcej wysiłku. Jeśli jednak moment wydaje się sztuczny i wymuszony, gracze mogą nie zareagować na niego pozytywnie. Filmowa śmierć kanonierki jest przykładem sytuacji, w której nieco podkręciliśmy akcję, by zwiększyć szanse na niezapomniany moment, unikając przy tym oczywistości. Dzięki projektowi mapy i trasy lotu gracz i kanonierka prawdopodobnie znajdą się we właściwych miejscach, gdy dojdzie do zestrzelenia. Kiedy tak się stanie, aktywujemy zderzenie kanonierki z samochodami. W innym wypadku spada zwyczajnie. Jest to trochę naciągane, ale testerzy nie mieli nic przeciwko takim dobrze rozegranym scenom."
N/A3946"#commentary\cn_029_assault_on_nova_prospekt.mp3" "[ Ariel Diaz ] Mając nieskończoną armię mrówkolwów atakującą ufortyfikowaną bazę Kombinatu na wybrzeżu, trudno nie stworzyć poziomu inspirowanego Normandią. Nasz wstępny prototyp zawierał okopy prowadzące do Nova Prospekt, z zabójczymi karabinami maszynowymi zmuszającymi gracza i jego mrówkolwy do pozostania w ukryciu. Gdy nad głową przelatywały pociski z karabinów i skaczące mrówkolwy, emocje rosły. Niestety, pomysł nie mieścił się w ramach wydajnościowych i ostatecznie musieliśmy stworzyć inny układ mapy. Ale pozostawiliśmy karabiny maszynowe, ponieważ ich śmiercionośność zachęcała graczy do polegania na mrówkolwach."
N/A3947"#commentary\cn_030_buggy_physics.mp3" "[ Charlie Brown ] Fizyka łazika to efekt wielu prób i błędów. Chcieliśmy, by wydawał się szybki, choć jego maksymalna prędkość to około 55 km/h, więc musieliśmy trochę oszukiwać, by wywołać odpowiednie wrażenie. Dodaliśmy siłę pionową do skoku turbo i lekkie nadrzucanie tyłem podczas ślizgu na ręcznym. Bez tych elementów łazik kiepsko się prowadziło przy niskiej prędkości. Poza tym, świat był dość nieprzewidywalny ze względu na fizykę – gracze mogli się zderzyć z wieloma rzeczami, więc dbaliśmy o to, by zawsze mieli jakieś wyjście z opresji. Wymagało to wielu eksperymentów i testów. Ostatecznie zdecydowaliśmy się na dość niezgrabną, nierealistyczną symulację – łazik wybacza dużo błędów i trudniej go wywrócić. Jego środek ciężkości jest bardzo nisko, a koła, choć wydają się stale obracać, w rzeczywistości tego nie robią. Była to nasza pierwsza próba stworzenia symulacji fizyki pojazdu i wyciągnęliśmy z niej wnioski. Dzięki temu samochód z Epizodu 2 był znacznie łatwiejszy w prowadzeniu."
N/A3948"#commentary\cn_031_the_bridge.mp3" "[ Charlie Brown ] Ta sekcja była wzorowana na moście Deception Pass, znajdującym się przy drodze do biura Valve. Początkowo była to czysta zagadka nawigacyjna, ale stopniowo dodawaliśmy do niej kolejne elementy. Stała się również głównym obszarem testowym dla tarcia na krawędzi. Nasz system ruchu subtelnie zwiększa tarcie podczas hamowania gracza, gdy zbliża się do krawędzi powierzchni. Gracze tego nie zauważyli – pewnie dlatego, że jest to zgodne z ich celem, czyli zatrzymaniem się nad krawędzią, by spojrzeć w dół, co współgra z ludzką tendencją do poruszania się wolniej i ostrożniej w pobliżu przepaści. Jest to kluczowa funkcja w tej części gry. Wiemy to, ponieważ w pewnym momencie przypadkowo coś popsuliśmy i nagle wszyscy testerzy zaczęli ciągle spadać i ginąć."
N/A3949"#commentary\cn_032_coast.mp3" "[ Chris Green ] Chcieliśmy stworzyć otwartą sekcję dla łazika, ale musieliśmy jakoś ograniczyć pole manewru gracza. Wybrzeże tworzyło naturalną granicę wzdłuż jednej strony mapy, jednocześnie zachowując wrażenie otwartości i przestrzeni. Była to też wizualizacja skutków eksploatacji zasobów Ziemi przez Kombinat. Testerzy nadal próbowali wypływać w morze, więc dodaliśmy pijawki, by ich odstraszyć. Nie mogły być prawdziwym wrogiem, z którym da się walczyć, więc są trochę magiczne. Gracze rozumieli, że przekraczają granice gry, więc nie skupialiśmy się na ich projekcie."
N/A3950"#commentary\cn_033_grenade_house.mp3" "[ Dave Riller ] Wiele elementów Half-Life polega na dostarczaniu graczom nowych wrażeń z walki na każdym kroku, nawet jeśli są to tylko niewielkie zmiany. Nie wszystkie muszą być wyzwaniami wymagającymi umiejętności; czasami mogą to być po prostu zabawne chwile, dające graczowi przyjemność. Dom pełen granatów jest jednym z takich momentów, z tym że odwróciliśmy typową sytuację. Gracz, zamiast zrzucać granaty na wrogów poniżej, musi zlikwidować tych nad sobą. Nieskończony zapas granatów jest nieco nieporadną zachętą do rozegrania scenariusza, ale niezniszczalna skrzynka pozwala wspiąć się, nawet jeśli gracz wysadził wszystko wokół."
N/A3951"#commentary\cn_034_buggy_training_course.mp3" "[ David Sawyer ] Ta sekcja treningowa służy do eksperymentów z łazikiem. W momencie premiery Half-Life 2 taki poziom symulacji fizycznej w pojeździe był nowością, więc chcieliśmy dać odbiorcom wystarczająco dużo okazji do zabawy. Gracz właśnie opuścił ciasne zaułki Ravenholm i dla kontrastu otrzymuje nagrodę w postaci szybkiego poruszania się po otwartej przestrzeni, siedząc w bezpiecznym pojeździe. Zadbaliśmy o to, by wydostanie się z tego obszaru wymagało wykonania turbo skoku, co było jednocześnie testem sprawdzającym, czy gracze dostatecznie opanowali sterowanie, a przy okazji gwarancją, że nie porzucą swojego łazika."
N/A3952"#commentary\cn_035_ambush.mp3" "[ David Sawyer ] Jednym z typowych wyzwań związanych ze strzelankami w stylu Half-Life jest to, że gracz nieustannie porusza się naprzód, w nieznane. Oznacza to, że kiedy rozpoczyna walkę, jest w nieznanym otoczeniu i nie ma pojęcia, jak podejść do starcia. Korzystamy z wielu metod pomagających rozwiązać ten problem, a ta zasadzka to dobry przykład. Po przybyciu gracz walczy z Kombinatem pomiędzy domami. W takcie bitwy i późniejszej eksploracji ma szansę poznać układ areny. A potem, podczas badania strychu, pojawia się druga fala Kombinatu. Tym razem, znając mapę, to gracz ma przewagę, co pozwala mu podejmować bardziej taktyczne decyzje, by wyjść cało z zasadzki."
N/A3953"#commentary\cn_036_bugbait_training.mp3" "[ David Sawyer ] To niezgrabne szkolenie z używania przynęty wynika z braku czasu, a gracze musieli zrozumieć, jak działa to narzędzie, aby koncepcja na Nova Prospekt miała sens. Zwykle staramy się nadać takim treningom charakter i kontekst, by nie wydawały się samouczkami, a naturalnym odkrywaniem czegoś nowego. Tym razem nie do końca się to udało. Choć wydaje się to oczywiste, gracze nie załapali od razu, jak działa przynęta. To dalsza część gry, więc mają doświadczenie w radzeniu sobie z wrogami. Zanim dodaliśmy szkolenie, pierwsi testerzy wyposażeni w przynęty przeszli do następnego poziomu i instynktownie zastrzelili pierwszego napotkanego mrówkolwa, bo do tej pory to działało. Half-Life zachęca do podejścia „najpierw strzelaj, potem zadawaj pytania”. Co więcej, gdy gracze dotarli do Nova Prospekt, nie rzucali przynętą w żołnierzy Kombinatu i polegali na zwykłej broni. Potrzebowaliśmy tego treningu nie tylko po to, by pokazać, jak działa przynęta, ale też by zademonstrować, że pobliskie mrówkolwy nie zaatakują gracza."
N/A3954"#commentary\cn_037_vortigaunt_extraction.mp3" "[ Dhabih Eng ] Ta arena to wyzwanie projektowe z kilku powodów. Po pierwsze, strażnik jest przeciwnikiem walczącym wyłącznie w zwarciu, więc nie mogliśmy pozwolić graczowi dotrzeć w miejsca, do których wróg nie ma dostępu. Chcieliśmy dodać kilka ataków dystansowych, ale rezultat był kiepski – na przykład plucie śluzem wyglądało absurdalnie. Zostawiliśmy tylko jeden atak z dystansu – rzucanie obiektami fizycznymi, ale te musiały znajdować się w zasięgu strażnika, a nie zawsze tak było. Drugą kwestią było zadbanie o to, by Wortygont mógł dotrzeć do zwłok strażnika, niezależnie od miejsca jego zgonu. To ważne, bo gra nie ruszy dalej, póki obcy nie wydobędzie przynęty."
N/A3955"#commentary\cn_038_dropship_deployment.mp3" "[ Doug Wood ] Zrzut żołnierzy z transportowców był trudny, ponieważ ich postacie musiały pojawić się wewnątrz innego obiektu stałego. Aby wydostać ich na otwartą przestrzeń, gdzie mogliby się poruszać, natychmiast odtwarzana jest animacja, w której wyskakują z kontenera, gdy tylko się pojawią. Gdy to zadziałało, napotkaliśmy kolejny problem – doświadczeni gracze czekali przed kontenerem i strzelali do wychodzących żołnierzy. Aby temu zaradzić, dodaliśmy do kontenera wieżyczkę, która chroni żołnierzy podczas desantu. Rozwiązanie nie zapobiega całkowicie wykorzystywaniu tej sytuacji przez graczy, zwłaszcza jeśli używają broni pośredniej, takiej jak granaty, ale wydawało się realistyczne i przypominało prawdziwe środki zaradcze, które mógłby podjąć ktoś myślący strategicznie."
N/A3956"#commentary\cn_039_laser_guided_rpg.mp3" "[ Eric Smith ] Laserowe naprowadzanie RPG było dla nas problemem, bo ciężko je wyjaśnić. Wielu testerów wystrzeliwało RPG i od razu chowało się za osłoną, co oznaczało, że nie widzieli toru lotu pocisku. Co gorsza, nie zdawali sobie sprawy, że rakieta zawraca i leci prosto na nich. Próbowaliśmy różnych elementów HUD i wskaźników laserowych, aby pomóc graczom, ale większość je przeoczyła, skupiając się na wrogu. Wprowadziliśmy tyle podpowiedzi, ile mogliśmy, podkreślając tę funkcję w dialogu z Odessą czy poprawiając dźwięk i grafikę związane z zestrzeleniem bezpośrednich strzałów przez kanonierkę. Chociaż zmiany te pomogły niektórym graczom zrozumieć działanie wyrzutni, nigdy nie mogliśmy mieć pewności, że wszyscy to załapali. Rozważaliśmy nawet usunięcie tej funkcji, ale bez niej walka z kanonierką jest mniej ciekawa. Naprowadzanie laserowe zmuszało gracza do utrzymywania wroga w zasięgu wzroku podczas lotu rakiety, co oznaczało, że kanonierka również go widziała, a to budowało napięcie, o które nam chodziło."
N/A3957"#commentary\cn_040_performance_constraints.mp3" "[ Eric Smith ] W przypadku ostatniej areny na Wybrzeżu wyobrażaliśmy sobie wielki finał, w którym gracz i oddział obywateli będą walczyć z falami żołnierzy Kombinatu, a kulminacją będzie bitwa z kanonierką. Duża liczba mieszkańców i żołnierzy na mapie wymagała wielu obliczeń, więc musieliśmy ciągle zmniejszać rozmiar starcia, by zmieścić się w naszym budżecie wydajnościowym. Kiedy doszliśmy do punktu, w którym mogliśmy wystawić tylko jeden oddział żołnierzy na raz, byliśmy już spóźnieni z pracami nad grą. Nie było czasu na większe zmiany i zwiększenie liczebności wrogów, dlatego przeprojektowaliśmy przebieg walki, by ograniczyć liczbę żołnierzy do minimum."
N/A3958"#commentary\cn_041_lighthouse_gunship.mp3" "[ Ido Magal ] Scenariusz z kanonierką wymagał sporo pracy, by pasował do naszej wizji – chcieliśmy, aby przebiegał jak w filmie. W wersji filmowej kanonierka strzelałaby przez okna, śladząc bohatera wspinającego się na latarnię morską. Aby zasymulować to śledzenie w grze, ustawiliśmy złożoną serię wyzwalaczy wzdłuż schodów. Gdy wykryją one poruszającego się gracza, nakazują kanonierce wybranie nowej trasy lotu odpowiadającej wysokości, na jakiej znajduje się jej cel. Wyzwalacze aktywują też punkty w oknach najbliższych graczowi – są to niewidoczne obiekty w grze, które sztuczna inteligencja natychmiast postrzega jako wrogie i rozpoczyna ostrzał. To połączenie sztucznej inteligencji i skryptów ma kluczowe znaczenie dla scenariuszy walki w Half-Life. SI zarządza ogólnym, adaptacyjnym zachowaniem postaci niezależnych, a skrypty dostosowują unikalne wymagania każdego scenariusza."
N/A3959"#commentary\cn_042_crane.mp3" "[ Jakob Jungels ] Prawidłowe działanie żurawia wymagało wielu poprawek. Zastosowanie tak dużej siły fizycznej było ryzykowne, biorąc pod uwagę ograniczenia naszej fizyki ciał sztywnych i technologii niszczenia. Na przykład magnes nie był w stanie w pełni spełnić oczekiwań graczy dotyczących obiektu o tak dużej masie. Jednak żuraw był nieruchomy, mogliśmy więc starannie dobrać wszystkie elementy w jego zasięgu i dostosować je wedle potrzeb. Na szczęście większość graczy nie zwróciła uwagi na niedoskonałości, zapewne ze względu na nowość, jaką jest interakcja z czymś takim w realistycznym środowisku fizycznym."
N/A3960"#commentary\cn_043_flashlight_power.mp3" "[ Jeff Lane ] Decyzja, by zarówno sprint, jak i latarka korzystały z zasilania kombinezonu HEV, była dość kontrowersyjna w Half-Life 2. Z początku tylko sprint korzystał z zasilania, co miało sens, bo miał to być krótki zryw. Z drugiej strony, latarka mogła być używana bez końca. Testy ujawniły problem – gracze często nie zauważali, że latarka nadal jest włączona, opuszczając ciemny obszar. W jasnych, otwartych przestrzeniach, takich jak Wybrzeże, nasz budżet wydajnościowy nie pozwalał na ciągłe działanie latarki i musieliśmy ją wyłączać bez udziału gracza. Ograniczenie jej mocy wydawało się prostym rozwiązaniem, które dodatkowo budowało napięcie w ciemności. Pozostało pytanie: jakich zasobów użyć? Mieliśmy zasilanie kombinezonu i nie chcieliśmy zaśmiecać interfejsu nowym zasobem tylko dla latarki. Zastanawialiśmy się nad wykorzystaniem zasilania kombinezonu do innych umiejętności gracza, bo uznaliśmy, że wybieranie pomiędzy nimi byłoby interesujące. To dobry przykład tego, że projektowanie gier często polega na wyborze między niedoskonałymi rozwiązaniami. Nie podobał nam się pomysł z jednym zasobem dla sprintu i latarki, ale nie chcieliśmy też wrzucić zbyt wielu takich elementów do interfejsu. W Epizodzie 2 nie zamierzaliśmy dodawać niczego innego wykorzystującego zasilanie, więc latarka otrzymała własny, oddzielny pasek energii."
N/A3961"#commentary\cn_044_open_world_loot.mp3" "[ Jeff Lane ] Otwartość Wybrzeża wprowadziła nowy problem związany z rozmieszczeniem nagród w postaci przedmiotów. W Half-Life zazwyczaj nagradzamy graczy za eksplorację. Jeśli widzisz drogę naprzód, ale zauważysz coś z boku, prawdopodobnie znajdziesz coś przydatnego, jeśli poświęcisz chwilę na poszukiwania. Kiedy pierwszy raz zaczęliśmy testować mapy Wybrzeża, ukryliśmy nagrody w zakamarkach obszarów zewnętrznych. Jednak przez to wrażenia z jazdy łazikiem stały się gorsze. Na otwartych przestrzeniach zawsze było wiele małych, interesujących miejsc do przeszukania, więc gracze cały czas zatrzymywali pojazd. Stało się to nużące i zakłócało zabawę. Dlatego usunęliśmy te rozrzucone nagrody. Ale pojawił się nowy problem: jak poinformować gracza, kiedy warto wysiąść? Po zastanowieniu ustaliliśmy zasadę: wszelkie ludzkie konstrukcje zawsze zawierają elementy rozgrywki i nagrody dla ciekawskich, zaś obszary czysto naturalne są puste. Nie mogliśmy powiedzieć tego graczom wprost, ale dobrze pasowało to do ich naturalnych domysłów, a my konsekwentnie potwierdzaliśmy te założenia."
N/A3962"#commentary\cn_045_gas_station.mp3" "[ Jeff Lane ] Mieliśmy wielkie plany co do tego starcia. Wyobrażaliśmy sobie stację benzynową, wokół której walczyłby gracz, prawdopodobnie podpalając zbiorniki paliwa i wszystko dookoła, a na koniec wyjeżdżałby przez szalejące płomienie. Jednak budżet i wydajność w 2003 roku mocno nas ograniczały, więc stacja musiała być coraz mniejsza i prostsza, by zmieścić się na otwartych mapach Wybrzeża. Nasz system dynamicznych pożarów ostatecznie nie powstał, a jego stworzenie nie miało uzasadnienia – dla każdego starcia należy ustalić jakiś sensowny nakład pracy. Jedyną pozostałością pierwotnej wizji są wybuchowe zbiorniki."
N/A3963"#commentary\cn_046_buggy_introduction.mp3" "[ John Cook ] Wprowadzenie łazika miało być czymś ciekawszym niż zwyczajne wskoczenie do niego i odjechanie. Pomógł nam w tym żuraw. Gracze przede wszystkim musieli się nauczyć, jak odzyskać przewrócony pojazd, a ta sekwencja ich do tego zmusza. Trening pod presją jest zawsze trudny, ale chcieliśmy podkreślić, że łazika nie należy opuszczać ze względu na mrówkolwy. Dlatego były one stałym zagrożeniem i zapewniliśmy wsparcie kilku obywateli uzbrojonych w karabiny maszynowe. Miłym dodatkiem jest też podniesienie gracza przez żuraw, zanim sam zacznie nim sterować."
N/A3964"#commentary\cn_047_crossbow.mp3" "[ John Cook ] Tu można po raz pierwszy zdobyć kuszę i patrząc z perspektywy czasu nieco zaskakujące jest to, że nie ograniczyliśmy gracza. Może po prostu przejechać obok niej. Aby zmniejszyć to ryzyko, ustawiliśmy blokadę drogi i punkt obserwacyjny, które zachęcą do opuszczenia łazika, a wtedy da się zauważyć kuszę i skrzynię z przedmiotami. Testy wykazały, że prawie każdy gracz zatrzymywał się i zabierał broń, ale jest to przypadek, w którym różnica między testami a rzeczywistą rozgrywką może być znacząca. Tester, który gra od początku Wybrzeża, może nie być tak zmęczony eksploracją jak ktoś, kto gra od samego początku fabuły. Dlatego umieściliśmy kolejną kuszę kilka poziomów dalej, bezpośrednio na ścieżce gracza w Nova Prospekt."
N/A3965"#commentary\cn_048_rollermines.mp3" "[ Josh Weier ] Miny toczące powstały po to, by stanowić zagrożenie dla łazika. Ponieważ gracz w pojeździe jest niemal w pełni fizycznie symulowaną istotą, uznaliśmy, że warto stworzyć wroga korzystającego z tej symulacji fizyki. Siekacz dowiódł, że takie podejście pozwala zaprojektować przeciwnika wchodzącego w ciekawe interakcje ze światem. Tak powstała mina tocząca – kula, której ruch jest całkowicie napędzany przez generowanie momentu obrotowego w niej samej – i doskonaliliśmy jej zachowanie, aż ucieczka przed nią stała się przyjemnością. Miny nie są zbyt niebezpieczne dla łazika, ale w zbyt dużej liczbie stanowią problem, zwłaszcza w pobliżu urwiska. Zadbaliśmy również o to, by działały równie dobrze, gdy gracz porusza się pieszo, co pozwoliło zaprojektować kilka dodatkowych starć."
N/A3966"#commentary\cn_049_sandtrap_thumper.mp3" "[ Laura Dubuk ] Gracze mogą używać wybuchających beczek do walki z mrówkolwami, chroniąc się pod dudnikiem. Jest to również wskazówka przed zbliżającym się spotkaniem ze strażnikiem – gracze często stosują tę samą taktykę, by wygrać walkę. O opcjonalnych metodach, takich jak wystrzeliwanie materiałów wybuchowych działem grawitacyjnym, można zapomnieć, jeśli rzadko się z nich korzysta. Mając do wyboru tak wiele działań gracze czasem nie wykorzystują niektórych z nich. Stąd subtelna sugestia, by ponownie włączyli je do swego arsenału przed walką ze strażnikiem."
N/A3967"#commentary\cn_050_coast_kickoff.mp3" "[ Marc Laidlaw ] Ten przerywnik pojawił się w późnej fazie tworzenia, łącząc Ravenholm z Wybrzeżem. Zauważyliście prawidłowość? Sporo elementów łączących w naszych grach powstaje na późnym etapie. W tym przypadku oznaczało to cięcie kosztów wszędzie, gdzie to możliwe – nie mieliśmy nawet czasu, aby animować Alyx na monitorze. Przyciągnięcie uwagi gracza zawsze jest wyzwaniem, a tu się to nie udało. To dobry przykład wykorzystania postaci w roli drogowskazów, bez nadawania im czy otoczeniu charakteru. Odbiorcy zapominają takie nieskładnie pozszywane sceny. Ale taka jest natura tworzenia gier – masz ograniczony czas i musisz wybrać, na co go poświęcisz. Laboratoria Kleinera i Elia były znacznie ważniejsze, więc to na nich się skupiliśmy."
N/A3968"#commentary\cn_051_odessa_cubbage.mp3" "[ Marc Laidlaw ] Odessa Cubbage to przykład postaci epizodycznej, która dobrze się sprawdza. Jest zabawnym facetem o interesujących cechach, żyjącym we własnej małej bańce. Ponieważ nie opuszcza swojego scenariusza, może być na tyle przerysowany, by się wyróżniać. Zaczęliśmy od jego modelu, który został przerobiony z wyciętej części gry, i nazwaliśmy go na cześć wysłanego do nas mailowego spamu. Model był pierwotnie norweskim rybakiem i nie pasował do Anglika, więc dodaliśmy mu wąsy – i w tym momencie narodziła się postać Odessy. Jest oszustem, wszystko w nim jest fałszywe – jego akcent, wąsy, cała reszta. Nigdy nie wystawiałby się na niebezpieczeństwo, jest więc idealną osobą do przekazania Gordonowi RPG i wyjaśnienia, jak go używać."
N/A3969"#commentary\cn_052_28_transitions_later.mp3" "[ Marc Laidlaw ] Po połączeniu kilku poziomów ciemnymi tunelami zdaliśmy sobie sprawę, że możemy zaskoczyć graczy, tworząc poziom, który wygląda jak taki łącznik, ale zawiera coś innego. Tak jak wszyscy, obejrzeliśmy w 2002 roku „28 dni później” – film bardzo nam się spodobał i stworzyliśmy eskalujące starcie z zombie w jednym z tuneli. Szybko zrealizowaliśmy pomysł i byliśmy zadowoleni z efektu. Lata później poznaliśmy Alexa Garlanda, scenarzystę filmu. Był fanem Half-Life 2, więc wyznaliśmy mu, że to jego dzieło zainspirowało nas do zaprojektowania tej sekcji."
N/A3970"#commentary\cn_053_finest_mind_of_his_generation.mp3" "[ Marc Laidlaw ] To kolejna krótka scena przejściowa, która ostatecznie się sprawdziła. Jedynym wymogiem było nauczenie gracza, by trzymał się z dala od piasku. W poprzednich scenariuszach skupialiśmy się głównie na tym, by były funkcjonalne, ale kiedy doszliśmy tutaj, czuliśmy się bardziej pewnie i zaczęliśmy czerpać przyjemność z wdrażania dodatkowych pomysłów. Dzięki temu postacie były czymś więcej niż tylko drogowskazami, wydawały się interesujące i zabawne. Po premierze Lazlo zyskał wielu fanów, przypominając nam, że trudno przewidzieć, co zapadnie graczom w pamięć."
N/A3971"#commentary\cn_054_bridge_playtesting.mp3" "[ Matt Boone ] Most zawsze był najważniejszym punktem testów, a testerzy niezmiennie reagowali tu bardzo emocjonalnie. Napięcie, jakie odczuwali, powoli przemierzając dźwigary, było widoczne w ich ruchach. Z biegiem czasu dodaliśmy więcej wyzwań, a testy wypadały jeszcze ciekawiej. Od pociągu dudniącego po moście i potrząsającego graczem, po zaskakującego głowokraba w chatce, która wydawała się bezpieczną przystanią w połowie drogi. Czuliśmy się trochę winni, ciesząc się na widok zestresowanych testerów, ale nie torturowaliśmy ich bez końca: po przejściu przez most mogli odetchnąć z ulgą, wyłączali osłonę Kombinatu, a potem zdali sobie sprawę, że muszą wrócić po dolnych dźwigarach. By droga powrotna ich nie znudziła, dodaliśmy kanonierkę, która dotrzymuje im towarzystwa."
N/A3972"#commentary\cn_055_thumper_final_stage.mp3" "[ Matt Boone ] Podobał nam się ostatni etap z dudnikami, gdzie odwracamy ich funkcję. Teraz, zamiast zapewniać bezpieczeństwo, działają jako blokada dla armii mrówkolwów gracza. Ale mogliśmy wcześniej wprowadzić bardziej szczegółowe szkolenie dotyczące tych urządzeń. Chociaż na poprzednich poziomach Wybrzeża gracze mogli tylko częściowo pojąć ich działanie, teraz stawka jest wyższa, ponieważ po raz pierwszy korzystają z przynęty. Ci, którzy nie załapią, że ten pierwszy dudnik uniemożliwia mrówkolwom posuwanie się naprzód, mogą źle zrozumieć działanie przynęty. Jeśli rzucą nią w żołnierzy w pierwszym bunkrze i nie pojawią się żadne mrówkolwy, mogą dojść do wniosku, że przynęta jest zawodna lub nie działa zgodnie z oczekiwaniami i powrócić do używania broni."
N/A3973"#commentary\cn_056_buggy_tools.mp3" "[ Matt Wright ] Łazik był czymś więcej niż tylko środkiem transportu, więc zamontowaliśmy na nim broń. Wybraliśmy działko Tau, fajną broń z Half-Life 1, dla której nie znaleźliśmy miejsca w Half-Life 2. Działko strzela przez ściany, co komplikuje projektowanie poziomów, więc ograniczyliśmy jego użycie do sekcji Wybrzeża. Po wprowadzeniu broni przebijającej ściany projektowanie map staje się znacznie trudniejsze. Co więcej, dodaliśmy skrzynię z amunicją z tyłu łazika, zapewniając nieograniczoną liczbę pocisków do SMG na całym Wybrzeżu. Było to ułatwienie dla testerów mających problem z pokonaniem nieskończonej liczby mrówkolwów wyskakujących z piasku."
N/A3974"#commentary\cn_057_antlion_guard.mp3" "[ Matt Wright ] W rzadkich przypadkach gracze mogą nie być w stanie zabić strażnika na tej arenie, na przykład gdy skończy im się amunicja i niewłaściwie wykorzystają wszystkie dostępne obiekty fizyczne, nie pozostawiając niczego, co da się wystrzelić działem grawitacyjnym. Rozwiązaniem było dodanie obywatela obsługującego wieżyczkę nad bramą – jeśli gracz utknie, może polegać na obywatelu, który zabije strażnika."
N/A3975"#commentary\cn_058_terrain_and_performance.mp3" "[ Mike Dussault ] Nasz budżet wydajnościowy często stanowił poważne ograniczenie dla starć, szczególnie na nierównym terenie. Kiedy postacie się poruszają, wielokrotnie sondują przestrzeń by określić, czy mogą bezpiecznie poruszać się wybraną ścieżką. Aby to lepiej zobrazować, wyobraźcie sobie, że są niewidome i ciągle machają przed sobą laską, by sprawdzić, czy droga jest wolna. Koszt wydajnościowy tych sondowań rośnie wraz ze złożonością geometrii świata. Nasz system rozmieszczania terenu tworzy nierówne powierzchnie z masy wielokątów – jest ich znacznie więcej niż na równych, płaskich podłogach w innych grach. Oznaczało to, że postacie poruszające się po Wybrzeżu zużywały więcej zasobów niż w innych obszarach, a ograniczenie to dyktowało skalę wielu starć w tej części gry."
N/A3976"#commentary\cn_059_area_portals.mp3" "[ Mike Dussault ] Jednym z wyzwań wydajnościowych podczas tworzenia Wybrzeża było ogarnięcie rozległych, otwartych przestrzeni zawierających budynki o bardzo szczegółowych wnętrzach – a przynajmniej szczegółowych jak na standardy z 2003 roku. Kiedy gracz znajdował się na zewnątrz, chcieliśmy przeznaczyć jak najwięcej naszego budżetu na renderowanie tej przestrzeni, nie tracąc zasobów na wnętrza. Jednak nie zamierzaliśmy zabić wszystkich okien i drzwi dechami na amen i gracz nadal mógł zajrzeć do środka. Rozwiązaniem okazały się tak zwane portale obszarowe – umieściliśmy je w każdym otwartym oknie i drzwiach. Portal wstępnie oblicza płaski obraz wnętrza budynku. Gdy gracz znajduje się w pewnej odległości, portal wyświetla ten wstępnie obliczony obraz nad oknem lub drzwiami, co pozwala nam pominąć renderowanie rzeczywistego wnętrza. Gdy gracz się zbliża, płynnie przechodzimy między obrazem z portalu a rzeczywistym wnętrzem. Dzięki ostrożnemu wykorzystaniu portali i drzwi czasem zamykających się za graczem zmieściliśmy się w budżecie wydajnościowym na Wybrzeżu."
N/A3977"#commentary\cn_060_buggy_removal.mp3" "[ Miles Estes ] Kiedy doszliśmy do momentu, w którym należy porzucić łazik, musieliśmy wyraźnie to zaznaczyć. Gracze wielokrotnie zostawiali pojazd na Wybrzeżu, a potem do niego wracali, więc zauważyliśmy, że testujący grę próbowali zabrać go ze sobą, jeśli tylko było to w najmniejszym stopniu możliwe. Ta krótka scena w garażu ma przede wszystkim jasno zasygnalizować, że gracz zakończył jazdę i dalej pójdzie pieszo."
N/A3978"#commentary\cn_061_d2_coast_04.mp3" "[ Randy Lundeen ] Ta mapa to właściwie pierwszy stworzony fragment Wybrzeża, zanim powstał żuraw i inne elementy. Osuszone dno morskie i zardzewiałe statki były jednymi z najwcześniejszych elementów oprawy graficznej, które opracowaliśmy. Wiele lat później zaprezentowaliśmy tę mapę podczas pokazu na E3 w 2003 roku, chociaż wiele elementów rozgrywki było wówczas w fazie planowania. Ostatecznie, kiedy rozpoczęliśmy tworzenie całego Wybrzeża, ten pokaz był dla nas wizją, do której mogliśmy dążyć."
N/A3979"#commentary\cn_062_transition_tunnels.mp3" "[ Randy Lundeen ] Tworzenie Wybrzeża wymagało od nas opracowania metody przejść między poziomami. Aby przejść z jednego do drugiego, musimy zapisać wszystko w przestrzeni przejściowej, gdy gracz opuszcza pierwszy poziom, i przywrócić to w następnym poziomie po załadowaniu. Co ważne, musimy również zapisać i przywrócić wszystko, co widać w obszarze przejściowym, nawet jeśli znajduje się poza nim. Dlatego łączniki były jak najmniejsze i jak najbardziej zamknięte. W większości gier wystarcza małe pomieszczenie. Jednak na Wybrzeżu potrzebowaliśmy innego rozwiązania. Po kilku eksperymentach zdecydowaliśmy się na ciemne tunele. Oprócz tego, że można je ponownie wykorzystać w wiarygodny sposób, pozwoliły nam dodać jasny błysk światła na końcu, maskujący fakt, że nie możemy renderować tego, co znajduje się przed graczem, gdyż istnieje to na zupełnie nowym poziomie."
N/A3980"#commentary\cn_063_sniper_alley.mp3" "[ Robin Walker ] Ta część ścieżki została dodana na późnym etapie, po tym jak laboratorium Elia i Ravenholm znalazły się przed Wybrzeżem. Może się wydawać, że gry powstają w sposób liniowy, tak naprawdę podzieliliśmy się na trzy grupy i pracowaliśmy równolegle nad różnymi sekcjami, zaczynając głównie od środkowej części rozgrywki. Pierwsza faza pracy każdej grupy skupiała się na dopracowaniu podstawowej części sekcji przed przejściem do kolejnej. Gdy mieliśmy już zarys całej gry, wróciliśmy do każdej sekcji, by ją dopieścić, dodać sprawdzone elementy z innych obszarów i usunąć te, które nie działały. W niektórych przypadkach, takich jak Ravenholm, przeniesiono całe sekcje. Dlatego potrzebowaliśmy nowego łącznika z Wybrzeżem, czyli obszarem, do którego właśnie wchodzicie. Ze względu na ograniczenia czasowe ta krótka sekcja została zbudowana z istniejących, sprawdzonych elementów rozgrywki, takich jak snajperzy i żołnierze Kombinatu."
N/A3981"#commentary\cn_064_battery_finding.mp3" "[ Robin Walker ] Wraz ze wzrostem liczebności obiektów w przestrzeni Half-Life 2 uznaliśmy, że gracze mogliby poszukać konkretnego przedmiotu, zwłaszcza jeśli istniała jakaś logika co do tego, gdzie można go znaleźć. Dzięki temu gracze mogliby zlokalizować przedmiot albo poprzez obserwację i dedukcję, albo po prostu rozwalając wszystko wokół. Ponieważ mieliśmy już modele aut i akumulatorów, naturalnym krokiem było stworzenie małego złomowiska. Ukryliśmy również kilka dodatkowych akumulatorów w niespodziewanych miejscach dla tych, którzy wybrali rozwałkę. Tak jak w przypadku innych zagadek z przedmiotami, ta również wymagała zabezpieczeń na wypadek, gdyby gracze zgubili akumulatory. Jeśli chcecie sprawdzić, co się stanie, możecie spróbować wrzucić je wszystkie z klifu."
N/A3982"#commentary\cn_065_boathouse.mp3" "[ Scott Dalton ] W Half-Life 1 odkryliśmy, że scenariusze, w których różni wrogowie walczą między sobą, są doceniane. Gracze czerpią przyjemność z oglądania ich starć, a obserwowanie zachowań przeciwników jest znacznie łatwiejsze, gdy nie jest się ich celem. Pierwsze spotkanie między mrówkolwami i Kombinatem to okazja do staranowania kogoś, ale podkreśla także znaczenie dudnika. Żołnierze używają go do powstrzymywania mrówkolwów i mieliśmy nadzieję, że więcej graczy zrozumie jego przeznaczenie. Żołnierze pokazali zalety pozostawania blisko dudnika podczas walki z mrówkolwami."
N/A3983"#commentary\cn_066_buggy_theft.mp3" "[ Scott Dalton ] Projektując zakończenie Wybrzeża zdecydowaliśmy, że Kombinat ukradnie graczowi łazik. Nie ma to żadnego logicznego sensu, ale po obejrzeniu wielu testów, w gracze bardzo przywiązali się do swoich pojazdów, postanowiliśmy wykorzystać tę emocjonalną więź. Po kradzieży testerzy byli wściekli na Kombinat za kradzież ich wozu, co możemy uznać za sukces. Żołnierz strzelający ze szczytu klifu ma przyciągnąć wzrok gracza, aktywując przy tym pojawienie się transportowca z łazikiem. Oglądając to teraz, 20 lat później, widzimy, że jest to absurdalne."
N/A3984"#commentary\cn_067_snipers.mp3" "[ Ted Backman ] Zespół Half-Life 2 nigdy nie był zbyt duży, więc zawsze szukaliśmy sposobów na tworzenie nowych typów rozgrywki z jednoczesnym ograniczeniem kosztów produkcji. Świetnym przykładem jest snajper. Nie ma rzeczywistego modelu – tylko wiązkę laserową – więc nie wymagał tworzenia grafiki czy animacji. Kiedy ginie, po prostu generuje ragdoll żołnierza i wyrzuca go przez okno. Mimo tej prostoty, uzyskaliśmy wiele unikalnych scen. Byliśmy zadowoleni z tego, jak współgra z obiektami fizycznymi. Gracze są przyzwyczajeni do wykorzystywania wybuchowych przedmiotów w pobliżu wrogów, więc wymyśliliśmy przeciwnika, który odwraca tę dynamikę, gdy gracz próbuje się ukryć."
N/A3985"#commentary\cn_068_buggy_model.mp3" "[ Ted Backman ] Model łazika przeszedł wiele iteracji, zanim powstała ostateczna wersja. Przetestowaliśmy projekty, które spełniały zarówno nasze wymagania artystyczne, jak i fizyczne, ale potem napotkaliśmy nieoczekiwaną przeszkodę: wielu testerów, nawet doświadczonych w strzelankach, miało mdłości podczas jazdy. Oprócz kilku poprawek symulacji odkryliśmy, że pomocna była zmiana modelu łazika – im bardziej model zasłaniał świat, tym mdłości były silniejsze. Zaczęliśmy odejmować części modelu, usuwając coraz więcej elementów karoserii, aż gracze przestali odczuwać nudności. Szczególnie zauważalną różnicę stanowiło podłoże widoczne przez usunięte podwozie."
N/A3986"#commentary\cn_069_antlion_design.mp3" "Ted Backman ] W najwcześniejszych projektach stworzyliśmy plany dla wielu głównych ras obcych, a Kombinat był tylko jedną z nich. Jedną z pozostałych ras była religijna rasa owadopodobnych stworzeń, do której należały mrówkolwy. Później, tworząc Wybrzeże, zaczęliśmy postrzegać je bardziej jako szkodniki, które przedostały się przez portale Xen, podobnie jak głowokraby i inne stworzenia. Chociaż nie pochodzą one z Xen, atakują każdy świat, do którego się przedostają – podobnie jak karaluchy."
N/A3987"#commentary\cn_070_explosive_barrels.mp3" "[ Brian Jacobson ] Tu wprowadzamy wybuchające beczki, będące podstawowym elementem strzelanek, ale z pewną nowością: drugi strzał z pistoletu podpala beczkę, uruchamiając opóźnioną detonację. Trzeci strzał powoduje natychmiastowy wybuch. W ten sposób gracze mogą opóźnić eksplozję lub wywołać ją od razu, zależnie od sytuacji. Mogą też podrzucić beczkę ukwiałowi i strzelić do niej dwa razy, co jest wygodnym sposobem na bezpieczne pozbycie się grupy tych stworzeń. Opóźniona eksplozja sprawiła również, że reakcje łańcuchowe między wieloma beczkami stały się ciekawsze. Wybuchające beczki były ulubionym elementem serii wśród fanów, ale projektanci poziomów też je polubili i uważali, że w grze nigdy nie ma ich za wiele."
N/A3988"#commentary\cn_071_ragdoll_magnets.mp3" "[ Dario Casali ] Fizyka Half-Life 2 dała nam różne narzędzia podnoszące poziom emocji w walce. Na przykład, gdy wrogowie nie trafiają gracza, delikatnie zmieniamy kierunek ich strzałów na pobliskie przedmioty, które można zniszczyć, dodając chaos i tworząc klimat filmu akcji. Wykorzystaliśmy również fizykę do dodania wskazówek. Stworzyliśmy tak zwane „magnesy ragdoll”, by zwłoki spadały w interesujący i dramatyczny sposób — na przykład z krawędzi lub na tory kolejowe."
N/A3989"#commentary\cn_072_helicopter_peekaboo.mp3" "[ Dave Riller ] Śmigłowiec szturmowy Kombinatu jako główny przeciwnik to idea rozwijana przez cały rozdział. Nieustępliwy helikopter stał się postacią samą w sobie. Jeśli wsłuchacie się i spojrzycie w górę, usłyszycie jego silnik i zobaczycie jak leci wzdłuż torów i znika w oddali. To pierwsza mała zapowiedź, a jego obecność staje się coraz bardziej wyraźna z upływem czasu – aż w końcu dochodzi do starcia."
N/A3990"#commentary\cn_073_iterative_passes.mp3" "[ David Speyrer ] Niektóre rozdziały, takie jak sekcje Kanałów i Ravenholm, które gracz pokonuje pieszo, zostały opracowane w kilku etapach przez różne zespoły. Odkryliśmy, że przekazywanie map w ten sposób prowadzi do większej różnorodności wrażeń i większej liczby interesujących momentów, ponieważ każdy zespół dodawał do map swoje unikalne pomysły. W części Kanałów pokonywanych na piechotę, w pierwszym etapie ustalono kierunek artystyczny i ścieżkę gracza oraz ogólny zarys wrażeń i kilka głównych celów. Jednak podczas testów alfa przeprowadzonych przez cały zespół stwierdzono, że brakuje tu napięcia i całość bywa monotonna. W drugim etapie wróciliśmy do mapy, skupiając się na stworzeniu tego napięcia i znacznie zwiększyliśmy zagęszczenie różnych scenariuszy."
N/A3991"#commentary\cn_075_pistol_design.mp3" "[ Josh Weier ] Standardowy pistolet jest podstawowym narzędziem w grze, służącym nie tylko jako pierwsza broń dystansowa, której uczycie się używać, ale także jako sposób interakcji z fizyką i obiektami, które można zniszczyć z bezpiecznej odległości przez całą grę. By zwiększyć responsywność i przyjemność z użytkowania, pistolet wykorzystuje unikalną mechanikę wystrzału. Broń strzela za każdym kliknięciem przycisku, co oznacza, że gracz odczuwa natychmiastową reakcję na swoje działania, a im szybciej klika, tym szybciej strzela."
N/A3992"#commentary\cn_076_shatterglass.mp3" "[ Josh Weier ] Projektując pierwsze poziomy, w których gracz ma do dyspozycji mniej mechanizmów, odkryliśmy, że równie interesujące jest zaprezentowanie nowych osiągnięć technicznych i tak zrobiliśmy w przypadku szkła. Aby uzyskać efekt rozbicia, podzieliliśmy szkło na siatkę małych kwadratów, co pozwoliło nam śledzić, które z nich są nienaruszone, a które rozbite, i wysadzać większe fragmenty, gdy wystarczająca liczba kwadratów traciła ze sobą połączenie. Każdy kwadrat był renderowany z unikalną teksturą opartą na stanie sąsiednich kwadratów, tworząc ostre, postrzępione krawędzie między potłuczonym a całym szkłem. Dziś potłuczone szkło jest powszechnym elementem, ale za czasów Half-Life 2 widywaliśmy je rzadko i byliśmy niezwykle zadowoleni z poziomu wierności i dynamiki, jakie wniosło do gry."
N/A3993"#commentary\cn_077_lambda_caches.mp3" "[ Laura Dubuk ] Właściwie pierwsza skrzynka lambda znajduje się w laboratorium Kleinera, ale to pierwsza skrzynka, którą gracz znajduje samodzielnie. Dodaliśmy skrzynki, by zachęcić graczy do eksploracji i podpowiedzieć im, gdzie mogą znaleźć ukryte zasoby, a zgodnie z fabułą zostały one umieszczone przez Ruch Oporu podczas rebelii. W Half-Life zawartość skrzynek z zasobami była z góry określona przez projektantów poziomów. W HL2 wprowadziliśmy adaptacyjne skrzynie, dające graczowi to, czego w akurat brakuje, w oparciu o cele dotyczące zasobów ustalone przez projektanta poziomu."
N/A3994"#commentary\cn_078_scanners.mp3" "[ Kerry Davis ] Skanery były trudnym wyzwaniem projektowym. Podobało nam się, że ich dystopijna obecność pomagała przedstawić okupację Kombinatu jako opresyjne państwo policyjne, ale nie chcieliśmy, by strzelały do gracza. Uznaliśmy, że celowanie w niebo i strzelanie do małego wroga mającego stale przewagę wysokości jest kiepską rozrywką. Ponieważ podobała nam się ich rola w fabule, zdecydowaliśmy, że podczas walki skanery będą służyć przede wszystkim jako oczy, ostrzegając pobliskich wrogów o obecności gracza — cechę tę wzmocniliśmy efektami dźwiękowymi żołnierzy. Poza tym będą mogą jedynie nękać gracza jasnymi światłami i sporadycznie próbować staranować gracza po otrzymaniu wystarczającej ilości obrażeń."
N/A3995"#commentary\cn_079_surface_properties.mp3" "[ Ariel Diaz ] Odtwarzamy niestandardowe dźwięki kroków, gdy gracz chodzi po śliskim błocie. To system „właściwości powierzchni”, wykorzystujący rodzaj materiału do określenia dźwięków i innych efektów, które powinny wystąpić podczas chodzenia lub strzelania. Na wcześniejszym etapie mieliśmy efekt spowalniający ruch graczy na błotnistych powierzchniach. Usunięto go w ostatecznej wersji gry, ponieważ uznano, że jest zbyt uciążliwy."
N/A3996"#commentary\cn_080_combat_entrances.mp3" "[ Dario Casali ] Wbieganie do nowej lokacji tylko po to, by zobaczyć stojących tam wrogów, zawsze jest niezręczne i sprawia, że świat wydaje się mniej żywy, a bardziej przypomina strzelnicę. Dlatego postanowiliśmy wprowadzić przeciwników do walki w ciekawszy i dynamiczny sposób, który odzwierciedlałby ich planowanie i intencje, tak jakby żołnierze mieli plan wobec Gordona jeszcze zanim ten się pojawił. Metrogliniarze w tej scenie skaczą w dół dzięki zaprogramowanym sekwencjom, a w dalszej części gry używamy podobnej techniki zjazdu na linie. Nie ma znaczenia, skąd naprawdę pochodzą wrogowie, ponieważ gracze sami sobie to wyobrażą. Ostatecznie uznaliśmy, że walka musi mieć jakieś uzasadnienie: zasadzka, niespodzianka, natarcie, atak. Wszystkie te scenariusze wykorzystują w dużej mierze tę samą sztuczną inteligencję wrogów, ale dla testerów były one zupełnie różne."
N/A3997"#commentary\cn_081_mounted_gun_gallery.mp3" "[ Dave Riller ] W tej scenie dzieje się kilka rzeczy: wieżyczka strzelająca do zniszczalnych skrzyń z tyłu uczy graczy, aby nie podejmowali bezpośredniej walki, tylko wykorzystali trasę przez kanały, by pokonać przeszkodę. Docierając do wieżyczki gracze mogą się nią nacieszyć, strzelając do fal Kombinatu i taranujących skanerów. Wprowadzamy również wystrzeliwujący rakiety wóz opancerzony Kombinatu, który popycha graczy do przodu i pojawi się ponownie w dalszej części rozdziału."
N/A3998"#commentary\cn_082_barnacle_bowling.mp3" "[ Josh Weier ] To satysfakcjonujący przykład tego, jak wiele elementów projektu może połączyć się w sieć interakcji, tworząc niezapomnianą scenę. Mamy ukwiały, naszą symulację fizyczną, właściwości śliskiego błota i wreszcie kluczowy obiekt: wybuchające beczki. Wszystkie te elementy znacie osobno, ale razem tworzą one naturalną całość, dając początek scenie, którą nazwaliśmy „kręglami z ukwiałami”."
N/A3999"#commentary\cn_083_barnacle_introduction.mp3" "[ Mike Dussault ] Ukwiały mogą być niezrozumiałe przy pierwszym kontakcie, więc chcieliśmy przedstawić je graczom tak, by mogli obserwować ich zachowanie z bezpiecznej odległości. Zrobiliśmy to jak w programie przyrodniczym, ukazując drapieżnika i ofiarę. Ale, jak zawsze, sceny tego typu wymagały wielu poprawek, by gracze mogli je wyraźnie zobaczyć."
N/A4000"#commentary\cn_084_physics_in_puzzles.mp3" "[ Eric Smith ] Często prostsze mechanizmy spotykane na początku gry są zaczerpnięte z bardziej złożonych w celach szkoleniowych. Zagadka z huśtawką, pierwszym urządzeniem opartym na fizyce, w istocie została zapożyczona z późniejszej, bardziej skomplikowanej zagadki z pralką w Kanałach. Huśtawka wykorzystuje te same zasady masy i pochylni, ale w bardziej bezpośredni sposób, który pozwala graczom na interakcję wprost, pomagając im zrozumieć fizykę gry i ułatwiając rozwiązywanie późniejszych łamigłówek. Zagadka podkreśla również analogowy charakter systemu fizycznego, w którym zarówno rozmieszczenie bloków cementowych, jak i ciężar gracza mają wpływ na rozwiązanie."
N/A4001"#commentary\cn_085_combine_attack_helicopter.mp3" "[ Brian Jacobson ] Gracze mieli już okazję go zobaczyć, ale teraz przedstawiamy głównego bossa Kanałów: śmigłowiec szturmowy Kombinatu. Helikopter bezlitośnie niszczy osłony gracza, wymuszając parcie naprzód pod groźbą śmierci. Chcieliśmy, by ta sekwencja była pełna napięcia i grozy, a helikopter wydawał się zbyt potężny, by stawić mu czoła bezpośrednio, oraz by ta intensywność utrzymywała się przez całe Kanały aż do ostatecznego starcia w zbiorniku wodnym. Aby to osiągnąć, znacznie ograniczyliśmy ruchy helikoptera w oparciu o konkretne cele rozgrywki. Na tej mapie, zaprojektowanej jako bieg od osłony do osłony pod ostrzałem, stworzyliśmy ścieżkę zataczającą koło na niebie nad areną. Śmigłowiec zawsze przemieszcza się do najdalej położonego punktu tego okręgu względem gracza, dzięki czemu pozostaje widoczny i było nam łatwiej umieścić osłony w odpowiednich miejscach."
N/A4002"#commentary\cn_087_explosive_barrel_factory.mp3" "[ David Speyrer ] To pomieszczenie, wypełnione absurdalną liczbą wybuchających beczek, wywołało w zespole dyskusję na temat tego, jak daleko można przesunąć granice realizmu. Szczerze mówiąc, jedna wybuchająca beczka to prawdopodobnie o jedną za dużo, jeśli chodzi o ten realizm – w prawdziwym świecie beczki raczej nie eksplodują, nawet jeśli się do nich strzela."
N/A4003"#commentary\cn_088_rising_water.mp3" "[ Dhabih Eng ] Pływający most i drewniane szpule wprowadzają koncepcję wyporności jako narzędzia dla gracza. W tym przypadku nie jest to tak naprawdę łamigłówka, a jedynie zabawa polegająca na interakcji z fizyką, ale później powracamy do tego pomysłu w Kanałach, gdzie trzeba podnieść rampę dla łodzi."
N/A4004"#commentary\cn_089_manhack_matt.mp3" "[ John Morello ] Nazwaliśmy tego gościa „Siekacz Matt”. Chcieliśmy sprawić wrażenie, że w zakamarkach Miasta 17 mieszkały setki ludzi. W tym momencie gracze już od dawna nie widzieli żadnego mieszkańca, więc chcieliśmy wyjaśnić znaczenie siekaczy, które były pierwszymi stworzonymi przez nas przeciwnikami opartymi na fizyce. W pierwotnej koncepcji w mieście znajdował się salon gier, w którym gracze mogli sterować siekaczami i atakować wirtualnych mieszkańców. W końcu odkrywali, że siekacze są prawdziwe, podobnie jak obywatele. W miarę jak okupacja Kombinatu stawała się coraz bardziej realistyczna, pomysł salonu gier przestał pasować do koncepcji i ostatecznie został porzucony."
N/A4005"#commentary\cn_090_fighting_motion_sickness.mp3" "[ David Speyrer ] We wczesnych testach wielu graczy cierpiało na chorobę lokomocyjną podczas prowadzenia łodzi. Próbując rozwiązać ten problem, odkryliśmy kilka odpowiadających za to czynników. Stwierdziliśmy, że pomocne jest ograniczenie ingerencji łodzi w pole widzenia, więc wprowadziliśmy kilka poprawek do modelu, by ją zmniejszyć. Pomagało również utrzymanie stałej częstotliwości odświeżania, dlatego zadbaliśmy o wydajność w tych sekcjach. Jednak najważniejszym czynnikiem było wyeliminowanie kołysania, by utrzymać stabilną linię horyzontu, niezależnie od zachowania łodzi. Jeden z programistów był bardzo podatny na chorobę lokomocyjną i odważnie zgłosił się do kilkukrotnych testów, aby ocenić nasze postępy w opracowywaniu rozwiązań. Jestem prawie pewien, że zwymiotował przynajmniej raz po testowaniu, ale jego szlachetne poświęcenie zostało bardzo docenione."
N/A4006"#commentary\cn_091_headcrab_canisters.mp3" "[ Jeff Lane ] Zużyte pojemniki z głowokrabami pojawiają się później w Ravenholm, więc chcieliśmy pokazać je tutaj, by dodać do nich historię i wyjaśnić, jak wykorzystuje je Kombinat. Historia opowiada o tym, że Kombinat używa fauny Xen jako broni przeciwko ludziom. Zakopane głowokraby zostały dodane jako nowa funkcja w tej sekcji i rozszerzyliśmy ją na większy obszar, aby pokazać slumsy zniszczone przez ten atak."
N/A4007"#commentary\cn_092_airboat_intro.mp3" "[ John Morello ] W tym miejscu gracz otrzymuje pierwszy pojazd w grze – łódź. Chcieliśmy stworzyć bezpieczną przestrzeń, w której gracze mogą poćwiczyć sterowanie tak długo, jak chcą, nim przejdą dalej. Arena jest pełna okazji do wykonywania skoków i trików, a ponadto wypełniliśmy ją toksycznym szlamem, by gracze pozostawali w łodzi na dłużej, uniemożliwiając im opuszczenie pojazdu i kontynuowanie podróży pieszo."
N/A4008"#commentary\cn_093_zombie_surprise.mp3" "[ Jeff Lane ] W tej rurze kanalizacyjnej znajduje się nieco zuchwały straszak. Gracze wchodzą tu, skupieni i ciekawscy, a wtedy pojawia się podwodny zombie, który prawie zawsze przeraża testerów. Jeden z nich całkowicie spadł z krzesła i uznaliśmy ten moment za sukces."
N/A4009"#commentary\cn_094_airboat_time.mp3" "[ Dave Riller ] Znalezienie równowagi między czasem spędzonym w pojeździe a podróżą na piechotę wymagało trochę pracy. Jazda z pełną prędkością pozwalała szybko się przemieszczać, ale podczas wczesnych testów zauważyliśmy, że gracze tracili okazję do eksploracji i podziwiania detali. Badanie i zrozumienie świata to podstawowe wartości Half-Life, więc nie chcieliśmy, aby pojazd je wyeliminował. Dodaliśmy więc rozrzucone przystanki, w których można wysiąść i zbadać niewielkie obszary pełne szczegółów. Dodatkowo, wraz z rozwojem systemu fizyki, uczyliśmy graczy nowych sposobów jego wykorzystania. Te postoje poza łodzią pozwoliły nam wprowadzić element odkrywania fizyki, na przykład poprzez zrzucanie skrzyń do wody lub łączenie beczek, by podnieść rampę. Dało to możliwość interakcji z wodą i fizyką na różne sposoby."
N/A4010"#commentary\cn_095_floating_supplies.mp3" "[ Josh Weier ] W testach alfa Kanały były usiane pływającymi skrzyniami z zapasami, które gracze mogli rozbijać łodzią, by zebrać znajdujące się w nich przedmioty. Mechanika była nieco nierealistyczna, ale pomagała utrzymać płynność rozgrywki, umożliwiając graczom uzupełnianie zapasów. By dodać tej koncepcji wiarygodności, dodaliśmy historię wyjaśniającą, jak skrzynie znalazły się w tak dogodnym miejscu na trasie gracza. Scena, w której mieszkańcy zrzucają skrzynie, pomaga sprzedać tę fikcję, a jednocześnie sprawia, że kanały wydają się bardziej żywe. Poza tym, gracze poczuli się bardziej heroiczni i ważni, otrzymując pomoc od tak wielu postaci drugoplanowych."
N/A4011"#commentary\cn_096_grenade_intro.mp3" "[ Brian Jacobson ] Ta baza Kombinatu została zaprojektowana jako trening i plac zabaw dla granatów, dostępnych w nieskończonej liczbie w skrzyniach, by gracze mogli się nimi swobodnie posługiwać bez obawy, że się skończą. Niech się wyżyją. Walka wykorzystuje rozbudowane oznaczenia, kierujące sztuczną inteligencję żołnierzy w stronę osłon i daje graczom dobrą okazję do użycia granatów. Na końcu obszaru ten sam pomysł na nieskończone granaty pomaga graczom pozbyć się wieżyczek, ponieważ bezpośredni szturm jest znacznie trudniejszy. Do granatów dodano jasnoczerwone światło i ślad cząsteczkowy, co znacznie ułatwia śledzenie ich trajektorii, niezależnie od tego, czy się je rzuca, czy też próbuje się uniknąć tych rzuconych przez żołnierzy."
N/A4012"#commentary\cn_097_puzzle_layers.mp3" "[ Dave Riller ] Ponieważ gracze często nie są świadomi intencji projektanta, co jest akurat zaletą, reagują na nasze zagadki w zaskakujący sposób. Nawet pozornie proste łamigłówki mogą wymagać wielu prób, nim osiągnie się sukces. Tak było z zagadką dotyczącą otwarcia śluzy – wymagała wielu wskazówek i podpowiedzi. Iskrzące koło sugeruje, że w tym miejscu zwykle otwiera się śluzę, ale potrzebna jest inna metoda. Kilka kruków kieruje uwagę gracza na rozwiązanie – w tym przypadku na wiązkę dźwigarów na wahadle. Ponieważ granaty zostały już odpowiednio wprowadzone, początkowo chcieliśmy, by gracze rzucili jednym z nich, by zniszczyć drewnianą konstrukcję nośną, ale nie było to dość oczywiste. Dodaliśmy eksplodujące beczki jako wyraźniejszą wskazówkę. Jednak nawet po rozwiązaniu zagadki niektórzy testerzy nie zdawali sobie sprawy, że brama jest już otwarta, przez co stale zaglądali do wnętrza bazy w poszukiwaniu innego wyjścia. Musieliśmy więc przypomnieć im o pierwotnym problemie, czyli zepsutej bramie. Dodaliśmy dym, syrenę alarmową oraz migające światło i dopiero wtedy zauważyliśmy zadowalające wyniki w testach."
N/A4013"#commentary\cn_098_metrocop_strafing.mp3" "[ Doug Wood ] Pierwotny projekt poziomów z łodzią miał rzucić graczom wyzwania w postaci trudnych manewrów pod ostrzałem metrogliniarzy. Schemat ostrzału sprawiał, że gracze musieli lawirować między pociskami, pędząc naprzód. Jednak podczas wewnętrznego procesu oceny, zwanego „Nadzorem”, niektórzy testerzy czuli frustrację, ponieważ byli ostrzeliwani i nie mogli się odgryźć. Woleli, by łódź była potężna i nie do zatrzymania. Na podstawie tych opinii zmieniliśmy poziom trudności, kładąc większy nacisk na poczucie mocy niż na wyzwania, przechodząc od unikania ataków do szybkiej walki, prędkości i przełamywania blokad."
N/A4014"#commentary\cn_100_mounted_gun.mp3" "[ Jeff Lane ] Dodaliśmy tu karabiny maszynowe, by zaprezentować graczowi skuteczność broni przeciwko śmigłowcowi szturmowemu podczas ostatecznej bitwy w zbiorniku wodnym. Było to konieczne, ponieważ dotąd helikopter był niewrażliwy na ataki gracza i musieliśmy wyraźnie zaznaczyć, że można go zniszczyć za pomocą cięższej broni. Było to tylko częściowo czytelne podczas testów ze względu na presję, pod jaką znajdował się odbiorca w tym momencie, dlatego opracowaliśmy efekty cząsteczkowe i dźwięki, które przekonały graczy, że naprawdę zadają obrażenia."
N/A4015"#commentary\cn_101_357_intro.mp3" "[ Josh Weier ] Z Magnum, o mniejszej szybkostrzelności niż podstawowy pistolet, korzysta się w sposób bardziej wyważony i przemyślany, zadając celowi ogromne obrażenia. Wcześniejsze wersje Magnum miały pewien losowy rozrzut, co naszym zdaniem pasowało do ciężaru i mniej czułego spustu dużego rewolweru. Prowadziło to jednak do rozczarowujących sytuacji, w których gracze starannie mierzyli do wroga, ale chybiali ze względu na niższą celność. Dlatego sprawiliśmy, że pierwszy pocisk trafia idealnie w środek celownika, a po każdym kolejnym wystrzale celność coraz bardziej spada."
N/A4016"#commentary\cn_102_helicopter_bombing_run.mp3" "[ Brian Jacobson ] To kolejny przykład projektowania zagrożeń dla poruszającej się łodzi. Helikopter próbuje pozostać przed graczem zrzucając bomby, a jeśli gracz zawraca, zawisa w powietrzu i zwraca się w stronę uciekającego, by go zaatakować. Podczas jednego z testów bomba przypadkowo spadła między miejsce łączenia rur, tworząc dość filmowy moment. Tester zareagował pozytywnie, więc zespół zaprogramował to zdarzenie tak, by dochodziło do niego za każdym razem. Proces ten stał się częścią naszego organicznego projektowania: co jakiś czas podczas testów losowo zdarza się coś fajnego i znajdujemy sposób, by zdarzało się to częściej."
N/A4017"#commentary\cn_103_smokestack_collapse.mp3" "[ Doug Wood ] Projektując kinową grę akcji, jaką jest Half-Life 1, chcieliśmy stworzyć kilka ogromnych, spektakularnych sekwencji zniszczenia, ale nigdy nie byliśmy w stanie tego zrobić. Fizyka Half-Life 2 wprowadziła system rozwalania małych obiektów, takich jak skrzynie, co pchnęło nas do opracowania czegoś znacznie większego. Zaryzykowaliśmy i spróbowaliśmy rozbić upadający komin na kawałki. Eksperymentowaliśmy z masami, aż efekt był zadowalający, udoskonaliliśmy model i dodaliśmy dużo dymu oraz dźwięków, by wzmocnić efekt. I tak uzyskaliśmy naszą ogromną, spektakularną scenę zniszczenia. Nasz system fizyki sprawił, że sekwencję ledwo udało się zrealizować i to w sposób, który według obecnych standardów może wydawać się nieco nietypowy, ale w tamtym czasie robiło to wrażenie. Ponieważ symulacja była unikalna za każdym razem, gdy ją uruchamialiśmy, musieliśmy zadbać o to, by drogi gracza nie zablokowały zwały gruzu. Udana scena zaostrzyła nasz apetyt na bardziej realistyczne, filmowe zniszczenia, które pojawiły się w Epizodzie 2."
N/A4018"#commentary\cn_104_washing_machine_puzzle.mp3" "[ David Speyrer ] Zagadkę z pralką stworzyliśmy pod koniec prac, po tym jak testy wykazały, że gracze potrzebują chwili wytchnienia po nieustającym pościgu helikoptera. Takie zmiany tempa mogą podkreślić najważniejsze momenty, resetując stan emocjonalny gracza i zapobiegając zmęczeniu, a nawet nudzie. Fakt, że gracze tak mocno zareagowali na wszystkie pomysły, które sprawiły, że helikopter był naprawdę groźny, to dobry znak, ale gdybyśmy nieodpowiednio zarządzali stresem, pojawiałoby się zmęczenie, które szybko zmieniłoby się w monotonię, a nie ekscytację. Pierwotnie gracze szybko przejeżdżali przez ten obszar, ale ze względu na ładne światło słoneczne i kompozycję kanału w tym miejscu, uznaliśmy, że jest to dobry postój, gdzie akcja staje, a gracz może odpocząć w ciszy, rozwiązując zagadkę. Sama łamigłówka, w której po raz pierwszy wykorzystano masy i bloczki, zainspirowała inne zagadki fizyczne związane z nawigacją w innych fragmentach gry."
N/A4019"#commentary\cn_105_airboat_changeup.mp3" "[ Jeff Lane ] Testerzy przekazali nam, że oczekują bardziej zróżnicowanej rozgrywki z wykorzystaniem łodzi. Do tego momentu gracz nie miał żadnej realnej możliwości walki z helikopterem i innymi przeciwnikami, więc wprowadzenie nowej broni wydawało się słusznym posunięciem, które pozwoliło zmienić tempo gry i przygotować grunt pod dalszy rozwój akcji. W kolejnych obszarach dodaliśmy strzelanie do celów, aby gracze mogli zapoznać się z nową bronią. Dodatkowa siła fizyczna pocisków z działka na łodzi wyrzucała wrogów w powietrze, sugerując, że broń jest potężniejsza od całej reszty arsenału gracza. Mimo to, podczas testowania walki ze śmigłowcem, wielu testerów nadal uważało, że jest niepokonany. Nie zauważyli naszych podpowiedzi wskazujących, że helikopter odnosił obrażenia od działka Kombinatu. Aby to zmienić, zrobiliśmy coś oczywistego: umieściliśmy śmigłowiec bezpośrednio przed tunelem, w którym gracz otrzymuje broń i jasno zaznaczyliśmy, że można, a wręcz należy do niego strzelać. I to zadziałało."
N/A4020"#commentary\cn_106_donkey_kong_barrel_ramp.mp3" "[ Eric Smith ] Ten konkretny obszar – rampy odprowadzające wodę – początkowo były tylko ciekawą częścią architektury poziomu. Jednak podczas testów szybko zauważyliśmy, jak fajnie zjeżdża się łodzią po zboczu, więc dodaliśmy więcej elementów, aby wzbogacić to doświadczenie, w tym między innymi metrogliniarzy zrzucających beczki na gracza, co było nawiązaniem do klasycznej zręcznościówki Donkey Kong."
N/A4021"#commentary\cn_107_lambda_cache_interlude.mp3" "[ Danika Rogers ] Half-Life jest ostatecznie liniowym doświadczeniem, ale zawsze szukamy sposobów na urozmaicenie ścieżki gracza i stworzenie nieliniowości na danym poziomie. Ta skrzynka lambda, zastąpiona zasadzką zombie i głowokrabów, była całkowicie opcjonalna i powstała wyłącznie po to, by nieco urozmaicić podróż przez kanały."
N/A4022"#commentary\cn_108_skybox_time_of_day.mp3" "[ Eric Kirchmer ] Kolor nieba i mgły zmienia się stopniowo w trakcie tego rozdziału. Jest to wizualne przedstawienie upływającego czasu, gdy gracz przemierza kanały i sam rozdział. Dwie wartości koloru mgły w przeciwnych kierunkach pomagają stworzyć iluzję ukośnego kąta padania promieni słonecznych. Widać, że zbliża się zachód słońca. Kulminacyjnym punktem jest walka z helikopterem na arenie, gdzie słońce zachodzi, a w oddali widać Ravenholm."
N/A4023"#commentary\cn_109_helicopter_megabomb_origin.mp3" "[ Brian Jacobson ] Megabombowy atak helikoptera wziął się z błędu programisty, który przypadkowo usunął przerwy między bombami, przez co śmigłowiec zrzucił ich setki równocześnie. Wyglądało to tak fajnie, że postanowiliśmy zachować tę koncepcję w ostatniej wersji bombardowania."
N/A4024"#commentary\cn_110_helicopter_final_battle.mp3" "[ Dave Riller ] Zaprojektowaliśmy ten obszar jako arenę ostatecznej rozgrywki ze śmigłowcem szturmowym Kombinatu. Gracz wreszcie ma szansę wyeliminować nieustępliwego wroga, który ścigał go od momentu ucieczki z podziemi po opuszczeniu laboratorium Kleinera. Obszar przeszedł wiele iteracji, nim efekt był odpowiedni. Potrzebowaliśmy dużej przestrzeni do szybkiej walki pojazdów, płynnego ruchu z wyraźnymi wyborami trasy i niezawodnej wydajności. Chcieliśmy też, by grafika była przejrzysta i pasowała do walki – miała być efektowna, ale nie rozpraszająca – a jednocześnie by po zniszczeniu helikoptera widok zapadał w pamięć."
N/A4025"#commentary\cn_111_airboat_wreckage.mp3" "[ David Speyrer ] Pierwotnie niszczyliśmy łódź podczas skoku przez tamę, więc poziom rozpoczynał się od gracza pływającego wśród szczątków ukochanego pojazdu. Podczas testów przeprowadzonych przez cały zespół gracze byli rozczarowani utratą środka lokomocji, w którym spędzili mnóstwo czasu. Wielokrotnie dyskutowaliśmy o tym, czy to poczucie straty było cennym doświadczeniem, czy nie. Ostatecznie zdecydowaliśmy się pozostawić łódź w całości, by nie wykluczyć ponownego spotkania z nią w przyszłości. Niektórzy twierdzą, że ona nadal tam jest i czeka na was."
N/A4026"#commentary\cn_112_arena_exit_gate.mp3" "[ Quintin Doroquez ] Mechanizm koła służący do podnoszenia śluzy został dodany specjalnie po to, by zmusić gracza do pokonania helikoptera, zanim będzie mógł ruszyć dalej. Często nazywamy takie elementy „zamykaniem bramy” przed graczem – wstawiamy elementy blokujące mu drogę, dopóki nie wykona konkretnego zadania. W tym przypadku jest to dosłownie brama."
N/A4027"#commentary\cn_113_blocking_tutorials.mp3" "[ Adrian Finol ] Czasami musimy się upewnić, że gracz się czegoś nauczył, a standardową metodą – przynajmniej w tworzeniu gier, nie w życiu – jest zamknięcie go za jakąś bramą, gdzie musi wykazać się swoją wiedzą, by przejść dalej. Staramy się przedstawić te bramy jako coś naturalnego, by nie sprawiać wrażenia, że wstrzymujemy grę. Oczywiście czas, zasoby lub sam kontekst środowiskowy mogą utrudniać to zadanie. Tutaj musieliśmy nauczyć graczy, jak przenosić obiekty, więc prosta łamigłówka polegająca na układaniu przedmiotów wydawała się najlepszym rozwiązaniem. Przetestowaliśmy bardziej złożone projekty, ale okazały się mniej skuteczne w nauczaniu tego, czego faktycznie oczekiwaliśmy od graczy."
N/A4028"#commentary\cn_114_natural_storytelling.mp3" "[ Bill Van Buren ] By osiągnąć cele związane z budowaniem świata i opowiadaniem historii na Dworcu, szukaliśmy naturalnego sposobu na przedstawienie dialogów, by całość nie wypadła sztucznie i nie wymagała samouczków. Zauważyliśmy, że gracze często podchodzili do postaci, by przyjrzeć się im z bliska, więc wykorzystaliśmy to, by owe postacie zwróciły uwagę na gracza i wypowiedziały swoje kwestie. Dzięki temu interakcje były niewymuszone, a to istotne, ponieważ obywatele nie są zbyt radośni ani żywiołowi. Ta prostota była również zgodna z jednym z głównych celów fabularnych Half-Life: dostosowaniem narracji do zainteresowań odbiorcy. Niektórzy chcą zagłębić się w każdy szczegół, zaś inni chcą po prostu wiedzieć, co robić dalej. Danie graczom kontroli nad zaangażowaniem się w fabułę, bez blokowania postępów, jest celem, który zawsze staramy się realizować w Half-Life. Poza tym, im mniej skomplikowana jest dana funkcja, tym więcej jej założeń możemy wprowadzić."
N/A4029"#commentary\cn_115_trainstation.mp3" "[ Charlie Brown ] Początek Half-Life ma spełnić ważne zadanie: wprowadzamy graczy w nowy świat, jednocześnie ucząc ich, jak wchodzić z nim w interakcję. Muszą szybko zrozumieć, co się dzieje, kim są kluczowe postacie, z jakimi zagrożeniami będą się mierzyć i jak się w to wszystko wpisują. I najważniejsze – rozgrywka musi być przyjemna i jak najbardziej interaktywna. Spełnienie tych warunków wymaga wielu iteracji i testów, zwłaszcza w przypadku drobnych elementów składających się na ogólny obraz gry. W tej sekcji omówimy kilka kluczowych momentów, problemy związane z projektowaniem oraz testy, podczas których nie wszystko poszło zgodnie z planem."
N/A4030"#commentary\cn_116_physics_objects.mp3" "[ David Sawyer ] Teraz mało kto o tym pamięta, ale w czasie premiery Half-Life 2 małe obiekty w grach, takie jak te śmieci, były zazwyczaj statyczne – albo się nie ruszały, albo ich ruch był bardzo prosty. Jeśli gracz miał szczęście, po uderzeniu mogły one rozpaść się na kilka sprite'ów. Jednym z celów tej początkowej sekcji Dworca było wyraźne pokazanie, że tego typu rzeczy są w Half-Life 2 odpowiednio symulowane fizycznie. Można je podnosić, upuszczać, rzucać, psuć, przemieszczać za pomocą innych sił – robić co tylko przyjdzie wam do głowy. Zaczynamy od drobnej rzeczy, pokazując, że śmieci są rozrzucane przez nadjeżdżający pociąg – a dokładniej przez niewidzialną masę, która jest aktywowana przez wychodzącego gracza."
N/A4031"#commentary\cn_117_blocking_tutorials_3.mp3" "[ Eric Smith ] Drugą porażką w tym samouczku jest błędne szkolenie — przypadkowo uczymy gracza czegoś, czego nie zamierzaliśmy. Trudno tego uniknąć bez szeroko zakrojonych testów, ponieważ gra zawsze czegoś uczy, nawet jeśli nie jest to zamierzone. Bardziej ekstremalny przykład tego zjawiska omówimy później, przy okazji Dworca. Niektóre przypadki błędnego szkolenia wymagają natychmiastowej poprawki, na przykład gdy gracz nauczy się niewłaściwie używać broni lub interakcji z powszechnym elementem gry. Ten przypadek był bardziej subtelny. Ucząc przenoszenia przedmiotów, nauczyliśmy graczy również układania obiektów fizycznych w stosy, by uciec z danej przestrzeni. Zwykle nie ma w tym nic złego, ale później wykorzystujemy tej zagadki, a nauczanie czegoś nieistotnego zaśmieca umysł i utrudnia zapamiętanie przydatnych informacji na później. Co gorsza, układanie obiektów w celu ucieczki stało się problemem, z którym musieliśmy sobie radzić w wielu lokacjach. Przy tak dużej liczbie przedmiotów opartych na fizyce, powstrzymanie tego zachowania bez umieszczania wszędzie sufitów nie było realną opcją. Liczyliśmy, że gracze nie będą zbytnio zastanawiać się nad tą wczesną lekcją, a kiedy testy wykazały, że utknęli w dalszej części, nie zamierzaliśmy im o tym przypominać."
N/A4032"#commentary\cn_118_welcome.mp3" "[ Gabe Newell ] Tu Gabe Newell, witam ponownie w Half-Life 2. Od premiery minęło już dwadzieścia lat. W tej rocznicowej aktualizacji staraliśmy się uwzględnić jak najwięcej próśb społeczności. Być może nie jest to absolutnie najważniejsze oczekiwanie fanów, ale często pojawiały się prośby o tryb komentarzy, więc cieszymy się, że w końcu udało nam się zrealizować ten pomysł. Mieliśmy problem nie tylko z przypomnieniem sobie wielu szczegółów dotyczących tworzenia Half-Life 2 – musieliśmy też przejrzeć stary kod gry i zastanawiać się, co nam wtedy strzeliło do głowy. Oprócz dodania komentarzy twórców usunęliśmy sporo starych błędów i staraliśmy się zostawić wszystko w lepszym stanie. Teraz przynajmniej wiemy, jak to wszystko się ostatecznie potoczyło. Aby odsłuchać komentarz, ustawcie celownik nad pływającym symbolem komentarza i naciśnijcie przycisk „Użyj”. Aby zatrzymać komentarz, ustawcie celownik nad obracającym się symbolem i ponownie naciśnijcie „Użyj”. Dajcie znać, co o tym myślicie. Można się ze mną skontaktować pod adresem gaben@valvesoftware.com. Dzięki i dobrej zabawy!"
N/A4033"#commentary\cn_119_metrocop_shoving_citizens.mp3" "[ Josh Weier ] Przeszliśmy ledwie kilka metrów, a już mamy problem do rozwiązania. Przedstawiamy metrogliniarza – wroga, którego gracze będą musieli ostatecznie zabić – i dajemy wam wgląd w świat, do którego wkraczacie. Jest to prosta, jasna scena, która pokazuje relacje między gliniarzami a obywatelami, a co za tym idzie – z graczami. Przy okazji postanowiliśmy wyraźnie zaznaczyć obecność podstawowej symulacji fizycznej, pokazując, w jaki sposób postacie mogą swobodnie wchodzić w interakcje z obiektami w grze. Widok walizki uderzającej w inną i przewracającej ją był wówczas zupełną nowością. Te momenty na Dworcu, w których połączyliśmy wiele celów, okazały się najbardziej udane – wydawały się naturalne, jakby gra nie zatrzymywała się tylko po to, aby dać graczowi lekcję."
N/A4034"#commentary\cn_120_fall_damage.mp3" "[ Kerry Davis ] Nauczanie graczy, jak wykonywać różne czynności, jest niezbędnym elementem gry. Jednak aby mogli podjąć pewne decyzje, muszą również zrozumieć bardziej subtelne zasady. Ta krótka scena obejmuje dwie z nich: po pierwsze, pokazuje, z jakiej wysokości można spaść, nie odnosząc obrażeń. Po drugie, wprowadza nieco „słownictwa” gry – wskazuje, jak będzie wyglądać komunikacja z odbiorcą. Gracze często martwią się upadkami z wysokości, ale boją się również zrobić coś, czego nie można cofnąć, więc skrzynia, na której można wylądować, sygnalizuje, że spadanie jest bezpieczne i jest to droga naprzód. A kiedy skrzynia się rozpada, przypomina o symulacji fizyki i jest to prawdopodobnie pierwszy raz, kiedy gracze zobaczą, że większe obiekty można zniszczyć."
N/A4035"#commentary\cn_121_sweeping_vortigaunt.mp3" "[ Laura Dubuk ] Kolejny kluczowy moment fabuły i następne nawiązanie do fizyki: pokazujemy, jak Wortygonty wpisują się w ten nowy świat, zmieniając całkiem ich rolę z Half-Life 1, gdzie byli wrogami. Podobnie jak wiele innych momentów na Dworcu, zamiatający Wortygont to efekt ciągłych poszukiwań sposobów na ukazanie postaci naturalnie współgrających z systemem fizyki. Po co mówić wprost, że Wortygonty są teraz przyjazne, skoro można pokazać jednego z nich, spokojnie zamiatającego podłogę i przewracającego przedmioty? Nic nie wskazuje pokojowych zamiarów lepiej, niż chęć do sprzątania bałaganu."
N/A4036"#commentary\cn_122_blocking_tutorials_2.mp3" "[ Robin Walker ] W tym samouczku występują dwa istotne błędy. Po pierwsze, gracze mogą zepsuć grę, wyrzucając wszystkie skrzynie przez okno, a wtedy utkną i nie będą mogli iść dalej, co uważamy za problem uniemożliwiający dalszą rozgrywkę i wymagający naprawy. Dobrym rozwiązaniem byłoby dostosowanie rozmiarów okna lub skrzyń tak, aby gracz mógł przejść przez otwór, ale skrzynie nie. Problem w tym, że zauważyliśmy to dopiero na późnym etapie tworzenia, a nawet tak prosta zmiana może mieć nieprzewidywalne konsekwencje i zepsuć grę, i to tuż przed premierą. Poza tym, problem był czysto teoretyczny. Nigdy nie widzieliśmy, aby testerzy to robili. Nasze testy tej przestrzeni przebiegały sprawnie, gracze uczyli się tego, czego potrzebowali i przechodzili dalej. Zmiana projektu pomieszczenia na tak późnym etapie mogłaby zepsuć udany pomysł w nieprzewidywalny sposób. Wybraliśmy więc bardziej zachowawcze rozwiązanie zamiast eleganckiego. Jeśli jesteście ciekawi, spróbujcie wyrzucić wszystkie skrzynie przez okno i sprawdźcie, co się stanie."
N/A4037"#commentary\cn_123_playground.mp3" "[ Brian Jacobson ] Zastanawiając się nad metodami podkreślenia naszej symulacji fizycznej w mieście, uznaliśmy plac zabaw za oczywisty wybór. A dla graczy słuchających uważnie doktora Breena jest to również zobrazowanie ceny, jaką ludzkość zapłaciła za poddanie się Kombinatowi. Wybraliśmy kilka elementów placu zabaw o interesującym potencjale fizycznym i zaczęliśmy je dostosowywać. Nawet przy zaawansowanej symulacji fizyki, jaką wówczas dysponowaliśmy, takie sceny zawsze wymagały ręcznych poprawek, ponieważ symulowaliśmy obiekty z pełną fizyką oddziałujące na elementy jej pozbawione lub symulowane tylko częściowo, takie jak gracz lub statyczna geometria. Łatwo założyć, że zaprogramowana symulacja może wziąć na siebie większą część implementacji rozgrywki, ale nawet dziś, 20 lat później, rzadko tak jest. Kiedy pracowaliśmy nad placem zabaw, pod koniec tworzenia gry, nie mogliśmy uzyskać odpowiedniego oporu na zjeżdżalni, więc postanowiliśmy zepsuć drabinkę, by zablokować przejście na górę. Jednak nadal można po prostu wejść przodem. Jak zwykle, gracz ma ostatnie słowo."
N/A4038"#commentary\cn_124_pick_up_that_can.mp3" "[ Charlie Brown ] Nadanie kontekstu samouczkom, czyli tworzenie scenariusza, w którym się one pojawiają, pozwala nam na coś więcej niż zatrzymanie gry, aby nauczyć graczy czegoś nowego. Możemy dodać wartość narracyjną. W tym przypadku nauczanie gracza rzucania przedmiotami jest połączone z fabularnym scenariuszem, pozwalającym na wybór reakcji. Po pokazaniu metrogliniarzy bez skrupułów znęcających się nad obywatelami, postawienie gracza w podobnej sytuacji wydawało się słuszne. Jeśli miał opinię na temat tego, jak powinni zareagować obywatele, mógł ją wyrazić. Testy wykazały, że większość graczy albo zgodziła się, albo odmówiła podniesienia puszki, ale niektórzy próbowali całkowicie uniknąć konfrontacji. Inni początkowo zgadzali się, a potem mścili za upokorzenie. Dzięki utrzymaniu tej sytuacji w ograniczonych ramach, zarówno działań gracza, jak i samej przestrzeni, mogliśmy odpowiednio zareagować na każdy z tych wyborów."
N/A4039"#commentary\cn_125_promises.mp3" "[ Danika Rogers ] Na początku Half-Life jednym z naszych celów jest złożenie graczowi obietnic, które wskażą mu, czego może się spodziewać w dalszej części gry. Wszystkie dobre media rozrywkowe, od filmów, przez seriale, po książki, w jakiś sposób to robią, a gry nie są tu wyjątkiem. Obietnice w Half-Life mogą przybierać różne formy. Niektóre są proste, na przykład pokazując fragment czegoś intrygującego. Inne są bardziej złożone, jak interakcje z metrogliniarzami. Stawiając przeciw nim bezsilnego gracza przygotowujemy grunt pod nadchodzącą chwilę, w której w końcu będzie mógł się zemścić."
N/A4040"#commentary\cn_126_exploration.mp3" "[ David Sawyer ] Po tym, jak metrogliniarze przeganiają graczy przez dworzec, chcieliśmy dać chwilę na eksplorację. Ten plac oferował kilka wzajemnych oddziaływań z obywatelami, gliniarzami, skanerami i infrastrukturą. Chcieliśmy, aby interakcje dawały wgląd w świat bez oczywistych samouczków, więc dopracowywaliśmy je, aż zaczęły działać naturalnie i żadne szkolenie nie było potrzebne."
N/A4041"#commentary\cn_127_early_game_exploration.mp3" "[ David Speyrer ] Do tego momentu gracz nie musiał zbytnio zastanawiać się nad wyborem ścieżki, gdyż była jasna i prosta. Jednak w tym miejscu chcieliśmy zachęcić do eksploracji, więc droga stała się mniej oczywista, co mogło wywołać uczucie zagubienia lub, co gorsza, dezorientacji. Takie zmiany mogą być trudne, zwłaszcza na początku gry, kiedy odbiorca wciąż uczy się mechaniki wskazówek. Tutaj sytuację dodatkowo komplikują punkty kontrolne z polem siłowym, które pozwalają na przejście postaciom niezależnym, ale ograniczają gracza, przez co wielu testerów sądziło, że da się je jakoś ominąć. Ostatecznie to właśnie dzięki szczegółowym testom udało nam się uczynić alejkę naprzeciw bardziej widoczną, wykorzystując oświetlenie, układ i drewnianą skrzynię – przedmiot, który gracze wykorzystali już jako znak, że zmierzają we właściwym kierunku – wszystko po to, aby subtelnie poprowadzić ich do przodu."
N/A4042"#commentary\cn_128_strider.mp3" "[ Doug Wood ] Ta prosta chwila to zapowiedź tego, że w dalszej części gry gracz spotka się z czymś naprawdę ogromnym. Nawet tak nieskomplikowana scena jak ta wymaga wielu testów i poprawek, ponieważ założeniem Half-Life jest pozostawienie kontroli w rękach odbiorcy. Zapewne się domyślacie, że potrzeba wielu drobnych poprawek, aby jak najwięcej graczy patrzyło w odpowiednim momencie we właściwe miejsce. Układ ulic i scena z metrogliniarzem mają na celu skierowanie uwagi, idealnie kadrując stępacza, gdy się pojawia."
N/A4043"#commentary\cn_129_physics_simulation.mp3" "[ Jay Stelly ] Mimo że rozpoczęliśmy pracę nad Half-Life 2 od funkcjonalnej symulacji fizyki opracowanej przez zewnętrzną firmę, potrzebowaliśmy jeszcze wielu lat dodatkowej pracy zarówno nad samą symulacją, jak i jej integracją z grą, zanim uznaliśmy, że możemy spełnić ambicje projektantów. Utrzymanie odpowiedniego poziomu jakości i wydajności było wyzwaniem, ale bardziej subtelną kwestią było ustalenie, co i w jakim zakresie należy symulować. Nie możemy zrobić wszystkiego, a nawet gdybyśmy mogli, z powodów projektowych wrażenia są lepsze, gdy tego nie robimy. Często celowo modyfikujemy symulację, aby poprawić wrażenia z gry. Te zmiany zazwyczaj pozostają niezauważone, ponieważ są zgodne z intencjami odbiorcy. Na przykład wyłączamy kolizje między graczem a dużymi obiektami, by mógł obracać się w wąskich przestrzeniach. Lub modyfikujemy alternatywny tryb strzału karabinu Kombinatu, by delikatnie kierować pociski w stronę wrogów, zwiększając skuteczność broni."
N/A4044"#commentary\cn_130_physics_simulation_2.mp3" "[ Jeff Lane ] Obszary, w których projekt gry lub inne ograniczenia miały wpływ na symulację fizyczną, często wymagały dodatkowych poprawek, by symulacja się nie posypała. Na przykład, na początku eksperymentowaliśmy ze zwiększeniem symulacji dla postaci gracza, by ruch był bardziej związany z fizyką świata. Wiedzieliśmy, że przez to poruszanie będzie mniej precyzyjne, ale mieliśmy nadzieję, że stworzymy nowe wrażenia. Jednak po dostosowaniu ruchu do mniej symulowanej wersji napotkaliśmy poważny problem: siła fizyczna potrzebna do poruszania się gracza z normalną prędkością była tak duża, że samo zderzenie z innymi symulowanymi obiektami mogło prowadzić do zgonu. Próbowaliśmy to poprawić, ale ostatecznie nie znaleźliśmy dobrego rozwiązania i wróciliśmy do ograniczonej symulacji ruchu. Nie było to jednak łatwe — pojawiły się nowe wyzwania związane z interakcją mniej symulowanego gracza z bardziej symulowanymi obiektami w grze. Pozwoliło nam to jednak zapewnić precyzyjne wrażenia z ruchu, zgodne z oczekiwaniami."
N/A4045"#commentary\cn_131_playtesting.mp3" "[ John Morello ] Testowanie jest kluczowym elementem procesu tworzenia gier – nigdy nie jesteśmy w stanie przewidzieć, jak zareagują gracze ani jakie wnioski wyciągną z tego, co stworzyliśmy. Testy pozwalają nam się uczyć i ulepszać nasze produkty. W ich trakcie nie udzielamy graczom wskazówek ani nie rozmawiamy z nimi, nawet jeśli utkną – ponieważ po premierze raczej nie będziemy siedzieć obok gracza. Staramy się, by testerzy zapomnieli, że testują grę, i grali tak, jakby byli w domu. Każda ingerencja może zafałszować dane, więc wtrącamy się tylko wtedy, gdy pojawia się błąd uniemożliwiający postęp lub, rzadziej, gdy zachowanie gracza jest tak niejasne, że musimy zrozumieć, co myśli."
N/A4046"#commentary\cn_132_playtesting_anecdote_1.mp3" "[ Matt Boone ] Jedna z pamiętnych sesji testowych przypomniała nam, że nigdy nie możemy być pewni, co myślą gracze ani jakie wnioski wyciągają z gry. Po rozpoczęciu gry tester utknął przy próbie otwarcia drzwi i przez kilka minut przechodził między grą a ustawieniami klawiatury. Kiedy zapytaliśmy, czego szuka, odpowiedział, że szuka sterowania ekwipunkiem, sądząc, że może użyć przedmiotu, który wcześniej podniósł, by otworzyć drzwi. Widzieliśmy, jak zbierał i upuszczał kilka obiektów, ale źle zrozumiał, co się dzieje. Sądził, że naciśnięcie klawisza „Użyj” podczas trzymania obiektu przenosi go do ekwipunku, ponieważ przedmiot spadł prosto w dół. Była to tylko grawitacja, ale założenie testera nie było szalone, ponieważ niektóre gry przygodowe z tamtej epoki w ten sposób przenosiły przedmioty do niewidzialnego ekwipunku. Wyjaśniliśmy, że nie ma ekwipunku, i test trwał dalej. Później zastanawialiśmy się, czy powinniśmy zająć się tą kwestią, ale żaden inny tester nie miał takich samych wątpliwości, a wszystkie potencjalne rozwiązania były zbyt radykalne, uznaliśmy więc, że jest to odosobniony przypadek, którym nie trzeba się zajmować. Było to jednak dobre przypomnienie, że nawet najdrobniejsze pomijane szczegóły mogą wprowadzać gracza w błąd."
N/A4047"#commentary\cn_133_cratebaby.mp3" "[ Scott Dalton ] Ta laleczka ma długą historię. Podczas ciągnących się miesiącami wewnętrznych testów część zespołu potraktowała ją jako wyzwanie – sposób na urozmaicenie 47. podejścia do rozgrywki. Umieszczali lalkę w pobliskiej niebieskiej skrzyni i sprawdzali, jak daleko uda im się ją przenieść w trakcie gry. Po premierze Half-Life 2 społeczność graczy również zaczęła przenosić lalkę, dodając do tego własne historie i zasady. Kilka lat później, podczas prac nad Epizodem 2, stało się to inspiracją dla osiągnięcia „Mały astronauta”, w którym gracze musieli przenosić krasnala ogrodowego o imieniu Gnome Chompski przez cały epizod. Chompski powrócił nawet w Left 4 Dead 2, w osiągnięciu „Krasnal stróż”, w którym gracze musieli nosić go przez całą kampanię Dark Carnival. Tego rodzaju interakcje są jednymi z najbardziej satysfakcjonujących elementów tworzenia gier. Projektujemy gry w oparciu o teorie, ale nigdy nie wiadomo, jak potoczą się sprawy, dopóki gracze nie wezmą ich w swoje ręce."
N/A4048"#commentary\cn_134_the_citadel.mp3" "[ Eric Kirchmer ] Chcieliśmy, aby pierwsze spojrzenie gracza na Miasto 17 podkreślało dominację Cytadeli nad wszystkim, symbolizując całkowitą władzę Kombinatu nad ludzkością. Był to również jasny cel – już na początku wskazaliśmy, gdzie kończy się podróż. Jednak pomimo ogromnych rozmiarów Cytadeli, testerzy często jej nie zauważali. Odczucie głębi i skali może być trudne do uchwycenia na monitorze. Jeśli graliście w gry w VR, pewnie zwróciliście uwagę, że skala wydaje się bardziej naturalna. W tym przypadku położenie Cytadeli nad graczem również nie pomagało, co może wynikać z faktu, że strzelanki uczą graczy skupiania się na tym, co znajduje się przed nimi lub pod ich stopami. Aby zwiększyć szanse na dostrzeżenie Cytadeli, dodaliśmy ptaki lecące w kierunku budowli, co jest subtelną sztuczką, która, jak się okazało, pomaga kierować wzrok odbiorcy."
N/A4049"#commentary\cn_135_close_captions.mp3" "[ Yahn Bernier ] Podczas tworzenia Half-Life 2 zgłosiły się do nas osoby zainteresowane dostępnością, zachęcające nas do rozbudowania napisów znanych z Half-Life 1. Poprosiły o w pełni funkcjonalny system, obejmujący wszystkie dźwięki, a nie tylko dialogi. Okazało się to znacznie trudniejszym wyzwaniem, niż sądziliśmy. W Half-Life 2 występowało wiele różnych dźwięków, a ich kategoryzacja na potrzeby napisów miała kluczowe znaczenie. Ważne było również ustalenie priorytetów: dialogi musiały się wyróżniać i jasno wskazywać, kto mówi. Dźwięki otoczenia, na przykład odległe walki, były ważne dla stworzenia nastroju na niektórych poziomach, ale mniej istotne, jeśli w pobliżu strzelał wróg. Projektanci poziomów często ponownie wykorzystywali odgłosy w różnych kontekstach, więc dźwięk mógł wymagać napisów w jednym miejscu, a w innym – nie. Ostatecznie każdy dźwięk otrzymał własne dane napisów, sformatowane prawie jak HTML, co dało nam kontrolę nad stylem wizualnym każdego napisu. Tak jak w przypadku plików audio, dane napisów były zbyt duże, by przechowywać je w pamięci, więc zbudowaliśmy asynchroniczny system buforowania, aby efektywnie je obsługiwać."
N/A4050"#commentary\cn_136_the_raid.mp3" "[ David Sawyer ] Sekcja, w której metrogliniarze robią nalot na mieszkanie, gdy gracz jest w środku, wymagała wielu poprawek, żeby wszystko działało jak trzeba. Ogólnie rzecz biorąc, projektujemy Half-Life tak, by gracze mogli sami ustalać tempo, bo każdy gra inaczej. Niektórzy biegają, ignorując wszystko, co nie wygląda na zagrożenie, a inni metodycznie sprawdzają każdy kąt. Kiedy musimy narzucić określone tempo, największym wyzwaniem jest postaranie się, by gracze zwrócili na nie uwagę i naturalnie się do niego dostosowali. Ponieważ robiliśmy to po raz pierwszy, musieliśmy włożyć wiele pracy, aby odbiorcy zrozumieli, że muszą się szybko ruszać i nie ma czasu na eksplorację."
N/A4051"#commentary\cn_137_materials_and_shaders.mp3" "[ Gary McTaggart ] Half-Life 2 wydaliśmy w okresie znaczących zmian w grafice 3D, kiedy branża przeszła od tekstur do materiałów i shaderów. W Half-Life 1 każda powierzchnia miała teksturę, czyli obraz nałożony na wielokąty powierzchni. Jednak już w Half-Life 2, zaledwie pięć lat później, każda powierzchnia miała zarówno materiał, jak i shader. Shader był fragmentem kodu, który dostosowywał sposób renderowania powierzchni. Materiał określał właściwości fizyczne powierzchni i jej reakcje na rozgrywkę. Zawierał też odniesienia do tekstur i innych parametrów wykorzystywanych przez shader do renderowania. Graficy i projektanci mieli zatem znacznie większą kontrolę nad wyglądem i zachowaniem obiektów. Wiązało się to jednak z kompromisem: Half-Life 1 działa na komputerze wyposażonym wyłącznie w procesor, ale Half-Life 2 wymaga karty graficznej, ponieważ obliczenia potrzebne do renderowania materiałów i shaderów były zaprojektowane na taki sprzęt. Refrakcyjne szklane drzwi są przykładem niestandardowego shadera, ale w rzeczywistości każda powierzchnia w scenie wykorzystuje jakiś jego rodzaj."
N/A4052"#commentary\cn_138_the_raid_2.mp3" "[ Miles Estes ] Oprócz wywarcia na odbiorcy presji parcia naprzód, musieliśmy też zadbać o to, żeby sam nalot działał niezawodnie. Gracz nie mógł mieć żadnej możliwości jego ominięcia lub powrotu i ucieczki przed metrogliniarzami. Prawdziwym problemem nie było przerwanie sceny, ale wywołanie paniki, przez co gracze zaczęliby biegać bez ładu po zauważeniu niebezpieczeństwa. Ten moment wymaga delikatnej równowagi: ucieczka miała być emocjonująca i wywołać poczucie prawdziwego zagrożenia, a jednocześnie chcieliśmy, by dało się ją przejść za pierwszym razem i mieć poczucie, że ledwo udało się przetrwać. Osiągnęliśmy to, czyniąc ścieżkę naprzód przejrzystą i podobną do tej, którą gracze pokonali wcześniej. Seria starannie rozmieszczonych wyzwalaczy kontroluje zagrożenia pojawiające się z przodu i z tyłu, utrzymując napięcie, a jednocześnie dając graczom wystarczająco dużo czasu, by wyprzedzili prześladowców."
N/A4053"#commentary\cn_139_health_and_no_hud.mp3" "[ Dave Riller ] Sekwencja pościgu na dachu była wyjątkowym wyzwaniem projektowym. Nie chcieliśmy, by była ona prawdziwą przeszkodą, a byłoby najlepiej, gdyby gracze pokonali ją za pierwszym razem. Chcieliśmy jednak stworzyć poczucie prawdziwego zagrożenia, tak, by odbiorcy bali się nawet na chwilę przystanąć. Najgorsze było to, że bez kombinezonu HEV gracze nie mają technicznie wyświetlacza HUD, nie wiedzą więc, ile zdrowia im pozostało. Po kilku eksperymentach stworzyliśmy specjalny system zdrowia dla tej sekcji, używając czerwonego blasku wokół ekranu do wskazania obrażeń. Gracze zareagowali tak, jak oczekiwaliśmy, traktując to jako zachętę do ucieczki, a pościg przebiegał zgodnie z planem. Sprawiliśmy że zdrowie regenerowało się szybko, więc blask nie utrzymywał się zbyt długo, utwierdzając graczy, że bieg był właściwym wyborem i zadbaliśmy o to, by nie zginęli na końcu od zbłąkanej kuli tylko dlatego, że wcześniej zwlekali lub się zawahali."
N/A4054"#commentary\cn_140_playtesting_anecdote_2.mp3" "[ Jakob Jungels ] W kolejnej sekcji chcieliśmy powalić gracza, by Alyx mogła go ocalić. Ze względu na ograniczony czas i zasoby uprościliśmy tę scenę tak bardzo, jak się da — znów wykorzystaliśmy istniejące systemy i rozegrała się ona jak normalna sekwencja walki, z niestandardowym wydarzeniem wyzwalanym w chwili „śmierci”. Po kilku testach pomagających w dopracowaniu synchronizacji przeszliśmy dalej. Jednak przed premierą mieliśmy problem z testerem, który ciągle korzystał z szybkiego zapisu i natychmiast używał szybkiego wczytywania, gdy uznał, że zginął. Kiedy metrogliniarz go uderzył, załadował grę, zanim Alyx zdążyła interweniować i powtarzał to ponad 10 razy, nim poprosiliśmy, by przestał. Na tym etapie ostatecznego usuwania błędów musieliśmy ograniczyć się do naprawiania problemów uniemożliwiających grę, bo nawet niewielkie zmiany mogły zepsuć coś ważniejszego. Ponieważ większość testerów nie miała żadnych problemów i był to rzadki przypadek, wprowadziliśmy kilka drobnych zmian. Skróciliśmy opóźnienie między powaleniem a pierwszą kwestią Alyx i zmieniliśmy kolor wygaszania z czarnego na biały, co jednak nie było zbyt przydatne, ponieważ gracze nie ginęli jeszcze dość często, by kojarzyć czerń ze śmiercią. Rozważaliśmy wyłączenie szybkiego wczytywania na kilka sekund trwania sceny, ale obawialiśmy się, że pojawią się błędy, przez które szybkie wczytywanie wyłączy się na stałe."
N/A4055"#commentary\cn_141_character_reactions.mp3" "[ Ariel Diaz ] Ustalenie, na co i jak powinny reagować postacie, było ciągłym wyzwaniem. Zasadniczo zawsze chcemy, by gra reagowała na działania gracza. Jednak każda reakcja może być postrzegana jako nagroda. To, na co postacie reagują, a co ignorują, uczy gracza, jakiego rodzaju działań oczekuje gra. Dlatego zadbaliśmy o to, by reagować na rzeczy, których chcieliśmy więcej, takie jak majstrowanie przy urządzeniach w laboratorium, a ignorowaliśmy zachowania, których chcieliśmy mniej, wliczając w to uderzanie Kleinera w twarz pudłem. Serio, widzieliśmy, jak tester robił to przez pięć minut bez przerwy."
N/A4056"#commentary\cn_142_choreography.mp3" "[ Bill Fletcher ] System, który stworzyliśmy i udoskonaliliśmy, by wdrożyć fabułę Half-Life 2, nosił wewnętrzną nazwę Choreo, skrót od słowa „choreografia”. Na początku uznaliśmy, że porównamy proces do pisania sztuki teatralnej, w której jeden z aktorów nie zna scenariusza. Potrzebowaliśmy systemu, który mógłby kontrolować wszystkich pozostałych aktorów, poruszając nimi po scenie, kierując ich występami i wypowiadając ich kwestie. Pozostali aktorzy musieli płynnie łączyć nasze polecenia z dynamicznymi reakcjami na pozycję i zachowanie gracza. Największym wyzwaniem było oczywiście wyczucie czasu, ponieważ każda część sceny mogła wymagać wydłużenia, skrócenia, a nawet wstrzymania, zależnie od tego, co robił gracz."
N/A4057"#commentary\cn_143_phoneme_extraction.mp3" "[ Bill Fletcher ] Kolejnym ważnym narzędziem wbudowanym w FacePoser był edytor fonemów. Przetwarzał kwestie dialogowe aktorów głosowych i wyodrębniał fonemy, by wygenerować podstawowe animacje ruchu warg dla naszych postaci. W przypadku głównych bohaterów animatorzy wykorzystali to jako punkt wyjścia do stworzenia szczegółowych niestandardowych animacji dla każdej linii dialogowej, uwzględniając pełną animację twarzy. Jednak w dynamicznej scenie Choreo animatorzy nie wiedzieli dokładnie, co zrobi reszta ciała aktora. Oznaczało to konieczność starannego nakładania poleceń Choreo i synchronizacji w FacePoser, przy zachowaniu zdolności postaci do dynamicznego reagowania na gracza."
N/A4058"#commentary\cn_144_delivery.mp3" "[ Ken Birdwell ] Potrzebowaliśmy wielu iteracji i testów, by osiągnąć równowagę między informacją a emocjonalną więzią w naszych głównych scenach Choreo. Każda z nich zawierała wiele informacji, które musieliśmy przekazać odbiorcy, ale nie mogliśmy po prostu pozwolić postaciom wygłaszać długich monologów – odbiorcy zaczęliby uważać je za drogowskazy, a nie ludzi. Poświęciliśmy czas, by postacie mogły wchodzić w interakcje między sobą, a gracze obserwowali ich relacje. Jednocześnie musieliśmy rozbudować świat, dając graczom wgląd w to, co wydarzyło się podczas ich nieobecności. Wszystko należało wprowadzić ostrożnie, bez zbytniego przedłużania – chcieliśmy, by gra miała sens dla tych, którzy byli mniej zaangażowani w fabułę. Animacja stała się potężnym narzędziem w przekazywaniu emocjonalnych powiązań między postaciami, często szybko oddając głębię chwili bez jej wyolbrzymiania. Humor był kolejnym często stosowanym narzędziem, pomagającym obniżyć napięcie i rozluźnić gracza, gdy atmosfera stawała się zbyt ciężka."
N/A4059"#commentary\cn_145_alyxs_kiss.mp3" "[ Ken Birdwell ] To tylko krótka scena, ale pocałunek Alyx w policzek Elia był bardzo ważny. W końcu poprosimy gracza, aby uratował Elia i chcemy, aby mu na nim zależało. Aby zbudować tę emocjonalną więź, musieliśmy pokazać ciepło i uczucie między Alyx i ojcem. Nie chcieliśmy przesadzać z dialogami ani robić z tego zbyt wielkiej afery – wszystko musiało to wyglądać autentycznie, a nie teatralnie – i pracowaliśmy nad subtelnym przedstawieniem tej chwili, aż osiągnęła odpowiedni ton."
N/A4060"#commentary\cn_146_storytelling.mp3" "[ Bill Van Buren ] Stworzenie poczucia immersji było podstawową zasadą naszego podejścia do narracji w Half-Life 1, więc wyznaczyliśmy sobie granicę, aby nigdy – lub przynajmniej bardzo rzadko – nie odbierać graczowi kontroli i nie przerywać milczenia jego postaci. Ograniczenia te sprawiały, że tworzenie historii było czasami trudniejsze, ale uznaliśmy, że musimy trzymać się tego samego w Half-Life 2. Mieliśmy nadzieję, że dzięki zachowaniu tych zasad zmobilizujemy się do zgłębiania bardziej interaktywnej narracji."
N/A4061"#commentary\cn_147_archetypes.mp3" "[ Bill Van Buren ] Chcieliśmy stworzyć narracyjne powiązania między Half-Life 1 a Half-Life 2 poprzez naszych bohaterów. Próbowaliśmy stworzyć postacie, które reprezentowały archetypy z Half-Life 1, by gracze mogli uznać je za znajome, jakby spotkali je kiedyś w Half-Life 1, ale nie potrafili sobie ich przypomnieć. Dr Kleiner został oparty na modelu naukowca, który uznaliśmy za najbardziej charakterystyczny, a jego osobowość została w dużej mierze ukształtowana przez Hala Robinsa, którego głos i gra aktorska zdefiniowały naukowców z Half-Life 1. Pewnego dnia, kiedy próbowaliśmy zdefiniować osobowość tej postaci, twarz doktora Kleinera stała się jasna, ponieważ przypadkiem dzieliliśmy windę z księgowym z biura na innym piętrze naszego budynku. Patrząc na niego zrozumieliśmy, że „to właśnie twarz doktora Kleinera”. Na szczęście był chętny, kiedy zapytaliśmy, czy możemy zrobić mu zdjęcie i wzorować na nim postać z gry."
N/A4062"#commentary\cn_148_tone.mp3" "[ Bill Van Buren ] Nadanie odpowiedniego tonu naszym postaciom i ich dialogom było kluczowe. Chcieliśmy, by interakcje z graczem były pełne szacunku, niemal przyjemne, unikając jednocześnie wszystkiego, co mogłoby sprawiać wrażenie zbyt uległego. Zachowanie tej równowagi było szczególnie trudne w przypadku Alyx, która musiała wspierać gracza, nie tracąc przy tym siły charakteru – gracze musieli darzyć ją szacunkiem. Jej relacja z Eliem była główną motywacją, więc dbaliśmy o to, by gracze ją polubili i chcieli jej pomóc. Chcieliśmy również skontrastować ciepło i przyjaźń między sojusznikami gracza z wrogością Breena i Kombinatu, budząc w graczach poczucie słusznego gniewu przed nadchodzącymi bitwami."
N/A4063"#commentary\cn_149_voice-actors.mp3" "[ Bill Van Buren ] Aby stworzyć bardziej autentyczne i wielowymiarowe postacie w Half-Life 2, musieliśmy zmienić nasze podejście do współpracy z aktorami głosowymi. W Half-Life 1 wystarczyło przeczytanie scenariusza z niewielką ilością wskazówek, aby stworzyć dialogi dla większości postaci niezależnych, w Half-Life 2 daliśmy aktorom większą swobodę w definiowaniu postaci i ożywianiu ich. Podaliśmy im znacznie więcej wskazówek fabularnych, pokazując świat gry, środowiska, w których żyły ich postacie oraz inne osoby, z którymi wchodziły w interakcje. Szukaliśmy aktorów, którzy potrafiliby wykorzystać wszystkie te informacje i włączyć je do swojego repertuaru, by podnieść poziom złożoności swoich postaci ponad to, co zaplanowaliśmy. Zorganizowaliśmy wiele sesji z głównymi aktorami, by mogli z czasem oswoić się ze swoimi bohaterami i ich rozwinąć. W scenach, w których postacie wchodzą w interakcje, często podpowiadaliśmy aktorom, jak grać z innymi w scenie, by stworzyć lepsze poczucie więzi i płynności rozmów. Chociaż przychodziliśmy do studia z gotowym scenariuszem i planem nagrania, dbaliśmy o to, by aktorzy czuli się pewnie i mogli wnosić własne pomysły do postaci i swoich występów. Obecność animatorów podczas sesji nagraniowych również okazała się kluczowa, ponieważ byli odpowiedzialni za połączenie dialogów postaci z fizycznymi działaniami i mimiką, tworząc ostateczną scenę Choreo. Często animatorzy odkrywali, że ich plany dotyczące przebiegu sceny znacznie ewoluowały po współpracy z aktorem głosowym."
N/A4064"#commentary\cn_150_citizens.mp3" "[ Bill Van Buren ] Kiedy przyszedł czas na zaprojektowanie mieszkańców Miasta 17 i świata poza nim, postanowiliśmy uwzględnić różne rasy, grupy wiekowe i płcie. Nie tylko zapewniło to kontekst narracyjny dla zniewolenia całej ludzkości przez Kombinat – zależało nam również, by wszyscy odbiorcy mogli poczuć się częścią ruchu oporu, w którym mieszkańcy Ziemi zjednoczyli się przeciwko Kombinatowi. Chociaż znaleźliśmy wielu kandydatów, których mogliśmy wykorzystać jako wzór do stworzenia obywateli w naszym życiu codziennym i dzięki kontaktom, ostatecznie zdecydowaliśmy się zamieścić ogłoszenie Seattle Times, aby dotrzeć do osób pasujących do zakładanego wyglądu."
N/A4065"#commentary\cn_151_alyx.mp3" "[ Dhabih Eng ] Stworzenie postaci Alyx było dużym wyzwaniem — chcieliśmy, by gracze darzyli ją szacunkiem i im na niej zależało. Uratowanie Elia było głównym celem w połowie gry i wiedzieliśmy, że gracze szybciej się na nim skupią, jeśli będą również troszczyć się o Alyx i jej relacje z ojcem. Projekt Alyx, jej dialogi i aktorka głosowa zostały dobrane tak, by była sprytna, zdolna i bliska odbiorcom w świecie kontrolowanym przez Kombinat, a jednocześnie musiała być atrakcyjna i charyzmatyczna. Staraliśmy się uniknąć uprzedmiotowienia, przesady i hiperseksualności, które charakteryzowały wiele gier z pierwszej dekady XXI wieku, ponieważ nie osiągnęlibyśmy wówczas założonego celu."
N/A4066"#commentary\cn_152_lab_interactivity.mp3" "[ Dhabih Eng ] W scenach choreograficznych gracz jest przez chwilę uwięziony, co pozwala nam skupić się na postaciach i narracji. Aby dostosować się do różnych graczy – niektórych zaangażowanych w fabułę, innych niezdolnych do stania w miejscu dłużej niż sekundę – uznaliśmy, że potrzebujemy ciągłego przepływu ciekawych szczegółów na ekranie. Rozmieszczamy elementy narracji w całym otoczeniu, dbając o to, by niektóre z nich były interaktywne, więc gracz mógł się nimi bawić. W kilku przypadkach umieszczamy w nich dodatkowe elementy fabuły, takie jak mini-teleport w kształcie kaktusa, który zapowiada awarię teleportu. Była to delikatna równowaga – zbyt wiele elementów wizualnych mogło odwracać uwagę graczy od sedna sceny. Ostatecznie w laboratorium Kleinera postawiliśmy na bezpieczne interakcje, ponieważ była to pierwsza duża sekwencja. Później, w laboratorium Elia rozszerzyliśmy możliwości, a postacie zwracały uwagę na to, czym bawią się gracze."
N/A4067"#commentary\cn_153_gestures.mp3" "[ Doug Wood ] Każda z naszych postaci miała bibliotekę prostych animacji zwanych gestami, które mogliśmy łatwo nakładać na inne ruchy ciała. Pierwotnie miała to być oszczędność produkcyjna, umożliwiająca ponowne wykorzystanie animacji w całej grze, ale okazało się, że pomysł ma jeszcze inne zastosowanie. Ludzie często powtarzają pewne ruchy, które mogą być wyznacznikami ich osobowości. A zatem biblioteka gestów uchwyciła istotę każdej postaci, pomagając zespołowi animatorów w ujednoliceniu charakterologii bohaterów. Dzięki temu animatorzy mogli łatwiej dzielić się między sobą pracą związaną z daną postacią, co zdarzało się często w procesie produkcji."
N/A4068"#commentary\cn_154_interactive_storytelling.mp3" "[ Erik Johnson ] Gdy zaczynaliśmy pracę nad Half-Life 2, fabuła w grach była zwykle albo dopracowana i liniowa, albo mniej szczegółowa i interaktywna. Gracze poznali już rozbudowane fabuły w grach, ale nigdy nie byli w samym środku akcji – nie mogli obserwować, jak historia rozwija się wokół nich, reagować na nią i badać jej poszczególne elementy. Chociaż nie mogliśmy się doczekać tworzenia narracji, nie wiedzieliśmy jeszcze, jak będzie działać ani jakiej technologii potrzebujemy, by osiągnąć cel. W Half-Life 1 stworzyliśmy różnorodne techniki narracji, ale były głównie prezentowane przed graczem, brakowało im interaktywności i szczegółowości. Laboratorium Kleinera stało się poligonem doświadczalnym, na którym sprawdzaliśmy, jak faktycznie będzie działać nasze interaktywne opowiadanie historii."
N/A4069"#commentary\cn_155_monitors.mp3" "[ Ido Magal ] W Half-Life 2 i epizodach wykorzystujemy monitory do opowiadania historii tak często, że nawet nas samych to bawi. Problem w tym, że są po prostu zbyt użyteczne. Świetnie nadają się do poszerzania świata poprzez pokazywanie wydarzeń mających miejsce gdzie indziej i w łatwy sposób umożliwiają rozmowę z postaciami bez wyjaśniania, w jaki sposób wszystkie dotarły do lokalizacji gracza. Każdy, kto kiedykolwiek pisał jakąkolwiek historię, zwłaszcza z zespołem aktorskim, rozumie, jak frustrujące jest wymyślanie naturalnych powodów, dla których wszystkie postacie spotykają się jednym miejscu. W tym przypadku byliśmy zadowoleni, bo monitor pozwolił Alyx teleportować się i szybko pojawić się w laboratorium Elia, dzięki czemu wszystko wydawało się prawdziwe i powiązane."
N/A4070"#commentary\cn_156_scene_interactivity.mp3" "[ Jeff Lane ] W niektórych momentach naszych scen choreograficznych wymagamy od gracza podjęcia działania. Poza tymże dajemy mu coś do zrobienia i utrzymujemy jego zaangażowanie, momenty te spełniają kilka zadań. Po pierwsze, pozwalają graczowi nadrobić zaległości, jeśli coś w otoczeniu odwróciło jego uwagę. Scena może zostać bezpiecznie „wstrzymana” do momentu wykonania zadania, co gwarantuje, że gracz wróci do gry i będzie skupiony. Jednocześnie pozwalało nam to ustawić postać w odpowiednim miejscu, co ułatwiało kompozycję sceny i zapewniało, że gracz dostrzeże coś ważnego. W niektórych przypadkach wykorzystaliśmy te momenty na dwa sposoby, wykorzystując je do szkolenia – tutaj gracz uczy się obsługi wtyczek i gniazdek, co jest potrzebne do rozwiązania zagadek w dalszej części gry."
N/A4071"#commentary\cn_157_kleiners_lab.mp3" "[ Marc Laidlaw ] Laboratorium Kleinera było pierwszym elementem fabuły, nad którym pracowaliśmy i jego opracowanie zajęło nam najwięcej czasu. Oprócz wprowadzenia do gry, było ono spójną wizją zespołu deweloperskiego co do fabuły. Kiedy zaczęliśmy tworzyć postacie i narrację wokół gracza, pojawiło się wiele pytań, z których wszystkie wydawały się stanowić poważne ryzyko. Czy gracze będą w stanie wyciągnąć z tej sceny ważne informacje? Czy zdołamy sprawić, że będą się przejmować losami tych postaci? Jak zadowolić graczy o różnym poziomie zaangażowania w fabułę? Jak kosztowne jest stworzenie tej sceny? Ilu takich scen będziemy potrzebować? Na te i wiele innych pytań nie mogliśmy odpowiedzieć, dopóki nie stworzyliśmy wystarczającej części sceny i nie przetestowaliśmy jej z udziałem wielu testerów. Frustrujące było to, że w przeciwieństwie do wielu innych problemów, tu nie byliśmy w stanie odpowiedzieć na te pytania z całą pewnością, dopóki nie zakończyliśmy większości prac. Często możemy testować pomysły dotyczące rozgrywki na uproszczonych prototypach, ale jeśli gracz nie jest zaangażowany w naszą opowieść, gdy postacie są tylko szarymi blokami, to skąd możemy mieć pewność, że będzie zainteresowany, gdy postacie będą w pełni gotowe?"
N/A4072"#commentary\cn_158_characters.mp3" "[ Marc Laidlaw ] W Half-Life 1 strażnicy i naukowcy byli raczej archetypami, a nie indywidualnymi bohaterami. Były to abstrakcyjne postacie, które wyczerpywały możliwą do osiągnięcia szczegółowość wizualną. Jednak wraz z udoskonaleniem technologii w Half-Life 2 dostrzegliśmy możliwość wyjścia poza abstrakcje. Dzięki zwiększonej liczbie detali modeli w połączeniu z ulepszeniami animacji uwierzyliśmy, że możemy skupić się na tworzeniu indywidualnych bohaterów – ludzi, na których naprawdę zależy graczom. Mogliśmy napisać pełnoprawne dialogi i dać je wypowiedzieć postaciom w sposób na tyle realistyczny, aby gracze nie postrzegali ich jako pionków w grze, a przy okazji by popchnąć naszą narrację do przodu. W 2001 roku, po kilku latach prac nad grą, zainspirowała nas gra „Ico” z Japan Studio. Wyreżyserowana przez animatora produkcja zachwyciła nas tym, że postawiła na postacie jako kluczowy element łączący gracza z rozgrywką, co zachęciło nas do dalszej pracy."
N/A4073"#commentary\cn_159_writing.mp3" "[ Marc Laidlaw ] W czasach Half-Life 1 celem graczy w strzelankach byłą walka i pokonanie ewidentnie złego przeciwnika. Trudno było sprawić, by przejmowali się postaciami, które w Half-Life 1 były mało realistyczne. Zwiększając realizm bohaterów w Half-Life 2 chcieliśmy uczynić z nich motor napędowy narracji. Staraliśmy się, by motywacje odbiorcy były zbieżne z motywacjami postaci, aby gracz przejął się tymi ludźmi, ich nadziejami i obawami i chciał pomóc im odnieść sukces. Mając to na uwadze, mogliśmy zastanowić się nad podejściem do postaci i dialogów. Stworzyliśmy grupę bohaterów, którzy się lubili i troszczyli o siebie, mając nadzieję, że odbiorca poczuje to samo. Postacie te wchodziły w interakcje, włączając w nie odbiorcę, jak grupa starych przyjaciół, którzy postrzegają gracza jako jednego z nich – kogoś, kto po prostu był przez jakiś czas nieobecny. Uważaliśmy, że jeśli bohaterów połączą realistyczne emocjonalne więzi, uda nam się zbudować podobną relację również z graczem."
N/A4074"#commentary\cn_160_animation.mp3" "[ Miles Estes ] Stworzenie realistycznych ruchów postaci z licznych oddzielnych warstw animacji wymagało wielu iteracji technologicznych. Nawet proste czynności, takie jak odwrócenie się, by na coś spojrzeć, lub przejście do określonego miejsca, stały się bardziej złożone, a poza tym musiały reagować na gracza i polecenia systemu Choreo. Na przykład odwrócenie się musiało zostać rozłożone na czynniki pierwsze, umożliwiając postaci użycie dowolnej kombinacji oczu, głowy, ramion, górnej części tułowia lub całego ciała, by zwrócić się w stronę celu. W Half-Life 1 ciała postaci ludzkich były podzielone na górną i dolną połowę, co pozwalało im iść w jednym kierunku, patrząc w innym. Jednak takie podejście było zbyt abstrakcyjne dla postaci z Half-Life 2. Zamiast tego nasi animatorzy stworzyli animacje chodzenia w ośmiu kierunkach, które następnie można było płynnie łączyć w czasie rzeczywistym."
N/A4075"#commentary\cn_161_faceposer.mp3" "[ Yahn Bernier ] Głównym narzędziem stworzonym do obsługi systemu Choreo, był program o nieprecyzyjnej nazwie FacePoser, który umożliwiał naszym animatorom rozplanowanie całej struktury scen na osi czasu. Oś ta zawierała serię poleceń Choreo dla aktorów wraz ze wszystkimi informacjami niezbędnymi do wykonania tych wytycznych. Dzięki ułożeniu całości na osi czasu animatorzy mogli łatwo opisać, w jaki sposób aktor powinien patrzeć w jedną stronę, rozmawiać i jednocześnie przejść w inne miejsce. Oś czasu nie była jednak stałą, liniową sekwencją. Aktorzy wykonywali polecenia, ale musieli dynamicznie reagować na otaczający ich świat. Aktor mógł potrzebować więcej czasu, aby przejść do danego miejsca, jeśli gracz stał mu na drodze, lub musiał poczekać z wypowiedzią, ponieważ inny aktor został opóźniony przez gracza. FacePoser pozwolił nam szybko kreować sceny, by wypróbować różne układy, sposoby wypowiedzi i synchronizację. Ta możliwość natychmiastowego eksperymentowania i dostosowywania okazała się kluczowa w znalezieniu odpowiednich zachowań, by osiągnąć cele dotyczące postaci i narracji."
N/A4076"#commentary\cn_162_choreo_commands.mp3" "[ Yahn Bernier ] Ta wizualizacja debugowania pokazuje dwa najczęściej używane polecenia Choreo, które aktorzy otrzymują w trakcie sceny, znane jako „spójrz-na” i „idź-do”. Aktorzy otrzymują cele, na które mają patrzeć — czasami więcej niż jeden naraz — i próbują skupić się na tym, który ma największy sens w obecnej sytuacji. Jednocześnie mogą otrzymywać polecenia „idź-do”, które nakazują im przejść w określone miejsce i zwrócić się w danym kierunku lub w stronę określonego obiektu. Nawet te pozornie proste polecenia są wyjątkowo złożone. Scena mogła wymagać od aktora mówienia podczas pisania na klawiaturze i patrzenia na obiekt trzymany przez gracza. Ponieważ nie mogliśmy przewidzieć, gdzie będzie gracz podczas odtwarzania, tworzenie takich scen wymagało podzielenia każdego elementu na oddzielne części i warstwy. Potem można było ponownie złożyć je podczas odtwarzania w oparciu o działania gracza i w razie czego – przerwać."
N/A4077"#commentary\cn_163_antlions.mp3" "[ Kerry Davis ] Ponieważ gracz porusza się łazikiem wzdłuż Wybrzeża, potrzebny był wszechobecny wróg, który mógł pojawić się w dowolnym miejscu i być ciągłym zagrożeniem, zmuszając gracza do pozostania w łaziku lub w jego pobliżu. Idealnym rozwiązaniem okazały się mrówkolwy wyskakujące z piasku. Ich duża mobilność pozwalała im na krótko nadążać za łazikiem, czego nie potrafili humanoidalni wrogowie. Co więcej, rozjeżdżanie ich dawało sporą satysfakcję."
N/A4078"#commentary\cn_164_thumpers.mp3" "[ Adrian Finol ] Jeśli to możliwe, warto, by gracze mieli poczucie, że sami coś odkryli. Dzięki temu świat wydaje się bardziej żywy, zamiast być serią elementów rozgrywki przygotowanych dla gracza. Jeśli zaakceptujemy ryzyko, że część graczy może przegapić jakiś element, stosujemy bardziej subtelne podejście. Tak postąpiliśmy z dudnikami, projektując sytuacje, które gracze mogą napotkać, ale nie są zmuszeni do interakcji. Istnieje wiele wskazówek wizualnych i dźwiękowych, wliczając w to reakcje mrówkolwów, które pomagają graczowi zrozumieć, co się dzieje. Nie ma gwarancji, że wszyscy to załapią, ale w testach okazało się, że większości odbiorców się to udało."
N/A4079"#commentary\cn_165_d2_coast_09.mp3" "[ Aaron Seeler ] Pod koniec prac nad Wybrzeżem nasz kod znacznie wyprzedzał projekt poziomów, więc programiści zajmujący się rozgrywką chcieli napisać więcej kodu i pomóc nam w w wydaniu Half-Life 2. Wynikało to głównie z wymagań poziomów Wybrzeża, będących dużym obciążeniem dla projektantów poziomów ze względu na ogromną skalę i rozległy teren. Dlatego programiści od rozgrywki zaczęli projektować starcia o mniejszej skali. Później, gdy projektanci poziomów nadrobili zaległości, stworzyli ten poziom, łącząc trzy oddzielne spotkania zaprojektowane przez programistów i doszlifowując niezbędne szczegóły, by stał się pełni grywalny."
N/A4080"#commentary\cn_166_final_scene.mp3" "[ Bill Van Buren ] Zamknięcie gracza w kapsule podczas ostatecznej konfrontacji w biurze Breena było kompromisem, ale pozwoliło nam skupić się na postaciach w sposób, który nie byłby możliwy gdzie indziej. Wszystkie wątki fabularne postaci osiągają swój punkt kulminacyjny w tej scenie. Ograniczenie gracza do tej perspektywy stwarza okazję do prawdziwego emocjonalnego zwrotu akcji: kulminacyjnej sceny opartej na dialogach, głosach i animacjach. Z punktu widzenia produkcji ten moment był trudny w realizacji; musieliśmy ustawić odpowiednie blokady i ruchy i zgrać całość w czasie , by otrzymać emocjonalną synergię i połączenie wszystkich indywidualnych animacji i głosów, które nagraliśmy oddzielnie. Potrzebowaliśmy wielu poprawek, by osiągnąć odpowiedni dramatyzm tak, by wszystkie postacie naprawdę wydawały się ze sobą powiązane."
N/A4081"#commentary\cn_167_end_game_scramble.mp3" "[ Dave Riller ] Pierwotnie na zakończenie planowaliśmy znacznie większą scenę choreograficzną. Jednak zespół od Choreo miał masę pracy związanej z pozostałymi wątkami fabularnymi. By ich odciążyć, zespół odpowiedzialny za rozgrywkę w Cytadeli miał stworzyć wyzwanie na zakończenie gry. Mogła to być łamigłówka, scena walki lub cokolwiek innego. Tak powstała walka z bossem Breenem, wykorzystująca istniejącą mechanikę gry z superdziałem grawitacyjnym i odrobinę niestandardowej choreografii, dzięki czemu udało się stworzyć gotowy scenariusz w bardzo krótkim czasie."
N/A4082"#commentary\cn_168_combine_portal_effects.mp3" "[ Gary McTaggart ] Kluczowym elementem naszego procesu tworzenia jest to, że każdy członek zespołu może wnieść coś od siebie do dowolnej części gry. Po ukończeniu rozgrywki bitwy finałowej graficy i programiści efektów wizualnych pomogli ulepszyć wygląd portalu na planetę Kombinatu oraz efekt zatrzymania czasu na końcu gry. Do stworzenia efektu portalu użyliśmy shadera refrakcyjnego podobnego do tego, który wykorzystaliśmy w grafice wody."
N/A4083"#commentary\cn_169_citadel_entrance.mp3" "[ Jeff Lane ] Trasę do Cytadeli stworzyliśmy od końca: geometria wnętrza została opracowana jako prototyp. Wiedzieliśmy, że gracze będą docierać do Cytadeli z kanałów ściekowych na mapie Wojny Ulicznej, więc stworzyliśmy serię zjeżdżalni i skoczni prowadzących do Cytadeli, aby połączyć te dwa miejsca."
N/A4084"#commentary\cn_170_citadel_steep_landing.mp3" "[ Randy Lundeen ] Cytadela powstała dość późno w procesie twórczym i początkowo nie byliśmy do końca pewni, jak ma wyglądać. Nie jest to niczym niezwykłym. Chociaż proces tworzenia zazwyczaj opiera się na projekcie, to jednak ważne decyzje, podejmowane na wczesnym etapie, takie jak istnienie Cytadeli Kombinatu, wymagają konkretnych rozwiązań, by pasować do ostatecznej wizji. Po wielkiej bitwie w ostatnim rozdziale doszliśmy do wniosku, że fajnie byłoby urozmaicić finał w Cytadeli, nadając mu inny klimat. Nawet gdybyśmy chcieli podbić stawkę, tworzenie nowych mechanik i postaci na tak późnym etapie było zbyt ryzykowne. Pierwotnie zakładaliśmy stworzenie pasywnej narracji – przejażdżki pociągiem przez serce machiny wojennej Kombinatu, kończącej się w biurze Breena. Po opracowaniu tego planu spędziliśmy kilka dni nad prototypem mechaniki działa grawitacyjnego. Pomyśleliśmy, że pod koniec gry możemy spełnić wszystkie pragnienia graczy, dając im supermoce bez naruszania równowagi rozgrywki. Wyniki były obiecujące, więc szybko przeprojektowaliśmy grę, by uwzględnić superdziało grawitacyjne. Zamiast zwykłych wyzwań daliśmy graczom poczucie boskości — rzucali wrogami i wyrywali konsole ze ścian. Ostatecznie Cytadela łączy te dwie idee, przechodząc od widowiska do uwolnienia potęgi."
N/A4085"#commentary\cn_172_lightmap_pass.mp3" "[ Mike Dussault ] Wnętrze Cytadeli ma stosunkowo prostą geometrię, ale metalowy materiał Kombinatu i dramatyczne oświetlenie pomagają podkreślić ogrom tej konstrukcji. Rozdzielczość mapy światła została zwiększona na ważnych, interesujących powierzchniach, a zmniejszona na tych, które były całkowicie zacienione lub odległe. Ponadto, ze względu na rozległe przestrzenie Cytadeli, niepotrzebnie duża mapa światła miała znaczący wpływ na wydajność. Pod koniec prac jeszcze raz sprawdziliśmy wszystkie poziomy Cytadeli, by zoptymalizować te wartości pod kątem atrakcyjności wizualnej i wydajności. Ułatwiła to nowa funkcja w edytorze poziomów Hammer, która wyświetla powierzchnie wraz z gęstością luxeli."
N/A4086"#commentary\cn_173_super_gravity_origins.mp3" "[ Brian Jacobson ] Na tym etapie byliśmy już pewni projektu działa grawitacyjnego. Chcieliśmy dać graczom poczucie nieograniczonej potęgi i zabraliśmy się do pracy nad wersją o zwiększonej mocy. Nie zajęło to dużo czasu – może jeden dzień prac – i uzyskaliśmy coś, co nam się podobało i stało się podstawą rozgrywki w Cytadeli. Po ukończeniu silnika fizycznego mogliśmy swobodnie szukać nowych, ciekawych sposobów na przekroczenie dotychczasowych ograniczeń i uzyskanie jak najciekawszych rezultatów. Nasz prototypowy obiekt – niezwykle ciężki arbuz, który w naszej symulacji fizycznej ważył setki kilogramów – ostatecznie stał się kulami Kombinatu, które można zobaczyć w grze."
N/A4087"#commentary\cn_174_combine_energy.mp3" "[ Brian Jacobson ] To, co z początku było prototypem w formie arbuza, ostatecznie przekształciło się w kulę energii, ponieważ dźwięki uderzenia i eksplozji bardziej przypominały te pasujące do gry niż odgłos owoców. Kiedy zaczęliśmy pracować nad poziomami, które nie były oparte na arbuzach, zdaliśmy sobie sprawę, że kulę energii możemy wykorzystać nie tylko jako ciekawy sposób zabijania żołnierzy, ale także jako element łamigłówki służący do włączania i wyłączania różnych urządzeń. W późniejszym etapie projektowania nie podobał nam się ówczesny alternatywny tryb strzału AR2, a ponieważ zespół polubił kulę Kombinatu, ostatecznie wykorzystaliśmy ją w alternatywnym trybie AR2. Spoglądając wstecz zawsze jesteśmy zaskoczeni, jak rzeczy, które działają niezależnie od siebie później łączą się i rozwiązują nasze problemy."
N/A4088"#commentary\cn_175_combine_wall_and_balls_training.mp3" "[ Ido Magal ] Podczas testów gracze nie zauważali, że kule Kombinatu rozpuszczały żołnierzy i nie rozumieli, dlaczego znikają. Próbowaliśmy rozwiązać ten problem, sprawiając, że kule odbijały się w kierunku wrogów, zwiększając prawdopodobieństwo rozpuszczenia. W końcu zdaliśmy sobie sprawę, że gracze nie zauważali tego efektu, ponieważ zawsze działo się to podczas intensywnej walki, a ludzie mają ograniczoną zdolność uczenia się nowych rzeczy w stresujących sytuacjach. Dlatego później dodaliśmy spokojne pomieszczenie treningowe z polem siłowym, które można otworzyć tylko złapaną kulą Kombinatu. Było to specjalnie zaprojektowane szkolenie wskazujące, że kule wyłączają pola siłowe oraz że potrafią rozpuszczać żołnierzy. Jednak nawet to rozwiązanie odniosło umiarkowany sukces w testach. Pomimo naszych wysiłków, niektórzy gracze nadal nie zauważali efektów rozpuszczania. Co prawda skończył nam się czas, jednak gracze nadal byli zadowoleni z poczucia potęgi, więc uznaliśmy, że nie wszyscy muszą koniecznie wiedzieć, dlaczego udaje im się wygrać."
N/A4089"#commentary\cn_176_weapon_strip.mp3" "[ Josh Weier ] Kiedy wprowadziliśmy superdziało grawitacyjne, nie chcieliśmy, aby gracze powracali do broni konwencjonalnej, więc zrobiliśmy jedyną racjonalną rzecz: zniszczyliśmy ją. Dobrze jest mieć w grze nieprzeniknionego, nadprzyrodzonego wroga, takiego jak Kombinat, ponieważ wydaje się logiczne, że posiada coś takiego jak dezintegrator. Dlaczego nie? A gdybyśmy z jakiegoś powodu musieli zwrócić ekwipunek graczowi w połowie poziomu? Któż by się spodziewał, wrogowie mają również reintegrator."
N/A4090"#commentary\cn_177_breen_monologue.mp3" "[ Marc Laidlaw ] Żadne dzieło nigdy nie powstaje w próżni, ponieważ wszyscy czerpiemy inspirację z innych rzeczy. Monolog Breena, który pojawia się na monitorach Cytadeli, został zainspirowany wcześniejszą grą, którą wszyscy kochaliśmy, Thief 2, w której antagonista drwi z gracza, gdy ten skrada się po lokacji. Realizacja jest zupełnie inna, ale podstawowa inspiracja pozostała. Jednak najważniejsza rzecz, która naprawdę sprzedaje tę scenę, to gra zmarłego Roberta Culpa. Jego aktorstwo było idealne. Zinterpretował każdą z kwestii Breena z subtelnością i polotem, które zmieniły postać z kart scenariusza w kogoś naprawdę wyjątkowego. Sesja nagraniowa z Robertem Culpem była bardzo prosta – dostał scenariusz, inżynier włączył nagrywanie i to wszystko. Warto pracować z ludźmi, którzy mają większy talent niż my i od których na pewno się czegoś nauczymy. Nie należy mieć gotowego pomysłu na to, jak trzeba wypowiedzieć daną kwestię lub jak powinna wyglądać dana scena, a zamiast tego współpracować z uzdolnionymi ludźmi i wierzyć, że uczynią scenę jeszcze lepszą."
N/A4091"#commentary\cn_178_dissolved_weapons.mp3" "[ Quintin Doroquez ] Wszystkie bronie Kombinatu rozpuszczały się, gdy żołnierze ginęli od superdziała grawitacyjnego. Z kilku powodów. Po pierwsze, by gracze nie podnosili ich i nie używali, a poza tym po to, by poprawić wydajność na tych mapach. Dodatkowo dodaliśmy menedżera efektu ragdoll, który usuwał ciała zabitych żołnierzy w miarę postępów gracza."
N/A4092"#commentary\cn_179_elevator_fight.mp3" "[ Brian Jacobson ] Chociaż gracz miał czuć się wszechmocny, nie mogliśmy oprzeć się pokusie dodania trudnej walki w szybie windy. Bitwa tocząca się w oczekiwaniu na windę okazała się nieco trudniejsza niż pierwotnie zakładaliśmy dla tej części gry. Podczas testów stała się łatwiejsza, ale nie mieliśmy dość czasu, by zrównoważyć ją do zakładanego poziomu. Chociaż gracz nigdy nie był w zbyt wielkim niebezpieczeństwie, to dzięki dużej liczebności żołnierzy, walka wydaje się bardziej klimatyczna, niż jest w rzeczywistości."
N/A4093"#commentary\cn_180_replacing_the_prefabs.mp3" "[ Jeff Lane ] Kule energii są stosunkowo prostym pomysłem – pole siłowe utrzymuje nieustannie odbijające się obiekty. Jednak podczas testów wielokrotnie pojawiały się błędy związane z odbijającymi się kulami, które wymykały się spod kontroli i „uciekały” z pola siłowego, które miało je zatrzymać. Ze względu na ograniczenia naszej ówczesnej gotowej technologii wymagało to wielokrotnego ręcznego odtwarzania ich we wszystkich lokacjach, na wszystkich poziomach Cytadeli, na których się znajdowały."
N/A4094"#commentary\cn_181_strider_fight.mp3" "[ Ted Backman ] Jeden z oryginalnych prototypów Cytadeli obejmował możliwość chwytania stępacza za pomocą superdziała grawitacyjnego i przez długi czas walka polegała na zbliżeniu się do niego na tyle, by chwycić go za pomocą broni. Pod koniec prac uznaliśmy, że przez to chwytanie stępacze wydają się zbyt słabe, zwłaszcza po wszystkich bitwach z nimi podczas Wojny Ulicznej, więc zastąpiliśmy to starcie walką, w której niszczy się je kulami Kombinatu . Dodaliśmy elementy modelu, by stępacz rozlatywał się na kawałki i wybuchał w powietrze, zamiast padać na ziemię. Jest to jedyny moment w grze, w którym widać ten efekt zgonu stępacza."
N/A4095"#commentary\cn_182_getting_in_the_pod.mp3" "[ Dhabih Eng ] Sekwencja wznoszenia kapsuły, która rozpoczyna się w tym miejscu, wymagała przejęcia pełnej kontroli nad sceną i widokiem. Jest to sprzeczne z naszą filozofią pozostawienia graczowi jak największej kontroli. W przypadku tego ostatniego etapu uznaliśmy, że kompromis jest tego wart. Gracz jest w tym momencie tak potężny, że kontrolowanie go było trudne. Musieliśmy więc go wyłączyć. W scenie wciąż mamy wszystkie postacie, które rozmawiają z graczem, utrzymując go w centrum uwagi. Udało nam się również wprowadzić pewną narrację poprzez mijane otoczenie. Podróż przez Cytadelę, która rozpoczyna się tutaj, zawiera kilku przeciwników, dla których mieliśmy gotowe materiały graficzne, ale zostali oni wycięci z głównej części gry. Z bezpiecznego, przytulnego wnętrza kapsuły można zobaczyć tworzenie nękaczy i rzucić okiem na syntkraba."
N/A4096"#commentary\cn_183_turrets.mp3" "[ Mike Dussault ] Wieżyczki były przydatnym narzędziem, gdy gracz dysponował przynętą, ponieważ całkowicie uniemożliwiały mrówkolwom frontalny atak. Dzięki temu mogliśmy stworzyć sytuacje, w których gracz nie mógł po prostu rzucić przynętą, aby przejść dalej – musiał okrążyć i zlikwidować wieżyczki, by mrówkolwy mogły za nim podążać. Dodatkową zaletą było to, że oglądanie mrówkolwów koszonych przez ogień wieżyczek było świetnym widowiskiem."
N/A4097"#commentary\cn_184_grenade_puzzle.mp3" "[ Aaron Seeler ] Gracze często utykali na tej małej zagadce podczas testów, ponieważ skrzynka z nieograniczoną ilością granatów była umieszczona nieco za nimi. W tym momencie gracze w pełni nauczyli się kojarzyć skrzynki z nieograniczoną ilością amunicji z rozwiązaniami zagadek, więc gdyby skrzynka z granatami znajdowała się w tym miejscu, od razu wiedzieliby, że rozwiązaniem jest granat. Chcieliśmy, by najpierw musieli trochę pomyśleć. Ostatecznie dodaliśmy subtelną wskazówkę – granaty były widoczne przez okno, na biurku, co przypominało o nich graczom. Pomogły one również wykryć błąd podczas testów – jeden gracz podszedł, by przyjrzeć się skrzynce i zebrał granaty przez szybę."
N/A4098"#commentary\cn_185_allied_turrets_balancing.mp3" "[ Adrian Finol ] Dostosowanie walki do sojuszniczych wieżyczek było trudne. Są tutaj nowym elementem, więc jeśli gracze je ignorują, rozgrywka wydaje się powtarzalna, ponieważ przypomina to, co było wcześniej. Chcieliśmy wymusić wykorzystanie wieżyczek i nagradzać strategiczne rozmieszczenie, ale było to bardzo zero-jedynkowe – idealne rozmieszczenie sprawiało, że walka była łatwa, zaś przy złym rozstawieniu wyjątkowo trudna. Pomogło dostrojenie i dostosowanie logiki sztucznej inteligencji żołnierzy – stali się lepsi w niszczeniu wieżyczek, rzucając granaty lub atakując z flanki, by się ich pozbyć. Dzięki tym zmianom walka mniej skupiała się na idealnym ustawieniu, a bardziej na aktywnym pilnowaniu wieżyczek, ponieważ każda obrona była w końcu przełamywana. Opinie były różne – niektórzy testerzy uważali walkę za zbyt trudną, inni uznali ją za swój ulubiony moment. Kończył się czas, więc ostatecznie nieco ją ułatwiliśmy i wprowadziliśmy do gry, choć nie byliśmy zadowoleni z ostatecznej równowagi."
N/A4099"#commentary\cn_186_meeting_mossman.mp3" "[ Ariel Diaz ] Ponowne spotkanie gracza i Alyx z Mossman po scenie zdrady było trudne, ponieważ wielu graczy uważało, że powinni zastrzelić Mossman na miejscu. Nie mogliśmy na to pozwolić, bo nie mieliśmy czasu na opracowanie alternatywnych wątków fabularnych. Nie chcieliśmy jednak podkreślać, że odbieramy graczom wybór, więc postanowiliśmy ich do tego zniechęcić. Kuloodporne szkło pozwala zyskać czas na dialog między Alyx i Mossman, podczas którego staje się jasne, że Alyx nie uważa zabicia jej za słuszne rozwiązanie."
N/A4100"#commentary\cn_187_eli_in_pod_choreography.mp3" "[ Ken Birdwell ] Napisaliśmy i nagraliśmy dialogi do tej sceny, kiedy wciąż budowaliśmy Nova Prospekt. Na tym etapie wiedzieliśmy, że Alyx i Gordon teleportują się z więzienia, ale nie ustaliliśmy jeszcze żadnych szczegółów, więc dialogi musiały być na tyle ogólne, żeby pasowały do tego, co ostatecznie stworzymy. Przez to skupiliśmy się mniej na działaniach gracza, a bardziej na wrażliwości Alyx i jej relacji z ojcem. Mieliśmy nadzieję, że emocje będą miały większy wpływ na scenę niż sama narracja. Ostatecznie zależało nam, by gracz przejmował się losami tych postaci i chciał nadać priorytet temu, co jest ważne dla Alyx."
N/A4101"#commentary\cn_188_mossman_and_eli.mp3" "[ Bill Van Buren ] Ta scena choreograficzna wymagała wielu poprawek. Chcieliśmy wprowadzić zwrot akcji w środku sceny, jednocześnie nie ograniczając kontroli gracza. Wymagało to delikatnej równowagi, aby zwrot akcji był jasny, ale jednocześnie nieprzerwany. Jeśli gracze podążali za Alyx do konsoli, musieli zrozumieć, co się dzieje, gdy się odwracali. Jeśli zostali z tyłu i obserwowali Mossman, musieli pojąć, co się stało i jednocześnie nie próbować temu zapobiec. Wymagało to wielu modyfikacji i testów, by wszystko zgrało się w czasie, ale ostatecznie zastosowaliśmy kombinację odwrócenia uwagi, szybkiego rozegrania kluczowego momentu oraz wyjaśnienia sytuacji po całym wydarzeniu."
N/A4102"#commentary\cn_189_nova_prospekt_entry.mp3" "[ Danika Rogers ] Gracz właśnie ukończył dwa poziomy pełne walk, więc chcieliśmy nieco zwolnić tempo po wejściu do środka. Te wczesne poziomy zaprojektowano jako zmianę tempa, pozwalającą graczom na zapoznanie się z układem wnętrz Nova Prospekt. Po drodze zaczęliśmy wprowadzać rozgrywkę z wieżyczkami, najpierw jako wroga gracza, a później jako narzędzie, które może wykorzystać. Większość poziomu została zbudowana z prototypów i przestrzeni stworzonych wcześniej w tym projekcie, kiedy skupialiśmy się na kształtowaniu stylu wizualnego Nova Prospekt."
N/A4103"#commentary\cn_190_turret_training_exit.mp3" "[ Doug Wood ] Ta sterta śmieci, wraz z zagraconymi schodami, ma zniechęcić graczy do zabierania ze sobą wieżyczki. Chociaż nie spowodowałoby to żadnych problemów, chcieliśmy ich do tego zniechęcić. Uczynienie z wieżyczki niewygodnego balastu nie jest idealną strategią projektową, ale było to lepsze niż nic. Wielu testerów ostatecznie poddało się i odstawiło wieżyczkę, gdy zrozumieli, że gra próbuje im coś przekazać."
N/A4104"#commentary\cn_191_allied_antlions.mp3" "[ Eric Kirchmer ] Niekończące się ataki mrówkolwów na wieżyczki i żołnierzy oznaczały, że musieliśmy trochę pomyśleć nad rolą gracza w starciach w Nova Prospekt. Gracz zmierzył się już z wieloma żołnierzami Kombinatu, więc uznaliśmy, że walka tutaj będzie bardziej przypominała łamigłówkę i widowisko niż wyzwanie. Mając to na uwadze, stworzyliśmy scenariusze, które pozostawały bez zmian, dopóki gracz nie interweniował. Gracz mógł przechylić szalę zwycięstwa na korzyść mrówkolwów osobiście zabijając wrogów, ale chcieliśmy, by użycie przynęty było wyjątkowo przyjemne. W wielu scenariuszach, gdy gracz rzucał przynętę we wrogów, aktywowaliśmy dodatkowe generatory mrówkolwów, rzucając do walki nową falę. Wynikająca z tego rzeź była nagrodą, a użycie przynęty dawało satysfakcję."
N/A4105"#commentary\cn_192_laser_mines.mp3" "[ Erik Johnson ] Koncepcja laserowych potykaczy w Nova Prospekt przypadła nam do gustu. Była to broń z Half-Life 1, której nie udało nam się dorzucić do Half-Life 2, ale przynajmniej znalazła zastosowanie jako element łamigłówki. Podobało nam się, że służyły za swego rodzaju test moralności, gdy gracz dysponował armią mrówkolwów. Niektórzy gracze natychmiast rzucali przynętę za miny pułapkowe, poświęcając robale, by rozwiązać problem, zaś inni powstrzymywali swoich małych przyjaciół, dopóki nie usunęli bezpiecznie potykaczy innym sposobem. Nie ocenialiśmy ich."
N/A4106"#commentary\cn_193_final_turret_arena.mp3" "[ Erik Johnson ] Projektując przebieg elementu rozgrywki, takiego jak sojusznicze wieżyczki, często najpierw budujemy prototyp punktu końcowego tego elementu. Powtarzamy prototyp, aż testy pokażą, że działa. A potem się cofamy, dodając poprzedzające scenariusze, by wprowadzić element i rozwinąć umiejętności gracza. Wtedy mamy gwarancję, że ostateczny wynik będzie interesujący, zanim poświęcimy na niego za dużo czasu. Poza tym, nim przeszliśmy do tworzenia scenariuszy szkoleniowych, obserwowaliśmy wystarczająco wiele testów, by wiedzieć, które umiejętności wymagają wskazówek, a które gracze opanują naturalnie. Ten ostateczny scenariusz z wieżyczką był naszym celem, kładącym nacisk na obronę z wielu kierunków, wymagającym dynamicznego rozmieszczania wieżyczek i naprawiania ich."
N/A4107"#commentary\cn_194_one_way_drops.mp3" "[ Jakob Jungels ] Gracze nigdy nie wiedzą, co ich czeka, ale znają to, co mają za sobą, więc często wycofują się na znane tereny, gdy napotykają wroga. Jeśli stworzyliśmy arenę, na której miało dojść do starcia – zwłaszcza w przypadku wroga o określonych wymaganiach geometrycznych, takiego jak strażnik mrówkolwów – musimy znaleźć sposób, aby zapobiec tej ucieczce. Często stosowanym rozwiązaniem jest wymaganie od gracza wejścia na arenę przez jednokierunkowy spadek, co zapewne zauważyliście już kilka razy."
N/A4108"#commentary\cn_195_npcs_on_elevators.mp3" "[ Jay Stelly ] Często poświęcamy sporo czasu na rozwiązywanie problemów, których gracze mogą nawet nie zauważyć. Wiele z nich to subtelne wyzwania projektowe, a inne wynikają z interakcji wielu systemów. Na przykład zmuszenie postaci niezależnych do korzystania z wind stanowiło złożony problem, ponieważ wymagało zaangażowania różnych systemów – między innymi sztucznej inteligencji postaci, planowania nawigacji i symulacji ruchu. Dodatkowo sama winda miała swoje własne wymagania symulacyjne, niezwiązane z postaciami. Jednym z bardziej subtelnych wyzwań był fakt, że symulujemy postacie niezależne wolniej niż windy. Oznaczało to, że w zjeżdżającej windzie były symulowane – aby upewnić się, że stoją prawidłowo w windzie – a następnie winda była symulowana kilka razy, za każdym razem poruszając się dalej w dół szybu, dyskretnie pozostawiając postacie w tyle. Potem postać była symulowana po raz drugi i znowu lądowała na podłodze windy. Domyślacie się, że trudno było traktować Alyx poważnie, kiedy ciągle spadała o kilka centymetrów podczas rozmowy z wami."
N/A4109"#commentary\cn_196_looktargets.mp3" "[ John Cook ] Jednym z kluczowych narzędzi projektowych jest Looktarget — niewidoczny punkt w przestrzeni, który aktywuje się, gdy gracz na niego spojrzy. Projektanci mogą określić, jak dokładnie należy na niego spojrzeć, czas trwania spojrzenia i inne warunki. Po aktywacji Looktarget wyzwala różne zdarzenia w grze. Na przykład Alyx może czekać, aż gracz na nią spojrzy, zanim wygłosi swoją kwestię, widowisko może rozpocząć się dopiero wtedy, gdy znajdzie się w polu widzenia, a transportowiec Kombinatu może przelecieć nad graczem, gdy ten patrzy w jego ogólnym kierunku. Po wdrożeniu punktów Looktarget projektanci znaleźli nieskończoną liczbę sposobów ich wykorzystania, by rozgrywka była bardziej niezawodna, zwłaszcza że niektórzy gracze poruszają się z bardzo różną prędkością lub w trudny do przewidzenia sposób."
N/A4110"#commentary\cn_197_nova_prospekt_yard.mp3" "[ John Morello ] Walka na placu Nova Prospekt została w większości zainspirowana wczesnymi obserwacjami walk mrówkolwów z żołnierzami Kombinatu. Wysoka mobilność mrówkolwów i ich ataki wręcz dobrze komponowały się z zabójczą skutecznością żołnierzy na odległość i ich podatnością na ataki z bliska. Mrówkolwy świetnie prezentują się pod ostrzałem, gdy wszędzie widać efekty cząsteczkowe, a kiedy w końcu dopadają żołnierza, ragdoll jest niezwykle satysfakcjonujący."
N/A4111"#commentary\cn_198_vent.mp3" "[ John Morello ] Pewnie już to wiecie, ale jeśli jest jakiś szyb wentylacyjny, to musi być w nim głowokrab. Nie my ustalamy te zasady – podobnie jak same szyby wentylacyjne, nadchodzą prosto z góry."
N/A4112"#commentary\cn_199_kitchen.mp3" "[ Kerry Davis ] Wszyscy twórcy gier wiedzą, że w każdej kuchni w grze musi dojść do wybuchu gazu."
N/A4113"#commentary\cn_200_alyxs_tool.mp3" "[ Laura Dubuk ] Wielofunkcyjne narzędzie Alyx było niezwykle przydatne, ponieważ pozwalało nam wykorzystać ją jako klucz. Często musieliśmy zablokować graczowi drogę, a narzędzie pozwalało Alyx prowadzić dialog podczas otwierania przejścia. Chyba polegaliśmy na tym zbyt często, ale trudno było się oprzeć. Zawsze istnieje kompromis – wykorzystanie Alyx do otwarcia drzwi zamiast tworzenia niestandardowego rozwiązania pozwoliło nam zaoszczędzić czas, który mogliśmy poświęcić na inne, często ważniejsze elementy."
N/A4114"#commentary\cn_201_mossmans_betrayal.mp3" "[ Marc Laidlaw ] Pierwotnie planowaliśmy, że Judith Mossman zdradzi gracza mniej więcej w tym momencie. Jednak kiedy doszliśmy do tej sceny, po opracowaniu innych części gry, uznaliśmy, że bardziej prawdopodobna jest jej chęć ochrony Elia. Wyobrażaliśmy sobie, że zmieni zdanie, gdy zrozumie, że nie może zdradzić Gordona. Mieliśmy pomysły, aby wyjaśnić później tę zmianę, ale ostatecznie nigdy nie ukończyliśmy jej wątku. Podobała nam się niejednoznaczność Mossman, ale gracze najwyraźniej nie podzielali tego entuzjazmu – niemal wszyscy jej nienawidzili. Być może da się to uznać za skuces – ciężko pracowaliśmy, by gracze polubili Alyx, a ona również nie przepadała za Judith."
N/A4115"#commentary\cn_202_d2_prison_05_start.mp3" "[ Yahn Bernier ] Ponieważ gracz mógł przesuwać wiele obiektów, często napotykaliśmy trudności, zwłaszcza biorąc pod uwagę ograniczenia procesorów z 2003 roku. Jednym z tych ograniczeń był system nawigacji SI, który nie rozpoznawał dynamicznych obiektów fizycznych, takich jak te metalowe łóżka. Chociaż system ruchu postaci potrafił wykrywać i omijać obiekty, były one właściwie niewidoczne podczas zapytań nawigacyjnych w trakcie planowania przed ruchem. Wynikało to głównie z ograniczeń wydajnościowych – nie mogliśmy sobie pozwolić na nic bardziej złożonego. Napotkaliśmy też wyzwania bez jasnych rozwiązań, na przykład kwestię reakcji żołnierza, jeśli gracz całkowicie zablokował korytarz dużymi obiektami fizycznymi. By temu zaradzić, nadaliśmy postaciom dodatkową siłę, by mogły przesuwać obiekty. Następnie ograniczyliśmy ten problem poprzez projekt poziomów, poszerzając korytarze i zostawiając wystarczającą wolną przestrzeń, by pomieścić przedmioty lądujące w dowolnym miejscu. Jest to ryzykowne rozwiązanie: połączenie żołnierzy chowających się za łóżkami i mrówkolwów atakujących wręcz oznacza duże prawdopodobieństwo niepożądanych interakcji między systemem ruchu a łóżkami."
N/A4116"#commentary\cn_203_alyx_as_companion.mp3" "[ Miles Estes ] Ta sekcja stała się niezamierzonym prototypem tego, co ostatecznie pojawiło się w Epizodzie 1: Alyx jako towarzyszka, płynnie poruszająca się po ścieżce, łącząc dynamiczną walkę z oskryptowaną choreografią. Nie mieliśmy jeszcze jasnej wizji tego, jak dopasować ją do gracza w tych scenariuszach, ale nawet ta krótka chwila była dobrą nauką, mimo że nie mieliśmy dość czasu, by ją dopracować."
N/A4117"#commentary\cn_204_laundry.mp3" "[ Mike Dussault ] Kiedy gracz dociera do poziomu zwanego Pralnią, mamy pewność, że swobodnie używa przynęty do rozstrzygnięcia starć. Chcieliśmy więc nieco podnieść poprzeczkę, tworząc scenariusz, który zachęca do jeszcze większego wysiłku, łącząc przynętę z pełnym zestawem broni."
N/A4118"#commentary\cn_205_side_zombie.mp3" "[ Quintin Doroquez ] Ten trujący zombie zawsze był kluczowym elementem w testach gry. Gracze, skupieni na żołnierzach Kombinatu, mrówkolwach i wieżyczkach, od dłuższego czasu nie widzieli trującego zombie, więc jego nagłe pojawienie się w ciemności często wywoływało szok."
N/A4119"#commentary\cn_206_flares.mp3" "[ Quintin Doroquez ] Ta sekcja to miłe przeciwieństwo poprzedniego segmentu z wieżyczkami, jeśli chodzi o koszty produkcji i iteracji. Powstała późno, ale szybko nabrała kształtu, bo sztuczna inteligencja Alyx i żołnierza Kombinatu była już dopracowana. Podobała nam się ciemność i flary, więc odłożyliśmy całość na później jako coś, co warto rozwinąć w przyszłości. Wróciliśmy tutaj podczas planowania ciemnych sekcji w Epizodzie 1."
N/A4120"#commentary\cn_207_magic_wall.mp3" "[ Robin Walker ] Podobnie jak w przypadku wielu naszych aren, potrzebowaliśmy jakiejś bramy, by zablokować graczom przejście aż do zakończenia walki. Niestety, nie mieliśmy już czasu i musieliśmy przejść do Dworca, więc skończyło się na tym magicznej bzdurce: ścianie, która po pokonaniu drugiej kanonierki po prostu eksploduje, torując drogę. Pocieszaliśmy się, że większość graczy tego nie zauważy, ponieważ będą zajęci walką z kanonierkami, a nasze testy wykazały, że zazwyczaj wszyscy kończą starcie, nim dotrą do tego miejsca. Dzięki wystarczającej liczbie eksplozji na całej arenie zniszczona, płonąca ściana wyglądała całkiem naturalnie, więc dodaliśmy po drugiej stronie kilka prostych zagadek z gazem, aby to uzasadnić. Ale nie, nie jesteśmy z tego dumni."
N/A4121"#commentary\cn_208_ragdoll_vortigaunt.mp3" "[ Scott Dalton ] Widok tego martwego Wortygonta jest bolesny – dla naszych projektantów poziomów. W tamtym czasie narzędzia programistyczne nie pozwalały nam bezpośrednio ustawiać pozycji ragdoll, co oznacza, że kiedy NPC ginął i upadał na ziemię, nie mieliśmy żadnej kontroli nad tym, w jakiej pozycji się znajdzie. Gdybyśmy mieli trochę czasu, animatorzy mogliby nam dać pojedynczą klatkę animacji w zakładanej pozie, ale byliśmy spóźnieni, a nasz mały zespół animatorów był już przeciążony. Projektant poziomów umieścił więc Wortygonta nad tym krzesłem, kazał mu umrzeć podczas ładowania poziomu i czekał, aby zobaczyć, w jakiej pozycji ustawi się ragdoll. Potem lekko przesunął Wortygonta i spróbował ponownie. Nie pamiętamy dokładnie, ile prób to zajęło, ale na pewno więcej niż myślicie."
N/A4122"#commentary\cn_209_nova_prospekt_process.mp3" "[ Eric Smith ] Podobnie jak Ravenholm, Nova Prospekt został początkowo zaprojektowany z myślą o znacznie innej rozgrywce niż ta ostateczna. Pierwsza wersja skupiała się na walce z żołnierzami Kombinatu, bez udziału mrówkolwów. W przeciwieństwie do innych obszarów, gdzie rozgrywka i grafika ewoluowały razem, Nova Prospekt otrzymał duże wsparcie graficzne już na wczesnym etapie. Dzięki temu powstał zestaw dopracowanych wielofunkcyjnych sekcji geometrii z już zaimplementowaną grafiką. Złożenie Nova Prospekt z tych elementów przebiegło sprawnie, ponieważ układ więzienia był naturalnie powtarzalny. Później, kiedy powróciliśmy z mrówkolwami i przynętą, musieliśmy zmienić przeznaczenie geometrii, aby dopasować ją do nowej rozgrywki."
N/A4123"#commentary\cn_210_d2_prison_04.mp3" "[ Eric Kirchmer ] W procesie twórczym graficy projektowali małe pionowe fragmenty otoczenia, które nazwaliśmy „zoo graficznymi”. Zoo określały sposób wykorzystania tekstur i przedmiotów do tworzenia przestrzeni spełniających założone cele wizualne. Jednak podczas tworzenia toru rozgrywki powtarzalny układ więzienia pozwolił nam na bezpośrednie wykorzystanie grafiki. Ta mapa z początku powstała jako główne zoo graficzne dla Nova Prospekt, ale po wykorzystaniu jej do testowania prototypów – w tym tych, które ostatecznie doprowadziły do powstania przynęty – stała się częścią faktycznej architektury poziomu."
N/A4124"#commentary\cn_211_autosave_dangerous.mp3" "[ Dave Riller ] W Half-Life 1 mieliśmy zestaw automatycznych zapisów w całej grze, ręcznie umieszczonych przez projektantów poziomów i uruchamianych, gdy gracz dotarł do określonego momentu lub miejsca. Dzięki temu gra zapisywała się automatycznie podczas przemierzania korytarzy Black Mesy. W Half-Life 2 potrzebowaliśmy nowego narzędzia. Problem pojawił się w niektórych bardziej złożonych arenach. Kilka starć trwało dość długo i obejmowały wiele grup przeciwników. Inne były długimi, rozległymi mieszankami eksploracji i walki bez wyraźnego rozdzielenia tych dwóch elementów. Nie chcieliśmy, by automatyczny zapis następował w momencie, gdy gracz był narażony na śmierć zaraz po załadowaniu gry, ponieważ mogłoby to doprowadzić do tak zwanej pętli śmierci – ci, którzy pamiętają gry z tamtych czasów, na pewno kojarzą takie sytuacje. Dlatego też, o ile nie wprowadziliśmy celowo przerw w przebiegu każdego starcia, nie zawsze mieliśmy bezpieczne miejsce na umieszczenie autozapisu. Po kilku eksperymentach wdrożyliśmy funkcję o nazwie „Niebezpieczny autozapis”. To narzędzie dla projektantów poziomów, które łączyło automatyczne zapisywanie z powiązanym przedziałem czasowym. Po uruchomieniu przez projektanta, zapis następował natychmiast, ale był przechowywany poza rozgrywką i nie dało się go wczytać. Jeśli gracz pozostał przy życiu przez określony czas, plik był zatwierdzany i używany jako najnowszy automatyczny zapis. Pozwalało to projektantom umieścić automatyczny zapis w rozsądnym miejscu lub momencie na arenie, określić czas, na przykład trzydzieści sekund, i jeśli gracz pozostawał przy życiu pół minuty, autozapis stawał się użyteczny."
N/A4125"#commentary\cn_212_we_dont_go_to_ravenholm.mp3" "[ Dario Casali ] Kiedy zakończyliśmy pracę nad Ravenholm, nie mogliśmy pozbyć się wrażenia, że przejście z laboratorium Elia po prostu nie działało. Było zbyt gwałtowne – laboratorium łączyło się bezpośrednio z ulicami miasta, do którego wkrótce się udacie, a sekcja, w której się znajdujecie, nie istniała. W zakończeniu laboratorium podkreśliliśmy, że „Tam nie wracamy” i podobała nam się stworzona atmosfera. Jednak, gdy gracz dotarł do Ravenholm, natychmiast musiał stoczyć walkę z zombie, nie było czasu na budowanie napięcia. Dlatego stworzyliśmy tę sekcję i kolejne wąskie korytarze, aby naprawić ten problem w satysfakcjonujący sposób. Spowolniliśmy tempo, skupiliśmy się na grafice i oświetleniu i przygotowaliśmy graczy do poznania odpowiedzi, dlaczego nie wracamy do Ravenholm."
N/A4126"#commentary\cn_213_lever_shenanigans.mp3" "[ Dario Casali ] Mimo wszystkich starań, aby gracze zrozumieli związek między tą dźwignią a ogrodzeniem elektrycznym, niektórzy testerzy nadal przełączali dźwignię, nie wiedząc, co zrobili. Nawet chodzili po okolicy, ponownie przełączali dźwignię i znów się błąkali. Ponieważ nie mieliśmy wiele czasu, aby wyjaśnić ten związek, zdecydowaliśmy się po prostu oderwać dźwignię. Zapobiegło to cofnięciu postępów graczy i wzmocniło wrażenie, że Ravenholm jest niepewnym i rozpadającym się środowiskiem."
N/A4127"#commentary\cn_214_town_arenas.mp3" "[ Dario Casali ] W tym punkcie Ravenholm gracz poznał już wszystkie dostępne elementy rozgrywki i potrafi przewidzieć ich interakcje. Dzięki temu możemy tworzyć bardziej złożone sytuacje, podwyższając poziom zagrożenia i większą swobodę w podejściu gracza do każdego scenariusza. Ta arena jest celowo zagmatwaną przestrzenią, którą gracz musi zbadać, a my wykorzystujemy ten czas na powolne zwiększanie intensywności starcia. Im szybciej gracz bada arenę, tym szybciej podwyższamy trudność. Otwarty charakter areny utrudniał jej dostosowanie, ponieważ gracze mieli dużą swobodę w podejściu do napotkanych tu wyzwań."
N/A4128"#commentary\cn_215_mines.mp3" "[ Dario Casali ] Skomplikowana trasa, którą trzeba pokonać, by bezpiecznie przedostać się przez szyb kopalni, daje graczowi mnóstwo czasu, by zobaczyć, co czeka go na dole. I niespodzianka: są to głowokraby. Szczerze mówiąc, zwykle są to głowokraby. Ale w tym przypadku są to trujące głowokraby, które same w sobie są interesujące, ale największe emocje wywołują w połączeniu z szybkim wariantem. Te dwa stworzenia to świetna kombinacja: żadne nie jest szczególnie niebezpieczne samotnie, ale razem są niezwykle zabójcze. Po zatruciu wystarczy jedno uderzenie szybkiego głowokraba, by zabić gracza. I to właśnie biolodzy nazywają symbiozą. Przynajmniej tak nam się wydaje."
N/A4129"#commentary\cn_216_poison_headcrabs.mp3" "[ David Speyrer ] W tym pomieszczeniu nieumyślnie wprowadzono trujące głowokraby. Długo myśleliśmy nad ich odpowiednią prezentacją w dalszej części poziomu, ale kiedy zobaczyliśmy, jak dobrze sprawdzają się podczas testów, emocje wzięły górę i wkrótce rozrzuciliśmy je po całej okolicy. Gdy zorientowaliśmy się, że pojawiły się przed faktycznym wprowadzeniem, było już za późno, by to zmienić. Na szczęście ciasne pomieszczenie pełne trujących głowokrabów to niezłe szkolenie, ponieważ ich projekt pozwala uniknąć typowego problemu związanego z treningiem bojowym. Zwykle gracze są zestresowani i wielokrotna śmierć ich frustruje, gdy nie rozumieją, dlaczego giną. Tak, napotkaliśmy ten problem, próbując szkolić gracza przy użyciu trujących głowokrabów, jak i ich źródła, czyli trujących zombie. Jednak trujące głowokraby same w sobie nie mogą zabić gracza. Chociaż sytuacja jest stresująca, pomieszczenie pełne tych stworzeń pozwala przynajmniej uniknąć frustracji."
N/A4130"#commentary\cn_217_poison_zombie_introduction.mp3" "[ David Speyrer ] Ograniczenie gracza w ciasnej przestrzeni, zapewniając mu jednocześnie widok na zewnątrz, skutecznie zwiększa prawdopodobieństwo, że zauważy coś, co chcemy mu pokazać. W tym przypadku zwracamy uwagę jękiem, zanim trujący zombie stanie się widoczny. Pierwotnie spotkanie to było również pierwszym, w którym gracze mieli do czynienia z trującymi głowokrabami, ale, jak wspomnieliśmy wcześniej, zbytnio entuzjastycznie podeszliśmy do rozmieszczenia trujących głowokrabów na tym poziomie i ostatecznie zepsuliśmy ich wspólne wprowadzenie w tym miejscu. Ostatecznie jednak te pierwsze starcia i tak lepiej sprawdziły się oddzielnie."
N/A4131"#commentary\cn_218_final_arena.mp3" "[ Eric Smith ] Kiedy zakończyliśmy pierwsze sprawdzenie poziomów Ravenholm, ten dach miał być miejscem kulminacyjnej bitwy. Podobnie jak inne przestrzenie w Ravenholm, początkowo był to obszar zaprojektowany głównie pod względem wizualnym. Uznaliśmy, że gracz opuszczający miasto powinien mieć chwilę, by spojrzeć na miejsce, z którego się wydostał i rzucić okiem na cel, do którego zmierza. Wiele grup projektujących rozgrywkę próbowało stworzyć tutaj starcie, ale ciasna geometria i ograniczenia wydajności sprawiły, że nigdy nie udało nam się opracować finału, z którego bylibyśmy zadowoleni. Tak jak w przypadku samej sagi Half-Life, wydawało się, że Ravenholm nie doczeka się prawdziwego zakończenia."
N/A4132"#commentary\cn_219_tables_and_bodies.mp3" "[ Ido Magal ] Pod koniec tworzenia Ravenholm, kiedy wszystkie główne elementy były już na swoim miejscu, przejrzeliśmy całość i spróbowaliśmy wypełnić każdą pustą przestrzeń czymś ciekawym. Musieliśmy uważać, aby wykorzystać to, co już mieliśmy i nie tworzyć niczego nowego, ponieważ nie mogliśmy ryzykować wprowadzenia kolejnych błędów. Często, tak jak w tym pomieszczeniu, staraliśmy się dodać nowe elementy rozgrywki, a jednocześnie wzbogacić obszar o więcej szczegółów i fabuły. Takie małe scenki pozwalają uważnym graczom zastanowić się nad tym, co widzą i co może spotkać ich później."
N/A4133"#commentary\cn_220_physics_object_consistency.mp3" "[ Kerry Davis ] Wszystkie obiekty fizyczne mają różne parametry, które określają ich zachowanie: masę, ilość obrażeń, jaką mogą przyjąć przed zniszczeniem, na co się rozpadają i tak dalej. Podczas tworzenia gry parametry te były określane przez projektantów poziomów dla każdego elementu, co miało wpływ na działanie większości przedmiotów w grze. Jednak w późniejszym etapie zdaliśmy sobie sprawę, że stworzyliśmy problem – w grze były tysiące obiektów fizycznych i nie było szans, by były ze sobą spójne. W efekcie kartonowe pudło mogło rozpaść się po jednym strzale z pistoletu na jednym poziomie, a na innym być niezniszczalne. Wewnętrznie nazywaliśmy te niespójności „zbrodniami projektantów poziomów”. Aby to naprawić, stworzyliśmy system, który egzekwował spójność wszystkich obiektów fizycznych w oparciu o ich model wizualny. Ponieważ większość gry była gotowa, projektanci musieli zrezygnować z tego rozwiązania w skrajnych przypadkach, gdy musieli popełnić „zbrodnię”, aby zachować to, co zaprojektowali. Wewnętrznie nazywamy tych projektantów recydywistami, a niektórzy z nich do dziś kontynuują swoją przestępczą działalność w Valve."
N/A4134"#commentary\cn_222_fast_zombie_introduction.mp3" "[ Randy Lundeen ] Ta przestrzeń była kolejnym obszarem wstępnie stworzonym na targi E3 2003, gdzie prezentowano walkę gracza z żołnierzami Kombinatu. Kiedy powróciliśmy do niej, by wprowadzić szybkie zombie, staraliśmy się zachować jak najwięcej z pierwotnego projektu. Chcieliśmy uzyskać charakterystyczne ujęcie w świetle księżyca, z zombie przeskakującymi przed nim jak wilkołaki, by przyciągnąć wzrok gracza. Po zakończeniu sekwencji przedstawialiśmy pierwszego szybkiego zombie graczowi i wysyłamy go w jego kierunku. Znalezienie odpowiedniej równowagi oświetlenia, by scena wyglądała dobrze, a jednocześnie spełniała cele rozgrywki, wymagało wielu poprawek."
N/A4135"#commentary\cn_223_ravenholm_gameplay_focus.mp3" "[ Mike Dussault ] Po obejrzeniu wielu testów Ravenholm wiedzieliśmy, że podstawą rozgrywki na tym poziomie jest działo grawitacyjne i fizyka. Mając tę wiedzę, czuliśmy, że możemy odpowiednio zbudować przejście do Ravenholm i pomóc graczowi nauczyć się i zrozumieć, czego może się spodziewać. Takie sytuacje zdarzają się często – budujemy ścieżkę poziomu, ustalamy, co działa, a następnie projektujemy prolog. Zbudowaliśmy ten układ pomieszczeń, mając na uwadze ten scenariusz. Brutalność narzędzi, które udostępniamy graczowi, pomagała w stworzeniu atmosfery, do której dążyliśmy, zmieniając ton z bezpiecznego laboratorium Elia na coś mroczniejszego i przerażającego."
N/A4136"#commentary\cn_224_player_tools.mp3" "[ Steve Bond ] W tym momencie gracze mają już spore doświadczenie z fizyką Half Life 2, ale właśnie otrzymali działo grawitacyjne, które umożliwia zupełnie nowe interakcje z obiektami fizycznymi. Przetestowaliśmy różne przedmioty, którymi gracz mógł się bawić. Były to między innymi piły tarczowe, katapulty, wybuchowe kanistry, pułapki, włócznie i tak dalej. Wybraliśmy te, które dobrze współpracowały z bronią opartą na fizyce i usunęliśmy te niespełniające oczekiwań. Potem pozbyliśmy się amunicji z poziomów, by przetrwanie gracza zależało od tych obiektów."
N/A4137"#commentary\cn_225_contrived_setups.mp3" "[ Kerry Davis ] W wielu ćwiczeniach z działem grawitacyjnym i obiektami fizycznymi widać dość oczywistą sztuczność. Gracz wyciąga piłę z ściany za pomocą działa, w tym samym momencie zza rogu wyłania się zombie i aż prosi się, żeby rzucić w niego piłą. Potem gracz czołga się pod obracającą się pułapką z ostrzami, by ją wyłączyć i nagle pojawiają się trzy zombie, prowokując gracza do ponownego włączenia pułapki. Nie mieliśmy czasu na dopracowanie tej sekcji, więc potrzebowaliśmy rozwiązań, które sprawdzą się w przypadku wszystkich graczy, a nie tych bardziej otwartych, które wymagałyby od nich wykonania „właściwego” działania. Chociaż taki projekt może ograniczać kreatywność graczy, tutaj okazało się, że nie mieli nic przeciwko temu, że zmusiliśmy ich do określonego działania."
N/A4138"#commentary\cn_226_misteaching_flinches.mp3" "[ Kerry Davis ] Kolejny zapadający w pamięć test i przykład niebezpieczeństwa wynikającego z niewłaściwego szkolenia graczy miał miejsce w Ravenholm. Jedną z naszych zasad projektowych jest to, by gra w jak największym stopniu reagowała na działania gracza. Podczas projektowania działa grawitacyjnego wydawało się oczywiste, że jeśli gracz wyceluje je w zombie i pociągnie za spust, coś powinno się wydarzyć. Wystarczyło sprawić, by broń zadawała niewielkie obrażenia, powodując, że zombie się cofał, co wyglądało dobrze i wywoływało reakcję. Później obejrzeliśmy test, w którym tester odkrył tę interakcję natychmiast po przybyciu do Ravenholm i zinterpretował ją jako informację zwrotną, że działo grawitacyjne rani zombie… co było prawdą, ale nie do końca. Gracz strzelił w zombie wielokrotnie, rażąc wroga aż do śmierci. Jest to powolny, nieprzyjemny i nieludzki sposób walki z zombie, zwłaszcza gdy otaczają was piły i wybuchowe kanistry. Wyciągając wnioski z tej lekcji, usunęliśmy animację cofnięcia się, mimo że oznaczało to utratę interakcji między zombie a działem grawitacyjnym. W tym przypadku lepiej było zrezygnować z prostej interakcji, niż stwarzać fałszywe wrażenie, że działo grawitacyjne jest skutecznym sposobem walki. Nawet proste zasady mogą wymagać kompromisów, gdy zagłębimy się w szczegóły."
N/A4139"#commentary\cn_227_fire_trap.mp3" "[ Steve Bond ] Ta pułapka ogniowa miała pierwotnie służyć jako wizualny element systemu przeciwpożarowego, ale projektant poziomów zmienił jej przeznaczenie i wykorzystał ją jako element rozgrywki w Ravenholm. Podczas projektowania była ona wielokrotnie usuwana ze względu na wpływ na wydajność słabszych komputerów ze względu na nadmiar przezroczystych sprite’ów. Ostatecznie znalazł się programista, który uznał, że jest to ważny element rozgrywki, więc warto rozwiązać problemy z wydajnością i zadbać o to, by ogień znalazł się w grze."
N/A4140"#commentary\cn_228_hallway_cupboards.mp3" "[ Yahn Bernier ] Wypełnione śmieciami korytarze były prostym rozwiązaniem spowalniającym gracza. Ze względu na ograniczenia związane z zachowaniem jak największej części istniejącej geometrii oraz powolnymi zombie jako głównymi przeciwnikami, trudno było powstrzymać graczy przed ominięciem całości biegiem. Na szczęście Grigori, szalony mieszkaniec Ravenholm, uzasadniał te rozwiązania – to logiczne, że zablokował klatkę schodową, aby zabezpieczyć swoją pozycję na dachu. Ostatecznie rozwiązanie Grigoriego i nasze były takie same: po prostu zawaliliśmy przejście meblami, ponieważ jeśli powstrzyma to zombie, prawdopodobnie spowolni też gracza."
N/A4141"#commentary\cn_229_pacing_switch.mp3" "[ Steve Bond ] Skoro gracze zaliczyli już sekcję szkoleniową, możemy zacząć zmieniać tempo gry, przechodząc od ponurych, klaustrofobicznych przestrzeni do aren bardziej nastawionych na walkę. Gdy gracz zapoznał się już z różnymi narzędziami fizycznymi dostępnymi w otoczeniu, możemy zacząć łączyć je z otwartymi przestrzeniami i po prostu dać swobodę wyboru metod działania."
N/A4142"#commentary\cn_230_car_crushers.mp3" "[ Steve Bond ] Prasy samochodowe wymagały pewnych poprawek i sporo pracy nad naszym systemem fizycznych uszkodzeń. Interakcja dużych obiektów z postaciami niezależnymi zawsze stanowi wyzwanie. Na przykład, jeśli fizyka popchnie postać, może ona znaleźć się w miejscu, w którym nie powinna, uniemożliwiając jej powrót do poprzedniego położenia. Nie jest to duży problem w przypadku takich obiektów jak głowokrab, które mogą po prostu wyskoczyć z trudnej sytuacji, ale w przypadku zombie może to oznaczać, że utkną i będą bezradne, miotając się w miejscu. To zabija klimat horroru, który chcemy tutaj osiągnąć."
N/A4143"#commentary\cn_231_car_crusher_lifts.mp3" "[ Eric Smith ] Podniesienie gracza przez prasy samochodowe również było wyzwaniem. Gracz jest zawsze symulowany przez systemy fizyki i ruchu. Za każdym razem, gdy aktualizujemy stan gracza, porównujemy wyniki z obu systemów i decydujemy, który z nich jest „prawidłowy”, a potem synchronizujemy je i powtarzamy. Dzięki temu oba systemy mogą na siebie oddziaływać — na przykład, gdy gracz staje na huśtawce, fizyka powoduje, że deska się ugina, a gdy staje na prasie samochodowej, ta go podnosi. Chociaż jest to złożona metoda, oparcie jej na dwóch systemach było łatwiejsze w kalibracji niż próba obsługi zarówno fizyki, jak i ruchu jednocześnie. Dzięki rozdzieleniu tych elementów mogliśmy precyzyjnie dostosować ruch, by działał dobrze samodzielnie, a potem synchronizować oba systemy tylko wtedy, gdy fizyka miała wpływ na gracza."
N/A4144"#commentary\cn_232_paint_cans.mp3" "[ Steve Bond ] Kiedy działo grawitacyjne i fizyka stały się podstawą rozgrywki w Ravenholm, zaczęliśmy przeglądać poziomy i szukać obiektów, które mogliśmy przeoczyć, ponieważ byliśmy zajęci pracą nad naprawdę groźnymi elementami, takimi jak ostrza pił i wybuchające kanistry. Jedną z rzeczy, które znaleźliśmy, była puszka z farbą. Było to na tyle proste, że mogliśmy podkreślić oczekiwania graczy, sprawiając, że rzucane puszki rozpryskiwały farbę na zombie."
N/A4145"#commentary\cn_233_bringing_physics_to_the_enemies.mp3" "[ Tom Leonard ] Pułapki fizyczne w Ravenholm były jednymi z pierwszych elementów rozgrywki na tym poziomie, z których byliśmy naprawdę zadowoleni, ale brakowało w nich wpływu gracza. To właśnie piły pomogły nam zrozumieć, o co naprawdę chodzi w Ravenholm. Dzięki nim gracz mógł wykorzystać fizykę przeciwko zombie, zamiast wprowadzać zombie na obiekty fizyczne. Kiedy to zrozumieliśmy, Ravenholm szybko ewoluowało. Przeszukiwaliśmy mapę w poszukiwaniu rzeczy, zwłaszcza nietypowych, które mogłyby posłużyć jako narzędzie lub broń."
N/A4146"#commentary\cn_234_ravenholm_development.mp3" "[ Tom Leonard ] Rozpoczęliśmy prace nad Ravenholm na wczesnym etapie produkcji Half-Life 2, więc przeszła ono więcej niż jedną pełną fazę rozwoju. Pierwsza wersja powstała przed pojawieniem się działa grawitacyjnego, a rozgrywka skupiała się na tradycyjnej walce z zombie przy użyciu broni palnej i kilku pułapek fizycznych. Planowaliśmy nawet zaprezentować Ravenholm na targach E3 w 2002 roku, ale ostatecznie gra została pokazana rok później, w 2003. Już zainwestowaliśmy sporo zasobów w grafikę Ravenholm, czego zwykle unikamy, póki rozgrywka nie zostanie w pełni sprawdzona. Kiedy więc wróciliśmy do Ravenholm z mechaniką działa grawitacyjnego, pracowaliśmy z wieloma istniejącymi geometriami poziomów, które zaprojektowano z myślą o zupełnie innej rozgrywce."
N/A4147"#commentary\cn_235_grigori_plaza.mp3" "[ Steve Bond ] Ten otwarty plac jest jednym z obszarów opracowanych szczegółowo podczas pierwszej fazy rozwoju. Kiedy do niego wróciliśmy, chcieliśmy zachować jak najwięcej istniejącej grafiki, jednocześnie projektując nową ścieżkę rozgrywki, wykorzystującą wszystkie trzy wymiary, przemieszczając graczy na górę i w dół przez okna, po dachach, między budynkami. Nie była to duża przestrzeń, więc musieliśmy wycisnąć z niej jak najwięcej. Ponieważ z początku był to obszar skupiony na grafice, nie miał on większego znaczenia dla rozgrywki i musieliśmy rozwiązać pewien problem – testerzy często mijali go biegiem. Co więcej, już wtedy przekraczał on możliwości renderowania i nie pozostawiał miejsca na nic nowego. Wyzwaniem stało się znalezienie niewielkich elementów, które spowolniłyby gracza, choćby zagrożeń za rogami i w każdym zakamarku poziomu."
N/A4148"#commentary\cn_236_ravenholm_development_2.mp3" "[ Tom Leonard ] W rozmowach o Half-Life 2 fani często mówią, że najlepiej zapamiętali Ravenholm. Dzięki wielokrotnym zmianom w trakcie tworzenia i nagromadzeniu elementów, przy Ravenholm pracowało więcej członków zespołu niż gdziekolwiek indziej. To właśnie tam ustaliliśmy, jak zastosować nasze artystyczne rozwiązania do scenografii i zamierzonej atmosfery, jak fizyka i rozgrywka łączą się z działem grawitacyjnym, jak głowokraby i zombie muszą ewoluować w Half-Life 2 i tak dalej. Patrząc na to z perspektywy czasu tylko utwierdziliśmy się, że indywidualne zaangażowanie przeważa nad scentralizowaniem projektu. Ravenholm jest pełne atrakcji, spełnia wymogi wydajności i kierunku artystycznego, a także stanowi sumę niewielkich wkładów wielu osób, które potrafiły wykorzystać swoje umiejętności, by zdziałać więcej, niż zakładał projekt."
N/A4149"#commentary\cn_237_playtester_archetypes.mp3" "[ Tom Leonard ] Iteracje i regularne testy gry były siłą napędową produkcji Half-Life 2. Co tydzień po cichu obserwowaliśmy gracza przechodzącego sekcję, nad którą pracowaliśmy, notując co działa, a co nie. Stawialiśmy na testy z graczami o różnych poziomach umiejętności, aby mieć pewność, że nie podejmujemy decyzji, które sprawdzą się tylko w przypadku niektórych osób. Z czasem nauczyliśmy się wybierać konkretne typy testerów w zależności od aktualnego etapu rozwoju. Na początku korzystaliśmy z pomocy doświadczonych graczy, zazwyczaj członków zespołu, którzy potrafili poradzić sobie z niedopracowanymi, niedokończonymi obszarami i dobrze wyjaśniali swój tok myślenia. Do testowania walki szukaliśmy graczy o różnych zdolnościach, zwłaszcza tych kreatywnie korzystających z narzędzi. W końcu, gdy sekcje były bardziej dopracowane, skupiliśmy się na początkujących – osobach, które nie grały zbyt często lub nie były zaznajomione z strzelankami pierwszoosobowymi. Nawet jeśli niekoniecznie kupiliby naszą grę, często mogliśmy się czegoś od nich nauczyć."
N/A4150"#commentary\cn_238_the_real_final_arena.mp3" "[ Tom Leonard ] Pod koniec prac nad Half-Life 2, kiedy sprawdzaliśmy całą grę w poszukiwaniu ostatnich możliwych ulepszeń, zdecydowaliśmy, że naprawdę przyda nam się faktyczny finał dla Ravenholm. Walka na dachu nie była wystarczająca. Po dyskusji zdecydowaliśmy się dodać finałowe starcie na cmentarzu, w którym Grigori pomaga graczowi. Było to ryzykowne dla produkcji, ale czuliśmy, że gra tego potrzebuje. Ponieważ byliśmy już blisko końca prac, mieliśmy do dyspozycji sprawdzony zestaw narzędzi do tworzenia rozgrywki, a co ważniejsze, w tym momencie rozumieliśmy już nasz produkt. Tworzenie gry często polega na uczeniu się, co tak naprawdę się tworzy. Dlaczego nasza gra jest fajna? Czym się wyróżnia? Jakie są jej najważniejsze elementy? Tworząc grę i obserwując testerów, poznaliśmy odpowiedzi na te pytania, a tym samym staliśmy się lepsi w jej tworzeniu. Cmentarz powstał więc szybko i wymagał znacznie mniej iteracji niż wiele wcześniejszych obszarów."
N/A4151"#commentary\cn_239_cities.mp3" "[ Eric Kirchmer ] Jednym z trudniejszych wyzwań w tej sekcji było wymyślenie, jak stworzyć wrażenie przebywania w dużym mieście, gdy nasze możliwości techniczne nie pozwalały na renderowanie czegoś takiego. Przez to skupiliśmy się na ciasno ustawionych kamienicach, podziemnych garażach, tunelach metra, przepustach i tym podobnych. Wszystkie te miejsca znajdują się w miastach, ale zazwyczaj zasłaniają horyzont. Potem uzupełniliśmy ten styl projektowania poziomów o lokalizacje widokowe, w których całą przestrzeń przeznaczyliśmy na zaprezentowanie graczowi rozległej perspektywy. W tych miejscach mogliśmy poświęcić cały nasz budżet wydajności na widok i nie musieliśmy oszczędzać go na sztuczną inteligencję wrogów lub walkę."
N/A4152"#commentary\cn_240_strider_4.mp3" "[ Eric Smith ] Chociaż to mapa produkcyjna stworzoną dla stępacza, nadal mieliśmy oryginalną wersję do testowania jego sztucznej inteligencji. Uważaliśmy, że dobra mapa testowa dla sztucznej inteligencji ma ogromną wartość, gdyż pozwala szybko wypróbować nowe pomysły dotyczące rozgrywki i łatwo je dostosować. Gdy pojawiają się błędy lub problemy, można je szybciej izolować i poprawić. Jeśli sztuczna inteligencja działa prawidłowo, przenosimy ją do map produkcyjnych, by projektanci poziomów mogli z niej korzystać. Mapa testowa stępacza zawierała zarysy zniszczonych budynków oraz nieskończoną liczbę postaci pojawiających się w różnych miejscach i na różnych wysokościach, by zapewnić stały napływ celów. To pozwoliło nam udoskonalić sztuczną inteligencję stępacza i jego postawę, by wzbudzał ciekawość i emocje, nawet jeśli tylko obserwuje się jego działania."
N/A4153"#commentary\cn_241_perf_arena.mp3" "[ Aaron Seeler ] Ta arena to duże wyzwanie dla wydajności. Jej rozmiar oraz połęczenie sztucznej inteligencji stępaczy i mieszkańców wystawiły nas na ciężką próbę. Kiedy przenosiliśmy Half-Life 2 na Xboxa, musieliśmy wprowadzić kilka zmian projektowych. Zachowanie pierwotnego zamysłu i zapewnienie graczom takich samych wrażeń z ograniczonymi narzędziami i przestrzenią było trudnym zadaniem."
N/A4154"#commentary\cn_242_space_re-use.mp3" "[ Chris Green ] Powrót do tej przestrzeni przyniósł wiele korzyści. Pierwsza jest oczywista – koszty produkcji nowych obszarów są zawsze wysokie, więc wolimy dodać więcej elementów rozgrywki do istniejących lokacji. Ale w przypadku tak trudnej walki, w której gracz mierzy się z wieloma stępaczami, ponowne wykorzystanie ma dodatkowe zalety. Ponieważ gracze już tu byli, znają układ areny. Tym razem poruszają się w odwrotną stronę, ale ścieżka w dużej mierze pokrywa się z pierwotną trasą. Znajomość terenu jest przydatna, gdy gracze muszą iść naprzód, by zdobyć zasoby potrzebne do walki. Miasto 17 zniszczone przez wojnę pozwoliło nam dostosować osłony i dodać mniejsze przeszkody na trasie, dzięki czemu otoczenie pozostaje dynamiczne i zaskakujące."
N/A4155"#commentary\cn_243_tenements_and_courtyards.mp3" "[ Danika Rogers ] Wykorzystaliśmy wiele sztuczek i stworzyliśmy różne funkcje, by gracze mieli wrażenie, że w mieście trwa wojna. Większość pracy polegała na zaprezentowaniu graczom potyczek lub odgłosów odległych walk. Dzięki funkcji Looktarget za każdym razem, gdy gracz wyglądał przez okno, coś się działo, a narzędzia takie jak Tracer Maker pozwalały projektantom tworzyć smugi pocisków między dwoma punktami. W połączeniu z udźwiękowieniem tworzyliśmy wrażenie dwóch grup wrogów prowadzących wymianę ognia, bez konieczności uruchamiania sztucznej inteligencji. Opracowaliśmy również krótkie historie dla mieszkańców, których można dostrzec wielokrotnie, przechodząc poziom. Wszystkie te momenty zostały dopracowane podczas testów, byśmy mieli pewność, że jak najwięcej graczy będzie mogło ich doświadczyć."
N/A4156"#commentary\cn_244_hopper_mine_training.mp3" "[ Dario Casali ] Ta blacha falista została celowo umieszczona nad otworem, by zachęcić graczy do przełączenia się na działo grawitacyjne i usunięcia przeszkody. Jest to pewna manipulacja z naszej strony, ponieważ stwierdziliśmy, że szkolenie z radzenia sobie ze skaczącymi minami przebiegało znacznie lepiej, jeśli gracze od razu próbowali użyć na nich działa grawitacyjnego, a blacha znacznie zwiększała szansę, że będą mieli je pod ręką. Umieściliśmy w otworze wiele min, by gracze mieli kilka okazji do interakcji, zwiększając szanse, że odkryją inne sposoby ich usunięcia. Co więcej, po raz pierwszy przeprowadzamy trening, podczas którego graczowi towarzyszy oddział obywateli, więc skorzystaliśmy z okazji, by dodać kilka kwestii dialogowych dotyczących skaczących min."
N/A4157"#commentary\cn_245_dog_combat.mp3" "[ Eric Kirchmer ] Pies to naprawdę fajna postać i zawsze szukaliśmy sposobów, aby włączyć go do walki u boku gracza. Jednak uzyskanie odpowiedniej skali starć – czyli odpowiedniego środowiska, nowej sztucznej inteligencji wrogów oraz potencjalnie nawet nowych przeciwników – szybko wykroczyło poza zakres projektu. Tworząc scenariusz, który pokazałby, co potrafi Pies i mógłby konkurować z resztą rozgrywki, czuliśmy się, jakbyśmy tworzyli nową grę w grze. Wiedzieliśmy, że nie może on po prostu podbiec do żołnierza i go walnąć – nie wywarłoby to odpowiedniego wrażenia, nie wzbudziłoby podziwu. Potrzebował większych zagrożeń, które dorównywałyby jego potędze, a także interesujących sposobów interakcji z nimi. Ostatecznie zdecydowaliśmy się stworzyć dużą, wyreżyserowaną scenę kinową dla Psa w walce, bez potrzeby tworzenia rozbudowanej rozgrywki."
N/A4158"#commentary\cn_246_strider_2.mp3" "[ Eric Kirchmer ] Stale modyfikując stępacza w końcu uzyskaliśmy satysfakcjonujące wrażenia, ponieważ gracze musieli przemieszczać się między osłonami, unikając ostrzału i szukając rakiet. Chcieliśmy, by mieli wrażenie, że w ostatniej chwili rzucają się za osłonę, więc dostosowaliśmy wzór ostrzału stępacza, by sygnalizował zbliżające się zagrożenie. Stworzyliśmy również system ścieżek dla stępacza, umożliwiając mu dynamiczne przełączanie się między nimi, by gonić gracza lub mieć go w zasięgu wzroku. Takie ustawienie pozwoliło projektantom poziomów dokładnie dopasować ścieżki stępacza do osłon gracza, dostarczając odpowiednich przeżyć. Położenie nóg stępacza było w pełni ustalane przez kod, a jego nieprzewidywalne ruchy oznaczały, że często musieliśmy dokonywać drobnych poprawek, by w razie potrzeby kopnął samochód lub kontener z żołnierzami."
N/A4159"#commentary\cn_247_manhack_tunnels.mp3" "[ Eric Smith ] Opracowując zachowania sztucznej inteligencji dla postaci niezależnych stwierdziliśmy, że programistom SI przydałaby się mapa testowa do eksperymentów. Mapa ta często ewoluowała w środowisko zaprojektowane specjalnie do prezentacji unikalnych możliwości postaci. Później, gdy sztuczna inteligencja była gotowa dla projektantów poziomów, mapa testowa służyła za punkt odniesienia – bez niej projektanci mogliby przypadkowo stworzyć scenariusze, w których interesująca sztuczna inteligencja wypadłaby gorzej. W kilku przypadkach mogliśmy przenieść te mapy testowe wprost do gry. Na przykład ta niewielka sekcja powstała jako tunele użyte do opracowania SI siekacza."
N/A4160"#commentary\cn_248_sniper_streets_2.mp3" "[ Erik Johnson ] Pociski w Half-Life 2 nie mają trajektorii lotu – trafiają w cel natychmiast. Jednak w przypadku snajpera, który strzela powoli, a gracz zwraca uwagę na każdy strzał, chcieliśmy symulować lot kuli. Takie podejście działało jeszcze dzięki celownikowi laserowemu, który migocze, a pocisk zaraz potem trafia w cel, w zależności od odległości do snajpera. Jednak ta zmiana wprowadziła nowy problem: nie chcieliśmy, aby gracze po prostu biegali ulicą, aby uniknąć strzałów, więc snajper musiał wyprzedzać ruchomy cel i przewidzieć, gdzie trafi pocisk. Przewidywanie przyszłej pozycji graczy było trudne, ponieważ mogą zmieniać kierunek znacznie szybciej niż byłoby to możliwe w rzeczywistości. Dodaliśmy więc dodatkowe funkcje, aby wychwycić zachowania takie jak szybkie uniki w lewo i w prawo podczas biegu."
N/A4161"#commentary\cn_249_triangle_plaza.mp3" "[ Ido Magal ] Ta bitwa na placu była złożoną sytuacją wykorzystującą zachowanie szturmowe z dwiema zbiegającymi się szykami bojowymi, po jednym dla każdego pola siłowego. Gdy żołnierze wychodzą zza pól, ich szyk uniemożliwia im wtargnięcie na plac pojedynczo. W miarę eskalacji i gromadzenia się żołnierzy szyki zaczynają przesuwać się w kierunku centrum placu, więc żołnierze pokonają gracza, jeśli nie zostaną odparci."
N/A4162"#commentary\cn_250_sniper_streets_3.mp3" "[Jakob Jungels] Jedną z funkcji testowanych na tych ulicach było przygniecenie ogniem. Wielu graczy, skulonych na końcu ulicy, strzelało serią w okno snajpera, by sprawdzić, czy to coś da. Wprowadziliśmy więc krótkie migotanie celownika, dając graczom chwilę na zmianę pozycji. Jednak po wielu testach napotkaliśmy dwa problemy: po pierwsze, zakłócało to napiętą rozgrywkę dla snajpera polegającą na przemieszczaniu się i ukrywaniu. Strzelanie podczas sprintu nie różniło się zbytnio od innych czynności, których wymagamy od gracza w Mieście 17. Drugą, subtelniejszą kwestią było to, że gracze, którzy pierwsi odkryli przygniecenie ogniem zakładali, że jest to wymagane działanie i szybko zużywali amunicję. Jeśli amunicja kończyła się w połowie rozgrywki, często poddawali się, myśląc, że ponieśli porażkę, a jeśli przetrwali, zwykle zostawali bez amunicji. Z drugiej strony ci, którzy ukończyli scenariusz, działając w ukryciu, prawie w ogóle nie zużywali pocisków. Przez tę różnicę w zużyciu zasobów zależnie od podejścia niemal niemożliwe było zrównoważenie ilości amunicji w kolejnych sekcjach, więc pomysł ten nie trafił do ostatecznej wersji."
N/A4163"#commentary\cn_251_assault_behavior.mp3" "[ John Cook ] Najbardziej złożonym zachowaniem, jakie stworzyliśmy w Half-Life 2, był szturm, który wykorzystaliśmy w całej tej części gry. Pozwoliło to projektantom poziomów na tworzenie scenariuszy starć z żołnierzami Kombinatu i obywatelami, ustalanie linii frontu oraz kontrolowanie przebiegu tych walk w oparciu o działania gracza. Nacierające postacie niezależne próbowały znaleźć dogodne pozycje do strzału i wykorzystywały osłonę w zależności od położenia linii frontu. Gdy gracz posuwał się do przodu, mógł przesuwać linię frontu, przez co sprzymierzeni obywatele posuwali się naprzód, a żołnierze wycofywali się. Poza tym gracz mógł być zmuszony do zniszczenia niektórych wieżyczek Kombinatu lub wyeliminowania żołnierza za barykadą, by przesunąć linię frontu naprzód."
N/A4164"#commentary\cn_252_bank_roof_mortar.mp3" "[ John Morello ] Kiedy stworzyliśmy ten poziom wiedzieliśmy, że gracze będą mieli frajdę z używania moździerza. Mogliśmy pomyśleć o tym wcześniej. „Czy ktoś będzie chciał wystrzelić wybuchowe pociski w górę, by spadły na wrogów? No oczywiście”. W każdym razie – gracze dotąd byli celem moździerza, więc miłą nagrodą byłoby odpłacenie Kombinatowi tym samym. Jednak gdy zaczęliśmy o tym myśleć, zdaliśmy sobie sprawę, ile pracy to wymaga – co, szczerze mówiąc, jest myślą, która pojawia się każdego dnia, gdy tworzy się grę. Moździerz wymagałby animacji i efektów, ponieważ gracz znajdował się tuż obok, a wprowadzenie fal wrogów na placu, gdzie można go użyć, wymagałoby sporo wysiłku. A co ważniejsze, nie opracowaliśmy interfejsu dla tak wyjątkowej broni. Jak gracze mieliby celować i strzelać? Poświęcanie masy czasu na jedną chwilę w grze nie daje satysfakcji, więc uznaliśmy, że lepiej skupić się na czymś innym i przeszliśmy dalej. Przepraszamy! Być może rozwiążemy problem z moździerzem w następnej części Half-Life."
N/A4165"#commentary\cn_253_strider.mp3" "[ Kerry Davis ] To właśnie przed bankiem wymyśliliśmy stępacza. Kiedy po raz pierwszy zobaczyliśmy jego projekt koncepcyjny, wiedzieliśmy, że chcemy umieścić go w grze, ale pojawiło się mnóstwo pytań dotyczących tego, jak miałby on funkcjonować w praktyce. Nigdy wcześniej nie poruszaliśmy obiektem tej wielkości w naszym świecie, a przy takich rozmiarach musiał być niebezpieczny, ale jak gracze mieliby z nim walczyć? Podobnie jak w przypadku pozostałych wrogów, pojawiła się kwestia wykorzystania go w grze. Jakiego narzędzia potrzebowaliby projektanci poziomów, by tworzyć scenariusze z jego udziałem? Tego typu wątpliwości rozwiązaliśmy, eksperymentując na tej mapie."
N/A4166"#commentary\cn_254_sniper_streets.mp3" "[ Eric Kirchmer ] Na tych ulicach pełnych snajperów stworzyliśmy zarówno wrogów, jak i koncept wrażeń, które chcieliśmy dać graczom. Wiedzieliśmy, że snajperzy powinni strzelać do obiektów znajdujących się w pobliżu gracza, więc najpierw skupiliśmy się na znalezieniu dla nich różnych interesujących celów. Okazało się, że dobrze sprawdza się wykorzystanie pola widzenia gracza jako czynnika przy wyborze obiektów. Ciągle włączony celownik laserowy snajpera oznaczał, że gracze stale wiedzieli, w co mierzy, więc skierowanie go na cel, na który patrzył gracz, wydawało się odpowiednim wyjściem, wspaniale budującym napięcie."
N/A4167"#commentary\cn_255_citizen_squad_details.mp3" "[ Matt Wright ] Kiedy stworzyliśmy drużynę obywateli dla gracza i zaczęliśmy budować scenariusze wokół niej, otworzyły się przed nami nowe, interesujące możliwości. Testerzy zaczęli interesować się konkretnymi członkami drużyny, więc rozszerzyliśmy ich projekt. Członkowie podnosili lepszą broń, jeśli ją znaleźli, przekazywali graczowi amunicję, gdy jej zabrakło, a sanitariusze leczyli gracza w razie potrzeby. Zadbaliśmy też o to, by drużyna nadążała za graczem, który często wybierał nieprzewidywalne ścieżki. Poza kadrem drużyna „oszukiwała” na różne sposoby – regenerując zdrowie między walkami, poruszając się szybciej, by dogonić gracza, nawet teleportując się w razie potrzeby."
N/A4168"#commentary\cn_256_citizen_squads.mp3" "[ Ken Birdwell ] Wczesne testy walk ulicznych między Kombinatem i mieszkańcami ujawniły pewien problem: bez ograniczeń sztuczna inteligencja walczących postaci mogła znacznie oddalić się od gracza. Żołnierze mogli wycofywać się, by przeładować broń lub schronić się, a mieszkańcy ruszali w pościg. Działania obywateli musiały być bardziej zgodne z celami gracza, tak aby byli świadomi kierunku, w którym zmierza gracz i z którymi wrogami chce się zmierzyć. Doprowadziło to do stworzenia oddziału obywateli gracza. Sztuczna inteligencja wykorzystywała ten oddział do poruszania się za graczem, walcząc z tymi samymi wrogami i oferując podstawowy interfejs rozkazów. Początkowo mieliśmy bardziej złożony system poleceń, ale szybko stał się nieporęczny, więc go ograniczyliśmy."
N/A4169"#commentary\cn_257_ai_behaviors.mp3" "[ Mike Dussault ] Jedną z technologii sztucznej inteligencji, którą opracowaliśmy dla Half-Life 2, był system zachowań. Były to fragmenty kodu SI, które kierowały postaciami niezależnymi w określonych sytuacjach. Na przykład zachowanie „Prowadź”, które umożliwiało prowadzenie gracza, a zachowanie „Podążaj”, pozwalało podążać za graczem lub inną postacią. Zachowania działały równolegle z podstawowymi działaniami, więc sanitariusz w drużynie, korzystający z zachowania „Podążaj”, aby nadążyć za graczem, nadal wiedział, jak strzelać do wrogów, unikać granatów lub podać apteczkę."
N/A4170"#commentary\cn_258_occlusion.mp3" "[ Brian Jacobson ] W Half-Life 1 i większości Half-Life 2 świat składał się głównie z zamkniętych tuneli i korytarzy, co dobrze współgrało z binarnym podziałem przestrzeni (BSP) lub drzewem BSP. Technologia pozwalała szybko sortować geometrię i określać, co będzie widoczne dla gracza. Jednak otwarte obszary Wybrzeża i innych sekcji zewnętrznych nie pasowały do tego podejścia, więc potrzebowaliśmy nowych technologii. Jedną z nich były portale obszarowe, które pozwoliły podzielić świat na oddzielne fragmenty portalami – drzwiami i oknami, a nie portalami Aperture Science. Opracowaliśmy również dodatkowy system okluzji, który stwierdzał: „jeśli gracz nie może widzieć przez duży obiekt, nad nim lub wokół niego, nie renderuj tego, co znajduje się za nim”. Może się to wydawać oczywiste, ale wymaga nakładu pracy, by upewnić się, że obliczanie tego, co znajduje się po drugiej stronie obiektu, nie jest wolniejsze od renderowania całości. By przyspieszyć obliczenia, projektanci poziomów umieścili duże obszary okluzji wewnątrz głównego ukształtowania terenu i dużych obiektów przesłaniających widok, takich jak budynki, a podczas renderowania mogliśmy przetestować granice elementów względem tych obszarów, by uniknąć renderowania wszystkiego, czego gracz nie mógł zobaczyć."
N/A4171"#commentary\cn_259_detail_objects.mp3" "[ Brian Jacobson ] Kiedy powstały sekcje zewnętrzne zrozumieliśmy, że potrzebują one gęsto rozmieszczonych detali, więc dodaliśmy małe elementy roślinności, takie jak trawa i krzewy, na całym terenie. Wiedzieliśmy jednak, że nie możemy sobie pozwolić – to znaczy nie mieliśmy czasu – na ręczne umieszczenie ich wszystkich. Dlatego stworzyliśmy system obiektów szczegółowych, który automatycznie generuje małą roślinność w oparciu o typ terenu. Każdy materiał określa rodzaj roślinności, wraz z zestawem parametrów. Podczas kompilacji mapy system oblicza losowe punkty na powierzchni i wybiera, jaką roślinność tam umieści. Biorąc pod uwagę ograniczenia wydajności, nadal istniał dość złożony proces ręcznego tworzenia tekstur roślinności, co pozwalało nam renderować je wszystkie za jednym zamachem."
N/A4172"#commentary\cn_260_displacements_1.mp3" "[ Charlie Brown ] Po wydaniu Half-Life 1 projektanci poziomów i graficy poszukiwali lepszego rozwiązania dla środowisk zewnętrznych, więc stworzyliśmy pierwszą wersję systemu terenu. Był oparty na podzielonych czworokątach. Spróbujcie sobie wyobrazić płaski kwadrat podzielony na siatkę, w której każdy punkt siatki można przesuwać w górę lub w dół. Projektanci poziomów mogli układać wiele kwadratów, a następnie używać narzędzia pędzla do kształtowania wzgórz i dolin, układając punkty siatki. Do renderowania używaliśmy specjalnej mieszanej tekstury, łączącej dwie różne tekstury. Każdy punkt siatki określał, ile każdej tekstury należy użyć, umożliwiając płynne przejścia między powierzchniami, takimi jak piasek, trawa, ziemia i żwir. Taki system terenu nie był wówczas niczym niezwykłym w silnikach gier i naiwnie sądziliśmy, że wystarczy dla naszych projektantów."
N/A4173"#commentary\cn_261_displacements_2.mp3" "[ Charlie Brown ] Kiedy system terenu zaczął działać, myśleliśmy, że projektanci poziomów będą go używać do tworzenia przestrzeni zewnętrznych. Ale zaczęli eksperymentować, dodając detale w nieoczekiwanych miejscach. Używali podzielonych kwadratów na szczytach ścian, by stworzyć zniszczone krawędzie, zaokrąglone krawężniki, a nawet próbowali robić rury. Nie zawsze się to udawało, bo system terenu był zaprojektowany do tworzenia krajobrazów, a nie detali architektonicznych. Wróciliśmy więc do pracy nad kodem, przekształcając system terenu oparty na wysokości w pełne kształtowanie 3D. Zamiast przesuwać punkty siatki tylko w górę lub w dół, projektanci mogli przemieścić je w dowolnym kierunku. Pozwoliło to dodać detale do wszystkich powierzchni, używając mieszanych tekstur do wygładzenia przejść między kwadratami przemieszczeń a geometrią BSP. Wymagało to jednak dodatkowej pracy technicznej, ay zapewnić spójne oświetlenie między dwoma rendererami, w przeciwnym razie krawędzie były wyraźnie niedopasowane. Po wykonaniu wszystkich tych czynności projektanci poziomów wydawali się zadowoleni, a my naiwnie sądziliśmy, że tym razem to naprawdę wystarczy."
N/A4174"#commentary\cn_262_displacements_3.mp3" "[ Charlie Brown ] Mając ogólny system przemieszczania, projektanci poziomów nie poprzestali na dodawaniu szczegółów do świata i powrócili do swoich pierwotnych celów, czyli tworzenia rozległych sekcji zewnętrznych. Doprowadziło to do kolejnej serii aktualizacji mających zrównoważyć wydajność, tak by system był w stanie obsłużyć zarówno szczegóły, jak i większe tereny. Należało również poprawić teksturowanie, zwłaszcza złożonych struktur, takich jak półki skalne, których nie dało się stworzyć w oryginalnym systemie opartym na wysokości. Projektanci, którzy nigdy nie spoczywają na laurach, zaczęli również wykorzystywać przemieszczenia do tworzenia jaskiń i tuneli. Chociaż te dodatki wyglądały świetnie, wymagały jeszcze większych zmian technicznych. Ostatecznie udało nam się pogodzić wszystkie niewspółgrające ze sobą metody przemieszczeń i wprowadziliśmy je do dużych sekcji naszego świata. Patrząc wstecz, przemieszczenia są wyraźnym przykładem tego, jak technologia i projektowanie gier ewoluują razem. Jest to problem typu „jajko czy kura” – nie możemy przewidzieć, jak dokładnie dana technologia wpłynie na grę, ale nie możemy też jej stworzyć, nie wiedząc, do czego ma służyć. A, jak zawsze, musimy coś opracować. Zaczynamy od konkretnego przypuszczenia i sprawdzamy, dokąd nas to zaprowadzi."
N/A4175"#commentary\cn_263_particles.mp3" "[ Chris Green ] W silniku Source zainwestowaliśmy w rozbudowę technologii cząsteczkowych i efektów specjalnych. Pozwoliło to uzyskać bardziej realistyczny i złożony ruch cząsteczek, a także bardziej skomplikowane kształty i efekty cieniowania. Zwłaszcza dodanie bumpmappingu do funkcji cząsteczkowych znacznie zwiększyło ich objętość. Późniejsze wersje silnika Source zawierały potężny edytor systemu cząsteczek, ale oryginalna wersja z Half-Life 2 opierała się na ręcznie tworzonych efektach – każdy z nich wymagał od programisty skrupulatnego ręcznego tworzenia, co było dość pracochłonnym procesem."
N/A4176"#commentary\cn_264_cubemaps.mp3" "[ Chris Green ] Po dodaniu materiałów i shaderów potrzebowaliśmy rozwiązania dla powierzchni odbijających światło, takich jak szkło i stal. Powierzchnie musiały wiedzieć, co mają odbijać, ale w 2003 roku nie byliśmy w stanie renderować tego w czasie rzeczywistym. Dlatego opracowaliśmy system map sześciennych do wstępnego obliczania odbić. Mapa sześcienna to zestaw sześciu obrazów umieszczonych wewnątrz sześcianu, które odwzorowują otoczenie we wszystkich kierunkach, jak zdjęcie panoramiczne otaczające gracza ze wszystkich stron. Projektanci poziomów umieścili niewidoczne znaczniki w różnych miejscach, a w kompilacji mapy wygenerowaliśmy sześcienny obraz dla każdego znacznika. Renderując powierzchnie odbijające światło lokalizujemy najbliższą wstępnie obliczoną mapę sześcienną, by stworzyć odbicie."
N/A4177"#commentary\cn_265_water_shader.mp3" "[ Gary McTaggart ] Najbardziej złożonym shaderem, jaki stworzyliśmy, był shader wody, który w pełni wykorzystywał nowe, programowalne karty graficzne. Gdy pojawiała się woda, scena była renderowana trzykrotnie: najpierw podwodny świat dla załamania światła, potem odbicie, a na końcu części znajdujące się nad wodą. Renderując powierzchnię wody połączyliśmy widok załamania i odbicia, pokazując więcej odbić pod kątem poprzez równanie Fresnela. Śledziliśmy również głębokość dna pod powierzchnią wody, dzięki czemu w płytkich obszarach była ona bardziej przezroczysta i mniej załamywała światło. Poza tym musieliśmy stworzyć dwie techniki renderowania wody dla słabszych kart graficznych: karty średniej klasy wyświetlały odbicie o niższej szczegółowości, bez załamania i przezroczystości, zaś najsłabsze karty renderowały tylko częściowo przezroczystą powierzchnię."
N/A4178"#commentary\cn_266_normal_maps.mp3" "[ Gary McTaggart ] Half-Life 2 stworzyliśmy w interesującym okresie dla grafiki, kiedy na rynek trafiły pierwsze karty obsługujące programowalne shadery. Dzięki tej technologii nasza gra była jedną z pierwszych, w których zastosowano technologię normalnych map, poprawiającą oświetlenie geometrii powierzchni. Mapa normalna opisywała chropowatość powierzchni, umożliwiając oświetlenie każdego piksela wielokąta tak, by powierzchnie wydawały się bardziej nierówne i bardziej szczegółowe niż było to możliwe w Half-Life 1."
N/A4179"#commentary\cn_267_rendering_systems.mp3" "[ Gary McTaggart ] Na początku XXI wieku nie mogliśmy sobie pozwolić na renderer wielofunkcyjny, o szerokich możliwościach współczesnego silnika. Ograniczenia procesora, karty graficznej i pamięci wymagały specyficznych rozwiązań związanych z renderowaniem, byśmy mogli wycisnąć maksymalną wydajność ze sprzętu graczy. Dlatego Half-Life 2 ma trzy różne silniki renderujące: jeden dla geometrii świata, drugi dla terenu zewnętrznego, a trzeci dla elementów dynamicznych, takich jak postacie i obiekty. Te trzy rendery musiały obsługiwać skomplikowane funkcje – kolizje, śledzenie promieni, nakładki, oświetlenie offline, obliczenia widoczności i wiele innych. Ponadto każdy render musiał obsługiwać DirectX 7, 8 i 9. Różnice między wersjami DirectX były znaczące i często wymagały różnych podejść do przechowywania danych i renderowania, używały nawet różnych języków programowania! W sumie mieliśmy dziewięć różnych rendererów, z których każdy wymagał unikalnych rozwiązań, a zadbanie o spójną oprawę graficzną było jednym z najtrudniejszych problemów technicznych, z jakimi zmagaliśmy się podczas tworzenia."
N/A4180"#commentary\cn_268_dynamic_shadows.mp3" "[ Gary McTaggart ] Skupiając się na postaciach i obiektach fizycznych uznaliśmy, że do ich renderowania w pełnej krasie niezbędny jest dynamiczny system cieni. W 2003 roku procesory graficzne nie miały jeszcze dedykowanych funkcji cieniowania, jakie mają dzisiaj, więc wydajność była przeszkodą. Ostatecznie rozwiązaliśmy problem, sprawdzając każdą klatkę. Najpierw znajdowaliśmy wszystkie obiekty, które mogły rzucać cienie w polu widzenia. Ustaliliśmy, które obiekty znajdowały się w zasięgu wzroku lub nieco za nim, aby wychwycić elementy, które były poza ekranem, ale których cienie mogły pojawić się na ekranie. Następnie renderowaliśmy czarną wersję cienia każdego z tych obiektów jedną teksturą. Do tego renderowania używaliśmy modelu o najniższym poziomie szczegółowości dla obiektu, by proces przebiegał jak najszybciej. Na koniec używaliśmy tekstury cieniującej do narysowania każdego z cieni w polu widzenia, przyciemniając już renderowane piksele. Ostrożnie wycinaliśmy każdy cień w tej teksturze, by przy powstawaniu wielu cieni prawidłowo się na siebie nakładały. Miło jest spojrzeć wstecz na to, jak to robiliśmy, ale jesteśmy dziś o wiele szczęśliwsi, bo obecne karty graficzne ułatwiają rozwiązanie tego problemu."
N/A4181"#commentary\cn_269_combinatorial_shader_explosion.mp3" "[ Gary McTaggart ] Podczas tworzenia Half-Life 2 renderowanie stało się bardziej złożone dzięki dodaniu shaderów sprzętowych – małych fragmentów kodu kontrolujących renderowanie każdego piksela na powierzchni. W 2003 roku shadery były bardziej ograniczone niż obecnie: w czasach Half-Life 2 nie miały warunkowania, a ich rozmiar w kodzie był ograniczony. Oznaczało to brak logiki rozgałęzień if/else w oparciu o różne warunki oraz brak dużych, wielofunkcyjnych shaderów. Ponadto kompilowanie shaderów w locie było zbyt powolne, więc musieliśmy je skompliować wstępnie. Pracując w ramach tych ograniczeń musieliśmy obliczyć każdą możliwą kombinację shaderów i zapisać je indywidualnie jako osobny shader. Na przykład, jeśli shader wpływał na powierzchnię w oparciu o jedno źródło światła, potrzebowaliśmy innej wersji dla dwóch świateł, kolejnej dla trzech i tak dalej. Proces był złożony – jeśli shader obsługiwał również mapę normalną, potrzebowaliśmy dwóch wersji na każde światło, jednej z mapą normalną i jednej bez. Liczba shaderów gwałtownie wzrosła przez takie funkcje jak mieszanie tekstur, barwienie wierzchołków, refleksy świetlne, testowanie alfa i inne typy oświetlenia – kierunkowe, punktowe, reflektory. W dniu premiery mieliśmy tysiące indywidualnych shaderów. Wkrótce potem wydaliśmy Lost Coast, dodając obsługę HDR, co podwoiło liczbę shaderów. Kiedy kompilowanie shaderów na komputerach programistów zajmowało za dużo czasu, przeszliśmy na dystrybucję kompilacji shaderów w całej sieci za pomocą VMPi. Mieliśmy również dynamiczny tryb kompilacji shaderów, który był przydatny do tworzenia shaderów zapewniających szybką reakcję kosztem spadku liczby klatek na sekundę w momencie kompilacji."
N/A4182"#commentary\cn_270_gpu_wild_west.mp3" "[ Jay Stelly ] Podczas prac musieliśmy podjąć wiele decyzji w oparciu o docelowe minimalne wymagania sprzętowe – najsłabsze procesory i karty graficzne, które nadal zapewniałyby odbiorcom odpowiednie wrażenia. Na początku XXI wieku karty graficzne były znacznie bardziej zróżnicowane, mając nie tylko inne moce obliczeniowe, ale też różne metody renderowania. Jednak wówczas nie mieliśmy wiedzy na temat sprzętu używanego przez naszych klientów. Jakie procesory i karty posiadali? Ile pamięci RAM? Którą wersję Windows? Skontaktowaliśmy się z Microsoftem, mając nadzieję, że znają odpowiedzi na pytania takie jak: „Ile kart DX7 jest w użyciu? A DX8?”. Niestety, oni też nie dysponowali takimi danymi. Zdając sobie sprawę, że bez tych informacji możemy podjąć złe decyzje, opracowaliśmy narzędzie analityczne, pozwalające graczom zgłaszać specyfikacje swojego sprzętu i zintegrowaliśmy je z wczesną wersją Steam. Dane okazały się tak przydatne, że postanowiliśmy je upublicznić, uruchamiając w kwietniu 2003 ankietę Steam Hardware Survey. Od tego czasu pomaga ona nam – oraz innym twórcom – podejmować świadome decyzje."
N/A4183"#commentary\cn_271_3d_skybox.mp3" "[ Jay Stelly ] Zawsze musieliśmy renderować świat, który wydaje się większy niż pozwalają na to ograniczenia mapy. W Half-Life 1 użyliśmy tekstury cubemap, by gracze mogli widzieć obszar poza mapą gry. Jednak w Half-Life 2 chcieliśmy, aby widok na wielki świat był dynamiczny, a nie wyświetlany jako statyczna tekstura. Ograniczenie rozmiaru mapy wynosiło około kilometra w każdym wymiarze, ale zdaliśmy sobie sprawę, że możemy stworzyć znacznie większy świat zewnętrzny, jeśli zapiszemy go w zmniejszonej skali. Wymyśliliśmy więc coś, co nazwaliśmy 3D Skybox. To małe pudełko ukryte w rzeczywistej mapie, zawierające geometrię w skali 1/16. Wewnątrz znajduje się punkt odniesienia odpowiadający punktowi początkowemu na głównej mapie. Następnie, podczas renderowania przestrzeni poza obszarem gry, używamy geometrii z 3D Skybox, umieszczonej w tym punkcie odniesienia i powiększonej 16 razy. Uzyskanie płynnego przejścia oświetlenia i mgły między główną mapą a skyboxem stanowiło pewne wyzwanie, ale udało nam się. W efekcie świat wydawał się znacznie większy i ciekawszy niż w Half-Life 1."
N/A4184"#commentary\cn_272_missing_material.mp3" "[ Jay Stelly ] Na wczesnym etapie tworzenia niskopoziomowego kodu graficznego zauważyliśmy, że trudno wykryć wielokąty, które nie są renderowane z powodu brakującej tekstury. W takich wypadkach w miejscu, gdzie powinien znajdować się wielokąt, widoczna była po prostu czerń, przez co można tego nie zauważyć w ciemniejszych scenach. Aby bardziej niezawodnie wykrywać ten problem, stworzyliśmy teksturę błędu, która była wizualnie nie do pomylenia i powstawała automatycznie za każdym razem, gdy nie udało się załadować tekstury. Tak powstała kultowa tekstura w fioletowo-czarną szachownicę, która od tego czasu zyskała własne życie poza Half-Life 2."
N/A4185"#commentary\cn_273_air_resistance.mp3" "[ Jay Stelly ] Jedną z ważnych funkcji, którą musieliśmy dodać do silnika fizycznego Half-Life 2, był opór powietrza. W tamtym czasie silniki fizyczne zwykle implementowały ogólną funkcję hamowania, spowalniającą poruszające się obiekty. Jednak powodowało to jedynie symetryczne zmniejszanie energii. Aby stworzyć bardziej realistyczny ruch, zdecydowaliśmy się symulować opór powietrza. Pozwoliło nam to uzyskać asymetryczne zachowanie, w którym stopień spowolnienia obiektu poruszającego się w powietrzu różnił się w zależności od tego, jaka powierzchnia obiektu była skierowana w kierunku ruchu lub obrotu. Ta funkcja miała kluczowe znaczenie dla uzyskania wiarygodnego wyglądu eksplozji i obiektów rzucanych przez działo grawitacyjne. Szybko poruszające i obracające się obiekty należą do najtrudniejszych do obliczenia elementów symulacji fizyki Half-Life 2, więc opór powietrza poprawia również wydajność procesora w przypadkach takich jak eksplozje. Ma on również kluczowe znaczenie dla przedstawiania różnych materiałów i mas obiektów. Te o większej gęstości mogą łatwiej odpychać powietrze, co widać. Zastosowanie tego efektu pomaga uwydatnić różnicę w gęstości między kartonowymi pudełkami a drewnianymi deskami i naprawdę sprawia, że obiekty w świecie Half-Life 2 są bardziej przekonujące."
N/A4186"#commentary\cn_274_early_tech_planning.mp3" "[ Ken Birdwell ] Wydanie gry zawsze dostarcza nam wielu cennych informacji – w końcu dowiadujemy się, które z naszych decyzji były słuszne, a co powinniśmy zmienić następnym razem. Po wydaniu Half-Life 1, kiedy zaczęliśmy zastanawiać się nad kontynuacją, mieliśmy do przeanalizowania wiele opinii graczy. Na ich podstawie stworzyliśmy listę rzeczy, na których musimy się skupić w Half-Life 2. Nie próbowaliśmy zaprojektować konkretnych wrażeń dla graczy – uznaliśmy, że sensowniejsze będzie podejście z technologicznego punktu widzenia. Strażnicy i naukowcy z Black Mesa sprawdzili się dobrze. Co moglibyśmy osiągnąć, gdybyśmy naprawdę skoncentrowali się na postaciach? Podobało nam się nasze interaktywne opowiadanie historii. Co mogliśmy stworzyć, by wprowadzić jeszcze większą różnorodność w tej materii? Eksploracja i interakcja w Black Mesa były dla graczy fascynujące. Być może system fizyki pozwoliłby nam pójść o krok dalej? We wszystkich tych obszarach staraliśmy się wyobrazić sobie, jak mogłaby wyglądać najlepsza wersja tego rozwiązania za kilka lat, a następnie obliczyć zestaw kroków technologicznych, które mogłyby nas do tego doprowadzić."
N/A4187"#commentary\cn_275_character_lighting.mp3" "[ Ken Birdwell ] W pierwszym roku prac zmagaliśmy się z osiągnięciem pożądanego poziomu realizmu postaci. Pojawiło się wiele różnych kwestii, które ostatecznie wymagały konkretnych ulepszeń technologicznych i artystycznych. Pierwszym poważnym problemem było oświetlenie. W tamtym czasie technologia oświetlenia w grach miała wiele ograniczeń, z których część była związana z wydajnością, ale wiele z nich wynikało z braku zrozumienia, jak to wszystko działa. Aby postacie wyglądały dobrze, modele i tekstury musiały być tworzone z uwzględnieniem wielu rozwiązań oświetleniowych, takich jak cienie i połysk. Postacie wyglądały dobrze, ale nadal jak z gry wideo. Zaczęliśmy tworzyć Alyx, stosując to podejście. Wykorzystaliśmy wbudowane rozwiązania i oświetliliśmy ją jak aktorkę filmową –jakby miała niestandardową konfigurację oświetlenia, która podążała za nią i zapewniała, że zawsze wyglądała dobrze. Jednak to nie zadziałało. Zakres środowisk oświetleniowych i dynamiczny charakter rozgrywki sprawiały, że wyglądała świetnie w niektórych środowiskach, ale w pewnym momencie zawsze wypadała zbyt nierealistycznie. Próbowaliśmy zmodyfikować jej oświetlenie, aby zwiększyć jego możliwości, ale ostatecznie uznaliśmy, że to ślepy zaułek. Zaczynając od zera, postanowiliśmy spróbować innej metody. Stworzyliśmy Alyx, oświetlenie i tekstury od podstaw, odrzucając wszystko, co zrobiliśmy wcześniej. Zamiast skupiać się na tym, jak chcielibyśmy, by wyglądała w idealnym oświetleniu, skupiliśmy się na tym, jak powinno to działać w rzeczywistości. Może się to wydawać oczywiste, ale w grach robiło się to inaczej. Poza rendererem gry modele i tekstury wyglądały gorzej niż w poprzednich wersjach. Udało nam się jednak metodycznie wyeliminować wszystkie skróty i błędne przekonania dotyczące działania światła, tekstur i kart graficznych, a potem złożyć wszystko w całość. Kiedy wszystko było już gotowe i w końcu mogliśmy zobaczyć Alyx w grze, z nowymi modelami i teksturami, w dynamicznym otoczeniu, które zapewniało jej spójność wizualną przez cały czas, wyglądała świetnie. Całkowicie naturalnie wtapiała się w świat Half-Life 2."
N/A4188"#commentary\cn_276_gamma_correction.mp3" "[ John Morello ] Nasz silnik posiada system renderowania, który analizuje stan całej gry i oblicza wartość koloru dla każdego piksela na ekranie, aby go zwizualizować. Jednak proces obliczania tych pikseli wymaga również kodu i oprogramowania innych osób. Na przykład oprogramowania i komponentów w procesorze graficznym i monitorze. W pewnym momencie tworzenia nie byliśmy zadowoleni z wyglądu naszych postaci. Uważaliśmy, że są jak z wosku, jakby były chore. Ich skóra wyglądała nienaturalnie. Choć poświęciliśmy czas na dostosowanie oświetlenia, nie byliśmy w stanie sprawić, aby nasze postacie lub świat wyglądały, jak należy. Na szczęście nadal dysponowaliśmy w pełni funkcjonalnym oprogramowaniem renderującym, co oznaczało, że mogliśmy uruchomić grę bez karty graficznej. W tym czasie wielu graczy nadal nie posiadało takiej karty. Oglądając grę na tym rendererze, zauważyliśmy, że nasze oświetlenie nie ma tego samego problemu. Przejrzeliśmy dokładnie kod, próbując dowiedzieć się, gdzie nie współpracuje jak należy z kartą graficzną. Nie udało nam się to, zwróciliśmy się więc do producentów kart z prośbą o sprawdzenie, czy ich sprzęt nie interpretuje błędnie dostarczanych przez nas wartości pikseli. Był to początek długiego procesu – krótko mówiąc, poświęciliśmy prawie dwa lata na komunikację z producentami procesorów graficznych, zanim udało nam się ich przekonać, że nieprawidłowo wykonują korekcję gamma w niskopoziomowych obliczeniach na swoich kartach. W tym czasie musieliśmy nawet zbudować system, który weryfikował wartości kolorów poszczególnych pikseli w całym naszym procesie renderowania. Ostatecznie jednak otrzymaliśmy od nich nowe sterowniki i nasze postacie natychmiast wyglądały tak, jak powinny, zgodnie z oprogramowaniem renderującym."
N/A4189"#commentary\cn_277_facial_technology.mp3" "[ Ken Birdwell ] Chcieliśmy, aby gracze przejmowali się losami naszych bohaterów. By w ogóle mieć szansę na wykonanie tego zadania, musimy zainwestować znaczne środki w technologię tworzenia twarzy postaci. Wiadomo, że ludzie są genetycznie zaprogramowani, by zwracać uwagę na twarze i podświadomie odczytywać z nich różne informacje. Było to więc wielkie wyzwanie i gdybyśmy nie zdołali pokonać tej przeszkody, prawdopodobnie zrażalibyśmy graczy do naszych postaci, zamiast do nich przyciągać. Zaczęliśmy od przeprowadzenia wielu badań. Wyniki nie były zachęcające. Najlepsze przykłady, jakie udało nam się znaleźć, nie mogły być uruchamiane w czasie rzeczywistym, a najlepsze wersje działające w czasie rzeczywistym nie były zbliżone do jakości, której oczekiwaliśmy. Chcieliśmy, aby nasze postacie wyglądały tak dobrze, jak te z filmów animowanych, ale renderowanie klatek w tych filmach często trwało wiele godzin, a dzieła te były całkowicie liniowe i tworzone przez nawet stu animatorów. Natomiast nasi bohaterowie musieli być dynamiczni: postać mogła próbować wypowiedzieć dialog, stosując mimikę twarzy wynikającą z działań gracza, stworzoną przez zaledwie kilku grafików. To właśnie te wymagania ostatecznie doprowadziły nas do systemu kodowania mimiki doktora Paula Ekmana – kategoryzacji ruchów twarzy człowieka opracowanej w latach 70. Uzyskaliśmy słownictwo do opisywania mimiki w narzędziach i kodzie, a także cel, do którego dążyliśmy podczas projektowania twarzy postaci. Wykorzystując to jako podstawę, rozpoczęliśmy wieloletni proces iteracji tworzenia twarzy i głów naszych postaci. W przeciwieństwie do innych, chcieliśmy wykorzystać pełen zakres pracy Ekmana, co wymagało wielu eksperymentów w ramach ograniczeń wydajności. Jednak spędziliśmy również dużo czasu po prostu obserwując ludzi i twarze, próbując zidentyfikować dodatkowe cechy, będące wartością dodaną, jak elastyczność skóry i cieniowanie uzębienia. Chociaż nie osiągnęliśmy wszystkich zakładanych celów, udało nam się doprowadzić najważniejsze elementy do poziomu, dzięki któremu mimika postaci była przekonująca."
N/A4190"#commentary\cn_278_eye_shader.mp3" "[ Ken Birdwell ] Kolejnym kluczowym elementem dodającym twarzom realizmu były oczy. Ludzie są bardzo dobrzy w odczytywaniu sygnałów wzrokowych. Nasz mózg potrafi je analizować i nawet określić, gdzie ktoś patrzy, na podstawie odbicia w jego oczach. Istnieje jednak wiele subtelnych, znaczących szczegółów. Oczy nie są w rzeczywistości kulami. Powieki są zniekształcone przez ruch rogówki. Ruch gałki ocznej może zwiększyć prawdopodobieństwo mrugnięcia. Oczy nie znajdują się bezpośrednio za tęczówką, są nieco przesunięte. Wszystkie te detale mogą wydawać się nieistotne lub niezauważalne, ale ich brak szkodzi wiarygodności postaci. Poświęciliśmy dużo czasu na udoskonalenie modelu oka i jego cech. Niektóre elementy wymagały zewnętrznych interfejsów, na przykład określenie, które elementy otoczenia są interesujące dla postaci, zaś inne były automatyczne i działały na poziomie podświadomości w sztucznej inteligencji – np. mruganie, które jest oczywistym wymogiem, ale subtelnie dezorientuje, jeśli wygląda nieprawidłowo. Odbicia w oczach miały szczególnie duży wpływ – ostatecznie zajmują one niewielką powierzchnię na ekranie, ale różnica była ogromna. Wiedzieliśmy, że w końcu osiągnęliśmy nasz cel, kiedy doszliśmy do punktu, w którym przy wyłączonym shaderze oczu postać wyglądała jak lalka, podobna do człowieka, ale w jakiś trudny do opisania sposób nieprzekonująca – ale kiedy go włączyliśmy, nagle poczuliśmy, jakbyśmy patrzyli na człowieka."
N/A4191"#commentary\cn_279_combine_gunship.mp3" "[ Ken Birdwell ] Kanonierka była interesującym problemem. Mieliśmy już jej model lotu helikoptera i zabrakło nam czasu, by stworzyć coś zupełnie nowego. Dlatego dostosowaliśmy ten model lotu, aż wyglądał wystarczająco odmiennie, a następnie na podstawie wartości uzyskanych z symulacji opracowaliśmy organiczny stan animacji kanonierki. Staraliśmy się również, by był jak najbardziej realistyczny. Na przykład ruch głowy celującego pilota jest ograniczony. Jeśli musi przekroczyć to ograniczenie, zmienia tor lotu, by skierować działko w odpowiednim kierunku – nie może po prostu oszukiwać. Inną kluczową cechą był dźwięk silnika. Wykorzystujemy przestrzenność dźwięku, dzięki czemu gracz może z grubsza określić lokalizację pojazdu. Jednak kanonierka porusza się błyskawicznie w powietrzu, bez żadnych punktów odniesienia w pobliżu. Dlatego trudno jest określić jej dokładną odległość i prędkość. Aby temu zaradzić, dodaliśmy efekt Dopplera do dźwięku silnika, zmieniając jego wysokość w zależności od prędkości kanonierki względem gracza. Ten subtelny efekt jest niezwykle pomocny w podświadomym postrzeganiu lokalizacji i kierunku lotu. Ta kluczowa informacja pozwala graczowi zorientować się, że jest ścigany przez kanonierkę."
N/A4192"#commentary\cn_280_risk.mp3" "[ Ken Birdwell ] Patrząc na Half-Life 2 po dwóch dekadach widać doskonale, jak przerażający był proces twórczy. Tworzenie gier jest trudne. Nigdy nie da się w pełni ocenić ryzyka przed podjęciem kolejnych działań mających spełnić oczekiwania. Weźmy na przykład naszą technologię animacji twarzy. Potrzebowaliśmy około trzech lub czterech lat, zanim byliśmy pewni, że będzie ona działać. Nie mogliśmy jednak czekać tak długo. W pierwszym roku zaczęliśmy podejmować różne decyzje dotyczące projektu, produkcji zasobów i innych technologii, zakładając, że nasza technologia animacji twarzy będzie spełniać wymogi jakości i wydajności. Gdyby tak nie było, wiele innych decyzji również nie miałoby sensu. Ten sam profil ryzyka dotyczy innych ważnych decyzji, które podjęliśmy na początku. Nie możemy czekać, musimy po prostu działać i mieć nadzieję, że nasze przewidywania okażą się słuszne za kilka lat. To przerażające."
N/A4193"#commentary\cn_281_hugs_and_pickups.mp3" "[ Ken Birdwell ] Czasami nawet najmniejsze rzeczy okazują się koszmarne w realizacji. Na przykład animowanie przytulenia postaci lub podniesienie przez nią przedmiotu ze stołu prowadzi do problemów. Co gorsza, w naszym dynamicznym środowisku, gdzie postacie i przedmioty nie znajdują się w ustalonych pozycjach, a gracze biegają wokół i robią zamieszanie, osiągnięcie takiego poziomu synchronizacji jest wyjątkowo trudne, ponieważ żywi ludzie wykonują te czynności bez zastanowienia. Kiedy podchodzicie do stołu, by podnieść kubek, ciało przygotowuje się, ustawiając stopy i ręce w odpowiedniej pozycji, by umożliwić ci wam sprawne wykonanie tej czynności. Wszystko jest gotowe w momencie, gdy docieracie do celu. Jeśli podchodzicie, by kogoś przytulić, oboje robicie to w tym samym czasie, nieustannie dostosowując się do ruchów drugiej osoby. By te funkcje działały w grze, musieliśmy pracować nad synchronizacją, aby postacie były świadome siebie nawzajem i swojego otoczenia. Jednocześnie musiały być świadome swoich przyszłych planów. Kuszące jest rozbicie przykładu „podniesienia kubka” na odrębne kroki – podejście do stołu, skierowanie twarzy w stronę kubka, podniesienie go – ponieważ w ten sposób jest to znacznie prostsze, a kroki można powtórzyć. Ale tak działają roboty, nie ludzie. Nasze postacie musiały wiedzieć, że zbliżają się do stołu z zamiarem podniesienia kubka, by mogły pracować nad wieloma elementami procesu jednocześnie i zapewnić, że ich ręka chwyci przedmiot w odpowiednim momencie. W przypadku dwóch postaci synchronizacja jest jeszcze trudniejsza. Obie muszą uzgodnić, gdzie i kiedy to się stanie, a wszystko powinno przebiegać płynnie. Chociaż te proste interakcje między bohaterami są często krótkie, mają kluczowe znaczenie dla nadania im wiarygodności."
N/A4194"#commentary\cn_282_ropes.mp3" "[ Mike Dussault ] Jedną z rzeczy, które zauważyliśmy na wszystkich zdjęciach referencyjnych zebranych dla Miasta 17, była duża ilość kabli i przewodów, które widać było niemal wszędzie. Bardzo podobał nam się wygląd tych starszych europejskich miast, splecionych chaotyczną siecią współczesnego życia. Wiedzieliśmy, że potrzebujemy rozwiązania dla kabli, lin i podobnych elementów i miały być one dynamiczne. Nasi projektanci poziomów chętnie tworzyli zagadki związane z wtyczkami, a podłączenie przewodu do każdej wtyczki pomagało graczom lepiej zrozumieć mechanikę. Na początku produkcji opracowaliśmy system lin i udoskonalaliśmy go w trakcie całego procesu tworzenia gry. Każda lina składa się z wielu segmentów rozciągniętych między dwoma końcami, z których każdy porusza się niezależnie. Każdy segment działa jak sprężyna, reagując na siły występujące w grze, takie jak delikatny wiatr lub przelatująca nad głową kanonierka Kombinatu. Podczas renderowania każdy segment jest skierowany w stronę kamery i ma mapę wypukłości, co ma kluczowe znaczenie dla realistycznego i zaokrąglonego wyglądu lin."
N/A4195"#commentary\cn_283_vmpi.mp3" "[ Mike Dussault ] Podczas tworzenia byliśmy coraz bardziej sfrustrowani wolnym wprowadzaniem zmian w rozgrywce, głównie dlatego, że kompilowanie map – niezbędne do wstępnego obliczenia oświetlenia i widoczności – zajmowało wiele godzin. Komputery w 2000 roku były znacznie wolniejsze niż dzisiejsze modele i miały tylko jeden rdzeń procesora. Zainspirowani programem SETI@Home – rozproszonym programem, wykorzystującym komputery na całym świecie do analizowania fal radiowych w poszukiwaniu oznak życia pozaziemskiego – stworzyliśmy VMPi, nasz własny system rozproszony, który rozdzielał proces kompilacji między wiele komputerów biurowych. Obecnie tego typu systemy działają na gigantycznych klastrach kart graficznych, ale wtedy po prostu uruchamialiśmy je na wszystkich komputerach w biurze. Aby nadążyć za szybką ewolucją naszego oświetlenia wraz z mapami, VMPi wysyłał również nowe pliki .exe na komputery wszystkich pracowników. Z perspektywy czasu było to dość przerażające naruszenie bezpieczeństwa — koszmar dla informatyków! W końcu wysyłaliśmy po prostu plik wykonywalny na wszystkie nasze komputery służbowe, a te go uruchamiały. To było absolutne szaleństwo. Jednak w naszym przypadku zadziałało, znacznie przyspieszając przetwarzanie map i ostatecznie stając się kluczowym narzędziem."
N/A4196"#commentary\cn_284_field_of_view.mp3" "[ Kerry Davis ] W Half-Life 1 zastosowaliśmy pole widzenia wynoszące 90 stopni, co było dość standardowym rozwiązaniem w strzelankach w tamtym czasie. Jednak podczas tworzenia Half-Life 2 nie byliśmy zadowoleni z tego pomysłu. Biorąc pod uwagę, że nasza gra skupia się na postaciach, włożyliśmy wiele wysiłku w stworzenie szczegółowych animacji twarzy i ciała. Jednak pole widzenia 90 stopni nie pozwalało graczom pełni docenić tych szczegółów. Zaczęliśmy więc eksperymentować z węższym polem widzenia i ostatecznie zdecydowaliśmy się na 75 stopni. I my, i gracze, musieliśmy się do tego przyzwyczaić, a dodatkowe pole widzenia było potrzebne dla modeli widoku, pokazujących broń gracza na dole ekranu. Modele te zostały pierwotnie stworzone z myślą o polu widzenia 90 stopni, więc przy 75 stopniach były zniekształcone. Jednak ta zmiana pozwoliła nam osiągnąć nasz cel, jakim było umieszczenie postaci w centrum uwagi."
N/A4197"#commentary\cn_285_reference_maps.mp3" "[ Randy Lundeen ] Ponieważ postacie stały się bardziej realistyczne między Half-Life 1 a Half-Life 2, chcieliśmy, aby świat gry był równie wiarygodny. W Half-Life 1 ograniczenia techniczne gier często ułatwiały projektowanie stylizowanych lub abstrakcyjnych środowisk. Jednak w Half-Life 2 postanowiliśmy stworzyć otoczenie, które wydawało się rzeczywiste. Musieliśmy skupić się na wielu szczegółach, których wcześniej nie braliśmy pod uwagę. Jednym z naszych głównych działań było stworzenie map referencyjnych, aby ujednolicić sposób odwzorowywania rzeczywistych proporcji w grze. Mapy te określały takie detale jak wymiary ścian i drzwi, wysokość klamek, oświetlenie wnętrz, skala mebli i ogólna skala przedmiotów codziennego użytku. Stworzyliśmy standardowe tekstury dla projektantów poziomów, wraz z wartościami skali i oświetlenia, aby od samego początku cały układ był spójny. Oprócz ustalenia świata fizycznego, mapy referencyjne określały również, w jaki sposób gracz może się po nim poruszać, na przykład jak wysoko może skakać i jak nisko może się schylać, a także rozmiar przestrzeni, choćby szybów wentylacyjnych. Opierając się na tych podstawach byliśmy w stanie stworzyć spójną geometrię świata i realistyczne rozmiary przestrzeni w całej grze."
N/A4198"#commentary\cn_286_response_rules.mp3" "[ Scott Dalton ] Od początku wiedzieliśmy, że chcemy wprowadzić do gry dynamiczne dialogi, więc potrzebowaliśmy odpowiedniego systemu. Dążyliśmy do rozwiązania, które pozwoli projektantom dźwięku dodawać i dostosowywać kwestie dialogowe bez angażowania programistów, zapewni reakcję dialogów na stan gry i zminimalizuje powtarzalność. Z tą myślą stworzyliśmy system reguł reakcji. Za każdym razem, gdy postać wypowiada się poza zaplanowaną sceną, system określa, którą kwestię należy wygłosić. Zamiast wybierać dialogi bezpośrednio, sztuczna inteligencja postaci nieustannie identyfikuje „okazje do wypowiedzi” za każdym razem, gdy ma miejsce istotne wydarzenie, takie jak zauważenie gracza, odniesienie obrażeń, wystrzelenie ostatnich pocisków lub spotkanie z przeważającymi siłami wroga. Przy każdej okazji sztuczna inteligencja wysyła do reguł reakcji pakiet danych o aktualnym stanie gry, a system zwraca najbardziej pasującą kwestię dialogową, jeśli taka istnieje. Ta metoda umożliwiła naszym projektantom dźwięku stworzenie szczegółowej matrycy decyzyjnej dla dialogów. Na przykład postać może mieć różne kwestie dotyczące przeładowania broni podczas ostrzału i po walce, jeśli pozostał tylko jeden sojusznik lub jeśli w zasięgu wzroku znajduje się stępacz. W momencie premiery Half-Life 2 czuliśmy, że wykorzystaliśmy tylko niewielką część potencjału tego systemu. Stał się on podstawową funkcją Alyx w Epizodzie 1 i był wykorzystywany do tworzenia dynamicznych dialogów w naszych późniejszych grach, w tym dla klas w TF2 i bohaterów Left 4 Dead."
N/A4199"#commentary\cn_287_audio_caching.mp3" "[ Yahn Bernier ] Kolejnym napotkanym problemem była ogromna liczba dźwięków w grze. Biorąc pod uwagę wszystkie odgłosy związane z rozgrywką, muzykę i dialogi, mieliśmy zbyt dużo materiałów audio, aby zmieścić je wszystkie w pamięci – w 2003 roku była na wagę złota. Jednak musieliśmy mieć możliwość natychmiastowego odtwarzania dźwięków, zwłaszcza jeśli były one związane z rozgrywką. Dlatego stworzyliśmy pamięć podręczną audio, która przechowywała tylko pierwsze 125 ms każdego pliku audio i utrzymywała go w pamięci. Oszacowaliśmy, że strumieniowe przesyłanie audio z dysku zajmie właśnie 125 ms. Za każdym razem, gdy w grze odtwarzano dźwięk, odtwarzaliśmy jego początek z pamięci podręcznej, jednocześnie ładując cały plik audio z dysku. Zanim zakończyło się odtwarzanie fragmentu z pamięci podręcznej, plik był już załadowany i mogliśmy kontynuować odtwarzanie reszty. Dodaliśmy również kilka dodatkowych funkcji, takich jak przechowywanie ostatnich dźwięków w całości w pamięci, aby częstszych odgłosów nie trzeba było ciągle ponownie wczytywać. Dzisiejsze silniki zazwyczaj stosują tę samą strategię dla wszystkich zasobów, nie tylko dźwięków."
N/A4200
39184201}
39194202}