NOKOGI Rider 1.06をリリース

朝から、ひたすらNOKOGI Riderのデバッグを繰り返し、ようやく、スコアがズレる問題を完全に解消できたと思うので、今しがたVersion1.06をリリースしました。たぶん、完璧に直ったハズ。

今回の対策には、だいぶ苦労しました。
最終的には、プレイ時にフレーム単位でスコアをログに記録し、リプレイを再生するときにフレーム単位で完全に一致するかチェックする→差異が生じたタイミングの推定処理部分から、バグを見つけ出す・・・といった方法で、ズレる原因を特定しながら調査→修正する方法で直しました。

なお、今回のリリースにともない、価格改定を実施しました。
日本では、150円→200円になります。
※私は消費税の支払い対象業者ではないので、価格は税抜き価格です
価格制定の方針については、こちらの記事をご参照ください。

今回の改訂根拠としては、150円の頃（Version1.05）にご購入いただいた方に、保存したリプレイデータが正常に再生できなくなる可能性があるご迷惑をお掛けしたことになるので、当時の価格をその点を考慮したディスカウント価格と考え、+50円upとしました。
NOKOGI Riderの妥当価格は300円ぐらいだと思っているので、今後も品質向上や売り上げ目標達成などを契機に段階的に引き上げる予定です。

ちなみに、一つ前の記事で英語でVersion1.06の修正情報を載せていますが、これは、海外からコメント付きで☆１個や☆２個の低評価とともに、不具合のご連絡をいただいたためです。

問題があったのだから、低い評価をされるのは仕方が無いですが、問題を直せば評価が修正されるのかが気になります。そういう問題に遭遇した場合、「もう知らん！」といってアンインストールしてしまい、再評価の機会（アップデート）を失うような気もするので。

☆１個の評価の方は「落ちる」といった内容なので、それでも仕方がありません。
しかし、☆２個の方は、ゲーム内容自体は褒めているのに、「フルスクリーンがイヤだ」という理由だけで、低評価をつけられました。コチラの方は、評価の修正を切に願います。「非フルスクリーンに対応したら買ってやる」とのことでしたが、私としては、別に買ってくれなくても良いから、評価だけでも修正して欲しいところ。１本買って貰うことより、１つの悪評が消えることの方が嬉しいので。（もちろん、高評価をつけていただけるともっと嬉しい）

---

Information of NOKOGI Rider 1.06

Suzuki Plan has released the NOKOGI Rider version 1.06.

[Product version]

Corrected following problems:
- force close error or process stops unexpectedly.
- touch position may be wrong, when you have selected the non fullscreen mode.
- results of replay may be different from when you played.
Note: The replay data of before Version 1.5 may not play normally. This reason has effected by first problem. I'm sorry...

[Lite version]

Corrected following problems:
- force close error or process stops unexpectedly.
- touch position may be wrong, when you have selected the non fullscreen mode.
- score has not ranked , when level-1 has cleared on Lite version.

Changed specification:
- The default setting of full SCREEN MODE has changed to OFF.

Dear Reviewers,
Thanks for reported of problems. I think the both problems of force-close and screen mode will be corrected in this version 1.06. But I don't know it's the same of reported problem... Please describe the comment and judgement again, if your detected problem has corrected.
Best Regards,
Y.Suzuki

---

落ちる問題

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のホームページでの紹介のノリも「学習用途！」みたいな感じですし。

---