Re: [Cuyo-devel] Vorschlag: unbewegliche Variablen

[Mark Weyer]

> Offenbar hatte ich deine Idee noch nicht ganz verstanden. Du wuerdest 
> also in diesem Fall einen Satz Sorten fuer den Hintergrund haben und 
> einen Satz Sorten fuer den Vordergrund? (Aber will man in diesem Fall 
> vielleicht gleich mehr als zwei Blob-Ebenen? Und ist es nicht Zufall, 
> dass eine der Ebenen ortsfest ist und die andere nicht?)

Das klingt überzeugend. Also n Ebenen, der Programmierer wählt n und
die Bewegungsarten. Ebene 0 ist immer die, in der der Fall ankommt.

> - Geschmacksrichtungen von Variablen sind abgeschafft.

Nein. Aber sie sind nicht an die Ebenen gekoppelt. Zum Beispiel
könnten die Sorten in Labskaus Geschmacksrichtungen sein, da jede
ihren eigenen Satz an Variablen benutzt.

> - Es waere zu ueberlegen, ob man die Leer-Blobs noch braucht. Wann die
>   entstehen und wann sie verschwinden, war eh merkwuerdig. Wie man ohne
>   sie auskommt:
>   - Hintergrund malen geht mit ortsfesten Blobs
>   - In Nachbarfelder ueberstehende Blobstuecke malen sollte auch dann
>     mit "*@" gehen, wenn in dem Nachbarfeld gar kein Blob ist. (So was
>     hab ich mir eh schon im Hex-Modus gewuenscht, um in die halben Blob-
>     Stuecke am unteren Bildschirmrand malen zu koennen.)
>   Weiss jemand noch Level, in denen man damit nicht auskaeme?

Maze. Der Leer-Blop ist graphisch ein ganz normaler schema16-Blop
(vielleicht mit der Sonderregel, daß bei 1?1?1?1? das ohnehin leere
Bild gar nicht ausgegeben wird). So wie auch Gras und Grau.

> Performance-Ueberlegungen: Mir scheint, es gibt zwei Dinge, die Zeit 
> brauchen: Cual-Code ausfuehren (Proportional zur Code-Laenge, die 
> ausgefuhert wird) und Bildchen malen. Bei beidem sollte es eigentlich 
> keinen Unterschied zwischen den Weltbildern geben.

Was ist mit Variablen-kopieren?


> [...]

Du hast mich überzeugt. Also <,>,! in die Klammern. Und später noch
eine Zahl für die (relative oder absolute?) Ebene. Die dann vieleicht
mal nicht mit Komma abtrennen, sondern Semikolon oder so was.
Ist für die Grammatik etwas blöd, aber das kriegen wir hin.

> *       Blob selber
> *@      Global blob
> *@(1,1) relative Position  a
> *@@     Semi-global blob   a
> *@@1    ein Fall-Blob      a

Ein absoluter Fall-Blop.

> - Bei den mit a markierten Versionen ein modifier <, >, !. 
> Sinnvollerweise an konsistenter Stelle. Aber alle konsistenten Stellen 
> scheinen mir schon gefaehrlich nah dran, die Syntax uneindeutig zu 
> machen. (D. h. teilweise tun sie's nur deshalb nicht, weil es in cual 
> manche ueblichen Konstrukte aus anderen Programmiersprachen (noch) nicht 
> gibt.) Vielleicht waere "L", "R" fuer links/rechts sicherer statt "<", 
> ">". (Und dann konsequenterweise "O" fuer "onderer Spieler".)

Wenn man statt @@< halt @@(<) schreiben muß, wäre es wohl OK. Kommt
wohl eh selten genug vor (bisher gar nicht), da sind die zwei Zeichen
mehr vertretbar.
L R und O sind böse: die Koordinaten sind Ausdrücke, also fast Code.
Und einzelne Buchstaben bezeichnen schon Code. Da kriegt man früher
Probleme als mit <,>,!.

> - Zugriff auf absolute Koordinaten

Gibts: @@(1,1)

> - relativer Zugriff im Fall ("der andere Blob im Fall")

Gibts: @1. (Früher war @1 mal absoluter Zugriff im Fall, aber da nur
ich selbst das verwendet habe, war ich so frei, es zu konsistentieren.
Im Gegensatz zu @ und @@ (ohne was dran: Unterschied global/semiglobal;
mit was dran: Unterschied relativ/absolut)

> - ggf. Zugriff auf andere Ebene

Gibts nur fürs malen: *@(0,0): drüber, @(0,0)*: drunter.


Zur allgemeinern Erörterung: Ich würde mehrere Blop-Ebenen
favorisieren. Nach Wahl des Programmierers. Wie die mit den
draw-Ebenen zusammenhängen: Sehen wir mal. Vielleicht die
bisherigen drei pro neue Ebene (wäre auch der geringste Aufwand).

Außerdem sollten Variablen nicht überall sein, sondern nur da,
wo sie gebraucht werden. Diese Struktur ist aber eigentlich was
anderes als die Ebenen. Vielleicht feiner, vielleicht unvergleichbar
(was meint Ihr?).

Wie man das beides zusammenbringt, ist mir noch nicht ganz klar.
Wie genau die Variablenaromenstruktur aussieht, sollten wir vielleicht
separat ausarbeiten. Aber wenn man beide letzte Absätze zusammennimmt,
kann man als beweglicher Blop auf die ortsfesten Variablen nur mit
name@(0,0;-1) oder so zugreifen, statt einfach nur mit name. Ist das
ein akzeptabler Overhead? Ginge vielleicht einfach nur @(;-1)? Das
würde implizieren, daß es Ebenen nur im Spielfeld und nicht im
global-blop gibt.


Die Ebenen - sprich: dreidimensionales Spielfeld - würden übrigens
auch gleich ein von mir lang ersehntes Feature implementieren:
meherere Arten von Verbindungen pro Blop-nach-alter-Auffassung.
Brauche ich für einen 3D-Level und für Nasenkügelchen. Ganz viele
neue Verbindungsrichtungen... (z.B. @(0,-1;2))

  Mark