調律・・・

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

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

エンベロープとMML

(1)エンベロープ

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

• キーONしてから出力100%になるまでの時間（100ms単位）
• キーOFFしてから出力100%になるまでの時間（100ms単位）

を任意値で指定できる仕様が一番良さそう。

(2)MML

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

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

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

これは酷い

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

結果は、
これは酷い（）笑

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

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

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

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

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

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

で、ラ（Ａ）の周波数は、

• オクターブ５＝８８０Ｈｚ
• オクターブ４＝４４０Ｈｚ
• オクターブ３＝２２０Ｈｚ

という具合に決まっています。

オクターブｎのＡの周波数がｍＨｚであれば、オクターブｎ＋１のＡの周波数は２ｍＨｚ。

Aの音は全ての楽器の基準周波数になっているので、人間が一番聞き分け易い音です。

絶対音感が無い人でも、「Ａの音だけは分かる」という人は結構居るものです。

ベースなど弦楽器のチューニングはＡでやるし、オーケストラや室内楽なんかでも、演奏する前にＡ音の調整（チューニング）をしてます。ついでに、音楽大学の音の聞き分けテスト（そんなんあるんかい？）なんかでも、聞き分ける音の間にＡ音を鳴らしているようなことが漫画（のだめ）に描いてあったような気がします。

他の11個の音程（A#, B, C, C#, D, D#, E, F, F#, G, G#）の求め方は諸説色々あります。

一番シンプルなのは平均律。
半音＝（55×オクターブ）÷12Ｈｚの増加
という単純計算。
※55は12で割り切れない（4.583333333...になる）から、諸説乱立する訳です

で、コンピュータでアルゴリズム化する場合、55も1秒（1000ミリ秒）で割り切れないから更に厄介。
18.181818....回、波形の周期を繰り返せば、オクターブ1のラになる訳です・・・
18×55=990msなので、ラ音では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. エンベロープ：固定アルゴリズムパターンから選択
5. フィルター、モジュレーション、エフェクト等：なし

各チャネルで、任意の波形・エンベロープ・音量・音程で音を鳴らすことができる・・・という仕様。

まぁ、ほぼPC-Engineの内臓音源と同等スペックだと思います。

不要な奢侈機能は実装しない方向で。

独自シンセにすると、性能が悪くなるので。

「独自シンセなのに高性能」を目指したい。

ローパスフィルタ、ハイパスフィルタぐらいなら有っても良いかもしれませんが。（軽いので）

私は、音関連の知識は素人同然なので、まずは、波形と周波数の関係とかの勉強が必要。

面倒くさそうなもの＆有益度が低いものについては随時省いて、完成を早めたいところです。

とりあえず、PCMを鳴らす機能はINVADER BLOCK2に載せているVG-Engine version 1.00で完成しているから、後は音の仕組み（理論）さえ理解すれば良いので、完成は結構早いと思います。（音を聞くことができれば、理論の理解は容易な筈）

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

自己購入はNG

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


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


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

なお、公開してから約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を公開した時はチェックしましたが）

公開直前

InvaderBlock2の公開が間近ですが、色々と変更します。

（１）価格設定 → 最低価格にする
実は、有料だと全然売れないと思っているのですが、それでも、「値段の所為で売れなかった」という事態を避けるため、最低価格に修正。（そもそも、元々は無料で配ろうとしていたぐらいだし）
とはいっても、100円が99円になっただけですが。

（２）コピー防止機能 → 入れない方向とする
外的に埋め込むモノとはいえ、これが原因で何か起きた時に何も対処出来ない（しかも、間もなくサービス終了するという勧告もある）というリスクを避けるため。
そもそも、全然売れないと思うので、あまり目くじらを立てる必要も無かろう・・・と、推測してます。
そして、仮に１本でも売れた場合、その購入者に確実なサポートができなくなる方がマズイ。

ついでに、売れるとしても日本か米国のみだと想定している（和文と英文しか準備していない）ので、あまり心配する必要は無いでしょうし。ちなみに、BSAの調査（2010年版）では、日本、米国、ルクセンブルクの不正コピー率の低さは世界１位です。
http://www.bsa.or.jp/press/release/2011/0512.html

という訳で、対策を講じるとしても、ライセンスサービスの内容を把握して第二弾以降で。
完全に購入者の善意に委ねます。
先日の記事で「違法コピーを望まない旨の意思表示云々」言ってましたが、ソフトウェアの開発者サイドで違法コピー＝不利益を望む人なんてそもそも居ないですし。

あとは、約３時間後に（24:00を回ったら）公開ボタンを押すだけ。
審査とかに数日掛かったりする・・・なんて、オチが無いことは事前に確認済み。
実は、今日気付いて確認したんですが。危ない危ない...

一応、公開できたら自腹で購入テストをする予定。

いいかも・・・

InvaderBlock2は、AndroidManifest.xmlでポートレイト・モード（android:screenOrientation="portrait"＝縦画面固定）にしていたのですが、アスペクト比調整のデバッグで横画面にしてテストしたりしていました。

・・・で、気付いたんですが、私がデバッグに使っているタブレット（７インチ）は、横置きでアスペクト比調整すれば、ピッタリ、スマートフォンサイズになります。

で、先ほど気にしていた１６スロットの問題が本当に押し難いかチェック。
普通に押し易かったです。

とりあえず、スロット数を減らす修正は入れなくて良さそうです。
ターゲットユーザがスマートフォンなら、７インチ横置きでテストするのがベストかもしれない。
（ただし、リリース時はポートレイト・モードに戻すけど）

本当は、ターゲットユーザがスマートフォンなら、スマートフォンでテストするのがベストですが。。。

スマートフォンは高い・・・ランニングコスト的な意味で。

アスペクト比修正など

本当に３月１日にリリースする気があるのか・・・？
というぐらいの問題が発覚。

InvaderBlock2は、QVGAの縦置き（240x320ピクセル）という画面仕様で、デバッグ用のAndroid機は、画面がデカイけど、比率はそんなもんだろう・・・という想定で画面一杯に拡大していたのですが、どうも、手持ちのデバッグ機は600x1024ピクセルというサイズ（QVGA＝横0.75：縦1.00と比率が違う）でした。

その問題は、アスペクト比調整する修正を入れて軽く直しました。
しかし、画面が小さくなると、セーブスロット（16個）を選ぶ作業が大変・・・
そして、スマートフォンだともっと画面が小さいから、もっと大変・・・という問題も発覚。
何を今更・・・と、思ってますが、セーブスロットを16個→8個に減らそうか検討中。
（会社が休みだった昨日の内に気付かなかったのが悔やまれる）

難易度調整

簡単過ぎるゲームは好きではありません。
昨今のゲームは簡単すぎるものが多い。
しかし、単に難しければ何でも良いという訳でもありません。
恐らく、適度な達成感の得られるゲームというのが、最善です。

という訳で、InvaderBlock2の難易度を調整。
ボールの動きを少し遅くしてみたり...etc
こういう部分は、一度リリースしてしまうと「リプレイデータの互換性」という柵ができてしまうので、変更可能な唯一のタイミングが今です。単なるバグなら、アップデートで更新できる仕組みがあるから、こういう部分の調整に力を入れるのが吉だということに、本日夕方頃、気付きました。

実は、Androidの場合、画面（SurfaceView）の更新間隔が16msに1回のようです。
つまり、秒間の描画回数は62～63の間。（62.5fps）
Windows（DirectGraphic）のフルスクリーンのゲームであれば、簡単に60fpsに調整できますが、実はこの60fpsというのはあまり良い数字ではありません。60fpsだと1秒（=1000ms）で割り切れないので。（16.6666666....msになってしまうから、例えナノ秒精度でウェイトしてもダメ）

つまり、60fpsにしようとすると、16ms→17ms→17ms（50ms/3回）の不均等な間隔で描画する必要があります。そうすることで、1000ms÷50ms＝20になり、20×3回=60fpsという具合になり、めでたく60fpsが実現できる訳です。（ハードウェア的に60fpsをサポートしているGPUの場合、もっと細かい単位（μ秒やナノ秒単位）でズレを設けているかも・・・ハードには疎いから分かりませんが）

例え１ミリ秒であっても、不定期にズレが生じると違和感を感じることができます。
（故に、ガーベージコレクションというのはかなり厄介なシロモノ）
しかし、3回に1回という形で規則的に動作すれば、脳（視覚）は「均等に動いている」という錯覚を起こします。つまり、60fpsというのは、錯覚の原理を利用しているのでフレームの視覚的均一性は、実は幻だった・・・という訳です。ただし、人間は時間の単位を基本的に60進法で管理するので、60の方が良いのかも（＝1ミリ秒を1/1000秒としたのが誤りなのかも）しれませんが。

余談が長くなりましたが、要するに
「Android版InvaderBlock2は62.5fpsで、それを60fpsに調整する気はない」
ということです。（Windows版も公開時は62.5fpsに調整予定）

しかし、当初Windowsでは60fpsでテストしていたので、ゲームスピードが4%速くなってしまいました。
その分（4%）を調整するためにボールの速度を調整・・・という訳です。
もちろん、これの所為で達成感を損なうレベルに難度が落ちる事だけは避けたい。
なので、慎重に調整します。

公式HP

公式HPでInvaderBlock2の情報を開示。
http://hp.vector.co.jp/authors/VA040196/android/

シンプルに纏めました。
（トップページもシンプルに修正）

動作環境・公開先・（予定）価格は、今後作るゲームで皆同じにするつもりなので、第二弾以降を出したらレイアウト変更が必要ですね。

一応、第三弾ぐらいまでは、作りたいゲームのアイディアがあります。
第二弾は、シューティング（SHOT04）の予定。
予定は未定ですが。
しかし、タッチパネルでシューティングというのは、操作性の面が悩ましいです。ただし、ちょっとしたアイディア（もちろん、ゲームパッドなどの外部ハードは不要）があるので試してみたい。

あと、外部ハードで思い出しましたが、以前の日記で「タッチペン推奨」と書いていたかもしれませんが、試しに、600円ぐらいの安価なタッチペンを買ってきて使ってみたら、結構微妙でした。
結構筆圧をかけないと、反応してくれない感じです。
もうちょっと高価なタッチペンじゃないとダメかな？
本質的な仕組み（先っちょ部分）に大差は無いようだったので、定かではないですが。
現時点のInvaderBlock2は、指で快適に操作可能なので、高価なタッチペンで試す予定はありません。

アップロードまでの流れ確認

３月１日にInvaderBlock2を公開すると決めたは良いんですが、これまでの流れから推察して、
「色々と手間取ってリリース遅延するんじゃないか？」
と、心配になったので、アップロードまでの手順をギリギリの所（公開する直前）まで進めてみました。
「保存」をやったのに、何故か保存されなかったようですが、手順は把握しました。
概ね問題ありません。

ひとつ問題になったのが価格設定。
とりあえず、米ドル基準で1$の価格設定をしようとしました。
なので、日本円なら79円ぐらいということで80円。
１本あたりの私の利益は、56円。（Google按分が30%のため）

マーケットアカウント取得費用(約2000円)+英作文費用（約500円）の原価を稼ぐのが目標。
なので、約45本売れればプロジェクト成功です。
一応、デバッグ用のデバイス購入費や参考書（２冊）の購入費の設備投資費用もありますが。

・・・しかし、どうも最低価格というのが有るらしく、日本円なら99円が一番低い設定らしい。
という訳で、米国＝1$、欧州＝1€、日本＝100円という価格設定にします。
この方がスッキリして良いと思います。
端数はあんまり好きじゃないから、ワンコインでお釣り無しが良いので。（皆、クレジット決済でしょうけど・・・）

という訳で、１本あたりの私の利益は、70円にハネ上がりました。
目標売り上げ本数は約29本・・・これなら、なんとかなるかな？
微妙です。
というより、1本でも売れるのかが疑問。

あと、どうでも良いですが、YouTubeの動画はフルアクセス設定に修正。

不正コピー防止処置

Androidマーケットで公開するアプリケーションの防止処置としては、

• コードの難読化
• コピー防止（将来廃止予定）
• LVLの実装（Googleライセンスサービスの利用）

の３種類があるようです。

コードの難読化は、Java特有の事情でしょう。
なので、InvaderBlock2（殆どCのみで実装）ではほぼ影響なしだと思います。
※ただし、ARMの逆アセンブルは、6502系統だけあって純RISCアーキテクチャ（Rシリーズ等）と比較して解析し易いと思いますが。

コピー防止は将来廃止予定とのこと。
とりあえず、root化した端末で簡単にコピーできない程度のもののようです。
外的にAPKに埋め込むものらしいので、恐らく、突破は簡単。
外的にAPKに埋め込むから導入も簡単。

LVLは、コード変更が必要。
サンプルと解説を斜め読みした限り、通信が発生しそうな気がしています。
結構複雑なので、読みきれてませんが。

・・・で、「何をやり、何をやらないか」ですが。

• コード難読化 → 殆どCで実装しているからやらない
• コピー防止 → やる
• LVLの実装 → やらない

かな。

InvaderBlock2は今のところ通信処理を一切入れていないです。
アフィリエイト広告はヤメにしたので。
折角、無通信＆処理も軽い電池にやさしいアプリなのに、LVLのためにそれを行うのは・・・

もちろん、不正コピーの横行は防止したいですが。
しかし、公式ドキュメントを未だ理解しきれていない。（結構複雑です・・・英語だからかもしれませんが）
その状態で実装を入れるのは、かなりリスクが高い。

最低限のコピー禁止の意思表示はコピー防止の導入で伝わる筈。
そもそも、悪意がある人への防止は、如何にLVLを導入しても難しいと思います。

という訳で、利用者の善意に委ねるのがベストと判断。

動画を投稿完了

InvaderBlock2の動画を投稿完了。
http://www.youtube.com/watch?v=ecYfLS14WZc&feature=youtu.be


URLダイレクトアクセスで見れる設定なので、多分上記リンクからなら見れる筈。
Androidマーケット公開時にフルアクセスにします。


しかし・・・画質が、粗い。
YouTubeエンコで30FPSになったので、フレーム間隔で表示しているものが、見えたり、見えなかったりしているし・・・まぁ、良いか。

ちなみに、１回撮影後に画面の細かい仕様変更をしたため、TAKE-2です。
あと、ゲームは実機ではなくWindows版です。（カメラが無いので、Android版は録画できない...）

宣材なんだから、もっとシッカリ編集したいところですが、動画編集系のツールは持っていないので、未編集のノーカット放送でお届けしています。（ゲームのプレイはリプレイ再生ですが）
そもそも、開発機のメインPCのCPUがAtomなので、動画編集など無謀。。。

InvaderBlock2のリリース予定日

３月１日リリース予定です。

残す作業は、

⑤最終デバッグ
⑧紹介文（英語）執筆
⑨紹介動画の録画

明日、会社が休みなので、⑨（動画）は今日～明日中にはできる筈。

⑤（最終デバッグ）は、バグらしいバグはもう無いので、Windows版の方でデバッグコードを仕込んで、通常ではありえないケースの検証をしたりします。これも今日、明日中には完了する筈。

一番の難関は⑧（英文）。

⑧（英文）は、会社の英語が得意な人（TOEICが900点台？の人）にお願いする予定。
私も一応、英検４級をもっているので、そこそこデキるんじゃないかと思っていますが、念のため。

今回の開発での唯一の他力本願部分。

煙草一箱で引き受けていただく請負契約を口約束で締結済み。

あとは、Android版の公開が完了次第、ホームページに紹介ページを作って、Windows版（無料）の配布を開始する準備とか。ちなみに、Windows版はVectorに掲載する予定なので、掲載は早くとも３月中旬頃だと思います。

Android特有のバグ

今回、Windows版を最初に開発し、Android版へ移植という開発プロセスで開発してきました。
総括してみると、Windows/Androidでのプラットフォーム誤差というのは、大して無いです。
なので、この開発プロセスが一番生産性が高いんじゃないかな？と、思っています。

唯一、悩んだWindows/Android間のプラットフォーム誤差は、
タッチを離した瞬間の座標情報
です。

Windows版の場合、デバイスの入力にマウスを用います。
そして、

• マウスのクライアントウィンドウ内での座標情報をタッチ位置
• マウスの左クリックの状態をタッチ有無

という感じで入力情報を取得していました。

で、ゲーム中のボタンなどについては、タッチを離した瞬間（１フレーム）を判定機会とします。
その時、タッチを離した瞬間の座標情報が当り判定する位置となります。
マウスの場合、タッチ状態（左クリック）を離しても、座標情報は生きています。
しかし、Android（タッチパネル）の場合、タッチ状態を離すと座標情報も死にます。

冷静に考えてみれば、当たり前のことなんですがね。
しかし、このバグ原因を究明するのに結構時間が掛かりました。（２時間ぐらい）

---

まぁ、上記の問題はプラットフォーム依存コード（=VG-Engine）で吸収できます。
なので、VG-Engineの設計ミス。

こういうマイクロな問題を単純な「アプリケーションのバグ」ではなく「設計ミス」と認識することが、共通プラットフォームエンジンを作る上では重要な考え方になります。両方とも同じバグですが、プラットフォーム共通化エンジンの代表格であるOS設計ベンダーというのは、得てしてそれを「アプリケーションのバグ」という・・・ある程度、仕方の無い事情もありますが。

その他の事（グラフィックやサウンド等の純粋なハード依存部分）は、仮想的なエンジンを自前で作れば、割と簡単にプラットフォーム共通化ができます。（それが大変な訳ですが）

今回設計したプラットフォーム依存コードのWindows/Android各々の規模を見てみると、

• Windows+DirectX → 1030行(C++)
• Android → 533行(C) + 229行(Java) = 762行

という感じ。

つまり、Windows+DirectXのプログラミング知識があれば、Androidの方が必要な知識（情報量）が少ない分、楽。
恐らく、iPhone化ならもっと簡単なんじゃないかな。想像ですが。
Objective-C（＝Apple専用言語）というのが厄介ですが、Cのソースコード互換性を100%保っていてくれれば、別に大きな問題ではないと思います。（iPhone化を見越して、プラットフォーム非依存コードはすべてC++ではなくCを使うようにしていたりする）