ヽ｜∵｜ゝ(Fantom) の 開発blog？

　以前に作った Android と Applet の互換コーディングを使って簡単なサンプルを作ってみた。内容的には CG Puzzler を Android でそのまま動かせるコードにした感じなんだけどね。せっかくなので、ちゃんとしたシステムみたいにしてみた。簡単なものだけど、いくらでも発展できるように作ってあるので、いつか本格的に作ってみても良いかもね。

　とりあえず、各ステージごとに色々設定を変えてみて実験してみた感じなので、ゲームバランスはあまり良くないかも(笑)。ステージ１が一番難しい気がするね。このステージはスライドパズルにグレースケール（白黒）変化を加えてみたのだが、正しい位置に置いたときのみ色が付くので、それをヒントに並べることができるというもの。デジタルならではだね。ゲームとしてはなかなか面白い。

　ステージ２は番号付きのスライドパズルだが、制限時間を付けてある。でも今までとあまり変わらないので、新味はないかな。このパズルが得意な人にとっては簡単過ぎる気がする。

　ステージ３はモザイクフィルタに時間制限を付けたもの。あまりステージ２と変わらないが、上から正しい順に揃っているものだけ表示するようにしてみたら、少し脱衣っぽくなった（笑）。全部並べれば見えるという仕掛け。これもデジタルじゃないとできないので、良いかも知れないね。制限時間はあまり余裕がないように設定してあるので、悩んでいたらタイムアップになるだろう。コンティニュー(STAGE SELECT）ははじめから付いているので、何度でも挑戦できるけどね。

　CGモードはギャルゲ風に（笑）。これはイラスト作者のこばPさんが欲しいと言っていたので、作ってみた。うん、確かに達成感があって良いかも。

　コーディングの考え方はフレームワークの記事の通り。ただの実験だけど、やってみるとマルチプラットフォームみたいなやり方がわかったので、これからはこの手法で色々作ってみよう。Java は Applet、iアプリ、Android のように色々プラットフォームがあるが、そのたびに書き換えるのって面倒なんだよね。ハードウェアの違いは仕方ないが、ソフトウェアである程度違いを吸収できるなら、それに越したことはない。

　最新の Android もタブレットとの親和性も考えて、機種ごとのスクリーンサイズなども、だんだんＯＳやハードウェアが吸収してくれるように設計されてきているみたいだしね。本当は Android も iPhone も１つのコードで作れたら、開発者はかなり楽なんだけどね。昔のバージョンは少しだけできたらしいけど(Java を Objective-C に自動変換するソフトがあった)、今はアップル公認の開発ツールと正規の AppStore でないと動かないみたいだしね。もう少しアップルがオープンになってくれたら良いのにな…。


※イラスト：こばP さん


（関連記事）
・Android と Applet の互換ってできるもんだね
【Android】【Applet】【Java】interface と abstract の使い方・違いとは～簡単なフレームワークを作って、考えてみる
【Android】【Applet】【Java】interface を使って独自のラッパークラスを作る
【Android】【Applet】【Java】interface を使ってインスタンスを生成する

　とりあえずデザインはシンプルだが、カスタマイズはいつでもできるように作ってあるので、自作の確認ダイアログ、選択肢ウィンドウ、履歴ウィンドウを実装してみる。


　うむ、こんなもんかな。選択肢は吉里吉里仕様の [link] タグではなくて、独自仕様にしてしまったが（メッセージウィンドウ内では小さすぎて選択しずらいため）、スマホの画面なら仕方ないかな。基本的に選択機能はシナリオジャンプ仕様だけど、独自に変数に値を記録できる機能を付け加えるのもいいかな。さすがに TJS 式までは入れるつもりはないので、もっと簡単なタグ仕様で実現すれば良い。値をシナリオからメイン読み込んでアプリに渡す機能は付けてあるから、選択肢によって別々のステージに切り替えたりもできるね。

　さて、ほんのオマケ的に ADV パートを付け加える機能を作ってみたが、かなり本格的になってしまった。データのロード・セーブ機能を付け加えれば、そのままアドベンチャーゲームになるね。

　またサンプルを作ってみるかな。でも画像素材から自分でいじってるので、また時間がかかるな・・・。やはりゲームはプログラマーとデザイナーの最低２人で分担しないと、結構キツイね。サークルでも作りたい気分。メンバー募集(笑)。ちなみに BGM や SE も再生できる。つまり簡単なサウンドノベルなら、もう既にこのシステムで作れるクオリティになってしまった(笑)。

　現時点ではスマホもメモリや通信などの制限で PC 並の容量は無理だろうが、10年後くらいには当たり前になってるんだろうな。4GByte くらいのスマホアプリとか(笑)。まぁ、今のところは小さいアプリをシリーズで出すのもアリかな。


※シナリオ：月華夜奏さん
※キャラクター画像は「著作権フリー立ちキャラクター素材集」を使用しています。
※背景画像は「きまぐれアフター」と「ぐったりにゃんこ」のフリー素材を使用しています。

　Applet版ではメッセージ機能を付けてはあるんだけど、Android版では更にこの機能に簡単なパーサー機能を付けてみて、アドベンチャーパートっぽくできるように実験中なのだが、実際に動かしてみると、すいすい進み過ぎて少し物足りない。というわけで、わざわざアドベンチャーゲームによくあるような画面効果＝トランジション機能を自作してみた。

　とりあえずパーサーが吉里吉里っぽいタグ仕様にしてあるので、内容的にも同じようなものにして、トランジションルール画像を用いる方法とクロスフェードのようなものを作成。といっても効率良い方法はよく知らないので、試しにアルファチャンネルを変化させるようなプログラムにしてみたら、それっぽくなった。

　クロスフェードの方は Paint オブジェクトのアルファ値をタイマーで変化させるだけで良いので簡単だが、トランジションルール画像はピクセル単位で変化させているので、少し重いかな。でも実機で動かしたら、そんなに問題なさそう。１回の効果を 125ms 間隔くらいで 2000ms(2秒間) くらいで変化させる分にはスムーズに行く。

　ぐるりと回転するように背景が消えていったり、上からす～っとキャラが現れたり、逆に消えたり・・・。やっぱりアドベンチャーパートにはこういった効果があった方がしっくり来るね。別に無くてもゲームに支障があるわけじゃないけど、これは制作者のこだわりかな(笑)？

　選択肢などはPCと違って、メッセージレイヤーに書くと小さすぎて、指で上手く選択できないので、中央にダイアログっぽいのを出したりする工夫をしなければならないだろうけど、そういった機種に合わせた方法に置き換えれば、わりとこの仕様でも行けるかな。独自のタグを付け加えたり、なるべくメモリやファイルサイズを最小限にするために、オブジェクトを使いまわしたり、画像を動的に生成したり色々してるけど、上手く行けばそこそこのものが作れそう。


※シナリオ：月華夜奏さん
※キャラクター画像は「著作権フリー立ちキャラクター素材集」を使用しています。
※背景画像は「きまぐれアフター」と「ぐったりにゃんこ」のフリー素材を使用しています。



（関連記事）
・Android と Applet の互換ってできるもんだね

　以前の「メッセージウィンドウ」っぽいものと「テキストファイルを読み込む」に加えてシナリオパーサー的なものを作ったら、ADVパートっぽいものができた。結局「StreamTokenizer」は使わなかったけどね。その代わり自作のパーサーを作成中。仕様を１から考えるのも面倒なので、以前試しに吉里吉里で作ったものを、移植する感じでKAG3タグ仕様を真似てみたら、いい感じになってきた。

　まだ機能や演出的なものはないけど、タップでメッセージや画像、キャラが変わるだけで十分雰囲気でるね。以前は横形であくまでも見た目だけだったけど、今度はちゃんと話が進行する。ゲーム中に縦になったり、横になったりすると、少し面倒くさいので、わざと縦型レイアウト固定にしてみた。でもそうすると下の方が少し余るので、とりあえずボタンを配置。こんな感じ？

　やってみるとトランジションや入力待ちのウェイトっぽいのはあった方が良いなぁ・・・。何もないから速効で進むので少し味気ない。ADVの場合、演出って意外と重要かもね。画面が揺れたり、画面遷移してる経過が見えた方がそれっぽい。実現にはタイマー処理が不可欠になって、プログラムが複雑になってくるけど、せっかくここまでやったのだから、作ってみるかな。


※シナリオ：月華夜奏さん
※キャラクター画像は「著作権フリー立ちキャラクター素材集」を使用しています。
※背景画像は「きまぐれアフター」と「ぐったりにゃんこ」のフリー素材を使用しています。

　結局、標準 View では描画処理が追いつかないみたいなので、今度は SurfaceView で作り直してみた。本来ゲームのような高速描画が必要なものは OpenGL を使うものだろうが、勉強も兼ねて色々実験してみることにした。

　以前の ScheduledExecutorService を使った処理はなぜかバグるので、他に色々なサンプルを分析してみたら、Thread で独自ループを作っているものが多かったので、真似して自作のレンダリングループを作ってみた。おかげでメソッド１つで処理できるようなものではなく、描画スレッドそのものを作るハメになったが、ついでに独自機能を付け加えておく事もできた。

　fps 計測もその１つ。デバッグ用にいつも fps を見てると、処理速度が分り易いね。どうやら私の実機は最大 57fps くらいらしい(Android は最大 60fps)。でも少し描画処理が多くなると 30fps くらいまで落ちるね。

　あと、面白いこと発見したのだが、Android の描画処理は グラフィック描画処理よりもビットマップ画像描画の方が速いらしい。というのは、以前サンプル作ったときに、ブロックの硬さに斜線を入れると描画処理が追いつかず、画面がカクカクすると書いたが、試しにブロックの描画処理 - 具体的に言うと、Canvas.drawRect() を画像に置き換えてみたら、レンダリング速度が 30fps 前後から 44fps くらいまで上がった。これにはビックリ。実は Applet 版作ってたときも同じ実験をしたのだが、Applet では画像よりもグラフィック描画の方がはるかに速かった。実際にPC版はあのようにものすごく速い。はじめはそのまま移植していたから、その違いがよくわかる。同じ Java でも Applet や Android では全然結果が異なるということだね。まぁ、PC の CPU/GPU と Android の CPU/GPU/FPU などのハード環境の違いもあるだろうし、コンポーネントの違いでも全然違うらしい。やっぱり色々試してみるもんだ。ネットでググった情報も結構違ってるもの多いしね。又聞きで書いてあるものも良くあること。結局自分で実験してみるしかないんだよな…。


※イラスト：こばP さん