vimy hat geschrieben:pütone könntest du mir vielleicht erklären wie du da smit den "zahlen in den räumen" umgesetzt hast?.. also das der wirklich nur linien löscht die verschiedene räume von einander trennen? ich hab zwar ein programm was linien löscht geschrieben..aber ein wirkliches labyrinth kommt nicht dabei raus... weil das unterprogramm halt belibiege linien löscht (außer die außenwande)
vimy hat geschrieben:pütone könntest du mir vielleicht erklären wie du da smit den "zahlen in den räumen" umgesetzt hast?.. also das der wirklich nur linien löscht die verschiedene räume von einander trennen? ich hab zwar ein programm was linien löscht geschrieben..aber ein wirkliches labyrinth kommt nicht dabei raus... weil das unterprogramm halt belibiege linien löscht (außer die außenwande)
Schon deiner Formulierung kann man entnehmen, dass du immer noch keine Trennung von Programmlogik und graphischer Darstellung vorgenommen hast.
Das Problem ist doch nicht, irgendwelche Linien zu löschen, sondern sich zu überlegen, in welcher Art von Datenstruktur man die Informationen - Räume und Trennwände - sinnvollerweise speichert und wie man das Entfernen von Trennwänden rein logisch umsetzt.
Daraus dann später Linien zu machen, die wieder entfernt werden, ist der leichteste Teil der ganzen Arbeit.
Nach einer ganzen Zeit des Experimentierens mit Papier und Buntstiften (hast du sowas auch gemacht? Wenn nein: Tu das!) habe ich mich dafür entschieden, mit Trennwand-Objekten zu arbeiten.
Erst wollte ich mit Raum-Objekten arbeiten, aber das schien mir weniger günstig, weil jeder Raum unterschiedliche viele Trennwände haben kann und mir das komplizierter in der Umsetzung erschien.
Anstelle von Objekten könnte man aber auch einfach eine Liste oder ein Dictionary verwenden, weil die Trennwand-Objekte nur Datenattribute haben.
Jedes dieser Objekte erhält eine fortlaufende Nummer (ID) und die Information über beiden Räume, die durch diese Wand getrennt werden; die Räume sind ebenfalls durchnummeriert. Aus der ID einer Trennwand lässt sich ermitteln, ob es eine senkrechte oder waagerechte Trennwand ist und an welcher Stelle im (graphischen) Labyrinth sie positioniert ist. Das ist nicht ganz so einfach, und lässt sich durch - im Prinzip redundante - Informationen über die Lage und Ausrichtung auch einfacher gestalten.
Alle Trennwandobjekte werden nach der Erzeugung in einer Liste gehalten, aus der dann zufällig jeweils eine Trennwand ausgewählt und auch entfernt wird (das geht z.B. mit shuffle() und pop(), aber auch unter Verzicht auf diese beiden Funktionen, falls du sie nicht einsetzen willst/kannst/darfst).
Durch das Entfernen der Trennwand fällt ja ein Raum weg (der mit der höheren Nummer). Da es noch andere Trennwände geben kann, die an den selben Raum (der wegfällt) angrenzen, muss man für diese Trennwandobjekte diese Raumnummer auch auf die niedrigere Raumnummer des neu entstandenen Raums setzen.
Anschließend muss man noch prüfen, ob dadurch eine Trennwand entstanden ist, die nicht mehr zwei, sondern faktisch nur noch einen Raum (= gleiche Raumnummer) voneinander trennt. Dann ist das eine der Trennwände, die bis zum Schluss stehen bleiben. Da sie nicht entfernt werden soll, muss sie aus der Liste der noch zum Entfernen vorgesehenen Trennwände entfernt werden.
Das ist nicht alles, aber ein wichtiger Teil der Programmlogik.
Ich habe auf diese Weise eine neue Liste der zufällig entfernten Trennwände (ohne die unentfernbaren Trennwände) erstellt, womit das Problem eigentlich gelöst ist.
Die graphische Umsetzung ist dann einfach: Rohlabyrinth mit allen Trennwänden zeichnen und dann die in der Liste gesammelten entfernen.
Auch die Datenspeicherung ist dann kein Problem mehr: Wenn du es mit pickle() nicht kannst/darfst/willst, dann genügt es auch, die Anzahl der Zeilen und Spalten des Labyrinths sowie die IDs der zu entfernenden Trennwände in einer sequentiellen Datei zu speichern. Daraus lässt sich das Labyrinth dann wieder eindeutig rekonstruieren.
