DirectGraphic関連

Windowモードでもヌルヌル動くようになった・・・
処理性能が悪かったのは、メインループの処理シーケンスが不味かった模様。

(1) PeekMessage
(2) ゲームのメイン処理呼び出し（VGE-VRAMの描画）
(3) BeginScene
(4) VGE-VRAMをサーフェースへ転送
(5) EndScene
(6) フリップ(Present)

という順序で呼び出していたものを、


(1) PeekMessage
(2) BeginScene
(3) ゲームのメイン処理呼び出し（VGE-VRAMの描画）
(4) VGE-VRAMをサーフェースへ転送
(5) EndScene
(6) フリップ(Present)


という順序にしたら直りました。

どうも、DirectX関連の処理を実行しなくても、重い処理はBeginScene→EndSceneでサンドウィッチしないとマズイようです。

FullScreen対応

Windows版のフルスクリーンモードを実装。
640x480のフルスクリーンにして、240x320のVGEビデオメモリを中央（+200,+80）へ配置しました。

割と沢山隙間が開いています。
x1.5拡大して上下ピッタリにすることもできますが、敢えて拡大しない方向にしました。
このサイズがちょうど、スマホの画面と物理的に同じぐらいのサイズなので。

処理性能が重かった件も解決。
ようやく移動環境（ノーパソ）でヌルヌル動けます。

ちなみに、音声あり or なしのどちらでも、性能的な差異は無しでした。
ピスコラだと、22050Hz/Monoでも結構キツイ環境なんですが。

ピスコラも私の独自音声（VGS）も、仕組みはだいたい同じ（いわゆる、波形メモリ音源）ですが、ピスコラの場合、恐らく音階別の波形データをリアルタイム算出している（※推測）のに対して、VGSの場合、全ての波形（４パターン）＋音階（８０ぐらい）の１周期分の波形データ（約256KB）をメモリにストアしているので、波形計算を咬まない分、ピスコラよりも高速に動くことができる・・・という訳です（たぶん）。この他にも、エンベロープやら色々な計算に浮動小数点数を使っていない（小数点が必要な部分は32bit符号値の固定小数点数で処理している）し、パイプラインハザード抑止（分岐数を最小限にする／分岐は予測分岐でヒットし易い形にする）など、色々やってますが。
代わりに、表現性能は圧倒的に劣りますが。

重い・・・

ノートPC（Windows）で、Android用STGのWindows版をコンパイル→起動してみたら・・・重い。
重過ぎると思ったら、（４ヶ月ぶりぐらいに起動したので）バックで色々とアップデートが走っていたり、シングルCPUだったり、GPUがショボイなど、色々と要因がありますが、それを勘案しても重い。

タスクマネージャで確認したところ、ゲーム自体のCPU使用率はせいぜい20%ぐらい＋他ユーザプロセスを合わせても30%そこそこ。ただし、パフォーマンス（グラフ）で見ると100%張り付き。
ウィンドウ描画でヒィヒィ言っている模様。

全画面モードを実装すれば解消できそうです。
全画面モードならウィンドウ描画も無く、画面サーフェースを排他的に使えるので。
眠いので、明日（今日）直すか・・・

ちなみに、INVADER BLOCK 2のWindows版も同じような感じ。
ってことは、Windows版を折角ダウンロードしてくれたのに、重すぎて買って貰えなかったケースもそこそこあるかもしれない・・・まぁ、INVADER BLOCK 2は、販売の一連の流れを確認するのが最大目的だったので、販売数はあまり気にするところではありませんが。（そもそも、Windows版INVADER BLOCK 2のDL数は、国内で約50DL、海外で約30DL程度ですし）

demoplay(title)

タイトル画面のデモプレイが無事完成。

デモプレイを入れるの面倒ですが、これが無いと「アーケードゲーム」って感じがしません。
アーケードゲームではなく、Android用ゲームですが。
あと、画面キャプチャは、Windows版ですが。（※勿論、Android版も全く同じように動きます）

リプレイ自体、実装はとても簡単なんですが、ちゃんとテーブル設計しないと再生がズレるバグが発生するので厄介です。ただ、その辺りはSHOT01～SHOT03の開発で色々とノウハウを培っているので、今回は全く苦労しませんでした。

本当に苦労しなかったか否かは、完成してみないと分かりませんが・・・

移動開発環境

Androidコンパイル環境の移動開発環境を準備しようと思っていたけど、スッカリ忘れていた。。。
というより、Android SDK自体が重過ぎる。
とりあえず、Eclipseを使っていないから大分マシな方ですが。
しかし、Android SDKだけでもかなり重い上に、NDK、Ant、Cygwinも軽くは無い。

でも、無理してAndroid SDKの移動環境を作る必要は無いかもしれません。
私の場合、VGE上で動作するようにWindowsで開発すればよいだけなので、チープな環境（ノート）に無理してAndroidのビルド環境を作る意味が無いであろう・・・と、思います。

体験版公開までやらなければいけない作業は、
(1) タイトル画面作成
(2) スコアシステム作成
(3) 1面後半（中ボス後）作成
(4) １ボス作成

一応、どれも実機が無ければ作成できない訳ではない。
上記(4)の作業については、実機が無いと調整が難しいですが、大枠についてはWindowsオンリーで問題無い（ハズ）。

ちなみに現在、(1)を作成中。

残作業は、デモプレイの画面を付けたりする作業など。

デモプレイというのは、タイトルで暫く放置しておけば勝手に始まる、STGでお馴染みのアレ。

デモプレイを入れる目的は、HowToPlay（遊び方）を短時間で端的に使えるため。

HowToPlayは言語差を考慮してこのデモプレイのみ。

デモプレイを付けるには、リプレイ機能を一通り作らないといけないから、やや大変です。

体験版では、リプレイ機能自体は使用不可にしますが。

体験版は、パーミッション不要にしたいので、ファイル保存系の機能は全般的に入れない予定。

あと、どうでも良いですが、タイトルは、Atomic Laser→NOKOGI Rider（ノコギライダー）に変更。

しかし、シューティングっぽくないタイトルだ・・・レースゲームと勘違いされそう。

販売する国と地域

開発中のSTGを販売する国／地域をどうするか・・・という問題があります。
消費間接税が色々と厄介なので。

日本の場合は問題無いです。
日本の消費税は、基準年度の課税売上が1,000万円を超えない限り、課税対象とはならないので、まず、問題にならない筈なので、まず気にする必要はありません。（そこまでの収益を上げるには、100円の収益のゲームなら10万本以上・・・だから、まず無理ぽです）
万が一、必要になっても、日本での手続きならちゃんと意思疎通ができるから問題ありません。
（確定申告ぐらいしかやったことありませんが）

問題は、海外の消費間接税。
例えば、欧州の付加価値税（VAT）は、年間売上が10,000€を超える場合、海外の事業者でも支払う必要があるようです。確か、日本の消費税は、海外の事業者が日本で販売した場合、非課税になったと思いますが。

物理的なモノの取引であれば水際（＝税関）でチェックが働くから、制度上問題ありませんが、電子商取引の場合、物理的なモノが無いから、完全に事業者側の自己申告に頼るしかないので、制度上問題があります。つまり、善意者の過失を防ぐ手段が無いことが問題です。例えば、国内の取引であれば、（自国の）法律を知らないでは済まされませんが、消費間接税については相手の国の法律によるものなので、どちらかというと知らない方が普通です。

ちなみに、Appleの場合、（EUのVATが問題になるのは有名な話しなので）Appleがその辺りを代行してくれるようですが、Googleの場合、その辺りのことは、各デベロッパに○投げという契約になっています。
どっちが正しいのかは微妙。
取引の公平性という観点で、Appleのやり方が正しい気がしますが。
というより、そうしないと税の面でクリーンな取引は不可能なんじゃないかな・・・と、思います。

さて、どうしたものか。

Invader Block 2 was uploaded in SOFTPEDIA

Invader Block 2（Windows版）が、SOFTPEDIAさんという海外サイトで配布開始されたようです。
http://games.softpedia.com/get/Freeware-Games/Invader-Block.shtml

Download.comの紹介文は私が書いたのですが、上記はSOFTPEDIAのライターさんが紹介文を書いてくれました。意思疎通する程度の英語を書いたり読んだりするのは概ね問題無いのですが、英語圏の方の感覚にマッチした書き方は分からないので、助かります。
「アルカノイド＆スペースインヴェーダーにインスパイアされたファンゲーム」
とのこと。
なるほど。

アップロードから数分程度しか時間が経っていないのですが、もう、15本ぐらいDLされたようです。
これで、ちょっとは海外でも（Android版が）売れるかな。
まぁ、売れる売れないは別として、色々な国の人に遊んで貰えるだけでも嬉しいものです。

スクリーン仕様変更

開発中のSTGのスクリーン仕様を大幅に変えることにしました。
私が開発しているゲームエンジンは、「240x320の仮想ビデオメモリ領域をアスペクト比を保った状態で最大限に拡大し、画面中央に配置する」という仕様です。

Androidの場合、最も画面領域の小さい機種が240x320（QVGA）だという事情もありますが、個人的にQVGAが一番ゲームが作り易いし、ちょっと粗い感じの画面が好きだという事情が一番大きいです。もちろん、その部分の仕様は変更しません。

仕様変更するのは、「画面中央に配置」という部分。
具体的には下図のような感じに仕様変更します。

端末画面の縦横比が４：３（VGAやQVGAなど）の場合、画面目一杯拡大される形になります。
しかし、現状、市場に流通しているAndroidは、殆ど１．５：１（iPhoneと同じ比率）です。
１．５：１の画面の中に４：３の仮想スクリーンを、アスペクト比を保った状態で最大限に拡大すると、必然的に画面の上下にBLANK（余白）が発生します。

そして、そのBLANKを上下に均等分配していたものを、下に纏める形にします。
もちろん、仕様変更前の方がカッコイイんですが、背に腹はかえられぬ事情があります。

BLANK領域にも当然ながらタッチ判定があるのですが、現状仕様だと、プレイ中に誤ってHOMEボタンやRETURNボタンを押してしまう可能性が高そうだったので。つまり、誤ってホーム画面に戻ってしまったり、ポーズしてしまう誤操作が、かなりの高確率で発生してしまいます。（今日、昼休み中のテストプレイで数回、発生）

INVADER BLOCK2のように、左右移動だけなら発生することはほぼ無いですが。
しかし、開発中のSTGは、上下移動はよくするので、目を瞑れない程度のレベルで誤操作してしまいます。

という訳で、画面下にタッチ用の余白を確保することにしました。
まぁ、iPhoneの勢力からして、Androidの主流が再び４：３に戻ることは無いだろうと期待しつつ。

っていうか、そもそもボタンを画面下に持ってくる設計がそもそも微妙な気がしますが。
ハードウェアのボタンは画面上でも全然困らないです。
ゲーム以外のアプリでも、ボタンが画面下にある所為で操作ミスすることがありますし。

そういう操作ミスをし易いアプリを操作する場合、基本的に逆さまにして操作していｒ...
・・・これを書いていて気付いたのですが、画面を上下逆表示する機能があれば、良いんじゃない？という神が掛かったアイディアを思いつきました。（ちなみに、重力判定は重いからoffにしているので、ソフトウェア的に実装する必要があるから、若干面倒ですが、無理ではないです）

状況

開発中のSTGが予定通り、中ボスまでできて、あと色々と細かい画面エフェクト系のシステム周りも作っておき、無事Androidへのポーティングも完了。これで、ウィークデーも会社でデバッグができます・・・疲れた。

今回のゲームは、Windows（マウス）よりもAndroid（タッチパネル）の方が断然操作し易い。
InvaderBlock2は微妙にWindowsの方が操作し易かったのですが。
やっぱり、マウスだと左クリックしっ放しという状態は結構疲れるのかもしれません。
なので、Windows版をタダで配ってAndroid版を売るパターンは止めにしようか悩みどころです。

今回は、ステージ型のSTGなので、Android上で体験版を配るのみでも良いかもしれない。
フリーで作って配ったアプリ（VGS Chiptune Music）は、何も宣伝しなくても50本以上ダウンロードされたので、フリーであれば、配るだけでも宣伝効果があるようですし。


しかし、ここ数ヶ月、土日も仕事をしているような感じなので、GWにはゆっくり休みたいところ。

当り判定のつけかた

ようやく、中ボスを作成する作業に入ります。
まだ、色々と完成していない部分はありますが、今日中にとりあえず中ボスを作成しておき、Androidで中ボス戦まで遊べる状態にしておけば、ウィークデー中でも会社の休み時間などに調整ができるので、中ボスまで作ることを優先で。

ちなみに、中ボスの当り判定ですが、下図の紫枠のような感じになります。

私のSTGシステムの場合、１体の敵キャラクタはパーツ、オブジェクト（パーツ集合）、クラス（オブジェクト集合）という３層のデータ構造で表現しているので、パーツを上図の紫枠のように分割し、パーツ単位に当り判定します。
当り判定の範囲はパーツ単位で枠よりも小さくしたり、無判定にすることが可能。
そして、敵の耐久力はオブジェクト単位という感じです。

中ボスは、登場中に他の敵キャラクタが登場しないので、パーツを細かくして細かい当り判定をできるようにしよう・・・と、思ったら、パーツのハードリミット（１２個）を超えてしまったので、ハードリミットを１６に拡張しました。実は、パーツのハードリミットを拡張しても、処理性能への影響が無いので、もっと多くしても良いのですが、多くしてしまうと、ROMファイル（プログラムを除くデータ情報を格納したファイル）のサイズが大きくなります。

ちなみに、現時点のROMファイルのサイズは、1,312,322byte。
プログラム本体のサイズは、551,936byte。
合わせて1,864,268byte。（1.78MB）
APK（ZIP）に圧縮すると、600KBぐらいです。

気にする程、容量が膨れ上がっている訳ではないですが、「無駄データは１バイトでも少なくしたい」と思うのがプログラマの性癖です。BGMをoggとかmp3にしてしまうと、平気で数10MB～数100MBになりますが、やはり、それは気分が良いものではありません。

システム周り

STGの開発状況は、１面中ボスの手前まではできました。
中ボスを作る前に、難易度やゲームシステム周りに色々手を入れてます。

難易度的には、前３作と比較して大分落とします。
一応、EASY/NORMAL/HARDの３ランクを準備しますが、
・EASY = Elementary向け
・NORMAL = Soldier向け
・HARD = Ninja向け（私が楽しめる難易度）
という感じになる筈。

ゲームシステム的には、ボンバーが無いので、代わりに設けている回避処置（LASER）のルールを色々と弄って、良い感じになるようにしています。
当初、レーザー中は完全無敵にしようと思っていたのですが、それだと色々とバランス崩壊してしまうので、上手い感じになるように色々と調整してます。今の所、かなり流動的にルールが変化しているので、確定的なことは何も言えませんが。

一応、GW中には体験版（１面のみ）をリリースしたいのですが、できるかどうかは今のところ五分。
ザコ 敵が現状、まだ５種類しか居ないし。
ただ、ザコ敵の種類はあと１種類ぐらいで丁度良いかも・・・と思い始めてますが。
そういえば、SHOT03の時も、１面で作ったのは６種類だった気がします。
当初、１ステージ10種類ぐらい＆各ステージで流用無しで作ろうかと意気込んでいましたが。


しかし、一般的なSTGの1ステージあたりのザコ敵数って果たして何種類ぐらいなのか・・・

怒首領蜂の１面は、
①緑戦車（小）
②赤戦車（小）・・・恐らく、アルゴリズムは①と同じ
③小型ヘリ
④中型飛行機（丸っこいやつ）
⑤大型戦車
⑥ポッド？
⑦中ボス
⑧大ボス
だったと思います。
記憶違いがあるかもしれませんが。

やはり、ザコ＝６種類がベストかな。

アプリの信頼を得る方法

先日、Androidアプリの許可（パーミッション）に関する記事で「Googleが登録審査すべき」みたいなことを書きましたが、今朝やってたNHKの番組で専門家の人が、「それはまず無い」というような感じのことを言ってました。まぁ、Googleのスタンスからして、私もそれはほぼ無いだろうと思ってます。

アプリをダウンロード時の注意点について、専門家の意見を纏めると、
(1) ユーザがアプリインストール時にちゃんと許可（パーミッション）をチェックすべき
(2) 他のユーザが書いているレビューを参考にすべき
(3) なるべく安全なマーケット（キャリア提供のマーケット）だけ利用すべき
という感じ。
大筋ではこんな感じのことを伝えている番組でした。
（若干、私の脳内変換が入っているかも）

私が配布するアプリには、当然悪意は一切無いのですが、その点を第三者から信頼して貰う手段として、キャリア提供のマーケットで配るというのが有効かな・・・と、思いました。そこで、au Marketへアプリを登録する手段を調べてみましたが、au Marketへのアプリ登録者は原則的に日本国内に登記されている法人である必要があるようです（au Market利用規約の第5条3項2号を参照）。ただ、法人じゃなければダメ（＝必須要件）ではなく、例外が有るようですが。（あくまでも、例外なので「法人限定」という解釈で問題無いと思います）

現状、法人限定という点がちょっとハードルが高い。。。

上記以外の方法で、アプリの客観的信頼を得る方法としては、iPhone版を作って販売するのもそこそこ有効かも。アップルは、（審査が厳しいか否かは別にして）登録するアプリを審査しているようなので。

マルチプラットフォーム化は、開発者に技術力がそこそこ要求されるのがネックですが、幸い私には、それが問題にならない程度の技術（エミュレータを作れる程度の技術）なら有るので、ネックになる事が何も有りません。なので、今作っているSTGが完成したら、そのSTGとInvaderBlock2のiPhone版を作ろうと考えています。

ちなみに、私が開発しているAndroidアプリは全て、VGEという独自システムの上で作っていて、その独自システムはかなりチープな環境でも動作できる設計にしているから、iPhoneへの完全移植は容易です・・・たぶん（一応、iPhone移植を見越して論理ハードウェアを設計しているつもり）。

VGE（Video Game Engine system）というのは、CPUエミュレーションの無いエミュレータみたいなものです。実在する模倣対象のハードウェアが存在しないので、エミュレータというのは用語として適切では無いかもしれませんが、要するに、画面・入力・音声の要素部分を抽象化したものです。（下図のようなもの）

ちなみに、VGEの実在ハードは存在しませんが、自主制作（趣味）でこのVGEの仕組みを搭載した、携帯型ゲーム専用機（ハード）を作りたい・・・という野望が有ったりします。だから、VGE＝エミュレータというのは、強ち間違いではありません。「鶏が先か、卵が先か」という話しです。

ヘリ旋回

ヘリを旋回させた時のハネの座標を計算する作業が終了。

何のこっちゃ？
ですね。

ヘリが回転（旋回）する時、主翼（一番大きいプロペラ）の中心点を軸にして機体を回転させるのですが、その際に本体と尾翼の位置を求める作業です。

具体的には、以下のロジックのposを埋める作業。

/*  *----------------------------------------------------------------------------  * ヘリの向きを変える  *----------------------------------------------------------------------------  */ static void heri_roll(struct Enemy* e,short d) { static const short pos[9][4]={ {7,5,15,1} ,{5,5,5,3} ,{5,8,-2,14} ,{10,5,2,24} ,{6,11,8,30} ,{8,10,21,31} ,{10,8,30,23} ,{10,7,32,12} ,{10,5,27,2} }; int p; e->obj[0].pt[0].n+=d; while(e->obj[0].pt[0].n<31) e->obj[0].pt[0].n+=9; while(39<e->obj[0].pt[0].n) e->obj[0].pt[0].n-=9; p=e->obj[0].pt[0].n-31; e->obj[0].pt[0].x=pos[p][0]; e->obj[0].pt[0].y=pos[p][1]; e->obj[0].pt[1].x=pos[p][2]; e->obj[0].pt[1].y=pos[p][3]; }

ヘリは、９パターン（４０度）で作ったから、中々面倒でした。


ヘリ本体のスプライトサイズが32x32、主翼が48x48、尾翼が16x16という具合にパーツ毎にサイズが違うので、ズレを座標計算するのが中々めんどいです。

座標のズレを必要としない画像パターンを最初から準備すれば楽なんですが。
ただ、そうすると無駄にパターンサイズが大きくなってしまいます。
つまり、メモリ効率が悪くなります。
あと、スプライトサイズが大きいほど、処理も食います。


そういえば、上のキャプチャを取って初めて気付きましたが、プロペラの影の座標がズレてる・・・
影は、スプライトの1/2サイズなので、ズレ座標も1/2しなければいけないけど、それが漏れていたっぽい。早めに気付けて良かった。画面キャプチャを取ってみて初めて気づくバグが稀によく有るので、この開発日記を書く作業は結構有意義かもしれません。

タイトルの付け方

開発中のゲームのタイトルですが、一応、タイトル画面の画像を貼り付けたとき、「Atomic Laser」と書いてあったかもしれませんが、「Atomic Laser」にするつもりは無いです。流石に、それではダサ過ぎるので。

タイトルってかなり重要だと思います。

一応、候補に挙がっているのは、幾つかあります。
今のところ最有力候補は、SHOT04 - NO・KO・GI Rider （ショットゼロヨン・ノコギライダー）

VGS Chiptune Musicを作ったとき、ノコギリ波の波形名を表示する際、表示領域が足りなくて、「NOKOGIR」という略記にしたのですが、「ノコギルって何かカッコ良くない？」という感じです。

あと、このゲームの２面で使用予定の音楽（のピスコラ版）をピスコラの曲投稿サイトに投稿した時、
「'80年代戦隊ヒーローモノっぽい」
という評価を頂いたので、ノコギル＋戦隊っぽい何か・・・ということで、Nokogi Riderです。

ただ、Nokogi Riderだと見栄えがカッコ悪いから、「NO・KO・GI Rinder」です。
「E・S・P Rade」と概ね同じノリだと思います。
エスプレイド的な要素はほぼ無いと思いますが。

今のところノコギリ的な要素が皆無なのが難点。
結構気に入っているのですが。

PAUSE画面（その２）

現在開発中のSTGにポーズ画面を入れる修正を、Androidでも実装。

やり方としてはシンプルに、
http://techbooster.jpn.org/andriod/ui/4109/
上記URLで紹介されているBACKキーの入力を取得する方法で、BACKキーが押された時、デフォルト動作（アプリを停止）せずに、ポーズ画面に移行する感じにしました。

あと、HOMEキーを押した時は、ポーズ画面に移行しつつ、バックグラウンドに移行する形になります。
本当は、HOMEキーでもポーズ画面にしようとしたのですが、HOMEキーの入力情報はアプリで取得できないようなので、デフォルト動作（バックグラウンドに移行）しつつ、ポーズ画面に移行することにしました。

まぁ、HOMEキーもBACKキーと同じ動作することも不可能ではないと思いますが、このデフォルト動作（バックグラウンド移行）を変えるのは、結構危険と判断しました。というのも、例えばプレイ中に電話が掛かって来るといった割り込み動作がHOME相当の処理になりそうな気がしたので。
なので、この部分に手を入れてしまうと、優先度が高い割り込み操作が入ったときにKillManagerに殺られちゃうんじゃないかなぁ～・・・と想像しました。
ついでに、プレイ中にホームに戻りたいことも無いことは無かろうと思いますし。

忘れかけてましたが、一応スマホって電話なんですよね。
だから、電話用途で使われる可能性を排除しちゃいけないと思います。（一応）
電話としてのスマホの魅力は皆無ですが。

ヘリのハネ

シューティングといえば、ヘリ。
ヘリといえばシューティング・・・

・・・というぐらいのヘリ厨なんですが、そういえば、未だ嘗て、自作STGにヘリを出してなかった。
なので、今回は出します。
という訳で、ササッと作画。

ヘリのハネですが、＋状のものと、×状のものの２パターンだけでOK。
これだけでかなり自然な回転アニメーションになります。
適当なSTGの画面キャプチャを見れば分かると思いますが、皆、こんな感じです。
ゲームによっては、残像を少し付けた感じのものもありましたが。
まだ動かして確認していないので、動かしてみて、物足りなかったらつけようと思います（残像）。
何れにせよ、機械的なエフェクトで作画ができるから簡単。

PAUSE画面

そういえば、今回のAtomicLaserではポーズ画面を入れようと思っています。
実装中ですが、画面は↓こんな感じ。

スプライト表示が消える仕様です。
スプライト表示も残して画面を暗転する仕様にすることもできなくもないけど。

ちなみに、ホームボタンor戻るボタンのどちらを押してもポーズ画面にする仕様にするつもり。
あと、Windows版は画面フォーカスを失ったときもそうした方が良いかな。

ポーズ画面を入れる理由ですが、リセット（VGEのハードリセット）を入れる事が目的です。
InvaderBlock2の場合、1プレイ時間がものすごく短いので、心理的に不要だったのですが、シューティングの場合、ソフトリセットが無いと流石にマズイかなぁ・・・と、思ったので。
シューティングの場合、本当はソフトリセットが無い仕様の方が上達できるんですが・・・やはり、コンシューマ機向けのゲームだと有って当然だし、無いことを不快に思う人も結構居るはずでしょうから。私自信、アーケードゲームで育った人間で、コンシューマゲームは殆どやったことが無いから、ポーズ画面の必要性をあまり感じて無かったりします。

Androidのcharは符号なし

とりあえず、AtomicLaserをAndroidでコンパイルして動かしてみました。
写真は、デバッグ専用のタブレットで動かしたものですが、スマホでも問題無く動きます。

Windows→Android移植作業の過程で、Androidのプラットフォーム固有バグを、また発見。

どうも、AndroidのCでは、charが符号付き8bitの整数値ではないらしいです。
符号付き8bitの整数値同士の計算であれば良い（２の補数だからオーバフローにより期待値が得られる）けど、キャストして演算すると変な結果になってしまいます。

例えば、
------------------------------
char c = -1;
int i=0;
i+=c;
printf("%d\n",i);
------------------------------
という計算を行った場合の標準出力結果は、
Windows → -1
Android → 255
という風になります。

Linuxの仕様かも。
仕事でプログラムを組むときは、8bit符号整数は使わないので、詳しくは未調査です。
ゲームの場合、大量のデータを管理するとき、敢えて8bit符号整数を使う事がよく有りますが。（例えば、リプレイデータなんかの場合、処理効率よりもデータ量を少なくする事の方が重要だから、-128～127の範囲に収まる保存値は8bitで管理したりします）

これのお陰で、内部関数の仕様を大分変える必要がありました。。。
今の内に気付けただけでもラッキーと思っておくべきか。

todo

本日は有給休暇。
試験後は必ず有給休暇を取っていますが、試験が半ボイコット状態なので、若干後ろめたいです。

敵弾や敵＆敵弾との当り判定、自機の爆破などを実装。
敵弾は、敵と概ね似たような感じの別のデータで管理することにしました。

あとは、
・ザコ敵の種類を追加（現状３対のみ。１ステージ８種類ぐらい欲しい）
・敵弾の種類を追加（現状、自機狙い/自機外しと固定方向弾の２種類のみ）
・中ボス
・ボス
・ゲームオーバー処理
・ステージクリア処理
・スコアシステム
が主だった作りこみ系の作業か。

ちなみに、ランクはEASY/NORMAL/HARDの３種類。
EASYは、「ナメんな！」というぐらい楽にするつもり。
HARDは、「ふざけんな！」というぐらい難しくするつもり。

そういえば、まだAndroidで一回もコンパイルしたことが無いので、そろそろ、一度実機で検証をしてみる必要があるかも。前回、InvaderBlock2を初めてWindows→Androidに移行した時、色々とトラブったので。
特に、入力系統が想定通りにできるかどうか、早めに確認しておかないとマズイことになります。

タイトル画面

タイトル画面（仮）を作成。
概ね、InvaderBlock2と同じメニューになります。

実は、普段ゲームを作るとき、タイトルはゲーム本編が完成後に作っているのですが、後で作る方が面倒なので、先に作っておくことにしました。先に作っておく方が、色々と便利。

まだ、画面上の何処をタッチしてもゲームスタートにしかなりませんが。
評価版では、プラクティス以外全部使える状態にするつもりです。


全然関係ありませんが、今日は情報処理試験でしたが、午前２のみ受験して帰宅。
次の秋は、午前１を受けなければいけないけど、割と朝には強いので問題ありません。
なんというか、時間配分を間違えました。
微妙に時間が掛かる計算問題が２問ほどあったのですが、ウッカリそれらをじっくり解いてしまい、後半猛スピードでとりあえず全問回答・・・という典型的なダメパターンでした。明らかにサービスっぽい問題が後半に多かったのですが、そういう問題にジックリ時間を取らなかったから、イージートラップに引っ掛かってしまったものが多そう。あと、用語で微妙に記憶が曖昧なものも多かったです・・・これは、単なる勉強不足。
こういう場合、恐らくギリギリ６割に届かない程度の解答率になるので、時間が惜しいと思い帰宅。
午前が落ちていて、午後が手応えあり・・・というパターンは避けたいところです。
午前は即日で公式回答が出る＆合格ラインが決まっているので無常です。（昔は相対評価でしたが）
仮に午前が受かっていても微妙な気分になりますが。

Androidアプリの「許可」について

Android端末を使っている知り合いが、アプリの許可（パーミッション）について知らなかったことに驚きました。

許可（パーミッション）の情報は、GooglePlayとかでアプリをダウンロードする時に表示されます。
インストール済みのアプリについては、アプリの管理画面から確認することができます。

ちなみに、私が配布しているアプリで使用している許可は、
・INVADER BLOCK 2 → ストレージ
・VGS Chiptune music → なし
です。

ストレージというのは、SDカードへのファイル書き込み許可です。（以下）

---

ストレージ

USB ストレージのコンテンツの変更/削除、SD カードのコンテンツの変更/削除

USBストレージへの書き込みをアプリに許可します。SDカードへの書き込みをアプリに許可します。

---

※ストレージの許可は、スコア＆リプレイをSDカードに記録する目的で付与しています。

危険な許可の代表例は、「携帯のステータスとIDの読み取り」とか、「連絡先データの読み取り」など。
私のアプリでは（不要だから）設定していません。

連絡先の管理をするアプリであれば、「連絡先データの読み取り」（＆書き込み）が必須なので、連絡先の管理をするアプリをダウンロードする場合、「発行元が本当に信頼できるか？」という点を、利用者の責任で十分に確認してからダウンロードする必要があります。

今、世間で「the Movie」なるタイトルを冠するアプリが、連絡先の情報を抜き取って何処かに送りつけていた事件が起こってますが、それらアプリが「連絡先データの読み取り」の許可を必要としていることは、ダウンロード時に表示されていたようです。

私はそれらのアプリをダウンロードしようとしたことが無く、プレスから得た情報ですが。（ソースは以下）
http://www.itmedia.co.jp/enterprise/articles/1204/13/news113.html

もちろん、アプリの発行元が悪意をもって情報を抜き取っていたことはほぼ確実だと思うので、悪いのはそのアプリの発行元だということはほぼ間違いないと思います。ただ、ネットワークアクセスをするにも関わらず、ネットワークアクセスについての許可が表示されなかった点はAndroidの脆弱性だと思いますが。

また、「利用者に何も過失が無かった」とは言えないように思います。
アプリの許可（パーミッション）について、「何故こんな許可を必要とするのか？」という疑問があるアプリは、一切ダウンロードすべきではないです。
特に、「連絡先データの読み取り」については、「利用者本人だけでなく、利用者の友人や家族などの情報へのアクセスをアプリに許す」ということを意味しているから、十分に注意する必要があります。

あと、Googleもそういう点（不可解な許可の設定）については、審査すべきだと思います。
もちろん、目視での確認が必要になるので、相応のコストが掛かると思いますが、それは必要支出だと思います。
その程度の審査でも、やっていれば今回のケースは事前に防げた可能性が高いので。
（動画を見るのに連絡先を参照する意味が全く無いので）
もちろん、人間による審査だから100%確実ではないかもしれませんが、「審査を行っている」という点が重要。
今のままでは、「審査すら行っていない」という点で、Googleに過失責任がある気がします。

マップエディタやら

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

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

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

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

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

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

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

海外でのDL状況

Windows版InvaderBlock2を海外（CNET）で公開してそろそろ１週間ですが、Android版のダウンロード数に変化はなし・・・。InvaderBlock2は、シューティングというカテゴリになると思いますが、やっぱり、海外では所謂FPSじゃない普通のシューティングは人気無いのかな（と、思いつつシューティングを作ってますが）。

若しくは、CNET版が全然ダウンロードされていないとか。
（CNETでのダウンロード数はWeeklyで把握できるようなので、まだ分かりません）

InvaderBlock2はそんな感じですが、同時期に無償で公開した、独自波形メモリ音源のサンプル音楽集（VGS）はそこそこダウンロードされました。全く何も宣伝していませんが、トータルで50本ぐらい。


やはり、フリーは強い。


ちなみに、デベロッパコンソールで国別のダウンロード数を確認できます。
InvaderBlock2のダウンロードは日本のみですが、VGSは色々な国でダウンロードされました。
１位は米国で２位は日本です。

その辺りは想定通り。

３位がインドネシアというのが興味深かったです。
４位以下は概ね色々な国が横並びなので、日米以外ではインドネシアが突出してます。
インドネシアでは、Androidが凄く普及しているのだろうか・・・
と、思ったのですが、AndroidよりもBlackBerryの普及率の方が高いようです。

インドネシア人の心を掴む英語の紹介文が書けていたのだろうか？
インドネシア語はよく知りませんが、ヒンディー語（インドで一番メジャーな言語）とかは、日本語と文法が結構近いから、日本人が書いた英語が読みやすいとか・・・インドのダウンロード数はゼロですが。

謎です。

自機の方向を向く砲台

自機の方向を向く砲台のアルゴリズムを実装。

VGE（独自ゲームエンジン）には回転機能は無いので、砲台の絵を18パターン用意しました。
（18パターンということは20度単位ということになります）

その18パターンの砲台で、自機の方向を向かせるアルゴリズムがちょっと厄介でした。
アルゴリズム自体は、至極簡単なんですが。
自機と砲台の中心点間の角度を求め、単位度数で除算し、求まる番号＝パターン番号です。
（その辺りの情報はぐぐれば色々出てくるので省きます）


問題は、C言語の数学ライブラリ（math）にどの程度のプラットフォーム誤差が生じ得るか・・・ということ。数学ライブラリは、インタフェース自体が標準化されていても、内部の計算式で微妙に方言があることがあります。
なので、Windows/Androidクロスプラットフォームで開発している場合、使用すべきではないです。
結局、アークタンジェント（＋その算出の過程で使う平方根）を自前実装しました。

あと、サイン・コサインあたりも、標準ライブラリではなく自前で実装。（それらは単純なテーブル）

もちろん、扱う数値情報は固定小数点のみだから、物凄く高速です。
なので、沢山弾を出すことができます。

Invader Block in CNET Download.com

Windows版の「INVADER BLOCK 2」が無事、公開されました。
http://download.cnet.com/Invader-Block/3000-2095_4-75699783.html?tag=main;dropDownForm

CNETのスタッフ（？）により、表示タイトルが「Invader Block」へ修正されてしまったようですが。
- 全部大文字というのは、ヘン。
- タイトルに2が付いてないやんか？
あたりの事情かな。
まぁ、大した問題ではありません。

申請～アップロードまでに掛かる時間は、概ねVectorと同じぐらいといった感じのようです。
ダウンロード数がデイリーかリアルタイムかは不明ですが、Web上で確認できるのが良いです。
ただ、CNET側に独自のインストーラが組み込まれるのがちょっとアレですが。

Vectorの場合、月次でメールで報告という方式 or 申請して報告を貰う方式なので、面倒。ついでに、例のクラッキング問題で、月次メールが来ないらしいので、国内では果たして何本ダウンロードされたのかが不明です。

あと、Vectorは、アップロード申請もできない状態だったので、CNETの方が最新版になります。

平日不調

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

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

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

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


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

なかなか快調

なかなか快調です。
GWにテストバージョン（１面のみ＆無料）をAndroidマーケットに流すのも無理では無さそうです。
現時点の画面は↓こんな感じ。

ただ、そろそろ情報処理技術者試験が近いので、勉強した方が良いかなぁ・・・
受験区分はプロジェクトマネージャで、実質２回目の受験。
２回目だから勉強しなくても良いか、２回目だからこそ勉強すべきか。

迷いどころです。
１回目なら迷わず勉強するしかありませんが。

去年、味見で受験した実績では、勉強をしなくても論文以外は何とかなった（論文がＢ評価で不合格だった）ので、論文の対策（＝ネタの仕込み）だけは必要な気がしますが、そうやって高を括って受けると案外、午前や午後１で落ちそうな気がします。

ただ、焦って取る必要がある程のものではないから、開発作業を優先したいところ。
ついでに、本業であまりプロマネ的な仕事はしたくないから、下手に合格してしまうと墓穴を掘りかねない。
もちろん、受験料が勿体無いから受験はするし、受験する以上、最後まで受けますが。

受験する唯一の目的は、合格祝い金です。

同じレベル４の区分の中でも結構高いんですよね、この試験。
個人的には、スペシャリスト系（同じレベル４）の方が難しい気がします。
だけど、スペシャリスト系だと合格祝い金が大分安い。


 金、金、金！ 騎士として恥ずかしくないのか！

と、言われてしまいそうですが。

敵アルゴリズム

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

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

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

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


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


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

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

海外向けプロモーションの準備概ね完了

現時点で、Android用に有償アプリ、無償アプリを各１本を作って公開中。
ちなみに、有償アプリ（INVADER BLOCK 2）と無償アプリ（VGE Chiptune music）は全くの別物です。
有償アプリの機能制約版（Lite版？）を配り、プロモーションするやり方ではありません。
「INVADER BLOCK 2」の場合、ゲームの性質上、機能制約に向かないので。

無償アプリの方は公開から数週間で30本程度ダウンロードされました。
しかし、有償アプリは公開しただけでは全然売れません。
当然といえば当然。

独自の技術（Video Game Engine）により、Windows上で全く同じ動作をするものを作り、Windows用をVectorでフリーで配ってみたところ、少しだけ売れましたが。なので、何かしら無料版を試す機会を提供するのが必須だと思います。

ちなみに、無償アプリの方は世界各国、様々な地域でダウンロードされましたが、有償アプリの販売実績は日本のみ。現状、Vectorでしか配っていないためだと思います。という訳で、ダウンロード数を伸ばすためには海外向けのプロモーションが必須であろうということで、米国のソフトウェアダウンロードサイトに登録しました。

海外サイトに登録するのは中々厄介でした（ウェブサイトの英語化や英語ドキュメントの準備など...）が、何とかSuzukiPlanがCNETのカンパニーとして登録が承認されたようです。Windows版「INVADER BLOCK 2」を登録する手続きも済ませたので、あとは、それの審査待ち。

これで、海外向けに少しは売れるのか・・・は、未知数ですが。
ちなみに、カンパニーというのは和訳すると会社ですが、SuzukiPlanは法人ではないです。
日本の場合、（会社法上の）会社は法人でなければなりませんが。
住民税を支払えるほどの収入も無いし、そもそも法人制度の意義に当てはまらないので。

法人というのは、一種の法律テクニックとして、自然人以外のものに自然人の一部の権利能力（制限された権利能力）を与えた論理的な人を存在させるものです。その意義は、複数の人の意思を統合してひとつの意思として活動することが第一義だと私は考えています。
成人の自然人（但し、制限行為能力者を除く）には強力な権利能力が有るので、同じ事業を複数の人が同時にやろうとすると、取引の安全性が損なわれてしまう恐れがあるから、特定の目的に限って活動する別の人として法人という物理的に存在しない論理的な人を作る必要があるという訳です・・・あくまでも、私の勘ですが。
よく、法人化の目的として節税対策や損益の繰越の仕組みの違いなどが挙げられますが、これは副次的なもの（＝おまけ）で、重要なのは複数の人間が経営に携わっているか否かという点です。“経営に”という部分が少し重要。つまり、従業員や（普通の）中間管理職の人は含まれません。経営に携わる人というのは、法人の意思決定について権限を持つ人のことだと思います。なので、一般的な会社であれば、株主、取締役、執行役などが合計二人以上居る場合は法人化すべきで、そうでない場合は法人化する必要は無いと思います。法人の種類によっては、人数が「ｘ人以上」という決まりがあるものもありますが、いずれの法人も意思決定機関が必須でそれが複数（二人以上）であることが法律上の要件になっているんじゃないかと思います。あくまでも勘ですが。（私は法律の専門家ではないので）

余談が長くなりましたが、英語のカンパニーというのは、事業として営利活動をしていれば当てはまります。
自然人か法人かは不問です。つまり、個人事業主も含まれます。
個人事業主は「Sole proprietor」ですが。
カンパニーとしておけば、より広い範囲で含まれるから便利。（company limitedもcompanyの一種）

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）の開発はヤメにして、別路線を探るつもり。

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