Frage zu Pygame & Key-Listener

[DKKA]

Hallo zusammen,

Ich habe eine Frage bezüglich des Key-Listeners von Pygame.
Mit folgendem Code kann man den Delay der Tasten einstellen. Man kann somit entscheiden ob der Listener hören soll, wenn eine Taste gedrückt bleibt.

Code: Alles auswählen

pygame.key.set_repeat(1, 30)

Nun, wie löst ihr diese Problem, wenn man verschieden Tasten habt, die unterschiedlich funktionieren. Mittels einem Boolean?
Und wie macht ihr das, wenn ihr z.B. ein Menü habt, dass völlig andere Commands ausführen soll, als der Key-Listener im Spiel. Lohnt es sich dabei 2 verschiedene Key-Listener zu erstellen wegen der Übersicht?

Vielen Dank!

[BlackJack]

@DKKA: Um festzustellen ob eine Taste gedrückt bleibt braucht man kein `set_repeat()`. Da sowohl das drücken als auch das loslassen einer Taste ein Ereignis auslöst, ist in der Zeit zwischen diesen Ereignissen offensichtlich gedrückt.

Da das Spiel und das Menü hoffentlich in verschiedenen Funktionen stecken, beantwortet sich die letzte Frage irgendwie von selbst.

[DKKA]

@DKKA: Um festzustellen ob eine Taste gedrückt bleibt braucht man kein `set_repeat()`. Da sowohl das drücken als auch das loslassen einer Taste ein Ereignis auslöst, ist in der Zeit zwischen diesen Ereignissen offensichtlich gedrückt.

Da das Spiel und das Menü hoffentlich in verschiedenen Funktionen stecken, beantwortet sich die letzte Frage irgendwie von selbst.

Das heisst, ich soll 2mal MVC machen?

[BlackJack]

@DKKA: LOL. Von einem extrem ins nächste…

[DKKA]

@DKKA: LOL. Von einem extrem ins nächste…

Hab nun folgende Struktur umgesetzt:

Code: Alles auswählen

while running:
            if menu:
                        if not self.menuControlEvents():
                               return
                        self.menuViewEvents()
            else:
                        if not self.ControlEvents():
                               return
                        self.viewEvents()
            self.model()

Wäre das ne sinnvolle Lösung?

[BlackJack]

@DKKA: Sieht nicht so aus. Zudem entspricht weder die Einrückung noch die Namensschreibweise dem Style Guide. Das sieht alles zusammen eher so aus als wenn Du mit Java glücklicher wirst.

[jerch]

MVC? Java? Diese Hauptschleife? Bahnhof?

@DKKA:
Die Tastenwiederholung für "gedrückt" vs. "nicht gedrückt" zu nutzen, ist in Gegenwart von "down" und "up" events Unsinn und Missbrauch der Wiederholung. Warum nimmst du nicht einfach "up" und "down", um das zu entscheiden?
Deine Schleife - was soll das sein? Die Hauptschleife des Spiels? Mit etwas mehr Kontext kann man Dir vllt besser helfen. Was Du da gepostet hast, ist weder lauffähig noch ansatzweise nachvollziehbar (`return` z.B. muss in eine Funktion).

[DKKA]

@DKKA: Sieht nicht so aus. Zudem entspricht weder die Einrückung noch die Namensschreibweise dem Style Guide. Das sieht alles zusammen eher so aus als wenn Du mit Java glücklicher wirst.

Es hat mir beim kopieren die Tabs rausgelöscht. Und ich komme vom C und Haskell programmieren. Aber verstehe nicht, warum das wichtig sein sollte.

[BlackJack]

@DKKA: Das ist wichtig wenn Du Deinen Quelltext veröffentlichst. Also zum Beispiel auch hier um Fragen zu stellen. Einrücken ist vier Leerzeichen pro Ebene. Wer sich daran nicht hält bekommt potentiell weniger Hilfe weil ein Helfer dann nämlich unnötige Hürden zu überwinden hat den Code auszuprobieren oder Fragmente durch eigenen Quelltext zu ergänzen. Nicht jeder hat Lust und Zeit erst mal die Einrückung anzupassen, entweder in dem Quelltext oder im eigenen Editor.

Die Namensschreibweise ist wichtig weil es Schreib- und Lesegewohnheiten gibt. mixedCase für Methodennamen geht gerade noch so, aber spätestens wenn man anfängt gegen die Konventionen von Klassen- und Konstantennamen zu verstossen wird es ein echtes Problem, weil diese Namensschreibweisen bestimmte Erwartungen an die Werte beim Leser wecken.

Würdest Du in Haskell auf die Idee kommen namen_mit_unterstrichen zu verwenden? Wenn nicht, dann solltest Du in Python auch keine mixedCaseNamen verwenden. Und schon gar keine Namen die mit einem Grossbuchstaben anfangen aber keinen Datentyp (Klasse) benennen. Das würde in Haskell sogar als Fehlermeldung vom Compiler oder Interpreter auf die Nase fallen.