【ITニュース解説】Dev Log 19 - Chaos To Clarity

この開発日誌は、Unityというゲーム開発ツールを使って一つのプロジェクトを進める過程で直面した困難と、そこから得られた学びについて詳しく述べたものである。特に、システムエンジニアを目指す初心者が、実際の開発現場でどのような壁にぶつかり、それをどう乗り越えていくのかを知る上で非常に参考になる。

開発者は、Unityのユーザーインターフェース（UI）に関する経験がほとんどない状態で、このプロジェクトを開始した。最初はコンセプトと少しの空き時間しかなかったものの、約3ヶ月間、AIアシスタントの助けを借りながら、実践を通して学ぶという方法で開発を進めてきた。この「実践を通して学ぶ」というアプローチは、多くのエンジニアが実際に採用している効果的な学習方法だ。

初期の最大の課題は、様々なデバイスでのレイアウト互換性の確保だった。開発者は「アンカー」「ピボット」「レイアウトツール」といったUnity UIの基本的な機能を適切に使っていなかったという初歩的なミスを犯した。例えば、Galaxy S7という特定のデバイスでのシミュレーションモードだけでUIを構築し、それで全てがうまくいくと思い込んでいた。数週間もの間、その設定で開発を続けた結果、SafeAreaHandler.csというスクリプトを使えばモバイルデバイス間の表示のずれが全て解決されると誤解していた。しかし、実際にはそうではなかった。「Game View」というUnityの表示機能が、実際のデバイスでの表示と異なり、開発者を欺く結果となったのだ。また、「Prefab（プレハブ）」という再利用可能な部品も、期待通りの動作をせず、レイアウトは悪夢のようにデバイス間でずれてしまった。

こうした困難に直面しながらも、開発者は諦めなかった。各シーンでアンカー、ピボット、そしてオーバーライドという、UI要素の配置や挙動を制御する設定を一つ一つ見直し、修正を繰り返した。この地道な作業は、まるで儀式のようだったと述べている。

SafeAreaHandler.csの有効性を検証し、Pixel 5やiPhone Xといった異なるデバイスでのシミュレーションを通じて、ついにレイアウトの真実に気づいた。アンカーやピボットの監査も行ったが、それでも完全に問題を解決することはできなかった。

そして、開発者は一つの大きな決断を下した。それは、モバイルサポートを完全に断念することだった。何週間もの試行錯誤と挫折を経験した後、モバイルでの動作を完璧にすることは難しいと判断し、デスクトップ版の開発に注力することにしたのだ。最終的な目標をSteamでのPC版リリースに絞り、モバイルアプリストアでの配信は行わないことに決めた。これにより、何百もの異なるモバイルデバイスに対応するための調整作業から解放され、一つの安定したレイアウトに集中できるようになった。

この方向転換後、開発作業は大きく進展した。まず、モバイルサポートをアーカイブ（保存し、使用しない状態に）し、解像度を1920×1080ピクセルに固定した。タッチ入力は非推奨とし、マウスとキーボード操作のロジックを構築した。Canvas Scaler（キャンバススケーラー）というUIの表示サイズを調整する設定は「Constant Pixel Size（定数ピクセルサイズ）」に設定された。AIを使って背景画像をワイドスクリーン用に拡張し、UIのヘッダー、メインパネル、サイドバー、フッターといった「UIゾーン」を明確に定義し、全てのキャンバスとパネルを調整した。これにより、シーン全体でのPrefabの安全性が確保され、50以上のモジュール化されたオブジェクトがシステムに統合された。

これらの経験から、開発者はいくつかの重要な教訓を得た。一つは「Game Viewは嘘つきだが、Device Simulatorは真実を教えてくれる」ということ。Game Viewはあくまで開発中の目安であり、実際のデバイスでの表示は「Device Simulator」で確認する必要があるという学びだ。次に、「アンカーとピボットは非常に重要であり、開発の最初から適切に使うべきだ」という点。そして、「Prefabのオーバーライドは、その必要性を理解した上で慎重に行うべきで、安易に使うべきではない」ということも学んだ。レイアウトは単なる見た目ではなく、物語を伝える上で重要な要素であるとも気づいた。さらに、技術的な問題を解決することは、開発という物語の中での節目であると感じている。チュートリアルから学ぶよりも、経験を通して学ぶことの方が楽しく、そして同じくらい、あるいはそれ以上に重要であるという実感も得た。そして最後に、「問題が解決できない場合は、目標を変えることも有効な手段である」という教訓だ。今回のケースでは、モバイル対応を諦め、デスクトップに専念することで、プロジェクトを前進させることができた。

UIのレイアウト問題が解決し、プロジェクトの基盤が固まった後、開発者はゲームの核となる「物語分岐システム」の実装に取り掛かった。このシステムは、プレイヤーのキャラクターが持つ特性や装備（ギア）の状態に基づいて、物語の流れや表示されるテキストが変化するというものだ。例えば、「防水」や「ガス耐性」といった特性、あるいはそれらの否定形（「防水ではない」「素足である」など）によって、次に起こるイベントや表示される選択肢が変わる。

PlayerStats.csというスクリプトでは、装備のスロットに応じた特性チェックや、特性の否定形をサポートするロジックが実装された。また、条件が一致しなかった場合のフォールバック（代替）ロジックも組み込まれた。StoryNodeLoader.csというスクリプトは、こうした条件に基づいて適切なテキストを選択し、環境ハザード（危険な状況）への対応も行う役割を担っている。JSONスキーマというデータ形式も、条件フォーマットを標準化するために利用された。

開発者は、特定の条件（例えば「素足で、防水ではない」）が設定された状況で、物語の分岐が正しく機能するかを検証した。デバッグログを通じて、システムがプレイヤーの特性と一致する物語のバリアントを正しく選択し、UIにレンダリングしていることを確認できた。これにより、システムの完全な統合が確認され、ランタイムエラーやデータの読み込みに関する問題がないことも検証された。

今後のステップとして、さらに多くの特性（汚染、静か、耐火性など）をシステムに追加することや、装備スロットに視覚的な特性インジケーターを追加すること、そして装備レジストリ内のタグの欠落をチェックするバリデーターの作成などが挙げられている。

開発者は、このシステムの実装を「テストではなく、儀式」と表現している。システムがプレイヤーの装備状態を正確に認識し、特性の否定形も解釈して、適切な物語の展開を提供した。この達成感は、ハッキングや一時的な修正に頼るのではなく、クリーンな分岐ロジックが基盤から実行時にまで流れるように機能したことによるものだ。

一時的なUIレイアウトの問題で意気消沈した時期もあったが、今では困難を乗り越えて得た教訓を胸に、新たな方向へ進んでいる。開発者が最後に引用した「システムはクラッシュしなかった。それは頭を下げたのだ。」という言葉は、システムが開発者の意図通りに正確に機能したことへの深い満足感と達成感を表している。このプロジェクトは、単にお金を稼ぐためではなく、開発者自身がプレイしたいと思える、深みと物語、そしてリプレイ性のあるユニークなゲームを作るという情熱によって推進されている。レイアウトが固定され、システムが統合された今、開発者は着実に前進していく準備が整ったと述べている。