1. Introdução

Recentemente, histórias sobre jogos clássicos receberam uma boa recepção no GDC, mas havia muito poucas histórias sobre as ferramentas para seu desenvolvimento. Nesta série de artigos, tentaremos preencher essa lacuna entrevistando pessoas que desempenharam um papel importante na história das ferramentas de desenvolvimento de jogos.

Nas duas primeiras partes da série, conversamos com John Romero (sobre o TEd Editor) e Tim Sweeney (sobre o Unreal Editor) .

Ao escrever o terceiro artigo, tive a honra de conversar com Chris Norden sobre as ferramentas que ele desenvolveu para o híbrido FPS / RPG chamado Deus Ex . Conversei com Chris em São Francisco na GDC 2018.

Antes da tempestade iônica: origem e espelho

David Lightbone: Como você começou no Deus Ex no Ion Storm?

Chris Norden: Em 1994, trabalhei como programador do Origin em Austin. Meu primeiro projeto pago foi o combate de Jane's AD-64D Longbow da Jane's Combat Simulations. Era originalmente um jogo de arcade chamado Chopper Assault. Juntamente com Andy Hollis, trabalhei nele por dois anos.



Após o lançamento do jogo, a última coisa que eu gostaria de fazer é fazer outro simulador militar, porque eu absolutamente não gosto de tudo que é militar. De tempos em tempos, conversava com Warren Spector, que também trabalhava na Origin. Ele realmente gostou da trama de RPG. Pensei comigo: "Eu também gosto desses jogos, quero trabalhar em algo assim!"

Em 1996, Warren renunciou à Origin e tornou-se chefe do Looking Glass Studios em Austin, cuja existência ninguém sabia então. Este estúdio criou portas para jogos para Mac, como o Links 386 Pro . Ela também estava desenvolvendo seu próprio jogo de golfe, chamado British Open Championship Golf.

A Origin ainda estava desenvolvendo o Ultima Online. Ela foi apelidada de Multima, e parece ter usado o mecanismo Ultima VII. Eu experimentei um pouco com ele até deixar o Origin e me juntar a Warren no Looking Glass.

[Nota do autor: o estúdio principal do Looking Glass ficava em Cambridge, Massachusetts, perto de Boston]

Warren escreveu um documento de design e, durante algum tempo, trabalhamos em um role-playing game com a abreviação AIR (de Austin Internet Role-Playing), que deveria ser um projeto online. Queríamos fazer algo em 3D, porque enquanto os aceleradores 3D estavam apenas começando a aparecer. Temos um protótipo do Voodoo 1 e escrevemos um pequeno motor no GLide.

Fizemos uma parceria com o escritório de Cambridge da Looking Glass. Depois de lançar o British Open, ajudei Mark LeBlanc e Doug Church com um motor Thief chamado Dark Engine .

Por razões financeiras e outras, a Looking Glass não estava se sentindo muito bem naquele momento. A empresa tinha jogos incríveis, mas eles vendiam mal. Portanto, após cerca de um ano, foi decidido fechar o escritório em Austin.

[Nota do autor: Chris está absolutamente certo sobre os jogos - Ultima Underworld, System Shock e Terra Nova foram muito bem recebidos pelos críticos, eles foram alguns dos melhores jogos dos anos 90]

Na época em que o escritório foi fechado, havia poucos de nós: Warren, eu, Al Yarusso, Harvey Smith, Steve Powers. Todos nós ainda queríamos trabalhar neste jogo de interpretação de papéis. Depois que o escritório foi fechado, nos abraçamos por cerca de seis meses, esperando que pudéssemos estabelecer uma nova empresa e fazer alguma coisa. Tínhamos um documento de design muito bom, começamos a "vendê-lo" a editores e a nos comunicar com pessoas diferentes. Nem me lembro de todos os editores que contatamos. Uma dessas pessoas era John Romero e Tom Hall, que, junto com a Eidos, trabalharam para criar um novo estúdio em Dallas chamado Ion Storm.


Eu conhecia John desde os primeiros anos de id. Em 1991, em Dallas, a MTV deu uma enorme festa de navio dedicada ao Wolfenstein 3D. Havia duas máquinas VR Virtuality Arcade Machine . Naquela época, eu era criança e pensava: "Deus, isso é a coisa mais legal do mundo!" Eu conheci John nos dias em que ele vivia no estilo de "Eu sou rico demais para me preocupar com nada".

John é uma pessoa maravilhosa, trabalhei com ele na Monkeystone Games, ajudei a desenvolver o jogo para Gameboy Advance, mas isso é outra história.

[Nota do autor: o jogo foi chamado Hyperspace Delivery Boy. Para Gameboy Advance, era para ser publicado pela Majesco , mas no último momento a empresa se recusou a divulgá-lo.]

Conversamos com Romero e Tom Hall, e eles são: "Warren, você é legal, vamos fazer este jogo!". E Warren respondeu: “Há um problema. Nós não vamos nos mudar para Dallas. Não vamos nos mudar para a Califórnia. Não vamos nos mover em lugar algum. Vamos manter o estúdio em Austin. Portanto, permaneceremos completamente autônomos. Você me dará controle completo sobre tudo. Você vai me dar dinheiro, e tudo ficará bem. Eles responderam: “Ok, isso nos convém. Resolvido ".

[Nota do autor: obviamente, essa é uma versão simplificada das negociações, mas dá uma idéia do que aconteceu]

Warren tinha um ótimo documento de design para o jogo Troubleshooter na época, que gradualmente se transformou em um documento de design de Deus Ex.

Então, nós seis fundamos a Ion Storm Austin. Naquela época, eu era o diretor técnico, o chefe do departamento de TI, "Homo Arom", o serviço de segurança e o engenheiro líder. Não tínhamos pessoas suficientes para fazer todas essas coisas. Portanto, era necessário realizar entrevistas rapidamente e recrutar funcionários.

A equipe era pequena. Tínhamos três engenheiros: eu, Scott Martin e Al Yarusso. Sheldon Pacotti foi contratado como roteirista. Tínhamos duas equipes de design de três pessoas cada. Um foi liderado por Robert White, o segundo por Harvey. Parecia haver mais seis artistas liderados por Jay Lee.

Ah, e eu também contratei Alex Brandon porque eu era um grande fã da música dele para o Unreal. Agora somos grandes amigos. Eu o apresentei à sua futura esposa, porque éramos amigas no ensino médio. Ele é um cara legal: um excelente músico e bem versado em detalhes técnicos.

Então contratamos um administrador, e é isso. E então nos deparamos com um trabalho infernal por dois anos e meio! (risos)

Escolhendo entre os motores Irreal e Quake

JL: Então, enquanto o resto do Ion Storm trabalhou com o mecanismo do Quake, você escolheu o Unreal. Você pode explicar como chegou a essa decisão?

KN: Não importa o quanto eu respeite o mecanismo do Quake, eu sabia que naquele momento não teríamos nenhum suporte. Criamos um jogo muito específico no qual queríamos poder fazer qualquer coisa. Quake era um atirador, e nada mais. Se tentássemos fazer algo diferente do FPS, seria necessário muito trabalho e não teríamos recebido suporte do Id. Eles simplesmente gravaram um CD com o código, deram para os desenvolvedores e os deixaram em paz.

JL: Na minha entrevista com Tim Sweeney, ele chamou o modelo de licenciamento de mecanismo Quake da época de “operação xcopy de 250 milhões de dólares”.

KN: Sim, absolutamente certo! Eu concordo, o motor foi incrível. Naquela época, ele fez uma revolução, mas sabíamos que uma equipe de três engenheiros não seria capaz de reescrever o mecanismo e não poderia escrever o seu próprio. Simplesmente não teríamos tempo suficiente.

Ao mesmo tempo, eu era um grande fã da cena demo de Amiga, C64 e PC. Comecei a assistir a um videogame chamado Unreal e pensei: “Oh meu Deus, sim, há iluminação RGB e 3D completo. O mecanismo usa MMX, SSE e 3DNow. Ele parece muito legal! Como não conseguimos encontrar informações detalhadas sobre ele, planejamos uma viagem à Digital Extremes em Londres (Canadá). Nós nos encontramos com Tim e sua equipe, eles nos mostraram todas as características do motor. Também conheci Carlo Vogelsang , com quem agora trabalho com a Sony - ele está no departamento de Playstation. Ele escreveu o Galaxy Audio Engine: quase tudo em assembler, um cara super-hardcore. O motor tinha um sistema de partículas chamado Fire. Tudo isso estava dentro do motor. Eu pensei: "Gente, eu gosto da sua abordagem".


Naquela época, eles se concentraram em criar ferramentas super convenientes que ninguém havia feito antes. As ferramentas de terremoto eram boas, mas para usuários não técnicos elas não pareciam muito amigáveis. Tínhamos designers que não possuíam habilidades de engenharia e eles precisavam descobrir como usar esses programas.

Então decidimos: “Esses caras têm boas ferramentas, todo mundo nos ajuda muito, existem muitos caras da velha escola que escreveram coisas hardcore nos anos 80. Como é organizado o licenciamento? ” Eles responderam: "Nós nunca fizemos isso antes, para nós é algo novo". Eu acho que naquela época eles não entendiam como criar um modelo de licenciamento. Dissemos: "Temos Warren Spector, e ele quer criar um jogo no seu motor". Quando eles ouviram isso, ficou claro que eles realmente queriam trabalhar conosco.

Honestamente, não me lembro dos detalhes do nosso contrato de licença. Tim provavelmente se lembra. Não lembro quanto pagamos, mas não penso muito. "

JL: Provavelmente comparável a quantos IDs estavam solicitando o Quake naquela época?

KN: Eu penso menos! E isso foi outra vantagem. O motor deles era relativamente novo, mas não fomos os primeiros licenciados. Um dos primeiros foi Wheel of Time e Klingon Honor Guard.

[Nota do autor: você pode ler mais sobre o histórico de licenciamento do Unreal Engine em minha entrevista com Tim Sweeney sobre o Unreal Editor ]

Por isso, decidimos escolher. Os desenvolvedores nos deram o código fonte e disseram: "Nós o apoiaremos o mais rápido possível". Sempre conversamos cara a cara. Em caso de dúvida, enviamos um email: não havia sistema de suporte técnico.

Tivemos muitos problemas porque eles nunca haviam feito isso antes. Enviámos a eles muitos códigos e perguntas, tivemos uma longa correspondência e recebemos atualizações. Mas acredito que foi a decisão certa. Acho que se escolhermos o Quake, o jogo seria muito mais difícil de criar.

Além disso, tornei-me membro do Unreal Tech Advisory Group. Tivemos a ideia da primeira reunião técnica, na qual os chefes de todas as empresas que se tornaram licenciadas (havia quatro na época) se reuniram, discutiram maneiras de melhorar o motor, censuraram Tim por aspectos inconvenientes, resolvidos com álcool e comida, bem, tudo é como normalmente. Eu ainda mantenho contato com todas essas pessoas.

JL: Você compartilhou alguma coisa com outros membros do Unreal Tech Advisory Group?

KN: Eu acho que nós compartilhamos principalmente melhorias para o Unreal Editor. O motor era excelente, mas ele ainda tinha um longo caminho a percorrer. Então, quando conseguimos contratar ainda mais designers e artistas, eles também começaram a fazer sugestões para melhorar os processos de trabalho. Nós os implementamos ou os enviamos para a equipe da Unreal, ou perguntamos à equipe da Unreal se eles poderiam fazer isso mais rápido do que nós.

Fizemos muitas alterações no editor principal, mas a maioria estava relacionada apenas ao nosso jogo. Nós compartilhamos algumas das melhorias, mas a maioria dos outros desenvolvedores estava envolvida em jogos completamente diferentes.

Eu tive que escrever um monte de sistemas que eu acho que foram os primeiros de seu tipo. Pelo menos eu nunca os vi. Por exemplo, um sistema de mistura de animação; essencialmente, é assim que os alvos de transformação ou formas de mistura são chamados hoje. Não lembro de ninguém fazendo isso em jogos naquele momento. Ele já pode ter sido implementado em algum lugar, mas antes do amplo uso da Internet, o compartilhamento de informações era muito difícil.

JL: Você pode falar sobre as alterações feitas no Unreal Editor?

KN: Um dos sistemas, que por algum motivo não estava no editor na época, é a visualização dos splines das câmeras.

Nas primeiras versões do UnrealEd, você teve que arrastar a câmera e definir os pontos de seu caminho. Nesse caso, foi possível ver os pontos, mas não as conexões entre eles, que determinavam o caminho da câmera.


JL: É como um jogo ponto a ponto, mas sem números!

KN: Exatamente! O spline tinha pontos de interrupção e os designers nem sempre conseguiam descobrir como seria o caminho. Eles queriam saber com muita precisão como a câmera se moveria ao longo do caminho. Então eu adicionei este sistema e eles gostaram.

Foi muito simples. Quero dizer a simplicidade do código: desenhe os eixos de coordenadas em cada ponto de controle principal e depois desenhe o ponto de controle para realmente ver para onde foi. Isso realmente ajudou o designer, e criar um sistema assim era muito simples. Não sei por que tivemos que adicioná-lo. Eu acho que Tim não achava que ela seria realmente necessária.

DL: Isso é engraçado, porque se você se lembra da primeira demo do jogo Unreal ao público, a primeira coisa que as pessoas viram foi uma câmera voando pelo castelo, ou seja, era improvável que a Epic tenha criado caminhos de câmera.


KN: Acho que o motivo foi que muitos de seus designers de nível eram super técnicos e estavam acostumados a simular essas coisas em suas cabeças. Mas a indústria de videogames amadureceu gradualmente, por isso foi necessário criar ferramentas para pessoas com diferentes níveis de experiência. Nem todo designer era engenheiro, e hoje ainda mais! Esta foi a exceção e não a regra. Portanto, a ferramenta deve ter se tornado conveniente e simples.

A propósito, ainda não sei por que Pawn é indicado pela cabeça de um dinossauro.

JL: [risos] Sim, Tim e eu discutimos isso em uma entrevista! A propósito, você se arrependeu de alguma decisão tecnológica que tomou?

KN: Usamos muito o UnrealScript. Este foi um dos erros. O UnrealScript era muito flexível, mas muito lento. Precisávamos escrever muito mais em C nativo do que em UnrealScript.

Norte verdadeiro e falhas falsas

[Nota do autor: nesta fase da entrevista, abri o Deus Ex Editor (versão para UnrealEd), bem como a documentação do Deus Ex SDK]

JL: O instalador do Deus Ex SDK possui uma pasta Docs com alguns arquivos de documentação que você, Robert White, Sheldon Pacotti, Al Yarusso e Scott Martin parecem estar patrocinando. Você pode dizer quem eram essas pessoas e no que elas trabalhavam?

KN: Al estava envolvido no editor de diálogo. Scott trabalhou em IA. Eu fiz ... tudo . [risos] Entre outras coisas, eu fui assistente de direção e programadora principal. Mas fizemos um pouco de tudo, porque em todo o projeto, do início ao fim, havia apenas três engenheiros.


Chris Norden (canto inferior esquerdo), El Yarusso (lado direito e superior de Chris, com um relógio na mão), Robert White (fila do meio, ligeiramente à direita do centro, usando óculos escuros), Sheldon Pacotti (canto inferior direito) e Scott Martin (no segundo fileira, à direita, também em óculos de sol)

DL: Há uma seção na documentação do editor que diz "O Unreal não possui suporte nativo para escadas verticais, mas elas são adicionadas ao Deus Ex". Você pode nos contar mais sobre isso?

KN: As escadas são uma história interessante, porque tivemos que nos mover pelo nível, e nos atiradores em primeira pessoa da época, escadas inclinadas e subidas suaves eram tradicionalmente usadas para isso.

Um dos decretos de Warren (porque o design é a lei!) Disse que um jogador deveria ser capaz de completar qualquer missão de qualquer maneira. A idéia principal do jogo era que, se você quiser, pode passar por isso inteiro, nunca disparando. Na verdade, não tivemos sucesso - existem várias zonas em que você precisa filmar algumas vezes, mas estávamos muito perto.

DL: Eu acho que os desenvolvedores tiveram sucesso nas sequências.

KN: Sim, provavelmente.

Portanto, o jogador deveria ter conseguido passar o jogo inteiro sem disparar um tiro. Além disso, ele poderia passar o jogo inteiro sem fazer nada além de atirar. O jogador poderia passar o jogo inteiro para que nunca fosse detectado pelo inimigo. Foi possível passar por isso de maneiras completamente diferentes.

JL: A falta de escadas verticais foi um dos tópicos que você discutiu com Tim nas reuniões do Unreal Tech Advisory Group?

KN: Para responder, preciso encontrar e procurar no código do script se ele diz "Foda-se, Tim!" [risos], porque foi exatamente isso que fizemos quando estávamos com raiva - escrevemos comentários para lembrar disso mais tarde.

Quando começamos a pensar em como adicionar suporte para escadas verticais, pensamos primeiro em "vamos criar a geometria e, em seguida, talvez possamos fazer truques físicos complicados para que o jogador possa agarrar as barras com animação sincronizada". Mas depois que decidimos - bem, isso é tudo para o inferno, muito complicado.

JL: [risos]

KN: Tivemos que fazer isso muito rapidamente, porque os designers exigiram criar essa mecânica.

Portanto, como resultado, tive que usar hacks infernais. O mecanismo teve o conceito de "grupos de textura". Essencialmente, é um rótulo de string atribuído a certos tipos de texturas para facilitar sua classificação. Poderíamos solicitá-los em código. Então pensamos: "por que os artistas não fazem apenas algumas texturas para poderem ser escaladas?" Depois disso, simplesmente os adicionamos ao grupo de texturas, realizamos um raycast para reconhecê-los e, em seguida, com algumas restrições, o jogador foi preso na direção de seu movimento. Isso funcionou bem, mas nem sempre é perfeito, porque quando o jogador subia ao topo da textura, o feixe não era mais emitido, e precisávamos empurrá-lo para cima e para a plataforma. Ou seja, a solução é imperfeita, mas como resultado funcionou. Foi um truque barato e fácil.

Os leitores de hoje podem pensar: por que não havia escadas no motor, isso é lógico? Mas naqueles dias não havia nada. Estes eram apenas fragmentos BSP, não tínhamos malhas estáticas, não havia nada disso.


JL: O UnrealEd tinha um gerador de escada em espiral muito legal [risos], mas não havia escadas verticais.

KN: Sim, certo ... Parece que criticamos os designers por usá-lo, porque ele criou buracos no BSP. A escada parecia linda se não houvesse nada por perto. Porém, assim que você começa a fazer fatias angulares no BSP, você pode obter pequenos orifícios no BSP pelos quais pode passar, mas os orifícios em si não são visíveis. Essa função causou muita dor e proibimos seu uso. Parecia bom, mas estava quebrado ...

JL: A documentação também descreve uma classe chamada DeusExLevelInfo que contém informações sobre o mapa (por exemplo, é multiusuário), o nome do autor do mapa, o local da missão, o número da missão e assim por diante. Mas gostaria de perguntar sobre o TrueNorth.

KN: [risos] Era um tipo de BAM do motor Unreal: Binary Angle Measurement!

JL: Quais são esses números loucos ?!

KN: Naquela época, as operações de ponto flutuante eram muito caras. O ferro estava fraco, mas não havia memória suficiente. 360 graus não foram descritos por um número de 8 bits, que forneceria 255 unidades de precisão, ou seja, cerca de 1,4 graus por unidade, o que não seria suficiente. Tim usou um número de 16 bits para orientações, o que proporcionou maior precisão.

Para um programador, todos esses números são bastante simples. Estes são apenas poderes de dois, sem problemas, você pode calcular todos eles na sua cabeça. Mas designers e artistas estavam tendo problemas. Portanto, criamos pequenas simplificações para ajudar os desenvolvedores a lembrá-las.

[Enquanto trabalhamos com o editor, Chris chegou à aula de decorações]



KN: Decorações também foi uma classe enorme. Todas as malhas com as quais você pode interagir são decoração. Ou seja, quase tudo no jogo!

JL: Na seção Decorações da documentação, dizemos: "Avisamos que, se você alterar alguns dos campos não listados abaixo, o editor poderá falhar". Não se lembra por que isso aconteceu?

KN: [risos] Sinceramente, não me lembro. Eu acho que porque a Decoração era uma classe tão grande e tinha tantas funções épicas que interagiram com o mecanismo de uma maneira estranha que, em vez de explicar a um designer que não entende as sutilezas técnicas por que um determinado campo pode levar a um comportamento inesperado, simplesmente eles disseram "não use, caso contrário, o editor trava".

JL: [risos]

KN: Algo como táticas de susto. Nas reuniões de programadores, nos perguntamos: como explicar aos usuários que isso levaria a danos à cadeia BSP, e você precisa fazer isso e aquilo? Vamos apenas dizer a eles que o editor falhará.

Eu deveria estudar o código novamente, mas parece que somos até culpados de esconder falhas deliberadas em alguns lugares, a fim de assustar os usuários que são enganados profundamente.

JL: Vamos seguir em frente. A seção ParticleGenerator diz: "Uma das principais funções é que ele pode ser ativado e desativado usando gatilhos e não gatilhos". Ou seja, na versão do mecanismo Unreal com o qual você trabalhou, era impossível ativar e desativar as partículas?

KN: Naquela época, não. Se você inseriu um sistema de partículas, ele estava presente constantemente e nunca foi desligado. Parece-me que esta é uma supervisão estranha.

Caso contrário, o sistema de partículas irreais foi incrível. A maioria foi escrita em assembler. Foi processual e escrito muito bem em comparação com todo o resto. Designers a amavam. De fato, até demais. Era possível matar toda a taxa de quadros, e eles enlouqueceram, adicionando camadas cada vez mais transparentes.

Naquela época, ainda tínhamos que suportar a renderização de software, enquanto a renderização de hardware ainda não era generalizada. Tim tinha habilidades de programação incríveis e escreveu um ótimo renderizador de software, ele foi ótimo.

[Observando diferentes objetos no jogo, notei uma categoria com um nome incomum no painel Propriedades]

DL: O que é essa propriedade Smell?

KN: Os animais precisavam de um perfume para rastrear. De fato, os cães podem rastrear nós de odor. Se bem me lembro, ao passar pelos níveis, o jogador poderia deixar nós de odor que estavam ativos por um certo tempo. Por isso, fizemos isso para que os cães pudessem cheirá-lo.

DL: Ou seja, se você se esconder atrás de uma caixa, as pessoas não o encontrarão, mas os cães podem ...

KN: Precisamente porque é isso que acontece na realidade, e pensamos que seria um aspecto interessante da jogabilidade. No entanto, parece que no final ele foi cortado. Como não havia feedback gráfico, esse conceito era difícil de explicar ao jogador.



[ Intro, — , . ]

: . . ...



KN: Não, os espelhos eram reais! Como eram muito lentos, pedimos aos designers que os usassem raramente, no entanto, esses são espelhos reais.

De fato, quando escrevi o código do laser ... [risos]

DL: [risos] Eu vejo o que você está vendo ...

KN: ... eu realmente tive que procurar espelhos. Eu tinha um nível de teste em que testei o código para todos os dispositivos. Quando escrevi o código do ponteiro laser, criei uma bola de discoteca com espelho refletivo e construí uma sala com espelhos nas duas extremidades. Peguei o ponteiro laser, apontei para a bola de discoteca e funcionou!

Claro, a taxa de quadros caiu abaixo do nada, porque eu tive que rastrear todas as linhas ...

Veja a onda de luz: ferramenta de linha de comando LWO23D

[Nota do autor: LWO significa Lightwave Object. Este é o formato de geometria 3D do pacote de software Lightwave 3D da Newtek , também baseado no Texas, como a equipe de Deus Ex na época]



Captura de tela do Deus Ex Lab da Tack

JL: Por que sua equipe decidiu usar o Lightwave?

KN: Nossos artistas o conheciam bem. Portanto, tivemos que nos adaptar.

JL: Conte-nos mais sobre por que você escreveu o exportador como uma ferramenta de linha de comando.

KN: Naquela época, e mesmo agora, muitas vezes escrevo pequenas ferramentas de linha de comando para automatizar tarefas. Eu sou um programador da velha escola e não gosto de complicações desnecessárias. Eu principalmente não gosto de C ++. Eu não gosto de padrões. Não gosto de tudo que leva tempo.

Quando escrevo ferramentas de linha de comando, crio um arquivo em lotes do Win32, livre-me de tudo o que está embutido, inicio com um arquivo vazio, com int main() , e apenas prossigo. Esta é uma solução rápida e portátil que não causa problemas.

DL: Eu acho que exportar malhas estáticas foi um processo bastante padrão. Mas conte-nos como você exportou a animação.



Captura de tela do Deus Ex Lab da Tack

KN: Não houve animação esquelética no jogo. Não conheço um único mecanismo da época em que ele é implementado. Portanto, tudo foi feito através da mistura de vértices. Esfolar era muito caro na época. Sem GPUs, tudo tinha que ser calculado na CPU e, por qualquer meio, evitado cálculos de ponto flutuante.

Dentro do Lightwave, os designers criaram animação esquelética e exibiram seus quadros-chave. Era necessário criar uma pose em T, porque para misturar animações era necessário começar de uma base comum. Ou seja, para a combinação certa, as animações foram essencialmente compensadas pela pose em T. A mistura foi realizada no lado do motor.

JL: Então, na Unreal, tudo fez o mesmo?

KN: Provavelmente sim. Não acho que o Tim tenha adicionado animação esquelética à próxima versão.

Talking Heads: ConvEdit e Lipsink

[Agora abrimos a pasta ConvEdit]


JL: Conte-nos sobre o ConvEdit

KN: Foi idéia de Al, ele escreveu no Visual Basic.

JL: Como UnrealEd naquela época.

Sim, naquela época não havia muitas oportunidades para a implementação simples da interface. Havia Delphi e vários outros frameworks de interface do usuário. Se você não os usou, teve que escrever tudo de forma nativa, por exemplo, na API do Win32, GDI e tudo mais. Foi um grande problema.

Ou seja, o Visual Basic, que hoje parece bastante primitivo, na época era muito bom - uma estrutura visual simples com sua própria linguagem de programação, semelhante ao Basic, o antecessor do C #. Ele nos permitiu criar protótipos de funções e escrever ferramentas muito rapidamente.

[Nota: Se você está interessado em saber como o Visual Basic foi usado nas ferramentas de desenvolvimento de jogos daquela época, leia minha entrevista com Tim Sweeney sobre o Unreal Editor ]

Foi usado principalmente por Sheldon. Ele precisava de ferramentas para controlar a câmera, ferramentas para controlar sons. Ele queria usar muitas ferramentas cinematográficas que ninguém havia usado antes. Eu aprendi pela primeira vez o que é o zoom na tribuna, trabalhando neste jogo com Sheldon.

Eu acho que ainda hoje essa ferramenta ainda é usada.

A propósito, Sheldon tinha síndrome do punho do túnel (LER, Lesão por Esforço Repetitivo), de modo que o selo se tornou uma tortura para ele. Ele quase completamente trabalhou em Deus Ex usando a transcrição de voz em Dragon Dictate, que na época era muito pior do que hoje. Sheldon até teve que usar órteses, porque a síndrome era muito forte.




JL: Uau! Eu não sabia O jogo teve muitos diálogos e um monte de galhos ...

KN: Uma enorme quantidade de dados, mesmo para uma missão.

Sheldon queria ter um forte controle sobre o jogo e muitos diálogos interativos. Ele queria que o jogador fizesse uma escolha significativa. Ele e Warren odiavam ter que clicar nas caixas de diálogo sem escolha. Eles queriam que o jogador interagisse com os personagens e escolhesse coisas significativas, para que o jogo colocasse bandeiras e lembrasse como ele interagia com os personagens e se comportou durante a passagem.

JL: Desde o primeiro passo a passo de Deus Ex, lembro-me do briefing de Anna Navarre em seu escritório. Como sempre em qualquer videogame, comecei a correr pelo escritório fazendo todo tipo de besteira até os NPCs terminarem o diálogo. De repente, ela parou o diálogo, virou-se para mim e perguntou: "O que diabos você está fazendo?"

KN: [risos]

DL: Por um segundo eu congelei e me perguntei: “Foi isso o que realmente aconteceu?” Foi um evento tão significativo para mim em termos de imersão no jogo. Nem um único jogo antes deste já ter se encontrado. Suspeito que isso se deva em parte ao Editor de conversas.

KN: Um dos preceitos de Warren era: "Se um jogador está no escritório de alguém, se comporta como animais e quebra coisas, então o personagem deve dizer alguma coisa!" Ele não deve ignorar o jogador, porque isso não é realista. "

JL: Houve algum aspecto relacionado à cena para o qual foi especialmente difícil criar ferramentas?

KN: Tivemos muitos diálogos, e todos foram dublados. Passamos semanas em um estúdio de gravação gravando diálogos com atores. Isso significava que precisamos pensar em sincronizar o movimento dos lábios (lipsyne). Pensei: "Como criar um lipSink para tantas caixas de diálogo?" Afinal, não tínhamos apenas um monte de frases, mas também várias línguas.

Naquela época, não havia muitas ferramentas para ajudar no reboco. A maioria dos desenvolvedores executou o pré-processamento: eles executaram a caixa de diálogo na ferramenta, exibiram um arquivo de dados e depois o reproduziram. Mas decidi: "Não teremos tempo para isso e, se você precisar regravar a voz, precisará reprocessar tudo novamente".

Então comecei a pensar que deve haver alguma maneira de fazer isso em tempo real usando a análise dinâmica de som. Na faculdade, estudei engenharia elétrica e decidi descobrir sozinho, sem contar a ninguém.

JL: [risos]

KN: Pensei: "Vamos ver se consigo fazer isso e surpreender a todos". Novamente, não acho que alguém tenha feito algo assim antes, mas hoje essa técnica está em todo lugar.

Naquela época, de tudo o que vi, o mais próximo de um sistema desse tipo era o Half-Life. Os desenvolvedores usaram a técnica Envelope Following, que literalmente era essa: abra e feche sua boca, dependendo do volume do som. O sistema funcionou, mas não parecia muito realista.

JL: Na verdade, foi um "tremor na mandíbula".

KN: Sim, exatamente, exatamente.

Lembro que certa vez discuti com Gabe Newell como eles realizaram essa tarefa e ele disse: “Oh, basta usar o Envelope Following , e isso será suficiente. Tudo o resto será muito complicado.

Depois voltei para casa e comecei a estimar cálculos matemáticos e depois escrevi um sistema que executava FFT ( transformada rápida de Fourier ). Repito, enquanto os cálculos de ponto flutuante eram muito caros e provavelmente escrevi uma aproximação inteira simulando-os.

Ela analisou em tempo real um pequeno pedaço de gravação de áudio e extraiu os principais componentes de frequência e depois os vinculou a seis a sete fonemas diferentes.

Secretamente, pedi a um dos artistas que simulasse várias formas de mistura (formas de mistura): eu precisava de lábios fechados "oh", "a", etc. Ele perguntou o porquê e eu respondi que ele simplesmente fez isso e me deu os dados.



Transformação rápida de Fourier (imagem da Wikipedia) e série de fonemas Preston Blair

JL: [risos] Essa parece ser a combinação perfeita para o mix de animações que você usou em Deus Ex.

KN: Sim, exatamente, perfeito.

Então, ele me deu os dados, escrevi cálculos matemáticos e, como pude, manualmente, anexei os formulários. Eu não fiz nenhuma pesquisa séria, e o sistema era muito caro em termos de desempenho.

Criei um nível de teste com uma cabeça enorme no meio e alimentei algumas linhas com ela. Eu verifiquei a frase em alemão, em inglês, em francês e tudo sincronizou perfeitamente. Eu pensei: “Droga, isso é incrível! Realmente funcionou!

Encontrei Warren e disse a ele: "Quero mostrar uma coisa legal". Parece que ele estava atordoado. [Risos] Ele me perguntou: “Que diabos, podemos colocar isso no jogo? É simplesmente incrível! ”

Como resultado, lançamos um jogo com esse sistema, mas por uma questão de desempenho, tive que reduzi-lo bastante, devido ao qual a qualidade visual diminuiu. Mas meu primeiro nível de teste foi ótimo. Ainda acredito que esse foi o primeiro sistema de sincronização labial em tempo real. Não lembro de ninguém fazendo isso antes.

Talvez valesse a pena patentear. Mas não acredito em patentes de software porque acho uma prática cruel ...

Também tive uma grande discussão com um dos diretores de arte de Dallas, que queria usar esse sistema na Anacronox. Ela deveria ter saído antes do nosso jogo. Eu disse: "Não vou me importar em compartilhar, mas quero que Deus Ex seja o primeiro jogo em que ele aparecer". Ele disse: "Não, você deve nos dar!" Ele praticamente gritou para nós no corredor. Eu respondi: "Não, não deveria", e Warren me apoiou. Aconteceu que lançamos o jogo primeiro, então isso não era importante. Na verdade, acho que, como resultado, eles implementaram independentemente sua própria versão do sistema, porque não queríamos revelar isso. Pode ter sido egoísta, mas eu queria que nos graduássemos primeiro para podermos demonstrar esse recurso.

Todo o resto produzido por Ion Storm foi desenvolvido em Dallas: Domínio: Tempestade sobre o Presente 3 , Daikatana , Anacronox - tudo foi feito em Dallas. Somente Deus Ex foi criado em Austin, e havia apenas nossa equipe, mais ninguém. Estávamos em uma bolha, bastante isolados do escritório em Dallas, e isso foi feito de propósito. Não queríamos mexer com um monte ... Serei sincero, com um monte de todo o lixo deles. Essa separação foi completamente intencional e muito importante para nós. Nossa equipe e suas equipes não trocaram tecnologias, nenhum contato real.

Conclusão

DL: Então, para resumir, quero perguntar: se você pudesse dar conselhos aos desenvolvedores de ferramentas que estão lendo este artigo, o que você diria?

KN: Ouça o seu cliente. Nunca escreva ferramentas no vácuo. Como engenheiro, você pode pensar: "Eu posso usar essa ferramenta dessa maneira, e esse método é mais eficaz, então escreverei dessa maneira".

Mas quase sempre você está enganado. Você deve ouvir designers e artistas porque o fluxo de trabalho é muito diferente. Eles funcionam completamente diferente do que o resto. A ferramenta não será usada por você, na maioria das vezes é para eles.

DL: Você já conheceu essa mentalidade nas equipes com as quais trabalhou? E como você lidou com isso?

KN: Você só precisa dizer aos programadores: “Por que você acha que o usuário tem esse problema? Você acha que o problema está no código? Ou talvez o problema seja a estrutura da tela? A fonte é muito pequena? Cor do botão errado? Talvez você esteja fazendo algo fora do padrão?

Porque se você olhar para a maioria das ferramentas com um design profissional, geralmente elas são bastante consistentes. Existem guias de design sobre como as coisas devem funcionar.

A equipe criativa deve poder usar essas ferramentas. Não deve ser que eles tenham que ler a documentação. Em um mundo ideal, tudo deve ser óbvio.

Hoje existem designers de UX / UI, mas na época não havia nenhum, então tivemos que criar o design da interface, mas com o feedback dos usuários.

Então, sente-se ao lado dos usuários e veja como eles usam a ferramenta. Vimos como eles funcionam no Lightwave. Quando escrevemos a primeira versão da ferramenta, nos sentamos por perto, sem perguntar o que fazer e olhamos para eles, fazendo anotações como “houve dificuldades com isso” ou “eles constantemente precisam entrar no menu para descobrir isso” ou “talvez vale a pena torná-lo uma tecla de atalho ". Basta olhar para eles, aprender e se adaptar.

Ou seja, você realmente deve pensar no fluxo de trabalho dos designers. É necessário minimizar movimentos desnecessários, minimizar o rastreamento no menu, tentar adicionar teclas de atalho. Promovemos ativamente os atalhos de teclado para todas as funções, porque eles aceleram o fluxo de trabalho. No processo de aprendizado da ferramenta, você acelera bastante o trabalho com a ajuda de teclas de atalho e não precisa subir no menu.

Não é preciso cair na armadilha clássica dos engenheiros: “É melhor eu saber, escrevi o instrumento, sei como ele funciona. Se você não pode usá-lo, é apenas um idiota. Essa é a pior coisa que pode acontecer ao desenvolver uma ferramenta.

JL: Excelentes conselhos. Muito obrigado Chris!