2015年11月23日月曜日

いまさら、だけど Activity の遷移と終了について

ツールでもゲームでも複数の土台を持ちたい場合がありますよね。 土台というと分かりにくいけれども、例えば単純なゲームであるインベーダーやテトリスなら、 タイトル画面とメイン画面だけ用意すればいいですよね? でも、 Wiz(3D迷宮RPG) なんかだとタイトル画面、街滞在中の画面、3Dダンジョンの画面、戦闘画面、といくつか必要になりそうです。 Android でアプリを作る際には、 画面のデザインが異なる場合は、そのデザインパターンの数だけアクティビティーを作ります。 これが面倒なら、一つのアクティビティーで複数のレイアウトを使い回すこともできます。

アプリを複数のアクティビティーで分割管理することにはいくつかのメリットがあります。 まず、プログラムの構成がアカデミックな感じになります。 インデックスといいますか、大分類>小分類みたいな感じで、大量に発生してしまう Class(特定の役割を担ったプログラムの塊)を、 上手に仕分けることができます。 上手に整理すれば、どこに何があるのか分かりやすいし、機能を変更・追加する場合にしたって最小限の労力で作業を終わらせることができます。 整理がきっちりされている方が、バグや不具合が発生しにくいという側面だってあります。 それに、実際に使う部分だけのリソース(画像ファイルとか)を読み込ませることで、 マシーンの負担を軽減させることだってできる。 メリットはたくさんあります。

で、結局のところ、ある程度以上プログラムの規模がでっかくなりそうなときは、 素直にアクティビティーを複数作って、作業を分業化する方が効率的です。 複数のアクティビティーがあるということは、 アクティビティーの遷移と呼ばれる行為が必要となります。 これは、要するにアクティビティーAからアクティビティーBにジャンプするという行為です。 これによってAは後ろに下がり、Bが表に出てくるということになります。 これは、Android でプログラミングする際の超基本なんですが、ちょっとちょっと今さらながら、理解を深める必要があると思っている次第です。

finish() で現在、進行中の Activity を終わらせる。そう思っていた時期がオレにもありました。 と、いうか今まで当然のようにコレを行っていた。 が、しかし、Activity の終了を明示的に行わない方がいいらしい。 どういうことか? つまり、Activity の遷移だけ指示して、あとの終了過程はお任せしてしまうのである。

Activity には3つの状態がある。
実行中:表に出てきていてアクティブな状態
一時停止:表に出ていないが、一部が見えているケースもある
停止:バックグラウンドであり、見えない。システムによって終了させられやすい
一時停止と停止のときは、まだ完全には死に絶えておらず、変数なども破棄されていない。 メモリの余裕がなくなってきた場合は、停止状態のアクティビティーが優先的に廃棄される。 一時停止状態も場合によっては強制停止される。 つまり、メモリが不足してきた際に、自動的にアクティビティーを強制終了させるという 便利システムをアンドロイドさんが搭載しているので、終了過程は端末にお任せすればよいということみたい。 現に携帯は、ブラウザ、電話、メール、Playストア、YouTube、ゲームA、ゲームB、ゲームC、電卓、メモ帳…みたいな感じでいろいろなアプリを 同時並行的に使いますからね。こういう乱立状態の中で上手にメモリをやりくりしようという Google さんの知恵がシステムに反映されているようです。

で、Android のプログラミングをやってみようという入門書に必ず書かれているライフサイクルというものがある。 特定のタイミングで自動的に呼び出されるメソッドがあるから、そこで初期化とか終了処理とかするといいぜ、という奴である。 一発目の初回に起動させた時は、 onCreate()→onResume()の順で呼び出される。 終了するときは、onPasuse()→onStop()の順で呼び出されるし、 再開時は、onResume()のみが呼び出される。 アクティビティーを強制終了させない限りは、onCreate() の部分はショートカットされるようだ。 また、本当に強制終了されたときは、onDestroy()が呼び出され、 この状態からアプリを開いたらご丁寧に onCreate() からスタートするみたいだ。

onCreate() に記述する内容は最低限にしておかないと、 onCreate() の中身がスルーされてしまうかもしれない。 onResume() に記述しておけば、確実に実行されるだろう。 onCreate() や onResume() で変数の初期化を行うと、再開時に微秒なことが起こるので気を付けないといけない。 このあたりは、よくよく注意してプログラミングしないとバグを引き起こす元となりますよ。

再開時は、最後に開いていたアクティビティーから復活するのが基本です。 例えば、MainActivity→FieldActivity→BattleActivity という具合に遷移していって、 最後のバトルアクティビティーをやっている最中にホームボタンで中断したとしましょう。 このとき、BattleActivity から再開しようとするが、ここが finish() されていたら、一つ前の FieldActivity から再開されてしまう。 とにかく、 finish() を使ってアクティビティーを強制終了させると逆に混乱を産んでしまうので使わない方がよいだろう。

また、バックキー押したときの対応だが、一つ前のアクティビティーに戻るものの、 変数の初期化に失敗してチグハグなことになりがちなので、特にゲームではバックキーそのものを無効化してしまうのが最も簡単な解決策となるでしょう。

セーブと一時保存

ここまで書いているのは、あくまで一時保存からの再開です。 一時保存なので、保存の信用性はそれほど高くありません。 スマホの使い方によって個人差が著しくあるでしょうが、1ヵ月の間に1、2回程度はデータが消失するリスクがあります。 クリアまでに1時間以上かかるようなゲームであれば、セーブ機能を付けるしかないでしょう。 特に今の時代ともなれば、オートセーブが必須でしょう。

ただし、何でもかんでもオートセーブを小刻みにすればよいわけではありません。 例えばRPGで、絶対に勝てない状態から再スタートしたならば、プレイヤーは対策がないまま全滅を繰り返すしかありません。 将棋でいう「詰みの状態に入るより前」から再開できないと、やり直しようがないのです。 もし、20時間もプレイしたところでこの手の「セーブハマリ」に直面したら、プレイヤーの落胆は深く苦しいものになるでしょう。 哀しみは怒りへと変わり、「二度とやるかボケッ!」と吐き捨てて、アンイストールするにちがいありません。

あらゆる変数が、どのタイミングで初期化され、どのタイミングで更新され、どのタイミングで保存されるのか? と そこまで考えた上で設計するのが理想的なのだろうが、そんな細かいことできるわけねぇっ、と思わずにはいられません。

メモリーとヒープ

元々「男男女ダンジョン物語」の頃は、Activity の finish() をやりまくっていた。 これによって、オートセーブが実施される拠点にいるとき以外(ダンジョン探索中、会話イベント中、戦闘中)に 中断してしまうと、また拠点からやり直しというコトになっていた。 一回の旅路が5~10分程度で終わるものだから、それでもいいやと考えていたが、 いざ、中断復帰システム(アクティビティーを強制終了しないやり方)に切り替えたら、中断→再開がサクッとできるのはスゴイし便利だと思った。

finish() しまくるやり方は、プログラム技術が未熟なため、そうしていた面が大きいが、 メモリの解放という意味合いも無いわけではなかった。 メモリが不足してきた際に、自動的にアクティビティーを強制終了させると先ほど書きましたが、 これって「Aのアプリを実行中に、Bアプリの(そんなにいらない)アクティビティーを終了させる」ということではありません。 いや、そういうケースもあるのかもしれませんが、 「Aのアプリを実行中に、メモリが不足したのでAのアプリが強制終了する」ということが起こりうるのです。 いわゆる "out of memory" ですね。 これは、一般ユーザーの方も多くが経験をしていることでしょう。 一般ユーザーはエラーで落ちた場合、何が原因なのかまでは把握することはできませんが、 間違いなく「アプリがバグる原因BEST3」に入っている因子です。

今回、「アタックダンジョン MMF」では臨機応変に中断→再開ができる仕様を目指して、アクティビティーを殺さない「不殺」主義を貫きました。 しかし、開発が進展してテストでプレイする量が長くなってくると、、、早くも「アウトオブメモリー」による強制終了が出たあぁ! 困ったぁ。 largeHeap という技を使えば解決できるのですが、メモリの使用量を自力で抑える努力も必要だとのことで、なるほど、なるほど。 秘奥義「羅味曾父(らあじひいぷ)」を使わずに、現場の技術で何とかなるまいか? こんな開発半ばで秘奥義に頼るようでは、今後必ず追いつめられる…。
で…。
結局、アクティビティーが遷移するタイミングで用済みのアクティビティーをキッチリ終了させてやった方がメモリは解放できそうです。 実際にテストしたところ、finish() を多様するほど「アウトオブメモリー」を回避できるという結果が得られました。 というわけで「不殺」の誓いを早くも破る方向で、アクティビティーを殺しにかかります。

「ちょっと待てよ!」と、心の中から反論が飛んできます。 臨機応変に中断→再開ができる仕様を目指してたんじゃないのかと? そう、そうなんだけど…。 ただ、これは意外と簡単に解決できまして。 要するに onPause() 内で、特定の条件を満たした場合だけ finish() するように if で分岐させます。 特定の条件とは、正常なルーチンの流れでアクティビティーが遷移するときです。 だから、ホームキーを押して強制的に中断した場合などは onPause() が呼び出されても、finish() は実行されません。 あくまで、次のアクティビティーに切り替わったときだけ、finish() させるという構造です。 これによって「アウトオブメモリー」を回避しつつ、中断→再開も自由自在という無敵仕様が完成しました。 やればできるじゃん。

2015年11月19日木曜日

Wow... アイツが殺されたワケを知りたいって?

今回の記事は個人開発者である私が、 将来しくじらないように自戒の意味を込めて執筆します。
for me

最近、何が流行っているのかまったく理解していないんですけどね。 ネットで「君の目的は僕を殺すこと。」というアプリの記事を読んだので、 アプリダウンロードのページ(GooglePlay)に飛ぶボタンを押したら…
接続されない。
ちなみに、GooglePlay の検索で「君」と入力するだけで「君の目的は僕を殺すこと」と 出てきます。 これは、検索ワードとして有力であるという証…。 で、作者自身が「私はGoogleに嫌われたようだ」的なことを発言されていますので、 どうも消されたみたいですね。

以下に記す内容はすべて推測ですので、話半分で読んでください。

上記の人気アプリが Google から削除された理由は、 グーグルのガイドラインに抵触したからだと思われる。 キミボクiPhone版の記事がいくらでも見つかるので、そこからヒントを探したところ、 何が神の逆鱗に触れたのかは容易に推測できた。

広告を見ることに対して見返りを与えた

ゲームのメインキャラである魔人さんが「他の面白いアプリのビデオがあるんだけど、見ないですか?」 みたいなことを発言します。 で、CMを見たら本来は30分に1度訪れるフィーバータイムがすぐに訪れます。 30秒の広告動画視聴の対価がフィーバータイム獲得なのです。 フィーバータイムとは放置ゲームでよく使われますが、いつもより大量にゴニョゴニョをゲットできるぜ! というタイムサービス(サービスタイム?)のことです。 業界用語で言えば、リワード広告の一種であるとカテゴライズできますね。

レビューに対して見返りを与えた

魔人さんが「あなたにお願いなんですけど、ゴニョゴニョフガフガってレビューに書いてくれないかな? お礼はさせてもらうよ」みたいなことも発言します。 実際は、ユーザーがレビューを本当に書いたのかを追跡するのは技術的に困難なので、 レビューページに進んだら「レビューを書いたという扱い」になると思います。 つまり、ボタンを押してリンク先に移動した時点で報酬が発生します。 それはさておき、お礼が欲しくてレビューを書くユーザーはいくらでも存在することでしょう。 お礼は定番のコイン(ゲーム内通貨)みたいですね。

放置ゲームの収益性が高いと言われる理由はよく分かります。 放置ゲームの基本は何もしなくても、進行すること。 だから、やることがないから広告をタッチしやすい! こんな単純な理論で終わるつもりは毛頭ありません。

放置ゲームでは世界観が重要。 ユーザーは続きや先が気になって、進行を早めるために操作します。タップだとかスワイプだとか、連打であるとか。 タップやスワイプによって、何もしなければ1分かかるところがググッと短縮されて、10秒とか5秒になります。 この、何らかの介入を行うことによって時間を早めている錯覚を起こさせるところが、放置ゲームの妙技と言えましょう。 要するに、広告を見るのも、レビューを書くのも、介入の一種なわけです。 ゲーム感覚で広告を見るのです。 レビューを書くのです。 介入によって時間を圧縮するのです。 「誰にでも平等であるはずの時間」、これを意図的に操作するという神の気分を味わえるのが魅力なのです。

(割とどうでもいい内容の)ビデオやDVDを見るときに、「早送りできるかできないか」というのは超重要です。 早送りができなければ、見るのが苦痛で途中でやめてしまうレベルのものでも、早送りができれば興味のあるところまで進めればいいだけなので、ぜんぜん楽しめます。 おもいっきりエロビデオの話ですが。

脱線しすぎたので、話を元に戻しますが、Google さんは「報酬をあげるからチョメチョメしてよね」というやり方を嫌います。 まずは、「広告を見ることに対して報酬を与えた」の件ですが、 「水着で鬼ごっこ~ポロリもあるよ~」などの広告を見ることでゲームが有利になるタイプのアプリが無事であることから考えるにセーフなのではないかと。 2015年11月現在、インタースティシャル広告に関しては細かくメスを入れてきているみたいですが、 エサをぶらさげて広告を視聴させることはグーグルさんは容認している。 その一方でレビューを誘導する方の問題はどうなのでしょうか? 以下は Google Play デベロッパー プログラムポリシーからの引用です。

● デベロッパーは、不正なインストール、レビューや評価に対する報酬やレビューや評価の捏造といった不正な手段や~(中略)~よって、 ストア内でのプロダクトの掲載順位を変更しようとしたり、プロダクトの評価やレビューを操作しようしたりしてはいけません。

レビューや評価に対して報酬を与えることにはレッドカードのようです。 つまり、「このアプリのレビューをしてくれませんか?(報酬は何もなし)」なら問題ないのでしょうが、 「このアプリをレビューをしてコインをゲットしませんか?」だとポリシーに引っかかるということです。 これが、「君の目的は僕を殺すこと。」のAndroid版が惜しむらくもプレイストアから削除された顛末です。

2015年11月15日日曜日

Android アタックダンジョン MMF 開発記<起・参>

(タテ)と(ヨコ)の操作性を考える

オリジナルの「男男女ダンジョン物語」は横固定画面(landscape)でした。 横固定画面だと、(床に置いていない限り)両手で持つしかないので、 デザインは楽です。 スマホを横向きで両手で持ったら分かると思いますが、 右手の親指と左手の親指でスクリーン上の全領域をカバーできます。 つまり、どこにボタンを配置しようが「押しにくい」ということはないのです。 タブレットまで考えると、レイアウトはなめちゃいけないんですが。

↑ Landscape

横画面両手持ちは、サッカーのゴールにキーパーが2人いるようなものです。 2人いるだけに、すべての領域をまんべんなくカバーできます。

で、今作っている「アタックダンジョン MMF」は縦画面固定(portrait)です。 縦画面の操作は次の2パターンがあると思います。
・片手で持って、反対の手で操作する
・片手で持って、持ち手で操作する
どうせ縦画面にするのなら、後者でしょう。 右手にコーヒー、左手にスマホ。 左手にタバコ、右手にスマホ。 右手が吊革、左手がスマホ。 人生には、片手しか使えない場面も多々あります。 ただし、片手で持って操作するためにはボタン配置を寄せないとダメです。 押さないといけない場所がスクリーン全領域に点在していたら、 縦画面である魅力は半減し、マイナスばかりが目立つようになります。

↑ Portrait

普通片手でスマホをタテに持てば、デバイスの下の方を持つ形になります。 その際にフリーになるのは親指でしょう。 で、親指が無理なく楽に動かせる範囲というのは、画面下半分の領域と言えましょう。 文字入力する際にテンキーみたいな疑似キーボードがでてくるでしょう。 アレの範囲っていうのがだいたい画面下半分ですからね。

縦と横のどちらにもメリットとデメリットがあるので、一長一短です。 ですが、ゲームの場合はカテゴリによってどちらを選ぶ方が無難か? という傾向はありそうです。 アクションやシューティングの場合はスクロール方向が縦・横どっちなのかという方が重要になりそうなので、ここでは割愛します。 RPG の場合は、縦横両方ありますが、縦の方が主流の気がします。 やはり時代は気軽に、手軽に、ポチポチ系なのか??? ソシャゲも一周回って古くなってきた感がありますが…。

でも今回、わざわざレイアウトをいじる手間を犯してまで縦画面に変更した私である。 何だかんだいってタテの方がいい理由があるんじゃないの?
 ああ、そうだ…。
タテ型だと画面底部にちょうどいい「広告枠」がある。

デザインっていうのは「見る枠」「操作する枠」「遊びの枠」「広告の枠」、すべてを見据えて行わなければならない。

2015年11月7日土曜日

Android アタックダンジョン MMF 開発記<起・弐>

「アタックダンジョン MMF」製作中です。 公開は目指せ2015年12月10日。

徐々に製作中のアレやコレやを小出しに見せていくことで、 アプリの宣伝になればええなぁ、という淡い期待を抱いて年内は開発記を続けてみたい。 どの色好きなの? ということで、キャラクターの紹介です。

白の魔女「スノー」
氷の魔法を極めた熟女。欧米人は老けて見えるから、意外と若いかもしれないが…。 メンバーとして連れて行けば頼もしい味方として大活躍してくれることだろう。 初期装備はマナの帽子。
黒の魔女「バリ・バラ」
エキゾチックな呪術師。魔法使いは基本的に魔抵抗の値が高いが、彼女は最大値を持ち、敵の特殊攻撃を受け付けない。 初期装備は魔除けの帽子。
赤の魔女「スコーピオン」
悪魔族の魔法使い。デビルレディーですね。赤LV7魔法、エナジーフレアは超強力。しかし、青LV1のシールドを受け付けない体を持つので、 ガードが弱いという欠点を持つ。角が生えているが、これが頭装備扱いとなる。もちろん、換装はできない。
青の魔女「ローティー」
青枠はエルフの設定です。スコーピオンと同じくエナジーフレアを使えるが、下位の赤魔法をほとんど習得していないというお茶目な一面も。治療系の青魔法は得意。初期装備は月光の鉢巻き。
黄の魔女「ヒョウ」
黄枠はダンマスでいうところのイアイドー枠ですね。タランティーノとかリュック・ベッソンが描くデタラメなジャパニーズ・ニンジャ・ゲイシャ・スパイス・ガールに仕上がりました。 ただし、刀を持っているのは伊達ではなく、魔女の中では唯一物理攻撃で敵を切り刻める。肝心の魔力はふつう。舞踏会の仮面によって素早さが激アップしているが、消耗アイテムを装着することができない。
緑の魔女「アピ」
マレー語で炎を意味する、だったと思う、アピさん。最初の予定では、緑枠はアース・サンダー、アース・ウインド、アース・ファイアの3人にするつもりだったのですが、名前短い方がいいよね、欧米系の命名体系は半分までに抑えた方がいいよね、などの考えから「雷」「風」「炎」をマレー語に変換する作戦に変更しました。頭の形が人間と異なるので、専用装備です。

6人もそろえばお祭り騒ぎ。ハロウィンっぽくていいですね。えっ? 何か既視感のあるキャラがいるって? き、気のせいじゃないのかなあ…。

2015年12月XX日(予定)まで待てないよ、という人はこのアプリで長い夜を過ごしてみてはいかがでしょうか? 「アタックダンジョン MMF」 の元になっている作品です。
「*男男女・ダンジョン物語*」

2015年11月3日火曜日

Android アタックダンジョン MMF 開発記<起・壱>

性懲りもなく、また新作アプリの作成を始めました。 が、しかし、まったく新しいのをゼロから…という気力も時間もないので(時間はあるけども)、 よくあるリフォームというか、リユースというか、画像やプログラムといった過去資源をこれでもかっ、と使い回します。

パクリ元は自作品なので問題ないのですが、「男男女ダンジョン物語」というRPGです。 この作品の欠点である「長い・複雑・バグりやすい」、少なくともこの3つを徹底的に改善します。 ゲーム性というかゲームジャンルすら別物になるわけですが、まあ、これで行こう! というアイデアが閃いたものですから。

簡単に言うと、パズドラスタイルの簡単ダンジョンBOSSを「18人いる勇士から3人を選んで倒そうね」というゲームです。 そう、この任意に3人を選ぶという部分でこのゲームの(戦術性の)およそ大部分が説明できます。 プレイヤーに求めるものが何なのか? が、明確かつシンプルなのが特徴です。

例えば巨漢で体力のあるBOSSと対峙する場合、さっさと倒したいので攻撃力を重視してメンツを選びます。 状態異常技を得意とするBOSSと戦う場合は、そういった攻撃に耐えられそうなメンツを選びます。 また、道中の雑魚が非常に激しい物理攻撃を喰らわしてくる一方、BOSSが即死攻撃メインである場合は 「防御力」+「即死攻撃対策」の両輪でメンツを選ばなければなりません。

よくある属性のアレとは違います。 アレだとBOSSと相性の悪い属性を選んでしまうと、まったく勝ち目がありませんから。 必然的に、BOSSに対してアドバンテージを取れる属性を選ぶことが「誰の目にも明白な最適解」となります。 これだと、「○○ダンジョンはグー属性のBOSSだから、我々はパー属性の戦士でいこうか」ってな具合で、単純すぎて考える余地がありません。 だいたい、火属性が水属性攻撃に弱いといっても、 現実世界の火事ありますね。 電気火災や油火災の場合は水を使うな、というのが常識ですからね。だから、何? っていう…。

1枠(白の勇者/スタンダード)総合力が高く、欠点がない。無難な感じ。装備はイカスが、消耗品を所持していない。
2枠(黒の勇者/エキゾチック)ハードでタフな防御・耐久性重視の勇者。火力はやや低めか。
3枠(赤の勇者/悪魔族の亜人)最大の攻撃力を誇り、かつ吸血剣も持つが、防御魔法をかけることができないという欠点を持つ。
4枠(青の勇者/エルフ枠)高い魔力と独自の秘薬を持つ。
5枠(黄の勇者/ニンジャ芸者枠)特殊装備の補正によって意外と能力に優れるが、アイテムの使用・装着ができないという欠点を持つ。
6枠(緑の勇者/獣人枠)能力が低く使いにくいが、アイテムを過剰に所持しているため、アイデア次第で爆発力を持つかも。
と、いう感じで1~6枠まで特色があります。1枠に近いほど、単純に基本能力の合算値は高くなります。

1回、BOSSと戦えば「このBOSSは短期決戦で倒さないとこちらが不利になるみたいだから、1-3-5あたりかなあ」とプレイヤーが考えてくれれば助かります。 で、だいたいその予想は大きくは外れてはおらず、最終的に微調整が起こりますが、1-5-3あたりでBOSSを仕留めるはずです。 慣れてくれば、メンバー編成だけでなく戦闘中の戦い方にも工夫をこらしたものになるでしょう。

で、普通の遊び方としては各ステージBOSSをメンバー編成を考慮しながら撃破していく、というものになります。 BOSSのステータスや攻撃パターンを踏まえたうえで、最も有利に戦える編成を考えます。 いわゆる監督の仕事ですね。 勇者枠・戦士枠・魔女枠というのが決まっており、同色のメンバーは重複できませんので 6x5x4=120 通りのパターンがあります。 いわゆる競艇の3連単ですね。 各キャラクターに成長の要素はありません。 パズル的と言えばパズル的ですね。

しかし、変態的な考え方で行くと 「○○ステージを6-5-2」とかで突破できんかな? とも思いを馳せます。 つまり、奇をてらったメンバー編成による強硬突破作戦です。 基本的にボートレース(競艇)の3連単を意識してもらえばよいと思いますが、4~6枠は入りにくいです。 そりゃ、1-3-4 とか 2-5-3 とか 5-1-2 とかはありますけど、6-4-5 とかは絶望的にないですよね。反対に、2-1-3 あたりは低配当ガッチガチですが。 そこは逆にあえて高オッズ、高配当となるような組み合わせで「冒険してみる」のもこのゲームの粋な遊び方です。

で、もし、「○○ステージを6-5-2」でクリアしたのはあなたが世界で一番最初です、おめでとう、記念品を贈呈します。 とでもしたら、熱くなりますね。 ちょっとだけソーシャル要素を入れてみようと思います。せっかくのスマホゲーですからね。 サーバーで、○○ステージはどんな組み合わせで攻める人が多いのか? 等も集計できます。 その集計結果をふまえて、予想屋(ゲーム内キャラ)に「そのメンツで行くのかい。 あなた意外と堅実だね」とか 「そのメンツで行くのかい? あなた、ぶっ飛んでるね」とか喋らせるのも面白そうですね。

新作はオリジナルの「長い・複雑・バグりやすい」の3点を改善できたかと思います (まだ楽勝で完成していないんですけどね)。 最近ちょっとAndroidアプリのゲームなんかをちょくちょくやってみましたが、クリアするまでの時間は1~5時間くらいが適正な気がしますね。 で、1度クリアして満足サヨウナラ、の人もいれば、納得いくまで何回も、という人もいる。 そんなバランスが理想的な気がします。 とりあえずBOSSofBOSS(ラスボス)のダンジョンが解放されるまでに6ステージクリアが条件、 各ステージは5~20分程度で突破できるとして、エンディングまで計2時間。そんなボリュームを目指します。

装備の概念があるにはありますが、基本的に各キャラ固定装備です。 また、ダンジョン探索部分に関しては完全にオート。プレイヤーは操作できませんし、する必要もありません。 プログラムも当然、簡易的になってきて、 オリジナルにあったパッケージの1つをゴッソリ消去することができましたし、いくつかのクラスは不用になったのでまるごと処分できました。 これによって、処理が軽くなっていますので、バグも減るはずです。