Re: [Cuyo-devel] Vorschlag: unbewegliche Variablen

[Immanuel Halupczok]

Mark Weyer a écrit :
> > > Das würde ich aber machen wollen (sonst haben die ortsfesten Blops nicht
> > > viel Sinn). Natürlich erspart es nur, einen cual-Aufruf in ganz viele
> > > Sorten einzutragen. Aber das tut es eben auch und verbessert cual-code
> > > damit konzeptionell. So wie der semiglobal Blop in labskaus bereits
> > > dafür gesorgt hat, daß nicht jede Sorte etwas über Ballons wissen muß,
> > > sie aber trotzdem nicht nur in nothing erscheinen.
> >
> > Dann wuerde ich lieber die Moeglichkeit erlauben, dass es Code gibt, der 
> > von allen Sorten ausgefuehrt wird, unabhaengig von orstfest oder nicht. 
> > (Gleicher Code in vielen Sorten kann man auch in nicht-ortsfest wollen.)
>
>
> Ich halte es für unsauber, den Code sortenunabhängig auszuführen.
> Das heißt unabhängig von der Hintergrundsorte. Ich stell mir da immer
> einen pacman-level vor. Ich habe ihn nie gesehen und deshalb habe ich
> natürlich eine eigene Vorstellung: Im Vordergrund findet irgendein
> cuyo-spiel statt und im Hintergrund ein pacman-spiel. Beide brauchen
> mehrere Sorten, und zwar unabhängig voneinander.

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

Na gut, hier ein neues Ideal-Weltbild (IWB), was mehr zu dieser Idee 
passt (und in der Tat naeher an der aktuellen Version von cuyo ist und 
vermutlich auch eher das ist, was du dir vorstellst):
- Geschmacksrichtungen von Variablen sind abgeschafft.
- Es gibt tatsaechlich (mindestens) drei Ebenen von Blobs, und ausserdem
  die Fall und die semiglobalen und die globalen. "Ort" bezeichnet in
  Zukunft nicht nur die Koordinaten, sondern auch die Ebene.
- Es gibt keine Beschraenkung daran, welcher Blob an welchem Ort sein
  kann. (Wenn's dem Programmierer Spass macht, kann er eine gelbe
  Nasenkugel als globalen Blob verwenden, solange die nicht versucht,
  sich an ihren eigenen Ort zu malen.)
- Insbesondere gibt es von jeder Variable je eine Instanz an jedem Ort.
- Laengerfristig koennen irgendwann Variablen so definiert werden,
  dass sie nur in einer Sorte existieren; so kann der Programmierer
  selbst dafuer sorgen, dass doch nicht jede Variable drei mal so oft
  existiert wie noetig. (Allerdings wird man nicht zu parse-Zeit fest-
  stellen koennen, dass ein Variablenzugriff auf eine nicht-existente
  Variable passiert.)

Ein paar weitere Gedanken dazu:
- Die ganz ortsfesten Blobs koennte man sogar dann am Ort lassen, wenn
  alle variablen Blobs gerade dabei sind, sich pixelweise senkrecht
  zu verschieben. Das wuerde in manchen bereits existierenden Leveln
  graphische Artefakte vermeiden (ich denke an color/shapes).
- 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?
(Leerblobs abschaffen waere aber natuerlich ein groesseres Projekt fuer 
spaeter.)

Der Hauptgrund, weshalb ich zu (IWA) tentiere: Variable-existiert-nicht- 
Erkennung zu parse-Zeit.
Der Hauptgrund, weshalb ich zu (IWB) tentiere: Leer-Blobs koennen 
abgeschafft werden.

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.


> > Ich wuerds in die Klammer schreiben, weil es Teil der Ortsangabe ist.
> > Also "@(0,0,>)", ... Fuer andere Seite vielleicht "@(0,0,!)" ("!" = 
> > "not" auf die Spielernummer anwenden). Dann waere statt "<", ">" auch 
> > "0", "1" moeglich. "0", "1" hat den Vorteil, dass es tendenziell auch 
> > mehr Sinn macht, dass man spaeter irgendwann Variablen dafuer einsetzen 
> > kann. Dafuer ist ">" deutlich uebersichtlicher, vor allem in der 
> > Klammer, weil man bei "@(0,0,1)" nicht weiss ob (0,0),Spieler1 oder 
> > Spieler0,(0,1) gemeint ist. Ich tendiere im Moment also zu <, >, !.
>
>
> Man könnte auch sagen, es ist orthogonal zur Ortsangabe. Bei Deiner

Mit Ort meinte ich das, was (wenn ich es richtig verstanden habe) in 
deinem C++-Orts-Datentyp steht.

> Idee mit Zahlen gibt es konkret den Nachteil, daß bei @(1,1) nicht
> klar ist, ob der Programmierer denkt, ich bin im Gitter, und den Blop
> rechts unten von mir meint, oder ob er denkt ich bin im Fall und den
> anderen Blop im Fall Spielers1 meint. Genauso kann bei @@1 der zweite
> Blop im eigenen Fall oder der semiglobal-blop Spielers1 gemeint sein.
> Für den anderen semiglobal würden wir demnach beide @@! vorschlagen?

Scheint so. Zu "in Klammer": Der Bezug auf den global blob und die 
semiglobal-blobs steht ja jetzt eh auch nicht in der Klammer. Also ist 
es vielleicht doch nicht wichtig/sinnvoll, "<", ">", "!" in die Klammer 
zu schreiben. Allerdings hab ich auch Angst, dass die Syntax irgendwann
uneindeutig wird: Ist das "<" bei "@@<" ein Vergleichsoperator oder 
gehoert es zur Ortsbeschreibung?

Ich hab keinen Ueberblick darueber, welche Syntax du fuer welche 
Zugriffe eingefuehrt hast. (Und ich weiss nicht mal mehr genau, was ich 
eingefuehrt hatte.) Ich versuche mal aufzulisten, und du kannst 
ergaenzen/korrigieren:
*       Blob selber
*@      Global blob
*@(1,1) relative Position  a
*@@     Semi-global blob   a
*@@1    ein Fall-Blob      a
Neu waere/wuerde vielleicht irgendwannmal sein:
- 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".)
- Zugriff auf absolute Koordinaten
- relativer Zugriff im Fall ("der andere Blob im Fall")
- ggf. Zugriff auf andere Ebene

        Immi


--

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