Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Ich will in Python(ohne Pygame)ein jump and run programmieren.
aus irgendeinem Grund ist die variable UP (zur Feststellung ob die Figur auf festem Boden steht oder nicht) immer auf 1.
kann mir jemand sagen was ich falsch gemacht habe?
Bei ereignisgesteuerter Programmierung darf es keine Schleifen geben, die längere Zeit arbeiten, ohne die Kontrolle an die Hauptschleife zurückzugeben. Um eine gewisse Frame-Rate einzuhalten, kann man bei Tk after benutzen; screen.update ist dagegen nicht so toll.
Um komplexere GUI Programme zu schreiben, braucht man eigentlich auch objektorientierte Programmierung, um den Zustand des Spiels zwischen den Methoden teilen zu können.
Wenn die if-Bedingung wahr ist, wird UP auf 1 gesetzt,
direkt danach wird gefragt, ob UP gleich 0 ist.
Kann diese Bedingung jemals wahr sein?
Außerdem stimmt da was mit der Einrückung nicht.
Sirius3 hat geschrieben: Mittwoch 19. September 2018, 14:38
Bei ereignisgesteuerter Programmierung darf es keine Schleifen geben, die längere Zeit arbeiten, ohne die Kontrolle an die Hauptschleife zurückzugeben. Um eine gewisse Frame-Rate einzuhalten, kann man bei Tk after benutzen; screen.update ist dagegen nicht so toll.
Um komplexere GUI Programme zu schreiben, braucht man eigentlich auch objektorientierte Programmierung, um den Zustand des Spiels zwischen den Methoden teilen zu können.
@Eleocraft: Noch ein paar Anmerkungen zum Quelltext:
Um das „screen.update ist dagegen nicht so toll“ von Sirius3 noch mal zu vertiefen: Du hast das in der `Player_sp()`-Funktion stehen, die aufgerufen wird wenn der Benutzer eine Taste drückt. Während die Funktion läuft, sorgt das `update()` dafür das weitere Tasteneingaben verarbeitet werden, was dazu führen kann, das wieder die `Player_sp()`-Funktion aufgerufen wird. Tk garantiert nicht das man während der Abarbeitung eines Handlers wieder Handler auslösen kann ohne das komische Sachen passieren. Das ist also ein Programmierfehler.
Sternchenimporte sind Böse™. Damit holst Du Dir bei `tkinter` mehr als 100 Namen in das aktuelle Modul, von denen Du nur einen Bruchteil benötigst. Es ist schwerer nachvollziehbar wo Namen eigentlich herkommen, und es besteht die Gefahr von Namenskollisionen.
Kommentare sind dazu da dem Leser mitzuteilen *warum* etwas gemacht wird. Sofern das nicht klar ist. Denn *was* gemacht wird, steht ja bereits als Code dort. Sollte man dem Code das nicht entnehmen können, dann kann das auch an schlechten Namen liegen, die unpassend oder nichtssagend sind.
Namen sollten nicht kryptisch abgekürzt werden, sondern dem Leser klar vermitteln was der Wert bedeutet. Also keine einbuchstabigen Namen (ausser der Gültigkeitsbereich ist sehr begrenzt („comprehension“-Syntax, ``lambda``-Ausdrücke)) oder es ist eine der gängigen Ausnahmen wie beispielsweise `i`, `j`, `k` für ganze Zahlen die als Schleifenlaufvariable und/oder Index verwendet werden, oder `x`, `y`, `z` für Koordinaten.
`c` für ein `Canvas`-Objekt geht eher nicht, das sollte man `canvas` nennen (wenn einem nichts passenderes einfällt). `himg` hiesse besser `hintergrund_image` oder um in einer Sprache zu bleiben `background_image`.
Namen durchnummerieren ist ein Warnzeichen das man sich entweder passendere Namen aussuchen sollte, oder die Einzelwerte in einer Datenstruktur besser aufgehoben wären.
An die üblichen Schreibweisen und Namenskonventionen sollte man sich auch halten. Das sind kleinbuchstaben_mit_unterstrichen für alles ausser Konstanten (KOMPLETT_GROSS) und Klassen (MixedCase). Funktionen und Methoden werden üblicherweise nach der Tätigkeit benannt die sie ausführen. `Player` ist keine Tätigkeit. Und `UP` ist keine Konstante. Zudem ist bei der Variablen nicht so wirklich leicht zu verstehen was die magischen Zahlwerte 0 und 1 die an sie gebunden werden, und 2 das wahrscheinlich auch an `UP` gebunden werden soll, aber nur an ein lokales `UP` in der `Player_sp()`-Funktion gebunden wird, eigentlich bedeuten sollen. Das wäre ein Fall wo man Konstanten für diese Zahlen definieren würde. Da die alle von einem Typ sind, am besten per `enum.Enum` um sie nicht mit anderen Zahlen verwechseln zu können. Da kann man dann sowohl den Zahlen einen sinnvollen Namen geben, als auch den Oberbegriff für diese drei Werte.
Wegen `UP` kommst Du übrigens IMHO hier schon nicht mehr ohne objektorientierte Programmierung aus, denn das muss aus der Funktion für den Sprung nach draussen kommuniziert werden, die ist aber eine Rückruffunktion.
„A life is like a garden. Perfect moments can be had, but not preserved, except in memory. LLAP” — Leonard Nimoy's last tweet.