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

　大部分移植完了。前回 CGマインスイーパ を移植したときに、ライブラリもだが、ほとんどのメイン部分もフレームワークっぽくしておいたので、思ったよりもずっと早く形になった。

　ボールの軌道計算やブロック、ラケットの反射などはほぼそのまま行けた。描画オブジェクトを変えただけ。しかし、やはり標準の View では重すぎるな。このゲームはブロックの硬さによって斜線を入れてるのだが、２本以上入れると画面がカクカクする。どうやら描画処理が追いついてないらしい。

　SurfaceView＋ScheduledExecutorService は Android2.2 ではバグるみたいだしなぁ…。さて、どうするか…？とりあえず斜線は１本に限定しても良いが、それにしても全体のスピードが遅い。実はPC版作るときも重さが問題だったので、色々手を加えて高速化したのだ。でもそうするとオブジェクト指向的なコーディングでは無くなるんだよね。やはりリアルタイム性のあるゲームはオブジェクト破壊的なコーディングにするしかないか…？


※キャラクター画像は「著作権フリー立ちキャラクター素材集」を使用しています。

　といっても今の所、データや画像をサーバーに置いてダウンロードする仕様ではないので、あくまでもファイル(class)をメイン部分とデータ部分に分けることにより、フレームワークっぽくしただけなんだけどね。そのお陰で画像や配色などをカスタマイズできるので、見た目的にも色々工夫できる。

　色々実験してみたが、アクティビティも１つのコンポーネントみたいにしても良いが、データの受け渡しが困難になるので、データ専用の構造体（class）とビューのみのクラスに分けるのが手っ取り早かった。このビューを各ゲームに extends して、データ用構造体を定義、メインに登録して実行という感じかな。これが一番簡単で不具合も少なかった。ライブラリ、ビュー、データ、起動アクティビティに分割したとは言え、取り込んで１つのアプリケーションとしてコンパイルしただけだからね。構造的にも簡潔。

　アクティビティごとにデータ送信とかは、コンパイル済のライブラリとかではエラーが出るね。たぶんセキュリティの問題だろうが（アプリ間で簡単にデータを書き換えられてはマズイわけで）、その方法を解除することもできるだろうが、それはそれで毎回やるのは面倒臭い。それと putExtra() みたいな関数を使えたとしても、数十、数百のデータでは骨が折れる（ゲームはデータが多い）。こういうデータは構造体で渡すのが普通だが、後から修正したりして構造が変わってしまうと不具合も出やすい。結局はJavaらしい、部品めいたclassをたくさん作るのが無難かな。だからJavaって恐ろしくライブラリが細かくなるんだろうね。同じような機能がいくつもあって、どれを使えばいいか分からないことが良くある。Basic言語系なんかはあまりそういうのないんだけどね。

※イラスト：こばP さん
※キャラクター画像は「著作権フリー立ちキャラクター素材集」を使用しています。

　CGマインスイーパもメインは移植完了。ついでに CGブロック崩し のマッピング機能も付けてみた。少し変わった感じになりましたね。空白部分は０と同じなので、簡単になってしまうかな～と思ったけど、意外と大丈夫だった。形によっては逆に難しくなりますね。試しにやってみるもんだ(笑)。もちろん差分絵もモザイクも切り替え可能。

　一緒に大部分の自作ライブラリも移植したから、あとはいくつかサンプル作って、詰めていくかな。現在は画像もデータも全てソースに埋め込みだけど、外部化すれば汎用的に使えるかな。さて、どうするか…。


※キャラクター画像は「著作権フリー立ちキャラクター素材集」を使用しています。

　メッセージウィンドウの移植が完了。

　せっかくなので、アドベンチャーゲームっぽいサンプルを作ってみた(笑)。外観も少し変えましたね。と言っても実は Applet でも簡単に設定変更できるように作ってはあります。いつもデフォで使ってましたけどね。私のクセと言うか、基本的にコーディングする際はほとんどの値をパラメタ化して置くんですよね。そうすると最後に調整するときなどやり易い。またメソッドを付け加えるだけで設定変更できるし、仕事で作ってるときも、急な仕様変更に対応し易い利点もありました。

　思いっきりそれっぽい使い方をしてみましたが、実はこのウィンドウは少し普通のアドベンチャー用のウィンドウと違って、高さが文字列に合わせて可変するウィンドウなんですけどね。アドベンチャーは固定が多いですね。だからついでに固定にも変更できるようにしておいた。１つの class で作ってあるので、アドベンチャーゲームを作るときは、このクラスを継承して、シナリオを読み出すクラスを作れば、そのまま使えるハズ。全てをパラメタ化して置くと、再利用もできて実はお得(笑)。

　これでアドベンチャーパートみたいなものも簡単に作れるな。そろそろメインも移植し始めるか…。


※キャラクター画像は「著作権フリー立ちキャラクター素材集」を使用しています。

　ADV型のメッセージウィンドウを付けると少しゲームっぽくなるね。


　やっぱりこの機能はなかなか面倒くさい(笑)。文字列の幅や高さを計算するのに FontMetrics と言うものを使ってるんだが、Applet と Android では取得オブジェクトが違っていた。

　Applet では Font オブジェクトから取得するんだけど、Android では Paint オブジェクトから取得するみたい。というのもフォントの設定や色も Paint オブジェクトなんだよね。図形を描いたりする時も Paint オブジェクトを使うから、ちょっとややこしい気がする。

　また基本的に考え方は変わらないけど、取得できる値も微妙に違う。プロパティ値はどうやらベースラインからの距離になっているようだ。Applet は大きさって感じで正の値だったけど、Android は負の値も出る。そのまま移植したら、当然画面が変になった(笑)。


　調べてみたら、こんな感じだったけど、top, ascent は負の値で出るね。baseline からの距離みたい。あと float 型なので、値が細かい。そのまま使ったら、微妙に文字列間隔などが綺麗に並んで見えなかったので、小数点以下切り捨てて、整数型として使ってみた。そしたら綺麗に並んで見えた。

　あと、getFontMetrics(null) で得られるフォントの高さは、プロパティ：ascent と descent の距離を足したものと同値になるね。ascent は負の値なので、height = descent - ascent で計算すると良い。Applet には getHeight() メソッドがあったから、計算の必要は無かったけどね。

　こういうものはやってみないとわからないので、コピペではやっぱり移植はできないね～。Java のライブラリももっと統一感出ればやり易いんだけどね。内部の値を一つ一つ確認していくのは骨が折れる。まだまだ時間はかかりそう…。


※イラスト：こばP さん