Build Engine
| Build Engine | |
|---|---|
| Desenvolvedor | Ken Silverman |
| Plataforma | Multi-plataforma |
| Lançamento | 1994 |
| Idioma(s) | Inglês |
| Escrito em | 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 do gênero tiro em primeira pessoa desenvolvido por Ken Silverman em 13 de abril de 1993[1]. Ganhou notoriedade quando a empresa Apogee (atualmente 3D Realms) lançou Duke Nukem 3D, o seu primeiro jogo utilizando a sua tecnologia.
No total foram desenvolvidos 13 jogos entre 1995 e 1999.
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. Por conta disso, a engine é comummente denominada uma "engine 2.5D".
O método de renderização utilizado é o Ray Casting, mesmo método utilizado em vários motores de jogo da época.
Setores[editar | editar código-fonte]
Os setores são as salas do cenário onde os jogadores e demais objetos do jogo existem e se movimentam.
Sector Effectors[editar | editar código-fonte]
São objetos pré-programados inseridos no editor de cenários, utilizados para criar todos os efeitos apresentados durante o jogo. Há uma lista de funções pré-definidas que podem ser utilizadas.
Room Over Room[editar | editar código-fonte]
O Room Over Room é uma técnica desenvolvida para renderizar salas sobrepostas.
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. 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.
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.
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 em tempo real.
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 a 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)
- Yume Nikki 3D
Jogos que nunca foram finalizados:
- Corridor 8: Galactic Wars
- Fate
Anos posteriores[editar | editar código-fonte]
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 com desempenho satisfatório alguns jogos da Build Engine.
A tarefa de atualizar o mecanismo de compilação para um render 3D moderno 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 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 render 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, os membros da comunidade pensaram ser uma piada de 1º de abril, porém logo foi disponibilizado para uso.
Estas são algumas 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 refletivas (Normal and specular mapping)
Apesar de seus avanços, o Polymer não possui desempenho satisfatório. O alto consumo de memória causa perda de desempenho na GPU.
Referências
- ↑ «Ken Silverman's Build Engine Page». advsys.net. Consultado em 12 de fevereiro de 2016
- ↑ «Ken Silverman's Voxlap Page». advsys.net. Consultado em 16 de fevereiro de 2016
- ↑ a b «Release Notes for JFDuke3D». static.jonof.id.au. Consultado em 16 de fevereiro de 2016