そこを穿つ！

◆ パッケージに関する基礎知識

• シーンからイベントを切り出したものがパッケージ
• 繰り返しや同一の処理の効率化に威力を発揮

　カードワース ver.1.20で加わった概念「パッケージ」は、分かる人にはほとんど説明不要で分かってしまい、分からない人にはどうも今ひとつピンとこないようだ。もしかしたら、プログラミング経験の有無がパッケージに親しめる層と怖じ気づく層を分けているのかもしれない。
　分かる人向けに簡単に書いてしまえば、パッケージとはシナリオ内のどこからでも呼び出し可能なサブルーチンのようなものだ。
　以上。
　……で終わるわけには行かないので、説明は続く。
　まずは下の図を見てほしい。

[パッケージの例]

　図は、シナリオ「パッケージ大活用」の最初のシーンにある扉周りの処理を抜き出したものだ。宝の部屋へ通じる扉に対して「解錠」キーコードを持つカードを使用するとイベントが発火し、対応するパッケージの中身が実行されるようになっている。つまり、図の右下に示したパッケージ内容がこの扉の解錠イベントとしてぶら下がっているのと同じことを意味している。
　このように、パッケージへのリンク／コールを付けた箇所でパッケージ内容を実行するのがパッケージの本質だ。

　パッケージを使うことでどういう得があるか考えてみよう。
　このエリアには同じような扉が並んでいるのだが、解錠の処理はどの扉も共通で、図に示したパッケージを呼び出すだけの単純な形をしている。
　全く同じ処理をするのならば、処理を丸ごとパッケージ化するのが定石だ。そうすることで、同じコンテンツツリーをいくつも作らないで済むし、何よりデバグが楽になる。

　パッケージは別に難しくないので、恐れずどんどん使っていこう。

◆ リンクとコール

• リンクはパッケージ内処理を実行してそれでお終い
• コールはパッケージ内処理終了後、ツリーの続きを実行する

リンク コール [リンクとコール]

　行ったきりが「リンク」、戻ってくるのが「コール」と覚えておこう。ここでいう「行く」とか「戻る」というのは処理についてで、別のシーンに切り替わるわけではない。もちろん、エリア移動コンテントを使ってわざとそうなるパッケージを作ることは可能だ。

[終端の例]

　処理終了というのは、ツリーの終端に達することを意味する。ちょっと見ただけでは終端に見えないが、分岐コンテントの分岐先が用意されていない方向に進んだ場合も処理終了となる。一方、ツリーの終端にリンク系コンテントやコール系コンテントがある場合は処理が続行しているとみなされる。要するに、それ以上処理が続けられなくなったらそこでお終いということだ。
　「エリア移動」や「バトル開始」、「シナリオクリア」「ゲームオーバー」、そして「効果中断」は処理が強制中断される特殊なコンテントなので注意。コールの指示を無視されて、続きの処理に戻ってこないぞ。

　パッケージ内から別パッケージへのリンクやコールも許されているし、利用できないコンテントもない。つまり、リンクやコールの使用には、ほとんど制限がないと考えて良い。通常利用で気を付けるとすれば、上記のエリア移動コンテントくらいだろう。
　だが、何事にも例外が付き物で、上級シナリオ作者を目指すなら、次の項目で述べることに注意したい。

◆ パッケージ使用上の注意

• コールを多用すると処理速度が落ちる
• カード固有イベントで使ったパッケージは他シナリオでは無効

　コールには、多用すると処理速度が落ちてくるという性質がある。その顕著な例を拙作のシナリオ「ロールテスター」の「低速処理」に見ることができる。コールを使うか使わないかで、同内容の処理にかかる時間に数倍の差が出てくるのだ。
　しかし、この例のように何十回・何百回単位でコールをかけることは滅多にないだろう。よって、普段はあまり気にしないで良い。

　もう一つ、これもあまりやろうとする人はいないだろうが、他シナリオのパッケージ利用はできないことも記憶の片隅に置いておこう。この制限は、カード自体にイベントを埋め込んだ「カード固有イベント」で効いてくる。カードを配付したシナリオ外でパッケージを利用しようとすると、たとえ同じパッケージ名・ファイル名のパッケージが存在していても、呼び出されることはない。これは他のシナリオに悪影響を与えないための安全装置のようなもので、groupASK の思いやりといったところか？

◆ パッケージの利用場面

• 到着イベントとして
• ハズレのイベントとして
• 敵のカードのイベントとして
• エラー処理ルーチンとして
• その他なんでもかんでも

　最後に典型的なパッケージ利用場面をいくつか紹介する。パッケージ初心者はここらあたりから挑戦していくことをお奨めする。一度味をしめると、もうパッケージ無しではシナリオを作れなくなるだろう。

　まず一発目は、到着イベントとしての利用だ。具体的には、遭遇戦の判定や各シーンで共通して使われているフラグの初期化、ランダムに発生するお喋りなど。特にシーン数が多くなってくると、パッケージ利用の効果は絶大なものとなる。

　次の共通ハズレイベントは、鍵開け判定や鑑定判定などに失敗した場合、あるいは特にこれといってプレイヤーに伝えることがない場合のイベントのことを指している。こういうあまり意味がないイベントを幾つも作るのは馬鹿馬鹿しいので、パッケージを使ってスマートに処理してしまおう。
　まあ、敢えて無駄なイベントをカスタムメイドで執拗に作り続けるのも面白いかもしれない。そういう執念にも似たしつこさは、得てしてシナリオに異形の魂を与え、マニア好みの逸品を作り上げるものだから。

　三番目の敵のカードへの利用だが、これはイベントがしょちゅう変更される開発段階で非常に役立つ。たとえ戦闘中でも、パッケージ内容を変更してセーブだするけで、カードのイベントもその場で更新されるのだ。これは知っておくと便利。ただし、小手先の修正に限る。普通は、デバグモードでシナリオの更新をかけた方が良いか。

　四番目のエラー処理は筆者が特に押忍…じゃなくて、推すパッケージ利用法だ。称号判定やカード所持判定などあらゆる分岐処理の本来あり得ない分岐先全てに、エラー発生を知らせるパッケージを付けておくと、デバグ時にとても役立つ。
　シナリオ作者の中には、このエラー処理を丁寧に作って、どこでどんなバグが出たのかを分かりやすく表示して、バグ報告がスムーズに行くよう工夫している剛の者もいる。そこまでやらなくても、バグによって変なクーポンが残ったりして、そのシナリオが二度と遊べなくなる事態を防ぐ処理くらいは用意しておくと良いだろう。

　あとは工夫次第。いろいろな用途にパッケージを使ってほしい。そのうち、シナリオの構想段階で、パッケージを使うべき場面が自然に見えてくるようになるだろう。