クライアントサイドからみたネイティブアプリ開発のポイント
ここでスピーカーが白倉氏に交代し、クライアントサイドからのネイティブアプリ開発の工夫点などが語られた。
従来のWebアプリ開発では、画面の遷移と通信のタイミングが絡み、サーバだけで完結してしまう処理のため、1人で1機能を進めていく形になっている。
一方、ネイティブアプリの場合は、通信と表示の遷移がすごく複雑になる。1画面で1通信という切り分けができないため、通信と表示で役割分担をして開発が行われている。
第1プロダクション部 白倉悠祐氏
開発環境
今回のネイティブアプリにおけるクライアントサイドの開発環境だが、まず、開発にはUnityを使用している。世界的に実績もあり、グリー社内でも採用事例が多くある。また、GREE Platform、オープンソースであるLightweight SWF（通称LWF）も対応しており、利用されている。
GREE Unity SDKは、GREEをプラットフォームとしてアプリケーションサービスを提供する仕組みのUnity対応版になる。Unity上で使いやすいようにプラグインをC#でラップして使用する仕組みになっている。LWFは、既存のFlashプレイヤーに近い挙動によって、アニメーションやユーザインターフェースを作成可能となっている。
開発スタイル
次に開発スタイル。今回事例として挙げたプロジェクトでは、サーバとのやり取りを主に担当している部分をバックエンド、ユーザインターフェースや遷移の管理を担当している部分をフロントエンドと呼び、役割分担が行われている。
まずフロントエンドは、インターフェースの表示、表示タイミング、ゲーム内の演出といった仕様の細かい部分も多く、バックエンドに比べるとより多くの人数での作業となる。また、レビュー時や運用開始後には、機能追加などの要望が多く寄せられる。その際、インターフェース部分や遷移というのは、目に見える部分が主となるので仕様や処理が複雑になってしまう。それを複数人のエンジニアで作業を行うことになるため、どの遷移がどう絡んでいるのかを把握しながら作業するのは難しい。
さらに、プロジェクトのメンバーが常に同じとは限らない。運用に入ったら新規開発時とは異なり規模が小さくなったり、時がたつことによってメンバーが変わったりする可能性もある。
遷移図とコードの自動作成
そこで今回、白倉氏のプロジェクトではちょっとした工夫、『遷移図とコードの自動生成』を行った。期待される効果は、『ドキュメントの管理が楽になる』『ある程度コードが統一される』『新規メンバーの教育が楽になる』の3つになる。
自動生成のために考えたことは『共通項として、どういうものが自動で生成できるのか』『どのレベルのものまでなのか』『どういったものなら使いやすいのか』。
状態の遷移というのは、処理があり、条件があり、次の処理へと続いていく。中身の処理はもちろん異なるが、処理をする部分と遷移部分は同じような処理となる。この処理と条件を決まったフォーマットで記述することで、コードと遷移図を自動生成するようにした。
記述するフォーマットにはYAMLを使用した。インデントを使って階層を表すので、読みやすく分かりやすいからだ。遷移図の描画には、Graphvizを利用している。GraphivizとはDOTファイルを生成・編集するツール群で、rubyを使用していればruby-graphvizとして提供されている。コンバータはrubyで作成した。機能単位でYAMLにまとめコンバートすることで、機能単位での分割も可能だ。Unityで使用するために、いくつかC#のフォーマットを用意し、YAMLの情報をもとにコードを生成している。
このYAMLはStart、Main、Game、Doneの4つの状態から成る。Mainからは、スタートボタンが押されたときにGameに状態遷移し、終了したときにDoneに状態遷移する。Game中は、ゲームオーバーになるとMainの状態に変わる。これをコンバータにかけてみると、図のような遷移図ができあがる。そして指定したディレクトリに状態遷移用のコードができる。
白倉氏は最後に「自動生成は導入までの障壁が高かったが、得られるものが多かった」とまとめ、セッションを閉じた。
