2012年5月31日木曜日

どの程度、保持したものか

SHOT04(NOKOGI Rider)のローカル・スコア保存のシステム周りを実装中。
とりあえず、現時点では下図のような感じ。

画面上のRANK/TYPEで、スコアランキングを確認するRANK/TYPEを選択できます。
スコアは、RANK/TYPE別に16位まで保存。
ランキングの保存情報は、プレイ日付、スコア、到達ステージ(オールした場合はC)。
概ね東方と同じ方式だと思います。
この辺は、あまりカスタマイズ余地が無いかもしれません。
ちなみに、プレイヤのエントリ名はランキングでは表示なしの仕様。
エントリ名は、リプレイ保存でのみ設定する仕様にしました。
(ランキングは端末単位のローカル情報なんだから、設定は無意味と判断)

あと、[DETAIL]ボタンを押せば、統計情報を表示する感じにします。
統計情報は未だ仕様を決めてないのですが、
①ゲーム本編のステージ別プレイ回数 & 2面以降の到達率
②ゲーム本編のクリア回数(クリア率)
③プラクティスのプレイ時間(ステージ別)
④プラクティスのプレイ回数(ステージ別)
を表示する予定。
もちろん、①~④はRANK/TYPE別で。

そんな沢山の情報を保持したら、ディスクがパンパンになるのでは?
と思うかもしれませんが、これら全部+@の情報サイズは、全部で3KBいきません。
だから、この情報でディスクを切迫することは無いです。

ディスクサイズで気を遣う必要があるのはリプレイデータの方。
デモプレイのリプレイデータですら11KB(無圧縮)もあるので・・・
リプレイデータは、保存時に圧縮すべきか検討中。

Androidなら問題にならない程度なんですが、iPhoneの場合、ローカルストレージのビット単価がかなりのボッタクリ価格なので。だから、少しでもディスクサイズが小さくなるように努力する必要があります。
現に、私がiPodのアプリを選ぶ時は、ディスク容量で第一のフィルタが掛けていますし。
もちろん、Androidでも気にしない訳ではないけど、iPodよりは若干緩いです。

2012年5月30日水曜日

スコアランキング

まだ、(ローカルの)ランキングは作ってませんが、プラクティスのスコア保存などの機能を実装したりしました。
こういう機能は、別に後から作っても良いのですが、システム周りのことは先に作っておき、後付で必要なデータや要素を追加していった方が良いもの(楽しいもの)ができると思っているので、早目に実装するのが吉です。(一度リリースしてしまうと、互換性の問題が生じるから、アップデートで更新できない場合が多々あるので、初期リリースまでに必要な要素を全て詰め込む必要があります・・・そういう場合、こういうやり方=自分で遊びながら必要なものを後付するのがベストです)

とりあえず、プラクティスモード(製品版のみ)では、RANK別×TYPE別×STAGE別にハイスコア+そのリプレイを記録する仕様でいこうと思っています。

あとは、プレイ時間やプラクティス時間をゲーム内時間(60フレームを1秒でカウント)で記録して、プレイデータ画面(製品版のみ)で、統計データやランキングを確認できるようにするつもり。

ちなみに、ランキングはネットワーク連動ではなく、ローカルのみ。
ネットワーク系の機能は実装しません。
ただ、将来的にはネットワーク経由でSHOT04(NOKOGI-Raider)のリプレイをアップできるスコアボードのようなものを作りたいのは山々なのですが、仮に作るとしても製品とは別のアプリで作ることになります。ゲーム本編では一切のネットワーク接続をしない方向です。
これは、私の個人的な趣向なんですが、ゲームの画面遷移などがネットワーク連携したがためにモッサリするのが嫌いなので、ゲーム本体は完全ローカル指向です。だから、ネットワーク接続するのなら、専用の別アプリで作る形になります。

そういえば、スコア関連の処理を実装していて思い出したのですが、iPhoneなら、標準でGameCenter機能を利用することで、簡単に全国ランキングみたいなものをアプリで実装できるのですが、それもやりません。

CaveのiPhone版「虫姫さま」がGameCenterのスコアランキングと連動していて、始めた当初の頃は「これは、面白い!」と思ったのですが、明らかにバグかハックして出したハイスコアが、ランキング上位を独占していたので、かなり微妙。
まぁ、バグがあることそのものは(良くはないけど)問題ではありません・・・当然無い方が良いですが。
問題は、GameCenterのランキングが、バグで出したもの or 正規プレイの区別がつかないということ。
リプレイも込みで登録できるようにすれば良いのですが。
しかし、(GameCenterの仕様を調べた訳ではないから定かではないですが)そんなんに対応したら、サーバがパンパンになってしまうから、多分対応していないと思うので、仮にiPhone対応するとしても、GameCenterはやりません。

寧ろ、GameCenterへの対応は逆効果だと思ってます。
プレイヤーの8割は、ランカーではないという統計データが(私の脳内に)あり、自分のランクを過度に気にする人の割合は2割弱程度です。(8割の人は、ランクとかは別に「有っても無くても良い」と思っているものと思われます)
で、ランキング機能は、その2割弱の人が楽しむための機能なのですが、恐らく、その2割弱の人の大半は、正規のプレイでトップスコアを狙うことを目指しています。当然ながら、そういう方々は、バグプレイでランキングが荒らされることを嫌います。
つまり、2割弱の人が楽しむための機能なのに、2割弱の人の大半は(バグスコアに)ストレスを感じているので、正に誰得な機能。寧ろ、無い方が幸せになれる人の数が増えます。
そんな誰得機能が果たして要るのか?と考えれば、以下略。

2012年5月28日月曜日

マルチタッチの扱い

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

例えば、下図のように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について入門書の類は読んだ事が無い(英語の公式マニュアル以外は見たことがない)からよく分からないのですが、入門書とかにはこういうネタが書いてあるのかも。
要は、「ちゃんと入門書ぐらい嫁」という話なのかもしれません・・・だが、断る。
私は、入門書や参考書の類の書籍を未だ嘗て一度も読破したことが無いから、買うだけ無駄です。
リファレンス的な用途なら、公式だけで十分。
公式は英語だけだから、読むのが若干面倒ですが。

中々快調

2面の作成が中々快調です。
1匹ザコを作りました。
この調子でどんどんザコを増やしていきます。
1面の時と違って、システム面では色々と完成しているから、ゲーム本質部分を組み立てていくだけなので、1面を作っていた時よりは幾分か楽です。ただ、そのゲーム本質部分が問題なんですが。

ちなみに、SHOT値の導入により、レーザーをディスってしまわないように色々と工夫しています。
レーザーでの稼ぎ所もちゃんと作っておきたいと思っているので。
要は、レーザーを打てば弾消しができるので、弾を大量に吐く敵を作れば、そこがレーザーでの稼ぎ所になる仕様。なので、弾幕地獄を作れば割と簡単に実現できます。

とりあえず、ウィークデーに開発時間が確保できるようになったので、1日1~2匹程度のペースでザコを作って、今週末には二面の大枠を仕上げたい所。

最初の夏休みまでには3面ぐらいまでできていればベスト。
ちなみに、今年は夏休みが2回あるから、絶好の開発日和です。
夏場の開発はしんどいですが。

あと、ようやく体験版が海外でもDLされるようになってきました。
中東、米国、欧州、アジアあたりでワールドワイド且つ疎らな感じで。
ただ、VGSの一番のお得意様であるインドネシアのDL数がゼロでしたが・・・残念。
ちなみに、VGSのDL数1位は米国で、2位がインドネシアです。(日本は3位)
何故、VGSがインドネシアで好評(?)だったのかは謎。
音楽性が肌に合ったのかな?

2012年5月27日日曜日

2面を作成する前作業

本業の方が、労使協定の関係で、半強制的に時間を確保できるようになったので、開発作業を再開。
英国風に言えば、「本業が楽になら、副業を忙しくすれば良いじゃない」・・・でしょうか。
過労で倒れる前までには、SHOT04を完成させたいです。

しかし、2面を作成する作業に入る前に、色々と準備しなければいけないことがあります。
主に、ステージプラクティスの仕様を決めること。
2面以降をテストする上で必須なので。

私は、基本的に画面を描きながら仕様を考えます。
概ね仕様が纏まりつつあります。

まだ枠線などは書けてませんが、上図のような感じ。
ステージ単位でハイスコアとハイスコア取得時のリプレイを保存する仕様にします。
そして、リプレイボタンを押せば、ハイスコア取得時のリプレイを確認できる・・・という具合。
あと、画面遷移は煩わしいので、ランクと自機の選択は同一画面中でできるようにします。
リプレイはランク別には保存するとして、タイプ別に保存すべきか迷い所。
ランク別なら3×5=15パターンで済みますが、ランク+タイプ別だと3^2×5=45パターン。
1ステージ分のリプレイなら、大したサイズにはならないと思うから、問題無い良いかな?

対応機種

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円(税抜き)で販売しておき、体験版をインストールしてくれている方々にアップデートで製品版の完成を通知後、一定期間経過したら標準価格に引き上げるやり方が一番良いのではなかろうか・・・と、思案中。

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


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

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

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

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