update.txt

//120329:当たり判定は矩形で、物体の移動はベクトルで行う分担分けをする
//120404:Materialに場外判定を付ける、publicなのでprivateにするための作業
//120415:プレイヤーの移動モードの切り替え、pointingがごちゃっとしてきたのでリファる。
//120417:プレイヤーの移動を実装、ベクトルが砲台用に使われているので、そこを何とかする、移動用のベクトルと発射用のベクトルとを分ける。
//120423:プレイヤー操作について、キーボードのイベント受け取りとパラメータの操作になにか一枚噛ませたほうがいいんじゃね？パラメータを操作するコードが複数メソッドにまたがっててうぜえ、コントローラクラスを新規作成、キーイベントを受け取り、ゲームにとって理解可能な命令に置き換える。命令を置き換えるだけのクラスじゃあっても意味ないどころかコードの冗長性がましてしにたくなるだけ、もっといい事が欲しい。次はいよいよベクトル計算をやりたい。
//120424:描画を分けよう、矢印を表示するクラスを別に作るのだ,ベクトルの合成がわからぬ、平面座標から極座標へ変換する方法がいまいちわからん、三角関数の逆関数でも使うのか？コントローラが行き詰まる、２つの方向キー同時押しに対応できねえ、解決策が必要
//120425:ベクトルの合成が半分完了、角度が何か違う感じ、付け焼刃でatan2()を使った報いやね、appletの座標系をチェックして、自動でテストする関数を作ろう。角度だ、とにかく角度が問題、乗ってる世界事態の座標系、角度をチェックしねーとアカンで
//120427:なんとかベクトル合成終了、ベクトルを扱う部分が分散しているのでひとつにまとめるリファクタリングを行う、pointerにはgettersetterを持たせてmaterialからそいつらを使って角度の変更を行う。関数名に注意。
//120501:いよいよ衝突判定の実装、その下準備としてキャラを四角く描画する。バグ、弾の重力影響計算を分けてやっているが、発射タイミングによっては弾の重力制御が1フレーム分ずれて弾の軌道がずれることがある、コントローラクラスから間接的に操作させることでバグは取れるものと思われる。
//120503:コントローラーに躓く、KeyPressとKeyReleaseの仕様に苦しめられた。自由落下モードの時はスティックの操作を不可能にする
//120507:1フレームごとにボタンの判定を行なっているので、ボタン押しすぎる問題が発生(弾が一度に4発くらい出る、モードチェンジが複数回為される)、数フレームごとに押させる仕組みが必要。
//120511:ボタンを5フレームに一回押すように判定させたい、弾が出すぎてる,そのような制限機能はControllerに持たせるべきかBehaviorに持たせるべきか・・・？
//120515:着地関係の一歩目、ベクトルの補正、壁にぶつかった時などにベクトルを補正する、縦横方向のベクトルが取り出せりゃ終わり
//120520:めり込んだ状態で動けちゃうので何とかしたい、4方向にぶつかった、めり込んだ時点で位置を補正してやらねばならない、座標の補正を各種Operationに持たせる。
//120522:物体の座標の補正がうまく行かない、補正された無いはずの弾と同じように動く→弾と共通のコードが何かいたしている可能性大、それさえできればめり込みの問題も解消される、あとはリファクタリングしよう。
//120528:物体の衝突問題、だいたい解決、原因はSensorDot、座標関連の情報をしっかり把握してなかったのが問題、要は俺のミス、天井にぶつかった時の補正と、接地かつ接天井の状態の時の処理を何とかしたい、
//120531:弾とか敵とかを実装する前段階として、当たり判定のクラスを作成、お次はMaterialに当たり範囲を実装してCharaを作り、Player、Enemyを実装という流れ、さらに管理者も作りたい。管理者の処理が微妙に定まってないのでちゃんと定めて取り掛かりたい
//120602:MaterialAdministratorの実装をしよう、現行のPlayerは一旦無視、物体管理者に物体を追加してきっちり動くかを確かめるノダー、
//120602:相対範囲を導入したらHitterのあたり範囲がよくわからんくなった。そこらへんをきっちり整理しろ
//120605:物体管理者に全ての物体の管理を一任させた。キャラとそいつが生成する弾は同じ扱い、プレイヤーか、敵かは、登録時にタグか何かをつけて判別するようにする。
//120606:当たり判定が動いてないくせェー、色々チェックしろ、隅から隅まで全部だ！MAの衝突判定あたりがおかしいくさい。MAの適切なリストに物体が振り分けられてないバグは直した。
//120608:当たり判定に関するバグ取りは終了。新しい関数作ったらそのTestもしようね。Materilaに管理者を保持させるのはやめにした。逐一管理者のaddを呼び出すほうがいいだろうという判断。次はダメージとかそういうのやろう。ダメージってことは敵がいるよね、それやろう。
//120611:Behaviorを少しいじる。次はそろそろ敵の追加、それともステージの実装？ステージの実装のほうを先にやるべきだろう、なので次はそっちをやる。
//120612:Stage作成開始、しかし、その前に壁への激突判定で不安なところがあったので修正、コードをいじって対応したかったが、無理だった、今後の政策に不安が残る、センサの位置をずらして対応。
//120614:センサ関連のバグ取り、リファクタリングするつもりだったが、座標情報の更新をきっちりしたら思い通りに動いた、前回いじった時にそこが正常に動作しなかったのは何だったんや・・・ステージの作成を始める、テストもきっちり作ってそれなりに順調
//120619:ステージのデータを外部CSVから読み込めるようにしたい、CSVReaderを作り始める。
//120620:CSVファイルを読み込んで二次元配列にするプログラムを書いてる、ハマった。
//120625:アホらしいミス、メソッド内のローカルな配列に値突っ込んで初期化されていないクラス変数を返してた。そりゃ初期化されるわけがねーわな、コードを最初から読み直す癖をつけよう
//120627:ステージとカメラ関連を何とかしようとしたらものっそい状態になったのであばばばば、このバグは取るのに一週間くらいかかりそうだ
//120628:DRY原則に則ってというか直交性を失うような修正だったので大々的に戻す、カメラの挙動をしっかり考えて実装していこう
//120702:カメラの修正完了、座標系は問題ない臭い、でも不安だからTest書こうね。あとは描写なんだが・・・不安だ。とりあえずMaterialに描写座標を付け加えて・・・と考えている、当たり判定のHitterにも座標系があったな、いちいち変更するのめんどいし親クラスを一個作って座標系の操作をまとめよう。
//120703:とりあえずDrawObjectなるクラスを作成し始める、テストも作って確認ができたら他のクラスに継承させよう。
//120704:DrawObjectテスト完了、実装の前にStageのテストをしたい、TDDってのが少しわかっていた気がする、Testとともに開発。
//120706:Stageのmoveのテスト完了、いよいよDrawObjectを組み込んでいこう
//120710:BlockにDrawObjectを継承させて、描写座標を移動させようとしたがうまくいかない、描写座標は更新されているが、描写がなされない、何故だ。main内の背景描写メソッドになにかありそう。
//120711:ステージが移動に伴って動くようになった、mainの背景描写周りの理解が甘いので使用されているクラスを徹底的に調べよう。Playerの描写がおかしい、描写される位置と実際の位置があっていない。
//120713:結局Playerに記述されていたメソッドの名前が間違っていたため、Playerの描写座標を制御するメソッドが呼ばれていなかった。そこを直したらうまく動いたのでおｋ
//120717:SensorとHitterにDrawObjectを継承させて描写位置を正確な位置にするようにした。両方共管理者があるため、そちらの抽象クラスも用意できれば楽になるかな？と考えたが、両者ともに実装上の違いがあるからやらないほうがいいかもという結論、今後似たようなクラスが増えたら抽象クラスを実装しよう。そろそろソースの複雑さが上がってきたきがす。リファクタリングする？でもどこをどうやればいいのやら。
120718:見栄えがだいぶ良くなった。リファクタリングと言いながらMAをいじっていた。当たり判定の初期値で描写されてて一瞬妙な位置に弾やプレイヤーの当たり判定が描写されるバグを除去。原因はMAのallOperation内部のallDrawとallDrawMoveの実行タイミングのズレ。動いてない状態で描写してた。
120720:いちいちステージ全てを描写すると重くなるのでそこらへんを何とかしようとしたが思いの外苦労しそうなので断念。それよりも、BehaviorとPlayerとの関係を修正したい。API的なものを用意するアプローチは良いが、どこに用意するかが問題になってくる。Enemy追加でBehaviorを使い回せるようにしたいので、コードの配置などを考えたい。Playerのコードが肥大化してきているので、それも何とかしたい。敵の簡易行動パターンを使い回せるように設計したい、そうなると行動パターンを形成する基本的な動作はクラスにベタ書いたほうが無難か？クラス固有の動きもあるし。敵の振る舞いと自機の振る舞いは異なるので、Behaviorを継承してPlayerBehaviorとEnemyBehaviorを作るようにするべきか、そうなると抽象化が必要になるので、そもそも振る舞いがどのようになるのかを考える必要がある。
120723:Characterに振るまいクラスを集約し、MAで管理する方法に落ち着く、本当にコレでいいのだろうか？不安だがとりあえず進める、Characterのコンストラクタで振る舞いを取り込めるようにする。敵の振る舞いと自機の振る舞いをうまく分けたいが、同じ関数でクラスごとに処理させるのはきつそう、自機用の振る舞いと敵用の振る舞いを別々に用意するのがベターか？
120724:そもそもPlayer固有となるはずの振る舞いをBehaviorとの継承関係を通じて統合しようとしたのが間違いだった。PlayerBehaviorは孤立したクラスでいいし、そのほうがしっくりくる。次はEnemyの作成にとりかかろう。
120725:敵の振る舞いを実装することに成功。もう少しなんとかならねーかと思いつつの実装。あまり物体管理者の負担を増やすのも考えモノ、たくさんの管理者がそれぞれ一つのことを管理している方が直交性高くていいと思った。次は攻撃とかを実装してみよう。
120727:当たり判定の処理、事前に作ってあったのはいいが、弾や自機などの区別をしないので、そいつをどうするか考えた。各クラスに敵(もしくはその弾)と自機(もしくはその弾)のオブジェクトを渡してそれらに応じた処理を実装する。プレイヤーの中のhitメソッドから敵の中の「当てた！」メソッドを呼び出して、そいつの中を見て処理を決める。そのような流れなら色んな弾や敵の種類の拡張を許す形になるので、次はコレでやってみる。
120730:当たり判定の処理の分岐をなんとかしたい。オーバーライドをうまく使って同じ記述で複数の処理を実現したいがうまくいかぬ、Javaそのものへの理解が足りていないようだ。リストを使うことによって、リストからオブジェクトを取り出す時にMaterialでキャストしている。このため、型がMaterialに固定されてしまい、多態性が機能していない。コレの解決策としてクラスに名前を持たせて、そのクラス名を取り出して、改めてキャストしなおすという方法を考えた。コードが混乱していて微妙にうまくいっていない。少し頭を冷やそう。
120731:そもそも物体管理者の中に当たり判定を含めるのがおかしい。新しくするべき、そもそもそれだ。物体管理者中の物体を保持するリストをキャラと弾で区別するように改修。これで当たり判定の処理も含めれるようになった。当たり判定がなされたキャラや弾の反応をそれぞれのクラスに記述することにしよう。
120801:何か9割方同じ関数があるのがきに喰わない、こういうのがないのがOOPのはずなのに！リストからオブジェクトを取り出す時にキャストしてるのが問題なら、リストの型を予め固定してキャスト不要にすればイイ。キャラと弾で物体を保持するリストを分けたんだし、取り出す時に適切な型でオブジェクトを取り出せれば可能なはず。
120802:ジェネリクスとやらを使ってみたが型がしていされない。そもそも使えていなかった疑惑。リストに型を適用するのに必要そうだから習得しよう。
120806:ジェネリクスが全ッ然理解できねえ。まずジェネリクスの勉強しよう。
120905:久々にいじる、ジェネリクスがどうのと悩むのはやめにした。とりあえず進もう。完成させるのが先だ。
120916
敵が弾を発射できるようになったが、それに付随する問題が2つ。
まず、敵の振る舞い管理者について。
管理者が死んだ敵を排除していない、そもそもこういう処理も物体管理者側でやるべきか？それともキャラ管理者とか作ってその中に入れるべきか？どちらにしろ、似たような処理を物体管理者とキャラ管理者でやらせたくない、保守のコストがズンズン上がる。
次に、Behaviorについて、Behaviorごとにクラスを切るとか正気の沙汰じゃない、キャラに振る舞いを登録して、それに従わせるのが一番スマートに思える、そうすれば上記の振る舞い管理者の問題も解消されて、全てを物体管理者に任せれる気がする。
それからその日の記録を全部一行にまとめるとかいうのも後から見なおして見づらいので、今回からちゃんと改行も入れよう。
120923
敵とプレイヤーのふるまいのを物体管理者で一元管理。
敵味方共通の親クラスBehaviorをもたせた、これがなんの役に立つかと言われれば微妙だが、振る舞いを同じ族として縛るのは後々有効かもしれん。
120924
物体の大きさを変えれるようにした。
物体の大きさを元に描写などを行うようにすればOK?
次に何をしようか見えてこない、順当に行けばゲーム本体をいじる時期か？
ゲームオーバーやゲームの状態遷移に着手したい。
120927
細かいところを手直し
サイズを変えて変な動きにならないようにした。
物体の壁や天井にぶつかった時の補正を物体の大きさに合わせて行うようにした
物体が地面にめりこまないように速度の調整など
121005
ダブルバッファリングとか調整してる。
ゲームの状態遷移を実装するにあたって、mainを綺麗にしている。
paintとかimageとか正直ﾜｹﾜｶﾒな状態。
121008
mainの挙動が少しづつわかってきた。
それに加えて、物体のセンサーと当たり判定の描写が微妙にずれる問題を解決しようと頑張ってる。
DrawObject周りの不具合っぽい事は分かったがそれ以上はわからない。
物体の座標を中央に固定して動かしてる時に不具合が生じている事は分かった。
もう少しやったらゲームの構造の変革に乗り出そう。
121009
MaterialAdministratorのダイエットをした。
物体リストで保持していたデータを、物体リストとそれを継承したキャラリストにクラスとして切り分けた。
物体管理者側でやっていた処理を、物体に適用する処理やキャラにしか適用しない処理などを各マネージャに分けることで物体管理者の負担が減る。
衝突判定についてもやりやすくなるはず、衝突判定はこれからやる。
上記の変更に伴いコードを削減。
121024
Controllerのリファクタリング、とりあえず時間を保持する値をControllerに持たせた。
次は、ボタンをクラス化したい。