iPodTouch版でのポーズ方法

今開発中のSHOT04ですが、4面道中が完成。
夏休み前までに4面ボスまで完成させたかったのですが及ばず。
8月中に完成するか、微妙なところ。
まぁ、順調なので、今年中に完成できる点はほぼ確定です。

ところで当初、Android版が完成したらiPodTouch（iPhone）版を作ろうと思っていましたが、iPodTouchへ移植するにあたり、仕様面での最大の課題がボタン系統です。

Android版の場合、
(1) 戻るボタンを押せばポーズ
(2) ホームボタンを押せばポーズしてホームへ戻る
という感じでハードボタンを使っていますが、iPodTouchにはホームボタンしかありません。

つまり、ポーズができません。
ゲームのメイン画面中にソフトボタンは絶対に入れたくないです。
なので、iPodTouch版に限り、(1)の機能を落とす方向で検討していました。

ですが、
「マルチタッチをした時にポーズ画面にする仕様にしてみてはどうだろうか？」
という天の声（たぶん、ジョブズ）が聞こえました。

SHOT04の仕様は、シングルタッチ専用だから、それでも仕様上問題ありません。ただし、「２つ同時タッチ」だと誤ってやってしまうこともあるだろうから、３つ同時タッチでポーズにしてみました。（まだ、iPodTouch版は作る環境すら作っていないので、とりあえずAndroid版で）

操作性としては、特に問題無さそうな感じです。
これで、iPodTouch版を作る上での課題は全てクリアできたかも。
残る最大の課題は、SHOT04（Android版とWindows版）を完成させること。

ちなみに、iPodTouch版ですが、Android版とWindows版の利益だけで開発環境を導入できなければ、やりません。流石に、道楽でこれ以上の出費は避けたいので。道楽であれば、個人的にはWindows版とAndroid版だけで十分だと思っていますし。

何より、私がiPhoneを持つことは有り得ない。
iPhoneに慣れた人がAndroidへ移行することは結構簡単ですが、Androidに慣れた人がiPhoneへ移行するのは無理なので。
「AndroidだとできるのにiPhoneだとできない」ということがあまりにも多すぎます。
iPhoneのダメな所は、
・先述のハードボタンのこと
・SDカードが使えない
・パーミッションの仕組みが無い（セキュリティ的に脆弱なのでアプリを使うのが結構怖い）

セキュリティ的なところだと、Androidの方がショボイというのが世間の常識ですが、OSの実装レベルで見てみると、iOSの方がガードの仕組みが無い分、審査がザルだった場合のセキュリティリスクが高いといえます。そして、昔は「厳しい」ということで有名だったAppMarketの審査も、実際のところはザルに等しいと思われる事案がチラホラと起きて始めているので、iOSの方がセキュリティ的に見て脆弱だと思います。（これについては、将来的に立て直される可能性があるかもしれませんが）

そういえば、現状はAndroidMarket(GooglePlay)の審査もザルですが、先週末、Googleからデベロッパーアカウントを持っている人向けに、「そういった部分を強化するから覚悟しとけよ」という内容の通知が来ていました。この通知について、以下に日本語の記事がありました。
http://japan.cnet.com/news/service/35019972/
上記の内容は審査でもしないと分からないと思うので、何らかの審査でもするつもりですかね？
良い傾向だと思います。

Arcade mode

SHOT04のPC版限定ですが、縦画面モードを入れてみました。
※Android版については、最初から縦画面専用

480x640のフル画面表示です。（ちなみに、SHOT04のスクリーン仕様は240x320（QVGA））
ディスプレイを90℃回転して遊べばアーケードさながらの迫力の大画面でSHOT04が遊べます。
どのモードで遊ぶかは、起動時にダイアログ（以下）で選択する東方方式で。

一応、標準（横置き）のフルスクリーンモードは２系統用意することにしました。
640x480(VGA)の画面中央部分にオリジナルサイズ240x320を表示するモード（１番上）と、1.5倍の360x480に引き伸ばして（縦画面一杯分で）表示するモード。拡大処理はソフトウェア方式（自前）でやっているので、私が持っている無茶苦茶遅い悪いノートマシン（ネットブック）とかでは、240x320じゃないと厳しい。

ちなみに、不要とは思いますが、一応、横画面のフルスクリーン（640x480）で縦表示するアーケードモード（Arcade mode）というのも入れておきました。Arcade modeは、横画面で縦表示にして遊ぶことができます。（ほぼ、誰得機能ですが、念のため）

上記の画面キャプチャは、そのArcade modeで撮りました。
私のPCのディスプレイが横置き専用なので、キャプチャを撮るのに縦画面モードにするのが面倒。
こういうモードを入れておけば、横置きのまま、縦画面モードのキャプチャが撮れる訳です。
それだけの為の機能なので、Arcade modeについては、正式リリース時に削るかもしれません。

・・・縦置きディスプレイが欲しくなってきました。
やっぱり、縦スクロールSTGなら縦画面じゃないと迫力がありません。
ゲームのためだけに、新しいディスプレイを買うのは馬鹿らしいですが、実はプログラマにとって、横置きよりも縦置きの方が、一度に視認できるコード量が増えるから有利なんです・・・と、自分を説得中。

fps記録

Android2.3～4.0の場合、機種によってVSYNCの間隔が区々なようなので、リプレイデータにプレイした時のFPS平均値を記録＆表示するようにしてみました。Androidの場合、VSYNC間隔はプログラム側で弄れ無さそうなので、せめて「どの程度の環境でプレイした記録か」という情報を保持する必要があります。

SLOT1～3は、仕様変更前のリプレイデータだから、0.00fps。
SLOT4がテストで記録してみたもの。
ちなみに、Windows版の場合、DirectX9以降に対応したGPUを積んだ環境であれば、60.00fpsジャストになります。少し端数の具合を確認したかったので、プレイ中にわざとウィンドウを動かしてみたりして、端数が出るようにしました。

あと、計測対象は、ゲームメイン処理のプレイ中でプレイ開始時点の最初の約1秒（正確には1000ミリ秒～1ミリ秒の範囲）を除いた状態からの平均フレーム数で、ポーズ中やクリア時、エンディング時は測定しない仕様です。（※最初の約1秒を記録しないのは、秒単位で総フレーム数と総プレイ時間（秒単位）を測定するので、厳密な測定をする為に必要）

無駄に厳密な測定。

生産状況(8/4)

本日（4-Aug 2012）時点のSHOT04の開発規模を測定。

5月中旬ごろ（体験版が完成した時）の実行行数が7.7ksぐらいで、現時点で12.3ks。
2.5ヶ月ぐらいで+4.6ksといったところですか。
「単独製作なのに、2.5ヶ月でたった4.6ksかよ！？」
と、思われるかもしれませんが、基本休日（週休2日として約20人日）しかプログラムを組む時間が無いから、こんなもんです。
あと、ずっとプログラムを作る作業だけやっている訳ではなく、絵を描くのと音楽や効果音を作るのにもそれなりに時間が掛かります。（むしろ、プログラムよりも絵や音楽の方が専門外なので大変）

思ったよりもプログラム規模が膨れました。
5月時点では、スコアランキングやリプレイなどの機能が未実装（体験版として公開できる最低限度の実装をした状態）だったというのが増加要因なので、あとは完成するまで、あまり大きな増加は無かろう・・・と、思っていますが、あと、3ksぐらいは増えるかも。一応、一番デカいゲームの本編処理（game.c）と、VGEエミュレータ（vge*.*とvgs.c）の増加傾向は止まりつつありますが、敵のアルゴリズム（enemy.c）の規模が依然として増加し続けているので。

敵アルゴリズムは、内部で細かく部品化して実装量を抑えるようにしていますが、再利用率があまり高くないです。似たような敵でも、ついつい細かい演出の違いとかを入れたくて、結局再利用せずに新規で起こしたりしているので。これなら、最初から部品化をしない仕組み（＝非オブジェクト指向設計）にしておいた方が実装規模を抑えることができたかも。私はそこら辺（オブジェクト化するorしない）のバランス調整がかなり上手い方なので、通常は実装規模を最小限に抑えることができるのですが、この敵システムの作りこみに関しては、ミスった感が否めません。

ちなみに、SHOT03の時の実装規模は、10.2ks。
だいたい、10ksを超えだすと、ソース内に魔物が棲み始めます。
だから、プログラムの規模は少なければ少ないほど良いです。
（SHOT03の時は完成時ジャスト10ks程度になるように狙って作っていました）

SHOT04に関しては、今から10ks以下にするようにリファクタするのは期間的に不可能です。
なので、魔物を棲ませた状態で作り続けざるを得ません。
ロックロールせざるを得ません。

エスプレッソーダの魅力について

7/29ぐらいに、エスプレッソーダが上手かったという記事を投稿しました。
そろそろ、VIPの反応が出ているだろうということで調べたところ概ね想定通りの反応。

※「http://logsoku.com/thread/hayabusa.2ch.net/news4vip/1344002674/」から引用

まぁ、こんな感じになるだろうと思っていました。
私としては美味かったし、既に複数回購入して飲んでいますが。
エスプレッソーダを美味しく頂くには、幾つかの手順を踏む必要があります。

①コーヒーだと思ってはいけない ← 最重要
コーヒーではなく、あくまでもコーヒーテイストの別モノだという風に思うことが重要です。
アイスコーヒーというイメージで飲むと、やられます。

②喉を鳴らして飲む（ビールみたいな感じで飲む）
これは、次で説明する③の効果を高めるために必要な手順です。
コーラとかって、勢い良く飲むと、「ゲフッ」ってなりますが、それが狙い。
「ゲフッ」とする時に漂うコーヒー風味が、とても良いです。

③香りを楽しむ
上記②でゲップをした時、喉の奥から鼻にかけて、爽やかなコーヒーの香りが通り抜けます。
その香りを楽しんでください。

この感覚は、コーラだと味わえないし、普通のアイスコーヒーでも味わえない。
お下品ですが、要するに、炭酸の影響でゲップをした時に得られる爽やかな香りが最大の魅力。
お下品なので、他人様の前では飲むことができませんが。
たぶん、葉巻とよく合いそうな気がします。（葉巻は飲んだことがないので、想像ですが）

音楽が凄い

Android2.3用のデバッグ機としてSonyのZシリーズを導入しましたが、音楽プレイヤーとしてかなり良品。
音楽がものすごく良い音で聴くことができます。
少なくとも、私が今まで使った携帯音楽プレイヤーの中では一番良いです。

細かい特徴は、メーカーのページで謳われている通り。
http://www.sony.jp/CorporateCruise/Press/201109/11-0913B/

一番のポイントはイヤホンですかね。
Zシリーズに付属しているイヤホンですが、「完全にZシリーズ専用」という仕様。
他音楽プレイヤーに繋げて聴くと全然使えません。（かなり小さな音になる感じになります）
試しに少し音質が悪いかなり昔に録音された楽曲を鳴らしてみたところ、キレイに再生されたので、かなりの波形補正（ホワイトノイズのカット等）をしているような感じです。

反面、アンプとかの外部ハードを使いたい場合、相性等の問題が起こり易いかもしれません。
ただ、そういった外部ハードを一切導入することなく、それと同等の効果が得られるともいえます。
なので、多少本体価格が高いという印象でしたが、コスパはかなり良いモノだと思います。
たぶん、iPodTouchで同程度の音質を得ようと思うと、アンプ＋ノイズキャンセリング対応のイヤホンが必要だと思います。iPodTouchでZシリーズと体感的に同等の音質を得ようとすると、最安値商品に絞って調達したとしても、Zシリーズの標準メーカ小売価格の1.5倍程度の出費（※iPodTouchの本体価格を含む）が必要になります。

なので、音楽プレイヤー用途で選ぶなら、iPodTouchよりはZシリーズの方が良さ気です。

55fps

どうも、ウォークマン（SonyのZシリーズ）だと微妙にゲームが簡単になったと思ったら、Zシリーズの場合、VSYNCが55fps（18.18ms）のようです。

・・・これは、ハード依存なので、どうにもなりません。

ただ、Jelly Bean（Android4.1）では62.5fps固定（16ms）になるらしい。

http://news.mynavi.jp/news/2012/06/28/014/index.html

Android4.0で（2.3から）大幅に劣化したSurfaceViewの性能問題も何とかして欲しいところ。

上記のような大幅改修をしたのであれば、結構期待できるかも。

ただ、期待値と同程度のデグレードリスクもある訳ですが。

この性能問題を除けば、Android4.0には概ね満足してます。

しかし、この性能問題が致命的過ぎるので、4.1へアップデートできるのであれば、すぐにでも試したいところ。

ただ、私の携帯（MotorolaのRAZR）ではAndroid4.1へアップデートが行われるかは微妙ですが。

Android4.0へのアップデートですら、だいぶゴタゴタしたようで、遅れに遅れて配信されたので。

ちなみに、Android4.0にアップして一番良かったのはChromeが使えること。（標準ブラウザよりもかなり使い易い）

標準ブラウザでも、Safariとかと比べればかなり使い易いけど、Chromeは更にその上。

タブがかなり便利。

あと、余談ですが、Android4.1でのFlush完全非対応はどうでも良いです。

Android4.0でも全然まともに動かないけど、特に困りまらないので。

Adobeが正式にFlush撤退を表明してくれたから、一気に脱Flushが加速した感じでしょうか。

ちなみに、Adobeが公式に撤退を表明しているのはモバイル分野のみだったと思いますが、今の時代、モバイルから撤退するということは、完全に消えることと同じ意味になる筈。

これは、アップルGJです。（発端はアップル⇒http://www.apple.com/hotnews/thoughts-on-flash/）

ただ、私は「HTML5なら大丈夫」だとは思っていませんが。

一番ベストな方式は、ブラウザから専用アプリをキックする方式です。

PCの場合、それでは使い勝手上の問題がありましたが、AndroidやiPhoneの場合、UIがシングル構造のためPCの場合のような問題（＝UX上の問題）は起こらないので。

あと、専用アプリ方式の方が「バグを作り込むリスクが低い」というメリットもあります。

「バグを作り込むリスクが低い」というのは重要です。（ユーザ視点では見え難いことですが）

ケン・トンプソンとデニス・リッチーがUNIXを作った時の設計思想（Small is Beautiful）がまさにソレ。

つまり、Flushの敗因は色々と詰め込み過ぎたことです。

色々詰め込み過ぎ、肥満化したから、重くてセキュリティホールの巣窟になりました。

なので、HTML5が「Flushの代替品」として作り上げられた場合、結局Flushと同様、肥満（重くて、セキュリティホールわんさか）になるだけだから、無意味ではないかと。