Die Qual der Wahl... Engines vs. Frameworks

Dec 17, 2014 at 11:19 AM
Aus den Diskussionen der vergangenen Tage ist für mich eines klar geworden: Unter uns "Followern" gibt es mind. zwei Fraktionen: Die einen freuen sich darüber, vieles über die Basics der Spiele-Entwicklung zu lernen, die anderen freuen sich auf die Aussicht darauf, möglichst schnell ein eigenen Spiel selbst zu entwickeln.

Natürlich denken auch die Fans der Basics-Fraktion auch daran, letztlich ein Spiel zu entwickeln. :) Dennoch ist der Fokus jeweils ein anderer.

Tom hat beispielsweise bei Null begonnen (im wahrsten Sinne des Wortes). Bei ihm gab es zunächst keine "GameLoop". Selbst die Vektoren hat er selbst konstruiert. Sehr geil! Und schon kamen einige, die fragten, warum man denn nicht einfach Unity nutzen würde wie alle anderen.

Und da geht's halt los:
Wenn das Spiel später eine ansprechende Optik haben soll und mehr als nur einen Sound gleichzeitig abspielen können, dann kommt man nicht drum herum, entweder so richtig krass in die Tasten zu hauen, oder sich zu überlegen, ob man eventuell das bereits tausendfach erfundene Rad nutzt, statt ein neues zu erdenken.

Aus meiner Sicht sind Frameworks mehr Sammlungen an Bibliotheken, die einem spezifische Eigenheiten einer Zielplattform in der Entwickler einfacher zugänglich machen. So ist DirectX beispielsweise in sofern ein Framework, als dass ich mir über den direkten Grafikkartenzugriff keine Gedanken mehr machen muss und neben Sound, Netzwerk und Eingabethemen auch jede Menge Utility- und Helper Klassen existieren.

Eine GameEngine geht noch einen Schritt weiter. Das Framework könnte noch für alles mögliche eingesetzt werden (wie z.B. DirectX als Unterbau für WPF und damit auch für Business Applikationen). Die GameEngine reduziert den Einsatz nun aber wirklich auch das, worum es vor allem uns geht: Game Development. Sprich, hier sind meist Level-Editor, Asset-Management, Scene-Editor, Effect-Sampler und dergleichen mehr integriert. Unity ist so eine Engine.

Bei OctoAwesome finde ich persönlich besonders geil, dass wir die Basics zu Gesicht bekommen. Also all das, was eine GameEngine schonmal komplett wegkapselt... aber auch ein Framework größtenteils hinter bereits wohldurchdachten Architekturen verbirgt.

Dennoch: Auch hier kommen wir an einen Punkt, an dem ein Vorankommen nur noch seeeeehr langsam möglich ist, wenn wir die Kernkonzepte hinter bereits vorhandenen Frameworks neu erfinden müssten. Dann kann man nicht mehr mal eben in zwei oder drei Folgen einen Level-Editor bauen... von 3D ganz zu schweigen. :)

Also muss eine 3rd Party Abhängigkeit her.

Tom hat in dem Live Cast bereits erklärt, er würde OpenTK bevorzugen. Ich persönlich bin da kein so großer Fan von, gebe aber zu, dass das reine Geschmacksfrage ist. Ich würde mich riesig über XNA freuen.. wäre XNA nicht tot. Vor ein paar Tagen allerdings bin ich über MonoGame gestolpert und habe festgestellt, dass es - sofern man die Developer Version runterlädt - sogar verschiedene Content Prozessoren nebst einer entsprechenden Pipeline inkl. Builder mitbringt. Das macht den Umgang mit Assets total einfach: Einfach im Builder neue Dateien hinzufügen (z.B. Texturen, Fonts, etc.), Processor auswählen, bauen, das Ergebnis (.xnb) in das Projekt einbinden und ganz einfach darauf zugreifen.

Nunja... genau wie in XNA halt. Denn nichts anderes versucht MonoGame: XNA zu kopieren. :) Der wesentliche Unterschied: MonoGame ist aktuell und wird auch weiterentwickelt.

Es gibt da draußen aber so viele andere Möglichkeiten... doch XNA? Oder ANX? Oder wirklich OpenTK? Direkt OpenGL ohne irgendwelche Wrapper? DirectX (und dann nativ mit c++)? SharpDX? SlimDX?

Während ich selbst gerade mit MonoGame herumexperimentiere, steht immerhin eines fest: Ich möchte ein Framework nutzen, keine GameEngine. Ich habe zwar auch eine Pro Lizenz von GameMaker... aber ehrlich gesagt... das Produkt haut mich so gar nicht vom Hocker.

Wie steht es mit euch? Folgt ihr dem Pfad 1:1? Lauft ihr nebenher und nutzt in euren eigenen Projekten sogar andere Frameworks (bzw. plant es, so zu handhaben)? Habt ihr Erfahrungen mit irgendwelchen Frameworks... vielleicht sogar mit den hier genannten?

Mich interessiert eure Meinung.

Was OctoAwesome betrifft, freue ich mich schon auf die Fortsetzung im neuen Jahr und Toms Ideen... und die Wege, die er zur Realisierung einschlägt. :)

// Christian
Developer
Dec 17, 2014 at 7:23 PM
Guten Abend Christian

um gleich zur Sache zu kommen ich kann dir nur recht geben. Ich finde auch man muss nicht jedes mal das Rad neu erfinden, also sollten Frameworks schon verwendet werden dürfen, was engines angeht, finde ich es schwierig, bei einem Projekt wie OctoAwesome, auf eine quasi fertige Schnittstelle zu setzen, da ja das lernen und das erstellen von eigenen "engines" im Vordergrund stehen sollte, eben an einem konkreten Projekt...

Ich finde auch du sprichst gleich in den ersten 3 Zeilen ein großes Thema an, die Zwei Fraktionen. Und das wird sicherlich auch der Ausschlag gebende Punkt werden, wie ausführlich das Let's Code werden wird und ob man auf Frameworks und engines zurückgreifen muss...

Ich gebe aber mal hier zu bedenken, das ein Spiel, das dem Nutzer ermöglichen soll, live Code mit ein zu bringen, sich sicherlich viel schwerer gestallten lässt mit einer engine wie z.b. Unity, wenn es nicht sogar ganz unmöglich ist. Und das wiederum finde ich wirklich einen der wichtigsten Kernpunkte, den "AntMe-Gedanken" mit ein zu bringen.

Gruß PatteKi
Coordinator
Dec 18, 2014 at 7:23 AM
Moin moin Freunde,

oh ja. diese beiden Lager gibt es immer :) Aber da kann ich eigentlich nur sagen: Es ist ein Lets Code, kein Art-Workshop. Das hat einen einfachen Grund: Ich bin Coder und verstehe nicht viel vom stilvollen Entwurf eines 3D-Modells. Natürlich rate ich jedem, der effizient und schnell ein Spiel machen will, auf fertige Engines zurück zu greifen. Schließlich will man sich auf die Alleinstellungsmerkmale Game Design und Aufmachung kümmern. Dennoch bin ich persönlich ein großer Verfechter der Theorie, dass man, auch wenn man fertige Sachen verwendet, wissen sollte, was die Maschine darunter tut.

Ich selbst habe ich zu meiner Anfangszeit durch unzählige schlechte Tutorials, schwache Dokumentation und Büchern gequält, die von begnadeten Programmierern, aber gleichzeitig schlechten Autoren erstellt wurden. Ich bin dennoch froh das gemacht zu haben, weil es einen einfach weiter bringt.

Mit dem Lets Code will ich meine Erkenntnisse auf unterhaltsame und verständliche Weise übermitteln. Das mag zwar manchmal etwas umständlich erscheinen, verpackt aber meist einen dieser vielen Aha-Momente meines bisherigen Lebens ;) In dem Moment, wo ich aber selbst auf Dinge stoße, mit denen ich noch nie gearbeitet habe, fällt es mir schwer da solides Wissen zu vermitteln.

Lange rede, kurzer Sinn: Ich bin Techniker, weshalb das Lets Code immer einen Coder-Schwerpunkt haben wird. Zeugs in Unity zu skripten ist nicht ganz das, was ich mir darunter vorstelle. Und was die Wahl des Grafik-Frameworks angeht wäre ich auch großer XNA-Verteidiger - alleine schon wegen dem unkomplizierten Umgang mit Ressourcen. Dank Abkündigung wollte ich mal was anderes versuchen (daher mein OpenGL Vorschlag). Allerdings sieht MonoGame tatsächlich recht vielversprechend aus...

Cheers
Tom
Dec 21, 2014 at 10:23 AM
Moin Zusammen,

da in dem anderen Thread keiner reagiert hat, möchte zum Thema Grafik Framework noch mal kurz OGRE (http://www.ogre3d.org/about) einwerfen. Von der Feature Liste (http://www.ogre3d.org/about/features) klingt es ja zumindst mal ganz brauchbar.
Ich kann leider nicht bewerten wie gut das funktioniert und ob das wirklich was bringt oder ob das am Ende zu kompliziert für OctoAwesome ist, aber vielleicht kann sich das jemand der Ahnung hat mal angucken und hier mal ein Statement zu schreiben ob das ein gangbarer Weg ist oder ich davon ablassen soll das vorzuschlagen ;)

Danke & Gruß

Kai
Dec 22, 2014 at 10:01 AM
Hej :)

Ich hab schon sehr viel mit Monogame gearbeitet nach dem XNA-Schock. Das klappt echt gut, habe damals die XNB Datein noch mit einem XNA Projekt erzeugt, per PreBuild Befehlt dann kopiert und das Monogame-Spiel hat sie geladen. Auch so sachen wie Grafikprogrammierung hat funktioniert (in HLSL wurde dann mit nem speziellen Programm kompiliert und vom Spiel geladen) - ist alles ein bisschen Mehraufwand am Anfang aber dann klappt das schon.

Aber:
  • Mono wird immer mehr kommerzialisiert
  • Monogame = XNA, also wer XNA kann lernt vermutlich nix neues mehr und XNA Anleitungen gibt es haufenweise im Internet
Ich für meinen Teil würde es mit OpenGL (ohne Monogame) deutlich spannender finden, das ist wohl für die meisten C# Programmierer noch Neuland.

Frohes Fest wünsch ich euch !
Dominik
Dec 23, 2014 at 8:39 PM
Hey Tom und alle anderen,

ich kann Dominik nur zustimmen. Auch für mich als C#-Entwickler wäre es sehr reizvoll, mal wirklich an der Basis anzufangen einen einfachen Prototypen, wie Tom ihn "mit uns zusammen" innerhalb der ersten 30 Folgen erstellt hat, auf die nächste Stufe der Evolution zu heben.

Ich war von der ersten Folge an fasziniert und erstaunt, mit welch einfachen Mitteln ein doch sehenswertes Spiel entstehen kann. Ich habe die Folgen in nur wenigen Tagen verschlungen und kann es kaum erwarten das es weiter geht. Besonders bin ich auf die angekündigten Refactorings gespannt.

Freue mich schon auf das Neue Jahr. Kommt alle gut rein und verbringt zuvor eine gesegnete Weihnachtszeit mit all euren Lieben! Genießt die Feiertage!

Bis dann,
Maik