マップエディタやら

ゲームを作成する上で欠かせないツールがマップエディタです。
InvaderBlock2のようなゲームであれば不要ですが。

マップエディタ自体、色々なものがタダで配られています・・・が、独自開発推奨です。
そこそこ便利な機能が揃っているものも多いのですが、エディタ自体に手を入れないといけない事が結構多いので、ある程度凝ったゲームを作ろうとすると、既製品では開発効率が大分悪くなってしまいます。

私が使っているマップエディタも独自開発品です。
実の所、去年、SHOT03を完成させた後に作りました。
SHOT03は、適当なフリーのエディタを使っていたのですが、色々と大変だったので。

画面は↓こんな感じです。

実は、マップエディタのくせにDirectX9を使っています。
お陰で、ゲームと同じ画面効果（マップのアニメーションとか）をリアルタイムで確認できます。
あと、マップエディタとイベント（マップ上のNPCやら仕掛けなど）を配置する機能もあります。
（イベントは画面中の四角で囲まれた数字の部分）

今回作っているシューティングは、このエディタを使ってますが、お陰で色々と助かっています。
元々、アクションRPGを作る為に作ったエディタなので、STGを作るのに使う分には無駄機能が多いですが。
少なくとも、レイヤーとか自動海岸とか当たり判定とかは要らない。

逆に必要な機能がまだひとつも無いから、STG用としてはかなり完成したツールかもしれません。
このエディタ自体は非公開なので、第三者の意見が無いから、本当に完成しているかは不明ですが。
こういうエディタには完成が無いから、公開するのは中々厄介です。（主にメンテナンスが）
ノーメンテナンス宣言をして配る分には良いかもしれませんが、公開した以上、ノーメンテナンスだと逆宣伝効果が働きそうなので、公開することは無いと思います。

平日不調

本業がそろそろ忙しい時期を脱したと思ったら、まだまだ色々と忙しい。
随分前から、「今がピークだ」と自分に言い聞かせながら仕事をしていますが。
しかし、中々ピークが終わらない。
恐らく、去年の６月ぐらいからピークが続いているので、そろそろ一年か。。。

ゲーム作りの方は、ゲーム根幹部分のシステムを調整中。

「タッチ専用」＆「ソフトボタン無し」というスペックでシューティングを作ろうとすると、どうしてもボムを入れることができません。ただ、実は、個人的にシューティングにボムとパワーアップが本当に必要なのか、甚だ疑問です。パワーアップについては保留中ですが、少なくともボムは入れません。

ただ、回避処置が何も無いのもつまらないので、非タッチ状態を有効に活用して回避処置を設けています。
ちなみに、Android用のシューティングゲームはショットがオートなものばかりですが、私が開発中のものは、ショットはタッチ中のみオートで、非タッチ中はショットを打たない仕様になります。
常にフルオートでショットを出すのは、どうも間が抜けてる気がするので。


その非タッチ状態を活用した回避処置のことをAtomicLaserと呼んでいます。
そのAtomicLaserをどのようにスコア稼ぎ要素にするか・・・といった辺りを創意工夫中。

敵アルゴリズム

ようやく、敵を登場させるシステムの骨組みが完成。

あと、敵の絵やらアルゴリズムもどんどん追加していくだけ。

敵のアルゴリズムは、スクリプト化する派とプログラムでいく派が居ると思いますが、私は後者。
以下のように、アルゴリズム関数を関数配列で管理して、キックする感じでやっています。
STGの場合、このやり方で作る方がスクリプトのシステムを作るよりも効率が良い気がします。

敵アルゴリズム以外の部分が、まだ、色々とできてませんが。
敵のドット絵とか。
上のキャプチャはSHOT03のドット絵の流用物なので、若干・・・というより、かなり浮いている。
（このままでは流石に使えない）


システム的な面では、爆破やら、敵弾やらがノータッチ。


とりあえず、爆破パターンのドット絵はSHOT02の頃から使っているものを流用しようとしていますが、爆破ギミックは少し凝らせたいので、結構時間が掛かりそう。個人的に、爆破はシューティングの華だと思っているのですが、割とそういう議論をあまり聞かない・・・と、思っていたら、2chに専用スレッドがあり、色々な意見が見れて面白かったです。色々と参考にしながら試行錯誤してみようと思います。

敵弾も割と重要だし厄介。
ちなみに、弾幕STGにするかは微妙です。
個人的に高速な弾を高速な自機で避けるのが好きなので。
ただ、高速な弾主体にすると、必然的に自機狙いや自機外し（つまり、真っ直ぐに飛ぶ弾）が中心になってしまうから、それは避けたい。今回はもっと多彩な弾を飛ばせるようにするつもりです。
ですが、アクション・パズルゲームにはしたくない。
アクション・パズルゲームが嫌いな訳ではないですが。（寧ろ、好きな方）

STGにおける敵情報のデータ設計

シューティングゲーム（STG）の作り方を解説しているサイトは数あれど、敵のオブジェクト情報をどのように設計するかについて言及しているサイトは割と見かけないような気がするので、軽く解説しておきます。

そんなん、単純に構造体で管理だろJK

・・・かもしれませんが、この部分のデータ設計を予め如何に適切におこなっておくかで、ゲームの表現の幅が大分変わります。私はそのことを、SHOT01～SHOT03（３作品）の開発での失敗を経て実感しています。

まずは、実際に設計中のデータ（実物）を見た方がイメージが沸き易いかと思います。

なので、現在開発中のSHOT04で作成途中のデータ構造を例示します。

クラス構造としては、敵、オブジェクト、パーツの３種類。

E-Rで表記すると、

• 敵：オブジェクト＝１：ｎ（最大８）
• オブジェクト：パーツ＝１：ｎ（最大８）

という感じ。
つまり、１匹の敵は最大64パーツ（8^2）持てます。
数は今後、コロコロ変わっていくんでしょうけど。

実は、SHOT01の頃は単純な１個の構造体で敵を表現していました。
ただ、それだと当り判定が複数個所に分かれるような場合、処理が面倒になります。
そこで、SHOT02とSHOT03では、１つの敵を複数のオブジェクトで表現する感じにしました。
ただ、それでも処理が厄介な部分があったので、今回は、敵、オブジェクト、パーツの３層構造のスキーマを定義。（予定）

オブジェクトには、有するパーツ数＋パーツ情報を定義します。
例えば、グラディウスの多節足の敵の場合、根っこの部分、胴体の部分（複数）、頭の部分みたいなパーツをグループ化したものが、ひとつのオブジェクトになります。

それなら、オブジェクトとパーツだけ（２層構造）で十分だ・・・と普通は考えます。
（だから、SHOT02とSHOT03はその形態にしました）

ただ、例えば多節足を２本持っていて、足単位でパーツ破壊できるような敵（足×２＋本体）というものを作ろうとするとプログラムが複雑になってしまいます。だから、オブジェクトを更にグループ化した、クラス（Enemy）を追加・・・という訳です。これで、どんなものでも簡単な処理で表現できる筈。まだ、作ってないから確証は持てませんが。

ちなみに、クラスだとかスキーマだとか、オブジェクト指向の用語を使っていますが、プログラム言語はCのみです。私は、C++やJavaが大嫌いなんですが、オブジェクト指向の考え方自体は、重要だと思っています。（ついでに、iPod touch化するときにもに楽になる筈）

背景

背景がクロマティだと寂しいので、マップ機能を実装。

以前、GAME06という名称で作っていたアクションRPG（※開発断念）用に作ったマップエディタとマップシステムを、シューティング用にカスタマイズして作るだけだから、システム自体は一瞬で作れました。

問題は、リソース（チップセットの画像）。

私には絵心がほぼ無いので、ハムコロサマさんの素材あたりを使いたいところですが、フリーゲームで使うのならともかく、商売で作っているものに他人の著作物を使うのは（現時点の使用許諾は未確認なので、実際にダメかどうかは定かではないですが）トラブルの元なので、下手ですが、自分で描くことにしました。
地面の線路（のつもり）と、飛行機のサイズを影の大きさから計算して見てみると、明らかに寸法がおかしかったりしますが、気にしない方向で。

ちなみに、飛翔鮫みたいな感じの左右スクロールはしない方向です。
左右固定（＝東方と同じ方式）。
左右スクロールのプログラム自体、簡単に作れるのですが、マップを作るのが（広い分）面倒だし、ゲームバランスの調整も面倒になるので、左右は固定です。
要するに手を抜きます。

GW中には、ステージ1のみのトライアル版（無償）をマーケットに流したいから、開発効率優先で。

上下移動（実装）

上下移動を実装してみました。
かなり良い感じです。

少なくとも、Android市場に出回っている作品の中では、随一の操作性で、尚且つ全盛期（90年代）のシューティングゲームを求めるコアなシューターが満足できる水準のモノを仕上げることが出来ると思います。（たぶん）

問題は、コアなシューターがAndroidユーザーの中に居るかどうかですが。
たぶん、そんなに居ないんじゃないかと思っています。
満足のいく水準に達している作品が想像以上に少なかったので。
ただ、潜在的にはかなり居ると思っていますが。
というのも、Androidはデフォルトが縦画面（＝シューティング専用）なので。

とりあえず、この作品の１面が出来た段階のβ版（トライアル版）を無償で市場に流してみて、様子見をしてみるつもりです。そして、売れそうな感触だったら本気で作り、そうでなかったら、このゲーム（SHOT04）の開発はヤメにして、別路線を探るつもり。

ニーズが無くとも、完成させる可能性も大ですが。

上下移動

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

画面はこんな感じ。（まだ、自機以外の何も無い状態ですが）

とりあえず、左右の移動は「INVADER BLOCK 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のデメリットはほぼ感じなくなる筈。

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

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

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

自動消灯の抑止

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

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

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

Javaのコードであれば、

getWindow().addFlags(WindowManager.LayoutParams.FLAG_KEEP_SCREEN_ON);

とやるだけ。

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

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（公開中の最新版）よりも、若干見易い色に変更。
床の耐久力は、ボールの衝突を１回だけ耐えられる程度にしました。
当初、３回にしようとしましたが、ゲームバランスが悪かったので、１回だけ。

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

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

破線表示のON/OFF機能（2.04）

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

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

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

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

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

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

「近日」とは

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

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

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

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

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

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倍ぐらいは楽しくなったので。

予定軌道を表示する機能

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

この「予定軌道を表示する機能」というのは、分かり易くいうと、下図のように落下時（ボールのY方向ベクトルが正の時）に、壁の跳ね返りのみ考慮した形で軌道をドットで表示する・・・というもの。

上図では、分かり易くするために実線で示していますが、実際のゲーム画面では破線で示した形になっています。実際にプレイして貰った方が分かり易いので、この機能を入れたバージョン（2.02）のWindows版をアップしておきます。
http://www.k2.dion.ne.jp/~ysuzuki/IBLOCK2.ZIP

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

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

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

性能良好

作成した自作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に寄与するか、ケースバイケース。
例えば、エンベロープの計算に百分率が必須ですが、百分率を整数のみで計算する場合、

• 割られる数×１００ ÷ 割る数　＝　ｐ（１００％なら１００）
• ｎ×ｐ÷１００ ＝ ｎのｐ％の値

という感じで計算します。
※ここでは説明をし易くするために百分率といってますが、 実際は128分率とか64分率などで計算するのが一般的

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

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

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

分解率

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

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

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

中々美しく響きます

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

1秒の周波数 = 88200Hz

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

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

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

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

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