Google Developer Day 2010レポート

9/28に東京国際フォーラムで行われたGoogle Developers Day 2010に参加してきました。


最初に、イベントに参加してみて思ったことを少し書きます。

参加登録時に挑戦したDevQuizが楽しく、イベント前から開発者にGoogleテクノロジに関心をもたせてしまう仕掛けがすばらしいと思いました。

イベント当日は、ちょっと人数が多すぎて身動きがとりにくかったのと、タイトなスケジュール、まとまり過ぎてる発表内容で、私が勝手に期待していた「開発者同士の意見交換の場」ではなかったのが(個人的には)残念。これまでGoogleテクノロジ関係のイベントは参加したことの無い私の問題かもしれないのですが、入りにくい空気も若干ありました。(これを機に、GTUG界隈にも顔を出すようにしたいですが・・・。)

Googleのテクノロジーは誰でも使えるし企業自体がプロセスを公にしててオープンな印象を受けますが、Linux Symposiumみたいな参加者全員が当事者(そのテクノロジーの作り手)であるオープンソースコミュニティの集まりとは大きく違っていて、あくまでも企業イベントなのだと感じました。メインプレイヤーはGoogle、参加者はGoogleテクノロジーAPIユーザーであると考えると納得がいきます。作ってるものの目的が違うので比較するのも意味が無いことなのですが、オープンさの度合いには大きな開きを感じた一日でした。

初めての場ということもあり、自分が当初思い描いていた期待とのギャップはいろいろ感じたものの、Googleのやろうとしてることは面白いし価値があると思います。
それを支えるテクノロジーも面白いです。進化のスピードもすごい。
GoogleDeveloperDayは、Googleのテクノロジーを知って、使ってみて、どうビジネスにつなげていくかを考える場としては、とても充実してました。
Googleテクノロジーを使ってる技術者は是非参加しておきたいイベントだと思います。

今回、基調講演で取り上げられていたテーマは、大きく分けると以下の4つです。

後のレポートで詳細なメモを書きますが、ここでは各テーマの感想をまとめてみました。

HTML5 & Chrome

Webは、HTML5の登場で、これまでの「できる」「できない」という議論から、より快適で実用的なものが要求されてくる。そして、それを実現するためにはテクノロジーの進化が必要。開発者もこれを知った上で活用しなければならない。
GoogleHTML5を明確に強く推していってくれるのは心強い。Chromeのパフォーマンスと、開発ツールの充実を進めているのも良いニュースで、それを聞けたのは大きな収穫だったと思う。

クラウドプラットフォーム(GoogleAppEngine)

GoogleAppEngineはメンテナンスやライセンス、テストなど、プロダクト・サービスを作るうえで大きなウェイトを占めていた悩み事を、テクノロジーによって減らして行くというアプローチ。マネージャやエンジニアは、本当のサービス・製品価値の向上に時間を使える。今回のツールのデモでも、革新性の一端が垣間見れたように思います。

入力技術の進化(Google日本語入力

入力は重要なインタフェースにも関わらず、これまでほとんどイノベーションが起こらなかったという謎の分野。Google日本語入力、音声入力は、現時点でのベータ版でも革新性を感じさせるものだし、今回の発表内容を聞いているだけでも、今後の進化に期待しても良いと思いました。

Life cycle of developers

私がGoogleに良いイメージを持っているとすれば、エンジニアの生活を革新的な技術と同じレベルで重点テーマに挙げてくるところなのだと思います。食事が無料だとか、20%ルールとかいろいろと聞きますが、実際、Googleのエンジニアのみなさんはどう考えているのかは知る機会がありませんでした。今回「Googleエンジニアの日常」というセッションがあり、この関心のあったテーマについて、直接話を聞くことができました。
開発の障壁を取り除き、エンジニアの生産性を上げて、プロダクトの価値を最大化するための工夫がいたるところで感じられます。日頃から、私たちが取り組んでいることの、さらに進んだ実践事例の一つを知ることができました。

その他

メインテーマではないものの、個人的には気になっていた「プログラミング言語Go」のお話も聴けました。コードのメモリ展開のメカニズムなど、内部構造も織り交ぜながらのお話で、Goの言語としてのポジションが少し読み取れました。システム記述言語、大規模開発言語は革新が望まれる分野で、Goはそこを目指せる。今後、いじってみたい言語としてとても興味を持てました。


以下、受講した各セッションの詳細メモ(拾った情報を片っ端から。)を書いていきます。

GDD2010:基調講演

GoogleDeveloperDay2010の基調講演の全メモです。

Webの話

及川さん登場

  • 北米のネット利用時間の推移
    • ラジオ、テレビ、新聞に費やす時間の減少の一方、ネット利用時間は117%に増加している。
    • インターネットはライフラインを支える存在になってきている。
  • Web標準の推移
    • Webがアプリケーション化している。
    • こうした要求にこたえたのがHTML5
    • 特定のベンダーの独自技術ではなくopenな技術が核となる。
    • 囲い込みもないし、技術の組み合わせによる新しいサービスが生まれる。
HTML5

慶応大学 一色さん登場(W3Cということで。)。

  • 慶応がMITなどがホストとして参加しているW3Cコンソーシアムをやってるが、一色さんがそこの長をしている。
  • HTML5でWebが大きく変わってきている。
  • W3Cは世界に400社、ボランティアで1800人が参加。世界中で使えるWeb標準を書く、みんなで育てる。
  • HTML5
    • 観るWebからアプリケーションプラットフォームに
    • ビジネスが根幹から変わる。
    • 我々はいま、その場に立っている。
    • このイノベーションの上でビジネスを組んでいってほしい
  • GoogleWeb標準に100人ぐらいのエンジニアを送り込んでいる
    • ブラウザはどんどんHTML5を組み込んでいる。

再び、及川さん登場

  • 機能を持っているかどうかではなく、次のフェイズに進んでいる。
  • パフォーマンス、実用化のフェイズへ。
  • デモ
    • IEのテスト用(2D)コンテンツ
    • 熱帯魚を増やしていくデモ
    • Chrome標準で250匹表示させると、FPSが7〜8に落ちてしまう。
    • これをGPUを使うことで、20以上になる。
    • GPUアクセラレーションをブラウザに対応させている。カナリービルド、stableビルドに反映していく。
    • 3次元ではより効果を発揮する。
      • 3Dの魚デモ
      • →このデモのように、ただできる(機能)ではなく、パフォーマンス・実用性に、フェイズが変わることで、新しいものが作れるようになっているのがわかります。

Googleエンジニアの北村さんがデモに登場。

  • Googleのホーム画面を90度回転
    • CSSスタイルシートで簡単にできる。
    • Macのモーションセンサーで、画面をズームイン、ズームアウト、傾き検知
    • 検索も普通にできる。用途はみなさんで考えましょう!
  • ボイスサーチ
  • HTML5 studio
    • HTML5のデモサイト
    • ローカルファイルアクセスのデモ
    • JavaScriptでローカルファイルに簡単にアクセス、写真のサムネイルを表示するデモを行う。
  • 従来のブラウザはマイクにアクセスするのでさえプラグインが必要だった。
    • 音声認識エンジンの実装には不可知。サーバー、クライアント側どちらの実装でも良い
    • @speech
  • ファイルアクセス
    • これまではWebストレージとして持っていたがローカルファイルへのアクセスを実現できる。これまでにないWebアプリケーションが実現できる
Chrome Web Store
  • Googleの今後の課題と提案
    • 見つけやすさ
      • どうやって、ユーザーは魅力的なサイトに行き着くのか?口コミなどもあるが、現状、確立した手段がない。Windowsのアプリは、量販店に行って目的のものを買える。年賀状アプリケーションなど。
    • 再アクセスのしやすさ
      • よかったアプリケーションをもう一度使うには?
  • Chrome Web Store
    • アプリケーションを探しやすく
    • インストールという概念
    • 無償アプリケーション、有償アプリケーション
    • 開発者向けプレビューをすでに提供
  • インストールできる
  • GoogleChromeDeveloperビルドではWebアプリケーションのアイコンが表示される
  • 「FIABEE」のデモ
    • オンラインストレージサービス
    • いま、Windows用、iphone用のクライアントソフトを出しているが、Chrome用のアプリを開発している。
    • オンライン上に保存しているファイルのサムネイルを表示
    • クリックしてプレビュー、
    • 動画のプレビューも可能。一度キャッシュしたものはすぐに再生できる。
    • HTML5のWebSQLデータベースを使った機能。
    • Webで表示された画像で気に入った画像を保存するには、ドラッグ&ドロップして、
    • Webストレージ上に保存できる。
    • アンインストールもメニューから用意にできる。
HTML5
  • オープンプラットフォームによるイノベーション
  • できる、できないの議論ではなく、妥協無く機能を実現する段階にある
  • ChromeWebStoreによるWebアプリケーションの新たな配信
Android

ティム・ブレイさん(Androidのえらい人)登場。

  • 概要
    • 何故、Androidなのか、googleが注力しているのか?
  • なぜモバイルなのか?
    • 6.8 billion humans
    • 4.1 billion mobile debice
    • PCベースのアクセスをモバイルからのアクセスが超えた。モバイルに大きな機会がある
    • AOLに比べて、i-modeのアクセスが増加ペースを上回った。
    • iOSはさらにその5倍以上の伸び率でアクセスが増えた。
    • Androidは、今のところiOSの伸びを上回っている。
    • モバイルの大きな可能性が読めるデータを提示した。
    • GoogleI/Oで展示されたAndroid端末
      • 90デバイス
      • 21のマニュファクチャー
      • 50キャリア
      • 49カ国
    • 来年の今頃にはもっと標準的な端末になるだろう
  • Androidの今後の期待できるアプリケーションのひとつがゲームだ
    • スペクタクルソウルズを「Samsung Galaxy Tab」でデモ。
  • Androidマーケットの新しい機能実装が続いている。
    • 音声検索
    • similerTab
    • AppMarketのコメント、エラー報告
    • ライセンシングサーバー →ライセンスチェック
  • Cloud to device messaging
    • Chrome to phoneインタフェース
    • 電話番号をクリックしたら、電話に転送する
  • Enterprise features
  • better security
  • remote wipe
  • MS exchange service
  • フォント
    • モトヤフォント
      • 無償提供された品位の良いフォントに入れ替え、日本語での高品位な表示を提供。
  • 日本のアプリ数は世界で5位、ダウンロード数は世界で2位
GoogleAppEngine
  • エンジニアが、システムを作るのに収集できるサービス提供
    • Easy to build,
    • easy to maintain,
    • easy to scale
  • App engine growing
    • 90K developers
    • 130K apps active every week
    • 5.5B pageview/week
    • 日本Appエンジンのアクセス数が世界2位
  • 成功事例
  • エコポイントシステム
    • ITマネージャの悩み
      • 製品管理、トラフィック、ライセンス・・・・。考えることがたくさんある。これを、AppEngineが支える。
    • DomainConsole
      • アプリケーションを一箇所で管理
    • IT予算の60%は保守である。
      • 新しい開発や、イノベーションに費やされていない。これら、オーバーヘッドを減らしていきたい
  • Googleは保守をサポートしたい。
  • Roadmap
    • full mapreduce
    • datasotore dump and restore
    • background servers reserved instance
    • realtime channel api
    • build-in OAuth & openID
    • Make you smile :)
  • Javapnese Developer community
クラウド時代のポータビリティ
  • データポータビリティ
  • APPポータビリティ
    • オープンスタンダードにこだわる
    • 別のクラウド環境への移行も容易にする。
  • Google Web Toolkit&SpringRoo


ベンさん登場

・SpringRooのGoogleAppEngineの活用デモ
 →GWTを使って、基本的なパッケージを導入していくことで、
  数コマンドでWebアプリケーションをサクッと作るデモ


Google日本語入力

及川さん登場

  • Input
    • Webアプリケーションが増えていくと、ユーザーとのインタラクションが増えてくる。ユーザーはキーボードや音声を使ってデータを入力していく。この入力にイノベーションの可能性が存在する
    • 日本語入力、非英語圏に関して、必要な機能が提供できているだろうか?
    • 今回のイベントでは、Google日本語入力の開発背景を説明した冊子を配布
  • 変換効率の高い、日本語入力を、他の分野にも拡大したい
  • Google transliteration」
      • まずはバックエンド公開。フロントエンドのJavaScriptエンジンは後日公開。
    • Google transliterationデモ
    • TransliterationAPI
    • GETを発行して、その結果をとってくる、シンプルな使い方。
  • Google日本語入力テクニカルイベント
    • コードリーディングを含めたイベント
    • 10/23開催(10/10締め切り)
  • クラウドは、単にデータセンターとして使うのではなく、さらに踏み込んだ機能を提供する。
GoogleDeveloeprDayについて

石原さん登場

  • DevQuiz
    • Applied: 4904
    • Passed: 1481
    • Best Score:41.94
    • Pass Score:23.22(SuperHacker)
  • Life cycle of developers
    • Googleでは、コードを書くだけではなく、レビューを通らなければ、世に出すことはない。コードだけではなく、コメントをいかにわかりやすくするのかが重視される。これを厳密にやることで、Googleはプロダクトの価値を上げている。
  • 潜在的に可能性のある人を招待するために、SuperHacker以外の枠を設けた。
  • GTUGなどのコミュニティによってGDDは支えられている。

GDD2010:プログラミング言語 Go

プログラミング言語 Go
鵜飼 文敏

Go言語とは何か
  • 2009年11月10日にオープンソース公開
    • コントリビュートしてるのは125名(2010/09)
  • 特徴

主流なプログラミング言語C++Java)、
ライトウェイト言語(Python,Rubyなど)

これらの良い点を取り入れた特徴

    • 静的片付け、型安全
    • ダックタイピング、
    • 短いコンパイル時間
    • 大規模プログラミング可能
    • ネットワーキング
    • マルチコア
godentaku - Goで作った電卓

四則演算のパッケージはすでに揃っているが、あえて処理を書くことでプログラムを理解する。

  • 入力:bufio

func (*Reader) ReadBytes


packageを調べれば、こうした関数が調べれる。
godocというドキュメント
引数の型などを確認できる。


複数の値を返せるのがgoの特徴。

  • 出力:fmt

func Printf


いわゆるprintf
"%v"与えられた変数に応じた最適な表示を行うフォーマット指定

% 6g main.go  →64bit用コンパイル


6.out
実行バイナリ

  • int
    • ビット長を明確に指定しないと計算してくれない。
      • 違う型でも演算してしまって起こるエラーを防ぐため
  • sliceは配列に使うポインタ
    • 長さを変えられる配列

nbuf = buf[1:]


   →参照をひとつ進めて代入


   string(buf[0:i])

  配列はデータであり、
  stringとして参照するときはimmutableな配列に内部的に変換して表示に使われる。
  文字列は基本的にはUTF-8文字コードが前提

  • interface: Ast

type Ast interface {
String() string
Eval(env* Env) Ast
}


あるメソッドを備えたオブジェクトを受け取れる型
Ast型にの変数に代入できるのは、これらのメソッドが定義されている型のオブジェクト
Astにいれて使う方はこれらのメソッドを定義する。

演算は型をそろえないとコンパイルエラーになる。
実は、メモリ内では同じ扱いになったりするのだが、
コンパイラ、実行時はちゃんと評価してはじく。

  • map: variable table
    • いわゆるハッシュテーブル
    • intやstringをキーにして値参照できる。
    • そのmapにキーに相当する値があるかどうかを確かめるには、2つの受け取り用変数でmapを参照する

  (例)
  if v, found := map[hoge]

  • interfaceのメモリ内での扱い
    • 2つのポインタから成る。
    • データへのポインタと、Itabという型情報&メソッドのポインタ
    • intのように、わざわざ型情報を持つのがもったいない場合は、データのポインタにintの型情報が入っている。
  • interface type-switch

(例)
  if sym, ok := stmt.(Symbol);

  • 例外処理

 defer func() { ... }


その関数を呼ばれる前にかならず呼ばれる処理を実装することができる。
try, catchに相当する処理を実装するときに使う、

  • packageにする
    • ファイルを分割する
    • メインのファイル
      • import に"./godentaku"
      • godentaku.Read(line)
    • パッケージのファイル
      • package godentaku
      • 大文字で始まるとグローバルに参照できる。小文字で始まる場合はパッケージ内だけで参照できる。
    • 標準パッケージにコントリビュートする
      • codereviewでレビューしてもらう必要がある
    • googlecode でパッケージ公開

GDD2010:マーケットライセンシングを使って Android アプリケーションを守るには

マーケットライセンシングを使って Android アプリケーションを守るには
トニー チャン

マーケットライセンシングとは?
  • Androidマーケットに出ているアプリはライセンスでコントロールすることができる。
    • Licence Verification Library(LVL)がサポートされていればOK
    • APIlevel3〜
  • アプリケーションにLVLと統合する。
    • ユーザーのアプリケーションをクリックする。
    • Market Appがアプリケーションとバインドする。
    • MarketAppがGoogleライセンスサーバーと接続されて、ライセンス認証を行う。
実装のよくある間違い
  • サンプルそのままつかう
  • コードのobfuscate忘れ
  • NOT_LICENSEDが帰ってきてもアプリを終了しないという実装
  • テスト漏れ
Tips
  • コードの難読化

テクニックのひとつで、リバースエンジニアリングをやりにくくする。
コンパイルされたアプリは変更することができない

    • ProGuardツール
      • GPLで公開されている。
  • LVLモディファイ
    • コアLVLロジック
    • ライブラリの入り口、出口
    • LicenseChecker,LicenseValidator
  • switchステートメントをifに変更
    • HASHを使って新しいステートメントにかえる。
    • レスポンスコードを摩り替えるため。使われていない関数を削除したり、追加できる。
  • ポリシーインタフェースを省く
    • Proper license check and response handling
  • onCreateメソッドは難読化できない。Androidが直接参照しているためだ。
  • 頻繁なリリースをする、
  • クラックしにくくする
How to get started
  • サインアップ
  • セットアップ
    • AndroidSDKをインストールした後、LVLライブラリをダウンロードする。
    • アプリのプロジェクトのライブラリのところにLVLライブラリを追加
  • インテグ
    • ManifestにLVLを追加
    • Policyの定義
    • ServerManagedPolicy
    • StrictPolicy
  • テスト
    • ストアカウントを設定してレスポンスをテストできる。
参考文献
  • 「Market License developer guide」
  • LVL issue tracker
  • これに関するいくつかのブログポストもあるので、参照すること。

GDD2010:Google エンジニアの日常

Google エンジニアの日常
山内 知昭

山内さん
  • Googleのソフトウェアエンジニア
  • 2年前に入社
  • Web検索関連の仕事をやってる。
どんな仕事してるの?
  • 仕事の種類
    • SWE(Software Engineer)
      • Googleの製品・サービスを作る人
    • PM(Product Manager)
    • SRE(Site Reliability Engineer)
      • Googleのサービスを動かし続けている人
    • Ops(Operations ?)
      • 社内サービス開発する人
    • エンジニアが発想、設計、実装、launch
      • 最初から最後まで関わる。
どんなマシンを使っているの?
  • 占有マシン
    • ラップトップ
    • デスクトップ
      • データセンター上のVirtual Workstationを換わりに持っている人もいる。
      • 大きなディスプレイ:30インチが標準
  • 共有
    • 世界中のデータセンターを使える。ほんとに使える。
ソースコード
  • 基本的に全世界・全プロジェクト共通のリポジトリ
    • VCSコマンドを直接実行することは少ない。
    • さまざまなラッパーや補助システムがある。
  • コードレビューが必須。
  • かなり徹底していて、機能実装レビューだけでなく、言語として正しいかのレビューもある。
  • OpenSourceは管理が別
データ
  • ホームを含む様々なディレクトリがNFS
  • どの端末でも同じホームで作業できる。
  • どの端末でも同じコマンドが実行できる。
  • ジョブの入出力などの大容量データはGFS
ビルド
  • ビルドは内製のビルドツールがある。
    • 自動的に分散ビルド・分散テスト
ジョブ実行
  • 世界中のデータセンターの計算クラスタが自由に使える。
  • クォータの制限はあるが、かなり大きい
  • 同じバイナリをローカルでも実行可能
    • テスト実行で便利
  • 他のプロジェクトの生成ファイルにもアクセスできる。
    • 中間処理の終わったWebページなど、アノテーションのついてるWebデータを使ったりできる。
    • 前処理で思い処理をスキップして、自分のやりたいことに使えたりする。
仕事の進め方
  • 体制
    • 世界中から開発に参加
    • ロダクト単位のコアチームの構成
      • ある程度地理的な配置を考慮。
      • VCでつないでチームミーティング
      • 時差があるとさすがにしんどい
    • 個々のプロジェクトは少人数(1〜数人)
      • FtoFコミュニケーションは重要
      • 必要に応じて出張して開発
      • メール中心で、チャットを使う人もいる。
      • グループウェア(カレンダー、バグトラッカー)
  • 英語です
    • 日本人同士なら日本語で話すが、読み書きは英語です。
    • ダメな英語でも許してくれます。
    • 話すのはともかく、聞けないとしんどい。
ローンチプロセス
  • 確認項目
    • クオリティ
    • インパクトは十分か
    • セキュリティ
    • リソースは足りてるか
    • メンテナンスできるか
    • 法律に違反してないか
    • 関連チームへの確認
    • などなど
  • エンジニアが主体的に関わっていく範囲は広い
個人と組織
  • 好きな仕事ができてるか?
    • 半分Yesで半分No
  • Noの理由
    • アメンバーになるには、コアチームがいないとしんどい
    • 他のエンジニアのサポートがないとしんどい
  • Yesの理由
    • 20% Projectなら比較的自由にプロジェクトを選べる
    • Full-time projectでも課題発見・解決は最良の範囲
    • 親切な人や使えるリソースが多い
仕事以外の職場環境
  • オフィスに来るのが楽しくなる仕掛け
    • 食事、お菓子や飲み物が無料
    • オフィスデコレーション、遊具、マッサージ
    • 各種クラブ(カメラやグルメ、スポーツ、ダンス・・・)
      • Google日本だけで55のクラブ活動があるそうです。
  • チームの絆を深める仕掛け
    • 仕事中のおしゃべりはOK。休憩自由
    • 各種イベント、オンサイト・オフサイトミーティング
ワークライフバランス
  • 仕事時間の裁量は自由度が高い
    • 海外とやりとりすることがあると、朝早く、夜遅くにシフトしてる人もいる
  • 有給のほかに疾病休暇もあるので、
    • もしものために有給を残しておくとかの心配はいらない
  • 1週間まとめて休んで家族旅行とか普通。
  • 父親は育休(4週間)とれる。
  • 休みは取りやすい雰囲気です。
採用活動
  • エンジニアの採用は、エンジニアの大事な仕事
  • エンジニアが見て、「これは!」と思えば、面接へ。
  • 電話面接。オンサイト面接
    • 人事や管理職ではなく、現場のエンジニアが面接。
    • ホワイトボードにコードを書くことも。
    • 面接官は合否の判断と、その客観的理由をレポートする。
  • 必要なもの
    • 英語はできないと入った後しんどい
      • 山内さんはあまりできなかったが、入社2週間後には海外で仕事させられた。慣れない英語でなんとかサバイバルしていかないといけなかった。
    • 技術
      • さまざまな分野を知ってるほうがいい
      • CPUの仕組みからソフトウェアデザインまで
      • 表層的でない理解がもとめられる「なぜそうなのか?」
    • 人に指示する力ではなく、自分で作れる力を重視
    • きれいなコードを素早く書けること。
山内さんのケーススタディ
  • 文学部から工学部に変えた。
    • 大学院に行かずに就職
    • プログラミングは21歳から。
  • SIerに就職、2つ会社を経験
  • Googleの募集をWebで見て、レジュメを送った。
    • 1次面接受かって、2次にカリフォルニアで面接
    • 最初は落ちた。
  • 1年後、再度応募して、今度は受かる。
他の会社と違うところ
  • どのオフィスに所属しても、エンジニアとしては対等
    • 時差や規模などがハンディではない
  • エンジニアがエンジニアを評価する。
    • 採用でも人事評価でも。
  • リソースが多い
    • 世界中のデータセンターを実際に使える。何テラを自由に使えるのはすごいところ
    • 全コードが同じリポジトリなので、他のプロジェクトのコードもすぐに使える。
    • さらに、それを作った人にすぐに聞ける。
    • 物理的なものだけでなく、人的リソースも多い。

GDD2010:Android でリアルタイムゲームを開発する方法: リベンジ

Android でリアルタイムゲームを開発する方法: リベンジ
クリス プルエット

クリスさん
  • 「ワンダのレプリカ島」というゲームを開発
端末の種類
  • ゲームアプリは、パフォーマンスが気になる。端末重要。
    • 端末が多くなると、対応が難しいのではないか?
      • 端末の種類が多いが、大きく分けると2つの世代に分かれる。

   第1世代(古い端末)HT-03A相当
    だいたいQualcommMSM7200A 400MHzぐらい
    HVGA
    OpenGLES1.0
    30ヘルツないに5000頂点
    60ヘルツで1024頂点は問題ない

   第2世代
     500-1000MHz
     OpenGL2.0
      2.0になるとシェダーが使える
      ハードウェア補助
     WVGA
     30ヘルツ 3万頂点
     30ヘルツを超えられない端末も存在。

端末の特徴
  • 画面サイズ、解像度
  • インプット機能
    • トラックボール十字キー、キーボード、マルチタッチ
    • API的に対応しやすい
      • モーションイベントかキーイベントでくるので、
      • 比較的簡単に全端末対応できる。
  • OpenGL
    • テクスチャフォーマット:ATITC? PVRTC? ETC1?
      • 端末によって対応が違う
      • ほとんどのテクスチャはETC1で対応してるのでお勧め
    • OpenGLバージョン
      • AndroidのManifestで記述できるので、対応してない端末をはじける
    • GL_EXTENSIONS
      • OpenGLのバージョンによって機能を増やす方法。
      • ランタイムに確認できる。
Android端末のバージョン
  • ほとんどが2.1か2.2
  • マルチタッチ(2.1〜)などの機能要件によって、対応バージョンが決まる。
  • 1.6から画面サイズ対応
  • クリスさんのゲームは、1.5ベースで開発して、全バージョンに対応するのはそれほど難しくなかった。
  • HightMap Profiler
    • レンダリングにかかった時間などをプロファイルできる。
    • プロファイルでベンチマークとった
      • HT-03Aは頂点の数が増えるほど描画に時間がかかってくる
      • 秒間、30フレームを確保できないと、ゲームとしてはストレスを感じる
      • Xperiaはどんなに描画しても、画面のSyncにあわせて表示しているので、頂点の数が変わってもパフォーマンスがかわらない。ただし、30ヘルツを超えることができない。
LODの価値
  • 奥のものを簡単に描画するテクニック
  • 描画数を大幅に減らせるので、パフォーマンスを稼げる。
  • ゲーム会社は普通に使ってる技。
  • かなりきれいな画面が作れるはず。
パフォーマンスを高める方法
  • ★必ずVBOを利用
    • パフォーマンスが大きく上がる。
  • VBOの数を減らす
  • テクスチャコンプレッションならETC1
  • 2DならOpenGLのdraw_textureエクステンション
  • 30ヘルツで遊べるようにプランニング
  • 第一世代端末から第2世代端末までランタイムでスケール
    • GL_EXTENSIONSは役立つ
  • 第2世代のみの端末を狙うゲームならGLES2.0を利用
"ワンダ"の実装事例
  • キャラクスクリプトは draw_textureを利用
  • タイルをひとつのVBOからタイルのスキャンラインにした。
  • 2つのスレッドの仕組み
    • ゲームスレッドで当たり判定、操作を担当
    • レンダリングスレッドで描画に集中
      • Xperiaなどは、描画APIをたたいてから帰ってくるのに30ms絶対かかるので、CPUパワーを有効活用できる。
  • GLSurfaceViewが便利
  • NDKで高速化
  • アプリがポーズしたときの対策
    • ゲーム中にRAMがクリアされたときの対策が必要
    • 中断してほしくない場面は、GLSurfaceViewをいじって復帰対策をした。
学んだこと
  • 操作設定は必要
    • キーコンフィグレーション
      • 端末ごとについてるボタンが違うので、これをつけると好評だった。
      • 最初から考慮しておかないと、あとからつけるのは大変だと思う。
  • InputSystemを、InputInterfaceクラスと分離することで、設定を分離した。
    • ゲーム側のコードを変えずに入力の幅を広げられる
  • これって面白いだろうか?
    • プレイヤーが死んだポイントで、サーバーにデータを送る仕組みを入れた。
    • プレイヤーが死んでるところをマッピングすると、難しい箇所がわかるようになった。
    • 20万人ぐらいのデータをとったら面白い。
    • Androidはサーバーにデータを送るのはすごく簡単!
  • Webサーバーをつけた
    • デザインをちょこっと変えたいときに、シェーダーのデータを流し込めるようにする。
ゲームを作るにあたって
  • ”楽しいゲームには「革新」より「面白さ」のほうが大事”
    • Jonathan Blow, author of Braid
Androidマーケット上のゲームダウンロード回数
  • 5月からゲームのダウンロード回数が大幅に増えた
    • ダウンロードラインキングは全ジャンル中2位
    • Androidユーザーの一番関心があるのがゲーム。
    • Liteバージョンがほとんどの場合用意してある。
Useful Links
  • SpriteMethodTest HightMapProfiler
  • http;//replicaisland.net