A játékmotor a videojátékokban használt geometriai és fizikai számításokat végző szoftverösszetevők gyűjteménye . A szerelvény képez szimulátor a valós idejû visszajátszási jellemzőket fantáziavilágokat amelyben a készletek tartanak. A játékmotor célja, hogy egy fejlesztő csapat a számítógépes problémák megoldása helyett a játék tartalmára és folyamatára koncentrálhasson.
A 3D motor vetítési számításokkal készít képeket , míg a 2D motor raszteres képek egymásra építésével építi fel a játék képét . A motor keveri a hangokat és a zenét a játék során. A játékmotorok szkriptelési képességei lehetővé teszik a nem játszható karakterek viselkedésének szimulálását kevés programozással vagy anélkül, és a fizika motorját a fizika szabályainak, például a tehetetlenségnek vagy a gravitációnak a kikényszerítésére használják . hogy reálisabb mozdulatokat szerezzen.
A játékmotor (francia játékmotor ) fogalma az 1990-es években jelent meg, utalva a lövöldözős játékok első személyben használt szoftverére , mint például a Doom . Az Architecture of Doom volt egyértelmű különbséget a motor alkatrészek a játék, és saját digitális Doom mint a grafika, a hangok, a zene, a jelenetek és magatartási szabályokat, amelyek reprodukálják a hangulat a játék. A komponensek a motor volt, ezért újra, kisebb módosításokkal, más fegyverekkel, más ellenségekkel és más játékszabályokkal, amelyek lehetővé tették az új játékok gyorsabb piacra juttatását, mint korábban.
A modern videojátékokban vannak olyan fő készletek, amelyeket néha külön motorok kezelnek, amelyek mindegyike a fejlesztés egy meghatározott funkciójához kapcsolódik: a rendszer (bemenet / kimenet, felhasználói felület, memória stb.), Grafika, hang, hálózat (többjátékos játékokhoz) , fizika és mesterséges intelligencia . A játékmotor a játék elkészítéséhez szükséges speciális motorok összessége. Például a Valve Software forgalmazza a Source motort, amely a játékmotorjának kereskedelmi neve. A Source motor egy „kulcsfontosságú fejlesztési megoldás”. Kézben ”csoportosítás a játék fejlesztéséhez szükséges különféle motorokat (grafika, hang ...). Ennek a játékmotornak a fizikáját a harmadik cég által szakosodott és fejlesztett Havok motor kezeli, amelyet más játékokban is használnak. motorok.
A játékkészítő stúdió megválasztása tehát általában a játék fejlesztéséhez szükséges motorok egészének vagy egy részének megvásárlására vagy fejlesztésére korlátozódik. Fontos azonban kiemelni, hogy a játékmotorok szerepe évek óta folyamatosan növekszik. nő. A játékmotorok fejlesztése által képviselt beruházás folyamatosan növekszik, és megnehezíti, vagy akár lehetetlenné teszi egyetlen gyártmány amortizálását.
Az utóbbi években leginkább használt vagy észrevett játékmotorok közül megemlíthetjük (nem teljes felsorolás): a Renderware , a különféle Unreal motor , Unity , Quake motor , a Source motor , a CryEngine , a Torque Game Engine , RealityEngine , Novodex , Antiryad Gx stb.
Az ingyenes szoftveres játékmotorok közül megemlíthetjük:
Vezetéknév | Fő nyelv | Grafikus könyvtár | Hangkönyvtár | Megjegyzések |
---|---|---|---|---|
Blender Game Engine | Piton | OpenGL | OpenAL | Blender köré épült |
Kocka | ? | OpenGL | ? | szakosodott FPS |
Godot | GDScript, a Python változata | OpenGL és OpenGL ES ) | ? | 2D és 3D orientált |
SZERETET | Lua | OpenGL | ? | 2D orientált 3D kiterjesztésekkel. |
Luxe vagy LuxeEngine | Haxe | WebGL | ? | |
Fegyverzet vagy fegyverzet motorja | Haxe | OpenGL , WebGL és Vulkan | ? | Blender köré épült |
Néhány vállalat manapság úgynevezett keretrendszer fejlesztésére specializálódott , vagyis testreszabható funkciókat biztosít. Az ilyen termékek használatának célja a „ négyzetkerék újrafeltalálása ” elkerülése, valamint egy már bevált szoftvercsomag újrafelhasználása, amely a játék elkészítéséhez szükséges több elemet tartalmaz. Számos ilyen típusú szoftver a videojátékok területén nyújt fejlesztési lehetőségeket a grafika számára , a hang, a fizika és a mesterséges intelligenciák megvalósítása. Két széles körben használt képviselő a Gamebryo és a RenderWare .
Egyes keretrendszerek csak egy lehetőséget nyújtanak, például a fák és növények szintézisét, ez a SpeedTree esete , ez a specializáció lehetővé teszi, hogy meggyőzőbb képeket hozzon létre, mint az általánosabb motorok.
Egyes keretrendszerek az összes forráskódot tartalmazzák , mások a programozási felület dokumentációjával együtt lehetővé teszik az újrafelhasználást más szoftverekben.
Minden játékmotor egyedi. Néhány funkció azonban megtalálható.
Ez a rész a külső eszközök olvasásával foglalkozik:
Felelős a játékadatok olvasásáért és az írásokról is ment.
Feladata lesz a játékadatok tömörítése / kicsomagolása (különösen a betöltés felgyorsítása érdekében). Felelős az esetleges titkosításukért / visszafejtésükért is.
Megtalálunk mindenféle matematikai függvényt, amely szükséges egy játék fejlesztéséhez. 3D-s játékhoz különösen:
Példaként említhetjük a játékmotorban nagyon gyakran végrehajtott számításokat: a mátrixok szorzását, a mátrixok inverzióját, a skalárt vagy a vektor szorzatot .
A fizika modul kiszámítja a tárgyak mozgását, egymással kölcsönhatásukat, a padlón vagy a falakon való csúszkálást, ugrálást stb. Ő is kiszámítja a puha tárgyak, a haj, a haj, a ruhák és egyéb függönyök alakváltozását. A szimuláció három fő kategóriáját különböztethetjük meg:
Az ütközéskezelés olyan szoftverréteg, amely lehetővé teszi két objektum találkozásának észlelését, és ezáltal képes meghatározni az ebből eredő műveletet. Az objektum ekkor a játék elemeinek (karakterek, akadály, lövedékek stb.) Geometriai ábrázolása. Az ütközési modul általában matematikai függvényekből áll, amelyek a metszéspontokat geometriai primitív párok alapján számítják ki: gömb gömb ellen, gömb doboz ellen, doboz háromszög ellen ... Ezen funkciók mindegyike a modul képességeinek megfelelően számol. , a d 'metszéspont, az érintkezési ponthoz tartozó normál, valamint a két tárgy behatolási távolsága.
Az ütközéseknek két fő kategóriája van:
A játék típusától függően egyik vagy másik megközelítést alkalmazzák. A mai 3D-s játékmotorok jellemzően e két módszer keverékét használják. Az összetett alakzatok ütközési számításainak optimalizálásához a játékmotorok felhasználhatják a záró kötet fogalmát, és általánosabban a záró kötetek hierarchiáját. A gyors, de hozzávetőleges számítás lehetővé teszi az ütközés nélküli állapotok kiküszöbölését, különben pontos számítást végeznek az objektumon. A befogadó kötetek hierarchiája csak további lépéseket ad hozzá azáltal, hogy az objektumot egyszerű formában zárt részekre osztja fel. Az objektumpár-számítások számának csökkentése érdekében a motorok általában a teret közeli objektumok részhalmazaiba strukturálják.
A háromdimenziós játékokban a jeleneteket és a játékon belüli tárgyakat (szörnyeket, járműveket, lövedékeket) a sokszögek - gyakran háromszögek - háromdimenziós koordinátáiként rögzítik. Minden sokszög sorozat alkotja a játék világának különböző tárgyainak körvonalait. A 3D motor képszintézis számításokat végez annak érdekében, hogy a játék világának kétdimenziós vetületét kapja, amely vetület a képernyőre kerül.
Az úgynevezett sokszögű renderelés (vagy raszterizálás ) folyamatában a 3D motor egy adott szempontból kiszámítja a vetítést , kezdve az ebből a szempontból legtávolabbi sokszögekkel. A felületek textúrája (színe, mintázata stb.) Egy mátrix kép, amelyet a vetületre való felvitel előtt a sokszög távolsága és orientációja szerint torzítanak.
Az úgynevezett voxel folyamatban ( térfogat és pixel összehúzódás ) a játékban lévő tárgyakat kocka (voxel) sorozat formájában rögzítik, és a vetítés kiszámításához a sokszögű renderelési folyamatot használják .
A sugárvetítés (vagy sugárkövetés ) említett módszerében a 3D-s motor kiszámítja a vetület egyes pixeleinek színét (ami raszteres kép ), fordítva számolva a fény által az egyes pixelek fénypontját. kép, a geometriai optika szabályainak megfelelően, például az átlátszóság , a visszaverődés vagy a fénytörés . Ez a folyamat nagyon reális képeket ad, de nagy számítási teljesítményt igényel, és 2011-ben még mindig kevéssé használják videojátékokhoz.
A vetítési számításokat a grafikus processzor (rövidítve GPU ) hajthatja végre, míg a központi processzort egyéb számításokhoz, például hangmotorhoz vagy szkriptekhez használják.
A hangmotor ötvözi az audiolejátszó szoftvert a keverőszoftverrel és a hangeffektus- generátorral (visszhang, tömörítés, térbelisítés). A három komponens összekapcsolódik.
A motor folyamatosan számítja a szintetikus hang- és digitális jelfeldolgozást , minták ( minta ) digitalizált zenei pontszámok (gyakran MIDI formátum ) és hullámosíthatók alapján . Néhány hangmotor szimulálja a távoli forrásból kibocsátott hang visszhangját , fáziseltolódását és hangszínváltozását, és ezáltal hallási illúziókat produkál .
A szkriptnyelveket gyakran használják a videojátékokban, hogy beállítsák az ellenségek és gépek viselkedését, és szimulálják intelligenciájukat . A szkriptnyelv használata lehetővé teszi, hogy a tervezők vagy a forgatókönyvírók, akik alig vagy egyáltalán nem rendelkeznek programozási ismeretekkel, "beállíthatják" az ellenségek viselkedését, és így módosíthatják a játékmenetet anélkül, hogy programozót hívnának. Történelmileg felmerült a parancsfájl-rendszer iránti igény a sok interakciót igénylő kalandjátékok számára. Ennek eredményeként létrejött a Script Creation Utility for Maniac Mansion (SCUMM). Eredetileg létrehozták, és amint a neve is utal a Maniac Mansion (1987) játékra , és minden új játékhoz minimális módosítással újrafelhasználta, tíz évvel később újra felhasználta a The Curse of Monkey Island (1997) című darabot . A játékok többi műfaja is bonyolulttá vált, játékmotorjaikba gyakran beépítettek egy szkriptrendszert.
A Jedi Knight: Dark Forces II (1997) fejlesztéséhez a játékmotort úgy alakították át, hogy támogassa a szkript nyelvét. Robert Huebner, aki részt vett ebben a fejlesztésben, elmagyarázza, hogy korábban volt egy INF bináris nyelv, amelyet nehéz volt asszimilálni - erre a célra egy teljes füzetet szántak. A megvalósított szkriptnyelvet, a COG-t menet közben állítják össze a játék indításakor, majd egy virtuális gépen ( akkumulátorral működtetett automata ) futtatják a játék robusztusságának biztosítása érdekében. Nem jelentettek negatív következményeket sem a fejlesztés, sem a fejlesztés során. maga a játék, sokkal inkább a tervezők kreativitásának növekedése. Néhány vállalat kifejlesztette saját szkriptnyelveit, a fent leírtak szerint. Ez is a helyzet id Software a QuakeC nyelv vagy Epic Games a UnrealScript nyelvet . De egy szkriptnyelv integrálása nagyon hozzáférhetővé vált, egyes szoftverkönyvtárakat külön erre a célra fejlesztenek. Ez a helyzet a könyvtárral és a Lua nyelvvel, amelyet nagyon sokféle műfajú játékban használtak .