Care este diferența dintre un cadru de joc și un motor de joc?

Nu există definiții stricte pentru „motor” sau „cadru.”

În general, un motor este considerat „a face mai mult” sau au mai multe instrumente și suport conex decât un cadru, care este el însuși este adesea doar o colecție liberă de funcționalități conexe expuse printr-un API unificat.

În acest scop, lucrurile care pretind că sunt motoare pot folosi lucruri care pretind a fi cadre pentru a atinge funcționalitatea, dar nu întotdeauna trebuie să fie cazul. În mod similar, un lucru care pretinde a fi un motor de joc poate susține că părțile sale constitutive (fizica și redarea, etc.) sunt implementate cu un motor de fizică sau un cadru de fizică. Tipurile de tehnologie menționate de ambii termeni pot fi utilizate sau nu în mod interschimbabil.

Pot exista „motoare” sau „cadre” pentru aproape orice – fizică, sunet și da, chiar și grafică 2D sau 3D.

De fapt, este doar o terminologie problemă și, în general, nu contează prea mult. Dintr-o perspectivă a funcționalității, o perspectivă axată pe crearea jocului dvs., ceea ce ar trebui să conteze este dacă tehnologia în cauză oferă sau nu ceea ce aveți nevoie pentru a vă crea jocul. Indiferent dacă se numește un motor sau un cadru nu va avea nicio legătură cu asta.

Definiție simplă pe care o folosesc : puteți construi un motor pe un cadru, dar nu ați construi niciodată un cadru pe un motor. Unul este scheletul care determină arhitectura și fluxul programului, celălalt este mușchiul care face treaba.

Pentru un beton de exemplu, Artemis este un mic cadru îngrijit pentru construirea sistemelor componente, dar nu l-ați numi niciodată motor. Ați putea crea Sisteme Artemis și componente standard pentru a crea un motor din acesta.

Comentarii

• În compania mea, cineva a proiectat un cadru peste motor. acest cadru servește ca o colecție de piese lipsă pe care motorul nu le oferă ‘, unifică lucruri care altfel sunt puțin dezordonate în motorul nostru (vechi). Și oferă ajutoare pentru a facilita dezvoltarea.

Un cadru este o colecție de biblioteci (de obicei) de nivel inferior și lucruri de ajutor pe care le puteți folosi pentru a face orice naiba doriți (grafică, sunete etc.). Nu există nimic legat de joc despre un cadru, cu excepția faptului că acestea sunt de obicei optimizate sau concepute pentru a face lucruri obișnuite în jocuri.

Exemplu: un motor vă permite să aveți o listă de entități, fiecare cu o poziție pe hartă. Un cadru vă permite să redați un obiect 3d într-o anumită poziție.

Deci, le conectați oferind fiecărei entități un obiect 3d și le redați atunci când este necesar.

Și ta-da, aveți un joc.

Pentru o explicație foarte detaliată, vă recomand să citiți cea și only bible Game Engine Architecture de Jason Gregory. Cred că este cea mai completă lucrare despre acest subiect de când a fost publicată. Nu se ocupă doar de partea C ++, ci și de asemenea și important pentru fiecare programator de motoare de joc, teoria / arhitectura din spatele acestuia. Este un bun punct de plecare independent de limbaj. Pentru a obține o imagine de ansamblu despre ce vorbim este această imagine din carte

Permiteți-mi să încerc să răspund la întrebare.

Orice ai scrie va fi cod 🙂 după ani de experiență, scrie ce ai nevoie și cum ai nevoie sau folosește ceea ce îți oferă ceea ce ai nevoie.

Termenii motor și cadru din arhitectura software împreună cu alți termeni. Deci, să începem cu termenii de bază și să ne mișcăm în sus.

---

Biblioteca

Exemple tipice: o bibliotecă matematică care oferă toate tipurile și funcțiile de bază pentru calcule matematice (Vector, Matrix, …) sau bibliotecă de imagini (jpeg sau png) care oferă funcționalitatea pentru scrierea imaginilor jpeg sau png

În Unity 3D Math este un libray matematic.

Teorie: un libray oferă caracteristici dedicate în jurul unui subiect (de exemplu, math ) ȘI este apelat de programator la cerere .

Unele previzualizări: pot exista biblioteci care să dețină cadre care sunt, de asemenea, o bibliotecă cadru.

---

Framework

Teorie: un cadru introduce o inversiune a controlului . Aceasta înseamnă că dezvoltatorul nu apelează de cele mai multe ori metodele cadrului, dar cadrul apelează codul dezvoltatorului. Excepții fac atunci când trebuie să integrați biblioteca de cadru în codul dvs. și trebuie să porniți cadrul. O bibliotecă cadru oferă toate metodele și funcțiile și interfețele pentru un cadru cu o utilizare dedicată. Deci, cadrele pot fi într-o bibliotecă.

Exemplu tipic: Unity 3D MonoBehaviour oferă metode precum Trezire, Start, Actualizare. Dezvoltatorul implementează aceste metode și apoi aceste metode sunt apelate de cadrul (gestionarea obiectelor jocului) (aceasta este inversiunea controlului) . La fel și cu metodele OnCollisionEnter, OnCollisionExit. Sunt în același comportament Monobehavour, dar aș paria că sunt numiți de cadrul fizic.

---

O previzualizare: Motor, Runtime, Editor, SDK

Întrucât termenul motor a fost întotdeauna vag și încă mai este (și nu devine mai bun cu alte evoluții tehnologice) o explicație de previzualizare.

Termenul motor este utilizat pentru mai multe lucruri și nu se poate spune în mod unic care dintre ele are dreptate. În 2004, când am avut primul contact cu motoarele de jocuri de scris, a fost și vag. Aveați un motor de joc în sensul unui fel de cod care încărca date predefinite și vă permite să jucați jocul. Deoarece încarcă date predefinite, acestea au fost numite motoare bazate pe date. Le compilați o dată și datele externe ar fi putut fi jocuri diferite fără a le recompila. La un moment dat, acest lucru a fost la fel ca un timp de execuție.

Editorul este clar. Vă permite să definiți datele predefinite încărcate de motor / runtime.

Un motor cu un editor s-a numit SDK (de exemplu, Hammer SDK).

Apoi au existat / sunt motoare dedicate. Un motor phyiscs, un motor de redare, un motor de sunet, un motor de gestionare a obiectelor, un motor de rețea, …

În opinia mea personală, acestea nu sunt motoare (în special un motor de redare NU este un motor de joc, deoarece face doar redare). Când am google motor de joc, rezultatele conțin motoare de randare pură de 90%, care nu sunt motoare de joc. Le-aș numi pe toate biblioteci, dar din moment ce pot încărca date predefinite, acestea ar corespunde termenului motor bazat pe date.

O ultimă notă laterală scurtă înainte de a intra în detalii: am absolvit cu succes o diplomă de master în informatică. Teza mea de master a tratat subiectul „cum să dezvoltăm nucleul unui motor de joc”. Adică partea codului care indică împreună toate celelalte motoare, gestionează obiectele jocului, bucla jocului, etc …

Am publicat teza de master ca o carte (scurtă). Singurul comentariu despre Amazon de la un cumpărător / cititor este (după câțiva ani afară): nu este vorba despre un motor de joc. De când am absolvit cu succes și, prin urmare, mi-am susținut teza împotriva a 3 programatori cu experiență (2 dintre ei dedicați jocurilor și aplicațiilor interactive) cred că am scris un motor de jocuri.

---

Editor

Ușor: vă permite să definiți datele în formatul pe care le necesită celelalte părți și, prin urmare, elimină cererea de a scrie acele fișiere manual sau folosiți instrumente externe pentru a le crea.

Așa face editorul Unity 3D.

---

Runtime

Acest termen este adesea utilizat în mod egal cu motorul (care poate fi corect sau incorect).

Runtime execută datele generate și face ceea ce are de-a face cu datele. De exemplu, vă arată jocul și vă permit să jucați jocul. Nu creează date (cu excepția poate salvarea jocurilor), în sensul că nu puteți modifica jocul în sine cu acesta.

Unity Web Player este / a fost un timp de rulare care vă permite să jucați jocuri Unity într-un browser web.

Puteți încărca și executa mai multe jocuri diferite cu același timp de rulare.

În cazul Unity 3D scripting API există o reducere între funcționalitatea care va funcționa în joc și funcționalitate care va funcționa numai în editor.

---

SDK

Acest termen este adesea numit și cadru .

Pe atunci un SDK era un pachet de instrumente precum un editor, IDE (mediu dezvoltator integrat) pentru programatori, exportatori pentru formate de date și runtime / motor.

Deci, un SDK / framework vă oferă un flux de lucru și utilități predefinite și vă arată un mod (bine conceput) cum poți (cu ușurință) să creezi un joc.

Practic, motorul Unity 3D ar fi greșit, deoarece s-ar potrivi mai mult în direcția SDK. Dar, din moment ce Unity este și mai mult, este nevoie de un nou cuvânt / definiție pentru a se potrivi cu ceea ce este.

Oricum, pentru a introduce celălalt termen, un SDK / framework vă oferă o conductă de dezvoltare a jocului predefinită (nu numai un activ conductă, dar poate, ca Unity, o conductă pentru active, logică, versiuni, implementări, ….)

---

Motor

sarcasm pe Folosit pentru orice, deoarece toată lumea vrea să fie cool scriind nu numai o bibliotecă, un cadru sau un joc, ci mai bine scriind un motor complet. sarcasm off

Să declanșăm:

Un motor

1. este o bucată de cod / software
2. este menit să fie reutilizat în mai multe proiecte (puteți scrie, de asemenea, un motor de joc pentru un singur joc)
3. pentru a fi reutilizat, motorul de joc separă partea reutilizabilă de partea specifică jocului
4. pentru a fi reutilizabil (în funcție de modul în care este destinat a fi reutilizat) există diferite arome precum un motor bazat pe date încărcarea datelor externe

Un motor poate consta din alte motoare multipe (deoarece totul se numește motor în zilele noastre). Un motor de joc poate include

• un motor de redare care face redarea (AGAIN: zeu, naiba, iad: codul care face doar redarea NU ESTE un motor de joc)
• un motor de fizică exercitarea fizicii (este un motor de fizică, nu un motor de joc)
• un motor AI care gestionează lucrurile AI (este un motor AI și nu un motor de joc)
• a motor de rețea (de exemplu, RakNet) care face lucrurile de rețea (este un motor de rețea, nu un motor de joc)
• un motor audio care face lucrurile audio (este un motor audio și nu un motor de joc)

Un exemplu pentru o aplicație bazată pe un motor de bază care oferă un cadru bazat pe plug-in pentru a clua totul împreună într-un model de gestionare a obiectelor de joc bazat pe componente. Fiecare subengine (redare audio) este un modul adăugat motorului de joc ca plug-in. Fiecare componentă poate face parte dintr-un subengine / modul. Și gestionarea obiectelor de joc (bazate pe componente) este legătura de legătură între modulele separate.

---

Cel mai apropiat definiție pentru Game Engine

Un motor de joc face parte din codul sursă al jocului dvs. care oferă toate funcționalitățile care este destinat reutilizării pe mai multe jocuri și vă permite să cod și să executați jocul tău. Prin urmare, indică împreună toate celelalte părți ale codului (redare, audio, fizică, gestionarea obiectelor de joc, rețea) care sunt fie biblioteci, cadre sau motoare dedicate (redare, fizică, …).

Motorul jocului este mizeria din mijloc.

---

După cum a afirmat deja @Josh, nu există o definiție strictă a cadrului sau a motorului, dar, în sens conceptual, ambele sunt instrumente foarte diferite.

Un cadru conține o reducere a API-ului de bază pentru a lucra, oferind utilizatorului instrumente de nivel superior pentru a interacționa cu platforma sau funcționalitatea fără (în general) să vă faceți griji cu privire la performanță, compatibilitate etc. În exemplele pe care le-ați dat, SDL este un cadru vă abstracționați peste platformă și vă puteți construi software-ul în spatele acelui nivel, fără să vă faceți griji cu privire la gestionarea ferestrelor, lucruri specifice sistemului de operare etc. Dacă doriți să creați un software întreg, veți avea nevoie de diferite framework-uri, fe SDL pentru gestionarea materialelor media și platformă, Box2D pentru gestionarea fizicii etc.

Un motor este diferit, în acest caz, instrumentul livrează tot ce este necesar pentru dezvoltare, un motor fizic vă va oferi cu tot ce este necesar pentru a gestiona fizica și va livra un API ușor de utilizat, deci, dacă doriți să construiți o simulare fizică, nu veți avea nevoie de nicio altă bibliotecă terță parte. Motoarele nu sunt altceva decât o colecție de cadre, alte motoare, interfețe, fragmente și coduri generale, care oferă tot ce este necesar pentru a finaliza proiectul fără a avea nevoie de alte terțe părți și nici de griji pentru lucruri de nivel inferior.