Qual foi o primeiro editor irreal

Retrospectivas de jogos clássicos recentemente se tornaram populares, mas raramente lembram as ferramentas de desenvolvimento clássicas. Consegui conversar com Tim Sweeney sobre a primeira versão do Unreal Editor , ou UnrealEd .

BSP e falácias: "Precisamos escrever nosso próprio editor"

David Lightbone: Obrigado por reservar um tempo para falar comigo, Tim! Vamos começar desde os primeiros dias do Unreal Editor. Eu li que James Schmaltz, o criador do Epic Pinball , mostrou o jogo em que ele trabalhou e, quando você o viu, sugeri a criação de um editor para ele. Está tudo bem?

Tim Sweeney: Exatamente! Ele foi inspirado no jogo Bullfrog Magic Carpet . James é um desenvolvedor incrivelmente talentoso, mas ele só escreveu código em linguagem assembly, não queria aprender C. [risos] Assim, ele escreveu esse mecanismo 3D em puro assembler que representava o fundo de relevo e os objetos do jogo. Ele não queria criar um editor, então criou manualmente uma árvore BSP e colocou uma cápsula nesse alívio. Quando vi isso, eu disse: "Não, não, não, James, James ... você tem que fazer algo completamente diferente". (risos)



James Schmalz e Bullfrog Magic Carpet

Eu disse que escreveria um editor e, por incrível que pareça, comecei a criar a interface do usuário do Unreal Editor a partir do layout da interface do usuário no Visual Basic. Ele tinha uma interface de comando baseada em texto para se comunicar com um mecanismo C ++ que era renderizado. Então, escrevi um editor de estrutura de arame e o desenvolvimento continuou nessa base.

Ou seja, foi um processo de estudo interessante. Eu pensei em escrever este editor e integrá-lo ao renderizador de James. Uma vez perguntei a ele: “Você pode me enviar o código? Eu quero entender como integrar o renderizador ". E ele me enviou 30 mil linhas de código assembler. [risos] No mecanismo de renderização em 3D, havia alguns elementos do Epic Pinball e algum código de montador anterior, que ele simplesmente copiou. Pensei: “Meu Deus, que tipo de caos é esse? Não quero tocar nisso! " (risos)

Mas eu disse a mim mesma que, antes de começar a descobrir, escreveria apenas uma pequena ferramenta de mapeamento de textura. Então, li o artigo de Michael Abrash sobre mapeamento de texturas e estudei o código que Billy Zelsnack compartilhou. A texturização acabou sendo um tópico bastante simples, então decidi: "Vou tentar lidar com tudo isso".

Antes de implementar a iluminação, uma parte importante da magia das versões anteriores do Unreal Editor era a criação de uma árvore BSP em tempo real. A ideia era que você pudesse mudar a posição dos pincéis no espaço 3D, após o qual todo o trabalho de geração de BSPs foi completamente atualizado em tempo real.


As oportunidades oferecidas por essa função não se encaixavam na minha cabeça e, apenas para mostrar todo o seu poder, criei essa ferramenta para criar tori. Entrei em contato com James, que, lembro-me, construiu seus BSPs manualmente e disse a ele: "Confira". Criei dois toros conectados e os subtraí do mundo. Ele disse: “Uau, isso não pode ser! Isso é demais. Este foi um verdadeiro exemplo de obstinação do programador.

JL: Falando em BSP, pelo que entendi, John Carmack foi um dos primeiros a começar a usar o BSP em mecanismos de jogos e a idéia de trabalhar com o BSP era bastante nova para a indústria de jogos da época.

TS: Carmack escreveu um editor realmente poderoso no NeXT . Eu li todas as informações sobre ele e vi capturas de tela, mas nunca as usei. Naquela época, pensei: "Uau, Carmack escreveu um editor de BSP em tempo real!" O que eu não entendi foi que, na verdade, não funcionou em tempo real, houve um processo de pré-montagem e outras operações. Eu não sabia disso e pensei que ele havia criado um editor que funcionava completamente em tempo real, então ele também escreveu o mesmo. (risos)



QuakeEd no NeXT e John Carmack

JL: [risos] Você pensou que ele era tão poderoso, então aceitou o desafio.

TS: Sim! Muitas das características do Unreal surgiram devido ao meu mal-entendido sobre o que outras pessoas fizeram.

Além disso, um grupo de ex-fabricantes de demo da Future Crew montou uma empresa de equipamentos e lançou algumas capturas de tela com iluminação surround incrivelmente realista em uma cena interna. Havia fontes de luz com grandes esferas ao redor, e a iluminação volumétrica foi claramente cortada por toda a geometria ao seu redor. Parecia fisicamente perfeitamente preciso. Pensei: "Deus, nunca vi nada assim, preciso descobrir isso!"

Então comecei a entender e percebi que precisava calcular a integral linear da câmera para todos os pontos da tela. Na faculdade, estudei matemática, então disse a mim mesmo: "Eu tenho que ter sucesso". Então, deduzi uma fórmula para isso com algumas trigonometrias insanamente complicadas. Eu o implementei no código, mas foi cem vezes mais lento que o necessário. Então percebi: "Pare, eu posso fazer esses cálculos no espaço do mapa de luz", porque o mapa de luz é uma discretização da geometria em pequenos fragmentos. Transferi os cálculos para mapas de iluminação e implementei tudo em tempo real.



Exemplos de iluminação da Unreal com base em mapas de iluminação

Tirei uma captura de tela e enviei para um amigo da Finlândia, que trabalhava para aquela empresa de equipamentos. Ele respondeu: “Uau, isso é incrível! Mas nossa imagem é apenas uma renderização do 3D Studio Max, porque não conseguimos entender como fazer isso em tempo real. " (risos)

JL: [risos] Sim!

[Nota do autor: a empresa sobre a qual Tim está falando é a Bit Boys ]

TS: Ou seja, o Unreal Engine acabou sendo o primeiro mecanismo de iluminação volumétrica do mundo, como eu acho ... e foi baseado na minha falácia.

Foi um momento incrível no início da história da indústria de jogos, porque o 3D estava apenas começando a ser possível. Vários renderizadores de software já foram escritos, mas ninguém conseguiu resolver problemas de larga escala: como fazer a iluminação funcionar em um grande mundo, como fazer a geometria em tempo real funcionar em um grande mundo. Esse processo de desenvolvimento ocorreu em grandes saltos: Carmack implementou novas idéias malucas, eu percebi novas idéias malucas e constantemente lançamos capturas de tela do que somos capazes.

Se você observar agora, em apenas quatro anos, recriamos cerca de 20 anos de pesquisas nas décadas de 1980 e 1990, que antes eram possíveis apenas através de cálculos preliminares, e não em tempo real.

JL: Sim, como a idéia de BSP foi baseada em um artigo escrito em 1969.

TS: Exatamente, antes do meu nascimento!

TurboPascal e Maya: inspiração irreal

JL: Quais fontes de inspiração você usou para desenvolver a filosofia de design do Unreal Editor?

TS: Havia apenas algumas fontes de inspiração.

Se você olhar para o jogo ZZT , lançado em 1991, verá o conjunto básico de funções do Unreal Engine. Em essência, é um mecanismo de jogo com um jogo incorporado a ele. O jogo possui uma pequena linguagem de script, que, apesar de sua simplicidade, era uma linguagem totalmente com script que lhe permitia escrever pequenos scripts de jogo.

[Nota do autor: Detalhes do ZZT podem ser encontrados no livro de Anna Anthropy publicado pela Boss Fight Books]

O jogo tinha um editor interativo em tempo real WYSIWYG para criar níveis. Ao pressionar algumas teclas, você pode se mover, adicionar níveis e verificá-los no jogo e processá-los. Um fluxo de trabalho tão interativo foi uma característica essencial do jogo.



ZZT, modo de jogo e modo de editor

Outra inspiração foi o Turbo Pascal , que foi a primeira ferramenta de desenvolvimento que eu realmente amei. Era um editor muito fácil de usar para criar código e compilar. Você acabou de inserir o código e, após alguns segundos, ele já compilou e o executou. O processo iterativo de criação de programas foi incrível comparado ao que eu estava acostumado naquele momento. Se você observar a implementação do ZZT, ela realmente se parece com uma versão em texto do Unreal Engine. Todo o modelo da Unreal foi inspirado por ele.

Há outra fonte séria de inspiração que levou à criação de muitos elementos de design do mecanismo: o Visual Basic, semelhante ao clone da Microsoft Delphi, ou seja, a versão do Object Pascal para Windows com edição na interface visual da Borland. Mas nunca usei o Delphi, só trabalhei no Visual Basic.

A ideia era que o usuário tivesse um editor de formulários, ele desenha elementos, campos e tudo o mais, e depois clica neles e abre o código. O código aparece imediatamente e o usuário simplesmente continua a inseri-lo e continua a trabalhar.



TurboPascal by Borland

Transferi esses princípios para a Unreal: você pode simplesmente arrastar um objeto para um nível, clicar duas vezes nele para abrir o editor de scripts, inserir o script e salvá-lo. Para começar a escrever código, criar objetos tridimensionais e fazer tudo em tempo real, basta apenas alguns cliques do mouse.

Outro aspecto importante no desenvolvimento do Unreal foi que a Epic comprou várias estações de trabalho Silicon Graphics que lançaram a primeira versão do Maya. O Maya estava completamente desatualizado na época, mas havia um modo 3D interativo com um espaço de fundo azul-vermelho-preto no qual objetos e estruturas de arame eram desenhados em tempo real. Isso não pôde ser feito por nenhum programa no PC; todos eles estão presos no código legado e nos padrões de interface do usuário legados.



Então, a primeira coisa que fiz quando comecei a trabalhar no Unreal Editor foi criar um fundo preto com linhas azuis e vermelhas, copiando o Maya. Eu escrevi um procedimento para desenhar linhas e criei contornos tridimensionais de estrutura de arame de todos os objetos. Esse foi o exemplo que me inspirou, o que provou que era possível.

Do Visual Basic ao Slate: evolução da interface UnrealEd

[Nota do autor: no início da entrevista, lancei o UnrealEd 1 em uma máquina virtual no meu laptop. Passei um mouse para Tim para que ele pudesse trabalhar nela.]

TS: Uau, ótimo, você já o lançou!

JL: Sim! Eu apresentei que a versão que vemos aqui é o Visual Basic.

TS: Sim, sim!

[Nota do autor: Tim ficou feliz quando criou o nível do zero. Do lado de fora, parecia uma reunião de amigos que não eram vistos há muito tempo.]

JL: O que o levou a usar o Visual Basic para desenvolver a interface para a primeira versão do UnrealEd e quais outras opções você tinha?



Alan Cooper e Visual Basic

TS: Isso foi em 1995. Naquele momento, as estruturas de interface do usuário para C ++ eram simplesmente terríveis. Havia o Microsoft Foundation Classes, que era a parte mais miserável da API que você poderia imaginar. O usuário começou a desenhar controles de janela e a estrutura criou enormes quantidades de código C ++ com montes de comentários como: "aqui criamos um controle para você!" Se o usuário moveu o objeto, a estrutura atualizou parte do código, mas não as outras partes, e ele quebrou constantemente, então eu disse a mim mesmo: "Não tocarei mais nisso".

O Visual Basic foi uma excelente ferramenta para o desenvolvimento de uma interface de usuário na qual você poderia colocar com eficiência todos os controles, itens de menu e partes da interface do usuário. Foi o kit de ferramentas mais produtivo para a interface do usuário que eu já vi, principalmente porque era um programa interconectado muito claro: você desenhou uma interface do usuário, clicou nela e adicionou um código simples para sua interação. Percebi que é muito mais fácil criar uma interface do usuário e transmiti-la ao C ++ por meio da interface da linha de comando, enviando texto para frente e para trás, como uma maneira de serializar dados. Acho que a situação não mudou por cerca de uma dúzia de anos, até que no início dos anos 2000 kits de ferramentas de interface do usuário decentes para C ++, como Qt e similares, começaram a aparecer.

[Nota do autor: A primeira versão do Visual Basic foi desenvolvida por Alan Cooper , frequentemente chamado de " pai do Visual Basic ". Ele também é uma figura importante no campo da usabilidade e experiência do usuário]



UnrealEd 3, no qual os elementos wxWidgets estavam presentes

DL : Eu acho que, com o tempo, partes do editor começaram a ser substituídas por outras. Como essa evolução aconteceu?

TS: Depois de concluir o Unreal Editor 1, eu me acalmei e fiz várias pesquisas de nova geração que geralmente não deram frutos até Warren Marshall aparecer, que reescreveu partes do Visual Basic no Unreal Editor com C ++ usando wxWidgets . wxWidgets que naquela época era o melhor kit de ferramentas. Isso se tornou a base para a estrutura da interface do usuário no Unreal Editor 2.

No meio do processo de desenvolvimento do Unreal Engine 2, o código do Visual Basic desapareceu completamente do mecanismo. Tínhamos uma estrutura C ++ mais conveniente e limpa. Assim, temos quase a mesma interface do usuário, mas sem dificuldades de idioma. Mas o problema real era que o wxWidgets não se desenvolveu e outros kits de ferramentas da interface do usuário foram lançados, então continuamos a integrá-los para ferramentas especiais. Portanto, quando o ciclo de desenvolvimento do Unreal Engine 4 começou, tínhamos cinco kits de ferramentas de interface do usuário diferentes ...

JL: Isso geralmente acontece ...

TS: ... incluindo peças malucas de WPF escritas em C # e integradas no Unreal Engine 4 que não funcionavam no Mac, por exemplo. Portanto, naquele momento em nosso código, havia um enorme caos.

Ao mesmo tempo, Nick Atamas criou um protótipo da nova camada de interface do usuário em C ++ e, com o tempo, decidimos usá-lo. Então ele se transformou em uma lousa. Então, reescrevemos 100% da interface do usuário do Unreal Engine, livramos todos os kits de ferramentas da interface do usuário do plug-in e refizemos o mesmo estilo. Isso nos permitiu aumentar a escala do editor e chegar ao que temos hoje.


Captura de tela do UnrealEd com Slate UI

Mas ainda não conseguimos alcançar a conveniência que existia nos dias do Visual Basic. Até a estrutura da interface de usuário do C # era apenas uma enorme pilha de XML e outras insanidades desnecessárias. Parece que toda nova geração implementa a interface do usuário de uma maneira cada vez mais sofisticada e está piorando.

Capturas de tela e XCopy: a importância do licenciamento

DL: Quais empresas foram as primeiras a usar o Unreal Editor?

TS: Nos estágios iniciais, dois anos antes do lançamento, já tínhamos dois compradores de licenças: a Unreal Engine usava o Microprose e a Legend Entertainment o usava para o Wheel of Time, e fornecemos suporte a eles.



Legend Entertainment Roda do Tempo

JL: Eles ajudaram você também, certo? A colaboração fazia parte desse relacionamento.

TS: Sim, o pagamento da licença manteve a Epic à tona durante o processo de desenvolvimento da Unreal.

Naquela época, levava o licenciamento muito a sério, porque nos permitia pagar contas, o que nos levou ao modelo de licenciamento do mecanismo, que era completamente diferente do modelo de identificação. Naquela época, havia uma piada de que licenciar o mecanismo da Id era como comprar o XCopy por um quarto de milhão de dólares: você paga um quarto de milhão e eles inserem o comando DOS XCopy para fornecer uma cópia da fonte ... e é isso. (risos)

JL: [risos] Tudo bem, então o que levou à venda da licença da Unreal Engine para a Microprose e a Legend Entertainment antes mesmo do lançamento do Unreal 1?

TS: Acho que aconteceu porque ainda nos estágios iniciais, por volta de 1995, lançamos incríveis imagens não apenas do nosso jogo, mas também do nosso editor. Isso fez a empresa entrar em contato conosco. Eles nos ligaram da Microprose e disseram: “Queremos licenciar o seu motor!”, E somos como: “Motor? Qual motor? Ah, nosso motor! Vai custar muito caro. [risos] Foi literalmente como foi a conversa.



Uma das primeiras capturas de tela do Unreal Editor e Unreal

Dinossauros e lagartos: terminologia e iconografia UnrealEd

DL: Falando em screenshots: aqui está um deles publicado no Blue's News no final dos anos 90. Existem pequenas diferenças visíveis em relação à versão que está sendo executada em minha máquina virtual: por exemplo, no canto superior esquerdo, há os botões Play, Help e Epic, que não estão na versão final.

Você pode contar um pouco sobre isso?


Captura de tela do UnrealEd publicada no Blues News em 1998

TS: Este é definitivamente o Unreal Engine 1, por volta de 1998, porque possui o código de Steve Polge, que na época coordenava o jogo multiplayer.

O botão "Épico" era apenas um link para uma página da web, o que parecia irritante para todos porque eles clicavam constantemente e ficavam irritados: "Ah, o navegador abre novamente!" (risos)

JL: [risos] Bem, você pode falar um pouco sobre iconografia?

TS: Para todos os elementos da interface do usuário, desenhei ícones absolutamente terríveis e os enviei para Dan Cook, um artista que estava envolvido em gráficos para o nosso atirador Tyrian .

Ele precisava desenhar um ícone para o elemento Peão, então criou uma peça de xadrez. Eu disse: "Não, não, não", e ele respondeu: "Bem, então me diga o que é peão". Eu disse que era algo como um monstro, algo muito legal, então ele chamou a cabeça de uma criatura incompreensível: eles disseram que era um dinossauro, um lagarto ou algo mais ... mas esses ícones permaneceram conosco por cerca de dez anos.



Daniel Cook e os ícones que ele criou para o UnrealEd. O ícone "Adicionar peão" fica na parte inferior, terceiro à direita.

DL: Já falamos sobre a palavra "peão". Nós criamos nós mesmos ou vimos em algum lugar?

TS: Eu acho que foi proposto por Steve Polge ou James Schmalz.

JL: E o "ator"?

TS: Carmack criou sua própria terminologia, ele chamou objetos de "entidades", e eu pensei: "Não, precisamos de algo único".

JL: [risos]

TS: Decidimos que teríamos objetos designados como atores, porque na década de 1980, o SmallTalk , que eu amava na época, propunha princípios de programação baseados no modelo de ator . O modelo era orientado a objetos e parecia um bom começo para nós. Portanto, surgiu a idéia de peões e instigadores, que determinam o início de uma série de eventos e todas as outras terminologias.

Schmalcism e Vírus Brain Voodoo: Criando UnrealScript

JL: Conte-nos mais sobre como James e Steve contribuíram para usar e criar o UnrealScript.

TS: James Schmalz era um diamante único, faz-tudo. Ele foi o melhor artista da equipe, um excelente designer de níveis e também pode programar em UnrealScript e assembler.

DL: Em créditos irreais, seu nome aparece em um par de categorias completamente diferentes.

TS: Em toda a indústria de jogos, existem poucas pessoas com esse nível de talento e ele merece todo o sucesso alcançado.

Mas ele mudou de montador para UnrealScript e escreveu um código louco do UnrealScript, no qual ele simplesmente martelava linhas enquanto eles continuavam a trabalhar, e à noite eu me aproximava dele e simplificava seu código. Ele tinha expressões de várias linhas como "algo instigador ponto blá blá dot", e eu as substituí por algo como ... "eu". [risos]

DL: [risos]

TS:Chamamos esse código de "schmalcismo". E Polge tinha números mágicos como "velocidade de caminhada = velocidade de execução x 3,072" em seu código. Perguntei-lhe: "Existe realmente uma constante 3.072 em física que eu não conheço?" (risos)



TS: O UnrealScript foi inspirado em Java; naquela época, essa linguagem parecia ser a sucessora do C ++. Os criadores da linguagem copiaram muitas soluções construtivas e, além disso, adicionaram muitos conceitos novos. No UnrealScript, existiam os rudimentos dos contêineres básicos que apenas algumas gerações depois apareceram em Java.

Eu sempre pensei que, ao desenvolver a linguagem C #, os autores seguiram o UnrealScript porque vi alguns recursos do UnrealScript que surgiram no C #. Eu sempre esperei que eles emprestassem algumas dessas idéias.

Mas quanto mais eu me envolvia em programação orientada a objetos e no SmallTalk, estudava as pesquisas mais avançadas sobre metaclasses, mais percebia que era um tipo de vírus vodu cerebral que não tinha base teórica real. Por sua vez, se olharmos para a correspondência de Haskell e Curry-Howard , além de outros princípios modernos de programação, veremos a fonte e a estrutura da inspiração.

SoftDisk, ID e milhões de dólares em cheques

JL: Jay Wilbur e Mark Rein, com sua orientação comercial e experiência com o shareware, influenciaram o mecanismo, as ferramentas, o editor ou os recursos com os quais foram fornecidos?

TS: Nos estágios iniciais, a Epic trabalhou devido ao fato de eu estar envolvido no lado técnico e no Mark - nos negócios. Mark voou pelo mundo, fez negócios malucos que nos trouxeram dinheiro. Era muito importante, se não fosse por ele, não teríamos sobrevivido nesses estágios iniciais.



Mark Rain e Jay Wilbur

Em algum momento estávamos encalhados e todas as nossas despesas foram financiadas com o cartão American Express de Mark, que foi cancelado como resultado.

JL: [risos]

TS: Então ele voou para uma reunião com a TG Interactive e voltou de lá com um cheque de um milhão de dólares. Isso nos salvou. E assim foi repetido várias vezes em nossa história. É muito importante ter excelentes empresários que possam negociar. Ele foi o primeiro presidente da Id e depois que Mark Jay se tornou o primeiro CEO da Id.

DL: Antes disso, ele e Carmack estavam no SoftDisk, certo?

TS:Certo! E isso é engraçado, porque na verdade eu vendi meu primeiro jogo ZZT para o SoftDisk. Foi Jay Wilbur quem lidou com o meu contrato com a SoftDisk. Como resultado dessas negociações, recebi três mil dólares da SoftDisk, por isso conheci Jay por um longo tempo.


Os primeiros dias da Id Software. Jay Wilbur à direita.

Trabalhar com os caras do Id me inspirou desde o começo. Eu fui a uma conferência estúpida de shareware e eu apareci lá. Eles eram os favoritos da indústria na época porque lançaram o Wolfenstein 3D, que foi o maior sucesso na história do shareware. Eles conversaram conosco e depois foram convidados para jantar. Foi tão bom ver que as superestrelas da indústria eram apenas caras modestas. John Romero é o desenvolvedor de jogos mais fofo do mundo.

[Nota do autor: eu concordo. John Romero passou muito tempo em nossa entrevista ao TEd.]

WYSIWYG e facilidade de uso: o mais importante - perspectivas da ferramenta

DL: Então, em novembro de 1998, a versão Maximum PC apareceu, na qual houve uma entrevista com você, onde você também falou sobre as diferentes tecnologias existentes naquele momento. Este artigo dizia que "[Editor Unreal] está à frente de todos em termos de simplicidade" e "é difícil trabalhar com a tecnologia Quake".

Ele também diz: “A tecnologia [Quake III: Arena] é realmente impressionante” e “Prey e Trespasser parecem e funcionam melhor que a Unreal. Porém, se for mais difícil trabalhar com eles, os desenvolvedores permanecerão na Unreal. "

Ou seja, você tinha um objetivo desde o início de criar uma ferramenta cuja vantagem competitiva fosse a facilidade de uso?



PC máximo, novembro de 1998

TS: Sim, está certo. Você sabe, isso sempre foi a coisa mais importante para mim: escrever um editor que permita que designers de níveis criem criações incríveis. Desde o início, ficou claro que o aspecto mais importante disso é o trabalho em tempo real e as iterações de design ultrarrápidas, a implementação completa do princípio de "o que você vê é o que obtém" ("o que você vê é o que você obtém", WYSIWYG) . Então você será limitado apenas por sua imaginação e capacidade de apresentar novas idéias. Para nós, a Epic sempre teve uma ferramenta muito importante.

JL: Que processo a Epic utilizou para fornecer muita atenção, investindo tempo e trabalho na simplificação do uso de ferramentas?

TS:O processo de desenvolvimento na Epic é uma combinação da equipe de desenvolvimento do mecanismo, criando sistemas, funções e ferramentas, e a equipe do jogo, consumindo tudo isso para criar jogos. Usamos um processo iterativo quando as equipes de desenvolvimento de mecanismos criam novas idéias e as compartilham com as equipes de jogo e obtêm feedback constante sobre o que funciona e o que não funciona. Foi assim que nosso processo técnico foi criado: o fato de que os desenvolvedores de ferramentas deveriam ajudar os desenvolvedores de jogos permitiu que eles fossem honestos.

Queríamos não apenas criar ferramentas fáceis de usar, mas também garantir que elas apresentassem os compromissos certos que realmente permitem que você crie o conteúdo necessário para o lançamento do jogo.

. . , , , , .


Se você observar os últimos cinco ou seis anos de desenvolvimento de motores, a concorrência entre a Epic e o Unity será determinada pela facilidade de uso inicial, na qual o Unity tem uma vantagem. Ao mesmo tempo, no ciclo de desenvolvimento do lançamento do jogo, em termos de desempenho em diferentes plataformas, a Unreal tem uma vantagem. Isso ocorre porque estamos focados em poder lançar jogos de escala épica, ou seja, os que fazemos. De fato, isso é muito mais complicado do que simplificar o trabalho de três pessoas, liberando rapidamente algo simples.

Hoje, o tamanho do código do Unreal Engine é cerca de 20 vezes maior que o código do Unreal Engine 1. As ferramentas se tornaram dez vezes mais complicadas, e existem razões para isso. As pessoas iniciam o Unreal e se perdem porque existem muitas opções de menu. Então eles mudam para o Unity e vêem que tudo é bonitinho e simples. E então eles atingem o estágio em que você precisa lançar um produto, e acontece que você precisa comprar uma licença para o código-fonte para adicionar recursos que não estão no menu ao mecanismo. Existe uma dicotomia.

Fonte de inspiração e herança: o impacto da UnrealEd

JL: O UnrealEd inspirou alguns desenvolvedores de jogos, inclusive eu, a não apenas começar a criar jogos, mas também a escrever suas próprias ferramentas. O que você acha do impacto do UnrealEd na indústria?

TS: Eu acho que todo editor de jogos existente emprestou algo da UnrealEd. Este foi um dos primeiros editores, tomamos muitas decisões fundamentais corretas, por exemplo, como o usuário deve trabalhar com grades 2D, colocando objetos e se movendo pelo mundo. Eu acho que você pode acompanhar a herança passada do primeiro editor Doom para o editor Quake e, em seguida, para a Unreal. Hoje, tudo é, até certo ponto, baseado nisso.


Diagrama do histórico dos mecanismos FPS da Wikipedia. Clique para abrir uma versão maior.

Alguns aspectos foram influenciados por princípios gerais, por exemplo, o Maya, mas alguns estão especificamente relacionados ao Unreal - uma maneira de estruturar hierarquias de classes, implementar um sistema de desfazer e todos os outros problemas sérios de desenvolvimento de jogos. Todo mundo que entrou no setor no início dos anos 2000 geralmente passava por Unreal ou Quake. Embora Quake fosse um jogo muito maior, parece-me que a maioria dos designers veio do UnrealEd porque suas ferramentas eram muito convenientes.

Multiplicação e divisão de produtividade: dicas para desenvolvedores de jogos

JL: Em 2011, você deu uma entrevista ao Kotaku. Vou ler algumas citações que, ao que me parece, se relacionam com o nosso tópico:

“Sempre abordamos o desenvolvimento de jogos em termos de ferramentas. Criamos as ferramentas necessárias, criamos um conjunto de ferramentas fácil de usar e continuamos a trabalhar com elas. ”

“Nós da Epic pensamos muito à frente. Nós somos como a Intel. Pensamos no que faremos em cinco a dez anos e escolhemos as direções apropriadas para o desenvolvimento, enquanto para a maioria das empresas o limite do planejamento é o lançamento do próximo jogo. Eles colocam todos os seus recursos nele e depois fazem o próximo jogo. ”

“Grandes empresas de jogos como EA ou Activision não investem em ferramentas, não possuem um planejamento de longo prazo como o nosso e nossa consciência de que precisamos tornar os processos de desenvolvimento de jogos o mais eficientes possível.”



Na minha entrevista com John Romero, ele entendeu muito bem, dizendo: "As ferramentas vivem mais que os jogos".

Que conselho você pode dar aos desenvolvedores de jogos para que eles possam evitar esse erro e entender o valor a longo prazo de investir em ferramentas?

TS: Bem ... você não precisa "parecer" criar um mecanismo. Crie o mecanismo ou não faça isso. Agora, muitas empresas prejudicam seus processos de produção, criando mecanismos com ferramentas inúteis. São as ferramentas que matam pessoas.

Veja todos esses mecanismos criados internamente pelas empresas ... Por exemplo, o Frostbite possui funções de renderização mais avançadas que as nossas e, em muitos casos, desenha pixels mais bonitos que os nossos, mas os desenvolvedores da Unreal podem criar conteúdo de maneira muito mais produtiva, aproximadamente 30 a 50 por cento mais produtivo. Ou seja, uma equipe pode criar um jogo da mesma qualidade pela metade do poder. Ele pode fazer mais iterações e aprimorar o jogo melhor do que com ferramentas de menos qualidade. Portanto, todos precisam tomar uma decisão informada - investir completamente na criação de excelentes ferramentas para uso interno ou usar mecanismos de terceiros.

DL: Porque você acha que os desenvolvedores estão sofrendo com meias medidas?

TS: Sim. Em algum lugar dessas empresas, existem contadores incrivelmente estúpidos, pensando assim: "Oh, limitando os gastos no desenvolvimento de ferramentas, podemos economizar dois por cento do orçamento". Como resultado, isso leva a um aumento de 50% no orçamento, porque é necessário investir muito mais tempo e mão-de-obra na criação do jogo. Portanto, cria uma economia de custos tão louca, que não justifica.

Penso que toda empresa deve tomar uma decisão - ou investe muito mais em ferramentas ou não as faz.


E isso se aplica a tudo. Não apenas para um editor 3D para criar níveis, mas também para sistemas de montagem, para uma linguagem de programação, tecnologia de desenvolvimento, ferramentas DCC, para tudo isso.

As ferramentas devem aumentar a produtividade e, se elas reduzirem, você precisará se livrar delas.

JL: Ótimo. Obrigado por reservar um tempo para conversar comigo.