Hvad er forskellen mellem en game framework og en game engine?

Der er virkelig ikke strenge definitioner for “motor” eller “framework”.

Generelt anses en motor for at “gøre mere” eller har flere værktøjer og relateret support end en ramme, som i sig selv ofte kun er en løs samling af relateret funktionalitet, der udsættes for gennem en samlet API.

Til det formål kan ting, der hævder at være motorer, bruge ting, der hævder at være rammer for at opnå funktionalitet, men det behøver ikke altid at være tilfældet. Tilsvarende kan en ting, der hævder at være en spilmotor, hævde, at det er de bestanddele (fysik og gengivelse osv.), fysikmotor eller en fysikramme. Den slags teknologi, der henvises til af begge udtryk, kan bruges ombytteligt eller ej.

Der kan være “motorer” eller “rammer” til næsten alt – fysik, lyd og ja, endda 2D- eller 3D-grafik.

Det er egentlig bare en terminologi problem, og det betyder generelt ikke meget. Fra et funktionalitetsperspektiv, et perspektiv fokuseret på at lave dit spil, hvad der skal have betydning er, om den pågældende teknologi leverer det, du har brug for til at lave dit spil eller ej. Uanset om det kalder sig en motor eller en ramme, har det ingen indflydelse på det.

Enkel definition, som jeg bruger : du kan bygge en motor på en ramme, men du vil aldrig bygge en ramme på en motor. Det ene er skeletet, der bestemmer arkitektur og programflow, det andet er muskler, der udfører arbejdet.

For en beton Eksempelvis er Artemis en pæn lille ramme til bygning af komponentsystemer, men man kalder det aldrig en motor. Du kunne bygge Artemis Systems og standardkomponenter til at oprette en motor ud fra det.

Kommentarer

• I mit firma designede nogen en ramme over motoren. denne ramme fungerer som en samling af manglende dele, motoren ‘ ikke giver, forener ting, der ellers er lidt rodet i vores (gamle) motor. Og giver hjælpere til at lette udviklingen.

En ramme er en samling af (normalt) biblioteker på lavere niveau og hjælper ting, som du kan bruge til at gøre, hvad helvede du vil (grafik, lyde osv.). Der er ikke noget spilrelateret ved en ramme, bortset fra at de normalt er optimeret eller designet til at gøre ting, der er almindelige i spil.

Eksempel: En motor giver dig mulighed for at have en liste over enheder, hver med en position på kortet. En ramme giver dig mulighed for at gengive et 3d-objekt på en bestemt position.

Så du forbinder dem ved at give hver af dine enheder et 3d-objekt og gengive dem efter behov.

Og ta-da, du har et spil.

For en virkelig detaljeret forklaring anbefaler jeg at læse den ene og eneste bibel Game Engine Architecture af Jason Gregory. Jeg antager, at det er det mest komplette arbejde om dette emne, siden det blev offentliggjort. Det håndterer ikke kun C ++ -delen, men også og vigtigt for enhver programmerer af spilmotorer teorien / arkitekturen bag. Det er et godt udgangspunkt uafhængigt af sproget. For at få et overblik, hvad vi taler om, er dette billede fra bogen

Lad mig prøve at besvare spørgsmålet.

Uanset hvad du skriver, bliver det kode 🙂 Efter mange års erfaring, skriv hvad du har brug for, og hvordan du har brug for det, eller brug det, der giver dig det, du har brug for.

Udtrykkene motor og framework kommer fra softwarearkitektur sammen med andre vilkår. Så lad os starte med de grundlæggende udtryk, og lad os bevæge os opad.

---

Bibliotek

Typiske eksempler: et matematikbibliotek, der indeholder alle de grundlæggende typer og funktioner til matematiske beregninger (Vector, Matrix, …) eller billedbibliotek (jpeg eller png), der giver funktionaliteten til at skrive jpeg- eller png-billeder

I Unity 3D Matematik er en matematisk libray.

Teori: en libray giver dedikerede funktioner omkring et emne (f.eks. matematik ) OG kaldes af programmøren efter behov .

Noget eksempel: der kan være biblioteker med rammer, der også er et rammebibliotek.

---

Framework

Teori: En ramme introducerer en inversion af kontrol . Dette betyder, at udvikleren for det meste ikke kalder rammemetoderne, men rammen kalder udviklerkoden. Undtagelser er, når du skal integrere rammebiblioteket i din kode og skal starte rammen. Et rammebibliotek indeholder alle metoder og funktioner og grænseflader til en ramme med en dedikeret brug. Så rammer kan være i et bibliotek.

Typisk eksempel: Unity 3D MonoBehaviour giver metoder som Awake, Start, OnUpdate. Udvikleren implementerer disse metoder og derefter disse metoder kaldes af (game object management) -rammen (dette er inversionen af kontrol) . Det samme med metoderne OnCollisionEnter, OnCollisionExit. De er i samme Monobehaviour, men jeg vil vædde på, at de kaldes af fysikrammen.

---

En forhåndsvisning: Motor, Runtime, Editor, SDK

Da betegnelsen motor altid var en slags vag og stadig er (og det bliver ikke bedre med yderligere teknologisk udvikling), er der en forklaring på forhåndsvisning.

Udtrykket motor bruges til flere ting, og det kan ikke unikt siges, hvilken der er rigtig. Tilbage i 2004, da jeg først havde kontakt med at skrive spilmotorer, var det også vagt. Du havde en spilmotor i betydningen af en slags kode, der indlæste foruddefinerede data og lod dig spille spillet. Da det indlæser foruddefinerede data, blev de kaldt datadrevne motorer. Du kompilerer dem en gang, og de eksterne data kunne have været forskellige spil uden at kompilere dem igen. På et tidspunkt var dette det samme som en runtime.

Editoren er klar. Det giver dig mulighed for at definere de foruddefinerede data indlæst af motoren / runtime.

En motor med en editor blev kaldt SDK (f.eks. Hammer SDK).

Så var der / er dedikerede motorer. En phyiscs-motor, gengivelsesmotor, lydmotor, gameobject-styringsmotor, netværksmotor, ….

Efter min personlige mening er det ikke motorer (især en render-motor er IKKE en spilmotor, da den kun gengivelse). Når jeg googler spilmotorer, indeholder resultaterne 90% rene renderemotorer, som ikke er spilmotorer. Jeg vil kalde dem alle biblioteker, men da de muligvis indlæser foruddefinerede data, ville de matche begrebet datadrevet motor.

En sidste korte sidebemærkning, inden vi kommer ind i detaljerne: Jeg fik en kandidatgrad i computer videnskab. Min kandidatafhandling håndterede emnet “hvordan man udvikler kernen i en spilmotor”. Betydning af den del af koden, der viser alle de andre motorer, gør spillet objektadministration, spilsløjfen osv …

Jeg offentliggjorde min kandidatafhandling som en (kort) bog. Den eneste kommentar til Amazon fra en køber / læser er (efter et par år ude): dette handler ikke om en spilmotor. Siden jeg dimitterede med succes og derfor har forsvaret min afhandling mod 3 erfarne programmører (2 af dem dedikeret til spil og interaktive applikationer), tror jeg, jeg har skrevet en spilmotor.

---

Editor

Let: lader dig definere dataene i det format, som de andre dele kræver dem, og eliminerer derfor kravet om at skrive disse filer manuelt eller brug eksterne værktøjer til at oprette dem.

Dette er hvad Unity 3D-editoren gør.

---

Runtime

Dette udtryk bruges ofte til ligesom motor (hvilket kan være korrekt eller forkert).

Runtime udfører de genererede data og gør hvad det har at gøre med dataene. Vis f.eks. Spillet og lad dig spille spillet. Det opretter ikke nogen data (undtagen måske gemme spil) i den betydning, du ikke kan ændre selve spillet med det.

Unity Web Player er / var en runtime, hvor du kan spille Unity-spil i en webbrowser.

Du kan indlæse og udføre flere forskellige spil med samme kørselstid.

I tilfælde af Unity 3D scripting API er der en skære mellem funktionalitet, der fungerer i spillet og funktionalitet det fungerer kun i editoren.

---

SDK

Dette udtryk kaldes ofte også kaldet framework .

Dengang har en SDK været et bundt værktøj som en editor, IDE (integreret udviklermiljø) til programmører, eksportører til dataformater og runtime / engine.

Så en SDK / framework giver dig en foruddefineret arbejdsgang og hjælpeprogrammer og viser dig en (veldesignet) måde hvordan du (let) kan oprette et spil.

Grundlæggende ville Unity 3D-motor være forkert, da den ville passe mere ind i SDK-retningen. Men da Unity er endnu mere, er der behov for et nyt ord / en definition, der passer til, hvad det er.

Under alle omstændigheder giver en SDK / framework dig en foruddefineret spiludviklingspipeline (ikke kun et aktiv for at introducere det andet udtryk pipeline men måske ligesom Unity en pipeline for aktiver, logik, builds, implementeringer, ….)

---

Engine

sarkasme på Brugt til alt, da alle vil være seje ved ikke kun at skrive et bibliotek, en ramme eller et spil, men bedre at skrive en komplet motor. sarkasme fra

Lad os udløse det:

En motor

1. er et stykke kode / software
2. det sigter mod at blive genbrugt i flere projekter (du kan også skrive en spilmotor til kun ét spil)
3. for at blive genbrugt, skiller spilmotoren den genanvendelige del fra den spilspecifikke del
4. for at være genanvendelig (afhængigt af hvordan det er beregnet til at blive genbrugt) der er forskellige varianter som en datadrevet motor indlæsning af eksterne data

En motor kan bestå af flere motorer (da alt i dag kaldes en motor). En spilmotor kan omfatte

• en gengivelsesmotor, der gør gengivelsen (IGEN: gud, fanden, helvede: kode, der kun gengiver ER IKKE en spilmotor)
• en fysikmotor gør fysik (det er en fysikmotor, ikke en spilmotor)
• en AI-motor, der håndterer AI-tingene (det er en AI-motor og ikke en spilmotor)
• a netværksmotor (f.eks. RakNet), der laver netværksmaterialet (det er en netværksmotor, ikke en spilmotor)
• en lydmotor, der gør lydmaterialet (det er en lydmotor og ikke en spilmotor)

Et eksempel på en applikation baseret på en kernemotor, der giver en plug-in-baseret ramme til sammenkobling af alt sammen i en komponentbaseret spilobjektstyringsmodel. Hver undermotor (gengivelse af lyd) er et modul, der føjes til spilmotoren som plug-in. Hver komponent kan være en del af en undermotor / modul. Og den (komponentbaserede) spilobjektadministration er forbindelsesledet mellem de adskilte moduler.

---

Den nærmeste definiton til Game Engine

En spilmotor er den del af kildekoden i dit spil, at giver al den funktionalitet som er beregnet til at blive genbrugt på tværs af flere spil og lade dig kode og udføre dit spil. Derfor spor sammen alle de andre dele af koden (gengivelse, lyd, fysik, styring af spilobjekter, netværk), der er enten biblioteker, rammer eller dedikerede motorer (gengivelse, fysik, …).

Spilmotoren er rodet i midten.

---

Som @Josh allerede har sagt, er der ingen streng definition af ramme eller motor, men i en konceptuel forstand er begge meget forskellige værktøjer.

En ramme indeholder en grundlæggende API-abraktion at arbejde med, hvilket giver brugeren højere niveauværktøjer til at interagere med platformen eller funktionaliteten uden (generelt) at bekymre sig om ydeevne, kompatibilitet osv. I de eksempler, du gav, er SDL en ramme, det giver du fjerner funktionen over platformen, og du kan opbygge din software bag dette lag uden at bekymre dig om vinduesadministration, OS-specifikke ting osv. Hvis du vil opbygge en hel software, har du brug for forskellige rammer, fe SDL til styring af medier og platform ting, Box2D til styring af fysik osv.

En motor er anderledes, i dette tilfælde sender værktøjet alt, hvad der er nødvendigt for udviklingen, en fysikmotor giver dig med alt, hvad der er nødvendigt for at styre fysik, og vil sende en brugervenlig API, så hvis du vil opbygge en fysiksimulering, har du ikke brug for noget andet tredjepartsbibliotek. Motorer er ikke mere end en samling af rammer, andre motorer, grænseflader, uddrag og generel kode, der giver alt, hvad der er nødvendigt for at gennemføre projektet uden at have brug for andre tredjeparter eller bekymre sig om ting på lavere niveau.