| Bygg motor | |
|---|---|
| Sorts | Spelmotor |
| Utvecklaren | Ken Silverman |
| Skrivet i | Xi |
| Operativ system | DOS |
| Hårdvaruplattform | MS-DOS |
| Licens | kod från författaren - under den proprietära BUILDLIC.TXT [1] |
| Hemsida | advsys.net/ken/build.htm |
| Mediafiler på Wikimedia Commons | |
Build Engine är en first-person shooter -spelmotor skapad av Ken Silverman för 3D Realms . Precis som spelet Doom projicerar Build Engine spelvärlden på ett 2D-rutnät av slutna planformer som kallas sektorer och använder de enklaste platta objekten som kallas sprites för att fylla den geometriska världen med objekt.
Byggmotorn tillhör klassen av så kallade " 2,5-dimensionella motorer", eftersom spelvärlden är baserad på ett plan med en extra höjdkomponent. Varje sektor kan ha olika golv- och takhöjd, samt olika lutning på golv och tak. Som ett resultat av renderingen ser världen tredimensionell ut. Perspektivberäkning baseras endast på horisontellt avstånd - därför är de vertikala linjerna som motsvarar hörnen strikt vertikala, oavsett synvinkel. Detta orsakar betydande perspektivförvrängning när man tittar uppåt eller nedåt i höga vinklar i de flesta byggmotorspel .
Sektorer är huvudkomponenten i nivågeometrin. Du kan arbeta med sektorer i realtid. Deras parametrar (höjder, form, lutningsvinklar) kräver inte omräkning vid ändring. Detta gör att du kan göra miljön i spelet mer interaktiv, till exempel förstörbar (som i Blood ).
Utvecklarna använde reserverade sprites ( sektoreffektorer ), som tilldelades speciella topp- ( hi-taggar ) och botten ( lo-taggar ) taggar (nummer med en viss betydelse), vilket gjorde det möjligt att göra världen mer dynamisk (t.ex. dörrar, exploderande tunnor, etc.). Samma taggar kan ges till golvet och taket i sektorn för att ge speciella egenskaper. Till exempel skulle en spelare som går på ett golv med speciella taggar ramla ner och ramla ut ur ett annat tak med speciella taggar. I praktiken användes detta för att skapa reservoarer. En sektor kan få taggar som gör den till en dörr eller en hiss. Sektorer kan överlappa varandra så att den ena inte är synlig på grund av den andra (om i en sådan situation två sektorer är synliga samtidigt, då med kraftig förvrängning). Detta gjorde det möjligt att skapa, till exempel, ventilationsschakt placerade ovanför lokalerna (även om detta gjorde ytterligare arbete med denna del av nivån mycket svårare, eftersom utvecklaren tillbringar nästan hela tiden i tvådimensionellt läge). Det låter dig också skapa världar som är omöjliga ur fysiksynpunkt (till exempel ett system av rum i en byggnad som är större än själva byggnaden). Alla dessa effekter fick världen att se ut som tredimensionell, tills Quake -motorn dök upp .
För att sortera planen i Z-ordning använde Doom ett BSP-träd som byggdes varje gång WAD sparades. Till skillnad från Doom använde Build portalmekanismen .
Segmenten som separerar de två sektorerna deklareras som "portaler". Motorn ritar först den sektor där tittaren befinner sig och kommer ihåg alla portaler. Efter det börjar den rekursivt rendera de sektorer som är synliga genom portalerna (utan att röra det som redan är ritat).
I den 2,5-dimensionella motorn var denna metod bättre än BSP-trädet av följande skäl:
Senare versioner av motorn gjorde det möjligt att ersätta bilder i spelet med 3D-objekt gjorda av voxlar . Den här funktionen verkade för sent för att användas i Duke Nukem 3D , men användes i andra spel. Blood använder voxlar för vapen, ammunition, uppgraderingar och olika dekorationer (som gravstenar i Cradle to Grave).
I flera år har Ken arbetat med Voxlap- motorn baserad på voxelteknologi.
Vissa spel på Build-motorn använde tricket att kombinera golv och tak i två sektorer. Att skapa sådana strukturer under nivåredigering var svårt, så ofta flyttades sektorerna under laddning av nivån (vilket förenklade beräkningarna som utfördes av renderingsmotorn). Rum-över-rummet-tekniken användes i Shadow Warrior (skiftande sektorer under kartladdning) och Blood (ingen offset). Tekniken i sig var inte inbyggd i motorn, tänkte nivåskaparna på det.
Den 20 juni 2000 skapade Ken Silverman Build Engine med öppen källkod .
Version 2.0 (den första och enda officiella utgåvan) av Matt Setlers EDuke (en port för att köra Duke Nukem 3D på moderna operativsystem ) skickades till 3D Realms ( Duke Nukem 3D- och EDuke-källor var fortfarande offentliga). Matt arbetade med 2.1-betan och försökte bädda in Build-källorna i Duke-källorna, men projektet stängdes av innan felsökta offentliga utgåvor var tillgängliga. Flera Build-konverteringsteam bestämde sig för att arbeta direkt med Kens Build Engine-källor snarare än Dukes källor. Senare, som ett resultat av arbetet, dök mapster-redaktören upp. Länge var det svårt att porta Build-motorn till multitasking-operativsystem på grund av behovet av mycket stora områden med datorminne, som inte var tillgängliga i multitasking-operativsystem. Problemet löstes genom att ansluta virtuellt minne .
Den 1 april 2003 släppte 3D Realms källkoden för Duke Nukem 3D -motorn , trots långa påståenden om att detta aldrig skulle hända. Efter det dök portarna av Icculus och JonoF upp mycket snart . Det blev möjligt att spela Duke Nukem 3D sömlöst på GNU / Linux , Windows NT och andra plattformar, och intresset för portar ökade.
Ryan Gorden (icculus) skapade den första porten av motorn med hjälp av SDL med hjälp utifrån . Ursprungligen var det en port för Linux , senare för Cygwin och ännu senare för ren Win32 (när man byggde användes Watcom C++-kompilatorn , som också användes för det ursprungliga DOS- bygget (med den precision som Watcom C ++ användes) för Windows , och Build skrevs i vanlig C ) Det gick rykten om portering av EDuke till Windows, men ingenting hände.
Andra porten på Windows och senare på Linux av Jonathan Fowler (JonoF). Till skillnad från icculus-porten använder denna port DirectDraw istället för SDL på Windows och är betydligt snabbare. Under en lång tid stödde inte motorn multiplayer , sedan fanns det stöd för multiplayer endast för två spelare.
Författaren till motorn tog på sig uppgiften att uppdatera Build Engine till en fullfjädrad 3D-motor. I JFDuke3D release notes skriver Silverman:
När 3D Realms släppte källkoderna för Duke Nukem 3D trodde jag att någon skulle göra en OpenGL – eller Direct3D – port. Efter några månader insåg jag att ingen arbetar med att använda riktig hårdvaruacceleration i Build, folk säger bara att det inte är möjligt. Senare insåg jag att det enda sättet att uppnå något är att göra allt själv.
Polybridge- renderingssystemet använder OpenGL för hårdvaru-3D-acceleration. Hightile- teknologi har också introducerats , vilket gör det möjligt att ersätta standardspelresurser med bättre i olika format.
Polybridge har använts i JFBuild av Jonathan Flower, JFDuke3D, JFSW och andra portar baserade på denna kodbas.
Publiceringen av EDuke 2.0-källkoden lade till funktionerna hos JonoF-porten och Build Engine 2.1-motorn till EDuke, EDuke32 dök snart upp, men hittills är endast EDuke under utveckling.
Källkoden för den senaste personliga betaversionen av EDuke 2.1 (som aldrig kom ut) publicerades också efter källkoderna för EDuke 2.0. Det finns också en hamn baserad på Icculus, kodnamnet windeduke, som för närvarande inte är under utveckling.
EDuke innehöll delar av Nam och WW2 GI källkoder , vilket kan ha gjort utvecklingen lättare. Det gjordes också ett försök att återskapa Blood på DarkPlaces- motorn och kalla den Transfusion , men från och med 2006 är denna port fortfarande i tidig utveckling.
Källkoderna för Shadow Warrior släpptes den 1 april 2005 och JonoF publicerade en port av spelet den 2 april 2005. Det är sant att han påstår att han hade tillgång till källkoderna för Shadow Warrior en vecka innan de publicerades.
Källkoderna för Witchaven , Witchaven II , Tekwar och Corridor 8 har också släppts. Sanningen är tveksam är lagligheten av deras publicering.
| Build Engine- spel | |
|---|---|
| |