Unity on Wuyukwi's Notebook

☝️ 「汎用化したい」という衝動と、開発の現実

Mon, 18 May 2026 17:34:45 +0900

プログラマーを数年やっていると、おそらく全員が一度は同じことを考える。

最初はただ動けばよかったコードが、だんだん気持ち悪く見えてくる。
コピペも増える。責務も混ざる。依存も汚くなる。

すると自然に、

共通化したい
抽象化したい
再利用可能にしたい

という欲求が出てくる。

これは悪いことではない。むしろ健全だと思う。
“設計”を意識し始めた証拠だから。

ただ、この感覚はかなり危ない。

一歩間違えると、
簡単に「過剰設計」に転がり始める。

「将来使うかもしれない」

この一言が、
過剰設計の始まりになることはかなり多い。

今回は、自分がゲーム開発をやる中で感じた、

なぜ人は汎用化したくなるのか
なぜそれが失敗しやすいのか
実際どう考えるとちょうどいいのか

について書いてみる。

汎用化したくなるのは、実はかなり自然なこと

例えば、最初の頃のコードってかなり局所的になる。

if (isBoss)
{
hpBar.color = Color.red;
}

みたいな、「今必要だから書いたコード」が大量にある。

でも経験を積むと、
こういうコードを見るだけで“変更コスト”を想像するようになる。

「これ別のボス出たらどうするんだろう」
「色変えるたびに if 増えるの？」
「そもそも UI が敵情報知ってるのおかしくない？」

みたいなことを考え始める。

つまり汎用化欲求の正体って、単なる意識高い設計趣味ではなく、

“変更に弱いコードへの違和感”

なんだと思う。

だからある程度コードを書いた人ほど、自然と抽象化に向かう。

実際、汎用化にはかなり強いメリットがある

これは間違いない。

1. 「依存」に敏感になる

再利用を意識すると、まずベタ結合が気になり始める。

直接参照
Singleton ベタ依存
MonoBehaviour 神クラス
Inspector 配線地獄

みたいなものを避けたくなる。

結果として、

責務分離
Interface 化
データ駆動
疎結合

みたいな方向へ進む。

🧊 【Unity】10万オブジェクトを回転させたらどこがボトルネックになるのか（後編：ISystemで一桁msへ）

Wed, 01 Apr 2026 12:47:15 +0900

はじめに

前回は、Job System + Burst を使って
10万オブジェクトの回転処理（46ms → 3.5ms） まで最適化しました。

ただしその時点でも、フレーム全体としてはまだ重く、
ボトルネックはレンダリング側に残っていました。

なぜJob Systemだけでは不十分だったのか

前回の時点で回転処理自体はかなり軽くなっていましたが、
それでもフレーム全体としては大きな負荷が残っていました。

原因は、描画周りの処理です。

たとえロジック（Job）が高速でも、メインスレッド側では依然として
10万個の MeshRenderer を個別に処理する必要があります。

具体的には以下のような処理です：

Culling（可視判定）
Bounding Volume（バウンディング更新）
RenderQueue（描画順の整理）

これらがすべて「オブジェクト単位」で実行されるため、
結果として大きなCPU負荷になっていました。

この問題に対するアプローチが、Entities Graphicsです。

目標：
→ GameObjectベースのオブジェクトをEntityに変換する
仕組み：
→ 変換後は、これらの処理を Entities Graphics が内部的に管理し、
BatchRendererGroup を利用して描画処理をまとめて実行します。

その結果：

数万〜数十万単位のオブジェクトでも、
ごく少数のバッチとして扱えるようになります。

■ 結果

今回は DOTS（Entities + Entities Graphics）に移行した結果：

フレーム時間：約120ms → 約9ms
110FPS前後で安定

ほぼ別物レベルまで改善しています。

■ 比較

指標	改造前（GameObject）	改造後（Pure DOTS）	改善
Batches	~120,000	74	約1486倍削減
SetPass Calls	56	26	約2.1倍改善
Tris / Verts	不安定	安定	描画の一貫性向上
Frame Time	120ms（8FPS）	9ms（110FPS）	約13倍高速化

■ Profilerを見ると何が起きているか

Profilerを確認すると：

🧊 【Unity】10万オブジェクトを回転させたらどこがボトルネックになるのか（前編：LateUpdateとJob System）

Tue, 31 Mar 2026 17:31:45 +0900

最近、DOTS（Data-Oriented Tech Stack）が実際どのくらい効果があるのか気になっていたので、
簡単な検証を兼ねて触ってみることにしました。

せっかくなので「大量のオブジェクトを動かした場合にどこがボトルネックになるのか？」も含めて、
段階的に確認していこうと思います。

この記事ではまず、LateUpdateでの回転処理のボトルネックと、
Job Systemによる最適化の効果にフォーカスします。

レンダリング周り（CullingやDrawCall）については、次回以降で触れる予定です。

■ 検証環境

CPU：i7-12700K
GPU：RTX 3070
Unity：URPの新規プロジェクト
オブジェクト数：10万（Cube）

■ テスト内容

シンプルに「10万個のCubeを生成して回転させるだけ」です。

BoxColliderは削除
ランダム位置に配置

各オブジェクトにランダムな回転軸

void Start() { var root = new GameObject(“CubeRoot”).transform;

for (int i = 0; i < spawnCount; i++)
{
var go = Instantiate(prefab, Random.insideUnitSphere * 50f, Quaternion.identity, root);
transforms.Add(go.transform);
}

}

void LateUpdate() { float dt = Time.deltaTime;

for (int i = 0; i < transforms.Count; i++)
{
transforms[i].Rotate(rotationAxes[i], 100f * dt);
}

}

🙌 なぜ Unity は C# を選び、Unreal は選ばなかったのかについての個人の考察

Wed, 11 Mar 2026 19:31:51 +0900

はじめに

ゲームエンジンの言語の話になると、よくこんな対比が出てきます。

Unity は C#。
Unreal は C++ と Blueprint。

この違い、ただの好みではありません。
エンジンの設計思想そのものに関わっています。

C# が優れているとか、C++ が古いとか、そういう単純な話ではない。
両者はそもそも目指している開発体験が違うのです。

Unity が辿った言語統一の歴史

今でこそ「Unity といえば C#」という印象がありますが、最初からそうだったわけではありません。
初期の Unity では、開発者のバックグラウンドに合わせて複数の言語を選択できるのが特徴でした。

具体的には次の3つです。

C#
UnityScript （JavaScript 風の独自言語）
Boo （Python 風の言語）

当時の Unity は「スクリプト言語の自由度」を売りの一つにしており、Web 開発者は UnityScript、Python 系に慣れている人は Boo、という具合に選べるようになっていました。

しかし、この方針は長くは続きませんでした。

Unity 2017 頃から段階的に非推奨となり、
Unity 2019.1 を最後に UnityScript と Boo は完全に削除 されます。

結果として、Unity のスクリプト言語は C# のみ に統一されました。

参考
https://discussions.unity.com/t/which-release-removed-support-unityscript-and-boo/1624299

なぜこうなったのか。理由はいくつかあります。

まず、複数言語の維持コストです。
エンジン側はコンパイラ、ツールチェーン、デバッグ環境などをすべてサポートし続ける必要があります。

さらに重要なのは、UnityScript と Boo の実態です。
これらは見た目こそ別言語でしたが、内部では Mono 上で動作するスクリプトでした。

☝️ デバッグ UI を書かずに Unity のデバッグ環境を成立させる設計と実装

Wed, 18 Feb 2026 13:18:23 +0900

はじめに

Unity で開発していると、
実行中にパラメータを触りながら挙動を確認したい
という場面は、ほぼ毎日のように出てきます。

最初のうちは、Unity 標準の仕組みを使って
簡単な Runtime Debug UI を用意すれば十分でした。

ただ、プロジェクトが進み、

デバッグ項目が増える
調整対象が増える
複数人で同時に触る

という状況になるにつれ、
「その場しのぎ」で作ったデバッグ UI が、確実に足を引っ張る
ようになってきます。

この段階で欲しくなったのが、

でした。

この記事では、
そのために設計した 自作 Runtime Debug システム について、
設計意図と実装の要点 を中心にまとめます。

何が問題だったのか

問題の本質は、「UI をどう実装するか」 ではありませんでした。

本当に困っていたのは、

Debug 項目の追加・削除が面倒
どこに何のデバッグ設定があるのか分からない
不要になった項目が整理されず、蓄積していく

という 運用面の破綻 です。

特に後半になると、

という、本末転倒な状態になりがちでした。

目指したゴール

今回の設計で目指したゴールは、かなり明確です。

UI を書かずに Debug 項目を追加できる
構造が自然に整理され続ける
無効化・除去が簡単
プロジェクト規模が大きくなっても破綻しない

つまり、

を最優先にしました。

全体構成

全体の流れは、次のようになります。

起動
↓
RuntimeInitializeOnLoadMethod
↓
DebugManager 自動生成
↓
DebugOption 自動登録
↓
Reflection による項目収集
↓
UI 自動生成 & バインディング

ここで重視したのは、

🧠 AndroidビルドでPlayFabのSecretKeyが丸見えだった話と、ビルド時に自動変換する対策

Thu, 05 Feb 2026 14:15:44 +0900

はじめに

PlayFab を使ったプロジェクトで、
TitleId や DeveloperSecretKey をどう管理するかは、最初に一度は悩むポイントだと思います。

自分も最初は深く考えずに、

const string TitleId = "XXXX";
const string DeveloperSecretKey = "YYYY";

のようにコードに直接書いていました。

ところが Android ビルド後に apk を確認してみると、
strings コマンドで 平文のままキーが抜ける ことに気づき、
「これはさすがにまずいな……」となったのが今回のきっかけです。

問題点：apk 内に平文で残る

C# のコードに直接書いた文字列は、

IL2CPP でも
難読化をしていても

最終的に 文字列リテラルとして apk 内に残ります 。

つまり、

strings app.apk

を叩くだけで、TitleId や SecretKey が見えてしまう状態でした。

もちろん「完全に隠す」ことは不可能ですが、
平文で置いておくのはリスクが高すぎる と判断しました。

方針：コードには平文を置かない

今回の方針はシンプルです。

ソースコード内に 平文のキーを一切書かない
ビルド時に Editor 側で変換・生成する
ランタイムでは最小限の復号処理だけ行う

いわゆる「秘匿」というより、
apk を覗かれたときに即バレしない状態を作る のが目的です。

実装概要

実装は以下の流れにしました。

Editor フォルダ内

🐈 UnityのEditor拡張で「設定の保存先」に毎回悩む話

Mon, 02 Feb 2026 17:57:13 +0900

Unity でエディタ拡張を書いていると、
「この設定、どこに保存するのが正解なんだろう？」
と悩む場面がよくあります。

そのときにまず候補に上がるのが EditorPrefs です。

bool isOpen = EditorPrefs.GetBool("MyTool_Foldout", false);

とても手軽で便利ですが、使い方を間違えると
チーム開発では地味に事故りやすい API でもあります。

この記事では、

EditorPrefs は何のための仕組みなのか
どんな用途に向いているのか
逆に使ってはいけないケース

を整理してみます。

EditorPrefs とは何か

EditorPrefs は、Unity エディタ専用の設定保存機構 です。

プロジェクト単位ではない
ユーザー（マシン）単位で保存される
バージョン管理の対象外

という特徴があります。

つまり、

を保存するためのものです。

保存場所はどこ？

EditorPrefs の中身は、OS ごとに以下の場所に保存されます。

Windows：レジストリ
macOS：~/Library/Preferences
Linux：~/.config

この時点で分かる通り、
Git にも SVN にも乗りません 。

向いているユースケース

1. エディタ UI の表示状態

例えば、

ツールウィンドウの開閉状態
折りたたみ（Foldout）の ON / OFF
最後に選択していたタブ

こういった「見た目の状態」は、EditorPrefs と非常に相性が良いです。

bool isOpen = EditorPrefs.GetBool("MyTool_Foldout", false);

💡 【Unity UGUI】Maskを使わずに実現する「穴あき」ハイライト演出

Mon, 20 Oct 2025 19:24:18 +0900

はじめに

UGUIで部分的にハイライトを当てたい場面、特にチュートリアル中の誘導UI では「特定のボタンだけを明るく見せ、他の部分を半透明で覆う」演出がよく使われます。
一般的には Mask や RectMask2D を利用しますが、これらにはいくつかの課題があります。

Mask ：Stencilバッファを使うため、描画コストが高い
RectMask2D ：矩形領域しか扱えず、穴あき表現（逆マスク） はできない

そこで今回は、MaskableGraphic を継承し、完全プログラム制御で「逆マスク（穴あきマスク）」を生成する方法 を紹介します。
最終的には、ハイライト部分がクリック可能で、他の部分はブロックされる 、高性能な HollowOutMask コンポーネントを実装していきます。

目標仕様

機能	説明
視覚効果	自身の `RectTransform` 領域内に半透明のマスクを描画し、指定の `RectTransform` 部分を「くり抜く」
射線処理	穴の部分はクリックが通過し、マスク部分はクリックをブロック
動的追従	対象オブジェクトが動いたりスケールが変化しても、くり抜き領域が追従

これを、Mask 系コンポーネントを使わずに、頂点操作 だけで実現します。

実装の基本構造

HollowOutMask は MaskableGraphic を継承し、OnPopulateMesh() をオーバーライドします。

頂点生成の考え方

想像してみてください。
マスク全体を表す「外側の矩形（Outer Rect）」と、くり抜く「内側の矩形（Inner Rect）」があるとします。

この２つの矩形を組み合わせ、外側を塗りつつ内側を抜くには、8つの頂点 と8枚の三角形 が必要です。

コード例：OnPopulateMesh()

protected override void OnPopulateMesh(VertexHelper vh)
{
vh.Clear();
if (_isTargetNull)
{
base.OnPopulateMesh(vh);
return;
}
// Outer Rect（自身のRectTransform基準）
float outerLx = rectTransform.rect.xMin;
float outerBy = rectTransform.rect.yMin;
float outerRx = rectTransform.rect.xMax;
float outerTy = rectTransform.rect.yMax;
vh.AddVert(new Vector3(outerLx, outerTy), color, Vector2.zero);
vh.AddVert(new Vector3(outerRx, outerTy), color, Vector2.zero);
vh.AddVert(new Vector3(outerRx, outerBy), color, Vector2.zero);
vh.AddVert(new Vector3(outerLx, outerBy), color, Vector2.zero);
// Inner Rect（穴部分）
float innerLx = _targetMin.x;
float innerBy = _targetMin.y;
float innerRx = _targetMax.x;
float innerTy = _targetMax.y;
vh.AddVert(new Vector3(innerLx, innerTy), color, Vector2.zero);
vh.AddVert(new Vector3(innerRx, innerTy), color, Vector2.zero);
vh.AddVert(new Vector3(innerRx, innerBy), color, Vector2.zero);
vh.AddVert(new Vector3(innerLx, innerBy), color, Vector2.zero);
// Triangles（外側と内側の間を埋める）
vh.AddTriangle(0, 1, 5); vh.AddTriangle(5, 4, 0);
vh.AddTriangle(1, 2, 6); vh.AddTriangle(6, 5, 1);
vh.AddTriangle(2, 3, 7); vh.AddTriangle(7, 6, 2);
vh.AddTriangle(3, 0, 4); vh.AddTriangle(4, 7, 3);
}

これで、中央が透明な「リング状ポリゴン を生成できます。

📚 UI開発を10倍速くするための実戦ポイント

Thu, 09 Oct 2025 12:11:28 +0900

はじめに

多くの人は「UI開発＝手の速さ」だと思っています。
でも実際のプロジェクトでは、進行を遅らせる原因はコードの速さではなく、データフローとUI構造設計の悪さ です。

Unity（UGUI）で時間を食う典型的なポイントを挙げると、以下のようになります。

データ前処理がバラバラ ：ソートやフィルタが各UIに散らばっていると、UI層が処理待ちになる。
階層構造が深すぎる ：1回の更新で大量のTransformを走査、処理も重くバグも出やすい。
アニメーション・状態管理が未抽象化 ：新しい状態を追加するたびにコードを壊す。

同じランキングUIでも、ある人は半日で完成、ある人は3日かかる。
その差は、手の速さではなく設計の差 です。

データ層とUI層を明確に分離する

ありがちなアンチパターンは、OnClick() の中で
データ取得 → オブジェクト生成 → UI更新を全部やるケース。

短期的には動いても、UI改修のたびに全部作り直しになります。

もっと良い設計はこうです👇

DataService / Manager にデータロジックをまとめる
UI は DTO（Data Transfer Object） を受け取って表示専念
データ前処理は Python や外部ツールで事前に済ませる

こうすると要件変更が来ても、UI側はほとんど触らずに済みます。
データ層が変わってもUIは安定、これが真の開発効率化です。

リスト描画は「オブジェクトプール」が必須

ランキング、インベントリ、スキルリストなど、
毎回 Instantiate ＋ Destroy していると、
処理が重くなるだけでなく、開発時間も無駄に増えます。

対策：

オブジェクトプールを構築する ：
再利用可能なUI要素をキャッシュして、再描画時はデータだけ差し替え。
シンプルな PoolManager でOK ：
使い終わった要素は SetActive(false) して再利用。
ScrollRect の仮想化レンダリングと併用 ：
数千件でも軽く動作。

あるプロジェクトでは、インベントリUIの描画時間が
500セルで200ms → プール導入後は30msに短縮。
体感で「カクつき」が消えました。

🔥 ゲームプログラマーとして成長するために大切な3つの力

Thu, 18 Sep 2025 16:43:12 +0900

はじめに

「どうすればプログラミングが上手くなるのか？」
これは、ゲーム業界を目指すエンジニアにとって、常につきまとうテーマです。

Unity や Unreal Engine などの便利なエンジンやライブラリが整っている時代でも、「本当にゲームを作れる」プログラマーになるためには、言語やフレームワークの知識以上に重要な根本的スキル があります。

本記事では、ゲームプログラマーとして実務を経験する中で特に大事だと感じる3つの力 を紹介します。

① 抽象化の力 —— 巨大なコードを「分けて」考える

ゲーム開発は、数千〜数百万行にもなるコードの集合です。
その全てを頭に入れることは不可能なので、必要な部分だけをブラックボックスとして扱う 考え方が必須になります。

例えば、「プレイヤーが持つ全ての武器を取得する」処理を作る場合を考えます。

// Repositoryパターンによる例
class WeaponRepository {
public List<Weapon> GetAllWeapons(PlayerId playerId);
}

この WeaponRepository クラスを作るときは、

DBやセーブデータへのアクセス
ログやエラーハンドリング
フォーマット変換
など、たくさんの下位レイヤのライブラリを呼び出しますが、上のレイヤからは「GetAllWeapons」だけ見えればよい のです。

これが抽象化であり、モジュールを積み重ねて大規模ゲームを成立させる基本 です。

実戦ポイント

オブジェクト指向（OOP）、関数型（FP）、手続き型といった 複数のパラダイムを状況に応じて使い分ける
トップダウン（設計から実装）とボトムアップ（共通処理の抽出）を行き来しながら開発する
抽象化しすぎると開発が重くなり、抽象化しなさすぎるとコピペ地獄になるため、バランスを取る

② デバッグの力 —— ブラックボックスを「開ける」技術

抽象化したコードは便利ですが、バグが起きたときには中を開ける必要 があります。

たとえば「インベントリ画面に武器一覧が表示されない」と報告されたとき、どこから原因を追うべきでしょうか？

F12（DevTools）や curl でクライアント→サーバ間通信を確認
サーバで WeaponRepository.GetAllWeapons() の戻り値をログ出力
DBにクエリを直打ちして期待通りの結果か確認

こうして層を一つずつ下って調査 するのがデバッグの基本です。
このスキルはバグ修正だけでなく、新しいプロジェクトやチームに参加したときにコードを理解する力 にもなります。

実戦ポイント

ログやアサートを常に入れておく
デバッガでステップ実行できるように設計する
バグ報告を「再現可能な条件」に落とし込む

💨 Fusionの[Networked]属性はどう動いている？IL変換と自動同期の仕組みを解剖する

Wed, 04 Jun 2025 19:50:30 +0900

はじめに

Photon Fusionは、高性能・高柔軟性なネットワーク同期システムを提供する次世代ネットワークライブラリです。
その中でも特に重要な役割を担っているのが、[Networked] 属性です。

この属性を使うことで、プレイヤーの位置やアニメーション状態、ゲーム内オブジェクトの変化 などを自動的に同期でき、煩雑な手動のデータ送受信処理を省くことができます。

本シリーズでは、Fusionの内部同期処理を段階的に掘り下げて解説していきますが、今回は、[Networked] 属性の裏側で何が起きているのか、どのようにして自動同期が実現されているのかを詳しく見ていきます。

Fusionにおける[Networked]属性の同期処理概要

`[Networked]` 属性は？

Fusionでは、[Networked] 属性が付与されたプロパティはネットワーク状態の同期対象 として扱われますが、ユーザーが手動で同期コードを書く必要はありません。
この仕組みは、Unityが提供する ILPostProcessor API を活用しており、C# で書かれたコードをビルド後にIL（中間言語）レベルで自動変換 しています。

ILは、.NET における中間言語です。
Unity では、C# で書いたスクリプトは必ずこの IL を経由してからネイティブコードに変換されます。

具体的には、以下のような処理が行われます：

NetworkedWeaved という属性を追加して、該当プロパティがネットワーク状態バッファに割り当てられることを明示
getter/setter が NetworkBehaviour の内部バッファ（StateBuffer）へのメモリアクセスに差し替え られる
実行時に Spawned() されていない場合のアクセス制限も挿入される

変換前のC#コード：

 [Networked] private Vector2 _position { get; set; }

IL変換後（ILSpyで逆コンパイルしたコード）：

    [Networked]
    [NetworkedWeaved(0, 2)]
    private unsafe Vector2 _position
    {
        get
        {
            if (base.Ptr == null)
            {
                throw new InvalidOperationException("Error when accessing PhotonCapybara._position. Networked properties can only be accessed when Spawned() has been called.");
            }
            return (Vector2)base.Ptr[0];
        }
        set
        {
            if (base.Ptr == null)
            {
                throw new InvalidOperationException("Error when accessing PhotonCapybara._position. Networked properties can only be accessed when Spawned() has been called.");
            }
            Unsafe.Write(base.Ptr + 0, value);
        }
    }

補足解説：

base.Ptr は NetworkBehaviour に割り当てられたネットワーク状態メモリの先頭ポインタ です。

Unity on Wuyukwi's Notebook

☝️ 「汎用化したい」という衝動と、開発の現実

汎用化したくなるのは、実はかなり自然なこと

実際、汎用化にはかなり強いメリットがある

1. 「依存」に敏感になる

🧊 【Unity】10万オブジェクトを回転させたらどこがボトルネックになるのか（後編：ISystemで一桁msへ）

はじめに

なぜJob Systemだけでは不十分だったのか

■ 結果

■ 比較

■ Profilerを見ると何が起きているか

🧊 【Unity】10万オブジェクトを回転させたらどこがボトルネックになるのか（前編：LateUpdateとJob System）

■ 検証環境

■ テスト内容

🙌 なぜ Unity は C# を選び、Unreal は選ばなかったのかについての個人の考察

はじめに

Unity が辿った言語統一の歴史

☝️ デバッグ UI を書かずに Unity のデバッグ環境を成立させる設計と実装

はじめに

何が問題だったのか

目指したゴール

全体構成

🧠 AndroidビルドでPlayFabのSecretKeyが丸見えだった話と、ビルド時に自動変換する対策

はじめに

問題点：apk 内に平文で残る

方針：コードには平文を置かない

実装概要

🐈 UnityのEditor拡張で「設定の保存先」に毎回悩む話

EditorPrefs とは何か

保存場所はどこ？

向いているユースケース

1. エディタ UI の表示状態

💡 【Unity UGUI】Maskを使わずに実現する「穴あき」ハイライト演出

はじめに

目標仕様

実装の基本構造

頂点生成の考え方

コード例：OnPopulateMesh()

📚 UI開発を10倍速くするための実戦ポイント

はじめに

データ層とUI層を明確に分離する

リスト描画は「オブジェクトプール」が必須

対策：

🔥 ゲームプログラマーとして成長するために大切な3つの力

はじめに

① 抽象化の力 —— 巨大なコードを「分けて」考える

実戦ポイント

② デバッグの力 —— ブラックボックスを「開ける」技術

💨 Fusionの[Networked]属性はどう動いている？IL変換と自動同期の仕組みを解剖する

はじめに

Fusionにおける[Networked]属性の同期処理概要

[Networked] 属性は？

変換前のC#コード：

IL変換後（ILSpyで逆コンパイルしたコード）：

補足解説：

`[Networked]` 属性は？