オーラ写真倶楽部の話の続きです。
オーラ占いのプログラマは、先輩社員と、僕で始まりました。
後で説明しますが、途中から僕の同期が追加で入ります。
メインは当然、年長者である先輩でした。
たしか、先輩は占いの中心部分を作ったはずです。
詳細は後日改めて書きますが、オーラ写真倶楽部で「撮影」するオーラは、実はカメラで撮っているのではありません。
オーラを測定するセンサーとカメラは別にあり、ゲーム上で重ねて表示しています。
この部分は先輩の担当。
オーラの表示には、ST-V の自由変形ＢＧ面を使っていました。うねうねと揺らめきます。
占いの結果を決め、画面表示するまでが占いの中心になります。
＃オーラ画像は、オーラ測定パターンによって形も色も変わります。
また、１人用・２人用の占いによっても変わります。
基本的には「それ以外」が僕の担当。
ユーザー入力のＵＩ、プリンタへの出力、その他細々としたこと。
後で追加で入った同期は、途中からＵＩの担当をしてもらいました。
その後の仕様変更もあったので、僕が作ったのはＵＩの枠組みだけではないかな。
ST-V のカメラは、プリント倶楽部などの関係もあって日本語の資料があったのですが、オーラ測定センサーはオムロン製で、通信用 LSI の仕様書がそのまま渡されていました。
この仕様書が英語で、先輩が「俺英語苦手だから、作って」と僕に丸投げしました。
僕だって英語苦手ですが、タイミングチャートとか見ればだいたいやることわかります。作りました。
4bit 通信で、nibble という単位を始めて知ったのはこのときだったと思います。
＃bite(byte) 「噛む」が 8bit に対し、nibble 「齧る」は 4bit。
＃「英語苦手だから」と言っていたのですが、多分先輩はタイミングチャート通りにキッチリ動作するプログラムとかを作るのが面倒くさかったのだと思っています。
ゲーム作っている人で、きっちりした仕様通りに作るのが苦手な人って、結構多いです。
プリンタに関しては、ずっと以前のバイトの経験が役立ちました。
画面上に表示されている、カメラからの画像データと、オーラの画像データがあります。
これを重ねて、RGB CMYK 変換して、減色して印刷するだけ。
減色は、Oh! X でよく使われていたアルゴリズムを使っていたはずです。
桑野式誤差拡散、だったかな。整数演算とビットシフトのみで高速処理できる誤差拡散法。
プリンタ自体は、エプソンの安いインクジェットを使っていたはずです。
この頃、急にカラープリンタが普及し始め、安くなっていました。
オーラという特性上、背景は黒で、その前に薄い色が出ていました。
実は、インクジェットで印刷するときに一番悩ましいのが、この「黒の上に薄い色」で、インク濃度などを試行錯誤した覚えがあります。
さて、途中から追加で入った、もう一人の同期ですが、実は女性でした。
当時、セガに女性プログラマは３人しかいなかったと聞いています。
そして、途中から入った理由は、実は「働く期間の調整のため」でした。
みんなには内緒にしていたのですが、結婚退職することが決まっていたのです。
前のプロジェクトが終わったあと、新プロジェクトに入れると途中で退社することになってしまう。
そこで、ある程度作業が進んでいて、ちょうどよい時期に終了しそうな、オーラ占いに途中配属となったのでした。
プロジェクトの末期になり、もう少し調整が必要だということになって、締め切りが伸びました。
その時に彼女から相談されます。
実は結婚退職が決まっていること。
退職自体は伸ばすことも可能だが、結婚式の日取りと新婚旅行日程が決まっているので、その期間は仕事に来れないこと。
なので、締め切りが伸びたのであれば、いない間の引継ぎをお願いできないだろうか、というのが相談内容でした。
これは、何も問題ないので了承します。
元々ＵＩは僕が作っていた部分をベースとしていますし、何かあった時にちょっと変更するくらい簡単でしょう。
…が、後で悩むことになります。
引き継いだ後、どこかのアニメが動きが悪くて修正することになったのです。
プログラムを覗いてみると、こんな感じでした。
if(anime == 0){pattern = PN_MAIN_CHAR_LEFT_RIGHT_1; }
else if(anime == 1){pattern = PN_MAIN_CHAR_LEFT_RIGHT_2; }
else if(anime == 2){pattern = PN_MAIN_CHAR_LEFT_RIGHT_3; }
else if(anime == 3){pattern = PN_MAIN_CHAR_LEFT_RIGHT_4; }
else if(anime == 4){pattern = PN_MAIN_CHAR_LEFT_RIGHT_5; }
else if(anime == 5){pattern = PN_MAIN_CHAR_LEFT_RIGHT_6; }
else if(anime == 6){pattern = PN_MAIN_CHAR_LEFT_RIGHT_7; }
else if(anime == 7){pattern = PN_MAIN_CHAR_LEFT_RIGHT_8; }
else if(anime == 8){pattern = PN_MAIN_CHAR_LEFT_RIGHT_9; }
else if(anime == 9){pattern = PN_MAIN_CHAR_LEFT_RIGHT_10; }
else if(anime == 10){pattern = PN_MAIN_CHAR_LEFT_RIGHT_11; }
else if(anime == 11){pattern = PN_MAIN_CHAR_LEFT_RIGHT_11; }
else if(anime == 12){pattern = PN_MAIN_CHAR_LEFT_RIGHT_13; }
else if(anime == 13){pattern = PN_MAIN_CHAR_LEFT_RIGHT_14; }
else if(anime == 14){pattern = PN_MAIN_CHAR_LEFT_RIGHT_15; }
else if(anime == 15){pattern = PN_MAIN_CHAR_LEFT_RIGHT_16; endflg=true;}
anime ++;
えーと、PN_MAIN_CHAR_LEFT_RIGHT_1 …とかっていうのは、スプライトに表示されるパターンで、enum されたシンボルです。
左から右に振り返る、という 16 パターンのアニメを、1/60 秒ごとに表示するプログラム。
これ、
pattern = PN_MAIN_CHAR_LEFT_RIGHT_1 + anime;
if(anime==15){endflg=true;}
anime++;
で十分です。パターン名は enum なので、１づつ増加しているのですから。
もし単純増加ではなかったとしても、配列にしてしまえば if の羅列は不要になります。
さて、最初に書いたほうのプログラムにはバグがあります。それが「動きが悪い」原因。
PN_MAIN～ で示されるパターン番号、11 が２つあって、12 がありません。
指定を間違えて、アニメ表示が崩れてしまっているのです。
いちいち if で書いているから起きたバグで、計算で出せばバグなんて起きるわけがない。
気になって調べると、アニメーションするような個所は全部こんな感じ。
…どうしよう。直すべきか。しかし、締め切り間近なのに大きく手を加えると、全部チェックし直すことになる。
何よりも、彼女はまだ「退職」しておらず、新婚旅行に行っているだけでした。
プロジェクトの終了直前には戻ってくるはずなのに、僕が彼女の領分のプログラムに大きく手を入れるのは望ましくないでしょう。
…動いているプログラムは、美しいプログラム。たしか祝一平さんの言葉です。
この言葉を胸の中で唱えながら、結局必要な変更だけを行い、後は一切手をつけませんでした。
彼女はその後退職したとはいえ、主婦になったわけではなく「残業の少ない会社」に転職しただけです。
職種はそのままプログラマー。転職先でちゃんとやって行けたのか心配…
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |