ScratchPad & JarInflater & HTTP通信

今日もi アプリだよ。

ドラクエやFFが アプリサイズ100K＆データサイズ500Kになってたのにヒントを得て、
アプリと画像等素材データの分離配布モデルを実装してみた。

　・アプリのjarファイルにはプログラムとタイトル画像・タイトルBGMなどのみを入れる
　・ゲームスタートでその他もろもろの音楽と画像をダウンロード
　・ダウンロードしたデータ（画像等をかためたJAR）はScratchPadに保存
　・ゲーム内ではScratchPad上から画像・音楽を読み出して使用
　・次回起動時にはすでに落としてあるjarの内容を用いる。

と、だいたいこんな感じのモデルで実装してみた。

まずは素材一式をjarでかためてみた。
3～400Ｋバイトになったので、そいつをサーバにアップロードして
エミュレータで実験。

すると、ログに150k 以上のデータはhttpで落とせないですという旨のメッセージが・・

むぅ。。　そうきたか。。

しかたがないので、画像やら何やら種類別にわけてjar化してみた。

ドコモの仕様書に、ScratchPadは16個までもてますみたいなことが書いてあったので、
はじめは別々のScratchPad番号に種類別のファイルを先頭から書き出してみたが、
なんだかうまくいかない。。

しょうがないので、すべてのファイルを0番のSP上に先頭から順に
ならべて記憶させるようにした。

すると、アラマア！
うまく保存できたですよ。

そこまでで昨日は力尽きて眠ってしまいました。

んで、今日、会社の帰りのグリーン車の中で、
くちくちいじったところ、期待通りの動作をしたので
家に帰って実機確認してみました。

うごいたぁぁ！

初回、通信して５つのファイルにわかれた300キロ程度
のデータをとってきます。

しかし、　おせぇぇ！

エミュレータだと1秒もかからず、全ファイル落としてくるのに、
実機でやると1分近く通信しやがってくれました。

　教訓：　はじめに全部落としてくるのはダメぽい
　　　　　　⇒だからファイルをわけるにしても、
　　　　　　　種類別じゃなくて、シーン別というか
　　　　　　　ゲームの進行度合いに応じたJARパッケージング
　　　　　　　せんとだめぽ

　　　　　　⇒進行度合いに応じたパッケージングって
　　　　　　　　ゲームが出来上がってからなら簡単だけど、
　　　　　　　　開発中に試行錯誤的にシーンの順番を入れ替えたりする
　　　　　　　　ことができなくなっちゃう。
　　　　　　　　　（ツールが必要かなぁ・・）
　　　　　　　　

ちなみに、成果物は⇒　http://akio.shimono.net/2006/iappli/0622/　（FOMA　SH901iSのみ確認済）

あと、発見したこと。
一旦古いバージョンでJarをおとしてきてSPに書き込むと、
その後ソフトバージョンアップしても、SPはクリアされない。
（本来のSPの使い方を考えれば当たり前だけど・・）
だから、ちゃんとしたリリースの際は、
素材データもバージョン情報を持つ必要があって、
バージョニング機構は自分で実装せねばならないね。

Jarファイルにいっこテキストファイルを入れてもいいだろうけど、
マニフェストファイルをちゃんとつかえばいいかな？

あ、それと、昨日実家で2年前ぐらいにかった
504i/FOMA対応　iアプリゲームプログラミング（DoJa 2.0対応!）
なんて本を発掘したよ。

アプリサイズは１０ｋとか３０Kとか、
涙ちょちょぎれるようなことがホントに書いてあった・・
すごい・・　

んで、本をよんだら、キーイベントの拾い方、
変な自己流でやってたことに気づきました。
やっぱり本は大事だねぇ

それと、あとなんだ、
終了ボタンをおしたときに
「終了しますか？　はい／いいえ」
ダイアログが出るようにしたよ。

次の目標は・・と、
これが一番大事だね。

次々と簡単に実現可能そうでかつ、
大きな目標に着実に近づく目標をたてること。
こいつができさえすれば、あとは情熱だけで前にすすめる。

んーと。

　・シーンの切替
　・グラフィックに対するエフェクト（フェードイン・フェードアウト）
　・ウィンドウの実装
　・非圧縮フィールドマップデータの上を
　　てくてく歩く主人公＆フィールドスクロールの表現
　
そのへんかなぁ。

いや、ちょっと欲張りすぎた。

まずは、タイトル画面をだして、
ボタンを押すと今のアプリに遷移、
右ソフトキーは、アプリ終了に飛ばずに
タイトル画面に飛ぶようにする。

・・　そんなとこかな。（以上明日の目標）

そんつぎに、そのシーンのトランジションに
フェードイン・フェードアウトを入れる。（あさって）

さて、　夜も更けたし、ねるとしよう。
　
おやすみなさーい（＾～＾）

　　・・　てか、なんか、すぐできそうな気がしたので、
　　　　　明日の目標ってとこまでは達成してしまった。　（0622 ver0.5）

　　　　　但し、以下課題があることに気づいた
　　　　　　－シーンを以下のように親子ネスト構造とすることで、
　　　　　　　普通のRPGは表現できそうな気がするのでそれをイメージした
　　　　　　　クラスをつくってみたが、
　　　　　　　　　　　-タイトル　
　　　　　　　　　　　 　-マップ
　　　　　　　　　　　　　　-戦闘
　　　　　　　　今の実装だと、資源もちっぱなし。　メモリがたらなくなるかも・・
　　　　　　　　ネストしたシーンクラス自体は軽い実装にして、
　　　　　　　　そこで使う画像やら音楽はonEnter()でロードしてonExit（）で開放するようにしよう。。
　　　　　　　　　　⇒明日の課題

　　　こんどこそおやすみ～

i アプリ すこしだけわかってきたっぽ

おおー　

なんだかなんだか
i　アプリわかってきたぽ

本日、キーイベント取得　（押しっぱなし）と
キャラクタの移動
あたりができるようになったよ。

これに昨日おぼえた音楽のキーやテンポを変えるロジックと組み合わせて、
こんなアプリがつくれたよ。

http://akio.shimono.net/2006/iappli/index.html（ver0620とかいうリンク）
　↑ＦＯＭＡでアクセスだ！

方向キーで、顔グラフィック（Ｇｉｆ）をうごかして、
決定キーでをおすと、場所に応じて音楽の
キーとテンポがかわる。

んで、　ソフトキー左をおすと、
ファンファーレとともにキャラとＢＧＭがかわる！

　　：：　だからどぉしーた
　　：：　　ぼくどらえーもん

むはは！

おどろけ！

いやなに、それだけっちゃそれだけなんだけどさぁ
内部のコードがね。。

昨日まではサンプルアプリ、テトリスそのものだったのが、
今日は完全私のオリジナルなのだぁぁ～（除：素材）

しかも、一応、そこそこ本格ゲームが作れるようにと自分なりに考えた
フレームワークのプロトタイプの中で動いている。

この事実と、
あとなんだ、そのフレームワークが、
自分で書いてても、なかなか使いやすいじゃんってことで、
すげぇうれしいのだ。

それとなんだろ、
キーおすとなにかがその方向に動いて、それが、意味のある行為で、
（動いた先でボタンをおすことでいま音楽のテンポと調がかわる）
さらに、もう一個、キャラと曲が変わっちゃうボタンがあるという
あたりが、なんかこう、人間の探究心を本の少しながらも
刺激するわけで、（　キーをさげたら、どんな風に聞こえるかなぁという好奇心）
そのあたりも、私は満足だよ。

２～３日でここまでできたのは、ちょっとおいらエライ！

次は、顔グラのかわりにマップを動かしたり
Symbolの実装を進化させて、歩く人を表現したり、
そういうことしよう。。

あと、scratchPadつかって、画像や音楽を落としてきて
保存する仕掛けも実装しよう。

きょうは以上。　満足！

iアプリ Audioのループ再生

さてと今日も　i アプリの話題。

きのうはAudioのループ再生の挑戦したよ。

package rpg.core;

import com.nttdocomo.io.ConnectionException;
import com.nttdocomo.ui.AudioPresenter;
import com.nttdocomo.ui.MediaListener;
import com.nttdocomo.ui.MediaManager;
import com.nttdocomo.ui.MediaPresenter;
import com.nttdocomo.ui.MediaSound;
import com.nttdocomo.ui.UIException;

public class Sound {
private AudioPresenter as;

public Sound(String url) {
MediaSound ms = MediaManager.getSound(url);
try {
ms.use();
} catch (ConnectionException ce) {
ce.printStackTrace();
} catch (UIException uie) {
uie.printStackTrace();
}
as = AudioPresenter.getAudioPresenter();
as.setSound(ms);

}
public void play(int volume, int tempo, int keyShift, boolean repeat) {
if (repeat) {
MediaListener listener = new MediaListener() {
public void mediaAction(MediaPresenter source, int type, int param) {
if (type == AudioPresenter.AUDIO_COMPLETE) {
((AudioPresenter)source).play();
}
}
};
as.setMediaListener(listener);
}
as.setAttribute(AudioPresenter.SYNC_MODE, AudioPresenter.ATTR_SYNC_ON);
as.setAttribute(AudioPresenter.SET_VOLUME, volume);
as.setAttribute(AudioPresenter.CHANGE_TEMPO, tempo);
as.setAttribute(AudioPresenter.TRANSPOSE_KEY, keyShift);
as.play();
}
public void play() {
as.setAttribute(AudioPresenter.SYNC_MODE, AudioPresenter.ATTR_SYNC_ON);
as.play();
}
public void dispose() {
as.getMediaResource().dispose();
}

}

(なんかブログが勝手に改行いれちゃいます。かといってpreとると、
インデントが消えちゃうし・・
ブログにソース貼り付けるいい方法ってないのか？
 に置換して貼るなんてめんどいし・・・)

とりあえず、こんなクラスをつくっとくとサウンド再生が
楽チンかもとおもったわけです。

　＃iアプリプログラミング素人なので、
　＃　「こんな余計なクラスは省リソースの敵じゃ！」
　＃みたいな話が正解なのかもしれないけど・・

ループ再生については、ＡＰＩをパラ見するとこんな書き方が
できそうだけど＆一応ループ再生したのだけれど、
ループのつなぎ目が綺麗に再生できるかどうかがちょっと疑問・・

昨日やったときは、データがそもそもループ用に綺麗にできてなかった
のもあって、ちょっとぎこちないループになってしまった。

データのせいじゃなく、
そもそもこのやり方じゃスムーズにできないという話なのかもしれない・・

今後要調査。

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

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

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

.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対応するクラス群をつくって、
そのあとでダイエットすればいい。。かな。

iAppli初挑戦！

今日はなにを思ったか、
iAppliをつくってみたいという気持ちが高ぶり、
色々やってみたよ。

いや、なぜかっていうと、
ＲＰＧツクールforモバイルなるものが出たらしいという話を
先日聞いたのを思い出してちょこっとあそんでみたのがきっかけ。

ＲＰＧツクールforモバイルをインストールして動かすためには、
まず、以下のサイトにいって
DoJa-3.5なるものをダウンロード＆インストールせねばならぬと
書いてある。

http://www.nttdocomo.co.jp/service/imode/make/content/iappli/

ふむふむ。そういやDoJaってキーワードあったねぇ。
iAppliって感じだねぇ・・

なになに、今度はj2sdkを前もって入れとけって？
あー。Ｊａｖａははいっとるよ。

んじゃ、ぽちっとインストールをしてみっか。。
とプチプチやること数分。。、

！　j2sdkが入ってないよと怒られてインストール失敗。

む！
おかしい。。　毎日eclipseでj2skd1.4ベースの開発してるのに・・

あそっか。
よく考えたら、eclipseで開発していてsdkではなくjreにしか
パスが通ってなかったことを思い出した。

あーめんどくさい。。
とは思いながらもそのくらいで負けてはいられないので、
SUNのサイトにいってJ2SDK1.4_12とやらを落としてインストール。
環境変数書き換えて、改めてDoJaとやらのインストールを試みると
ちゃんとはいってくれました。

んで、ＲＰＧツクールforモバイルとやらもインストールして
出てきた画面がこんなの。

なるほど。　ふむふむ。
一応ツクールＸＰでゲーム作ろうとして
途中でなんとなくフェードアウトした（^^）
経験はあるので、操作はだいたいわかる。

へぇー
操作簡単だねぇ。

よし、じゃあ、ここまでで動かすと
実際どうなるのか、見てみよう。。

と
ぽちっと実行ボタンらしきものを押すと、
さっきインストールした
DoJaとやらが立ち上がり、こんな画面がでてくる。

おお～　すごいすごい。
せりふしゃべって、動いて、スクロールするじゃん。

たのし～

なるほど、DoJaってのはiAppliエミュレータなのね。
　（＋ＳＤＫ？　まだよくわかってないけど）

よし、
では、今度はエミュレータではなくて、
コイツをおれっちの本物の携帯電話で動して
みよう・・

・・・・と、、

む！？
なんだかよくわからんが、どうやるんじゃ？？

そう、
ここで問題発生！

ツクールモバイル君は、
無料である代わりに
つくったアプリを自由に配布はできず、
エンターブレイン社に送って、
審査に合格したら同社サイトから
有償ダウンロードになるというモデルなのだ。

であるからして、・・・

えぇぇぇー！！！

つまり、ちゃんとつくらないと、
自分の携帯で動かして自己満足に浸ったり、
友達に披露してみたり、そういうことできないってわけ？

それってすごくつまんねぇぞ。

ていうか、ちゃんとゲーム最後までつくれる
気がしないので、応募もできないわけで、
そうすると、ずーっとこのDoJaとかなんとかいう
エミュレータみたいなのでしか動かせないじゃん

きぃぃーーーーー
くやしいぃぃ

こんなのいやだぁぁーー

もう、このアフォウ人は、
自分のつくったものを自分のケータイ
SH901iSで動かしたくてしょうがなくなってしまってます。

ということで、普通にiAppliをつくってみようという気になったわけです。

さっき落としてきたDoJa-3.5まわりのドキュメントやら
DoJa落としたサイトやらをあさって、以下の決断をした。

　１．DoJaのバージョン、4.0でやりたい気もする（SH901iSは4.0対応）が、
　　　まあいいや、インスコ面倒だからとりあえず3.5つかっとこう
　２．DoJa-3.5のEclipseプラグイン、Eclipse-2.1.2対応って、
　　　そんな昔のEclipseやだなぁ。。できることなら今使ってる3.1に
　　　いれちゃえ

やってみたところ、いい感じ。
とくに大きな収穫は2の部分。

とりあえず動かしてみて触った限り、
Eclipse3.1でもプラグインちゃんと動いてます。

らっきー

ということでDoJa-3.5と戯れること数十分。

DoJa-3.5に入っているサンプルプログラム、テトリスのソースを眺めてみる。
ふむふむ。　すごいな。
テトリスってこんな短いプログラムですむのか。

よし、では本題にもどろう。
こいつを、なんとしても私のSH901iSに入れて動かしたい。

ということで、さらに、ドキュメントをあさること20分程度。

http://www.nttdocomo.co.jp/binary/pdf/service/imode/make/content/iappli/about/jguideforDoJa3_0_040428.pdf

みつけた↑このドキュメントの14章の記述とおりにやったところ
ちゃんとケータイでダウンロードしてテトリスあそべたよ。

嬉しくて、サンプルテトリスに自分の名前をいれてみた

http://akio.shimono.net/2006/iappli/index.html
（↑本日の成果：
　　めっさ暇人であり、かつ、
　　私が悪意のあるコードを書く
　　意図またはスキルがないと信じるアナタ！
　　そんなアナタは、
　　上記ｕｒｌにFOMAケータイからアクセス！）

いぇ～い。
なんか、iAppliじゃーん

満足～　（＾v＾）

ひょんなことで始まった本日のドタバタで、
iAppliをつくるための一通りの流れが
ちょこっとつかめた気がするよ。

iAppliって、言語が
いつも使ってるJAVAなので、
ここまでやり方がわかれば、
自分でも結構色々面白いことができる気がする。

明日からｒｐｇツクールみたいなやつを
eclipseプラグインでつくってみるかな～？
（eclipseプラグインなんてつくったことないけど・・ｗ）

画像処理JSP

原因解明！

みなさん！　掲題のごとき、画像処理JSPはダメです。

「サーブレットは要らん、JSP万歳！」
だった私は反省をする必要があります。

ここに私はJSP万能主義を撤回いたします。

いや、まい、ホームページ、akio.shimono.netのTOPで、
写真を適当に選んで、カンタンな画像処理（リサイズ）して
表示するJSPを置いてたのよ。

んで、TOPページ表示しようとすると、
１０回に１－２回ぐらい空白ページがかえってくるという
怪現象が起きていたんです。

じつはその画像表示JSPが原因でしたよ。

http://shimono.jspeed.jp/titlePicture.jsp

詳しい原因はまだわからないけど、
全く同じ処理をするサーブレットに変えたら
パタッと止んだのです。

なんだったんでしょうねぇ。

ブラウザの問題だったのかもしれない。

拡張子が.jspなのに、MimeType　JPEGで
バイナリが返ってきたら、IEちゃんびっくりしちゃったのかなぁ？？

ページにIMGタグで埋め込んでいたら、ちゃんと表示されてたけど、
単独で呼び出したら変なメッセージが出てたんだよね。

ASAFILEとかいう種類だとみなされたりしてて、、

いや、それが、必ずというわけではなく、時にはちゃんと表示される。。

なんか、挙動不審だったわけです。

そこで、サーブレットに変えてみたわけです。
http://shimono.jspeed.jp/TitlePictureServlet/pict.jpg

アラ不思議、いまんとこ、更新連打しても、
ちゃんと表示されてます。　

うーん。　不思議。　

とりあえず、「サーブレットでできることはJSPでも出来るんダァァ」
という主張には、穴があることを認めますだ。
URL自由にマッピングできないっすね。
だからこういう問題が起こりうると。。

ま、お勉強になりました。