2012年6月28日木曜日

最適な音源スペック

SHOT04(NOKOGI-Rider)の最終ステージの道中曲を作成中。
作曲ではなく、作成中。
曲自体は去年、ピスコラで作曲済みで、ピスコラ⇒VGS(自作波形メモリ音源)への変換するため、MMLを書き起こす作業中です。ピスコラだとテキストの楽譜データに変換できないのが痛いですが、大分慣れました。

最終ステージの曲は最大4声の対位法+ベースで作ったのですが、VGS(6チャネル)で全ての声部が収まりきらないから、目立たない声部をストレッタでぶった切って別の声部に繋げ直したりする必要があり、中々面倒。

ちなみに、
・4声の対位法⇒4チャネル
・ベース⇒1チャネル
・ドラムス⇒1チャネル
という割り当てにすれば、全部収まりますが、主旋律は際立たせる為に2チャンネル使うので、どうしても1声削る必要があります。

VGSを改造して声部を増やす(7チャネル以上にする)のは簡単なんですが、それは絶対にやらない。
漠然とした拘りのようなものがあります。
私がコンピュータで作曲を始めた頃、最初に使っていた音源がヤマハのYM-2203ですが、それの仕様が6チャネル(FM音源3チャネル+SSG音源3チャネル)でした。その後、YM-2608やMIDI音源各種(SC55ST, JV1010, SC8820, MU80, MU500あたり)を触ってきましたが、何だかんだで、聴くのも作るのもYM-2203の音楽が一番楽しい。恐らく、私の好きなゲームに一番合う音楽が、6チャネルぐらいのスペックの音源の音楽なんだろう・・・と思います。


だから、音源スペックを拡張するのはダメ。
音楽を音源スペックに合わせるのが正解。

2012年6月24日日曜日

3面

SHOT04(NOKOGI Rider)の3面の作成に入る前に、想定以上に蛇行レーザーの作成に時間を取られましたが、無事、作成に入りつつあります。

レーザーは、若干角度が粗い部分もあります。。。
とりあえず、許される範囲内に落ち着くことが出来たので良しとしておきます。
静止画で見ると粗さが目立ちますが・・・
あと、低難易度のモードだと速度が遅めな分、プレイ中にも若干粗さが目立つかも。

今の所、3面は大多数の背景を海にする予定。(陸もある)
1面=陸地メイン(海もある)
2面=ダンジョン
3面=海メイン(陸もある)
4面=基地

5面=中枢
という感じにするつもり。

ただ、単純にその状態だと3面が1面とイメージが被ってしまいます。
ステージ毎に特徴を作る為、敵パターンは基本的に刷新するようにして作ろうとしていたのですが、それでも若干目新しさに欠けるように見えたから、レーザーを頑張っておいた訳です。

2012年6月23日土曜日

Laser

敵のレーザーを作成中。
真っ直ぐ飛ばすレーザーなら簡単なんですが、ホーミングやカーブは若干面倒。

どちらにしても、回転機能が無いハードで実装する場合、先ずは回転パターンを作画します。
↓こんな感じで。
で、真っ直ぐ飛ばすだけなら同じラジアン値で連射すればOK。
普通の弾を飛ばすアルゴリズムでそのまま実現できます。
ちなみに、SHOT04(NOKOGI Rider)の敵弾は、1発毎に下図の構造体で情報を管理しています。
ただ、このデータ構造だと、
(1) レーザーを目標物(自機等)に向かってホーミングさせる
(2) レーザーをカーブさせる
といったことが実現できません※。
※正確には、不可能では無いけど複雑になり過ぎて処理効率が悪い

上記(1)(2)を実現するには、トレースというアルゴリズムを実装する必要があります。
トレースというのは、一番先頭のオブジェクト(リーダー)の動作情報(ログ)を記録しておき、サブオブジェクト(メンバ)は一定間隔過去のリーダーのログと同じ動作をする・・・というアルゴリズムです。


分かり難いですね・・・分かり易く言うと、
・ドラクエのパーティーの動き
・グラディウスのオプションの動き
・インストーラーがプログラムのインストールに失敗した時に、インストール前の状態に戻す動き
・データーベースでコミット済みの状態を変更前の状態に戻す動き(ロールバック)
などなど。
これらは皆、同じトレースです。
インストーラやデータベースのロールバックはバックトレース(ログを逆順に追跡)ですが、本質は同じ事。


で、トレースを実現するのには、ログ(ジャーナルともいう)が必要。
現状の敵ショットのメンバにログを持たせても良いですが、そうなるとメモリ効率が悪いし、メモリ効率を良くすると処理効率が悪い・・・つまり、別テーブルで管理するのがベストです。
とりあえず、下図のような感じのテーブルを追加。
まだ、肝心のプログラムを作っていないので、多分上記は何かデータが不足しているかも。
あと、ログはリングバッファで管理(256フレーム分)。
それで足りるかは不明。
事前に設計できなくも無いけど、作ってから調整。


ちなみに、リングバッファの場合、インデクスの加算処理で無駄な分岐によるパイプラインハザードを抑える為、要素数は2のn乗にする必要があります。(そうすることで、AND演算だけで限界時のループができるので)





【追記】
プログラムを作成してみました。
表示したみたところ、下図のような感じ。


ちなみに、テーブルの内容は結構変えました。
移動速度のログは残さない(加速しない)仕様にして、後は座標を最大の長さ分保持したり云々。
↓こんな感じで。(当初想定よりも大分シンプル)

/* 敵レーザー */
struct ELaser {
int flag; /* フラグ兼フレームカウンタ */
int ix; /* 初期X座標 */
int iy; /* 初期Y座標 */
short fx[32]; /* X座標(*8) */
short fy[32]; /* Y座標(*8) */
int len; /* 現在の長さ */
int maxL; /* 最大の長さ */
int R; /* 先端のラジアン値(0~627) */
unsigned char S; /* 速度(1~15) */
unsigned char itR; /* ラジアン値の変更間隔(フレーム数) */
unsigned char addR; /* ラジアン値の角度増減量 */
unsigned char typeR; /* ラジアン値の変更方法(0:変更しない, 1:右回転, 2:左回転, 3:ホーミング) */
short logR[512]; /* 角度ログ(512フレーム分) */
};


レーザーの長さはMAX=32にしておきました。
32×16=512ピクセルが最大長。これだけあれば十分。
あと、10度単位で回転パターン(36パターン)を準備したのですが、若干繋ぎ目が分かり易い・・・
ただ、これは気にならないレベルなので、まぁ良いかな。
8度単位(45パターン)にしてみようか微妙なところ。


ログのサイズは256だと足りないので、512に拡張。
速度&長さがMAXの場合に必要なログ数が32×16=512なので。
速度&長さがMAXなんて、鬼畜過ぎて使うことは無いと思いますが。


ちなみに、末尾~尻尾まで全てのレーザーが画面外アウトしたら消滅する仕様。
角度がキツ過ぎると、画面に戻ってくる場合があり、それは鬼畜過ぎるので、後で仕様変更するかも。




2012年6月21日木曜日

PowerUp

STGにパワーアップって必要なんですかねぇ・・・と、常々思っています。
で、実際にSHOT04は、パワーアップアイテム無しで作っている訳です。
しかし、STGにはパワーアップが有って当たり前という固定観念みたいなものがあります。

敢えて固定観念を捨てて、パワーアップに対して何を求めるかと考えて思いつくものは、
(1) だんだん強くなる成長過程を愉しむ
(2) 攻略を有利に進める
(3) 稼ぎ要素のひとつ(最高レベルの状態でPWアイテムを取得すると得点が入る等)
の3つぐらい。

上記は全て、無ければ無いで問題無い気がしています。
(1) ⇒ プレイヤーの腕前が上達していく成長過程を愉しめば良い
(2) ⇒ パワーアップが無い前提で攻略を有利にするパターンを探る楽しみがある
(3) ⇒ 他の稼ぎ要素があれば問題無い

寧ろ、パワーアップが有ることで生じるリスクも有ります。
・パワーアップアイテムを取得した時、攻撃力や連射速度を上げるケース
 ⇒ ミスによりパワーダウンした時の復活が厳しい
   (こういうゲームの場合、1ミスでゲームオーバーで良いのに・・・と思ってしまう)
・攻撃力は(殆ど)変えずに、拡散度を上げたり、当たり判定だけ大きくするケース
 ⇒ 狙って部品や敵機を破壊するのが難しくなる
   (個人的には、狙って部品等を破壊するのが楽しいと思っているので、これは結構致命的)

ノーパワーアップの方がスコアを稼げる仕組みにして、上級者(スコアラー)はノーパワーアップ、初級者はどんどんパワーアップして遊べるようにする・・・という案もあったのですが、「パワーアップアイテムをわざと落とす」というのは微妙だったので却下。
「わざとミスをする」とか、「わざとアイテムを逃す」というのはダメだと思います。
ゲームの本質(=競技性)と逆行してるから気がするので。
ミスはしたくないし、アイテムはなるべく取りたい。

2012年6月17日日曜日

2面完成

まだ、成分未調整の段階ですが、SHOT04の2面完成。
Ninjaの難易度が割りと酷い。
私がプラクティスモードで遊んでみても、結構な頻度でゲームオーバーになる。

でも、調整は後回しにして、まずは一通り完成させたいので、とりあえず3面の作成に移ります。


調整目標は、
・Beginner -> ノーミス・ノーレーザーでクリアできる難易度
・Soldier -> 安全にプレイすればノーミスが狙える難易度
・Ninja -> ギリギリ、オールクリアできる難易度
※全て私の腕前が基準。

まぁ、今回は携帯端末で作っているということもあり、色々な人にテストをお願いし易いので、低難度モードに関しては調整し易い筈。

2012年6月16日土曜日

ヘッドホン・イヤホン

新しいヘッドホンを購入。
DENONのAH-D1000というもの。
これまで、SONYのMDR-CD900STというヘッドホンを使っていたのですが、ちょっと暑苦しかったので。

ちなみに、イヤホンはKENWOODのKH-C711というのを使用してます。
そして、各ヘッドホン/イヤホンの仕様を比較して気付いたのですが、KH-C711が一番電力を食うっぽい?
インピーダンス音圧感度
MDR-CD900ST63Ω106dB/mW
AH-D100032Ω103dB/mW
KH-C71142Ω98dB/mW

インピーダンスというのは要するに抵抗です。
・・・物理は苦手なので、詳しくは分からないですが、一般的なヘッドホン(※ダイナミック型)は、電気の力で磁石(ボイスコイル)を動かし、その振動で音を鳴らします。そして、ボイスコイルの抵抗の大きさをインピーダンスと言うようです。

インピーダンスが高いほど、音を鳴らす(振動を発生させる)のに沢山の電気を必要とします。
その代わり、誤動作が少ないので、ノイズが少なかったり、音が鮮明になります。
つまり、高ければ高いほど、正確な音が鳴る可能性が高いと言えると思います。
なお、音の正確さは、物理ケーブルへの外的な刺激によっても変わるので、インピーダンスだけでは測れないところもありますが。あと、機器によって許容インピーダンスの範囲が決まっているので、極端なモノは使うと危険です(そういうものは、普通の家電量販店等には売っていないと思いますが、念のため)。

一方、音圧感度(NdB/mW)というのは、Nデシベルの音を出すのに必要な電力(ミリワット:mW)です。
つまり、100dBの音を出そうと思えば、
・MDR-CD900ST = 0.94mW
・AH-D1000 = 0.97mW
・KH-C711 = 1.02mW
の電力を要するという意味。
蛇足ですが、私の家の先月の消費電力量は87kW。
MDR-CD900STで100dBの音を約925532時間(だいたい105年ぐらい)鳴らし続けた時に生じる電力量という事かな?

音圧感度だけ見れば、消費電力の多さは、MDR < AH < KH という風になります。
ただし、それに対して、別途インピーダンスによる抵抗が介入します。
インピーダンスが半分であれば、音圧は3dB大きくなるとの事。

なので、単純なスペック比で見ると、以下のような結果になります。
- 音の正確さ: AH < KH < MDR
- 音の大きさ: KH < AH < MDR
- 消費電力量: MDR≒AH < KH 。

要するに、音圧感度&インピーダンスの両方を考慮しても、KH-C711の消費電力量が高い。
一般的にヘッドホンよりも、イヤホンの方が電力を食うものなんですかね。
直感的なイメージでは逆ですが。
・ヘッドホン=パワーのある機器に繋げる
・イヤホン=電池駆動のチープな機器に繋げる
なので。

それとも、KH-C711のインピーダンスが特別に高いのだろうか?
面倒なので調べませんが。
そもそも、音の良し悪しは、値(スペック)では判断できないし。
物理的な形状や、趣向(好み)にもよるので、一概には言えません。


KH-C711はカナル型イヤホンだから、敢えて高インピー+低音圧にしていると考えれば合理的かな。

2012年6月13日水曜日

動く背景

体験版のSHOT04では、背景アニメーションを一切無しでやっていましたが、3面を海ステージにしたかった&海背景が動いていないと微妙なので背景をアニメーションする機能を実装。
一応、1面の海背景部分でテストしてみました。

画像(静止画)では分かり難い・・・というより分かりませんが、ちゃんとアニメーションしてます。

背景を動かす処理自体は簡単なんですが、若干重い。
最大で画面(240x320)全体分のBGチップ300枚(15×20)をフレーム毎に描画することになるので。
1フレーム(約1/60秒)あたり、76,800ピクセル。

ちなみに、画面中にアニメーションチップがひとつも無い場合、1フレームあたり240~3,840ピクセル。
16フレーム毎の平均が1,920ピクセル。
つまり、画面全体が動く背景の場合、40倍の量のピクセルを描画する必要がある訳です。


まぁ、最近のCPUなら微々たるものですが。
ついでに、VGEの場合、純粋なメモリ処理のみでピクセル描画をする(ピクセル情報はメモリストアでそれを1フレーム毎に1回だけビデオメモリに転送する)ので、尚更全く気にならないレベル。
SHOT04は、Android 2.3が載っている全ての端末で処理落ちすることなく動作できるアプリにするつもりで作っているので、性能にはかなり気を遣わざるを得ません。

2012年6月12日火曜日

ペース

GW明けにSHOT04体験版をリリースした筈なので、約1ヶ月ちょっと経過か。
現状、2面ステージが完成し、2面ボスを作成中。
開発ペースは、概ね予定通り。
夏休みに纏まった期間でサクサクッと完成させて、リリースさせるのが夢ではなさそうです。

約1ヶ月経過ということで、体験版のDL数をチェックしたところ、700DL弱ぐらい。
想定よりも多いです。
ただ、有効インストール数は300弱。余裕の50%割れ・・・orz
ついでに、海外でのDL数はサッパリ。
多分、英語の説明文をかなり手を抜いたので、検索キーワードとかで良い感じにヒットしない為かな。

ちなみに、日本以外での有効インストール数は、中東方面に偏った感じ。
アラビア圏が5件、欧州圏が1件、アジア圏が1件。
当初期待していた米国は0件。

亜米利加人は、ドンパチするゲームは好きだろうと思ったのですが、やはり、FPSじゃないとダメなんですかねぇ。
だからといって、私がFPS開発に手を染めることは100%有り得ないことですが。

2012年6月11日月曜日

スコアシステム修正

現状のスコア算出方式ですが、ちょっと微妙だと思い始めました。
現状、メインショットの打ち込みが一定時間無かった時にSHOT値(MAX99,999)が10%づつ減少していき、その時の減少値を基点としたスコア加算をしてます。
しかし、この方式だと相当な変態的な稼ぎプレイが必要になってしてしまう・・・

上限に達した場合、一定時間フレームアウトを狙い、10,000を割り切らないようにしてまた打ち込みを続けるということを繰り返すと、スコアが高くなる訳です。(それを狙ってやるのは、かなり厳しい)

もっと直感的な稼ぎができるように修正するしかない。
狙いは、上級者のプレイを変態的にすることではなく、見ていて楽しいものにすること。
なので、稼ぎ方は直感的であれば、直感的である程良い(ハズ)。

2012年6月10日日曜日

耐えて忍ぶ者(要するにM)

2面中ボスが完成。
作画~プログラム作成まで一日掛り。
作画は例によって、DOGA先生が大活躍ですが、結構自分で描いたパーツもあったりします。
キャタピラとか、大砲とか。

低難度(Beginner/Soldier)でも、そこそこ苦戦するかも・・・という難易度にしておきました。
コレを倒せば1upするので、まぁ、良いかな。
難易度インフレは抑えたい所。

しかし、Ninja(最高難度のモード)については、リミッターを外しておきました。
まだ序盤ですが、色々と酷いので、きっと、上級者でも愉しめます。
もちろん、無理ゲーにはしません。
Ninjaに関しては、私がギリギリクリアできる難易度が目標。

ちなみに、難易度の名称(Beginner/Soldier/Ninja)ですが、Beginner/Soldierは適当。
Ninjaは一見すると外国人向けにウケを狙っているように見えるかもしれませんが、違います。
実はちゃんと考えあっての名称です。
まぁ、考えているとはいっても、フザけた考えですが。(記事のタイトル参照)

Music Room

作曲担当の鈴木が、SHOT04の2曲目のBOSS曲を作ったのですが、肝心の2面ボスがまだできていない・・・
音量調整用のデバッグ機能として、Music Roomを作ってみました。
これで調整できる。

ちなみに、作曲担当の鈴木の他に、音響効果担当の鈴木、グラフィック担当の鈴木、プログラマの鈴木の計4人に鈴木を使って平行作業をしています。このブログは広報担当の鈴木が書いているから5人か。5人とはいっても、時分割多重方式だから、常人の目には1人で作業しているようにしか見えないらしいです。

未だ作っていない曲は、ステージ5とボス3とエンディング。
実は、「作っていない」とはいっても、VGS用のMMLを作っていないだけで、作曲自体は済んでますが。
作曲自体は、去年作り溜めた曲と昔作った曲のアレンジが大半。
今年作った曲は、ステージ4の曲のみ。

腕が鈍るのもアレなので、ボス曲を3→5に増やしてみようか・・・と思ってますが、プログラム担当の割り当て時間を増やしたいので、その計画が実現する可能性は低いと思います。とりあえず、1面&3面をBOSS1、2面&4面をBOSS2、5面をBOSS3という具合にすれば、割と飽きずに音楽を楽しめると思っていたりもするので。(何よりも、作曲自体が完全に専門外だから、得意ではない)

ちなみに、ある方法を行うことで、製品版でもこのMusic Roomへ行けるようにしておきます。
私の音楽を聴きたい人など居ないだろうと思ったのですが、海外で割と評判が良かったので。
それでも、ニーズはそんなに無いと思うから、裏技にしておきます。

2012年6月9日土曜日

リプレイ圧縮

リプレイの圧縮ロジックの実装が完了。
試しに1面~2面途中までの実際のプレイデータ(9241フレーム)で圧縮率を測ってみたところ
・圧縮前:46,269byte
・圧縮後:16,401byte <圧縮前の約35%>
という感じ。

だいたい、1/3ぐらい。
zipのアルゴリズムで圧縮した場合、平均して圧縮前の90%程度に圧縮できたので、zipには全然及びません。
まぁ、簡単なアルゴリズムで圧縮しているので、この程度です。
もうちょっとネバってアルゴリズムを改造するか若しくはgzipにすべきか又は諦めるか・・・
まぁ、35%でも圧縮できた訳ですし、サラリと諦めてゲーム本編の開発を急ぐのがベストか。
あまり難しいアルゴリズムにして、変なバグを作り込むのもイヤですし。

ようやく中ボス(2面)

ようやく、SHOT04(NOKOGI Rider)の2面中ボスを作成できるところまで進捗。

2面のキャプチャを公開するのは初。
背景のテーマはダンジョンで。(BGMのタイトルもダンジョンだし)
面毎に一応テーマらしきものを決めて背景画像を描く方向。
・1面:いかにもシューティングっぽい感じ
・2面:ダンジョン
・3面:地球(海にしようか上級にしようか)
・4面:箱
・5面:まだ決めてない

問題は私の作画センス。
それでも、背景については外部素材を使わずに作ります。

機体類もなるべく自分で描いています。
ただし、デッサン力が追いつかない部分はDOGA頼みですが。
DOGAもなるべくなら使わない方が良いので、デッサンだけ流用させて貰って色は自分で塗り直すとか、自分で描いたパーツとDOGAのパーツを組み合わせるとかして、DOGA単体で描いた時の上手さをかき消す努力をしてます。

他人の素材を使うと、妙にツクールっぽい感じがしてツマラナイものになります。
別にツクールで作ったものがツマラナイという訳ではないです。
むしろ、ログインのSOFCOMとかは好きでしたし。

ツクールで作られたものは、デフォルト素材を使っているものが多い。
それらがどういう訳か微妙なものが多く、下手でも全部自分で作ったものを主体で使っているものの方が面白いものが多かった気がしています。「究極バカげ~む 超ステキ編」とか。

2面中ボスの作成に入る前に、リプレイデータの簡易圧縮保存をやる予定ですが。
zip圧縮でも良いのですが、コードが汚れてしまうので、独自アルゴリズムで。

2012年6月8日金曜日

ネームエントリー画面

開発中のSTG(NOKOGI Rider)では、ハイスコア保存時はネームエントリーしない仕様にしたのですが、リプレイを保存する時は、ネームエントリーする感じにしました。

で、ネームエントリー画面を作成。

こういうシステマチックな画面なら、キーボードやコントローラよりもタッチパネルの方が簡単に作れます。

名前の領域をタッチすれば直接、カーソルを移動できます。

「←」や「→」のボタンでもカーソルを移動できますが。
「カーソルのボタンなんて要らないのでは!?」

と思われた方は賢明です・・・作っている途中で気付きました。

でも、無駄なスペースが発生するのがイヤなので、残しておきます。
カーソルボタンを削除した分、別の文字(ハイフンとかアットマークとか)を入れても良かったんですがね。
ただ、「一番下の列は制御系」、「上4列は文字系」という形の方が様式的に美しいかと。

iPhone/Android比較

私は、開発上の都合でiPod touch(iPhoneの代用)とAndroidの2台持ちをしていますが、
「iPhoneとAndroidだと、どっちが良いの?」
ということを知りたい人のための参考情報を書いておきます。
こういう比較記事は掃いて捨てるほどありますが、一応、私視点ということで。

ちなみに、iPhoneとiPod touchはだいたい同じです。
Wikipediaに載っていた相違点は以下。

  • 音声通話やSMS、 MMSが利用できる。
  • HSDPA (W-CDMA) などにより、無線LAN以外のデータ通信ができる。
  • 近接センサを搭載している。
  • デジタルコンパスを搭載している(3GS以降)。
  • LEDフラッシュを搭載している(4以降)。
  • バイブレータを内蔵している。

あとは、RAMサイズが若干違ったりします。(iPod touch=256MB/iPhone=512MB)
電話用途以外であればだいたいiPod touchでも同じことができるという認識で問題無いと思います。

■アプリの安全性

割と「iPhoneの方が安全」という認識でまかり通っています。
が、iPhoneも結構微妙。

iPhoneのアプリは、Appleによる審査があります。
結構厳しいことで有名ですが、コードレベルでの解析が100%できるものでもありません。
なので、絶対に安全なアプリしか無いと思ったら痛い目を見ることになるかも。
レベルの低いクラッカーのアプリであれば、すぐに見つかって、マーケットから締め出されて終了ですが。

Androidのアプリは、審査に関してはザルです。
代わりに、マーケットから落とす時に必要な権限(パーミッション)が明記されています。
「ネットワーク通信する」とか「電話機のIDを読み出す」とか「通話をする」・・・などなど。
つまり、落とすアプリのパーミッションが問題無いかちゃんとチェックすれば、問題が起きることは無い筈です。
ただし、root化した端末であればパーミッションを無視して何でもできるからアレですが。
通常、root化した場合メーカー保障が受けられなくなるので、普通の人はまずやらないと思いますが。

iPhoneのアプリの場合、Androidのようなパーミッションの仕組みが無い分、危険。
Androidのアプリの場合、何も考えずにアプリをインストールすると、危険。
つまり、システムの安全性は、人的なシステムならiPhone機械的なシステムならAndroidに分があります。

■操作性

iPhoneだと1つしかボタンが無いから簡単。
Androidは3~4ボタンぐらいあるから若干複雑。
・・・という意見をよく見ますが、全ての操作が1ボタンで済む訳ではないです。。

Androidの3ボタンは、
①機能ボタン(アプリの各種機能を選択するためのボタン)
②ホームボタン(アプリを中断してホーム画面に戻るためのボタン)
③戻るボタン(アプリの操作を1つ前の状態に戻すためのボタン)
というものがあります。(実は正式名称は知らないので、正式名称は違うかも)

だいたい「どのアプリでも概ね共通する操作」があります。
iPhoneの場合、そういったボタンの配置がアプリによって区々なので、操作を覚えるのが面倒。
全てのアプリに共通する操作は「アプリを中断してホーム画面に戻る」のみです。

Androidの場合、上記3ボタンの範囲であれば、全てのアプリを同じボタンで同じ操作できる分、初めて触るアプリも概ね直感的に操作できる場合が多いです。

共通ボタン以外の操作性はアプリ依存。
なので、同じアプリであれば、操作性はAndroidの方が良いと言えると思います。


■ストレージ


普通の携帯電話は、外付けのSDカードをストレージとして使えます。
Androidも外付けのSDカードをストレージとして使えます。
iPhoneは外付けのSDカードが無いので、ストレージとして使えるのは携帯本体のメモリのみ。
なので、iPhoneで大容量のデータを扱う場合、無線LANディスクやクラウドが必須。

「SDカードぐらいついてて当たり前だろ?」
という風に思ってiPhoneを買った後でオワタ状態になった人を何人か知っています。
「よく調べてから買いましょう」ということかもしれませんが。
しかし、常識的に考えて有り得ないと思っていた時期が、私にもあります。
ただ、それでユーザの不満が爆発していないということは、許容範囲の事かな?という認識。

■どちらが良いか?

電話orメールしかしない人なら、ガラパゴス携帯がオススメです。
電池持ちが良いですし、余分な機能は何もついていないので。

アプリをガラケーと同じ感覚で使いたい人であれば、iPhoneがオススメです。
完全にガラケーと同じ感覚で使うと(アプリにできる事が多い分)ちょっと危険ですが。
先述のパーミッションの話が理解できる人の場合は、Androidの方がオススメです。

あと、「あくまでも個人の感想」ですが、個別のアプリの事情でいえば、

・2chをよく使う人 → Androidがオススメ
2chMateが便利です。(現状iPhone用には2chMate程使いやすいビューアが無い)

・ニコニコ動画をスマホで見る人 → Androidがオススメ
iPhoneだと、ブラウザからは見れないので専用アプリが必要ですが、専用アプリの使い勝手が悪い。
ブラウザの方が直感的に操作できます。
そして、Androidならブラウザから見れます。

・Caveシューティングをやりたい人 → iPhoneがオススメ
Android版は、種類が少ないし、対応機種が結構限られています。
ただ、Caveシューティングは結構電池を食うので、スマホよりもiPod touchでやった方が良いかも。

・ツイッターをやる人 → Androidがオススメ
私はツイートしない(ROM専)でツイッターを使っていますが、ガジェット(ホーム画面から記事を見ることができる機能)が便利。iPhoneだと、いちいちアプリを起動する必要があるので面倒。

便利さという面では、iPhoneよりはAndroidの方が良さ気。
あと、Androidでテザリングを設定すれば、iPod touchでも外出先で通信できるので、2台持ちにしたい人の場合、Android+iPod touch以外の選択肢は無いと思います。

追記(25-Sept, 2012):
iPhone5でテザリング対応したっぽいので、iPhone5+Zシリーズという選択肢が増えたかも。

2012年6月7日木曜日

dotエフェクト改善

SHOT04(NOKOGI-Rider)では、ドットでエフェクトを入れています。
かなり古典的な手法ですが、軽いし、パレットアニメーションすれば割と綺麗なので現役です。
下図だと、真ん中あたりのショットを敵に衝突させた時の衝撃波や、自機のエンジンから噴出している燃えカスなど、使い所を挙げればキリがない程度に使っています。

この座標管理を整数から実数に変更してみたところ、かなり疎らにバラけてくれるようになり、綺麗に表示されるようになりました。実数とはいっても、floatやdoubleではなくshortで固定小数点方式ですが。(実数は処理効率が悪い上に、メモリ効率も悪いから全く使っていないです)

使い所を挙げればキリがない程度に使っていたから、修正が微妙に大変でしたが。

2012年6月6日水曜日

実機ビルド

今日はあまり時間が無いので、ここまでできたシステム周りを実機(Androidのスマホ)で動かす為にビルド。
普段、VGEのエミュレータでしか動かしてなくて、それで99%問題無い・・・
・・・と、高を括っていたら、Android固有のバグを幾らか発見。

当然のことですが、やはりシステム周りを弄った場合は、十分に実機テストをしないとマズイ。
ゲーム本編もエミュレータ(@Windows)と実機ではだいぶ感触が違うし。
もちろん、一通り完成したら実機で叩きまくる予定なんですが、完成していなくても週1ぐらいで実機用にビルドして会社の休み時間などにデバッグすべきかも・・・Android用のコンパイルは無茶苦茶遅いから面倒ですが。

NDKとSDKのビルド+署名で1回のビルドにつき1分以上掛かるから、独自のエミュレータを設計して、それで動くゲームを作る開発環境にしないと、とてもじゃないけどゲームを作る気になれないレベルの遅さです。(ちなみに、Windows版VGE用のビルドであれば、差分コンパイルが1~2秒弱、フルビルドでも10秒前後のコンパイル時間)

単に、私が開発機に使っているマシン(Atom機)が遅すぎるだけなのかもしれませんが。

2012年6月5日火曜日

リプレイスロット=8

リプレイ機能の実装がほぼ完成。
あとは保存する時のネームエントリー処理を実装するぐらい。
ロード画面は↓こんな感じ。

リプレイの保存の仕組みはInvaderBlock2と同じ。
ゲームオーバー後にSAVE REPLAYを選択して、保存するスロットを選べばそこに保存されます。

ただ、保存できる数は、8個にしました。(InvaderBlock2は16個)
理由は、スマホの画面では16個だと細かすぎて押し難かったので。
代わりに、PRACTICEモードでは、難易度(RANK)、機種(NOKOGI-Rider)、ステージ別にハイスコア獲得時に自動保存するので、PRACTICEでの保存数は45個。

リプレイ機能に関しては、どちらかといえばゲーム本編の方はオマケ。
リプレイ機能の最大の目的は、PRACTICE用です。

しかし、Androidだと「ストレージ」という概念がLinuxと同じファイルシステムの仕組みで存在するから、ユーザ向けに「リプレイデータはxxxディレクトリに保存してますよー」的な情報開示をしておけば良い訳ですが、iPhoneだとそういった部分はどうなるのやら。まだ、iPhoneの開発環境の仕様は調べてないから、よく分かりませんが。(恐らく、iPhoneはストレージ周りがかなり弱いから、そこら辺で色々と仕様的にAndroid版と同じにできない可能性が高いと思っています)

2012年6月4日月曜日

難易度設計

本日は有給。
有意義に過ごしたかったので、ほとんど開発はせず。

プラクティス画面からリプレイ再生ができるようにした程度。
システム周りで未完成の部分は、リプレイ保存・再生画面ぐらいだろうか。
仕組みの今回はプラクティスのリプレイ再生やデモ画面(0.01から実装済み)と同じなので、大して難しいものでもないから、今日中には仕上がるかな。

という訳で、システム周りのところは概ね完成したっぽいです。
そこまでできれば、ひたすらゲーム本編部分を作り続ければ良い状態になります。

ゲーム本編部分は、2面途中あたりまで作りかけていたところでペンディング。
理由は、
①2面途中ぐらいまでできれば、システム周りの90%を完成できる
②システム周りはバグの作りこみリスクが大きい
(初期の内から完成させておき、本編を作りながら叩いた方が最終的な品質が高くなる)
③ゲーム本編の難易度調整がスランプ中
あたり。

要は現実逃避(③)で楽な作業(システム周りの実装)に逃げてる訳です・・・難易度設計は、難しい。
システム周りと違い、想定通りに作ることが難しいので。
難易度設計は、1面と5面であれば楽です。
・1面=お披露目用
・5面=最終防衛ラインなので(私の)限界を目指せば良い
という感じで目的がハッキリしているので。

とりあえず作ってしまい、後で鬼調整するという方法もありますが。
ただ、私の経験則ではそのやり方だと最終的なバランスが悪くなるから、今回はやらない。
第三者のテスターを確保してやったとしても多分同じ。
実際、市販品でも1面と最終面は絶妙なバランスなのに、中間ステージは微妙なものが多い。

2012年6月3日日曜日

謎スペック

前の記事で書いた集計情報の表示ですが、もちろん、カウントも同様です。

上図はデバッグ用に「GAME COUNT」の時間が有り得ない値になっていますが。

一番上の「TIME」は、ゲーム本編+プラクティスの合計プレイ時間。
「GAME COUNT」の時間は、ゲーム本編のプレイ時間(ステージクリア画面やエンディングは含まず)。
「PRACTICE COUNT」の時間は、ステージ別の練習時間。

「GAME COUNT」と「PRACTICE COUNT」の時間表示部分は、表示位置の関係で表示上限の最大時間が9,999,999時間59分59秒が限界。
ただ、時間は非符号32bitで秒単位で保持しているので、4,294,967,295秒が上限。
つまり、約1,193,046時間が限界。
1,193,046時間ということは、日数換算すれば約49,710日、年数換算すれば約136年。

136年ぶっ続けでやり続ければカンスト・・・ですが、カンスト処理は実装せずオーバーフローで0に戻るようにしておきました。プレイ時間が136年を超える場合、136年毎にノート等に正の字を書く等で記録するなりして、お楽しみください!!

・・・純然たる謎スペックですが、こういうジョークは嫌いではないです。

ちなみに、こういう所で、「どの仕様が最適か」という事を見極める技術は結構重要。
つまり、何処までを実装(プログラム)で、何処からを運用(ノートに正の字で記録など)でカバーすべきか。
まぁ、ゲームとはほぼ関係ない事ですが。

Totalize

SHOT04で、ローカルのプレイ記録を表示する画面では、
・RANK(難易度)別
・TYPE(機種)別
にランキングやデータを表示する感じでした。

しかし、全RANKの集計、全TYPEの集計が欲しかったので追加。
RANK+TYPE別、RANKだけ集計、TYPEだけ集計、RANK+TYPE全てを集計の4パターンが可能。
Tを押せば良いだけです。(起動時のデフォルトは、RANK+TYPE両方Tの状態)

上手くなってくると、ランクはN(Ninja)だけで埋められるんでしょうけど。
ただ、こういうのは、だんだんと埋めていくのが楽しいと思うので、スコアアタックゲームでは必須だと思います。(スコアボード専用のサイトとかなら普通にできることですし)

ただ、意外とやっているものは少ない。
東方でもやってないし、CAVEシューティングでも私が知る限りではやっているものは無いです。
もしかすると、作るのが大変なのかも。
別にそれ程難しいものでもなかったけど。(それでも、作るのに2時間程度はかかりましたが)

ちなみにRANK+TYPE両方のトータルだと、データは最大144位までありますが、17位以下は切り捨て。
全表示するにはスクロールが必要なので、かなり面倒。
面倒な割りに誰も得しないと思うので却下。

2012年6月2日土曜日

GameCenter

以前、iPhone版の虫姫さまのGameCenterのスコアボードがアレだと書きましたが、iPhone版の大往生のスコアボードは正常なようです。少なくとも、異常だと思える(=理論値を遥かに超えている)スコアの登録は今のところ無いです。

という訳で、スコアラーはおとなしく、虫さまではなく大往生をやるべきか。
虫姫さまは、稼ぎの仕組みがシンプルで好きでしたが残念。
虫姫さまのバグは仕方が無い・・・虫だけに。

iPhone版の大往生は、やり始めたばっかりなので、まだまだスコアは低いです。
現時点で86,915,770点。(A-type, Laser)
GameCenterでの順位も、まだまだ底辺(11,550人中、492位)。

母数が多いので、現在のスコアでも結構上位に見えるように錯覚しそうですが。
ただ、やり込んでいる人の割合は精々全体の2割程度だろうから、実質2,310人中492位。
私の脳内統計情報では、やり込んでいる人の5%(115位以内)に俳人になる素質があります。
なので、やるからには100位以内を目指したいところ。

下手をすると100位以内であれば、HELLではなくHARDの方が狙い易いかも。

大往生は、1周クリア時の残機ボーナスが高いので。
HELLだと、私の腕では1周ノーミスは無理だけど、HARDなら無理ではなさそう。


どうせ後でHELLしかプレイしない日が来るので、最初っからHELLで良い気もしたのですが、HARDだと無条件で2周目に入れるのがおいしい。(この仕様のお陰で、HARDに関しては捨てゲー率を0にできるので、効率良く腕を上げることができます)

あと、課金アイテムが色々あるようですが・・・必要なんですかね?
どうせやるなら、コンティニューで使えるクレジットを1クレジット10円ぐらいで10クレジットセットとかで課金販売すれば良いのに・・・と思ったりしました。ついでに、プラクティスでの練習にも1クレジット必要とかにすれば、上級者でも(というより、寧ろ上級者の方が)課金するだろうし、消耗品だから定期的な収入も見込めるんじゃないか・・・。

本体価格を0円にして、クレジット消費でプレイするゲーム(ゲーセンのイメージ)でも面白いかも。
ただ、それはやり過ぎ(某Gや某Dに間違われる恐れがある)かもしれませんが。
そもそも、課金=某Gや某Dというイメージすら有る人も居る様ですし。

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

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