Das deutsche Python-Forum

Heipa mal wieder,

"arbeite" gerade an einem Bomberman Klon:
http://www.directupload.net/file/d/351 ... rn_png.htm

Grosse Mühe bereitet mir der Algorithmus bzgl. Tilecollision. An sich ja keine grosse Sache hab ich gedacht, aber das Problem ist, dass im Originalspiel der Char sich "um die Tiles herumbewegt". Ein Beispiel: Man läuft nach rechts und steht an einem Teil an. Dann wird der Char nach oben oder unten ausweichen, je nach dem, welcher Zwischenraum näher ist, wo er dann einfach weiter nach rechts laufen kann.

Das an sich ginge evtl. auch noch, aber es kommt noch übler..:

Im Original (sagen wir mal Bomberman II, SNES) läuft der Char, obwohl sein Sprite offenbar gleich gross ist wie die Tiles (16 x 16), zum Teil diagonal um die Tiles herum; er "schneidet die Kurve" sozusagen. Man kann dies gut beobachten (evtl. kurz in Juuutuuub ein Video zum Game anschauen).

...und es kommt NOCH übler...

Wenn man z.Bsp. RECHTS-UNTEN drückt aufm Controller, läuft der Char im Original ein Tile nach unten, eins nach rechts, eins nach unten... er wechselt sozusagen immer die Laufrichtung, weil der Player ja offenbar "diagonal" laufen möchte.

Jemand eine Idee, wie man all dies umsetzen könnte? Mein Char soll nicht diagonal laufen, also "Kurven schneiden" können; aber er sollte smooth um die Teils herumgehen, wenn man den Zwischenraum nicht ganz sauber ansteuert, und er sollte auch "diagonal" durch die Tiles laufen wenn der Player 2 Richtungen drückt, wie oben beschrieben. Die Rect Collisionsmethode an sich ist kein Problem und ich reduziere die Zahl der zu prüfenden Tiles anhand der Position des Spielers (max. 4 Tiles pro Frame müssen gerechnet werden). Dann den Spieler bei einer Kollision wieder "aus dem Tile zu drücken" ist kein Probelm, das hatte ich schon oft, aber dies löst mein Problem natürlich noch nicht ganz.

@Henry Jones Jr.: Die Tilekollision in Bomberman ist sehr wahrscheinlich nicht an der Grafik ausgerichtet sondern an der internen repräsentation des Spielfeldes. Das sind ja alles Blöcke und die Spielfigur kann sich nicht wirklich frei bewegen sondern nur entweder horizontal oder vertikal von einem Tile zum nächsten. Und immer wenn man an so einer Grenze steht, kann man anhand der internen Karte des Levels testen ob das Feld betretbar ist oder nicht.

Das die Spielfigur „Kurven schneidet” oder tatsächlich diagonal laufen kann, kann ich jetzt weder aus meiner Erinnerung noch aus den ersten 20 Minten eines Videos von Bomberman Ⅱ auf dem SNES bestätigen.

Das mit dem abwechselnd rechts und runter ergibt sich doch eigentlich aus der Umgebung automatisch weil immer entweder rechts oder unten etwas im Weg ist und der Spielfigur dann jeweils nur runter oder rechts als Möglichkeit bleibt. Ansonsten kann man sich immer die letzte Bewegungsrichtung merken und wenn man zwei Wege zur Verfügung hat, den nehmen der nicht der letzten Richtung entspricht.

@ BlackJack: Danke, sowas hatte ich mir schon fast gedacht... Das Raster ist fix; aber dann sind da ja noch weitere Blocks die einen behindern können: Die Zerstörbaren und die Bombem selbst. Und bzgl. diagonal um die Ecken laufen: Hast Du einen SNES Emu? Jetzt ohne Scheiss, wenn man knapp an einem Tile ansteht und in Richtung Tile drückt, dann läuft der Char diagonal um das Teil rum; er "schneidet die Kurve". x und y wird gleichzeitig manipuliert.

Ich habe einfach ein wenig Mühe damit, wie das alles zusammenspielen soll, aber ich glaube ich implementiere es so, dass es IMMER so funktioniert, auch ohne fixes Raster. In meinem Kopf steht's schon fast; es müsste klappen. Aber es ist schon ein bisschen Brainfuckin'... ...find ich zumindest Aber genau diese Dinge sind es, die mich antreiben beim proggen und die mir Spass machen Ich will ja nicht einfach bestehenden Code in Python übersetzen, sondern schlussendlich mein Spiel mit meinen Regeln schreiben, so wie das Spiel meiner Meinung nach reagieren sollte. Das kommt schon noch; erst mal muss ich das Rect Zeugs fixen.

Danke!

@Henry Jones Jr.: Die zerstörbaren Blöcke und die Bomben sind doch auch an das feste Tile-Raster gebunden, die kann man also genau wie die Wände in der internen Karte vermerken und so ein Tile als nicht betretbar erkennen.

Mir half es, mich gedanklich von Pixelkoordinaten zu trennen. Stell dir das Spielfeld als Netz mit horizontal und vertikal verbundenen Knoten vor. Diese haben einen Abstand von genau 1. (float).

Auf die Knotenpunkte kann man nun Eigenschaften definieren wie "nicht betretbar" oder "Powerup" etc.

Die Akteure (Actors) können sich nun nur auf den Kanten (den Linien zwischen den Knoten) bewegen.

Wie das ganze nun aussieht (Grafik) ist erst der zweite (gedankliche) Schritt.

Wichtig ist m. E., dass man zwischen innerer und äußerer Repräsentation trennt. So kann man diese flexibel austauschen (z. B. statt pygame auf pyglet setzen, eine Netzwerkschicht dazwischen setzen, etc.).

Danke für den Tipp, bwbg!

Also konkret würde es dann so aussehen, dass ich nur vom Mittelpunkt des Char Rects ausgehe und diesen entlang der besagten "Kanten" bewege. Dann müsste mein Char nur wissen, auf welchem Knoten er gerade steht und müsste beim gehen lediglich prüfen, ob der nächste Knoten in Laufrichtung "besetzt" ist oder nicht oder was auch immer (eben Powerup etc.); habe ich Dich richtig verstanden vom Prinzip her?

Ich würde wirklich ein Tile-Modell aufbauen, welches *vollständig* unabhängig von PyGame und jeglicher Grafik. Alle logischen Entscheidungen, also wo kann man langgehen, wo etwas platzieren usw, würde ich ausschließlich auf diesem Modell berechnen. Die grafische Ausgabe sieht lediglich in dieser Tile-Welt nach und rendert dann stumpf die vorhandenen Objekte.

Da man Gegenstände auf Untergrund haben kann usw. braucht es vermutlich eine Liste von Listen von Listen

ähmmm... Mkay??

Bahnhof, sorry

Dann befürwortest Du also bwbg's Vorgehen oder habe ich ALLES komplett gar nicht verstanden?

Henry Jones Jr. hat geschrieben: Dann befürwortest Du also bwbg's Vorgehen oder habe ich ALLES komplett gar nicht verstanden?

So in der Richtung ja. Wobei ich eine Tile-Map eher als "Karo-Papier" ansehe.

Hier mal ein älterer Beitrag von mir. Damit solltest Du verstehen, was ich meine.