Template:PatchDiff/March 6, 2026 Patch/hl2/resource/closecaption swedish.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 ] För att få fysiken att kännas rätt för spelaren var det viktigt att ljuden som produceras av fysiken också låter rätt. Som människor är vi vana vid hur objekt och material låter i olika situationer, även om det inte är något vi aktivt lägger märke till. Vi visste att vi inte skulle kunna redogöra för allt, men vi ville fokusera på detaljerna som bidrar mest till att få fysiken att låta realistisk. Vi började med att skapa ljud för varje objekt vid kollisioner och stötar. Det gjorde att ett objekt, som en trälåda, hade ett anpassat ljud när den kolliderade med andra objekt eller typer av objekt. Därefter började vi att dynamiskt justera ljuden baserat på den fysiska händelsens egenskaper, som massornas och kollisionernas kraft. Det fungerade bra för kollisioner men inte riktigt lika bra för andra interaktioner, som objekt som skrapade mot varandra. I verkligheten gör trädlådor ett annat ljud när de skrapar mot en vägg jämfört med när de kastas mot väggen. Och tro mig, det finns ingen som forskat mer kring nyanserna av en trälådas fysiska egenskaper än oss. För att få ut vad vi ville av interaktionerna implementerade vi kollisionsljud per material: metall mot trä, metall mot metall och så vidare. Ljuden justerades dynamiskt baserat på detaljer, som hur hårt materialet var eller typen av metall och så vidare. Att få ljudet att låta rätt krävde massor av små justeringar som vi bara märkte när ljudet spelades upp. Vi experimenterade också med anpassade ljud för rullande objekt men valde i slutändan att ta bort den funktionen då vi inte var nöjda med resultatet."
N/A3919"#commentary\cn_002_ramming_with_the_buggy.mp3" "[ Jay Stelly ] Fysisksystemet är baserat på stela kroppar, vilket innebär att det inte stöder deformation eller förstörelse av objekt. Om ett fysiskt objekt träffas av något kan det flytta sig om möjligt, men annars händer ingenting. När man kör buggyn genom ett glasfönster måste vi använda lite knep för att allt att fungera som förväntat. Eftersom fönstret sitter fast på plats får fysiksimuleringen buggyn att studsa från fönstret, men det meddelar spelsystemet om att en kollision inträffade. Spelsysetmet hanterar förstörelse, så det har sönder fönstret till glasskärvor och säger till fysisksystemet att börja simulera dem. Samtidigt säger spelsystemet åt fysisksystemet att återställa buggyns tillstånd till som det var före kollisionen. Det säkerställer att buggyn kör fritt genom det nu förstörda fönstret nästa gång fysiken simuleras. Processen resulterar i att buggyns fysik hakar upp sig i en bildruta, då den kort stannar och teleporteras tillbaka till ögonblicket före kollisionen. Vi beklagar om den här lilla insikten har gjort Half-Life 2 helt ospelbart, men efter att ha tittat på speltester kom vi fram till att vi faktiskt gillade det ögonblickliga rycket – det förhöjde kollisionskänslan."
N/A3920"#commentary\cn_003_ramming_zombies_with_the_buggy.mp3" "[ Jay Stelly ] Som människor har vi förväntningar på den fysiska världen, vilket vi har tagit upp några gånger här i kommentatorspåret. En av de förväntningarna är att zombier som blir påkörda av bilar bara måste flyga iväg. Att åstadkomma den effekten i spelet är dock inte lika enkelt som det är i den riktiga världen. Av prestandaskäl använder fiender som zombier en förenklad kollisionsbox under spelet. Boxen sitter tätt runt zombien utan att några delar av modellen sticker ut. Men när zombien dör omvandlas den till en ragdoll med mer exakta kollisionsboxar per lem. Det är dock dyrare att simulera. Förändringen i kollisionsrepresentation gör det mer komplecerat när man kör på en zombie med buggyn, utöver bara bildproblemet. När buggyn kolliderar med zombien vidrör den zombiens förenklade kollisionsbox. Spelet dödar sedan zombien och omvandlar den till en ragdoll som fysiksystemet börjar simulera. Nu när vi har mer exakt kollision per lem kan den närmaste delen av zombien vara flera centimeter bort från buggyn. Resultatet är att nästa gång fysiksystemet simuleras får tyngdkraften zombien att falla eftersom buggyn inte längre knuffar den. Det tar bara ett kort ögonblick innan buggyn når zombien igen, men den här lilla avvikelsen gör det otillfredsställande att att köra på zombier – de ramlade ofta ut ur spelarens vy. För att åtgärda det sparade vi kraften som zombiens kollisionsbox fick när den träffades av buggyn. Vi tillämpade samma kraft på ragdollen efter omvandlingen. Vi lade också till en lätt uppåtriktad kraft på ragdollen, vilket sköt upp den en aning. Med de här justeringarna vek sig zombierna på ett tillförlitligt sätt över framsidan på buggyn vid kollision, vilket stämde bättre överens med spelarnas förväntningar."
N/A3921"#commentary\cn_004_buggy_sound_engine.mp3" "[ Kelly Bailey ] Ljudet från buggyn var en utmaning, för vi ville att den skulle kännas som ett kraftfullt fordon som kör i superhög fart, trots att kartorna egentligen inte är anpassade för det. Buggyn lämnar knappt ens första växeln och mMaxhastigheten är nog inte högre än 55 km/h. Till vårt försvar är 55 km/h ändå rätt snabbt, särskilt år 2004. Utöver farten är körkontrollerna väldigt enkla. Spelar man med skrivbord är spelarkontrollerna i stort sett binära, så antingen accelererar buggyn eller så gör den inte det. Den vrider sig antingen helt i en riktning eller så vrider den sig inte alls. Vi fick alltså skapa en sorts ljudkomplexitet för att representera en simulation som inte ens är komplex. Vi byggde en låtsasmotor för buggyns ljud. Den har en egen växellåda och vi kombinerar spelarinmatningar med data från fysiksimuleringen. Vi mäter vridmomentet på varje simulerat hjul, oavsett om det snurrar eller har fäste, och vi skapade loopande ljud som vi sedan försiktigt blandar ihop när låtsasmotorn växlar och svarar på hjuldata. Vi försökte i princip att prova olika saker. Vi lade till mer komplexitet. Vi gjorde lite finjusteringar tills buggyn kändes roligare och belönar en med sin fartkänsla. De flesta spelare har har inte så mycket att säga om den, mer än att buggyn låter bra. Det tar vi som att vi lyckats, med tanke på all galenskap som pågår under huven."
N/A3922"#commentary\cn_005_buggy_sound_design.mp3" "[ Kelly Bailey ] Buggyns ljuddesignen baserades på samplingar från en gammal Camaro från 1968. Vi valde den bilen eftersom den har fantastiska V8-motorer med stora kolvar. Det finns inget annat ljud som kommer i närheten. Den har det där renodlade urvrålet vi var ute efter. Växellådan har dessutom ett riktigt härligt mekaniskt gnäll när den slutar accelerera. Den kombinationen gav rätt sorts respons i det nästan binära kontrollsystemet som vi var tvungna att arbeta med. Växellådan på låtsasmotorn modellerades inte efter någon riktig bil. Istället utformades den som ett enkelt belöningssystem när man trycker ner gaspedalen. Den är som en rulltrappa som producerar en stigande ton – den bygger hela tiden spänning och växlar när tonen måste startas om. Eftersom man inte har så mycket svängrum på de relativt små kartorna var målet att göra det roligt att accelerera i kortare stötar."
N/A3923"#commentary\cn_006_automating_dsp.mp3" "[ Kelly Bailey ] Allt ljud som spelaren hör bearbetas genom vårt digitala signalbehandlingssystem – vår ”DSP”. Systemet hanterar hur ljudet ändras för att återspegla miljön som spelaren befinner sig i. Samma ljud kommer exempelvis att låta annorlunda på en parkeringsplats, i ett litet rum eller utomhus. I Half-Life 1 placerade vi manuellt osynliga noder i hela världen för att definiera DSP-inställningarna per utrymme. I Half-Life 2 visste vi att manuell placering skulle vara för tidskrävande, särskilt eftersom vi ville ha ett större spel och vi fortfarande bara hade en ljudperson i teamet. Vi byggde ett system som automatiskt avgör DSP-inställningarna för spelaren i realtid. Det sker genom att utrymmet runt spelaren analyseras och att volymen runt omkring bedöms. Kortfattat undersöks alla material i närheten. Systemet matchar sedan det utrymmet med en av 25 handskrivna grundläggande DSP-typer, sen justeras parametrarna en aning för att skapa en detaljerad DSP som ändrar ljuden som spelaren hör."
N/A3924"#commentary\cn_007_dynamic_mixing.mp3" "[ Kelly Bailey ] Under spelets gång spelas många ljud upp på samma gång, men vissa ljud är naturligtvis viktigare än andra och vi måste ställa in volymen på ljuden i förhållande till varandra för att se till de viktiga ljuden sticker ut. I filmer görs ljudmixningen i efterhand, men i spel händer det i realtid som svar på spelarens handlingar, så det går inte att i förväg förutse vilka ljud som kommer att spelas upp samtidigt. För att hantera det grupperas alla ljud i olika typer och taggas med olika prioriteringsordningar. Under spelets gång övervakar ljudsystemet alla aktiva ljud och sänker volymen på ljud i en grupp om ljud med högre prioritet spelas. Mixningen kan justeras. Om skottljud måste vara höga i en scen kan vi sänka prioriteten där. Om en specifik röstreplik måste höras tydligt kan volymen på alla andra ljud sänkas. Vi gör samma sak med musiken. Det är ett subtilt men mycket viktigt system, och det förhindrar att ljudlandskapet blir för rörigt."
N/A3925"#commentary\cn_008_soundscapes.mp3" "[ Kelly Bailey ] I Half-Life 1 placerades omgivningsljud för hand och justerades sedan individuellt. I Half-Life 2 ville vi har mer omgivningsljud i miljöerna, med högre kvalitet och mindre manuellt pill. Därför byggde vi systemet som vi kallar ljudlandskapssystemet. Ett ljudlandskap är i princip ett litet program som styr vilka omgivningsljud som spelas, varifrån de kommer och hur de beter sig i en specifik miljö – flugor som surrar, vind som blåser, ett tåg eller en strid i fjärran. Ljudlandskapssystemet kan slumpmässigt välja ut och spela ljuden, och framförallt kan det hantera mjuka övergångar när spelaren förflyttar sig mellan olika miljöer. Ljudlandskap kan innehålla andra ljudlandskap, vilket gör att vi kan skapa återanvändbara ljudsamlingar. Strider i fjärran kan exempelvis bestå av skottlossning, avlägsna explosioner eller helikoptrar som flyger förbi. Ljudlandskapen kan sammanställas dynamiskt och spelas upp från många olika separata ljud. Det hjälper oss att undvika den konstgjorda känslan av att bara ha ett spår som loopas. Ljudlandskapssystemet sliter hårt i Half-Life 2 och ansvarar för i stort sett alla ljud man hör som inte uppstår dynamiskt under spelets gång."
N/A3926"#commentary\cn_009_audio_over_distance.mp3" "[ Kelly Bailey ] De stora utrymmena på kustnivåerna fick oss att hitta en lösning för hur ljudet ändras på avstånd. På de nivåerna kan en fiende befinna sig långt över 100 meter bort, och fiendens pistol bör låta annorlunda på det avståndet än på nära håll. Vi bestämde oss för att lagra ljuden i en enda stereofil, med ljud på nära håll i den vänstra kanalen och ljud på avstånd i den högra kanalen. Under uppspelning använder vi crossfade eller ändrar andelen ljud man hör, mellan de två kanalerna baserat på spelarens avstånd från ljudet. Det var en enkel lösning som fungerade bra. Det hjälpte oss med minnesbegränsningar. Man kan lätt höra det spelas upp – lyssna bara efter hur combine-soldaters skott ändras när du närmar dig dem."
N/A3927"#commentary\cn_010_flying_vehicle_audio.mp3" "[ Kelly Bailey ] De stora flygande fienderna i spelet utgör en unik ljudutmaning. I strid är de mycket mer rörliga än andra fiender, och de förflyttar sig ofta en bra bit bort från spelaren. De är också mycket farliga om de har fri sikt. De här faktorerna fick oss att fokusera på en ljudlösning inriktad på siktlinjer, alltså när man själv kan se fienden och när fienden kan se en själv. Vi ville göra en tydlig ljudskillnad när när fienderna har fri sikt. Ljuden från den flygande fordonsmotorn består av ett flertal ljudslingor som vi spelar på samma gång. Vissa av slingorna bearbetas av DSP-systemet baserat på utrymmet som man befinner sig i medan andra ljud spelas upp direkt utan bearbetning. DSP-systemet lägger på en ekoeffekt när vi kör ljudet genom systemet. När siktlinjen till det flygande objektet bryts och det inte kan se en ökar procentandelen ljudslingor som körs genom DSP-bearbetningen, och det får det att låta som att objektet är lite mer avlägset. När siktlinjen sedan blir fri igen spelar vi det mer direkta ljudet. Överlag ger det känslan av att ljudet antingen är avlägset och riktningslöst eller mer direkt i ens siktlinje. Man hör det när helikoptern kommer fram från bakom en byggnad. Helst ska man kunna höra skillnaden markant."
N/A3928"#commentary\cn_011_bullet_audio.mp3" "[ Kelly Bailey ] En sak var vi helt säkra på – det kommer att vina många kulor om spelaren, så vi lade en massa tid på att försöka göra ljudbehandlingen perfekt för det. Tyvärr är kulträffarna i spelet i princip omedelbara, så det går inte att bara lägga till ett ljud på dem och förlita sig på förflyttningen för positioneringen. Efter lite experimentering hittade vi en lösning: genom att hitta kulbanans närmaste punkt till spelarens öra beräknar vi den exakta tiden och positionen som kulan konceptuellt passerar spelaren. Sedan spelar vi upp två olika ljud för att fejka en dopplereffekt – en när kulan närmar sig och en när den flyger iväg från spelaren. Vi försenar kulans avfärdsljud baserat på den beräknade tiden då kulan passerar."
N/A3929"#commentary\cn_012_staircase.mp3" "[ Aaron Seeler ] Det finns situationer i hela spelet som härrör från enkla och ganska raka designmål, och den här trappan har två av dem. Det första var att rama in citadellet när det vaknade, för att visa att spelaren har rört om i grytan. Det andra var att visa upp ragdollsystemet. Det är standard nu, men 2004 var det fortfarande ovanligt att se kroppar ramla på ett realistiskt sätt, och trapporna var den perfekta skådeplatsen."
N/A3930"#commentary\cn_013_alyx_and_mossman.mp3" "[ Bill Fletcher ] I de tidiga planerna för berättelsen i Half-Life 2 ville vi ta oss an utmaningen att göra något mindre spelinriktat. Inte bara en berättelse om den övertydligt goda spelaren som besegrar de övertydligt onda fienderna. Istället ville vi fokusera på karaktärerna och deras relationer. Vi tänkte att det kunde vara intressant att utforska familjen som den centrala dynamiska enheten i Half-Life 2. Spänningen mellan Alyx och Mossman kom från den idén, och vi gillade det eftersom det kändes relaterbart – något som spelare kunde förstå och känna empati med."
N/A3931"#commentary\cn_014_exposition_board.mp3" "[ Danika Rogers ] Här ville vi berätta mycket rent visuellt, för det är här spelet är som mest tydligt med att säga åt spelaren att utforska sin omgivning. Primärt är det ett sätt att bygga upp världen, men vi fokuserar även på att framhäva relationen mellan Eli och Breen, vilket ger sammanhang till den centrala konflikten i världen."
N/A3932"#commentary\cn_015_city_17_awakens.mp3" "[ David Sawyer ] Tågstationsdelen i början var utformad för att få staden att kännas likgiltig gentemot spelaren, som om Gordon bara är en av många namnlösa, ansiktslösa medborgare redo att tyglas. Det ändras under hyreslägenhetsräden och jakten över hustaken, då staden identifierar spelaren som en avvikelse. Som angripare riktar staden sin uppmärksamhet helt mot spelaren. Övervakningsstyrkans högtalarsystem, som först hörs under räden, spelar en viktig roll i att leverera meddelandet. Om man lyssnar noga kan man höra mycket information om stadens medvetenhet. Även för spelare som inte är uppmärksamma förmedlar ljudet ändå det känslomässiga budskapet vi är ute efter."
N/A3933"#commentary\cn_016_elis_lab.mp3" "[ Dhabih Eng ] Vi byggde Elis labb efter Dr. Kleiners labb, så vi hade bättre koll på hur man utformar effektiva koreografiscener. Därmed kunde vi skapa ett mer komplicerat scenario med fler möjligheter att reagera på det spelaren gör. Att ha flera karaktärer som gör olika saker i rummet gjorde iscensättningen svår och krävde många justeringar och mycket speltestning för att få allt att fungera smidigt. Vi lärde oss att spelare på det stora hela vill delta i händelserna – de behöver bara tillräckligt med subtila ledtrådar för att veta var vi vill ha dem. Om spelaren blir distraherad pausas scenen medan den väntar på att spelaren återvänder."
N/A3934"#commentary\cn_017_feel_free_to_look_around.mp3" "[ Dhabih Eng ] Att balansera spelarens önskan att utforska scenen med berättelsen var alltid en utmaning. Vi ville att rummet skulle vara fullt av intressanta saker att titta på, men många spelare utforskade inte rummet förrän de var säkra på att de inte missade något av det karaktärerna gjorde. Därför var det viktigt för Eli att säga till spelaren att se sig omkring halvvägs genom scenen. Det signalerade att det var säkert att börja utforska. Därefter kunde vi utlösa olika anpassade miniscener baserat på vad som fångade spelarens intresse."
N/A3935"#commentary\cn_018_interstitial_scenes.mp3" "[ Eric Kirchmer ] Under speltestningen hittade vi ofta områden där spelare glömde bort vad de skulle göra, vilket inte är ovanligt i ett spel som Half-Life. För att lösa det lade vi till kortare mellanliggande scener för att hjälpa spelaren på vägen och påminna dem om sina mål. Efter att ha blivit klara med merparten av utvecklingen av de större koreografiscenerna, som Kleiners labb, blev det relativt enkelt att sätta ihop de mindre scenerna. Vi upptäckte att det fungerade mycket bättre att använda karaktärer i de scenerna än att förlita sig på passivt berättande eller någon slags påminnelse i en pausmeny."
N/A3936"#commentary\cn_019_overwatch.mp3" "[ Josh Weier ] Under utvecklingen genererade vi övervakningsrösten med hjälp av ett gratis text till tal-verktyg, men när vi närmade oss lansering insåg vi att vi inte hade rättighet att använda det. Vi testade olika röstskådespelare för att hitta någon som kunde matcha det vi gillade i de genererade replikerna. Det tog inte lång tid innan vi hittade Ellen McClain, vars röst var exakt vad vi var ute efter. Vi spelade upp de genererade replikerna som hon skulle härma i ljudstudion, fast med hennes egen stil. Hon var lite sarkastisk i början, med tanke på att hon hade blivit ombedd att efterlikna en robotröst. När hon flera år senare återvände för sin ikoniska roll som GLaDOS i Portal hade hon hittat ett kreativt sätt att använda robottonen i sitt framträdande."
N/A3937"#commentary\cn_020_box_car_joe.mp3" "[ Laura Dubuk ] Den korta scenen innehöll ursprungligen två mänskliga karaktärer, men senare i utvecklingen ersatte vi en av dem med en vortigaunt. Vi ville visa att vortigaunter kunde samexistera med människor och att de gjorde motstånd mot combine. Vi introducerade också deras förmåga att läka spelaren, fast vi utnyttjade inte den funktionen fullt ut i hela spelet. Vortigaunter blev ett användbart berättarverktyg för att hålla dialogen kort då deras grupptänk motiverade deras omfattande kunskap om världen och spelarens mål. Det innebar att de aldrig behövde ställa frågor, vilket fick oss att på ett snyggt sätt kringgå utmaningen med att skriva dialog till en tyst huvudperson."
N/A3938"#commentary\cn_021_mossman.mp3" "[ Marc Laidlaw ] Judith Mossman var ursprungligen baserad på en karaktär som vi hade planerat att ha med i ett avsnitt av Half-Life 1. Det avsnittet togs bort och återanvändes i Uplink, fast utan den karaktären. Vi anser henne vara den mest komplexa karaktären i Half-Life 2. Vi visste att det skulle bli svårt att veta vad spelaren tyckte om henne, även före Nova Prospekt, eftersom spelarens betrodda källor inte håller med varandra. Eli gillar henne, men Alyx gör inte det. Vi förstod att det fanns en gräns för hur mycket komplexitet vi kunde använda i relationer, men vi kände att ett förhållande mellan styvmor och dotter var något som spelare skulle förstå sig på. Vare sig du håller med Mossman eller inte är det hon gör heroiskt. Hon tar risken att bli en dubbelagent för att få informationen hon behöver för att beskydda Eli och Alyx. Hon hade bara inte räknat med Gordon."
N/A3939"#commentary\cn_022_hands_free.mp3" "[ Matt Wright ] När Half-Life 2 släpptes gav de flesta förstapersonsskjutare spelaren en pistol eller ett närstridsvapen direkt, men vi valde att låta spelaren starta tomhänt. Utan ett vapen var det enklare att visa på vilka nya sätt spelaren kunde interagera med världen, och även introducera berättelsen. Vi ville att spelaren skulle gå från att vara på flykt till att anfalla, och ett vapen vid rätt tidpunkt skulle skapa det ögonblicket naturligt. När det här händer är spelaren inte längre på flykt. Det brukas sägas att det bästa sättet att vinna är att undvika konfrontationer, men vi vet alla att det inte stämmer. Det bästa sättet att vinna är att springa mot någonting samtidigt som man skjuter."
N/A3940"#commentary\cn_023_metrocop_scene.mp3" "[ Mike Dussault ] Det här är en annan scen vi designade för att göra det tydligt att metro-poliserna är skurkarna, fast den här gången har spelaren ett vapen och kan äntligen göra någonting åt det. Och med ”någonting” menar vi det som kommer ut ur pipan på en pistol. Vi visste att vi behövde få spelarna att känna att slåss för rätt sak, och det här ögonblicket var en del av det. Metro-poliserna är fortfarande mänskliga i spelet, till skillnad från combine, så vi kände att vi behövde jobba extra hårt för att se till att spelarens handlingar kändes rättvisa och inte bara sprungna ur ilska."
N/A3941"#commentary\cn_024_moving_the_gravity_gun.mp3" "[ Ted Backman ] När gravitationsvapnet skapades som prototyp var tanken att ge det till spelaren halvvägs genom spelet, men under speltestningen såg vi styrkan i dess design och insåg att gravitationsvapnet, och framför allt möjligheten att skjuta sågblad mot zombier, måste introduceras tidigare. Det innebar även att tidigarelägga Elis labb. Det var en betydande förändring, men också avgörande för Half-Life 2:s framgång. Det är en bra påminnelse om att berättande och spelmekanik hör ihop och att de måste fungera sida vid sida."
N/A3942"#commentary\cn_025_buggy_birds.mp3" "[ Adrian Finol ] I ett minnesvärt speltest på kusten återvände en spelare till sitt fordon efter att ha utforskat ett hus och råkade se en fågel flyga förbi. Spelaren skrek på fågeln och sa till den att hålla sig borta från buggyn, och beklagade sig över att fåglar brukar bajsa på bilar i verkligheten. I diskussionerna efter speltestet insåg vi att det här var första gången som vi hade objekt som var separata från spelaren och som spelaren brydde sig om. Vi utforskade det här mer och utvecklade ett system för att återskapa ögonblicket som speltestaren fruktade. När spelaren lämnat buggyn ett tag och den är utom synhåll spawnar en fiskmås på en slumpmässig plats på buggyn. Efter ett tag bajsar fiskmåsen på bilen och fortsätter med det tills den flyger iväg när spelaren återvänder. Naturligtvis vill speltestarna kunna tvätta sina fordon, så vi lade till möjligheten att tvätta bilen genom att köra den genom grunt vatten. Det var ganska sent in i utvecklingen, så vi hade all teknik för att snabbt kunna implementera funktionen. Det är en sån där grej som bara ett fåtal spelare kommer att upptäcka, men om vi kan implementera såna detaljer på ett effektivt sätt och om vi har tillräckligt många av dem så kommer de flesta spelare att upptäcka minst en."
N/A3943"#commentary\cn_026_bridge_gunship.mp3" "[ Adrian Finol ] Vi var särskilt nöjda med striden på kanonskeppet, trots att den var svår att skapa med tanke på nivågeometrin. När det befann sig på undersidan av bron var det möjligt för kanonskeppet att röra sig helt runt spelaren och använda alla tre dimensioner för att placera sig ovan- och nedanför vid olika ögonblick. Balkarna gav gott om högfrekvent skydd, vilket gav möjlighet för kanonskeppets eld att skapa roliga och dynamiska visuella effekter och ljudeffekter."
N/A3944"#commentary\cn_027_floor_is_lava.mp3" "[ Adrian Finol ] Att bygga spelmekanik kring allmänna begrepp som \"golvet är lava\" underlättade träningen. Vi gillade att fysiksystemet gav spelarna stor kreativ frihet när de försökte ta sig fram. Vissa byggde gångvägar med många olika föremål medan andra fokuserade på att bara använda två metallplåtar. Vissa följde försiktigt stigen upp i klipporna och oroade sig över att ramla, medan andra gick direkt mot utgången via föremål på sanden. Spelstilarna varierade; vissa spelare ansåg det vara ett misslyckande om myrlejonen dök upp och laddade om på en gång, medan andra tyckte om att krypa tillbaka upp på klipporna för att återhämta sig. Vi gillade också att det fungerade som ett navigeringspussel som kunde omvandlas till en arena om spelarna så önskade – vissa hoppade helt enkelt ner på sanden och kämpade sig fram till slutet."
N/A3945"#commentary\cn_028_opportunistic_moments.mp3" "[ Ariel Diaz ] Vissa minnesvärda ögonblick i spelet uppkom genom interaktioner mellan flera spelsystem, men ibland inser vi att de här ögonblicken troligtvis inte inträffar så ofta. Vid såna tillfällen önskar vi ofta att fler spelare skulle få uppleva dem. Det finns även ett problem med det här. Ju mer vi vet att spelare kommer att stöta på något, desto mer kan vi fokusera på det. Men om det känns för konstlat kan ögonblicket framstå som påtvingat och spelarna kanske inte reagerar lika positivt. Kanonskeppets filmiska död är ett exempel där vi försökte öka chanserna att skapa ett minnesvärt ögonblick utan att det skulle vara uppenbart. Utformningen av området och kanonskeppets flygvägar gör det troligt att spelaren och kanonskeppet är på rätt ställe när det dör. Om de är det kraschar kanonskeppet in i bilarna. Om inte så dör det på sitt vanliga sätt. Det är väldigt \"speligt\", men speltestarna verkade inte ha några problem med det här ögonblicket."
N/A3946"#commentary\cn_029_assault_on_nova_prospekt.mp3" "[ Ariel Diaz ] Med en oändlig myrlejonsarmé vid en kustlinje som anfaller en befäst combine-bas var det svårt att inte försöka sig på en Normandie-inspirerad nivå. Vår första prototyp innehöll skyttegravar som ledde fram till Nova Prospekt, med kraftfulla maskingevär som tvingade spelarna och deras myrlejon att stanna i skyttegravarna för att överleva. Det var spännande att ha maskingevärseld och hoppande myrlejon som ständigt passerade ovanför skyttegravarna. Tyvärr fick vi det inte att fungera inom vår prestationsbudget, och till slut var vi tvungna att lägga det åt sidan till förmån för en helt annan layout. Men de monterade maskingevären finns kvar, eftersom de är så farliga att spelarna uppmuntras förlita sig på sina myrlejon."
N/A3947"#commentary\cn_030_buggy_physics.mp3" "[ Charlie Brown ] Fysiken för buggyn krävde mycket arbete. Vi ville att den skulle kännas snabb, även om toppfarten bara var cirka 55 km/h, så vi var tvungna att fuska lite för att få det att fungera. Vi lade till extra vertikal kraft till turbohoppet och lite extra kraft baktill när handbromsen användes för att sladda. Utan det här skulle den låga hastigheten göra att buggyn helt enkelt inte var rolig att köra. Utöver det var världen full av oförutsägbart kaos som drivs av fysiksystem – det var oundvikligt att spelarna skulle råka ut för alla möjliga kollisioner, så vi var tvungna att se till att de kunde ta sig vidare. Det här krävde många experiment och speltester. Till slut bestämde vi oss för en ganska fånig, orealistisk simulering som gjorde buggyn lättare överlag och svårare att välta. Buggyns tyngdpunkt är superlåg, och hjulen svänger, även om det ser ut så, inte särskilt mycket. Det var vårt första försök med ett fysiskt simulerat fordon, och vi lärde oss massor av det. Tack vare det kunde vi göra muskelbilen i Episode 2 mycket enklare att köra."
N/A3948"#commentary\cn_031_the_bridge.mp3" "[ Charlie Brown ] Den här brosektionen inspirerades av Deception Pass Bridge, som ligger alldeles intill Valves kontor. Vi byggde till en början sektionen som ett rent navigeringspussel och lade gradvis in mer spelmekanik i det. Det blev också det primära testfallet för vår spelares kantfriktion. I vårt rörelsesystem minskar vi hastigheten vid förflyttning när spelaren närmar sig kanten av en yta. Spelarna har aldrig märkt det – troligtvis för att deras tanke är att stanna vid kanten för att titta ner, vilket överensstämmer med den mänskliga reaktionen att röra sig långsammare och försiktigt nära ett stup. Det är en väldigt viktig funktion för den här delen av spelet. Vi vet det här eftersom vi vid ett tillfälle under utvecklingen inte hade den aktiverad, och plötsligt började alla speltestare upprepade gånger att falla mot sin död."
N/A3949"#commentary\cn_032_coast.mp3" "[ Chris Green ] Vi ville ha en vidöppen del av spelet ägnad åt buggyn, men vi behövde samtidigt ett sätt att begränsa spelarens rörelse. Kustlinjen gav oss en naturlig gräns längs ena sidan av kartan, samtidigt som området kändes öppet och stort. Det hjälpte också till att visualisera resultatet av combines utvinning av jordens resurser. Speltestarna försökte fortfarande simma ut i havet, så vi lade till iglar för att avskräcka dem. Iglarna fick inte vara riktiga fiender som går att undvika och ser ut att kunna bekämpas, så de är lite magiska. Spelarna förstod i mångt och mycket att de tänjde på spelets gränser, så vi såg till att inte ”överutveckla” dem."
N/A3950"#commentary\cn_033_grenade_house.mp3" "[ Dave Riller ] En stor del av Half-Life-spelen handlar om att ge spelare nya stridsupplevelser gång på gång, även om de bara skiljer sig lite från de tidigare. Det behöver inte alltid vara skicklighetsbaserade utmaningar; ibland kan de bara vara roliga stunder där spelaren får roa sig. Det här granathuset är ett sånt ögonblick, med skillnaden att vi har vänt på den traditionella utformningen. Istället för att spelaren släpper granater på fiender nedanför har vi placerat fienderna ovanför. Den obegränsade granatlådan är ett lite klumpigt sätt att uppmuntra spelaren att engagera sig i scenariot, men dess osårbarhet säkerställer också att spelaren fortfarande kan klättra upp till våningen ovanför, även om de har sprängt allt annat."
N/A3951"#commentary\cn_034_buggy_training_course.mp3" "[ David Sawyer ] Den här träningssektionen skapades för att låta spelaren leka med sin buggy. När Half-Life 2 släpptes var den här en ny nivå av fysiksimulering i ett fordon, så vi ville ge spelarna gott om möjligheter att prova sig fram. Spelaren har precis lämnat Ravenholms trånga utrymmen och vi gillade tanken på den kontrasterande belöningen att kunna röra sig snabbt genom ett stort utrymme och känna sig trygg i ett fordon. Vi såg till att ett turbohopp krävdes för att komma ut ur det här området, vilket fungerade som ett test för att se till att spelaren hade lärt sig tillräckligt mycket om körningen, och även säkerställa att buggyn inte lämnades kvar."
N/A3952"#commentary\cn_035_ambush.mp3" "[ David Sawyer ] En av de vanliga utmaningarna med FPS i Half-Life-stil är att spelarna hela tiden rör sig framåt till platser de inte känner till. När de hamnar sig i strid befinner de sig alltså i okända områden utan kunskap om hur de ska ta sig an kampen. Vi använder många olika metoder för att hjälpa dem med det här kruxet, och det här bakhållet är ett bra exempel. När spelarna anländer slåss de mot en grupp combine bland husen. Under striden, och sedan när de utforskar efteråt, har de möjlighet att bekanta sig med arenans layout. Sedan, när de utforskar den här vinden, spawnar vi en andra våg med combine. I den här, andra, striden har spelarna nu ett övertag i att de kan layouten, vilket gör att de kan fatta mer taktiska beslut när de försvarar sig mot angriparna."
N/A3953"#commentary\cn_036_bugbait_training.mp3" "[ David Sawyer ] Den här klumpiga insektsbetesträningen var det vi kom fram till när vi fick slut på tid men behövde få spelarna att förstå verktyget för att Nova Prospekts design skulle funka. Oftast försöker vi att sätta träning i ett sammanhang i berättelsen så att det inte känns som träning utan som en naturlig del av att upptäcka något nytt. Här lyckades vi inte riktigt. Det kanske verkar uppenbart nu, men i början förstod spelarna inte insektsbetet intuitivt. Nu är vi långt in i spelet, så spelarna har gott om erfarenhet av fiender. Innan vi lade till träningen tog de första speltestarna som hittat insektsbete sig till nästa nivå och sköt direkt det första myrlejon de såg – det hade ju funkat fram till dess. I Half-Life brukar ju ”skjut först och fråga sen” vara en bra strategi. På samma sätt tänkte inte spelarna på att kasta insektsbete på combine-soldaterna när de kom till Nova Prospekt, utan förlitade sig på sina vanliga vapen. Vi behövde den här träningen för att visa hur insektsbetet funkar och för att demonstrera att myrlejonen befinner sig nära spelaren utan att attackera."
N/A3954"#commentary\cn_037_vortigaunt_extraction.mp3" "[ Dhabih Eng ] Den här arenan orsakade lite knepiga designproblem, av flera skäl. Det första var att vakten bara på slåss på nära håll, så vi kunde inte låta spelaren ta sig till områden vakten inte kunde nå. Vi experimenterade med olika avståndsattacker men gillade inte resultaten – geggspottsattacken såg jättefånig ut, exempelvis. Den enda icke-närstridsattack som överlevde var förmågan att slå fysikobjekt mot spelaren, men det krävde att föremålen befann sig inom räckhåll – och det gör de ju inte alltid. Den andra utmaningen var att se till att var vakten än dör så kan vortigaunten nå kadavret. Det var enormt viktigt. Spelet kan ju inte fortsätta om vortigaunten inte kan ta ut insektsbetet."
N/A3955"#commentary\cn_038_dropship_deployment.mp3" "[ Doug Wood ] Det var svårt att sätta ut soldater från droppskeppen, eftersom det kräver att NPC:erna spawnar inuti ett solitt objekt. För att få ut dem i det öppna, där de kan ta sig runt som vanligt, har de en animation där de hoppar ur containern så fort de spawnar. När vi väl hade fått det att funka stötte vi på nästa problem – listiga spelare väntade utanför containern och sköt soldaterna under utgångsanimationen. För att motverka det lade vi till en kanon på containern som skyddar soldaterna när de kliver ur. Det förhindrar inte helt att spelarna drar nytta av situationen, särskilt inte om de använder indirekta vapen som granater, men det kändes realistiskt och som något någon som tänker strategiskt skulle göra."
N/A3956"#commentary\cn_039_laser_guided_rpg.mp3" "[ Eric Smith ] Raketgevärets laserstyrning blev en enorm huvudvärk för oss eftersom den var så svår att lära ut. Många speltestare sköt en raket och hukade sig sedan bakom ett skydd, så de såg inte hur raketen flög. Än värre var att de då inte insåg att raketen vände om och flög tillbaka mot dem. Vi provade olika gränssnittselement och laserpunktindikatorer som skulle hjälpa till, men vi märkte att de flesta spelare missade dem när de fokuserade på fienden. Vi gjorde alla små förbättringar vi kunde, som att lägga vikt vid funktionen i Odessas tal samt förbättra det audiovisuella kring hur kanonskeppet skjuter ner direkta raketer. De här ändringarna fick spelarna att förstå funktionen, men vi nådde aldrig en punkt där vi var säkra på att nästan alla förstod. Vi funderade på att stryka funktionen helt, men utan den blev striden med kanonskeppet mycket tråkigare. Laserstyrningen tvingade spelaren att ha kanonskeppet i sikte när raketen var i luften, men det innebar ju också att kanonskeppet hade en siktlinje mot spelaren – och det skapade en spänning vi gillade."
N/A3957"#commentary\cn_040_performance_constraints.mp3" "[ Eric Smith ] Vi tänkte oss att det sista kustområdet skulle avslutas med en storslagen final där spelaren och en grupp medborgare skulle kämpa mot en grupp combine-soldater, något som skulle kulminera i en strid mot ett kanonskepp. Tyvärr krävde soldaternas och kamraternas förflyttning i terrängen så mycket prestanda att vi var tvungna att skala ner på striden för att klara prestandabudgeten. När vi sett till så att det bara fanns en grupp soldater kvar åt gången var vi långt in i utvecklingen. Det var för sent för att göra om arenan för att få plats för fler fiender, så vi hade inget annat val än att designa om striden för att minimera antalet soldater."
N/A3958"#commentary\cn_041_lighthouse_gunship.mp3" "[ Ido Magal ] Scenariot med kanonskeppet här krävde en del arbete för att det skulle funka som vi hade tänkt – vi ville att det skulle kännas som en film. Hade det varit en film hade kanonskeppet förutsett huvudpersonens rörelser och skjutit genom fönstren medan protagonisten tog sig upp genom fyren. För att skapa samma känsla i spelet skapade vi en komplex serie med aktiveringsområden längs trappan. När de upptäcker att spelaren är på väg uppåt ber de kanonskeppet att välja en ny väg som matchar spelarens höjd. De aktiverar även måltavlor i fönstren närmast spelaren – osynliga spelföremål som fiende-AI:n uppfattar som fientliga – och instruerar skeppet att skjuta på fönstren. Den här blandningen av AI och skriptat beteende är grunden i Half-Lifes stridsscenarier. AI:n hanterar NPC:ernas allmänna anpassningsbara beteende medan skriptet anpassar varje scenarios unika krav."
N/A3959"#commentary\cn_042_crane.mp3" "[ Jakob Jungels ] Lyftkranen krävde mycket finjustering för att få till. Något som skapar så mycket fysisk kraft är alltid knepigt sett till våra fysikmodellers och vår förstörelsetekniks begränsningar. Magneten skulle till exempel aldrig kunna möta spelarens förväntningar kring något med så mycket massa, men eftersom lyftkranen var stationär kunde vi välja allt inom dess räckvidd och finjustera efter behov. Som tur var märkte inte de flesta spelarna skavankerna – kanske för att det var så pass nyskapande att interagera med något sånt i en vagt realistisk fysikmiljö."
N/A3960"#commentary\cn_043_flashlight_power.mp3" "[ Jeff Lane ] Det var ett kontroversiellt beslut att spurten och ficklampan skulle använda sig av samma kraft som HEV-dräkten i Half-Life 2. Till en början var det bara spurten som använde dräktens kraft, vilket var logiskt eftersom det bara skulle vara en kort hastighetsbonus. Ficklampan, å andra sidan, kunde användas utan begränsningar, men under speltesten visade sig ett problem: spelarna lämnade ofta mörka områden utan att inse att ficklampan fortfarande var på. I väl upplysta, öppna områden som kusten var det för prestandakrävande att konstant ha ficklampan igång, så vi behövde ett sätt att stänga av den utan spelarens inblandning. Att begränsa dess energi var en enkel lösning, som även skulle göra mörka områden mer spännande. Då dök en ny utmaning upp – vad ska den använda för resurs? Vi hade redan dräktkraften och ville inte plottra till gränssnittet med en ny resurs bara för ficklampan. Vi lekte med idén att ge spelaren andra förmågor som skulle använda dräktkraften och tyckte att det skulle bli intressant att tvinga spelarna att väga dem mot varandra. Det här är ett bra exempel på hur speldesign ofta handlar om att välja mellan lösningar som inte är helt perfekta. Vi ogillade tanken på att spurten och ficklampan skulle dela på samma resurs men ville inte gör gränssnittet plottrigt med fler resurser. I Episode 2 valde vi att ge ficklampan en egen separat resurs, eftersom vi ändå inte skulle lägga till något annat som förbrukade dräktkraft."
N/A3961"#commentary\cn_044_open_world_loot.mp3" "[ Jeff Lane ] Eftersom kusten är så öppen fick vi nya problem med utdelningen av föremålsbelöningar. I Half-Life-spelen brukar vi belöna spelare för utforskning. Ser man en väg framåt men upptäcker något vid sidan om är det ofta värt att ta sig tiden att leta lite. När vi först började speltesta kustkartorna gömde vi hemligheter i utomhusområdenas hörn, men det ledde till att buggysektionen blev sämre. De öppna områdena innebar att det alltid fanns små områden som såg ut att kunna innehålla något, så spelarna stannade och hoppade ur buggyn gång på gång för att leta. Det blev tjatigt och gjorde nivån tråkigare, så vi tog bort de utspridda belöningarna. Men nu uppstod ett nytt problem: hur informerar vi spelaren om när det är värt att lämna buggyn? Efter lite eftertanke kom vi fram till en regel: allt människobyggt skulle bjuda på spelmoment och belöningar för den utforskningslystna, medan helt naturliga områden skulle vara tomma. Vi kunde inte berätta det för spelaren, men det är något som gifter sig väl med mångas naturliga antaganden – och vi såg till att spegla de antagandena med områden som det här."
N/A3962"#commentary\cn_045_gas_station.mp3" "[ Jeff Lane ] Vi hade stora planer för den här striden. Vi tänkte bygga en bensinmack som spelaren skulle strida i – och antagligen tända på bensintankarna så att allt började brinna. Vi tänkte oss att spelaren skulle köra iväg från ett rasande inferno. Dock var budgeten och prestandan väldigt begränsad år 2003 och stationen behövde bli mindre och enklare för att passa kustens stora banor. Det hände inget med planerna för ett dynamiskt brandsystem, och det var inte längre rimligt att skapa det – det finns alltid en gräns för hur mycket jobb som är rimligt att lägga ner för en enda strid. Det enda som finns kvar av vår ursprungliga explosion de explosiva tankarna."
N/A3963"#commentary\cn_046_buggy_introduction.mp3" "[ John Cook ] Vi ville introducera buggyn på ett roligare sätt än att bara låta spelarna hoppa in och köra iväg. Det hjälpte lyftkranen till med. Vi behövde lära spelarna hur man vänder på buggyn om den hamnar upp och ner, och den här sekvensen tvingade in dem i den situationen. Träning under press är alltid knepigt, men vi ville att myrlejonenen skulle bli en anledning att hålla sig i buggyn. Därför höll vi myrlejonhotet aktivt och placerade ut medborgare med monterade vapen som understöd. En liten bonus: Spelarna får uppleva hur det är att lyftas av kranen innan de använder den."
N/A3964"#commentary\cn_047_crossbow.mp3" "[ John Cook ] Det är här spelarna för första gången kan få armborstet, och så här i efterhand är det lite förvånande att vi inte gjorde det obligatoriskt. Det är nämligen helt möjligt att bara köra förbi. För att minska risken för det designade vi vägspärren och utsiktsplatsen som en uppmaning till spelarna om att kliva ur buggyn och se armborstet och föremålslådan. Speltesterna visade att nästan alla spelare stannade och tog vapnet, men det här är ett fall där skillnaden mellan speltest och faktiska spelsessioner kan vara viktig. Speltestare som spelat sedan början av kusten kanske inte är lika trötta på utforskning som folk som spelat sedan spelets början. Därför lade vi ut ett andra armborst några banor senare, rätt i spelarnas väg i Nova Prospekt."
N/A3965"#commentary\cn_048_rollermines.mp3" "[ Josh Weier ] Vi skapade rullminorna eftersom det behövdes en fiende som var ett hot mot spelaren i buggyn. Spelaren i fordonet var i princip helt fysiskt simulerad, så vi tyckte det skulle bli intressant med en fysiskt simulerad fiende. Spinnsågen hade redan visat oss hur det här tänket kunde leda till en fiende med många intressanta interaktioner med världen. Därför byggde vi rullminan, en boll vars rörelse drivs helt av vridmomentet den skapar mot sig själv – och justerade beteendet tills den var kul att köra mot. Rullminor är inte särskilt farliga mot buggyn, men om man drar på sig för många kan de bli det – särskilt nära klippor. Vi såg även till att de funkar bra när spelaren är till fots, så att våra nivådesigner kunde använda dem till fler strider."
N/A3966"#commentary\cn_049_sandtrap_thumper.mp3" "[ Laura Dubuk ] De explosiva tunnorna är till för att användas mot myrlejon medan spelarna står säkert inom dunkarens skydd. Vi använder även det här som ledtråd inför den kommande striden mot myrlejonvakten, där spelarna ofta använder liknande taktiker för att vinna striden. Frivilliga handlingar, som att kasta explosiva föremål med gravitationsvapnet, kan glömmas bort om de inte används regelbundet. Eftersom vi gett spelarna massor av anfallsalternativ är det inte garanterat att de använt den här förmågan nyligen. Här ger vi därför en ledtråd om att plocka fram den förmågan innan de möter vakten."
N/A3967"#commentary\cn_050_coast_kickoff.mp3" "[ Marc Laidlaw ] Den här scenen blev till rätt sent i utvecklingen, för att koppla ihop Ravenholm och kusten. Märker du ett mönster? Ganska mycket av det som binder ihop spelen tillkommer mot slutet. I det här fallet fick vi ta genvägar där det gick – vi hade inte ens tid att animera Alyx på skärmen. Den här sortens scener är alltid svåra att göra något intressant av, och här lyckades vi inte. Det är ett bra exempel på vad som händer när man behandlar NPC:er som skyltar, utan att ge dem eller scenen karaktär. Resultatet är något som inte blir särskilt minnesvärt, och som visar spelets sömmar. Så är det med utveckling – man har begränsat med tid och måste välja vad man gör av den. Kleiners och Elis laboratorier var mycket viktigare, så vi fokuserade på dem."
N/A3968"#commentary\cn_051_odessa_cubbage.mp3" "[ Marc Laidlaw ] Odessa Cubbage är ett bra exempel på en sidokaraktär som funkar. Han är en rolig typ med roliga karaktärsdrag, och bor liksom i sin egen lilla bubbla. Eftersom han inte lämnar sitt scenario kunde vi göra honom överdriven, så att han sticker ut. Vi började med hans modell, som återanvändes från en bortklippt del av spelet, och döpte honom efter ämnesraden i ett skräppostmeddelande vi fick. Modellen var ursprungligen till för en norsk fiskare och passade inte riktigt som en engelsman, så vi gav honom en mustasch – och där uppstod karaktären Odessa. Han är en bluff. Allt med honom är fejk – accenten, mustaschen, alltihop. Han skulle aldrig försätta sig själv i fara, vilket gör honom perfekt i rollen som han som ger Gordon raketgeväret och förklarar hur man använder det."
N/A3969"#commentary\cn_052_28_transitions_later.mp3" "[ Marc Laidlaw ] När vi hade knåpat ihop några nivåer med mörka tunnlar som transportsträckor insåg vi att vi kunde överraska spelarna genom att bygga något som verkade vara en transportsträcka men visade sig innehålla något annat. Som alla andra såg vi filmen 28 dagar senare år 2002, och eftersom vi älskade den ville vi skapa en eskalerande zombiestrid i en av våra mörka tunnlar. Vi satte ihop den snabbt och blev nöjda med resultatet. Flera år senare träffade vi Alex Garland, som skrev filmens manus. Han hade spelat och gillar Half-Life 2, och vi berättade att hans film inspirerat den här delen av spelet."
N/A3970"#commentary\cn_053_finest_mind_of_his_generation.mp3" "[ Marc Laidlaw ] Här har vi ännu en liten mellansekvens som fungerade bra. Det enda vi behövde göra här var att lära spelaren att hålla sig borta från sanden. I tidigare scener fokuserade vi på att scenen bara skulle funka, men när vi hade kommit hit var vi mer bekväma och ville lägga lite extra eftertanke bakom de här ögonblicken. När vi gjorde det blev karaktärerna mer än bara skyltar – något mer intressant och underhållande. Efter att spelet släpptes fick Lazlo en hängiven skara fans: en påminnelse om hur svårt det är att förtusäga vad spelarna kommer fästa sig vid."
N/A3971"#commentary\cn_054_bridge_playtesting.mp3" "[ Matt Boone ] Bron var alltid en höjdpunkt under speltester och testarna reagerade alltid starkt på den. Man kunde i deras rörelser se spänningen de kände när de långsamt tog sig över balkarna. Vi lade till fler och fler utmaningar här och speltesten blev gradvis mer underhållande att titta på. Allt från tåget som dundrar över bron och skakar spelaren till en gömd huvudkrabba i ett till synes säkert skjul halvvägs genom. Vi fick lite dåligt samvete när vi njöt av speltestarnas påtagliga stress, men vi var inte fullständiga monster. När spelarna tagit sig över bron andades de ut, stängde av combine-skölden och insåg att de behövde ta sig tillbaka via undersidan. Vi var rädda att spelarna skulle få det tråkigt på tillbakavägen och lade till ett kanonskepp för att hålla dem sällskap ute på balkarna."
N/A3972"#commentary\cn_055_thumper_final_stage.mp3" "[ Matt Boone ] Vi gillade dunkarnas sista fas, där de får ett omvänt syfte: istället för att hålla en säker blockerar de ens myrlejonarmé. Fast vi borde nog ha lärt spelaren mer om hur dunkarna funkar innan det här partiet. Det var okej att spelarna bara förstod dunkarna delvis på de tidigare kustnivåerna, men nu står mer på spel när spelarna provar på insektsbetet för första gången. Spelare som inte fattar att den här första dunkaren förhindrar deras myrlejons framfart kan missförstå hur insektsbetet funkar. Om de kastar insektsbete på soldater i den första bunkern och det inte dyker upp några myrlejon kanske de tror att insektsbetet inte går att lita på eller funkar som förväntat, vilket gör att de byter tillbaka till vanliga vapen istället."
N/A3973"#commentary\cn_056_buggy_tools.mp3" "[ Matt Wright ] Vi ville göra buggyn till mer än bara ett transportmedel, så vi bestämde oss för att fästa ett vapen på den. Vi valde tau-kanonen, ett vapen från Half-Life 1 som vi gillade men inte hittat någon plats för i Half-Life 2. Tau-kanonen kan skjuta genom väggar, vilket gör nivådesignen knepig, så vi begränsade den till kustdelen. När man lägger till vapen som kan skjuta genom väggar blir nivådesignen mycket svårare. Vi monterade även en ammunitionslåda på baksidan av buggyn så att spelaren får obegränsad kpistammunition på kusten. Det kom till särskild nytta för speltestare som hade problem med det oändliga antal myrlejon som kom upp ur sanden."
N/A3974"#commentary\cn_057_antlion_guard.mp3" "[ Matt Wright ] I sällsynta fall kunde spelarna inte döda myrlejonvakten i den här arenan. Det kunde inträffa om de hade slut på ammunition och använt fysikobjekten fel så det inte gick att kasta något med gravitationsvapnet. För att lösa problemet lade vi till en medborgare med ett monterat vapen ovanför porten, så att spelare som kört fast skulle kunna förlita sig på att medborgaren dödar vakten."
N/A3975"#commentary\cn_058_terrain_and_performance.mp3" "[ Mike Dussault ] Vår prestandabudget var ofta en rejäl begränsning när det kom till strider, särskilt strider i terräng. När NPC:er rör sig gör de många små kontroller i omgivningen för att se om de kan följa sin valda väg på ett säkert sätt. Man kan se det som att de är blinda och viftar med en käpp framför sig för att kontrollera var de kan gå. Kontrollernas prestandakostnad höjs i takt med att världen blir mer kompex. Vårt terrängsystem skapar ojämna ytor med många polygoner – många fler än de helt platta golven på annat håll. Det gör att NPC:ers förflyttning på kustens terräng är mer resurskrävande än i andra områden, och den begränsningen låg till grund för stridernas storlek i den här delen av spelet."
N/A3976"#commentary\cn_059_area_portals.mp3" "[ Mike Dussault ] En av prestandautmaningarna med kusten var att försöka hantera vidöppna utrymmen som innehöll byggnader med många detaljer inuti sig – i alla fall med 2003 års mått. När spelarna var utomhus ville vi ägna så mycket som möjligt av budgeten åt att rendera utomhusmiljön, utan att tappa resurser till interiörerna. Dock kunde spelarna fortfarande se in i byggnaderna, om vi valde att spika för alla fönster och dörrar. För att lösa problemet uppfann vi så kallade områdesportaler och placerade dem i alla öppna fönster och dörrar. En områdesportal ritar en platt bild av byggnadens interiör i förväg. När spelaren befinner sig en bit bort visar områdesportalen den här förritade bilden över fönstret eller dörren, så vi slipper rendera den faktiska interiören. När spelaren närmar sig går vi smidigt över mellan områdesportalens bild och byggnadens faktiska innehåll. Genom att använda områdesportalerna smart kunde vi nå våra prestandamål på kusten – i kombination med dörrar som stängde sig själva bakom en."
N/A3977"#commentary\cn_060_buggy_removal.mp3" "[ Miles Estes] När vi nådde punkten där vi ville att spelaren skulle lämna buggyn bakom sig behövde vi vara extremt tydliga med det. Längs kusten hade spelarna lämnat buggyn och sedan återvänt till den, så vi upptäckte att speltestarna försökte ta med sig den om det fanns minsta möjlighet till det. Den här lilla garagescenen finns främst för att tydligt visa att spelaren kört färdigt och ska fortsätta till fots."
N/A3978"#commentary\cn_061_d2_coast_04.mp3" "[ Randy Lundeen ] Den här kartan var den första delen av kusten vi byggde, innan lyftkranen och de andra inslagen fanns. Den torrlagda havsbottnen och de rostiga skeppen var bland de första visuella inslag vi skapade. Flera år senare visade vi upp kartan i vår demonstration på E3 2003, men vi höll fortfarande på att bena ut spelmekaniken. Därför blev den demonstrationen ett bra mål att sträva mot när vi byggde resten av kusten."
N/A3979"#commentary\cn_062_transition_tunnels.mp3" "[ Randy Lundeen ] När vi byggde kusten var vi tvungna att komma på ett sätt att hantera övergångar mellan nivåer. För att gå från en nivå till en annan måste vi spara allt i övergångsutrymmet när spelaren lämnar den första nivån och återställa det i den andra nivån när den har laddats. Det är viktigt att vi sparar och återställer allt som är synligt för spelaren i övergångsområdet, även om det ligger utanför själva utrymmet i sig. Därför satsar vi på att hålla övergångsutrymmena så små och avstängda som möjligt. I större delen av spelet fungerar ett litet rum bra i det här syftet. På kusten behövde vi en annan lösning. Efter att ha experimenterat lite bestämde vi oss för mörka tunnlar. Förutom att de kunde återanvändas på ett trovärdigt sätt lät de oss lägga till ett starkt ljus i slutet för att dölja att vi inte kan rendera det som finns framför spelaren, eftersom det ligger på en helt annan nivå."
N/A3980"#commentary\cn_063_sniper_alley.mp3" "[ Robin Walker ] Den här delen av spelet lades till sent i utvecklingen, efter att vi lagt Elis labb och Ravenholm före kustpartiet. Det är lätt att tro att vi byggde spelet på linjärt vis, men vi delade faktiskt upp utvecklingen i tre olika delar och började till stor del i mitten. Varje grupp såg till att verkligen få grepp om sin dels huvudfokus innan de fortsatte. När vi väl fått till ett grovt utkast av hela spelet gick vi tillbaka till varje enskild del och finslipade den genom att lägga till lyckade grejer från andra områden och ta bort sådant som inte funkade. I vissa fall, som Ravenholm, togs hela sjok bort. Och sen när Ravenholm flyttades behövde vi något som kopplade det partiet till kusten: området du går in i nu. Eftersom vi hade ont om tid byggdes den här delen med befintliga, beprövade spelelement som krypskyttar och combine-soldater."
N/A3981"#commentary\cn_064_battery_finding.mp3" "[ Robin Walker ] Eftersom Half-Life 2 har fler objekt än ettan överlag kände vi att det skulle vara kul att låta spelarna leta efter ett särskilt föremål, särskilt om det fanns en logik bakom var det låg. Spelarna skulle antingen kunna hitta saken genom att iaktta och slutleda eller genom att bara finkamma området grundligt. Och eftersom vi redan hade modeller för bilar och batterier kändes det naturligt att skapa ett litet skrotupplag att utforska. Vi gömde även ett par extrabatterier på lite oväntade ställen för de som valde finkamningsmetoden. Och precis som i andra föremålsbaserade pussel måste det gå att lösa även om man tappar batterierna. Du kan prova att kasta ut alla för klippan och se vad som händer."
N/A3982"#commentary\cn_065_boathouse.mp3" "[ Scott Dalton ] I Half-Life 1 märkte vi att det är givande med scenarier där olika AI-fiender slåss mot varandra. Det är kul för spelarna att titta på, och det är mycket lättare att få koll på fiendens beteende när man inte själv är i fara. Den här första striden mellan myrlejon och combine-soldater är designad för att ge en nåt kul att köra in i med buggyn, men den lyfter också fram dunkaren. Att som spelare se soldaterna försvara sig mot myrlejonen med dunkaren gör förhoppningsvis att man förstår vad den är till för. Det är bra att soldaterna visar värdet av att hålla sig nära dunkaren när man kämpar mot myrlejonen."
N/A3983"#commentary\cn_066_buggy_theft.mp3" "[ Scott Dalton ] När vi byggde slutet av kusten kom vi på att combine borde stjäla spelarens buggy. Det kanske inte känns jättelogiskt, men efter en massa speltestning där vi såg hur spelarna fäste sig vid buggyn ville vi leka lite med den känslomässiga kopplingen. När vi lagt till stölden började vissa speltestare skrika argt på combine för att de stal fordonet – ett tecken på att vi lyckats. Soldaten som skjuter på en från klippan är bara där för att man ska titta upp, vilket triggar ett så kallat blickmål och spawnar droppskeppet med buggyn. Nu när vi kollar på sekvensen 20 år senare känns alltihop väldigt fånigt."
N/A3984"#commentary\cn_067_snipers.mp3" "[ Ted Backman ] Half-Life 2-teamet var inte särskilt stort, så vi försökte alltid få till nya spelupplägg utan höga kostnader för att ta fram material. Krypskytten är ett bra exempel. Den har ingen riktig modell – bara en laserstråle – så den krävde varken grafik- eller animationsarbete. När den dör spawnar den bara en trasdocka av en combine-soldat och kastar ut den ur fönstret. Men trots enkelheten fick vi till ganska unika spelmoment. Vi är extra nöjda med hur skytten interagerar med fysikobjekten i spelvärlden. Som spelare är man van vid att dra fördel av explosiva saker nära fiender, så det kändes rätt med en fiende som vänder på det konceptet när spelaren tar skydd."
N/A3985"#commentary\cn_068_buggy_model.mp3" "[ Ted Backman ] Buggyns modell gick igenom många olika stadier innan vi fick till slutversionen. Vi provade designer som både kändes rätt sett till stil och fysiksimulering men fick ett oväntat problem: många speltestare, inklusive FPS-veteraner, blev åksjuka när de körde fordonet. Vi märkte att justeringar i simuleringen och ändringar av själva buggymodellen hjälpte – ju mer modellen var i vägen för det man ser av spelvärlden, desto värre blev åksjukan. Så vi tog bort fler och fler delar av modellen tills folk slutade må illa. Möjligheten att kunna se marken, eftersom underredet saknas, gjorde väldigt stor skillnad."
N/A3986"#commentary\cn_069_antlion_design.mp3" "[ Ted Backman ] I vårt tidiga arbete med spelet funderade vi på att ha med flera olika utomjordiska raser, där combine bara var en av dem. En av de andra raserna var ett religiöst insektsfolk, och myrlejonen tillhörde dem. Senare, i takt med att vi byggde kusten, började vi se myrlejonen som skadedjur som kommit genom Xen-portaler tillsammans med huvudkrabbor och andra varelser. De är inte från Xen, men de förpestar alla världar de besöker – lite som kackerlackor."
N/A3987"#commentary\cn_070_explosive_barrels.mp3" "[ Brian Jacobson ] Här ser vi för första gången explosiva tunnor – en vanlig syn i dåtidens FPS-spel, men med en liten twist: ett andra pistolskott sätter eld på tunnan och får den att sprängas efter en viss tid. Ett tredje skott får den att sprängas direkt. På så sätt kan spelaren antingen fördröja explosionen eller detonera tunnan omedelbart beroende på situation. Man kan till exempel låta en långhals äta en tunna och sedan skjuta den två gånger för att smidigt få bort en hel klunga. Den fördröja explosionen låter en dessutom få till mycket mer intressanta kedjeraktioner mellan tunnor. De här föremålen blev väldigt omtyckta bland spelarna, och våra bandesigner gillade dem också så mycket att de ville ha tunnor precis överallt."
N/A3988"#commentary\cn_071_ragdoll_magnets.mp3" "[ Dario Casali ] Fysiken i Half-Life 2 lät oss göra striderna ännu mer spännande. När fienderna missar spelaren har vi till exempel sett till att skotten omdirigeras till förstörbara objekt i närheten, vilket höjer stämningen och ger en actionfilmskänsla. Vi har även låtit fysiken ge en del ledtrådar. Vi skapade vad vi kallar ”trasdocksmagneter” som får lik att ramla på intressanta och dramatiska sätt – ner för avsatser och rakt framför tåg, till exempel."
N/A3989"#commentary\cn_072_helicopter_peekaboo.mp3" "[ Dave Riller ] Combine-attackhelikoptern var något vi ville ha som huvudfiende genom hela kapitlet. Den blev som en karaktär i sig. Om du lyssnar och tittar upp här hör du helikopterns motor och ser hur den flyger bort längs tågspåren. Det är en första glimt som fungerar som en liten antydan om vad som väntar, och fienden blir mer och mer närvarande – tills man står där och måste tampas med den."
N/A3990"#commentary\cn_073_iterative_passes.mp3" "[ David Speyrer ] Vissa kapitel i spelet, som när man tar sig runt till fots bland kanalerna och i Ravenholm, utvecklades i olika omgångar av olika kabaler. Vi kände att den sortens utvecklingsprocess skulle göra upplevelsen mer varierad och leda till fler intressanta ögonblick, och varje kabal lade till sina egna unika grejer på kartorna. I delen där man går till fots bland kanalerna fokuserade de första utvecklingsomgångarna på den grafiska stilen och spelarens väg framåt samt upplevelsen i stora drag och några viktigare händelser. Men i hela teamets alfaspeltest såg vi att det inte var tillräckligt spännande här. I andra omgången gick vi tillbaka till kartan och fokuserade helt på att höja stämningen och få till fler bra ögonblick."
N/A3991"#commentary\cn_075_pistol_design.mp3" "[ Josh Weier ] Standardpistolen är ett viktigt verktyg som inte bara fungerar som ens första distansvapen utan även är ett sätt att interagera med fysik och förstörbara objekt på säkert avstånd genom hela spelet. För att den ska ha bra respons och kännas kul att använda har den en mekanik som bara den har i spelet: den skjuter precis så snabbt som man själv trycker på skjutknappen, så att man får omedelbar respons och skjuter snabbare ju snabbare man trycker."
N/A3992"#commentary\cn_076_shatterglass.mp3" "[ Josh Weier ] När vi designade tidiga banor där spelaren har färre saker till sitt förfogande kom vi på att det är minst lika spännande att lyfta fram nya tekniska grejer i spelet, som med det förstörbara glaset här. För att få till krosseffekten delade vi in glaset i ett rutnät av mindre kvadrater så att vi kunde se vilka som var intakta respektive förstörda och kunna krossa större sektioner när tillräckligt många kvadrater är bortkopplade från varandra. Varje kvadrat renderades med en unik textur baserat på de intilliggande rutornas status, vilket gav de taggiga kanterna mellan krossat och intakt glas. Det är numera vanligt att kunna krossa glas i spel, men det var det inte när vi skapade Half-Life 2 – och vi är väldigt stolta över hur realistiskt och dynamiskt det får spelet att kännas."
N/A3993"#commentary\cn_077_lambda_caches.mp3" "[ Laura Dubuk ] Tekniskt sett finns det första lambdaförrådet i Kleiners labb, men det här är första gången spelaren hittar ett helt själv. Vi lade till förråden för att uppmuntra till utforskning och ge en antydan om var dolda resurser går att hitta, och i berättelsen förklaras det att motståndsrörelsen satt ut dem som del av sitt uppror. I Half-Life bestämdes resurslådornas innehåll av bandesignen. I HL2 introducerade vi föremålslådor som ger en det man har ont om där och då, baserat på resursmål bandesignern satt."
N/A3994"#commentary\cn_078_scanners.mp3" "[ Kerry Davis ] Skannrarna var en knepig speldesignutmaning. Vi gillade hur deras dystopiska framtoning visade att combine-ockupationen är ett förtryckande övervakningssamhälle, men vi ville inte att de skulle skjuta på spelarna. Vi insåg att det inte skulle bli roligt att sikta upp mot himlen för att träffa en liten, rörlig fiende som alltid har ett övertag eftersom den befinner sig på högre höjd. Eftersom vi gillade rollen de spelar i berättelsen bestämde vi att de i strid agerar främst som ögon som varnar fiender i närheten om spelarens närvaro – en funktion vi förstärkte med ljudeffekter från soldaterna. Utöver det kunde de bara trakassera spelarna med starka ljus och ibland göra ett dykanfall om de tagit tillräckligt med skada."
N/A3995"#commentary\cn_079_surface_properties.mp3" "[ Ariel Diaz ] Vi spelar särskilda fotstegsljud när spelaren går på den hala leran. Det här var ett system som kallades ”ytegenskaper”, som använde sig av materialtypen för att avgöra vilka ljud och andra effekter som skulle användas när ytorna gicks eller sköts på. Tidigare i utvecklingen hade vi en effekt som saktade ner spelares rörelser på leriga ytor. Men vi tog bort det till fullversionen, eftersom vi kände att det gjorde spelet för svårt."
N/A3996"#commentary\cn_080_combat_entrances.mp3" "[ Dario Casali ] Det känns alltid lite konstigt att runda ett hörn och komma in i ett nytt område där det står fiender. Det får världen att kännas mer som en skjutbana än en levande värld. Därför ville vi introducera fiender i strider på mer spännande och dynamiska sätt, som får det att verka som att de har planer och avsikter – som om de hade en plan för Gordon redan innan han dök upp. Metro-poliserna i den här scenen hoppar ner via skriptade sekvenser, och senare i spelet har vi fiender som firar ner sig i rep på liknande vis. Det spelar ingen roll varifrån de faktiskt kommer, eftersom spelarnas fantasi tar hand om den biten. Vi kom fram till att striderna ska ha en historia bakom sig – ett bakhåll, en överraskning, ett anfall. Alla de här scenarier använder liknande fiende-AI, men kändes olika för speltestarna."
N/A3997"#commentary\cn_081_mounted_gun_gallery.mp3" "[ Dave Riller ] Det sker lite olika grejer i den här scenen: tornet som skjuter på de förstörbara lådorna lär spelarna att inte ta sig an hotet direkt, utan att gå via kloakerna för att besegra det. När spelarna kommer fram till tornet gillar de att använda det i en stridssekvens med en våg av combine-soldater och dykbombande skannrar. Vi introducerar även den robotskjutande combine-pansarbilen som driver spelarna vidare och dyker upp senare i kapitlet."
N/A3998"#commentary\cn_082_barnacle_bowling.mp3" "[ Josh Weier ] Det här är ett bra exempel på hur olika designelement möts i ett nätverk av interaktioner och blir ett minnesvärt scenario för spelaren. Vi har långhalsar, vår fysiksimulering, hala leriga ytor och – sist men inte minst – explosiva tunnor. Man har stött på de här grejerna individuellt, men här möts de naturligt i något som vi kallar ”långhalsbowling”."
N/A3999"#commentary\cn_083_barnacle_introduction.mp3" "[ Mike Dussault ] Långhalsar kan vara förvirrande när man först stöter på dem, så vi ville introducera dem på ett sätt som visar deras beteende på säkert avstånd. Vi bestämde oss för att skapa en scen som påminner om ett naturprogram, med rovdjuret och dess villebråd. Som alltid krävs det mycket arbete för att försäkra sig om att spelaren ser scener som den här."
N/A4000"#commentary\cn_084_physics_in_puzzles.mp3" "[ Eric Smith ] Ofta är enkel mekanik man stöter på tidigt i spelet tagen från mer komplexa grejer längre fram, så att det blir som en sorts träning. Gungbrädepusslet, det första fysikbaserade pusslet i spelet, baserar sig på ett mer komplicerat pussel med en tvättmaskin i kanalerna senare. Gungbrädan använder samma princip med massa och ramper, men på ett enklare sätt som spelare kan interagera direkt med – vilket hjälper dem att förstå spelets fysik och gör det lättare att hantera senare pussel. Det här pusslet visar även fysiksystemets analoga natur, där placeringen av cementblock och spelarens egna vikt båda blir del av lösningen."
N/A4001"#commentary\cn_085_combine_attack_helicopter.mp3" "[ Brian Jacobson ] Spelarna har fått se glimtar av den tidigare, men det är här vi introducerar kanalkapitlets huvudboss: combine-attackhelikoptern. Helikoptern förstör spelarens skydd helt brutalt och tvingar spelaren att ta sig framåt för att inte bli nedskjuten. Vi ville att sekvensen skulle kännas spännande och hotfull. Det var viktigt att helikoptern upplevs som för kraftfull för att gå på direkt, och så skulle vi ha samma intensitet genom kanalerna fram till slutstriden i reservoaren. För att uppnå det begränsade vi helikopterns rörelser rejält baserat på våra mål i speldesignen. På den här kartan, som är designad som en spurt från skydd till skydd under beskjutning från helikoptern, har vi skapat en ringformad väg i himlen, ovanför arenan. Helikoptern färdas alltid till den punkt på ringen som ligger längst från spelaren, vilket håller den synlig och gör det lättare för oss att placera ut skydd på lämpliga platser."
N/A4002"#commentary\cn_087_explosive_barrel_factory.mp3" "[ David Speyrer ] Det här rummet, som har helt absurt många explosiva tunnor, gav upphov till en del diskussioner inom teamet kring hur viktig världens trovärdighet var. Ärligt talat är bara en enda explosiv tunna i sig orealistiskt – i verkligheten sprängs inte tunnor, inte ens om man skjuter på dem."
N/A4003"#commentary\cn_088_rising_water.mp3" "[ Dhabih Eng ] Den flytande bron och träspolarna här visar hur spelaren kan använda flytkraft som redskap. Det är inte riktigt ett pussel, utan bara ett sätt för spelaren att ha kul med fysiksystemet – men senare återbesöker vi det här spelelementet när spelaren ska bygga en ramp åt luftbåten i kanalerna."
N/A4004"#commentary\cn_089_manhack_matt.mp3" "[ John Morello ] Den här snubben kallade vi ”spinnsågs-Matt”. Vi ville ge spelarna intrycket att det bor hundratals invånare i Stad 17:s gömda skrymslen och vår. Här var det ett tag sedan spelaren sist sett en medborgare och vi ville förklara betydelsen av spinnsågarna, som var den första fysikbaserade fiende vi skapade. I vårt första koncept hade staden en arkadhall där spelarna kunde flyga runt med spinnsågar och attackera virtuella medborgare. Senare skulle spelarna upptäcka att spinnsågarna var verkliga, och så även medborgarna. När vi jobbat mer med combine-ockupationen kändes det som att arkadhallen inte passade in, så till sist ströks den."
N/A4005"#commentary\cn_090_fighting_motion_sickness.mp3" "[ David Speyrer ] Tidigt i speltestandet blev många spelare åksjuka när de körde luftbåten. När vi försökte lösa det upptäckte vi att flera faktorer bidrog till problemet. Vi insåg att det hjälpte om luftbåten tog upp mindre av synfältet, så vi gjorde om modellen flera gånger för att lösa det. Det hjälpte att ha en stabil bildfrekvens, så det var viktigt att hålla koll på prestandan i de här delarna. Den absolut viktigaste faktorn var att ta bort kamerarullning för att få en mer stabil horisont vad luftbåten än gjorde. En av våra programmerare var extremt känslig för åksjuka och erbjöd sig att göra speltester flera gånger för att utvärdera våra framsteg. Jag är rätt säker på att det blev minst en spya under speltesterna, och den ädla uppoffringen uppskattades enormt."
N/A4006"#commentary\cn_091_headcrab_canisters.mp3" "[ Jeff Lane ] Använda huvudkrabbskartescher dyker upp senare i Ravenholm, så vi valde att visa dem här för att visa hur de används av combine. Berättelsen här är att combine använder Xens varelser som vapen mot människorna. Nedgrävda huvudkrabbor lades till som ny grej i den här delen, som utökades till ett större område som föreställer en bosättning som decimerats av ett huvudkrabbsanfall."
N/A4007"#commentary\cn_092_airboat_intro.mp3" "[ John Morello ] Det är här spelaren får spelets första fordon: luftbåten. Vi ville skapa en trygg plats där spelarna kunde öva på att köra luftbåten så länge de ville innan de åkte vidare. Arenan är full av möjligheter till hopp och trick, och vi fyllde den med giftigt slem för att hålla spelarna i luftbåten längre och se till att de inte övergav fordonet och fortsatte till fots."
N/A4008"#commentary\cn_093_zombie_surprise.mp3" "[ Jeff Lane ] Det finns en liten läskig överraskning i det här kloakröret. Spelarna går in här, fokuserade och nyfikna, och så hoppar en zombie upp ur vattnet. Det skrämde nästan alltid livet ur speltestarna. En speltestare föll av stolen, och då kände vi att vi hade lyckats."
N/A4009"#commentary\cn_094_airboat_time.mp3" "[ Dave Riller ] Det tog ett tag att hitta rätt balans mellan tiden man spenderar i fordonet respektive till fots. När spelarna körde i full fart for de genom världen snabbt, och i de tidiga speltesterna kände vi att de missade utforskningen och spelets detaljer. Utforskning av världen är en av Half-Lifes viktigaste aspekter, och vi ville inte att fordonet skulle ta bort det. För att lösa problemet lade vi till olika platser där spelarna kunde kliva ut och titta runt i små detaljerade områden. När fysiksystemet utvecklades lärde vi oss olika sätt att utnyttja det. De här platserna gav spelarna möjlighet att upptäcka fysiken, exempelvis genom att kasta lådor i vattnet eller använda tunnor för att höja en ramp. Man fick chans att interagera med vatten och fysik på olika sätt."
N/A4010"#commentary\cn_095_floating_supplies.mp3" "[ Josh Weier ] I alfaspeltestet var kanalerna fulla med flytande förnödenhetslådor som spelarna kunde krossa med luftbåten för att få resurserna inuti. Det var lite väl ”speligt” men hjälpte oss få ett bra tempo i spelet genom att låta spelaren fylla på med förnödenheter under färden. För att få det att kännas mer trovärdigt ville vi berätta historien om hur de flytande lådorna hamnade på så smidiga ställen längs spelarens väg. Den här scenen med medborgare som kastar ner lådor säljer in den berättelsen och får kanalerna att kännas mer levande. Spelarna känner sig dessutom mer hjältemodiga och viktiga när det är så många karaktärer som hjälper dem längs vägen."
N/A4011"#commentary\cn_096_grenade_intro.mp3" "[ Brian Jacobson ] Vi tänkte oss den här combine-basen som både ett träningsområde och en lekplats för granater. Vi introducerar dem här, i oändliga förnödenhetslådor som visar att spelarna kan använda granater som de vill utan att de tar slut. Kör hårt, liksom. Striden här är regisserad för att leda soldat-AI:n mot skydd och ge spelarna bra möjligheter att använda granater. I slutet av området används samma teknik med oändliga granater för att hjälpa spelarna att lösa situationen med tornet – annars blir ett direkt anfall mycket svårare. Vi gav granaterna ett starkt rött ljus och ett partikelspår, vilket gör det mycket lättare för spelarna att följa deras väg – oavsett om de kastar dem eller väjer för combine-soldaters granater."
N/A4012"#commentary\cn_097_puzzle_layers.mp3" "[ Dave Riller ] Eftersom spelarna ofta är helt omedvetna om designerns avsikt, vilket vi ser som något bra, brukar de reagera på våra pussel på alla möjliga överraskande sätt. Även pussel vi tycker verkar enkla kan få folk att misslyckas gång på gång i jakt på lösningen. Så var det med det här pusslet för att öppna kanalportarna, vilket krävde många lager av ledtrådar och signaler. Det gnistrande hjulet visar att det är här man brukar öppna porten, men att det behövs någon annan metod. Några kråkor drar spelarens blick till lösningen – några balkar på en pendel. Eftersom granaterna hade introducerats utförligt ville vi att spelarna skulle kasta en för att förstöra träkonstruktionen, men det var inte tillräckligt uppenbart. Vi lade till exploderande tunnor som en tydligare ledtråd, men vissa spelare insåg inte att portarna hade öppnats när de löst pusslet, så de irrade runt i basen i jakt på en annan utgång. Därför behövde vi påminna dem om ursprungsproblemet: den trasiga porten. Vi lade till rök, larmsirenen och en snurrande lampa, och det var först då vi äntligen började få bra resultat i speltesten."
N/A4013"#commentary\cn_098_metrocop_strafing.mp3" "[ Doug Wood ] Den ursprungliga designen på luftbåtsnivåerna hade som syfte att utmana spelarna med tajta manövrar när metro-poliserna sätter press på dem. Polisernas eldmönster var tänkt att få spelarna att köra slalom runt skotten när de åkte fram, men i vår granskningsprocess – internt kallad ”övervakningen” – kände vissa speltestare sig frustrerade över att beskjutas utan möjlighet att skjuta tillbaka. De ville att luftbåten skulle kännas kraftfull och oslagbar. Baserat på den feedbacken lade vi prio på att spelaren skulle känna sig stark över att bjuda på en utmaning, så vi växlade från att väja för attacker till snabba strider, hög fart och att braka fram genom hinder."
N/A4014"#commentary\cn_100_mounted_gun.mp3" "[ Jeff Lane ] De monterade vapnen lades till här för att lära spelaren använda vapnet mot attackhelikoptern i den sista striden i reservoaren. Det behövdes eftersom helikoptern hittills hade varit osårbar mot spelarens arsenal, och vi var tvungna att visa att den kunde skadas med större vapen. Det här var bara någorlunda effektivt i speltesten med tanke på pressen spelaren utsätts för, så vi utvecklade partikeleffekter och ljud som finns där för att visa att man verkligen gör skada."
N/A4015"#commentary\cn_101_357_intro.mp3" "[ Josh Weier ] Magnumen har lägre elhastighet än den vanliga pistolen och är avsedd att avfyras på ett mer beräknat sätt, så att man gör enorm skada mot målet. Tidigare versioner av magnumen hade slumpmässig spridning, vilket vi tyckte passade en större pistol som väger tyngre och har en mindre känslig avtryckare. Det ledde dock till antiklimax när spelare siktade noga, bara för att missa till följd av precisionsstraffet. För att bemöta det såg vi till att den första kulan alltid är pricksäker, men att varje efterföljande skott har lägre precision när man skjuter snabbt."
N/A4016"#commentary\cn_102_helicopter_bombing_run.mp3" "[ Brian Jacobson ] Det här är ännu ett exempel på hur vi skapar faror i luftbåtspartierna. Helikoptern försöker hålla sig framför spelaren när den släpper bomber, och om spelaren vänder om så växlar den till att hovra och anfaller spelaren direkt. Under ett speltest råkade en bomb hamna mellan rörfogarna, vilket ledde till ett rätt filmiskt ögonblick. Speltestaren reagerade positivt, så teamet bestämde sig för att skripta det så att det skulle ske varje gång. Det här har blivit en viktig del av vår organiska designprocess: ibland råkar något coolt hända under ett speltest, så vi hittar ett sätt att få det att ske mer pålitligt."
N/A4017"#commentary\cn_103_smokestack_collapse.mp3" "[ Doug Wood ] När vi gjorde filmiska actionspel som det första Half-Life ville vi alltid få till stora, spektakulära förstörelsesekvenser, men vi lyckades aldrig riktigt. Half-Life 2:s fysik introducerade ett system för att förstöra små föremål, som lådor, i mindre delar – vilket fick oss att känna att vi ville göra något mycket större. Vi tog steget och experimenterade med att bryta upp en skorsten i delar medan den föll. Vi experimenterade med massorna tills det kändes bättre, förfinade modellen och lade till massor av rök och ljud för att göra effekten verklighetstrogen, och till sist hade vi vår stora spektakulära förstörelsescen. Fysiken gjorde att sekvensen knappt var möjlig på ett sätt som kanske känns rätt avlägset idag, men som kändes helt otroligt då. Eftersom simuleringen var unik varje gång den kördes behövde vi se till att bråte inte helt blockerade spelarens väg. När vi lyckades med den här sekvensen fick vi blodad tand för de mycket mer avancerade filmiska förstörelseeffekterna i Episode Two."
N/A4018"#commentary\cn_104_washing_machine_puzzle.mp3" "[ David Speyrer ] Vi skapade fysikpusslet med tvättmaskinen sent i utvecklingen, efter att speltesterna visade att spelarna behövde en paus från helikopterns ständiga hot. Att växla tempo på det här sättet kan förbättra spelets höjdpunkter eftersom spelarnas känslotillstånd liksom återställs, vilket motverkar utmattning och uttråkning. Vi såg det som positivt att spelarna reagerade så starkt på allt arbete vi lagt på att få helikoptern att kännas som ett riktigt hot, men om vi inte lyckades hantera deras stress rätt skulle de tröttna och se allt som enformigt istället för spännande. Först körde folk snabbt genom det här området, men eftersom kanalen har så trevligt solljus och är så fint byggd här tyckte vi att det var en bra plats att låta spelarna ta en paus från all action och lösa ett pussel i lugn och ro. Själva pusslet, som var det första med massor och taljor, inspirerade andra fysiknavigeringspussel i spelet."
N/A4019"#commentary\cn_105_airboat_changeup.mp3" "[ Jeff Lane ] Speltestarna sa att luftbåtspartierna gärna fick vara mer varierade. Fram till den här punkten hade spelarna inget bra sätt att slå tillbaka mot helikoptern och andra fiender, så det kändes rätt att introducera ett nytt vapen och på så vis ändra tempot och förbereda inför det som väntade. I de efterföljande områdena lade vi till skytteträning för att bekanta spelarna med sitt nya vapen. Den extra fysikkraften på luftkanonens projektiler fick målen att flyga iväg och kanonen att kännas mycket starkare än allt annat i spelarens arsenal. Trots det trodde många speltestare att det inte gick att skada helikoptern med den när helikopterstriden testades. De märkte inte vårt försök att visa att helikoptern tog skada av combines monterade vapen tidigare. För att lösa det gjorde vi det mest självklara: placerade helikoptern direkt utanför tunneln man får kanonen i och gjorde det extremt tydligt att man kan och bör skjuta den. Det funkade."
N/A4020"#commentary\cn_106_donkey_kong_barrel_ramp.mp3" "[ Eric Smith ] Det här området, dräneringsrampen, var till en början bara en bit intressant arkitektur på nivån. Under speltesten märkte vi snabbt hur roligt det var att köra luftbåten upp och runt lutningen, så vi lade till fler element för att förhöja den upplevelsen. Bland annat lade vi in metro-poliser som släpper ner tunnor mot spelaren, som en blinkning till det klassiska arkadspelet Donkey Kong."
N/A4021"#commentary\cn_107_lambda_cache_interlude.mp3" "[ Danika Rogers ] Half-Life-spel är i slutändan linjära upplevelser, men vi letar alltid efter sätt att bryta upp spelarens självklara väg och göra vissa nivåer icke-linjära. Det här lambdaförrådet, som ersattes med ett zombie- och huvudkrabbanfall, var helt valfritt och byggdes för att göra den här delen av kanalfärden mindre linjär."
N/A4022"#commentary\cn_108_skybox_time_of_day.mp3" "[ Eric Kirchmer ] Färgen på himlen och dimman ändras gradvis under kapitlet. Det ska visuellt representera hur tiden förflyter när spelaren färdas genom kanalerna och kapitlet i sig. Två dimfärger i motsatta riktningar skapar illusionen av solens sneda vinkel. Här ser man att det närmar sig solnedgång. Det här kulminerar i helikopterstridsarenan, där solen går ner och Ravenholm syns i fjärran."
N/A4023"#commentary\cn_109_helicopter_megabomb_origin.mp3" "[ Brian Jacobson ] Helikopterns megabombattack baserar sig på en bugg som uppstod när en programmerare råkade ta bort väntetiden för bombanfall, vilket resulterade i att helikoptern släppte hundratals bomber på en gång. Det såg så coolt ut att vi bestämde oss för att ha kvar det i den slutgiltiga versionen."
N/A4024"#commentary\cn_110_helicopter_final_battle.mp3" "[ Dave Riller ] Vi designade det här området som en arena för den sista striden mellan spelaren och combine-attackhelikoptern. Det är en chans att äntligen eliminera den obevekliga fiende som jagat en sedan flykten under jord efter Kleiners labb. Vi gjorde många versioner av området för att få till det. Det behövde finnas gott om plats för snabba fordonsstrider, ett smidigt rörelseflöde med tydliga vägval och pålitlig prestanda. Vi satsade även på visuell tydlighet som passar för strider – slående, men inte för plottrigt – och att se till att det skulle bli en minnesvärd syn när helikoptern väl förstörts."
N/A4025"#commentary\cn_111_airboat_wreckage.mp3" "[ David Speyrer ] I första versionen förstördes luftbåten i hoppet över dammen, så den här nivån började med att spelaren befann sig i vraket av sin älskade luftbåt. När hela teamet testade spelet kände folk sig besvikna över att förlora fordonet de hade lagt så mycket tid på. Det var många interna debatter kring om den känslan av förlust var viktig eller inte. I slutändan valde vi att lämna luftbåten intakt för att göra det möjligt för spelaren att återförenas med den en vacker dag. Vissa hävdar att båten fortfarande väntar på en där ute."
N/A4026"#commentary\cn_112_arena_exit_gate.mp3" "[ Quintin Doroquez ] Hjulmekanismen som hissar upp porten lades till för att tvinga folk att besegra helikoptern innan de går vidare. Vi brukar prata om att vi lägger upp ”portar” för spelarna – vi använder designelement för att förhindra att de går vidare innan de klarat en uppgift. Här görs det med en bokstavlig port."
N/A4027"#commentary\cn_113_blocking_tutorials.mp3" "[ Adrian Finol ] Ibland måste vi försäkra oss om att spelaren har lärt sig nåt, och standardmetoden – inom spelutveckling, inte i verkligheten – är att låsa in spelaren bakom en port av något slag, där spelaren måste visa sin kunskap för att kunna ta sig vidare. Vi försöker att förklä de här portarna som något naturligt, så att det inte känns som att spelet har stannat helt. Tid, resurser eller miljön i spelet kan förstås göra det knepigt. I det här fallet behövde vi lära spelarna att flytta föremål, så ett enkelt staplingspussel kändes som den bästa lösningen. Vi provade mer komplexa idéer, men det var inte lika effektivt för att lära ut det som spelaren behövde veta."
N/A4028"#commentary\cn_114_natural_storytelling.mp3" "[ Bill Van Buren ] För att göra världsbygget och berättelsen bra på tågstationen behövde vi ett naturligt sätt att få till dialog utan att det liksom kändes för speligt och krävde handledningar. Vi märkte att spelarna ofta gick fram till NPC:er för att ta sig en närmare titt, så vi gjorde det till en möjlighet för NPC:erna att märka spelaren och säga sina repliker. Det gjorde interaktionerna lågmälda, vilket var viktigt med tanke på att invånarna inte direkt är muntra. Enkelheten med det här rimmar väl med en av Half-Lifes huvudfilosofier: att berättelsen ska utgå från spelarens intresse. Vissa spelare vill sätta sig in i alla detaljer medan andra bara vill veta vad nästa mål är. Att låta spelarna välja hur mycket av berättelsen de vill ta in – utan att sakta ner själva spelet – är ett mål vi alltid har i Half-Life-spel. Och ju mindre komplicerat ett visst inslag är, desto mer av det kan vi ha i spelet."
N/A4029"#commentary\cn_115_trainstation.mp3" "[ Charlie Brown ] Det är mycket som ska åstadkommas i början av ett Half-Life-spel: spelaren ska introduceras till en helt ny värld och lära sig hur man interagerar med den. Man måste snabbt förstå vad som händer, vilka de viktigaste karaktärerna är, vilka hot de utsätts för och hur de passar in i helheten. Framförallt måste det vara så roligt och interaktivt som möjligt. Att få till det kräver många justeringar och speltest, särskilt gällande de mindre ögonblick som utgör spelet i stort. I den här delen diskuterar vi några viktiga ögonblick, speldesignproblem och ett par speltest där allt inte gick enligt planerna."
N/A4030"#commentary\cn_116_physics_objects.mp3" "[ David Sawyer ] Det är kanske inget man minns nu, men när Half-Life 2 släpptes var mindre objekt som det här skräpet ofta statiska – de rörde sig inte, och om de gjorde det så var det på väldigt enkla sätt. Hade man tur gick sakerna sönder i ett antal sprites om man slog på dem. Ett av våra mål med tågstationen här i början var att göra det tydligt för spelarna att den här sortens grejer verkligen har en fysik som simuleras i Half-Life 2. Man kan plocka upp dem, släppa dem, kasta dem, ha sönder dem, flytta dem indirekt och så vidare. Här börjar vi bara med en liten småsak: vi visar att skräpet blåser iväg för att tåget anländer – eller i praktiken en osynlig volym som aktiveras när man som spelare kliver av tåget."
N/A4031"#commentary\cn_117_blocking_tutorials_3.mp3" "[ Eric Smith ] Vår andra miss på det här handledningsstället var att vi råkade lära spelaren nåt vi inte hade planerat. Sånt är svårt att undvika utan omfattande speltestning eftersom spelet alltid lär en saker, även när det inte är avsiktligt. Vi tar upp ett mer extremt exempel på det senare på tågstationen. Vissa såna här missar måste man bara åtgärda, som när spelaren lär sig att använda ett vapen eller nån annan grundgrej i spelet på fel sätt. Men det här stället var klurigare. Vi ville lära spelaren att flytta objekt, men lärde samtidigt att man kan stapla fysikobjekt på varandra för att lämna en viss plats. I vanliga fall är det ingen stor grej – men eftersom vi inte har några sådana pussel senare i spelet är det helt onödigt att ens ge spelaren det mentala verktyget, för då blir det bara svårare att fokusera på det viktiga senare. Dessutom blev den sortens stapling ett problem senare i spelet, och vi var tvungna att aktivt motverka den metoden i flera områden. Kruxet är att spelet har så många fysikbaserade objekt att vi inte kunde lösa det genom att smälla upp tak över alla problemområden. I slutändan hoppades vi bara att spelarna inte skulle lära sig den extragrejen här, och när folk fastnade under testningen av senare delar såg vi till att inte påminna om tricket."
N/A4032"#commentary\cn_118_welcome.mp3" "[ Gabe Newell ] Jag heter Gabe Newell och hälsar dig välkommen tillbaka till Half-Life 2. Tänk att det har gått hela 20 år sedan lanseringen. I den här jubileumsuppdateringen har vi försökt att ta itu med så många av communityns synpunkter som möjligt. Även om det kanske inte är det allra mest efterfrågade hör jag ofta folk säga att de vill ha ett läge med utvecklarkommentarer, så det här känns kul. Förutom att det var en utmaning att minnas alla smådetaljer om spelets utveckling är det knappast lätt att öppna gammal kod och försöka förstå hur tusan man tänkte på den tiden. Vid sidan om kommentarerna har vi städat upp en drös gamla buggar och försökt lämna saker i ett bättre tillstånd än de var i. Och nu vet vi åtminstone hur allt gick i slutändan. För att lyssna på en kommentarsnod riktar du hårkorset mot den svävande kommentarssymbolen och trycker på Använd-tangenten. För att avsluta kommentarsläget sätter du hårkorset över den roterande noden och trycker på samma tangent igen. Och berätta gärna vad du tycker. Jag nås på gaben@valvesoftware.com. Tack och ha så kul!"
N/A4033"#commentary\cn_119_metrocop_shoving_citizens.mp3" "[ Josh Weier ] Vi har bara gått en liten bit och har redan problem vi måste lösa. Vi introducerar metro-poliser – fiender vi i slutändan ber spelarna att döda – och ger en liten inblick i deras värld. Det är ett enkelt och tydligt ögonblick som visar på relationen mellan poliserna, invånarna och, indirekt, spelarna. Samtidigt pekar vi här igen på den grundläggande fysiksimuleringen genom att visa hur NPC:erna interagerar med objekt. Sånt som att en väska kunde slå emot en annan så att den åkte loss var något man inte direkt hade sett på den tiden. De här ögonblicken på tågstationen, där vi kombinerade olika mål, är de mest lyckade – de känns naturliga, som att spelet lär en saker utan att stanna upp."
N/A4034"#commentary\cn_120_fall_damage.mp3" "[ Kerry Davis ] Det är viktigt att spelet lär en saker. Men för att spelarna verkligen ska veta vad de gör måste de också förstå de lite mer subtila reglerna. Det här stället demonstrerar två av dem: för det första får man reda på hur långt man kan falla utan att ta skada. För det andra introduceras här lite av spelets ”vokabulär”, alltså hur spelet kommunicerar med en. Spelare oroar sig ofta för fallskada, men även för att råka göra saker som inte går att ångra. Här finns en låda att landa på som signalerar att det är säkert att ta sig ner och att det är den bästa vägen framåt. Och när lådan går sönder får man se fysiksimuleringen, och antagligen även att man kan ha sönder större objekt för första gången."
N/A4035"#commentary\cn_121_sweeping_vortigaunt.mp3" "[ Laura Dubuk ] Ännu ett viktigt ögonblick i berättelsen, och ännu en blinkning till fysiksystemet: här visar vi hur vortigaunterna passar in i den här nya världen – en stor förändring från deras roll som fiender i Half-Life 1. Precis som många andra ögonblick på tågstationen kom den sopande vortigaunten från vår konstanta jakt på sätt att visa karaktärer som interagerade naturligt med fysiksystemet. Varför tala om för spelarna att vortigaunterna är vänliga nu när man istället kan visa en som står och sopar golvet och knuffar runt några simulerade föremål? Inget säger ”Hej, skjut mig inte!” som någon som städar."
N/A4036"#commentary\cn_122_blocking_tutorials_2.mp3" "[ Robin Walker ] I den här handledningen finns det två större missar. För det första så kan spelarna sabba den genom att kasta ut alla lådor genom fönstret, och det är ju förstås inte bra. Då fastnar de och kan inte fortsätta, och det anser vi vara en spelförstörande bugg som måste åtgärdas. En bra lösning hade varit att justera storleken på fönstret eller lådorna så att spelaren kommer igenom men inte lådorna. Problemet var bara att vi märkte det här sent i utvecklingen – precis innan lanseringen, till och med – och en så enkel anledning kan ha oförutsägbara konsekvenser som potentiellt förstör spelupplevelsen. Det här problemet var dessutom helt teoretiskt – vi hade aldrig sett några speltestare faktiskt göra det. Speltesterna av det här momentet hade gått bra. Spelarna lärde sig vad de behövde veta och gick vidare. Hade vi ändrat rummets design så sent i spelet kunde det ha sabbat det på sätt vi inte kunnat förutse. Därför valde vi en konservativ lösning framför en mer elegant. Om du är nyfiken kan du prova att kasta ut alla lådor genom fönstret och se vad som händer."
N/A4037"#commentary\cn_123_playground.mp3" "[ Brian Jacobson ] När vi diskuterade hur vi skulle visa vår fysiksimulering i stadsmiljön kändes en lekplats som ett naturligt val. För spelare som lyssnar på dr Breen blir det även en påminnelse om priset mänskligheten betalade i kriget mot combine. Vi valde några lekredskap med intressant fysikpotential och började justera dem. Även med den avancerade fysiksimulering vi hade där och då behövde sånt här justeras för hand, eftersom vi hade helt simulerade objekt som interagerade med icke-simulerade eller delvis simulerade objekt – till exempel spelaren eller statisk geometri. Det är lätt att anta att en simulering drar det tyngsta lasset i implementationen, men det stämmer sällan även 20 år senare. När vi jobbade med lekplatsen sent under spelets utveckling fick vi inte friktionen på rutschkanan att kännas rätt, så vi hade sönder stegen för att se till att spelaren inte kan ta sig upp. Dock går det fortfarande att klättra upp framifrån. Som så ofta får du som spelare chans att genomskåda oss."
N/A4038"#commentary\cn_124_pick_up_that_can.mp3" "[ Charlie Brown ] Att sätta handledningar i ett sammanhang – att skapa berättelsescenarier som innehåller hjälpavsnitt – låter oss göra mer än bara stanna upp spelet för att lära spelarna saker. Ögonblicket får liksom ett berättelsemässigt värde. Här lär vi spelarna att kasta föremål, men kombinerar det med en berättelsesekvens där man själv får välja hur man ska reagera. Efter att spelarna fått se hur metro-poliserna behandlar medborgarna illa kändes det rimligt att sätta dem i en liknande situation. Om man kände att medborgarna borde ha reagerat på ett annat sätt är det nu upp till bevis själv. Speltesten visade att de flesta spelare antingen lydde eller vägrade plocka upp burken, medan vissa försökte att undvika konfrontationen helt. Andra lydde till en början, men gjorde motstånd när de kände sig förödmjukade. Genom att hålla ögonblicket relativt begränsat kring både spelarens handlingar och själva utrymmet kunde vi i mångt och mycket reagera på spelarnas val på rimliga sätt."
N/A4039"#commentary\cn_125_promises.mp3" "[ Danika Rogers ] Tidigt i Half-Life-spelens utveckling är ett av våra mål att ge spelarna löften, så att de vet vad de kan förvänta sig senare. All bra underhållning – filmer, tv-serier, böcker – gör det på något sätt, och det är likadant med spel. Löftena i ett Half-Life-spel kan se olika ut. En del är enkla, som att vi ger spelaren en titt på något spännande. Andra är mer komplexa, som interaktionerna med metro-poliserna. Genom att göra spelaren maktlös mot dem lägger vi grunden för ett framtida ögonblick där spelaren till sist får hämnas."
N/A4040"#commentary\cn_126_exploration.mp3" "[ David Sawyer ] Efter att spelarna vallats genom tågstationen av metro-poliserna ville vi dem chans att utforska lite. Det här torget ger en flera sätt att interagera med medborgarna, metro-poliser, skannrar och stadens infrastruktur. Vårt mål var att få interaktionerna att bygga ut världen utan att behöva explicit handledning och såg till att finslipade dem tills de fungerade naturligt utan träning."
N/A4041"#commentary\cn_127_early_game_exploration.mp3" "[ David Speyrer ] Innan det här torget har spelaren troligen inte behövt tänka så mycket kring vägval, eftersom de varit raka och tydliga. Här ville vi uppmuntra till utforskning, vilket innebar att vi behövde göra vägen framåt mindre uppenbar – vilket kan få spelaren att känna sig vilsen eller, ännu värre, förvirrad. Den sortens förändring kan vara jobbig, särskilt tidigt i spelet när spelaren fortfarande lär sig hur spelet visar vägen. Här kompliceras det ytterligare av kontrollpunkter med kraftfält, som medborgarna kan gå igenom men blockerar spelaren: något som fick många speltestare att tro att det fanns ett sätt att kringgå dem. Tack vare utförlig testning såg vi till att gränden som tar spelaren framåt syns på rätt sätt, via ljussättning, layout och en trälåda – ett föremål man redan använt som ett tecken på att man är på väg åt rätt håll – så att man leds rätt på ett subtilt sätt."
N/A4042"#commentary\cn_128_strider.mp3" "[ Doug Wood ] Det här enkla ögonblicket är ett löfte till spelaren om att man kommer stöta på den här stora grejen senare. Även okomplicerade scener som den här kräver mycket speltestning och många justeringar, eftersom målet med Half-Life är att aldrig ta ifrån spelaren kontrollen. Som du nog anat krävs det många småjusteringar för att se till att så många spelare som möjligt tittar på rätt plats vid rätt tillfälle här. Gatans layout och scenen med metro-poliserna är till för att leda spelarens blick så att tramparen syns klart och tydligt när den kommer."
N/A4043"#commentary\cn_129_physics_simulation.mp3" "[ Jay Stelly ] Vi påbörjade arbetet med Half-Life 2 med en fungerande fysiksimulering från tredje part, men det tog oss ändå flera års arbete med både simuleringen och dess integration i spelet innan vi kände att vi uppfyllt våra designmål. Vi visste att det skulle bli en utmaning att få både kvalitet och prestanda på en presentabel nivå, men ett lite mindre framträdande problem var att lista ut vad som skulle simuleras – och i vilken utsträckning. Vi kan inte simulera allt, och även om vi skulle kunna det så finns det speldesignmässiga anledningar till att upplevelsen blir bättre när vi inte gör det. I många fall manipulerar vi simuleringen aktivt för att förbättra spelarens upplevelse. Oftast märks de här justeringarna inte av eftersom de är i linje med spelarens avsikter. Vi stänger till exempel av kollisioner mellan spelaren och stora föremål för att man ska kunna vända sig i trånga utrymmen. Eller så justerar vi combine-gevärets alternativa attack för att leda energibollen mot fiender och göra den mer effektiv."
N/A4044"#commentary\cn_130_physics_simulation_2.mp3" "[ Jeff Lane ] Områden där speldesign eller andra begränsningar påverkade fysiksimuleringen krävde ofta extra justering för att förhindra att simuleringen gick i stöpet. Tidigare experimenterade vi till exempel med att göra simuleringen av spelaren mer betydande – alltså att vi gjorde spelarens rörelser till en större del av världens fysiksimulering. Vi visste att det här skulle få förflyttningen att kännas mindre exakt, men hoppades att det skulle leda till unika upplevelser. När vi hade justerat förflyttningen för att matcha den mindre simulerade versionen stötte vi på ett stort problem: det krävdes så mycket fysisk kraft för att spelaren skulle röra sig i sin vanliga hastighet att det räckte med att springa in i andra simulerade föremål för att dö av kollisionen. Vi justerade det här flera gånger men hittade ingen lösning vi gillade, och gick därför tillbaka till mindre simulerad förflyttning. Det var dock inte nödvändigtvis en enklare väg – det ledde till nya utmaningar kring hur den mindre simulerade spelaren interagerade med spelets mer simulerade föremål. Men det lät oss åtminstone få till en förflyttning som var tillräckligt precis."
N/A4045"#commentary\cn_131_playtesting.mp3" "[ John Morello ] Speltester är en viktig del av hur vi utvecklar spel – vi kan aldrig helt förutse hur spelare reagerar eller vad de får ut av det vi bygger. Vi testar för att lära oss och förhoppningsvis bli bättre. Under speltester vägleder eller pratar vi inte med spelarna, inte ens om de kör fast – det är nämligen extremt osannolikt att vi sitter bredvid dem när spelet väl släpps. Vårt mål är att testarna ska glömma att de är speltestare och spela som om de satt hemma. Eventuella avbrott riskerar att påverka resultaten, så vi kliver bara in om en bugg blockerar vägen fram eller om spelarnas beteende är så förvirrande att vi behöver förstå hur de tänker."
N/A4046"#commentary\cn_132_playtesting_anecdote_1.mp3" "[ Matt Boone ] Ett minnesvärt speltest påminde oss om att vi aldrig kan vara säkra på vad spelarna tänker eller vad de har lärt sig av sina upplevelser. Den här spelaren hade spelat från början och körde fast när en dörr skulle öppnas, och gick fram och tillbaka mellan spelet och tangentbordsinställningarna i flera minuter. När vi frågade vad spelaren letade efter fick vi svaret att det var oklart hur man öppnar förrådet, eftersom personen tänkte att det skulle gå att använda ett tidigare upplockat föremål för att låsa upp dörren. Vi hade sett spelaren plocka upp och släppa flera fysikobjekt utan att förstå vad som hände. Testaren trodde att om man tryckte på Använd när man höll i ett föremål så hamnade det i ett förråd, eftersom föremålet föll rakt ner. Vi visste att det bara var gravitationen, men personens antagande var inte ologiskt eftersom en del äventyrsspel på den tiden lade föremål i ett osynligt förråd på det sättet. Vi förklarade att det inte fanns något förråd, och testet fortsatte. Senare funderade vi på om vi behövde göra något åt det här, men eftersom inga andra speltestare upplevde samma förvirring och alla våra tilltänkta lösningar var klumpigare än nödvändigt ansåg vi att det var en avvikelse som vi inte behövde göra något åt. Däremot blev det en bra påminnelse om hur även de mest minsta förbisedda detaljer kan vilseleda spelare."
N/A4047"#commentary\cn_133_cratebaby.mp3" "[ Scott Dalton ] Den här lilla dockan har en lång historia. Under månaderna med interna tester skapade delar av teamet en utmaning kring den – ett sätt att göra den 47:e genomspelningen lite roligare. Testarna lade dockan i en blå låda i närheten och såg hur långt de kunde ta med sig den. När Half-Life 2 släpptes började spelarna göra detsamma, och bidrog med egna historier och regler. Några år senare, när vi jobbade med Episode 2, blev det här inspirationen till en prestation vid namn ”Den lille astronauten”, som kräver att spelaren tar med sig trädgårdstomten Gnome Chompski genom hela spelet. Chompski kom tillbaka i Left 4 Dead 2 i prestationen ”Tomträtt”, som kräver att man bär honom genom kampanjen Skräckens tivoli. De här interaktionerna med spelarna är bland det mest givande med spelutveckling. Vi designar spel med teorier i huvudet, men man vet aldrig vad som faktiskt händer förrän spelarna väl spelar."
N/A4048"#commentary\cn_134_the_citadel.mp3" "[ Eric Kirchmer ] Vi ville att spelarens första möte med Stad 17 skulle framhäva citadellet och hur det dominerar staden, som en symbol för combines fullständiga makt över mänskligheten. Det behövde också vara ett tydligt mål – redan i början av spelet kan man se var resan slutar. Och trots att det är så enormt missade speltestare ofta det. Spelarnas sinne för djup och skala kan bli knepigt på en datorskärm. Om du har spelat spel i VR har du nog märkt att skalan känns naturligare. I det här fallet så hjälpte det inte heller att citadellet är ovanför spelaren, eftersom skjutspel ofta lär en att fokusera på det som sker rakt framför en, eller vid ens fötter. För att göra det mer sannolikt att spelarna tog in citadellet lade vi till fåglar som flög mot byggnaden. Vi insåg att det var ett smidigt sätt att leda spelarens blick."
N/A4049"#commentary\cn_135_close_captions.mp3" "[ Yahn Bernier ] Under utvecklingen av Half-Life 2 kontaktades vi av folk som lade stor vikt vid tillgänglighet i spel och bad oss att utveckla undertextsystemet vi hade skapat till Half-Life 1. De bad om ett fullfjädrat undertextsystem som skulle ha med alla spelljud, inte bara dialog. Det visade sig vara en mycket tuffare utmaning än väntat. Half-Life 2 innehöll många olika ljud, och det var viktigt att kategorisera dem för undertexterna. Det var också viktigt att prioritera: dialogen behövde sticka ut, och det behövde vara tydligt vem som talade. Bakgrundsljud, som avlägsna strider, var viktiga för att sätta stämningen på vissa banor – men mindre viktiga om en fiende sköt i närheten. Våra nivådesigner återanvände ofta samma ljud i olika sammanhang, så ett visst ljud kunde behöva en viss textning på ett ställe, men en annan på ett annat. Till sist fick varje ljud i spelet sina egna undertextdata, formaterade ungefär som en liten version av HTML – vilket gav oss kontroll över undertexternas visuella stil. Precis som med ljudfilerna var undertextinfon för stor för att ha i minnet, så vi byggde ett asynkront cachesystem för att hantera det effektivt."
N/A4050"#commentary\cn_136_the_raid.mp3" "[ David Sawyer ] Delen här längre fram, där metro-poliserna slår till mot lägenheten med spelaren inuti, var kämpig att få till. I grund och botten är designtänket med Half-Life att spelarna själva ska få välja tempo, eftersom folk spelar på många olika sätt. Vissa spelare springer och ignorerar allt som inte är ett hot medan andra metodiskt undersöker allt. När vi vill tvinga fram ett specifikt tempo är det alltid en utmaning att se till så att spelarna verkligen tar till sig speltakten och spelar med naturligt. Eftersom det här var första gången vi gjorde det krävdes en hel del arbete på att för att göra det tydligt för spelarna att man måste skynda sig och inte hinner utforska."
N/A4051"#commentary\cn_137_materials_and_shaders.mp3" "[ Gary McTaggart ] Half-Life 2 släpptes under ett stort skifte inom 3D-grafik, där branschen gick från texturer till material och shaders. I Half-Life 1 hade varje yta en textur – en bild som låg ovanpå ytans polygoner. I Half-Life 2, bara fem år senare, hade varje yta både ett material och en shader. Shadern var en kodsnutt som anpassade hur ytan ritades upp. Materialet definierade egenskaper för hur ytan betedde sig fysiskt och hur den reagerade på spelfunktioner. Den hade även referenser till texturer och andra parametrar som shadern använde för rendering. Som ett resultat av detta hade grafiker och designer mer kontroll över hur saker såg ut och betedde sig. Det fanns dock en nackdel: Half-Life 1 kunde köras med en dator med bara en processor, men Half-Life 2 krävde ett grafikkort eftersom beräkningarna som behövs för material och shaders var specifikt designade för grafikkorts hårdvara. Glasdörren som bryter ljuset här är ett tydligt exempel på en anpassad shader, men varje yta i scenen kör en shader av något slag."
N/A4052"#commentary\cn_138_the_raid_2.mp3" "[ Miles Estes ] Förutom att se till så att spelaren känner press att ta sig framåt behövde vi se till att själva räden var vattentät. Det fick inte finnas något sätt för spelarna att undvika den eller vända om och ta sig förbi metro-poliserna. Det möjliga problemet var inte att spelarna skulle försöka sabba scenen, utan att många skulle få panik och springa hejvilt när de insåg att de var i fara på riktigt för första gången. Det här ögonblicket kräver en noggrann balans – vi ville ha en adrenalinstinn flykt med en känsla av riktig fara, men vi ville att spelarna skulle ta sig igenom det på första försöket och känna sig som att de nätt och jämnt kommit undan. För att få till det höll vi vägen framåt tom och fick den att likna den spelarna tagit genom förra våningen. En serie noggrant placerade aktiveringspunkter kontrollerar hoten som dyker upp framför och bakom. De håller pressen uppe men ger spelarna nog med tid att hålla sig före de som jagar dem."
N/A4053"#commentary\cn_139_health_and_no_hud.mp3" "[ Dave Riller ] Jakten på taket blev en unik designutmaning. Vi ville inte att det skulle bli ett hinder för spelupplevelsen, och helst skulle spelarna klara det på första försöket. Samtidigt ville vi skapa en känsla av verklig fara, där spelarna kände sig legitimt hotade om de inte skyndade sig. Utmaningen bestod i att spelarna tekniskt sett inte har något gränssnitt utan HEV-dräkten, vilket innebär att det inte finns något sätt att visa tagen skada eller återstående hälsa. Efter att ha experimenterat lite skapade vi ett särskilt hälsosystem för den här sektionen, där vi låter det lysa rött runt skärmen som en indikation på att man är skadad. Spelarna reagerade som väntat och tog det som ett tecken på att fortsätta framåt, och jakten fungerade som tänkt. Som pricken över i lät vi hälsan återställas fort, så att skenet inte skulle ligga kvar – vilket visade spelarna att det var rätt val att springa och såg till att spelarna inte dödades av en förlupen kula i slutet bara för att de tog för lång tid på sig eller tvekade tidigare."
N/A4054"#commentary\cn_140_playtesting_anecdote_2.mp3" "[ Jakob Jungels ] I den kommande scenen var vi tvungna att slå omkull spelarna så att Alyx kan komma och rädda dem. Eftersom vi hade begränsat med tid och resurser förenklade vi det så mycket som möjligt – vi återanvände befintliga system och lät det fungera som en vanlig stridssekvens, med en unik händelse som aktiverades när spelarna ”dog”. Efter några speltester för att få till rätt tajming gick vi vidare. Men när vi kom nära lanseringen stötte vi på problem med en speltestare som ständigt snabbsparade och direkt snabbladdade när personen trodde sig ha misslyckats med något. När en metro-polis gick till anfall snabb snabbladdade testaren innan Alyx dök upp och gjorde om det tio gånger innan vi bad personen att sluta. Så här sent i utvecklingen, under den sista buggfixningsfasen, behövde vi begränsa oss till rent spelförstörande problem – även små ändringar kunde förstöra något viktigt. Vi visste att det här var en avvikelse eftersom de flesta speltestarna inte stötte på problem här, så vi gjorde några ofarliga ändringar. Vi minskade väntetiden mellan att spelaren slås omkull och Alyx första replik, och ändrade så att bilden tonades ut till vitt istället för svart. Det hjälpte inte så mycket eftersom spelarna inte dött tillräckligt för att förknippa svart färg med döden. Vi funderade på att stänga av snabbladdning under den här scenen men var rädda för att det skulle kunna leda till en bugg som stängde av snabbladdning permanent."
N/A4055"#commentary\cn_141_character_reactions.mp3" "[ Ariel Diaz ] Det här med vad karaktärerna borde reagera på – och hur – var en ständig utmaning. I grund och botten vill vi att våra spel ska ge respons på spelarens handlingar, men all sorts respons från spelet kan ses som en belöning i spelarens ögon. Så det karaktärer reagerar på och ignorerar lär spelaren vilken sorts handlingar spelet förväntar sig. Därför såg vi till att responsen gällde saker vi ville ha mer av, som att spelarna fifflar med saker i labbet, och att handlingar som att slå Kleiner i ansiktet med en låda om och om igen ignorerades. Och ja, vi såg en speltestare göra det i fem minuter utan avbrott."
N/A4056"#commentary\cn_142_choreography.mp3" "[ Bill Fletcher ] Systemet vi byggde och använde för att få till berättelsen i Half-Life 2 kallades internt för Choreo, efter ”koreografi”. Med det föreställde vi oss tidigt att vi skrev en pjäs där en av skådespelarna inte kunde manuset. Vi behövde ett system som kunde styra alla andra skådisar, flytta runt dem på scenen, spela deras roller och säga deras repliker. Och för att det skulle gå var de andra skådespelarna tvungna att snyggt bolla anvisningarna från oss regissörer med bra respons på spelarens position och beteende. Tajmingen skulle bli den stora utmaningen eftersom delar av scenerna måste kunna förlängas, förkortas eller till och med pausas beroende på vad spelaren gör."
N/A4057"#commentary\cn_143_phoneme_extraction.mp3" "[ Bill Fletcher ] Ett annat viktigt verktyg som vi byggde in i FacePoser var fonemredigeraren. Den bearbetade röstskådespelarnas repliker och plockade ut fonemer för att skapa enkla läppsynkningsanimationer till karaktärerna. I huvudpersonernas fall använde animatörerna det här som startpunkt för att skapa högkvalitativa, unika animationer per replik komplett med fullfjädrad ansiktsanimation. Men i dynamiska Choreo-scener visste inte animatörerna exakt hur resten av skådisens kropp skulle röra sig. Därför var vi tvungna att hålla noggrann koll på Choreos kommandon och tajming i FacePoser och samtidigt se till att skådespelaren kunde svara spelaren dynamiskt beroende på situation."
N/A4058"#commentary\cn_144_delivery.mp3" "[ Ken Birdwell ] Det krävdes många justeringar och mycket speltestning för att få till en bra balans mellan information och känslomässig tyngd i våra Choreo-huvudscener. Alla scener hade mycket information att förmedla till spelaren, men karaktärerna kunde inte bara stå och häva ur sig exposition – då skulle spelaren börja se dem mer som skyltar än faktiska karaktärer. Det var viktigt att karaktärerna fick tid att interagera med varandra och låta spelaren observera deras förhållanden. Samtidigt ville vi berätta om världen, så att man får ett uppfattning om allt som har hänt medan man varit borta. Allt det här var vi tvungna att implementera med omsorg, utan att ta för lång tid på oss – vi ville ju att spelet skulle vara kul även för alla som inte vill följa berättelsen. Animationerna blev därför ett viktigt sätt att kommunicera karaktärernas känslomässiga samband på ett ofta kort men kärnfullt sätt utan övertydlighet. Humor var en annan sak vi ofta använde för att få historien att andas och lätta lite på stämningen när det hela blev för allvarligt."
N/A4059"#commentary\cn_145_alyxs_kiss.mp3" "[ Ken Birdwell ] Alyx puss på Elis kind är en liten men viktig detalj. Senare ber vi spelarna att rädda Eli, och då vill vi att folk ska bry sig om honom. För att få till den känslomässiga tyngden var det viktigt att visa ömheten Alyx och Eli emellan. Vi ville inte vara övertydliga med dialog eller göra det till en för stor grej – det måste kännas äkta, inte påklistrat – och vi såg till att finslipa det här ögonblicket tills det blev precis subtilt nog."
N/A4060"#commentary\cn_146_storytelling.mp3" "[ Bill Van Buren ] Att låta spelaren verkligen bli ett med spelupplevelsen var en nyckelgrej för oss i Half-Life 1-berättelsen, vilket tvingade oss att aldrig – eller åtminstone väldigt sällan – ha spelmoment man inte själv styr, plus se till så att spelarkaraktären inte pratar. De begränsningarna gjorde historieberättandet svårare till och från, men det var viktigt att behålla det tänket i Half-Life 2. Vi höll fast vid filosofin för att förhoppningsvis få till en ännu mer komplex och interaktiv berättelse."
N/A4061"#commentary\cn_147_archetypes.mp3" "[ Bill Van Buren ] Vi ville överbrygga berättelsen mellan Half-Life 1 och Half-Life 2 med hjälp av karaktärerna. Idén var att designa figurer som representerade arketyperna i Half-Life 1 för att på så sätt få dem att kännas bekanta för spelarna – lite som att man träffat dem i Half-Life 1 utan att man riktigt kan minnas när eller var. Vi baserade doktor Kleiner på forskarmodellen vi ansåg var den mest ikoniska, och hans personlighet är till stor del påhittad av Hal Robins, vars röst och rollprestationer blivit synonym med Half-Life 1-vetenskapsmännen. En dag, när vi höll på att skriva karaktären, fick vi en tydlig bild av hur Kleiner skulle se ut när vi delade hiss med en revisor från ett kontor på en annan våning i samma byggnad. Vi såg direkt att det var doktor Kleiners ansikte. Lyckligtvis svarade han ja när vi frågade om vi kunde fota honom till en spelkaraktär."
N/A4062"#commentary\cn_148_tone.mp3" "[ Bill Van Buren ] Det var viktigt att karaktärerna och deras dialog hade helt rätt känsla. Vi siktade på respekfulla, nästan vänliga, interaktioner med spelaren och undvek sådant som kändes alltför undergivet. Det här blev särskilt klurigt med Alyx, som måste stötta spelaren utan att tumma på sin egen styrka – det var viktigt för att spelaren skulle respektera henne. Hennes och Elis förhållande var en drivkraft för spelarens motivation, så det var viktigt att man gillade och ville hjälpa henne. Vi ville dessutom att spelarens vänskapliga relation till medhjälparna skulle stå i kontrast till Breens och combines hemskheter, så att man känner att man kämpar för rätt sak."
N/A4063"#commentary\cn_149_voice-actors.mp3" "[ Bill Van Buren ] För att skapa mer responsiva och flerdimensionella karaktärer i Half-Life 2 fick vi utveckla hur vi arbetade med röstskådespelarna. Manuset krävde bara en smula regi vid NPC-dialoginspelningen till Half-Life 1, men i Half-Life 2 ville vi ge skådisarna större möjlighet att definiera karaktärerna och ge dem liv. Vi gav dem mycket mer kontext kring berättelsen och visade dem spelvärlden, miljöerna deras karaktärer lever i samt de andra karaktärerna i deras närhet. Vi anlitade skådespelare som kunde ta den informationen och väva in den i sitt skådespel så att karaktärerna blev ännu bättre än vi tänkt oss. Vi körde flera pass med huvudskådisarna och lät dem ta in och utveckla karaktärerna över tid. I scener där olika figurer interagerar med varandra visade vi ofta andra skådespelares prestationer för att få bättre sammanhang och flyt. Vi kom till studion med ett manus och en inspelningsplan men såg till att skådisarna kände sig sedda och kunde krydda karaktärerna och skådespeleriet med sina egna idéer. Att animatörerna fick vara med vid inspelningarna visade sig också viktigt eftersom det var de som förenade karaktärernas dialog med fysiska handlingar och uttryck till den slutliga Choreo-scenen. Animatörerna kände ofta att bilden de hade av scenerna utvecklades av samarbetet med röstskådespelarna."
N/A4064"#commentary\cn_150_citizens.mp3" "[ Bill Van Buren ] När vi designade de mänskliga invånarna i Stad 17 och världen utanför staden valde vi att ha med folk i olika åldrar och av olika etnicitet och könstillhörighet. Det rimmade inte bara väl med att combine förslavat hela mänskligheten – det var också viktigt för oss att alla som spelar spelet kan se sig själv representerad i motståndsrörelsen, eftersom hela jorden står enad mot combine. Vi hade några potentiella referenspersoner till designen av invånarna men valde till slut att lägga ut jobbannonser i Seattle Times för att få med alla olika utseenden vi hade i åtanke."
N/A4065"#commentary\cn_151_alyx.mp3" "[ Dhabih Eng ] Det var allt annat än lätt att få till Alyx design – vi ville att spelarna både skulle respektera och bry sig om henne. Att rädda Eli var ett viktigt spelarmål i mitten av spelet, och vi visste att folk skulle bry sig mer om den uppgiften om de även brydde sig om Alyx och hennes förhållande till sin pappa. Vi såg till att designa, skriva dialog för och anlita en röstskådis till Alyx som gjorde henne smart, skicklig och relaterbar i den här combine-styrda världen, samtidigt som hon skulle vara attraktiv och karismatisk. Vi försökte undvika objektifieringen, överdrifterna och hypersexualiteten många spel på 2000-talet körde med eftersom vi kände att det skulle gå emot vår vision av henne som karaktär."
N/A4066"#commentary\cn_152_lab_interactivity.mp3" "[ Dhabih Eng ] I våra Choreo-scener är spelaren fast ett litet tag så att vi kan fokusera på karaktärerna och handlingen. För att ta olika sorters spelare i beaktning – de som är djupt inne i berättelsen och de som inte vill stå still i mer än ett par sekunder – kändes det som att det behövdes en strid ström intressanta detaljer på skärmen. Vi lade ut saker kopplade till historien här och var i miljön och såg till att vissa av dem är interaktiva, lite som leksaker man kan leka med. I vissa fall bakade vi in ännu fler berättelsedetaljer i de sakerna, som kaktus-miniteleportören som ger en antydan om det kommande teleportörsfiaskot. Vi balanserade på en fin tråd – för många saker att kolla in kan få folk att tappa fokus på det som är viktigt i scenen. I slutändan tog vi det lugnt med interaktivitet i Kleiners labb eftersom det var den första Choreo-scenen. Senare, i Elis labb, experimenterade vi mer med interaktiviteten och såg till att karaktärerna lade märke till vad spelaren gjorde."
N/A4067"#commentary\cn_153_gestures.mp3" "[ Doug Wood ] Varje karaktär hade ett bibliotek med enkla animationer vi kallade ”gester”, som vi enkelt kunde lägga ovanpå andra kroppsrörelser. Det var från början tänkt som en smidig grej som lät oss återanvända animationer i spelet, men vi kom på att de kunde användas på andra sätt också. Vi människor tenderar att upprepa vissa rörelser, som ibland kännetecknar vår personlighet. Därför blev vårt gestbibliotek nåt som fångade essensen av varje karaktär och hjälpte animationsteamet att greppa vilka de var. Det gjorde det mycket enklare för animatörerna att jobba på vissa karaktärer gemensamt, vilket ofta krävdes."
N/A4068"#commentary\cn_154_interactive_storytelling.mp3" "[ Erik Johnson ] När vi började med Half-Life 2 var spelberättelser generellt sett antingen linjära eller interaktiva. Vi visste att folk hade upplevt suveräna historier i spel, men de hade aldrig på riktigt varit del av händelsernas centrum och sett handlingen förtäljas runt omkring dem på ett sätt som låtit dem interagera med och se saker på nära håll. Vi ville gärna prova det, men visste inte hur vi skulle få till det eller vad för sorts teknik som krävdes. Vi hade byggt olika berättelsesystem i Half-Life 1, men det mesta visades så att säga framför spelarens ögon och saknade interaktiviteten och den där äkta känslan vi siktade på. I Kleiners labb kunde vi försöka ta reda på hur fullfjädrat interaktivt historieberättande egentligen skulle fungera."
N/A4069"#commentary\cn_155_monitors.mp3" "[ Ido Magal ] Vi använder skärmar till en stor del av historieberättandet i Half-Life 2, Episode One och Episode Two, vilket vi själva skämtar om. De är bara så himla användbara. De är ett suveränt sätt att visa vad som händer i andra delar av spelvärlden och är bra för att få karaktärer att prata utan att behöva förklara varför de är på samma plats som spelaren. Alla som har skrivit den här sortens historier, särskilt med så många skilda karaktärer, känner till det unika problemet med att försöka hitta naturliga skäl till varför alla karaktärer plötsligt är på samma ställe. Här är vi väldigt stolta över hur skärmen får Alyx att teleporteras bort och sedan snabbt dyka upp i Elis labb, så att allt känns äkta och konsekvent."
N/A4070"#commentary\cn_156_scene_interactivity.mp3" "[ Jeff Lane ] Ibland tvingar vi spelarna till handling i våra Choreo-scener. Förutom att helt enkelt ge folk nåt att göra och hålla intresset uppe finns det ett par viktiga anledningar till det. För det första gör det att man kommer in i handlingen igen om man distraherats av nåt annat i omgivningen. Scenen kan liksom ”pausas” tills man är klar med uppgiften, så att man garanterat kommer tillbaka och är uppmärksam. Samtidigt låter det oss positionera spelarna där vi vill ha dem, vilket är praktiskt för att kunna visa scener på ett speciellt sätt och se till att folk ser något särskilt. I vissa fall slår vi två flugor i en smäll genom att träna spelaren – här får man till exempel lära sig interagera med stickkontakter och uttag inför senare pussel."
N/A4071"#commentary\cn_157_kleiners_lab.mp3" "[ Marc Laidlaw ] Kleiners labb var den första delen av berättelsen vi arbetade med, och var också den del som tog längst tid att få ihop. Förutom att det är här spelaren börjar spelet på riktigt blev det så småningom också stället som gav utvecklingsteamet en enad vision om historieberättandet. I takt med att vi började utveckla karaktärerna och sättet berättelsen förmedlas runtomkring spelaren dök många frågetecken upp, och alla kändes riskfyllda för spelet. Skulle spelarna lyckas ta till sig den viktiga informationen i scenen? Skulle vi kunna få dem att bry sig om de här karaktärerna? Hur skulle vi hjälpa spelare som inte var lika inne i handlingen? Hur dyrt skulle det bli att producera en sån här scen? Och hur många fler skulle vi behöva? Det och mycket annat var inget vi skulle kunna svara på förrän vi byggt tillräckligt mycket av scenen och testat den mot massor av speltestare. Det här var alltså, till skillnad från mycket annat, inget vi skulle kunna lösa förrän vi blivit klara med en massa annat. Det går ofta att testa spelidéer med enkla prototyper, men om spelarna inte är engagerade i historien när karaktärerna bara är gråa block, hur vet man då att de bryr sig när figurerna ser ut som de ska?"
N/A4072"#commentary\cn_158_characters.mp3" "[ Marc Laidlaw ] I Half-Life 1 kan väktarna och forskarna bäst beskrivas som arketyper, inte individer. Abstrakta karaktärer uppbyggda av grafiken vi lyckades få till där och då. Men allt eftersom tekniken utvecklades med Half-Life 2 såg vi vår chans att ta karaktärerna steget längre. Karaktärsmodellerna var snyggare och animationerna hade blivit bättre, så vi kände att vi kunde fokusera på enskilda karaktärer – folk man faktiskt bryr sig om. Vi såg till att skriva riktiga repliker och lät karaktärerna säga dem på sätt som kändes tillräckligt realistiska för att folk skulle se de här figurerna som mer än bara vanliga NPC:er i ett spel – samtidigt som historien drevs framåt. År 2001, ett par år in i utvecklingen, blev vi väldigt motiverade av Ico av Japan Studios. Det är regisserat av en animatör och blåste oss av stolen med sitt fokus på karaktärers samspel med spelaren, vilket gav oss modet att fortsätta kämpa på."
N/A4073"#commentary\cn_159_writing.mp3" "[ Marc Laidlaw ] FPS-spel på Half-Life 1-tiden handlade till stor del om att bara peppra och besegra en uppenbart ond skurk. Det var svårt att få spelare att bry sig om karaktärer när de var så pass outvecklade som de var i Half-Life 1. Nu när vi planerade att ta karaktärerna till nästa nivå i Half-Life 2 ville vi försöka få till figurer som verkligen driver berättelsen framåt. Målet var att spelarens motivationer skulle rimma väl med våra karaktärers – att spelaren skulle bry sig om deras hopp och förtvivlan och vilja dem väl. Med den riktlinjen började vi skapa både karaktärer och dialog. Vi gjorde några karaktärer som gillade och brydde sig om varandra och hoppades att spelaren skulle känna samma sak. Figurerna skulle interagera på ett välkomnande sätt, som ett gäng gamla vänner som ser spelaren som en av dem – som att man bara varit iväg ett litet tag. Om karaktärerna bara kunde visa prov på realistisk känslomässig koppling till varandra var vi säkra på att spelaren också skulle känna för dem."
N/A4074"#commentary\cn_160_animation.mp3" "[ Miles Estes ] Det krävdes en hel del tekniska justeringar för att få till trovärdiga mänskliga rörelser från många animationslager. Även enkla handlingar som att vända sig för att titta på något eller gå till en plats blev mer komplext i kombination med behovet att dynamiskt reagera på spelaren och kraven Choreo-kommandona ställde. Att vända sig på det sättet behövde till exempel brytas ner i smådelar så att karaktärerna kan använda alla kombinationer av ögon, huvud, axlar, överkropp eller hela kroppen för att vända sig mot ett mål. I Half-Life 1 var mänskliga karaktärers kroppar indelade i övre och undre halvor så att de kunde gå åt ett håll men titta åt ett annat, men det var för abstrakt för Half-Life 2:s karaktärer. Istället skapade våra animatörer gånganimationer i alla åtta kompassriktningar, som sedan kunde kombineras i spelet."
N/A4075"#commentary\cn_161_faceposer.mp3" "[ Yahn Bernier ] Huvudverktyget vi byggde åt Choreo-systemet var FacePoser, ett felaktigt döpt program som lät våra animatörer lägga upp scenernas hela struktur på en tidslinje. Tidslinjen innehöll en serie Choreo-kommandon åt aktörerna, samt all nödvändig information för utförandet av kommandona. Genom att lägga de kommandona i lager på tidslinjen kunde animatörerna lätt beskriva hur en aktör behövde titta på en grej, prata med en annan aktör och gå till en annan plats – på samma gång. Tidslinjen var inte en fast linjär sekvens. Aktörerna följde sina kommandon men behövde reagera dynamiskt på världen runt dem. En aktör kan ta längre tid på sig att nå en viss plats om spelaren är i vägen, eller behöva vänta på att säga sin replik eftersom en annan aktör har fördröjts av spelaren. FacePoser lät oss snabbt justera scener och prova olika layouter, dialogleveranser och olika sorters tajming. Möjligheten att snabbt experimentera och justera var viktig för att hitta rätt sätt att nå våra mål med karaktärerna och berättelsen."
N/A4076"#commentary\cn_162_choreo_commands.mp3" "[ Yahn Bernier ] Den här felsökningsvisualiseringen visar de två vanligaste Choreo-kommandon aktörer får i en scen. Internt kallas de ”titta-på-” och ”gå-till-kommandon”. Aktörer får mål att titta på – ibland fler än ett – och försöker fokusera på det som är rimligast utefter aktuella förhållanden. Samtidigt kan de få gå-till-kommandon, som instruerar dem att gå till en plats och vända sig mot en specifik riktning eller ett specifikt föremål. Även den här sortens till synes enkla kommandon är väldigt komplexa. En scen kan kräva att en aktör pratar samtidigt som den skriver på ett tangentbord, samtidigt som den tittar på ett föremål som spelaren håller i. Eftersom vi inte kunde förutsäga var spelaren skulle befinna sig under scenen var vi tvungna att dela in varje del av scenen i separata bitar och lager. Sedan kunde vi sätta ihop dem efter behov när scenen skulle spelas upp, baserat på spelarens handlingar, och avbryta dem om så behövdes."
N/A4077"#commentary\cn_163_antlions.mp3" "[ Kerry Davis ] När spelaren skulle köra buggyn längs kusten behövde vi en fiende som skulle kunna dyka upp var som helst och agera som ett konstant hot som håller spelaren i eller nära fordonet. Myrlejon som kryper upp ur sanden var den perfekta lösningen. Eftersom de är så pass rörliga kan de hålla jämna steg med buggyn under kort tid, till skillnad från våra mänskliga fiender. Och så var de väldigt härliga att köra över."
N/A4078"#commentary\cn_164_thumpers.mp3" "[ Adrian Finol ] I den mån det är möjligt är det viktigt att få spelarna att känna att de har listat ut saker på egen hand. Det får världen att kännas mer levande och inte bara som en radda spelelement som väntar på spelarna. Om vi accepterar risken att vissa spelare missar något element helt och hållet kan vi också vara mer subtila. Så tänkte vi med dunkarna, där vi designade scenarier spelarna lär stöta på men inte måste engagera sig i. Det finns massor av ledtrådar i både ljud och bild och myrlejonens reaktioner, som hjälper folk förstå vad som sker. Det betyder inte att alla listar ut det, men speltester visade att de flesta gjorde det."
N/A4079"#commentary\cn_165_d2_coast_09.mp3" "[ Aaron Seeler ] Sent i utvecklingen av kusten låg spelkoden så pass före nivådesignen att våra programmerare letade efter mer kod att skriva och nya uppgifter som skulle få Half-Life 2 att bli klart snabbare. Det här var till stor del ett resultat av kraven kustnivåerna ställde – de blev en stor börda för våra nivådesigner till följd av sin storlek och användning av terräng. Därför började programmerarna att designa mindre moment. När nivådesignerna kom ikapp skapade de den här nivån genom att sy ihop tre av programmerarnas mindre grejer och göra det som krävdes för att få det klart för lansering."
N/A4080"#commentary\cn_166_final_scene.mp3" "[ Bill Van Buren ] Det här med att spelaren blir inlåst i en kapsel inför den sista konfrontationen i Breens kontor var något av en kompromiss, men det möjliggjorde ett fokus på karaktärer som inte var möjligt någon annanstans. Alla karaktärers historier når vägs ände i den här scenen, och genom att begränsa spelaren till det här perspektivet får vi till ett riktigt emotionellt klimax – en scen som drivs av en kombination av dialog, röstskådespel och animationer. Det var en utmaning ur produktionssynvinkel – att få till rätt komposition och rörelse, få till effektiv tajming och känslomässig synergi och samband från alla enskilda animationer, samt det separat inspelade röstskådespelet. Det krävdes mycket finjustering för att få till dramaturgisk synergi, och det kände som att alla karaktärer verkligen klaffade."
N/A4081"#commentary\cn_167_end_game_scramble.mp3" "[ Dave Riller ] Från början tänkte vi ha en mycket större koreograferad scen i slutet av spelet, men koreografiteamet hade fullt upp med det enorma berättelsearbete som krävdes i övriga delar av spelet. För att göra saker och ting lättare för dem fick citadellets speldesignkabal i uppgift att skapa en spelutmaning att avsluta spelet med. Ett pussel, en strid, vad som helst. Bosstriden mot Breen använde den befintliga mekaniken för supergravitationsvapnet och lite anpassad koreografi för att skapa en slutprodukt på mycket kort tid."
N/A4082"#commentary\cn_168_combine_portal_effects.mp3" "[ Gary McTaggart ] En viktig del av vår utvecklingsprocess är att alla i teamet kan bidra med sina färdigheter i alla delar av spelet. När spelmekaniken för den sista striden var färdig hjälpte grafiker och programmerare av visuella effekter till med att förbättra presentationen av portalen till combines hemplanet och tidsstoppeffekten precis i slutet. En brytande shader, ungefär som den vi använde till vatten, användes till combine-portaleffekten."
N/A4083"#commentary\cn_169_citadel_entrance.mp3" "[ Jeff Lane ] Vi byggde vägen in i citadellet baklänges: den inre geometrin skapades som en prototyp för att få till utseendet. Vi visste att man skulle komma från kloakröret på vår gatukrigskarta och var tvungna att skapa en sektion med rutschbanor och hopp till citadellets ingång för att koppla samman delarna."
N/A4084"#commentary\cn_170_citadel_steep_landing.mp3" "[ Randy Lundeen ] Citadellet bygges väldigt sent i utvecklingen, och till en början hade vi ingen tydlig vision gällande spelmekaniken där. Det är inget ovanligt – vanligtvis drivs vår process av speldesign, men stora kreativa beslut som vi fattar tidigt, som citadellets existens, kräver specifikt designarbete för att passa in i slutprodukten. Efter den stora striden i det föregående kapitlet tyckte vi att det skulle kännas mer givande med en annan känsla i finalen i citadellet. Vi ville att mer skulle stå på spel, men att skapa ny spelmekanik och nya NPC:er skulle vara för riskabelt så här sent. Vår första plan var att göra det till mer av ett passivt berättelsemässigt spektakel – en tågresa genom hjärtat av combines krigsmaskin, med Breens kontor som slutetapp. Efter att vi lagt upp den planen lade vi några dagar på ett experimentera med supergravitationsvapnets mekanik. Vi tänkte att vi i slutet av spelet skulle kunna uppfylla spelarnas önskningar genom att göra dem väldigt starka utan att förstöra speldesignens övergripande balans. Resultaten var väldigt lovande och ledde till en snabb omdesign för att få med supergravitationsvapnet. Istället för traditionella utmaningar ville vi att spelaren skulle känna sig som en gud som lyfter fiender och sliter loss konsoler från väggar. Citadellet kombinerar de här två koncepten och växlar mellan spektakel och superstyrka."
N/A4085"#commentary\cn_172_lightmap_pass.mp3" "[ Mike Dussault ] Citadellets interiör är rätt enkel geometriskt, men combines metallmaterial och den dramatiska ljussättningen understryker hur enorm byggnaden är. Ljuskartornas upplösning höjdes på viktiga intressanta ytor och sänktes på de som var helt i skugga eller långt borta. Eftersom utrymmena i citadellet var så stora hade onödigt stora ljuskarteytor en rejäl prestandakostnad. Nära slutet av utvecklingen gick vi igenom citadellets nivåer för att optimera de här värdena för att få allt grafiskt intressant och optimera prestandan. Arbetet underlättades av en ny karta i nivåredigeraren Hammer som visar ytornas luxel-täthet."
N/A4086"#commentary\cn_173_super_gravity_origins.mp3" "[ Brian Jacobson ] När vi hade kommit så här långt i utvecklingen kände vi oss säkra kring designen på gravitationsvapnet. Vi ville ge spelaren ett smakprov på allsmäktig styrka och började fila på en superladdad version. Det tog inte lång tid – typ en dags prototyparbete – att få till något vi gillade, och det blev kärnan i citadellets spelmekanik. När fysikmotorn var klar kunde vi hitta nya och spännande sätt att gå bortom tidigare begränsningar och se alla roliga resultat. Vårt prototypföremål – en jättetung vattenmelon som vägde hundratals kilo i fysiksimuleringen – blev combine-bollarna man ser i spelet."
N/A4087"#commentary\cn_174_combine_energy.mp3" "[ Brian Jacobson ] Det som började som en vattenmelon i prototypform blev till en energiboll, eftersom ljudeffekterna som gjordes för bollens träffar och explosioner lät mer som det vi har i spelet nu än som frukt. När vi började finslipa nivåer som inte var vattenmelonsbaserade insåg vi att energibollen inte bara fungerade som ett roligt sätt att döda soldater, utan även som ett pusselelement för att slå på och av diverse utrustning. Mycket senare i utvecklingen var vi inte nöjda med den alternativa attacken till AR2 som vi hade då, och eftersom teamet gillade combine-bollen fick den bli AR2:s sekundära attack. I backspegeln blir vi alltid lika förvånade över hur saker som fungerar oberoende av varandra i spelet löser problem senare i utvecklingen."
N/A4088"#commentary\cn_175_combine_wall_and_balls_training.mp3" "[ Ido Magal ] Under speltesterna märkte inte folk att combine-kloten löste upp soldaterna, och förstod därför inte varför de försvann. Först försökte vi lösa problemet genom att styra kloten mot att studsa mot fiender för att öka sannolikheten att de dödades genom upplösning. Vi insåg efter ett tag att spelarna inte lade märke till effekten eftersom den alltid inträffade under stridens hetta, och folk är inte jättebra på att lära sig nya saker under stress. Som en sen åtgärd lade vi till ett stressfritt träningsrum, med ett kraftfält som bara kan öppnas genom att ta combine-bollen. Det var ett nödvändigt tillskott för att lära spelaren hur combine-bollar stänger av kraftfält, och att de löses upp om man slungar dem på soldater. Men det gick ändå så där i speltesterna. Trots allt vårt slit hade vissa spelare fortfarande svårt att förstå projektilernas upplösande effekter. Vi fick slut på tid och kände att eftersom spelarna trots allt sa att de kände sig kraftfulla så var det okej om inte alla fattade varför de lyckades."
N/A4089"#commentary\cn_176_weapon_strip.mp3" "[ Josh Weier ] När vi hade introducerat supergravitationsvapnet ville vi inte att spelarna skulle återvända till sina vanliga vapen, så vi gjorde det enda rimliga – vi löste upp dem. Det är bra att ha mystiska, övernaturliga fiender som combine som skurkar i spel, för det framstår inte som konstigt att de har en maskin som löser upp vapen. Varför inte, liksom? Hade vi känt att vi måste ge tillbaka arsenalen till dig mitt på nivån hade vi bara sett till att de har en maskin som sätter ihop dem igen."
N/A4090"#commentary\cn_177_breen_monologue.mp3" "[ Marc Laidlaw ] Kreativt arbete görs aldrig i ett vakuum. Vi inspireras alla av annat vi gillar. Breens monolog på citadellets skärmar inspirerades av ett tidigare spel vi alla älskade – Thief 2, där spelets skurk hånar en när man smyger runt. Utförandet är rätt annorlunda, men den grundläggande inspirationen finns där. Det som verkligen får det att funka, som verkligen säljer in det här ögonblicket, är den numera bortgångna Robert Culps röstskådespel. Hans insats var helt perfekt. Han tolkade var och en av Breens repliker med både subtilitet och kreativitet, på ett sätt som förvandlade karaktären på pappret till något utöver det vanliga. Röstinspelningarna med Robert Culp var alltid jättelätta – han hade manuset, teknikern tryckte på inspelningsknappen, och så var det klart. Det vi lärde oss är att man ska arbeta med folk som är skickligare än en själv, som man lär sig något av. Gå inte in med en bestämd uppfattning om hur repliken ska läsas eller hur ett visst ögonblick ska utspela sig, utan samarbeta med talangfulla personer och lita på att de kommer att göra det ännu bättre."
N/A4091"#commentary\cn_178_dissolved_weapons.mp3" "[ Quintin Doroquez ] Vi gjorde så att alla combine-vapen skulle upplösas efter att combine-soldaterna slungades iväg med gravitationsvapnet, av två skäl. Det första var att spelaren inte skulle plocka upp och använda vapnen, och det andra var att förbättra prestandan på de här nivåerna. Dessutom lades en trasdockehanterare till för att ta bort de stupade soldaternas lik när spelaren fortsätter framåt."
N/A4092"#commentary\cn_179_elevator_fight.mp3" "[ Brian Jacobson ] Trots att vi ville att spelaren skulle känna sig allsmäktig kunde vi inte motstå frestelsen att lägga till en riktigt tuff strid i hisschaktet. Striden i väntan på hissen blev lite svårare än vad vi först hade tänkt oss för den här delen. Den blev enklare under speltesterna, men vi hade inte tillräcklig med testtid för att balansera den till den nivå vi siktade på. Spelaren är aldrig i särskilt mycket fara, men antalet soldater får det att kännas som en större strid än det faktiskt är."
N/A4093"#commentary\cn_180_replacing_the_prefabs.mp3" "[ Jeff Lane ] Combine-energibollarna är en rätt enkel historia, med ett kraftfält som håller kvar de evigt studsade föremålen. Under speltesterna stötte vi flera gånger på buggar som fick bollarna att studsa runt och ”fly” från fältet som ska hålla kvar dem. Till följd av begränsningar i vår teknik för färdiga objekt behövde vi bygga om dem manuellt flera gånger, på alla platser där de fanns, på alla citadellnivåer som hade såna."
N/A4094"#commentary\cn_181_strider_fight.mp3" "[ Ted Backman ] En av de första citadell-prototyperna lät en greppa tag i tramparen med supergravitationsvapnet, och under lång tid gick striden mot fienden ut på att så nära att man kunde ta tag i honom. Mot slutet av utvecklingen tyckte vi att tramparna kändes för svaga om man kunde ta tag i dem, särskilt efter alla strider med dem under gatukriget, så vi ersatte upplägget med en strid där man dödar honom med combine-bollar. Modelldelar lades till så att tramparen kunde sprängas i bitar, istället för att kroppen skulle släpas runt. Det är det enda tillfället i spelet där tramparen har en sån effekt."
N/A4095"#commentary\cn_182_getting_in_the_pod.mp3" "[ Dhabih Eng ] Kapselsekvensen som börjar här kräver att man tar full kontroll över scenen och spelarnas perspektiv. Det står i kontrast till vår vanliga filosofi om att ge spelarna så mycket kontroll som möjligt, men i det här sista steget kände vi att det var värt det. Här är spelarna så kraftfulla att det är svårt att kontrollera dem, så vi var tvungna att neutralisera dem. Alla karaktärer i scenen pratar med en, så det är fortfarande man själv som står i fokus. Vi kunde även berätta lite med omgivningen längs vägen. Tågresan genom citadellet, som börjar här, har flera fiender som vi hade gjort grafik för men som tagits bort ur spelet. Från ens trygga kapsel ser man hur smygare marscherar och får en snabb glimt av krabbsynten."
N/A4096"#commentary\cn_183_turrets.mp3" "[ Mike Dussault ] Tornen var ett fiffigt designverktyg när spelaren hade insektsbete, eftersom de kunde förhindra direkta anfall från myrlejon. De lät oss skapa scenarier där spelaren inte bara kunde kasta insektsbete för att ta sig fram, utan istället var tvungna att gå runt och slå ut tornen så att myrlejonen kunde följa efter. Det skadade inte heller att det såg coolt ut att se myrlejon mejas ner av tornens eld."
N/A4097"#commentary\cn_184_grenade_puzzle.mp3" "[ Aaron Seeler ] Det här lilla pusslet fick ofta spelare att köra fast under speltester, eftersom lådan med obegränsade granater låg en bit bakom dem. Så här långt in i spelet har spelarna lärt sig att förknippa lådor med oändlig ammunition med pussellösningar, så om det fanns en granatlåda där skulle spelarna direkt inse att de behövde en granat för att lösa pusslet. Vi ville att de skulle behöva tänka lite först. Efter ett tag lade vi till en subtil ledtråd genom att göra granater synliga på skrivbordet genom ett fönster, bara för att påminna om att de finns. Det hjälpte oss även att upptäcka en bugg: under ett speltest gick en spelare fram för att ta en närmare titt och råkade plocka upp granaterna genom glaset."
N/A4098"#commentary\cn_185_allied_turrets_balancing.mp3" "[ Adrian Finol ] Det var en utmaning för oss att balansera den här striden vid de allierade tornen. Tornen är det unika här, så om spelarna ignorerar dem känns det spelmässiga onödigt med tanke på att så mycket liknar sånt som synts tidigare. Vi ville tvinga spelarna att använda tornen och belöna strategisk placering, men vi brottades med två extremer – perfekt placering gjorde striden lätt medan dålig placering gjorde den väldigt svår. Finjustering och anpassad AI-logik för soldater funkade – soldaterna blev bättre på att välta torn genom att kasta granater eller flankera för att slå omkull dem. De här ändringarna fick striden att handla mindre om perfekt placering och mer om aktivt underhåll av tornen, eftersom alla placeringar förr eller senare skulle avbrytas. Speltesterna såg väldigt olika ut. Vissa tyckte att det var för svårt, och andra sa att det var deras favoritstrid. Eftersom vi hade ont om tid gjorde vi allt lite enklare inför lanseringen, men vi var inte helt nöjda med den slutgiltiga balansen."
N/A4099"#commentary\cn_186_meeting_mossman.mp3" "[ Ariel Diaz ] Det var svårt att återförena spelarna och Alyx med Mossman efter sveket, eftersom många spelare ville skjuta Mossman på fläcken. Vi kunde inte tillåta det eftersom vi inte hann få berättelsen att förgrena sig. Vi ville inte heller visa att vi hindrade folk från att skjuta, så vi ville minska sannolikheten att spelarna ens försökte. Det skottsäkra glaset här ger mer tid åt samtalet mellan Alyx och Mossman, där det blir tydligt att Alyx tycker det vore fel att skjuta Mossman."
N/A4100"#commentary\cn_187_eli_in_pod_choreography.mp3" "[ Ken Birdwell ] Vi skrev och spelade in dialogen till den här scenen medan vi fortfarande byggde Nova Prospekt. Då visste vi att Alyx och Gordon skulle teleportera sig ut ur fängelset, men eftersom vi inte hade rett ut alla detaljer var det viktigt att dialogen var generell nog att passa vad vi än byggde. Det gjorde att vi fokuserade mindre på spelarens handlingar och mer på Alyx sårbarhet och hennes band till sin pappa. Vi hoppades att känslorna skulle bära scenen bättre än själva historien. Vårt mål är att spelaren ska bry sig om karaktärerna och vilja prioritera det som är viktigt för Alyx."
N/A4101"#commentary\cn_188_mossman_and_eli.mp3" "[ Bill Van Buren ] Den här scenen krävde många justeringar. Vi ville ha en överraskande vändning mitt i scenen, men samtidigt inte ta ifrån spelaren kontrollen. Det krävdes en noggrann balans för att göra vändningen tydlig men samtidigt se till att det inte gick att avbryta scenen. Spelare som följde med Alyx till konsolen behövde förstå vad som hände när de vände sig om. Om spelarna stannade och tittade på Mossman behövde de förstå vad som händer utan att känna att det är något de måste stoppa. Det krävdes en hel del justering och speltestning för att få tajmingen rätt, men till sist körde vi på en kombination av avledning, en snabb leverans av det viktiga ögonblicket och en förklaring efter händelsen."
N/A4102"#commentary\cn_189_nova_prospekt_entry.mp3" "[ Danika Rogers ] Spelarna har precis kört igenom två nivåer med många strider, så vi ville sakta ner tempot lite när spelarna väl tagit sig in. De här tidiga nivåerna byggdes för att växla tempo och låta spelarna utforska Nova Prospekts interiör. Längs vägen började vi introducera tornen, först som en fiende och senare som ett användbart verktyg. Vi skapade en stor del av den här nivån genom att återanvända prototyper och grafik från tidigare i projektet, när vi fokuserade på Nova Prospekts estetik."
N/A4103"#commentary\cn_190_turret_training_exit.mp3" "[ Doug Wood ] Den här skräphögen, samt allt skrot i trappan, är där för att spelarna inte ska ta med sig ett torn. Inget skulle förstöras om de gjorde det, men vi ville göra det mindre sannolikt. Det är ingen fantastisk designstrategi att bara göra det besvärligt att ta med sig tornet, men det är bättre än inget. Många speltestare gav upp och slängde ifrån sig tornet när de insåg att spelet försökte säga dem något."
N/A4104"#commentary\cn_191_allied_antlions.mp3" "[ Eric Kirchmer ] Eftersom vi hade en armé av myrlejon som spawnade om i all oändlighet och anföll torn och soldater var vi tvungna att lista ut vilken roll spelarna skulle ha i Nova Prospekts strider. De hade redan mött många combine-soldater, så vi bestämde oss för att striderna här skulle kännas mer som ett pussel och spektakel snarare än en stridsutmaning. Genom att döda fiender direkt kunde spelarna skifta balansen till myrlejonens fördel – men vi ville göra det särskilt belönande att använda insektsbetet. I många fall aktiverade vi extra spawnpunkter för myrlejon när spelaren kastade insektsbete på fiender, vilket snabbt släppte lös en våg nya myrlejon. Slakten som följde var en belöning som gjorde det värt att använda betet."
N/A4105"#commentary\cn_192_laser_mines.mp3" "[ Erik Jonson ] Vi gillade verkligen de här laserminorna i Nova Prospekt. De var ett vapen från Half-Life 1 som vi inte kunnat använda i Half-Life 2, men de passade åtminstone som pusselinslag. Vi gillade hur de fungerade som en moralisk prövning när spelaren hade en armé av myrlejon: vissa spelare kastade direkt insektsbetet förbi laserminorna och lät myrlejonen lösa problemet, medan andra höll tillbaka sina små vänner tills de hade fått bort laserminorna med andra verktyg. Vi såg till att inte döma valen."
N/A4106"#commentary\cn_193_final_turret_arena.mp3" "[ Erik Johnson ] När vi utvecklar ett spelmekaniskt inslag, som de allierade tornen, brukar vi börja med en prototyp som representerar utvecklingens slutpunkt. Vi gör justerar prototypen gång på gång tills speltester visar att den funkar. Sen jobbar vi baklänges och lägger till tidigare scenarier för att introducera elementet och se till att spelaren lär sig det. Med det arbetssättet vet vi att slutresultatet är intressant innan vi lägger tid på det. Det betyder också att vi, när vi skapar träningsscenarier, har tittat på nog med scenarier för att lista ut vilka färdigheter som kräver vägledning och vilka som spelarna förstår naturligt. Det här sista tornscenariot var vårt mål – det lade fokus på spelarnas försvar mot fiender från flera håll och krävde dynamisk placering och återhämtning av torn."
N/A4107"#commentary\cn_194_one_way_drops.mp3" "[ Jakob Jungels ] Spelarna vet aldrig vad som väntar men är bekanta med vad som finns bakom dem, så det är vanligt att de drar sig tillbaka till bekanta platser när de stöter på en fiende. Om vi har byggt en arena där vi vill att spelarna ska kämpa hårt – särskilt mot en fiende med specifika geometrikrav, som myrlejonvakten – behöver vi ett sätt att förhindra att folk retirerar. En vanlig lösning är att få dem att falla ner i arenan utan något sätt att ta sig upp. Du har nog märkt det några gånger redan."
N/A4108"#commentary\cn_195_npcs_on_elevators.mp3" "[ Jay Stelly ] Vi lägger ofta mycket tid på att lösa problem som spelare kanske inte ens märker. Många av dem är subtila designutmaningar, medan andra kommer från flera system som interagerar med varandra. Det var till exempel klurigt att få NPC:er att åka hiss, eftersom det innefattade olika system – NPC:ers beslutsfattande, navigationsplanering och rörelsesimulering, för att nämna några saker. Dessutom hade själva hissen egna simuleringskrav som inte hade med NPC:er att göra. En mindre påfallande utmaning uppstod ur det faktum att vi simulerar NPC:er mer sällan än vi simulerar hissar. NPC:er i en hiss på väg nedåt simulerades – för att se till att de stod korrekt i hissen – och sedan simulerades hissen några gånger och åkte längre ner i schaktet medan NPC:n lämnades kvar. Kort därefter simulerades NPC:n en andra gång och flyttades ner på hissgolvet igen. Du kan tänka dig hur svårt det var att ta Alyx på allvar när hon konstant föll medan hon pratade med en."
N/A4109"#commentary\cn_196_looktargets.mp3" "[ John Cook ] Ett av huvudverktygen vi använde oss av under designen var ”blickmålet”: en osynlig punkt som aktiveras när spelaren tittar på den. Som designer kan man välja hur precist spelaren måste rikta blicken mot den, hur länge man måste titta och så vidare. När målet väl aktiverats händer olika saker i spelet. Alyx kanske till exempel väntar på att spelaren ska titta på henne innan hon säger en viss replik, en spektakulär händelse kanske inte börjar förrän den är inom synfältet och ett combine-droppskepp kanske flyger över en när man tittar i dess riktning. När vi väl hade lagt in blickmålen kom designerna på massor av bra användningsmetoder, som gjorde att spelet kändes mer pålitligt för spelarna eftersom olika personer rör sig olika snabbt och vissa tar sig runt på oförutsägbara sätt."
N/A4110"#commentary\cn_197_nova_prospekt_yard.mp3" "[ John Morello ] Allt stridande på Nova Prospekt-gården är till stor del baserat på hur vi tidigt såg myrlejon slåss mot combine-soldater. Myrlejonens smidighet och närstridsattacker blev en bra motpol mot soldaternas skicklighet på distans och sårbarhet på nära håll. Myrlejon ser häftiga ut när de blir beskjutna, med partikeleffekter som flyger överallt, och när de till slut når fram till en soldat blir trasdockseffekten otroligt härlig."
N/A4111"#commentary\cn_198_vent.mp3" "[ John Morello ] Det här vet du säkert redan, men där det finns en lufttrumma måste det finnas en huvudkrabba. Det är inte vi som bestämmer det – sånt kommer, precis som lufttrummorna, från ovan."
N/A4112"#commentary\cn_199_kitchen.mp3" "[ Kerry Davis ] Alla spelutvecklare vet att kök i spel alltid är lika med gasexplosion."
N/A4113"#commentary\cn_200_alyxs_tool.mp3" "[ Laura Dubuk ] Alyx multiverktyg var väldigt smidigt på så vis att vi kunde använda henne som nyckel. Vi var ofta tvungna att hindra spelarens framfart tills allt var redo, och verktyget lät henne säga repliker medan hon låste upp vägen framåt. Vi kan ha använt oss av det greppet lite väl mycket, men det var svårt att motstå. Det är alltid en kompromiss: genom att ha Alyx som nyckel till olika rum kunde vi istället för att skapa en annan lösning lägga tid på andra delar av spelet – oftast viktigare sådana."
N/A4114"#commentary\cn_201_mossmans_betrayal.mp3" "[ Marc Laidlaw ] Från början tänkte vi att Judith Mossman skulle förråda spelaren ungefär vid den här punkten i spelet. Men när vi kom till den här scenen efter att ha utvecklat andra delar kändes det som att det vore mer realistiskt om hon bara försökte skydda Eli. Vi föreställde oss att hon tog en funderare och insåg att hon inte kunde hugga Gordon i ryggen. Det fanns planer på att förtydliga det skiftet senare, men i slutändan knöt vi aldrig ihop säcken med henne. Vi gillade att Mossman inte går att läsa, men det verkade inte spelarna göra – nästan alla hatade henne. Det kanske var bäst så. Vi jobbbade ju hårt på att få spelaren att gilla Alyx, som inte direkt är något större fan av Judith heller."
N/A4115"#commentary\cn_202_d2_prison_05_start.mp3" "[ Yahn Bernier ] Eftersom spelaren kan flytta många objekt fick vi ofta problem, särskilt med tanke på alla begränsningar i processorer från 2003. En begränsning var att vårt AI-navigeringssystem inte märkte dynamiska fysikobjekt som de här metallsängarna. Vårt NPC-rörelsesystem kunde upptäcka och undvika fysikobjekt vid förflyttning, men objekten var i stort sett osynliga vid navigeringsmätningar till strategisk planering inför rörelser. Det handlade framförallt om begränsad prestanda – vi hade helt enkelt inte råd med något mer komplext. Vi stod också intför rena designutmaningar utan tydliga svar, som hur soldater borde reagera om spelarna helt blockerar en korridor med stora fysikobjekt. Vi löste det genom att ge NPC:erna mer styrka att skyffla undan objekten med. Sen gjorde vi det enklare för oss genom att i bandesignen förstora korridorer och se till att det fanns nog med tomt utrymme för att rekvisita skulle kunna landa utan problem. Det vi ser här är farligt: kombinationen av att soldater gömmer sig bakom sängar och att myrlejon anfaller på nära håll höjer risken för krockar mellan NPC:ernas rörelser och sängarna."
N/A4116"#commentary\cn_203_alyx_as_companion.mp3" "[ Miles Estes ] Den här delen blev en oavsiktlig prototyp för vad Episode One skulle komma att ha: Alyx som medhjälpare, som rör sig smidigt längs en väg som blandar dynamiska strider med skriptad koreografi. Vi hade på den här tiden ingen tydlig bild av hur hon skulle passa in jämte spelaren i de scenarierna, men även om den här delen är kort lärde vi oss mycket – trots att vi inte hann med justeringar."
N/A4117"#commentary\cn_204_laundry.mp3" "[ Mike Dussault ] När spelarna kommer till den här nivån, som vi kallar ”Laundry” (”Tvättstugan”), tänker vi att de vet hur man använder insektsbete för att lösa stridsscenarier. Därför ville vi ta allt till en ny nivå med ett scenario som uppmuntrar en att kombinera betet med hela sin vapenarsenal."
N/A4118"#commentary\cn_205_side_zombie.mp3" "[ Quintin Doroquez ] Den här giftzombien var alltid en höjdpunkt under speltesterna. Spelarna, som varit så koncentrerade på combine-soldater, myrlejon och stridstorn, hade inte sett en giftzombie på ett tag, så när en sån dök upp i mörkret var chocken ofta total."
N/A4119"#commentary\cn_206_flares.mp3" "[ Quintin Doroquez ] Den här delen är en härlig kontrast till de tidigare stridstornsmomenten sett till produktionskostnader och justeringar. Den byggdes väldigt sent och blev klar snabbt eftersom AI:n hos Alyx och combine-soldaterna redan var på plats. Vi gillade mörkret och lysraketerna och lade den på hyllan för att forsätta senare. Vi gick tillbaka till den när vi planerade de mörka delarna i Episode One."
N/A4120"#commentary\cn_207_magic_wall.mp3" "[ Robin Walker ] Precis som i många andra av våra stridsarenor behövde vi något som hindrade spelarna från att gå vidare innan striden var över. Tyvärr hade vi inte tid och var tvungna att fortsätta till tågstationen, så det blev att vi fick köra med den här nonsensgrejen: en vägg som bara exploderar efter att det andra kanonskeppet är besegrat och på så sätt skapar en väg framåt. Vi tänkte att de flesta spelarna nog inte märker något eftersom de fokuserar på kanonskeppen, och våra speltester visade att de flesta var klara med striden innan de kom hit. Med tillräckligt många explosioner i arenan kändes den förstörda, brinnande väggen ganska naturlig, så vi slängde in några enkla gaspussel på andra sidan för att rättfärdiga greppet. Men det är inget vi är särskilt stolta över."
N/A4121"#commentary\cn_208_ragdoll_vortigaunt.mp3" "[ Scott Dalton ] Den här döda vortigaunten bär på mycket smärta – från våra nivådesigner. På den här tiden kunde vi inte ge trasdockor särskilda poser direkt med våra utvecklingsverktyg, så när en NPC dog och blev till en trasdocka hade vi ingen kontroll över vilken pose den hamnade i. Om animatörerna hunnit hade de kunnat göra en animation med en enda bildruta och ungefär den pose vi ville ha, men vi låg redan efter och vårt lilla animationsteam hade för mycket att göra. En nivådesigner placerade vortigaunten ovanför den här stolen och gav den kommandot att dö när nivån laddades för att se vilken pose trasdockan hamnade i. Sen flyttade designern vortigaunten lite och provade igen. Vi minns inte hur många försök det tog, men det var långt fler än man kan tro."
N/A4122"#commentary\cn_209_nova_prospekt_process.mp3" "[ Eric Smith ] Precis som Ravenholm designades Nova Prospekt med ett ganska annorlunda spelupplägg jämfört med det som syns i slutprodukten. Den första versionen fokuserade på strider mellan spelaren och combine-soldater, utan inblandning från myrlejonen. Till skillnad från andra områden i spelet, där spelmekaniken och grafiken utvecklades tillsammans, gjorde vi mycket grafikarbete för Nova Prospekt tidigt. Det gav oss en uppsättning återanvändbara, polerade sektioner nivågeometri som redan hade grafik. Det gick bra att sätta ihop Nova Prospekt av de här delarna, eftersom fängelset hade en rätt repetitiv layout. När vi återvände med myrlejon och insektsbete behövde vi göra om geometrin så att den passade den nya spelmekaniken."
N/A4123"#commentary\cn_210_d2_prison_04.mp3" "[ Eric Kirchmer ] Under utvecklingen skapade våra grafiker små färdiga miljöer vi kallade ”grafikdjurparker”. De här djurparkerna visade hur vi skulle använda texturer och rekvisita för att skapa spelutrymmen som rimmade väl med våra visuella mål. När vi byggde spelmekaniken i fängelset gjorde layouten att vi kunde använda grafiken mer direkt. Den här nivån byggdes ursprungligen som den huvudsakliga grafikdjurparken för Nova Prospekt, men efter att ha använts för att testa olika prototyper – inklusive de som ledde till insektsbete – blev den del av den faktiska nivåarkitekturen."
N/A4124"#commentary\cn_211_autosave_dangerous.mp3" "[ Dave Riller ] I Half-Life 1 hade vi en uppsättning autosparpunkter som placerats ut för hand av spelets nivådesigner och aktiverades när spelaren nådde ett specifikt ögonblick eller en viss plats i spelet. Det såg till att spelet sparades automatiskt när man utforskade Black Mesas korridorer. I Half-Life 2 behövde vi ett nytt verktyg. Kruxet låg i vissa av de mer komplexa arenorna vi byggt. Vissa strider pågick ganska länge och hade flera uppsättningar fiender. Andra var långa, vidsträckta kombinationer av utforskning och strider, utan någon tydlig gränsdragning mellan elementen. Vi ville aldrig ha en autosparning där spelaren riskerar att dö direkt efter att spelet laddats, för då kan man hamna i en dödsloop – spelade man spel på den här tiden hamnade man garanterat i såna situationer. Såvida vi inte medvetet skapade pauser i varje arenas flöde kanske det inte fanns ett säkert ställe att lägga en autosparning på. Efter att ha experimenterat lite skapade vi en funktion för att upptäcka farliga tillfällen för autosparning. Det var ett nivådesignverktyg som kombinerade en autosparning och en tidsram. När nivådesignern aktiverade den sparades spelet omedelbart, men sparfilen hölls dold och kunde inte laddas av spelaren. Om spelaren höll sig vid liv under en viss tid blev den här sparfilen en riktig sparfil, den senaste autosparningen. Det lät spelaren lägga en autosparpunkt på en rimlig plats eller efter en rimlig tid i en arena och specificera en tid, exempelvis 30 sekunder – och om spelaren fortfarande var vid liv efter den tiden användes autosparningen."
N/A4125"#commentary\cn_212_we_dont_go_to_ravenholm.mp3" "[ Dario Casali ] När vi började närma oss slutet av Ravenholms utveckling kände vi att övergången från Elis labb inte funkade. Den var för abrupt – Elis labb anslöt direkt till stadens gator, där du snart befinner dig, och sektionen du står i fanns inte. Vi hade gett ett löfte i slutet av Elis labb – ”Vi beger oss inte dit längre” – och gillade hur vi byggt upp berättelsen överlag, men när spelarna kom till Ravenholm kastades de direkt in i strid med zombier utan utrymme för spänningsuppbyggnad. Vi skapade det här momentet och de följande trånga korridorerna för att lösa det på ett sätt vi gillade. Vi sänkte tempot, fokuserade på grafik och belysning och gjorde folk redo att upptäcka varför vi inte längre beger oss till Ravenholm."
N/A4126"#commentary\cn_213_lever_shenanigans.mp3" "[ Dario Casali ] Trots allt arbete vi gjorde för att försöka skapa en koppling mellan spaken och elstängslet i spelarens hjärna var det vissa testare som drog i spaken och sen inte förstod vad de hade gjort. De irrade runt, återställde spaken och irrade runt lite till. När vi inte hade mycket tid kvar att lägga på att göra kopplingen tydligare valde vi att låta spaken gå sönder. Det förhindrade att spelare saboterade sina egna framsteg, och bidrog till känslan av Ravenholm som en opålitlig miljö i förfall."
N/A4127"#commentary\cn_214_town_arenas.mp3" "[ Dario Casali ] Här har spelaren lärt sig alla tillgängliga spelelement och kan förutse hur de interagerar. Det låter oss skapa mer komplicerade scenarier med högre hotnivå och mer frihet gällande hur spelaren tar sig an varje scenario. Den här arenan är ett noggrannt sammanflätat utrymme man måste utforska, och vi använder utforskningstiden för att sakta men säkert göra striderna mer intensiva. Ju snabbare spelaren utforskar, desto snabbare ökar vi intensiteten. Den öppna designen var svår att finjustera, eftersom olika spelare tog sig an momentet på vitt skilda sätt."
N/A4128"#commentary\cn_215_mines.mp3" "[ Dario Casali ] Den komplexa vägen spelarna tar för att säkert komma igenom gruvschaktet ger dem gott om tid att se vad som väntar på botten. Spoiler: det är huvudkrabbor. Det är faktiskt ganska ofta huvudkrabbor. Men i det här fallet är det giftiga huvudkrabbor, som är roliga i sig men blir ännu roligare när man slänger in snabba huvudkrabbor. Det är en fantastisk kombination: De två typerna är inte så farliga i sig, men tillsammans är de rent av livsfarliga. Om man blir förgiftad som spelare räcker det med en enda träff från en snabb huvudkrabba för att man ska dö. Biologerna kallar det symbios. Tror vi, i alla fall."
N/A4129"#commentary\cn_216_poison_headcrabs.mp3" "[ David Speyrer ] Det här rummet introducerar, oavsiktligen, giftiga huvudkrabbor. Vi hade lagt mycket tid på att bygga en ordentlig introduktion senare på nivån, men när vi såg hur bra de funkade i speltesten blev vi för uppspelta och spridde ut dem här och där. När vi insåg att de hade dykt upp innan de egentligen skulle introduceras var det för sent att göra om dem. Som tur är blir ett trångt rum med giftiga huvudkrabbor rätt hyfsad träning eftersom deras design gör att man slipper ett vanligt problem med stridsträning. Vanligtvis är spelare stressade och kan bli frustrerade om de dör ofta utan att förstå varför, och vi stötte förstås på det problemet när vi skulle träna spelaren med både giftiga huvudkrabbor och deras källa, giftzombien. Giftiga huvudkrabbor kan dock inte döda spelaren på egen hand. Visst är det stressigt med ett rum fullt av dem, men man slipper åtminstone frustrationen."
N/A4130"#commentary\cn_217_poison_zombie_introduction.mp3" "[David Speyrer] Ett bra sätt att se till att spelare ser något vi vill att de ska se är att stänga in dem i ett trångt utrymme och låta dem se ut ur det. Här fångar vi spelarens uppmärksamhet med giftzombiens tjut, innan själva zombien blir synlig. Egentligen hade vi tänkt att det här skulle bli första gången spelarna mötte giftiga huvudkrabbor, men som tidigare nämnt blev vi för entusiastiska med att sprida ut giftiga huvudkrabbor, så de kom tidigare än tänkt. I slutändan visade det sig att de här första mötena funkade bättre separat."
N/A4131"#commentary\cn_218_final_arena.mp3" "[ Eric Smith ] När vi gjorde klart den första versionen av Ravenholm var tanken att slutstriden skulle äga rum på det här taket. Precis som med andra platser i Ravenholm började det som ett ställe som först och främst skulle vara visuellt intressant. Det var viktigt för oss att spelarna skulle titta tillbaka på Ravenholm, staden de just överlevt, och få en titt på vart de skulle härnäst. Flera utvecklargrupper provade att bygga en strid här, men den snäva geometrin och prestandakraven ledde till att vi aldrig fick till en final vi var nöjda med. Det verkade som att Ravenholms öde var att inte få något riktigt slut – ungefär som Half-Life-serien i stort."
N/A4132"#commentary\cn_219_tables_and_bodies.mp3" "[ Ido Magal ] Mot slutet av produktionen av Ravenholm, när alla viktiga delar var på plats, gick vi igenom området och försökte fylla alla tomma utrymmen med något mer intressant. När vi gjorde det såg vi till att använda sånt vi redan hade och inte skapa något nytt, eftersom vi inte ville riskera nya buggar. Ofta, som i det här rummet, försökte vi lägga till nya spelmoment och även ge området mer detaljer och berättelseelement. Små scener som den här låter uppmärksam spelare tänka på vad de ser och vad som väntar härnäst."
N/A4133"#commentary\cn_220_physics_object_consistency.mp3" "[ Kerry Davis ] Alla fysikobjekt har olika parametrar som definierar deras beteende: deras massa, mängden skada de kan ta utan att gå sönder, hur de går sönder och så vidare. Under utvecklingen specificerade nivådesignerna de här parametrarna för varje föremål, och det var så de flesta grejerna i spelet funkade. Senare under utvecklingen insåg vi att vi hade satt krokben för oss själva – det fanns tusentals fysikobjekt i spelet men inget sätt för oss att garanterat att de var konsekventa. Till exempel kunde en kartong gå sönder med ett enda pistolskott på en nivå och vara helt oförstörbar på en annan. Internt kallade vi såna inkonsekvenser för ”nivådesignbrott”. För att åtgärda dem och skipa rättvisa byggde vi ett system som tvingade fram konsekvens för alla fysikobjekt baserat på deras grafiska modell. Eftersom större delen av spelet redan var byggt var vi tvungna att låta nivådesigner göra undantag från det här systemet i specifika fall, om de behövde göra något brottsligt för att bevara det de designat. Internt kallar vi såna designer för återfallsförbrytare, och vissa fortsätter sin brottsliga bana på Valve än idag."
N/A4134"#commentary\cn_222_fast_zombie_introduction.mp3" "[ Randy Lundeen] Det här området byggdes ursprungligen för E3 2003, där vi visade hur spelaren strider mot en grupp combine-soldater. När vi återvände för att introducera den snabba zombien ville vi bevara så mycket av det tidigare arbetet som möjligt. Vi ville ha en ikonisk månbelyst scen där zombier hoppar förbi månen som varulvar för att dra till sig spelarens blick. När det ögonblicket är över bussar vi den första snabba zombien på spelaren. Det tog många försök att få till rätt balans med ljussättningen – det skulle se bra ut, men också funka rent spelmässigt."
N/A4135"#commentary\cn_223_ravenholm_gameplay_focus.mp3" "[ Mike Dussault ] Efter att ha sett många speltester av Ravenholm visste vi att nivån i grunden handlade om gravitationsvapnet och fysiken. När vi hade den kunskapen kände vi att vi kunde bygga övergången till nivån och hjälpa spelaren lära sig och förstå vad som väntade. Det händer ofta – vi bygger nivåns huvudspår, listar ut vad som funkar och designar sedan prologen. Vi byggde de följande rummen med det i åtanke. Eftersom vi ger spelaren så pass brutala redskap blev det lättare att sätta rätt stämning och skifta tonen från tryggheten i Elis labb till något mörkare och läskigare."
N/A4136"#commentary\cn_224_player_tools.mp3" "[ Steve Bond ] Så här långt in i spelet har spelarna mycket erfarenhet av Half-Life 2:s fysik, men de har precis fått gravitationsvapnet – som ger en ett helt nytt sätt att interagera med spelets fysikobjekt. Vi finslipade ett urval av fysikobjekten som spelaren kan leka med – saker som sågklingor, katapulter, explosiva behållare, fällor, spjut och så vidare – och fokuserade på de som funkade bra med gravitationsvapnet och tog bort de som fungerade sämre. Sen tog vi bort ammunitionsföremål från nivåerna så att spelaren skulle behöva förlita sig på de här föremålen för att överleva."
N/A4137"#commentary\cn_225_contrived_setups.mp3" "[ Kerry Davis ] Det finns en del krystade trick i hur träningen kring gravitationsvapnet och fysikobjekten går till. Spelaren drar en sågklinga ur väggen med gravitationsvapnet, och precis då kommer en zombie snubblade runt hörnet och bara ber om att få en sågklinga kastad på sig. Sen kryper spelaren under en fälla med snurrande klingor för att stänga av den, och då dyker tre zombier upp, som för att be spelaren slå på fällan igen. Vi hade inte mycket tid till den här delen, så vi behövde scenarier som funkar för alla spelare, inte mer öppna scenarier som förlitade sig på att spelaren gjorde ”rätt” val. Den här sortens design kan minska spelarens kreativitet, men här upptäckte vi att spelarna inte hade något emot att vi höll dem i handen lite."
N/A4138"#commentary\cn_226_misteaching_flinches.mp3" "[ Kerry Davis ] Ett annat minnesvärt speltest, och ett exempel på farorna i att lära spelaren fel saker, inträffade i Ravenholm. En av våra designprinciper är att spelet ska reagera på spelarna så mycket som möjligt. När vi designade gravitationsvapnet verkade det uppenbart att något skulle ske om spelarna riktade det mot en zombie och tryckte av. Det lätt att få det att träffa zombien och göra lite skada, så att zombien ryckte till. Det kändes bra och responsivt. Sen såg vi ett speltest där testaren upptäckte den här interaktionen så fort personen kom till Ravenholm, och tog det som att gravitationsvapnet skadade zombien… vilket det gjorde, men inte särskilt mycket. Därför sköt testaren zombien gång på gång tills den dog av stötarna. Det är ett långsamt, tråkigt och inhumant sätt att slåss mot zombier, särskilt när man är omgiven av sågklingor och explosiva behållare. När vi insåg det tog vi bort skadeanimationen, trots att det tog bort interaktionen mellan zombien och gravitationsvapnet. I det här fallet var det bättre att inte ha en sån enkel interaktion än att ge ett falskt intryck av att gravitationsvapnet var effektivt mot zombier. Även enkla principer kan kräva kompromisser på detaljnivå."
N/A4139"#commentary\cn_227_fire_trap.mp3" "[ Steve Bond ] Den här eldfällan designades ursprungligen för att visa upp eldsystemet, innan en nivådesigner gjorde om det till ett spelelement i Ravenholm. Den var nära att tas bort flera gånger under utvecklingen, till följd av prestandapåverkan på svagare datorer på grund av allt extra renderingsarbete med genomskinliga sprites. Till sist tyckte en programmerare att fällan var tillräckligt viktig för att lägga ner tid på att lösa prestandaproblemen och se till att den kunde vara med."
N/A4140"#commentary\cn_228_hallway_cupboards.mp3" "[ Yahn Bernier ] De här skrotfyllda korridorerna var en enkel lösning när vi var tvungna att sakta ner spelaren. Eftersom vi behövde bevara så mycket befintlig geometri som möjligt och hade långsamma zombier som huvudfiende var det svårt att hindra spelarna från att bara springa igenom. Som tur var gjorde den galne Grigori det enkelt att förklara varför det ser ut så här – det är ju helt rimligt att han skulle fylla trapphuset med skrot för att hålla sig säker på taken. I slutändan körde vi och Grigori på samma lösning: vi bara ställde olika möbler i vägen. Stoppar det zombier lär det sakta ner spelaren också."
N/A4141"#commentary\cn_229_pacing_switch.mp3" "[ Steve Bond ] Nu när spelarna har tagit sig igenom träningsområdet kan vi gå från stämningsfulla klaustrofobiska utrymmen till mer stridsfokuserade actionarenor. När spelarna är bekanta med de olika fysikverktygen i omgivningen kan vi börja kombinera dem med öppna områden och ge folk friheten att välja väg."
N/A4142"#commentary\cn_230_car_crushers.mp3" "[ Steve Bond ] De här bilkrossarna krävde lite justeringar och mycket arbete med vårt fysikskadesystem. Det är alltid en utmaning när stora fysikföremål interagerar med NPC:er. Om fysikföremålen exempelvis kan knuffa NPC:n kan det leda till att de hamnar där de inte ska vara, utan att kunna återhämta sig. Det här är ingen större fara för till exempel huvudkrabbor, som bara kan hoppa sig ur knepiga situationer, men zombier kan fastna och bli så hjälplösa att de bara står och viftar i springan de fastnat i. Det sabbar den där skräckkänslan vi är ute efter här."
N/A4143"#commentary\cn_231_car_crusher_lifts.mp3" "[ Eric Smith ] Det var också svårt att få bilkrossarna att lyfta spelarna, eftersom de alltid simuleras av både fysiksystemet och spelets förflyttningssystem. Varje gång vi uppdaterar spelets tillstånd jämför vi resultaten från båda systemen och avgör vilket som är ”rätt”, sen synkroniserar vi dem och upprepar. På så sätt får vi de två systemen att påverka varandra – när spelarna står på en gungbräda låter fysiken brädan ge vika, och när de ställer sig på en bilkross lyfter den upp dem. Att köra med två system var mer komplext, men lättare att finjustera än att försöka hantera både fysik och spelarförflyttning i samma system. Genom att hålla isär dem kunde vi finjustera rörelsesystemet så att det kändes bra på egen hand och bara förena dem när fysiken påverkade spelarna."
N/A4144"#commentary\cn_232_paint_cans.mp3" "[ Steve Bond ] När det började gå bra för oss att skapa gravitationsvapnet och fysikbaserad spelmekanik som Ravenholms känra gick vi igenom nivåerna och letade efter föremål vi kunde ha råkat missa, eftersom vi arbetade med brutala grejer som sågklingor och exploderande behållare. En grej vi hittade var färgburken, och det var inte särskilt svårt att få den att göra det alla förväntar sig: skvätta färg på zombier när man kastar den."
N/A4145"#commentary\cn_233_bringing_physics_to_the_enemies.mp3" "[ Tom Leonard ] Fysikfällorna i Ravenholm var bland de första spelelementen på nivån vi blev riktigt nöjda med, men spelarna kunde inte interagera med dem tillräckligt mycket. Det var sågklingorna som fick oss att förstå vad grejen med Ravenholm var. Med dem kunde spelarna ta fysiken till zombierna istället för att leda in zombierna i fysiken. Den insikten fick nivån att utvecklas snabbt: Vi finkammade kartan på allt, särskilt ovanliga grejer, som kunde förvandlas till ett verktyg eller vapen åt spelarna."
N/A4146"#commentary\cn_234_ravenholm_development.mp3" "[ Tom Leonard ] Vi började utveckla Ravenholm tidigt i produktionen av Half-Life 2, så det genomgick mer än en fullständig utvecklingsrunda. Den första versionen var innan gravitationsvapnet introducerades, och fokuserade på traditionella zombiestrider med skjutvapen och några fysikfällor. Vi tänkte till och med visa Ravenholm på E3 2002, men spelet presenterades ett år senare. Då hade vi lagt rejält med krut på Ravenholms grafik, vilket vi oftast försöker undvika tills vi vet att allt spelmässigt sitter. När vi gick tillbaka till Ravenholm med gravitationsvapnet i åtanke arbetade vi med befintlig nivågeometri som designats med väldigt annorlunda spelmekaniska mål i åtanke."
N/A4147"#commentary\cn_235_grigori_plaza.mp3" "[ Steve Bond ] Det här öppna området var ett av områdena där vi gjorde alla detaljer i vår första utvecklingsrunda, och när vi återvände till det ville vi bevara så mycket befintlig grafik som möjligt samtidigt som vi designade en ny spelarväg som nyttjade alla tre dimensioner. Spelaren skulle röra sig upp och ner genom fönster, över tak och mellan byggnader. Det var inget stort område, så vi klämma ur mest möjliga ur det. Eftersom det till en början var en grafikfokuserad plats fanns det inte många rena spelelement, och vi behövde ta itu med det faktum att speltestarna oftast rusade förbi området. Som lök på laxen hade vi dessutom nästan spräckt vår renderingsprestandabudget, så det fanns inte mycket plats för något nytt. Utmaningen blev att hitta små tillskott som kunde sakta ner spelaren, så vi lade till hot bakom varje hörn och i alla skrymslen och vrår."
N/A4148"#commentary\cn_236_ravenholm_development_2.mp3" "[ Tom Leonard ] När fans pratar med oss om Half-Life 2 är det oftast Ravenholm de minns bäst. Tack vare flera utvecklingsomgångar och tätheten på materialet i Ravenholm är fler teammedlemmar representerade på den nivån än i någon annan del av spelet. Det var där vi listade ut hur vi skulle använda vår grafikpipeline för den dekor och stämning vi ville ha, hur fysik och spelmekanik kombinerades med gravitationsvapnet, hur huvudkrabbor och zombier behövde utvecklas till Half-Life 2 och mycket mer. När vi tittar tillbaka nu stärker det vår tro på individuell styrka över centraliserad design. Ravenholm är kompakt, väldigt effektivt sett till spelupplägg och grafik, och resultatet av många små bidrag från individer som förstod hur de kunde ta saker till nästa nivå med sina egna unika förmågor."
N/A4149"#commentary\cn_237_playtester_archetypes.mp3" "[ Tom Leonard ] Finjusteringar och regelbundna speltester var Half-Life 2-produktionens själva livsnerv. Varje vecka tittade vi tyst över axeln på en spelare som gick igenom delen vi arbetade med och förde anteckningar om vad som funkade och inte funkade. Det var viktigt för oss att testa med olika färdighetsnivåer för att se till att vi inte tog beslut som bara funkade för vissa. Över tid lärde vi oss att välja specifika speltestare beroende på vilken utvecklingsfas vi var i. Tidigt använde vi erfarna spelare, vanligtvis teammedlemmar, som kunde klara ofärdiga områden och var bra på att förklara hur de tänkte. När vi testade strider hittade tog vi in spelare på alla färdighetsnivåer, särskilt såna som var kreativa i hur de använde verktygen. När olika moment blev mer polerade fokuserade vi på nybörjare – spelare som inte spelade så många spel eller inte var bekanta med FPS-spel. Även om det kanske inte var personer som skulle köpa spelet kunde vi lära oss viktiga saker av att iaktta dem."
N/A4150"#commentary\cn_238_the_real_final_arena.mp3" "[ Tom Leonard ] Sent i Half-Life 2:s utveckling, när vi gick igenom hela spelet för att hitta den sista förbättringpotentialen, bestämde vi att vi faktiskt ville ha en riktig final i Ravenholm. Striden på taket räckte inte. Efter lite diskussion valde vi att lägga till den här sista striden, där Gregori slåss sida vid sida med spelaren. Det var farligt utvecklingsmässigt, men vi kände att spelet behövde det. Eftersom vi var nära slutet av produktionen hade vi en färdig uppsättning speldesignverktyg att arbeta med, men viktigast av allt var att vi förstod vårt spel. Att göra ett spel är ofta en process där man lär sig vad det är man skapar. Varför är vårt spel roligt? Vad gör det unikt? Vilka är de viktigaste elementen? När vi byggde spelet och såg speltestarna gå igenom det fick vi svar på de frågorna och blev bättre på utvecklingen. Kyrkogården blev klar snabbt och krävde mycket färre justeringar än många tidigare delar av spelet."
N/A4151"#commentary\cn_239_cities.mp3" "[ Eric Kirchmer ] En av de svårare utmaningarna i den här delen av spelet var hur vi skulle ge spelaren känslan av att vara i en vidsträckt stad när våra prestandabudgetar inte räckte till för att bygga en sådan. Därför fokuserade vi på tätt packade hyreshus, underjordiska garage, tunnelbanetunnlar, kulvertar och så vidare. Platser som finns i städer men oftast gör det svårt att se ända till horisonten. Sen kompletterade vi den sortens nivådesign med utkiksplatser, där hela utrymmet handlade om att ge spelaren en vidsträckt vy. Där kunde vi lägga hela prestandabudgeten på utsikten och var inte tvungna att spara något till fiende-AI eller strider."
N/A4152"#commentary\cn_240_strider_4.mp3" "[ Eric Smith ] Det här var produktionskartan som byggdes för tramparen, men vi hade en utvecklingskarta att testa dess AI på. Vi har alltid sett det som värdefullt att ha en bra testkarta för AI, eftersom det låter oss snabbt prova nya spelidéer och justera dem enkelt. Om det finns buggar eller designproblem kan vi isolera dem och finslipa dem snabbare. När AI-funktionerna funkar bra transplanterar vi dem till produktionskartorna, där våra nivådesigner kan jobba med dem. Tramparens testkarta hade grova konturer av byggnaders ruiner, med oändliga medborgarspawnare på olika platser och höjder för att ge spelarna en strid ström av måltavlor. Det här lät oss förfina tramparens AI och ställningsbyten för att göra den intressant och spännande, även om man bara lutade sig tillbaka och tittade på den."
N/A4153"#commentary\cn_241_perf_arena.mp3" "[ Aaron Seeler ] Det här området hade en stor utmaning: prestanda. Storleken och den kombinerade trampar- och medborgar-AI:n tänjde på gränserna. När vi portade Half-Life 2 till Xbox var vi tvungna att göra vissa designjusteringar. Det var knepigt att ha kvar den ursprungliga visionen och erbjuda samma spelarupplevelse med färre verktyg och mindre utrymme."
N/A4154"#commentary\cn_242_space_re-use.mp3" "[ Chris Green ] Det fanns flera fördelar med att återvända till det här området. Det första var uppenbart: produktionskostnaden för nya områden är alltid hög, så det är en vinst om vi kan lägga till nya spelelement i ett befintligt område. I en svår strid som den här, där spelaren möter flera trampare, finns det extra fördelar med att återanvända saker. Eftersom spelarna har gått igenom arenan tidigare har de ett hum om hur den är upplagd. Den här gången rör sig spelaren baklänges genom området, men vägen följer till största del den ursprungliga rutten: nytt kunskap när spelarna måste ta sig framåt för att skaffa resurser till striden. Stad 17:s krigshärjade tillstånd gav oss flexibiliteten att justera skydd och lägga till mindre hinder längs vägen för att hålla miljön dynamisk och överraskande."
N/A4155"#commentary\cn_243_tenements_and_courtyards.mp3" "[ Danika Rogers ] Vi använde oss av många små knep och byggde olika funktioner för att skapa intrycket av en stad i krig. Mycket av arbetet fokuserade på att låta spelaren se glimtar av sammandrabbningar eller höra ljuden av strider i fjärran. Blickmål såg till att något hände varje gång en spelare tittade ut genom ett fönster, medan verktyg som spårljusskapare lät våra designer skapa fejkad spårljuseld mellan två punkter. I kombination med ljudverktygen såg det ut som att två fiendegrupper öppnade eld utan att vi behövde köra någon AI. Vi skapade även små historier för grupper av medborgare som spelare skulle se flera gånger under nivåns gång. De här ögonblicken finslipades genom speltester för att se till att så många spelare som möjligt upplevde dem."
N/A4156"#commentary\cn_244_hopper_mine_training.mp3" "[ Dario Casali ] Den här räfflade metallpanelen placerades medvetet över hålet för att uppmana spelarna att byta till gravitationsvapnet och ta bort hindret. Det är lite manipulation från vårt håll, för vi märkte att det gick mycket bättre att träna spelarna på hoppminor om de direkt provade att använda gravitationsvapnet på dem. Metallpanelen gjorde det mycket mer sannolikt att de hade den framme. Vi placerade flera minor i hålet så att spelarna skulle få flera möjligheter att interagera med dem och göra det mer sannolikt att de hittade andra sätt att göra sig av med dem. Det här är dessutom första gången vi har träning medan spelarna har en hel grupp medborgare med sig, så vi drog nytta av den möjligheten för att lägga till några repliker om hoppminorna."
N/A4157"#commentary\cn_245_dog_combat.mp3" "[ Eric Kirchmer ] Dog är en väldigt rolig karaktär, och vi letade alltid efter sätt att inkludera honom i strider tillsammans med spelaren. Att få till rätt stridstyp åt honom – lämplig miljö, ny fiende-AI och kanske till och med nya fiender – hamnade snabbt utanför projektets omfång. Om vi skulle skapa ett stridsscenario som gjorde Dog rättvisa och kunde mäta sig med resten av spelet skulle vi mer eller mindre behöva bygga ett nytt spel i spelet. Han kunde inte bara springa fram till en soldat och dela ut en smocka – då skulle han kännas mindre imponerande och inte ge den där wow-känslan. Det krävdes ett större hot som matchade honom samt spännande sätt att interagera med dem. I slutändan valde vi att skapa en stor koreograferad scen som uppfyllde de filmiska målen för Dog i strid utan att vi tvingades till utförligt speldesignarbete."
N/A4158"#commentary\cn_246_strider_2.mp3" "[ Eric Kirchmer ] Efter att ha finslipat tramparen här fick vi till sist till något vi var nöjda med, där spelarna var tvungna springa från skydd till skydd och undvika dess eld i jakt på raketer. Vi ville få folk att känna att de dök in bakom skydd i sista sekund, så vi finjusterade tramparens skottmönster för att varna för fara. Vi byggde även ett system med spår tramparen kunde följa och lät den dynamiskt växla mellan dem för att jaga spelaren eller skapa en siktlinje. Det här lät våra nivådesigner lägga tramparnas spår efter spelarnas skydd för att få till en balanserad upplevelse. Placeringen av tramparens ben drevs helt av kod, och dess oförutsägbara rörelser innebar att vi ofta behövde finjustera saker så att vi var säkra på att den sparkade en bil eller truppcontainer när så krävdes."
N/A4159"#commentary\cn_247_manhack_tunnels.mp3" "[ Eric Smith ] När vi utvecklade en NPC:s AI-beteende märkte vi att det var nyttigt för AI-programmeraren att ha en testkarta att experimentera på. Den kartan blev ofta en miljö som var designad specifikt för att visa NPC:ns unika förmågor. Senare, när AI:n var klar att användas av våra nivådesigner, var testkartan en viktig refernspunkt – utan den råkade våra designer bygga scenarier som gjorde en annars intressant AI mindre spännande. I vissa fall kunde vi implementera testkartorna i själva spelet. Den här delen började till exempel som tunnlarna som användes för att utveckla spinnsågens AI."
N/A4160"#commentary\cn_248_sniper_streets_2.mp3" "[ Erik Jonson ] Kulor i Half-Life 2 följer ingen bana – de når sitt mål direkt. Men för prickskytten, som skjuter långsamt och har spelarens uppmärksamhet på sig vid varje skott, ville vi simulera att kulorna färdades genom världen. Det funkade bättre med lasersiktet, där siktet stängs av och kulan landar kort därefter, beroende på avståndet till prickskytten. Men ändringen gav oss ett nytt problem: vi ville inte att spelaren bara skulle springa ner för gatan för att undvika skotten, så prickskytten var tvungen att följa ett rörligt mål och försöka förutspå var kulan skulle träffa. Det var knepigt att förutspå spelarens framtida position, eftersom folk kan byta riktning mycket snabbare än vad som är möjligt i verkligheten. Vi lade därför till extra kontroller för att fånga beteenden som till exemåel spelare som tryckte snabbt åt vänster och höger när de sprang."
N/A4161"#commentary\cn_249_triangle_plaza.mp3" "[ Ido Magal ] Den här striden på torget var komplex eftersom vi använde anfallsbeteendet med två sammanlöpande stridslinjer – en för varje kraftfält. När soldaterna kliver in från bakom fälten finns stridslinjerna där för att hindra dem från att rusa in på torget. I takt med att striden eskalerar och fler soldater kommer flyttas stridslinjerna mot mitten av torget, vilket får soldaterna att bli alldeles för många om inte spelaren tar hand om dem."
N/A4162"#commentary\cn_250_sniper_streets_3.mp3" "[ Jakob Jungels ] En grej vi provade på de här gatorna var nedhållande eld. Många spelare satte sig på huk i slutet av gatan och sköt en salva på en krypskytts fönster för att se om det hade någon effekt. Vi experimenterade med att göra så att lasersiktet försvann en kort stund, så att man fick möjlighet att ta sig någon annanstans. Men efter att antal speltester stötte vi på två problem: Dels störde vi det spännande upplägget med att springa och gömma sig, som var tanken med krypskytten. Att springa medan man skjuter var inte jätteannorlunda från andra saker vi ber spelaren göra i Stad 17. Ett mer subtilt problem var att vissa spelare fick intrycket att den nedhållande elden krävdes, och sköt snabbt slut på sin ammunition. Om de fick slut på den halvvägs igenom gav de ofta upp och tänkte att de misslyckats, medan de som lyckades ofta hade slut på ammunition efteråt. De som klarade scenariot genom att smyga använde knappt någon ammunition alls. Den här skillnaden mellan olika metoder gjorde det i princip omöjligt att få till en bra ammunitionsbalans i de påföljande delarna, så idén skippades i spelets slutversion."
N/A4163"#commentary\cn_251_assault_behavior.mp3" "[ John Cook ] Det mest komplexa beteendet vi byggde till Half-Life 2 var anfallsbeetendet, som används i den här delen av spelet. Det lät bandesignerna göra stridsscenarier med combine-soldater och invånare, skapa stridslinjer mellan dem och styra hur de striderna går baserat på spelarnas handlingar. NPC:er i anfall försöker hitta smarta positioner för eldgivning och ta skydd baserat på var stridslinjen är. När spelarna går längs en väg kan de föra stridslinjen framåt, vilket får allierade invånare att avancera och soldaterna att dra sig tillbaka. Ibland måste spelarna slå ut några combine-stridstorn eller döda en soldat bakom en barrikad för att flytta fram linjen."
N/A4164"#commentary\cn_252_bank_roof_mortar.mp3" "[ John Morello ] När vi hade byggt nivåns huvudspår fram till den här punkten kände vi att det skulle vara kul om spelaren fick använda granatkastaren. Det borde vi kanske ha tänkt på tidigare. ”Kan det finnas någon som vill bombardera fienderna med granater? Ja, självklart.” Hur som helst – spelarna hade lagt en massa tid på andra sidan om vapnet, så nu vorde det fint om de fick ge combine en dos av deras egen medicin. Men vi insåg snabbt hur mycket jobb det skulle kräva – vilket ju i och för sig är något man tänker varje dag när man gör spel. Granatkastaren skulle behöva både animationer och effekter nu när spelaren är precis bredvid den, och det tar sin tid att skapa en fiendeeskalering nere på torget. Men viktigast av allt var att vi inte hade något gränssnitt för det här helt unika vapnet. Hur skulle man sikta och skjuta med det? Det känns sällan bra att lägga en massa tid på ett enda spelögonblick, så efter att ha bestämt att vi hellre lägger den tiden på andra ställen gick vi vidare. Förlåt! Vi kanske får lösa det här designdilemmat med granatkastaren i en kommande del i Half-Life-serien."
N/A4165"#commentary\cn_253_strider.mp3" "[ Kerry Davis ] Det var i det här området, framför banken, som vi listade ut hur tramparen funkade. När vi först såg konceptbilden visste vi att vi ville ha med den i spelet, men det var många frågetecken kring hur det skulle funka i praktiken. Vi hade aldrig flyttat något så stort genom spelvärlden, och något så stort behövde vara farligt – men hur skulle spelarna faktiskt slåss mot den? Precis som med alla våra fiender fanns det frågetecken kring hur spelupplägget skulle se ut. Vilka verktyg skulle våra nivådesigner behöva för att bygga scenarier med den? Det var såna frågor vi ville besvara med våra experiment på den här kartan."
N/A4166"#commentary\cn_254_sniper_streets.mp3" "[ Eric Kirchmer ] De var på de här gatorna, som är fulla av prickskyttar, vi utvecklade både fienden och kärnan i upplevelsen vi ville ge spelarna. Vi visste att vi ville att prickskytten skulle skjuta på saker nära spelaren, så först fokuserade vi på att hitta olika intressanta mål för skytten att skjuta. Vi märkte att det funkade bra om vi använde oss av spelarens vy för att välja föremål. Prickskyttens ständigt aktiva lasersikte innebar att spelarna var konstant medvetna om prickskyttens uppmärksamhet, så att låta siktet förflyttas till ett mål som spelarna tittade på kändes väldigt responsivt och spännande."
N/A4167"#commentary\cn_255_citizen_squad_details.mp3" "[ Matt Wright ] När vi hade fått till spelarens grupp med medborgare och börjat bygga scenarier runt den märkte vi att den skapade andra spännande möjligheter. Speltestarna började att bry sig om specifika gruppmedlemmar, så vi lade mer krut på deras design. Gruppmedlemmarna plockade upp bättre vapen om de hittade såna och gav spelaren ammunition efter behov – och sjukvårdarna läkte spelaren när så krävdes. Vi behövde också se till att gruppen kunde hålla jämna steg med spelare som ofta tog oväntade vägar. Bakom kameran ”fuskade” gruppen på olika vis – de regenererade hälsa mellan strider, rörde sig snabbt för att komma ikapp och kunde till och med teleportera sig vid behov."
N/A4168"#commentary\cn_256_citizen_squads.mp3" "[ Ken Birdwell ] Våra tidiga tester med strider mellan combine och medborgare pekade mot ett problem: utan gränser kunde strids-AI:n driva långt bort från spelarna. Soldaterna drog sig tillbaka för att ladda om eller ta skydd, och medborgarna jagade dem. Vi behövde ett sätt att få medborgarnas handlingar att matcha spelarens mål bättre och hålla dem medvetna om vart spelaren var på väg och vilka fiender spelaren ville strida mot. Det var det som ledde till att spelaren fick sin egen grupp med medborgare. Medborgar-AI:n använde den här gruppen för att röra sig med spelaren, anföll samma fiender och erbjöd ett enkelt gränssnitt för spelarkommandon. Till en början hade vi ett mer komplext kommandosystem, men eftersom det snabbt blev för rörigt förenklade vi det."
N/A4169"#commentary\cn_257_ai_behaviors.mp3" "[ Mike Dussault ] En AI-teknik vi utvecklade till Half-Life 2 var beteendesystemet. Beteenden var bitar av AI-kod som styrde NPC:er i specifika situationer. Vi hade exempelvis beteendet ”Led” som lät en NPC leda spelaren, och ”Följ” som lät en NPC följa spelaren eller en annan NPC. Beteendena samarbetade med NPC:ernas grundhandlingar, så en sjukvårdare i spelarens grupp som använde beteendet Följ för att följa efter spelaren visste även hur man skjuter på fiender, undviker granater och erbjuder förbandslådor."
N/A4170"#commentary\cn_258_occlusion.mp3" "[ Brian Jacobson ] I Half-Life 1 och stora delar av Half-Life 2 bestod världen till största del av tunnlar och korridorer, som funkade bra med ett BSP-träd (Binary Space Partition). Den här tekniken lät oss snabbt gå igenom geometrin och avgöra vad som kan vara synligt för en spelare. De öppna områdena på kusten och i andra utomhusområden passade dock inte den metoden, så vi behövde ny teknik. Områdesportaler var en lösning, som lät oss dela upp världen i stycken åtskilda av portaler – dörrar och fönster, alltså, inte såna man hittar på Aperture Science. Vi utvecklade även ett synlighetssystem, som mer eller mindre sa ”om spelaren inte kan se genom, över eller runt ett stort föremål ska den andra sidan inte renderas”. Det kanske låter uppenbart, men det krävs en hel del arbete för att se till att det inte tar längre tid att beräkna vad som finns på andra sidan av den stora grejen än att rendera allt. För att snabba på de beräkningarna placerade nivådesignerna stora ocklusionsvolymer i större terrängformer och stora siktblockerande föremål som byggnader. Under renderingen kunde vi testa föremåls gränser mot de här volymerna för att undvika rendering av sånt spelaren inte kunde se."
N/A4171"#commentary\cn_259_detail_objects.mp3" "[ Brian Jacobson ] När utomhussektionerna var igång var det uppenbart att de behövde någon form av ofta återkommande detaljer, så vi lade till mindre växtlighet, som gräs och små buskar, längs förskjutningsterrängen. Vi hade inte råd – det vill säga tid – att placera ut allt för hand. Därför byggde vi detaljföremålssystemet, som genererar små växtlighetselement automatiskt baserat på förskjutningsmaterialet. Varje material specifierar vilken sorts växtlighet som ska placeras ut samt en uppsättning parametrar. När kartan kompileras beräknar systemet slumpvalda punkter på ytan och väljer växtlighet att placera där. Eftersom det fanns prestandabegränsningar krävdes fortfarande en ganska komplex utplaceringsprocess för hand för växtlighet, så att allt kunde renderas på en gång."
N/A4172"#commentary\cn_260_displacements_1.mp3" "[ Charlie Brown ] Efter lanseringen av Half-Life 1 ville våra bandesigner och grafiker ha en bättre lösning för utomhusmiljöer, så vi byggde den första versionen av vårt terrängsystem. Det baserades på fyrsidiga polygoner som delades in i mindre delar. Tänk dig att man tar en platt kvadrat och delar in den i ett rutnät, där varje punkt i rutnätet kan flyttas uppåt eller nedåt. Våra nivådesigner kunde lägga upp flera kvadrater och sedan använda ett penselverktyg för att skapa kullar och dalar genom att justera punkterna i rutnätet. För rendering använde vi en specialtextur som kombinerade två olika texturer. Varje punkt i rutnätet specificerade hur mycket av varje textur som skulle användas, vilket möjliggjorde smidiga övergångar mellan ytor som sand, gräs, jord och grus. Den här sortens terrängsystem var inte ovanliga i spelmotorer på den tiden, och vi var naiva nog att tro att det skulle räcka för våra speldesigner."
N/A4173"#commentary\cn_261_displacements_2.mp3" "[ Charlie Brown ] När det ursprungliga terrängsystemet var igång tänkte vi att våra nivådesigner skulle använda det till utomhusområden. Istället började de experimentera med att lägga till detaljer på oväntade ställen. De använde systemet ovanpå väggar för att skapa förstörda kanter, rundade av trottoarer och försökte till och med att göra rör. Det gick inte alltid vägen, eftersom terrängsystemet byggdes för landskap och inte arkitektur. Vi återvände till kodgruvorna och förvandlade det höjdbaserade terrängsystemet till ett fullfjädrat 3D-förskjutningssystem. Nu kunde våra designer inte bara flytta punkterna i rutnätet uppåt och nedåt, utan i alla riktningar. Det lät dem ge alla sorters ytor extra detaljer och använda blandade texturer för att lösa smidigare övergångar mellan förskjutningspolygonerna och BSP-geometrin. Det krävde dock extra teknikarbete att se till att belysningen var konsekvent mellan de två renderarna, annars hade det uppstått en uppenbar skillnad. När allt det här var klart verkade nivådesignerna nöjda, och vi var naiva nog att tro att det räckte."
N/A4174"#commentary\cn_262_displacements_3.mp3" "[ Charlie Brown ] När nivådesignerna hade fått det allmänna förskjutningssystemet nöjde de sig inte bara med att göra världen mer detaljerad, utan återvände till sitt ursprungliga mål med att bygga storskaliga utomhusdelar. Det ledde till en till omgång uppdateringar för att balansera prestandan och se till att systemet kunde hantera både små detaljer och större markterräng. Textureringen behövde också förbättras, särskilt för att möjliggöra komplexa skapelser som överhängande klippor, som inte var möjliga med det ursprungliga höjdbaserade systemet. Våra designer nöjde sig aldrig med sina åstadkommanden utan började även använda förskjutningar för att skapa grottor och tunnlar. De såg fantastiska ut men krävde ännu fler tekniska justeringar. Till sist lyckades vi få ordning på alla konkurrerande krav på hur förskjutningar skulle användas, och vi använde dem i stora delar av spelvärlden. I efterhand så är förskjutningarna ett tydligt exempel på hur teknik och speldesign utvecklas tillsammans. Det är ett hönan-eller-ägget-problem – vi kan inte förutse alla sätt ny teknik påverkar spelet på, men vi kan samtidigt inte skapa tekniken utan att ha ett mål för den. Vi måste, som alltid, bygga något. Vi börjar med kvalificerade gissningar och ser var vi hamnar."
N/A4175"#commentary\cn_263_particles.mp3" "[ Chris Green ] Med Source-motorn ville vi utöka partikel- och specialeffektsteknik. Det möjliggjorde mer realistiska och komplexa partikelrörelser, samt mer komplexa former och shader-effekter. När vi gav våra partikelfunktioner bumpmapping förändrades deras volumetriska utseende rejält. Senare versioner av Source-motorn hade en kraftfull partikelsystemsredigerader, men den ursprungliga versionen i Half-Life 2 förlitade sig på handgjorda effekter – som alla krävde att en programmerare noggrannt byggde effekten manuellt, vilket var en rätt krävande process."
N/A4176"#commentary\cn_264_cubemaps.mp3" "[ Chris Green ] När vi lade till material och shaders behövde vi en lösning för reflekterande ytor som glas och stål. De här ytorna behövde veta vad de skulle spegla, men år 2003 gick det inte att rendera sånt i realtid. Därför utvecklade vi cubemap-systemet för förberäknade reflektioner. En cubemap är sex bilder på insidan av en kub, som fångar miljön åt varje håll – tänk dig en panoramabild som omger dig på alla sidor. Våra nivådesigner placerade osynliga markörer på nivåerna, och när kartan kompilerades genererade vi en cubemap vid varje markör. När man spelar spelet och en reflektiv yta ska renderas letar vi upp närmaste förberäknade cubemap för att skapa reflektionen."
N/A4177"#commentary\cn_265_water_shader.mp3" "[ Gary McTaggart ] Den mest komplexa shadern vi skapade till spelet var vattenshadern, som utnyttjade programmerbara grafikkort, som var nya på den tiden, till fullo. När det fanns vatten renderades scenen tre gånger. Först renderades världen under vattnet för brytning, sen renderades en reflekterad vy, och sen det som fanns över vattnet. När vi rendererade vattenytan blandade vi brytnings- och reflektionsvyn och använde Fresnel-ekvationen för att visa mer spegling i vissa vinklar. Vi höll även koll på djupet under vattenytan och gjorde det mer genomskinligt med mindre brytning i grunda områden. Dessutom var vi tvungna att skapa två alternativa vattenrenderingstekniker för svagare grafikkort: grafikkort i mellanklassen visade mindre detaljerade reflektioner utan brytning eller genomskinlighet, medan svaga grafikkort bara renderade en delvis genomskinlig yta."
N/A4178"#commentary\cn_266_normal_maps.mp3" "[ Gary McTaggart ] Half-Life 2 utvecklades under en spännande tid för grafik, när de första grafikkorten med stöd för programmerbara shaders släpptes. Med den tekniken blev vi ett av de första spel som implementerade normalkartor: en teknik som förbättrade belysningen på ytgeometri. En normalkarta beskriver ytans ojämnhet, vilket låter varje pixel i en polygon belysas på ett sätt som får ytor att se gropigare och mer detaljerade ut än vad som var möjligt i Half-Life 1."
N/A4179"#commentary\cn_267_rendering_systems.mp3" "[ Gary McTaggart ] Under det tidiga 2000-talet hade vi inte råd med en allmän renderare med en modern motors många möjligheter. Begränsningar kring processorer, grafikkort och minne krävde väldigt specifika lösningar på renderingsutmaningar så att vi kunde klämma den sista lilla biten prestanda ur spelarnas hårdvara. Som ett resultat av det har Half-Life 2 faktiskt tre olika renderingsmotorer: en för världsgeometri, en andra för utomhusterräng och en tredje för dynamiska saker som karaktärer och objekt. De här tre renderarna behövde ha stöd för en komplicerad uppsättning funktioner – kollisioner, raytracing, dekaler, offlinebelysning, synlighetsberäkningar och så vidare. Dessutom behövde varje renderare stödja DirectX 7, 8 och 9. De här DirectX-versionerna skiljde sig åt rejält och krävde olika sorters datalagring och rendering – de använde till och med olika programmeringsspråk! Allt som allt hade vi nio olika renderare, som alla behövde unika lösningar, och att få alla att se konsekventa ut var ett av de svåraste tekniska problemen vi ställdes inför under utvecklingen."
N/A4180"#commentary\cn_268_dynamic_shadows.mp3" "[ Gary McTaggart ] Eftersom vi fokuserade på karaktärer och fysikobjekt kände vi att det krävdes ett dynamiskt skuggsystem för att rendera dem i all sin prakt. År 2003 hade inte grafikkort de skuggningsmöjligheter de har idag, så prestandan var ett knepigt problem. Lösningen vi kom fram till funkade så här, och kördes varje bildruta: Först hittade vi alla objekt som kan ha skuggor i synfältet. Vi var tvungna att hitta alla objekt som fanns inom synfältet, eller strax bakom det, för att upptäcka saker som var ur bild men vars skugga kunde hamna i bild. Sen renderade vi en svart skuggversion av vart och ett av de här föremålen till en enda skuggtextur. I den renderingen använde vi den minst detaljerade modellen för objektet, för att det skulle gå snabbt som möjligt. Sen använde vi skuggtexturen för att rita var och en av skuggorna i spelarens synfält och göra de redan renderade pixlarna mörkade. Vi klippte försiktigt runt varje skugga i den skuggtexturen, för att se till att de låg korrekt ovanpå varandra ifall flera skuggor överlappade varandra. Det är trevligt att titta tillbaka på hur vi löste sånt – men vi är otroligt tacksamma för modern grafikkortshårdvara, som gör det till ett mycket enklare problem."
N/A4181"#commentary\cn_269_combinatorial_shader_explosion.mp3" "[ Gary McTaggart ] Renderingen blev mycket mer komplex under utvecklingen av Half-Life 2, när det tillkom hårdvarushaders, små kodsnuttar som styrde hur mycket varje pixel på en yta skulle rendera. År 2003 var shaders mycket mer begränsade än idag: shaders från Half-Life 2:s tid saknade stöd för villkor och hade strikta begränsningar på kodstorlek. Det innebar att det inte gick att justera beteendet efter olika villkor, och att man inte kunde göra stora shaders med breda funktionsuppsättningar. Kompilering av shaders efter behov gick för långsamt för att vara användbart, så vi var tvungna att förkompilera dem. För att kunna arbeta inom de begränsningarna behövde vi även beräkna varje möjlig shaderkombination och spara var och en som en egen shader. Om en shader exempelvis påverkade en yta baserat på en enda ljuskälla behövde vi en ny version för två ljuskällor, en till för tre och så vidare. Det var kombinatoriskt – om shadern även stödde en normalkarta behövde vi två versioner per ljuskälla, en med normalkartan och en utan. Eftersom vi hade funktioner som texturblandning, vertexfärgning, blänk, alfatestning och olika typer av ljuskällor – riktade, punktbelysning, spotlights – exploderade shadermängden. När spelet släpptes hade vi tusentals individuella shaders. Kort därefter släppte vi Lost Coast, som lade till HDR-stöd och dubblerade shadermängden igen. När det började ta för lång tid att kompilera shaders lokalt på utvecklarnas datorer gick vi över till att distribuera shaderkompileringen över hela nätverket med VMPI. Vi hade även ett dynamiskt shaderskompileringsläge, som var användbart för att utveckla shaders som snabbt kom igång, med nackdelen att bildfrekvensen sjönk när en shader behövde kompileras."
N/A4182"#commentary\cn_270_gpu_wild_west.mp3" "[ Jay Stelly ] Under utvecklingen ställdes vi inför många beslut som påverkades av vårt val av minimisystemkrav – den svagaste kombinationen av processor och grafikkort som ändå skulle ge kunderna en bra upplevelse. På 2000-talet fanns det mycket större variation bland grafikkort än idag. Det var inte bara hastigheten som skiljde sig, utan även den grundläggande renderingen. Samtidigt hade vi inga riktiga data på vilken hårdvara våra kunder använde. Vilka processorer och grafikkort hade de? Hur mycket RAM? Vilken Windows-version? Vi hörde av oss till Microsoft och hoppades att de skulle ha svar på frågor som ”Hur många DX7-kort används? Och DX8?”. Tyvärr hade de inga data på det. Vi insåg att vi riskerade att fatta dåliga beslut utan den sortens information och utvecklade ett analysverktyg som lät spelare rapportera sina hårdvaruspecifikationer till oss, som vi integrerade i den tidiga versionen av Steam. Den informationen var så användbar att vi bestämde oss för att göra den offentlig och lanserade Steams hårdvaruundersökning i april 2003. Den har hjälpt oss – och förhoppningsvis andra utvecklare – att fatta välgrundade beslut sen dess."
N/A4183"#commentary\cn_271_3d_skybox.mp3" "[ Jay Stelly ] Vi har alltid behövt rita upp en värld som känns större än våra kartbegränsningar tillåter. I Half-Life 1 använde vi en cubemap-textur för att låta spelare se bortom det spelbara området. I Half-Life 2 ville vi att den inblicken i den större världen skulle vara dynamisk och inte bara en statisk textur. Vår kartstorlek var begränsad till ca 800 m i varje riktning, men vi insåg att vi kunde skapa en mycket större yttre värld om vi lagrade den i mindre skala. Då uppfann vi det vi kallar 3D-skyboxen. 3D-skyboxen är en liten låda gömd på den riktiga spelkartan, som innehåller geometri i 1/16-skala. I den finns en referenspunkt som matchar mot en motsvarande punkt på huvudkartan. När vi renderar utrymmet bortom det spelbara området använder vi geometrin från 3D-skyboxen, positionerad enligt referenspunkten och uppskalad till 16 gånger storleken. Det blev en del knepiga utmaningar med att få ljussättning och dimma att gå ihop utan skarvar när vi gick från huvudkartan till skyboxen, men det funkade. Som resultat kändes världen mycket större och mer stämningsfull än Half-Life 1."
N/A4184"#commentary\cn_272_missing_material.mp3" "[ Jay Stelly ] Tidigt i utvecklingen av lågnivågrafikkoden insåg vi att det skulle vara svårt att se polygoner som inte renderades till följd av en saknad textur. När det skedde blev det oftast bara svart där polygonen skulle vara, vilket var lätt att missa i mörkare scener. För att fånga upp den här buggen på ett mer pålitligt vis skapade vi en feltextur som inte skulle gå att missa och skulle genereras automatiskt när det inte gick att ladda en textur. Det här ledde till den ikoniska lilasvarta schackrutiga texturen, som har fått eget liv långt bortom Half-Life 2."
N/A4185"#commentary\cn_273_air_resistance.mp3" "[ Jay Stelly ] En viktig funktion som vi behövde lägga till i vår fysikmotor till Half-Life 2 var luftmotstånd. På den tiden brukade fysikmotorer använda en allmän dämpningsfunktion för att sakta ner rörliga objekt , men det tar bara bort energi på ett symmetriskt sätt. För att skapa mer trovärdig rörelse bestämde vi oss för att simulera luftmotstånd istället. Det lät oss få asymmetriskt beteende, där hur mycket objektet saktades ner i luften varierade beroende på hur mycket av föremålets yta som var vänd mot rörelse- eller rotationsriktningen. Den här funktionen var viktig för att få explosioner och föremål som kastades av gravitationsvapnet att kännas trovärdiga. Snabbt rörliga och snabbt snurrande föremål är bland de dyraste sakerna att simulerar i Half-Life 2:s fysikmotor, så luftmotståndet förbättrar processorprestanda vid exempelvis explosioner. Det är även viktigt för att demonstrera olika objekts diverse material och massor. Objekt med högre densitet kan knuffa undan luft enklare, och det är lätt att se. När vi har den här effekten i simuleringen gör det skillnaden i densitet mellan kartonger och plankor med uppenbar, och det får objekten i Half-Life 2:s värld att kännas mer övertygande."
N/A4186"#commentary\cn_274_early_tech_planning.mp3" "[ Ken Birdwell ] Vi lär oss alltid mycket av att lansera ett spel – vi får äntligen reda på vilka beslut som var bra, och vilka vi kan göra annorlunda till nästa gång. Efter Half-Life 1 satte vi oss ner för att fundera på vad vi skulle kunna göra för uppföljare, och då hade vi alla möjliga sorters spelarfeedback att gå igenom. Därifrån försökte vi att sätta ihop en lista över saker Half-Life 2 skulle fokusera på. Vi försökte inte att designa en viss spelarupplevelse, utan tyckte det var bättre att närma oss frågan ur ett tekniskt perspektiv. Black Mesas vakter och forskare funkade bra. Vad kunde vi göra om vi fokuserade stenhårt på karaktärer? Vi gillade vårt interaktiva berättande. Vad kunde vi hitta på för att göra ännu mer av det, med större variation? Spelarna tyckte att det var spännande att utforska och interagera med Black Mesa. Kanske kunde vi ta det längre med ett fysiksystem? Inom alla de här områdena funderade vi på hur den bästa versionen av våra idéer skulle kunna se ut flera år in i framtiden, och sen arbetade vi baklänges för att komma fram till olika tekniska steg som skulle ta oss dit."
N/A4187"#commentary\cn_275_character_lighting.mp3" "[ Ken Birdwell ] Under det första utvecklingsåret hade vi problem med att få våra karaktärer att kännas så realistiska som vi ville. Vi hade faktiskt många olika problem, som alla krävde specifika tekniska och grafiska förbättringar för att lösa. Det första stora problemet var ljussättning. På den här tiden fanns det många genvägar inom ljusteknik i spel. En del fanns av prestandaskäl, medan många fanns till följd av missförstånd kring hur allt funkar. På den tiden fick man karaktärerna att se bra ut genom att skapa deras modeller och texturer med deras belysningslösning, exempelvis skuggor och glansighet, inbyggd i dem. Karaktärerna såg häftiga ut men var uppenbart spelkaraktärer. Vi började bygga Alyx enligt den här metoden, för det var så man skulle göra. Vi använde inbyggda lösningar och belyste henne som en filmskådis – som om hon hade en egen ljusrigg som följde henne och såg till att hon alltid såg bra ut. Men det funkade inte riktigt. De många olika ljusmiljöerna, samt spelmediets dynamiska natur, gjorde att hon såg fantastisk ut i vissa miljöer, men nånstans såg hon alltid hemskt orealistisk ut. Vi provade att justera hennes ljusrigg och utöka dess möjligheter, men till sist kändes det som att vi hade kört fast. Vi gick tillbaka till ritbordet och provade en annan metod. Vi byggde henne och ljussättningen och texturerna från grunden och slängde bort allt annat. Vi fokuserade inte på hur hon skulle se ut i perfekta ljusförhållanden utan hur saker skulle funka rent realistiskt. Det låter kanske uppenbart, men det var inte så man gjorde då – åtminstone inte i spel. När vi tittade på modellerna och texturerna utanför spelets renderare såg de faktiskt sämre ut än tidigare versioner. Vi lyckades att metodiskt montera ner alla genvägar och missförstånd om hur ljus och texturer och grafikkort funkar och sätta ihop allt igen. När allt det var gjort kunde vi äntligen titta på Alyx i spelet, med sin nya modell och sina texturer, i en dynamisk miljö som såg till att hon ständigt var visuellt konsekvent, och hon såg fantastisk ut. Hon passade perfekt i Half-Life 2:s värld."
N/A4188"#commentary\cn_276_gamma_correction.mp3" "[ John Morello ] Vår spelmotor har ett renderingssystem som ansvarar för att ta hela spelets tillstånd och beräkna ett färgvärde för varje pixel på ens skärm, som representerar det tillståndet. Kod och programvara från andra personer är också del av att beräkna de pixlarna. Ta till exempel program- och hårdvaran i ditt grafikkort och din skärm. Vid ett tillfälle under utvecklingen var vi missnöjda med hur våra karaktärer ser ut. Vi tyckte att de såg ut som vaxdockor, eller att de såg sjuka ut. Det var fel på deras hud. Vi lade tid på att finjustera ljussättningen, men fick helt enkelt inte till karaktärerna och världen. Som tur var hade vi en fullfjädrad programvarurenderare som lät oss köra spelet utan ett grafikkort, för på den här tiden var det inte alla som hade ett. När vi tittade på spelet med den renderaren märkte vi att vår ljussättning inte hade samma problem. Vi finkammade koden för att försöka ta reda på var vår renderingskod gjorde fel när den arbetade med ett grafikkort. När det inte gick provade vi att prata med grafikkortstillverkarna och be dem dubbelkolla att de inte gjorde några fel med pixelvärdena vi gav dem. Det var början på en lång resa – och för att göra en lång historia kort tog det nästan två år av diskussioner med grafikkortstillverkarna innan vi kunde övertyga dem att de gjorde fel med gammakorrigeringen i lågnivåmatematiken på deras kort. Under den här tiden hade vi till och med behövt bygga ett system som validerade färgvärdena på en enskild pixel under hela vår renderingspipeline. I slutändan fick vi äntligen nya drivrutiner och då såg våra karaktärer direkt ut som de skulle. De matchade programvarurenderaren."
N/A4189"#commentary\cn_277_facial_technology.mp3" "[ Ken Birdwell ] Vi ville att spelarna skulle bry sig om karaktärerna, och för att ha minsta chans att lyckas med det behövde vi investera i massor av teknik till våra figurers ansikten. Det är allmänt känt att människor är gjorda för att bry sig om ansikten och omedvetet utläsa all möjlig information från dem. Det är en extremt hög ribba, och om vi inte kunde nå den så skulle vi nog driva bort spelarna från karaktärerna, snarare än till dem, som vi ville. Vi började med att göra massor av research. Det var inte uppmuntrande. De bästa exemplen vi kunde hitta var inte ens i närheten av att kunna köras i realtid, medan de bästa realtidslösningarna inte ens var i närheten av kvaliteten vi ville ha. Vi ville att de skulle se lika bra ut som i en animerad film, men de tog oftast flera timmar på sig att rendera bildrutor och var helt linjära, gjorda av upp till hundra animatörer, medan våra ansikten skulle vara dynamiska – en karaktär skulle kunna prata och ha ett minspel som utgår från spelarens handling, och vara skapad av bara ett fåtal grafiker. De här kraven ledde oss till dr Paul Ekmans Facial Action Coding System, ett system framtaget på 70-talet för att kategorisera mänskliga ansiktsrörelser. Det gav oss ett vokabulär för att beskriva ansiktsrörelser genom våra verktyg och vår kod, samt ett mål att sikta på när vi designade figuerernas ansikten. Med det som ramverk påbörjade vi en mångårig process för att utveckla hur vi byggde ansikten och huvuden till våra karaktärer. Andra hade provat att ta lite av Ekmans arbete, men vi ville försöka använda allt. Vi lade mycket tid på att lista ut hur varje del skulle funka inom de snäva prestandabegränsningar vi hade. Vi lade även en hel del tid på att bara titta på folk och deras ansikten för att försöka lista ut vilka egenskaper som skulle ge störst värde – exempelvis hudelasticitet och tänders skuggning. I slutändan kunde vi inte göra allt vi ville, men vi lyckades att få till de bitar som vi tyckte var viktigast för att skapa övertygande ansiktsuttryck till karaktärerna."
N/A4190"#commentary\cn_278_eye_shader.mp3" "[ Ken Birdwell ] En annan viktig del av att göra övertygande karaktärsansikten var ögonen. Människor är väldigt bra på att läsa av ögon. Hjärnan har en särskild del för det, som kan lista ut vart någon tittar baserat på ögonglobernas reflektioner. Det finns alla möjliga små detaljer som spelar roll. Ögonen är egentligen inte klot. Ögonlock påverkas av hur hornhinnan rör sig under dem. Ögonrörelse medför högre chans att blinka. Ögonen är faktiskt inte helt raka bakom pupillen, utan är något förskjutna. Alla de här detaljerna kan kännas små eller omärkvärdiga, men när de inte finns där känns karaktärerna mindre trovärdiga. Vi jobbade på ögonen under lång tid och förbättrade ögonens modeller och funktioner steg för steg. Vissa saker krävde externa gränssnitt, som vilka saker i miljön som var intressanta att titta på, medan andra var automatiska och undermedvetna i AI:n – som blinkningar, ett uppenbart krav som dock blir förvirrande om det görs fel. Ögonreflektioner hade särskilt stor påverkan – de tar upp väldigt lite plats på skärmen, men de gjorde enorm skillnad. Vi visste att vi var klara när vi nådde en punkt där karaktärerna såg ut som dockor om vi stängde av vår ögonshader – de liknande människor men var inte övertygande, på ett sätt som var svårt att beskriva. Men när vi slog på den igen kändes det som att det var människor som tittade på oss."
N/A4191"#commentary\cn_279_combine_gunship.mp3" "[ Ken Birdwell ] Kanonskeppet var ett intressant problem. Vi hade redan en helikopterflygmodell och hade inte tid att bygga något helt nytt. Vi anpassade helikopterns flygmodell tills den kändes annorlunda nog och baserade sedan kanonskeppets organiska animationstillstånd på värdena som kom ur den simuleringen. Vi siktade även på att hålla det så ärligt som möjligt. Det finns till exempel en begränsning gällande hur mycket det får vrida på huvudet för att sikta med kanonen, och om det behöver sikta längre än så måste det ändra sin flygväg för att få kanonen rätt – det får inte fuska. Den andra huvudfunktionen var motorljudet. Vi har rumsbaserat ljud, så spelaren kan lista ut ungefär var det är. Kanonskeppet rör sig snabbt, uppe i luften, långt från närliggande referenspunkter. Därför kan det vara svart att avgöra exakt hur långt bort det är och hur snabbt det rör sig. Därför lade vi till en dopplereffekt på motorljudet, som skiftar tonhöjden baserat på kanonskeppets hastighet relativt dig. Det är en subtil effekt, men den är extremt effektiv på att få en att undermedvetet uppfatta var kanonskeppet befinner sig och vilken riktning det rör sig i. Viktig information som låter en veta att man jagas."
N/A4192"#commentary\cn_280_risk.mp3" "[ Ken Birdwell ] När vi tittar tillbaka på Half-Life 2 nu, 20 år senare, får vi oss en tankeställare när vi tänker på hur läskig stora dela av utvecklingen var. Spelutveckling är svårt. Man får aldrig riktigt vad man är ute efter, nämligen möjligheten att kunna utvärdera risker innan man börjar lägga på mer. Ansiktsanimationstekniken, till exempel… Det tog nog runt 3–4 års arbete innan vi var säkra på att det faktiskt skulle funka. Vi kunde inte vänta så länge. Under det första året började vi göra många andra val i vår speldesign, vår produktion av spelmaterial och våra andra tekniker – alla baserade på antagandet att vår ansiktsanimationsteknik skulle funka i slutändan ur kvalitets- och prestandasynpunkt. Hade den inte gjort det hade många andra val inte funkat heller. Samma riskprofil gäller många andra stora val vi gjorde tidigt. Vi kan inte vänta – vi måste bygga och hoppas att våra gissningar stämmer om några år. Jätteläskigt."
N/A4193"#commentary\cn_281_hugs_and_pickups.mp3" "[ Ken Birdwell ] Ibland kan det vara en mardröm att få småsaker att funka, exempelvis att få två karaktärer att kramas, eller något så enkelt som att plocka upp ett föremål från ett bord. Något som krånglar till det ytterligare är vår dynamiska miljö, där karaktärerna och föremålen inte befinner sig på förbestämda platser och spelaren springer runt och hamnar i vägen. Det kräver en nivå av synkronisering som kan bli knepig. Det blir extra knepigt eftersom människor gör det här utan att tänka. När man går till ett bord för att plocka upp en kopp gör man alla möjliga förberedelser med kroppen för att få ens händer och fötter på rätt plats för att göra det på ett bekvämt sätt. Allt är redo när man kommer dit. Om man går in för att krama någon gör båda parterna det på samma gång justerar kroppen baserat på varandra rörelser. För att få det här att funka i spelet krävdes mycket synkroniseringsarbete för att göra karaktärerna medvetna om varandra och världen. Samtidigt var vi tvungna att få mer medvetna om sina framtida planer. Det är frestande att vilja dela upp exemplet med koppen i tydliga steg – gå till bordet, vänd dig mot koppen, plocka upp koppen – det är mycket enklare så, och då kan man återanvända stegen. Men så funkar robotar, inte människor. Våra karaktärer behövde veta att de var på väg till ett bord för att plocka upp en kopp, så att de kunde jobba på flera delar av det samtidigt och se till att deras händer tar koppen precis när de kommer fram. Med två karaktärer blir det ännu mer av en förhandling. Båda parter måste gå med på var och när saker ska hända, och allt måste hända på plats utan skarvar. De här enkla interaktionerna mellan karaktärerna är ofta korta, men de var viktiga för att få dem att kännas som trovärdiga personer."
N/A4194"#commentary\cn_282_ropes.mp3" "[ Mike Dussault ] En sak vi märkte i alla referensbilder vi samlade till Stad 17 var att det gick kablar och sladdar överallt, och att de var en stor del av den dekor spelaren såg. Vi älskade hur de här gamla europeiska städerna snärjts i det moderna livets kaotiska nät. Vi kände att vi behövde en lösning för kablar, rep och dylikt och ville att de skulle vara dynamiska. Våra nivådesigner ville gärna skapa kontaktpussel, och om en kontakt hade en kabel till sig var det lättare för spelare att förstå mekaniken. Tidigt i produktionen byggde vi ett repsystem och finslipade det under utvecklingen. Under huven består varje rep av flera segment som sträcker sig mellan de två ändpunkterna och kan röra sig oberoende av varandra. Varje segment beter sig som en fjäder och reagerar på krafter i spelvärlden, som en lugn vind eller ett combine-kanonskepp som far förbi. När segmenten renderas är de vända mot kameran och har bumpmapping, vilket är viktigt för att få dem att se realistiska och avrundade ut."
N/A4195"#commentary\cn_283_vmpi.mp3" "[ Mike Dussault ] Under utvecklingen blev vi allt mer frustrerade över hur långsamt det gick att justera grejer, särskilt eftersom kartkompileringen – som krävs för att beräkna belysning och synlighet – tog flera timmar. År 2000 var datorerna mycket långsammare än idag och de hade bara en processorkärna var. Vi inspirerades av SETI@Home, ett distribuerat program som använde datorer över hela världen för att analysera radiovågor efter tecken på utomjordiskt liv, och byggde VMPi – ett egetdistribuerat system som spred ut kartkompileringsprocessen över många kontorsdatorer. Idag körs sådana distribuera system på stora grafikkortskluster, men på den tiden körde vi det på alla datorer på kontoret. För att ta itu med hur vår belysningskod utvecklades lika snabbt som kartorna skickade VMPi även nya .exe-filer till allas datorer. I efterhand var det fruktansvärt otäckt ur säkerhetssynpunkt. Bedrövligt dåligt. En riktig mardröm för it-folk. Vi skickade godtycklig programvara till alla datorer på kontoret och folk bara körde den. Det var galet. Men det funkade och ökade kartiterationshastigheten. Därför blev det ett viktigt verktyg."
N/A4196"#commentary\cn_284_field_of_view.mp3" "[ Kerry Davis ] I Half-Life 1 använde vi ett 90-gradigt synfält, som var ganska typiskt i skjutspel på den tiden. Under Half-Life 2:s utveckling blev vi missnöjda med det. Som följd av spelets fokus på karaktärer hade vi lagt ner mycket arbete på detaljerade ansikts- och kroppsanimationer, men det 90-gradiga synfältet lät inte spelarna komma nära nog för att uppskatta de detaljerna. Vi började att experimentera med ett snävare synfält och nöjde oss med 75 grader. Det krävdes lite justering för både oss och spelarna, och det krävdes ett extra synfält för perspektivmodeller – spelarens vapen vid botten av skärmen. De modellerna byggdes med ett 90-gradigt synfält i åtanke, så de såg fel ut med 75 grader. Den här ändringen lyckades med det vi ville: att sätta karaktärerna i första rummet."
N/A4197"#commentary\cn_285_reference_maps.mp3" "[ Randy Lundeen ] När våra karaktärer blev mer verklighetstrogna mellan Half-Life 1 och Half-Life 2 ville vi att världen skulle kännas lika realistisk. I Half-Life 1 gjorde FPS-genrens begränsningar ofta det enklare att förlita sig på stiliserade eller abstrakta miljöer. Med Half-Life 2 ville vi skapa en värld som kändes grundad i verkligheten, vilket innebar att vi fokuserade på många fler små detaljer vi inte fokuserat på förr. Ett av de viktigaste stegen var att skapa referenskartor för att standardisera hur verkliga proportioner skulle översättas till spelet. De här kartorna specificerade detaljer som mått på väggar och dörrar, hur högt dörrvred skulle sitta, interiörbelysning, möbelskala och den allmänna skalan på vanliga föremål. Vi skapade standardiserade texturer för bandesigner, kompletta med skalnings- och belysningsvärden så att layouterna skulle vara konsekventa från början. Förutom att vi lade grunden för den fysiska världen definierade de här referenskartorna hur spelarna rörde sig genom den – hur högt de kunde klättra, hur länge de kunde huka sig och hur stora exempelvis ventilationstrummor skulle vara. Med de här kartorna som grund kunde vi hålla världsgeometrin konsekvent och se till att spelets utrymmen hade en realistisk storlek."
N/A4198"#commentary\cn_286_response_rules.mp3" "[ Scott Dalton ] Vi visste tidigt att vi ville ha mycket dynamisk dialog i spelet, så vi behövde ett system för att hantera den effektivt. Vi satsade på ett system som lät våra ljuddesigner att lägga till och anpassa repliker utan programmerares inblandning, gjorde dialogen responsiv på spelets tillstånd och minimerade upprepningar. Utifrån de här kraven skapade vi svarsregelsystemet. När en karaktär pratar utanför en koreograferad scen avgör systemet vilken replik som ska sägas. Istället för att köra repliker direkt signalerar karaktärs-AI:n ”möjligheter att prata” när en relevant händelse sker – som att en karaktär ser spelaren, blir skadad, tömmer magasinet på sitt vapen, möter övermäktiga fiender och så vidare. För varje möjlighet skickar karaktärs-AI:n ett datapaket till svarsregelsystemet, med information om spelets tillstånd, och systemet skickar tillbaka den lämpligaste repliken om en sådan finns. Det här arbetssättet lät våra ljuddesigner skapa en detaljerad beslutsmatris för dialog. Exempelvis kanske en karaktär har olika repliker när den laddar om i strid gentemot om den laddar om efter strid, eller om det bara finns en allierad kvar, eller om den har en trampare i sikte. När vi var klara med Half-Life 2 kände vi att vi bara skrapat på ytan gällande spelets potential. Det blev en viktig del av Episode 1:s Alyx och drev dynamisk dialog i våra senare spel, så som TF2:s klasser och huvudpersonerna i Left 4 Dead."
N/A4199"#commentary\cn_287_audio_caching.mp3" "[ Yahn Bernier] Ett annat problem var den enorma mängden ljud i spelet. Alla spelljud samt all musik och dialog blev för mycket för att lagra i minnet – minne var en lyx år 2003. Men som kanske kan föreställa dig behövde vi kunna spela ljud direkt, särskilt om de var spelrelaterade. Vi byggde en ljudcache som bara lagrade de första 125 millisekunderna av varje ljudfil och höll dem i minnet. Den tiden var vår bästa gissning på hur lång tid det skulle ta oss att strömma en ljudfil från hårddisken. När ett ljud spelades i spelet spelade vi början av det från vår ljudcache, medan vi laddade den fullständiga filen från disken. När början, som hade cachats, tog slut var filen laddad och vi kunde spela resten av ljudet. Det fanns några andra små funktioner, som att hålla nyligen använda ljud helt i minnet så att frekvent använda ljud inte konstant behövde laddas. I dagens spelmotorer använder allt möjligt material, inte bara ljud, sig av liknande strategier."
N/A4200 
39184201}
39194202}