Ich hoffe ich habe mich klar ausgedrückt und man versteht mein Anliegen. Danke.
Nicht so richtig
Wenn ich dich richtig verstehe ist deine Simulation von der Reihenfolge der einzelnen Aufrufe abhängig. Was wäre wenn du die Objekte welche ihr Update noch nicht ausführen können auf eine extra Liste packst? Oder das Update für die Zellen ausführst welche das Update der aktuellen Zelle behindern. Dazu kannst du ja zusätzlich mit einer Closedlist arbeiten. Ansonsten lieferst du ja selbst eine Lösung mit. Was spricht dagegen?
Deine eigentliche Frage kann ich dir nicht beantworten. Wie die Reihenfolge ist, bzw vermutlich eher wie sie sein sollte weiß ich nicht. Das müsstest du ja selbst wissen da du weißt was deine Simulation tun soll und wie sie sich richtig verhält.
Die Tiles (Particle nenn ich sie auch) sollen sich ähnlich wie so ein BoulderDash verhalten. Aber es gibt einige Fallen hier. Und BoulderDash müsste die Update-Schritte strikt trennen. Also erst das fallen der Boulder (beginnend alle updaten von links unten vom Grid). Dann erst die Boulders updaten die nach rechts abdriften. Dann kommen die Gegner Tiles. Und etc.
Aber ich will dass ich jegliches Verhalten simulieren kann. Nicht nur die paar vordefinierten.
Bei BoulderDash bekommen die Boulders ja ein Attribut "isFalling", so muss man ja gucken ob der darunter auch fällt (das ist dann nicht mehr so relevant mit der Tiefensuche wenn sie wieso nur nach unten fallen können - dann fängt man unten links auf dem grid an zu updaten). Der obere darf sich nicht dann nach Rechts bewegen anhand der Logic des Tiles, sondern mitfallen natürlich. Das funktioniert ja nur wenn die Reichenfolge richtig ist. Und wenn die Regeln nicht so einfach sind, wie zum Beispiel, dass die Gravity bei einigen Tiles sie nach oben bewegt, anstatt nach unten, so kann man die updates ja nicht mehr von unten links am grid anfangen lassen.
Im Grunde könnte man auch die updatephasen (mehrere pässe) vielleich machen (also erstmal gucken ob alle Tiles fallen können und sie fallen lassen, und dann erst deren anderen Verhalten ausführen im zweiten Pass). Dann priorisiert man schon dass Gravity vorrang hat. Aber im Grunde drehe ich mich im Kreis und die Reihenfolge ist wichtig. Um eine Tiefensuche komme ich ja garnicht herum oder?
Ich müsste erstmal gucken ob der Tile in der sich das andere Tile bewegt sich mit in die selbe Richtung bewegt oder schon im Stillstand ist (eine Hindernis erreicht hat und daher als Bewegungslos gilt (isFalling = false - oder eher isMoving = false)). Aber auch hier müsste ich eine Tiefensuche machen. Im Grunde komme ich doch garnicht um eine Tiefensuche herum oder? Damit ich bei den enden Anfange zu updaten. Vielleicht in der Richtung in der die Tiles sich bewegen. Daher brauche ich ein Attribut (Vector2 movedir]) die die Richtung des Falls beschreiben, pro updateschritt. Und dieses Attribute lenkt dann die Tiefensuche.
Gibt es irgendwelche Links wo man sowas nachlesen kann wie man das macht. Sonst muss ich eine eigene Lösung anstreben obwohl es vielleicht sogar schon bewehrte und nicht so rechenintesive Lösungen gibt. Im Grunde muss ich eine Tiefensuche machen ständig. Das kostet Leistung.
Ich glaube ich denke zu kompliziert hier. Boulder Dash ist hingegen kein wirkliches gutes Beispiel glaube ich. Hier wird denke ich auch ein State gemacht, wo "isFalling" relevant ist. Aber meine Tiles sollen jegliches Verhalten annehmen können und auch die Richtung der Gravity kann sich unterscheiden pro Tile. Können also auch nach oben sich bewegen.
Meine Simulaton hat eher Attribute wie "Gravity (Schwerkraft)" und "Density (Dichte)".