0　未来のPortal：BFシリーズの創造性のゆくえ

―― 変わる前提で作る、壊れにくい思考

• 作り方は変わる：ツールの仕様、AIのふるまい、UIの標準が変わると、ベストプラクティスも変わります。いまの「正解」を“固定した正解”として覚えると、変化のたびに作り直しになります。
• 変化はチャンス：ルールエディタやマップエディタの機能が増えるほど、少ないコードで、より安全に作れる可能性が広がります。
• “見張り方”を覚えると、不安が消える：なにが変わりやすいか、変わったらどこを見直せばいいか――監視ポイントと読み替え手順を持てば、更新は怖くありません。

本章は、未来を言い当てるのではなく、未来が来たときに迷わないための考え方をまとめます。

1　変わりやすいもの・変わりにくいもの

まずは整理です。変わりやすい＝都度見直す、変わりにくい＝長く使い回す。

変わりやすい

• UIの作法（メッセージの出し方、HUDの標準）
• SFX/FXの“鳴らし方”（クールダウンや混雑対策の推奨）
• XPや公開まわりの扱い（状況により制限の可能性は常に意識）

変わりにくい

• 「ことば → 目印 → 効果」 の順番（伝え方の基本）
• IDを名前で管理する（ids.ts）
• 状態を明示し、一度しか通らない道を作る（Phase と onceIn）
• 境界／状態／見せ方の三箱（第7章の分割設計）

未来に合わせるのは“やり方”。守り続けるのは“考え方”。
この切り分けができると、変化は「面倒」から「楽しい調整」になります。

2　ツールの進化に合わせた“読み替え”

2.1　ルールエディタが増える／変わる

• 読み替え：新イベント・新アクションが増えたら、あちこちから直接呼ばず、まず api.ts や ui.ts に自分用の呼び出し関数を1つ作る。main や Script.ts から直接叩く場所を増やさない。
• チェック：既存の onceIn（単一通行）と相性が悪くないか。多重発火しない作りのまま置き換える。

プログラミングでは、このような薄い呼び出し関数を「ラッパ」と呼ぶことがあります。
ここで大事なのは用語ではなく、Portal APIの呼び方が変わっても直す場所を1箇所に寄せることです。

2.2　マップエディタのオブジェクトが増える

• 読み替え：第4章のルールどおり、IDを重複させない／系列を増やすだけでOK。
• チェック：Shared系はベースマップ互換に注意。警告マークが出るかどうかを“いつも通り”見ればよい（第4章の習慣を守る）。

2.3　UI標準の変化（通知、ピン、アイコン）

• 読み替え：ui.say を一箇所で差し替え可能に（第7章・第8章）。
• チェック：「一度に一つ」の原則を崩さない。新UIが来ても同時に複数を出さない。
• 効果：演出の“うるささ”は時代で基準が変わっても、出し過ぎない設計ならズレない。

3　AIとスクリプトの関係（今後の伸び代に備える）

AIまわりは進化の恩恵が大きい領域です。

• 今の作法：AI_Spawner と AI_WaypointPath を使い、湧いた前方の余白と曲がり角の緩さを確保する（第4章）。
• 伸び代：AIの行動APIが増えたら、 「行動はデータ、開始合図はイベント」 に分ける。
  • 例） 行動レシピ を固定値として定義し、ルールからは 「レシピAを開始」 と呼ぶだけにする。
• 理由：AIの細かな命令は変わりやすい。 合図の骨格（押す→誘導→到達→演出） は変わりにくい。
• 実装メモ：いまのうちから、AI関連は 専用の位置のプログラム群として寄せておくと、将来差し替えが楽。

4　パフォーマンスとスケール（先回りの癖）

将来、より大きなマップや密度の高い戦闘が標準になったとき、重さに強い作りは活きます。

• 毎フレーム処理を避ける（第8章9）：距離更新や誘導は0.5〜1秒に1回で十分。
• 同時再生の上限を自前で決める（SFX/FXは“上限3”など）。
• “切れる設計”：遠距離では演出を出さない。ui に距離フィルタを入れておく。
• テスト習慣：満員テストを1回差し込む運用（第9章）。
  • → 未来の“重くなりがちな場面”でも、同じ手順で検証できます。

5　公開後に少人数で育てる作法

モードは遊ばれて初めて成長します。
ただし、Portalで無名の個人モードに自然流入だけで人を集めるのは簡単ではありません。
大手配信者や既存コミュニティの導線がない場合、大人数が継続的に集まる前提で設計しすぎない方が安全です。

本書では、集客そのものを目的にしません。
公開後に見るべきなのは、来てくれた少人数が迷わず始められるか、進行不能にならないか、次に直す場所が分かるかです。

• 256文字以内の短文テンプレ（第9章）を習慣化：目的／人数／所要／最初の行動。
• タグで補足する前提にしない：作成者が自由に付けられるタグはないものとして、タイトル・説明文・サムネ・外部告知で伝える。
• 小さく改善→即公開：少人数の感想から、迷った場所や長すぎた場面を直す。
• 外部告知は無理に広げない：X、Discord、Blog、Noteなど、自分が続けやすい場所を1つ決める。

6　“未来耐性”チェックリスト（半年ごと）

半年に一度、次だけ見直せば十分です。

1. ids.ts：Vitestで -1、重複、用途不明IDをチェック。Godot側の配置IDはObjIdManagerや第4章の台帳で確認。
2. ui.ts：say/guide/celebrate の順番・頻度（うるさくなっていない）。
3. config.ts：防衛秒／クールダウン／推奨人数の数値は今の環境に合っている。
4. flow（遷移表）：分岐が増えすぎていない（不要な分岐は畳む）。
5. パフォーマンス：満員で1回だけ負荷テスト。
6. 説明文：実態とズレていない。256文字以内で、目的／人数／所要／最初の行動が分かる。

7　「今日の正解」を“明日の素材”にする

作って公開して終わり、ではもったいない。

• 使い回す：ui・api・game・ids の4点セットはテンプレとして次のモードにコピペ。
• 薄く始める：新機能が来たら、まずは小さく試す→テンプレへ薄く取り込む。
• 捨てる勇気：重くなった小技は、次のモードでは初手から入れない。過去は図書館、現在は現場。

8　創造性のゆくえ（作り手の視点）

• “正しく怖がる”がクリエイティブを守る：変化を前提に、壊れない芯（ID・状態・順番）だけを固める。
• “最小ループ”は文化になる：押す→誘導→到達→演出、の流れを共有できれば、複数人でも素早く作れる。
• “見える化”が発明を呼ぶ：デバッグHUDで数値と状態が見えると、実験→学び→改善の速度が上がる。

未来は「新しい武器が増える」だけではありません。
“伝え方のルール”が更新されるのです。あなたは、その都度 少しだけ 書き換えればいい。

結論

• 第10章は、未来を占う章ではなく、未来に折れない作り方を定着させる章です。
• 守るのは IDの名前化／状態と単一通行／ことば→目印→効果／三箱分割。
• 変わるのは APIの呼び方／UIの作法／AIの細かい動き。そこはapi や ui を一箇所直すだけ。
• 半年に一度の未来耐性チェックで、あなたのモードは長生きします。

付録／次への案内

• 付録A：主要イベント・アクション一覧
• 付録B：公式サンプルプログラム解説
• 付録C：modlib解説

本章は 最後の哲学 ではなく、 明日も作れる道具箱 です。第3〜8章で築いた手順に、この章の見張り方を重ねれば、Portalがどう進化しても、あなたの創作は続きます。