選択が意味を持つのは、物語がその選択を覚えているときです。この初心者向けプロジェクトでは、成人の共同制作者二人がスタジオの開き方を決めます。使うのは小さなパッセージのグラフ、保存される一つの決定、そして二つのエンディングです。必要なアート素材はごくわずかです。まずは各選択が意図した結果につながるようにし、その結果がセーブと再読み込みを経ても維持されるようにしましょう。
ダウンロードできるのはSugarCube用のTweeソースです。Tweegoとインストール済みのSugarCubeストーリーフォーマットを使ってプレイ可能なHTMLにコンパイルするか、Twineで物語のパッセージを手作業で再現してください。この環境ではサンプルをTwineの実行環境で動かしていないため、公開前に以下のテスト手順を実施してください。
最初にフォーマットを選ぶ
Twineで物語を作成し、ストーリーフォーマットとしてSugarCube 2を選び、使用するバージョンを記録します。マクロ、変数、セーブについて確認できるよう、公式ドキュメントを手元に用意しておきましょう。Harloweの例は構文が異なるため、そのままSugarCubeにコピーすると、単純なシーンがたちまちデバッグ作業に変わってしまいます。
ダウンロードしたソースでは、::で始まる行がパッセージの開始を示します。StoryTitleとStoryDataには設定情報が入っています。Twineのエディターで物語のタイトルとSugarCubeフォーマットを設定し、StoryInitと物語の六つのパッセージを、名前を一字も変えずに作成してください。それぞれの本文を::の見出し行を除いてコピーし、開始パッセージにStartを選びます。.tweeファイルは編集可能なソースです。プレイヤー向けにはHTMLを公開してください。
パッセージのグラフを作る
サンプルでは$sharedPlanをfalseで初期化します。Startには二つの返答があり、SharedPlanでは値をtrueに、SeparatePlanではfalseに設定します。どちらもDiscussionにつながり、そこで値を確認してSharedEndingまたはIndependentEndingへのリンクを表示します。グラフはこれで全部です。一つの決定に、目に見える結果が伴います。
パッセージには変更しない、区別しやすい名前を付け、すべてのリンク先をビジュアルグラフと公開したビルドの両方で確認してください。魅力的なリンクのラベルも、リンク先の名前の誤字は救えません。パッセージの内部名は、書き直したり翻訳したりする本文から切り離しておきましょう。そうすれば、表現を変えてもルートが壊れません。
状態の変化を予測しやすくする
一つの具体的な決定に、名前付きの変数を使います。ここでは$sharedPlanが、プレイヤーが共同の計画を選んだかどうかを記録します。登場人物の間の感情をすべて表す必要はありません。選択が行われる場所で値を設定し、結果が現れる場所で読み取ってください。この関係を明確にしておくと、小さな物語を拡張しやすくなります。
プレイヤーがパッセージを再び訪れたときに何が起こるか確認してください。表示するだけでポイントが加算される場合、再訪時に意図せずもう一度ポイントを与えてしまうことがあります。大きなプロジェクトでは、一度だけ起こるイベントに専用のルールを設け、物語の履歴を戻ったときにその効果を取り消すかどうか決めましょう。再読み込みも、初回の訪問と同じ動作をすると思い込まずにテストしてください。
読みやすいページを設計する
ストーリーフォーマットの標準インターフェースから始めましょう。本文は読みやすい幅にし、読みやすい書体を使い、キーボード操作時のリンクのフォーカスを明確に表示します。幅の狭い画面で段落と選択肢を確認してください。次の行が見つからないとき、装飾のオーバーレイはほとんど助けになりません。凝った背景を追加するのは、読み進めやすくなってからにしましょう。
設定、最初からやり直す操作、セーブの操作を見つけやすくしておきます。利用できるリンクや重要な状態は色だけで示さず、色の手がかりを見落としてもページを理解できるようにしてください。音声や動きを加える場合は操作手段を用意し、控えめに始めましょう。音楽やアニメーションをいつシーンに加えるかは、プレイヤーが選べるようにします。
公開してデータの永続性をテストする
Twineから公開するか、選択したSugarCubeフォーマットでソースをHTMLにコンパイルし、そのファイルを利用予定のホスティング環境で配信します。ブラウザーで、かつプレイヤーが利用するサイトのオリジンでテストしてください。ブラウザーのストレージはそのコンテキストに結び付いているため、ローカルでセーブに成功しても、ホスティングされた版がどう動作するかはそれだけでは判断できません。
決定の前と、その後の両方でセーブしてください。ページを閉じて再度開き、各セーブデータを読み込んで、記憶されている選択と利用可能なエンディングが正しいか確認します。新しいブラウザープロファイルでも、新たにセーブデータを作って同じテストを行ってください。プライベートブラウジング、ストレージを消去した場合、他のページに埋め込んで配信する場合は、それぞれ別に確認します。見つかった制約は説明してください。ブラウザーの設定やホスティング環境の動作によって、セーブデータが保持されないことがあります。
アップデートの手順を準備する
編集可能なソースをバージョン管理し、公開したHTMLリリースをすべて保管してください。SugarCubeのバージョンとパッセージの変更を記録し、代表的なセーブファイルも残して、アップデートを以前のビルドと比較できるようにします。アップデートで既存のセーブデータをサポートするか決めましょう。プレイヤーが最初からやり直す必要があるなら、新しいリリースを読み込む前にその要件を説明してください。
各エンディングを最初からプレイし、すべてのリンクをキーボードで、必要に応じてタッチ操作でも確認します。ルートのテストマトリクスを使って、期待した結果と実際の結果を記録してください。物語が読みやすく、状態が予測どおりに動作し、公開手順を再現できれば、次に進む準備が整っています。大きな分岐の網を作る前に、ルートと状態のガイドを参照しましょう。
重要な決定事項
- SugarCubeのマクロを書く前にSugarCube 2を選んでください。
- Tweeソースを保管し、プレイ可能なHTMLを公開してください。
- 利用予定のホスティング環境で、再訪、セーブ、再読み込みをテストしてください。
- パッセージの名前を変えず、公開したリリースを保管してください。
ガイドのファイル
SugarCube用Tweeサンプル ↓ルートのテストマトリクス ↓外部のモデル関連コミュニティやコンテンツ公開サイトには、露骨な表現を含むコンテンツが掲載されている場合があります。出典へのリンクは新しいタブで開きます。このガイドでは、リンク先のプレビューを読み込みません。