@ BlackJack: auch Dir vielen Dank fürs reinschauem und für die interessanten Inputs!
BlackJack hat geschrieben:
Ein anderer Weg das anzugehen ist eine bessere Organisation der Module. Zum Beispiel nur *ein* Skript auf oberster Verzeichnisebene und den Rest in ein Package stecken. In dem Skript muss nicht viel stehen. Importieren des Startmoduls aus dem Package und ausführen der Hauptfunktion würde schon reichen. Dieses Programm wäre für mich auch die einzige Stelle wo ein ändern von `sys.path` okay ist um das Package im Pfad zu haben egal von welchem Arbeitsverzeichnis man das Skript startet. Das Ändern damit die Verzeichnisse ``core`` und ``levels`` im Pfad sind ist IMHO unsauber. Warum sind das nicht einfach Packages? Es macht doch wenig Sinn den Quelltext auf Verzeichnisse aufzuteilen, nur um diese Struktur dann für Importe wieder „flachzuklopfen” in dem alle Verzeichnisse zu den Modulsuchpfaden hinzugefügt werden.
.
Das mit den Packages klingt einlauchtend und Du hast Recht; ich habe noch nie Packages benutzt und bin allgemein bzgl. Struktur von Programmen noch nicht der King... die Packages muss ich mir anschauen. Dann könnte ich z.Bsp. meine "Engine" (eben den "Core" Ordner), die ich für jedes Game brauche und immer wieder extende, als package importieren (wie pygame selbst)? Das klingt gut!
BlackJack hat geschrieben:
Ein ähnliches „vermanschen” machst Du Durch die Sternchenimporte. `constants` importiert aus *fünf* Modulen alles mit Sternchen und das Modul wird dann selbst wieder in *21* anderen Modulen mit Sternchenimport verwendet. Dort dann nachzuvollziehen wo einzelne Namen aus den fünf ursprünglichen Modulen her kommen ist unnötig schwer.
Das mit dem constants Modul hab ich eben gemacht, dass ich, wenn ich ein neues Skript anfange, dieses Modul mit * importieren kann und so all die wichtigen Konstanten des jeweiligen Games (RES, directions, Farben, load_image() etc) immer überall parat habe. Als ich dieses constant File noch nicht hatte, war es übler; ich glaube im Grundsatz ist das nicht so schlecht, dieses constants File, das die Engine und wichtige Konstanten des Spiels einliest und zur Verfügung stellt?
BlackJack hat geschrieben:
Beim Code habe ich hier und da mal reingeschaut und da wird einiges komplizierter gemacht als es müsste. Bei 6K+ Zeilen Code möchte ich da aber jetzt nicht alles durchgehen.

Es könnten aber wohl weniger sein, wenn man Quelltext der nach kopieren und einfügen und geringfügig anpassen aussieht umschreibt, zum Beispiel mit Schleifen und/oder Funktionen.
Ein Blick in die Datei mit der gestartet wird zeigt mir auch dass ich da gar nicht ins Detail gehen möchte solange das Modul nur aus *einer* Klasse mit über *80* Methoden in cirka 1800 Zeilen Code besteht. Das ist im Grunde bloss ein Modul mit lauter ``global``-Anweisungen in eine Klasse verschoben so das ``global`` dann durch ``self`` ersetzt ist. Semantisch macht es das aber nicht besser.
Mal vorab: Wenn Du mit "kopieren und einfügen und geringfügig anpassen" meinst, dass ich Teile von der letzten Game Klasse, die ich geschrieben habe, wiederverwende (und gegebenenfalls anpasse), dann hast Du... wohl Recht

. Aber wenn Du meinst, ich kopiere mir irgendwas zusammen von woher-auch-immer: Nö. ALLES "from scratch" (abgesehen von Pygame natürlich)! Ich schreibe mein Game selbst und es ist eher mein "Problem", dass ich sogar low level Zeugs wie eben die Rect Klasse lieber selbst schreibe (und dabei was lerne), als dass ich bestehenden Code verwende... wenn ICH es geschrieben habe, weiss ich, was es macht und was ich tun muss, wenn's es nicht mehr macht

. Das ist mir wohler als Zeugs zu kopieren.
Dann sagst Du, "Es könnten aber wohl weniger sein..." "...zum Beispiel mit Schleifen und/oder Funktionen."
Meine Game Instanz HAT ja nur Schleifen und Funktionen (Methoden)? Siehst Du da "losen" Code rumhängen? Da verstehe ich nun wirklich nicht was Du meinst... Die Methoden meines Games, auch wenn es viele sind - und es braucht deren viele -, sind doch allesamt schön verpackt?
Du scheinst ganz grundsätzlich mit der Game Klasse unzufrieden zu sein, hab ich das richtig verstanden? Diese sei gross / kann zu viel (hat zu viele Methoden) oder was genau meinst Du? Ist es nicht sinnvoll, dass es eine Game Klasse gibt, von welcher ich dann eine Game Instanz erzeuge, und dieser sage: run()? Dann sollte ich dem Game doch auch sagen können: blit_chars()? Und wait(frames)? und check_quit()? Ich weiss nicht genau, was Du findest, ist daran nicht gut? Kannst Du mir das noch etwas näher bringen?
Dann hat das Game ja verschiedene "scenes". Sprich: Im Titelmenü wird etwas immer wieder (gleich) gemacht, im Editor, im Spiel selbst, im Intro... dies sind meine verschiedenen Scenes (Methoden der Instanz "game") und das Game, wenn ich sage game.run(), macht dann einfach immer dasselbe: es führt game.scene() aus. Und wenn game.scene None ist, bricht das Spiel ab. Das ist doch eine gute Grundstruktur für ein Programm/Game?
Verstehe mich nicht falsch, ich möcht meinen Code besser machen, aber was findest Du an dieser Struktur mit der Game-Instanz, welche das eigentliche Spiel selbst darstellt, nicht gut?