Documentário de 25 anos de Half-Life [Vídeo]
(youtube.com)- Em 1996, após deixarem a Microsoft, Mike Harrington e Gabe Newell começaram ao mesmo tempo o desenvolvimento de Half-Life e o desenho organizacional da Valve com uma equipe que quase não tinha experiência em lançar jogos
- Com a licença da engine de Quake, a contratação de criadores de mods e a junção de talentos com trajetórias pouco convencionais, a primeira IP da Valve foi criada do zero
- Half-Life buscou uma imersão em primeira pessoa sem interrupções com cor de 16 bits, animação esquelética, transições curtas de fase, eventos roteirizados, IA reativa e som
- Quando uma revisão interna em 1997 concluiu que o jogo não estava coeso, o lançamento foi adiado e o fluxo das fases foi redesenhado com o processo de cabal, formado por pequenos grupos multidisciplinares
- Na reta final houve limitações como jornadas de 18 horas, monstros e fases cortados e um Xen concluído às pressas, mas a produção iterativa e os playtests elevaram a qualidade final
Saída da Microsoft e fundação da Valve
- Mike Harrington sentia que a Microsoft tinha ficado grande demais e, cerca de um ano antes, já dizia aos gerentes que sairia da empresa para criar uma empresa de jogos
- Harrington falou primeiro com Michael Abrash, mas Abrash depois se juntou à id Software após ser convencido por John Carmack
- Quando Harrington disse que criaria uma empresa de jogos, Gabe Newell respondeu que também queria sair, e os dois começaram a Valve juntos
- Newell achava que, olhando só para a situação da época, parecia muito provável que aquilo fracassasse, e imaginava que cerca de um ano depois perceberia o erro e pediria emprego de volta aos amigos da Microsoft
- Os dois fundadores tinham experiência em desenvolvimento de software e ideias sobre como estruturar uma empresa, e projetaram a Valve enquanto faziam Half-Life
Engine de Quake, primeira IP e equipe inicial
- A Valve começou sem um plano claro, mas visitou a id Software por contato de Michael Abrash e voltou com o código-fonte de Quake em um CD
- Na época ainda não havia contrato, mas a Valve conseguiu acesso ao código-fonte de Quake, algo muito próximo de um ativo central da id
- John Romero aconselhou que, para abrir uma empresa de jogos, seria preciso contratar level designers
- A maior parte da equipe inicial não tinha experiência em desenvolvimento de jogos, e em toda a empresa só havia de 3 a 4 pessoas que de fato já tinham lançado um jogo
- A Valve precisava criar do zero a IP de seu primeiro jogo, e Gabe Newell usou a tensão e a atmosfera de
The Mist, de Stephen King, como referência - No início a Valve tinha dois projetos
- Quiver: o projeto que depois virou Half-Life
- Prospero: um projeto separado que desapareceu à medida que Half-Life absorveu recursos e funcionalidades dele
- Um efeito de feixe criado para Prospero acabou entrando na sequência do desastre de Half-Life e nos efeitos dos Vortigaunts
Criadores de mods e talentos pouco convencionais
- A Valve contratou muitos designers vindos da comunidade de criadores de mods
- Jovens criadores de mods como Steve Guthrie, Steve Bond e John Guthrie entraram na equipe
- Steve Bond, que fazia mods em QuakeC, contribuiu para grande parte da IA dos soldados de Half-Life
- Havia muitas pessoas na equipe com trajetórias distantes do caminho padrão da indústria de jogos
- A pessoa que escreveu mais código em Half-Life tinha se formado em química e estava tentando virar advogada de patentes em Atlanta
- Quem mais contribuiu para o design da IA das criaturas era gerente de um Waffle House
- Marc Laidlaw trouxe estrutura narrativa e ideias para a equipe, além de ajudar a puxar ideias dos outros
- Na época, a indústria não tinha uma rota padronizada como um “doutorado em design de videogames”, e a Valve precisava encontrar gente talentosa e convencê-la de que ali seria um lugar melhor para trabalhar
As escolhas técnicas que fizeram Half-Life
- A Valve desenvolveu sobre a engine de Quake da id, mas adicionou várias tecnologias necessárias para Half-Life
- As transições de fase foram implementadas usando o sistema de salvar/carregar
- Em corredores ou trechos de trem, havia uma breve pausa para carregar a próxima fase
- A maioria das transições em Half-Life 1 durava cerca de 1 a 2 segundos
- Os dois grandes investimentos técnicos de Half-Life foram cor de 16 bits e animação esquelética para os monstros
- Ao passar de 8 bits para 16 bits, deixou de ser necessário encaixar texturas em apenas 256 cores
- Os personagens de Quake guardavam posições de vértices ao longo do tempo, mas com um esqueleto era possível ter mais animações, troca de partes, armas acopladas e reutilização de modelos
- A animação esquelética virou a base para incluir animações com 100, 200 ou mais de 500 frames e facilitar deformações de personagens
Eventos roteirizados e um mundo que reage
- A equipe definiu como princípio que, se o jogador estivesse avançando, algo deveria acontecer a cada 3 a 5 segundos
- O evento não precisava ser uma grande batalha; podia ser uma placa, um som, uma pequena cena ou uma sequência roteirizada
- Se o jogador ficasse parado, o mundo podia permanecer quieto, mas se agisse, o mundo deveria reagir
- As sequências roteirizadas permitiam fazer personagens correrem até posições específicas ou criar cenas de voo e impacto sincronizadas com animações
- Os eventos roteirizados eram poderosos, mas frágeis
- A cena em que um headcrab salta sobre um cientista funcionava em 90% dos casos, mas quebrava se alguns jogadores corressem direto até o cientista
- Algumas cenas precisavam ser colocadas atrás de vidro para impedir a aproximação do jogador
- A sequência do Tentacle ficou como um exemplo marcante de mistura estreita entre gameplay e evento roteirizado
- Gabe Newell via a diversão menos como realismo e mais como o grau em que o jogo reconhece e reage às escolhas e ações do jogador
- Se o jogador atira na parede, devem ficar marcas de bala
- Se muitos soldados morrem, os outros deveriam fugir
- A ideia de que o mundo do jogo precisa reconhecer a presença e os atos do jogador se tornou um dos elementos centrais de Half-Life
Criaturas, personagens e o G-Man
- O design das criaturas de Half-Life buscava um caminho naturalista e ao mesmo tempo alienígena
- Ted Backman criou muitos designs carnosos e biológicos como headcrab, houndeye e bullsquid
- Chuck Jones, vindo de Duke Nukem, criou monstros com outro estilo, e foi preciso encontrar equilíbrio entre os dois
- O headcrab virou uma das criaturas mais icônicas de Half-Life, e o zumbi surgiu ao colocar um headcrab sobre o modelo de cientista
- Gordon Freeman não tinha uma aparência claramente definida desde o começo
- O modelo inicial, “Ivan the space biker”, era um protótipo grosseiro
- Chuck Jones colocou sua própria aparência no modelo inicial de Gordon, e o modelo de multiplayer manteve um pequeno vestígio de rabo de cavalo
- O G-Man foi criado como um personagem que lembrava o cigarette man de
The X-Files- No início ele era mais uma figura sinistra ao fundo da cena de escritório no começo do jogo
- Depois passou a ser colocado em vários lugares inacessíveis, tornando-se uma presença misteriosa
- O Vortigaunt foi adicionado mais cedo em mapas da campanha relativamente tarde no desenvolvimento, para reduzir a repetição de monstros do começo
- O Assassin também entrou tarde como inimigo; como o modelo e as animações já existiam, ele foi finalizado acoplando IA sem novas animações
- Criaturas como Panthereye, stooka bat e chub toad permaneceram no jogo por muito tempo ou chegaram à fase de implementação, mas acabaram removidas
O espaço de Black Mesa e as texturas
- Black Mesa partiu de elementos como um grande prédio de escritórios comum nos arredores de Washington, DC, pisos de linóleo, teto rebaixado, paredes de bloco de concreto e chão de ladrilho preto e branco
- Karen Laur foi responsável pela maior parte do trabalho de texturas do jogo e, no início, desenhava tudo à mão antes de migrar para uma abordagem baseada em referência fotográfica
- Ela fotografou metal enferrujado e imagens industriais em lugares como Seattle, Harbor Island e Gasworks Park
- Muitas texturas de corredores de Half-Life usam imagens como superfícies de vagões e trens
- Imagens de deserto e penhascos do leste de Washington e do Columbia Gorge também serviram de referência para a atmosfera sudoeste
- Dentro de Black Mesa havia não só instalações de pesquisa, mas também elementos cotidianos como escritórios, cozinha, micro-ondas e a cena da sopa explodindo
- A cena do micro-ondas vinha de experiências reais no escritório da Valve com sopa explodindo
- As faixas coloridas foram usadas para ajudar o jogador a se orientar dentro do complexo de pesquisa
A crise de 1997 e o processo de cabal
- No primeiro ano de desenvolvimento, a equipe avançou guiada por oportunidades e ainda buscava uma direção
- Cerca de 3 meses antes da previsão de lançamento em 1997, internamente concluiu-se que o jogo não estava se encaixando bem
- Engenharia, level design e animação estavam desconectados entre si
- Havia monstros sem plano claro de uso e fases em que nem se sabia ainda o que seria colocado
- Como extensão da cultura de mods, em que cada level designer fazia seu próprio mundo, faltava coesão ao conjunto
- A reação de Gabe Newell, após jogar todas as fases em uma revisão de dois dias, dizendo “vamos fracassar”, ficou muito marcada na equipe
- A Valve disse que não lançaria o jogo no cronograma da Sierra e decidiu continuar mesmo que a Sierra não bancasse custos adicionais
- Sob a ideia de que “atrasar é temporário, mas ruim é para sempre”, a equipe decidiu não forçar um lançamento prematuro
- Depois disso foi introduzido o processo de cabal
- Pequenas equipes multidisciplinares com artistas, level designers e engenheiros escreviam as especificações das fases
- Seguindo o fluxo narrativo escrito por Marc Laidlaw, definiam em ordem quais mapas eram necessários e qual seria a próxima peça
- Tentavam aplicar de forma uniforme ao jogo inteiro a proporção entre combate, exploração e puzzles
- Os esboços funcionavam como atas visuais das reuniões e ficaram como um dos principais produtos do cabal
A abertura, a sequência do desastre e a imersão sem interrupção
- A cena de abertura no trem em Half-Life foi uma resposta aos hábitos dos shooters em primeira pessoa da época
- Muitos jogos davam arma e inimigos imediatamente, sem cutscene, ou começavam a jogar depois de uma cutscene
- Half-Life começa com um cientista anônimo indo trabalhar de trem e entrando em Black Mesa
- Muitos jogadores acharam no começo que era uma cena gravada e só perceberam que era em tempo real ao mexer o mouse
- Parte da estrutura do trecho pré-desastre sobreviveu da versão do primeiro ano e depois foi refinada por John Guthrie e outros para a versão final
- A sequência da câmara de testes foi um ponto de virada importante
- Uma versão feita por John Guthrie durante a noite já era muito próxima da que foi lançada
- Luz, som, batimentos cardíacos, respiração e encenação foram reunidos para criar “uma experiência contínua que realmente acontece com o jogador”
- Depois dessa sequência, que ligava o antes e o depois do desastre, a equipe passou a acreditar que o jogo podia ser amarrado como um produto único, e não como um conjunto de conteúdos soltos
O preview vazado e a reação externa
- Como uma das formas de financiar o desenvolvimento, a Valve vendeu uma build de preview de Half-Life para empresas de placas de vídeo
- Pelo contrato, ela precisava ser entregue até uma data específica, e a equipe concluiu as três primeiras fases para cumprir isso
- Essa build logo vazou, e no começo a reação foi de raiva, mas depois começaram a se espalhar online as reações de quem jogou
- Uma revista, mesmo dizendo que normalmente não analisava software beta, resenhou essa build e a avaliou positivamente
- Essa resposta externa serviu como uma forte validação da direção que a Valve estava tentando seguir
Armas, som e sinais de IA
- As armas de Half-Life foram desenhadas para ter papéis o mais diferentes possível entre si
- Além do eixo básico de shotgun e pistol, havia rocket launcher, Gauss gun e snark
- O Snark foi pensado como arma para lidar com jogadores que ficam acampados, soltando uma criaturinha que sai circulando
- O crowbar entrou como resultado do desejo de ter mecanismos pelos quais o mundo reagisse
- Bater na parede dava um feedback fortemente satisfatório para a época
- Foi um exemplo concreto de como a ideia de que “diversão é o mundo reagir às ações” virou decisão de design
- O som foi usado como meio essencial para transmitir ao jogador o estado interno da IA
- Os soldados revelavam por voz quando estavam feridos, jogando granada ou buscando cobertura
- Mesmo sem perceber conscientemente, o jogador passava a prever pelo som o que aconteceria em seguida
- Kelly Bailey usou a engine de som e também compôs a trilha sonora
- Ele nunca tinha escrito uma trilha antes, mas fez toda a música do jogo e ainda recebeu prêmios
- O som do headcrab foi criado a partir de um som de rato bastante desacelerado e invertido
- Efeitos de DSP ajudavam a diferenciar a reverberação de dutos de ventilação e de espaços amplos, reforçando a sensação de espaço
- O movimento labial dos personagens foi implementado relativamente rápido usando o sinal de áudio
- Como animador e programador enxergavam como difíceis partes diferentes do problema, uma conversa no almoço levou em pouco tempo a personagens falando e mexendo a boca
Design de fases e trechos marcantes
- O trecho Power Up sobreviveu quase intacto porque foi projetado em torno da criatura Gargantua
- O jogador precisa lidar com o Gargantua, ligar a energia e mover o trem para seguir em frente
- O ponto de partida do design foi encontrar uma forma de impedir que o jogador fosse direto para a saída
- No segundo ano, em vez de encaixar IA em mapas já prontos, a equipe passou a criar primeiro ambientes restritos em que a IA pudesse se destacar, para depois os level designers integrarem isso às fases
- A IA dos soldados evoluiu em mapas de teste que mostravam situações de combate com diferença de altura, recuo, uso de escadas e ataque flanqueando
- O trecho do trem era uma tentativa de oferecer um veículo que o jogador pudesse controlar, mas com limitações
- Como algo no nível dos veículos de Half-Life 2 era impossível, escolheu-se o trem como forma mais restrita
- Como alguns jogadores abandonavam o trem e seguiam a pé, foi colocada eletricidade nos trilhos para incentivá-los a trazê-lo de volta
- Surface Tension nasceu muito motivado por um esboço com penhascos, tanque, base de soldados, deserto, helicóptero e represa
- O trecho dos penhascos foi desenhado para explorar a vertigem
- A parte da represa, que lembrava a Hoover Dam, foi feita em poucas horas
- Karen Laur tentou criar coesão visual dando nomes aos conjuntos de texturas com base na fase correspondente, para evitar que novas texturas fossem usadas de forma caótica em várias áreas
Transmissão da história, nomes e vozes
- A narrativa de Half-Life buscava uma escrita diegética transmitida dentro do jogo, em vez de explicações fora das cutscenes
- Depois dos playtests, foram adicionadas falas de cientistas em pontos onde se julgava faltar orientação ou explicação da situação
- Por exemplo, cenas em que um cientista aparecia de repente para dar pistas como “vá por ali” foram inseridas no fim do desenvolvimento
- Parte da localização e do nome de Black Mesa nasceu de marcações e nomes em mapas iniciais
- Um ponto marcado no México em um mapa do lobby acabou levando depois à definição de localização e nome
- Os desenvolvedores preferiam nomes sugestivos, sem explicar tudo, por acharem que isso reforçava o mistério
- A voz de Barney foi decidida na hora em que Hal Robins falou ao telefone e a equipe sentiu imediatamente que “era ele”
- Michael Shapiro fez o G-Man; no começo ele gravou uma atuação mais segura e direta, mas depois foi escolhida uma interpretação mais próxima de uma “voz de lagarto maluco”
- A voz de Nihilanth também foi produzida internamente pela equipe
O trabalho exaustivo e a vida pessoal no fim do desenvolvimento
- Na reta final de Half-Life, as longas jornadas de trabalho continuaram
- Alguns membros da equipe disseram ter trabalhado 18 horas por dia
- Os integrantes mais jovens muitas vezes ficavam no escritório até muito tarde da noite
- Karen Laur relembra que era a única mulher da equipe na época e que a situação não era boa
- A foto de Isabel, filha de um dos desenvolvedores, foi colocada no armário de Gordon
- Originalmente estava escondida em algum escritório destruído como um easter egg pessoal, mas depois foi movida para o armário de Gordon
- Isabel nasceu durante a produção de Half-Life e precisava de cuidados especiais, o que tornou aquele período muito difícil para a família
- Os desenvolvedores dizem que, mesmo logo após o lançamento final, ainda era difícil ter certeza de que o jogo era realmente divertido
- Havia quem dissesse que, se qualquer membro da equipe tivesse desaparecido por um mês, o jogo não teria sido lançado, de tão importante que cada pessoa era
Xen e as limitações da parte final
- Xen começou a partir da ideia de entrar no interior de uma enorme criatura alienígena para pará-la ou manipulá-la
- A equipe queria expressar arquitetura alienígena e estruturas biológicas, mas as ferramentas eram adequadas para criar retângulos, e o resultado acabou sendo reduzido gradualmente a estruturas mais cheias de corredores
- Como Xen ficava na parte final do jogo, a pressão de tempo era grande
- Algumas partes permaneceram em um estado muito próximo de um primeiro rascunho
- Em certo momento cogitou-se até não ir a Xen, mas a força do conceito artístico fez com que ele fosse mantido
- As texturas de Xen foram inspiradas por imagens de microscópio eletrônico, insetos e besouros, entre outras referências orgânicas
- O editor não era amigável para criar formas orgânicas, e construir aquelas fases era muito difícil
- A baixa gravidade e mudanças como o jump pack entraram tarde e tiveram de ser incorporadas a espaços que já estavam prontos
- Em certo momento a equipe concluiu que precisava parar de lapidar e simplesmente terminar
- Se o jogador não estivesse se divertindo até ali, então o fracasso já teria acontecido de qualquer forma, e o importante na parte final era fechar o jogo
- Também surgiam piadas do tipo “sempre existe Half-Life 2”\n
Retrospectiva após a conclusão
- Os membros da equipe lembram como algo importante a colaboração entre pessoas com formações profissionais muito diferentes durante a produção de Half-Life
- Karen Laur diz que entrou como artista de texturas, mas pôde influenciar bastante no que o jogo viria a ser
- Um bom jogo exige fazer conteúdo suficiente para dois jogos e descartar a parte ruim, e a Valve conseguiu fazer isso graças ao apoio de Mike Harrington
- Gabe Newell diz valorizar mais o que ainda pode ser feito no futuro do que revisitar o legado do passado, vendo o trabalho anterior mais como um degrau que permitiu seguir em frente
1 comentários
Opiniões no Hacker News
Achei realmente interessante como a Valve acertou em cheio nas primeiras contratações
Havia muita gente sem formação em CS, e até sem histórico em games, mas muitos deles acabaram se revelando pessoas persistentes, engenhosas, criativas e trabalhadoras
A pessoa que escreveu a maior parte do código de Half-Life também não era desenvolvedora; pelo que me lembro, na época estudava para se tornar advogada ou contadora
No fim, não dá para negar que timing, fundadores e simplesmente sorte tiveram um papel decisivo
Na prática, foi como se o primeiro ano tivesse sido usado para ganhar experiência, e o ponto importante é que a distribuidora Sierra aceitou isso
Hoje em dia, especialmente em jogos AAA, acho que algo assim dificilmente aconteceria. Os orçamentos ficaram grandes demais, e a distribuidora provavelmente pressionaria o estúdio a lançar o que já existe, remendado de qualquer jeito com fita adesiva, em vez de dar um plano B
Afinal, dá para corrigir com patches depois, certo?
A indústria de tecnologia parece obcecada por desenvolvedores 10x como Carmack, mas pessoas motivadas também conseguem fazer coisas incríveis
Então eles foram até a id, saíram de lá com o engine do Quake e ainda receberam conselhos do Romero
Às vezes, conhecer as pessoas certas ajuda de verdade, e sempre há alguma dose de sorte no sucesso. Também é claro que uma ótima equipe fez daquele jogo o que ele se tornou
A forma como equilibraram realismo e diversão também foi interessante, e o processo de criação de algo é sempre fascinante
Naquela época, acho que esse tipo de coisa era muito mais comum do que hoje. Hoje é preciso ser capaz de fazer um trabalho um ou dois níveis acima do necessário para as tarefas de lançamento, provavelmente porque a gestão e os cronogramas estão tão distorcidos que é preciso entregar mesmo com pressa e excesso de trabalho
Quem está começando agora ou mudando de carreira quase não recebe esse tipo de apoio e só pode torcer para estar aprendendo, por conta própria, habilidades suficientes para ser contratado
No fim dos anos 90, eu participei bastante da comunidade australiana de Team Fortress (versão para Quake 1), e o ‘bro’ (Robin Walker) e John Cook eram como deuses para nós
Eles participavam constantemente da cultura de LANs da RMIT/Melbourne e da cena online; naquela época, a maioria usava modems de 28,8/33,6k, e havia alguns LPBs nas conexões ISDN das universidades da costa leste
Talvez a dificuldade na tentativa de passar de qwtf para ‘tf2’ tenha sido boa no fim das contas. As lições aprendidas naquele deserto devem tê-los ajudado depois, quando entraram na Valve e trabalharam em HL2
Também é bem interessante que TF2 originalmente seria um shooter militar moderno muito mais realista, mas acabou naufragando por causa do aumento de escopo
Fiquei muito animado quando eles foram contratados pela Valve para fazer TFC e, depois, HL2
Depois veio Day of Defeat, que preencheu esse papel muito bem
Aqui surge uma pergunta bastante óbvia. O que havia de diferente naquela equipe? Era talento, liderança ou foco no produto?
Falando como alguém que trabalha há muito tempo como desenvolvedor JavaScript, acredito sinceramente que, entre as pessoas que trabalham principalmente com JavaScript, só cerca de 4% realmente sabem o que estão fazendo
A equipe inicial da Valve parecia ter muita paixão, mas quase nenhuma experiência real com aquele tipo de código ou produto. Eles ganharam um enorme ponto de apoio, o código do Quake, e descobriram o resto por conta própria
Não ficaram estagnados em cima do código do Quake; mexeram bastante nele para adequá-lo às suas necessidades. A maioria das equipes JavaScript não consegue fazer esse tipo de coisa. Fica presa ao framework favorito e só gira em torno de estilo de código e processos
Qual é a diferença entre a equipe inicial da Valve e várias equipes JavaScript? Certamente não é educação nem maturidade profissional
Além disso, a menos que você seja bem sênior, normalmente não recebe autoridade para fazer grandes mudanças; e mesmo que decida continuar buscando autoaperfeiçoamento, é pouco provável que a empresa recompense esse crescimento técnico
No fim, vejo isso como uma área com retornos decrescentes bem fortes
Se você já jogou algum jogo multiplayer competitivo, sabe que há pessoas que passam milhares de horas jogando e não melhoram nada
Às vezes as pessoas parecem encontrar um gargalo, mas não sabem como superá-lo
Naquele tempo, criar níveis, modelos, animações etc. para videogames era drasticamente mais simples do que hoje
Uma pessoa fez todo o trabalho de texturas do jogo inteiro, uma pessoa criou todos os efeitos sonoros e a música, e ainda programou um motor DSP que manipulava o som em tempo real conforme o ambiente
Algumas pessoas muito talentosas, dispostas a liderar pessoas inteligentes, entusiasmadas e motivadas, conseguem fazer muita coisa. Acho que foi exatamente isso que aconteceu na Valve
Eles sabiam o bastante para terminar o trabalho, mas não sabiam o suficiente para concluir que o que queriam fazer “não dava”
Desenvolvedores mais experientes talvez tivessem descartado muitas das ideias que a equipe de Half-Life acabou implementando como “demoradas demais” ou “praticamente impossíveis”
Os desenvolvedores da Valve na época não tinham experiência suficiente para fazer esse tipo de suposição, então simplesmente mergulharam de cabeça e encontraram um jeito
No fim, eles basicamente recomeçaram com o “cabal” e tiveram de reunir as boas partes que já tinham criado para finalizar o jogo
Há um texto mais detalhado sobre o processo cabal aqui (começa na página 2):
https://web.archive.org/web/20210823181232/https://www.gamas...
É um texto de 1999 e é muito mais detalhado que o vídeo
O desenvolvimento de jogos é, por natureza, um processo em cascata. Você trabalha por alguns anos e acumula tudo para um grande lançamento. Hoje pode haver processos ágeis dentro dos marcos, mas, fundamentalmente, tudo caminha para uma grande cascata
Isso é importante. O ágil de hoje, em certos aspectos, transforma desenvolvedores autônomos em engrenagens de uma grande máquina. Mas o “cabal” da Valve tinha liberdade para fazer o que achava melhor
Gabe Newell provavelmente tinha a decisão final e dava opiniões, mas, em última instância, aquele grupo tinha flexibilidade. Os desenvolvedores conheciam o sistema inteiro; não era algo como pegar tickets do Jira do quadro, à maneira da parábola dos cegos e o elefante[1]
Eles sabiam como as peças se encaixavam porque foram eles mesmos que as colocaram ali. Se as peças não se encaixassem, também tinham autoridade para fazê-las encaixar
Também é interessante ver a história de Half-Life pela perspectiva de The Mythical Man-Month[2]
Mesmo que o resultado tenha sido um sucesso, o crunch é um lembrete amargo
Foi por causa dessas jornadas de trabalho que parei de fazer mods e fui para o lado de software empresarial entediante
Além disso, você ainda pode fazer desenvolvimento de jogos no tempo livre. Afinal, você realmente tem tempo livre
O playthrough de Dario Casali do 25º aniversário de Half-Life também vale a pena ver: https://www.youtube.com/playlist?list=PLk5gaNp4x_AVIJviyHueH...
Jornadas incessantes de 12 a 16 horas, discussões por e-mail e uma gestão que desanimava a equipe
Quando eu era criança, tinha uma imagem meio de conto de fadas de que trabalhar na Valve era um ambiente incrível, com pessoas inteligentes fazendo o melhor trabalho possível. Em certa medida, isso provavelmente ainda é verdade, mas não acho que eu conseguiria fazer os sacrifícios que esses desenvolvedores fizeram por um único videogame. Impressionante
Um dos vídeos mais interessantes para mim foi o do mapa multiplayer no final, porque Dario tinha muito a dizer sobre design de mapas
Vi ontem, e desenvolvimento de jogos é realmente duro e imprevisível
Especialmente neste caso, quase todo mundo era amador, com pouca ou nenhuma formação em programação ou jogos, mas com muita paixão
Também desmistifica como ele foi feito. Os bons elementos de Half-Life, como a introdução, o G-Man, Xen, os headcrabs e a música, quase nada disso existia desde o início; foram surgindo ao longo do processo
O documentário foi excelente. Joguei aquele jogo uma quantidade absurda no passado
Agora parece que Half-Life Deathmatch também está passando por uma pequena renascença, então vale experimentar se quiser sentir nostalgia
A Valve também lançou alguns modelos de personagens de arte conceitual, ajustes de gameplay e mapas novos. Ou seja, conteúdo novo para um jogo de 25 anos
Para referência, Half-Life e HL2 hoje são ambos bastante jogáveis em VR. Half-Life roda até nativamente no Quest 2
Mas a Valve não reconheceu o 17º aniversário do anúncio de Half-Life 2 Episode 3
“Atrasar é passageiro, mas ser ruim é para sempre” é uma boa frase
No Man’s Sky vem à mente, e Cyberpunk 2077 talvez também se encaixe
Foi um ótimo documentário. Depois de ver o documentário de aniversário, também recomendo procurar a primeira parte[1] de Black Mesa, o remake do Half-Life original no motor Source
Os modders falam bastante sobre os elementos mencionados pelos desenvolvedores originais e as dificuldades que encontraram ao recriá-los
[1] https://www.youtube.com/watch?v=G_TcAxAKCAI