spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Hi,

dazu muss man ggf erstmal ein paar Grundbegriffe klären:

Bibliothek
Eine Sammlung von Routinen/Klassen die Funktionalität für ein unabhängiges Programm anbieten. Also ganz im Stil von CBS.

API
Eine API ist eine Programmierschnittstelle um externe Programmfunktionalität in ein Softwaresystem zu integrieren. Der allgemein bekannte Fall ist hier vermutlich die Schnittstelle zu Programm-/Klassenbibliotheken (z.B. in Form von DLLs). Allerdings ist der Begriff API noch etwas abstrakter zu sehen. Eine API kann z.B. auch Protokollorientiert sein um Zugriff auf die Funktionalität zu gewährleisten (z.B. per HTTP o.ä.).
Allgemein bekannte Beispiele von APIs sind u.A.: WinAPI, OpenGL, DirectX, SDL, ...

Framework
Ein Framework besteht aus einer Menge von zusammenarbeitenden Klassen die i.A. einen Entwurf speziell zugeschnitten auf bestimmten Typen von Software da, also z.B. Frameworks für CAD Anwendungen, ... Im Hinblick auf die Zielklassen unterscheidet man hier zwischen horizontanlen- und vertikalen Frameworks.
Wichtig ist allerdings das Frameworks die Architektur der Anwendung i.d.R stark beeinflussen (sogar vorgeben) und den Kontrollfluss der Anwendung definieren; d.h. als Entwickler kümmert man sich nicht mehr um rudimentäre Dinge sondern um spezifische Details.
Was heißt das also? Bei Verwendung eines Frameworks führt das zum Inversion of control, das Framework definiert also den großen Hauptteil des Kontrollflusses, die Anwendung legt lediglich den Code fest der vom Framework aufgerufen wird (siehe im Gegensatz dazu die Anwendung von Programmbibliotheken/Klassenbibliotheken).

Die Kerneigenschaften von Frameworks sind

• Wiederverwendbarkeit
• Flexibilität und anwendungsspezifische Erweiterungsmöglichkeit

Man unterscheidet ferner zwischen white-box- und black-box-Frameworks. Erstere werden angepasst durch Vererbung, oder Implementierung von abstrakten Klassen. Im Allgemeinen sind bei der Verwendung von white-box-Frameworks die Internas klar. Im Gegensatz zu black-box-Frameworks wo man sich eher auf Komposition stützt.

Eine Engine kann sowohl als Framework oder API angeboten werden (oder sogar dazwischen angesiedelt sein). Viele opensource Grafik-Engines fallen z.B. unter den Begriff API, also z.B. Irrlicht, Ogre, ... (wobei man an dieser Stelle noch differenzieren muss zwischen lowlevel-, und highlevel API) obwohl mit den Begriff Engine eher Frameworkeigenschaften mitschwingen.

So, hier noch einige wiki-Links zum Thema:
Programlibrary
API
Framework
Spiele-Engine

Meiner Meinung nach gibt es keine feste Definition für Engines im Computerbereich. Du kannst genauso eine Parser Engine haben oder im klassischem Sinne eine Game Engine. Ich finde es meistens am besten, wenn man das Wort einfach übersetzt. "Motor" und so verhält es sich auch, es gibt einfach keine feste Definition. Aber sie sollte eine gute Basis für ein Projekt bieten und auch in anderen Projekten sollte man sie einsetzen können.

Eine Engine ist praktisch das, was ein Spiel antreibt. Sie stellt Funktionen für bestimmte Bereiche zur Verfügung und erspart einem, direkt mit einer API zu programmieren. Engine bedeutet auch noch das Zusammenspiel von unterschiedlichen Komponenten zu perfektionieren. Viele kleine Zahnräder müssen miteinander kooperieren. Das ist ganz wichtig.

Achtung, nur ein kleiner Überblick mit wenig Inhalt, da fehlen durchaus noch Module .Hier mal die Struktur unserer Engine:

Engine ->

LibApplications:
Stellt grundlegende Funktionen für den Start und die Verwaltung von
Applikationen bereit( Konsole, Window )

LibCore:
Praktisch die Innerein der Engine. Hier wird gaaaanz viel Mathe-Kram
erledigt und die Basis-Funktionen des OS werden gekapselt.
( FileIO, Debugging, Logging, Math, Curves, Languages, Scripts, Memory,
Streaming )

LibGraphics:
Das Herz der Engine. Stellt die grafischen Funktionen bereit.
Abstrakt gehalten.Renderer für OpenGL3 und D3D9/D3D11.
Besonderes Augenmerk auf Material-System und Scenegraph.

LibGameFoundation:
Ab hier fängt eigentlich erst die Game Engine an.
Bis jetzt war das alles eigentlich nur eine Grafik-Engine.
Hier werden Dinge wie State Machines oder Entities
implementiert.

Wie du siehst sind es einfach mehrere Module, die aufeinander aufbauen oder die miteinander vernetzt sind.

Dann gibt es noch weitere Parts aus denen Game Engines bestehen können. Man sollte immer strikt zwischen einer 3D-Engine( wie OGRE ) und einer Game Engine( wie Unity )
unterscheiden. Eine GameEngine könnte dann noch aus Sound, Networking und millionen von anderen Modulen bestehen.

Man kann Engines nicht einfach entwickeln, jedenfalls nicht im großem Maßstab. Das dauert Jahre und braucht sehr viel Erfahrung, die du anscheinend noch nicht hast. Ich empfehle dir entweder etwas wie Batzer hier im Forum zu machen oder eine bestehende Game Engine wie Unity zu nutzen. Batzer hat eine riesige Lernkurve und lernt auch sehr viel über Software-Architektur.

Engine sind hochkomplexe Software-Gebilde. Sie können aus mehreren dutzend Modulen bestehen und ein 25 Mann Team über 3 Jahre beschäftigen( CryENGINE 3 ). Es werden Bücher damit gefüllt, die sich nur mit einer Game-Engine Architektur beschäftigen.
In diesem Segment gibt es meiner Meinung nach 3 sehr gute Bücher:

* Game Engine Architecture:
Beschäftigt sich mit den vielen SubSystems einer Engine.
In meinem Beispiel wäre das dann alles über dem
Grafik-Modul. In diesem Buch gibt es viele gute Beispiele
anhand von OGRE und der Naughty Dog in-house Engine.
Der Autor arbeitet bei Naughty Dog.Auch ein sehr
nettes Kapitel über Animationen.

* Game Engine Design:
Achtung, sehr viel Mathematik gibt es in diesem Buch, ist ja auch
klar, denn es wurde von einem Mathematiker geschrieben. Auch
ein sehr tolles Buch, das sich auch viel mit den Renderern und
allgemein dem Grafik-Modulen beschäftigt.

*Game Coding Complete:
Hier werden viele Sachen besprochen, die in anderen Büchern
eigentlich selten besprochen werden. Hier wird sehr
viel über SubSystems geredet.

Das sind meiner Meinung nach die wichtigsten Bücher in diesem Segment. Zusätzlich brauch man dann noch sehr gute C++-Kenntnisse, Assembler kann auch helfen und man muss unbedingt eine API( D3D oder GL ) sehr gut können. Man muss bereits bei der Planung wissen, wo es Probleme geben kann und wo man es noch besser machen kann.

Ich empfehle dir, es so wie Batzer zu machen. Oder eben Unity/OGRE, aber nicht selberschreiben. Make games, not engines!

Okay. Da war ich wohl zu langsam. @Thread-Starter: David_pbs Post ist einfacher zu verstehen, richte dich lieber nach seinem.

Zitat von »Mastermind«

Deja vu?

Ah ja:

Begrifflichkeiten

Ja, das Thema ist ja auch nich ganz so trivial! In dem alten Thread werden die Begriffe aber z.T. leider falsch dargestellt bzw weiter vermischt...

Ich würde gerne noch einen Aspekt erwähnen und zwar die Tools, die zu einer Engine gehören.
Sowas wie ein Level-Editor oder Content-Editor.
Wer möchte denn heutzutage noch Quests mit einem simplen Text-Editor erstellen ?

Bei der CryEngine oder UnrealEngine sind die entsprechenden Tools gleich mit dabei.

Die entsprechenden Tools zu entwickeln, zu testen und nutzbar zu machen nimmt mindestens genauso viel Zeit in Anspruch, wie die Engine selbst zu programmieren.

Danke erst mal an SupremeDeveloper, ich fühl mich richtig geehrt
Aber mache ich nicht auch eher ne Art Engine?

@FalkT
Ich denke nicht, dass die Tools unbedinkt notwendig sind für eine Engine.
Sie vereinfachen nur die Dinge um ein vielfaches.
Und ich glaube, dass bei der UnrealEngine der Editor die ganze Engine ist.
Mit C++ ist da nichts, nur mit UnrealScript im Editor selbst.

Zitat von ».:!Batzer!:.«

Danke erst mal an SupremeDeveloper, ich fühl mich richtig geehrt
Aber mache ich nicht auch eher ne Art Engine?

@FalkT
Ich denke nicht, dass die Tools unbedinkt notwendig sind für eine Engine.
Sie vereinfachen nur die Dinge um ein vielfaches.
Und ich glaube, dass bei der UnrealEngine der Editor die ganze Engine ist.
Mit C++ ist da nichts, nur mit UnrealScript im Editor selbst.

Für mich sah das die ganze Zeit noch nicht so gewaltig aus.

@UnrealEngine: Nope, das ist nur bei der UDK so.

kleine Anmerkung: Eine funktionierende Toolchain wird von den meisten (Hobby?)Programmierern deutlich unterschätzt, aber im Endeffekt ist gerade diese nach meiner Erfahrung für das Vorankommen entscheidend.