ソースコード検査

独立行政法人の情報処理推進機構（IPA）で、C言語用のソースコード検査ソフトを無償配布しているという情報を得たので、早速、試してみることにしました。

（本件に関するIPAのプレスリリース）
http://www.ipa.go.jp/about/press/20120508.html

Android用に販売中のSHOT04-NOKOGI RiderとInvaderBlock2の検査をしてみようかと。
これらのソフトは、Android用ですが、だいたい（９割９分ぐらいの割合で）C言語で作られています。
起動部分とか、Android特有の部分だけJavaで、残りは全部Cという感じ。
本当は、全部Cで作ることもできる仕組み（NativeActivity）もありますが、色々と不便だったので、Android特有部分については（仕方なく）Javaで書いておきました。

IPAが配布しているソースコード検査ソフトはLinux用のソフトウェアですが、VMWarePlayerで再生できるイメージ形式でも配布されていました。これなら、セットアップの手間が省けて簡単です。

しかし、無料ソフトということで結構制約が厳しい。
次のような制約があるようです。

① C 言語（ANSI C）で記述されたソースコード
② x86 アーキテクチャ向けに記述されたソースコード
③ 100ファイル以下で構成されるプログラムのソースコード
④ 構造体を使用していないソースコード
⑤ goto文を使用していないソースコード

もともと、iPhone（※Objective-C）への移植もソースコード修正をせずにできることを目指して設計した（要するに、C++言語も使わないようにしていた）ので、①は余裕でクリアです。あと、x86ではなくARM用ですが、中核部分はWindowsと完全にソースコード互換がある形にしたので、②も問題ありません。あと、ファイル数が多いと色々と面倒だから、③もクリアしています。

しかし、④の構造体がダメというのは、無理・・・
（Cですが）データ構造についてはオブジェクト指向で設計しているので、構造体だらけです。

あと、⑤のgotoも沢山使っています。
当然ながらスパゲッティではないですが、gotoを使うことで、異常系処理を簡潔に記述するのに役立つので、プロの開発現場でも普通に使います。むしろ、頑なにgotoを使わない人が作ったプログラムの方が、メモリリークとかのバグを作り込みやすい傾向があったりします。

情報系の大学や専門学校なんかでは、軽々しく「gotoはダメ！」みたいな教え方をしている所がありますが、それは正確ではありません。（正しくは、「gotoは構造化プログラミングを保った上で適切に使え！」です）

という訳で、残念ながら利用は断念します。

④と⑤がダメってことは、商用のプログラムでは、ほぼ使い物になりませんね。
こういうツールで商売している業者さんも居るので、そういう方面への配慮かな？
IPAのホームページでの紹介のノリも「学習用途！」みたいな感じですし。

---

波形メモリ音源（VGS）

拙作「SHOT04 - NOKOGI Rider」で採用している波形メモリ音源VGSについて、解説します。
まず、VGSという音源は、物理的には実在しません。
私の脳内で設計し、それをソフトウェア・エミュレーションする方式で、「SHOT04 - NOKOGI Rider」に搭載しました。

基本スペック：
・周波数: 22050Hz固定
・ビットレート: 16bit固定
・チャネル: モノラル固定
・同時発音: 6声
・音色数: 4（三角波、ノコギリ波、矩形波、ノイズ）
・声部別エンベロープ
・ピッチダウン（※ピッチアップは不要だったので未実装）
・声部別ボリューム
・マスターボリューム
・自動マスターボリューム制御（主にフェードアウト用途）

ちなみに、分解率＝周波数という方式を採用。つまり、22050fpsです。
厳密には、処理周期は100ms間隔（10fps）ですが、オペレーションは22050fpsのフレーム間隔で出せます。
つまり、音の長さの最小は、だいたい45μ秒（1μ秒=100万分の1秒）程度の間隔になります。
テンポ120の場合、32768分音符がだいたい61μ秒になるので、「テンポ120の65536分音符よりちょっと長く、32768分音符よりちょっと短い」という感じです。

・・・少し分かり難いですね。
もう少し分かり易く例えるなら、報道によると東京証券取引所では、次期売買システムの取引性能を「1件あたり1ms以下にする（1秒間に1000件以上の取引ができるようにする）」らしいですが、そのシステムで「１回の取引をしている間に22回ぐらい音符を鳴らすことができる」という感じです。

一見すると誰得機能ですが、かなり重要な機能です。東証の方は誰が得するのか理解に苦しみますが。
この分解性能の粒度によって、音楽の表現性能が劇的に変わります。
この辺りのことは、音源本体（ハードウェア=エミュレータ）ではなく音源ドライバの役回りですが。

もちろん、音源ドライバも自作しました。
音源ドライバ仕様は、固定長のオペレーションで発音指示や待機指示をしたりする感じです。
昔のアーケードゲームとかだと、Z80で組むのが一般的。

VGSの場合、「何処からがハード仕様で、何処からがドライバ仕様なのか」がかなり曖昧ですが。
一応、一般的な区分は、「オペレーションを送るプログラム」がドライバで、「オペレーションを処理する部分（プログラム）」がハードウェア（エミュレータ）という風になります。
VGSの場合、ハードも論理的な存在だから、境界線が曖昧になります。
全てが論理的であれば、境界線の存在自体、ナンセンスだったりします。

そして、オペレーションの集まりが曲データになります。
ただ、オペレーションをずらずら並べて曲データを作るのが面倒なので、独自のMMLコンパイラ（MMLで書いたものをオペレーション集合に変換するプログラム）も作りました。

例えば、「SHOT04 - NOKOGI Rider」の「STAGE 1」のMMLは以下のような感じ。

$Brass \s600 \e22050 @1 %80 $Harp \s1000 \e1500 @0 %50 $Bass \s10   \e200 @2 %50 $Sq \s600 \e22050 @2 %75 $Sq2 \s6000 \e22050 @1 %80 $Hue \s5000 \e22050 @2 %80 $Osi \s22050 \e10000 @2 %80 $Ou \s500 \e5000 @1 %50 $B  \s10 \e1000 p-128 @0 %10 v35 o3 $S  \s1  \e1000 p-128 @3 %20 v20 o4 #----------------------------------------------------------------------------- # Bass #----------------------------------------------------------------------------- Ch0 t172 m8 v12 (Bass) o3l16 | Ch0 d8ddd8ddd8ddd8dd c8ccc8ccc8ccc8cc < b-8b-b-b-8b-b-b-8b-b-b-8b-b- a8aaa8aa aa>a<a>g<a>f<a Ch0 l8 gggg gggg dddd dde-f gggg gggg ggrg16g16 gggg Ch0 gggg gggg ff>f<f ff>f<f gg>g<g g16g16g>g<g g16g16g>g<g l16 <ffggaab-b- Ch0 > crcccrcccrcccrcc drdddrdddrdddrdd grgggrgggrgggrgg frfffrfffrfffrff Ch0 crcccrcccrcccrcc grgggrgggrgggrgg <g4.a4.b-4^2 l8 gg>g<g Ch0 > l16 c8c4ccc8c8>c8<cc < g8g4ggg8g8>g8<gg f8f4fff8f8>f8<f8 > d8d8>d8<ddd8d8>d8<dd Ch0 c8cc>c8<ccc8cc>c8<cc d8dd>d8<dd dd>d<d>c<db-d grgggrgggrgggrgg d8d4ddd4f+4 Ch0 l8 > dd>d<d4d>d<d < gg>g<g4g>g<g > cc>c<c4c>c<c dd>d<dcc>c<c Ch0 dd4d16d16dd>d<d cc>c<c cc>c<c < aa>a<a4a>a<a aa>a<a4 a>a<a Ch0 l8 > dd>d<d4d>d<d < gg>g<g4g>g<g > cc>c<c4c>c<c dd>d<dcc>c<c Ch0 dd>d<d4d>d<d < aa>a<a4a>a<a > dd>d<d4d>d<d dd>d<d4ddd #----------------------------------------------------------------------------- # Melody #----------------------------------------------------------------------------- $Me1 r1r1r1r1 d2rdc<b- a2f4a4 g1^2r2 > d2rdc<b- >c2<a4>f4 d1^2r2 $Me2 e-2re-fg f2d4f4 g2rgab- a2g4f4 g2>c2< b-4a4g4a4 b-4.>c4.d4^2.r4 $Me3 (Sq) < e-2re-dc d2<b-2> c2rc<b-a g4b->d8^2 e-2re-fg f2d2 b-2rb-ag f+4a>c4.d4 $Me4 < a4gf8^2 b-4ag8^2 e4fg4efg a4.g16f16g4e4 d2ref4 g2rg>c4< a1^2.r4 $Me5 a4gf8^2 b-4ag8^2 e4fg4efg a4.g16f16g4e4 d2rdefec4<a4.>e4 d2.^16 l32 ef ga b->c d1 Ch1 v13 (Brass) \s3000 o5l8  (Me1)(Me2)  (Me3) (Brass) v-- (Me4)(Me5) v++ Ch2 v12 (Brass) \s6000 o4l8 <(Me1)(Me2)> (Me3) (Hue) > v- (Me4)(Me5)< v+ #----------------------------------------------------------------------------- # Side-A #----------------------------------------------------------------------------- Ch3 v10(Ou)o4l16 Ch3 a>dfa<  v- a>dfa<  v- a>dfa<  v- a>dfa<  v+++ Ch3 g>ce-g< v- g>ce-g< v- g>ce-g< v- g>ce-g< v+++ Ch3 fb->df< v- fb->df< v- fb->df< v- fb->df< v+++ Ch3 < fa>cf v- a>cfa v- fc<af v- c<afc v+++ Ch3  grgr8.gggrgr8.gr Ch3   drdr8.dddrdr8.dr Ch3 (Sq) \s1000 > g4.fe-d2 <  @1 b-2g4b-4 Ch3 @2l8 b-2rb->cd f2rfa>c Ch3 @1l16 \s50 g>d<db-<b->g<g>d<db-<b->g<g>d<db- \s1000 Ch3 @2g4.fga4b-4 Ch3 l2>ce-d<ab->dc1 <<g>cdg b-4.>c4.d4^2.r4 Ch3 (Ou)l8 e->e-ce-<g>e-ce- < d>d<b->d<g>d<b->d< c>c<a>c<f>c<a>c< gb->dg<gb->dg Ch3 l16 c>c<g>c<e->c<g>c< c>c<g>c<e->c<g>c< Ch3 < a>afadafa<a>afadafa< Ch3 b->b-gb-db-gb-< b->b-gb-db-gb-< Ch3 < df+a>c df+a>c df+a>c df+a>c #----------------------------------------------------------------------------- # Side-B #----------------------------------------------------------------------------- Ch4 v12\s100\e1000@2%65o5l1 # dc<b-a Ch4 l32 v2  d>d< v+ d>d< v+ d>d< v+ d>d< d>d< v+ d>d< v+ d>d< v+ d>d< v+ d>d< v- d>d< v- d>d< v- d>d< d>d< v- d>d< v- d>d< v- d>d< Ch4 l32 v2  c>c< v+ c>c< v+ c>c< v+ c>c< c>c< v+ c>c< v+ c>c< v+ c>c< v+ c>c< v- c>c< v- c>c< v- c>c< c>c< v- c>c< v- c>c< v- c>c< Ch4 l32 v2< b->b-< v+ b->b-< v+ b->b-< v+ b->b-< b->b-< v+ b->b-< v+ b->b-< v+ b->b-< v+ b->b-< v- b->b-< v- b->b-< v- b->b-< b->b-< v- b->b-< v- b->b-< v- b->b-< Ch4 l32 v2  a>a< v+ a>a< v+ a>a< v+ a>a< a>a< v+ a>a< v+ a>a< v+ a>a< v+ a>a< v- a>a< v- a>a< v- a>a< a>a< v- a>a< v- a>a< v- a>a< Ch4 v9(Sq)l8 \s4000 v9 b-2rb-ag f2rfdf g1 d4.e-16f16g4b-4 Ch4 g2rgab- >c2.f4d1^2r2 l16 Ch4 \s1000 c<b->c4r8c2 Ch4 <a4.b->cd4f4 Ch4 g4.fe-d4<b-4 f2r2 Ch4 < g2>c2d2g2 >d2.^16l32 e-fgab->c d1 l8 Ch4 < v-- r32 e-2re-dc d2<b-2> c2rc<b-a g4b->d8^2 e-2re-fg f2d2 b-2rb-ag f+4a>c4.d8.^32 v++ #----------------------------------------------------------------------------- # Side-A+B(C part) #----------------------------------------------------------------------------- $SI1 l8(Ou) dfa>d< dfa>d< dgb->d< dgb->d< ceg>c< ceg>c< <a>dfagec<g a>afadafa c>c<g>c<e>c<g>c< dfa>d< dfa>d< dfa>d< dfa>d< $SI2        dfa>d< dfa>d< dgb->d< dgb->d< ceg>c< ceg>c< <a>dfagec<g d>d<a>d<f>d<a>d< c>c<a>c<e>c<a>c< dfa>d<dfa>d< dfa>dfa>d Ch3 o4    v++ (SI1) (SI2) f8 v-- Ch4 o4    r16 (SI1) (SI2) f16 #----------------------------------------------------------------------------- # Drums #----------------------------------------------------------------------------- Ch5 l4 (B) cccc cccc cccc ccc8 (S)c8c8c16c16 Ch5 l16 (B) c4 (S)c8.(B)c c8cc (S)c4 Ch5 l16 (B) c4 (S)c8.(B)c c8cc (S)c8c8 Ch5 l16 (B) c4 (S)c8.(B)c c8cc (S)c4 Ch5 l16 (B) c4 (S)c8.(B)c c8cc (S)cccc Ch5 l16 (B) c4 (S)c8.(B)c c8cc (S)c4 Ch5 l16 (B) c4 (S)c8.(B)c c8cc (S)c8c8 Ch5 l16 (B) c4 (S)c8.(B)c c8cc (S)c4 Ch5 l16 (B) c8 (S)ff (B) c8 (S)e-e- (B) c8 (S)d-d- (B) c8 (S)<bb> Ch5 l16 (B) c4 (S)c8.(B)c c8cc (S)c4 Ch5 l16 (B) c4 (S)c8.(B)c c8cc (S)c8c8 Ch5 l16 (B) c4 (S)c8.(B)c c8cc (S)c4 Ch5 l16 (B) c4 (S)c8.(B)c c8cc (S)cccc Ch5 (B) c2c2 (S)c8(B)c8c8 (S)c8(B)c8c8 (S)c8(B)c8 Ch5 (S) f4.d4.<b-4> (B)r2c8(S)c8c8cc Ch5 l16 (B) c4 (S)c8.(B)c c8cc (S)c4 Ch5 l16 (B) c4 (S)c8.(B)c c8cc (S)c8c8 Ch5 l16 (B) c4 (S)c8.(B)c c8cc (S)c4 Ch5 l16 (B) c4 (S)c8.(B)c c8cc (S)cccc Ch5 l8 (B)c(S)c(B)c(S)c(B)c(S)c(B)c(S)c Ch5 l8 (B)c(S)c16c16(B)c(S)c(B)c(S)c16c16(B)c(S)c Ch5 l8 (B)c(S)c(B)c(S)c(B)c(S)c(B)c(S)c Ch5 l16 (B)c8(S)c8c8cc cccc cccc Ch5 l8(B) cc(S)c(B)c4c(S)c(B)c cc(S)c(B)c4c(S)c(B)c cc(S)c(B)c4c(S)c(B)c cc(S)c(B)c4c(S)cc Ch5 l8(B) cc(S)c(B)c4c(S)c(B)c cc(S)c(B)c4c(S)c(B)c cc(S)c(B)c4c(S)c(B)c cc(S)c(B)c4(S)ccc Ch5 l8(B) cc(S)c(B)c4c(S)c(B)c cc(S)c(B)c4c(S)c(B)c cc(S)c(B)c4c(S)c(B)c cc(S)c(B)c4c(S)cc Ch5 l8(B) cc(S)c(B)c4c(S)c(B)c cc(S)c(B)c4c(S)c(B)c cc(S)c(B)c4c(S)c(B)c cc(S)c(B)c (S)cccc16c16

特殊な命令は、主にエンベロープ関連の以下３つぐらいで、あとは標準的な仕様だと思います。
・「\s」スタート・エンベロープ（音を鳴らし始めてからMAX音量になるまでの時間）
・「\e」エンド・エンベロープ（音を止めてから音量0に減るまでの時間）
・「%」キーオフ・タイミング（%50で4分音符を鳴らせば、8分のタイミングでキーオフ指令を出して、そこからエンド・エンベロープによる減衰が始まります）

音色数は少ないのですが、エンベロープさえ弄れれば表現の幅は無限大です。
だから、音色数はもっとも基本的な三角波、ノコギリ波、矩形波（＋ノイズ）だけでも、割と困りません。
フレキシブルな波形変化については、波形メモリ音源やPSG音源の単音では不可能な部分（FM音源じゃないとできない特徴）ですが。一応、複数チャネルを使って音を重ねれば、多少の変化は得られます。

ただし、あまり重ねすぎると汚くなりますが。
絵の具と同じです。
だから、同時発生数を敢えて6声に制限しました。
6声ぐらいが一番キレイ。

---

体験版によるマーケティング成果

先日、めでたくSHOT04 - NOKOGI Riderの製品版をリリースできた訳ですが、今回は、開発途中（１面完成時）に即座にソレを体験版（Trial版）として無償公開して、ユーザーさんの反応を伺いながら製品開発をする・・・というスタイルで開発を進めてきました。

こういうスタイルで開発をした理由は、開発と同時にマーケティング（広報）活動をするため。

広報は苦手ですが、やらないことには製品版を売ることができません。

なお、今回の体験版公開→製品版リリースまでのタイムラインは概ね以下のような感じです。

(1) 5月初頭に体験版初期バージョン(Ver0.01）をリリース

(2) 5月中旬にユーザーからの要望対応で体験版のバージョンアップ（Ver0.02）

(3) 8月25日に製品版リリースと同時に体験版をLite版相当にバージョンアップ（Ver1.04）

体験版の有効なインストール端末数の遷移は以下のようになりました。

・オレンジ色の線 = Ver0.01

・緑色の線 = Ver0.02

・青色の点 = Ver1.04（Lite版）

体験版に関して、その他に実施した広報活動といえば、「開発状況をブログに書き続ける」ぐらい。

それでも、結構な数をインストールしてもらうことができました。（約4ヶ月の累計DL数は980件ぐらい）

ただ、公開から一ヶ月ちょっと経過後から、右肩下がりになり始めてしまいましたが。

でも、製品版の公開初日まで、200端末程度、インストールしてくれていた方々が居て、そこから一気に60件ぐらい（=有効インストール端末数の3割りぐらい）、Lite版をDLしていただけました。

この60件の中から、何件製品版の購入まで進んで貰えるかが、一番重要な点です。

あと、この60件（今週中にはもうちょっと増えると思います）の中から想定率を超える売り上げがあれば、例えば広告に出したりなど、お金をかけて本格的な広報活動をすればそれなりの対価が得られると判断できますし、想定率を下回っていたら「お金をかけて広報活動をしても無駄」と判断できます。つまり、ちゃんと売れるかどうかを見極めるのに十分程度の試金石を得ることが出来たことが、この広報活動の最大の成果です。

有効インストール端末数が200/1000（約20%）という状況から、既に悲観ムードですが...orz

InvaderBlock2の時のように、Windows版から流れて買ってくれる方については、期待しています。

Windows版（Lite版）は、今週中頃にはVectorから配布開始されると思います。

公開しました

SHOT04 - NOKOGI Riderの製品版とLite版を公開する手続きをとりました。
いつ公開されるかは分かりませんが、その内、公開されると思います。
そういえば、Googleが何か審査をするようなことを言っていたので、若干時間が掛かるかも。

今回は、かなりタフな開発でした。
とりあえず、完成に至るまでの経緯を振り返ってみます。


2011年3月 - SHOT03完成
SHOT03が完成した後、宣伝用に載せたフリーゲームのDLサイトで「洞窟物語」を見つけて遊んでハマり、「ARPGでも作ってみようか」という軽いノリでマップエディタを作り始めました。

マップエディタは、たぶん、１ヶ月ぐらいで完成。
画面は↓こんな感じ。
主な仕様は、
・３層のレイヤー
・チップ毎に可変サイズの当たり判定を入れれる
・自動海岸線機能あり
・イベント配置機能あり

結局、ARPGは作らなかったけど。
ただ、SHOT04のステージエディタとして役に立ちました。
イベント配置機能以外は誰得状態でしたが。
（自動海岸線とか、作るのが結構大変だったのに）


2011年4月～8月 - 本業多忙
本業が恐ろしく多忙で記憶が定かではありません。


2011年9月～2012年1月 - 作曲
洞窟物語を知ったお陰で、ピストンコラージュの存在を知り、作曲しまくりました。
一応、ARPG用のBGMを作る名目で。
そのARPGのメインテーマ曲が↓コレ。
http://www.k2.dion.ne.jp/~ysuzuki/sample2.mp3

上記URLの曲データは、厳密にはピスコラで作ったものではなく、VGSへ移植したものです。
ちなみに、ピスコラで最初に作った曲が、SHOT04の２面で使っているBGM。
１面のBGMは、SHOT03のアレンジ（２面と４面を組み合わせた感じ）。
SHOT04の３面と５面の曲は、隠しモチーフとして上記URLの曲の旋律を使っています。
４面の曲は、ピスコラの曲投稿サイトでやってたコンテストに応募したりしました。
結果は入選ならず。（５位ぐらいだったと思います）

ピスコラのお陰で、「私もオリジナルの波形メモリ音源を作りたい！」と思い、ほぼ知識ゼロの状態から音の勉強を始め、その結果、VGS（Video Game Sound）が生まれました。まぁ、もともと自作ゲーム用のソフトシンセを作りたい欲求はあったのですが、敷居が高そうだと思っていました。

勉強してみると、音の仕組みというのはもの凄く簡単でした。
これなら、誰でも簡単に自作のサウンドエミュレータを作れると思います。
なのに、洞窟物語ぐらいしかそれらしいことをやっていないのが不思議。
「波形メモリ音源エミュレータの作り方 ～ ゲーム音源を作ろう」みたいな本を出せば売れますかね？
狙いどころがマニアックすぎるかな？
スマホ用のゲームの場合、容量の大きさ（を少なくすること）がかなり重要なので、ニーズはあると思いますが。


2012年2月～3月 - Androidを触り始める
この頃もまだ仕事がかなり忙しく、自分がゲーム開発をしていることは完全に過去のものになってました。
ただ、ふとした思い付きでAndroidタブレットを購入し、開発環境を揃えて開発を始めました。
で、サクッとInvaderBlock2を開発。

InvaderBlock2はタダで配っても良かったのですが、試したいことがあったので有償にしました。

試したいことというのは、「本当に売れるのか？」ということ。
案の定、マーケットに載せただけでは売れません。
しかし、Windows版を無料でVectorに載せてみたところ、数本ですが売れました。

正直驚きました。
たった一本でも「売れた」という事実に。
そこで、「ちゃんとしたモノを作れば、そこそこ稼げるかも」と思い、欲望と共にSHOT04プロジェクトを始動。

～以下、中略（SHOT04プロジェクトでやっていたことは、ブログにだいたい書いてあるので割愛）～

2012年8月
無事完成。 ← 今ココ

今のところ、次回作の予定は未定です。
とりあえず、SHOT04の拡販活動をしつつ、次の構想を練ります。

公開準備中

SHOT04を公開する準備がほぼ整いました。
あとは、公開ボタンを押せば公開できると思います。
中々押せない・・・

とりあえず、最後の点検をもうちょっとやっておこうかな。
どうせ、公開してもライト版のVUPをしないと直ぐには売れないとは思いますが、万が一、売れてしまったら即座に差し替えるのは申し訳ない。

やっぱり、最初に公開するときが一番躊躇います。
「本当にこれで良いのか？」とか思ったり、
「しょっぱいバグは残ってないような？」とか思ったり、
「とりあえず、TARI TARIを観終わってから公開しようか」とか思ったり。

開発期間

SHOT04の最終リリースの候補版を作成。
まだ、リリースはしません。

長い道のりでした。
３月ぐらいからSHOT04のコードを書き始めたので半年程度？
一応、音楽については去年夏頃から作り貯めていましたが。
なので、作曲期間を含めれば１年ぐらい？

10曲（内2.5曲はSHOT03から流用）作るのに半年・・・ということは流石に無いですが。
そもそも、音楽については当初、ARPG用に作っていたので。
村っぽい感じの曲とか教会っぽい感じの曲など、「STG？」な没曲が沢山あります。

あとは、Android用のプログラミングを勉強するためにInvaderBlock2を作っていた期間が1ヶ月程度。
なので、厳密には１年丸まる作り続けていた訳ではないですが、だいたい１年。
次回作はInvaderBlock2みたいな一瞬で作れるようなアクションゲームにしたいところ。
やはり、大作を作るのはしんどい。

リリース時期について

そろそろ良い感じに煮詰まってきました。

再来週（9/1）あたりにリリースする腹で進めてきてましたが、予定が入ってしまい難しそうなので、今週末か来週初頭（日曜日）あたりに見切り発射的にリリースするかもしれません。シューティングだけに。やはり、一通り形が完成してしまっていると、早く公開したい欲が出てくるので、ゲームを作る場合、形を完成し切る前に調整し尽くすやり方が私には合っている気がします。

なお、一度リリースした製品については、バグフィックス以外の修正はしない方針（InvaderBlock2は例外的にチョコチョコ手を入れてしまいましたが...）なので、早期リリースは自らの首を絞める結果にもなり得るから、慎重にいきたいのは山々。しかし、鉄は暑い時期に叩けということで、８月中のリリースがベストなんじゃないかと思ったり、思わなかったり。

ところで、このSHOT04ですが、出来上がってみると（まだ一応調整中だけど）シューティングゲームとしては、オーソドックス過ぎるぐらいオーソドックスなものになりました。画面がレトロで音楽もレトロだから尚更。ただ、入力デバイス＝タッチパネルという前提で最大限の操作性を追及したものにしたので、割とゲーム性としては新しい気がしています。

すでにタッチパネル「対応」のシューティングはそこそこ有ります。怒首領蜂とか。

タッチパネルとシューティングというのは、かなり相性が良いと思います。

ただ、ソフトボタンを一切排除したものというのは、殆ど無い気がします。

もちろん、実験レベルのものであれば幾らかありましたが、それなりのクオリティのものは見当たりません。それなりのクオリティのあるものは、何かしらのソフトボタン（例えばボムボタンとか、カーソルとか）があるものが大半・・・というのが、AndroidやiPhone用のSTG群を見て、私が感じた傾向でした。

もちろん、それでも面白いものは面白いのです。怒首領蜂とか。

ですが、怒首領蜂ですら、微妙な違和感がありました。

タッチパネル前提でゲームを設計する以上、ソフトボタンという入力インタフェースはオブソリートにしなければいけない・・・と直感的に思っていたので、それが違和感の原因じゃないかと推測。そこで、SHOT04で「完全にタッチパネル特化」したインタフェース仕様で設計したゲームを作ってみた訳です。

そして、その試みは概ね成功したんじゃないかと思っています。ただし、Windows（マウス）と同じ仕様にしたかったので、マルチタッチを活かしきれて居ない点が若干片手落ちな気もしますが。私としては合格点だと思っています。それが世間に受け入れられるかどうかは別として。

もちろん、売れれば嬉しいですが、私が楽しめるアクションゲームがようやくスマホでできるようになったということに概ね満足したので、さっさとリリースしてしまいたいという心境になりました。

extend

extendの配分を調整中。
もともと、初期残機が３機で５回（最大残機数は８）という方向でしたが、
①２面の中ボス撃破時
②４面の中ボス撃破時
③100万点到達時
④300万点到達時
⑤600万点到達時
⑥1,000万点到達時
⑦2,000万点到達時
⑧3,000万点到達時
と、ちょっと増やす方向で。
あふれた場合は、1upせず得点が入る＆オールクリア時に残機ボーナスは無し。
という仕様でしばらく遊んでみます。

ガレッガやバトライダーのように、自滅をして有利になる要素は入れない方向で。
個人的にそういうルールだとやる気が半減してしまうので、そうならないようにミスによるランク低下という要素は入れていません。そもそも、SHOT04の場合、意図的に初期で選択するランク以外にランク変動要素を入れないようにしました。（個人的に「ランクを調整する」という戦略が好きではなかったりするので）

オーラ打ち

至近距離でショットを当てると、オーラが出てくる感じにしてみました。

近ければ近いほど、オーラ量が多くなり、オーラの量が多いと打ち込み点が高くなる感じ。
リリースが近い今の段階で新しい稼ぎフューチャを実装するのはあまりよろしくないです。
こうやってバランスが崩壊していく・・・もちろん、バランスが崩壊しないように調整しますが。
個人的にシューティングは至近距離で打ち込んだ時にメリットがあった方が爽快感がある気がします。
だから、今の段階でも無理して入れておくことにしました。

調整

SHOT04を順調に調整中。
製品版（Android版）を９月中（なるべく早く）にリリースできる筈。

会社のあまりアクションゲームが得意で無い人にBeginnerをやってもらったところ、初回プレイで２面に行けたとのことだったので、なかなか良い難度だと思います。ただ、その後、数回やったものの１面を越せなかったとか。

レーザーの貯め時間がもうちょっと短ければ・・・とのことだったので、Beginnerモードに限り、他（Soldier,Ninja）よりも1.5倍早く溜まるようにしておきました。あと、レーザーが強すぎたと思い、ミス後の無敵時間中はレーザーを貯めれない仕様にしていましたが、これは無敵時間中でも貯めれる仕様に戻してみたりしました。

レーザーがチート過ぎるので、弱体化する処置をいれるべきかと思われたのですが、その辺りはちょっと考え直します。レーザーを使うデメリットは稼ぎ（スコア）に限定する方向で。
・攻略優先時はがんがんレーザーを撃つ
・スコア稼ぎをする時は極力レーザーを撃たない
という分かり易い図式にします。

調整中・・・

SHOT04のBeginnerモードを調整していて、通しプレイでちょうどラスボス戦の第二形態になったところで地震（震度２ぐらい？）があって、「はて、そんな演出は入れた筈はないが？」と冷静に考えていました。あまり、慣れすぎるのも良くない。

BeginnerとSoldierは、軽くしか弄ってませんが、結構良い感じになりました。
あとは、Ninja。
私がNinjaをクリアするまで、調整は続きます。
ここからが本当の地獄だ・・・

ところで、会社でSDカードでapkを配ろうとしたら、大抵のAndroid端末はSDカードを入れる所がバッテリーを外したところにあり、取り外しが結構面倒だということが判明。私の端末（MotorolaのRAZR）の場合、普通に側面のところについていますが。

たぶん、コンピュータに詳しくない人は、アンマウントせずにSDカードを取り外したりするのかも。
それで、「データが壊れた！」とか騒いがれるリスクよりも不便さの方を選んだ？。
・・・が、折角iPhoneよりも優れている特長を不便にしてしまうのは惜し過ぎる気がします。
もちろん、コンピュータリテラシーが無い人でも安全に使えるようにすることは重要です。
しかし、その為にコンピュータリテラシーが有る人にとって不便なものにしてしまうのはNGです。
両者を共存できる形にすべきです。
手段が無い訳ではありません。
例えば、UNIXのCDドライブのように、SDカードをアンマウントしないと抜けないようにするとか、考えれば幾らでも方法は有る筈。多少コストは掛かると思いますが、自由にリムーバブルメディアを使えるのがAndroidの最大の利点（＆iPhoneの最大の欠点）なんだから、iPhoneからシェアを奪うのなら、その部分をケチってはいけないと思います。

調整

SHOT04のライト版を作成する作業を進めておきました。
あと、エンディングやらを作ったりして、とりあえず形だけは仕上がった感じです。
残るは最終調整のみ。

ちなみに、チュートリアルというかHow to playは、Demonstrationを見れば分かる程度の内容しかなかったので削る方向で。細かいルールの説明は、日本語と英語でWeb＋マーケットの説明文でアップすることにしました。（そろそろ、情報処理の勉強をしないとマズイ感じだから、８月中にはマスターアップしたいので、作り込みは避けたい心境）

なお、ライト版は製品版リリースとほぼ同時にバージョンアップします。
あと、Windowsでもライト版をビルドするようにしておきました。
Android版の製品版をリリース後にWindows版のライト版もリリースする予定。
Windows版の製品版は主に販路の調整中。（DLマーケットあたりが妥当な線です）
で、結局今日はそういった作業に追われてしまい、肝心なゲーム本編の調整が進まず・・・
調整は明日から会社で休み時間などにスマホを使ってやる予定。とりあえず、APKをSDカードで持っていき、Androidを持っていてゲーム好きな感じの人にテスタになってもらいます。

調整目標は、
・Beginner = 私がノーミスでオールできる程度
・Soldier = 私がほどよくオールできる程度
・Ninja = 私がギリギリ、オールできる程度
まだまだ遠い。。。

カンストはしない・・・はず

とりあえず、SHOT04のラスボスが完成。
第三形態を作るかどうかは、調整の状況を見て決めようと思います。
たぶん、調整すると難易度は落ちる方向になる筈なので、「これでは物足りない！」という難易度だった場合に第三形態を入れます。「もう十分です＞＜」という場合、入れない方向で。（現時点で結構な鬼畜難度なので、後者に倒れる可能性が高そう）

で、この状況でとりあえず「ノーミスでオールした場合、どのぐらいのスコアが入るのか？」という素朴な疑問があったので、無敵フラグを立てた状態で最高難度をノーミスでオールしてみました。

１億５～６千万ちょいぐらいのようです。
理論値（もっとも稼げるパターン）でクリアしたとしても、２億ぐらいですかね？
ちなみにカンストは999,999,990点。
なので、どんな変態シューターがプレイしたとしても、カンストすることは無いと思います。
現時点の難易度で普通にプレイした場合の私のベストスコアは2千万弱ぐらい。
全国一レベルの方の場合でも5千万前後。

さて、これから鬼調整をするか・・・
調整というのは、ひたすらプレイして難度を弄る作業。
遊び要素が大きいので、あまり苦にはなりませんが、時間が掛かる作業です。
基本的に、Ninja以外はどんどん緩くする方向で調整する方向。

ちなみに、SHOT03の時の調整に要した時間は100時間前後。
SHOT04は、現時点ですでに100時間ぐらい調整しています。。。
難易度を３種類にしたことに加えて、機種を３機種にしたことが色々と痛い。。。
「機種は２種類で良かったんじゃない？」と、今更思っていたりします。

生産状況（18-Aug）

SHOT04の現時点（５面ボスの第２形態を３～５割ぐらい作成完了したところ）の生産ステップ数を取得。

実行行数がほぼ１６ｋｓというところ。（8/4の前回の生産状況から＋３ｋｓ増加）
まだ、エンディングとか、チュートリアルとか、調整とかでワサワサと増えそうな感じなので、完成時点で２０ｋｓぐらいになるかも。

以下、蛇足

ちなみに、仕事でプログラムを作る場合、ステップ数を見積もり値にしている所が意外と多くあるようですが、ステップ数の見積もり値なんて全然アテにならないのにやる意味あるんですかね？私が仮に、想定規模を計上する必要に迫られた場合、とりあえずFP法（私の場合、画面単位ではなく機能単位で算出する方が精度が高い）なりで何かしらの根拠のある数字を出しますが、だいたい以下のような要因でその数字はフェーズとともに上下します。
①「この機能とこの機能は共通化できる」（機能レベルの共通化見落とし）
②「この機能はｘ機能とｙ機能に分割しなきゃダメだ」（機能レベルの分割漏れ）
③「この機能が必要だった」（機能レベルの実装漏れ）
④「この機能は要らなかった」（機能レベルの冗長実装）
そして、より下流フェーズに進むと①～④の「機能」が「関数」とかの細かい単位に変わります。まぁ、下流フェーズでも機能レベルの設計ミス（＝すり抜け不良）がある程度残存するものですが。一般的に、見積もり値の上下幅は、上流フェーズの設計ミスほど広く、下流フェーズの設計ミスであれば狭くなります。自社開発なら、それでも大して問題は無いと思います。問題は、他社に請負契約で発注するケース。請負契約の場合、発注時点で発注に掛かる費用（予算）を決めますが、プログラムが完成していない時点（コーディング前）の場合、幾ら掛かるのか客観的に分かり難いため、適正価格が発注時点で分かりません。だから、かなりアヤフヤな値であることを承知で想定規模（想定される画面数やプログラムのステップ数）なんかを指標にしている企業がたくさん居る訳です。個人的には、請負契約が妥当なプロセスは、テスト工程（※定性的な項目が多い統合テストなどを除く）ぐらいだと思います。請負契約で上手くやる（見積もりと実績の乖離を減らす）のに有用な開発手法は、経験則ではスパイラルモデルの開発ぐらいです。要は、見積もりと実績の乖離を減らすには、すり抜け不良を少なくすれば良い訳で、それをやるのに一番良い手段は、開発サイクルを小さく分割することだけだと思っています。学問レベルでは色々な手法が考えられているようですが、スパイラル以外の実用レベルで使い物になる手法は未だ見たことがありません。ただし、スパイラルだとそれを第三者が管理するのは無理に等しいから、開発作業とマネジメント作業を両立できるエンジニア以外できないこと（＝要員確保が困難なこと）がネック。そして、そういうエンジニアは得てして単価が高いから、予算オーバーになり易いという落とし穴があります。そもそも、スパイラルで妥当な程度の規模にサイクルを分断すると、発注のオーバヘッド（恐らく裁断したサイクル単位で発注する→妥当な規模に裁断すると契約がポコポコ増える→大変になる）でパフォーマンスが落ちるような気もするので、結局のところ「コーディングまで委任契約がベスト」だと思っています。

要は、「コーディング＝定量的な作業」という風潮をなんとかする必要があるんじゃないかと。

開発状況（17-Aug）

ネット環境がスマホしか無いところで１週間弱過ごし、今帰ってきました。
ポータブルな開発環境を整えたので、そういう所の方が捗るのかもしれません。
温泉宿とかで１週間ぐらい篭ったりするのが理想。
シーズン中は嫌ですが。（混むので）

「せっかく温泉宿に行ってゲーム作りなんて・・・」と、思うかもしれませんが、結構オススメです。
ゲーム作りでなくても、例えばその他の創作活動（漫画とか小説など）や試験勉強などにも良いです。
「ｘｘｘをする為にｙｙｙに居る」という意識が働くことで集中力が増します。
更に、貧乏性の私の場合、「お金を払ってまで」という意識が更に集中力を増幅させます。

なので、コストは高ければ高いほど良いから、温泉宿がベスト。
ただし、温泉宿だとちょっと足が出ない場合、ビジネスホテルとかでも良いかも。
または、（音が気にならないのであれば）漫画喫茶とか。
あと、国内出張ならグリーン車、海外出張ならビジネスクラスかファーストクラスというのもアリです。
（もちろん、普通料金からの差額は自腹で）

まぁ、今回私が行ってきたのは温泉宿でもなければビジネスホテルでもありませんが。
法要で田舎で宿泊してただけ。（漫画喫茶にはチョクチョク行って作業しましたが）
とりあえず、SHOT04の５面の道中が完成し、ラスボスを作成しているところ。
ラスボスは作画が終わっていて、あとはアルゴリズムを組むだけという感じです。
この土日でとりあえず完成させて、あとは８月中に調整を終わらせ、９月中にはリリースしたい...

４面完成

４面が完成。

割とゴチャゴチャしたステージになりました。
一定距離を保って箱を打つと、アイテムジャラジャラみたいな感じです。
難易度はほど良い感じ。

あとは今週中に５面完成すれば良いなぁ・・・。
そういえば、説明書とかってAndroidだと、Windowsみたいにドキュメント（Readme.txt）を付属する習慣が無いから、やっぱり、チュートリアル的なものを作らなければ駄目かな？と、今さら考え始めました。
しかし、言語フリーで作るのは結構大変そうかも。
基本、ゲーム画面中には、単語レベルの英語以外は入れたくないと思っています。
例えば、基本的な操作系であれば、
1. Touch -> Fire and Move
2. Not touch -> Charge
3. Fill & Touch -> Laser
ぐらいが、言語を用いる上限になるイメージ。

今、ふと、「リプレイの機能を使ってそれを流しながら上記の単語レベルの説明入れていけば良いんじゃないか？」というナイスな考えを思いつきました。ちょっと面倒くさそうですが、そういう部分には力を入れた方が良さそうな気がしないでもないです。

やはり、Windows版が本丸

Android用のゲーム開発を開始してそろそろ半年ぐらい。

しかし、端末毎の仕様差が想像以上に激しいので、やはりAndroid版でのモノ作りは色々と厳しい。

設備投資を惜しまず、最初はiPhone向けで作るのが吉だった感が否めません。

私が一番気にしている問題（VSYNCの端末差）は、Android4.1でようやく解消されるようなので、Android版の開発はそれを待ってからやるべきだったんじゃないかと。あと、Android4.0で地雷（SurfaceViewの大幅な性能デグレード問題）を踏みましたし。

ですが、今開発中のSTGの本丸プラットフォームは、Windows版。

要は、Android版やiPhone版というのは客寄せパンダ的な位置づけのつもり。

やはり、STGはタブレットや電話機のようなチマチマとした画面ではなく、大画面でやりたいので。

しかも、今回は縦画面のフルスクリーン対応。

23型ぐらいのワイドディスプレイを縦置きにしてプレイすれば、ゲームセンターと同じ迫力で楽しめます。

Androidと仕様を合わせる都合上、入力装置にマウスを使うのがちょっとアレですが。

シューターは伝統に囚われる人が多いから、最初は抵抗があるかもしれません。

ただ、STG用の入力機器としては、セイミツ工業のアケステ以上にマウスの方が向いているかも。

アケステよりも精密な動きができるので。

Music room

開発中のSTGのオマケで付ける音楽の試聴機能を、かっこいい感じにしてみました。
とはいえ、こういうオマケ部分にあまり力を入れたくないから、VGS Chiptune musicからの流用ですが。

せっかく、めずらしい方法で音楽を鳴らしているので、そのことを実感していただくために。
開発中のSTGは私が独自に設計した波形メモリ音源VGS（VideoGameSound）をソフトウェアエミュレーションする方式で音楽を鳴らしています。（VGSは私の脳内にしかないので、実在しません）

言うほど難しいことはやっていませんが、こういうやり方で音楽を鳴らしているゲームといえば、エミュレータ類を除けば洞窟物語（あと、イカちゃん？）ぐらいしか思い浮かばない。結構簡単に作れるし、アプリの容量も抑えられるし、凝らなければ処理性能もかなり速い（VGSの場合、ネットブックでもサクサク動きました）ので、もっとやっている人が居ても不思議はないんですがね。
ついでに、自作音源なら、自分のやりたい範囲で好きなようにハードウェア仕様を弄れるから楽しい。

iPodTouch版でのポーズ方法

今開発中のSHOT04ですが、4面道中が完成。
夏休み前までに4面ボスまで完成させたかったのですが及ばず。
8月中に完成するか、微妙なところ。
まぁ、順調なので、今年中に完成できる点はほぼ確定です。

ところで当初、Android版が完成したらiPodTouch（iPhone）版を作ろうと思っていましたが、iPodTouchへ移植するにあたり、仕様面での最大の課題がボタン系統です。

Android版の場合、
(1) 戻るボタンを押せばポーズ
(2) ホームボタンを押せばポーズしてホームへ戻る
という感じでハードボタンを使っていますが、iPodTouchにはホームボタンしかありません。

つまり、ポーズができません。
ゲームのメイン画面中にソフトボタンは絶対に入れたくないです。
なので、iPodTouch版に限り、(1)の機能を落とす方向で検討していました。

ですが、
「マルチタッチをした時にポーズ画面にする仕様にしてみてはどうだろうか？」
という天の声（たぶん、ジョブズ）が聞こえました。

SHOT04の仕様は、シングルタッチ専用だから、それでも仕様上問題ありません。ただし、「２つ同時タッチ」だと誤ってやってしまうこともあるだろうから、３つ同時タッチでポーズにしてみました。（まだ、iPodTouch版は作る環境すら作っていないので、とりあえずAndroid版で）

操作性としては、特に問題無さそうな感じです。
これで、iPodTouch版を作る上での課題は全てクリアできたかも。
残る最大の課題は、SHOT04（Android版とWindows版）を完成させること。

ちなみに、iPodTouch版ですが、Android版とWindows版の利益だけで開発環境を導入できなければ、やりません。流石に、道楽でこれ以上の出費は避けたいので。道楽であれば、個人的にはWindows版とAndroid版だけで十分だと思っていますし。

何より、私がiPhoneを持つことは有り得ない。
iPhoneに慣れた人がAndroidへ移行することは結構簡単ですが、Androidに慣れた人がiPhoneへ移行するのは無理なので。
「AndroidだとできるのにiPhoneだとできない」ということがあまりにも多すぎます。
iPhoneのダメな所は、
・先述のハードボタンのこと
・SDカードが使えない
・パーミッションの仕組みが無い（セキュリティ的に脆弱なのでアプリを使うのが結構怖い）

セキュリティ的なところだと、Androidの方がショボイというのが世間の常識ですが、OSの実装レベルで見てみると、iOSの方がガードの仕組みが無い分、審査がザルだった場合のセキュリティリスクが高いといえます。そして、昔は「厳しい」ということで有名だったAppMarketの審査も、実際のところはザルに等しいと思われる事案がチラホラと起きて始めているので、iOSの方がセキュリティ的に見て脆弱だと思います。（これについては、将来的に立て直される可能性があるかもしれませんが）

そういえば、現状はAndroidMarket(GooglePlay)の審査もザルですが、先週末、Googleからデベロッパーアカウントを持っている人向けに、「そういった部分を強化するから覚悟しとけよ」という内容の通知が来ていました。この通知について、以下に日本語の記事がありました。
http://japan.cnet.com/news/service/35019972/
上記の内容は審査でもしないと分からないと思うので、何らかの審査でもするつもりですかね？
良い傾向だと思います。

Arcade mode

SHOT04のPC版限定ですが、縦画面モードを入れてみました。
※Android版については、最初から縦画面専用

480x640のフル画面表示です。（ちなみに、SHOT04のスクリーン仕様は240x320（QVGA））
ディスプレイを90℃回転して遊べばアーケードさながらの迫力の大画面でSHOT04が遊べます。
どのモードで遊ぶかは、起動時にダイアログ（以下）で選択する東方方式で。

一応、標準（横置き）のフルスクリーンモードは２系統用意することにしました。
640x480(VGA)の画面中央部分にオリジナルサイズ240x320を表示するモード（１番上）と、1.5倍の360x480に引き伸ばして（縦画面一杯分で）表示するモード。拡大処理はソフトウェア方式（自前）でやっているので、私が持っている無茶苦茶遅い悪いノートマシン（ネットブック）とかでは、240x320じゃないと厳しい。

ちなみに、不要とは思いますが、一応、横画面のフルスクリーン（640x480）で縦表示するアーケードモード（Arcade mode）というのも入れておきました。Arcade modeは、横画面で縦表示にして遊ぶことができます。（ほぼ、誰得機能ですが、念のため）

上記の画面キャプチャは、そのArcade modeで撮りました。
私のPCのディスプレイが横置き専用なので、キャプチャを撮るのに縦画面モードにするのが面倒。
こういうモードを入れておけば、横置きのまま、縦画面モードのキャプチャが撮れる訳です。
それだけの為の機能なので、Arcade modeについては、正式リリース時に削るかもしれません。

・・・縦置きディスプレイが欲しくなってきました。
やっぱり、縦スクロールSTGなら縦画面じゃないと迫力がありません。
ゲームのためだけに、新しいディスプレイを買うのは馬鹿らしいですが、実はプログラマにとって、横置きよりも縦置きの方が、一度に視認できるコード量が増えるから有利なんです・・・と、自分を説得中。