新時代のソーサリアンを提案する

30周年を越えたソーサリアンの夢と妄想を語り続ける

ソーサリアンText開発者向けテクニック集(メモ)

ここでは、ソーサリアン Textのシナリオを執筆する際に、ちょっと気にしてみると良いかも?というポイントをなんとなくまとめています。

あまり綺麗にまとめるつもりはなく、ソーサリアン Text固有のこともあれば、一般的なゲームブックにもあてはまる話もあるかもしれません。そもそも公平な話をするつもりもないので、偏った意見もあるかもしれません。

とりあえず、役に立つかも、という話がひとつくらいあればいいではないですか。
そんなページです。

今後も思いつき次第、バラバラと書き散らしていく(=不定期更新の)予定です。なお、「推奨」とあるのは、経験上、特に気にしておきたい点です。

シナリオの適切な長さは?

最初から自分に跳ね返ってきそうな話題ですな。。
というのは、さておき。

ソーサリアン Textのオートセーブ機能は、あくまで簡易なものです。リロード時に「新規に冒険をはじめる」を選択すれば、簡単に消えてしまいます。

このようにしたのは、基本、ソーサリアン Textのシナリオは、原作に則って、「一気にクリアできる」程度のシンプルさを想定しているため。でも、途中で休みたい人もいるよね、ということで、中断/再開の手段を最低限提供している――そんな程度の機能なわけです。

そんな理由から、ソーサリアン Textでは、あまりに長いシナリオはお勧めしません(いい加減、何時間もプレイしたデータが消えてしまったら、再度やる気もそがれるというものです)。

どの程度が適切――とは、イベントの複雑さや文章の長さなどもあるので、一概には言えませんが、個人的な感触としては、最長でも「最短距離(全体ではなく)で100〜120scene程度が望ましい」といったところでしょうか。

物語を膨らめたい場合にも、物語そのものを長くするのではなく、分岐を増やして、短く何度もプレイできる余地を作るのが、SText的には(ゲームブックとしても)向いていると思います。

それでも長くなってしまう場合には、連作にするのも手だとは思います。前後編ではなく、できるだけ一作一作独立した構成で。陳腐な対策ではありますが、一作一作に大なり小なりエンディングを設けることで、物語も引き締まります。

20〜40scene単位にセーブポイントを(推奨

上とも関連しますが、ソーサリアン Textのセーブデータは簡単に消えます。
また、その性質上から、「なるべく短く何度もプレイできる」構成がお勧めです。

そのような構造を前提とした場合、物語を途中から再開できるように、(最短距離で)20〜40scene程度の区切り目で、チェックポイントを設けることをお勧めします。

拙作「新・消えた王様の杖」(以下、王杖)でも5か所のチェックポイントを設け、プロローグ(scene 0)から移動できるようになっています。

なお、具体的なテクニックですが、チェックポイントに移動する際には、そこまでのアイテム/フラグをまとめて再現する復元sceneを介するようにしてください。以下は、王杖の例です。

<scene id="13000" items="i04,i06,i11" flags="f01,f02,f03,f04,f05,f06">

ここでフラグ/アイテムを復元した後、徐ろにチェックポイントに移動させるわけです。

ただし、物語が大きく分岐している場合には、その時点で入手しているフラグ/アイテムがいつも同じとは限りません。よって、王杖では

ステータス欄を確認して
見覚えのないアイテムが含まれているとしたら、
人知を超えた神々の恩寵に
深く感謝してもらっておきたまえ。

とか言って、適当にごまかしています!

シーン番号の振り方

物語に沿って順番に振る(推奨

普通のゲームブックと違って、STextでは(プレイ画面からは)前後のシーン番号を見られません。よって、物語の進行順に、シーン番号を振っても、プレイヤーが誤って先のシーンを見てしまう心配はありません。

むしろ執筆時には、(完全ではないにせよ)前から順番に物語を確認できた方が、開発生産性は向上します*1ゲームブックを作り慣れた人ならば、猶更ですが、シーン番号をシャッフルする必要はありません!*2

シーン番号は1000、100、10の単位に

シーン番号は原則として10の単位を最小に振ることをお勧めします。
上とも関連しますが、こうすることで、もしもあとからシーンを追加する場合にも、割り込みがしやすい(=順番に並べやすい)からです。

同じ理由から、シナリオを大きく

  1. 物語の大きな区切り目
  2. 個々のイベント
  3. 個々のシーン

の階層で管理して、1.では1000の単位で、2.では100の単位で、3.は(先ほども触れたように)10の単位で、それぞれ番号を振ることで、物語の塊が把握しやすくなりますし、途中でのイベント追加がしやすくなります。

STextではシーン番号を連番にする必要はありませんし、してはいけません。

イベント分岐も規則立って並べる

シーンが分岐した場合にも、できるだけ規則だって並べることで、あとから確認する際などにも、物語を辿りやすくなります。具体的には、「王杖」では、以下のような点を意識していました。

  • ゲームオーバー分岐を最初に並べる(大概、短く切れるので)
  • 後続のsceneに繋がる分岐をあとに
  • ただし、当該イベント共通のscene(共通ゲームオーバー)などは、該当するシーン群の最後に
    • できれば90、990、9990など、番号単位の末尾を利用するのが望ましい
  • チェックポイントの復元scene(先述)は、シナリオ末尾にまとめる

一定区間ごとに結節ポイントを設ける

結節ポイントとは、イベントを構成するscene群を連結する単一のポイントのこと。どんな選択をしても、必ず通過するポイント、と言い換えても良いかもしれません*3

ゲームブックでは、途中、プレイヤーによって物語が複雑に分岐していきますが、ある程度の塊で、いったん分岐を収束させて、次のイベントに繋げるための結節ポイントを設けることをお勧めします。

その理由は、以下の通りです。

物語の管理に便利

イベントの塊が明確になります。先述したように、番号付けを「物語の大きな区切り目」で管理している場合、結節ポイントは番号繰り上げの明確なポイントとなるでしょう。

GBAT to STextの連結機能にもマッチする

GBAT(無償版)は、100sceneまでの開発に制限されます。よって、ある程度の長さのシナリオを開発する場合は、自ずとファイルそのものを分割しながら、開発していくことになります(GBAT to STextでは複数ファイルを連結できるので、ご心配なく!)。

その場合にも明確に結節ポイントを設けてあると、ファイル同士の連結が容易になります(複数のsceneがファイルを跨っていても構いませんが、管理は面倒です)。

複数BGMにも対応しやすい

シナリオの途中でBGMを変更する場合、変更前後のシーンでbgm属性(要素)を設定しなければないません。プレイヤーが前のシーンに戻った場合に、前のBGMを復元するための――専らシステム側の都合です。

その都合上、切り替えのポイントは単一(=結節ポイント)であることをお勧めします。分岐したシーンの途中でBGMを変更する場合、bgm属性の指定が複雑になりやすいため、バグが混入しやすくなります。

ワンシーンにはできるだけ敵は一体

ソーサリアン Textは、ダメージやステータスをほぼ手動で更新しなければならない――よく言えば、古き良き時代のゲームブックまんまなゲーム、悪く言えば、手作業を強いられる面倒なゲーム、ということです。

■Note■
もっとも、面倒くさいことを旨としているわけではなく。

きちんと遊びたい人はきちんとステータス管理しても良いけれど、手早く分岐する物語を楽しみたいという人は、無敵モードも歓迎よ、という意味もありますし。

戦闘はシナリオの裁量に委ねるよ、シナリオ作者がどんどん特徴を打ち出してね、というシステム側からの意思表示(ぶん投げ)だったりもするわけです。

よって、ワンシーンでの複雑な戦闘(判定)は不向きです。

具体的には、複数の敵との戦闘は、何度もステータスを更新しなければならないため、煩わしく感じるかもしれません。戦闘を中心とした展開を演出するならば、そもそも複数のシーンに分割した方がテンポは良くなるでしょう。

あるいは、物語の演出上、単に複数の敵を登場させたい、ということであれば、「ゴブリン×10」のような<一体の敵>を設ける方法もあります*4

状態異常の利用は要注意(推奨

STextの状態異常は、原作と同じくシビアな設定となっており(それでも一度、緩和しています^^;)、中〜高確率でゲームオーバーの原因となりえます。

具体的には、以下の順で危険度が上がっていきます。

毒<呪い<凍結<忘却<石化

シナリオ開発者は、以上を意識して状態異常イベントを設置すべきです。特に、石化/忘却はプレイヤーにとって致命的になりうることを意識して利用してください。石化は解除ポイントがなければ一定期間で死亡しますし、忘却によって弱体化したキャラに強敵を当てることは致命打になりえます。

特に危険度の高い石化/忘却は、

  • 余程、低確率の結果
  • 誤った道を選択した場合のペナルティ(ほぼゲームオーバー相当)

などに留めることを強くお勧めします。

また、危険度の高低に関わらず、状態異常を利用した場合には、以下の救済策を検討してください。

  • 万能薬、回復イベントの設置
  • 欠片の入手機会を高め、魔法による回復手段を提供

特に、危険度の高い状態異常では(ゲームオーバー上等を前提にしているのでなければ)、正しい選択をすれば救済されるルートを必ず設けてください。

■Note■
余談ですが、味方に状態異常があるならば、敵にも状態異常を付与すべき、という意見がありました。が、現時点のSTextでは、これは未対応です(おそらく戦闘システムを大きく変更しない限り、敵の状態異常の対応は難しいでしょう)。

そのようなニーズには、シナリオ側のシーン分岐として表現することをお勧めします。なんらかのアイテムを利用することで、弱体化した敵との戦闘sceneに移動する、などです。

同じように、標準以外の状態異常(たとえば巨人化、小人化のような)も、フラグなどで管理します。

戦闘は飾りなんですよ

STextでは、もともと戦闘はあまり重要視していません。
分岐する物語へのちょっとしたスパイス程度、というつもりです。

実際、ステータスの幅がそれなりにあるので、強弱バランスは難しいと思いますし。
原作でも、戦闘はオマケみたいな感じでしたし。
とはいえ、戦闘によるゲームオーバーの危険がまったくないのもつまらないので。

基本的に、同じルートを何度も行き来して、同じ戦闘を繰り返すような行動をとらなければ、ゲームオーバーにはならない、程度の難易度で良いと割り切っています。

STextでゲームオーバーとなる主要因は、誤った分岐を(繰り返し)選択した時なのです。

同じ理由で、(ある場合は)ボス戦も簡単で良いと思っています。
ボスを倒せるかどうかは、そこまでに適切なフラグを立てたか(正しい選択をしたか)によって決まるのであって、ダイス運によって左右されるべきではない、というスタンスですね。

# だって、そこまで長い道筋をたどってきた苦労が、一度のダイスで水の泡になるのは理不尽ではないですか。

戦闘ルールの複雑化は避けるべき

戦闘を比較的軽視している理由はもうひとつ。

パソコン、ましてやモバイル環境でプレイする際に、メモ用紙やエディターを片手に、という状況は考えにくいはず。手軽に選択して、最低限、足し引きした結果をステータスにポチポチ反映して――という遊び方が精々でしょう。

そのような状況を考えると、戦闘ルールはその場で手軽に暗算できる程度の複雑度に留めるのが前提になると思います。難しいかもしれませんが、シンプルな中でどれだけの駆け引きを盛り込めるかに、シナリオ執筆の皆さまは挑戦して戴きたいと思うわけです。

■Note■

本文のような話をすると、必ずステータス更新の自動化という話題が出るのですが、おそらくSTextでは将来含めて対応しません(ステータス更新を簡単化するサポート機能は実装するかもですが、精々そこまで)。

というのも、理屈上は自動化はいくらでもできるのですが、それってコマンド式のコンピューターRPGでやれば良いよね、という話になってしまうので。ゲームブックとはかくあるべき、などと枠にはめるつもりもないのですが、辿り着いた先が結局、既存の別方式というのではつまらないではないですか。

STextでは「分岐する物語」という路線をどれだけ極められるかを、追及していければと思っています。

ルールブックは別シナリオで

上で述べた理由から、シナリオ固有のルールはできるだけシンプルにすることを強く推奨しますが、それでもルールが一定量を超える(もしくは進行中に随時参照させたい)場合があると思います。その場合は、以下の方策を検討してください。

  • 別シナリオとして切り出す
  • 外部リンク機能を使って、ブログなどに切り出す*5

ルールブックは最大限、いつでもどこからでも参照できるようにすべきです(ただし、ルールを学ばせることが本来の目的でない以上、ルールブックは作らない、がまず著者のお勧めです)。

ブラウザーの[戻る]機能は使わない

現在のSTextでは、ブラウザーの[戻る]機能を許容していますが、シナリオ実装時に、これを前提とした機能を備えるのはお勧めしません。

というのも、[戻る]には、現状把握している限り、以下の問題があります。

  1. [戻る]ことで、本来入手しなかったはずのフラグ/アイテムが入手できたことになってしまう*6
  2. [戻る]を前提にしたルートの途中でゲームを中断した場合、元のシーンに戻れなくなってしまう

現時点では、上記の問題が比較的軽微である点、開発時の利便性を考慮して、[戻る]機能を残していますが、将来的には削除する可能性はあります。

フラグは「あらすじ」となる

ソーサリアン Textでは、そこまでに得たフラグをステータス画面から確認できます。フラグの羅列でもって、プレイヤーはあらすじを確認できるわけです。

よって、フラグは分岐のためだけでなく、物語の区切り区切りで細かく立てていくことをお勧めします*7。また、フラグテキストは、できるだけ物語の進行を把握できるよう、具体的な内容にすべきです。

ワンシーンは短く

主観が強まりますが、個人的にはゲームブックはプレイヤーに間断なく選択を求め続けるゲームだと思っています。

よって、極端には、シーンでの描写は、「選択のための材料を与えるための最小限」に留めるべきだと思っています。物語の進行はプレイヤーに委ね、シナリオはそのためのサポート役に徹する、というわけですね。

そうした意味でも、sceneあたりの文章はできるだけ短く――長くてもPC画面でワンスクロール程度が限界かなとは(モバイル環境だと、それでも辛いかもなので、理想は一画面に収まる程度では?)

画像もワンシーンに複数配置できますが、特別な演出を除いては、原則として1画像/シーンとするのが、画面的にはすっきりするかと思います(こちらもモバイルで大きな画面を複数入れると、結構大変なことに)。

そもそも、選択ボタンはイラストの後方に配置されるので、イラストで選択が邪魔されるのは避けたいものです。

カラーリングはできるだけ抑えめに

一応、テキストのカラーリング機能を設けていますが、利用はごく限定することをお勧めします(紙面が五月蠅くなります)。

基本、強調は太字程度にとどめ、もしそれ以上の強調をしたい場合にも、ワンシーンにカラーは1色、適用箇所もせいぜい1〜2か所に留めるべきです。

システムとシナリオのバランス

ソーサリアン Textは、基本、シナリオ任せなプラットフォームです。

  • システムはシナリオの邪魔をしない
  • シナリオでできることはシステムではやらない
  • 「ないと困る」機能しか実装しない(=「あっても良い」はやらない)

の三原則(今決めた)を前提に、できるだけシンプルで中性的なシステムを目指しています。ソーサリアン Textでは、シナリオが主役なんです。

というのが、まずは大原則。

でもそれだけに、システムでなにができるかを最初に是非確認していただきたいのです。
とにかく自由なので、独自路線を行こうと思えば、なんでもできてしまう。
シナリオ独自のルールをほぼ一から構築することすら可能です。

ただ、シナリオ独自ルールはプレイヤーに理解の負担を強いますし、システムが想定していないので、表現もプアになりがち&操作も迂遠になる可能性が高まります。

個人的には、

ルールの説明が一定以上に嵩んできたら要注意。

独自ルールを作りたいと思ったら、まずは

  • STextの機能で賄えないか
  • さもなくば、独自ルールとSTextルールとそれぞれを歩み寄らせることはできないか
  • (ルールを一から作るのではなく)標準ルールを拡張する方向

に思いを馳せていただけると、遊びやすく、シナリオの保守性も高まるのではないか

と思うわけです。

そして、システム開発者としても、折角用意した諸機能なので、「あ、別ルール用意したんで」と言わずに、どんどん使い倒していただけると、実装した甲斐があるというものなのです。

シナリオのリクエストについて

システムは現在、月次でUpdateを継続しているので、シナリオを執筆していく中でご要望の点は、私までお願いします。既存機能とのバランス、開発工数などの要因もあるので、すべてをお受けできるわけではありませんが、皆さんのアイデアを可能な範囲でどんどん標準機能として取り込み、STextを良いプラットフォームにしていければと思っています。

リクエストが受け入れられやすい基準としては、

  1. どれだけ具体的な用途を想定されているか
  2. その機能が欲しいよという熱意

でしょうか^^;

大概、リクエストを検討させていただく際に、そのまま実装するわけではなく、どういった用途を想定されているのかを想像し、既存機能にもマッチする実装方法を検討するわけで。その際に、具体的な用途が見えているかどうか、というのは大きいわけです。

熱意の方はもっと単純で、ご意見から「あっても良い」<「あった方が良い」<「なくては困る」を判断し、当然、実装したら使ってもらえそうな機能から実装しています ;-)

なんてことを書いてると、偉そうに聞こえるかもしれませんが、リクエストはホント大歓迎で、システム側としても大いに刺激となっているので、お気軽にどんどんお寄せくださいm(_ _)m

結局のところは

いろいろ書き散らしていますが、模範的なシナリオ*8が必ずしも面白いわけではありません。

折角、さまざまな人たちが興味を持って、創作を披露するソーサリアン Textの世界。なんとなくルールの中で小さく収まってしまうのは面白くないではないですか。

どんどん挑戦的なアイデアを、皆さんのシナリオに盛り込んでいってやってください。

適度に納得し、そして、どんどん打ち破っていく*9のが、このドキュメントとの良い付き合い方だと思っています。

*1:テキストエディターで執筆する場合。GBATでは、フロチャがあるので、その限りではありませんが、それでも意外と生ソースで最後確認したいということはよくあります。

*2:GBATには、シーンのシャッフル機能がありますが、使ってはいけません!

*3:途中で大きく物語が分岐する場合は、その限りではないかもしれませんが、その場合もその大きな分岐の中では必ず通過するポイントであるべきです

*4:この辺は、王杖を執筆した後に感じたところで、王杖ではあまり実践できていないのですが、次作には活かしていきたいものです。

*5:ご自分のサイトを持っていない場合には、本ブログで公開させていただくことも可能です。

*6:1. のアイテムについては、前のシーンでアイテムをはく奪するようにすることで、最低限防げますが、積極的に利用すべきではありません。

*7:王杖では残念ながら、実行できていません。最初からあらすじ構想はあったのですが、単に時間オーバーでした…いずれ修正します

*8:そもそも、ここで書かれていることを守ることが模範的などうかもわかりませんが :-P

*9:あえて、無視する、ではないのですよ