spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Eine Engine hat nichts mit Klickibunti zu tun und man muss sehr wohl Programmieren können, um mit einer ein Spiel zu kreieren (oder zumindest einer im Team).
Nichts mit Baukasten und alles wird schön. Schau dir mal die Unity Engine an.

Professionell erklären kann ich es nicht, ich arbeite auch nicht mit Engines.

Zitat von »GamerXpension«

Eine Engine hat nichts mit Klickibunti zu tun und man muss sehr wohl Programmieren können, um mit einer ein Spiel zu kreieren (oder zumindest einer im Team).
Nichts mit Baukasten und alles wird schön. Schau dir mal die Unity Engine an.

Um's mal anders zu formulieren: Doch, es gibt Engines die wie klickibunti funktionieren und Unity ist eine davon. Vom Prinzip her ist eine Engine das, was das Spiel unter der Motorhaube antreibt. Sie kümmert sich um Ressourcen, wie sie geladen und verwaltet und freigegeben werden, wie die Ressourcen dargestellt oder abgespielt werden. Sie bietet eben Schnittstellen für eigene Modelle und Texturen und stellt jede Menge Zeug bereit, welches diese dann anzeigen und animieren, meist ohne allzugroßen Aufwand durch den Benutzer. Zumindest deutlich weniger, als wenn er sich selbst damit abquälen würde dafür zu sorgen, dass seine Daten irgendwie auf die Grafikkarte kommen, richtig aussehen und sich korrekt bewegen.
Engines gibt es dabei in diversen Abstufungen. Von einfachen Frameworks, die nur die grundlegenden Dinge kapseln bis hin eben zu klickibunti-Oberflächen wie Unity. Unreal bietet auch ziemlich viel Oberfläche zum einfachen "zusammenstecken" seiner Komponenten.

Eine engine ist eine, in Umfang und Spezialisierung variable, Funktions- und Werkezugsammlung für:
- Ai
- rendering, shading, sound
- scripting
- physik
- tools

Um es mal kurz und bündig zusammen zu fassen

Zitat von »BlueCobold«

Doch, es gibt Engines die wie klickibunti funktionieren und Unity ist eine davon.

Selbst in Unity kommt man ohne Scripts nicht weit. Sobald ein Feature etwas spezieller ist als "laufe vorwärts", benötigt man Programmierkenntnisse und/oder viel Geld für den Assetstore.

Das mag wohl sein. Geld erfordert aber keine Kenntnisse und eben weil Unity so klickibunti ist, glauben viele nach 20 Minuten, dass man damit ein neues MMO Zombie Survival Open World zusammen klicken könnte. Ändert aber nichts daran, dass Unity schon das GUI-lastige Ende der Liste von Engines darstellt.

Ich wüsste nicht, in wie weit sich das vom UDK/der Unreal Engine abhebt, bei der man mit Hilfe von Kismet ohne Programmiererfahrungen bereits ganze Spiele zusammenklicken kann...

Ansonsten haben BlueCobold und iSmokiieZz schon gute Zusammenfassungen geliefert.
Wichtig zu bedenken ist aber, dass das Game Engines sind, die beschrieben wurden. Es gibt auch Engines, die ganz spezielle Aufgaben übernehmen, wie Physik Engines (Box2D, PhysX, Havok, Bullet, ...), Rendering Engines (Orge, Irlicht, ...), JavaScript Engines (V8, Spidermonkey, Chakra, ...) usw.
Game Engines implementieren i. d. R. nicht alle Funktionalitäten gänzlich selbst sodass für die Physik in Spielen immer wieder die gleichen Physik-Engines zum Einsatz kommen, auch wenn unterschiedliche oder keine Game Engines verwendet werden.

Zitat von »Sacaldur«

Ich wüsste nicht, in wie weit sich das vom UDK/der Unreal Engine abhebt, bei der man mit Hilfe von Kismet ohne Programmiererfahrungen bereits ganze Spiele zusammenklicken kann...

Das Blueprintsystem von Unreal sieht dann zwar wie "zusammenklicken" aus, bringt einem aber nichts, wenn kein Verständnis für die typischen Vorgänge in einem Programm hat. Man kommt am Scripten (lernen) nicht vorbei. Ob man das nun visuell oder mit Quelltext macht ist eigentlich egal.