Merge branch 'develop'

Author: BreadMotion

WebSite/blog/blog_00001.html

@@ -81,9 +81,9 @@ <h1 class="post-detail__title">ブログはじめました</h1>
 <h2>自己紹介</h2>
 <p>こんにちは、パン君です。</p>
 <p>私はとあるゲーム会社で働きながら、インディーズや個人制作でも活動しているゲームエンジニアです。</p>
-<p>社会人2年目ということもあり、インディーズやプライベートで制作した作品などを整理して、今後の活動に役立つような「まとめの場所」が欲しいと思い、このサイトを作りました。</p>
-<p>本当はサーバーを借りたり、常駐用のミニPCを用意して1から環境構築して……という方法も考えましたが、まずは <strong>「早く出す」ことを優先</strong> して、今回は GitHub Pages を使っています。</p>
-<p>ページのクオリティは自分次第なので、今後もいろいろ調べながらブラッシュアップしていく予定です。<br>その過程も含めて、このサイトを通じて成長していけたらいいなと思っています。</p>
+<p>社会人2年目ということもあり、インディーズやプライベートで制作した作品などを整理して<br>今後の活動に役立つような「まとめの場所」が欲しいと思いこのサイトを作りました。</p>
+<p>本当はサーバーを借りたり、常駐用のミニPCを用意して1から環境構築して……という方法も考えましたが、<br>まずは <strong>「早く出す」ことを優先</strong> して、今回は GitHub Pages を使っています。  </p>
+<p>ページのクオリティは自分次第なので、今後もいろいろ調べながらブラッシュアップしていく予定です。<br>その過程も含めて、このサイトを通じて成長していけたらいいなと思っています。  </p>
 <hr>
 <h2>やりたいこと</h2>
 <p>このサイトの大きな目標は下記のとおりです。</p>
@@ -96,9 +96,8 @@ <h2>やりたいこと</h2>
 <li>作成したプロジェクトの詳しい機能紹介</li>
 <li>個人で作ったツールや仕組みの解説</li>
 </ul>
-<p>といった内容をまとめておき、
-<strong>ポートフォリオの補足資料</strong> としても使えるようにしたい、という思いがあります。</p>
-<p>ブログの記事自体も、長い目で見れば <strong>スキルと実績を示すポートフォリオの一部</strong> になるので、<br>「これはお得だな」と感じて始めました。</p>
+<p>といった内容をまとめておき、<br><strong>ポートフォリオの補足資料</strong> としても使えるようにしたい、という思いがあります。  </p>
+<p>ブログの記事自体も、長い目で見れば <strong>スキルと実績を示すポートフォリオの一部</strong> になるので、<br>「これはお得だな」と感じて始めました。  </p>
 <hr>
 <h2>このサイトの構成イメージ</h2>
 <p>現時点で想定している構成はこんな感じです。</p>

WebSite/blog/blog_00002.html

@@ -79,7 +79,7 @@ <h1 class="post-detail__title">Odin を導入してみた</h1>
 
           <section class="post-detail__body markdown-body">
 <p>こんにちは！パン君です。</p>
-<p>今回は、インディーズのプロジェクトで <strong>Odin Inspector</strong> を導入した際に起きたトラブルと、そのときに行った対処についてまとめます。</p>
+<p>今回はインディーズのプロジェクトで <strong>Odin Inspector</strong> を導入した際に起きたトラブルと、そのときに行った対処についてまとめます。</p>
 <p>ざっくり言うと、</p>
 <ul>
 <li><strong>Odin 関連の <code>.meta</code> ファイルに差分が出る</strong></li>
@@ -198,72 +198,65 @@ <h3>手順 2: Odin および Test Framework の状態確認</h3>
 <h3>手順 3: <code>.meta</code> 差分の整理</h3>
 <p>Odin 関係の <code>.meta</code> ファイルで差分が出ている場合は、</p>
 <ul>
-<li><p>まずはリポジトリ側に <strong>正しい状態の Odin + meta をコミット</strong></p>
-</li>
-<li><p>その後、他メンバーには</p>
-<pre><code class="language-text">1. 作業ブランチでローカル変更を避難する（stash or commit）
-2. 最新ブランチに同期
-3. Library を削除
-4. Unity 再起動後、Odin 関係の .meta 差分が出るか確認
+<li>まずはリポジトリ側に <strong>正しい状態の Odin + meta をコミット</strong></li>
+<li>その後、他メンバーには</li>
+</ul>
+<pre><code class="language-text">  1. 作業ブランチでローカル変更を避難する（stash or commit）
+  2. 最新ブランチに同期
+  3. Library を削除
+  4. Unity 再起動後、Odin 関係の .meta 差分が出るか確認
 </code></pre>
+<p>という流れで動いてもらいました。
+　
+「動いている環境」をいったん正としてリポジトリに固め、それ以外の環境を合わせにいく<br>という考え方です。</p>
+<h2>チームで Odin を導入するときの運用ルール</h2>
+<p>今回のトラブルを踏まえて、次のプロジェクト以降で気をつけようと思ったポイントをまとめておきます。  </p>
+<h3>1. 導入前に「担当者」を決める</h3>
+<ul>
+<li>Odin のバージョン選定</li>
+<li>プロジェクトへのインポート</li>
+<li>初回コミット</li>
+</ul>
+<p>ここは <strong>1人の担当者がまとめてやる</strong> 方が事故りにくいです。</p>
+<p>中途半端な状態で複数人がそれぞれインポートすると、<br>.meta や manifest.json がぐちゃっとなりやすいです。  </p>
+<h3>2. Unity / Odin / Test Framework の「想定バージョン」を明文化する</h3>
+<ul>
+<li>プロジェクト開始時に<ul>
+<li>Unity バージョン</li>
+<li>Odin バージョン</li>
+<li>Test Framework バージョン
+を、どこかドキュメントに書いておく<br>後から参加してくるメンバーにも、「これに合わせてください」と案内するだけで済むようになります。</li>
+</ul>
 </li>
 </ul>
-<pre><code>
-という流れで動いてもらいました。
-　
-「動いている環境」をいったん正としてリポジトリに固め、それ以外の環境を合わせにいく
-という考え方です。
-
-## チームで Odin を導入するときの運用ルール
-
-今回のトラブルを踏まえて、次のプロジェクト以降で気をつけようと思ったポイントをまとめておきます。
-
-### 1. 導入前に「担当者」を決める
-
-- Odin のバージョン選定
-- プロジェクトへのインポート
-- 初回コミット
-
-ここは **1人の担当者がまとめてやる** 方が事故りにくいです。
-
-中途半端な状態で複数人がそれぞれインポートすると、
-.meta や manifest.json がぐちゃっとなりやすいです。
-
-### 2. Unity / Odin / Test Framework の「想定バージョン」を明文化する
-
-- プロジェクト開始時に
-  - Unity バージョン
-  - Odin バージョン
-  - Test Framework バージョン
-を、どこかドキュメントに書いておく
-後から参加してくるメンバーにも、「これに合わせてください」と案内するだけで済むようになります。
-
-### 3. 初回セットアップ手順を README に書いておく
-
-今回やったような、
-- git clone / git pull 後にやること
-  - Library 削除
-  - Unity 再起動
-- うまく起動しなかったときの確認ポイント
-  - Odin / Test Framework の状態確認
-  - Safe Mode になったときはログを添付して報告してもらう
-といった内容を、簡単な手順書にしておくだけでトラブル時のコミュニケーションコストがかなり下がります。
-
-## まとめ
-
-今回の Odin 導入で学んだことをまとめると、こんな感じです。
-
-- Odin 自体は便利だが、チーム導入時には「Unity / Test Framework / meta ファイル」の差異で事故りやすい
-- 「動いている環境」を 1 つ決めて、そこから
-  - Odin + Test Framework の状態をコミット
-  - 他メンバーの環境をその状態に寄せていくという方針がやりやすい
-- 導入時の手順や想定バージョンを **事前に軽くドキュメント化** しておくだけでも、だいぶ安全になる
-
-Odin はカスタムインスペクターやエディタ拡張まわりでかなり強力なツールなので、
-一度チームで安定して導入できる形が作れると、**次以降のプロジェクトがかなり楽**になります。
-
-今後は、実際にどんな機能を Odin で作っているか（属性ベースの Editor 拡張や、Data 管理の工夫など）も、別の記事で書いていければと思います。
-</code></pre>
+<h3>3. 初回セットアップ手順を README に書いておく</h3>
+<p>今回やったような、</p>
+<ul>
+<li>git clone / git pull 後にやること<ul>
+<li>Library 削除</li>
+<li>Unity 再起動</li>
+</ul>
+</li>
+<li>うまく起動しなかったときの確認ポイント<ul>
+<li>Odin / Test Framework の状態確認</li>
+<li>Safe Mode になったときはログを添付して報告してもらう</li>
+</ul>
+</li>
+</ul>
+<p>といった内容を、簡単な手順書にしておくだけでトラブル時のコミュニケーションコストがかなり下がります。</p>
+<h2>まとめ</h2>
+<p>今回の Odin 導入で学んだことをまとめると、こんな感じです。</p>
+<ul>
+<li>Odin 自体は便利だが、チーム導入時には「Unity / Test Framework / meta ファイル」の差異で事故りやすい</li>
+<li>「動いている環境」を 1 つ決めて、そこから<ul>
+<li>Odin + Test Framework の状態をコミット</li>
+<li>他メンバーの環境をその状態に寄せていくという方針がやりやすい</li>
+</ul>
+</li>
+<li>導入時の手順や想定バージョンを <strong>事前に軽くドキュメント化</strong> しておくだけでも、だいぶ安全になる</li>
+</ul>
+<p>Odin はカスタムインスペクターやエディタ拡張まわりでかなり強力なツールなので、<br>一度チームで安定して導入できる形が作れると、 <strong>次以降のプロジェクトがかなり楽</strong> になります。</p>
+<p>今後は実際にどんな機能を Odin で作っているか（属性ベースの Editor 拡張や、Data 管理の工夫など）も、<br>別の記事で書いていければと思います。</p>
 
           </section>
 

WebSite/blog/blog_00003.html

@@ -199,16 +199,16 @@ <h3>1. ベースとなる Window クラス</h3>
 <p>ウィンドウを開くだけで</p>
 <ul>
 <li>指定したScriptableObjectの中身が <strong>同じ画面</strong> に展開される</li>
-<li>その場で値を編集、ほぞんが　反映される
-という状態にできます。</li>
+<li>その場で値を編集、ほぞんが　反映される</li>
 </ul>
+<p>という状態にできます。</p>
 <h3>2. ScriptableObject側の設計</h3>
 <p>もともとのデータ構造をScriptableObject化しておけば</p>
 <ul>
 <li>プロジェクト全体では通常通りScriptableObjectとして利用</li>
-<li>編集時だけコンテキストエディターのウィンドウからアクセス
-という二重の使い方ができます。</li>
+<li>編集時だけコンテキストエディターのウィンドウからアクセス</li>
 </ul>
+<p>という二重の使い方ができます。</p>
 <p>例えば :</p>
 <pre><code class="language-csharp">[CreateAssetMenu(menuName = &quot;Game/Event&quot;)]
 public class EventConfig : ScriptableObject
@@ -226,17 +226,16 @@ <h3>2. ScriptableObject側の設計</h3>
     public bool isEnabled;
 }
 </code></pre>
-<p>これを先ほどのContextEditorWindowのフィールドとして参照しておけば、
-ウィンドウ側でInlineEditorしたときに、 <strong>Odinのデコレーション込みで表示されます</strong> 。</p>
+<p>これを先ほどのContextEditorWindowのフィールドとして参照しておけば、<br>ウィンドウ側でInlineEditorしたときに、 <strong>Odinのデコレーション込みで表示されます</strong> 。</p>
 <h3>3. ちょっとしたUX改善</h3>
 <p>例：</p>
 <ul>
 <li>「選択中のステージだけテストシーンを起動する」ボタン</li>
 <li>「報酬テーブルをデフォルト値で初期化する」ボタン</li>
-<li>「特定 ID のデータを検索してフォーカス」ボタン
-Odin の Button 属性を使えば、EditorWindow 内にメソッドをそのままボタンとして出せるので、
-ちょっとしたツール感を簡単に足せます</li>
+<li>「特定 ID のデータを検索してフォーカス」ボタン</li>
 </ul>
+<p>Odin の Button 属性を使えば、EditorWindow 内にメソッドをそのままボタンとして出せるので、
+ちょっとしたツール感を簡単に足せます</p>
 <h2>実際に運用してみて</h2>
 <p>実際にプランナーに使ってもらって感じたメリットはこんな感じでした。</p>
 <ul>
@@ -259,9 +258,7 @@ <h2>最後に</h2>
 <li>「プロジェクト専用の編集画面」をサクッと用意したいとき</li>
 </ul>
 <p>にかなり相性がいいと感じました。</p>
-<p>Inspector 拡張だけでは足りないけれど、EditorWindow をフルスクラッチするのは大変
-というケースでは、Odin の属性と EditorWindow を組み合わせるだけで、
-「ちょうどいいライン」のツールが作りやすいです。</p>
+<p>Inspector 拡張だけでは足りないけれど、EditorWindow をフルスクラッチするのは大変<br>というケースでは、Odin の属性と EditorWindow を組み合わせるだけで、<br>「ちょうどいいライン」のツールが作りやすいです。  </p>
 <p>今後は、</p>
 <ul>
 <li>もう少し UI/UX を整理したバージョン</li>