2面完成

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

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


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

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

動く背景

体験版の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が載っている全ての端末で処理落ちすることなく動作できるアプリにするつもりで作っているので、性能にはかなり気を遣わざるを得ません。

ペース

GW明けにSHOT04体験版をリリースした筈なので、約１ヶ月ちょっと経過か。
現状、２面ステージが完成し、２面ボスを作成中。
開発ペースは、概ね予定通り。
夏休みに纏まった期間でサクサクッと完成させて、リリースさせるのが夢ではなさそうです。

約１ヶ月経過ということで、体験版のDL数をチェックしたところ、700DL弱ぐらい。
想定よりも多いです。
ただ、有効インストール数は300弱。余裕の50%割れ・・・orz
ついでに、海外でのDL数はサッパリ。
多分、英語の説明文をかなり手を抜いたので、検索キーワードとかで良い感じにヒットしない為かな。

ちなみに、日本以外での有効インストール数は、中東方面に偏った感じ。
アラビア圏が５件、欧州圏が１件、アジア圏が１件。
当初期待していた米国は０件。

亜米利加人は、ドンパチするゲームは好きだろうと思ったのですが、やはり、FPSじゃないとダメなんですかねぇ。
だからといって、私がFPS開発に手を染めることは100%有り得ないことですが。

スコアシステム修正

現状のスコア算出方式ですが、ちょっと微妙だと思い始めました。
現状、メインショットの打ち込みが一定時間無かった時にSHOT値（MAX99,999）が10%づつ減少していき、その時の減少値を基点としたスコア加算をしてます。
しかし、この方式だと相当な変態的な稼ぎプレイが必要になってしてしまう・・・

上限に達した場合、一定時間フレームアウトを狙い、10,000を割り切らないようにしてまた打ち込みを続けるということを繰り返すと、スコアが高くなる訳です。（それを狙ってやるのは、かなり厳しい）

もっと直感的な稼ぎができるように修正するしかない。
狙いは、上級者のプレイを変態的にすることではなく、見ていて楽しいものにすること。
なので、稼ぎ方は直感的であれば、直感的である程良い（ハズ）。

耐えて忍ぶ者（要するにM）

２面中ボスが完成。
作画～プログラム作成まで一日掛り。
作画は例によって、DOGA先生が大活躍ですが、結構自分で描いたパーツもあったりします。
キャタピラとか、大砲とか。

低難度（Beginner/Soldier）でも、そこそこ苦戦するかも・・・という難易度にしておきました。
コレを倒せば１upするので、まぁ、良いかな。
難易度インフレは抑えたい所。

しかし、Ninja（最高難度のモード）については、リミッターを外しておきました。
まだ序盤ですが、色々と酷いので、きっと、上級者でも愉しめます。
もちろん、無理ゲーにはしません。
Ninjaに関しては、私がギリギリクリアできる難易度が目標。

ちなみに、難易度の名称（Beginner/Soldier/Ninja）ですが、Beginner/Soldierは適当。
Ninjaは一見すると外国人向けにウケを狙っているように見えるかもしれませんが、違います。
実はちゃんと考えあっての名称です。
まぁ、考えているとはいっても、フザけた考えですが。（記事のタイトル参照）

Music Room

作曲担当の鈴木が、SHOT04の２曲目のBOSS曲を作ったのですが、肝心の2面ボスがまだできていない・・・
音量調整用のデバッグ機能として、Music Roomを作ってみました。
これで調整できる。

ちなみに、作曲担当の鈴木の他に、音響効果担当の鈴木、グラフィック担当の鈴木、プログラマの鈴木の計４人に鈴木を使って平行作業をしています。このブログは広報担当の鈴木が書いているから５人か。５人とはいっても、時分割多重方式だから、常人の目には１人で作業しているようにしか見えないらしいです。

未だ作っていない曲は、ステージ５とボス３とエンディング。
実は、「作っていない」とはいっても、VGS用のMMLを作っていないだけで、作曲自体は済んでますが。
作曲自体は、去年作り溜めた曲と昔作った曲のアレンジが大半。
今年作った曲は、ステージ４の曲のみ。

腕が鈍るのもアレなので、ボス曲を３→５に増やしてみようか・・・と思ってますが、プログラム担当の割り当て時間を増やしたいので、その計画が実現する可能性は低いと思います。とりあえず、１面＆３面をBOSS1、２面＆４面をBOSS2、５面をBOSS3という具合にすれば、割と飽きずに音楽を楽しめると思っていたりもするので。（何よりも、作曲自体が完全に専門外だから、得意ではない）

ちなみに、ある方法を行うことで、製品版でもこのMusic Roomへ行けるようにしておきます。
私の音楽を聴きたい人など居ないだろうと思ったのですが、海外で割と評判が良かったので。
それでも、ニーズはそんなに無いと思うから、裏技にしておきます。

リプレイ圧縮

リプレイの圧縮ロジックの実装が完了。
試しに１面～２面途中までの実際のプレイデータ（9241フレーム）で圧縮率を測ってみたところ
・圧縮前：46,269byte
・圧縮後：16,401byte ＜圧縮前の約35%＞
という感じ。

だいたい、1/3ぐらい。
zipのアルゴリズムで圧縮した場合、平均して圧縮前の90%程度に圧縮できたので、zipには全然及びません。
まぁ、簡単なアルゴリズムで圧縮しているので、この程度です。
もうちょっとネバってアルゴリズムを改造するか若しくはgzipにすべきか又は諦めるか・・・
まぁ、35%でも圧縮できた訳ですし、サラリと諦めてゲーム本編の開発を急ぐのがベストか。
あまり難しいアルゴリズムにして、変なバグを作り込むのもイヤですし。

ようやく中ボス（２面）

ようやく、SHOT04（NOKOGI Rider）の2面中ボスを作成できるところまで進捗。

２面のキャプチャを公開するのは初。
背景のテーマはダンジョンで。（BGMのタイトルもダンジョンだし）
面毎に一応テーマらしきものを決めて背景画像を描く方向。
・１面：いかにもシューティングっぽい感じ
・２面：ダンジョン
・３面：地球（海にしようか上級にしようか）
・４面：箱
・５面：まだ決めてない

問題は私の作画センス。
それでも、背景については外部素材を使わずに作ります。

機体類もなるべく自分で描いています。
ただし、デッサン力が追いつかない部分はDOGA頼みですが。
DOGAもなるべくなら使わない方が良いので、デッサンだけ流用させて貰って色は自分で塗り直すとか、自分で描いたパーツとDOGAのパーツを組み合わせるとかして、DOGA単体で描いた時の上手さをかき消す努力をしてます。

他人の素材を使うと、妙にツクールっぽい感じがしてツマラナイものになります。
別にツクールで作ったものがツマラナイという訳ではないです。
むしろ、ログインのSOFCOMとかは好きでしたし。

ツクールで作られたものは、デフォルト素材を使っているものが多い。
それらがどういう訳か微妙なものが多く、下手でも全部自分で作ったものを主体で使っているものの方が面白いものが多かった気がしています。「究極バカげ～む 超ステキ編」とか。

２面中ボスの作成に入る前に、リプレイデータの簡易圧縮保存をやる予定ですが。
zip圧縮でも良いのですが、コードが汚れてしまうので、独自アルゴリズムで。

ネームエントリー画面

開発中のSTG（NOKOGI Rider）では、ハイスコア保存時はネームエントリーしない仕様にしたのですが、リプレイを保存する時は、ネームエントリーする感じにしました。

で、ネームエントリー画面を作成。

こういうシステマチックな画面なら、キーボードやコントローラよりもタッチパネルの方が簡単に作れます。

名前の領域をタッチすれば直接、カーソルを移動できます。

「←」や「→」のボタンでもカーソルを移動できますが。
「カーソルのボタンなんて要らないのでは！？」

と思われた方は賢明です・・・作っている途中で気付きました。

でも、無駄なスペースが発生するのがイヤなので、残しておきます。
カーソルボタンを削除した分、別の文字（ハイフンとかアットマークとか）を入れても良かったんですがね。
ただ、「一番下の列は制御系」、「上４列は文字系」という形の方が様式的に美しいかと。

dotエフェクト改善

SHOT04（NOKOGI-Rider）では、ドットでエフェクトを入れています。
かなり古典的な手法ですが、軽いし、パレットアニメーションすれば割と綺麗なので現役です。
下図だと、真ん中あたりのショットを敵に衝突させた時の衝撃波や、自機のエンジンから噴出している燃えカスなど、使い所を挙げればキリがない程度に使っています。

この座標管理を整数から実数に変更してみたところ、かなり疎らにバラけてくれるようになり、綺麗に表示されるようになりました。実数とはいっても、floatやdoubleではなくshortで固定小数点方式ですが。（実数は処理効率が悪い上に、メモリ効率も悪いから全く使っていないです）

使い所を挙げればキリがない程度に使っていたから、修正が微妙に大変でしたが。

実機ビルド

今日はあまり時間が無いので、ここまでできたシステム周りを実機（Androidのスマホ）で動かす為にビルド。
普段、VGEのエミュレータでしか動かしてなくて、それで99%問題無い・・・
・・・と、高を括っていたら、Android固有のバグを幾らか発見。

当然のことですが、やはりシステム周りを弄った場合は、十分に実機テストをしないとマズイ。
ゲーム本編もエミュレータ（@Windows）と実機ではだいぶ感触が違うし。
もちろん、一通り完成したら実機で叩きまくる予定なんですが、完成していなくても週１ぐらいで実機用にビルドして会社の休み時間などにデバッグすべきかも・・・Android用のコンパイルは無茶苦茶遅いから面倒ですが。

NDKとSDKのビルド＋署名で１回のビルドにつき1分以上掛かるから、独自のエミュレータを設計して、それで動くゲームを作る開発環境にしないと、とてもじゃないけどゲームを作る気になれないレベルの遅さです。（ちなみに、Windows版VGE用のビルドであれば、差分コンパイルが1～2秒弱、フルビルドでも10秒前後のコンパイル時間）

単に、私が開発機に使っているマシン（Atom機）が遅すぎるだけなのかもしれませんが。

リプレイスロット=8

リプレイ機能の実装がほぼ完成。
あとは保存する時のネームエントリー処理を実装するぐらい。
ロード画面は↓こんな感じ。

リプレイの保存の仕組みはInvaderBlock2と同じ。
ゲームオーバー後にSAVE REPLAYを選択して、保存するスロットを選べばそこに保存されます。

ただ、保存できる数は、８個にしました。（InvaderBlock2は16個）
理由は、スマホの画面では16個だと細かすぎて押し難かったので。
代わりに、PRACTICEモードでは、難易度（RANK）、機種（NOKOGI-Rider）、ステージ別にハイスコア獲得時に自動保存するので、PRACTICEでの保存数は45個。

リプレイ機能に関しては、どちらかといえばゲーム本編の方はオマケ。
リプレイ機能の最大の目的は、PRACTICE用です。

しかし、Androidだと「ストレージ」という概念がLinuxと同じファイルシステムの仕組みで存在するから、ユーザ向けに「リプレイデータはxxxディレクトリに保存してますよー」的な情報開示をしておけば良い訳ですが、iPhoneだとそういった部分はどうなるのやら。まだ、iPhoneの開発環境の仕様は調べてないから、よく分かりませんが。（恐らく、iPhoneはストレージ周りがかなり弱いから、そこら辺で色々と仕様的にAndroid版と同じにできない可能性が高いと思っています）

難易度設計

本日は有給。
有意義に過ごしたかったので、ほとんど開発はせず。

プラクティス画面からリプレイ再生ができるようにした程度。
システム周りで未完成の部分は、リプレイ保存・再生画面ぐらいだろうか。
仕組みの今回はプラクティスのリプレイ再生やデモ画面（0.01から実装済み）と同じなので、大して難しいものでもないから、今日中には仕上がるかな。

という訳で、システム周りのところは概ね完成したっぽいです。
そこまでできれば、ひたすらゲーム本編部分を作り続ければ良い状態になります。

ゲーム本編部分は、２面途中あたりまで作りかけていたところでペンディング。
理由は、
①２面途中ぐらいまでできれば、システム周りの90%を完成できる
②システム周りはバグの作りこみリスクが大きい
（初期の内から完成させておき、本編を作りながら叩いた方が最終的な品質が高くなる）
③ゲーム本編の難易度調整がスランプ中
あたり。

要は現実逃避（③）で楽な作業（システム周りの実装）に逃げてる訳です・・・難易度設計は、難しい。
システム周りと違い、想定通りに作ることが難しいので。
難易度設計は、１面と５面であれば楽です。
・１面＝お披露目用
・５面＝最終防衛ラインなので（私の）限界を目指せば良い
という感じで目的がハッキリしているので。

とりあえず作ってしまい、後で鬼調整するという方法もありますが。
ただ、私の経験則ではそのやり方だと最終的なバランスが悪くなるから、今回はやらない。
第三者のテスターを確保してやったとしても多分同じ。
実際、市販品でも１面と最終面は絶妙なバランスなのに、中間ステージは微妙なものが多い。

謎スペック

前の記事で書いた集計情報の表示ですが、もちろん、カウントも同様です。

上図はデバッグ用に「GAME COUNT」の時間が有り得ない値になっていますが。

一番上の「TIME」は、ゲーム本編＋プラクティスの合計プレイ時間。

「GAME COUNT」の時間は、ゲーム本編のプレイ時間（ステージクリア画面やエンディングは含まず）。

「PRACTICE COUNT」の時間は、ステージ別の練習時間。

「GAME COUNT」と「PRACTICE COUNT」の時間表示部分は、表示位置の関係で表示上限の最大時間が9,999,999時間59分59秒が限界。

ただ、時間は非符号32bitで秒単位で保持しているので、4,294,967,295秒が上限。

つまり、約1,193,046時間が限界。

1,193,046時間ということは、日数換算すれば約49,710日、年数換算すれば約136年。

136年ぶっ続けでやり続ければカンスト・・・ですが、カンスト処理は実装せずオーバーフローで0に戻るようにしておきました。プレイ時間が136年を超える場合、136年毎にノート等に正の字を書く等で記録するなりして、お楽しみください!!

・・・純然たる謎スペックですが、こういうジョークは嫌いではないです。

ちなみに、こういう所で、「どの仕様が最適か」という事を見極める技術は結構重要。

つまり、何処までを実装（プログラム）で、何処からを運用（ノートに正の字で記録など）でカバーすべきか。

まぁ、ゲームとはほぼ関係ない事ですが。

Totalize

SHOT04で、ローカルのプレイ記録を表示する画面では、
・RANK（難易度）別
・TYPE（機種）別
にランキングやデータを表示する感じでした。

しかし、全RANKの集計、全TYPEの集計が欲しかったので追加。

RANK+TYPE別、RANKだけ集計、TYPEだけ集計、RANK+TYPE全てを集計の４パターンが可能。
Tを押せば良いだけです。（起動時のデフォルトは、RANK+TYPE両方Tの状態）

上手くなってくると、ランクはN（Ninja）だけで埋められるんでしょうけど。
ただ、こういうのは、だんだんと埋めていくのが楽しいと思うので、スコアアタックゲームでは必須だと思います。（スコアボード専用のサイトとかなら普通にできることですし）

ただ、意外とやっているものは少ない。
東方でもやってないし、CAVEシューティングでも私が知る限りではやっているものは無いです。
もしかすると、作るのが大変なのかも。
別にそれ程難しいものでもなかったけど。（それでも、作るのに２時間程度はかかりましたが）

ちなみにRANK+TYPE両方のトータルだと、データは最大144位までありますが、17位以下は切り捨て。
全表示するにはスクロールが必要なので、かなり面倒。
面倒な割りに誰も得しないと思うので却下。

どの程度、保持したものか

SHOT04（NOKOGI Rider）のローカル・スコア保存のシステム周りを実装中。
とりあえず、現時点では下図のような感じ。

画面上のRANK/TYPEで、スコアランキングを確認するRANK/TYPEを選択できます。
スコアは、RANK/TYPE別に16位まで保存。
ランキングの保存情報は、プレイ日付、スコア、到達ステージ（オールした場合はC）。
概ね東方と同じ方式だと思います。
この辺は、あまりカスタマイズ余地が無いかもしれません。
ちなみに、プレイヤのエントリ名はランキングでは表示なしの仕様。
エントリ名は、リプレイ保存でのみ設定する仕様にしました。
（ランキングは端末単位のローカル情報なんだから、設定は無意味と判断）

あと、[DETAIL]ボタンを押せば、統計情報を表示する感じにします。
統計情報は未だ仕様を決めてないのですが、
①ゲーム本編のステージ別プレイ回数 & ２面以降の到達率
②ゲーム本編のクリア回数（クリア率）
③プラクティスのプレイ時間（ステージ別）
④プラクティスのプレイ回数（ステージ別）
を表示する予定。
もちろん、①～④はRANK/TYPE別で。

そんな沢山の情報を保持したら、ディスクがパンパンになるのでは？
と思うかもしれませんが、これら全部＋＠の情報サイズは、全部で3KBいきません。
だから、この情報でディスクを切迫することは無いです。

ディスクサイズで気を遣う必要があるのはリプレイデータの方。
デモプレイのリプレイデータですら11KB（無圧縮）もあるので・・・
リプレイデータは、保存時に圧縮すべきか検討中。

Androidなら問題にならない程度なんですが、iPhoneの場合、ローカルストレージのビット単価がかなりのボッタクリ価格なので。だから、少しでもディスクサイズが小さくなるように努力する必要があります。
現に、私がiPodのアプリを選ぶ時は、ディスク容量で第一のフィルタが掛けていますし。
もちろん、Androidでも気にしない訳ではないけど、iPodよりは若干緩いです。

スコアランキング

まだ、（ローカルの）ランキングは作ってませんが、プラクティスのスコア保存などの機能を実装したりしました。

こういう機能は、別に後から作っても良いのですが、システム周りのことは先に作っておき、後付で必要なデータや要素を追加していった方が良いもの（楽しいもの）ができると思っているので、早目に実装するのが吉です。（一度リリースしてしまうと、互換性の問題が生じるから、アップデートで更新できない場合が多々あるので、初期リリースまでに必要な要素を全て詰め込む必要があります・・・そういう場合、こういうやり方＝自分で遊びながら必要なものを後付するのがベストです）

とりあえず、プラクティスモード（製品版のみ）では、RANK別×TYPE別×STAGE別にハイスコア＋そのリプレイを記録する仕様でいこうと思っています。

あとは、プレイ時間やプラクティス時間をゲーム内時間（60フレームを1秒でカウント）で記録して、プレイデータ画面（製品版のみ）で、統計データやランキングを確認できるようにするつもり。

ちなみに、ランキングはネットワーク連動ではなく、ローカルのみ。
ネットワーク系の機能は実装しません。
ただ、将来的にはネットワーク経由でSHOT04（NOKOGI-Raider）のリプレイをアップできるスコアボードのようなものを作りたいのは山々なのですが、仮に作るとしても製品とは別のアプリで作ることになります。ゲーム本編では一切のネットワーク接続をしない方向です。
これは、私の個人的な趣向なんですが、ゲームの画面遷移などがネットワーク連携したがためにモッサリするのが嫌いなので、ゲーム本体は完全ローカル指向です。だから、ネットワーク接続するのなら、専用の別アプリで作る形になります。

そういえば、スコア関連の処理を実装していて思い出したのですが、iPhoneなら、標準でGameCenter機能を利用することで、簡単に全国ランキングみたいなものをアプリで実装できるのですが、それもやりません。

CaveのiPhone版「虫姫さま」がGameCenterのスコアランキングと連動していて、始めた当初の頃は「これは、面白い！」と思ったのですが、明らかにバグかハックして出したハイスコアが、ランキング上位を独占していたので、かなり微妙。
まぁ、バグがあることそのものは（良くはないけど）問題ではありません・・・当然無い方が良いですが。
問題は、GameCenterのランキングが、バグで出したもの or 正規プレイの区別がつかないということ。
リプレイも込みで登録できるようにすれば良いのですが。
しかし、（GameCenterの仕様を調べた訳ではないから定かではないですが）そんなんに対応したら、サーバがパンパンになってしまうから、多分対応していないと思うので、仮にiPhone対応するとしても、GameCenterはやりません。

寧ろ、GameCenterへの対応は逆効果だと思ってます。
プレイヤーの８割は、ランカーではないという統計データが（私の脳内に）あり、自分のランクを過度に気にする人の割合は２割弱程度です。（８割の人は、ランクとかは別に「有っても無くても良い」と思っているものと思われます）
で、ランキング機能は、その２割弱の人が楽しむための機能なのですが、恐らく、その２割弱の人の大半は、正規のプレイでトップスコアを狙うことを目指しています。当然ながら、そういう方々は、バグプレイでランキングが荒らされることを嫌います。
つまり、２割弱の人が楽しむための機能なのに、２割弱の人の大半は（バグスコアに）ストレスを感じているので、正に誰得な機能。寧ろ、無い方が幸せになれる人の数が増えます。
そんな誰得機能が果たして要るのか？と考えれば、以下略。

マルチタッチの扱い

シングルタッチ専用のゲームでのマルチタッチの扱いについて、技術的なネタを書いておきます。
「シングルタッチ専用のゲームなのにマルチタッチ？」と思われるかもしれません。
しかし、シングルタッチ専用の場合でも、マルチタッチの扱いに関して、それなりの考慮が必要です。

例えば、下図のようにP1をタッチしている状態でP2をタッチした場合で考えます。

私が検証した環境では、P1がプライマリ、P2がセカンダリになりました。（個体差はあるかも）

そして、
(1) P1をタッチ
(2) P1のタッチを維持したまま、P2をタッチ
(3) P2のタッチを維持したまま、P1を離す
という操作をした時、(3)の瞬間、プライマリがP1→P2に変化します。

プライマリのみを拾っているシングルタッチのプログラムだと、「P1→P2のスライドを行った」という判定がされることになります。なので、ベクトル情報としてスライド量を拾っているアプリでは、直感的ではない動作をします。

例えば、「上方向にスライドした分だけジャンプをするアクションゲーム」であれば、画面下部=P1 & 画面上部=P2として、(1)～(3)の操作をすれば、スライドしていないのに大ジャンプができるという感じになります。

これを解決する処理方式として、マルチタッチ検出時は非タッチ状態と判定する処理方式が一番直感的かな？と思っています。「タッチしているのに非タッチ」というのは一見すると微妙な気がするかもしれませんが、これが一番自然な操作感覚が得られました（他の方式も色々と試したのですが）。

とりあえず、SHOT04（NOKOGI-Rider）がその処理方式で実装しているので、実際にどんな感じで動くか気になる方は、 SHOT04で遊んでみてください（・・・これが世にいうステマというヤツですかね?自分の技術紹介サイトで自分のゲームを宣伝する分には問題無いと思ってますが）。

割と、「シングルタッチのプログラムではマルチタッチの考慮は不要」と思っている人が多いと思うので、参考までに紹介しておきました（かくいう私が、NOKOGI-Riderを公開する前の初期の頃にこれにハマりました）。

ちなみに私は、AndroidSDKについて入門書の類は読んだ事が無い（英語の公式マニュアル以外は見たことがない）からよく分からないのですが、入門書とかにはこういうネタが書いてあるのかも。
要は、「ちゃんと入門書ぐらい嫁」という話なのかもしれません・・・だが、断る。
私は、入門書や参考書の類の書籍を未だ嘗て一度も読破したことが無いから、買うだけ無駄です。
リファレンス的な用途なら、公式だけで十分。
公式は英語だけだから、読むのが若干面倒ですが。

中々快調

２面の作成が中々快調です。
１匹ザコを作りました。
この調子でどんどんザコを増やしていきます。
１面の時と違って、システム面では色々と完成しているから、ゲーム本質部分を組み立てていくだけなので、１面を作っていた時よりは幾分か楽です。ただ、そのゲーム本質部分が問題なんですが。

ちなみに、SHOT値の導入により、レーザーをディスってしまわないように色々と工夫しています。
レーザーでの稼ぎ所もちゃんと作っておきたいと思っているので。
要は、レーザーを打てば弾消しができるので、弾を大量に吐く敵を作れば、そこがレーザーでの稼ぎ所になる仕様。なので、弾幕地獄を作れば割と簡単に実現できます。

とりあえず、ウィークデーに開発時間が確保できるようになったので、１日１～２匹程度のペースでザコを作って、今週末には二面の大枠を仕上げたい所。

最初の夏休みまでには３面ぐらいまでできていればベスト。
ちなみに、今年は夏休みが２回あるから、絶好の開発日和です。
夏場の開発はしんどいですが。

あと、ようやく体験版が海外でもDLされるようになってきました。
中東、米国、欧州、アジアあたりでワールドワイド且つ疎らな感じで。
ただ、VGSの一番のお得意様であるインドネシアのDL数がゼロでしたが・・・残念。
ちなみに、VGSのDL数１位は米国で、２位がインドネシアです。（日本は３位）
何故、VGSがインドネシアで好評（？）だったのかは謎。
音楽性が肌に合ったのかな？

２面を作成する前作業

本業の方が、労使協定の関係で、半強制的に時間を確保できるようになったので、開発作業を再開。
英国風に言えば、「本業が楽になら、副業を忙しくすれば良いじゃない」・・・でしょうか。
過労で倒れる前までには、SHOT04を完成させたいです。

しかし、２面を作成する作業に入る前に、色々と準備しなければいけないことがあります。
主に、ステージプラクティスの仕様を決めること。
２面以降をテストする上で必須なので。

私は、基本的に画面を描きながら仕様を考えます。
概ね仕様が纏まりつつあります。

まだ枠線などは書けてませんが、上図のような感じ。
ステージ単位でハイスコアとハイスコア取得時のリプレイを保存する仕様にします。
そして、リプレイボタンを押せば、ハイスコア取得時のリプレイを確認できる・・・という具合。
あと、画面遷移は煩わしいので、ランクと自機の選択は同一画面中でできるようにします。
リプレイはランク別には保存するとして、タイプ別に保存すべきか迷い所。
ランク別なら3×5=15パターンで済みますが、ランク＋タイプ別だと3^2×5=45パターン。
１ステージ分のリプレイなら、大したサイズにはならないと思うから、問題無い良いかな？