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
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 (eduke32)

Build engine é um motor de jogo desenvolvido por Ken Silverman[1] em 1993, 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 12 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[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.

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.

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.

TROR[editar | editar código-fonte]

Recentemente foi criado um método chamado 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.

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". 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]

4 principais títulos (Também chamados de Big Four):

Jogos que foram criados diretamente usando o motor de jogo:

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[2] .

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:

"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 um 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."

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, 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. O seu alto consumo de memória diminui o desempenho da renderização. É necessário ter um computador muito potente para rodar todos os seus recursos sem perda no desempenho.

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's Build Engine Page". advsys.net. Consultado em 2016-02-12. 
  2. Ken Silverman (20/06/2000). "Ken Silverman's Build Engine Source Code Page". Ken Silverman. Consultado em Último acesso: 06/08/2014.