どことは言わないが、同人系販売サイトに登録して作った物を売ってお小遣い稼ぎしようかなと考え、とりあえず物を作った。
で、これまでを振り返り、気を付けたいことを備忘録として個人的にまとめる。
書き上げた後から読み返すと、だいたい当然の事しか書いてないような気がするなぁ…。
作るゲームのボリュームを考えよう
よく言われる初心者がやりがちなやつね。
いきなりソウルシリーズみたいなアクション、FFやドラクエみたいなRPGを作りたいと言って手を動かし始めるやつ。
作ろうとしている物は、自身の実力や集中力、予算や期限に見合っているか？
やるにしてもまず初代マリオから始めた方が良いんじゃないか？
そこそこUnityの知識を蓄えた状態でロックマン的な物を作ろうとしたら、こんがらがって一旦作るの止めた。
で、ゲーム性がほぼないミニゲーム的な物を作って誤魔化した感じだけど、それでも売り物となる最初の作品として作り上げるのに半年ほどかかってるんだから、ロックマン的な物を作り続けてたらきっともう1～2年かかってたと予想できる。
ちょっとしたUnity自信ニキだと思い込んでる私でこのザマよ。
だってペイントツールで画像素材を自作したり、Blenderでモーション作成したりとかが思いのほかダルいんだもの。
モーションキャプチャー欲しいわ…。
定期的にビルドして.exeを実行しろ
この機能作った！Unityエディタ上で想定通りに動いた！ヨシッ！
で、他の機能とか諸々作った後に、いざビルドして吐き出されたexeを実行したらなんか挙動がおかしいんだけど？
って事が結構あったので、定期的にビルドしてexeを動かした方が良い。
体験版できたぞ！出力して動確だ！
exe動かしたら変なところがあるから直したぞ！
エディタ上では問題ないぞ！
exe動かしたら変なところが（ｒｙ
エディタ上では（ｒｙ
exe動か（ｒｙ
……いつ体験版出せるんや…ってなった
あとはエディタ上で動確するよりも実は負荷がかかってカクつきが酷いとか、セーブデータファイルだとかの配置場所があまりよろしくなかったとか、そういう発見もあるかもしれんし。
実際、ネットの情報だけで作ってると「Unityエディタ上では動くけど実機だと動きませんor実機動確未確認です」みたいなトラップはそれなりにあると思う。
Resourcesフォルダは使わない or 最低限の使用に留める
公式が使うなって言ってるっていうのは何となく知ってたけど、実際に人前に出すつもりの物を作ると理解できる。
プレハブも画像も音声も3Dモデルも全部Resoucesに入れてると起動時に読み込むデータ量が～…とかそういう話もあるけど、それ以前に画像とかの素材が生データのままユーザーが触れる状態になってしまうので、素材を改変されたり削除された後のゲームの動作とか画像素材等の権利的なところで非常に危険。
手動で面倒だとしても、publicなり[SerializeField]なりを使って必要素材を事前設定するようにしとけ。（それが良いやり方かは知らないが）
Resources.Load()は使わないに越したことはない。
事前の技術検証はしっかりと
ゲームの内容や要素を考えて、「こういう技術（機能）は必要。最悪ぶっ壊れても良いテストプロジェクト作って実現性可否の確認と実装判断をしよう」みたいにしましょうねっていう話。
なので実際に作り始める前に使いたい機能は洗い出しておくべき。
開発途中で実装するってなった場合に、プロジェクトの構成自体が変わるような大きな変更が必要な技術なら、いっそ見送るか1から作り直すかの選択をするべき。（1敗）
デカール機能使いたいなぁ⇒URP？HDRP？良く分からないけどその機能を入れればいいんだろ！⇒既存シェーダー諸々破壊して改善もできずゲーム画面が酷いことに…
ということを一度やって反省した。
実際の開発と平行して追加検証用のプロジェクトとしても使えるだろうし。
不定期でもいいからバックアップはちゃんと取る
当然の話かもしれないけどね。
前述の通り一度プロジェクト破壊したけど、バックアップ取ってたおかげ事無きを得た。
バックアップツールを導入するなり、自前でそういうツールを作るなりして万一に備えよう。
ざっくりでいいから作業スケジュールを立てておく
この工程を何月までに終わらせるってやつ。
まあ、（少なくともIT業界の）社会人をやっていれば作業計画は当然立てるべきことではあるかも…？
ざっくりでもスケジュールを出すには、当然ながら途中で何をやるのかもある程度は明確にしておかないといけない。
そういう意味でも事前の技術検証とかやっておけば、必要な工程は洗い出せるかと思う。
そもそもいきなり手を動かし始めても、直近のやりたいことをやり終えたら「次は何をすればええんや…」って感じで路頭に迷いかねない。
そうならないようにするための道標にもなる。
ええ、「個人製作だし適当でええやろ」で進めた私は迷いに迷って色々ととっ散らかりましたとも。
プロジェクトを作成する前に、ある程度の設計はしておく
エクセルでもメモ帳でも良いから、どんな要素があるのか・どういう機能が必要か・どういうファイルが必要か・どういうクラスが必要かくらいは書いておくと良い。
最終的にそれが設計書らしくはなると思う。
漠然とした状態で作り始めても、迷走ばかりして疲れて諦めた、みたいになりそうだしね。
プロジェクト内のフォルダ構成も決めておく
設計段階の話で意外と大事。
いざ作り始めると、適当にフォルダを作って適当な場所にファイルを配置しがち。
で、ある程度プロジェクトの規模が大きくなってくると、どのファイルがどこに置いてあったのか分からなくなる。
人によっては無駄に煩雑になったフォルダ構成にイラっとするかも。
これは実際に自分に合った構成を作るようにした方がいいけど、イメージが湧かないならググって他の人がどんな構成にしてるのか調べてもいいかも。
あと、一度その構成をテンプレートにできれば以後のゲーム制作でもフォルダ構成をそのまま流用できたりするし、やっておいて損は無いはず。