Wat is het verschil tussen een gameframework en een game-engine?

Er zijn echt geen “strikte definities voor” engine “of” framework “.

Over het algemeen wordt een engine beschouwd als” meer doen ” of meer tools en gerelateerde ondersteuning hebben dan een raamwerk, dat zelf vaak slechts een losse verzameling gerelateerde functionaliteit is die via een uniforme API wordt getoond.

Daartoe kunnen dingen die beweren engines te zijn, dingen gebruiken die beweren frameworks te zijn om functionaliteit te bereiken, maar dat hoeft niet altijd het geval te zijn. Evenzo kan iets dat beweert een game-engine te zijn, beweren dat de samenstellende delen (de fysica en weergave, enzovoort) zijn geïmplementeerd met een physics engine of een physics framework. De soorten technologie waarnaar beide termen verwijzen, kunnen door elkaar worden gebruikt of niet.

Er kunnen “engines” of “frameworks” zijn voor zo ongeveer alles: natuurkunde, geluid en ja, zelfs 2D- of 3D-afbeeldingen.

Het is eigenlijk maar een terminologie probleem, en het maakt over het algemeen niet zoveel uit. Vanuit een functionaliteitsperspectief, een perspectief gericht op het maken van je game, moet het erom gaan of de technologie in kwestie levert wat je nodig hebt om je game te maken. Of het zichzelf nu een engine of een framework noemt, heeft daar geen invloed op.

Simpele definitie die ik gebruik : je kunt een motor bouwen op een raamwerk, maar je zou nooit een raamwerk op een motor bouwen. Het ene is het skelet dat de architectuur en de programmastroom bepaalt, het andere is de spier die het werk doet.

Voor een concrete Artemis is bijvoorbeeld een leuk klein raamwerk voor het bouwen van componentensystemen, maar je zou het nooit een motor noemen. Je zou Artemis-systemen en standaardcomponenten kunnen bouwen om er een engine van te maken.

Opmerkingen

• In mijn bedrijf ontwierp iemand een raamwerk over de engine. dit framework dient als een verzameling van ontbrekende onderdelen die de engine niet ‘ levert, verenigt dingen die anders een beetje rommelig zijn in onze (oude) engine. En biedt helpers om de ontwikkeling te vergemakkelijken.

Een framework is een verzameling van (meestal) bibliotheken op een lager niveau en hulpdingen die u kunt gebruiken om te doen wat u maar wilt (afbeeldingen, geluiden, enz.). Er is niets game-gerelateerd aan een framework, behalve dat ze meestal zijn geoptimaliseerd of ontworpen om dingen te doen die gebruikelijk zijn in games.

Voorbeeld: een engine stelt je in staat om een lijst met entiteiten te hebben, elk met een positie op de kaart. Een raamwerk stelt je in staat een 3D-object op een bepaalde positie weer te geven.

Dus je verbindt ze door elk van je entiteiten een 3D-object te geven, en render ze wanneer nodig.

En ta-da, je hebt een spel.

Voor een echt gedetailleerde uitleg raad ik aan het spel te lezen en enige bijbel Game Engine Architecture door Jason Gregory. Ik denk dat dit het meest complete werk over dit onderwerp is sinds het werd gepubliceerd. Het behandelt niet alleen het C ++ -gedeelte, maar ook en belangrijk voor elke game engine programmeur de theorie / architectuur erachter. Het is een goed startpunt onafhankelijk van de taal. Om een overzicht te krijgen waar we het over hebben is deze afbeelding uit het boek

Laat me eens proberen om de vraag te beantwoorden.

Wat je ook schrijft, het zal code zijn 🙂 schrijf na jarenlange ervaring op wat je nodig hebt en hoe je het nodig hebt, of gebruik wat je geeft wat je nodig hebt.

De termen engine en framework komen van softwarearchitectuur samen met andere termen. Dus laten we beginnen met de basistermen en naar boven gaan.

---

Bibliotheek

Typische voorbeelden: een wiskundige bibliotheek met alle basistypen en functies voor wiskundige berekeningen (Vector, Matrix, …) of afbeeldingsbibliotheek (jpeg of png) die de functionaliteit biedt voor het schrijven van jpeg- of png-afbeeldingen

In Unity 3D Math is een wiskundige libray.

Theorie: een libray biedt speciale functies rond een onderwerp (bijv. wiskunde ) EN wordt door de programmeur op aanvraag aangeroepen .

Een voorbeeld: er kunnen bibliotheken zijn met frameworks oftewel een frameworkbibliotheek.

---

Framework

Theorie: een raamwerk introduceert een inversie van controle . Dit betekent dat de ontwikkelaar meestal niet de framework-methoden aanroept, maar het framework de code van de ontwikkelaar aanroept. Uitzonderingen zijn wanneer u de framework-bibliotheek in uw code moet integreren en het framework moet starten. Een raamwerkbibliotheek biedt alle methoden en functies en interfaces voor een raamwerk met een specifiek gebruik. Frameworks kunnen dus in een bibliotheek staan.

Typisch voorbeeld: The Unity 3D MonoBehaviour biedt methoden zoals Awake, Start, OnUpdate. De ontwikkelaar implementeert deze methoden en vervolgens worden deze methoden aangeroepen door het framework (game-objectbeheer) (dit is de inversie van de besturing) . Hetzelfde met de methoden OnCollisionEnter, OnCollisionExit. Ze zijn in hetzelfde Monobehaviour, maar ik durf te wedden dat ze worden aangeroepen door het physics-framework.

---

Een voorbeeld: Engine, Runtime, Editor, SDK

Aangezien de term engine altijd een beetje vaag was en nog steeds (en het wordt niet beter met verdere technologische ontwikkelingen) een voorbeeldverklaring is.

De term engine wordt voor meerdere dingen gebruikt en het kan niet eenduidig worden gezegd welke de juiste is. In 2004, toen ik voor het eerst contact had met het schrijven van game-engines, was het ook vaag. Je had een game-engine in de betekenis van een soort code die vooraf gedefinieerde gegevens laadde en je het spel liet spelen. Omdat het vooraf gedefinieerde gegevens laadt, werden ze datagestuurde engines genoemd. Je compileert ze één keer en de externe gegevens hadden verschillende spellen kunnen zijn zonder ze opnieuw te compileren. Op een bepaald moment was dit hetzelfde als een runtime.

De editor is duidelijk. Het laat je de voorgedefinieerde data definiëren die door de engine / runtime worden geladen.

Een engine met een editor heette SDK (bijv. Hammer SDK).

Toen waren / zijn er speciale engines. Een phyiscs-engine, rendering-engine, sound-engine, gameobject-management-engine, netwerk-engine, …

Naar mijn persoonlijke mening zijn dat geen engines (vooral een render-engine IS GEEN game-engine, aangezien het alleen weergave). Wanneer ik de game-engine google, bevatten de resultaten 90% pure render-engines die geen game-engines zijn. Ik zou ze allemaal bibliotheken noemen, maar omdat ze vooraf gedefinieerde gegevens kunnen laden, komen ze overeen met de term datagestuurde engine.

Een laatste korte kanttekening voordat we in details treden: ik ben met succes afgestudeerd met een masterdiploma in computertechnologie. Mijn masterscriptie behandelde het onderwerp “hoe de kern van een game-engine te ontwikkelen”. Dit betekent het deel van de code dat alle andere engines samenbrengt, het beheer van de game-objecten, de game-loop, enz …

Ik heb mijn masterproef gepubliceerd als een (kort) boek. De enige opmerking over Amazon van een koper / lezer is (na een paar jaar uit): dit gaat niet over een game-engine. Sinds ik succesvol ben afgestudeerd en daarom mijn scriptie heb verdedigd tegen 3 ervaren programmeurs (waarvan 2 toegewijd aan games en interactieve applicaties), denk ik dat ik een game-engine heb geschreven.

---

Editor

Eenvoudig: laat je de gegevens definiëren in het formaat dat de andere delen nodig hebben en elimineert daarom de vraag om die bestanden te schrijven met de hand of gebruik externe tools om ze te maken.

Dit is wat de Unity 3D-editor doet.

---

Runtime

Deze term wordt vaak op dezelfde manier gebruikt als engine (wat correct of incorrect kan zijn).

De runtime voert de gegenereerde data uit en doet wat het met de data te maken heeft. Laat je bijvoorbeeld het spel zien en laat je het spel spelen. Het creëert geen gegevens (behalve misschien games opslaan) in de zin dat je “het spel zelf er niet mee kunt wijzigen.

De Unity Web Player is / was een runtime waarmee je Unity-spellen kunt spelen binnen een webbrowser.

Je kunt meerdere verschillende spellen laden en uitvoeren met dezelfde runtime.

In het geval van de Unity 3D-scripting-API is er een scheiding tussen functionaliteit die in het spel werkt en functionaliteit dat werkt alleen binnen de editor.

---

SDK

Deze term wordt vaak ook wel framework genoemd.

Destijds was een SDK een bundel tools zoals een editor, IDE (Integrated Developer Environment) voor programmeurs, exporteurs voor dataformats en de runtime / engine.

Dus een SDK / framework biedt je een voorgedefinieerde workflow en hulpprogrammas en toont je een (goed ontworpen) manier hoe je (gemakkelijk) een game kunt maken.

In wezen zou de Unity 3D-engine verkeerd zijn omdat deze meer in de SDK-richting zou passen. Maar aangezien Unity nog meer is, is er een nieuw woord / definitie nodig die overeenkomt met wat het is.

Hoe dan ook, om de andere term te introduceren, biedt een SDK / framework u een vooraf gedefinieerde pijplijn voor game-ontwikkeling (niet alleen een pluspunt). pijplijn maar misschien, net als Unity, een pijplijn voor activa, logica, builds, implementaties, ….)

---

Engine

sarcasme op Wordt voor alles gebruikt omdat iedereen cool wil zijn door niet alleen een bibliotheek, een framework of een spel te schrijven, maar beter een complete engine te schrijven. sarcasme uit

Laten we het in gang zetten:

Een engine

1. is een stukje code / software
2. het is bedoeld om in meerdere projecten (je kunt ook een game-engine schrijven voor slechts één game)
3. om hergebruikt te worden, scheidt de game-engine het herbruikbare deel van het spelspecifieke deel
4. omdat het herbruikbaar is (afhankelijk van hoe het is bedoeld om te worden hergebruikt) zijn er verschillende smaken, zoals een datagestuurde engine externe gegevens laden

Een engine kan uit meerdere andere engines bestaan (aangezien alles tegenwoordig een engine wordt genoemd). Een game-engine kan

• een render-engine bevatten die het renderen doet (AGAIN: god, damn, hell: code doet alleen rendering IS GEEN game-engine)
• een physics-engine de fysica doen (het is een fysica-engine, geen game-engine)
• een AI-engine die de AI-dingen afhandelt (het is een AI-engine en geen game-engine)
• een netwerkengine (bijv. RakNet) die het netwerk doet (het is een netwerkengine, geen game-engine)
• een audio-engine die de audio doet (het is een audio-engine en geen game-engine)

Een voorbeeld voor een applicatie die is gebaseerd op een kernengine die een op plug-ins gebaseerd raamwerk biedt om alles samen te brengen in een op componenten gebaseerd spelobjectbeheermodel. Elke subengine (rendering audio) is een module die als plug-in aan de game-engine is toegevoegd. Elke component kan deel uitmaken van een subengine / module. En het (op componenten gebaseerde) spelobjectbeheer is de verbindende schakel tussen de gescheiden modules.

---

De dichtstbijzijnde definitie voor Game Engine

Een game-engine is het deel van de broncode van uw game die alle functionaliteit biedt, namelijk bedoeld om opnieuw te gebruiken in meerdere games en je te laten coderen en uw spel. Daarom geeft samen alle andere delen van de code (weergave, audio, fysica, spelobjectbeheer, netwerken) die zijn ofwel bibliotheken, frameworks of speciale engines (rendering, physics, …).

De game-engine is de puinhoop in het midden.

---

Zoals @Josh al zei, is er geen strikte definitie van framework of engine, maar in conceptuele zin zijn het beide heel verschillende tools.

Een framework bevat een basis API-abastractie om mee te werken, waardoor de gebruiker tools op een hoger niveau krijgt om te communiceren met het platform of de functionaliteit zonder zich (algemeen) zorgen te maken over prestaties, compatibiliteit, enz. In de voorbeelden die je gaf, is SDL een framework, het geeft je staart over het platform, en je kunt je software achter die laag bouwen zonder je zorgen te maken over vensterbeheer, OS-specifieke dingen, enz. Als je een hele software wilt bouwen, heb je verschillende frameworks, zoals SDL om de media en platformdingen te beheren, Box2D om de fysica te beheren, enz.

Een engine is anders, in dit geval levert de tool alles wat nodig is voor de ontwikkeling, een physics-engine levert je met alles wat nodig is om de fysica te beheren en zal een gebruiksvriendelijke API leveren, dus als je een fysica-simulatie wilt bouwen, heb je geen andere bibliotheek van derden nodig. Engines zijn niet meer dan een verzameling frameworks, andere engines, interfaces, fragmenten en algemene code die alles bieden wat nodig is om het project te voltooien zonder andere derde partijen nodig te hebben of zich zorgen te maken over dingen op een lager niveau.