3.9 KiB
title, slug, date, tags, language, draft
| title | slug | date | tags | language | draft | |||||
|---|---|---|---|---|---|---|---|---|---|---|
| ゲーム開発とmulti-platform | ue-mac | 2025-12-28 |
|
|
false |
今回は、ゲーム開発のmutli-platform(マルチプラットフォーム)対応について。
近況
win, mac, iosで動くゲームがようやくできました。
動作は軽量で、winで開発していた時より安定しています。
mac/ios向けを作る開発者の数
個人開発では、ほとんど見当たりません。ueを使う個人開発者自体が少ないですが、mac/iosで作る人はさらに少ない。これには理由があると思いますが、ここでは話しません。
情報が少なく難易度が上がる欠点はありますが、やっている人がいないというのはチャンスでもあります。
開発者がmulti-platformをやる利点
mac/iosでゲームを作っていると、様々な利点に気づきます。
個人開発者は、win以外のmac, ios, linux, androidなど、複数のplatformで動くゲームを作る利点に気づいたので、今回はそのことを話します。
まず、winだけで作っていると気付かないボトルネックをいくつか発見し、設計を見直しました。
こういうものを放置していると、内部で蓄積し、ゲームの不安定化に繋がっていたと思います。
大企業が作るゲームはやたら安定していることを不思議に思っていました。もしかすると、こういうことだったのかもしれません。multi-platformを心がけることで自然とゲームの軽量化、安定化が進むので、結果的にwinで作るゲームも良くなっていたのかも。
multi-platformの大変さ
これも話しておかないとフェアじゃないので、書きます。
multi-platformの対応は、様々な問題が発生し、大変な苦労でした。
ゲーム開発自体が大変ですが、multi-platformへの対応はさらに大変です。
企業、あるいはチームがやるレベルの作業量、知識、対応が必要。基本的には、個人がやるようなことではなく、おそらく、個人では難しいと思う。
おすすめの方法は、winで作っていたprojectの移植を考えるのではなく、一からmacを基準に作ることです。ios, linux, androidの場合も同様です。
o ... mac -> win
x ... win -> mac
開発環境を整えることも重要で、私はgit, openssh, pwsh, zshなどを使います。
app storeに提出する場合、.pkg, .ipaなどの仕様を理解しておく必要があります。
最終的には、各os上で動作するbuild, deploy, testの自動化環境を作りました。
cmd example:
$ ${UE_ROOT}/Engine/Build/BatchFiles/RunUAT.sh
$ codesign -f -s "$IOS_CERTIFICATE_NAME" --entitlements "$entitlements" "$app_path"
$ iconutil -c iconset "$custom_icon" -o "$tmp_iconset_icns"
$ xcodebuild -exportArchive -archivePath "$archive" -exportPath "$BUILD_DIR" -exportOptionsPlist "$BUILD_DIR/ExportOptions.plist"
$ xcrun devicectl device install app --device "$IOS_DEVICE_ID" "$app_path"
$ xcrun altool --upload-app -f "$pkg_path" -t macos --apiKey "${ASC_KEY_ID}" --apiIssuer "${ASC_ISSUER_ID}"
画質と動作チェック
結果は、mac/iosで動くゲームは画質、 動作ともにあまりよくない。winはかなり良いという結果。開発者としては、winでプレイしてほしい気持ちがでてくる。