ue mac/ios support

• ue 5.6.1
• mac 26
• windows 11

ue for mac

現時点でのxcode26には対応していません。ueを起動する際はxcodeを切り替えます。そうではないとbuild optionが機能しません。(クエリ中になる)

appleの方針で製品のversionは年号になりました。

ex: mac26, ios26

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ができます。

# Finderでアーカイブを右クリック → "Show in Finder"
# .xcarchive を右クリック → "Show Package Contents"
# ./Products/Applications/ai.app をダブルクリック

# ターミナルでTeam IDを確認
$ security find-identity -v -p codesigning

ue for linux

linux版もbuildすることにしました。

• steam osはたしかlinuxだったはず
• ゲームとpixelstreamingをlinux serverで動かせれば楽

https://dev.epicgames.com/documentation/ja-jp/unreal-engine/linux-development-requirements-for-unreal-engine

必要なものをdownloadして、windows上で環境を整えます。clang 18.1.0

ue editorを開いてメニューのtool -> c++で何かを作ります。すると、.slnがproject rootにできます。できなければ、.uprojectを右クリックで.slnを作ります。

epic launcherでue installerのoption:linuxを再び有効にします。

.slnを開いてbuildにlinuxを選択し、右バーのMyProject(Airse)を右クリックでbuildします。pluginなどが対応していないときは.uprojectを開いてfalseに変更します。対応している場合もbuild errになることがあります。

wsl ubuntuなども必要になるかもしれませんが、情報にはありません。

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/*が生成され、これを使うことになります。

/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を使用することにしました。

$ winget install git.git
$ cd ${project}
$ git pull

署名も機能させておきたいので、gpgを使います。commit, pushするとverifyが付くやつです。

$ winget install gnupg.gnupg
$ which gpg
$ git config --global gpg.program "C:\Program Files (x86)\gnupg\bin\gpg.exe"

現在使っているterminalは作成(パスフレーズ)が動作しないようです。したがって、mac, linuxで作成してimportします。

$ 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に登録しておけばいいでしょう。

$ gpg --armor --export ${id}

あと、~/.gitconfigも更新しておきます。

$ git config --global user.signingkey ${id}
$ git config --global commit.gpgsign true

# 再起動
$ gpgconf --kill gpg-agent
$ gpg-connect-agent /bye

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

# 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

[fix]
1. ai/airse -> ai/rse
2. syui/ai/rse -> Syui/Airse

version

今までgame systemのversionでやってきました。game systemのversionはアイのモデルの変化で決定されてきました。

しかし、ue versionがわかったほうがいいので、以下の形式に変更します。

• version: 5.7.0.6.11

[ue] [system] [fix]
5.7.0.6.11

{
    "version": "5.7.0.6.11",
    { 
        "ue": "5.7.0",
        "system": "6",
        "fix": "11"
    }
}

開発の方向性

考えに変化があったので、お伝えします。大きなものは以下の2つです。

1. ゲームの完成を目指すが、ちゃんとしたシステムを作ることも目指す
2. 完璧に自信があるものでゲームを作る

ちゃんとしたシステムを作る

ゲームの完成を目指して、色々と考えやってきましたが、ちゃんとしたシステムを作ることを優先したほうがいいと考えるようになりました。

というのも、ちゃんとしたシステムを作っておけば、それを組み合わせるだけでいろんなゲームを作れるからです。

ゲームを構成する要素、その基本というのは決まっていて、システムも決まっています。例えば、キャラクター操作。それさえ本当にレベルの高いシステムを自分で作れるなら、色々なゲームに応用できますよね。

ゲームを完成させられることは素晴らしいことです。

しかし、ゲーム制作をやめてしまうときはどんなときでしょう。ゲームを完成させるのは本当に大変で、そこに到達できる人は少ないのですが、しかし、到達できた人も、そこでやめてしまう人が多いんじゃないでしょうか。

続けられる人はごく僅かで、大きな理由は2つあると思っています。

一つは成功しなかったこと。続けるだけのメリットを感じられなかったことだと思います。

2つ目は、作ってきたものがどうしようもなく再利用できない状態にあることだと思います。例えば、作ってきたものがシステム化されておらず、他のゲームを作ろうとしたときに利用できない形、ごちゃごちゃで自分にも把握できず、使い回せない、あるいは別のゲームに統合できない状態であること。

そうでなければ、他のアイデアをすぐに試してみようとなりやすい、ゲーム開発のハードルは低くなっているはずです。にも関わらず、ちょっとやってすぐ辞めてしまう人がいます。

それはなぜかというと、作ってきたものがゴチャゴチャで使い物にならなかったときじゃないかと思います。もちろん、本人の熱意とか継続性とか意思とかそういったものもあります。でも、心が折れそうな時にもコントロール可能な環境要因があるはずで、そうした環境を構築する能力も重要なのではないかと思うのです。周りにちゃんとしたシステムがたくさんある、そんな状態を作る、ということ。そういうのを目指していきたいと思い、ちゃんとしたシステムを作ることも優先的に考え始めました。

自信があるものでゲームを構築する

インディーズゲーム、特に3dは本当に難しい。私のゲーム開発の方針は、少しずつ決まってきて、注意しなければならないこともわかってきました。

それは、無理をしないこと。無茶をしないと言い換えてもいいでしょう。

しかし、この無茶をしないというのは表現が難しく、本人が無茶だと思っていなくても無茶に含まれることは多いと思います。

例えば、個人が3dでゲームを作ることでしょう。

「いやいや、そんな」と思われるかもしれませんが、細かいところを見ると、個人開発で3dをやるのは、結構な無茶だと今では思います。また、ueを使うこともそれに含まれるかもしれません。

ueや3dを使うと、個人でも大きいものが作れた気になってしまう。広いマップ、リアルな描写、動く3dモデル。

しかし、扱いきれない武器ほど怖いものはありません。初心者の個人開発にとって、それを置いていくほうがいい場合もある。だけどそれを手にとって進んでしまうのです。

この場合、個人ができるのは、その武器に圧倒的な制限をつけ、使える場面を限定することだと思います。

私も自分のゲームをプレイしていて、この部分はよくできているなというところが少しあります。しかし、総合的なゲーム性で考えると、全然ダメですね。

でも、それなら本当によくできた自信がある部分だけでゲームを作ればいいんじゃないかな。

そこには工夫が必要になるかもしれないし、コンセプトが重要になると思いますが、私はそのような結論に至ります。

完璧に動作する部分、バグが少なく、自信があるところ、自分のゲームの最大の魅力、そこだけを使ってゲームを構築することを今は考えています。

面白いかどうかは、正直わかりませんが、パッと見で、少しプレイして、「あれ、これすごいんじゃない」と思わせることができたら成功だと思います。最初はそこを目指していこうかなと。

無理をしてできることを増やしても意味がありません。特に個人開発で、3dで、かつueだと、それはとても危険な気がします。

とはいえ、重要なのは、たくさん作ること。

3dで開発するな、ueを使うな、開発者は好きなものを作るな、と言いたいわけではありません。

言いたいのは、たくさん作ってきたものの中には光るもの、よくできたものがいくつか出てきます。そういったものを使ってゲームを構築する。その方向性でも考えてみる、ということ。

おそらく、3dで作る場合、ueを使う場合、個人開発者が好きなものを作る場合に、このような制限は役に立つと思います。

以上が、最近の個人開発の方向性、あるいは考え方の話です。

ちゃんとしたシステムをどのように作るのか

1. 名前規則に忠実であること。フォルダ、ファイルや変数、関数などのすべて。例外的な名前規則を付けたものを置く場所を決めておくこと。
2. 簡単にシステムを分離、統合できる状態であること。
3. 依存関係を減らし、ファイルは自分のフォルダのみで動く状態にすること。assetはdownloadするが、できる限りそれを使わず、使用するものは自分のフォルダに置いて整理すること。それを使ってシステムを構築すること。
4. その時に使わないものは即座に削除すること。これはノードや変数、関数、すべて。

ようは、売られているassetやpluginの状態を目指すのが一番良くて、downloadすればすぐに使えるような形が理想的。

pvをゲームにする試み

自信があるものでゲームを構築するといっても、どのようにやればいいのでしょう。

ここからは自分が書いたメモを貼り付けます。

原神のキャラクターpvがある。とても参考になりそうだ。

https://www.youtube.com/watch?v=0MiIciljaWY

pvを作ったほうがいいのかと思ったことがあって、いや、pvをゲームにすればいいという案が浮かんだ。

これはpixelstreamingなどで配信することを考えたゲームといえばいいかな。要は簡単に遊べる一つの軽量パッケージのようなものだ。体験版みたいな感じだろうか。

さて、ゲームを開始すると同時にロゴ、音楽が流れる。pvのような少しのムービーがあり、キャラクターが紹介される。

次に、戦闘シーンだが、これに関しては例えばユーザーがスキル、バーストの2種類の技を発動できるようにしておき、ユーザーの行動によってpvが変わるという仕様である。仕様というか、仕組みである。つまり、pvをゲームに、ゲームをpvに。そんな感じの試み。

軽量パッケージ化をどのように進めるか、あるいは、簡単なゲーム作りはどう進めるかに迷っていたが、この方向性で行こうと思う。

pvを作ると同時に、ゲームを作る。ゲームをpvにする。単純だが効果的なアイディアだと思う。

これなら操作可能範囲も大幅に削れるし、基本的にpvを作って、一部操作可能なゲームにするだけだ。

ゲーム性とダメージ変動。これについては簡易的な個人アカウントみたいなものを使って実装したいという案がある。ゲームには再生ボタンがあり、実行するとpvが流れる仕組みだが、上にログインボタンがあり、そこでログインできる。ログインといってもhandleを入れるだけの簡単なものだ。で、oauthで簡単なゲームアカウント作成のページを別に作っておく。それを実行していると、atprotoからデータを読み取る。

ゲーム作りの方向性として、軽量で、しっかりと動き(バグがなく)、効果的で面白いものを作ろうとしていて、その答えの一つが、pvをゲーム化するという案だった。

これはいくつの前提思考をもとに構築されている。前提思考とは、シンプルなゲームを作ろうという試みで、最初はわかりやすいシューティングゲームのようなものを構想していた。

しかし、この構想には不足がある。一言でゲームの始まりは?終わりは?クリアやゲームオーバーの演出は?その他諸々のゲームにとって重要な要素が伝わらない、そして、その部分をどう構築していくか見えない点にあった。

この弱点を克服した案が「ゲームキャラのpv動画をゲームにしよう」というものだ。

もっとシンプルに言うと「pvをゲームにする」ということ。これならイメージがはっきりと浮かび上がり、かつゲーム化する際の要素も決まってくる。ゲームの始まりと終わり、ゲーム中がどのようなものかをはっきりとイメージすることができる。

では、実際のキャラpvを分析してみよう。ここでは原神のウェンティの動画を分析する。

1. 黒い画面にロゴ(作者)が浮かび上がる。美しいBGMが流れる
2. 緑の木々と青い空
3. カメラがキャラクターの方に移動
4. キャラクターが物語の重要なセリフ
5. 背後に敵の影
6. 敵が攻撃してくる、攻撃はキャラクターの方向に向かう、カメラワーク
7. キャラは優雅にそれを避ける
8. キャラの紹介文や演出が入る
9. バトルシーン
10. スキル、爆発の紹介(セリフあり)
11. 最後のキャラを正面に通常攻撃、弓が放たれ
12. ロゴ(タイトル)が浮かび上がる。美しいBGMの終わりと合わせる

これを自分のゲームに当てはめてみる。

1. 黒い画面にロゴ(syui)が浮かび上がる。BGM、ピッチは0.2
2. アイの家とアイが屋根の上に座っている、モーションあり
3. セリフ、物語は天空に浮かぶ島からはじまる(誰しもが興味を掻き立てられる内容=天空城や古代兵器)、BGMのピッチを徐々に上げていくmax:1.0
4. 地球に近づく黒い影
5. 砲撃が始まる、赤い光が星をめがけて落ちていく
6. アイが高速飛行して、敵の場所に移動
7. キャラの紹介と音声
8. スキルとバーストの技紹介、キーやボタンをかっこよく表示(ななめ、大きめ)。背景は灰色とカラーをあわせる
9. バトルシーン(プレイヤーが操作可能)
10. 1ボタン(1操作)でゲームクリア。時間経過で次のシーンに移行
11. 最後にキャラを正面にアップし通常攻撃
12. ロゴ(ai)が浮かび上がり、BGMの終わりと合わせる

面白さの実装には弱いpv。これをどう克服していくかを考える。

• バトルシーンを少し長くする
• atprotoのデータを参照し、現実アカウントの値をダメージ表記に反映する
• ダメージ総合値を表示したり記録したりする

原神の面白さは元素反応にある。つまり、キャラクターの攻撃の組み合わせ。ダメージ増加量など。原神では、キャラを敵の前に動かせる、スキル回し、爆発という流れで戦闘を楽しむ。これを分解すると、「合わせることと、ダメージ増加量のコントロール」だと思う。これを自分にもできる簡単な仕組みで実現できないかを考えている。