Leg-das-Rohr-Minispiel

  • #1, by MachtnixSunday, 29. November 2015, 01:43 5 years ago
    Ich bastele gerade an meinem Rohrlegespiel. Ich möchte 25 Nullobjekte plazieren und diese zufallsgesteuert auf der Spielfläche verteilen. Dafür gibt es 25 fixe Positionen. Daran werden später die Rohrelemente angedockt (hier als sechs unterschiedliche Charaktere mit verschiedenen Animationen als Outfits ausgeführt).

    Wie es theoretisch geht, ist mir ungefähr klar: ich lege einen Zufallsgenerator an, erzeuge eine Matrix (Tabelle) von durcheinandergewürfelten 25 Integer-Zahlen, lasse die Indices durch zwei for-Schleifen laufen, die die 5x5 Werte den X- und Y-Positionen für 25 Positionswerte zuordnen, übergebe diese Werte an 25 Nullobjekte auf der Spielfeldkulisse (jetzt sind erst zwei da) und schwupps ordnen sich die zugeordneten Rohrteile an die zufälligen Nullobjekt-Positionen.
    Ganz einfach (*räusper*)... Leider habe ich NULL Ahnung von Lua. Quäle mich gerade durch einige Tutorials. Oder ist das überhaupt zu kompliziert gedacht?

    Wie kann ich Positionen nun auslesen und einlesen, um z.B. auch den Austausch der zwei Rohrelemente rechts zu bewerkstelligen? Es wird immer das zuletzt angeklickte mit dem Austauschmodul außerhalb vertauscht, dort liegt immer das letzte gebeamte. Dazu brauche ich immer die Position des zuletzt angeklickten Elements.

    Das Hauptproblem (wann erkennt das Programm das Rohr als korrekt verbunden?) habe ich nicht mal ansatzweise gelöst. Das kommt erst später, wenn ich es überhaupt schaffe...

    Hätte nie gedacht, dass es soooooo schwierig werden würde...

    Machtnix

    http://abload.de/thumb/leg-das-rohr-screengkrz3.gif

    Thread Captain

    1078 Posts


  • #2, by MachtnixMonday, 30. November 2015, 16:02 5 years ago
    Hallo.
    OK, wahrscheinlich war es für die meisten zu kompliziert. Nun gut, dann stelle ich nur eine einzige Frage: wie kann ich erfahren, an welchem Objekt ein Charakter positioniert ist?

    Bei Beginn der Szene gibt es ja den Ort, an dem der Charakter auf der Kulisse plaziert wird. Eine exakte Positionsangabe brauche ich eigentlich nicht. Es reicht also dieses Objekt, um auszusagen, wo der Charakter gerade steht oder hingehen soll. Meinetwegen darf es auch die ID sein, die in der VED-Datei angelegt wird. Wichtig ist nur, dass ich es als Wert weiterverarbeiten kann.

    In der Visionaire Data Structure steht sicher der richtige Befehl drin. Das ist aber alles höhere Mathematik für mich. Ich vermute, dass es CharacterDestinationObject ist. Was gibt mir dieser Befehl aus?

    Ich würde für die Abfrage nur einige Zeilen Lua brauchen. Fast alles andere funktioniert auch mit dem VisEditor. Allerdings ist das viel mühsamer, denn ich habe zig Dutzende von If-Abfragen, weil es keine Schleifen gibt und ich kaum Variablen an den wichtigen Stellen einsetzen kann. Ich muss quasi jedes Objekt jedesmal einzeln abfragen (und es sind 26). Nun gut, geht eben nicht anders. Der Editor ist für solche Minispiele nicht gemacht. Ich muss also zwischendurch ab und zu ein Lua-Script einbauen. Aber je weniger, desto besser...

    Ist das der richtige Befehl und wie setze ich ihn ein, um die Daten in einen Wert übertragen zu bekommen, den ich dann weiter im Editor verwenden kann?


    Eigentlich hängt davon ab, ob ich Visionaire benutzen kann oder nicht. Ich habe jetzt drei Spielideen, die alle drei nur mit viel Lua realisierbar sind. Ich komme um eine Programmiersprache also nicht herum. Wenn ich sowieso eine neue Sprache lernen muss, kann ich z.B. auch Flash benutzen und ActionScript lernen...;-)

    Machtnix

    Thread Captain

    1078 Posts

  • #3, by sebastianMonday, 30. November 2015, 18:36 5 years ago
    Ich glaube es gab im wiki ein script wo man checken kann ob der cursor im umkreis von einem anderen objekt ist. Hier könntest du anstatt cursor x/y die character Koordinaten abfragen.

    http://wiki.visionaire-tracker.net/wiki/IsInRadius_(CMS)

    Thread Captain

    2336 Posts

  • #4, by sebastianMonday, 30. November 2015, 18:38 5 years ago
    * CharacterDestinationObject ist ein verweis auf das objekt, wo der aktive character gerade hinläuft

    Thread Captain

    2336 Posts

  • #5, by MachtnixMonday, 30. November 2015, 19:06 5 years ago
    Danke.

    Der Cursor nützt mir leider nichts, denn in diesem Spiel klicke ich auf ein Rohrobjekt innerhalb des Feldes von 5x5 Elementen und das wird dann mit einem anderen Rohrstück auf dem Stapel ausgetauscht. Um die Position zu bestimmen, wohin das Stapel-Teil abgelegt werden soll, brauche ich die "festen" Werte, wo das andere mal lag.

    Ich lese zwar viel im http://wiki.visionaire-tracker.net/wiki/, aber ich bin nun mal kein Programmierer, das heißt: was mache ich nun mit dem Befehl? Liefert der mir einen Wert zurück? Oder zwei? Oder den Namen? Wie bekomme ich diesen Wert in mein Spiel? Kann ich diesen Befehl einfach als einzeiliges Lua-Script einfügen?

    Im Grunde genommen fehlt mir das Verständnis zwischen der reinen Programmiersprache und der Verknüpfung zum Vis-Interface, da es keine Dokumentation gibt. Ich nehme mir fertige Scripte vor und versuche herauszufinden, wie die angebunden sind, wie die Werte überhaupt übergeben werden und warum was passiert...

    Machtnix

    Thread Captain

    1078 Posts

  • #6, by sebastianMonday, 30. November 2015, 19:32 5 years ago
    das ist mir klar dass du den cursor nicht brauchen kannst. Daher wie erwähnt anstatt cursor x/y die character Koordinaten abspeichern und im script abfragen lassen, sodass du rauskriegst ob ein Objekt in der nähe ist (Ich beziehe mich auf deine erste Frage):

    wie kann ich erfahren, an welchem Objekt ein Charakter positioniert ist?



    script aus dem wiki, modifiziert mit character Koordinaten:
    ---(definition script)---
    local x, y -- empty variables which the objects position or center will be stored in
    local pos = {} -- empty table which we will store the mouse character positions in
    local char -- character which checks the radius around itself

    -- check if character is in radius (circle)
    function isInRadius(char, obj, rad)
    -- + character position + --
    pos.x = getObject("Characters["..char.."]"):getPoint(VCharacterPosition).x
    pos.y = getObject("Characters["..char.."]"):getPoint(VCharacterPosition).y
    -- + object position & radius + --
    if obj:getId().tableId == eCharacters then
    x = obj.Position.x; y = obj.Position.y
    rad = math.floor(obj.Size * rad) / 100
    elseif obj:getId().tableId == eObjects then
    x = obj.ObjectSprite.SpriteSprite:getPosition().x + (obj.ObjectSprite.SpriteSprite:getSize().x / 2)
    y = obj.ObjectSprite.SpriteSprite:getPosition().y + (obj.ObjectSprite.SpriteSprite:getSize().y / 2)
    rad = math.floor(obj.Scale * rad)
    end
    -- + calculate distance from circle center + --
    if x > pos.x then x = math.floor(x - pos.x) else x = math.floor(pos.x - x) end
    if y > pos.y then y = math.floor(y - pos.y) else y = math.floor(pos.y - y) end
    if math.floor( math.pow(x, 2) + math.pow(y, 2) ) <= math.pow(rad, 2) then
    Conditions["inRadiusVal"].ConditionValue = true; return true end
    Conditions["inRadiusVal"].ConditionValue = false; return false -- if not in radius then it's false
    end
    ---
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28


    als char übergabewert kannst du nun den Namen des chars angeben der dessen radius gecheckt werden soll.


    Damit das ganze jetzt im Visionaire Actionpartkram besser verwendbar ist, macht es sinn zusätzlich zu "return true/false" oben im script diese in Conditions abzuspeichen (oben "inRadiusVal" genannt. "inRadiusVal" als Condition irgendwo in Visionaire anlegen).


    Jetzt kannst du folgendes machen in Visionaire:
    Actionpart: Execute Script: isInRadius(NAME_VOM_CHAR,Objects["object_name"], 10)
    //checkt ob NAME_VON_CHAR im Umkreis von 10 Pixel Nahe Object "object_name" steht.
    IF CONDITION inRadiusVal IS TRUE
    ...char steht in der nähe
    ELSE
    ...char steht nicht in der nähe
    END
    1
    2
    3
    4
    5
    6
    7
    8






    *nicht getestet

    Thread Captain

    2336 Posts

  • #7, by MachtnixMonday, 30. November 2015, 20:19 5 years ago
    OMG... Vielen Dank.

    Ich versuche irgendwann zu verstehen, was da abgeht. Für die Schlussüberprüfung, ob die Rohre verbunden sind, ist es mit Sicherheit ein brauchbarer Ansatz (ich kann so feststellen, ob die offenen Enden nahe gernug beieinanderliegen, um als "verbunden" definiert zu werden).

    Aber für die einfache Abfrage, wo sich mein Charakter Nr. 17 oder 5 befand, kommt mir das wie Overkill vor, denn ich muss das jedesmal abfragen, wenn der Spieler ein Feld anklickt... meine "Charaktere" - die 26 Rohrelemente - haben ja feste Positionen, die sind am Start des Spiels einmal definiert, sie bewegen sich auch nicht tatsächlich, sondern werden einfach von einer fixen Position auf die andere gebeamt.

    Vielleicht mache ich mal eine Skizze, damit es klarer wird...

    Es ist mit Sicherheit ein zu komplizierter Ansatz, das liegt aber daran, dass ich eigentlich nur mit Bordmitteln auskommen wollte... Ich glaube, ein pfiffiger Scripter schafft das mit 30 Lua-Zeilen, und dann ist es außerdem noch erweiterbar... ;-) ;-)

    Machtnix

    Thread Captain

    1078 Posts

  • #8, by sebastianMonday, 30. November 2015, 21:36 5 years ago
    Habe ich das richtig verstanden, dass du die charactere, welche ein Rohrstück darstellen, zufällig auf dem brett verteilst?
    Wäre es nicht sinnvoller die charaktere (oder objekte) statisch zu platzieren und deren status (feld 1-25) zufällig zu setzen wobei ein feld nur 1x vorkommen darf?
    (natürlich kann es mehrere gerade oder rechtskurven, etc geben, aber intern sind sie jeweils einzigartig)
    Danach hast du auch ein zufällig aufgebautes 5x5 Feld.
    Feld ID von oben links 1 bis unten rechts 25:
    01 02 03 04 05
    06 07 08 09 10
    11 12 13 14 15
    16 17 18 19 20
    1
    2
    3
    4
    5



    Da dein angehängtes Bild so aussieht als kann man die Felder drehen, macht es sinn hier jedem Feld 4 conditions zu geben, welche die Verbindungsmöglichkeit nach oben, unten, links und rechts definieren. Dreht man so ein Feld, werden der status der Feldverbindungen entsprechend angepasst (brei rechtsdrehung wird aus rechts unten, unten links, links oben und oben rechts).


    Jetzt weiß ich natürlich nicht ob der Start und Endpunkt jeweils immer derselbe ist. Theoretisch auch egal.
    Wenn die Felder sich alle drehen können und entsprechend die Ausgangsverbindungen aktualisiert werden, könntest du nun eine Schleife machen, die dann abfragt ob am Feld neben der aktuellen startposition eine Conditions auf True steht, die eine Verbindung nach Links offen hat (Im beispiel wird feld 11 gecheckt da der start daneben ist).

       01 02 03 04 05
    06 07 08 09 10 E
    S 11 12 13 14 15
    16 17 18 19 20
    1
    2
    3
    4
    5

    S= start , E = ende, Feld 11 wäre aktuell zb eine rechtskurve, die nach links und unten offen ist (sprich links=true und unten=true)


    Wenn ja, dann setze einen merker auf diese position des Feldes (11). Der Merker dient nur intern um zu ermitteln wie weit eine verbindung vom startpunkt besteht. Jetzt lässt du in einer weiteren Schleife die Ausgänge des Felds checken, welche noch nicht durchdrungen wurden (alle ausser Links).
    Also erst checken ob das aktuelle Feld (11) eine öffnung oben hat (oben=true), falls ja, dann checken ob auf dem Feld "Aktuell-5" (11-5 = 6 -> über 11) unten = true ist. Falls oben=false ist braucht entsprechend nicht nach oben gecheckt werden und es kann mit rechts"Aktuell+1" bzw. unten "Aktuell+5" weitergemacht werden.
    Danach rufst du rekursiv nochmals die hauptschleife auf, allerdings mit dem neuen standpunkt des merkers.
    Das ganze ist sinnvoll in lua zu machen, da ich mir nicht sicher bin wie dynamisch und rekursivfähig das ganze actionpart system ist...


    ich glaube ich habs sehr verwirrend geschrieben und weiß auch selbst nicht, ob es die beste lösung ist, da ich selbst nicht sehr bewandert in dem ganzen bin...
    Rekursion ist aber hier denke ich ein wichtiger Hinweis razz

    Thread Captain

    2336 Posts

  • #9, by MachtnixTuesday, 01. December 2015, 00:30 5 years ago
    Oha, da zerbricht sich jemand meinen Kopf... ;-) Whow!

    Hier nochmal mein Spielprinzip:

    Das Spiel besteht aus einem quadratischen Feld mit 5 x 5 Slots für die Rohrmodule. Die Module sollen bei jedem Spiel zufallsgesteuert auf den 25 Plätzen verteilt werden. Es gibt insgesamt 6 Modulelemente. Die Elemente können nur auf den Stapel verschoben, nicht gedreht werden. Es gibt also von jedem Element 4 Stück und von einem fünf, sonst gehts ja nicht auf. Außerdem liegt auf dem "Stapel" das 26. Element. Ein- und Auslauf sind in der Testversion fixiert.

    Ziel des Spiels ist es, die Deckel durch einmaliges Anklicken zuerst freizulegen und danach - mit einem weiteren Mausklick - das Rohrteil, das darunter zum Vorschein kommt, mit einem Element auf einem Lagerplatz am Rand des Spielfelds auszutauschen, um das Rohr zu verbinden. Es wird somit immer das letzte angeklickte Element mit dem sich im Lager befindlichen vertauscht. Nach etwa dem vierten angelegten Element oder nach einer definierten Zeitspanne oder was auch immer beginnt die Flüssigkeit zu fließen, und wenn der Spieler die Verbindung nicht geschafft hat, ist Game Over. Austausch ist nur solange möglich, wie keine Flüssigkeit im Element fließt.

    Ob Ein- und Auslass jedesmal anders liegen, ob auch ein Feld mit 6x6 Elementen angelegt werden kann, sind alles nur zusätzliche Bonus-Funktionen. Erstmal habe ich mich auf fixe Start- und Endpunkte festgelegt. Schon alleine wegen der Kulissengröße (Hier 800x600 Pixel). Meine Lösungen erlauben keine anderen Variationen, sie sind nicht modular. Erweiterungen gehen nicht.

    Nach drei verworfenen Lösungen mit Objekten habe ich die Elemente als Charaktere angelegt. Jeder Charakter bekommt vier Outfits: Deckel, Standbild des leeren Elements, und zwei Animationen, in denen die Flüssigkeit durchläuft, einmal von einer Seite, einmal von der anderen.

    Mit welcher Methode ich sie auf dem Brett zufällig verteile, ist eigentlich egal. Da die 26 Elemente der Reihe nach auf der Kulisse aufgelistet sind (zuerst die vier waagrechten Geraden, dann die vier senkrechten Geraden, usw.), bekommen sie erstmal eine individuelle ID. Das muss sein, weil Visionaire das benötigt. Zweitens lege ich 25 + 1 Nullobjekte an, die ich als Raster auf dem Brett anordne. Nullobjekt 1 hat die Positionsdaten links oben, Nr. 2 daneben und so fort. Durch einen Zufallsgenerator bekommen die fixen Nullobjekte nun irgendeines der 26 Elemente zugewiesen. Das könnte schon im Editor gelingen, denn ich habe ja den Zufallsgenerator an Bord.

    Gut. Ich habe jetzt die 25 zufällig verteilten geschlossenen Deckel auf dem Brett. Der Spieler klickt einen Deckel an und das darunter befindliche Rohrstück kommt zum Vorschein.

    Beim nächsten Klick springt das angeklickte Element (angenommen es hat die ID=5) auf den Stapel und das dort liegende (angenommen es hat die ID=26) kommt auf die Position, auf der vorher das angeklickte sich befand. Da immer nur eine "Person" sichtbar ist und das von der Reihenfolge auf der Kulisse abhängig ist, kam die Lösung, einfach alle 25 übereinander zu legen und unsichtbar zu schalten, nicht in Frage. Ich brauchte einen echten Austausch.

    Das habe ich jetzt bei zwei Rohrelementen hinbekommen, indem ich für die Aktion "Linker Mausklick" einen Zähler angelegt habe, der von 1 bis 2 zählt. Natürlich mit If-Abfrage... ;-)

    Die Richtung AUF den Stapel klappt und ist einfach. Ich brauche ja nur die Koordinaten des Stapels als Zielpunkt eingeben (oder das Nullobjekt), und die sind immer gleich.

    Aber für die andere Richtung brauche ich natürlich den Ort, wo das Rohrstück herkam. Es lag z.B. am Nullobjekt 14 - quasi auf Platz 14. Das vom Stapel genommene Element muss also auf Platz 14. Ich kam auf die Lösung, dass das mit zwei Hilfsvariablen funktionieren kann: sie nehmen als Cache kurzzeitig die alte ID und die alte Position auf, bis sie mit der neuen ID und neuer Position überschrieben werden. Habe ich aber noch nicht getestet. Ich hoffe, die Variable wird überhaupt immer neu aktualisiert (sie muss global sein), sonst geht's gar nicht.

    Das Problem ist nun, das Feld 14 ausfindig zu machen und zu adressieren, damit das neue Element weiß, wo es hinhüpfen muss. Dazu muss ich die Nummer des Nullobjekts (oder seine Position, was aber einen Wert mehr bedeutet: nämlich x UND y) auslesen können. Ich kann das zwar beim Charakter eintragen, es steht aber unerreichbar irgendwo drin und ich komme nicht ran. Ich kann es von dort nicht in einer Variablen einpflegen. Ich brauche demnach nur die Eintragung: Element mit der ID=5 lag auf Platz 14, und diese 14 gehört in den Kurzzeit-Wert. Später liegt es auf dem Stapel, also auf Platz 26. Beim nächsten Klick springt es z.B. auf Platz 21, weil dort ein passendes Stück lag. Es hat jedesmal eine andere Position und diese Position brauche ich auch jedesmal. Das klappt nicht ohne Lua.

    Die Idee mit den vier Anschlusspunkten hatte ich auch. Ebenfalls mit vier Bool-Werten. Ist aber nicht ganz so einfach. Ich habe für jedes Element sechs mögliche richtige Kombinationen. Davon fallen drei weg, weil der Spieler das Rohr ja nur in eine Richtung baut. Aus der Ursprungsrichtung kommt die Flüssigkeit, diese Richtung ist also ausgeschlossen. Da er aber auch eine S-Kurve bauen darf, ist nicht klar, welche Richtung aktuell die richtige ist, um später die korrekte Fließrichtung aller Animationen vom Start bis zum Ziel abzugleichen.

    Wenn ich das vorab geklärt habe, bleiben mir schließlich drei Richtungen übrig. Genau wie du das vorgeschlagen hast, muss ich also die Anschlussfelder checken. Deshalb die fixen Positionen, denn tatsächlich gibt es die Möglichkeiten +5, -5, +1 und -1 Felder weiterzurechnen.
    Ich muss diese Kombinationen checken und diejenigen ausschließen, wo ein TRUE auf ein FALSE trifft. Das klappt aber bei Elementen, die am Rand liegen, schon nicht mehr. Wenn z.B. rechts oben auf 5 ein TRUE nach rechts liegt, und auf Platz 6 (nächste Zeile links) ein TRUE nach links, würde das ja als TRUE erkannt. Geht also nicht. Muss wahrscheinlich abfragen, ob das Element am Rand liegt; dann gelten wieder andere Regeln... Hab aber dafür noch kein Konzept. Bei Schachprogrammen wird noch eine unsichtbare Felderreihe um das Spielfeld herum angelegt, möglich, dass das zwingend notwendig ist. Dann habe ich ohnehin die A... Karte, weil ich alles neu basteln müsste....

    Wie gesagt, das Problem liegt ganz weit hinten. Erstmal möchte ich, dass überhaupt alle Elemente ordnungsgemäß und narrensicher ausgetauscht werden können...

    Alle deine Vorschläge sind reine Lua-Vorschläge. Ich bin sicher, dass es in Lua funktioniert. Dafür muss ich es erstmal lerenen. Und Programmierlogik sowieso erstmal begreifen. Ansonsten war dies mein Test, ob ich 1. logisch zu einer Lösung komme, und 2. ob Visionaire wie versprochen das ohne Programmierkenntnisse schafft. 2. klappt schon mal nicht... ;-)

    Vielen Dank für deine Hilfe.

    Machtnix

    Thread Captain

    1078 Posts

  • #10, by MachtnixSaturday, 15. April 2017, 21:04 3 years ago
    Ab und zu probiere ich an dem Spielprinzip herum, komme aber nie wirklich weiter.

    Die Lösung, alle 25(+1) Rohrpuzzles mit Charakteren zu machen, war viel zu aufwendig. Das führte zu 25x7 (+6 für den Austauschplatz) =181 Outfits. War also gigantisch unsinng und sehr speicherintensiv.

    Die Lösung mit Einzel-Objekten zu machen, war ebenfalls zu umfangreich. Übereinandergestapelte Objekte führten auch zum Chaos.

    Deswegen bin ich auf die Idee gekommen, eine Animation mit 7 Frames einzuführen (dank AFRLme). Offensichtlich benötigt jedes sichtbare Puzzle aber eine eigene Animation, denn die Position der Animation ist von der Position des Objekts abhängig. Schade, ich dachte, ich käme mit nur einer Animation aus, denn die 7 Frames sind ja überall gleich. Nun, gut, ich habe also 25+1 identische Animationen.

    Nun hat sich ergeben, dass ich einen Rand brauche (wie bei einem Schachspiel), um abfragen zu können, ob das Spielfeld verlassen wird oder nicht. Ich möchte nun die Puzzles 9-13, 16-20, usw. in eine Tabelle einfügen.

    Welches Objekt der Spieler gerade anklickt, könnte man simpel durch die Abfrage des Objektnamens abgreifen. Die Objekte haben einfach nur Zahlen als Namen. Die genaue Position des Objekts brauche ich gar nicht.

    Ich hätte also eine Tabelle mit 25 (+1 Tauschfeld) Indices. So ließe sich auch bequem irgendein Zufallsgenerator zu Spielanfang starten. Da es egal ist, WANN der Zufall stattfindet, würfle ich den Frame erst dann aus, wenn das Puzzleteil aufgedeckt wird. Ich muss nur darauf achten, dass nicht z.B. 26 gerade Rohrteile aufgedeckt werden, denn dann wäre das Spiel nicht lösbar. Da habe ich noch keinen Plan...

    Jedem Indice wird eine Wert zugewiesen, der der Framenummer entspricht, die angezeigt werden soll. Tabellenelement 17 hätte also z.B. den Wert 2, was dem Framebild eines senkrecht stehenden Rohrstücks entspräche. Auf dem Tauschfeld 26 außerhalb liegt z.B. Frame-Nummer 3 (ein gebogenes Element). Tausche ich nun die Rohrstücke aus, so werden intern nur die Framenummern ausgewechselt. Objekt Nr 17 bekommt also den Frame 3 und das Tauschfeld den Frame 2. Ich verschiebe beide alten Werte in eine Speichervariable und weise sie neu zu. Eine wirkliche Verschiebung findet also nicht statt.
    Dazu muss ich wahrscheinlich bei jedem Mausklick die komplette Tabelle abfragen und ggf. neu einordnen.

    Jeder Frame bekommt eine Art Eigenschaftsstapel zugewiesen. Das senkrechte Rohrstück hat eine Öffnung auf der Nordseite und eine auf der Südseite. Es bekommt die Werte N=1, O=0, S=1, W=0. (Die Himmelsrichtungen sind praktisch...) Irgendwie muss ich also beim Einlaufen der Flüssigkeit abklären, ob z.B. Element 17 nach oben (+7 oder - 7, nach links und rechts +1 oder -1) einen Anschluss finden kann. Das ergibt jedesmal, so befürchte ich, eine Höllenanzahl von if-Abfragen... Die Flüssigkeit kann also nur durch 17 fließen, wenn das  Element 17-1 und das Element 17+1, oder das Element 17+7 und 17-7 zusammenpassen... Aber auch hier habe ich noch keinen Plan.

    Ist eine Verbindung vorhanden, so müssen jeweils 25 neue Animationen aufgerufen werden. Jedes Rohrelement hat also 12 Animationen (in beide Richtungen!) mit Flüssigkeit, macht 300 Animationen insgesamt! Anscheinend kann ich auch jetzt nicht auf nur ein Set für alle zurückgreifen, so dass es ganz schön umfangreich wird.
    Vielleicht geht's einfacher - ich weiß nur nicht, wie. Vielleicht könnte ich alle 12 Animationen in eine stopfen und nur die entsprechenden Frames herauspicken und ablaufen lassen... aber dann muss ich immer die komplette Animation laden. Ich glaube, einzeln wäre es ergonomischer.

    Soweit die Theorie. Aber programmierblöd wie ich bin, krieg ich die Algorithmen einfach noch nicht hin. Und einen Einzelframe in einer Animation anzusprchen, klappt auch noch nicht.

    _______

    Google-Translator:

    From time to time I try the game principle, but never really go further.

    The solution to make all 25 (+1) pipe puzzles with characters was far too elaborate. This resulted in 25x7 (+6 for the exchange) = 181 outfits. So was giganticly nonsense.

    The solution with single objects was also too extensive. Stacked objects also led to chaos.

    That's why I came up with the idea to introduce an animation with 7 frames (thanks to AFRLme). Obviously every visible puzzle needs its own animation, because the position of the animation depends on the position of the object. Too bad, I thought I would come out with only one animation, because the 7 frames are the same everywhere. Well, well, I have 26 identical animations.

    Now it has turned out that I need an edge (as in a chess game), in order to be able to query whether the field is left or not. I now want to insert the puzzles 9-13, 16-20, etc. into a table.

    Which object the player just clicks, one could easily get by the query of the object name. The objects simply have numbers as names. The exact position of the object I do not need at all.

    So I would have a table with 25 (+1 exchange) indices. So it would be easy to start any random generator at the beginning of the game. Since it does not matter, WHEN the random takes place, I dice the frame only when the puzzle part is uncovered. I just have to make sure that there are not 26 straight pipe sections, because then the game would not be solvable. Since I have no plan yet, how to make this ...

    Each indice is assigned a value that corresponds to the number of fractions to be displayed. Table element 17 would therefore have, e.g.  the value 2, which corresponds to the frame image of a straight tube piece. On the exchange panel 26 outside, e.g. frame number 3 (a curved element). If I now replace the pipe pieces, only the number of fractions are exchanged internally. Object  17 thus gets the frame 3 and the exchange field the frame 2. I move both old values ??into a memory variable and re-assign them. A real shift therefore does not take place.
    For this I probably have to query with every mouse click the complete table and re-arrange it if necessary.

    Each frame is assigned a kind of property stack. The vertical tube has an opening on the north side and one on the south side. The values ??N = 1, O = 0, S = 1, W = 0 are obtained. (The directions of the sky are practically ...) Somehow, I have to clarify when the fluid flows in, for example. Element 17 to the top (+7 or - 7, to the left and right +1 or -1). This always results, I fear, by a huge number of if-queries ... The liquid can only flow through 17 if the element 17-1 and the element 17 + 1, or the elements 17 + 7 and 17-7 fit together ... But here, too, I have no plan.

    If there is a connection, 25 new animations must be called. Each tube element thus has 12 animations (in both directions!) With liquid, makes 300 animations in total! Apparently, I can not go back to just one set for all, so it will be quite extensive.
    Maybe it's easier - I just do not know how. Perhaps I could stuff all 12 animations into one and only the corresponding frames pick out and run off ... but then I always have to load the complete animation. I think individually it would be more ergonomic.

    As far as the theory. But stupid as a coder as I am, I do not get the algorithm simply. And a single frame in an animation to address, does not work yet.

    OMG...

    Thread Captain

    1078 Posts

  • #11, by sebastianSaturday, 15. April 2017, 21:19 3 years ago
    Ist schon etwas her, dass Thema. Wie genau sollte nochmal das Spiel funktionieren? Wäre doch gelacht, wenn es da nicht irgendwie auch eine einfachere Herangehensweise geben würde...
    (ich steige immer noch nicht so ganz dahinter oder verstehe das irgendwie falsch)

    Thread Captain

    2336 Posts

Write post