設計は大切だが納期に追われて仕事をするのに慣れ、まず大雑把でも作ってみるクセが付いたのは案外プラスに働く。何故なら、何からどう取り掛かろうかと悩むあまり頭のなかで完結しない分量の仕事は永遠に設計できず着手されないので、まず書いてみて考えをアウトプットし、コンパイラに怒られてバグを実行時に発見して作り直すという手順はプログラムにどれほど慣れてもすっ飛ばすことは出来ない。
それゆえ、昨日まではあんまりに行き当たりばったりだった部分を書き直すわけだけど、その手順を消し去って出来上がったプログラムを細切れにして生徒や後輩に「こう書くんだよ」と教えるのはいかがなものか。マズいままギットハブして絵描きさんのタイムラプス動画が如くプログラミングの手順が残ればと。
そんなわけで今日はマップを作って簡単な接触判定。昨日までのコードは幾分マシにしたが今日のコードも行き当たりばったりでひどいもんだ。だけど、いきなりマップファイルをリソース読み込みとか圧縮解凍とかは出来ないので、配列ベタ打ちから始めている。遊べてしまう。もし職場でこんなプログラムを実行テストしたらファミコンのエミュか何かで遊んでいるようにしか見えない。そこがマズいところだ。
今日書いた物理エンジンのバグで高いところから画面端を少し超える辺りを狙ってジャンプで飛び降りると落下の慣性がかかりまくった状態で接触判定を通り越してマリオが画面外に落ちて帰ってこなくなる。これもマズい。後々なんとかするが今のところ良い対症療法が思いつかない。
マリオのような自由度の高いアクションをどんな操作にも耐えうるデバッグと設計をするのって意外と難しい。
