ZFX + Developia

Hallo,

Ich wollte schon seit einigen Jahren mit der Spieleentwicklung anfangen und meine eigenen kleinen Spiele entwickeln.
Die sollen natürlich nicht für irgendwelche komerziellen Zwecke oder sowas ähnliches dienen, ich würde nur gerne mal welche schreiben.
Da ich später als Beruf Spieleentwickler werden möchte und so meine eigene kleine Spielewelt aufbauen will, find ich es besser früh genug damit anzufangen das zu erlernen. Ich weiß das, dass solche Fragen wahrscheinlich fast täglich kommen aber ich würde trotzdem gerne hören, wie das funktioniert und was ich dazu machen muss.
Ich hab mich schon teilweise mit Java / C / VB beschäftigt und habe so leichte Kentnisse, ich würde sagen auf Anfänger Niveau.
Mein Alter ist nochn bisschen jung wie ich gehört hab, aber was solls wenn ich Spaß dran habe mach ichs.
Meine konkreten Fragen nun:

1. Was muss ich lernen um meine eigenen Spiele entwickeln zu können (ohne Engine)?
2. Brauche ich künstlerische Fertigkeiten um Spiele zu designen? (Ich bin im malen wirklich grottenschlecht und das liegt nicht daran das ich zu faul bin ;P)
3. Mit welcher Sprache sollte ich Spiele programmieren? (Java oder C++?)
4. Hat Spieelentwicklung es konkret mit Programmieren zu tun?
5. Könnt ihr mir Tutorials geben mit denen ich die Sachen lernen kann? (Deutsche wären mir am liebsten)

Vielen Dank schonmal ;P

Trunestus hat geschrieben:1. Was muss ich lernen um meine eigenen Spiele entwickeln zu können (ohne Engine)?

- Eine Programmiersprache
- Die Benutzung von Schnittstellen, um auf Grafikausgabe, Eingabe, Sound und Netzwerk zuzugreifen

Beispiel 1: Programmiersprache C, Grafik und Eingabe mit SDL, kein Sound, kein Netzwerk
Beispiel 2: Programmiersprache Java, Applet-API für Eingabe, Ausgabe; Netzwerk wird von Java angeboten

Trunestus hat geschrieben:2. Brauche ich künstlerische Fertigkeiten um Spiele zu designen? (Ich bin im malen wirklich grottenschlecht und das liegt nicht daran das ich zu faul bin ;P)

im Prinzip nein, du kannst überall Platzhaltergrafiken benutzen.

Trunestus hat geschrieben:3. Mit welcher Sprache sollte ich Spiele programmieren? (Java oder C++?)

Such es dir aus.

Trunestus hat geschrieben:4. Hat Spieelentwicklung es konkret mit Programmieren zu tun?

Ja. (Es sei denn du nimmst eine Engine, die so spezialisiert ist, dass du nur noch fertige Szenen mit einem Editor zusammenklicken musst)

Trunestus hat geschrieben:5. Könnt ihr mir Tutorials geben mit denen ich die Sachen lernen kann? (Deutsche wären mir am liebsten)

Wofür hast du dich denn bei 3. entschieden?

(ohne Engine)

Hm, seine eigene Engine fürs Spiel schreibt man heutzutage eigentlich nur noch selten. Was spräche denn gegen eins der gängigen Entwicklertoolkits? UDK, Unity und Cryengine gibts ja für Lau.

antisteo hat geschrieben:

Trunestus hat geschrieben:1. Was muss ich lernen um meine eigenen Spiele entwickeln zu können (ohne Engine)?

- Eine Programmiersprache
- Die Benutzung von Schnittstellen, um auf Grafikausgabe, Eingabe, Sound und Netzwerk zuzugreifen

Beispiel 1: Programmiersprache C, Grafik und Eingabe mit SDL, kein Sound, kein Netzwerk

Das stimmt so nicht. In C kannst du genau das gleiche Programmieren, wie in jeder anderen Programmiersprache auch. Sound wird auch über die SDL angeboten und Netzwerk auch. Und gerade beim Netzwerk gibt es, sollte auf einem System nur die absolut notwendigen Funktionen zur Verfügung stehen, select, recv, send.

Alles andere deines Posts gebe ich dir vollkommen Recht.

Tiles hat geschrieben:Hm, seine eigene Engine fürs Spiel schreibt man heutzutage eigentlich nur noch selten.

Da wäre ich mir gar nicht so sicher. Ich sehe immer noch genug große und kleine Spiele, die nicht auf Source, UDK oder Unity basieren.

Erstmal: Danke für die schnellen Antworten ;)

@antisteo:
Wie ist das mit der Benutzung der Schnittstellen gemeint?
Was sind Platzhaltergrafiken? :/
Ich habe mich jetzt für C++ entschieden, weil ich gesehen hab wie viele Engines C++ unterstützen und ich Java verworfen hab aufgrund
persönlicher Meinungsänderung (Minecraft wegen dem laggen bsp [Ich weiß ist nicht immer so]).
Bei welchem Engine muss man denn nurnoch die fertigen Szenen zusammenklicken? Ist das nicht eher sowas wie ein Baukasten?
Wie gesagt habe mich für C++ entschieden.

@Tiles:
Ich möchte gerne, später viele schwere Programme schreiben und finde es etwas professioneller wenn ich meine eigene Engine schreibe.
Ich will ja alles aus diesem Bereich lernen um so viel wie möglich vom programmieren zu lernen ;)
Benutzen die Entwickler von den heutigen Spielen auch nur die Engines?

Auf jedenfall würde ich gerne alles über die Spieleentwicklung lernen, weil ich später noch grössere Pläne haben und das vllt. mit meinem Interesse
an Hardware verbinden will und vllt. so einen kleinen Roboter oder so etwas bauen und selbst programmieren ;P
Ehrgeizige Pläne -- Ich habe aber auch genug Zeit die umzusetzen.

Vielen Dank nochmal an alle ;)

€dit:
Ich habe mir jetzt das Buch "C++ für Dummies" bestellt und werde mich da mal einlesen, kennt ihr noch gute Tutorials für C++?

Trunestus hat geschrieben:Auf jedenfall würde ich gerne alles über die Spieleentwicklung lernen, weil ich später noch grössere Pläne haben und das vllt. mit meinem Interesse an Hardware verbinden will und vllt. so einen kleinen Roboter oder so etwas bauen und selbst programmieren ;P

Und warum fängst du dann mit Spielen an? Robotik hat, abgesehen von relativ viel linearer Algebra und der einen oder anderen Visualisierung, nicht sehr viel mit Spielen gemeinsam.

So war das nicht gemeint.
Das war nur ein Beispiel vllt. will ich in Richtung Konsolenentwicklung was machen.

Erstmal willkommen bei ZFX!

Früh genug kann man nicht anfangen, denn es ist ein langer Weg. Bedenke, dass du ein paar Jahre brauchen wirst, bis du wirklich was gutes auf die Beine stellen wirst. Ich habe damals auch mit C++ angefangen - wenn man sich erstmal reingefunden hat ist es gar nicht mehr so schwer. Ich empfehle learning-by-doing, am besten mit einem Buch an der Seite. Bücher finde ich in der Regel besser als Online-Tutorials, aber auch da wird es gute geben. Warte auf dein Buch und spiel ein bischen rum. Fang mit Konsolenanwendungen an (also keine Anwendungen für Konsolen, sondern einfache Ein- und Ausgabe in einem Konsolenfenster). Grafische Anwendungen und eigene Engine würde ich später angehen. Allgemein solltest du nicht gleich mit Spielen anfangen. Bau was kleines, damit du Erfolgserlebnisse hast. Vielleicht einen Taschenrechner oder simple Algorithmen um z.B. die Fibonacci-Folge zu berechnen. Das klingt öde, aber es macht Spaß und man lernt was dabei. Du solltest eh erstmal die Grundlagen lernen. Variablen, Funktionen, Klassen, Zeigerarithmetik usw. und auch nach und nach ein paar gängige Bibliotheken kennenlernen (im Fall von C++ ist die STL zum Beispiel sehr wichtig und nützlich).

Ich habe damals mit sowas angefangen und rumgespielt und dadurch gelernt wie vieles funktioniert. Nach einer Weile habe ich mir dann eine simple OpenSource-2D-Spieleengine angeschaut und versucht den Code zu verstehen. Danach habe ich meine eigene kleine 2D-Engine gebastelt, die Grafiken und Text anzeigen konnte und habe damit meine ersten kleinen Spiele gebastelt (sowas in der Art von Moorhuhn). Soweit war ich etwa nach 6-12 Monaten (ist schon lange her).

Zum Thema Platzhaltergrafik: Das sind einfach simple (vielleicht auch häßliche) Grafiken, die man verwendet um erstmal was zu sehen und die dann später im fertigen Spiel gegen die richtigen Grafiken ausgetauscht werden. So könnte die Spielfigur z.B. am Anfang einfach ein roter Ball oder ein rotes Viereck sein und im fertigen Spiel dann die Grafik eines Charakters. Wichtig ist nämlich am Anfang nicht die Optik, sondern eher die technische Umsetzung und ob alles so läuft, wie man sich das vorstellt. Ob man nun ein rotes Viereck (die Platzhaltergrafik) oder ein Männchen über den Bildschirm bewegt ist am Anfang recht egal. ;)

Trunestus hat geschrieben:Wie ist das mit der Benutzung der Schnittstellen gemeint?

C++ ist halt nur die Programmiersprache, die keine direkte Möglichkeit bietet irgendwelche Grafiken oder Sounds auszugeben. Dafür gibt es spezielle APIs/Bibliotheken. Im Falle von Grafik gibt es z.B. die SDL. Man kann aber auch direkt mit DirectX oder OpenGL was auf den Bildschirm zaubern. Unter heutigen Betriebssystemen kann man nicht direkt aus dem Code in den Grafikspeicher schreiben (wie das z.B. beim GameBoy ging), daher benötigt man Schnittstellen wie eben DIrectX oder OpenGL. Zu diesem Thema kannst du dich wenn die Zeit reif ist ja mal schlaumachen. ;)

Danke ;)
Für mich klingt nichts öde was mit PC zu tun hat, weil ich einfach liebend gerne am PC arbeite.
Werde ich machen, aber ist man nicht mit einer Programmierersprache mit den Grundlagen fertig sobald man ein Lernbuch/Lehrbuch durchgearbeitet und verstanden hat?
So wie ich das verstanden hat sollte ich C++ lernen und dann mit DirectX oder OpenGL anfangen?
Die "paar" Jahre habe ich, da ich das auch als Beruf ausüben möchte da das meine Liebe zum Computer und zu Spielen verbindet ;P

Man ist lange nicht fertig, wenn man ein Buch durch hat. Ich mache jetzt C++ seit 15 Jahren und Programmierung im allgemeinen seit über 25 Jahren und ich lerne immernoch jeden Tag neues. Du kannst Dir eine Menge davon ersparen, weil speziell im Bereich "Computer" vieles schnell veraltet, aber viele Erfahrungen musst Du trotzdem machen, bevor Du wirklich eine Programmiersprache beherrschst.

DirectX und OpenGL sind aber in jeder Programmiersprache machbar. Dafür muss es jetzt nicht unbedingt C++ sein. Und wenn Du C++ machen willst, würde ich dazu raten, am Anfang eine Bibliothek zu nutzen, die Dir die gängigen Aufgaben abnimmt. Allein das allgemeine Verstehen des Zusammenspiels von CPU und GPU auf aktuellen Rechnern ist schon ein ordentlicher Packen. C++ bringt leider keine eingebauten Möglichkeiten für Grafik oder Sound mit. Mit einer Bibliothek wie z.b. der SFML kannst Du erstmal grundlegende Spielelogik lernen, ohne in die Tiefen der 3D-Programmierung und der WinAPI einzusteigen, um überhaupt ein Fenster auf dem Desktop zu öffnen.

Lass Dir Zeit, überhaste nichts, fange wirklich wirklich klein an. Berzerker hat den Finger drauf, wenn er sagt, dass Du mit ganz kleinen Konsolen-Anwendungen anfangen solltest. Allein dafür wirst Du einige grundlegende Programmierkonzepte draufhaben müssen, die für komplette Neulinge eine Hürde darstellen.

Schrompf hat geschrieben:DirectX und OpenGL sind aber in jeder Programmiersprache machbar. Dafür muss es jetzt nicht unbedingt C++ sein. Und wenn Du C++ machen willst, würde ich dazu raten, am Anfang eine Bibliothek zu nutzen, die Dir die gängigen Aufgaben abnimmt. Allein das allgemeine Verstehen des Zusammenspiels von CPU und GPU auf aktuellen Rechnern ist schon ein ordentlicher Packen. C++ bringt leider keine eingebauten Möglichkeiten für Grafik oder Sound mit. Mit einer Bibliothek wie z.b. der SFML kannst Du erstmal grundlegende Spielelogik lernen, ohne in die Tiefen der 3D-Programmierung und der WinAPI einzusteigen, um überhaupt ein Fenster auf dem Desktop zu öffnen.

Prinzipiell gebe ich dir Recht wenn es darum geht zu lernen wie man Spiele entwickelt. Ich finde es aber auch wichtig zu verstehen wie eine Engine funktioniert und wie eigentlich die Grafik auf den Bildschirm kommt. Wie gesagt habe ich damals eine sehr kleine (SFML ist ja schon etwas größer) 2D-Engine gefunden (damals noch DirectDraw, was ich für den Einstieg sehr einfach fand), deren Code wirklich überschaubar war und wirklich nur das Nötigste enthielt (Fenster erstellen -> MessageLoop -> Zeichnen von Grafiken und Text). Ich brauchte damals auch nichts (bzw. wenig) von 3D oder GPUs zu wissen (vielleicht wozu ein Backbuffer dient etc), wusste aber immerhin wie ich mit der Schnittstelle (in dem Fall DirectX) etwas auf den Bildschirm bekomme. Es war für mich eine Vorstufe zu der eigentlichen Umsetzung eines Spiels - und es war sehr viel spaßiger etwas "mit den eigenen Händen" sichtbar zu machen. Ich weiß nicht wie mein Weg ausgesehen hätte, wenn ich erst mit einer fertigen Engine / SDK ein Spiel gebastelt hätte und danach erst verstanden hätte wie das ganze technisch eigentlich möglich war. Zugegeben wäre das ganze in OpenGL etwas komplizierter (mit DirectGraphics wohl auch), aber mir hat eine sehr simple Engine ohne viel Funktionalität und Schnickschnack damals mehr gebracht. Auch das Kennenlernen der WinAPI fand ich nicht verkehrt, auch wenn es ein recht großer Brocken ist. Hat man diesen aber grundlegend verstanden, versteht man auch viele technische Details (zumindest in der Windows-Welt).

Trunestus hat geschrieben:Werde ich machen, aber ist man nicht mit einer Programmierersprache mit den Grundlagen fertig sobald man ein Lernbuch/Lehrbuch durchgearbeitet und verstanden hat?

Schrompf hat es schon auf den Punkt gebracht. Unterschätze das ganze nicht! Es steckt viel Arbeit und Zeit in der Erlernung und es ist ein lebenslanger Lernprozess. Es wird immer etwas geben was man besser oder anders machen kann, es wird immer mal wieder Neues geben und auch nach Jahrzehnten wird man immer noch Überraschungen erleben oder Leute treffen, die die eigene Sichtweise ändern.

Trunestus hat geschrieben:So wie ich das verstanden hat sollte ich C++ lernen und dann mit DirectX oder OpenGL anfangen?
Die "paar" Jahre habe ich, da ich das auch als Beruf ausüben möchte da das meine Liebe zum Computer und zu Spielen verbindet ;P

Wichtig ist erstmal der Einstieg - die Grundlagen. Sie sind das Handwerkszeug, welches du benötigst um überhaupt erst einmal ein Programm zu schreiben. Wenn du dein Handwerk gut genug beherrschst, kannst du weitermachen. Kleine Progrämmchen - viel Ausprobieren. Hintergründe und Verfahren verstehen bzw. kennenlernen, viel Zeit mit der Suche von Bugs verbringen und irgendwann wirst du auch so weit sein in tiefere Bereiche wie der Spieleentwicklung vorzudringen. Nimm dir Zeit. Bleib am Ball. Übe, probiere, mach was! Wenn du ehrgeizig bist und Spaß dran hast wird aus dir mal ein guter Programmierer. ;)

Dazu will ich auch mal was sagen

Berserker hat geschrieben:Ich finde es aber auch wichtig zu verstehen wie eine Engine funktioniert und wie eigentlich die Grafik auf den Bildschirm kommt...

Ich denke aber auch, um mit einer Engine (oder Bibliothek, oder Framework, oder was auch immer) ein gewünschtes Ergebnis zu bekommen, muss man im Prinzip verstehen wie diese funktioniert. Also wenn man sich alleine schon mit einer Engine/etc. beschäftigt, lernt man schon etwas über die Funktionsweise.
Ich merkte das zB an Qt. Am Anfang waren es eben Tutorials abarbeiten, damit mal etwas rumspielen, mal was eigenes gebastelt. Dabei verstand ich immer ein Stück mehr, wie diese im Prinzip intern funktioniert. Ich lernte nebenbei auch noch etwas über Softwaredesign (@Trunestus: auch ein Thema mit dem du dich früher oder später auseinandersetzen solltest/zwangsläufig musst ;) ).
Hatte ich mal zeitweise mit anderen GUI-Frameworks zu tun, konnte ich auf meine Erfahrung mit Qt zurückgreifen.
Ich denke, ähnlich ist es auch bei Engines.

Aber grundsätzlich wurden hier ja schon die wichtigsten Tipps gegeben, warn nur mal meine 2 Cent..

simbad hat geschrieben:

antisteo hat geschrieben:

Trunestus hat geschrieben:1. Was muss ich lernen um meine eigenen Spiele entwickeln zu können (ohne Engine)?

- Eine Programmiersprache
- Die Benutzung von Schnittstellen, um auf Grafikausgabe, Eingabe, Sound und Netzwerk zuzugreifen

Beispiel 1: Programmiersprache C, Grafik und Eingabe mit SDL, kein Sound, kein Netzwerk

Das stimmt so nicht. In C kannst du genau das gleiche Programmieren, wie in jeder anderen Programmiersprache auch. Sound wird auch über die SDL angeboten und Netzwerk auch. Und gerade beim Netzwerk gibt es, sollte auf einem System nur die absolut notwendigen Funktionen zur Verfügung stehen, select, recv, send.

Alles andere deines Posts gebe ich dir vollkommen Recht.

Und was ist jetzt an dem Beispiel falsch? Ich behaupte nur, dass etwaige Kombination von Sprache+API möglich ist. (Ich persönlich nutze Freepascal, SDL, enet, OpenAL, Newton, OpenGL und es funktioniert auch)

Was mir aufstösst ist die Verbindung von "C" mit "kein Sound, kein Netwerk". Was bei mir die Assoziation auslöst, das man eben wenn man in C programmiert keinen Sound und kein Netzwerk nutzen könne. Und das ist falsch.
Bei der Verbindung Java hingegen sind alle Komponenten irgendwie verfügbar.
Das ist alles.

Danke für die Antworten, ich werde das so machen wie ihr vorgeschlagen habt.
Mir erschließt sich aber irgendwie nicht, wie man in C++ ein Spiel schreiben sollte..
Kann mir einer bitte noch einen Bespielcode geben?
Also von einem kleinen Spiel.

Google ist dein Freund ;)
zB hier:
http://www.cplusplus.happycodings.com/Games/index.html

Zum Thema Spieleentwicklung:
Ob du eie Programmiersprache lernen musst oder nicht hängt im Wesentlichen davon ab, was du machen willst. Wenn du die Implementierung übernehmen willst, führt keinWeg daran vorbei. Wenn du dir aber eher interessante Spielmechaniken überlegen willst, dann müsstest du nur eine Programmiersprache lernen, wenn es ein Computerspiel sein muss (scheint gegeben zu sein) und du keine Leute oder geeigneten Tools findest. In vielen Fällen lässt sich eine konkrete Spielmechanik, beispielsweise zu Test- oder Präsentationszweck, auch als Brett-/Karten-/Pen&Paper-Spiel umsetzen. Du solltest auch schauen, in wie weit vorhandene Tools dir Arbeit abnehmen können. Zu diesen gehören die SDKs der größeren Engines, Unity, der Gamemaker, Stencyl etc. ...

Zur Programmiersprache:
Diese sollte man in Abhängigkeit von den Anforderungen wählen. Dazu gehört neben den umzusetzenden Merkmalen auch das vorhandene Wissen.

Zur Engine:
Für ein einfacheres kleines Spiel benötigt man meist keine Engine. Und ich erinnere mich an den Satz "Programmiere keine Engine, programmiere Spiele!".

Sacaldur hat geschrieben:Zur Engine:
Für ein einfacheres kleines Spiel benötigt man meist keine Engine. Und ich erinnere mich an den Satz "Programmiere keine Engine, programmiere Spiele!".

Das heißt aber, dass man für ein Spiel eine fertige Engine nehmen sollte und eben NICHT die kompletten Strukturen einer Engine zusätzlich mitprogrammiert.

antisteo hat geschrieben:

Sacaldur hat geschrieben:Zur Engine:
Für ein einfacheres kleines Spiel benötigt man meist keine Engine. Und ich erinnere mich an den Satz "Programmiere keine Engine, programmiere Spiele!".

Das heißt aber, dass man für ein Spiel eine fertige Engine nehmen sollte und eben NICHT die kompletten Strukturen einer Engine zusätzlich mitprogrammiert.

Eine Engine ist ja ein breit gefächerter Begriff. Heutzutage denkt ja jeder bei Engine gleich an tolle 3D-Engines mit tollen Features, vielleicht sogar noch Unterstützung für Sound und Physik. Eine Engine kann aber auch was ganz kleines sein, was einfach ein paar farbige 2D-Formen auf den Bildschirm zaubern kann. Und ich finds nicht verkehrt solche kleinen Engines selbst zu programmieren. Meine erste Engine bestand aus einem einzigen Paar aus Header- und Sourcedatei und hatte insgesamt vielleicht 100-200 Zeilen Code. Sie konnte nicht viel, aber man konnte schon kleine häßliche Spielchen damit fabrizieren.

Am Anfang sollte man eh nicht gleich den Fokus auf optisch herausragende Spiele legen, sondern Projekte, bei denen man Spielmechaniken und Umsetzungsverfahren erlernt. Daher finde ich es gar nicht so gut, dass man sich gleich auf Unity und Co. stürzt, wenn man vor hat später auch selbst Spiele von Grund auf selbst zu programmieren oder halt ohne Eierlegende Wollmilchsäue und nur mit einer simplen Engine oder Hilfs-Libs ein Spiel zu entwickeln.

antisteo hat geschrieben:

Sacaldur hat geschrieben:Zur Engine:
Für ein einfacheres kleines Spiel benötigt man meist keine Engine. Und ich erinnere mich an den Satz "Programmiere keine Engine, programmiere Spiele!".

Das heißt aber, dass man für ein Spiel eine fertige Engine nehmen sollte und eben NICHT die kompletten Strukturen einer Engine zusätzlich mitprogrammiert.

es heißt wohl eher, dass man Spiele entwickeln soll - und diese müssen ja nicht zwingend auf einer Engine aufbauen

wie bereits geschrieben wurde: das Verständnis des Begriffs Engine ist nicht gerade einheitlich
so würde ich neben den (beispielhaft) genannten Game-Engines (bspw. Unreal Engine, Cry Engine, Source Engine), auch Physic Engines (Box2D, Chipmunk, Havok, ...) 3D-Engines (Irrlicht, Ogre, ...) usw. sehen
aber selbst wenn man so eine so kleine "Engine" als Engine bezeichnen würde: ich würde weiterhin das Zitat anbringen

Sacaldur hat geschrieben:

antisteo hat geschrieben:

Sacaldur hat geschrieben:Zur Engine:
Für ein einfacheres kleines Spiel benötigt man meist keine Engine. Und ich erinnere mich an den Satz "Programmiere keine Engine, programmiere Spiele!".

Das heißt aber, dass man für ein Spiel eine fertige Engine nehmen sollte und eben NICHT die kompletten Strukturen einer Engine zusätzlich mitprogrammiert.

es heißt wohl eher, dass man Spiele entwickeln soll - und diese müssen ja nicht zwingend auf einer Engine aufbauen

Wir willst du das anstellen? Ich meine, selbst wenn du ein Textadventure auf der Kommandozeile entwickelst, sobald du eine Datenstruktur anlegst, die zentral die Antwortmöglichkeiten für die Nutzereingabe bereithält, kann man das schon als Engine bezeichnen.
Engine vs Spiellogik ist einfach eine logische Trennung, die man typischerweise bei jedem Spiel vorfindet. Bei dem einen ausgeprägter, beim anderen zusammengematscht.
Was du wohl meinst ist, dass du zusammengematscht programmieren willst. (Hinweis: Damit macht man sich manchmal mehr Arbeit als nötig.)

Nein, das hast Du missverstanden, antisteo. Der Hinweis lautet: versuche nicht, eine Engine zum Selbstzweck zu schreiben, denn dann wird die Engine unbrauchbar für richtige Spiele. Wenn Du dagegen die Engine zusammen mit einem Spiel entwickelst, kommt eine Engine dabei heraus, die zumindest für ein Spiel taugt. Von sauberer oder unsauberer Software-Architektur war da nirgends die Rede. Die wird bei einem wirklichen sowieso Grütze.

Jepp, der Klassiker: Write Games, Not Engines

Most hobby developers who “finish” an “engine” that was designed and built in isolation (with the goal of having an engine, not a game, upon completion) can’t ever actually use it, and neither can anybody else. Since the project didn’t have any goals, any boundaries, or any tangible applications, it essentially attempted to solve aspect of the chosen problem space and consequently failed miserably. These “engines” tend to be little more than an inconsistent and messy amalgamation of random functionality that isn’t terribly practical, robust or reusable.