Template:PatchDiff/March 6, 2026 Patch/hl2/resource/closecaption portuguese.txt
39153915"wood.scraperough" " "
39163916"plastic_box.scraperough" " "
39173917
N/A3918"#commentary\cn_001_physics_sound.mp3" "[ Jay Stelly ] Para que as leis da física parecessem corretas para o jogador, os sons produzidos pela física também tinham de soar naturais. Enquanto humanos, estamos habituados ao som de objetos e materiais em todo o tipo de interações, mesmo que não seja consciente. Apesar de sabermos que não podíamos contabilizar tudo, queríamos concentrar-nos nos detalhes que mais contribuíam para tornar as leis da física realistas. Começámos pelos sons dos objetos em colisões e impactos. Desta forma, um objeto, como uma caixa de madeira, teria sons únicos ao colidir com outros objetos ou classes de objetos. Depois, começámos por alterar estes sons de forma dinâmica com base nas características de um evento físico, como as massas envolvidas e a força da colisão. Isto funcionou bem para as colisões, mas não noutras interações, como objetos a raspar uns nos outros. Na realidade, uma caixa de madeira faz um som diferente quando raspa numa parede ou quando é atirada contra a mesma parede. Posso dizer que ninguém fez mais pesquisas sobre as nuances das propriedades físicas de uma caixa de madeira do que nós. Para obtermos o que pretendíamos nestas interações, implementámos sons de colisão por material: metal contra madeira, metal contra metal e por aí adiante. Estes sons também foram alterados de forma dinâmica com base em detalhes, como a dureza do material ou o tipo de metal. Para que o sistema produzisse sons corretos, tivemos de fazer vários pequenos ajustes que só conseguimos identificar depois de estar tudo a funcionar. Também testámos sons personalizados para objetos que rebolavam, mas acabámos por descontinuar essa funcionalidade porque não ficámos satisfeitos com os resultados."
N/A3919"#commentary\cn_002_ramming_with_the_buggy.mp3" "[ Jay Stelly ] O nosso sistema de física baseia-se em corpos rígidos. Ou seja, não suporta deformações ou a destruição de objectos. Se um objeto físico for atingido, pode mover-se se puder. Caso contrário, não acontece nada. Por isso, quando o jogador conduz o buggy por uma janela de vidro, temos de usar alguns truques para fazer com que tudo funcione como esperado. Como a janela está fixa, na realidade, a simulação física vai fazer com que o buggy faça ricochete na janela, mas notifica o sistema que aconteceu uma colisão. O sistema de jogo gere a destruição, parte a janela em pedaços de vidro e indica ao sistema de física para começar a simular os pedaços. Também importante, o sistema indica ao sistema de física para repor o buggy onde estava antes da colisão. Desta forma, na próxima vez que o sistema simular a física, o buggy vai atravessar a janela já destruída. Este processo cria um solavanco de um frame na física do buggy, já que o buggy tem de parar e ser teletransportado para o instante anterior ao impacto. Pedimos desculpa se esta revelação estragou o Half-Life 2, mas depois de termos visto os testes na altura, concluímos que até gostámos do solavanco. Aumentou a sensação de impacto."
N/A3920"#commentary\cn_003_ramming_zombies_with_the_buggy.mp3" "[ Jay Stelly ] Enquanto seres humanos, temos expectativas para o nosso mundo físico, como referimos algumas vezes neste comentário. Uma dessas expectativas é que se atropelarmos um zombie, este deve sair disparado pelo ar. Mas conseguir este efeito no jogo não é tão simples como na vida real. Por motivos de desempenho, os inimigos como o zombie têm uma caixa de colisão simplificada. É uma caixa que envolve o zombie, sem ter partes do modelo fora dela. Mas, quando o zombie morre, ele é convertido num boneco com caixas de colisão por membro mais precisas, apesar de isto usar mais recursos para simular. Esta alteração na representação da colisão dá uma maior complexidade quando atropelamos um zombie com o buggy, para além de influenciar os frames. Quando o buggy toca pela primeira vez no zombie, toca na caixa de colisão simplificada dele. É assim que o jogo mata o zombie, transformando-o num boneco que o sistema de física começa a simular. Com as colisões mais precisas por membro, a parte mais próxima do zombie pode ficar a vários centímetros do buggy. Assim, da próxima vez que o sistema de física criar uma simulação, o zombie começa a cair por causa da gravidade, porque o buggy já não o está a empurrar. Apesar de demorar muito pouco tempo para o buggy voltar a atingir o zombie, esta discrepância tornou a colisão com zombies estranha, já que caíam para fora da vista do jogador. Para corrigir isto, mantivemos a força que a caixa de colisão do zombie sofria quando é atingido pelo buggy e aplicámos essa mesma força ao boneco depois da conversão. Também acrescentámos uma pequena força ao boneco para lançá-lo para cima. Com estes ajustes, os zombies passaram a dobrar de forma credível sobre o capô do buggy e isso correspondeu às expectativas dos jogadores."
N/A3921"#commentary\cn_004_buggy_sound_engine.mp3" "[ Kelly Bailey ] O áudio do buggy foi complicado porque queríamos que parecesse que tinha muita potência a alta velocidade, mesmo que os mapas não fossem suficientemente grandes para isso e o buggy não saísse da primeira velocidade. E tem uma velocidade máxima de cerca de 55 km/h. Em nossa defesa, 55 km/h é rápido, especialmente em 2004. Para além da velocidade, o controlo era muito simples. Por isso, com um teclado como forma de controlo, os comandos do jogador são basicamente binários. Ou seja, o buggy está a acelerar ou não, está a virar todo numa direção ou não. Essencialmente, tivemos de criar esta complexidade no áudio para representar uma simulação que não a tinha. Portanto, construímos um motor falso para o áudio do buggy. Tem a sua própria transmissão e combinamos os controlos dos jogadores com os dados da simulação de física. Medimos o binário em cada roda simulada, a rodar ou a fazer contacto, e criámos um conjunto de sons em loop que depois misturámos enquanto o motor falso mudava de velocidade e respondia aos dados das rodas. E continuámos a experimentar outras coisas. Acrescentámos mais complexidade. Fizemos pequenos ajustes até que o buggy fosse mais divertido e transmitisse a sensação de velocidade. E a maioria dos jogadores não disse nada sobre isso, só que o buggy soava bem. Para nós, isso foi um sucesso, dada a quantidade de loucuras que aconteciam debaixo do capô."
N/A3922"#commentary\cn_005_buggy_sound_design.mp3" "[ Kelly Bailey ] Os sons do buggy foram inspirados em amostras de um Camaro de 1968. Escolhemos este carro porque tem um incrível motor V8 com pistões enormes. Não há som que se compare. Era o som visceral e de certo modo \"corajoso\" que procurávamos. A transmissão também tem um zumbido mecânico maravilhoso quando paramos de acelerar. E esta combinação parecia ideal para o sistema de controlo binário com o qual tivemos de trabalhar. A transmissão do motor falso não foi criada com base num carro real. Em vez disso, foi concebida como um sistema simples para recompensar o jogador por manter o acelerador a fundo. É como uma escada rolante interminável que produz um som crescente, criando constantemente tensão e mudando de velocidade sempre que o tom tem de reiniciar. Como os jogadores ficavam sem espaço num instante nos mapas que eram relativamente pequenos, o objetivo foi só tornar a aceleração divertida durante um curto período de tempo."
N/A3923"#commentary\cn_006_automating_dsp.mp3" "[ Kelly Bailey ] Todos os sons que o jogador ouve são processados pelo sistema Digital Signal Processing ou DSP. Isto refere-se apenas à forma como o áudio sofre alterações para refletir o ambiente em que o jogador se encontra. Por exemplo, o mesmo som é diferente dependendo de se é ouvido numa garagem, numa divisão pequena ou ao ar livre. No Half-Life 1, espalhámos nós invisíveis no mundo do jogo para definir estas definições de DSP para cada espaço. Para o Half-Life 2, sabíamos que o posicionamento manual seria muito demorado, especialmente porque queríamos criar um jogo maior e continuávamos a ter apenas um responsável pelo áudio na equipa. Por isso, construímos um sistema que determina automaticamente e em tempo real as definições de DSP em torno do jogador. O sistema analisa o espaço ao redor do jogador, avalia a volumetria em que se encontra e examina os materiais que compõem o ambiente, basicamente. Em seguida, o sistema faz corresponder o espaço a um dos 25 tipos básicos de DSP criados manualmente. Ajustamos alguns parâmetros e criamos o DSP detalhado que modifica os sons que o jogador ouve."
N/A3924"#commentary\cn_007_dynamic_mixing.mp3" "[ Kelly Bailey ] Durante o jogo, ouvem-se muitos sons ao mesmo tempo, mas alguns são naturalmente mais importantes e temos de definir os volumes relativos para garantir que os mais importantes se destacam. Num filme, esta mistura é feita no pós-processo. Porém, num jogo, isto acontece em tempo real, respondendo às ações dos jogadores. Por isso, não podemos prever quais os sons que serão reproduzidos em simultâneo. Para resolver esta situação, todos os sons são agrupados por tipo e marcados com prioridades. Enquanto se joga, o sistema de áudio monitoriza todos os sons ativos e diminui o volume de um grupo de sons se estiver a ser reproduzido um som com prioridade maior. Esta mistura é ajustável. Se os tiros tiverem de ser ruidosos numa cena, podemos dar-lhes mais prioridade. Se uma linha específica de diálogo tiver de ser ouvida, reduzimos o volume dos outros sons. E o mesmo acontece com a música. É um sistema subtil, mas essencial, que evita que a paisagem sonora fique confusa."
N/A3925"#commentary\cn_008_soundscapes.mp3" "[ Kelly Bailey ] No Half-Life 1, os sons ambiente eram colocados manualmente e ajustados individualmente mais tarde. No Half-Life 2, queríamos ter mais sons ambiente nos cenários, com maior qualidade e menos esforço manual em termos de posicionamento. Por isso, criámos um sistema chamado \"sistema de paisagens sonoras\". Uma paisagem sonora é basicamente um pequeno programa que controla os sons ambientes que devem ser reproduzidos, de onde vêm e como se comportam num dado ambiente. Moscas a zumbir, vento a soprar, pássaros, um comboio ao longe, um combate distante. Depois, o sistema de paisagens sonoras podia selecionar e reproduzir aleatoriamente estes sons e, igualmente importante, criar uma transição suave quando um jogador se movia pelos cenários. As paisagens sonoras podem também ter paisagens sonoras secundárias e isso permitiu criar coleções reutilizáveis de sons. Por exemplo, um combate distante pode incluir fogo de armas de pequeno porte, explosões distantes ou um helicóptero a passar. Estas paisagens sonoras seriam montadas e reproduzidas de forma dinâmica a partir de muitos sons individuais e isto ajudou-nos a evitar aquela sensação artificial de ouvir uma única faixa interminável. O sistema de paisagens sonoras foi um verdadeiro cavalo de batalha no áudio do Half-Life 2 e praticamente responsável por todos os sons que escutamos que não estão diretamente ligados à jogabilidade."
N/A3926"#commentary\cn_009_audio_over_distance.mp3" "[ Kelly Bailey ] Os espaços em grande escala nos mapas da Costa obrigaram-nos a procurar uma solução de áudio para a forma como o som sofre com a distância. Por exemplo, nestes mapas, se um inimigo estiver a mais de 100 metros de distância, a sua arma tem de ter um som diferente a essa distância do que se estiver perto. Decidimos guardar os sons num único ficheiro estéreo, com o som próximo no canal esquerdo e o distante no canal direito. Depois, durante a reprodução, criávamos um crossfade ou alterávamos a proporção do som a ouvir entre os dois canais, dependendo da distância do jogador ao som. Foi uma solução simples e que funcionou bem. Foi útil devido às restrições de memória. É fácil escutar. Basta ouvir como os disparos de um soldado dos Combine mudam conforme nos aproximamos dele."
N/A3927"#commentary\cn_010_flying_vehicle_audio.mp3" "[ Kelly Bailey ] Os grandes inimigos voadores do jogo foram um desafio sonoro único. Durante combates, são muito mais móveis do que outros inimigos e costumam afastar-se bastante do jogador. Também são muito perigosos se tiverem uma linha de mira. Estes fatores obrigaram-nos a encontrar uma solução de áudio específica em torno da oclusão. Ou seja, quando o jogador consegue ver o inimigo e quando o inimigo vê o jogador. Queríamos criar uma distinção clara de áudio quando há esta linha de visão. Os sons do motor da aeronave são compostos por muitos sons em loop que reproduzimos em simultâneo. Alguns dos loops são processados pelo sistema DSP dependendo do espaço onde está, enquanto outros são reproduzidos diretamente e sem serem processados. O sistema DSP adiciona mais um efeito de eco ambiente quando executamos o som através deste sistema. Quando a aeronave está atrás de alguma coisa e não consegue ver o jogador, aumentamos a percentagem de loops que passam pelo processamento do DSP para soar como se o objeto estivesse mais distante. Desta forma, quando o inimigo surge de trás de um objeto e vê o jogador, reproduzimos mais o som direto. No geral, isto dá a sensação que o som está longe e sem direção ou mais diretamente na linha de visão do jogador. Conseguimos ouvir quando o helicóptero surge de trás de um edifício. Idealmente, o jogador consegue mesmo ouvir essa diferença."
N/A3928"#commentary\cn_011_bullet_audio.mp3" "[ Kelly Bailey ] Se há algo do qual temos a certeza é que muitas balas passam a voar pelo jogador ao longo do jogo. Por isso, dedicámos muito tempo a aperfeiçoar o áudio para estas situações. Infelizmente, como as balas são praticamente instantâneas, não podemos simplesmente dar-lhes um som e confiar no movimento para o posicionamento. Após várias experiências, chegámos a uma solução. Ao descobrir o ponto mais próximo na trajetória da bala do ouvido do jogador, calculámos o tempo e a posição em que a bala passaria. Assim, tocámos dois sons diferentes nesse ponto para simular um efeito Doppler. Um para a aproximação da bala e outro para o afastamento. Atrasámos o som de afastamento com base no tempo calculado da passagem da bala."
N/A3929"#commentary\cn_012_staircase.mp3" "[ Aaron Seeler ] Há situações no jogo que partem de objetivos de design simples e diretos. Esta escada apresenta dois deles. O primeiro era enquadrar a Cidadela enquanto despertava para mostrar ao jogador que tinham agitado a colmeia. O segundo era apresentar o sistema de bonecas de trapos. Embora seja algo normal agora, em 2004 era uma novidade ver corpos cair de forma realista. E as escadas eram o cenário perfeito para demonstrar isso."
N/A3930"#commentary\cn_013_alyx_and_mossman.mp3" "[ Bill Fletcher ] Nos planos iniciais da narrativa do Half-Life 2, quisemos assumir o desafio de criar algo menos focado de forma explícita no jogo. Não queríamos criar uma simples história sobre um jogador que era obviamente bom e que teria de derrotar os inimigos que são obviamente os maus. Em vez disso, tentámos focar-nos nas personagens e nas suas relações. Pensámos que seria interessante explorar a família como a unidade dinâmica central do Half-Life 2. A tensão entre Alyx e Mossman surgiu dessa ideia, e gostámos dela porque parecia identificável. Algo que os jogadores pudessem compreender e com o qual pudessem empatizar."
N/A3931"#commentary\cn_014_exposition_board.mp3" "[ Danika Rogers ] Queríamos colocar aqui esta parte complexa de história visual porque é o momento em que o jogo é mais explícito ao pedir aos jogadores para explorarem um espaço. Embora a função principal seja a construção do mundo, também nos esforçamos por destacar a relação entre Eli e Breen, contextualizando o conflito central do mundo."
N/A3932"#commentary\cn_015_city_17_awakens.mp3" "[ David Sawyer ] A secção inicial na Estação Ferroviária foi concebida para fazer com que a cidade parecesse indiferente à presença do jogador. Como se o Gordon fosse apenas mais um cidadão anónimo e sem rosto, pronto para ser subjugado. Mas, durante o ataque aos apartamentos e a perseguição no telhado, a cidade identifica o jogador como uma anomalia e começa a agitar-se. Com o jogador identificado como agressor, a cidade foca-se nele. O sistema de sons da Overwatch, que é ouvido pela primeira vez neste ataque, tem um papel fundamental na transmissão desta mensagem. Se os jogadores ouvirem com atenção, há muitas informações sobre a consciência da cidade. Mesmo quando os jogadores não prestam atenção, o áudio continuava a transmitir a mensagem emocional que procurávamos."
N/A3933"#commentary\cn_016_elis_lab.mp3" "[ Dhabih Eng ] Criámos o Laboratório de Eli depois do Laboratório do Dr. Kleiner, o que nos deu uma melhor compreensão de como devíamos configurar e conceber cenas Choreo mais eficazes. Assim, conseguimos criar um cenário mais complexo, com mais oportunidades para que este fosse capaz de responder ao jogador. Ter muitas personagens a fazer as suas próprias coisas na sala tornou a encenação muito complicada, e foi preciso criar muitas iterações e correr testes para que tudo funcionasse na perfeição. Esta experiência provou que, normalmente, os jogadores queriam acompanhar a cena. Só precisavam de receber pistas suficientemente subtis para saber onde os queríamos. Da mesma forma, se se distraíssem, a cena tinha de parar suavemente e esperar que regressassem."
N/A3934"#commentary\cn_017_feel_free_to_look_around.mp3" "[ Dhabih Eng ] Equilibrar a vontade do jogador em explorar com os objectivos narrativos da cena sempre foi um desafio. Queríamos que a sala estivesse cheia de coisas interessantes para observar, mas muitos jogadores não exploravam até terem a certeza de que não iriam perder nenhuma das atuações das personagens. Por isso, era importante que o Eli dissesse ao jogador para olhar em redor no meio da cena. Isto indicava que era seguro explorar. A partir daí, podíamos acionar várias minicenas personalizadas com base no que despertasse o interesse do jogador."
N/A3935"#commentary\cn_018_interstitial_scenes.mp3" "[ Eric Kirchmer ] Com o avanço dos testes, encontrámos várias áreas em que os jogadores perdiam o foco no objetivo, que não é algo invulgar num jogo como o Half-Life. Para resolver este problema, colocámos pequenas cenas intersticiais para guiar os jogadores e destacar o objetivo deles. Depois de termos concluído a maior parte do desenvolvimento das cenas maiores no Choreo, como o Laboratório de Kleiner, a junção com estas cenas mais pequenas tornou-se simples. Descobrimos que usar personagens nestes momentos, funcionava melhor do exposição passiva ou lembretes no menu de pausa."
N/A3936"#commentary\cn_019_overwatch.mp3" "[ Josh Weier ] Durante a fase de desenvolvimento, criámos a voz da Vigilância com uma ferramenta gratuita de conversão de texto em voz. Mas, quanto mais nos aproximávamos do dia do lançamento, mais claro se tornava que não tínhamos direitos para a utilizar. Por isso, fizemos audições com dobradores para encontrar uma voz com as qualidades que tínhamos nas falas geradas. Encontrámos rapidamente a Ellen McClain, cuja voz era exatamente o que procurávamos. Então, reproduzíamos as falas geradas para que ela as recriasse no seu estilo. No início, a Ellen era um pouco sarcástica, uma vez que tinha de replicar uma voz robótica. Alguns anos mais tarde, quando regressou para o papel icónico de GLaDOS no Portal, encontrou uma forma de integrar este tom de forma criativa na sua performance."
N/A3937"#commentary\cn_020_box_car_joe.mp3" "[ Laura Dubuk] Esta cena curta originalmente tinha duas personagens humanas. Mas, mais tarde, na fase de desenvolvimento, substituímos um dos humanos por um Vortigaunt. Queríamos mostrar que os Vortigaunts coexistiam com os humanos e também resistiam aos Combine. Também introduzimos a capacidade que tinham de curar o jogador, embora não tenhamos explorado bem esta característica ao longo do jogo. Os Vortigaunts tornaram-se numa ferramenta narrativa útil para manter o diálogo curto, já que a sua mente coletiva justificava o facto de conhecerem o mundo e os objetivos do jogador. Desta forma, os Vortigaunt não tinham de fazer perguntas e isso ajudava a contornar o desafio de escrever diálogos com um protagonista que não fala."
N/A3938"#commentary\cn_021_mossman.mp3" "[ Marc Laidlaw ] A Judith Mossman foi inspirada numa personagem que tínhamos planeado para uma secção do Half-Life 1. Esta secção foi cortada do jogo e reutilizada no Uplink, mas sem a personagem. Para nós, é a personagem mais complexa do Half-Life 2. Sabíamos que estaríamos a andar na corda bamba com o que o jogador pudesse sentir por ela, mesmo antes de Nova Prospekt, porque as fontes fidedignas do jogador discordam: o Eli gosta dela, mas a Alyx não. Sabíamos que havia um limite para a complexidade que podíamos alcançar com as relações, mas concluímos que uma dinâmica entre madrasta e filha era algo que os jogadores iriam entender. Quer concordemos ou não com Mossman, ela está a fazer algo heróico. Corre o risco de ser uma agente dupla para obter as informações que precisa para proteger o Eli e a Alyx. Só não tinha nada planeado para o Gordon."
N/A3939"#commentary\cn_022_hands_free.mp3" "[ Matt Wright ] Na altura do lançamento do Half-Life 2, a maioria dos FPS dava ao jogador uma arma de fogo ou uma arma branca no início. Nós optámos por começar de mãos a abanar. Sem arma, era mais fácil treinar o jogador quanto a formas mais inovadoras de interagir com o mundo e de apresentar a história. Queríamos que o jogador fizesse a transição de fugitivo para agressor e armá-lo no momento certo para criar esse momento de forma natural. Quando finalmente conseguia obter uma arma, o jogador já teria parado de fugir. Diz-se que, por vezes, a melhor forma de ganhar é virar costas, mas sabemos que isso não é verdade. A melhor forma de ganhar é correr na direção de um inimigo aos tiros."
N/A3940"#commentary\cn_023_metrocop_scene.mp3" "[ Mike Dussault ] Esta é outra cena criada para deixar claro que os Metrocops são os vilões. Só que desta vez o jogador tem uma arma e pode finalmente fazer algma coisa. E essa coisa sai do cano de uma arma. Sabíamos que o jogador tinha de se sentir do lado certo da justiça e este momento fez parte disso. Os Metrocops continuam a ser humanos, ao contrário do resto dos Combine. Por isso, sentimos que precisávamos de ir mais além para garantir que as ações do jogador eram justas e não apenas reflexo de raiva."
N/A3941"#commentary\cn_024_moving_the_gravity_gun.mp3" "[ Ted Backman ] Quando criámos o protótipo da arma de gravidade, planeámos dá-la ao jogador a meio do jogo. Mas, conforme os testes avançavam, reparámos na força do design e percebemos que a arma de gravidade, e mais importante, a capacidade de disparar lâminas contra as caras dos zombies, tinha de ser implementada mais cedo. Para tal, o Laboratório do Eli também tinha de ser implementado mais cedo. Foi uma mudança significativa, mas essencial para o sucesso do Half-Life 2. É um bom exemplo sobre como a narrativa e a jogabilidade estão interligadas e nenhuma deve ter prioridade. Têm de trabalhar juntas."
N/A3942"#commentary\cn_025_buggy_birds.mp3" "[ Adrian Finol ] Num teste da Costa memorável, um jogador regressou ao veículo depois de explorar uma casa e, por acaso, viu um pássaro a voar. Gritou com o pássaro, disse-lhe para se afastar do buggy e reclamou com o facto de os pássaros costumarem sujar o seu carro na vida real. Na discussão após o teste, percebemos que era a primeira vez que tínhamos criado objetos separados do jogador com os quais eles se preocupavam. Entendemos isto como algo a explorar e assim criámos um sistema para criar o tal momento temido pelo tester. Quando o jogador abandona o buggy durante algum tempo e este fica fora do campo de visão, geramos uma gaivota num local ao acaso na estrutura do veículo. À medida que o tempo passa, a gaivota deixa marcas de cocó no carro por baixo dela e continua até que o jogador regresse, e nessa altura voa. Naturalmente, os testers queriam poder limpar o buggy. Por isso acrescentámos a possibilidade de limpar o carro ao conduzi-lo em águas rasas. O desenvolvimento do jogo estava numa fase tão avançada que já tínhamos a tecnologia para fazer isso e foi fácil de implementar. É um daqueles casos em que temos a certeza que apenas poucos jogadores vão descobrir, mas se conseguirmos implementar estes detalhes de forma eficaz e tivermos casos suficientes, a maioria dos jogadores vai encontrar pelo menos um."
N/A3943"#commentary\cn_026_bridge_gunship.mp3" "[ Adrian Finol ] Ficámos particularmente satisfeitos com o confronto contra a nave de combate, apesar de ser complicado de configurar por causa da geometria do nível. Como o jogador estava na parte de baixo da ponte, a nave de combate podia movimentar-se completamente à volta do jogador, usando as três dimensões para se colocar acima e abaixo em momentos diferentes. As vigas davam muita cobertura de alta frequência, criando oportunidades para que os disparos da nave fossem um espetáculo visual e sonoro, divertido e dinâmico."
N/A3944"#commentary\cn_027_floor_is_lava.mp3" "[ Adrian Finol ] Criar a jogabilidade em torno de conceitos compreendidos como \"o chão é lava\" facilitou o treino. Gostámos da forma como o sistema de física permitiu muita liberdade criativa na forma como os jogadores lidavam com ele. Alguns construíam passagens com muitos objetos, enquanto outros usavam só as suas duas folhas de metal preferidas. Alguns seguiam o caminho das rochas com cuidado, a tentar não cair, enquanto outros iam diretamente em direção à saída, a seguir os objetos que estavam mesmo por cima da areia. Os estilos de jogo variavam. Alguns jogadores achavam ser um fracasso se invocassem os Antlions e recarregavam imediatamente, enquanto outros preferiam voltar às rochas para recuperar. Também gostamos que funcionasse como um quebra-cabeças de navegação, mas que pudesse ser transformado numa arena se assim os jogadores preferissem. Alguns preferiam simplesmente ir para a areia e combater até chegar ao fim."
N/A3945"#commentary\cn_028_opportunistic_moments.mp3" "[ Ariel Diaz ] Alguns dos momentos memoráveis do jogo surgem da interação de vários sistemas. Mas entendemos que estes momentos acontecem raramente. Quando isto acontece, queremos que mais jogadores os vivenciem. Há uma tensão: quanto mais sabemos que os jogadores vão encontrar algo, mais esforço colocamos nisso. Mas se parecer muito artificial, esse momento pode parecer forçado e os jogadores podem não responder de forma positiva. A cena cinematográfica da destruição do helicóptero de ataque é um bom exemplo de tentarmos aumentar as probabilidades de acontecer algo memorável sem sermos demasiado óbvios. O design desta zona e as trajetórias de voo do helicóptero aumentam a probabilidade de tanto o jogador como o helicóptero estarem nos pontos certos quando é destruído. Se for esse o caso, ativamos a colisão do helicóptero contra os carros. Se não for, é destruído da forma normal. É muito típico dos jogos, mas os testers não se importaram quando correu bem."
N/A3946"#commentary\cn_029_assault_on_nova_prospekt.mp3" "[ Ariel Diaz ] Com um exército de Antlions infinito na costa a atacar uma base fortificada dos Combine, seria difícil não ter criado uma fase inspirada na Normandia. O protótipo inicial tinha trincheiras que levavam até Nova Prospekt, com metralhadoras a obrigar os jogadores e os Antlions a ficarem nas trincheiras para sobreviverem. Foi incrível ver fogo de metralhadora e Antlions a saltar constantemente sobre as trincheiras. Infelizmente, não conseguimos que funcionasse com o orçamento de desempenho e tivemos de usar um layout completamente diferente. No entanto, as armas montadas ficaram, já que eram tão perigosas que se tornaram úteis para incentivar os jogadores a confiar nos Antlions."
N/A3947"#commentary\cn_030_buggy_physics.mp3" "[ Charlie Brown ] A física do buggy obrigou-nos a fazer várias experiências. Queríamos que parecesse ser rápido, mesmo que a velocidade máxima fosse só de 56 km/h. Por isso, fizemos algumas batotas para que funcionasse. Acrescentámos mais força vertical ao salto do turbo e um pouco de força traseira ao usar o travão de mão para derrapar. Sem isso, a baixa velocidade não fazia com o buggy fosse divertido de guiar. Além disso, o mundo tinha muito caos imprevisível que era reforçado pelos sistemas de física. Os jogadores estavam condenados a sofrer vários tipos de colisões e tivemos de garantir que podiam sair sempre que quisessem. Para tal, tivemos de fazer várias experiências e testes. Por fim, decidimos seguir uma simulação muito irrealista, que tornou o buggy mais fácil de controlar e mais difícil de capotar. O centro de gravidade é muito baixo e as rodas, apesar de parecerem girar muito, na realidade não o fazem. Foi a nossa primeira tentativa em criar um veículo fisicamente simulado e aprendemos muito. Foi assim que conseguimos tornar o muscle car do Episode Two mais fácil de conduzir."
N/A3948"#commentary\cn_031_the_bridge.mp3" "[ Charlie Brown ] Esta secção da ponte foi inspirada na ponte Deception Pass, mesmo acima da rua dos escritórios da Valve. Originalmente, criámos esta secção como um quebra-cabeças de navegação ao qual adicionámos cada vez mais jogabilidade. Esta secção também se tornou no caso de teste principal para o atrito em extremidades do jogador. No nosso sistema de movimento, aumentámos ligeiramente o atrito na desaceleração do jogador conforme se aproxima das extremidades de uma superfície. Os jogadores nunca repararam nisto, provavelmente porque segue de forma natural o objetivo de parar na extremidade para olhar para baixo, combinando com a tendência humana de nos movermos cada vez mais devagar e com cuidado quando há risco de queda. Mas é uma funcionalidade crítica para esta parte do jogo. Sabemos disso porque, a certa altura, durante a fase de desenvolvimento, parou de funcionar e, de repente, os testers começaram todos a cair e morrer."
N/A3949"#commentary\cn_032_coast.mp3" "[ Chris Green ] Queríamos criar uma secção de jogo ampla para o buggy, mas ainda precisávamos de encontrar uma forma de limitar o movimento dos jogadores. A Costa deu-nos um limite natural num dos lados do mapa, sem deixar de parecer uma zona aberta e expansiva. Também nos ajudou a visualizar os efeitos da extração dos recursos terrestres pelos Combine. Como alguns testers ainda tentaram nadar no mar, acrescentámos sanguessugas para os impedir. As sanguessugas não podiam ser um inimigo que os jogadores pensassem que podiam enfrentar, por isso são um bocado mágicas. Em geral, os jogadores entenderam que estavam a ir contra os limites do jogo e por isso não as desenvolvemos em demasia."
N/A3950"#commentary\cn_033_grenade_house.mp3" "[ Dave Riller ] Grande parte de um jogo Half-Life é proporcionar experiências de combate ligeiramente diferentes a cada esquina, mesmo que não passem de pequenos ajustes em relação às anteriores. Nem todos os desafios têm de depender de habilidade. Por vezes, podem ser só momentos divertidos para o jogador aproveitar. Esta casa de granadas é um desses momentos, com a diferença de que invertemos a configuração normal. Em vez de o jogador lançar granadas contra inimigos abaixo dele, os inimigos estão elevados. A caixa de granadas ilimitada é uma forma um pouco óbvia de incentivar os jogadores a interagirem com o cenário, mas a invulnerabilidade também empurra os jogadores para subirem ao andar de cima, mesmo que tenham explodido com tudo."
N/A3951"#commentary\cn_034_buggy_training_course.mp3" "[ David Sawyer ] Esta secção de treino foi pensada para que os jogadores se divertissem com o buggy. No lançamento do Half-Life 2, este nível de simulação física em veículos era inédito. Por isso, quisemos dar aos jogadores uma grande oportunidade de experimentarem. Como também tinham acabado de sair das zonas apertadas de Ravenholm, quisemos dar-lhes como recompensa a possibilidade de se moverem rapidamente num espaço amplo e se sentirem segurança num veículo. Garantimos que seria preciso fazer um salto com turbo para sair desta área, o que também servia como um teste para saber se tinham chegado a um determinado nível de conforto na condução e impedia que abandonassem o buggy."
N/A3952"#commentary\cn_035_ambush.mp3" "[ David Sawyer ] Um dos desafios gerais de um FPS como o Half-Life é que o jogador está sempre a entrar em espaços que não conhece. Isto significa que, quando entra em combate, está em áreas desconhecidas, sem saber como abordar a luta. Usámos muitos métodos diferentes para ajudar o jogador, e esta emboscada é um bom exemplo. No início, o jogador enfrenta um grupo dos Combine entre estas casas. Durante o confronto e a exploração que se segue, o jogador pode analisar o espaço da arena. Depois, quando o jogador chega a este sótão, geramos uma segunda onda de ataques dos Combine. Neste segundo confronto, o jogador passa a ter a vantagem de conhecer o espaço e pode tomar decisões defensivas mais estratégicas contra os atacantes."
N/A3953"#commentary\cn_036_bugbait_training.mp3" "[ David Sawyer ] Acabámos por criar este treino com iscos. Ficámos sem tempo, mas os jogadores tinham de entender esta ferramenta para que o design de Nova Prospekt funcionasse. Normalmente, queremos acrescentar coisas divertidas e contexto suficientes ao treino para que não pareça um treino, para que pareça uma parte natural da descoberta de algo novo. Mas neste caso não conseguimos. Por mais óbvio que pareça, os iscos não eram algo que os jogadores entendessem de forma intuitiva. Já estávamos numa fase avançada do jogo e os jogadores tinham muita experiência a lidar com inimigos. Antes de acrescentarmos um treino, os primeiros testers que recolheram iscos entraram no nível seguinte e, de forma instintiva, disparavam contra o primeiro Antlion que viam, porque era isso que funcionava até então. O Half-Life tende a incentivar uma abordagem \"disparar primeiro, fazer perguntas depois\". Da mesma forma, quando os jogadores chegavam a Nova Prospekt, não pensavam em atirar isco contra os soldados dos Combine e, em vez disso, usavam as armas habituais. Por isso, tivemos de criar este treino não só para mostrar como funcionam os iscos, mas também para demonstrar que os Antlions se iriam aproximar do jogador sem atacar."
N/A3954"#commentary\cn_037_vortigaunt_extraction.mp3" "[ Dhabih Eng ] Esta arena tinha alguns problemas de design por vários motivos. Primeiro, como o Antlion guardião é um inimigo de ataque corpo a corpo, não podíamos permitir que o jogador chegasse a zonas que o Antlion guardião não pudesse alcançar. Experimentámos usar alguns ataques à distância, mas não gostámos dos resultados. Por exemplo, o ataque de cuspir gosma acabou por ficar ridículo. O único ataque à distância que sobreviveu foi a capacidade de atirar objetos físicos contra o jogador, mas para fazer isso, os objetos tinham de estar ao alcance, o que nem sempre era garantido. O segundo desafio era garantir que, fosse qual fosse o local onde o Antlion guardião morresse, o Vortigaunt seria capaz de alcançar o cadáver. Isto era essencial, já que o jogo não podia avançar se o Vortigaunt não conseguisse extrair o isco."
N/A3955"#commentary\cn_038_dropship_deployment.mp3" "[ Doug Wood ] Largar soldados a partir das naves de transporte era complicado, já que exigia que os NPCs surgissem dentro de outro objeto sólido. Para os colocar numa zona aberta, para poderem começar a mover-se normalmente, reproduziam uma animação que fazia com que saltassem para fora do contentor quando surgissem. Mal começou a funcionar, reparámos noutro problema. Os jogadores mais experientes esperavam do lado de fora do contentor e disparavam durante a animação de saída. Para contrariar isto, colocámos uma torre no contentor para defender os soldados enquanto saíam. Isto não impedia os jogadores de ganharem vantagem, especialmente se usassem uma arma indireta, como uma granada ou semelhante. Mas parecia realista e era uma contra-medida real e estratégica."
N/A3956"#commentary\cn_039_laser_guided_rpg.mp3" "[ Eric Smith ] A funcionalidade de orientação a laser do RPG foi uma grande dor de cabeça porque era difícil de ensinar ao jogador. Muitos testers disparavam o RPG e protegiam-se imediatamente. Mas assim não viam a trajetória do rocket. Pior ainda, não reparavam que o rocket voltava para eles. Experimentámos vários elementos do HUD, com indicadores de pontos laser para ajudar, mas descobrimos que a maioria dos jogadores também os ignorava para se concentrar no inimigo. Fizemos muitas melhorias, como realçar esta funcionalidade com uma fala do Odessa, e melhorar o áudio e os visuais na forma como o helicóptero abatia os rockets do RPG. Apesar de estas mudanças terem ajudado alguns jogadores a entender, não chegámos a um ponto em que ficássemos confiantes de que quase todos o iriam consguir. Chegámos a pensar cortar a funcionalidade, mas os combates com helicópteros seriam muito menos interessantes sem ela. A orientação a laser obrigava o jogador a manter o helicóptero na mira enquanto o rocket era disparado, mas isso também dava ao helicóptero linha de visão, criando uma tensão que adorávamos."
N/A3957"#commentary\cn_040_performance_constraints.mp3" "[ Eric Smith ] Para a arena final da Costa, concebemos um grande final onde o jogador e um esquadrão de cidadãos resistiam a vagas de ataque de soldados dos Combine, acabando numa batalha de naves de combate. Infelizmente, o custo em termos computacionais para ter soldados e aliados a moverem-se no terreno obrigou a batalha a ser constantemente reduzida para cumprir o orçamento de desempenho. Quando chegou o momento de apresentar um único esquadrão de soldados de cada vez, já estávamos atrasados no processo de desenvolvimento. Era demasiado tarde para fazer alterações em grande escala na arena para poder colocar mais inimigos e tivemos de alterar o fluxo da luta para usar um número mínimo de soldados."
N/A3958"#commentary\cn_041_lighthouse_gunship.mp3" "[ Ido Magal ] Este cenário com a nave de combate deu muito trabalho para ser executado tal como imaginámos. Queríamos que acontecesse como num filme. Num filme, a nave de combate iria disparar pelas janelas enquanto o protagonista subisse o farol, antecipando os seus movimentos. Para simular esta antecipação, construímos uma série complexa gatilhos volumétricos ao longo da escada. À medida que detetam o jogador a subir, dizem à nave de combate para escolher uma nova trajetória de voo que corresponda à altitude do jogador. Os gatilhos também ativam alvos nas janelas mais próximas do jogador. São objetos invisíveis que a IA do inimigo entende imediatamente como algo hostil, indicando à nave de combate para disparar contra as janelas. Esta combinação de IA com guião é essencial nos cenários de combate do Half-Life. A IA gere o comportamento geral e adaptativo dos NPCs, enquanto o guião personaliza os requisitos únicos de cada cenário."
N/A3959"#commentary\cn_042_crane.mp3" "[ Jakob Jungels ] O Guindaste teve de sofrer muitos ajustes para ficar perfeito. Um elemento que tenha de gerar muita força física é sempre arriscado devido às limitações das leis da física quanto a corpos rígidos e da tecnologia de destruições. Por exemplo, o íman não era capaz de corresponder completamente às expectativas dos jogadores para um elemento com tanta massa. Mas, como o Guindaste estava parado, podíamos escolher o que estava ao seu alcance e fazer ajustes conforme avançávamos. Felizmente, a maioria dos jogadores não reparou em algumas falhas, provavelmente por causa da novidade que era interagir com um guindaste num ambiente com leis da física vagamente realistas."
N/A3960"#commentary\cn_043_flashlight_power.mp3" "[ Jeff Lane ] A decisão de ter a corrida e a lanterna a usar a energia do fato HEV foi controversa no Half-Life 2. No início, só a corrida usava a energia do fato, o que fazia sentido, já que era suposto ser um pequeno sprint. A lanterna podia ser usada indefinidamente. Porém, os testes mostraram um problema. Os jogadores costumavam sair de zonas escuras sem repararem que as lanternas continuavam ligadas. Em zonas abertas e bem iluminadas, como na Costa, o orçamento de desempenho não aguentava ter a lanterna sempre acesa. Assim, tivemos de encontrar uma forma de a desligar sem que o jogador se envolvesse. Criar uma limitação da energia parecia ser uma solução simples, com a vantagem de dar mais tensão às zonas escuras. Assim, a questão passou a ser: que recurso devia usar? Já tínhamos a energia do fato e não queríamos sobrecarregar a interface com uma nova funcionalidade só para a lanterna. Fizemos experiências com outras habilidades do jogador a usarem a energia do fato, a pensar que seria interessante se os jogadores fizessem concessões entre elas. É um bom exemplo de como, por vezes, o design de jogos envolve optar entre soluções imperfeitas. Não gostámos da ideia de ter a corrida e a lanterna a partilharem um recurso, mas também não queríamos mais recursos a ocupar a interface. Para o Episode Two, como não tínhamos planos para acrescentar nada que consumisse energia do fato, decidimos dar à lanterna o seu próprio recurso."
N/A3961"#commentary\cn_044_open_world_loot.mp3" "[ Jeff Lane ] A estrutura aberta da Costa criou um novo problema quanto à distribuição de recompensas de itens. Num jogo Half-Life, normalmente recompensamos os jogadores por explorarem. Se virmos o caminho a seguir mas repararmos em alguma coisa mais ao lado, é provável que tenha algo útil se procurarmos. Quando começámos a testar os mapas da Costa, posicionámos recompensas nos cantos das áreas exteriores. No entanto, isto criou uma pior experiência para o buggy. Os espaços abertos tinham muitas zonas pequenas que pareciam conter algo e os jogadores estavam sempre a parar e a sair do buggy para procurar. Tornou-se incómodo e interrompia o fluxo do nível. Por isso, removemos as recompensas espalhadas. Mas isto criou outro problema: como devíamos indicar aos jogadores quando vale a pena sair do buggy? Pensámos um pouco e criámos uma regra: todas as construções humanas teriam sempre conteúdo jogável e recompensas de exploração, enquanto as áreas naturais não. Não podíamos indicar isto diretamente aos jogadores, mas alinhava com as ideias naturais e reforçámo-lo de forma consistente em zonas como esta."
N/A3962"#commentary\cn_045_gas_station.mp3" "[ Jeff Lane ] Tínhamos grandes planos para este encontro. Queríamos construir uma bomba de gasolina onde o jogador lutaria, provavelmente ateando os depósitos de gasolina para incendiar tudo. Imaginámos o jogador a fugir de um incêndio enorme. Contudo, o orçamento e o desempenho criaram muitas limitações em 2003, e a bomba teve de ficar cada vez mais pequena e simples para caber nos níveis grandes da Costa. Os planos para criar um sistema de fogo dinâmico não se concretizaram e, sendo assim, já não fazia sentido construí-lo. Há sempre um limite para a quantidade de trabalho que podemos justificar para um único encontro. No final, a única parte que sobrou da ideia original foram os tanques de gasolina explosivos."
N/A3963"#commentary\cn_046_buggy_introduction.mp3" "[ John Cook ] Queríamos ter algo mais interessante na introdução do buggy do que simplesmente ter o jogador a entrar e arrancar. O guindaste ajudou. Basicamente, os jogadores tinham de aprender a recuperar o buggy quando capotasse e esta sequência obrigou-os a fazer isso. Um treino sob pressão é sempre complicado, mas quisemos destacar a infestação de Antlions como o grande motivo para não se sair do buggy. Por isso, deixámos a ameaça dos Antlions e colocámos cidadãos com armas montadas para dar apoio. Como bónus, os jogadores também são levantados pelo guindaste um pouco antes de poderem usar um."
N/A3964"#commentary\cn_047_crossbow.mp3" "[ John Cook ] Esta é a primeira oportunidade de o jogador obter a besta. Pensando nisso, é surpreendente não termos usado uma barreira. É possível que o jogador passe por ela sem reparar. Para reduzir essa probabilidade, montámos um bloqueio de estrada e um ponto de observação para incentivar o jogador a sair do buggy. Nessa altura, os jogadores veriam a besta e a caixa de itens. Os testes provaram que quase todos os jogadores paravam e recolhiam a arma, mas trata-se de um caso em que a diferença entre o teste e o jogo real pode ter importância. Um tester que esteja a jogar só desde o início da Costa pode não estar tão farto de explorar como alguém que tenha começado o jogo do início. Por isso, colocámos outra besta uns níveis mais à frente, diretamente no caminho do jogador, em Nova Prospekt."
N/A3965"#commentary\cn_048_rollermines.mp3" "[ Josh Weier ] Criámos as minas rolantes para preencher a necessidade de ter um inimigo que pudesse ameaçar os jogadores enquanto conduziam o buggy. Como o jogador ao volante do buggy é essencialmente uma entidade completamente simulada fisicamente, seria interessante também ter um inimigo simulado fisicamente. O robot-serra já tinha mostrado como esta abordagem podia criar um inimigo com muitas interações interessantes com o mundo. Assim, criámos a mina rolante. Uma bola com movimento completamente influenciado pela geração de binário sobre si mesma. Criámos iterações do seu comportamento até que fosse divertido guiar contra ela. As minas rolantes não são particularmente perigosas para o buggy, mas quando se acumulam podem ser um problema, especialmente se o jogador estiver perto de um penhasco. Também garantimos que funcionavam bem quando o jogador estava a pé, permitindo aos designers de níveis criar mais alguns encontros."
N/A3966"#commentary\cn_049_sandtrap_thumper.mp3" "[ Laura Dubuk ] Aqui há barris explosivos para os jogadores usarem contra os Antlions enquanto ficam em segurança, protegidos pelo Thumper. Mas também usámos isto como dica para o próximo encontro com o Antlion guardião, onde os jogadores costumam usar estratégias semelhantes para vencer. Outras ações, como lançar explosivos com a arma de gravidade, podem ficar esquecidas se não forem usadas regularmente. Com a enorme oferta de opções de ataque que oferecemos aos jogadores, não podemos garantir que tenham usado esta recentemente. Por isso, aqui estamos a sugerir de forma subtil que coloquem essa arma de novo no inventário de ferramentas antes de enfrentarem o Antlion guardião."
N/A3967"#commentary\cn_050_coast_kickoff.mp3" "[ Marc Laidlaw ] Esta cena intersticial surgiu no final da produção para ligar Ravenholm à Costa. Reparam em alguma tendência? Grande parte do tecido de ligação dos nossos jogos forma-se no final. Neste caso, tivemos de atalhar sempre que possível. Nem sequer tivemos tempo para animar a Alyx no monitor. Este tipo de cenas costuma ser um desafio para que fiquem interessantes e não tivemos sorte com esta. É um bom exemplo do que acontece quando os NPCs são tratados como sinalizações, sem personalidade e sem acrescentarem nada à cena. O resultado é um momento que esquecemos e em que se notam as costuras do jogo. Mas esta é a natureza do desenvolvimento de um jogo. Temos pouco tempo e temos de decidir onde o gastar. O Laboratório de Kleiner e o Laboratório do Eli eram mais importantes e tivemos de nos concentrar nesses espaços."
N/A3968"#commentary\cn_051_odessa_cubbage.mp3" "[ Marc Laidlaw ] O Odessa Cubbage é um exemplo do tipo de cameo que achamos funcionar bem. É um tipo divertido com pormenores interessantes. Vive na sua própria bolha. Como não sai do seu cenário, pode ser uma personagem exagerada para se destacar. Começámos por criar o seu modelo, que foi reaproveitado de uma secção cortada, e o nome dele é o nome de um assunto de um e-mail de spam que recebemos. O modelo original era de um pescador norueguês e não se parecia com um inglês. Por isso, demos-lhe um bigode e foi assim que nasceu o Odessa. No fim de contas, ele é um charlatão. Tudo nele é falso: o sotaque, o bigode, tudo. Nunca se colocaria a si próprio em perigo. É a pessoa ideal para entregar o RPG ao Gordon e explicar-lhe como se usa."
N/A3969"#commentary\cn_052_28_transitions_later.mp3" "[ Marc Laidlaw ] Depois de alguns níveis com túneis escuros como espaços de transição, percebemos que podíamos subverter as expectativas dos jogadores ao criar outro que aparentasse ser uma transição, mas que na verdade tivesse algo mais. Tal como a maioria das pessoas, também tínhamos visto o filme 28 Dias Depois em 2002. Adorámo-lo e quisemos criar logo um encontro cada vez mais intenso com zombies num dos túneis escuros. Foi rápido de fazer e ficámos satisfeitos com o resultado. Alguns anos depois, conhecemos o Alex Garland, argumentista do filme. Ele jogou e gostou do Half-Life 2, e nós confessámos que o filme inspirou esta parte."
N/A3970"#commentary\cn_053_finest_mind_of_his_generation.mp3" "[ Marc Laidlaw ] Esta é mais uma pequena cena intersticial que acabou por funcionar bem. O único requisito para este momento era ensinar ao jogador a manter-se afastado da areia. Nas cenas anteriores, ainda estávamos concentrados em torná-las funcionais, mas quando chegámos a esta, sentíamo-nos mais confortáveis e começámos a apreciar o processo de pensar melhor nestes momentos. Desta forma, levámos as personagens para além de meros sinais e criámos algo mais interessante e divertido. Depois do lançamento, o Lazlo começou a ter imensos fãs, e isso recordou-nos de como é complicado prever o que terá sucesso com os jogadores."
N/A3971"#commentary\cn_054_bridge_playtesting.mp3" "[ Matt Boone ] A secção da ponte sempre foi um ponto alto nos testes. Os testers tinham sempre reações fortes. A tensão que sentiam enquanto avançavam lentamente sobre as vigas era visível nos movimentos. Com o passar do tempo, acrescentámos mais desafios à travessia, e os testes ficaram mais divertidos de analisar. Desde o comboio a fazer ruído na ponte e a abanar o jogador, até um headcrab a aparecer de surpresa numa cabana que parecia um lugar seguro a meio do caminho. Sentimo-nos um bocado culpados a sentir o stress visível dos testers, mas não éramos propriamente monstros. Quando os jogadores atravessavam a ponte, respiravam de alívio, desativavam o escudo dos Combine e só depois entendiam que tinham de voltar por baixo. Como não queríamos que se aborrecessem na segunda parte da viagem, adicionámos uma nave de combate para fazer companhia aos jogadores."
N/A3972"#commentary\cn_055_thumper_final_stage.mp3" "[ Matt Boone ] Gostámos da fase final dos Thumpers, onde o seu propósito era invertido. Agora, em vez de serem uma ferramenta de proteção, bloqueavam o exército de Antlions do jogador. No entanto, talvez devêssemos ter criado um treino mais completo de Thumpers antes de chegarmos a este ponto. Apesar de ser aceitável que os jogadores entendessem só uma parte do funcionamento dos Thumpers nos níveis iniciais da Costa, agora os riscos eram maiores porque os jogadores também estavam a usar iscos pela primeira vez. Os jogadores que não percebiam que o primeiro Thumper impedia os Antlions de avançar podiam não perceber como funcionava o isco. Se lançassem isco contra os soldados do primeiro bunker e nenhum Antlion chegasse, podiam concluir que o isco não era fiável ou não funcionava como esperado e voltariam a usar as armas."
N/A3973"#commentary\cn_056_buggy_tools.mp3" "[ Matt Wright ] Queríamos que o buggy fosse muito mais do que um simples meio de transporte. Por isso, instalámos uma arma. Escolhemos o canhão Tau, uma arma do Half-Life 1 de que gostávamos muito, mas que não tínhamos encontrado um sítio certo para usar no Half-Life 2. O canhão Tau é capaz de disparar através de paredes, o que cria complicações quanto ao design de níveis. Por isso, limitámos a sua utilização à secção da Costa. Introduzir armas capazes de penetrar paredes complica a criação do design dos níveis. Além disso, instalámos uma caixa de munições na traseira do buggy para que os jogadores tivessem munições ilimitadas para a SMG na Costa. Isto foi particularmente útil para os testers que encontraram dificuldades em enfrentar os Antlions infinitos que surgiam na areia."
N/A3974"#commentary\cn_057_antlion_guard.mp3" "[ Matt Wright ] Em alguns casos raros, os jogadores não conseguiam matar o Antlion guardião nesta arena. Isso acontecia se ficassem sem munições e se também tivessem usado todos os objetos físicos disponíveis de forma incorreta, não sobrando nada para usar com a arma de gravidade. Para resolver este problema, acrescentámos um cidadão na torre por cima do portão para ajudar, caso o jogador ficasse bloqueado e precisasse da ajuda do cidadão para matar o Antlion guardião."
N/A3975"#commentary\cn_058_terrain_and_performance.mp3" "[ Mike Dussault ] O orçamento de desempenho era uma grande limitação para os combates. E ainda mais para combates em superfícies de terreno. Quando os NPC se movem, fazem várias pequenas sondagens espaciais para perceberem se podem percorrer o caminho escolhido em segurança. Imaginem que não conseguem ver e estão sempre a abanar uma vara à frente deles, para descobrirem se o caminho está livre. O custo de desempenho destas sondagens cresce quanto maior for a complexidade da geometria do mundo. O sistema de deslocamento de terreno cria superfícies irregulares com muitos polígonos. Muito mais do que os pavimentos planos de outros locais. Isto significava que os NPCs que se moviam no terreno da Costa consumiam mais recursos do que noutras áreas. E esta limitação restringia a escala de muitos encontros nesta secção."
N/A3976"#commentary\cn_059_area_portals.mp3" "[ Mike Dussault ] Um dos desafios do desempenho na Costa, foram os espaços abertos e amplos que incluíam edifícios com interiores muito detalhados (pelo menos, detalhados para os padrões de 2003). Quando o jogador estava no exterior, queríamos alocar o máximo possível do nosso orçamento para renderizar esse espaço, sem perder recursos para os interiores dos edifícios. Mas, a não ser que estivéssemos dispostos a fechar todas as janelas e todas as portas, o jogador conseguia ver o interior. Para resolver este problema, criámos uma funcionalidade chamada \"portais de área\", que eram colocados em cada janela e porta aberta. Um portal de área pré-calcula uma imagem plana do interior do edifício. Enquanto se joga, quando o jogador está a alguma distância, o portal de área mostra essa imagem pré-calculada sobre a janela ou porta para que possamos ignorar a renderização do interior real. Quando o jogador se aproxima, fazemos um crossfade suave entre a imagem do portal de área e o conteúdo real do edifício. Bem usados, os portais de área ajudaram-nos a atingir os objetivos de desempenho na Costa, assim como algumas portas que se fechavam atrás do jogador."
N/A3977"#commentary\cn_060_buggy_removal.mp3" "[ Miles Estes ] Quando chegámos ao ponto em que queríamos que o jogador abandonasse o buggy, tivemos de ser mesmo explícitos. Por toda a Costa, os jogadores estavam a abandonar o buggy, mas depois a regressar até ele. Assim, descobrimos que os testers tentavam levá-lo se fosse minimamente possível. Esta pequena cena na garagem existe principalmente para indicar claramente que o jogador tem de parar de conduzir e terá de continuar a pé."
N/A3978"#commentary\cn_061_d2_coast_04.mp3" "[ Randy Lundeen ] Na realidade, este mapa foi a primeira zona da Costa que criámos, antes do Guindaste e outros elementos. O leito drenado do mar e os navios enferrujados foram algumas das primeiras partes de direção de arte que concebemos. Alguns anos depois, apresentámos o mapa na demonstração da E3 de 2003, embora grande parte da jogabilidade ainda estivesse a ser desenvolvida. Assim, quando começámos a criar a secção completa da Costa, esta demonstração tornou-se uma perspetiva muito útil."
N/A3979"#commentary\cn_062_transition_tunnels.mp3" "[ Randy Lundeen ] Criar a Costa obrigou-nos a desenvolver uma forma de lidar com as transições entre níveis. Para passar de um nível para outro, tínhamos de guardar tudo no espaço de transição quando o jogador saía do primeiro nível e repô-lo no nível seguinte depois do carregamento. Basicamente, também tínhamos de guardar e repor tudo o que é visível para o jogador na área de transição, mesmo que ficasse fora do próprio espaço. Por isso, tentámos manter os espaços de transição o mais pequenos e fechados possível. Na maioria do jogo, uma divisão pequena funciona bem para este intuito. Mas na Costa, tivemos de procurar uma solução diferente. Depois de fazermos algumas experiências, optámos por túneis escuros. Além de poderem ser reutilizados de forma credível, os túneis permitiram adicionar um clarão de luz no final para esconder o facto de não podermos renderizar o que está à frente do jogador porque existe num nível diferente."
N/A3980"#commentary\cn_063_sniper_alley.mp3" "[ Robin Walker ] Esta secção foi adicionada no fim da fase de produção depois de termos mudado o Laboratório do Eli e Ravenholm para surgirem antes da Costa. Apesar de se poder pensar que construímos o jogo de forma linear, na verdade dividimo-nos em três grupos e trabalhámos em paralelo em secções diferentes, começando por trabalhar principalmente a meio do jogo. A primeira passagem de cada grupo concentrou-se em definir o núcleo da secção respetiva antes de avançar. Depois, quando tínhamos uma versão em bruto definida, regressávamos a cada secção para a melhorar. Adicionamos elementos positivos de outras áreas e removemos o que não está a funcionar. Em alguns casos, como Ravenholm, movemos secções inteiras. Depois, quando Ravenholm já tinha sido recolocado, precisávamos de ter uma nova peça para o ligar à Costa, que é a zona em que estamos agora a entrar. Devido às restrições de tempo, esta pequena secção foi construída com elementos de jogabilidade existentes e comprovados, como snipers e soldados dos Combine."
N/A3981"#commentary\cn_064_battery_finding.mp3" "[ Robin Walker ] Com a maior densidade de objetos nos espaços jogáveis do Half-Life 2, julgámos que seria interessante fazer com que os jogadores procurassem um item em específico, particularmente se existisse uma lógica sobre o local onde estaria. Assim, os jogadores poderiam localizar o item ao observar e deduzir ou por força bruta, procurando nessa zona. Como já tínhamos modelos de carros e baterias, foi natural criar uma pequena sucata para os jogadores explorarem. Também escondemos baterias em zonas inesperadas para os jogadores que escolheram usar força bruta. Como costuma acontecer com outros quebra-cabeças baseados em itens, era preciso ter um dispositivo de segurança caso os jogadores perdessem as baterias. Se querem ver o que acontece, podem tentar atirá-las de um penhasco."
N/A3982"#commentary\cn_065_boathouse.mp3" "[ Scott Dalton ] No Half-Life 1, descobrimos que podíamos derivar muito valor de cenários em que inimigos diferentes lutam entre si. É divertido para os jogadores observá-los e é mais fácil olhar para os comportamentos de inimigos quando não estamos ameaçados. Este primeiro encontro entre Antlions e soldados dos Combine foi criado para ser uma oportunidade divertida em atropelar algo com o buggy, mas também serve para dar destaque ao Thumper. Ao verem os soldados a usar o Thumper para afastar os Antlions, esperávamos que mais jogadores entendessem a sua utilidade. Gostámos da forma como os soldados demonstravam a importância em ficar perto de um Thumper enquanto enfrentavam Antlions."
N/A3983"#commentary\cn_066_buggy_theft.mp3" "[ Scott Dalton ] Conforme íamos criando o final da Costa, decidimos que os Combine iriam roubar o buggy ao jogador. Logicamente, não faz muito sentido, mas depois de termos visto vários testes em que os jogadores criaram um laço forte com o buggy, quisemos brincar com esta ligação emocional. Mal implementámos o roubo, os testers gritaram com os Combine por terem roubado o carro deles, algo que consideramos ser um sinal de sucesso. O soldado que dispara do cume do penhasco serve só para chamar a atenção do jogador, ativando o alvo para olhar e gerando a nave de transporte com o buggy. Ver isto 20 anos depois, fica mesmo ridículo."
N/A3984"#commentary\cn_067_snipers.mp3" "[ Ted Backman ] A equipa do Half-Life 2 nunca foi muito grande, por isso estávamos sempre à procura de formas de criar uma nova jogabilidade sem ter custos elevados na produção de ativos. O sniper é um bom exemplo. Não há um modelo, é só um raio laser. Por isso, não precisa de ter arte nem animações. Quando morre, gera um boneco que é um soldado da Combine que cai da janela. Apesar dessa simplicidade, deu-nos uma jogabilidade única. Ficámos particularmente satisfeitos com a forma como interage com os objetos físicos. Como os jogadores estão habituados a explorar objetos explosivos perto de inimigos, julgámos que devíamos ter um inimigo capaz de inverter esta dinâmica quando o jogador estava a proteger-se."
N/A3985"#commentary\cn_068_buggy_model.mp3" "[ Ted Backman ] O modelo do buggy sofreu várias iterações até à versão final. Testámos muitos designs que se adequavam ao que procurávamos em termos de arte e simulação da física, mas tivemos um problema inesperado. Muitos testers, até jogadores experientes em FPS, sentiam-se enjoados ao guiar o carro. Fizemos alguns ajustes na simulação e descobrimos que alterar o modelo do buggy ajudava. Quanto mais o modelo obscurecia o mundo, piores eram os enjoos. Por isso, começámos a remover partes do modelo, cada vez mais peças da carroçaria até que os jogadores deixassem de sentir enjoos. Em particular, a capacidade de ver o chão pela parte inferior que faltava fez uma grande diferença."
N/A3986"#commentary\cn_069_antlion_design.mp3" "[ Ted Backman ] Nos primeiros trabalhos de design, tínhamos planos para criar várias raças alienígenas principais, sendo que os Combine eram apenas uma delas. Uma das outras raças era uma espécie insectoide religiosa, e os Antlions faziam parte dela. Mais tarde, ao produzirmos a Costa, começámos a vê-los mais como pragas que surgiam pelos portais Xen, assim como os headcrabs e outras criaturas. Apesar de não serem de Xen, infestam todos os cantos de qualquer mundo em que entrem, como as baratas."
N/A3987"#commentary\cn_070_explosive_barrels.mp3" "[ Brian Jacobson ] Aqui introduzimos os barris explosivos. São um elemento básico dos FPS, mas aqui com uma novidade. O segundo tiro de pistola incendeia o barril, iniciando uma detonação temporizada. O terceiro tiro detona o barril imediatamente. Assim, os jogadores podem atrasar a explosão ou causá-la imediatamente, dependendo da situação. Podem dar um barril explosivo a um Barnacle e disparar duas vezes para tentar despachar um grupo deles. A explosão retardada também tornou as reações em cadeia entre vários barris mais interessantes. Os barris explosivos foram um sucesso no jogo anterior, mas também eram algo útil para os designers de níveis, que nunca se cansavam deles."
N/A3988"#commentary\cn_071_ragdoll_magnets.mp3" "[ Dario Casali ] A física do Half-Life 2 deu-nos várias ferramentas capazes de tornar os combates mais emocionantes. Por exemplo, quando os inimigos não atingem o jogador, redirecionamos os disparos de forma subtil para objetos frágeis por perto, causando mais caos e criando uma sensação de filme de ação. Também usamos a física para adicionar dicas. Criámos algo a que chamamos de \"ímanes de bonecos\" pelo jogo para fazer com que os corpos dos inimigos caíssem de formas interessantes e dramáticas. Como de extremidades ou para a frente de um comboio."
N/A3989"#commentary\cn_072_helicopter_peekaboo.mp3" "[ Dave Riller ] A escolha no helicóptero de ataque dos Combine como antagonista principal foi algo que quisemos desenvolver ao longo do capítulo. O helicóptero implacável tornou-se numa personagem por si só. Aqui podemos ouvi-lo, escutar o motor e vê-lo a voar a acompanhar os carris e a desaparecer no horizonte. Este primeiro contacto é um prenúncio, com a sua presença a tornar-se cada vez maior ao longo do tempo, até que eventualmente o enfrentarmos."
N/A3990"#commentary\cn_073_iterative_passes.mp3" "[ David Speyrer ] Alguns capítulos, como as secções que fazemos a pé nos Canais e em Ravenholm, foram criados em várias passagens por diferentes grupos. Concluímos que dividir os mapas desta forma criava uma maior variedade na experiência e uma maior densidade de momentos interessantes, já que cada grupo adicionava os seus próprios elementos aos mapas. Na parte a pé nos Canais, a primeira passagem estabeleceu a direção de arte, o percurso dos jogadores, os traços gerais da experiência e algumas partes importantes. Mas na fase de testes alfa, equipa identificou uma tensão insuficiente e uma experiência monótona. Na segunda passagem, regressámos ao mapa focados apenas em criar mais tensão e aumentar a densidade dos cenários entre momentos."
N/A3991"#commentary\cn_075_pistol_design.mp3" "[ Josh Weier ] A pistola padrão é fundamental no jogo. Para além de ser a primeira arma de longo alcance que aprendemos a usar, também é uma forma de interagir com as leis da física e com objetos destrutíveis a uma distância segura durante o jogo inteiro. Para tornar a pistola mais responsiva e divertida, usámos uma mecânica de reativação única. A velocidade com que esta arma dispara depende da rapidez com que o jogador clica no botão. Ou seja, o jogador sente uma resposta instantânea às suas ações e, quanto mais rápido clicar, mais rápido dispara."
N/A3992"#commentary\cn_076_shatterglass.mp3" "[ Josh Weier ] Ao criar os níveis iniciais, onde os jogadores têm acesso a menos mecânicas, descobrimos que é positivo destacar novas características técnicas, como fizemos neste caso com o vidro quebrável. Para criar o efeito de estilhaçamento, o vidro foi dividido numa grelha de pequenos quadrados. Desta forma, rastreamos quais os quadrados intactos ou partidos e explodimos secções maiores quando haviam quadrados suficientes que não estejam ligados entre si. Cada quadrado era renderizado com uma textura única que dependia do estado dos quadrados vizinhos, criando as arestas afiadas e irregulares entre vidros partidos e intactos. Atualmente, ver vidros partidos é comum em jogos, mas não era assim durante a criação do Half-Life 2. Ficámos muito satisfeitos com o nível de fidelidade e dinamismo que este elemento trouxe ao jogo."
N/A3993"#commentary\cn_077_lambda_caches.mp3" "[Laura Dubuk] Tecnicamente, o primeiro depósito lambda está no Laboratório de Kleiner, mas este é o primeiro que o jogador encontra sem ajuda. Usámos depósitos lambda para incentivar a exploração e indicar onde se escondiam alguns recursos, a narrativa sendo que eram colocados pela Resistência como parte da revolta. No Half-Life, o conteúdo das caixas de mantimentos era decidido pelo design dos níveis. No HL2, introduzimos caixas de itens adaptáveis que fornecem o que está em falta nesse momento com base nos objetivos de recursos definidos pelos designers."
N/A3994"#commentary\cn_078_scanners.mp3" "[ Kerry Davis ] As sondas foram um desafio de design complexo. Apesar de gostarmos da forma como a sua presença distópica transmitia o sentido de ocupação da Combine como um estado de vigilância opressivo, não queríamos que disparassem contra os jogadores. Descobrimos que o ato de apontar para cima para atingir um inimigo pequeno, móvel e com a vantagem de sobrevoar o jogador era algo que não conseguíamos tornar divertido. Como dávamos muito valor ao seu papel na história, decidimos que as sondas serviriam sobretudo como olhos em combate, alertando os inimigos da presença do jogador, algo que reforçámos com efeitos sonoros dos soldados. Para além disso, só conseguem incomodar o jogador com luzes brilhantes e fazer um ataque direto depois de sofrerem algum dano."
N/A3995"#commentary\cn_079_surface_properties.mp3" "[ Ariel Diaz ] Reproduzimos sons de passos personalizados quando os jogadores caminham na lama escorregadia. Este sistema chamava-se Surface Properties e usava o tipo de material para determinar os sons e outros efeitos que ocorriam ao pisar ou disparar sobre eles. No início, tínhamos um efeito que abrandava o movimento dos jogadores ao caminhar em superfícies com lama. Contudo, foi removido na versão final, pois era demasiado penalizador."
N/A3996"#commentary\cn_080_combat_entrances.mp3" "[ Dario Casali ] Virar uma esquina a correr para chegar a uma nova área só para ver os inimigos parados é algo estranho e faz com que o mundo pareça menos vivo e mais parecido com um campo de tiro. Por isso, queríamos introduzir os inimigos em espaços de combate de formas interessantes e dinâmicas, que comunicassem um plano e intencionalidade, como se tivessem planos para o Gordon mesmo antes de ele aparecer. Nesta cena, os Metrocops saltam para a zona através de sequências programadas e, mais tarde, usamos o rapel de forma semelhante. Na verdade, não importa de onde vêm, porque os jogadores acabam por inferir esta história. No fim de contas, descobrimos que os combates tinham de ter uma história implícita: uma emboscada, uma surpresa, um surto, um ataque. Estes cenários usam quase a mesma IA inimiga, mas pareciam diferentes para quem testava o jogo."
N/A3997"#commentary\cn_081_mounted_gun_gallery.mp3" "[ Dave Riller ] Há várias coisas a acontecer nesta cena. A torre a disparar contra caixas que partem ensina os jogadores a não enfrentar a ameaça de frente, mas sim a seguir a rota do esgoto para a derrotar. E, quando chegam à torre, divertem-se a usá-la como num campo de tiro, com uma horda de soldados dos Combine e Sondas a descer dos céus. Aqui também começámos a introduzir o veículo blindado dos Combine, que dispara mísseis, obriga os jogadores a avançar e volta a aparecer mais tarde neste capítulo."
N/A3998"#commentary\cn_082_barnacle_bowling.mp3" "[ Josh Weier ] Este é um bom exemplo de como vários elementos de design se juntam numa matriz de interações para criar um cenário memorável. Temos os barnacles, a simulação física, as propriedades de superfície na lama escorregadia e, finalmente, mas não menos importante, os barris explosivos. O jogador encontrou-os sem ajuda, mas tudo se encaixa naturalmente para criar um momento a que chamamos \"bowling de barnacles\"."
N/A3999"#commentary\cn_083_barnacle_introduction.mp3" "[ Mike Dussault ] Como os barnacles podem criar confusão quando são encontrados pela primeira vez, quisemos apresentá-los de uma forma que explicasse o seu comportamento a uma distância segura. Decidimos apresentá-los numa cena predador/presa ao estilo \"BBC Vida Selvagem\". Mas, como sempre, este tipo de cenas exigiram muitas iterações para que os jogadores as vissem de forma fiável."
N/A4000"#commentary\cn_084_physics_in_puzzles.mp3" "[ Eric Smith ] Algumas mecânicas mais simples, que podemos encontrar no início do jogo, são obtidas através de mecânicas mais complexas como forma de treino. O quebra-cabeças do balancé, que é a primeira engenhoca inspirada na física do jogo, na verdade surgiu do quebra-cabeças posterior e mais complexo da máquina de lavar roupa nos Canais. O balancé usa os mesmos princípios de massa e rampas, mas de uma forma mais direta, com a qual é possível interagir diretamente para ajudar a compreender a física do jogo e tornando os próximos quebra-cabeças mais fáceis de resolver. Este quebra-cabeças também destaca a natureza analógica do sistema de física através do posicionamento dos blocos de cimento e do peso do jogador a serem considerados na solução."
N/A4001"#commentary\cn_085_combine_attack_helicopter.mp3" "[ Brian Jacobson ] Os jogadores já tinham observado antes, mas é aqui que apresentamos o boss principal do capítulo dos Canais: o helicóptero de ataque dos Combine. Este helicóptero destrói a cobertura do jogador, obrigando-o a avançar para não ser abatido. Queríamos que esta sequência fosse muito tensa e ameaçadora, com o helicóptero a parecer demasiado forte para ser enfrentado diretamente e a manter essa intensidade durante os Canais e até ao confronto final no Reservatório. Para conseguir isso, limitámos o movimento do helicóptero com base em objetivos de jogabilidade específicos. Neste mapa, que foi criado para ser uma corrida de cobertura em cobertura sob fogo do helicóptero, elaborámos um percurso em anel no céu acima da arena. O helicóptero desloca-se sempre para o ponto mais distante do jogador nesse anel, mantendo-o visível e facilitando a colocação de cobertura nos locais certos."
N/A4002"#commentary\cn_087_explosive_barrel_factory.mp3" "[ David Speyrer ] Esta divisão, que tem um número absurdo de barris a explodir, despertou um debate dentro da equipa sobre até onde devíamos levar a plausibilidade do mundo que criámos. Sinceramente, um barril a explodir talvez seja demasiado em termos de realismo. No mundo real, os barris não explodem, mesmo que sejam atingidos."
N/A4003"#commentary\cn_088_rising_water.mp3" "[ Dhabih Eng ] Esta ponte flutuante e os carretos de madeira introduzem o conceito de flutuabilidade como ferramenta. Neste caso, não é propriamente um quebra-cabeças. É só um jogo para o jogador interagir com o sistema de física. Mas mais tarde revisitámos este elemento nos Canais para criar uma rampa para o aerobarco."
N/A4004"#commentary\cn_089_manhack_matt.mp3" "[ John Morello ] Chamamos a este tipo \"Matt Robot-serra\". Queríamos dar aos jogadores a sensação de que centenas de cidadãos habitavam todos os cantos e recantos da Cidade 17. Nesta altura do jogo, há já muito tempo que os jogadores não viam um cidadão e queríamos explicar o significado dos Robots-serra, que foram os primeiros inimigos que seguem as leis da física que criámos. No conceito original, tínhamos um salão de jogos na cidade onde os jogadores podiam pilotar Robots-serra para atacar cidadãos virtuais. Eventualmente, os jogadores acabariam por descobrir que os Robots-serra eram reais, tal como os cidadãos. Quando a ocupação dos Combine se desenvolveu, esta ideia de existir um salão de jogos foi uma escolha estranha e acabou por se abandonada."
N/A4005"#commentary\cn_090_fighting_motion_sickness.mp3" "[ David Speyrer ] Nos primeiros testes, muitos jogadores sofreram enjoos ao pilotar o aerobarco. Ao tentar corrigir isto, descobrimos que haviam vários fatores em jogo. Concluímos que reduzir a intrusão do aerobarco no campo de visão ajudava, pelo que testámos o modelo várias vezes para o reduzir. Uma taxa de fotogramas consistente também ajudava, por isso era importante prestar atenção ao desempenho nestas secções. Porém, o fator mais importante foi a eliminação da rotação da câmara para manter o horizonte mais estável, independentemente do que o aerobarco fizesse. Um dos programadores sofria muito de enjoos e ofereceu-se para vários testes de forma a avaliar o progresso na busca de uma solução. Tenho a certeza de que vomitou pelo menos uma vez após o teste. O seu sacrifício nobre foi apreciado."
N/A4006"#commentary\cn_091_headcrab_canisters.mp3" "[ Jeff Lane ] As cápsulas dos headcrabs usadas são vistas mais tarde em Ravenholm. Por isso, decidimos mostrá-las aqui para contar a história de como são usadas pelos Combine. A história é que os Combine transformaram a fauna Xen numa arma para a usar contra humanos. Os headcrabs enterrados foram acrescentados como uma nova funcionalidade nesta secção, que foi expandida para uma zona maior, com o objetivo de mostrar uma favela dizimada pelo ataque dos headcrabs."
N/A4007"#commentary\cn_092_airboat_intro.mp3" "[ John Morello ] É aqui que os jogadores encontram o primeiro veículo do jogo: o aerobarco. Queríamos criar um espaço seguro para treinarem a pilotagem do aerobarco durante o tempo que quisessem antes de avançar. A arena está cheia de oportunidades para fazer saltos e manobras, além de estar cheia de uma gosma tóxica para manter os jogadores dentro do aerobarco mais tempo evitando que abandonassem o veículo para seguir a pé."
N/A4008"#commentary\cn_093_zombie_surprise.mp3" "[ Jeff Lane ] Criámos um pequeno susto neste esgoto. Os jogadores entram aqui, concentrados e curiosos. De repente aparece um zombie debaixo da água, que assustou quase sempre os testers. Um deles até caiu da cadeira! Marcámos esse momento como um sucesso."
N/A4009"#commentary\cn_094_airboat_time.mp3" "[ Dave Riller ] Encontrar o equilíbrio certo entre passar tempo no veículo e a pé deu muito trabalho. Conduzir a alta velocidade transportava os jogadores pelo do mundo rapidamente e, nos primeiros testes, sentimos que estavam a perder oportunidades de explorar e absorver todos os detalhes do jogo. A exploração e a análise do mundo são valores essenciais do Half-Life, por isso não queríamos que o veículo eliminasse essa questão. Para resolver isto, acrescentámos pontos periódicos em que os jogadores podiam sair e explorar pequenas zonas muito detalhadas. Além disso, à medida que o sistema de física evoluía, aprendíamos novas formas de o utilizar. Estes pontos fora do aerobarco permitiram-nos introduzir um elemento de descoberta em torno da física, como atirar caixas para a água ou juntar barris para levantar uma rampa. Isto deu aos jogadores várias hipóteses de interagir com a água e as leis da física."
N/A4010"#commentary\cn_095_floating_supplies.mp3" "[ Josh Weier ] No teste alfa, os Canais tinham várias caixas de mantimentos flutuantes que podiam ser destruídas com o aerobarco para depois recolher os mantimentos. A mecânica era algo \"gamey\", mas ajudava a manter o fluxo da jogabilidade permitindo aos jogadores abastecerem-se sem parar. Para ajudar a tornar esta premissa mais plausível, contámos a história de como as caixas flutuantes eram colocadas de forma tão conveniente ao longo do percurso. Esta cena dos cidadãos a derrubar caixas de mantimentos ajuda a confirmar esta hipótese e dá mais vida aos Canais. Também fazia com que os jogadores se sentissem mais heróicos e importantes por serem ajudados por tantas personagens secundárias."
N/A4011"#commentary\cn_096_grenade_intro.mp3" "[ Brian Jacobson ] Concebemos esta base dos Combine como zona de treino e um parque para granadas, introduzindo-as aqui em caixas de mantimentos infinitas para indicar que podem usar as granadas que quiserem sem ficarem sem elas. Percam a cabeça. O combate aqui é altamente direcionado, fazendo com que a IA dos soldados procure cobertura e crie oportunidades para os jogadores usarem as granadas. No fim da zona, a mesma técnica das granadas infinitas ajuda a solucionar o posicionamento da torre, já que um ataque direto é muito mais difícil. Adicionámos uma luz vermelha e um rasto de partículas às granadas para que fosse mais fácil seguir trajetórias, seja ao atirá-las ou desviando-se de uma granada de um soldado dos Combine."
N/A4012"#commentary\cn_097_puzzle_layers.mp3" "[ Dave Riller ] Como os jogadores costumam desconhecer completamente as intenções dos designers, o que é positivo, tendem a responder de formas surpreendentes aos quebra-cabeças. Até os quebra-cabeças aparentemente mais simples podem apresentar vários falhanços até termos um sucesso. Foi o caso deste quebra-cabeças para abrir dos portões do canal, que exigiu muitas dicas e sugestões. A roda comunica que é aqui que alguém costuma abrir o portão, mas é preciso usar outro método. Uns corvos atraem o olhar do jogador para a solução. Neste caso, é um conjunto de vigas num pêndulo. Como as granadas já tinham sido introduzidas, originalmente queríamos que os jogadores atirassem uma para partir a estrutura de suporte de madeira. Mas isso não era suficientemente óbvio. Então, adicionámos barris explosivos para serem uma pista mais óbvia. Mas, mesmo depois de resolverem o quebra-cabeças, alguns jogadores não percebiam que os portões estavam abertos e isso levava-os a explorar o interior da base à procura de outra saída. Por isso, tivemos de recordar os jogadores do problema original: o portão avariado. Adicionámos fumo, a sirene e uma luz giratória. E foi assim que finalmente começámos a ter resultados fiáveis nos testes."
N/A4013"#commentary\cn_098_metrocop_strafing.mp3" "[ Doug Wood ] O objetivo do design inicial dos níveis do aerobarco era desafiar os jogadores com manobras precisas sob a pressão dos Metrocops. O padrão de movimento dos Metrocops serviu para obrigar os jogadores a ziguezaguear em torno dos disparos enquanto aceleravam. Mas, durante a análise, conhecida internamente como \"Overwatch\", alguns testers sentiram-se frustrados por serem atacados sem poderem retaliar. Queriam que o aerobarco fosse poderoso e imparável. Com base nestas opiniões, redesenhámos os níveis para destacar o controlo em vez do desafio, passando de esquivar ataques a criando combates rápidos, mais velocidade e obstáculos ultrapassados."
N/A4014"#commentary\cn_100_mounted_gun.mp3" "[ Jeff Lane ] Os canhões montados foram adicionados aqui para ajudar a treinar os jogadores quanto à a eficácia dessa arma contra o helicóptero de ataque na batalha final no reservatório. Isto foi necessário porque, até àquele ponto, o helicóptero era invulnerável às armas dos jogadores e tínhamos de dar alguma indicação de que podia ser danificado por armamento pesado. Isto foi parcialmente eficaz nos testes devido à quantidade de pressão sob a qual o jogador se encontrava naquele momento, o que nos levou a criar os efeitos de partículas e sons que convenceriam os jogadores de que estavam mesmo a causar dano."
N/A4015"#commentary\cn_101_357_intro.mp3" "[ Josh Weier ] A Magnum, ao contrário da pistola padrão, com a sua cadência de tiro mais lenta, foi pensada para ser disparada de forma mais controlada e calculada, causando danos catastróficos aos alvos. As versões anteriores da Magnum tinham alguma dispersão aleatória, que era adequado ao peso e ao gatilho menos sensível de uma pistola maior. Porém, isto causou momentos anticlimáticos em que os jogadores apontavam cuidadosamente e falhavam devido à perda de precisão. Para resolver este problema, tornámos a primeira bala precisa e cada tiro seguinte seria menos preciso à medida que se disparava."
N/A4016"#commentary\cn_102_helicopter_bombing_run.mp3" "[ Brian Jacobson ] Este é outro exemplo de como criámos perigos de movimento nas fases do aerobarco. O helicóptero tenta colocar-se à frente do jogador e lança bombas. Se o jogador recuar, passa a pairar e ataca o jogador. Num teste, uma bomba caiu por acaso entre os canos, o que criou um momento muito cinematográfico. Como o tester teve uma reação positiva, a equipa decidiu programar o jogo para que acontecesse sempre. Este processo tornou-se parte do processo de design orgânico: de vez em quando, acontece algo porreiro por acaso num teste e encontramos uma forma de fazer com que aconteça de forma mais fiável."
N/A4017"#commentary\cn_103_smokestack_collapse.mp3" "[ Doug Wood ] Quando criamos um jogo de ação cinematográfico como o primeiro Half-Life, queremos criar sequências com destruições grandiosas e espetaculares, mas nunca conseguimos fazer bem isso. A física do Half-Life 2 introduziu um sistema para partir objetos físicos pequenos, como caixas, em pedaços, o que despertou a ideia de fazer algo maior. Demos o salto e tentámos partir uma chaminé em pedacinhos enquanto caía. Então, experimentámos com massas até que ficasse melhor, refinamos o modelo, adicionámos fumo e áudio para reforçar o efeito e conseguimos. Tínhamos um grande momento de destruição. No fim de contas, a física possibilitou essa sequência de uma forma que até parece engraçada em comparação com padrões atuais, mas foi incrível na altura. Como a simulação era única sempre que a executávamos, tivemos de tomar medidas para evitar que os grandes pedaços de destroços bloqueassem o caminho dos jogadores. O sucesso da sequela aguçou o nosso apetite pelos efeitos de destruição com física cinematográfica de maior fidelidade, vistos no Episode Two."
N/A4018"#commentary\cn_104_washing_machine_puzzle.mp3" "[ David Speyrer ] Criámos o quebra-cabeças de física da máquina de lavar roupa na reta final da produção, depois de os testes terem indicado que os jogadores precisavam de algum descanso após a pressão da perseguição do helicóptero. Os contrastes de ritmo como este realçam os momentos intensos, redefinindo o estado emocional do jogador e eliminando exaustão ou tédio. Foi positivo quando os jogadores reagiram tão bem a todo o trabalho feito para tornar o helicóptero ameaçador. Mas, se não tivéssemos gerido o stress, a fadiga instalava-se, e rapidamente começava a parecer monotonia em vez de entusiasmo. No início, os jogadores conduziam rapidamente por esta zona, mas por causa da luz solar e da composição do canal, decidimos que era um bom sítio para parar a ação e fazer com que o jogador passasse algum tempo tranquilo a resolver um quebra-cabeças. O quebra-cabeças em si, que foi o primeiro com massas e roldanas, acabou por dar origem a outros quebra-cabeças de navegação com leis da física do jogo."
N/A4019"#commentary\cn_105_airboat_changeup.mp3" "[ Jeff Lane ] Os testers pediram-nos uma jogabilidade mais variada para o aerobarco. Até este ponto, o jogador não tinha uma forma real de enfrentar o helicóptero e outros inimigos, e julgámos que devíamos introduzir uma nova arma e, por sua vez, criar uma mudança de ritmo e preparar o cenário para o que viria. Nas zonas seguintes, acrescentámos tiro ao alvo para familiarizar os jogadores com a nova arma. A maior força física dos projéteis da air gun lançaria os alvos para longe e faria com que parecesse muito mais forte do que qualquer outra arma que o jogador tivesse. Ainda assim, quando chegou o momento de testar o combate contra o helicóptero, muitos testers continuaram a achar que ele era invencível. Não tinham reparado nas nossas tentativas de indicar que o helicóptero estava a sofrer danos das armas montadas dos Combine. Para resolver esta situação, fizemos o mais óbvio: colocámos o helicóptero do lado de fora do túnel em que se apanha a arma e deixámos evidente que era possível e até deviam disparar contra ele. E funcionou."
N/A4020"#commentary\cn_106_donkey_kong_barrel_ramp.mp3" "[ Eric Smith ] Esta área em particular, a rampa de drenagem, começou por ser só um pormenor de arquitetura de nível interessante. Mas, durante os testes, compreendemos que era muito divertido deslizar o aerobarco pela rampa e acrescentámos mais elementos para melhorar a experiência. Isto incluía Metrocops a lançar barris em direção ao jogador, que é uma referência ao clássico arcade Donkey Kong."
N/A4021"#commentary\cn_107_lambda_cache_interlude.mp3" "[ Danika Rogers ] Um jogo Half-Life é uma experiência essencialmente linear. Mas estamos sempre à procura de criar formas de dividir o percurso para criar uma não linearidade à escala de cada nível. Este depósito lambda, substituído por uma emboscada de zombies e headcrabs, era opcional e foi criado só para dar um pouco de não linearidade a uma secção da viagem pelos canais."
N/A4022"#commentary\cn_108_skybox_time_of_day.mp3" "[ Eric Kirchmer ] A cor da skybox e do nevoeiro muda gradualmente ao longo deste capítulo. Serve para representar visualmente a passagem do tempo, enquanto os jogadores percorrem os canais e o capítulo. Há dois valores de cor do nevoeiro em direções opostas que ajudam a criar a ilusão do ângulo oblíquo do sol. Podemos ver o pôr-do-sol a aproximar-se neste ponto. Isto culmina na arena de combate com o helicóptero com o pôr-do-sol e Ravenholm visíveis na skybox."
N/A4023"#commentary\cn_109_helicopter_megabomb_origin.mp3" "[ Brian Jacobson] O ataque do helicóptero com megabombas foi inspirado num bug que surgiu quando um programador retirou acidentalmente o tempo de espera do lançamento da bomba, fazendo com que o helicóptero lançasse centenas de bombas de uma só vez. Ficou tão incrível que decidimos guardar esse momento para o bombardeamento na versão final."
N/A4024"#commentary\cn_110_helicopter_final_battle.mp3" "[ Dave Riller ] Criámos esta área para ser a arena do confronto final entre o jogador e o helicóptero de ataque dos Combine. É a oportunidade para o jogador finalmente eliminar este inimigo implacável, que o persegue desde que fugiu do subsolo, após de ter deixado o Laboratório de Kleiner. Esta zona teve muitas iterações até ficar perfeita. Tinha de ter um espaço amplo para haverem combates rápidos com veículos, um fluxo de movimento suave com opções de trajetória claras e um desempenho fiável. Também tentámos estabelecer uma clareza visual adequada ao combate. Algo impressionante, mas não demasiado barulhento. Desta forma, garantíamos que seria uma visão memorável após a destruição do helicóptero."
N/A4025"#commentary\cn_111_airboat_wreckage.mp3" "[ David Speyrer] Originalmente, destruíamos o aerobarco no salto sobre a barragem. Por isso, este nível começa com o jogador no meio dos destroços do aerobarco. Num teste com toda a equipa, os jogadores ficaram desiludidos por perderem o veículo que usaram durante tanto tempo. Tivemos uma grande discussão interna sobre se este sentimento de perda era uma experiência valiosa ou não. No final, decidimos deixar o aerobarco intacto para deixar em aberto a possibilidade de o jogador o reencontrar mais tarde. Há quem diga que o aerobarco ainda está à espera."
N/A4026"#commentary\cn_112_arena_exit_gate.mp3" "[ Quintin Doroquez ] O mecanismo de roldanas para erguer o portão de saída foi acrescentado para obrigar o jogador a derrotar o helicóptero antes de poder avançar. Frequentemente, falamos sobre elementos como este como uma forma de criar \"portões\" para o jogador, utilizando elementos de design para impedir a progressão até que se conclua uma dada tarefa. Nete caso, é literalmente um portão."
N/A4027"#commentary\cn_113_blocking_tutorials.mp3" "[ Adrian Finol ] Por vezes, temos de ter a certeza de que o jogador aprendeu algo. O método padrão, pelo menos no desenvolvimento de jogos, não na vida real, é impor-lhe uma barreira, onde o jogador é obrigado a demonstrar o seu conhecimento do jogo para continuar. Tentámos disfarçar as barreiras como algo natural, para que não parecesse que o jogo tivesse sido interrompido. Claro que o tempo, os recursos ou o contexto ambiental podem complicar isso. Neste caso, como tivemos de ensinar os jogadores a mover objetos, um quebra-cabeças simples de empilhar pareceu ser a melhor solução. Testámos designs mais complexos, mas acabaram por ser menos eficientes a ensinar o que o jogador tinha de aprender."
N/A4028"#commentary\cn_114_natural_storytelling.mp3" "[ Bill Van Buren ] Para atingirmos os nossos objetivos na construção do mundo e da narrativa na Estação Ferroviária, precisávamos uma forma natural de apresentar diálogos, sem que tivessem uma linguagem de jogos ou exigissem tutoriais. Reparámos que os jogadores se aproximavam dos NPCs para os verem ao perto. Então, usámos isso como uma oportunidade para os NPCs reconhecerem o jogador e falarem. Desta forma, criámos interações discretas, o que era essencial, já que os cidadãos não são muito alegres ou animados. A simplicidade desta abordagem também seguia um dos objetivos principais da narrativa do Half-Life: tornar a narrativa reativa ao interesse dos jogadores. Alguns jogadores querem descobrir todos os detalhes, enquanto outros só querem saber o que fazer a seguir. Dar aos jogadores o controlo sobre com que partes da história interagir sem bloquear o progresso é um objetivo que tentamos sempre manter na série Half-Life. Além disso, quanto menos complicado for a implementação de uma funcionalidade, mais a podemos usar."
N/A4029"#commentary\cn_115_trainstation.mp3" "[Charlie Brown] O início de um Half-Life tem muito a fazer: temos de apresentar aos jogadores um novo mundo e ensiná-los a interagir com ele. Os jogadores têm de perceber o que está a acontecer rapidamente, quem são os principais intervenientes, quais as ameaças que vão enfrentar e como se encaixam em tudo isto. Acima de tudo, tem de ser divertido e o mais interativo possível. Para conseguir tudo isto, é preciso muita iteração e testes, especialmente nos pequenos momentos que fazem parte do todo do jogo. Nesta secção, vamos destacar alguns momentos chave, problemas de design e alguns testes onde algumas coisas não correram como planeado."
N/A4030"#commentary\cn_116_physics_objects.mp3" "[ David Sawyer ] Pode ser difícil de recordar, mas quando o Half-Life 2 foi lançado, os objetos pequenos usados nos jogos, como este lixo, costumavam ser estáticos. Ou seja, não podiam ser movidos ou, quando isso era possível, moviam-se de forma muito simples. Em certos casos, podiam ser divididos em pequenos sprites quando eram destruídos pelo jogador. Um dos objetivos desta secção inicial da estação ferroviária era mostrar aos jogadores que este tipo de coisas estavam mesmo a ser simuladas em termos físicos no Half-Life 2. Podiam ser apanhados, largados, atirados, partidos, movidos por outras forças, etc. Aqui, começámos com um pequeno exemplo a mostrar que o lixo está a ser empurrado pela chegada do comboio, ou mais especificamente, um volume invisível ativado pelo jogador ao sair do comboio."
N/A4031"#commentary\cn_117_blocking_tutorials_3.mp3" "[ Eric Smith ] O segundo erro neste tutorial é um caso de erro de explicação, em que ensinámos acidentalmente algo que não pretendíamos. Pode ser difícil de evitar sem testes extensos, uma vez que o jogo está sempre a ensinar, mesmo quando não é intencional. Falamos sobre um exemplo mais extremo deste caso mais à frente na Estação Ferroviária. Alguns casos de erro de explicação têm mesmo de ser corrigidos, como quando o jogador aprende a usar uma arma ou interage com um elemento comum de forma errada. Mas este foi mais subtil. Ao ensinar os jogadores a mover objetos, também ensinámos a empilhar objetos para escapar de um espaço. Normalmente, isto é bom. Só que apenas implementámos este quebra-cabeças mais tarde no jogo e ensinar algo irrelevante complica a aprendizagem, tornando mais difícil recordar coisas úteis mais tarde. Pior ainda, empilhar objetos para escapar de um espaço tornou-se num problema mais tarde e tivemos de prevenir isso ativamente em várias áreas. Com tantos objetos baseados na física, bloquear este comportamento sem colocar tetos em todo o lado não era uma opção. No fim de contas, esperávamos que os jogadores não pensassem demasiado nesta lição inicial. E quando os testes provaram que ficavam presos mais tarde, tivemos o cuidado de não os lembrar disso."
N/A4032"#commentary\cn_118_welcome.mp3" "[ Gabe Newell ] Chamo-me Gabe Newell e dou mais uma vez as boas-vindas ao Half-Life 2. Já passaram mais de vinte anos desde o lançamento do jogo. Nesta atualização de aniversário, tentámos responder ao máximo possível de pedidos da comunidade. Embora este não fosse o primeiro na lista de pedidos dos fãs, sei que muitas pessoas gostariam de ter um modo de comentário, por isso estamos contentes por finalmente criarmos um. Além de ser um desafio recordar muitos dos detalhes do desenvolvimento do Half-Life 2, também não foi fácil rever o código de programação de há duas décadas e tentar perceber o que estávamos a pensar naquela altura. Além de adicionarmos comentários, corrigimos muitos bugs antigos e tentámos deixar as coisas em melhor estado. E, desta vez, pelo menos temos o luxo de conhecer o resultado final. Para ouvirem o conteúdo de um ícone de comentário, coloquem a mira sobre o símbolo flutuante de comentário e primam a tecla \"Usar\". Para parar o comentário, coloquem a mira sobre o ícone rotativo e primam novamente a tecla \"Usar\". E digam-nos o que acharam. Podem contactar-me através do endereço de e-mail gaben@valvesoftware.com. Obrigado e divirtam-se!"
N/A4033"#commentary\cn_119_metrocop_shoving_citizens.mp3" "[ Josh Weier ] Só andámos uns metros e já temos problemas para resolver. Introduzimos o Metrocop (um inimigo que vamos acabar por pedir aos jogadores para matar), para dar um vislumbre do mundo em que estão a entrar. É um momento simples que mostra a relação entre os Metrocops e os cidadãos e, por extensão, o jogador. Ao mesmo tempo, reforçámos a existência da simulação física, mostrando como os NPCs podem interagir com objetos de forma casual. Ver algo como uma mala bater noutra e soltar-se era inédito naquela altura. Estes momentos na Estação Ferroviária, onde combinámos vários objetivos, foram os mais bem-sucedidos. Parecem muito naturais, como se o jogo não estivesse a fazer uma pausa só para explicar algo."
N/A4034"#commentary\cn_120_fall_damage.mp3" "[ Kerry Davis ] Ensinar os jogadores a fazer as coisas é essencial. Mas, para que tomem decisões com confiança, também têm de entender as regras mais subtis. Este pequeno momento aborda duas dessas regras: em primeiro lugar, mostra a distância que se pode cair sem sofrer dano. Em segundo, introduz o \"vocabulário\" do jogo, como o jogo vai comunicar. Os jogadores costumam preocupar-se em sofrer danos de queda, mas também em dar um passo que não podem voltar atrás. Por isso, neste caso, uma caixa para aterrar sinaliza que cair é seguro e é o caminho a seguir. E quando a caixa se parte, reforça a simulação física e é a primeira vez que os jogadores descobrem que podem partir objetos maiores."
N/A4035"#commentary\cn_121_sweeping_vortigaunt.mp3" "[Laura Dubuk] Outro momento narrativo importante e mais uma referência ao sistema de física: aqui mostramos como os Vortigaunts se encaixam neste novo mundo, uma grande mudança em relação ao papel de inimigos que tinham no Half-Life 1. Como tantos outros momentos na Estação Ferroviária, o Vortigaunt varredor surgiu da nossa busca incansável de encontrar formas de mostrar as personagens a interagir de forma natural com o sistema de física. Porque devíamos dizer aos jogadores que os Vortigaunts são amigáveis, se podemos mostrar um a varrer o chão e a mover objetos simulados? Nada diz \"Não disparem contra mim!\" como alguém que esteja a limpar."
N/A4036"#commentary\cn_122_blocking_tutorials_2.mp3" "[ Robin Walker ] Há duas falhas a destacar neste tutorial. Primeiro, os jogadores podem torná-lo impossível ao atirar todas as caixas pela janela, o que não é ideal. Se fizerem isso, ficam presos e incapazes de continuar, o que consideramos um bug que interrompe o jogo e temos de corrigir. A solução ideal teria sido ajustar o tamanho das janelas ou das caixas para que apenas o jogador pudesse passar. O problema é que só percebemos isso demasiado tarde no processo de desenvolvimento e fazer mudanças simples como esta pode ter consequências imprevisíveis. E mesmo antes do lançamento, além disso. Este problema também era apenas teórico. Não tivemos casos de jogadores de teste a fazerem isso. Os nossos testes neste espaço decorreram sem problemas, com os jogadores a aprenderem o que precisavam e a seguirem em frente. Uma alteração no design da sala nesta altura podia ter interrompido este sucesso de formas imprevisíveis. Assim, optámos por uma solução mais conservadora e menos elegante. Se tiverem curiosidade, experimentem atirar todas as caixas pela janela e vejam o que acontece."
N/A4037"#commentary\cn_123_playground.mp3" "[ Brian Jacobson ] Quando discutimos formas de destacar a simulação física no ambiente da cidade, um parque infantil foi a escolha natural. E para os jogadores que prestam atenção ao Dr. Breen, também recorda o preço da rendição da humanidade aos Combine. Optámos por usar algumas estruturas de parques infantis com potencial físico interessante e começámos a criar ajustes. Mesmo com a simulação física avançada que tínhamos, algumas configurações como esta exigiam ajustes manuais, uma vez que alguns objetos completamente simulados interagiam com objetos não simulados ou parcialmente simulados, como o jogador ou a geometria estática do mundo. Pode pensar-se que uma simulação é capaz de suportar grande parte da carga da implementação, mas mesmo vinte anos depois, é raro isso acontecer. Quando estávamos a trabalhar no parque infantil, no fim da fase de desenvolvimento, ainda não conseguíamos fazer com que o atrito do escorrega fosse correto. Por isso, decidimos partir a escada para que o jogador não conseguisse subir. Mas pode simplesmente subir pela frente. Os jogadores acabam sempre por encontrar uma forma de terem a última palavra."
N/A4038"#commentary\cn_124_pick_up_that_can.mp3" "[ Charlie Brown ] Contextualizar tutoriais, criar um cenário da história em que aconteçam, permite-nos fazer mais do que simplesmente interromper o jogo para ensinar algo aos jogadores. Podemos acrescentar um valor narrativo. Neste caso, ensinamos o jogador a disparar objetos em conjunto com uma narrativa que dá uma escolha como resposta. Depois de ver os Metrocops a abusar de cidadãos, pareceu-nos certo colocar o jogador numa posição semelhante em seguida. Se o jogador tiver uma opinião sobre a forma como os cidadãos deviam ter reagido, agora pode expressá-la. Os testes provaram que a maioria obedeceu ou recusou o pedido de apanhar a lata, mas alguns tentaram evitar completamente o confronto. Outros obedeceram inicialmente, mas depois retaliaram após se sentirem humilhados. Ao manter o momento relativamente restrito, tanto em termos de ações do jogador como do próprio espaço, conseguimos reagir apropriadamente a qualquer escolha que fizessem."
N/A4039"#commentary\cn_125_promises.mp3" "[ Danika Rogers ] No início de um jogo Half-Life, um dos nossos objectivos é fazer promessas aos jogadores, dando-lhes uma ideia do que podem esperar mais tarde. Todos os filmes, séries ou livros, o melhor entretenimento faz isto de alguma forma. Os jogos não são exceção. As promessas num jogo Half-Life podem ter várias formas. Algumas simples, como um vislumbre de algo intrigante ou mais complexas, como as interações com os Metrocops. Ao colocar um jogador numa posição impotente contra eles, preparamos um momento futuro em que finalmente poderão retaliar."
N/A4040"#commentary\cn_126_exploration.mp3" "[ David Sawyer ] Depois de sermos levados através da Estação Ferroviária pelos Metrocops, quisemos dar ao jogador a hipótese de explorar. Esta praça oferece várias formas de interagir com os Cidadãos, Metrocops, Scanners e com as infraestruturas da cidade. O objetivo era que estas interações continuassem a construir o mundo sem recorrer a tutoriais. Por isso, melhorámo-las até que funcionassem de forma natural, sem precisar de treinos."
N/A4041"#commentary\cn_127_early_game_exploration.mp3" "[ David Speyrer ] Até chegar a esta praça, o jogador não teve de pensar muito no caminho que seguia, já que era direto. Mas aqui quisemos incentivar a exploração, e para isso foi preciso tornar o caminho a seguir menos óbvio, o que pode criar uma sensação de se estar perdido, ou pior, confusão. Este tipo de mudança pode ser difícil, especialmente no início do jogo, quando os jogadores ainda estão a aprender dicas. Neste caso, torna-se ainda mais complicado devido aos pontos de verificação dos campo de força, que permitem que os cidadãos NPC se movam, mas restringem o jogador, fazendo com que muitos jogadores na fase de testes tivessem julgado que havia uma forma de os contornar. No fim de contas, foi a enorme quantidade de testes que ajudaram a encontrar a visibilidade certa da saída do beco, usando iluminação, o enquadramento e uma caixa de madeira: um objeto que os jogadores já tinham usado como sinal de que estavam a seguir a direção certa, tudo para os orientar de forma subtil."
N/A4042"#commentary\cn_128_strider.mp3" "[ Doug Wood ] Este momento simples é uma promessa de que os jogadores vão encontrar esta coisa enorme mais tarde. Até uma cena simples como esta requer muitos testes e iterações por causa do objetivo do Half-Life em não retirar o controlo ao jogador. Como podem imaginar, é preciso fazer vários ajustes para garantir que o maior número possível de jogadores olha para o sítio certo, no momento certo. O traçado das ruas e a cena do Metrocop foram preparadas para orientar o olhar, enquadrando o Strider na perfeição quando aparece."
N/A4043"#commentary\cn_129_physics_simulation.mp3" "[ Jay Stelly ] Embora o Half-Life 2 tenha começado por ter uma simulação de leis da física funcional, foram necessários vários anos de trabalho adicional na simulação e na integração com o jogo até sentirmos que estávamos a ir ao encontro das ambições dos designers. Manter um nível de qualidade e desempenho que pudesse ser lançado era algo que sabíamos que seria um desafio, mas a questão mais subtil era descobrir o que tínhamos de simular e em que medida. Não é possível simular tudo. E, mesmo que fosse, por motivos de design, a experiência é superior se não o fizermos. Em muitos casos, distorcemos propositadamente a simulação para melhorar a experiência de jogo. Estes ajustes costumam passar despercebidos porque se alinham com as intenções dos jogadores. Por exemplo, desativámos as colisões entre jogadores e objetos grandes para que fossem capazes de rodar em espaços apertados. Também ajustámos o disparo alternativo da espingarda dos Combine para orientar suavemente a bola dos Combine na direção dos inimigos de forma a ser mais eficaz."
N/A4044"#commentary\cn_130_physics_simulation_2.mp3" "[ Jeff Lane ] As áreas onde o design ou outras restrições tiveram impacto na simulação física exigiram mais alguns ajustes para evitar que a simulação falhasse. Por exemplo, no início, tentámos aumentar a simulação com a entidade do jogador, ou seja, tentámos integrar mais o movimento do jogador na simulação física do mundo. Sabíamos que poderia fazer com que o movimento fosse menos preciso, mas contávamos que pudesse criar experiências novas. Porém, após termos ajustado o movimento para corresponder à versão menos simulada, descobrimos um grande problema: a força física necessária para o jogador se mover à velocidade normal era tão grande que um simples choque noutros objetos simulados poderia matá-lo. Criámos outras iterações relacionadas, mas não conseguimos encontrar uma solução que nos agradasse e voltámos ao movimento menos simulado. No entanto, isto acabou por não ser propriamente no caminho mais fácil. Encontrámos novos desafios na forma como o jogador com menos integração na simulação interagia com os objetos com maior simulação. Mas permitiu-nos criar a experiência de movimento precisa que procurávamos."
N/A4045"#commentary\cn_131_playtesting.mp3" "[ John Morello ] A fase de testes é uma parte essencial na criação dos nossos jogos. Não conseguimos prever completamente como os jogadores respondem ou o que retiram do que construímos. Por isso, testamos para aprender e, com alguma sorte, melhorar. Durante a fase de testes, não orientamos nem conversamos com os jogadores, mesmo que fiquem bloqueados, já que é extremamente improvável que estejamos sentados ao lado de um jogador depois do jogo ser lançado. O objetivo é que quem testa o jogo se esqueça que está a testar e jogue como se estivesse em casa. Como as interrupções correm o risco de distorcer os dados, só intervimos se houver um bug a bloquear um progresso ou, mais raramente, se o comportamento do jogador for tão confuso que precisemos de entender no que estão a pensar."
N/A4046"#commentary\cn_132_playtesting_anecdote_1.mp3" "[ Matt Boone ] Um teste que nunca vou esquecer recordou-nos que não conseguimos ter a certeza do que os jogadores estão a pensar ou que lições retiram da sua experiência. Este jogador de teste, depois de jogar desde o início e ter ficado preso a tentar abrir uma porta, passou vários minutos a alternar entre o jogo e as definições do teclado. Quando perguntámos o que procurava, disse que procurava os controlos do Inventário, pois pensava que podia usar um objeto que tinha apanhado antes para abrir a porta. Embora tivesse recolhido e largado vários objetos que seguem as leis da física, o jogador não entendeu o que estava a acontecer. Julgava que se premisse a tecla de usar enquanto segurava um objeto, esse objeto seria guardado num inventário, já que o objeto caía diretamente para baixo. Nós sabíamos que isto era apenas a gravidade a funcionar, mas a suposição que o jogador fez não era descabida. Em alguns jogos de aventura dessa altura, podia-se deslizar objetos para um inventário invisível da mesma forma. Explicámos-lhe que o jogo não tinha inventário e o teste continuou. Mais tarde, pensámos se teríamos de resolver este problema, mas como foi o único jogador a sentir confusão e todas as possíveis soluções eram mais pesadas do que o necessário, decidimos que se tratava de algo secundário, que não precisava de ser resolvido. Mas serviu como lembrete de que até os detalhes mais subtis e ignorados podem enganar um jogador."
N/A4047"#commentary\cn_133_cratebaby.mp3" "[ Scott Dalton ] Esta boneca tem um longo legado. Nos longos meses de testes internos, alguns membros da equipa transformaram-na num desafio. Uma forma de tornar a 47.ª partida mais divertida. Colocaram a boneca dentro de uma caixa azul e viam até onde conseguiam transportá-la. Após o lançamento do Half-Life 2, a comunidade também começou a transportar a boneca, acrescentando as suas próprias histórias e regras. Alguns anos depois, quando trabalhávamos no Episode Two, foi a inspiração para a conquista Little Rocket Man, em que os jogadores tinham de transportar um gnomo de jardim chamado Chompski durante todo o episódio. O Chompski regressou ainda no em Left 4 Dead 2, na conquista Guardin' Gnome, em que os jogadores tinham de o transportar durante a campanha Dark Carnival. Este tipo de interação com os jogadores é uma das partes mais satisfatórias da criação de jogos. Concebemos jogos com algumas teorias em mente, mas nunca se sabe que vão tomar até que os jogadores lhes ponham as mãos em cima."
N/A4048"#commentary\cn_134_the_citadel.mp3" "[ Eric Kirchmer ] Queríamos que a primeira vista do jogador na Cidade 17 destacasse a Cidadela e o seu domínio sobre a cidade, representando o poder total dos Combine sobre a humanidade. Também teria de funcionar como um objetivo claro. Logo no início, podemos de ver onde acabará a nossa aventura. Mas, apesar do tamanho, muitos dos jogadores de teste não se apercebiam. A noção de profundidade e escala é complexa num monitor de computador. Quem jogou algo em RV, deve ter reparado que a escala parece mais natural. Seja como for, neste caso, a posição da Cidadela acima do jogador também não ajudou, e é por esse motivo que os FPS treinam os jogadores a concentrarem-se diretamente à frente ou nos seus pés. Para aumentar as hipóteses de os jogadores repararem na Cidadela, colocámos pássaros a voar em direção à estrutura. Foi um truque subtil que ajuda a orientar a visão de quem joga."
N/A4049"#commentary\cn_135_close_captions.mp3" "[ Yahn Bernier ] Durante a fase de desenvolvimento do Half-Life 2, algumas pessoas interessadas em acessibilidade incentivaram-nos a explorar o sistema de legendas que tínhamos criado para o Half-Life 1. Pediram-nos um sistema de legendas completo para captar todos os sons do jogo, não só os diálogos. Acabou por ser um desafio mais difícil do que esperávamos. O Half-Life 2 tinha uma grande variedade de sons e a categorização destes sons para legendas foi essencial. Definir prioridades também foi fundamental: o diálogo tinha de se destacar e indicar claramente quem estava a falar. Os sons ambiente, como combates à distância, eram importantes para definir o ambiente em alguns níveis, mas tinham de ter menos destaque se houvesse um inimigo a disparar perto. Como os designers de níveis também reutilizavam sons em contextos diferentes, um som podia precisar legendas numa área, mas não noutra. No fim, cada som teve uma legenda, formatadas quase como uma versão em HTML, dando o controlo sobre o estilo visual de cada legenda. Tal como acontece no caso dos ficheiros de áudio, os dados das legendas eram demasiado grandes para guardar na memória. Por isso, criámos um sistema de cache assíncrono para uma gestão eficaz."
N/A4050"#commentary\cn_136_the_raid.mp3" "[ David Sawyer ] Esta secção, onde os Metrocops invadem o apartamento enquanto o jogador está lá dentro, precisou de várias iterações até ficar correta. Normalmente, concebemos o Half-Life para permitir que os jogadores sigam o seu próprio ritmo, já que os jogadores costumam mover-se no jogo de diferentes formas. Alguns jogadores correm e ignoram tudo o que não seja uma ameaça, outros mexem em tudo. Por isso, sempre que temos de forçar um ritmo específico, é difícil garantir que os jogadores percebam o ritmo pretendido e joguem dessa forma. Como foi a primeira vez que fizemos isto, tivemos de nos esforçar para deixar bem evidente que era preciso correr rapidamente e que não havia tempo para explorar."
N/A4051"#commentary\cn_137_materials_and_shaders.mp3" "[ Gary McTaggart ] O Half-Life 2 foi lançado durante uma grande mudança nos gráficos 3D, quando a indústria mudou de texturas para materiais e shaders. No Half-Life 1, todas as superfícies tinham uma textura. Uma imagem envolvida nos polígonos da superfície. Mas no Half-Life 2, só cinco anos depois, todas as superfícies tinham um material e um shader. O shader era um código que personalizava a forma como a superfície era renderizada. O material definia algumas propriedades, sobre como a superfície se comportava fisicamente e de que forma respondia a funcionalidades de jogabilidade. Também tinha referências de texturas e outros parâmetros para que o shader utilizasse na renderização. Assim, os artistas e designers tinham mais controlo sobre o visual e comportamentos. No entanto, isto tinha uma desvantagem. O Half-Life 1 podia ser executado num computador com apenas um CPU, mas o Half-Life 2 já exigia um GPU, porque os cálculos necessários para materiais e shaders tinham sido pensados especificamente para um GPU. Esta porta de vidro refratora é um bom exemplo de um shader personalizado. Mas todas as superfícies nesta cena têm um shader."
N/A4052"#commentary\cn_138_the_raid_2.mp3" "[ Miles Estes ] Além de termos de garantir que os jogadores sentissem pressão para avançar, também tínhamos de garantir que o ataque era infalível. Não podia haver forma de o jogador o evitar ou regressar pelos Metrocops. O desafio não era que os jogadores tentassem quebrar esta cena, mas que muitos jogadores poderiam entrar em pânico e correr ao acaso assim que percebessem que havia uma ameaça. Este momento tinha de ter um equilíbrio delicado. Queríamos criar uma fuga de cortar a respiração, uma sensação de perigo real, mas também que os jogadores conseguissem passar à primeira e sentissem que tinham escapado à justa. Para conseguir isto, mantivemos o caminho em frente limpo e a fazer lembrar o que tinham acabado de percorrer no piso anterior. Há muitos gatilhos posicionados com cuidado a controlar as ameaças que aparecem à frente e atrás para manter a pressão e dar aos jogadores tempo suficiente para estarem à frente dos perseguidores."
N/A4053"#commentary\cn_139_health_and_no_hud.mp3" "[ Dave Riller ] A sequência de perseguição nos telhados foi um desafio de design único. Não queríamos que fosse um verdadeiro obstáculo, e o melhor cenário era que os jogadores conseguissem passar à primeira. Mas também queríamos criar uma sensação de perigo real, em que os jogadores se sentissem ameaçados se não continuassem a avançar. O desafio era que, sem o fato HEV, os jogadores não tinham um HUD, o que significa que não tinham forma de ver o dano ou vida. Depois de termos feito algumas experiências, criámos um sistema de vida especial para esta secção, usando um brilho vermelho à volta do ecrã para indicar o dano sofrido. Os jogadores reagiram como esperávamos, interpretando isto como sinal para continuar a avançar, e a perseguição aconteceu como esperado. Além disso, fizemos com que a vida regenerasse rapidamente para que o brilho não se mantivesse. Assim reforçávamos a ideia de que correr era a escolha certa e garantimos que os jogadores não eram atingidos por uma bala perdida no final só porque tinham demorado ou hesitado."
N/A4054"#commentary\cn_140_playtesting_anecdote_2.mp3" "[ Jakob Jungels ] Na secção seguinte, o jogador tinha de ser derrubado para que a Alyx o pudesse salvar. Como tínhamos pouco tempo e recursos, simplificámos este encontro o mais possível. Reutilizámos sistemas e fizemos com que se desenrolasse como uma sequência de combate normal, mas com um evento personalizado acionado quando o jogador \"morria\". Depois alguns testes para ajustar o timing, avançámos. Mas, com o lançamento a aproximar-se, deparámo-nos com um problema com um tester que guardava rapidamente e constantemente, e carregava imediatamente em carregamento rápido sempre que pensava que tinha falhado. Quando um Metrocop o atingia, carregava rapidamente antes que a Alyx aparecesse e repetiu mais de dez vezes antes de lhe pedirmos para parar. Nesta fase de desenvolvimento, na fase final de correção de bugs, tivemos de nos limitar a corrigir problemas que causassem crashes, já que até as mais pequenas alterações podiam causar crashes mais importantes. Como este era um caso extremamente raro, porque a maioria dos testers não tinha tido problemas, fizemos poucas alterações. Reduzimos o atraso entre o derrube e a primeira fala da Alyx e mudámos a cor do fade out para branco em vez de preto. Não era tão útil, já que os jogadores ainda não tinham morrido vezes suficientes para associar o preto à morte. Pensámos desativar o carregamento rápido nos poucos segundos em que a cena se desenrolava, mas pensámos que isso podia criar um bug que desativasse o carregamento rápido."
N/A4055"#commentary\cn_141_character_reactions.mp3" "[ Ariel Diaz ] Perceber ao que as personagens deveriam reagir, e de que forma, foi um desafio constante. No fim de contas, queríamos que o jogo respondesse sempre à ação dos jogadores. No entanto, qualquer resposta do jogo podia ser entendida como uma recompensa pelo jogador. Portanto, aquilo a que as personagens reagiam e o que ignoravam ensinaria o jogador sobre o tipo de ação que o jogo espera. Como resultado, garantimos que respondíamos a coisas que queríamos que fizessem mais, como jogadores a mexer em dispositivos no Laboratório e ignorámos comportamentos que queríamos ver menos, como jogadores a bater na cara do Kleiner com uma caixa. A sério, vimos um tester bater no Kleiner durante cinco minutos seguidos."
N/A4056"#commentary\cn_142_choreography.mp3" "[ Bill Fletcher ] O sistema que construímos e iterámos para demonstrar a narrativa do Half-Life 2 tinha o nome interno de Choreo, abreviatura de \"coreografia\". No início, pensámos que seria útil imaginar que estávamos a escrever uma peça em que um dos atores não conhecia o guião. Precisávamos de ter um sistema capaz de controlar os outros atores, movê-los pelo palco, que apresentasse as performances e dissesse as suas falas. Para tal, os outros atores teriam de combinar os nossos comandos direcionais com respostas dinâmicas às posições e aos comportamentos dos jogadores. O timing seria um grande desafio, já que qualquer parte da cena podia ter de ser alongada, contraída ou até pausada, dependendo do que os jogadores fizessem."
N/A4057"#commentary\cn_143_phoneme_extraction.mp3" "[ Bill Fletcher ] Outra ferramenta essencial que integrámos no FacePoser foi o Phoneme Editor. Esta ferramenta processava as falas dos dobradores e extraía fonemas para gerar animações básicas de sincronização dos lábios para as personagens. Para as personagens principais, os animadores usaram esta ferramenta como ponto de partida para criar animações personalizadas de alta qualidade para cada fala e integrar uma animação facial completa. Porém, numa cena dinâmica com o Choreo, os animadores não sabiam exatamente o que o resto do corpo do ator estaria a fazer. Por isso, tivemos de sobrepor os comandos e os tempos do Choreo no FacePoser para que o ator fosse capaz de responder de forma dinâmica ao jogador."
N/A4058"#commentary\cn_144_delivery.mp3" "[ Ken Birdwell ] Tivemos de fazer muitas iterações e testes até encontrar o equilíbrio certo entre informação e ligação emocional nas principais cenas com o Choreo. Todas as cenas tinham imensa informação que tinha de ser transmitida aos jogadores, mas não podíamos simplesmente ter personagens a falar. Os jogadores começariam a pensar nelas mais como placas de sinalização do que como pessoas. Tínhamos de ter tempo para que as personagens interagissem entre si, para que o jogador observasse as suas relações. Ao mesmo tempo, tínhamos de expandir o mundo, dando ao jogador noção do que aconteceu na sua ausência. Tudo isto tinha de ser feito com muito cuidado e sem demorar muito. Queríamos que o jogo funcionasse para os jogadores que estivessem menos envolvidos na narrativa. A animação tornou-se numa ferramenta muito útil para comunicar ligações emocionais entre personagens, transmitindo a profundidade de um momento rapidamente e sem exageros. O humor era outra ferramenta utilizada que ajudava a romper uma configuração e a desarmar o jogador quando uma situação ficasse demasiado pesada."
N/A4059"#commentary\cn_145_alyxs_kiss.mp3" "[Ken Birdwell] É um momento pequeno, mas o beijo na cara que a Alyx dá ao Eli foi importante. Eventualmente, vamos pedir ao jogador para salvar o Eli e queremos que se preocupe com ele. Para criar esta ligação emocional, tínhamos de mostrar o afeto entre a Alyx e o Eli. Não queríamos exagerar no diálogo nem escrever algo grandioso. Tinha de ser um momento genuíno, não performativo. E conseguimos criar as subtilezas do momento para que tivesse o tom certo."
N/A4060"#commentary\cn_146_storytelling.mp3" "[ Bill Van Buren ] Criar uma sensação de imersão foi um princípio fundamental na nossa abordagem à narrativa do Half-Life 1. Isto fez com que tivéssemos restrições autoimpostas quanto a nunca (ou pelo menos raramente) tirar o controlo ao jogador e manter o avatar em silêncio. Estas restrições tornaram a narrativa mais desafiante em alguns pontos, mas julgámos que era importante mantê-las no Half-Life 2. Ao aderir a estes princípios, esperávamos explorar uma narrativa mais complexa e interativa."
N/A4061"#commentary\cn_147_archetypes.mp3" "[ Bill Van Buren ] Queríamos criar ligações narrativas entre o Half-Life 1 e o Half-Life 2 através das personagens. A ideia era criar personagens que fossem representações dos arquétipos do Half-Life 1 para que os jogadores sentissem que eram familiares, como se os tivessem conhecido no Half-Life 1 num momento de que não se lembravam. O Dr. Kleiner foi inspirado no modelo de cientista que considerávamos mais icónico e a sua personalidade foi moldada por Hal Robins, cuja voz e performance já tinham definido os cientistas do Half-Life 1. Certo dia, enquanto estávamos a tentar criar esta personagem, a cara do Dr. Kleiner entrou em cena, porque, por mero acaso, partilhávamos o elevador com um contabilista de um escritório de outro piso. Olhámos para ele e ficou evidente que \"esta é a cara do Dr. Kleiner\". Felizmente, ele foi muito recetivo quando lhe perguntámos se podíamos fotografá-lo para a personagem de um videojogo."
N/A4062"#commentary\cn_148_tone.mp3" "[ Bill Van Buren ] Definir o tom certo para as personagens e para os diálogos foi essencial. Procurámos um estilo de interações respeitosas, mesmo agradáveis, com os jogadores, evitando tudo o que parecesse ser demasiado subserviente. Este equilíbrio foi particularmente complicado com a Alyx, que tinha de apoiar o jogador sem comprometer a força da própria personagem, algo que pensámos ser essencial para que os jogadores a respeitassem. Como a relação dela com o Eli é um fator central nas motivações dos jogadores, era importante que os jogadores gostassem dela e a quisessem ajudar. Também quisemos criar um contraste entre a camaradagem que existia entre os aliados do jogador com as hostilidades de Breen e dos Combine, inspirando um sentimento de indignação nas batalhas futuras."
N/A4063"#commentary\cn_149_voice-actors.mp3" "[ Bill Van Buren ] Para poder criar personagens mais reativas e multidimensionais no Half-Life 2, tivemos de evoluir a abordagem com os dobradores. Embora seguir um guião com um mínimo de indicações fosse suficiente para a maioria dos diálogos dos NPCs no Half-Life 1, para o Half-Life 2, decidimos dar aos atores mais oportunidades de se envolverem para ajudar a definir as personagens e dar-lhes vida. Partilhámos muito mais contexto da história com os atores, mostrámos o mundo do jogo, os ambientes que as personagens habitavam e outras personagens com quem iriam interagir. Procurámos atores que fossem capazes de pegar nestas informações e transpô-las para as suas performances de forma a elevarem as personagens para além do que tínhamos imaginado. Fizemos muitas sessões com os atores principais para que assimilassem e desenvolvessem as personagens ao longo do tempo. Nas cenas em que as personagens interagem umas com as outras, demos várias dicas usando performances de outros atores na mesma cena para criar uma sensação mais natural. Embora tivéssemos chegado ao estúdio com um guião e um plano para a sessão de gravação, demos abertura aos atores para implementarem as suas próprias ideias para as personagens e para as performances. A presença de animadores nas sessões de dobragem também foi importante, já que eram os responsáveis por ligar o diálogo das personagens com as ações físicas e expressões de forma a criar a cena ideal no Choreo. Por vezes, os animadores percebiam que os planos originais para o desenrolar de uma cena evoluíam muito depois de trabalharem com a equipa de dobragem."
N/A4064"#commentary\cn_150_citizens.mp3" "[ Bill Van Buren ] Quando tivemos de criar os cidadãos humanos da Cidade 17 e do mundo exterior, optámos por incluir várias raças, idades e géneros. Além de dar contexto narrativo sobre a escravização de toda a humanidade pelos Combine, demonstrou como era importante para nós que qualquer pessoa que jogasse pudesse ver-se representada na Resistência, com todas as pessoas da Terra unidas contra os Combine. Embora tenhamos encontrado muitos candidatos para utilizar como referência na criação dos cidadãos através das nossas vidas e ligações quotidianas, acabámos por usar os classificados do jornal Seattle Times para encontrar os rostos que tínhamos imaginado."
N/A4065"#commentary\cn_151_alyx.mp3" "[Dhabih Eng] Acertar no design da Alyx foi um grande desafio. Queríamos que os jogadores a respeitassem e se preocupassem com ela. Salvar o Eli era um objetivo fundamental a meio do jogo e sabíamos que fazer com que os jogadores se preocupassem com esse objetivo seria mais fácil se também se preocupassem com a Alyx e com a relação que tinha com o pai. Desenhámos, escrevemos diálogos e escolhemos uma voz para a Alyx intencionalmente, para que fosse inteligente, capaz e identificável no mundo controlado pelos Combine, e também para que fosse uma presença atraente e carismática. O objetivo era evitar a objetificação, exagero e hipersexualidade que muitos jogos dessa década tinham, uma vez que isso poderia prejudicar os nossos objetivos para esta personagem."
N/A4066"#commentary\cn_152_lab_interactivity.mp3" "[ Dhabih Eng ] Nas cenas com o Choreo, prendemos o jogador durante algum tempo para nos focarmos nas personagens e na narrativa. Para acomodar jogadores diferentes, como os que se envolvem na história e os que não conseguem ficar parados mais de um segundo, precisávamos de encontrar um fluxo constante de detalhes interessantes no ecrã. Então, espalhámos elementos narrativos pelo cenário, garantindo que alguns eram interativos, como brinquedos. Em alguns casos, integrámos narrativas neles, como o miniteletransportador de catos que indica a falha iminente do teletransportador. Era um equilíbrio delicado. Demasiado interesse visual podia distrair os jogadores do mais importante da cena. No fim de contas, o Laboratório de Kleiner teve pouca interatividade, já que foi a primeira grande cena criada com o Choreo. Mais tarde, no Laboratório de Eli, explorámos esta questão mais a fundo, e fizemos com que as personagens prestassem atenção ao que os jogadores fizessem."
N/A4067"#commentary\cn_153_gestures.mp3" "[ Doug Wood ] Cada personagem tinha uma biblioteca de animações simples, chamada Gestos, que podíamos sobrepor facilmente com outros movimentos do corpo. Embora tenha sido planeada como uma forma de poupar na produção, permitindo-nos reutilizar animações ao longo do jogo, descobrimos que tinham mais utilidades. Os humanos repetem determinados movimentos e estes podem ser marcadores de uma personalidade específica. Assim, a biblioteca de Gestos acabou por captar a essência de cada personagem, ajudando a unificar a compreensão da equipa de animação sobre quem eram estas personagens. Isto ajudou os animadores a partilharem a carga de trabalho de qualquer personagem entre si, que era normalmente exigido pela produção."
N/A4068"#commentary\cn_154_interactive_storytelling.mp3" "[ Erik Johnson ] Quando começámos a trabalhar no Half-Life 2, as narrativas nos jogos ou eram de alta fidelidade e lineares ou de baixa fidelidade e interativas. Sabíamos que os jogadores já conheciam narrativas de alta qualidade em jogos, mas nunca tinham sido colocados no meio de uma, podendo observar o desenrolar à sua volta ou interagir e examinar qualquer parte de perto. Embora este objetivo nos entusiasmasse, ainda não sabíamos como funcionaria ou que tipo de tecnologia teríamos de usar para que acontecesse. Tínhamos criado uma variedade de tecnologias narrativas no Half-Life 1, mas eram apresentadas à frente do jogador e não tinham a interatividade e fidelidade que procurávamos. Por isso, o Laboratório de Kleiner tornou-se na secção que utilizámos como local de testes para descobrir como a narrativa interativa funcionaria."
N/A4069"#commentary\cn_155_monitors.mp3" "[ Ido Magal ] Usamos muitos monitores para expor narrativa no Half-Life 2 e nos episódios. Tantos que até gozamos connosco próprios. O problema é que são mesmo muito úteis. Expandem o mundo ao mostrar eventos a acontecer noutros sítio e são uma forma fácil de fazer com que as personagens conversem sem termos de explicar como chegaram ao sítio onde está o jogador. Qualquer pessoa que tenha escrito uma história, especialmente uma que tenha um elenco vasto, sentiu a frustração de tentar criar motivos naturais para que todas as personagens se encontrem no mesmo lugar. Neste caso, ficámos muito satisfeitos com a forma como o monitor ajudou a Alyx a teletransportar-se e aparecer rapidamente no Laboratório do Eli, para que tudo parecesse real e interligado."
N/A4070"#commentary\cn_156_scene_interactivity.mp3" "[ Jeff Lane ] Em alguns pontos das cenas com o Choreo, pedimos aos jogadores para agir. Mais do que simplesmente dar-lhes algo para os manter envolvidos, estes momentos também tinham funções importantes. Primeiro, davam informação ao jogador caso estivesse distraído com outra coisa no ambiente. A cena podia \"pausar\" em segurança até que o jogador concluísse essa tarefa, garantindo que voltasse e prestasse atenção. Ao mesmo tempo, ajudavam-nos a posicionar o jogador onde tinha de estar, o que foi útil para enquadrar a cena e garantir que visse algo importante. Em alguns casos, eram duplamente valiosos, porque utilizávamos estes momentos para treinar o jogador. Neste caso, está a aprender a interagir com fichas e tomadas, uma habilidade útil para usar em quebra-cabeças mais tarde."
N/A4071"#commentary\cn_157_kleiners_lab.mp3" "[ Marc Laidlaw ] O Laboratório de Kleiner foi a primeira parte da narrativa em que trabalhámos e a que demorou mais tempo a ser concluída. Para além do papel de lançar o jogador no jogo, acabou por se tornar numa visão unificadora para a equipa de desenvolvimento em termos de narrativa. Quando começámos a construir as personagens e a narrativa em torno do jogador, surgiram muitas questões, e todas elas pareciam ser grandes riscos para o jogo. Os jogadores seriam capazes de obter as informações mais importantes da cena? Éramos capazes de fazer com que se preocupassem com as personagens? Como poderíamos dar apoio aos jogadores com distintos níveis de investimento na história? Qual seria o custo de produzir uma cena destas? E quantas mais teríamos de criar? Estas e muitas outras eram perguntas que não poderíamos responder até termos construído parte suficiente da cena e testado com muitos jogadores. Foi frustrante, mas ao contrário de muitos outros problemas que enfrentámos, não eram questões que pudéssemos responder com confiança até termos feito muita coisa. Por vezes, podemos testar ideias de jogabilidade com protótipos de baixa fidelidade, mas se um jogador não tiver interesse na narrativa quando as personagens são meros blocos, que confiança podemos ter de que um jogador se vai importar quando as personagens estiverem completamente desenvolvidas?"
N/A4072"#commentary\cn_158_characters.mp3" "[ Marc Laidlaw ] No Half-Life 1, os seguranças e cientistas podem ser descritos como arquétipos, não indivíduos. Eram abstrações de personagens com a fidelidade visual que éramos capazes de obter na altura. Mas, com o avanço tecnológico no Half-Life 2, tivemos uma oportunidade de ir além das abstrações. A maior fidelidade visual dos modelos das personagens, assim como as melhorias na animação, fizeram-nos pensar que nos podíamos concentrar na criação de personagens individuais, pessoas com quem nos conseguíssemos importar. Escrevemos diálogos reais e fizemos com que as personagens se comportassem de forma suficientemente realista para que os jogadores não pensassem neles como peões num jogo, talvez até pudessem avançar a narrativa. Em 2001, poucos anos após o início do desenvolvimento, fomos dinamizados por Ico, da Japan Studio. Dirigido por um animador, este jogo surpreendeu-nos ao usar as personagens como ligação principal com o jogador, dando-nos coragem para continuar a avançar."
N/A4073"#commentary\cn_159_writing.mp3" "[ Marc Laidlaw ] Na era do Half-Life 1, os objetivos dos jogadores nos jogos FPS ainda eram, maioritariamente, lutar e derrotar um inimigo obviamente malvado. Era difícil fazer com que os jogadores se preocupassem com as personagens quando tinham tão pouca complexidade como no Half-Life 1. Com as melhorias planeadas em termos de complexidade das personagens para o Half-Life 2, quisemos tentar tornar as personagens na força principal da narrativa. O objetivo era que as motivações dos jogadores se alinhassem com as das personagens. Que os jogadores preocupassem-se com as personagens, com as suas esperanças e receios, e quisessem que tivessem sucesso. Com esta ideia em mente, conseguimos definir uma abordagem quanto às personagens e diálogos. Queríamos criar um conjunto de personagens que gostassem e se preocupassem umas com as outras, e esperávamos que os jogadores sentissem o mesmo. Estas personagens iriam interagir de uma forma inclusiva, como um grupo de velhos amigos que veem o jogador como semelhante, alguém que esteve ausente. Se as personagens demonstrassem ligações emocionais realistas, pensávamos que também poderíamos criar uma ligação emocional com os jogadores."
N/A4074"#commentary\cn_160_animation.mp3" "[ Miles Estes ] Criar movimentos humanos credíveis com várias camadas discretas de animação, exigiu muita experimentação tecnológica. Até as ações mais simples, como virar para olhar para algo ou caminhar até um sítio, ficaram mais complexas quando foram combinadas com a necessidade de responder de forma dinâmica ao jogador e aos requisitos dos comandos do Choreo. Por exemplo, o ato de virar para olhar para algo tinha de ser completamente decomposto para que uma personagem pudesse usar qualquer combinação de olhos, cabeça, ombros, tronco ou corpo inteiro para encarar um alvo. No Half-Life 1, as personagens humanas tinham os corpos separados pelas metades superior e inferior para que pudessem caminhar numa direção e virar-se para outra. No entanto, esta abordagem era demasiado abstrata para as personagens do Half-Life 2. Em vez disso, os animadores decidiram criar animações de caminhar nas oito direções da bússola, que podiam ser combinadas durante a ação."
N/A4075"#commentary\cn_161_faceposer.mp3" "[ Yahn Bernier ] A principal ferramenta que construímos para o sistema Choreo chamava-se FacePoser. Era um programa que tinha um nome vago e que permitia aos animadores esquematizar a estrutura completa das cenas numa linha temporal. A linha temporal tinha uma série de comandos Choreo para os atores e todas as informações necessárias para que os executassem. Ao sobrepor estes comandos na linha temporal, os animadores podiam descrever como um ator teria de olhar para algo enquanto conversava noutra e caminhava para outro sítio, tudo ao mesmo tempo. Mas a linha temporal não era uma sequência fixa e linear. Os atores seguiam os seus comandos, mas tinham de responder de forma dinâmica ao mundo que os rodeava. Um ator podia demorar mais tempo a deslocar-se para um local se o jogador estivesse à sua frente ou podia ter de esperar para dizer uma fala porque outro ator tinha sido atrasado pelo jogador. O FacePoser permitiu criar iterações nas cenas rapidamente , experimentando com layouts, diálogos e timings distintos. Esta possibilidade de experimentar e fazer ajustes rápidos foi essencial para encontrar as performances certas para ir de encontro aos objetivos quanto a personagens e narrativa."
N/A4076"#commentary\cn_162_choreo_commands.mp3" "[ Yahn Bernier ] Esta visualização de depuração mostra os dois comandos Choreo mais comuns que os atores recebem numa cena. São internamente conhecidos como \"olhares\" e \"movimentos\". Os atores recebem alvos para os quais olhar, por vezes, mais do que um de cada vez, e depois tentam concentrar-se no que fizer mais sentido, dependendo do estado atual. Ao mesmo tempo, podem receber comandos de movimento que dizem para se moverem para um sítio e encararem uma direção ou objeto específicos. Até estes comandos aparentemente simples são muito complexos. Uma cena pode exigir que um ator fale enquanto escreve num teclado, tudo enquanto olha para um objeto que o jogador esteja a segurar. Como não era possível prever a posição do jogador durante a reprodução, a criação de cenas como esta exigiu que dividíssemos todos os elementos da cena em várias partes e camadas. Depois, estas partes podiam ser montadas novamente conforme necessário durante a reprodução, dependendo das ações do jogador e interrompidas caso fosse necessário."
N/A4077"#commentary\cn_163_antlions.mp3" "[ Kerry Davis ] Como o jogador conduzía o buggy na Costa, tivemos de criar um inimigo omnipresente que pudesse aparecer de forma credível em qualquer lugar e agir como uma ameaça constante, para que o jogador ficasse dentro ou perto do buggy. Os Antlions que surgem da areia foram a solução perfeita. A sua grande mobilidade permitia-lhes acompanhar o buggy por pequenos períodos, ao contrário dos inimigos humanoides. Além disso, atropelá-los era bem agradável."
N/A4078"#commentary\cn_164_thumpers.mp3" "[ Adrian Finol ] Sempre que possível, damos muito valor aos momentos em que jogadores sentem que descobriram algo sozinhos. Isto faz com que o mundo tenha outra vida, em vez de ser só uma série de elementos de jogabilidade criados para o jogador. Se aceitarmos o risco de que uma percentagem de jogadores possa perder um elemento por completo, podemos seguir uma abordagem mais subtil. Seguimos esta abordagem com os Thumpers, criando cenários que os jogadores os iriam encontrar, mas com os quais não fossem obrigados a interagir. Há muitas dicas visuais e sonoras, assim como reações dos Antlions, para ajudar os jogadores a compreender o que estava a acontecer. Não garante que todos os jogadores descubram, mas os testes provaram que a maioria conseguiu."
N/A4079"#commentary\cn_165_d2_coast_09.mp3" "[ Aaron Seeler ] No reta final de desenvolvimento da Costa, chegámos a um ponto em que o código estava tão à frente do design de níveis que os programadores de jogabilidade precisavam de mais código para escrever e novas tarefas para ajudar o Half-Life 2 a ser lançado. Isto deveu-se maioritariamente às exigências dos níveis da Costa, que sobrecarregaram os designers de níveis devido à escala e utilização extensiva do terreno. Por causa disso, os programadores de jogabilidade começaram a criar encontros em menor escala. Depois, quando os designers apanharam os programadores, criaram este nível ao juntar três encontros dos programadores e preparando tudo para o lançamento."
N/A4080"#commentary\cn_166_final_scene.mp3" "[ Bill Van Buren ] Prender o jogador num pod para o confronto final no escritório de Breen foi um compromisso, mas permitiu que nos concentrássemos nas personagens que não podíamos ter noutro lugar. Todas as histórias das personagens chegam às suas conclusões nesta cena. Limitar o ponto de vista do jogador cria uma oportunidade para obter uma recompensa emocional real. Uma cena climática criada pela combinação de diálogos, performances de dobragem e animações. Esta cena foi um grande desafio do ponto de vista de produção: criar os bloqueios e o movimento de forma correta, encontrar o timing e uma sinergia emocional ideais e uma ligação entre todas as animações individuais e performances de dobragem que tinham sido gravadas separadamente. Tivemos de fazer vários ajustes para obter alguma sinergia dramática e parecia mesmo que as personagens estavam todas conectadas."
N/A4081"#commentary\cn_167_end_game_scramble.mp3" "[ Dave Riller ] Originalmente, tínhamos previsto uma cena de coreografia maior para o fim do jogo. No entanto, a equipa de coreografia estava ocupada com imenso trabalho narrativo em falta. Para aliviar um pouco este trabalho, pedimos à equipa de jogabilidade da Cidadela para criar um desafio para terminar o jogo. Podia ser um quebra-cabeças, um combate, qualquer coisa. A batalha contra Breen aproveitou a mecânica de jogo que tínhamos com as super-armas de gravidade e criou uma pequena coreografia personalizada para construir um produto final num período muito curto."
N/A4082"#commentary\cn_168_combine_portal_effects.mp3" "[ Gary McTaggart ] Uma parte essencial do nosso processo de desenvolvimento é a possibilidade de qualquer membro da equipa poder contribuir em qualquer parte do jogo. Assim que a jogabilidade da batalha final estava sólida, os artistas e os programadores de efeitos visuais ajudaram a melhorar a apresentação do portal para o mundo original dos Combine e o efeito de tempo parado no final do jogo. Usámos um shader refrativo semelhante ao que tínhamos para a água para criar o efeito do portal dos Combine."
N/A4083"#commentary\cn_169_citadel_entrance.mp3" "[ Jeff Lane ] Criámos o percurso para a Cidadela ao contrário. A geometria interior foi criada como protótipo de arte para aperfeiçoar o visual. Sabíamos que o jogador surgia do cano de esgoto no mapa Streetwar e tivemos de criar uma secção com rampas e saltos na entrada da Cidadela para os ligar."
N/A4084"#commentary\cn_170_citadel_steep_landing.mp3" "[ Randy Lundeen ] A Cidadela foi criada na fase final do desenvolvimento e no início não tínhamos uma visão clara para a jogabilidade. Não é algo invulgar. Apesar de o design do jogo ter habitualmente influência no nosso processo, as escolhas criativas mais importantes que fazemos no início, como a existência da Cidadela dos Combine, recebem um trabalho de design específico para se encaixarem no produto final. Depois da batalha climática do capítulo anterior, queríamos criar outro tom para o final na Cidadela que fosse mais recompensador. Mesmo que quiséssemos criar algo mais intenso, a construção de novas mecânicas e NPCs era demasiado arriscada a esta altura. O primeiro plano foi criar um espetáculo narrativo passivo. Uma viagem de comboio pelo centro da máquina de guerra dos Combine, com final no escritório de Breen. Mas depois de termos desenvolvido este plano, dedicámos alguns dias a construir o protótipo da mecânica da super-arma de gravidade para que, no final do jogo, pudéssemos cumprir com os pedidos dos jogadores, tornando-as muito potentes sem interromper o equilíbrio geral do design. Os resultados foram logo promissores e alterámos completamente o design para integrar a super-arma de gravidade. Em vez dos tradicionais desafios de finais de jogos, queríamos que o jogador se sentisse uma divindade. Podia pegar nos inimigos à vontade ou arrancar consolas das paredes. No fim de contas, a Cidadela combina estes dois conceitos, alternando entre o espetáculo visual e o poder sem limites."
N/A4085"#commentary\cn_172_lightmap_pass.mp3" "[ Mike Dussault ] O interior da Cidadela é relativamente simples do ponto de vista geométrico, mas o material metálico dos Combine e uma iluminação dramática ajudam a criar uma imagem convincente da dimensão da estrutura. Aumentámos a resolução do mapa de luz em superfícies de interesse importantes e reduzimos a mesma nas que estavam completamente na sombra ou distantes. Além disso, por causa da grande dimensão dos espaços da Cidadela, as superfícies do mapa de luz que eram demasiado grandes tinham um custo de desempenho significativo. Perto do fim da fase de desenvolvimento, revimos todos os níveis da Cidadela para otimizar estes valores do ponto de vista de interesse visual e também do desempenho. Este processo foi facilitado por uma nova funcionalidade acrescentada ao editor de níveis Hammer, que apresentava superfícies com a sua densidade luxel."
N/A4086"#commentary\cn_173_super_gravity_origins.mp3" "[ Brian Jacobson ] Nesta fase do desenvolvimento, tínhamos confiança no design da arma de gravidade. Queríamos dar aos jogadores a sensação de se sentirem omnipotentes e começámos a trabalhar numa versão superpotente. Não demorámos muito. Aliás, só precisámos de um dia para criar o protótipo, até termos algo do nosso agrado e que se tornasse no centro da jogabilidade na Cidadela. Depois de termos concluído o motor de física, tínhamos liberdade para encontrar novas formas de o levar além dos limites anteriores e produzir resultados divertidos. O objeto do protótipo, uma melancia ultrapesada que pesava centenas de quilos na simulação de física, acabou por se transformar nas bolas dos Combine que vemos no jogo."
N/A4087"#commentary\cn_174_combine_energy.mp3" "[ Brian Jacobson ] O que começou por ser uma melancia no protótipo acabou por se tornar numa bola de energia depois de os sons criados para o impacto e para a explosão soarem menos como mercearia e mais como o que temos no jogo. Quando começámos a fazer testes em níveis que não eram baseados na melancia, descobrimos que era possível usar a bola de energia não só como uma forma divertida de matar soldados, mas também como elemento de quebra-cabeças para ligar e desligar diversos equipamentos. Numa fase muito posterior do desenvolvimento, não estávamos a gostar do disparo secundário da AR2. E como a equipa gostou da bola dos Combine, acabou por integrá-la no disparo secundário da AR2. Sempre que olhámos para trás, ficamos surpreendidos com a forma como as coisas que funcionam de forma independente acabam por juntar-se mais tarde para resolver problemas."
N/A4088"#commentary\cn_175_combine_wall_and_balls_training.mp3" "[ Ido Magal ] Durante a fase de testes, os jogadores não reparavam que as esferas dos Combine dissolviam soldados e por que motivo desapareciam. No início, tentámos resolver este problema ao fazer com que as esferas ricocheteassem em direção aos inimigos para aumentar a probabilidade de dissoluções. Mas acabámos por perceber que o motivo pelo qual os jogadores não reparavam neste efeito era porque acontecia sempre em combates intensos e que há uma capacidade muito limitada para aprender coisas novas em situações de stress. Encontrámos uma solução muito tardia ao criar uma sala de treino de baixa pressão com um campo de forças que só podia ser aberto ao pegar numa bola da Combine. Esta configuração foi adicionada em específico para treinar a forma como as bolas dos Combine funcionam para desativar campos de força e para ensinar que arremessá-las contra soldados os dissolvia. Ainda assim, nos testes, tivemos um sucesso moderado. Apesar destas tentativas, alguns jogadores continuavam a não perceber os efeitos de dissolução dos projéteis. Como ficámos sem tempo, decidimos que, como os jogadores ainda diziam que se sentiam muito fortes, não havia problema se nem todos percebessem porque estavam a conseguir."
N/A4089"#commentary\cn_176_weapon_strip.mp3" "[Josh Weier] Assim que introduzimos a super-arma de gravidade, não queríamos que os jogadores voltassem a usar armas convencionais, por isso fizemos a única coisa racional a fazer: desintegrámo-las. Ter um inimigo sobrenatural e inescrutável como os Combine ajuda, porque é lógico que poderiam ter um desintegrador. Porque não? E se, por algum motivo, precisássemos que o jogador voltasse a recuperar o arsenal anterior a meio de um nível... Vejam só! Também há um reintegrador."
N/A4090"#commentary\cn_177_breen_monologue.mp3" "[ Marc Laidlaw ] O trabalho criativo nunca existe num vácuo. Somos todos inspirados por outras coisas. O monólogo de Breen, que aparece nos monitores da Cidadela, foi inspirado num jogo anterior que todos gostávamos: Thief 2, em que o antagonista provoca o jogador enquanto este se esconde. Aqui a execução é diferente, mas a inspiração está lá. No entanto, o trabalho pesado, e que torna este momento convincente, é todo do falecido Robert Culp. A sua performance foi perfeita. Interpretou todas as falas de Breen com tal subtileza e talento que transformaram esta personagem em algo especial. As sessões de dobragem com o Robert Culp eram facílimas. Ele seguia o guião, o engenheiro de som gravava e pronto. A lição a aprender é que devemos trabalhar com pessoas cujo talento é superior ao nosso, pessoas com quem vamos de certeza aprender. Não devemos ter uma ideia fixa sobre como uma fala deve ser dita ou como um dado momento deve desenrolar-se. Em vez disso, temos de colaborar com pessoas talentosas e confiar que vão melhorar o produto final."
N/A4091"#commentary\cn_178_dissolved_weapons.mp3" "[ Quintin Doroquez ] Todas as armas dos Combine foram criadas para se dissolverem quando um soldado deles é atingido pela arma de gravidade por dois motivos. Primeiro, para que os jogadores não as usassem, mas também para melhorar o desempenho nestes mapas. Além disso, acrescentámos um gestor de bonecos para remover os cadáveres dos soldados mortos quando o jogador avançasse."
N/A4092"#commentary\cn_179_elevator_fight.mp3" "[ Brian Jacobson ] Apesar de querermos que o jogador se sentisse uma divindade, não resistimos à tentação de criar uma luta difícil no poço do elevador. A batalha enquanto esperamos a chegada do elevador tornou-se um pouco mais difícil do que previsto para esta parte. Ficou mais fácil durante a fase de testes, mas não tivemos tempo para a equilibrar ao ponto que queríamos. Apesar de o jogador nunca ter corrido assim tanto perigo, a quantidade de soldados faz com que a batalha pareça mais climática do que é na realidade."
N/A4093"#commentary\cn_180_replacing_the_prefabs.mp3" "[ Jeff Lane ] As bolas de energia dos Combine são uma configuração relativamente simples, tendo um campo de forças que segura os objetos que saltam eternamente. No entanto, durante a fase de testes, aconteceram erros recorrentes com as bolas de energia aos saltos, que ficavam descontroladas e \"escapavam\" do campo de forças que tínhamos criado para as conter. Devido aos limites da tecnologia pré-fabricada da altura, tivemos de reconstruir tudo manualmente várias vezes, em cada local e em todos os níveis da Cidadela onde estavam."
N/A4094"#commentary\cn_181_strider_fight.mp3" "[ Ted Backman ] Num dos protótipos originais da Cidadela havia a possibilidade de pegar no Strider com a super-arma de gravidade. E, durante muito tempo, a luta com o Strider resumia-se a chegar perto dele para pegar nele com a arma. Perto do fim da fase de desenvolvimento, decidimos que a capacidade de agarrar o Strider dava a entender que pareciam demasiado fracos, especialmente depois dos combates no mapa Street War. Por isso, substituímos este encontro por um em que o jogador usa bolas dos Combine. Acrescentámos peças ao modelo para que o Strider pudesse ser cortado e explodisse em vez de arrastarmos o corpo dele. Esta é a única vez no jogo em que um Strider tem este efeito."
N/A4095"#commentary\cn_182_getting_in_the_pod.mp3" "[ Dhabih Eng ] A sequência de ascensão do pod que começa aqui obrigou-nos a assumir o controlo total da cena e da visão do jogador. Isto vai contra a nossa vontade habitual de que o jogador tenha o máximo de controlo possível. Nesta fase final, sentimos que valeu a pena. Aqui o jogador é tão forte que seria difícil controlá-lo. Por isso, tivemos de o desativar. As personagens todas ainda falam com ele, mantendo-o como o centro das atenções. Também conseguimos dar alguma narrativa através do ambiente pelo caminho. A viagem de comboio pela Cidadela, que começa aqui, mostra vários adversários para os quais tínhamos conteúdo de arte, mas que acabaram por ser cortados da parte principal do jogo. Na segurança e conforto do seu pod, o jogador pode ver o processamento de Stalkers e um pouco do Crab Synth."
N/A4096"#commentary\cn_183_turrets.mp3" "[ Mike Dussault ] As torretas eram uma ferramenta útil sempre que o jogador tivesse isco, já que dessa forma podia impedir os Antlions de se aproximarem. Isto permitiu-nos criar cenários em que o jogador não podia simplesmente atirar isco para continuar. Tinha de circular e eliminar as torretas para que os seus Antlions o pudessem seguir. Ver os Antlions a serem abatidos pelas torretas também dava um excelente visual."
N/A4097"#commentary\cn_184_grenade_puzzle.mp3" "[ Aaron Seeler ] Este pequeno quebra-cabeças fazia com que alguns jogadores ficassem presos nos testes, já que a caixa de granadas ilimitadas estava um pouco atrás do caminho deles. Por esta altura, os jogadores já sabiam usar as caixas de munições ilimitadas para resolver quebra-cabeças. Por isso, se uma caixa de granadas estivesse aqui, sabiam logo que tinham de usar uma granada para resolver algo. Mas queríamos que primeiro pensassem um pouco. Eventualmente, colocámos uma dica subtil ao tornar as granadas visíveis na mesa por uma janela, só para recordar que podiam ser usadas. Isto também ajudou a encontrar um bug num teste quando um jogador se aproximou para ver de mais perto e acabou por recolher as granadas através do vidro."
N/A4098"#commentary\cn_185_allied_turrets_balancing.mp3" "[ Adrian Finol ] Equilibrar nesta luta em torno das torretas aliadas foi complicado. Neste momento, as torretas são um elemento novo. Por isso, se forem ignoradas pelos jogadores, a jogabilidade fica redundante, porque grande parte é semelhante ao que já aconteceu antes. Queríamos que os jogadores usassem as torretas e recompensar um posicionamento estratégico, mas a questão era muito binária. Um posicionamento perfeito tornava a luta demasiado fácil, enquanto um mau posicionamento a tornava muito difícil. Alguns ajustes e a lógica da IA personalizada do soldado ajudaram a corrigir a situação. Os soldados derrubavam mais torretas ao usar granadas ou ao flanqueá-las. Estas alterações fizeram com que a luta estivesse menos dependente de um posicionamento perfeito e mais da utilização ativa das torretas, já que qualquer posicionamento podia sofrer interrupções a qualquer momento. Os resultados dos testes variaram muito. Alguns jogadores achavam muito difícil e outros diziam que era a sua luta preferida. Como estávamos a ficar sem tempo, acabámos por tornar este confronto um pouco mais fácil, mas não ficámos satisfeitos com o equilíbrio final."
N/A4099"#commentary\cn_186_meeting_mossman.mp3" "[ Ariel Diaz ] Reunir o jogador e a Alyx a Mossman depois da cena da traição foi complicado. Muitos jogadores pensavam que tinham de atingir Mossman assim que a vissem. Não podíamos permitir que isso acontecesse, pois não tínhamos tempo para desenvolver histórias alternativas da narrativa. Porém, também não queríamos evidenciar que estávamos a bloquear esta escolha, e por isso tentámos reduzir a probabilidade de os jogadores tentarem fazer isso. Este vidro à prova de bala dá-nos tempo para o diálogo entre a Alyx e Mossman, durante o qual se torna evidente que a Alyx julga que matar Mossman não é o correto."
N/A4100"#commentary\cn_187_eli_in_pod_choreography.mp3" "[ Ken Birdwell ] Escrevemos e gravámos os diálogos para esta cena durante a fase de construção de Nova Prospekt. Nessa altura, sabíamos que a Alyx e o Gordon se iriam teletransportar para fora da prisão, mas ainda não tínhamos definido especificidades. Por isso, o diálogo tinha de ser genérico o suficiente para fazer sentido independentemente do que acabássemos por criar. Isto obrigou-nos a focar-nos menos nas ações do jogador e mais na vulnerabilidade da Alyx e na relação com o pai dela. Contávamos que a emoção fosse mais importante para a cena do que própria narrativa. No fim de contas, o objetivo era que o jogador se preocupasse com estas personagens e que desse prioridade ao que é mais importante para a Alyx."
N/A4101"#commentary\cn_188_mossman_and_eli.mp3" "[ Bill Van Buren ] Esta cena Choreo obrigou a várias iterações. Queríamos criar uma reviravolta na história durante a cena e manter o controlo nas mãos dos jogadores. Exigiu um equilíbrio delicado para que a reviravolta fosse evidente, mas também para garantir que não era interrompida. Se os jogadores seguissem a Alyx até à consola, tinham de perceber o que estava a acontecer quando se virassem. Se ficassem para trás a olhar para Mossman, tinham de entender o que estava a acontecer sem sentir que era algo que deviam tentar evitar. Tivemos de fazer vários ajustes e testes para acertar com o timing. Acabámos por usar uma combinação de distrações, acelerar o momento crucial e dar uma explicação depois do acontecimento."
N/A4102"#commentary\cn_189_nova_prospekt_entry.mp3" "[ Danika Rogers ] Os jogadores tinham completado dois níveis com combates intensos. Por isso, quisemos desacelerar o ritmo quando entrassem. Estes níveis iniciais foram criados para mudar o ritmo para que os jogadores pudessem explorar os interiores de Nova Prospekt. Pelo caminho, começámos a introduzir a jogabilidade das torretas, primeiro como inimigo e depois como ferramenta a utilizar. Grande parte deste nível foi criada através da reutilização de protótipos e espaços de arte criados anteriormente, quando estávamos concentrados no aspeto de Nova Prospekt."
N/A4103"#commentary\cn_190_turret_training_exit.mp3" "[ Doug Wood ] Este monte de lixo e a descida pelas escadas, foi criada para desincentivar os jogadores em levar uma torreta. Apesar de não estragar nada no jogo se o fizessem, queríamos reduzir essa probabilidade. Fazer com que fosse inconveniente levar a torreta não era uma estratégia ideal, mas era melhor do que nada. Muitos testers acabaram por desistir e abandonaram a torreta por sentir que o jogo estava a tentar mostrar-lhes algo."
N/A4104"#commentary\cn_191_allied_antlions.mp3" "[ Eric Kirchmer ] Ter um exército de infinito de Antlions a atacar torretas e soldados, implicou dedicar muito tempo a descobrir o papel do jogador nos combates em Nova Prospekt. Como os jogadores já tinham enfrentado muitos soldados dos Combine, decidimos fazer com que esta batalha fosse mais um quebra-cabeças e um espetáculo em vez de ser um desafio de combate. Com esta ideia, criámos configurações que se mantinham estáveis até o jogador intervir. Ao matar inimigos diretamente, o jogador mudava o equilíbrio a favor dos Antlions, mas queríamos tornar o uso do isco recompensador. Em muitos cenários, quando o jogador atirava isco contra inimigos, ativávamos mais geradores de Antlions para lançar uma vaga rápida deles. Essa carnificina era a recompensa que ajudava a criar uma satisfação por usar o isco."
N/A4105"#commentary\cn_192_laser_mines.mp3" "[ Erik Johnson ] Gostámos muito de colocar estas minas a laser em Nova Prospekt. Era uma das armas do Half-Life 1 que não tínhamos conseguido incluir no Half-Life 2, mas conseguimos encontrar um lugar para elas num quebra-cabeças. Gostámos da forma como serviam como teste de moralidade quando o jogador tinha um exército de Antlions ao seu dispor. Alguns jogadores atiravam isco diretamente para as minas a laser, sacrificando os Antlions, enquanto outros mantinham os seus amigos protegidos até removerem as minas com outras ferramentas. Sem julgamento..."
N/A4106"#commentary\cn_193_final_turret_arena.mp3" "[ Erik Johnson ] Quando criamos um capítulo dedicado a um elemento de jogabilidade, como a utilização de torretas aliadas, costumamos criar um protótipo que represente o ponto final desse capítulo. Criamos iterações desse protótipo até que os testes provem que funcione. Depois, trabalhamos de trás para a frente, acrescentando cenários anteriores para introduzir esse elemento e desenvolver as habilidades dos jogadores. Esta abordagem garante que a parte final da história é envolvente antes de investirmos muito tempo. Isto também significa que, quando criávamos cenários de treino, observávamos testes suficientes para saber que habilidades precisavam de orientação e quais os jogadores compreendiam de forma natural. Este cenário final com torretas era o objetivo. Destaca a defesa dos jogadores contra inimigos vindos de várias direções, exigindo colocar e recuperar torretas de forma dinâmica."
N/A4107"#commentary\cn_194_one_way_drops.mp3" "[ Jakob Jungels ] Os jogadores nunca sabem o que os espera, mas estão sempre familiarizados com o que já viram. Por isso, é normal voltarem para algo familiar quando encontram um inimigo. Se construímos uma arena onde queremos que o jogador interaje, particularmente quando temos um inimigo com requisitos específicos de geometria, como o guardião Antlion, temos de encontrar uma forma de impedir que batam em retirada. Uma das soluções mais habituais é fazer com que o jogador entre na arena por uma entrada de sentido único, algo que devem ter reparado várias vezes."
N/A4108"#commentary\cn_195_npcs_on_elevators.mp3" "[ Jay Stelly ] Por vezes, passamos muito tempo a resolver problemas de que os jogadores podem nem se aperceber. Muitos são desafios subtis de design, enquanto outros acontecem devido à interação de vários sistemas. Por exemplo, fazer com que NPCs andassem em elevadores era um problema complexo porque envolvia vários sistemas. Tomadas de decisões da IA dos NPCs, um planeamento de navegação e simulação de movimento, só para citar alguns. Além disso, o próprio elevador tinha os seus requisitos de simulação, não relacionados com os NPCs. Um dos desafios mais subtis veio do facto de simularmos NPCs a um ritmo mais lento do que simulamos elevadores. Assim, os NPCs num elevador em descida simulavam, para garantir que estavam bem de pé no elevador, e depois o elevador simulava algumas vezes, a descer cada vez mais no poço, deixando o NPC para trás subtilmente. A seguir, o NPC simulava uma segunda vez e descia de novo para o piso do elevador. Podem imaginar como era difícil levar a Alyx a sério quando ela estava sempre a cair ligeiramente enquanto falava connosco."
N/A4109"#commentary\cn_196_looktargets.mp3" "[ John Cook ] Uma das ferramentas principais do nosso conjunto de ferramentas de design é o Looktarget. É um ponto invisível que é ativado quando o jogador olha na sua direção. Os designers podem indicar a precisão com que o jogador tem de olhar para ele, durante quanto tempo deve olhar e outras condições. Assim que é ativado, o Looktarget ativa vários acontecimentos. Por exemplo, a Alyx pode ter de esperar que o jogador olhe para ela antes de falar, algo pode arrancar só quando estiver à vista do jogador ou uma nave de transporte dos Combine pode passar a voar por cima quando o jogador estiver a olhar na sua direção em geral. Depois de implementarmos os Looktargets, os designers criaram várias formas de os usar para tornar a jogabilidade mais fiável, particularmente porque os jogadores se movem a velocidades diferentes ou de maneiras difíceis de prever."
N/A4110"#commentary\cn_197_nova_prospekt_yard.mp3" "[ John Morello ] O combate nesta zona de Nova Prospekt foi inspirado pelas primeiras observações de Antlions a enfrentar soldados dos Combine. A grande mobilidade e os ataques corpo a corpo dos antlions combinavam bem com a capacidade de destruição à distância e a vulnerabilidade dos soldados a curta distância. Os antlions têm bom aspeto quando estão sob fogo, com efeitos de partículas a voar por todo o lado. Quando finalmente alcançavam um soldado, o efeito de boneco é muito satisfatório."
N/A4111"#commentary\cn_198_vent.mp3" "[ John Morello ] Já devem saber, mas se há uma conduta, tem lá um headcrab escondido. Não somos nós que fazemos as regras. Tal como estas condutas, as regras vêm de cima."
N/A4112"#commentary\cn_199_kitchen.mp3" "[ Kerry Davis ] Há uma tradição entre os criadores de jogos em que tem de acontecer uma explosão de gás em todas as cozinhas de jogos."
N/A4113"#commentary\cn_200_alyxs_tool.mp3" "[ Laura Dubuk ] A multiferramenta da Alyx foi útil para permitir que a usássemos como chave. Por vezes, temos de impedir que o jogador avance até o jogo estar pronto. E a multiferramenta permitia apresentar diálogos enquanto o caminho era desbloqueado. Talvez tenhamos confiado demasiado nela, mas foi difícil resistir. Há sempre uma contrapartida. Ao usar a Alyx para bloquear uma sala, em vez de conceber uma solução personalizada, poupou tempo que gastámos noutras partes, mais essenciais."
N/A4114"#commentary\cn_201_mossmans_betrayal.mp3" "[ Marc Laidlaw ] A ideia original para o arco da história da Judith Mossman era que traísse o jogador nesta altura. Mas quando chegámos a esta cena, depois de termos criado outras partes do jogo, concluímos que ela estava só a tentar proteger o Eli. Pensamos nela a refletir e a perceber que não podia trair o Gordon. Tivemos algumas ideias para esclarecer esta mudança mais tarde, mas acabámos por não concluir esta parte da história. Gostávamos da ambiguidade de Mossman, mas os jogadores não. Quase todos a detestavam. Mas isto podia ser considerado um sucesso. Trabalhámos muito para criar uma afinidade entre o jogador e a Alyx, e a Alyx também não era propriamente fã da Judith."
N/A4115"#commentary\cn_202_d2_prison_05_start.mp3" "[ Yahn Bernier ] Como os jogadores eram capazes de mover muitos objetos, encontrámos vários desafios, especialmente por causa das limitações dos CPUs de 2003. Uma das limitações era o facto de o nosso sistema de navegação de IA não ter noção de objetos físicos dinâmicos, como estas camas de metal. Apesar do sistema de movimento de NPCs ser capaz de detetar e evitar objetos físicos quando se moviam, ficavam praticamente invisíveis nas consultas de navegação de planeamentos estratégicos antes de se moverem. Isto acontecia principalmente por causa das limitações de desempenho. Não podíamos dar-nos ao luxo de criar algo mais complexo. Também tivemos problemas de design sem encontrar soluções óbvias, como a forma como um soldado deveria responder se um jogador bloqueasse um corredor com objetos físicos grandes. Para resolver este problema, demos mais força aos NPCs para poderem empurrar objetos físicos. Depois, mitigámos o problema através do design dos níveis, alargando os corredores para haver espaço vazio suficiente para os objetos que caíssem nesse espaço. Esta configuração era arriscada: a combinação de soldados escondidos atrás das camas com Antlions a atacar diretamente abre a possibilidade de acontecerem interações estranhas entre o sistema de movimento dos NPCs e as camas."
N/A4116"#commentary\cn_203_alyx_as_companion.mp3" "[ Miles Estes ] Esta secção transformou-se num protótipo não intencional para o que o Episode One acabaria por apresentar. A Alyx como companheira, a mover-se suavemente por um caminho que combina combate dinâmico com narrativa coreografada. Ainda não tínhamos um modelo certo sobre como ela combinaria com o o jogador nestes cenários. Mas esta secção ensinou-nos muito, apesar de não termos tido tempo suficiente para criar iterações."
N/A4117"#commentary\cn_204_laundry.mp3" "[ Mike Dussault ] Quando o jogador chega a este nível, conhecido como a Lavandaria, sabemos que está à vontade a usar isco em cenários de combate. Por isso, aumentámos a dificuldade ao criar um cenário que incentivasse um maior envolvimento, combinando o isco com o arsenal completo."
N/A4118"#commentary\cn_205_side_zombie.mp3" "[ Quintin Doroquez ] Este zombie venenoso foi um dos grandes destaques nos testes. Os jogadores estavam tão concentrados nos soldados dos Combine, nos Antlions e nas torretas que não reparavam no zombie venenoso. E o seu aparecimento súbito no escuro costumava ser uma grande surpresa."
N/A4119"#commentary\cn_206_flares.mp3" "[Quintin Doroquez] Esta secção é um bom contraponto ao segmento anterior com as torretas quanto a custos de produção e iterações. Criada muito tarde, foi terminada num instante, já que a IA da Alyx e do soldado dos Combine já estava amadurecida. Gostámos da escuridão e dos clarões, e arquivámos a secção como algo a explorar mais tarde. Depois, foi revisitada quando planeámos as secções escuras do Episode One."
N/A4120"#commentary\cn_207_magic_wall.mp3" "[ Robin Walker ] Como acontece em muitas arenas de combate, tínhamos de ter uma espécie de portão para impedir que os jogadores avançassem antes de acabar esta luta. Infelizmente, não tínhamos muito tempo e tivemos de avançar para a Estação Ferroviária. Por isso, acabámos com esta treta mágica: uma parede que explode quando a segunda nave de combate é derrotada, abrindo o caminho a seguir. Tentámos fazer com que a maioria dos jogadores não reparasse, pois estariam ocupados a enfrentar as naves de combate, e os testes provaram que, de forma geral, todos os jogadores acabavam a luta antes de chegar a este momento. Com explosões suficientes pela arena, a parede destruída e em chamas parecia natural. Por isso, colocámos uns quebra-cabeças simples de gás do outro lado como justificação. Mas não, não estamos propriamente orgulhosos disto."
N/A4121"#commentary\cn_208_ragdoll_vortigaunt.mp3" "[ Scott Dalton ] Vemos muito sofrimento neste Vortigaunt morto. Sofrimento dos designers de níveis. Na altura, as ferramentas de desenvolvimento não permitiam posar um boneco diretamente. Ou seja, quando um NPC morre e cai sistematicamente como um boneco, não tínhamos controlo sobre a posição em que ficava. Se tivéssemos tido mais tempo para criar animações, podíamos ter tido uma animação com um fotograma único na posição que queríamos. Mas estávamos atrasados e a pequena equipa de animação já estava sobrecarregada. Um designer de níveis colocou o Vortigaunt por cima desta cadeira, indicou que morresse enquanto o nível carregava e esperou para ver em que posição ficava. Depois, o designer moveu ligeiramente o Vortigaunt e tentou de novo. Não sabemos exatamente quantas tentativas foram precisas, mas foram muito mais do que se possa pensar."
N/A4122"#commentary\cn_209_nova_prospekt_process.mp3" "[ Eric Smith ] Tal como Ravenholm, Nova Prospekt foi inicialmente criada com uma jogabilidade diferente da do momento do lançamento. A primeira versão centrava-se em combates entre os jogadores e soldados dos Combine, sem Antlions. Ao contrário de outras zonas, onde a jogabilidade e a arte evoluíram juntas, Nova Prospekt recebeu imensa arte logo no início. Isto criou um conjunto de secções reutilizáveis e com geometria com arte já aplicada. A montagem de Nova Prospekt com estas peças funcionou bem, já que o layout da prisão era naturalmente repetitivo. Mais tarde, quando regressámos com os Antlions e isco, reaproveitámos a geometria para se adequar à nova jogabilidade."
N/A4123"#commentary\cn_210_d2_prison_04.mp3" "[ Eric Kirchmer ] Durante a fase de desenvolvimento, os artistas criaram pequenas fatias verticais de ambientes a que chamamos de \"zoos de arte\". Estes zoos definiram a forma de usar texturas e adereços para criar espaços que fossem ao encontro dos nossos objetivos visuais. No entanto, quando criámos a parte da prisão, o layout repetitivo permitiu usar a arte de forma mais direta. De início, este mapa foi construído como o zoo de arte principal para Nova Prospekt. Mas depois de ter sido usado para testar vários protótipos, incluindo os que acabaram por criar o isco, fez parte da arquitetura dos níveis."
N/A4124"#commentary\cn_211_autosave_dangerous.mp3" "[ Dave Riller ] No Half-Life 1, tínhamos várias gravações automáticas ao longo do jogo, colocadas manualmente pelos designers de níveis e ativadas quando um jogador chegava a um momento ou posição específica. Isto garantia que o jogo era guardado automaticamente enquanto percorríamos os corredores de Black Mesa. No Half-Life 2, precisávamos de usar uma nova ferramenta. O problema surgiu em algumas das arenas mais complexas que construímos. Alguns destes encontros duravam muito tempo e tinham inimigos diferentes. Outros combinavam exploração e combate, sem uma separação evidente. Não queríamos ter um sistema de gravação automática em que um jogador corresse o risco de morrer logo após carregar o jogo, porque isso poderia colocá-lo num loop. Se jogaram vários jogos naquela época, devem ter encontrado esta situação pelo menos uma vez. Por isso, a menos que criássemos pausas no fluxo de cada arena, nem sempre teríamos um local seguro para colocar gravações automáticas. Depois de algumas experiências, implementámos uma funcionalidade chamada Autosave Dangerous. Era uma ferramenta de design de níveis que combinava gravações automáticas com um período de tempo associado. Quando era ativada por um designer, guardava o jogo imediatamente, mas mantinha a gravação isolada, indisponível para ser carregada. Se o jogador continuasse vivo durante o período de tempo indicado, a gravação era confirmada e usada como a gravação automática mais recente. Assim, os designers podiam colocar gravações automáticas num local ou hora razoáveis na arena, especificar um tempo, como trinta segundos, e, se um jogador ainda estivesse vivo, elas seriam usadas como gravações automáticas."
N/A4125"#commentary\cn_212_we_dont_go_to_ravenholm.mp3" "[ Dario Casali ] Quando acabámos Ravenholm, não nos conseguimos livrar da sensação de que a transição do Laboratório do Eli não estava a funcionar. Era demasiado abrupta. O Laboratório do Eli ligava diretamente às ruas da cidade, para onde iríamos, e a secção em que estamos não existia. Tínhamos acabado de fazer essa promessa no fim do Laboratório do Eli. \"Não vamos lá mais\". E gostámos do resultado geral que tínhamos criado. Mas quando o jogador chegava a Ravenholm, era imediatamente colocado em combate contra zombies, sem um espaço para criar tensão. Por isso, construímos esta secção e os corredores estreitos seguintes para resolver o problema de uma forma que nos agradasse. Reduzimos o ritmo, concentrámo-nos na arte e na iluminação e preparámos o jogador para saber porque já não se ia a Ravenholm."
N/A4126"#commentary\cn_213_lever_shenanigans.mp3" "[ Dario Casali ] Mesmo com todo o trabalho que tivemos para que os jogadores entendessem que esta alavanca estava ligada à cerca elétrica exterior, alguns testers acabaram por usar a alavanca sem saber o que tinham feito. Até passeavam pela zona, usavam a alavanca outra vez e passeavam mais um bocado. Como não tínhamos muito tempo para esclarecer essa ligação, decidimos partir a alavanca. Isto impedia que os jogadores anulassem o progresso e reforçava a sensação de que Ravenholm era um ambiente instável e decadente."
N/A4127"#commentary\cn_214_town_arenas.mp3" "[ Dario Casali ] Neste ponto em Ravenholm, o jogador já sabe todos os elementos de jogabilidade disponíveis e pode prever interações. Isto permite construir cenários mais complexos, criar um maior nível de ameaça e dar mais liberdade na forma como o jogador pode abordar cada cenário. Esta arena é um espaço deliberadamente entrelaçado que o jogador tem de explorar. E usámos este tempo de exploração para aumentar lentamente a intensidade dos combates. Quanto mais rápido o jogador explorar, mais rápido aumentamos a intensidade. A forma livre deste design complicou os ajustes, dada a grande variedade de formas como os jogadores se comportavam."
N/A4128"#commentary\cn_215_mines.mp3" "[ Dario Casali ] O percurso complexo que o jogador faz para percorrer esta mina em segurança dá-lhe muito tempo para ver o que o espera no fundo. E surpresa! São headcrabs. Na verdade, costumam ser headcrabs. Mas neste caso são headcrabs venenosos, que são divertidos por si só, mas uma enorme confusão quando também há headcrabs rápidos à mistura. Estes dois são uma boa combinação. Nenhum é particularmente perigoso por si só, mas juntos são mortíferos. Assim que o jogador fica envenenado, basta um golpe de um headcrab rápido para matá-lo. E é a isto que os biólogos chamam de simbiose. Pelo menos é isso que pensamos."
N/A4129"#commentary\cn_216_poison_headcrabs.mp3" "[ David Speyrer ] Esta divisão introduz involuntariamente os headcrabs venenosos. Dedicámos muito tempo a elaborar uma introdução adequada no fim do nível, mas quando tivemos bons resultados nos testes, o entusiasmo falou mais alto e acabámos por espalhá-los pelo nível. Quando percebemos que tinham aparecido antes da introdução, era demasiado tarde para fazer alterações. Felizmente, uma sala apertada e cheia de headcrabs venenosos é um bom treino, já que o seu design evita um problema comum com treinos de combate. Normalmente, os jogadores ficam stressados e podem ficar frustrados se morrerem várias vezes sem entender porquê. E obviamente tivemos este problema ao tentar treinar o jogador com os headcrabs venenosos e a sua origem: o zombie venenoso. No entanto, os headcrabs venenosos não conseguem matar o jogador sozinhos. Portanto, apesar de ser um momento stressante, uma divisão cheia deles acaba por evitar essa frustração."
N/A4130"#commentary\cn_217_poison_zombie_introduction.mp3" "[ David Speyrer ] Se limitarmos o jogador a um espaço apertado e lhe dermos uma visão exterior, isso torna-se numa forma útil de aumentar as probabilidades de o jogador reparar numa coisa que queremos que veja. Neste caso, chamamos a atenção com o som de um lamento antes de o zombie venenoso ficar visível. Originalmente, este encontro também foi a primeira vez que o jogador encontrava os headcrabs venenosos. Mas como mencionámos num nó anterior, espalhámos demasiados headcrabs venenosos neste nível e acabámos por estragar a introdução do conjunto. Contudo, no fim, estes primeiros encontros acabaram por funcionar melhor em separado."
N/A4131"#commentary\cn_218_final_arena.mp3" "[ Eric Smith ] Quando acabámos a primeira passagem por Ravenholm, este telhado foi concebido para ser o palco da luta final. Tal como acontece noutros espaços em Ravenholm, começou por ser um espaço apenas centrado em ser visualmente interessante. Julgámos que era importante que, ao abandonar Ravenholm, o jogador precisasse de um momento para olhar para trás, para a cidade onde tinha acabado de sobreviver, e tivesse um vislumbre de para onde ia. Alguns grupos tentaram ter uma luta aqui, mas a geometria apertada e as restrições de desempenho fizeram com que não tivéssemos um final que nos satisfizesse. Tal como acontece na saga Half-Life, Ravenholm estava destinado a não ter um final a sério."
N/A4132"#commentary\cn_219_tables_and_bodies.mp3" "[ Ido Magal ] Antes do final da produção de Ravenholm, com todas as peças principais preparadas, fizemos uma revisão e tentámos preencher todos os pequenos espaços vazios com algo interessante. Tivemos de ter o cuidado de utilizar o que já tínhamos e não criar nada novo, pois não podíamos arriscar introduzir mais bugs. Por vezes, como acontece nesta divisão, tentávamos acrescentar novos momentos de jogabilidade e adicionávamos mais detalhes e narrativa. Algumas cenas pequenas, como esta, ajudam os jogadores mais atentos a pensar no que encontram e no significado para algo que encontrem a seguir."
N/A4133"#commentary\cn_220_physics_object_consistency.mp3" "[ Kerry Davis ] Todos os objectos físicos têm vários parâmetros que definem o seu comportamento. A massa, a quantidade de dano que sofrem antes de partirem, o que parte e assim adiante. Durante o desenvolvimento, estes parâmetros foram especificados pelos designers de níveis para cada item. Era assim que a maioria das coisas no jogo funcionava. Mas, mais tarde, entendemos que tínhamos criado um problema. O jogo tinha milhares de objetos físicos e não tínhamos métodos para garantir uma consistência entre eles. Assim, uma caixa de cartão podia partir-se com um disparo de uma pistola num nível e ser invulnerável noutro. Internamente, costumamos referir-nos a estas inconsistências como \"crimes dos designers de níveis\". Para corrigir e encontrar alguma justiça, criámos um sistema que impunha uma consistência a todos os objetos físicos com base no modelo visual. Como a maior parte do jogo já tinha sido criada, deixámos que os designers de níveis optassem por não usar este sistema em casos raros e extremos em que precisassem de fazer algo \"criminoso\" para preservar o que tinham criado. Internamente, chamamos estes designers de \"reincidentes\". E alguns continuam a perpetuar a sua vida criminosa na Valve."
N/A4134"#commentary\cn_222_fast_zombie_introduction.mp3" "[ Randy Lundeen ] Este espaço foi outra zona criada para a E3 de 2003, em que o jogador enfrentava um esquadrão de soldados dos Combine. Quando voltamos para o usar para apresentar o zombie rápido, tentamos manter o máximo possível do que já tínhamos feito. Queríamos ter uma cena icónica ao luar, com zombies a saltar em frente à lua como lobisomens para chamar a atenção do jogador. Quando esta cena acaba, introduzimos o primeiro zombie rápido no espaço do jogador e enviamo-lo na sua direção. Foram precisas muitas iterações para encontrar o equilíbrio certo na iluminação, para que tivesse um bom aspeto e garantisse que cumpria os objetivos de jogabilidade."
N/A4135"#commentary\cn_223_ravenholm_gameplay_focus.mp3" "[ Mike Dussault ] Depois de temos visto muitos testes de Ravenholm, sabíamos que a jogabilidade principal do nível girava em torno da arma de gravidade e da física. Com esta noção, julgámos que podíamos construir a transição para Ravenholm e ajudar o jogador a aprender e entender como seria a experiência seguinte. Isto acontece com frequência. Construímos o fluir do nível, descobrimos o que está a funcionar e concebemos o prólogo. Criámos o conjunto seguinte de salas com este cenário em mente. A brutalidade das ferramentas que fornecemos ao jogador pareceu ajudar a definir o ambiente que procurávamos, ajudando a mudar o tom da segurança do Laboratório do Eli para algo mais sinistro e assustador."
N/A4136"#commentary\cn_224_player_tools.mp3" "[ Steve Bond ] Nesta fase do jogo, os jogadores já têm muita experiência com a física do Half-Life 2, mas acabam de receber a arma de gravidade, que é uma forma completamente nova de interagir com os objectos físicos. Criámos iterações de vários objetos físicos com os quais o jogador podia brincar. Coisas como lâminas, catapultas, recipientes explosivos, armadilhas, lanças, etc. Melhorámos os que funcionavam bem com a arma de física e eliminámos os que não funcionavam. Depois, reduzimos os itens de munições para que o jogador dependesse destes objetos para sobreviver."
N/A4137"#commentary\cn_225_contrived_setups.mp3" "[ Kerry Davis ] Um treino com uma arma de gravidade e objetos de física sofre certas limitações. O jogador arranca uma lâmina da parede com a arma de gravidade e, no momento perfeito, um zombie dobra a esquina, mesmo a pedir para levar com a lâmina. Depois, o jogador rasteja para baixo de uma armadilha com lâminas giratórias para a desligar e de repente surgem três zombies que obrigam o jogador a ligar a armadilha de novo. Como não tivemos muito tempo para criar iterações desta secção, tivemos de procurar configurações que funcionassem para todos os jogadores e não deixar folgas que dependessem de eles fazerem o movimento certo. Apesar deste tipo de design poder causar uma redução da criatividade do jogador, neste caso, descobrimos que não pareciam importar-se a serem obrigados a fazer algo."
N/A4138"#commentary\cn_226_misteaching_flinches.mp3" "[ Kerry Davis ] Outro teste memorável e bom exemplo do perigo de ensinar mal os jogadores aconteceu em Ravenholm. Um dos nossos princípios de design é que o jogo responda ao jogador o mais possível. Por isso, ao conceber a arma de gravidade, parecia evidente que se o jogador a apontasse para um zombie e puxasse o gatilho, tinha de acontecer alguma coisa. Era suficientemente simples eletrocutar um zombie, causando uma pequena quantidade de dano e fazendo com que o zombie fizesse a animação de recuo, que tinha qualidade e era responsiva. Depois, houve um momento em que um tester descobriu esta interação imediatamente ao chegar a Ravenholm e a interpretou como indicação que a arma de gravidade estava a causar dano ao zombie... Que estava, mas não muito. Por isso, eletrocutou o zombie outra vez e mais uma vez, causando vários choques até que morresse. Isto é uma forma lenta, nada divertida e desumana de enfrentar zombies, especialmente quando estamos rodeados de lâminas e recipientes explosivos. Depois de aprendermos esta lição, removemos a animação de recuo, mesmo que isso implicasse a perda da interação entre o zombie e a arma de gravidade. Neste caso, era preferível não ter esta interação do que dar a falsa ideia de que a arma de gravidade era uma forma eficaz de combater zombies. Até os princípios mais simples nos podem obrigar a fazer concessões quando entramos nos pormenores."
N/A4139"#commentary\cn_227_fire_trap.mp3" "[ Steve Bond ] Esta armadilha de fogo foi concebida como uma apresentação visual do sistema de fogo, até um designer de níveis a ter adaptado como elemento de jogabilidade em Ravenholm. Quase foi cortada várias vezes no processo de desenvolvimento por causa do impacto no desempenho em PCs mais fracos, devido ao overdraw relacionado com os sprites transparentes. No final, um programador achou que era importante para a jogabilidade e resolveu os problemas de desempenho para garantir que fosse implementada."
N/A4140"#commentary\cn_228_hallway_cupboards.mp3" "[ Yahn Bernier ] Estes corredores cheios de tralha foram uma solução simples para abrandar o jogador. Com a limitação de preservar o máximo possível da geometria, combinada com os zombies lentos como inimigo principal, tornou-se complicado impedir que o jogador fizesse esta parte a despachar. Felizmente, o facto de termos o Grigori como o residente louco de Ravenholm ajudou a tornar estas configurações fáceis de justificar. Faz todo o sentido que o Gregori tapasse a escada para se manter protegido no topo. No fim de contas, a solução do Grigori e a nossa foi a mesma: atirar um monte de móveis para o caminho. Porque se os móveis impedem a passagem dos zombies, também devem abrandar o jogador."
N/A4141"#commentary\cn_229_pacing_switch.mp3" "[ Steve Bond ] Agora que os jogadores concluíram a secção de treino, passamos do ritmo dos espaços claustrofóbicos e sombrios para as arenas de ação mais centradas em combate. Com o jogador familiarizado com as ferramentas físicas do ambiente, começámos a combiná-las em espaços abertos e a dar-lhe a liberdade de escolher a abordagem."
N/A4142"#commentary\cn_230_car_crushers.mp3" "[ Steve Bond ] Estes esmagadores de carros tiveram de sofrer alguns ajustes e também serem alvo do sistema de danos físicos. É sempre um desafio quando objetos físicos grandes interagem com NPCs. Por exemplo, se as leis da física empurrarem um NPC, podem empurrá-lo para um sítio onde não devia ir, deixando-o incapaz de recuperar. Não é problema para algo como um headcrab, que é capaz de sair de uma situação complicada. Mas um zombie pode ficar preso e indefeso, debatendo-se numa brecha onde se tenha enfiado. E isso destrói o ambiente de terror de sobrevivência que queremos criar."
N/A4143"#commentary\cn_231_car_crusher_lifts.mp3" "[ Eric Smith ] Fazer com que os esmagadores erguessem o jogador também foi complicado. O jogador é sempre simulado pelo sistema de física e pelo sistema de movimento do jogo. Sempre que atualizamos o estado do jogador, comparamos os resultados dos dois sistemas e decidimos qual é o correto. Depois sincronizamos ambos e repetimos. Assim, os sistemas influenciam-se mutuamente. Por exemplo, quando o jogador está num balancé, as leis da física fazem com que a prancha ceda. Ou quando fica de pé no esmagador, este ergue-o. Apesar de ser mais complexa, esta abordagem de sistema duplo foi mais fácil de ajustar do que se lidássemos com a física e o movimento do jogador num só sistema. Ao separar ambos, conseguimos ajustar o sistema de movimento para ficar bem isolado e reconciliamos os dois apenas quando as leis da física afetam o jogador."
N/A4144"#commentary\cn_232_paint_cans.mp3" "[ Steve Bond ] Quando começámos a fazer da arma de gravidade e da física as partes mais essenciais da experiência em Ravenholm, começámos a percorrer os níveis e a procurar objectos que podíamos ter ignorado, já que estávamos ocupados a enfrentar obstáculos agressivos, como lâminas e recipientes explosivos. Uma das coisas que encontrámos foi a lata de tinta. E isso era suficientemente simples para reforçármos expectativas ao fazer com que as latas espirrassem tinta contra os zombies quando eram atiradas contra eles."
N/A4145"#commentary\cn_233_bringing_physics_to_the_enemies.mp3" "[ Tom Leonard ] As armadilhas físicas de Ravenholm foram alguns dos primeiros elementos de jogabilidade com os quais ficámos mesmo satisfeitos, mas faltava-lhes agência do ponto de vista do jogador. As lâminas ajudaram-nos a descobrir o verdadeiro significado de Ravenholm. Com as lâminas, o jogador conseguia aplicar as leis da física nos zombies em vez de levar os zombies para as leis da física. Depois compreendermos isto, Ravenholm evoluiu num instante. Continuámos a vasculhar o mapa em busca de qualquer coisa, algo invulgar, que pudesse ser transformado numa ferramenta ou arma para o jogador."
N/A4146"#commentary\cn_234_ravenholm_development.mp3" "[ Tom Leonard ] Começámos a desenvolver Ravenholm no início da fase de produção do Half-Life 2. Por isso, passou por mais do que uma fase completa de desenvolvimento. A primeira versão era anterior à arma de gravidade, com a jogabilidade centrada em combates tradicionais contra zombies com uso de armas e algumas armadilhas físicas. Chegámos a planear apresentar Ravenholm na E3 em 2002, mas o jogo acabou por ser revelado um ano depois, em 2003. Nessa altura, já tínhamos investido muito na arte de Ravenholm, algo que costumamos evitar até que a jogabilidade esteja comprovada. Por isso, quando voltámos a Ravenholm a pensar na mecânica da arma de gravidade, estávamos a trabalhar com muitas geometrias de níveis já existentes que tinham sido concebidas a pensar noutro objetivo de jogabilidade."
N/A4147"#commentary\cn_235_grigori_plaza.mp3" "[ Steve Bond ] Esta praça é uma das zonas que foi completamente detalhada na primeira fase de desenvolvimento. Quando voltámos a ela, quisemos preservar o máximo possível da arte enquanto concebíamos um caminho novo para o jogador que usasse as três dimensões. Mover os jogadores para cima e para baixo por janelas, telhados, entre edifícios. Como o espaço não era muito grande, tivemos de conseguir o máximo de percurso possível. E como começou por ser uma zona centrada na arte, tinha pouca jogabilidade e tivemos de resolver o problema de os testers passarem por ela a correr. Para piorar esta situação, estava a pressionar o orçamento de desempenho de renderizações com pouco espaço para criar algo novo. O desafio acabou por ser a criação de pequenos obstáculos para abrandar o jogador e adicionar ameaças em todos os cantos e recantos do nível."
N/A4148"#commentary\cn_236_ravenholm_development_2.mp3" "[ Tom Leonard ] Quando os fãs nos falam no Half-Life 2, Ravenholm é uma das secções mais recordadas. Graças às várias fases de desenvolvimento e à densidade do material que contém, há mais membros da equipa representados em Ravenholm do que em qualquer outro sítio. Foi aqui que descobrimos como aplicar o pipeline artístico às peças e ao ambiente que queríamos, como a forma como as leis da física e a jogabilidade combinavam com a arma de gravidade, como os headcrabs e zombies tinham de evoluir no Half-Life 2 e muito mais. Em retrospetiva, reafirma a nossa fé na agência individual em vez do design centralizado. Ravenholm é uma zona densa, muito eficiente na sua jogabilidade e execução artística. E também é a soma de muitas contribuições de pessoas que entenderam de que forma poderiam levá-lo um pouco mais longe com as suas capacidades únicas."
N/A4149"#commentary\cn_237_playtester_archetypes.mp3" "[ Tom Leonard ] A iteração e os testes regulares foram a alma da produção do Half-Life 2. Todas as semanas, observámos silenciosamente por cima do ombro de um jogador a percorrer a secção em que estávamos a trabalhar, a apontar o que funcionava e o que não funcionava. Para nós, era importante testar com uma grande gama de níveis de habilidade para ter a certeza de que não estávamos a tomar decisões que funcionassem apenas para alguns. Com tempo, aprendemos a escolher tipos de testers específicos com base na fase de produção atual. No início, usámos jogadores experientes, normalmente colegas de equipa, que eram capaz de lidar com zonas difíceis e inacabadas e sabiam explicar os seus processos mentais. Nos testes de combate, usámos jogadores com vários níveis de habilidade, especialmente criativos na utilização de ferramentas. Finalmente, à medida que as secções ficavam mais polidas, focámo-nos nos principiantes. Jogadores que não jogavam muito ou não estavam familiarizados com FPS. Mesmo que fossem pessoas que talvez não comprassem o jogo, muitas vezes aprendemos algo importante ao observá-los."
N/A4150"#commentary\cn_238_the_real_final_arena.mp3" "[ Tom Leonard ] Na parte final do desenvolvimento do Half-Life 2, quando estávamos a rever o jogo todo à procura de fazer as melhorias finais, decidimos que queríamos ter um final a sério para Ravenholm. O confronto no telhado não era suficiente. Após algumas discussões, optámos por acrescentar esta luta final no cemitério com o Gregori ao lado do jogador. Era arriscado em termos de produção, mas sentimos que o jogo precisava disto. Como estávamos perto do fim da produção, tínhamos um bom conjunto de ferramentas de jogabilidade ao nosso dispor, mas mais importante ainda, por esta altura já tínhamos compreendido o próprio jogo. A criação de um jogo pode ser um processo de aprendizagem do que se está mesmo a criar. Porque é que o jogo é divertido? Como é que é diferente? Quais são os elementos mais importantes? Ao construirmos o jogo e observarmos os testers, aprendemos as respostas a estas perguntas. E, por sua vez, melhoramos a criação. Assim, o cemitério foi criado rapidamente e exigiu menos iterações do que muitas áreas anteriores."
N/A4151"#commentary\cn_239_cities.mp3" "[ Eric Kirchmer ] Um dos desafios mais complicados desta secção foi encontrar uma forma de dar ao jogador a sensação que está numa vasta cidade, quando os orçamentos de desempenho não permitiam renderizar nada do género. Isto obrigou-nos a concentrar em cortiços apertados, garagens subterrâneas, túneis de metro, canos de esgoto e espaços semelhantes. Todos os sítios que estão em cidades, mas que tapam o horizonte. Depois, acrescentámos locais com vista a este estilo de design de níveis, onde o espaço é todo dedicado a dar uma visão expansiva ao jogador. Aqui dedicámos o orçamento inteiro de desempenho à vista, sem termos de precisar de guardar nada para a IA dos inimigos nem para os combates."
N/A4152"#commentary\cn_240_strider_4.mp3" "[ Eric Smith ] Apesar deste mapa ter sido o mapa de produção criado para o Strider, ainda tínhamos um mapa de desenvolvimento original para testar a IA dele. Damos sempre muito valor a ter um mapa de teste sólido para uma IA, pois permite testar novas ideias de jogabilidade e fazer ajustes rápidos. Se existirem bugs ou problemas de design, podemos isolá-los e criar iterações mais depressa. Quando as capacidades da IA estiverem a funcionar, transplantamo-las para os mapas de produção para que os designers de níveis trabalhem nelas. O mapa de teste do Strider tinha simples contornos de edifícios em ruínas, com pontos de geração de cidadãos infinitos, em vários locais e altitudes para criar um fluxo de alvos constante. Esta configuração ajudou-nos a melhorar a postura e a IA do Strider para que ele fosse mais interessante e envolvente, nem que fosse para simplesmente observá-lo."
N/A4153"#commentary\cn_241_perf_arena.mp3" "[ Aaron Seeler ] Esta arena teve um grande desafio: o desempenho. O tamanho e a combinação das IAs do Strider com a dos cidadãos desafiaram os nossos limites. Quando adaptámos o Half-Life 2 à Xbox, esta arena não pôde ser lançada sem termos feito alguns ajustes de design. Para preservar a intenção original e conseguir oferecer a mesma experiência aos jogadores com menos ferramentas e espaço foi preciso encontrar um equilíbrio delicado."
N/A4154"#commentary\cn_242_space_re-use.mp3" "[ Chris Green ] O regresso a este espaço trouxe muitas vantagens. Primeiro, a mais evidente: os custos de produção para criar novas áreas são sempre elevados. Por isso, se pudermos acrescentar mais jogabilidade a uma área que já exista, melhor. Mas para combates difíceis como este, em que o jogador enfrenta muitos Striders, a reutilização traz ainda mais vantagens. Como os jogadores já conhecem este tipo de combate, têm maior noção da estrutura da arena. Desta vez, movem-se de trás para a frente, mas o caminho segue maioritariamente o percurso original. Esta familiaridade é útil quando os jogadores são obrigados a mover-se para a frente para obter recursos para usar em combate. O estado de destruição da Cidade 17 também nos deu flexibilidade para ajustar proteções e acrescentar obstáculos mais pequenos pelo caminho de forma a manter o ambiente dinâmico e surpreendente."
N/A4155"#commentary\cn_243_tenements_and_courtyards.mp3" "[ Danika Rogers ] Usámos diversos pequenos truques e criámos muitas funcionalidades para dar aos jogadores a ideia de uma cidade em guerra, com grande parte do trabalho concentrado em dar vislumbres de pequenas lutas ou sons de combates à distância. Os Looktargets ajudavam a fazer com que algo acontecesse sempre que o jogador olhava por uma janela, enquanto outras ferramentas, como os Tracer Makers, ajudavam os designers a criar disparos entre dois pontos. Combinando isto com as ferramentas de áudio, criámos a ilusão de que dois grupos de inimigos estavam a trocar disparos, sem precisar de executar IA inimiga. Também concebemos pequenas histórias sobre grupos de cidadãos que o jogador encontrava várias vezes enquanto progredia no nível. Estes momentos foram todos ajustados na fase de testes para garantir que eram encontrados pelo máximo possível de jogadores."
N/A4156"#commentary\cn_244_hopper_mine_training.mp3" "[ Dario Casali ] Este painel de metal ondulado foi colocado de forma deliberada por cima do buraco para incentivar os jogadores a mudar para a arma de gravidade para o remover. É uma manipulação da nossa parte. Descobrimos que para treinar os jogadores em relação às minas saltadoras funcionava melhor se tentassem usar a arma de gravidade. O painel de metal aumentou a probabilidade de a terem a postos. Colocámos muitas minas no buraco para que os jogadores tivessem várias oportunidades de interagir com elas e também aumentando as probabilidades de descobrirem outras formas de as eliminar. Além disso, é a primeira vez que fazemos um treino com um esquadrão de cidadãos a acompanhar o jogador. Por isso, aproveitámos esta oportunidade para colocar linhas de diálogo sobre as minas saltadoras."
N/A4157"#commentary\cn_245_dog_combat.mp3" "[ Eric Kirchmer ] O Dog é uma personagem muito divertida. Estávamos sempre a tentar encontrar formas de o incluir em combates com o jogador. No entanto, tentar encontrar a escala de combate certa para a personagem, ou seja, o ambiente apropriado, nova IA inimiga e até novos inimigos, ficou muito além da abrangência do projeto. Para criarmos um cenário de combate que fizesse justiça ao Dog e que se destacasse do resto do jogo, quase parecia que teríamos de criar um jogo novo dentro do jogo. Sabíamos que ele não podia simplesmente correr até um soldado e dar-lhe um murro. Não seria nada impressionante e ninguém ficaria surpreendido. O Dog tinha de ter ameaças maiores, que correspondessem à sua escala, e também formas interessantes de interagir. Acabámos por decidir criar uma grande cena coreografada que seguisse os objetivos cinematográficos do Dog em combate, sem integrar um design de jogabilidade extensivo."
N/A4158"#commentary\cn_246_strider_2.mp3" "[ Eric Kirchmer ] Esta iteração do Strider deu-nos finalmente uma experiência satisfatória, já que o jogador tinha de correr de proteção em proteção para evitar os seus disparos enquanto procurava rockets. Queríamos que o jogador sentisse que tinha encontrado proteção no último momento. Por isso, ajustámos o padrão de tiros do Strider para telegrafar perigo iminente. Também criámos um sistema de percursos para o Strider seguir. Podía alternar de forma dinâmica entre eles para perseguir o jogador ou estabelecer uma linha de visão. Esta configuração ajudou os designers de níveis a alinhar cuidadosamente o percurso do Strider com a proteção do jogador para criar uma experiência mais equilibrada. O posicionamento das pernas do Strider era controlado por código e os seus movimentos imprevisíveis obrigaram-nos a ajustar tudo frequentemente para garantir que pontapeava um carro ou contentor de tropas de forma fiável se fosse necessário."
N/A4159"#commentary\cn_247_manhack_tunnels.mp3" "[ Eric Smith ] Ao conceber o comportamento da IA para um NPC, descobrimos que o programador devia ter um mapa de teste para experimentar. Este mapa costumava ser transformado num ambiente concebido em específico para mostrar as capacidades únicas do NPC. Mais tarde, quando a IA estivesse pronta para ser usada pelos designers de níveis, o mapa de teste era usado como ponto de referência importante. Sem este mapa, os designers podiam criar cenários que tornassem uma IA interessante menos envolvente sem querer. Em alguns casos, conseguimos integrar estes mapas no jogo. Por exemplo, esta secção começou por ser os túneis usados para desenvolver a IA do robot-serra."
N/A4160"#commentary\cn_248_sniper_streets_2.mp3" "[ Erik Johnson ] As balas no Half-Life 2 não seguem uma verdadeira trajetória, chegam ao alvo instantaneamente. Mas no caso do Sniper, como tem uma baixa cadência de tiro e a atenção completa do jogador em cada disparo, quisemos simular a trajetória das balas. Esta abordagem também funcionou melhor com a mira laser, em que a mira pisca e a bala atinge o alvo pouco depois, dependendo da distância até ao sniper. No entanto, esta alteração criou um novo problema. Como não queríamos que os jogadores simplesmente corressem pela rua para fugir aos disparos, o sniper tinha de acompanhar um alvo em movimento e prever onde a bala ia atingir. Prever a posição do jogador era complicado, já que os jogadores podem mudar de direção mais rapidamente do que na vida real. Por isso, acrescentámos mais verificações para detetar vários comportamentos, como toques rápidos no comando para a esquerda e direita enquanto corriam."
N/A4161"#commentary\cn_249_triangle_plaza.mp3" "[ Ido Magal ] Esta batalha na praça foi uma configuração complexa com o comportamento de Assalto e duas linhas de batalha convergentes, uma para cada campo de força. Quando os soldados aparecem atrás dos campos, as respetivas linhas de batalha impedem que invadam a praça individualmente. Quando a luta começa a ficar mais intensa e os soldados se posicionam, as linhas de batalha começam a mover-se na direção do centro da praça. É assim que os soldados dominam o jogador se não forem afastados."
N/A4162"#commentary\cn_250_sniper_streets_3.mp3" "[ Jakob Jungels ] Uma das funcionalidades com as quais fizemos testes nestas ruas foi o fogo de supressão. Muitos jogadores, que ficavam agachados no fim da rua, disparavam uma rajada contra a janela do sniper para ver se tinha algum efeito. Por isso, experimentámos fazer com que a mira laser piscasse brevemente, para dar aos jogadores uma oportunidade de reposicionamento. Mas, após muitos testes, encontrámos dois problemas. Primeiro, isto interrompia a jogabilidade tensa de movimento e cobertura que queríamos criar com o sniper. Correr e disparar não era muito diferente das outras ações que o jogador tem de fazer na Cidade 17. O segundo problema, que era mais subtil, era que os jogadores que descobriam o fogo de supressão primeiro pensavam que este era necessário e gastavam as munições num instante. Se ficassem sem munições a meio, por vezes vezes desistiam, porque pensavam que tinham falhado. Se conseguissem, costumavam acabar sem munições. Por outro lado, os jogadores que concluíam o cenário de forma furtiva não usavam quase quaisquer munições. Este fosso de recursos entre as abordagens tornou quase impossível equilibrar as munições para as próximas secções. Por isso, não está presente no jogo."
N/A4163"#commentary\cn_251_assault_behavior.mp3" "[ John Cook ] O comportamento mais complexo que criámos para o Half-Life 2 foi o de Assalto, que é usado nesta secção. Este comportamento permitiu que os designers construíssem cenários de combate com soldados dos Combine e cidadãos, estabelecendo linhas de batalha entre eles e controlando a forma como as batalhas se desenrolavam dependendo das ações do jogador. Os NPCs envolvidos num assalto procuram posições inteligentes para disparar e usam proteções dependendo da localização da linha de batalha. Quando um jogador avança numa rua, pode empurrar a linha de batalha e fazer com que os cidadãos aliados avancem enquanto os soldados inimigos recuam. Noutros casos, o jogador pode ter de derrubar torretas dos Combine ou eliminar um soldado protegido para avançar a linha de batalha."
N/A4164"#commentary\cn_252_bank_roof_mortar.mp3" "[ John Morello ] Na altura em que já tínhamos criado os níveis até este ponto, concluímos que seria divertido se o jogador usasse o morteiro. Imagino que é o tipo de coisas que nos devia ter ocorrido antes. \"Achas que os jogadores vão querer disparar explosivos para o ar para que caiam em cima dos vilões? Sim, também acho.\" Seja como for, como os jogadores passaram este tempo todo como alvo, seria uma boa recompensa se pudessem virar o feitiço contra o feiticeiro aos Combine. Mas assim que começámos a pensar nisso, reparámos no imenso trabalho que daria, o que, para sermos sinceros, é uma ideia que temos todos os dias quando criámos um jogo. O morteiro teria de ter animações e efeitos agora que o jogador estaria perto dele e teríamos muito trabalho pela frente para implementar um aumento de inimigos na praça para o usar. Mas, ainda mais importante, não tínhamos uma interface para uma arma tão única. Como é que os jogadores iriam apontar e disparar? É difícil sentirmo-nos bem se gastarmos muito tempo num único momento do jogo. Por isso, decidimos que seria melhor investir tempo noutra coisa e abandonámos a ideia. Desculpem! Pode ser que consigamos resolver o problema do design do morteiro num próximo título Half-Life."
N/A4165"#commentary\cn_253_strider.mp3" "[ Kerry Davis ] Foi nesta zona em frente ao Banco que descobrimos como criar o Strider. Quando vimos a arte conceptual desta personagem pela primeira vez, sabíamos que queríamos colocá-lo no jogo. Mas tínhamos montes de dúvidas sobre como iria funcionar na prática. Nunca tínhamos movido algo deste tamanho no mundo do jogo e, a esta escala, tinha de ser perigoso. Mas como é que os jogadores o enfrentariam? Tal como acontece com todos os nossos inimigos, pensámos sempre em termos de jogabilidade. Que ferramentas iriam precisar os designers de níveis para construir cenários com ele? Era para este tipo de questões que queríamos encontrar respostas nas experiências com este mapa."
N/A4166"#commentary\cn_254_sniper_streets.mp3" "[ Eric Kirchmer ] Foi nestas ruas cheias de snipers que desenvolvemos o inimigo e a essência da experiência que contávamos que os jogadores tivessem. Queríamos que o sniper atingisse coisas perto do jogador, por isso, primeiro concentrámo-nos em encontrar alvos interessantes para atingir. Concluímos que funcionava bem se usássemos a visão do jogador como fator na seleção de objetos. A mira laser sempre ativada do sniper acompanhava constantemente a posição do jogador. Por isso, a mira deslocar-se para um alvo que o jogador estivesse a observar era muito responsivo e criava momentos de grande tensão."
N/A4167"#commentary\cn_255_citizen_squad_details.mp3" "[ Matt Wright ] Depois de termos estabelecido o esquadrão de cidadãos do jogador e termos começado a criar cenários em torno dele, descobrimos que criava oportunidades interessantes. Como os testers começaram a preocupar-se com membros específicos do esquadrão, adicionámos mais elementos ao design. Os membros do esquadrão apanhavam armas superiores se as encontrassem, davam munições ao jogador se fosse necessário e os médicos curavam o jogador se fosse preciso. Também tivemos de garantir que o esquadrão era capaz de acompanhar o jogador, que por vezes seguia caminhos imprevisíveis. Fora do olhar da câmara, o esquadrão fazia \"batota\" de várias formas. Regenerava vida entre lutas, movia-se rapidamente para apanhar o jogador e até se teletransportava se fosse preciso."
N/A4168"#commentary\cn_256_citizen_squads.mp3" "[ Ken Birdwell ] Os primeiros testes que fizemos com lutas de rua entre os Combine e cidadãos revelaram um problema. Sem ter limites, a IA de combate podia afastar-se muito dos jogadores. Os soldados podiam retirar-se para recarregar ou para se protegerem e a IA do cidadão iria sempre persegui-los. Tínhamos de encontrar uma forma de alinhar as ações dos cidadãos mais de perto com os objetivos do jogador para soubessem para onde o jogador iria e quais os inimigos que o jogador queria enfrentar. Assim, criámos um esquadrão de cidadãos para o jogador. A IA dos cidadãos usava este esquadrão para seguir o jogador, enfrentava os mesmos inimigos e era uma interface básica para os comandos do jogador. De início, tínhamos criado um sistema de comandos mais complexo, mas como a gestão era complicada, tivemos de reduzir a escala."
N/A4169"#commentary\cn_257_ai_behaviors.mp3" "[ Mike Dussault ] Uma das tecnologias de IA que criámos para o Half-Life 2 foi o sistema de comportamento. Os comportamentos são pedaços de código de jogabilidade da IA que orientam os NPCs em situações específicas. Por exemplo, criámos um comportamento de liderança que fazia com que um NPC orientasse o jogador e um comportamento de acompanhamento para que um NPC seguisse o jogador ou outro NPC. Os comportamentos funcionavam em conjunto com as ações básicas dos NPCs. Desta forma, um membro do esquadrão médico que usasse o comportamento de acompanhamento para seguir o jogador continuava a saber disparar contra inimigos, fugir de granadas ou oferecer um estojo médico."
N/A4170"#commentary\cn_258_occlusion.mp3" "[ Brian Jacobson ] No Half-Life 1 e em grande parte do Half-Life 2, o mundo consistia marioritariamente em túneis e corredores fechados, que funcionavam bem com uma Partição de Espaço Binário, ou árvore BSP. Basicamente, esta tecnologia permitia-nos classificar rapidamente a geometria e decidir o que ficaria visível na visão do jogador. Mas as zonas abertas da Costa e outras secções ao ar livre não seguiam esta abordagem. Por isso, tivemos de encontrar uma tecnologia nova. Os portais de área foram uma dessas tecnologias. Permitiram dividir o mundo em pedaços discretos e separados por portais. Portas e janelas, não portais da Aperture Science. Também criámos mais um sistema de oclusão, que basicamente indicava que se o jogador não conseguisse ver através, sobre ou à volta de um objeto grande, o que estava do outro lado não era renderizado. Pode parecer algo óbvio a não fazer, mas dá muito trabalho garantir que o cálculo de algo que está do outro lado de uma coisa grande não seja um processo mais demorado do que a renderização de tudo. Por isso, para acelerar este cálculo, os designers de níveis criaram volumes grandes de oclusão dentro de grandes formas de terreno e grandes objetos de oclusão, como edifícios. Durante a renderização, testámos os limites das entidades em relação a estes volumes para evitar renderizar algo que o jogador não era capaz de ver."
N/A4171"#commentary\cn_259_detail_objects.mp3" "[ Brian Jacobson ] Depois de termos as secções exteriores a funcionar, ficou evidente que tinham de ter algum detalhe de alta frequência. Assim, acrescentámos elementos pequenos de folhagem, como relva e arbustos, ao longo da parte de deslocamento. Mas sabíamos que não nos podíamos dar ao luxo... ou seja, não tínhamos tempo de colocar todos manualmente. Por isso, criámos o sistema de objetos de detalhe, que gera elementos pequenos de folhagem automaticamente com base no material de deslocamento. Cada material especifica o tipo de folhagem a colocar e um conjunto de parâmetros. No momento da compilação do mapa, o sistema calcula pontos aleatórios na superfície e escolhe a folhagem a colocar. Por causa das restrições de desempenho, tínhamos ainda um processo de criação manual complexo para as folhas de textura de folhagem, que permitia renderizar todas numa única passagem."
N/A4172"#commentary\cn_260_displacements_1.mp3" "[ Charlie Brown ] Após o lançamento do Half-Life 1, os designers de níveis e artistas procuravam uma solução melhor para ambientes exteriores. Por isso, criámos a primeira versão do sistema de terreno. Baseava-se em quadrantes subdivididos. Para visualizar isto, imaginem um quadrado dividido numa grelha, em que cada ponto da grelha pode ser movido para cima ou para baixo. Os designers de níveis podiam criar vários quadrados e usar uma ferramenta de pincel para moldar colinas e vales, ajustando os pontos da grelha. Para a renderização, utilizámos uma textura especial, que combinava duas texturas diferentes. Cada ponto da grelha indicava a quantidade de cada textura a usar, permitindo criar transições suaves entre superfícies como areia, relva, terra e cascalho. Este tipo de sistema de terrenos não era invulgar nos motores de jogo da altura e pensámos que seria suficiente para os designers."
N/A4173"#commentary\cn_261_displacements_2.mp3" "[ Charlie Brown ] Assim que o sistema de terrenos inicial estava em funcionamento, esperávamos que os designers de níveis pudessem utilizá-lo para os espaços exteriores. Em vez disso, começaram a fazer experiências, acrescentando detalhes em locais inesperados. Usaram os quadrantes subdivididos no topo dos muros para criar extremidades em ruínas, arredondaram passeios e até tentaram criar canos. Teve níveis distintos de sucesso, já que o sistema de terrenos foi concebido para paisagens e não para detalhes arquitetónicos. Depois, regressámos ao código, transformando o sistema de terrenos baseado na altura num sistema de deslocamento 3D completo. Em vez de simplesmente mover os pontos da grelha para cima ou para baixo, os designers podiam movê-los em qualquer direção. Desta forma, puderam acrescentar mais detalhes a todos os tipos de superfícies, usando texturas fundidas para suavizar as transições entre os quadrantes de deslocamento e a geometria BSP. Contudo, isto exigiu mais trabalho técnico para garantir uma iluminação consistente entre os dois renderizadores, caso contrário as arestas teriam ficado visivelmente incompatíveis. Com tudo isto feito, os designers pareceram satisfeitos e pensámos que desta vez, seria mesmo suficiente."
N/A4174"#commentary\cn_262_displacements_3.mp3" "[ Charlie Brown ] Com o sistema geral de deslocamento em utilização, os designers de níveis não se limitaram a acrescentar detalhes ao mundo e regressaram ao objetivo original de construir secções exteriores em grande escala. Isto deu origem a outra ronda de atualizações para equilibrar o desempenho, de forma a que o sistema pudesse lidar tanto com detalhes como com terrenos maiores. A texturização também teve de ser melhorada, especialmente para aguentar estruturas complexas como penhascos salientes, que não era possível com o sistema de altura original. Os designers, que nunca ficam satisfeitos, começaram também a usar deslocações para criar grutas e túneis. Embora estas novidades parecessem excelentes, exigiram ainda mais ajustes técnicos. Eventualmente, acabámos por conseguir lidar com os requisitos de todas as formas que deslocamentos estavam a ser usados e foram implementados em grandes secções do mundo do jogo. Em retrospetiva, os deslocamentos são um exemplo claro de como a tecnologia e o design de jogos evoluem em conjunto. É o problema do ovo e da galinha. Não conseguimos prever todas as formas como uma tecnologia terá impacto no jogo, mas também não podemos construir a tecnologia sem saber o que tem de realizar. Por isso, como sempre, temos de construir algo. Começamos com um bom palpite e vemos até onde nos leva."
N/A4175"#commentary\cn_263_particles.mp3" "[ Chris Green ] Para o motor de jogo Source, investimos na expansão da tecnologia de partículas e efeitos especiais. Desta forma, conseguimos obter movimentos de partículas mais realistas e complexos, assim formas e efeitos de shaders mais complexos. Em específico, ao adicionar bumpmapping às funcionalidades de partículas, obtivemos uma melhor aparência volumétrica. Embora as versões seguintes do Source tivessem um excelente editor de sistema de partículas, a versão que usámos no Half-Life 2 usava efeitos criados à mão. Cada efeito exigia que um programador construísse o efeito manualmente, o que dava muito trabalho."
N/A4176"#commentary\cn_264_cubemaps.mp3" "[ Chris Green ] Com novos materiais e shaders, precisávamos de uma solução para superfícies refletoras, como vidro e aço. Estas superfícies tinham de saber o que deviam refletir. Mas em 2003, não podíamos fazer nada disto em tempo real. Depois, desenvolvemos o sistema cubemap para reflexões pré-computorizadas. Um cubemap é um conjunto de seis imagens dentro de um cubo que captam o ambiente em todas as direções. Como uma foto panorâmica que nos rodeia por todos os lados. Os designers de níveis colocaram marcadores invisíveis nos níveis e durante a compilação do mapa gerámos um cubemap em cada marcador. Depois, enquanto se jogava, ao renderizar uma superfície refletora, localizávamos o cubemap pré-computorizado mais próximo para criar esse reflexo."
N/A4177"#commentary\cn_265_water_shader.mp3" "[ Gary McTaggart] O shader mais complexo que criámos foi o da água, para o qual usámos todos os recursos das novas placas gráficas programáveis que tinhamos ao nosso dispor. Quando víamos água, a cena era renderizada três vezes. Primeiro, o mundo subaquático para refração. Segundo, uma visão refletida. E terceiro, as partes por cima da água. Ao renderizar a superfície da água, fundimos as visões refrativa e reflexiva, e mostramos uma maior reflexão em ângulos de visão periférica através da equação de Fresnel. Também rastreámos a profundidade do solo abaixo da superfície da água para ficar mais transparente e menos refrativa nas zonas mais rasas. Além disso, tivemos de criar duas técnicas alternativas de renderização de água para o jogo funcionar com placas gráficas inferiores. As placas de gama média usavam uma reflexão com menos detalhes e sem refração ou transparência, enquanto as placas de gama baixa só renderizavam uma superfície parcialmente transparente."
N/A4178"#commentary\cn_266_normal_maps.mp3" "[Gary McTaggart] O Half-Life 2 foi desenvolvido numa altura fantástica em termos de gráficos, com a chegada ao mercado das primeiras placas gráficas com suporte para shaders programáveis. Graças a esta tecnologia, fomos um dos primeiros jogos a implementar mapas normais, uma técnica que potenciava a iluminação na geometria da superfície. O mapa normal descrevia a rugosidade da superfície, e isso permitia que todos os pixeis de um polígono fossem iluminados para tornar as superfícies mais irregulares e detalhadas, algo que era impossível no Half-Life 1."
N/A4179"#commentary\cn_267_rendering_systems.mp3" "[ Gary McTaggart ] No início deste século, não tínhamos capacidade para ter um renderizador geral e com todas as capacidades de um motor moderno. Em vez disso, as limitações de CPU, GPU e memória exigiam soluções específicas para os desafios de renderização de forma a que pudéssemos extrair todo o desempenho do hardware dos computadores dos jogadores. Assim, o Half-Life 2 tem três motores de renderização diferentes: um para a geometria do mundo, outro para terrenos externos e um último para entidades dinâmicas, como personagens e objetos. Os três renderizadores tinham de suportar uma matriz complexa de características: colisões, ray tracing, decalques, iluminação offline, cálculos de visibilidade e muito mais. Além disso, cada renderizador tinha de ser compatível com DirectX 7, 8 e 9. As diferenças entre estas versões do DirectX eram significativas e muitas vezes exigiam abordagens distintas em termos de armazenamento de dados e renderização. Até usavam linguagens de programação diferentes! No total, tivemos nove renderizadores diferentes, cada a exigir soluções únicas. Conseguir que todos fossem consistentes entre si foi um dos problemas técnicos mais complexos durante a produção."
N/A4180"#commentary\cn_268_dynamic_shadows.mp3" "[ Gary McTaggart ] Com um foco nas personagens e objetos físicos, concluímos que precisávamos de ter um sistema de sombras dinâmico para renderizar de forma fantástica. Em 2003, as GPUs não tinham nenhuma das características dedicadas de sombras que têm agora, pelo que o desempenho era um problema. A solução passou por renderizar todos os frames. Em primeiro lugar, tivemos de encontrar todos os objetos que pudessem ter sombras. Para tal, tínhamos de descobrir quais os objetos que estavam no campo da visão ou ligeiramente atrás para captar entidades fora do ecrã, mas cuja sombra poderia acabar no ecrã. Depois, teríamos de renderizar uma versão em sombra preta de cada objeto numa única textura de sombra. Para esta renderização, teríamos de usar o modelo de nível de detalhe mais baixo do objeto, de forma a ser o mais rápido possível. Finalmente, utilizaríamos a textura de sombra para desenhar cada sombra na visão do jogador, escurecendo os pixeis renderizados. Cortámos cuidadosamente cada sombra nessa textura de sombra para garantir que ficavam sobrepostas de forma correta no caso de haver sobreposição de várias sombras. É interessante recordar como fazíamos estas coisas, mas, no fim de contas, estamos muito mais satisfeitos agora, em que o hardware da GPU simplifica isto."
N/A4181"#commentary\cn_269_combinatorial_shader_explosion.mp3" "[ Gary McTaggart ] A renderização tornou-se muito mais complexa durante a fase de produção do Half-Life 2 com adição de shaders por hardware, pequenos pedaços de código que controlam a forma como cada pixel de uma superfície deve ser renderizado. Em 2003, os shaders eram muito mais limitados do que agora. Os shaders da era do Half-Life 2 não tinham condicionantes e tinham grandes restrições de tamanho de código. Por isso, não havia uma lógica de ramificação if/else para ajustar com base em condições diferentes nem shaders grandes com conjuntos amplos de características. Além disso, a compilação de shaders à medida que eram necessários era demasiado lenta para ser útil, por isso tínhamos de os pré-compilar. Para trabalhar com estas limitações, tínhamos de calcular todas as combinações possíveis de shaders e guardar cada uma individualmente como um shader único. Por exemplo, se um shader tivesse efeito numa superfície com base numa fonte de luz, precisávamos de ter outra versão para duas luzes, outra para três e assim por diante. E era combinatório. Se um shader também fosse compatível com um mapa normal, precisaríamos de ter duas versões por luz, uma com o mapa normal e outra sem ele. Com várias características, como a fusão de texturas, matização de vértices, realces especulares, testes alfa e outros tipos de luz, como holofotes direcionais, pontuais e focos, a contagem de shaders explodiu. No lançamento, tínhamos milhares de shaders individuais. Pouco depois, lançámos o Lost Coast e adicionámos suporte para HDR, o que duplicou outra vez o número de shaders. Quando compilar shaders nas máquinas locais dos programadores começou a demorar demasiado tempo, passámos a distribuir a compilação pela rede com o VMPi. Também tínhamos um modo de compilação de shaders dinâmico, útil para a criação de shaders rapidamente processados, mas com menos fotogramas quando era preciso compilar um shader."
N/A4182"#commentary\cn_270_gpu_wild_west.mp3" "[ Jay Stelly ] Na fase de desenvolvimento, tivemos de tomar várias decisões influenciadas pelas especificações mínimas, a combinação de CPU e GPU menos potentes que ainda assim proporcionaria uma boa experiência aos jogadores. No início deste século havia uma maior variedade de GPUs do que agora, com grandes diferenças não só em velocidade, mas também na abordagem à renderização. Mas, na altura, não tínhamos dados reais sobre o hardware que os jogadores usavam. Que CPUs e GPUs tinham? Quanto de RAM? Que versão do Windows? Contactámos a Microsoft para que pudessem dar-nos respostas a diversas perguntas. Quantas placas DX7 estão no mercado? E DX8? Infelizmente, eles também não tinham estes dados. Como corríamos o risco de tomar más decisões sem estes dados, criámos uma ferramenta de análise que permitia aos jogadores partilhar as suas especificações de hardware e integrámos isso na versão inicial do Steam. Os dados foram tão úteis que decidimos torná-los públicos e lançámos o Steam Hardware Survey em abril de 2003. Desde então, tem-nos ajudado, e esperamos que a outros programadores, a tomar decisões informadas."
N/A4183"#commentary\cn_271_3d_skybox.mp3" "[ Jay Stelly ] Tentamos sempre renderizar um mundo que parecesse maior do que as limitações do mapa permitiam. No Half-Life 1, usámos uma textura de mapas de cubos para que os jogadores pudessem ver para além da área jogável. Mas, no Half-Life 2, queríamos que a visão do mundo maior fosse dinâmica e não apenas uma textura estática. A limitação do tamanho do mapa era de cerca de 800 metros em cada dimensão, mas podíamos criar um mundo exterior muito maior se o guardássemos numa escala reduzida. Por isso, inventámos o que chamamos 3D Skybox. O 3D Skybox é uma pequena caixa escondida no mapa real do jogo com uma geometria à escala de 1/16. Dentro dela, um ponto de referência corresponde a uma origem correspondente no mapa principal. Depois, quando renderizamos o espaço para além da área jogável, usamos a geometria do 3D Skybox, posicionada nesse ponto de referência e ampliada 16 vezes. A forma como a iluminação e o nevoeiro se misturavam na transição do mapa principal para a skybox trouxe desafios complexos, mas funcionou. O resultado fez com que o mundo parecesse muito maior e mais envolvente do que no Half-Life 1."
N/A4184"#commentary\cn_272_missing_material.mp3" "[ Jay Stelly ] No início do desenvolvimento do código gráfico de baixo nível, concluímos que seria difícil identificar polígonos não renderizados devido a uma textura em falta. Quando isto acontecia, normalmente só se via preto onde devia estar o polígono, o que podia passar despercebido em cenas mais escuras. Para detetar melhor este bug, criámos uma textura de erro visualmente inconfundível e gerada automaticamente sempre que uma textura falhasse o carregamento. Isto deu origem à famosa textura axadrezada roxa e preta, que desde então ganhou vida própria muito para além do Half-Life 2."
N/A4185"#commentary\cn_273_air_resistance.mp3" "[ Jay Stelly ] Uma característica importante que tivemos de acrescentar ao motor de física do Half-Life 2 foi a resistência ao ar. Na altura, os motores de física implementavam uma característica geral de amortecimento para abrandar os objetos à medida que se moviam. Mas isso só removia a energia de forma simétrica. Para criar um movimento mais realista, simulámos a resistência ao ar. Isto ajudou-nos a obter um comportamento assimétrico, em que a desaceleração do objeto ao mover-se pelo ar era diferente, dependendo da área de superfície do objeto estava virada para a direção ou da rotação do movimento. Esta funcionalidade foi essencial para fazer com que as explosões e os objetos disparados pela arma de gravidade fossem credíveis. Os objetos que se movem e giram rapidamente estão entre as coisas mais difíceis de simular no motor de física do Half-Life 2. Por isso, a resistência ao ar também melhora o desempenho do CPU em casos como as explosões. Também é essencial para apresentar materiais e massas de objetos diferentes. Objetos mais densos deslocam o ar mais facilmente e isso é visível. Ter este efeito na simulação ajuda a tornar a diferença de densidade entre as caixas de cartão e as tábuas de madeira mais evidente e torna os objetos do mundo do Half-Life 2 mais convincentes."
N/A4186"#commentary\cn_274_early_tech_planning.mp3" "[ Ken Birdwell ] Lançar um jogo ensina-nos sempre muito. Conseguimos descobrir que decisões foram boas e o que devíamos ter feito de outra forma. Depois do Half-Life 1, quando começámos a pensar sobre o tipo de sequela que queríamos criar, tínhamos um monte de feedback dos jogadores para digerir. A partir disso, criámos uma lista principal daquilo em que o Half-Life 2 se focaria. Não tentámos criar uma experiência específica para o jogador. Achámos mais útil abordar o jogo de um ponto de vista tecnológico. Os seguranças e cientistas de Black Mesa trabalharam bem. O que poderíamos fazer se lavássemos as personagens mais além? Gostávamos da narrativa interativa. O que poderíamos construir que permitisse fazer ainda mais com isso e com uma maior variedade? Os jogadores gostavam da exploração e das interações em Black Mesa. Pensámos que talvez um sistema de física permitisse dar um passo em frente. Em todas estas áreas, tentámos imaginar como seria a melhor versão daqui a uns anos e retirar disso um conjunto de etapas tecnológicas que nos pudessem levar até esse ponto."
N/A4187"#commentary\cn_275_character_lighting.mp3" "[ Ken Birdwell ] No primeiro ano de desenvolvimento, tivemos dificuldades para que as personagens parecessem tão realistas como queríamos. Aliás, tivemos uma série de problemas diferentes que acabaram por exigir melhorias tecnológicas e artísticas específicas para serem corrigidos. O primeiro grande problema foi a iluminação. Na altura, a tecnologia de iluminação de jogos seguia muitos atalhos, alguns devido a desempenho, mas muitos devido a mal entendidos sobre como as coisas funcionavam. Para fazer com que os personagens tivessem bom aspeto na altura, tivemos de criar modelos e texturas com grande parte da solução de iluminação integrada, como sombras e brilho. As personagens tinham bom aspeto, mas também pareciam personagens de jogos. Começámos a criar a Alyx seguindo esta abordagem, porque era assim que se devia fazer. Utilizámos as soluções prontas a usar e iluminámo-la como se fosse uma atriz de cinema. Basicamente, como se tivesse um equipamento de iluminação personalizado que a seguia e garantia que estava sempre bem. Mas não funcionou. A variedade de ambientes de iluminação e a natureza dinâmica dos jogos ditava que ficava muito bem em alguns ambientes, mas acabava sempre por parecer irrealista a dado momento. Tentámos criar iterações no equipamento de iluminação, aumentando as suas capacidades, mas acabámos por concluir que estávamos num beco sem saída. Voltámos à raiz e decidimos tentar outra abordagem. Construímos a personagem, a iluminação e as texturas de raiz e deitámos tudo fora. Concentrámo-nos menos em como queríamos que ela ficasse sob a iluminação ideal e mais em como tudo devia funcionar no mundo real. Pode parecer óbvio, mas não se fazia isso na altura, pelo menos em jogos. Quando estes modelos e texturas eram vistos fora do renderizador do jogo, pareciam piores do que as versões anteriores. Mas, de forma metódica, conseguimos remover todos os atalhos e ideias erradas sobre como funcionavam a luz, a textura e as placas gráficas e voltar a juntar tudo. Depois de isto tudo, quando finalmente pudemos ver a Alyx no jogo, com os novos modelos e texturas, num ambiente dinâmico que a manteve sempre visualmente consistente, bem... estava fantástica. Completamente integrada e sendo parte do mundo do Half-Life 2."
N/A4188"#commentary\cn_276_gamma_correction.mp3" "[ John Morello ] O nosso motor de jogo tem um sistema de renderização que analisa todo o estado do jogo e calcula um valor de cor para cada pixel no ecrã para representar esse estado. Mas o código e software externos também estão envolvidos no processo de cálculo dos pixéis. Por exemplo, o software e hardware do GPU e do monitor. A certa altura, na fase de desenvolvimento, não estávamos satisfeitos com a aparência das personagens. Em particular, tinham um ar de \"cera\" ou doentes. A pele não parecia bem. Dedicámos algum tempo a ajustar a iluminação, mas não conseguimos fazer com que as personagens e o mundo ficassem bem. Felizmente, tínhamos um renderizador de software completo, e isso ajudou-nos a correr o jogo sem GPU, porque nessa altura muitos jogadores ainda não tinham um. E vendo o jogo no renderizador, entendemos que a iluminação não sofria do mesmo problema. Por isso, analisámos o código a pente fino para tentar descobrir onde é que o código de renderização estava a errar quando trabalhava com uma GPU. Sem sucesso, tentámos falar com os fabricantes de GPUs e pedimos que verificassem se havia algo errado nos valores dos pixéis que estávamos a passar. Foi o início de uma longa aventura. Resumindo, foram quase dois anos de comunicação com fabricantes de GPUs antes de conseguirmos convencê-los que estavam a fazer correções de gama de forma incorreta na matemática de baixo nível nas placas deles. Entretanto, tivemos de construir um sistema que validasse os valores de cor de um pixel individual no nosso pipeline de renderização. Mas, no fim, recebemos novos drivers deles e as personagens ficaram como deviam, combinando com o renderizador de software."
N/A4189"#commentary\cn_277_facial_technology.mp3" "[ Ken Birdwell ] Queríamos que os jogadores se preocupassem com as personagens. Para conseguir isso, sabíamos que tínhamos de investir muito na tecnologia facial. É sabido que os humanos estão programados para prestar atenção aos rostos, para ler de forma subconsciente todo o tipo de informações. Portanto, era um padrão extremamente elevado que se não fosse alcançado, afastaria os jogadores das personagens e não os aproximá-los como esperávamos. Começámos por fazer muitas pesquisas. Não foram animadoras. Os melhores exemplos que conseguimos encontrar estavam muito longe de serem executados em tempo real, enquanto os melhores em tempo real estavam distantes da qualidade que procurávamos. Queríamos encontrar um aspeto semelhante ao de um filme de animação, mas eles demoravam várias horas a renderizar fotogramas e eram completamente lineares, criados por cem animadores, enquanto os nossos tinham de ser dinâmicos. Uma personagem pode estar a tentar dizer algo com uma expressão facial causada pelas ações do jogador e criado por poucos artistas. Estes requisitos acabaram por levar-nos até ao Sistema de Codificação de Ações Faciais do Dr. Paul Ekman, um sistema que taxonomiza os movimentos faciais de humanos, criado na década de 70. Este sistema deu-nos um vocabulário que descrevia os movimentos faciais nas nossas ferramentas e no código, assim como um objetivo na criação dos rostos das personagens. Com este sistema como base, iniciámos um processo de vários anos de iteração sobre como construímos rostos e cabeças. Enquanto outros tentavam pegar em algumas partes do trabalho de Ekman, nós queríamos usar tudo. Para tal, precisámos de dedicar muito tempo a descobrir como fazer cada peça dentro das restrições de desempenho. Mas também passámos muito tempo só a observar pessoas e rostos, tentando encontrar mais características que dariam mais valor, como a elasticidade da pele ou o sombreado dos dentes. No fim de contas, apesar de não termos conseguido fazer tudo o que queríamos, obtivemos as partes que considerávamos mais importantes para atingir um nível convincente de desempenho facial."
N/A4190"#commentary\cn_278_eye_shader.mp3" "[ Ken Birdwell ] Outra parte essencial para fazer com que os rostos das personagens fossem convincentes estava nos olhos. Os humanos são bons a ler olhos. Há uma parte do cérebro dedicada a isso, até para saber para onde alguém está a olhar com base nos reflexos nos globos oculares. Mas há várias subtilezas importantes. Os olhos não são mesmo esferas. As pálpebras ficam distorcidas pela córnea que se move por baixo. O movimento dos olhos pode aumentar as probabilidades de piscar. Os olhos não estão alinhados diretamente atrás da pupila, estão ligeiramente deslocados. Todos estes detalhes podem parecer impercetíveis, mas a sua ausência prejudica a credibilidade da personagem. Trabalhámos nos olhos durante muito tempo, criando iterações no modelo de globos oculares e conjunto de características aos poucos. Algumas coisas exigiam interfaces externas, como quais as coisas no ambiente que tinham maior interesse de observar, enquanto outras eram automáticas, a um nível subconsciente da IA. Como piscar os olhos, um requisito óbvio, mas que é subtilmente confuso se estiver errado. Os reflexos oculares tiveram um impacto particular. Ocupam uma pequena área no ecrã, mas têm muito peso. Pensámos que tinha sido o fim quando chegámos ao ponto em que, com o shader de olhos desligado, uma personagem parecia uma boneca humana, nada convincente de uma forma difícil de descrever. Mas quando o ativávamos, de repente, parecia estar um humano a olhar para nós."
N/A4191"#commentary\cn_279_combine_gunship.mp3" "[ Ken Birdwell ] O helicóptero de ataque foi um problema interessante. Tínhamos um modelo de voo de helicóptero e não tínhamos tempo para construir algo novo. Por isso, ajustámos o modelo de voo do helicóptero até que ficasse suficientemente diferente e derivámos o estado de animação orgânica do helicóptero de ataque com os valores dessa simulação. Também tentámos fazer com que fosse o mais fiel possível. Por exemplo, há um limite para o quanto consegue virar a dianteira para apontar o canhão. Se tiver de apontar além disso, tem de alterar a trajetória para colocar o canhão em posição. Não pode simplesmente fazer batota. A outra característica essencial era o som do motor. O jogo tem som espacial, para que o jogador saiba aproximadamente onde está. Mas o helicóptero move-se muito rapidamente e está no ar, longe de pontos de referência próximos. Assim, pode ser difícil dizer exatamente a que distância está e a que velocidade está a deslocar-se. Para corrigir, acrescentámos um efeito Doppler ao som do motor para alterar o tom com base na velocidade do helicóptero em relação ao jogador. É um efeito subtil, mas muito eficaz para ajudar a entender de forma subconsciente a localização e direção do helicóptero de ataque. São informações essenciais que ajudam a saber que estamos a ser perseguidos por ele."
N/A4192"#commentary\cn_280_risk.mp3" "[ Ken Birdwell ] Olhando para o Half-Life 2 em retrospetiva, 20 anos depois, é impressionante refletir sobre como grande parte do desenvolvimento foi aterradora. O desenvolvimento de jogos é difícil. Nunca conseguimos realmente o que procuramos, que é podermos validar o risco antes de começarmos a adicionar mais coisas. Por exemplo, a tecnologia de animação facial. Gastámos cerca de 3 ou 4 anos de trabalho até termos a certeza de que funcionaria. Mas não podíamos esperar tanto tempo. No primeiro ano, começámos imediatamente a fazer outras escolhas no design do jogo, na produção de ativos e noutras tecnologias, todas baseadas no pressuposto de que a tecnologia de animação facial iria funcionar, de um ponto de vista de qualidade e desempenho. Se não tivesse funcionado, muitas destas escolhas também não funcionariam. E seguimos o mesmo perfil de risco noutras escolhas importantes que fizemos no início. Não podemos esperar. Só temos de criar e esperar que os palpites se tornem realidade passado alguns anos. É aterrorizante."
N/A4193"#commentary\cn_281_hugs_and_pickups.mp3" "[ Ken Birdwell ] Por vezes, até as mais pequenas coisas podem ser um pesadelo para que funcionem. Por exemplo, fazer com que uma personagem abrace outra, ou ainda mais simples, pegue num objeto de uma mesa, pode causar muitos problemas. Pior ainda, neste ambiente dinâmico, onde as personagens e os objetos não estão em posições predefinidas e o jogador anda a atrapalhar, é preciso um nível de sincronização que pode tornar-se complicado. São ainda mais difíceis porque os humanos fazem isso sem pensar. Quando vamos até uma mesa para pegar numa chávena, fazemos vários movimentos com o corpo para colocar os pés e as mãos na posição certa para pegar de forma confortável. Para ter tudo pronto quando lá chegamos. Se nos movemos para abraçar alguém, estamos a abraçar ao mesmo tempo, ajustamo-nos com base no movimento do outro. Para que isto funcionasse no jogo, foi preciso muito trabalho de sincronização, para tornar as personagens conscientes umas das outras e do mundo. E, ao mesmo tempo, fazendo-os saber mais sobre os planos futuros. É tentador querer dividir o exemplo de pegar numa chávena em passos discretos: caminhar até à mesa, ficar de frente para a chávena, pegar na chávena. Porque é muito mais simples assim e torna os passos reutilizáveis. Mas é assim que os robôs funcionam, não os humanos. As personagens tinham de saber que estavam a mover-se na direção de uma mesa com a intenção de pegar numa chávena, para poderem trabalhar em várias partes dessa ação ao mesmo tempo, garantindo que as mãos agarravam a chávena assim que lá chegassem. Com duas personagens, é uma negociação ainda maior. Ambos têm de concordar onde e quando é que isso vai acontecer e tudo tem de acontecer de forma contínua. Embora estes momentos de interação simples entre as personagens no mundo sejam curtos, eram essenciais para que parecessem pessoas credíveis."
N/A4194"#commentary\cn_282_ropes.mp3" "[ Mike Dussault ] Uma das coisas que reparámos em todas as imagens de referência que reunimos para a Cidade 17 foi a existência de cabos e fios por toda a parte e que eram uma grande parte dos detalhes de alta frequência à vista. Adoramos o visual das cidades europeias mais antigas e a forma como se enredam na vida moderna. Concluímos que teríamos de encontrar uma solução para os cabos, cordas e elementos semelhantes para que fossem dinâmicos. Os designers de níveis estavam ansiosos por criar quebra-cabeças com fichas, e a ligação de um cabo a cada ficha ajudou os jogadores a compreenderem esta mecânica. No arranque do processo de produção, construímos um sistema de cordas que fomos refinando durante o processo de desenvolvimento. Por baixo do capô, cada corda é feita de vários segmentos esticados entre as duas extremidades, podendo mover-se de forma independente. Cada segmento funciona como uma mola e responde às forças do jogo, como uma brisa ou a passagem de uma nave dos Combine. Quando é renderizado, cada segmento é apresentado de frente para a câmara e é mapeado. Isto é essencial para dar um aspeto realista e mais arredondado às cordas."
N/A4195"#commentary\cn_283_vmpi.mp3" "[ Mike Dussault ] Na fase de produção, sentimo-nos cada vez mais frustrados com a lentidão das iterações, principalmente porque a compilação de mapas, que é necessária para pré-computar iluminação e visibilidade, demorava várias horas. Os computadores do início do século eram muito mais lentos do que os atuais e só tinham um núcleo de CPU. Inspirados pelo SETI@Home, um programa que utilizava PCs do mundo inteiro para analisar ondas de rádio à procura de sinais de vida extraterrestre, criámos o VMPi, um sistema distribuído que espalhava o processo de compilação de mapas por vários computadores do nosso escritório. Atualmente, este tipo de sistemas distribuídos funcionam em clusters gigantes de GPUs, mas na altura executávamo-los em todos os computadores do escritório. Para gerir a rapidez com que o código de iluminação evoluía, assim como os mapas, o VMPi também distribuía novos ficheiros .exe a todos os computadores. Em retrospetiva, foi um conceito de segurança assustador, simplesmente péssimo. Um pesadelo para a equipa de TI. Porque estávamos a enviar um executável a todos os PCs do escritório e eram simplesmente executados. Foi uma loucura. Mas funcionou e aumentou a velocidade de iteração dos mapas, o que acabou por ser uma ferramenta essencial."
N/A4196"#commentary\cn_284_field_of_view.mp3" "[ Kerry Davis ] No Half-Life 1, utilizámos um campo de visão de 90 graus que era padrão nos FPS da altura. Mas durante o desenvolvimento do Half-Life 2, ficámos descontentes. Ao estarmos a concentrar o jogo nas personagens, trabalhámos mais nas animações faciais e de corpos detalhadas, mas o campo de 90 graus não permitia que os jogadores se aproximassem para apreciar estes detalhes. Então, começámos a experimentar um campo mais estreito e, finalmente, chegámos aos 75 graus. Isto exigiu ajustes para nós e para os jogadores e foi necessário ter um campo adicional para os modelos de visão, que são a arma do jogador, na parte inferior do ecrã. Os modelos foram originalmente criados para os 90 graus, e por isso pareciam distorcidos em 75. Mas esta mudança conseguiu fazer o que queríamos: colocar as personagens no centro do jogo."
N/A4197"#commentary\cn_285_reference_maps.mp3" "[ Randy Lundeen ] Com as personagens a ficarem mais realistas entre o Half-Life 1 e 2, queríamos que o mundo do jogo fosse igualmente realista. No Half-Life 1, as limitações de um FPS levam-nos a usar ambientes estilizados ou abstratos. Mas no Half-Life 2, planeámos criar um cenário que parecesse real. Para tal, focámo-nos em pequenos detalhes que não tínhamos antes. Um dos passos principais foi criar mapas de referência para padronizar a forma como mapeávamos as proporções do mundo real no jogo. Estes mapas estabeleciam vários detalhes, como dimensões de paredes e portas, alturas de puxadores de portas, iluminação interior, a escala dos móveis e a escala geral de objetos. Criámos texturas padronizadas para os designers, com valores de escala e iluminação, para que os layouts fossem consistentes desde o início. Além de configurarem o mundo físico, estes mapas de referência definiram a forma como o jogador se movia nele. Que altura conseguia saltar, até onde conseguia baixar-se e o tamanho de vários espaços, como saídas de ar. Com estes mapas como base, conseguimos manter a geometria do mundo consistente e garantir espaços de tamanho realistas por todo o jogo."
N/A4198"#commentary\cn_286_response_rules.mp3" "[ Scott Dalton ] No início, já sabíamos que queríamos ter muitos diálogos dinâmicos, e por isso tínhamos de ter um sistema para lidar com eles de forma eficaz. O objetivo era ter um sistema que permitisse aos designers de som acrescentar e ajustar falas sem precisar da ajuda de programadores, que tornasse o diálogo responsivo quanto ao estado do jogo e reduzisse repetições. Com estes requisitos em mente, criámos o sistema Regras de Respostas. Sempre que uma personagem fala fora de uma cena coreografada, este sistema decide fala usar. Em vez de captar as falas diretamente, a IA da personagem está sempre a sinalizar oportunidades para falar quando acontecer um evento relevante. Ver o jogador, magoar-se, disparar a última munição de uma arma, encontrar inimigos fortes, etc. A cada oportunidade, envia ao sistema Regras de Respostas um pacote de dados sobre o estado atual do jogo e o sistema devolve o diálogo mais adequado, caso exista. Esta configuração permitiu que os designers de som pudessem criar uma matriz de decisões detalhadas para os diálogos. Por exemplo, uma personagem tem um conjunto diferente de falas para anunciar que vai recarregar enquanto é atacada, em comparação com o fim de um combate, se só sobrar um aliado ou se houver um Strider à vista. Quando lançámos o Half-Life 2, concluímos que ainda não tínhamos explorado todo o potencial do sistema. Tornou-se uma funcionalidade importante para a Alyx, no Episode One, e passou a reforçar os diálogos dinâmicos nos jogos seguintes, incluindo para as classes do TF2 e para as personagens do Left 4 Dead."
N/A4199"#commentary\cn_287_audio_caching.mp3" "[ Yahn Bernier ] Outro problema que encontrámos foi a enorme quantidade de áudio que tínhamos no jogo. Com todos os sons de jogabilidade, música e diálogos, tínhamos áudio a mais para poder guardar na memória, quer era limitada em 2003. Mas, como é possível imaginar, o jogo tem de reproduzir sons imediatamente, especialmente se estiverem relacionados com a jogabilidade. Por isso, criámos uma cache de áudio que guardava só os primeiros 125 milissegundos de cada ficheiro de áudio e os mantinha na memória. Este tempo de 125 milissegundos era a melhor estimativa de quanto tempo demoraria até conseguirmos ler um ficheiro áudio do disco. Assim, sempre que um som era reproduzido, reproduzíamos o início a partir da cache de áudio enquanto, em simultâneo, iniciávamos o carregamento do ficheiro de áudio completo do disco. Quando o início em cache acabasse, o ficheiro estaria carregado e podíamos continuar a reproduzir o resto do som. Também tínhamos outras funcionalidades, como manter os sons recentes na memória para que os mais usados não tivessem de ser carregados constantemente. Nos motores de jogo atuais, todos os tipos de ativos, para além dos sons, costumam seguir a mesma estratégia."
N/A4200
39184201}
39194202}