Építés (játékmotor) - Build (game engine)
 | |
 Képernyőkép, amely bemutatja az Építés 2D módban lehetőséget
| |
| Fejlesztő (k) | Ken Silverman |
|---|---|
| Első kiadás | 1995. szeptember 30 . |
| Adattár | advsys |
| Utód | Építés 2 |
| Engedély | Szabadalmazott |
| Weboldal | advsys |
A Build egy első személyű lövöldözős motor , amelyet Ken Silverman , a Ken labirintusa szerzője készített a 3D Realms számára . A Doom motorhoz hasonlóan a Build motor is kétdimenziós rácson ábrázolja világát, zárt 2D alakzatokat használva, amelyeket szektoroknak neveznek, és egyszerű lapos tárgyakat használ, amelyeket spriteknek nevez, hogy a világgeometriát tárgyakkal töltse fel.
A Build motort általában 2,5D motornak tekintik, mivel az alapvető világgeometria kétdimenziós, hozzáadott magasságkomponenssel, amely lehetővé teszi minden szektor eltérő mennyezetmagasságát és padlómagasságát. A játék azt mutatja, hogy egyes emeletek alacsonyabbak, mások magasabbak lehetnek; ugyanaz a mennyezetekkel (egymáshoz képest). A padlók és a mennyezetek a szektor egyik fala mentén csuklósak lehetnek, ami lejtést eredményez. Ezekkel az információkkal a Build motor háromdimenziós megjelenítéssel jeleníti meg a világot , ellentétben a modern játékmotorokkal, amelyek tényleges 3D környezetet hoznak létre.
Bár a Build motor nagy hírnevet szerzett az 1996 - os első személyű lövöldözős Duke Nukem 3D bekapcsolásával , sok más játékhoz is használták. A "Big Three" Build motorjátékok általában a Duke Nukem 3D , az Shadow Warrior és a Blood .
Műszaki jellemzők
Ágazatok
A szektorok egy szint elrendezésének építőkövei, amelyek felülről nézve kétdimenziós sokszögű körvonalból állnak, és a szektor felső és alsó felülete külön magasságokat kap, hogy háromdimenziós teret hozzon létre. Ezért minden fal tökéletesen függőleges - minden, ami egyébként megjelenik, technikailag lejtős padló vagy mennyezet. A szoba szó lazán helyettesíthető a megértés elősegítésére, bár a játékvilág egy szobája sok szektorból állhat, és a parallaxis égbolt a szabadban való tartózkodás illúzióját keltheti. A szektorok valós időben manipulálhatók; minden tulajdonságukat, például az alakot, a magasságot és a lejtőt, játékok "menet közben" módosíthatják, ellentétben a korábbi Doom motorral . Ez lehetővé tette, hogy a játékok elpusztíthatóak legyenek, például a Blood -ban . Ez a technika hasonló a tolófalak használatához a korábbi Apogee Software Rise of the Triad címében , amely hasonló dinamikus környezeteket tartalmazott.
A motoron alapuló játékok fejlesztői speciális fenntartott "sprite -eket" (játékobjektumokat) használtak, amelyeket gyakran "szektor effektoroknak" [ sic ] neveznek , amelyek speciális címkék (meghatározott jelentésű számok) megadásával lehetővé teszik a szinttervező számára, hogy dinamikus világ; hasonló címkeinformációk adhatók a szektor falaihoz és alapterületéhez, hogy egy szektor különleges jellemzőit adják. Például egy adott szektor effektor elengedheti a játékosokat a padlón, ha átmennek rajta, és teleportálja őket egy másik szektorba; a gyakorlatban ezzel fel lehet használni azt a hatást, hogy leesik egy lyukból egy nagyobb helyiségbe, vagy víztestet hoz létre, amelybe be lehet ugrani a víz alatti felfedezéshez. Egy szektor kaphat egy címkét, amely miatt úgy viselkedett, mint egy lift vagy lift.
A szektorok átfedhetik egymást, feltéve, hogy nem láthatók egyszerre (ha két egymást átfedő szektort látnak egyszerre, a tükrök csarnoka hatása keletkezik). Ez lehetővé tette a tervezők számára, hogy például olyan légcsatornákat hozzanak létre, amelyek úgy tűntek, hogy átnyúlnak egy másik szoba tetején (ez azonban bonyolult lehet a tervezők számára a szerkesztési folyamat nagy részében használt 2D nézőpont miatt). Ez lehetővé tette a tervezők számára, hogy olyan világokat hozzanak létre, amelyek fizikailag lehetetlenek (pl. Egy kis épület ajtaja egy épületnél nagyobb helyiségek hálózatába vezethet). Noha mindezek miatt a motor használatával végzett játékok 3D-snek tűntek, csak a későbbi első személyű lövöldözők, mint például a Quake , amely a Quake- motort használta , a motor valóban a 3D-s információként tárolta a világ geometriáját. az egyik terület létrehozása egy másik terület tetején egyetlen térképen nagyon megvalósítható.
Voxel
Ken Silverman Build motorjának későbbi verziói lehetővé tették, hogy a játékban kiválasztott művészeti lapokat voxelből készült 3D objektumokkal helyettesítsék . Ez a funkció túl későn jelent meg ahhoz, hogy a Duke Nukem 3D -ben használni lehessen , de néhány későbbi Build motorjátékban is látható volt. A Blood voxelt használ fegyver- és lőszerfelvételre, erősítésre és édességre (például a "Bölcsőtől a sírig" szint síremlékei, néhány szék és egy kristálygömb a "Sötét karneválban"). A Shadow Warrior még fejlettebben használja ki a technológiát, a falra helyezhető voxelekkel (a játék összes kapcsolója és gombja voxel).
Ken több évig dolgozott egy modern, teljes egészében voxel alapú motoron, az úgynevezett Voxlap -on .
Szoba szoba fölött
A Build motor egyik korlátozása, hogy szintgeometriája csak egy kapcsolatot képes ábrázolni a szektorok között egy adott falnál. Emiatt egy olyan egyszerű szerkezet, mint egy polc, amelyen felül és alatt is van hely, lehetetlen, bár néha spritek vagy voxelek helyettesíthetők. A többszintes épületek technikailag lehetségesek, de nem lehetséges, hogy egy ilyen épület közvetlenül egy másik ablak felett vagy alatt külső ablakot tartalmazzon. Ezenkívül bizonyos szabadságjogokat kell biztosítani a lépcsőházakkal, liftekkel és más hozzáférési módokkal minden emeleten.
Több Build motorjáték (nevezetesen a Shadow Warrior , a Blood és a Redneck Rampage ) megkerülte ezt úgy, hogy egy további renderelési passzuson keresztül megjelenített egy "nézetablakot" egy másik szektorhoz. Ez a technika, amelyet úgy hívnak: szoba-szoba-szoba (ROR), zökkenőmentesnek tűnik a játékos számára. A függőleges felépítés széles skálája mellett a ROR -t gyakran használták víztömegek áttetsző felületeinek megadására . A ROR soha nem volt a Build motor jellemzője, hanem egy "trükk", amelyet a játékfejlesztők hoztak létre. A Duke Nukem 3D -ben használt trükk ennek kiküszöbölésére , mint az átlátszatlan víz alatti szakaszainál, az volt, hogy egyszerűen le kell szállítani a játékost a térkép egy másik régiójába, amely azt utánozza, hasonlóan a Rise of the Triad liftjeihez .
2011-ben az EDuke32 szolgáltatásba bekerült egy True Room over Room (TROR) nevű szolgáltatás, amely lehetővé teszi több szektor függőleges egymásra rakását, így minden szektor fala saját kapcsolattal rendelkezik, lehetővé téve a függőlegesen korlátlan szerkezeteket. A különbség a ROR és a TROR között az, hogy a TROR szektorok fizikailag átfedik egymást a térképadatokban és a szerkesztőben (lehetővé téve az egyszerű létrehozást és vizualizációt), ahelyett, hogy külön helyekről rajzolnák őket a nézetportálok segítségével, tehát valódi szoba a szobában. A TROR az EDuke32 forrásport egyik jellemzője, nem játékfunkció vagy trükk.
Építs motoros játékokat
- Játékok, amelyek közvetlenül a Build motorra épülnek
- Rock'n'Shaolin: Legend of the Seven Paladins 3D (1994) (csak helyben adták ki, illegálisan használták a Build motor korai verzióját)
- Witchaven (1995)
- William Shatner TekWar (1995)
- Duke Nukem 3D (1996)
- Witchaven II: Blood Vengeance (1996)
- PowerSlave (PC verzió) (1996)
- Vér (1997)
- Árnyharcos (1997)
- A Duke Nukem 3D kódon alapuló játékok
- Redneck Rampage (1997)
- Redneck Rampage Rides Again (1998)
- Redneck Deer Huntin ' (1998)
- NAM (1998)
- Extrém Paintbrawl (1998)
- Liquidator (1998) (csak helyben megjelent, illegálisan használt Build motor és az Akella kiadója )
- Világháborús GI (1999)
- Ion Fury (2019) (az EDuke32 segítségével )
- Kiadatlan Build motor játékok
- 8. folyosó: Galaktikus háborúk (befejezetlen, forráskód elérhető)
- Sors (befejezetlen, csak demó létezik)
Fejlődés
A Build motor lényegében egyszemélyes projekt volt Ken Silverman számára, bár a projekt elején John Carmacktól kért útmutatást.
Forrásközlés és további fejlemények
2000. június 20 -án (honlapja szerint) Ken Silverman szabadalmaztatta a Build motor forráskódját .
Kezdetekben
Version 2.0 Matt SAETTLER a EDuke , a projekt, hogy javítsa a Duke Nukem 3D for modders , küldték a 3D Realms csomagolására röviddel megjelenése után a Build forrás, így Duke Nukem 3D az előre beépített könyvtárak, hogy a 3D Realms használta az eredeti Herceg. (Mind a Duke Nukem 3D, mind az EDuke még zárt forrásúak voltak.)
A 2,1 privát bétával Saettler azon dolgozott, hogy Silverman építési forrását integrálja a Duke forráskódjába, de a projekt elbukott, mielőtt valami több buggy privát bétát produkált volna. A Build játékokhoz tartozó néhány konverziós csapat úgy döntött, hogy közvetlenül a Silverman Build -kódjából dolgozik, és kifejlesztették a Build szerkesztő Mapster néven ismert továbbfejlesztett verzióját.
Abban az időben sokan azt állították a 3D Realms fórumokon, hogy lehetetlen lenne a Build -et többfeladatos operációs rendszerre portolni, mivel ehhez nagy, összefüggő memóriablokkra van szükség, amely nem lenne elérhető többfeladatos környezetben. Ez a kijelentés nem bírta az alapos vizsgálatot, mivel minden modern operációs rendszer virtuális memóriát használ, amely lehetővé teszi az alkalmazások számára, hogy összefüggő logikai memóriát kapjanak anélkül, hogy összefüggő fizikai memóriát használnának, de a korabeli hagyományos bölcsesség szerint a Build ilyen operációs rendszerre való átvitele lehetetlen.
A Duke Nukem 3D forráskiadása
2003. április 1-jén, többéves ellenkező állítás után, a 3D Realms kiadta a forráskódot a Duke Nukem 3D számára a GPL-2.0 vagy újabb licenc alapján. Nem sokkal később Ryan C. Gordon és Jonathon Fowler létrehozta és kiadta a játék forrásportjait, beleértve a Build motort is. A Duke Nukem 3D -t jól lehetett játszani a Windows NT vonalán (beleértve a Windows 2000/XP -t ), valamint Linuxon és más Unix operációs rendszereken, és megugrott az érdeklődés a forrásportok iránt.
icculus.org port
Ryan C. Gordon (icculus) mások segítségével SDL segítségével elkészítette a motor első portját . A port először a Linux , majd a Cygwin , és végül egy natív Windows -konstrukció volt, amely a Watcom C ++ fordítót használta, amely az eredeti DOS -buildhez használt fordító volt (annak ellenére, hogy a Watcom C ++ programmal fordították, a Build sima C.) néhányan arról beszélnek, hogy Matt Saettler ezt használja az EDuke -nak a Windows -hoz való átviteléhez , de semmi sem lett belőle.
JonoF port
A második forrásportot Jonathon Fowler (JonoF) készítette a Windows, majd később a Linux és a Mac OS X számára. Ez a port, a JFDuke3D, kezdetben nem támogatta a hálózati játékokat, bár ezt később fejlesztették ki.
Polymost
A Build motor valódi 3D -s megjelenítőre való frissítésének feladatát Silverman maga vállalta. A Polymost kiadási megjegyzéseiben ezt írta: "Amikor a 3D Realms kiadta a Duke Nukem 3D forráskódot, azt hittem, valaki OpenGL vagy Direct3D portot fog csinálni. Néhány hónap elteltével semmi jelét nem láttam annak, hogy valaki a Build valódi hardveresen gyorsított portja, csak az emberek azt mondták, hogy ez nem lehetséges. Végül rájöttem, hogy ez az egyetlen módja annak, hogy magam fogom megtenni. "
A Polymost renderer lehetővé tette 3D hardveresen gyorsított grafikák használatát az OpenGL használatával . Ezenkívül bemutatta a "hightile" -t, amely lehetővé tette a játék eredeti textúráinak nagy felbontású cseréjét különböző formátumokban. A Polymost -ot Jonathon Fowler JFBuild, JFDuke3D, JFShadowWarrior és a kódbázisukból származó forrásportokban használták fel.
32
Később megjelent az EDuke 2.0 forrása, ezt követte az EDuke 2.1 utolsó privát bétájának forrása (amely soha nem került kiadási verzióra). Richard Gobeille (TerminX) egyesítette az EDuke 2.0 forrást a JFDuke3D -vel, hogy EDuke32 legyen . Egy másik kikötő, a Wineduke , az icculus kód alapján, azóta megszűnt, így az EDuke32 az egyetlen EDuke port, amely még fejlesztés alatt áll.
Az EDuke32 támogatja a NAM és a második világháborús GI játékokat is , mivel az EDuke ezen játékok kódján alapult.
Polimer
2009. április 1 -jén kiderült, hogy egy OpenGL shader modell 3.0 renderert fejlesztettek ki az EDuke32 -hez , Polymer néven, hogy megkülönböztessék Ken Silverman Polymost -tól . Eleinte áprilisi tréfának hitték, de a megjelenítőt később nyilvánosságra hozták. Modernebb effektusokat tesz lehetővé, például valós idejű dinamikus színes megvilágítást és árnyék-leképezést, tükröződést és normál leképezést , valamint egyéb árnyékoló alapú funkciókat a Polymosthoz az évek során hozzáadott legtöbb funkció mellett. Bár a polimer teljesen használható, technikailag hiányos és nem optimalizált, és még fejlesztés alatt áll. Az EDuke32 fejlesztői kijelentették, hogy miután a Polimert átírták a sebesség érdekében, teljesen kiszorítja a Polymost, mivel kiváló renderelő, és a Polymostéval azonosnak tekinthető.
Egyéb játékportok
| Fejlesztő (k) | Alexander "[M210]" Makarov |
|---|---|
| Első kiadás | 2018. január 12 . |
| Stabil kiadás | 1.04 / 2019. szeptember 13
|
| Adattár | gitlab |
| Felület | Jáva |
| típus | Játék motor |
| Engedély | Szabadalmazott |
| Weboldal | M210 |
A Shadow Warrior forráskódját 2005. április 1-jén adták ki GPL-2.0 vagy újabb licenc alatt, a JonoF pedig 2005. április 2-án kiadta annak forrásportját, a JFShadowWarrior-t. Azonban elismerte, hogy hozzáférhet a A Shadow Warrior forráskódja körülbelül egy héttel a megjelenése előtt. Ezt a portot később a ProASM elágazta az SWP porthoz.
A Transzfúziós projekt célja a Blood in the DarkPlaces motor újrateremtése volt , de 2006-tól ez a projekt még korántsem teljes, bár teljes deathmatch multiplayerrel rendelkezik; hasonló projekt BloodCM amely újrateremti az összes Monolith készült egyjátékos szintek Blood tetején EDuke32, valamint ZBlood mely portok néhány Blood eszközök és szintek rá ZDoom .
A Witchaven , a Witchaven II: Blood Vengeance , a William Shatner TekWar és a Corridor 8: Galactic Wars forráskódja is napvilágot látott . Ezek jogi helyzete azonban nem világos. A teljes forráskód egy alfa verziója Blood is kiszivárgott, és ezt használjuk referenciaként az egyébként visszafejtettek port Java használatával LibGDX nevű BloodGDX május 2017.
Ez a szerző korábbi, januárban megjelent TekWar portjából következett , majd a Witchaven , a Redneck Rampage , a Duke Nukem 3D , a Powerslave , a Legends of the Seven Paladins és az Shadow Warrior portjai követték nyomon , mostantól együtt BuildGDX néven .
2019 januárjában megjelent egy újabb Blood port , NBlood néven, az EDuke32 és az alkotó korábbi Rednukem portálja alapján, a Redneck Rampage számára . 2019. november 21 -én megjelent a PCExhumed nevű EDuke32 port a PowerSlave számára .
A forrás port lerombol Forks különböző Építőanyag motor kikötők, beleértve JFDuke3D , SWP , NBlood , Rednukem és PCExhumed , és a kapcsolatok, hogy egy új, mögöttes háttér alapján GZDoom .
Utód
Miután többször megpróbálta megtervezni a Build utódját, 2006 -ban Silverman ismét kísérletezni kezdett egy ilyen ötlettel. Ezt a munkát - ma Build 2 -nek hívják - felhasználta, miközben 2007 -től 2009 -ig egy nyári táborban tanította meg a gyerekeknek a 3D -s játékprogramozást, és a munka folytatódott. 2011 -ig, amikor elvesztette érdeklődését a projekt iránt. Fejlettebb világítási rendszerrel, voxel-rendereléssel rendelkezik az entitások számára és valódi helyiség-helyiség 3D-s terek, és legalább részben megmaradt az eredeti Build-szel való visszafelé való kompatibilitás. Silverman 2018. március 7 -én tette közzé tervezeteit a nyilvánosság számára. A forráskódot 2019. június 8 -án tették közzé saját licenc alatt.
