スタジオ全員が信頼できる分岐ストーリーを
ライターは各シーンをビジュアルに組み立て、ルートプランナーがシーン同士のつながりをチェックし、osf コマンドラインツールがすべてのプルリクエストで同じチェックを実行します。
承認に関わる全員に、イエスと言う理由を
分岐会話をもっと良い方法で書く必要があることは、あなたが一番よく知っています。味方にしたい人それぞれにとって、LoreHub で何が変わるかをまとめました。
ナラティブチームに必要なすべてを、すべてのプランで
プランの違いは容量と席数だけで、機能に差はありません。
プログラマーも納得するオープンな基盤
LoreHub は非公開のデータベースではなく、オープンな形式に保存します。ファイルはゲームと並べて Git や Perforce に置き、変更はほかのコード変更と同じようにすべてレビューし、OSF を扱えるどのツールでも開けます。もし LoreHub をやめることになっても、ストーリーは一緒に持ち出せます。
検証では、スキーマ、会話間のすべてのジャンプ、キャラクターと変数のすべての参照、到達不能なノード、未翻訳の行をチェックします。osf コマンドラインツールが、プルリクエストごとに同じチェックを実行します。
厳密なスキーマを持つプレーンテキストは、AI アシスタントにとって読み書きしやすい形式です。AI による編集ごとに検証を実行してリンク切れや未翻訳を捕まえ、あとは通常の diff としてレビューするだけです。
すべての行に安定したキーがあり、翻訳はストーリーファイルと同じ構造で管理されます。言語ごとに、未翻訳の行でビルドを止めるか、ソース言語で代替するかを選べるので、ある言語を先にリリースして後から仕上げることができます。
Open Story Foundation は、LoreHub の開発者が立ち上げたインタラクティブストーリーのためのオープンな標準で、あらゆるツールやエンジンに開かれています。
OSF についてライターの編集から、プレイできるシーンへ
- 1書く
LoreHub またはプレーンな OSFライターが LoreHub のビジュアルエディターでシーンを変更するか、任意のテキストエディターで .osf ファイルを直接編集します。どちらでも結果はプレーンな .osf ファイルです。
- 2レビューGit または Perforce
変更は通常の diff として届きます。開発者はプルリクエストや Perforce のチェンジリストで、ほかのコード変更と同じようにレビューします。
- 3検証osf validate
無効なジャンプ、未定義のキャラクターや変数、到達不能なノード、未翻訳の行が、ファイル名と行番号付きで報告されます。
- 4ビルドosf build
プロジェクトは JSON または YAML にコンパイルされ、会話、キャラクター、変数ごとに一つのリソースになります。
- 5プレイCLI、LoreHub、またはエンジン
osf CLI でターミナル上で、LoreHub の会話プレイヤーで、あるいは JSON や YAML をゲームエンジンに読み込んでシーンをプレイできます。
1 つのシーンで、2 週間でイエスを
決定を勝ち取るのに移行計画は要りません。1 つのシーンを LoreHub で回し、見つかったものをチームに見せましょう。
- 11 週目：シーンを 1 つ選ぶ
すでに問題を起こした分岐シーンを選び、担当者と一緒に Free プランで作り直します。
- 22 週目：新しいやり方で進める
ルートマップで会話をつなぎ、言語を追加し、ライターと翻訳者に同時に作業してもらいます。
- 3その後：見つかったものを見せる
ルートの衝突、古い翻訳、変更履歴をプロデューサーとテックリードに見せましょう。その打ち合わせには私たちも参加できます。