Game-Engine Architecture



  • Moin,
    ich bin dabei mein geballtes Wissen (:D) in eine Engine zu investieren. Dabei ist es mir nicht wichtig, direkt eine lauffähige Engine zu programmieren, sondern eher, dass ich versuche das erste große Projekt anzugehen und dabei sauber zu arbeiten.

    Da kam/kommt mir gleich zu Beginn die erste Frage. Semmel ich den gesamten Code nun in ein Projekt (scheint mir etwas "messy") oder kapsel ich die Untersysteme (Core-Engine, Render-Engine, Physik-Engine)?

    Wie genau würde "gekapselt" werden? Heißt es, dass ich z.B. die gesamte Core-Engine in eine DLL exportiere, die dann von der Render-Engine eingebettet wird? Oder werden vielleicht die einzelnen Aspekte der Core-Engine, wie z.B. die Mathematik, exportiert?

    Mir ist klar, dass ich es handhaben kann wie ich es will, aber da ich keine praktische Erfahrung im Programmieren einer Game-Engine besitze, würde ich gerne wissen, wie ihr es tun würdet bzw. wie es z.B. Unity realisiert.

    MfG


  • Mod

    Du willst eine Problemloesung für deinen Code der erst geschrieben wird?

    Tip 1:
    Schreib erstmal ausreichend deiner "Engine" bevor du die anfallenden Probleme wirklich loest. Du fragst ja auch nicht, ob du "while" oder "for" schleifen verwenden sollst und entscheidest dich im anschluss, dass es eine 3D engine wird.

    Weil:
    Wenn du jetzt denkst "Aber Unreal Engine..." (bzw irgendeine andere software) ist so gut aufgeteilt.. dann musst du bedenken, dass das entwickler sind die 1. es schon zig mal gemacht haben und somit die probleme kennen die sie loesen. 2. ist UE4 nicht von 0 geschrieben, sondern aus UE3 entstanden. da wurden manche dinge "messy" und in der neuen iteration der engines wurde dann das, was als problem erkannt wurde, durch refactoring bereinigt. (Trotzdem steckt in UE4 code aus UE1, der teil der nicht messy war, du kannst dir denken wie klein dieser anteil ist)

    ➡ Löse reale Probleme.

    Tip 2:
    Falls du fleissig bist und einigermassen eine "Engine" hast, wirst du _immer_ zu dem schluss kommen, dass es "messy" ist und du es 100 mal besser machen koenntest. Wenn du diesen moment erreichst, fang nicht bei 0 an sonst endest du im second system syndrome.
    Programmierer zu sein bedeutet nicht nur algorithmen zu kennen oder die sprache zu beherrschen, es bedeutet auch eine code-base verwalten zu koennen. die chancen sind <1% dass du mal von 0 dein traumprojekt (beruflich) erstellen kannst. zu 99% wirst du also eine bestehende code base "erben". dann hast du 2 moeglichkeiten: 1. du kannst wirklich unzufrieden sein wie "scheisse" die ist und du es viel besser schreiben wurdest wenn du bei 0 anfangen kannst. oder 2. weil du es aus deinen "Engine" projekten gelernt hast, findest du wege die code-base am leben zu erhalten und dennoch in den guten zustand zu refactorn, den du dir mit dem System 2.0 eigentlich wuenschen wurdest. Denn jetzt ist endlich der moment sich die fragen zu stellen, die du hier schon vor dem anfang deines projektes machst, und all zu oft tendieren programmierer in projekt 2.0 zu fliehen.

    ➡ Wenn Probleme (endlich) da sind, löse sie.



  • Danke für dein ausführliches Statement.

    Mir ging es bei der Fragestellung eben um folgenden von dir beschriebenen Punkt:

    dann musst du bedenken, dass das entwickler sind die 1. es schon zig mal gemacht haben und somit die probleme kennen die sie loesen. 2. ist UE4 nicht von 0 geschrieben, sondern aus UE3 entstanden. da wurden manche dinge "messy" und in der neuen iteration der engines wurde dann das, was als problem erkannt wurde, durch refactoring bereinigt. (Trotzdem steckt in UE4 code aus UE1, der teil der nicht messy war, du kannst dir denken wie klein dieser anteil ist)

    Ich wollte eben nicht die gleichen Fehler begehen, die die Entwickler von Unity / Unreal (kann auch jedes andere Mega-Projekt sein) gemacht haben, sondern aus deren Erfahrungen "lernen". Aber da ich mich direkt an die Entwickler von den genannten Marken wenden müsste, um dessen Erfahrungen zu kommen, werde ich deinen Vorschlag wohl angehen müssen und selber auf die Fresse fallen :D.

    Ich dachte es gäbe eine allgemeine Herangehensweise für solche Projekte, um alles schön gekapselt und leicht austauschbar zu halten.



  • Egal, was du konkret geschrieben hast (habs nicht gelesen), hier ist deine Antwort: was du vorhast, ist Zeitverschwendung.





  • Also ich finde die Idee erstmal gut, dass du dir sowas vornimmst. Bei so ein Projekt kann man viel lernen.

    Mein Vorschlag: Du schreibst für die Physik, Sound, KI, Grafik, Mathe, Core jeweils eine eigene Dll und fängst für jedes Unterprojekt erstmal an die die Anforderungen und die Schnittstelle zu überlegen.

    Es wäre sogar leichter, wenn du jedes dieser Unterprojekte sogar zuerst erstmal einzeln anlegst, und ein separates kleines Spiel dafür machst, was erstmal nur dieses Unterprojekt testet.

    D.h. ein kleines Spiel mit einfacher Grafik aber toller Physik. Dann ein einfaches Spiel mit einfacher Grafik und Physik dafür aber mit tollen Sound. Usw. für jedes Unterprojekt.

    Danach weißt du dann erstmal, was du mit den Unterprojekten machen willst und kannst nun anfangen dafür eine Schnittstelle dir zu überlegen. Das Core-Projekt vereinigt dann die ganzen Unterprojekte und kennt nur die Schnittstelle für die Unterprojekte, nicht aber die konkreten Klassen.

    Wenn du dann lauter Unterprojekte hast, wirst du feststellen, dass z.B. Physik und Grafik als gemeinsame Basis ein 3D-Objekt hat. All diese Dinge lagerst du dann aus und das wäre dann ein Projekt, was quasi ganz unten die Basis von den Teilprojekten ist.

    Fang also erstmal mit den Teilprojekten an und siehe dann zu, wie du sie vereinigst. Das wäre mein Vorschlag für diese Aufgabe.



  • wasting schrieb:

    Egal, was du konkret geschrieben hast (habs nicht gelesen), hier ist deine Antwort: was du vorhast, ist Zeitverschwendung.

    Argumente?

    dot schrieb:

    1. das hier lesen: https://geometrian.com/programming/tutorials/write-games-not-engines/

    Danke für den Artikel, aber eine einseitige Diskussion über "immer diese Kiddies, die wenn sie ein Spiel entwickeln wollen auch gleich immer anfangen wollen eine Engine zu bauen" hilft mir nicht weiter.

    For any number of reasons, many neophyte game developers (and even some moderately experienced ones) seem to think that a game engine is a required, critical part of a game. They think that—in keeping with the mechanical analogy from which the term “engine” comes from in the first place—like a car, a game with no engine will simply not run. But that mechanical analogy starts to break down when you take it this far, because when you look at the reality of the situation, a game engine is about reusable components. Much like you can build a car with custom parts or generic ones, you can build a game with custom components or reusable ones. The notion that you must have an engine to build a non-trivial game is a fallacy, something perpetuated largely by people who don’t know any better.

    Alles schön und gut und mag für Medieninformatiker zutreffen, die kein Bock haben sich mit der Technologie auseinander zu setzen, die hinter einer Engine steckt und diese nur für ihre Zwecke misshandeln. Ich hab jedoch Interesse an Grafikprogrammierung (nicht Spiele) und an ein größeres Projekt für mich selbst.

    XMAMan schrieb:

    Also ich finde die Idee erstmal gut, dass du dir sowas vornimmst. Bei so ein Projekt kann man viel lernen.

    Mein Vorschlag: Du schreibst für die Physik, Sound, KI, Grafik, Mathe, Core jeweils eine eigene Dll und fängst für jedes Unterprojekt erstmal an die die Anforderungen und die Schnittstelle zu überlegen.

    Es wäre sogar leichter, wenn du jedes dieser Unterprojekte sogar zuerst erstmal einzeln anlegst, und ein separates kleines Spiel dafür machst, was erstmal nur dieses Unterprojekt testet.

    D.h. ein kleines Spiel mit einfacher Grafik aber toller Physik. Dann ein einfaches Spiel mit einfacher Grafik und Physik dafür aber mit tollen Sound. Usw. für jedes Unterprojekt.

    Danach weißt du dann erstmal, was du mit den Unterprojekten machen willst und kannst nun anfangen dafür eine Schnittstelle dir zu überlegen. Das Core-Projekt vereinigt dann die ganzen Unterprojekte und kennt nur die Schnittstelle für die Unterprojekte, nicht aber die konkreten Klassen.

    Wenn du dann lauter Unterprojekte hast, wirst du feststellen, dass z.B. Physik und Grafik als gemeinsame Basis ein 3D-Objekt hat. All diese Dinge lagerst du dann aus und das wäre dann ein Projekt, was quasi ganz unten die Basis von den Teilprojekten ist.

    Fang also erstmal mit den Teilprojekten an und siehe dann zu, wie du sie vereinigst. Das wäre mein Vorschlag für diese Aufgabe.

    Danke, ich habe gestern Nacht noch Kontakt zu Leuten auf anderen Plattformen gesucht, die bereits einiges an Erfahrung im Design einer Engine besitzen und im Grunde haben sie mir genau das gleiche vermitteln wollen, wie du. Außerdem ist deine die einzige Antwort, die wirklich auf meine Fragen eingegangen ist.



  • Kluddizz schrieb:

    Alles schön und gut und mag für Medieninformatiker zutreffen, die kein Bock haben sich mit der Technologie auseinander zu setzen, die hinter einer Engine steckt und diese nur für ihre Zwecke misshandeln. Ich hab jedoch Interesse an Grafikprogrammierung (nicht Spiele) und an ein größeres Projekt für mich selbst.

    D.h. du bist also schon fit in mindestens einer der drei wichtigen APIs. Um dort hinzukommen hast du notwendigerweise schon viele Demos geschrieben, erst um die Grundlagen zu festigen und Erfahrung zu sammeln und später immer mehr um einige fortgeschrittene Effekte zu implementieren. In dem Fall kannst du ja dennoch einfach dem Vorschlag aus dem verlinkten Artikel folgen und anfangen, gemeinsam benutzte Funktionalität aus den letzten paar deiner Demos zu abstrahieren und in eine Library zu packen. Und die nächsten Demos die du schreibst, baust du alle auf dieser Library auf und refactorest wann immer nötig...



  • Kluddizz schrieb:

    wasting schrieb:

    Egal, was du konkret geschrieben hast (habs nicht gelesen), hier ist deine Antwort: was du vorhast, ist Zeitverschwendung.

    Argumente?

    Mein Argument ist, dass es Zeitverschwendung ist. Du wirst weder irgendwas "fertig" bekommen, noch wird sich irgendjemand für den nutzlosen Haufen Code interessieren, den du Meganoob dir da zusammenklöppelst. Niemand wird ein Spiel damit schreiben. Quasi jeder mit Erfahrung auf dem Gebiet wird dir davon abraten.

    Ich hab jedoch Interesse an Grafikprogrammierung (nicht Spiele) und an ein größeres Projekt für mich selbst.

    Oooooh, klar. Kein Interesse an Spielen, aber Game Engines schreiben. Heh. Na dann mal viel Erfolg.



  • dot schrieb:

    D.h. du bist also schon fit in mindestens einer der drei wichtigen APIs. Um dort hinzukommen hast du notwendigerweise schon viele Demos geschrieben, erst um die Grundlagen zu festigen und Erfahrung zu sammeln und später immer mehr um einige fortgeschrittene Effekte zu implementieren. In dem Fall kannst du ja dennoch einfach dem Vorschlag aus dem verlinkten Artikel folgen und anfangen, gemeinsam benutzte Funktionalität aus den letzten paar deiner Demos zu abstrahieren und in eine Library zu packen. Und die nächsten Demos die du schreibst, baust du alle auf dieser Library auf und refactorest wann immer nötig...

    Ja, danke für den Hinweis.

    wasting schrieb:

    Mein Argument ist, dass es Zeitverschwendung ist. Du wirst weder irgendwas "fertig" bekommen, noch wird sich irgendjemand für den nutzlosen Haufen Code interessieren, den du Meganoob dir da zusammenklöppelst. Niemand wird ein Spiel damit schreiben. Quasi jeder mit Erfahrung auf dem Gebiet wird dir davon abraten.

    1. Geile Argumentationsmethodik, der du da folgst.
    2. Wer bist du, dass du private Projekte, von denen weder behauptet wird, dass diese vermarktet werden sollen, noch dass dritte jemals Zugang zu Quellcode bekommen werden, versuchst schlecht zu machen. Ich gehe ja auch nicht in die Uni, um dem Prof zu erzählen: "Junge, deine Vorlesung ist Zeitverschwendung. Weil es Zeitverschwendung ist. Und [...] weil sich niemand um deine für uns ausgedachten Hausarbeiten interessieren wird. Du Meganoob!"
    Es wird dir vielleicht nicht jeder, der Erfahrung in diesem Gebiet hat, das folgende sagen, aber ich mit meinem beschränkten Denken und meiner offiziell anerkannten Meganoob-Auszeichnung sehe mich befähigt zu sagen: Junge, wenn man keine Ahnung hat, einfach mal die ....

    wasting schrieb:

    Ich hab jedoch Interesse an Grafikprogrammierung (nicht Spiele) und an ein größeres Projekt für mich selbst.

    Oooooh, klar. Kein Interesse an Spielen, aber Game Engines schreiben. Heh. Na dann mal viel Erfolg.

    Und auch hier sehe ich kein Gesprächspotential. Du willst mir also sagen, dass jeder, der an einer Engine bastelt auch vor hat, diese exzessiv zu nutzen und damit Spiele zu entwickeln? Sorry, aber ich glaube nicht einmal, dass sich die Entwickler von meinetwegen Unity sich hinsetzen und Spiele damit entwickeln. Warum müssen sie dies auch tun? Um zu sehen, ob das Teil gut nutzbar ist, gibt's Usability-Experten. Um zu sehen, ob implementierte Funktionen so funktionieren wie sie sollen, werden diese sicherlich im laufenden Entwicklungsprozess ausgiebig getestet.
    Also ja, wenns mir darum ginge ein Spiel zu entwickeln, würde ich nicht auf meinen eigenen "nutzlosen Haufen Code, den niemand interessiert" zurückgreifen, sondern besser implementierten "Haufen Code" nutzen.

    Um vielleicht zu wissen, dass

    Kluddizz schrieb:

    Dabei ist es mir nicht wichtig, direkt eine lauffähige Engine zu programmieren, sondern eher, dass ich versuche das erste große Projekt anzugehen und dabei sauber zu arbeiten.

    müssest du vielleicht meine Posts erst einmal lesen, um ordentlich zu argumentieren, aber was bei dir abgeht, beschreibst du ziemlich gut selbst mit:

    wasting schrieb:

    Egal, was du konkret geschrieben hast (habs nicht gelesen), hier ist deine Antwort: was du vorhast, ist Zeitverschwendung.

    Schönen Gruß



  • Du scheinst mich mit jemandem zu verwechseln, den es einen Dreck interessiert was du treibst und schnallst nicht, dass man dir einen Gefallen tun möchte. Du hast einen ganzen Artikel vorgesetzt bekommen, der dir und den Millionen anderen Noobs erklärt, warum dieses Vorhaben dumm ist und zu nichts führt - aber du weißt es besser. Dann einfach mal los, ne.



  • Der Artikel ist aber ebenso Schrott. Als Anfänger gilt sowieso: Don't write [3D] games!
    Wenn man aber Spiele entwickelt (wie ich es lange Zeit getan habe), dann wird man eine geeignete Architektur aufsetzen, welche auf einer Engine basiert. Und selbst, wenn man auf eine professionelle Engine aufbaut, so wird man trotzdem einen Layer (Library) entwickeln, welcher Anpassungen ermöglicht (also quasi eine eigene "Engine").



  • Und ich find solche Artikel sowieso ziemlich sinnlos, wenn es um private Projekte geht (zumindest, wenn man halbwegs weiß, was man tut). Eine Engine zu schreiben kann viel mehr Spass machen, als ein Spiel zu schreiben. Punkt. Artikel sinnlos.



  • Ich kann nur aus Erfahrung sprechen. Ich war selber mal ein Noob, hab ungefähr 28× genau die gleichen Fehler gemacht. Low-level Grafikprogrammierung ist, wofür ich dieser Tage bezahlt werde. Aber was weiß ich schon...steht jedem frei einen gut gemeinten Rat zu ignorieren... 😉


  • Mod

    @Kluddizz
    nimm dir die Antworten nicht so sehr zu Herzen, denn wenn du 100 Entwickler fragst was sie davon halten, wirst du 100 Antworten bekommen. Und jeder wird dir natuerlich den einzig richtigen weg sagen, weil jeder dich davon abhalten will dieselben fehler zu machen (Hab ich oben ja auch), wenn auch diese fehler eventuell die entwickler zu dem machte was sie sind. (und natuerlich werden manche elaboriert antworten, andere in einzeilern "mach xyz, oder willst du ein idiot sein" sagen. trotzdem entspannt bleiben!)

    und vergiss nicht dich zu regestrieren ;), selbst die die dir hier von allem abraten, werden dir vermutlich gerne bei technischen/programmier-problemen helfen.



  • rapso schrieb:

    @Kluddizz
    nimm dir die Antworten nicht so sehr zu Herzen, denn wenn du 100 Entwickler fragst was sie davon halten, wirst du 100 Antworten bekommen. Und jeder wird dir natuerlich den einzig richtigen weg sagen, weil jeder dich davon abhalten will dieselben fehler zu machen (Hab ich oben ja auch), wenn auch diese fehler eventuell die entwickler zu dem machte was sie sind. (und natuerlich werden manche elaboriert antworten, andere in einzeilern "mach xyz, oder willst du ein idiot sein" sagen. trotzdem entspannt bleiben!)

    und vergiss nicht dich zu regestrieren ;), selbst die die dir hier von allem abraten, werden dir vermutlich gerne bei technischen/programmier-problemen helfen.

    Keine Sorge, ich bin ja derjenige der dumm gefragt hat, von daher darf ich mich auch nicht beschweren 🙂

    Falls ich einen neue Fragen habe, werde ich mich natürlich auch registrieren (Ich hoffe du bekommst jetzt einen Anwerber-Bonus 😋)



  • Kluddizz schrieb:

    Falls ich einen neue Fragen habe, werde ich mich natürlich auch registrieren (Ich hoffe du bekommst jetzt einen Anwerber-Bonus 😋)

    Nur wenn du einfachste Worte falsch schreibst, wo etwas ähnliches wie Englisch sprichst und als Einziger glaubst, Rechtschreibung sei total unwichtig. Dann schon.



  • 😃



  • This post is deleted!

Log in to reply