Jaký je rozdíl mezi herním rámcem a herním enginem?

Ve skutečnosti neexistují striktní definice výrazů „engine“ nebo „framework“.

Obecně lze říci, že engine „dělá více“ nebo mají více nástrojů a související podporu než rámec, což je samo o sobě často jen volná sbírka souvisejících funkcí vystavená prostřednictvím nějakého sjednoceného API.

Za tímto účelem mohou věci, které se prohlašují za motory, používat věci, které tvrdí, že jsou rámce pro dosažení funkčnosti, ale nemusí tomu tak vždy být. Podobně věc, která tvrdí, že je herním strojem, může tvrdit, že její součásti (fyzika a vykreslování atd.) jsou implementovány pomocí fyzikální engine nebo fyzikální rámec. Druhy technologií, na které odkazují oba termíny, lze použít zaměnitelně či nikoli.

Mohou existovat „motory“ nebo „rámce“ pro téměř cokoli – fyziku, zvuk a ano, dokonce i 2D nebo 3D grafiku.

Je to opravdu jen terminologie problém a obecně na tom moc nezáleží. Z hlediska funkčnosti, perspektivy zaměřené na to, jak svou hru vytvořit, by mělo záležet na tom, zda daná technologie přináší či neposkytuje to, co pro svou hru potřebujete. Ať už si to říká motor nebo rámec, nebude to mít žádný vliv.

Jednoduchá definice, kterou používám : můžete postavit engine na frameworku, ale na enginu byste ho nikdy nepostavili. Jedním z nich je kostra, která určuje architekturu a tok programu, druhým je sval, který dělá práci.

Pro konkrétní příklad, Artemis je elegantní malý rámec pro vytváření komponentních systémů, ale nikdy byste jej nenazvali motorem. Můžete vytvořit Artemis Systems a standardní komponenty a vytvořit z toho engine.

Komentáře

• V mé společnosti někdo navrhl rámec přes engine. tento rámec slouží jako sbírka chybějících částí, které engine neposkytuje, sjednocuje věci, které jsou jinak v našem (starém) enginu trochu neupravené. A poskytuje pomocníky pro usnadnění vývoje.

Rámec je sbírka (obvykle) knihoven nižší úrovně a pomocné věci, které můžete použít, abyste dělali cokoli sakra chcete (grafika, zvuky atd.). Rámec neobsahuje nic, co by se týkalo hry, kromě toho, že jsou obvykle optimalizovány nebo navrženy tak, aby dělaly věci, které jsou ve hrách běžné.

Příklad: engine vám umožňuje mít seznam entit, každá s pozicí na mapě. Rámec vám umožňuje vykreslit 3D objekt na určité pozici.

Takže je propojíte tak, že každé ze svých entit dáte 3D objekt, a v případě potřeby je vykreslíte.

A ta-da, máte hru.

Pro opravdu podrobné vysvětlení doporučuji přečíst si tu a pouze bible Game Engine Architecture od Jasona Gregoryho. Myslím, že je to nejkompletnější práce o tomto tématu od jejího vydání. Nezabývá se pouze částí C ++, ale a také důležité pro každého programátora herního enginu je teorie / architektura. Je to dobrý výchozí bod nezávisle na jazyku. Chcete-li získat přehled, o čem mluvíme, je tento obrázek z knihy

Pokusím se na otázku odpovědět.

Cokoli napíšete, bude to kód 🙂 po letech zkušeností napište, co potřebujete a jak to potřebujete, nebo použijte to, co vám poskytne to, co potřebujete.

Výrazy engine a framework přijít ze softwarové architektury spolu s dalšími pojmy. Pojďme tedy začít se základními pojmy a pojďme se posunout nahoru.

---

Knihovna

Typické příklady: matematická knihovna poskytující všechny základní typy a funkce pro matematické výpočty (Vector, Matrix, …) nebo knihovna obrázků (jpeg nebo png) poskytující funkce pro psaní obrázků jpeg nebo png

V Unity 3D Matematika je matematické libray.

Teorie: libray poskytuje specializované funkce týkající se tématu (např. matematika ) AND je volán programátorem na vyžádání .

Nějaký náhled: mohou existovat knihovny, které obsahují frameworky aka jsou frameworkovou knihovnou.

---

Framework

Teorie: Rámec zavádí inverzi řízení . To znamená, že vývojář většinu času nevolá metody rozhraní, ale rozhraní volá kód vývojáře. Výjimkou je situace, kdy musíte do svého kódu integrovat knihovnu rozhraní a musíte rozhraní spustit. Knihovna architektury poskytuje všechny metody a funkce a rozhraní pro architekturu s vyhrazeným využitím. Rámec tedy může být v knihovně.

Typický příklad: Unity 3D MonoBehaviour poskytuje metody jako Awake, Start, OnUpdate. Vývojář implementuje tyto metody a poté tyto metody zavolá rámec (správa objektů hry) (toto je inverze ovládání) . Totéž s metodami OnCollisionEnter, OnCollisionExit. Jsou ve stejném Monobehaviouru, ale vsadil bych se, že se jim říká rámec fyziky.

---

Náhled: Engine, Runtime, Editor, SDK

Vzhledem k tomu, že výraz engine byl vždy trochu vágní a stále je (a s dalším technologickým vývojem se nezlepšuje) nějaké vysvětlení náhledu.

Termín engine se používá pro více věcí a nelze jednoznačně říci, která z nich má pravdu. V roce 2004, kdy jsem poprvé kontaktoval psaní herních enginů, to bylo také vágní. Měli jste herní engine ve smyslu nějakého druhu načítání kódu předdefinovaných dat a nechali jste si hru zahrát. Vzhledem k tomu, že načítá předdefinovaná data, říkalo se jim datové motory. Zkompilujete je jednou a externí data mohla být různými hrami, aniž byste je překompilovali. V určitém okamžiku to bylo stejné jako za běhu.

Editor je jasný. Umožňuje definovat předdefinovaná data načtená modulem / modulem runtime.

Stroj s editorem se jmenoval SDK (např. Hammer SDK).

Pak existovaly / jsou vyhrazené nástroje. Phyiscs engine, rendering engine, sound engine, engineobject management engine, network engine, ….

Podle mého osobního názoru to nejsou enginy (zejména renderovací engine NENÍ herní engine, protože dělá pouze vykreslování). Když jsem google herní engine, výsledky obsahují 90% čisté renderovací enginy, které nejsou herní enginy. Nazval bych všechny z nich knihovnami, ale protože mohou načítat předdefinovaná data, odpovídaly by pojmu engine řízený daty.

Poslední krátká poznámka, než se dostaneme do podrobností: Úspěšně jsem absolvoval magisterský titul v oboru počítačová věda. Moje diplomová práce se zabývala tématem „jak vyvinout jádro herního enginu“. To znamená část kódu, která spojuje všechny ostatní enginy, dělá správu herních objektů, herní smyčku atd …

Vydal jsem svou diplomovou práci jako (krátkou) knihu. Jediný komentář kupujícího / čtenáře k Amazonu je (po několika letech): nejde o herní engine. Vzhledem k tomu, že jsem úspěšně promoval, a proto jsem svou práci obhájil proti 3 zkušeným programátorům (z nichž 2 se věnují hrám a interaktivním aplikacím), myslím, že jsem napsal herní engine.

---

Editor

Snadné: umožňuje definovat data ve formátu, který ostatní části vyžadují, a proto eliminuje požadavek na zápis těchto souborů ručně nebo k jejich vytvoření použijte externí nástroje.

To je to, co dělá editor Unity 3D.

---

Runtime

Tento výraz se často používá stejně jako engine (což může být správné nebo nesprávné).

Modul runtime provede vygenerovaná data a provede s nimi data. Například vám ukážeme hru a necháte ji hrát. Nevytváří žádná data (kromě snad ukládání her), což znamená, že samotnou hru nemůžete upravovat.

Unity Web Player je / byl běhový modul a umožňuje vám hrát hry Unity ve webovém prohlížeči.

Můžete načítat a spouštět více různých her se stejnou dobou běhu.

V případě skriptovacího API Unity 3D existuje omezení mezi funkcemi, které budou ve hře fungovat, který bude fungovat pouze v editoru.

---

SDK

Tento termín se často nazývá také framework .

Tehdy byla sada SDK balíkem nástrojů, jako je editor, IDE (integrované vývojářské prostředí) pro programátory, exportéry pro datové formáty a runtime / engine.

Takže SDK / framework vám poskytuje předdefinovaný pracovní tok a nástroje a ukazuje vám (dobře navržený) způsob jak můžete (snadno) vytvořit hru.

V zásadě by se Unity 3D engine mýlil, protože by zapadal více do směru SDK. Ale protože Unity je ještě více, je potřeba nové slovo / definice, aby odpovídalo tomu, čím je.

Každopádně, pro představení druhého výrazu vám SDK / framework poskytuje předdefinovaný vývojový kanál hry (nejen aktivum potrubí, ale možná, stejně jako Unity, potrubí pro prostředky, logiku, sestavení, nasazení, ….)

---

Engine

sarkazmus na Používá se na všechno, protože každý chce být v pohodě tím, že budete psát nejen knihovnu, framework nebo hru, ale lépe napsat kompletní engine. sarcasm off

Pojďme to spustit:

Stroj

1. je část kódu / softwaru
2. jehož cílem je opětovné použití ve více projekty (můžete také napsat herní engine pouze pro jednu hru)
3. pro opětovné použití herní engine odděluje opakovaně použitelnou část od konkrétní herní části
4. pro opětovné použití (v závislosti na tom, jak to je určené k opětovnému použití) existují různé příchutě, jako je datově řízený engine načítání externích dat

Motor se může skládat z několika dalších motorů (protože dnes se všechno nazývá motor). Herní engine může obsahovat

• renderovací engine provádějící vykreslování (AGAIN: bůh, sakra, peklo: kód dělá pouze vykreslování NENÍ herní engine)
• fyzický engine dělat fyziku (to je fyzikální engine, ne herní engine)
• engine AI zpracovávající věci AI (je to engine AI a ne herní engine)
• a síťový modul (např. RakNet), který dělá síťové věci (je to síťový modul, nikoli herní modul)
• zvukový modul, který provádí zvukové věci (je to zvukový modul a ne herní modul)

Příklad aplikace založené na jádrovém enginu poskytující rámec založený na zásuvných modulech pro všechny informace v modelu správy objektů založeném na komponentách. Každý subengine (rendering audio) je modul přidaný do herního enginu jako plug in. Každá komponenta může být součástí subengine / modulu. Správa herních objektů (založená na komponentech) je spojovacím článkem mezi oddělenými moduly.

---

Nejbližší definice pro herní engine

A herní engine je součástí zdrojového kódu vaší hry, která poskytuje všechny funkce , kterou je určené k opakovanému použití ve více hrách a umožní vám kód a spuštění vaše hra. Proto získává dohromady všechny ostatní části kódu (vykreslování, zvuk, fyzika, správa herních objektů, síťování), které jsou buď knihovny, rámce nebo vyhrazené enginy (rendering, fyzika, …).

Herní engine je nepořádek uprostřed.

---

Jak již @Josh uvedl, neexistuje striktní definice rámce nebo enginu, ale v koncepčním smyslu jsou oba velmi odlišné nástroje.

Rámec obsahuje základní abastrakci API, se kterou lze pracovat, což dává uživateli na vyšší úrovni nástroje pro interakci s platformou nebo funkcemi, aniž by se (obecně) staral o výkon, kompatibilitu atd. V příkladech, které jste uvedli, je SDL rámec, který dává abstarction over the platform, and you can build your software behind that layer without worring with window management, OS specific things, etc. If you want to build a whole software, you will need to different frameworks, fe SDL to manage the media and platform stuff, Box2D to manage fyzics, etc.

Engine je jiný, v tomto případě nástroj dodává vše potřebné pro vývoj, fyzikální engine vám poskytne se vším potřebným pro správu fyziky a dodá snadno použitelné API, takže pokud chcete vytvořit simulaci fyziky, nepotřebujete žádnou další knihovnu třetích stran. Motory nejsou nic jiného než kolekce rámců, jiných motorů, rozhraní, úryvků a obecného kódu, které poskytují vše potřebné k dokončení projektu, aniž by bylo potřeba dalších třetích stran, aniž by se museli starat o věci na nižší úrovni.