Template:PatchDiff/March 6, 2026 Patch/hl2/resource/closecaption danish.txt

From Team Fortress Wiki
Jump to: navigation, search
39153915"wood.scraperough" " "
39163916"plastic_box.scraperough" " "
39173917 
N/A3918"#commentary\cn_001_physics_sound.mp3" "[ Jay Stelly ] At få fysikken til at føles rigtig for spilleren betød, at lydene produceret af fysikken også skulle lyde rigtige. Som mennesker er vi alle vant til, hvordan objekter og materialer lyder i forskellige interaktioner, selvom det ikke er noget, vi aktivt bemærker. Selvom vi vidste, at vi ikke kunne tage højde for alt, ønskede vi at fokusere på de detaljer, der bidrog mest til at få vores fysik til at lyde realistisk. Vi startede med lyde pr. objekt ved kollisioner og stød. Dette gjorde det muligt for et objekt, som en trækasse, at have brugerdefinerede lyde, når det kolliderede med andre objekter eller klasser af objekter. Dernæst begyndte vi dynamisk at ændre disse lyde baseret på egenskaberne ved den fysiske begivenhed, såsom de involverede masser og kollisionskraften. Dette fungerede godt til kollisioner, men fungerede ikke i andre interaktioner, som genstande, der skrabede mod hinanden. I virkeligheden giver en trækasse en anden lyd, når den skraber mod en væg, sammenlignet med når den kastes mod den samme væg. Jeg kan med sikkerhed sige, at ingen har forsket mere i nuancerne i en trækasses fysiske egenskaber end os. For at få det, vi ønskede ud af disse interaktioner, implementerede vi kollisionslyde pr. materiale – metal mod træ, metal mod metal osv. Disse lyde blev også dynamisk ændret baseret på detaljer, som materialehårdhed eller metaltype. Det krævede utallige små justeringer at få dette system til at lyde rigtigt, som vi kun kunne identificere, når det kørte. Vi eksperimenterede også med brugerdefinerede lyde til rullende objekter, men fjernede i sidste ende funktionen, fordi vi ikke var tilfredse med resultaterne."
N/A3919"#commentary\cn_002_ramming_with_the_buggy.mp3" "[ Jay Stelly ] Vores fysiksystem er baseret på stivlegemer, hvilket betyder, at det ikke understøtter nogen deformation eller ødelæggelse af objekter. Hvis et fysisk objekt rammes af noget, kan det bevæge sig, hvis det er tilladt, men ellers sker der intet. Så når du kører buggyen gennem et glasvindue, er vi nødt til at bruge nogle tricks for at få tingene til at fungere som forventet. Fordi vinduet er fastgjort på plads, vil fysiksimuleringen faktisk få buggyen til at springe tilbage fra vinduet, men det giver vores spilsystem besked om, at der opstod en kollision. Spilsystemet håndterer ødelæggelse, så det bryder vinduet i glasskår og fortæller fysiksystemet at begynde at simulere dem. Meget vigtigt fortæller spilsystemet også fysiksystemet, at det skal gendanne buggyens tilstand, hvor den var før kollisionen. Dette sikrer, at næste gang fysikken simuleres, kører buggyen frit gennem det nu ødelagte vindue. Denne proces producerer et problem på én frame i buggyens fysik, da den kortvarigt stopper og teleporteres tilbage til øjeblikket før stødet. Vi beklager, hvis viden om dette har gjort Half-Life 2 helt uspilleligt. Men efter at have set playtests dengang besluttede vi, at vi faktisk kunne lide det kortvarige problem – det øgede følelsen af sammenstødet."
N/A3920"#commentary\cn_003_ramming_zombies_with_the_buggy.mp3" "[ Jay Stelly ] Som mennesker har vi som nævnt et par gange i denne kommentar forventninger til vores fysiske verden. En af disse forventninger er, at hvis du rammer en zombie med din bil, skal den helt sikkert blive kastet op i luften. Men det er ikke så ligetil at få denne effekt i spillet, som det er i den virkelige verden. Af præstationsmæssige årsager bruger fjender som zombier en forenklet kollisionskasse under gameplay. Dette er en kasse, der passer tæt rundt om zombien, uden at nogen del af modellen stikker ud. Men når zombien dør, konverteres den til en ragdoll med mere nøjagtige kollisionskasser per lem, selvom dette er dyrere at simulere. Denne ændring i kollisionsrepræsentation tilføjer yderligere kompleksitet, når du rammer en zombie med buggyen, ud over frame-problemet. Når buggyen først kolliderer med zombien, rører den zombiens forenklede kollisionskasse. Spillet dræber derefter zombien og konverterer den til en ragdoll, som fysiksystemet begynder at simulere. Med mere præcis kollision per lem, kan den nærmeste del af zombien nu være flere centimeter væk fra buggyen. Næste gang fysiksystemet simulerer, begynder zombien derfor som resultat heraf at falde på grund af tyngdekraften, fordi buggyen ikke længere skubber den. Selvom det kun er et kort øjeblik, før buggyen når zombien igen, gjorde denne lille uoverensstemmelse det utilfredsstillende at ramme zombier – de røg ofte ud af spillerens synsfelt. For at løse dette gemte vi den kraft, zombiens kollisionskasse modtog, da den blev ramt af buggyen, og anvendte den samme kraft på ragdollen efter konvertering. Vi tilføjede også en lille opadgående kraft til ragdollen, der kastede den lidt op i luften. Med disse tweaks faldte zombierne pålideligt ind over fronten af buggyen, når de blev ramt, hvilket bedre matchede spillernes forventninger."
N/A3921"#commentary\cn_004_buggy_sound_engine.mp3" "[ Kelly Bailey ] Lyden til buggyen var udfordrende, fordi vi ønskede, at den skulle føles som et virkelig kraftfuldt køretøj, der kører med meget høj hastighed, selvom banerne ikke rigtigt er store nok til at understøtte det, og buggyen ikke rigtigt kommer ud af første gear. Og den har en tophastighed på måske 55 km/t. Til vores forsvar skal siges, at 55 km/t stadig er ret hurtigt, især tilbage i 2004. Ud over hastigheden er styringen virkelig enkel. Så med et tastatur som inputenhed er spillerens styring dybest set binære – så buggyen enten accelererer eller ikke accelererer, drejer helt i en retning eller ej. Så vi er dybest set nødt til at skabe al denne lydkompleksitet for at repræsentere en simulering, hvor kompleksiteten faktisk ikke eksisterer. Derfor byggede vi en falsk motor til buggyens lyd. Den har sin egen gearkasse, og vi kombinerede spillerens input med data fra fysiksimuleringen. Vi målte drejningsmomentet på hvert simuleret hjul, uanset om det spandt eller var i kontakt med overfladen, og vi lavede et sæt loopende lyde, og blandede derefter forsigtigt mellem dem, når den falske motor skiftede gear og reagerede på hjuldataene. Og vi fortsatte dybest set bare med at prøve forskellige ting. Vi tilføjede mere kompleksitet. Vi lavede nogle finjusteringer, indtil buggyen bare føltes sjovere og belønnede dig med følelsen af at køre hurtigt. Og de fleste spillere kommenterede ikke på det, bortset fra at sige, at buggyen lyder godt, og for os er det succesen i betragtning af mængden af skøre ideer, der blev smidt under kølerhjelmen."
N/A3922"#commentary\cn_005_buggy_sound_design.mp3" "[ Kelly Bailey ] Lyddesignet til buggyen blev baseret på prøver fra en gammel Camaro fra 1968. Vi valgte den bil, fordi den har en fantastisk V8-motor med enorme stempler. Og der er ikke rigtig en anden lyd som den; den har sådan en primitiv lyd med saft og kraft, som vi ledte efter. Geakassen har også denne virkelig vidunderlige mekaniske jamren, når den holder op med at accelerere. Og den kombination føltes virkelig passende til det mere eller mindre binære inputsystem, som vi var nødt til at arbejde med. Så den falske motors gearkasse blev ikke modelleret på en bil i den virkelige verden. I stedet blev den bare designet som et simpelt system til at belønne spilleren for at holde gaspedalen nede. Så det er som en rulletrappe, der producerer en stigende tone, konstant opbygger spænding og skifter gear, når tonen skal genstartes. Da spilleren hurtigt ville løbe tør for plads på vores relativt små baner, var målet bare at gøre accelerationen sjov i en kort periode."
N/A3923"#commentary\cn_006_automating_dsp.mp3" "[ Kelly Bailey ] Alle de lyde, som spilleren hører, behandles gennem vores Digital Signal Processing-system, eller DSP. Dette refererer bare til, hvordan lyd ændres for at afspejle det miljø, spilleren befinder sig i. For eksempel vil den samme lyd variere, når den høres i et parkeringshus, et lille rum eller udendørs. I Half-Life 1 placerede vi manuelt usynlige punkter over hele verden for at definere disse DSP-indstillinger for hvert rum. For Half-Life 2 vidste vi, at manuel placering bare ville være alt for tidskrævende, især da vi ønskede et større spil, og vi stadig kun havde én lydperson på holdet. Så vi byggede et system, der automatisk bestemmer DSP-indstillingerne omkring spilleren i realtid. Det gør det ved at analysere rummet omkring spilleren, vurdere størrelsen på rummet, spilleren befinder sig i, og ved at undersøge de materialer, der grundlæggende udgør miljøet. Derefter matcher systemet dette rum til en af de 25 håndskrevne grundlæggende DSP-typer, vi justerer nogle parametre, og vi opretter den fuldt detaljerede DSP, der ændrer de lyde, spilleren hører."
N/A3924"#commentary\cn_007_dynamic_mixing.mp3" "[ Kelly Bailey ] I løbet af spillet afspilles mange lyde på samme tid, men nogle er naturligvis vigtigere end andre, og vi er nødt til at indstille lydstyrken i forhold til hinanden for at sikre, at de vigtige skiller sig ud. I en film udføres denne lydblanding som en efterproces. Men i et spil sker det i realtid som respons på spillerens handlinger, så vi kan ikke forudsige på forhånd, hvilke lyde der afspilles samtidigt. For at håndtere dette er alle lyde grupperet i typer og mærket med prioriteter. I løbet af spillet overvåger lydsystemet alle de aktive lyde og sænker lydstyrken i en gruppe, hvis der afspilles en lyd med højere prioritet. Denne blanding er justerbar. Hvis skuddene skal være høje i en scene, kan vi give dem højere prioritet der. Hvis en bestemt dialoglinje skal høres tydeligt, kan den tvinge alle de andre lyde til at falde i lydstyrke. Og vi gør det samme med musik. Det er et subtilt, men meget kritisk system, og det forhindrer lydbilledet i at blive for rodet."
N/A3925"#commentary\cn_008_soundscapes.mp3" "[ Kelly Bailey ] I Half-Life 1 blev omgivende lyde placeret manuelt og derefter individuelt indstillet. Til Half-Life 2 ønskede vi flere omgivende lyde i vores miljøer med højere kvalitet og mindre manuel indsats for placering. Så vi byggede det system, som vi kalder lydlandskabssystemet. Et lydlandskab er dybest set et lille program, der styrer, hvilke omgivende lyde der afspilles, hvor de kommer fra, og derefter hvordan de opfører sig i et bestemt miljø. Så summende fluer, lyden af vinden, fugle, et fjernt tog, fjern kamp. Lydlandskabssystemet kunne derefter tilfældigt vælge og afspille disse lyde, og også meget vigtigt håndtere den glatte overgang, når spilleren bevæger sig gennem miljøer. Lydlandskaber kan også indeholde andre lydlandskaber, og det giver os mulighed for at skabe genanvendelige samlinger af lyde – så for eksempel kan fjern kamp være håndskydevåben, fjerne eksplosioner, en forbipasserende helikopter. Disse lydlandskaber ville dynamisk samles og afspilles fra mange individuelle lyde, og det hjælper os med at undgå den kunstige følelse af et enkelt loopende spor. Samlet set var lydlandskabssystemet en vigtig arbejdshest for lydene i Half-Life 2 og stort set ansvarlig for hver lyd, du hører, der ikke er direkte drevet af gameplay."
N/A3926"#commentary\cn_009_audio_over_distance.mp3" "[ Kelly Bailey ] De store rum på Coast-kortene fik os til at søge en lydløsning til, hvordan lyd ændrer sig over afstand. På disse kort kan en fjende eksempelvis være langt over 100 meter væk, og deres pistol skal lyde anderledes på den afstand, end når de er tæt på. Vi besluttede at gemme vores lyde i en enkelt stereofil, med den nære lyd i venstre kanal og den fjerne lyd i den højre kanal. Derefter krydsfader vi under afspilning, eller vi ændrer andelen af lyd, du hører, mellem disse to kanaler baseret på afspillerens afstand fra lyden. Det var en simpel løsning, der fungerede godt, og den hjalp os med hukommelsesbegrænsninger. Du kan nemt høre det i aktion – hør bare, hvordan en Combine-soldats skud ændrer sig, når du kører mod ham."
N/A3927"#commentary\cn_010_flying_vehicle_audio.mp3" "[ Kelly Bailey ] De store flyvende fjender i spillet præsenterer en unik lydudfordring. Under kamp er de meget mere mobile end andre fjender, og de bevæger sig ofte en betydelig afstand væk fra spilleren. De er også virkelig farlige, hvis de har sigtelinje. Disse faktorer fik os til at fokusere på en lydløsning specifikt omkring okklusion. Med andre ord når du kan se fjenden, og når fjenden kan se dig. Vi ønskede at skabe en klar lydmæssig forskel mellem, hvornår de har sigtelinje. De flyvende fartøjsmotorlyde består af flere loopende lyde, som vi spiller samtidigt. Nogle af disse sløjfer behandles af DSP-systemet baseret på det rum, du er i, mens andre afspilles direkte og ubehandlet. DSP-systemet tilføjer mere af en miljøekkoeffekt, når vi kører lyd gennem dette system. Når det flyvende objekt er okkluderet bag noget, og det ikke kan se dig, øger vi procentdelen af sløjfer, der går gennem DSP-behandlingen, og det lyder som om, objektet er lidt fjernere. Så når fjenden dukker op bag et objekt, og den kan se dig, spiller vi mere af den direkte lyd. Det giver dig generelt bare en fornemmelse af, at lyden enten er fjern og retningsløs eller mere direkte i dit synsfelt. Du kan høre det, når helikopteren dukker op bag en bygning, og ideelt set kan du virkelig høre den forskel."
N/A3928"#commentary\cn_011_bullet_audio.mp3" "[ Kelly Bailey ] Hvis der er en ting, vi er sikre på, så er det, at mange kugler flyver forbi spilleren gennem hele spillet, så vi brugte en masse tid på at forsøge at perfektionere lydbehandlingen til det. Desværre er kugler i spillet essentielt øjeblikkelige, så vi kan ikke bare vedhæfte en lyd til dem og stole på deres bevægelse for positionering. Efter nogle eksperimenter landede vi på denne løsning: Ved at finde ud af det nærmeste punkt på kuglens bane til spillerens øre beregner vi den nøjagtige tid og position, kuglen konceptuelt ville passere dem. Vi spiller derefter to forskellige lyde på det tidspunkt for at forfalske en Doppler-effekt – en for kuglens komme og en for dens forsvinden. Vi forsinker afgangslyden baseret på den beregnede tid, kuglen passerede forbi."
N/A3929"#commentary\cn_012_staircase.mp3" "[ Aaron Seeler ] Der er situationer i hele spillet, der stammer fra enkle og ret ligefremme designmål, og denne trappe har to af dem. Det første var at indramme citadellet, mens det vågner, og vise spilleren, at de har stukket hånden i hvepseboet. Det andet var at fremvise vores ragdoll-system. Selvom det er standard nu, var det i 2004 stadig en nyhed at se kroppe tumle realistisk, og trapper gav en perfekt scene til at få det til at ske."
N/A3930"#commentary\cn_013_alyx_and_mossman.mp3" "[ Bill Fletcher ] I vores tidlige planer for Half-Life 2's fortælling ønskede vi at påtage os udfordringen med at gøre noget mindre eksplicit spilfokuseret. Ikke kun en historie om den åbenlyst gode spiller, der besejrer de åbenlyst onde fjender. I stedet havde vi som mål at fokusere på karakterer og deres forhold. Vi troede, det ville være interessant at udforske familie som den centrale dynamiske enhed i Half-Life 2. Spændingen mellem Alyx og Mossman opstod fra denne idé, og vi kunne godt lide det, fordi det føltes relaterbart – noget spillere kunne forstå og have empati med."
N/A3931"#commentary\cn_014_exposition_board.mp3" "[ Danika Rogers ] Vi ønskede at placere denne tætte blok med visuel historie her, fordi det er det sted, spillet er mest eksplicit i at fortælle spillerne, at de skal udforske et rum. Selvom det primære job er at opbygge en verden, bestræber vi os stadig på at fremhæve forholdet mellem Eli og Breen, som giver kontekst til verdens centrale konflikt."
N/A3932"#commentary\cn_015_city_17_awakens.mp3" "[ David Sawyer ] Den tidlige togstationssektion blev designet til at få byen til at føles indifferent overfor spilleren, som om Gordon bare er endnu en navnløs, ansigtsløs borger, der er klar til underkastelse. Men under angrebet på boligblokken og tagjagten identificerer byen spilleren som en anomali og begynder at vågne. Nu, med spilleren som aggressor, vender byen fuldt ud sin opmærksomhed mod dem. Overwatch PA-systemet, der først blev hørt under angrebet, spillede en nøglerolle i leveringen af dette budskab. Hvis spillerne lytter nøje efter, er der en masse information om byens bevidsthed. Selv når spillerne ikke var opmærksomme, formidlede lydbehandlingen dog stadig det følelsesmæssige budskab, vi sigtede efter."
N/A3933"#commentary\cn_016_elis_lab.mp3" "[ Dhabih Eng ] Vi byggede Eli's Lab efter Dr. Kleiners, hvilket gav os en bedre forståelse af, hvordan man opsætter og designer effektive Choreo-scener. Som resultat heraf var vi i stand til at skabe et mere komplekst scenarie med flere muligheder for, at det kunne reagere på spilleren. Med flere karakterer, der gjorde deres egne ting rundt omkring i rummet, blev iscenesættelsen vanskelig, og det krævede en masse iteration og playtesting for at få det til at køre problemfrit. Vores erfaring viste, at spillerne generelt ønskede at spille sammen med scenen – de havde bare brug for nok små hints til at vide, hvor vi ville have dem hen. På samme måde måtte scenen forsigtigt pause, hvis de blev distraheret, og vente på, at de vendte tilbage."
N/A3934"#commentary\cn_017_feel_free_to_look_around.mp3" "[ Dhabih Eng ] Det var altid en udfordring at balancere spillerens ønske om at udforske med scenens fortællende mål. Vi ønskede, at rummet skulle være fyldt med interessante ting at se på, men mange spillere ville ikke udforske, før de var sikre på, at de ikke ville gå glip af nogen af karakterforestillingerne. Derfor var det vigtigt for Eli at bede spilleren om at se sig omkring midtvejs gennem scenen – det signalerede, at det var sikkert at udforske. Derfra kunne vi udløse en række brugerdefinerede mini-scener baseret på, hvad der fangede spillerens interesse."
N/A3935"#commentary\cn_018_interstitial_scenes.mp3" "[ Eric Kirchmer ] Efterhånden som spiltestingen skred frem, fandt vi ofte områder, hvor spillerne mistede overblikket over deres mål, hvilket ikke er ualmindeligt i et spil som Half-Life. For at løse dette tilføjede vi mindre mellemliggende scener for at hjælpe spillere på deres vej og bestyrke deres mål. Efter at have afsluttet størstedelen af udviklingen på vores større Choreo-scener, såsom Kleiners Lab, blev det relativt ligetil at sætte disse mindre scener sammen. Vi opdagede, at brugen af karakterer i disse øjeblikke fungerede meget bedre end at stole på passiv historiefortælling eller endda en eller anden påmindelse, du ville blive vist i en pausemenu."
N/A3936"#commentary\cn_019_overwatch.mp3" "[ Josh Weier ] Under udviklingen genererede vi Overwatch-stemmen ved hjælp af et gratis tekst-til-tale-værktøj. Men da vi nærmede os udgivelse, indså vi, at vi faktisk ikke havde rettighederne til at bruge den. Så vi afholdt auditions med stemmeskuespillere for at finde nogen, der kunne matche de kvaliteter, vi kunne lide i de genererede linjer. Det tog ikke lang tid, før vi fandt Ellen McClain, hvis levering var præcis, hvad vi ledte efter. I hendes sessioner spillede vi de genererede linjer, som hun skulle efterligne, dog i hendes egen stil. Hun var lidt sarkastisk i starten, da hun blev bedt om at replikere en sådan robotstemme. Men flere år senere, da hun vendte tilbage til sin ikoniske rolle som GLaDOS i *Portal*, havde hun fundet en kreativ måde at integrere denne tone i sin præstation."
N/A3937"#commentary\cn_020_box_car_joe.mp3" "[ Laura Dubuk ] Denne lille scene indeholdt oprindeligt to menneskelige karakterer, men senere i udviklingen erstattede vi en med en Vortigaunt. Vi ønskede at vise, at vortigaunts sameksisterede med mennesker og også kæmpede mod Combine. Vi introducerede også deres evne til at helbrede spilleren, selvom vi ikke udnyttede den funktion fuldt ud i løbet af spillet. Vortigaunts blev et nyttigt fortællerværktøj til at holde dialogen kort, da deres sværmesind retfærdiggjorde deres fulde viden om verden og spillerens mål. Dette betød, at de aldrig behøvede at stille spørgsmål, hvilket belejligt omgik udfordringen med at skrive dialog til en tavs hovedperson."
N/A3938"#commentary\cn_021_mossman.mp3" "[ Marc Laidlaw ] Judith Mossman var oprindeligt baseret på en karakter, vi havde planlagt til en sektion af Half-Life 1. Dette afsnit blev skåret ud af grundspillet og genbrugt i Uplink, men uden karakteren. Vi betragter hende som den mest komplekse karakter i Half-Life 2. Vi vidste, at det ville være en balancekunst i forhold til, hvordan spilleren havde det med hende, selv før Nova Prospekt, fordi spillerens betroede kilder ikke er enige – Eli kan lide hende, men Alyx kan ikke. Vi erkendte, at der var en grænse for, hvor meget kompleksitet vi kunne klare i personforhold, men vi følte, at en stedmor-datter-dynamik var noget, spillerne ville forstå. Uanset om du er enig med Mossman eller ej, gør hun noget heroisk. Hun risikerer at være dobbeltagent for at få de oplysninger, hun har brug for for at beskytte Eli og Alyx. Hun havde bare ikke tænkt Gordon ind i planen."
N/A3939"#commentary\cn_022_hands_free.mp3" "[ Matt Wright ] På tidspunktet for udgivelsen af Half-Life 2 gav de fleste skydespil spilleren en pistol eller et nærkampsvåben lige fra start, men vi valgte at lade spillere starte tomhændet. Uden et våben var det lettere at træne spilleren på de nye måder, hvorpå de er i stand til at interagere med verden og introducere dem til vores historie. Vi ønskede, at spilleren skulle gå fra jaget til jæger, og bevæbning af dem på det rigtige tidspunkt skabte det øjeblik naturligt. Når spilleren endelig får et våben, er det slut med at løbe væk. Man siger, at nogle gange er den bedste måde at vinde på at gå væk, men vi ved alle, at det ikke er sandt. Den bedste måde at vinde på er at løbe mod noget, mens du skyder på det."
N/A3940"#commentary\cn_023_metrocop_scene.mp3" "[ Mike Dussault ] Dette er en anden scene designet til at gøre det klart, at Metrocop er skurkene – bortset fra at denne gang har spilleren et våben, så de endelig kan gøre noget ved det. Det \"noget\" kommer ud af løbet på en pistol. Vi vidste, at vi havde brug for, at spilleren følte sig retfærdig, og dette øjeblik var med til at skabe det. Metrocop er stadig menneskelige, i modsætning til resten af Combine i spillet, så vi følte, at vi var nødt til at gå den ekstra mil for at sikre, at spillerens handlinger føltes som retfærdighed og ikke kun som vrede."
N/A3941"#commentary\cn_024_moving_the_gravity_gun.mp3" "[ Ted Backman ] Da tyngdekraftpistolen var i prototypefasen, planlagde vi at give den til spilleren midtvejs gennem spillet. Men efterhånden som spiltesten skred frem, så vi styrken i dens design og indså at tyngdekraftspistolen, og endnu vigtigere, evnen til at affyre savklinger mod horder af zombier, skulle komme tidligere. Det betød, at Elis laboratorium også skulle ligge tidligere. Det var en betydelig ændring, men det var afgørende for Half-Life 2's succes. Det tjener som en god påmindelse om, at historiefortælling og gameplay er sammenflettet, og ingen af dem kan altid have prioritet; de skal arbejde sammen."
N/A3942"#commentary\cn_025_buggy_birds.mp3" "[ Adrian Finol ] I en mindeværdig Coast-playtest vendte en spiller tilbage til sit køretøj efter at have udforsket et hus og så tilfældigvis en fugl flyve forbi. Spilleren råbte efter fuglen, og bad den holde sig væk fra hans vogn, mens han klagede over, at fugle ofte ødelagde hans bil i det virkelige liv. I vores diskussion efter playtesten indså vi, at dette var første gang, vi havde objekter adskilt fra spilleren, som spilleren faktisk var interesseret i. Vi så det som en mulighed, der kunne udforskes, så vi byggede et system til at levere det øjeblik, som playtesteren frygtede. Hvis spilleren lader sin buggy være alene et stykke tid og er ude af syne, skaber vi en måge på et tilfældigt sted på køretøjets ramme. Efterhånden som tiden går, laver mågen afføringsmærker på karosseriet under den og fortsætter, indtil spilleren vender tilbage, hvorefter den flyver væk. Naturligvis ønskede playtestere at være i stand til at rengøre deres køretøj, så vi tilføjede muligheden for at vaske bilen ved at køre den i lavt vand. Det var sent nok i udviklingen til, at vi allerede havde teknologien til alt dette, så funktionen var hurtig at implementere. Det er et af de tilfælde, hvor vi ved, at kun en lille procentdel af spillerne vil opdage det, men hvis vi kan implementere denne slags detaljer effektivt og have nok af dem, vil de fleste spillere støde på mindst én."
N/A3943"#commentary\cn_026_bridge_gunship.mp3" "[ Adrian Finol ] Vi var særligt tilfredse med kampen mod kampfartøjet, selvom det er vanskeligt at sætte op på grund af niveaugeometrien. Da den er på undersiden af broen, kunne kampfartøjet bevæge sig helt rundt om spilleren og anvende alle tre dimensioner til at placere sig selv over og under på forskellige tidspunkter. Dragerne gav masser af højfrekvent dækning, så kampfartøjet fik mulighed for at bruge sin ildkraft til at skabe en sjov og dynamisk visuel og lydeffekt."
N/A3944"#commentary\cn_027_floor_is_lava.mp3" "[ Adrian Finol ] Ved at opbygge gameplay omkring bredt forståede begreber som 'jorden er giftig', blev træningen gjort lettere. Vi kunne godt lide, hvordan vores fysiksystem tillod en høj grad af kreativ frihed i, hvordan spillerne valgte at tackle situationen. Nogle byggede gangbroer ud af mange genstande, mens andre fokuserede på kun at bruge deres to foretrukne metalplader. Nogle fulgte omhyggeligt stien op i klipperne, fordi de var bekymrede for at falde, mens andre bevægede sig direkte mod udgangen, der befandt sig på genstande lige over sandet. Spillestilene varierede – nogle spillere betragtede det som en fiasko, hvis de tiltrak sig antlions og genindlæste straks, mens andre nød at krybe tilbage på klipperne for at komme sig. Vi kunne også godt lide, at det fungerede som et navigationspuslespil, men kunne omdannes til en arena, hvis spillerne foretrak det; nogle sprang bare ned på sandet og kæmpede sig vej til den bitre ende."
N/A3945"#commentary\cn_028_opportunistic_moments.mp3" "[ Ariel Diaz ] Nogle mindeværdige øjeblikke i spillet kommer fra samspillet mellem flere spilsystemer, men nogle gange er vi klar over, at disse øjeblikke sandsynligvis kun sker sjældent. Når det er tilfældet, ville vi ønske, at flere spillere oplever dem. Der er en spænding her: Jo mere vi ved, at spillerne vil støde på noget, jo mere arbejde kan vi lægge i det. Men hvis det føles for kunstigt, kan øjeblikket virke som tvunget, og spillerne reagerer muligvis ikke så positivt. Kampfartøjets filmiske død er et eksempel, hvor vi skubbede lidt til tingene og forsøgte at øge chancerne for et mindeværdigt øjeblik, uden at det er for indlysende. Udformningen af dette område og kampfartøjets flyvebaner gør det sandsynligt, at spilleren og kampfartøjet er på de rigtige steder, når det dør. Hvis de er det, udløser vi kampfartøjets nedstyrtning i bilerne. Hvis ikke, dør den på den sædvanlige måde. Det er helt 'gamey', men playtestere syntes ikke at have noget imod, når øjeblikket spillede sig godt ud."
N/A3946"#commentary\cn_029_assault_on_nova_prospekt.mp3" "[ Ariel Diaz ] Med en uendelig antlion-hær på en kystlinje, der angriber en befæstet Combine-base, var det svært ikke at have en bane inspireret af Normandiet. Vores oprindelige prototype indeholdt skyttegrave, der førte op til Nova Prospekt, med dødbringende maskingeværer, der tvang spilleren og dennes antlions til at forblive inden for skyttegravene for at overleve. Det var spændende at have maskingeværild og springende antlions, der konstant passerede over skyttegravene. Desværre kunne vi ikke få det til at fungere inden for vores budget og måtte i sidste ende sætte det til side til fordel for et helt andet layout. De monterede kanoner forblev imidlertid, da deres dødelighed viste sig nyttig til at tilskynde spillerne til at stole på deres antlions."
N/A3947"#commentary\cn_030_buggy_physics.mp3" "[ Charlie Brown ] Fysikken til buggyen krævede, at vi prøvede os frem. Vi ønskede, at det skulle føles hurtigt, selvom dens tophastighed kun var omkring 55 km/t, så vi var nødt til at snyde for at få det til at fungere. Vi tilføjede ekstra lodret kraft til turbohoppet og lidt spark bagpå, når vi brugte håndbremsen til powerslide. Uden dem betød den lave hastighed, at buggyen bare ikke var sjov at køre. Desuden var verden fuld af uforudsigeligt, fysiksystemdrevet kaos – spillerne ville helt sikkert køre buggyen ind i alle mulige slags kollisioner, så vi var nødt til at sikre, at de altid kunne komme ud. Dette krævede en masse eksperimentering og playtesting. Til sidst besluttede vi os for en temmelig fjollet, urealistisk simulering, der gjorde buggyen mere tilgivende og sværere at vende. Dens tyngdepunkt er super lavt, og hjulene, selvom de ser ud som om de drejer meget, gør det faktisk ikke. Det var vores første forsøg på et fysisk simuleret køretøj, og vi lærte en masse af det. Takket være det var vi i stand til at gøre muskelbilen i Episode 2 meget lettere at køre."
N/A3948"#commentary\cn_031_the_bridge.mp3" "[ Charlie Brown ] Denne brosektion blev inspireret af Deception Pass Bridge, lige op ad vejen fra Valves kontor. Vi byggede oprindeligt sektionen som et rent navigationspuslespil og lagde gradvist mere gameplay ind i det. Det blev også den primære testsag for vores spillers kantfriktion. I vores bevægelsessystem øger vi subtilt friktionen på spillerens deceleration, når de nærmer sig kanten af en overflade. Spillerne har aldrig bemærket det – sandsynligvis fordi det stemmer naturligt med deres mål om at stoppe ved kanten for at se ned, hvilket matcher den menneskelige tendens til at bevæge sig langsommere og forsigtigt nær en afsats. Men det er en kritisk funktion for denne del af spillet. Vi ved det, fordi vi på et tidspunkt under udviklingen ved et uheld brød det, og pludselig begyndte alle vores playtestere gentagne gange at falde i døden."
N/A3949"#commentary\cn_032_coast.mp3" "[ Chris Green ] Vi ønskede en vidåben del af spillet til buggyen, men vi havde stadig brug for en måde at begrænse spillerens bevægelse på. At vælge en kystlinje gav os en naturlig grænse langs den ene side af kortet, mens det stadig føltes åbent og ekspansivt. Det hjalp også med at visualisere virkningerne af Combines udvinding af Jordens ressourcer. Spilletestere forsøgte stadig at svømme ud i havet, så vi tilføjede igler for at afskrække dem. Iglerne kunne ikke være en rigtig, undgåelig fjende, som spillerne følte, at de kunne bekæmpe, så de er lidt magiske. Spillerne forstod generelt, at de skubbede til spillets grænser, så vi overudviklede dem ikke."
N/A3950"#commentary\cn_033_grenade_house.mp3" "[ Dave Riller ] Meget af et Half-Life-spil handler om at give spillerne lidt nye kampoplevelser rundt om hvert hjørne, selvom de bare er små justeringer af tidligere kampe. De behøver ikke alle at være færdighedsbaserede udfordringer; nogle gange kan de bare være sjove øjeblikke, hvor spilleren får mulighed for at hygge sig. Dette granathus er et af disse øjeblikke, hvor twisten er, at vi har omvendt den sædvanlige opsætning. I stedet for at lade spilleren smide granater på fjender nedenfor, har vi sat fjenderne ovenover. Den ubegrænsede granatboks er en noget klodset måde at tilskynde spillerne til at engagere sig i scenariet, men dens usårbarhed sikrer også, at spilleren stadig kan klatre op til gulvet ovenfor, selvom de har sprængt alt andet i luften."
N/A3951"#commentary\cn_034_buggy_training_course.mp3" "[ David Sawyer ] Denne træningssektion er designet til at lade spilleren lege med deres buggy. Da Half-Life 2 blev udgivet, var dette niveau af fysisk simulering i et køretøj nyt, så vi ønskede at give spillerne rig mulighed for at eksperimentere med det. Spilleren har også lige forladt Ravenholms stramme grænser, og vi kunne godt lide at give dem den kontrasterende belønning ved at kunne bevæge sig hurtigt gennem et stort rum og føle sig trygge inde i et køretøj. Vi sørgede for, at det krævede et turbospring at komme ud af dette område, hvilket fungerede som en test for at sikre, at de havde nået et niveau af komfort i deres kørsel, og også sikre, at de ikke efterlod deres buggy."
N/A3952"#commentary\cn_035_ambush.mp3" "[ David Sawyer ] En af de generelle udfordringer ved et FPS-spil i stil med Half-Life er, at spilleren konstant bevæger sig fremad i rum, de ikke kender. Det betyder, at når de befinder sig i kamp, er de i ukendte områder uden viden om, hvordan man nærmer sig kampen. Vi bruger mange forskellige metoder til at hjælpe spilleren med dette problem, og dette baghold er et eksempel. Ved ankomsten kæmper spilleren med en gruppe Combine omkring disse huse. Under kampen og udforskningen bagefter har spilleren chancen for at lære arenaens layout. Derefter, når spilleren udforsker dette loft, laver vi en ny Combine-bølge. I den anden kamp har spilleren nu fordelen ved at kende layoutet, så de kan træffe mere taktiske beslutninger for at forsvare sig mod bagholdene."
N/A3953"#commentary\cn_036_bugbait_training.mp3" "[ David Sawyer ] Vi landede på denne klodsede bugbait-træning , efter at være løbet tør for tid, da vi havde brug for, at spillerne forstod værktøjet, så Nova Prospekts design kunne fungere. Generelt sigter vi mod at tilføje nok fylde og kontekst til træning, så det ikke føles som træning – det føles som en naturlig del af at opdage noget nyt. Her klarede vi det dog ikke helt. Selvom det kan synes indlysende, var bugbait ikke noget, spillerne intuitivt forstod. Vi er godt inde i spillet nu, så spillerne har masser af erfaring med at håndtere fjender. Før vi tilføjede nogen træning, gik de første playtestere, der indsamlede bugbait, op på næste niveau og skød instinktivt den første antlion, de så – for det havde fungeret indtil da. Half-Life har en tendens til at tilskynde til en \"skyd først, stil spørgsmål senere\"-tilgang. På samme måde tænkte spillerne ikke på at kaste bugbait på Combine-soldater, da de nåede Nova Prospekt, og de tyede i stedet for til deres sædvanlige våben. Så vi havde brug for denne træning ikke kun for at vise, hvordan bugbait fungerer, men også for at demonstrere, at antlions kunne være tæt på spilleren uden at angribe ham."
N/A3954"#commentary\cn_037_vortigaunt_extraction.mp3" "[ Dhabih Eng ] Denne arena præsenterede nogle vanskelige designproblemer af et par grunde. For det første er vagten en nærkampsfjende, så vi kunne ikke tillade spilleren at nå områder, hvor vagten ikke kunne følge efter. Vi eksperimenterede med et par afstandsangreb, men kunne ikke lide resultaterne – dets dårlige angreb endte for eksempel med at se latterligt ud. Det eneste ikke-nærkampsangreb, der overlevede, var dets evne til at slå på spilleren med fysiske objekter, men dette kræver, at objekterne er inden for rækkevidde, hvilket ikke altid er garanteret. Den anden udfordring var at sikre, at uanset hvor vagten dør, kan Vortigaunten nå liget. Dette var vigtigt, da spillet ikke kan fortsætte, hvis Vortigaunten ikke er i stand til at udtrække bugbait."
N/A3955"#commentary\cn_038_dropship_deployment.mp3" "[ Doug Wood ] Det var vanskeligt at indsætte soldater fra dropskibene, da det krævede, at NPC'erne spawnede inde i et andet solidt objekt. For at få dem ud i det fri, hvor de kunne begynde at navigere normalt, spiller de straks en animation, der får dem til at springe ud af containeren, i det øjeblik de spawner. Da det fungerede, stødte vi på et andet problem – kyndige spillere ville simpelthen bare vente uden for containeren og skyde soldaterne under deres exit-animation. For at imødegå dette tilføjede vi et tårn til containeren for at forsvare soldaterne, når de forlader den. Det forhindrer ikke helt en spiller i at drage fordel heraf, især hvis de bruger et indirekte våben som en granat eller lignende, men det føltes realistisk og som en virkelighedstro modforanstaltning, som nogen, der tænker strategisk, kan tage."
N/A3956"#commentary\cn_039_laser_guided_rpg.mp3" "[ Eric Smith ] Raketstyrets laserbaserede styringssystem var en enorm hovedpine for os, fordi det var svært at lære spillerne. Mange playtestere affyrede raketstyret og dukkede sig derefter straks ned bag dækningen, hvilket betød, at de ikke så rakettens flyvevej. Endnu værre var de ikke klar over, at raketten nu vendte sig om for at flyve tilbage mod dem. Vi prøvede forskellige HUD-elementer og laserpunktindikatorer for at hjælpe, men fandt ud af, at de fleste spillere overså dem og fokuserede på fjenden i stedet. Vi lavede så mange små forbedringer, som vi kunne, såsom at understrege funktionen i Odessas tale og en forbedring af lyd og grafik omkring, hvordan kampfartøjet nedskyder direkte affyrede raketter. Selvom disse ændringer hjalp nogle spillere med at forstå funktionen, nåede vi aldrig et punkt, hvor vi følte os sikre på, at næsten alle forstod det. Vi overvejede endda at skære funktionen helt væk, men kampen mod kampfartøjet uden den var meget mindre interessant. Laserstyringen tvang spilleren til at holde kanonskibet i syne, mens raketten var i flugt, men det betød også, at kanonskibet selv havde sigtelinje, hvilket skabte en spænding, vi elskede."
N/A3957"#commentary\cn_040_performance_constraints.mp3" "[ Eric Smith ] Til den sidste Coast-arena forestillede vi os en stor finale, hvor spilleren og en gruppe borgere ville holde stand mod bølger af Combine-soldater, hvilket kulminerede i en kamp mod et kampfartøj. Desværre betød beregningsomkostningerne ved at have soldater og venlige allierede, der bevægede sig rundt i terræn, at slaget blev ved med at blive skaleret tilbage for at passe ind i vores budget. Da vi var nede på kun at have en enkelt gruppe soldater på et givet tidspunkt, var vi allerede sent i udviklingen. For sent til at foretage store ændringer i arenaen for at rumme flere fjender, så vi var nødt til at redesigne kampens flow for at holde antallet af soldater på et minimum."
N/A3958"#commentary\cn_041_lighthouse_gunship.mp3" "[ Ido Magal ] Scenariet med kampfartøjet her krævede noget arbejde at få til at udspille sig, som vi forestillede os det – vi ønskede, at det skulle udfolde sig, som det ville i en film. I den filmiske version ville et kampfartøj skyde gennem vinduerne, mens hovedpersonen bevægede sig op i fyret, og foregribe dennes bevægelse. For at simulere denne forventning i spillet oprettede vi en kompleks række triggervolumener langs trappen. Når de registrerer, at spilleren bevæger sig opad, instruerer de kampfartøjet i at vælge en ny flyverute, der matcher spillerens højde. Udløserne aktiverer også bullseye-mål i vinduerne nærmest spilleren – disse er usynlige spilobjekter, som fjendens AI straks vil opfatte som fjendtlige – og beder kampfartøjet om at skyde mod vinduerne. Denne blanding af AI og scripting er central i Half-Lifes kampscenarier. AI'en styrer NPC'ernes generelle, adaptive adfærd, mens scripting tilpasser sig til hvert scenaries unikke krav."
N/A3959"#commentary\cn_042_crane.mp3" "[ Jakob Jungels ] Kranen krævede en masse finjustering for at få den helt rigtig. En genstand, der havde brug for at generere så meget fysisk kraft, var altid risikabelt i betragtning af begrænsningerne i vores stivlegemefysik og ødelæggelsesteknologi. For eksempel ville magneten aldrig fuldt ud opfylde spillerens forventninger til noget med så meget masse. Men fordi kranen stod stille, kunne vi omhyggeligt vælge alt inden for dens rækkevidde og finjustere efter behov. Heldigvis så de fleste spillere ikke ud til at lægge mærke til dens hårdere kanter, sandsynligvis på grund af den rene nyhed ved at interagere med noget lignende i et vagt realistisk fysikmiljø."
N/A3960"#commentary\cn_043_flashlight_power.mp3" "[ Jeff Lane ] Beslutningen om at have både sprint og lommelygte til at dele HEV-dragtens kraft var kontroversiel i Half-Life 2. Oprindeligt var det kun sprint, der brugte dragtens kraft, hvilket gav mening, da det kun var meningen, at det var en kort hastighedsforøgelse. Lommelygten kan derimod bruges på ubestemt tid. Men playtesting afslørede et problem – spillerne forlod ofte mørke områder uden at indse, at deres lommelygte stadig var tændt. I stærkt oplyste, åbne områder som kysten kunne vores præstationsbudget ikke understøtte, at lommelygten var tændt kontinuerligt, så vi havde brug for en måde at slukke den uden spillerens involvering. At begrænse dens kraft virkede som en simpel løsning, der også havde den fordel, at det tilføjede en vis spænding i mørke områder. Udfordringen blev derefter: Hvilken ressource skal den bruge? Vi havde allerede dragtens kraft og ønskede ikke at rode med brugergrænsefladen med en ny ressource kun til lommelygten. Vi legede med ideen om andre spillerevner drevet af dragtens kraft, og tænkte, at det kunne være interessant at få spillerne til at foretage afvejninger mellem dem. Dette er et godt eksempel på, at spildesign ofte handler om at vælge mellem ufuldkomne løsninger. Vi elskede ikke ideen om sprint og lommelygten, der deler en ressource, men vi ønskede heller ikke, at flere ressourcer gjorde brugergrænsefladen tilrodet. I episode 2 besluttede vi, uden planer om at tilføje noget andet, der forbrugte dragtens strøm, i sidste ende at give lommelygten sin egen separate ressource."
N/A3961"#commentary\cn_044_open_world_loot.mp3" "[ Jeff Lane ] Coast-regionens åbne landskab introducerede et nyt problem for os; hvordan distribuerede vi genstandsbelønninger. I Half-Life belønner vi typisk spillerne for at udforske. Hvis du ser vejen frem, men bemærker noget ved siden af, er der sandsynligvis noget nyttigt, hvis du tager dig tid til at kigge. Da vi først begyndte at spilteste vores Coast-kort, gemte vi belønninger væk i hjørnerne af udendørsområderne. Dette førte dog til en værre oplevelse med buggyen. De vidåbne rum betød, at der altid var masser af små områder, der så ud som om, de kunne indeholde noget, og spillerne blev ved med at stoppe og træde ud af buggyen for at kigge. Det blev kedeligt og afbrød det sjove ved niveauet. Så vi fjernede de spredte belønninger. Men dette rejste et nyt problem: hvordan fortæller vi spilleren, hvornår det er værd at komme ud af buggyen? Efter lidt overvejelser etablerede vi en regel: enhver form for menneskelig konstruktion ville altid komme med gameplay-indhold og udforskningsbelønninger, mens rent naturlige områder ville blive efterladt tomme. Vi kunne ikke fortælle spillerne dette direkte, men det stemte godt overens med deres naturlige antagelser, og vi forstærkede det konsekvent med områder som dette."
N/A3962"#commentary\cn_045_gas_station.mp3" "[ Jeff Lane ] Vi havde store planer for dette encounter. Vi forestillede os at bygge en tankstation, som spilleren ville kæmpe omkring, sandsynligvis antænde gastankene og sætte ild til alt. Vi forestillede os, at spilleren kørte væk fra en rasende ild. Men budget og ydeevne var hårde begrænsninger i 2003, og stationen blev ved med at blive mindre og enklere for at passe ind i Coast-regionens store niveauer. Vores planer for et dynamisk brandsystem blev ikke realiseret, og det gav ikke længere mening at bygge det – der er altid en grænse for, hvor meget arbejde vi kan retfærdiggøre for et enkelt encounter. I sidste ende er de eneste rester af vores oprindelige vision de eksplosive gastanke."
N/A3963"#commentary\cn_046_buggy_introduction.mp3" "[ John Cook ] Vi ønskede noget mere engagerende til buggyens introduktion end bare at få spilleren til at hoppe ind og køre væk. Kranen hjalp med det. Det afgørende var, at vi havde brug for, at spillerne lærte, hvordan de vender buggyen, når den flipper over, og denne sekvens tvang dem ud i den situation. Træning under pres er altid vanskeligt, men vi ønskede at understrege antlion-angrebet som grunden til at blive inde i buggyen. Så vi holdt antlion-truslen aktiv og gav et par borgere på monterede kanoner som ildstøtte. En lille bonus: Spillerne får også oplevelsen af at blive løftet af kranen – lige før de kommer til at betjene en."
N/A3964"#commentary\cn_047_crossbow.mp3" "[ John Cook ] Dette er spillerens første mulighed for at få armbrøsten i spillet, og når man ser tilbage, er det lidt overraskende, at vi ikke indespærrede den. Det er helt muligt for spilleren at køre lige forbi den. For at gøre det mindre sandsynligt oprettede vi vejspærringen og udsigtspunktet for at opmuntre spillerne til at komme ud af buggyen, hvorefter de ville få øje på armbrøsten og genstandskassen. Playtesting viste, at næsten alle spillere stoppede og tog våbnet, men dette er et tilfælde, hvor forskellen mellem playtesting og rigtigt spil kan have betydning. En playtester, der har spillet siden starten af Coast-regionen, er måske ikke så træt af udforskning som en, der har spillet helt fra starten af spillet. Så vi placerede en anden armbrøst et par niveauer længere fremme, direkte på spillerens sti vej i Nova Prospekt."
N/A3965"#commentary\cn_048_rollermines.mp3" "[ Josh Weier ] Rulleminerne blev skabt for at udfylde behovet for en fjende, der kunne true spillerne, mens de kørte buggyen. Da spilleren i buggy i praksis var en fuldt fysisk simuleret enhed, troede vi, at det ville være interessant også at have en fysisk simuleret fjende. Manhacken havde allerede vist os, hvordan denne tilgang kunne føre til en fjende med masser af interessante interaktioner med verden. Så vi byggede rulleminen – en bold, hvis bevægelse udelukkende er drevet af at generere drejningsmoment på sig selv – og itererede på dens opførsel, indtil den var sjov at køre imod. Rulleminer er ikke særligt farlige for buggyen, men hvis du lader dem samle sig i hobetal, kan de blive et problem, især i nærheden af en klippe. Vi sørgede også for, at de fungerede godt, når spilleren er til fods, så niveaudesignerne kunne få et par ekstra møder ud af dem."
N/A3966"#commentary\cn_049_sandtrap_thumper.mp3" "[ Laura Dubuk ] De eksplosive tønder er til rådighed, så spilleren kan bruge dem mod antlions, mens de står sikkert inden for Thumperens beskyttelse. Men vi bruger også dette som et tip til det kommende encounter med Antlion-vagterne, hvor spillerne ofte bruger lignende taktikker for at vinde kampen. Valgfri spillerhandlinger, som affyring af sprængstoffer med tyngdekraftspistolen, kan blive glemt, hvis de ikke bruges regelmæssigt. Med den brede vifte af offensive muligheder, vi giver spillerne, er der ingen garanti for, at de har brugt denne evne for nylig. Så her foreslår vi subtilt, at de bringer det tilbage i deres værktøjskasse, før de står over for vagten."
N/A3967"#commentary\cn_050_coast_kickoff.mp3" "[ Marc Laidlaw ] Denne mellemliggende scene kom sent i udviklingen for at forbinde Ravenholm med Coast-regionen. Har du bemærket en tendens? En hel del af bindevævet i vores spil falder sent på plads. I dette tilfælde betød det, at vi måtte skyde genveje, hvor det var muligt – vi havde ikke engang tid til at animere Alyx på skærmen. Denne slags scener er altid en udfordring at gøre interessante, og det lykkedes os ikke med den her. Det er et godt eksempel på, hvad der sker, når NPC'er behandles som skilte uden at tilføje karakter til dem eller scenen. Resultatet er et glemt øjeblik, hvor spillets kanter viser sig. Men det er spiludviklingens natur – du har kun så meget tid, og du er nødt til at beslutte, hvor du skal bruge den. Kleiner's Lab og Eli's Lab var meget vigtigere, så det var her, vi fokuserede vores indsats."
N/A3968"#commentary\cn_051_odessa_cubbage.mp3" "[ Marc Laidlaw ] Odessa Cubbage er et eksempel på den slags cameo-karakter, der fungerede godt. Han er en underholdende fyr med nogle underholdende detaljer, der bor inde i sin egen lille boble. Da han ikke forlader sit scenarie, er han fri til at være overdrevet nok til at skille sig ud. Vi startede med hans model, som blev genbrugt fra en klippet sektion af spillet, og opkaldte ham efter titlen på en spam-e-mail, vi modtog. Modellen var oprindeligt en norsk fisker, og den passede ikke helt som englænder, så vi satte et overskæg på ham – og i det øjeblik blev Odessas karakter født. Han er i sidste ende en charlatan, hvor alt ved ham er falsk – hans accent, hans overskæg, alt. Han ville aldrig sætte sig selv i fare, hvilket gjorde ham til den perfekte person til at give Gordon raketstyret og forklare nøjagtigt, hvordan man bruger det."
N/A3969"#commentary\cn_052_28_transitions_later.mp3" "[ Marc Laidlaw ] Efter at have sammensat et par niveauer med mørke tunneler som overgangsrum, indså vi, at vi kunne undergrave spillernes forventninger ved at bygge et andet, der syntes at være en overgang, men i stedet indeholdt noget andet. Som alle andre så vi 28 Days Later i 2002, elskede den og ønskede straks at skabe et eskalerende zombie-encounter i en af vores mørke tunneler. Det faldt hurtigt på plads, og vi var tilfredse med resultatet. Flere år senere mødte vi Alex Garland, der havde skrevet filmen. Han havde spillet og nydt Half-Life 2, og vi indrømmede, at hans film inspirerede dette afsnit."
N/A3970"#commentary\cn_053_finest_mind_of_his_generation.mp3" "[ Marc Laidlaw ] Her er en anden lille fyldscene, der endte med at fungere godt. Det eneste krav for dette øjeblik var et ønske om at lære spilleren at holde sig væk fra sandet. I tidligere scener var vi stadig fokuseret på blot at gøre dem funktionelle, men da vi kom til denne, blev vi mere komfortable og begyndte at nyde processen med at bruge ekstra tid på disse øjeblikke. Dermed skubbede vi karaktererne ud over blot at være skilte, hvilket skabte noget mere interessant og underholdende. Efter udgivelsen endte Lazlo med at samle sig et større følge, hvilket mindede os om, hvor svært det er at forudsige, hvad spillerne vælger at holde fast i."
N/A3971"#commentary\cn_054_bridge_playtesting.mp3" "[ Matt Boone ] Brosektionen var altid et højdepunkt i playtests, hvor testere konsekvent havde stærke reaktioner på det. Den spænding, de følte, mens de langsomt gik over bjælkerne, var synlig i deres bevægelser. Over tid lagde vi flere udfordringer ind i gennemgangen, og playtests blev kun mere underholdende at se. Fra toget, der rumlede over broen og rystede spilleren, til en overraskende hovedkrabbe i en hytte, der virkede som et sikkert tilflugtsted midtvejs i banen. Vi følte os lidt skyldige over at nyde spilletesternes synlige stress, men vi var ikke totale monstre: Efter at spillerne kom over broen, drog de et lettelsens suk, deaktiverede Combine-skjoldet og indså, at de måtte vende tilbage over undersiden. Bekymret for, at de måske ville kede sig på den anden tur, besluttede vi at tilføje et kampfartøj for at holde dem selskab ude på bjælkerne."
N/A3972"#commentary\cn_055_thumper_final_stage.mp3" "[ Matt Boone ] Vi kunne godt lide den sidste fase af Thumpers, hvor deres formål bliver vendt om. I stedet for at tjene som et sikkerhedsværktøj fungerer de nu som en blokering for spillerens antlion-hær. Vi burde dog sandsynligvis have indarbejdet en mere grundig Thumper-træning inden dette tidspunkt. Selvom det var acceptabelt for spillere kun delvist at forstå Thumpers i de tidligere Coast-niveauer, er indsatsen højere nu, fordi spillerne også prøver bugbait for første gang. Spillere, der ikke er klar over, at denne første Thumper forhindrer deres antlions i at bevæge sig fremad, kan misforstå, hvordan bugbait fungerer. Hvis de kaster bugbait på soldater i den første bunker, og der ikke ankommer nogen antlion, kunne de konkludere, at bugbait er upålideligt eller ikke fungerer som forventet, og skifte tilbage til at bruge deres våben i stedet."
N/A3973"#commentary\cn_056_buggy_tools.mp3" "[ Matt Wright ] Vi ønskede, at buggyen skulle være mere end bare et rejsemiddel, så vi besluttede at sætte et våben på den. Vi valgte Tau-kanonen, et Half-Life 1-våben vi kunne lide, men ikke havde fundet et sted til i Half-Life 2. Tau-kanonen kan skyde gennem vægge, hvilket gør den vanskelig for niveaudesign, så vi begrænsede den til Coast-regionen. Så snart man introducerer væggennemtrængende våben, bliver niveaudesignet meget hårdere. Desuden monterede vi en ammunitionskasse på bagsiden af buggyen, hvilket gav spilleren ubegrænset SMG-ammunition i hele Coast-regionen. Dette var især nyttigt for playtestere, der kæmpede med de uendelige antlions, der dukkede op af sandet."
N/A3974"#commentary\cn_057_antlion_guard.mp3" "[ Matt Wright ] I sjældne tilfælde kunne spillerne finde sig selv i en situation, hvor de ikke var i stand til at dræbe antlion-vagten i denne arena. Dette kunne ske, hvis de løb tør for ammunition og også havde misbrugt alle de tilgængelige fysiske objekter og ikke har efterladt noget at affyre med tyngdekraftspistolen. For at løse dette problem tilføjede vi en borger på det monterede kanontårn over porten som en sikkerhedsanordning, så en spiller, der sidder fast, kunne regne med, at borgeren dræber vagten."
N/A3975"#commentary\cn_058_terrain_and_performance.mp3" "[ Mike Dussault ] Vores præstationsbudget var ofte en betydelig begrænsning, når det kom til kamp, og endnu mere ved kamp på terrænoverflader. Når NPC'er bevæger sig, udfører de mange små rumlige målinger for at afgøre, om de sikkert kan navigere på deres valgte vej. For at hjælpe med at visualisere det, skal du forestille dig, at de ikke kan se og konstant vifter med en pind foran sig for at kontrollere, om vejen er klar. Ydelsesomkostningerne ved disse målinger stiger med kompleksiteten af verdensgeometrien. Vores terrænforskydningssystem skaber ujævne overflader ved hjælp af mange polygoner – langt mere end de perfekt flade gulve, der findes andre steder. Dette betød, at NPC'er, der bevægede sig på terræn i Coast-regionen, var mere ressourcekrævende end i andre områder, og den begrænsning dikterede omfanget af mange encounters i denne del af spillet."
N/A3976"#commentary\cn_059_area_portals.mp3" "[ Mike Dussault ] Én præstationsudfordring, vi stod over for i Coast-regionen, var at håndtere brede åbne rum, der omfattede bygninger med meget detaljeret interiører – eller i det mindste var de detaljerede efter 2003-standarder. Når spilleren var udenfor, ønskede vi at afsætte så meget af vores budget som muligt til gengivelse af det rum uden at miste ressourcer til bygningens interiør. Men medmindre vi var villige til at sømme hvert vindue og dør til, kunne spilleren stadig se indenfor. For at løse dette oprettede vi en funktion kaldet områdeportaler, som blev placeret i hvert åbne vindue og dør. En områdeportal forudberegner et fladt billede af bygningens interiør. Under spillet, når spilleren er et stykke væk, viser områdeportalen dette forudberegnede billede over vinduet eller døren, så vi kan springe over gengivelsen af det faktiske interiør. Når spilleren nærmer sig, krydser vi jævnt mellem områdeportalens billede og bygningens faktiske indhold. Med omhyggelig brug hjalp områdeportaler os med at nå vores præstationsmål på kysten – sammen med den lejlighedsvise dør, der lukkede sig bag dig."
N/A3977"#commentary\cn_060_buggy_removal.mp3" "[ Miles Estes ] Da vi nåede det punkt, hvor vi ønskede, at spilleren skulle efterlade buggyen, måtte vi være meget eksplicitte om det. I hele Coast-regionen havde spillerne forladt buggyen og derefter vendt tilbage til den, så vi fandt ud af, at playtestere ville prøve at tage den med, hvis det så bare lidt muligt ud. Denne lille garagescene eksisterer primært for at signalere klart, at spilleren er færdig med at køre og skal fortsætte til fods."
N/A3978"#commentary\cn_061_d2_coast_04.mp3" "[ Randy Lundeen ] Dette kort var faktisk det første område af Coast-regionen, som vi byggede, før kranen og andre elementer eksisterede. Den drænede havbund og rustne skibe var nogle af de tidligste kunstværker, vi udviklede. År senere fremviste vi kortet i vores 2003 E3-præsentation, selvom meget af gameplayet stadig var ved at blive regnet ud på det tidspunkt. Som et resultat blev denne præsentation en nyttig vision for os at arbejde hen imod, da vi begyndte at bygge hele Coast-regionen."
N/A3979"#commentary\cn_062_transition_tunnels.mp3" "[ Randy Lundeen ] Det krævede, at vi udviklede en måde at håndtere niveauovergange på, for at kunne bygge Coast-regionen. For at bevæge sig fra et niveau til et andet, måtte vi gemme alt i overgangsrummet, når spilleren forlader det første niveau, og gendanne det på det næste niveau efter indlæsningen. Helt kritisk er vi også nødt til at gemme og gendanne alt, hvad der er synligt for spilleren i overgangsområdet, selvom det ligger uden for selve rummet. Af denne grund tilstræber vi at holde overgangsrummene så små og lukkede som muligt. I det meste af spillet fungerer et lille rum godt til dette formål. Men i Coast-regionen havde vi brug for en anden løsning. Efter nogle eksperimenter bestemte vi os for mørke tunneler. Udover at kunne genbruges på en troværdig måde tillod tunnelerne os at tilføje et stærkt lysskær for enden for at skjule det faktum, at vi ikke kan gengive det, der ligger foran spilleren, fordi det eksisterer på et helt andet niveau."
N/A3980"#commentary\cn_063_sniper_alley.mp3" "[ Robin Walker ] Dette afsnit af spilsporet blev tilføjet sent i udviklingen, efter at vi flyttede Eli's Lab og Ravenholm til at komme før Coast-regionen. Selvom du måske tror, at vi bygger spillet lineært, delte vi faktisk opgaven op i tre forskellige grupper og arbejdede parallelt på forskellige sektioner, der mest startede midt i spillet. Hver gruppes første pas fokuserede på at fastslå kernen i deres sektion, før de gik videre. Da vi så havde lavet en grov version af hele spillet, gik vi tilbage til hvert afsnit for at finpudse det – tilføjede vellykkede elementer fra andre områder og fjernede det, der ikke fungerede. I nogle tilfælde, såsom i Ravenholm, blev hele sektioner flyttet. Derefter, efter at Ravenholm var blevet flyttet, havde vi brug for et nyt stykke til at forbinde det med Coast-regionen, som er det område, du kommer til nu. I betragtning af tidsbegrænsningerne blev dette korte afsnit bygget ved hjælp af eksisterende, gennemprøvede gameplayelementer, som snigskytter og Combine-soldater."
N/A3981"#commentary\cn_064_battery_finding.mp3" "[ Robin Walker ] Med den øgede tæthed af objekter i Half-Life 2's gameplay-rum troede vi, at det ville være interessant at få spillerne til at søge efter et bestemt element, især hvis der var en vis logik i, hvor det kunne findes. På denne måde kunne spillerne finde genstanden enten ved omhyggelig observation og deduktion, eller bare ved at brute force-gennemsøge hele området. Da vi allerede havde modeller til biler og batterier, var det et naturligt skridt at skabe en lille losseplads, som spillerne kunne udforske. Vi gemte også et par ekstra batterier på uventede steder for de spillere, der valgte brute force-metoden. Som med andre genstandsbaserede puslespil var der brug for en sikkerhedsanordning, hvis spillerne mistede batterierne. Du kan prøve at smide dem alle ud over klippen, hvis du vil se, hvad der sker."
N/A3982"#commentary\cn_065_boathouse.mp3" "[ Scott Dalton ] I Half-Life 1 opdagede vi, at vi kunne få en masse værdi fra scenarier, hvor forskellige AI-fjender kæmper mod hinanden. Det er sjovt for spillerne at se dem gå i kamp med hinanden, og det er meget lettere at observere fjendens adfærd, når du ikke er den, der bliver truet. Dette første møde mellem antlions og Combine-soldater er designet til at være en sjov mulighed for at ramme noget med buggyen, men det tjener også til at fremhæve Thumperen. Ved at se soldaterne bruge Thumperen til at holde antlions væk, håbede vi, at flere spillere ville forstå dens formål. Vi kunne godt lide, hvordan soldaterne demonstrerede værdien af at blive i nærheden af Thumperen, mens de kæmpede mod antlions."
N/A3983"#commentary\cn_066_buggy_theft.mp3" "[ Scott Dalton ] Da vi byggede enden af Coast-regionen, besluttede vi at lade Combine stjæle spillerens buggy. Det giver virkelig ikke logisk mening, men efter at have set så mange playtests, hvor spillerne udviklede en stærk tilknytning til deres buggy, ønskede vi at lege med den følelsesmæssige forbindelse. Da vi implementerede tyveriet, fik vi spiltestere, der råbte ad Combine for at have stjålet deres øse – noget vi tog som et tegn på succes. Soldaten, der skyder ned fra klippetoppen, er der simpelthen for at tiltrække spillerens blik, hvilket udløser bliktriggeren og spawner dropskibet med buggyen. Når vi ser det nu, 20 år senere, bliver vi ramt af, hvor latterligt det hele er."
N/A3984"#commentary\cn_067_snipers.mp3" "[ Ted Backman ] Half-Life 2-holdet var på intet tidspunkt særlig stort, så vi ledte altid efter måder at skabe nyt gameplay uden høje produktionsomkostninger til aktiver. Snigskytten er et godt eksempel. Det har ingen egentlig model – bare en laserstråle – så det krævede ingen kunst- eller animationsstøtte. Når den dør, spawner den blot en Combine Soldier-ragdoll og smider den ud ad vinduet. På trods af denne simplicitet fik vi en masse unikt gameplay ud af det. Vi var især tilfredse med, hvordan det interagerede med fysikobjekterne i spilverdenen. Spillerne er vant til at udnytte eksplosive genstande i nærheden af fjender, så det føltes passende at have en fjende, der vendte den dynamik, når spilleren var i dækning."
N/A3985"#commentary\cn_068_buggy_model.mp3" "[ Ted Backman ] Buggyens model gennemgik mange iterationer, før den nåede sin endelige version. Vi gennemgik design, der opfyldte både vores kunstneriske og fysiske simuleringsbehov, men vi ramte derefter et uventet problem: Mange playtestere, selv erfarne FPS-spillere, blev køresyge, mens de kørte den. Sammen med nogle simuleringsjusteringer opdagede vi, at ændring af buggy-modellen hjalp – jo mere modellen skjulte verden, jo værre blev køresygen. Så vi begyndte at fjerne dele af modellen og fjerne mere og mere af karrosseriet, indtil spillerne holdt op med at føle sig køresyge. Især det at kunne se jorden gennem den manglende undervogn gjorde en mærkbar forskel."
N/A3986"#commentary\cn_069_antlion_design.mp3" "[ Ted Backman ] I noget af det tidligste designarbejde til spillet havde vi planer om flere centrale fremmede racer, hvor Combine kun var én af dem. En af de andre racer var en religiøs insektoid art, og antlions var en del af det. Senere, da vi udviklede Coast-regionen, begyndte vi at se dem mere som skadedyr, der kom gennem Xen-portalerne sammen med hovedkrabber og andre skabninger. Selvom de faktisk ikke er fra Xen, hærger de alle fire verdenshjørner af enhver verden, de kommer til – meget lig kakerlakker."
N/A3987"#commentary\cn_070_explosive_barrels.mp3" "[ Brian Jacobson ] Her introducerer vi eksplosive tønder, en fast bestanddel i skydespil, men med et nyt twist: det andet pistolskud sætter tønden i brand og starter en tidsbestemt detonation. Et tredje skud detonerer tønden med det samme. På denne måde kunne spillerne enten forsinke eksplosionen eller udløse den med det samme, afhængigt af situationen. Spillere ønsker måske at fodre en eksplosiv tønde til en barnacle og derefter skyde den to gange som en praktisk og sikker måde at rydde en klynge af dem af vejen på. Den forsinkede eksplosion skabte også mere interessante kædereaktioner mellem flere tønder. Eksploderende tønder var en fanfavorit i serien, men blev også internt foretrukket af niveaudesignere, der ofte følte, at spillet aldrig kunne have nok af dem."
N/A3988"#commentary\cn_071_ragdoll_magnets.mp3" "[ Dario Casali ] Half-Life 2s fysik gav os en række værktøjer til at gøre kampe mere spændende. For eksempel omdirigerer vi subtilt deres skud mod ødelæggende genstande i nærheden, når fjender rammer ved siden af spilleren, hvilket tilføjer kaos og skaber en action-filmfølelse. Vi brugte også fysik til at tilføje tip. Vi skabte det, vi kaldte 'ragdoll-magneter' på tværs af spillet for at få fjendens lig til at falde på interessante og dramatiske måder – såsom ned fra afsatser eller ind foran et tog."
N/A3989"#commentary\cn_072_helicopter_peekaboo.mp3" "[ Dave Riller ] Combine-angrebshelikopteren som central antagonist var noget, vi ønskede at udvikle gennem hele kapitlet. Den utrættelige helikopter blev en karakter i sig selv. Hvis du lytter efter og ser opad her, kan du høre dens motor og se den flyve langs togsporene og i det fjerne. Dette første glimt er et lille stykke forvarsel, hvor dens tilstedeværelse bliver mere udtalt over tid – indtil du til sidst kæmper mod den."
N/A3990"#commentary\cn_073_iterative_passes.mp3" "[ David Speyrer ] Nogle kapitler i spillet, såsom fodsektionerne af kanalerne og Ravenholm, blev udviklet over flere omgange af forskellige kabaler. Vi fandt ud af, at det førte til større variation i oplevelsen, hvis vi overdragede banerne på denne måde, og en højere tæthed af interessante øjeblikke, da hver kabale tilføjede deres unikke detaljer til banerne. I den del af kanalerne, hvor spilleren færdes til fods, etablerede den første gennemgang kunstretningen og spillerens vej sammen med de brede streger og nogle større nedslag i oplevelsen. Men alfa-playtesten for hele teamet identificerede utilstrækkelig spænding og en noget ensformig oplevelse her. I vores anden runde vendte vi tilbage til banen udelukkende med fokus på at skabe den spænding, og vi øgede tætheden af øjeblik-til-øjeblik-scenarier kraftigt."
N/A3991"#commentary\cn_075_pistol_design.mp3" "[ Josh Weier ] Standardpistolen er spillets arbejdshest og fungerer ikke kun som det første afstandsvåben, du lærer at bruge, men også som en metode til at interagere med fysik og ødelæggelige genstande på sikker afstand i løbet af hele spillet. For at få den til at føles mere lydhør og sjov at bruge, anvender pistolen en genaffyringsmekanik, der er unik for den i spillet. Pistolen skyder så hurtigt, som spilleren kan klikke på skydeknappen, hvilket betyder, at de mærker et øjeblikkeligt svar på deres input, og jo hurtigere de kan klikke, jo hurtigere kan de skyde."
N/A3992"#commentary\cn_076_shatterglass.mp3" "[ Josh Weier ] Da vi designede tidlige niveauer, hvor der er færre mekanikker i spillerens værktøjssæt, fandt vi ud af, at det er lige så engagerende at sætte fokus på nye tekniske funktioner i stedet, som vi gjorde her med glas, der kan knuses. Til den knusende effekt blev glas opdelt i et gitter af små firkanter, så vi kunne spore, hvilke der var intakte eller ødelagte, og kunne sprænge større sektioner ud, når nok firkanter ikke længere var forbundet. Hver firkant blev gengivet med en unik tekstur baseret på status for dens nærliggende firkanter, hvilket skabte de skarpe, takkede kanter mellem brudt og intakt glas. Selvom glasbrydning nu er almindeligt i spil, var det noget, vi ikke havde set meget af, da vi lavede Half-Life 2, og vi var utroligt tilfredse med det niveau af realisme og dynamik, det bragte til spillet."
N/A3993"#commentary\cn_077_lambda_caches.mp3" "[ Laura Dubuk ] Teknisk set findes den første lambda-cache i Kleiners laboratorium, men dette er den første, spilleren finder på egen hånd. Vi tilføjede lambda-caches for at tilskynde til udforskning og for at antyde overfor spillerne, hvor skjulte ressourcer kunne findes, med fiktionen om, at de blev placeret af modstandsbevægelsen som en del af deres underjordiske oprør. I Half-Life blev indholdet af forsyningskasser forudbestemt af niveaudesignet. I HL2 introducerede vi adaptive genstandskasser, der giver spilleren det, de mangler på det givne tidspunkt, baseret på ressourcemål sat af niveaudesigneren."
N/A3994"#commentary\cn_078_scanners.mp3" "[ Kerry Davis ] Scannere præsenterede en vanskelig spildesignudfordring. Selvom vi godt kunne lide, hvordan deres dystopiske tilstedeværelse hjalp med at formidle Combine-besættelsen som en undertrykkende overvågningsstat, ønskede vi faktisk ikke, at de skulle skyde på spilleren. Vi fandt ud af, at vi ikke kunne gøre det sjovt at sigte mod himlen for at ramme en lille, mobil fjende med en konstant højdefordel. Da vi elskede deres rolle i historien, besluttede vi, at scannere i kamp primært ville tjene som øjne og advare nærliggende fjender om spillerens tilstedeværelse – en funktion, vi forstærkede med lydeffekter fra soldaterne. Desuden ville de kun være i stand til at chikanere spilleren med stærkt lys og lejlighedsvis ved at styrtbombe spilleren efter at have taget nok skade."
N/A3995"#commentary\cn_079_surface_properties.mp3" "[ Ariel Diaz ] Vi afspiller brugerdefinerede fodtrinslyde, når spilleren går på det glatte mudder. Dette var et system kaldet overfladeegenskaber, der brugte materialetypen til at bestemme de lyde og andre effekter, der skulle opstå, når man gik på eller skød på den. Tidligere i udviklingen havde vi en effekt, der bremsede spillernes bevægelse, når de gik på mudderoverflader. Dette blev dog fjernet i den lancerede versionen, da vi besluttede, at det var for strafende."
N/A3996"#commentary\cn_080_combat_entrances.mp3" "[ Dario Casali ] Det er altid akavat at løbe rundt om et hjørne ind i et nyt område bare for at se fjender stå der, og det får verden til at føles mindre levende og mere som et skydegalleri. Så vi var motiverede til at introducere fjender i kamprum på mere interessante og dynamiske måder, der kommunikerede planlægning og intentionalitet fra deres side, som om disse soldater havde en plan for Gordon, allerede før han dukkede op. Metrocops i denne scene hopper ned i rummet via scriptede sekvenser, og senere i spillet bruger vi rappelling på en lignende måde. Det betyder ikke noget, hvor de kommer fra i virkeligheden, fordi spillerne ender med at fortælle den historie selv. Vi fandt ud af, at kamp i sidste ende skulle have en historie indbygget i sin opsætning: et baghold, en overraskelse, en bølge, et angreb – alle disse scenarier bruger meget af den samme fjendtlige AI, men alle føltes anderledes for playtesterne."
N/A3997"#commentary\cn_081_mounted_gun_gallery.mp3" "[ Dave Riller ] Der foregår et par ting i denne scene: tårnet, der skyder mod de nedbrydelige kasser bagved, lærer spillerne ikke at angribe truslen direkte og i stedet bruge ruten gennem kloaken til at besejre den. Og når de når tårnet, nyder spillerne at bruge det i et skydegalleri med en bølge af Combine-soldater og styrtbombescannere. Vi begynder også at introducere den missilaffyrende Combine APC, der presser spillerne videre og dukker op igen senere i kapitlet."
N/A3998"#commentary\cn_082_barnacle_bowling.mp3" "[ Josh Weier ] Dette er et tilfredsstillende eksempel på, hvordan en flok designelementer kan samles i en matrix af interaktioner for at skabe et mindeværdigt scenarie for spilleren. Vi har barnacles, vores fysiksimulering, glatte mudderoverfladeegenskaber og sidst men ikke mindst: eksplosive tønder. Du er stødt på alle disse på egen hånd, men de blander sig naturligt sammen for at skabe et øjeblik, vi har kaldt 'barnacle bowling'."
N/A3999"#commentary\cn_083_barnacle_introduction.mp3" "[ Mike Dussault ] Da barnacles kan være forvirrende, når spillerne først møder dem, ønskede vi at introducere dem på en måde, der viste spillerne deres opførsel på sikker afstand. Vi besluttede at gøre det gennem en slags rovdyr/byttescene som i et naturprogram. Men som altid krævede scener som denne en masse iteration for at sikre, at spillerne så dem."
N/A4000"#commentary\cn_084_physics_in_puzzles.mp3" "[ Eric Smith ] Ofte trækkes enklere mekanikker, spilleren har mødt tidligere i spillet, fra mere komplekse som en form for træning. Vippepuslespillet, den første fysikbaserede indretning i spillet, blev faktisk afledt af et senere, mere indviklet vaskemaskinespuslespil i kanalerne. Vippen bruger de samme principper med masse og ramper, men på en mere ligetil måde, som spillerne direkte kan interagere med, hvilket hjælper dem med at forstå spillets fysik og gøre senere gåder lettere at tackle. Dette puslespil fremhæver også den analoge karakter af fysiksystemet, hvor placeringen af cementblokke og spillerens egen vægt begge indgår i løsningen."
N/A4001"#commentary\cn_085_combine_attack_helicopter.mp3" "[ Brian Jacobson ] Spillere har set glimt før, men her introducerer vi fuldt ud den primære boss i kanalkapitlet: Combine-angrebshelikopteren. Denne helikopter ødelægger ubarmhjertigt spillerens dækning og tvinger dem til at bevæge sig fremad eller risikere at blive skudt ned. Vi ønskede, at denne sekvens skulle føles anspændt og truende, hvor helikopteren syntes alt for kraftig at konfrontere direkte, og at opretholde denne intensitet gennem kanalerne indtil det endelige opgør i reservoiret. For at opnå dette begrænsede vi kraftigt helikopterens bevægelse baseret på specifikke gameplay-mål. På dette kort, der er designet som et løb fra dækning til dækning under beskydning fra helikopteren, skabte vi en cirkelformet sti på himlen over arenaen. Helikopteren bevæger sig altid til det fjerneste punkt på den cirkel set fra spilleren, mens den holdes synlig og gør det lettere for os at placere dækninger på de rigtige steder."
N/A4002"#commentary\cn_087_explosive_barrel_factory.mp3" "[ David Speyrer ] Dette rum, fyldt med et absurd antal eksploderende tønder, inspirerede en godmodig debat inden for holdet om, hvor langt vi skulle skubbe det plausible i vores verden. Helt ærligt er én eksploderende tønde nok for mange med hensyn til realisme – i den virkelige verden burde tønder virkelig ikke eksplodere, selv hvis du skyder på dem."
N/A4003"#commentary\cn_088_rising_water.mp3" "[ Dhabih Eng ] Den flydende bro og træspolerne introducerer her begrebet opdrift som et værktøj for spilleren. I dette tilfælde er det ikke rigtig et puslespil, det er bare sjovt for spilleren, der interagerer med fysiksystemet, men senere vender vi tilbage til dette gameplay-element i kanalerne for at hæve en rampe til luftbåden."
N/A4004"#commentary\cn_089_manhack_matt.mp3" "[ John Morello ] Vi kaldte den her fyr 'Manhack Matt'. Vi ønskede at give spillerne fornemmelsen af, at hundredvis af borgere beboede de skjulte hjørner og kroge i City 17. På dette tidspunkt i spillet var det et stykke tid siden, spillerne havde set en borger, og vi ønskede at forklare betydningen af manhacks, der var den første fysikbaserede fjende, som vi skabte. I det oprindelige koncept var der en videoarkade i byen, hvor spillerne kunne flyve manhacks rundt for at angribe virtuelle borgere. Til sidst ville spillerne opdage, at manhacks var virkelige, og det var borgerne også. Efterhånden som Combine-besættelsen blev mere uddybet, passede denne idé om en videoarkade dårligt ind, og den blev til sidst kasseret."
N/A4005"#commentary\cn_090_fighting_motion_sickness.mp3" "[ David Speyrer ] I tidlige playtests udviklede mange spillere køresyge, mens de styrede luftbåden. Mens vi forsøgte at løse dette, opdagede vi flere faktorer, der bidrog til det. Vi fandt ud af, at reduktion af luftbådens forstyrrelse af udsynet hjalp, så vi foretog flere ændringer af modellen for at nedjustere det. Opretholdelse af en ensartet billedhastighed hjalp også, så det var vigtigt at holde øje med ydeevnen i disse sektioner. Den vigtigste enkeltfaktor var imidlertid at fjerne synsrulning for at opretholde en mere stabil horisont, uanset hvad luftbåden lavede. En af programmørerne på holdet var super tilbøjelig til køresyge, og vedkommende tilbød tappert at spilteste flere gange for at evaluere vores fremskridt mod en løsning. Jeg er ret sikker på, at vedkommende kastede op mindst en gang efter en playtest, og deres noble offer er enormt værdsat."
N/A4006"#commentary\cn_091_headcrab_canisters.mp3" "[ Jeff Lane ] Brugte hovedkrabbebeholdere ses senere i Ravenholm, så vi besluttede at vise dem her for at fortælle historien om, hvordan de bruges af Combine. Historien er, at Combine har gjort Xen-faunaen til våben for at bruge dem mod menneskene. Begravede hovedkrabber blev tilføjet som en ny funktion til dette afsnit, der blev udvidet til et større område, som er beregnet til at vise en borgerhytte, der blev decimeret af hovedkrabbeangrebet."
N/A4007"#commentary\cn_092_airboat_intro.mp3" "[ John Morello ] Det er her spilleren får det første fartøj i spillet, luftbåden. Vi ønskede at skabe et sikkert rum, hvor spillerne kunne øve sig i at styre luftbåden, så længe de ville, før de fortsatte. Arenaen er strøet med muligheder for spring og tricks, og vi fyldte arenaen med giftigt slim for at holde spillerne i luftbåden i længere tid, samtidig med at de forhindrede dem i at forlade fartøjet og fortsætte til fods."
N/A4008"#commentary\cn_093_zombie_surprise.mp3" "[ Jeff Lane ] Der er en lille bid fræk jumpscar i dette kloakrør. Spillerne vandrer herind, superfokuserede og nysgerrige, og så dukker en undervands-zombie op, der næsten altid skræmmer livet af spiltesterne. En af dem faldt endda ned fra sin stol, og vi markerede det øjeblik som en succes."
N/A4009"#commentary\cn_094_airboat_time.mp3" "[ Dave Riller ] Det krævede arbejde at finde den rigtige balance mellem tid i fartøjet og tid til fods. Kørsel i fuld fart drev spillerne hurtigt gennem verden, og i tidlige playtests følte vi, at spillerne gik glip af at udforske og indtage spillets detaljer. Udforskning og verdensundersøgelse er kerneværdier i Half-Life, så vi ønskede ikke, at køretøjet skulle eliminere det. For at løse dette tilføjede vi periodiske steder, hvor spillerne kunne komme ud og udforske små lommer med tætsamlede detaljer. Efterhånden som fysiksystemet udviklede sig, lærte vi også nye måder at bruge det på. Disse episoder væk fra luftbåden lader os introducere et element af opdagelse omkring fysik, som at smide kasser i vandet eller kombinere tønder for at hæve en rampe. Dette gav spillerne chancer for at interagere med vand og fysik på forskellige måder."
N/A4010"#commentary\cn_095_floating_supplies.mp3" "[ Josh Weier ] I alfa-playtesten blev kanalerne spækket med flydende forsyningskasser, som spillerne kunne smadre med luftbåden for at indsamle forsyningerne indeni. Mekanikken var noget gamey, men hjalp med at holde flowet i gameplayet ved at give spilleren mulighed for at forsyne sig på farten. For at gøre forudsætningen mere plausibel ønskede vi at fortælle historien om, hvordan de flydende kasser endte så bekvemt placeret langs spillerens vej. Denne scene med borgere, der dropper forsyningskasser, hjælper med at sælge den fiktion, samtidig med at kanalerne føles mere levende. Det fik også spillerne til at føle sig mere heroiske og vigtige, når de blev hjulpet af så mange bipersoner."
N/A4011"#commentary\cn_096_grenade_intro.mp3" "[ Brian Jacobson ] Vi udtænkte denne Combine-base som både et træningsområde og en legeplads til granater og introducerede dem her i uendelige forsyningskasser for at signalere, at det er sikkert for spillerne at bruge granater frit uden frygt for at løbe tør. Gå bersærk. Kamptræfningen her bruger omfattende markering til at lede AI-soldaterne mod dækning og give spillerne gode muligheder for at gøre brug af granater. I slutningen af området hjælper den samme uendelige granatteknik spillerne med at løse tårnplaceringen, da et direkte angreb er meget vanskeligere, hvis du ikke gør det. Et skarpt rødt lys og et partikelspor blev tilføjet til granaterne, hvilket gjorde det betydeligt lettere for spillerne at følge deres bane, uanset om de kaster dem eller undviger en fra en Combine-soldat."
N/A4012"#commentary\cn_097_puzzle_layers.mp3" "[ Dave Riller ] Fordi spillerne ofte er helt uvidende om designerens hensigt, hvilket vi synes er en god ting, har de en tendens til at reagere på alle mulige overraskende måder på vores gåder. Selv tilsyneladende enkle gåder kan byde på utallige fiaskoer på vejen til succes. Det var tilfældet med dette puslespil for at åbne kanalportene, hvilket krævede mange lag med tip og signaler. Gnisthjulet kommunikerer, at det er her, nogen normalt ville åbne porten, men en anden metode er nødvendig. Et par krager drager spillerens øjne mod løsningen – i dette tilfælde en stak bjælker på et pendul. Da granater er blevet grundigt introduceret, ønskede vi oprindeligt, at spillerne skulle kaste en for at bryde træstøttestrukturen, men det var ikke indlysende nok. Vi tilføjede eksploderende tønder som en meget klarere ledetråd. Men selv efter at have løst puslespillet, var nogle spillere ikke klar over, at portene nu var åbne, hvilket førte dem til uendeligt at udforske basens interiør på udkig efter en anden udgang. Så vi måtte minde dem om deres oprindelige problem, den ødelagte port. Vi tilføjede røg, alarmer og et roterende lys, og så begyndte vi endelig at se pålideligt gode resultater i playtesting."
N/A4013"#commentary\cn_098_metrocop_strafing.mp3" "[ Doug Wood ] Det oprindelige design af luftbådsniveauerne havde til formål at udfordre spillerne med stramme manøvrer under pres fra Metrocop. Metrocops skudmønster var beregnet til at få spillerne til at styre i slalom mellem skuddene, mens de susede forbi. Men i vores gennemgangsproces, internt kendt som \"Overwatch\", følte nogle playtestere sig frustrerede over at blive skudt på uden en måde at gengælde ilden. De ønskede, at luftbåden skulle føles kraftfuld og ustoppelig. Baseret på denne feedback omfokuserede vi niveauerne for at skabe empowerment frem for udfordring, og vi skiftede fra at undvige angreb til hurtige kampe, hastighed og gennembrud af barrierer."
N/A4014"#commentary\cn_100_mounted_gun.mp3" "[ Jeff Lane ] De monterede kanoner blev tilføjet her for at hjælpe med at træne spilleren i pistolens effektivitet mod angrebshelikopteren under den sidste kamp i reservoiret. Dette var nødvendigt, fordi helikopteren indtil dette tidspunkt var usårbar for spillerens våben, og vi var nødt til at give en indikation af, at den kunne blive skadet med større våben. Dette var kun delvist effektivt i playtests på grund af mængden af pres, spilleren var under i dette øjeblik. Det førte til, at vi udviklede partikeleffekter og lyde, der ville sælge ideen til spillerne om, at de faktisk gjorde skade mod den."
N/A4015"#commentary\cn_101_357_intro.mp3" "[ Josh Weier ] Magnum'en, i modsætning til basispistolen med sin langsommere skudhastighed, er beregnet til at blive affyret på en mere målrettet, kalkuleret måde og forårsage katastrofale skader på dit mål. Tidligere versioner af Magnum havde lidt tilfældig spredning, som vi følte passede til det kraftige og mindre følsomme aftrækkertræk fra en større pistol. Dette førte dog til antiklimatiske øjeblikke, hvor spillerne omhyggeligt forberedte et skud, kun for at ramme ved siden af på grund af nøjagtighedsstraffen. For at løse dette gjorde vi den første kugle perfekt nøjagtig, mens hvert efterfølgende skud blev mindre nøjagtigt, efterhånden som du affyrede våbnet."
N/A4016"#commentary\cn_102_helicopter_bombing_run.mp3" "[ Brian Jacobson ] Dette er et andet eksempel på, at vi skaber bevægelsesfarer, mens spilleren styrer luftbåden. Helikopteren forsøger at blive foran spilleren, når den smider bomber, og hvis spilleren trækker sig tilbage, skifter den til at svæve og vender sig for at angribe spilleren. I en spilletest faldt en bombe tilfældigvis mellem rørsømmene og skabte et smukt filmisk øjeblik. Playtesteren havde en positiv reaktion, så holdet besluttede at scripte det, så det skete hver gang. Denne proces er blevet en del af vores organiske designproces: Af og til sker der tilfældigt en cool ting i en playtest, og vi finder en måde at få det til at ske mere pålideligt."
N/A4017"#commentary\cn_103_smokestack_collapse.mp3" "[ Doug Wood ] Da vi lavede et filmisk actionspil som det første Half-Life, havde vi altid ønsket at lave nogle store, spektakulære ødelæggelsessekvenser, men vi var aldrig helt i stand til at gøre noget i den stil. Half-Life 2s fysik introducerede et system til at bryde fysiske små genstande, såsom kasser, i stykker, hvilket prikkede til ideen om at gøre noget meget større. Vi tog en chance og prøvede at bryde en røgstak i stykker, da den faldt. Så eksperimenterede vi med masserne, indtil det føltes bedre, raffinerede modellen og tilføjede masser af røg og lyd for at sælge effekten. Og så havde vi det. Vi havde vores store, spektakulære ødelæggelsesøjeblik. I sidste ende gjorde vores fysik sekvensen lige akurat mulig på en måde, der måske virker ejendommelig efter moderne standarder, men føltes virkelig fantastisk på det tidspunkt. Fordi simuleringen var unik, hver gang vi kørte den, var vi nødt til at tage skridt for at undgå fuldstændigt at blokere spillerens vej med de store klumper af brokker. Succesen med denne sekvens vækkede vores appetit på de meget højere troværdige filmiske og fysiske ødelæggelseseffekter, der igen ses i episode to."
N/A4018"#commentary\cn_104_washing_machine_puzzle.mp3" "[ David Speyrer ] Vi skabte det fysiske vaskemaskinepuslespil sent i udviklingen, efter at playtesting viste, at spillerne havde brug for noget nedetid på grund af det ubønhørlige pres fra helikopteren. Tempokontraster som denne kan fremhæve de intense øjeblikke ved at nulstille spillerens følelsesmæssige tilstand og afværge udmattelse eller endda kedsomhed. Det var et positivt tegn på, at spillerne reagerede så stærkt på alt det arbejde, der blev udført for at gøre helikopteren virkeligt truende, men hvis vi ikke håndterede stresset ved det, meldte en træthed sig, der hurtigt begyndte at føles som monotoni snarere end spænding. Oprindeligt kørte spillerne hurtigt gennem dette område, men på grund af det dejlige sollys og kanalens sammensætning her besluttede vi, at det var et godt sted at stoppe handlingen og få spilleren til at bruge lidt stille tid på at løse et puslespil. Selve puslespillet, som var det første til at bruge masser og bloktrisser, endte med at give anledning til andre fysiknavigationspuslespil andre steder i spillet. "
N/A4019"#commentary\cn_105_airboat_changeup.mp3" "[ Jeff Lane ] Vi hørte fra playtestere, at de ønskede mere varieret gameplay ud af luftbåden. Indtil dette tidspunkt i spillet havde spilleren ingen reel måde at kæmpe tilbage mod helikopteren og andre fjender, så det føltes rigtigt at introducere et nyt våben og til gengæld levere en tempoændring og sætte scenen for, hvad der snart ville komme. I de efterfølgende områder tilføjede vi skydeøvelser for at gøre spillerne bekendt med deres nye våben. Ekstra fysikkraft på Air Gun-projektiler betød, at mål ville blive kastet tilbage, hvilket fik våbnet til at føles langt mere kraftfuldt end noget andet i spillerens arsenal. Men selv der, når det kom til spiltest af kamp mod helikopteren, troede mange testere stadig, at den var uovervindelig. De havde ikke bemærket vores bestræbelser på at illustrere, at helikopteren tog skade fra de Combine-monterede kanoner tidligere. For at løse dette gjorde vi det mest oplagte: vi satte helikopteren direkte uden for tunnelen, hvor du får våbnet, og gør det ekstremt klart, at du kan og bør skyde den. Og det virkede."
N/A4020"#commentary\cn_106_donkey_kong_barrel_ramp.mp3" "[ Eric Smith ] Dette særlige område, dræningsrampen, startede oprindeligt som bare et interessant stykke banearkitektur. Men under playtesting så vi hurtigt, hvor sjovt det var at skubbe luftbåden op og rundt om skråningen, så vi tilføjede flere elementer for at forbedre oplevelsen. Dette omfattede Metrocop, der droppede tønder ned mod spilleren i et lille nik til det klassiske arkadespil Donkey Kong."
N/A4021"#commentary\cn_107_lambda_cache_interlude.mp3" "[ Danika Rogers ] Et Half-Life-spil er i sidste ende en lineær oplevelse, men vi leder altid efter måder at bryde spillerstien op og skabe ikke-linearitet på niveauskala. Denne lambda-cache, erstattet med et zombie- og hovedkrabbebaghold, var helt valgfri og kun bygget for at tilføje noget af den ikke-linearitet til denne del af rejsen gennem kanalerne."
N/A4022"#commentary\cn_108_skybox_time_of_day.mp3" "[ Eric Kirchmer ] Skybox- og tågefarven ændres trinvist i løbet af dette kapitel. Den er beregnet til visuelt at repræsentere tidens gang, når spilleren rejser gennem kanalerne og kapitlet. To tågefarveværdier i modsatte retninger hjælper med at sælge illusionen af solens skrå vinkel. Du kan se, at det er tæt på solnedgang på dette tidspunkt. Det kulminerer i helikopterkamparenaen med solnedgang og Ravenholm synlig i skyboxen."
N/A4023"#commentary\cn_109_helicopter_megabomb_origin.mp3" "[ Brian Jacobson ] Megabomb-helikopterangrebet var baseret på en fejl, hvor en programmør ved et uheld fjernede nedkølingen af bombenedkastningen, hvilket resulterede i, at helikopteren droppede hundredvis af bomber på én gang. Det så så sejt ud, at vi besluttede, at vi skulle beholde det til det sidste bombeangreb."
N/A4024"#commentary\cn_110_helicopter_final_battle.mp3" "[ Dave Riller ] Vi designede dette område som arena for det endelige opgør mellem spilleren og Combine-kamphelikopteren. Det er spillerens chance for endelig at eliminere den nådeløse fjende, der har jagtet dem, siden de flygtede under jorden efter at have forladt Kleiners laboratorium. Dette område gennemgik mange iterationer for at få det helt rigtigt. Der var brug for rigelig plads til hurtige fartøjskampe, et jævnt bevægelsesflow med klare stimuligheder og pålidelig ydeevne. Vi sigtede også efter visuel klarhed, der var egnet til kamp – slående, men ikke alt for støjende – samtidig med at vi sikrede, at det ville fungere som en mindeværdig udsigt, når helikopteren er ødelagt."
N/A4025"#commentary\cn_111_airboat_wreckage.mp3" "[ David Speyrer ] Oprindeligt ødelagde vi luftbåden i hoppet over dæmningen, så dette niveau åbnede med spilleren midt i vraget af deres elskede luftbåd. I en playtest med hele teamet var folk skuffede over at miste det fartøj, de havde brugt så meget tid i. Der var en masse intern debat om, hvorvidt denne følelse af tab var en værdifuld oplevelse eller ej. I sidste ende besluttede vi at lade luftbåden være intakt for at give mulighed for, at spilleren genforenes med den en dag. Nogle siger, at luftbåden stadig er derude og venter på dig."
N/A4026"#commentary\cn_112_arena_exit_gate.mp3" "[ Quintin Doroquez ] Hjulmekanismen til at hæve udgangsporten blev tilføjet specifikt for at tvinge spilleren til at besejre helikopteren, før de kan bevæge sig fremad. Vi henviser ofte til elementer som dette som at \"gate\" spilleren – at bruge designelementer til at forhindre dem i at komme videre, indtil de har afsluttet en nødvendig opgave. Her er det bogstaveligt talt en port."
N/A4027"#commentary\cn_113_blocking_tutorials.mp3" "[ Adrian Finol ] Til tider er vi nødt til at være sikre på, at spilleren har lært noget, og standardmetoden – i det mindste i spiludvikling, ikke i livet – er at fange dem bag en port af en slags, hvor spilleren skal demonstrere sin viden for at kunne fortsætte. Vi forsøger at skjule disse porte som noget naturligt, så det ikke føles som om spillet er stoppet. Selvfølgelig kan tid, ressourcer eller selve miljøkonteksten gøre det vanskeligt. I dette tilfælde var vi nødt til at lære spillerne at flytte objekter, så et simpelt stablingspuslespil virkede som den bedste løsning. Vi testede mere komplekse designs, men de endte med at være mindre effektive til at undervise i det, vi havde brug for, at spilleren skulle lære."
N/A4028"#commentary\cn_114_natural_storytelling.mp3" "[ Bill Van Buren ] For at nå vores verdensopbygnings- og historiefortællingsmål i hele togstationen havde vi brug for en naturlig måde at levere dialog på, uden at det føltes for 'gamey' eller krævede tutorials. Vi bemærkede, at spillerne ofte henvendte sig til NPC'er for at se nærmere på dem, så vi gjorde det til en mulighed for NPC'erne at anerkende spilleren og levere deres linjer. Dette holdt interaktionerne lavmælte, hvilket var vigtigt, da borgerne ikke ligefrem er for muntre eller livlige. Enkelheden i denne tilgang stemmer også overens med et af Half-Life's kernefortællingsmål: at gøre fortællingen lydhør over for spillerens interesse. Nogle spillere ønsker at grave i alle detaljer, mens andre bare vil vide, hvad de skal gøre nu. At give spillerne kontrol over, hvor meget historie de engagerer sig i – uden at det blokerer fremskridt – er et mål, vi altid forsøger at opretholde i et Half-Life-spil. Plus, jo mindre kompliceret en funktion er at implementere, jo mere af den kan vi inkludere.  "
N/A4029"#commentary\cn_115_trainstation.mp3" "[ Charlie Brown ] Begyndelsen på et Half-Life-spil har en stor opgave: Vi er nødt til at introducere spillerne til en ny verden, mens vi lærer dem, hvordan de interagerer med den. Spillerne skal hurtigt forstå, hvad der sker, hvem de vigtigste spillere er, hvilke trusler de står over for, og hvordan de passer ind i det hele. Og frem for alt skal det være sjovt og så interaktivt som muligt. Det kræver en masse iteration og spiltestning at finde dette, især af de små øjeblikke, der udgør spillets større udtryk. I dette afsnit vil vi fremhæve nogle vigtige øjeblikke, problemer med spildesign og et par playtests, hvor tingene ikke helt gik som planlagt."
N/A4030"#commentary\cn_116_physics_objects.mp3" "[ David Sawyer ] Det kan være svært at huske det nu, men tilbage da Half-Life 2 kom ud, var små genstande i spil, som disse stykker affald, normalt statiske – som i, de bevægede sig ikke rigtig, eller hvis de gjorde det, var det på en meget enkel måde. Hvis du var heldig, kan de bryde sammen i nogle sprites, hvis du rammer dem. Et af målene for denne indledende togstationssektion var at gøre det helt klart for spillerne, at denne slags ting blev korrekt, fysisk og faktisk simuleret i Half-Life 2. De kunne samles op, smides, kastes, ødelægges, flyttes af andre kræfter, alt, du kan forestille dig. Her starter vi med bare en lille ting, der viser, at skraldespanden bliver ramt af et vindstød ved togets ankomst – eller mere specifikt en usynlig kraft, der udløses, når spilleren forlader toget."
N/A4031"#commentary\cn_117_blocking_tutorials_3.mp3" "[ Eric Smith ] Den anden fiasko i dette vejledningsrum er et tilfælde af misforståelse – hvor vi ved et uheld lærer spilleren noget, vi ikke havde til hensigt. Dette kan være svært at undgå uden omfattende spiltestning, da spillet altid underviser, selv når det ikke er designet sådan. Vi dækker et mere ekstremt eksempel herpå senere på togstationen. Nogle tilfælde af fejllæring er afgørende at rette, som hvis spilleren lærer den forkerte måde at bruge et våben på eller interagere med et almindeligt element i spillet. Men denne her var mere subtil. Mens vi lærte spillerne at flytte objekter, lærte vi dem også at stable fysikobjekter for at undslippe et rum. Normalt er det fint – bortset fra at vi ikke implementerer det puslespil senere i spillet, og at lære noget irrelevant roder bare deres mentale værktøjssæt til og gør det sværere at huske nyttige ting senere. Værre var det, at stabling af genstande for at undslippe spillerummet blev et problem senere, noget vi aktivt måtte forhindre i flere områder. Med så mange fysikbaserede objekter i spillet var det ikke rigtigt en mulighed at blokere denne adfærd uden at lægge loft overalt. I sidste ende håbede vi, at spillerne ikke ville overtænke denne tidlige lektion, og da playtests viste, at spillerne sidder fast senere, sørgede vi for ikke at minde dem om det."
N/A4032"#commentary\cn_118_welcome.mp3" "[ Gabe Newell ] Jeg er Gabe Newell, og velkommen tilbage til Half-Life 2. Det er tyve år siden udgivelsen. I denne jubilæumsopdatering har vi forsøgt at besvare så mange af fællesskabets anmodninger som muligt. Og selvom dette måske ikke er den absolutte topanmodning fra fans, hører jeg ofte, hvor meget folk gerne vil have et kommentarspor, så vi er glade for endelig at få det til at ske. Ikke alene var det en udfordring at huske mange af detaljerne i Half-Life 2's udvikling, men det er ikke let at knække årtiers gamle computerkode op og spekulere på, hvad fanden vi tænkte på dengang. Sammen med udviklerkommentaren har vi ryddet op i en masse gamle bugs og forsøgt at efterlade tingene i en bedre form, end vi fandt dem i. Og i det mindste har vi denne gang den luksus at vide, hvordan tingene virkede i sidste ende. For at lytte til et kommentarpunkt skal du sætte dit sigtekorn over det svævende kommentarsymbol og trykke på din brugstast. For at stoppe et kommentarpunkt skal du sætte dit sigtekorn over det roterende punkt og trykke på brugstasten igen. Og lad mig endelig vide, hvad du synes. Du kan kontakte mig på gaben@valvesoftware.com. Tak, og god fornøjelse!"
N/A4033"#commentary\cn_119_metrocop_shoving_citizens.mp3" "[ Josh Weier ] Vi er kun gået et par meter, og vi har allerede problemer at løse. Vi introducerer Metrocop – en fjende, som vi til sidst beder spillerne om at dræbe – og giver dem et glimt af den verden, de træder ind i. Det er et simpelt, klart øjeblik, der viser forholdet mellem Metrocop og borgere og i forlængelse heraf spilleren. Samtidig besluttede vi at forstærke eksistensen af den grundlæggende fysiksimulering og vise den måde, hvorpå NPC'er tilfældigt kan interagere med objekter i verden. At se eksempelvis en kuffert banke ind i en anden og slå den løs var ret nyt dengang. Disse øjeblikke på togstationen, hvor vi kombinerede flere mål, var de mest succesrige – de føltes naturlige, som om spillet ikke stoppede bare for at lære dig noget."
N/A4034"#commentary\cn_120_fall_damage.mp3" "[ Kerry Davis ] Det er vigtigt, at spillet lærer spillerne, hvordan man gør ting. Men for at de skal træffe sikre beslutninger, er de også nødt til at forstå de mere subtile regler. Dette lille øjeblik dækker to af dem: For det første viser det, hvor langt spilleren kan falde uden at tage skade. For det andet introducerer det lidt af spillets 'ordforråd' – hvordan spillet vil kommunikere med dem. Spillere bekymrer sig ofte om at tage faldskader, men de bekymrer sig også om at tage et skridt, de ikke kan tage tilbage, så her signalerer en indbydende kasse, spilleren kan lande på, at det er sikkert at falde ned, og at det er vejen frem. Og når kassen går i stykker, forstærker den fysiksimuleringen, og det er sandsynligvis første gang, spillerne ser, at større objekter kan slås i stykker."
N/A4035"#commentary\cn_121_sweeping_vortigaunt.mp3" "[ Laura Dubuk ] Endnu et vigtigt historiefortællingsøjeblik og endnu et nik til fysiksystemet: Her viser vi, hvordan Vortigaunts passer ind i denne nye verden, hvilket er et stort skift fra deres Half-Life 1-rolle som fjender. Som så mange øjeblikke i togstationen opstod den fejende Vortigaunt fra vores konstante jagt på måder at vise karakterer, der interagerer naturligt med fysiksystemet. Hvorfor bare fortælle spillerne, at Vortigaunts er venlige nu, når du kan vise en af dem afslappet feje gulvet og skubbe til nogle simulerede objekter? Intet signalerer 'Hej, skyd mig ikke denne gang' som nogen, der er villig til at rydde op."
N/A4036"#commentary\cn_122_blocking_tutorials_2.mp3" "[ Robin Walker ] Der er to bemærkelsesværdige fiaskoer i denne vejledning. For det første kan spillerne bryde den ved at smide alle kasserne ud af vinduet, hvilket naturligvis ikke er godt. Dette efterlader dem siddende fast og ude af stand til at fortsætte, hvilket vi betragter som en spilstoppende fejl, der skal rettes. En nem løsning ville have været at justere vindues- eller kassestørrelserne, så spilleren kunne passe igennem, men ikke kasserne. Problemet var, at vi faktisk først fangede dette sent i udviklingen, og at foretage selv en simpel ændring som den kan have uforudsigelige, spilbrydende konsekvenser – og ikke mindst lige før lanceringen. Også dette spørgsmål var rent teoretisk. Vi havde faktisk aldrig set playtestere gøre det. Vores playtests af dette designrum var gået problemfrit, hvor spillerne lærte, hvad de havde brug for, og gik videre. At ændre rummets design så sent i spillet kunne have forstyrret denne succes på måder, vi ikke kunne forudse. Så vi valgte en mere konservativ løsning snarere end noget elegant. Hvis du er nysgerrig, så prøv at smide alle kasser ud af vinduet og se, hvad der sker."
N/A4037"#commentary\cn_123_playground.mp3" "[ Brian Jacobson ] Da vi diskuterede måder at fremhæve vores fysiksimulering omkring bymiljøet på, føltes en legeplads som et naturligt match. Og for spillere, der er opmærksomme på Dr. Breen, er det også en påmindelse om omkostningerne ved menneskehedens overgivelse til Combine. Vi valgte et par legepladsstrukturer med interessant fysikpotentiale og begyndte at tune dem. Selv med den avancerede fysiksimulering, vi havde på det tidspunkt, krævede opsætninger som denne altid håndindstilling, da vi havde fuldt simulerede objekter, der interagerede med ikke- eller delvist simulerede objekter, såsom spilleren eller statisk verdensgeometri. Det kan være let at antage, at en simulering kan bære meget af implementeringsbelastningen, men selv nu, tyve år senere, er det sjældent tilfældet. Da vi arbejdede på legepladsen, sent i udviklingen af spillet, kunne vi ikke få friktionen på rutsjebanen til at føles rigtig, vi besluttede at ødelægge stigen, så spilleren ikke kunne komme derop. Du kan dog stadig bare gå lige op foran. Som det ofte sker, ler spilleren ofte sidst."
N/A4038"#commentary\cn_124_pick_up_that_can.mp3" "[ Charlie Brown ] Kontekstualisering af tutorials – skabelsen af et historiescenarie, hvor de foregår – lader os gøre mere end bare at stoppe spillet for at lære spillerne noget. Vi får tilføjet fortællingsværdi til øjeblikket. Her kombineres undervisning af spilleren om, hvordan man kaster genstande, med en fortællende opsætning, der giver dem et valg i, hvordan de skal reagere. Efter at have set Metrocop tilfældigt misbruge borgere, føltes det rigtigt at sætte spilleren i en lignende position. Hvis de havde meninger om, hvordan borgerne skulle have reageret, får de nu mulighed for at udtrykke dem. Playtesting viste, at de fleste spillere enten efterkom eller nægtede anmodningen om at hente dåsen, men nogle forsøgte at undgå konfrontationen helt. Andre ville først overholde og derefter gengælde efter at have følt sig ydmyget. Ved at holde øjeblikket relativt begrænset, både hvad angår spillerens handlinger og selve rummet, kunne vi generelt reagere passende på det valg, de tog."
N/A4039"#commentary\cn_125_promises.mp3" "[ Danika Rogers ] Et af vores mål tidligt i et Half-Life-spil er at give løfter til spilleren og give dem en fornemmelse af, hvad de kan forvente senere. Fra film til tv-shows og bøger – al god underholdning gør dette på en eller anden måde, og computerspil er ikke en undtagelse. Løfterne i et Half-Life-spil kan tage forskellige former. Nogle er enkle, som at tilbyde bare et glimt af noget spændende. Andre er mere lagdelte, såsom interaktionerne med Metrocop. Ved at sætte spilleren i en magtesløs position, sætter vi scenen for det fremtidige øjeblik, hvor de endelig kan komme til at gøre gengæld."
N/A4040"#commentary\cn_126_exploration.mp3" "[ David Sawyer ] Efter at være blevet ført gennem togstationen af Metrocop ønskede vi at give spilleren en chance for at udforske. Dette torv bød på flere måder at interagere med borgere, Metrocops, scannere og byens infrastruktur. Vi tilstræbte, at disse interaktioner fortsatte med at opbygge verden uden at have brug for eksplicitte tutorials, og vi forfinede dem, indtil de fungerede naturligt uden nogen reel træning."
N/A4041"#commentary\cn_127_early_game_exploration.mp3" "[ David Speyrer ] Frem til dette torv har spillerne sandsynligvis ikke behøvet at tænke meget over deres vej, da det har været klart og ligetil. Men her ønskede vi at tilskynde til udforskning, hvilket betød, vi måtte gøre vejen frem mindre indlysende. Det kan give en følelse af at være fortabt, eller værre, forvirret, hvilket du måske kan forestille dig. Disse slags skift kan være hårde, især tidligt i spillet, mens spilleren stadig lærer spillets vejledende signaler. Her kompliceres det yderligere af checkpoints med kraftfelter, som giver NPC-borgere mulighed for at passere forbi, men begrænser spilleren. Det får mange playtestere til at tro, at der var en måde at omgå dem på. I sidste ende var det omfattende test, der hjalp os med at finde den rigtige synlighed for gyden videre ved hjælp af belysning, layout og en trækasse – et objekt, som spillerne allerede har brugt som et tegn på, at de er på vej i den rigtige retning – alt sammen for at lede dem subtilt fremad."
N/A4042"#commentary\cn_128_strider.mp3" "[ Doug Wood ] Dette enkle øjeblik er et løfte om, at du vil støde på denne enorme ting senere i spillet. Selv en ukompliceret scene som denne kræver virkelig en masse playtesting og iteration på grund af Half-Life's mål om ikke at tage kontrollen væk fra spilleren. Som du kan forestille dig, kræver det en masse små tweaks for at sikre, at så mange spillere som muligt kigger på det rigtige sted på det rigtige tidspunkt her. Gadelayoutet og Metrocop-scenen er alle indstillet til at lede spillerens blik, så Strideren indrammes perfekt, når den dukker op."
N/A4043"#commentary\cn_129_physics_simulation.mp3" "[ Jay Stelly ] Selvom vi begyndte Half-Life 2 med en funktionel tredjeparts fysiksimulering, tog det os stadig år med ekstra arbejde både på selve simuleringen og dens integration i spillet, før vi følte, at vi kunne opfylde vores designeres ambitioner. At opretholde et niveau af kvalitet og ydeevne, der kunne sendes ud til spillerne, var noget, vi vidste ville være en udfordring undervejs, men det mere subtile problem var faktisk at finde ud af, hvad man skulle simulere – og i hvilket omfang. Vi kan ikke simulere alt, og selvom vi kunne, er der spildesigngrunde til, at oplevelsen er bedre, når vi ikke gør det. I mange tilfælde bøjer vi bevidst simuleringen for at forbedre spillerens oplevelse. Disse justeringer går normalt ubemærket hen, fordi de stemmer overens med spillerens intentioner. For eksempel deaktiverer vi kollisioner mellem spilleren og store objekter for at lade dem dreje i smalle rum. Eller vi justerer Combine-riflens alternative skydeindstilling for forsigtigt at lede Combine-kuglen mod fjender, hvilket gør den mere effektiv."
N/A4044"#commentary\cn_130_physics_simulation_2.mp3" "[ Jeff Lane ] Områder, hvor spildesign eller andre begrænsninger påvirkede den fysiske simulering, krævede ofte ekstra tuning for at forhindre simuleringen i at sprænge i luften. Eksempelvis eksperimenterede vi tidligt med at øge simuleringen på spillerfiguren, hvilket vil sige gøre spillerens bevægelse meget mere til en del af den fysiske simulering af verden. Vi vidste, at dette kunne få bevægelsen til at føles mindre præcis, men håbede, at det kunne føre til nogle nye oplevelser. Efter at have indstillet bevægelsen til at matche den mindre simulerede version ramte vi imidlertid et stort problem: den fysiske kraft, der var nødvendig for, at spilleren kunne bevæge sig med sin sædvanlige hastighed, var så høj, at blot at løbe ind i andre simulerede objekter kunne resultere i død fra sammenstødet. Vi gentog simuleringen, men kunne i sidste ende ikke finde en løsning, vi kunne lide, så vi vendte tilbage til den mindre simulerede bevægelse. Men dette var ikke ligefrem den lettere vej – det introducerede nye udfordringer med, hvordan den mindre simulerede spiller interagerede med de mere simulerede objekter i spillet. Men det gjorde det muligt for os at levere den præcise bevægelsesoplevelse, vi ønskede."
N/A4045"#commentary\cn_131_playtesting.mp3" "[ John Morello ] Playtesting er en central del af, hvordan vi laver spil – vi kan aldrig fuldt ud forudsige, hvordan spillerne vil reagere, eller hvad de vil tage med af det, vi har bygget. Så vi tester for at lære og forhåbentlig forbedre spillet. Under en playtest guider eller taler vi ikke med spilleren, selvom de sidder fast – da det er ekstremt usandsynligt, at vi sidder der ved siden af spilleren, når spillet er udgivet. Vores mål er, at testerne helt glemmer, at de spiltester og spiller, som om de sidder hjemme. Eventuelle afbrydelser risikerer at fordreje dataene, så vi træder kun ind, hvis der er en fejl, der blokerer fremskridt eller mere sjældent, hvis deres adfærd er så forvirrende, at vi er nødt til at forstå, hvad de tænker."
N/A4046"#commentary\cn_132_playtesting_anecdote_1.mp3" "[ Matt Boone ] En mindeværdig playtest mindede os om, at vi aldrig kan være sikre på, hvad spillerne tænker, eller hvilken læring de tager med fra deres oplevelse. Efter at have spillet fra starten og siddet fast i et forsøg på at åbne en dør, brugte denne tester flere minutter på at gå frem og tilbage mellem spillet og tastaturindstillingerne. Da vi spurgte, hvad de ledte efter, sagde de, at de ledte efter inventarkontrollerne og troede, at de kunne bruge en genstand, de havde samlet op tidligere, til at låse døren op. Selvom vi havde set dem samle flere fysiske objekter op og droppe dem igen, havde de misforstået, hvad der skete. Testeren mente, at du flyttede objektet ind i dit inventar, når du trykkede på brugtasten, mens du holdt det i hånden, fordi genstanden faldt lige ned. Vi vidste, at det bare var tyngdekraften, men deres antagelse var ikke skør, da nogle eventyrspil fra den æra skubbede genstande ind i en usynlig beholdning på den måde. Vi forklarede, at der ikke var noget inventar, og testen fortsatte. Senere overvejede vi, om vi havde brug for at løse dette, men da ingen andre playtestere havde den samme forvirring, og alle vores potentielle løsninger var mere hårdhændede end nødvendigt, besluttede vi, at det var en afvigelse, der ikke behøvede at blive adresseret. Det fungerede dog som en god påmindelse om, hvordan selv de mest subtile, oversete detaljer kan vildlede en spiller."
N/A4047"#commentary\cn_133_cratebaby.mp3" "[ Scott Dalton ] Denne lille babydukke har en omfattende fortid. I løbet af de lange måneder med intern test gjorde nogle af holdet testen til en udfordring – en måde at gøre det 47. gennemspil af spillet lidt sjovere. De placerede dukken i en nærliggende blå kasse for at se, hvor langt de kunne bære den gennem hele spillet. Efter lanceringen af Half-Life 2 begyndte fællesskabet også at bære kassebabyen og tilføjede deres egne historier og regler til situationen. Et par år senere, mens vi arbejdede på afsnit 2, var dette inspirationen til 'Little Rocket Man'-præstationen, hvor spillerne skulle bære rundt på en havenisse kaldet 'Gnome Chompski' gennem hele episoden. Chompski gjorde endda et comeback i Left 4 Dead 2 i 'Guardin' Gnome-præstationen, hvor spillerne måtte bære ham gennem Dark Carnival-kampagnen. Denne form for interaktion med spillere er nogle af de mest givende dele af spiludvikling. Vi designer spil med teorier i tankerne, men du ved aldrig rigtig, hvor tingene ender, før spillerne får fat i det."
N/A4048"#commentary\cn_134_the_citadel.mp3" "[ Eric Kirchmer] Vi ønskede, at spillerens første glimt af City 17 skulle fremhæve citadellet og dets dominans over byen, hvilket repræsenterede Combines komplette og totale magt over menneskeheden. Det skulle også tjene som et klart mål – selv i starten kan du se, hvor din rejse slutter. Men på trods af sin enorme størrelse overså playtestere det ofte. En spillers følelse af dybde og skala kan være vanskelig på en computerskærm. Hvis du har spillet spil i VR, har du sandsynligvis bemærket, at skalaen føles mere naturlig. Under alle omstændigheder hjalp citadellets position over spilleren heller ikke på tingene, hvilket kan skyldes, at FPS-spil træner spillerne til at fokusere lige frem eller ned for deres fødder. For at forbedre chancerne for, at spillerne bemærkede citadellet, tilføjede vi fugle, der flyver mod strukturen. Det er et subtilt trick, som vi har fundet hjælper med at styre spillerens syn."
N/A4049"#commentary\cn_135_close_captions.mp3" "[ Yahn Bernier ] Under udviklingen af Half-Life 2 blev vi kontaktet af folk interesseret i tilgængelighed, som opfordrede os til at gå ud over det undertekstsystem, vi havde bygget til Half-Life 1. De anmodede om et fuldt udstyret undertekstsystem til at fange alle spillyde, ikke kun dialog. Dette viste sig at være en meget hårdere udfordring end forventet. Half-Life 2 producerede en lang række lyde, og kategorisering af dem til billedtekster var afgørende. Prioritering var også nøglen: dialogen skulle skille sig ud, og det skulle være klart, hvem der talte. Omgivelseslyde, som fjern kamp, var vigtige for at sætte stemningen på nogle niveauer – men mindre, hvis der var en fjende, der skød i nærheden. Vores niveaudesignere genbrugte også ofte lyde i forskellige sammenhænge, så en lyd kan kræve billedtekster i et område, men ikke i et andet. I sidste ende endte hver lyd i spillet med sine egne billedtekstdata, formateret næsten som en lille version af HTML, hvilket gav os kontrol over den visuelle stil for hver billedtekst. Som med lydfilerne var billedtekstdataene for store til at opbevares i hukommelsen, så vi byggede et asynkront cache-system til at håndtere det effektivt."
N/A4050"#commentary\cn_136_the_raid.mp3" "[ David Sawyer ] Sektionen forude, hvor Metrocops angriber lejligheden, mens spilleren er derinde, krævede en masse iterationer at få helt rigtig. Generelt designer vi Half-Life, så spillerne kan sætte deres eget tempo, da folk bevæger sig gennem spillet på mange forskellige måder. Nogle spillere løber og ignorerer alt, der ikke virker som en trussel, mens andre metodisk prikker til alt. Så når vi har brug for at fremtvinge et bestemt tempo, er det altid en udfordring at sikre, at spillerne opfatter det tempo og naturligt spiller med. Da dette er første gang, vi gør det, var vi nødt til at lægge meget arbejde i at gøre det klart for spilleren, at de havde brug for at bevæge sig hurtigt, og der ikke er tid til udforskning her."
N/A4051"#commentary\cn_137_materials_and_shaders.mp3" "[ Gary McTaggart ] Half-Life 2 kom ud midt i et betydeligt skift i 3D-grafik, hvor branchen flyttede fra teksturer til materialer og shaders. I Half-Life 1 havde hver overflade en struktur – i det væsentlige et billede pakket ind på overfladens polygoner. Men i Half-Life 2, kun fem år senere, havde hver overflade både et materiale og en shader. Shaderen var en blok kode, der tilpassede, hvordan overfladen blev gengivet. Materialet definerede egenskaber for, hvordan overfladen opførte sig fysisk, og hvordan den reagerede på gameplay-funktioner. Det indeholdt også referencer til teksturer og andre parametre, som skyggen skulle bruge til gengivelse. Som et resultat heraf havde kunstnere og designere meget mere kontrol over, hvordan tingene så ud og opførte sig. Dette kom dog med en afvejning: Half-Life 1 kunne køre på en computer med kun en CPU, men Half-Life 2 krævede en GPU, fordi de beregninger, der var nødvendige for materialer og shaders, var specielt designet til GPU-hardware. Den lysbrydende glasdør her er et tydeligt eksempel på en brugerdefineret shader, men hver overflade i scenen kører faktisk en shader af en eller anden slags."
N/A4052"#commentary\cn_138_the_raid_2.mp3" "[ Miles Estes ] Ud over at sikre, at spilleren følte sig presset til at komme videre, måtte vi sikre, at selve raidet var idiotsikkert. Der kunne ikke være nogen måde for spilleren at undgå det eller gå bagom forbi Metrocop. Den virkelige udfordring var ikke, at spillerne ville forsøge at knække scenen, men at mange ville gå i panik og løbe i tilfældige retninger, når de indså, at de var truet for første gang. Dette øjeblik kræver en delikat balance: Vi ønskede en hjertebankende flugt, følelsen af reel fare, men vi ønskede også, at spillerne skulle klare det i deres første forsøg og føle, at de slap væk med nød og næppe. For at opnå dette holdt vi stien fremad klar og og lod den minde om den, de lige havde taget gennem forrige etage. En række omhyggeligt placerede triggere kontrollerer truslerne, der vises foran og bagved spilleren, og opretholder presset, mens det stadig giver spilleren tid nok til at være foran sine forfølgere."
N/A4053"#commentary\cn_139_health_and_no_hud.mp3" "[ Dave Riller ] Jagtsekvensen på taget udgjorde en unik designudfordring. Vi ønskede ikke, at det skulle være en ægte gameplay-hindring, og vores bedste case var, at spillerne skulle klare det i deres første forsøg. Men vi ønskede stadig at skabe følelsen af reel fare, hvor spillerne følte sig legitimt truet, hvis de ikke blev ved med at bevæge sig. Udfordringen var, at uden HEV-dragten har spillerne teknisk set ikke en heads-up-skærm eller HUD – hvilket betyder, at vi ikke har nogen måde at vise skade eller resterende helbred på. Efter nogle eksperimenter oprettede vi et specielt helbredsssystem til dette afsnit ved hjælp af en rød glød rundt om skærmen for at indikere skader. Spillerne reagerede, som vi håbede, tog det som et tegn til at fortsætte med at bevæge sig, og jagten udfoldede sig som forventet. For at afrunde det fik vi helbredet til at regenerere hurtigt, så gløden blev ved, hvilket forstærkede over for spillerne, at løb faktisk var det rigtige valg, som sikrede, at spillerne ikke blev taget ned af en omstrejfende kugle i slutningen, bare fordi de smølede eller tøvede tidligere."
N/A4054"#commentary\cn_140_playtesting_anecdote_2.mp3" "[ Jakob Jungels ] I den kommende sektion havde vi brug for, at spilleren blev slået ned, så Alyx kunne redde dem. Med begrænset tid og ressourcer forenklede vi mødet så meget som muligt ved at genbruge eksisterende systemer og lade det spille som en normal kampsekvens, med en brugerdefineret begivenhed, der udløses, når spilleren 'døde'. Efter et par playtests for at finjustere timingen gik vi videre. Men da vi kom tæt på udgivelsesdatoen, stødte vi på et problem med en playtester, der konstant brugte quicksave og straks ramte quickload, når de troede, at de havde fejlet. Da en metrocop ramte dem, skyndte de sig at quickloade, før Alyx kunne komme på banen, og de gentog dette mere end ti gange, før vi bad dem om at stoppe. På dette udviklingsstadium, i den sidste fejlrettelsesfase, måtte vi begrænse os til kun at løse spilbrydende problemer – da selv små ændringer kunne risikere at bryde noget vigtigere. Da vi vidste, at dette var en sjælden hændelse, eftersom de fleste playtestere ikke havde nogen problemer, foretog vi et par konservative ændringer. Vi forkortede forsinkelsen mellem knockdown og Alyxs første linje og ændrede fade-out-farven til hvid i stedet for sort, hvilket i sidste ende ikke var så nyttigt, da spillerne endnu ikke var døde nok til at forbinde sort med døden. Vi overvejede at deaktivere quickload i de få sekunder, scenen spiller ud, men vi var bekymrede for, at det kunne introducere en fejl, hvor quickload blev deaktiveret permanent"
N/A4055"#commentary\cn_141_character_reactions.mp3" "[ Ariel Diaz ] Det var en løbende udfordring at finde ud af, hvad karakterer skulle reagere på – og hvordan. Dybest set ønsker vi altid, at spillet skal reagere på spillerens input. Imidlertid kan ethvert svar fra spillet ses som en belønning af spilleren. Så hvad karakterer reagerer på, og hvad de ignorerer, lærer spilleren noget om den slags input, spillet forventer. Som et resultat heraf sørgede vi for, at spillet reagerede på ting, vi ønskede mere af, såsom spillere, der pillede ved enheder i laboratoriet, og ignorerede adfærd, vi ønskede mindre af, såsom at spillere gentagne gange slog Kleiner i ansigtet med en kasse. Helt seriøst, vi så en playtester gøre det i fem minutter i træk."
N/A4056"#commentary\cn_142_choreography.mp3" "[ Bill Fletcher ] Systemet, vi byggede og itererede på for at levere Half-Life 2's historiefortælling, blev internt kaldt Choreo, forkortelse for koreografi. Tidligt fandt vi det nyttigt at forestille os, at vi skrev et skuespil, hvor en af skuespillerne ikke kendte manuskriptet. Vi havde brug for et system, der kunne kontrollere alle de andre skuespillere, flytte dem rundt på scenen, levere deres optrædener og deres replikker. For at håndtere dette skulle de andre skuespillere problemfrit blande vores instruktørkommandoer med dynamiske reaktioner på spillerens position og adfærd. Timing ville helt klart blive en stor udfordring, da enhver del af scenen muligvis skulle forlænges, sammentrækkes eller endda sættes på pause, afhængigt af hvad spilleren lavede."
N/A4057"#commentary\cn_143_phoneme_extraction.mp3" "[ Bill Fletcher ] Et andet kritisk værktøj, vi indbyggede i FacePoser, var Phoneme Editoren. Det behandlede stemmeskuespillernes dialoglinjer og ekstraherede fonemer for at generere grundlæggende læbesynkroniseringsanimationer til vores karakterer. For heltefigurerne brugte vores animatorer dette som udgangspunkt til at skabe brugerdefinerede animationer af høj kvalitet til hver dialoglinje, der inkorporerede fuld ansigtsanimation. I en dynamisk Choreo-scene kunne animatorerne imidlertid ikke vide nøjagtigt, hvad resten af skuespillerens krop gjorde. Dette betød, at det krævede omhyggelig lagdeling af Choreo-kommandoer og timinger i FacePoser, samtidig med at skuespillerens evne til dynamisk at reagere på spilleren opretholdtes."
N/A4058"#commentary\cn_144_delivery.mp3" "[ Ken Birdwell ] Det krævede en masse iteration og playtesting at finde den rette balance mellem information og følelsesmæssig forbindelse i vores store Choreo-scener. Hver scene havde en masse information, vi havde brug for at formidle til spilleren, men vi kunne ikke bare have karakterer, der udgydede eksposition – spillerne ville begynde at tænke på dem mere som skilte end som mennesker. Vi var nødt til at tage os tid til at lade karaktererne interagere med hinanden, så spilleren kunne observere deres forhold. Samtidig var vi nødt til at udvide verden og give spilleren en fornemmelse af alt, hvad der var sket, mens de var væk. Alt dette skulle gøres omhyggeligt, uden at tage for lang tid – vi ønskede, at spillet skulle fungere for spillere, der var mindre investeret i fortællingen. Animation blev et kraftfuldt værktøj til at kommunikere de følelsesmæssige forbindelser mellem karakterer, og den formidler ofte dybden af et øjeblik hurtigt uden at overdrive det. Humor var et andet almindeligt anvendt værktøj, der hjalp med at punktere en opsætning og afvæbne spilleren, når tingene blev lidt for tunge."
N/A4059"#commentary\cn_145_alyxs_kiss.mp3" "[ Ken Birdwell ] Det er et kort øjeblik, men Alyxs kys på Elis kind var vigtigt. Til sidst beder vi spilleren om at redde Eli, og vi vil have spilleren til at bekymre sig om ham. For at opbygge den følelsesmæssige forbindelse var vi nødt til at vise varmen og hengivenheden mellem Alyx og Eli. Vi ønskede ikke at oversælge det med dialog eller gøre det for stort til en begivenhed – det skulle føles ægte, ikke performativt – og vi var i stand til at iterere finesserne i denne scene, indtil den ramte den helt rigtige tone."
N/A4060"#commentary\cn_146_storytelling.mp3" "[ Bill Van Buren ] Et kerneprincip i vores tilgang til Half-Life 1's historiefortælling var at skabe en følelse af fordybelse, og det førte os til de selvpålagte begrænsninger om aldrig – eller i det mindste meget sjældent –at tage kontrollen væk fra spilleren og gøre spillerens avatar tavs. Disse begrænsninger gjorde til tider historiefortælling mere udfordrende, men vi følte, at det var vigtigt at holde fast i dem i Half-Life 2. Vores håb var, at vi ved at opretholde disse principper ville presse os selv til at udforske dybere, mere interaktiv historiefortælling."
N/A4061"#commentary\cn_147_archetypes.mp3" "[ Bill Van Buren ] Vi ønskede at skabe fortællende forbindelser mellem Half-Life 1 og Half-Life 2 gennem vores karakterer. Vores idé var at designe personer, der følte sig som repræsentationer af Half-Life 1's arketyper, så spillerne måske fandt dem bekendte – næsten som om de havde mødt dem i Half-Life 1 på et tidspunkt, men de ikke helt kunne huske det. Vi baserede Dr. Kleiner på den videnskabsmodel, vi følte var den mest ikoniske, og hans personlighed blev stort set formet af Hal Robins, hvis stemme og opførsel havde defineret Half-Life 1-forskerne. En dag, da vi var ved at prøve at finde ud af denne karakter, kom Dr. Kleiners ansigt i fokus, da vi tilfældigvis delte elevator med en revisor fra et kontor på en anden etage i vores bygning; og da vi kiggede på ham, stod det klart, at 'Dette er Dr. Kleiners ansigt'. Heldigvis var han modtagelig, da vi spurgte, om vi måtte fotografere ham til en computerspilskarakter."
N/A4062"#commentary\cn_148_tone.mp3" "[ Bill Van Buren ] Det var kritisk at sætte den rigtige tone for vores karakterer og deres dialog. Vi sigtede efter en respektfuld, næsten behagelig interaktionsstil med spilleren, mens vi undgik alt, hvad der føltes for underdanigt. Denne balance var især vanskelig med Alyx, der havde brug for at støtte spilleren uden at gå på kompromis med hendes karakters styrke – noget vi følte var afgørende for, at spillerne respekterede hende. Hendes forhold til Eli var en primær drivkraft for spillerens motivationer, så det var vigtigt, at spilleren kunne lide hende og ville hjælpe hende. Vi ønskede også at kontrastere varmen og kammeratskabet mellem spillerens allierede mod fjendtlighederne fra Breen og Combine, hvilket inspirerede en følelse af retfærdig forargelse hos spilleren for de kommende kampe."
N/A4063"#commentary\cn_149_voice-actors.mp3" "[ Bill Van Buren ] For at skabe mere responsive og flerdimensionelle figurer i Half-Life 2 var vi nødt til at udvikle vores tilgang til at arbejde med stemmeskuespillere. Selvom det var tilstrækkeligt at køre igennem et manuskript med en smule instruktion for store dele af NPC-dialogen til Half-Life 1, besluttede vi for Half-Life 2 at give skuespillerne mere mulighed for at være med til at definere karaktererne og bringe dem til live. Vi gav skuespillerne meget mere historiekontekst og viste dem spilverdenen, de miljøer, deres karakterer beboede, og de andre karakterer, de interagerede med. Vi søgte skuespillere, der kunne tage al den information og syntetisere den i deres leveringer for at hæve deres karakterer ud over, hvad vi havde forestillet os. Vi afholdt flere sessioner med hovedrolleskuespillerne, så de kunne fordøje og bygge videre på deres karakterer over tid. For scener, hvor karakterer interagerer med hinanden, ville vi ofte give stikord til en skuespiller med optræden fra andre skuespillere i scenen for at skabe en bedre følelse af forbindelse og flow. Selvom vi kom til studiet med et manuskript og en plan for optagelsessessionen, sørgede vi for, at skuespillerne følte sig bemyndigede og havde plads til at bringe deres egne ideer til karakteren og forestillingerne. Det viste sig også kritisk at have animatorer med i voice-over-sessionerne, da de var ansvarlige for at sy karakterens dialog sammen med fysiske handlinger og udtryk for at danne den resulterende Choreo-scene. Ofte opdagede animatorerne, at deres planer for, hvordan en scene ville udspille sig, udviklede sig en hel del efter arbejdet med stemmeskuespilleren."
N/A4064"#commentary\cn_150_citizens.mp3" "[ Bill Van Buren ] Da det var tid til at designe de menneskelige borgere i City 17 og verdenen uden for byen, valgte vi at inkludere en vifte af racer, aldre og køn. Dette gav ikke kun narrativ kontekst for Combine's slaveri af hele menneskeheden, men det var også vigtigt for os, at enhver, der spillede spillet, kunne se sig selv repræsenteret i modstanden, med alle på Jorden forenet mod Combine. Mens vi fandt en række kandidater til at bruge som reference til at skabe borgerne gennem vores daglige liv og forbindelser, tyede vi i sidste ende til reklamer i Seattle Times rubrikannoncer for at nå det ønskede udvalg af ansigter, som vi havde forestillet os."
N/A4065"#commentary\cn_151_alyx.mp3" "[ Dhabih Eng ] Det var en stor udfordring at få Alyxs design til at sidde lige i skabet – vi ønskede, at spilleren både skulle respektere og passe på hende. Det var et centralt spillermål midtvejs gennem spillet at redde Eli, og vi vidste, at det ville være lettere at få spillerne til at bekymre sig om det mål, hvis de også bekymrede sig om Alyx og hendes forhold til sin far. Vi designede med vilje, skrev dialog til og castede en stemmeskuespiller for Alyx, så hun var kyndig, dygtig og til at forholde sig til i den Combine-kontrollerede verden, samtidig med at vi også gjorde hende attraktiv og karismatisk. Vi havde som mål at undgå den objektivering, overdrivelse og hyperseksualitet, som mange spil i 2000'erne indeholdt, da vi følte, at det ville underminere vores mål for hendes karakter."
N/A4066"#commentary\cn_152_lab_interactivity.mp3" "[ Dhabih Eng ] I vores Choreo-scener har vi fanget spilleren lidt, så vi kan fokusere på karaktererne og fortællingen. For at imødekomme forskellige spillere – nogle dybt investerede i historien, andre ude af stand til at stå stille i mere end ét sekund – følte vi, at vi havde brug for en konstant strøm af interessante detaljer på skærmen. Vi spredte fortællingselementer i hele miljøet og sikrede, at nogle var interaktive, i princippet legetøj, som spilleren kunne pille ved. I nogle tilfælde integrerede vi yderligere historiefortælling i disse, som kaktus-mini-teleporteren, der antydede den kommende teleportfejl. Det var en delikat balance – for mange visuelt interessante ting kunne distrahere spilleren fra scenens kerne. I sidste ende tog vi den sikre løsning med Kleiner's Lab i forhold til interaktivitet, da det var den første store Choreo-scene. Senere, i Eli's Lab, udforskede vi det mere og sikrede, at karaktererne selv var opmærksomme på, hvad spilleren pillede ved."
N/A4067"#commentary\cn_153_gestures.mp3" "[ Doug Wood ] Hver af vores figurer havde et bibliotek med enkle animationer kaldet Gestures, som vi let kunne lægge oven på andre kropsbevægelser. Selvom det oprindeligt var planlagt som en produktionsbesparelse for at give os mulighed for at genbruge animationer gennem hele spillet, fandt vi ud af, at de faktisk havde mere nytte end det. Mennesker gentager ofte visse bevægelser, og disse kan være markører for deres specifikke personlighed. Som resultat endte vores Gestures-bibliotek med at fange essensen af hver karakter og hjælpe med at forene vores animationsteams forståelse af, hvem disse figurer var. Dette gjorde det meget lettere for vores animatorer at dele arbejdet med en karakter indbyrdes, hvilket produktionen ofte krævede."
N/A4068"#commentary\cn_154_interactive_storytelling.mp3" "[ Erik Johnson ] Da vi startede med Half-Life 2, var historiefortælling i spil generelt enten høj gengivelseskvalitet og lineært eller lav gengivelseskvalitet og interaktivt. Vi vidste, at spillerne havde set historiefortælling af høj kvalitet i spil, men de var aldrig blevet placeret lige midt i det – i stand til at se det udfolde sig omkring dem, interagere med den og undersøge enhver del nøje. Selvom dette mål begejstrede os, vidste vi endnu ikke, hvordan det ville fungere, eller hvilken slags teknologi vi havde brug for for at få det til at ske. Vi havde bygget en række forskellige historiefortællingsteknologier i Half-Life 1, men de blev for det meste præsenteret foran spilleren og manglede den interaktivitet og troskab, vi sigtede efter. Så Kleiners Lab blev den del af spillet, vi brugte som en testbænk til at finde ud af, hvordan vores interaktive historiefortælling faktisk ville fungere."
N/A4069"#commentary\cn_155_monitors.mp3" "[ Ido Magal ] Vi bruger skærme meget til historiefortælling i Half-Life 2 og i episoderne. Så meget at vi endda gør grin med os selv for det. Problemet er bare, at de er så forbandet nyttige. De er fantastiske til at udvide verden med ved at vise begivenheder, der sker andre steder, og de giver en nem måde at få karakterer til at tale uden at skulle forklare, hvordan de alle kommer til spillerens placering. Enhver, der nogensinde har skrevet nogen form for historie, især en med en ensemblebesætning, forstår den unikke frustration ved at forsøge at skabe naturlige grunde til, at alle dine karakterer er sammen på samme sted. I dette tilfælde var vi virkelig tilfredse med, hvordan skærmen tillod Alyx at teleportere væk og derefter hurtigt dukke op i Eli's Lab, hvilket fik alt til at føles ægte og forbundet."
N/A4070"#commentary\cn_156_scene_interactivity.mp3" "[ Jeff Lane ] På visse tidspunkter i vores Choreo-scener kræver vi, at spilleren handler. Ud over blot at give dem noget at gøre og holde dem engagerede, tjente disse øjeblikke et par nøgleformål. Først lod de spilleren indhente, hvis de var blevet distraheret af noget andet i miljøet. Scenen kunne sikkert 'pauses', indtil spilleren afsluttede opgaven, hvilket sikrede, at de var tilbage og var opmærksomme. Samtidig lod det os placere spilleren, hvor vi havde brug for vedkommende, hvilket var nyttigt til at indramme scenen og sikre, at de så noget vigtigt. I nogle tilfælde fik vi dobbelt værdi ud af disse øjeblikke ved at bruge dem til at træne spilleren – her lærer de at interagere med stik og stikkontakter, en færdighed, de skal bruge til gåder senere i spillet."
N/A4071"#commentary\cn_157_kleiners_lab.mp3" "[ Marc Laidlaw ] Kleiners Lab var det første stykke historiefortælling, vi arbejdede på, og det var det, der tog længst tid at finde ud af. Ud over sin rolle med at kaste spilleren ud i spillet, blev det til sidst den samlende vision for udviklingsteamet med hensyn til historiefortælling. Da vi begyndte at opbygge vores karakterer og historielevering omkring spilleren, opstod der mange spørgsmål, som alle føltes som store risici for spillet. Ville spilleren være i stand til at udtrække de vigtige oplysninger fra scenen? Kan vi få vedkommende til at bekymre sig om disse karakterer? Hvordan ville vi støtte spillere med forskellige investeringsniveauer i historien? Hvor dyrt ville det være at producere en scene som denne? Og hvor mange flere har vi brug for? Vi kunne ikke besvare dette, og mange flere, spørgsmål, før vi havde bygget nok af scenen og testet den med en masse playtestere. Frustrerende nok, og i modsætning til mange andre problemer vi står over for, var dette ikke spørgsmål, vi med sikkerhed kunne besvare, før vi havde gjort et betydeligt arbejde. Vi kan ofte teste gameplay-ideer med prototyper med lav fidelitet, men hvis en spiller ikke investerer i vores historiefortælling, når karaktererne bare er grå blokke, hvor sikre kan vi så være på, at de vil bekymre sig, når karaktererne er fuldt realiseret?"
N/A4072"#commentary\cn_158_characters.mp3" "[ Marc Laidlaw ] I Half-Life 1 kunne sikkerhedsvagter og forskere bedst beskrives som arketyper, ikke individer. De var abstraktioner af karakterer, der matchede den visuelle troskab, vi kunne opnå på det tidspunkt. Men efterhånden som vores teknologi blev forbedret med Half-Life 2, så vi en mulighed for at bevæge os ud over abstraktioner. Den øgede visuelle troværdighed af karaktermodellerne kombineret med forbedringer i animation fik os til at tro, at vi kunne fokusere på at skabe individuelle karakterer – mennesker, du faktisk ville være interesseret i. Vi tillod os selv at skrive ægte dialog og få karakterer til at levere den på en måde, der føltes realistisk nok til, at spillerne ikke tænkte på dem som brikker i et computerspil, og forhåbentlig drive vores fortælling fremad. I 2001, et par år inde i udviklingen, fik vi energi af Japan Studios Ico. Spillet, der er instrueret af en animator, blæste os væk med sin afhængighed af karakterer som nøgleforbindelsen til spilleren, hvilket gav os modet til at gå videre."
N/A4073"#commentary\cn_159_writing.mp3" "[ Marc Laidlaw ] I Half-Life 1-æraen handlede spillermål i FPS-spil stadig stort set om at kæmpe og besejre en åbenlyst ond fjende. Det var svært at få spillerne til at bekymre sig om karakterer, da de havde så lav troværdighed som var tilfældet i Half-Life 1. Med de planlagte forbedringer i karaktertroskab i Half-Life 2 ønskede vi at forsøge at gøre karaktererne til drivkraften i fortællingen. Vores mål var, at spillerens motiver skulle stemme overens med vores karakterers – at spilleren skulle bekymre sig om disse mennesker, deres håb og frygt, og ønske, at det skulle lykkedes for dem. Med dette i tankerne var vi i stand til at samle vores tilgang til karakter og dialog. Vi ville skabe et sæt karakterer, der kunne lide og bryder sig om hinanden, i håb om, at spilleren ville føle det samme. Disse figurer ville interagere på en måde, der føltes inkluderende, som en gruppe gamle venner, der ser spilleren som en af dem, bare en, der har været væk i et stykke tid. Hvis karaktererne demonstrerede realistiske følelsesmæssige forbindelser med hinanden, mente vi, at vi også kunne opbygge en følelsesmæssig forbindelse med spilleren."
N/A4074"#commentary\cn_160_animation.mp3" "[ Miles Estes ] Det krævede en masse teknologisk iteration at konstruere troværdig menneskelig bevægelse for vores karakterer ud af mange diskrete lag af animation. Selv enkle handlinger som at vende sig for at se på noget eller gå til et sted blev mere komplekse, da de blev kombineret med behovet for dynamisk at reagere på spilleren og kravene i Choreo-kommandoerne. For eksempel skulle det at vende sig for at se på noget være fuldstændigt brudt op, så en karakter kunne bruge enhver kombination af øjne, hoved, skuldre, overkrop eller hele kroppen til at vende sig mod et mål. I Half-Life 1 fik menneskelige karakterer deres kroppe adskilt i øvre og nedre halvdele, så de kunne gå i en retning, mens de vendte mod en anden. Denne tilgang var dog for abstrakt for Half-Life 2s karakterer. I stedet skabte vores animatorer ganganimationer i alle otte retninger af kompasset, som derefter kunne blandes jævnt sammen under runtime."
N/A4075"#commentary\cn_161_faceposer.mp3" "[ Yahn Bernier ] Det primære værktøj, vi byggede til at drive Choreo-systemet, blev kaldt FacePoser, et upræcist navngivet program, der gjorde det muligt for vores animatorer at lægge hele strukturen i vores scener ud langs en tidslinje. Tidslinjen indeholdt en række Choreo-kommandoer til skuespillerne, sammen med alle de nødvendige oplysninger for at få dem til at udføre disse kommandoer. Ved at lægge disse kommandoer på tidslinjen kunne animatorerne let beskrive, hvordan en skuespiller muligvis skal kigge på en ting, mens han taler med en anden, og går til et helt tredje sted – alt sammen på samme tid. Men tidslinjen var ikke en fast, lineær sekvens. Skuespillerne ville følge deres kommandoer, men de måtte reagere dynamisk på verden omkring dem. En skuespiller bruger måske længere tid på at flytte sig til et sted, hvis spilleren er i vejen, eller de skal muligvis vente med at levere en linje, fordi en anden skuespiller er blevet forsinket af spilleren. FacePoser gjorde det muligt for os hurtigt at gentage scener, prøve forskellige layouts, dialogleverancer og timinger. Denne evne til hurtigt at eksperimentere og justere viste sig at være kritisk for at finde de rigtige optrædner for at nå vores karakter- og fortællingsmål."
N/A4076"#commentary\cn_162_choreo_commands.mp3" "[ Yahn Bernier ] Denne fejlfindingsvisualisering viser de to mest almindelige Choreo-kommandoer, som skuespillerne modtager i løbet af en scene, internt kendt som look-ats og move-tos. Skuespillere får mål at se på – nogle gange mere end et ad gangen – og prøver derefter at fokusere på det, der giver mest mening i betragtning af deres nuværende tilstand. Samtidig modtager de muligvis flyttekommandoer, som instruerer dem i at flytte sig til et sted og vende i en bestemt retning eller mod et bestemt objekt. Selv disse tilsyneladende enkle kommandoer involverede en masse kompleksitet. En scene kan kræve, at en skuespiller taler, mens han skriver på et tastatur, alt imens han ser på et objekt, som spilleren holder. Da vi ikke kunne forudsige, hvor afspilleren ville være under afspilningen, krævede skrivningen af scener som denne, at vi opdelte hvert element i scenen i separate stykker og lag. Disse kunne derefter samles igen efter behov under afspilningen, baseret på spillerens handlinger, og afbrydes om nødvendigt."
N/A4077"#commentary\cn_163_antlions.mp3" "[ Kerry Davis ] Mens spilleren kørte buggyen gennem Coast-regionen, havde vi brug for en gennemgribende fjende, der med rette kunne dukke op hvor som helst og fungere som en konstant trussel for at holde spilleren i eller i nærheden af deres buggy. Antlions, der spawner fra sandet, var den perfekte løsning. Deres høje mobilitet gjorde det muligt for dem at holde trit med buggyen i korte udbrud, i modsætning til vores humanoide fjender. Plus, de var meget tilfredsstillende at køre over."
N/A4078"#commentary\cn_164_thumpers.mp3" "[ Adrian Finol ] Hvor det er muligt, er der stor værdi i spillere, der føler, at de har fundet ud af noget på egen hånd. Det får verden til at føles mere levende, snarere end bare en række gameplay-elementer, der er stillet op for spilleren. Hvis vi kan acceptere risikoen for, at en procentdel af spillerne måske helt går glip af et element, kan vi tage en mere subtil tilgang. Vi tog denne tilgang med Thumpers og designede situationer, som spillerne sandsynligvis støder på, men som de ikke er tvunget til at engagere sig i. Der er masser af visuelle og lydmæssige signaler, såvel som antlion-reaktioner til at hjælpe spilleren med at forstå, hvad der sker. Det garanterer ikke, at alle spillere finder ud af det, men playtesting viste, at de fleste gjorde det."
N/A4079"#commentary\cn_165_d2_coast_09.mp3" "[ Aaron Seeler ] Sent i udviklingen af Coast-området nåede vi et punkt, hvor vores spilkode var langt nok foran vores niveaudesign til, at vores gameplay-programmører ledte efter mere kode at skrive og nye opgaver, der kunne hjælpe med at gøre Half-Life 2 færdigt. Dette skyldtes i høj grad kravene fra Coast-niveauerne, som lagde en tung byrde på vores niveaudesignere med deres store skala og omfattende brug af terræn. Derfor begyndte vores gameplay-programmører at designe encounters i mindre skala. Senere, da vores niveaudesignere indhentede dem, skabte de dette niveau ved at sy tre separate encounters fra programmører sammen, og de udførte alt det nødvendige efterbehandlingsarbejde for at forberede det til udgivelse."
N/A4080"#commentary\cn_166_final_scene.mp3" "[ Bill Van Buren ] Det var lidt et kompromis at låse spilleren inde i en pod til den sidste konfrontation på Breens kontor, men det tillod et fokus på karaktererne, som vi virkelig ikke kunne give andre steder. Alle figurernes historier når deres konklusioner i denne scene, og det skaber muligheden for en reel følelsesmæssig gevinst - en klimaktisk scene drevet af kombinationen af dialog, stemmeoptrædener og animationer, hvis vi begrænser spilleren til dette synspunkt. Scenen var en udfordring at udføre fra et produktionssynspunkt; at opsætte den rigtige blokering og bevægelse, få effektiv timing og følelsesmæssig synergi og forbindelse fra alle de enkelte animationer og vokalforestillinger, der blev indspillet separat. Det krævede en masse tuning, før det nåede en dramatisk synergi og føltes virkelig som om alle karaktererne faktisk blev forbundet. "
N/A4081"#commentary\cn_167_end_game_scramble.mp3" "[ Dave Riller ] Der var oprindeligt en markant større koreografiscene planlagt til slutningen af spillet. Choreo-teamet havde dog meget travlt med den enorme mængde historiefortællingsarbejde, der manglede gennem hele spillet. For at fjerne noget arbejde fra deres bord blev Citadel-gameplay-gruppen bedt om i stedet at skabe en gameplay-udfordring til at afslutte spillet. Det kunne være et puslespil, en kamp, hvad som helst. Den resulterende Breen-bosskamp udnyttede eksisterende spilmekanik med supertyngdekraftpistolen og en lille smule brugerdefineret koreografi til at skabe et færdigt produkt på meget kort tid."
N/A4082"#commentary\cn_168_combine_portal_effects.mp3" "[ Gary McTaggart ] En vigtig del af vores udviklingsproces er den måde, hvorpå ethvert teammedlem kan bidrage med deres færdigheder til enhver del af spillet. Da det sidste kamp-gameplay var på plads, hjalp kunstnere og programmører af visuelle effekter med at hæve præsentationen af portalen til Combine-hjemverdenen og den standsede tidseffekt i slutningen af spillet. En brydningsshader svarende til den, vi brugte til vand, blev brugt til Combine-portaleffekten."
N/A4083"#commentary\cn_169_citadel_entrance.mp3" "[ Jeff Lane ] Vi byggede ruten ind i citadellet baglæns: den indvendige geometri blev skabt som en kunstprototype for at perfektionere udseendet. Vi vidste, at man kom fra kloakrøret på vores Streetwar-kort og var nødt til at oprette et afsnit af kureture og spring ind i Citadel-indgangen for at forbinde dem."
N/A4084"#commentary\cn_170_citadel_steep_landing.mp3" "[ Randy Lundeen ] Citadellet blev bygget meget sent i udviklingen, og oprindeligt havde vi ingen klar vision for dets gameplay. Dette er ikke usædvanligt – selvom spildesign normalt driver vores proces, kræver store kreative valg, som vi træffer tidligt, såsom eksistensen af Combine-citadellet, specifikt designarbejde, for at det passer ind i det endelige produkt. Efter det foregående kapitels klimatiske kamp mente vi, at en anden tone til finalen her i citadellet ville føles mere givende. Selv hvis vi havde ønsket at øge indsatsen, var det for risikabelt at skabe ny mekanik og NPC'er så sent. Vores første plan var at gøre det til et passivt fortællende skuespil – en togtur gennem hjertet af Combine-krigsmaskinen, der sluttede på Breens kontor. Men efter at vi havde udviklet den plan, brugte vi et par dage på at lave prototyper af supertyngdekraftpistolens mekanik, og vi tænkte, at vi i slutningen af spillet kunne opfylde spillernes ønsker ved at gøre dem almægtige uden at forstyrre spildesignets overordnede balance. Resultaterne var straks lovende, hvilket førte til et hurtigt redesign for at inkorporere supertyngdekraftpistolen. I stedet for traditionelle slutspilsudfordringer ønskede vi, at spilleren skulle føle sig guddommelig – gribe fjender efter forgodtbefindende, rive konsoller af vægge. I sidste ende blander citadellet disse to koncepter ved at skifte mellem skuespil og magt, der slippes løs."
N/A4085"#commentary\cn_172_lightmap_pass.mp3" "[ Mike Dussault ] Citadel-interiøret er relativt enkelt geometrisk, men Combine-metalmaterialet og den dramatiske belysning hjælper med at sælge strukturens uendelighed. Lightmap-opløsningen blev øget på vigtige, interessante overflader og reduceret på dem, der var fuldt skyggefulde eller fjerne. På grund af den store størrelse af Citadel-rummene havde unødigt store lightmap-overflader også en betydelig ydelsesomkostning. I slutningen af udviklingen blev der udført en stor gennemgang af Citadel-niveauerne for at optimere disse værdier for visuel interesse og ydeevne. Dette blev gjort lettere af en ny funktion tilføjet til Hammer-niveaueditoren, der viste overflader med deres luxel-tæthed."
N/A4086"#commentary\cn_173_super_gravity_origins.mp3" "[ Brian Jacobson ] På dette tidspunkt i udviklingen var vi sikre på designet af tyngdekraftpistolen. Vi ønskede at give spilleren en forsmag af at føle sig almægtig og gik i gang med at lave en superladet version. Det tog ikke lang tid – måske en dag med prototyping – før vi havde noget, vi kunne lide, og det blev kernen i gameplayet i Citadel. Med vores fysikmotor færdig kunne vi frit finde nye og spændende måder at presse den ud over dens tidligere grænser og give de sjove resultater, der kom ud af det. Vores prototypeobjekt – en ultratung vandmelon, der vejede flere hundrede kilo i vores fysik-sim – blev i sidste ende til de Combine-bolde, du oplever i spillet."
N/A4087"#commentary\cn_174_combine_energy.mp3" "[ Brian Jacobson ] Det, der startede livet som en vandmelon i prototypeform, endte med at blive til en energibold, da lydene, når den ramte ting og fra dens eksplosion, lød mindre som frugt og mere som det, vi har her i spillet. Da vi begyndte at iterere på niveauer, der ikke var vandmelonbaserede, indså vi, at vi kunne bruge energibolden ikke kun som en sjov måde at dræbe soldater på, men også som et puslespilelement til at tænde og slukke for forskelligt udstyr. På et væsentligt senere tidspunkt i udviklingen kunne vi ikke lide den AR2 alt-fire, som vi havde på det tidspunkt, og da holdet kunne lide Combine-bolden, endte vi med at inkorporere den lige i AR2 alt-fire. Når vi ser tilbage, er vi altid overraskede over, hvordan de ting, der fungerer uafhængigt af hinanden i spillet, sent samles for at løse problemer."
N/A4088"#commentary\cn_175_combine_wall_and_balls_training.mp3" "[ Ido Magal ] I playtests bemærkede spillerne ikke, at Combine-sfærer opløste soldaterne, og hvorfor de forsvandt. Vi forsøgte oprindeligt at løse dette ved at få sfærerne til at foretrække at hoppe mod fjender for at øge sandsynligheden for et opløsende drab. Vi indså til sidst, at grunden til, at spillerne ikke bemærkede effekten, var fordi det altid skete under intens kamp, og at folk har en meget begrænset evne til at lære nye ting, når de er under stress. Som en sen løsning indsatte vi et lavintenst træningsrum med et kraftfelt, der kun kan åbnes ved at gribe fat i Combine-bolden. Denne opsætning blev tilføjet specifikt for at træne, hvordan Combine-bolde kan deaktivere kraftfelter, og at sende dem mod soldaterne ville opløse dem. Selv da var det i playtestene kun moderat vellykket. På trods af vores indsats kæmpede nogle af spillerne stadig med at opfatte projektilernes opløsende virkninger. Vi løb tør for tid, og da spillerne stadig fortalte os, at de følte sig magtfulde, besluttede vi, at det var okay, hvis ikke alle sammen opfattede, hvorfor det lykkedes for dem."
N/A4089"#commentary\cn_176_weapon_strip.mp3" "[ Josh Weier ] Da vi introducerede supertyngdekraftspistolen, ønskede vi virkelig ikke, at spillerne vendte tilbage til deres konventionelle våben, så vi gjorde den eneste rationelle ting: vi opløste dem. Det hjælper at have en uudgrundelig overnaturlig fjende som Combine som antagonisten i dit spil, fordi det giver fin mening, at de kunne have en desintegrator. Hvorfor ikke? Og hvis vi af en eller anden grund havde brug for, at du fik dit udstyr tilbage midt i niveauet, havde de minsanten også en reintegrator."
N/A4090"#commentary\cn_177_breen_monologue.mp3" "[ Marc Laidlaw ] Kreativt arbejde sker aldrig i et vakuum, da vi alle er inspireret af andre ting. Breens monolog, der vises på Citadel-skærmene her, fik lidt inspiration fra et tidligere spil, vi alle elskede – Thief 2, hvor antagonisten håner spilleren, mens de sniger sig rundt. Udførelsen er helt anderledes, men kerneinspirationen er der. Det virkeligt tunge løft, som virkeligt sælger dette øjeblik, kommer imidlertid fra afdøde Robert Culps optræden. Hans levering var perfekt. Han fortolkede hver af Breens linjer med en subtilitet og flair, der forvandlede karakteren på papiret til noget virkelig specielt. En stemmesession med Robert Culp var noget af det nemmeste, du kunne forestille dig –han fik manuskriptet, og teknikeren trykkede på optag, og det var ca. det. Den lektie, der forstærkes her, er at man skal arbejde med mennesker, hvis talent overstiger ens eget, mennesker, man er sikker på at lære af. Gå ikke ind med en fast idé om, hvordan linjen skal leveres, eller hvordan et bestemt øjeblik skal udspille sig, men samarbejd i stedet med talentfulde mennesker og gå ind i det med tillid til, at de vil gøre det endnu bedre."
N/A4091"#commentary\cn_178_dissolved_weapons.mp3" "[ Quintin Doroquez ] Alle Combines våben blev af to grunde indstillet til at blive opløst, når Combine-soldaten blev forvandlet til en ragdoll af tyngdekraftpistolen. For det første så spillerne ikke kunne samle dem op og bruge dem, men også for at forbedre ydeevnen på disse kort. Derudover blev der tilføjet en ragdoll-manager, der fjernede de faldne soldaters ragdoll-lig, når spilleren fortsatte fremad."
N/A4092"#commentary\cn_179_elevator_fight.mp3" "[ Brian Jacobson ] Selvom vi ønskede, at spilleren skulle føle sig almægtig, kunne vi ikke modstå fristelsen til at tilføje en hård kamp ved elevatorskakten. Kampen, der ventede på elevatorens ankomst her, endte med at blive noget vanskeligere end oprindeligt forudset for denne del af spillet. Den blev gjort lettere under playtesting, men der var virkelig ikke nok playtest-tid til at afbalancere det til det niveau, den burde have haft. Selvom spilleren aldrig var i så stor fare, er det antallet af soldater, der vises, der får det til at føles som mere af en klimatisk kamp, end den er."
N/A4093"#commentary\cn_180_replacing_the_prefabs.mp3" "[ Jeff Lane ] Combine-energikuglerne er en relativt enkel opsætning med et kraftfelt, der holder på de evigt hoppende genstande. Under spiltesten var der dog gentagne fejl med energiboldene, der hoppede rundt, blev uberegnelige og 'undslap' det kraftfelt, vi satte op for at inddæmme dem. På grund af grænserne for vores præfabrikerede teknologi på det tidspunkt krævede dette, at de manuelt blev genopbygget flere gange på hver af deres placeringer, på alle Citadel-niveauer, der omfattede dem."
N/A4094"#commentary\cn_181_strider_fight.mp3" "[ Ted Backman ] En af de originale Citadel-prototyper omfattede at kunne gribe strideren med supertyngdekraftpistolen, og i lang tid handlede kampen med strideren om at komme tæt nok til at gribe den med pistolen. Mod slutningen af udviklingen besluttede vi, at det at gribe strideren fik dem til at føles for svage, især efter alle kampene mod dem i Street War, så vi erstattede træfningen med en, hvor du dræber den med Combine-bolde. Modeldele blev tilføjet, så strideren kunne gibbes og blæses fra hinanden i stedet for at trække kroppen rundt. Dette er den eneste gang i spillet, hvor en strider har denne effekt."
N/A4095"#commentary\cn_182_getting_in_the_pod.mp3" "[ Dhabih Eng ] Pod-opstigningssekvensen, der starter her, nødvendiggjorde fuld kontrol over scenen og spillerens synsvinkel. Dette er i strid med vores sædvanlige ønske om at lade spilleren bevare så meget kontrol som muligt. Til dette sidste trin følte vi, at afvejningen var det værd. Spilleren er så magtfuld på dette tidspunkt, at det var svært at kontrollere dem, så vi var nødt til at invalidere dem. Vi har stadig alle figurerne i scenen, der taler med spilleren og holder dem i centrum for opmærksomheden. Vi var også i stand til at levere en bid fortælling gennem miljøet undervejs. Togturen gennem citadellet, der starter her, indeholder flere modstandere, som vi havde visuelt indhold til, men som blev skåret fra hoveddelen af spillet. Fra din hyggelige pods sikkerhed kan du se behandlingen af stalkere og et hurtigt glimt af Crab Synth."
N/A4096"#commentary\cn_183_turrets.mp3" "[ Mike Dussault ] Tårne var et nyttigt designværktøj, mens spilleren havde bugbait, da de fuldstændigt kunne forhindre antlions i at nærme sig dem forfra. Dette gjorde det muligt for os at lave situationer, hvor spilleren ikke bare kunne kaste bugbait for at fortsætte – de var nødt til at cirkle rundt og rydde tårnene, så deres antlions kunne følge efter. Det skadede ikke, at det også var fedt at se antlions blive mejet ned af beskydning fra tårnet."
N/A4097"#commentary\cn_184_grenade_puzzle.mp3" "[ Aaron Seeler ] Denne lille gåde fik ofte spillerne til at sidde fast under playtests, fordi den ubegrænsede granatkasse blev placeret lidt bag dem på deres vej. På dette tidspunkt i spillet har spillerne fuldt ud lært at forbinde ubegrænsede ammunitionskasser med gådeløsning, så hvis der var en granatkasse her, ville de straks vide, at de skulle bruge en granat til at løse gåden. Vi ønskede, at de skulle tænke lidt først. Til sidst tilføjede vi et subtilt tip ved at gøre granater synlige på skrivebordet gennem et vindue, bare for at minde spillerne om, at de er tilgængelige. De hjalp også med at afdække en fejl i en playtest, da en spiller nærmede sig for at se nærmere på dem og endte med at samle granaterne op gennem glasset."
N/A4098"#commentary\cn_185_allied_turrets_balancing.mp3" "[ Adrian Finol ] Det var udfordrende at balancere denne kamp omkring de allierede tårne. Tårnene er det nye element her, så hvis spillerne ignorerer dem, føles gameplayet overflødigt, fordi så meget af det ligner det, der har været før. Vi ønskede, at det var nødvendigt at bruge tårnet, og at belønne den strategise placering, men det var meget binært – perfekt placering gjorde kampen let, mens dårlig placering gjorde den meget vanskelig. Fintuning og brugerdefineret AI-logik for soldaterne hjalp; soldaterne blev bedre til at vælte tårne ved at kaste med granater eller flankere dem for at slå dem ned. Disse ændringer gjorde, at kampen handlede mindre om en perfekt placering og mere om aktivt at vedligeholde tårnene, da enhver placering ville blive forstyrret på et tidspunkt. Playtests varierede meget, og nogle spillere fandt det for svært, mens andre kalder det deres yndlingskamp. Da vi løb tør for tid, gjorde vi det i sidste ende lidt lettere og udgav det, selvom vi ikke var tilfredse med den endelige balance."
N/A4099"#commentary\cn_186_meeting_mossman.mp3" "[ Ariel Diaz ] Det var vanskelig at genforene spilleren og Alyx med Mossman efter forræderiscenen, da mange spillere følte, at de skulle skyde Mossman med det samme. Vi kunne ikke tillade dette, da vi ikke havde tid til at udvikle alternative historiegrene. Vi ønskede dog heller ikke at fremhæve, at vi forhindrede dette valg, så vi havde som mål at reducere sandsynligheden for, at spillerne prøvede det. Det skudsikre glas her køber tid til dialog mellem Alyx og Mossman, hvor det bliver klart, at Alyx ikke synes, at det er det rigtige at skyde Mossman."
N/A4100"#commentary\cn_187_eli_in_pod_choreography.mp3" "[ Ken Birdwell ] Vi skrev og indspillede dialog til denne scene, mens vi stadig byggede Nova Prospekt. På det tidspunkt vidste vi, at Alyx og Gordon ville teleportere ud af fængslet, men ingen af detaljerne var blevet udarbejdet, så dialogen skulle være bred nok til at passe til det, vi i sidste ende byggede. Det fik os til at fokusere mindre på spillerens handlinger og mere på Alyxs sårbarhed og hendes forbindelse til sin far. Vi håbede, at følelserne ville bære scenen mere end selve fortællingen. I sidste ende sigter vi efter, at spilleren skal bekymre sig om disse karakterer – at ville prioritere, hvad der er vigtigt for Alyx."
N/A4101"#commentary\cn_188_mossman_and_eli.mp3" "[ Bill Van Buren ] Denne choreo-scene krævede betydelig iteration. Vi ønskede at levere et plottwist midt i scenen, mens vi holdt spillerkontrollen ubegrænset. Det krævede en delikat balance for at gøre det twist klart, men alligevel sørge for, at det ikke blev afbrudt. Hvis spillerne fulgte Alyx til konsollen, skulle de forstå, hvad der skete, når de vendte sig om. Hvis de forblev tilbage og så Mossman, havde de brug for at forstå, hvad der skete uden at føle, at det var noget, de skulle forsøge at forhindre. Det krævede omfattende tuning og playtesting at få timingen rigtig, men i sidste ende brugte vi en kombination af distraktion, leverede det afgørende øjeblik hurtigt og leverede endeligt en forklaring efter begivenheden."
N/A4102"#commentary\cn_189_nova_prospekt_entry.mp3" "[ Danika Rogers ] Spilleren har netop afsluttet to kamptunge niveauer, så vi ønskede at bremse tingene, når de kom indenfor. Disse tidlige niveauer blev designet som en tempoændring, så spillerne kunne udforske layoutet af Nova Prospekts interiør. Undervejs begyndte vi at introducere tårn-gameplayet, først som en fjende for spilleren og senere som et værktøj, spilleren kan bruge. Meget af dette niveau blev bygget ved at genbruge prototype- og illustrationsrum skabt tidligere i projektet, da vi var fokuseret på at forme udseendet på Nova Prospekt."
N/A4103"#commentary\cn_190_turret_training_exit.mp3" "[ Doug Wood ] Denne bunke affald sammen med den rodede nedstigning ned ad trappen er designet til at afskrække spillere fra at tage et tårn med sig. Selvom det ikke ville ødelægge noget, hvis de gjorde det, ønskede vi at gøre det mindre sandsynligt. Det er ikke en ideel designstrategi at gøre det ubelejligt at beholde tårnet, men det var bedre end ingenting. Mange playtestere gav til sidst op og kastede tårnet fra sig, når de følte, at spillet forsøgte at fortælle dem noget."
N/A4104"#commentary\cn_191_allied_antlions.mp3" "[ Eric Kirchmer ] At have en endeløs antlionhær, der angreb tårne og soldater, betød, at vi måtte bruge tid på at finde ud af spillerens rolle i Nova Prospekts kamp. Spilleren havde allerede stået over for masser af Combine-soldater, så vi besluttede, at vi ville have kamp her til at føles mere som et hovedbrud og et skuespil i stedet for en kampudfordring. Med det in mente skabte vi situationer, der forblev i en stabil tilstand, indtil spilleren greb ind. Ved direkte at dræbe fjender kunne spilleren tippe balancen til fordel for antlions – men vi ønskede at gøre brugen af bugbait særligt givende. I mange scenarier aktiverede vi yderligere antlion spawners, når spilleren kastede bugbait på fjender, hvilket førte til en hurtig tilstrømning af nye antlions i kampen. Det resulterende blodbad var belønningen, der gjorde bugbait tilfredsstillende at bruge."
N/A4105"#commentary\cn_192_laser_mines.mp3" "[ Erik Johnson ] Vi nød virkelig at bringe disse lasersnubleminer ind i Nova Prospekt. De var et våben fra Half-Life 1, som vi ikke havde formået at inkludere i Half-Life 2, men endelig fandt de et sted som et hovedbrudselement. Vi kunne godt lide, hvordan de fungerede som en slags personlig moraltest, mens spilleren havde en antlionhær. Nogle spillere kastede straks bugbait forbi snubleminerne og kastede antlionlig efter problemet, mens andre holdt deres små venner tilbage, indtil de sikkert havde fjernet snubleminerne med andre værktøjer. Vi dømte ikke."
N/A4106"#commentary\cn_193_final_turret_arena.mp3" "[Erik Johnson] Når vi skaber et handlingsforløb for et gameplayelement, såsom brugen af allierede tårne, bygger vi ofte en prototype, der repræsenterer forløbets endepunkt først. Vi itererer på den prototype, indtil playtestene viser, at den fungerer. Derefter arbejder vi baglæns og tilføjer forudgående scenarier for at introducere elementet og opbygge spillerfærdigheder. Denne tilgang sikrer, at det endelige forløb er engagerende, før vi investerer betydelig tid. Det betyder også, at når vi laver træningsscenarier, har vi observeret nok playtests til at vide, hvilke færdigheder kræver vejledning, og hvilke spillere der vil forstå det naturligt. Dette sidste tårnscenarie var vores mål og understregede spillerens forsvar mod fjender fra flere retninger, hvilket krævede dynamisk tårnplacering og genopretning."
N/A4107"#commentary\cn_194_one_way_drops.mp3" "[ Jakob Jungels ] Spillerne ved aldrig, hvad der er foran dem, men de er bekendt med, hvad der er bag dem, så det er almindeligt, at de trækker sig tilbage til kendt grund, når de støder på en fjende. Hvis vi har bygget en arena, hvor vi vil have spilleren til at engagere sig – især for en fjende med specifikke geometriske krav, som Antlion-vagten – har vi brug for en måde at forhindre dette tilbagetog på. En almindelig løsning er at kræve, at spilleren kommer ind i arenaen gennem et envejsfald, som du sandsynligvis allerede har bemærket et par gange."
N/A4108"#commentary\cn_195_npcs_on_elevators.mp3" "[ Jay Stelly ] Vi bruger ofte en betydelig mængde tid på at løse problemer, som spillerne måske ikke engang bemærker. Mange af disse er subtile designudfordringer, mens andre stammer fra flere systemer, der interagerer med hinanden. For eksempel var det et komplekst problem at få ikke-spillerfigurer til at køre med elevatorer, fordi det involverede forskellige systemer – NPC AI-beslutningstagning, navigationsplanlægning og bevægelsessimulering for at nævne nogle få. Derudover havde elevatoren selv sine egne simuleringskrav, der ikke var relateret til NPC'er. En af de mere subtile udfordringer kom fra det faktum, at vi simulerer NPC'er i en langsommere hastighed, end vi simulerer elevatorer. Dette betød, at NPC'er på en nedadgående elevator ville simulere – for at sikre, at de stod korrekt på elevatoren – og derefter simulerede elevatoren et par gange og bevægede sig længere ned ad elevatorskakten hver gang, mens den subtilt efterlod NPC'en hængende. Kort efter simuleredes NPC'en igen og faldt ned på elevatorgulvet igen. Du kan sikkert forestille dig, at det var svært at tage Alyx alvorligt, mens hun konstant faldt ned i små ryk, mens hun talte med dig."
N/A4109"#commentary\cn_196_looktargets.mp3" "[ John Cook ] Et af nøgleværktøjerne i vores designværktøjssæt er LookTarget – et usynligt punkt i rummet, der aktiveres, når spilleren ser på det. Designere kan angive, hvor præcist spilleren skal se på det, hvor længe spilleren skal se på det og andre forhold. Når det er aktiveret, udløser Looktarget forskellige begivenheder i spillet. For eksempel kan Alyx vente på, at spilleren ser på hende, før systemet leverer en dialog, en scene begynder måske kun, når det er i sigte, eller et Combine-dropship kan flyve ovenover, når spilleren kigger i dens generelle retning. Efter vi implementerede Looktargeting, fandt designerne uendeligt mange måder at bruge det på til at få gameplayet til at føles mere pålideligt for spillerne, især da nogle spillere bevæger sig med meget forskellige hastigheder eller på måder, der er vanskelige at forudsige."
N/A4110"#commentary\cn_197_nova_prospekt_yard.mp3" "[ John Morello ] Kampen i hele Nova Prospekt-gården var stort set inspireret af vores tidlige observationer af antlions, der kæmpede mod Combine-soldater. Antlions høje mobilitet og nærkampsangreb passede godt sammen med soldaternes dødelighed på afstand og sårbarhed tæt på. Antlions ser godt ud under beskydning, med partikeleffekter, der flyver overalt, og når de endelig når en soldat, er den resulterende ragdoll-effekt utroligt tilfredsstillende."
N/A4111"#commentary\cn_198_vent.mp3" "[ John Morello ] Du ved sandsynligvis allerede det her, men hvis der er en udluftning, skal der være hovedkrabber i den. Vi laver ikke disse regler, de kommer ligesom ventilationsåbningerne direkte oppefra."
N/A4112"#commentary\cn_199_kitchen.mp3" "[ Kerry Davis ] Det er en velkendt skik blandt spiludviklere, at alle køkkener i computerspil skal have en gaseksplosion."
N/A4113"#commentary\cn_200_alyxs_tool.mp3" "[ Laura Dubuk ] Alyxs multiværktøj var utroligt nyttigt til at lade os bruge hende som en nøgle. Ofte havde vi brug for at forhindre spilleren i at bevæge sig fremad, indtil vi var klar, og hendes multiværktøj gjorde det muligt for hende at levere dialog, mens hun låste op for vejen frem. Vi benyttede os sandsynligvis lidt for meget af det, men det var svært at modstå. Der er altid en afvejning – ved at bruge Alyx til at lukke et rum op i stedet for at skabe en brugerdefineret løsning, sparer vi tid, som vi kunne bruge på andre dele af spillet, der ofte var mere kritiske."
N/A4114"#commentary\cn_201_mossmans_betrayal.mp3" "[ Marc Laidlaw ] Vores oprindelige plan for Judith Mossmans fortællingsforløb var, at hun skulle forråde spilleren omkring dette tidspunkt. Men da vi nåede til denne scene, efter at have udviklet andre dele af spillet, følte vi, at hun mere sandsynligt bare forsøgte at beskytte Eli. Vi forestillede os, at hun genovervejede, og indså, at hun faktisk ikke kunne forråde Gordon. Vi havde ideer til at afklare dette skift senere, men i sidste ende afsluttede vi aldrig hendes fortælling. Vi kunne godt lide tvetydigheden i Mossman, men spillerne virkede ikke til at kunne lide det – de hadede hende næsten universelt. Det kan dog være en succes; vi arbejdede hårdt for at opbygge spillerens affinitet for Alyx, og Alyx var heller ikke ligefrem fan af Judith."
N/A4115"#commentary\cn_202_d2_prison_05_start.mp3" "[ Yahn Bernier ] Da spilleren kunne flytte et stort antal objekter, løb vi ofte ind i udfordringer, især i betragtning af begrænsningerne i CPU'erne i 2003. En begrænsning var, at vores AI-navigationssystem ikke var opmærksom på dynamiske fysikobjekter, som disse metalsenge. Mens vores NPC-bevægelsessystem kunne registrere og undgå fysikobjekter under bevægelse, var de i bund og grund usynlige under navigationsforespørgsler til strategisk planlægning før bevægelse. Dette skyldtes primært ydelsesbegrænsninger – vi havde ikke råd til noget mere komplekst. Vi stod også over for designudfordringer uden klare løsninger, som eksempel hvordan en soldat skulle reagere, hvis en spiller fuldstændigt blokerede en korridor med store fysikobjekter. For at løse dette gav vi NPC'er yderligere styrke til at skubbe rundt på fysikobjekter. Vi dæmpede derefter problemet ved hjælp af niveaudesign, udvidelse af korridorer og ved at sikre nok tomme områder til at håndtere rekvisitter, der kan lande hvor som helst i dem. Denne opsætning er en højrisiko-opsætning: Kombinationen af soldater, der gemmer sig bag senge, og antlions, der stormer i nærkamp, skaber en god chance for akavede interaktioner mellem NPC-bevægelsessystemet og sengene."
N/A4116"#commentary\cn_203_alyx_as_companion.mp3" "[ Miles Estes ] Denne sektion blev en utilsigtet prototype for, hvad Episode 1 i sidste ende kom til at indeholde: Alyx som ledsager, der bevæger sig gnidningsløst langs en sti, der blander dynamisk kamp med manuskriptbaseret koreografi. Vi havde endnu ikke en klar model for, hvordan hun ville passe ind sammen med spilleren i disse scenarier, men selv denne korte sektion lærte os meget, på trods af at vi ikke havde nok tid til at eksperimentere med den."
N/A4117"#commentary\cn_204_laundry.mp3" "[ Mike Dussault ] Når spilleren når dette niveau, der er kendt som Laundry, er vi sikre på, at de er komfortable med at bruge bugbait til at løse kampscenarier. Så vi ønskede at hæve indsatsen lidt ved at skabe et scenarie, der tilskynder spilleren til at blive endnu mere involveret, ved at kombinere bugbait med deres fulde arsenal af våben."
N/A4118"#commentary\cn_205_side_zombie.mp3" "[ Quintin Doroquez ] Denne giftige zombie var altid et højdepunkt i playtests. Spillerne, der havde været så fokuserede på Combine-soldater, antlions og tårne, havde ikke set en gift-zombie i lang tid, så dens pludselige optræden i mørket skabte ofte et øjeblik af chok."
N/A4119"#commentary\cn_206_flares.mp3" "[ Quintin Doroquez ] Dette afsnit er et godt kontrapunkt til det forrige tårnsegment med hensyn til produktionsomkostninger og iteration. Det blev bygget meget sent, men faldt hurtigt på plads, da AI'en til Alyx og Combine-soldaterne allerede var på plads. Vi kunne godt lide mørket og lysglimtene og lagde det til side som noget, vi skulle se på senere. Senere reviderede vi det igen, da vi planlagde de mørke sektioner i Episode 1."
N/A4120"#commentary\cn_207_magic_wall.mp3" "[ Robin Walker ] Som med mange af vores kamparenaer havde vi brug for en port af en eller anden slags for at forhindre spillerne i at gå videre, før de afsluttede denne kamp. Desværre var vi løbet tør for tid og måtte gå videre til togstationen, så vi endte med denne smule magisk vrøvl: En mur, der bare eksploderer, efter at det andet kampfartøj er besejret, hvilket viser vejen frem. Vi forsikrede os selv om, at de fleste spillere ikke ville bemærke det, da de ville have travlt med at kæmpe mod kampfartøjerne, og vores playtesting havde vist, at de generelt alle afsluttede kampen, før de nåede til dette punkt. Med nok eksplosioner i hele arenaen føltes den ødelagte, brændende mur temmelig naturlig, så vi kastede et par enkle gasgåder på den anden side for at retfærdiggøre det. Men nej, vi er ikke ligefrem stolte af det."
N/A4121"#commentary\cn_208_ragdoll_vortigaunt.mp3" "[ Scott Dalton ] Der er meget smerte at se i denne døde vortigaunt – vores niveaudesigneres smerte. På det tidspunkt tillod vores udviklingsværktøjer os ikke direkte at opstille en ragdoll, hvilket vil sige, at vi ikke havde nogen kontrol over, hvilken position den endte i, når en NPC dør, og den systemisk ragdolls faldt til jorden. Hvis vi havde haft lidt animatortid, kunne de have givet os en enkelt rammeanimation i nogenlunde den position, vi ønskede, men vi var forsinkede, og vores lille animationsteam var allerede overbelastet. Så en niveaudesigner placerede vortigaunten over denne stol, bad den dø, mens niveauet blev indlæst, og ventede på at se, hvilken position ragdollen landede i. Derefter flyttede designeren Vortigaunten lidt og prøvede det igen. Vi kan ikke huske nøjagtigt, hvor mange forsøg det tog, men det var langt, langt flere, end man skulle tro."
N/A4122"#commentary\cn_209_nova_prospekt_process.mp3" "[ Eric Smith ] Ligesom Ravenholm blev Nova Prospekt oprindeligt designet med markant anderledes gameplay end det, der i sidste ende blev leveret. Den første version fokuserede på kamp mellem spilleren og Combine-soldater uden inddragelse af antlions. I modsætning til andre områder af spillet, hvor gameplay og kunst udviklede sig sammen, fik Nova Prospekt tidligt et stort kunstskub. Dette producerede et sæt genanvendelige, polerede sektioner af niveaugeometri, hvor grafikken allerede var til stede. Det fungerede godt at samle Nova Prospekt fra disse stykker, da fængslets layout var naturligt repetitivt. Og senere, da vi vendte tilbage med antlions og bugbait, måtte vi lave geometrien om, så den passede til det nye gameplay."
N/A4123"#commentary\cn_210_d2_prison_04.mp3" "[ Eric Kirchmer ] Gennem udviklingen skabte vores kunstnere små lodrette skiver af miljøer, som vi kaldte art zoos. Disse zoologiske haver bestemte, hvordan vi brugte teksturer og rekvisitter til at skabe gameplay-rum, der opnåede vores visuelle mål. Men da vi byggede fængslets gameplay-spor, tillod det gentagne layout os at bruge kunsten mere direkte. Dette kort blev oprindeligt bygget som den primære art zoo for Nova Prospekt, men efter at være blevet brugt til at teste forskellige gameplay-prototyper – inklusive dem, der til sidst førte til bugbait – blev det en del af den faktiske niveauarkitektur."
N/A4124"#commentary\cn_211_autosave_dangerous.mp3" "[ Dave Riller ] I Half-Life 1 havde vi et sæt autosaves gennem hele spillet, håndplaceret af niveaudesignerne, der blev udløst, når spilleren nåede et bestemt øjeblik eller sted i spillet. Dette sikrede, at spillet automatisk blev gemt for dig, når du krydsede gennem Black Mesas korridorer. I Half-Life 2 havde vi brug for et nyt værktøj. Problemet opstod i nogle af de mere komplekse arenaer, vi havde bygget. Nogle af disse encounters ville vare i et stykke tid og indeholdt flere sæt fjender. Andre var lange, spredte blandinger af udforskning og kamp uden nogen klar adskillelse mellem de to. Vi ønsker aldrig en autosave, hvor spilleren er i fare for at dø lige efter indlæsning af spillet, fordi det kan placere spilleren i en dødssløjfe – hvis du spillede nok spil dengang, her du med sikkerhed befundet dig i denne situation mindst én gang. Så medmindre vi bevidst lavede pauser i hver arenas flow, var der ikke altid et sikkert sted at placere et autosave. Efter nogle forsøg implementerede vi en funktion kaldet Autosave Dangerous. Dette var et niveaudesignværktøj, der kombinerede autosave med en tilknyttet tidsramme. Når det blev udløst af niveaudesigneren, gemte det straks spillet, men holdt det gemte spil til siden, så det ikke var tilgængelig som et gemt spil, der kunne indlæses. Hvis spilleren derefter forblev i live i den angivne tidsramme, så blev gemningen udført og brugt som det seneste autosave. Dette gjorde det muligt for niveaudesignere at placere en autosave på et rimeligt sted eller tidspunkt i en arena, angive et tidsinterval, som tredive sekunder, og hvis spilleren stadig levede i efter tredive sekunder, ville autosave blive brugt."
N/A4125"#commentary\cn_212_we_dont_go_to_ravenholm.mp3" "[ Dario Casali ] Da vi var færdige med vores arbejde på Ravenholm, kunne vi ikke ryste følelsen af, at overgangen fra Eli's Lab bare ikke fungerede. Den var alt for hård – Elis laboratorium var forbundet direkte til byens gader, hvor du snart kommer hen, og den sektion, du står i, eksisterede ikke. Vi havde lige givet dette løfte i slutningen af Eli's Lab: \"Vi tager ikke derhen længere\", og vi kunne godt lide den samlede opbygning, vi havde skabt. Men da spilleren kom til Ravenholm, blev de straks smidt i kamp med zombier uden plads til spændingsopbygning. Så vi byggede dette afsnit og de efterfølgende smalle korridorer for at tackle det på en måde, vi var tilfredse med. Vi bremsede tempoet, fokuserede på kunst og belysning og gjorde dig klar til at opleve, hvorfor vi ikke tager til Ravenholm længere."
N/A4126"#commentary\cn_213_lever_shenanigans.mp3" "[ Dario Casali ] Selv med alt det arbejde, vi lavede for at forsøge at skabe en forbindelse mellem dette håndtag og det udvendige elektriske hegn i spillerens sind, ville nogle testere stadig trække i håndtaget uden at vide, hvad de havde gjort. De ville endda vandre rundt, trække i håndtaget igen og vandre lidt mere rundt. Da der ikke var meget tid tilbage at bruge på at gøre forbindelsen klarere, valgte vi bare at få håndtaget til at knække. Dette forhindrede spillerne i at fortryde deres handling, og tilføjede følelsen af, at Ravenholm var et upålideligt og forfaldende miljø."
N/A4127"#commentary\cn_214_town_arenas.mp3" "[ Dario Casali ] På dette tidspunkt i Ravenholm har spilleren lært alle de gameplay-elementer, der er tilgængelige for dem, og kan forudsige deres interaktioner. Dette giver os mulighed for at opbygge mere komplekse situationer, der giver et større trusselsniveau og mere frihed i, hvordan spilleren kan gå til hvert scenarie. Denne arena er et bevidst sammenflettet rum, som spilleren bliver nødt til at udforske, og vi bruger denne efterforskningstid til langsomt at øge kampens intensitet. Jo hurtigere spilleren udforsker, jo hurtigere skruer vi op for intensiteten. Designets frie form gjorde det udfordrende at tune, givet det store dynamiske område af måder, spillerne spillede igennem det på."
N/A4128"#commentary\cn_215_mines.mp3" "[ Dario Casali ] Den komplekse rute, spilleren tager for sikkert at navigere gennem denne mineskakt, giver dem masser af tid til at se, hvad der venter på dem på bunden. Surprise: Det er hovedkrabber. Helt ærligt det er ofte hovedkrabber. Men i dette tilfælde er det giftige hovedkrabber, som er sjove i sig selv, men en rigtig fest, når du føjer hurtige hovedkrabber til blandingen. Disse to udgør en fantastisk kombination: Ingen af dem er særligt farlige alene, men sammen er de utroligt dødbringende. Når spilleren først er forgiftet, kan et enkelt slag fra en hurtig hovedkrabbe dræbe spilleren. Og det er det, biologer kalder symbiose. I det mindste er det det, vi mener."
N/A4129"#commentary\cn_216_poison_headcrabs.mp3" "[ David Speyrer ] Dette rum introducerer utilsigtet giftige hovedkrabber. Vi havde brugt meget tid på at udforme deres ordentlige introduktion senere på niveauet, men da vi så, hvor godt de fungerede, tog vores iver over, og inden længe havde vi spredt dem ud over niveauet. Da vi indså, at de var dukket op før deres intro, var det virkelig for sent at lave det om. Heldigvis fungerer et snævert rum med giftige hovedkrabber som anstændig træning, fordi deres design undgår et almindeligt problem med kamptræning. Spillerne er typisk stressede, og de kan blive frustrerede, hvis de dør gentagne gange uden at forstå hvorfor, og vi stødte da også på det problem, da vi forsøgte at træne spilleren med både giftige hovedkrabber og deres kilde, giftzombien. Giftige hovedkrabber kan dog ikke dræbe spilleren alene. Så mens det er stressende, undgår spilleren i det mindste den frustration med et rum fuld af dem."
N/A4130"#commentary\cn_217_poison_zombie_introduction.mp3" "[ David Speyrer ] At begrænse spilleren i et trangt rum, mens du giver dem udsigt udad, er en nyttig måde at øge chancerne for, at de vil bemærke noget, vi vil have dem til at se. Her henleder vi spillerens opmærksomhed med lyden af jamren, før giftzombien selv bliver synlig. Oprindeligt var dette møde også første gang spilleren stod over for giftige hovedkrabber, men som nævnt tidligere blev vi alt for entusiastiske i at sprede giftige hovedkrabber rundt om i niveauet, så vi endte med at ødelægge deres fælles introduktion her. I sidste ende fungerede disse første møder dog alligevel bedre som separate tilfælde."
N/A4131"#commentary\cn_218_final_arena.mp3" "[ Eric Smith ] Da vi afsluttede den første gennemgang af Ravenholm, var dette tag beregnet til at være den kulminerende kamp. Ligesom andre rum i Ravenholm var det begyndt som et rum, der udelukkende var fokuseret på at være en interessant visuel placering. Vi følte, at det var vigtigt, at de, når spilleren forlod Ravenholm, havde et øjeblik til at se tilbage ud over byen, de lige havde overlevet, og få et glimt af, hvor de var på vej hen herefter. Flere gameplay-grupper tog en chance for at skabe en kamp her, men den stramme geometri og præstationsbegrænsninger betød, at vi aldrig rigtig skabte en finale, vi var tilfredse med. Ikke ulig selve Half-Life-sagaen virkede det som om Ravenholm var bestemt til ikke at have en reel afslutning."
N/A4132"#commentary\cn_219_tables_and_bodies.mp3" "[ Ido Magal ] Mod slutningen af Ravenholms produktion, med alle de store elementer på plads, gik vi gennem spillet og forsøgte at udfylde hver eneste tomme plads med noget interessant. Vi måtte her være forsigtige med at bruge det, vi allerede havde, og ikke skabe noget nyt, da vi ikke kunne risikere at introducere flere fejl. Ofte, som i dette rum, forsøgte vi at tilføje nye øjeblikke af gameplay, samtidig med at vi tilføjede flere detaljer og historiefortælling til området. Små scener som denne giver en opmærksom spiller mulighed for at tænke over, hvad de ser, og hvad det kan betyde for, hvad de vil støde på næste gang."
N/A4133"#commentary\cn_220_physics_object_consistency.mp3" "[ Kerry Davis ] Alle fysikobjekter har en række parametre, der definerer deres adfærd: deres masse, mængden af skade, de tager, før de går i stykker, hvad de går i stykker som osv. Under udviklingen blev disse parametre specificeret af niveaudesignerne for hvert element, hvilket er måden, de fleste ting i spillet fungerede. Men senere i udviklingen indså vi, at vi havde skabt et problem for os selv – der var tusinder af fysikobjekter i spillet, og ingen metode til at sikre konsistens på tværs af dem. På grund af det kan en papkasse gå i stykker med et enkelt pistolskud på et niveau og være fuldstændig usårlig på et andet. Internt omtalte vi generelt disse uoverensstemmelser som niveaudesignerforbrydelser. For at løse disse og for at levere noget retfærdighed byggede vi et system, der håndhævede konsistens på alle fysikobjekter baseret på deres visuelle model. Da det meste af spillet allerede var bygget, blev vi tvunget til at tillade niveaudesignerne udtrykkeligt at fravælge dette system i sjældne edge-tilfælde, hvor de havde brug for at gøre noget kriminelt for at bevare det, de havde designet. Internt henviser vi til disse designere som recidivister, og nogle af dem foreviger deres kriminelle liv hos Valve den dag i dag."
N/A4134"#commentary\cn_222_fast_zombie_introduction.mp3" "[ Randy Lundeen ] Dette rum var et andet område, der oprindeligt blev bygget til E3 2003, hvor det viste spilleren, der kæmpede mod en gruppe Combine-soldater. Da vi vendte tilbage for at bruge det til at introducere den hurtige zombie, forsøgte vi at beholde så meget af det tidligere arbejde som muligt. Vi ønskede et ikonisk, måneoplyst skud, med zombier, der sprang forbi månen som varulve for at tiltrække spillerens blik. Når dette øjeblik er forbi, introducerer vi den første hurtige zombie til spillerrummet og sender den efter spilleren. Det krævede en masse iteration at finde den rigtige balance i belysningen, for at scenen kunne se godt ud, samtidig med at den sikrede, at den også fungerede for gameplay-målene."
N/A4135"#commentary\cn_223_ravenholm_gameplay_focus.mp3" "[ Mike Dussault ] Efter at have set mange playtests af Ravenholm vidste vi, at niveauets kernespil drejede sig om tyngdekraftspistolen og fysikken. Da vi først havde den viden, følte vi, at vi på passende vis kunne bygge overgangen til Ravenholm og hjælpe spilleren med at lære og forstå lidt om, hvad den kommende oplevelse ville være. Dette sker ofte – vi bygger niveausporet, finder ud af, hvad der fungerer, og designer derefter dets prolog. Vi byggede det følgende sæt rum med den opsætning i tankerne. Brutaliteten af de værktøjer, vi giver spilleren, syntes at hjælpe med at skabe den stemning, vi stræbte efter, og hjalp med at skifte tonen fra sikkerheden i Elis laboratorium til noget mørkere og mere skræmmende."
N/A4136"#commentary\cn_224_player_tools.mp3" "[ Steve Bond ] På dette tidspunkt i spillet har spillerne en masse erfaring med Half-Life 2's fysik, men de har lige fået tyngdekraftpistolen, som giver en helt ny måde at interagere med fysikobjekterne i spillet på. Vi itererede på en række fysikobjekter, som spilleren kunne lege med. Ting som savklinger, katapulter, eksplosive beholdere, fælder, spyd osv. Og finpudsede dem, der fungerede godt med fysikpistolen og droppede dem, der ikke gjorde det. Derefter gik vi i gang med at rydde niveauerne for ammunitionsgenstande, så spilleren måtte bero på disse objekter for at overleve. "
N/A4137"#commentary\cn_225_contrived_setups.mp3" "[ Kerry Davis ] Der er en temmelig åbenlys konstruktion i en stor del af tyngdekraftpistol- og fysikobjekttræningen. Spilleren trækker et savblad ud af væggen med tyngdekraftpistolen, og som kaldet vakler en zombie rundt om hjørnet og tigger om at få et savblad affyret mod sig. Derefter kravler spilleren under en fælde med en roterende klinge for at slukke den, og pludselig dukker tre zombier op, der håner spilleren til at tænde fælden igen. Vi havde ikke meget tid til at iterere på dette afsnit, så vi havde brug for opsætninger, der fungerede for alle spillere, ikke mere åbne, der krævede, at de foretog det 'rigtige' træk. Selvom denne form for design har potentialet til at reducere spillerens kreativitet, fandt vi i dette tilfælde, at de ikke syntes at have noget imod, at vi tvang deres hånd lidt."
N/A4138"#commentary\cn_226_misteaching_flinches.mp3" "[ Kerry Davis ] En anden mindeværdig playtest og et eksempel på faren for at fejltræne spillerne fandt sted i Ravenholm. Et af vores designprincipper er, at spillet reagerer på spilleren så meget som muligt. Så da vi designede tyngdekraftpistolen, virkede det indlysende, at der skulle ske noget, hvis spilleren pegede den mod en zombie og trykkede på aftrækkeren. Det var nemt nok at få den til at beskadige zombien for en lille mængde skade, hvilket fik zombien til at afspille sin flinch-animation, som føltes godt og responsiv. Senere så vi en playtest, hvor testeren opdagede denne interaktion umiddelbart efter ankomsten til Ravenholm, og fortolkede det som feedback om, at tyngdekraftpistolen skadede zombien ... hvilket den gjorde, bare ikke særlig meget. Så de skød zombien igen, gentagne gange og gav den stød igen og igen, indtil den døde. Dette er en langsom, usjov, umenneskelig måde at bekæmpe zombier på, især når du er omgivet af savklinger og eksplosive beholdere. Efter at have lært vores lektie fjernede vi den flinch-animation, selvom det betød, vi mistede interaktionen mellem zombien og tyngdekraftpistolen. I dette tilfælde var det bedre ikke at have denne enkle interaktion snarere end at give det falske indtryk, at tyngdekraftpistolen var en effektiv måde at bekæmpe zombier på. Selv enkle principper kan kræve afvejninger, når du dykker ned i detaljerne."
N/A4139"#commentary\cn_227_fire_trap.mp3" "[ Steve Bond ] Denne brandfælde var oprindeligt tænkt som et visuelt udstillingsstykke til ildsystemet, før en niveaudesigner genbrugte det som et gameplay-element til Ravenholm. Det blev næsten droppet flere gange under udviklingen på grund af ydeevnepåvirkningen på low-end-computere på grund af al den overtegning, der er involveret i de gennemsigtige sprites. Til sidst var der en programmør, der følte, at det var vigtigt nok for spillet, at det var værd at gøre arbejdet for at løse ydeevneproblemerne og sikre, at vi kunne få det ind i spillet. "
N/A4140"#commentary\cn_228_hallway_cupboards.mp3" "[ Yahn Bernier ] Disse skrammelfyldte gange var en enkel løsning på vores behov for at bremse spilleren. Med begrænsningen af at bevare så meget af den eksisterende geometri som muligt kombineret med langsomt bevægende zombier som hovedfjende, var det vanskeligt at forhindre spilleren i bare at sprinte igennem her. Heldigvis gjorde Grigori som den vanvittige indbygger i Ravenholm disse situationer lettere at retfærdiggøre – det giver god mening, at han blokerede trappeopgangen for at holde sig sikker på hustagene. I sidste ende var Grigoris løsning og vores en og samme: bare smid en masse møbler i vejen – for hvis det stopper zombier, vil det sandsynligvis også bremse spilleren."
N/A4141"#commentary\cn_229_pacing_switch.mp3" "[ Steve Bond ] Nu da spillerne er gennem træningssektionen, kan vi begynde at flytte tempoet fra lunefulde klaustrofobiske rum til mere kampfokuserede actionarenaer. Efter spilleren er bekendt med de forskellige fysikværktøjer i miljøet, kan vi begynde at blande dem i åbne rum og bare give spilleren friheden til at vælge sin egen tilgang. "
N/A4142"#commentary\cn_230_car_crushers.mp3" "[ Steve Bond ] Disse bilknusere krævede nogle justeringer og en hel del arbejde på vores fysiske skadesystem. Der er altid en udfordring, når store fysikobjekter interagerer med ikke-spillerfigurer. Hvis fysikken eksempelvis kan skubbe NPC'en, kan den skubbe dem et sted, hvor de ikke skal hen, hvilket efterlader dem ude af stand til at komme tilbage. Dette er ikke et stort problem for noget som en hovedkrabbe, som bare kan hoppe ud af en vanskelig situation, men for noget som en zombie kan det betyde, at den sidder fast og ender med at fægte hjælpeløst med armene i det hul, den har formået at kile sig fast i. Det dræber den overlevelseshorrorstemning, vi går efter her. "
N/A4143"#commentary\cn_231_car_crusher_lifts.mp3" "[ Eric Smith ] Det var også vanskelig at få bilknuserne til at løfte spilleren. Se her, spilleren bliver altid simuleret af både fysiksystemet og spillets bevægelsessystem. Hver gang vi opdaterer spillerens tilstand, sammenligner vi resultaterne fra begge systemer og beslutter, hvilket der er 'rigtigt', og synkroniserer dem derefter og gentager. Dette gør det muligt for de to systemer at påvirke hinanden – som når spilleren står på en vippe, så lader fysikken brættet vippe, eller når de står på bilknuseren, så løfter den dem op. Selvom det var mere komplekst, var denne dobbelte systemtilgang lettere at indstille end at forsøge at håndtere både fysik og spillerbevægelse i et enkelt system. Ved at holde dem adskilt kunne vi finjustere bevægelsessystemet, så det føltes godt alene, og kun forene de to, når fysikken påvirkede spilleren."
N/A4144"#commentary\cn_232_paint_cans.mp3" "[ Steve Bond ] Da vi begyndte at have held med at gøre tyngdekraftpistolen og fysik-gameplayet til kernen i Ravenholm-oplevelsen, begyndte vi at gå gennem niveauerne og lede efter objekter, som vi måske havde overset, da vi havde travlt med at arbejde med de virkeligt aggressive ting som savklinger og eksploderende beholdere. En af de ting, vi fandt, var malingdåsen, og det var simpelt nok for os at styrke dine forventninger ved at få malingsdåserne til at sprøjte maling på zombierne, når du kastede en af dem mod dem. "
N/A4145"#commentary\cn_233_bringing_physics_to_the_enemies.mp3" "[ Tom Leonard ] Fysikfælderne i Ravenholm var nogle af de første gameplay-elementer i niveauet, som vi var rigtigt tilfredse med, men de manglede spilleragens. Det var savklingerne, der hjalp os med at finde ud af, hvad Ravenholm virkelig handlede om. Med savklingerne var spilleren i stand til at bringe fysikken til zombierne i stedet for at føre zombier til fysikken. Da vi først havde opnået den forståelse, udviklede Ravenholm sig hurtigt. Vi blev ved med at gennemsøge kortet på udkig efter noget, især noget usædvanligt, der kunne omdannes til et værktøj eller våben for spilleren. "
N/A4146"#commentary\cn_234_ravenholm_development.mp3" "[ Tom Leonard ] Vi begyndte at udvikle Ravenholm tidligt i produktionen af Half-Life 2, så det gennemgik mere end en fuld udviklingsgennemgang. Den første version gik forud for tyngdekraftpistolen, med gameplay fokuseret på traditionel zombiekamp ved hjælp af kanoner og nogle af fysikfælderne. Vi planlagde endda at fremvise Ravenholm på E3 i 2002, men spillet blev i sidste ende fremvist et år senere i 2003. På det tidspunkt havde vi investeret meget i Ravenholms kunst, noget som vi generelt undgår, indtil gameplayet er fuldt på plads. Så da vi vendte tilbage til Ravenholm med tyngdekraftsmekanikken in mente, arbejdede vi med en masse allerede eksisterende niveaugeometri, der var designet med et meget andet gameplay-mål for øje. "
N/A4147"#commentary\cn_235_grigori_plaza.mp3" "[ Steve Bond ] Denne åbne plads er et af de områder, der blev detaljeret i vores første udviklingsgennemgang, og da vi vendte tilbage til det, ønskede vi at bevare så meget af den eksisterende kunst som muligt, mens vi designede en ny spillersti, der brugte alle tre dimensioner. Flytning af spillere op og ned gennem vinduer, på tværs af hustagene, mellem bygninger. Det var ikke et stort rum, så vi måtte presse så meget ud af det som muligt. Og eftersom det startede som et kunstfokuseret område, var det sparsomt med gameplay, og vi var nødt til at gøre noget ved, at playtesterne havde tendens til at storme lige igennem det. Oven i det pressede det allerede vores budget for renderingspræstationer med meget lidt plads tilbage til noget nyt. Udfordringen blev at finde små tilføjelser for at bremse spilleren ved at tilføje trusler rundt om hjørnet og i hver en krog og sprække på niveauet."
N/A4148"#commentary\cn_236_ravenholm_development_2.mp3" "[ Tom Leonard ] Når fans taler med os om Half-Life 2, er Ravenholm ofte det mest huskede afsnit. Takket være de mange udviklingsgennemgange og tætheden af materialet i det er flere medlemmer af teamet repræsenteret i Ravenholm end noget andet sted. Det var her, vi fandt ud af, hvordan vi kunne anvende vores kunstneriske pipeline på de kulisser og stemninger, vi ønskede, hvordan fysik og gameplay kombineredes med tyngdekraftpistolen, hvordan hovedkrabber og zombier skulle udvikles til Half-Life 2 og meget mere. Når vi ser tilbage på det nu, forstærker det vores tro på individuel empowerment frem for centraliseret design. Ravenholm er tæt, yderst effektiv i sit gameplay og sin kunstneriske udførelse, og summen af mange små bidrag fra enkeltpersoner, der forstod, hvordan de kunne skubbe det lidt længere med deres egne unikke evner. "
N/A4149"#commentary\cn_237_playtester_archetypes.mp3" "[ Tom Leonard ] Iteration og regelmæssige spiltests var livsnerven i Half-Life 2's produktion. Hver uge kiggede vi stille og roligt over skulderen på en spiller, der gennemspillede det afsnit, vi arbejdede på, og noterede, hvad der fungerede, og hvad der ikke fungerede. Det var vigtigt for os at teste med en bred vifte af færdighedsniveauer for at være sikre på, at vi ikke traf beslutninger, der kun fungerede for nogle spillere. Over tid lærte vi at vælge bestemte typer spiltestere baseret på det udviklingsstadium, vi var på. Tidligt brugte vi erfarne spillere, normalt teammedlemmer, der kunne håndtere ru, ufærdige områder og var gode til at forklare deres tankeproces. Til kamptest fandt vi spillere på alle færdighedsniveauer, især dem, der er kreative i deres brug af værktøjerne. Endelig, efterhånden som sektioner blev mere polerede, fokuserede vi på begyndere – folk, der ikke spillede spil meget eller ikke var fortrolige med skydespil. Selvom de ikke nødvendigvis var nogen, der ville købe spillet, lærte vi ofte noget værdifuldt ved at følge dem. "
N/A4150"#commentary\cn_238_the_real_final_arena.mp3" "[ Tom Leonard ] Meget sent i udviklingen af Half-Life 2, da vi gennemgik hele spillet for endelige forbedringsmuligheder, besluttede vi, at vi faktisk ønskede en rigtig finale til Ravenholm. Kampen på taget var ikke nok. Efter nogen diskussion valgte vi at tilføje denne sidste kamp gennem kirkegården med Gregori ved spillerens side. Det var risikabelt udviklingsmæssigt, men vi følte, at spillet havde brug for det. Da vi var tæt på slutningen af produktionen, havde vi et modent sæt gameplay-værktøjer at arbejde med, men vigtigere endnu forstod vi på dette tidspunkt vores eget spil. At lave et spil er ofte en proces med at lære, hvad det er, du rent faktisk skaber. Hvorfor er vores spil sjovt? Hvordan er det anderledes? Hvad er de vigtigste elementer? Da vi byggede spillet og så spilletestere gennemspille det, fik vi svar på disse spørgsmål og blev til gengæld bedre til at lave det. Så kirkegården faldt hurtigt på plads og krævede langt mindre iteration end mange tidligere områder af spillet. "
N/A4151"#commentary\cn_239_cities.mp3" "[ Eric Kirchmer ] En af de sværere udfordringer i dette afsnit var at finde ud af, hvordan man giver spilleren følelsen af at være i en vidstrakt by, når vores præstationsbudgetter ikke ville tillade os at gengive noget, der mindede derom. Dette førte os til at fokusere på tætpakkede lejligheder, underjordiske garager, metrotunneler, gennemløbsrør og lignende. Det er alle steder, der er i byer, men generelt forhindrer, at man kan se horisonten. Vi supplerede derefter den stil med niveaudesign med udsigtsplaceringer, hvor hele rummet er dedikeret til at give en ekspansiv udsigt til spilleren. I dem kunne vi afsætte hele vores præstationsbudget til udsigten og ikke skulle gemme noget af det til fjendens AI eller kamp."
N/A4152"#commentary\cn_240_strider_4.mp3" "[ Eric Smith ] Selvom dette kort var produktionskortet bygget til Strideren, havde vi stadig et originalt udviklingskort til test af dets AI. Vi har altid fundet en masse værdi i at have et solidt testkort til en AI, da det giver os mulighed for hurtigt at prøve nye gameplay-ideer og nemt justere på dem. Hvis der er fejl eller designproblemer, kan vi isolere og iterere på dem hurtigere. Når AI-funktionerne fungerer godt, transplanterer vi dem i produktionskortene, som niveaudesignerne kan arbejde med. Striderens testkort omfattede grove konturer af ødelagte bygninger med uendelige borgerspawnere på forskellige steder og højder for at give en konstant strøm af mål. Denne opsætning gjorde det muligt for os at forfine Striderens AI og holdningsændringer for at gøre det interessant og engagerende, også selv om det bare er for at læne sig tilbage og se den i aktion."
N/A4153"#commentary\cn_241_perf_arena.mp3" "[ Aaron Seeler ] Denne arena kom med en stor udfordring: præstation. Dens størrelse og den kombinerede strider- og borger-AI skubbede til vores grænser her. Da vi porterede Half-Life 2 til Xbox, kunne denne arena ikke leveres uden visse designjusteringer. Det var en vanskelig balance at bevare den oprindelige hensigt og levere den samme spilleroplevelse med færre værktøjer og mindre plads."
N/A4154"#commentary\cn_242_space_re-use.mp3" "[ Chris Green ] At vende tilbage til dette rum bragte flere fordele. Først den åbenlyse — produktionsomkostningerne for nye områder er altid høje, så hvis vi kan tilføje mere gameplay til et eksisterende område, er det en gevinst. Men for en hård kamp som denne, hvor spilleren står over for flere striders, har genbrug ekstra fordele. Da spillerne har været igennem det før, har de allerede en fornemmelse af arenaens layout. Denne gang bevæger de sig i modsat retning, men stien følger stort set deres oprindelige rute. Denne fortrolighed er nyttig, når spillerne har brug for at komme videre for at få fat i ressourcer til kampen. City 17s krigshærgede tilstand gav os også fleksibiliteten til at justere dækninger og tilføje mindre forhindringer langs ruten, der gjorde miljøet dynamisk og overraskende."
N/A4155"#commentary\cn_243_tenements_and_courtyards.mp3" "[ Danika Rogers ] Vi brugte en masse små tricks og byggede forskellige funktioner for at give spillerne indtryk af en by i krig med meget af arbejdet rettet mod at give glimt af træfninger eller lyden af fjerne kampe. Looktargeting hjalp med at få noget til at ske, hver gang spilleren kiggede gennem et vindue, mens værktøjer som Tracer Makers tillod designere at skabe falsk tracer-ild mellem to punkter. Parret med lydværktøjer fik dette det til at virke som om, to grupper af fjender udvekslede ild uden behov for at køre nogen AI. Vi udviklede også små historier til grupper af borgere, som spilleren ville se flere gange, mens han bevægede sig gennem niveauet. Alle disse øjeblikke blev finjusteret gennem playtests for at sikre, at så mange spillere som muligt ville opleve dem."
N/A4156"#commentary\cn_244_hopper_mine_training.mp3" "[ Dario Casali ] Dette bølgede metalpanel blev bevidst placeret over hullet for at tilskynde spillerne til at skifte til tyngdekraftspistolen og fjerne forhindringen. Det er lidt manipulation fra vores side, fordi vi fandt ud af, at træning af spillerne på hopperminer fungerede meget bedre, hvis de straks prøvede at bruge tyngdekraftspistolen på dem, og metalpanelet øgede chancen markant for, at de ville have den klar. Vi placerede flere miner i hullet, så spillerne ville have flere muligheder for at interagere med dem, og det øgede chancerne for, at de ville finde alternative måder at bortskaffe dem på. Desuden er det første gang, vi træner, mens spilleren har en hel gruppe borgere med sig, så vi benyttede lejligheden til også at inkludere nogle dialoglinjer vedrørende hopperminerne."
N/A4157"#commentary\cn_245_dog_combat.mp3" "[ Eric Kirchmer ] Dog er en rigtig sjov karakter, og vi ledte altid efter måder at inkludere ham i kamp sammen med spilleren. Men at få den rigtige kampskala for ham – hvilket betyder et passende miljø, ny fjendtlig AI og potentielt endda nye fjender – faldt hurtigt uden for projektets omfang. For at skabe et kampscenarie, der ydede Dog retfærdighed og kunne stå op mod resten af spillet, føltes det næsten som om, at vi måtte bygge et nyt spil inde i spillet. Vi vidste, at han ikke bare kunne løbe hen til en soldat og slå på tæven – han ville føles mindre imponerende uden nogen følelse af ærefrygt. Han havde brug for større trusler for at matche hans skala, sammen med interessante måder at interagere med dem på. Til sidst valgte vi at skabe en stor koreograferet scene, der leverede de filmiske mål for Dog i kamp uden at inkorporere omfattende gameplay-design."
N/A4158"#commentary\cn_246_strider_2.mp3" "[ Eric Kirchmer ] Iterering på strideren her gav os endelig en oplevelse, vi var tilfredse med, da spillerne havde brug for at springe fra dækning til dækning og undgå dens skud, mens de jagtede efter raketter. Vi ønskede, at spillerne skulle føle, at de kastede sig i dækning i sidste øjeblik, så vi indstillede striderens hakkende skydemønster til at telegrafere forestående fare. Vi byggede også et system af spor, som strideren kunne følge, så den dynamisk kunne skifte mellem dem for at forfølge spilleren eller etablere sigtelinjer. Denne opsætning gjorde det muligt for niveaudesignere at justere strider-sporene omhyggeligt med spillerens dækning for en afbalanceret oplevelse. Striderens benpositionering blev udelukkende drevet af kode, og dens uforudsigelige bevægelser betød, at vi ofte var nødt til at finjustere tingene for at sikre, at den pålideligt sparkede til en bil eller troppecontainer, når det var nødvendigt."
N/A4159"#commentary\cn_247_manhack_tunnels.mp3" "[ Eric Smith ] Da vi udviklede AI-adfærden for en NPC, fandt vi, at det var nyttigt for AI-programmøren at have et testkort, hvor han kunne eksperimentere. Dette kort udvikledes ofte til et miljø, der er specielt designet til at vise NPC's unikke evner. Senere, da AI'en var klar til brug for niveaudesignerne, fungerede testkortet som et værdifuldt referencepunkt – uden det kunne designere ved et uheld bygge scenarier, der gjorde en ellers interessant AI mindre engagerende. I nogle tilfælde var vi i stand til at indarbejde disse testkort direkte i spillet. Denne lille sektion startede for eksempel som tunnelerne, der blev brugt til at udvikle manhackens AI."
N/A4160"#commentary\cn_248_sniper_streets_2.mp3" "[ Erik Johnson ] Kugler i Half-Life 2 følger faktisk ikke en flyvevej – de ankommer til deres mål med det samme. Men for snigskytten, med sin langsomme skudhastighed og spillerens tætte opmærksomhed på hvert skud, ønskede vi at simulere kuglens bevægelse. Denne tilgang fungerede også bedre med lasersigtet, hvor sigtet glider af, og kuglen lander kort efter, afhængigt af afstanden til snigskytten. Denne ændring introducerede imidlertid et nyt problem: Vi ønskede ikke, at spillerne bare skulle spurte ned ad gaden for at undgå skud, så snigskytteren måtte spore et bevægeligt mål og forudsige, hvor kuglen skulle ramme. Det var vanskeligt at forudsige spillerens fremtidige position, da spilleren kan ændre retning meget hurtigere, end det ville være muligt i den virkelige verden. Så vi tilføjede ekstra kontroller for at fange adfærd såsom spillere, der hurtigt trykker til venstre og højre, mens de løb."
N/A4161"#commentary\cn_249_triangle_plaza.mp3" "[ Ido Magal ] Denne plazakamp var en kompleks opsætning, der benyttede angrebsadfærden med to konvergerende kamplinjer, en for hvert kraftfelt. Når soldaterne kommer ind bag markerne, forhindrer deres kamplinjer dem i individuelt at storme ind på pladsen. Efterhånden som kampen eskalerer, og soldaterne hober sig op, begynder kamplinjerne at bevæge sig mod midten af pladsen, hvilket får soldaterne til at overvælde spilleren, hvis de ikke bliver stødt tilbage."
N/A4162"#commentary\cn_250_sniper_streets_3.mp3" "[ Jakob Jungels ] En funktion, vi prøvede i disse gader, var undertrykkelsesbeskydning. Mange spillere, der lå og trykkede sig i enden af gaden, ville affyre en salve mod snigskyttens vindue for at se, om det havde nogen effekt. Så vi eksperimenterede med at få lasersigtet til at flimre kort, hvilket gav spillerne et øjeblik til at flytte sig. Men efter en række playtests stødte vi på to problemer: For det første forstyrrede det det spændte, ryk-i-skjul gameplay, som vi havde som mål at skabe med snigskytten. Sprint under skud var ikke meget forskellig fra andre handlinger, vi beder spilleren om at udføre i City 17. Det andet, mere subtile problem var, at spillerne, der opdagede undertrykkelsesbeskydningen, først antog, at det var nødvendigt og ville bruge deres ammunition hurtigt. Hvis de løb tør halvvejs igennem, ville de ofte give op og tro, at de havde fejlet; hvis de klarede det, ville de ofte stå tilbage uden ammunition. På den anden side brugte spillere, der gennemførte scenariet ved at snige sig, næsten ingen ammunition overhovedet. Denne ressourceforskel mellem tilgangene gjorde det næsten umuligt at afbalancere ammunition til de sektioner, der fulgte, så det kom ikke med i det endelige spil."
N/A4163"#commentary\cn_251_assault_behavior.mp3" "[ John Cook ] Den mest komplekse opførsel, vi byggede til Half-Life 2, var angrebsadfærden, som bruges i hele denne sektion af spillet. Det gjorde det muligt for niveaudesignere at oprette kampscenarier med Combine-soldater og borgere, etablere kamplinjer mellem dem og kontrollere, hvordan disse kampe udspillede sig baseret på spillerens handlinger. NPC'er involveret i et angreb ville forsøge at finde smarte skydepositioner og bruge dækning baseret på kamplinjens placering. Mens spilleren avancerede ned ad en gade, kunne de rykke kamplinjen fremad, hvilket fik allierede borgere til at rykke frem, mens fjendtlige soldater faldt tilbage. Alternativt kan spilleren være nødt til at vælte nogle Combine-tårne eller slå en soldat ud bag en barrikade for at flytte kamplinjen fremad."
N/A4164"#commentary\cn_252_bank_roof_mortar.mp3" "[ John Morello ] Da vi havde bygget niveaubanen op til dette punkt, var det indlysende, at det ville være sjovt for spilleren at komme til at bruge morteren. Det er muligvis noget, der burde være faldet os ind tidligere. \"Tror du, at nogen kunne have lyst til at affyre sprængstoffer op i luften og få dem til at regne ned over skurkene? Ja, det tror jeg også\". Nå – spillerne har været i den modtagende ende i så lang tid, så det ville have været en dejlig belønning at kunne give Combine en smag af deres egen medicin. Men så snart vi begyndte at tænke over det, indså vi, hvor meget arbejde der ville være – hvilket, for at være fair, er en tanke, man har hver eneste dag, når man går i gang med at lave et computerspil. Morteren skulle nu bruge animationer og effekter, hvor spilleren står ved siden af den, og der ville være en hel del arbejde for at implementere en dejlig eskalering af fjenderne nede på pladsen til at bruge den på. Men endnu mere grundlæggende havde vi ingen grænseflade til et våben, der var så unikt. Hvordan ville spillerne sigte med og affyre det? Det er ikke nemt at have det godt med at bruge masser af tid på et enkelt øjeblik i spillet, så vi besluttede, at vores indsats var bedre brugt andre steder, og gik videre. Undskyld! Måske løser vi morterens designgåde i en fremtidig del af Half-Life-serien."
N/A4165"#commentary\cn_253_strider.mp3" "[ Kerry Davis ] Dette område foran banken var stedet, hvor vi regnede strideren ud. Da vi først så konceptkunsten til den, vidste vi, at vi ville have den med i spillet, men der var masser af spørgsmål om, hvordan det praktisk ville fungere. Vi havde aldrig flyttet noget af den størrelse gennem vores spilverden, og i den skala skulle det være farligt, men hvordan ville spillerne faktisk bekæmpe den? Som med alle vores fjender var der altid et spørgsmål om, hvordan vi ville få gameplay ud af det. Hvilken slags værktøjer ville niveaudesignerne have brug for for at bygge scenarier med det? Det var den slags spørgsmål, vi forsøgte at finde svar på i vores eksperimenter på dette kort."
N/A4166"#commentary\cn_254_sniper_streets.mp3" "[ Eric Kirchmer ] Disse snigskyttefyldte gader var stedet, hvor vi udviklede både fjenden og kernen i den oplevelse, vi håbede spillerne ville få. Vi vidste, at vi ville have snigskytten til at skyde på ting i nærheden af spilleren, så vi fokuserede først på at finde en række interessante mål, som de kunne ramme. Vi fandt ud af, at det fungerede godt, hvis vi brugte spillerens syn som en faktor ved valg af objekter. Snigskyttens altid tændte lasersigte betød, at spillerne havde en konstant indikator for snigskyttens opmærksomhed, så det at få det til at glide til et mål, som spilleren kiggede på, føltes virkelig responsivt og gav intense øjeblikke."
N/A4167"#commentary\cn_255_citizen_squad_details.mp3" "[ Matt Wright ] Da vi havde etableret borgerspillerholdet og begyndt at bygge scenarier omkring det, fandt vi ud af, at det skabte andre interessante muligheder. Spilletestere begyndte at bekymre sig om specifikke holdmedlemmer, så vi tilføjede mere til deres design. Holdmedlemmerne ville samle bedre våben op, hvis de fandt dem, give ammunition til spilleren, når det var nødvendigt, og feltlæger ville helbrede spilleren efter behov. Vi var også nødt til at sikre, at holdet kunne følge med en spiller, der ofte tog uforudsigelige ruter. Uden for kameraet ville holdet 'snyde' på forskellige måder – regenerere liv mellem kampe, bevæge sig hurtigt for at indhente spilleren og endda teleportere, når det var nødvendigt."
N/A4168"#commentary\cn_256_citizen_squads.mp3" "[ Ken Birdwell ] Vores tidlige test med gadekampe mellem Combine og borgerne afslørede et problem: Uden grænser kunne kamp-AI bevæge sig betydeligt væk fra spilleren. Soldaterne ville trække sig tilbage for at lade deres våben eller finde dækning, og borgernes AI ville følge efter. Vi havde brug for en måde at knytte borgernes handlinger med spillerens mål, holde dem opmærksomme på, hvor spilleren var på vej hen, og hvilke fjender spilleren ønskede at angribe. Dette førte til oprettelsen af et borgerspillerhold. Borger-AI brugte dette hold til at bevæge sig med spilleren, engagere de samme fjender og give en grundlæggende grænseflade til spillerens kommandoer. Vi havde oprindeligt et mere komplekst kommandosystem, men det blev hurtigt uhåndterligt, så vi skalerede det tilbage."
N/A4169"#commentary\cn_257_ai_behaviors.mp3" "[ Mike Dussault ] Et stykke AI-teknologi, vi udviklede til Half-Life 2, var adfærdssystemet. Adfærd var bidder af AI-gameplay-kode, der guidede NPC'er i specifikke situationer. For eksempel havde vi en guide-adfærd, der gjorde det muligt for en NPC at guide spilleren, og en følg-adfærd, der gjorde det muligt for en NPC at følge spilleren eller en anden NPC. Adfærd fungerede sammen med NPC'ens basishandlinger, så en holdkammerat, der var feltlæge, som bruger følg-adfærden for at holde trit med spilleren, ville stadig vide, hvordan man skyder mod fjender, undviger granater, eller tilbyder en førstehjælpspakke."
N/A4170"#commentary\cn_258_occlusion.mp3" "[ Brian Jacobson ] I Half-Life 1 og meget af Half-Life 2 bestod verden hovedsageligt af lukkede tunneler og korridorer, som fungerede godt med et Binary Space Partition eller BSP-træ. I hovedtræk tillod denne teknologi os hurtigt at sortere gennem geometrien og bestemme, hvad der kunne være synligt i spillerens syn. Men de åbne områder i Coast-regionen og andre udendørs sektioner passede ikke til den tilgang, så vi havde brug for ny teknologi. Områdeportaler var en teknologi, der gjorde det muligt for os at skære verden op i diskrete bidder adskilt af portaler – altså døre og vinduer, ikke Aperture Science-portaler. Vi udviklede også et ekstra okklusionssystem, der grundlæggende sagde 'hvis spilleren ikke kan se igennem, over eller omkring et stort objekt, skal du ikke gengive det, der er på den anden side.' Dette kan virke som en indlysende ting ikke at gøre, men det kræver noget arbejde at sikre, at beregning af, hvad der er på den anden side af den store ting, ikke er langsommere end bare at gengive alt. Så for at gøre denne beregning hurtig placerede niveaudesignere store okklusionsvolumener inde i store terrænformer og store okkluderende objekter som bygninger, og under rendering kunne vi derefter teste enhedernes grænser mod disse volumener for at undgå at gengive noget, som spilleren ikke kunne se."
N/A4171"#commentary\cn_259_detail_objects.mp3" "[ Brian Jacobson ] Da vi fik de udendørs sektioner op at køre, var det klart, at de havde brug for en form for højfrekvente detaljer, så vi tilføjede små løvelementer, som græs og buske, på tværs af forskydningsterrænet. Men vi vidste, at vi ikke havde råd – hvilket vil sige, vi ikke havde tid – til at placere dem alle manuelt. Så vi byggede detaljeobjektsystemet, som automatisk genererer små løvelementer baseret på forskydningsmaterialet. Hvert materiale specificerer den type løv, der skal placeres, sammen med et sæt parametre. Ved kortkompileringstidspunktet beregner systemet tilfældige punkter på overfladen og vælger løv, der skal placeres der. I betragtning af ydeevnebegrænsninger var der stadig en ret kompleks hånddrevet proces for løvteksturark, så vi kunne gengive dem alle i en enkelt gennemgang."
N/A4172"#commentary\cn_260_displacements_1.mp3" "[ Charlie Brown ] Efter Half-Life 1 blev udgivet, ønskede vores niveaudesignere og kunstnere en bedre løsning til udendørs miljøer, så vi byggede den første version af vores terrænsystem. Det var baseret på underopdelte quads. For at visualisere dette skal du forestille dig en flad firkant opdelt i et gitter, hvor hvert punkt på gitteret kan flyttes op eller ned. Niveaudesignere kunne lægge flere firkanter ud og derefter bruge et penselværktøj til at forme bakker og dale ved at justere gitterpunkterne. Til gengivelse brugte vi en speciel blandet tekstur, der kombinerede to forskellige teksturer. Hvert gitterpunkt specificerede, hvor meget af hver tekstur der skulle bruges, hvilket muliggør glatte overgange mellem overflader som sand, græs, snavs og grus. Denne type terrænsystem var ikke usædvanlig i spilmotorer på det tidspunkt, og vi troede naivt, at det ville være nok for vores spildesignere."
N/A4173"#commentary\cn_261_displacements_2.mp3" "[ Charlie Brown ] Da det indledende terrænsystem var i gang, forventede vi, at niveaudesignere ville bruge det til udendørs rum. I stedet begyndte de at eksperimentere og tilføje detaljer på uventede steder. De brugte de opdelte firkanter oven på væggene til at skabe ødelagte kanter, afrundede gadekanter og forsøgte endda at lave rør. Dette havde varierende succes, da terrænsystemet var designet til landskaber, ikke arkitektoniske detaljer. Så vi vendte tilbage til kodeminerne og omdannede det højdebaserede terrænsystem til et fuldt 3D-forskydningssystem. Nu kunne designere flytte dem i enhver retning i stedet for kun at flytte gitterpunkterne op eller ned. Dette gjorde det muligt for dem at tilføje ekstra detaljer til alle slags overflader ved hjælp af blandede teksturer til at glatte overgange mellem forskydningsquads og BSP-geometrien. Dette krævede dog yderligere teknisk arbejde for at sikre ensartet belysning mellem de to renderere, ellers ville disse kanter have været mærkbart uoverensstemmende. Men da alt dette var gjort, virkede niveaudesignerne tilfredse, og vi troede naivt, at det denne gang virkelig ville være nok."
N/A4174"#commentary\cn_262_displacements_3.mp3" "[ Charlie Brown ] Med det generelle forskydningssystem i hånden stoppede niveaudesignere ikke med at tilføje detaljer til verden, men vendte tilbage til deres oprindelige mål om at bygge store udendørs sektioner. Dette førte til endnu en runde opdateringer for at afbalancere ydeevnen, hvilket sikrede, at systemet kunne håndtere både fine detaljer og større terræn på jorden. Teksturering måtte også forbedres, især for at understøtte komplekse strukturer som overhængende klipper, der ikke var mulige med det originale højdebaserede system. Designerne, der aldrig hvilede på laurbærene, begyndte også at bruge forskydninger til at skabe huler og tunneler. Mens disse tilføjelser så godt ud, krævede de endnu mere teknisk justering. Til sidst lykkedes det os at imødegå de konkurrerende krav til alle de måder, hvorpå forskydninger blev brugt, og de blev inkluderet i store dele af vores spilverden. Når man ser tilbage, er forskydninger et klart eksempel på, hvordan teknologi og spildesign udvikler sig sammen. Det er et kyllingen og ægget-problem – vi kan ikke forudse alle de måder, et stykke teknologi vil påvirke spillet på, men vi kan heller ikke bygge teknologien uden at vide, hvad den skal opnå. Så som det altid er tilfældet, er vi nødt til at bygge noget. Vi starter med et solidt gæt og ser, hvor det fører os hen."
N/A4175"#commentary\cn_263_particles.mp3" "[ Chris Green ] Til Source-motoren investerede vi i at udvide partikel- og specialeffektteknologi. Dette muliggjorde mere realistisk og kompleks partikelbevægelse samt mere indviklede former og skyggeeffekter. Især tilføjelsen af bumpmapping til vores partikelfunktioner gjorde en enorm forskel i det volumetriske udseende af dem. Mens senere iterationer af Source-motoren omfattede en kraftfuld partikelsystemeditor, var den originale version, der blev brugt i Half-Life 2, afhængig af håndlavede effekter – hver krævede, at en programmør omhyggeligt byggede effekten manuelt, hvilket var en temmelig arbejdskrævende proces."
N/A4176"#commentary\cn_264_cubemaps.mp3" "[ Chris Green ] Med tilføjelsen af materialer og shaders havde vi brug for en løsning til reflekterende overflader som glas og stål. Disse overflader skulle vide, hvad de skulle reflektere, men i 2003 kunne vi ikke udføre den slags gengivelse i realtid. Så vi udviklede cubemap-systemet til forudberegnede refleksioner. Et cubemap er et sæt af seks billeder på indersiden af en terning, der fanger miljøet i alle retninger – som et panoramabillede, der omgiver dig på alle sider. Niveaudesignere placerede usynlige markørenheder over hele niveauerne, og under kortkompilering genererede vi et cubemap ved hver markør. Da vi derefter gengav en reflekterende overflade i spillet, kunne vi finde det nærmeste forudberegnede cubemap for at skabe refleksionen."
N/A4177"#commentary\cn_265_water_shader.mp3" "[ Gary McTaggart ] Den mest komplekse shader, vi lavede til spillet, var vandshaderen, som gjorde fuld brug af de nyligt tilgængelige programmerbare grafikkort. Når der var vand til stede, blev scenen gengivet tre gange: for det første undervandsverdenen til brydning; for det andet et reflekteret lag; og for det tredje delene over vandet. Ved gengivelse af vandoverfladen blandede vi brydnings- og reflekterende visninger og viste mere refleksion i blikvinkler ved hjælp af Fresnel-ligningen. Vi sporede også jorddybden under vandoverfladen og gjorde den mere gennemsigtig og mindre brydningsbar i lavvandede områder. Derudover var vi nødt til at oprette to alternative vandgengivelsesteknikker til grafikkort i den lavere ende: mellemklassekort viste en refleksion med lavere detaljer uden brydning eller gennemsigtighed, mens low-end-kort kun gengav en delvist gennemsigtig overflade."
N/A4178"#commentary\cn_266_normal_maps.mp3" "[ Gary McTaggart ] Half-Life 2 blev udviklet i en spændende tid for grafik, da de første programmerbare shader-understøttede grafikkort kom på markedet. Ved hjælp af denne teknologi blev vi et af de første spil til at implementere normale kort, en teknik, der forbedrede belysningen på overfladegeometri. Det normale kort beskrev overfladens ruhed, hvilket gjorde det muligt for hver pixel i en polygon at blive oplyst på en måde, der fik overflader til at se mere bumpede og mere detaljerede ud, end det nogensinde var muligt i Half-Life 1."
N/A4179"#commentary\cn_267_rendering_systems.mp3" "[ Gary McTaggart ] I begyndelsen af 2000'erne havde vi ikke råd til en general-purpose renderer med en moderne motors brede muligheder. I stedet krævede CPU-, GPU- og hukommelsesbegrænsninger meget specifikke løsninger til gengivelsesudfordringer, så vi kunne presse hver eneste bit af ydeevne ud af spillernes hardware. Som et resultat heraf har Half-Life 2 faktisk tre forskellige gengivelsesmotorer: en til verdensgeometri, en anden til udendørs terræn og en tredje til dynamiske enheder som karakterer og objekter. Disse tre renderere måtte understøtte en kompliceret matrix af funktioner – kollisioner, strålespor, dekaler, offline belysning, synlighedsberegninger og mere. Derudover skulle hver renderer understøtte DirectX 7, 8 og 9. Forskellene mellem disse DirectX-versioner var betydelige og krævede ofte forskellige datalagrings- og gengivelsestilgange; de brugte endda forskellige programmeringssprog! Alt i alt havde vi i princippet ni forskellige renderere, der hver havde brug for unikke løsninger, og at få dem alle til at se konsistente ud var et af de mest udfordrende tekniske problemer, vi stod over for under udviklingen."
N/A4180"#commentary\cn_268_dynamic_shadows.mp3" "[ Gary McTaggart ] Med fokus på karakterer og fysikobjekter følte vi, at et dynamisk skyggesystem var nødvendigt for at gengive dem i al deres herlighed. I 2003 havde GPU'er ikke nogen af de dedikerede skyggefunktioner, som de har i dag, så ydeevne var et vanskeligt problem. Vores endelige løsning fungerede omtrent således, hvor hver frame blev kørt. Find først alle de objekter, der kan have skygger i synsfeltet. For at gøre det, skulle vi finde ud af, hvilke objekter der var i synsfeltets keglestub, eller lidt bag den, for at fange entiteter, der var uden for skærmen, men hvis skygge kunne ende på skærmen. Derefter gengiver vi en sort skyggeversion af hvert af disse objekter til en enkelt skyggetekstur. Til den gengivelse brugte vi den laveste detaljeringsmodel for objektet for at gøre det så hurtigt som muligt. Endelig brugte vi skyggeteksturen til at tegne hver af skyggerne ind i spillerens synsfelt og gøre de allerede gengivne pixels mørkere. Vi skar omhyggeligt rundt om hver skygge i den skyggetekstur for at sikre, at de korrekt lå over hinanden i tilfælde, hvor flere skygger overlappede hinanden. Det er fedt at se tilbage på, hvordan vi gjorde disse ting, men i sidste ende er vi meget gladere i dag, hvor GPU-hardware gør det til et meget mere ligetil problem."
N/A4181"#commentary\cn_269_combinatorial_shader_explosion.mp3" "[ Gary McTaggart ] Rendering blev meget mere kompleks under Half-Life 2's udvikling med tilføjelsen af hardware shaders – små stykker kode, der styrer, hvordan hver pixel på en overflade skal gengives. I 2003 var shaders langt mere begrænsede end i dag: Half-Life 2-æraens shaders manglede betingelser og havde alvorlige kodestørrelsesbegrænsninger. Dette betød ingen if/else-forgreningslogik til at justere baseret på forskellige forhold, og ingen store shaders med brede funktionssæt. Desuden var kompilering af shaders efter behov for langsom til at være nyttig, så vi var nødt til at forkompilere dem. For at kunne arbejde inden for disse grænser var vi nødt til at beregne alle mulige shader-kombinationer og gemme hver enkelt individuelt som sin egen shader. Hvis en shader for eksempel påvirkede en overflade baseret på en enkelt lyskilde, havde vi brug for en anden shader-version til to lys, en tredje til tre osv. Og det var kombinatorisk – hvis skyggen også understøttede et normalt kort, ville vi have brug for to versioner pr. lys, en med det normale kort og en uden. Med funktioner som teksturblanding, toppunktfarvning, spejlede højdepunkter, alfatest og forskellige andre lystyper, retningsbestemt lys, punktlys, spotlights, eksploderede vores antal shaders. Ved udgivelsen havde vi tusindvis af individuelle shaders. Kort efter frigav vi Lost Coast og tilføjede HDR-understøttelse, hvilket fordoblede antallet af shaders igen. Da kompilering af shaders på de lokale udviklermaskiner begyndte at tage for lang tid, skiftede vi til at distribuere shader-kompileringerne over hele netværket ved hjælp af VMPi. Vi havde også en dynamisk shader-kompileringstilstand, der var nyttig til udvikling af shaders, der gav hurtig vending behandlingstid på bekostning af frame rate-hitching, når en shader skulle kompileres."
N/A4182"#commentary\cn_270_gpu_wild_west.mp3" "[ Jay Stelly ] Under udviklingen stod vi over for adskillige beslutninger påvirket af vores valg af minimumsspecifikation – den mindst kraftfulde CPU- og GPU-kombination, der stadig ville levere en god oplevelse for kunderne. I begyndelsen af 2000'erne var der langt mere variation blandt GPU'er end i dag med store forskelle ikke kun i hastighed, men i grundlæggende tilgange til rendering. Men på det tidspunkt havde vi ingen reelle data om den hardware, vores kunder brugte. Hvilke CPU'er og GPU'er havde de? Hvor meget RAM? Hvilken version af Windows? Vi rakte ud til Microsoft i håb om, at de måske kendte svarene på spørgsmål som, 'Hvor mange DX7-kort er i brug? Eller DX8? ' Desværre havde de heller ikke dataene. Da vi indså, at vi risikerede at træffe dårlige beslutninger uden denne indsigt, udviklede vi et analyseværktøj, der gjorde det muligt for spillere at rapportere deres hardwarespecifikationer til os og integrerede det i den tidlige version af Steam. Disse data var så nyttige, at vi besluttede at offentliggøre dem ved at lancere Steam Hardware Survey i april 2003. Det har hjulpet os – og forhåbentlig andre udviklere – med at træffe informerede beslutninger lige siden."
N/A4183"#commentary\cn_271_3d_skybox.mp3" "[ Jay Stelly ] Vi har altid haft brug for at gengive en verden, der føles større, end vores kortbegrænsninger tillader. I Half-Life 1 brugte vi en kubekortstruktur for at lade spillerne se ud over det spilbare område. Men i Half-Life 2 ønskede vi, at udsigten til den større verden skulle være dynamisk og ikke kun en statisk struktur. Vores kortstørrelsesbegrænsning var omkring en halv kilometer i hver dimension, men vi indså, at vi kunne skabe en meget større ydre verden, hvis vi lagrede den i reduceret skala. Så vi opfandt det, vi kaldte 3D Skybox. 3D Skybox er en lille kasse skjult i selve spilkortet, der indeholder geometri i 1/16 skala. Inde i det svarer et referencepunkt til en matchende oprindelse på hovedkortet. Når vi derefter gengiver rummet ud over det spilbare område, bruger vi geometrien fra 3D Skybox, placeret ved dette referencepunkt og skaleret op 16 gange. At få belysningen og tågen til at blande sig problemfrit på tværs af overgangen fra hovedkortet til skyboxen gav nogle gevaldige udfordringer, men det fungerede. Resultatet fik verden til at føle sig markant større og mere fordybende, end den havde gjort i Half-Life 1."
N/A4184"#commentary\cn_272_missing_material.mp3" "[ Jay Stelly ] Tidligt i udviklingen af vores low level grafikkode indså vi, at det ville være svært at få øje på polygoner, der ikke gengives på grund af en manglende tekstur. Når dette skete, ville du typisk bare se sort, hvor polygonen skulle være, hvilket let kunne gå ubemærket hen i mørkere scener. For at fange denne fejl mere pålideligt oprettede vi en fejltekstur, der ville være visuelt umiskendelig og genereres automatisk, når en tekstur ikke kunne indlæses. Dette gav anledning til den nu ikoniske lilla og sorte skakbrætstruktur, som siden har fået sit eget liv langt ud over Half-Life 2."
N/A4185"#commentary\cn_273_air_resistance.mp3" "[ Jay Stelly ] En vigtig funktion, vi var nødt til at tilføje til vores fysikmotor til Half-Life 2, var luftmodstand. På det tidspunkt ville fysikmotorer typisk implementere en generel dæmpningsfunktion til at bremse objekter, når de bevægede sig. Men dette fjerner blot energi på en symmetrisk måde. For at skabe mere troværdig bevægelse besluttede vi at simulere luftmodstand i stedet. Dette gjorde det muligt for os at få asymmetrisk opførsel, hvor mængden, objektet blev bremset med, når den bevægede sig gennem luft, var forskellig afhængigt af, hvor meget overfladeareal af objektet vendte i bevægelses- eller rotationsretningen. Denne funktion var nøglen til at få eksplosioner og genstande kastet af tyngdekraftspistolen til at se troværdige ud. Hurtigt bevægelige og hurtigt roterende objekter er blandt de dyreste ting at simulere i Half-Life 2s fysikmotor, så luftmodstand forbedrer også CPU-ydelsen i tilfælde som eksplosioner. Det er også nøglen til at præsentere forskellige materialer og masser af objekter. Mere tætte genstande kan lettere skubbe luft til side, og dette er synligt. At have denne effekt i simuleringen hjælper med at gøre forskellen i tæthed mellem papkasser og træplanker mere tydelig og hjælper virkelig med at gøre objekterne i Half-Life 2s verden meget mere overbevisende."
N/A4186"#commentary\cn_274_early_tech_planning.mp3" "[ Ken Birdwell ] Udgivelsen af et spil lærer os altid meget – vi finder endelig ud af, hvilke af de valg, vi tog, var gode, og hvad vi skulle gøre anderledes næste gang. Så da vi satte os ned efter Half-Life 1 for at begynde at tænke over, hvilken slags efterfølger vi kunne bygge, havde vi alle mulige spillerfeedback at fordøje. Ud fra det forsøgte vi at opbygge en masterliste over ting, som Half-Life 2 skulle fokusere på. Vi forsøgte ikke at designe en bestemt spilleroplevelse, i stedet fandt vi det mere nyttigt at nærme os spørgsmålet fra et teknologisk synspunkt. Black Mesas sikkerhedsvagter og forskere havde fungeret godt. Hvad kunne vi gøre, hvis vi pressede virkelig hårdt på karaktererne? Vi kunne godt lide vores interaktive historiefortælling. Hvad kunne vi bygge, der ville give os mulighed for at gøre endnu mere af det og med større variation? Udforskningen og interaktionen inden for Black Mesa var overbevisende for spillerne. Måske ville et fysiksystem give os mulighed for at tage det skridtet videre? På alle disse områder forsøgte vi at forestille os, hvordan den bedste version af det kunne se ud, år ude i fremtiden, og derefter løse et sæt teknologiske trin, der kunne få os dertil."
N/A4187"#commentary\cn_275_character_lighting.mp3" "[ Ken Birdwell ] I det første udviklingsår kæmpede vi for at få vores karakterer til at føles så realistiske, som vi ville have dem til. Der var faktisk en hel del forskellige problemer, som alle til sidst krævede specifikke teknologiske og kunstneriske forbedringer at løse. Det første store problem var belysning. På det tidspunkt brugte lysteknologi i spil mange genveje, nogle på grund af ydeevne, men mange på grund af misforståelser om, hvordan det hele fungerer. For at få karaktererne til at se godt ud på det tidspunkt, måtte der skabes modeller og teksturer med meget af deres belysningsløsning bagt ind i dem – såsom skygger og glans. Karaktererne så seje ud – men de lignede også computerspilfigurer. Vi begyndte at bygge Alyx med denne tilgang, fordi det var sådan, man skulle gøre det. Vi brugte de færdige løsninger og belyste hende som en filmskuespiller – i princippet som om hun havde en brugerdefineret belysningsrig, der fulgte hende rundt og sikrede, at hun altid så godt ud. Men det virkede ikke rigtigt. Udvalget af lysmiljøer og computerspils dynamiske karakter betød, at hun ville se godt ud i nogle miljøer, men altid ende med at se frygtelig urealistisk ud på et tidspunkt. Vi prøvede at iterere på hendes belysningsrig og øge dens muligheder, men til sidst føltes det som om vi var endt i en blindgyde. Da vi vendte tilbage til tegnebrættet, besluttede vi at prøve en anden tilgang. Vi byggede hende og belysningen og teksturerne fra bunden og smed alt andet væk. Vi fokuserede ikke på, hvordan vi ønskede, at hun skulle se ud under ideel belysning, men på hvordan tingene skulle fungere i den virkelige verden. Det kan virke indlysende, men det var ikke, sådan det blev gjort, i det mindste ikke i computerspil. Når man kiggede på dem uden for spillets render, så disse modeller og teksturer faktisk værre ud end de tidligere versioner. Men det lykkedes os metodisk at fjerne alle genveje og misforståelser om, hvordan lys og tekstur og grafikkort fungerede og sætte det hele sammen igen. Efter alt det var gjort, kunne vi endelig se på Alyx i spillet, med hendes nye modeller og teksturer, i et dynamisk miljø, der holdt hende visuelt konsistent på alle tidspunkter. Ja, hun så godt ud. Helt sømløs og som en del af Half-Life 2-verdenen."
N/A4188"#commentary\cn_276_gamma_correction.mp3" "[ John Morello ] Vores spilmotor har et rendersystem, der er ansvarlig for at tage hele tilstanden af spillet og beregne en farveværdi for hver pixel på din skærm for at repræsentere denne tilstand. Men kode og software fra andre mennesker er også involveret i processen med at beregne disse pixels. Eksempelvis softwaren og hardwaren i din GPU og skærm. På et tidspunkt under udviklingen var vi utilfredse med, hvordan vores karakterer så ud. Især mente vi, at de så voksagtige eller syge ud. Deres hud var forkert. Vi brugte lidt tid på at justere vores belysning, men vi kunne bare ikke få både vores karakterer og vores verden til at se rigtigt ud. Heldigvis havde vi stadig en fuldt udstyret softwarerenderer, som gjorde det muligt for os at køre spillet uden en GPU, fordi dette var en periode, hvor mange spillere stadig ikke havde en. Og når vi ser på spillet på den renderer, bemærkede vi, at vores belysning ikke havde det samme problem. Så vi gennemgik vores kode med en fin tættekam og forsøgte at finde ud af, hvor vores renderingkode gjorde noget forkert, når den arbejdede med en GPU. Da det ikke lykkedes os, forsøgte vi at tale med GPU-producenterne og bede dem om at dobbelttjekke, at de ikke gjorde noget galt med de pixelværdier, vi sendte dem. Det var starten på en lang rejse – og kort fortalt var det en rejse med næsten 2 års kommunikation frem og tilbage med GPU-producenter, før vi var i stand til at overbevise dem om, at de lavede gammakorrektion forkert i matematikken på lavt niveau på deres kort. I løbet af denne proces havde vi endda været nødt til at bygge et system, der validerede farveværdierne for en individuel pixel gennem hele vores gengivelsespipeline. Men til sidst fik vi endelig nye drivere tilbage fra dem, og vores karakterer så straks ud, som de skulle, og matchede softwarerenderen."
N/A4189"#commentary\cn_277_facial_technology.mp3" "[ Ken Birdwell ] Vi ønskede, at spillerne skulle bekymre sig om vores karakterer, og for at have bare en chance for at opnå det, vidste vi, at vi var nødt til at investere en masse teknologi i vores karakterers ansigter. Det er velkendt, at mennesker er programmeret til at være opmærksomme på ansigter og ubevidst læse alle slags oplysninger i dem. Så det er en ekstremt høj tærskel, og hvis vi ikke kunne nå den, ville vi sandsynligvis skubbe spillerne væk fra vores karakterer, ikke tiltrække dem til dem, som vi håbede på. Vi startede med at lave en masse research. Det var ikke opmuntrende. De bedste eksempler, vi kunne finde, var ikke i nærheden af at kunne køres i realtid, mens de bedste realtidseksempler ikke var tæt på den kvalitet, vi ønskede. Vi ønskede at få det til at se lige så godt ud som en animeret film, men de tog ofte timer om at gengive billeder og var helt lineære, skrevet af op til hundrede animatorer, hvorimod vores skulle være dynamisk – en karakter kunne forsøge at tale dialog over en ansigtsstemning, der stammer fra spillerens handlinger og skabt af kun en håndfuld kunstnere. Disse krav førte os til sidst til Dr. Paul Ekmans Facial Action Coding System, et system til taksonomisering af menneskelige ansigtsbevægelser udført tilbage i 1970'erne. Det gav os et ordforråd til at beskrive ansigtsbevægelser gennem vores værktøjer og kode og et mål at sigte efter, når vi designede vores karakterers ansigter. Med det som ramme startede vi en mangeårig proces med at iterere, hvordan vi byggede ansigter og hoveder på vores karakterer. Hvor andre havde forsøgt at tage stykker af Ekmans arbejde, ville vi prøve at bruge det hele. Det resulterede i, at vi brugte meget tid på at finde ud af, hvordan man laver hvert stykke inden for de stramme præstationsbegrænsninger, vi havde. Men vi brugte også meget tid på bare at kigge på mennesker og ansigter og forsøge at finde de ekstra træk, der ville tilføje mest værdi – som hudelasticitet og tandskygge. I sidste ende, lykkedes det os at få de dele, vi troede var de vigtigste for et overbevisende ansigtspræstationsniveau på vores karakterer, selvom vi ikke var i stand til at gøre alt, hvad vi ville."
N/A4190"#commentary\cn_278_eye_shader.mp3" "[ Ken Birdwell ] En anden kritisk del af at få karakteransigter til at være overbevisende var øjnene. Mennesker er gode til at læse øjne. Der er en del af din hjerne dedikeret til det, ned til at vide, hvor nogen ser baseret på refleksionerne på øjeæblerne. Men der er en masse slags underfundigheder, der spiller ind. Øjne er faktisk ikke kugler. Øjenlågene bliver forvrænget af hornhinden, der bevæger sig rundt nedenunder. Øjenbevægelse kan øge chancerne for at blinke. Øjnene er faktisk ikke på linje direkte bag pupillen, de forskydes lidt. Alle disse små detaljer kan føles små eller umærkelige, men fraværet skader karakterens troværdighed. Vi arbejdede på øjnene i lang tid og itererede lidt efter lidt på vores øjeæblemodel og funktionssæt. Nogle ting krævede eksterne grænseflader, såsom hvilke ting i miljøet var interessante at se på, mens andre var automatiske, på et underbevidst niveau i AI – som at blinke, et indlysende krav, men et, der er subtilt forvirrende, hvis det er forkert. Øjenrefleksioner havde en særlig stor indflydelse – de udgør egentlig en lille mængde fast ejendom på skærmen, men forskellen, de gjorde, var enorm. Vi vidste, at vi endelig var færdige, da vi nåede det punkt, hvor en karakter, med vores øjenshader slukket, lignede en dukke, menneskelignende, men ikke overbevisende på nogen måde, der var svær at beskrive – men da vi tændte den, føltes det pludselig som et menneske, der kiggede på os."
N/A4191"#commentary\cn_279_combine_gunship.mp3" "[ Ken Birdwell ] Kampfartøjet var et interessant problem. Vi havde allerede en helikopterflymodel, og havde ikke rigtig tid til at bygge noget helt nyt. Så vi ændrede lidt på helikopterens flyvemodel, indtil den føltes anderledes nok, og afledte derefter kampfartøjets organiske animationstilstand ud fra værdierne, der kom ud af denne simulering. Vi forsøgte også at holde det så sandfærdigt som muligt. For eksempel er der en grænse for, hvor meget den kan vende hovedet for at sigte med sin kanon, og hvis den har brug for at sigte ud over det, skal den ændre sin flyvevej for at få kanonen til at pege den rigtige vej – den må ikke bare snyde. Den anden nøglefunktion var dens motorlyd. Vi har lydspacialisering, så spilleren kan fortælle nogenlunde, hvor det er. Men kamfartøjet er et hurtigt bevægende objekt, og det er oppe i luften, væk fra eventuelle nærliggende referencepunkter. Derfor kan det være svært at fortælle nøjagtigt, hvor langt væk det er, og hvor hurtigt det bevæger sig. For at løse det tilføjede vi en doppler-effekt til motorlyden og skiftede tonehøjden baseret på kampfartøjets hastighed i forhold til spilleren. Det er en subtil effekt, men det er ekstremt effektivt til ubevidst at hjælpe dig med at opfatte kampfartøjets placering og retning. Det er kritiske oplysninger, der fortæller dig, at du bliver jaget af det."
N/A4192"#commentary\cn_280_risk.mp3" "[ Ken Birdwell ] Når jeg ser tilbage på Half-Life 2 nu, 20 år senere, er det nøgternt at reflektere over, hvor skræmmende det var gennem store dele af udviklingen. Spiludvikling er svær. Du får aldrig rigtig det, du gerne vil have, hvilket er at kunne validere risiko, før du begynder at smide mere på bunken. Eksempelvis vores ansigtsanimationsteknologi. Det tog sandsynligvis omkring 3 eller 4 års arbejde, før vi var sikre på, at det faktisk ville fungere. Men vi kunne ikke vente til da. I det første år begyndte vi straks at træffe alle mulige andre valg i vores spildesign, vores aktivproduktion og vores andre teknologier, alt sammen baseret på antagelsen om, at vores ansigtsanimationsteknologi i sidste ende ville fungere ud fra et kvalitets- og præstationssynspunkt. Hvis det ikke var tilfældet, ville mange af disse andre valg heller ikke have fungeret. Og den samme risikoprofil gælder for andre store valg, vi tog tidligt. Vi kan ikke vente, vi er bare nødt til at bygge, og håber, at vores gæt vil være sande om mange år fra nu. Skræmmende."
N/A4193"#commentary\cn_281_hugs_and_pickups.mp3" "[ Ken Birdwell ] Nogle gange kan selv små ting være et mareridt at få til at fungere. For eksempel kan det forårsage mange problemer at få en karakter til at kramme en anden karakter, eller endnu mere simpelt bare at hente et objekt fra et bord. Værre endnu, i vores dynamiske miljø, hvor karaktererne og objekterne ikke er i forudindstillede positioner, og spilleren løber rundt og står i vejen, kræver disse et niveau af synkronisering, der kan være ret vanskeligt. De gøres sværere, fordi mennesker håndterer dem uden at tænke. Når du bevæger dig til bordet for at hente en kop, laver du alle mulige former for forberedelser med din krop for at få dine fødder og hænder i den rigtige position, så du kan gøre det komfortabelt. Alt så det er klar, lige når du kommer derhen. Hvis du rykker ind for at kramme nogen, gør I det begge på samme tid og tilpasser jer konstant baseret på hinandens bevægelse. At få disse funktioner til at fungere i spillet involverede en masse synkroniseringsarbejde, der gjorde karaktererne opmærksomme på hinanden og verden. Og på samme tid få dem til at vide mere om deres fremtidige planer. Det er fristende at ønske at opdele saml-en-kop-op-eksemplet i diskrete trin – gå til bordet, vende mod koppen, samle koppen op – fordi det er meget enklere på den måde, og det gør trinene pænt genanvendelige. Men det er sådan robotter fungerer, ikke mennesker. Vores figurer måtte vide, at de flyttede til et bord med den hensigt at hente en kop, så de kunne arbejde på flere dele af det samtidigt og sørge for, at deres hånd griber koppen, lige når de kommer dertil. Med to karakterer er det endnu mere en forhandling. Begge er nødt til at blive enige om, hvor og hvornår det skal ske, og alt skal ske på stedet på en problemfri måde. Selvom disse øjeblikke med simpel interaktion mellem vores karakterer i verden ofte er korte, var de kritiske for at få dem til at virke som troværdige mennesker."
N/A4194"#commentary\cn_282_ropes.mp3" "[ Mike Dussault ] En af de ting, vi bemærkede i alle de referencebilleder, som vi samlede til City 17, var, at der var kabler og ledninger overalt, og at de var en stor del af de synlige, højfrekvente detaljer. Vi elskede udseendet af disse ældre, europæiske byer indlejret i det tilfældige net af det moderne liv. Vi følte, at vi havde brug for en løsning til kabler, reb og lignende elementer, og vi ønskede, at de skulle være dynamiske. Vores niveaudesignere var ivrige efter at skabe stikpuslespil, og tilslutning af en ledning til hvert stik hjalp spillerne med bedre at forstå mekanikken. Tidligt i produktionen byggede vi et rebsystem og gentog det under hele udviklingen. Under kølerhjelmen er hvert reb lavet af flere segmenter strakt mellem de to endepunkter, og de kunne bevæge sig uafhængigt. Hvert segment fungerer som en fjeder og reagerer på kræfter i spillet, såsom en mild vind eller et Combine-kampfartøj, der passerede henover. Når det bliver renderet, vises hvert segment vendt mod kameraet og er bump-kortlagt, hvilket er afgørende for at give rebene et realistisk, afrundet udseende."
N/A4195"#commentary\cn_283_vmpi.mp3" "[ Mike Dussault ] Under udviklingen blev vi mere og mere frustrerede over vores langsomme gameplay-iterationshastigheder, hovedsageligt fordi kortkompilering – nødvendig for at forudberegne belysning og synlighed – tog timer. Computere i 2000 var meget langsommere end nutidens, og de havde kun en enkelt CPU-kerne hver. Inspireret af SETI @Home, et distribueret program, der brugte pc'er over hele verden til at analysere radiobølger for tegn på udenjordisk liv, byggede vi VMPi, som var vores eget distribuerede system, der spredte kortkompileringsprocessen på tværs af mange kontorcomputere. I dag kører denne slags distribuerede systemer på gigantiske GPU-klynger, men på det tidspunkt kørte vi det bare på alle computere på vores kontor. For at håndtere, hvordan vores belysningskode udviklede sig lige så hurtigt som vores kort, distribuerede VMPi også nye .exe-filer til alles computer. Set i bakspejlet var dette et temmelig skræmmende sikkerhedskoncept, simpelthen frygteligt dårligt, et mareridt for IT-folk, fordi vi bare sendte en vilkårlig eksekverbar fil til alle vores arbejds-pc'er, og de bare kørte den. Det var absolut vanvid. Men det fungerede for os, og det øgede vores kort-iterationshastighed betydeligt. Som resultat heraf endte det med at blive et afgørende værktøj."
N/A4196"#commentary\cn_284_field_of_view.mp3" "[ Kerry Davis ] I Half-Life 1 brugte vi et 90-graders synsfelt eller FOV (\"field of view\"), som var ret standard for førstepersonsskydespil på det tidspunkt. Men under udviklingen af Half-Life 2 blev vi utilfredse med det. Med vores spils fokus på karakterer ville vi lægge en stor indsats i detaljerede ansigts- og kropsanimationer, men 90-graders FOV tillod bare ikke spillerne at komme tæt nok på til fuldt ud at værdsætte den detalje. Så vi begyndte at eksperimentere med en strammere FOV og landede i sidste ende på 75 grader. Det krævede en vis justering for både os og spillerne, og det krævede en ekstra FOV for visningsmodeller, som er spillerens våben, holdt nederst på skærmen. Deres modeller blev oprindeligt bygget med 90 grader i tankerne, så de så forvrænget ud ved 75. Men denne ændring formåede at gøre, hvad vi ønskede: at sætte vores karakterer i centrum i spillet."
N/A4197"#commentary\cn_285_reference_maps.mp3" "[ Randy Lundeen ] Da vores figurer blev mere naturtro mellem Half-Life 1 og Half-Life 2, ønskede vi, at spilverdenen skulle føles lige så realistisk. I Half-Life 1 gjorde begrænsningerne i skydespil det ofte lettere at læne sig op ad stiliserede eller abstraherede miljøer. Men med Half-Life 2 satte vi os for at skabe en ramme, der føltes forankret i virkeligheden, hvilket betød et fokus på en masse små detaljer, vi ikke havde før. Et af vores vigtigste trin var at oprette referencekort for at standardisere, hvordan vi kortlagde virkelige proportioner i spillet. Disse kort etablerede detaljer som væg- og dørdimensioner, dørhåndtagshøjder, indvendig belysning, møbelskala og den generelle skala for almindelige genstande. Vi skabte standardiserede teksturer til niveaudesignere, komplet med skala- og lysværdier, så layout ville være konsistente fra starten. Udover at oprette den fysiske verden definerede disse referencekort, hvordan spilleren ville bevæge sig gennem den – hvor højt de kunne hoppe, hvor lavt de kunne dukke og størrelsen på rum såsom ventilationsåbninger. Ved at bruge disse kort som fundament var vi i stand til at holde vores verdensgeometri konsistent og sikre realistiskt store rum i hele spillet."
N/A4198"#commentary\cn_286_response_rules.mp3" "[ Scott Dalton ] Vi vidste tidligt, at vi ønskede en masse dynamisk dialog i spillet, så vi havde brug for et system til at håndtere det effektivt. Vi sigtede efter et system, der gjorde det muligt for lyddesignere at tilføje og finjustere linjer uden at involvere programmører, gjorde dialogen tæt lydhør over for spillets tilstand og minimerede gentagelse. Med disse krav oprettede vi Response Rules-systemet. Når en karakter taler uden for en koreograferet scene, bestemmer dette system, hvilken linje der skal leveres. I stedet for at samle linjer direkte, markerer karakter-AI konstant \"muligheder for tale\", når der sker en relevant begivenhed: når NPC'wn ser spilleren, kommer til skade, affyrer det sidste skud med en pistol, støder på overvældende fjender osv. Ved hver mulighed sender Response Rules-systemet en pakke data om spillets aktuelle tilstand, og systemet returnerer den mest passende dialoglinje, hvis der er nogen. Denne opsætning gjorde det muligt for vores lyddesignere at oprette en detaljeret beslutningsmatrix til dialog. For eksempel kan en karakter have et andet sæt linjer til at annoncere en genladning, mens den er under beskydning, kontra efter afslutningen af en kamp, eller hvis kun én allieret er tilbage, eller hvis der er en Strider i sigte. Da vi udgav Half-Life 2, følte vi, at vi kun havde berørt overfladen af dette systems potentiale. Det blev en kernefunktion i Episode 1s Alyx og fortsatte med at drive dynamisk dialog i vores senere spil, inklusive TF2s klasser og rollebesætningen i Left 4 Dead."
N/A4199"#commentary\cn_287_audio_caching.mp3" "[ Yahn Bernier ] Et andet problem, vi stødte på, var den store mængde lyd i spillet. Med alle spillelydene, musikken og dialogen havde vi for meget lyd til at kunne gemme det hele i hukommelsen – hukommelsen var i høj kurs i 2003. Men som du kan forestille dig, skal vi være i stand til at afspille lyde med det samme, især hvis de er gameplay-relaterede. Så vi byggede en lydcache, som kun gemte de første 125 ms af hver lydfil, og holdt det i hukommelsen. Den 125ms tid var vores bedste gæt på, hvor lang tid det ville tage for os at kunne streame en lydfil ind fra disken. Når en lyd derefter blev afspillet i spillet, spillede vi starten af den fra vores lydcache, mens vi samtidig startede en indlæsning af den fulde lydfil fra disken. Når vores cachelagrede startlyd sluttede, ville vi have indlæst filen og kunne fortsætte med at afspille resten af lyden herfra. Der var nogle andre, mindre funktioner, såsom at bevare nyligt afspillede lyde fuldt ud i hukommelsen, så de med høj trafik ikke behøvede at blive indlæst konstant. I nutidens motorer bruger alle slags aktiver, ud over bare lyde, typisk den samme slags strategi."
N/A4200 
39184201}
39194202}