６１８日目

　?.http://onc.li/OELiCX#http://www.kotaku.jp/2010/05/smb_starscramble2.html
　オホホ、なんとなく好感が持てるエミネムのゲーム論（？）
　でもまぁそうかもねえ、実際にリア充の中のリア充のエミネムには、ゲームはそういうモンでいいんだろうなあと。
　他に一杯楽しいお付き合いとかあるんだろうし。というかエミネムだけじゃなく他のリア充の方々にとって・・・
　
　でも今のゲームの売り上げの中心はモチロン、リア充の人ではないので、その意見は多分汲まれないんでしょうなあ・・・
　
　もう１個ラッパー×ゲームねたで
　http://www.kotaku.jp/2009/08/ice_t_gamelife.html
　乳めちゃくちゃでかいな（そこかよ）
　身体つきがエロイから結婚するわってのも即物的で、いかにも（ギャングスタ）ラッパーを地でいくなあ・・・
　
　アッチでは割と実在するラッパーがゲームに出演、というかメインに据えたゲームもあるみたいです。50centとか。
　「50セント: ブラッド オン ザ サンド」
　
　?.豆乳
　getPatWidth()って命令があって、カッコの中に、$pat_neko_1みたいに画像を指定すると、その幅が出るっていう関数なんだけど、
　getPatWidth($ziki.p)　みたいに、○○のクラスが持った画像・・・と指定した方がずっと汎用性があるよな、広がるよなと。
　いやそんだけ・・・似たことには気づいてたけど・・・なるほど。そんなに使う場面も無い気がするが。
　
　前は
　str_ = "$pat_neko_" + kazu;
　みたいに、文字列に画像ナンバーを組み込んで、getPatWidth(str_)　ってしようとしたんだっけ、これは確か上手くいかなかったんだよナ・・・
　
　
　あとは黒ビッチの新脱衣方式、に少し不明瞭なところがあったのだが、解決を思いつく　これでいける・・・はず。
　５月中に完成？　毎日を精一杯努力していきたい（首相風に）
　
　しっかし既存の１〜３面をそのまま組み込めなかったのが痛かったよ、わざわざ結合したんだもんな
　繰り返すがC++なら・・・普通のゲームツールなら、面をフォルダごとに分けれて、そこに飛ばせばいいだったかも知れない
　豆乳の場合、サブフォルダに行くはいいが戻って来ることは出来ない、という仕様なので、面セレクトとしては不十分なのだ
　
　がまあ・・・それだけなら、共通してるクラス名や画像名を変えて（これも一苦労だけど）同一フォルダにぶちこめばいいだけだったかも知れない、しかし自機に関する処理などまだパワーアップさせる予定があったので、ここは共通にしないといけない
　でこれまた自機に関する処理は一定じゃなく・・・常に１〜３面と進化していったんだな・・・
　
　ziki_motoみたいな親クラスを継承していたかと思えば、２面みたいにローションで動きが遅くなるのもある（これ、海の中に入った時の処理と同じで、海の処理と分けられておらず、無闇に大きな関数になってて困っていた）
　こうして書くとzikiというクラスに１面〜３面用の、個別の処理を分けて子としてくっ付ければ良かったんだろうか、まぁそういうのも考えましたが、細かい所で色々と違い、共通部分（親）のzikiさえ作るのが手間になる、という感じだった確か
　
　まだアンゼリカ、黒ビッチ用のを書かねばいけない。zikiの記述は簡便にしておきたい・・・
　あとenemytamaというクラスで自機との当たり判定をしていたのが１面。かと思えば、２面以降のenemytamaとの当たり判定は、zikiの方に書かれていた・・・。
　１面のenemytamaの処理を自機に移すか。だがエラー噴出かも・・・なぜなら、自機と敵弾当たった時に自機を動かす処理とか、自機に当たったことを前提として書いたりもするので。その値をまた他に引っ張ってたりして・・・ナハハ
　（＊ちなみにこれ、３面ではzikiクラスに関数として置いてある処理・・・）
　
　１１１は当たり判定に関する新しいクラスを作ることにした。そこで全ての当たり判定を常時監視するのだ、おお
　しかし１〜３面のそれぞれの当たり判定を１つにぶち込んでしまったことで中身は肥大化、しかもビミョーーにコードが違うことで、共通化もできんという状態に
　結果的に見づらくなる・・・
　あと常時監視であったせいで、当たり判定無しのenemytamaが出現即死亡したりして（＊設定される前だった）その対応の必要も出てきた（コンストラクタで解決）
　
　こうして書くと、また無闇に１１１の製作期間が伸びつつあるなぁと分かるけど、対応自体はそうそうまずくない・・・というか、これだけ仕様がコロコロ変わっているなら、ある程度チグハグになるのもやむを得ないと思う。
　問題の急所は、いまも黒ビッチとアンゼリカは脱衣新方式と言ってることからも分かるように、仕様がころっころ変わる点である、ある時はこっちの方がいいんじゃねー？　というシステムの練り込み、またある時は、プログラムの腕の向上に伴った意識の変化で。（一件良い事のように思えるが、まとめる時にはすげー苦労するわな・・・）
　
　しかしビジョンとして少し見えるのは、こう、完全にクラスとして分離しており、必要な時だけ引っ張ってくる。これを理解し、設計していたなら、１〜３面の仕様が大幅に違えども、容易に着脱可能というか、そんな感じではなかったかと。
　だって少なくともステージごとにバラエティがあるのは当然じゃんね。その上で処理が動く。まぁ、１面ごとに自機のシステムが変化するのはさすがに珍しいが・・・そして、見た目変わらないのに内側の処理方式が面ごとに変化してるのは前代未聞だと言えるが・・・
　
　初めに仕様書を書くでしょう、大本はそれ固定。で、ステージごとの変化はハンコのようにばんばんコピーして違う部分を付け足す、というのが理想なんでしょうなあ・・・
　関数の名前が同じでも、中身がコロコロ変わったら普通に動くわけない、そういうことですな。いや引数の数が増えてくだけなら実は対応する手段もあるけど、なぜか既存の引数に対する処理もコロコロ変わっちゃうという。
　まったくイカレてやがるぜ！
　
　度重なる仕様変更でプログラマー切れるとかよく言うけど、なぜかそれを自分で指示し自分で組んでいるという究極のひとりSMかい