Flash という考え方

Flash という考え方

Web を眺めていると、ときどき驚くほど凝った Flash コンテンツに当たることがあります。ちょっと見た限りでは一体どういうロジックで動いているのか分からないくらいの。しかもユーザからのインタラクションに敏感に反応しつつ全体としての動作の整合性を失わないような。
Flash のコンテンツは、ご存じのとおり MovieClip という小さなムービーの組み合わせで出来ています。そのような「凝った」コンテンツというのは、ほぼ例外なく自律的な MovieClip が多数組み合わさることで作成されているのですね。個々の MovieClip はそれぞれで破綻なく動作し、全体としてもそれぞれの MovieClip がお互いの領域を踏み越えないように協調するがゆえに破綻しない。そういうシステムは、ユーザからのインタラクション (外部からの刺激) に驚くほどリッチな反応を示す傍ら、とても安定した状態を作ることが出来るようです。
思うに、全ての MovieClip の動きをあらかじめ想定し、トップダウンなロジックで全てを組み上げようとしたなら、それほどリッチ、かつ安定したものは構築できないでしょう (どちらか一方は得られるとしても)。これってまさに「オブジェクト指向の恩恵」と呼ばれているものの目に見える成果なんですよね。
全ての UI はそのうち Flash のような考え方で作られていくに違いない、てなことを、PSX の消えない戻りフラッシュアイコンを見ながら思ったのでした(笑。

コメント

うさ (Tue, 24 Feb 2004 16:29:20)

・・・PSXなんて買うなぴょん・・・

かぴさん (Tue, 24 Feb 2004 23:25:44)

アクションゲームなどは太古から各キャラがインタラクティブに独立した動きを見せているわけで。サターンベーシックなんかはスプライトの位置だけでなく速度の情報も持っていて、コードで座標ずらししなくても勝手に動いたりするのだよね。すべてのＵＩはゲームのロジックで作られてゆくに違いないと思ったのでしたマル。

Digitune (Wed, 25 Feb 2004 00:58:39)

それを言ったら PSX はモロにゲームの文法で作られているわけで＞かぴのすけ。君のバルダーもそうだけど、ちょっと前までのゲームって比較的トップダウンなロジックで全体が構築されていることが多かったんじゃない？オブジェクティブな方法論が使えるようになってきたのって、CPU パワーがそれなりに高まってきたここ最近のことのような気がする。

かぴ３ (Wed, 25 Feb 2004 20:35:20)

> それを言ったら PSX はモロにゲームの文法で作ら
> れているわけで

そいつが中途半端なんじゃないのかね。

バルダーがトップダウンかってーとちぃーと問題ありげ
だな。いいたいことはわかるが。一つ一つのブロック＝キャラ
をローカルに処理しているだけなわけで、個々のブロックは
カプセル化されていると見ても良くオブジェクト指向とも
言える。BLOCK型を継承して各キャラのクラスを作るイメージ
と言うか。

一見独立に見えるムービークリップも無限ループ回すと全体が固まったりするわけで、フラッシュは割と同期を意識して作られてる感じがすげーするけどもね。ローカル制御とグローバル制御は一長一短なんでどっちか一方てーんじゃなく栄養のバランスよくエコロジカルに配合されているべきなんだよ。

あとＯＯとＣＰＵパワーとの相関を科学的に分析して説明すれ。

Digitune (Wed, 25 Feb 2004 22:56:24)

バルダーをオブジェクト指向とは言わない。

オブジェクト指向の定義はさまざまだが、こないだ読んだいわゆる「スリーアミーゴ」の本によると、そのメリットとして「人間が普段用いている抽象的な概念を直接プログラム・モデルに反映させられることで理解しやすくなる」があげられている。
つまり、旧来のプログラミング・モデルが、プログラマーに対して本来実現したい抽象概念を無理矢理ノイマン型コンピュータの理解出来るモデルへ翻訳することを強要するのに対し、オブジェクト指向モデルではそのままの形でモデル化出来る点がメリットであるといっているわけだ。

バルダーの場合、プログラム構造は確かに極めて局所化されているが、その局所化、カプセル化が本来実現したい抽象概念とはまったく異なるレベルに構築されている。つまり結局は、プログラマーは本来実現したい概念 (バルダー君、石、蝶…) をその局所化されたブロックで構成される「バルダーシステム」に翻訳することを強要されている。それはオブジェクト指向的とは言わないんじゃないかと思う。

OO と CPU パワーの相関について、実際的な話をしても無意味 (単に実装の優劣を比較するだけになってしまう) なんで概念的な話をするが、「オブジェクト指向」が上記のようなものだとするなら、かつてはプログラマー自らが行っていた「概念を計算機に翻訳する」という作業の一部を計算機に行わせていることとなり、相対的に作業量が増大することは明らかだろう。

ところで Flash が同期的であるのは、あくまでも「Flash のステージ、Flash という世界が同期的である」だけでしょ。TSS システムが jiffy 単位で同期的であるとか、現実世界がプランク時間単位で同期的である、ってのと同義。

かぴ３ (Fri, 27 Feb 2004 01:01:47)

> 「スリーアミーゴ」の本によると

どれほど優れた本も読み手の解釈で如何様にもなってしまうからこわいわな。

キャラ自身の情報・動作の記述はバルダーであってもなくても同様に定義可能であって、単に空間にマッピングされた情報を持っているかいないかぐらいの違いでしかないんだよ。つまり、個々のオブジェクトを位置情報に基づいてマッピングしてから各オブジェクトのメソッドを呼び出すという上層の記述があるかないかぐらいの違いでしかない。どっちにしても上層は必要なのでここでマッピングするかどうかってだけ。バルダーの場合はマッピングしっぱなしだが、これによって構造や記述が変わるわけでもない。

次。「概念を計算機が翻訳するから作業量が増す」とのことだがプリコンピューティングが可能ならＣＰＵパワーはそれほどいらない。なのでプリコンピューティングが不可であることを示さなければ「明らか」とは言えない。

最後。「フラッシュのバックグランドが同期なだけ（暗黙的と言いたいのかな）」とのことだが、フラッシュは基本的にタイムラインを意識しまくる作りなので同期の部分をバリバリに見せている。実際にアニメをいくらか作ったときはこれがヒジョーにうざかった。ムービークリップの出現と消滅を自律的に制御できなかったと思ったぞ確か。動きの記述は自律的だがね。イベント処理はすぐに返さないといかんけどもね。計算の遅れたやつだけ遅く動かすとかやりたいときもあるけどもね。が、たいがいは同期的なほうが便利なのでフラッシュは今時分の現実的なレベルでそれなりにまとまってる環境でしょーな。いじょ。

Digitune (Fri, 27 Feb 2004 08:39:21)

バルダーについて：
おぬしは空気を吸うように「概念をプログラムに変換する」作業を行ってしまっているんで気がついていないんだろうが、オブジェクト指向ってもっとバカっぽいレベルの話なんだよ。つまり、
> 上層の記述があるかないかぐらいの違いでしかない。
その「上層がある」ことが重要。DCT だの MergeSort だの旧来の計算機的な概念レベルから、顧客だのバルダー君だの昔は「プログラム外」でしか定義出来なかった概念まで含めてプログラム中で定義可能とするのがオブジェクト指向のメリットであり技術なわけだ。この「上から下まで全て」という部分が俺も (また例の本でも) 重視しているところであって、そういう意味で、上位概念がプログラム側に欠如しているバルダー君は本当の意味ではオブジェクト指向的とはいわない。
よく、「C でも static 等で外部からデータ隠蔽されてアクセス API のみを提供されているようなライブラリはオブジェクト指向」という話があるが、確かにそのライブラリだけを見ればオブジェクトっぽく見える。しかし C の場合、かなり注意深く作らなければ、そのライブラリを使って作られる、より上位の概念はプログラム中で明確化出来ない。つまり簡単に「オブジェクト指向的」でなくなってしまう。

プリコンピューティングについて：
プリコンピューティングという形で処理を分散可能だと考えると、確かにかぴのすけの言う通り、本質的に OO が (実行時) CPU パワーを使うのかどうか、という点について明確な結論が出ているという話は俺も聞いたことがない。
事前に完璧な動態分析を行ってカリカリにチューニング出来るようなコンパイラの存在も想像出来るし、上位概念をプログラム中に持っていることでより高度な最適化を実行時に行うことが出来、結果的に (そのような最適化処理を行ってもなお) 実行時 CPU パワーを削減出来る場合があることは、既にいくつかの事例で見られることだ。
というわけで、ここは「既存実装全般の傾向として OO は重い」というレベルまで撤退することにする。

フラッシュの話：
> ムービークリップの出現と消滅を自律的に制御できなかったと思ったぞ確か。
生まれいづることを制御出来る個体はいない、っつーことで。
まぁ Flash はもともとアニメツールなんで今はタイムラインをあれほど意識させるんでしょうが、今後 Macromedia が言うような「汎用 UI 作成ツール」に進化するなら、その辺ももう少し洗練されてくるんじゃないの？

> 計算の遅れたやつだけ遅く動かすとかやりたいときもあるけどもね。
例のカートゲームでは実行環境のスクリプト実行速度によって動的フレームレート制御を行っているわけだが、あれはタイムラインの遷移とは独立にスクリプト内で絶対時間を見ていて、それによって各フレームでの描画内容を切り替えてしまうことで対応しているんだな。そういう意味で激しく Flash の精神を冒涜しているというか、古いゲームの文法で書かれているプログラムなのだった。

Digitune (Fri, 27 Feb 2004 09:11:56)

にゃお、当初のかぴのすけの疑問には「実行時」なんて話は出てきてなかったわけだが (実行時限定でなければ俺の最初の話でおしまいだ。プリコンピューティングだって CPU を使うことは間違いナイ)、そこは話の流れ的に俺が譲歩した、ってことで。
勝手に違う問題を持ち出すのはほんとはずるい手だぞ。

かぴ３ (Fri, 27 Feb 2004 21:13:26)

なげーなークリリン。

バルダーが典型的ＯＯだってんでなくＯＯ的な視点で見ることも出来るぞとゆっていたわけだが。

そもそも物体そのものに位置なんてプロパティーはないんだよ。閉空間とかその他物体が与えられたときに相対的に不可抗力で位置情報が発生するものであって、それらの存在を無視したら位置なんてものはキャラ自体には存在しない。持つべきは内部プロパチーのみだ。

その点、バルダーは各キャラに内部プロパチーと振舞いの情報だけ持たせ、それらの空間（空間もひとつのオブジェクトと考える）への配置と移動（本当にメモリ空間を移動する）によって世界を構築しているのでむしろ現実の自然界をモチーフとした素直な構造を持っているということで真のＯＯと言える。フラッシュこそ偽者。

・ぷりこん

この話のぷりこんなんてのはせいぜいコンパイラの範疇だがそのレベルでＣＰＵパワーがそんなに問題だったかというと問題じゃなかったからプリコンの処理時間はデフォで無問題なんだよ。だから暗黙のうちに実行時に限定なのだ。

・フラッシュ

出現が自律で出来ないことに関してはもともと特に問題を感じていないな。自律で終了を決定できないことがうざかった。ちうことで現状フラッシュのキャラ制御ＯＯ度はそこいらのアクションゲーよりへぼ。

あと可変フレームは計算の遅れたやつだけ遅く動かすのと全然違うので無関係だな。

と、けなしてばかりいるとグレるかもしれないのでほめとくと、カートレースなかなか良くできてるじゃん。重いけど。まんじうかわいいよね。

つーことー。ぽえー。

Digitune (Sat, 28 Feb 2004 09:30:56)

ナゲーか。すまん。

かぴのすけは実行時モデルとプログラミング・モデルを混同してるんじゃなかろうか。バルダーは状態遷移マシンとして全体が設計されているわけだが、状態遷移マシン自体は OO とは関係がない。OO でも実装出来るし、旧来のモデルでも実装出来るからね。また、状態遷移マシンをして「OO」だ、という見方も一般的だとは思えない。概念的に別のレイヤーの話だと思うんだよ。

かぴのすけが OO をそういうものとして理解しているんだとすると、その理解は広すぎると思う。OO ってもっと馬鹿っぽい話なんだってば。

ちなみに状態遷移マシンによる実装、ってのはとてもナイスだと俺も思うぞ。ローランでパクッてるわけだし。

> だから暗黙のうちに実行時に限定なのだ。

ははは。ずりっちー。

> 自律で終了を決定できないことがうざかった。

制御出来なかったっけ？自分自身に対して unloadMovie って出来なかったか。

> あと可変フレームは計算の遅れたやつだけ遅く動かすのと全然違うので無関係だな。

Flash で絶対的なのは、
・みんな揃ってタイムラインに合わせ進むこと。
・スクリプト実行は途中でキャンセルされない。
だと思った。これってゲームでも当たり前なんじゃない？計算が間に合わないと flip しないから今も昔も「処理落ち」する (スプライトハードの場合はどうだったっけ？描画されなくなっちゃうこともあったような…)。
どっちかっつーとかぴのすけの言う、「処理の遅れたヤツだけ遅く動かす」って方がムズカシそうだが…。
処理自身は並行に実行する thread でやらせて、world tick とは独立して動かす、とか出来ると綺麗なのかな？

カートが重いのは、疑似的にラスタ制御と同様のことを行ってるからだな。ラスタハードなら軽かったんだが、ソフトでエミュレートすると激しく重い。まぁそういうもんだ、とゆーことで。

かぴ３ (Sat, 28 Feb 2004 21:59:22)

・ばるだＯＯ

実行時の挙動をしてＯＯだとゆっていた意図はなんらなかったわけだが。もしそのように取ったのなら曲解の可能性が高い。

・はにーふらっしゅ

アンロードはクリエートされたやつだけとか制限があったはずだが。割と制限多いんだよフラッシュ。

処理が中断されないのはゲームでも一緒だし、それが違うともゆってない。いちいち中断されると動きの整合性が壊滅的に予測しにくくなるので非実用的だ。このようなフラッシュやゲームの動きが悪いなどとは思ってもいないしゆってもいない。適当レベルの独立性と協調性があったほうがいい。大事なのはバランスで極端なのは何事もたいがいうまくいかない。過ぎたるは及ばざるが如し。それが俺のルールだぜ。

> カートが重いのは

自前で描画しなかったからだよ。あの環境は描画量とあんまり関係なくムービークリップの数で重くなる。実際、動くか動かないかギリギリの線のブツをいろいろ作ったりして試したから。

Digitune (Sun, 29 Feb 2004 12:06:56)

疲れたからそろそろやめよーぜ。

バルダー：
「実行時挙動」ではなく「実行時モデル」。OO の結構重要なポインツは「分析を放棄できる」という姿勢だと思う。「上から下まであらゆるレベルで概念モデルを作成できる」ってことはそういうことだ。例えば「その点、バルダーは各キャラに内部プロパチーと振舞いの情報だけ持たせ、それらの空間（空間もひとつのオブジェクトと考える）への配置と移動（本当にメモリ空間を移動する）によって世界を構築しているのでむしろ現実の自然界をモチーフとした素直な構造を持っているということで真のＯＯと言える。」とのことだが、プログラム中で「バルダー」を表す明示的なクラスはなかったように記憶している。概念的には「バルダー」に属するロジック (プロパティではなくロジック) も、「空間」の方のロジックに織り込まれてなかったっけ？
空間の方がオブジェクトに働きかける、アフォーダンス的発想なんだよ、とか言えば言えなくもないけど、「バルダー」という概念を、「空間」を通してしか操作できない (一段分析フェーズが必要) という構造は、あまり OO 的とは言えんだろう。この辺はかぴのすけがバルダーをデバッグしてる時に、微妙な石の挙動なんかをある種試行錯誤的に「空間」のパラメータを変更することで行っていた (石そのもののロジックを分析、空間のロジックに適用) あたりの印象からの判断だ。

結局、「『バルダープログラム』ではそもそもバルダーという概念を明示する必要はなく、言ってみればコンウェイのライフゲームにおけるグライダーのようなものとして、つまり『空間における一現象』としてしか扱っていないのだー」ということなんだろうな。コンウェイのライフゲームを OO 的に実装することは可能だし、その場合に「グライダー」クラスが現れないことはたぶん当たり前だろう。プログラムで表現したい概念のレイヤーからグライダーのレイヤーは外れているからね。

> アンロードはクリエートされたやつだけとか制限があったはずだが。

あーなんかあったような。それなら全部動的ロードにしちゃえー。

> 自前で描画しなかったからだよ。

Flash 5 までを動作環境に含めようと思うと、自前描画手段は取れなかったんじゃなかったと思う。自前で描画出来るようになったのは Flash MX 以降じゃなかったかな。
Flash 5 はスクリプト実行スピードも遅くて２重苦なんだよね…。

かぴ３ (Sun, 29 Feb 2004 19:45:42)

> 疲れたからそろそろやめよーぜ。

の割にまたなげーなークリリン。こっちゃ短くいくぜ。

・ばるだ

実行時モデルすなわち「実行時のオブジェクト構造・振舞いのモデル」を「実行時の挙動」と表現するのはアリなんで。

当時のバルダのコードは割とつらつらと記してあったのでそいつにイメージにひっぱられているようだが、オブジェクトの捉え方なんかは単に物の見方であって「こうでなきゃいかん」というものでもなくいろいろだから「こういう風に取らないとＯＯじゃない！」というもんでもない。

つーこって、

　　　ＯＯ信者はＯＯの呪縛に捕らわれ過ぎなんだよ！

と、また波乱を呼ぶようなことをゆってみる。

いじょ。

Digitune (Sun, 29 Feb 2004 23:11:27)

> ＯＯ信者はＯＯの呪縛に捕らわれ過ぎなんだよ！

つーか、OO ってのは人と人とのコミュニケーションを潤滑にするための道具であるからして (構造化とか OO 以外のプログラミング・モデルも全てそう)、あんまり一般的じゃないものに対しても「OO」と言っちゃうと概念的に曖昧になって意味なくなっちゃうんだよ。そんためにデザインパターンとか先人はいろいろ苦労してるわけだし。頼むよ一つ。

モデルの取り方とかがいろいろ、ってのは確かにそうだがね。しかしライフゲーム的手法を積み重ねて複雑なシステムを作るんは神様でもなきゃ難しいわな (で、それが自己組織化という話で…と繋がる。わはは)。

かぴさん (Sat, 06 Mar 2004 12:50:20)

バルダの空間オブジェクト＝フラッシュ、と捉えればあとのレベルはまったく同等にできる。空間、環境が既存のものとすればＯＯに落とし込める。空間側のサービスはキャラの配置サービス程度で済むのでこれは無視できる範囲。実装メソッドを実質的にＯＯと同等にできるので必死に線引きをするほどのものではないのだヨ。