ワイドだろぉ～？

世の中には「物理キー」と「ソフトキー」と呼ばれるものがあります。
「物理キー」は普通のボタンだと思ってください。押してへこんだら作動する昔ながらのスタイル。 指先の感覚で押したことがハッキリわかること、液晶が付いていない状態でも押せること、などがメリット。 故障しやすい、防水が難しくなる、生産コストが高くなる、などがデメリット。
「ソフトキー」は液晶上に表示されるタッチ操作に反応するキーですね。 android 端末では「ホームキー」「バックキー」「メニューキー」が標準的ですね。 メリット・デメリットは「物理キー」の真逆であるといえましょう。
iPhone は「物理キー」ですね。 iPhone のパクリだと言われた GalaxySC-02B なんかも「物理キー」ですね。 2012年以降の android 端末は「ソフトキー」が多いですね。 Google さんは「ソフトキー」を推奨していますね。
以上の予備知識をふまえたうえで下記をお読みください。

普通さあ、800x480 (10:6)と1280x720 (10:5.625 = 16:9)を比べたら、後者の方が横長だと思うじゃないですか。 パソコンや液晶テレビなら文句なく、後者の方が横長のディスプレイなのですが、 ことスマホの世界においては「当たり前が通用しない」。

上の画像は Eclipse のDDMS によるスクリーンショット。800x480。

上の画像は Eclipse のDDMS によるスクリーンショット。1280x720。

上の画像は Eclipse のDDMS によるスクリーンショット。2560x1600(タブレット)。

ちょ、ちょっと待てよ、10:6 のメイン画面の横にソフトキーを配置して、そりゃもちろんソフトキーも液晶の一部だから、 それに異論はないが「ディスプレイのアスペクト比 16:9」ってマジで言ってんのかい。 実質、絵が描画されているエリアは 10:6 じゃないか？？？　、 最近の動画はワイド画面の 16:9 が多いのでそれに対応したディスプレイですっ、って嘘言いなさいっ、と思ったら You Tube で LandScape（横向き）にしたらソフトキーの部分も消えて横マックスで絵が表示され、 正真正銘の 16:9 となりました。なるほどぉ

勉強不足でよくわかりませんが、と、いうことはソフトキーを消し去って フル描画させることも可能なのかもしれません。 しかし、そんなことをしたらユーザー様から「ホームキー」「バックキー」「メニューキー」を押すことができなくなるので、 不便きわまりないクソ仕様だと文句の一つも言われることでしょう。

まあソフトキーはいざってときに自らの姿を消すこともできる忍者みたいなやつですよ。 器用ですね、未来的ですね。 その代わり、押しにくい、押しにくい、押しにくい、と世界中でブツブツ文句を言われているみたいです。 どっちがいいとかそういう話ではなく、アプリ製作者としては（知識として、デザインの要素として） 押さえておかなければならない重要なポイントでした、ね？

音の迷宮事件 Xperia と SoundPool

１月冒頭の記事（これの２つ前）で、ディスプレイのアスペクト比が変わったらどうのこうの… と心配していましたが、実機で確認した結果は問題なしでした。
SC-02B(4.0 inch)(800x480 比率1.67倍)
SO-02F(4.3 inch)(1280x720 比率1.78倍)
F-02F(10.1 inch)(2560x1600 比率1.6倍)

LC-20DZ3(20 inch)(1366x768 比率1.78倍)＜シャープの液晶LED/TV＞
PSP(4.3 inch)(480x272 比率1.76倍)＜ポータブルゲーム機＞

参考までに家にあったスマートフォン以外のディスプレイも調べてみました。 Xperia は20インチテレビとほぼ同等の解像度。 Arrows のタブレットは余裕で20インチテレビをぶっちぎっています。 まあ、そんなことより重要なのは縦横比が 1.6～1.78倍という限られた範囲で推移しているということです。 android でアプリを作る場合は様々な機種に対応するように配慮しなければなりませんが、 かといって 1200x600 みたいな存在しないケースは無視してしまって構わない。 あくまで実勢の範囲内で適合させていく努力が必要ということです。 まあ、私はまったくやったことありませんが iPhone でのアプリ開発の方がその点では楽勝ですね。

で、機種毎による違いというものはディスプレイ関係だけではすまない。 実際に実機でテストしてみると「はぁ！？」という事態がときどき起こり得ます。 今回は音の問題です。

SoundPool というものを使って効果音をだしていました。 10秒未満な短い音を同時多発的に出していく場合に有効な手段です。 で、去年まではデバッグ用実機としてギャラクシーしかありませんでしたから、それで音が鳴れば「よっしゃよっしゃ」と開発を進めていた次第です。 で、今回 Xperia と Arrows で実機テストを行った際、Arrows では問題なく音が鳴りましたが、 Xperia だと音がちっちゃい。「えっ？」って思いますよね。

そもそも SoundPool で鳴らされる音量はどうやって決まるのか？

streamID = sp.play( seID[1], volLevel, volLevel, 1, 0, 1.2F);

たしかに↑でいうところの volLevel には 0.1～1.0 の変数を入れ込みます。 これによって音量が変わる仕様です。 で、0.1～1.0 まで数値を変えたら出力されるボリュームが段階的に変わるのか？　といったら、う～ん、という感じです。 まあ、これはちょっと置いておいて、ベースの音量というものがあります。

sp = new SoundPool( 8, AudioManager.STREAM_MUSIC, 0 );

↑みたいな初期設定を onCreate() あたりで行いますが、STREAM_MUSIC、要するに音楽やゲームで使われる音量がベースとなります。

sp = new SoundPool( 8, AudioManager.STREAM_ALARM, 0 );

↑みたいにすれば、STREAM_ALARM、アラームの音量がベースとなります。 いずれにせよ SoundPool を利用する際は何らかの音源（他には電話音量 STREAM_RING なども）を拠り所にしています。

とりあえず Xperia で音が小さかったので音を大きくしてやろう。 いろいろ試した結果、 play の前に

AudioManager am = (AudioManager)getSystemService(Context.AUDIO_SERVICE);
int max_volume = am.getStreamMaxVolume(AudioManager.STREAM_ALARM);
am.setStreamVolume(AudioManager.STREAM_ALARM, max_volume, 0);

このようにすればアラームの最大音量を取得しセット、それを play に適用しますから大きな音で SoundPool が鳴ります。 なぜ、STREAM_MUSIC ではなく STREAM_ALARM にするかというと、 bgm をメディアプレイヤーで鳴らしており、それの音量が STREAM_MUSIC に由来しているからです。 つまり、STREAM_MUSIC を下手にいじれば bgm に干渉してしまう、だから、STREAM_ALARM を使ってみました。 勝手に（ユーザー端末の）アラーム音量をいじるわけですから、用が済んだら元のアラーム音量に戻しておくのはマナーとして忘れずに。 とにかく、このやり方だと Xperia でも音が大きく鳴りました （最終的にはMAX音量から -1 した値で音量セットするようにしました）。 しかし、Galaxy や Arrows で試したらばかでっかい音が鳴ってしまう。うるせぇ！

本当にいろいろ試しました。試行錯誤といやつでしょうか？　まず考えた大筋はユーザーに効果音量を設定させて、 その設定を保存しておく、というものでした。 なにせ、３機種でしか実機テストを行っていませんので、他の端末ではどうなるのかは分かりません。 だから、ユーザー側で任意に調整できるようにしておくのが親切かつフレキシブルだろうと判断しました。 できたら、１～５段階くらいの効果音設定をしたかったのですが、いろいろ試した挙句、
極小＜＜＜＜＜適音（やや小さめ）＜適音＜適音（やや大きめ）＜＜＜＜＜爆音
みたいな感じにしかできなかったので、「強・弱」の２段階設定に落ち着きました。 つまり初期設定は弱であり、Galaxy と Arrows だとこれで普通に効果音が聞こえます。下手に強にしてしまうと 爆音地獄になりますが、すぐにユーザーは元の弱設定に戻すことでしょう。 Xperia だと初期設定ではもろもろの効果音がとても小さく再生されます。 これを強に変えると適当な音量に落ち着きます。

        if(Otsu4Activity.seVolLevel==0) {
            sp = new SoundPool( 8, AudioManager.STREAM_MUSIC, 0 );
        } else {
            sp = new SoundPool( 8, AudioManager.STREAM_ALARM, 0 );
        }

↑こういう感じで強設定なら STREAM_ALARM でいき、弱設定なら STREAM_MUSIC でいきます。 弱設定の場合は道なりで行くので、SoundPool の音量は STREAM_MUSIC に比例します。 つまり、BGM の音量にリンクします。 しかし、STREAM_MUSIC　のボリュームが 10以上になると爆音領域に突入するので STREAM_MUSIC　のボリュームが 10以上の際はボリューム 9 という扱いにしています。

なかなか仕様書どおりにはいきませんねえ、という話でしたが、 Galaxy と Arrows ではまったく同じ挙動を示したので、 おろらく Xperia 以外の機種だったら弱設定でうまくいくのではなかろうか？　と思います。 ググったら Xperia で SoundPool を処理させる場合に不具合がでやすいみたいな記事をいくつか見かけました。 真相は分かりませんが、こういった端末間における（予期せぬ）再現性の違いというものが Android につきものなのは 間違いなく、iPhone でのアプリ開発の方がその点では楽勝ですね。

大苦労、タブレットでUSBデバッグ

毎日毎日、通勤の通り道などで煽りのポスターを見続けたからでしょうか？　時間をかけてジワジワとすっかり洗脳された私は スマホの機種変＆＆タブレットの新規契約もしてしまいました。 旧機種もシムカードは抜かれるものの返してくれるので、なんと３台ものデバック用実機を持つことになったわけです。
Sumsung SC-02B (Galaxy)
Sony SO-02F (Xperia)
Fujitsu F-02F (Arrows Tab)

それにしても、電話・メール・インターネットという通信機能を失ったスマホは純粋な（？）ゲーム機として生まれ変わりますね。 私の場合は目覚まし時計として旧機種がなお活躍しています。 いや、カメラだってあるし意外と多機能モバイルマシーンな感じですね、シムカードを失っても…。

ちょっと余談ですが、私がSC-02Bを買った３年前は「サムスンの機種が圧倒的に優秀」 「アイフォンと戦えるのはギャラクシーしかいない」という評価であり、 エクスペリア（とその他大勢の日本勢）はもっと頑張れ、という風潮でした。 しかし、最近はソニーエリクソンからソニー直下に開発を移行して、国内のみならず海外でも高い評価を受けているようです、 Xperia が！　実際、性能がそんなに変わらないのなら、防水・防塵ありでメタルボディーの Xperia の方が、 プラスティックボデーの Galaxy よりもいい感じです。

旧が Galaxy SC-02B(Android 2.2)だったのですが、更新した5インチと10インチの新機種たちはともにバージョン 4.2.2 です。 で、USBデバッグの手続きをするのが実に3年ぶりくらいだったので、かなり手こずりました。

まずは携帯電話の Xperia の方からやりましたが、 覚えているのは携帯端末の方で「正体不明のアプリをインストールする」「USBデバッグを行う」の２つを有効にしておくこと。 ただし、どーもデバイスドライバ（PCの方にインストールさせる制御用ソフトウェア）をダウンロードさせないといけないみたいです。 この辺はソニーの機種の場合は、USBでスマホとPCをつないだら勝手にやってくれましたが、 なんかインストール成功？失敗？、よくわからん…という状態が続いてなんかよくわからん（２時間くらい迷った）うちに Eclipse側からの run ができるようになりました。

日をおいて今度は10インチのタブレットの方に挑戦。富士通の Arrows ですね。 で、こっちはいきなりバグった。 と、いうのも「USBデバッグを行う」の項目がいくら探してもでてこない。 ググって調べているうちに Android 4.2 以降？　は仕様で初期状態では「開発者オプション」が表示されないみたい。 で、その解除の仕方が「設定」＞「タブレット情報」と押していって「ビルド番号」のうえを７回アタタタタタタタッ！と叩いてやると 反応するという嘘のような本当の話。 不思議で仕方ないのが、Xperia のときは最初から「開発者オプション」が表示されていた、ということ。 携帯屋さんの担当者が押したんかな？　それともソニーではそうなのか？　謎です。

で、今度はUSBをつないだだけじゃデバイスドライバのインストールがダメっぽい。 なので、ググってみたら富士通のサイトで機種別デバイスドライバ一覧みたいなところへ到達したので、それをPCへダウンロードさせました。 ここまでけっこう時間がかかったので、やっとやっと成功か？　と思いきや今度は Eclipse で端末は認識するものの、 unknown offline みたいな困った表示をしてくる始末。 どうも、どうも…、eclipse にインストールしているアンドロイドの情報が古い、っちゅーことみたいですので SDK を更新してみました。 これも素直に成功せず、とりあえず Android 4.2.2(API 17)だけでいいから更新…という方針でやるもうまくいかず、 ものすごい中途半端な更新となりましたが、これによって run が成功しました。

…これでうまくいった。 はずが、どうもおかしい。 いくら eclipse上で内容を更新して上書きしてもスマホ（タブレット）側で内容が更新されない。 一回USB経由でもぐらせたアプリをアンインストールして、再度 eclipse から launch しても内容が前のまま。？？？

なんかいろいろバグってるなあ、と思って eclipse をいじくったりしているうちに 今度はソース上に問題がないのに、run すると「エラーがあるからダメです」状態に。 そこから tool とかなんとか　インストールとかしてみますが、徐々にわけのわからない深みの状態に陥っていき、いらいら！イライラ！！
「そうだ、eclipse を交換しよう」と思い至ってその日は寝ました。

今はなんと、アンドロイドデベロッパー向けパックみたいなやつがあるんですね。
Android SDKとEclipseのインストール Tech Fun これはなんかいいぞ、SDK もセットになっているから、おろらく今後最新版の android に更新しても不具合が生じないはず。 正味、ダウンロードはコミコミなので一発、zip の解凍は時間がかかりましたが、そこから最新版の API なんかをインストするだけ。 最後に古いほうのワークスペースからプロジェクトをインポートして、文字化けあったので、コードを UTF-8 に変えた、 くらいですけども万事解決っぽい。

アンドロイド アスペクト比に悩む

正月が終わってしまう…
正月が…
いまだにギャラクシーの android2.2 のやつを使っているんですが、 これはアスペクト比が 5:3 なんですよね。 で、最近のスマートフォンの主流は 16:9 ということで、私の機種より若干横長になっているという…。 まあ、画面の大きいタブレットに関しては 5:3 より 4:3 に近いものが主流なんですけどね。 基本的に画面のインチ数が大きくなるほど 4:3 に近付いていく風潮のようです。

実機としてさっさと 16:9 のやつに買い変えたらいいのですが、 ちょっと名案を思いついたので、試してみました。 要するに一台のスマホで、異なるアスペクト比での画面表示を確認する方法です。

簡単な話で、Activity で行っている
requestWindowFeature(Window.FEATURE_NO_TITLE);
getWindow().addFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN);
あたりを削除してやればいいんですよね、 // を付けて。 これで、今まで消えていたタイトルバーとステータスバーが画面上部に出現するので、 おのずと表示領域の縦幅が狭くなり、横長のアスペクト比に変化するというわけです。

それで、試してみると案の定、あちこちおかしな画面表示になってしまっています。

上の図のレイアウトは中央部分をとにかく正方形になるように作図して、その余りで四隅の配置を行っています。 この方法だと、アスペクト比が変わっても中央部分はさすがに正方形のままですが、四隅の方は破綻してきます（潰れてしまう）。 ただし、一番下の画像（タイトルバーとステータスバー有）でもギリギリ耐えているのでまあよしとしましょう。

今度のパターンはやばいです。タイトルバーとステータスバー有のバージョンだと右下のステータス表示の一部が見えなくなっています。 私はよく横幅の1/20、みたいな形でフォントサイズを指定しているのですが、文字は横書きなのでレイアウトしやすいわけです。 しかし、このやりかただとアスペクト比によって縦に何行書くことができるか？　というところで差異がでてくるわけです。 当然のことながら横長の画面であるほど縦に書ける行数は減ってしまいます。 今ならそう、冷静に分析することができますが作っているときはスッパリ意識していませんでした。 画面レイアウト事態を考え直さないといけない、ようです。

上記以外にもまずいところが複数見つかったので、随時訂正しました。致命傷みたいなのがなかったのは、サスガ今回が処女作じゃないだけの ことはありますが、それにしても android はメンドクサイっすねえ。

宣伝 乙Ｑ迷伝

拙作、android RPG アプリ「」もうすぐ「見切り発車●だいたいDEKITAバージョン」が完成しそうなので、 宣伝目的でいろいろ書いてみます。

本作は「遊びながら危険物乙４の試験対策もできる！」というイロモノ・ゲテモノ企画ですが、 必要以上にゲーム部分にこだわったために、やっつけ仕事感は極めて薄いのではないでしょうか？　つまり、作り込みがえぐいっすね。

「クイズRPG 魔法使いと黒猫のウィズ」さんをライバル視しているんですが（やったことないっすけど）、 やっていることは似ていますよ、考え方は。 パズドラの大ヒット以来流行している「RPG+●●」な企画。　 つまり、戦闘部分にアクション性を持たせようとした FF4だとか、テイルズ（やったことないっすけど）なんかがありますが、 こういうのをもっと昇華させたところに「落ち物パズル」「クイズ」「乙４問題」などをくっつけた RPG がでてくるわけです。

ただ、上記の特徴が最大のイロなんですが、いろいろと他にもチャレンジしている部分が多々あるわけですよ。 戦闘シーンでは敵モンスターがアニメーションするのですが、普通の感覚でいくと（3D・ポリゴンのやつは別として）待機中のパターンと 攻撃中のパターンの２通りを持っているわけです。 待機中は足踏みとかしていて、攻撃の際は剣を振り下ろすみたいな。 あるいはケムコさんのマシンナイトみたいにモンスターの体を頭・胴体・腕みたいにパーツわけしてパーツ単位で動かす手法とかが… 多分主流です（3D・ポリゴンのやつは別として）。 で、私としてはこれは非常にめんどくさいと感じた。 開発のかなり初期に人間型の悪魔サキュバス（よくいるよね、この人）を根性で作ってみたのですが、待機パターンと攻撃パターンで計11コマ、 非常にめんどくせぇぇぇ！　特に人間型は不自然な動きをさせたら分かりやすいので、関節の曲がりや衣装の揺れなども考えて作らないと 違和感バリバリなので難易度高い（逆に煙っぽい奴とかは簡単）。しかし、ここからモンスター量産の試行錯誤を重ね、たった４コマのアニメーションパターンで待機と攻撃の両方を兼用させる ことに成功しました。 これはちょっとした発明ですよね、逆に新しいですよね。

他にも５分１サイクルシステム（ダンジョン探索一発が3～10分ですむ）、 タッチ移動でシンボルエンカウント（移動中もリアルタイム）、 戦闘後HP自動回復・拠点でしか装備変更できないなどのシンプル操作の追及、 などなどスマートフォンの携帯ゲームであることを前提にした遊びやさを追及した設計（ゲームのライト化）。

ライトなだけじゃない、 モンスターの足跡から敵の気配を感じ取ったり、 武装に重さの概念があったり、重い武器ほど疲労度がたまりやすいといったマニアックな追及 ――従来のRPGではほとんど無視されていた物理攻撃の疲弊を表現。 疲労度はスタミナと読みかえることができるんですが、（別にソーシャルゲームみたいに課金でスタミナ回復という路線ではないにせよ） 「携帯ゲーム」＆「キャラの疲労」という組み合わせは相性がいいのだと思います。 なんていうか、ちっちゃい画面でちっちゃいキャラがセコセコ動き回って「オラ、疲れたよ」と言うのは妙に説得力があるというか…。 理論的に言えば、短時間のプレイで疲労してくれた方が、プレイするユーザーに「一仕事したぜ」という気分を与えやすいからです。

あとはやはり、乙４問題と関連するのですが、敵の特殊攻撃（麻痺とか魔法封じとか即死とか）を「乙４問題を解く」ことで回避するわけですね。 この運じゃなくて実力で困難をねじ伏せるというシステムデザインがゲーム的で面白いですね。 乙４問題に正解すれば危機回避ですから。 あと、５択問題なので運次第でなんとかなる、という点も見逃せない（多少は運の要素も残した方が味わい深い）。 従来の RPG では状態異常を使ってくる敵というのは、（特に序盤では）あまり多発しません。 というのも、眠り攻撃を仕掛けられたとして眠るか眠らないか運次第というのでは「運ゲー」すぎます。 だから、状態異常を防ぐ（某ファイナル●●でいうところのリボンのような）アイテムが充実してくる中盤～終盤になってからです、 敵が即死・石化などをやらかしてくるのは！！！ でも、耐性アイテムを装備することで敵の特殊攻撃を形骸化できるので、しらけるといえばしらけます（ガチンコ勝負な気がしない）。 つまり、従来の RPG では敵の状態異常攻撃というやつを持て余し気味だったと言わざるをえません。 ダメージであれば装備を強化して 100 くらっていたのが 80 になった、とすることができますが、 即死攻撃が 70% きまっていたのが 50% まで軽減できた！　となっても感じにくい＝実感できないわけです。 確率というやつは試行回数が多くないと鉄壁の効果とはならないですから。 この辺はギャンブルやる人はよく理解できると思いますが…。

例えば３回＜危機回避＞チャレンジしてみるとします。 即死技成功率 70% であれば何回殺されるでしょうか？　即死技成功率 50% であれば何回殺されるでしょうか？　答えは前者も後者も同じ 「０～３回殺される」です。 これが、300回チャレンジになれば 50% と 70% の違いは明らかになりますが そこまで長期スパンかつ統計学的な視点でゲームをやる天才がいるでしょうか？　いや、いない。 100ダメージが 80ダメージに減った！という現象と比べてあまりにも分かりにくい。 じゃあもっと極端に 70%（耐性なし） と 30%（耐性装備有） なら違いが分かるはずだ、と思われるかもしれません。 ここまで違うと10人中7～9人くらいは耐性装備の効果を実感できるでしょう、おそらく。 しかし、不運な1～3人は耐性装備にも関わらず、効果を実感できないでしょう。 確率ってやつは本当に気まぐれ。 この辺はギャンブルやる人はよく理解できると思いますが…。 じゃあもう、耐性装備なら 0% にしよか、となるのは当然の流れ。 0% なら10人中10人が効果を実感できます。確実ですね、安心ですね。

果たして昔のウィザードリーやドラクエの時代から比べて、 敵モンスターの個性化に成功したんだろうか？　と思えてなりません。 結局、状態異常攻撃というやつが形骸化していますから敵の特徴として「固い」「一撃が強い」「しぶとい」「群れる」「全体攻撃」 くらいしかないんですよね。 あとは「炎」「氷」「風」「光」「闇」「沼」「月」「火」「水」「木」「金」「土」「日」みたいな属性ですか？ 結局、個性化にそこまで成功していないから進歩したグラフィックで（絵的に）個性化させようとしても 「前衛的な外見をしたアナーキー漫才師がごく普通の漫才をしたとして、個性的なのかな？」という感じです。 あいつは火力が低いけど嫌らしい攻撃をしてくる…というパターンは欲しいですよね。 雑魚Ａと雑魚Ｂがタッグを組んだら意外な強敵になった…というパターンも欲しいですよね。 キン肉マンでいうステカセ・キングとかミキサー大帝のようなイロモノ・モンスターもアクセントとして欲しいですよ。 と、なってくると状態異常攻撃がまともに機能していないといけません。 どちらかというと、コンピューターRPG は味方側の攻撃バリエーションが増える方向で進んできた感がありますが、 それよりも敵側の魅力・個性を大事にした方がよかったんじゃないのか？　と思います。

まあ長々と口上が過ぎましたが、まとまりのない話で申し訳ない。 しかし、android アプリ「乙Ｑ迷伝」はすごくよくまとまっていますので、遊んであげてください。

乙４無念！

別に昨日今日の出来事ではありませんが、 乙４試験の結果がでたので申し上げます。 残念ながらすべってやんの、第１問目でいきなりフリーズしたから嫌な予感はしたんですが…。 予感はみごと的中。 これだけは言っておく！　現場に早く着いたので、小一時間ほどは時間があまった。 そこで持ってきていた参考書を熱心に読んでみたのだが、そこで得たフレッシュな情報は見事なまでに本試験では絡まなかった。アレレ…。 運が悪かったのか、出題範囲が広範だという証明なのか、は分かりませんけどね。

だけどおしかったのは、法令(53%)/物理・化学(70%)/性質・消火(70%)という結果よ。 つまり、法令であと一問正解していれば合格していたという事実！　紙一重で負けた。ドーハの悲劇ですね。

特に法令は日本語の嫌らしさ全開なところもあるのでナメテかからないほうがいいぜ！　例えば「化学名」という言葉、 私は恥ずかしながら「化学名」という言葉を（本試験で）はじめて読んだのですが、 てっきり CH3OH みたいなことなのかと思ったら「メタノール」っていうことなのね。 化学式と化学名は違いますからっ！　残念！　的な…失敗というか過ちを犯したのは間違いない！

まあ私の努力不足だということで再トライしてみようと思います。 アプリ制作の観点からしたら、もう一度受験するくらいの方が質を高めることに貢献するはずなので、一概に悪い悪いという 話でもないのですがね。
なぜ本試験は市販問題集よりハードなのか？
↑参考記事

ゲーム性とは？ ゲームとは？ 遊技とは？

今年は RPG な andorid アプリを気長に作っており、 色々と試行錯誤を繰り返しているわけで、発見も色々とあるわけで…。 そんなわけで、今、すごく分かりかけてきた気がする、のでゲーム性とは何なのか？　ということを僭越ながら書いてみます。

まず先に結論から言うと「不安とヒントの絶妙なバランス」的な話です。テトリスが分かりやすいっすね、 あれは７種類のブロックがランダム（無作為）に落ちて・く～る～　（You は Shock!!!） なゲームですが、 上手に隙間なく並べていくというアクション・パズルの不朽の名作です。 あれ、落ちてくるブロックの順序に規則性がないんですよね。 四角の次には棒が来る、みたいな決まりごとがない。 それに７種類しかないから、特定のブロックがずっと来ないということはありえないですね。 基本、どれが降ってきてもいいように作っていきますが、運（＋落下速度）次第で徐々に破綻していく…。

「今、四角いやつが落ちてきたらおしまいや」というときに四角ブロックが落ちてくるかどうかは運次第なわけです。 けれども、NEXT バッターズサークルがあるんですよね、次に落ちてくるブロックの種類だけは事前に教えてくれるという…。 もし、ネクストがわからないテトリスがあったらつまらん、と思うんですよね。 考えなきゃいけなないことが一気に減るから、「指先に神経を集中させながら運任せ」なゲームになります。 実際、ネクストの分からないテトリスがあったとしたら、次の落下物を高確率で予想的中させる能力がない限り、すぐに手詰まりになるでしょう。 逆にネクスト、ネクスト、と次の次まで分かったら 「確率論的にベストな置き方」というものが発生するでしょう。 ただし、これにたどりつくには物凄く色々考えないといけないので、２手先、３手先を常に読むという将棋的な集中力が必要となります。 物凄く色々考える＝ゲームとしてつまらない、ということは決してないのですが、 素早く考えて的確に動かす、というアクション要素があることを考慮すると、物凄く色々考えさせたらダメです。煩雑すぎるから。

それにテトリスの場合、ネクストが分かるくらいのヒントがあれば、 少なくとも落下速度が遅いときは無難に凌げます。 どんなパターンで落下してこようが、（難易度の高い低いのムラはあるものの）処理できるようになっています、おそらく。 だから、結局のところ「ミスを重ねること」が命取りになるので、 落下速度が増してくる中でいかにミスをしないで処理し続けられるか、というゲーム性になっています。

余談が長くなりましたが、「不安とヒントの絶妙なバランス」ということですわ。 私はゲームの制作において「ドルアーガの塔」を参考にランダム・マップ（自動生成の迷路）を生成するプログラムを作りました。 と、いってもテクニカルな部分はネット上にあるやつをいただいただけですが。 そして、このランダム・マップをどう楽しむか、という試行錯誤の過程でいろいろ見えてきたわけですよ。

①ランダム・マップの作成とキャラクターの移動（宝箱が何個か置かれているので、それを探す）
②ランダム・マップの地図を表示できるように
③地図は最初は見えず、地図の入った宝箱をとると地図が表示されるように
④地図の入った宝箱の座標とキャラクターの現在位置を示す座標を表示
⑤座標関係の表示を撤廃して、最寄りの宝箱の方向を示す羅針盤を表示
⑥羅針盤は２番目に近い宝箱にも影響を受けてフラフラと針がばらつくような演出を加味

2Dか3Dか？　ということは本質的には関係なく、どちらの場合でも同様の結論となるはずですが、 今回は2D見下ろし型（ファミコン・ドラクエ的）です。 まず①の状態ですが、テスト的な意味合いも含めてランダム・ダンジョンを歩きまわりました。 かったり～、というのが本音でぜんぜん面白くない。 なぜかというと、根気さえあれば迷路を制覇して全ての宝箱を見つけることはできるからです。 根気さえあればできることを、めんどくせえ、という気分と戦いながら続けるのは作業です、お仕事感がはんぱねえ。 これではテストにならんということで、迷路の地図をずばっと表示するようにしました。 これが、②の状態です。迷路が意図したとおりに作れていることと、毎回違うものができあがることは確認できましたが、 地図を見ながらキャラクターを動かしても、やっぱり面白くない。 なぜかというと、全部見えているからです。 テトリスでいうなら、30手先までブロックの種類が分かっているようなもの。 麻雀でいうなら、相手の手を見たうえでリーチに振り込まないように牌を切るようなもの。 面白くない。

まとめると、根気（だけ）が要求されること、分かりきっていることはつまらない。 「うまいことやったら、どうにかなるんじゃね？」と思わせる要素（たとえ錯覚だとしても）がなければ、つまらない。 「こうすれば絶対100% うまくいきます」→「はい、そうですか、やってください」→「はい、やります、成功しました」、 ではつまらない。 人は面倒なことが嫌いだけど、スリルを求めているのよ。

だから、③の状態に変えてみます。地図の入った宝箱にたどりつくまでは徒手空拳、ノーヒントです。 …宝箱にたどりつくまでが、かったるい…。

④の状態、現在座標と目標座標が分かるようにしてみると、少しだけ 迷路を探索しているような気になりますが、 やはり、左端の列にいて２ブロック下に宝箱がある、みたいな状態では「まる見え」ではないものの、ほぼ見えているようなもの。 興はそがれます。

⑤の状態。コンパス、羅針盤といっても真面目に北を指すようなアレではなくて、 ジャック・スパロウが持っているような「その者が欲しがっている物の方向を示す」的なやつです （余談ですが、これを実装する為に三角関数だとか、余弦定理だとかを勉強してつらかった、 しかも最終的に英語圏のサイトで書かれていたアークコサインの利用例みたいなやつをダメもとで参考にしたら成功という、 ネットで欲しい情報を探そうとしても近いものは見つかってもそのものズバリはなかなか見つからんということね！　知ってたけど）。 これで、だいぶ迷路を彷徨っている感はでてきました。 右下を指していても迷路なので素直に→↓という具合に進めるとは限りません。迂回したり、ぐるっとまわったり…。 でも、ノーヒントで探すよりは遥かに見つかりやすい、ただちょっと見つかりやすすぎるような…。

⑥に改造。今度は最寄りの宝箱の方向を基本的に指すんですが、二番目に近い宝箱の方にも針が振れるので、 針の動き的には現実世界のコンパスの動きに近くなり、リアル感が増しました。 それに迂回している途中で最寄りの宝箱が入れ替わったりすると、けっこうはちゃめちゃになるので遊びがあって面白い。 これでも、ノーヒントで探すよりはかなり見つけやすい。 針が→を指して右に壁があった場合、上に行くか下に行くかはプレイヤーの勘しだいです、自由度です自由度。 この辺の不透明性の振り幅が重要だと思われます。

「不安」の部分はランダム・マップで、しかもどの辺にいるのかも分からない、というところで演出しています。 「ヒント」の部分はコンパスの針の方向で、だいたいアッチに向かえばいいよ、というところで演出しています。

パチンコのリーチ演出なども近いところはありますね。 当たるときは、いろいろな予告や保留変化、チャンスアップなどが絡みますが、これらはヒントの側面です。 「当たるかもしれないからね、注目するなら今ですよ」っていうヒントですね。 しかし、確定演出という「絶対当たる（一応公式には99.9%くらい）」演出が絡まなければ、いくら賑やかでもお祭りさわぎでもハズレの 場合がある。だから、「いける？　いけんのか？　いけよ！　赤・赤・赤・赤…うわ、青やんか」と顔面蒼白になるわけです。 これは不安の側面です。 不安と期待をアップダウンさせながら、最終的な運命のジャッジタイムに向けて列車は進んでいく…。 結局のところ、アメとムチみたいな話なのかなあ。 人の心を御するには、結局は、アメとムチ！