[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: |
Mon, 05 Dec 2005 20:38:41 +0100 |
User-agent: |
Mozilla Thunderbird 1.0.2 (X11/20050602) |
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
--------------------------------------------------------------------------
- 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 <=
- Re: [Cuyo-devel] Vorschlag: unbewegliche Variablen, Mark Weyer, 2005/12/06
- Re: [Cuyo-devel] Vorschlag: unbewegliche Variablen, Immanuel Halupczok, 2005/12/06
- 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