大きく変化しつつあります。「マルチプラットフォーム開発に対応したゲームエンジンの普及」と「ゲーム業界以外の企業によるアプリ&サービス開発の拡大」は、その中でも代表的なものでしょう。向けサービスの開始も予定しているアバター・コミュニケーション・サービス「PocoTown(ポコタウン)」も、その一つです。顔やファッション、部屋のインテリアまで、さまざまなパーツをカスタマイズでき、組み合わせ方は100億種類以上。アバターごとに12種類の感情を表現でき、スタンプ感覚で使用することもできます。異なり、匿名性によるサービスなので、利用者の年齢層が幅広く、思いがけない交流が発生する点も特徴です。開発はエンジニアチームのうち、クライアント側で4名、サーバ側で2名のチームからスタートし、後にデザイナーチームが合流。ピーク時で15~6名の体制となり、ローンチまでに9ヶ月程度かかりました。同社はデコメ絵文字アプリの「エモジバ」をはじめ、コミュニティ向けのサービスを中心に展開しており、いわゆる「ゲーム的な」アプリの開発経験は、ほとんどありませんでした。使用したことがないメンバーもいたほどです。した「初めてづくし」の開発で、ツールがどのように貢献したか、お話を伺いました。直感的に使用できたことと、Unity用のアセットプログラムが公開されていたことが導入の決め手もともと「プラットフォームになり得るサービスを作る」という目標で企画がスタートした本プロジェクト。スマートフォンにおける競合が少なかったこともあり、最終的にアバター・コミュニケーション・サービスに着地しました。使ってみたい」という希望が大きかったと言います。あわせてキャラクターアニメーション用のツールも選定が進みました。白羽の矢が立つことに。公開されていたことが、導入の決め手になったと語りました。Unityでアバター・コミュニケーション・サービスを開発すると聞くと、疑問点が浮かぶエンジニアがいるかもしれません。この手のサービスは、大量のパーツの組み合わせで画面が表示されています。何度もオブジェクトを表示させると、いわゆる「ドローコール問題」が発生し、動作が非常に重たくなってしまうからです。松瀬氏はこれを「必要なテクスチャをアトラスにパッキングして回避した」と語りました。本作ではアバターは1024×1024ピクセル、インテリアは2048×2048ピクセルのアトラスにパッキングされ、必要最小限度のドローコールで表示しています。これにより10~15フレーム程度でアバターをアニメーションさせられるようになりました。実際に操作してみると、大量のオブジェクトと相まって、フレームレート以上の表現力が感じられます。Unityを、仕様にあわせてカスタマイズして活用ただし、思いがけないトラブルも発生しました。本作のようなアバター・コミュニケーション・サービスの開発では、ユーザーが任意でいわゆる「きせかえ」をすることができるのが魅力。Unity」のデフォルト状態のコードでは、「きせかえ」のための動的なパーツ差し替えが、機能として実装されていなかったのです。これは、プロジェクト自体の成否にも関係してきます。オープンソースで提供されていた点が功を奏しました。本作では衣服などのアイテムが複数のパーツで構成され、それぞれにユニークIDがふられて、アセットバンドルとしてサーバーに格納されています。これがアバターの状態にあわせてクライアント側に呼び込まれ、アセットバンドルが展開され、その画像をアトラスにパッキングしています。値が設定され、アニメーションデータとして再生される・・・という構造をとっています。ソースコードが改造されました。その上で「完了」ボタンを押すと、改めて一枚のアトラスにパッキングし直されるという仕組みです。ドローコールが非常に多くなりますが、この場面ではアバターをアニメーションさせる必要がないため、この措置は有効でした。改造して、自分たちの用途に合うように活用して欲しい」とコメントされました。このやり方ではクライアント上でパーツのグラフィックデータを展開する際に、メモリを消費しがちです。現在は問題ありませんが、将来においてはわかりません。そのため、今後は「きせかえ」の処理をすべてサーバ上で行い、サーバ側でアトラスをパッキングして、クライアント側に転送する仕組みも検討されています。アニメーションデータが収納されるXMLファイルに、ユーザーデータ領域が設定されており、任意の文字列を設定できます。これにより、アバターの動きにあわせてフラグを設定し、プログラム側で読み取って、アニメーションの切り替えなどを行うことが可能です。本作においても、アバターがベッドに横たわる際に、ベッドに近づいたタイミングで掛け布団を消し、アバターが横たわったところで掛け布団を表示する、などの演出が行われています。一方でサーバ側では、また違った問題が発生しました。前述の通り、本サービスではアバターが泣いたり、笑ったりと、多彩な感情表現を見せる点が特徴です。この表情はアバターのアニメーションデータにもとづいて作成されています。おけるアニメーションデータは、パラパラアニメのようにフレーム毎の画像データが存在するわけではなく、パーツごとの動きのデータで指定されています。そのため、標準の状態では個々の画像をフレーム数などで指定することができず、エンジニアが複雑な計算を行ってエクスポートする必要があるのです。佳氏は「当初は計算で出力しようとしたが、うまくいかず、目視で全データを指定した」と語ります。必要なデータ数は約1300個にもおよび、丸二日かかりました。アニメーションデータの画像サイズが変更になるなど、仕様が二転三転したため、そのたびに目視でデータベースの修正も行ったと言います。本サービスの開発中に、これを手軽に実施する機能が加わりました。この中にはアニメーションデータをベイクした状態で出力できるツールがあります。これを使用すれば、「特定キャラクターの、何フレーム目の画像データ」という指定が簡単にできるのです。ツールはC#ではなく、C++で記述されている点がネック。それでも皆木氏は「C++の学習コストを払ってでも、このツールを活用すれば良かった。目視による力業で作業が完結してしまったため、サポートに問い合わせる発想がなかった」と語りました。これらのアップデート情報は現在、メールニュースを中心に通知されています。本件のように「開発サイドでの見落とし」が発生しがちなのも事実。活用し積極的に告知を進めていくので、注目してもらいたいと述べられました。実際にアニメーションデータを作成した、デザイナー側の声もご紹介しましょう。中山乃菜さんもその一人。プロデューサーでしたが、スタッフが不足していたため、急遽デザイナーとして活躍することになりました。触ったことがなかった」ほどでしたが、数十分のレクチャーでアニメーションが作れるようになったと語ります。読み込み、アニメーションデータを作成して、クライアント側のエンジニアに渡す・・・これが主なワークフローです。「最初はパラパラアニメを作るものだとばかり思っていたので、フレームの補完機能に感動しました」という中山さん。使用経験者から機能不足を指摘されることもありました。マスク機能がない、などはその一つです。使用することができません。浅井氏はマスク機能については将来的な機能追加を検討していると説明しました。SDK」からとのことでした。今後のアップデートに期待したいところです。ヘルプの機能充実についても要望が上がりました。中山さん自身、基礎的な機能は独学で習得したそうです。学習コストの低さを裏付けるものでもありますが、そんな中山さんでも「もっと良いやり方があるのではないか」と不安に感じることもあるそうです。中でも「軽いアニメーションデータの作り方」のノウハウに興味があると言います。一般的に動きをつけるうえで、キーフレームの数が増えるほどデータが重くなります。少ないキーフレームで魅力的な動きを見せるかは、デザイナーの腕の見せどころでしょう。ヘルプ機能に盛り込みにくいのも事実。浅井氏も動画やドキュメントなどで、ノウハウを提示していきたいと語りました。「開発する側」と「使う側」との情報共有の必要性このように紆余曲折がありながらも、無事リリースされた「PocoTown」。未経験者も参加しての開発」という、初めてづくしの挑戦となりました。逆にツールやミドルウェア類の充実によって、こうした企業が新たに参入し、コンテンツやサービスが拡充したことは、エンドユーザーにとって歓迎すべきことでしょう。一方でツールやミドルウェアの活用法は千差万別です。そのためサポート類の充実もさることながら、企業にとって必要な部分はクロースドにして、必要でない部分はオープンソースで公開したり、開発者コミュニティ間での情報共有が、ますます必要になっています。ツールやミドルウェアメーカーにとって、開発者コミュニティの育成やマネジメントが、製品の完成度と同じか、それ以上に重要になりつつあるのです。した採用事例レポートの公開も、そうした取り組みの一つだと言えそうです。関するお問い合わせはこちらからどうぞ。