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

From Team Fortress Wiki
Jump to: navigation, search
39203920"wood.scraperough" " "
39213921"plastic_box.scraperough" " "
39223922 
N/A3923"#commentary\cn_001_physics_sound.mp3" "[Jay Stelly] Perché la fisica risultasse verosimile, anche i suoni prodotti dalla fisica stessa dovevano risultare credibili. Come esseri umani, siamo abituati ai suoni prodotti da oggetti e materiali durante le interazioni, anche se li diamo per scontati. Pur sapendo di non poter riprodurre tutto, volevamo concentrarci sui pochi dettagli necessari a rendere realistica la nostra fisica. Abbiamo iniziato con i suoni di ciascun oggetto per gli impatti. Questo consentiva a un solido, come una cassa di legno, di emettere suoni personalizzati entrando in collisione con altri oggetti simili o di altre categorie. Poi siamo passati a modificare dinamicamente questi suoni in base alle caratteristiche dell'evento fisico, come le masse coinvolte e la forza d'impatto. Questa soluzione funzionava alla grande per le collisioni, ma non altrettanto bene con altri tipi di interazione, come la frizione. Una cassa di legno emette un suono diverso se gratta contro un muro o se gli viene lanciata contro. Dubito che qualcuno abbia studiato più a fondo di noi le proprietà fisiche di una cassa di legno! Per ottenere ciò che volevamo da queste interazioni, abbiamo implementato un diverso suono di collisione per ogni singolo materiale: metallo contro legno, metallo contro metallo e così via. Inoltre, gli effetti sono stati modificati dinamicamente in base ad altri aspetti, come la durezza del materiale o il tipo di metallo. Per mettere a punto questo sistema sono stati necessari innumerevoli aggiustamenti, che abbiamo potuto individuare solo giocando. Avevamo anche realizzato dei suoni personalizzati per il rotolamento degli oggetti, ma alla fine abbiamo accantonato la funzionalità perché non eravamo soddisfatti dei risultati."
N/A3924"#commentary\cn_002_ramming_with_the_buggy.mp3" "[Jay Stelly] Il nostro sistema fisico è basato su corpi rigidi, pertanto non supporta alcuna deformazione o distruzione dei solidi. Se un oggetto fisico viene colpito, può muoversi se gli è consentito, altrimenti non succede nulla. Quindi, se sfondi una finestra con la dune buggy, dobbiamo ricorrere a qualche trucco perché il risultato funzioni. Poiché la finestra è fissa, il sistema di fisica fa rimbalzare il mezzo contro di essa, ma avvisa il sistema di gioco che si è verificata una collisione. Il sistema di gioco gestisce le distruzioni, per cui frantuma il vetro e ordina al sistema di fisica di iniziare a simulare i frammenti. Soprattutto, il sistema di gioco ordina al sistema fisico di riportare la dune buggy allo stato in cui si trovava prima dell'impatto. In questo modo, alla successiva simulazione della fisica, il veicolo potrà attraversare la finestra rotta. Questo processo genera uno scarto di un frame nella fisica del veicolo, che si blocca per un attimo e viene teletrasportato all'istante precedente lo schianto. Speriamo che questa consapevolezza non vi renda Half-Life 2 totalmente ingiocabile! I test di gioco condotti all'epoca, tuttavia, ci hanno convinti che quel breve scatto funziona: aumenta il senso di impatto."
N/A3925"#commentary\cn_003_ramming_zombies_with_the_buggy.mp3" "[Jay Stelly] Come esseri umani, ci aspettiamo che il mondo fisico si comporti in determinati modi, come detto. Per esempio, se investi uno zombi con l'auto, ti aspetti che venga sbalzato in aria. Tuttavia, ottenere questo risultato in un gioco non è immediato come nella realtà. Per motivi legati alle prestazioni, i nemici come gli zombi usano un'area di collisione semplificata. È un'area che avvolge interamente il modello, nessuna parte esclusa. Ma quando muore, lo zombi viene convertito in una marionetta con aree di collisione più precise e disposte su ogni arto, una soluzione che richiede un dispendio di risorse maggiore per essere simulata. Questo cambio di modello di collisione aumenta la complessità quando investi uno zombi con la dune buggy, al di là dello scatto di frame. Quando l'auto colpisce il nemico, tocca inizialmente l'area di collisione semplificata. Il gioco uccide quindi lo zombi, tramutandolo in una marionetta che il sistema di fisica inizia a simulare. Ora che abbiamo collisioni precise per ogni arto, la parte dello zombi più vicina alla dune buggy può comunque essere distante svariati centimetri. Di conseguenza, alla successiva simulazione fisica, il mostro inizia a cadere per effetto della gravità, visto che l'auto non lo sta più spingendo. Anche se trascorreva solo un istante prima che la dune buggy lo raggiungesse di nuovo, questo breve intervallo rendeva poco gratificante travolgere gli zombi, che spesso finivano fuori dalla visuale del giocatore. Per ovviare, abbiamo registrato la forza d'impatto impartita dall'auto allo zombi e l'abbiamo applicata identica al manichino. Abbiamo anche aggiunto una lieve spinta verso l'alto, così da lanciarlo leggermente. Con questi accorgimenti, gli zombi si accasciano sul mezzo una volta colpiti, come si aspetta il giocatore."
N/A3926"#commentary\cn_004_buggy_sound_engine.mp3" "[Kelly Bailey] L'audio della dune buggy è stato impegnativo, perché volevamo trasmettere la sensazione di un veicolo potente che sfreccia a tutta velocità, nonostante le mappe non siano tanto ampie e l'auto abbia una sola marcia, con una velocità massima di 50 km/h. A nostra discolpa, 50 km/h non sono pochi, soprattutto nel 2004! Anche i comandi sono essenziali. Avendo la tastiera come dispositivo di input di riferimento, i comandi sono sostanzialmente binari: l'auto può accelerare o non accelerare, e sterzare completamente in una direzione o andare dritto. In sostanza, dovevamo creare complessità audio a sostegno di una simulazione tutt'altro che complessa. Così, abbiamo realizzato un finto motore appositamente per l'audio della dune buggy. È dotato di cambio e abbiamo incrociato gli input del giocatore con i dati della simulazione fisica. Misuriamo la coppia di ciascuna ruota, verificando che stia girando o abbia trazione, e creiamo una serie ciclica di suoni, per poi sovrapporli tra loro mentre il finto motore cambia marcia e reagisce ai dati delle ruote. A seguire, abbiamo continuato a sperimentare, aggiungendo complessità. Abbiamo messo a punto la dune buggy per renderla divertente da guidare e con un gratificante senso di velocità. La maggior parte dei giocatori non ha commentato la dune buggy, se non per elogiarne l'audio, ed è stato un successo, considerando il folle lavoro che c'è dietro."
N/A3927"#commentary\cn_005_buggy_sound_design.mp3" "[Kelly Bailey] L'audio della dune buggy è stato ottenuto campionando una vecchia Camaro del 1968. Abbiamo scelto questa auto per il suo motore V8 di grossa cilindrata. È unico nel suo genere e produce quel suono profondo e viscerale a cui puntavamo. Quando non acceleri, poi, la trasmissione genera un meraviglioso rumore meccanico. Questa combinazione risultava particolarmente reattiva nel contesto del sistema di input binario che avevamo realizzato. Insomma, la finta trasmissione del motore non era ispirata a un'auto reale. Era un escamotage per gratificare il giocatore mentre teneva premuto l'acceleratore. È come una scala mobile che produce un tono ascendente, aumentando costantemente la tensione e cambiando marcia quando il tono deve riavviarsi. Poiché il giocatore avrebbe esaurito presto lo spazio, a causa delle ridotte dimensioni delle mappe, era sufficiente che accelerare risultasse divertente per brevi periodi."
N/A3928"#commentary\cn_006_automating_dsp.mp3" "[Kelly Bailey] Tutti i suoni che il giocatore sente passano per il nostro sistema di elaborazione digitale del segnale, o DSP. Si tratta del modo in cui l'audio viene modificato in base al luogo in cui si trova il giocatore. Per esempio, lo stesso suono risulta diverso se riprodotto in un parcheggio, in una stanza o all'aperto. In Half-Life 1, avevamo inserito manualmente dei nodi invisibili nel mondo di gioco per definire le impostazioni del DSP per ogni scenario. In Half-Life 2, il posizionamento manuale avrebbe richiesto troppo tempo, soprattutto perché il gioco era più vasto e avevamo sempre una sola persona addetta all'audio. Pertanto, abbiamo realizzato un sistema che determina automaticamente e in tempo reale le impostazioni del DSP intorno al giocatore. Per farlo, analizza lo spazio circostante per determinarne le dimensioni ed esaminare i materiali che lo compongono. A seguire, il sistema abbina quello spazio a uno dei 25 modelli di DSP preconfigurati manualmente, mentre noi correggiamo alcuni parametri e creiamo un DSP ultradettagliato che modifica i suoni uditi dal giocatore."
N/A3929"#commentary\cn_007_dynamic_mixing.mp3" "[Kelly Bailey] Durante il gioco, molti suoni vengono riprodotti contemporaneamente, ma alcuni sono ovviamente più importanti di altri ed è necessario regolare il volume di ciascuno in rapporto agli altri per dare risalto ai più rilevanti. Nei film, questo lavoro di mixaggio audio viene svolto in post-produzione. In un gioco, tuttavia, avviene in tempo reale, in risposta alle azioni del giocatore, quindi non possiamo sapere in anticipo quali suoni saranno riprodotti insieme. Per gestire il problema, tutti i suoni sono raggruppati per tipologia e priorità. Durante l'azione, il sistema audio monitora tutti i suoni in esecuzione e riduce il volume di un gruppo non appena si attivano tracce di priorità superiore. Questo mixaggio è regolabile. Se in una scena i colpi di pistola devono risaltare, possiamo aumentare la loro priorità in quel determinato punto. Se una determinata battuta deve sentirsi chiaramente, possiamo ridurre forzatamente il volume di tutto il resto. Lo stesso avviene con la musica. È un sistema nascosto ma fondamentale, ed evita che l'audio complessivo diventi cacofonico."
N/A3930"#commentary\cn_008_soundscapes.mp3" "[Kelly Bailey] In Half-Life 1, i suoni ambientali sono stati inseriti a mano e regolati singolarmente. In Half-Life 2, volevamo un numero maggiore di suoni ambientali negli scenari, aumentando la qualità ma riducendo l'intervento manuale richiesto. A questo scopo, abbiamo realizzato il cosiddetto \"sistema di paesaggio sonoro\". Un paesaggio sonoro è un piccolo programma che determina l'ambiente in cui i suoni vengono riprodotti, il loro punto di origine e come si comportano in ciascun contesto. Per esempio, il ronzio delle mosche, il vento, il cinguettio degli uccelli, un treno in lontananza o degli spari in sottofondo. Il sistema di paesaggio sonoro può selezionare e riprodurre casualmente queste tracce e, soprattutto, gestirne la transizione graduale mentre il giocatore si muove nello spazio. I paesaggi sonori possono includerne altri al loro interno, consentendo di creare raccolte di suoni riutilizzabili. Per esempio, un combattimento in lontananza può essere composto da spari, esplosioni e un elicottero di passaggio. Questi paesaggi sonori assemblano e riproducono dinamicamente svariati suoni singoli e non risultano artificiali come una singola traccia ripetuta. Nel complesso, i paesaggi sonori sono un elemento centrale dell'audio di Half-Life 2 e gestiscono pressoché ogni suono non prodotto dall'azione di gioco."
N/A3931"#commentary\cn_009_audio_over_distance.mp3" "[Kelly Bailey] Gli estesi spazi delle mappe sulla costa ci hanno spinti a elaborare una soluzione per gestire l'alterazione dei suoni dovuta alla distanza. Per esempio, in questi livelli un nemico può trovarsi a più di 100 metri dal giocatore e la sua arma deve suonare diversa rispetto a quando è vicino. Abbiamo deciso di archiviare gli effetti audio in un singolo file stereo, con quello vicino nel canale sinistro e quello lontano nel canale destro. Durante la riproduzione, eseguiamo una dissolvenza incrociata o modifichiamo il bilanciamento di ciascun canale in base alla distanza del giocatore dalla fonte. È una soluzione semplice ma efficace, e ha permesso di aggirare i limiti di memoria. Nel gioco si nota facilmente, è sufficiente prestare attenzione agli spari di un soldato Combine mentre si guida verso di lui."
N/A3932"#commentary\cn_010_flying_vehicle_audio.mp3" "[Kelly Bailey] I grossi nemici volanti rappresentano una sfida dal punto di vista audio. Durante i combattimenti, si muovono molto di più rispetto agli altri e spesso si allontanano parecchio dal giocatore. Sono inoltre molto pericolosi se hanno la visuale libera. Questi elementi ci hanno spinti a elaborare una soluzione audio incentrata sull'occlusione. Detto altrimenti, quando tu puoi vedere il nemico e quando il nemico può vedere te. Volevamo differenziare nettamente l'audio nel caso in cui avessero una linea di tiro libera. I rumori del motore del velivolo sono composti da vari suoni sovrapposti e riprodotti ciclicamente. Alcuni di questi cicli vengono elaborati dal sistema DSP in base all'ambiente circostante, mentre altri vengono riprodotti direttamente, senza elaborazione. Il sistema DSP aggiunge una sorta di eco ambientale ai suoni che elabora. Quando il velivolo è nascosto dietro un ostacolo e non può vederti, aumentiamo la percentuale di cicli da elaborare con il DSP, così il mezzo sembra più distante. Quando poi il nemico emerge da dietro l'impedimento e può vederti, aumentiamo la porzione del suono diretto. Nel primo caso, hai la sensazione che il suono sia distante e privo di direzione. Nel secondo, che provenga direttamente dal tuo campo visivo. Senti chiaramente quando l'elicottero emerge da dietro un edificio, è una differenza percepibile."
N/A3933"#commentary\cn_011_bullet_audio.mp3" "[Kelly Bailey] Se c'è una cosa di cui possiamo essere sicuri, è che il giocatore sentirà parecchi proiettili sfrecciargli sopra la testa. Per questo abbiamo dedicato tanto tempo a perfezionarne la resa audio. Purtroppo, nel gioco i proiettili sono quasi istantanei, per cui non possiamo applicare loro un suono e affidarci al movimento per modificarlo. Dopo vari esperimenti, abbiamo scelto questa soluzione: dopo aver individuato il punto della traiettoria del colpo più vicino all'orecchio del giocatore, calcoliamo il momento e il luogo esatti in cui il proiettile lo attraversa. Quindi, riproduciamo due diversi suoni in quel punto per simulare l'effetto Doppler: uno per quando il proiettile si avvicina e uno per quando si allontana. Il suono in allontanamento viene ritardato in base al momento stimato del suo passaggio."
N/A3934"#commentary\cn_012_staircase.mp3" "[Aaron Seeler] Ci sono situazioni di gioco che originano da obiettivi di design piuttosto semplici e diretti, e questa scala ne combina due. Il primo è mostrare il risveglio della Cittadella, suggerendo al giocatore che ha scoperchiato l'alveare. In secondo luogo, volevamo sfoggiare il nostro sistema di simulazione dei corpi. Ora è uno standard, ma nel 2004 non era comune vedere dei corpi rotolare in modo realistico, e le scale rappresentavano l'occasione perfetta."
N/A3935"#commentary\cn_013_alyx_and_mossman.mp3" "[Bill Fletcher] Fin dalla prima stesura della storia di Half-Life 2, abbiamo scelto di tentare qualcosa di diverso dal classico videogioco, dove un protagonista assolutamente buono deve sconfiggere nemici assolutamente malvagi. Invece, ci siamo concentrati sui personaggi e i loro rapporti. Ci sembrava interessante approfondire la famiglia come dinamica centrale di Half-Life 2. La tensione tra Alyx e Mossman è emersa da questa idea e ci è piaciuta perché risultava facile immedesimarsi. Era una situazione che i giocatori avrebbero potuto comprendere e sentire propria."
N/A3936"#commentary\cn_014_exposition_board.mp3" "[Danika Rogers] Qui abbiamo inserito una fase molto densa di narrazione visiva perché è la fase del gioco più esplicita nell'incoraggiare i giocatori a esplorare un ambiente. Anche se il suo scopo principale è dare corpo al mondo narrativo, abbiamo comunque cercato di evidenziare il rapporto tra Eli e Breen, per dare contesto al conflitto al centro della storia."
N/A3937"#commentary\cn_015_city_17_awakens.mp3" "[David Sawyer] La prima scena alla stazione ha lo scopo di mostrare come la città sia indifferente al giocatore, come se Gordon fosse un anonimo cittadino come tanti, prono agli ordini. Durante l'incursione nel complesso residenziale e sui tetti, tuttavia, la città riconosce nel protagonista un'anomalia e inizia ad agitarsi. Ora che il giocatore è diventato l'aggressore, l'intera città rivolge l'attenzione su di lui. Il sistema di altoparlanti della Sorveglianza, introdotto durante l'incursione, gioca un ruolo centrale nel trasmettere questo messaggio. Se si ascolta con attenzione, contiene molte informazioni sullo stato di allerta della città. Anche i giocatori che lo ignorano, comunque, possono cogliere le sensazioni che vuole trasmettere grazie al lavoro svolto sull'audio."
N/A3938"#commentary\cn_016_elis_lab.mp3" "[Dhabih Eng] Abbiamo realizzato il laboratorio di Eli dopo quello del dottor Kleiner, da cui abbiamo imparato molto su come allestire e progettare sequenze coreografiche efficaci. Pertanto, abbiamo potuto creare uno scenario più complesso e con più opportunità di interazione per il giocatore. La presenza di svariati personaggi impegnati nelle proprie attività ha reso complicata la messa in scena, e siamo riusciti a far funzionare tutto solo dopo molti test e tentativi. La nostra esperienza dimostrava che, di base, il giocatore vuole seguire la scena, a condizione di ricevere gli indizi necessari per capire dove andare. Al contempo, se si distrae, la scena si interrompe delicatamente in attesa del suo ritorno."
N/A3939"#commentary\cn_017_feel_free_to_look_around.mp3" "[Dhabih Eng] Non è stato semplice bilanciare il desiderio di esplorazione del giocatore con gli obiettivi narrativi della scena. Volevamo che la stanza fosse ricca di elementi interessanti, ma molti giocatori non iniziavano a esplorarla finché non erano sicuri che non avrebbero perso nessun dialogo dei personaggi. Quindi, era importante che Eli invitasse il protagonista a guardarsi intorno a metà della scena: era il via libera a esplorare senza rischi. Da quel momento, potevamo attivare una serie di mini-sequenze in base alle scelte del giocatore."
N/A3940"#commentary\cn_018_interstitial_scenes.mp3" "[Eric Kirchmer] Durante i test, emergevano spesso aree in cui i giocatori perdevano di vista l'obiettivo, un'evenienza comune in un gioco come Half-Life. Per risolvere il problema, abbiamo inserito brevi scene di raccordo per guidare i giocatori nel loro percorso e ribadire l'obiettivo. Una volta completato lo sviluppo di gran parte delle scene coreografiche principali, come il laboratorio di Kleiner, realizzare queste fasi minori è stato relativamente semplice. Abbiamo scoperto che usare i personaggi in queste sequenze risultava molto più efficace rispetto alla narrazione passiva o ai promemoria inseriti nei menu di pausa."
N/A3941"#commentary\cn_019_overwatch.mp3" "[Josh Weier] Durante lo sviluppo, abbiamo creato la voce della Sorveglianza usando uno strumento di sintesi vocale gratuito. Al momento della pubblicazione, tuttavia, ci siamo accorti di non avere i diritti per usarlo. Quindi, abbiamo organizzato dei provini per cercare una doppiatrice con caratteristiche simili alle battute generate dal programma. Non abbiamo impiegato molto a trovare Ellen McClain, la cui interpretazione era perfetta. Durante le sessioni di registrazione, le facevamo ascoltare le battute generate, affinché le imitasse a modo suo. All'inizio ha reagito con sarcasmo alla richiesta di riprodurre un'interpretazione robotica. Ma a distanza di anni, quando l'abbiamo richiamata per l'iconico ruolo di GLaDOS in Portal, ha ideato una soluzione creativa per integrare quel tono nella sua interpretazione."
N/A3942"#commentary\cn_020_box_car_joe.mp3" "[Laura Dubuk] In origine, questa piccola scena coinvolgeva due personaggi umani. Procedendo nello sviluppo, tuttavia, ne abbiamo sostituito uno con un Vortigaunt. Volevamo mostrare come i Vortigaunt convivessero con gli umani, contribuendo alla resistenza contro i Combine. Abbiamo anche introdotto la loro capacità di curare il giocatore, nonostante sia un aspetto che non abbiamo approfondito nel resto del gioco. I Vortigaunt si sono rivelati uno strumento narrativo efficace con cui limitare i dialoghi, in quanto la loro mente alveare giustificava la loro profonda comprensione del mondo e degli obiettivi del giocatore. Non avevano necessità di fare domande, aggirando il problema di scrivere dialoghi per un protagonista silenzioso."
N/A3943"#commentary\cn_021_mossman.mp3" "[Marc Laidlaw] Judith Mossman era ispirata a un personaggio creato per una sezione di Half-Life 1. Quella scena fu tagliata dal gioco base e riutilizzata in Uplink, ma senza quel personaggio. La consideriamo la figura più complessa di Half-Life 2. Sapevamo che avremmo dovuto gestire con attenzione i sentimenti del giocatore verso di lei, anche prima di Nova Prospekt, perché i suoi alleati più fidati hanno giudizi discordanti nei suoi confronti: a Eli piace, a Alyx no. Non potevamo spingerci oltre certi limiti nella complessità dei rapporti, ma ritenevamo che il giocatore avrebbe potuto cogliere una dinamica di tipo figlia-matrigna. Qualunque sia la propria opinione su Mossman, il suo eroismo è innegabile. Rischia il doppio gioco per ottenere informazioni utili a proteggere Eli e Alyx. Semplicemente, non si aspettava Gordon."
N/A3944"#commentary\cn_022_hands_free.mp3" "[Matt Wright] All'epoca dell'uscita di Half-Life 2, molti sparatutto in soggettiva fornivano al giocatore un'arma da fuoco o da mischia fin dall'inizio, mentre noi abbiamo scelto di lasciarlo a mani nude. Senza un'arma, sarebbe stato più semplice mostrargli le nuove modalità di interazione con il mondo e introdurlo alla storia. Volevamo trasformare il protagonista da fuggiasco ad aggressore e, per rendere la transizione naturale, dovevamo armarlo al momento giusto. Per questo, ottiene finalmente un'arma nel momento in cui smette di scappare. Secondo qualcuno, non reagire è la vera vittoria, ma sappiamo tutti che non è vero. Il modo migliore per vincere è correre incontro all'avversario sparando a tutto spiano."
N/A3945"#commentary\cn_023_metrocop_scene.mp3" "[Mike Dussault] Questa è un'altra scena scritta per ribadire che i poliziotti sono il nemico, con la differenza che ora il giocatore ha un'arma e può finalmente fare qualcosa. E quel \"qualcosa\" consiste nel premere un grilletto. Volevamo far sentire il giocatore dalla parte del giusto, e questo momento contribuisce allo scopo. I poliziotti sono comunque umani, a differenza degli altri Combine del gioco, per cui dovevamo assicurarci che le azioni del giocatore apparissero come un atto di giustizia e non di furia cieca."
N/A3946"#commentary\cn_024_moving_the_gravity_gun.mp3" "[Ted Backman] Quando abbiamo creato la pistola gravitazionale, avevamo intenzione di fornirla al giocatore verso la metà del gioco. Nei test, tuttavia, abbiamo capito quanto funzionasse bene e che quell'arma, e soprattutto la possibilità di lanciare lame circolari in faccia agli zombi, andava introdotta prima. Di conseguenza, anche il laboratorio di Eli doveva essere anticipato. Si trattava di una modifica profonda, ma cruciale per il successo di Half-Life 2. È la conferma di come narrazione e azione siano interconnesse. Nessuno dei due fattori è più importante a priori, devono funzionare insieme."
N/A3947"#commentary\cn_025_buggy_birds.mp3" "[Adrian Finol] In un memorabile test sulla costa, un giocatore è tornato al suo veicolo dopo aver esplorato una casa e ha visto un uccello volargli accanto. Ha urlato all'animale di allontanarsi dalla dune buggy, lamentandosi di come gli uccelli gli sporchino sempre l'auto nella vita reale. Nella riunione successiva al test, abbiamo notato come fosse la prima volta in cui un giocatore si preoccupava per qualcosa che non fosse il suo personaggio. Abbiamo pensato di approfondire il tema e abbiamo realizzato un sistema per concretizzare il timore del tester. Quando il giocatore abbandona la dune buggy fuori dal suo campo visivo per un periodo, un gabbiano si posa su un punto casuale del telaio. Con il passare del tempo, il gabbiano produce texture di escrementi sulla carrozzeria e non smette finché il giocatore non torna, momento in cui spicca il volo. Naturalmente, i tester volevano poter ripulire il veicolo, per cui abbiamo aggiunto la possibilità di farlo attraversando uno specchio d'acqua. Lo sviluppo era in fase avanzata e disponevamo della tecnologia necessaria, quindi implementare questa funzionalità ha richiesto poco tempo. È uno di quei casi in cui sappiamo che solo alcuni giocatori se ne accorgeranno, ma se questi dettagli sono realizzati bene e in numero sufficiente, molti giocatori ne troveranno almeno uno."
N/A3948"#commentary\cn_026_bridge_gunship.mp3" "[Adrian Finol] Eravamo particolarmente soddisfatti dello scontro con il gunship, nonostante le difficoltà incontrate a causa della geometria del livello. Avere il giocatore sotto il ponte permetteva al velivolo di girargli completamente intorno, sfruttando le tre dimensioni per posizionarsi sopra o sotto, in base ai momenti. Le travi garantivano una rete di ripari, permettendo alle raffiche del gunship di produrre effetti audio e visivi molto dinamici e divertenti."
N/A3949"#commentary\cn_027_floor_is_lava.mp3" "[Adrian Finol] Sviluppare le dinamiche di gioco intorno a concetti consolidati come \"il pavimento è lava\" le ha rese facili da comprendere. Eravamo orgogliosi della libertà che il nostro sistema di fisica concedeva ai giocatori nella risoluzione dei problemi. Alcuni costruivano passerelle composte da molti oggetti, altri riciclavano le stesse due lastre di metallo. Alcuni procedevano con prudenza tra le rocce, temendo di cadere, mentre altri puntavano velocemente all'uscita, in precario equilibrio su oggetti sopra la sabbia. Ognuno aveva il suo stile di gioco: c'era chi considerava un fallimento attirare le formicheleone, nel qual caso ricaricava subito, o chi tornava di corsa alle rocce per riprendersi. E sebbene fosse un enigma ambientale, apprezzavamo che i giocatori potessero tramutarlo in un'arena. Alcuni si limitavano a saltellare sulla sabbia combattendo fino all'uscita."
N/A3950"#commentary\cn_028_opportunistic_moments.mp3" "[Ariel Diaz] Alcuni momenti memorabili dell'avventura scaturiscono dalle interazioni tra più sistemi di gioco. Diverse, tuttavia, sono circostanze che si verificano raramente. In quel caso, vorremmo farle sperimentare a più giocatori. Si crea una tensione tra due opposti: più un evento ha probabilità di verificarsi, più lavoro possiamo dedicargli. Ma se risulta troppo artificiale, apparirà forzato, creando una risposta negativa nel giocatore. La distruzione cinematografica del gunship è un evento su cui siamo intervenuti per aumentare la probabilità di rendere spettacolare il momento senza che apparisse evidente. La conformazione dell'area e la traiettoria di volo del gunship rendono probabile che il giocatore e il velivolo si trovino nel punto giusto al momento del suo abbattimento. In quell'eventualità, attiviamo lo schianto del gunship sulle auto. Altrimenti, viene distrutto in modo normale. È molto \"videogiocoso\", ma funzionava e i tester hanno reagito positivamente."
N/A3951"#commentary\cn_029_assault_on_nova_prospekt.mp3" "[Ariel Diaz] Con un esercito infinito di formicheleone che assalta una fortezza dei Combine sulla costa, era difficile non ispirarsi alla Normandia. Il prototipo iniziale prevedeva delle trincee fino a Nova Prospekt, con letali mitragliatrici che costringevano il giocatore e le formicheleone a restare al riparo. Era esaltante aggirarsi per le trincee con le raffiche e le formicheleone che ti passavano sopra. Purtroppo, non è stato possibile implementarlo a causa dei nostri limiti tecnici, quindi siamo stati costretti ad accantonare l'idea e a ripiegare su un'altra soluzione. Tuttavia, le torrette di artiglieria sono rimaste, e la loro pericolosità è stata utile per incentivare il giocatore ad affidarsi alle formicheleone."
N/A3952"#commentary\cn_030_buggy_physics.mp3" "[Charlie Brown] La fisica della dune buggy ha richiesto parecchi esperimenti. Doveva sembrare veloce, ma superava a stento i 50 km/h, per cui siamo dovuti ricorrere a qualche trucchetto. Abbiamo incrementato la forza verticale del salto turbo e applicato una lieve spinta al posteriore quando si derapa con il freno a mano. Altrimenti, la bassa velocità avrebbe reso il mezzo poco divertente da guidare. Inoltre, il mondo di gioco era disseminato di variabili fisiche del tutto imprevedibili: i giocatori avrebbero potuto andare a sbattere ovunque, e dovevamo assicurarci che potessero sempre uscire. Ha richiesto parecchi esperimenti e test. Alla fine, abbiamo scelto una simulazione piuttosto goffa e improbabile che rendeva la dune buggy permissiva e difficile da ribaltare. Il suo baricentro è bassissimo e l'angolo di sterzata, nonostante le apparenze, è limitato. Era la nostra prima simulazione di un veicolo e ci ha insegnato molto. Quell'esperienza ci ha permesso di rendere la muscle car di Episode 2 molto più semplice da guidare."
N/A3953"#commentary\cn_031_the_bridge.mp3" "[Charlie Brown] Questa sezione del ponte è ispirata al Deception Pass Bridge, che si trova vicino agli uffici Valve. All'inizio abbiamo progettato la sequenza come un puro enigma ambientale, per poi aggiungere altre meccaniche di gioco. Ed è diventato il nostro test primario per l'attrito del giocatore sulle sporgenze. Il nostro sistema di movimento incrementa leggermente l'attrito del protagonista quando si avvicina al bordo di una superficie. I giocatori non se ne sono mai accorti, forse perché asseconda la loro intenzione di fermarsi per guardare in basso, insieme alla tendenza a muoversi con più cautela vicino a un precipizio. Tuttavia, è una funzione fondamentale in questa parte del gioco. Ce ne siamo accorti quando l'abbiamo disattivata per errore durante lo sviluppo e, di colpo, tutti i tester hanno iniziato a morire a ripetizione cadendo nel vuoto."
N/A3954"#commentary\cn_032_coast.mp3" "[Chris Green] Volevamo una sezione del gioco abbastanza ampia per la dune buggy, seppure con dei limiti al movimento del giocatore. La costa ci garantiva un confine naturale su un lato della mappa, senza compromettere il senso di ampiezza e libertà. Peraltro, rendeva evidenti gli effetti dello sfruttamento delle risorse terrestri da parte dei Combine. Considerato che i tester tentavano di allontanarsi a nuoto, abbiamo aggiunto le sanguisughe come deterrente. Non potevano apparire come un nemico reale ed eliminabile, quindi hanno una parvenza magica. I giocatori capivano che stavano forzando i limiti del gioco e non abbiamo aggiunto altro."
N/A3955"#commentary\cn_033_grenade_house.mp3" "[Dave Riller] Un elemento preponderante degli Half-Life è offrire ai giocatori combattimenti sempre leggermente diversi dai precedenti, seppur per qualche dettaglio. Non deve trattarsi necessariamente di prove di abilità. A volte possono essere momenti di puro svago per il giocatore. La casa con le granate è uno di questi momenti, con la differenza che i presupposti sono invertiti rispetto al solito. Di norma, si lanciano bombe verso bersagli più in basso, mentre qui i nemici sono in alto. La cassa di munizioni infinite è un mezzo piuttosto grossolano per spingere il giocatore a sperimentare con lo scenario, la cui indistruttibilità permette di salire al piano di sopra anche se tutto il resto è esploso."
N/A3956"#commentary\cn_034_buggy_training_course.mp3" "[David Sawyer] Questa sezione tutorial è stata progettata per permettere al giocatore di prendere confidenza con la dune buggy. All'epoca di Half-Life 2, non si era mai visto un simile livello di simulazione fisica applicata a un veicolo, per cui volevamo permettere al giocatore di sperimentare. Inoltre, era appena uscito dagli spazi angusti di Ravenholm ed era giusto premiarlo con la sensazione opposta di sfrecciare in spazi ampi, protetto all'interno di un veicolo. Per uscire da quest'area è necessario eseguire un salto turbo, che rappresenta al tempo stesso un test di padronanza del mezzo e un espediente per evitare che abbandoni la dune buggy."
N/A3957"#commentary\cn_035_ambush.mp3" "[David Sawyer] Una delle difficoltà che il giocatore incontra negli FPS come Half-Life è trovarsi in ambienti sempre nuovi. Quando entra in combattimento, si muove in aree sconosciute e non sa come approcciare lo scontro. Usiamo diversi metodi per aiutare il giocatore in casi simili, come dimostra questa imboscata. All'arrivo, il protagonista combatte un gruppo di Combine tra le case. Durante la battaglia e la successiva fase esplorativa, ha modo di scoprire la conformazione dell'arena. Quindi, quando arriva in questa soffitta, schieriamo una seconda ondata di Combine. Questa volta il giocatore ha il vantaggio di conoscere l'ambiente e può attuare delle tattiche più consapevoli per difendersi dagli aggressori."
N/A3958"#commentary\cn_036_bugbait_training.mp3" "[David Sawyer] Questo maldestro tutorial sulle esche per insetti è il risultato dello scarso tempo a disposizione, ma era necessario per insegnare al giocatore a sfruttare questo strumento a Nova Prospekt. In genere, cerchiamo di mascherare i tutorial con elementi di contorno perché non sembrino fasi di addestramento, ma un naturale processo di scoperta. Qui non ci siamo riusciti. Può sembrare strano, ma i giocatori non trovavano intuitivo l'uso delle esche. Siamo nelle fasi avanzate dell'avventura, e i giocatori hanno acquisito esperienza contro i nemici. Prima che inserissimo un tutorial, i tester che trovavano l'esca entravano nel livello successivo e sparavano d'istinto alla prima formicaleone che vedevano, perché è quello che avevano sempre fatto. Half-Life incoraggia il classico approccio \"Nel dubbio, spara\". Allo stesso modo, arrivati a Nova Prospekt, invece di lanciare un'esca ai soldati Combine, i giocatori si affidavano alle consuete armi. Questo tutorial serviva non solo a mostrare il funzionamento di un'esca, ma anche a chiarire che le formicheleone avrebbero accompagnato il giocatore senza aggredirlo."
N/A3959"#commentary\cn_037_vortigaunt_extraction.mp3" "[Dhabih Eng] Questa arena ha rappresentato una sfida a livello progettuale per almeno due motivi. In primis, la guardia combatte solo in mischia, per cui dovevamo impedire al giocatore di raggiungere aree in cui il nemico non potesse seguirlo. Abbiamo sperimentato alcuni attacchi a distanza, ma con scarsi risultati: quando sputava melma, per esempio, risultava ridicolo. L'unico attacco a lungo raggio che è rimasto è il lancio di oggetti basato sulla fisica, ma presuppone che ci siano oggetti a portata, e non sempre è così. In secondo luogo, dovevamo garantire che il Vortigaunt fosse sempre in grado di raggiungere il cadavere della guardia, ovunque morisse. Questo era fondamentale, perché se il Vortigaunt non estrae l'esca, il gioco non può proseguire."
N/A3960"#commentary\cn_038_dropship_deployment.mp3" "[Doug Wood] Schierare soldati dalle dropship è stato complicato, perché presupponeva di generare personaggi all'interno di un altro oggetto solido. Prima di uscire all'aperto e muoversi normalmente, dovevano eseguire un'animazione per saltare fuori dal container non appena apparivano. Sistemato questo aspetto, si è presentato un altro problema: i giocatori più smaliziati si sarebbero appostati fuori dal container e avrebbero sparato ai soldati durante l'animazione di uscita. Per impedirglielo, abbiamo aggiunto una torretta al container in difesa delle truppe in uscita. Non impedisce del tutto al giocatore di sfruttare la situazione, soprattutto se usa un'arma indiretta come una granata, ma ci sembrava una soluzione realistica e una contromisura strategicamente plausibile."
N/A3961"#commentary\cn_039_laser_guided_rpg.mp3" "[Eric Smith] La funzione di guida laser del lanciarazzi ha rappresentato un grosso grattacapo, perché era difficile da insegnare. Molti tester si mettevano al riparo appena dopo aver sparato, quindi non vedevano la traiettoria di volo del razzo. Quel che è peggio, non capivano che a quel punto il proiettile stava tornando indietro verso di loro. Abbiamo provato vari stili di interfaccia e di indicatori laser, ma la maggior parte dei giocatori li ignorava, concentrandosi sul nemico. Abbiamo apportato molte piccole correzioni, come sottolineare quella funzione nel discorso di Odessa e migliorare la resa audio e video del gunship che abbatte i razzi che procedono in linea retta. Anche se queste modifiche hanno aiutato qualcuno a comprendere la meccanica, non eravamo sicuri che sarebbe risultata chiara a tutti. Abbiamo persino valutato di eliminarla, ma avrebbe reso lo scontro con il gunship molto meno interessante. La guida laser costringeva il giocatore a tenere il velivolo nel campo visivo durante il volo del razzo, ma anche a restare esposto al gunship, creando una tensione che trovavamo perfetta."
N/A3962"#commentary\cn_040_performance_constraints.mp3" "[Eric Smith] Per l'ultima arena della costa, avevamo pensato a un gran finale in cui il giocatore e un gruppo di cittadini si sarebbero asserragliati contro ondate di soldati Combine, fino alla battaglia contro un gunship. Purtroppo, il costo computazionale di soldati e alleati che si muovono in scena ci ha costretti a ridurre le dimensioni della battaglia per rientrare nel nostro budget tecnico. Quando siamo arrivati ad avere una sola squadra di soldati alla volta, eravamo già in ritardo con lo sviluppo. Poiché era troppo tardi per apportare modifiche su larga scala all'arena e includere più nemici, abbiamo dovuto ripensare la sequenza di combattimento per ridurre al minimo il numero di soldati."
N/A3963"#commentary\cn_041_lighthouse_gunship.mp3" "[Ido Magal] Realizzare questa scena con il gunship nel modo in cui l'avevamo immaginata ha richiesto molto lavoro, perché volevamo che sembrasse cinematografica. Se fosse un film, il gunship sparerebbe attraverso le finestre mentre il protagonista scala il faro, anticipandone gli spostamenti. Per riprodurre quel tipo di anticipazione nel gioco, abbiamo disposto una serie di aree di attivazione lungo le scale. Quando rilevano il giocatore che sale, comunicano al gunship di portarsi alla stessa altezza del protagonista. Gli attivatori impostano anche dei bersagli sulle finestre vicine al giocatore: in sostanza, degli elementi di gioco che l'IA nemica percepisce come ostili, ordinando al gunship di sparargli. Questa combinazione di IA ed eventi predefiniti è alla base delle fasi di combattimento di Half-Life. L'IA gestisce la condotta generica e adattiva dei personaggi non giocabili, mentre gli eventi predefiniti personalizzano i requisiti specifici di ogni scenario."
N/A3964"#commentary\cn_042_crane.mp3" "[Jakob Jungels] Mettere a punto la gru ha richiesto parecchio lavoro. Una struttura in grado di generare una simile forza fisica rappresentava un rischio, considerati i limiti della nostra fisica dei corpi rigidi e della nostra tecnologia di distruzione. Per esempio, il magnete non avrebbe mai soddisfatto quelle che erano le aspettative del giocatore per un macchinario di quella mole. Ma poiché la gru era fissa, abbiamo potuto scegliere accuratamente ciò che aveva intorno e modificare dove necessario. Per fortuna, molti giocatori non notavano le sue imperfezioni, forse per il senso di novità derivante dal poter interagire con una struttura del genere in un ambiente fisico verosimile."
N/A3965"#commentary\cn_043_flashlight_power.mp3" "[Jeff Lane] La scelta di usare l'energia della tuta HEV per alimentare lo scatto e la torcia è stata controversa in Half-Life 2. Inizialmente, solo lo scatto consumava l'energia della tuta. Aveva senso, perché doveva fornire una breve accelerazione. La torcia, invece, poteva essere usata senza limiti. Dai test, tuttavia, è emerso un problema: spesso i giocatori uscivano dalle zone buie dimenticandosi la torcia accesa. In aree aperte e illuminate come la costa, il nostro budget tecnico non poteva gestire l'uso costante della torcia, per cui dovevamo trovare un modo per disattivarla senza l'intervento del giocatore. Limitarne l'energia era la soluzione più semplice, con il vantaggio di aumentare la tensione al buio. A quel punto, il problema era scegliere la risorsa che avrebbe dovuto consumare. Avevamo già l'energia della tuta e non volevamo appesantire l'interfaccia con un indicatore riservato alla torcia. Abbiamo valutato anche altre abilità legate all'energia della tuta, perché sarebbe stato interessante costringere il giocatore a scegliere quali usare. Questo è un ottimo esempio di come la progettazione di un gioco costringa spesso a scegliere tra soluzioni imperfette. Non ci faceva impazzire l'idea di usare la stessa risorsa per scatto e torcia, ma non volevamo appesantire l'interfaccia. In Episode 2, non avendo intenzione di aggiungere altre funzioni che consumassero l'energia della tuta, abbiamo dedicato alla torcia una risorsa a parte."
N/A3966"#commentary\cn_044_open_world_loot.mp3" "[Jeff Lane] L'ampiezza del livello sulla costa ci ha posto di fronte al problema di come distribuire le ricompense. Nella serie Half-Life, tendiamo a premiare l'esplorazione del giocatore. Se sai dove andare, ma noti una deviazione e dedichi del tempo a esplorarla, è probabile che troverai qualcosa di utile. Quando abbiamo iniziato a testare le mappe sulla costa, abbiamo nascosto le ricompense negli angoli delle aree esterne. Tuttavia, questa scelta peggiorava l'esperienza con la dune buggy. La natura aperta degli spazi implicava la presenza di numerosi anfratti che sembravano nascondere segreti, e i giocatori si fermavano di continuo per andare a controllare. Diventava noioso e spezzava il ritmo. Quindi, abbiamo rimosso tutte le ricompense. Ma questo creava un altro problema: come fa il giocatore a capire quando scendere dalla dune buggy? Dopo una lunga riflessione, abbiamo stabilito una regola: ogni edificio di costruzione umana avrebbe sempre incluso elementi di gioco e ricompense per l'esplorazione, mentre le aree naturali sarebbero rimaste vuote. Non potevamo comunicarlo direttamente al giocatore, ma assecondava le sue aspettative e rinforzavamo il messaggio con aree come questa."
N/A3967"#commentary\cn_045_gas_station.mp3" "[Jeff Lane] Avevamo grandi progetti per questo scontro. Volevamo che il giocatore combattesse intorno a una stazione di servizio, incendiando le pompe di benzina e bruciando tutto, per poi allontanarsi in auto circondato dalle fiamme. Tuttavia, budget e prestazioni rappresentavano un limite stringente nel 2003, e la stazione è stata progressivamente ridimensionata e semplificata per poter essere inserita nei grandi livelli della costa. Il progetto di una simulazione dinamica del fuoco non si è mai concretizzato e non aveva più senso realizzarlo: c'è un limite alla quantità di lavoro che puoi dedicare a un singolo scontro. Alla fine, ciò che resta dell'idea originale sono le pompe di benzina che esplodono."
N/A3968"#commentary\cn_046_buggy_introduction.mp3" "[John Cook] Volevamo introdurre la dune buggy in modo interessante, prima che il giocatore si mettesse al volante. Ci siamo riusciti grazie alla gru. Soprattutto, dovevamo insegnare ai giocatori come ripristinare l'auto quando si ribaltava, e questa sequenza serviva allo scopo. I tutorial sotto pressione sono sempre complicati, ma era necessario spiegare che l'infestazione di formicheleone imponeva di restare a bordo della dune buggy. Quindi, abbiamo tenuto attiva la minaccia delle formicheleone e garantito un paio di torrette alleate di supporto. Con un bonus: i giocatori sperimentano la sensazione di essere sollevati dalla gru poco prima di usarne una."
N/A3969"#commentary\cn_047_crossbow.mp3" "[John Cook] Questa è la prima occasione in cui il giocatore può ottenere la balestra e, ripensandoci, mi stupisce che il ritrovamento non sia obbligato. Nulla impedisce di continuare a guidare e ignorarla. Per evitare che accadesse, abbiamo creato un posto di blocco e una postazione sopraelevata per incoraggiare il giocatore a scendere dalla dune buggy, affinché notasse la balestra e la cassa di oggetti. I test mostravano che quasi tutti i giocatori si fermavano e raccoglievano l'arma, ma questo è uno di quei casi in cui test ed esperienza di gioco reale possono differire. Un tester che ha iniziato a giocare dal livello della costa potrebbe essere meno stanco di esplorare di chi affronta il gioco dall'inizio. Quindi, abbiamo inserito una seconda balestra pochi livelli dopo, direttamente sul percorso verso Nova Prospekt."
N/A3970"#commentary\cn_048_rollermines.mp3" "[Josh Weier] Le mine rotanti sono state create perché serviva un nemico che minacciasse il giocatore mentre guidava. Poiché il protagonista sulla dune buggy è un'entità fisica interamente simulata, ci sembrava interessante introdurre un nemico fisicamente realistico. La lama della morte dimostrava che questo approccio portava i nemici a interagire in modo stimolante con l'ambiente. Così abbiamo creato la mina rotante, una sfera che si muove generando coppia su sé stessa, e messo a punto il suo comportamento affinché fosse divertente da colpire con l'auto. Le mine rotanti non sono particolarmente pericolose, ma se si accumulano possono diventare un problema, soprattutto vicino ai precipizi. Ci siamo assicurati che funzionassero bene anche quando il giocatore è a piedi, per permettere ai designer dei livelli di inserirle in qualche altro combattimento."
N/A3971"#commentary\cn_049_sandtrap_thumper.mp3" "[Laura Dubuk] I barili esplosivi consentono al giocatore di difendersi dalle formicheleone mentre è protetto dal martellatore. Ma sono anche un'anticipazione del successivo scontro con la guardia formicaleone, in cui i giocatori ricorrono spesso a tattiche simili. Alcune opzioni di gioco alternative, come il lancio di esplosivi con la pistola gravitazionale, tendono a essere dimenticate se non vengono usate spesso. Con l'ampia scelta di opzioni offensive a disposizione, non possiamo sapere se il giocatore ha usato di recente questa abilità. Quindi, stiamo suggerendo implicitamente di tenere a mente questa possibilità prima di affrontare la guardia."
N/A3972"#commentary\cn_050_coast_kickoff.mp3" "[Marc Laidlaw] Questa scena di raccordo è stata introdotta in fase avanzata di sviluppo per collegare Ravenholm alla costa. Suona familiare? Molte sequenze di collegamento dei nostri giochi vengono create alla fine. In questo caso, dovevamo tagliare il superfluo: non avevamo nemmeno tempo per animare Alyx sul monitor. È sempre complicato rendere interessanti queste scene, e in questo caso non ci siamo riusciti. È un buon esempio di cosa succede quando tratti i personaggi non giocabili come cartelli informativi, senza caratterizzare loro o la scena. Il risultato è una fase trascurabile, in cui il gioco si trascina. Ma è insito nella natura dello sviluppo: il tempo è limitato e devi scegliere come impiegarlo. I laboratori di Kleiner e Eli erano molto più importanti e hanno ricevuto più attenzione."
N/A3973"#commentary\cn_051_odessa_cubbage.mp3" "[Marc Laidlaw] Odessa Cubbage è un esempio di personaggio secondario che funziona bene. È un tipo divertente, con alcuni tratti simpatici e che vive nella sua piccola bolla. Visto che non esce mai dal suo scenario, può distinguersi con il suo essere sopra le righe. Siamo partiti dal modello poligonale, riciclato da una sezione tagliata del gioco, e lo abbiamo chiamato con il titolo di una email di spam che avevamo ricevuto. In origine, era il modello di un pescatore norvegese e non era molto credibile come inglese, per cui gli abbiamo aggiunto dei baffi. Così è nato il personaggio di Odessa. È sostanzialmente un ciarlatano, finto sotto ogni aspetto, a partire dai baffi e dall'accento. Non si esporrebbe mai al pericolo, motivo per cui è la persona perfetta per consegnare a Gordon il lanciarazzi e spiegargli come si usa."
N/A3974"#commentary\cn_052_28_transitions_later.mp3" "[Marc Laidlaw] Dopo diversi livelli consecutivi in cui usavamo dei tunnel bui come aree di raccordo, ci siamo accorti che avremmo potuto sovvertire le aspettative del giocatore creandone un altro che sembrasse di transizione, ma che invece contenesse altro. Come tutti, abbiamo visto \"28 giorni dopo\" nel 2002, ci è piaciuto e abbiamo tentato di inserire uno scontro con gli zombi in uno dei tunnel in penombra. Ha richiesto poco tempo ed eravamo soddisfatti del risultato. Anni dopo, abbiamo incontrato Alex Garland, lo sceneggiatore del film. Aveva giocato e apprezzato Half-Life 2, e gli abbiamo confessato che questa sezione era ispirata al suo film."
N/A3975"#commentary\cn_053_finest_mind_of_his_generation.mp3" "[Marc Laidlaw] Questa è un'altra piccola scena di raccordo che funziona bene. L'unico scopo di questa fase era insegnare al giocatore a stare alla larga dalla sabbia. Nelle sequenze precedenti eravamo troppo concentrati a cercare di farle funzionare, ma a questo punto avevamo acquisito maggiore consapevolezza e potevamo divertirci a infondere più cura in un momento del genere. Nello specifico, abbiamo elevato i personaggi a qualcosa di più di semplici cartelli informativi, creando una scena più interessante e divertente. Dopo l'uscita, Lazlo ha sviluppato un grandissimo seguito, a dimostrazione di quanto sia difficile prevedere cosa farà breccia nel pubblico."
N/A3976"#commentary\cn_054_bridge_playtesting.mp3" "[Matt Boone] Il ponte è sempre stato tra le sezioni più apprezzate nei test, e ha generato ogni volta reazioni emotive molto intense. La tensione sperimentata dai giocatori nel percorrere le travi traspariva dai loro movimenti. Man mano che aggiungevamo nuove sfide, i test diventavano più divertenti da osservare. Ricordo il treno che sferraglia sul ponte facendo tremare la struttura, o il succhiateste piazzato a sorpresa in un capanno apparentemente sicuro a metà della traversata. Ci sentivamo vagamente in colpa a goderci lo stress dei tester, ma non era solo perfidia: una volta attraversato il ponte e tirato un sospiro di sollievo, disattivavano lo scudo dei Combine, per poi scoprire che dovevano tornare indietro percorrendo la sezione inferiore della struttura. Non volevamo che si annoiassero, quindi abbiamo aggiunto un gunship che tenesse loro compagnia durante il viaggio."
N/A3977"#commentary\cn_055_thumper_final_stage.mp3" "[Matt Boone] La fase conclusiva della sezione dei martellatori è tra le nostre preferite, perché il loro scopo viene completamente sovvertito: invece di rappresentare un rifugio, diventano un ostacolo per le formicheleone del giocatore. Forse, tuttavia, avremmo dovuto illustrarne meglio il funzionamento nelle fasi precedenti. Fraintendere il senso dei martellatori non è un problema nei primi livelli della costa, ma qui la posta in gioco è più alta, perché ora è possibile sperimentare con le esche. Se non comprende che sono i martellatori a impedire alle sue formicheleone di avanzare, il giocatore rischia di non cogliere il funzionamento delle esche. Se lanciando un'esca contro i soldati nel primo bunker le formicheleone non corrono in suo soccorso, il giocatore può pensare che sia uno strumento inaffidabile e tornare alle sue solite armi."
N/A3978"#commentary\cn_056_buggy_tools.mp3" "[Matt Wright] Volevamo che la dune buggy rappresentasse più di un semplice mezzo di trasporto, quindi l'abbiamo dotata di un'arma. La scelta è caduta sul cannone tau, un'arma proveniente da Half-Life 1 che non eravamo riusciti a inserire in Half-Life 2. Considerata la sua capacità di sparare attraverso i muri, ne abbiamo limitato la disponibilità alla sezione sulla costa. Introdurre armi perforanti avrebbe complicato molto il design dei livelli. Inoltre, abbiamo aggiunto una cassa di proiettili sul retro del veicolo, in modo da fornire munizioni infinite per il mitra in tutta la sezione. Una scelta molto apprezzata dai tester alle prese con le formicheleone che emergono senza sosta dalla sabbia."
N/A3979"#commentary\cn_057_antlion_guard.mp3" "[Matt Wright] In rari casi, alcuni giocatori si sono trovati impossibilitati a uccidere la guardia formicaleone in questa arena. Capitava che esaurissero le munizioni e facessero un uso errato degli oggetti interagibili, finendo per non avere nulla da lanciare con la pistola gravitazionale. Abbiamo risolto il problema posizionando un cittadino alla torretta sul cancello, perché aiutasse i giocatori in difficoltà a eliminare il nemico."
N/A3980"#commentary\cn_058_terrain_and_performance.mp3" "[Mike Dussault] Il nostro budget tecnico ha rappresentato spesso un serio ostacolo nella progettazione dei combattimenti, specialmente quelli in spazi aperti. Per muoversi, i personaggi non giocabili eseguono numerosi piccoli rilevamenti dello spazio circostante lungo il loro tragitto. È possibile immaginarli come persone non vedenti che agitano il bastone per verificare se il passaggio è sicuro. Il \"costo\" di questi rilevamenti cresce di pari passo con la complessità strutturale degli ambienti. Per generare superfici irregolari, il nostro sistema di creazione degli scenari impiega un numero di poligoni di gran lunga maggiore rispetto a un pavimento perfettamente liscio, rendendo i movimenti dei PNG molto più impegnativi da gestire e limitando la portata degli scontri in molte sezioni del gioco."
N/A3981"#commentary\cn_059_area_portals.mp3" "[Mike Dussault] Una delle sfide tecniche della costa è stata la necessità di gestire in parallelo ampie aree aperte ed edifici con interni dettagliati. Secondo gli standard del 2003, quantomeno. Quando il giocatore era all'aperto, la nostra priorità era renderizzare gli scenari visibili, senza sprecare risorse sugli interni. Ma a meno di sbarrare ogni apertura, restava comunque la possibilità di sbirciare dentro. Per ovviare a questo problema, abbiamo creato i cosiddetti \"portali dell'area\", posizionandoli su ogni porta e finestra aperta. I portali generano un'immagine bidimensionale degli interni dell'edificio e la proiettano sui passaggi quando il giocatore guarda dentro da una certa distanza, risparmiando le risorse necessarie al rendering degli interni. Man mano che il giocatore si avvicina, viene eseguita una dissolvenza tra l'immagine del portale e gli interni reali. L'uso di questo stratagemma, insieme alle classiche porte che si chiudono automaticamente alle spalle del giocatore, ci ha consentito di contenere i costi tecnici di questi scenari."
N/A3982"#commentary\cn_060_buggy_removal.mp3" "[Miles Estes] Una volta giunti al punto in cui bisogna abbandonare la dune buggy, è stato necessario essere espliciti. Per l'intera fase sulla costa, i giocatori non fanno altro che abbandonarla per poi tornare a guidarla, quindi i tester cercavano il modo di portarla con sé ogni qualvolta sembrasse minimamente plausibile. Questa breve scena nel garage ha lo scopo di comunicare al giocatore che da quel punto in poi dovrà procedere a piedi."
N/A3983"#commentary\cn_061_d2_coast_04.mp3" "[Randy Lundeen] Questa mappa è stata la prima sezione della costa a essere completata, prima ancora della gru e degli altri elementi. L'area marina in secca e le navi arrugginite sono tra i primi bozzetti creati per il gioco. Anni dopo, abbiamo usato questa sezione per una dimostrazione all'E3 2003, quando la struttura di gioco era ancora da definire. In seguito, quando abbiamo iniziato a sviluppare la sezione ambientata sulla costa, quella presentazione si è rivelata una preziosa fonte di indicazioni su come procedere."
N/A3984"#commentary\cn_062_transition_tunnels.mp3" "[Randy Lundeen] Per dare forma all'area costiera abbiamo dovuto escogitare un metodo per gestire il passaggio tra i livelli. Mentre il giocatore percorre l'area di transizione, è necessario salvare tutto quanto si trova nel livello di provenienza e ripristinarlo nell'area che viene caricata. Inoltre, è fondamentale eseguire questa operazione per ogni elemento visibile al giocatore nell'area di transizione, anche se si trova all'esterno. Per questo, in genere le aree di passaggio sono più claustrofobiche possibile. In gran parte del gioco abbiamo usato piccole stanze, ma per la costa serviva una soluzione diversa. Dopo qualche esperimento, abbiamo optato per dei tunnel bui. Oltre a essere credibili anche in caso di utilizzi ripetuti, i tunnel ci hanno consentito di sfruttare l'effetto di abbagliamento all'uscita per mascherare l'impossibilità di renderizzare ciò che si trova alla fine del passaggio, considerato che fa parte di un altro livello."
N/A3985"#commentary\cn_063_sniper_alley.mp3" "[Robin Walker] Questa sezione del gioco è stata aggiunta sul finire della lavorazione, quando il laboratorio di Eli e Ravenholm sono stati spostati in modo da precedere l'area costiera. Qualcuno potrebbe pensare che il gioco sia stato sviluppato in modo lineare, ma in realtà abbiamo allestito tre gruppi, lavorando in parallelo su diverse aree a partire dalla sezione centrale del gioco. Inizialmente, ogni gruppo si è concentrato sugli aspetti chiave della sua parte. Dopo aver messo insieme una versione preliminare dell'intero gioco, abbiamo ripreso le singole sezioni per aggiungervi gli elementi più interessanti delle altre o eliminare gli aspetti meno convincenti. In alcuni casi sono stati spostati interi livelli, come Ravenholm, e quando è emersa la necessità di collegarlo alla costa, è stata creata questa sezione. Considerato lo scarso tempo a disposizione, abbiamo scelto di sfruttare elementi di gioco collaudati, come i cecchini e le truppe Combine."
N/A3986"#commentary\cn_064_battery_finding.mp3" "[Robin Walker] Considerata la mole di oggetti negli scenari di Half-Life 2, abbiamo pensato che sarebbe stato interessante chiedere ai giocatori di recuperare un oggetto specifico, magari basando la ricerca su un ragionamento deduttivo. In tal modo, sarebbe stato possibile superare la sfida attraverso la logica e lo spirito d'osservazione, oppure \"con la forza\", limitandosi a setacciare l'intera area. Avevamo già dei modelli per automobili e batterie, quindi abbiamo creato un piccolo sfasciacarrozze da esplorare e abbiamo nascosto un paio di batterie aggiuntive in luoghi improbabili per chi volesse procedere con il secondo metodo. Al pari di altri enigmi basati sugli oggetti, anche qui abbiamo introdotto una scappatoia nel caso in cui i giocatori avessero perso le batterie. Per scoprire di cosa si tratta, potete provare a lanciarle tutte dal dirupo."
N/A3987"#commentary\cn_065_boathouse.mp3" "[Scott Dalton] In Half-Life 1 abbiamo scoperto che le situazioni in cui diverse tipologie di nemici si affrontano possono risultare molto utili. I giocatori adorano osservarle, ed è più semplice analizzare il comportamento dei nemici quando il giocatore non è l'oggetto dei loro attacchi. Il primo scontro tra formicheleone e soldati Combine è stato progettato sia per permettere di investire qualche nemico con la dune buggy, sia per introdurre i martellatori. Osservando le truppe Combine che li sfruttano per arginare le creature, speravamo che i giocatori ne avrebbero colto il funzionamento. Ci piaceva l'idea che fossero i soldati a spiegare l'utilità di restare vicini ai martellatori mentre si affrontano le formicheleone."
N/A3988"#commentary\cn_066_buggy_theft.mp3" "[Scott Dalton] Mentre eravamo al lavoro sulle ultime sequenze dell'area costiera, abbiamo deciso che i Combine avrebbero rubato la dune buggy del giocatore. Non aveva molto senso narrativamente, ma dopo aver svolto numerosi test, abbiamo notato che i giocatori finivano per affezionarsi al veicolo, e volevamo sfruttare quel legame emotivo. Quando abbiamo introdotto la sequenza del furto, alcuni tester hanno preso a inveire contro i Combine. Un chiaro segnale che ci avevamo visto giusto. Il soldato che spara dall'altura serve esclusivamente a distrarre il giocatore per il tempo necessario a far comparire la dropship con la dune buggy. Rivedendo la sequenza oggi, venti anni dopo, sembra a dir poco ridicola."
N/A3989"#commentary\cn_067_snipers.mp3" "[Ted Backman] Il gruppo di lavoro di Half-Life 2 non è mai stato molto numeroso, quindi cercavamo espedienti per creare situazioni di gioco che non avessero costi di produzione elevati. Il cecchino è un esempio perfetto: non ha un modello, e l'unico elemento visibile è il mirino laser, quindi non ha richiesto bozzetti o animazioni. Alla sua morte viene generata la marionetta di un soldato Combine che precipita dalla finestra. Nonostante la sua semplicità, è stato possibile sfruttarlo in numerose sequenze. Siamo rimasti particolarmente soddisfatti dal modo in cui interagiva con gli elementi negli scenari. I giocatori adorano sfruttare gli oggetti esplosivi vicino ai nemici, quindi ci sembrava appropriato creare un nemico in grado di ribaltare questa dinamica."
N/A3990"#commentary\cn_068_buggy_model.mp3" "[Ted Backman] Il modello della dune buggy è stato sottoposto a numerose modifiche prima di trovare la sua forma definitiva. Ma mentre cercavamo un equilibrio tra esigenze artistiche e simulative, ci siamo imbattuti in un problema inatteso: molti tester, persino quelli con lunga esperienza negli FPS, finivano per soffrire di nausea alla guida. Oltre a ritoccare la fisica del veicolo, abbiamo scoperto che modificare il modello poligonale garantiva buoni risultati. Il fastidio era più accentuato quanto più la visuale del mondo esterno era coperta, così abbiamo rimosso progressivamente parti della scocca finché i giocatori non hanno smesso di stare male. In particolare, poter vedere il terreno sotto al veicolo ha avuto un impatto enorme."
N/A3991"#commentary\cn_069_antlion_design.mp3" "[Ted Backman] Nelle prime fasi dello sviluppo avevamo previsto la presenza di diverse razze aliene, oltre ai Combine. Una di queste era composta da creature insettoidi animate da ideali religiosi, e le formicheleone dovevano farne parte. In seguito, durante lo sviluppo dell'area costiera, abbiamo iniziato a considerarle una razza infestante giunta sulla Terra attraverso i portali Xen, insieme ai succhiateste e ad altre creature. Anche se non provengono da Xen, l'idea è che invadano ogni mondo in cui riescono a entrare, più o meno come gli scarafaggi."
N/A3992"#commentary\cn_070_explosive_barrels.mp3" "[Brian Jacobson] In questa sezione introduciamo nel gioco i barili esplosivi, un classico degli FPS, aggiungendo tuttavia un tocco personale: il secondo colpo di pistola incendia il barile, innescando un conto alla rovescia prima dell'esplosione, mentre il terzo proiettile scatena un'esplosione immediata. In questo modo, i giocatori possono scegliere se ritardare l'esplosione o attivarla subito, in base alle necessità. Per esempio, è possibile far ingoiare un barile esplosivo a un cirripede e poi sparargli due volte, eliminando tutti gli esemplari vicini. L'esplosione ritardata, inoltre, consente di creare interessanti reazioni a catena. I barili esplosivi sono sempre stati una risorsa molto apprezzata sia dai fan della serie, sia dai designer dei livelli, che sembrano non averne mai abbastanza."
N/A3993"#commentary\cn_071_ragdoll_magnets.mp3" "[Dario Casali] La fisica di Half-Life 2 ci ha offerto diversi strumenti per rendere i combattimenti più coinvolgenti. Per esempio, quando un nemico manca il bersaglio, la traiettoria dei colpi viene indirizzata verso gli oggetti distruttibili nelle vicinanze, rendendo caotica la scena e creando un'atmosfera da film d'azione. La fisica è stata usata anche per fornire indizi visivi, o creare quelli che chiamavamo \"magneti per marionette\", punti in grado di attirare i cadaveri dei nemici uccisi, facendoli precipitare in modo spettacolare da una sporgenza o sui binari del treno."
N/A3994"#commentary\cn_072_helicopter_peekaboo.mp3" "[Dave Riller] Volevamo usare l'elicottero da combattimento Combine come antagonista principale nel corso di tutto il capitolo. La sua presenza incombente ha finito per renderlo quasi un personaggio a sé. In questa sezione, tendendo le orecchie e alzando lo sguardo, è possibile sentirne il motore e vederlo in lontananza lungo i binari del treno. Questo primo avvistamento è solo un assaggio di ciò che verrà: la sua presenza diventerà via via più minacciosa, fino all'inevitabile scontro frontale."
N/A3995"#commentary\cn_073_iterative_passes.mp3" "[David Speyrer] Alcuni capitoli del gioco, come le sezioni a piedi nei canali o Ravenholm, sono stati sviluppati in più fasi da gruppi di lavoro differenti. Avevamo notato che gestire la lavorazione in questo modo portava a creare un'esperienza di gioco più varia, con una maggiore concentrazione di momenti interessanti, in quanto ogni gruppo finiva per aggiungere il proprio tocco. Nella sezione a piedi dei canali, per esempio, la prima fase della lavorazione ha dettato la direzione artistica e il percorso del giocatore, definendo la struttura del livello e gli eventi principali. In seguito, tuttavia, un alpha test esteso a tutto il team ha rilevato una certa mancanza di tensione e una leggera monotonia, quindi nella seconda fase siamo tornati al lavoro con l'obiettivo di aumentare il numero di eventi e situazioni di gioco uniche."
N/A3996"#commentary\cn_075_pistol_design.mp3" "[Josh Weier] La pistola standard è uno dei pilastri del gioco. Non solo è la prima arma a distanza che il giocatore impara a usare, ma è anche uno strumento essenziale per interagire con la fisica e gli oggetti distruttibili tenendosi a distanza di sicurezza. Per renderla più reattiva e divertente da usare, la pistola è stata dotata di una meccanica unica: la sua cadenza di tiro dipende unicamente dalla velocità con cui il giocatore riesce a premere il comando di fuoco, creando un legame diretto tra l'abilità del giocatore e l'efficacia dell'arma. Più veloce è il clic, più rapida sarà la raffica."
N/A3997"#commentary\cn_076_shatterglass.mp3" "[Josh Weier] Durante la progettazione dei primi livelli, abbiamo scoperto che quando il giocatore ha ancora un numero ridotto di strumenti, illustrare nuove funzionalità tecniche in luogo delle meccaniche di gioco risulta altrettanto coinvolgente. È quello che abbiamo fatto qui con il vetro frantumabile. Per ottenere l'effetto della rottura, il vetro è stato suddiviso in una griglia di piccoli quadrati, consentendoci di tenere traccia delle sezioni integre e danneggiate e di far saltare intere aree quando un determinato numero di quadrati risultava \"scollegato\" dagli altri. Ogni quadrato veniva renderizzato con una texture unica basata sullo stato di quelli adiacenti, generando dei bordi realisticamente frastagliati tra il vetro rotto e quello intatto. Anche se nei videogiochi recenti poter frantumare un vetro viene dato per scontato, all'epoca si vedeva di rado, e siamo rimasti molto soddisfatti del livello di realismo e dinamismo di questa tecnologia."
N/A3998"#commentary\cn_077_lambda_caches.mp3" "[Laura Dubuk] Tecnicamente, la prima cassa di scorte lambda si trova nel laboratorio di Kleiner, ma questa è la prima che il giocatore scopre da solo. Le casse sono state aggiunte per incoraggiare l'esplorazione e suggerire ai giocatori dove trovare risorse utili. Dal punto di vista narrativo, l'idea è che siano state piazzate dalla resistenza per aiutare i ribelli. In Half-Life, il contenuto delle casse era predeterminato. In Half-Life 2, invece, le casse forniscono al giocatore ciò di cui ha più bisogno in quel momento, a seconda dei limiti di risorse impostati dai designer dei livelli."
N/A3999"#commentary\cn_078_scanners.mp3" "[Kerry Davis] Sotto il profilo del design, i droni scanner si sono rivelati una sfida interessante. La loro presenza contribuiva a trasmettere l'idea che l'occupazione dei Combine avesse creato uno stato totalitario, ma non volevamo che attaccassero direttamente il giocatore: affrontare un nemico volante piccolo e rapido non è mai divertente. Tuttavia, il loro ruolo narrativo ci piaceva molto, quindi abbiamo deciso che gli scanner avrebbero avuto una funzione principalmente ricognitiva, segnalando la presenza del giocatore ai nemici vicini. In seguito, abbiamo sottolineato la loro funzione tramite gli effetti sonori dei soldati. Per il resto, avrebbero potuto solo disturbare il giocatore con lampi di luce o lanciarsi contro di lui dopo aver subito danni."
N/A4000"#commentary\cn_079_surface_properties.mp3" "[Ariel Diaz] Quando il giocatore si muove su terreni fangosi e scivolosi, il rumore dei passi viene reso con un effetto sonoro specifico. Questo sistema, denominato \"proprietà delle superfici\", determina suoni ed effetti visivi usati in base alla natura del materiale con cui si interagisce. Nelle fasi iniziali dello sviluppo, avevamo previsto anche che i movimenti del giocatore venissero rallentati quando attraversava terreni fangosi, ma questa caratteristica è stata rimossa nella versione finale perché ritenuta troppo frustrante."
N/A4001"#commentary\cn_080_combat_entrances.mp3" "[Dario Casali] Girare l'angolo e trovarsi di fronte dei nemici fermi ad attenderci è sempre spiazzante. Rende il mondo di gioco meno credibile, come una sorta di tiro a segno. Ragionamenti del genere ci hanno motivati a far entrare in scena i nemici in modi più dinamici e interessanti, che comunicassero l'idea di un'azione eseguita secondo un piano. Come se aspettassero Gordon con una strategia concordata. Qui i poliziotti saltano giù con una sequenza scriptata, e più avanti nel gioco il medesimo effetto viene ottenuto facendoli calare dalle corde. All'atto pratico, non importa da dove stiano arrivando, perché il giocatore riempie da sé i vuoti narrativi. Abbiamo imparato che ogni combattimento deve suggerire una storia: un'imboscata, una trappola, un attacco in forze, un assalto. Per quanto usassero tutti più o meno la stessa IA, agli occhi dei tester questi scenari risultavano molto diversi tra loro."
N/A4002"#commentary\cn_081_mounted_gun_gallery.mp3" "[Dave Riller] Questa scena presenta diversi aspetti interessanti. La torretta che spara contro le casse, per esempio, serve a far capire al giocatore che affrontare la minaccia frontalmente è inutile, e che è meglio aggirarla usando il passaggio nelle fogne. Una volta raggiunta la torretta, il giocatore può usarla per bersagliare i soldati Combine e i droni scanner. Inoltre, viene presentato il blindato dei Combine armato di missili, che costringe il giocatore a fuggire e che tornerà più avanti nel capitolo."
N/A4003"#commentary\cn_082_barnacle_bowling.mp3" "[Josh Weier] Questa sezione è indicativa di come diverse meccaniche di gioco possano interagire tra loro dando vita a momenti memorabili. Ci sono i cirripedi, la fisica, le superfici fangose con le relative proprietà e, ovviamente, i barili esplosivi. Tutti elementi che il giocatore ha già visto in precedenza, ma che insieme finiscono per creare un momento che abbiamo chiamato \"bowling con i cirripedi\"."
N/A4004"#commentary\cn_083_barnacle_introduction.mp3" "[Mike Dussault] Per evitare che i cirripedi disorientassero i giocatori, abbiamo deciso di presentarli illustrando chiaramente il loro comportamento da una distanza di sicurezza. Per questo, abbiamo optato per una scena da documentario, mostrando il rapporto tra predatore e preda. Scene simili hanno sempre richiesto molto lavoro per assicurarci che i giocatori cogliessero gli aspetti salienti."
N/A4005"#commentary\cn_084_physics_in_puzzles.mp3" "[Eric Smith] In genere, le meccaniche più semplici presentate nelle prime fasi di gioco sono estrapolate da altre più complesse per illustrarne il funzionamento. Il bilico, il primo enigma basato sulla fisica che si incontra nel gioco, è ispirato a un rompicapo più complesso presente nei canali, che ruota attorno a una lavatrice. Il bilico sfrutta gli stessi principi di massa e leve, ma in forma più elementare, permettendo al giocatore di provare la fisica del gioco e fornendogli gli strumenti per risolvere gli enigmi successivi. La struttura suggerisce inoltre la natura analogica del sistema fisico, evidenziando come il posizionamento dei blocchi di cemento e il peso del giocatore influiscano entrambi sulla soluzione."
N/A4006"#commentary\cn_085_combine_attack_helicopter.mp3" "[Brian Jacobson] Dopo averne suggerito più volte la presenza, in questa sequenza viene finalmente presentato il boss dei canali: l'elicottero d'assalto Combine. Le sue armi distruggono sistematicamente i ripari del giocatore, costringendolo alla fuga. Volevamo che questa sequenza trasmettesse un senso di minaccia, comunicando chiaramente che l'elicottero è un nemico troppo potente per affrontarlo direttamente. L'idea era di tenere viva la tensione per tutta la sezione nei canali, fino allo scontro finale nel bacino idrico. A questo scopo, abbiamo limitato i movimenti dell'elicottero in base agli obiettivi desiderati. In questa fase, pensata come una corsa da un riparo all'altro sotto il fuoco nemico, abbiamo impostato un percorso ad anello nei cieli sovrastanti l'arena. L'elicottero si posiziona sempre nel punto più lontano dell'anello rispetto al giocatore, restando visibile e permettendoci di posizionare con precisione i ripari."
N/A4007"#commentary\cn_087_explosive_barrel_factory.mp3" "[David Speyrer] Questa stanza piena di barili esplosivi ha dato vita all'interno del team a uno spassoso dibattito sulla verosimiglianza del mondo di gioco, e su quanto fosse opportuno spingersi oltre. In effetti, in termini di realismo anche un singolo barile esplosivo sarebbe eccessivo, considerato che i barili non dovrebbero esplodere nemmeno sparandogli contro."
N/A4008"#commentary\cn_088_rising_water.mp3" "[Dhabih Eng] Il ponte sull'acqua e le bobine in legno di questa sezione servono a illustrare al giocatore le proprietà di galleggiamento. Non si tratta esattamente di un enigma: più che altro, è un momento in cui è possibile interagire con la fisica di gioco divertendosi. Questi elementi verranno ripresi nei canali in una sezione in cui sarà necessario sollevare una rampa per consentire il passaggio dell'idroscivolante."
N/A4009"#commentary\cn_089_manhack_matt.mp3" "[John Morello] Durante la lavorazione, questo personaggio era noto come \"Matt delle lame\". Volevamo comunicare l'idea che i meandri di City 17 ospitassero centinaia di cittadini. Essendo passato del tempo dall'ultima interazione tra il giocatore e un essere umano, abbiamo approfittato di questa sequenza per illustrare meglio il ruolo delle lame della morte, il primo nemico basato sulla fisica che abbiamo creato. Inizialmente, in città doveva esserci una sala giochi in cui i cittadini controllavano le lame per attaccare altri esseri umani in una simulazione. Ovviamente, più avanti si scopriva che era tutto vero. Man mano che sviluppavamo la nostra visione dell'occupazione dei Combine, l'idea ci è sembrata sempre meno adatta al tono del gioco, e alla fine è stata scartata."
N/A4010"#commentary\cn_090_fighting_motion_sickness.mp3" "[David Speyrer] Nel corso dei primi test, diversi giocatori hanno accusato una forte nausea guidando l'idroscivolante. Cercando una soluzione, abbiamo identificato numerosi fattori scatenanti. Rendere più scarno il modello del veicolo, per esempio, era di grande aiuto, quindi l'abbiamo modificato più volte. Anche mantenere stabile il numero di frame risultava molto utile, quindi abbiamo curato più possibile le prestazioni grafiche in queste sezioni. Tuttavia, il fattore più importante si è rivelato l'eliminazione del rollio della visuale al fine di mantenere stabile l'orizzonte a prescindere dai movimenti del veicolo. Uno dei programmatori, che soffriva terribilmente di chinetosi, si offrì volontario per effettuare vari test e valutare i progressi. Sono quasi certo che abbia vomitato almeno una volta dopo una sessione. Il suo generoso sacrificio è stato molto apprezzato."
N/A4011"#commentary\cn_091_headcrab_canisters.mp3" "[Jeff Lane] Nelle strade di Ravenholm, più avanti nel gioco, sono presenti numerose capsule per succhiateste, quindi abbiamo deciso di sfruttare questa sequenza per mostrarne l'utilizzo da parte dei Combine. L'idea è che gli invasori abbiano trasformato la fauna Xen in un'arma biologica da usare contro gli umani. Questa sezione vede inoltre l'esordio di una nuova specie: i succhiateste che emergono dal terreno. Nel corso dello sviluppo, l'area si è allargata fino a diventare una baraccopoli devastata dall'invasione dei succhiateste."
N/A4012"#commentary\cn_092_airboat_intro.mp3" "[John Morello] In questa sequenza, il giocatore ottiene il primo veicolo del gioco, l'idroscivolante. Volevamo creare uno spazio sicuro in cui esercitarsi alla guida per tutto il tempo necessario prima di proseguire. Abbiamo inserito vari punti in cui eseguire salti e acrobazie, e riempito l'area di melma tossica per spingere il giocatore a restare a bordo e impedirgli di lasciare il veicolo e proseguire a piedi."
N/A4013"#commentary\cn_093_zombie_surprise.mp3" "[Jeff Lane] In questa condotta fognaria ci siamo divertiti a inserire un momento horror piuttosto riuscito. Mentre il giocatore avanza lungo il tunnel con la massima concentrazione, all'improvviso uno zombi emerge dall'acqua terrorizzandolo. Ricordo che uno dei tester finì per cadere dalla sedia durante la sezione, e lo considerammo un successo."
N/A4014"#commentary\cn_094_airboat_time.mp3" "[Dave Riller] Trovare un equilibrio tra il tempo trascorso a bordo di un veicolo e quello a piedi ha richiesto parecchio lavoro. Guidare a tutta velocità consentiva di attraversare gli scenari troppo in fretta, e durante i primi test ci siamo resi conto che i giocatori si perdevano momenti chiave e dettagli importanti. Esplorazione e immersività sono due dei pilastri di Half-Life, e non volevamo che la presenza di un veicolo potesse intaccarli. Per ovviare al problema, abbiamo disseminato gli scenari di piccole aree piene di dettagli da esplorare a piedi. Inoltre, perfezionando il motore fisico abbiamo appreso nuovi modi per sfruttarne le possibilità. Queste sezioni ci hanno consentito di introdurre un elemento di scoperta per i giocatori, facendoli interagire con i fluidi e la fisica in diversi modi. Per esempio, lanciando casse nell'acqua o sfruttando dei barili per sollevare una rampa."
N/A4015"#commentary\cn_095_floating_supplies.mp3" "[Josh Weier] Nel corso degli alpha test, i canali erano disseminati di casse di rifornimenti galleggianti che i giocatori potevano distruggere con l'idroscivolante per raccoglierne il contenuto. La meccanica era molto \"da videogioco\", ma aiutava a mantenere il ritmo, permettendo di fare rifornimento in corsa. Per dare maggiore plausibilità alla circostanza, abbiamo deciso di spiegare come mai quelle casse si trovassero lungo il percorso del giocatore. Questa scena, in cui i cittadini lanciano casse di rifornimenti, dona credibilità all'idea e, al tempo stesso, rende il livello più vibrante. Inoltre, ricevere supporto da un tale numero di personaggi secondari finisce per far sentire i giocatori ancora più importanti ed eroici."
N/A4016"#commentary\cn_096_grenade_intro.mp3" "[Brian Jacobson] Questa base dei Combine è una via di mezzo tra un centro di addestramento per le granate e un tiro a segno. La presenza di casse di rifornimento infinite serve a segnalare al giocatore che può usarle liberamente, senza preoccuparsi di esaurirle. Come a dire: \"Prego, scatenati!\". Lo scontro in questa zona è stato progettato per condurre i soldati verso le coperture e offrire molte opportunità per usare le granate. Nelle battute finali, la presenza di altre granate infinite consente al giocatore di gestire le torrette, che altrimenti sarebbero difficili da affrontare direttamente. Abbiamo dotato le granate di una luce rossa e di una scia di particelle, al fine di seguirne più facilmente la traiettoria sia quando vengono lanciate, sia quando si cerca di evitare quelle usate dalle truppe Combine."
N/A4017"#commentary\cn_097_puzzle_layers.mp3" "[Dave Riller] Spesso i giocatori non sono consapevoli degli obiettivi che si prefiggono gli sviluppatori. Ed è una fortuna, perché questo garantisce che reagiscano a ogni sfida in modi sorprendenti. Anche situazioni apparentemente elementari possono richiedere numerosi tentativi prima di giungere a una soluzione. È il caso di questo enigma per aprire il cancello del canale, che ha richiesto l'inserimento di diversi livelli di suggerimenti. Le scintille emesse dalla ruota comunicano che normalmente è lì che andrebbe aperto il passaggio, ma che le circostanze impongono di ricorrere a un altro metodo. In seguito, dei corvi attirano lo sguardo del giocatore verso la soluzione: un fascio di travi penzolante. Essendo già state introdotte le granate, inizialmente volevamo che il giocatore ne lanciasse una per distruggere i supporti di legno, ma non ci sembrava intuitivo. Per questo, abbiamo aggiunto dei barili esplosivi, che suggeriscono più chiaramente la soluzione. Tuttavia, pur avendo risolto l'enigma, alcuni giocatori non si accorgevano dell'apertura del passaggio e continuavano a esplorare la base in cerca dell'uscita, quindi abbiamo provato a ricordare loro il problema iniziale: il cancello rotto. Solo dopo aver aggiunto del fumo, una sirena e una luce lampeggiante abbiamo iniziato a vedere risultati costanti nei test."
N/A4018"#commentary\cn_098_metrocop_strafing.mp3" "[Doug Wood] Inizialmente, il design dei livelli con l'idroscivolante era pensato per mettere alla prova i giocatori costringendoli a guidare sotto il fuoco delle forze dell'ordine. Le loro raffiche erano studiate per costringere a veloci slalom tra i proiettili. Tuttavia, durante il nostro processo di revisione interna, denominato \"Overwatch\", alcuni tester si sono detti frustrati dal fatto di essere bersagliati senza poter rispondere. Volevano che il veicolo trasmettesse una sensazione di potenza, che fosse inarrestabile. Sulla base delle loro opinioni, abbiamo riprogettato i livelli per puntare più sull'emozione che sulla difficoltà, passando da sezioni incentrate sull'evitare i colpi nemici a combattimenti serrati con barriere da sfondare a tutta velocità."
N/A4019"#commentary\cn_100_mounted_gun.mp3" "[Jeff Lane] Le mitragliatrici fisse sono state aggiunte per suggerire al giocatore le armi da usare durante lo scontro finale con l'elicottero d'assalto nel bacino idrico. Fino a quel momento, l'elicottero è invulnerabile alle armi disponibili, quindi era necessario indicare chiaramente che potesse essere danneggiato con armamenti più pesanti. Tuttavia, nei test questo messaggio non giungeva sempre in modo chiaro, a causa della pressione costante sul giocatore, quindi abbiamo aggiunto effetti visivi e sonori che rendessero più evidente che l'elicottero stava subendo danni."
N/A4020"#commentary\cn_101_357_intro.mp3" "[Josh Weier] A differenza della pistola base, la cadenza di tiro ridotta della magnum impone un uso più controllato e mirato, volto a infliggere danni devastanti al bersaglio. Nelle sue versioni iniziali, la magnum soffriva di una leggera dispersione casuale, che ci sembrava coerente con il peso dell'arma e la ridotta sensibilità del grilletto. Tuttavia, questo aspetto causava nei giocatori dei momenti di frustrazione, visto che pur prendendo la mira con la massima precisione, finivano a volte per mancare il bersaglio. Per risolvere il problema, abbiamo fatto in modo che il primo colpo fosse estremamente preciso e che, continuando a sparare, i successivi diventassero sempre meno accurati."
N/A4021"#commentary\cn_102_helicopter_bombing_run.mp3" "[Brian Jacobson] Questa sequenza illustra uno dei tranelli che abbiamo inserito nelle fasi in cui il giocatore è alla guida dell'idroscivolante. Di norma, l'elicottero cerca di tenersi di fronte al veicolo bombardandolo, ma se si cerca di tornare indietro, passa a un volo a punto fisso e si gira per bersagliare il giocatore. Durante uno dei test, una bomba è finita tra le giunture dei condotti, con risultati spettacolari. Il tester ha reagito in maniera entusiasta, così abbiamo deciso di scriptare la scena in modo che si verificasse sempre. Questo modo di lavorare è diventato parte del nostro iter progettuale: se durante un test si verifica un imprevisto interessante, cerchiamo di renderlo parte integrante del livello."
N/A4022"#commentary\cn_103_smokestack_collapse.mp3" "[Doug Wood] Durante lo sviluppo del primo Half-Life, speravamo di realizzare sequenze di distruzione spettacolari, ma non siamo mai riusciti a ottenere nulla di convincente. Quando la fisica di Half-Life 2 ha introdotto la possibilità di distruggere oggetti fisici come le casse, abbiamo deciso di provare con qualcosa di più grande. Così, abbiamo pensato di far crollare una ciminiera in modo che andasse in pezzi durante la caduta. Abbiamo sperimentato con la massa fino a ottenere risultati soddisfacenti, perfezionato il modello, poi aggiunto fumo ed effetti sonori per rendere tutto più credibile. Alla fine, abbiamo ottenuto la sequenza di distruzione dei nostri sogni. In effetti, il nostro motore fisico riusciva a stento a mettere in scena quanto descritto in modo accettabile per gli standard moderni, ma all'epoca era qualcosa di entusiasmante. Considerato che la simulazione era diversa ogni volta, sono state necessarie alcune precauzioni per evitare che i detriti più voluminosi bloccassero il percorso del giocatore. Il successo di questa sequenza ha aperto la strada a effetti ancora più complessi e realistici, che avremmo usato tempo dopo in Episode Two."
N/A4023"#commentary\cn_104_washing_machine_puzzle.mp3" "[David Speyrer] Abbiamo creato l'enigma della lavatrice verso la fine dello sviluppo, quando i test hanno evidenziato il bisogno di una pausa dalla costante minaccia dell'elicottero. Variare il ritmo di gioco esalta i momenti di tensione, perché consente al giocatore di cambiare il registro emotivo tenendo alla larga stanchezza e noia. Senza dubbio, la forte reazione emotiva ottenuta rendendo l'elicottero una minaccia costante era un dato positivo, ma se non avessimo gestito al meglio lo stress generato, presto sarebbe subentrata la fatica, poi un senso di monotonia. Inizialmente, i giocatori attraversavano l'area guidando a tutta velocità, ma vista la luce incantevole e la splendida cornice fornita dal canale, abbiamo deciso che fosse il luogo ideale per rallentare l'azione e lasciare che il giocatore si rilassasse per qualche istante usando il cervello. L'enigma, il primo del gioco basato su massa e carrucole, ha poi ispirato momenti simili in altre sezioni."
N/A4024"#commentary\cn_105_airboat_changeup.mp3" "[Jeff Lane] Nel corso dei test, era emersa chiaramente la richiesta di rendere più varie le dinamiche di gioco a bordo dell'idroscivolante. Fino a quel momento, il giocatore non possiede alcun mezzo per reagire agli attacchi dell'elicottero o di altri nemici, quindi ci è sembrato opportuno fornirgli una nuova arma, cambiando il ritmo di gioco e preparando il terreno per gli eventi a venire. Nelle aree successive, abbiamo inserito un poligono di tiro utile a familiarizzare con le sue caratteristiche. La forza d'urto dei proiettili era tale da far volare via i bersagli, mostrando che la nuova arma era la più potente nell'arsenale del giocatore. Tuttavia, durante i test del combattimento contro l'elicottero, molti giocatori continuavano a essere convinti che fosse invulnerabile. I nostri sforzi per mostrare che il nemico veniva danneggiato dalle torrette Combine nelle sequenze precedenti erano stati vani. Per risolvere il problema abbiamo bandito ogni sottigliezza, posizionando l'elicottero all'uscita del tunnel in cui si ottiene l'arma e specificando che bisognava usarla contro il velivolo. Per fortuna, la strategia ha funzionato."
N/A4025"#commentary\cn_106_donkey_kong_barrel_ramp.mp3" "[Eric Smith] Inizialmente, l'area della rampa di scarico doveva essere solo un elemento architettonico interessante, ma durante i test è emerso subito quanto fosse divertente usarla per sfrecciare su e giù con l'idroscivolante, così abbiamo aggiunto altri elementi per valorizzare quell'esperienza. Tra questi, i poliziotti che lanciano barili verso il giocatore: un piccolo omaggio a Donkey Kong."
N/A4026"#commentary\cn_107_lambda_cache_interlude.mp3" "[Danika Rogers] Fondamentalmente, Half-Life è un'esperienza lineare, ma abbiamo sempre cercato degli stratagemmi per interrompere il cammino del giocatore e introdurre elementi esplorativi nei livelli. Questa cassa di scorte lambda e la successiva imboscata di zombi e succhiateste, per esempio, sono totalmente opzionali. Il loro unico scopo è rendere meno lineare questa sezione del viaggio attraverso i canali."
N/A4027"#commentary\cn_108_skybox_time_of_day.mp3" "[Eric Kirchmer] Durante questo capitolo, i colori del cielo e della nebbia cambiano gradualmente. È un modo per rappresentare visivamente il passare del tempo durante il viaggio del giocatore attraverso i canali e il capitolo stesso. I due gradienti opposti della nebbia rendono l'idea che il sole si trovi a un'angolazione obliqua. In effetti, è possibile notare come il tramonto sia ormai prossimo. Il viaggio culmina nello scontro con l'elicottero al calar del sole, in un'arena da cui è possibile intravedere Ravenholm."
N/A4028"#commentary\cn_109_helicopter_megabomb_origin.mp3" "[Brian Jacobson] L'attacco con la \"megabomba\" dell'elicottero è nato da un bug: un programmatore aveva rimosso per errore il tempo di attesa tra un ordigno e l'altro, causando il lancio in contemporanea di centinaia di bombe. L'effetto era così spettacolare che decidemmo di usarlo come attacco finale del bombardamento."
N/A4029"#commentary\cn_110_helicopter_final_battle.mp3" "[Dave Riller] Abbiamo progettato quest'area come teatro dello scontro finale tra il giocatore e l'elicottero d'assalto Combine. Finalmente, il giocatore ha l'occasione di eliminare il nemico che lo ha braccato da quando ha lasciato il laboratorio di Kleiner. L'area ha subito numerose modifiche prima di assumere il suo aspetto definitivo. Era necessario garantire spazio sufficiente per un combattimento ad alta velocità tra veicoli, con percorsi chiaramente leggibili che consentissero la massima fluidità di movimento. Tutto questo con un buon livello di prestazioni. Abbiamo cercato di ottenere un impatto visivo adatto a uno scontro, spettacolare ma non troppo caotico. Qualcosa che risultasse indimenticabile una volta abbattuto l'elicottero."
N/A4030"#commentary\cn_111_airboat_wreckage.mp3" "[David Speyrer] Originariamente, avevamo previsto che l'idroscivolante venisse distrutto durante il salto della diga, pertanto questo livello doveva iniziare con il giocatore tra i rottami del veicolo. Tuttavia, durante un test interno esteso a tutta la squadra, molti si dissero delusi per la perdita del veicolo, a cui si erano affezionati. Ne seguì un dibattito sul fatto che quella sensazione di perdita fosse o meno un'esperienza significativa. Alla fine, decidemmo di lasciare intatto l'idroscivolante, per mantenere aperta la possibilità di tornare a usarlo. Alcuni dicono che sia ancora lì, in attesa."
N/A4031"#commentary\cn_112_arena_exit_gate.mp3" "[Quintin Doroquez] Il meccanismo per sollevare il cancello di uscita è stato aggiunto per costringere il giocatore a sconfiggere l'elicottero prima di poter proseguire. In genere, queste strategie di design vengono definite \"gating\", e consistono nel bloccare l'avanzamento del giocatore finché non ha completato un determinato obiettivo. In questo caso, la strategia ruota letteralmente attorno a un \"gate\", un cancello."
N/A4032"#commentary\cn_113_blocking_tutorials.mp3" "[Adrian Finol] A volte, dobbiamo essere certi che il giocatore comprenda una determinata meccanica, e il metodo standard, almeno nello sviluppo di videogiochi, non nella vita reale, è bloccarlo in modo che possa superare l'ostacolo solo dimostrando di aver capito. Generalmente si cerca di camuffare questi ostacoli in modo che siano organici rispetto al gioco, ma ovviamente il tempo, le risorse disponibili o il contesto possono finire per complicare la situazione. In questo caso, dovevamo insegnare al giocatore a spostare gli oggetti, quindi abbiamo optato per un semplice enigma da risolvere impilandoli. Avevamo valutato anche enigmi più complessi, ma finivano per rivelarsi meno efficaci nel trasmettere le nozioni necessarie."
N/A4033"#commentary\cn_114_natural_storytelling.mp3" "[Bill Van Buren] Per ottenere gli obiettivi narrativi che ci eravamo prefissi nella stazione ferroviaria e delineare il mondo di gioco, dovevamo gestire i dialoghi in un modo che non fosse troppo artificioso o complesso. Ci siamo accorti che spesso i giocatori si avvicinavano ai personaggi per osservarli, quindi abbiamo trasformato questa dinamica in un'opportunità, assicurandoci che i personaggi reagissero alla presenza del giocatore parlandogli. In questo modo, abbiamo anche mantenuto il necessario tono di sobrietà, visto che i cittadini non sono particolarmente allegri o spensierati. La semplicità di questo approccio, peraltro, è in linea con uno dei pilastri del design di Half-Life: la storia deve reagire agli interessi del giocatore. Alcuni vogliono approfondire ogni dettaglio, altri solo sapere cosa fare. Dare al giocatore il controllo su quanta storia fruire senza ostacolarne i progressi è da sempre uno dei nostri obiettivi. Inoltre, più una funzione è semplice da implementare, più possiamo utilizzarla."
N/A4034"#commentary\cn_115_trainstation.mp3" "[Charlie Brown] Le prime fasi dei giochi della serie Half-Life rivestono un'importanza capitale: devono condurre i giocatori in un nuovo mondo, insegnando loro come interagirvi. È necessario cogliere velocemente cosa sta accadendo, chi sono i personaggi chiave, quali minacce bisognerà affrontare e qual è il ruolo del giocatore. E ovviamente, tutto questo deve essere più divertente e interattivo possibile. Riuscire in questo intento richiede un'infinità di modifiche e test, incentrati soprattutto sui piccoli momenti che compongono il quadro generale. In questa sezione ripercorreremo vari passaggi chiave dello sviluppo, le sfide di progettazione affrontate e alcuni test che non sono andati secondo i piani."
N/A4035"#commentary\cn_116_physics_objects.mp3" "[David Sawyer] Oggi, dettagli simili potranno sembrare scontati, ma quando Half-Life 2 ha fatto il suo debutto, piccoli oggetti come questa spazzatura erano generalmente statici. Non si muovevano, o se lo facevano, era in modo molto semplice. Nel migliore dei casi, si scomponevano in sprite una volta colpiti. Uno degli obiettivi, in questa sezione iniziale della stazione, era far capire ai giocatori che in Half-Life 2 questi oggetti venivano simulati fisicamente. Potevano essere raccolti, lanciati, spostati da forze esterne, distrutti e via discorrendo. Qui partiamo da qualcosa di molto semplice: mostrare che la spazzatura viene spostata dall'arrivo del treno, o più precisamente, da un volume invisibile che si attiva non appena il giocatore lascia il vagone."
N/A4036"#commentary\cn_117_blocking_tutorials_3.mp3" "[Eric Smith] Il secondo problema di quest'area è un caso di \"insegnamento involontario\", ovvero una situazione in cui insegniamo al giocatore qualcosa che non avevamo previsto. È difficile evitare che accada senza eseguire molti test, perché il gioco insegna sempre qualcosa, anche senza volerlo. Più avanti nella stazione, troveremo un esempio ancora più estremo. Alcuni errori di questo tipo vanno tassativamente rettificati, come i casi in cui il giocatore impara a usare in modo scorretto un'arma o una meccanica base del gioco. Qui l'errore era più sottile: nell'insegnare ai giocatori a spostare gli oggetti, abbiamo anche insegnato loro a impilarli per uscire da una stanza. Di per sé non sarebbe un problema, ma in seguito non sono più presenti enigmi di quel tipo, quindi il giocatore si ritrova con un'informazione superflua, che finisce solo per complicare la memorizzazione delle meccaniche realmente utili. Inoltre, impilare gli oggetti per cercare di uscire dagli scenari diventa un problema concreto nelle sezioni successive, e visto il numero di oggetti interagibili, non è stato possibile prevenirlo posizionando soffitti ovunque. Alla fine, ci siamo limitati a sperare che i giocatori non prestassero più attenzione del necessario a questa spiegazione, e quando abbiamo visto che alcuni partecipanti ai test rimanevano bloccati in situazioni simili, ci siamo ben guardati dal ricordargliela."
N/A4037"#commentary\cn_118_welcome.mp3" "[Gabe Newell] Sono Gabe Newell. È un piacere accoglierti nuovamente in Half-Life 2. Sono trascorsi vent'anni dall'uscita del gioco, e in questo aggiornamento celebrativo abbiamo cercato di esaudire quante più richieste possibile tra quelle provenienti dalla community. Anche se non si tratta della richiesta numero uno in assoluto, so che tanti desideravano una modalità di gioco commentata, quindi siamo felici di averla finalmente realizzata. Rievocare tutti i dettagli dello sviluppo di Half-Life 2 non è stato facile, e nemmeno rimettere mano a del codice scritto vent'anni fa chiedendosi il perché di determinate decisioni. Oltre a inserire questo commento, abbiamo approfittato dell'occasione per correggere una serie di vecchi bug, nel tentativo di lasciare il gioco in condizioni migliori di come l'abbiamo trovato. Se non altro, stavolta abbiamo il privilegio di conoscere l'esito delle nostre scelte. Per ascoltare un commento, porta il mirino sul simbolo fluttuante e premi il comando \"Usa\". Per interrompere la riproduzione, porta nuovamente il mirino sul simbolo rotante e premi il comando \"Usa\". Non dimenticare di farmi avere le tue impressioni. Puoi scrivermi all'indirizzo gaben@valvesoftware.com. Grazie, e buon divertimento!"
N/A4038"#commentary\cn_119_metrocop_shoving_citizens.mp3" "[Josh Weier] Dopo pochi passi, ecco i primi problemi da affrontare. Qui entrano in scena i tutori dell'ordine, nemici che più avanti chiederemo ai giocatori di affrontare, e diamo una prima occhiata al mondo di gioco. È un momento dalle implicazioni chiare, che mostra il rapporto tra i poliziotti e i cittadini, e di riflesso tra i poliziotti e il giocatore. Allo stesso tempo, abbiamo voluto rafforzare la presenza della simulazione fisica, mostrando come anche i personaggi siano in grado di interagire con gli oggetti negli scenari. All'epoca, vedere una valigia urtarne una seconda e spingerla via era una novità. Scene come queste alla stazione, che consentono di ottenere più obiettivi contemporaneamente, risultano particolarmente efficaci e naturali, evitando l'impressione che l'azione si sia fermata solo per spiegare qualcosa al giocatore."
N/A4039"#commentary\cn_120_fall_damage.mp3" "[Kerry Davis] Illustrare le meccaniche di gioco è un compito fondamentale. Ma per consentire ai giocatori di prendere decisioni informate, è necessario insegnare loro a cogliere alcune sottigliezze. Questa breve sequenza ne contiene due: oltre a mostrare da quale altezza il giocatore può cadere senza subire danni, presenta un aspetto del \"lessico\" di gioco, ovvero le modalità con cui il gioco in seguito comunicherà con lui. Spesso il timore dei danni da caduta si accompagna a quello di fare un passo con conseguenze irreparabili. Qui, una cassa accuratamente posizionata segnala che è sicuro saltare, e che quella è la strada da seguire. Quando la cassa si rompe, inoltre, rafforza l'idea della simulazione fisica. Probabilmente è la prima volta in cui viene mostrato al giocatore che anche gli oggetti più grandi possono andare in pezzi."
N/A4040"#commentary\cn_121_sweeping_vortigaunt.mp3" "[Laura Dubuk] Questo è un altro momento chiave della narrazione abbinato a una strizzata d'occhio al sistema di simulazione fisica. La sequenza mostra la posizione dei Vortigaunt in questo nuovo mondo. Un cambiamento radicale rispetto al loro ruolo di nemici in Half-Life 1. Al pari di altri momenti narrativi presenti nella stazione, il Vortigaunt che spazza nasce dal nostro desiderio di mostrare i personaggi che interagiscono in modo naturale con la simulazione fisica. Perché limitarsi a comunicare che i Vortigaunt sono ormai degli amici quando è possibile mostrarne uno che spazza il pavimento ripulendolo da qualche oggetto simulato? Non c'è nulla che dica \"non spararmi\" più chiaramente di un personaggio che spazza in giro."
N/A4041"#commentary\cn_122_blocking_tutorials_2.mp3" "[Robin Walker] Questo tutorial presenta due problemi: il primo è che i giocatori possono bloccarlo lanciando tutte le casse dalla finestra. Un grosso guaio, visto che facendolo finirebbero per non poter proseguire nel gioco. Si tratta di un bug critico da risolvere. Una soluzione elegante sarebbe stata modificare le dimensioni della finestra o delle casse in modo da consentire solo al giocatore di passarci attraverso. Purtroppo, questo problema è emerso nelle fasi finali dello sviluppo, quando anche un cambiamento apparentemente semplice può avere effetti collaterali imprevedibili. E questo, proprio a ridosso del lancio. Va detto che si trattava di un problema esclusivamente teorico. Nel corso dei test, nessuno l'aveva mai fatto, e le prove di questa sezione erano sempre andate lisce: i giocatori imparavano ciò che serviva e proseguivano. Modificare il design della stanza rischiava di compromettere quel risultato in modi difficili da prevedere. Quindi abbiamo optato per una soluzione più prudente che elegante. Per scoprirla, è sufficiente lanciare tutte le casse fuori dalla finestra."
N/A4042"#commentary\cn_123_playground.mp3" "[Brian Jacobson] Discutendo dei modi per evidenziare la fisica simulata in un ambiente cittadino, un parco giochi ci è sembrato la scelta naturale. Per i giocatori attenti al dottor Breen, è anche un promemoria di quanto sia costata all'umanità la resa ai Combine. Scelte le strutture con un potenziale fisico promettente, abbiamo iniziato a metterle a punto. Pur disponendo di un sistema di fisica avanzato, situazioni del genere richiedono sempre un intervento diretto, quando oggetti pienamente simulati interagiscono con altri simulati solo parzialmente o niente affatto, come il giocatore o le geometrie statiche. Si potrebbe presumere che una simulazione possa gestire gran parte del carico di implementazione, ma persino oggi, vent'anni più tardi, accade di rado. Quando abbiamo lavorato sul parco giochi, a sviluppo già inoltrato, non siamo riusciti a regolare correttamente la frizione dello scivolo. Pertanto, abbiamo rotto la scala per impedire al giocatore di salirci. Ciononostante, è comunque possibile salire camminando dal davanti. Come sempre, l'ultima risata spetta al giocatore."
N/A4043"#commentary\cn_124_pick_up_that_can.mp3" "[Charlie Brown] Contestualizzare i tutorial, creando uno scenario in cui calarli, ci consente di fare molto più che fermare il giocatore per spiegargli qualcosa. Possiamo donare al momento un peso narrativo. Qui, la spiegazione del lancio degli oggetti si combina con uno scenario narrativo che consente di scegliere una risposta. Dopo aver assistito agli abusi sulla cittadinanza da parte della polizia, era il momento di calare il giocatore in una situazione simile. Se ha maturato un'opinione su come i cittadini dovrebbero reagire, ora può esprimerla. A giudicare dai test, la maggior parte dei giocatori obbediva o si rifiutava di raccogliere la lattina, ma alcuni provavano a evitare del tutto il confronto. Altri obbedivano all'inizio, per poi ribellarsi sentendosi umiliati. Limitando i confini dello scenario, in termini di azioni concesse e di spazio, avremmo potuto rispondere appropriatamente a qualsiasi scelta compiuta."
N/A4044"#commentary\cn_125_promises.mp3" "[Danika Rogers] Nelle prime fasi di un gioco di Half-Life, uno dei nostri obiettivi è fare promesse al giocatore, accennando a ciò che lo attende in seguito. Film, serie televisive, libri... Tutto l'intrattenimento di qualità usa espedienti simili, e i videogiochi non fanno eccezione. In un gioco di Half-Life, le promesse possono assumere forme diverse. Alcune sono semplici, come far intravedere qualcosa di interessante. Altre sono più complesse, come le interazioni con la polizia. Costringendo il giocatore in una condizione di impotenza, prepariamo la scena per il momento in cui potrà finalmente vendicarsi."
N/A4045"#commentary\cn_126_exploration.mp3" "[David Sawyer] Dopo averlo guidato per la stazione con i poliziotti, volevamo concedere al giocatore l'opportunità di esplorare. Questa piazza fornisce interazioni diverse con cittadini, poliziotti, scanner e infrastrutture. Desideravamo che queste interazioni contribuissero a raccontare il mondo senza la necessità di tutorial espliciti, e le abbiamo rifinite affinché funzionassero naturalmente, senza alcuna preparazione."
N/A4046"#commentary\cn_127_early_game_exploration.mp3" "[David Speyrer] Prima di questa piazza, è improbabile che il giocatore abbia pensato al proprio percorso, finora sempre chiaro e diretto. Qui, tuttavia, volevamo incoraggiare l'esplorazione, rendendo la progressione meno ovvia, con il prevedibile rischio di suscitare un senso di smarrimento o, peggio ancora, di confusione. Una svolta potenzialmente brusca, specialmente all'inizio, quando il giocatore sta ancora apprendendo i segnali guida del gioco. La situazione è complicata ulteriormente dai checkpoint, con campi di forza che lasciano passare i cittadini ma non il giocatore, tanto da far presumere a molti tester che ci fosse un modo per aggirarli. Alla fine, proprio grazie ai test, siamo riusciti a definire la giusta visibilità del vicolo, sfruttando l'illuminazione, la conformazione e una cassa di legno, già utilizzata per indicare la direzione corretta, per guidare il giocatore con discrezione."
N/A4047"#commentary\cn_128_strider.mp3" "[Doug Wood] Questo semplice momento promette un incontro futuro con quella creatura colossale. Persino una sequenza così poco complessa richiede numerosi test e modifiche, perché Half-Life si pone l'obiettivo di non privare mai il giocatore del controllo. Come si può immaginare, servono molti piccoli aggiustamenti per essere certi che la maggior parte dei giocatori guardi nella direzione giusta al momento giusto. La configurazione della strada e la scena con il poliziotto servono a guidare lo sguardo del giocatore, perché inquadri alla perfezione l'arrivo dello strider."
N/A4048"#commentary\cn_129_physics_simulation.mp3" "[Jay Stelly] Sebbene all'inizio della lavorazione di Half-Life 2 disponessimo di una simulazione fisica di terze parti funzionante, sono serviti diversi anni di lavoro aggiuntivo, sulla simulazione stessa e sulla sua integrazione nel gioco, prima di sentirci allineati con le ambizioni dei nostri designer. Sapevamo che mantenere un livello di qualità e prestazioni degno di pubblicazione sarebbe stata una sfida, ma il problema più insidioso era decidere cosa simulare, e fino a che punto. Non si può simulare tutto, e anche potendo sussistono ragioni progettuali che rendono l'esperienza migliore in caso contrario. Spesso, abbiamo piegato la simulazione a favore dell'esperienza. Queste modifiche tendono a passare inosservate, perché in linea con le intenzioni del giocatore. Per esempio, abbiamo disattivato le collisioni tra giocatore e oggetti grandi per consentire le rotazioni in spazi angusti. E abbiamo modificato il fuoco alternativo del fucile Combine per guidare gentilmente la sfera verso i nemici, rendendolo più efficace."
N/A4049"#commentary\cn_130_physics_simulation_2.mp3" "[Jeff Lane] Le aree in cui il design di gioco e altri limiti influenzano la simulazione fisica richiedono spesso ulteriori affinamenti per evitare risultati disastrosi. Per esempio, nelle prime fasi avevamo provato a incrementare la simulazione sull'entità giocatore, integrandone maggiormente i movimenti nella simulazione del mondo. Sapevamo che avrebbe potuto renderli meno precisi, ma speravamo di dare vita a esperienze originali. Purtroppo, dopo aver modificato il movimento per allinearlo alla versione meno simulata, siamo incorsi in un problema grave: la forza fisica necessaria per muovere il giocatore alla normale velocità era talmente elevata che correre contro un oggetto simulato poteva condurre alla morte per l'impatto. Dopo varie modifiche, non siamo riusciti a trovare una soluzione accettabile, e siamo tornati al movimento meno simulato. Non era comunque la strada più semplice, perché introduceva nuove sfide relative alle interazioni del giocatore meno simulato con gli oggetti più simulati. Ma ci consentiva di garantire l'esperienza di movimento preciso a cui ambivamo."
N/A4050"#commentary\cn_131_playtesting.mp3" "[John Morello] I test sono parte integrante del nostro processo creativo. È impossibile prevedere le reazioni dei giocatori, tantomeno cosa ricaveranno da ciò che abbiamo realizzato. I test ci aiutano a imparare e, si spera, a migliorare. Durante questa fase, non aiutiamo mai i giocatori, anche se restano bloccati, poiché è molto improbabile che potremo sedere al loro fianco all'uscita del gioco. L'obiettivo è spingere i tester a giocare come se fossero a casa propria, dimenticandosi del test. Qualsiasi interruzione rischia di distorcere i dati, per cui interveniamo solo in caso di bug che impediscono la progressione o, più raramente, se assistiamo a comportamenti talmente confusi da richiedere spiegazioni."
N/A4051"#commentary\cn_132_playtesting_anecdote_1.mp3" "[Matt Boone] Una delle sessioni di test più memorabili ci ha ricordato che non si può mai essere certi di cosa pensi il giocatore, né di quale lezione possa trarre dall'esperienza. Una persona, rimasta bloccata davanti a una porta chiusa, aveva perso diversi minuti a passare dal gioco alle impostazioni della tastiera, e viceversa. Quando abbiamo chiesto cosa stesse facendo, ci ha detto che cercava i comandi dell'inventario, per aprire la porta con un oggetto raccolto in precedenza. Nonostante avesse raccolto e abbandonato diversi oggetti fisici, aveva frainteso l'accaduto. Credeva che premere il tasto Usa mentre reggeva un oggetto avesse inviato l'oggetto all'inventario, poiché era caduto verso il basso. Noi sapevamo che era solo questione di gravità, ma la sua ipotesi non era assurda: alcuni giochi d'avventura dell'epoca facevano scivolare gli oggetti in un inventario invisibile in quel modo. Dopo aver spiegato l'assenza dell'inventario, il test è proseguito. In seguito, ci siamo chiesti se valesse la pena intervenire, ma visto che nessun altro tester aveva mostrato la medesima confusione, e che le soluzioni possibili erano tutte eccessive, abbiamo deciso che si trattasse di un caso limite che non richiedeva modifiche. Ci ha ricordato, tuttavia, che anche i dettagli più sottili o insignificanti possono sviare chi gioca."
N/A4052"#commentary\cn_133_cratebaby.mp3" "[Scott Dalton] Questo bambolotto ha un'eredità duratura. Durante i lunghi mesi di test interni, alcuni membri del team lo avevano trasformato in una sfida, un modo per rendere più divertente la 47ª partita. Infilavano il bambolotto in una cassa blu nei paraggi e provavano a portarlo con sé il più a lungo possibile nel corso del gioco. Dopo il lancio di Half-Life 2, la community ha preso a sua volta a trasportare il \"bimbo nella cassa\", creando nuovi aneddoti e regole personali. Qualche anno più tardi, lavorando su Episode 2, ci è stato di ispirazione per l'obiettivo \"L'omino dello spazio\", in cui i giocatori dovevano trasportare uno gnomo da giardino, ribattezzato \"gnomo Chompski\", per l'intera durata dell'episodio. Chompski è tornato anche in Left 4 Dead 2 con l'obiettivo \"Fronte Liberazione Nani\", in cui bisognava fargli attraversare la campagna Luna park lugubre. Queste interazioni con i giocatori sono uno degli aspetti più gratificanti dello sviluppo. Progettiamo giochi con tante teorie in testa, ma è impossibile prevedere cosa accadrà quando i giocatori ci metteranno mano."
N/A4053"#commentary\cn_134_the_citadel.mp3" "[Eric Kirchmer] Volevamo che City 17 mostrasse sin dalla prima occhiata la Cittadella e il suo dominio sulla città, a rappresentare l'asservimento totale e assoluto dell'umanità ai Combine. Serviva anche a segnalare un obiettivo chiaro: già dalle prime battute, si intuiva la conclusione del viaggio. Nonostante le dimensioni colossali, tuttavia, molti tester la ignoravano. Un monitor PC può ingannare la percezione di profondità e proporzioni del giocatore. Chi ha provato a giocare in VR avrà notato che le dimensioni sembrano più naturali. In questo caso, nemmeno la posizione sopraelevata della Cittadella aiutava, forse perché gli FPS abituano a guardare davanti a sé o in basso. Per incrementare le probabilità che i giocatori notassero la Cittadella, abbiamo aggiunto un volo di uccelli in direzione della struttura, un espediente per guidarne lo sguardo."
N/A4054"#commentary\cn_135_close_captions.mp3" "[Yahn Bernier] Durante lo sviluppo di Half-Life 2, siamo stati contattati da persone interessate all'accessibilità, che ci hanno incoraggiati a migliorare il sistema di sottotitoli di Half-Life 1. Serviva un sistema di sottotitoli codificati che catturasse anche i suoni del gioco, oltre ai dialoghi. Si è rivelata una sfida molto più ostica del previsto. Half-Life 2 produceva un ampio ventaglio di suoni, e categorizzarli per i sottotitoli era cruciale. Anche le priorità erano importanti: i dialoghi dovevano restare in evidenza, esplicitando sempre il parlante. I suoni ambientali, come gli scontri in lontananza, erano importanti per dettare l'atmosfera di alcuni livelli... Molto meno se c'era un nemico aggressivo nelle vicinanze. I designer dei livelli tendevano a riutilizzare gli stessi suoni in contesti diversi, per cui alcune aree richiedevano i sottotitoli e altre no. Alla fine, a ogni suono del gioco sono stati assegnati i dati necessari, formattati come una versione semplificata di HTML, consentendoci di controllare lo stile di ogni sottotitolo. Come nel caso dei file audio, anche i dati dei sottotitoli erano troppo ingombranti per tenerli in memoria, per cui abbiamo ideato un efficace sistema di cache asincrona."
N/A4055"#commentary\cn_136_the_raid.mp3" "[David Sawyer] La sezione che segue, in cui le forze dell'ordine assaltano l'appartamento mentre il giocatore è all'interno, ha richiesto numerosi interventi. In genere, Half-Life è progettato per consentire al giocatore di muoversi al proprio ritmo, poiché ognuno procede in modo diverso. Alcuni corrono, ignorando ciò che non rappresenta una minaccia, mentre altri sperimentano metodicamente. Per cui, quando dobbiamo dettare un ritmo specifico, è sempre una sfida assicurarci che venga percepito e seguito con naturalezza. Questa è la prima situazione del genere, per cui abbiamo dovuto sforzarci di comunicare al giocatore il senso di urgenza, e l'impossibilità di fermarsi a esplorare."
N/A4056"#commentary\cn_137_materials_and_shaders.mp3" "[Gary McTaggart] Half-Life 2 è uscito nel corso di un'evoluzione cruciale della grafica 3D, quando l'industria ha abbandonato le texture in favore di materiali e shader. In Half-Life 1, ogni superficie disponeva di una texture, un'immagine che ricopriva i poligoni. In Half-Life 2, appena cinque anni dopo, ogni superficie disponeva sia di un materiale, sia di uno shader. Lo shader era un blocco di codice che ne personalizzava il rendering. Il materiale ne definiva il comportamento relativo alla fisica e in risposta alle funzionalità di gioco. Conteneva inoltre riferimenti alle texture e ad altri parametri usati dallo shader per il rendering. Di conseguenza, grafici e designer disponevano di maggiore controllo sull'aspetto e sul comportamento degli oggetti. Ma c'era un prezzo da pagare: per Half-Life 1 era sufficiente un computer dotato di processore, mentre Half-Life 2 richiedeva una scheda grafica, poiché i calcoli relativi a materiali e shader erano specificamente progettati per quel tipo di hardware. Le rifrazioni di questa porta a vetri sono un esempio di shader personalizzato, ma ogni superficie della scena usa uno shader di qualche tipo."
N/A4057"#commentary\cn_138_the_raid_2.mp3" "[Miles Estes] Oltre ad assicurarci che il giocatore sentisse l'urgenza di procedere, dovevamo essere certi che il raid fosse a prova di bomba. Il giocatore non doveva avere modo di evitarlo o di tornare indietro scavalcando i poliziotti. Il vero problema non era che i giocatori avrebbero provato a \"rompere\" la scena, ma che potessero scappare in una direzione casuale, in preda al panico, una volta compreso di essere a rischio per la prima volta. Era richiesto un equilibrio delicato: volevamo una fuga frenetica, con un reale senso di pericolo, ma anche che i giocatori la superassero al primo tentativo, mantenendo l'impressione di esserci riusciti per un pelo. A tale scopo, la strada da seguire è sgombra, e ricorda quella seguita sul piano precedente. Una serie di attivatori, posizionati accuratamente, controlla l'apparizione delle minacce di fronte e alle spalle, mantenendo alta la pressione ma lasciando al giocatore il tempo necessario a distanziare gli inseguitori."
N/A4058"#commentary\cn_139_health_and_no_hud.mp3" "[Dave Riller] La scena di inseguimento sui tetti poneva una sfida di design unica. Non volevamo che rappresentasse un vero ostacolo, e preferivamo che i giocatori la superassero al primo tentativo. Ma ci tenevamo anche a trasmettere un senso di pericolo reale, che facesse sentire minacciato chi smetteva di muoversi. Il problema era che, senza la tuta HEV, mancava un'interfaccia a schermo, un HUD, per cui non c'era verso di mostrare i danni e la salute rimasta. Dopo qualche esperimento, abbiamo creato un sistema speciale per questa sezione, usando un bagliore rosso ai bordi dello schermo per segnalare i danni. I giocatori hanno reagito come speravamo, interpretandolo come un invito a restare in movimento, e la fuga si è svolta secondo i piani. Inoltre, abbiamo fatto in modo che la salute si rigenerasse rapidamente, dissolvendo il bagliore, per ribadire ai giocatori che correre era la scelta giusta e assicurarci che non venissero abbattuti da un proiettile vagante alla fine, solo perché avevano esitato in precedenza."
N/A4059"#commentary\cn_140_playtesting_anecdote_2.mp3" "[Jakob Jungels] Nella sezione che segue, era necessario che il giocatore venisse tramortito, perché Alyx potesse salvarlo. Avendo risorse e tempo limitati, abbiamo semplificato l'incontro il più possibile, riutilizzando sistemi esistenti e lasciando che si svolgesse come un normale combattimento, con un evento personalizzato da attivarsi alla \"morte\" del giocatore. Dopo qualche test per rifinire le tempistiche, siamo passati ad altro. Ma in vista della pubblicazione siamo incorsi in un problema con uno dei tester, che abusava dei salvataggi rapidi e ricaricava immediatamente se pensava di aver fallito. Dopo l'attacco del poliziotto, aveva caricato la partita prima che Alyx potesse agire, e ripetuto l'operazione più di dieci volte prima che interrompessimo il test. In quel momento, nella fase finale di risoluzione dei bug, dovevamo limitarci a risolvere solo i casi più gravi, poiché anche una modifica minima rischiava di danneggiare elementi più cruciali. Ritenendolo un caso limite, poiché gli altri tester non avevano evidenziato problemi, abbiamo apportato delle modifiche prudenti. Abbiamo ridotto l'attesa tra il KO e la prima battuta di Alyx, e modificato la dissolvenza dal nero al bianco. Una scelta rivelatasi non molto utile, poiché i giocatori non erano morti abbastanza spesso da associare il nero alla morte. L'idea di disattivare i salvataggi rapidi per i pochi secondi di durata della scena è stata invece scartata, per timore di introdurre un bug che li disattivasse permanentemente."
N/A4060"#commentary\cn_141_character_reactions.mp3" "[Ariel Diaz] Definire cosa dovesse suscitare le reazioni dei personaggi, e come, è stata una sfida continua. Di base, volevamo che il gioco rispondesse agli input del giocatore. D'altra parte, ogni risposta del gioco può essere interpretata come una ricompensa. Ciò a cui i personaggi reagiscono, e ciò che ignorano, insegna al giocatore quale genere di input il gioco si attende. Di conseguenza, ci siamo accertati di rispondere ai comportamenti desiderabili, come le interazioni con i dispositivi del laboratorio, e di ignorare quelli sgraditi, come colpire ripetutamente Kleiner con una scatola. Sul serio, durante i test abbiamo visto qualcuno farlo per cinque minuti di fila."
N/A4061"#commentary\cn_142_choreography.mp3" "[Bill Fletcher] Il sistema che avevamo ideato e sviluppato per la narrativa di Half-Life 2 si chiamava internamente Choreo, abbreviazione di \"coreografia\". In principio, ci è stato utile immaginare di scrivere un'opera teatrale in cui uno degli attori non conosceva il copione. Ci serviva un sistema che controllasse il resto degli attori, muovendoli sul palco, facendoli esibire e recitandone le battute. A questo scopo, gli altri attori dovevano combinare fluidamente le nostre direttive registiche con risposte dinamiche alla posizione e al comportamento del giocatore. Le tempistiche avrebbero rappresentato una sfida, chiaramente, poiché ogni parte di una scena avrebbe dovuto allungarsi, accorciarsi o persino interrompersi in base alle azioni del giocatore."
N/A4062"#commentary\cn_143_phoneme_extraction.mp3" "[Bill Fletcher] Un altro strumento cruciale integrato in FacePoser era l'editor di fonemi. Elaborava le linee di dialogo dei doppiatori, e ne estraeva i fonemi per generare semplici animazioni per il labiale dei personaggi. Per i personaggi principali, i nostri animatori lo hanno usato per creare animazioni personalizzate di alta qualità per ciascuna battuta, incorporando animazioni facciali complete. D'altra parte, in una scena Choreo dinamica, gli animatori non avrebbero potuto prevedere le azioni del resto degli attori. Di conseguenza, è stato necessario coordinare accuratamente i comandi di Choreo alle tempistiche di FacePoser, preservando l'abilità degli attori di rispondere dinamicamente al giocatore."
N/A4063"#commentary\cn_144_delivery.mp3" "[Ken Birdwell] Sono serviti numerosi interventi e test per raggiungere il giusto equilibrio tra informazione e legame emotivo nelle scene Choreo principali. Ciascuna scena conteneva molte informazioni da comunicare, ma non volevamo che i personaggi si limitassero a sputare spiegazioni. I giocatori li avrebbero visti come cartelli informativi, e non come persone. Serviva il tempo necessario per consentire ai personaggi di interagire a vicenda, poiché il giocatore potesse osservare le loro relazioni. Al contempo, dovevamo espandere il mondo di gioco, dando al giocatore la percezione di quanto era accaduto in sua assenza. E doveva funzionare accuratamente, senza richiedere troppo tempo. Volevamo che il gioco accontentasse anche chi era meno interessato alla storia. Le animazioni si sono rivelate uno strumento potente per comunicare i legami emotivi tra i personaggi, trasmettendo il peso di un momento in modo rapido e succinto. Anche l'umorismo si è dimostrato utile, per sovvertire le aspettative o sdrammatizzare quando la situazione si faceva troppo tesa."
N/A4064"#commentary\cn_145_alyxs_kiss.mp3" "[Ken Birdwell] È un momento fugace, ma il bacio di Alyx sulla guancia di Eli era importante. Prima o poi avremmo chiesto ai giocatori di salvare Eli, e volevamo che si affezionassero a lui. Per costruire quel legame emotivo, dovevamo mostrare il calore e l'affetto che legavano Alyx e Eli. Non volevamo esagerare con i dialoghi, né enfatizzare troppo l'evento. Doveva sembrare spontaneo, non affettato, e siamo intervenuti sui dettagli più minuti fino a cogliere il tono ideale."
N/A4065"#commentary\cn_146_storytelling.mp3" "[Bill Van Buren] Creare un senso di coinvolgimento era stato uno dei principi cardine del nostro approccio alla narrazione in Half-Life 1. Per questo, ci eravamo imposti dei limiti precisi: mai, o quasi mai, privare il giocatore del controllo, e rendere il suo avatar muto. In alcuni casi, quei limiti avevano reso l'atto narrativo più impegnativo, ma abbiamo ritenuto importante preservarli in Half-Life 2. Speravamo che, aderendo ai medesimi principi, potessimo spingerci a esplorare forme di narrazione più profonde e interattive."
N/A4066"#commentary\cn_147_archetypes.mp3" "[Bill Van Buren] Con i nostri personaggi, volevamo creare dei legami narrativi tra Half-Life 1 e Half-Life 2. L'intento era progettare individui che sembrassero rappresentare gli archetipi di Half-Life 1, in modo che i giocatori li trovassero familiari, come se li avessero già incontrati nel primo gioco, in circostanze che non ricordano. Per il dottor Kleiner ci siamo basati sul modello di scienziato che ci è sembrato più riconoscibile. La sua personalità è stata plasmata in gran parte da Hal Robins, che con la voce e l'interpretazione aveva definito gli scienziati di Half-Life 1. Un giorno, mentre ancora stavamo elaborando il personaggio, ci è apparso il volto del dottor Kleiner. Eravamo in ascensore con il contabile di un altro ufficio dello stabile, e ci è bastato uno sguardo per capire: \"Lui è il volto del dottor Kleiner\". Per fortuna, quando gli abbiamo chiesto di farsi fotografare per il personaggio di un videogioco, si è mostrato disponibile."
N/A4067"#commentary\cn_148_tone.mp3" "[Bill Van Buren] Era fondamentale trovare il tono corretto per i personaggi e i rispettivi dialoghi. Puntavamo a uno stile di interazione rispettoso verso il giocatore, quasi bonario, senza risultare troppo accondiscendente. Trovare l'equilibrio si è rivelato particolarmente difficile con Alyx, che doveva sostenere il giocatore senza compromettere la forza del proprio personaggio, un aspetto che ritenevamo cruciale perché i giocatori la rispettassero. Il suo rapporto con Eli era uno dei motori principali per motivare i giocatori, per cui era importante che la prendessero in simpatia e desiderassero aiutarla. Inoltre, volevamo creare un contrasto tra l'affetto e il cameratismo degli alleati del giocatore e l'ostilità di Breen e dei Combine, instillando un senso di virtuosa indignazione per le battaglie a venire."
N/A4068"#commentary\cn_149_voice-actors.mp3" "[Bill Van Buren] Per creare personaggi più reattivi e sfaccettati in Half-Life 2, dovevamo evolvere il nostro approccio ai doppiatori. Seguire un copione e un minimo di indicazioni era stato sufficiente per i dialoghi dei personaggi non giocabili di Half-Life 1, ma per Half-Life 2 abbiamo deciso di concedere ai doppiatori una maggiore opportunità di partecipazione nel definire i personaggi e infondergli vita. Abbiamo fornito loro maggiore contesto, mostrando ai doppiatori il mondo di gioco, gli ambienti abitati dai loro personaggi e gli altri personaggi con cui avrebbero interagito. Abbiamo cercato persone che potessero prendere quelle informazioni e sintetizzarle in un'interpretazione che elevasse i personaggi oltre la nostra immaginazione. Abbiamo svolto sessioni multiple con gli attori principali, per consentire loro di assimilare e sviluppare i personaggi nel tempo. Per le scene in cui i personaggi interagiscono tra loro, suggerivamo al doppiatore le battute degli altri colleghi coinvolti, per creare un migliore senso di connessione e fluidità. Anche se entravamo in studio di registrazione con un copione e un piano pronti per la sessione, volevamo che i doppiatori si sentissero autonomi e avessero margine per apportare idee proprie a personaggi e interpretazioni. Anche coinvolgere gli animatori nelle sessioni di doppiaggio si è rivelato cruciale, poiché a loro spettava cucire i dialoghi con i movimenti e le espressioni, per creare la scena Choreo finale. Spesso, gli animatori scoprivano che i loro piani sullo svolgimento di una scena si evolvevano significativamente lavorando con i doppiatori."
N/A4069"#commentary\cn_150_citizens.mp3" "[Bill Van Buren] Quando è giunto il momento di definire i cittadini umani di City 17 e il mondo esterno alla città, abbiamo scelto di includere un ventaglio di etnie, età e generi. Da un lato, stavamo fornendo un contesto narrativo all'asservimento dell'umanità ai Combine. Dall'altro, era importante che chiunque affrontasse il gioco potesse sentirsi rappresentato nella resistenza, e parte della popolazione terrestre coalizzata contro i Combine. Tra le nostre conoscenze personali avevamo trovato diversi candidati da usare come riferimento per i cittadini. Tuttavia, alla fine abbiamo deciso di pubblicare un annuncio sul Seattle Times per raggiungere il ventaglio di volti ideale per l'obiettivo che ci eravamo posti."
N/A4070"#commentary\cn_151_alyx.mp3" "[Dhabih Eng] Perfezionare il design di Alyx è stata una sfida impegnativa: volevamo che il giocatore la rispettasse, ma si affezionasse anche a lei. Salvare Eli era un obiettivo chiave della parte intermedia del gioco, e sapevamo che i giocatori ci avrebbero tenuto maggiormente se avessero tenuto anche ad Alyx e al suo rapporto con il padre. Internamente, abbiamo progettato, scritto dialoghi e scelto una doppiatrice perché Alyx risultasse competente, abile e plausibile in un mondo controllato dai Combine, ma anche attraente e carismatica. Volevamo evitare l'oggettivazione, le esagerazioni e l'eccesso di sensualità che caratterizzavano molti giochi degli anni 2000, perché avrebbero minato i nostri obiettivi per il personaggio."
N/A4071"#commentary\cn_152_lab_interactivity.mp3" "[Dhabih Eng] Nelle scene coreografiche, intrappoliamo il giocatore per un breve periodo, enfatizzando personaggi e storia. Per venire incontro a giocatori diversi, quelli profondamente coinvolti nella narrativa come quelli incapaci di restare fermi per più di un secondo, dovevamo offrire un flusso costante di dettagli interessanti. Abbiamo sparso elementi narrativi in tutto l'ambiente, assicurandoci che alcuni fossero interattivi, veri e propri giocattoli per intrattenere il giocatore. In alcuni casi, vi abbiamo inserito ulteriori elementi narrativi, come il cactus nel modellino di teletrasporto, che presagisce l'imminente disastro. Era un equilibrio delicato, troppi richiami visivi potevano distrarre i giocatori dal fulcro della scena. Alla fine, il laboratorio di Kleiner ha preso la strada meno rischiosa in termini di interattività, trattandosi della prima scena coreografica importante. Successivamente, nel laboratorio di Eli, abbiamo osato di più, assicurandoci che i personaggi prestassero attenzione alle sperimentazioni dei giocatori."
N/A4072"#commentary\cn_153_gestures.mp3" "[Doug Wood] Ciascuno dei nostri personaggi disponeva di una libreria di animazioni essenziali denominate \"gesti\", che potevamo sovrapporre facilmente agli altri movimenti corporei. Progettate nell'ottica del risparmio produttivo, per riutilizzare le stesse animazioni nel corso del gioco, si sono rivelate più utili del previsto. Gli esseri umani tendono a ripetere determinati movimenti, che possono riflettere la loro personalità. Di conseguenza, la nostra libreria di gesti ha finito per catturare l'essenza di ciascun personaggio, aiutando il nostro team di animatori a consolidare la comprensione della loro identità. Ha inoltre agevolato la condivisione del lavoro di animazione su un personaggio tra diversi animatori, come spesso richiesto dalla produzione."
N/A4073"#commentary\cn_154_interactive_storytelling.mp3" "[Erik Johnson] All'inizio della lavorazione di Half-Life 2, la narrativa nei giochi tendeva a essere lineare ma ad alta fedeltà, oppure interattiva ma a bassa fedeltà. C'erano stati giochi narrativamente eccellenti, ma i giocatori non erano mai stati direttamente coinvolti nella storia, né in grado di seguirne lo svolgimento intorno a loro, interagire con essa, ed esaminarne ogni aspetto da vicino. L'obiettivo ci entusiasmava, ma non sapevamo ancora come metterlo in pratica, tantomeno quale genere di tecnologia ci sarebbe servita per riuscirci. Avevamo creato diverse tecnologie narrative in Half-Life 1, ma in genere erano poste di fronte al giocatore e mancavano dell'interattività e della fedeltà a cui miravamo. Pertanto, la sequenza nel laboratorio di Kleiner è diventata un banco di prova per comprendere l'effettivo funzionamento della nostra narrazione interattiva."
N/A4074"#commentary\cn_155_monitors.mp3" "[Ido Magal] In Half-Life 2 e negli episodi usiamo spesso i monitor a fini narrativi, talmente tanto che siamo i primi a riderne. Il problema è che sono maledettamente utili. Sono favolosi per espandere il mondo mostrando eventi in corso altrove, e consentono di intavolare conversazioni con i personaggi senza dover spiegare come siano giunti dal giocatore. Chiunque abbia mai scritto una storia, specialmente con un ampio cast di protagonisti, comprende quanto sia frustrante inventare motivazioni plausibili per riunire tutti i personaggi in un unico luogo. In questo caso, siamo rimasti molto soddisfatti di come il monitor consentisse ad Alyx di trasportarsi altrove e poi apparire rapidamente nel laboratorio di Eli, in modo realistico e fluido."
N/A4075"#commentary\cn_156_scene_interactivity.mp3" "[Jeff Lane] In determinati momenti delle scene coreografiche, è necessario l'intervento del giocatore. Questi momenti hanno scopi precisi, che non si limitano a tenerlo impegnato. Per prima cosa, consentono al giocatore di riprendere le fila se è stato distratto da qualcosa. La scena può andare tranquillamente in \"pausa\" finché il giocatore non completa l'incarico, assicurandosi che torni a prestare attenzione. Allo stesso tempo, ci consente di posizionare il giocatore dove vogliamo, per inquadrare meglio la scena e fare in modo che si accorga di un dettaglio importante. In alcuni casi, questi momenti sono doppiamente preziosi, perché servono ad addestrare il giocatore. Qui sta imparando a interagire con spine e prese, un'abilità che tornerà utile con gli enigmi futuri."
N/A4076"#commentary\cn_157_kleiners_lab.mp3" "[Marc Laidlaw] Il laboratorio di Kleiner è stata la prima sequenza narrativa su cui abbiamo lavorato, e quella che ha richiesto più tempo per il completamento. In aggiunta al suo scopo, proiettare il giocatore nel gioco, ha finito per rappresentare la visione unitaria del team di sviluppo in termini di narrazione. Mentre ci accingevamo a costruire personaggi e narrativa intorno al giocatore, sono emersi molti dubbi, ciascuno dei quali rappresentava un grosso rischio. I giocatori sarebbero riusciti a estrarre le informazioni cruciali dalla scena? Saremmo riusciti a farli affezionare ai personaggi? Come avremmo potuto supportare giocatori diversamente coinvolti nella storia? Quanto sarebbe costato produrre una sequenza del genere? E quante altre ne sarebbero servite? A queste e a molte altre domande non avremmo potuto rispondere prima di allestire una parte consistente della scena e sottoporla a numerosi test. Purtroppo, a differenza di altri casi, non era possibile sciogliere con sicurezza questi dubbi prima di averci lavorato a lungo. Spesso era possibile sottoporre a test alcune idee con prototipi a bassa fedeltà. Ma se un giocatore non è preso dalla storia quando i personaggi sono dei blocchi grigi, come possiamo essere certi che gli importi quando assumeranno la forma definitiva?"
N/A4077"#commentary\cn_158_characters.mp3" "[Marc Laidlaw] In Half-Life 1, guardie di sicurezza e scienziati sono assimilabili ad archetipi, non sono individui. Erano personaggi astratti che rispecchiavano la fedeltà grafica possibile all'epoca. Con il miglioramento delle tecnologie a nostra disposizione per Half-Life 2, abbiamo intravisto l'opportunità di superare le astrazioni. La maggiore fedeltà grafica dei modelli, combinata con le animazioni migliorate, ci ha spinti a concentrarci sulla creazione di personaggi individuali, persone a cui fosse possibile sentirsi legati. Ci siamo concessi di scrivere dialoghi veri, che i personaggi avrebbero recitato in modo sufficientemente realistico da non apparire come pedine in un videogioco, facendo evolvere, così speravamo, la nostra narrativa. Nel 2001, dopo un paio di anni di sviluppo, Ico di Japan Studio ci ha galvanizzati. Diretto da un animatore, ci ha sconvolti per come affidava ai personaggi il ruolo di legame chiave con il giocatore, e ci ha infuso il coraggio per perseverare."
N/A4078"#commentary\cn_159_writing.mp3" "[Marc Laidlaw] All'epoca di Half-Life 1, negli FPS l'obiettivo del giocatore era quasi sempre combattere e sconfiggere un nemico palesemente malvagio. Era difficile spingere i giocatori a preoccuparsi dei personaggi con la qualità grafica di Half-Life 1. Con i previsti miglioramenti alla fedeltà grafica di Half-Life 2, volevamo provare a renderli la forza motrice della storia. L'obiettivo era allineare le motivazioni del giocatore a quelle dei personaggi, perché si preoccupasse di loro, delle loro speranze e delle loro paure, e si augurasse il loro successo. Seguendo questa idea, siamo riusciti a elaborare il nostro approccio a personaggi e dialoghi. Avremmo creato un gruppo di personaggi legati da simpatia e affetto reciproci, nella speranza che il giocatore provasse gli stessi sentimenti. Questi personaggi avrebbero interagito in modo apparentemente inclusivo, come un gruppo di vecchi amici che considera il giocatore uno di loro, che non vedevano da tempo. Se avessero mostrato legami emotivi realistici, ritenevamo, sarebbe stato possibile creare un tale legame anche con il giocatore."
N/A4079"#commentary\cn_160_animation.mp3" "[Miles Estes] Generare movimenti umani credibili per i nostri personaggi, a partire dai molti livelli discreti di animazione, ha richiesto numerosi interventi tecnologici. Persino azioni semplici come voltarsi per guardare qualcosa o muoversi verso un punto diventavano più complesse se combinate alla necessità di rispondere dinamicamente al giocatore e ai requisiti dei comandi di Choreo. Per esempio, l'azione di voltarsi verso qualcosa andava completamente scomposta, per consentire al personaggio di usare ogni combinazione di occhi, testa, spalle, busto o figura intera per rivolgersi a un bersaglio. In Half-Life 1, i corpi dei personaggi umani erano divisi in busto e metà inferiore, per consentirgli di camminare in una direzione e guardare in un'altra. Questo approccio, tuttavia, era troppo astratto per i personaggi di Half-Life 2. I nostri animatori hanno quindi creato animazioni di movimento in tutte le otto direzioni cardinali, che si potevano fondere fluidamente durante l'esecuzione."
N/A4080"#commentary\cn_161_faceposer.mp3" "[Yahn Bernier] Lo strumento primario sviluppato per potenziare il sistema Choreo si chiamava FacePoser, un nome impreciso per un programma che consentiva ai nostri animatori di posizionare l'intera struttura delle scene su una linea temporale. Quest'ultima conteneva una serie di comandi Choreo per gli attori, oltre alle informazioni necessarie alla loro esecuzione. Sovrapponendo questi comandi alla linea temporale, gli animatori potevano descrivere facilmente il modo in cui un attore doveva voltarsi verso un oggetto mentre parlava con qualcuno e si muoveva verso un altro obiettivo... simultaneamente. Ma la linea temporale non era una sequenza fissa e lineare. Gli attori obbedivano ai comandi, ma dovevano anche reagire dinamicamente al mondo circostante. Un attore poteva impiegare più del previsto a raggiungere un punto se intralciato dal giocatore, o poteva rimandare una battuta perché un altro attore era rallentato dal giocatore. FacePoser ci consentiva di creare rapidamente versioni diverse delle scene, provando disposizioni, dialoghi e tempistiche differenti. La capacità di sperimentare e apportare rapide modifiche si è dimostrata cruciale per ottenere le prestazioni corrette e rispettare i nostri obiettivi per personaggi e storia."
N/A4081"#commentary\cn_162_choreo_commands.mp3" "[Yahn Bernier] La visualizzazione di debug mostra i due comandi Choreo più comuni ricevuti dagli attori durante una scena, internamente noti come \"guarda-qui\" e \"vai-qui\". Gli attori ricevono dei bersagli da guardare, a volte più di uno alla volta, e provano a concentrarsi su quello che appare più sensato in base alle circostanze. Allo stesso tempo, possono ricevere comandi di movimento, che gli impongono di raggiungere un punto preciso e voltarsi verso una determinata direzione o oggetto. Anche questi comandi apparentemente semplici implicano una notevole complessità. Una scena può richiedere che un attore parli mentre batte sulla tastiera e osserva un oggetto in mano al giocatore. Poiché non potevamo prevedere la posizione del giocatore durante l'esecuzione, per creare scene simili abbiamo dovuto suddividere ciascun elemento in parti e livelli separati, da assemblare secondo i casi durante l'esecuzione, in base alle azioni del giocatore, e da interrompere se necessario."
N/A4082"#commentary\cn_163_antlions.mp3" "[Kerry Davis] Con il protagonista impegnato a guidare la dune buggy lungo la costa, ci serviva un nemico pervasivo che potesse apparire ovunque e rappresentare una minaccia costante per impedire al giocatore di allontanarsi dalla dune buggy. Le formicheleone che emergono dalla sabbia erano la soluzione perfetta. Grazie all'elevata mobilità, potevano tenere il passo del veicolo per brevi scatti, a differenza dei nemici umanoidi. In più, investirle era molto soddisfacente."
N/A4083"#commentary\cn_164_thumpers.mp3" "[Adrian Finol] Dove possibile, è molto importante che i giocatori sentano di essere giunti a una scoperta da soli. Fa percepire il mondo come vivo, e non una semplice sequenza lineare di elementi di gioco. Accettando il rischio che un determinato elemento possa sfuggire del tutto a una percentuale di giocatori, possiamo adottare un approccio più raffinato. L'abbiamo fatto nella sezione dei martellatori, progettando situazioni che i giocatori avrebbero probabilmente incontrato, ma senza obbligarli a interagire con esse. Erano presenti numerosi indizi visivi e sonori, così come le reazioni delle formicheleone, per aiutare i giocatori a interpretare la scena. Non garantivano che tutti ci sarebbero arrivati, ma molti l'avrebbero fatto, come dimostrato dai test."
N/A4084"#commentary\cn_165_d2_coast_09.mp3" "[Aaron Seeler] Nelle ultime fasi di sviluppo della sezione sulla costa, il codice di gioco era talmente avanti rispetto alla progettazione dei livelli che i nostri programmatori chiedevano di poter scrivere nuovo codice e di poter completare nuovi task per contribuire ai progressi di Half-Life 2. Il motivo principale va ricercato nelle esigenze dei livelli costieri, che per portata complessiva e uso esteso del terreno mettevano sotto pressione i nostri designer. Di conseguenza, i programmatori hanno preso a sviluppare una serie di incontri in scala ridotta. In seguito, quando la progettazione dei livelli ha recuperato il distacco, un livello è stato creato incollando tre incontri separati realizzati dai programmatori, e applicando le rifiniture necessarie in vista della pubblicazione."
N/A4085"#commentary\cn_166_final_scene.mp3" "[Bill Van Buren] Imprigionare il giocatore in una capsula per lo scontro finale nell'ufficio di Breen è stato un compromesso, ma ci ha permesso di concentrarci sui personaggi come non sarebbe stato possibile altrove. Tutti gli archi narrativi raggiungono l'epilogo in questa scena, e limitare il punto di vista del giocatore amplifica l'impatto emotivo. Un climax rafforzato dalla combinazione di dialoghi, doppiaggio e animazioni. Dal punto di vista produttivo, realizzare questa scena è stato impegnativo: impostare correttamente pause e movimenti, ottenere tempistiche e sinergie emotive efficaci e collegare tutte le singole animazioni a prestazioni vocali registrate separatamente... Sono servite molte rifiniture prima di raggiungere una sinergia emotiva per cui i personaggi sembrassero davvero comunicare tra loro."
N/A4086"#commentary\cn_167_end_game_scramble.mp3" "[Dave Riller] In origine, per la fine del gioco era prevista una scena coreografica più imponente. Purtroppo, il team responsabile era impegnato con la mole restante di lavoro narrativo. Per alleggerire il loro carico, al gruppo responsabile delle sezioni di gioco della Cittadella è stato chiesto di creare una sfida che conducesse all'epilogo. Poteva trattarsi di un enigma, di un combattimento, di qualsiasi cosa. Il risultato, lo scontro con il boss Breen, ha combinato le meccaniche preesistenti della pistola gravitazionale potenziata con una piccola coreografia personalizzata, creando un prodotto finito in un breve lasso di tempo."
N/A4087"#commentary\cn_168_combine_portal_effects.mp3" "[Gary McTaggart] Per il nostro approccio allo sviluppo è cruciale che i membri di ciascun team possano contribuire a qualsiasi aspetto del gioco. Una volta concretizzata la sequenza di battaglia finale, i grafici e i programmatori degli effetti visivi sono intervenuti per migliorare la presentazione del portale che conduce al mondo dei Combine e dell'effetto di paralisi temporale all'epilogo del gioco. Per l'effetto del portale è stato usato uno shader di rifrazione, simile a quello impiegato per l'acqua."
N/A4088"#commentary\cn_169_citadel_entrance.mp3" "[Jeff Lane] Abbiamo progettato il percorso che conduce alla Cittadella al contrario: la geometria interna era stata creata come prototipo grafico per perfezionarne l'aspetto. Sapendo che il giocatore sarebbe emerso dalle tubature fognarie della mappa \"Streetwar\", abbiamo dovuto creare una sezione di raccordo con dislivelli e salti fino all'ingresso della Cittadella."
N/A4089"#commentary\cn_170_citadel_steep_landing.mp3" "[Randy Lundeen] La Cittadella è stata realizzata a sviluppo molto inoltrato, e inizialmente non avevamo le idee chiare sulla parte giocata. Non è insolito: sebbene siano spesso le meccaniche di gioco a guidare il nostro approccio, le scelte creative preliminari, come l'esistenza della Cittadella Combine, richiedono un'opera di progettazione specifica per integrarsi nel prodotto finale. Dopo la battaglia campale del capitolo precedente, ritenevamo che l'epilogo nella Cittadella meritasse un tono diverso. Pur volendo alzare la posta, creare nuove meccaniche e personaggi in questa fase sarebbe stato troppo rischioso. Il piano originale prevedeva di realizzare uno spettacolo narrativo passivo: un treno che attraversa il cuore della macchina da guerra dei Combine, fino all'ufficio di Breen. Dopo averlo sviluppato, abbiamo passato qualche giorno a sperimentare le meccaniche della pistola gravitazionale potenziata, pensando che a fine gioco potessimo accontentare i giocatori, rendendoli onnipotenti senza compromettere l'equilibrio complessivo. I risultati si sono rivelati promettenti, e sono stati incorporati nel gioco con le opportune modifiche. Invece di una classica sfida finale, volevamo che i giocatori si sentissero delle divinità, afferrando i nemici a piacimento, strappando le console dalle pareti. Alla fine, la Cittadella fonde entrambi i concetti, passando dallo spettacolo al potere sfrenato."
N/A4090"#commentary\cn_172_lightmap_pass.mp3" "[Mike Dussault] Gli interni della Cittadella prevedono geometrie relativamente semplici, ma il metallo Combine e l'illuminazione marcata aiutano a comunicare l'immensità della struttura. La risoluzione delle lightmap era maggiore sulle superfici di particolare interesse e minore su quelle distanti o totalmente in ombra. Inoltre, vista la dimensione degli spazi della Cittadella, le grandi superfici dotate di lightmap incidevano notevolmente sulle prestazioni. Verso la fine dello sviluppo, abbiamo rivisto per intero i livelli della Cittadella, ottimizzando questi valori in base all'interesse visivo e alle prestazioni. Ci ha aiutato l'aggiunta di una nuova funzione all'editor di livelli Hammer, che visualizzava le superfici con la rispettiva densità in luxel."
N/A4091"#commentary\cn_173_super_gravity_origins.mp3" "[Brian Jacobson] In questa fase dello sviluppo, eravamo convinti del design della pistola gravitazionale. Volevamo comunicare ai giocatori un senso di onnipotenza, per cui ci siamo messi al lavoro per crearne una versione potenziata. Non c'è voluto molto, un giorno di prototipi al massimo, prima di ottenere un risultato apprezzabile che divenisse il nucleo delle sezioni di gioco nella Cittadella. Con il motore fisico ormai ultimato, eravamo liberi di sperimentare modi nuovi ed emozionanti per forzarne i limiti e godere dei risultati divertenti che ne sarebbero scaturiti. Il nostro oggetto prototipo, un'anguria che pesava centinaia di chili nella simulazione fisica, si è tramutata nelle sfere Combine presenti nel gioco."
N/A4092"#commentary\cn_174_combine_energy.mp3" "[Brian Jacobson] Quello che in forma di prototipo era un'anguria si è trasformato in una sfera energetica quando il suono e l'esplosione prodotti all'impatto hanno smesso di ricordare la frutta, avvicinandosi al risultato finale. Mentre mettevamo a punto i livelli che non si basavano sull'anguria, ci siamo resi conto che la sfera energetica non si prestava solo all'uccisione dei soldati, ma poteva integrarsi negli enigmi per attivare e spegnere equipaggiamenti diversi. In una fase di sviluppo molto successiva, non eravamo soddisfatti del fuoco secondario dell'AR2, e visto l'apprezzamento per la sfera Combine, l'abbiamo incorporata nell'arma. A ripensarci, ci stupisce sempre come elementi indipendenti del gioco possano combinarsi in seguito per risolvere un problema."
N/A4093"#commentary\cn_175_combine_wall_and_balls_training.mp3" "[Ido Magal] Durante i test, ai giocatori sembrava sfuggire che le sfere Combine dissolvessero i soldati, quindi non capivano perché scomparissero. Come prima soluzione, abbiamo provato a spingere i rimbalzi delle sfere in direzione dei nemici, per accrescere le probabilità che venissero dissolti. Infine, abbiamo capito che i giocatori non si accorgevano dell'effetto perché si verificava durante combattimenti intensi, e le capacità di apprendimento delle persone risultano molto limitate sotto pressione. Come ultima spiaggia, abbiamo inserito una stanza di addestramento a bassa pressione con un campo di forze che poteva essere aperto solo afferrando la sfera Combine. Lo scenario è stato aggiunto proprio per insegnare l'uso delle sfere Combine per disattivare i campi di forza, e il modo di indirizzarle contro i soldati per dissolverli. Eppure, i risultati dei test non sono stati trionfali. Nonostante i nostri sforzi, alcuni giocatori faticavano ancora a percepire l'effetto di dissolvenza dei proiettili. Poiché il tempo stringeva, e molti affermavano comunque di sentirsi potenti, abbiamo accettato l'idea che a qualcuno potesse sfuggirne il motivo."
N/A4094"#commentary\cn_176_weapon_strip.mp3" "[Josh Weier] Una volta introdotta la pistola gravitazionale potenziata, non volevamo che i giocatori tornassero alle armi convenzionali. Per cui abbiamo fatto l'unica cosa sensata: le abbiamo disintegrate. La presenza di un nemico misterioso e sovrannaturale come i Combine aiuta molto, perché è plausibile che dispongano di un disintegratore. Perché no? E se, per qualsiasi motivo, fosse stato necessario ripristinare le vecchie armi nel mezzo di un livello... Tu guarda, hanno anche un reintregratore!"
N/A4095"#commentary\cn_177_breen_monologue.mp3" "[Marc Laidlaw] Il lavoro creativo non avviene nel vuoto, e ognuno di noi trae ispirazione da qualcosa. Il monologo di Breen che appare negli schermi della Cittadella prende spunto parzialmente da un gioco che tutti amavamo: Thief 2, in cui l'antagonista provoca il giocatore durante le sue incursioni. L'esecuzione è molto diversa, ma il nucleo ispiratore rimane. Il contributo maggiore all'efficacia della scena, comunque, viene dall'interpretazione del compianto Robert Culp. La sua dizione è perfetta. Recita ciascuna battuta di Breen con una sottigliezza e un'eleganza che trasformano il personaggio sulla carta in qualcosa di speciale. Le sessioni di doppiaggio con Robert Culp erano una passeggiata: lui veniva con il copione, l'ingegnere avviava la registrazione e finiva lì. La morale della favola è che bisogna lavorare con persone il cui talento superi il proprio, da cui si è certi di imparare qualcosa. Senza fissarsi su come una battuta vada recitata o come una scena debba svolgersi, ma piuttosto collaborando con persone di talento, consapevoli che sapranno migliorare il risultato."
N/A4096"#commentary\cn_178_dissolved_weapons.mp3" "[Quintin Doroquez] Tutte le armi dei Combine erano impostate per dissolversi quando un Combine veniva ridotto a marionetta dalla pistola gravitazionale, per due motivi. Innanzitutto, per impedire ai giocatori di raccoglierle e usarle, poi per migliorare le prestazioni in quelle mappe. Inoltre, abbiamo aggiunto un gestore di marionette che rimuoveva i soldati caduti non appena il giocatore procedeva oltre."
N/A4097"#commentary\cn_179_elevator_fight.mp3" "[Brian Jacobson] Pur volendo trasmettere al giocatore una sensazione di onnipotenza, non potevamo resistere alla tentazione di implementare uno scontro difficile presso la tromba dell'ascensore. La battaglia in attesa dell'arrivo dell'ascensore si è rivelata più impegnativa rispetto ai piani originari per questa sezione di gioco. È diventata più facile durante i test, ma non avevamo tempo a sufficienza per bilanciarla al punto giusto. Sebbene il giocatore non corra mai rischi eccessivi, è il numero di soldati presenti che la fa sembrare una battaglia campale più di quanto non sia."
N/A4098"#commentary\cn_180_replacing_the_prefabs.mp3" "[Brian Jacobson] Questa struttura con le sfere energetiche Combine è relativamente semplice: un campo di forza che argina degli oggetti che rimbalzano di continuo. Durante i test, tuttavia, eravamo incorsi in numerosi bug per cui le sfere rimbalzavano in giro, fino a liberarsi e \"fuggire\" dal campo di forza che avrebbe dovuto contenerle. Considerati i limiti delle tecnologie di prefab di cui disponevamo all'epoca, è stato necessario ricostruirle a mano numerose volte, in ciascuna delle posizioni previste, e in tutti i livelli della Cittadella che le includevano."
N/A4099"#commentary\cn_181_strider_fight.mp3" "[Ted Backman] Uno dei prototipi originari della Cittadella prevedeva la possibilità di afferrare lo strider con la pistola gravitazionale potenziata, e per molto tempo lo scontro ha richiesto di avvicinarsi a sufficienza per afferrarlo. A sviluppo quasi concluso, abbiamo deciso che afferrare uno strider lo facesse apparire troppo debole, soprattutto dopo il precedente scontro in strada. Pertanto, abbiamo modificato l'incontro perché venisse eliminato con le sfere Combine. Parti di modello sono state aggiunte allo strider perché potesse subire smembramenti ed esplodere, invece di agitarsi scompostamente. È l'unica istanza nel gioco in cui a uno strider è applicato questo effetto."
N/A4100"#commentary\cn_182_getting_in_the_pod.mp3" "[Dhabih Eng] La sequenza di ascesa nella capsula che ha inizio qui richiedeva un controllo totale della scena e della visuale del giocatore. Contraddiceva la nostra volontà di lasciare al giocatore il massimo controllo possibile, ma per quest'ultimo passo ci è sembrato un compromesso accettabile. Ormai, il giocatore è talmente potente da essere quasi incontrollabile, per cui dovevamo immobilizzarlo. Il resto dei personaggi è comunque presente per parlargli, tenendolo al centro dell'attenzione. Siamo riusciti anche a conferire una valenza narrativa agli ambienti lungo il percorso. Il viaggio attraverso la Cittadella che inizia qui contiene diversi avversari di cui avevamo pronta la grafica, ma che erano stati rimossi dai contenuti principali. Dalla sicurezza dell'accogliente capsula, si può osservare il processo di creazione degli stalker e vedere di sfuggita il synth granchio."
N/A4101"#commentary\cn_183_turrets.mp3" "[Mike Dussault] Le torrette erano uno strumento progettuale utile laddove il giocatore disponesse di un'esca, poiché impedivano un assalto diretto delle formicheleone. Questo ci consentiva di ideare scenari in cui limitarsi a lanciare l'esca per procedere non fosse sufficiente, ma bisognasse fare il giro e liberarsi delle torrette prima di far muovere le formicheleone. Inoltre, assistere alla mattanza di insetti da parte delle torrette era uno spettacolo notevole."
N/A4102"#commentary\cn_184_grenade_puzzle.mp3" "[Aaron Seeler] Durante i test, i giocatori restavano spesso bloccati su questo semplice enigma, perché la cassa di granate infinite era posizionata troppo indietro rispetto al percorso. A questo punto del gioco, i giocatori hanno imparato ad associare le casse di munizioni infinite alla risoluzione degli enigmi, per cui trovando qui una cassa di granate avrebbero capito subito di doverne usare una. Noi volevamo che ci riflettessero sopra un minimo. Infine, abbiamo introdotto un indizio, mostrando le granate sul tavolo attraverso una finestra, per ricordarne la disponibilità ai giocatori. Ci è servito anche a scoprire un bug durante un test: se un giocatore si avvicinava troppo per guardare, poteva raccogliere le granate attraverso il vetro."
N/A4103"#commentary\cn_185_allied_turrets_balancing.mp3" "[Adrian Finol] Bilanciare questo scontro in virtù delle torrette alleate è stato complicato. Sono un elemento inedito, e se il giocatore le ignora la sequenza appare ridondante, perché molto simile a situazioni già vissute. Volevamo rendere necessario l'uso delle torrette e premiarne il posizionamento strategico, ma si verificavano due estremi: un posizionamento perfetto rendeva lo scontro banale, un posizionamento errato lo rendeva troppo difficile. Rifinire e personalizzare la logica della IA dei soldati ci è stato d'aiuto: sono diventati più abili a rovesciare le torrette con le granate o ad aggirarle per abbatterle. Queste modifiche hanno spostato l'enfasi dal posizionamento delle torrette al loro mantenimento, poiché qualsiasi formazione sarebbe crollata, prima o poi. I test fornirono responsi diversi: alcuni si erano trovati in grande difficoltà, altri lo consideravano il proprio scontro preferito. A corto di tempo, abbiamo deciso di facilitarlo un minimo e chiudere la pratica, sebbene insoddisfatti del bilanciamento finale."
N/A4104"#commentary\cn_186_meeting_mossman.mp3" "[Ariel Diaz] Far ricongiungere il giocatore e Alyx con Mossman dopo la scena del tradimento non è stato semplice, poiché molti giocatori erano pronti a spararle a vista. Non potevamo permetterlo, considerato che non c'era tempo per sviluppare variazioni della trama. Al contempo, non volevamo evidenziare questa carenza di discrezionalità, per cui abbiamo cercato di ridurre le probabilità che i giocatori ci provassero. Il vetro antiproiettile concede tempo al dialogo tra Alyx e Mossman, durante il quale si rende evidente che Alyx non abbia intenzione di ucciderla."
N/A4105"#commentary\cn_187_eli_in_pod_choreography.mp3" "[Ken Birdwell] Abbiamo scritto e registrato i dialoghi di questa scena prima ancora di completare Nova Prospekt. A quel punto, sapevamo che Alyx e Gordon si sarebbero teletrasportati fuori dalla prigione, ma i dettagli andavano ancora definiti, per cui i dialoghi dovevano essere abbastanza aperti da adattarsi al risultato finale. Pertanto, ci siamo concentrati sulla vulnerabilità di Alyx e sul suo rapporto con il padre, piuttosto che sulle azioni del giocatore. Speravamo che le emozioni potessero sostenere la scena più della narrazione stessa. In fondo, volevamo che il giocatore si affezionasse a questi personaggi, perché desse priorità a ciò che importava ad Alyx."
N/A4106"#commentary\cn_188_mossman_and_eli.mp3" "[Bill Van Buren] Questa scena coreografica ha richiesto interventi ripetuti. Volevamo comunicare una svolta improvvisa durante la scena, senza limitare il controllo del giocatore. Era necessario un equilibrio delicato per chiarire il colpo di scena, impedendo al contempo qualsiasi interruzione. Se i giocatori avessero seguito Alyx alla console, dovevano comprendere cosa stava accadendo quando si fossero voltati. Se fossero rimasti indietro a osservare Mossman, dovevano intuire cosa stava accadendo senza convincersi di doverlo impedire. Sono serviti molti aggiustamenti e test per ottenere il tempismo corretto, ma ci siamo riusciti con una combinazione di distrazione ed esecuzione rapida del momento cruciale, chiudendo con una spiegazione a seguito dell'evento."
N/A4107"#commentary\cn_189_nova_prospekt_entry.mp3" "[Danika Rogers] Il giocatore ha appena superato due livelli densi di combattimenti, per cui volevamo allentare la tensione, una volta all'interno. Questi livelli iniziali sono stati pensati come cambio di ritmo, per consentire al giocatore di esplorare la struttura interna di Nova Prospekt. Lungo il percorso, abbiamo cominciato a inserire le meccaniche legate alle torrette, prima come nemici e successivamente come strumenti a disposizione. Buona parte del livello è stata realizzata riutilizzando prototipi ed elementi grafici creati in precedenza, quando eravamo impegnati a definire l'aspetto di Nova Prospekt."
N/A4108"#commentary\cn_190_turret_training_exit.mp3" "[Doug Wood] Questo mucchio di rifiuti, insieme alla discesa per la scala ingombra, doveva fungere da deterrente per impedire ai giocatori di portare con sé una torretta. Non avrebbero rotto nulla riuscendoci, ma volevamo ridurre le probabilità che accadesse. Rendere scomodo il trasporto della torretta non è una scelta concettuale ideale, ma è meglio di niente. Molti tester hanno finito per arrendersi, gettando via la torretta quando hanno intuito che il gioco stesse cercando di comunicare un messaggio."
N/A4109"#commentary\cn_191_allied_antlions.mp3" "[Eric Kirchmer] La presenza di un esercito inesauribile di formicheleone lanciato all'assalto di torrette e soldati ci ha obbligati a riflettere sul ruolo del giocatore nei combattimenti di Nova Prospekt. Il giocatore aveva già affrontato molti soldati Combine, per cui abbiamo deciso di rendere gli scontri di questa sezione più simili a un enigma o a uno spettacolo, che a una sfida di combattimento. A partire da questo concetto, abbiamo creato situazioni che restassero stabili fino all'intervento del giocatore. Eliminando i nemici, era possibile volgere lo scontro a favore delle formicheleone, ma volevamo premiare l'uso dell'esca. In molti casi, se il giocatore lanciava l'esca contro i nemici, si attivavano dei generatori di formicheleone aggiuntivi, scatenando un'ondata di insetti in battaglia. Il massacro risultante era il premio che rendeva l'esca soddisfacente."
N/A4110"#commentary\cn_192_laser_mines.mp3" "[Erik Johnson] Ci siamo molto divertiti a reintrodurre queste mine laser a Nova Prospekt. Erano un'arma di Half-Life 1 che non eravamo riusciti a inserire in Half-Life 2, ma che qui trovava una collocazione come parte di un enigma. Apprezzavamo che rappresentassero una sorta di dilemma etico, quando il giocatore aveva un esercito di formicheleone al proprio seguito. Alcuni lanciavano subito l'esca verso le mine, usando gli insetti come carne da macello. Altri facevano arretrare le loro amichette finché non riuscivano a rimuovere le mine con altri mezzi. Noi non giudicavamo."
N/A4111"#commentary\cn_193_final_turret_arena.mp3" "[Erik Johnson] Quando elaboriamo una sequenza legata a un elemento di gioco, come le torrette alleate, partiamo in genere da un prototipo della parte finale, che rifiniamo finché i test non ne confermano il funzionamento. Poi, procediamo a ritroso, aggiungendo gli scenari precedenti per introdurre l'elemento e addestrare il giocatore. Questo approccio ci assicura che la sequenza finale sia coinvolgente prima di investirvi tempo eccessivo. Inoltre, al momento di creare gli scenari di addestramento, sappiamo già dai test quali abilità richiedano una guida e quali giocatori riusciranno a cavarsela da soli. L'obiettivo era questa sequenza finale con le torrette: enfatizzare la difesa contro nemici provenienti da direzioni diverse, richiedendo di posizionare e recuperare dinamicamente le torrette."
N/A4112"#commentary\cn_194_one_way_drops.mp3" "[Jakob Jungels] I giocatori non sanno mai cosa li aspetta, ma ricordano le esperienze pregresse, e tendono a tornare in territorio conosciuto quando incontrano un nemico. Se abbiamo costruito un'arena e vogliamo che il giocatore la affronti, soprattutto nel caso di nemici con requisiti geometrici specifici, come le guardie formicaleone, dobbiamo impedire questa ritirata. Una soluzione classica è obbligare il giocatore ad accedere all'arena con una caduta a senso unico, come si sarà già notato in un paio di occasioni."
N/A4113"#commentary\cn_195_npcs_on_elevators.mp3" "[Jay Stelly] Investiamo molto del nostro tempo a risolvere problemi che i giocatori nemmeno noteranno. Spesso rappresentano raffinate sfide di progettazione, altre volte nascono dall'interazione tra sistemi multipli. Per esempio, far salire i personaggi non giocabili sugli ascensori si è rivelato un problema complesso, perché coinvolgeva un ventaglio di sistemi: le decisioni della IA dei PNG, la pianificazione degli spostamenti e la simulazione dei movimenti, per citarne alcuni. Inoltre, lo stesso ascensore presentava requisiti di simulazione propri, indipendenti dai PNG. Una delle sfide più complicate è scaturita dal fatto che simulavamo i PNG a una frequenza inferiore rispetto agli ascensori. In pratica, su un ascensore in discesa venivano prima simulati i PNG, per essere certi che si posizionassero correttamente al suo interno, poi veniva simulato l'ascensore un certo numero di volte, ciascuna delle quali serviva a farlo discendere nel suo condotto, lasciando appena indietro il PNG. Poco dopo, la simulazione veniva applicata al PNG per la seconda volta, riposizionandolo sul pavimento dell'ascensore. Prevedibilmente, non era facile prendere sul serio Alyx, vedendola cadere a piccoli scatti mentre ti parla."
N/A4114"#commentary\cn_196_looktargets.mp3" "[John Cook] Uno degli strumenti chiave a nostra disposizione è il Looktarget, un punto invisibile nello spazio che si attiva quando il giocatore lo inquadra. I designer possono specificare la precisione con cui va guardato, la durata dello sguardo e altre condizioni. Una volta attivato, il Looktarget innesca diversi elementi nel gioco. Per esempio, Alyx può attendere che il giocatore la guardi prima di recitare la battuta di un dialogo, una scena può mostrarsi solo se osservata, o una dropship Combine può sorvolare il cielo se il giocatore è rivolto in quella direzione. Dopo aver implementato i Looktarget, i designer hanno trovato infinite applicazioni per rendere il gioco più affidabile nei confronti dei giocatori, soprattutto perché alcuni si muovono a velocità molto diverse o in modo imprevedibile."
N/A4115"#commentary\cn_197_nova_prospekt_yard.mp3" "[John Morello] Lo scontro nel cortile di Nova Prospekt si basava sulla precedente osservazione degli scontri tra formicheleone e soldati Combine. L'elevata mobilità e gli attacchi in mischia delle formicheleone si abbinavano bene ai soldati, letali dalla distanza e vulnerabili nel corpo a corpo. Le formicheleone si mettevano in mostra sotto il fuoco, in un trionfo di effetti particellari, e quando raggiungevano un soldato, l'effetto marionetta era incredibilmente soddisfacente."
N/A4116"#commentary\cn_198_vent.mp3" "[John Morello] Non sarà una novità, ma dove c'è un condotto di ventilazione, deve esserci un succhiateste. Non le abbiamo stabilite noi queste regole, vengono dai piani alti, come i condotti."
N/A4117"#commentary\cn_199_kitchen.mp3" "[Kerry Davis] Tra gli sviluppatori di videogiochi vige una storica consuetudine: in ogni cucina di un videogioco deve avvenire un'esplosione di gas."
N/A4118"#commentary\cn_200_alyxs_tool.mp3" "[Laura Dubuk] Il multiutensile è stato incredibilmente utile per sfruttare Alyx come una sorta di chiave. Spesso, dovevamo impedire al giocatore di procedere prima che fossimo pronti, e il multiutensile le consentiva di dialogare mentre apriva la strada. Forse vi abbiamo fatto troppo affidamento, ma era difficile resistere. C'è sempre un compromesso: usare Alyx per gestire l'accesso a una stanza, invece di creare una soluzione specifica, ci concedeva il tempo per lavorare su altre parti del gioco, spesso più cruciali."
N/A4119"#commentary\cn_201_mossmans_betrayal.mp3" "[Marc Laidlaw] Il piano originario per l'arco narrativo di Judith Mossman prevedeva che tradisse il giocatore in questo momento. Ma una volta raggiunta la scena, e sviluppate altre sezioni del gioco, ci è parso più plausibile che volesse proteggere Eli. Avrebbe cambiato idea, rinunciando a tradire Gordon. Avevamo un piano per chiarire questo cambiamento in seguito, ma non siamo riusciti a ultimare il suo arco narrativo. Noi apprezzavamo l'ambiguità di Mossman, ma i giocatori meno: la detestavano quasi all'unanimità. È stato comunque un successo. Avevamo lavorato molto per alimentare l'affinità tra il giocatore e Alyx, e quest'ultima non era certo un'ammiratrice di Judith."
N/A4120"#commentary\cn_202_d2_prison_05_start.mp3" "[Yahn Bernier] La capacità del giocatore di spostare grandi quantità di oggetti ci ha causato diversi grattacapi, soprattutto a causa delle limitazioni delle CPU del 2003. Una di queste impediva al sistema di orientamento della nostra IA di riconoscere ed evitare gli oggetti fisici durante il movimento. In pratica, risultavano invisibili durante le richieste di orientamento necessarie a pianificare strategicamente gli spostamenti. Era dovuto in buona parte a limiti di prestazioni. Non potevamo permetterci nulla di più complesso. Abbiamo affrontato anche problemi progettuali senza soluzioni evidenti, come decidere la reazione di un soldato se un giocatore ostruiva un corridoio con oggetti fisici ingombranti. In risposta, abbiamo dotato i personaggi non giocabili di forza aggiuntiva perché spingessero via gli ostacoli. Successivamente, abbiamo mitigato il problema intervenendo sulla struttura dei livelli, ampliando i corridoi e assicurandoci che ci fosse spazio a sufficienza per accogliere gli oggetti di scena. Questo è uno scenario ad alto rischio: la combinazione di soldati nascosti dietro ai letti e formicheleone in avvicinamento per attaccare in mischia è foriera di interazioni complicate tra il sistema di movimento dei PNG e i letti."
N/A4121"#commentary\cn_203_alyx_as_companion.mp3" "[Miles Estes] Questa sezione è diventata un prototipo involontario di ciò che sarebbe accaduto in Episode 1: Alyx come compagna, e spostamenti fluidi lungo un percorso che alterna scontri dinamici a coreografie scriptate. Non disponevamo ancora di un modello chiaro per farla agire al fianco del giocatore, ma anche questa breve sequenza ci ha insegnato molto, nonostante il poco tempo speso a perfezionarla."
N/A4122"#commentary\cn_204_laundry.mp3" "[Mike Dussault] Quando il giocatore raggiunge questo livello, la lavanderia, possiamo dare per scontato che sappia usare l'esca per risolvere gli scenari di combattimento. Pertanto, volevamo alzare la posta creando una sequenza che incoraggiasse un coinvolgimento ancora maggiore, combinando l'esca con l'intero arsenale di armi."
N/A4123"#commentary\cn_205_side_zombie.mp3" "[Quintin Doroquez] Questo zombi velenoso è stato grande protagonista dei test. I giocatori, la cui attenzione è rivolta a soldati Combine, formicheleone e torrette, non ne incontravano uno da un pezzo, per cui la sua apparizione improvvisa nel buio era uno shock."
N/A4124"#commentary\cn_206_flares.mp3" "[Quintin Doroquez] Questa sezione bilancia efficacemente la precedente sequenza con le torrette, in termini di costi di produzione e lavoro. Realizzata molto tardi, ha preso forma velocemente perché l'IA di Alyx e dei Combine era già matura. Ci piacevano il buio e i razzi, e l'abbiamo archiviata per futuri approfondimenti. In seguito, l'abbiamo rivisitata mentre progettavamo le sezioni al buio di Episode 1."
N/A4125"#commentary\cn_207_magic_wall.mp3" "[Robin Walker] Come in molte delle nostre arene di battaglia, ci serviva uno sbarramento che impedisse ai giocatori di procedere oltre prima di aver concluso lo scontro. Purtroppo, eravamo a corto di tempo e dovevamo passare alla stazione dei treni, per cui ci siamo inventati questa sciocchezza implausibile: una parete che esplode dopo la sconfitta del secondo gunship, rivelando la strada da seguire. Speravamo che passasse inosservata alla maggior parte dei giocatori, troppo impegnati ad affrontare i gunship, e i test ci avevano mostrato che, in genere, completavano lo scontro prima di arrivare a questo punto. Con sufficienti esplosioni nell'arena, la parete distrutta e in fiamme appariva vagamente naturale, per cui abbiamo aggiunto un paio di enigmi con il gas dall'altro lato per giustificarla. Ma no, non ne siamo mai andati fieri."
N/A4126"#commentary\cn_208_ragdoll_vortigaunt.mp3" "[Scott Dalton] Questo Vortigaunt defunto comunica un grande dolore: il dolore dei nostri designer di livelli. All'epoca, i nostri strumenti non ci consentivano di mettere in posa una marionetta. Quando un personaggio non giocabile moriva e crollava scompostamente al suolo, non potevamo controllare la posa che avrebbe assunto. Se avessimo affidato il lavoro a un animatore, avrebbe potuto fornirci un singolo frame di animazione che riproducesse vagamente la posa desiderata. Ma eravamo in ritardo e il nostro manipolo di animatori era oberato di lavoro. Pertanto, un designer di livelli ha posizionato il Vortigaunt sulla sedia, gli ha detto di morire al caricamento del livello, e ha atteso di vedere quale posa assumesse. Poi, lo ha mosso leggermente e ci ha riprovato. Non ricordiamo esattamente quanti tentativi siano serviti, ma di certo molti, molti più di quanto si possa immaginare."
N/A4127"#commentary\cn_209_nova_prospekt_process.mp3" "[Eric Smith] Come Ravenholm, anche Nova Prospekt prevedeva in origine situazioni di gioco drasticamente diverse da quelle finali. La prima versione si concentrava sugli scontri tra giocatore e soldati Combine, senza coinvolgere le formicheleone. A differenza di altre aree, in cui grafica e meccaniche si sono evolute insieme, la grafica di Nova Prospekt è stata definita con largo anticipo, producendo sezioni di geometrie del livello rifinite e riutilizzabili, con gli elementi grafici già applicati. Assemblare Nova Prospekt con questi componenti ha reso bene, vista la struttura ripetitiva della prigione. In seguito, dopo l'introduzione delle formicheleone e dell'esca, abbiamo dovuto convertire le geometrie per adattarle alle nuove meccaniche."
N/A4128"#commentary\cn_210_d2_prison_04.mp3" "[Eric Kirchmer] Nel corso dello sviluppo, i grafici hanno creato sezioni circoscritte dei livelli, che chiamavamo \"zoo grafici\". Questi zoo mostravano come usare texture e oggetti di scena per creare spazi di gioco che realizzassero i nostri obiettivi visivi. Ciononostante, nel creare le meccaniche di gioco delle prigioni, la struttura ripetitiva ci ha consentito di integrare la grafica in modo più diretto. Questa mappa è nata come zoo grafico principale di Nova Prospekt, ma dopo averla usata per sperimentare diversi prototipi, incluso quello che avrebbe condotto all'esca, è stata integrata nell'architettura del livello."
N/A4129"#commentary\cn_211_autosave_dangerous.mp3" "[Dave Riller] In Half-Life 1, avevamo previsto diversi salvataggi automatici nel corso del gioco, posizionati dai designer dei livelli e attivati in momenti o posizioni specifiche. In questo modo, eravamo certi che il gioco salvasse in automatico durante l'esplorazione dei corridoi di Black Mesa. In Half-Life 2 abbiamo avvertito l'esigenza di uno strumento diverso. Il problema è sorto in alcune delle arene più complesse. Alcuni incontri duravano un tempo significativo, e coinvolgevano gruppi diversi di nemici. Altri erano lunghe ed estese sezioni di esplorazione e combattimento senza soluzione di continuità. Un salvataggio automatico non è auspicabile, se il giocatore rischia di morire subito dopo il caricamento, perché creerebbe un ciclo di morte infinito. Chi ha giocato abbastanza videogiochi di quel periodo si sarà trovato in questa situazione. Per cui, a meno di non spezzare il flusso delle arene con pause accuratamente inserite, non era scontato trovare un punto sicuro per attivare il salvataggio automatico. Dopo qualche esperimento, abbiamo implementato una funzione chiamata \"Autosave Dangerous\", uno strumento per i designer che associava il salvataggio automatico a una finestra temporale. Se attivato dal designer, salvava immediatamente la partita e teneva il file di salvataggio da parte, impedendone il caricamento. Se il giocatore restava vivo per la finestra temporale specificata, allora veniva confermato, e usato come salvataggio automatico più recente. In questo modo, i designer potevano inserire un salvataggio automatico in una sezione o momento plausibile di un'arena, e specificare un'attesa, per esempio di trenta secondi. Se il giocatore restava vivo per trenta secondi, il salvataggio automatico diventava utilizzabile."
N/A4130"#commentary\cn_212_we_dont_go_to_ravenholm.mp3" "[Dario Casali] Completati i lavori su Ravenholm, non riuscivamo a liberarci dall'impressione che la transizione dal laboratorio di Eli non funzionasse a dovere. Era troppo brusca: il laboratorio era collegato direttamente alle strade cittadine, la tappa successiva, e la sezione in cui si trovava il giocatore non esisteva. Alla fine del laboratorio, c'era una promessa: \"Non andiamo più in quel luogo\". Ed eravamo soddisfatti del crescendo complessivo. Ma quando il giocatore arrivava a Ravenholm, veniva subito gettato in uno scontro con gli zombi, senza alcun margine per costruire la tensione. Pertanto, abbiamo creato questa sequenza e gli angusti corridoi per risolvere il problema in modo soddisfacente. Rallentando il ritmo e concentrandoci su grafica e illuminazione, preparavamo il giocatore a scoprire perché nessuno andasse più a Ravenholm."
N/A4131"#commentary\cn_213_lever_shenanigans.mp3" "[Dario Casali] Nonostante gli sforzi profusi per creare, nella mente del giocatore, un collegamento tra questa leva e il recinto elettrificato all'esterno, alcuni tester restavano comunque confusi dopo aver tirato la leva. Altri, addirittura, si allontanavano, attivavano di nuovo la leva, e tornavano a girovagare. Disponendo di poco tempo per rendere il collegamento più esplicito, abbiamo fatto in modo che la leva si rompesse, impedendo ai giocatori di annullare i progressi compiuti, e rafforzando la sensazione che quello di Ravenholm fosse un ambiente insidioso e fatiscente."
N/A4132"#commentary\cn_214_town_arenas.mp3" "[Dario Casali] In questa fase di Ravenholm, il giocatore ha appreso tutti gli elementi di gioco a sua disposizione e può prevederne le interazioni. Questo ci consentiva di allestire scenari più complessi, fornendo un livello maggiore di sfida e di libertà di approccio a ciascuno scenario. Questa arena è uno spazio volutamente intricato, che il giocatore è costretto a esplorare, e sfruttiamo il tempo dedicato all'esplorazione per incrementare gradualmente l'intensità degli scontri. Più è veloce l'esplorazione, più l'incremento è rapido. La natura libera di questo approccio complica il lavoro di rifinitura, a causa dell'ampio ventaglio di possibilità dinamiche con cui è possibile affrontare la sequenza."
N/A4133"#commentary\cn_215_mines.mp3" "[Dario Casali] L'intricato percorso che il giocatore deve seguire nel condotto minerario gli concede tempo in abbondanza per scoprire cosa lo attenda in fondo. Sorpresa: dei succhiateste! Tanto per cambiare. In questo caso, si tratta di succhiateste velenosi, che sono già simpatici da soli, ma diventano un vero spasso se accompagnati da succhiateste veloci. Questi due piccoletti sono una squadra magnifica: da soli non sono molto pericolosi, ma uniti diventano spaventosamente letali. Una volta avvelenato, è sufficiente un singolo colpo di un succhiateste veloce per uccidere il giocatore. È quella che i biologi chiamano \"simbiosi\". O almeno crediamo."
N/A4134"#commentary\cn_216_poison_headcrabs.mp3" "[David Speyrer] Questa stanza introduce involontariamente i succhiateste velenosi. Avevamo lavorato a lungo sulla loro presentazione ufficiale, più avanti nel gioco, ma l'entusiasmo scaturito dal loro successo nei test ci ha spinti a distribuirli in tutto il livello. Quando ci siamo resi conto che apparivano prima della presentazione prevista, era troppo tardi per intervenire. Per fortuna, una stanzetta piena di succhiateste velenosi è un valido addestramento, perché il loro design risolve un problema comune. I giocatori tendono a sentirsi sotto pressione, fino alla frustrazione, se muoiono ripetutamente senza un motivo apparente. E infatti, il problema si è posto quando abbiamo provato ad addestrarli abbinando i succhiateste velenosi con la loro origine, lo zombi velenoso. Questi succhiateste non possono uccidere il giocatore da soli, invece. Di conseguenza, per quanto snervante, una stanza piena scongiura quel genere di frustrazione."
N/A4135"#commentary\cn_217_poison_zombie_introduction.mp3" "[David Speyrer] Costringere il giocatore in uno spazio ristretto fornendogli una visuale sull'esterno è un buon metodo per accrescere le probabilità che si accorga di ciò che vogliamo mostrargli. Qui attiriamo la sua attenzione con il suono di un lamento prima che lo zombi velenoso si mostri. In origine, questo doveva essere il primo incontro dei giocatori con i succhiateste velenosi, ma come spiegato in un nodo precedente, ci siamo lasciati prendere la mano, disseminandoli in tutto il livello e rovinando la loro presentazione congiunta in questo frangente. Alla fine, tuttavia, questi incontri si sono rivelati più efficaci come istanze separate."
N/A4136"#commentary\cn_218_final_arena.mp3" "[Eric Smith] Quando abbiamo ultimato la prima versione di Ravenholm, questo tetto doveva ospitare lo scontro finale. Come altri spazi di questa mappa, era nato allo scopo di rappresentare un luogo di interesse visivo. Ritenevamo importante, al momento di lasciare Ravenholm, che il giocatore potesse gettare uno sguardo sulla città da cui era appena fuggito, e intravedere la sua prossima destinazione. Molti gruppi al lavoro sulle parti giocate hanno provato a inscenare un combattimento qui, ma le geometrie anguste e i limiti di prestazioni ci hanno impedito di creare un finale soddisfacente. Proprio come la saga stessa di Half-Life, sembra che anche Ravenholm fosse destinata a restare senza un vero epilogo."
N/A4137"#commentary\cn_219_tables_and_bodies.mp3" "[Ido Magal] Verso le ultime fasi di produzione di Ravenholm, con tutti i tasselli principali ormai disposti, abbiamo provato a riempire ogni spazio vuoto con elementi di interesse. Per riuscirci, ci siamo premurati di usare quanto avevamo a disposizione, senza creare nulla di nuovo, per non rischiare di introdurre bug. Spesso, come in questa stanza, cercavamo di aggiungere nuovi momenti di gioco, e al contempo introdurre nuovi dettagli ed elementi narrativi nell'area. Piccole scene come questa consentono a un giocatore attento di riflettere su quello che ha visto e sul suo significato rispetto a quello che lo attende."
N/A4138"#commentary\cn_220_physics_object_consistency.mp3" "[Kerry Davis] Tutti gli oggetti fisici dispongono di una varietà di parametri che ne definiscono il comportamento: la massa, i danni subiti prima di rompersi, il modo in cui si rompono e così via. Durante lo sviluppo, questi parametri erano stati specificati dai designer dei livelli per ciascun oggetto, ed è il motivo per cui la maggior parte degli elementi del gioco funzionava. In seguito, tuttavia, ci siamo resi conto di aver creato un problema: nel gioco erano presenti migliaia di oggetti fisici, ma non esisteva un metodo per assicurarne la coerenza complessiva. Di conseguenza, una scatola di cartone poteva sfasciarsi con un singolo colpo di pistola in un livello, e diventare invulnerabile in un altro. Internamente, ci riferivamo a queste incoerenze come \"Crimini dei designer dei livelli\". Per risolverle, e per fare giustizia, abbiamo realizzato un sistema che forzasse la coerenza degli oggetti fisici in base al loro modello grafico. Poiché gran parte del gioco era pronta, abbiamo dovuto concedere ai designer la libertà di ignorare il sistema nei casi limite in cui servisse un intervento criminale per preservare il progetto originale. Internamente, definivamo costoro \"recidivi\", e alcuni ancora perseverano nelle loro attività criminali dentro Valve."
N/A4139"#commentary\cn_222_fast_zombie_introduction.mp3" "[Randy Lundeen] Anche questa area era stata inizialmente realizzata per l'E3 2003, per mostrare il giocatore alle prese con una squadra di soldati Combine. Quando siamo tornati a usarla per introdurre lo zombi veloce, abbiamo cercato di preservare la maggior parte del lavoro svolto. Volevamo una sequenza epica illuminata dalla luce lunare, con gli zombi che balzano oltre la luna come licantropi per attirare lo sguardo. Concluso quel passaggio, avremmo introdotto il primo zombi veloce, lanciandolo contro il giocatore. Sono servite molte modifiche per bilanciare l'illuminazione per impreziosire la scena, assicurandoci che contribuisse anche agli obiettivi di gioco."
N/A4140"#commentary\cn_223_ravenholm_gameplay_focus.mp3" "[Mike Dussault] Dopo aver assistito a molti test di Ravenholm, sapevamo che la pistola gravitazionale e la fisica sarebbero stati il fulcro delle meccaniche del livello. Con questa consapevolezza, abbiamo ritenuto di poter realizzare la transizione verso Ravenholm in modo appropriato, per aiutare il giocatore a scoprire e comprendere un minimo l'esperienza imminente. Accade spesso: realizziamo la progressione del livello, scopriamo cosa funziona, infine ne progettiamo il prologo. Abbiamo allestito queste stanze con quel percorso in mente. La brutalità degli strumenti forniti al giocatore sembrava favorire l'atmosfera a cui miravamo, propiziando un mutamento di tono dal laboratorio di Eli a un luogo più cupo e spaventoso."
N/A4141"#commentary\cn_224_player_tools.mp3" "[Steve Bond] A questo punto del gioco, i giocatori hanno maturato una discreta esperienza con la fisica di Half-Life 2. Ma ora hanno ricevuto la pistola gravitazionale, che garantisce nuove modalità di interazione con gli oggetti fisici. Abbiamo sperimentato diversi elementi con cui il giocatore poteva divertirsi, quali lame circolari, catapulte, barili esplosivi, trappole, lance e via discorrendo. Abbiamo isolato quelli che funzionavano meglio con la pistola gravitazionale ed eliminato il resto. Poi ci siamo premurati di rimuovere le munizioni dal livello, per costringere il giocatore a fare affidamento su quegli strumenti."
N/A4142"#commentary\cn_225_contrived_setups.mp3" "[Kerry Davis] Diverse situazioni che illustrano la fisica degli oggetti e la pistola gravitazionale sono palesemente artificiose. Il giocatore estrae una lama circolare da un muro con la pistola, e con tempismo impeccabile uno zombi emerge caracollando da un angolo, come a chiedere di essere falciato dalla lama. Poi, il giocatore deve strisciare sotto una lama rotante per spegnerla, e all'improvviso appaiono tre zombi, che lo sfidano a riattivare la trappola. Non abbiamo avuto molto tempo per rifinire questa sezione, per cui ci servivano situazioni che funzionassero per tutti, invece di sequenze aperte che richiedessero di compiere la mossa \"giusta\". Sebbene questo approccio rischi di limitare la creatività dei giocatori, nel caso specifico ci è sembrato che non patissero troppo questa forzatura."
N/A4143"#commentary\cn_226_misteaching_flinches.mp3" "[Kerry Davis] Un altro test memorabile, nonché riprova di quanto sia rischioso comunicare nozioni errate, si è svolto a Ravenholm. Uno dei nostri principi è reagire il più possibile al giocatore. Pertanto, nel progettare la pistola gravitazionale, ci è sembrato ovvio che, puntandola contro uno zombi e premendo il grilletto, il giocatore avrebbe dovuto ottenere un risultato. Non è stato difficile fare in modo che folgorasse lo zombi per un breve periodo, attivando la sua animazione di vacillamento. Un esito soddisfacente e reattivo. In seguito, durante un test, qualcuno ha scoperto questa interazione subito dopo l'arrivo a Ravenholm, ricavandone che la pistola gravitazionale avesse ferito lo zombi. Deduzione corretta, ma il danno era minimo. Per cui, lo ha colpito di nuovo, ripetutamente, folgorandolo finché non è morto. Un metodo straziante, disumano e poco divertente per affrontare gli zombi, soprattutto se intorno abbondano lame circolari e barili esplosivi. Imparata la lezione, abbiamo rimosso l'animazione di vacillamento, rinunciando a quell'interazione tra lo zombi e la pistola gravitazionale. Nel caso specifico, era preferibile eliminarla, piuttosto che supportare l'idea, falsata, che la pistola gravitazionale fosse un'arma efficace per eliminare gli zombi. Persino i principi più elementari possono richiedere compromessi, scendendo nel dettaglio."
N/A4144"#commentary\cn_227_fire_trap.mp3" "[Steve Bond] Questa trappola era stata pensata per mostrare il sistema di gestione delle fiamme, prima che un designer dei livelli la rendesse un elemento di gioco a Ravenholm. Nel corso dello sviluppo, ha rischiato di essere rimossa più volte per via dell'impatto sulle prestazioni dei PC meno potenti, causato dall'uso eccessivo di sprite trasparenti. Infine, uno dei programmatori ha ritenuto che fosse abbastanza importante da meritare gli sforzi necessari a ridurre il peso sulle prestazioni e assicurarsi che venisse inserita nel gioco."
N/A4145"#commentary\cn_228_hallway_cupboards.mp3" "[Yahn Bernier] Questi corridoi ingombri di rifiuti erano un espediente per rallentare il giocatore dove necessario. L'obbligo di preservare la maggior parte delle geometrie esistenti, unito alla lentezza di nemici come gli zombi, rendeva complicato impedire al giocatore di procedere di corsa. Per fortuna, la presenza di Grigori, folle abitante di Ravenholm, ci aiutava a giustificare queste sezioni. Aveva senso che avesse ostruito le scale per restare al sicuro sui tetti. A conti fatti, la soluzione di Grigori e la nostra coincidevano: spargere un mucchio di mobili in giro. Se fermavano gli zombi, avrebbero rallentato anche il giocatore."
N/A4146"#commentary\cn_229_pacing_switch.mp3" "[Steve Bond] Ora che i giocatori hanno superato la sezione di addestramento, possiamo cambiare ritmo: dagli scenari d'atmosfera e claustrofobici alle arene incentrate sugli scontri. Con il giocatore consapevole degli strumenti fisici disponibili nell'ambiente, possiamo introdurli in aree più aperte e lasciare libera scelta sull'approccio da tenere."
N/A4147"#commentary\cn_230_car_crushers.mp3" "[Steve Bond] Queste auto usate come pressa hanno richiesto diverse modifiche e qualche intervento sul nostro sistema di danni fisici. Sorge sempre una sfida, quando oggetti fisici di grandi dimensioni interagiscono con i personaggi non giocabili. Per esempio, se la fisica non riesce a schiacciare il PNG, potrebbe spingerlo in un punto indesiderabile, impedendogli di riprendersi. Nel caso dei succhiateste, non è un problema grave, poiché possono balzare via dalla situazione scomoda, ma per le creature come gli zombi c'è il rischio che si incastrino e restino indifese, agitando gli arti scompostamente in qualsiasi anfratto siano riuscite a infilarsi. Demolendo l'atmosfera da survival horror che volevamo creare."
N/A4148"#commentary\cn_231_car_crusher_lifts.mp3" "[Eric Smith] Anche consentire alle presse di sollevare il giocatore è stato complicato. Il giocatore viene costantemente simulato, sia dal sistema fisico, sia dal sistema di movimento del gioco. Ogni volta che aggiorniamo il suo stato, confrontiamo i risultati di entrambi i sistemi per decidere quale sia quello \"corretto\", poi li sincronizziamo e la procedura si ripete. In questo modo, i due sistemi possono influenzarsi a vicenda: se il giocatore sale su un'altalena, la fisica fa abbassare l'asse; se sale sulla pressa, viene sollevato. Sebbene fosse più complesso, questo approccio duplice consentiva interventi più semplici rispetto a gestire la fisica e il movimento del giocatore con un unico sistema. Tenendoli separati, potevamo rifinire il sistema di movimento perché risultasse soddisfacente da solo, riconciliando entrambi quando la fisica influiva sul giocatore."
N/A4149"#commentary\cn_232_paint_cans.mp3" "[Steve Bond] Dopo i primi fruttuosi tentativi di rendere la pistola gravitazionale e la fisica il fulcro dell'esperienza a Ravenholm, abbiamo cominciato a esaminare i livelli in cerca di oggetti dal potenziale sottovalutato, poiché ci eravamo concentrati su quelli più aggressivi, come le lame circolari e i barili esplosivi. Una delle scoperte ha riguardato il barattolo di vernice, e siamo riusciti facilmente a rinforzare le aspettative del giocatore, facendo in modo che imbrattasse gli zombi se scagliato come proiettile."
N/A4150"#commentary\cn_233_bringing_physics_to_the_enemies.mp3" "[Tom Leonard] Le trappole legate alla fisica di Ravenholm sono state tra i primi elementi del livello a convincerci appieno, ma la partecipazione del giocatore era limitata. Sono servite le lame circolari per comprendere il vero significato di Ravenholm. Con le lame, il giocatore poteva portate la fisica agli zombi, invece di condurre questi ultimi alla fisica. Assimilato questo aspetto, l'evoluzione di Ravenholm è stata rapida. Abbiamo continuato a setacciare la mappa in cerca di qualsiasi elemento, preferibilmente insolito, che potesse trasformarsi in un'arma o uno strumento per il giocatore."
N/A4151"#commentary\cn_234_ravenholm_development.mp3" "[Tom Leonard] Il lavoro su Ravenholm è iniziato nelle prime fasi di produzione di Half-Life 2, per cui ha attraversato più di un passaggio integrale di sviluppo. La prima versione è precedente alla pistola gravitazionale, e prevedeva classici scontri con gli zombi, utilizzando le armi e alcune delle trappole basate sulla fisica. Avevamo persino intenzione di mostrare Ravenholm all'E3 2002, ma infine il gioco è stato svelato un anno più tardi, nel 2003. A quel punto, avevamo investito molto nella grafica di Ravenholm, una prassi che tendiamo a evitare prima di aver consolidato le parti giocate. Per cui, tornati a Ravenholm con le meccaniche della pistola gravitazionale in mente, ci siamo trovati a lavorare su numerose geometrie preesistenti, progettate con obiettivi molto diversi."
N/A4152"#commentary\cn_235_grigori_plaza.mp3" "[Steve Bond] Questa piazza aperta è una delle aree che avevamo definito integralmente nel primo passaggio di sviluppo. Nel ritornarci, abbiamo voluto creare un nuovo percorso per il giocatore, che sfruttasse tutte e tre le dimensioni, preservando al contempo la maggior parte della grafica esistente. Muovendo il giocatore su e giù attraverso le finestre, sui tetti, da un edificio all'altro. Non era uno spazio ampio, per cui abbiamo dovuto spremerne ogni possibile utilizzo. L'area, in partenza, privilegiava la grafica, per cui i contenuti di gioco erano limitati. Avevamo anche notato che i tester tendevano ad attraversarla di corsa. Come se non bastasse, eravamo già al limite del budget tecnico a disposizione, con scarso margine per introdurre novità. La sfida è stata introdurre aggiunte minori che rallentassero il giocatore, inserendo minacce dietro ogni angolo e in ogni anfratto."
N/A4153"#commentary\cn_236_ravenholm_development_2.mp3" "[Tom Leonard] Quando parliamo di Half-Life 2 con i fan, Ravenholm resta per molti la sezione più memorabile. In virtù dei molteplici passaggi di sviluppo e della densità di contenuti, a Ravenholm hanno contribuito più membri del team rispetto a qualsiasi altra sezione. È stato qui che abbiamo compreso come applicare le nostre procedure grafiche alle sequenze animate e all'atmosfera che cercavamo, come la fisica e le meccaniche di gioco si integrassero alla pistola gravitazionale, come succhiateste e zombi dovessero evolvere in Half-Life 2 e molto altro ancora. Ripensarci rafforza la nostra fede nel potere individuale rispetto a un approccio centralizzato. Ravenholm è densa, efficiente come meccaniche di gioco e realizzazione grafica, e somma di molteplici contributi minori da parte di persone che hanno capito come spingere un passo avanti i propri talenti individuali."
N/A4154"#commentary\cn_237_playtester_archetypes.mp3" "[Tom Leonard] Rifiniture continue e test costanti sono stati la linfa vitale della produzione di Half-Life 2. Ogni settimana, osservavamo in silenzio qualche giocatore affrontare la sezione su cui stavamo lavorando, e prendevamo appunti su cosa funzionasse e cosa no. Era cruciale svolgere test mirati a un ampio ventaglio di abilità, per assicurarci che le nostre scelte non accontentassero solo alcuni. In seguito, abbiamo imparato a scegliere specifiche tipologie di tester in base alla fase di sviluppo corrente. In quelle iniziali, ci affidavamo a giocatori esperti, in genere compagni di squadra, che sapevano gestire aree grezze e incomplete ed esprimere chiaramente le proprie riflessioni. Per i test sui combattimenti, cercavamo giocatori di diversa abilità, ma in particolare chi sapeva usare creativamente gli strumenti. Infine, a uno stadio di rifinitura avanzato, ci concentravamo sui principianti: coloro che non giocavano spesso o non avevano familiarità con gli sparatutto in soggettiva. Magari non avrebbero comprato il gioco, ma osservarli ci insegnava sempre qualcosa."
N/A4155"#commentary\cn_238_the_real_final_arena.mp3" "[Tom Leonard] A sviluppo di Half-Life 2 molto inoltrato, durante la revisione mirata a identificare eventuali opportunità di miglioramento, abbiamo deciso che, a conti fatti, Ravenholm meritasse un vero epilogo. Lo scontro sui tetti non bastava. Dopo averne discusso, abbiamo scelto di introdurre questo scontro finale nel cimitero, con Grigori al fianco del giocatore. Dal punto di vista dello sviluppo, era rischioso, ma sentivamo che il gioco ne avrebbe giovato. Poiché eravamo agli sgoccioli della produzione, disponevamo di un set maturo di strumenti. Ma soprattutto, ormai conoscevamo il nostro gioco. Realizzare un gioco consiste spesso nel comprendere cosa stai realmente creando. Perché è divertente? In cosa si distingue? Quali sono gli elementi principali? Sviluppando il gioco e osservando le prove dei tester, abbiamo trovato le risposte a queste domande, e al contempo siamo migliorati nel nostro lavoro. Pertanto, il cimitero è stato completato in tempi rapidi, e ha richiesto molti meno interventi delle aree precedenti."
N/A4156"#commentary\cn_239_cities.mp3" "[Eric Kirchmer] Una delle sfide più insidiose di questa sezione è stato comunicare al giocatore la sensazione di trovarsi in una grande città, quando il nostro budget tecnico non ci consentiva di renderizzare nulla del genere. Ci ha spinto a concentrarci su edifici addossati l'uno all'altro, garage sotterranei, tunnel della metro, canali e via discorrendo. Tutti luoghi normalmente presenti in una città, ma che impediscono di guardare l'orizzonte. Poi, abbiamo integrato dei punti panoramici in questo approccio alla progettazione dei livelli, luoghi in cui l'intero spazio ha lo scopo di fornire al giocatore un'ampia visuale. Qui potevamo dedicare l'intero budget tecnico al panorama, senza dover risparmiare risorse per l'IA o il combattimento."
N/A4157"#commentary\cn_240_strider_4.mp3" "[Eric Smith] Sebbene questa fosse la mappa di produzione realizzata per lo strider, disponevamo ancora di una mappa di sviluppo per testarne l'IA. Abbiamo sempre ritenuto prezioso poter contare su una mappa affidabile per i test sulla IA, perché ci consente di sperimentare nuove idee di gioco, e di rifinirle con facilità. In caso di bug o problemi concettuali, possiamo isolarli e intervenire rapidamente. Quando le funzionalità della IA sono pronte, le importiamo nelle mappe di produzione perché possano lavorarci i designer dei livelli. La mappa di test dello strider includeva le sagome abbozzate di edifici in rovina, con generatori di cittadini in posizioni e altezze diverse a fornire un flusso costante di bersagli. In questo modo, potevamo rifinire l'IA e i cambi di postura dello strider per renderlo interessante e coinvolgente, anche solo da osservare in azione."
N/A4158"#commentary\cn_241_perf_arena.mp3" "[Aaron Seeler] Questa arena presentava una sfida notevole: le prestazioni. Le dimensioni e l'IA combinata di strider e cittadini forzavano i nostri limiti. Quando abbiamo convertito Half-Life 2 su Xbox, sono state necessarie delle modifiche progettuali. Preservare l'intento originario e garantire la medesima esperienza di gioco con spazi e strumenti ridotti si è rivelato un complesso gioco di equilibri."
N/A4159"#commentary\cn_242_space_re-use.mp3" "[Chris Green] Tornare in questo spazio presentava diversi vantaggi. Per primo, quello più ovvio: i costi di produzione delle nuove aree sono sempre elevati, per cui aggiungere nuove sezioni di gioco a un'area esistente è sempre una vittoria. Per uno scontro così impegnativo, tuttavia, in cui i giocatori affrontano molteplici strider, il riciclo ha benefici aggiuntivi. Poiché sono già stati nell'arena, i giocatori hanno un'idea della sua struttura. Stavolta procedono a ritroso, ma ripercorrendo in buona parte il percorso originale. Questa familiarità si rivela utile quando devono muoversi per recuperare le risorse necessarie allo scontro. Lo stato di guerra di City 17 ci ha anche garantito la flessibilità necessaria per intervenire sulle coperture e aggiungere ostacoli minori, mantenendo l'ambiente dinamico e imprevedibile."
N/A4160"#commentary\cn_243_tenements_and_courtyards.mp3" "[Danika Rogers] Per comunicare l'atmosfera di una città in guerra, abbiamo usato molti trucchi e creato funzionalità apposite, con l'obiettivo di mostrare sprazzi di battaglie o riprodurre suoni di scontri in lontananza. I Looktarget ci consentivano di attivare un evento ogni volta che il giocatore si affacciava a una finestra, mentre strumenti come i \"Tracer Maker\" aiutavano i progettisti a creare false scie di proiettili traccianti tra due punti. Con l'ausilio degli strumenti audio, si creava l'illusione di uno scontro a fuoco tra due fazioni, senza implementare alcuna IA. Abbiamo anche sviluppato piccole storie per gruppi di cittadini, che il giocatore avrebbe intravisto ripetutamente procedendo lungo il livello. Questi momenti sono stati rifiniti con i test per assicurarci che vi assistesse la maggior parte dei giocatori."
N/A4161"#commentary\cn_244_hopper_mine_training.mp3" "[Dario Casali] Questo pannello di metallo ondulato è stato posizionato deliberatamente sul buco per spingere il giocatore a rimuovere l'ostruzione con la pistola gravitazionale. È una forma di manipolazione, perché ci eravamo accorti che i giocatori imparavano meglio a gestire le mine saltatrici se provavano subito a colpirle con la pistola gravitazionale, e il pannello incrementava notevolmente le probabilità che l'avessero equipaggiata. Abbiamo disposto molteplici mine nel buco per fornire numerose opportunità di interazione, facilitando la scoperta di metodi alternativi per liberarsene. Inoltre, questa è la prima volta che addestriamo il giocatore mentre ha con sé un'intera squadra di cittadini, per cui ne abbiamo approfittato per includere nuove linee di dialogo riguardanti le mine saltatrici."
N/A4162"#commentary\cn_245_dog_combat.mp3" "[Eric Kirchmer] Dog è un personaggio molto divertente e cercavamo sempre nuovi modi per coinvolgerlo nei combattimenti del giocatore. Tuttavia, creare scontri che fossero proporzionati a lui, in termini di scenario, nuova IA degli avversari e potenzialmente nuovi nemici, ha superato in fretta la portata del progetto. Per creare una battaglia che rendesse giustizia a Dog e fosse all'altezza del resto del gioco, avremmo dovuto quasi creare un gioco nel gioco. Non poteva semplicemente correre verso un soldato e tirargli un pugno: non avrebbe trasmesso nessun senso di stupore. Servivano minacce proporzionate alla sua stazza e modi interessanti di farlo interagire con loro. Alla fine, abbiamo optato per una grande scena coreografata che rendesse Dog protagonista di una sequenza di combattimento cinematografica, senza dover progettare dinamiche di gioco complesse."
N/A4163"#commentary\cn_246_strider_2.mp3" "[Eric Kirchmer] Dopo vari tentativi, finalmente eravamo soddisfatti della fase con lo strider, dove i giocatori dovevano correre tra i ripari e schivare proiettili mentre cercavano razzi. Volevamo che i giocatori avessero la sensazione di tuffarsi al riparo all'ultimo istante, per cui abbiamo ottimizzato le raffiche dello strider perché preannunciassero il pericolo. Abbiamo anche realizzato un sistema di binari per lo strider, consentendogli di passare da uno all'altro per inseguire il giocatore o stabilire una linea di tiro. Questa soluzione permetteva ai designer dei livelli di allineare i binari dello strider ai ripari del giocatore, bilanciando l'esperienza. Il posizionamento delle gambe dello strider era gestito interamente dal codice e i suoi movimenti imprevedibili ci costringevano spesso a correggere qualcosa per essere sicuri che calciasse un'auto o un trasporto truppe al momento giusto."
N/A4164"#commentary\cn_247_manhack_tunnels.mp3" "[Eric Smith] Per aiutare i programmatori a sviluppare l'IA dei personaggi non giocabili, fornivamo loro una mappa di prova in cui sperimentare. Spesso, quella mappa si evolveva in un ambiente progettato appositamente per mettere in mostra le capacità specifiche di un PNG. Quando poi l'IA era pronta per essere usata dai designer dei livelli, la mappa di prova rappresentava un riferimento prezioso: senza di essa, i designer avrebbero potuto creare scenari incapaci di valorizzare un'IA valida. In alcuni casi, abbiamo inserito queste mappe di prova direttamente nel gioco. Questa breve sezione, per esempio, è nata per sviluppare l'IA della lama della morte."
N/A4165"#commentary\cn_248_sniper_streets_2.mp3" "[Erik Johnson] I proiettili di Half-Life 2 non seguono una traiettoria, ma raggiungono il bersaglio all'istante. Per il cecchino, considerata la ridotta cadenza di fuoco e l'elevata attenzione del giocatore a ogni colpo, volevamo simulare il movimento del proiettile. Questo approccio si adattava bene al mirino laser, che si spegne appena prima che il proiettile giunga a destinazione, a seconda della distanza dal cecchino. Tuttavia, questa modifica creava un nuovo problema: non volevamo che i giocatori si limitassero a correre per evitare i proiettili. Pertanto, il tiratore doveva anticipare i movimenti del bersaglio. Prevedere gli spostamenti del giocatore era complicato, perché può cambiare direzione molto più velocemente di quanto sia possibile nella realtà. Quindi, abbiamo inserito degli strumenti per captare le azioni dei giocatori, come la rapida pressione dei comandi destra o sinistra."
N/A4166"#commentary\cn_249_triangle_plaza.mp3" "[Ido Magal] È stato complicato allestire questo combattimento, che usa il comportamento Assalto con due linee di battaglia convergenti, una per ogni campo di forza. Mentre i soldati entrano dai campi di forza, le loro linee di battaglie gli impediscono di correre da soli verso la piazza. Quando lo scontro diventa più intenso, e i soldati si accumulano, le linee di battaglia iniziano a spostarsi verso il centro della piazza, dove i nemici possono travolgere il giocatore, se non vengono respinti."
N/A4167"#commentary\cn_250_sniper_streets_3.mp3" "[Jakob Jungels] Una delle funzionalità che abbiamo provato a inserire qui è il fuoco di soppressione. Molti giocatori si accucciavano in fondo alla strada e provavano a sparare alla finestra del cecchino per vedere se producesse qualche effetto. Quindi, abbiamo provato a introdurre una breve scomparsa del mirino laser per dare tempo al giocatore di spostarsi. Dopo diversi test, tuttavia, sono emersi due problemi: innanzitutto, rovinava la tensione della meccanica incentrata sul muoversi tra i ripari che volevamo creare. Sparare in corsa non era molto diverso dalle altre azioni che il giocatore eseguiva a City 17. Il secondo e meno evidente problema era che i giocatori che scoprivano il fuoco di soppressione pensavano fosse necessario e consumavano in fretta le munizioni. Quando le esaurivano a metà strada, spesso rinunciavano pensando di aver fallito. E se arrivavano in fondo, erano praticamente a secco. Di converso, chi si muoveva furtivamente non sparava quasi mai. Il divario di risorse tra i due approcci rendeva quasi impossibile bilanciare le munizioni per le sezioni successive, per cui abbiamo abbandonato l'idea."
N/A4168"#commentary\cn_251_assault_behavior.mp3" "[John Cook] Il comportamento più complesso che abbiamo creato per Half-Life 2 era il comportamento Assalto, usato in questa fase del gioco. Permetteva ai designer di creare scenari di combattimento con soldati Combine e cittadini, stabilendo linee di battaglia tra gli schieramenti che reagissero alle azioni del giocatore. I personaggi non giocabili coinvolti in un assalto cercavano posizioni di tiro efficaci e usavano i ripari in base al piazzamento della linea di battaglia. Quando il giocatore avanzava, poteva spingere in avanti la linea di battaglia, inducendo i cittadini alleati a procedere e i soldati nemici a ripiegare. In altri casi, il giocatore doveva abbattere delle torrette Combine o eliminare un soldato dietro una barricata per permettere alla linea di battaglia di avanzare."
N/A4169"#commentary\cn_252_bank_roof_mortar.mp3" "[John Morello] Una volta costruito il percorso del livello che conduce a questo punto, era ovvio che sarebbe stato divertente far usare il mortaio al giocatore. Avremmo dovuto intuirlo prima. \"Pensi che a qualcuno piacerebbe lanciare esplosivi in cielo e farli piovere sui cattivi? Sì, anch'io\". Comunque, fino a quel momento i giocatori si erano sentiti un bersaglio: permettergli di ripagare i Combine con la loro stessa moneta sarebbe stata un'ottima ricompensa. Ma ci siamo subito resi conto di quanto lavoro avrebbe richiesto. Un pensiero che ti accompagna sempre, quando decidi di creare un videogioco. Ora che era vicino al giocatore, il mortaio richiedeva animazioni ed effetti, e non sarebbe stato facile aumentare il numero di nemici su cui usarlo nella piazza sottostante. Soprattutto, non avevamo un'interfaccia per un'arma così particolare. Come avremmo gestito la mira e il fuoco? Non volevamo dedicare troppo tempo a un singolo momento di gioco e abbiamo preferito concentrare i nostri sforzi altrove, passando oltre. Mi dispiace! Magari verremo a capo della progettazione del mortaio in un prossimo episodio di Half-Life."
N/A4170"#commentary\cn_253_strider.mp3" "[Kerry Davis] Questa zona di fronte alla banca è dove abbiamo concepito lo strider. Non appena abbiamo visto i bozzetti, abbiamo deciso di inserirlo nel gioco, ma c'erano numerose incognite su come farlo funzionare. Non avevamo mai mosso un elemento così grande nel nostro mondo di gioco e, considerata la stazza, doveva essere pericoloso, ma i giocatori come avrebbero dovuto affrontarlo? Come per tutti gli altri nemici, ci ponevamo il problema di come ricavarne meccaniche di gioco. Che tipo di strumenti sarebbero serviti ai designer per costruire livelli in grado di contenerlo? Queste erano le domande a cui cercavamo di dare risposta sperimentando su questa mappa."
N/A4171"#commentary\cn_254_sniper_streets.mp3" "[Eric Kirchmer] È in queste strade disseminate di cecchini che abbiamo sviluppato i nemici e il cuore dell'esperienza che avrebbero vissuto i giocatori. Poiché volevamo che il cecchino colpisse degli oggetti vicino al giocatore, ci siamo messi a pensare a dei potenziali bersagli. Sembrava una buona idea sfruttare la visuale del giocatore come criterio di scelta degli oggetti. Il mirino laser indicava costantemente dove fosse rivolta l'attenzione del cecchino, quindi muoverlo verso un bersaglio visibile al giocatore ci sembrava una soluzione molto reattiva e in grado di creare momenti di grande tensione."
N/A4172"#commentary\cn_255_citizen_squad_details.mp3" "[Matt Wright] Una volta creata la squadra di cittadini, ci siamo messi al lavoro sugli scenari e abbiamo intravisto opportunità interessanti. I tester si affezionavano ai singoli membri del gruppo, spingendoci a curare di più la loro caratterizzazione. I compagni raccoglievano armi migliori, se ne trovavano, passavano munizioni al giocatore, se le stava esaurendo, e i medici lo curavano. Dovevamo anche assicurarci che la squadra seguisse sempre il giocatore, nonostante i suoi spostamenti fossero imprevedibili. Quando non era visibile, la squadra \"barava\" in vari modi: recuperava salute dopo gli scontri, accelerava per recuperare terreno e, se necessario, si teletrasportava."
N/A4173"#commentary\cn_256_citizen_squads.mp3" "[Ken Birdwell] I primi test degli scontri in strada tra Combine e cittadini hanno subito rivelato un problema: senza confini, i combattimenti basati su IA potevano allontanarsi parecchio dal giocatore. I soldati ripiegavano per ricaricare o ripararsi, e l'IA dei cittadini li spingeva a inseguirli. Serviva un modo per allineare le azioni dei civili agli obiettivi del giocatore, aggiornandoli sulla direzione in cui procedeva il protagonista e su quali nemici decideva di attaccare. Da qui è nata l'idea di una squadra di cittadini alleati. L'IA dei cittadini teneva il gruppo vicino al giocatore, attaccando gli stessi nemici e fornendo un'interfaccia essenziale per gli ordini del giocatore. All'inizio avevamo un sistema di comandi più complesso, ma era scomodo, per cui l'abbiamo alleggerito."
N/A4174"#commentary\cn_257_ai_behaviors.mp3" "[Mike Dussault] Una tecnologia di IA che abbiamo sviluppato per Half-Life 2 è il sistema di comportamenti. I comportamenti sono porzioni di codice di gioco che guidano i personaggi non giocabili in determinate situazioni. Per esempio, avevamo un comportamento Guida che consentiva a un PNG di guidare il giocatore, e uno Segui con cui i PNG seguivano il protagonista o altri personaggi. I comportamenti affiancavano le azioni base dei PNG, per cui un medico alleato spinto dal comportamento Segui a restare vicino al giocatore avrebbe continuato a sparare ai nemici, a schivare granate o a offrire kit medici."
N/A4175"#commentary\cn_258_occlusion.mp3" "[Brian Jacobson] In Half-Life 1 e in buona parte di Half-Life 2, il mondo era composto principalmente da tunnel e corridoi chiusi, che funzionavano bene con una partizione binaria dello spazio, detta anche struttura ad albero BSP. In sostanza, questa tecnologia passava velocemente in rassegna le geometrie per stabilire quali potessero essere nel campo visivo del giocatore. Tuttavia, le aree sulla costa e le altre sezioni all'aperto non si prestavano a questo approccio, serviva una tecnologia diversa. Una di queste erano i portali, che permettevano di suddividere il mondo in blocchi separati da portali... Nel senso di porte e finestre, non quelli della Aperture Science. Abbiamo anche sviluppato un ulteriore sistema di occlusione, che in sostanza bloccava la renderizzazione delle porzioni di oggetti non visibili al giocatore. Può sembrare una soluzione ovvia, ma serve parecchio lavoro per evitare che il calcolo della porzione non visibile di un grosso oggetto non richieda più risorse del rendering. Per accelerare il calcolo, i designer dei livelli inserivano grossi volumi di occlusione dentro gli elementi del terreno o negli edifici e, durante il rendering, potevamo testare i confini delle entità in rapporto a questi volumi per non renderizzare ciò che il giocatore non vedeva."
N/A4176"#commentary\cn_259_detail_objects.mp3" "[Brian Jacobson] Dopo aver reso funzionanti le sezioni all'aperto, era necessario aggiungere piccoli dettagli al terreno, come piante, erba e cespugli. Tuttavia, sapevamo di non avere abbastanza tempo per disporli a mano. Per questo, abbiamo realizzato un sistema di dettagli che genera automaticamente piccoli elementi di vegetazione in base al materiale della superficie. Ogni materiale è associato a una tipologia di vegetazione e include una serie di parametri. Al momento di compilare la mappa, il sistema calcola dei punti casuali sulla superficie e seleziona il tipo di vegetazione da inserire. A causa dei limiti tecnici, c'era comunque un processo piuttosto complesso di modifica manuale delle texture della vegetazione, che poi venivano renderizzate tutte in un solo passaggio."
N/A4177"#commentary\cn_260_displacements_1.mp3" "[Charlie Brown] Dopo l'uscita di Half-Life 1, i nostri grafici e designer di livelli volevano una tecnologia migliore per gli ambienti esterni, motivo per cui abbiamo realizzato la prima versione del nostro sistema per i terreni. Si basava sulla suddivisione di quadrati. Immaginate una griglia piatta di forma quadrata in cui ogni punto poteva essere sollevato o abbassato. I designer potevano disporre più quadrati e usare un pennello virtuale per creare colline o avvallamenti spostando i punti della griglia. Per il rendering usavamo una texture mista, ottenuta combinandone due diverse. Ogni punto della griglia indicava la percentuale di ciascuna texture da usare, permettendo transizioni graduali tra superfici come sabbia, erba, terra e ghiaia. Questo strumento per i terreni era piuttosto comune all'epoca e, ingenuamente, pensavamo sarebbe stato sufficiente per i nostri designer di gioco."
N/A4178"#commentary\cn_261_displacements_2.mp3" "[Charlie Brown] Ora che il sistema di terreni era operativo, pensavamo che i designer dei livelli l'avrebbero usato per gli spazi esterni. Invece, hanno iniziato a sperimentare, aggiungendo dettagli in luoghi non previsti. Hanno usato le griglie quadrate sui muri per creare bordi fatiscenti, hanno arrotondato i marciapiedi e persino tentato di creare tubi. I risultati non erano sempre ottimali, perché quel sistema era pensato per i paesaggi, non i dettagli architettonici. Ci siamo quindi rimessi a programmare per convertire il sistema di terreni basato sulle altezze in un sistema di modellazione 3D. Ora, oltre a muovere i punti su e giù, i designer potevano spostarli in ogni direzione. Questo permetteva di aggiungere dettagli a ogni superficie, usando le texture miste per addolcire le transizioni tra i quadrati e la geometria BSP. Tuttavia, serviva del lavoro in più per uniformare l'illuminazione dei due rendering, altrimenti i bordi sarebbero stati troppo evidenti. Fatto questo, comunque, i designer dei livelli erano soddisfatti e ci illudevamo che, questa volta, sarebbe stato sufficiente."
N/A4179"#commentary\cn_262_displacements_3.mp3" "[Charlie Brown] Con il sistema di modellazione a disposizione, i designer dei livelli non si sono limitati ad aggiungere dettagli al mondo di gioco, e sono tornati all'obiettivo iniziale: creare scenari esterni su larga scala. Questo ci ha costretti a un altro giro di aggiornamenti per bilanciare le prestazioni e assicurarci che il sistema potesse gestire sia i dettagli, sia i terreni. Anche le texture dovevano essere migliorate, soprattutto per supportare strutture complesse come le rupi sospese, che non erano possibili con il precedente sistema basato sull'altezza. I designer, che non riposano mai sugli allori, hanno quindi iniziato a usare la modellazione per creare caverne e tunnel. Erano aggiunte fantastiche, ma richiedevano ulteriori correzioni tecniche. Alla fine, siamo riusciti ad accorpare i requisiti contrastanti dei vari modi in cui la modellazione veniva usata, inserendola in grosse porzioni del mondo di gioco. Ripensandoci ora, la modellazione è un chiaro esempio di come la tecnologia e la progettazione di gioco evolvano insieme. È come il dilemma dell'uovo e della gallina: non possiamo prevedere il reale impatto di una tecnologia sul gioco, ma non possiamo creare una tecnologia senza sapere a cosa servirà. Come sempre, l'importante è creare. Partiamo da un'ipotesi e vediamo dove ci porta."
N/A4180"#commentary\cn_263_particles.mp3" "[Chris Green] Per il motore Source, abbiamo scelto di puntare sugli effetti particellari e speciali, rendendo più realistico e articolato il movimento delle particelle, oltre a effetti più complessi per forme e shader. In particolare, l'aggiunta della mappatura bump alle funzionalità particellari ne migliorava nettamente la resa volumetrica. Sebbene le versioni successive del motore Source includessero un potente editor di particelle, la versione originale usata in Half-Life 2 ricorreva a effetti creati meticolosamente a mano dai programmatori, un processo molto dispendioso in termini di forza lavoro."
N/A4181"#commentary\cn_264_cubemaps.mp3" "[Chris Green] Con l'aggiunta di materiali e shader, ci serviva una soluzione per le superfici riflettenti, come vetro e acciaio. Era necessario comunicare alle superfici cosa riflettere, ma nel 2003 quel tipo di rendering non era possibile in tempo reale. Così, abbiamo sviluppato il sistema di cubemap per riflessi precalcolati. Un cubemap è un cubo contenente sei immagini che cattura l'ambiente in ogni direzione, come una foto panoramica che ti avvolge completamente. I designer piazzavano degli indicatori invisibili nei livelli e, durante la compilazione della mappa, noi generavamo un cubemap presso ogni indicatore. Quindi, se nel gioco era necessario renderizzare una superficie riflettente, individuavamo il cubemap precalcolato più vicino per creare il riflesso."
N/A4182"#commentary\cn_265_water_shader.mp3" "[Gary McTaggart] Lo shader più complesso che abbiamo realizzato per il gioco è quello dell'acqua, che sfruttava al massimo le nuove schede grafiche programmabili. Se era presente dell'acqua, la scena veniva renderizzata tre volte: una volta per il mondo subacqueo e le rifrazioni; una seconda per la visuale riflessa; e una terza per le parti fuori dall'acqua. Nel rendering della superficie dell'acqua sovrapponevamo le rifrazioni e i riflessi, aumentando i riflessi agli angoli radenti con l'equazione di Fresnel. Misuravamo anche la profondità del fondale, aumentando la trasparenza e riducendo i riflessi dove era minore. Inoltre, abbiamo creato due diverse tecniche di rendering dell'acqua per le schede grafiche meno potenti: quelle di fascia media mostravano riflessi meno dettagliati, senza rifrazioni o trasparenze, mentre quelle di fascia bassa renderizzavano solo una superficie semi-trasparente."
N/A4183"#commentary\cn_266_normal_maps.mp3" "[Gary McTaggart] Half-Life 2 è stato sviluppato in un'epoca esaltante per la grafica, perché stavano arrivando sul mercato le prime schede grafiche con supporto a shader programmabili. Questa tecnologia gli ha permesso di essere uno dei primi giochi a implementare la mappatura normale, una tecnica che migliorava l'illuminazione sulle geometrie delle superfici. La mappatura normale evidenziava la rugosità delle superfici, permettendo a ogni pixel di un poligono di essere illuminato in modo da rendere le texture più irregolari e dettagliate di quelle di Half-Life 1."
N/A4184"#commentary\cn_267_rendering_systems.mp3" "[Gary McTaggart] Nei primi anni 2000, non potevamo permetterci un renderer generico con le capacità di un motore moderno. I limiti di CPU, GPU e memoria imponevano di trovare soluzioni estremamente specifiche ai problemi di rendering per ottenere il massimo dagli hardware dei giocatori. Per questo Half-Life 2 ha tre diversi motori di rendering: uno per le geometrie del mondo, uno per i terreni esterni e un terzo per le entità dinamiche, come personaggi e oggetti. Questi tre renderer dovevano supportare un complicato intreccio di funzioni, come collisioni, tracciamento delle luci, texture, illuminazione offline, calcolo della visibilità e molto altro. Inoltre, ogni motore doveva supportare le DirectX 7, 8 e 9. Queste versioni delle DirectX erano molto diverse tra loro e spesso imponevano approcci diversi all'archiviazione dei dati e al rendering. Usavano persino linguaggi di programmazione diversi! Nel complesso, avevamo nove diversi renderer, ognuno con soluzioni specifiche. Riuscire a ottenere gli stessi risultati da tutti è stata una delle principali sfide dello sviluppo."
N/A4185"#commentary\cn_268_dynamic_shadows.mp3" "[Gary McTaggart] Considerata l'importanza di personaggi e oggetti fisici, pensavamo che solo un sistema di ombre dinamiche avrebbe permesso di renderizzarli in tutto il loro splendore. Nel 2003, le GPU non possedevano le funzionalità dedicate alle ombre di quelle odierne, per cui si presentava un problema di prestazioni. Alla fine, abbiamo optato per la seguente soluzione, eseguita a ogni frame. Prima, cercavamo tutti gli oggetti che potessero avere ombre visibili. Voleva dire individuare quali elementi fossero nel cono visivo o appena alle spalle, nel caso di entità che fossero fuori dallo schermo ma che avrebbero potuto proiettare ombre visibili. Quindi, renderizzavamo una versione nera di ciascun oggetto in una singola texture ombra. Per quel rendering usavamo il modello meno dettagliato possibile, per velocizzare il calcolo. Infine, usavamo la texture ombra per disegnare tutte le ombre nel campo visivo del giocatore, inscurendo i pixel già renderizzati. Ritagliavamo accuratamente ogni ombra della texture ombra, per assicurarci che combaciassero perfettamente nel caso di più ombre sovrapposte. È bello ripensare a come abbiamo risolto questi problemi, ma oggi lavoriamo decisamente meglio, con GPU che rendono tutto più semplice."
N/A4186"#commentary\cn_269_combinatorial_shader_explosion.mp3" "[Gary McTaggart] Durante lo sviluppo di Half-Life 2, il rendering è diventato molto più complesso per l'aggiunta degli shader hardware, piccole porzioni di codice che controllano il rendering di ogni pixel di una superficie. Nel 2003, gli shader erano più limitati di oggi: all'epoca di Half-Life 2 non prevedevano istruzioni condizionali e le dimensioni del codice erano stringenti. Questo significava non avere logiche di ramificazione if/else da adattare a varie condizioni, né shader di grandi dimensioni con ampi set di funzionalità. Inoltre, compilare shader specifici richiedeva troppo tempo, per cui dovevamo precompilarli. Per lavorare entro questi limiti, eravamo costretti a calcolare ogni possibile combinazione di shader e memorizzare ciascuna come shader a sé stante. Per esempio, se uno shader agiva su una superficie in base a una singola fonte di luce, serviva un altro shader se le luci erano due, un altro ancora per tre e così via. Ed era combinatorio: se quello shader supportava anche una mappa normale, servivano due versioni per ogni luce, una con mappa normale e una senza. Con funzionalità come la combinazione di texture, la colorazione a vertici, i riflessi speculari, il test alpha e altri tipi di illuminazione, per esempio direzionale, puntiforme o a spot, il numero di shader saliva alle stelle. A fine progetto, avevamo migliaia di shader. Poco dopo abbiamo pubblicato Lost Coast, aggiungendo il supporto all'HDR, che raddoppiava il numero di shader. Quando la compilazione degli shader sulle singole macchine degli sviluppatori è diventata troppo lenta, l'abbiamo distribuita sull'intera rete tramite VMPi. Avevamo anche una modalità di compilazione shader dinamica che riduceva i tempi, ma comportava scatti nel frame rate al momento di compilare uno shader."
N/A4187"#commentary\cn_270_gpu_wild_west.mp3" "[Jay Stelly] Durante lo sviluppo, abbiamo dovuto prendere delle decisioni per via dei requisiti minimi che avevamo stabilito, ossia la combinazione di CPU e GPU meno potente in grado di offrire una buona esperienza al giocatore. Nei primi anni 2000, la varietà di GPU era maggiore, con enormi differenze non solo di velocità, ma anche di approccio al rendering. All'epoca, tuttavia, non avevamo dati sull'hardware usato dagli acquirenti. Quali CPU e GPU avevano? Quanta RAM? Quale versione di Windows? Abbiamo contattato Microsoft, sperando avessero risposte a domande come \"Quante sono le schede DX7 in uso? O DX8?\". Purtroppo, neanche loro disponevano di dati. Rendendoci conto che rischiavamo di compiere scelte sbagliate per mancanza di informazioni, abbiamo sviluppato uno strumento di analisi che permettesse ai giocatori di comunicarci le loro specifiche hardware e lo abbiamo integrato nella prima versione di Steam. I dati si sono rivelati talmente utili che abbiamo deciso di renderli pubblici, lanciando il sondaggio hardware di Steam nell'aprile del 2003. Da allora, aiuta noi e, ci auguriamo, gli altri sviluppatori a prendere decisioni informate."
N/A4188"#commentary\cn_271_3d_skybox.mp3" "[Jay Stelly] Abbiamo sempre puntato a renderizzare un mondo che apparisse più grande dei limiti imposti dalle nostre mappe. In Half-Life 1, abbiamo usato una texture cubemap per consentire ai giocatori di vedere oltre l'area di gioco. In Half-Life 2, tuttavia, volevamo che la visuale sul mondo circostante fosse dinamica, non una texture statica. Il limite delle nostre mappe era di circa 800 metri per ogni dimensione, ma abbiamo scoperto di poter creare un mondo esterno molto più grande memorizzandolo in scala ridotta. Per riuscirci, abbiamo inventato il cosiddetto Skybox 3D. Si tratta di una piccola scatola nascosta nella mappa di gioco che contiene geometrie in scala 1:16. Al suo interno, un punto di riferimento corrisponde a un'origine nella mappa principale. Quindi, quando renderizziamo lo spazio esterno all'area di gioco, usiamo la geometria dello Skybox 3D, disposta in base al punto di riferimento e ingrandita sedici volte. Rendere uniforme la transizione di luci e nebbia dalla mappa principale allo Skybox non è stato facile, ma ha funzionato. Il risultato faceva apparire il mondo molto più grande e coinvolgente di quanto non fosse in Half-Life 1."
N/A4189"#commentary\cn_272_missing_material.mp3" "[Jay Stelly] Sin dalle prime fasi di sviluppo del nostro codice grafico di basso livello abbiamo capito che sarebbe stato difficile individuare i poligoni che non venivano renderizzati a causa di una texture mancante. In casi simili, il poligono lasciava il posto a uno spazio nero, che spesso passa inosservato nelle scene più buie. Per avere la certezza di individuare questo bug, abbiamo creato una texture di errore visivamente inconfondibile che veniva generata automaticamente in caso di mancato caricamento di una texture. Così è nata la famosa texture a scacchi viola e neri, ora nota anche all'infuori di Half-Life 2."
N/A4190"#commentary\cn_273_air_resistance.mp3" "[Jay Stelly] Una funzionalità importante che abbiamo dovuto inserire nel motore fisico di Half-Life 2 è stata la resistenza dell'aria. All'epoca, i motori fisici rallentavano gli oggetti in movimento usando una funzione generica di smorzamento. Tuttavia, si limitava a rimuovere energia in modo simmetrico. Per rendere più credibile il movimento, dovevamo simulare invece la resistenza dell'aria. Questo ci avrebbe permesso di riprodurre un comportamento asimmetrico, in cui l'entità del rallentamento dell'oggetto che si sposta nell'aria varia in base a quanta superficie dell'oggetto stesso è rivolta nella direzione del movimento o della rotazione. Questa funzionalità era cruciale per rendere credibili le esplosioni e gli oggetti lanciati dalla pistola gravitazionale. Gli oggetti che si muovono o ruotano ad alta velocità sono i più complessi da simulare per il motore fisico di Half-Life 2. Di conseguenza, la resistenza dell'aria migliora anche le prestazioni della CPU nel gestire eventi come le esplosioni. È fondamentale anche per rappresentare le differenze di massa e materiali degli oggetti. Corpi più densi spostano più aria, ed è visibile. La presenza di questo effetto in una simulazione evidenzia la differente densità di una scatola di cartone e di un'asse di legno, e aumenta la credibilità degli oggetti del mondo di Half-Life 2."
N/A4191"#commentary\cn_274_early_tech_planning.mp3" "[Ken Birdwell] Completare lo sviluppo di un gioco ti insegna sempre molto: scopri quali scelte si sono rivelate efficaci e dove invece avresti dovuto procedere diversamente. Dopo Half-Life 1, quando abbiamo iniziato a ragionare su che tipo di sequel realizzare, avevamo molti feedback dei giocatori da valutare. Da lì, abbiamo tentato di stilare un elenco di priorità per Half-Life 2. Invece di provare a progettare un determinato tipo di esperienza, abbiamo preferito approcciare la questione da un punto di vista tecnologico. Le guardie e gli scienziati di Black Mesa avevano funzionato bene. Cosa avremmo potuto ottenere puntando ancora di più sui personaggi? Eravamo orgogliosi della nostra narrazione interattiva. Cosa avremmo potuto creare per sfruttarla ancora di più e con maggiore varietà? L'esplorazione e l'interazione all'interno di Black Mesa erano state molto coinvolgenti per i giocatori. Forse un sistema di fisica ci avrebbe permesso di spingerci oltre? In tutti questi ambiti, abbiamo provato a immaginare la possibile evoluzione da lì a qualche anno, per poi procedere a ritroso nello sviluppare le tecnologie necessarie a raggiungerla."
N/A4192"#commentary\cn_275_character_lighting.mp3" "[Ken Birdwell] Nel primo anno di sviluppo, abbiamo incontrato difficoltà a creare personaggi sufficientemente realistici. Dipendeva da problemi di vario tipo, ciascuno dei quali è stato risolto con specifiche soluzioni tecnologiche e artistiche. Il primo grande problema era l'illuminazione. All'epoca, l'illuminazione dei giochi ricorreva a molte scorciatoie, alcune dovute alle prestazioni, ma molte riconducibili alla scarsa comprensione del suo funzionamento. In quegli anni, per ottenere una buona resa estetica dei personaggi, i modelli e le texture dovevano integrare al loro interno gran parte delle soluzioni di illuminazione, come ombre e riflessi. I personaggi erano di impatto, ma la loro estetica era tipicamente da videogioco. Abbiamo iniziato a lavorare su Alyx con questo approccio, perché avevamo sempre fatto così. Abbiamo usato le soluzioni integrate e l'abbiamo illuminata come un'attrice di cinema: in pratica, come se avesse avuto un impianto luci che la seguiva ovunque, facendola sempre apparire al meglio. Ma non funzionava. A causa dei diversi contesti di illuminazione e della natura dinamica dei videogiochi, la sua resa era perfetta in alcuni ambienti, ma terribilmente inverosimile in altri. Abbiamo provato a intervenire sulle sue luci, ampliandone le capacità, ma ci sentivamo in un vicolo cieco. Ripartendo da capo, abbiamo deciso di cambiare approccio. Abbiamo ricreato lei, le luci e le texture da zero, gettando via tutto. Non ci siamo concentrati sull'aspetto che avrebbe dovuto avere sotto la luce ideale, ma su come avrebbe dovuto funzionare nel mondo reale. Può sembrare ovvio, ma allora non si ragionava in questi termini, almeno nei videogiochi. Visti all'esterno del rendering del gioco, texture e modelli nuovi sembravano peggiori dei precedenti. Ma eravamo riusciti a rimuovere sistematicamente tutti gli errori concettuali e le scorciatoie sul funzionamento di luci, texture e schede grafiche, per poi rimettere tutto insieme. Al termine di questo processo, quando abbiamo finalmente visto Alyx nel gioco, realizzata con nuovi modelli e texture, in un ambiente dinamico che la faceva sempre apparire visivamente coerente, beh... era perfetta. Era parte integrante del mondo di Half-Life 2."
N/A4193"#commentary\cn_276_gamma_correction.mp3" "[John Morello] Il nostro motore di gioco include un sistema di rendering che prende l'intero stato del gioco e lo rappresenta calcolando un valore cromatico per ogni pixel sullo schermo. Tuttavia, nel calcolo di quei pixel vengono coinvolti anche codici e software di altre persone. Per esempio, il software e l'hardware della GPU e del monitor in uso. A un certo punto dello sviluppo, non eravamo soddisfatti dell'aspetto dei personaggi. Sembravano troppo pallidi, quasi malaticci. La pelle non andava bene. Abbiamo provato a correggere le luci, ma non riuscivamo a rendere convincenti i personaggi e il mondo di gioco insieme. Per fortuna, avevamo ancora un software di rendering completo, che ci permetteva di eseguire il gioco senza una GPU, perché all'epoca molti giocatori non ne avevano una. Osservando il gioco su quel renderer, abbiamo notato che la nostra illuminazione non presentava lo stesso problema. Quindi, abbiamo scandagliato il codice per capire dove sbagliasse quando lavorava con una GPU. Non abbiamo trovato nulla, così abbiamo interpellato i produttori delle GPU, chiedendo loro di verificare che le schede non sbagliassero qualcosa con i valori dei pixel che gli passavamo. Quello è stato l'inizio di un lungo viaggio... Per farla breve, sono serviti due anni di botta e risposta con i produttori di GPU per convincerli che avevano implementato la correzione di gamma in modo errato nella matematica di basso livello delle loro schede. Nel frattempo, avevamo persino costruito un sistema che verificava i valori cromatici di un singolo pixel nel corso dell'intero processo di rendering. Alla fine, siamo riusciti a ottenere dei nuovi driver dai produttori e i nostri personaggi hanno subito ritrovato l'aspetto giusto, come nel software di rendering."
N/A4194"#commentary\cn_277_facial_technology.mp3" "[Ken Birdwell] Volevamo far affezionare i giocatori ai nostri personaggi, e l'unico modo possibile per riuscirci era investire molta tecnologia sui volti. È risaputo che gli umani sono programmati per prestare attenzione ai volti, traendone inconsciamente informazioni di ogni tipo. Era un obiettivo estremamente ambizioso e, se l'avessimo fallito, avremmo probabilmente allontanato i giocatori dai nostri personaggi invece che avvicinarli. Abbiamo iniziato svolgendo ricerche approfondite. Non è stato incoraggiante. I primi esempi che abbiamo trovato non erano nemmeno vicini a poter essere riprodotti in tempo reale, mentre i migliori risultati in tempo reale erano distanti dalla qualità a cui puntavamo. Volevamo la stessa qualità dei film animati, che tuttavia richiedevano ore per il rendering di ogni fotogramma ed erano esperienze lineari e curate da più di cento animatori, mentre un gioco è dinamico: un personaggio può dover recitare una frase con un'espressione facciale assunta in risposta alle azioni del giocatore e creata da una manciata di grafici. Queste considerazioni ci hanno infine condotti al sistema di codifica delle espressioni facciali del dottor Paul Ekman, un sistema per la tassonomizzazione dei movimenti del volto umano risalente agli anni '70. Ci forniva un vocabolario con cui descrivere le espressioni tramite i nostri strumenti di programmazione e un obiettivo a cui puntare nel realizzare i volti dei personaggi. Con questo riferimento, abbiamo iniziato un lavoro pluriennale di sperimentazione sulla costruzione dei volti. Laddove altri avevano preso spunto dal lavoro di Ekman, noi volevamo provare ad applicarlo in toto. Questo significava dedicare parecchio tempo a capire come realizzare ogni elemento entro i nostri rigidi limiti tecnici. Abbiamo anche studiato a lungo le persone e i loro volti, alla ricerca dei tratti che avrebbero aggiunto più valore, come l'elasticità della pelle o le ombre sui denti. Alla fine, pur non avendo raggiunto tutti gli obiettivi prefissati, siamo riusciti a mettere a punto gli strumenti più importanti per rendere convincenti le espressioni facciali dei nostri personaggi."
N/A4195"#commentary\cn_278_eye_shader.mp3" "[Ken Birdwell] Un altro aspetto fondamentale per rendere convincenti i volti dei personaggi risiede negli occhi. Gli esseri umani sono molto bravi a leggere lo sguardo. Abbiamo una porzione del cervello dedicata, al punto da poter capire dove qualcuno sta guardando in base ai riflessi sulle sue pupille. Sono moltissimi i dettagli che fanno la differenza. Gli occhi non sono sfere perfette. Le palpebre vengono distorte dalla cornea che si muove sotto di esse. Il movimento dell'occhio aumenta la probabilità di sbattere le palpebre. E gli occhi non sono perfettamente allineati dietro le pupille, ma leggermente sfalsati. Tutti questi dettagli possono sembrare minuscoli, o impercettibili, ma la loro assenza mina la credibilità del personaggio. Abbiamo lavorato sugli occhi per molto tempo, migliorando progressivamente i nostri modelli di bulbi oculari e le loro caratteristiche. Alcuni aspetti hanno richiesto interfacce esterne, come stabilire quali oggetti dell'ambiente fossero interessanti da guardare. Altri erano automatici, a livello inconscio dell'IA, come sbattere le palpebre: un gesto banale, ma che può disorientare se mal eseguito. I riflessi sugli occhi avevano un impatto notevole: occupano uno spazio minimo sullo schermo, ma fanno un'enorme differenza. Abbiamo capito di avercela fatta quando siamo giunti al punto in cui, disattivando gli shader degli occhi, un personaggio sembrava un manichino, realistico ma poco convincente per motivi difficili da descrivere, per poi tornare di colpo umano non appena li riattivavamo."
N/A4196"#commentary\cn_279_combine_gunship.mp3" "[Ken Birdwell] Il gunship ha rappresentato un problema stimolante. Disponevamo già di un modello di volo per elicotteri e non c'era tempo per realizzare qualcosa di completamente nuovo. Quindi, abbiamo modificato il modello per elicotteri finché non ci è sembrato abbastanza diverso, poi abbiamo ricavato gli stati di animazione organici del gunship dai valori prodotti da quella simulazione. Abbiamo anche provato a renderlo il più autentico possibile. Per esempio, c'è un limite a quanto possa ruotare il muso quando mira con il cannone, superato il quale è costretto ad alterare la traiettoria di volo per allineare l'arma al bersaglio. Non volevamo barare. Un altro aspetto cruciale era il rumore del motore. Il nostro audio è spazializzato, in modo che il giocatore possa intuire dove si trovi il velivolo. Ma il gunship si muove velocemente, e per di più in cielo, lontano da punti di riferimento certi. Pertanto, può essere difficile intuire quanto sia distante e a che velocità proceda. Per risolvere, abbiamo aggiunto un effetto Doppler al rumore del propulsore, modificandone la tonalità in base alla velocità del gunship in relazione al giocatore. È un dettaglio, ma è estremamente efficace a livello inconscio per aiutare a percepire la posizione e la direzione del gunship, informazioni preziose per capire se ti è addosso."
N/A4197"#commentary\cn_280_risk.mp3" "[Ken Birdwell] Ripensando a Half-Life 2 ora, a distanza di 20 anni, fa riflettere come il suo sviluppo sia stato in gran parte terrificante. Creare giochi è difficile. Non ottieni mai ciò che vorresti, ossia sapere i rischi a cui vai incontro prima di correrne altri. Per esempio, la nostra tecnologia di animazioni facciali. Sono serviti tre o quattro anni di lavoro prima di avere la certezza che funzionasse. Ma non potevamo attendere tanto. Nel primo anno, abbiamo subito iniziato a prendere altre decisioni riguardo al design di gioco, alla produzione di risorse e ad altre tecnologie, tutte basate sul presupposto che la tecnologia di animazione facciale avrebbe funzionato, da un punto di vista qualitativo e prestazionale. Se ciò non fosse avvenuto, molte altre scelte si sarebbero rivelate fallimentari. Lo stesso profilo di rischio vale per altre scelte fondamentali fatte in precedenza. Non possiamo aspettare, dobbiamo andare avanti e sperare che le nostre intuizioni si rivelino corrette, ad anni di distanza. È terrificante."
N/A4198"#commentary\cn_281_hugs_and_pickups.mp3" "[Ken Birdwell] A volte, anche i dettagli possono rivelarsi un incubo da risolvere. Per esempio, mettere in scena un abbraccio tra due personaggi o anche solo raccogliere un oggetto da un tavolo può creare parecchi problemi. Quel che è peggio, nel nostro ambiente dinamico, in cui personaggi e oggetti non sono in posizioni prefissate, e il giocatore è libero di muoversi ovunque, è necessario raggiungere un livello di sincronizzazione piuttosto complesso. Ed è ancora più difficile perché una persona compie questi gesti senza pensarci. Mentre ti avvicini al tavolo per prendere una tazza, il tuo corpo assume una determinata postura con piedi e mani per rendere agevole il gesto. Quando arrivi, è tutto pronto. Se due persone si avvicinano per abbracciarsi, agiscono contemporaneamente, apportando correzioni continue in risposta ai movimenti altrui. Per riprodurre tutto questo in un videogioco è necessario un grande lavoro di sincronizzazione, affinché ogni personaggio abbia consapevolezza dell'altro e del mondo circostante. Al contempo, devi fare in modo che conoscano le loro intenzioni future. Sarebbe bello poter suddividere l'esempio della tazza in una serie di passaggi, come camminare verso il tavolo, rivolgersi verso la tazza e raccoglierla. Sarebbe molto più semplice e renderebbe ogni passaggio riutilizzabile. Ma i robot si comportano così, non le persone. I nostri personaggi dovevano sapere che si stavano avvicinando al tavolo con l'obiettivo di raccogliere una tazza, in modo da coinvolgere più parti del corpo ed essere sicuri che la mano fosse pronta ad afferrare la tazza nel momento giusto. Con due personaggi, la coordinazione richiesta è ancora maggiore. Entrambi devono concordare il dove e il quando dell'abbraccio e tutto deve svolgersi senza interruzioni. Anche se queste interazioni tra personaggi all'interno del gioco sono spesso brevi, sono fondamentali per renderli credibili."
N/A4199"#commentary\cn_282_ropes.mp3" "[Mike Dussault] Un aspetto che ci ha colpiti delle immagini di riferimento che abbiamo raccolto per City 17 era la presenza di cavi e fili ovunque, e di come rappresentassero uno dei dettagli più visibili e frequenti. Ci piaceva l'aspetto di queste antiche città europee avvolte da una disordinata ragnatela di modernità. Ci serviva una soluzione per gestire cavi, funi ed elementi simili, e volevamo che fosse dinamica. I designer dei livelli non vedevano l'ora di creare enigmi basati sulle prese elettriche, e connettere i cavi alle prese aiutava i giocatori a comprendere queste meccaniche. A inizio progetto abbiamo realizzato un sistema di funi, per poi migliorarlo nel corso dello sviluppo. Dietro le quinte, ogni fune è composta da segmenti tesi tra le due estremità e dotati di mobilità indipendente. Ogni segmento agisce come una molla e risponde alle forze nel gioco, come una lieve brezza o il passaggio in volo di un gunship Combine. Quando viene renderizzato, ogni segmento è rivolto verso la visuale e dotato di mappatura bump, fondamentale per dare alle funi un aspetto arrotondato e realistico."
N/A4200"#commentary\cn_283_vmpi.mp3" "[Mike Dussault] Durante lo sviluppo, eravamo frustrati dalla lentezza dei progressi nelle meccaniche di gioco, soprattutto perché la compilazione delle mappe, necessaria per precalcolare luci e visibilità, richiedeva ore. I computer degli anni 2000 erano molto più lenti di quelli odierni e avevano CPU con un solo core. Prendendo ispirazione da SETI@Home, un programma di distribuzione che usava i PC di tutto il mondo per analizzare onde radio alla ricerca di tracce di vita aliena, abbiamo realizzato VMPi, un nostro sistema distribuito che ripartiva il processo di compilazione delle mappe tra diversi computer dell'ufficio. Oggi, questi sistemi distribuiti vengono eseguiti su enormi cluster di GPU, ma all'epoca eravamo limitati ai computer aziendali. Considerato che il codice dell'illuminazione si evolveva con la stessa rapidità delle nostre mappe, VMPi distribuiva anche nuovi file .exe a tutti i computer. Con il senno di poi, era un concetto terrificante dal punto di vista della sicurezza, davvero terribile, l'incubo di qualsiasi tecnico IT. Inviavamo un semplice eseguibile a tutti i PC dell'azienda, che lo avviavano senza troppe storie. Una vera follia. Ma ha funzionato e ha accelerato notevolmente il lavoro sulle mappe, dimostrandosi uno strumento essenziale."
N/A4201"#commentary\cn_284_field_of_view.mp3" "[Kerry Davis] In Half-Life 1 abbiamo usato un campo visivo di 90 gradi, un valore standard per gli sparatutto in soggettiva dell'epoca. Durante lo sviluppo di Half-Life 2, tuttavia, non ne eravamo soddisfatti. I personaggi avevano un ruolo centrale nel gioco, e avevamo lavorato molto per ottenere animazioni dettagliate del viso e del corpo, ma il campo visivo di 90 gradi non permetteva ai giocatori di avvicinarsi abbastanza per apprezzare quei dettagli. Abbiamo quindi iniziato a sperimentare un campo visivo più stretto, scendendo fino a 75 gradi. Ha richiesto un periodo di adattamento tanto per noi quanto per i giocatori, e ha imposto un campo visivo diverso per le armi del giocatore, poste alla base dello schermo. Erano state modellate tenendo i 90 gradi come riferimento, per cui a 75 apparivano deformate. Questa modifica, comunque, ha ottenuto il risultato sperato: mettere i personaggi al centro del gioco."
N/A4202"#commentary\cn_285_reference_maps.mp3" "[Randy Lundeen] Così come i nostri personaggi erano diventati più realistici da Half-Life 1 a Half-Life 2, volevamo che lo stesso avvenisse con il mondo di gioco. In Half-Life 1, le limitazioni dei giochi in soggettiva imponevano spesso di puntare su ambienti stilizzati o astratti. Con Half-Life 2, invece, abbiamo scelto di creare luoghi ispirati al mondo reale. Questo significava concentrarsi su una miriade di dettagli che prima non c'erano. Un passaggio fondamentale è stato creare mappe di riferimento per standardizzare il modo in cui avremmo mappato le proporzioni del mondo reale nel gioco. Queste mappe definivano dettagli come le dimensioni di muri e porte, l'altezza delle maniglie, l'illuminazione interna, le proporzioni dei mobili e la scala degli oggetti comuni. Abbiamo creato texture standardizzate per i designer dei livelli, comprensive di valori di scala e di illuminazione, affinché le planimetrie fossero coerenti fin dall'inizio. Oltre a impostare il mondo fisico, queste mappe definivano come il giocatore si sarebbe mosso al suo interno: quanto in alto poteva saltare, quanto in basso accucciarsi e le dimensioni di spazi come i condotti dell'aria. Usando queste mappe come punto di partenza, siamo riusciti a mantenere coerente la geometria del mondo e a creare spazi di dimensioni realistiche in tutto il gioco."
N/A4203"#commentary\cn_286_response_rules.mp3" "[Scott Dalton] Sapevamo fin dall'inizio che avremmo inserito molti dialoghi dinamici nel gioco, per questo ci serviva un sistema in grado di gestirli. Doveva permettere ai designer audio di aggiungere e modificare le battute senza l'aiuto dei programmatori, rendendo i dialoghi reattivi al contesto di gioco e riducendo al minimo le ripetizioni. Da questi requisiti è nato il sistema di regole di risposta. Quando un personaggio parla al di fuori di una scena coreografata, questo strumento determina quale battute riprodurre. Invece di selezionare direttamente le frasi, l'IA del personaggio segnala \"opportunità di dialogo\" quando si verifica un evento rilevante: avvistare il giocatore, subire una ferita, sparare l'ultimo proiettile, affrontare nemici più forti e così via. A ogni opportunità, invia al sistema di regole di risposta un pacchetto di dati sullo stato attuale del gioco, in base al quale il sistema restituisce la battuta più adatta, se esiste. Questo impianto ha permesso ai nostri designer audio di creare una matrice dettagliata di scelte per i dialoghi. Per esempio, un personaggio può avere varie frasi da pronunciare quando ricarica sotto il fuoco nemico, dopo la fine di uno scontro, se resta un solo alleato in vita o se c'è uno strider in vista. Quando è uscito Half-Life 2, sentivamo di aver appena scalfito la superficie del potenziale di questo sistema. È poi diventato una funzionalità centrale della Alyx di Episode 1 e ha reso possibili i dialoghi dinamici dei nostri giochi successivi, tra cui le classi di TF2 e il cast di Left 4 Dead."
N/A4204"#commentary\cn_287_audio_caching.mp3" "[Yahn Bernier] Un altro problema in cui siamo incappati è la mole impressionante di audio presente nel gioco. Tra gli effetti, la musica e i dialoghi, l'audio era troppo per essere archiviato in memoria. La memoria era un bene prezioso nel 2003. Chiaramente, la riproduzione dei suoni doveva essere immediata, soprattutto quelli legati all'azione di gioco. Così, abbiamo creato una cache audio in cui erano archiviati solo i primi 125 ms di ogni file audio, da tenere in memoria. Quei 125 ms era il tempo che ipotizzavamo servisse per fare lo streaming di un file audio dal disco. Quindi, ogni volta che un suono veniva emesso nel gioco, riproducevamo l'inizio dalla nostra cache audio, avviando al contempo il caricamento del file audio completo dal disco. Una volta esaurita la cache, avremmo avuto il file caricato in memoria, pronto a completare la riproduzione del suono. C'erano anche altri piccoli accorgimenti, come tenere in memoria la versione completa dei suoni recenti, per non dover caricare continuamente quelli più frequenti. Nei motori di oggi si ricorre a una strategia simile per qualunque risorsa, non solo i suoni."
N/A4205 
39234206}
39244207}