Unity3.5時代の愚痴

# はじめに
この記事は単なるポエムです
現在進行形でUnityを使っている人に有益な情報は一切ありません
もし、昔Unityを触っていた人が偶然この記事を見て、
「ここが原因でUnity使うの辞めたんだよな」と言う人がいたとしたら、
今のUnityはとてもよくなっているので、もう一度触ってもらえると嬉しいです

## なんでこの記事を書いたか
ちょうど私がUnityを使い始めて、2021年で10年になります
なので、この10年でUnityがどう変わっていったかを振り返ろうかと思いました
しかし振り返っていると、「今思うとあれは酷かったな…」と思うものがいくつか出てきたので、
せっかくなのでネガティブになってしまいますが、愚痴という形で過去のUnityを振り返ろうかと考えました

### ・UIのデフォルトのシステムが悪い
今でこそuGUIがあり、Hierarchy上でUIを配置して確認ができるようになっていますが、
uGUIが出る前はOnGUI()でUIを配置するのがデフォルトでのUIシステムでした
OnGUI自体は今でもあり、Editor拡張で使っている人も多いと思います
（残念ながらEditor拡張ではまだ現役です）
このOnGUIだけで愚痴が1記事余裕で書けるほどのものでした。主だったものを上げると
・実行しないと配置が確認できない
・Buttonを１つ使うたびDrawCallが増える
・そもそも関数が書いてある時点でボトルネック

などがありました。では当時どう開発していたかと言うと、AssetStoreでNGUIと言うアセットを買っていました
それはもうみんな買っていました。定価90$したと思いますが、開発には必須だったのです
あまりにもみんな購入していたのが理由なのか、NGUIの作者は後にUnityに入社してuGUIを手掛けます

### ・日本語に対応していない
日本語対応していない。と聞くと、Editorのメニューやドキュメントが対応していない。と思う人も多いでしょう
もちろん今はそれらも日本語対応しています
しかし、ここで言いたいのは「日本語入力」の問題です
当時、UnityではEditor内で日本語の入力ができませんでした。なので一回メモ帳などで書いたものをコピペしていました
Editor内だけではなく、当時のUnityのデフォルトの開発環境であったMonoDevelopも日本語入力に対応していませんでした
（後に日本語入力もできてユニティちゃんも眺められる、[痛MonoDevelop](http://anchan828.hatenablog.jp/entry/2013/12/23/222531)と言う物も流行りました）
じゃあMonoDevelopではなく、VisualStudioを使えば良い。と思うでしょう。実際使いました
そこでも日本語で問題がありました
日本語でコメントを打つと、その次の行までコメントアウト扱いになってしまうのです
じゃあ英語で全部コメントつけるのか？　となりますが、解決策は
`// 日本語のコメント打てるよ! .`
と最後に半角文字をいれると防げました。

### ・日本語での情報がほぼ無い
今はUnityの日本語の情報はいっぱい出てきます。公式のドキュメントも日本語対応されている物も多いです
コミュニティも多くできていて、本も大量に出版されています
しかし当時は本やコミュニティも日本にはほぼ無く、ブログで技術記事を書いてあるところも少なかったです
Unityの方々もそれは理解していたのか、FacebookでUnityユーザー助け合い所と言うものを作ったり、
そこで公式の方々が親切に質問に答えていたりしていました

### ・2Dゲームが作りづらい
当時、UnityはUnity3Dと言う名称でした。そう3Dなのです。2D用には作られていませんでした
前述した通り、Unityは2DのデフォルトUIが大変使いづらい物でしたので、
3Dのシステムを使ってなんとか2Dゲームを作っていた。と言う時代でした
ただそうなると、当たり判定や重力処理は3D用の物なので、2Dにはあまり使えません
なので全部自前実装になっていました

### ・謎の言語UnityScript
UnityはC#のイメージが強いのですが、当時はJavaScriptが多かったです
自分が知る限り最初に出た日本語の[Unity本](https://www.amazon.co.jp/exec/obidos/ASIN/487311506X/masafumislabo-22/ref=nosim/)もJavaScriptで書かれていました
問題は、UnityのJavaScriptはJavaScriptと言う名前ですが、言語仕様が違っていたのです
(むしろActionScriptに近いのでは無いかと言われていました)
なので、JavaScriptが出来る人がUnityを触って困惑した。と言う話をいくつか聞いていました

それといまだに謎なのですが、JavaScriptではUpdate()内でyield;が使えていました
毎フレーム呼ばれる物になんで使えていたんだろうか…

### ・コンパイルやビルドが劇遅
当時、モバイルゲームをUnityで作っていたりもしたのですが、
この時は作りやスペックの問題もあると思いますが、１行変更したら、その変更をコンパイルするのに３分ほどかかっていました
もしそこでtypoなどあれば、また修正して３分待つ必要があります。地獄でした
そこで、少しでも早くするため、作業途中のスクリプトはPluginsフォルダで作業する。と言うハックがありました
UnityのコンパイルはPluginsフォルダが先に行われるため、そこでコンパイルエラーは防ごうと言う魂胆です
また、ビルドもとても時間がかかりました。当時はCI/CDの知識も技術もあまり無く、愚直にビルドして実行していました
Androidはまだ良いのですが、特にiOSへのビルドはXCodeも通す必要があり、40分以上はかかっていたと思います

### ・バージョン管理システムAssetServer
当時、UnityはUnity内で完結出来る、AssetServerと言うシステムを売り出していました
Gitのような物ですね。ただこちらが曲者でした
基本的にはコミットして、他の人はそれを持ってきて、競合が発生したら破棄するかマージするかを選択する
と言うような、基本的なバージョン管理システムです
ただ、AssetServerはブランチを切れません（無理やりコピー作ってブランチ作るなどはできます）
コミットがプッシュ扱いなので、ローカルの作業を一旦コミットしてログに残す。と言ったこともできません。
その上、マージするときも差分を確認しながらなどがやりにくく、多人数で開発すると、コンフリクトからのマージ失敗で作業内容が消えると言うことが多発しました
結局当時はGitに乗り換えました。このAssetServer、1ユーザーで400$ぐらいしたと思います

### ・AssetBundleがとにかく使いづらい
AssetBundleは今でも使われる物ですが、当時はAssetBundleでググると
「AssetBundleは何がクソなのか」と言う記事が最初にヒットしていました
（今見たら消えてました）
挑戦的なタイトルですが、内容は完全に同意出来る物だったと記憶しています
個人的に一番の問題だと思っていたのは、当時のAssetBundleはUnityのバージョンが上がると、
AssetBundleの互換性がよく切れていて、AssetBundleのビルドどころかユーザーにデータのDLをさせ直していました
また、EditorでAssetBundleのシミュレートモードがなかったので、AssetBundleをビルドしてサーバに上げて、実機でDLして確認…
と言う面倒な作業をしていました。前述の通り、当時はCI/CDが整備されていなかったので手作業です

AssetBundleは何がクソなのか。に最後に書かれていた文が印象的なのですが、
「一番クソなのはこのシステムを使わなくてはいけないことだ」
みたいな事が書いてあって、同意すると共に笑った記憶があります

### 最後に
ここまで愚痴を書いてきましたが、これらは全て過去の話です
いかにUnityが進化し、使いやすいものになっていったかを認識できました

また、色々と愚痴を書いていますが、「じゃあなんでUnity使ってたの？」と思うことでしょう
当時は、ゲームエンジンはとても高価なものでした。特に3Dが使え、マルチプラットフォーム対応
それをUnityは数十万円払えば、Proライセンスを買い切りで使えたのです
（当時は買い切りでUnityPro,iOSPro,AndroidProがありました）

また、何よりもUnity Technologies Japanの方々が改善や布教に尽力していたのが好感持てて、印象的だったと言うのもあります
積極的にコミュニティやイベントを開催し、質問事項のメールの返信も迅速で丁寧でした。これは今でもですね

これからのUnityの進化にも期待しています