最適な音源スペック

SHOT04（NOKOGI-Rider）の最終ステージの道中曲を作成中。
作曲ではなく、作成中。
曲自体は去年、ピスコラで作曲済みで、ピスコラ⇒VGS（自作波形メモリ音源）への変換するため、MMLを書き起こす作業中です。ピスコラだとテキストの楽譜データに変換できないのが痛いですが、大分慣れました。

最終ステージの曲は最大４声の対位法＋ベースで作ったのですが、VGS（6チャネル）で全ての声部が収まりきらないから、目立たない声部をストレッタでぶった切って別の声部に繋げ直したりする必要があり、中々面倒。

ちなみに、
・４声の対位法⇒４チャネル
・ベース⇒１チャネル
・ドラムス⇒１チャネル
という割り当てにすれば、全部収まりますが、主旋律は際立たせる為に２チャンネル使うので、どうしても１声削る必要があります。

VGSを改造して声部を増やす（7チャネル以上にする）のは簡単なんですが、それは絶対にやらない。
漠然とした拘りのようなものがあります。
私がコンピュータで作曲を始めた頃、最初に使っていた音源がヤマハのYM-2203ですが、それの仕様が６チャネル（FM音源3チャネル＋SSG音源3チャネル）でした。その後、YM-2608やMIDI音源各種（SC55ST, JV1010, SC8820, MU80, MU500あたり）を触ってきましたが、何だかんだで、聴くのも作るのもYM-2203の音楽が一番楽しい。恐らく、私の好きなゲームに一番合う音楽が、６チャネルぐらいのスペックの音源の音楽なんだろう・・・と思います。


だから、音源スペックを拡張するのはダメ。
音楽を音源スペックに合わせるのが正解。

3面

SHOT04（NOKOGI Rider）の3面の作成に入る前に、想定以上に蛇行レーザーの作成に時間を取られましたが、無事、作成に入りつつあります。

レーザーは、若干角度が粗い部分もあります。。。
とりあえず、許される範囲内に落ち着くことが出来たので良しとしておきます。
静止画で見ると粗さが目立ちますが・・・
あと、低難易度のモードだと速度が遅めな分、プレイ中にも若干粗さが目立つかも。

今の所、３面は大多数の背景を海にする予定。（陸もある）
１面＝陸地メイン（海もある）
２面＝ダンジョン
３面＝海メイン（陸もある）
４面＝基地

５面＝中枢
という感じにするつもり。

ただ、単純にその状態だと３面が１面とイメージが被ってしまいます。
ステージ毎に特徴を作る為、敵パターンは基本的に刷新するようにして作ろうとしていたのですが、それでも若干目新しさに欠けるように見えたから、レーザーを頑張っておいた訳です。

Laser

敵のレーザーを作成中。
真っ直ぐ飛ばすレーザーなら簡単なんですが、ホーミングやカーブは若干面倒。

どちらにしても、回転機能が無いハードで実装する場合、先ずは回転パターンを作画します。
↓こんな感じで。
で、真っ直ぐ飛ばすだけなら同じラジアン値で連射すればOK。
普通の弾を飛ばすアルゴリズムでそのまま実現できます。
ちなみに、SHOT04（NOKOGI Rider）の敵弾は、１発毎に下図の構造体で情報を管理しています。
ただ、このデータ構造だと、
(1) レーザーを目標物（自機等）に向かってホーミングさせる
(2) レーザーをカーブさせる
といったことが実現できません※。
※正確には、不可能では無いけど複雑になり過ぎて処理効率が悪い

上記(1)や(2)を実現するには、トレースというアルゴリズムを実装する必要があります。
トレースというのは、一番先頭のオブジェクト（リーダー）の動作情報（ログ）を記録しておき、サブオブジェクト（メンバ）は一定間隔過去のリーダーのログと同じ動作をする・・・というアルゴリズムです。


分かり難いですね・・・分かり易く言うと、
・ドラクエのパーティーの動き
・グラディウスのオプションの動き
・インストーラーがプログラムのインストールに失敗した時に、インストール前の状態に戻す動き
・データーベースでコミット済みの状態を変更前の状態に戻す動き（ロールバック）
などなど。
これらは皆、同じトレースです。
インストーラやデータベースのロールバックはバックトレース（ログを逆順に追跡）ですが、本質は同じ事。


で、トレースを実現するのには、ログ（ジャーナルともいう）が必要。
現状の敵ショットのメンバにログを持たせても良いですが、そうなるとメモリ効率が悪いし、メモリ効率を良くすると処理効率が悪い・・・つまり、別テーブルで管理するのがベストです。
とりあえず、下図のような感じのテーブルを追加。
まだ、肝心のプログラムを作っていないので、多分上記は何かデータが不足しているかも。
あと、ログはリングバッファで管理（256フレーム分）。
それで足りるかは不明。
事前に設計できなくも無いけど、作ってから調整。


ちなみに、リングバッファの場合、インデクスの加算処理で無駄な分岐によるパイプラインハザードを抑える為、要素数は2のn乗にする必要があります。（そうすることで、AND演算だけで限界時のループができるので）

---

【追記】
プログラムを作成してみました。
表示したみたところ、下図のような感じ。

ちなみに、テーブルの内容は結構変えました。
移動速度のログは残さない（加速しない）仕様にして、後は座標を最大の長さ分保持したり云々。
↓こんな感じで。（当初想定よりも大分シンプル）

/* 敵レーザー */ struct ELaser { int flag; /* フラグ兼フレームカウンタ */ int ix; /* 初期X座標 */ int iy; /* 初期Y座標 */ short fx[32]; /* X座標(*8) */ short fy[32]; /* Y座標(*8) */ int len; /* 現在の長さ */ int maxL; /* 最大の長さ */ int R; /* 先端のラジアン値(0～627) */ unsigned char S; /* 速度(1～15) */ unsigned char itR; /* ラジアン値の変更間隔(フレーム数) */ unsigned char addR; /* ラジアン値の角度増減量 */ unsigned char typeR; /* ラジアン値の変更方法(0:変更しない, 1:右回転, 2:左回転, 3:ホーミング) */ short logR[512]; /* 角度ログ(512フレーム分) */ };

レーザーの長さはMAX=32にしておきました。
32×16=512ピクセルが最大長。これだけあれば十分。
あと、10度単位で回転パターン（36パターン）を準備したのですが、若干繋ぎ目が分かり易い・・・
ただ、これは気にならないレベルなので、まぁ良いかな。
8度単位（45パターン）にしてみようか微妙なところ。


ログのサイズは256だと足りないので、512に拡張。
速度＆長さがMAXの場合に必要なログ数が32×16=512なので。
速度＆長さがMAXなんて、鬼畜過ぎて使うことは無いと思いますが。


ちなみに、末尾～尻尾まで全てのレーザーが画面外アウトしたら消滅する仕様。
角度がキツ過ぎると、画面に戻ってくる場合があり、それは鬼畜過ぎるので、後で仕様変更するかも。

PowerUp

STGにパワーアップって必要なんですかねぇ・・・と、常々思っています。
で、実際にSHOT04は、パワーアップアイテム無しで作っている訳です。
しかし、STGにはパワーアップが有って当たり前という固定観念みたいなものがあります。

敢えて固定観念を捨てて、パワーアップに対して何を求めるかと考えて思いつくものは、
(1) だんだん強くなる成長過程を愉しむ
(2) 攻略を有利に進める
(3) 稼ぎ要素のひとつ（最高レベルの状態でPWアイテムを取得すると得点が入る等）
の３つぐらい。

上記は全て、無ければ無いで問題無い気がしています。
(1) ⇒ プレイヤーの腕前が上達していく成長過程を愉しめば良い
(2) ⇒ パワーアップが無い前提で攻略を有利にするパターンを探る楽しみがある
(3) ⇒ 他の稼ぎ要素があれば問題無い

寧ろ、パワーアップが有ることで生じるリスクも有ります。
・パワーアップアイテムを取得した時、攻撃力や連射速度を上げるケース
　⇒ ミスによりパワーダウンした時の復活が厳しい
　　　（こういうゲームの場合、１ミスでゲームオーバーで良いのに・・・と思ってしまう）
・攻撃力は（殆ど）変えずに、拡散度を上げたり、当たり判定だけ大きくするケース
　⇒ 狙って部品や敵機を破壊するのが難しくなる
　　　（個人的には、狙って部品等を破壊するのが楽しいと思っているので、これは結構致命的）

ノーパワーアップの方がスコアを稼げる仕組みにして、上級者（スコアラー）はノーパワーアップ、初級者はどんどんパワーアップして遊べるようにする・・・という案もあったのですが、「パワーアップアイテムをわざと落とす」というのは微妙だったので却下。
「わざとミスをする」とか、「わざとアイテムを逃す」というのはダメだと思います。
ゲームの本質（＝競技性）と逆行してるから気がするので。
ミスはしたくないし、アイテムはなるべく取りたい。

2面完成

まだ、成分未調整の段階ですが、SHOT04の２面完成。
Ninjaの難易度が割りと酷い。
私がプラクティスモードで遊んでみても、結構な頻度でゲームオーバーになる。

でも、調整は後回しにして、まずは一通り完成させたいので、とりあえず３面の作成に移ります。


調整目標は、
・Beginner -> ノーミス・ノーレーザーでクリアできる難易度
・Soldier -> 安全にプレイすればノーミスが狙える難易度
・Ninja -> ギリギリ、オールクリアできる難易度
※全て私の腕前が基準。

まぁ、今回は携帯端末で作っているということもあり、色々な人にテストをお願いし易いので、低難度モードに関しては調整し易い筈。

ヘッドホン・イヤホン

新しいヘッドホンを購入。
DENONのAH-D1000というもの。
これまで、SONYのMDR-CD900STというヘッドホンを使っていたのですが、ちょっと暑苦しかったので。

ちなみに、イヤホンはKENWOODのKH-C711というのを使用してます。
そして、各ヘッドホン／イヤホンの仕様を比較して気付いたのですが、KH-C711が一番電力を食うっぽい？

	インピーダンス	音圧感度
MDR-CD900ST	63Ω	106dB/mW
AH-D1000	32Ω	103dB/mW
KH-C711	42Ω	98dB/mW

インピーダンスというのは要するに抵抗です。
・・・物理は苦手なので、詳しくは分からないですが、一般的なヘッドホン（※ダイナミック型）は、電気の力で磁石（ボイスコイル）を動かし、その振動で音を鳴らします。そして、ボイスコイルの抵抗の大きさをインピーダンスと言うようです。

インピーダンスが高いほど、音を鳴らす（振動を発生させる）のに沢山の電気を必要とします。
その代わり、誤動作が少ないので、ノイズが少なかったり、音が鮮明になります。
つまり、高ければ高いほど、正確な音が鳴る可能性が高いと言えると思います。
なお、音の正確さは、物理ケーブルへの外的な刺激によっても変わるので、インピーダンスだけでは測れないところもありますが。あと、機器によって許容インピーダンスの範囲が決まっているので、極端なモノは使うと危険です（そういうものは、普通の家電量販店等には売っていないと思いますが、念のため）。

一方、音圧感度（NdB/mW）というのは、Nデシベルの音を出すのに必要な電力（ミリワット：mW）です。
つまり、100dBの音を出そうと思えば、
・MDR-CD900ST = 0.94mW
・AH-D1000 = 0.97mW
・KH-C711 = 1.02mW
の電力を要するという意味。
蛇足ですが、私の家の先月の消費電力量は87kW。
MDR-CD900STで100dBの音を約925532時間（だいたい105年ぐらい）鳴らし続けた時に生じる電力量という事かな？

音圧感度だけ見れば、消費電力の多さは、MDR < AH < KH という風になります。
ただし、それに対して、別途インピーダンスによる抵抗が介入します。
インピーダンスが半分であれば、音圧は3dB大きくなるとの事。

なので、単純なスペック比で見ると、以下のような結果になります。
- 音の正確さ： AH < KH < MDR。
- 音の大きさ： KH < AH < MDR。
- 消費電力量： MDR≒AH < KH 。

要するに、音圧感度＆インピーダンスの両方を考慮しても、KH-C711の消費電力量が高い。
一般的にヘッドホンよりも、イヤホンの方が電力を食うものなんですかね。
直感的なイメージでは逆ですが。
・ヘッドホン＝パワーのある機器に繋げる
・イヤホン＝電池駆動のチープな機器に繋げる
なので。

それとも、KH-C711のインピーダンスが特別に高いのだろうか？
面倒なので調べませんが。
そもそも、音の良し悪しは、値（スペック）では判断できないし。
物理的な形状や、趣向（好み）にもよるので、一概には言えません。

---

KH-C711はカナル型イヤホンだから、敢えて高インピー＋低音圧にしていると考えれば合理的かな。

動く背景

体験版のSHOT04では、背景アニメーションを一切無しでやっていましたが、３面を海ステージにしたかった＆海背景が動いていないと微妙なので背景をアニメーションする機能を実装。
一応、１面の海背景部分でテストしてみました。

画像（静止画）では分かり難い・・・というより分かりませんが、ちゃんとアニメーションしてます。

背景を動かす処理自体は簡単なんですが、若干重い。
最大で画面（240x320）全体分のBGチップ300枚（15×20）をフレーム毎に描画することになるので。
1フレーム（約1/60秒）あたり、76,800ピクセル。

ちなみに、画面中にアニメーションチップがひとつも無い場合、1フレームあたり240～3,840ピクセル。
16フレーム毎の平均が1,920ピクセル。
つまり、画面全体が動く背景の場合、40倍の量のピクセルを描画する必要がある訳です。


まぁ、最近のCPUなら微々たるものですが。
ついでに、VGEの場合、純粋なメモリ処理のみでピクセル描画をする（ピクセル情報はメモリストアでそれを１フレーム毎に１回だけビデオメモリに転送する）ので、尚更全く気にならないレベル。
SHOT04は、Android 2.3が載っている全ての端末で処理落ちすることなく動作できるアプリにするつもりで作っているので、性能にはかなり気を遣わざるを得ません。