[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Cuyo-devel] Vorschlag: unbewegliche Variablen
From: |
Immanuel Halupczok |
Subject: |
Re: [Cuyo-devel] Vorschlag: unbewegliche Variablen |
Date: |
Tue, 06 Dec 2005 14:34:18 +0100 |
User-agent: |
Mozilla Thunderbird 1.0.2 (X11/20050602) |
[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
--------------------------------------------------------------------------
- Re: [Cuyo-devel] Vorschlag: unbewegliche Variablen, Mark Weyer, 2005/12/01
- Re: [Cuyo-devel] Vorschlag: unbewegliche Variablen, Immanuel Halupczok, 2005/12/01
- Re: [Cuyo-devel] Vorschlag: unbewegliche Variablen, Mark Weyer, 2005/12/05
- Re: [Cuyo-devel] Vorschlag: unbewegliche Variablen, Immanuel Halupczok, 2005/12/05
- Re: [Cuyo-devel] Vorschlag: unbewegliche Variablen, Mark Weyer, 2005/12/05
- Re: [Cuyo-devel] Vorschlag: unbewegliche Variablen, Immanuel Halupczok, 2005/12/05
- Re: [Cuyo-devel] Vorschlag: unbewegliche Variablen, Mark Weyer, 2005/12/06
- Re: [Cuyo-devel] Vorschlag: unbewegliche Variablen,
Immanuel Halupczok <=
- Message not available
- Re: [Cuyo-devel] Vorschlag: unbewegliche Variablen, Mark Weyer, 2005/12/06
Re: [Cuyo-devel] Vorschlag: unbewegliche Variablen, Bernhard R. Link, 2005/12/05