Template:PatchDiff/March 6, 2026 Patch/hl2/resource/closecaption brazilian.txt
39153915"wood.scraperough" " "
39163916"plastic_box.scraperough" " "
39173917
N/A3918"#commentary\cn_001_physics_sound.mp3" "[ Jay Stelly ] Para a física parecer correta pro jogador, os sons produzidos pela física também precisavam soar corretos. As pessoas estão acostumadas a como objetos e materiais soam em várias interações, mesmo que não notem ativamente. Embora soubéssemos que não tínhamos como dar conta de tudo, queríamos focar nos detalhes que mais contribuíssem para nossa física soar realista. Começamos com sons de colisões e impactos para cada objeto. Assim, um objeto, como uma caixa de madeira, teria sons personalizados quando colidisse com outros objetos ou classes de objeto. Em seguida, modificamos esses sons de forma dinâmica com base nas características do evento físico, como as massas envolvidas e a força da colisão. Isso funcionou muito bem para colisões, mas não deu muito certo para outras interações, como objetos raspando um no outro. Na vida real, uma caixa de madeira emite um som diferente quando raspa numa parede e quando é arremessada contra ela. E, olha, ninguém fez mais pesquisa sobre as nuances das propriedades físicas de uma caixa de madeira do que nós. Para chegar no resultado desejado com essas interações, implementamos sons de colisão por material: metal em madeira, metal em metal e assim por diante. Também modificamos esses sons de forma dinâmica com base em detalhes, como dureza do material ou tipo de metal. Fazer esse sistema parecer correto demandou muitos ajustes, que só identificamos quando o sistema já estava rodando. Também experimentamos com sons personalizados para objetos rolando, mas acabamos limando esse recurso porque não gostamos do resultado."
N/A3919"#commentary\cn_002_ramming_with_the_buggy.mp3" "[ Jay Stelly ] Nosso sistema de física se baseia em corpos rígidos, ou seja, não suporta deformação nem destruição de objetos. Se um objeto físico é atingido, ele pode se mover caso permitido, senão nada acontece. Quando você atravessa uma janela de vidro com o buggy, temos que empregar uns truques para tudo funcionar conforme o esperado. Como a janela é fixa, a simulação de física faz o buggy quicar na janela e notifica o sistema do jogo que ocorreu uma colisão. Esse sistema cuida da destruição, quebrando a janela em cacos de vidro, e diz para o sistema de física começar a simulá-los. Fundamentalmente, o sistema do jogo também diz para o sistema de física restaurar o estado do buggy anterior à colisão. Assim, na próxima vez que a física é simulada, o buggy vai seguir dirigindo através da janela destruída. Esse processo produz um engasgo de um quadro na física do buggy, como se ele parasse brevemente e fosse teletransportado ao instante antes do impacto. Perdão se, ao saber isso, Half-Life 2 tornou-se totalmente injogável para você. Após ver os testadores na época, acabamos gostando do engasgo momentâneo, pois ele contribuía para a sensação de impacto."
N/A3920"#commentary\cn_003_ramming_zombies_with_the_buggy.mp3" "[ Jay Stelly ] Como seres humanos, temos expectativas para o mundo físico, como já mencionamos nestes comentários. Uma dessas expectativas é que, se você atropelar um zumbi, ele saia voando, mas conseguir esse efeito no jogo não é tão simples como no mundo real. Por motivos de desempenho, inimigos como o zumbi usam uma caixa de colisão simplificada durante o jogo. Essa caixa fica confortável ao redor do zumbi, sem nenhuma parte dele saindo da caixa. Quando o zumbi morre, ele é convertido em boneco de pano, com caixas de colisão mais precisas, divididas por parte do corpo, embora isso demande mais da simulação. Essa mudança na representação da colisão deixa um atropelamento de zumbi com o buggy ainda mais complexo, para além do engasgo no quadro. Quando o buggy acerta o zumbi, ele toca a versão simplificada da caixa de colisão. O jogo mata o zumbi, convertendo-o em um boneco que o sistema de física começa a simular. Com a colisão mais precisa, por parte do corpo, a parte mais próxima do zumbi pode estar a vários centímetros do buggy. Como resultado, na próxima vez em que a física é simulada, o zumbi começa a cair por gravidade, porque o buggy não está mais empurrando ele. Embora demore só um instante até o buggy atingir o zumbi de novo, esta pequena discrepância tirou a graça de atropelar zumbis, já que eles costumavam sair do campo de visão do jogador. Para corrigir esse problema, salvamos a força que a caixa de colisão do zumbi recebeu do buggy e aplicamos a mesma força ao boneco de pano após a conversão. Também incluímos uma ligeira força ascendente no boneco, lançando-o um pouco no ar. Com esses ajustes, os zumbis quase sempre eram jogados por cima do buggy, o que batia com as expectativas do jogador."
N/A3921"#commentary\cn_004_buggy_sound_engine.mp3" "[ Kelly Bailey ] O áudio do buggy foi desafiador porque queríamos que ele parecesse um veículo bem potente, que atinge velocidades altíssimas, embora os mapas não sejam grandes o bastante para dar conta disso e o buggy não sair da primeira marcha. E a velocidade máxima era de uns 60 km/h. Em nossa defesa, 60 km/h ainda é bem rápido, principalmente para 2004. Além da velocidade, os comandos para dirigir são bem simples. Tendo um teclado como dispositivo de entrada, os controles do jogador são basicamente binários: o buggy está acelerando ou não está, indo com força máxima numa direção ou não. Essencialmente, tivemos que criar toda a complexidade de áudio para representar uma simulação bem simples. Construímos um motor falso para o áudio do buggy, com sua própria transmissão, e combinamos os comandos do jogador com dados da simulação de física. Medimos o torque em cada roda simulada, se estava girando ou fazendo contato, e criamos um conjunto de sons em loop a serem meticulosamente mesclados enquanto o motor falso mudava de marcha e respondia aos dados das rodas. Basicamente, só ficamos tentando coisas diferentes e adicionando complexidade. Seguimos ajustando o buggy até ele ficar mais divertido e parecer uma recompensa pela sensação de dirigir rápido. A maioria dos jogadores nem comentou sobre o som do buggy além de dizer que estava bom e, para nós, isso é um sucesso, considerando o tanto de loucura que acontecia por baixo do capô."
N/A3922"#commentary\cn_005_buggy_sound_design.mp3" "[ Kelly Bailey ] O design sonoro do buggy foi baseado em amostras de um Camaro antigo de 1968. Escolhemos esse carro porque ele tem motores V8 incríveis com pistões enormes. E não tem mais nada parecido com esse som visceral que estávamos procurando. A transmissão também emitia um ruído mecânico maravilhoso quando parava de acelerar. Essa combinação pareceu bem responsiva dentro do sistema basicamente binário com o qual tivemos que trabalhar. A transmissão do motor falso não foi inspirada em um carro real; ela foi projetada como um sistema simples para recompensar o jogador por segurar o acelerador. É como uma escada rolante em loop que produz um tom crescente, aumentando a tensão e mudando de marcha sempre que o tom precisava recomeçar. Como o jogador logo ficava sem espaço em nossos mapas relativamente pequenos, o objetivo era só fazer que acelerar por um curto período de tempo fosse divertido."
N/A3923"#commentary\cn_006_automating_dsp.mp3" "[ Kelly Bailey ] Todos os sons que o jogador ouve são processados pelo nosso sistema de Processamento de Sinal Digital, ou DSP em inglês. É basicamente como o áudio é alterado para refletir o ambiente onde o jogador está. Por exemplo, o mesmo som varia se ouvido numa garagem, num cômodo pequeno ou num ambiente externo. Em Half-Life 1, colocamos pontos invisíveis manualmente por todo o mundo para definir as configurações de DSP de cada espaço. Em Half-Life 2, sabíamos que isso consumiria muito tempo, principalmente porque queríamos um jogo maior e ainda tínhamos só uma pessoa de áudio na equipe. Então construímos um sistema que determina automaticamente as configurações de DSP ao redor do jogador em tempo real. Para isso, ele analisa o espaço ao redor do jogador, avaliando o volume, e basicamente examina os materiais que compõem o ambiente. Depois, o sistema pareia o espaço com um dos 25 tipos básicos do DSP feitos à mão, e ajusta alguns parâmetros para criar um DSP rico em detalhes que modifica o som que o jogador escuta."
N/A3924"#commentary\cn_007_dynamic_mixing.mp3" "[ Kelly Bailey ] Durante o jogo, muitos sons tocam ao mesmo tempo, mas alguns são mais importantes que outros. Precisamos ajustar os volumes dos sons relativamente uns aos outros para que os mais importantes se destaquem. Num filme, a mixagem de som ocorre durante o pós-processamento, mas, num jogo, ela acontece em tempo real, reagindo às ações do jogador, então não temos como prever quais sons serão reproduzidos simultaneamente. Para lidar com isso, todos os sons são agrupados em tipos e rotulados com prioridades. Durante o jogo, o sistema de áudio monitora todos os sons ativos e reduz o volume dos sons de um grupo caso um som de prioridade maior esteja sendo reproduzido. Essa mixagem é ajustável. Se os tiros precisam ser mais altos em uma cena, definimos como prioridade naquele momento. Se uma fala específica precisa ser ouvida com clareza, ela pode abaixar o volume de todos os outros sons. Fazemos o mesmo com a música. É um sistema sutil, porém crucial, e evita que a paisagem sonora fique muito confusa."
N/A3925"#commentary\cn_008_soundscapes.mp3" "[ Kelly Bailey ] Em Half-Life 1, os sons do ambiente foram posicionados à mão e ajustados individualmente. Já em Half-Life 2, queríamos mais sons, com mais qualidade e menos trabalho braçal. Foi então que construímos o que chamamos de sistema de paisagem sonora. Uma paisagem sonora é um programinha que controla quais sons de ambiente são reproduzidos, de onde vêm e como se comportam em determinados ambientes. Moscas zumbindo, vento soprando, pássaros, um trem ao longe, combate distante. O sistema de paisagem sonora sorteava e reproduzia um desses sons e, igualmente importante, lidava com as transições suaves de quando o jogador transitava entre ambientes. As paisagens sonoras também contêm outras paisagens sonoras, e isso permite que criemos coleções reutilizáveis de sons. Por exemplo, um combate distante pode incluir tiros mais baixos, explosões distantes, um helicóptero passando. Essas paisagens montam e reproduzem sons individuais de forma dinâmica, e isso nos ajuda a evitar a sensação de artificialidade que tem em uma faixa rodando em loop. O sistema de paisagem sonora foi o carro-chefe do áudio em Half-Life 2, e basicamente responsável por todos os sons que você escuta que não são acionados diretamente pela jogabilidade."
N/A3926"#commentary\cn_009_audio_over_distance.mp3" "[ Kelly Bailey ] Espaços mais amplos nos mapas da Costa nos levaram a buscar uma solução de áudio para a forma como o som muda com a distância. Por exemplo, um inimigo pode estar a mais de 100 metros de distância, e a arma dele pode soar diferente do que quando está perto. Decidimos armazenar os sons em um único arquivo estéreo, com o som próximo no canal da esquerda e, o distante, no da direita. Depois, durante a reprodução, fazemos o crossfade, ou mudamos a proporção de som que você escuta, entre esses dois canais com base na distância do jogador até o som. Foi uma solução simples que deu certo e ajudou com restrições de memória. É fácil ouvir esse efeito em ação — basta escutar como os tiros de um soldado da Combine mudam conforme você se aproxima."
N/A3927"#commentary\cn_010_flying_vehicle_audio.mp3" "[ Kelly Bailey ] Os inimigos voadores grandes no jogo trazem um desafio de áudio bem específico. Durante o combate, eles se locomovem muito mais que os outros inimigos e costumam estar a uma distância maior do jogador. Também são bem perigosos quando têm o jogador na linha de visão. Esses fatores nos levaram a focar numa solução de áudio específica a cada oclusão, ou seja, quando você vê o inimigo e quando ele vê você. Queríamos fazer uma distinção de áudio clara quando houvesse essa linha de visão. Os sons do motor do veículo voador são compostos por vários sons em loop que reproduzimos simultaneamente. Alguns desses loops são processados pelo sistema DSP com base no espaço onde você está, enquanto outros são reproduzidos diretamente, sem processamento. O sistema DSP traz algo mais como um efeito ecoante quando rodamos o som por ele. Quando o inimigo voador está ocluído atrás de um objeto e não pode ver você, aumentamos a porcentagem de loops que passam pelo processamento do DSP, e fica parecendo que o inimigo está um pouco mais distante. Depois, quando ele emerge de trás do obstáculo e passa a ver você, rodamos mais do som direto. De modo geral, isso dá a sensação de que ou o som está distante e não direcionado, ou direto na sua linha de visão. Dá para ouvir quando o helicóptero emerge de trás de um prédio. Idealmente, dá para notar bem a diferença."
N/A3928"#commentary\cn_011_bullet_audio.mp3" "[ Kelly Bailey ] Se uma coisa é certa, é que várias balas passarão voando perto do jogador durante o jogo, então gastamos muito tempo tentando aperfeiçoar o respectivo tratamento de áudio. Infelizmente, as balas no jogo são basicamente instantâneas, então não tem como anexar um som a elas e depender do movimento para posicioná-lo. Após alguns testes, chegamos a uma solução: descobrindo o ponto da trajetória da bala mais próximo do ouvido do jogador, calculamos a posição e o tempo exatos que a bala levaria para passar teoricamente. Em seguida, reproduzimos dois sons diferentes naquele ponto para forjar um efeito Doppler: um para a aproximação da bala e outro para sua partida. Atrasamos o som de partida com base no cálculo do tempo que a bala levaria para passar."
N/A3929"#commentary\cn_012_staircase.mp3" "[ Aaron Seeler ] Há situações no jogo que se originam de metas de design simples e bem diretas, e esta escada exemplifica duas delas. A primeira era enquadrar a Fortaleza despertando, mostrando ao jogador que ele mexeu no vespeiro. A segunda era mostrar o sistema \"boneco de pano\". Embora hoje seja padrão, em 2004 ainda era novidade ver corpos tombando de forma realista, e a escada era o palco perfeito para isso acontecer."
N/A3930"#commentary\cn_013_alyx_and_mossman.mp3" "[ Bill Fletcher ] Em nossos planos iniciais pra narrativa de Half-Life 2, queríamos encarar o desafio de fazer algo menos explicitamente focado em jogo, não só uma história de um jogador obviamente bom derrotando inimigos obviamente maus. Em vez disso, quisemos focar em personagens e suas relações. Pensamos que seria interessante explorar a família como unidade dinâmica central em Half-Life 2. A tensão entre Alyx e Mossman emergiu dessa ideia, e gostamos dela porque era de fácil identificação, algo que o jogador compreenderia e que despertaria empatia."
N/A3931"#commentary\cn_014_exposition_board.mp3" "[ Danika Rogers ] Queríamos colocar esse blocão de história visual aqui porque é o lugar onde o jogo é mais explícito ao dizer ao jogador onde explorar. Embora sua função principal seja construção de mundo, ainda tivemos o cuidado de 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 parte da estação de trem no início foi projetada para fazer a cidade parecer indiferente ao jogador, como se Gordon fosse só outro cidadão sem nome nem rosto, pronto para ser subjugado. Durante o ataque ao cortiço e a perseguição no telhado, a cidade identifica o jogador como uma anomalia e começa a agir. Com o jogador como agressor, a cidade volta toda sua atenção a ele. O sistema de alto-falantes da Vigilância, ouvido pela primeira vez durante o ataque, tem um papel crucial na entrega dessa mensagem. Prestando atenção, muitas informações indicam que a cidade está ciente. Mesmo sem prestar atenção, o tratamento de áudio transmite a mensagem emocional que queríamos."
N/A3933"#commentary\cn_016_elis_lab.mp3" "[ Dhabih Eng ] Construímos o Laboratório do Eli depois do Laboratório do Dr. Kleiner, então já tínhamos uma compreensão melhor de como projetar cenas coreografadas eficazes. Assim, pudemos criar um cenário mais complexo, com mais oportunidades de reação ao jogador. Ter vários personagens, cada um fazendo uma coisa pela sala, complicou a encenação, e precisamos de muitos testes para fazer a cena rodar a contento. Pela nossa experiência, no geral o jogador queria interagir com a cena. Ele só precisava de dicas sutis para saber aonde queríamos que ele fosse. Da mesma forma, se ele se distraísse, a cena seria pausada discretamente, esperando que ele voltasse."
N/A3934"#commentary\cn_017_feel_free_to_look_around.mp3" "[ Dhabih Eng ] É sempre um desafio equilibrar o desejo do jogador de explorar com os objetivos narrativos da cena. Queríamos que a sala fosse cheia de coisas interessantes, mas muitos jogadores não exploravam até terem certeza de que não perderiam as atuações dos personagem. Por isso, foi importante que Eli dissesse ao jogador para dar uma olhada ao redor no meio da cena. Era um sinal de que era seguro explorar. A partir daí, podíamos iniciar várias minicenas personalizadas com base no que despertou o interesse do jogador."
N/A3935"#commentary\cn_018_interstitial_scenes.mp3" "[ Eric Kirchmer ] Conforme os testes avançavam, encontrávamos áreas onde o jogador esquecia o objetivo, o que não é incomum em jogos como Half-Life. Para resolver isso, criamos cenas intersticiais menores para ajudar a guiar o jogador pelo caminho certo e relembrar sua meta. Após terminar o grosso do desenvolvimento de cenas coregrafadas maiores, como o Laboratório do Kleiner, montar cenas menores ficou relativamente simples. Descobrimos que usar personagens nesses momentos funcionava muito melhor que confiar em narrativas passivas ou mesmo algum tipo de lembrete que você encontraria incorporado no menu de pausa."
N/A3936"#commentary\cn_019_overwatch.mp3" "[ Josh Weier ] Durante o desenvolvimento, geramos a voz da Vigilância usando uma conversor gratuito de texto para voz. Mas, perto do lançamento, notamos que não tínhamos direito de usá-lo. Fizemos audições para encontrar alguém que tivesse as qualidades que queríamos para as falas geradas. Não demorou muito até encontrarmos Ellen McClain, cuja atuação foi exatamente o que procurávamos. Nas sessões dela, reproduzimos as falas geradas para ela imitar, só que do jeito dela. Ela foi um pouco sarcástica no começo, já que estávamos pedindo para ela replicar a atuação robótica. Anos depois, quando ela voltou em seu papel marcante como GLaDOS em *Portal*, ela encontrou uma forma criativa de integrar aquele tom em sua atuação."
N/A3937"#commentary\cn_020_box_car_joe.mp3" "[ Laura Dubuk ] Originalmente, havia dois personagens humanos nesta cena curta, mas depois substituímos um deles por um vortilético. Queríamos mostrar que os vortiléticos coexistiam com os humanos, resistindo também à Combine. Além disso, apresentamos sua habilidade de curar o jogador, embora não tenhamos explorado muito esse recurso ao longo do jogo. Os vortiléticos tornaram-se uma ferramenta narrativa útil para encurtar diálogos, pois sua mente coletiva explicava como eles sabiam tudo do mundo e dos objetivos do jogador. Assim, eles nunca precisavam perguntar nada, evitando com elegância o desafio de escrever diálogos para um protagonista mudo."
N/A3938"#commentary\cn_021_mossman.mp3" "[ Marc Laidlaw ] Originalmente, Judith Mossman foi baseada em uma personagem que planejamos para uma parte que foi cortada de Half-Life 1 e reutilizada em Uplink, mas sem a personagem. Nós a consideramos a personagem mais complexa de Half-Life 2. Sabíamos que prever o que o jogador sentiria por ela seria como andar na corda bamba, mesmo antes de Nova Prospekt, pois as fontes em que o jogador confiava discordavam: o Eli gosta dela, mas a Alyx não. Reconhecemos a limitação de complexidade que conseguiríamos pôr nas relações, mas achamos que o jogador entenderia uma dinâmica entre madrasta e enteada. Concorde ou não com Mossman, ela está fazendo algo heroico. Ela se arrisca sendo agente dupla para obter as informações de que precisa para proteger Eli e Alyx. Ela só não contava com o Gordon."
N/A3939"#commentary\cn_022_hands_free.mp3" "[ Matt Wright ] Quando Half-Life 2 foi lançado, a maioria dos FPS dava uma arma de fogo ou uma arma branca logo de cara, mas optamos por fazer o jogador começar sem nada. Sem arma, era mais fácil treinar o jogador em novas formas de interagir com o mundo e apresentar a história. Queríamos que o jogador se transformasse de fugitivo em agressor. Dar uma arma na hora certa criou esse momento de transição naturalmente. Quando pega a arma, o jogador para de fugir. Dizem que muitas vezes a melhor forma de vencer é sair de perto, mas sabemos que não é verdade. A melhor forma de vencer é correr atirando na direção do inimigo."
N/A3940"#commentary\cn_023_metrocop_scene.mp3" "[ Mike Dussault ] Esta é outra cena criada para deixar claro que os policiais são os vilões, só que, desta vez, o jogador está armado e pode finalmente fazer algo. Esse \"algo\" vem do cano de uma arma. Sabíamos que o jogador precisava sentir que estava fazendo justiça, e este momento contribui nesse sentido. Os policiais ainda são humanos, diferentemente dos outros membros da Combine no jogo, então tivemos muito cuidado para as ações do jogador parecerem justas, não apenas um ato de fúria."
N/A3941"#commentary\cn_024_moving_the_gravity_gun.mp3" "[ Ted Backman ] Quando saiu o primeiro protótipo da arma de gravidade, o plano era que ela aparecesse no meio do jogo. Conforme avançaram os testes, vimos a força de seu design e notamos que a arma de gravidade — e principalmente, a capacidade de lançar serras na cara dos zumbis — precisava aparecer antes. E, por consequência, o laboratório do Eli também. Foi uma mudança significativa, mas crucial para o sucesso de Half-Life 2. Esse caso serve como lembrete de que narrativa e jogabilidade estão interligados e que nenhum dos dois pode ter a prioridade sempre — eles precisam caminhar juntos."
N/A3942"#commentary\cn_025_buggy_birds.mp3" "[ Adrian Finol ] Em um momento memorável dos testes na Costa, um jogador voltou ao veículo após explorar uma casa e viu um pássaro passar voando. Ele gritou com o pássaro, mandando ele ficar longe do buggy, reclamando que as aves costumam sujar o carro dele na vida real. Em discussões pós-teste, percebemos que era a primeira vez que tinha um objeto importante para o jogador longe dele. Vimos como uma oportunidade a explorar, então criamos um sistema para entregar o momento tão temido pelo testador. Quando o jogador ficava com o buggy fora de visão por um tempo, gerávamos uma gaivota em um local aleatório da estrutura do veículo. Com o tempo, a gaivota gerava adesivos de titica no corpo do carro abaixo dela, continuando até o jogador voltar, quando então ela saía voando. Obviamente, os testadores quiseram uma forma de lavar o veículo, então fizemos o carro ficar limpo ao passar por águas rasas. Era tão tarde no desenvolvimento que já dispúnhamos de toda a tecnologia necessária, então foi rápido de implementar. É um daqueles casos que sabemos que só uma pequena porcentagem dos jogadores vai descobrir, mas, se colocarmos vários detalhes assim com eficiência ao longo do jogo, a maioria dos jogadores vai encontrar pelo menos um."
N/A3943"#commentary\cn_026_bridge_gunship.mp3" "[ Adrian Finol ] Ficamos bem satisfeitos com a luta com a aeronave de combate, embora tenha sido difícil de configurar, dada a geometria da fase. Com o jogador sob a ponte, a aeronave pode se mover totalmente ao redor, usando as três dimensões para se posicionar acima ou abaixo em diferentes momentos. As vigas forneciam cobertura bem detalhada, criando oportunidades para os tiros da aeronave produzirem um espetáculo sonoro e visual bem divertido e dinâmico.
N/A3944"
N/A3945"#commentary\cn_027_floor_is_lava.mp3" "[ Adrian Finol ] Criar jogabilidade em torno de um conceito amplamente conhecido como \"chão de lava\" facilita o treinamento. Gostamos de como nosso sistema de física dava margem a uma grande liberdade criativa quanto à abordagem do jogador. Alguns criavam passarelas com muitos objetos, enquanto outros usavam suas duas placas de metal favoritas. Alguns seguiam o caminho pelas pedras, preocupados em não cair, enquanto outros iam direto até a saída se apoiando em objetos logo acima da areia. Os estilos de jogo variavam. Alguns sentiam que haviam falhado se chamassem formigas-leão e recarregavam o jogo na hora, enquanto outros gostavam de voltar correndo até as pedras para se recompor. Também gostamos que funcionava como um quebra-cabeça de navegação, mas podia virar uma arena se o jogador preferisse. Alguns simplesmente pulavam na areia e seguiam lutando até o fim."
N/A3946"#commentary\cn_028_opportunistic_moments.mp3" "[ Ariel Diaz ] Alguns momentos memoráveis vêm de interações de vários sistemas de jogo, mas às vezes esses momentos só ocorrem raramente. Quando é o caso, costumamos ficar querendo que mais jogadores os vivenciem. Há uma tensão: quanto mais sabemos que o jogador vai encontrar alguma coisa, mais esforços empregamos. Mas, se parecer muito artificial, o momento pode ficar forçado, e o jogador talvez não responda de forma tão positiva. A cena da morte da aeronave de combate é um exemplo onde forçamos um pouquinho a barra tentando aumentar as chances de ocorrer um momento memorável sem que ficasse muito óbvio. Por conta do projeto desta área e dos caminhos de voo da aeronave, é provável que o jogador e a aeronave estejam nos lugares certos quando ela morre. Se estiverem, acionamos a queda da aeronave sobre os carros. Se não, ela morre do jeito normal. Tem muita cara de jogo, mas os testadores não se incomodaram com essa cena."
N/A3947"#commentary\cn_029_assault_on_nova_prospekt.mp3" "[ Ariel Diaz ] Com um exército de formigas-leão ressurgindo infinitamente no litoral durante o ataque à base fortificada da Combine, foi difícil fugir de uma fase inspirada na Normandia. Nosso protótipo inicial tinha trincheiras levando a Nova Prospekt, com metralhadoras letais obrigando o jogador e suas formigas-leão a ficar nas trincheiras para sobreviver. Era emocionante ter as metralhadoras atirando e as formigas-leão passando por cima das trincheiras. Infelizmente, não deu com nossa limitação de desempenho e tivemos que substituir por uma diagramação totalmente diferente. Mas as metralhadoras fixas ficaram, e sua letalidade provou ser útil em encorajar o jogador a contar com suas formigas-leão."
N/A3948"#commentary\cn_030_buggy_physics.mp3" "[ Charlie Brown ] A física do buggy precisou de muita tentativa e erro. Queríamos que ele parecesse rápido, embora não chegasse a 60 km/h, então tivemos que trapacear para fazer dar certo. Acrescentamos força vertical extra no salto com turbo e um impulso na traseira ao usar o freio de mão para derrapar. Sem isso, a velocidade baixa tirava a diversão de dirigir o buggy. Além disso, o mundo é cheio de caos imprevisível por conta da física. O jogador vai acabar colidindo com o buggy, então tivemos que garantir que sempre desse para sair de qualquer situação. Precisamos de muita experimentação e testes. No fim, nos contentamos com uma simulação bem boba e nada realista que deixava o buggy mais difícil de capotar e com controle mais tolerante. O centro de gravidade é bem baixo, e as rodas, embora pareçam que podem virar bastante, não viram muito. Foi nossa primeira tentativa com um veículo de física simulada e aprendemos muito. Graças a isso, conseguimos deixar o muscle car no Episode 2 muito mais fácil de dirigir."
N/A3949"#commentary\cn_031_the_bridge.mp3" "[ Charlie Brown ] Esta parte da ponte foi inspirada na Deception Pass Bridge, próxima ao escritório da Valve. Começamos construindo esta parte como um quebra-cabeça de navegação e fomos incluindo elementos gradualmente. Ela também foi nosso teste primário para o atrito de beirada do jogador. No nosso sistema de movimento, aumentamos sutilmente o atrito na desaceleração do jogador conforme ele se aproxima da beirada de uma superfície. Os jogadores nunca notaram, provavelmente porque se alinha ao objetivo de parar na beirada para olhar para baixo, o que combina com a tendência humana de andar mais devagar e com mais cuidado perto de um abismo. Mas é um recurso essencial nesta parte. Certa vez, quebramos esse recurso sem querer e todos os testadores começaram a despencar várias vezes."
N/A3950"#commentary\cn_032_coast.mp3" "[ Chris Green ] Queríamos uma área bem aberta pro buggy, mas ainda precisávamos de uma forma de restringir o movimento do jogador. A escolha de um litoral forneceu limites naturais em um lado do mapa, enquanto ainda parecia aberto e expansivo. Também ajudou a visualizar os efeitos da extração de recursos que a Combine fez na Terra. Os testadores tentavam nadar para o mar aberto, então incluímos sanguessugas para detê-los. Elas não podiam ser um inimigo real e evitável que parecesse possível de derrotar, então ficaram meio mágicas. Em geral, o jogador entende que está forçando os limites do jogo, então não as desenvolvemos demais."
N/A3951"#commentary\cn_033_grenade_house.mp3" "[ Dave Riller ] Boa parte de Half-Life foca em dar ao jogador uma experiência de combate ligeiramente nova a cada curva, mesmo que seja uma diferença pequena. Nem todas precisam ser desafios focados na habilidade. Às vezes, pode ser um momento divertido que o jogador simplesmente aproveita. Esta casa de granadas é um desses momentos. Aqui, invertemos a configuração normal. Em vez de o jogador lançar granadas em inimigos lá embaixo, nós os colocamos no alto. A caixa de granadas ilimitadas é uma forma meio troncha de motivar o jogador a interagir com o cenário, mas sua invulnerabilidade garante que o jogador ainda poderá subir para o andar de cima, mesmo que exploda toda o resto."
N/A3952"#commentary\cn_034_buggy_training_course.mp3" "[ David Sawyer ] Esta seção de treino foi projetada para que jogador brinque com o buggy. Quando Half-Life 2 foi lançado, este nível de simulação física em um veículo era novidade, então queríamos dar ao jogador ampla oportunidade de experimentar com ele. O jogador também acabou de sair das áreas mais confinadas de Ravenholm, então achamos boa ideia dar a recompensa contrastante de poder se locomover rapidamente por uma área grande na segurança de um veículo. Por fim, a saída da área exige um salto com turbo, que serve tanto como teste do nível de conforto do jogador na direção, quanto como garantia de que o buggy não seria deixado para trás."
N/A3953"#commentary\cn_035_ambush.mp3" "[ David Sawyer ] Um dos desafios de um FPS no estilo Half-Life é que o jogador está sempre avançando para áreas que não conhece. Assim sendo, quando entra em combate, ele não está familiarizado com a área, nem tem conhecimento de como abordar a luta. Usamos métodos diferentes para ajudar o jogador com esse problema, e esta emboscada é um exemplo. Ao chegar aqui, o jogador luta com um grupo da Combine nessas casas. Durante a luta e na exploração subsequente, ele tem a chance de conhecer a disposição da arena. Depois, quando o jogador explora este sótão, geramos uma segunda leva de inimigos da Combine. Na segunda luta, o jogador já tem conhecimento, então consegue tomar decisões mais táticas na hora de se defender."
N/A3954"#commentary\cn_036_bugbait_training.mp3" "[David Sawyer ] Este treino desengonçado de isca foi o que deu para fazer, já que estávamos sem tempo, mas precisávamos que os jogadores entendessem a ferramenta para o design de Nova Prospekt funcionar. Em geral, tentamos trazer contexto e narrativa para o treino não parecer treino, e sim parte natural de uma descoberta. Aqui, não conseguimos fazer isso. Por mais óbvio que pareça, a isca não foi algo que os jogadores entenderam de forma intuitiva. Já avançamos bastante no jogo, então o jogador já tem muita experiência em como lidar com inimigos. Antes de criarmos um treino, os primeiros testadores que coletavam a isca entravam na fase seguinte e atiravam instintivamente na primeira formiga-leão que viam porque isso sempre funcionou. Half-Life tende a encorajar uma abordagem de atirar antes de perguntar. De forma parecida, quando chega a Nova Prospekt, o jogador não pensa em jogar a isca nos soldados da Combine. Em vez disso, contam com as armas tradicionais, então precisamos deste treino não apenas para mostrar o funcionamento da isca, mas também que as formigas-leão podiam ficar perto do jogador sem atacá-lo"
N/A3955"#commentary\cn_037_vortigaunt_extraction.mp3" "[ Dhabih Eng ] Esta arena trouxe dois problemas de design principais. Primeiro, a Guarda é um inimigo que ataca apenas de perto, então o jogador não podia ficar em áreas inalcançáveis por ela. Experimentamos alguns ataques à distância, mas não gostamos dos resultados. A cusparada de gosma, por exemplo, ficou ridícula. O único ataque à distância que sobreviveu foi sua capacidade de lançar objetos físicos contra o jogador, mas isso requer que haja objetos disponíveis, o que nem sempre é garantido. O segundo problema foi que o Vortilético conseguisse alcançar o corpo da Guarda onde quer que ela morresse. Isso foi essencial porque o jogo não avança se o Vortilético não conseguir extrair a isca."
N/A3956"#commentary\cn_038_dropship_deployment.mp3" "[ Doug Wood ] Enviar soldados de cargueiros foi complicado, pois os PNJs precisam ser gerados dentro de um objeto sólido. Para fazê-los surgir onde pudessem se locomover normalmente, eles rodam imediatamente uma animação que os faz pular do contêiner na hora em que surgem. Quando essa parte estava funcionando, encontramos outro problema: os jogadores mais espertos simplesmente esperavam fora do contêiner e atiravam nos soldados durante a animação de saída. Para tentar impedir, colocamos uma torreta no contêiner para defender os soldados. Não que isso evite totalmente que um jogador tire proveito desse momento, principalmente se estiver usando armas indiretas como a granada, mas pareceu realista, uma contramedida verossímil do que alguém faria se estivesse pensando estrategicamente."
N/A3957"#commentary\cn_039_laser_guided_rpg.mp3" "[ Eric Smith ] O recurso de mira a laser do lança-foguetes foi uma baita dor de cabeça porque era difícil de ensinar. Muitos testadores disparavam o foguete e logo se abaixavam para se proteger, ou seja, não viam o trajeto de voo do foguete. Pior ainda, não percebiam que o foguete estava voltando até eles. Tentamos vários elementos no HUD e indicadores com ponto de laser para ajudar, mas a maioria dos jogadores não percebeu, pois só focava no inimigo. Fizemos várias melhorias pequenas, como enfatizar o recurso da fala do Odessa e aprimorar as dicas sonoras e visuais de como a aeronave da Combine abate tiros diretos com o lança-foguetes. Embora essas mudanças tenham ajudado alguns jogadores, nunca chegamos a um ponto em que sentíssemos confiança que quase todo mundo entenderia. Até pensamos em cortar o recurso, mas o combate com a aeronave sem ele seria bem menos interessante. A mira a laser obrigava o jogador a manter a aeronave na linha de visão enquanto o foguete estivesse no ar, mas a linha de visão era recíproca, e isso criava a tensão que tanto amamos."
N/A3958"#commentary\cn_040_performance_constraints.mp3" "[ Eric Smith ] Para a última arena da Costa, idealizamos um final de peso com o jogador e um esquadrão de cidadãos contendo levas de soldados da Combine, culminando com uma batalha contra a aeronave de combate. Infelizmente, o custo computacional de ter soldados e aliados andando pelo terreno nos obrigou a reduzir a escala da batalha para que ela se encaixasse nos nossos limites de desempenho. Quando só conseguíamos ter um esquadrão de soldados de cada vez, já estava tarde demais. Não dava pra fazer mudanças de larga escala na arena para acomodar mais inimigos, então tivemos que reprojetar o fluxo da luta para reduzir o número de soldados ao mínimo."
N/A3959"#commentary\cn_041_lighthouse_gunship.mp3" "[ Ido Magal ] O cenário da aeronave aqui precisou de trabalho para rodar, queríamos como nos filmes. Na versão cinematográfica, a aeronave atiraria pelas janelas enquanto o protagonista subiria pelo farol, prevendo os movimentos dele. Para simular essa previsão no jogo, preparamos uma série complexa de volumes de gatilho pela escada. Quando detectam o jogador subindo, eles instruem a aeronave a escolher uma nova rota de voo que bata com a altitude do jogador. Os gatilhos também ativam alvos nas janelas mais próximas do jogador — objetos invisíveis no jogo que a IA inimiga percebe como hostis — e fazem a aeronave atirar nas janelas. Essa mistura de roteiro e IA é central nos cenários de combate de Half-Life. A IA gerencia o comportamento geral e adaptável dos PNJs, enquanto o roteiro personaliza os requisitos específicos de cada cenário."
N/A3960"#commentary\cn_042_crane.mp3" "[ Jakob Jungels ] O Guindaste precisou de muitos ajustes até acertarmos. Algo que precisasse gerar tanta força física era sempre arriscado, considerando nossas limitações de física de corpos rígidos e tecnologia de destruição. Por exemplo, o ímã jamais atenderia a todas as expectativas do jogador por conta de sua massa, mas o Guindaste ficava parado, então podíamos escolher tudo dentro de seu alcance e ajustar conforme o necessário. Felizmente, a maioria dos jogadores não notou a falta de polimento, provavelmente por conta da novidade que era interagir com algo assim em um ambiente com física vagamente realista."
N/A3961"#commentary\cn_043_flashlight_power.mp3" "[ Jeff Lane ] A decisão de fazer a corrida e a lanterna dividirem a energia do traje HEV foi controversa em Half-Life 2. No começo, só a corrida usava a energia do traje, o que fazia sentido, já que era só um rompante curto de velocidade. A lanterna, por outro lado, podia ser usada sem limite, mas os testes revelaram um problema: os jogadores costumavam sair de áreas escuras e deixavam a lanterna ligada sem perceber. Em áreas abertas e iluminadas como a Costa, nossos limites de desempenho não comportavam uma lanterna ligada o tempo todo, então precisávamos de uma forma de desligá-la sem envolvimento do jogador. Limitar a energia pareceu uma solução simples, com o benefício de criar tensão em áreas escuras também. O desafio então foi saber que recurso ela usaria. Já tínhamos a energia do traje e não queríamos poluir a IU com um recurso novo só para a lanterna. Brincamos com a ideia de outras habilidades do jogador usarem a energia do traje, pensando que podia ser interessante fazer o jogador escolher entre elas. Este é um bom exemplo de como projetar um jogo pode forçar uma escolha entre soluções imperfeitas. Não adoramos a ideia de a corrida e a lanterna dividirem o mesmo recurso, mas também não queríamos vários recursos poluindo a IU. No Episode 2, sem planos de criar nada novo que consumisse a energia do traje, acabamos criando um recurso separado para a lanterna."
N/A3962"#commentary\cn_044_open_world_loot.mp3" "[ Jeff Lane ] A natureza aberta da Costa trouxe o problema quanto à forma de distribuir itens como recompensa. Em um jogo Half-Life, geralmente recompensamos o jogador por explorar. Se você vê o caminho a seguir, mas nota algo em um desvio, geralmente há algo útil para quem vasculhar ali. Quando começamos a testar nossos mapas da Costa, escondemos recompensas nos cantos das áreas externas, mas isso levou a uma experiência pior com o buggy. Como eram espaços amplos, sempre havia áreas pequenas que pareciam conter alguma coisa, e os jogadores paravam e saíam do buggy para explorar. Acabou ficando tedioso e interrompendo a diversão, então tiramos os itens espalhados, mas isso trouxe outro problema: como dizemos ao jogador quando vale a pena sair do buggy? Após pensar um pouco, criamos uma regra: qualquer tipo de construção humana sempre viria com conteúdo de jogabilidade e recompensas de exploração, enquanto áreas puramente naturais ficariam vazias. Não íamos dizer isso ao jogador diretamente, mas se alinhava com suas suposições naturais, e reforçamos essa noção consistentemente com áreas assim."
N/A3963"#commentary\cn_045_gas_station.mp3" "[ Jeff Lane ] Tínhamos grandes planos para este encontro. A ideia era construir um posto de combustível onde o jogador travaria a luta, provavelmente ateando fogo em tanques de gasolina e em tudo o mais. Imaginamos o jogador saindo de buggy no meio de grandes labaredas, mas orçamento e desempenho eram limitações cruéis em 2003, e o posto precisava ser menor e mais simples para caber nas fases maiores da Costa. Nosso plano de um sistema de fogo dinâmico não se materializou e nem fazia mais sentido. Há limite no tanto de esforço que é justifável para um único confronto. No fim, os únicos resquícios da ideia original são os tanques de gasolina explosivos."
N/A3964"#commentary\cn_046_buggy_introduction.mp3" "[ John Cook ] Queríamos algo mais envolvente para a introdução do buggy que só entrar no veículo e sair dirigindo. O guindaste ajudou com isso. Era crucial que o jogador aprendesse a recuperar o buggy quando ele capota, e esta sequência o obriga a passar por essa situação. Treinar sob pressão é sempre complicado, mas queríamos enfatizar a infestação de formigas-leão como motivo para ficar dentro do buggy. Deixamos a ameaça das formigas-leão ativa e colocamos alguns cidadãos em armas fixas dando suporte. E um pequeno bônus: o jogador passa pela experiência de ser içado pelo guindaste logo antes de ter a chance de operar um guindaste."
N/A3965"#commentary\cn_047_crossbow.mp3" "[ John Cook ] Esta é a primeira oportunidade de o jogador conseguir a besta e, em retrospecto, é um tanto surpreendente que não tenhamos forçado o jogador a pegá-la antes de seguir. É bem possível que o jogador passe direto por ela. Para reduzir a probabilidade, bloqueamos a estrada e criamos um ponto de vantagem para estimular o jogador a sair do buggy e encontrar a besta e a caixa de item. Os testes mostraram que quase todo jogador parou e pegou a arma, mas é um caso em que a diferença entre um teste e uma sessão de jogo real pode fazer a diferença. Um testador que está jogando desde o começo da Costa pode não estar tão fadigado com a exploração quanto alguém que tenha jogado desde o começo do jogo. Por isso, colocamos outra besta algumas fases depois, bem no caminho do jogador em Nova Prospekt."
N/A3966"#commentary\cn_048_rollermines.mp3" "[ Josh Weier ] Minas rolantes foram criadas para suprir a necessidade de uma ameaça a quem estivesse dirigindo o buggy. Como o jogador no buggy era essencialmente uma entidade com simulação física integral, achamos que seria interessante também ter um inimigo simulado com física. O Cortador já havia mostrado como essa abordagem pode trazer um inimigo com muitas interações interessantes com o mundo, então criamos a mina rolante — uma bola cujo movimento é totalmente impulsionado pelo torque gerado em si mesma — e testamos seu comportamento até ficar divertida para quem está dirigindo. As minas rolantes não são especialmente perigosas para o buggy, mas podem virar um problema se você deixar acumular, principalmente perto de penhascos. Também cuidamos para ela funcionar bem com o jogador a pé, e os projetistas incluíram alguns encontros extras com ela."
N/A3967"#commentary\cn_049_sandtrap_thumper.mp3" "[ Laura Dubuk ] Fornecemos os barris explosivos para o jogador usar contra as formigas-leão de dentro da proteção do Batedor, mas isso também serve como dica para o confronto iminente com a Formiga-leão Guarda, no qual os jogadores costumam usar táticas semelhantes para vencer. Ações opcionais como lançar explosivos com a arma de gravidade podem ser esquecidas se não forem usadas com frequência. Com tantas opções ofensivas disponíveis, não há garantia que o jogador tenha usado essa habilidade recentemente. Aqui, estamos sugerindo de forma sutil que eles se lembrem dessa ferramenta antes de enfrentarem a Guarda."
N/A3968"#commentary\cn_050_coast_kickoff.mp3" "[ Marc Laidlaw ] Esta cena intersticial veio tarde para conectar Ravenholm à Costa. Notou uma tendência? Boa parte do tecido conjuntivo dos nossos jogos chega tarde. Neste caso, precisávamos de todo atalho possível. Não tivemos tempo nem para animar Alyx no monitor. É sempre um desafio deixar cenas como esta interessantes, e esta não foi um sucesso. É um bom exemplo do que acontece quando tratamos PNJs como placas informativas, sem incluir personalidade neles nem na cena. O resultado é um momento esquecível em que as falhas do jogo ficam visíveis, mas essa é a natureza do desenvolvimento de jogos. Você tem tempo limitado e precisa decidir onde alocá-lo. Os Laboratórios do Kleiner e do Eli eram muito mais importantes, então foi onde concentramos nossos esforços."
N/A3969"#commentary\cn_051_odessa_cubbage.mp3" "[ Marc Laidlaw ] Odessa Cubbage é um exemplo de participação especial que achamos que funciona bem. Ele é um cara divertido, com detalhes interessantes, vivendo dentro da própria bolha. Como não sai do cenário dele, ele tem liberdade de ser exagerado a ponto de se destacar. Começamos com o modelo dele, que foi reaproveitado de uma parte que cortamos do jogo, e o batizamos em homenagem ao título de um e-mail de spam que recebemos. O modelo original era de um pescador norueguês e não encaixava muito bem para um inglês, então tascamos um bigode nele. Naquele momento, nascia Odessa. Basicamente, ele é um charlatão. Tudo nele é falso: o sotaque, o bigode, tudo mesmo. Ele nunca se colocaria em perigo, então é a pessoa perfeita para entregar o lança-foguetes a Gordon e explicar exatamente como usá-lo."
N/A3970"#commentary\cn_052_28_transitions_later.mp3" "[ Marc Laidlaw ] Depois de costurar fases usando túneis escuros como espaços de transição, tivemos a ideia de subverter as expectativas do jogador construindo um local que parecesse de transição, mas que contivesse outra coisa. Como todo mundo, vimos Extermínio em 2002, adoramos, e logo quisemos criar um confronto crescente com zumbis em um dos nossos túneis escuros. Ficou pronto rápido e gostamos do resultado. Anos depois, conhecemos Alex Garland, roteirista do filme. Ele tinha jogado Half-Life 2 e gostado. Confessamos que o filme dele havia inspirado essa parte do jogo."
N/A3971"#commentary\cn_053_finest_mind_of_his_generation.mp3" "[ Marc Laidlaw ] Temos aqui outra ceninha intersticial que acabou dando certo. O único requisito deste momento era ensinar o jogador a ficar longe da areia. Nas cenas anteriores, ainda estávamos focados em deixá-las funcionais, mas, com o tempo que levou até aqui, já estávamos mais acostumados e começamos a curtir o processo de pensar mais nesses momentos. Assim, fizemos os personagens serem mais que placas informativas, criando algo mais envolvente e divertido. Após o lançamento, Laszlo acabou conquistando uma popularidade enorme, o que serve de lembrete de como é difícil prever a que os jogadores vão se apegar."
N/A3972"#commentary\cn_054_bridge_playtesting.mp3" "[ Matt Boone ] A parte da Ponte foi um ponto alto nos testes. Os testadores sempre reagiam bem. A tensão que sentiam enquanto cruzavam as vigas devagarinho era visível em seus movimentos. Com o tempo, incluímos mais desafios na travessia, e os testes ficaram mais divertidos de assistir. Isso ia do trem fazendo a ponte tremer e sacudindo o jogador a um chupa-crânio surpresa em uma casinha que parecia um porto seguro no meio do caminho. Sentíamos um pouco de culpa ao ficarmos animados com o estresse visível do jogador, mas não éramos monstros: depois que cruzava a ponte, o jogador respirava aliviado, desativava o escudo da Combine, e então se dava conta de que precisava voltar pela parte de baixo. Preocupados que ele poderia ficar entendiado na segunda perna da viagem, decidimos trazer uma aeronave de combate para lhe fazer companhia nas vigas."
N/A3973"#commentary\cn_055_thumper_final_stage.mp3" "[ Matt Boone ] Gostamos da fase final dos Batedores, onde seu propósito é invertido. Em vez de servir como ferramenta de segurança, eles agem como um bloqueador do exército de formigas-leão do jogador. Contudo, devíamos ter incorporado mais treinos com o Batedor antes deste ponto. Embora seja aceitável para o jogador entender o Batedor parcialmente nas fases iniciais da Costa, aqui há mais coisa em jogo porque o jogador também está experimentando com a isca pela primeira vez. Quem não se dá conta de que este primeiro Batedor impede as formigas-leão de avançarem pode entender errado o funcionamento da isca. Se jogar uma isca em um soldado no primeiro bunker e não vier nenhuma formiga-leão, o jogador pode concluir que a isca não é confiável ou que não funciona como o esperado, voltando a usar as armas convencionais."
N/A3974"#commentary\cn_056_buggy_tools.mp3" "[ Matt Wright ] Queríamos que o buggy fosse mais que um meio de transporte, então acoplamos uma arma nele. Escolhemos o Canhão Tau, arma de Half-Life 1 de que gostávamos, mas para a qual ainda não tínhamos achado um lugar em Half-Life 2. Esse canhão atira através da parede, o que dificulta o projeto da fase, então o limitamos à Costa. Quando trazemos armas que perfuram a parede, projetar as fases fica muito mais difícil. Além disso, incluímos uma caixa de munição na traseira do buggy, dando ao jogador munição ilimitada de submetralhadora durante a Costa. Isso ajudou especialmente os testadores que penavam com formigas-leão infinitas surgindo da areia."
N/A3975"#commentary\cn_057_antlion_guard.mp3" "[ Matt Wright ] Em casos raros, o jogador podia ficar impossibilitado de matar a Formiga-leão Guarda nesta arena. Isso acontece se acabar a munição e os objetos físicos disponíveis não tiverem sido utilizados direito, não sobrando nada a lançar com a arma de gravidade. Para lidar com isso, pusemos uma pessoa na torreta fixa acima do portão como garantia. Assim, o jogador que estiver preso pode contar com ela para matar a Guarda."
N/A3976"#commentary\cn_058_terrain_and_performance.mp3" "[ Mike Dussault ] Nosso orçamento de desempenho era uma limitação significativa frequente nos combates, e mais ainda em combates em superfícies de terreno. Quando se desloca, o PNJ faz várias sondagens espaciais para descobrir se pode caminhar pelo caminho escolhido. Imagine que ele não enxerga e está sempre usando um bastão para conferir se o caminho está livre. O custo de desempenho dessas sondagens aumenta com a complexidade da geometria do mundo. Nosso sistema de deslocamento de terreno cria superfícies irregulares com muitos polígonos — bem mais que nos chãos perfeitamente planos dos outros lugares. Assim, um PNJ se locomovendo no terreno da Costa consumia muito mais recursos que em outras áreas, e essa limitação ditou a escala de muitos confrontos nesta parte do jogo."
N/A3977"#commentary\cn_059_area_portals.mp3" "[ Mike Dussault ] Um desafio de desempenho que enfrentamos na Costa foram áreas abertas que incluíam prédios com interior bastante detalhado — para os padrões de 2003. Quando o jogador está em uma área externa, alocamos o máximo do desempenho para renderizar aquele espaço, sem perder recursos para construir os interiores, mas, a menos que fôssemos fechar todas as portas e janelas, o jogador ainda veria lá dentro. Como solução, criamos um recurso chamado de \"Portal de Área\", e colocamos um desses em cada porta e janela. O Portal de Área pré-computa uma imagem plana do interior do prédio. Durante o jogo, quando o jogador está a alguma distância, o Portal de Área exibe essa imagem pré-computada em uma janela ou porta, tirando a necessidade de renderizar de fato o interior. Conforme o jogador se aproxima, fazemos uma transição suave da imagem do Portal de Área para o conteúdo real do prédio. Usando os Portais de Área com cuidado, atingimos nossos objetivos de desempenho na Costa, e em algumas outras que se fecham quando o jogador passa."
N/A3978"#commentary\cn_060_buggy_removal.mp3" "[ Miles Estes ] Quando chegamos ao ponto onde queríamos que o jogador deixasse o buggy para trás, tivemos que ser bem explícitos. Por toda a Costa, os jogadores deixavam o buggy e depois voltavam a ele, então achamos que os testadores tentariam levá-lo adiante se parecesse remotamente possível. Esta ceninha na garagem existe principalmente para mostrar sem sombra de dúvida que o jogador não vai mais dirigir e que deve seguir a pé."
N/A3979"#commentary\cn_061_d2_coast_04.mp3" "[ Randy Lundeen ] Este mapa foi a primeira área da Costa que construímos, antes do Guindaste e de outros elementos existirem. O fundo do mar seco e os navios enferrujados foram alguns dos primeiros elementos da direção de arte que criamos. Anos depois, exibimos o mapa na nossa demonstração na E3 de 2003, embora ainda não tivéssemos decidido boa parte da jogabilidade. Assim, quando começamos a criar a seção inteira da Costa, aquela demonstração serviu como uma visão útil na qual miramos."
N/A3980"#commentary\cn_062_transition_tunnels.mp3" "[ Randy Lundeen ] Para construir a Costa, precisamos desenvolver uma forma de lidar com transições entre as fases. Para ir de uma fase a outra, tínhamos que salvar tudo no espaço de transição enquanto o jogador estivesse saindo, e restaurar tudo na fase seguinte após carregar. Também temos que salvar e restaurar tudo vísivel ao jogador na área de transição, mesmo que fique fora do espaço em si. Por isso, sempre tentamos deixar o espaço de transição o menor e mais fechado possível. Na maior parte do jogo, uma sala pequena funciona bem, mas, na Costa, precisávamos de outra solução. Após alguns testes, fechamos com um túnel escuro. Além de ser reutilizável de uma forma natural, o túnel permite colocar um clarão no final para mascarar o fato de que não podemos renderizar o que está adiante do jogador, já que isso existe em uma fase totalmente diferente."
N/A3981"#commentary\cn_063_sniper_alley.mp3" "[ Robin Walker ] Esta parte do jogo entrou tarde, depois que trouxemos o Laboratório do Eli e Ravenholm para antes da Costa. Embora você possa pensar que criamos o jogo de forma linear, dividimos em três grupos e trabalhamos paralelamente em partes diferentes, começando principalmente no meio do jogo. A primeira fase de cada grupo serve para definir o cerne daquela área antes de seguirmos em frente. Depois, já com uma versão crua do jogo inteiro, voltamos a cada parte para dar polimento, incluindo elementos que deram certo em outras áreas e tirando o que não funcionou. Em alguns casos, como em Ravenholm, reposicionamos partes inteiras. Depois que Ravenholm foi realocada, precisávamos de uma parte nova que fizesse a conexão com a Costa, que é a área na qual você está entrando agora. Por conta das restrições de tempo, esta parte curta foi criada com elementos pré-existentes já testados, como Franco-atiradores e Soldados da Combine."
N/A3982"#commentary\cn_064_battery_finding.mp3" "[ Robin Walker ] Com o aumento da densidade de objetos em espaços de jogo de Half-Life 2, achamos que seria interessante fazer o jogador procurar um item específico, principalmente se houvesse alguma lógica quanto ao local onde seria encontrado. Assim, o jogador poderia localizar o item por dedução e observação cautelosa, ou então usar força bruta para vasculhar a área. Como já tínhamos modelos para carros e baterias, foi natural criar um pequeno ferro-velho para o jogador explorar. Também escondemos baterias extras em lugares inesperados para quem escolhesse o método da força bruta. Assim como outros enigmas focados em itens, este precisava de uma proteção contra falhas caso o jogador perdesse as baterias. Experimente jogar as baterias do penhasco para ver o que acontece."
N/A3983"#commentary\cn_065_boathouse.mp3" "[ Scott Dalton ] Em Half-Life 1, descobrimos que podíamos fazer bom proveito dos cenários onde inimigos de diferentes IAs lutam entre si. É divertido para o jogador vê-los interagirem, e é muito mais fácil de observar o comportamento do inimigo quando você não está sob ameaça. Projetamos o primeiro encontro entre formigas-leão e soldados da Combine como uma oportunidade divertida de atropelar alguma coisa com o buggy, mas também serve para destacar o Batedor. Ao ver os soldados usarem o Batedor para conter formigas-leão, queríamos que mais jogadores compreendessem seu propósito. Gostamos de como os soldados demonstravam a importância de ficar perto de um Batedor ao enfrentar formigas-leão."
N/A3984"#commentary\cn_066_buggy_theft.mp3" "[ Scott Dalton ] Quando criamos o final da Costa, decidimos fazer a Combine roubar o buggy do jogador. Isso não faz nenhum sentido lógico, mas, ao ver tantos testadores se apegarem ao buggy, quisemos brincar com esse vínculo emocional. Quando implementamos o roubo, alguns testadores gritaram com a Combine por roubar seu veículo, e interpretamos isso como sucesso. O soldado atirando do topo do penhasco serve apenas para atrair o olhar do jogador, ativando o alvo de visão e gerando o cargueiro com o buggy. Vendo isso agora, 20 anos depois, ficamos chocados com o nível de ridículo da cena."
N/A3985"#commentary\cn_067_snipers.mp3" "[ Ted Backman ] A equipe de Half-Life 2 nunca foi muito grande, então sempre buscávamos formas de inovar na jogabilidade sem aumentar custos. O Franco-atirador é um ótimo exemplo. Ele não tem modelo — é só um feixe de laser —, então não precisou de artistas nem de animadores. Quando morre, ele cria um boneco de Soldado da Combine e o arremessa pela janela. Apesar da simplicidade, ele trouxe muitos elementos únicos. Ficamos bem satisfeitos com a forma como ele interagia com objetos físicos. O jogador está acostumado a aproveitar objetos explosivos perto de inimigos, então pareceu justo ter um inimigo que invertesse essa dinâmica quando o jogador estava se escondendo."
N/A3986"#commentary\cn_068_buggy_model.mp3" "[ Ted Backman ] O modelo do buggy passou por muitas iterações antes de chegar à versão final. Testamos vários modelos que satisfaziam as nossas necessidades artísticas e de simulação de física, mas enfrentamos um problema inesperado: muitos testadores, inclusive jogadores experientes de FPS, ficavam enjoados ao dirigir. Além de ajustes na simulação, descobrimos que alterar o modelo do buggy ajudou. Quanto mais o modelo obscurecia o mundo, pior ficava o enjoo, então começamos a remover partes do buggy até os jogadores não ficarem enjoados. Uma coisa que fez uma diferença mais pronunciada foi poder ver o chão através dos vãos no chassi."
N/A3987"#commentary\cn_069_antlion_design.mp3" "[ Ted Backman ] Nos primórdios do desenvolvimento do jogo, tínhamos planos para várias raças alienígenas centrais, sendo a Combine apenas uma delas. Uma das outras raças era uma espécie de insetoides religiosos, e as formigas-leão eram parte dela. Depois, enquanto trabalhávamos na Costa, começamos a vê-los mais como pragas que vieram pelos portais de Xen, como chupa-crânios e outras criaturas. Embora não sejam de Xen, elas infestam os cantos de qualquer mundo em que entram — assim como baratas."
N/A3988"#commentary\cn_070_explosive_barrels.mp3" "[ Brian Jacobson ] Aqui, apresentamos os barris explosivos, um clássico dos FPS, mas com um detalhe: o segundo tiro de pistola põe fogo no barril, iniciando uma detonação cronometrada. O terceiro tiro detona o barril imediatamente. Assim, o jogador pode atrasar a explosão ou ativá-la na hora, dependendo da situação. O jogador pode dar um barril explosivo para uma craca comer e então atirar nele duas vezes como uma forma prática de se livrar de um grupo de cracas. A explosão atrasada também podia dar origem a reações em cadeia entre vários barris. Os fãs da série sempre amaram os barris explosivos, mas os projetistas também — estes frequentemente pensavam que sempre havia espaço para mais barris."
N/A3989"#commentary\cn_071_ragdoll_magnets.mp3" "[ Dario Casali ] A física de Half-Life 2 trouxe várias ferramentas que deixavam o combate mais animado. Por exemplo, quando o inimigo errava o jogador, a bala era redirecionada sutilmente a algum objeto quebrável próximo, criando caos e uma atmosfera de filme de ação. Também usamos a física para dar pistas. Criamos o que chamamos de \"ímãs de boneco\", que faziam os corpos dos inimigos caírem de formas dramáticas e interessantes, como de uma beirada elevada ou no caminho de um trem."
N/A3990"#commentary\cn_072_helicopter_peekaboo.mp3" "[ Dave Riller ] O helicóptero de ataque da Combine como antagonista central foi algo que quisemos desenvolver durante todo o capítulo. A aeronave implacável virou um personagem por si só. Aqui, se você escutar e olhar para cima, poderá ouvir seu motor e vê-lo sobrevoando os trilhos e ir para longe. Esse primeiro vislumbre é apenas um pequeno prenúncio, e sua presença vai ficando mais pronunciada ao longo do tempo, até que, alguma hora, vocês acabam se enfrentando."
N/A3991"#commentary\cn_073_iterative_passes.mp3" "[ David Speyrer ] Alguns capítulos do jogo, como as partes a pé dos Canais e de Ravenholm, foram desenvolvidos em vários ciclos, passando por diferentes equipes. Achamos que criar mapas assim levava a uma maior variedade de experiências e maior densidade de momentos interessantes, pois cada equipe dava seus próprios toques aos mapas. Na parte a pé dos Canais, o primeiro ciclo definiu a direção de arte e o caminho do jogador, bem como os traços gerais da experiência e os momentos mais importantes. Mas a testagem Alfa multidisciplinar identificou tensão insuficiente e uma experiência um tanto monótona aqui. No segundo ciclo, voltamos ao mapa com o único foco de criar tensão e aumentar bastante a densidade dos cenários momento a momento."
N/A3992"#commentary\cn_075_pistol_design.mp3" "[ Josh Weier ] A pistola padrão é o carro-chefe do jogo, funcionando não só como a primeira arma à distância que você aprende a usar, mas também como método para interagir com a física e com objetos quebráveis de uma distância segura por todo o jogo. Para ficar mais responsiva e divertida, ela emprega uma mecânica de tiros consecutivos que só ela tem no jogo. A arma atira tão rápido quanto o jogador consegue clicar no botão de ação, então ele sente uma resposta imediata a seu comando e, quanto mais rápido clicar, mais rápido vai atirar."
N/A3993"#commentary\cn_076_shatterglass.mp3" "[ Josh Weier ] Ao projetar as primeiras fases, onde o jogador ainda domina poucas mecânicas, achamos que seria interessante destacar novas funções técnicas, como fizemos aqui com o vidro quebrável. Para o efeito de estilhaçamento, o vidro foi dividido em uma grade de quadradinhos para sabermos quais estavam intactos ou quebrados, e podermos estourar pedaços maiores quando houvesse menos quadrados conectados. Cada quadrado era renderizado com uma textura única, dependendo do estado dos quadrados vizinhos, criando bordas afiadas e irregulares entre partes de vidro quebrado e intacto. Embora quebrar vidro seja básico nos jogos de hoje, não era algo muito comum quando estávamos fazendo Half-Life 2, e ficamos felicíssimos com o nível de fidelidade e dinamismo que esse recurso trouxe ao jogo."
N/A3994"#commentary\cn_077_lambda_caches.mp3" "[ Laura Dubuk ] Tecnicamente, o primeiro suprimento lambda fica no Laboratório do Kleiner, mas este é o primeiro que o jogador encontra sozinho. Colocamos suprimentos lambda para estimular a exploração e indicar onde há recursos. A história é que foi a Resistência que os colocou como parte de sua rebelião subterrânea. Em Half-Life 1, o conteúdo das caixas de suprimentos era predeterminado pelo projeto da fase. Em HL2, introduzimos caixas de item adaptativas que dão o recurso de que o jogador mais precisar no momento, com base nas metas de recurso determinadas pelo projetista de nível."
N/A3995"#commentary\cn_078_scanners.mp3" "[ Kerry Davis ] Vasculhadores traziam um desafio de design complicado. Embora gostássemos de como sua presença distópica ajudava a transmitir a ocupação da Combine como estado opressor vigilante, não queríamos que eles atirassem no jogador. Achamos que mirar no céu para atingir um alvo móvel pequeno com constante vantagem de altura não tinha como ser divertido. Como amávamos seu papel na história, decidimos que, em combate, os vasculhadores serviriam principalmente como olhos, alertando inimigos próximos da presença do jogador, e reforçamos essa função com efeitos sonoros dos soldados. Além disso, eles só seriam capazes de incomodar o jogador com luzes fortes ou, após receberem dano, mergulhando e explodindo."
N/A3996"#commentary\cn_079_surface_properties.mp3" "[ Ariel Diaz ] Reproduzimos sons específicos de passos quando o jogador anda na lama. Era um sistema chamado de \"propriedades de superfície\", que usava o material para determinar os sons e outros efeitos que ocorreriam o jogador andava ou atirava na superfície. No início do desenvolvimento, tínhamos um efeito que desacelerava o movimento em superfícies lamacentas, mas o removemos na versão final, pois decidimos que era muito cruel."
N/A3997"#commentary\cn_080_combat_entrances.mp3" "[ Dario Casali ] Dobrar uma esquina e encontrar inimigos parados numa área nova é sempre esquisito e deixa o mundo menos realista, e mais como uma sessão de tiro esportivo. Queríamos introduzir os inimigos no combate de formas mais interessantes e dinâmicas que transmitissem planejamento e intencionalidade por parte dos soldados, como se eles tivessem um plano para Gordon antes que ele chegasse. Os policiais nesta cena pulam na área por sequências roteirizadas e, posteriormente, chegam de rapel de forma semelhante. Não importa de onde eles de fato vêm porque o jogador acaba inventando uma justificativa na cabeça. Descobrimos que o combate deve ter uma história implícita na configuração: um emboscada, uma surpresa, um ataque... Todos esses cenários usam a mesma IA de inimigo, mas pareceram diferentes aos testadores."
N/A3998"#commentary\cn_081_mounted_gun_gallery.mp3" "[ Dave Riller ] Há algumas coisas ocorrendo nesta cena: a torreta atirando em caixas quebráveis lá atrás ensina o jogador a não enfrentar a ameaça diretamente, e sim usar a rota pelo esgoto para derrotá-la. Ao chegar na torreta, o jogador pode usá-la em um tiroteio com uma leva de soldados da Combine e vasculhadores explosivos. Também apresentamos o blindado lançador de mísseis da Combine, que força o jogador a seguir por um caminho e voltará a aparecer mais tarde no capítulo."
N/A3999"#commentary\cn_082_barnacle_bowling.mp3" "[ Josh Weier ] Eis um exemplo satisfatório de como vários elementos de design se mesclam numa matriz de interações para criar um cenário memorável para o jogador. Temos cracas, simulação de física, propriedades de superfície de lama escorregadia e os barris explosivos. Você já encontrou tudo isso separadamente, mas aqui eles se unem de forma natural para criar um momento que chamamos de \"boliche de cracas\"."
N/A4000"#commentary\cn_083_barnacle_introduction.mp3" "[ Mike Dussault ] Como as cracas podem ser confusas na primeira vez, queríamos apresentar seu comportamento ao jogador de uma distância segura. Optamos por usar uma cena de presa e predador, como num documentário de natureza, mas, como sempre, precisamos de muitos testes para garantir que o jogador assistia essa cena."
N/A4001"#commentary\cn_084_physics_in_puzzles.mp3" "[ Eric Smith ] Não raro, mecânicas simples do início do jogo vêm de mecânicas mais complexas como forma de treino. O quebra-cabeça da gangorra, a primeira engenhoca de simulação física no jogo, vem de um quebra-cabeça posterior mais complicado com máquina de lavar que aparece nos Canais. A gangorra usa os mesmos princípios de massa e rampas, mas de forma mais clara, e o jogador pode interagir diretamente. Isso o ajuda a entender a física do jogo e facilita os quebra-cabeças futuros. Este quebra-cabeça também destaca a natureza analógica do sistema de física, já que a colocação dos blocos de concreto e o próprio peso do jogador fazem parte da solução."
N/A4002"#commentary\cn_085_combine_attack_helicopter.mp3" "[ Brian Jacobson ] O jogador já teve um vislumbre antes, mas é aqui que apresentamos o chefe principal do capítulo dos Canais: o helicóptero de ataque da Combine. Ele fica destruindo as coberturas do jogador sem cessar, obrigando-o a avançar para não levar tiro. Queríamos que essa cena parecesse tensa e ameaçadora, que o helicóptero parecesse forte demais para ser confrontado diretamente, e que essa intensidade perdurasse pelos Canais até o confronto final no reservatório. Para isso, restringimos bastante o movimento do helicóptero com base nos objetivos de jogo. Neste mapa, projetado para o jogador correr de cobertura em cobertura sob tiro do helicóptero, criamos um caminho em anel no céu acima da arena. O helicóptero sempre viaja até o ponto no anel mais longe do jogador, mantendo-o visível, e isso facilitou o posicionamento de cobertura nos lugares certos para nós."
N/A4003"#commentary\cn_087_explosive_barrel_factory.mp3" "[ David Speyrer ] Este cômodo, repleto com um número absurdo de barris explosivos, inspirou debates bem-humorados na equipe quanto aos limites da plausibilidade em nosso mundo. Sendo franco, um barril explosivo já é demais em termos de realismo. No mundo real, barris não explodem, mesmo que você atire neles."
N/A4004"#commentary\cn_088_rising_water.mp3" "[ Dhabih Eng ] As bobinas de madeira e a ponte flutuante apresentam o conceito de flutuabilidade como ferramenta. Neste caso, não é um quebra-cabeça de fato, só algo divertido para o jogador interagir com o sistema de física. Depois, revisitamos esse elemento de jogo nos Canais para erguer uma rampa para um aerobarco.
N/A4005"
N/A4006"#commentary\cn_089_manhack_matt.mp3" "[ John Morello ] Chamamos esse cara de \"Matt Cortador\". Queríamos transmitir a sensação de que havia centenas de cidadãos vivendo nos cantinhos da Cidade 17. Neste ponto do jogo, fazia tempo que o jogador não via um cidadão e queríamos explicar a importância dos cortadores, que foi o primeiro inimigo baseado em física que criamos. No conceito original, havia um fliperama na cidade, e o jogador controlava cortadores para atacar cidadãos virtuais. Posteriormente, o jogador descobriria que os cortadores eram de verdade, atacando cidadãos de verdade. Conforme a ocupação da Combine foi se desenvolvendo, essa ideia de fliperama pareceu não se encaixar e acabou sendo abandonada."
N/A4007"#commentary\cn_090_fighting_motion_sickness.mp3" "[ David Speyrer ] No começo dos testes, muitos jogadores sentiram enjoo ao pilotar o aerobarco. Enquanto tentávamos corrigir isso, descobrimos vários fatores que contribuíam. Por exemplo, reduzir a intrusão do aerobarco na visão ajudava, então fizemos vários testes com o modelo para reduzi-lo. Manter uma taxa de quadros constante também ajudava, então era importante ficar de olho no desempenho. No entanto, o fator mais importante foi eliminar o rolamento de câmera para manter o horizonte mais estável, independentemente do movimento do aerobarco. Um dos programadores da equipe era muito suscetível a enjoo e teve a coragem de se oferecer para fazer vários testes e avaliar nosso progresso. Tenho certeza que ele vomitou pelo menos uma vez depois de um teste, e ficamos muito gratos por seu nobre sacrifício."
N/A4008"#commentary\cn_091_headcrab_canisters.mp3" "[ Jeff Lane ] Cápsulas de chupa-crânio usadas são vistas depois em Ravenholm, então decidimos mostrá-los aqui para contar como são usados pela Combine. A história é que a Combine transformou a fauna xen em armas contra os humanos. Chupa-crânios enterrados foram incluídos como novo recurso nesta parte, que foi expandida em uma área maior com o objetivo de mostrar uma comunidade que foi dizimada por um ataque de chupa-crânios."
N/A4009"#commentary\cn_092_airboat_intro.mp3" "[ John Morello ] É aqui que o jogador pega o primeiro veículo do jogo: o aerobarco. Queríamos criar um local seguro para o jogador praticar a pilotagem do aerobarco o tempo que desejasse antes de prosseguir. A arena é repleta de oportunidades de salto e manobra. Também a enchemos com gosma tóxica para o jogador usar o aerobarco por mais tempo, já que o impedimos de deixar o veículo para trás e seguir a pé."
N/A4010"#commentary\cn_093_zombie_surprise.mp3" "[ Jeff Lane ] Tem uma cena de susto marota aqui neste cano de esgoto. O jogador entra, focado e curioso, e aí pula um zumbi de dentro d'água, quase sempre assustando o jogador. Teve um que chegou a cair da cadeira, e marcamos aquele momento como um sucesso."
N/A4011"#commentary\cn_094_airboat_time.mp3" "[ Dave Riller ] Encontrar o equilíbrio entre tempo a pé e em veículo deu trabalho. Pilotar na velocidade máxima permitia avançar rápido pelo mundo e, nos primeiros testes, sentimos que o jogador não estava explorando nem absorvendo o mundo a contento. Examinar o mundo e explorar são valores centrais de Half-Life, então não queríamos que o veículo eliminasse isso. Assim, criamos pontos periódicos onde o jogador pudesse sair e explorar pequenos bolsões de detalhes. Além disso, conforme o sistema de física evoluía, aprendíamos novas formas de usá-lo. Esses locais fora do aerobarco serviam para apresentar um elemento de descoberta da física, como jogar caixas na água, ou combinar barris para fazer uma rampa subir. Isso deu ao jogador a chance de interagir com a água e com a física de formas diferentes."
N/A4012"#commentary\cn_095_floating_supplies.mp3" "[ Josh Weier ] Na testagem alfa, os Canais estavam cheios de caixas de suprimentos boiando para o jogador quebrar com o aerobarco e coletar o conteúdo. A mecânica era um tanto artificial, mas ajudava a manter o fluxo do jogo, reabastecendo o jogador no caminho. Para ajudar a deixar a premissa mais plausível, queríamos contar a história de como as caixas flutuantes foram parar de forma tão conveniente no caminho do jogador. Esta cena de cidadãos jogando caixas de suprimentos ajuda a vender essa ficção, enquanto também dá mais vida aos canais. Ela também faz o jogador se sentir mais heroico e importante, já que tantos coadjuvantes o ajudam."
N/A4013"#commentary\cn_096_grenade_intro.mp3" "[ Brian Jacobson ] Concebemos esta base da Combine como área de treino e parquinho para granadas, apresentando-as aqui com caixas de suprimento infinito para indicar que é seguro usá-las à vontade, sem medo de acabarem. Pode ir à loucura. O combate aqui usa muitas marcações que direcionam a IA dos soldados para coberturas, fornecendo boas oportunidades para o jogador usar as granadas. No final da área, a mesma técnica de granadas infinitas ajuda o jogador a resolver o posicionamento da torreta, pois, sem isso, o ataque direto fica bem mais difícil. Incluímos uma luz vermelha brilhante e um rastro de partículas na granada para sua trajetória ficar mais fácil de seguir, esteja o jogador a lançando ou se desviando da granada de um soldado da Combine."
N/A4014"#commentary\cn_097_puzzle_layers.mp3" "[ Dave Riller ] Como o jogador costuma não ter ideia da intenção do projetista — o que julgamos ser bom —, ele tende a responder de formas variadas e surpreendentes aos nossos enigmas. Até os aparentemente simples podem trazer vários fracassos no caminho até o sucesso. Foi o caso com este enigma para abrir o portão do canal, que precisou de muitas dicas. A manivela em curto comunica que ali é onde se abre o portão normalmente, mas que outro método se faz necessário. Alguns corvos guiam o olhar do jogador até a solução: neste caso, um conjunto de vigas em um pêndulo. Como o jogador já conhece bem as granadas, a ideia original era lançar uma granada para quebrar a estrutura de madeira, mas isso não era óbvio, então botamos barris explosivos, que são uma pista bem mais clara. Mesmo após resolverem o enigma, alguns jogadores não perceberam que o portão estava aberto, então ficaram explorando o interior da base um tempão, procurando outra saída. Tivemos que lembrá-los do problema original: o portão quebrado. Incluímos fumaça, a sirene de alarme e uma luz giratória, e foi então que finalmente começamos a ver resultados positivos consistentes nos testes."
N/A4015"#commentary\cn_098_metrocop_strafing.mp3" "[ Doug Wood ] O design inicial das fases com o aerobarco tinha como meta desafiar o jogador com manobras precisas sob a pressão dos policiais. O padrão de tiro dos policiais tinha a intenção de fazer o jogador ziguezaguear para não ser atingido enquanto avançava. Mas, no processo de revisão, chamado internamente de \"Vigilância\", alguns testadores ficaram frustrados por levarem tiro e não terem como revidar. Eles queriam que o aerobarco fosse forte e imparável. Com base nisso, adaptamos as fases para enfatizar força em vez de desafio, passando de desviar de ataques a um combate rápido, foco em velocidade e quebra de barreiras."
N/A4016"#commentary\cn_100_mounted_gun.mp3" "[ Jeff Lane ] Colocamos as armas fixas aqui para ensinar ao jogador sua eficácia contra o Helicóptero de Ataque na batalha final no reservatório. Isso foi necessário porque, até aqui, o helicóptero era invulnerável às armas do jogador e tínhamos que indicar que ele podia ser danificado com armamento mais pesado. O método teve apenas alguma eficácia durante os testes por conta da pressão que o jogador estava sofrendo no momento. Por isso, desenvolvemos sons e efeitos de partículas que indicavam ao jogador que ele estava causando dano."
N/A4017"#commentary\cn_101_357_intro.mp3" "[ Josh Weier ] A Magnum, por ter uma cadência de tiro mais baixa que a da pistola básica, foi feita para atirar de forma mais comedida e calculada, causando dano catastrófico ao alvo. As primeiras versões da Magnum tinham uma dispersão mais aleatória, o que achávamos condizente com o peso e o gatilho menos sensível de uma pistola maior. Contudo, isso levava a momentos anticlimáticos em que o jogador alinhava o tiro meticulosamente, mas errava por conta da penalidade de precisão. Assim, fizemos a primeira bala ter precisão perfeita e os tiros subsequentes serem menos precisos."
N/A4018"#commentary\cn_102_helicopter_bombing_run.mp3" "[ Brian Jacobson ] Eis outro exemplo em que criamos riscos de movimento enquanto o jogador pilota o aerobarco. O helicóptero tenta ficar na frente, lançando bombas e, se o jogador recuar, ele passa a pairar e atirar. Em um teste, calhou de uma bomba cair entre as juntas da tubulação, criando um momento cinematográfico. O testador teve uma reação positiva, então a equipe decidiu fazer isso acontecer sempre. Isso tornou-se parte do nosso processo de design orgânico: com frequência, se uma coisa legal acontece por acaso, damos um jeito de fazê-la acontecer de forma mais garantida."
N/A4019"#commentary\cn_103_smokestack_collapse.mp3" "[ Doug Wood ] Ao criar um jogo de ação cinematográfico como o primeiro Half-Life, sempre quisemos fazer sequências de destruição espetaculares e grandiosas, mas nunca conseguimos. A física de Half-Life 2 introduziu um sistema para quebrar em pedaços objetos físicos pequenos, como caixas, e isso nos deu vontade de fazer algo bem maior. Foi então que tentamos quebrar uma chaminé em pedacinhos enquanto ela caía. Experimentamos com as massas até parecer melhor, refinamos o modelo, botamos muita fumaça e áudio para vender o efeito e pronto, lá estava nosso momento de destruição espetacular e grandioso. No fim, nossa física tornou a sequência minimamente possível e, embora parecesse estranha pros padrões atuais, foi incrível pra época. Como a simulação era diferente a cada vez que rodávamos, tivemos que tomar alguns cuidados para não bloquear o caminho do jogador completamente com pedações de destroços. O sucesso dessa sequência atiçou nosso apetite para os efeitos de destruição física cinematográfica de maior fidelidade que vemos no Episódio Dois."
N/A4020"#commentary\cn_104_washing_machine_puzzle.mp3" "[ David Speyrer ] Criamos o quebra-cabeça de física com a máquina de lavar bem tarde, depois que os testes indicaram que o jogador precisava descansar um pouco da pressão implacável do helicóptero. Contrastes de ritmo como este acentuam os pontos altos, pois limpam o estado emocional do jogador, evitando exaustão e tédio. A reação forte dos jogadores foi um sinal positivo de todo o trabalho para deixar o helicóptero ameaçador, mas, se não gerenciarmos o nível de estresse, podemos causar fadiga, que logo deixa a experiência monótona em vez de empolgante. Originalmente, o jogador passava rápido por esta área, mas, por conta do sol e da composição do canal, decidimos que seria um bom lugar para pausar a ação e dar um descanso para o jogador resolver um enigma. O quebra-cabeça em si, que foi o primeiro a usar pesos e polias, acabou dando origem a outros enigmas de navegação com física no jogo."
N/A4021"#commentary\cn_105_airboat_changeup.mp3" "[ Jeff Lane ] Os testadores nos contaram que queriam mais variedade de jogo com o aerobarco. Até aqui, o jogador não teve como revidar contra o helicóptero e outros inimigos, então pareceu certo apresentar uma arma nova que traria uma mudança de ritmo e armaria o palco para o que viria em breve. Nas áreas seguintes, botamos um treino de tiro ao alvo para o jogador se familiarizar com a arma nova. Força física extra nos projéteis da arma de ar fazia os alvos voarem longe e a arma parecer a coisa mais forte que o jogador tem à disposição. Mas, quando testamos o combate contra o helicóptero, muitos testadores ainda pensavam que ele era invencível. Eles não haviam notado nossos esforços de ilustrar que o helicóptero estava recebendo dano das armas fixas da Combine. Para superar esse problema, fizemos o óbvio: colocamos o helicóptero diretamente fora do túnel em que você pega a arma e deixamos bastante claro que você pode e deve atirar nele. E deu certo."
N/A4022"#commentary\cn_106_donkey_kong_barrel_ramp.mp3" "[ Eric Smith ] Esta área, a rampa da galeria de águas, começou apenas como um caso interessante de arquitetura de fase. Durante os testes, vimos como seria divertido passar com o aerobarco pela rampa, então colocamos mais elementos para aprimorar a experiência, o que incluiu policiais jogando barris no jogador — um aceno sutil ao clássico dos arcades, Donkey Kong."
N/A4023"#commentary\cn_107_lambda_cache_interlude.mp3" "[ Danika Rogers ] Os jogos Half-Life são, em última instância, uma experiência linear, mas sempre buscamos formas de tirar o jogador do caminho e criar uma não linearidade. Este suprimento lambda, substituído por uma emboscada com um zumbi e chupa-crânios, era totalmente opcional, criado apenas para trazer não linearidade a esta parte da travessia dos canais."
N/A4024"#commentary\cn_108_skybox_time_of_day.mp3" "[ Eric Kirchmer ] As cores da névoa e do céu mudam gradualmente neste capítulo. A ideia é representar visualmente a passagem do tempo enquanto o jogador trafega pelos canais e pelo capítulo. Dois valores de cor de névoa em direções opostas ajudam a vender a ilusão do ângulo oblíquo do sol. Neste ponto, dá para notar ele ficando mais perto de se pôr. Isso culmina com a arena de combate contra o helicóptero, com o sol se pondo e Ravenholm visíveis no céu."
N/A4025"#commentary\cn_109_helicopter_megabomb_origin.mp3" "[ Brian Jacobson ] O superbombardeio do helicóptero começou como um erro causado quando um programador removeu o tempo de recarga da bomba. O resultado foi o helicóptero lançar centenas de bombas de uma vez. Ficou tão legal que decidimos manter no bombardeio da versão lançada."
N/A4026"#commentary\cn_110_helicopter_final_battle.mp3" "[ Dave Riller ] Projetamos esta área como a arena do confronto final entre o jogador e o helicóptero da Combine. É quando o jogador pode finalmente eliminar esse inimigo implacável que está atrás dele desde que saiu do laboratório do Kleiner. Esta área passou por muitas repetições até acertarmos. Precisava ter um espaço amplo para um combate contra um veículo rápido, um fluxo suave de movimento com opções de caminho claras, e um desempenho confiável. Também almejávamos uma clareza visual adequada para um combate — marcante, mas não muito poluída —, ainda garantindo que serviria como vista memorável depois da destruição do helicóptero."
N/A4027"#commentary\cn_111_airboat_wreckage.mp3" "[ David Speyrer ] Originalmente, o aerobarco era destruído no salto sobre a represa, então esta fase começava com o jogador em meio aos destroços de seu amado aerobarco. Em testes com toda a equipe, as pessoas ficaram decepcionadas de perder o veículo no qual haviam passado tanto tempo. Houve um debate interno para decidir se esse luto era válido. Por fim, decidimos manter o aerobarco intacto para deixar margem pra possibilidade de o jogador se reunir a ele algum dia. Dizem que o aerobarco ainda está esperando por você em algum lugar por aí."
N/A4028"#commentary\cn_112_arena_exit_gate.mp3" "[ Quintin Doroquez ] O mecanismo de manivela para erguer o portão de saída foi incluído apenas para obrigar o jogador a derrotar o helicóptero antes de avançar. Costumamos chamar esses elementos de \"gating\", ou \"portão\", que impede o jogador de prosseguir antes de realizar uma tarefa necessária. Aqui, é literalmente um portão."
N/A4029"#commentary\cn_113_blocking_tutorials.mp3" "[ Adrian Finol ] Às vezes, precisamos ter certeza de que o jogador aprendeu algo, e o método padrão — pelo menos em desenvolvimento de jogos, não na vida real — é prendê-lo atrás de algum portão e obrigá-lo a demonstrar seu conhecimento para continuar. Tentamos disfarçar esses portões como algo natural para não parecer que o jogo empacou. Claro que tempo, recursos e o próprio contexto do ambiente podem dificultar essa parte. Neste caso, precisamos ensinar o jogador a mover objetos, então um simples enigma de empilhar parecia a melhor solução. Testamos ideias complexas, mas acabaram sendo menos eficazes na hora de ensinar o que de fato o jogador precisava aprender."
N/A4030"#commentary\cn_114_natural_storytelling.mp3" "[ Bill Van Buren ] Para atingir nossos objetivos de construção de mundo e narrativa na Estação de Trem, precisávamos de uma forma natural de transmitir o diálogo que não parecesse jogo nem tutorial. Notamos que os jogadores costumavam se aproximar de PNJs para vê-los de perto, então aproveitamos essa oportunidade para que os PNJs reconhecessem o jogador e dissessem suas falas. Assim, as interações ficavam discretas, o que é essencial, pois os cidadãos não são exatamente felizes e animados. A simplicidade dessa abordagem também se alinhou a um dos principais objetivos narrativos de Half-Life: ter uma narrativa ajustável ao interesse do jogador. Alguns vão querer explorar cada detalhe, enquanto outros só querem saber o próximo objetivo. Dar controle ao jogador sobre o volume de história com que interagem – sem bloquear o progresso – é algo que sempre tentamos manter em jogos Half-Life. Além disso, quanto menos complicado for implementar uma função, mais instâncias podemos incluir."
N/A4031"#commentary\cn_115_trainstation.mp3" "[ Charlie Brown ] O começo de um jogo Half-Life tem uma grande tarefa: apresentar os jogadores a um mundo novo enquanto ensinamos a interagirem com ele. Eles precisam entender rápido o que está acontecendo, quem são os personagens principais, que ameaças enfrentarão e como se encaixam em tudo isso. Acima de tudo, tem que ser o mais interativo e divertido possível. Acertar nesse ponto demanda muitos testes e repetições, principalmente pelos momentos pequenos que compõem o panorama do jogo. Nesta parte, destacamos alguns momentos importantes, problemas de design e alguns testes que não saíram como o planejado."
N/A4032"#commentary\cn_116_physics_objects.mp3" "[ David Sawyer ] Pode ser difícil lembrar agora, mas, quando Half-Life 2 foi lançado, objetos pequenos no jogo, como esses lixos, no geral eram estáticos. Não se mexiam mesmo, ou caso se mexessem, era de um jeito bem simples. Com sorte, eles quebravam em sprites se você os acertasse. Um dos objetivos iniciais da parte da Estação de Trem era deixar claro ao jogador que esse tipo de objeto estava sendo simulado de uma forma fisicamente correta em Half-Life 2. Eles podiam ser pegos, largados, arremessados, movidos por outras forças – o que você pensar. Aqui, começamos com algo pequeno, mostrando que o lixo é empurrado pela chegada do trem – ou, mais especificamente, um volume invisível que é ativado quando o jogador desembarca."
N/A4033"#commentary\cn_117_blocking_tutorials_3.mp3" "[ Eric Smith ] O segundo fracasso neste tutorial é um caso em que sem querer ensinamos ao jogador algo que não queríamos. Pode ser difícil evitar esse tipo de coisa sem testes extensos, já que o jogo está sempre ensinando, mesmo quando não há intenção. Cobrimos um exemplo mais extremo adiante na Estação de Trem. Corrigir alguns casos é crítico, tipo se o jogador aprender a forma errada de usar uma arma ou interagir com um elemento comum do jogo. Mas este caso é mais sutil. Enquanto ensinamos a mover objetos, também ensinamos a empilhar objetos físicos para fugir de um local. Normalmente, não tem problema, mas não usamos essa mecânica em outro momento do jogo, e ensinar algo irrelevante só serve para sobrecarregar o jogador com ferramentas mentais, dificultando o acesso às coisas úteis depois. Pior ainda, empilhar objetos para fugir de um local tornou-se um problema, algo que tivemos que impedir ativamente em várias áreas. Com tantos objetos físicos no jogo, bloquear esse comportamento sem pôr teto por toda parte não era uma opção. No fim, torcemos para que o jogador não pensasse demais nessa lição inicial. Quando os testes mostraram jogadores empacando em outras partes, fizemos questão de não resgatar essa mecânica."
N/A4034"#commentary\cn_118_welcome.mp3" "[ Gabe Newell ] Meu nome é Gabe Newell, e bem-vindos de volta a Half-Life 2. Já se passaram longos vinte anos desde seu lançamento. Nesta atualização de aniversário, tentamos responder ao maior número possível de solicitações da comunidade. Embora possa não ser o pedido número um dos fãs, sempre ouço como as pessoas gostariam de um modo de comentários, então estamos empolgados em finalmente fazer acontecer. Não só foi um desafio lembrar muitos detalhes do desenvolvimento de Half-Life 2, mas também não é fácil decifrar programação com duas décadas e se perguntar em que diabos você estava pensando naquela época. Junto com os comentários do desenvolvedor, resolvemos vários bugs antigos e tentamos deixar as coisas em um estado melhor do que encontramos. Pelo menos desta vez, temos o luxo de saber como as coisas saíram. Para ouvir uma seção de comentários, coloque a mira no símbolo de comentário flutuante e pressione a tecla de Usar. Para parar um comentário, coloque a mira no balão girando e pressione a tecla de Usar novamente. E eu quero saber o que você achou. Entre em contato comigo por gaben@valvesoftware.com. Obrigado e divirta-se!"
N/A4035"#commentary\cn_119_metrocop_shoving_citizens.mp3" "[ Josh Weier ] Demos poucos passos e já temos problemas a resolver. Apresentamos o policial municipal, um inimigo que depois vamos pedir que o jogador mate, e damos um vislumbre do mundo no qual o jogador está entrando. É um momento claro e simples que mostra a relação entre os policiais e os civis e, por extensão, o jogador. Ao mesmo tempo, decidimos reforçar a existência da essência da simulação de física e mostrar de que formas os PNJs interagem casualmente com objetos no mundo. Ver algo como uma maleta batendo em outra era uma grande novidade na época. Esses momentos na Estação de Trem, em que combinamos vários objetivos, foram os de maior sucesso. Eles pareceram naturais, como se o jogo não estivesse pausando para ensinar alguma coisa."
N/A4036"#commentary\cn_120_fall_damage.mp3" "[ Kerry Davis ] Ensinar o jogador a fazer certas coisas é essencial em qualquer jogo. Para tomar decisões com confiança, o jogador precisa entender as regras mais sutis. Este momento cobre duas dessas regras: ele mostra até que ponto o jogador pode cair sem sofrer dano, e introduz parte do vocabulário do jogo — a forma como o jogo se comunica. O jogador costuma se preocupar com dano de queda, mas também com passos que parecem irreversíveis, então aqui há uma caixa de pouso acolhedora indicando que cair é seguro e que é o caminho a seguir. Quando essa caixa quebra, reforça a simulação de física. Também é provavelmente a primeira vez que o jogador vê que objetos grandes quebram em objetos menores."
N/A4037"#commentary\cn_121_sweeping_vortigaunt.mp3" "[Laura Dubuk] Outro momento importante da narrativa e outro aceno ao sistema de física. Estamos mostrando como os vortiléticos se encaixam nesse mundo novo, e é uma grande mudança de seu papel como inimigos em Half-Life 1. Como em muitos momentos na Estação de Trem, o vortilético varrendo veio de nossa busca constante por formas de mostrar personagens interagindo naturalmente com o sistema de física. Por que esfregar na cara que os vortiléticos ficaram amistosos quando se pode mostrar um deles varrendo o chão casualmente e derrubando objetos simulados? Nada grita mais \"Não atira em mim!\" que alguém limpando."
N/A4038"#commentary\cn_122_blocking_tutorials_2.mp3" "[ Robin Walker ] Há dois fracassos dignos de nota neste tutorial. Primeiro, o jogador pode arruiná-lo jogando as caixas pela janela, o que obviamente não é bom. Eles ficam presos, impedidos de prosseguir, e isso é um erro crítico a ser corrigido. Uma solução elegante seria ajustar a janela ou o tamanho das caixas para que o jogador pudesse passar, mas não as caixas. O problema foi que só percebemos bem tarde no processo de desenvolvimento, e até uma alteração simples poderia ter consequências imprevisíveis ou até quebrar o jogo — pertinho do lançamento, ainda por cima. Fora que esse problema era puramente teórico. Nenhum testador tinha feito isso de fato. Os testes deste local correram muito bem, com os jogadores aprendendo o necessário antes de continuar. Mudar o projeto da sala tão tarde poderia ter atrapalhado esse sucesso de formas imprevisíveis. Então optamos por uma correção mais conservadora em vez de algo elegante. Se tiver curiosidade, tente jogar todas as caixas pela janela e veja o que acontece."
N/A4039"#commentary\cn_123_playground.mp3" "[ Brian Jacobson ] Quando discutimos formas de destacar nossa simulação de física no ambiente urbano, um parquinho pareceu um candidato natural. Pro jogador atento ao Dr. Breen, também serve de lembrete do preço da rendição humana à Combine. Escolhemos alguns brinquedos de parquinho com potencial físico interessante e começamos a afinar. Mesmo com a simulação física avançada da época, configurações como essa exigiam ajustes manuais, pois tínhamos objetos totalmente simulados interagindo com objetos parcialmente ou não simulados, tais como o jogador ou a geometria do mundo estático. É fácil presumir que uma simulação carrega bastante da carga da implementação, mas até hoje, vinte anos depois, raramente é o caso. Quando trabalhamos no parquinho, mais pro final do desenvolvimento do jogo, não conseguimos deixar o atrito natural no escorregador, então decidimos quebrar a escada para o jogador não poder subir. No entanto, ainda é possível subir andando pela frente. Como de costume, você, jogador, é quem ri por último."
N/A4040"#commentary\cn_124_pick_up_that_can.mp3" "[ Charlie Brown ] Contextualizar tutoriais — criar um cenário em que eles ocorrem — permite mais que apenas parar o jogo para ensinar algo ao jogador. É uma chance de incluir valor narrativo no momento. Aqui, ensinar o jogador a arremessar objetos se combina com uma configuração narrativa que dá opções de como reagir. Depois que o jogador observou os policiais maltratarem civis casualmente, parece certo colocá-lo em uma posição semelhante. Caso ele tenha uma opinião sobre como os civis deviam ter reagido, agora ele podem se expressar. Os testes mostraram que a maioria dos jogadores ou obedecia ou recusava o pedido de pegar a lata, mas alguns tentavam evitar o confronto. Outros obedeciam de início, mas retaliavam ao se sentirem humilhados. Ao restringir relativamente o momento, tanto no tocante às ações do jogador quanto ao próprio espaço físico, pudemos criar respostas adequadas a qualquer decisão do jogador."
N/A4041"#commentary\cn_125_promises.mp3" "[ Danika Rogers ] No início de Half-Life, um de nossos objetivos era fazer promessas ao jogador, dando uma sensação do que esperar no futuro. Sejam filmes, séries ou livros, todo bom entretenimento faz isso de um jeito ou de outro, e videogames não são exceção. As promessas em um jogo Half-Life assumem formas diferentes. Algumas são simples, como oferecer um vislumbre de algo intrigante. Outras têm mais camadas, como as interações com os policiais. Pondo o jogador em uma posição de desamparo contra eles, armamos o palco para o momento futuro em que ele passa a poder revidar."
N/A4042"#commentary\cn_126_exploration.mp3" "[ David Sawyer ] Depois que o jogador é arrebanhado pela Estação de Trem por policiais, queríamos que ele tivesse a chance de explorar. Esta praça oferece várias formas de interagir com civis, policiais, vasculhadores e a infraestrutura da cidade. A meta era que essas interações continuassem a construir o mundo sem a necessidade de tutoriais explícitos, e as refinamos até que fluíssem naturalmente, sem treinamento."
N/A4043"#commentary\cn_127_early_game_exploration.mp3" "[ David Speyrer ] Até esta praça, o jogador dificilmente pensou muito em sua rota, pois ela sempre foi clara e direta. Mas aqui queríamos encorajar a exploração, o que significava deixar o caminho menos óbvio, e isso pode fazer o jogador se sentir perdido ou, pior ainda, confuso, como esperado. Mudanças como essa são difíceis, principalmente se for cedo no jogo, quando o jogador ainda está aprendendo quais dicas servem de guia. Aqui, é ainda mais complicado por ter pontos de controle com \"campo de força\", permitindo que PNJs passem, mas que restringem o jogador, fazendo muitos testadores acreditarem que havia uma forma de passar por eles. Por fim, foram muitos testes que ajudaram a encontrar a visibilidade certa para o beco que levaria adiante, usando iluminação, disposição e uma caixa de madeira — objeto que o jogador já identificou como sinal de que está na direção certa —, todos guias sutis de como avançar."
N/A4044"#commentary\cn_128_strider.mp3" "[ Doug Wood ] Este momento simples é uma promessa de que você enfrentará aquela coisa enorme mais tarde no jogo. Até uma cena modesta como esta requer bastante teste e repetição porque o objetivo de Half-Life é não tirar o controle do jogador. Como você pode imaginar, são necessários vários pequenos ajustes para que o máximo possível de jogadores olhem para o lugar certo na hora certa. A disposição da rua e a cena com os policiais foram pensadas para guiar o olhar do jogador, criando uma moldura perfeita para o Trípode quando ele aparece."
N/A4045"#commentary\cn_129_physics_simulation.mp3" "[ Jay Stelly ] Embora tenhamos começado Half-Life 2 com uma simulação de física funcional de terceiros, levou anos de trabalho extra tanto na própria simulação quanto em sua integração ao jogo até sentirmos que atendia às ambições de nossos projetistas. Sabíamos que manter um nível de qualidade e desempenho publicável seria um desafio, mas um problema mais sutil foi pensar no que simular, e até que ponto. Não podemos simular tudo e, mesmo que pudéssemos, há motivos para a experiência ser melhor quando não simulamos. Em muitos casos, distorcemos a simulação deliberadamente para melhorar a experiência do jogador. Esses ajustes costumam passar despercebidos porque se alinham às expectativas do jogador. Por exemplo, desativamos colisões entre o jogador e objetos grandes para ele poder fazer curvas em espaços apertados. Também ajustamos o tiro secundário do fuzil da Combine para guiar sutilmente a bola da Combine na direção dos inimigos, deixando-a mais eficaz."
N/A4046"#commentary\cn_130_physics_simulation_2.mp3" "[ Jeff Lane ] Áreas onde o design de jogo e outras limitações tinham um impacto na simulação física exigiam afinamento extra para impedir que a simulação explodisse. Como exemplo, no início experimentamos um aumento da simulação da entidade do jogador, ou seja, o movimento do jogador fazia muito mais parte da simulação física do jogo. Sabíamos que esse movimento seria menos preciso, mas esperávamos que traria experiências novas. No entanto, após afinar o movimento para combinar menos com a versão simulada, encontramos um problemão: a força física necessária para o jogador se movimentar na velocidade normal era tão alta que trombar com outros objetos simulados podiam resultar em morte por impacto. Repetimos testes, mas por fim não encontramos uma solução satisfatória e revertemos para o movimento menos simulado. Contudo, esse caminho não foi exatamente o mais fácil. Ele trouxe novos desafios quanto à forma como o jogador menos simulado interagia com os objetos mais simulados no jogo, mas isso permitiu que entregássemos a experiência de movimento preciso que queríamos."
N/A4047"#commentary\cn_131_playtesting.mp3" "[ John Morello ] Os testes são uma parte essencial de como criamos jogos. Jamais poderemos prever todas as respostas possíveis do jogador, nem como eles receberão o que construímos. Então testamos para tentar melhorar. Durante um teste, não guiamos nem falamos com o jogador, mesmo que fiquem empacados, já que é bem improvável que estejamos ao lado dele depois que o jogo for lançado. Nosso objetivo é que os testadores esqueçam que estão testando e joguem como se estivessem em casa. Toda interrupção traz o risco de enviesar os dados, então só agimos se houver um erro que bloqueie o progresso ou, mais raramente, se o comportamento for confuso a ponto de não entendermos o que estão pensando."
N/A4048"#commentary\cn_132_playtesting_anecdote_1.mp3" "[ Matt Boone ] Um momento memorável nos testes lembrou que nunca podemos ter certeza do que o jogador está pensando, ou de que lição ele levou da experiência. Um testador, após jogar do começo e empacar para abrir uma porta, passou minutos alternando entre o jogo e as Configurações do Teclado. Quando perguntamos o que estava procurando, ele disse que queria saber os controles do inventário, achando que poderia usar um item que havia pegado para abrir a porta. Embora tenhamos visto ele pegar e largar vários objetos, ele não entendeu o que estava acontecendo. O testador acreditou que apertar o botão Usar ao segurar um objeto colocava o item no inventário porque o objeto caía direto para baixo. Sabíamos que era só gravidade, mas não foi uma suposição insana, já que alguns jogos de aventura daquela era guardavam itens em inventários invisíveis daquela forma. Explicamos que não havia inventário e o teste continuou. Depois, ponderamos se deveríamos tratar do problema, mas, como nenhum outro testador se confundiu da mesma forma e todas as potenciais soluções pesavam mais na mão que o necessário, decidimos que era um caso isolado e que não precisava de solução. Mas serviu como lembrete de que até os detalhes mais sutis e imperceptíveis podem desorientar o jogador."
N/A4049"#commentary\cn_133_cratebaby.mp3" "[ Scott Dalton ] Esta bonequinha tem um grande legado. Durante os muitos meses de testes internos, parte da equipe a transformou num desafio como forma de deixar mais divertida a 47ª vez jogando o jogo. Colocaram a boneca num caixote azul que havia ali para ver até que ponto do jogo conseguiriam levá-la. Depois que Half-Life 2 saiu, a comunidade também passou a carregar a boneca no caixote, acrescentando suas próprias histórias e regras. Anos depois, enquanto trabalhava no Episódio 2, essa foi a inspiração para a conquista \"Pequeno Astronauta\", que pedia que o jogador levasse um gnomo de jardim chamado \"Gnomo Chompski\" por todo o episódio. Chompski até voltou em Left 4 Dead 2, na conquista \"Gnomos São Nossos Amigos\", que pedia que o jogador carregasse o gnomo por toda a campanha \"Parque Sombrio\". Interações com os jogadores como essa estão entre as partes mais satisfatórias do desenvolvimento de um jogo. Projetamos jogos com teorias em mente, mas nunca se sabe onde tudo vai parar depois que o jogador entra em contato com o jogo."
N/A4050"#commentary\cn_134_the_citadel.mp3" "[ Eric Kirchmer ] Queríamos que a primeira visão da Cidade 17 destacasse a Fortaleza e sua opressão sobre a cidade, representando o poder total da Combine sobre a humanidade. Também precisava ser um objetivo claro. Mesmo no começo, você já vê onde a jornada acaba. Apesar de seu tamanho descomunal, muitos testadores não a notaram. A noção de profundidade e escala do jogador pode ser complexa em uma tela. Se já jogou RV, você deve ter notado que a escala parece mais natural. Enfim, neste caso, a posição da Fortaleza acima do jogador não ajudou, talvez porque jogos de FPS treinam os jogadores a olhar para a frente ou para os pés. Para melhorar as chances de o jogador notar a Fortaleza, incluímos aves voando rumo à estrutura, um truque sutil que ajuda a guiar a visão do jogador."
N/A4051"#commentary\cn_135_close_captions.mp3" "[ Yahn Bernier ] No desenvolvimento de Half-Life 2, pessoas interessadas em acessibilidade nos abordaram e nos encorajaram a ir além do sistema de legendas que havíamos usado em Half-Life 1. Eles pediram um sistema de legendas ocultas (CC) completo para capturar todos os sons do jogo, não só diálogos. Isso acabou sendo bem mais desafiador que o esperado. Half-Life 2 produziu uma ampla variedade de sons, e categorizá-los para as legendas foi crucial. Priorização também foi essencial: diálogos precisam se destacar, e o locutor precisava ser claro. Sons do ambiente, como combate distante, eram importantes para o clima em algumas fases, mas menos que um inimigo próximo atirando. Nossos projetistas também reaproveitaram os sons em contextos diferentes, então um som pode ter legendas diferentes em áreas diferentes. Por fim, cada som acabou tendo sua própria legenda, formatada quase como numa versão reduzida de HTML, o que nos dava controle sobre o estilo visual de cada legenda. Assim como com os áudios, os dados de legenda eram muito grandes para armazenar na memória, então criamos sistema de cache assíncrono para lidar com eles com eficiência."
N/A4052"#commentary\cn_136_the_raid.mp3" "[ David Sawyer ] A parte a seguir, em que os policiais invadem o apartamento com o jogador dentro, precisou de muitos testes para acertarmos. De forma geral, projetamos Half-Life para os jogadores definirem o próprio passo, já que cada um avança no jogo de um jeito. Alguns correm, ignorando tudo que não for ameaça, enquanto outros fuçam tudo de forma metódica. Sempre que precisamos ditar um passo específico, é um desafio fazer o jogador perceber esse passo e segui-lo de forma natural. Como aqui é a primeira vez que fazemos isso, deu trabalho deixar claro ao jogador que eles precisavam correr e que não há tempo para explorar."
N/A4053"#commentary\cn_137_materials_and_shaders.mp3" "[ Gary McTaggart ] Half-Life 2 saiu em meio a uma mudança drástica nos gráficos 3D, com a indústria migrando de texturas a materiais e sombreadores. Em Half-Life 1, toda superfície tinha uma textura, essencialmente uma imagem envolvendo a superfície dos polígonos. Já em Half-Life 2, cinco anos depois, toda superfície tinha um material e um sombreador. O sombreador era um bloco de código que personalizava a renderização da superfície. O material definia propriedades de como a superfície se comportaria fisicamente e reagiria às funções do jogo. Ele também trazia referências a texturas e outros parâmetros para o sombreador usar na renderização. Como resultado, artistas e projetistas tinham muito mais controle sobre a aparência e o comportamento das coisas. No entanto, havia um porém: Half-Life 1 podia rodar com apenas uma CPU, mas Half-Life 2 precisava de uma GPU, pois as computações necessárias para materiais e sombreadores foram projetadas especificamente para GPU. A porta de vidro canelado aqui é um exemplo nítido de sombreador personalizado, mas toda superfície na cena roda algum tipo de sombreador."
N/A4054"#commentary\cn_138_the_raid_2.mp3" "[ Miles Estes ] Além de fazer o jogador sentir a pressão de avançar, precisávamos que a invasão em si fosse infalível. Devia ser impossível que o jogador a evitasse, ou voltasse passando pelos policiais. O verdadeiro desafio não foi impedir que quebrassem a cena, mas que muitos entrariam em pânico e correriam em direções aleatórias ao perceberem a ameaça pela primeira vez. Este momento precisou de um equilíbrio delicado: queríamos uma fuga estressante, com sensação real de perigo, mas queríamos que o jogador conseguisse fugir de primeira e sentisse que escapou por um triz. Para isso, deixamos o caminho a seguir claro e parecido com o caminho seguido no andar anterior. Colocamos meticulosamente uma série de gatilhos que controlam o surgimento de ameaças na frente e atrás, mantendo a pressão, mas ainda dando tempo suficiente para o jogador manter a distância dos perseguidores."
N/A4055"#commentary\cn_139_health_and_no_hud.mp3" "[ Dave Riller ] A sequência de perseguição no telhado foi um desafio peculiar. Não queríamos que fosse um grande obstáculo, e o ideal era que o jogador passasse de primeira. Mas ainda queríamos uma sensação de perigo real, em que o jogador se sentisse ameaçado de forma legítima caso não avançasse. O desafio foi que, sem o traje HEV, ele não tinha o display de alerta nem a interface, ou seja, não havia como mostrar dano ou vida restante. Após alguns testes, criamos um sistema de vida especial para esta parte, com um brilho vermelho em volta da tela indicando dano. Os jogadores reagiram como o esperado, entendendo como sinal para avançar, e a perseguição ocorreu como queríamos. Além disso, fizemos a vida regenerar rápido para o brilho não durar muito, reforçando para o jogador que correr era o caminho, garantindo que ele não fosse abatido por uma bala perdida no final só porque enrolou ou hesitou no começo."
N/A4056"#commentary\cn_140_playtesting_anecdote_2.mp3" "[ Jakob Jungels ] Na parte a seguir, o jogador precisava ser nocauteado para que Alyx o salvasse. Com limitações de tempo e recurso, simplificamos o encontro ao máximo, reutilizando sistemas preexistentes e deixando tudo correr como um combate normal, mas com um evento diferente ativado quando o jogador \"morre\". Após alguns testes ajustando o tempo, seguimos em frente. Perto do lançamento, tivemos um problema com um testador que salvava toda hora e sempre carregava o jogo assim que achava que tinha falhado. Quando um policial o abatia, ele carregava o jogo antes que Alyx aparecesse, e repetiu isso mais de dez vezes até mandarmos parar. Naquele ponto do desenvolvimento, na fase final de correção de erros, tivemos que nos limitar a corrigir apenas erros que quebram o jogo, já que até a menor alteração podia quebrar algo mais importante. Sabendo que era um caso isolado, pois a maioria dos testadores não teve problema, fizemos mudanças conservadoras. Encurtamos o tempo de espera entre o nocaute e a primeira fala de Alyx, e trocamos a cor do fade-out de preto para branco, o que não ajudou muito, pois o jogador ainda não tinha morrido o suficiente naquele ponto para associar a cor preta à morte. Pensamos em desativar o carregamento rápido durante alguns segundos da cena, mas ficamos preocupados que isso poderia introduzir um erro que desativasse o carregamento rápido permanentemente."
N/A4057"#commentary\cn_141_character_reactions.mp3" "[ Ariel Diaz ] Descobrir a que os personagens devem reagir — e como — foi um desafio constante. Sempre queremos que o jogo responda às ações do jogador. No entanto, toda resposta do jogo pode ser entendida como recompensa. As coisas a que os personagens reagem e as que eles ignoram ensinam ao jogador que tipo de ação o jogo espera dele. Como resultado, criamos respostas às coisas que queríamos que o jogador fizesse mais, como mexer nos dispositivos do laboratório, e ignoramos comportamentos que queríamos menos, como jogadores que batiam com uma caixa na cara do Kleiner. Sem brincadeira, vimos um testador passar cinco minutos fazendo isso."
N/A4058"#commentary\cn_142_choreography.mp3" "[ Bill Fletcher ] O sistema que construímos e repetimos até a entrega da narrativa de Half-Life 2 era chamado internamente de \"Choreo\", de \"coreografia\". No início, era útil imaginar que estávamos escrevendo uma peça em que um dos atores não conhecia o roteiro. Precisávamos de um sistema que controlasse todos os outros atores, fazendo-os se mover pelo palco, atuando e dizendo as falas deles. Para lidar com isso, os outros atores precisariam se mesclar perfeitamente aos nossos comandos de direção, com respostas dinâmicas à posição e ao comportamento do jogador. Precisão no tempo seria um grande desafio, e todas as partes da cena precisariam se estender, acelerar ou até pausar dependendo do que o jogador estava fazendo."
N/A4059"#commentary\cn_143_phoneme_extraction.mp3" "[ Bill Fletcher ] Outra ferramenta crucial que construímos no FacePoser foi o editor de fonemas. Ele processava as falas dos atores e extraía fonemas, gerando animações básicas de sincronização labial para nossos personagens. Para os personagens importantes, nossos animadores usaram isso como ponto de partida para criar animações personalizadas de qualidade para cada fala, fundindo numa animação facial completa. No entanto, em cenas dinâmicas do Choreo, os animadores não sabiam exatamente o que o corpo do personagem estaria fazendo, o que exigiu uma sobreposição meticulosa de comandos do Choreo e tempos no FacePoser, mas sem comprometer a capacidade do personagem de reagir dinamicamente ao jogador."
N/A4060"#commentary\cn_144_delivery.mp3" "[ Ken Birdwell ] Precisou de muito teste e repetição para chegar ao equilíbrio certo entre informação e conexão emocional nas cenas coreografadas mais importantes. Cada cena traz muita informação que precisávamos transmitir, mas não podíamos ter apenas personagens em papel expositivo. O jogador pensaria neles mais como placas informativas e não como pessoas. Precisávamos dar um tempo para os personagens interagirem e o jogador observar essas relações. Ao mesmo tempo, tínhamos que expandir o mundo, passando a sensação de tudo o que ocorreu na ausência do jogador. Tudo isso exigia cuidado, mas não podia demorar demais, pois queríamos que o jogo também agradasse quem estivesse menos interessado na narrativa. A animação foi uma ferramenta importante para comunicar conexões emocionais entre personagens, não raro transmitindo a profundidade de um momento rapidamente sem fazer muito alarde. O humor foi outra ferramenta frequente, ajudando a romper uma cena e desarmar o jogador quando o assunto pesava demais."
N/A4061"#commentary\cn_145_alyxs_kiss.mp3" "[ Ken Birdwell ] É um momento singelo, mas o beijo de Alyx na bochecha de Eli foi crucial. Mais tarde, vamos pedir para o jogador salvar Eli, e queremos que ele se importe com o personagem. Para criar essa conexão emocional, precisávamos mostrar o afeto e o carinho entre Alyx e Eli. Não queríamos exagerar com diálogo nem fazer muito alarde. Tinha que parecer genuíno, não apenas atuação. No fim, conseguimos iterar as sutilezas do momento até chegar no ponto ideal."
N/A4062"#commentary\cn_146_storytelling.mp3" "[ Bill Van Buren ] Criar uma sensação de imersão foi um princípio central na narrativa de Half-Life 1, e isso nos levou às restrições pelas quais optamos de nunca — ou muito raramente — tirar o controle do jogador e de deixar sempre mudo o avatar do jogador. Essas limitações trouxeram alguns desafios para a narrativa, mas achamos que foi importante mantê-las em Half-Life 2. A esperança é que, mantendo esses princípios, estaríamos nos obrigando a explorar narrativas mais profundas e interativas."
N/A4063"#commentary\cn_147_archetypes.mp3" "[ Bill Van Buren ] Queríamos que os nossos personagens criassem elos narrativos entre Half-Life 1 e 2. Nossa ideia era projetar indivíduos que parecessem representações dos arquétipos de Half-Life 1 para que os jogadores os achassem familiares, quase como se já os tivessem conhecido vagamente em Half-Life 1. Baseamos o Dr. Kleiner no modelo de cientista que considerávamos o mais emblemático, e sua personalidade foi bastante moldada por Hal Robins, cuja voz e atuação definiram os cientistas de Half-Life 1. Certo dia, quando penávamos tentando decidir como seria esse personagem, o rosto do Dr. Kleiner veio a foco quando, por acaso, pegamos o elevador com um contador de um escritório de outro andar do nosso prédio. Olhando para ele, foi claro que aquele era o rosto do Dr. Kleiner. Por sorte, ele foi receptivo quando perguntamos se ele toparia tirar fotos para um personagem de videogame."
N/A4064"#commentary\cn_148_tone.mp3" "[ Bill Van Buren ] Foi essencial encontrar o tom certo para nossos personagens e diálogos. Miramos em um estilo respeitoso e quase agradável de interação com o jogador, evitando tudo que parecesse subserviente. Esse equilíbrio foi particularmente complicado com Alyx, que precisava dar suporte ao jogador sem comprometer a força de sua personagem. Isso foi crucial para os jogadores a respeitarem. Sua relação com Eli foi o principal motor das motivações do jogador, então era importante que o jogador gostasse dela e quisesse ajudá-la. Também queríamos contrastar a cordialidade e a camaradagem entre os aliados do jogador com a hostilidade de Breen e da Combine, inspirando no jogador um sentimento de indignação por justiça nas batalhas vindouras."
N/A4065"#commentary\cn_149_voice-actors.mp3" "[ Bill Van Buren ] Para criar personagens multidimensionais mais responsivos em Half-Life 2, precisávamos evoluir nossa abordagem de trabalho com os dubladores. Embora um roteiro com pouquíssima direção bastasse para a maioria dos diálogos com PNJs em Half-Life 1, em Half-Life 2, demos aos dubladores uma oportunidade para se envolver, ajudando a definir e dar vida aos personagens. Fornecemos muito mais contexto de história aos dubladores, mostrando o mundo do jogo, os ambientes onde viviam seus personagens e com quem interagiam. Buscamos dubladores que reunissem todas essas informações e as sintetizassem em suas performances a fim de elevar o personagem além do que havíamos imaginado. Fizemos várias sessões com os dubladores principais para digerirem e construírem os personagens com o tempo. Nas cenas em que os personagens interagiam entre si, muitas vezes mostrávamos as gravações de outros dubladores naquela cena para criar uma sensação melhor de fluxo e conexão. Embora chegássemos ao estúdio com um roteiro e um plano para a sessão de gravação, fazíamos os dubladores se sentirem no direito de trazer suas próprias ideias. Ter os animadores presentes nas sessões de dublagem também foi crucial, pois eles eram responsáveis por costurar o diálogo do personagem nas expressões e ações físicas a fim de formar a cena coreografada final. Com frequência, os animadores descobriam que seus planos para o desenrolar de uma cena evoluíam bastante após trabalharem com os dubladores."
N/A4066"#commentary\cn_150_citizens.mp3" "[ Bill Van Buren ] Quando chegou a hora de projetar cidadãos humanos da Cidade 17 e do mundo além dela, optamos por incluir uma variedade de etnias, idades e gêneros. Isso não só forneceu contexto narrativo para que a Combine tenha escravizado toda a humanidade, como também foi importante para que qualquer jogador se visse representado na Resistência, estando todos na Terra unidos contra a Combine. Embora tenhamos encontrado vários candidatos para usarmos de referência na criação de cidadãos em nossas vidas e conexões pessoais, acabamos recorrendo aos classificados do Seattle Times para atingir o número de rostos que tínhamos em mente."
N/A4067"#commentary\cn_151_alyx.mp3" "[ Dhabih Eng ] Acertar o design de Alyx foi um grande desafio. Queríamos que o jogador a respeitasse e gostasse dela. Salvar Eli era um grande objetivo do jogador no meio do jogo, e sabíamos que fazer o jogador se importar com esse objetivo seria mais fácil se também se importasse com Alyx e a relação dela com o pai. Toda decisão foi intencional: o design, os diálogos e a escolha da dubladora de Alyx serviram para transmitir a imagem de alguém sagaz, hábil e identificável dentro de um mundo controlado pela Combine, mas também atraente e carismática. Quisemos evitar a objetificação, os exageros e a hipersexualização comuns a muitos jogos dos anos 2000, pois achamos que prejudicaria nossas metas para a personagem."
N/A4068"#commentary\cn_152_lab_interactivity.mp3" "[ Dhabih Eng ] Nas cenas coreografadas, prendemos o jogador por um tempo, focando nos personagens e na narrativa. Para acomodar jogadores diferentes — alguns bastante interessados na história, outros incapazes de ficarem parados por um segundo —, precisávamos de um fluxo constante de detalhes cativantes na tela. Espalhamos elementos narrativos pelo ambiente para que houvesse brinquedos interativos para o jogador mexer. Em alguns casos, incorporamos ainda mais narrativa nesses objetos, como o miniteletransportador do cacto, que aponta para o futuro fracasso com o teletransportador. Foi um equilíbrio delicado: muito estímulo visual distrairia o jogador do foco da cena. Por fim, o Laboratório do Kleiner seguiu uma interatividade mais segura, pois era a primeira cena coreografada. Depois, no Laboratório do Eli, exploramos com mais profundidade para que os personagens prestassem atenção àquilo em que o jogador estivesse mexendo."
N/A4069"#commentary\cn_153_gestures.mp3" "[ Doug Wood ] Cada personagem tinha uma biblioteca de animações simples chamadas \"Gestos\", que eram fáceis de sobrepor a outros movimentos corporais. Embora seu propósito original fosse economia, pois permitiam reutilizar animações no jogo, elas acabaram tendo mais utilidade. Seres humanos costumam repetir certos movimentos, e eles podem ser marcadores de certa personalidade. Como resultado, nossa biblioteca de Gestos acabou capturando a essência de cada personagem, ajudando a unificar a compreensão que a equipe de animação tinha de quem eram esses personagens. Assim, ficou muito mais fácil para os animadores dividirem a carga de trabalho de um personagem, o que era necessário com frequência."
N/A4070"#commentary\cn_154_interactive_storytelling.mp3" "[ Erik Johnson ] Quando começamos Half-Life 2, a narrativa nos jogos costumava ser ou de alta fidelidade e linear, ou de baixa fidelidade e interativa. Sabíamos que os jogadores já tinham visto narrativas de qualidade em jogos, mas nunca haviam sido colocados bem no meio dela, podendo vê-la se desenrolar, interagir com ela, examinar as partes de perto. Embora essa meta fosse empolgante, ainda não sabíamos como fazer, nem que tecnologia seria necessária. Criamos várias tecnologias narrativas em Half-Life 1, mas quase tudo era apresentado ao jogador, carecendo da interatividade e fidelidade que almejávamos. Então o laboratório do Kleiner virou a parte do jogo que usamos de teste para descobrir como nossa narrativa interativa funcionaria de fato."
N/A4071"#commentary\cn_155_monitors.mp3" "[ Ido Magal ] Usamos muito os monitores nas narrativas de Half-Life 2 e episódios — tanto que até fazemos piada disso. A verdade é que eles são muito úteis. São fantásticos para expandir o mundo, mostrando eventos ocorrendo em outro lugar, e para fornecer um meio fácil de os personagens conversarem sem precisarmos explicar como eles estão no mesmo local que o jogador. Quem já escreveu uma história, principalmente com um elenco volumoso, entende a frustração de tentar criar motivos naturais para todos os seus personagens se reunirem no mesmo lugar. Neste caso, foi ótimo que o monitor tenha permitido que Alyx se teletransportasse e logo aparecesse no Laboratório de Eli, deixando tudo mais realista e conectado."
N/A4072"#commentary\cn_156_scene_interactivity.mp3" "[ Jeff Lane ] Em certos pontos das cenas coreografadas, o jogador precisa realizar uma ação. Além de dar algo para ele fazer e manter o foco, esses momentos serviam alguns propósitos cruciais. Primeiro, o jogador podia voltar para a cena caso tenha se distraído com o ambiente. A cena ficaria \"pausada\" até o jogador concluir a ação, e ele voltaria a prestar atenção. Ao mesmo tempo, podíamos posicionar o jogador onde precisávamos, o que foi útil para enquadrar a cena e garantir que ele visse algo importante. Em alguns casos, esses momentos serviam também como treinamento. Aqui, o jogador aprende a interagir com plugues e tomadas, habilidade que será necessária em quebra-cabeças que aparecem mais tarde no jogo."
N/A4073"#commentary\cn_157_kleiners_lab.mp3" "[ Marc Laidlaw ] O laboratório do Kleiner foi o primeiro local de narrativa em que trabalhamos, e um dos que levou mais tempo para resolver. Além de seu papel em introduzir o jogador no jogo, ele virou a visão que uniu a equipe de desenvolvimento em termos de narrativa. Quando começamos a criar os personagens e a entrega da narrativa em torno do jogador, surgiram muitas questões, e todas representavam grandes riscos para o jogo. O jogador extrairia as informações importantes da cena? Será que se importariam com os personagens? Como acolhemos jogadores com diferentes níveis de interesse pela história? Qual seria o custo de produzir uma cena como esta? E de quantas cenas precisaríamos? A essas e muitas outras perguntas, não podíamos responder até termos construído boa parte da cena e experimentado com muitos testadores. O frustrante é que, assim como muitos problemas que enfrentamos, não eram perguntas que responderíamos com confiança até termos avançado o bastante no trabalho. Com frequência, testamos ideias com protótipos de baixa fidelidade, mas, se o jogador não está interessado na narrativa quando os personagens são apenas blocos cinza, com que confiança podemos acreditar que eles vão se importar com personagens totalmente desenvolvidos?"
N/A4074"#commentary\cn_158_characters.mp3" "[ Marc Laidlaw ] Os seguranças e cientistas de Half-Life 1 podem ser descritos como arquétipos, não como indivíduos. Eram abstrações de personagens que batiam com a fidelidade visual viável na época. Mas, como nossa tecnologia melhorou em Half-Life 2, vimos uma oportunidade de ir além das abstrações. A fidelidade visual aprimorada dos modelos dos personagens e da animação nos fez acreditar que podíamos focar na criação de personagens individuais, pessoas por quem você poderia se afeiçoar. Nos permitimos escrever diálogos reais e ter personagens para entregá-los de uma forma que parecesse realista a ponto de os jogadores não os enxergarem como peões em um videogame e, com sorte, também impulsionar nossa narrativa. Em 2001, com dois anos de desenvolvimento, ficamos empolgados com Ico, do Japan Studio. Dirigido por um animador, o jogo nos surpreendeu por usar os personagens como ponto-chave de conexão com o jogador, e isso nos deu coragem para prosseguir."
N/A4075"#commentary\cn_159_writing.mp3" "[ Marc Laidlaw ] Na era de Half-Life 1, as metas de jogos FPS ainda eram principalmente lutar e derrotar um inimigo obviamente mau. Era difícil fazer os jogadores ligarem para os personagens quando estes eram de baixa fidelidade como em Half-Life 1. Com as melhorias planejadas na fidelidade dos personagens em Half-Life 2, queríamos que os personagens fossem a força-motriz da narrativa. O objetivo era que as motivações do jogador se alinhassem às dos personagens e que o jogador se importasse com essas pessoas, seus medos e anseios, e torcessem por seu sucesso. Com isso em mente, chegamos à nossa abordagem para personagens e diálogos. Criávamos um grupo de personagens com laços muito fortes entre eles na esperança de que o jogador sentisse essas conexões. Esses personagens interagiam de uma forma inclusiva, como um grupo de velhos amigos que veem o jogador com alguém do grupo, mas que passou muito tempo afastado. Se os personagens demonstrassem conexões emocionais realistas entre eles, acreditamos que poderíamos criar uma conexão emocional também com o jogador."
N/A4076"#commentary\cn_160_animation.mp3" "[ Miles Estes ] Criar movimento humano realista para nossos personagens com várias camadas distintas de animação demandou muita iteração tecnológica. Até ações simples, como virar para olhar algo ou andar até um local, ficaram mais complexas quando combinadas com a necessidade de resposta dinâmica ao jogador e aos requisitos dos comandos do Choreo. Por exemplo, virar para olhar algo precisava ser decomposto, permitindo que o personagem usasse qualquer combinação de olhos, cabeça, ombros, tronco superior ou corpo inteiro para olhar o alvo. Em Half-Life 1, os humanos tinham o corpo dividido em metades superior e inferior para poderem andar em uma direção enquanto olhavam para outra. Para os personagens de Half-Life 2, essa abordagem era muito abstrata. Em vez disso, nossa equipe criou animações de caminhada em todas as oito direções, o que se mesclava de forma orgânica em tempo real."
N/A4077"#commentary\cn_161_faceposer.mp3" "[ Yahn Bernier ] A principal ferramenta que criamos como motor do sistema Choreo era chamada de FacePoser, um programa de nome impreciso para nossos animadores disporem toda a estrutura das nossas cenas em uma linha do tempo. Essa linha continha uma série de comandos do Choreo para os atores, além de toda informação extra para eles realizarem os comandos. Dispondo esses comandos na linha do tempo, os animadores descreviam facilmente como um ator precisava encarar uma coisa, falava com outra, enquanto andava para outro lugar, tudo ao mesmo tempo. Mas a linha do tempo não era uma sequência fixa e linear. Os atores seguiam seus comandos, mas precisavam responder de forma dinâmica ao mundo ao redor. Um ator pode levar mais tempo para andar até um local se o jogador estiver no caminho ou se precisar esperar antes de dizer uma fala porque o jogador atrasou outro ator. O FacePoser permitia iterar as cenas rapidamente, experimentando com disposições, entregas de diálogo e tempo diferentes. Poder testar e ajustar rapidamente foi essencial para encontrar as performances corretas e atingir nossas metas para a narrativa e os personagens."
N/A4078"#commentary\cn_162_choreo_commands.mp3" "[ Yahn Bernier ] Essa visualização da depuração mostra os dois comandos mais comuns do Choreo que os atores recebem na cena, conhecidos internamente como \"olhar-para\" e \"ir-para\". Os atores recebem alvos para olhar, às vezes mais de um por vez, e tentam focar no que faz mais sentido, considerando seu estado atual. Ao mesmo tempo, podem receber comandos \"ir-para\", que mandam ir a um local e olhar para um objeto ou direção específico. Até esses comandos aparentemente simples envolviam muita complexidade. Uma cena pode pedir que um ator fale enquanto digita no teclado, tudo isso enquanto olha para o objeto na mão do jogador. Como não dava para prever onde o jogador estaria durante a reprodução, para criar cenas, era necessário quebrar cada elemento em partes e camadas distintas. Depois, essas peças eram remontadas durante a reprodução com base nas ações do jogador, ou até interrompidas se necessário."
N/A4079"#commentary\cn_163_antlions.mp3" "[ Kerry Davis ] Com o jogador dirigindo o buggy pela Costa, precisávamos de um inimigo onipresente que pudesse aparecer em qualquer lugar e que fosse uma ameaça constante a fim de manter o jogador no buggy. As formigas-leão aparecendo da areia foram a solução perfeita. Com sua alta mobilidade, investiam para alcançar o buggy, diferentemente dos inimigos humanoides. Fora que atropelá-las era gostoso demais."
N/A4080"#commentary\cn_164_thumpers.mp3" "[ Adrian Finol ] Sempre que possível, é muito bom fazer o jogador sentir que descobriu algo sozinho. Faz o mundo parecer mais vivo, em vez de uma série de elementos de jogo esperando pelo jogador. Se aceitarmos o risco de que parte dos jogadores talvez não note esse elemento, podemos optar por uma abordagem mais sutil. Seguimos esse caminho com os Batedores ao projetar configurações que os tornam prováveis de encontrar, mas que não obrigam o jogador a interagir com eles. Há muitas dicas sonoras e visuais, além das reações das formigas-leão, para ajudar o jogador a entender o que está acontecendo. Não garante que todo jogador vá compreender, mas os testes mostraram que a maioria entendia."
N/A4081"#commentary\cn_165_d2_coast_09.mp3" "[ Aaron Seeler ] Em momento tardio do desenvolvimento da Costa, chegamos a um ponto em que nosso código estava tão avançado em relação ao projeto das fases que os programadores estavam procurando mais código para escrever e novas tarefas para ajudar a lançar Half-Life 2. Isso foi por conta das demandas altas da Costa, que exigiam muito dos projetistas de fase por serem enormes e usarem muito do terreno. Então os programadores ficaram projetando confrontos menores. Depois, quando os projetistas alcançaram, começaram a criar esta fase emendando três confrontos separados dos programadores e fazendo todos os ajustes finais para preparem tudo para o lançamento."
N/A4082"#commentary\cn_166_final_scene.mp3" "[ Bill Van Buren ] Prender o jogador em um casulo no confronto final no gabinete de Breen foi um pouco tenso, mas isso nos permitiu focar nos personagens de uma forma que não foi possível em outros lugares. Os arcos de todos os personagens culminam nesta cena, e restringir o jogador a este ponto de vista traz a oportunidade de se criar uma emoção real: uma cena decisiva, movida à combinação de diálogos, vozes e animações. Do ponto de vista de produção, a cena foi um desafio: ajustar a marcação e os movimentos, acertar o tempo e a conexão e a energia emocionais de todas as animações individuais, e as vozes que foram gravadas separadamente. Precisamos fazer vários ajustes para que atingíssemos a sinergia dramática e que todos os personagens parecessem conectados de fato."
N/A4083"#commentary\cn_167_end_game_scramble.mp3" "[ Dave Riller ] Originalmente, havia uma cena coreografada bem maior preparada para o fim do jogo. Contudo, a equipe de coreografia estava muito ocupada com a quantidade enorme de trabalho narrativo que ainda faltava. Para tirar carga dos ombros deles, pedimos que a equipe de jogabilidade da Fortaleza criasse um desafio para concluir o jogo. Poderia ser um quebra-cabeça, um combate... qualquer coisa. A batalha resultante contra Breen usou a mecânica pré-existente da arma de supergravidade e poucas coreografias personalizadas para criar um produto acabado em um tempo curtíssimo."
N/A4084"#commentary\cn_168_combine_portal_effects.mp3" "[ Gary McTaggart ] Uma parte crucial do nosso processo de desenvolvimento é como qualquer membro da equipe pode contribuir com suas habilidades em qualquer parte do jogo. Quando a batalha final ficou consolidada, artistas e programadores de efeitos visuais ajudaram a melhorar a apresentação do portal ao mundo natal da Combine e do efeito de tempo parado no final do jogo. Usamos um sombreador refrativo semelhante ao da água para o efeito do portal da Combine."
N/A4085"#commentary\cn_169_citadel_entrance.mp3" "[ Jeff Lane ] Construímos a rota de entrada na Fortaleza ao contrário. Criamos a geometria do interior como protótipo de arte para aperfeiçoar a aparência. Sabíamos que você entraria pelo esgoto no mapa da guerra na rua e tivemos que criar uma parte com escorregadores e saltos que davam para a entrada da Fortaleza."
N/A4086"#commentary\cn_170_citadel_steep_landing.mp3" "[ Randy Lundeen ] A Fortaleza foi construída bem tarde no desenvolvimento e, de início, não tínhamos uma visão clara quanto à jogabilidade. Isso não é raro. Embora o projeto do jogo costume impulsionar nosso processo, grande decisões criativas que tomamos cedo, como a existência da Fortaleza da Combine, precisam de trabalho de design específico para se encaixar no produto final. Após a batalha emocionante do capítulo anterior, queríamos mudar o tom para o final na Fortaleza ser mais recompensador. Mesmo assim, criar novas mecânicas a esta altura é muito arriscado. Nosso plano inicial era criar um espetáculo narrativo passivo: um passeio de trem pela máquina de guerra da Combine até o gabinete de Breen. Depois de desenvolvermos esse plano, passamos dias prototipando mecânicas com a arma de supergravidade, pensando que, no final do jogo, seria satisfatório ao jogador se o tornássemos superpoderoso, sem quebrar o equilíbrio geral do jogo. Os resultados logo foram promissores, o que levou a uma rápida reformulação para incorporar a arma de supergravidade. Em vez dos desafios tradicionais de fim de jogo, queríamos que o jogador se sentisse um deus pegando os inimigos, arrancando consoles da parede etc. No fim, a Fortaleza mescla esses dois conceitos, alternando entre espetáculo e superpoder."
N/A4087"#commentary\cn_172_lightmap_pass.mp3" "[ Mike Dussault ] O interior da Fortaleza tem geometria relativamente simples, mas os materiais de metal da Combine e a iluminação dramática ajudam a vender a imensidão da estrutura. Aumentamos a resolução dos mapas de luz em superfícies importantes e reduzimos nas que estavam na sombra ou distantes. Além disso, por conta do tamanho dos espaços da Fortaleza, superfícies de mapa de luz desnecessariamente grandes tinham um impacto significativo no desempenho. Perto do fim do desenvolvimento, passamos pelas fases da Fortaleza para otimizar esses valores em termos de interesse visual e desempenho. Isso foi muito fácil por conta de um recurso do editor Hammer que exibia superfícies com sua densidade de luxel."
N/A4088"#commentary\cn_173_super_gravity_origins.mp3" "[ Brian Jacobson ] Neste ponto do desenvolvimento, tínhamos confiança no design da arma de gravidade. Queríamos que o jogador se sentisse onipotente e passamos a trabalhar na versão supercarregada da arma. Não demorou muito — talvez um dia de prototipagem — até termos um resultado satisfatório, e ela virou o cerne da jogabilidade da Fortaleza. Com nosso motor de física completo, tínhamos liberdade para encontrar novas formas empolgantes de ir além dos limites de antes e proporcionar toda a diversão que saísse daí. Nosso objeto de prototipagem — uma melância pesadíssima de centenas de quilos no nosso simulador de física — acabou virando as bolas da Combine que você vê no jogo."
N/A4089"#commentary\cn_174_combine_energy.mp3" "[ Brian Jacobson ] O que veio à vida como melancia na forma de protótipo acabou virando uma bola de energia depois que os sons criados para o impacto e a explosão pareciam menos fruta e mais o que temos no jogo. Quando começamos a iterar fases não baseadas na melancia, notamos que poderíamos usar a bola de energia não apenas como uma forma divertida de matar soldados, mas como um elemento de quebra-cabeça que pudesse ligar e desligar vários equipamentos. Em um ponto posterior do desenvolvimento, não estávamos gostando do disparo alternativo da AR2 e, como a equipe gostava da bola da Combine, acabamos incorporando ela no disparo alternativo da AR2. Sempre ficamos surpresos em retrospecto com a forma como algumas coisas funcionam independentemente no jogo e acabam se mesclando depois para resolver um problema."
N/A4090"#commentary\cn_175_combine_wall_and_balls_training.mp3" "[ Ido Magal ] Nos testes, os jogadores não estavam notando que as Esferas da Combine dissolviam os soldados, nem por que eles estavam desaparecendo. Primeiro, tentamos fazer as esferas quicar na direção dos inimigos para aumentar a chance de ocorrer esse tipo de abate. Acabamos percebendo que o motivo pelo qual os jogadores não notavam o efeito era porque ele sempre ocorria durante um combate intenso, e as pessoas têm capacidade limitada de aprender algo novo sob estresse. Como tentativa mais tardia de remediar isso, inserimos uma sala de treino de baixa pressão, com um campo de força que só era aberto ao pegar uma bola da Combine. Criamos essa configuração apenas para ensinar que as bolas da Combine desativavam campos de força, e que jogá-las nos soldados fazia eles se dissolverem. Apesar de nossos esforços, alguns jogadores ainda custaram a notar os efeitos de dissolução dos projéteis. Ficamos sem tempo e decidimos que, como os jogadores ainda relatavam que se sentiam poderosos, não havia problema se eles não percebessem por que estavam tendo sucesso."
N/A4091"#commentary\cn_176_weapon_strip.mp3" "[ Josh Weier ] Quando introduzimos a arma de supergravidade, não queríamos que o jogador voltasse a usar as armas convencionais, então fizemos a única coisa racional a fazer: desintegrá-las. Ter como antagonista do jogo um inimigo sobrenatural incompreensível como a Combine ajuda porque faz sentido que eles tenham um desintegrador. Por que não? E, se por algum motivo precisássemos que você recuperasse seu arsenal no meio da fase, veja só: eles também têm um reintegrador."
N/A4092"#commentary\cn_177_breen_monologue.mp3" "[ Marc Laidlaw ] Trabalho criativo nunca nasce do vácuo, pois somos todos inspirados por outras coisas. O monólogo de Breen que aparece nos monitores da Fortaleza foi inspirado em um jogo que adorávamos: Thief 2, no qual o antagonista provoca o jogador enquanto ele está avançando furtivamente. A execução é bem diferente, mas a inspiração principal é visível. O trabalho pesado mesmo e o que fez a diferença foi a performance do saudoso Robert Culp. A atuação dele foi perfeita. Ele interpretou cada fala do Breen com uma sutileza e um toque que tiraram o personagem do papel e o transformaram em algo especial. Toda sessão de gravação com Robert Culp era facílima: ele tinha o roteiro, o diretor apertava o botão para gravar, e pronto. A lição reforçada aqui é trabalhar com gente mais talentosa que você, que tenha algo a lhe ensinar. Não chegue com uma ideia fixa de como a frase deve ser interpretada ou como um momento precisa se desenrolar. Em vez disso, trabalhe com pessoas talentosas e chegue com a confiança de que elas podem deixar tudo muito melhor."
N/A4093"#commentary\cn_178_dissolved_weapons.mp3" "[ Quintin Doroquez ] Tivemos dois motivos para fazer todas as armas da Combine se dissolverem depois que o soldado virasse boneco com a arma de gravidade. Primeiro, para o jogador não pegar e usar a arma. Segundo, para melhorar o desempenho nesses mapas. Além disso, o gerenciador de bonecos que criamos removia os corpos dos soldados abatidos conforme o jogador avançava."
N/A4094"#commentary\cn_179_elevator_fight.mp3" "[ Brian Jacobson ] Embora quiséssemos que o jogador se sentisse todo-poderoso, não dava para resistir à tentação de incluir uma luta difícil na área do elevador. A batalha durante a espera pelo elevador acabou sendo um tanto mais difícil que a ideia original para esta parte do jogo. Ficou mais fácil durante os testes, mas não havia tempo de teste suficiente para equilibrar a luta até o nível desejado. Embora o jogador nunca esteja em perigo real, o número de soldados que aparece é o que faz a batalha parecer mais grandiosa do que é."
N/A4095"#commentary\cn_180_replacing_the_prefabs.mp3" "[ Jeff Lane ] As bolas de energia da Combine são relativamente simples, com um campo de força mantendo os objetos quicando eternamente. Mas, durante os testes, houve vários erros com as bolas de energia quicando por aí, se rebelando e \"fugindo\" do campo de força feito para contê-las. Por conta dos limites de nossa tecnologia pré-fabricada da época, precisamos reconstruí-las manualmente várias vezes, em todas as fases da Fortaleza onde elas apareciam."
N/A4096"#commentary\cn_181_strider_fight.mp3" "[ Ted Backman ] Um dos protótipos originais da Fortaleza incluía pegar o trípode com a arma de supergravidade e, por muito tempo, a luta com o trípode se resumia a chegar perto o suficiente para agarrá-lo com a arma. Mais pro final do desenvolvimento, decidimos que pegar o trípode o fazia parecer muito fraco, principalmente depois de todo o combate contra ele na Guerra nas Ruas, então trocamos o confronto para você ter que matá-lo com uma bola da Combine. Acrescentamos peças ao modelo do trípode para você arrancar e estourar em vez de arrastar seu corpo. É a única vez no jogo em que um trípode tem esse efeito."
N/A4097"#commentary\cn_182_getting_in_the_pod.mp3" "[ Dhabih Eng ] A sequência de ascensão no casulo que começa aqui exigiu que tirássemos todo o controle da cena e da visão do jogador. Isso vai contra nosso desejo típico de fazer o jogador ter o máximo de controle possível. Nesta etapa final, sentimos que valia a pena. O jogador está tão poderoso que é difícil controlá-lo, então precisamos desativá-lo. Ainda temos todos os personagens na cena falando com o jogador, mantendo-o no centro das atenções. Também conseguimos incluir alguma narrativa durante o deslocamento. O passeio sobre trilhos pela Fortaleza que começa aqui contém vários adversários para os quais tínhamos conteúdo de arte, mas que foram cortados da parte principal do jogo. Da segurança de um casulo confortável, você vê o processamento de sub-humanos e tem um vislumbre da síntese de chupa-crânios."
N/A4098"#commentary\cn_183_turrets.mp3" "[ Mike Dussault ] As torretas foram uma ferramenta de design útil quando o jogador tinha a isca, pois evitavam que as formigas-leão se aproximassem diretamente. Assim, pudemos criar configurações em que o jogador não pudesse arremessar a isca para avançar, mas que tivesse que dar a volta e eliminar as torretas para as formigas-leão seguirem. Também não foi ruim que as formigas-leão sendo dizimadas pelas torretas era um espetáculo legal de ver."
N/A4099"#commentary\cn_184_grenade_puzzle.mp3" "[ Aaron Seeler ] Este pequeno quebra-cabeça fez um bocado de jogadores empacarem nos testes porque a caixa de granadas ilimitadas ficava um pouquinho para trás. A esta altura do jogo, o jogador já associou caixas de munição infinita à solução de quebra-cabeças, então, se houvesse uma caixa de granadas aqui, ele saberia na hora que precisaria de uma granada. Queríamos que ele pensasse um pouco primeiro. Acabamos incluindo uma dica sutil depois, deixando granadas visíveis na mesa pela janela, para lembrar o jogador que elas estão disponíveis. Elas também ajudaram a descobrir um erro em um teste em que um jogador se aproximou para olhar melhor a acabou coletando as granadas através do vidro."
N/A4100"#commentary\cn_185_allied_turrets_balancing.mp3" "[ Adrian Finol ] Equilibrar esta luta em torno das torretas aliadas foi um desafio. As torretas são a novidade, então, se o jogador as ignorar, a jogabilidade parece redundante porque boa parte é parecida com momentos anteriores. Queríamos que o uso das torretas e seu posicionamento estratégico fossem necessários, mas acabou sendo binário: o posicionamento perfeito deixava a luta fácil; já um ruim deixava bem difícil. O que ajudou foram ajustes e uma IA de soldado personalizada. Os soldados ficaram melhores em derrubar torretas jogando granadas ou flanqueando. Essas mudanças deixaram a luta menos dependente de uma configuração perfeita e mais de uma manutenção ativa das torretas, pois qualquer configuração seria quebrada em algum momento. Os testes variaram muito: alguns jogadores acharam a luta dificílima; outros disseram que era sua preferida. Com o tempo acabando, acabamos deixando a luta mais fácil e lançamos assim, mesmo que insatisfeitos com o equilíbrio final."
N/A4101"#commentary\cn_186_meeting_mossman.mp3" "[ Ariel Diaz ] Reunir o jogador e Alyx com Judith após a cena de traição foi complicado, pois muitos jogadores achavam que deviam atirar na Judith assim que a vissem. Não podíamos permitir isso, pois não tínhamos tempo para desenvolver ramificações na história. Mas também não queríamos deixar claro que estávamos impedindo essa decisão, então tentamos diminuir a probabilidade de o jogador tentar matá-la. O vidro à prova de balas serve para ganhar tempo pro diálogo entre Alyx e Judith, durante o qual fica claro que Alyx não acha que atirar na Judith é o certo a fazer."
N/A4102"#commentary\cn_187_eli_in_pod_choreography.mp3" "[ Ken Birdwell ] Escrevemos e gravamos o diálogo desta cena enquanto ainda construíamos Nova Prospekt. Naquele ponto, sabíamos que Alyx e Gordon sairiam da prisão via teletransporte, mas os detalhes ainda não estava definidos, então o diálogo precisava ser vago o bastante para encaixar no que criássemos. Isso nos levou a focar menos nas ações do jogador e mais na vulnerabilidade de Alyx e na conexão dela com o pai. A intenção era que as emoções carregassem a cena mais que a narrativa. Por fim, o objetivo era que o jogador se importasse com esses personagens, que priorizasse o que é importante para Alyx."
N/A4103"#commentary\cn_188_mossman_and_eli.mp3" "[ Bill Van Buren ] Esta cena coreografada precisou de muita iteração. Queríamos entregar uma reviravolta no meio da cena, mantendo o controle do jogador irrestrito. Precisou de um equilíbrio delicado para deixar essa reviravolta clara ao mesmo tempo em que não desse para interromper. Se seguisse Alyx até o console, o jogador precisaria entender o que estava havendo ao dar meia-volta. Se ficasse para trás observando Judith, precisaria entender o que estava havendo sem sentir que precisava evitar que aquilo ocorresse. Foi com muitos testes e ajustes que chegamos ao tempo certo, mas acabamos empregando uma combinação de distração, entrega rápida do momento crucial, e uma explicação após o evento."
N/A4104"#commentary\cn_189_nova_prospekt_entry.mp3" "[ Danika Rogers ] O jogador acabou de concluir duas fases com muito combate, então queríamos desacelerar o ritmo quando ele entrasse. As fases iniciais foram projetadas como mudança de ritmo para os jogadores explorarem o interior de Nova Prospekt. No caminho, começamos a apresentar a jogabilidade da torreta, primeiro como inimigo e depois como ferramenta. Boa parte desta fase foi reaproveitada de protótipos e espaços de arte criados no início do projeto, quando estávamos focados em definir a aparência de Nova Prospekt."
N/A4105"#commentary\cn_190_turret_training_exit.mp3" "[ Doug Wood ] Esta pilha de lixo, assim como a descida apertada pela escada, foi projetada para desencorajar o jogador de trazer uma torreta. Embora trazer a torreta não fosse quebrar nada, queríamos diminuir essa probabilidade. Fazer com que trazer a torreta seja inconveniente não é uma estratégia ideal de design, mas era melhor que nada. Muitos testadores acabaram desistindo e jogando a torreta fora quando sentiram que o jogo estava tentando dizer alguma coisa."
N/A4106"#commentary\cn_191_allied_antlions.mp3" "[ Eric Kirchmer ] Para termos um exército de formigas-leão que ressurgem infinitamente para atacar torretas e soldados, passamos tempo pensando no papel do jogador no combate em Nova Prospekt. O jogador já enfrentou muitos soldados da Combine, então deixamos a luta mais como um quebra-cabeça espetaculoso que um desafio de combate. Com isso em mente, criamos configurações que permaneciam estáveis até o jogador intervir. Se matasse os inimigos diretamente, o jogador facilitava o trabalho das formigas-leão, mas queríamos que usar a isca recompensasse bem o jogador. Em muitos cenários, quando o jogador arremessava uma isca nos inimigos, ativávamos geradores extras de formigas-leão, liberando um surto rápido de novas formigas-leão na luta. A carnificina resultante era a recompensa que deixava a isca divertida de usar."
N/A4107"#commentary\cn_192_laser_mines.mp3" "[ Erik Johnson ] Gostamos muito de trazer as minas antipessoais a laser para Nova Prospekt. Elas eram uma arma de Half-Life 1 que não conseguimos incluir em Half-Life 2, mas pelo menos entraram como elemento de quebra-cabeça. Gostamos como elas serviam de teste de moralidade quando o jogador tinha um exército de formigas-leão. Alguns jogadores arremessaram a isca imediatamente nas minas, usando o corpo da formiga-leão para resolver o problema, enquanto outros contiveram seus amiguinhos até removerem as minas com outras ferramentas. Não julgamos."
N/A4108"#commentary\cn_193_final_turret_arena.mp3" "[ Erik Johnson ] Ao construir o arco de um elemento de jogabilidade, como o uso de torretas aliadas, costumamos começar criando um protótipo que representa o ponto final do arco. Iteramos até os testes mostrarem que funciona, depois fazemos o caminho contrário, incluindo cenários anteriores que apresentam o elemento e treinam o jogador. Essa abordagem garante que o arco final seja envolvente antes de investirmos muito tempo. Fora que, quando criamos cenários de treino, já observamos testes para saber quais habilidades precisam de mais orientação e quais os jogadores aprendem naturalmente. O cenário final da torreta era nosso objetivo, enfatizando a defesa do jogador contra inimigos de várias direções, o que requer posicionamento dinâmico de torretas e recuperação."
N/A4109"#commentary\cn_194_one_way_drops.mp3" "[ Jakob Jungels ] O jogador nunca sabe o que o aguarda adiante, mas sabe o que há atrás, então é comum que recue a um terreno conhecido quando encontra um inimigo. Se construirmos uma arena em que queremos que o jogador se envolva — principalmente com um inimigo com requisitos de geometria específicos como a Formiga-Leão Guarda —, precisamos de uma forma de impedir esse recuo. Uma solução comum é fazer o jogador entrar na arena por uma queda, recurso que você já deve ter notado algumas vezes."
N/A4110"#commentary\cn_195_npcs_on_elevators.mp3" "[ Jay Stelly ] É comum passarmos muito tempo solucionando problemas que o jogador talvez nem note. Muitos são desafios sutis de design, embora outros sejam oriundos da interação de vários sistemas. Por exemplo, fazer um personagem não jogável andar de elevador foi um problema complexo porque envolvia vários sistemas: tomada de decisão de PNJs por IA, planejamento de navegação e simulação de movimento, para citar alguns. Além disso, o elevador já tinha seus próprios requisitos de simulação sem relação com PNJs. Um dos desafios mais sutis se deu porque simulamos NPCs em taxa mais lenta do que simulamos elevadores. Ou seja, um PNJ descendo de elevador seria simulado para que ficasse de pé no elevador, e então o elevador seria simulado algumas vezes, a cada instância descendo um pouco mais, sutilmente deixando o PNJ para trás. Logo em seguida, o PNJ seria simulado uma segunda vez, aparecendo no piso do elevador de novo. Dá para imaginar que era difícil levar Alyx a sério quando ela ficava caindo aos pouquinhos enquanto conversava com você."
N/A4111"#commentary\cn_196_looktargets.mp3" "[ John Cook ] Uma das ferramentas mais importantes para nossos projetistas é o OlharAlvo: um ponto invisível no espaço que é ativado quando o jogador olha para ele. Os projetistas conseguem especificar a precisão e a duração do olhar, além de outras condições. Ao ser ativado, o OlharAlvo desencadeia vários eventos no jogo. Por exemplo, Alyx pode esperar o jogador olhar antes de dizer sua fala, um espetáculo pode começar quando estiver no campo de visão, ou um cargueiro da Combine pode passar voando quando o jogador olhar naquela direção aproximada. Quando implementamos o OlharAlvo, os projetistas encontraram várias formas de usá-lo e deixar a jogabilidade mais confiável, principalmente porque os jogadores andam em velocidades diferentes ou de formas difíceis de prever."
N/A4112"#commentary\cn_197_nova_prospekt_yard.mp3" "[ John Morello ] O combate no pátio de Nova Prospekt foi inspirado em nossas observações iniciais das formigas-leão lutando contra soldados da Combine. A alta mobilidade e os ataques corpo a corpo das formigas-leão combinavam com a letalidade à distância e a vulnerabilidade de perto dos soldados. As formigas-leão ficam ótimas sob tiro, com efeitos de partículas voando para todo lado e, quando alcançam um soldado, o efeito de boneco de pano resultante é bem satisfatório."
N/A4113"#commentary\cn_198_vent.mp3" "[ John Morello ] Você já deve saber, mas, se há um duto de ventilação, há um chupa-crânio dentro. Não criamos essas regras; assim como os dutos, elas vêm de cima."
N/A4114"#commentary\cn_199_kitchen.mp3" "[ Kerry Davis ] É costume conhecido entre desenvolvedores de jogos que toda cozinha de videogame precisa incluir uma explosão de gás."
N/A4115"#commentary\cn_200_alyxs_tool.mp3" "[ Laura Dubuk ] A multiferramenta de Alyx foi bem útil para usarmos a personagem como chave. Com frequência, precisávamos impedir o jogador de avançar até estarmos prontos, e a multiferramenta permitia que Alyx dissesse sua fala enquanto destrancava o caminho. Acho que abusamos um pouco dessa solução, mas era difícil resistir. Há sempre uma compensação: usar Alyx para travar uma sala, em vez de criar uma solução personalizada, poupava tempo que gastávamos em outras partes do jogo, em geral mais críticas."
N/A4116"#commentary\cn_201_mossmans_betrayal.mp3" "[ Marc Laidlaw ] Nosso plano original para o arco de Judith Mossman era ela trair o jogador neste ponto do jogo. Mas, quando chegamos a esta cena, com outras partes já desenvolvidas, sentimos que ela estava mais tentando proteger o Eli. Imaginamos que ela reconsiderou, percebendo que ela não podia trair Gordon. Tínhamos ideias para esclarecer essa mudança depois, mas acabmos nunca terminando o arco dela. Gostamos da ambiguidade de Judith, mas parece que os jogadores não. O ódio por ela foi quase universal. Mas isso pode ser um sucesso: demos duro para fazer o jogador desenvolver afinidade por Alyx, e ela também não era lá muito fã de Judith."
N/A4117"#commentary\cn_202_d2_prison_05_start.mp3" "[ Yahn Bernier ] Podendo o jogador mover vários objetos, não raro enfrentávamos desafios, principalmente por conta das limitações das CPUs de 2003. Uma limitação era que nosso sistema de navegação de IA não tinha ciência de objetos físicos dinâmicos, como estas camas de metal. Embora o sistema de movimento de PNJ detectasse e evitasse objetos físicos ao se mover, eles eram invisíveis às sondagens de navegação necessárias ao planejamento estratégico pré-movimento. Isso era devido principalmente às limitações de desempenho. Não dávamos conta de nada mais complexo. Também enfrentamos desafios de design sem soluções claras — por exemplo, como um soldado responde se o jogador bloquear totalmente um corredor com um objeto grande? Para lidar com isso, demos aos PNJs força extra para empurrar os objetos. Depois, mitigamos o problema com o projeto da fase, alargando corredores e garantindo espaços vazios para lidar com adereços em qualquer lugar. Essa configuração trazia grandes riscos. A combinação de soldados escondidos atrás de camas com formigas-leão avançando para atacar de perto cria uma chance alta de interações esquisitas entre o sistema de movimento de PNJs e as camas."
N/A4118"#commentary\cn_203_alyx_as_companion.mp3" "[ Miles Estes ] Esta parte acabou virando sem querer o protótipo de um destaque do Episódio 1: Alyx como companheira, andando por um caminho que mescla combate dinâmico com coreografia roteirizada. Ainda não tínhamos um modelo claro de como ela se encaixaria ao lado do jogador nesses cenários, mas até esta parte curta nos ensinou muito, embora não tenhamos tido tempo suficiente para testá-la."
N/A4119"#commentary\cn_204_laundry.mp3" "[ Mike Dussault ] Quando o jogador chega a esta fase, conhecida como Lavanderia, temos confiança de que já se familiarizaram em usar a isca para resolver cenários de combate. Quisemos dificultar um pouco criando um cenário que encorajasse o jogador a se envolver mais, combinando a isca com todo seu arsenal."
N/A4120"#commentary\cn_205_side_zombie.mp3" "[ Quintin Doroquez ] Este zumbi venenoso sempre de destacou nos testes. Como o jogador está tão focado em soldados da Combine, formigas-leão e torretas, e sem ver o zumbi venenoso há tanto tempo, sua aparição repentina no escuro costumava criar um momento de choque."
N/A4121"#commentary\cn_206_flares.mp3" "[ Quintin Doroquez ] Esta parte é um ótimo contraponto ao segmento anterior das torretas em termos de iteração e custos de produção. Criada bem tarde, ela ficou pronta rápido, pois a IA de Alyx e dos soldados da Combine já estava madura. Gostamos da escuridão e dos clarões, e a arquivamos para explorar mais a fundo. Depois, a revisitamos ao planejar as partes escuras do Episódio 1."
N/A4122"#commentary\cn_207_magic_wall.mp3" "[ Robin Walker ] Como muitas arenas de combate, precisávamos de algum tipo de portão para o jogador não avançar antes de terminar a luta. Infelizmente, estávamos sem tempo e tínhamos que seguir para a Estação de Trem, então acabamos com esta palhaçada mágica: uma parede que simplesmente explodia depois que a segunda aeronave era derrotada, revelando o caminho a seguir. Nós nos convencemos de que a maioria dos jogadores não notaria, pois estaria ocupada enfrentando aeronaves, e nossos testes mostraram que, em geral, o jogador concluía a luta antes de chegar a este ponto. Com explosões suficientes por toda a arena, a parede em chamas destruída pareceu bem natural, então pusemos alguns quebra-cabeças de gás simples no outro lado para justificar, mas não ficamos muito orgulhosos, não."
N/A4123"#commentary\cn_208_ragdoll_vortigaunt.mp3" "[ Scott Dalton ] Esse vortilético morto transmite muito sofrimento... por parte dos projetistas. Na época, nossas ferramentas de desenvolvimento não permitiam posicionar um boneco diretamente, ou seja, quando um PNJ morria e caía de forma sistêmica como um boneco no chão, não tínhamos controle da pose em que terminaria. Se tivéssemos tempo com os animadores, eles poderiam criar uma animação de um quadro na pose que queríamos, mas estávamos atrasados e a equipe pequena de animadores estava sobrecarregada. Um projetista posicionou o vortilético acima desta cadeira e o programou para morrer assim que a fase carregasse para ver em que posição ele ficaria. Ele moveu ligeiramente o Vortilético e tentou de novo. Não lembro quantas tentativas foram, mas foi muito, muito mais do que você imagina."
N/A4124"#commentary\cn_209_nova_prospekt_process.mp3" "[ Eric Smith ] Como Ravenholm, Nova Prospekt foi projetada inicialmente com jogabilidade diferente da versão lançada. A primeira versão focava em combate entre jogador e soldados da Combine, sem envolvimento das formigas-leão. Ao contrário de outras áreas do jogo, em que arte e jogabilidade evoluíram juntas, Nova Prospekt recebeu muito conteúdo de arte no início. Isso produziu um conjunto de seções polidas e reutilizáveis de geometria de fase com a arte já aplicada. Montar Nova Prospekt com essas peças deu muito certo, pois a disposição da prisão era naturalmente repetitiva. Depois, quando voltamos com as formigas-leão e a isca, tivemos que adaptar a geometria para se encaixar na nova jogabilidade."
N/A4125"#commentary\cn_210_d2_prison_04.mp3" "[ Eric Kirchmer ] Durante o desenvolvimento, nossos artistas criavam fatias verticais de ambientes, que chamamos de zoológicos de arte. Eles definiam como usar texturas e adereços para criar espaços de jogo que serviam a nossos objetivos visuais. Contudo, ao criar a pista de jogo da prisão, a disposição repetitiva permitiu que usássemos a arte mais diretamente. Este mapa foi construído inicialmente como zoológico de arte primário para Nova Prospekt, mas, após ser usado para testar vários protótipos de jogabilidade, incluindo os que levaram à isca, ele virou parte da arquitetura da fase."
N/A4126"#commentary\cn_211_autosave_dangerous.mp3" "[ Dave Riller ] Em Half-Life 1, tínhamos vários salvamentos automáticos no jogo, colocados à mão pelos projetistas e ativados quando o jogador chegava a uma posição ou momento específico no jogo. Assim, o jogo era salvo automaticamente enquanto você atravessava os corredores de Black Mesa. Em Half-Life 2, precisávamos de uma nova ferramenta. Alguns confrontos duravam bastante tempo e traziam vários conjuntos de inimigos. Outros eram misturas longas e extensas de exploração e combate, sem separação clara entre cada parte. Não queremos um salvamento automático em que o jogador seja posto em perigo logo após carregar o jogo, pois poderia iniciar um loop de mortes. Se você jogou o suficiente antigamente, com certeza já viveu essa situação pelo menos uma vez. Então, a menos que colocássemos pausas no fluxo de toda arena, não havia uma forma segura de colocar um salvamento automático. Após alguns testes, implementamos o que chamamos de Salvamento Automático Perigoso. Era uma ferramenta de projetista que combinava salvamento automático com um tempo associado. Ao ser ativado pelo projetista, ele salvava o jogo na hora, mas em paralelo — não ficava disponível para carregar. Se o jogador sobrevivesse pelo tempo especificado, então o salvamento seria registrado como o salvamento automático mais recente. Assim, os projetistas podiam colocar um salvamento automático em um momento ou lugar razoável na arena, especificar algo como trinta segundos e, se o jogador sobrevivesse por esses trinta segundos, o salvamento automático seria usado."
N/A4127"#commentary\cn_212_we_dont_go_to_ravenholm.mp3" "[ Dario Casali ] Quando estávamos terminando Ravenholm, ficou a sensação de que a transição do Laboratório do Eli não estava boa. Era muito abrupta. O laboratório do Eli ligava direto às ruas da cidade, aonde você logo vai chegar, e o local onde você está não existia. Tínhamos acabado de fazer aquela promessa no final do laboratório — \"Nós não vamos mais para lá.\" — e gostamos da expectativa geral que criamos. Mas, quando chega a Ravenholm, o jogador logo entra em combate com zumbis, sem aumento gradativo da tensão. Então criamos esta parte e os corredores apertados subsequentes para criar essa tensão, e ficamos bem satisfeitos. Desaceleramos o ritmo, focamos na arte e na iluminação, e deixamos você prontinho para vivenciar o motivo pelo qual não vamos mais a Ravenholm."
N/A4128"#commentary\cn_213_lever_shenanigans.mp3" "[ Dario Casali ] Mesmo com tudo o que fizemos para criar uma conexão entre esta alavanca e a cerca elétrica do lado de fora, alguns testadores ainda mexiam na alavanca e não entendiam seu efeito. Eles ficavam perambulando pela área, às vezes reativando a alavanca no processo. Sem muito tempo para deixarmos a conexão ainda mais clara, decidimos fazer a alavanca quebrar. Assim, o jogador não conseguiria desfazer seu progresso, e ainda reforçava a sensação de que Ravenholm era um ambiente instável e decadente."
N/A4129"#commentary\cn_214_town_arenas.mp3" "[ Dario Casali ] A esta altura de Ravenholm, o jogador já aprendeu todos os elementos de jogo disponíveis e é capaz de prever as interações. Isso nos permite criar configurações mais complexas, fornecendo um nível maior de ameaça e mais liberdade na forma de lidar com cada cenário. Esta arena foi criada deliberadamente como um espaço entrelaçado que o jogador precisa explorar, e o tempo de exploração serve para aumentar gradativamente a intensidade do combate. Quanto mais rápido for a exploração, mais rápido aumentamos a intensidade. Por ser mais livre, a área foi difícil de refinar, considerando a variação dinâmica de como os jogadores passavam por ela."
N/A4130"#commentary\cn_215_mines.mp3" "[ Dario Casali ] A rota complexa que o jogador toma para navegar por essa parte da mina dá tempo de mostrar o que o aguarda lá embaixo. Para variar, são chupa-crânios. Sinceramente, quase sempre são chupa-crânios. Neste caso, são Chupa-crânios Venenosos, divertidos sozinhos, mas causam um caos total quando pareados com chupa-crânios rápidos. Esses dois formam uma dupla incrível. Nenhum é muito perigoso sozinho, mas juntos, são bem letais. Basta um golpe de um Chupa-crânios Rápido para matar um jogador envenenado. É isso que os biólogos chamam de simbiose. Pelo achamos que é."
N/A4131"#commentary\cn_216_poison_headcrabs.mp3" "[ David Speyrer ] Esta sala apresenta os chupa-crânios venenosos sem querer. Passamos muito tempo criando a apresentação deles num momento posterior, mas, quando vimos que estavam indo bem nos testes, ficamos tão empolgados que acabamos espalhando eles por toda a fase. Quando nos demos conta, eles apareciam antes da apresentação e era tarde para mudar. Felizmente, uma sala cheia de chupa-crânios venenosos serve como treino decente porque eles não trazem um problema comum de treinos de combate. Normalmente, o jogador fica estressado e frustrado quando morre várias vezes sem entender por quê. Obviamente, encontramos esse problema quando tentamos treinar o jogador com chupa-crânios venenosos juntos de sua fonte, o zumbi venenoso. No entanto, os chupa-crânios venenosos não conseguem matar o jogador sozinhos, então, embora seja estressante, uma sala cheia deles pelo menos evita essa frustração."
N/A4132"#commentary\cn_217_poison_zombie_introduction.mp3" "[ David Speyrer ] Prender o jogador em um lugar apertado com vista para uma área externa é uma forma útil de aumentar as chances de que ele veja algo que queremos que veja. Aqui, chamamos a atenção do jogador com um som agudo antes que o Zumbi Venenoso ficasse visível. Originalmente, este encontro também apresentava os Chupa-crânios Venenosos, mas, conforme mencionado em comentário anterior, ficamos tão empolgados em proliferar os Chupa-crânios Venenosos pela fase que acabamos estragando a apresentação conjunta dos inimigos aqui. No fim, esses primeiros encontros acabaram funcionando melhor em separado mesmo."
N/A4133"#commentary\cn_218_final_arena.mp3" "[ Eric Smith ] Quando terminamos a primeira fase de desenvolvimento de Ravenholm, este terraço era para ser a luta final. Assim como outros locais de Ravenholm, este nasceu com foco apenas em ser visualmente interessante. Achamos importante que, ao sair de Ravenholm, o jogador tivesse um momento para olhar a cidade à qual sobreviveu e ter um vislumbre de seu próximo destino. Vários grupos de projetistas tentaram criar uma batalha aqui, mas, dadas as limitações de geometria e desempenho, não ficamos satisfeitos com nenhum final que criamos. Assim como a própria saga de Half-Life, pareceu que Ravenholm estava destinada a ficar sem um final de verdade."
N/A4134"#commentary\cn_219_tables_and_bodies.mp3" "[ Ido Magal ] Perto do final da produção de Ravenholm, com todas as peças principais no lugar, tentamos preencher cada espaço vazio com alguma coisa interessante. Ao fazer isso, tivemos que tomar o cuidado de usar o que já tínhamos e não criar nada novo, pois não podíamos correr o risco de introduzir novos erros. Com frequência, como nesta sala, tentamos criar novos momentos de jogo que incluíssem mais detalhes e elementos narrativos à área. Cenas curtas como esta servem para o jogador atento pensar no que está vendo e no que ele pode encontrar no futuro."
N/A4135"#commentary\cn_220_physics_object_consistency.mp3" "[ Kerry Davis ] Todos os objetos físicos têm uma variedade de parâmetros que definem seu comportamento: massa, quantia de dano recebido antes de quebrar, o que acontece ao quebrar etc. Durante o desenvolvimento, esses parâmetros foram especificados pelos projetistas para cada item, e a maioria das coisas do jogo funcionava assim. Depois, percebemos que criamos um problema, pois havia milhares de objetos físicos no jogo e nenhum método que garantisse consistência entre eles. Como resultado, uma caixa de papelão pode quebrar com um tiro de pistola em uma fase e ser completamente indestrutível em outra. Internamente, chamávamos essas inconsistências de crimes de projetista de fase. Para lidar com eles e fazer justiça, criamos um sistema que forçava consistência em todos os objetos físicos com base em seu modelo visual. Como boa parte do jogo já estava construída, fomos obrigados a permitir que os projetistas abrissem uma exceção a esse sistema em casos extremos em que era necessário cometer algum crime para preservar o que haviam projetado. Internamente, chamamos esses projetistas de recidivistas, alguns dos quais perpetuam sua vida de crime na Valve até hoje."
N/A4136"#commentary\cn_222_fast_zombie_introduction.mp3" "[ Randy Lundeen ] Esta área também foi construída originalmente para a E3 de 2003, quando ela apareceu mostrando o jogador lutando contra soldados da Combine. Quando voltamos a ela para apresentar o Zumbi Rápido, tentamos preservar o máximo do trabalho prévio. Queríamos que a tomada épica sob o luar, com os zumbis pulando na frente da lua como lobisomens, chamasse a atenção do jogador. Passada essa pausa, apresentamos o primeiro Zumbi Rápido atacando o jogador. Foram necessários muitos testes para achar o equilíbrio de iluminação para a cena ficar bonita e ainda cumprir seus objetivos de jogabilidade."
N/A4137"#commentary\cn_223_ravenholm_gameplay_focus.mp3" "[ Mike Dussault ] Após assistir muitos testes de Ravenholm, sabíamos que o cerne de jogabilidade da fase teria relação com física e a arma de gravidade. Sabendo disso, achamos que dava para criar uma transição adequada para Ravenholm e ajudar o jogador a aprender e compreender parte de como seria a experiência seguinte. Isso acontece com frequência. Construímos a rota da fase, descobrimos o que funciona, e depois projetamos um prólogo. Criamos o conjunto seguinte de salas com essa preparação em mente. A brutalidade das ferramentas que oferecemos ao jogador ajudou a compor o clima almejado e a mudar o tom da segurança do Laboratório do Eli para uma coisa mais sombria e assustadora."
N/A4138"#commentary\cn_224_player_tools.mp3" "[ Steve Bond ] A esta altura do jogo, o jogador já tinha bastante experiência com a física de Half-Life 2, mas acabou de receber a arma de gravidade, que traz uma forma inédita de interagir com objetos físicos. Fizemos testes com vários objetos físicos com os quais o jogador podia brincar, como serras circulares, catapultas, latões explosivos, armadilhas, lanças etc. Aprimoramos os que funcionaram bem com a arma de gravidade e cortamos os outros. Depois, fomos limando os itens de munição para o jogador ser forçado a contar com esses objetos para sobreviver."
N/A4139"#commentary\cn_225_contrived_setups.mp3" "[ Kerry Davis ] Há um artifício bem óbvio em boa parte dos treinos com a arma de gravidade e os objetos físicos. O jogador arranca uma serra da parede com a arma e, na mesma hora, aparece um zumbi, praticamente implorando para levar a serra na cara. Depois o jogador rasteja por baixo de uma armadilha de lâmina para desligá-la e, de repente, aparecem três zumbis, incitando o jogador a religar a armadilha. Não tivemos muito tempo para testar esta parte, então precisávamos de configurações que servissem para todos os jogadores, não opções mais abertas que dependiam de o jogador realizar a ação \"certa\". Embora esse tipo de design tenha potencial para reduzir a criatividade, neste caso, vimos que os jogadores não se importavam com nossa condução um pouco mais direta."
N/A4140"#commentary\cn_226_misteaching_flinches.mp3" "[ Kerry Davis ] Outro teste memorável e exemplo dos perigos de ensinar algo errado ao jogador ocorreu em Ravenholm. Um de nossos princípios de design é que o jogo reaja o máximo possível ao jogador. Ao projetar a arma de gravidade, pareceu óbvio que, se o jogador a usasse contra um zumbi, algo deveria acontecer. Foi simples fazer a arma causar um dano pequeno ao zumbi e ativar uma animação de reação, que pareceu boa e responsiva. Depois, vimos um testador descobrir essa interação, assim que chegou a Ravenholm, e interpretar que a arma de gravidade estava causando dano ao zumbi... o que era verdade, mas era um dano bem baixo. O testador ficou repetindo essa ação por muito tempo até o zumbi morrer. É uma forma lenta, chata e desumana de lutar contra os zumbis, principalmente havendo tantas serras circulares e latões explosivos ao redor. Tendo aprendido a lição, tiramos essa animação, mesmo que isso implicasse perder a interação entre a arma de gravidade e os zumbis. Neste caso, foi melhor sacrificar essa interação simples em vez de passar a falsa impressão de que a arma de gravidade era eficaz para combater os zumbis. Até aos princípios simples, cabem exceções quando analisamos as minúcias de cada caso."
N/A4141"#commentary\cn_227_fire_trap.mp3" "[ Steve Bond ] Esta armadilha de fogo tinha como objetivo original mostrar o visual do sistema de fogo, mas um projetista acabou transformando-a em elemento de jogo em Ravenholm. Ela quase foi cortada várias vezes por conta do impacto no desempenho que a sobrecarga envolvida nos sprites transparentes tinha em PCs inferiores. No fim, um programador achou importante o bastante para ter o trabalho de resolver os problemas de desempenho e incluí-la no jogo."
N/A4142"#commentary\cn_228_hallway_cupboards.mp3" "[ Yahn Bernier ] Esses corredores entulhados foram uma solução simples para desacelerar o jogador. Com a limitação de preservar o máximo possível da geometria e tendo os zumbis lentos como inimigo principal, foi difícil impedir o jogador de passar correndo por aqui. Por sorte, foi fácil justificar esses passos graças ao Grigori, o morador maluco de Ravenholm. Fazia sentido ele bloquear a escada para ficar seguro no telhado. No fim, a nossa solução e a de Grigori eram a mesma: jogar um monte de móveis no caminho, pois, se eles detêm os zumbis, também devem retardar o jogador."
N/A4143"#commentary\cn_229_pacing_switch.mp3" "[ Steve Bond ] Agora que o jogador passou pela parte de treino, podemos começar a mudar o ritmo do jogo, de espaços claustrofóbicos atmosféricos para arenas de ação focadas em combate. Estando o jogador familiarizado com várias ferramentas de física do ambiente, podemos misturá-las com espaços abertos e dar a liberdade de o jogador escolher sua própria abordagem."
N/A4144"#commentary\cn_230_car_crushers.mp3" "[ Steve Bond ] Esses esmagadores de carros precisaram de ajustes e um bocado de trabalho no nosso sistema de dano de física. É sempre um desafio quando objetos físicos grandes interagem com Personagens Não Jogáveis. Por exemplo, se a física pode empurrar o PNJ, pode acabar jogando-o em algum lugar aonde ele não deveria ir, tornando-o irrecuperável. Isso não é um problemão para algo como um chupa-crânio, que pode simplesmente sair da situação com um salto, mas, se for tipo um zumbi, ele pode ficar preso e sem ter o que fazer, vai ficar se debatendo no vão onde conseguiu se enfiar. Isso meio que mata o clima de terror de sobrevivência que almejamos aqui."
N/A4145"#commentary\cn_231_car_crusher_lifts.mp3" "[ Eric Smith ] Fazer o esmagador de carros erguer o jogador também foi complicado. O jogador está sempre sendo simulado no sistema de física e no sistema de movimento do jogo. Cada vez que atualizamos o estado do jogador, comparamos os resultados dos dois sistemas e decidimos qual é o \"certo\", para só então sincronizarmos antes de repetir. Assim, os dois sistemas se influenciam, como quando o jogador sobe numa gangorra e a física faz a tábua ceder, ou quando ele fica em cima do esmagador de carros e é erguido. Embora seja mais complexo, usar dois sistemas foi mais fácil de refinar do que tentar lidar com a física e o movimento num único sistema. Mantendo-os separados, pudemos ajustar o sistema de movimento para que parecesse bom sozinho, reconciliando os dois apenas quando a física afetasse o jogador."
N/A4146"#commentary\cn_232_paint_cans.mp3" "[ Steve Bond ] Quando colocamos a física e a arma de gravidade como cerne da experiência de Ravenholm, começamos a passar pelas fases e procurar objetos que possam ter passado batido, pois estávamos focados em itens bem agressivos, como serras circulares e latões explosivos. Uma das coisas que encontramos foi a lata de tinta, e foi bem simples reforçar essa expectativa fazendo-as pintarem os zumbis de branco quando você jogava uma lata contra eles."
N/A4147"#commentary\cn_233_bringing_physics_to_the_enemies.mp3" "[ Tom Leonard ] As armadilhas de física em Ravenholm foram um dos primeiros elementos da fase com que ficamos satisfeitos, mas não colocavam o jogador como agente. Foram as serras circulares que nos ajudaram a chegar à essência de Ravenholm. Com as serras, o jogador podia levar a física aos zumbis, em vez do contrário. Quando entendemos isso, Ravenholm evoluiu rápido. Seguimos combinando elementos no mapa, procurando por qualquer coisa, principalmente algo incomum, que pudesse ser uma arma ou ferramenta para o jogador."
N/A4148"#commentary\cn_234_ravenholm_development.mp3" "[ Tom Leonard ] Começamos a desenvolver Ravenholm no começo da produção de Half-Life 2, então ela passou por mais de uma fase completa de desenvolvimento. A primeira versão era anterior à arma de gravidade, então focava em combate tradicional contra zumbis, com tiros e algumas armadilhas de física. A ideia era mostrar Ravenholm na E3 de 2002, mas o jogo acabou sendo revelado apenas em 2003. Àquela altura, tínhamos investido pesado na arte de Ravenholm, o que em geral evitamos até consolidarmos a jogabilidade. Quando voltamos a Ravenholm com a mecânica da arma de gravidade em mente, tivemos que mexer em boa parte da geometria pré-existente da fase que fora projetada com foco em um objetivo diferente."
N/A4149"#commentary\cn_235_grigori_plaza.mp3" "[ Steve Bond ] Esta praça é uma das áreas que recebeu detalhamento completo na primeira fase de desenvolvimento e, quando voltamos, quisemos preservar o máximo possível da arte enquanto projetávamos um novo caminho para o jogador que usasse as três dimensões, fazendo-o subir e descer, passar por janelas, telhados e de um prédio a outro. Não era um espaço grande, então tivemos que espremer o máximo que deu. Como a área começou tendo foco na arte, não tinha muita jogabilidade e precisávamos fazer os jogadores não passarem tão rápido por ela. Para piorar, ela já forçava nosso potencial de desempenho de renderização, mal havendo espaço para algo novo. O desafio foi achar coisinhas que desacelerassem o jogador, como ameaças a cada curva e em cada cantinho da fase. "
N/A4150"#commentary\cn_236_ravenholm_development_2.mp3" "[ Tom Leonard ] Quando os fãs falam de Half-Life 2, Ravenholm costuma ser a parte mais lembrada. Graças a suas várias fases de desenvolvimento e à densidade de material, mais membros da equipe são representados em Ravenholm que em qualquer outro lugar. Foi onde descobrimos como aplicar o processo artístico às cenas e à atmosfera que queríamos, foi como a física e o jogo se combinaram na arma de gravidade, foi como chupa-crânios e zumbis precisaram evoluir em Half-Life 2 e muito mais. Em retrospecto, Ravenholm confirma nossa crença em empoderamento individual em vez de design concentrado. É um lugar denso, muito eficaz em execução artística e jogabilidade, e é a soma de várias contribuições pequenas de indivíduos que compreenderam como podiam levar o jogo além com suas próprias capacidades."
N/A4151"#commentary\cn_237_playtester_archetypes.mp3" "[ Tom Leonard ] Iterações e testes normais foram a alma da produção de Half-Life 2. Toda semana, observávamos em silêncio atrás de um jogador passando pela parte em que estávamos trabalhando, tomando notas do que funcionava e do que não funcionava. Era importante testar com vários níveis de habilidade para sabermos que não estávamos tomando decisões que só funcionassem para alguns. Com o tempo, aprendemos a escolher o tipo de testador de acordo com a fase do desenvolvimento. No começo, usávamos jogadores experientes, em geral companheiros de equipe, que davam conta de áreas mais cruas e inacabadas e sabiam explicar melhor o processo de raciocínio. Para testar combate, usávamos jogadores de todos os níveis, principalmente os mais criativos no uso de ferramentas. Por fim, com a área mais polida, focávamos em iniciantes, pessoas que não jogavam muito ou que não estavam acostumadas com FPS. Mesmo que elas não fossem comprar o jogo, geralmente aprendíamos algo de valor ao observá-las."
N/A4152"#commentary\cn_238_the_real_final_arena.mp3" "[ Tom Leonard ] Bem no final do desenvolvimento de Half-Life 2, quando estávamos revisando o jogo inteiro para fazer as últimas melhorias, decidimos que queríamos, sim, um final de verdade para Ravenholm. A luta no terraço não bastava. Após alguma discussão, optamos por incluir esta luta final no cemitério com Gregori ao lado do jogador. Foi arriscado em termos de desenvolvimento, mas achamos necessário. Como estávamos perto do final da produção, dispúnhamos de ferramentas de jogabilidade amadurecidas e, melhor ainda, já compreendíamos nosso próprio jogo. Fazer um jogo costuma ser um processo de aprendizado sobre o que de fato você está criando. Por que o jogo é divertido? Como ele é diferente? Quais são os elementos mais importantes? Conforme criávamos o jogo e observávamos os testadores, descobrimos essas respostas e ficamos melhores em desenvolver o jogo. Assim, o cemitério ficou pronto bem rápido e precisou de bem menos iterações que muitas áreas anteriores do jogo."
N/A4153"#commentary\cn_239_cities.mp3" "[ Eric Kirchmer ] Um dos desafios mais complexos nesta parte foi pensar em como dar ao jogador a sensação de estar numa cidade extensa com limitações de desempenho que não nos permitiam renderizar nada parecido. Isso nos levou a focar em cortiços apinhados, estacionamentos subterrâneos, túneis de metrô, dutos de drenagem e coisas do tipo. Todos lugares urbanos, mas que costumam bloquear o horizonte. Depois, complementamos esse estilo de projeto de fase com locais com vistas, onde todo o espaço seria dedicado a fornecer uma visão expansiva ao jogador. Nesses lugares, podíamos dedicar todo nosso orçamento de desempenho a essa vista, sem precisar poupar nada para combate ou IA de inimigos."
N/A4154"#commentary\cn_240_strider_4.mp3" "[ Eric Smith ] Embora este mapa tenha sido o mapa de produção criado para o Trípode, ainda tínhamos um mapa de desenvolvimento original para testar sua IA. Valorizamos um mapa de testes sólido para uma IA, pois nos permite experimentar novas ideias de jogo e ajustá-las facilmente. Se houver erros ou problemas de design, podemos isolá-los e iterá-los mais rápido. Quando os recursos de IA estão funcionando bem, transplantamos para os mapas de produção para os projetistas de fase trabalharem. O mapa de teste do Trípode incluía esboços crus de prédios em ruínas, com geradores de cidadãos infinitos em vários locais e alturas para fornecer um fluxo constante de alvos. Essa configuração nos permitiu refinar as mudanças de postura e a IA do Trípode para deixá-lo envolvente, mesmo que apenas para ficar vendo ele em ação."
N/A4155"#commentary\cn_241_perf_arena.mp3" "[ Aaron Seeler ] Esta arena trouxe um grande desafio: desempenho. O tamanho dela e as IAs do Trípode e dos cidadãos forçaram os limites. Quando portamos Half-Life 2 para o Xbox, esta arena precisou de ajustes de design. Preservar a intenção original e entregar a mesma experiência ao jogador com menos ferramentas e espaço foi um equilíbrio difícil."
N/A4156"#commentary\cn_242_space_re-use.mp3" "[ Chris Green ] Voltar a este espaço trouxe várias vantagens. A primeira e mais óbvia é que os custos para produzir áreas novas é sempre alto, então criar jogabilidade nova em áreas pré-existentes é sempre bom. Mas, em uma luta difícil como esta, onde o jogador enfrenta vários Trípodes, o reúso tem benefícios extras. Como já passou por aqui, o jogador tem noção do layout da arena. Desta vez, ele faz o sentido inverso, mas o caminho segue boa parte da rota original. Essa familiaridade é útil quando o jogador precisa avançar para coletar recursos para a luta. Como a Cidade 17 foi assolada pela guerra, temos flexibilidade para ajustar coberturas e obstáculos menores pelo caminho, deixando o ambiente dinâmico e surpreendente."
N/A4157"#commentary\cn_243_tenements_and_courtyards.mp3" "[ Danika Rogers ] Usamos muitos truquezinhos e criamos vários recursos para passar a impressão de uma cidade em guerra. Boa parte do esforço focava em mostrar vislumbres de batalhas ou sons de luta distante. Os OlharAlvo ajudaram a fazer algo acontecer toda vez que um jogador olhava por uma janela, enquanto ferramentas como Criadores de Traçado permitiam que os projetistas criassem tiros falsos traçados entre dois pontos. Combinado com ferramentas de áudio, deu a impressão de dois grupos de inimigos trocando tiros, sem precisar rodar nenhuma IA. Também desenvolvemos pequenas linhas narrativas para os grupos de cidadãos que o jogador via várias vezes ao avançar pela fase. Todos esses momentos foram ajustados com vários testes para que o máximo de jogadores os vivenciasse."
N/A4158"#commentary\cn_244_hopper_mine_training.mp3" "[ Dario Casali ] Esta placa de metal enrugado foi colocada de propósito no buraco para encorajar o jogador a usar a arma de gravidade para remover o obstáculo. É um pouco de manipulação de nossa parte porque achamos que treinar o jogador com a mina saltadora funcionava bem melhor se ele tentasse usar a arma de gravidade nela imediatamente, e a placa de metal aumentava significativamente a chance de ele estar com a arma de gravidade pronta. Colocamos várias minas no buraco para o jogador ter várias oportunidades de interagir com elas, aumentando a chance de descobrir formas alternativas de se livrar delas. Além disso, é a primeira vez que treinamos o jogador na companhia de um esquadrão de cidadãos, então também aproveitamos essa oportunidade para incluir alguns diálogos sobre as minas saltadoras."
N/A4159"#commentary\cn_245_dog_combat.mp3" "[ Eric Kirchmer ] Dog é um personagem bem divertido e sempre buscamos formas de incluí-lo no combate ao lado do jogador. Contudo, acertar a escala do combate para ele — ambiente adequado, nova IA de inimigo e potencialmente até novos inimigos — logo ficou além do escopo do projeto. Para criar um cenário de combate que fizesse jus ao Dog e que se equiparasse ao resto do jogo, quase pareceu que estávamos criando um jogo novo dentro do jogo. Sabíamos que ele não podia simplesmente correr até um soldado e desferir um soco. Assim, ele impressionaria menos, não daria uma sensação de assombro. Ele precisava de ameaças maiores, de seu tamanho, bem como de formas interessantes de interagir. No fim, optamos por uma cena coreografada grandiosa que entregou os objetivos cinematográficos para Dog em um combate que não incorporasse muito design de jogo."
N/A4160"#commentary\cn_246_strider_2.mp3" "[ Eric Kirchmer ] Iterar no Trípode aqui finalmente trouxe a experiência com que ficamos satisfeitos, pois o jogador precisava correr entre coberturas, fugindo dos disparos enquanto catava mísseis. Queríamos que ele sentisse que chegava à cobertura no último segundo, então ajustamos o padrão de disparos do Trípode para sinalizar um perigo iminente. Também criamos um sistema de trilhas em que o Trípode pudesse alternar de forma dinâmica para perseguir o jogador ou estabelecer uma linha de visão. Essa configuração serviu para os projetistas alinhassem essas trilhas com as coberturas, culminando numa experiência equilibrada. O posicionamento da perna do Trípode era feito apenas por código, e seus movimentos imprevisíveis nos obrigou a ajustar várias coisas para garantir que ele chutasse um carro ou contêiner de tropas quando necessário."
N/A4161"#commentary\cn_247_manhack_tunnels.mp3" "[ Eric Smith ] Ao desenvolver comportamento de IA para um PNJ, era útil que um programador de IA tivesse um mapa onde pudesse fazer testes. Em geral, o mapa trazia um ambiente projetado especificamente para destacar as habilidades exclusivas do PNJ. Depois, quando a IA estava pronta para os projetistas de fase, o mapa de teste servia como ponto de referência. Sem ele, os projetistas poderiam acabar criando cenários que tiraria a graça de uma IA potencialmente interessante. Em alguns casos, incorporamos esses mapas de teste diretamente no jogo. Esta parte curta, por exemplo, começou como os túneis usados para desenvolver a IA do cortador."
N/A4162"#commentary\cn_248_sniper_streets_2.mp3" "[ Erik Johnson ] As balas em Half-Life 2 não seguem uma trajetória — elas chegam instantaneamente ao destino. Com o Franco-atirador, pela baixa cadência de tiro e atenção do jogador a cada disparo, quisemos simular a trajetória da bala. Essa abordagem também funcionou melhor com a mira a laser, com a mira piscando logo antes de a bala chegar, dependendo da distância. No entanto, essa mudança trouxe um novo problema: não queríamos que o jogador pudesse evitar os disparos correndo pela rua, então o atirador precisava calcular o movimento do alvo, prevendo onde a bala precisava atingir. Prever a posição do jogador foi complicado, pois ele pode mudar de direção bem mais rápido do que seria possível na vida real, então incluímos verificações extras para captar alguns comportamentos, como o jogador oscilando entre direita e esquerda rapidamente ao correr."
N/A4163"#commentary\cn_249_triangle_plaza.mp3" "[ Ido Magal ] Esta batalha na praça foi uma configuração complexa usando o comportamento Assalto com duas linhas de batalha convergentes, uma para cada campo de força. As linhas de batalha impediam que os soldados que entravam de trás desses campos corressem para a praça. Conforme a luta crescia e mais soldados chegavam, as linhas de batalha andavam rumo ao centro da praça, e isso sufocava o jogador caso ele não repelisse os soldados."
N/A4164"#commentary\cn_250_sniper_streets_3.mp3" "[ Jakob Jungels ] Um recurso que experimentamos nestas ruas foi o tiro de supressão. Muitos jogadores encurralados no final da rua tentavam disparar contra a janela de um Franco-atirador para ver se surtia algum efeito. Tentamos fazer a mira a laser piscar brevemente, dando um tempinho para o jogador se realocar, mas, após alguns testes, encontramos dois problemas. O primeiro foi que quebrava a mecânica tensa de avançar e se esconder que queríamos criar com o Franco-atirador. Correr e atirar não era diferente de outras ações que exigimos na Cidade 17. O segundo, mais sutil, foi que o jogador que descobria o tiro de supressão rápido presumia que era um requisito e gastava munição rápido. Se ficasse sem na metade do caminho, achava que tinha fracassado; se concluísse, acabava ficando sem munição. Por outro lado, o jogador que concluía o cenário apenas com furtividade praticamente não gastava munição. Esta discrepância de recursos entre as abordagens praticamente impossibilitava um equlíbrio de munição nas seções seguintes, então acabamos cortando do jogo."
N/A4165"#commentary\cn_251_assault_behavior.mp3" "[ John Cook ] O comportamento mais complexo que criamos para Half-Life 2 foi o Assalto, que é usado em toda esta parte do jogo. Ele permitiu que os projetistas de fase montassem cenários de combate com soldados da Combine e cidadãos, estabelecendo linhas de batalha entre eles e controlando o fluxo dessas batalhas com base nas ações do jogador. Os PNJs envolvidos no Assalto tentavam encontrar posições inteligentes de tiro e usar cobertura com base no local da linha de batalha. Conforme avançava pela rua, o jogador podia empurrar a linha de batalha para a frente, fazendo aliados avançarem e inimigos recuarem. Em outros casos, o jogador podia ter que derrubar torretas da Combine ou abater um soldado atrás de uma barricada para fazer a linha de batalha avançar."
N/A4166"#commentary\cn_252_bank_roof_mortar.mp3" "[ John Morello ] Quando chegamos a este ponto da construção da fase, era óbvio que seria divertido para o jogador usar o morteiro. Acho que devíamos ter pensado nisso antes. \"Acha que alguém vai querer lançar explosivos no céu para eles caírem nos vilões? É, eu também acho.\" Os jogadores passaram todo esse tempo só recebendo os morteiros, então seria uma boa recompensa dar pra Combine um pouco do próprio remédio. Assim que começamops a pensar, nos demos conta da quantidade de trabalho envolvida — para ser sincero, é um pensamento que temos todo dia quando decidimos fazer um jogo. O morteiro precisaria de animações e efeitos, já que agora o jogador estava próximo, e daria muito trabalho implementar uma intensificação adequada dos inimigos na praça para servirem de alvo. Mas, ainda mais fundamental, não tínhamos interface para uma arma tão única. Como seria para mirar e disparar? É difícil se animar com a ideia de gastar muito tempo num momento breve no jogo, então achamos melhor investir tempo em outro lugar e seguimos em frente. Foi mal! Talvez a gente resolva esse dilema de design do morteiro num jogo futuro da série Half-Life."
N/A4167"#commentary\cn_253_strider.mp3" "[ Kerry Davis ] Esta área na frente do Banco foi onde resolvemos o Trípode. Quando vimos a arte conceitual pela primeira vez, logo quisemos incluí-lo no jogo, mas havia muita dúvida quanto à forma que ele funcionaria na prática. Nunca movemos nada desse tamanho no mundo do jogo e, naquela escala, ele tinha que ser perigoso, mas como o jogador o enfrentaria? Assim como todos os nossos inimigos, sempre havia dúvidas quando à jogabilidade que sairia dele. De que tipos de ferramentas os projetistas precisariam para criar cenários com ele? Foram essas perguntas que quisemos responder em nossos experimentos com este mapa."
N/A4168"#commentary\cn_254_sniper_streets.mp3" "[ Eric Kirchmer ] Estas ruas cheias de franco-atiradores foram onde desenvolvemos o inimigo e o cerne da experiência que pensamos para o jogador. Sabíamos que queríamos que o inimigo atirasse em coisas próximas ao jogador, então primeiro procuramos vários alvos interessantes. Achamos que funcionou usar a visão do jogador como fator para selecionar os objetos. A mira a laser sempre ligada do Franco-atirador era um indicador constante da atenção do inimigo no jogador, então fazê-lo mudar de alvo para coisas que o jogador estava vendo pareceu bem responsivo e criou ótimos momentos de tensão."
N/A4169"#commentary\cn_255_citizen_squad_details.mp3" "[ Matt Wright ] Quando estabelecemos o esquadrão de cidadãos do jogador e começamos a construir cenários em torno dele, vimos que ele criava outras oportunidades interessantes. Os testadores passaram a se afeiçoar a membros específicos do esquadrão, então aprimoramos o design deles. Os membros pegavam armas melhores se as encontrassem, passavam munição, e os médicos até curavam o jogador. Também tivemos que fazer o esquadrão acompanhar o jogador, que não raro rumava por caminhos imprevisíveis. Fora da câmera, o esquadrão \"trapaceava\" de várias formas: regenerando vida entre as lutas, andando rápido para alcançar os outros e até se teletransportando caso necessário."
N/A4170"#commentary\cn_256_citizen_squads.mp3" "[ Ken Birdwell ] Os primeiros testes com as lutas na rua entre Combine e cidadãos revelaram um problema: sem limitações, a IA de combate podia se distanciar bastante do jogador. Os soldados talvez recuassem para recarregar ou procurar cobertura, e a IA dos cidadãos poderia mandar persegui-los. Precisávamos de uma forma de alinhar as ações dos cidadãos aos objetivos do jogador, deixando-os cientes do destino e dos alvos do jogador. Isso levou à criação de um esquadrão de cidadãos do jogador. A IA dos cidadãos usava esse esquadrão para caminhar com o jogador, atacando os mesmos inimigos e fornecendo uma interface básica para os comandos do jogador. De início, tínhamos um sistema de comandos mais complexo, mas ele logo ficou difícil de manejar, então o reduzimos."
N/A4171"#commentary\cn_257_ai_behaviors.mp3" "[ Mike Dussault ] Uma tecnologia de IA que desenvolvemos para Half-Life 2 foi o sistema de Comportamento. Os comportamentos são blocos de código de jogabilidade de IA que guiam os PNJs em situações específicas. Por exemplo, tínhamos o comportamento Liderar, que permitia que um PNJ guiasse o jogador, e um comportamento Seguir fazia o PNJ seguir o jogador ou outro PNJ. Os comportamentos atuavam em paralelo às ações básicas do PNJ, então um Médico do esquadrão com o comportamento Seguir ainda saberia atirar no inimigo, se esquivar de granadas e oferecer um kit médico."
N/A4172"#commentary\cn_258_occlusion.mp3" "[ Brian Jacobson ] Em Half-Life 1 e em boa parte de Half-Life 2, o mundo consistia principalmente em corredores e túneis fechados, o que funcionava bem com Particionamento de Espaço Binário, ou árvore BSP. Essencialmente, essa tecnologia permitia resolver a geometria rapidamente e determinar o que estaria visível ao jogador. Já em áreas abertas como a Costa, essa abordagem não servia, então precisávamos de uma tecnologia nova. Portais de área foram uma, permitindo que criássemos o mundo em blocos separados por portais — portas e janelas mesmo, nada a ver com a Aperture Science. Também desenvolvemos um sistema de oclusão extra, que basicamente dizia que, se o jogador não consegue ver atrás, por cima ou ao redor de um objeto grande, não renderize o que está do outro lado. Pode parecer óbvio, mas dá um trabalho saber se calcular o que está atrás do objeto grande não acaba sendo mais lento que só renderizar tudo. Para acelerar o cálculo, os projetistas colocaram grandes volumes de oclusão dentro de formas maiores do terreno e objetos de oclusão grandes, como prédios. Durante a renderização, pudemos testar os limites das entidades em relação a esses volumes para não renderizar nada que o jogador não pudesse ver."
N/A4173"#commentary\cn_259_detail_objects.mp3" "[ Brian Jacobson ] Quando rodamos as áreas externas, ficou claro que elas precisavam de detalhes de alta frequência, então incluímos pequenos elementos de vegetação pelo terreno, como grama e arbustos. Sabíamos que não dava tempo de colocar esses elementos manualmente, então criamos o sistema de objetos de detalhe, que gera pequenos elementos de vegetação automaticamente com base no material de deslocamento. Cada material especifica o tipo de vegetação a colocar e um conjunto de parâmetros. Na hora de compilar o mapa, o sistema calcula pontos aleatórios na superfície e seleciona a vegetação. Considerando as limitações de desempenho, ainda houve um processo manual relativamente complexo para criar lâminas de textura da vegetação, permitindo que renderizássemos tudo de uma só vez."
N/A4174"#commentary\cn_260_displacements_1.mp3" "[ Charlie Brown ] Após lançar Half-Life 1, nossos projetistas e artistas quiseram uma solução melhor para ambientes externos, então construímos a primeira versão do nosso sistema de terreno, que era subdividido em quadrantes. Imagine um quadrado plano dividido em uma grade, cujos pontos podem ser movidos para cima ou para baixo. Os projetistas colocavam vários quadrados e ajustavam os pontos da grade para dar forma a morros e vales. Na renderização, usávamos uma textura mesclada especial que combinava duas texturas diferentes. Cada ponto da grade especificava quanto de cada textura usar para criar transições suaves entre superfícies como areia, grama, terra e cascalho. Esse tipo de sistema de terreno não era incomum nos motores de jogos da época e fomos ingênuos de pensar que bastaria para os nossos projetistas."
N/A4175"#commentary\cn_261_displacements_2.mp3" "[ Charlie Brown ] Quando o sistema de terreno inicial estava funcionando, esperávamos que os projetistas o usassem para ambientes externos, mas eles começaram a fazer testes, pondo detalhes em locais inesperados. Eles usaram os quadrantes subdivididos no topo de muros para criar beiras dilapidadas, meios-fios arredondados e até tentaram fazer canos. O grau de sucesso variou, pois o sistema era projetado para paisagens, não para detalhes arquitetônicos. Voltamos a trabalhar no código, transformando o sistema baseado em altura em um sistema de deslocamento totalmente 3D. Em vez de mover os pontos da grade apenas para cima ou para baixo, os projetistas os moviam em qualquer direção, permitindo pôr mais detalhes em todo tipo de superfície, com texturas mescladas para suavizar transições entre quadrantes de deslocamento e geometria BSP. No entanto, isso exigiu mais trabalho técnico para que a iluminação ficasse consistente entre os dois renderizadores, senão essas beiras ficariam nitidamente incompatíveis. Os projetistas pareceram satisfeitos e fomos ingênuos na época de pensar que bastaria."
N/A4176"#commentary\cn_262_displacements_3.mp3" "[ Charlie Brown ] Com o sistema de deslocamento geral pronto, os projetistas não pararam de pôr detalhes no mundo e voltaram a seus objetivos originais de construir grandes áreas externas. Isso levou a outra rodada de atualizações para equilibrar o desempenho e garantir que o sistema cuidaria dos pequenos detalhes e do terreno grande. A texturização também precisava melhorar, principalmente para dar suporte a estruturas complexas como penhascos pendentes, que não eram possíveis com o sistema baseado em altura. Os projetistas, que não descansam quando têm sucesso, também começaram a usar os deslocamentos para criar cavernas e túneis. Embora parecesse ótimo, tudo isso demandava mais ajustes técnicos. Acabamos conseguindo dominar os requisitos conflitantes de todas as formas que os deslocamentos eram usados, e utilizamos em partes grandes do mundo do jogo. Em retrospecto, os deslocamentos são um exemplo claro de como tecnologia e design de jogo evoluem juntos. É o problema do ovo e da galinha: não podemos prever todas as formas como uma tecnologia terá impacto no jogo, mas também não podemos construir tecnologia sem saber do que ela precisa dar conta, então, como sempre, temos que começar construindo alguma coisa. Começamos com um chute embasado e vemos aonde ele nos leva."
N/A4177"#commentary\cn_263_particles.mp3" "[ Chris Green ] Com o motor Source, investimos em tecnologias de expansão de partículas e efeitos especiais, o que permitiu um movimento de partículas mais complexo e realista, bem como efeitos de sombreador e formatos mais detalhados. O mapeamento de colisões de nossas partículas fez uma diferença gritante em sua aparência volumétrica. Embora versões posteriores do Source incluíssem um editor de sistema de partículas poderoso, a versão original de Half-Life 2 dependia de efeitos feitos à mão, ou seja, cada um exigia que um programador construísse o efeito manualmente com todo o cuidado. Foi um processo bastante árduo."
N/A4178"#commentary\cn_264_cubemaps.mp3" "[ Chris Green ] Com a adição de materiais e sombreadores, precisávamos de uma solução para superfícies refletoras como vidro e aço. Elas precisavam saber o que refletir, mas, em 2003, não dava para renderizar nada disso em tempo real. Então desenvolvemos um sistema de mapeamento em cubo para reflexos pré-computados. Trata-se de um conjunto de seis imagens dentro de um cubo, capturando o ambiente em cada direção, como uma foto panorâmica que captura todos os lados. Os projetistas colocaram entidades marcadoras invisíveis em todas as fases e, durante a compilação de mapa, geramos um mapa cúbico em cada marcador. Depois, ao renderizar uma superfície refletora, localizamos o mapa cúbico pré-computado mais próximo para criar o reflexo."
N/A4179"#commentary\cn_265_water_shader.mp3" "[ Gary McTaggart ] O sombreador mais complexo do jogo foi o da água, que usava todos os recursos das novas placas de vídeo programáveis disponíveis. Quando havia água, a cena era renderizada três vezes: primeiro, a refração do mundo subaquático; segundo, uma visão refletida; e terceiro, as partes acima da água. Ao renderizar a superfície da água, mesclamos as visões refratora e refletora, mostrando mais os reflexos em ângulos de visão com a equação de Fresnel. Também acompanhávamos a profundidade da superfície até o chão, deixando a água mais transparente e menos refratora nas partes mais rasas. Além disso, tivemos que criar duas técnicas alternativas de renderização da água para placas de vídeo menos potentes: GPUs medianas exibiam os reflexos com pouco detalhe, sem refração ou transparência, enquanto as menos potentes só renderizavam uma superfície parcialmente transparente."
N/A4180"#commentary\cn_266_normal_maps.mp3" "[ Gary McTaggart ] Half-Life 2 foi desenvolvido em uma época empolgante para os gráficos, pois as primeiras GPUs com suporte a sombreadores programáveis estavam chegando ao mercado. Com essa tecnologia, produzimos um dos primeiros jogos a usar mapas normais, uma técnica que aprimora a iluminação na geometria de superfícies. O mapa normal descreve a rugosidade da superfície para que cada pixel do polígono se ilumine de forma a deixar a superfície mais irregular e detalhada do que jamais foi em Half-Life 1."
N/A4181"#commentary\cn_267_rendering_systems.mp3" "[ Gary McTaggart ] No início dos anos 2000, não podíamos pagar por um renderizador de uso geral com as capacidades amplas de um motor moderno. As limitações de CPU, GPU e memória demandaram soluções bastante específicas para desafios de renderização para que pudéssemos tirar o máximo proveito do hardware do jogador. Como resultado, Half-Life 2 tem três renderizadores diferentes: um para a geometria do mundo, outro para terreno externo, e um terceiro para entidades dinâmicas, como objetos e personagens. Esses três renderizadores precisavam dar conta de uma matriz complexa de recursos: colisões, traçado de raios, decalques, iluminação offline, cálculos de visibilidade e muito mais. Além disso, cada renderizador precisava dar conta de DirectX 7, 8 e 9. As diferenças entre essas versões de DirectX eram significativas e exigiam diferentes abordagens para renderização e armazenamento de dados. Elas até usavam linguagens de programação diferentes! Basicamente, tínhamos nove renderizadores diferentes, cada um com suas soluções. Deixar todos consistentes foi um dos maiores desafios técnicos que enfrentamos."
N/A4182"#commentary\cn_268_dynamic_shadows.mp3" "[ Gary McTaggart ] Como focávamos nos personagens e nos objetos com física, sentimos a necessidade de um sistema de sombras para renderizar tudo da melhor forma possível. Em 2003, as GPUs não tinham o sistema dedicado para as sombras que existe hoje, então desempenho era um problema. Nossa solução acabou sendo algo assim, executado a cada quadro. Primeiro, encontrávamos todos os objetos dentro da visão que poderiam ter sombra. Assim, era possível determinar quais objetos estavam no frustum da visão, ou ligeiramente atrás dele, para capturar entidades fora da tela, mas cuja sombra pudesse aparecer. Depois, renderizávamos uma versão com sombra preta de cada um desses objetos em uma única textura de sombra, usando o modelo com menor nível de detalhe do objeto para ser o mais rápido possível. Por fim, usávamos a textura de sombra para desenhar cada sombra na visão do jogador, escurecendo os pixels já renderizados. Recortávamos meticulosamente ao redor de cada sombra nessa textura de sombra para que ficassem corretamente sobrepostas, caso várias sombras se cruzassem. É legal olhar como fazíamos essas coisas, mas estamos muito mais satisfeitos hoje que o hardware de GPU deixa esse problema muito mais simples."
N/A4183"#commentary\cn_269_combinatorial_shader_explosion.mp3" "[ Gary McTaggart ] A renderização ficou muito mais complexa durante o desenvolvimento de Half-Life 2 com a adição de sombreadores de hardware — bloquinhos de código que controlavam a renderização de cada pixel de uma superfície. Em 2003, os sombreadores eram bem mais limitados. Os sombreadores da época de Half-Life 2 careciam de condicionais e tinham restrições graves de tamanho de código. Ou seja, nada de lógica if/else para se adaptar às condições, e nada de sombreadores com muitos recursos. Fora isso, compilar sombreadores conforme o necessário demorava muito, então tínhamos que pré-compilar. Para trabalhar com essas limitações, tínhamos que computar toda combinação de sombreadores possível e armazenar cada uma em separado. Por exemplo, se um sombreador afetava uma superfície com uma fonte de luz, precisaríamos de outro para duas fontes de luz, para três fontes etc. E era combinatório. Se o sombreador suportasse um mapa normal, precisaríamos de duas versões por luz: uma com o mapa normal e outra sem. Com recursos como mistura de texturas, coloração por vértice, realces especulares, teste de alfa e outros tipos de luz — direcional, pontual, holofotes —, nossa contagem de sombreadores explodiu. No lançamento, tínhamos milhares. Logo depois, lançamos Lost Coast, com suporte a HDR, e esse número dobrou. Quando a compilação de sombreadores nas máquinas locais dos desenvolvedores começou a demorar demais, passamos a distribuir a compilação por toda a rede usando o VMPi. Também tínhamos um modo de compilação dinâmica de sombreadores, útil para o desenvolvimento, que permitia uma resposta rápida ao custo de travadinhas na taxa de quadros quando um deles precisava ser compilado."
N/A4184"#commentary\cn_270_gpu_wild_west.mp3" "[ Jay Stelly ] Durante o desenvolvimento, encaramos muitas decisões relativas à nossa escolha para os requisitos mínimos — a combinação menos potente de CPU e GPU que entregaria uma boa experiência para o usuário. No início dos anos 2000, havia muito mais variedade de GPUs que hoje, com diferenças não só de velocidade, mas também de abordagens de renderização. Naquela época, não tínhamos dados reais do hardware que nossos clientes usavam. Que CPUs e GPUs eles tinham? Quanto de RAM? Que versão do Windows? Entramos em contato com a Microsoft para obter respostas a perguntas como \"Há quantas placas com DX7 em uso? E com DX8?\". Infelizmente, eles também não tinham esses dados. Sabendo do risco de tomar decisões ruins sem essas informações, desenvolvemos uma ferramenta de análise que permitia que os jogadores nos informassem os dados de sua máquina e a integramos à versão antiga do Steam. Os dados foram tão úteis que decidimos tornar a ferramenta pública, lançando a Pesquisa de Hardware do Steam em abril de 2003. Desde então, ela nos ajuda a tomar decisões embasadas, e espero que ajude outros desenvolvedores também."
N/A4185"#commentary\cn_271_3d_skybox.mp3" "[ Jay Stelly ] Sempre quisemos renderizar um mundo que parecesse maior que o permitido por nossas limitações de mapa. Em Half-Life 1, usamos uma textura de mapa de cubo para o jogador ver além da área de jogo. Já em Half-Life 2, queríamos que essa visão do mundo expandido fosse dinâmica, não só uma textura estática. Nossos limites de tamanho de mapa eram de cerca de meio quilômetro em cada dimensão, mas notamos que poderíamos criar um mundo externo bem maior se o armazenássemos em escala reduzida, então inventamos o que chamamos de 3D Skybox. Trata-se de uma caixinha escondida no mapa do jogo contendo geometria em escala 1:16. Dentro, um ponto de referência corresponde a uma origem no mapa principal. Quando renderizamos o espaço além da área de jogo, usamos a geometria do 3D Skybox, posicionamos pelo ponto de referência e o escalonamos 16 vezes maior. Houve desafios complexos para fazer a luz e a névoa se mesclarem em toda a transição do mapa principal ao skybox, mas deu certo. O resultado fez o mundo parecer bem maior e mais imersivo que em Half-Life 1."
N/A4186"#commentary\cn_272_missing_material.mp3" "[ Jay Stelly ] No início do desenvolvimento de nosso código gráfico de baixo nível, percebemos que seria difícil notar polígonos não renderizados por não terem textura. Quando isso ocorria, você geralmente veria preto onde o polígono deveria estar, e isso passava batido em cenas mais escuras. Para notar esse erro de forma consistente, criamos uma textura de erro inconfundível visualmente e que era gerada automaticamente sempre que uma textura não carregava. Foi assim que surgiu a famosa textura xadrez preta e roxa, que, desde então, assumiu vida própria e foi além de Half-Life 2."
N/A4187"#commentary\cn_273_air_resistance.mp3" "[ Jay Stelly ] Um recurso importante que tivemos que incluir no nosso motor de física de Half-Life 2 foi a resistência do ar. Na época, os motores de física costumavam implementar um recurso de amortecimento geral para desacelerar objetos em movimento, mas isso só remove a energia de forma simétrica. Para criar um movimento mais crível, decidimos simular a resistência do ar. Assim, pudemos criar um comportamento assimétrico, fazendo a desaceleração de um objeto se movendo pelo ar ser proporcional à superfície do objeto no sentido do movimento ou rotação. Esse recurso foi essencial para as explosões e objetos lançados pela arma de gravidade serem críveis. Objetos que se movem rápido ou giram rápido estão entre as coisas que mais consomem recursos para simular com o motor de física de Half-Life 2, então a resistência do ar também melhora o desempenho da CPU em casos como explosões. Ela também é crucial para apresentar diferentes materiais e massas de objetos. Os mais densos deslocam o ar com mais facilidade, e isso é visível. Ter esse efeito na simulação ajuda a evidenciar a diferença entre caixas de papelão e pranchas de madeira, o que ajuda a deixar os objetos do mundo de Half-Life 2 bem mais convincentes."
N/A4188"#commentary\cn_274_early_tech_planning.mp3" "[ Ken Birdwell ] Publicar um jogo sempre ensina muito. Finalmente descobrimos quais decisões foram acertadas e quais deveríamos abordar de outra forma na próxima vez. Após Half-Life 1, quando começamos a pensar em que tipo de sequência poderíamos criar, tínhamos vários feedbacks diferentes dos jogadores para digerir. A partir daí, tentamos construir um listão com tudo que seria foco de Half-Life 2. Não tentamos projetar uma experiência específica para o jogador. Em vez disso, achamos mais útil abordar a questão de um ponto de vista tecnológico. Os cientistas e seguranças de Black Mesa haviam funcionado bem. O que seria possível se investíssemos pesado nos personagens? Gostávamos da narrativa interativa. O que poderíamos construir para conseguirmos fazer ainda mais coisas, com mais variedade? A exploração e interação em Black Mesa foram atraentes para os jogadores. Talvez com um sistema de física pudéssemos ir além? Em cada aspecto desse, tentamos imaginar a melhor versão possível, anos no futuro, e fazer o caminho reverso pelos passos tecnológicos que levariam até lá."
N/A4189"#commentary\cn_275_character_lighting.mp3" "[ Ken Birdwell ] No primeiro ano de desenvolvimento, penamos tentando deixar os personagens tão realistas quanto queríamos. Havia diversos problemas, e todos acabaram precisando de uma melhoria artística ou tecnológica para resolver. O primeiro grande problema foi a iluminação. Na época, a iluminação em jogos tomava muitos atalhos, fosse por desempenho ou por falta de compreensão. Para deixar os personagens com boa aparência na época, os modelos e texturas tinham que vir com soluções de iluminação embutidas, como sombras e brilho. Os personagens ficavam legais, mas pareciam muito personagens de videogame. Começamos a criar Alyx com essa abordagem porque era assim que se fazia. Usamos as soluções típicas e a iluminamos como uma atriz de cinema: basicamente como se houvesse uma luz seguindo ela para garantir boa aparência. Mas não deu muito certo. Pela variedade de ambientes de iluminação e pela natureza dinâmica dos videogames, ela ficava ótima em alguns ambientes, mas sempre acabava ficando nada realista em algum momento. Tentamos iterações com a iluminação, aumentando suas capacidades, mas acabamos num beco sem saída. Então decidimos tentar uma abordagem diferente. Jogamos tudo fora e construímos ela, a iluminação e as texturas do zero, focando não em como queríamos que fosse sua aparência em condições ideais de luz, mas em como deveria ser no mundo real. Pode parecer óbvio, mas não se fazia assim, pelo menos não em videogames. Quando víamos fora do renderizador do jogo, esses modelos e texturas na verdade tinham uma aparência pior que as versões anteriores, mas fomos eliminando metodicamente cada atalho e equívoco sobre luz, textura e funcionamento da placa de vídeo, para enfim reconstruirmos tudo. Quando finalmente pudemos ver Alyx no jogo, com seus modelos e texturas novos, em um ambiente dinâmico em que ela ficava sempre consistente, olha, ela ficou excelente. Totalmente perfeita e integrada ao mundo de Half-Life 2."
N/A4190"#commentary\cn_276_gamma_correction.mp3" "[ John Morello ] Nosso motor de jogo tem um sistema de renderização responsável por captar o estado inteiro do jogo e calcular um valor de cor para cada pixel na tela a fim de representar esse estado, mas o código e o software de terceiros também entram no cálculo desses pixels, como, por exemplo, o software e o hardware na GPU e no monitor. Em certo ponto, estávamos insatisfeitos com a aparência dos personagens. Eles pareciam de cera ou doentes, e a pele também estava errada. Passamos um tempo ajustando a iluminação, mas não conseguíamos fazer os personagens e o mundo ficarem bons. Por sorte, ainda tínhamos um renderizador de software com todos os recursos para rodar o jogo sem GPU, já que era uma época em que muitos jogadores ainda não tinham GPU. Vendo o jogo no renderizador, percebemos que a iluminação não tinha o mesmo problema. Então passamos um pente fino no nosso código para tentar descobrir onde o código de renderização estava errando ao trabalhar com uma GPU. Como não conseguimos, tentamos contato com as fabricantes de GPU, pedindo para conferirem se não estavam fazendo nada errado com os valores dos pixels que estávamos enviando. Foi o começo de uma longa jornada. Para resumir, levou quase 2 anos de comunicação com as fabricantes antes de as convencermos que estavam fazendo a correção de gama de forma incorreta na matemática básica de suas placas. Durante esse processo, até criamos um sistema que validava os valores de cor de um pixel individual por todo o processo de renderização. No fim, acabamos recebendo drivers novos das fabricantes e nossos personagens ficaram imediatamente com a aparência que deveriam, igual ao renderizador de software."
N/A4191"#commentary\cn_277_facial_technology.mp3" "[ Ken Birdwell ] Queríamos que o jogador se afeiçoasse aos personagens e, para ter uma chance de conseguir, sabíamos que era necessário investir muita tecnologia nos rostos dos personagens. É sabido que os humanos são programados para prestar atenção a rostos e ler de forma inconsciente todo tipo de informação. É uma meta altíssima e, se falhássemos, acabaríamos na verdade afastando o jogador dos personagens. Começamos fazendo muita pesquisa. Não foi animador. Os melhores exemplos que encontramos não chegavam perto de poderem rodar em tempo real, e os melhores que podiam ficavam longe da qualidade almejada. Queríamos que tivesse a aparência de um filme de animação, mas eles levavam horas para renderizar alguns quadros e eram lineares, feitos por até cem animadores, enquanto o nosso tinha que ser dinâmico, pois o personagem pode estar dizendo sua fala enquanto expressa no rosto uma reação às ações do jogador, e tinha que ser criado por apenas um punhado de artistas. Esses requisitos acabaram nos levando ao Sistema de Codificação da Ação Facial de Paul Ekman, um sistema dos anos 1970 que taxonomizava movimentos faciais humanos. Ele forneceu vocabulário para descrever movimentos faciais em nossos códigos e ferramentas, e uma meta enquanto projetávamos os rostos dos personagens. Tendo ele como base, começamos um processo de muitos anos para iterar como criamos os rostos e as cabeças dos personagens. Já haviam tentado reproduzir partes da obra de Ekman, mas nós queríamos usar ela toda. Ou seja, muito tempo gasto tentando descobrir como fazer cada pedacinho, tudo dentro dos limites de desempenho que tínhamos. Também passamos muito tempo olhando rostos de pessoas, tentando descobrir os detalhes extras que agregariam mais valor, como elasticidade da pele ou sombreamento nos dentes. No fim, embora não tenhamos feito tudo que queríamos, conseguimos fazer com que as partes que julgávamos mais importantes entregassem uma atuação de rosto convincente para os personagens."
N/A4192"#commentary\cn_278_eye_shader.mp3" "[ Ken Birdwell ] Outra parte crucial para os rostos dos personagens serem convincentes foram os olhos. Humanos são ótimos para ler olhos. Tem uma parte do cérebro dedicada a isso, inclusive para saber para onde alguém está olhando com base nos reflexos no globo ocular. Mas há várias sutilezas que importam. O olho não é esférico. O movimento da córnea distorce a pálpebra. O movimento dos olhos pode aumentar a chance de piscar. O olho não se alinha diretamente atrás da pupila. Todos esses detalhes podem parecer pequenos ou imperceptíveis, mas não tê-los prejudica a credibilidade do personagem. Trabalhamos nos olhos por muito tempo, iterando o modelo do globo ocular e o conjunto de feições aos pouquinhos. Algumas coisas precisaram de interfaces externas, como quais coisas no ambiente eram interessantes de olhar, enquanto outras foram automáticas, em um nível inconsciente da IA, como piscar —requisito óbvio, mas que confunde de forma sutil se sair errado. Os reflexos nos olhos tiveram um impacto significativo. Embora ocupem pouco espaço na tela, a diferença que faziam era enorme. Sabíamos que tínhamos terminado quando chegamos ao ponto em que, desligando o sombreador de olhos, o personagem parecia um boneco semelhante a um humano, mas nada convincente de alguma forma difícil de descrever; quando o ligávamos, de repente parecia que um ser humano estava nos encarando."
N/A4193"#commentary\cn_279_combine_gunship.mp3" "[ Ken Birdwell ] A aeronave de combate foi um problema interessante. Já tínhamos o modelo de voo do helicóptero, e estávamos sem tempo para criar algo totalmente novo, então ajustamos o modelo de voo do helicóptero até parecer diferente o suficiente, e depois derivamos a animação orgânica da aeronave a partir dos valores que saíam da simulação. Também tentamos deixá-la bem verossímil. Por exemplo, há um limite de quanto ela pode virar para mirar com os canhões. Se ela precisar de mais, precisa alterar a rota de voo — mas ela não pode trapacear. Outro recurso importante foi o som do motor. Temos espacialização de som, então o jogador consegue ter noção de onde ela está. Mas a aeronave de combate é um objeto rápido, que fica no ar, bem longe de qualquer ponto de referência. Ou seja, é difícil determinar sua distância ou velocidade. Para resolver isso, incluímos um efeito Doppler no som do motor, que varia o tom com base na velocidade da aeronave em relação ao jogador. É um efeito sutil, mas bastante eficaz em ajudar a perceber inconscientemente a posição e a direçãod a aeronave. É uma informação crítica que permite que o jogador saiba que está sendo caçado por ela."
N/A4194"#commentary\cn_280_risk.mp3" "[ Ken Birdwell ] Olhando agora para Half-Life 2, 20 anos depois, é preocupante pensar como boa parte do desenvolvimento foi assustadora. Desenvolver jogos é difícil. Você nunca consegue exatamente o que quer, que é validar um risco antes de acumular outros riscos. Por exemplo, nossa tecnologia de animação facial deve ter levado 3 ou 4 anos antes de ficarmos confiantes de que iria funcionar, mas não podíamos esperar. No primeiro ano, começamos imediatamente a tomar várias outras decisões no projeto do jogo, como a produção de recursos e outras tecnologias, tudo baseado na suposição de que nossa tecnologia de animação facial funcionaria no final, de um ponto de vista de qualidade e também de desempenho. Se não tivesse funcionado, várias dessas outras decisões também não teriam dado certo. E esse mesmo tipo de risco vale para outras decisões grandes que tomamos. Não tem como esperar; temos que criar e torcer para acertarmos nossas previsões, de anos anteriores. Assustador."
N/A4195"#commentary\cn_281_hugs_and_pickups.mp3" "[ Ken Birdwell ] Às vezes, até algo pequeno pode ser um pesadelo para fazer funcionar. Por exemplo, um personagem abraçar outro ou, ainda mais simples, pegar um objeto da mesa pode causar muitos problemas. Para piorar, no nosso ambiente dinâmico, com personagens e objetos sem uma posição predefinida, e o jogador zanzando por aí e ficando no caminho, tudo isso fica ainda mais complicado. É mais difícil porque seres humanos fazem isso sem pensar. Quando você vai até a mesa para pegar um copo, você faz todo tipo de preparativo com o corpo para deixar seus pés e mãos na posição certa para realizar a ação de forma confortável. Tudo pronto bem quando você chega lá. Se você estiver andando para abraçar alguém, as duas pessoas fazem isso ao mesmo tempo, se ajustando constantemente ao movimento da outra. Fazer isso funcionar no jogo requer muito trabalho de sincronização para os personagens estarem cientes uns dos outros e do mundo, e ao mesmo tempo saberem de seus planos. É tentador querer destrinchar o exemplo de pegar o copo em passos separados: andar até a mesa, olhar para o copo, pegar o copo. É muito mais simples assim, e cada passo acaba sendo reutilizável. Mas isso é como os robôs agem, não os humanos. Nossos personagens precisavam saber que estavam indo até a mesa com a intenção de pegar um copo para trabalhar em cada etapa simultaneamente, a fim de pegarem o copo assim que chegassem à mesa. Com dois personagens, fica parecendo uma negociação. Os dois precisam concordar onde e quando vai acontecer, e tudo precisa ocorrer de forma perfeita. Embora esses momentos de interação simples entre personagens no mundo costumem ser curtos, eles foram cruciais para construí-los como pessoas críveis."
N/A4196"#commentary\cn_282_ropes.mp3" "[ Mike Dussault ] Uma das coisas que notamos em todas as imagens de referência que reunimos da Cidade 17 é que havia fios e cabos por toda parte, e que eles eram grande parte da informação visível. Adorávamos o visual de cidades europeias antigas mesclado com essa trama caótica da vida moderna. Precisávamos de uma solução para cabos, cordas e afins, e queríamos que fossem dinâmicos. Nossos projetistas de fases estavam ansiosos para criar enigmas de plugues, e conectar um cabo a cada plugue ajudou os jogadores a entenderem a mecânica. No início da fase de produção, construímos um sistema de cordas e o repetimos por todo o desenvolvimento. Por baixo dos panos, cada corda é composta de vários segmentos esticados entre as duas extremidades, podendo se mover de forma independente. Cada segmento funciona como uma mola e responde a forças no jogo, como uma brisa ou uma aeronave da Combine passando. Renderizados, cada segmento aparece virado para a câmera e recebe mapeamento de relevo, crucial para dar uma aparência realista e arredondada às cordas."
N/A4197"#commentary\cn_283_vmpi.mp3" "[ Mike Dussault ] Durante o desenvolvimento, ficamos cada vez mais frustrados com a lentidão no ciclo de iteração do jogo, principalmente porque a compilação de mapas, necessária para pré-computar iluminação e visibilidade, levava horas. Os computadores dos anos 2000 eram bem mais lentos que os de hoje e tinham apenas um núcleo de CPU. Inspirados pelo SETI@Home, programa distribuído que usava PCs do mundo todo para buscar sinais de vida extraterrestre em ondas de rádio, construímos o VMPi, nosso próprio sistema distribuído que espalhava o processo de compilação de mapas por muitos computadores. Hoje, esses sistemas distribuídos rodam em aglomerados gigantes de GPUs, mas, na época, rodamos em todos os computadores da empresa. Como nosso código de iluminação evoluía tão rápido quanto nossos mapas, o VMPi também distribuía novos arquivos .exe para todos os computadores. Em retrospecto, isso era péssimo para a segurança, simplesmente terrível — um pesadelo para a turma do TI. Estávamos enviando um executável arbitrário para todos os PCs do trabalho e eles simplesmente rodavam. Loucura total. Mas funcionou, acelerou bastante a iteração dos mapas e, como resultado, acabou sendo uma ferramenta crucial."
N/A4198"#commentary\cn_284_field_of_view.mp3" "[ Kerry Davis ] Em Half-Life 1, usamos um Campo de Visão (FOV) de 90°, que era padrão para FPS na época. Durante o desenvolvimento de Half-Life 2, ficamos insatisfeitos com esse ângulo. Com o foco do jogo nos personagens, envidamos muitos esforços em animações detalhadas de corpo e rosto, mas o FOV de 90° não permitia que o jogador se aproximasse o bastante para ver todos os detalhes, então começamos a experimentar um FOV mais estreito e acabamos ficando com 75°. Precisou de adaptação, tanto nossa quanto do jogador, além de FOV adicional para modelos de visão, isto é, a arma do jogador na parte inferior da tela. Os modelos originais foram construídos com 90° em mente, então ficaram distorcidos em 75°, mas essa mudança logrou nosso objetivo: dar destaque aos personagens no jogo."
N/A4199"#commentary\cn_285_reference_maps.mp3" "[ Randy Lundeen ] Conforme nossos personagens ficavam mais realistas entre Half-Life 1 e 2, queríamos que o mundo parecesse igualmente realista. Em Half-Life 1, com as limitações de jogos em primeira pessoa, era mais fácil contar com ambientes estilizados ou abstratos. Já em Half-Life 2, queríamos criar um ambiente que parecesse baseado na realidade, então tivemos que focar em vários detalhezinhos novos. Um dos principais passos foi criar mapas de referência para padronizar o mapeamento de proporções do mundo real para o jogo. Esses mapas definiram detalhes como dimensões de paredes e portas, altura de maçanetas, iluminação interna, escala de mobília e a escala geral de objetos comuns. Criamos texturas padronizadas para os projetistas, com valores completos de escala e iluminação para que as disposições fossem consistentes desde o início. Além do mundo físico, esses mapas definiam o movimento do jogador pelo cenário — a altura ao pular, ao se agachar, e o tamanho de espaços como dutos de ventilação. Tendo esses mapas como base, mantivemos a geometria do mundo consistente, garantindo espaços de tamanho realista por todo o jogo."
N/A4200"#commentary\cn_286_response_rules.mp3" "[ Scott Dalton ] Soubemos desde o início que queríamos muitos diálogos dinâmicos no jogo, então precisávamos de um sistema para lidar com isso. Queríamos um sistema que permitisse que o designer de som incluísse ou ajustasse falas sem envolver programadores, que deixasse o diálogo bem responsivo ao estado do jogo e que minimizasse repetições. Com esses requisitos, criamos o sistema de Regras de Resposta. Sempre que um personagem fala fora de uma cena coreografada, esse sistema determina a fala ser dita. Em vez de escolher diretamente, a IA do personagem indica \"oportunidades de fala\" sempre que ocorre um evento relevante: avistar o jogador, ferir-se, disparar o último tiro da arma, encontrar inimigos fortes etc. A cada oportunidade, a IA manda um pacote de dados com o estado do jogo ao sistema de Regras de Resposta, que, por sua vez, devolve a fala mais adequada, se houver alguma. Com essa configuração, nossos designers de som puderam criar uma matriz de diálogo detalhada. Por exemplo, o personagem pode ter um conjunto de fala para anunciar que vai recarregar durante um tiroteio, outro quando está no final de uma batalha, um terceiro quando só tiver sobrado um aliado, e outro ainda quando houver um Trípode na área. Quando lançamos Half-Life 2, a sensação foi de só termos engatinhado no potencial desse sistema. Ele foi central para a Alyx do Episode 1 e deu vida ao diálogo dinâmico em outros jogos, como as classes de TF2 e o elenco de Left 4 Dead."
N/A4201"#commentary\cn_287_audio_caching.mp3" "[ Yahn Bernier ] Outro problema que enfrentamos foi a quantidade colossal de áudio no jogo. Com todos os sons, músicas e diálogos, era muito áudio para armazenar na memória, que era artigo de luxo em 2003. Mas, como você pode imaginar, precisamos reproduzir sons imediatamente, principalmente se tiverem relação com a jogabilidade. Criamos um cache de áudio que armazenava apenas os primeiros 125 ms de cada arquivo de áudio e guardava na memória. Esses 125 ms eram nosso melhor chute para o tempo que levaria para transmitir um áudio do disco. Sempre que um som era reproduzido no jogo, rodávamos o início do cache de áudio enquanto começávamos simultaneamente a carregar o áudio completo do disco. Quando o início do cache terminava, o arquivo já estava carregado e podíamos reproduzir o resto do som. Havia outros recursos menores, como armazenar sons recentes inteiros na memória para que os mais usados não precisassem ser carregados toda hora. Nos motores de hoje, todos os recursos — não só os sons — costumam usar o mesmo tipo de estratégia."
N/A4202
39184203}
39194204}