アプリケーションに誤りがあります

携帯電話用ＲＰＧゲームエンジンを作成しようという
ひそかな野望をもった私は、とりあえず
ＲＰＧツクールに入っている素材画像と
テトリスサンプルをお借りして
くちくちとＪａｖａクラスを書いてみた。

Ｇｉｆ画像を表示して音楽をならすところまで
ＤｏＪａエミュレータで確認した段階で、
「このへんで実機で確認したいな」
と考えた。

.jar ファイルと .jam ファイルをＦＴＰで
ホームページにあげたところで、携帯から
おもむろに、「ダウンロード」

・・

すると、なんとこんなエラーが！

「アプリケーションに誤りがあります」

えっ！

そうきたか。。
エミュレータで確認したのに・・

まず疑ったのが、音楽のファイル。
どこかのＭＩＤＩサイトからひろってきたＭＩＤＩファイルを
そのまま使ったが、わがＳＨ９０１iSは対応していないのかも・・
という疑いだ。

ファイルをＲＰＧツクールに入っている mld ファイルに交換して
もう一度テスト。

やっぱり

「アプリケーションに誤りがあります」

がでる。

こんどは、音楽再生ロジックをコメントアウトしてトライ。

⇒まだきえねぇ

なんだよなんだよぅ。。
MediaImageとかMediaSoundクラスの使い方がまずいのか？

ということで、ＧＩＦファイルを表示しているロジックもコメントアウト。

⇒それでも、無常にも「誤りがあります」のメッセージ・・

！　ひょっとして、ＥＢ社の凶悪なプロテクトが
ＧｉｆファイルやMldファイルにかかっている？

普通のＧｉｆにそんなものを組み込む余地はないが、
Ｄｏｃｏｍｏが独自拡張したりしてるかもしれない・・・

むっぅぅ・・・

と、ＥＢ社にあらぬ疑いをかけたところで、
ここで気がついたです。

「そういや携帯ってアプリサイズちっこくないと
　だめなんかなぁ・・」

ドキュメントをあさると、初期のiアプリは、１０Ｋｂ
が上限とかいてある。

ぐへぇ。。　10キロってあーた。
８ビットパソコン時代みたいなこというんかいな・・

サーバサイドプログラマにとって、
かなりのカルチャーショックでしたよ！

１０Ｋってさ、頭じゃわかるんだけど、やっぱ、
異文化・異次元だよ。。

ググると、　ファイルサイズ小さくするために、
クラスやメソッド名を短くするだとか、そんなことが書いてある・・

　　いやだぁぁぁ～；；

まあいい。　

とりあえず動かそうということで、
ツクールさんからお借りした画像をresディレクトリから
サクサク消して再ビルドしたら、ちゃんとダウンロードできますたよ。。

なーるほどねぇ・・

実際のところ、ＳＨ９０１iSの時代までくると100KBまでは
いけるようだが、10KBが100KBになったところで、
やはり別次元。。

100KBっていうと、最近の普通のＷｅｂページの
1ページサイズぐらい？

その容量でで数時間遊べるアプリをつくるというのだから、
やっぱり、すごいもんだよ。。

ちなみに、ＳＨ９０１iSでダウンロードした
ドラゴンクエストやファイナルファンタジーは

アプリ: 100KB
データ: 500KB

となっていた。たぶん、画像とか音楽などを
データ領域にもっていってる気がする。

それと、半年前ぐらいに遊んでたナムコの
Tales of Breakerというソフトは
画像もきれいで、声まで出てた代わりに、

6章それぞれが１アプリにわかれていて、かつ
マップが切り替わるたびに通信してた。

そんときは、なんでマップ切り替わるたびに
パケ代かかるんや～　と思ったが、今は納得したよ。

よし、んじゃ、やることリスト！

　１．まずは、５００ＫＢのデータ領域のほうに画像と音楽を入れる仕掛けを勉強
　２．そんでから、Jarファイルの中身をいじってメソッド名を短くするツールを選定
　３．1年前に考えたＸＭＬベースのゲームエンジンをもちょっとちゃんと設計する。
　４．最後にＸＭＬのバイナリ化仕様決めてエンジン実装。

そんな感じかのぅ。。

まずは、３も、最初はアドベンチャーゲームやクイズゲーム対応が
限度かな。。その次にＲＰＧに向けてバトルシーンとフィールドシーンをつくるか。

一応クラス設計としては、以下のような形に

Game
　<>
|
Scene <|-- MovieScene　（タイトル画面・エンディング・途中のムービー等：　フラッシュ的なつくり）
<|-- FieldScene　（フィールド移動：　スクロールだとか、タイルチップセットとか、そういうの）
<|-- BattleScene　（敵とか、エフェクトとか、そういうの）

<>--BackgroundPicture
<>--Sound

グラフィックのことをGraphic という名前にすると Graphicsとまぎらわしい＆
写真はどっちにしろつかわないので、Ｇｉｆだろうと何だろうとＰｉｃｔｕｒｅって言葉をつかうと
いいかなとおもったよ。

そいと、ＢＧＭという命名は効果音とか実装できないし、
Ｓｏｕｎｄという名前でバッティングしなそうなので、これは採用かな。

それと、中間レベルＡＰＩ群として
Ｆｌａｓｈみたいにネスト・拡大縮小回転・フィルタ適用可能な
グラフィックコンテナＳｙｍｂｏｌという考え方は使おうとおもう。

あとは、ＥｖｅｎｔとＥｖｅｎｔＦｌｏｗ　。。
名前はＥｖｅｎｔなのかなぁ。。

・・ってこんなにクラスを増やしすぎると、分かりやすくなるかもしれないが
サイズが・・

いや、まずは、わかりやすく作る。

その後、クラスをまとめたりして省リソースを目的に
リファクタリングすればいいかな。。

というか、ＸＭＬのスキーマは、わかりやすくするのを第一義にすべきなので、
こういう設計をすることが必須。

んで、最初は、スキーマと素直に1対1対応するクラス群をつくって、
そのあとでダイエットすればいい。。かな。