調整

SHOT04のライト版を作成する作業を進めておきました。
あと、エンディングやらを作ったりして、とりあえず形だけは仕上がった感じです。
残るは最終調整のみ。

ちなみに、チュートリアルというかHow to playは、Demonstrationを見れば分かる程度の内容しかなかったので削る方向で。細かいルールの説明は、日本語と英語でWeb＋マーケットの説明文でアップすることにしました。（そろそろ、情報処理の勉強をしないとマズイ感じだから、８月中にはマスターアップしたいので、作り込みは避けたい心境）

なお、ライト版は製品版リリースとほぼ同時にバージョンアップします。
あと、Windowsでもライト版をビルドするようにしておきました。
Android版の製品版をリリース後にWindows版のライト版もリリースする予定。
Windows版の製品版は主に販路の調整中。（DLマーケットあたりが妥当な線です）
で、結局今日はそういった作業に追われてしまい、肝心なゲーム本編の調整が進まず・・・
調整は明日から会社で休み時間などにスマホを使ってやる予定。とりあえず、APKをSDカードで持っていき、Androidを持っていてゲーム好きな感じの人にテスタになってもらいます。

調整目標は、
・Beginner = 私がノーミスでオールできる程度
・Soldier = 私がほどよくオールできる程度
・Ninja = 私がギリギリ、オールできる程度
まだまだ遠い。。。

カンストはしない・・・はず

とりあえず、SHOT04のラスボスが完成。
第三形態を作るかどうかは、調整の状況を見て決めようと思います。
たぶん、調整すると難易度は落ちる方向になる筈なので、「これでは物足りない！」という難易度だった場合に第三形態を入れます。「もう十分です＞＜」という場合、入れない方向で。（現時点で結構な鬼畜難度なので、後者に倒れる可能性が高そう）

で、この状況でとりあえず「ノーミスでオールした場合、どのぐらいのスコアが入るのか？」という素朴な疑問があったので、無敵フラグを立てた状態で最高難度をノーミスでオールしてみました。

１億５～６千万ちょいぐらいのようです。
理論値（もっとも稼げるパターン）でクリアしたとしても、２億ぐらいですかね？
ちなみにカンストは999,999,990点。
なので、どんな変態シューターがプレイしたとしても、カンストすることは無いと思います。
現時点の難易度で普通にプレイした場合の私のベストスコアは2千万弱ぐらい。
全国一レベルの方の場合でも5千万前後。

さて、これから鬼調整をするか・・・
調整というのは、ひたすらプレイして難度を弄る作業。
遊び要素が大きいので、あまり苦にはなりませんが、時間が掛かる作業です。
基本的に、Ninja以外はどんどん緩くする方向で調整する方向。

ちなみに、SHOT03の時の調整に要した時間は100時間前後。
SHOT04は、現時点ですでに100時間ぐらい調整しています。。。
難易度を３種類にしたことに加えて、機種を３機種にしたことが色々と痛い。。。
「機種は２種類で良かったんじゃない？」と、今更思っていたりします。

生産状況（18-Aug）

SHOT04の現時点（５面ボスの第２形態を３～５割ぐらい作成完了したところ）の生産ステップ数を取得。

実行行数がほぼ１６ｋｓというところ。（8/4の前回の生産状況から＋３ｋｓ増加）
まだ、エンディングとか、チュートリアルとか、調整とかでワサワサと増えそうな感じなので、完成時点で２０ｋｓぐらいになるかも。

以下、蛇足

ちなみに、仕事でプログラムを作る場合、ステップ数を見積もり値にしている所が意外と多くあるようですが、ステップ数の見積もり値なんて全然アテにならないのにやる意味あるんですかね？私が仮に、想定規模を計上する必要に迫られた場合、とりあえずFP法（私の場合、画面単位ではなく機能単位で算出する方が精度が高い）なりで何かしらの根拠のある数字を出しますが、だいたい以下のような要因でその数字はフェーズとともに上下します。
①「この機能とこの機能は共通化できる」（機能レベルの共通化見落とし）
②「この機能はｘ機能とｙ機能に分割しなきゃダメだ」（機能レベルの分割漏れ）
③「この機能が必要だった」（機能レベルの実装漏れ）
④「この機能は要らなかった」（機能レベルの冗長実装）
そして、より下流フェーズに進むと①～④の「機能」が「関数」とかの細かい単位に変わります。まぁ、下流フェーズでも機能レベルの設計ミス（＝すり抜け不良）がある程度残存するものですが。一般的に、見積もり値の上下幅は、上流フェーズの設計ミスほど広く、下流フェーズの設計ミスであれば狭くなります。自社開発なら、それでも大して問題は無いと思います。問題は、他社に請負契約で発注するケース。請負契約の場合、発注時点で発注に掛かる費用（予算）を決めますが、プログラムが完成していない時点（コーディング前）の場合、幾ら掛かるのか客観的に分かり難いため、適正価格が発注時点で分かりません。だから、かなりアヤフヤな値であることを承知で想定規模（想定される画面数やプログラムのステップ数）なんかを指標にしている企業がたくさん居る訳です。個人的には、請負契約が妥当なプロセスは、テスト工程（※定性的な項目が多い統合テストなどを除く）ぐらいだと思います。請負契約で上手くやる（見積もりと実績の乖離を減らす）のに有用な開発手法は、経験則ではスパイラルモデルの開発ぐらいです。要は、見積もりと実績の乖離を減らすには、すり抜け不良を少なくすれば良い訳で、それをやるのに一番良い手段は、開発サイクルを小さく分割することだけだと思っています。学問レベルでは色々な手法が考えられているようですが、スパイラル以外の実用レベルで使い物になる手法は未だ見たことがありません。ただし、スパイラルだとそれを第三者が管理するのは無理に等しいから、開発作業とマネジメント作業を両立できるエンジニア以外できないこと（＝要員確保が困難なこと）がネック。そして、そういうエンジニアは得てして単価が高いから、予算オーバーになり易いという落とし穴があります。そもそも、スパイラルで妥当な程度の規模にサイクルを分断すると、発注のオーバヘッド（恐らく裁断したサイクル単位で発注する→妥当な規模に裁断すると契約がポコポコ増える→大変になる）でパフォーマンスが落ちるような気もするので、結局のところ「コーディングまで委任契約がベスト」だと思っています。

要は、「コーディング＝定量的な作業」という風潮をなんとかする必要があるんじゃないかと。

開発状況（17-Aug）

ネット環境がスマホしか無いところで１週間弱過ごし、今帰ってきました。
ポータブルな開発環境を整えたので、そういう所の方が捗るのかもしれません。
温泉宿とかで１週間ぐらい篭ったりするのが理想。
シーズン中は嫌ですが。（混むので）

「せっかく温泉宿に行ってゲーム作りなんて・・・」と、思うかもしれませんが、結構オススメです。
ゲーム作りでなくても、例えばその他の創作活動（漫画とか小説など）や試験勉強などにも良いです。
「ｘｘｘをする為にｙｙｙに居る」という意識が働くことで集中力が増します。
更に、貧乏性の私の場合、「お金を払ってまで」という意識が更に集中力を増幅させます。

なので、コストは高ければ高いほど良いから、温泉宿がベスト。
ただし、温泉宿だとちょっと足が出ない場合、ビジネスホテルとかでも良いかも。
または、（音が気にならないのであれば）漫画喫茶とか。
あと、国内出張ならグリーン車、海外出張ならビジネスクラスかファーストクラスというのもアリです。
（もちろん、普通料金からの差額は自腹で）

まぁ、今回私が行ってきたのは温泉宿でもなければビジネスホテルでもありませんが。
法要で田舎で宿泊してただけ。（漫画喫茶にはチョクチョク行って作業しましたが）
とりあえず、SHOT04の５面の道中が完成し、ラスボスを作成しているところ。
ラスボスは作画が終わっていて、あとはアルゴリズムを組むだけという感じです。
この土日でとりあえず完成させて、あとは８月中に調整を終わらせ、９月中にはリリースしたい...

４面完成

４面が完成。

割とゴチャゴチャしたステージになりました。
一定距離を保って箱を打つと、アイテムジャラジャラみたいな感じです。
難易度はほど良い感じ。

あとは今週中に５面完成すれば良いなぁ・・・。
そういえば、説明書とかってAndroidだと、Windowsみたいにドキュメント（Readme.txt）を付属する習慣が無いから、やっぱり、チュートリアル的なものを作らなければ駄目かな？と、今さら考え始めました。
しかし、言語フリーで作るのは結構大変そうかも。
基本、ゲーム画面中には、単語レベルの英語以外は入れたくないと思っています。
例えば、基本的な操作系であれば、
1. Touch -> Fire and Move
2. Not touch -> Charge
3. Fill & Touch -> Laser
ぐらいが、言語を用いる上限になるイメージ。

今、ふと、「リプレイの機能を使ってそれを流しながら上記の単語レベルの説明入れていけば良いんじゃないか？」というナイスな考えを思いつきました。ちょっと面倒くさそうですが、そういう部分には力を入れた方が良さそうな気がしないでもないです。

やはり、Windows版が本丸

Android用のゲーム開発を開始してそろそろ半年ぐらい。

しかし、端末毎の仕様差が想像以上に激しいので、やはりAndroid版でのモノ作りは色々と厳しい。

設備投資を惜しまず、最初はiPhone向けで作るのが吉だった感が否めません。

私が一番気にしている問題（VSYNCの端末差）は、Android4.1でようやく解消されるようなので、Android版の開発はそれを待ってからやるべきだったんじゃないかと。あと、Android4.0で地雷（SurfaceViewの大幅な性能デグレード問題）を踏みましたし。

ですが、今開発中のSTGの本丸プラットフォームは、Windows版。

要は、Android版やiPhone版というのは客寄せパンダ的な位置づけのつもり。

やはり、STGはタブレットや電話機のようなチマチマとした画面ではなく、大画面でやりたいので。

しかも、今回は縦画面のフルスクリーン対応。

23型ぐらいのワイドディスプレイを縦置きにしてプレイすれば、ゲームセンターと同じ迫力で楽しめます。

Androidと仕様を合わせる都合上、入力装置にマウスを使うのがちょっとアレですが。

シューターは伝統に囚われる人が多いから、最初は抵抗があるかもしれません。

ただ、STG用の入力機器としては、セイミツ工業のアケステ以上にマウスの方が向いているかも。

アケステよりも精密な動きができるので。

Music room

開発中のSTGのオマケで付ける音楽の試聴機能を、かっこいい感じにしてみました。
とはいえ、こういうオマケ部分にあまり力を入れたくないから、VGS Chiptune musicからの流用ですが。

せっかく、めずらしい方法で音楽を鳴らしているので、そのことを実感していただくために。
開発中のSTGは私が独自に設計した波形メモリ音源VGS（VideoGameSound）をソフトウェアエミュレーションする方式で音楽を鳴らしています。（VGSは私の脳内にしかないので、実在しません）

言うほど難しいことはやっていませんが、こういうやり方で音楽を鳴らしているゲームといえば、エミュレータ類を除けば洞窟物語（あと、イカちゃん？）ぐらいしか思い浮かばない。結構簡単に作れるし、アプリの容量も抑えられるし、凝らなければ処理性能もかなり速い（VGSの場合、ネットブックでもサクサク動きました）ので、もっとやっている人が居ても不思議はないんですがね。
ついでに、自作音源なら、自分のやりたい範囲で好きなようにハードウェア仕様を弄れるから楽しい。

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以下にするようにリファクタするのは期間的に不可能です。
なので、魔物を棲ませた状態で作り続けざるを得ません。
ロックロールせざるを得ません。

/mnt/sdcard/ディレクトリのアクセス権限

ウォークマン（Zシリーズ）で、SHOT04（NokogiRider）をデバッグしていて機種依存の盲点をひとつ発見。

SHOT04の場合、SDカード（/mnt/sdcard）の下に専用のディレクトリを掘って、そこにプレイデータ（スコアとか）やリプレイデータを保存する仕様にしていたのですが、Zシリーズの場合、/mnt/sdcardにアクセス権限が無いようでした。

確かに、Androidの仕様として、/mnt/sdcardの有無は機種依存に成り得ます。
Androidの仕様として、アプリケーションが（ストレージパーミッションで）読み書きが保障されているのは、基本的に 標準のアプリケーションディレクトリ（/data/data/パッケージ名） 配下のみのようです。

という訳で、/mnt/sdcardにアクセス権限が無い場合、標準のアプリケーションディレクトリ（/data/data/パッケージ名）にデータファイルを保存する仕様にしておきました。


なお、/mnt/sdcardにアクセス権限がある場合は、SDカードに保存するようにします。
一般的にSDカードの方が空き領域が大きいので、標準のアプリケーションディレクトリに配置するデータは可能な限り小さくする方が、ユーザにとって親切だと思うし、リプレイデータとかを独自にバックアップしたりするのも楽なので。（/data/dataディレクトリの場合、パス決めウチで打たないとファイルへアクセスできないという...）


これは、InvaderBlock2も同じ仕様にしておく必要がありそうです。
まぁ、このバグに気付けただけでも、Zシリーズを購入した甲斐がありました。
Zシリーズ設備投資分のペイバックは無いでしょうけど。

しかし、Androidの機種依存には困ったものです。
SHOT04は、かなりその辺を柔軟に作ってましたが、それでもこういう手落ちは出てくる・・・

---

追記(8/4):
Xアプリで、音楽データを転送したら/mnt/sdcardに書き込み権限ができたっぽい？
とりあえず、SHOT04は、/mnt/sdcardに書き込み権限があれば、/mnt/sdcardにデータ保存して、なければ/data/dataにデータ保存する仕様にしておきます。

Windows版の扱い

現在開発中のSTG（SHOT04）ですが、Android版については無料のLITE版を配布＆有料（100～200円程度の予定）の製品版を販売する予定ですが、Windows版の扱いをどうしようか、全然決めてなかったな。。。

LITE版相当の無料版は適当に（ベクターとかで）配るつもりですが。

せっかくなので、アレンジ付きのサウンドトラックと製品版相当のWindows版をセットで同人ショップあたりで販売しようかという案があります。

DL販売ではなく物理媒体の販売で。

ただし、そうなると赤字の可能性が・・・まぁ、一種の道楽なので、多少の赤字は問題無いですが。

とりあえず、適当なプレス屋さんで値段を調べてみました。

Pケース：3week

枚数	300枚	500枚	700枚	1000枚	1500枚	2000枚
料金	89,700	95,000	100,100	105,000	157,500	206,000
1枚当たりの単価	299	190	143	105	104	103
枚数	2500枚	3000枚	3500枚	4000枚	4500枚	5000枚
料金	247,500	294,000	339,500	384,000	427,500	470,000
1枚当たりの単価	99	98	97	96	95	94

[参考] http://www.inv.co.jp/~popls/

コストパフォーマンスで見ると、1,000枚～が概ね最低ラインですかね。

Android版でちゃんと原価分の利益が出てくれれば、何も躊躇することなくトライできますが。

仮に、Android版を150円で販売した場合、Googleの手数料(30%=45円）を差し引いて、1,000本ぐらい売れればトライできる感じですかね。（1,000本も売れる気がしませんが）

3ボス完成

3面のボスがとりあえず完成。

デカめのレーザー。
発射前にはちゃんと集気的な感じの前振り＋効果音で知らせるので、初見殺しではないです。
３面はステージの難易度が高めだったので、ボスの難易度は緩くしておきました。

しかし、現時点では最高難度（Ninja）で私が３面を越せないという状況。
このままではマズイので、調整が必要です。
ただ、全体バランスというのもあるので、とりあえず完成を優先する方が吉な気がしてきました。

あと、ボス戦でグダグダと稼ぐゲームにはしたくないので、タイムボーナスを高くする方向で調整中。
スコアシステムは、体験版（公開中）から大分弄ったかも。
あまりにも弄りすぎてしまい、私自信が細かい要素を忘れつつあります。

だいたい、ソースコードが10ks（10,000行）を超えだすと、自分自身でも全体を把握し切れない|-)
全体規模で10ksは余裕で超えていますが、そろそろゲーム本編処理のみで10ksを超えそうな感じ。

開発状況（3面ボス作成中）

3面ボスを作成中。

怒首領蜂（無印）の２面ボスあたりをオマージュした感じでしょうか。
珍しく、DoGAに殆ど頼らずドット絵を自分で描いてみました。
（DoGAで描いているのは、左右の副砲のみ）

色々と予定が遅延方向になる事由があったので、進捗は悪いです。
夏中に完成は厳しいかも。
というより、難易度の調整が厄介です。
３面のボスが一通り完成したら、ちょっとやり込んで調整する必要があります。
無理ゲーというほどではないのですが、現行の３面の難易度が鬼畜すぎるので、易しくする方向で。２面は、殆ど調整不要で良い感じにできたのですが、３面は色々と自重しなかった所為で、色々と吹っ切れ過ぎてしまいました。


今にして思えば、全５面というのがオーバースペックだったかも。。。
まぁ、音楽も作ってしまったので、全５面で作りますが。
ただ、次回作からは全３面で良いかも・・・と、思いつつあります。
次回作を作る予定は、今のところありませんが。
構想めいたものはありますが、どの程度売れるかが疑心暗鬼なので。
（SHOT04が想定よりも売れたら作る予定）

とりあえず、調整し易いように残機MAXでデバッグしてますが、Practiceはこのままで良いかも。
あと、画面構成を少し変えました。
例の問題のこともあるので、FPS表示をする方向で。

効果音の作り方

アマチュアがゲームを作るとき、効果音を自作している人はどれぐらい居るのでしょうか？
ふと、疑問に思いました。
割と有名なフリー素材があり、そこから拝借・・・という手があります。
しかし、私の経験上、自分で作った方が楽です。
素材だと、気に入った音を探すのが大変だし、ライセンス（使用許諾）の縛りも発生するので。
つまり、技術的にも権利云々（著作権とか）でも、自作した方が楽です。

(0)必要な機材

必要なのは、PCと波形エディタソフトだけです。
マイクとかは不要です。
自然音を加工して使いたいのであれば別ですが、ゲームの場合、自然音を使うと逆に不自然。

私は、3種類の波形エディタを使っています。（全部フリーウェア）
①効果音エディタ_D
②wavy
③Tiny Wave Editor


(1)音を作る


一番大事なことは、「効果音エディタ_Dで目的の音を自在に作れること」だと思います。
適当に弄っていても作れますが、音色の仕組みを理解すれば、ある程度狙って作れます。

a) サイン波
最も基本的な音色はサイン波（下図）です。

効果音エディタ_Dで波形（音色）のところに上図のような線を描き、再生してみてください。
たぶん、「ぽーーー」という感じの丸い音が鳴ると思います。
笛系の楽器の音がだいたいサイン波です。
マイクを持っている人は、笛の音を録音して、１周期（凸と凹の１セット）を見れば分かります。



b) 三角波

サイン波を少し変化させた感じの音色に三角波（下図）があります。

三角波は、概ねサイン波と同じような感じの音です。
ただ、ちょっと鋭い感じになります。
「ぺーーー」という感じでしょうか。
ちなみに、ファミコンのベース音でよく使われるのが、この三角波です。


c) 矩形派
嘗て、電子音といえば矩形派でした。
理由は波形を作るための計算が物凄く簡単なので。
つまり、安価なマイクロチップで処理できます。
AY-3-8190とかのPSG（Programmable Sound Generator）は矩形派ですね。

「ピーーー」という感じの音が鳴ります。
楽器でいうとクラリネットとかよく言われますが、個人的には「？」です。

ポイントは、
・サイン波＝ポーーー
・三角波＝ペーーー
・矩形波＝ピーーー
です。

相違（図では黒線の位置）の変化が大きいと、音が鋭くなるという感じでしょうか。
それだけ抑えておけば、だいたいどんな音でも狙って作れます。
あとは、デューティー比（プラスの相違とマイナスの相違の比率）を調整したり、合成したり等々。


d) ノコギリ波
メロディーとしてよく使われる音色がノコギリ波ですね。
ちょっと、分かり易くするために２周期分のノコギリ波を描いてみました。

サイン波や三角波との決定的な違いは、１周期終わった後の変化量です。
上から下まで一気に降下しているのが分かると思います。
この大きな変化量が、非常に心地よい違和感を与えてくれます。
楽器でいうと、ストリングスとかの音になります。

上図だと、２周期分のノコギリ派を鳴らしますが、単位時間あたりの波の周期の数（周波数）が多くなると、音が高くなります。１秒間に440周期で鳴らせば、オクターブ４のラの音になります。
８８０周期鳴らせば、オクターブ５のラですね。

効果音エディタ_Dでは、音色と同様、周波数の波（時系列での変化）も編集できます。
あとは、音量の波も編集できます。
そして、これらを弄って目的の音を作ります。
左右の出力バランスも調整できますが、私は効果音は全てモノラルで作るので使いません。

e) ノイズ
あとは、相違をランダムに変化させれば、ノイズになります。
ちなみに、ファミコンで使えるプリセット波形は、三角波、矩形波、ノコギリ派、ノイズの４種類です。

(2)音を加工する

wavyなどのフィルターツールを使い、適当な加工をします。
加工のコツですが、「加工し過ぎないこと」です。
実はこれは結構重要です。
だから、私の場合、加工フェーズで使うフィルターは概ねエコーのみです。


(3)周波数などの調整


私の場合、ゲームで使う効果音は、22050Hzのモノラルと決めています。
そういった周波数の調整をするのに、Tiny Wave Editorが役立ちます。
Tiny Wave Editorは、かつてヤマハのサイトで無料で入手できました。
ただ、最近は配っていないようです。

海外のヤマハサイトを巡回すれば見つかるかもしれません。
ちなみに、私は3年ぐらい前にカナダのヤマハサイトで見つけました。
（一応、まだ無いかチェックしてみましたが、もう無いようです）


(4)効果音を入れるコツ

細かい全ての動作に対して効果音を入れると良いです。
過剰に設定するぐらいがちょうど良いです。
ちょっと邪魔っぽい感じだったら、音を鳴らさなくする前に、音を小さくしてみると良いかも。
ちなみに、SHOT04（NokogiRider）の体験版で使っている効果音は、34種類。
現段階（３面途中）では40種類。
完成版では、少なくとも50種類ぐらいになると思います。

今後の対応について

今後のアプリ開発の方向性について、Androidの扱いをどうするか真剣に考える必要がありそうです。
とりあえず、前の記事に書いたパフォーマンス劣化の問題が酷すぎるので。
最初から、iPhoneをメインを据えるべきだったか。。。

ただ、この問題が私の使った端末（Razr）固有のものだったら、まだ救いはあります。
たぶん、2.3から4.0へアップデートできる端末はそんなにはないので、そのケースの地雷を踏んだだけかも。
そうであれば、まだAndroidを切るという判断は早い。

更に、SHOT04（NokogiRider）の体験版を既にAndroidMarketで無料配布していて、尚且つ1,000本近いダウンロードもして頂いたので、ここで頓挫してしまったら楽しみにして頂いている方たちに申し訳ないです。まだ、日本の方からは感想は貰ってませんが、海外の方からはメールで感想を貰っていて、楽しみにしているとのことでしたし。


でも、私のメイン端末でデバッグができないのは痛すぎますが。
その点は、2.3系のスマホを別途（白ロムで）入手して、何とかしようと思います。
一応、2.3系のタブレットは持ってますが、やはりメインターゲットはスマホなので、スマホのデバッグ機は１台は欲しい。

まさか、１年で３台買うハメになるとはね。。。orz
開発環境のコストはタダ同然（最初に25$必要なだけ）だから、最初は（iPhoneではなく）Androidにしたのですが、もしかすると裏目だったかも。

OpenGL/ESによる2D描画の高速化 (update-6)

VG-EngineのJava部分の描画処理をSurfaceView+CanvasからOpenGL（GLSurfaceView+GL10）に変更したところ、処理性能が大分落ちてしまった問題が直りつつあります・・・ですが、今一歩。。。

ポイントとなるonDrawFrameの処理は以下のような感じ。

public void onDrawFrame(GL10 gl10) { // VG-Engineの描画処理を呼び出す int rc=SHOT04.setVram(vram); if(0!=rc) { System.exit(0); } // VRAMの内容をテクスチャ領域へ転送 // GLUtils.texSubImage2D(GL10.GL_TEXTURE_2D,0,0,0,vram); gl10.glTexSubImage2D(GL10.GL_TEXTURE_2D,0,0,0 ,TXSIZE ,YSIZE ,GL10.GL_RGB ,GL10.GL_UNSIGNED_SHORT_5_6_5 ,vbuf ); // 描画 drawUv.put(vramPositions); drawUv.position(0); gl10.glEnableClientState(GL10.GL_VERTEX_ARRAY); gl10.glVertexPointer(3, GL10.GL_FLOAT, 0, drawUv); gl10.glDrawArrays(GL10.GL_TRIANGLE_STRIP, 0, 4); }

最初のSHOT04.setVramというのは、VG-Engine（エミュレータ）の中核描画ルーチンです。
従来、引数に渡しているvramはBitmapクラス（AndroidBitmap）でしたが、byte配列に変更。
この部分で、仮想VRAM（240x320pixel）の描画処理を行います。
AndroidBitmapのlock/unlockが無くなった分、高速になったかも。
ただ、ポイントはそこではないです。

ポイントは、「VRAMの内容をテクスチャ領域へ転送」というコメントのところです。
この部分を、GLUtils.texSubImage2DからGL10.glTexSubImage2Dに変更しました。
GLUtils.texSubImage2Dの場合、AndroidBitmapを引数に渡します。
しかし、転送するバッファサイズを指定できないから、常に全体を転送する無駄が生じます。
OpenGLの仕様上、テクスチャ画像の辺の長さが2のn乗でなければならないので、VG-EngineのVRAM仕様（QVGA=240x320）の場合、AndroidBitmapのサイズは256x512pixelという具合になり、無駄なデータ転送が発生する訳です。

GL10.glTexSubImage2Dの場合、テクスチャバッファに転送するバッファの幅と高さ情報を指定できるので、転送量を256x320にすることが可能になります。（ちなみに横方向は240にすると危なそうなので、256のままにしておきました）

これにより、転送量を262,144byteから、163,840byteに削減できます。
ほぼ半分程度の削減になりますね。（47.5%の削減）
OpenGL内部でのバッファ⇒テクスチの変換処理が恐ろしく遅いので、この削減効果は極めて大きいです。

ちなみに、テクスチャやテクスチャの表示位置を設定する処理は、全てonSurfaceChangedで纏めてやってます。
つまり、変換イベントを検出しない限り、1回ポッキリ。
こうすることで、バッファリング演算の処理回数を大幅に削減できます。
大幅っていっても１テクスチャのみだから高が知れてますが。



描画時の頂点バッファ演算（２ポリゴン分）は削れませんが。（この部分も最適化の余地があります）
なお、サーフェースのクリア処理（glClearとか）は大して重くないけど、やる意味が無いから、やってません。
（テクスチャは画面全体のVRAMが1枚のみだから、こういうやり方でOK）

しかし、このやり方でやっても52～58fps程度しか出ない。（IdeaPadA1の場合）
やはり、常識的に考えて、テクスチャの書き換えというのは重過ぎる。。。
（当然ながら、ボトルネックはglTexSubImage2Dです）

ちなみに、上記はBVQ（Basic Vert Quads）という、割とオーソドックスな手法です。
DTE（Draw Texture Extension）の方が高速という噂があるので、DTEも試したのですが、結果は同程度。
（性能が同程度なら、オーソドックスな手法の方が良かろうと思います）

やはり、テクスチャの書き換えによる描画という手法自体が鬼門ですねぇ・・・。
まぁ、最初から知っていたことですが。（知っていたから、当初Canvasを使っていた訳で）
surface lockをサポートしている分、OpenGLよりはDirect3Dの方が2D向きです。
何故、OpenGLはsurface lockをサポートしていないのやら・・・
3D onlyのゲームでも普通に要ると思うのですが。

半分、諦めの境地です。
ですが、諦めるのはまだ早い。
「思い切って、フルネイティブ（NativeActivity）にしてしまえばどうだろう？」というのも、無くは無いです。
当初、Android特有の拡張機能を取り込むのに不便だから避けてましたが、必要になるとすれば広告（アフィリエイト）や何らかの通信サービスを入れる時ぐらいだろうし、そういうものを実装するつもりは今の所無いので。（でも、後からやりたくなったら困るから、中々踏み切れない）

---

追記

上記のonDrawFrameの処理時間を測定してみたところ、だいたい平均で9ms～10msぐらい。

個別に測定してみたところ、
・仮想VRAM作成（setVram）が3～6msぐらい（ゲーム本編の処理量による）
・テクスチャ作成’（glTexSubImage2D）が5～15msぐらい（平均すると7ぐらい）
・描画が1～2msぐらい

たぶん、これが限界性能なのかも。
もうちょっと最適化余地を探ってみますが。

あとは、JavaVM（ダルビッシュでしたっけ？）とかAndroid側の制御や、VGSの処理（OpenSL）の制御やらが色々絡んでって感じかなぁ・・・ただ、VGSは別スレッドの筈だから、そんな大したものではないです。なので、やはりNativeActivity化が一番優良の策なのかも。。。


キツイなぁ。

---

追記2

とりあえず、NativeActivity化する前に、onDrawFrameの処理（全部）をJNIで実行する形に改造。

↓こんな感じ

@Override public void onDrawFrame(GL10 gl10) { // VG-Engineの処理を呼び出す if(0!=SHOT04.setVram(gl10)) { System.exit(0); // Exitボタンが押された } }

まぁ、Javaで書く意味は無いですからねぇ。
頂点座標についても、onSurfaceChangedで、Cのバッファへコピーし、Cで作成。
ループ処理中のJavaからのデータ受け渡しは一切無いです。

こうすれば、NativeActivityで実装するのとほぼ同等性能だと思います。
たしかに、少しばかり速くなりました。
遅いタブレットマシンでだいたい55～58fpsぐらい。
Razrならほぼ60fps。

う～ん・・・今一歩です。
やっぱり、NativeActivityにするしか無いかなぁ・・・

---

追記3

まぁ、追記2のコードでダメだったということは、このままNativeActivity化しても効果はほぼ無いでしょう。
Javaコードは、タッチ等のイベント処理とonDrawFrameしか走らないので。
なので、圧縮テクスチャを利用してみようと思います。

一般論で、「圧縮」というと遅そうなイメージですが。
ただ、OpenGLの世界では、圧縮＝色のビットレートを落とすことという意味らしい。
まぁ、圧縮であることには違いません。
データ転送量が減るから、圧縮した方が高速だということです。

16bitカラーから8bitカラーに変更した場合、glTexSubImage2Dの転送量が次のようになります。
・16bitカラーの場合 = 240×320×2 = 153,600byte
・8bitカラーの場合 = 256色×3byte＋240×320×1byte = 77,568byte


VGEの仮想ハードウェアの色表示性能は8bit（256色）なので、表現性に劣化は生じません。
（VGEのハードスペックを設計した時、8bitカラーを採用しておいて本当に良かった・・・）
表現性に劣化が生じずに転送量を1/2にできるというのは美味しすぎる。
つまり、これをやらない手はないです！

---

追記4

ほぼ、チェックメイトになりました・・・
圧縮したテクスチャ情報を送信する場合
・glCompressedTexImage2D または
・glCompressedTexSubImage2D を使います。

glCompressedTexImage2Dの場合、転送する画像サイズが、テクスチャサイズと同値でないと失敗します。
・VRAMサイズ = 240x320pixel（QVGA）
・テクスチャサイズ = 256x512pixel
という差異があり、テクスチャサイズでしか転送できない場合、倍程度の無駄領域が発生してしまいます。
なので、折角圧縮して転送量が半分になるのに、無駄領域の転送により転送量が倍になる・・・
・・・要するに、完全なる無意味状態。

glCompressedTexSubImage2Dの場合、圧縮形式が通常のGL_PALETTE8_R5_G6_B5_OESとかではなく、PVRTC方式というGPU内部のアルゴリズムで圧縮しなければなりません。
一応、glext.hに以下の4種類が#defineされています。

#define GL_COMPRESSED_RGB_PVRTC_4BPPV1_IMG                      0x8C00
#define GL_COMPRESSED_RGB_PVRTC_2BPPV1_IMG                      0x8C01
#define GL_COMPRESSED_RGBA_PVRTC_4BPPV1_IMG                     0x8C02
#define GL_COMPRESSED_RGBA_PVRTC_2BPPV1_IMG                     0x8C03

で、この圧縮方式ですが、けっこう複雑です。
要するに、GPU内部でこのアルゴリズムでテクスチャ情報を変換して保持しているから、テクスチャイメージの書き換えには膨大な処理時間を持っていかれてしまう訳ですね。
なので、仮に自前のCPU演算で同じ圧縮演算をしたとしても、GPU任せの変換と比較して膨大な処理時間を食う訳です。


という訳で、ほぼチェックメイトです。
「ほぼ」というのは、まだ２つほど別のアイディアがあるという意味です。

【アイディア１：ベースロジックの改造】
テクスチャ変換処理を完全に別スレッド（非同期）にして、onDrawFrameのサイクルが呼ばれる時点で完成した前フレームのテクスチャを画面に出力する（毎回１フレームの遅延が発生するけど、かなり軽くなる筈）


【アイディア２：総転送量を減らす】
テクスチャを２枚（256x256と256x64にして、組み合わせて256x320にする。
この方式はかなり危険です。
・つなぎ目の境界がボンヤリ見えてしまう可能性がある。
・2回glCompressedTexImage2Dを呼び出す必要がある。

---

追記5


とりあえず、【アイディア２：総転送量を減らす】を実装してみました。
つなぎ目は割りと気になりません。
しかし、やはり、2回glCompressedTexImage2Dを呼び出すオーバーヘッドが思ったよりも大きい。
一応速くなりましたがね。


IdeaPadA1で、55～56fpsで安定していたものが57～58fpsで安定する程度に。。。
もはや、ギブアップ寸前。。。

やっぱり、OpenGL/ESは使い物にならない。。。

そもそも、ポリゴンのテクスチャとは、頻繁な書き換えを想定したものではないので。
OpenGL/ESで性能を出そうと思えば、パターンデータは完全に固定化する必要があるというのが、結論かな。
しかし、2Dゲームの場合、そんなんだと使い物になりません。。。
ピクセル単位での書き込みや、スプライトのマスキング表示などが必須なので。
それらはパターンデータの加工が必須。
テスクチャを書き換えずに利用する方式だと、パターンデータの加工はできない。
よって、チェックメイト・・・。


ちなみに、onFrameDrawのC側の関数の入口と出口にログ出力処理を入れてみたところ、
I/SHOT04  (16557): 2012/07/15 19:01:37.562 start
I/SHOT04  (16557): 2012/07/15 19:01:37.578 end (4ms)
I/SHOT04  (16557): 2012/07/15 19:01:37.579 start
I/SHOT04  (16557): 2012/07/15 19:01:37.595 end (16ms)
I/SHOT04  (16557): 2012/07/15 19:01:37.597 start
I/SHOT04  (16557): 2012/07/15 19:01:37.612 end (15ms)
I/SHOT04  (16557): 2012/07/15 19:01:37.613 start
I/SHOT04  (16557): 2012/07/15 19:01:37.629 end (16ms)
I/SHOT04  (16557): 2012/07/15 19:01:37.630 start
I/SHOT04  (16557): 2012/07/15 19:01:37.646 end (16ms)
I/SHOT04  (16557): 2012/07/15 19:01:37.647 start
I/SHOT04  (16557): 2012/07/15 19:01:37.662 end (15ms)
I/SHOT04  (16557): 2012/07/15 19:01:37.664 start
I/SHOT04  (16557): 2012/07/15 19:01:37.671 end (7ms)
I/SHOT04  (16557): 2012/07/15 19:01:37.686 start
I/SHOT04  (16557): 2012/07/15 19:01:37.694 end (8ms)
という具合。

絶望的な遅さです。
何よりバラツキが激しい。
やっぱり、PVRTCが相当なｸｾﾓﾉです。
完全なソフトウェアレンダリングの方が高速に処理できる気がしてきたので、そっちの方向で探ってみるか。。。

---

追記6


そもそも、今回の問題の発端になったCanvasがICS（Android4）で劇的に性能劣化するようになった原因のGoogle公式回答が見つかりました。
https://groups.google.com/forum/?fromgroups#!topic/android-developers/CK_jkHEQoOM


Google「すまんね、lockCanvasはAndroid3以降、ハードウェアアクセラレーションしないよ。」

えっ？
それだけ？

質問している方は、代替策を聞いているのに、代替策に関しては無策ということはバグですね。
ICSからのバグならまだしも、Android3の頃からのバグ（仕様欠陥）ってことは、直す気ナシか？
Googleみたいなスカタンな連中にOSを作らせた結果がコレです。

完全に推測ですが、ICS開発中のGoogle内部でのやりとりは、大方
・電池持ちについて検討
・SurfaceView+CanvasのH/Wアクセラレーションを切れば電池持ちが良くなる
・ゲームが遅くなる可能性については黙認 （デグっても問題なしと判断）
といった感じですかね。

さて、どうしたものか。
Android 2.3専用にして作り続けるか、開発自体をドロップするかの二択？
厳しいなぁ。。。

とりあえず、やる気が大分削げました。
Windowsでゲーム本編の開発を進めることはできるから、作りながら待つべきか。

OpenGL化に苦戦中

とりあえず、SurfaceView + Canvasで描画していたVRAM転送処理を、OpenGL化。
VRAM情報（AndroidBitmap）はそのまま使える筈なので、骨組みを変更するだけ・・・・
・・・なんですがね。

Java部分というかAndroid固有部分の実装は、正直かなり面倒です。
とりあえず、本屋でOpenGL/ES関連の書籍を入手。
http://www.amazon.co.jp/%E5%88%9D%E3%82%81%E3%81%A6%E3%81%AEOpenGL-ES-%E5%B1%B1%E4%B8%8B-%E6%AD%A6%E5%BF%97/dp/4873114969

とりあえず、OpenGL/ESの1.0で実装してみました。
しかし、Android2.3の検証機で動かしてみたのですが、重い。。。
Android2.3で遅くなるのはアウト過ぎます。
私自身のスマホは4.0にアップしましたが、やはり、メインターゲットは2.3なので。

まぁ、まだかなり改善余地がありそうなので、頑張ってみます。
AndroidBitmapで作成したVRAM情報を、毎フレームtexSubImage2Dで転送しているのが無駄に思えてしょうがない。

OpenGL側で管理しているテクスチャ原本のメモリポインタを取得できれば、一気に解決なんですが。

３面進捗が・・・

結局、NHKがらみの対応（参照）で、殆ど開発が着手できず・・・
実際にやったことといえば、テレビの処分と解約の手続きだけで昨日（7/7）全て完了していたのですが、主に法律関係の調査と理論武装などに若干の時間が掛かりました。法律は難しいですねぇ。でも、法律を勉強するのは楽しいので、あまり入れ込みすぎないように注意する必要があります。（私の場合、下手をするとネタで司法試験予備試験でも受けてみようかという発想になりかねない）

本当は、今日、３面が完成する予定だったんですが、当然ながら完成せず。
９月公開という線については、若干暗雲が立ち込めてきましたが、まだ焦るような時期じゃない。
平日が割りと暇になる頃合なので、平日にチャージできそうですし。