スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。



今日はエルク画像

今日はエルクの戦闘アニメーション画像を追加しました。
エルクは現存する動物なんだけど,これという動画がなくて困った困った。

調べて調べて見つかったのはコレ。

http://www.youtube.com/watch?v=3pPvWoAyuJU


メスを奪おうとするオスと,メスを囲うオスが対峙するという構図。
面白いのは,戦っている間に,横から別のオスが奪いにいくというwww

人が一生懸命戦っているのに,まさに横取り。

でも横取りオスはメスから相手にされていないみたいwww

さて,次の画像にいくか。
スポンサーサイト



ジャッカルアニメーションの追加

今日はジャッカルの戦闘アニメーションを描いてました。
今回もYouTubeの動画を参考にしました。

これ
http://www.youtube.com/watch?v=Kzy6qgL8tdk


ジャッカルが仕留めた獲物をカラカルが奪うという動画です。
カラカルが途中,ジャッカルに襲われながら食べているんですが,
「味えないよね」と思ってしまいました。

最終的には草むらに逃げていって,落ち着いて食べようとしているんです(そりゃそうだよね)
それでもジャッカルはあきらめがつかないみたいだけど...www

カラカルとの戦闘をコマ送りで見てみると,
攻撃しようとしているけど,当ててない。
当てようとすると自分も怪我するから,ってことなんだろうか?

生きるか死ぬかの瀬戸際での喧嘩ってコワイ。
人間に生まれてよかった~!!

ということで,ジャッカル画像完成ですwww



ガルスガルスの戦闘アニメーションを追加

この前の続きで,説明文の文字列を定義していました。
思った以上に文字数が多かったので,3行だけでは表示しきれなかった。
4行に変更して,対応する画像も4行分に修正。

ユーザビリティがこれでかなりあがったんじゃないかな。
(単純に自分が忘れているからってこともあるけど)

次に,ガルスガルスの戦闘アニメーション。
闘鶏の動画を参考に画像を作成しました。
闘鶏...日本じゃ禁止されているみたいで,
TVでしかみたことなかったですが,手に汗握りますね。

http://www.youtube.com/watch?v=Lr4cLU8zpWw


YouTubeは本当助かる。
昔の人は動物園に行ってたんだろうな。

動物画像は1日1枚が限界かなぁ。
となるとやはり制作期間は最低1ヶ月はかかるってか...。
たいへーん><



備忘録

Androidのテスト自動化について @IT
http://www.atmarkit.co.jp/fsmart/articles/androidtest02/01.html

DBを実装するときのパターンおよびテストを考慮した設計
http://www.atmarkit.co.jp/fsmart/articles/androidtest04/01.html



文字列定義...

今日はエミューの戦闘アニメーション画像を用意。
画像を変えてみるとテンションあがりますね。

次にテクノロジーの取得条件と効果の説明を定義。
といってもまだ終わっていないんだけど。

説明文の定義って凄く時間がかかる。
間違いやすいし。

携帯アプリって説明書がないだけに,
アプリ内に説明を追加しておかないと
どんなアプリかもわからない。

って前作のとき言われて,急いで作った気がする。
今回はその反省を活かして,先に用意してます。

明日も説明文の定義かな。
あとはアニメーション画像か。
一日一枚でも17日かかる...。
主人公も合わせると25日くらいか!!!????

って1ヶ月。
1日3枚以上は作っていけたらいいな。



バランス調整しながら...

序盤の動物,鶏(ガルスガルス)のステータス調整。
クリティカルの発生確率を5%にしていても,意外とでるもんですね~。

調整しては,直してという作業です。

セーブデータのヘッダ情報に不具合があったので修正したり,
アイテム拾ったときに研究レベルを表示するようにしたり,
細かい変更をちらほら。

いま残っている大きな作業といえば,

戦闘画面の主人公, 動物のアニメーション画像の用意。(超デカイ)
街画面での人画像の用意。(ファイルサイズが不安材料)
街画面の不足している表示情報。
オープニング,街画面での村人とのやりとりの仕組みを考察・実装。(大...というか全く考えていない)
各画面のスレッド化。(小...やることが決まっているので力技)
マップ画面での移動コスト表示の画像用意。(中)

ロード時の視界情報が不正になる件を修正。
各不具合を都度対応。

優先度の低い作業
遊び方の充実。(どの点がわかりにくいかのヒアリング等の後に作業予定)


当分は,アニメーション画像とバランス調整を平行するという感じかな。
うむ...またもや画像か...でかい山だぜ。



セーブデータのフォーマット変更

ゲームクリアしたかどうかをセーブデータに保存してあります。
何に使うかは秘密ですけどwww

こまったことにboolean型が書き込まれるときに1[byte]で書き込まれるってこと。
booleanは1ビットで表現できるのに1[byte]って,どうやって書き込まれているのかつー。

Javaの仕様書を読めばどこかに書いてあるんだろうけど,
めんどくさかったのでw,一度読み込んで,クリア状態部分までのデータを再構築して
コピーという手を使いました。

セーブデータのフォーマットがこれで落ち着くといいな。


ニュースを見てると新しいワークスタイルがあるみたいですね。
前々から気にはなっていたんですが,コワーキングとかノマドワークとか...。
テレワーキングって理想ですよね...。

ただTVでやってた徳島県の神山町は,さすがに遠すぎと思ったけど。
東日本は大地震がおきやすいってこともあって,西日本にサテライトオフィスを置くことは
リスク分散としてはいいことなのかもね~。

家賃が激安で生活に困らない都市ってないだろうか...。

てか確定申告いかないとな...。



セーブデータを2つ

花粉症で頭痛に悩まされているBoBです。

この3日間セーブデータを増やすことにはまっていたわけなんですが,
やっとこさ終わりました。

レコードIDを管理するようにして,
セーブデータの保存IDであるスロット番号とのリレーションを保持するようにしました。

あとは3つに増えようが4つに増えようが,どんとこい。
なんて,アプリのサイズによって制限があるので,どこまで増やせるかは不明。

戦闘画像等を入れ込んで,アプリサイズに余裕があれば
セーブデータを3つに増やしていこうと思います。

作りこんだ箇所を再設計しなおしたので疲れましたが
セーブデータが増えたことはゲームの利便性があがったはず!!

機能的に不足していた保存先変更画面もひと段落したので,
次の作業を....
って何してたっけwww

4日前に自分が何していたのか忘れてしまったwww
バランス調整だったかな。
ブログをたどって次の作業だ!!



大ハマリ中...

神様,セーブデータをひとつ増やすことを簡単だって思ってしまってゴメンナサイwww

マジではまってます。
ひとつのセーブデータを増やすことがコレが大変。
2つのデータを3つにするには簡単だけど,
1つのデータを複数にするのには,つくりを大きく変える必要がありましたぁ。

そしてまだセーブもできなければロードもできない。
あと1日あればできるか...。

まさかこんなところで足踏みしちゃうとはなぁ。



CCLIPのバグ

J2MEにはプリプロセスやenumがないのでCCLIPというプリプロセスを使用しています。
http://www.vector.co.jp/soft/dl/winnt/prog/se271920.html

今日はこのプリプロセスの不具合にやられました。
RecordEnumerationインターフェースのenumerateRecordsメソッドを実装したのに,
プリプロセスを通すとこのメソッドがなくなってしまう。

なくなるとは...

recordStore.enumerateRecords(null, null, false);

が,

recordStore.

多分enum型と勘違いしているんだろうと思い
試しにファイルの頭で以下のように定義したら問題を回避できた。

#define ENUMERATERECORDS enumerateRecords

もちろん,このときのコードは

recordStore.ENUMERATERECORDS(null, null, false);

になります。

このプリプロセッサにはかなり助けられているだけに,
今回の不具合は目をつむっておきたいところ。
開発も終了しているみたいだし。



セーブデータ2つ!?

セーブデータのサイズを計算したら
1スロットが約10KBになることがわかった。
このサイズならば,セーブデータを2つくらいはいけるんじゃないかな。

ということでセーブデータを複数保存できるように実装してました。
セーブデータのフォーマットが変更になったため,
いままでの保存データが使用できなくなっちゃいました。

画面が終わったと思っていた矢先,
セーブデータの保存先を選ぶための画面が必要になるので,
画面を作らないと...。(これはまだ)



あと大きな実装は戦闘アニメーションをOFFにする機能を実装しました。
Image.createImage()でOutOfMemoryErrorがでてしまう問題に
対応できるかわかりませんが,
小さい画像を読み込むことでエラーになる確率を減少させようという魂胆です。

アニメーションがウザイっていう人にも対応できるので,
機能としては有りかと。

これによって作業量が増えましたが,
プレイできる人数が増えれば,たいしたことない...と思いたいwww

さてセーブ先変更画面を作るか。



よ~し

今日はクレジット画面と他1画面を作りました。
これで想定している画面はすべてできたことになります。

あとは演出やリファクタリング等の作業だけ...
またひと段落というところですね。

これでまたバランス調整に一歩近づいた。
がんばるで~。



遊び方画面の実装終わり

遊び方画面の仕組みの実装は終わりました。
あとはレイアウトなどの表面的なことや,
説明する内容を充実させるなど。
(キー制御時の音の処理はいれないとなぁ...)

テキストファイルを表示するコントロールを作りました。
オフスクリーン画像をつくって,そこに描画していきたいところですが,
createImage()によるアプリの停止問題があったため,
オフスクリーン画像は使わない方向に。

その変わり,フレーム描画の度に最初の行からズラーっと描画していくことにしました。
スクロールは座標変換処理で対応して,
描画範囲はクリッピングにて対応。

描画遅延も見られないので,ヒープサイズの小さい携帯では,
こっちの方がいいのかもしれない。
(もっと賢く作るならば,キー制御によって移動したときのみ画面を再描画する)


キー制御時の音を実装し終わったら,
クレジット画面かな。
今日作ったコントロールを応用するつもり。



遊び方画面...実装中

お腹減った~。
お腹が減らなければ制作に没頭できるんだけどな。
そういうスイッチが欲しい今日この頃。

そんな今日は遊び方画面を実装していました。
前回説明したサイクルを実装してますが,
テキストファイルを表示するコントロールを作ってなかったので,
メッセージ表示処理で代替してみました。

ただメッセージ表示とは違うから,
最初から作らないとなぁ...と。

テキストファイルを表示するだけなのに,
そういうコントロールを作らないといけないなんて
MIDPって生産性悪いなぁと。

次回も遊び方画面。
テキスト表示処理を実装していこうと思います。



ハイスコア画面の完成

ハイスコア画面に初期化処理を実装して一通り完成しました。

データフォーマットが変わったときの処理も実装したので,
アルファ版をリリース後も対応できるようになりました。

その後は遊び方画面を実装はじめました。
遊び方画面は

リストからの選択
対応するテキストファイルの読み込み
表示
リストに戻る

というサイクルで実現できそうなので,
まずはその大枠を実装していく予定。

今日はお腹減ったので終わり~。



キタ~ッ

花粉がwww

とうとう来たよ花粉が...。
もうすぐ春ってことなんですね~。

花粉時期は頭痛や倦怠感と性能ダウンしがち。
花粉対策してがんばるぺ。

今日はハイスコア画面を実装してました。
初期化処理はまだなので,次はそこを実装だな。

この流れですべての画面を実装していこうかな。
残りは3, 4画面なので,大枠だけでも用意していこう。



ハイスコア

ハイスコアといってもスコア計算してなくて
ゲームクリアしたときの年月などを記録するというものです。

年月以外は,発見したテクノロジー数や,村の発展レベル,人口。

今日は,これらの記録を更新した場合にデータを保存するという処理を実装しました。
次回はタイトル画面から見るレコード画面を実装していこうかと思います。

セーブデータフォーマットが変わった可能性があるから,
初期化処理も入れないとな。

よっしゃがんばるで~!!



戦闘画面の中間発表

戦闘開始時,いきなり開始していたために逃げるコマンドを入力する期間がありませんでした。
先制攻撃したにも関わらず逃げられないのはイマイチだったので,
戦闘開始してからしばらく期間を置くようにしました。

遠距離攻撃は都度,気付くか,気付かないかの2択になっていて,
気がつかなければ死ぬまで攻撃することができます。

気付きの状態をアニメーション内に組み込んでみました。

とりあえず戦闘の仕組みはある程度実装したので,
次回からは~他いけるかな~。

今の戦闘アニメーションを動画にアップしてみました。
アイテム名などは仮なので悪しからず。


http://www.youtube.com/watch?v=emvZ5Qs3Jxc



あらためて...

今日はリファクタリング作業をちょこっとしてました。
コード的な改善要素がたくさんあるので,ちょいちょいやってます。

不具合もいくつかあったので修正。
ロード後にライオンと戦えなくなってたりw
村の発展レベルに合わせて画像が差しかわってなかったり
細かい修正。

戦闘画面の仕組み自体はかなり出来上がってきた。
あとは画面内に表示する情報を増やしたりする作業で仕組みとしてはおおむねできたのでは
と思っている。
ただボリュームがあるのは,アニメーション画像の用意。
とりあえずマンモスは用意したが,他16種類の動物と主人公のものを用意するとなると
結構,時間がかかりそうだ。

先にゲームシステムで残っている,ハイスコアの情報などを先に実装して,
画像についてはバランス調整作業をやりつつ用意していこうかと思う。

あとはシナリオや村でのコミュニケーションをどうすっか...とか。
アルファ版も見えてきたかな!?



復活

友人の933SHで試してもらったが現象がでない。
このことから自分が持っている816SH特定の問題だといえる。
つまりはVM側の問題で,解決策はないようです。

816SHで現象がでるときは大体2Mくらいヒープを使用しているときに集中しているので
空き容量の計算になんらかの不具合があるのかと思う。

933SHでは問題なく動くということなら,
そういう端末向けにリリースできるということで,
問題は残しつつ続けてみようと思う。

Androidでもそうだけど,OS側の問題に対しての修正版が継続してリリースされない。
(2年単位で買い替えが前提だから,古い携帯は除外されている)
これは携帯業界の悪いところだと思う。
今後,PCのように継続的にセキュリティパッチがリリースされていくことになって欲しい。



私の船は座礁した...

ここへ来て不可解な問題にぶつかりました。
こうなると断念することも考えられますが,
何年もかけてやってきたことを水の泡にするも
どうも気が進まない。

原因はわかっても対応策がないとなるとなぁ...。

もう少し悪あがきして,
ダメだったら戦闘画面でとまることを前提にリリースするしかないなぁ。
そんなソフト世の中にないけどね。

続きを読む




省メモリー化

OutOfMemoryErrorが発生するのは
Image.createImage()メソッドだということがわかった。

例外の内容からヒープの空き容量が足りないと思い,
まずは空き容量を画面に表示するようにしてみた。
(RuntimeクラスのfreeMemory()メソッド)

Softbankから提供されているとおり,
自分が使っている816SHの最大ヒープサイズは4M。

問題が発生するときの空き容量は約2Mがあった。
戦闘アニメーションに使用される画像は,
大きいもので背景が47KB,
アニメーション用画像 主人公3KB, 敵18KBで
あわせても68KB...2MBには程遠い。

また発生するのが数回戦ったあとということで,
循環参照によるメモリリークが疑われたが...
戦闘前と戦闘後のメモリ使用量を比較しても,増えてる傾向はみられない。
(再度,詳細を調査する必要あり)

このことからもJava VM側の問題のようにみえ
対応することができないと考えられる。

さて,いきなり暗礁に乗り上げたけど
どないしましょう...。

とりあえず戦闘画面の背景画像サイズを横に縮めてファイルサイズを33KBまで落としましたが
それでも問題がでる...。

空き容量との関連性はあまり高く内容に見えるけど...。



OutOfMemoryError

戦闘を何回か繰り返すとプログラムが停止してしまう問題が発生。
なぜとまるか全くわからず,ログを仕込んで調査していくと
画像の取得処理で停止していることが判明。

画像の取得処理はかなり深い低層クラスで起きているので,
例外をそのまま上層へ伝えるように実装を変えてみました。

すると投げられた例外はOutOfMemoryError。
どうやらヒープが足りなくなっているよう...。

ヒープの解放は都度行っているのと,
戦闘が終わったらGCを実行していても
メモリが足りない...。

ここへ来てVMとの相談...ふかーい問題ですねぇ。
全コードの見直しか!????

とりあえずメモリ使用量や画像のファイルサイズを小さくしたりと
いろいろと対策を考えてみようと思います。

今日は徹夜か...><



間違ってた~

Spriteクラスの画像をsetTransform()メソッドでTRANS_MIRROR(左右反転)したものが直らなかった件を
よくよく見てみると自分が書いたコードが間違っていた。
別にsetFrameSequence()メソッドを実行する・しないに関わらず適用されてました><

ということで,従来の形にコードを書き直し。

次は,遠距離攻撃用アニメーションの仕組みを実装。
これにて戦闘アニメーションの大枠は全部実装したことになります。

あとは演出部分の受けたダメージ量表示や,戦闘の状態・結果を表示するなどなど。

ただ困ったことに戦闘が始まるときに固まってしまう不具合が発生。
マルチスレッド化したことが問題かと思うんだけど,
問題は実機でしかでないため,デバッグができない。

リリース用コードを書き換えて対応しているが,まだ原因はわからず。

次回は問題を調査しつつ,演出部分の実装をしようと思う。

やはり戦闘画面はおおっきな山だぁ。。。



逃げる...終わってなかった

逃げるアニメーション終わったかと思ったけど,いろいろと見てたら終わってなかったね。
前回も書いたように逃げるアニメーションはSpriteクラスのsetTransform()メソッドを使用して
左右反転(TRANS_MIRROR)させました。

このとき逃げられなかったら,待機アニメーションになります。
左右反転したものを元に戻さないといけないんだけど,
setTransform()メソッドでTRANS_NONEしても元に戻らない。
Why???

反転したものは反転して戻すのかと思って,再度TRANS_MIRRORしても元に戻らず。
四苦八苦してみたけど,setTransform()メソッド後に
アニメーションフレーム番号を変更するためにsetFrameSequence()メソッドを呼んでいたので
適用されていなかった模様。

setFrameSequence()メソッドをコールしてから
setTransform()メソッドにてTRANS_NONEを指定することによって
反転した画像が元に戻りました。

なんか使い勝手悪いような...。
簡単なプログラムを作って実験してみないと,白黒つけられないんですが,
とりあえずは戻ったのでよしとしようと思います。

あと100%で逃げられてしまう件は,足し算の間違いでしたwww
A + Bにするところを,A + Aにしていて,Aには50が入ってたのですw
凡ミスでよかったwww

またモチベーションが下がりつつありますが,焦らずに着実に進めていこうと思います。
落ち着け自分!!



アクセス
あなたは
キーワード
カテゴリー
最近の記事
リンク
月別アーカイブ
ブロとも申請フォーム

この人とブロともになる

WEB検索
Google

RSSフィード
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。