Leg-das-Rohr-Minispiel

den füllstand als wert hätte ich halt genutzt um quasi den stand der dinge pro feld abzufragen, damit nicht jedes mal ein neues Feld gechekct wird, sondern nur alle X schritte je nach wasserstand halt. 6 war jetzt ein reines Beispiel

Okay, muss ich mal drüber nachdenken.

Zur Zeit habe ich die eine Variante, dass alle 25 Felder der Reihe nach durchgecheckt werden sollen, egal, ob bereits Wasser drin ist oder nicht. Die Felder, die "belegt" sind geben ein Statement zurück und könnten dann von der Suche ausgeklammert werden. Das Problem ist ja, dass der Spieler bereits existierende, funktionierende (aber noch leere) Verbindungen wieder trennen kann, wenn er eine bessere Lösung findet oder für die Fertigstellung ihm Rohrteile fehlen, so dass er schnell einen anderen Weg basteln muss.

Die aussichtsreichere Variante ist aber, nur die verbundenen Verbindungen zu berücksichtigen, dass sich der Algorithmus also von jedem verbundenen Feld bis zum nächsten vorarbeitet, bis er stoppt oder das Spiel gewonnen ist. Das hätte den Vorteil, dass ich nur die geglückten Verbindungen checken muss und dass ich sofort eine Fließrichtung hätte, denn ich starte die Suche ja links oben, das heißt die Richtung wäre im ersten Feld nur "nach rechts" oder "nach unten". Außerdem müsste ich dann nur drei Varianten pro Feld abklären (jede Verbindung erlaubt drei weitere) - bis auf den Spielfeldrand natürlich.

Aber egal, wie ich es mache - noch habe ich ein Brett vorm Kopf. Ich denke zuallererst linear, das heißt, ich schreibe erstmal dutzende von If-Abfragen hintereinander (so wie ich das Spiel spielen würde). Erst danach denke ich darüber nach, ob man einige zusammenlegen kann...

Ich bin zu doof, eine Schleife zu binden. Ich weiß einfach nicht, was ich mit was aufrufen muss, um eine rekursive Abfrage zu machen. Ich glaube, ich mache mal ein paar Tage Pause...

Hab mich mit Breitensuche, Tiefensuche, A*, Labyrinthen und allem möglichen Zeugs rumgeschlagen, aber ich deshalb weiß immer noch nicht, wie ich abfragen könnte, welches Rohr mit welchem verbunden ist. Im Gegenteil: mir schwirrt der Kopf. Ist mir  alles zu theoretisch, was ich im Netz finde. Es gibt zwar Pseudo-Algorithmen (meist in einer Art C++ oder Phython geschrieben), die mir eine Prinzipstruktur veranschaulichen sollen, aber wie ich "Knoten aus der Agenda lösche" oder "Kindelemente gleicher Wertigkeit extrahiere" ist mir alles zu sehr Fachdeutsch...

Das einzige, was bis jetzt dabei rausgekommen ist, ist eine bis jetzt fünfmal verschachtelte if-Abfrage, die checkt, ob an jedem geschlossenen Rohrende genau die drei passenden Teile angesetzt sind, die eine gültige Weiterführung bilden (jedes Rohrende hat ja drei Anschlussmöglichkeiten, die theoretisch weiterführen - bis auf die Ausnahme-Fälle, wo das Rohr das Spielfeld verlässt). Damit habe ich aber gerade mal fünf Felder abgefragt.

Das gilt außerdem nur, wenn ich vorher die Fließrichtung kenne - sonst gibt es nämlich immer sechs Möglichkeiten, die ich abfragen muss. Das kann aber nicht die Lösung sein, denn die Verzweigungsvariationen sind ja am Ende ziemlich umfangreich (wenn auch nicht unendlich), so dass ich irgendwann tausend Abfragen habe. Wo muss jetzt eine Schleife hin...?

Ich dachte, es wäre damit getan, einfach alle Nachbarn eines Feldes (mit +1, -1, +5, -5) auf geschlossene Verbindung zu testen und bei verbundenen Feldern irgendwie einen Schritt nur in die richtige Richtung weiterzurücken, bis ich irgendwann bei Feld 25 angekommen bin (oder nicht). Aber das ist Theorie...

Hier merke ich deutlich, dass ich kein Programmierer bin und die Logik nicht umsetzen kann. Ich brauche sozusagen ein Tutorial, das mir zeigt, wie man solche Probleme überhaupt angeht und sie Schritt für Schritt löst.

Eigentlich nimmt mir der Spieler die Such-Arbeit ab. Es handelt sich ja um keine Labyrinth-Suche, denn es gibt anfangs gar kein Labyrinth!

Da das Feld 1 nur mit zwei Rohrelementen sinnvoll weiterführt, kann ich die Suche nach dem nächsten Feldelement und nach der Fließrichtung in die Wassereinlauf-Animation legen.

Liegt im ersten Feld z.B. ein waagrechtes Rohr, kann der Pfad ja nur nach rechts weitergehen und zwar mit der Fließrichtung nach rechts. Ich frage also den Typ von Feld 1 ab. Setze ich nun die Einlaufanimation des ersten Feldes fest (Einlauf von links nach rechts), kann ich dort im letzten Frame ein Script starten, das mir die weiterführenden drei Möglichkeiten abfragt. Es geht nur nach rechts, nach rechts oben oder nach rechts unten weiter. Trifft eine der drei Möglichkeiten zu, liegt auch automatisch die Fließrichtung des 2. Feldes fest. Gut, nach oben ist zwar eine Sackgasse, dennoch fließt ja Wasser ein; ich muss die Einlaufanimation also trotzdem durchführen. Das heißt, ich muss auch jedesmal abfragen, ob der Rand erreicht wurde.

Im Moment probiere ich rum, ob ich mit nur EINEM Script auskomme, das automatisch alle Möglichkeiten abfragt, egal, in welchem Feld ich mich gerade befinde. Das ist für mich knifflig... Ich weiß noch nicht, ob es sinnvoller ist, Einzelanimationen zu verwenden oder alles in eine zu packen. Im Moment kriege ich es noch nicht hin, dass die Animation auf einem Frame stoppt und stehenbleibt. Da muss dann wohl eine Art Unendlich-Schleife rein... aber bislang friert der Player immer ein... Einfacher ist es, auf eine Einzel-Animation mit gefüllten Rohr zu wechseln, die unendlich abläuft. Wenn ich das mit Lua nicht hinkriege, muss ich es eben so machen...

Erneute kurze Zwischenbilanz:

offenbar funktioniert die setAnimFrames-Funktion nur mit unendlichen Animationen.

Ich habe alle Wasseranimationen hintereinander in eine Animation gelegt und wollte nun  diejenigen Frames abspielen lassen, die ich jeweils brauche. Das klappt nur, wenn ich bei Frame 1 anfange, also 1-12, 1-24, 1-48... Manchmal gehtes auch noch beim zweiten oder dritten Frame (also 3-12, 3-24), aber beim vierten läuft die Animation schon nicht mehr ab - 4-12, 4-24 und alle folgenden usw. starten also schon nicht. Einen Ausschnitt von z.B. Frame 36-48 (was einem Einlauf in ein gerades Rohr von links entspricht) kann ich deshalb nicht abspielen.

Die Animationen dürfen logischerweise nur einmal durchlaufen, danach werden sie auf eine Standbildanimation des gefüllten Rohres gelinkt. Stelle ich sie auf unendlich, funktioniert es zwar, aber das ist natürlich Blödsinn.

Ich habe versucht, mit Sebastians Tipp die Animation vorher zu stoppen, damit sie immer vom Anfang starten kann, aber das brachte auch keinen Erfolg. Ich habe alle Schreibweisen versucht, die mir einfielen.

Ich befürchte, dass ich doch die Einlaufanimationen alle einzeln anlegen muss. Eine Animation, bestehend aus sechs Frames mit sechs vollen Rohrtypen, funktioniert hingegen, da es sich um unendliche Standbilder handelt. Ich kann dort z.B. Frame 4 aufrufen und unendlich abspielen lassen.

Ich muss also noch 325 Animationen einpflegen, umbenennen  und auf die Objekt-Position schieben... Oder?

das ist sicherlich ein Weg. Zumindest musst du dich dann nicht mit FirstFrame/LastFrame gescripte rumärgern... 

Mit der manuellen Methode im Editor bin ich auf dem richtigen Weg. Allerdings tauchen hier und da merkwürdige Erscheinungen auf; das kann aber auch daran liegen, dass man, nachdem man 200 Ziffern eingegeben hat, irgendwie unkonzentriert wird und Zahlendreher einbaut...

Bis jetzt läuft die Flüssigkeit in 80% der Fälle reibungslos durch, manchmal wird ein Feld zwischendurch vergessen und ich muss dann suchen, wo der Schreibfehler liegt...   Es ist nur tierisch viel einzutippen (und immer dasselbe....).

Jetzt juckt schon wieder der Übermut und ich könnte doch zusätzlich einige Sprengfallen einbauen...

Bilanz:

die Hälfte der 25 Felder habe ich angelegt, aber die Trefferquote beim Wassereinlauf ist nicht 100%. Manchmal stoppt es nach dem dritten oder vierten Feld (Im log steht dann merkwürdigerweise "Feldnummer = 0").  An der Logik liegt es offenbar nicht, dort müsste z.B. Nummer 10 liegen.

Nun habe ich bereits in früheren Spielen bemerkt, dass das Aufeinanderfolgen von Nicht-unendlichen Animationen (jeweils aufgerufen durch den letzten Frame) nicht optimal funktioniert. Vom gesunden Menschenverstand her müsste es ja sinnvoll sein, die Einlaufanimation des nächsten Feldes aus dem letzten Frame der vorherigen Animation zu starten, wenn abgefragt wird, ob diese möglich ist - andernfalls läuft eben keine Animation ab.

Hierbei ist mir aufgefallen, dass wieder ein "Stoppen" oder "Entladen" nötig ist, obwohl ich mir nicht erklären kann, wozu das notwendig ist. Wenn eine Animation, die nur einmal durchlaufen soll, einmal durchgelaufen ist, sollte ja nichts weiter passieren. Und wenn ich 20 verschiedene Animationen starte, sollten die doch - je nach Startzeitpunkt - einfach bis zum Ende ablaufen, oder? Kann Visionaire nur eine Animation zur Zeit verwalten und ich muss deshalb die anderen Animationen entfernen bzw. anhalten?

Da ich alle Abfragen in einem Script habe und der Scriptaufruf mit den Animationen mitkopiert wurde: kann es sein, dass Visionaire dieses Script zwar sichtbar kopiert, aber intern nicht verlinkt hat? Ich kenne das aus den Aktionen: ändere ich einen Namen von Werten oder Objekten, so wird der Name im Auswahlmenü zwar aktualisiert angezeigt, ich muss aber in das Aufklappmenü und das Objekt nochmals explizit auswählen, damit es "richtig" aktualisiert ist. Ansonsten wird es beim nächsten Mal zu einem "leer"-Feld.

da scheint noch etwas anderes bei dir vorzugehen, denn animationen lassen sich unabhängig voneinander starten/stoppen.

Ja, ich glaube, der Fehler lag diesmal bei mir. Ich habe ungewollt einen rekursiven Aufruf gestartet. Allerdings helfen auch meine logischen Überlegungen im Moment nicht weiter, wie ich das umgehen könnte. Benutze ich nämlich "break", um eine Bedingung abzubrechen, wenn sie erfüllt wurde, startet das Ganze gar nicht mehr. Ich brauche irgendwas, um aus einer Wenn-dann-Bedingung auszusteigen. In Basic hätte ich jetzt "goto" verwendet, aber soetwas gibt es ja in Lua nicht, oder? Außerdem hat es ja den verruchten Ruf des unsauberen Programmierens...

ein break in Lua gibt es nur in Schleifen (for, while, repeat) nud kann (darf) nicht außerhalb von solchen genutzt werden.