Re: [Cuyo-devel] Vorschlag: unbewegliche Variablen

[Immanuel Halupczok]

[An Mark: Sorry, dass du die Mail zweimal bekommst. Du weisst schon, 
"reply"...]

Mark Weyer a écrit :

>> 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.


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.

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.

>
>> - 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.


Args, Geschmacksrichtungen hatte fuer mich eine etwas andere Bedeutung: 
Das wesentliche an Geschmacksrichtungen sollte fuer mich sein, dass man 
schon zu parse-zeit merkt, wie's schmeckt. (Wenn verschiedene Sorten 
verschiedene Variablen-Saetze haben, dann sind die immernoch die selbe 
Geschmacksrichtung.)

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).

>
>
>> - 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.


Schade.

>
>
>> 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?


Da denk ich zwar immer, dass man aufpassen sollte, aber ich frag mich, 
ob es in der Praxis wirklich relevant ist. Man muesste mal einen 
Test-Level machen, in dem man einfach ganz viele Variablen deklariert 
und schaut, ob's langsamer wird.

>
>
>
>> [...]
>
>
>
> 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.


Ok.

> 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.


Ok.

>> - 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?).


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.)

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.)

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...



>
> 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.


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.)


> 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))


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.)



Noch ein Argument dafuer, ortsfeste und variable Dinge wirklich 
verschieden zu behandeln (d. h. ihnen verschiedene Geschmacksrichtungen 
zu geben): Es gibt viele Flags, die nur fuer Variable Dinge Sinn machen 
(wird von Gravitation beeinflusst, verbindet sich mit, explodiert bei, 
.....).

(Uebrigens: Nein, der pac-man-level braucht keine verschiedenen Sorten 
in der ortsfesten Ebene.)

       Immi

--

--------------------------------------------------------------------------
    Immanuel Halupczok       www.karimmi.de       www.croco-puzzle.com
--------------------------------------------------------------------------