2014年8月14日木曜日

【アプリ】ビート&マジシャンズをリリースしました!

チームEGGの曽川です。

ボーカロイドPの「mathru@かにみそP」氏プロデュース!
リズム&育成ゲームのビート&マジシャンズ(ビーマジ)をリリースしました!

内容ですが、
リズムに合わせてグルーブストーンという色付きの玉が流れてきます。
この色に対応する属性を持ったモンスターがスキルを溜めたり発動したりしながら相手を倒していきます。
音楽ゲームが苦手な人でもキャラクターを強くしていけば勝てるようになっているので、音楽ゲームが苦手な私でも楽しくプレイできます。

「mathru@かにみそP」氏は、GacktさんのEpisode.0の曲やダンシング☆サムライを書いた人です。
実は一緒に会社をやっていて、曲もUnityも書けます。
前作の3秒サムライの曲も描き下ろしてもらってたりします。BGMが高評価です。
名曲揃いなので好きな曲をガンガンプレイしてもらう楽しみ方もいいかもしれません。


Get it on Google Play


2014年3月31日月曜日

AndroidにSwipeRefreshLayout(Pull To Refresh)が追加されました

Android Support Library revision 19.1.0においてSwipeRefreshLayoutが追加されました。

サンプルコード

簡単なサンプルコードを作ってみました。
リストを下に引っ張ると更新アニメーションが2秒間表示されます。
ActionBarのメニューからも更新アニメーションを表示します。

SwipeRefreshLayout

今回追加されたのはリストを下側に引っ張ってコンテンツを更新するレイアウトです。(いわゆるPull To Refresh)
SwipeRefreshLayoutをListViewの親レイアウトとして定義します。


SwipeRefreshLayoutを使用する準備として、setColorSchemeで色のリソースidを設定します。
これにより指定された色がアニメーションとして表示されます。(8行目)
また、更新処理のコールバックとしてsetOnRefreshListenerでSwipeRefreshLayout.OnRefreshListenerを設定します。(12行目)


更新時の処理はSwipeRefreshLayout.OnRefreshListener#onRefreshで受け取ります。
ここでは単に2秒後にmRefreshDone内の処理を行っているだけです。(14行目)
setEnable(false)はリストを下に引っ張れないようにロックします。更新中はこれを呼び出すことで引っ張る操作を防げます。(16行目)


2秒後にmRefreshDoneの処理が呼び出されます。
setRefreshing(false)を呼び出すとでアニメーションが停止します。(6行目)
setEnabled(true)を呼び出すと下に引っ張りだす操作を復活させます。(8行目)


setRefreshing(true)を呼び出すと、マニュアルで更新時のアニメーションが表示されます。(6行目)
この場合も前述と同じようにsetRefreshing(false)を呼び出すことでアニメーションが停止します。


所感

SwipeRefreshLayoutは、引っ張った時や更新中の進捗表示が用意されているので、開発側で大きな変更をすることなく既存のアプリに組み込めそうです。
しかし、リストのヘッダ部分に何かメッセージを表示させたり、Gmailのように引っ張った時にActionBarを変化させる処理は用意されていません。この辺りは自作するかStackOverFlowに頼ることになりそうです。

2014年3月27日木曜日

Android Wearを使ってみた(基本編)〜NHK番組表APIとの連携〜

チームEGGの曽川です。

前回のAndroid Wearを使ってみた(導入編)に引き続き、今回は基本編として簡単なプログラムを紹介します。
今回作成するアプリは、Android Wearで直近のNHKの番組を表示します。

NHK番組表API

NHK番組表APIは、現在放送されている番組や番組のリストを表示するAPIです。
ユーザ登録を行うと、APIキーが発行されるので簡単に利用できます。
今回は、直近で放送されている番組を取得するNow On Air APIを使用します。
使い方はリンク先で非常にわかりやすく説明されています。

サンプルコード

サンプルコードは以下で公開しています。

Android WearのStacking Notification

現在放送中の番組と、次の番組を以下の形で表示します。

ここでスタック表示のために使っているコードはこちらです。


9行目のgroupOrderの部分でスタックを表すWearableNotifications.SUMMARYとその並び順を表す数値を与えています。
このグループを24行目で設定し、26行目でスタックさせたい数だけ通知を行います。
これ以外のコードは通常のAndroidの処理と同じようにVolleyで通信を行っているだけです。

所感
Notificationの記述が誤っているとAndroidWearに通知されないので、デバッグはしづらい印象です。
そのため、どこが誤っているのかトライアンドエラーを繰り返しながら進めました。
また、NotificationCompatとWearableNotificationsが絡み合うので、複雑な通知になればなるほど混乱しそうですね。

2014年3月19日水曜日

Android Wearを使ってみた(導入編)

チームEGGの曽川です。

GoogleがAndroid Wearを発表したので使ってみました。
Android Wearはウェアラブル端末用のAndroidプラットフォームで、第1弾としては腕時計型の製品を発表しています。

Google I/Oで発表されたGeofenceやActivity Recognitionと相性が良さそうです。


Android Wear開発環境のセットアップ

開発環境のセットアップは以下の手順です。(Eclipse環境)
1.Android Wearのプレビュー版に登録
2.Android Wearに関連するインストールやバージョンアップ
3.Android Wearエミュレータの作成・起動
4.Android WearとAndroid端末の連携
5.通知テスト(Gmailを送ってみる)

1.Android Wearのプレビュー版に登録

以下のリンクから「Sign Up For the Develoeper Preview」を選択して、必要事項を入力します。 http://developer.android.com/wear/preview/start.html
しばらくすると、メールでセットアップ手順がやってきます。基本的にはこのメールに添付されたライブラリやソースコードをダウンロードして使用します。

2.Android Wearに関連するインストールやアップデート

EclipseのADTアップデート

ADT Plugin for Eclipseの場合は、Help>Install New Softwareからアップデートしましょう。
注:アップデート時、問題にぶつかった場合は参考にしてください


Android SDK Managerから以下をインストール

・Android SDK Tools 22.6(以上)
・Android Wear ARM EABI  v7a System Image


3.Android Wearエミュレータの作成・起動

Window>Android Virtual Device ManagerからNewを選択してエミュレータを作成します。
以下は設定例です。
AVD Name AndroidWearRound
Device Android Wear Round(320 x 320: hdpi)
Target Android 4.4.2 - API Level 19(デフォルト)
CPU/ABI Android Wear ARM(armeabi-v7a)(デフォルト)
Skin Android Wear Round
Memory Options RAM:512 VM Heap:32(デフォルト)
Internal Storage 200(デフォルト)


OKを押すとAndroid Wearエミュレータが作成されますので、Startで起動しましょう。



4.Android WearとAndroid端末の連携

Android Wearのダウンロード

1番目の手順で受け取ったメールのURLから、Android Wear Previewをダウンロードします。

4.4.2以上の端末(Nexus 10はダメでした)しか対応していないようです。
そのため、該当する端末を持っていない場合は、genymotionでNexus5を作成し、Google Playをインストールすれば利用可能です。


アプリ側(Android Wear Preview)の設定

アプリを起動して青い部分をクリックします。


通知へのアクセス画面でチェックを入れます。

ダイアログが表示されるのでOKを押します。(このダイアログに承諾してもらうことがアプリ開発者の苦悩になりそうですね。)

adbコマンドでAndroid WearとAndroid端末を接続

adb -d forward tcp:5601 tcp:5601
※genymotionで行っている場合は、
adb devices
で端末名を取得してから
adb -s 端末名(192.168.xx.xx:5555) forward  tcp:5601 tcp:5601
と入力してください。

Android Wearのアイコンが「g」になれば接続成功です。

5.通知テスト(Gmailを送ってみる)

自分にGmailを送ります。

Android Wearに通知が届きました。
※届かない場合は、Gmailの同期設定などを確認してみてください。

2014年3月14日金曜日

ウナ先生の基本情報技術者試験をリリースしました。

ウナ先生の基本情報技術者試験をリリースしました。
体験版は問題数を制限していますが、有料版では多くの問題を提供しています。


技術的なところで言うとこれまでのタブよりもレイアウトに自由がきくSlidingTabsBasicを取り入れたり、カードUIの注意点など色々知りながらできました。
予想問題を多めにしたことと、技術を身近に感じれるような用語解説を心がけたため、リリースが伸びたような気がしてます。。。
基本情報試験自体は4月20日なので、受験する方がいましたら体験版だけでも使ってみてください。

2013年12月14日土曜日

AndroidのFragmentについてのセミナーを実施しました&お知らせ

チームEGGの曽川です。

セミナーについて

レバレジーズ様でAndroidのセミナーを行いました。
今回のテーマはFragmentについてです。
基本的な使い方や、アンチパターンの紹介を行っています。
サンプルコードでは以下を取り扱っています。
・GoogleMapsV2デモ
・YouTubePlayerAPIデモ
・UIあり/なしのフラグメント
・ダイアログフラグメント
・フラグメントやアクティビティのライフサイクル
・タブレット対応
・フラグメントのコールバックについて

以下にリンクを貼っておきますのでご覧ください。
資料
サンプルプロジェクト
サンプルアプリ


お知らせ

さてこの度、チームEGGは法人化し、チームEGG株式会社となりました。
これも皆様のおかげでございます。
また、状況が落ち着いてきましたら正式にお知らせいたしますが、2014年より活動の幅を広げていきたいと思っております。
これからもEGG開発ブログをよろしくお願いいたします。

2013年9月28日土曜日

Androidでゲーム開発する際のTips

チームEGG 曽川です。

こちらのAndroid Developers Blogの翻訳です。
Using the Hardware Scaler for Performance and Efficiency
要はスケーラを1080pxにするとパフォーマンス等で恩恵があるという話です。


パフォーマンス向上と効率化のために、ハードウェアスケーラを使用する

パフォーマンスを要する3Dゲームを開発する場合に、美しいグラフィック、高いフレームレート、よりよいレスポンスをする方法を探すことでしょう。また、バッテリーの節約やもプレイ中にデバイスが熱くなるのも避けたいでしょう。この分野全てにおいての最適化を支援するために、現在ほぼすべてのAndroidデバイスで利用可能なハードウェアスケーラの活用を検討してください。

どのように動作し、なぜ使用するのか

最近のほぼすべてのAndroidデバイスは、ハードウェアビデオスケーラを含むCPUとGPUのチップセットを使用しています。Androidは上位ベルでの統合を提供しており、Javaやネイティブコード(C++)からAndroid 標準APIを介してアプリがスケーラを利用できます。ハードウェアスケーラを利用するには、システムが利用するデフォルトのグラフィックバッファ(デバイスのフルスクリーン解像度にサイズ調整されています)ではなく、固定のグラフィックバッファを使用するだけです。

固定サイズのバッファにレンダリングする場合、デバイスのハードウェアはアスペクト比の調整も含めて、デバイスの画面解像度に合うように拡大や縮小を行います。通常、効率的にレンダリングさせるために、デバイスのフルスクリーンよりも小さい固定サイズのバッファを作成します。(特に、現在の高解像度の画面において)

ハードウェアスケーラを使用するとより効率が良くなる理由はいくつかあります。
1つ目は、ハードウェアスケーラは非常に高速で、マルチタップと表示の乱れを減らすアルゴリズムを通して、素晴らしい表示結果を生成することができます。2つ目は、アプリが小さなバッファにレンダリングされているため、GPUでの演算負荷が減り性能が向上します。3つ目は、少ない演算処理によりGPUは低温で動作し、バッテリーの使用が少なくなります。最後は、使用したいレンダリングバッファのサイズを選択でき、実際の画面解像度にかかわらず全てのデバイスで同じとなります。

フィルレートの最適化

モバイル用のGPUにおいて、ピクセルフィルレートはパフォーマンスを要するゲームアプリのボトルネックとなる主な原因の1つです。最近の携帯端末やタブレットはかなり高い画面解像度を提供し、2Dや3Dのグラフィックをレンダリングすると、大幅にフレームレートが下がります。GPUは最大のフィルレートを埋めるために非常に多くのピクセルを打つため、フレームレートが低下します。

Androidで使用される一般的なチップセットにおける
レンダリングされる解像度別のGPUの消費電力
(データはQualcommが提供)
これらのボトルネックを回避するためには、ゲームが各フレームで描画するピクセルの数を減らす必要があります。これを達成するためにZプリパスの最適化のような方法がありますが、簡単で効果的な方法はハードウェアスケーラを使用することです。

サイズが2560x1600のようなフルサイズのバッファを描画するのではなく、ゲームでは小さなバッファ(例えば1280x720や1920x1080)にすることで、ハードウェアスケーラは追加のコストがなく、できるかぎり少ない画質低下で表示を拡大します。

消費電力と発熱を少なくする

パフォーマンスを要するゲームは多くのバッテリーを消費し、かなり発熱する傾向があります。ゲームの消費電力と発熱に関することはユーザにとって重要であり、開発者にとっても重要な検討事項です。

図に示すように、GPUでの消費電力はレンダリングする解像度が高くなると大幅に増加します。多くの場合、GPUに負荷をかけることはデバイスのバッテリ寿命を減らすことになります。

また、CPU/GPUのレンダリング負荷が増加するにつれて、持っていることが不快になるほど発熱します。発熱するにつれてCPU/GPUを冷やすために、処理速度を調整するように設計されているので、ゲームを処理する順番を抑えることができます。

消費電力と発熱の両方を最小限に抑えるために、ハードウェアスケーラは非常に便利です。小さいバッファにレンダリングするため、GPUは少ない電力でレンダリングし発熱を少なくします。

Android APIからハードウェアスケーラへのアクセス

Androidは、標準のAPIからハードウェアスケーラに簡単にアクセスできます。(JavaコードやAndroidNDKを介したネイティブ(C++)コード)

これには固定サイズのバッファを作成し、レンダリングするためのAPIを使用するだけです。デバイスの実際の画面サイズを考慮する必要はないですが、元の縦横比を保持したい場合には画面とバッファのアスペクト比を一致させるか、バッファのレンダリング領域に画面を合わせます。

Javaコードからは、APIレベル1で導入されたSurfaceViewを通じてスケーラーにアクセスします。ここで、1280x720の解像度で固定サイズのバッファを作成する方法は次のとおりです。

ネイティブコードからスケーラを使用したい場合は、Android 2.3(APIレベル9)で導入されたNativeActivityクラスを介して行います。ここで、NativeActivityを使って1280x720の固定バッファを作成する方法は以下のとおりです。

バッファサイズを指定することで、ハードウェアスケーラが有効にされ、指定されたウィンドウへのレンダリングが対象となります。


グラフィックバッファの選択

固定サイズのグラフィックスバッファを使用する場合、パフォーマンスや処理性能向上と、対象デバイス間での画質バランスにおいてサイズを選択することが重要です。

ハードウェアスケーラを使用するほとんどの高性能3Dゲームは、レンダリングの推奨サイズは1080pxです。図に示すように、1080pxは画質、フレームレート、消費電力において最適な大きさです。もちろん720pxで十分な場合は、良い操作性のためにこの値を使用してください。


さらに

アプリでハードウェアスケーラを使用したい場合は、AndroidフレームワークでレンダリングしているかネイティブAPIでレンダリングしているかに応じて、SurfaceViewNativeActivityのドキュメントを参照してください。

バードウェアスケーラを使用したサンプルコードは近日公開です!