Hva er forskjellen mellom et spillrammeverk og en spillmotor?

Det er egentlig ikke strenge definisjoner for «motor» eller «framework».

Generelt sett anses en motor for å «gjøre mer» eller har flere verktøy og relatert støtte enn et rammeverk, som i seg selv ofte bare er en løs samling av relatert funksjonalitet som er eksponert gjennom noen enhetlig API. hevder å være rammeverk for å oppnå funksjonalitet, men det trenger ikke alltid være tilfelle. På samme måte kan en ting som hevder å være en spillmotor hevde at den er de bestanddelene (fysikk og gjengivelse, osv.) er implementert med en fysikkmotor eller et fysikkrammeverk. Hvilken teknologi som begge begrepene refererer til, kan brukes om hverandre, eller ikke.

Det kan være «motorer» eller «rammer» for omtrent hva som helst – fysikk, lyd og ja, til og med 2D- eller 3D-grafikk.

Det er egentlig bare en terminologi problem, og det betyr generelt ikke mye. Fra et funksjonalitetsperspektiv, et perspektiv fokusert på å lage spillet ditt, det som betyr noe er om den aktuelle teknologien leverer det du trenger for å lage spillet ditt. Enten det kaller seg en motor eller et rammeverk, har det ingen betydning for det.

Enkel definisjon som jeg bruker : du kan bygge en motor på et rammeverk, men du vil aldri bygge et rammeverk på en motor. Det ene er skjelettet som bestemmer arkitektur og programflyt, det andre er muskler som gjør jobben.

For en betong for eksempel er Artemis et pent lite rammeverk for å bygge komponentsystemer, men du vil aldri kalle det en motor. Du kan bygge Artemis Systems og standardkomponenter for å lage en motor fra den.

Kommentarer

• I mitt selskap designet noen et rammeverk over motoren. dette rammeverket fungerer som en samling av manglende deler motoren ikke ‘ t gir, forener ting som ellers er litt rotete i vår (gamle) motor. Og gir hjelpere for å legge til rette for utvikling.

Et rammeverk er en samling av (vanligvis) lavere biblioteker og hjelper ting du kan bruke til å gjøre hva i helvete du vil (grafikk, lyder osv.). Det er ikke noe spillrelatert ved et rammeverk, bortsett fra at de vanligvis er optimalisert eller designet for å gjøre ting som er vanlige i spill.

Eksempel: En motor lar deg ha en liste over enheter, hver med en posisjon på kartet. Et rammeverk lar deg gjengi et 3d-objekt på en bestemt posisjon.

Så du kobler dem sammen ved å gi hver av enhetene dine et 3d-objekt, og gjengi dem når det er nødvendig.

Og ta-da, du har et spill.

For en veldig detaljert forklaring anbefaler jeg å lese den og eneste bibelen Game Engine Architecture av Jason Gregory. Jeg antar at det er det mest komplette arbeidet med dette emnet siden det ble publisert. Det håndterer ikke bare C ++ delen, men også og viktig for hver spillmotorprogrammerer teorien / arkitekturen bak. Det er et godt utgangspunkt uavhengig av språket. For å få en oversikt hva vi snakker om er dette bildet fra boka

La meg prøve å svare på spørsmålet.

Uansett hva du skriver vil det være kode 🙂 etter mange års erfaring, skriv hva du trenger og hvordan du trenger det, eller bruk det som gir deg det du trenger.

Begrepene motor og rammeverk kommer fra programvarearkitektur sammen med andre vilkår. Så la oss begynne med de grunnleggende begrepene og la oss bevege oss oppover.

---

Bibliotek

Typiske eksempler: et mattebibliotek som gir alle grunnleggende typer og funksjoner for matematiske beregninger (Vector, Matrix, …) eller et bildebibliotek (jpeg eller png) som gir funksjonaliteten for å skrive jpeg- eller png-bilder

I Unity 3D Matematikk er et matematisk bibliotek.

Teori: et bibliotek gir dedikerte funksjoner rundt et emne (f.eks. matematikk ) OG kalles av programmereren på forespørsel .

Noe forhåndsvisning: det kan være biblioteker som har rammeverk som et rammebibliotek.

---

Framework

Teori: Et rammeverk introduserer en inversjon av kontroll . Dette betyr at utvikleren mesteparten av tiden ikke kaller rammemetodene, men rammeverket kaller utviklerkoden. Unntak er når du må integrere rammebiblioteket i koden din og må starte rammeverket. Et rammebibliotek gir alle metoder og funksjoner og grensesnitt for et rammeverk med en dedikert bruk. Så rammer kan være i et bibliotek.

Typisk eksempel: Unity 3D MonoBehaviour gir metoder som Awake, Start, OnUpdate. Utvikleren implementerer disse metodene og deretter blir disse metodene kalt av rammen (game object management) (dette er inversjonen av kontroll) . Det samme med metodene OnCollisionEnter, OnCollisionExit. De er i samme monobehaviour, men jeg vil satse på at de blir kalt av fysikkrammeverket.

---

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

Siden begrepet motor alltid var litt vagt og fremdeles er (og det blir ikke bedre med videre teknologisk utvikling), er det noen forklaringer på forhåndsvisning.

Begrepet motor brukes til flere ting, og det kan ikke unikt sies hvilken som er riktig. Tilbake i 2004 da jeg først hadde kontakt med å skrive spillmotorer, var det også vagt. Du hadde en spillmotor i betydningen av en slags kode som lastet inn forhåndsdefinerte data og lot deg spille spillet. Siden den laster inn forhåndsdefinerte data, ble de kalt datadrevne motorer. Du kompilerer dem en gang, og de eksterne dataene kan ha vært forskjellige spill uten å kompilere det på nytt. På et tidspunkt var dette det samme som en kjøretid.

Redaktøren er klar. Den lar deg definere de forhåndsdefinerte dataene som er lastet inn av motoren / kjøretiden.

En motor med en editor ble kalt SDK (f.eks. Hammer SDK).

Så var det / er dedikerte motorer. En phyiscs-motor, gjengivelsesmotor, lydmotor, spillobjektstyringsmotor, nettverksmotor, ….

Etter min personlige mening er det ikke motorer (spesielt en render-motor er IKKE en spillmotor siden den bare gjengivelse). Når jeg googler spillmotorer inneholder resultatene 90% rene rendermotorer som ikke er spillmotorer. Jeg vil kalle dem alle biblioteker, men siden de kan laste inn forhåndsdefinerte data, vil de matche begrepet datadrevet motor.

En siste kort sidemerknad før vi kommer i detalj: Jeg ble vellykket utdannet med en mastergrad i informatikk. Masteroppgaven min håndterte temaet «hvordan utvikle kjernen i en spillmotor». Betydningen av den delen av koden som peker sammen alle de andre motorene, gjør spillet objektadministrasjon, spillsløyfen osv …

Jeg publiserte masteroppgaven min som en (kort) bok. Den eneste kommentaren til Amazon fra en kjøper / leser er (etter noen år ute): dette handler ikke om en spillmotor. Siden jeg ble uteksaminert med suksess og derfor har forsvart oppgaven min mot 3 erfarne programmerere (to av dem dedikert til spill og interaktive applikasjoner), antar jeg at jeg har skrevet en spillmotor.

---

Editor

Enkelt: lar deg definere dataene i formatet som de andre delene krever dem, og eliminerer derfor kravet om å skrive disse filene for hånd eller bruk eksterne verktøy for å lage dem.

Dette gjør Unity 3D-redigereren.

---

Runtime

Dette begrepet er ofte brukes likt med motor (som kan være riktig eller feil).

Kjøretiden kjører de genererte dataene og gjør det de har med dataene å gjøre. For eksempel vise deg spillet og la deg spille spillet. Det skaper ingen data (bortsett fra kanskje lagring av spill) i den betydningen at du ikke kan endre selve spillet med det.

Unity Web Player er / var en kjøretid som lar deg spille Unity-spill i en nettleser.

Du kan laste og utføre flere forskjellige spill med samme kjøretid.

I tilfelle av Unity 3D scripting API er det et kutt mellom funksjonalitet som vil fungere i spillet og funksjonalitet som bare fungerer i redigeringsprogrammet.

---

SDK

Dette begrepet kalles ofte også kalt framework .

Den gang har en SDK vært en gruppe verktøy som en editor, IDE (integrert utviklermiljø) for programmerere, eksportører for dataformater og kjøretid / motor.

Så et SDK / rammeverk gir deg en forhåndsdefinert arbeidsflyt og verktøy og viser deg en (godt designet) måte hvordan du (enkelt) kan lage et spill.

I utgangspunktet ville Unity 3D-motor være feil siden den ville passe mer inn i SDK-retningen. Men siden enhet er enda mer, er det nødvendig med et nytt ord / en definisjon for å matche hva det er.

Uansett, for å introdusere det andre begrepet, gir en SDK / ramme deg en forhåndsdefinert spillutviklingspipeline (ikke bare en ressurs pipeline men kanskje, som Unity, en pipeline for eiendeler, logikk, builds, distribusjoner, ….)

---

Engine

sarkasme på Brukes til alt siden alle vil være kule ved å ikke bare skrive et bibliotek, et rammeverk eller et spill, men bedre å skrive en komplett motor. sarkasme av

La oss utløse det:

En motor

1. er et stykke kode / programvare
2. det er rettet mot å bli gjenbrukt i flere prosjekter (du kan også skrive en spillmotor for bare ett spill)
3. for å bli gjenbrukt, skiller spillmotoren den gjenbrukbare delen fra den spillspesifikke delen
4. for å være gjenbrukbar (avhengig av hvordan Det er ment å bli gjenbrukt) det er forskjellige smaker som en datadrevet motor laster inn eksterne data

En motor kan bestå av flere motorer (siden alt kalles en motor i dag). En spillmotor kan inkludere

• en gjengemotor som gjør gjengivelsen (IGJEN: gud, jævla, helvete: kode som bare gjengir ER IKKE en spillmotor)
• en fysikkmotor gjør fysikk (det er en fysikkmotor, ikke en spillmotor)
• en AI-motor som håndterer AI-greiene (det er en AI-motor og ikke en spillmotor)
• a nettverksmotor (f.eks. RakNet) som gjør nettverks ting (det er en nettverksmotor, ikke en spillmotor)
• en lydmotor som gjør lyden ting (det er en lydmotor og ikke en spillmotor)

Et eksempel for en applikasjon basert på en kjernemotor som gir et plugin-basert rammeverk for å peke alt sammen i en komponentbasert spillobjektadministrasjonsmodell. Hver undermotor (gjengivelse av lyd) er en modul lagt til spillmotoren som plug-in. Hver komponent kan være en del av en undermotor / modul. Og den (komponentbaserte) spillobjektadministrasjonen er koblingsleddet mellom de separerte modulene.

---

Den nærmeste definisjonen for spillmotoren

En spillmotor er delen av kildekoden i spillet ditt at gir all funksjonaliteten som er ment å bli gjenbrukt på tvers av flere spill og lar deg kode og utføre spillet ditt. Derfor ledetråder sammen alle de andre delene av koden (gjengivelse, lyd, fysikk, spillobjektadministrasjon, nettverk) som er enten biblioteker, rammer eller dedikerte motorer (gjengivelse, fysikk, …).

Spillmotoren er rotet i midten.

---

Som @Josh allerede har uttalt, er det ingen streng definisjon av rammeverk eller motor, men i konseptuell forstand er begge veldig forskjellige verktøy.

Et rammeverk inneholder et grunnleggende API-abastrasjon å jobbe med, noe som gir brukeren verktøy på høyere nivå for å samhandle med plattformen eller funksjonaliteten uten (generelt) å bekymre seg for ytelse, kompatibilitet osv. I eksemplene du ga er SDL et rammeverk, det gir du avbryter funksjonen over plattformen, og du kan bygge programvaren din bak det laget uten å bekymre deg for vinduestyring, OS-spesifikke ting osv. Hvis du vil bygge en hel programvare, trenger du forskjellige rammer, fe SDL for å administrere media og plattforms ting, Box2D for å administrere fysikk osv.

En motor er annerledes, i dette tilfellet sender verktøyet alt som trengs for utviklingen, en fysikkmotor vil gi deg med alt som trengs for å administrere fysikk og vil levere et brukervennlig API, så hvis du vil bygge en fysikksimulering, trenger du ikke noe annet tredjepartsbibliotek. Motorer er ikke mer enn en samling rammer, andre motorer, grensesnitt, kodestykker og generell kode som gir alt som trengs for å fullføre prosjektet uten å trenge andre tredjeparter eller bekymre seg for ting på lavere nivå.