ブラウザプラットフォームの未来について 〜NBPF とは何か〜

image1.png

パートナーの皆様、こんにちは。私はプラットフォーム本部システム部シニアアーキテクトの @zigorou です。

2009年に入社し、Mobage Open Platform の最初のリリースから現在まで一貫してプラットフォームのシステムアーキテクチャ設計を担当しております。昔はコードも書いていましたが、現在は引退しております!


今回は、私がプロジェクトオーナーをしている Next Browser Platform (NBPF) プロジェクトについてご紹介したいと思います。

 

NBPF の背景と概要

さて、昨今各社が Native Application 開発に重点を移しつつある中で各OSで異なる言語で開発する点など多くの苦労があるかと思います。

一方で多少の互換性の問題に目を瞑ればブラウザこそクロスプラットフォーム、クロスデバイスの元祖だと言えます。

様々なアプリケーションに対してプラットフォームとは何かを位置づけるのであれば、Native Application を取り巻く環境を見てみると次のように言えるでしょうか。

 

  • アプリケーションを探して配信する仕組み (Market App)

  • アプリケーションを構築し実行する枠組み (SDK, Server-Side API)

  • デバイス上からアプリケーションを起動したり通知する枠組み (HomeScreen, Remote Notification)

  • ユーザーのアイデンティティの確立 (Google+ SignIn)

  • ユーザー間のコミュニケーションの場 (Chat, Wiki, コミュニティ等)

 

などが候補として挙がって来ると思います。

これらは実に上手くエコシステムとしてワークしています。この点は普段スマートフォンを使っていればすぐに分かる事で、ホームスクリーンやランチャ等から素早く目的のアプリケーションを立ち上げ、欲しいアプリケーションがあればマーケットから探し、アプリケーションの新着情報は Remote Notification によって受け取るなどはすっかりおなじみの姿かと思います。

残念ながら現在の Mobage というブラウザ上でのプラットフォームは Native Application を取り巻くプラットフォームに大きく遅れを取っており、重要な機能が不足していると言えます。

 

さて、Google の Game を取り巻くスタックのイメージを以下に示してみます。

image2.png

Google の場合は以下のような特徴があります。

 

  • Google Account が Gmail によって強く認知されており、また Google Play と強力に紐づいている為、Identity が何かに強く依存することなく存在価値があります

    • IDaaS (IDentity as a Service) としての Authentication/Authorization の仕組みを OpenID Connect 1.0 とする事によって横展開した様々なサービスや外部サービスに対して SSO を提供したりデータアクセスを許可出来るようになっています

  • Google+ が Google Account を用いて利用可能な汎用的なコミュニティとなっています

  • Google Play Game Services においてゲーム開発における汎用的なデータ(Leaderboard, Achievement など)を操作する事が出来る様になっています

  • Google Play アプリによってアプリを配信する仕組みや Device と Google アカウントの橋渡しとして機能しています

 

余談ですが OpenID Connect とは既存の OpenID Authentication 2.0 とは大きく異なり、OAuth 2.0 を安全に「認証 (Authentication)」にも使えるように拡張した概念です。つまり元々の OAuth 2.0 の機能である「認可 (Authorization)」も当然使えて、なおかつ Authorization Server (OpenID Provider) との SSO も提供出来るようになります。

 

翻って現在の Mobage を見てみると次のようになります。

image3.png

敢えて分類するとこのようなスタックになっていますが、元々の Mobage というウェブサイトに引きずられていてスタックが実は分離していません。

NBPF プロジェクトでは Browser をターゲットの中心に据えていますが戦略としては Browser に限定した物ではなく Native Application をも包含する概念で、このスタックの図示で言えば次のような物を提供していきたいと考えています。

image4.png

既存と異なる部分はどこかと言うと、

 

  • 今までの Mobage というウェブサイトに依存した形で機能拡張をするのではなく、Mobage Connect (OpenID Connect) を中心とした疎結合なモデルを用意します

    • Browser 向けには JavaScript SDK を提供して Mobage Connect と Mobage の各種サービス群をより使いやすくしていきます

    • Native Application 向けには Native SDK を提供して同様の仕組みを提供していきます

  • Mobage Game Catalogue を立ち上げ、探したいゲームがすぐに探せ、どのようなゲームなのかが分かるような物を構築していきます

  • Browser の弱点の一つであった Remote Notification を提供する

    • これには Mobage Chat, Mobage のポータルアプリケーション、メール、SMS など様々な提供方式を検討しています

  • Mobage Community をよりゲームに特化した形で提供していきます

 

といった具合でしょうか。我々は一度ゲームに特化した疎結合なコミュニティ、情報集約の場として再構築していきたいと考えています。

 

Mobage JavaScript SDK について

実のところ、昨年末に Mobage Connect は Closed β リリースをしており現在も開発を継続中です。既に本番環境でも稼働しております。

画像は左から Mobage Connect でのログインフォーム、認可同意画面。最後はアイテム決済の画面です。

画像は左から Mobage Connect でのログインフォーム、認可同意画面。最後はアイテム決済の画面です。

またこの Mobage Connect を利用した Mobage とのサービス連携をブラウザ上で提供する為の開発キットとしてMobage JavaScript SDKを近日リリースする予定です。ご期待ください!

さて、この JavaScript SDK ですが既存の Proxy Server モデルと違って次のような特徴を持っています。

 

  • 画面遷移の無いゲームの開発との親和性が高いスマートフォンウェブ向けの新しい開発環境です

  • Proxy Server モデルと異なり、ゲームそのものを独自ドメインで提供可能で、また Mobage にログインしていないユーザーにもゲームを提供する事が可能です

  • Proxy Server モデルより速いアプリケーションを作りやすくなります

  • チャットやリアルタイム通知、リアルタイムバトル等が作りやすいです

 

また JavaScript SDK を用いたタイトルに対してはレギュレーションを緩和し、自由なデザインをブラウザの画面領域全てを用いて提供でき、ホームスクリーンアイコンの作成を支援したり、アイテム購入画面等の Mobage の機能を利用する物に関してもデザインをカスタマイズ可能にしていきます。

回りくどい言い方になってしまいましたが、よりイメージを持つには Facebook 連携したウェブサイトが世間には無数ありますが、Mobage の一部としてゲームが存在するという見え方ではなく、まずゲームがあり、そのゲームが場合によっては Mobage アカウントを用いてサービス連携するような、Facebook 連携したウェブサイトと同じような提供形式になります。

このような提供形式にする事によって、SEO やソーシャルメディア連携なども自由に行う事ができ、既存の Mobage ユーザーだけでなくオーガニックユーザーなども取り込む事が可能です。

 

元々ブラウザはほとんど全ての OS に装備されており、オープンな物です。

インストールレスという特徴から、例えばゲームの紹介ムービーなどでアピールするのではなく、ゲームそのもののリプレイを非 Mobage ユーザーに対しても即座に見せる事ができるはずです。まだまだブラウザの良さについては追求出来るのではないかなと考えています。

 

最後に

今回は概念的な話で終わりとしますが、また次の機会に JavaScript SDK のコンセプトや、今後のブラウザゲームについての想いなどを書いていこうと思っております。