ゲームをXamarinで複数PF向けに同時開発やってもあまり嬉しくないという話

2014年10月25日土曜日

本記事は、日経ソフトウエア2014年12月号に掲載された「Android & iOS アプリ 同時開発」の落ち穂拾い(紙面の都合上カットされたネタ)記事です。

日経ソフトウエア 2014年 12月号

日経BP社 (2014-10-24)

雑誌掲載の記事では、Xamarinの向いたエリアについて挙げました。実は原稿段階では不向きなエリアについても書いていました。これを増補する形で紹介します。

ゲームは割と不向きという話をします。



モバイルの各プラットフォームにおいて、ゲームは比較的特殊な扱いを受けています。
まず、プラットフォームごとに定めるUIガイドラインへの厳密な準拠があまり求められません。
OSコンポーネントの利用、標準的なダイアログボックスの利用、画面要素のレイアウトやカラーリングなど、ほとんどの箇所で通常アプリなら許されないようなことが好き勝手にできます。
それでもAndroidではbackボタンを叩いたらナビゲーション上しかるべき動作をすべき、といった最低限のものはありますが、非常に自由です。

これは、各モバイルプラットフォームがゲームというカテゴリについて「ゲームクリエイターが自身の持つ独自の世界観を表現すること」を尊重しているためと言えます。
 例を2点挙げます(引用元はいずれも iOS ヒューマンインターフェイスガイドライン (pdf))。

1点目: 外観の整合性というくだり
同様に、ゲームなどの没入型のアプリケーションでは、楽しさを約束してくれて、発見のありそうな美しい外観をユーザは期待します。ゲームでは真面目な作業や生産的な作業を実行することは期待されませんが、見た目と体験が一体化していることは期待されます。
 2点目: タスクにあわせてインタフェースをカスタマイズするというくだり
常にカスタマイズの理由を考える。

(中略)

作成するアプリケーションがゲームの場合、または没入型でストーリー駆動型の体験を提供する場合、ユーザは、豊かで美しいグラフィックと革新的なインタラクティブ操作の詰まった独特の世界に入れることを期待します。
あと、過去作の移植なども多いですし。

こういう格好なので、要は「世界観の表現 > OSガイドライン という優先度付けで複数プラットフォームに対して同UIを提供する」というポリシーで進めればXamarinはゲーム開発に向いたプラットフォームのように思えます。

もちろん、現代的なクロスプラットフォーム開発環境であるXamarinは、ゲーム向けのコンポーネントとしてOpenGLなどを利用できますし、ゲーム向けのMonoGameも存在します。
が、これらをがっつり利用していちからゲーム開発をスタートするのはおすすめしません。少なくとも2014年10月24日までの時点では。

これは単純に、他のクロスプラットフォーム対応のゲームエンジンが優れているからです。

2DについてはOpenGLベースのC++環境としてcocos2d-xがあり、3DについてはC#ならUnity、C++ならUnreal Engineといった仕組みがあります。
これらは機能面に加えて現状の利用人口が多く、Web上でも書籍媒体でも参考情報が多いです。
これは単純に正義です。

加えて、Xamarinのビジネス用ライセンスはUnityと比較して決して安いとはいえないものでもあります(cocos2d-xとは比べるまでもありません)。また、iOSとAndroidを扱おうとするとUnity同様両方のライセンスが必要です。

cocos2d-xファミリーのcocos2d-XNAから派生して古いAPI群をばっさりと落としたXamarin系プロジェクトであるCocosSharpも存在はして、盛り上がり前夜ぐらいの感じにはなっているのですが、Web上での情報源が多いとは言えません。cocos2d-xファミリーゆえのファミリー内移行コストがそれなりに低い点を利用してランタイムの成熟を図れると一定の選択肢にはなりそうですが。

このため、ゲームに関してXamarinを利用するメリットのあるパターンは、
  • 既にC#ベースで書かれた多くのコードがあって、それらをなるべくそのまま利用したい場合
  • Unityが対応していない新しい言語仕様や新しいMonoランタイムを駆使したコードを書きたい場合
  • C#以外でコードを書きたくない、C#以外の学習コストが非常に大きい、といったメンバーのみで開発にあたる場合
  • 既にXamarinの利用コストを何らかの形で負担していて、ライセンス面での追加負担が必要ない場合(むしろツールセット共通化のメリットが大きい場合)
  • Visual Studio連携などのXamarin BUSINESS版機能が一切不要でかつ、5人未満の会社・団体内で利用する場合
に限られると考えています。
これは、一般に広くお勧めできるほど広いパイには思えません。 なので割と不向きという話を書きました。


2014年10月24日(Miguel的時間では23日)、状況の変わりそうな大イベントが発生しました。
個人的には、日本で見られる皆既月食並の頻度の大イベントです。
Mono(Xamarin)の、Unreal Engine対応です。

Mono for Unreal Engine



Unreal Engine 4.4.3とXamarin Studio 5.6(alpha)の組み合わせでサクサクとゲーム内の制御をおこなえる格好です。
Unreal Engineは、非常に強力な機能セットを持つがゆえに大変学習コストの高い環境といえます。そのため、既にUnreal Engineへの一定の習熟をしている人がMono for Unreal Engineを利用するための移行コストはcocos2d-x→CocosSharpよりも相対的に低いことが期待できます。それで最新C#を思う存分に使えるなら嬉しすぎてyabai
とりわけ、Mono for Unreal Engineは構造上、UE内部の機能群に対して比較的浅いエリアでアクセスするAPIレイヤを提供するもので、エンジン部分まで深くがっつりと手を入れているCocosSharpのアプローチよりも序盤から安定した動作をすることが期待できます。

あと、Unreal EngineはARM64(64 bit ARM環境)のサポートに対して前向きです。
これは、2015/02/01以降の新規アプリアップロード時に64 bitバイナリを必須化するというAppleの発表(64-bit and iOS 8 Requirements for New Apps)に照らして可能性を感じます。

当然、利用についてはXamarinとUnreal Engine、両方のライセンスが必要です。
しかし、 Unreal Engineが$19/月のサブスクリプションモデルを提供している今、これは非常に強力な選択肢となり得ます。

# まだプレビュー版のダウンロードアクセスをもらえていないので試せていないのですが...
# 「そんなにMono for UEへ興味持つ人いないじゃろ」と思って手動でオペレーションを始めたらめっちゃアクセス権限リクエストが来てパンクしてるという話がMLに流れてますねー

0 件のコメント:

コメントを投稿