マルチタッチの扱い

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

例えば、下図のように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パターン。
１ステージ分のリプレイなら、大したサイズにはならないと思うから、問題無い良いかな？

対応機種

Android版の大復活（怒首領蜂）が対応機種を拡大したようで、私の機種（モトローラのRAZR）でも遊べるようになったようです・・・既にiPhone版を持っているから、買わないと思いますが。ただ、CAVEには期待しているし、小額なものなので、お布施として買っておいても良いんじゃなかろうかとも思っています。

しかし、Androidだと対応機種というのは結構大きな壁ですね。
機種が多様なので。

私の場合、機種については問題無いのですが、AndroidのOSバージョンには悩まされました。
私のゲームの場合、Android 2.3.3以降であれば、市場に出回っているほぼ全ての端末で動作できます。
しかし、本当は、普及バージョン（Android 2.2以降）にしたかったのですが。
ただ、Android 2.2だとOpenSLが使えないので、音関係では何もできないといっても過言ではないです。

Android 2.2が普及してしまった所為で、Androidのゲームには音関係がショボイものが多い...
ゲームを構成する要素の中で、音の重要度はかなり高いと思っているのですが。
Android 2.3が初期の普及であったのなら、状況は大分違ったと思います。
というより、Javaという時点で、Androidでアクションゲームを動かすことは想定外なんでしょうけど。
Javaを積むこと自体には、開発コストを抑える等のそれなりの意義が有ると思いますが、メインアーキテクチャをネイティブにして、ネイティブでの品質を高めてからJavaを積むのが妥当です。もちろん、それだとx86やARMといった石の互換性の影響を受けてしまうのですが、それなら機械語部分を仮想化すれば良いだけの話だと私は思っています。例えば、フィジカルな石はx86だけど、ロジカルな石をARMにして、OSよりも上位レイヤー（ミドルなど）を全てフィジカルロジカルな石（ARM）用にコンパイルして動かすことを前提とすれば、Javaのようなコンピュータのプログラムを作るのに適さない言語を使う事無く、石の差異を吸収できる訳です。（一見するとオーバーヘッドが高いやり方ですが、Javaよりは大分マシ）

・・・そもそも、Androidの場合、プラットフォーム差異の吸収方法に関する発想の基点（Java万能説を信じた所）から間違っていたと思うので、今更どうにもなりませんが。

といより、ヘタに差異吸収を考えるより、Appleのように割り切ったやり方が正解だと思いますが。
上述のような技術の開発コストよりも、市場を制圧すればそれしか無くなる訳なので、安く済みます。
もちろん、市場を制圧することが大変なんですが。
しかし、そこら辺のことを、Appleの前の経営者はよく分かっていたんじゃないかと思います。
そこら辺の事情（＝良いものが普及するのではなく、普及したものが良いものになるという定説）により、最初は大負けしていた訳なので。もっとも、今も昔も、私はAppleが嫌いですが。

価格設定

SHOT04の価格設定ですが、値段が高すぎて買わないという人が出ないよう、販売開始時点では最低価格に・・・と、思ったのですが、最低価格にすると、InvaderBlock2と同じ値段になってしまうから、InvaderBlock2の税抜き価格（99円）から+1円値上げして、100円（税抜き）を初期時点の価格にしようと思っています。

あんまり値段に関しては低く設定すべきではないと思っていますが。
多分、小額に設定した方が儲かると思うのですが、ダンピングは良くないです。
幾ら作っても、タダで何でも手に入ってしまうと、作る人が居なくなってしまい、何も作られなくなる・・・
・・・という状況を（PCで）見てきたので、それなりの危機感を持っています。

ただし、「後から値段を下げる」というのは絶対にNGだと思っていますが。
理由は、その行為は早い時期に買ってくれた方々に対する裏切りだと思っているので。
これは、去年SHOT03を売り出した時にそう思い、定めたポリシーです。
だから、SHOT03が如何に売れなくても、値下げはしないし、フリー化もしません。

SHOT03は価格設定を完全にミスったのですが。そして、一本も売れていないから、フリー化しても誰も損しませんが、そういう前例を作ってしまうことがアウトだと思っています。

しかし、逆に「後から値段を上げる」のは、競争原理に則っているので問題のないことだと思います。

SHOT04の場合、体験版という形で、ライト版相当の商品を先行配信しているから、販売当初は100円（税抜き）で販売しておき、体験版をインストールしてくれている方々にアップデートで製品版の完成を通知後、一定期間経過したら標準価格に引き上げるやり方が一番良いのではなかろうか・・・と、思案中。

ですが、標準価格は、まだ決定してません。
中々難しいです。

「キャンペーンです」とか言って、何の悪気も無く値下げセールを『後出し』でやったりしている所は多くありますが、そういうのを見ると「如何なものか」と思ってしまいます。在庫管理が不要で（物理的な意味で）腐らない電子的なもの（情報）で商売する場合、「後から値下げ」は禁忌だと思っていますが・・・私の感覚がオカシイのかな？

物理在庫があったり、消費期限のあるものの場合、ソレが捌けなければ余計な在庫管理費用が掛かったり破棄の必要がでてくるので、値下げ販売はある程度やむを得ません。半額弁当などのように、それが常態化するのは問題がありますが。（※蛇足ですが、「常態化している」ということは、つまり、それが価格に転嫁されていて、それ自体を客寄せパンダみたいな意味合いで使っている場合が殆どです。なので、標準価格で購入すると、必然的に半額販売用の折込価格を消費者に負担させていることになります。その点を消費者が理解した上で、標準価格の弁当を購入するのなら問題ありませんが、そうでない場合は問題があります。）

海外・・・

SHOT04の体験版のDL数が300に到達しそうな感じで、中々好調です。
インストール率は、57%ぐらいで、かなり低いですが・・・
SHOT04は、他のAndroidゲームと比べて、ディスク容量が無茶苦茶小さいから、「ディスクの無駄」という理由は無いと思います。つまり、43%の人は「つまらない」という理由でアンインストールした・・・ということだと思います。多分。

しかし、それ以上の懸念は、海外でのDL数がサッパリだということ。
SHOT04の場合、日本国内よりも海外でウケると思っているのですが、それ以前にDLして貰えていないという状況・・・現時点で海外のインストール数は、2件。

VGS chiptune musicは、海外のユーザーが圧倒的に多いので、ちょっとばかり曲を追加しつつ、VGS chiptune musicの画面中で、SHOT04の宣伝を入れてみるアップデートをしてみました。

ちなみに追加した曲は、SHOT04の4面で使う予定。

NOKOGI Rider / version 0.02(Trial) has released

SHOT04（NOKOGI Rider）のバージョン0.02（体験版）が無事リリースされました。
今、GooglePlay経由で私のスマホにインストールできることを確認。
問題ありません。
Have fun!

今回のアップデートの目玉は、
①自機の種類が３種類に増えたこと
②スコアシステム（SHOT値）の導入

Type-Cは、アンチパターン（＝初心者）向けに作ったつもりですが、攻撃が分散されるので、中ボス戦でレーザーを織り込まないと、逃げられてしまうから、それなりにパターンを組むことが要求されます・・・なので、完全に初心者向けとは言い難くなってしまったかも。（若干、誰得な機種）
Type-Aが一番バランスが取れていて、楽しめる筈。
個人的には、Type-Bが一番楽しい。



スコアシステム（SHOT値）は、一見すると地味なアップデートですが、かなり重要。

私の個人的な思いとして、「上級者にレーザーではなくショット主体でプレイして貰いたい」というものがあり、上級者がレーザーでパターンを組むスタイルを回避するために設けました。このAndroid用のSTGとして特化した特長であるレーザーの仕組みを、私自身がディスるのは、若干微妙な気分ですが、実はそうすることの方が理に適っているような気がしたので、実装しました。
レーザーの仕組みが誕生したそもそもの目的は、ボンバーに替わる回避処置としてです。
殆どのSTGには、回避処置として、ボンバーがあります。
しかし、ボンバーを実装するには、ボタンなどの発射用のインターフェースが必要になります。
しかし、私はAndroidやiPhone用のゲームでは、絶対にボタンは入れるべきではないと思っています。
そして、ボタンを使わずに実現できる回避処置として考え付いたのが、この仕組みです。
あくまでも回避処置なんだから、使わなければ得点を稼げるようにする事が自明の理・・・です。

そういえば、そういう方向にしたのだから、レーザー発射中は無敵にしてしまった方が良いかも。
（現状、レーザー発射中にも敵や敵弾との当たり判定があります）