Re: [Cuyo-devel] Vorschlag: unbewegliche Variablen

[Mark Weyer]

Immi schrieb, aber mal wieder nicht an die Liste:

> >Das klingt überzeugend. Also n Ebenen, der Programmierer wählt n und
> >die Bewegungsarten. Ebene 0 ist immer die, in der der Fall ankommt.
> 
> Und die Ebenen malen in der Reihenfolge, wie sie nummeriert sind? Das 
> haette den Vorteil, dass man sich keine Gedanken darueber machen muss, 
> ob die ortsfesten oder die beweglichen zuerst malen.

Ja. Oben meinte ich allerdings nicht, daß es nur Ebenen 0 bis n-1
gibt. Die dorthin-fällt-Zeug-Ebene muß nicht unten liegen. Vielleicht
ist es andersrum doch praktischer: Man sagt, wo der Fall landet.
Oder noch besser: Man hat alle beweglichen Ebenen im Fall. Wan landet
der Fall dann? Wenn er es in einer Ebene tut?

> Findet Gravitation, etc. in jeder beweglichen Ebene getrennt statt? (D. 
> h. kann in einer beweglichen Ebene ein Blob sich sprengen, waehrend in 
> einer anderen der Blob da bleibt... also: Finden lauter getrennte 
> Cuyo-Spiele uebereinander statt?) Werden Zusammenhangskomponenten 
> Ebenenweise geprueft? Das klingt wirklich nach zu viel Overhead.

Verbindungen: getrennt, mit der Möglichkeit, in andere Ebenen rein zu
verbinden. Besser gesagt: Einmal im Quader.
Gravitation und sprengen: Gute Frage. Bin mir noch nicht sicher, was
ich will. Die bisherigen Ideen für braucht-mehrere-bewegliche-Ebenen
brauchen vor allem das Verbindungsfeature. Sie stammen aus der Zeit
vor der Ebenen-Idee und daher hatte ich mich schon mit sprengen-halt-
synchron-und-Gravitation-sowieso abgefunden. Aber eigentlich ist es
asynchron besser... Vielleicht synchron/asynchron nach Wahl des
Programmierers?
Overhead: Nein. Wer mehrere bewegliche Ebenen bestellt, braucht sie
auch.

Neue, vage Level-Idee: Nasenkugeln und Sticken (oder sonst zwei für
sich leichte Level). Völlig unabhängig übereinander. Völlig? Nein, im
Fall synchronisiert.

> Trotzdem hab ich nochmal drueber nachgedacht, dass man die 
> Geschmacksrichtungen drin lassen koennte, und zwar: Jede Sorte hat eine 
> Geschmacksrichtung, und nur Sorten der Geschmacksrichtung "ortsfest" 
> koennen sich in der ortsfesten Ebene befinden (bzw. in einer ortsfesten 
> Ebene).
> 
> >
> >
> Vorschlag: Sorten durch Buendelungshierarchien ersetzen (wie ich bereits 
> mal beschrieben hatte; ein Grund dafuer ist auch, dass Sorten schon 
> lange nicht mehr nur als Sorten im urspruenglichen Sinne verwendet 
> werden). Und in dieser Hierarchie kann man auch Variablen deklarieren 
> oder nicht deklarieren. (Wenns Geschmacksrichtungen gibt, dann waere die 
> Geschmacksrichtung gleichzeitig die oberste Ebene in der 
> Buendelungshierarchie.)

OK. Später?

> Wenn man nicht zu parse-zeit entscheiden kann, welche Variablen 
> existieren und welche nicht, wuerde ich sagen: Man darf auch auf 
> Variablen zugreifen, die nicht existieren und erhaelt dann einen 
> default-Wert, den man selbst festlegen kann. (Ist eh schon so, wenn man 
> auf Variablen ausserhalb des Spielfelds zugreift.)

OK.

> Das bietet einige Moeglichkeiten sauberer in Cual zu programmieren. (Ich 
> hab mir z. B. oft gewuenscht, dass bei nix-blobs gewisse Variablen 
> automatisch resettet werden). Allerdings vermute ich, dass es nicht viel 
> Laufzeit einspart: Ich vermute, es ist schneller, wenn man fuer alle 
> Variablen von allen Blobs gleich viel Speicherplatz reserviert: Dann 
> kann man Speicher-Reservieren einmal am Anfang vom Spiel machen und muss 
> nicht dauernd umreservieren, wenn ein Blob auf einen anderen kopiert 
> wird. (Ich denke, umreservieren braucht viel Zeit.)
> 
> Andererseits: Wenn das Existieren von Variablen tatsaechlich in einem 
> Baum angeordnet ist (wie von den Buendelungshierarchien suggeriert), 
> dann kann man doch etwas Speicherplatz einsparen, indem man nur so viel 
> Platz reserviert, wie der speicheraufwaendigste Ast braucht...

Wir sollten Abstraktion und Implementation trennen. Wenn ein Blop
abstrakt nur wenige Variablen hat, kann er trotzdem für ganz viele
Speicher reservieren. Je nachdem, ob das Performance-mäßig ein Vor-
oder Nachteil gegenüber umreservieren ist. Die schnellste Variante
bei genug Hauptspeicher ist wohl: Alle Blops haben gleich viel Daten
und je Sorte gibt es eine Tafel die sagt, welche Variablen wirklich
zugreifbar sind und für welche es nur den default gibt. Oder so.
Bei wenig Hauptspeicher mag es anders aussehen.
Der speicheraufwändigste (von aufwänden: eine Wand aufstellen. Hier
eine metaphorische Wand. Wenn man ganz viel Speicher verschwendet,
verbannt man andere Prozesse in den swap. Sie haben dann das Gefühl,
durch Wände ausgegrenzt zu sein.) Ast ist oft kaum kürzer als die
Summe. Breakout: Die ganze Berechnung findet im global-blop statt.
Mit vielen Variablen. Der Rest braucht kaum noch was.

> Ich ueberlege, ob man die Syntax fuer Zugriff auf global-Blob 
> aendert/konsistent macht: Alle ortsangaben haben die Form @(...).
> In der Klammer kann man dann von mir aus "g" fuer global schreiben,
> "s" fuer semiglobal, ... Notationen wie "@(;-1)" sollten dann auch
> erlaubt sein. "@" koennte man als Kurzschreibweise fuer "@(g)" 
> beibehalten (etc.) (Wenn man das zu chaotisch findet, kann man irgend 
> wann "@" auch abschaffen.)

Das g würde niemand verwenden. Also vielleicht einfach ein Zeichen
für s (ich würde keinen Buchstaben nehmen) (anstelle des bisherigen
zweiten @)

> Ok, Nasenkügelchen ist das erste richtige Anwendung fuer n Ebenen, die 
> ich sehe. (Wobei: Selbst mit n Ebenen musst du noch rummurksen, damit 
> Nasenkuegelchen von einer Ebene in eine andere fallen koennen.)

Schauen wir mal was wir bis dahin an Möglichkeiten haben. Vielleicht
asynchrones Sprengen aber synchrone Gravitation? Kann das Deadlocks
geben?


Ich habe den Überblick verloren. Ist es konsensfähig, das Spielfeld
dreidimensional zu machen und dann mal weiterzusehen?