Pygame für Aufbaustrategie?

[waschecht]

Für den ersten simplen Einstieg ganz nett, aber auch hier sieht man dieses große hässliche main-Loop-Konstrukt. Um eine bessere Struktur in sein pygame-Projekt zu bekommen empfehle ich diese Seite hier: Link

Hallo,
ich hab ein paar Fragen zu dem Beispiel.
Vorab, ich habe wenig Erfahrung Python und Programmierung, allerdings gutes mathematisches Wissen. Bisher hab ich so Dinge wie, Listen sortieren, XML lesen und schreiben, Iconbuttons erstellen und Events drauflegen gemacht.
Ich würde nun gerne das ganze in ein größeres Projekt einbringen. Ziel soll ein Klon eines Wirtschaftsspiels aus den 80er/90er Jahren mit vielen Menues sein. Getestet hab ich pyglet, cocos2d und jetzt pygame. Letzteres scheint mir (aus meiner Sicht) einfacher, weswegen ich mich dazu entschieden habe.

Zu der Frage:
Wie ich das sehe, dient der eventmanger zur Steuerung des gesamten Programms. Soweit okay, ich hab auch recht einfach neue events einzufügen und ansteuern können.
In einem anderen Beispiel sah ich aber, dass auch ein neuer Controller (RoomController) hinzugefügt wurde. Damit sollten andere Räume (also auch Menüs) betreten werden können. Ich bin nun etwas verwirrt, weil ich dachte, alles über den Eventmanager regeln zu können.
Wie läuft das mit diesem Ansatz genau? Was braucht man, um effizent an verschiedenen Menuescenen zu arbeiten?

Vielleicht hat jemand eine gute Antwort oder einen verständlichen Link!
Danke schon mal!

PS: Hoffe das war halbwegs verständlich.

[BlackJack]

@waschecht: Der Eventmanager, im ersten Diagramm ja noch Mediator genannt, vermittelt nur die Events zwischen Sendern und Empfängern. Der steuert nichts. Also brauchst Du wenn Du Räume steuern willst, einen Controller dafür. Wobei mir jetzt nicht ganz klar ist was für Dich oder das Beispiel Räume sind, und warum ein Raum auch ein Menü sein soll. Lass uns also lieber über einen MenuController reden, hinter dem ein Modell von einem Menü mit Menüpunkten und eventuell Untermenüs steht. Der sich beim Eventmanager wahrscheinlich als Listener für Tastendrücke, Mausbewegungen, und Mausklicks registrieren. Und selbst wird er Ergeignisse wie „Neues Menü”, „Menüpunkt X ist ausgewählt”, „Menüpunkt X ist aktiviert” und so weiter versenden. In dem Tutorial kommen ja solche Beispiele vor.

Da sind wir aber schon fast dabei ein eigenes Menü- oder vielleicht sogar Fenstersystem zu entwickeln. Ich glaube das würde ich nicht machen wenn ich ein Spiel implementieren wollte. Dann kommt man nämlich nicht zum Spiel selbst sondern macht einen riesigen Nebenkriegsschauplatz auf. Gerade wenn man das so entkoppelt wie möglich machen möchte wie in dem Tutorial, kann man sich da endlos in Detailfragen verzetteln und bekommt nichts Spielbares auf die Reihe.

Ich würde mir da ein fertiges Rahmenwerk suchen. Und wahrscheinlich nicht das aus dem Tutorial, denn da sind einige Sachen drin die nicht nach Python aussehen. Der macht das offenbar noch nicht lange, und da ist vielleicht mehr Java oder C# als Python drin. Mal ein Beispiel:

Code: Alles auswählen

    def Connect(self, eventDict):
        for key,event in eventDict.iteritems():
            try:
                self.__setattr__( key, event )
            except AttributeError:
                print "Couldn't connect the ", key
                pass

Das ``pass`` ist unsinnig. Die Fehlerbehandlung ist keine, denn wenn man ein Event nicht verbinden konnte, sollte man das vielleicht nicht einfach nur ausgeben, aber ansonsten „verschlucken”. Ausserdem frage ich mich wann dieser `AttributeError` eigentlich überhaupt auftreten kann‽ Dann sollte man die „magischen” Attribute vermeiden wenn man das gleiche ohne erreichen kann. In diesem Fall also die `setattr()`-Funktion. Oder man macht es wissentlich und absichtlich magisch, dann würde man aber direkt das `__dict__`-Attribut aktualisieren. Was mir dabei semantisch nicht gefällt, ist das man aufpassen muss keine Attribute von der Klasse oder ihren Basisklassen damit zu verdecken. Da ist nicht nur eigener Code bei, sondern das ganze erbt von der `Sprite`-Klasse aus `pygame`. Man hat also nicht mal sicher unter Kontrolle welche Attribute es da geben könnte, sondern hängt von einer Bibliothek von jemand anderem ab.

Ansonsten wird auf Wörterbüchern öfter die `keys()`-Methode aufgerufen wo das gar nicht nötig ist. Statt Wahrheitswerten wird 0 und 1 verwendet. Irgendwo gibt es `__text` als Attributnamen…

[waschecht]

An welches Framework denkst du?
Ich hab natürlich auch schon fertige Software ausprobiert, also sowas wie Game Develop und co. Blender und Panda hab ich auch angeschaut. Letztere sind etwas zu überdimensioniert, weil ich eigentlich nur Bilder, Tabellen, Buttons und Slider benötige. Game Develop ist einfach zu unflexibel, war zumindest mein erster Eindruck.

Für pyglet gibt es kein geeignetes GUI. Bei pygame gibt es zumindest 2 die in Frage kommen.

Also die Rooms sind wohl Räume in einem RPG, die man durchgehen kann, darunter auch Menues. Mich erinnert das eher an eine State Engine, ähnlich wie bei Cocos die Scenes. Beispiel hier

[BlackJack]

@waschecht: Ich dachte an kein konkretes Rahmenwerk. Kenne keines für `pygame`. Wie wichtig ist denn überhaupt Grafik bei Dir? Ein Wirtschaftsspiel aus den 80/90ern könnte man vielleicht ja auch mit einem normalen GUI-Toolkit umsetzen. Bilder, Tabellen, Buttons, und Slider gibt es da einfacher als bei `pygame`.

[waschecht]

Graphik ist eher nebensächlich, zB Animationen hab ich erstmal gar nicht auf dem Plan, zeichnen werde ich wohl bei Graphen wie zB GuV über Zeit. Nach meiner Vorstellung sollte es momentan mausgesteuert sein und daher würde ich - wenn man es in Anlehnung an HTML so nennen will - auch lieber "Graphik-Links" statt "Text-Links" haben.
Paar Bilder sollten schon vorhanden sein, für einen gewissen Flair. Aber alles statische Bilder.

Bevor ich pygame ins Visier nahm, hab ich auch wxwidgets und tkinter angesehen. Da kam aber nicht so der Flair auf. Bei pygame würde ich ocempgui nutzen, die lief bei mir gut, wobei ich zugegeben nur die Beispiele angesehen habe und passendes auf meine Bedürfnisse zugschnitten habe. Also Vorauswahl.

Das Entscheidende wäre für mich, dass ich ein halbwegs brauchbares Grundgerüst habe, dass einfach erweiterbar ist. Also funktionierndes Gerüst, an das einfach neue Menues und Funktionen drangepappt werden können. Idealerweise neuen Event anmelden, View programmieren und dann das Modell dazu.
Ein "Menüsystem" hab ich textbasiert mit Python gemacht, da gerät aber der Code insgesamt ziemlich aus den Fugen und wird unübersichtlich (trotz Splittung in verschiedene Dateien). Weil ich eben auch eher prozedural programmiert habe.

Ich denke, ich werde das mit der State-Engine nochmal genauer anschauen. Im Moment fehlt mir glaube ich noch der Gesamtüberblick.


Kann man denn mit vorhandenen PythonGUIs einfach imagebuttons erzeugen? Das wäre eine echte Alternative.

[BlackJack]

@waschecht: Ich habe das Gefühl Du verzettelst Dich zu sehr in GUI/Architektur-Fragen. Kann aber auch daran liegen, dass Du grundsätzlich anders an die Sache herangehst als ich das tun würde. Die Reihenfolge Event, View, Modell finde ich komisch. Bei mir käme zuerst das Spiel und dann erst die GUI-Schicht darüber, und das möglichst getrennt, so dass man die GUI auch austauschen kann.

Tkinter finde ich ganz nett aber sehr eingeschränkt was die Widgets angeht. Und mit wxWidgets hast Du Dir nicht gerade das modernste Toolkit rausgesucht.

[Hyperion]

Also ich halte es für die größte Schwäche von `pygame`, dass es eben keine GUI gibt. Man kann damit natürlich Spiele entwickeln, aber speziell bei GUI lastigen Dingen, wie es nach meinem Verständnis alle möglichen Aufbauspiele sind, muss man letztlich ein komplettes GUI-Framework in pygame nach implementieren. Iirc gab es doch mal jemanden von der Regulars hier, der ein GUI-Toolkit auf PyGame-Basis umsetzen wollte?

Ich würde Dir für eine "sexy" Oberfläche ja Qt mit QML empfehlen.

[Leonidas]

Iirc gab es doch mal jemanden von der Regulars hier, der ein GUI-Toolkit auf PyGame-Basis umsetzen wollte?

Das gibts doch wie Sand am Meer, weil das jeder erstmal implementiert, bevor er feststellt, wie archaisch und schlecht maintained Pygame ist und es in einem halbfertigen Zustand verwirft.

[waschecht]

@waschecht: Ich habe das Gefühl Du verzettelst Dich zu sehr in GUI/Architektur-Fragen. Kann aber auch daran liegen, dass Du grundsätzlich anders an die Sache herangehst als ich das tun würde. Die Reihenfolge Event, View, Modell finde ich komisch. Bei mir käme zuerst das Spiel und dann erst die GUI-Schicht darüber, und das möglichst getrennt, so dass man die GUI auch austauschen kann.

Mhh, also ich hab früher einiges mit HTML und PHP gemacht. Kann sein, dass ich daher ziemlich optisch orientiert bin. Vielleicht habe ich das mit der Reihenfolge auch etwas komisch ausgedrückt.
Irgendwie möchte ich schon sehen, was das Modell ausspuckt, daher erst der View. Eigentlich wäre es aber wohl parallel erarbeitet.

Was das Spiel angeht, habe ich so einiges vorgearbeitet. Also Modelle erarbeitet und in Excel ausprobiert. Generelle Menüstruktur festgelegt. Sowie bereits Vorarbeiten zu Inhalten. Sogar schon ein Buttonset erstellt.
Im Moment scheitert es tatsächlich an der GUI/Architektur. Und natürlich an meiner völligen Unerfahrenheit mit Python.

archaisch und schlecht maintained Pygame ist

Du würdest von Pygame abraten?

[JörnS]

Mein Tipp wäre Panda3D, damit kann man auch 2D super einfach nutzen, und wenn einem das dann doch zu langweilig ist, kann man dann zu 3D wechseln...

http://images.wikia.com/pyrdacor/de/ima ... _scrot.png

Ein Screenshot aus meinem kleinen Projekt, bzw dem Leveleditor dafür. Im Hintergrund der Editor an und für sich, links ein kleines Tkinter-Fenster und rechts, auf dem 2D-Bereich gezeichnet, eine Listbox zum auswählen der Tiles aus dem die Level aufgebaut sind - und die Listbox-Klasse ist mit wenigen Zeilen selber programmiert. Es gibt dann noch DirectGUI für Buttons etc, das sieht aber etwas dröge aus. librocket wird jetzt auch unterstützt, sieht super aus - ist aber nicht mein persönlicher Fall. Werde ich mir trotzdem noch mal genauer ansehen.

EDIT: Da der Screenshot so groß ist, hab ich aus dem IMG lieber einen URL-Tag gemacht.

[Hyperion]

Mein Tipp wäre Panda3D, damit kann man auch 2D super einfach nutzen, und wenn einem das dann doch zu langweilig ist, kann man dann zu 3D wechseln...

Toller Tipp, wenn es nicht um ein Spiel mit komplexen UI-Elementen ginge Diese müsste er doch dann genauso neu schreiben, wie bei pygame auch...

Ich würde ja immer noch für Qt mit QML plädieren. Der QML-Teil sollte fix und flexibel genug für alles sein; für reine Standard-UI-Menüs kann man dann immer noch die "alten" QWidgets nehmen.