Pygame: Rechteck mit Hitbox erstellen?
Angenommen, ich habe so ein Programm:
Der Spieler kann sich auf der X- und Y-Koordinate frei bewegen. Naja, nicht komplett frei. Der Spieler muss immer vollständig auf dem Screen sein. Dazu habe ich eingestellt, dass die Velocity (=Geschwindigkeit) nur die Position des Spielers verändert, wenn sich die Koordinaten des Spielers, und vorallem der player.rect (Rechteck), sich auf dem Screen befinden. Wenn er also außerhalb war, wurde die Geschwindigkeit zwar berechnet, hatte aber keine Auswirkungen auf seine Koordinaten und somit bewegte er sich einfach nicht mehr weiter. Hierbei ist wichtig: Die beiden Koordinaten (x & y) sind voneinander unabhängig! Wenn sich der Spieler also beispielsweise links am Rand befindet, kann er sich zwar nicht mehr nach links bewegen, jedoch kann er immernoch nach unten und oben gehen (X-Achse).
Soweit, so gut. Jetzt will das gleiche machen, nur für ein anderes pygame.rect (Rechteck). Hierbei ist der zentrale Unterschied, dass sich der Spieler hier nicht, wie beim Screen, nicht aus dem Bereich bewegen darf, sondern er darf hier nicht den Bereich betreten. Dafür gibt es ja die Funktion pygame.rect.colliderect(). Die sagt, ob sich die beiden pygame.rect's überschneiden, also kollidieren. Das Problem jedoch, ich komme nicht auf die Idee, wie ich die Koordinaten voneinder unabhängig machen kann.
Angenommen, mein Spieler würde sich jetzt hier befinden:
Wie soll ich im Programm klarmachen, ob der Spieler von oben oder von links kommt? Und überhaupt, woher soll ich mir das klarmachen? Das kann man ja nicht sagen, woher er gekommen ist, er könnte ja auch von rechts gekommen sein. Diese Methode, wie beim screen würde hier also nicht funktionieren.
Hat jemand eine Idee, wie ich das sonst machen könnte? Bringen mir die Velocities vielleicht etwas?
Falls jemand eine Idee hat: Ich brauche jetzt nicht unbedingte einen Code, ich bräuchte nur ein Konzept, was ich dann auch selber umsetzen kann.
Danke im Vorraus!
1 Antwort
Du wirst dafür entweder kleinere Zeitschritte verwenden müssen (sodass sich der Spieler garnicht erst so weit bewegen kann in einem zeitschritt) oder indirekte Berechnungsverfahren nutzen müssen (die quasi den Pfad des Objekts vorausberechnen und auf diesem Kollisionen bestimmen und entsprechend schon bei der bewegung diesen stoppen; Quasi wie wenn du prüfst, ob sich zwei Geraden schneiden, nur eben auf bewegten Flächen statt auf Geraden).
Letzteres wäre die stabilere Möglichkeit.
Normalerweise würde man dort wohl eher prüfen, ob sich primitive schneiden werden (also hier die Randlinien). Das funktioniert bei geschlossenen Objekten.
