Build Engine

Origem: Wikipédia, a enciclopédia livre.
Ir para: navegação, pesquisa
Question book.svg
Este artigo ou secção necessita de referências de fontes secundárias fiáveis publicadas por terceiros (desde agosto de 2014).
Por favor, melhore-o, incluindo referências mais apropriadas vindas de fontes fiáveis e independentes.
Fontes primárias, ou que possuem conflito de interesse geralmente não são suficientes para se escrever um artigo em uma enciclopédia.
Encontre fontes: Google (notícias, livros e acadêmico)
Build Engine
Desenvolvedor Ken Silverman
Plataforma Multi-plataforma
Lançamento 1996
Idioma(s) Inglês
Linguagem C
Sistema operacional DOS, Windows
Gênero(s) Motor de Jogo
Licença Livre para uso não-comercial
Estado do desenvolvimento Inativo

Build Engine é um motor de jogo estilo first-person shooter desenvolvido por Ken Silverman para a 3D Realms em 1996.

Ela representa o ambiente do jogo em uma perspectiva tridimensional(3D), porém, a maioria dos objetos encontrados nele são bidimensionais(2D), que são genericamente denominados sprites.

Existe um artigo em uma wiki da source-port Eduke32 que se aprofunda mais na área técnica do motor de jogo Build.

Você pode acessá-lo clicando aqui.

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

Setores[editar | editar código-fonte]

Os setores são as salas desenhadas no wire-frame 2D(visto de cima) do mapa/cenário em construção. Em cada setor é possível ter vários outros setores, um dentro do outro. Os setores possuem chão, teto e paredes.

O chão e teto podem ter a forma, altura e inclinação modificadas, tanto no modo de edição de cenário como em tempo real. Esse detalhe foi um dos mais revolucionários da época, pois o ambiente do jogo se tornava dinâmico, podendo o jogador destruir várias estruturas do cenário usando armas de fogo e explosivos. Até então, uma técnica jamais vista em jogos do gênero.

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 disparador/ativador(trigger), que podem variar entre um projétil de arma de fogo explodindo algo, ou por apenas o jogador "pisar" em 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.

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

Outra inovação disponibilizada pela engine seria o Room over Room, onde no cenário era fisicamente possível ter salas sobrepostas. Caso você entrasse em um prédio, poderia andar por vários andares, um sobre o outro. Essa técnica só funciona se você não poder ver os níveis ao mesmo tempo.

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

Voxel Sprite é um objeto composto por vários pixels em uma grade tridimensional. O nome é uma combinação de "Volume" e "Pixel"

Versões mais recentes da engine permitiram que no jogo fosse inseridos objetos 3D feitos à partir de voxels. Quando essa característica estava pronta para uso, já era tarde demais para ser usada em Duke Nukem 3D. Por este motivo ela foi apenas usada nos jogos seguintes.

Shadow Warrior se destacou no uso de voxels, pois usou desse método até mesmo para simples botões e interruptores no cenário do jogo, enquanto Blood apenas usava para itens e armas.

Jogos[editar | editar código-fonte]

Como a engine alcançou um sucesso muito grande com Duke Nukem 3D, outros vários títulos foram lançados ao longo do tempo.

4 principais títulos:

Jogos que foram criados diretamente usando a engine:

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

Não concluídos/liberados:

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

Liberação do Código Fonte[editar | editar código-fonte]

De acordo com o web-site de Ken Silverman, o código fonte da engine foi liberado em 20 de junho de 2000[1] .

Polymost[editar | editar código-fonte]

Com o passar do tempo, a renderização da engine estava se tornando ruim com o avanço da tecnologia, onde os PCs mais atualizados encontravam alguns problemas para renderizar os jogos desenvolvidos nela.

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

"When 3D Realms released the Duke Nukem 3D source code, I thought somebody would do a OpenGL or Direct3D port. Well, after a few months passed, I saw no sign of somebody working on a true hardware-accelerated port of Build, just people saying it wasn't possible. Eventually, I realized the only way this was going to happen was for me to do it myself."

O renderizador então apelidado de Polymost permitiu uma aceleração 3D usando OpenGL.

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, além da substituição de objetos 2D por modelos 3D.

O renderizador Polymost tem sido utilizado em Jonathon Fowler 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, um renderizador Shader Model 3.0 OpenGL foi anunciado ter sido desenvolvido para EDuke32, chamado de Polymer, para distinguir de Polymost, que havia sido desenvolvido por Ken Silverman.

De primeira, pensaram ser uma piada de 1º de abril (April Fools), mas o renderizador mais tarde foi publicado. Ele permite que os efeitos mais modernos, como iluminação dinâmica em tempo real por pixel e mapeamento de luz e sombra, mapeamento especular e mapeamento normal, e outros recursos baseados em sombreamento por pixel, além de a maioria dos recursos adicionados ao Polymost ao longo dos anos.

Embora Polymer ser completamente utilizável, é tecnicamente incompleto e não-otimizado, e ainda está em desenvolvimento.

Os desenvolvedores de EDuke32 afirmaram que o Polymer foi reescrito para a velocidade, ele irá substituir o Polymost completamente, já que é um renderizador superior, e foi feito para ser idêntico ao Polymost.


Referências

  1. Ken Silverman (20/06/2000). Ken Silverman's Build Engine Source Code Page Ken Silverman. Visitado em Último acesso: 06/08/2014.