2007/12/23(日) [n年前の日記]
#1 [iappli] BG当たり判定部分を作成
BGと障害物OBJの当たり判定部分を作成できた。と思う。たぶん。
範囲外の当たりを判定しようとしてる・エラーが出るのでおかしいなと思ってたら、処理ステップによっては初期化されてない座標値を元にして判定処理をしていた。当たり判定処理のバグかと思って散々悩んでしまった…。
範囲外の当たりを判定しようとしてる・エラーが出るのでおかしいなと思ってたら、処理ステップによっては初期化されてない座標値を元にして判定処理をしていた。当たり判定処理のバグかと思って散々悩んでしまった…。
◎ 点数表示位置がおかしい。 :
ソースを見たら、描画処理部分の中に、直接、描画座標値を埋め込んであるようで。とにかく修正が一苦労。
こういうのって、基準位置を指定したら、後はその基準位置から相対的に座標を決めていくような作りにしたほうがいいと思うんだけどな…。まあ、その分、計算やプログラム容量は増えるんだけど。最初の頃の、処理がとにかく遅かった・容量がめちゃくちゃ厳しかった時代の、iアプリ作成のノリを引きずってるのかしらん。＞プロトタイプ版の作者様。
こういうのって、基準位置を指定したら、後はその基準位置から相対的に座標を決めていくような作りにしたほうがいいと思うんだけどな…。まあ、その分、計算やプログラム容量は増えるんだけど。最初の頃の、処理がとにかく遅かった・容量がめちゃくちゃ厳しかった時代の、iアプリ作成のノリを引きずってるのかしらん。＞プロトタイプ版の作者様。
◎ ゲームがプレイできない。 :
BG上の各種記号(?)の配置・初期時のスクロール位置が、プロトタイプ版と本番用では大きくずれたので、各種判定がおかしくなっている模様。ソースを見たら、これも全部、座標値を直接埋め込んで判定してる模様。修正が…。
せめて、元々のBG画像上のどのへんの位置を参照しているか、作業用の画像が残っていれば楽なのだけど。とにかく作業用・開発時の各種座標値取得用の画像は残しておいたほうがいいなと思ったり。
せめて、元々のBG画像上のどのへんの位置を参照しているか、作業用の画像が残っていれば楽なのだけど。とにかく作業用・開発時の各種座標値取得用の画像は残しておいたほうがいいなと思ったり。
◎ 当初予定されていたスケジュール通りにはいかない予感がしてきた。 :
人様のソースを修正していく作業なので、どこを修正すれば追加仕様を実装できるか、非常に把握しづらい。移植モノなら、ソースのコンパイルさえ通れば、それでほとんど作業は終了したも同然なのだけど。どうも、そういう感じには程遠い。
*1
プロトタイプ版を作った人が、そのまま本番用を作るべきだよな。そのほうが効率がいい。けど、 _アインシュタインと秘書の喩え(比較優位) もあるわけで。「〜が〜を作るべき」とは言い切れないのかもしれない。
プロトタイプ版を作った人が、そのまま本番用を作るべきだよな。そのほうが効率がいい。けど、 _アインシュタインと秘書の喩え(比較優位) もあるわけで。「〜が〜を作るべき」とは言い切れないのかもしれない。
*1: そういえば、初めて移植作業を担当したときは、コンパイルが通るか否かが一番重要、ということすら判らずに、約半年(!)も元ソースをただただ眺めて「動作を事細かに把握せねば」と思い込んでたわけで…。別チームのベテランプログラマーの方が、たった2週間で、画面上で色々動いてる状態にしてしまったのを見て、目から鱗がボトボトッと落ちた、みたいな。…つーか、アセンブラからCに移行した状況ってのを、もっとよく考えてから作業すべきだったよなぁ。＞自分。何のためにわざわざ高級言語でソースが書かれているんですかと。そのメリットの一つとして、移植が容易になるってのがあるだろうと。そういったことにピンとくるかどうかが、ダメプログラマーと天才プログラマーの境界線、なのかなと思わないでもない。
[ ツッコむ ]
以上です。