落ちる問題

SHOT04-NOKOGI Riderのバグ修正で、リプレイ再生をした時、スコアがズレる問題を修正したものをチェック中・・・。

たぶん、直ったと思います。
今分かっている範囲では、本件は単一の問題ではなく、２つの複合的な問題に起因するものでした。

内、ひとつの問題がかなり致命的。
単純にリプレイがズレるだけでなく、場合によっては、プログラムが落ちるレベルの問題です。
リプレイは、製品版でしか記録できませんが、落ちる問題はLite版でも発生し得ます。

でも、「落ちた！」といった連絡は、1000件以上ダウンロードされているけど、まだ一回も無い・・・と、思っていたら、海外の方から、コメントに評価１とともに「落ちた」というレビューがありました。この問題と同件問題である可能性が結構高いです。できれば、どういう操作をした時に落ちたか分からないので、本当に同件かは定かではないです。

とりあえず、土曜日中には対策版（Version1.6）をリリースする予定です。
なお、この問題の影響でVersion1.5以前のリプレイデータが正常に再生できなくなる可能性があります。
一応、こういう自体を想定して、リリース初期段階の価格は安めに設定している訳ですが、だからといって、問題が無い方が良いに越したことはありません。

---

誰が得するのか・・・

iPhone5の画面幅のサイズが16対9になるらしいです。
iPhone4の頃は、1.5対1。（Androidでも標準が1.5対1になりつつあります）

割と思い切った仕様変更の割りに結構無意味な仕様変更かも。
一応、縦に長い文書やページを読む時は、縦に長い16対9の方が便利なので、16対9のAndroidがあっても不思議ではないです。しかし、アミューズメント分野専用機（だと思っている）iPhoneを16対9にする目的は何なのか？

中途半端なメリットしかないような気がします。
むしろ、「全機種で画面比が同じだから、アプリが作りやすい」というメリットの方が大きかった気がします。
それでも、画面比について定まった仕様が無いAndroidよりは幾分かマシですが。

---

NOKOGI Rider 1.06リリース予定

今のところ、NOKOGI RiderのVersion 1.05（以前）に以下の問題があることを把握しています。

(1) 非フルスクリーンモード時にタッチ位置がズレることがある問題の対策
(2) リプレイ再生したときのスコアがプレイ時と異なる場合がある問題の対策（※製品版限定）
(3) Lite版の「PLAY DATA」にプレイしたスコアがランキングされない問題の対策（※Lite版限定）

これらの内、(2)のスコアがズレる問題ですが、これは緊急度が高いと思っているので、寝る間を惜しんで調査中なのですが、ようやく、原因を特定できたかもしれません。ただ、もしかするとVersion1.05以前で記録したリプレイは完全に再生できず、Version1.06以降で記録したリプレイに限り、完全に再生できる形になるかも・・・大変申し訳ないです...

あと、(1)のタッチ位置がズレる問題ですが、解決方法が見つかったので、コチラはスッキリ対処できると思います。
コレの原因ですが、かなり馬鹿だったので、紹介しておきます。

Androidのアプリは、Activityというフレームワークの下で動作します。
そして、画像や図形などは、Activityに作ったViewという領域に描画します。
Version1.05以前は、Activityでタッチイベント（onTouchEvent）を拾い、タッチ状態や座標情報をゲーム本体（JNI）に渡していました。

フルスクリーンなら、これでも問題ありません。
しかし、非フルスクリーンの場合、この方法だと問題が起きます。
たいていのAndroid端末は、ステータスバー（電池残量や時計などを表示する領域）が画面上部に表示されますが、これによりゲーム画面（SurfaceView）の表示部分が、ステータスバーの高さ分だけ下にズレます。

Activityでタッチイベントを拾うと、純粋に画面全体の領域の座標を拾うので、ゲーム本体（JNI）に渡す座標情報から「ステータスバーの高さ分のサイズ」を減算する必要があります。
しかし、この「ステータスバーの高さ分のサイズ」を正確に拾う方法が（Android2.3では）無いので、Version1.5では、若干信頼性の低い方法でステータスバーの高さ情報を拾うようにしていました。このやり方だと、稀によくステータスバーの高さを間違えることがあり、この時、タッチ位置がズレる現象が起きます。

しかし、今日「Viewでもタッチイベントを拾えるんじゃないか？」と思い調べたところ、当然の如く、拾うことができました。onTouchEventをViewでオーバーライドしてあげれば、普通にViewでタッチイベントを拾うことができます。そして、このやり方ならステータスバーによるズレを意識しなくても良くなるので無事解決・・・という訳です。

修正版（Version1.6）は、早ければ今週の土曜日ぐらいにリリースすると思います。
あと、Version1.6のリリースと同時に第１回目の値上げをする予定です。
NOKOGI Riderの価格は、こちらの記事で書いたように、適正価格になるまで段階的に引き上げていきます。当然ながら、既にご購入いただいた方からの追加徴収などはありません。
あと、InvaderBlock2の方にも非フルスクリーンへの対応やポーズ機能の実装などを入れる予定です。

---

また曲作りから

SHOT04-NOKOGI Riderの続編（SHOT05）で使う音楽を作曲をする作業を始めてみました。

とりあえず、１面の曲を作曲。

TwitSoundなる、音楽共有サイトにSHOT04のステルスマーケティングとともに投稿。

http://twitsound.jp/musics/tsXYSuMHv

だいたい、こうゆう音楽は１日掛からないぐらいの期間で作れます。
限界までやれば、１日２曲ぐらいのペースかも。
逆に１日以上の時間を掛けて作曲すると、前後の繋がりが「？」になってしまいます。
なので、勢いで作るのが重要。

ただ、作曲作業自体は１日で終わるのですが、VGS用のMMLに変換するのが大変。
作曲する作業には、ピストンコラージュを使っていますが、音符データをテキスト形式に変換する手段が無いので、ピアノロールを眺めながら、ひたすらMMLに書き直すという作業。

この曲は、土曜日の午前中に作曲したのですが、MML変換が終わったのが昨日ぐらい。
一応、普通のサラリーマン（残業は毎日だいたい２時間～程度）だから、掛かりきりではないですが。

このMMLへの変換作業ですが、単純作業という訳ではなく、細かいバランス調整をする作業も兼ねています。なので、今の仕様のままで良いかな・・・面倒くさいけど。
VGSのMMLコンパイラを作ったばかりの頃は、ピスコラから音符データをテキスト形式で取れるようにする為、ptcolのEventV5データ（内部データ）を一生懸命解析したりしていましたが、割と解析しにくかったので諦めました。

---

ソースコード検査

独立行政法人の情報処理推進機構（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のホームページでの紹介のノリも「学習用途！」みたいな感じですし。

---

「無料アプリ」について

AndroidやiPhoneなどのアプリには「無料」をうたうアプリが沢山あります。
皆さん、ボランティア精神が旺盛・・・などという訳ではありません。
それら無料アプリの大半は、アプリ内課金やアフィリエイト広告を収益の柱としています。
個人的には、そのどちらにも問題があると考えています。

「アプリ内課金」については、正しいやり方であれば問題ないと思います。
正しいやり方とは、例えば、ドラクエ４のような感じのゲームであれば、「１章は無料、２章～５章は各500円」みたいな。
そういうやり方であれば、安全な取引ができるので。

現状、嘗てのビックリマンチョコみたいな感じのゲームが横行していますが、そういう類のゲームというのは非常に簡単に作ることができます。恐らく、プログラマは１人月程度の工数で作っているんじゃないでしょうか。そっち方面の仕事はやったことが無いので想像ですが。しかし、技術者視点で見ると、ビックリマンチョコみたいな感じのゲームは皆、その程度の中身の無いゲームしかありません。

「１章は無料、２章～５章は各500円」みたいなゲームの場合、そういう中身が無いゲームでは商売が成立しません。つまらなければ誰も買わないので。ポイントは、利用者が課金する時に「冷静な判断ができるか否か」だと思います。つまり、「安全な取引」が可能なものであれば、アプリ内課金をやっても良いと思います。

ただ、そういうゲームであれば、無料のLite版と有料の製品版を分けるやり方と大差はありません。「アプリ内課金」といってしまうと、（コンプガチャなどの所為で）聞こえが悪いので、無料のLite版と有料の製品版を分けるやり方が、ベストだと思います。

もちろん、コンプガチャのような中身の無いゲームが好きな方も居るかもしれませんが。
なので、多少はあっても良いかもしれません。
しかし、そういう中身の無いゲームが横行する事態は、異常だと思います。
在っても悪くは無いけど、もっとマニア専用のニッチな存在であるべきだと思います。

なお、「アフィリエイト広告」については、アフィリエイト広告の仕組み自体に問題があると思います。これについては、別の記事で、実際に（たった100$ですが）出資して実験してみた結果を載せています。アフィリエイト広告付きで無料アプリ（アフィリエイトブログを含む）を出そうと思っている方には、是非、一読していただきたいです。

私は、アフィリエイト広告付きで無料アプリ（アフィリエイトブログを含む）の存在を否定するつもりはありません。しかし、広告掲載者になる以上、アフィリエイト広告業者ではなく、スポンサー（広告出資者）との間で、Win/Winの関係を築けるよう、最大限の努力をしていただきたいと思っています。（まぁ、今の仕組み上、それは無理だと思っていますが・・・広告掲載者があまりにも多すぎるので、ひとりふたりが努力したところで無意味です。機械的な仕組みで不正を排除する必要があるのですが、それをやるべきインセンティブがアフィリエイト広告業者サイドに働かない点に問題があると思っています）

---

バナー

SHOT04 - NOKOGI Riderの宣伝について、アフィリエイト広告に出資をしてみる試みについては失敗に終わった（コチラの記事を参照）ので、新たな宣伝戦略を考えてみることにしました。

ところで、このブログですが、バナー広告の類は一切設定していません。
設定すれば、クリック単価の収益が得られるようです。
しかし、私自身、アフィリエイト広告については批判的な立場なので、今後も設置しません。
ただ、自分の広告を自分のブログに載せるのは建設的だと思うので、そういうバナーを作ってみました。

↓こんな感じです。


今後、ブログの末尾にこの広告を載せていこうと思います。
このバナー広告は、クリックしても誰もコストを支払わないタイプなので、思う存分、クリックしていただいて問題ありません。

あとは、なるべく面白い記事を書くようにして、トラフィックを集めるように頑張る感じでしょうか。
でも、文才は無いと思うので、あまり大した広告効果は期待できませんが。