「負けた。」

38日目は、ゲームに負けた日でした。

MISSION FAILED。
自軍の拠点を敵に占領されて、敗北しました。

ユニットは4体全員生存。戦力は開始時と変わらず100%。
完璧な状態のまま、拠点を取られて終わりました。

実装してから初めて出た「負け」の画面です。
悔しいより先に、「ちゃんと動いてる」という安堵がありました。

■ DEMOバグ修正・v1.0.1リリース

Xのフォロワーから詳細なフィードバックをいただきました。

「初級をクリアしたら中級を飛ばして上級に進んだ」という報告でした。

再現を試みると、「保存せずに進む」を選択した場合にのみ発生することが判明。
原因を追うと、ProceedToNext() が2回呼ばれていました。

Unity Input Systemの仕様で、ボタン表示のタイミングによってクリックイベントが貫通することがあります。
セーブパネルが表示された瞬間に、前のボタンへのクリックが「保存せずに進む」ボタンにも届いていました。

修正は _isProceeding フラグを1つ追加するだけでした。
シンプルな解決策ですが、原因特定まではかなり時間がかかりました。

その他、READMEにマップスクロール操作（右ドラッグ）の説明と、初回起動時のWindowsセキュリティ警告の対処手順を追記し、v1.0.1としてBOOTH・itch.ioを更新しています。

フィードバックをくださった方には、修正報告のリプライを送りました。
「遊んで報告してくれる人がいる」というのは、開発の大きな励みになります。

■ フリーゲーム夢現に投稿しました

国内向けのプロモーション展開として、フリーゲーム夢現にDEMO版を投稿しました。

投稿後、当日中に審査が通りました。
思っていたより早かったです。

週1本の制限があるサイトなので、更新頻度には注意が必要です。
BOOTHを正式配布場所として案内するテキストを掲載し、導線を整えています。

■ 中立ユニット占領システム完成

Steam版開発で進めていた中立ユニットシステムが、本日で完成しました。

Step2：自軍化座標への通行制限

制圧前の自軍化座標は、占領能力を持つユニット以外が通行できません。
Pathfindingの移動コスト計算に IsActivationCoord() の判定を組み込みました。

また占領可能ユニットは、その座標に到達した時点で移動が強制停止します。
通過してしまわないよう、ZOCと同じ仕組みで探索をそこで打ち切っています。

敵ユニットで囲むことで座標への進入路を塞ぐ、といった防衛戦術が生まれます。

Step3：旗ビジュアルと点滅ホバー

自軍化座標に旗を立てました。
2枚のスプライトを交互に切り替えるぱたぱたアニメーションで、グループ識別のためにギリシャ文字（α・β）をテキストで重ねています。

旗にカーソルを乗せると、関連する中立ユニットが点滅します。
「この旗を制圧するとこのユニットが動く」という情報を、プレイヤーが直感的に把握できるようにしました。

制圧完了と同時に旗は消えます。

実装中にいくつかバグも出ました。
GetNeutralUnitsAt() がリストの参照をそのまま返していたため、ホバー処理の Clear() で内部データが消えてしまう問題がありました。
new List<>() でコピーを返すことで解決しています。

地味ですが、見落とすと再現性のないバグになります。

■ 敵AIの拡張

占領システムに連動する形で、敵AIを拡張しました。

新しいAIパターン CaptureFirst を追加し、占領優先の行動ロジックを実装しています。

Aggressive + canCapture=true
→ 自軍化座標があれば占領を優先。攻撃はしない。
→ 座標がすべて制圧済みになったら通常の突撃行動に切り替え。

CaptureFirst + canCapture=true
→ 占領優先は同じ。
→ 座標消滅後は、プレイヤーの拠点を直接目指す。

さらに、敵が自軍化座標を制圧した場合、そのターン内に中立から敵化したユニットが追加行動を取るようにしました。
「制圧した瞬間に増援が動き出す」という緊張感が生まれます。

■ スクリプト設計の整理

TurnManager.cs が肥大化していたため、敵AIロジックを EnemyAIController.cs として分離しました。

移管した処理：

• CanAIStartAction()（AI行動開始判定）
• ExecuteUnitAction()（1ユニット分の行動実行）
• FindApproachPath()（接近経路探索）

TurnManager はターン制御とフェーズ管理に専念する構成になりました。
将来的にスコアロジックや複雑なAI判定もここへ集約していく予定です。

■ Steamworks開発者承認

本日夜、Valveからメールが届きました。

「おめでとうございます。あなたはSteamworks開発者になりました。」

KYC申請（4/17）から5日での承認でした。
30日間の待機期間（4/17起算）は変わりませんが、ストアページの作成や設定はこれから進められます。

最短で5/17以降にストアフロントが公開できる見込みです。

執筆後記

MISSION FAILEDを見た時、少し笑ってしまった。

全ユニット生存・戦力100%のまま拠点を奪われた。
戦争に勝って戦略に負けた、という感じです。

「拠点を守りながら中立ユニットを確保しつつ敵を倒す」
そういう判断を迫られるゲームになりつつある。

38日目にして、ようやくゲームらしくなってきた気がします。

「動き出した。」

37日目は、次へ向かう日でした。

DEMOを出した翌日。
静かな余韻の中で、次のことを考え始めていました。
Blueskyを始めて、リポジトリを分けて、コードを書いた。
「公開」から「開発」へ、気持ちが切り替わった一日です。

■ Bluesky、始めました

SNS展開の一環として、Blueskyに新規アカウントを作りました。

@hakubyousai.bsky.social

Xが主軸なのは変わりません。
ただ、英語圏へのリーチを考えると、Blueskyは無視できない選択肢でした。

ゲーム開発者向けのスターターパックが充実していて、登録してすぐに同業者を見つけやすい環境になっています。
Xと違い、外部リンクへのペナルティもないため、BOOTHやitch.ioのURLをそのまま貼れる点も魅力です。

ひとつ失敗したのは、日本語ハッシュタグが文字化けすること。
#ゲーム制作 と書いたつもりが #ゲーム制◆◆ になってしまいました。
Blueskyでは英語タグのみ使用する、と覚えておきます。

#gamedev #indiegame #pixelart #tactics

■ リポジトリを分けた

DEMO版と Steam版、開発リポジトリを分離しました。

D:\GitHub\SteelSymphony          → DEMO版（バグ修正専用）
D:\GitHub\SymphonyOfSteel_Steam  → Steam版（機能追加・正式版）

DEMOをリリースした直後の状態をベースに、Steam版用のリポジトリを新規作成しています。
今後、DEMOへのバグ修正はDEMO版で、新機能の実装はSteam版で、と明確に分離できます。

混ぜてしまうと後で必ず混乱します。
このタイミングで分けておいて正解でした。

■ アーキテクチャ改善：UnitAffiliation enum導入

Steam版開発の第一歩として、コードの改善から着手しました。

これまでユニットの陣営は isPlayer（bool）で管理していました。
自軍か否かの2択です。
ところが中立ユニットの実装を検討した瞬間、この設計が破綻しました。

isPlayer = false → 敵軍？中立？

判断できません。

そこで UnitAffiliation enumを導入しました。

public enum UnitAffiliation
{
    Player,  // 自軍
    Enemy,   // 敵軍
    Neutral  // 中立
}

既存コードへの影響を最小化するため、isPlayer は後方互換プロパティとして残しています。
触るファイルが多かったので、今後は各ファイルを改修する際に合わせて順次対応していく方針です。

■ 中立ユニットシステム実装（Step1）

Steam版の戦術要素追加として、中立ユニットシステムを実装しました。

ネクタリスの工場システムに触発されたものですが、「格納」ではなく「合流」という形にしています。

仕様

マップ上に白色で配置された中立ユニットグループが存在します。
グループごとに「自軍化座標」が設定されており、占領能力を持つユニットがその座標へ移動・行動終了すると、グループ全体がその陣営に所属します。

自軍が先に到達すれば即戦力として合流。
敵が先に到達すれば、事前に設定したAIパターンで動き始めます。

自軍化座標は1グループに複数設定できます。
左右から進軍して取り合う、といった状況も設計できます。

工夫した点

中立ユニットが「敵としてカウントされてしまう」問題が発生しました。
原因は MapManager の初期化処理が、全ユニットに Initialize() を呼び出していたためです。
中立ユニットをスキップする条件を追加することで解消しました。

また、移動途中（キャンセル可能な状態）で自軍化が発動してしまうバグもありました。
OnMoveComplete() ではなく SetDone()（行動確定）のタイミングで判定するよう修正しています。

ステージエディタも対応

Sceneビュー上で中立ユニットと自軍化座標をドラッグ操作できるよう、エディタツールも拡張しました。

白い球：中立ユニットの初期配置
黄色い球：自軍化座標（ACT:0、ACT:1…と複数表示）

中立ユニットはステージ開始時に白色をしています。

目印が無いのでわかりにくいですが、自軍化する座標に歩兵が待機すると白いユニットが味方(青色)になります。

■ 次にやること

Step2として、自軍化座標への通行制限を実装する予定です。
制圧前は占領可能ユニット以外が通行できないようにします。

Step3では旗のビジュアルとアニメーションを追加します。
α・β・γと描かれた旗がぱたぱたと揺れて、占領されたら消える、そういうイメージです。

執筆後記

DEMOを出してから最初の開発日だった。

「次に何をするか」は決まっていた。
でも実際に手を動かし始めると、少し不思議な感覚がある。
目標が「リリース」から「より良いゲームにすること」に変わった瞬間というか。

中立ユニットのシステムを実装しながら、ステージデザインの幅が広がっていくのを感じた。
作っていて楽しい、と思えた一日でした。

「出した。」

36日目は、リリースの日でした。

BOOTH、itch.io、X。
朝から動いて、気づいたら夜になっていました。

作ったものを世界に出す、という行為がこんなに緊張するとは思っていませんでした。
反応があるかどうかより、「出した」という事実の方が、今は大きく感じています。

■ 本日やったこと

BOOTH商品ページを公開した

サムネイル選定から商品説明テキストの作成（日英中3言語）、段落構成の整備まで、一から作りました。

こだわった点はひとつ。
制作環境については何も書かなかった。

「Unity製」「フルスクラッチ開発」と書きたい気持ちはありましたが、それはプレイヤーにとって関係のない情報です。
伝えるべきはゲームの中身だけ、と判断しました。

itch.ioにも公開した

海外向けに英語ページを用意しました。

ひとつ気づいたことがあります。
紹介文に「Nectaris」と書いていたのですが、海外では「Military Madness」として知られているタイトルでした。
両方を併記する形に修正しています。

Symphony of Steel is a turn-based hex strategy game inspired by the classic tactical SLG “Nectaris” (known as Military Madness in the West).

プレイ動画（Stage 1クリアまで）もYouTubeに限定公開し、ページへ埋め込みました。
動画があるとページの説得力が全然違います。

■ 36日間を振り返る

せっかくなので、今日は開発の変遷を画像で振り返ってみます。

戦術マップの変遷

開発初期、マップは本当に殺風景でした。
色のついた四角形がヘックスを示しているだけで、「これがゲームになるのか」と自分でも半信半疑でした。

以下は3月16日頃の画像。丸や四角がユニットです。

地形チップが増えるにつれて、少しずつ「戦場らしさ」が出てきました。
草原や森、都市。仮の地形画像を作成して配置するだけでゲームっぽさもアップ。
ユニットが置かれた瞬間に、はじめてゲームに見えてくるものです。
しかし素材がAIポン出しで統一感無いですね(笑)

現在のマップです。
地形チップはまだ全14種中5種しか完成していませんが、
それでも初期と比べると隔世の感があります。
異なる地形間の接続とか作れてないですが、質感はだいぶまとまってきたかなと。

戦闘画面の変遷

戦闘画面は、最も試行錯誤した部分です。

最初期は、まずユニットを表示する。次にただ数字が表示するといった感じで見た目も全然作り込んでません(笑)
ATKとDEFとHPが表示されているだけで、演出も何もない。
常時表示されているデバッグ用ボタンがなんとも。

以下の画像は3月17日から3月18日頃に撮影していました。

その後、戦闘背景・ユニットスプライト・エフェクトと順番に追加していきました。
爆発エフェクト、ヒットエフェクト、回復エフェクト。
音も付いた。
少しづつ現在の形に近づいていきます。

この辺で大まかなイメージが固まってきた感じです。画像は3月23日に撮影。

そして36日目の時点では、補正表示まで追加されています。
地形ボーナス、支援ボーナス、包囲ペナルティが色分けされてフェードインする。

「数字が並んでいた画面」が、ここまで来ました。

UIの変遷

UIはおそらく、最も変化が激しかった部分です。

初期のUIは仮置きの白いパネルばかりでした。
フォントも暫定、色も暫定、レイアウトも暫定。
「動けばいい」という段階です。

タイトル画面もテキスト直書きしてるだけのシュールさ。
3月19日のスクリーンショットですね。見た目はともかく動けばいいという感じ(笑)

戦術画面も早期に下部パネルは作りだしていますが、右側はすっかすかでターン終了のボタンだけ配置してただ動かせますといった状態。
以下の画像は3月25日に撮影してます。この辺の作業の２～３日で劇的にゲーム画面が変化しました。

現在のUIです。
タイトル画面は大幅に改修し、戦術画面もユニット情報パネル、フェーズ表示、各種ボタンなど賑やかになりました。
まだ統一感に課題はありますが、「ゲームのUI」として機能するものになりました。

■ 36日間でできたこと・できなかったこと

できたこと

• ヘックスグリッドの戦術マップ
• ターン制の戦闘システム
• 地形効果・支援ボーナス・包囲補正
• 熟練度システム（0〜20・星表示）
• セーブスロット3つ
• 日英中3言語対応
• BGM・SE
• 勝敗ファンファーレ
• バトル画面補正表示
• セーブデータバージョン管理基盤
• DEMOビルド完成・公開

できなかったこと（正式版へ先送り）

• 解像度1920×1080対応
• ピクセルアートの統一感
• 自動ターン終了
• 画像系素材の準備（一部、DEMO完成優先で先送りなど。）

「できなかったこと」は、意図的に先送りにしたものがほとんどです。
完璧を目指してリリースしないより、動くものを出してフィードバックをもらう方が正しいと判断しました。

■ これから

Steam版の公開を5月17日以降に目指しています。

まずはSteamworks SDKの導入。
そしてストアページの素材準備。

DEMOへの反応を見ながら、正式版の完成度を上げていきます。

無料で遊べるDEMO版はこちらです。

BOOTH：https://atelier-ksg.booth.pm/items/8223410
itch.io：https://hakubyousai.itch.io/symphony-of-steel-demo

執筆後記

リリース日の記事を書くのは、思ったより難しかった。

「やったこと」より「感じたこと」の方が多い日でした。
出してしまえばこっちのもの、と思っていたのですが、出した後の方が静かで、少し怖い。

反応がくれば嬉しいし、こなくても続ける。
それだけです。

「リリースの形が、ようやく見えてきた」日

35日目は、開発系の実装とリリース準備を同時に進めた一日でした。

バトル画面への補正表示追加。
セーブデータのバージョン管理基盤の導入。
ビルド作成、アイコン・カーソルの設定、README作成。

やることが多かったですが、気づいたら全部終わっていました。

■ バトル画面に補正表示を追加した

何が変わったか

戦闘前の準備フェーズに、発生した補正をパネルの下部へ積み上げ表示する演出を追加しました。

表示される補正は以下の4種類です。

• 地形防御補正（EFFECT DEF+XX% / DEF-XX%）：プラスは緑、マイナスは赤
• 支援攻撃ボーナス（SUPPORT ATK +）：シアン
• ジャミング制圧ボーナス（SUPPORT DEF +）：シアン
• 包囲成立（FLANKED ATK/DEF -50%）：オレンジ

補正が発生しない場合は表示されません。詰めて表示します。

演出のこだわり

ただテキストを出すだけでは面白くないので、出現時に少し工夫しました。

白くフラッシュしながら大きいサイズで出現し、指定の色・通常サイズへ収縮する。
0.2秒程度の短い演出ですが、「補正が乗った」感が出ていい感じです。

InspectorでフラッシュのdurationとスケールのStart倍率をチューニングできるようにしてあります。

包囲表示の文言について

包囲成立の表示に「×½」という表記を使おうとしたのですが、
使用フォントで「×」「½」の両方を表示できず断念しました。

ASCII文字のみで構成した「FLANKED ATK/DEF -50%」に落ち着いています。
英語圏のプレイヤーにも伝わる表現なので、結果的にこちらの方が良かったかもしれません。

最初は雑にTextオブジェクトにとりあえず正しく動いてるか確認できるレベルで実装テストします。

最終的には以下のようになりました。

■ ターンチェンジ回復SEを追加した

回復エフェクト（緑の+N表示）は実装済みでしたが、音が鳴っていませんでした。

HealEffectRoutine()の冒頭にSE再生を1行追加するだけで完了です。
既存の爆発SEと同じパターンなので、影響範囲はUnitController.csのみ。シンプルな修正でした。

■ セーブデータのバージョン管理基盤を作った

なぜ今やるのか

開発中にセーブデータの構造は頻繁に変わります。
フィールドを追加したり、削除したり、型を変えたり。

そのたびにユーザーに「セーブデータを削除してください」と伝えるわけにはいきません。
DEMO版のうちに仕組みを入れておくべき、と判断しました。

設計の方針

基本思想は「読めたら移行、読めなければ削除して初期化」の2段構えです。

起動時
 └─ SaveDataMigrator.Migrate()
      ├─ バージョン確認
      ├─ 旧バージョン → 移行処理（フィールド補完）
      ├─ 破損 → 削除して初期化
      └─ ダウングレード → 削除して初期化

各JSONファイルに saveVersion フィールドを追加し、アプリ側に現行バージョン定数を持たせます。

public static class SaveDataVersion
{
    public const int SAVE_DATA   = 1;
    public const int SYSTEM_DATA = 1;
}

将来の運用

構造を変えるたびに SaveDataVersion を +1 し、MigrateSaveDataFrom() に移行処理を追記するだけです。

累積適用パターン（if (oldVersion <= N)）で書いておけば、v0のデータが来てもv1→v2→v3と順番に全部適用されます。
離れたバージョン間の移行を個別に考える必要がありません。

ちなみに今回、JsonUtility はフィールドが増えても減ってもデフォルト値で黙って読んでくれることを改めて確認しました。
つまりフィールドの追加・削除だけなら「バージョンアップして上書き保存」するだけで十分です。
本当に困るのは型が変わった場合や、JSONとして物理的に壊れた場合だけです。

■ ビルド作成と各種設定

Company Name / Product Name を英数字に統一した

ビルドを作る前に、Player Settingsを整理しました。

日本語のCompany Name・Product Nameをそのまま使うと、
中国語環境のWindowsで文字化けや起動失敗のリスクがあります。

Company Nameを変えるとpersistentDataPath（セーブデータの保存先）も変わります。
DEMO版初回リリースのこのタイミングで変えておかないと、
正式版リリース後に変えた場合、既存ユーザーのセーブデータが消えます。
今変えておいて正解でした。

アイコンとカーソルを設定した

どちらもChatGPTで生成しました。

アイコンは512×512のピクセルアート風戦車画像。
ヘックスグリッドの背景に戦車のシルエット、という構成で、ゲームの雰囲気が伝わりやすいデザインになっています。

カーソルは64×64のシェブロン（階級章）モチーフの矢印。
ミリタリー感があってゲームに合っています。

カーソルはPlayer SettingsだけではなくコードでもCursor.SetCursor()を呼ぶ必要がありました。
Unityあるあるですね。

以下はアイコン画像です。

ビルドサイズについて

ビルドフォルダの解凍後サイズは約679MB。
思ったより大きいと感じましたが、中国語フォントが130MB超あることが判明しました。

これはFont Assetの文字セットを使用文字だけに絞れば大幅削減できます。
ただしDEMO版はレイアウトが完成しており今から変更するのは手間なので、正式版で対応する予定です。

ZIP圧縮後は約254MBまで減りました。予想より圧縮が効いて良かったです。

README.txtを作成した

日本語・英語・中国語の3言語を1ファイルに収録しました。

記載内容は以下の通りです。

• ゲーム概要・動作環境・起動方法
• 操作説明（マウスオンリー、左クリック決定・右クリックキャンセルが基本）
• 注意事項・免責事項
• クレジット（BGM：PeriTune様、SE：効果音ラボ様、フォント、AI開発支援）

AI開発支援については Claude・ChatGPT・Gemini の3つを記載しています。
今やAIなしでの個人開発は考えられないので、きちんとクレジットしておきたいと思いました。

■ 現在の残タスク（35日目時点）

執筆後記

今日は「実装」と「リリース準備」を同時に走らせた一日でした。

バトル画面の補正表示は、ずっと「余力があれば」と先送りにしていた機能です。
やってみたら思ったより工数がかからず、演出もいい感じに仕上がりました。
先送りにしていた自分を少し反省しています。

セーブデータのバージョン管理は、地味ですがリリース前に必ず入れておくべき仕組みでした。
ユーザーに「フォルダのファイルを消してください」と伝える未来を回避できました。

ビルドも出来た。READMEも書いた。
次はBOOTH商品ページを作れば、DEMO版のリリースが現実になります。
もう少しです。

「配布準備が、全部動き出した」日

34日目は、リリースに向けた実務を一気に片付けた一日でした。

BOOTHショップの公開。Steamworksへの開発者登録。
どちらも「やらないといけないのはわかってるけど後回しにしてた」作業です。

気づいたら両方終わっていました。

■ BOOTHショップ公開

ショップのコンセプトを整理した

今回のBOOTHショップは、鋼鉄の交響曲専用ではなく「スタジオ白猫斎のくそげ工房」として設計しています。

将来的に複数のゲームを出す想定のため、特定タイトルに依存しない構成にしました。
親ブランド「くそげ工房」・子ブランド「スタジオ白猫斎」という関係で、ヘッダー画像にも両方のロゴを配置しています。

ショップ名：白猫斎のくそげ工房 / Studio Hakubyousai (Atelier-KSG)
URL：https://atelier-ksg.booth.pm/

特定商取引法に基づく表記を整備した

無料配布でも、特定商取引法の表記は整備しておくべきと判断しました。

個人・無料配布のみという条件では義務対象外ですが、表記があることで閲覧者への信頼感が上がります。
また将来有料販売を始めた際の対応コストを下げる意味でも、今のうちに整えておく方が合理的です。

特に重要だと感じたのが免責事項です。

フリーウェアを配布する以上、
「このゲームを使って生じた損害には責任を負わない」
という旨を明記しておかないと、万が一のクレームへの対応が難しくなります。

今回の表記には以下を含めています。

・本ソフトウェアの使用により生じたいかなる損害についても開発者は責任を負わない
・動作を完全に保証するものではない
・ご自身の責任においてご使用ください

無料で配って責任を取らされる事態は避けたいので、ここは慎重に対応しました。

■ Steamworks開発者登録

思ったより手続きが多かった

Steamでゲームを販売するためには、Steamworksへの開発者登録が必要です。
登録自体は無料ですが、ゲームを1本登録するたびに$100（Steam Direct料金）の支払いが必要になります。

今回の手続きの流れは以下の通りです。

1. Steamworksアカウント登録
2. NDA（秘密保持契約）署名
3. SDA（Steam配信契約）署名
4. $100支払い
5. 銀行口座情報入力
6. 税金情報（W-8BEN）提出
7. 本人確認書類（KYC）アップロード

一日でここまで終わらせるつもりはなかったのですが、一つ終わるたびに次のステップが見えてくるので、結果的に全部やりきりました。

税金情報でつまずきそうなポイント

海外販売では米国の税務申告に対応したフォーム（W-8BEN）の提出が必要です。
日本在住の個人であれば、日米租税条約が適用されます。

マイナンバー（個人番号）を外国TINとして提供することで、源泉徴収税率0%が適用されました。

つまり、Steamの売上から米国税が引かれない状態になっています。
これは日本と米国が租税条約を結んでいるためで、日本在住の開発者には有利な条件です。

30日待機がスタートした

$100を支払った日から、ゲームをリリースできるようになるまで30日間の待機期間があります。
これはValveが取引相手の情報を確認するための期間です。

4月17日に支払いを完了したため、5月17日以降にストアページの公開（「近日登場」）が可能になります。
実際の販売開始はそこからさらに最低2週間後となるため、最短でも6月上旬の見込みです。

この待機期間中にストアページの作成・審査・「近日登場」ページの公開を進めることができるため、
実質的に準備を並行して進めることになります。

とりあえず$100払ったから後戻りはできないですね(笑)
絶対に何かは販売します。売れるかはわからないですが…。

■ 現在の残タスク（34日目時点）

執筆後記

今日は「やらなきゃいけないけど面倒くさそう」な作業を全部片付けた日でした。

BOOTHショップは思ったよりシンプルに整えられました。
Steamworksは思ったより手順が多かったです。

ただ、どちらも「やり始めれば終わる」作業でした。
後回しにしている間の精神的負荷の方が、実際の作業コストより高かったかもしれません。

次の作業はBOOTH商品ページの作成です。
ビルドを作り、READMEを書き、説明文を用意する。
ここまで来たら、あとは手を動かすだけです。

「DEMO版の中身が揃った」日

33日目は、積み残していたコンテンツ制作を一気に片付けた一日でした。

ステージストーリーテキスト、ブリーフィングイメージアート、AIバグ修正。
それぞれ個別には小さな作業に見えますが、これで「DEMO版として出せる中身」が揃いました。
残るは配布準備だけです。

■ ステージストーリーテキスト：全4ステージ完了

攻略ヒントを命令口調に溶け込ませる、という方針を継続

前回、ステージ1「初級演習」のテキストが完成していました。
33日目では残る3ステージ分を一気に作成し、全4ステージが完了しました。

各ステージのテーマは以下の通りです。

難易度が上がるにつれて、テキストの締めくくりも変化させています。

• ステージ1：「速やかに敵を掃討せよ」（基礎の確認）
• ステージ2：「それが今回の演習で問われる判断力だ」（応用）
• ステージ3：「判断の質だ」（戦略的思考）
• ステージ4：「卒業してみせろ」（総仕上げ）

単なる状況説明ではなく、指揮官としての成長を示す流れになっています。
日本語・英語・中国語の3言語で作成しています。

■ ブリーフィングイメージアート：全4枚確定

ChatGPTを使ったピクセルアート生成

ブリーフィング画面に表示するイメージアートを、ChatGPTで生成しました。

方針として「ゲーム本体のドット絵と世界観を合わせる」ことを優先し、
ピクセルアート調・俯瞰視点・くすんだ色調で統一しています。

試行錯誤のポイントとして、画像参照よりもテキストプロンプトで
スタイルを言語化する方が安定した結果になりました。
また矢印やUIっぽい要素が混入しやすいため、
「no arrows, no UI elements」の明示が必須でした。

DEMO版のクオリティとして十分と判断し、全4枚を確定としました。

■ 敵AIバグ修正：StationaryとDefensive

Stationary：射程内でも攻撃しない問題

待機型AI（Stationary）が、攻撃範囲内にプレイヤーユニットがいるにもかかわらず攻撃しない場合がある、というバグを修正しました。

原因はターゲット選択のスコア計算にありました。
ダメージ期待値が低いユニットに対してスコアが不安定になるケースがあり、結果として攻撃対象が選ばれないまま行動終了していました。

特に防御力の高い超重戦車に対して顕著で、経験値が上がって攻撃力が増すと攻撃し始めるという、意図しない挙動になっていました。

修正方針として、Stationaryは「射程内の最初のターゲットを即採用」する専用ロジックに変更しました。
「動かない砲台は射程内なら必ず撃つ」という直感的な挙動になっています。

影響範囲はTurnManager.csのEnemyRoutine内のみです。

Defensive：移動後射程での攻撃判定漏れ

防御型AI（Defensive）が、移動すれば攻撃可能な範囲にプレイヤーユニットが入っても攻撃してこない問題を修正しました。

判定が「現在地からの攻撃射程」のみで、「移動後に攻撃可能か」を見ていなかったことが原因です。

修正後は意図した挙動で動作することを確認しています。

■ X運用続報：フォロワー整理の結果

※ここからは私個人のケースとして記録しています。
同じ手法がすべての方に当てはまるわけではありません。

前回の推論を実行に移した

前回の記事で「無反応フォロワーの増加が初動インプレッションを下げる」という推論を書きました。

4月15日、急増したフォロワーの約10%を整理しました。
整理の基準は「フォロワー数の増加・インプレッション・収益化のみを目的とした発信しかしていないアカウント」です。

結果：インプレッションが明確に改善した

4月15日・16日のインプレッションが、直前の数日と比較して明確に改善しました。

グラフを見ると、4月9日の#ブルバ100実施後にフォロワーが急増し、数日後にインプレッションが落ち込む流れがはっきり確認できます。
フォロワー整理後の4月15〜16日は、この落ち込みから回復しています。

考察

今回の結果から言えることを整理します。

フォロワー整理はマイナスを減らす作業

フォロワー整理によってインプレッションが回復したのは、自分の投稿に関心を持つアクティブフォロワーの割合が増えたためと考えています。
Xは投稿直後の初期反応でリーチを決める構造のため、無反応フォロワーの割合が高いほど投稿が広がりにくくなります。

ただし、これはあくまで「マイナスを減らした」に過ぎません。
フォロワーを整理しても、反応してくれる層が増えるわけではないからです。

ブルバ100が悪いわけではない

念のために書いておくと、#ブルバ100という手法自体が良い・悪いという話ではありません。

フォロワー増加・インプレッション拡大・収益化を目的とした発信であれば、ブルバで集まる層とコンテンツのテーマが一致するため、非常に強い拡散力を持つ手法です。

私の場合、個人ゲーム開発が主なテーマのため、増えたフォロワーとのニーズにミスマッチが生じました。
それが今回の結果の原因です。

本質は地道な積み上げ

結論として、インプレッションを安定させるには「自分のコンテンツに関心を持つフォロワーを地道に増やす」以外に近道はないという考えに至っています。

数を追うのではなく、反応する層を丁寧に作っていく。
宣伝フェーズに向けて、この方針で運用を続けます。

■ 現在の残タスク（33日目時点）

執筆後記

DEMO版の中身が揃いました。
33日間かけて積み上げてきたものが、ゲームとして形になっています。

残るは配布準備だけです。
BOOTHヘッダー画像と特定商取引法の表示を片付ければ、4月下旬のリリースが現実的な射程に入ってきました。

X運用の話は、ゲーム開発とは少し離れたテーマですが、宣伝フェーズで同じ失敗をしないための記録として残しています。
個人開発者がSNSで発信する場合、数より質という話は理屈ではわかっていても、実際にデータで確認すると改めて実感します。

リリースに向けて、最後の準備を進めます。