diff --git a/my-blog/content/posts/2025-09-22-ue-mac.md b/my-blog/content/posts/2025-09-22-ue-mac.md
new file mode 100644
index 0000000..f931eef
--- /dev/null
+++ b/my-blog/content/posts/2025-09-22-ue-mac.md
@@ -0,0 +1,267 @@
+---
+title: "ue + vrm4u + mac/ios"
+slug: "ue-mac"
+date: "2025-09-22"
+tags: ["ue", "mac"]
+draft: false
+---
+
+# ue mac/ios support
+
+## ue for mac
+
+現時点でのxcode26には対応していません。ueを起動する際はxcodeを切り替えます。そうではないとbuild optionが機能しません。(クエリ中になる)
+
+appleの方針で製品のversionは年号になりました。
+
+> ex: mac26, ios26
+
+```sh
+xcode-ue () {
+        disk=hdd
+        case $1 in
+                (u | ue) d=/Volumes/${disk}/Xcode.app/Contents/Developer  ;;
+                (*) d=/Applications/Xcode.app/Contents/Developer  ;;
+        esac
+        sudo xcode-select --reset
+        sudo xcode-select --switch $d
+}
+```
+
+ここでは、`/Volumes/${disk}/Xcode.app`をxocde16とします。
+
+buildすると`/$Project/Mac/${Project}.xcarchive`ができます。
+
+```sh
+# Finderでアーカイブを右クリック → "Show in Finder"
+# .xcarchive を右クリック → "Show Package Contents"
+# ./Products/Applications/ai.app をダブルクリック
+```
+
+```sh
+# ターミナルでTeam IDを確認
+$ security find-identity -v -p codesigning
+```
+
+## vrm4u for mac
+
+まずc++のprojectをueで作成します。
+
+`libassimp.a`を生成します。
+
+https://github.com/ruyo/assimp
+
+これを`/Plugins/VRM4U/ThirdParty/assimp/lib/Mac/libassimp.a`に置いて、projectで開きます。pluginがbuildされますが、`/Plugins/VRM4U/Binaries/Mac/*`が生成され、これを使うことになります。
+
+```sh
+/Plugins/VRM4U/
+├── Binaries
+│   ├── Mac
+│   │   ├── UnrealEditor-VRM4U.dylib
+│   │   ├── UnrealEditor-VRM4UCapture.dylib
+│   │   ├── UnrealEditor-VRM4UCaptureEditor.dylib
+│   │   ├── UnrealEditor-VRM4UEditor.dylib
+│   │   ├── UnrealEditor-VRM4UImporter.dylib
+│   │   ├── UnrealEditor-VRM4ULoader.dylib
+│   │   ├── UnrealEditor-VRM4UMisc.dylib
+│   │   ├── UnrealEditor-VRM4URender.dylib
+│   │   └── UnrealEditor.modules
+├── ThirdParty
+│   ├── assimp
+│   │   ├── lib
+│   │   │   ├── Mac/libassimp.a #このファイル
+└── VRM4U.uplugin
+```
+
+他のprojectで利用する際は`/Binaries`, `/ThirdParty`をcopyすればいいので、取っておいてください。vrm4uが更新されたときは再びprojectでbuildしたほうがいいですね。
+
+## ue for git
+
+mac/iosでもbuildできるようにすること、そういったprojectを作成することを目指します。
+
+最終的にiosでもプレイできるゲームを作りたいなと思っていて、これは単純なカードを集め、キャラを強化するゲームにしようと考えています。
+
+mac/iosは軽量パッケージとして必要最小限の構成で作る予定です。特に重いworld systemを分離、統合が簡単にできるようにする予定です。
+
+そこで、winにはrsyncがありませんので、gitを使用することにしました。
+
+```sh
+$ winget install git.git
+$ cd ${project}
+$ git pull
+```
+
+署名も機能させておきたいので、gpgを使います。commit, pushすると`verify`が付くやつです。
+
+```sh
+$ winget install gnupg.gnupg
+$ which gpg
+$ git config --global gpg.program "C:\Program Files (x86)\gnupg\bin\gpg.exe"
+```
+
+現在使っているterminalは作成(パスフレーズ)が動作しないようです。したがって、mac, linuxで作成してimportします。
+
+```sh
+$ gpg --full-generate-key
+XXX
+$ id=XXX
+$ gpg --export-secret-keys ${id} > ~/gpg-key-win.asc
+---
+$ gpg --import C:\Users\${USER}\gpg-key-win.asc
+$ rm C:\Users\${USER}\gpg-key-win.asc
+$ gpg --edit-key ${id}
+trust
+5
+quit
+```
+
+作成したkeyはwinでimportした後はmac, linuxから削除したほうがいいかも。コマンドは書きません。
+
+これをgit-serverに登録しておけばいいでしょう。
+
+```sh
+$ gpg --armor --export ${id}
+```
+
+あと、`~/.gitconfig`も更新しておきます。
+
+```sh
+git config --global user.signingkey ${id}
+git config --global commit.gpgsign true
+```
+
+# Airse
+
+ゲームのタイトルは`Airse`に決まりました。まだ決まっていなかったのかというと、決まっていませんでした。仮名で作ってきましたが、これを機に根本的な部分を見直しました。
+
+- ai + verse
+- [A]irse = `unrealengine` naming rules
+
+## rse
+
+RSE = [R]elativistic [S]tellar [E]volution
+
+> ja: 相対論的恒星進化
+
+## name rule
+
+- app, name, project = Airse
+- repo, dir = `ai/rse`
+- id = `ai.syui.rse`
+
+file, variable, function, etc. follow the following name rules.
+
+1. use `_` to separate characters after abbreviations such as `CBP`.
+2. use `_` to separate characters before numbers.
+3. use capital letters for all other names, priority: `ue > repo`
+
+ex: `CBP_CharacterAiSkill_1`
+
+## game system
+
+`[ai, yui, at, world]`
+
+- AUTHOR = Syui
+- PROJECT = Airse
+
+```sh
+# example
+/Content/${AUTHOR}/${PROJECT}/
+├── World/           # world system
+│   ├── Origin/      # origin system (dream system)
+│   └── BGM/         # bgm system
+├── Yui/             # yui system  
+│   ├── Character/   # character system
+│   ├── Enemy/       # enemy system
+│   ├── Evolution/   # e system (evo system)
+│   ├── Voice/       # voice system
+│   └── Live/        # v system (live system)
+├── AI/              # ai system
+│   ├── Action/      # action system  
+│   └── Status/      # status system
+└── AT/              # at system
+    ├── Item/        # item system
+    ├── Card/        # card system
+    └── Save/        # save system
+```
+
+## bad ex
+
+1. `ai/airse` = `[ai] x 2`
+2. `syui/ai/rse` = `priority < ue`
+
+```md
+[fix]
+1. ai/airse -> ai/rse
+2. syui/ai/rse -> Syui/Airse
+```
+
+# 開発の方向性
+
+考えに変化があったので、お伝えします。大きなものは以下の2つです。
+
+1. ゲームの完成を目指すが、ちゃんとしたシステムを作ることも目指す
+2. 完璧に自信があるものでゲームを作る
+
+## ちゃんとしたシステムを作る
+
+ゲームの完成を目指して、色々と考えやってきましたが、ちゃんとしたシステムを作ることを優先したほうがいいと考えるようになりました。
+
+というのも、ちゃんとしたシステムを作っておけば、それを組み合わせるだけでいろんなゲームを作れるからです。
+
+ゲームを構成する要素、その基本というのは決まっていて、システムも決まっています。例えば、キャラクター操作。それさえ本当にレベルの高いシステムを自分で作れるなら、色々なゲームに応用できますよね。
+
+ゲームを完成させられることは素晴らしいことです。
+
+しかし、ゲーム制作をやめてしまうときはどんなときでしょう。ゲームを完成させるのは本当に大変で、そこに到達できる人は少ないのですが、しかし、到達できた人も、そこでやめてしまう人が多いんじゃないでしょうか。
+
+続けられる人はごく僅かで、大きな理由は2つあると思っています。
+
+一つは成功しなかったこと。続けるだけのメリットを感じられなかったことだと思います。
+
+2つ目は、作ってきたものがどうしようもなく再利用できない状態にあることだと思います。例えば、作ってきたものがシステム化されておらず、他のゲームを作ろうとしたときに利用できない形、ごちゃごちゃで自分にも把握できず、使い回せない、あるいは別のゲームに統合できない状態であること。
+
+そうでなければ、他のアイデアをすぐに試してみようとなりやすい、ゲーム開発のハードルは低くなっているはずです。にも関わらず、ちょっと辞めてしまう人がいます。
+
+それはなぜかというと、作ってきたものがゴチャゴチャで使い物にならなかったときじゃないかと思います。もちろん、本人の熱意とか継続性とか意思とかそういったものもあります。でも、心が折れそうな時にもコントロール可能な環境要因があるはずで、そうした環境を構築する能力も重要なのではないかと思うのです。周りにちゃんとしたシステムがたくさんある、そんな状態を作る、ということ。そういうのを目指していきたいと思い、ちゃんとしたシステムを作ることも優先的に考え始めました。
+
+## 自信があるものでゲームを構築する
+
+インディーズゲーム、特に3dは本当に難しい。私のゲーム開発の方針は、少しずつ決まってきて、注意しなければならないこともわかってきました。
+
+それは、無理をしないこと。無茶をしないと言い換えてもいいでしょう。
+
+しかし、この無茶をしないというのは表現が難しく、本人が無茶だと思っていなくても無茶に含まれることは多いと思います。
+
+例えば、個人が3dでゲームを作ることでしょう。
+
+「いやいや、そんな」と思われるかもしれませんが、細かいところを見ると、個人開発で3dをやるのは、結構な無茶だと今では思います。また、ueを使うこともそれに含まれるかもしれません。
+
+ueや3dを使うと、個人でも大きいものが作れた気になってしまう。広いマップ、リアルな描写、動く3dモデル。
+
+しかし、扱いきれない武器ほど怖いものはありません。初心者の個人開発にとって、それを置いていくほうがいい場合もある。だけどそれを手にとって進んでしまうのです。
+
+この場合、個人ができるのは、その武器に圧倒的な制限をつけ、使える場面を限定することだと思います。
+
+私も自分のゲームをプレイしていて、この部分はよくできているなというところが少しあります。しかし、総合的なゲーム性で考えると、全然ダメですね。
+
+でも、それなら本当によくできた自信がある部分だけでゲームを作ればいいんじゃないかな。
+
+そこには工夫が必要になるかもしれないし、コンセプトが重要になると思いますが、私はそのような結論に至ります。
+
+完璧に動作する部分、バグが少なく、自信があるところ、自分のゲームの最大の魅力、そこだけを使ってゲームを構築することを今は考えています。
+
+面白いかどうかは、正直わかりませんが、パッと見で、少しプレイして、「あれ、これすごいんじゃない」と思わせることができたら成功だと思います。最初はそこを目指していこうかなと。
+
+無理をしてできることを増やしても意味がありません。特に個人開発者で、3dで、かつueだと、それはとても危険な気がします。
+
+とはいえ、重要なのは、たくさん作ること。
+
+3dで開発するな、ueを使うな、開発者は好きなものを作るな、と言いたいわけではありません。
+
+言いたいのは、たくさん作作った中に光るもの、よくできたものがいくつか出てきます。そういったものを使ってゲームを構築する、その方向で考えること。
+
+おそらく、3dで作る場合、ueを使う場合、個人開発者が好きなものを作る場合に、このような制限は役に立つと思います。
+
+以上が、最近の個人開発の方向性、あるいは考え方の話です。
+