OMG... würde ich das Spiel verkaufen, würdest du (mindestens) die Hälfte der Einnahmen kriegen...
Danke.
Aber ganz ehrlich: ich würde auf soetwas nie im Leben kommen. Diese "Denkungsweise" ist mir sowas von fremd. Ich fertige lieber die Bilder und Animationen an (die alle schon fertig sind...).
Ich habe eine abartig schmutzige und schnelle Lösung genommen: ich habe einfach 20 Tabellen zufällig angelegt und lasse sie nacheinander durchlaufen. Ich habe keinen Zufallsgenerator genommen, sondern das Mischen selbst besorgt (frei nach Zorg: wenn man will, dass etwas gemacht wird, muss man es selbst machen...). Klar ist das blöd. Aber wenigstens gibt es jetzt keine 24 geraden Rohre mehr...
Wer das Spiel 20mal hintereinander spielt, merkt vielleicht, dass es sich wiederholt - die anderen nicht. Da sieht man, dass es mir immer nur um die Lösung eines Problems - egal wie - geht. Elegantes Programmieren ist toll, aber wenn es auch ohne klappt, verzichte ich darauf...
Deine Tipps mit dem Wassereinlauf sind - nun - auch noch in Kladde. Das Konzept ist einleuchtend. Ich brauche eine Variable dafür, ob schon Wasser drin ist (das ist für mich aber nur eine Randbedingung - die Überprüfung der Verbindungen sind das größte Hindernis), aber wie und mit was für Mitteln ich das alles überprüfe, ist mir KONKRET noch nicht klar. Deine Überlegungen
Sprich bei einer Funktion, die den Wasserstand eines JEDEN Rohrs aktualisiert* (+1 setzt) und voll ist (sagen wir mal wenn der Wert 5 erreicht ist das Rohr voll), checkst du zum einen vom rohr den Typ und von welcher Seite ursprünglich wasser eingeflossen ist. Wenn du diese beiden Sachen weißt, kannst du auch bestimmen wo das Wasser rausfließen würde.
sind absolut logisch, aber... an der konkreten Umsetzung hapert es. Ich würde übrigens den letzten Frame der Einfließanimation als Trigger dafür wählen, ob das Rohrstück voll ist. Aber dafür brauche ich auch unterschiedliche 25 Werte (oder etwas weniger).
Für die Überprüfung der Verbindungen benötige ich anscheinend tatsächlich vier verschiedene Werte, aber müssen die Öffnungen jetzt nun für jedes Feld eindeutig sein (also z.B. Feld8_Ost, Feld15_Süd) - oder reicht es, wenn jedes Feld einfach viermal dieselben Variablen hat (Nord, Ost, Süd, West)? Dann dürften die nur lokal gelten, werden abgefragt und in einer eindeutigen Variablen gespeichert. Oder wie auch immer... Vielleicht gehts auch ohne diese vier Werte, denn jedes Rohrstück ist ja an sich schon durch seine Kombinationsmöglichkeiten definiert. Wenn also ein bestimmtes Rohr neben einem anderen liegt, stehen die Chancen, ob sie passen, ja bereits fest.
Ich habe 20 A4-Seiten vollgekritzelt, wie ich was überprüfen könnte, aber letztendlich bin ich kein Stück weiter. Die Methode, die vier Öffnungen mit 1-4 zu bennen und sie jeweils mit den vier angrenzenden Feldern (+1, -1, +5, -5) zu vergleichen, ist wohl vielversprechend. Und die Überprüfung der Spielfeldränder kommt ja auch noch...
Abgesehen davon soll die Animation natürlich auch flüssig ablaufen. Ich muss also bei jedem Übergang abzählen, wie lange die vorherige Animation gedauert hat, bevor ich die im nächsten Rohr starte. Oder die nächste im letzten Frame der vorherigen anstoßen. Da gehört noch ein Script hin, denn woher weiß die alte Ani, welche neue Ani als nächstes gestartet werden muss...? Hört sich nach Peanuts an, aber ich befürchte, daran knabbere ich genauso lange. Aber das kommt GAAANZ am Schluss
Ich glaube jedoch, dass es sinnvoll ist, einen Programmierdenkerfreund hinzuzuziehen, weil es sonst zu lange dauert und ich dann auch die Motivation verliere.
Deswegen mache ich mir so früh einen Kopf über alle Probleme, weil ich vielleicht doch das 7x7-Feld wähle, weil das besser zu rechnen ist. Nachher kann ich das nur mühsam abändern.
Thread Captain
