icicle

public void onCreate(Bundle icicle)
これは何？ public void onCreate(Bundle savedInstanceState) の savedInstanceState が icicle。Activity の onCreate(Bundle savedInstanceState) をオーバーライドしているものだが。

■http://stackoverflow.com/questions/919153/what-is-androids-icicle-parameter
"icicle" is sometimes used as the name of the parameter because onSaveInstanceState() used to be called onFreeze().

■http://blog.livedoor.jp/maochan__/archives/1885701.html
「ver.0.9beta 以前の onSaveInstanceState() は onFreeze() を呼び出し、保存された状態は ”つらら(icicle)" と呼ばれていた。一部のドキュメントやサンプルでは、まだこの古い名前が使われている場合がある。」

■http://blog.tyreeapps.com/2011/02/icicle-and-savedinstancestate-are.html
以前のバージョンの名残ということで、今となっては hoge 的なもの、ということでよいのか。

ドキュメント

黙々とAndroidについて読む。http://developer.android.com/guide/index.html
BGM は Challenger 1985 (Gradius) のループ。

Android ドキュメント

真面目に、Android の開発者ガイドを読む。Framework Topics の Activities だけだが。
英語を読んだあとで日本語サイト(ユーザーサイト)を読むと理解度があがる？ 英語読むのに時間がかかって日本語のユーザサイトを読む気力がないが。
eclipse でのビルド時、やたら res/main.xml が main.out.xml となってエラー(レイアウト内容がない)となって、なんでだろうと思っていたが、main.xml 編集画面を開いて(メイン画面に表示されて)いる状態でビルドするとエラーになるとのこと。なんだかなぁ。

エミュレータの起動

前回、マシンスペック低すぎて起動しないのかとまで思ったが、気長に待っていると無事起動した。が、起動後エミュレータの速度が遅い。実機を入手しないといけないのか？

保存・読出

ボーナスポイントを振り分けて(振り分けの最大・最小のチェック)、各パラメーターへの振り分けに応じてクラス(職業)を表示させ、と簡単な条件の集まりだけどなかなか面白い。作成後は同じ名前のキャラクタを作成できないようにセーブ。バイナリ保存になるが、キャラクタ以外のセーブデータもあるわけで、管理が大変になりそう。
次は、作成したキャラクタをパーティに追加だが、きちんとキャラクタのセーブ(ロード)処理を作らないと...

ボーナスポイント表示まで

迷宮をあるいていて、街や城などの拠点に戻る。最初もしくは途中でプレイヤーキャラクターを作成する。画面遷移どうすんだろというところろ。結局、getContentPane() , validate(), repraint() であっさり切り替えができた。
切り替え時にモードをセットして対応するパネルを表示。
フォントがつらいので、swing に移行。使える等幅日本語フォントはないのか？
Wizardry を踏襲して、名前を入力、種族、属性を選んでボーナスポイント！
名前は、KeyListener で取るが、名前なし＋Enter でひとつ前の画面、名前あり＋Enterで種族選択画面、名前でバックスペースされたときの処理、カーソルキーの操作は除外と各キーに応じて、各モード毎に制御していかないといけないのか？ とりあえずバックスペース処理は実装したがちまちま面倒な作業が続く。

キャラメイク

ワイヤーフレームダンジョンはひとまず終了。通常壁のとき通過できるかのみしか追加していないけど。
ダンジョン内歩いてて、現在はいわばウィザード・モードチックであり、まだいまいち感じが伝わってこない。
こ、これは、キャラがいねーからだよ。ということで、キャラクターメイキング画面を作る。
んー、画面をどうやって切り替えるのだ？ Textfieldに名前入れて、キーリスナー keyPressed で入力文字(名前)を取って、次の別画面に遷移させたいがかわんねぇ...

壁や扉は面倒や

何度もやり直ししたが、このくらいにしておく。
方向変換して壁の見え方が変わるときの情報の取り方、取り方を考慮した情報の持ち方が謎。

マップデータそのものを作るのが面倒。

しかし、なんでダンジョン内歩いているとき、画面ちらつくのかなぁ。処理が重い？

壁は通ることはできません

壁の通行判定は、壁なら座標移動しない(現在地、向きはそのまま)ということで実装。ただ、一方通行とか、隠し扉を考えたとき、現状のデータの保持の仕方では無理。
適当に paint() 一本にぶっこんでいたせいか見づらいため、それなりにクラスを作りだす。さらに、描画の仕方も再考ということでやり直し。

動かしてみる

今回 Java で書いてます。AWTで。キー入力を受けつけ、repaint(); させる。
「おおぉ」、動いてる。笑ってしまった。
キー入力は方向を変えたとき、そのあとさらに前進したとき、下方向キーで反転させたときと分岐が多いな。
動かせることができるので、マップデータの間違いも見つけやすくなった。といっても、マップ表示での確認が主ですが。

当然、壁なんかすり抜けますよ、そりゃ。あとは、上下(階段とかメッセージ)の処理とか。Wizardry #1 の左下部分のマップを書いて動かしてみたが、ダークゾーンとかもあるか。

Wanderers / Wandroid

Wanderers の作者、Android版でも作っていたのですね。端末を持ってないのでプレイできないが...
■Hall Of Wanderers
http://homepage1.nifty.com/taka_homepage/

Android って、自由にフォントが使えるのかな？

とりあえず終わり

方向を変えてもちゃんとマップ情報どおりに表示できた。オートマップ用と言うわけではないが、マップデータ確認のための全体マップ表示機能もつける。
壁ありとなししか描いていなかったので、扉あり壁もつくる。とりあえずはこれでいいだろう。
次は、キー入力で描いた擬似3Dダンジョンを歩けるように。

すすまない...が

マップデータは今は適当で良いのでスプレッドシートに東西南北(UP/DOWNもそのまま足せるが)を書いて、エディタにコピーして加工してとりあえずは問題なし。ただ、壁情報を一マス書き換えると、接している他のマスの情報も書き換えなくてはいけないために面倒だけど...
方向変換したときの描画をやるつもりだったが、単純にワイヤーフレーム描画にまだつまづきがあり延々修正。あぁ、一応できたか。
方向転換のことを考慮しながら書いていたが、たとえば、北東南西 の順序で設定し、右(東に向いたときは) 東南西北 と、向いている方向が決まればあとは考えなくても良い？　行列を回転させての求め方がほとんどでしたが...
にしても時間かかった。
オートマップ表示も作らないと、描いたマップデータ自体があっているかどうかも確認できん。

マップ情報

結局描画だけできたことにした。
次は、方向変換したときの処理。これに加えてマップ情報を作る処理。編集しやすくて、視認性が良くて、テキスト書き出し処理ができるようなものを作成することに。よーく考えず、見た目だけでワイヤーフレームははまったので要注意。

ワイヤーフレーム描画で、三角関数を使った場合も考慮したが、三角関数使うと double になり、精度を修正しても...今回は y=x, y=-x(ax+by+c=0)で intのみで描けるので採用しない。でも、壁描画は楽だろうなぁ。

3マス先って

■□□□□□■ 3マス先
  ■□□□■   2マス先
    □□□     1マス先
      ▲

3マス先まで見渡せるというイメージで、上図のように考える。▲は現在地。■のマスは左側にある場合は左の壁、右側にある場合は右側の壁だけ表示しない(視界に入っていないつもり)。
3マス先の列を左端から描いていくと、左右の壁が重複するので、真ん中より左は左壁のみ、右側は右壁のみとやっていたら、非常に面倒(真ん中のマスだけ左右の壁を描画)。
PC-9801版 Wizardry #1 で3マス先の壁の描かれ方を見てみる。結果は次の通り。

    ■□■     3マス先
    ■□■     2マス先
    ■□■     1マス先
      ▲

左側、右側のマスそれぞれ左壁、右壁の描画なし...。■のマスは、それぞれ左右の壁は描画されない。これだと現在地から正面マスの左右だけ見れば良いので楽ではあるが。
SFC(NP)版 #1 を確認してみると PC-9801版 とは違う描画になっている。
もーホント面倒なので、PC-9801版を採用する!!

Vampiryy

■Vampiryy(ヴァンパイリィィ)
http://vampiryy.nobody.jp/
Wizardryライクの作品ですが、なんかすご過ぎっぞ。概要にある「server/client 型。」って。

やりなおし

もう、Wizardryを作っているかのようなワイヤーフレーム。奥のマスから描画して手前のマスで上書き(後から書いているだけ)する。
ただ、一番前方奥のマスを描画するとき、正面・右・左の3つを描いて、次に手前のマスの正面・右・左とやっていたら、最後の自マスでzap...
一番奥のマス(3マス先)は 7マス見渡せるが 7マスのうちの左端から描いたのが良くないのか...
オートマップ用に一緒に上から見た図の表示もさせていたが、いったんやめよう。

計算が...

ワイヤーフレーム...何日やってんだんか。うすうすというか間違いなくだが、プログラム以前に数学的な処理が必要で...
y=x, y=-x で、マスの割合は y=a*x^2 + a。各座標は四則演算で(ここは三角関数使うとこかな...)書き直し。
向こう先何マスを見渡せるかによって、奥に行けばいくほど見渡せる量が増えるため、手前のマスに壁がなく、奥のマスに壁があったとき、壁の両端をどこまで描画すれば良いのか謎...というか後回し
書き直したのはいいが、今は単に線を引いているだけ。画像を貼りつけることはしないので、奥のマスの線が見えてしまう。手前から描いても、奥から書いても、正面、左右に壁があるかの分岐が必要になる。奥から書いて塗りつぶしでいいのか？

見た感じの問題

とりあえず描画できたワイヤフレーム表示だが、よーく見ているとどうも感じが違う。
表示が間違っているわけでなくて、受ける感じが違う。
お手本はWizardryですが、こう地下に潜っている感が全然わかない。Wizardryの画面の画像を検索し、それを参考に書き直し。
書き直したものを見ると、以前のものとは迫力が違う。雰囲気が出てるw

ワイヤーフレームのマップ

擬似3Dダンジョンをワイヤーフレームで描く。位置と向き固定で、マップデータをもとに描画することができた。最大3マス先まで見渡せる状態。描画に必要な全座標を割り出して、あとはマップデータ(壁ありなしとか)をもとに描画(線を引いているだけだけど)。
アルゴリズムもへったくれもなく、力技としか思えないが。次はマップデータをデータファイルにちゃんと持たせ、それを読み出して描画させる。

ワイヤーフレームのマップを描こうとしたが

座標をとり、直線を引く形で作成。各マスの情報の保持の仕方が問題。

Androidアプリ開発環境

開発環境の構築を紹介しているページを参照してセットアップ。 eclips(日本語化版)は素直にWinRARで解凍しておくべきだった。 適当にエミュレータを起動してみたが、動かん。 あきらめたが、あとあと調べると、激重が当然だったとは...

ワイヤーフレームで擬似3Dダンジョン

何マス先まで描画するか、向いている方向、壁や扉や階段、マップデータ保持も含めてどうやって処理するのか。難しいというかおもしろい。

開設

2011年11月8日 開設しました。