フィーチャーフォンからのゲームの移行

フィーチャーフォン向けのソーシャルゲームを、スマートフォン (iOS, Android 系デバイス) へ適応させるためのガイドです。

スマートフォン対応の流れ

既存のフィーチャーフォンのアプリケーションをスマートフォン対応するには以下の対応が必要になります。

  • ユーザーインターフェース対応
  • インタラクティブアニメーションコンテンツ対応
  • デバイス対応

ユーザインターフェース対応

ユーザビリティやデザインの対応について解説します。

ユーザビリティへの配慮

リンクの修正

タッチスクリーンでの操作となるため、リンクの間隔が狭いとリンクが押しにくくなる場合があります。下記の対応をご検討ください。

  • リンク間の間隔を広げる
  • リンクをボタン化する

アクセスキーの対応

スマートフォンはフィーチャーフォンのアクセスキーに対応していません。
アクセスキーに関するコード記述、絵文字、画像などを除去することをご検討ください。

高解像度画像への差し替え検討

スマートフォン はフィーチャーフォンと比べると、画面解像度が高くなっています。
(例)

iPad

w768 x h1024

Galaxy Tab SC-01C

w600 x h1024

Galaxy Tab SC-01D

w1280 x h800

iPhone 4

w640 x h960

iPhone 3GS

w320 x h480

docomo Galaxy S

w480 x h800

au IS03

w640 x h960

フィーチャーフォン

w240, w220 が主流

フィーチャーフォンで使ってきた画像をそのまま流用することはできますが、スマートフォンで見るとグラフィックの粗さが目立ちます。
このため、各種グラフィック素材について高解像度の画像を準備し、フィーチャーフォンと使い分けることをご検討ください。
ただし、画像の解像度を上げると、その分ファイルサイズも大きくなります。
(弊社タイトルでは ImageOptim を使うなどして PNG 画像の容量最適化を行なっております)
iPhone4 や Android の一部機種など、高解像度表示に対応したデバイスに対しては更に出し分けを行うとデバイスの性能を活かしたより美麗な画像を提供できます。

インタラクティブアニメーションコンテンツ対応

Flash コンテンツについての対応について解説します。
フィーチャーフォンにおいて Flash を利用したアニメーションコンテンツを採用していた場合、スマートフォンにおいては iOS, Android に合わせた対応が必要です。
下記に、各デバイスと OS の Flash, アニメーション GIF のサポート状況を記します。

 

iOS

Andorid

Flash

非対応のため表示されない

OS 2.1: Flash Player Lite 4 搭載(一部端末を除く)OS 2.2: Flash Player 10 搭載(一部端末を除く)

アニメーションGIF

表示可能

OS 1.6, OS 2.1: 表示されるがアニメーションしないOS 2.2: 表示可能

Android への対応

Android では Flash が利用可能なため、次の二つの方向性が考えられます。

  • Flash を Android 用に移植
    • 対応は容易で、シンプルなアニメーションFlashであれば、改修コードは3〜5行程度
  • Flash 以外の方式 JavaScript + HTML化, HTML5 Canvas, CSS3 Animation など)
    • 対応はそれなりの開発工数が必要

Flash を Android 用に移植

Flash を Android 用に移植する際のポイントを記します。

  • Flash の タッチ化
    • on(keyPress "<Enter>") などのイベントについて、ボタンオブジェクトに変更またはレイヤーを重ねた上で、on (press) イベントで実行できるようにします
      ただし下記のような様々な要因で表示異常や表示の差が生じることを確認しています。
  • 解像度の違いによる影響
  • OS の違いによる影響
  • 表示方式 - インライン/全画面の違いによる影響
  • 利用する合成エンジンの影響
  • HTTP Response の内容による影響(ブラウザバグと考えられる)
  • 一つのFlash 内に含める MovieClip や Button などのインスタンス数の影響

Flash 以外の方式

Flash 以外の方式を選択する際のポイントを記します。

  • JavaScript + HTML化
    • iOS と兼用のコードにする場合、アニメーションのスピードを [ デバイス × OS ] 別に制御できるような機構をご検討ください。『ある機種/OSではアニメーションが早すぎる/アクションがとても難しい』といったことが生じるためです。
  • CSS3 Animation化
    • Sencha Animator にて Flash アニメーションを再制作することで、同等のアニメーションを CSS3 により実現することが可能です。

iOS への対応

Flash は利用できないため、代替案として次の選択肢が考えられます。
どういった対応が最適であるかは、開発コストやゲーム性によって違いがありますので選定が必要となります。

ExGameを利用する

swfファイルをHTML5に変換しながら再生する JavaScript ライブラリーです。Android 向けにタッチ対応させた swf を与える事でそのまま容易に iOS 対応可能です。

JavaScript + HTML化

プログラマにより、Flash のアニメーションを JavaScript コードで実装します。

HTML5 Canvas化

HTML5 からサポートされている Canvas の機能を利用する選択肢があります。

CSS3 Animation化

Sencha Animator で Flash アニメーションを再制作することで、同等のアニメーションを CSS3 により実現することが可能です。

ExGameについて

Flash を iOS 上でも実行再生するための、JavaScript で記述された SWF 実行エンジンです。
本エンジンを使うことでFlash Lite1.1で開発されたSWFコンテンツをそのまま iOS 上で実行でき、
既存資産の活用により開発工数やサーバコストを大幅に削減して iOS 向けに既存フィーチャーフォンゲームを適応させ、提供することが可能となります。
詳しくは、オプションサービス のExGameのセクションを参照してください。

参考事例

弊社タイトルでは主に下記のような対応方法を採用しております。

  1. Android 向けに Flash を改修する
  2. ExGame を用いて Android 対応 Flash を iOS に提供する
    Android においては フィーチャーフォン 用の Flash に透過ボタンを重ねることで容易にタッチ対応が行なえ、より自然な操作体感を Android ユーザに提供できます。
    またベクタデータをそのまま描画処理出来る、機種依存トラブルが少なくなるなど、Android において ExGame より Adobe Flash Player を用いる方が相性良い結果が出ております。
    iOS においては GPU アクセラレーションが使える事からも ExGame が効率よく動作し、特に Android 向けにタッチ対応させた Flash であれば工数少なく、こちらも自然な操作体感を iOS ユーザに提供できます。

デバイス対応

iOS および Android の OS や機種の違いによりどういった実装上の工夫が必要か解説します。

Android 系

AndroidOSバージョンと機種のバリエーション

  • OS : 4.0, 3.2, 3.1, 3.0, 2.3, 2.2, 2.1, 1.6
  • AndroidOS バージョンによる違い
    • HTMLでの違いはほぼありませんが CSS, JavaScript については違いがあるため、異なる OS バージョンでの検証は必須になります。

iOS 系

iOSバージョンと機種のバリエーション

  • OS バージョン : 5.0, 4.3, 4.2.1, 4.1.1, 4.0, 3.1.3, ...
  • 機種 : iPhone4S, iPhone4, iPhone 3GS, iPhone 3G, iPod Touch, iPad
  • iOS バージョンによる違い
    • iOS5 は iOS4 に比べ JavaScript, CSS, Canvas 等のアニメーションに関わる部分が高速化されており、より優れた品質での提供が可能となっています。
    • iOS 対応を考える際には iOS4 と iOS5 に分け、特にユーザの伸びが期待出来る後者を注意しながら進めると良い結果が期待できます。

複数デバイス向けのゲーム運用方法

フィーチャーフォンで運用してきたアプリをスマートフォンに移植する際、スマートフォン向けに最適化し過ぎるとフィーチャーフォンとスマートフォンの両デバイス向けの開発・改修が発生するため、開発・運用コストがかさみます。
最適化すべきポイントについては、どこまでを共通とし、どこまでを異なるものにするかを見極め今後のスマートフォン利用者数などを考慮する必要があります。
(例)

スマートフォン向けに最大限の最適化を実施するページ

アプリトップページ、マイページ、バトル直前ページ

3ページ

中程度の最適化を実施するページ

ミッション一覧、ミッション実行、プロフィールページ、他

5ページ程度

その他 考慮点

  • デバイスにより Retina の対応、非対応がございます。Retina 対応デバイス向けに画像素材を用意する、ExGame 設定をチューニングする事でユーザにより美麗なアニメーションを提供できるようになります。
  • 横幅を size 属性で指定しているとデザインの崩れが起きやすいため、リキッドレイアウトの採用をお勧め致します。iPad と iPhone の表示解像度差への対応、また更に多様な Android デバイスへの対応も考え合わせるとリキッドレイアウトの採用が効率良い選択になります。
  • もっとも描画処理が重い組み合わせは iPhone4 + iOS4 です。これはスクリーン解像度が 640x960 と高く、また iOS4 では GPU アクセラレーションの適用が限定されている等の理由から描画処理が iOS5 に劣るためです。動作確認、チューニング等のご参考にお役立て下さい。

セキュリティ対応

セキュリティ上の配慮すべきポイントを解説します。

通信の制約解除と端末の個体識別番号について

スマートフォンはPCに近いものとして捉え、PC 向け Web アプリケーションを作成する場合と同等のセキュリティ上の配慮やユーザ認証の仕組みを検討する必要があります。
セキュリティ上の配慮に関わるポイントの一部を、対比して例示します。

項目

フィーチャーフォン

スマートフォン

通信経路

キャリア公表のIPアドレスに限られ、それ以外の通信は公衆網と見なすことができる

3G回線利用時はキャリアIPだが、無線LAN利用時は公衆網

個体識別番号

各キャリアの仕様で送出され、ユーザアカウントの識別に利用できる(かんたんログイン等)

個体識別番号と呼べるものは事実上なく、類似のものはあるがブラウザからの通信時は送出されない。

UA偽装

不可能

容易

HTMLソースの表示

困難

可能

通信のキャプチャ

困難

可能

同時複数セッション

タブ方式ブラウザを搭載した端末では可能だが、同時タイミングは実質不可能

二台の端末でほぼ同時に操作が可能

通信パラメータの改ざん

しにくい - ロボットプログラムを作っても Webアプリケーション側で通信経路判定している場合は拒絶することが可能

アドレスバーを操作しやすく容易であり、通信経路が自由な公衆網のためロボットプログラムの開発が可能

Cookie

全端末ではないが利用可能

利用可能

Cookie漏洩

困難

PC 向けなどの一般的な Web アプリケーションと同等の脅威がある

XSS(クロスサイトスクリプティング)

JavaScript が使える端末が限られている

JavaScript は自由に使えるため、完全な対策が必要

セキュリティ上の観点から次の点を考慮してください。

  • PC向けWebアプリケーション開発と同等の視点でセキュリティ上の欠陥が無いか検討し、脆弱性を徹底して無くす。
  • ロボットプログラムなどの自動処理をブロックする仕組みを導入する。
  • Flash内で重要な計算をしない等、クライアントサイドでの重要なビジネスロジックを排除する。
    次により、詳細を解説します。

Webアプリケーションの脆弱性への対処

  • XSS(クロスサイトスクリプティング), CSRF(クロスサイトリクエストフォージェリ) などのセキュリティ上の問題をプログラムコードから排除する。
  • 開発完了後は、脆弱性検査を実施することを強くお勧めします。外部専門家への委託や専門ソフトの利用も考えられます。

ロボットプログラムなどの自動処理をブロック

まず「リクエストを連続的・自動的に処理できると、ユーザにとって優位性が生じる機能は何か?」という観点から、対処すべき機能を洗い出してください。
(例)

  • ミッションの進行を自動化 → あっという間にゲームを進められる
  • ウィンクを自動化 → 連携ポイントを一気に溜めることができる
    それがゲームにとってリスクであると判断した場合、その機能やアプリケーション全体を対象に、次のような対処方法をご検討ください。
  • システム上のリクエスト制限
    • window.Touch 等を利用して JavaScript でスマートフォンデバイスであるかどうかを確認する。
    • 連続したリクエストのブロック
      • (例1)同一のユーザからアプリケーションサーバに対して1秒間に3リクエスト受け取ったら、不正や攻撃の可能性を疑い、一定時間アクセスをブロックする。
      • (例2)同一のユーザから、同一の URI (パラメータ部を除く) に対して1秒間に3リクエスト受け取ったら、不正や攻撃の可能性を疑い、一定時間アクセスをブロックする。
    • CAPTCHAの導入
      • (例)ウィンクコメント入力時、一定の確率で CAPTCHA 認証を実施するように実装する。
    • ゲーム性の変更
      • (例)ウィンクは仲間にしか実行できないよう仕様を変更する。

クライアントサイドでの重要なビジネスロジックの排除

例えば Flash 内で課金・決済に関わる処理を行うようなコンテンツは、悪意のあるユーザに Flash コンテンツをダウンロード・解析され、重大なリスクを追う可能性があります。
クライアントサイドに重要なビジネスロジックが存在しないか確認してください。
(例)
HTML5 で作りなおす場合、ボス戦のロジック解析防御のため、従来のボス戦を Ajax ベースのアプリケーションに改修し、演算処理をクライアント側(Flash)からサーバサイドへ移しました。

検証

基本的な検証

  • フィーチャーフォンと スマートフォン でコードを共有している場合は、フィーチャーフォンの検証ももおこなう必要があります。
  • セキュリティの項で説明させていただいたように、脆弱性検査を実施することを強く推奨します。

体感速度について

通信や処理の遅さは、ユーザに対してテンポのよいゲームが提供できないばかりか、ストレスになりかねません。通信においてもアプリケーションにおいても、すばやい動作が求められます。
スマートフォン端末を無線 LAN に接続した状態で開発・検証していると、通信速度の遅さに気づかない場合があります。3G 回線だと思いのほか遅くなる場合があります。
このため、無線 LAN 利用を OFF にして、3G 回線での検証も必要です。
特にスマートフォンのブラウザでは、ブラウザキャッシュが効きます。HTTP Response Status の制御により、ブラウザキャッシュを活用することをご検討ください。特に Cache-Control,Expire など。

更新履歴

  • 2013/03/28
    • ドキュメント移行

PREVIOUS

リクエストに関するパフォーマンスガイドライン

NEXT

リーダーボード機能の使い方