誰かに言われる前に自分で書きます.
子供にこれが動かないと言われたとき,そのいくつかはViscuitの仕様と言う名のバグです.言われる都度,ご免なさいと思いつつ,「ああ,それ出来ないんだよね」と言ってごまかしてます.僕自身,ビジュアルプログラミング言語をViscuitの前からずっと研究してきていて,まあビジュアルプログラミング言語おたくです.
嫌いというより,TODOみたいなものですが,いつまでたっても短くなりません.
*動かしたくないのに,動いちゃう.
絵を左右に行ったり来たりさせたいときに,壁を作って,その壁にぶつかったら跳ね返る,というプログラムを作ったりします.結構,発見されます.ところが,壁にぶつかる判定を緩くやっているので(そうしないと,壁をすり抜けることがあるから),結構手前でぶつかったことになってしまいます.
ビスケットの書き換えの特徴は,柔らかいマッチングと柔らかい書き換えです.「A を B に書き換える」があったときAに近い A' は B ではなくてBに近い B' に書き換えられます.このAとA'の差分が B と B'の差分として反映されるようにしているために,書き換えが非常に面白い動きになります.で,このために壁も動いてしまうのでした.
もうちょっと書き換えルールの解釈を変えて,差分の反映はメガネの左右の差分の影響を受ける,という感じで,つまり跳ね返る絵の方はがらっと変化しているから,大きな影響を受けて,壁の方は,左右でまったく同じ位置にあるので,AとA'の差分の影響は受けない,という計算方法にすれば良さそうです.これもやってみましたが,今度は発散することがあって,A'が大きくズレたときのB'の位置が直観と合わない感じになったように記憶してますが,もう忘れてしまいました.
いまは,この二つの計算の中間でやっているはずです.で,それだけだと動いちゃうので,メガネの左右で絵が動いていないときだけは特例として別に計算させてます.非常に僕的には恥ずかしい実装です.
正しくは,それらが滑らかにつながっているような書き換え方法であるべきで,まだその方法は開発されてません.それが見つかったとしても,今のビスケットと互換性が無くなってしまうので,つまり,微妙な調整で動いているプログラムたちは全部調整が狂ってしまうので,Viscuit2 みたいな形で出すときにやるしかないです.だいぶ変わると思います.
*まっすぐ動かしたいのに,曲がっちゃう.
ほんのちょっとでもルールの中の絵が回転していたらすぐに回転してしまいます.これを直すのはほぼ無理なので,壊して作り直しをしてもらいます.まあ反論というか言い訳もあって,世の中で自然なものでまっすぐなものって珍しくて,大抵は曲がってたりします.目をつぶって歩いても普通は曲がります.ロボットも左右のタイヤを独立に動かしてフィードバックが無ければまっすぐ進むのは難しいです.なので,まっすぐ動くのが簡単にできるコンピュータとか機械の方が珍しいのだと思いますが.でも,作っている人の思いはまっすぐなのにまっすぐ進まない,というのは何かやりようがありそうですね.
*「待つ」という機能のダメダメさ
メガネの右側に「1秒」または時計のアイコンを入れると,書き換えが終わってから,それらが次に書き換えの対象になるまでにある時間待つ,と言う機能があります.たとえばこのように使います.
![](https://blogimg.goo.ne.jp/user_image/52/7f/25deb5a5293a0b9353cf8e10d0b582f2.png)
これは,三角からミサイルが発射して,そのミサイルは飛んで行く.発射のところに時計が置いてあるのでその時間だけ待って,また発射されます.このプログラムで待って欲しいのはミサイルの発射であって,ミサイル自身は出たらすぐに飛び立って欲しいわけです.しかし,今の仕様では,ミサイルも動き出す前に待ってしまいます.書き換えのタイミングはそれぞれの絵で管理しているので,たとえば三角だけ書き換えを遅らせるということにすればよくて,時計を三角に重ねる用に置くと三角だけ次の書き換えまで待つ,という仕様にしてもよさそうなんですが,それはちょっと難しくなって,さらにバグの元になりそうなので.
本当は
![](https://blogimg.goo.ne.jp/user_image/4d/97/41e69b430cab89c501710554c6239f30.png)
のようにして,メガネの矢印に時計を置いた方がよくて,書き換えは瞬時じゃなくてゆっくり行われる,という意味にした方がよいです.この方が誤解が少ないと思います.そもそもメガネの右側に時計を入れるというのも不自然で,よく左側に入れる(これは何の意味も無い)間違えも見ます.ところが,これは実装がまた面倒で,書き換えが一瞬で終わらないということは,書き換え対象を書き換えが終了するまでロックして他の書き換えの対象にされないようにするとか.だけど,反射させる壁のような絵は,次々来る絵にマッチしなきゃならないので,待たせるわけにはいかないとか.
メガネにリードオンリーの属性をつければロックはいらないとか,複雑にすれば方法はあるんですが,なかなか良いアイデアが浮かばないです.
*メガネの編集のダメダメさ
メガネはすぐに壊れます.持つところを間違うと,中の部品を出してしまったり,部品を上のメガネに入れたつもりが,下のメガネに入ってしまったり.触っててイライラします.もう少し真面目に作れば,すかっとするのになりそうですが.いま,メガネにはロック機能があって,ロックしている間は中は編集禁止にできます.あとは,メガネを重ねたとき,下になったメガネは自動的にロックされるようにして,ロックされたメガネの上に部品を置こうとしたら,置けないで逃げるとか戻るといった仕様にすればいいかな.早くやれよ,です.
*スクロール
昔はスクロールバーが嫌いでした.スクロールさせたい方向と逆に動かさなきゃないとか.あとペンコンピュータでスクロールバーをいじるのって結構大変で.その時代に作ったものだから,スクロールしません.ところが,iPad的な操作が今は主流になって,無地の部分をドラッグすればその方向にスクロールする,っていうインタフェースが発明されているのですよね.とっとと対応すべきです.何の言い訳にもなりませんが,今のFlashで書かれたビスケットは2008年に作ったものをだましだまし拡張しているもので,いろいろ古いです.
*XXXX
セキュリティに関係するので書けません.
*ファイルが消える
ブラウザをリロードすると消えます.バックボタンでも消えます.Flashでもローカルにデータを保存する機能があるから,それを使えば消えないようにできるのですが,やってません.
ほんとはまだまだあるんですが.最後に.
*新バージョン
新バージョンを作ってます.新バージョンは欲張らずに,上の問題だけ解決すれば良さそうなものなのに,その3倍くらい欲張っているので,まったく出来そうにありません.そんな感じで作りかけのものはいくつか転がってます.でも結局いま動いているやつをやっつけで修正して寿命を延ばしてしまっているのです.恥ずかしくてコードは見せられません.
子供にこれが動かないと言われたとき,そのいくつかはViscuitの仕様と言う名のバグです.言われる都度,ご免なさいと思いつつ,「ああ,それ出来ないんだよね」と言ってごまかしてます.僕自身,ビジュアルプログラミング言語をViscuitの前からずっと研究してきていて,まあビジュアルプログラミング言語おたくです.
嫌いというより,TODOみたいなものですが,いつまでたっても短くなりません.
*動かしたくないのに,動いちゃう.
絵を左右に行ったり来たりさせたいときに,壁を作って,その壁にぶつかったら跳ね返る,というプログラムを作ったりします.結構,発見されます.ところが,壁にぶつかる判定を緩くやっているので(そうしないと,壁をすり抜けることがあるから),結構手前でぶつかったことになってしまいます.
ビスケットの書き換えの特徴は,柔らかいマッチングと柔らかい書き換えです.「A を B に書き換える」があったときAに近い A' は B ではなくてBに近い B' に書き換えられます.このAとA'の差分が B と B'の差分として反映されるようにしているために,書き換えが非常に面白い動きになります.で,このために壁も動いてしまうのでした.
もうちょっと書き換えルールの解釈を変えて,差分の反映はメガネの左右の差分の影響を受ける,という感じで,つまり跳ね返る絵の方はがらっと変化しているから,大きな影響を受けて,壁の方は,左右でまったく同じ位置にあるので,AとA'の差分の影響は受けない,という計算方法にすれば良さそうです.これもやってみましたが,今度は発散することがあって,A'が大きくズレたときのB'の位置が直観と合わない感じになったように記憶してますが,もう忘れてしまいました.
いまは,この二つの計算の中間でやっているはずです.で,それだけだと動いちゃうので,メガネの左右で絵が動いていないときだけは特例として別に計算させてます.非常に僕的には恥ずかしい実装です.
正しくは,それらが滑らかにつながっているような書き換え方法であるべきで,まだその方法は開発されてません.それが見つかったとしても,今のビスケットと互換性が無くなってしまうので,つまり,微妙な調整で動いているプログラムたちは全部調整が狂ってしまうので,Viscuit2 みたいな形で出すときにやるしかないです.だいぶ変わると思います.
*まっすぐ動かしたいのに,曲がっちゃう.
ほんのちょっとでもルールの中の絵が回転していたらすぐに回転してしまいます.これを直すのはほぼ無理なので,壊して作り直しをしてもらいます.まあ反論というか言い訳もあって,世の中で自然なものでまっすぐなものって珍しくて,大抵は曲がってたりします.目をつぶって歩いても普通は曲がります.ロボットも左右のタイヤを独立に動かしてフィードバックが無ければまっすぐ進むのは難しいです.なので,まっすぐ動くのが簡単にできるコンピュータとか機械の方が珍しいのだと思いますが.でも,作っている人の思いはまっすぐなのにまっすぐ進まない,というのは何かやりようがありそうですね.
*「待つ」という機能のダメダメさ
メガネの右側に「1秒」または時計のアイコンを入れると,書き換えが終わってから,それらが次に書き換えの対象になるまでにある時間待つ,と言う機能があります.たとえばこのように使います.
![](https://blogimg.goo.ne.jp/user_image/52/7f/25deb5a5293a0b9353cf8e10d0b582f2.png)
これは,三角からミサイルが発射して,そのミサイルは飛んで行く.発射のところに時計が置いてあるのでその時間だけ待って,また発射されます.このプログラムで待って欲しいのはミサイルの発射であって,ミサイル自身は出たらすぐに飛び立って欲しいわけです.しかし,今の仕様では,ミサイルも動き出す前に待ってしまいます.書き換えのタイミングはそれぞれの絵で管理しているので,たとえば三角だけ書き換えを遅らせるということにすればよくて,時計を三角に重ねる用に置くと三角だけ次の書き換えまで待つ,という仕様にしてもよさそうなんですが,それはちょっと難しくなって,さらにバグの元になりそうなので.
本当は
![](https://blogimg.goo.ne.jp/user_image/4d/97/41e69b430cab89c501710554c6239f30.png)
のようにして,メガネの矢印に時計を置いた方がよくて,書き換えは瞬時じゃなくてゆっくり行われる,という意味にした方がよいです.この方が誤解が少ないと思います.そもそもメガネの右側に時計を入れるというのも不自然で,よく左側に入れる(これは何の意味も無い)間違えも見ます.ところが,これは実装がまた面倒で,書き換えが一瞬で終わらないということは,書き換え対象を書き換えが終了するまでロックして他の書き換えの対象にされないようにするとか.だけど,反射させる壁のような絵は,次々来る絵にマッチしなきゃならないので,待たせるわけにはいかないとか.
メガネにリードオンリーの属性をつければロックはいらないとか,複雑にすれば方法はあるんですが,なかなか良いアイデアが浮かばないです.
*メガネの編集のダメダメさ
メガネはすぐに壊れます.持つところを間違うと,中の部品を出してしまったり,部品を上のメガネに入れたつもりが,下のメガネに入ってしまったり.触っててイライラします.もう少し真面目に作れば,すかっとするのになりそうですが.いま,メガネにはロック機能があって,ロックしている間は中は編集禁止にできます.あとは,メガネを重ねたとき,下になったメガネは自動的にロックされるようにして,ロックされたメガネの上に部品を置こうとしたら,置けないで逃げるとか戻るといった仕様にすればいいかな.早くやれよ,です.
*スクロール
昔はスクロールバーが嫌いでした.スクロールさせたい方向と逆に動かさなきゃないとか.あとペンコンピュータでスクロールバーをいじるのって結構大変で.その時代に作ったものだから,スクロールしません.ところが,iPad的な操作が今は主流になって,無地の部分をドラッグすればその方向にスクロールする,っていうインタフェースが発明されているのですよね.とっとと対応すべきです.何の言い訳にもなりませんが,今のFlashで書かれたビスケットは2008年に作ったものをだましだまし拡張しているもので,いろいろ古いです.
*XXXX
セキュリティに関係するので書けません.
*ファイルが消える
ブラウザをリロードすると消えます.バックボタンでも消えます.Flashでもローカルにデータを保存する機能があるから,それを使えば消えないようにできるのですが,やってません.
ほんとはまだまだあるんですが.最後に.
*新バージョン
新バージョンを作ってます.新バージョンは欲張らずに,上の問題だけ解決すれば良さそうなものなのに,その3倍くらい欲張っているので,まったく出来そうにありません.そんな感じで作りかけのものはいくつか転がってます.でも結局いま動いているやつをやっつけで修正して寿命を延ばしてしまっているのです.恥ずかしくてコードは見せられません.