2012年3月31日土曜日

上下移動

とりあえず、海外展開で私がやるべき「INVADER BLOCK 2」に関する作業は概ね終わり、後は時を待つばかりなので、2作目の開発にとりかかりました。

画面はこんな感じ。(まだ、自機以外の何も無い状態ですが)
とりあえず、左右の移動は「INVADER BLOCK 2」の方式が一番妥当だと思います。
なので、2作目もその点は引き継ぎます。
問題は上下の移動。

考え得る方式としては、

  1. 左右と同様に、ポイントした地点(指が邪魔にならないように少し上の方)を目指す
  2. ポイント位置に関係なく、スライドした分だけ上下に移動する
  3. マルチタッチにして画面上下を左右移動、画面左右を上下移動に使う
  4. 上下移動はしない


方式1は、ポイント地点を上にズラしたところで、指が邪魔になることに変わりはありません(程度の問題です)。他のAndroid用シューティングを幾つかやってみましたが、この方式のものはやはり、「指が邪魔」という類のコメントが付いていました。そして、私もそういう風に感じたので、不採用。

方式2は怒首領蜂とかと同じ方式なので、有力候補です。実は、あまり直感的に動けない(というより指が疲れる)デメリットがあることを、「INVADER BLOCK 2」開発途中に確認済みなので、単純に方式2を取り入れるのは微妙。


方式3は却下です。マルチタッチだとWindowsで遊べなくなってしまうので。
Windows版を販促用に無償配布する都合上、Windowsで遊べないものは作れません。

方式4はギャラガ方式ですね。一見するとかなり微妙なのですが、そういうものだと割り切れば悪くは無いとも思っています。ゲーム性が狭まるデメリットが大きいのですが、だからこそ出来ることも有るような気がします。必ず、デメリットには相反するメリットが内在するので、そのメリットを高める工夫をすれば、デメリットをかき消すことが可能になる・・・ということも稀に有ります。

つまり、方式2 or 4が有力候補。

今の所、左右移動に「INVADER BLOCK 2」の方式、上下移動に方式2を採る複合案が最有力。
シューティングは、どちらかというと左右の移動が直感的に出来れば良く、上下の移動は補助的な動作になるから、方式2のデメリットはほぼ感じなくなる筈。

ただし、その方式を採用しているゲームは今のところ見当たらなかったので、

  • その方式だと操作し難い
  • 考え付いた人が居ない

の何れかの原因がありそうだ・・・と、思っています。
後者の可能性は低い(普通に誰でも考え付くレベルのアイディア)と思っています。なので、前者の可能性が高いかも。でも、私が熟慮して選んだ案にはハズレが多く、「この方式が良さそうだ」と思ったのは直感なので、アタリかもしれません。

日本語でおk

わたしのサイトを一通り英語化しました・・・しかし、わたしの英語はかなり怪しい。
一応、英検4級を持っているので、結構大丈夫だと思いますが。
個人情報保護方針とか、活動方針とかは、齟齬が無いようにするため、英語が得意な人に確認してもらっておこうと思います。

あとはこのブログも英語で書くようにすれば、少しは英語力が身に付くかと思いますが、やはり面倒くさいので、ブログは日本語でおkの方向です。大した内容は書いてないし。

そういえば、スマホで表示したときに、みょうに字が小さくなる感じだったので、ヘッダのメタタグでビューポイントを設定してみました。

↓こんな感じです。
<HEAD>
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0, user-scalable=no, target-densityDpi=medium-dpi">
</HEAD>

上記を入れておけば、とりあえずスマホのブラウザでも大きく表示されるので見易くなります。
私のウェブサイトは情報量が少ないから、単純に上記を設定するだけで、問題無い感じです。

2012年3月30日金曜日

Add english

どうやら、upload.comに登録するには、web siteを英語にする必要があったようです。

とりあえず、情報量が少ないから、トップページは全部英語にするのは簡単。ソフトウェアのダウンロード先はvectorを除き英語対応済み。

問題は、個人情報保護方針の英語対応か。。。

ちなみに、初めてスマホから記事を書いてみました。字はそこそこ打ちやすい。けど、アプリが使いにくい。。。

2012年3月28日水曜日

自動消灯の抑止

Android用のゲームプレイ中に気になることは殆どないのですが、INVADER BLOCK 2では、リプレイデータを再生中、一定時間が経過すると勝手に画面が消灯してしまうことに今さら気付く・・・

デバッグ機(タブレット)は消灯OFFなので気付かず、スマホではリプレイを再生したことが無かったので気付きませんでした。やっぱり、無駄機能でしたかね?(リプレイ)

消灯設定OFFにするには、何か許可(permission)が必要だと思っていたので、ちょっと微妙な気分だったのですが、どうやら、特別な許可を設定しなくても良いようです。

Javaのコードであれば、
getWindow().addFlags(WindowManager.LayoutParams.FLAG_KEEP_SCREEN_ON);
とやるだけ。

もちろん、4/8に公開するバージョン2.05には入れておきます。

海外向けの公開先確保

海外向けのWindows版(無料版)の公開先として、CNETのupload.comにユーザー登録しました。

会社概要(company description)を200字以上の英文で書かなければいけないのが厄介でしたが、何とかなりました。登録申請から数時間後に、「内容をレビューするから3/31(予定)まで待ってくれ」という内容(英語)の返事があったので、結果は不明。(多分、問題無いと思いますが)

一応、Android版のバージョンアップ(4月8日)後、同時にWindows版「INVADER BLOCK 2」をupload.comへ登録申請をしようと思っているので、3/31でも全く問題は無いですが、問題あった場合はどうしようか。。。

とりあえず、INVADER BLOCK 2のREADMEを英訳する作業を済ませました。
その英訳が違和感無く読めるかどうかが微妙ですが。
たぶん、意味は通じると思いますが、所々、おかしな表現があるのは否めません。
商業とIT分野の英語なら割と普通に読めるのですが、書くのは難しい。。。

しかし、gmailの方に届くメールの英文率が高い・・・
仕事でも英文でやりとりすることが稀によく有るのですが、中々慣れることができません。

2012年3月27日火曜日

Windows版INVADER BLOCK 2(2.05)先行配信

無償版(Windows版)のINVADER BLOCK 2バージョン2.05を先行配信しておきます。
http://www.k2.dion.ne.jp/~ysuzuki/IBLOCK2.ZIP
※プレイには、DirectX End User Runtimeが必要です。

ご意見・ご要望等を頂けると嬉しいです。
4月7日までにご連絡いただいたものは、可能な限り製品版(Android版)に反映させます。

耐久床

「INVADER BLOCK 2」に耐久床を付ける改造が完了。
タイトル画面はこんな感じにしました。
ボタン式にしました。
(アイコンだと、押せるのかどうかが分かり難かったので)

で、本編のゲーム画面は下図のような感じです。



軌道の表示(GUIDE)は、バージョン2.03(公開中の最新版)よりも、若干見易い色に変更。
床の耐久力は、ボールの衝突を1回だけ耐えられる程度にしました。
当初、3回にしようとしましたが、ゲームバランスが悪かったので、1回だけ。

ちなみに、GUIDEをONにすると、ラウンドクリア時のボーナスが1/2になり、FLOORをONにすると、ラウンドクリア時に累計ボーナスアイテム数がリセットされる形になります。(スコアペナルティ)

あとは、前回(2.03)のように焦ってリリースせず、早くとも4月8日以降にリリースする方向で、デバッグしまくっておきます。ついでに、このバージョン(2.05以降)をリリースするまでに、海外でWindows版の「INVADER BLOCK 2」を売り込むため、海外のダウンロードサイト(登録先)を幾つか物色しておこうと思います。(ついでに、日本のダウンロードサイトも、Vector以外の配布チャネルを増やす方向で検討中)

2012年3月26日月曜日

破線表示のON/OFF機能(2.04)

とりあえず、破線表示をON/OFFする機能を実装してみました。

※このバージョン2.04は非公開です

先ほどの記事に書いたように、破線表示のON/OFF状態もリプレイに記録される形になります。
更に、旧バージョンのリプレイデータも問題無く、再生可能。
ただし、旧バージョンのリプレイデータは常に、破線非表示の状態で再生される形になります。。。

もちろん、このまま公開しても良いのですが、流石にそれだと芸が無さ過ぎるし、次のアップデート間隔までの猶予もあるので、このバージョンは非公開にします。

リプレイデータの空き領域に結構余裕があるので、更に、画面の下に3回程度、ボールの落下を耐える床のモードとかを追加すると楽しそうじゃないかと思ったりしています。

問題はタイトル画面がゴチャゴチャしてきたということ。
やっぱり、文字項目は5項目以下じゃないと、見栄えが悪い。。。
ガイド表示、耐久床、サウンド(=ON/OFFで設定するもの)は、アイコン表示っぽい感じの方が良いのかも。

「近日」とは

昨日、「INVADER BLOCK 2」のバージョン2.03をアップロードしたのですが、いきなり有効インストール端末数が2つ減ってしまったことに心を痛めています。やはり、仕様変更=オプション化は必須という風に真摯に受け止めて対応しようと思います。

で、あわてて「近日中にオプション化したものを公開します」という一文を追加しておきました。

ただ、その一文を追加してふと思ったのですが、先日の不具合対策(バージョン2.01)から1週間も間を空けずにバージョン2.03をアップロードしてしまったため、ウザッたらしく思われてしまったのではないか・・・とも考えました。

という訳で、(不具合の対策を除く)急を要さないアップデートに関しては、今後、直前のリリースから2週間以上の間を空けてアップデートしようと思います。(もちろん、明確な要望があれば、それを優先しますが)
なので、オプション化対応のものは、(ある程度脳内で仕様は固まっているので、ほぼ完成しているのですが、)来月8日前後を目処にアップロードすることにします。

現状の脳内仕様としては、次のアップデートでは、タイトル画面で軌道を表示するか否か選択できるようにして、且つ、リプレイデータ再生時に、プレイした時の設定でリプレイを再現する感じにします。もちろん、リプレイデータの互換性を保った状態で。(ただし、現状公開しているバージョン2.03以前のリプレイデータは、全て軌道が表示されない形で再生される形になると思います)
ジックリとデバッグする期間を確保するのも目的の一環なので、速く具現化はしておきたいところ。

2012年3月25日日曜日

Windows版INVADER BLOCK2(2.03)

先ほどにGoogle Play(Android Market)で公開した、「INVADER BLOCK 2」バージョン2.03と同一の修正を行った、Windows版(@Vector)を差し替える手続きをしました。
一応、Vectorで公開予定のバージョンでは、Android版で行った細かい修正を幾らか取り込んでいるので、先ほどの記事でアップした先行公開版とは、若干異なるものになります。(殆ど誰も気付かないレベルのものですが)

しかし、このブログを始めてそろそろ一ヶ月ちょっとになりますが、ちゃんと見られているのやら。
一応、ページビューのカウントが3,000ぐらいなので、私以外に誰も見ていないということも無いと思いますが。ただ、米国からのアクセスがやたらと多いから、恐らくロボットの巡回カウントが結構含まれている筈なので、生身の人間のアクセス数はPVの1/10ぐらいかな。

一応、そこそこ有用な記事はGoogle検索でも引っ掛かるっぽいので、有用な情報を配信すれば、自作ソフトの宣伝効果にもなるのかな・・・と、思ったり、思わなかったり。私が作った、Android/Windows共用のVG-Engineの仕組みについて、ポイントを絞って解説記事を載せたりすれば、結構有効かもしれないと思っています。

ただ、技術系情報を載せる場合、ライトなものの方が良いという噂をよく聞きますが。
レベルが高いと折角記事を書いても、読まれる可能性が低いとか。
一定の技術力が有る人なら、公式の情報+Androidのソースを直接解析してモノ作りをするものなので、そもそもニーズが無いとか。

まぁ、私は物書きではないので、記事で宣伝とかは考えず、ゲームのラインナップを増やしていく方が堅実だと思います。折角宣伝しても、商材が「INVADER BLOCK 2」一本というのは弱すぎるので。やはり、本格的な宣伝活動に動くのなら、10本ぐらいは商材が欲しいです。そのために、開発効率よく、Android用ソフトウェアを開発できる仕組み(VG-Engine)を作った訳ですし。

結論(バージョン2.03)

INVADER BLOCK2バージョン2.03をリリースするか否か・・・結論は、リリースする方向です。
先ほど、マーケット上でアップデートを行いました。
この変更が受け入れられるか否か・・・ちょっとしたギャンブルかもしれません。

【蛇足】
あと、VGS Chiptune Musicをアップロードした時にも気になったのですが、個人情報の保護方針のURL入力を求められるようになったようなので、策定&公示しておきました。
http://hp.vector.co.jp/authors/VA040196/privacy.htm

ズラズラと色々書いてありますが、要するに個人情報の利用目的はプログラム製品の販売管理及び当事者との保守連絡(不具合への対応や要望事項に関するやりとり等)のみです。これまで、Windows用の他製品に関しても、同様の規定で対応していて、第三者への提供などは行ったことがないので、ご安心ください。

あまりにも常識的過ぎるし、法律(個人情報の保護に関する法律)でも規定されていることなので、敢えて明文する必要性を感じなかった(というより、書くと逆に「やましいことでもあるのか?」と思われてしまうと思った)のですが、求められる以上はあった方が良いと判断しました。
まぁ、しっかり意思表示しておくことは重要だと思います。

難易度論

前の記事で公開したWindows版INVADER BLOCK 2のバージョン2.03ですが、Android版をビルドして、スマホ端末(RAZR)の方にもインストールして遊んでみたんですが・・・やはり、面白さが2.56倍ぐらい大きくなった気がします。(まだ、マーケットには流してませんが)

恐らく、2.01以前は2面までしか行けなかった人も3面、4面まで行けるようになる感じになり、ゲーマーならクリアも目指せるようになったと思います。(ボーナスアイテムを無視して、とことん安全にプレイすることが容易に可能になったので)
また、ハイレベルなプレイヤーなら、より高度な戦略を組み立てられるようになったので、ライト~ヘビーの水準に関係なく、楽しめる内容に仕上がったんじゃないかな。結果として難易度が落ちたのですが、これは良い落ち方(上級者にも受け入れられる落ち方)だと思います。

本題からかなり脱線しますが、昔、将棋ゲームのドキュメントに、「弱く作る方が難しい」と書いてありました。
弱くするために、わざと悪手を打ったりしてしまうと興醒めだとも書いてありました。
まさにその通りだと思います。

実は、将棋が上手くない人の方が、将棋を上手い人よりもコンピュータで表現するには高度な思考をしていて、その熟慮の上で導き出した一手だから、対戦していて面白い・・・という事だと思います。それは、プロでも同じ(多分)。プロの対局の場合、決着が付いた後に検証みたいなことをやっていて、NHK教育の将棋番組なんかでは、放送時間が余っていたらその検証場面も流してくれる事があるのですが、それがかなり面白いので、一度は見てみることをオススメします。棋譜からは読み取れない、色々なものが分かります。要するに、コンピュータの場合、只管強くしていくことは容易なんですが、その「棋譜からは読み取れない、色々なもの」を全て表現することは不可能な訳です。将棋の、上手 or 下手に関係なく。(上手 or 下手の違いは、その部分の量と質のみ)


私は、「最近のゲームには簡単なものが多い」と感じているのですが、それは、先の例に倣えば「悪手を打つ」ような簡単さだから興醒めしてしまったのかもしれません。そうならないように、バランスを保った上で難易度を落とす工夫は必要。

今回の教訓から私が学ぶべきことは、リリースを焦り過ぎないこと。
リリース前だったら、この2.03相当の機能は即採用できたので。

あと、リプレイ機能はルールが完全に安定後の後バージョンで追加した方が良いかもしれません。
初期バージョンでつけてしまうと、ルール自体には手を入れられないので。
ただ、そうそうルールが変えられてると、プレイヤが困ってしまう可能性が高いので、その抑止機能として初期バージョンから付ける方が正解かもしれませんが。(INVADER BLOCK 2のテストプレイをやってもらった取引先の方に言わせれば、リプレイ=無駄機能とのことですが)

反射軌道も表示

どうせ、軌道を表示するのなら、反射後の軌道も表示した方が良いんじゃね?
という天の声が聞こえたので、その対策も実施。(バージョン2.03)
http://www.k2.dion.ne.jp/~ysuzuki/IBLOCK2.ZIP

恐らく、この仕様変更は、現状ご購入頂いているヘビーなゲーマーさんにも歓迎される筈。
跳ね返り角度も認識できることで、運の要素(Ninjaなら目測できなくもないかもしれませんが)をより減らすことができるから、戦略的性質(=ゲーム性)が高くなるので。

色々な議論があることかもしれませんが、ゲームにはエンターテインメント性とストラテジ性というものがあって、前者の要素が強いものが世間一般の人が持っているゲームに対する印象だと思います。
しかし、私が作るゲームを気に入っていただけた方というのは、ゲームに対してストラテジ性を求めている方に違いない・・・という楽観的な観測を信じることにしてみようと思います。

最終的な結論は、明日(今日)、よく考えてから決めますが。
睡眠不足の状態ではロクな判断ができないので。

でも、初期バージョンだったら迷わず2.03の仕様でいくのは確か。
少なくとも私にとっては、現状のINVADER BLOCK 2よりも2.5倍ぐらいは楽しくなったので。

2012年3月24日土曜日

予定軌道を表示する機能

「INVADER BLOCK 2」が難し過ぎるということで、入り口を広げるための工夫として、ボール落下時の予定軌道を表示する機能を入れてテストしているんですが、これなら、ゲーム本編の方に入れてしまっても問題無いんじゃなかろうか・・・という案が浮上してきました。

この「予定軌道を表示する機能」というのは、分かり易くいうと、下図のように落下時(ボールのY方向ベクトルが正の時)に、壁の跳ね返りのみ考慮した形で軌道をドットで表示する・・・というもの。
上図では、分かり易くするために実線で示していますが、実際のゲーム画面では破線で示した形になっています。実際にプレイして貰った方が分かり易いので、この機能を入れたバージョン(2.02)のWindows版をアップしておきます。
http://www.k2.dion.ne.jp/~ysuzuki/IBLOCK2.ZIP

これなら、互換性に影響しません。
また、既購入者(=難しいゲームが好きなゲーマーのみと想定)からも、文句言われないんじゃないかなぁ・・・と、思っています。というのも、平均よりはゲームが上手い人の場合、(このゲームでは)ちゃんと予定軌道を目視で測ってプレイしている(その上で、可能な限り得点アイテムを回収しつつ、ボールを落とさないバー運びをする戦略の組み立てを楽しんでいる)なので。

ただ、「既購入者うんぬん」の内容は、想像の域を出ません。
そして上記の想像は「楽観的な観測」なので、鵜呑みにするのは一般的に危険です。
欧米の会社は、楽観的な観測だけでとんでもない仕様変更をよくしてきますが。
しかし、私は、欧米人ではないので、最低限、オプション化(表示・非表示の切り替え)は必要かな。
しかし、設定系の操作を複雑にはしたくないので、中々厳しい。

とりあえず、マーケットに流してみて反応を伺うというのもアリかな?
・・・という、楽観的な観測もあります。
しかし、「一度追加した機能を文句を言われて外すという失態は信用問題だ」という、昔ながらのお役人さんみたいな意見もあります。(@私の脳内でのこと)

VGS Chiptune Music

「INVADER BLOCK 2」のリビジョンアップ作業に入る前に、折角作った独自音源ドライバなんだから、サンプルミュージックだけでも配っておこうと思い、Androidマーケットで無料配布しておきました。(本当は、8曲作って出そうとしてましたが、6曲のみですが...)
成果は、何かしらの形に残しておきたかったので。

アプリの名称は、「VGS Chiptune Music」(和名:VGS チップチューン音楽)。
「音楽&オーディオ」のカテゴリに流してます。
明日ぐらいには、Android Market(Google Play)で「suzukiplan」とかで検索してヒットする筈。
そういえば、有料アプリは開発者本人が買えない仕組みになっていますが、無料アプリはどうなっているんだろうか?無料アプリを公開するのは初めてなので、1回だけ試してみる予定。

これで、リビジョンアップ作業に入れます。


追記:(16:45頃)
もう公開されたようです。無料の方が反映が早いのかな。
自作アプリを自分でダウロードすることは、無料なら可能なようです。
FTPやSDカードで携帯電話にAPKを持っていく手間が省けて助かります。

あと、無料アプリだとAdMobで広告を打つことができるようです。(有料アプリだとできない)
やっぱり、無料で流して、アフィリエイトで収入を得るタイプじゃないとダメポですかね。

2012年3月23日金曜日

難易度の対策(予定)

INVADER BLOCK 2の難易度に関して、マーケットのコメントでは特に意見は無い(というよりコメントは未だ無い)ですが、やはり、難し過ぎるというのものが多いです。

ただし、ゲーム本編の難易度については、変更するつもりは無いです。
数人とはいえ買ってくれた人が居る訳だし、(私のように)現状の難易度で満足している可能性もあるので、ゲーム本編の難易度に手を入れる事は、出来ないと思っています。(ついでに、リプレイデータの互換性も保ちたい)

しかし、入り口を広げる努力はしておきたい所です。
具体的には、練習モードというのを追加しようと思っています。
練習(プラクティス)というよりは、訓練(トレーニング)的な要素の方が強いものになるかも。

ボールの予定軌道のガイドを表示するモードや、落ちる(落ちそうになる)前にボールの速度をスローダウンさせるモードなど。それらのモードで繰り返しやれば、ゲーム本編のプレイ時間を長くする効果が得られそうなものを考え中。
とりあえず、今思いついているのはその2モードですが、3モードぐらいは欲しいです。
あと、練習モードはステージ1限定+スコア・リプレイ保存無しとするつもり。
(本編はあくまでも現状のまま)

ただ、時間が足りないので、時間が若干掛かるかもしれませんが。
まぁ、そこは何とかするしかない。

2012年3月21日水曜日

入力インタフェース

AndroidMarketで色々と(自分以外の人が作った)ゲームを遊んでいて、どうも、コントローラに対する未練が多いものが多いなぁ・・・という印象が強いです。Android/iPhoneで作るからには、外付けコントローラやソフトコントローラ(画面上のコントローラの絵)からは脱却するしか無いと思いますが。

前作(INVADER BLOCK 2)の場合、幸い、入力インタフェースが左右だけだから、タッチで直感的&違和感の無い操作が簡単にできます。しかし、一番の問題は上下の移動。上下移動箇所をタッチで指示する仕様にしてしまうと、どうしても指が邪魔になります。

パズルゲームなら良いのですが、アクションゲームやシューティングゲームでは致命的。
今の所、満足できる上下左右の移動ができるゲームは(私がやった範囲では)見当たりません。
私もこれについては、上手い回避策を思いつきません。
ゲームパッドは偉大です。
未練が断ち切れないのも分からなくも無い。

で、第2弾のゲームの草案としては、「INVADER BLOCK 2」のように、コントロール対象物が左右だけではなく、上下にも移動しますが、入力に関しては左右だけでいく感じにしようと思います。
恐らく、AndroidやiPhone用の操作し易いアクションゲームを作ろうとすると、「入力は左右限定」という縛りでゲームのルールで工夫していくしか無いかな・・・と、思ったり思わなかったり。

ちなみに、上下左右の移動ができるアクションゲームの中で、一番操作性が良かったと思ったのは、CAVEの怒首領蜂大復活(体験版)。製品版も買おうとしたのですが、手持ちのAndroid機が全て未対応だったので未確認。

ちなみに、ステマではありません。“元”東亜+CAVE信者ですが。
ただ、起動するのにWeb接続が入ったりするのは微妙な感じです。
多分、スタンドアロンにしなかったのは、価格と収益の関係で仕方の無いことだと思いますが、スタンドアロン起動可能だったら倍以上の値段でも買うのに。ついでに、大復活ではなく、初期の怒首領蜂か大往生が、大復活と同等の操作性&スタンドアロンなら、10倍程度の値段でも欲しい。

2012年3月20日火曜日

解析断念

ptcopの解析は断念。
調べれば何とかなりそうな感じでしたが、ピスコラで作り溜めた曲はせいぜい20曲ぐらいだし、MMLの打ち込みにもだいぶ慣れてきて、一日3~5曲程度ならアナログ方式(ピスコラのピアノロールを見ながらMMLを書き起こす)でできそうな感じなので、解析を完遂させる労力に見合わないと判断。(解析ができても、そこからMMLにデコードするのも面倒だし)

曲はとりあえず、5曲ほど、MML化しました。
8曲ぐらいできたら、無償でストアに流します。(たぶん)

2012年3月19日月曜日

ptcopを解析中...

ptcopファイルの音符情報等(EventV5レコード)の解析ですが・・・中々厄介だということは、把握。
ピスコラ自体、あまり「誰もが知っている」というレベルで普及しているものではないので、解析データの情報が転がっていない(海外にかなり間違ったデータを載せているものはありましたが...)から、色々と試行錯誤しながら解析しています。

とりあえず、かなり適当に作ったコンバータで、4部休符+4部音符(音程はc)を2小節(音符はオクターブ0と1を交互に)鳴らすptcopを解析したところ、こんな感じになりました。
Number of event: 25
    1: Tr#00/Ev#0C: Inst: 0000(0)
-----: Tr#00: Wait=01f0(496)
    2: Tr#00/Ev#02: Key : 6680(26240)
    3: Tr#00/Ev#01: Len : 01f0(496)
    4: Tr#00/Ev#04: Vel : 0068(104)
-----: Tr#00: Wait=03e0(992)
    5: Tr#00/Ev#02: Key : 7e80(32384)
    6: Tr#00/Ev#01: Len : 01f0(496)
    7: Tr#00/Ev#04: Vel : 0068(104)
-----: Tr#00: Wait=03e0(992)
    8: Tr#00/Ev#02: Key : 6680(26240)
    9: Tr#00/Ev#01: Len : 01f0(496)
   10: Tr#00/Ev#04: Vel : 0068(104)
-----: Tr#00: Wait=03e0(992)
   11: Tr#00/Ev#02: Key : 7e80(32384)
   12: Tr#00/Ev#01: Len : 01f0(496)
   13: Tr#00/Ev#04: Vel : 0068(104)
-----: Tr#00: Wait=03e0(992)
   14: Tr#00/Ev#02: Key : 6680(26240)
   15: Tr#00/Ev#01: Len : 01f0(496)
   16: Tr#00/Ev#04: Vel : 0068(104)
-----: Tr#00: Wait=03e0(992)
   17: Tr#00/Ev#02: Key : 7e80(32384)
   18: Tr#00/Ev#01: Len : 01f0(496)
   19: Tr#00/Ev#04: Vel : 0068(104)
-----: Tr#00: Wait=03e0(992)
   20: Tr#00/Ev#02: Key : 6680(26240)
   21: Tr#00/Ev#01: Len : 01f0(496)
   22: Tr#00/Ev#04: Vel : 0068(104)
-----: Tr#00: Wait=03e0(992)
   23: Tr#00/Ev#02: Key : 7e80(32384)
   24: Tr#00/Ev#01: Len : 01f0(496)
   25: Tr#00/Ev#04: Vel : 0068(104)
-----: Tr#00: Wait=6574(25972)


・・・ここまででもちょっと面倒でした。
しかし、まだ色々と読み違えている箇所があるようです。
なので、上記解析は未だ間違っているのかもしれません。
結構複雑です。

“V5”ということは、色々と仕様面で綺麗にはできていないだろう・・・と、想定済みですが。

2012年3月18日日曜日

色々と移植中

Android用の独自PSG音源は一応完成しましたが、実際に曲を打ち込んでみて、音源(またはMMLコンパイラ)のブラッシュアップを図る作業中。

私は、音楽の作曲にピストンコラージュを用いてますが、ピスコラのデータ形式(ptcop又はpttune)は公開されていないようなので、MMLに打ち込み直す作業に結構時間が掛かりました。
約50小説の曲でだいたい1人日ぐらい。(今日の昼ぐらいから作り始めて今1曲完成)

ノート(音符)データなら、MasterV5レコードEventV5レコード(ptcopの内部データ形式)あたりを解析すれば取り出せそうな感じなので、コンバータを作るのに丸1週間程度掛けても、余裕で元が取れるな・・・と、思い始めてます。

昔作った曲を~10曲程度作ったら、ジュークボックスみたいな形にして、Marketでタダで配る予定。
ちなみに、↓こういう曲ばかり。(ズンダラ節っていうんですかね?)
http://www.k2.dion.ne.jp/~ysuzuki/game06/bgm09.mp3
※上記は、ピスコラで作ったもの

2012年3月17日土曜日

独自PSG音源の実機検証

Android用に作っているPSG音源なのに、Android上で一回も鳴らしたことが無かった(Windowsでのみ確認していた)ので、Android向けにコンパイルして鳴らしてみました。

ちなみに、画面(Windows/Android共通)は下記のような感じです。

結果は良好。
当然ながら、鳴っている音の内容も全くWindows版と同じ。
ただ、ちょっと音が丸くなったかもしれません。
これはスピーカーの個体差かな。


動作はかなり軽快です。

このテスタをバックグラウンドでループ再生し続けた状態で、INVADER BLOCK 2を起動してみましたが、全く処理落ちせずに動作できました。CPU使用率にかなりの余裕があるので、デバッグ機(LenovoのIdea Pad 01)よりも遅い環境でも問題無いと思います。

多少の表現能力を犠牲にしてでも性能を追求した甲斐がありました。

Android用・独自PSG音源(VGS)の仕様

概ね、Android用・独自PSG音源の仕様が固まったので、纏めておきます。
  • 基本情報: 22050Hz + 16bit + モノラル(秒間約43キロバイト程度)
  • 同時発声: 6ch (6声)
  • 分解精度: 1/22050 (1Hz毎にキーオン等のイベント指令が可能)
  • 波形数: 4種類(三角波、ノコギリ波、短形波、 短形ノイズ)のプリセットのみ
  • エンベロープ:  各ch毎(6系統) & キーオン・キーオフ毎(2系統) に設定可能
  • ピッチシフト: 各ch毎に周波数精度の自動ピッチアップ・ピッチダウンに対応
  • ボリューム: マスターボリューム+チャネル別ボリューム
  • 処理性能: 500MHz程度のマシンで、CPUを最大2~3%占有する
  • 発音例:  http://www.k2.dion.ne.jp/~ysuzuki/sample2.mp3 (※ノイズとピッチシフトは未使用)
シンプル過ぎるぐらいシンプルですが、ゲーム音楽用の音源としてはこれぐらいが丁度良いです。

Android搭載用ということで、消費電力を気をつけなければいけないから、性能には拘りました。
普通、波形計算には浮動小数点数が使われるのですが、全て整数で計算したりとか。
なお、AndroidのAPIが全般的に浮動小数点数を多様するものが多いので、Android端末のCPU(ARM)は、FPUが特化しているのかな?・・・と思ったのですが、それ程でもなかったので、計算は全て整数で行うのが正解です。(単にAndroidIを作った人が性能に関して疎かっただけ)


ドラム音源

独自PSG音源のドラムは、完全にプリセットのPCMでいこうとしたのですが、自動的にキーダウン・キーアップする機能がやっぱり欲しかったので、ドラムもPSGで鳴らす方向で。

↓こんな感じになりました。
http://www.k2.dion.ne.jp/~ysuzuki/drum.mp3

まぁ、ショボイですが、この方がPSG音源とも調和が取れるので良いかも。
音源については、あとはループ再生する命令を実装すれば一通り完成。
ようやく、本編(ゲーム)の開発に戻れそうです。

そういえば、前作(INVADER BLOCK 2)ですが、マーケットでは意見を貰えるほどダウンロードされていないので、会社の人や取引先の人から意見を収集したところ、主に以下のような指摘がありました。

①難しすぎる
②残機が欲しい(1機でゲームオーバーという仕様)
③何故、Android 2.2対応にしなかったし

これでもかなり難度を落としたのですが、まだまだのようです。
②は単純に①の影響で1回のプレイ時間が満足のいくものでないことが原因だと思います。
ということで、難易度が一番のネック。

でも、易し過ぎると私が遊べなくなってしまいます。
という訳で、次回作ではEasy/Normal/Hardみたいな感じのランク設定を設ける予定。
たぶん、私が作るゲームでは初めての試みになる筈。
一応、昔作ったSHOT02というゲームにエキスパート・モードみたいなものがありましたが。


あと、取引先の人のAndroidが2.2でした。
やはり、2.2の普及率は侮れない。
でも、2.3.3以降にしないとOpenSLが使えないからどうにもなりません。
OpenSLじゃないと、波形データを直書きできないので。
波形データを直書きできないということは、(音関係では)何もできないも同然。

2012年3月15日木曜日

脳内で鳴っていた筈の音

昨日、独自PSG音源で鳴らしたサンプルをアップしていたのですが、実の所、MMLで書いた内容と微妙に違ってて、違和感みたいなものを感じていました。

「まぁ、こんなもんだろ」程度に思っていたのですが、実は、MMLコンパイラがバグっていて、本来、各チャネルに設定できる筈のエンベロープが、全てチャネル0にしか設定されず、チャネル1~5はデフォルトのエンベロープで鳴っていた・・・という、かなりしょっぱいバグでした。

正しい演奏は、下記。
http://www.k2.dion.ne.jp/~ysuzuki/sample2.mp3

昨日アップロードしたしょっぱいヤツは、下記。
http://www.k2.dion.ne.jp/~ysuzuki/sample1.mp3

何故、昨日の時点で耳で気付けなかったのか・・・。
作曲や音楽は完全に専門外ですが、それにしては酷いイージーミスです。

2012年3月14日水曜日

独自音源の実力(当社比)

とりあえず、独自PSG音源で音楽らしい音楽を鳴らせるようになったのに、「蛙の歌」や「キラキラ星」などの童謡しか鳴らさないのはどうよ?・・・という訳で、自作の曲で現状の独自PSG音源の実力を100%発揮した音楽を作ってみました。

http://www.k2.dion.ne.jp/~ysuzuki/sample1.mp3

現状、ドラム機能がないので、ドラムの無い曲。
新曲ではなく、1年ぐらい前にピスコラで作った曲ですが。
とりあえず、6チャンネル全て使って鳴らしています。

とりあえず、これが現状の音源の表現性能の限界・・・という訳ではないですが。
作曲の腕前がイマイチなので、表現性能としては限界値に達せません。
実装した機能を全て使っているので、機能的な限界なのは確かですが。

次の課題は、ドラム音源の搭載。
とりあえず、申し訳ない程度のノイズ音源を実装してみましたが、やはりキーダウンとか、性能影響がありそうな機能追加が必要になってしまうので、やはり、PCMをそのまま鳴らす方向がベストか。

デューティー比は落とす

ここ数日、独自PSG音源エミュレータを作成する方向で作業をしていましたが、ちょっと転機。

当初、波形は「三角波」、「ノコギリ波」、「短形波」の3種類で、デューティー比を弄れる感じにしようと思ったのですが、基本周波数が22050Hzだとあまり綺麗な音が鳴らなかったので、デューティー比は5:5固定にします。

そうなると、独自PSG音源は、PSG音源ではなく、独自の波形メモリ音源になるのかな?
少なくとも、波形に関してはプログラマブルではなく、完全固定になるので。
そもそも、私は「PSG音源」の厳密な定義はよく分かっていませんが。
「プログラムで弄り易い音源」という意味なら、波形メモリ音源もPSGの一種のような気もする。

ちなみに、デューティー比というのは、波形の正負値の比率のことです。

例:デューティー比5:5の正弦波

で、この比率を変えると、音色が「かなり」変化します。
波形エディタで書いて鳴らしてみると、楽しいかもしれません。
波形エディタは、下記URLにある「効果音エディタ_D」というのがオススメ。
http://www.geocities.jp/hirogamesoft/se_d/se_d.html



デューティー比が弄れれば、波形パターン(音色数)が少なくても、色々な音色が作れます...
なので、性能のためとはいえ、ちょっと残念かも。
遅くとも600MHz程度の超高速なCPUを積んでいるAndroid端末なら、全然気にならないレベルなんですが、CPU占有が多すぎると消費電力量が多くなってしまうので、やはり、性能を一番気にしておきたいところ。

2012年3月13日火曜日

合成完成

前の記事に書いたとおりのアルゴリズムで、音符の合成ロジックを作ってみたところ、アッサリと合成処理が完成。

プログラムを書くのより、サンプルの演奏データを作る方が時間が掛かったかも。
とりあえず、↓こんな感じ。
http://www.k2.dion.ne.jp/~ysuzuki/seikou4.mp3

ようやく、音楽らしい音楽を鳴らせるところまできました。
あとは、MMLで色々と細かいけど重要な機能を色々追加すれば、音源機能はとりあえず完成かな。
当初、ノイズ音源も作ろうとしましたが、ノイズ(ドラム)はPCMの固定波形パターンを鳴らせば良いんじゃないかと、思い始めました。(その方が、処理が軽いので)

いっぺんにやろうとするから難しい

独自PSG音源専用のMMLコンパイラで、とりあえず、1チャネルで音楽を鳴らすことに成功。
毎日だいたい夜11:00頃帰宅(これでも早いほう)なので、ウィークデーの進捗はこの程度。
次の課題は「複数チャネルの音をどうやって同時に鳴らすか」。

まぁ、その辺は簡単に計算できます。
今のところ、PSG音源に対する指示情報としては、以下の7種類。

  1. エンベロープ1を設定(キーオンしてから100%になるまでの周波数)
  2. エンベロープ2を設定(オーオフしてから消音になるまでの周波数)
  3. チャネル別のボリュームを設定
  4. マスターボリュームを設定
  5. キーオン(音を鳴らす指示)※音色や音程も一緒に指定する仕様
  6. キーオフ(音を止める指示)
  7. 待機

網掛けしている待機という指示情報だけに着眼すれば良いだけです。

仮に、
  • Ch.1: event1 → wait(100Hz) → event2
  • Ch.2: event3 → wait(50Hz) → event4 → wait(75Hz) → event5
という感じで並んでいたら、

event1 → event3 → wait(50Hz) → event4 → wait(50hz) → event2 → wait(25Hz) → event5

という感じにすればOK。

アルゴリズム的に表現すれば、

  1. 待機時間が短い方の待機時間を採用し、
  2. 長い方(非採用)の待機時間は、採用値を減算
  3. 次の待機時間についても同じ処理で求める

で、OKな筈。(未検証)

処理としては単純。
問題は6チャネルの場合、フラグが沢山有り過ぎて、アルゴリズムが無茶苦茶複雑になりそうだ・・・
と、思っていたのですが、ピンポン録音の要領で、

  1. チャネル1+チャネル2=チャネルA
  2. チャネルA+チャネル3=チャネルB
  3. チャネルB+チャネル4=チャネルC
  4. チャネルC+チャネル5=チャネルD
  5. チャネルD+チャネル6=チャネルE

って、やれば良いだけですね。
物凄く簡単だった。

これなら、明日にはチャネル合成ができるかな。(本業の状況次第ですが)

ちなみに、チャネル毎の音の合成(音源レベルの話)をどうやるのか疑問だったのですが、これは単純な足し算でOKでした。音の合成ってこんな簡単だったのか。(てっきり、もっと複雑な「xxxの公式」みたいなヤツでも要るのかと)

2012年3月11日日曜日

構文解析まではできた

独自PSG音源エミュレータで音楽を鳴らすためのMMLコンパイラを作成中。
本当は、この土日で完成させる予定でしたが、昨日、スマートフォンを買ったり、色々と設定やらをしたり、遊んでいたところ、完成しなかった・・・orz

とりあえず、今日の昼から開発を再開して、構文解析まではほぼ完成。
ただ、色々と細かい所ができてないです。

構文仕様としては、下図のような感じになりました。(色々足りないかも)

ごく簡単なマクロ言語です。
「$なにがし」でマクロを定義して、「Ch0~5」でチャネル毎の音符情報を書きます。

分解性能を周波数と同値にしたお陰で、「%」というオペランドを使って、音の長さに対するキーオンの時間の割合というものを定義できました(これがやりたかった)。%を低めに設定すればスタッカートみたいな感じになり、高めに設定すればレガートになる感じです。

ちなみに、ボリューム(音量)としては、マスターボリューム(全チャネル共通のボリューム)とチャネル別のボリュームのみで、ヴェロシティ(音符単位のボリューム)は無い仕様にしました。
できなくもないけど、私が作る曲では概ね要りません。
必要な時は、MIDIからの変換ツールの方でボリュームオペランド(v)で調整すれば良いし。
ただ、それだとデータ量が多くなってしまうので、改善の余地ありかもしれませんが、今のところ、多彩なヴェロシティの曲を作るつもりは無いというのが一番の理由。)
一応、データ的にはヴェロシティーに対応させる空き領域は有りますが。

ヒープ破壊のチェック方法@Windows

大方のAndroidプログラマの方には無縁だと思いますが、私が作るアプリの場合、コードの9割強がC/C++で作られているので、ヒープ破壊のバグが発生すると、必然的にデバッグが極めて困難になります。
勿論、ダンプが取れれば、壊れた形跡から概ね何処で壊したか特定できますが。
ヒープ破壊の厄介なところは、壊れ方によっては、何の問題も無く動いてしまうところ。
(スタック破壊なら、/RTCsオプションとかでチェックできますが)

Linuxであればvalgrindを使えば、ヒープ破壊のチェックができますが。
しかし、WindowsのC(VisualC)でAndroid用のソフトを開発している私の場合、それは無理。

RationalのPurifyを使えば、チェックできますが、色々と設定が面倒くさい。
インストゥルメントしてしまうと、動きも重くなってしまうし、モノによっては正常に動かなくなります。
ついでに、結構値段が高いPurifyを個人で買うのはちょっと・・・

Windowsで、お金を掛けずにヒープ破壊のチェックをしたければ、Debugging Tools for Windowsの付属ツール(gflags)を使い、未確保の領域を触った時点でクラッシュさせてあげれば良いです。

gflags -p /full /enable 実行ファイル名

という感じでやってから実行ファイルを実行すれば、未確保の領域を触ったときに落ちてくれます。
あと、実行ファイルをコンパイルする際に/Ziオプションを付与してデバッグ情報をオブジェクトモジュールに設定し、リンク時に/DEBUGオプション+/PDBオプションでPDBを作ってあげれば、コールスタックから落ちた位置を簡単に特定できます。

Debugging Tools for Windowsは、Microsoftからタダで落とせます。
かなり便利なツールの宝庫なので、色々と使ってみると楽しいですよ。
ドキュメントは全部英語なので、読むのが面倒くさいですが。


追記: ちなみにゲームの場合、ヒープは起動時に全部確保して、停止時に全部開放します。
動作中は動的メモリを一切確保せず、リングバッファのみで情報を管理するのが普通。
実は、ヒープの確保は結構重いので、仮に大した量でなくてもそうすることが、ゲーム作りでは常識。
ちなみに、私にはもう関係無いことですが、Javaの場合、アプリはJヒープ(JavaHeap)という領域を使いますが、これはもっと重い。
多分、Javaを開発した当初は、エクスプリシット(参照カウンタが全部外れれば解放する)で作っていたと思うのですが、Jヒープの余りの重さに悩んだSunの技術者が、「ヒマな時に解放すればよいんでない?」程度の浅はかな考えで、GCなる処理を作ったんだろうと思います。(私はSunの人間ではないので単なる勘ですが)
Javaでゲームを作っている人は大変だろうなぁ・・・と、思います。

2012年3月10日土曜日

広報活動(INVADER BLOCK2)

INVADER BLOCK2の広報活動として、フリーゲーム夢現さんにWindows版の記事を投稿。
フリーゲーム夢現さんは、リンクの少なさに定評がある私のホームページ(http://hp.vector.co.jp/authors/VA040196/)のリンクに載せているゲームレビューサイトです。
「リンクが少ない」っていうより、現状、フリーゲーム夢現さんしか載せてませんが。

フリーゲーム夢現さんは、去年SHOT03を販売した時にも利用させていただきました。
SHOT03は、今になって思えば、フリーで出しておけばそこそこ遊んで貰えたかも。
それでも、300本ぐらいはダウンロードされたので、「フリーじゃないから売れなかった」のではなく、純粋にツマらなかったのであろう・・・と、反省しておきます。(フリーだとそもそも売れませんが)

幸い、INVADER BLOCK2は現時点で数本、売れました。
ご購入いただいた方々は本当にありがとうございます。
正直な所、「1本も売れないんじゃないか」と思っていたので、最初の1本が売れた時は驚きました。

ちなみに、INVADER BLOCK2が売れ始めたのは、VectorでWindows版を無償公開後。
Windows版を無償で公開するというやり方は、中々良かったかもしれません。
それをやるのは、技術的に少し大変かもしれませんが。
(エミュレータを作れる程度の技術力があれば、簡単に作れます)

なるほど

スマホといえど、携帯の延長線上のものだろ・・・と思ってナメていたいのですが、確かに便利。
携帯と違い、5,000円/月払ってもまぁ良いかな・・・と、思える代物でした。
在宅時はWiFiをonにすれば、動画もサクサク見れる。
動画を再生すると、電池の減り方が大分アレですが。

入力系統はどうあがいてもWindowsには敵わないので、開発や文書を書く作業には向きません。
しかし、エンターテインメント的な要素で使う分には、PCよりも洗練されているという印象。

ただ、PCの方は、Windows8でひと波乱有りそうな気がしますが。
仕事道具としては、iOS/Androidなんかより断然、Windowsの方が使い易かったのに・・・
まだ、評価版を会社で触ってみただけなので、製品版ではどうなるか分かりませんが。

私見ですが、Windowsはタブレットなんかに載せず、PC専用のOSとしてシェアを保つのが最善の選択肢だと思っています。
しかし、Windows8は単なるiOS/Androidの劣化版・・・というのが正直な印象。
元々、Windows自体がMacをパクッて作ったものなので、今に始まったことではないですが。
そして、昔はそれで上手くいったので、Microsoftが8でコケるか否かは未知数か。

変えました

スマホに機種変更してきました。 機種は、モトローラのRAZR。
http://plusd.itmedia.co.jp/mobile/articles/1202/27/news065.html

決め手は、Android4.0へのアップデートを予定しているという点。
 私が開発・販売するアプリケーションの対象OSは、Android2.3系統ですが。
 タブレット(ideapad)の方を「想定最低OS」のデバッグ専用機にする方向。
 スマホ(RAZR)の方は、最終点検+私用用途ということで、最新状態を保ちます。 

料金は、来月から2年間、3980円(定額通信)+399円(保険)+780円(基本料金)/月。
 3年目以降、4480円+399円+780円/月。
 ちょっと想定(月5k未満)よりも高くなってしまった... 
どうやら、5460円の中には、電話+EZWEBの基本料金(780円)が含まれないらしい。
 まぁ、良いか。

 「アプリ販売で賄えるようにする」 という目標ができたということで良しとしておきます。
 使用実績が少なければ、固定定額プラン(5,460円/月)から約2,000円/月~6,000円/月の範囲の変動プランにすれば、概ね許容範囲にできるようですし。 

あと、どうでも良いことですが、初期費用=本体価格(約55,000円)が、月賦でも一括払いでも支払額が同じというのが微妙な気分。 

ちなみに、INVADER BLOCK 2をスマホ(RAZR)にインストールして遊んでみましたが、タブレットよりもかなり遊び易い。 画面が小さくて遊びづらいんじゃないかな?と心配していたのですが、安心しました。

変え時か

Androidアプリを作ってはいるけど、実はスマートフォンを持っていません。 3G契約不要のタブレットで使えば良いので。 ネックなのは、月額費の高さ。 普通の携帯電話なら月1,000円ぐらいですが、スマートフォンだと月5,480円ぐらい。 ただ、どうもauの光通信に加入していれば、月1,500円程度安くなるらしい。 ただし、1,500円安くなるのは最大2年で、3年目以降は月1,000円引き(月4,480円)らしいですが。 まぁ、月5,000円未満なら、悪く無さそうだと思い始めました。

2012年3月8日木曜日

音が鳴らない問題 (更新3※解決)

今日、会社でINVADER BLOCK 2で遊んでいたのデバッグをしていたところ、何故か、音が鳴らない現象が発生し、一瞬「バグかな?」と思い、焦りました。

しかし、INVADER BLOCK 2のプロセスを止めて再起動しても現象が再発します。
なので、どうやら、INVADER BLOCK 2のバグではなさそうです。(推測ですが)

帰宅後にlogcatでログを確認してみたところ、AudioFlingerというプロセスが、「TrackBase::getBuffer buffer out of range:」みたいな感じのエラーを延々と出し続けていました。

AudioFlingerというのは、Androidの音声入出力を担うプログラムのようです。
ググればソースコードも見つかります。
問題のエラーを出している部分の実装は、以下のような感じでした。

■AudioFlinger.cppより抜粋
void* AudioFlinger::ThreadBase::TrackBase::getBuffer(uint32_t offset, uint32_t frames) const {
    audio_track_cblk_t* cblk = this->cblk();
    int8_t *bufferStart = (int8_t *)mBuffer + (offset-cblk->serverBase)*cblk->frameSize;
    int8_t *bufferEnd = bufferStart + frames * cblk->frameSize;


    // Check validity of returned pointer in case the track control block would have been corrupted.
    if (bufferStart < mBuffer || bufferStart > bufferEnd || bufferEnd > mBufferEnd ||
        ((unsigned long)bufferStart & (unsigned long)(cblk->frameSize - 1))) {
        LOGE("TrackBase::getBuffer buffer out of range:\n    start: %p, end %p , mBuffer %p mBufferEnd %p\n    \
                server %d, serverBase %d, user %d, userBase %d, channels %d",
                bufferStart, bufferEnd, mBuffer, mBufferEnd,
                cblk->server, cblk->serverBase, cblk->user, cblk->userBase, cblk->channels);
        return 0;
    }


    return bufferStart;
}
※このソースのライセンスはApache License 2.0です

たぶん、波形情報のバッファを取り出して再生をおこなうための処理だと思います。
何らかの原因でバッファが不整合な状態になり、それが継続してしまい、音が鳴らなくなった・・・という感じでしょうか。

別のプログラムが不正なバッファを渡し続けていて、それに巻き込まれたのかな?
または、AudioFlingerの不良?

こういう場合の調査は、「非は自分にある」と断定してするのが鉄則なので、愚直にINVADER BLOCK 2の処理に問題がないのかも点検しておきます。

ちなみに、INVADER BLOCK 2は、OpenSLを使って音声出力の処理を行っていますが、OpenSL自体、まだ出て間もないもののようなので、OpenSLのバグという可能性も・・・まぁ、そこは気にせず、「非は自分にある」と断定して。


■追記1 (2012/03/09 00:30頃)
愚直にコードを見直してますが、「コレだ!」と確証の持てるバグは無いです。
あと、現象を再現させるために、色々怪しそうな操作をしていますが、一度も再現してません。
海外に幾らか同件と思しき現象の報告のようなものがありますが、解決はしていなさそう。
ちょっと、OS側のソースを解析してみようか考え中。(今日はもうやりませんが)



■追記2 (2012/03/10 00:30頃)
やはり、アプリケーション(INVADER BLOCK 2)の問題ではなさそうな気がします。
そもそも、アプリのプロセスを止めているのに発生し続けていた時点で、その点は確定ですが。
(この問題が発生すると、Androidを再起動するまで現象が発生し続けます)

仮に、アプリレベルで引き起こせる問題だと、もっと世界中で大問題になっている筈。
それにしては、情報が少な過ぎます。
同件と思しき現象が発生しているっぽい情報は以下。(2009年の情報)
http://code.google.com/p/android/issues/detail?id=3197

ちなみにこの現象ですが、開発中は1回も発生したことが無いです。
開発が終了した3月1日に、ちょっとした勘違いでOSのアップデートをしてしまったのですが、それ以降発生したという点がちょっと怪しい。つまり、OSがアップデートでデグった可能性もゼロではないのではないかと。ちなみに、現象が発生したOSは、現時点(3月10日時点)でLenovoの IdeaPad Tablet A1 に適用できる最新のAndroid 2.3.4。(リリースされてから日が浅いため、情報が少ないとか)

もうひとつ、考えられるのが、常駐プログラムの不具合。
OSの不具合だとすると情報が少な過ぎるので、可能性としてはそっちの方が高い。
ちなみに、私の端末で常駐させているプロセスは、

①設定
②Androidシステム
③Googleサービス
④マップ
⑤GO Keyboard for Lenovo

とりあえず、「④マップ」は要らないので消そうとしたところ、結構中核のもの?っぽいことが書いてあったし、音は出さないだろうから放置で。

「⑤GO Keyboard for Lenovo」は音を出すアプリなのでちょっと関係しそう。
念のため、普通のAndroidキーボード(無音)に変更。
この状態で再発したら、再び更新します。
それまで様子見。



■追記3 (2012/03/18 00:30頃)
再現はしてませんが、OS側の実装を調査した結果、原因が判明しました。
INVADER BLOCK 2のバグということになります。
修正版のINVADER BLOCK 2は先ほどリリースしました。


で、問題の原因ですが、OpenSLのリソース解放関連の処理手続きに問題がありました。
解放(Destroy)を行う前にSetPlayStateでSL_PLAYSTATE_STOPPEDにする必要があるようです。
SL_PLAYSTATE_STOPPEDとDestroyでググれば、色々と情報が出てきました。
↓日本語の情報も有りました。
http://www.ku6.jp/report/5.html 



上記記事で書かれている通り、SL_PLAYSTATE_STOPPEDにしなければなりませんそうしないと、音声バッファが不整合な状態になることで、AudioFlingerにヘンなデータが渡ってしまい、結果として「TrackBase::getBuffer buffer out of range」の洪水が起きる形になり得ます。

2012年3月7日水曜日

性能良好

作成した自作PSG音源エミュレータ+ドライバでベンチマークをしてみました。
あんまり厳密な解析じゃないけど。

ちなみに測定環境は、

  • 型式:Acer AspireRevo R3610
  • CPU:Atom330 / 1.6GHz / 64Bit
  • メモリー:4GB

という、環境。
CPUに関しては、性能の悪さに定評のあるAtom。

この環境で開発もやっているから、Android用のコンパイルには物凄く時間が掛かります。
ですが、ベンチマーク用としては妥当です。
グラフィック(GPU)性能がちょっと良すぎる点がアレですが。

まず、VG-Engine(グラフィックのみ)でプロセスを起動した場合、CPU使用率は約5%前後。
で、VG-Sound(と、命名したオリジナルPSG音源エミュレータ)で、6ch同時に発音した状態で測定したところ、CPU使用率は概ね約7~8%前後。

ちょっとだけ、上がってしまいました。
ですが、この程度であれば、Android上でもサクサク動けます。(多分)

かなり、性能面には気をつけました。主に、

  • パイプラインハザードの防止
  • 浮動小数点は使わない
あたり。

前者は単純に分岐回数を可能な限り少なくするだけ。
(ループ値は論理積を使うなど)

後者は、本当に性能upに寄与するか、ケースバイケース。
例えば、エンベロープの計算に百分率が必須ですが、百分率を整数のみで計算する場合、
  • 割られる数×100 ÷ 割る数 = p(100%なら100)
  • n×p÷100 = nのp%の値
という感じで計算します。
※ここでは説明をし易くするために百分率といってますが、 実際は128分率とか64分率などで計算するのが一般的

FPUが高性能な場合、全ての数値を浮動小数点数で計算すれば、結果的には浮動小数点数のみで計算した方が命令の実行ステップが少ない分、高速になる可能性があります。ただ、実数は精度が悪い(表現できない数が多い)ので、「全てを浮動小数点数で」という部分がネック。音の場合、波形データは整数(16bitの2の補数)だから、FPUが早くても整数・実数間の変換がボトルネックになるし、パイプラインハザードは極力実装レベルでも防いでいるからステップ数はあまり問題にならない筈だ・・・

ということを悶々と考えた結果、実数を排除するのがベストと判断。
(単純に、実数がキライだというのもあります)

結果、Windowsではそこそこ良い性能結果だったので、読みは当ったんだろうと、思っておきます。
Androidでも同じ結果になるかは、定かではないですが。

音源ドライバ完成

週末は、MMLコンパイラを作る作業に専念したいため、前記事の分解率の問題を平日中に直してしまおう・・・と、思い昨夜、AM2:00ぐらいまで頑張っていたら、今日会社でグロッキー状態でした。
30を過ぎると、2時寝・6時起きはキツイ。

その甲斐あって、無事、音源ドライバ部分も完成。
以下のような感じで発音(KEYON)や消音(KEYOFF)などの指示情報をズラズラ並べれば・・・



↓こんな感じで演奏してくれます。
http://www.k2.dion.ne.jp/~ysuzuki/seikou3.mp3

若干、音程が切り替わる間のプツッという部分が気になります。
こういう風になる原因は、音が切り替わった時の直前の波形からの差異が大きいため。

パッと考え付く限り、回避する手段は、

  • 消音のエンベロープ時間を短くし、キーオフの待ち時間中に波形相異0で安定させる
  • キー切り替え時に近似値を算出し、乖離を少なくする

あたりかな。

前者は、MMLコンパイラで回避でき、後者はアルゴリズムで回避。
どっちが良いのかが、よく分からない。

2012年3月5日月曜日

分解率(解決)

昨日、独自PSG音源の分解率(分解性能)のことで難産してましたが、解が見えてきました。

VG-Engineの音声システムは、100ミリ秒の周期で発音情報をD/A変換(ディジタルデータを音に変換)する形で音声を鳴らしています。WindowsとAndroidで、この部分の実装に用いる仕組みは違いますが、理屈は同じ。

  • Windows(DirectSound)の場合: 次の動作をする専用スレッドでループ処理
    1. 100ms分の音バッファを作る
    2. D/A変換
    3. 100再生完了のイベント待機
  • Android(OpenSL|ES)の場合:  100ms再生完了する都度、次の処理を実行(コールバック)
    1. 100ms分の音バッファを作る
    2. D/A変換

で、独自PSG音源+ドライバ(音源を発音させたり、消音させたりする処理部分のこと)は、何れも「100ms分の音バッファを作る」処理部分で実装してます。

問題があったのは、独自PSG音源の①発音(キーオン)、②消音(キーオフ)、③無音で処理をスイッチ的に切り分けていたこと。だから、そこでドライバのキーオンやキーオフの指示を処理するのが難しかった訳です。

なので、その部分の処理をスイッチ的に切り分けるのではなく、キーオン、キーオフ、無音などの状態に関係無く、常に(元々の)①発音(キーオン)相当として処理すれば良い訳です。

偉そうに言ってますが、実はコレ(スイッチ的に切り分けること自体が)、単純なバグじゃないか・・・
・・・ということに、この記事を書いていて気付きました。
何故昨日、気付かなかったし。
まぁ、バグとは得てしてそういうものか。
(ロジック的なバグは、処理を言葉で書いて整理すれば、解決し易い)

分解率=分解性能(かなり厄介)

先ほどの記事で、独自PSG音源のドライバ(バイナリのMMLを鳴らす機能)の分解率(分解性能と呼ぶべきか?)を22050回/秒にしようとしましたが、処理実装上、それは不可能・・・ではないけど、もの凄く複雑なことになりそうです。

素直に、音源とドライバは別スレッドで独立させてあげれば楽。
中々面倒です。
しかも、そうなると、分解率は1000回/秒か。
まぁ、1秒間に1000回も音符を鳴らす音楽は想定されないけど。

もの凄い複雑な処理をあくまでもシングルスレッドで実装するか。
又は、簡素にマルチスレッドで実装するか。
私の好みは前者ですが。
スレッドはオーバーヘッドが大きいので、不可避な事情が無い限り、使わない派。

プログラミングを始めた頃(11歳頃)から現在にかけて出会った、難しいロジックのベスト30位以内に入ると思います。公私で膨大な量のプログラムを日々作り続けているから、あまり定かではないですが。

さて、どうしたものか。。。

全然関係ありませんが、、プログラミングを始めた歳を書いて気付きました。
来年でプログラミング歴20年のようです。
時が経つのは、何とはやいことか・・・


2012年3月4日日曜日

分解率

独自PSG音源のMMLを実装していますが、分解率は、秒間22050回にする方向で。
つまり、周波数(22050Hz)と同じ。
分解率というのは、1秒間に音符を鳴らせる回数の上限。
その分、処理負荷が掛かりますが、この分解率如何で表現の幅が変わるから、ここは落とせない。
これを最大限に細かくするために、周波数を22050Hzにしたり、音色を固定プリセットにしたりするなど、処理性能を最大限に高めたといっても過言ではないです。

これが完成すれば、独自PSG音源について、残すTODOはMMLコンバータとMIDIコンバータを作る等の面倒な作業を残すのみ。

MMLコンバータは良いけど、MIDIコンバータは規格を解析するのが少しだけ面倒くさい。
なので、MMLコンバータ単体で作り易くしておき、MIDIコンバータは後付にする方向。
というより、MIDIコンバータは作りらないかも。
昔(PC-9801の頃)は、PMDのMMLで何一つ不自由しなかったし。

中々美しく響きます

独自PSG音源で、高音部が上手く鳴らせなかったのですが、どうもプリセットするバッファサイズが小さいことが原因だった模様。

1秒の周波数 = 88200Hz

という実際に鳴らす音(22050Hz)の×4のバッファサイズをプリセットに準備することで解決。
ようやく機械調整での調律が完了。

以下↓は、この状態で手何も手を入れずに、エンベロープを実装して鳴らしたもの。
http://www.k2.dion.ne.jp/~ysuzuki/seikou2.mp3

良い感じで、美しく鳴ってくれました。

×4バッファなら手動調整は不要そうです。
これで、独自PSG音源の音源部はほぼ完成か。

FM音源は要らないかな。
VG-Engineは、PC-Engine並のソフトウェア音源搭載が目標なので。
個人的には、ゲーム音楽用の音源として、FM音源はゴージャス過ぎる気がするというのもあります。
性能を落としてまで、FM音源を搭載させる価値を見出せません。

調律・・・

独自PSG音源の調律を行うために、オクターブと音色を選択できるように改造。

現状の音程を一通りの音色で一通り鳴らしてみましたが、かなりの調整が必要そうです。
これは、特定の波形データを特定の音程で出すシミュレータを作り、それを用いる形で作業が要りそうです・・・なかなか、そういった目的に適うソフトは無い・・・自分で作るしかなさそうです。

エンベロープとMML


(1)エンベロープ

エンベロープについては当初、アルゴリズムパターンを選択する方式にしようとしていましたが。

  • キーONしてから出力100%になるまでの時間(100ms単位)
  • キーOFFしてから出力100%になるまでの時間(100ms単位)
を任意値で指定できる仕様が一番良さそう。

(2)MML

楽曲データはMML→(独自コンバータ)→バイナリ形式というのが当初想定。
しかし、MIDIシーケンサ(SSWとか)でお手軽に作曲したいので、
MIDI→(独自コンバータ1)→MML→(独自コンバータ2)→バイナリ形式
の方向で。

MIDIからダイレクトにバイナリ形式にしてしまうと、エンベロープや音色等の細かい選択ができなくなってしまうので、ワンクッション(MML)を設けるのが適当。MIDIの特定パラメタ(イベント)を利用してダイレクト変換する方式もアリといえばアリですが、MIDIの解析が面倒なので、MIDIからは純粋にノート(音程+音の長さ+音の強さ)の情報のみ拾う感じにするつもり。

本当はピスコラ(ピストンコラージュ)からノート情報を拾いたいんですが....
(ピスコラのバイナリフォーマットは非公開なので、独自に解析するのが面倒)


純旋律で調整(成功)

純旋律で調整してみたところ、無事成功。

http://www.k2.dion.ne.jp/~ysuzuki/seikou.mp3

最後に「プツッ」と切れてしまうのは、エンベロープのアルゴリズムを実装すれば解消するので問題ではありません。今の所、キーオフすればブッツリ切っているから、それが問題なだけです。(つまり、大した問題ではありません)


厄介なのは、Dの音とかがノイズっぽい感じのところとか。
音程はあっています。
なので、これは周波数ではなく波の形状(波形)の問題。

今のところ、C言語で計算式で求めた波形データを元に、C言語の配列宣言の形式で出力するCGIプログラムを使ってメモリ波形情報を(85音階分)プリセットし、それを使って鳴らしています。
なので、波形データは編集自由。

音程の調律は無事完了しましたが、音色の質を調整する調律も必要です。
この部分(アナログデータ)は、流石に機械計算に任せきりにはできません。
この作業で、独自PSG音源の品質が決まるから、ここは手を抜けません。

この部分(音色の質)をシッカリ作りこめば、音色数の少なさは、大した問題ではない筈。
音色数=三角波、ノコギリ波、短形波の3種類+ノイズ
量の少なさは質でカバーする。

純平均律

どうも、純粋な平均律は、一般的な聴きなれた音階ではないようでした。

http://www.k2.dion.ne.jp/~ysuzuki/shippai2.mp3

上記は、以下の周波数で三角波を鳴らしたもの。


C 275.0000
C# 293.3333
D 311.6667
D# 330.0000
E 348.3333
F 366.6667
F# 385.0000
G 403.3333
G# 421.6667
A 440.0000
A# 476.6667
B 513.3333
C 550.0000


計算で鳴らしているのではなく、予め計算されたプリセット(1周期分の波形を準備したもの)を用いて鳴らしているので、微妙な誤差が生じるのは想定の範囲内ですが、ここまで違うとなると純粋な平均値で求めた音階というのは、一般的な平均律とは違うということ・・・かな?

そろそろ思考が停止してきたので、明日考えるか。

2012年3月3日土曜日

これは酷い

とりあえず、三角波のテスト波形ができたので、VG-Engineに載せて、ついでに以下のような鍵盤プログラムを作成し、ドレミファソラシドを演奏してみました。

結果は、
これは酷い()笑

あまりにも酷すぎるので、記念に録音しておきました。
http://www.k2.dion.ne.jp/~ysuzuki/shippai.mp3

これ、ドレミファソラシドって鳴らしています。(念のため)
一応、音程は変わっているので、基本的な理論は正しくできているようです。
なので、実験は失敗ですが概ね成功。

さて、鬼調整でもするか。

音程周波数のアルゴリズム化

音声プログラミング一般の理論は、前記事の書籍で大丈夫。
ただ、音程周波数のアルゴリズム化はその本では話題にしていないから自分で作る必要がありそう。

まず、音程というのは、波の周期(0→正方向の波→負方向の波→0)を単位時間(1秒)内に何回繰り返すかで決まります。そして、その単位のことを周波数(波の周期の回数)といい、ヘルツ(Hz)という単位で表記します。(音量は波の大きさで決まる)

で、ラ(A)の周波数は、

  • オクターブ5=880Hz
  • オクターブ4=440Hz
  • オクターブ3=220Hz
という具合に決まっています。

オクターブnのAの周波数がmHzであれば、オクターブn+1のAの周波数は2mHz

Aの音は全ての楽器の基準周波数になっているので、人間が一番聞き分け易い音です。
絶対音感が無い人でも、「Aの音だけは分かる」という人は結構居るものです。
ベースなど弦楽器のチューニングはAでやるし、オーケストラや室内楽なんかでも、演奏する前にA音の調整(チューニング)をしてます。ついでに、音楽大学の音の聞き分けテスト(そんなんあるんかい?)なんかでも、聞き分ける音の間にA音を鳴らしているようなことが漫画(のだめ)に描いてあったような気がします。

他の11個の音程(A#, B, C, C#, D, D#, E, F, F#, G, G#)の求め方は諸説色々あります。
一番シンプルなのは平均律。
半音=(55×オクターブ)÷12Hzの増加
という単純計算。
※55は12で割り切れない(4.583333333...になる)から、諸説乱立する訳です

で、コンピュータでアルゴリズム化する場合、55も1秒(1000ミリ秒)で割り切れないから更に厄介。
18.181818....回、波形の周期を繰り返せば、オクターブ1のラになる訳です・・・
18×55=990msなので、ラ音では1%の誤差が生じます。
平均律だと、ラ音以外にも強かに誤差が生じる筈。
この辺りの誤差は、実際に鳴らしてみて微調整するしか無いですねぇ....
まさか、ディジタル楽器を作るのに調律が必要になるとは。

とりあえず、
  • オクターブ1のA~G#の波形パターンをオンメモリでプリセットする
  • 配列サイズ(周期)は小数点以下は切り捨てて考える
という感じで、作ってみます。
性能優先なので、違和感があった場合、DDT又は配列サイズの調整で調律する感じ。
(浮動小数点数は重いので使わない)

とりあえず、三角波の波形パターンを作ってみてテストしてみようと思います。
あ・・・あと、サイン波は音が気に入らなかった(使いどころが少なそうだった)し、面倒くさいので、落とす方向で。(三角波、ノコギリ波、短形波+ノイズで実装する方向)

良書(音関連)

VG-Engineの独自PSG音源を実装するにあたり、先ずは、波形と周波数の関係が分かり易く解説されている理論書を探しに本屋に行ったところ、良書過ぎる良書を発見。


C言語ではじめる音のプログラミング
サウンドエフェクトの信号処理
青木直史・著(オーム社/出版局)
http://www.amazon.co.jp/C%E8%A8%80%E8%AA%9E%E3%81%A7%E3%81%AF%E3%81%98%E3%82%81%E3%82%8B%E9%9F%B3%E3%81%AE%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E2%80%95%E3%82%B5%E3%82%A6%E3%83%B3%E3%83%89%E3%82%A8%E3%83%95%E3%82%A7%E3%82%AF%E3%83%88%E3%81%AE%E4%BF%A1%E5%8F%B7%E5%87%A6%E7%90%86-%E9%9D%92%E6%9C%A8-%E7%9B%B4%E5%8F%B2/dp/4274206505


ウチの近所の本屋では、プログラミング関連の本の所ではなく、ディジタル信号処理関連の本の所に有りました(理論ベースで調べようとして正解)。まだ、全体をパッと斜め読み(速読)しただけですが、独自PSG音源を実装する上で必要な理論は一通り揃っていて、尚且つ、C言語で解説つき。

一般的な理論書から音(波形や周波数)の理論をC言語に落とし込む手間が省けます。
ついでに、(入門書的な位置づけのようなので)書いてある内容も簡素。

独自音源(ソフトシンセ)を実装したい人に、オススメの一冊です。
まあ、普通の人はwav、ogg、mp3でお手軽に鳴らせれば良いんでしょうけど。
普通じゃない人は、理論書ベースで何ら苦労しない簡単な内容だから、そもそも、こういう本が存在することを期待していなかったので、ラッキーでした。

VG-Engine 2.00の強化

とりあえず、INVADER BLOCK2に開発については、一通りの作業が完了したっぽいです。
AndroidMarketの場合、かなり本腰を入れて販促活動(プロモーション)をしないと全然売れないと思うので、公開開始してからがスタートラインの気がしないでもないですが。
ただ、Android/Windowsの独自ソース共通化エンジン(VG-Engine)を強化する作業を優先。

■VG-Engine version 2.00に向けた強化点

  • 効果音の合成:INVADER BLOCK2では不要だったけど、他ゲームでは必要。
  • 音源搭載:独自PSG音源を搭載する。

音関連だけです。

グラフィック方面も強化の為所は有りますが・・・回転、拡大縮小、半透明など。
ただ、それらは無ければ無くても何とかなる。

「音源搭載」も、BGMを全てPCMで鳴らせば何とかなりますが、それだと容量がデカくなり過ぎる。
如何に、スマホのダウンロード性能が早くて、大容量のストレージを積んでいたとしても、その部分に頼るのは、プログラマの信義に反します。

という訳で、独自PSG音源のスペックとしては、

  1. モノラル
  2. 同時発音数:6チャネル
  3. 波形:サイン波、三角波、ノコギリ波、矩形波の4種類(固定)+ノイズ
  4. エンベロープ:固定アルゴリズムパターンから選択
  5. フィルター、モジュレーション、エフェクト等:なし
各チャネルで、任意の波形・エンベロープ・音量・音程で音を鳴らすことができる・・・という仕様。
まぁ、ほぼPC-Engineの内臓音源と同等スペックだと思います。
不要な奢侈機能は実装しない方向で。
独自シンセにすると、性能が悪くなるので。
「独自シンセなのに高性能」を目指したい。
ローパスフィルタ、ハイパスフィルタぐらいなら有っても良いかもしれませんが。(軽いので)

私は、音関連の知識は素人同然なので、まずは、波形と周波数の関係とかの勉強が必要。
面倒くさそうなもの&有益度が低いものについては随時省いて、完成を早めたいところです。
とりあえず、PCMを鳴らす機能はINVADER BLOCK2に載せているVG-Engine version 1.00で完成しているから、後は音の仕組み(理論)さえ理解すれば良いので、完成は結構早いと思います。(音を聞くことができれば、理論の理解は容易な筈)

2012年3月2日金曜日

INVADER BLOCK 2 Windows版(無償公開) <更新>

Android Marketで販売中の「INVADER BLOCK 2」(99円)のWindows版を無償公開します。
INVADER BLOCK 2は、タッチでバーを操作し、ボールでインヴェーダーを倒すアクションゲームです。
↓Android版の詳細は、コチラ
http://hp.vector.co.jp/authors/VA040196/android/

Windows版(無償)は、現在Vectorにアップロード申請中です。
来週中にはアップロードされると思います。

ただ、このブログを見て下さった方向けに、以下URLで先行公開します。
公開終了しました

上記ZIPを解凍してIBLOCK2.EXEを実行すればゲームが開始します。
なお、このゲームは、DirectX9を使用して作られているので、実行にはDirectX End-User Runtimeが必要です。(DirectX End-User Runtimeについては、同梱しているREADME.TXTに詳しく書いてあります)

追記(2012年3月5日)
Vectorで公開開始されたので、先行配信版(上記の網掛け部分)を消しました。
以下のURLからダウンロードできます。
http://www.vector.co.jp/soft/winnt/game/se496097.html

2012年3月1日木曜日

自己購入はNG

どうも、「自分で作った有料アプリを自分で購入すること」は、NGらしいです。
Google Checkoutのポリシーとかで。
なので、Googleアカウントに紐付けているクレジットカードではエラーになるようです。
(エラーになりました)


確かに、自転車操業的に自分で何本も買うこと(工作)はダメだと思いますが、1本だけならテスト用に許して良いような気もしますが・・・まぁ、ダメなものは仕方が無い。


という訳で、会社に知り合いに頼んで一本買って貰い、検証。
特に問題無いようでした。

なお、公開してから約22時間経過の現時点で、総ダウンロード数はその一本のみ。
やはり、Android Marketの仕組み上、ある程度宣伝活動をしないとダメか。
とりあえず、当初予定通り、先ずはWindows版(フリー)を配布してみようと思います。

ただ、Windows版(フリー)は、Vectorに載せる方向で動いていますが、こういうパターンが規約に抵触しないかはノーチェックだった。→追記:問題なし

2.3.7~

Windows上のAndroidMarketでINVADER BLOCK2を検索したところ、普通に発見。
https://market.android.com/details?id=com.suzukiplan.IBLOCK&feature=search_result#?t=W251bGwsMSwxLDEsImNvbS5zdXp1a2lwbGFuLklCTE9DSyJd

動作要件が「2.3.7~」になっていた。
恐らく、アップロード時点で最新の2.3.xになっているのだろうか?
API的には「2.3.3~」のもの(API Level 10)なんですが・・・

そして、私のデバッグ機は「2.3.4」でした。
これが原因。
端末アップデートしたら、無事検索できました。


しかし、最低バージョンを2.2以降にしなかった(できなかった)弊害がこんなところで出るとは・・・
(OpenSL|ESを使う為には、2.3.3以降にせざるを得なかったのが痛い)

[3/1訂正]
どうも、アップデートは関係無かった模様。
2.3.4の未アップデート端末でも普通に検索できました。

どうやって探すんだ?

公開しました・・・が、検索しても見つからない。
DB反映はバッチ処理かな。
検索以外に検索する手段が無いのが、Androidマーケットの痛いところ。

で、検索していて気付いたのですが、「Invader Block」という別の方が作られたゲームが存在します。
私が登録したソフトは、「INVADER BLOCK 2」。
「Invader Block」と「INVADER BLOCK 2」とは、全くの無関係です。
無料ゲームだったので、DLして内容を確認しましたが、幸いゲーム本質の内容は、全然別でした。
しかし、私の方が「2」がついているので、続編と勘違いされるかも....

一応、説明文に、
「2009年に公開したWindows用ゲーム INVADER BLOCKの続編です」
と、補足を追記。
英語版のInvader Blockが有るのか不明なので、英語の説明は変更せず。

あとは、Invader Blockの作者さんから怒られないことを願うばかり。
しかし、Androidで同名ソフトが無いかチェックするのをウッカリ忘れていた・・・
(勿論、初代のINVADER BLOCKを公開した時はチェックしましたが)