今からUnityでゲームを作る貴方へ送る10個の言葉

C++言語とDirextXでごりごりゲームを作るのに限界を感じて
Unityで移行して早五年くらい経つ自分が
とりあえずUnityでゲームを一本作ってみて気を付けたほうがいいポイントを
メモがてらにここに書き記そうと思います

初歩的なものから、Unityに限った話じゃないものがたくさん含まれます
(10年以上ゲーム作っておいてまだ学ばないのか)

1.日本語が含まれるパスを使わない

ゲームつくりに限った話ではないですけど
PCのユーザー名に至るまで全部英語が推奨です
(日本語のマルチバイト文字なんて考慮されてないんです)
C\るうん\UnityProject
とかになってるとまぁ大抵のものがバグりちらかします
全部バグるならともかく一部だけバグるからたちが悪いです

最近の変わり種ではフォントが日本語名だったのですが
フォントからテクスチャを作る機能利用時だけまったく動かなく
それが原因で半日くらい潰しました

なーんだ平気じゃーんって油断してると刺されます
気を付けて下さい

2.大文字小文字は統一する

「PlayerIcon.png」というファイルがあったとしましょう
例えば全部小文字の「playericon.png」でUnity上では読み込めますが
違うプラットホームでは読み込めないパターンがあります

スクリプト側で全部小文字に変換するなり処理をいれて事なきを得ましたが
うっかり発生すると非常に面倒です

2.ファイル名には種別をいれとけ

仮にプラントというモンスターを作ったとしましょう

そしてそのモンスターにかかわる画像やスクリプトすべてに
「ene_plant」とファイル名を付けたとします

画像は画像フォルダに、スクリプトはスクリプト用のフォルダへ
もちろん拡張子が存在するのでかぶったとしても何の問題もない……と思うでしょう？

間違ったファイルが入ってたり足りなかったりしてもぱっと見じまったくわかりません
なので「tex_ene_plant」や「mat_ene_plant」などにして
拡張子なしでもファイル単体で何のファイルか判別出来たほうがいいと思います

ここらへんはUnityのバージョンが新しくなるとかわるかもしれません

3.Unity標準の「PlayerPrefs」は使うな

標準で使えるPlayerPrefsはなんとレジストリにセーブデータを書き込みます

今すぐやめましょう

4.スクリプト内でUiなどは直接Pixel数値で動かさない

Unityには画面のサイズがかわったときに
自動的にUIをスケールしてくれるすごい便利な機能があります

移植のしやすいUnityを使うのならば
いずれゲームを解像度が異なる環境でリリースすることも考えられるでしょう

例えば動く指のカーソルとか固定値で動いてるものは悲惨なほどズレます

ちょっとだけ面倒ですけど
最初から指カーソルとかは目的座標が設定されたらそこに移動するとかのほうがいいかもしれないです

5.Ui.Textを使わない

最初からあるUi.Textさんには皆さんお世話になると思いますが
使い方に慣れたらTextMeshProUGUIに移行しましょう

こいつのすぐれた点は文字列の途中に好きな画像を差し込めるところです

例えば操作説明の時に「Aボタン」と表記しなくて
Aボタンの「画像」を表示させることもできちゃいます

『別に「Aボタン」でも「画像」でもよくね？』って思います

6.Resourcesフォルダを使うな

ResourcesフォルダはUnityにおいて
動的にデータを読み込むことができる(おそらく)唯一のフォルダです

正直これを使ったままゲームを作ることもできますし
なんならこれを利用してなんの不自由のない方もいるでしょう

ただしこのフォルダには欠点があって
おおざっぱにしかロードやアンロードをしてくれない点です

PCならともかくスペックがかつかつな機種などでは非推奨とされています

修正はわりと大がかりな変更になると思うので早めに卒業して
AssetBundleと対峙することをおすすめします

7.Inspectorで巨大なデータを扱うな

初めてUnityに移行して思ったこと

「Inspectorならゲームを起動しながら値の調整ができる！すげー！」

ゲームをプレイしながら敵のHPを調整したりなどわりとなんでも設定できます

ただし情報量に応じてとんでもなく動作が遅くなりますしチェックが難しくなります
(それ専用のアドインなどを入れれば話は別だが)

例えばモンスターの詳細ステータスやアイテムの細かなデータなどは
おとなしくCSVファイルなどで管理しましょう

8.Find~をあんまり使うな

スクリプトでよく使われるFind～は
ヒエラルキー一覧から条件に応じたものを引っ張ってくることができます

便利な反面くっそ重いらしいので毎フレーム使ったりするのはやめよう

9.UI用の文字を直接Inspector入力するな

スタート画面のシーンにおいたUi.TextのInspectorにあるTextに
「ゲームスタート」と直接記載するのはやめましょう

どういう時に困るかというとそれは多言語対応するときです

「俺は日本語しか対応しないぜ！」

って硬い意志があるのなら話は別ですが
そうでないのなら適当なスクリプトのInspectorの「STR_GAMESTART」などの
文字列を設定しておきスクリプト側でゲーム中の言語に応じた文字列を
引っ張って来るといいです

10.AssetBundleからは逃げられない

多くは他の方の記事を見たほうが早いです

個人的な意見をいえばゲーム作ってるなかで一番辛かった作業はAssetBundle対応でした

みなさんは僕みたいにならないようにもっと早く対応してください

もしこれを見て誰か少しでも助かったら幸いです

何か質問、Unityのここが辛かった！などがあればコメント欄までお願いします！

一般人向け：ゲームエンジンって？

最近Unreal Engineの話題が
ゲーム制作界隈でよく呟かれてますがみなさまはご存じでしょうか？
お

↓この動画は少し前のものですが、Unreal Engineの技術の高さでゲーム制作界隈では大きな反響を呼んだ動画です
https://www.youtube.com/watch?v=qC5KtatMcUw

…とは言っても一般の方にとってはゲームエンジンなんて興味のなく
まったくイメージのしにくい話題だと思います。

そこでちょっとわかりやすい例を出しましょう。

個人的にゲーム制作は「料理」に例えられると思っています。

「プログラマー」は「料理人」であり
「イラスト」や「音楽」など様々な材料を調理して
「仕様書」というなの「レシピ」に基づいて
最終的に「料理」というなの「ゲーム」が完成させます。

ではゲームエンジンは料理に例えると何になるかというと
それはずばり「調味料セット」です。

例えば料理に塩が必要だとしたら
ゲームエンジンを使わない場合は海に行って海水を採取して塩を作るようなものだとしたら
ゲームエンジンを使う場合は最初から塩が瓶に入って用意されているようなものです。

そして塩や胡椒などといった基本的な調味料は、
作る料理が変わっても使いまわすことができます。

これをゲーム制作においてゲームエンジンは、
ロールプレイングゲームであってもレーシングゲームを作るにしろ
使いまわすことができることと一緒です。

かつてはゲーム会社ごとに秘伝のたれの如くオリジナルゲームエンジンを使っていたのが一般的らしいですが
現在は大手以外はUnreal EngineやUnityなどといった有名どこのゲームエンジンに置き換わっているらしいです。
※FF14やMHWはオリジナルのエンジンだったはず(うろ覚え)
※天穂のサクナヒメで有名なえーでるわいすさんもオリジナルのエンジンだったはず(うろ覚え)

かくいうPhotonSystemもかつてはオリジナルのゲームエンジンを使っていましたが
さすがにNonetEnsemble～魔法仕掛けの迷宮～からはUnityを使っています。

……恐らく今後はオリジナルのゲームエンジンに戻ることはないでしょう。

ゲームエンジンに移行してよかったことなど語りだすと
とたんに開発者向けの記事になっちゃうのでこの話はここらへんまでにしようと思います。

また気が向いたら続きを書きたいと思います！
それでは！