読者です 読者をやめる 読者になる 読者になる

はまやんはまやんはまやん

hamayanhamayan's blog

有名アプリ会社2社へのインターンとインディーズゲームアプリ開発で得た経験と成果のまとめ

殴り書きであるが、Unityを使ったゲーム開発で使えそうな知識をメモしておく。

成果物

  • グルーヴこねくしょん

http://denbaku.com/gc/index.html

企画自体は4月から。
グルーブをつなげて、よりノリノリになるゲーム。
2Dゲームなので、uGUIを使った開発をしました。

以下、Tips形式

入力関連

デバッグ段階で入力関連には色々考えさせられました。
一緒に開発していた友人がデバッグが上手いこともあり、入力の罠が色々見えてきました。

入力処理を受け付けてほしくない場面がある

例えばダイアログを出している時は、ダイアログ以外の入力は受け付けてほしくありません。
その他にも、画面遷移中に他のボタンが押せるのも、二重で遷移が起きてしまいよろしくありません。
つまり何が言いたいかというと、”入力処理を受け付ける時はその入力処理を行っていいか確認しよう”ということです。
入力の司令塔となるクラスを作っておきます。
そこに「タッチ処理が来たんですけど、処理を実行してもいいですか?」と確認を取ります。
OKサインが出れば処理という形にします。
どんな場面であっても、必ず確認を取ります。
デバッグの際に、確認漏れがむちゃくちゃあってデバッグに手間取りました。
”必ず確認しましょう”

マスターデータ

Google Spread Sheetがやはり偉大だった。
インターン先でも良く見かけたので、マスターデータ管理で用いたが最強だった。
Google Apps Scriptでデータを持ってきている。
若干遅いが、デバッグやレベリング用だと思えば全然許せる。
実機でも問題無く動作するので、実機上での確認(音とか)がGoogle Spread Sheetだけで完結するのは感動

音声周り

SEManagerがなぜ必要か分かった。
音周りがあっちこっちにあると頭パンクする(俺だけ?)。
使う側はSEManagerを呼んで使うだけなので、何も考えなくてもいい。
まとめておくことで、マスターデータとの連携もしやすい
あと、音声は止めたりポーズをしたりをする可能性があることを事前に考えて、設計されたし。
(欲を言うと、フェードとか、音声の調節とかも?)
Criwareが最善手な気もするけど)

シングルトン

不用心なシングルトンはやめよう。
シングルトン止めとけ説は、インターン行った2社ともの現場で聞いた気がする。
確かに何もかもリセットして処理やり直したいって時にシングルトンだと後がない。
シングルトンであるクラスを1つ作って、そのクラスがシングルトン化したいインスタンスを管理する方が安全。
これは有名な話か。

意思決定は1つにまとめる

これはインターン先の方からの受け売りみたいな所がある。
Unityのようなオブジェクト志向が前提で、全部のオブジェクトがUpdateできる関係で、ゲームについての決定を様々な所で行うことができる。
インターン先の方からの指摘だと、様々な所で決定を行うと(割り込みとかがあったりして)矛盾が起きやすいから纏めるとかおっしゃってた気がする。
それもそうだなと思うし、その上、決定している所が複数あると、後から処理を付け加えたり改変したい時に、見るべき場所が分からなくなる。
そのため、基本、ゲームの大事な決定をする部分は1つにまとめて、他のオブジェクトは観察・報告・動作だけに徹する方が見通しが良くなる。
やりすぎると嫌われそうだけど、このあたりをサボると、どんどんスパゲッティになっていく。

あと、Unityでは特に指定しないとスクリプトの呼び出し順がランダムであるために、スクリプトの実行順が変わるとバグるという現象が起きた。
これも意思決定が1つにまとまっていれば、防げたように思える。

オブジェクトの命名はシーン名+~にする

オブジェクト名をそのまま処理に使うのも1手だと思う。
例えば、SEのIDをオブジェクト名にしておいて、それが押されたら、オブジェクト名のSEを鳴らすようにするとか。
まだ、考察段階だけど。

パスマネージャを作りたい

リソースを動的に取ってくるときにパスを指定するけど、流石に直書きはマズイから、パス管理者を作る。
これは、自分の開発中にはやってなかったし(直書きしてた)、どういうふうに管理すべきか考えてないけど、必要そう。
(アセバンを考え込みながらやる必要がある?)

乱数(オカルト欄)

Random.Rangeが偏った乱数な気がする(体感だけかも)

Unity Cloud Build is GOD

ほんとに便利。
アセバン関係がうまく動かなかった(設定不足?)こと以外はほんとに満足。
無料でココまでやれていいのって感じ。
特に2人で開発していたので、俺がgitでプッシュすれば、1時間も経たずに2人とも実機で触れる。
相方が結構実機デバッグしてくれて、かなり助かった。
それで色々思ったこと

デバッグ表示

実機でも何らかの形でログが見れるとよい。
ホントは、Unity上で実行してみて正しく動くか確認すべきだが、横着して、未確認のままプッシュしたりする。
Unityはエラーが出ると、そこで処理アボートしちゃって何が起きてるか分からない場合がある。
特にUnity cloud buildを使っているとログを取るのに、ケーブルでMacに繋がなくてはいけない(なんか意味なくない?)。
(windowsでログを見る手段があるっぽいけど、どうやってもできなかったので)ログを取るためにMac Book Airを出さなくてよくなるように、実機で見られるように何らかの形で実機にログを出す

アプリバージョンとアセバンとセーブデータ

アセバンに関しては最初の内から入稿フローを作るべきだった。
最後の方になってアセバン化するアセットを手動で別にしたり、細分化できなかった。
セーブデータは変換器さえ用意できれば下位互換は簡単にできそう。
アプリの更新を促す警告とかはどうすべきかな…
毎回、アセバンやマスターデータのデータは最低限、前後のバージョンについて互換性が無いと、整合性が取れなくなりそう。
この辺をサーバメンテナンス無しで上手いことやる方法は無いものだろうか。
使う度に最新か問い合わせて、最新じゃなくなったらゲームを再起動させて読んでもいいけど、最新か問い合わせるコストはどうなんだろう
アセバンは外部化するときはプロジェクトから外さないといけないけど、画面上で配置させるときにはプロジェクトには入れないといけない。
だから、必然的にアセバンを作るようのプロジェクトとアセバンを使う側のプロジェクトの2つが最低いると思うし、インターン先でもそうなってた。
もっとより良い方法は無いものか。

位置もマスターに置けない??

配置を変えるだけなのにビルドし直すってのもなんかセンスが無い気がする。
アセバン化がベスト?それともプロはマスタの方に位置も書いてたりする?

アニメーション

ここは何らかのアニメーションが必須!ゲームとして無いのは考えられないという部分があった。
画面遷移(フェード)、ボタンの押下アニメ(アニメしないと板触ってるみたいになる)
こういう部分は自動的に何らかのアニメーションをしてくれるような仕組みが欲しい。
特に画面遷移のアニメーションってどうやるのが最善手なんだろうか

起動時

起動時にはスプラッシュ画面が表示されるので、スプラッシュ画面も考慮して最初の画面は作らないといけない。
スプラッシュが消えるのを待つもよし、スプラッシュからシームレスに移行しているような演出も作るもよし、だが、起動直後のStartメソッド内などで重い処理が走ると、
固まってスプラッシュが出なくなるので、重い処理が走らないように注意する

審査

審査の流れにむちゃくちゃ詰まった。
審査提出後にURLがおかしい所が見つかったので、マスターデータでなるべく怪しい所は外部化しておきたい。

Unity Ads

公開後に何故かブラックアウトして表示されないという現象が起きた。
初回公開時にテストモードで公開してしまっていて、これが原因かとも思われたけれど。
(原因はUnityサイドだった)
ブラックアウトして帰ってこないのは例外処理を疎かにしていたのが根本的な原因なのだが、マスター側でアドの表示設定もできるようにしておけば早急な対応ができたかもしれない。

終わりに

2Dの挙動はかなり勉強になった。
次は3Dでの中規模ゲームをやってみたい。