Build Engine

Origem: Wikipédia, a enciclopédia livre.
Ir para: navegação, pesquisa


Build Engine
Captura de tela
Topview da Build engine (Mapster32 rodando no Windows 8.1)
Desenvolvedor Ken Silverman
Plataforma Multi-plataforma
Lançamento 1994
Idioma(s) Inglês
Linguagem C
Sistema operacional DOS, Windows, Unix
Gênero(s) Motor de Jogo
Licença Livre para uso não-comercial
Estado do desenvolvimento Ativo

Build engine é um motor de jogo desenvolvido por Ken Silverman em 1993[1], especificamente para jogos de tiro em primeira pessoa.

Em 1996 a empresa 3D Realms à utilizou para o desenvolvimento de Duke Nukem 3D, trazendo assim grande sucesso e fama para seu nome.

No total foram desenvolvidos 13 títulos utilizando a sua tecnologia, ainda contendo outros 3 títulos que não foram oficializados.

Informações Técnicas[editar | editar código-fonte]

Perspectiva do ambiente no modo 3D (Duke Nukem 3D - E1M1)

Perspectiva[editar | editar código-fonte]

O ambiente do jogo é representado em uma perspectiva tridimensional, porém, a maioria dos objetos encontrados nele são bidimensionais, genericamente denominados sprites.

Com a introdução do polymost, tornou-se possível renderizar também objetos em 3D, utilizando o formato MD2 e MD3, ambos formatos desenvolvidos para a quake engine.

Exemplo de um setor. O espaço do interior é uma área que o jogador e outros atores podem se deslocar.

Setores[editar | editar código-fonte]

Os setores são as salas do cenário, que consistem em um contorno poligonal bidimensional quando visto de cima. Após desenhar um setor no wireframe 2D, são criadas 2 faces, uma superior e outra inferior.

Alterando a altura de cada face, é possível criar um espaço tridimensional, onde o jogador e os demais objetos do jogo podem se deslocar livremente. Estas faces se chamam Floor e Ceiling (Chão e Teto).

Sector Effectors[editar | editar código-fonte]

Para auxilar o funcionamento dos setores, são usados os sector effectors, que são sprites hard-coded que possuem atributos pré-definidos pelo autor do cenário. No modo de jogo, esses sprites são ativados por algum ativador(trigger), que podem variar entre um projétil de arma de fogo sendo detonado, ou por apenas o jogador passar por um lugar específico.

Um exemplo disso seria o próprio ato de o jogador atirar contra um tanque de gás, originando uma explosão que acabaria destruindo uma parede. Outro exemplo seria se o jogador pisasse em um tele-transportador. No mesmo momento ele seria levado para outro setor.

Com a mesma base do Sector effector 7 (transporter), foi desenvolvido a possibilidade do jogador mergulhar na água em determinadas situações.

Exemplo: O jogador está em um setor que possui a tag 1 - water, utilizando um SE(sector effector) com a tag 7 - transporter e hitag 1, em outro lugar do cenário existirá o setor submerso, usando a tag 2 - underwater e o mesmo SE descrito anteriormente. Isso faria com que ao se abaixar em cima da água o jogador seria transportado para esse setor submerso e vice-versa.

Exemplo Room Over Room
Exemplo de sala sobreposta. Na primeira imagem vamos a superfície da água e na segunda imagem vemos a parte submersa. Apesar do efeito de submersão, estas salas não estão fisicamente sobrepostas no mapa.

Room Over Room[editar | editar código-fonte]

O Room Over Room é uma técnica desenvolvida para criar salas sobrepostas.

De fato, desde o princípio do desenvolvimento da Build Engine já era possível haver salas sobrepostas, mas não completamente.

A versão da engine que foi utilizada para Duke Nukem 3D apenas suportava essa técnica se o jogador não pudesse ver os diferentes níveis ao mesmo tempo.

Exemplo: Não poderia haver um prédio com duas janelas uma em cima da outra para o jogador entrar, elas teriam que ser uma do lado da outra, uma em cima e outra embaixo.

Já a versão da engine que foi usada para Shadow Warrior e Blood utilizam uma forma um pouco diferente deste recurso. As salas teriam que ser desenhadas em lugares diferentes do mapa e depois uma enxergaria a outra.

Exemplo: Para poder construir uma casa onde o jogador poderia entrar e subir no telhado, seria necessário desenhar a parte inferior da casa e depois desenhar a parte superior em outro lugar do mapa.

Após isso, é utilizado um sector effector para fazer os setores se enxergarem, tanto quando o jogador estiver em cima do telhado como quando estiver na frente da casa.

Exemplo TROR
Exemplo de uma sala sobreposta utilizando a técnica TROR. Na segunda imagem observa-se que os setores estão de fato sobrepostos.

TROR[editar | editar código-fonte]

Recentemente foi criado uma técnica chamada TROR, acrônimo de True Room Over Room, onde as salas não precisariam mais ser desenhadas em outros lugares do mapa, mas sim exatamente uma sobre a outra, permitindo o mesmo efeito utilizado nas versões de Shadow Warrior e Blood.

SLAB6
Screenshot de uma cadeira em formato Voxel (.kvx)

Voxel Sprites[editar | editar código-fonte]

São objetos compostos por vários pixels em uma grade tridimensional. O nome vem da combinação de "Volume" e "Pixel"[2]. Desta forma é possível renderizar objetos tridimensionais formados por vários pixels

Quando este recurso estava pronta para uso, já era tarde demais para ser usado em Duke Nukem 3D. Por conta disso, apenas os jogos posteriores o utilizaram.

Jogos[editar | editar código-fonte]

Jogos que foram desenvolvidos diretamente utilizando o motor de jogo Build engine:

  • Legend of the Seven Paladins (1994) (Foi finalizado mas não chegou á ser comercializado)
  • Witchaven (1995)
  • William Shatner's TekWar (1995)
  • Duke Nukem 3D (1996)
  • Witchaven II: Blood Vengeance (1996)
  • PowerSlave (PC version) (1996)
  • Blood (1997)
  • Shadow Warrior (1997)

Jogos baseados no código fonte de Duke Nukem 3D:

  • Redneck Rampage (1997)
  • Redneck Rampage Rides Again (1998)
  • Redneck Deer Huntin' (1998)
  • NAM (1998)
  • Extreme Paintbrawl (1998)
  • World War II GI (1999)

Jogos que nunca foram finalizados:

  • Corridor 8: Galactic Wars
  • Fate

Anos posteriores[editar | editar código-fonte]

Renders da Build engine
Polymer (imagem 1) Polymost (imagem 2) Software Render (imagem 3)

Polymost[editar | editar código-fonte]

Com o passar do tempo, a renderização estava se tornando ruim com o avanço da tecnologia. Os computadores mais novos não conseguiam reproduzir alguns jogos desenvolvidos na Build engine.

A tarefa de atualizar o mecanismo de compilação para um render 3D decente foi assumida pelo próprio Silverman. Nas notas de lançamento para JFDuke3D, ele escreveu:

"Quando a 3D Realms liberou o código fonte de Duke Nukem 3D, eu pensei que alguém iria fazer uma porta para OpenGL ou Direct3D. Bom, depois de alguns meses, eu vi que ninguém estava trabalhando em uma verdadeira porta para a Build, apenas via pessoas dizendo que "não era possível". Eventualmente eu percebi que isso só iria acontecer se eu mesmo à fizesse."

Graças ao Polymost, permitiu-se uma aceleração 3D usando OpenGL de auto desempenho.

Ele também introduziu hightile, um recurso que tornou possível substituir as texturas originais do jogo por texturas de alta resolução em uma variedade de formatos[3], além da substituição de objetos 2D por modelos 3D utilizando os modelos MD2 e MD3 da quake engine[3].

O renderizador Polymost tem sido utilizado em JFBuild, JFDuke3D, JFShadowWarrior, Eduke32 e portas derivadas de suas bases de código.

Polymer[editar | editar código-fonte]

Em 1º de abril de 2009, foi anunciado na comunidade de Eduke32 um novo método de renderização com suporte à Shader Model 3.0 chamado Polymer.

Na primeira impressão, pensaram ser uma piada de 1º de abril, porém logo foi disponibilizado para uso.

Temos abaixo algumas das principais melhorias do Polymer:

  • Iluminação dinâmica em tempo real por pixel (Per-pixel dynamic lighting)
  • Mapeamento de luz e sombra em tempo real por pixel (Per-pixel dynamic shadows)
  • Mapeamento em Relevo/Superfícies reflectivas (Normal and Specular mapping)

Apesar de seus avanços, o Polymer ainda não está otimizado para um desempenho excelente. O alto consumo de memória causa perda de desempenho na GPU. Atualmente ele encontra-se em desenvolvimento e a esperança de seus idealizadores é de que ele substitua completamente o Polymost nos próximos anos.

Referências

  1. «Ken Silverman's Build Engine Page». advsys.net. Consultado em 2016-02-12. 
  2. «Ken Silverman's Voxlap Page». advsys.net. Consultado em 2016-02-16. 
  3. a b «Release Notes for JFDuke3D». static.jonof.id.au. Consultado em 2016-02-16.