| Byg motor | |
|---|---|
| Type | Spil motor |
| Udvikler | Ken Silverman |
| Skrevet i | Xi |
| Operativ system | DOS |
| Hardware platform | MS-DOS |
| Licens | kode fra forfatteren - under den proprietære BUILDLIC.TXT [1] |
| Internet side | advsys.net/ken/build.htm |
| Mediefiler på Wikimedia Commons | |
Build Engine er en first-person shooter -spilmotor skabt af Ken Silverman til 3D Realms . Ligesom spillet Doom projicerer Build Engine spilverdenen på et 2D-gitter af lukkede planformer kaldet sektorer og bruger de enkleste flade objekter kaldet sprites til at befolke den geometriske verden med objekter.
Build Engine tilhører klassen af såkaldte " 2.5-dimensionelle motorer", fordi spilverdenen er baseret på et fly med en ekstra højdekomponent. Hver sektor kan have en forskellig gulv- og lofthøjde, samt en forskellig hældning af gulv og loft. Som et resultat af gengivelse ser verden tredimensionel ud. Perspektivberegning er kun baseret på vandret afstand - derfor er de lodrette linjer, der svarer til hjørnerne, strengt taget lodrette, uanset synsvinklen. Dette forårsager betydelig perspektivforvrængning, når man kigger op eller ned i høje vinkler i de fleste Build engine-spil .
Sektorer er hovedkomponenten i niveaugeometrien. Du kan arbejde med sektorer i realtid. Deres parametre (højder, form, hældningsvinkler) kræver ikke genberegning ved ændring. Dette giver dig mulighed for at gøre miljøet i spillet mere interaktivt, såsom destruerbart (som i Blood ).
Udviklerne brugte reserverede sprites ( sector effectors ), som blev tildelt specielle top ( hi-tags ) og bund ( lo-tags ) tags (tal med en bestemt betydning), som gjorde det muligt at gøre verden mere dynamisk (f.eks. døre, eksploderende tønder osv.). De samme tags kan gives til gulv og loft i sektoren for at give specielle egenskaber. For eksempel vil en spiller, der går på et gulv med specielle mærker, falde ned og falde ud af et andet loft med særlige mærker. I praksis blev dette brugt til at skabe reservoirer. En sektor kan få tags, der gør den til en dør eller en elevator. Sektorer kan overlappe hinanden, så den ene ikke er synlig på grund af den anden (hvis i en sådan situation er to sektorer synlige på én gang, så med alvorlig forvrængning). Dette gjorde det muligt at skabe for eksempel ventilationsskakter placeret over lokalerne (selvom dette gjorde yderligere arbejde med denne del af niveauet meget vanskeligere, da udvikleren tilbringer næsten hele tiden i todimensionel tilstand). Det giver dig også mulighed for at skabe verdener, der er umulige ud fra et fysisk synspunkt (for eksempel et system af rum i en bygning, der er større end selve bygningen). Alle disse effekter fik verden til at se ud som tredimensionel, indtil Quake -motoren dukkede op .
For at sortere flyene i Z-rækkefølge brugte Doom et BSP-træ , der blev bygget hver gang WAD'en blev gemt. I modsætning til Doom brugte Build portalmekanismen .
Segmenterne, der adskiller de to sektorer, erklæres "portaler". Motoren tegner først den sektor, hvor seeren er placeret, og husker alle portalerne. Derefter begynder den rekursivt at gengive de sektorer, der er synlige gennem portalerne (uden at røre ved det, der allerede er tegnet).
I den 2,5-dimensionelle motor var denne metode bedre end BSP-træet af følgende årsager:
Senere versioner af motoren gjorde det muligt at erstatte billeder i spillet med 3D-objekter lavet af voxels . Denne funktion syntes for sent til at blive brugt i Duke Nukem 3D , men blev brugt i andre spil. Blood bruger voxels til våben, ammunition, opgraderinger og forskellige dekorationer (såsom gravsten i Cradle to Grave).
Ken har i flere år arbejdet på Voxlap -motoren baseret på voxel-teknologi.
Nogle spil på Build-motoren brugte tricket med at kombinere gulv og loft i to sektorer. At skabe sådanne strukturer under niveauredigering var vanskeligt, så ofte blev sektorerne flyttet under indlæsning af niveauet (hvilket forenklede beregningerne udført af renderingsmotoren). Rum-over-rum-teknologien blev brugt i Shadow Warrior (skifte sektorer under indlæsning af kort) og Blood (ingen offset). Selve teknologien var ikke indbygget i motoren, tænkte niveauskaberne på det.
Den 20. juni 2000 åbnede Ken Silverman Build Engine.
Version 2.0 (den første og eneste officielle udgivelse) af Matt Setlers EDuke (en port til at køre Duke Nukem 3D på moderne operativsystemer ) blev sendt til 3D Realms ( Duke Nukem 3D og EDuke kilder var stadig i det offentlige domæne). I arbejdet med 2.1-betaen forsøgte Matt at indlejre Build-kilderne i Duke-kilderne, men projektet blev lukket ned, før debuggede offentlige udgivelser var tilgængelige. Flere Build-konverteringsteams besluttede at arbejde direkte med Ken's Build Engine-kilder i stedet for Dukes kilder. Senere, som et resultat af arbejdet, dukkede mapster-redaktøren op. I lang tid var det vanskeligt at overføre Build-motoren til multitasking-operativsystemer på grund af behovet for meget store områder med computerhukommelse, som ikke var tilgængelige i multitasking-operativsystemer. Problemet blev løst ved at tilslutte virtuel hukommelse .
Den 1. april 2003 udgav 3D Realms kildekoden til Duke Nukem 3D -motoren , på trods af lange påstande om, at dette aldrig ville ske. Derefter dukkede havnene i Icculus og JonoF op meget snart . Det blev muligt at spille Duke Nukem 3D problemfrit på GNU / Linux , Windows NT og andre platforme, og interessen for porte steg.
Ryan Gorden (icculus) skabte den første port af motoren ved hjælp af SDL med hjælp udefra . Oprindeligt var det en port til Linux , senere til Cygwin og endnu senere til ren Win32 (ved bygningen blev Watcom C++ compileren brugt, som også blev brugt til den originale DOS build (med den nøjagtighed, at Watcom C++ blev brugt) for Windows , og Build blev skrevet i almindeligt C ) Der var rygter om portering af EDuke til Windows, men der skete ikke noget.
Anden port på Windows og senere på Linux af Jonathan Fowler (JonoF). I modsætning til icculus-porten bruger denne port DirectDraw i stedet for SDL på Windows og er betydeligt hurtigere. I lang tid understøttede motoren ikke multiplayer , så var der kun understøttelse af multiplayer for to spillere.
Forfatteren af motoren påtog sig opgaven med at opdatere Build Engine til en fuldgyldig 3D-motor. I JFDuke3D-udgivelsesbemærkningerne skriver Silverman:
Da 3D Realms frigav kildekoderne til Duke Nukem 3D, troede jeg, at nogen ville lave en OpenGL - eller Direct3D - port. Efter et par måneder indså jeg, at ingen arbejder på at bruge ægte hardwareacceleration i Build, folk siger bare, at det ikke er muligt. Senere indså jeg, at den eneste måde at opnå noget på er at gøre alting selv.
Polybridge- gengivelsessystemet bruger OpenGL til hardware 3D-acceleration. Hightile- teknologi er også blevet introduceret , som gør det muligt at erstatte standardspilressourcer med bedre i forskellige formater.
Polybridge er blevet brugt i JFBuild af Jonathan Flower, JFDuke3D, JFSW og andre porte baseret på denne kodebase.
Udgivelsen af EDuke 2.0-kildekoden tilføjede JonoF-portens og Build Engine 2.1-motorens muligheder til EDuke, EDuke32 dukkede snart op, men til dato er det kun EDuke, der er under udvikling.
Kildekoden til den seneste personlige betaversion af EDuke 2.1 (som aldrig nåede at blive udgivet) blev også offentliggjort efter kildekoderne til EDuke 2.0. Der er også en havn baseret på Icculus, kodenavnet windeduke, som i øjeblikket ikke er under udvikling.
EDuke indeholdt elementer af Nam- og WW2 GI -kildekoderne , hvilket kan have gjort udviklingen lettere. Der var også et forsøg på at genskabe Blood på DarkPlaces -motoren og kalde den Transfusion , men fra 2006 er denne port stadig i tidlig udvikling.
Kildekoderne til Shadow Warrior blev udgivet den 1. april 2005, og JonoF udgav en port af spillet den 2. april 2005. Sandt nok hævder han, at han havde adgang til kildekoderne til Shadow Warrior en uge før de blev offentliggjort.
Kildekoderne til Witchaven , Witchaven II , Tekwar og Corridor 8 er også blevet frigivet. Sandheden er tvivlsom er lovligheden af deres offentliggørelse.
| Build Engine spil | |
|---|---|
| |