約 4,024,090 件
https://w.atwiki.jp/mizcremorne/pages/274.html
はじめに スクリプトのサイズ モジュール化の概念 モジュール化の手法 ドア・システム・スクリプト基本的なモジュールslide door module standard door module door main module short touch module group touch module 拡張モジュールsensor module phantom door module モジュール化の効果 モジュール化のデメリット はじめに LSLでは巨大なプログラムを作ることができません。 というのも一つのLSLのサイズは16KByteまでという制限があるためです。 この制限は、スクリプトコードの本体のサイズだけでなく、スクリプトが動作したときのメモリを含めたサイズです。 スクリプトを正しく書いていても、サイズが大きくなって16KByteの制限を越えてしまうと、 「Stack-Heap Collision」 などのエラーが発生し、スクリプトは動かなくなってしまいます。 今回はこの問題に対処するための、中級者向けのお話をしておきます。 スクリプトのサイズ メモリとかコードサイズと言われても何のことやら、という方もいらっしゃると思いますので、簡単に解説します。 解説なんかいらんからサンプルコードを見せい！という方はこちらまで読み飛ばしちゃって下さい。 スクリプトが動作するときには、当然ながらサーバーのパワーを使うわけですが、一つのスクリプトが動作するときに使えるパワーには限度があるということです。 ここで言う「サーバー側のパワー」というのは、スクリプトが動作するための場所のことです。 たとえば、学校の校庭を思い浮かべて見て下さい。 校庭ではいろいろなスポーツが出来るようになっていますが、面積には限りがありますよね。 テニスならば4面取れるけど、サッカーをするときは1面しか取れないとか。 コンピュータ上で何かプログラムが動くときは、校庭にコートを確保するのと同じように、プログラムが動作できるスペースを確保して動くようになっています。 このスペースのことを「メモリ」と言います。 LSLは、このメモリの大きさが16KByteまでに制限されているのです。 校庭のごく一部だけを自由に使えるようなものです。 16KByteというのがどのくらいのサイズかと言うと、例えば、 "こんにちは" という文字データは、1文字4Byte、5文字なので20Byteです。 16キロByteというのは約16,000Byteのことですので、 "こんにちは" に換算すると800個分ですｗ 「おお、800回も"こんにちは"が言えるのか！」 とは思わないで下さい。 今回の記事のここまでの記述をデータ量に置き換えると、1,700Byteあります。 わずか30行程度の文章でそこまで行きますので、16,000Byte程度ならあっという間に埋まります。 あるいは、皆さんが今使っているかもしれない、インターネットのブラウザ。 私は先ほどインターネットエクスプローラを立ち上げてみましたが、何のページも表示していない状態で、使用メモリは6,000KByteでした。 6,000KByteというのは6,000,000Byteのことです。 16,000Byteと比べると桁違いですね（＾＾； 「たった16KByteしか使えないのか！」 と思っていただければ幸いです。 スクリプトのサイズを制限しているのは、言うまでもなくサーバー負荷を軽減するためでしょう。 無制限にメモリを使えてしまったら、一本のスクリプトが校庭全面を占拠して、 「今日は俺様のリサイタルだ～！」 などという暴挙が可能になってしまいます。 そんな野望を阻止するため、スクリプトのサイズは16KByteに制限されているわけです。 しかし・・・。 「お、お願いです、うちには相撲取りの息子が5人も居るんです・・・」 「ええい、黙れ！配給は一家につきイモ16個と決まっておる！」 「そ、そんな、それでは息子たちは食べていけません！」 「うるさいヤツめ、ならば食わなければよかろう！」 我々はそんな抑圧された環境下で、黙って耐え忍んでいくしかないのでしょうか。 モジュール化の概念 16KByteの制限はLSLの仕様ですので、これを打ち破ることは不可能です。 一つのスクリプトは必ず16KByte以内で収まるように作らなければいけません。 ですが、複雑なことをしようと思うと、どう頑張ってみたところで16KByteには収まりきらないという事態が起こりえます。 この限界は想像以上にすぐにぶち当たる壁です。 そして、正面からぶつかっていっても、絶対に越えることのできない困難な壁でもあります。 ではどうやったらこの壁を越えることができるでしょうか。 その答えは少年ジャンプあたりを読むと書いてあります。 少年ジャンプのストーリーは「努力」「友情」「勝利」がテーマなんだそうです。 最近のジャンプは知りませんが、ドラゴンボールなどはまさに典型的ですよね。 スクリプトの限界サイズは「努力」しても越えることができません。 こうなると「友情」に頼るしかありません。 一人の小さな手では何もできませんが、皆が集まると何かできてしまうのです。 これがLSLのモジュール化の発想です。 つまり、一つのスクリプトの限界は16KByteですが、複数のスクリプトを組み合わせ、全体として一つの大きなシステムにしてやるのです。 スクリプトの機能を分化し、連携して動くようにすることをモジュール化と言います。 モジュール化してやれば、トータルで見たときには16KByteの制限を越えるシステムを作ることが可能になります。 また、モジュール化には他のメリットもあります。 第一に開発効率が良くなります。 ダイアログモジュールやリッスンモジュール、アニメーション、サウンドなどをモジュール化しておくと、次にそれらの機能を使いたいときにはそのモジュールをほぼそのまま使うことが可能です。 一つ一つのスクリプトにいちいちリッスンやアニメーションのわずらわしいコードを書く必要がなくなります。 メンテナンス性の向上もみこめます。 モジュールごとに機能が分かれていれば、何か修正するときには一部のモジュールだけを更新するだけでOKになります。 例えばゲームの点数やRPGシステムの経験値など、データを保存するようなスクリプトの場合、スクリプトを修正するとデータはリセットされてしまいます。 しかしモジュール化によってデータを管理するスクリプトと、他の機能のスクリプトが分かれていれば、データ管理のスクリプトを修正しない限りはデータは保持されます。 また、拡張性も高くなります。 機能が分割されていますので、新しい機能を追加するときには別のモジュールを作って追加すれば良いのです。 例えば、オブジェクトの色が変わる機能を追加したいと思ったら、色変更用のモジュールを追加するだけです。 モジュール化を上手に実現しておくと、もとからあるスクリプトを一切いじらなくても大丈夫です。 モジュール化の手法 モジュール化を行うには、別に難しいコードを書く必要はありません。 初級スクリプトでも解説しているリンクメッセージ機能を利用すれば良いのです。 リンクメッセージは違うprimのスクリプト同士で通信を行う機能として紹介しましたが、実は同じprim内のスクリプト同士の通信も可能です。 同一prim内のスクリプトへのリンクメッセージ送信： llMessageLinked(LINK_THIS, integer ,string, key); 同一オブジェクト内（全リンクprim）のスクリプトへのリンクメッセージ送信： llMessageLinked(LINK_SET, integer ,string, key); この二つを知っていれば十分にモジュール化は可能です。 モジュールのイベントは基本的に全てlink_messageイベントに統一しておきます。 普通のLSLの構造は、「きっかけ」があったら「処理」を行うものだと何度も説明していますが、「きっかけ」をリンクメッセージだけに統一してしまうのです。 そして「処理」のほうは実現したい機能に応じたものを書きます。 つまり、 「リンクメッセージを受信したら、何らかの処理を行うスクリプト」 これがモジュールの基礎スタイルになります。 イベントをリンクメッセージのみに限定することで、考えるべきポイントは「いかに処理を行うか」だけになります。 処理を実現する仕組みのことを「ロジック」と言いますが、このことから、こうしたモジュールを「ロジック・モジュール」と私は勝手に呼んでいます（＾＾； 要するに「処理」が主体のモジュールのことです。 一方、タッチやリッスンなど、外部からの操作を受け付けるモジュールもまた必要です。 アバターが直接リンクメッセージを送る方法はありませんので、 「タッチされたらリンクメッセージを送る」 「コマンドを聞いたらリンクメッセージを送る」 というような、先ほどの「ロジック・モジュール」とは逆の働きをするモジュールを用意しなければなりません。 これらは様々なイベントを受け取りますが、あくまでも「処理」は「リンクメッセージの送信」です。 私はこれらのモジュールを「イベント・モジュール」と呼んでます。 ロジック・モジュールイベント：リンクメッセージ 処理：任意 イベント・モジュールイベント：任意 処理：リンクメッセージ さてさて。 少し具体的に考えて見ましょう。 例えば、ドア・システムのモジュール群です。 あんまりモジュール化するメリットはないかもしれませんが、説明するのにわかり易いと思うので（＾＾； ドアと言っても、いろんな種類のものがありますよね。 初級スクリプトの記事の中でも、回転して開くドアや自動スライドドアなどを作りました。 同じ自動ドアでも、センサーを使ったもの、衝突判定を使ったものなど、作り方を変えることもできました。 そんな風にいろいろな実現方法があるドアを、モジュール化することでひとまとまりの「ドア・システム」にし、どのモジュールを使うかによって回転ドアになったり、スライドドアになったり、はたまた自動ドアにする、手動ドアにするなど、自由自在に組み替えられるようにしてみたいと思います。 まず、ロジック・モジュール。 「処理」を実現する部分です。 今回はドアですから、「ドアの開閉」を実現できればどんなものでも良いでしょう。 ドアの開閉方法はいくつか考えられますね。 回転 スライド（横に限らず。上下とかも） 薄くなって消える 穴が開く／削れる（ホロウやパスカットを使用した変形） 開・閉のテクスチャ切り替え（開いた画像のときにはファントム化する） 他にもあるでしょうが、まぁこんなところで。 それからイベント・モジュール。 ドアが開く「きっかけ」となる部分です。 これもいろんなものが考えられます。 タッチ（誰でもタッチ可能なものから、特定グループ、オーナーのみ等、様々） 合言葉（リッスンを利用したもの） センサー（自動ドア用） 衝突判定（自動ドア用） タイマー（特定時間で開閉） 基本的にはこんなところでしょうか。 やろうと思えばもっと変なのも出来ますが（＾＾；強い風が吹くと開くとかｗｗｗ 以上のようなモジュールを用意したとすると、ドアを作る際、使いたいものを組み合わせてオブジェクトに放り込むだけでOKになります。 いちいちスクリプトを書き直す必要がなくなります。 また、「風で開くドア」を作りたいと思ったら、追加するのはイベントモジュール一つだけで済みます。 ロジックモジュール部分はなんら変える必要がありません。 そのように使い勝手が良く、拡張も楽なのがモジュール化のメリットです。 ドア・システム・スクリプト 具体的にコーディングしてみましょう。 ここに載せたスクリプトは自由に改造・再利用していただいて構いません。 組み合わせていろいろドアを作ってみるといいでしょう。 なお、モジュール・スクリプトはオブジェクトの中に直接作るのではなく、インベントリ内に作ったほうが後で使いやすいかと思います。 基本的なモジュール slide door module まずは「ロジック・モジュール」をいくつか作ります。 「ドアの開閉の仕組み」です。 インベントリのお好みの位置に新しいスクリプトを作成し、"slide door module"という名前を付けて下さい。 そして以下のコードを記述します。 slide door module vector pos; vector move_to = 0.0, 1.5, 0.0 ; integer opened = FALSE; default { state_entry(){ pos = llGetLocalPos(); } moving_end(){ if (opened){ pos = llGetLocalPos() - (move_to * llGetRot()); }else{ pos = llGetLocalPos(); } } link_message(integer send, integer num, string str, key id){ if (str == "door"){ if (num){ // open llSetPos(pos + (move_to * llGetRot())); opened = TRUE; } else { // close llSetPos(pos); opened = FALSE; } } } } このモジュールはオブジェクト（prim）をY軸方向に1.5ｍスライドさせます。 スライドして開くドアの動きを実現したものです。 しかしながら、あくまでも「開閉の動き」だけしか実現していません。 何をしたときにドアが開くかについては一切記述されていませんので、アバターがタッチしたり体当たりしたところで何も起こりません。 standard door module もう一つ「ロジック・モジュール」を作っておきましょう。 インベントリのお好みの位置に新しいスクリプトを作成し、"standard door module"という名前を付けて下さい。 そして以下のコードを記述します。 standard door module rotation rot; vector rotation_to = 0.0, 0.0, 90.0 ; integer opened = FALSE; default { state_entry(){ rot = llGetLocalRot(); } moving_end(){ if (opened){ rot = llGetLocalRot() / llEuler2Rot(rotation_to * DEG_TO_RAD); }else{ rot = llGetLocalRot(); } } link_message(integer send, integer num, string str, key id){ if (str == "door"){ if (num){ // open llSetLocalRot(rot * llEuler2Rot(rotation_to * DEG_TO_RAD)); opened = TRUE; } else { // close llSetLocalRot(rot); opened = FALSE; } } } } このモジュールはオブジェクト（prim）をZ軸基準に90度回転させます。 一般的なドアの動きを実現したものです。 しかしながら、先ほどのスライドドアと同様、あくまでも「開閉の動き」だけしか実現していません。 ２つの「ロジック・モジュール」を載せましたが、これらのモジュールはどちらも、リンク・メッセージを受信したときに動き出します。 特に、リンクメッセージの文字列が"door"の場合にのみ「開閉動作」を行うようになっています。 リンクメッセージのinteger値がTRUEの場合は「開」、FALSEの場合は「閉」の動作です。 door main module さて、それでは次に、この二つの「ロジック・モジュール」にリンクメッセージを送る部分のLSLを書いてみます。 インベントリのお好みの位置に新しいスクリプトを作成し、"door main module"という名前を付けて下さい。 コードは以下のようになります。 door main module float auto_close_timer = 60.0; integer opened = FALSE; default { link_message(integer send, integer num, string str, key id){ if (str == "action"){ opened = (!opened) * (num == -1) + (num != FALSE) * (num != -1); llMessageLinked(LINK_SET,opened,"door",NULL_KEY); llSetTimerEvent(auto_close_timer * opened); } } timer(){ llSetTimerEvent(0.0); llMessageLinked(LINK_SET,FALSE,"action",NULL_KEY); } } このロジックモジュールは、あらゆるドアに共通した性質・動作を実装したものです。 共通した性質とは「ドアには開・閉の２つの状態がある」という点です。 共通した動作とは「開けてから一定時間が経過すると自動的に閉まる」ことです。 スライドドアであろうと、普通のドアであろうと、開・閉の２状態があることには変わりないし、一定時間経つと自動で閉まる機能があってしかるべきでしょう。 つまりこのモジュールは「ドアの基本的な性質」を実現したものです。 あらゆるドアは全てこのモジュールをコアとして使います。 コードをざっとながめていただくと分かるかと思いますが、このモジュールはリンクメッセージ"action"を受信したときに動き、"door"というリンクメッセージを送信するだけの動きしかしません。 先ほど載せたスライドドア、スタンダードドアはどちらもリンクメッセージ"door"で動き出すようになっていましたから、このメインモジュールからのリンクメッセージを受けて動くということになります。 ドアの動きをスライド式にしたければ、スライド・ドア・モジュールを使い、一般的なドアにしたければスタンダード・ドア・モジュールを使います。 どちらのモジュールを使うにしても、メイン・モジュールは同一のものでOKになります。 short touch module さて、これでロジックモジュールができましたので、次に「イベントモジュール」を作ってみましょう。 「ドアの開閉するきっかけ」です。 インベントリのお好みの位置に新しいスクリプトを作成し、"short touch module"という名前を付けて下さい。 そして以下のコードを記述します。 short touch module float distance = 5.0; default { touch_start(integer detected){ if (llVecDist(llGetPos(), llDetectedPos(0)) = distance){ llMessageLinked(LINK_SET,-1,"action",llDetectedKey(0)); }else{ llInstantMessage(llDetectedKey(0), "There is out of your reach. You can t touch. "); } } } このモジュールは基本的にタッチイベントに反応しますが、距離の制限が付いています。 先頭に定義している変数distanceがタッチが有効になる距離です。 ここに記載した例（distance = 5.0）であれば、オブジェクトから５ｍ以内ならタッチできますが、それより距離があるとタッチしたことになりません。 適切な距離からオブジェクトにタッチすると、リンクメッセージ"action"が送信されます。 このリンクメッセージはドアのメインモジュールで受信され、最終的にドアの開閉が行われます。 遠い位置からのタッチを無効にすることで、ドア開閉の動きはより自然になるはずです（ドアの側にいないのにタッチして開けられるのは不自然ですのでｗ）。 group touch module もう一つイベントモジュールを作りましょう。 インベントリのお好みの位置に新しいスクリプトを作成し、"group touch module"という名前を付けて下さい。 group touch module float distance = 5.0; default { touch_start(integer detected){ if (llVecDist(llGetPos(), llDetectedPos(0)) = distance ){ if (llSameGroup(llDetectedKey(0))){ llMessageLinked(LINK_SET,-1,"action",llDetectedKey(0)); }else{ llInstantMessage(llDetectedKey(0), "Group member only."); } }else{ llInstantMessage(llDetectedKey(0), "There is out of your reach. You can t touch. "); } } } ほとんどショート・タッチと一緒ですが、グループ判定を付け加えてみました。 オブジェクトと同一グループをアクティブにしていないと反応しません。 グループメンバーが適切な距離からオブジェクトにタッチすると、リンクメッセージ"action"が送信されます。 そしてドアメインモジュールを経由し、ドアの開閉が行われることになります。 拡張モジュール ロジック、イベントモジュールともに２つ載せましたが、どちらを使うかは用途に応じて選択すればOKです。 さらには、もっと他のモジュールを用意しても構いません。 必要なことは、 １、イベントモジュールはリンクメッセージ"action"を送信する ２、ロジックモジュールはリンクメッセージ"door"を受信して動く この２点です。 さらに詳しく書くなら、リンクメッセージに指定する整数値と文字列は以下のような意味になります。 イベントモジュールから送信するリンクメッセージ 整数値 文字列 意味 TRUE "action" ドアを開く FALSE "action" ドアを閉じる -1 "action" ドアが開いてれば閉じる、閉じていれば開く ロジックモジュールで受信するリンクメッセージ 整数値 文字列 意味 TRUE "door" ドアを開く FALSE "door" ドアを閉じる 以上のルールを逸脱しなければ、どのようなモジュールを追加することも可能です。 では拡張してみましょう。 sensor module 自動ドアに対応するため、センサーイベントを使ったイベントモジュールを追加してみます。 インベントリのお好みの位置に新しいスクリプトを作成し、"sensor module"という名前を付けて下さい。 せっかくですので、以前すくりぷたXさんがおっしゃっていた段階的な探知を実現してみましょう。 sensor module default { state_entry(){ llSensorRepeat("", "", AGENT, 15, PI, 10.0); } sensor(integer detected){ state wait_level2; } } state wait_level2 { state_entry(){ llSensorRepeat("", "", AGENT, 10, PI, 3.0); } sensor(integer detected){ state wait_level3; } no_sensor(){ state default; } } state wait_level3 { state_entry(){ llSensorRepeat("", "", AGENT, 5, PI, 0.25); } sensor(integer detected){ state activate; } no_sensor(){ state wait_level2; } } state activate { state_entry(){ llMessageLinked(LINK_SET,TRUE,"action",llDetectedKey(0)); llSensorRepeat("", "", AGENT, 5, PI, 5.0); } no_sensor(){ llMessageLinked(LINK_SET,FALSE,"action",llDetectedKey(0)); state wait_level3; } } 遠距離・長間隔の探知から近距離・短間隔の探知へと遷移していき、至近距離に入ったときにリンクメッセージTRUE,"action"を送信し、ドアを開きます。 逆に、至近距離に誰もいなくなったときにはリンクメッセージFALSE,"action"を送り、ドアを閉じます。 これで自動ドアも作れるようになりました。 ショートタッチやグループタッチの代わりにセンサーモジュールを使えば、そのまま自動ドアになります。 phantom door module ロジックモジュールも拡張してみましょう。 バリアのように、薄れて消えるタイプのドアを作ってみます。 インベントリのお好みの位置に新しいスクリプトを作成し、"phantom door module"という名前を付けて下さい。 phantom door module float alpha_max = 0.5; integer opened = FALSE; default { state_entry(){ llSetStatus(STATUS_PHANTOM, FALSE); } link_message(integer send, integer num, string str, key id){ if (str == "door"){ if (num){ if (!opened){ float a; // open for (a = alpha_max; a 0.0; a -= 0.05){ llSetAlpha(a, ALL_SIDES); llSleep(0.05); } llSetAlpha(0.0, ALL_SIDES); llSetStatus(STATUS_PHANTOM, TRUE); opened = TRUE; } } else { if (opened){ float a; // close for (a = 0.0; a alpha_max; a += 0.05){ llSetAlpha(a, ALL_SIDES); llSleep(0.05); } llSetAlpha(alpha_max, ALL_SIDES); llSetStatus(STATUS_PHANTOM, FALSE); opened = FALSE; } } } } } このモジュールはドアを透明にし、ファントム化（幻影）にします。 閉じるときは半透明（先頭の変数alpha_maxに定義した透明度）になります。 開閉のきっかけはリンクメッセージ"door"ですので、スライドドアやスタンダードドアの代わりとしてそのまま使えます。 モジュール化の効果 以上でスクリプトを合計７本、載せました。 今回載せたスクリプトによって、何種類のドアが作れるでしょうか？ イベントモジュール、メインモジュール、ロジックモジュールの３つを組み合わせて使いますが、組み合わせは以下の通りです。 No イベント メイン ロジック ドアの機能 1 short touch main slide タッチするとスライドして開くドア 2 short touch main standard タッチすると回転して開くドア 3 short touch main phantom タッチすると透明になるドア 4 group touch main slide スライドして開くグループ専用ドア 5 group touch main standard 回転して開くグループ専用ドア 6 group touch main phantom 透明になるグループ専用ドア 7 sensor main slide スライドして開く自動ドア 8 sensor main standard 回転して開く自動ドア 9 sensor main phantom 透明になる自動ドア 全部で9種類のドアが実現可能であることがおわかりいただけるかと思います。 スクリプトは7種類しか書いていないのに、9種類の機能が実現できる、これがモジュール化の利点です。 イベントモジュールやロジックモジュールを追加するたびに実現可能なドアは増えます。 例えば、イベント・ロジックともにもう一つずつ追加すると、スクリプトの数は９個で、作れるドアは４×４の１６種類になります。かなりのお得感♪ まぁ、今回取り上げたのはドアですから、わざわざモジュール化しなくてもどれも簡単に作れるだろうとは思います。 しかし、より複雑なものを作るにあたり、モジュール化を念頭にして作っていくのと、ひたすら一つのスクリプトとして組み上げるのでは、後々の効率が大きく異なってきます。 例えば、今回作ったイベントモジュールなどは他のものを作るときにも流用可能なはずです。 仲間と一緒に複雑なシステムを組み上げるなんていうときにも便利です。 リンクメッセージでやり取りする内容さえ決めておけば、あとはそれぞれに分業が可能になりますので。 一つのスクリプトのサイズ上限を克服するための小細工が、ここまでくると実に有用な開発手法であることがお分かりいただけるかと思います。 なんでもかんでもモジュール化すれば良いとは言いませんけども（＾＾； モジュール化のデメリット 良いところばかり挙げて問題点に触れないわけにもいきませんので、最後に補足です。 一つのLSLモジュールは16kのサイズであると、最初に書きました。 逆説的に言うなら、モジュールを１つ作ると16kのサーバーリソースを消費する、とも言えます。 モジュール化が便利だからといって何でもかんでも分割していたら、トータルのサイズはどんどん大きくなっていきますので、一概にメリットばかりではなくなってきます。 また、モジュール間のやりとりにはリンクメッセージを使っていますが、同一prim内のスクリプトが増加すると、一度のリンクメッセージでそれらが一斉に反応することになります。 listenなどに比べれば負荷は軽いとは言え、数が増せばそれなりに重くなっていくのは確かです。 最も良いのは、各モジュールを16k単位に分割することです。 ぴったり分けるのは困難ですから、可能な範囲でモジュールを一つにまとめ、なるべく無駄のない形に仕上げることが最良の道になります。 例えば、一つのスクリプトで済むところを４つも５つものモジュールにするというのは少々安易です。 バランスの問題になりますので、難しいところではありますが。 名前 コメント
https://w.atwiki.jp/cgmtb/pages/290.html
ビアンカ １／１／１ ０：１ × × ×× × ×○ × ○ （自動）全てのプレイヤーは資源を支払う場合、資源として支払ったカードは捨て札に置かれず除外される。
https://w.atwiki.jp/gununu/pages/6524.html
ビアンカ〔びあんか〕 作品名：ドラゴンクエストV 天空の花嫁 作者名：[[]] 投稿日：2012年5月2日 画像情報：640×480px サイズ：96,160 byte ジャンル：[[]] キャラ情報 このぐぬコラについて 2012年4月21日投稿 2012年5月2日修正版再投稿 コメント 名前 コメント 登録タグ 2012年5月2日 ドラゴンクエストV 天空の花嫁 個別ひ
https://w.atwiki.jp/modae/pages/12.html
ある種のモジュールは、演奏時に値が変化しないことが保証されているため、 一度だけ評価すればよい、ということがある。 このようなモジュールはその値を出力する Constant クラスのインスタンスに 置換してよい。 このようなモジュールを「定数モジュール」といい、 定数モジュールを Constant のインスタンスに置換することを 「定数モジュールの最適化」ということにする。 定数モジュールの最適化は、演奏時のパフォーマンス向上を目的として構築時に行う。 定数モジュールについては、それに対する入力を考慮する必要がないし、 prepareNext() を呼ぶ必要もない。 定数モジュールの例： 1 は定数モジュールである。 1 + 42 は定数モジュールである。 sin(phase) は、phase が定数モジュールなら定数モジュールであり、そうでないならそうでない。 sin(phase) + 1 も同様に、phase が定数モジュールなら定数モジュールであり、そうでないならそうでない。 Foo() Bar() は、Foo() と Bar() の両方が定数モジュールなら定数モジュールである。また、Foo() または Bar() が定数モジュールで、かつその値が偽であっても定数モジュールである。それ以外ならそうでない。 （ の両辺が定数のとき、 は定数であり、値は通常の と同じ。 の左辺または右辺が定数で、かつそれが偽であるとき、 は定数であり、値は偽。 || の両辺が定数のとき、|| は定数であり、値は通常の || と同じ。 || の左辺または右辺が定数で、かつそれが真であるとき、|| は定数であり、値は真。 これ以外は定数モジュールでない。 ） 一般に、あるモジュールが定数モジュールかどうかは、そのときの接続状況 （具体的には、InJack に接続されているモジュールの定数性）に依存する。 接続関係が変化すると定数性も変化する。 （定数モジュールの最適化は構築中は行わず、演奏開始直前まで遅延した方がよい） モジュールに以下の API を追加： 現在の接続状況において自らが定数モジュールであるかどうか 定数モジュールである場合、構築時に値を得る（generateOutputs() が使えるか？）
https://w.atwiki.jp/dqhwiki/pages/19.html
基本情報 紹介 特技・呪文 専用スキル パラメーター 特殊効果 キャラクター解説・考察 コメント欄 基本情報 名前 ビアンカ 使用武器 弓 必殺技 想い出のリボン 声優 井上麻里奈 紹介 宿屋を営む一家の娘。 幼少期は男勝りな性格の持ち主だったが、大人になり美しい女性へと成長を遂げる。 困った人をほってはおけない心優しき女性。 （『ドラゴンクエストV 天空の花嫁』より） 早く お父様とフィアンセを探さないと! しっかり者のお姉さん ビアンカ 特技・呪文 □ボタン スキル名称 スキル内容 MP 習得条件 必要ポイント サンダーボルト 雷をまとった矢を放ち稲妻のドームを出現させ周辺の敵を攻撃する 9 - - △ボタン スキル名称 スキル内容 MP 習得条件 必要ポイント さみだれうち 複数の矢を同時に放ちねらった敵に連続でヒットさせる 12 - 6 ○ボタン スキル名称 スキル内容 MP 習得条件 必要ポイント メラ 前方に燃えさかる炎の玉を放つ 4 - 4 メラミ 前方に燃えさかる大きな炎の玉をを放つ 7 メラ習得 8 メラゾーマ 巨大な炎の玉を放ち燃えさかる火柱を出現させる 13 メラミ習得 16 専用スキル スキル名称 スキル内容 習得条件 必要ポイント ラリホー 敵を眠らせる呪文ラリホーを覚える MP消費7 - 6 サンダーボルト強化 サンダーボルトの効果時間が長くなる サンダーボルト習得後 20 さみだれうち強化 △を長押しすると複数の敵を同時に狙えるようになる さみだれうち習得後 8 マルチアロー ノーマルショットで□を長押しすると 複数の敵を同時に放てる - 8 マルチアロー強化 マルチアローでより遠くの敵まで撃できるようになる マルチアロー習得後 5 ストロングアロー ノーマルショットで□をさらに長押しすると強力な矢を放てる マルチアロー習得後 8 ストロングアロー強化 ストロングアロー習得後 5 ターニングキック強化 その1 ターニングキックでより広範囲の敵を攻撃できるようになる - 5 ターニングキック強化 その2 ターニングキックの直後にスピードショットが出せるようになる - 8 さいだいMP+5 さいだいMPが5増える - 10 ちから+5 ちからが5増える - 10 かしこさ+5 かしこさが5増える - 10 ハイテンション維持＋8秒 ハイテンションの持続時間が8秒長くなる Lv32以上 15 MP消費しない率+5％ MPを5%の確率で消費しない - 6 会心時MP大回復 かいしんのいちげき時にMPが大きく回復する Lv32以上 8 瀕死時会心率アップ 瀕死状態の間会心率がアップする - 15 パラメーター スキル名称 スキル内容 習得条件 必要ポイント さいだいHP+10 さいだいHPが10増える - 3 - 3 Lv20以上 6 Lv25以上 7 Lv32以上 8 さいだいMP+5 さいだいMPが5増える - 3 - 3 Lv16以上 6 Lv25以上 7 Lv32以上 8 ちから+5 ちからが5増える - 3 - 3 Lv19以上 6 Lv26以上 7 Lv32以上 8 みのまもり+5 みのまもりが5増える - 3 - 3 Lv23以上 6 Lv28以上 7 Lv32以上 8 かしこさ+5 かしこさが5増える - 3 - 3 Lv19以上 6 Lv24以上 7 Lv32以上 8 特殊効果 スキル名称 スキル内容 習得条件 必要ポイント きようさ小アップ きようさが少し増える - 6 きようさ大アップ きようさがかなり増える Lv28以上 15 みかわし強化小 みかわしの無敵時間が少し長くなる - 6 テンション上昇量アップ テンションがアップしやすくなる Lv22以上 6 ハイテンション持続+2秒 ハイテンションの持続時間が2秒長くなる - 3 会心時MP小回復 かいしんのいちげき時にMPが回復する Lv16以上 3 会心時こうげき力アップ かいしんのいちげき時にこうげき力がアップ - 15 会心時しゅび力アップ かいしんのいちげき時にしゅび力がアップ - 6 瀕死時こうげき力アップ 瀕死状態の間、こうげき力がアップする - 15 瀕死時しゅび力アップ 瀕死状態の間、しゅび力がアップする - 6 キャラクター解説・考察 性能解説 弓による射撃キャラ。そのため空中の相手にも強い。 通常攻撃は誘導性能がついていて、向いている方向の一番近い敵を優先的に狙う。 □ボタン長押しをすると弓を構える状態に移行。移行中は移動出来ないが長押し時間によって複数の効果がある攻撃が可能。 LV３２以上で会心時MP大回復を取得し、力のルビーを複数装備したさいの性能は今作随一の壊れキャラと言える ずっとさみだれうちのターン！ なおさみだれうちは、さみだれうち強化取得後なら照準を付けなくても向いている方向の敵を追尾してくれるため 連打しているだけで敵がいなくなる。みかわし率の高いキメラにも当たりやすい。 高低差があっても自動で追尾してくれるのも魅力。また壁越しでも攻撃してくれる。 今作のメタル系の敵を倒すのにもこの力のルビーを装着したさみだれうちが一番である。 メタル系のモンスターは移動速度が素早く、近寄ることですら困難な場合も多い。 この力のルビーを装着したさみだれうちならば、至近距離まで近づく必要がなく、また照準も自動で合わせてくれるので適当な距離から 適当に放つだけで簡単に会心の一撃が出て倒すことができる。 サンダーボルトは暫く放った場所に雷を発生し続ける特技である。 しばらく留まって範囲内の敵に攻撃し続けるので、とくに狭い場所で使うと効果的。 敵が攻撃を食らっている間に、さみだれうちを当てていくとより殲滅力が増す。 最大の魅力はラリホー。ほぼ全ての敵に効果があるという強力な代物。 前面に円陣で発動し、範囲内の敵全てに効果あり、効果中は行動を一切せずダメージも倍増という至れり尽くせりの呪文。 これとサンダーボルトによる継続ダメージでテンションアップもお手軽。 大型モンスターには効きづらい者もいるが、効かないというわけではないので何度も当てると眠る。 中盤の山場キングレオでさえ眠る。原作よろしくゴーレム系は100％ラリホーが入るためハメ殺しが可能。 補助呪文系はAI任せの時でも優先して使ってくれるためお供としても役立つ。 なおゲージ貯めは□貯め１の赤い爆裂弾か、□貯め３の青い貫通だんが最適 とくに貯め３の貫通弾はギガンテスなどの大型ボスに決めると一射でテンションゲージが半分貯まる時も… メラ系列は前方にしか飛ばず、追尾もなく射程も短い。 他の技が使い勝手が良すぎるので、わざわざ使う必要性が無い不遇の呪文と化している。 必殺技のゲレゲレは縦の射程はあるが、横の射程が狭いので一見すると使いづらい印象がある。 だが壁を突き抜けて攻撃するので、覚えておくと特定のストーリー攻略では有利に運ぶことが出来る。 ビアンカはとにかく、さみだれうち、ラリホーが強力なので、ストーリーにおける防衛ミッションで連れて行くと かなり楽に攻略することができる。 さみだれうちは、他の範囲技と違って敵を遠くまで吹き飛ばさないので、素材集めにも便利なキャラ。 ストーリー、素材集め、メタル狩り等、なにかとお世話になるだろう。 弱点は、キラーパンサーやキラーマシン２等の素早い敵には弱い。 その場合ラリホーも良いが、キラーパンサーはバックステップで避けることが多く、キラーマシン系は効かないことも多い為 無理せずに操作キャラを変えてしまおう。 コメント欄 この掲示板はツリー方式です。レスをする時は、レスをしたい記事の先頭をクリックして選択してから書き込んで下さい。 それをしないとツリー表示されず、新規投稿になってしまいます。他の人が不快になる様な投稿は控えましょう。質問は質問掲示板で行いましょう。 名前 全てのコメントを見る
https://w.atwiki.jp/shrikemwo/pages/8.html
モジュールの説明になります。
https://w.atwiki.jp/rubyiw/pages/48.html
Rubyには、モジュールという概念がある。この機能により、クラスが128倍パワーアップするという素敵なものなのである。これから解説していこうと考えているわけだが、ちょっとその前に、少しお話しておきたいことがあるのだ。 あるクラスを基にして新しいクラスを作成することを『継承』と呼ぶのであるが、実はこの『継承』には、2種類の方法がある。 それは、基になるクラスをひとつだけに限定するか、もしくは複数を許すかということなのだ。前者は『単一継承』、後者は『多重継承』と呼ばれている。 下等な生物であれば単一生殖もありうるが、通常単一では子供が生まれない。であるから、親子という概念からすると、『多重継承』の方が自然であるような気もするが、オブジェクト指向プログラミング言語においての継承は、親子関係のメタファーではなくどちらかというと『種の進化』という側面が強いので、『単一継承』も十分アリだという気もする。 しかしまあ、現実の世界になぞらえて、プログラミング言語を考えるのは、楽しいけれども、あまり意味のないことなので、言語仕様という側面から２つの継承方法を考えてみよう。 実は、数あるオブジェクト指向（っぽいものも含む）プログラミング言語で、多重継承をサポートしているものは少ないのである。Eiffel(アイフェル、エッフェル)、C++言語、Perl、Pythonぐらいのものであろうか。その他の言語は、多重継承はサーポートしていない。なぜなら、多重継承は、非常に問題点が多いのだ。 1.継承関係が複雑になりすぎる。 2.メンバ名の衝突。 3.コンパイラ、インタプリタの実装が難しくなる。 とまあ、3番目の問題は、言語開発者サイドからみた問題点であるので、使う立場の者にとっては関係ないことだが、1と2については、なかなかに問題は深刻だ。そのため、比較的新しく誕生したオブジェクト指向プログラミング言語、例えば、Objective-C、Java、C#、VisualBasic.NETなどは、多重継承をサポートしていないのである。その代わりといっては何だが、これらの言語にはInterfase(インターフェイス)という概念がある。 例えば、人間クラスと鳥クラスの両方の機能を継承して、鳥人間クラスを作りたいとする。どうしてそのようなクラスを作りたいかというと、鳥のように大空を飛び回る人間を作りたかったのだ。これが多重継承であれば話は簡単で、例えば次のようにすればよい。 001 | // 人間クラス 002 | class CHuman 003 | { 004 | }; 005 | // 鳥クラス 006 | class CBard 007 | { 008 | void fly() 009 | { 010 | } 011 | }; 012 | // 鳥人間クラス 013 | class CBardMan public CHuman, public CBard 014 | { 015 | }; 016 | 017 | CBardMan bm; 018 | bm.fly(); これで、大空を自由に飛べる新しい人類が誕生し、めでたしめでたしと思っていたのだが、様々な問題があることがわかってきたのである。例えば、鳥目のために夜何も見えないとか、公園の池でぴちょっと跳ねる鯉をパクッといきたいという衝動にかられるなどの問題だ。 これはやはりまずいよということで登場したのが、インターフェイスという概念なのである。 今回、人間クラスに追加したいのは、『空を飛ぶ』という機能なのである。そこで、『空を飛ぶ』という機能を仕様として切り出し、インターフェイスとして定義するのである。C#を例に、実際に定義してみよう。 001 | // 空飛ぶインターフェイス 002 | public interfase IFly 003 | { 004 | void approach(); // 助走 005 | bool takeoff(); // 離陸 006 | void flutter(); // 羽ばたき 007 | void ascend(); // 上昇 008 | void gliding(); // 滑空 009 | void descent(); // 下降 010 | bool landing(); // 着地 011 | } そして、この空飛ぶインターフェイスを鳥クラスと、人間クラスに定義してやるのだ。 001 | class CHuman IFly 002 | { 003 | } 004 | class CBard IFly 005 | { 006 | } よしこれで完璧だと安心するのはまだ早計で、実はIFlayインターフェースにある7つのメソッドは、全てガラだで、中身が詰まっていないのである。『鳥と人間とでは、同じ空を飛ぶにしたって、やることはちょっとずつ違うだろう。だから、各メソッドの中身は全部自分で実装してくれ』というスタンスなのだ。その代わり、IFlyというインターフェースを持つクラスのインスタンスは、外部から見ると全く同じ操作で空を飛ばすことができるというわけである。 継承できるクラスはたったひとつだけだが、インターフェイスは複数くっつけることができる。要するにインターフェースとは『仕様の多重継承』というわけである。 実になんともすばらしい概念なのだが、ここでひとつ不満が沸いてこないだろうか。それは、 「なんだよ。実装を共有できないのかよ」という不満である。可能であれば、マンガのドラえもんに出てくるタケコプターのように、頭にくっつければ後は勝手に飛んでくれるというのがよろしい。 そこで登場したのが、RubyのMix-in(ミックスイン)という考え方だ。これは、中身のつまったインターフェイスと考えればよろしい。それを実現するのがモジュールというわけなのである。 001 | #タケコプターモジュールの定義 002 | module TakeCopter 003 | def fly 004 | #空を飛ぶノウハウがぎっしりと・・・ 005 | puts "飛んで飛んで飛んで" 006 | end 007 | end 008 | 009 | #鳥人間クラスの定義 010 | class BardMan 011 | #タケコプターモジュールのMix-in 012 | include TakeCopter 013 | end 014 | 015 | bm=BardMan.new 016 | bm.fly 12行目が、モジュールをインクルードしているところで、この一行さえあれば、タケコプターモジュールの機能を全て自分の中に取り込むことができる。16行目で、flyメソッドが、さも自分のもののように呼び出されているのを見ていただきたい。 上記のコードは、コード作成時、静的にモジュールを取り込んだわけだが、プログラム実行中、動的に取り込むこともできる。 001 | #タケコプターモジュールの定義 002 | module TakeCopter 003 | def fly 004 | #空を飛ぶノウハウがぎっしりと・・・ 005 | puts "飛んで飛んで飛んで" 006 | end 007 | end 008 | 009 | #鳥人間クラスの定義 010 | class BardMan 011 | end 012 | 013 | bm=BardMan.new 014 | #タケコプターモジュールを動的に取り込む 015 | bm.extend TakeCopter 016 | bm.fly もう、ここまでくると、もうなんでもありなのかという気持ちになってくる。これだけ強力な機能があれば、もしかするとクラスの継承すら、もう必要ないのかもしれない。
https://w.atwiki.jp/kuroeu/pages/603.html
ビアンカ 種族：人間族 登場作品：魔導巧殻 解説 メルキア帝国キサラ領所属の魔導技師。 妖艶な魅力を持つ女性。 熟練の魔導技師であり、重装備でありながら移動速度には定評がある。 雑感・考察 名前
https://w.atwiki.jp/sazi/pages/87.html
ビアンカ=グッドオール 本名：ビアンカ=グッドオール 身長：160前半 体重：70kg台(前半) 所属：私立七転学園教師(美術科教諭) 能力：自重しない程度の能力魔法を使う程度の能力 普通の教師(全学年美術担当)、年齢は50台後半(姿と年齢が一致しないのは仕様です) 和やかそうな外見とは裏腹に、行動的な性格をしている人。 怒ると怖い、らしい。 学園には大分初期から居る様で、全学年の美術を担当する事もあり、学園での顔はとても広い、そこそこ人脈もある様子。 同じ教師であるゴドウィンとは姉弟であり、孫2人(ホリー、キャサリン)も同学校に在籍している。 身内とは言え、学園内部ではキッチリ呼び分ける様だが、放課後だとかは愛称を使って声を掛ける、とか。 姉弟の関係であるゴドウィンと姓が違うのは、父母の離婚の影響である。 (バートウィッスルは父姓、グッドオールは母姓。 因みに、ホリーやキャサリンと姓が違うのは息子(ホリー達の父)が婿養子としてオールドリッチ家に入ったからである) 弟と似たような収集癖があり、その対象は『宝石』 曰く憑きから流行トレンドまで、そのコレクションは幅広い。 種族的には『普通の人間』だが、伝来の技、なるもののお陰？で『魔法』が使える。 (下記参照) 裏(？)設定(厨二病全開、ゆとり仕様な設定) 魔法。 性質はホリーの物と全く同じ、『マナ』なる物を使ってあらゆる現象を発現させる物。 ただし、自然そのものを媒介とするホリーと異なり、魔力結晶である宝石を使用。 その影響か、ホリーの発動させる魔法より、効果はより強力な物となっている。 絵筆、『絵の具』 絵筆自体は魔力を有する刻印を刻んだだけの筆である。 『絵の具』は、筆に刻んである刻印に反応、宝石を『溶かす』事によって発現する『物体』であり『現象』、描いた物に生を与えたり、発生した事象を消し去ってしまったり(反対に、発現させたり)と、本人の使う『魔法』を純粋に応用(改良)した物になっている。 ･違う点 宝石を直接使用する場合は、威力が下がる事は無いが、1回発動させてしまえば、宝石の魔力は無くなってしまう。 絵の具に変えて使用する場合は、若干威力、効果は下がるものの、絵筆に"色"が残っている間は宝石(絵の具)の魔力は無くならない(長持ちする)。 長年の倹約術の成果、だと本人は言い張っている。 腕輪等の装身具 散りばめられた宝石にも、しっかり魔力は篭っている。 エメラルドとオパールの腕輪は、物や人を探すのに便利らしい。 [随時更新予定なのよぉ、って姉キが言ってたぜ！] 著：ゴドウィン=バートウィッスル
https://w.atwiki.jp/taigagaga/pages/353.html
ビアンカ ＰＬ ゆとれすと 年齢 22 性別 ♀ 職業 トレジャーハンター 人種 ラクセン人 能力値 武勇 機敏 精神 備考 基本値 5 3 1 攻撃力 7 3 1 防御力 5 3 1 ＨＰ 20(25) スキル 常備 二刀流 消費 なぎ払い 連続行動 連続行動 経験点 0(10) 参加回 突発337回「狗」 突発第357回「紫の絨毯の下で」 装備品 武器 匠の剣・匠の剣 鎧 帯刀用ベルト 所持品 非消費 匠の剣、匠の剣、匠の剣、ロープ(10/10)、フック 消耗品 『約束の香水』消耗品 売値1500上等な香水＜ラベンダー＞であり、聖水、上等な傷薬、万能薬の効果を持つ フレーバー アーミットの花冠(ラベンダー) 所持金 7325G ＮＰＣ利用 可 二次創作 可 口調 一人称 私、アタシ 三人称 呼び捨て、○○さん、○○ちゃん。年功序列はしっかりと。 設定 何の変哲も無い農家の娘として生まれ。正義感の強い父に恵まれた。しかし、その父は濡れ衣で処刑されそうになっていた隣人を助ける為、無謀にも騎士団に襲い掛かり、妻を残しその場で刺し殺された。丁度その頃、１４歳だったビアンカは、絶対に父と同じ生き方はしないと心に誓った。母を養うため、有名なトレジャーハンターに取り入り、冒険に同行して分け前を貰ったりしていたが暫ししてその母も亡くなり、彼女は孤独になった。その後は、正義や名誉のためでなく、自らの稼ぎのために危険を冒すトレジャーハンターが彼女の毛色によく合い、それを生業としている。基本的にはフレンドリーで接しやすい性格をしている。ただ、力ある者に媚びたり、人間相手に不意打ちを仕掛けたりと卑怯な行動に躊躇いが無い。それは１４歳の頃の経験からか、半ば強迫観念のように彼女にインプットされている。また、結婚願望は全く無い。これも父の影響か。そして、なんといっても腰に五本の長剣を帯刀しているのが最大の特徴。同時に扱えるのは二本までの為、残りの三本は錨やつっかえ棒、ロープと合わせて命綱の代わりなど、探索にフル活用する。そのため、特に自分の剣に思い入れは無く、投げたり他人に貸したりと武人としてあるまじき行為も平気で行う。 コネクション パーシヴァル(突発第357回「紫の絨毯の下で」) 面識表 コメントなど ゴドー 洞察力鋭い、只者ではないおじいさん。一緒に依頼をしていると凄く頼もしいけど、その分暴走もする危険人物。ちょっと警戒しておこう。 ホプルス うん、元気な子だね。 ただ獲物から言って暗殺者志望っていうのは本当っぽい。 あの性格で本当にそんな仕事ができるのかな？ チェルシー 恐ろしく暢気で、まっすぐな娘。あれは大物になるな、うん。 リョウエン 日輪国の僧侶だという。袈裟に両眼帯と結構怪しい格好なのに、いい人オーラが駄々漏れ。あれは色々と苦労するねー。 アーミット パワフル妖精。割とモノを考えずに猛進する性格らしいので、結構ツカエル。あと可愛い。