パラドックス公式フォーラムにてBATTLETECH(バトルテック)開発者日記(Developer Diary)#13が掲載されました。

今回はフラッシュポイントを設計する際にどのようなやり方で行っているのかその舞台裏を紹介する内容となっています。
BATTLETECH 開発者日記 #13 フラッシュポイント作成の概要
※今回はBATTLETECHの主席作家であるHBSのAndrew McIntosh氏が日記の担当です。
はじめに
みなさん、こんにちは!私の名前はAndrew McIntosh、バトルテックの主席作家です。
今日は、フラッシュポイントのシナリオを書くために採用しているテクニックのいくつかを紹介します。
これは、プロセスの簡単な窓口であるため、網羅的なチュートリアルを意図したものではありません。
もしも包括的なガイドを探している場合は、Amechwarriorが対応します。
真剣に彼のガイドをチェックしてください。これは素晴らしいリソースです。

さらに先へと進む前に、おそらくこの事について言及する必要があります。
この開発日記には、DLCであるFlashpointとUrban Warfareのマイナーなストーリーのネタバレが含まれる場合があります。
はい、警告しました!
フラッシュポイントの定義
ではフラッシュポイントとは正確には何でしょうか?
最も基本的なレベルでは、フラッシュポイントは、文脈のある一対のグループ会話の間に挟まれる遭遇戦となります。
線形フラッシュポイントとは、上記のように基本的に分岐をしていない決定ポイントなしとなっている手続き型のコンタクトになっています。
これは大規模なキャンペーンのコンポーネントとしては素晴らしいのですが、スタンドアロンのストーリー構造としては、多くの要望が残されています。
自己完結型のストーリーのため、あなたはおそらく、より多くの深みとして追加のミッション、決定ポイント、および分岐を考えます。
2番目にあるグループの会話、1組の新しいミッション、3番目のグループの会話に分岐を追加することで、ショートスプリットと呼ばれるものに到達します。
Short SplitsはFlashpointの中で最も一般的な形式であり、その理由は、フォーカスされており、分岐を可能にするための意思決定ポイントを持っていて、プレイヤーが喜ぶ範囲を超えないほどに短いものからです。
新しいデザイナーにとって、Short Split形式は手始めに行うものとして最適です。
私の知る限り、Flashpointの長さや複雑さに実際のところ制限はありません。
5つの分岐決定ポイントを持つ10ミッションの構造を設計する場合は、街にでかけましょう!
フラッシュポイントの構造を長く複雑にするほど、書くのに時間がかかり、テストが面倒になることに注意してください。
新しいフラッシュポイントのワークショップ
フラッシュポイントとは何かを確立しましたので、それらを書くことについて話しましょう。新しいFlashpointを作成するために席に座ったとき、自分の考えを導くために自分自身に尋ねるのに適したいくつかの質問があります。
- BattleTechの世界ではまだ語られていない、ある種のストーリーがあるのだろうか?
それとも、すでに探求したストーリーのコンセプトに新たな解釈を加えることができるのだろうか? - BattleTechの伝承としてまだ探究していないが、探究すべきではない正統な要素があるだろうか?
- 例:Flashpoint拡張にある「The Baying of Hounds」ではMorgan Kell氏が突然Kell Hounds社を去ったことの影響について掘り下げている。
- この物語を発展させてくれたBishop Steinerに特別な感謝を!
- 私がシナリオを書きたいと思うような、説得力のある道徳的あるいは戦術的な選択があるだろうか?
- 例:Urban Warfare拡張の「Hearts and Minds」では、プレイヤーがどこまで契約を完遂させようとするかを調べることができます。
- まだ開拓されていないストーリー・トーンやサブジャンルのミリタリー・サイエンス・フィクションで、遊び心のあるものはあるだろうか?
- 例:Urban Warfare拡張の「Tournament of Champions」と「One Man’s Trash」。
これらのFlashポイントはコメディに特化しており、HeartsやMindsのような重くてシリアスなコンテンツから音色が途切れる状況を提供します。書くのも楽しい!
- 例:Urban Warfare拡張の「Tournament of Champions」と「One Man’s Trash」。
これらの自己問答を処理する過程で、通常、ブレインストーミングドキュメントにストーリーの種とキャラクターのアイデアを入れます。
この段階の目標は、細部まで詰めるのではなく、ゆるく高レベルな状態にとどめることです。
フラッシュポイントの可能性について確固たるアイデアを持っていることに満足したら、アウトラインステージに進み、ストーリーコンセプトを一連の明確なビートに分解しようとします。
これらのビートは、自由に使用できるツール、Combat EncountersとGroup Conversationsを使用してマッピングされます。
遭遇戦
遭遇戦はFlashpointのゲームプレイを構成する要素となります。
このため、ストーリーの主要なビートが、使用可能な遭遇タイプと互換性があることを確認することが重要です。
ゲームの内容がストーリーと矛盾している事で、戦闘任務がまるで繋ぎ合わされたように感じさせてはいけません。
ほとんどの遭遇戦は、いくつかの点で柔軟性がありますが、他の点では非常に厳格です。
エスコートクエスト(引率クエスト)には所定のルートがあります。
基地の確保と破壊の遭遇戦は、マップに焼き付けられた建物のプロットを中心に展開し、敵の出現ポイントは常に遭遇レベルに設定されます。
一般的に言って、最も効果的なフラッシュポイントには、自然であり、強制されない方法で一連の遭遇戦と分けることが可能な物語が盛り込まれています。
そのため、物語の核心はおそらく、主人公たちがバトルメックでできること、つまり建物を爆破したり敵部隊を排除したりといったことを中心に据えるべきでしょう。
それとは対照的に、より微妙なアクション (探偵の仕事、探検など)を中心としたストーリーは、BATTLETECの中核的なゲームプレイにはあまり適していません。
もちろん、このようなアイデアをグループ会話の場で検討することもできますが、戦闘ゲーム中にプレイヤーが実際に行っている事が、ストーリーのおまけのように感じられた場合、長期的にはフラッシュポイントとしてはおそらく苦労することになるでしょう。
グループ会話
グループ会話は、フラッシュポイントをコンテキストで包むための主要なツールとして機能します。
また、決定点としてのプレイヤーの選択をゲームに導入する方法でもあります。
グループ会話は多くのことを行うことができますが、それらを書くときに伝統的に従ってきたいくつかの規則があります。
- 会話は会話のみで、説明的な「GM(ゲームマスター)テキスト」はない。
- この決定は、カメラがグループ会話で焦点を合わせているアニメーション化された3D乗組員から生まれました。
これらの各キャラクターは、変更できないシンプルなアイドルアニメーションをループします。
初期プロトタイプの作成中に、これらのアイドルアニメーションと同期していないアクションまたはボディランゲージの記述は場違いで耳障りであることがわかりました。
- この決定は、カメラがグループ会話で焦点を合わせているアニメーション化された3D乗組員から生まれました。
- プレイヤーは結果としてArgoのクルーメンバーの行動が大きく変化することを期待するほど影響力が感じられるような筋書きには概ね反対しています。
- 設計上、フラッシュポイントは任意の順序で再生できるため、この決定を行いました。
- 以前のFlashpointで行われたかもしれない主要な決定を説明するためにすべてのFlashpointを改良することはクールなアイデアですが、それは私たちの規模のスタジオにとっては選択範囲外なのです。
独立したデザイナーとして、これらの規則を順守する必要はありませんが、Flashpointを私たちのものとうまく連携させるには、おそらくこうすべきでしょう。
回避すべき制限のいくつかを確認したので、次に使用する必要があるツールについて見てみましょう。
- キャラクターをエモートさせることはできませんが、イタリックまたはALL-CAPSを使用して感情の強さと興奮を伝えることはできます。
- また、ビュースクリーンを使用して、簡単な説明テキストをごまかすこともできます。
- 慣例により、新しい画像がビュースクリーンに表示されるときはいつでも、プレーヤーが見ているもののステージを設定するために、括弧で囲まれた1行または2行のテキストが付随します。
- 例: [The Liao MechWarrior scowls into the Viewscreen, her brow furrowed in disgust.](Liao MechWarriorは、眉をひそめて嫌気を示し、ビュースクリーンの中へと潜り込む。)
- ダイアログの中でGMテキストを使用することに対する制限をごまかすために、これを控えめに使用できます。
- 音色と方言でキャラクターを区別できます。
- トーナメントオブチャンピオンズのメンシウスホルバート教授は、意図的に大きく幅広いキャラクターとして書かれました。彼の会話スタイルは、「紫の散文」と「大丈夫、これは実際には少し不快になります」のどこかから始まり、カラマー・ギガンテが到着する頃には、コメディに完全に傾いています。
Flashpointの構成要素を確認したので、さらにいくつかの知識をお伝えします。
苦労しないようなやり方でです。
Focus = Quality、またはシンプルに保つことの価値
おおよその概要として、フラッシュポイントの記述で遭遇した問題の約90%は、単一のものにまで突き詰められると言えます。
問題は不必要なストーリーの複雑さです。「やりすぎ」ということです。
これを言うのは痛いです。本当にそうです。
ストーリーが深くて複雑で、プロットの糸が絡み合っていたり、複数の視点から見ているキャラクターがいたり、ジャズが好きです。
しかし、Flashpointsはストーリーの複雑さを満足のいく方法で提供するのにはあまり適していません。
グループ会話が11~12回以上のクリックを要するほど長いと、Flashpointのクロール速度を遅くする可能性があり、遭遇戦の割り込みダイアログを通じて説明を提供することはさらに悪いことです。
超複雑なフラッシュポイントを書くことはできないと言っているわけではありませんが、ストーリーの展開中にレンガの壁にぶつかったことに気付いたら、一歩下がってそこにあるものを調べることをお勧めします。
独自のフラッシュポイントにカットしたり、フラッシュポイントに変えたりできるBストーリーはないか?そこにいる必要のないサイドキャラクターはいないか?ロード・コマンダーの言葉で言うと、「Focus = Quality(フォーカス=品質)」であり、それは、他のものと同じように、フラッシュポイントの作成にも当てはまります。
Writing=Rewriting または反復の重要性
ヘミングウェイがかつて言ったように、「書き直しだけ。」です。
それはゲームを書くことにおいても同じことです。
ゲーム内とエディタ内では、行の外観が大きく異なる場合があります。
アート、音楽、およびUIの要素は、セリフの読み方を完全に変えることができます。
例をあげましょうか。Darius(ダリウス)を見てください。
ダリウスの戦闘の咆哮ーご存知のように、「援軍を送りました」などについての文章を書いたとき、それは彼が非常に有能な傭兵オペレーターだということに気づかせる意図によるものでした。
残念なことに、リリース時にいくつかのバグがあったため、その会話の一部は間違ったタイミングで開始されました。そしてこのような会話の多くが間違ったタイミングで始まりました。
その結果、ダリウスはまったく自信に満ちた態度で、驚くほど誤った戦術情報を繰り返し伝えていました。
その後の結果を説明する必要はないでしょう。
私がこの話をしているのはある理由があります。文字の書き方が必ずしもその文字の受け止め方と一致するとは限らないといいう事です。
Flashpointsを書く際には、ダリウスを襲った特定の問題について心配する必要はないですが、コンテンツをレビューし、改訂することは重要です。
あなたが望むように読めない行がありますか?
ではそれを編集するか捨ててしまうかしてください。
次のFlashpointでは、いつでも再検討することができるでしょう。
最後に
HBSでのフラッシュポイント開発に関する逸話やストーリーを10ページ以上埋めることができますが、管理しやすくするためにここまででまとめます。
とはいえ、もし十分な関心があれば、後ほど別の開発日記でこれをフォローアップできれば嬉しく思います。
とりあえず、開発プロセスのこの短い時間を楽しんでいただけたことを願っています。
コミュニティの皆さんが思いつくフラッシュポイントのいくつかをプレイするのを楽しみにしています!
日記ここまで
感想など
BATTLETECH開発者日記の第13回目でした。
紹介が遅くなってしまい申し訳ないです…。
内容としてはとてもためになるお話で、これはバトルテックに限らずゲームを作ってみたい、あるいはゲームでなくともなにかストーリーを書いてみたいという場合に参考になる内容に感じました。
またダリウスについては確かにプレイ中に「全然噛み合ってない」事が多く、なんとなく頼りないキャラだなぁ…。この人なんで仲間になったんだろう…という様な印象で見ていたのですが、こういう理由があったんですね…。
ダリウスに関する舞台裏が知れて面白かったです。
今回は以上です。
[画像引用元:パラドックスフォーラム内の元記事]