こんにちは。CYBIRDエンジニア Advent Calendar 2017 22日目の@gucchonです。新卒入社5年目のエンジニアです。
21日目は@kenchang100kgさんの「2017年の振り返り(インフラ)」でした。振り返ってみれば、本当に大きな変化があった1年だったなぁ…としみじみしますね。

本日の内容

弊社の恋愛ゲームアプリのクライアントサイドは、1年前までWebViewアプリとしての開発が主でした。しかし、社内外の諸々の事情を鑑みて、今年からは、Unityでのゲーム開発にチャレンジしています。私にとっても、開発チームにとっても、慣れないUnityでの開発は大きなチャレンジでしたが、なんとか無事に1タイトルリリースすることができ、今後より良いプロダクトへと発展させていくための土台作りができたのではと手応えを感じています。

ということで今回は、これまでWebView開発をしていた我々が、Unity開発に乗り換えてみて、苦労したことや、良かったことなどをまとめてみようと思います。

苦労したこと

大きくは3つあります。どれも新規タイトルの開発中に直面した問題でした。

1. 実装の自由度が高い

WebView時代が低かったのかというとそんなことはないのですが、Unityでの開発ノウハウのない状態で実装が始まったので、人によって各機能の実装方法がバラバラになってしまっていました。

例えば、Scene内のHieraruchyのGameObjectの構成とか。コンポーネントの掴み方なんかも、PrefabをInstantiateしたあとGetComponentをしたり、SerializeFieldを指定した変数にアサインしたり、Find系でHieraruchy内を探したり(これは検索範囲が広い場合はNG)と、色々な方法が取られていました。初期の頃は特に、そういった細々した実装方法の方針を決めていなかったので、開発チーム内に混乱を生んでしまっていました。

なので、Unityでチーム開発するときは、実装方針についてチーム内で議論して、しっかり決めておいた方が良いと思いました。我々の場合は、1つの機能を作りきって、全員でレビューをして、認識を合わせる...ということを実施しました。要はお手本となるようなScene、Prefab、Script一式を用意した感じです。

2. レビューに手間がかかる

弊社では、WebView時代からGithubを使ったバージョン管理をしていて、実装時のコードレビューもGithubのPull Requestで行うのが通例となっています。Unityの開発チームでもPull Requestでのレビューを行っていますが、.unityとか.prefabといったUnity独自のファイルは、コードの差分を見たところで、「何が変更されているのか」、「正しく仕様を満たせているのか」といったことを判断できません。WebView時代ならコードレビューで十分判断できましたし、差分を見ただけで、実装者が変更した内容の意図を汲み取ることもできます。

そのため、少し手間はかかりますが、.unityとか.prefabの変更があれば、実際にUnityで変更したSceneを開いたり、実行したりして、レビューするようにしています。

3. コンフリクトを解消できない

これもGitに絡んだ話ですが、.unityとか.prefabファイルはコンフリクトしたらほぼ解消できないので、細心の注意を払う必要があります。特にチーム規模が大人数になればなるほど、危険性が高まりますね。新規開発プロジェクトの後半になると、色んな人が色んな部分のバグ修正をあっちでもこっちでもやり出すので、より危ないです。

我々の場合はもう「運用でカバー」といった感じで、Scene単位で管理表を作って、作業着手するときに「このScene触ってます」というのを記載してもらっていました。あとは、メンバーの役割も別けていたので、コンフリクトが発生しない運用ができていました。

一応、UnityYAMLMergeというツールがあるようですが、今のところ「運用でカバー」で安定していて、困ってはいないので試したことはないです。まぁ、WebViewだろうがUnityだろうがコンフリクト起こさないに越したことはないですね。

良かったこと

こちらも大きく3つです。

1. 開発環境の構築が楽

WebView時代はPCでの開発環境の構築にそれなりに手間がかかりました。基本的にはコマンドを手順通りに実行していけばOKなのですが、ハマってしまう頻度もそこそこ高かったように思います。特に非エンジニアに簡単に提供できるようなものではなく、それなりに知識がないと扱いづらい環境になってしまっていたと思います。

その点Unityは、インストールしてプロジェクトを開けばすぐにゲームを実行できるので、開発や確認までの敷居が圧倒的に下がったと感じます。

2. 非エンジニアでも実装作業に参加できる

最も大きな利点がこれだと思っています。前述したように、環境構築や実行が楽になったことにも起因していますが、流石ゲームエンジンだけあって、非エンジニアでもある程度容易に扱えるようになっているので、開発フローの改善には素晴らしい効果があったように思います。デザイナーがそのままゲーム画面のレイアウトやアニメーションを実装できるようになったことは、かなりの生産性UPにつながっています。

おかげで、エンジニアは機能実装に、デザイナーはデザイン作業にそれぞれ集中できるようになりました。

3. 表現の幅が広がった

WebGLを活用すれば、WebViewでもリッチな表現を実現できますが、端末環境、開発環境の現状から、使いこなすのはまだ少しハードルが高いのかなと感じていました。Unityの場合は、アニメーションやパーティクルエフェクトなどを手軽に実装でき、Scriptからの制御も容易にできます。

また、前述の通り、デザイナーがUnity上で実装を行うことで、クオリティUPに集中できることも、表現力を上げれられるようになった一因だと感じます。

最後に

今回は、WebView開発からUnity開発に乗り換えてみて、苦労したことと良かったことをざっくりとまとめてみました。

結果としては、メリットの方が大きく、開発チームにとっても、ユーザにとっても良い選択だったのではないかと思っています。特に生産性UPという部分に関しては、想像以上の成果があったように思います。

とはいえ、まだ熟練しているとは言い難いので、今後も精進していきたいところです。

さて、CYBIRDエンジニア Advent Calendar 2017。明日、23日目は@ntrvさんの「GoでZabbixを爆速にしたかった」です。どうぞお楽しみに！