はじめに
僕はもともとObjective-Cの時代からゲームを作っていました。
そして半年前からUnityでゲームを作るようになりました。
本記事では、この変更の理由とSwiftとUnityのテクノロジーの違いを書いています。
僕が使ったテクノロジーについて
ここでは僕が使ってきたテクノロジーとそのテクノロジーを使わなくなった理由を書いていきます。
OpenGL2
ゲームと言ったら動的に動く物！
という理由で調べたところアニメーションなどに適しているのがOpenGLだったため、一冊の本を買ってOpenGLを学びました。
OpenGLをObjective-Cで制御してシューティングゲームを作りました。
辞めた理由
OpenGLは2Dのゲームを描画するための技術なのですが、知識がないとかなり大変です。
例えばPNGファイルを取り込んで画面に出すだけでもかなり多くのコードを書く必要があります。
また、制御を誤ると画面がちらついたり1フレーム前に描画した画像が残像のように残ってしまったりします。
例えばドラクエのようにマップ内を歩き回る処理を書く場合は、移動のたびに背景のマップを全描画する必要がありました。（僕のスキルでは）
とにかく難しくコード量も多いため３作品ほど作ったところで他のテクノロジーに変えることにしました。
Cocos2d-iPhone(SpriteBuilder)
「OpenGLを直接使わずにOpenGLを扱える技術が何かないか？」
と調べたところUnityとCocos2dが見つかりました。
この時にUnityを選択すればよかったのですが、当時のUnityは3Dに特化していて僕には敷居が高い物でした。
また、Cocos2d-iPhoneは当時の最新言語であるSwiftでコーディングができたため勉強も兼ねてCocos2d-iPhoneを選択しました。
（おかげで当時業務で使っていたSwiftのスキルが上達しました。）
Cocos2dはOpenGLを容易に操作できる上にTiledというタイルマップのライブラリーもサポートしていたため開発速度は一気に向上しました。
（Cocos2d-iPhoneを使う前は自前でTiledのデータを読み込んでいたので、バグも多くコード量も多かったのです。）
正直この技術最高じゃない！と思ってました。
辞めた理由
しかし、僕がこのCocos2d-iPhoneに飛びついた瞬間にCocos2d-iPhoneのサポートは終わってしまいました。
サポートが終わってもしばらく使っていたのですが、XCodeがアップデートするたびにCocos2d-iPhoneの中身を書き換えないと動かない状況に陥りました。
（この作業は本当に苦痛でした。サポートされていないため文献もなく、Cocos2d-iPhoneの中身をあてもなく彷徨って変更して確認して・・・という地獄のような作業でした。）
ここで僕は再び露頭に迷ってしまいました。
SpriteKit
OpenGLを直接触るのは嫌だし、どうしようかと思っていたところにApple社からSpriteKitが発表されました。
これを使えばOpenGLを直接触らずに操作ができる上に、Apple社がサポートしているからサポートが打ち切られる事はないと思い飛びつきました。
Cocos2d-iPhoneの二の舞は嫌だったのでCocos2d-xを選択する事はありませんでした。
（C++を触るのが嫌だったという理由もあります。）
辞めた理由
しかし、SpriteKitはCocos2dに比べると様々な点で劣ってました。
例えばTiledのサポートは無い（途中で中途半端にサポートされましたが・・・）ため、マップを作る処理は自前でした。
また、Sceneの作成用のツールを使っているととにかく落ちまくりました。
長い間使っていたのですが、なかなか便利になりませんでした。
どうやらApple社はこのテクノロジーを改善していく気が無いのだと感じたのです。
Swift
上記の理由からApple社純正のSwiftでUIよりもゲーム性に特化したゲーム作りに舵を切り始めます。
SpriteKitはアニメーションが必要なところだけで使おうと割り切りました。
辞めた理由
純正なのでUI周りの作成は問題がなかったのですが、アニメーションを入れるためにSpriteKitを入れると座標計算方法が違うためxibファイルとsksファイルでの操作性を統一させるのが困難でした。
もう少しアニメーションを入れたいと思っても、上記の理由で煩雑なコードになるため実現ができませんでした。
Unityに変えた理由
このような紆余曲折があってUnityにたどり着きました。（すごく回り道をした気分です。）
この時代になるとUnityも2Dゲームの実績が多くなってました。
Unityを選んだ大きな理由は以下になります。
- 僕が調べた限りでは一番メジャーだった。
- クロスプラットフォームだった。
- 文献が数多く存在していた。
- Unityだけで完結していると思った。（実際はEditerはVBなどの選択をする必要があった）
- C#で書ける。（僕はC#の経験者だった。）
これらの理由からUnityでゲームを作ってみようと決めました。
戸惑った点
Unityを始めた時に一番戸惑ったのがSceneという単位でゲームを作る事でした。
Xcodeでゲームを作る場合はStoryBoardを使ってスタート画面を設定したり、AppDelegateからsksやxibを呼び出せるので導線がわかりやすかったのですがUnityにはこのような明確な導線が見当たらなかったので戸惑いました。
「Scene間でのデータのやりとりはどうすれば良いのか？」なども戸惑いました。
共通部品の作成方法であるPrefabについても開発者ごとに意見が違ったため、どの方法がベストなのだろうか？と悩みました。
あと、フォルダの名前によって役割が変わるためどのようなフォルダ構成にすれば良いのか悩みました。
（これは今も悩んでます。）
ついでに言うとモダン言語であるSwiftから若干レガシーな言語であるC#に戻ったので、コードを書く時に不便だなーと思いました。
（もちろん便利な点もありますが、やはり後発言語の方が書きやすいです。C#のオプショナルは貧弱なので、Swiftから移ってくるとコードに違和感があります。ラムダも冗長だし・・・とこの辺りは書き出すと止まらないです。）
変えて良かった点
書くまでもなくOpenGLやMetalという下位層のレイヤーを触らなくて済むのがUnityの素晴らしい点です。
SpriteKitも下位層は触らなくても良いのですが、エディターがよく落ちる上に扱えるオブジェクトが少ない（テキストボックスさえ使えない）レベル。なので、これだけでもUnityに置き換えた大きなメリットです。
UI周り
これが一番の恩恵です。
UnityはUI周り処理がとても書きやすいです。
SpriteKitを使うと途中で落ちてしまうことが多々ありましたが、Unityではあまり落ちませんでした。（稀に落ちる）
それに、煩雑なUIを作ることに長けている上に、共通部品であるPrefabの設計など本当に秀逸でした。
ライティング周りも少し調べれば2DLightなどがあったため雰囲気を出しやすかったです。
とにかくUI周りに関しては、Googleで調べれば大抵の事が実現できたのが良かったです。
クロスプラットフォーム
他にも各プラットフォームのサポートが手厚いため多少の手間でiOSとAndroidの対応ができるのもよかったです。
C#はコード量が若干多いですが、慣れるとあまり気になりませんでした。
音源周り
これもUnityがサポートしていて、細かい設定周りのサポートが簡単（本を参考にしてますが・・・）に設定できるのが良かったです。
（これ、XCodeで実装すると音が鳴らないタイミングとかがありました。）
タイルマップ
Cocos2dに比べると弱いですが、タイルマップ周りの描画がサポートされていたのは助かりました。
（配置したタイルに情報を埋め込みたかったのですが、これはサポートされてませんでした。）
ローカルデータの扱い
XCodeでローカルデータを扱うと、フォルダの階層がとても深い上にXCodeのバージョンを上げると紛失してしまいます。
しかし、Unity内部でのローカルデータは固定フォルダに出力されるのでUnityのバージョンが変わってもローカルデータがなくならないのは地味に便利でした。
（Unityはバージョン変更が容易にできます。gitで管理しておけば元に戻すのもあまり大変ではありません。）
FPSタイマーを自作しなくて良い
UnityはFPSタイマーで動くことが前提になっているので、この辺りをの処理を自作で作らなくて良いです。
SpriteKitの場合はMoveなどのメソッドでオブジェクトを動かすのですが、C#にはコルーチンが用意されているためアニメーション周りでもそこまで困りませんでした。
（FPSとメソッドで移動させるのについて、どちらが良いかは今だにわかりませんがiTweetみたいなライブラリがあるのを見るとメソッドで動かしたい人がUnityにも居るようです。）
僕はOpneGL時代に自作FPSを作って苦労してたので、コルーチンがあるだけで随分楽にコードがけるようになったなーと思いました。
ScriptableObjectが使える。
XCodeで設定周りを記述するときはPlistが主力になります。
このPlistはある程度のレベルなら良いのですが、データが増えてくると管理が煩雑になります。
その点はUnityのScriptableObjectを使うと(癖はありますが）スキーマーを自在に作れるので管理が楽にできました。
他にもExcelなどを使ってインポートするなどもできるようですが、これはXCodeでも出来るので割愛。
（僕は出来るだけ同一環境でデータを管理したいのでExcelなどでコンバートする二重管理方式があまり好きでは無いのです・・・）
課金周り
スモール実装なら驚くほど簡単です。
IAPを使えばほとんどコードを書かずに実装できます。
レシートチェックとかを入れると。。。まぁ、それはどの環境でも大変ですよね。
AssetStoreがある
欲しいプログラムや素材をすぐに購入できる仕組みがあります。
これは本当にありがたいです。
僕はまだUnityでゲームをリリースしていませんが、このストアでは数万円〜もしくはもっと買い物をしたかもしれません。
それだけ便利です！
その他
他にもありますが、とりあえず思い出せる点を書き連ねてみました。
個人的には上記に記載しているUI周りとクロスプラットフォーム周りの恩恵が一番大きいと思っています。
変えてキツかった点
とはいえ、やはりキツかった点もあります。
戸惑った点にも書いていますが・・・
プログラム周りが弱い
モダン言語は大抵において過去のプログラムの良いところを採用して作られている場合がほとんどです。
なので、15年近く前に作られたC#とは大きな差があります。
RxSwiftなどのライブラリはUniRxなどで代用が効くのが良いのですが、、、基本構文はなかなかの面倒臭さがあります。
- Enumにメソッドがつけられない。（拡張は出来るがコードが散らばる）
- EnumのCaseに漏れがあってもコンパイルエラーにならない。（賛否両論があると思いますが、Swiftのこの機能は生産性を高めます。）
- ラムダ式で
$0などの省略が使えない。（簡単なラムダ式でも冗長になってしまいます。） - オプショナル型が弱い（一応
?などは使えますが、オプショナル型ではないのでnullチェックが必要。Nulltable型のコードが冗長になる。） - キャストが弱い（
if let = optionalが使えないのはもちろんで、親オブジェクトに暗黙的にキャストしてくれないので一つ一つジェネリクスのコードを書く必要がある。これ、地味に面倒です。） - Switch文で同じcaseが使えない。（
case a,b:ということが出来ない上にbreak必須なので、同じような属性の値でもコードを書く必要が出てくる。） - 変数のスコープが少しわかりにくい。（if文の中だけで使う変数をif文を抜けてから再定義する事ができない。これは僕のプログラムの書き方の問題もあるけれど
itemなどの変数をスコープ外と内で別の意味で使わせてくれても良いのに・・・） -
flatMap系がない。（似て非なる物ならあるのですが、、、まぁ、これは言語特性の問題なので仕方なし。僕はflatMap系を多用するのでちょっと困りました。）
と、まぁ、これも書き出すとキリがないのですが・・・
SwiftからUnityに移った人はラムダとオプショナル、Enumに関して「え？」と思うかもしれません。
多画面対応
Unityって様々なプラットフォームに対応しているのですが、多画面の対応が少し弱い感じがしました。
XCodeならConstraintsを使ってラベルが横に長くなったり縦に長くなっても対応に大した問題はありませんでした。
しかし、Unityではこれができません。
基本的には画面のどのあたりに配置するのか？と言うところまでしか対応できません。（多分）
ただ、これはSpriteKitを使った場合に同様の問題にぶち当たるので処理速度を優先した結果なのかもしれないと思っています。
スクロールが貧弱
Unityのスクロールは何も考えずに使うと大量のメモリを消費するようにできています。
ついつい500個くらいのアイテムをスクロールに表示すると上部を表示するだけでも500個のデータがレンダリングされてしまいます。
ただ、これもSpriteKitと比べると・・・SpriteKitにはスクロールがないですからね・・・（確か
XCodeのスクロールは癖がありますが、高速にレンダリングできるようになっているので安心して使えます。
結論として、僕はこのスクロール問題を解決するために自作しました。
Firebaseに冷たい
Firebaseだけじゃないかもしれません。サードパーティーはAndroidとiOSで別々に作られている場合があるためAndroidとiOSで設定の仕方が違います。
Androidはそんなに問題ないのですが、iOSは最終的にPodsを使う必要があるのでUnityネイティブの人はインストールに難儀する気がします。
あと、地味にAndroidとiOSで処理結果が違う時があります。（アナリティクスのみ。Realtime databaseは同じ感じがします。Firestoreはサポートされていません。）
多言語は自前
Unityは全世界で使われているので多言語対応もバッチリかと思ってましたが、これは自前でやるしかありません。
それはXCodeでも実は同じ（XCodeに用意されている機構は使いにくいので大体の人は自前で実装すると思います。）。
イニシャライズに罠がある
RuntimeInitializeOnLoadMethodを使うとアプリが起動する前に処理ができるのですが・・・
ここで設定ファイルの読み込みとか、別スレッドを発行とか色々やると稀にアプリが落ちる事があります。
これはただの癖の問題ですが、ついつい便利だから初期化処理をすべて詰め込んでしまうと謎のバグ（起動直後に固まる）に遭遇します。
これ、原因に気がつくまで２〜３週間くらいかかりました。
動かないバージョンがある
これも仕方がないのですが、MacのバージョンがCatalinaになったてからしばらくの間はUnityから実機転送しても動かない時期がありました。
XCodeの場合は同じApple社が作っているので実機転送後に動かないことはなかったのですが・・・
なので、Unityのバージョンを変える場合は注意が必要です。
また、Unityのバージョンを変えるとXCodeのPodsを更新する必要があったり多言語用ファイルを作り直す必要があったりするので鬼門です。
最後に
最後に色々問題点を書きましたが、これは僕がUnityに慣れていない事も原因ですし乗り越えられない問題でもないです。
むしろ開発効率を見ると遥かにUnityの方が高いです。
ゲームを作りたい人で、上記に書いている事がクリアーできる人ならUnityを選択する事をお勧めします。
ただし、業務系に関してはSwiftとKotlinで別に書く事をお勧めします。
OSに関して直接指示が出せないのは少し厳しいのと、業務系のプログラムはそこまで大きくならない（サーバーで処理を吸収できるはず）ので個別に書く事をお勧めします。