2012年2月29日水曜日

公開直前

InvaderBlock2の公開が間近ですが、色々と変更します。

(1)価格設定 → 最低価格にする
実は、有料だと全然売れないと思っているのですが、それでも、「値段の所為で売れなかった」という事態を避けるため、最低価格に修正。(そもそも、元々は無料で配ろうとしていたぐらいだし)
とはいっても、100円が99円になっただけですが。

(2)コピー防止機能 → 入れない方向とする
外的に埋め込むモノとはいえ、これが原因で何か起きた時に何も対処出来ない(しかも、間もなくサービス終了するという勧告もある)というリスクを避けるため。
そもそも、全然売れないと思うので、あまり目くじらを立てる必要も無かろう・・・と、推測してます。
そして、仮に1本でも売れた場合、その購入者に確実なサポートができなくなる方がマズイ。

ついでに、売れるとしても日本か米国のみだと想定している(和文と英文しか準備していない)ので、あまり心配する必要は無いでしょうし。ちなみに、BSAの調査(2010年版)では、日本、米国、ルクセンブルクの不正コピー率の低さは世界1位です。
http://www.bsa.or.jp/press/release/2011/0512.html

という訳で、対策を講じるとしても、ライセンスサービスの内容を把握して第二弾以降で。
完全に購入者の善意に委ねます。
先日の記事で「違法コピーを望まない旨の意思表示云々」言ってましたが、ソフトウェアの開発者サイドで違法コピー=不利益を望む人なんてそもそも居ないですし。

あとは、約3時間後に(24:00を回ったら)公開ボタンを押すだけ。
審査とかに数日掛かったりする・・・なんて、オチが無いことは事前に確認済み。
実は、今日気付いて確認したんですが。危ない危ない...

一応、公開できたら自腹で購入テストをする予定。

2012年2月28日火曜日

いいかも・・・

InvaderBlock2は、AndroidManifest.xmlでポートレイト・モード(android:screenOrientation="portrait"=縦画面固定)にしていたのですが、アスペクト比調整のデバッグで横画面にしてテストしたりしていました。

・・・で、気付いたんですが、私がデバッグに使っているタブレット(7インチ)は、横置きでアスペクト比調整すれば、ピッタリ、スマートフォンサイズになります。

で、先ほど気にしていた16スロットの問題が本当に押し難いかチェック。
普通に押し易かったです。

とりあえず、スロット数を減らす修正は入れなくて良さそうです。
ターゲットユーザがスマートフォンなら、7インチ横置きでテストするのがベストかもしれない。
(ただし、リリース時はポートレイト・モードに戻すけど)


本当は、ターゲットユーザがスマートフォンなら、スマートフォンでテストするのがベストですが。。。
スマートフォンは高い・・・ランニングコスト的な意味で。

アスペクト比修正など

本当に3月1日にリリースする気があるのか・・・?
というぐらいの問題が発覚。

InvaderBlock2は、QVGAの縦置き(240x320ピクセル)という画面仕様で、デバッグ用のAndroid機は、画面がデカイけど、比率はそんなもんだろう・・・という想定で画面一杯に拡大していたのですが、どうも、手持ちのデバッグ機は600x1024ピクセルというサイズ(QVGA=横0.75:縦1.00と比率が違う)でした。

その問題は、アスペクト比調整する修正を入れて軽く直しました。
しかし、画面が小さくなると、セーブスロット(16個)を選ぶ作業が大変・・・
そして、スマートフォンだともっと画面が小さいから、もっと大変・・・という問題も発覚。
何を今更・・・と、思ってますが、セーブスロットを16個→8個に減らそうか検討中。
(会社が休みだった昨日の内に気付かなかったのが悔やまれる)

2012年2月27日月曜日

難易度調整

簡単過ぎるゲームは好きではありません。
昨今のゲームは簡単すぎるものが多い。
しかし、単に難しければ何でも良いという訳でもありません。
恐らく、適度な達成感の得られるゲームというのが、最善です。

という訳で、InvaderBlock2の難易度を調整。
ボールの動きを少し遅くしてみたり...etc
こういう部分は、一度リリースしてしまうと「リプレイデータの互換性」という柵ができてしまうので、変更可能な唯一のタイミングが今です。単なるバグなら、アップデートで更新できる仕組みがあるから、こういう部分の調整に力を入れるのが吉だということに、本日夕方頃、気付きました。

実は、Androidの場合、画面(SurfaceView)の更新間隔が16msに1回のようです。
つまり、秒間の描画回数は62~63の間。(62.5fps)
Windows(DirectGraphic)のフルスクリーンのゲームであれば、簡単に60fpsに調整できますが、実はこの60fpsというのはあまり良い数字ではありません。60fpsだと1秒(=1000ms)で割り切れないので。(16.6666666....msになってしまうから、例えナノ秒精度でウェイトしてもダメ)

つまり、60fpsにしようとすると、16ms→17ms→17ms(50ms/3回)の不均等な間隔で描画する必要があります。そうすることで、1000ms÷50ms=20になり、20×3回=60fpsという具合になり、めでたく60fpsが実現できる訳です。(ハードウェア的に60fpsをサポートしているGPUの場合、もっと細かい単位(μ秒やナノ秒単位)でズレを設けているかも・・・ハードには疎いから分かりませんが)

例え1ミリ秒であっても、不定期にズレが生じると違和感を感じることができます。
(故に、ガーベージコレクションというのはかなり厄介なシロモノ)
しかし、3回に1回という形で規則的に動作すれば、脳(視覚)は「均等に動いている」という錯覚を起こします。つまり、60fpsというのは、錯覚の原理を利用しているのでフレームの視覚的均一性は、実は幻だった・・・という訳です。ただし、人間は時間の単位を基本的に60進法で管理するので、60の方が良いのかも(=1ミリ秒を1/1000秒としたのが誤りなのかも)しれませんが。

余談が長くなりましたが、要するに
「Android版InvaderBlock2は62.5fpsで、それを60fpsに調整する気はない」
ということです。(Windows版も公開時は62.5fpsに調整予定)

しかし、当初Windowsでは60fpsでテストしていたので、ゲームスピードが4%速くなってしまいました。
その分(4%)を調整するためにボールの速度を調整・・・という訳です。
もちろん、これの所為で達成感を損なうレベルに難度が落ちる事だけは避けたい。
なので、慎重に調整します。

公式HP

公式HPでInvaderBlock2の情報を開示。
http://hp.vector.co.jp/authors/VA040196/android/

シンプルに纏めました。
(トップページもシンプルに修正)

動作環境・公開先・(予定)価格は、今後作るゲームで皆同じにするつもりなので、第二弾以降を出したらレイアウト変更が必要ですね。

一応、第三弾ぐらいまでは、作りたいゲームのアイディアがあります。
第二弾は、シューティング(SHOT04)の予定。
予定は未定ですが。
しかし、タッチパネルでシューティングというのは、操作性の面が悩ましいです。ただし、ちょっとしたアイディア(もちろん、ゲームパッドなどの外部ハードは不要)があるので試してみたい。

あと、外部ハードで思い出しましたが、以前の日記で「タッチペン推奨」と書いていたかもしれませんが、試しに、600円ぐらいの安価なタッチペンを買ってきて使ってみたら、結構微妙でした。
結構筆圧をかけないと、反応してくれない感じです。
もうちょっと高価なタッチペンじゃないとダメかな?
本質的な仕組み(先っちょ部分)に大差は無いようだったので、定かではないですが。
現時点のInvaderBlock2は、指で快適に操作可能なので、高価なタッチペンで試す予定はありません。

アップロードまでの流れ確認

3月1日にInvaderBlock2を公開すると決めたは良いんですが、これまでの流れから推察して、
「色々と手間取ってリリース遅延するんじゃないか?」
と、心配になったので、アップロードまでの手順をギリギリの所(公開する直前)まで進めてみました。
「保存」をやったのに、何故か保存されなかったようですが、手順は把握しました。
概ね問題ありません。

ひとつ問題になったのが価格設定。
とりあえず、米ドル基準で1$の価格設定をしようとしました。
なので、日本円なら79円ぐらいということで80円。
1本あたりの私の利益は、56円。(Google按分が30%のため)

マーケットアカウント取得費用(約2000円)+英作文費用(約500円)の原価を稼ぐのが目標。
なので、約45本売れればプロジェクト成功です。
一応、デバッグ用のデバイス購入費や参考書(2冊)の購入費の設備投資費用もありますが。

・・・しかし、どうも最低価格というのが有るらしく、日本円なら99円が一番低い設定らしい。
という訳で、米国=1$、欧州=1€、日本=100円という価格設定にします。
この方がスッキリして良いと思います。
端数はあんまり好きじゃないから、ワンコインでお釣り無しが良いので。(皆、クレジット決済でしょうけど・・・)

という訳で、1本あたりの私の利益は、70円にハネ上がりました。
目標売り上げ本数は約29本・・・これなら、なんとかなるかな?
微妙です。
というより、1本でも売れるのかが疑問。

あと、どうでも良いですが、YouTubeの動画はフルアクセス設定に修正。

不正コピー防止処置

Androidマーケットで公開するアプリケーションの防止処置としては、

  • コードの難読化
  • コピー防止(将来廃止予定)
  • LVLの実装(Googleライセンスサービスの利用)

の3種類があるようです。

コードの難読化は、Java特有の事情でしょう。
なので、InvaderBlock2(殆どCのみで実装)ではほぼ影響なしだと思います。
※ただし、ARMの逆アセンブルは、6502系統だけあって純RISCアーキテクチャ(Rシリーズ等)と比較して解析し易いと思いますが。

コピー防止は将来廃止予定とのこと。
とりあえず、root化した端末で簡単にコピーできない程度のもののようです。
外的にAPKに埋め込むものらしいので、恐らく、突破は簡単。
外的にAPKに埋め込むから導入も簡単。

LVLは、コード変更が必要。
サンプルと解説を斜め読みした限り、通信が発生しそうな気がしています。
結構複雑なので、読みきれてませんが。

・・・で、「何をやり、何をやらないか」ですが。

  • コード難読化 → 殆どCで実装しているからやらない
  • コピー防止 → やる
  • LVLの実装 → やらない

かな。

InvaderBlock2は今のところ通信処理を一切入れていないです。
アフィリエイト広告はヤメにしたので。
折角、無通信&処理も軽い電池にやさしいアプリなのに、LVLのためにそれを行うのは・・・

もちろん、不正コピーの横行は防止したいですが。
しかし、公式ドキュメントを未だ理解しきれていない。(結構複雑です・・・英語だからかもしれませんが)
その状態で実装を入れるのは、かなりリスクが高い。

最低限のコピー禁止の意思表示はコピー防止の導入で伝わる筈。
そもそも、悪意がある人への防止は、如何にLVLを導入しても難しいと思います。

という訳で、利用者の善意に委ねるのがベストと判断。

合理的ではないものを作りたい

ここ最近、実機版の東方VGSの開発が忙しくて、東方VGSの曲追加が滞っています。 東方VGS(実機版)のデザインを作りながら検討中。基本レトロUIベースですがシークバーはモダンに倣おうかな…とか pic.twitter.com/YOYprlDsYD — SUZUKI PLAN (...