Mi a különbség a játék keretrendszere és a játékmotor között?

A “motor” vagy a “keretrendszer” valójában nincsenek szigorú meghatározások.

Általánosságban elmondható, hogy a motor “többet csinál”. vagy több eszközzel és kapcsolódó támogatással rendelkezik, mint egy keretrendszer, ami gyakran csak a kapcsolódó funkciók laza gyűjteménye, amely valamilyen egységes API-n keresztül van kitéve.

Ebből a célból a motornak mondott dolgok olyan dolgokat használhatnak, amelyek azt állítják, hogy a funkcionalitás elérésének keretrendszere, de ennek nem mindig kell így lennie. Hasonlóképpen, egy játékmotornak valló dolog azt állíthatja, hogy alkotó részeit (a fizika és a renderelés stb.) egy fizikai motor vagy fizikai keretrendszer. A mindkét kifejezés által említett technológiák felcserélhetők, vagy sem.

Lehetnek “motorok” vagy “keretek” szinte mindenre – fizikára, hangra, és igen, akár 2D vagy 3D grafikára is.

Ez valójában csak egy terminológia kérdés, és ez általában nem számít sokat. A funkcionalitás szempontjából, a játék elkészítésére összpontosítva, az számít, hogy a kérdéses technológia biztosítja-e a játék elkészítéséhez szükségeset vagy sem. Az, hogy motornak vagy keretrendszernek hívja-e magát, ennek semmi köze nincs.

Egyszerű meghatározás, amelyet használok : motort építhet keretrendszerre, de soha nem építene keretet motorra. Az egyik a csontváz, amely meghatározza az architektúrát és a program folyamatát, a másik az izom, amely elvégzi a munkát.

Egy konkrét Például az Artemis egy szép kis keretrendszer az alkatrész rendszerek felépítéséhez, de soha nem hívnád motornak. Megépítheti az Artemis Systems rendszert és a szokásos alkatrészeket, hogy motorot hozzon létre belőle.

Megjegyzések

• Az én cégemben valaki egy keretet tervezett a motorra. ez a keretrendszer hiányzó alkatrészek gyűjteményeként szolgál, amelyeket a motor nem szolgáltat, egyesíti a (régi) motorunkban egyébként kissé rendetlen dolgokat. És segítséget nyújt a fejlesztés megkönnyítéséhez.

A keretrendszer (általában) alacsonyabb szintű könyvtárak gyűjteménye és segítő dolgok, amelyekkel bármit megcsinálhatsz (grafika, hangok stb.). A keretrendszeren nincs semmi játékhoz kapcsolódó dolog, kivéve, ha általában a játékokban elterjedt dolgokra optimalizálják vagy tervezik őket.

Példa: egy motor lehetővé teszi az entitások listájának elkészítését, amelyek mindegyikének vannak pozíciói. a térképen. A keretrendszer lehetővé teszi egy 3d objektum renderelését egy bizonyos helyen.

Tehát összekapcsolja őket úgy, hogy mindegyik entitásának egy 3d objektumot ad, és ha szükséges, megjeleníti őket.

És ta-da, van játékod.

Az igazán részletes magyarázatért javaslom elolvasni a csak Jason Gregory biblia Játékmotor-architektúra . Gondolom, ez a témával kapcsolatos legteljesebb munka a megjelenése óta. Nem csak a C ++ részt kezeli, hanem és minden játékmotor programozó számára fontos a mögöttes elmélet / architektúra. Ez a nyelvtől független jó kiindulópont. Ha áttekintést szeretnénk kapni, ez a kép a könyvből

Hadd próbáljam meg megválaszolni a kérdést.

Bármit is írsz, az kód lesz 🙂 több éves tapasztalat után írd meg, mire és mire van szükséged, vagy használd azt, amire szükséged van.

A motor és framework jön a szoftverarchitektúrától, más kifejezésekkel együtt. Tehát kezdjük az alapfogalmakkal, és engedjük, hogy felfelé haladjanak.

---

Könyvtár

Tipikus példák: egy matematikai könyvtár, amely az összes alapvető típust és funkciót biztosítja a matematikai számításokhoz (vektor, mátrix, …), vagy egy kép (jpeg vagy png) könyvtár, amely biztosítja a jpeg vagy png képek írásának funkcióit

Az Unity 3D-ben a A matematika egy matematikai könyvtár.

Elmélet: a könyvtár egy dedikált funkciót biztosít a téma körül (pl. matematika) ) ÉS A -t a programozó igény szerint meghívja .

Néhány előnézet: létezhetnek olyan könyvtárak, amelyek keretrendszereket tartalmaznak, más néven kerettárak.

---

Framework

Elmélet: A keretrendszer a vezérlő inverzióját vezeti be . Ez azt jelenti, hogy a fejlesztő legtöbbször nem a keretrendszer metódusait hívja meg, hanem a keretrendszer a fejlesztő kódját hívja meg. Kivételt képez az az eset, amikor integrálnia kell a keretrendszer könyvtárat a kódjába, és el kell indítania a keretrendszert. A keretrendszer-könyvtár minden módszert, funkciót és interfészt biztosít egy keretrendszer számára, külön felhasználással. Tehát a keretek lehetnek egy könyvtárban.

Tipikus példa: A Unity 3D MonoBehaviour olyan módszereket nyújt, mint az Ébredés, a Start, az OnUpdate. A fejlesztő végrehajtja ezeket a módszereket, majd ezeket a módszereket a (játékobjektum-menedzsment) keretrendszer hívja meg (ez a vezérlés inverziója) . Ugyanez az OnCollisionEnter, OnCollisionExit módszerekkel is. Ugyanabban a mono-viselkedésben vannak, de fogadni mernék, hogy a fizikai keretrendszer hívja meg őket.

---

Előnézet: Motor, Futásidejű, Szerkesztő, SDK

Mivel a motor kifejezés mindig kissé homályos volt, és még mindig (és a további technológiai fejlődéssel nem válik jobbá) némi előnézet magyarázat.

A motor kifejezést több dologra használják, és nem lehet egyértelműen megmondani, hogy melyiknek van igaza. Még 2004-ben, amikor először találkoztam játékmotorok írásával, ez is homályos volt. Volt egy játékmotorod valamiféle kód értelmében, amely előre meghatározott adatokat tölt be, és lehetővé teszi a játékot. Mivel előre definiált adatokat tölt be, ezeket adatvezérelt motoroknak hívták. Összeállítja őket egyszer, és a külső adatok különböző játékok lehettek volna, anélkül, hogy újrafordítanák őket. Valamikor ez ugyanaz volt, mint a futás.

A szerkesztő egyértelmű. Ez lehetővé teszi a motor / futásidő előre betöltött adatainak meghatározását.

Egy szerkesztővel rendelkező motort SDK-nak hívtak (pl. Hammer SDK).

Akkor voltak dedikált motorok. Phyiscs motor, renderelő motor, hangmotor, játékobjektum-kezelő motor, hálózati motor, ….

Személyes véleményem szerint ezek nem motorok (főleg a render motor NEM játékmotor, mivel csak renderelés). Amikor google játékmotort keresek, az eredmények 90% -ban tiszta render motorokat tartalmaznak, amelyek nem játékmotorok. Mindegyiket könyvtárnak nevezném, de mivel előre meghatározott adatokat tölthetnek be, ezért megfelelnek az adatvezérelt motor kifejezésnek.

Utolsó rövid mellékjegyzet, mielőtt a részletekbe kezdenénk: sikeresen diplomáztam a Számítástechnika. A diplomamunkám azzal foglalkozott, hogy “hogyan lehet fejleszteni a játékmotor magját”. A kódnak azt a részét jelenti, amely összekapcsolja az összes többi motort, elvégzi a játékobjektum-kezelést, a játékhurkot stb. …

A diplomamunkámat (rövid) könyvként publikáltam. Az Amazon egyetlen megjegyzése egy vevőtől / olvasótól (néhány év múlva): ez nem játékmotorról szól. Mivel sikeresen érettségiztem és ezért megvédtem a diplomamunkámat 3 tapasztalt programozóval szemben (akik közül kettőt játékoknak és interaktív alkalmazásoknak szenteltek), azt hiszem, írtam egy játékmotort.

---

Szerkesztő

Könnyű: lehetővé teszi az adatok olyan formátumban történő meghatározását, amelyre a többi résznek szüksége van, és így megszűnik a fájlok írásának igénye kézzel, vagy külső eszközöket hozhat létre ezek létrehozásához.

Ezt a Unity 3D szerkesztő teszi.

---

Futásidejű

Ezt a kifejezést gyakran használják a motorral (ami lehet helyes vagy helytelen).

A futásidejű végrehajtja a létrehozott adatokat, és megteszi, amit az adatokkal kapcsolatos. Pl. Mutassa meg neked a játékot, és engedje meg, hogy játsszon. Nem hoz létre adatokat (kivéve talán a játékok mentését), vagyis nem változtathatja meg önmagában a játékot.

A Unity Web Player futási idő volt / volt, amely lehetővé teszi, hogy Unity játékokat játsszon egy webböngészőben.

Több különböző játékot is feltölthet és futtathat ugyanazzal a futási idővel.

A Unity 3D parancsfájl-kezelő API esetében van egy vágás a játékban működő funkcionalitás és a funkcionalitás között. ez csak a szerkesztőn belül működik.

---

SDK

Ezt a kifejezést gyakran más néven keretrendszernek nevezik .

Akkoriban az SDK egy sor eszköz volt, mint például szerkesztő, IDE (integrált fejlesztői környezet) programozóknak, exportálók az adatformátumokhoz és a futásidejéhez / motorjához.

Tehát az SDK / keretrendszer előre definiált munkafolyamatot és segédprogramokat nyújt Önnek, és egy (jól megtervezett) módot mutat be. hogyan lehet (könnyen) létrehozni egy játékot.

Alapvetően téves lenne a Unity 3D motor, mivel jobban illeszkedik az SDK irányába. De mivel a Unity még inkább egy új szóra / definícióra van szükség ahhoz, hogy megfeleljen annak, ami van.

Egyébként a másik kifejezés bevezetéséhez az SDK / framework egy előre definiált játékfejlesztési folyamatot kínál (nem csak eszközt) csővezeték, de lehet, hogy az Unity-hoz hasonlóan az eszközök, a logika, a buildek, a telepítések stb.) is.)

---

Motor

szarkazmus a mindenhez használható, mivel mindenki hűvös akar lenni nem csak könyvtár, keretrendszer vagy játék megírásával, hanem egy teljes motor megírásával. szarkazmus ki

Engedje le:

A motor

1. kód / szoftver darab
2. célja, hogy többször is újrafelhasználható legyen projektek (játékmotort is csak egy játékhoz írhatsz)
3. újrafelhasználás céljából a játékmotor elválasztja az újrafelhasználható részt a játék specifikus részéből
4. újrafelhasználható (attól függően, hogy hogyan) ez újrafelhasználásra szánják) különböző ízek vannak, például egy adatvezérelt motor külső adatok betöltése

A motor többféle motorból állhat (mivel manapság mindent motornak hívnak). A játékmotor tartalmazhat

• renderelő motort, amely a renderelést végzi (ÚJRA: isten, rohadt, pokol: a kódot csak a renderelés NEM játékmotor)
• egy fizikai motort fizikával foglalkozik (ez fizikai motor, nem játékmotor)
• egy AI motor, amely az AI dolgokat kezeli (ez egy AI motor, és nem játék motor)
• a hálózati motor (pl. RakNet), amely a hálózati dolgokat végzi (ez hálózati motor, nem játékmotor)
• egy audio motor, amely az audio dolgokat végzi (ez egy audio motor, és nem egy játék motor)

Példa egy magmotoron alapuló alkalmazásra, amely plug-in alapú keretet biztosít minden összetartozásához egy összetevő alapú játékobjektum-kezelési modellben. Minden egyes subengine (renderelő hang) egy modul, amelyet plug-inként adnak a játék motorjához. Minden alkatrész része lehet egy subengine / modulnak. A (komponens alapú) játékobjektum-kezelés pedig az összekötő kapcsolat az elkülönített modulok között.

---

A Game Engine legközelebbi meghatározása

A játékmotor a forráskód része A játék játékának, amely biztosítja az összes olyan funkciót, amely “686b0e923d”>

Ahogy @Josh már elmondta, nincs szigorú meghatározása a keretrendszernek vagy a motornak, de fogalmi értelemben mindkettő nagyon különböző eszköz.

A keretrendszer tartalmaz egy alapvető API absztrakciót, amellyel együtt lehet dolgozni, így a felhasználó magasabb szintű eszközökkel interakcióba léphet a platformmal vagy a funkcionalitással anélkül, hogy (általában) aggódna a teljesítmény, a kompatibilitás stb. Miatt. absztrakciót hajt végre a platformon, és a szoftvert ennek a rétegnek a mögé építheti anélkül, hogy aggódna az ablakkezelés, az operációs rendszer-specifikus dolgok stb. miatt. Ha egy teljes szoftvert szeretne felépíteni, akkor másra lesz szüksége keretrendszerek, pl. SDL a média és a platform dolgainak kezeléséhez, a Box2D a fizika kezeléséhez stb.

Egy motor más, ebben az esetben az eszköz mindent eljuttat a fejlesztéshez, egy fizikai motor biztosítja Önnek mindent tartalmaz, ami a fizika kezeléséhez szükséges, és egy könnyen használható API-t fog szállítani, így ha fizikai szimulációt szeretne felépíteni, akkor nincs szüksége más harmadik fél könyvtárára. A motorok nem több, mint keretrendszerek, más motorok, interfészek, kivonatok és általános kódok gyűjteménye, amely mindent megad a projekt befejezéséhez, anélkül, hogy más harmadik felekre lenne szükség, és nem kell aggódnia az alacsonyabb szintű dolgok miatt.