第１５２回　１つ目のトラウマ

 

軽く前回の続きからです。

なんとかよくわからないシステムから逃れたものの、
デザイナーさんとしては、その画面を一新したい。

新人に何を期待しているのやら。

それまでの画面はカーソルを合わせてボタンを押すだけの、
単純なお買い物画面でして、データ整理さえできれば、
そこまで問題なくできます。

当時のミナミは、前担当者のソースをいじっているだけだったので、
まだセーブ・ロード関連を自分で作ってはいなく、

データーの整理なんてほぼしてません。

そんなミナミも今はデーター管理の責任者になっています。

そんな単純な画面だったので、新人のミナミでも、
変更可能だろうと担当を割り振られたのですが、

そんな大幅に変更するなんて！

話が違うぜ・・・・・デザイナーさん。

ただの買い物画面を

スロット風にするなんて！

考えが飛びぬけてるぜ・・・・・デザイナーさん。

というか意味がわからない。

買い物 = スロット　の意味がわからない。

飛びぬけたセンスがあるから、デザイナーになれるのですね。

そんなわけで一から作り直す程、

プログラム力があるわけでもなく、

前の担当者のソースを全部把握できる程、

プログラム読解能力があるわけでもないので、

前のソースを流用しつつ、なんとなくで作ってました。

もともと単純なプログラムな事もあり、
変更はしやすかったのですが、
それでもなんとかデザイナーさんの注文通りの物を作り、
OKをもらいました。

たぶん今なら１から作り直して１日で終わらせるプログラムを

１週間もかかりましたけどね。

しかし、本人は何とかなったのでホッとしていて、

完全なチェックをしなかったのです。


だいたいソースをしっかり把握しないで作ったプログラム。
どんな変数を使っているかなんて、

細かい部分は見ていません。

その変数に数字を入れているのはわかりますが、

どのように宣言されているかなんて、

見てなかったりします。

実際にプログラムを把握していると、

細かい部分まで目が行きますが、

把握していないので、

面倒になって、解析をやめてしまうんですよ。

だから大変な事になったりします。

符号なし整数型にマイナスを入れたり・・・・・・。

プログラマの皆さんはわかりますよね？

これがどれだけ大変な事か。
これがどれだけ初心者ミスか。

前の担当者がunsignedで宣言していまして、
マイナスにならないように組んでいたのですが、

ミナミはそれを知らずにマイナス判定を下にズラした。

だから、とんでもない値になり、

暴走していまいました。

このどえらいバグが発見されたのは

発売後。

今でもトラウマです。

これ以来、ミナミはunsigned型を

一生使わない事を心に決め、

そのような宣言を見つけたら、

すべて符号ありに変えています。

だいたい今のゲームの容量なら、

unsigned型にしなくも問題はありません。

そんなわけで今回はトラウマになったお話でした。

皆さんも気をつけましょう。

今は逆にオーバーフローしてる時がありますけどね。

↓記事がおもしろかったらクリックおねがいします。