あなたはだれ？
絶対パス･相対パス
AS講座もついに第03回です。
内容がだんだん難しくなっていくような気がするのは、
間違いなく気のせいじゃありません。
というのも、今回扱うパスというものは、AS独特のものなので、
他のコンピュータ言語の経験がある人でさえ、
ASを勉強する時に真っ先につまづくポイントなのです。
だから、コンピュータ言語を全くやってない人がここで苦労しても
全く恥ずかしくないことですからね。
というか、第09回までの中で間違いなくここが最難関。
ですが、このパスはAS独特のものであると同時に、
ASにとっては非常に重要です。
もし、AS書くときにこれがわからないと、
ASでできることの9割以上はできなくなってしまうでしょう。
たとえば、こんなの。
下の5つのボタンでおにぎりがまわったり止まったりします。
これをASを使わずに作るのは至難だというのはおわかりでしょうか。
くるくるまわるのが1つだけなら、普通のボタンでできるかもしれません。
が、1つのボタンから同時3つのものに指示を出すというのは、
ASを使わなければどうにもなりません。
それも、いままでこの講座でやってないASを。
そう、これをやるのにはパスが必要なんです。
というか、パス以外にこの講座でやってないことは一切使ってません。
ですから、第03回の内容を理解すればみなさんも同じものが作れるはずですよ。
さて、長い前置きでしたが、第03回の内容を始めます。
いきなり上のようなものを作るのは大変なので、もっと簡単なところから始めましょう。
おにぎりが1つになりました。
ボタンも減りました。
実はこれだけならおにぎりの絵をメインでまわして、
2つの画像をボタンとしておけば、AS使わなくても作れるのですが、
勉強のためにAS使ってみましょう。
慣れるとこっちの方が楽ですしね。
今回使うソースをダウンロード
さて、03_00.pflを開きましょう。
で、左ペインにテキストファイルが2つありますね。
もとのソースではHGP創英角ポップ体というフォントを使ってますが、
このフォントが入ってないPCだと変なことになると思うので、
そんなフォントはいってねーよって人や入ってるかどうかわかんねーって人は
まず最初にフォントを各自好きなものに変えてください。2つとも。
で、今までよりやや複雑な状態からスタートするので、
ソースがどうなっているのかしっかりと理解してください。
たっぷり時間をかけても誰も文句を言う人はいませんし。
まず、おいてあるMCが3つ。
1番上はいつものくるくるおにぎり。
下の2つは、ボタンの絵（といいつつテキストですが）が
ポツンと置いてあるだけのMC。
あれ？なんでこれをMCに入れる必要が？と思った方は、
前回の内容を思い出しつつ、今作りたい上のSWFのことを考えてみてください。
そう、onイベントハンドラを書きたいからですね。
本当はテキストのままでも「ボタンにする→＜スクリプト＞」で
onイベントハンドラを書けます。
書けるのですが、パスが絡むと非常にややこしいことになるため、
今回はそっちは避けてMCでやります。
詳しいことを知りたい方は、パスを完璧に理解した後で
PlusOneの手前あたりをどうぞ。
さて、今のソースの状態は把握できたでしょうか？
これを目的のSWFにするためには、
「playをクリックしたらおにぎりのMCを再生」
「stopをクリックしたらおにぎりのMCを停止」
を書ければいいわけですね。
じゃあstopの方から作りましょう。
playの方が上にあるのになんでこっちから作らないのかは、
みなさんちょっと考えてみてください。
いじわるしてるとかそういうのじゃなく、ちゃんと理由があります。
答えはあえてここには書きませんが、
分からない人は、一度今回の内容を理解したあとで、
playの方から作ってみようとすればわかると思います。
AS書くときは、作るべき順番が見えないと悲惨なことになります。
慣れるまでは難しいでしょうけどね。
横道にそれてしまいましたね。
じゃあ、今度こそstopの方を作りましょう。
･･･あ、その前に、この03_00.pflは後でもう1回使うので、
どこかに元の状態をコピーしておいてください。
おっと、また脱線してしまいました。
三度目の正直、stopの方を作りましょう。
書くASの内容は、こうですね。
「stopをクリックしたらおにぎりのMCを停止」
うわぁ、目がチカチカする。
黄色については第02回でやりましたので、すぐわかりますよね？
stopが入ってるMCにon(release)で赤と青を書けばいいでしょう。
次、青。
これも第01回でやったstop()が使えそうです。
今までは自分自身しか止められませんでしたが、
何らかの方法で、他のMCにstop()という命令を出せるようにできるのでしょう。
そう、で、その「何らかの方法」こそが赤部分。
といっても、そのMCの名前を書くだけです。
ということは、あとはタイトル通り、指示を出したいMCの名前がわかればいいだけです。
と書くと、すごく簡単に見えますが、そこが落し穴。
右のスクロールバーを見てください。
残り全部、「MCの名前をどう書くか」というお話です。
説明にこれだけかかるくらい、MCの名前の書き方は非常に難解かつ厄介なのです。
なんせ、他のコンピュータ言語出来る人でもつまづくくらいですから。
あ、ちなみに、この指示を出すための「MCの名前」をパスといいます。
さて、MCの名前を書くためには、
MCに名前をつけなきゃいけません。
おにぎりのMCのプロパティを開きましょう。
ここに半角英数字でわかりやすい名前をつけましょう。
なんで半角英数字なのかはわかりますね。
ASには半角英数字しか使えないので、名前を書くときに困るからです。
一部記号も使えますが、英数字だけでつけるのが無難でしょう。
追記：大事なことを書き忘れてました。
インスタンス名は半角英数字で、と言いましたが、
特殊な場合を除き、1文字目だけは半角英字限定です。
つまり、数字からはじまるインスタンス名はダメなのでお気をつけください。
今回はおにぎりのMCなので、onigiriと名前をつけましょうか。
他の名前がいい人は他の名前つけてもいいですよ。
ただし、後から他の場所でMCの名前を見たときにどのMCなのかわかるようにしてくださいね。
aとか意味のない名前を付けると、後でソースを見たときに
「aってどのMCだっけ、わかんねーようわぁぁん」ってなるのは自分です。
「･･･あれ？名前ついたし、今回の内容終わりじゃね？」と思った方、いるでしょうね。
残念でした。いや、別にだますつもりだとか混乱させるつもりとかじゃないんですけどね。
実は今までずっと「MCの名前」という言葉を使ってきましたが、
単に「MCの名前」と言った場合、
「インスタンス名」を指す場合と「パス」を指す場合があります。
今つけたのはインスタンス名。今回知りたいのはパス。
どう違うのか、こんな例を出して説明してみましょう。
例えば、知り合いに山田太郎さんがいたとします。
で、その山田太郎さんは今会話している人と共通の知人です。
で、その会話中で、「この前、山田太郎がさぁ、〜〜」という言葉が出ました。
会話中でフルネームかよ、とかいうのはおいといて。
山田太郎なんて名前の人、日本にはいっぱいいそうですよね。
でも、この言葉を聞くのが人間なら、
会話の相手とか内容から「ああ、共通の知人のあの山田太郎のことだな」と
なんとなく推測することができるので、会話は成立します。
じゃあ、コンピュータがこれを聞いたらどうなるでしょうか。
コンピュータは推測ということをしません。
というか、勝手に推測して万一間違えられたら困るので、できないようにされてます。
ということで、どうなるかというと、
「山田太郎なんて日本にいっぱいいるじゃねーか」
「どの山田太郎かちゃんと説明しろよバーカバーカ」
ということになります。
仕方ないので、どの山田太郎さんのことなのか、その人の住所も一緒に教えてあげましょう。
住所があればコンピュータでも他の山田太郎さんと区別できますよね。
「○○町の××番地に住んでる山田太郎」
これで十分でしょうか。違いますね。
○○町なんて日本中探せばいくつかあるかもしれません。
そこの同じ番地に別の山田太郎さんが住んでるかもしれません。
「かもしれない」でしかありませんが、コンピュータにとっては
「かもしれない、もなくしてくれなきゃ、勘違いしたら困るだろ！」ということになります。
ということで、もっとちゃんと住所を書きましょうか。
とはいっても、どこから書くかは際限がないので、
このコンピュータは「日本」という地名だけは勘違いなく理解できることにしましょう。
日本は理解するんですから、こう書けば間違いなく理解してくれますね。
「日本の△△県の◇◇市の○○町の××番地に住んでる山田太郎」
これでやっとコンピュータも山田太郎さんを理解してくれました。
めでたしめでたし。
ってことで、「インスタンス名」と「パス」という2種類の「MCの名前」が
この例ではどれになるかというと、
最初に出てきた「山田太郎」がインスタンス名です。
これはSWFの世界では作る人が自由に（といっても半角英数字限定ですが）つけられます。
あ、そうそう。
さっきの例では「同じ家に同姓同名の人がいたらどうすんの？」という点は触れませんでしたが、
SWFの世界では自由に名前をつけられるのですから、
そんなことにならないように計画的にインスタンス名をつけてくださいね。
で、パスはどれかというと、
最後の「日本の△△県の◇◇市の○○町の××番地に住んでる山田太郎」がパス。
インスタンス名にそれがある場所もつけて、絶対に勘違いされないようにした名前。
さて、じゃあ、問題のおにぎりのMCのパスは一体なんなのでしょうか。
あ、長いこと脱線してたので、何しようとしてたか忘れた人は
一度上に戻って確認してきてくださいね。
さっきの例では、「日本」だけはちゃんと認識してくれることにしました。
実は、SWFの世界でも、何も説明しなくても理解してくれるMCが1つだけあります。
それはメイン。
え？と思った方もいるかもしれません。
メインがMC？何を言ってるんだコイツ？と。
ですが、よく考えてみてください。
ParaFla!の勉強をしてるとき、ほとんどの人が
「MC（スプライト）はもう1つ新しいSWFを作るようなものだ」
といわれてMCを作ることを覚えましたよね？
なんでそんなことが出来るのかというと、
実はメイン自体も1つのMC（スプライト）だからなんですよ。
なので、同じような方法で作るのは当然なんですよね。
ただし、メインは特別なMCなので、普通のMCとちょっとだけ違うところもあります。
その1つがインスタンス名。
メインは普通のMCと違って、_rootというインスタンス名が最初からついています。
しかもその名前は変えることができません。
ただ、変えられないかわりに、パスも_rootだけでOKです。
メインだけは何も説明しなくても理解してくれるってのはこういうことですね。
あ、ちなみに「_」ってのは、右のShiftキーの左（ノートPCだともうちょい左かもしれません）の
「ろ」って書かれたキーをShiftを押しながら押してください。
ASで使うので、半角でお願いしますね。
さて、これがわかったら、onigiriのパスがわかるのも近そうです。
_rootにあるonigiriと書ければいいわけですからね。
こういう場合、ASではMCのインスタンス名を.でつなぎます。
見えてますか？ドットです。英語の授業ならピリオドとか言うやつです。
「。」のキーですね。
ということで、おにぎりのMCのパスは、_root.onigiriということになりました。
ドットがものすごく見にくいです。
htmlでディレクトリ名（フォルダ名）をスラッシュでつないでいく感覚に近いので、
サイトを持ってる人はイメージがつかみやすいかもしれません。
余談ですが、htmlみたいなのをスラッシュシンタックスといい、
ASみたいなのをドットシンタックスといいます。
感覚的なものだけじゃなく、根本的にほとんど同じもの。
あー、長かった。
やっと今回の目的達成･･･ではなく、最後の詰めが残ってますね。
忘れている人が多そうですが、パスを知って、
そのパスにstop()という命令を出すことが本当の目的でした。
パスに命令を出すのも、パスと命令をドットでつなげればいいです。
ということで、_root.onigiriというパスを持つMCにstop()という命令を出すには、
_root.onigiri.stop();
と書けばいいわけです。
じゃあ、03_00.pflいじりを再開しましょうか。
今こんな状態でしたね。
さて、書いてみましょう。
クリックしたら〜〜はアレを使えばいいですね。
パスと命令は今書いたとおりです。
さあ、やってみましょう。
できましたか？
構文チェック、動作チェック、忘れないでくださいね？
Training
ここでTrainingってことは、当然お題はこれですね。
|
playの方もASを書き、目標としたこのSWFを完成させましょう。 |
Training
ここでもう1つ。
やや難しいので、自信がある人のみ挑戦してみてください。
自信がない人も、AS講座の先へ進んだりして力をつけたころには
ぜひ挑戦してみてください。
|
最初にお見せしたこのSWFみたいなものを1から作ってみましょう。 できたら、これを機にParaDrawで自分で絵を描くのもやってみてほしいです。 別に絵はおにぎりじゃなくてもいいですし、 動き方も回転じゃなくてもかまいませんし、全部が同じ動きでなくてもいいです。 数も2つ以上常識的な数ならいくつでもいいです。 各ボタンを押したときの動作も自由。 好きに作ってみましょう。 うまく作るとスロットマシンみたいなこともできますね。 自信作が出来たら、どこかのレンタルホームページスペースにでもアップロードして、 掲示板の感想･意見･雑談等スレにでもURLを書き込んでみましょう。 思わず「すげー！」って言いたくなるような作品を期待してます。 あと、すげーと思った人はぜひレスしてあげてくださいね。 以下、これを作るうえで必要な知識を1つだけ。 ･onイベントハンドラの{}の中には命令は複数書ける。 その時、セミコロンでどこからどこまでが1つの命令なのかは理解してもらえるが、 セミコロンごとに改行すると作る人自身が見やすい。 （AS中に改行は変な場所でなければ自由に入れてよい、詳細は第04回。） |
さて、もうちょっとパスについて勉強してみましょうか。
03_01.pflを開いてください。
あ、これはオブジェクトを何も配置していないので、
プレビューしても何も起きません。
パスを勉強するためのpflですから。
メインにtableとchairがおいてあります。
で、tableにcupがおいてあります。
さらに、cupの中にはcoffeeがあります。
さて、まずtableとchairのパスはいいですね？
一応反転で書いておくので、答えてから見てください。
tableのパスは、_root.table
chairのパスは、_root.chair
さて、次はcupのパスについて考えてみましょうか。
cupはtableにおいてあります。
じゃあパスはtable.cupでいいのでしょうか？
違いますね。不十分です。
町の名前から書いても山田太郎さんは特定できません。
さらにさかのぼって、tableがどこにあるのかも書かなくちゃいけません。
ということで、正解は、_root.table.cupでした。
じゃあもうひとつ。
coffeeのパスは？
いいですか、_rootに行き着くまでどこまででもさかのぼるんですよ？
答えは反転で書いておきます。答えてから見てください。
coffeeのパスは、_root.table.cup.coffee
だんだん長くなりますね。
MCが何重にもネスト（MCの中にMCがあること）すると、
パスがとんでもなく長くなることもあります。
まあ、でも、このcoffeeのパスが分かった人はどれだけ長くなっても大丈夫だと思います。
あ、で、_rootに続いてズラズラと書く、このパスの書き方を絶対パスと言います。
はい、そこの嫌な予感がした人、鋭い。
このパスの書き方を、ということは別の書き方があるということですね。
今回の内容にも（絶対パス･相対パス）って書いてありますしね。
ってことで、パスのことについてはここでまだ半分です。
むしろややこしさや難解さはまだ3割。
では、引き続き、もう1つのパスの書き方である相対パスについてやっていきましょう。
まずは、先ほどの山田太郎さんの例を思い出しましょう。
コンピューターは「日本」という地名以外は、それ単独ではわかってくれません。
ということは、「日本の〜〜〜に住んでる山田太郎」という書き方でしか
コンピュータはわかってくれないのでしょうか。
実は、そうではありません。
日本という地名を使わずにわかってもらう方法もあるのです。
それは、その山田太郎さんが住んでる家で、「ここに住んでる山田太郎」と言う方法。
あるいは、山田さんが住んでる家がある町内で、
「この町の××番地に住んでいる山田太郎」と言う方法。
これはいくらなんでも別の山田太郎さんと勘違いする可能性はないですね。
これが、相対パス。
自分自身の場所、ASならそのASを書いた場所を基準にするパスの書き方です。
では実際ASで書くにはどうすればいいのか見ていきましょう。
さっき使った03_01.pflをまた使いましょうか。
たしかMCの構造はこんな感じになっていましたね。
_root ┣ table ┃ ┗ cup ┃ ┗ coffee ┗ chair |
これが見にくい人は、手元のメモ用紙にでも、
MCのネストの関係がパッとわかるような図を書いてください。
というか、この図はスクロールすると見えなくなるんで、みんな書いてほしい気も。
正直言って、相対パスに慣れるまではこういう図がないと死ねます。
さて、相対パスは、ASを書く位置を基準とするんでした。
ということは、当然、厄介なことにASを書く位置によってパスもかわります。
だから「相対」パスっていうんですけどね。
じゃあ最初は、tableにASを書く場合のことを、
つまりtable基準の相対パスを考えてみましょう。
まず、tableを基準としたtableの相対パス。つまり、自分自身。
自分自身の相対パスはいつでも誰でもthisです。
このthisからドットでつないで他のMCのパスも書くわけですね。
ちなみに、thisは省略することもできますが、
省略してもわかりにくくなるだけなので、
常に省略せずに書いておくことを強くお勧めします。
ついでに。勘がいい人は、今まで書いたstop();とかのことにも気づいたかもしれません。
ただstop();と書いた場合、何もパスがないのではなく、thisというパスが省略されたと理解されるので、
知らず知らずのうちにthis.stop();と書いたことになっていたのですね。
これからは自分自身を止める場合もthisを略さずにthis.stop();と書きましょう。
どうもこの講座は横道にそれることが多いですね。
ともかく、自分自身の相対パスはthis、これは覚えてください。
さて、次。
table基準でのcupの相対パスを考えてみましょうか。
thisでtableを指せます。
cupはそこにおいてあるのですから、その相対パスはthis.cupになります。
絶対パスと同じ感覚なので、絶対パスが理解できた人には簡単だったと思います。
では問題、tableを基準にしたcoffeeの相対パスは？
答えは反転で書きます。考えて、答えてから見てくださいね？
tableを基準としたcoffeeの相対パスは、this.cup.coffee
ここまでは絶対パスと同じなので、そう難しくないですね。
さて、難しいのはここからです。
table基準での_rootの相対パスは何でしょうか。
ちょっと考えてみてください。
相対パスを、ではなく、なぜこの相対パスを書くのが難しいかを。
ぱっと見今までと何も変わらない問題なのに、
1つ大きな違いがあるせいで急に難しくなってます。
わかりましたかね？
絶対パスにしろ、これまでの相対パスにしろ、
今までは中にあるMCのインスタンス名をつなげてパスを作れました。
が、今回はtableの中に_rootはありません。むしろ逆。
だから今までと同じようには書けないのです。さぁ困った。
じゃあ、どうすればいいのかというと、_parentというものを使います。
これは「そのMCがおいてあるMC」という意味になります。
これを親MCとか言ったりしますよね。だから_parent。
今回の場合は、tableのところにthis._parentと書けば、
tableがおいてあるMCということになり、すなわち_rootのことになります。
だから、tableを基準とした_rootのパスはthis._parentとなります。
で、tableを基準としたchairの相対パスは、それを使って、this._parent.chairになります。
大丈夫ですか？ついてきてますか？
わかんない人はじっくり考えるなり、
遠慮なく掲示板で質問するなりしてくださいね。
さて、じゃあ問題。
chairにASを書きましょう。
chair基準のそれぞれのMCの相対パスはどうなりますか？
答えは反転してあるので、例によって答えてから見てくださいね。
| _root | this._parent |
| table | this._parent.table |
| cup | this._parent.table.cup |
| coffee | this._parent.table.cup.coffee |
| chair | this |
続いてはcupから。
それぞれのMCの相対パスはどうなりますか？
| _root | this._parent._parent |
| table | this._parent |
| cup | this |
| coffee | this.coffee |
| chair | this._parent._parent.chair |
ちょっとだけ解説も反転で。
_rootのパスはthis._parent._parentなわけですが、
this._parentで「cupがおいてあるMC」ってことでtableのパスになり、
_rootはさらにそれがおいてあるMCなので、もう1回_parentをくっつけて、
「『cupがおいてあるMC』がおいてあるMC」として_rootのパスを書きます。
反転解説ここまで。
最後にcoffeeから。
それぞれのMCの相対パスはどうなりますか？
| _root | this._parent._parent._parent |
| table | this._parent._parent |
| cup | this._parent |
| coffee | this |
| chair | this._parent._parent._parent.chair |
最後のはなかなかにひどいですね。
「このMCがおいてあるMCがおいてあるMCがおいてあるMC においてあるchair」ですって。
Training
今回3度目。
|
最初にやった03_00.pflの改造を相対パスを使って同じようにやってみましょう。 コピーしておいたやつを使って、前半を見ずに改造の最初からどうぞ。 |
問題も全部わかって、Trainingもあっさりできた人は相対パスも問題ないでしょう。
逆にさっぱりわかんなかった人。落ち込む必要はありません。
なんせ、これは最初に言ったとおり、かなり難しい内容で、
初級ASの最大の壁といっていいほどのところですから。
実際、パスがわからないと嘆いていたダン☆おに制作者も複数知ってます。
私を含め、たいていの人が一度つまづくところですし、堂々とつまづきましょう。
わからなければ、わかるまで考えればいいんです。
それでもわからなきゃ掲示板でわからないことを訊けば、
わかる誰かがきっと答えてくれます。
「何がわからないかわからない」というのはさすがに勘弁ですけど。
ということで、いまいち分からない人はぜひ一番上へもう一度戻ってください。
最初にも言いましたが、パスはASにおいて非常に大事です。
ここの理解なくして第04回以降はないと思ってください。
どんな手段を使っても、この大きな壁を突破してください。
ちなみに、今回さえ越えてしまえばしばらくは楽です。
「第04回が書かれる前に理解しなきゃ！」とか焦らなくても、
後から十分追いつけるので、じっくりと、時間をかけても確実にパスを理解してください。
さて、人数は少ないと思いますが、
絶対パスも相対パスもすんなり理解した方は先へどうぞ。
まだパスがあやふやな人は、読んでも混乱するだけなので、
ここから先立ち入り禁止。
PlusOneに入れようかと思いましたが、けっこう大事なことなので、
本編の最後に書かせてもらうことにした相対パスに関する項目があります。
多少難しいことですし、ここを読むことで混乱することもあるかもしれませんが、
これまでの内容が完璧に理解できたのなら、
時間がかかってもかまわないのでぜひこれも理解してください。
今回はASを全てMCから書きました。
でも、ASが書ける場所はMCだけではありません。
第01回でやったように、アクションの挿入→＜スクリプト＞に書くこともあります。
そこにASを書く場合、絶対パスなら全く問題はないのですが、
相対パスだと大問題が発生します。
this･･･ってどこ？ってことですね。
MCに書いた場合は、thisといえばそのMCでした。
さてMCじゃないところに書いた場合のthisは。
答えは、その＜スクリプト＞を置いたMCがthisになります。
例えば、03_01.pflで、tableの中、cupがおいてあるのと並べて＜スクリプト＞をおきました。
_root ┣ table ┃ ┣ cup ┃ ┃ ┗ coffee ┃ ┗ ＜スクリプト＞ ┗ chair |
そこにASを書いた場合、thisはtableを指します。
なので、その＜スクリプト＞基準の相対パスはこうなります。
| _root | this._parent |
| table | this |
| cup | this.cup |
| coffee | this.cup.coffee |
| chair | this._parent.chair |
どうでしょうか？
_rootなんか、うっかりthis._parent._parentと書いてしまいたくなりますが、
＜スクリプト＞で書いた場合は違いますのでご注意を。
同じ位置においたMCに書く場合はthis._parent._parentであってるんですけどね。
あ、そういえば、ASを書ける場所は3箇所あるんでした。
MCと、アクションを挿入する→＜スクリプト＞の他にもう1つ。
画像やテキストファイルのプロパティで「ボタンにする」にチェックを入れて
＜スクリプト＞を選ぶと、onイベントハンドラだけは書くことができます。
ということはその中でパスを書くことになるわけですが、
ここで相対パスを使うことはとてもお勧めできません。
というのは、出す命令の種類によってthisが指す位置が違うという、
とんでもないことになってるからです。
いや、まあ、どういう場合にどうなるのかがわかればちゃんと使えるんでしょうが、
個人的には難しいことを考えるよりも、今回やったようにMCにポツンと置いてしまって、
MCに書いたほうが間違いがないので、
相対パスを使いたい場所ではこっちをおすすめします。
一応、私がいろいろ試した感じでは大まかにこうわかれるっぽいです。
03_01.pflのtable内に絵を置いてボタンにする→＜スクリプト＞を基準にした相対パス
_root ┣ table ┃ ┣ cup ┃ ┃ ┗ coffee ┃ ┗ 絵(ボタン) ┗ chair |
| フレーム操作系 | プロパティ関係 | |
| _root | this._parent | this._parent._parent |
| table | this | this._parent |
| cup | this.cup | this._parent.cup |
| coffee | this.cup.coffee | this._parent.cup.coffee |
| chair | this._parent.chair | this._parent._parent.chair |
なお、合ってるかどうか、保障はしません。
プロパティというのは第08回でやりますが、
今はMCを右に動かしたりそういうことをするASと思ってもらえればいいです。
ま、絶対パス使うか、MCにポツンとおくかするだけでこのややこしさは回避できるんで、
画像やテキストのボタンでは相対パスは意地でも使わない
という選択をするのが一番賢いと思います。
PlusOne：絶対パスと相対パス、結局どっちを使えばいいの？
もっともな質問ですよね。
基本的に、どこからどのMCを指すのも、
絶対パスでも相対パスでも可能です。
じゃあ、いざパスを使おうと思ったとき、
どっちを使ったらいいんでしょうか。
Let's thinking !
注：日本ではLet's thinking !とよく言いますが、英語としては間違いです。
AS講座と全く関係ないですけど。
パッと考えると、絶対パスの方が分かりやすくて、
うっかり間違えることも少なそうな気がします。
でも、相対パスもわざわざこの講座で詳しくやったくらいですし、
何か重要なことのような気もします。
さて、正解は。
答えは、「ケースバイケース」です。
日本語で言えば、「場合によりけり」。
ま、「そんな答えは認めない、どっちか選べ！」と言われたら、
相対パスになるでしょうかね。
この2種類のパス、どこで違いが出るかというと、
主にそのSWFをあとからいじる時なんです。
03_01.pflを例にとりましょう。
そろそろ見なくても中身が分かりそうなくらい使ってますね。
_root ┣ table ┃ ┗ cup ┃ ┗ coffee ┗ chair |
こんな構造してました。
これが、このまま完成で、もうMCのネスト関係が2度とかわらないなら、
絶対パスでも相対パスでも差は全くありません。
ですが、作ってる途中段階で、完成までネスト関係は絶対かわらないと言い切れますか？
あるいは、完成後、そのSWFをいじることは2度とないと言い切れますか？
むしろダン☆おにソースとかなら、あとから改造なんていくらでもするでしょう。
そういうときに、絶対パスか相対パスかってので大きく差が出ます。
実際に03_01.pflを改造するとどうなるか考えてみましょう。
じゃあ、coffeeからtableに何か命令を出していたとしましょう。
まずは絶対パスの場合。
_root ┣ table ┃ ┗ cup ┃ ┗ coffee ←_root.tableで命令を出す ┗ chair |
あ、図が見にくい人は図が出てくるたびに手元のメモ用紙にでも
似たような図をわかりやすく書いてくださいね。
さて、あなたは作ってる途中で、こんなことを思いました。
そうだ、絨毯敷こう。tableとchairは敷いたcarpetにおくことにしよう。
なぜ思ったかは今は触れないことにします。
とにかく、こうなりました。
_root ┗ carpet ┣ table ┃ ┗ cup ┃ ┗ coffee ←_root.tableで命令を出す ┗ chair |
あれ？
命令がうまく出ていませんね。
_rootにtableなんてMCはありません。
tableの住所が変わってしまったので、
coffeeに書いてたASのパスを全部、_root.tableを_root.carpet.tableに
書き換えなくてはならなくなってしまいました。
出してた命令が1つならまだいいですが、
もしこれが100行とかあるASだったりすると悲惨です。
その長いAS全部見直して、ひたすら書き換え作業です。
1つでもうっかり見逃そうものなら、その部分だけちゃんと命令が出なくて、
原因不明のバグ発生という事態になってしまいます。
すると今度はバグ探しのために、どう間違ってるのかわからないまま100行のAS見直し。
こうなるとまさにドロ沼、地獄です。
まして、今はcoffeeからtableへ、だけを考えましたが、
cupにもcoffeeへの命令とtableへの命令が、tableにはchairへの命令が、
なんてあったりすると、それらも全部見直し、書き換えが必要です。
大変だー。
一方、相対パスだとどうでしょうか。
もとの状態がこうです。
_root ┣ table ┃ ┗ cup ┃ ┗ coffee ←this._parent._parentで命令を出す ┗ chair |
そうだ、絨毯敷こう。tableとchairは敷いたcarpetにおくことにしよう。
で、こうなりました。
_root ┗ carpet ┣ table ┃ ┗ cup ┃ ┗ coffee ←_root._parent._parentで命令を出す ┗ chair |
どうでしょうか、ちゃんと命令出てますよね。
今はcoffeeからtableへ、だけを考えましたが、
cupにもcoffeeへの命令とtableへの命令が、tableにはchairへの命令が、
なんてあったりすると･･･大丈夫ですね。
相対パスを使ってると、中の構造が複雑なMCの場所を動かす時に、
その中から中への命令のパスは一切かわりません。
ですから、こんな改造のことを考えれば、
ここは相対パスで書いておくべきだ！ということになるわけです。
じゃあ、何でもかんでも相対パスで書けばいいのでしょうか。
実は、そうでもありません。
こんどは別の改造をしてみましょう。
相対パスの場合のもとがこうでしたね。
_root ┣ table ┃ ┗ cup ┃ ┗ coffee ←this._parent._parentで命令を出す ┗ chair |
ここで、あなたはあることに気がつきます。
あ、コーヒー皿がない！
ってことで、急遽tableにplateを用意し、cupはそこに乗せることにしました。
_root ┣ table ┃ ┗ plate ┃ ┗ cup ┃ ┗ coffee ←this._parent._parentで命令を出す ┗ chair |
あれ？
命令先がtableじゃなくplateにいっちゃいました。
ASを全部見直して_parent1つ増やさなきゃ。困ったもんです。
これがもし、絶対パスで書かれていたらどうなったかというと、
_root ┣ table ┃ ┗ cup ┃ ┗ coffee ←_root.tableで命令を出す ┗ chair |
あ、コーヒー皿がない！
_root ┣ table ┃ ┗ plate ┃ ┗ cup ┃ ┗ coffee ←_root.tableで命令を出す ┗ chair |
ちゃんと命令できていますね。
ですから、相対パスで書いていた人は、
しまったなぁ、絶対パスで書いておけばよかったなぁ、
と後悔することになります。
さて、以上の2つの例を見た上で、あなたはこのcoffeeからtableへの命令を
絶対パスと相対パス、どっちで書きますか？
_root ┣ table ┃ ┗ cup ┃ ┗ coffee ←tableに命令を出したい ┗ chair |
全員に共通の正解はありません。
自分がこれから先、絨毯を敷く可能性が高いか、コーヒー皿を用意する可能性が高いか。
絨毯を敷く可能性が高い人なら相対パスが正解。
コーヒー皿を用意する可能性が高い人なら絶対パスが正解。
じゃあ、五分五分どっちをする可能性もある人は？
絨毯やコーヒー皿なんて今はまだ思いつきすらしない人は？
もうそろそろ気づいてる人もいるでしょうね。
パスの本当の難しさ、一番の難しさは、ここなんです。
どこを絶対パスで書き、どこを相対パスで書くかの選択。
ここで間違えると後で改造する時にひどい目にあいます。
ちなみに、さっきの、「じゃあ、五分五分でどっちをする可能性もある人は？」の答えは、
相対パスで書くのが正解です。
「思いつきすらしない人」も、相対パスが正解。
なぜかというと、絶対パスで絨毯を敷いた場合、
ASを見直さなきゃならないMCは、4つあります。
仮にchairがなかったとしても3つありますね。
一方、相対パスで書いててコーヒー皿を用意することになった場合、
ASを見直すMCは2つですみます。
だから、ひどい目にあった時にまだ被害の少ない相対パスで書いておくのが正解
ということになります。
さらにちなみに。
絨毯敷いた上でコーヒー皿も用意するという大胆なことをしそうな人の場合、
絶対パスで書いても相対パスで書いてもcoffeeからtableへの命令はどうやっても崩れます。
が、全部が相対パスで書いてあった場合、
cupとcoffeeの間の命令、tableとchairの間の命令だけはそのままでいいので、
相対パスの方がほんのちょっとだけ有利です。
といいつつ結局ほぼ全部見直すはめになるので大差ないですけど。
そんなこんなで、パスって本気で考えると難しいんだよーという、
今回のPlusOneでした。
あ、まった。
まだ終わっちゃだめだ。
後から改造する場合以外にも、もう一つ相対パスが圧倒的有利になる例があります。
それは、同じMCを複数使う場合。
たとえば、tableとchairを2組おきましょう。
改造じゃなく、もとから同じMCを2組おく計画で作ってますよ？
_root ┣ table ┃ ┗ cup ┃ ┗ coffee ←tableに命令を出したい ┣ chair ┣ table2 ┃ ┗ cup ┃ ┗ coffee ←table2に命令を出したい ┗ chair2 |
同じところに同じインスタンス名のものをおくと困るので、table2とchair2に。
中は同じMCを使ってる以上インスタンス名は同じになりますが、
住所が違うので何も問題は起きません。
さて、coffeeから、それぞれがおいてあるtableに命令を出したいとします。
相対パスだと無事に命令できます。
_root ┣ table ←────┐ここへ行く ┃ ┗ cup │ ┃ ┗ coffee ←this._parent._parentに命令を出す ┣ chair ┣ table2 ←────┐ここへ行く ┃ ┗ cup │ ┃ ┗ coffee ←this._parent._parentに命令を出す ┗ chair2 |
これが絶対パスだとこうなります。
_root ┣ table ←────┐ここへ行く ┃ ┗ cup │ ┃ ┗ coffee ←_root.tableに命令を出す ┣ chair ┣ table2 ←───×┐ここへ行かずに、上のtableに命令が行っちゃう ┃ ┗ cup │ ┃ ┗ coffee ←_root.tableに命令を出す ┗ chair2 （同じMCを使う以上、命令先は書き変えられない） |
これじゃあ問題ですね。
絶対パスでこういうのを作ろうと思ったら、
ASの_root.tableを_root.table2に変えた以外は全く同じ
別のcoffeeのMCを用意しなくちゃなりません。
それだけじゃなく、おいてあるcoffeeが今作った別のやつになっている
別のcupのMCを用意しなくちゃなりません。
同じく、おいてあるcupが今作った別のやつになっている
別のtableのMCを用意しなくちゃなりません。
なんだかんだで結局別のMCを作ることになってしまいました。
こうなるとSWFも重くなりますし、メリットは何もないでしょう。
ということで、同じMCを何個か使う場合、
その中から中へのパスは必ず相対パスを使いましょう。
ダン☆おにで言えば、各矢印の中では相対パスを使わないと死にますね。
何百個も流れてくる矢印を全部1つずつMCを作るわけにはいきませんし。
絶対パスと相対パス、どこでどっちを使うかという話を長々としてきましたが、
なんだかんだ言って、結局は経験だと思います。
いろいろ作ってみる間に、感覚的に「あ、ここは相対パスだな」とか
「ここは絶対パスの方がよさげな気がする」とかわかってきます。
そういう感覚は、いろいろなものを実際に作りながら身につけていってください。
以上、今回のPlusOneでした。
Training
意表をついてPlusOneの後のTraining。
2回目のTrainingでちょろっと言いましたね。
お題はこちら。
|
スロットマシンっぽいものを作ってください。 リール3つ、ストップボタンが3つ、 スタートのレバー･･･は難しいのでかわりにスタートボタン、 以上7つが最低でも置いてあるように。 そろった時の判定はまだできないので、 「わーいそろったー」とモニタの前でうれしくなるだけでかまいません。 あと、リールもきれいに回ってるように見せるのは難しいので、 今回は画像を順番に表示するだけでかまいません。 以下、参考手順を書いておきますが、必ずしもこれに従う必要はありません。 むしろ、見ずに作れるならそっちの方が理想です。 ･スタートボタンやストップボタンの画像を用意。 ･リール用の画像を何種類か用意。大きさは揃えること。 絵を書くのが苦手な人は1〜9の数字の絵でもいいかと。 ･それを1コマずつ順番に表示するMCを作る。 同じ絵を何度かおくと、その絵の出現率を上げたりできます。 ･そのMCとストップボタンが置いてあるMCを作る。 ストップボタンを押したらリールのMCが止まるように、 ASを書いたりいろいろする。 ･リールとストップボタンを置いたMCをメインに3つ配置。 ･リールが最初に止まっててほしいので、 第02回の2回目のTrainingを参考にして、 このタイミングでリールのMCを改造。 なぜこのタイミングなのかは各自考えてみてください。 ･スタートボタンをメインに置く。押したら3つのリールが動き出すように。 ボタンじゃなくレバーで頑張る人は、同時にレバーが動くように。 完成！ 以下は作り終えてから反転して見てください。 「こんなの作らなくても簡単じゃん」って人も実際に作るまでは見ないように！ このTrainingのポイントは、このPlusOneの後にあるだけあって、 パスが正しく使えるどうかかだけでなく、 絶対パスと相対パスを正しく使い分けられるかどうかもポイントです。 手順どおりに作った人は、おそらく2箇所で4つのパスを使ったでしょう。 自力で作った人は、場合によっては4箇所で6つかもしれませんね。 まず、2箇所で4つのパスを使った人。 リールとストップボタンをセットにした人ですね。 自力で作ってこう作った人がもしいたら、 かなりAS慣れかSWF慣れしてる人、もしくはかなりのセンスの持ち主ですね。 さて、ストップボタンのAS、同じMCを何個も使うってことを見越して ちゃんと相対パスで書けましたか？ ここはうっかり絶対パスで書くと即死するところです。 また、スタートボタンはどっちで書きましたか？ ここは、どっちで書いたにしろ、考えて選んだなら、合格でしょう。 逆に、何も考えずにパスを書いてたら、どっちを選んでても不合格。 ちなみに、私なら相対パスで書きます。 このリールとボタンをまとめて新しいMCの中に放り込む可能性があるので。 ただ、そんなこと絶対にしないと断言できる人は ミスしにくい絶対パスで書いた方がいいかもしれません。 4箇所で6つのパスを使った人。 リールはリールで3つおき、ストップボタンも普通に3つおいた人ですね。 こっちの方が作り方としては直感的なやり方ですね。 また、全部絶対パスでも書けるため、ミスが少ない作り方もできます。 いい意味で背伸びしない作り方かと思います。 ただ、メインにおくMCの数が増えるので、ソースが見にくくなる欠点も。 絶対パスと相対パスの選択については、上のスタートボタンのとこ参照。 こっちの場合のスタートボタンとストップボタンにも全く同じことが言えます。 |
おまけ。
おにぎりこねこね。
なんか複雑なASで表現しているように見えるかもしれませんが、
じつはASはこの第03回までに使ったものしか使ってません。
大したAS使わなくてもいろいろできるもんですよ？
あ、念のため、ParaFla!の高級な機能使ってるわけでもないです。
本当に基礎的なものだけをうまく組み合わせて作ってます。
興味がある人はこれをどんな方法で作ってるか考えてみるのも面白いのでは。
戻る 掲示板へ