私が携わってきた物。
年はリリースされた年だから、物に依ってはその前年から作業をしている。
東京のプログラマ派遣会社に就職。
COBOL がメインの会社だったけど、C 経験者の選抜組 3 人で C の研修をした。
と言っても講師はいなくて(実務でやっている人がいなかったっぽい)、本を買ってきて自主勉強だった。
研修で使ったのは PC-98XL2、大きな筐体だった。
私はアセンブラ経験者という事で、群馬の通信機器メーカーへ派遣された。
当初は Z80 を使った多機能電話機をやるとかで仕様書を読み込んだりしたけど、その仕事は結局しなかった。
代わりにやったのが、68000 を使った ISDN 構内交換機。
業務で 68000 に初めて触る。
開発機材は PC-9801VM/CV/LT。
同時期に X68000 を買って、公私共に 68000 に染まる生活がスタート。
68000 と云えば MD を買ったのもこの頃だったけど、群馬の田舎だったので本体しか買えず、しばらくソフトが手に入らなかった。
ISDN パケットを受信して、その内容に従って関数を呼び出して状態遷移をする処理を書いた時の事を覚えている。
現在の状態番号とパケット種別番号をインデックスに持つ 2 次元配列に関数のポインタを入れたジャンプテーブルにして、戻り値を新たな状態番号にすれば実装もメンテナンスも楽だと思った。
FSM の実装の定番だし。
でもそれを提案したら、責任者に「テーブルの全ての要素を検査するのが大変だし、漏れがあると困るから」という理由で却下された。
if
や switch
だって全組み合わせの検査をするだろうし、そのやり方で綺麗に書けるとはとても思えなかった。
面従腹背で、何かワンクッション置いてジャンプテーブルで実装した記憶がある。
2000 年頃に用事があって東京の会社があった近所を歩いたんだけど、もう存在していなかった。
タイトーに転職。
面接で千代田区平河町の本社まで行ったんだけど、丁度その頃は当時の宇野宗佑首相が退陣したばかりで、目と鼻の先にある砂防会館の周りに多くの人と車が居たのを覚えている。
8 月に入社して熊谷に配属。
その年の新入社員が研修を終えて熊谷に配属になったのは 5 月の末だから、そう大きく隔たってはいなかった。
開発中の『ダライアスⅡ』が目の前で動いているのに興奮した覚えがある。
グリーンモニタでオールインワンの HP 64000 と『ドンドコドン』の基板でちょっと研修。
ゲーム初仕事は『ミズバク大冒険』。
プログラマは 4 人中 3 人、ドット絵師も半分位が新人のプロジェクトだった。
YouTube で確認をしたら、プログラマは K.ISHIDA / K.NAGAHARA,G.A. / K.TSUNEKIYO / TABBY.K 🐾 と、全員が「K」だった。
当時は気付かなかったな。
まあ普段から K で始まる名前で呼ばれていたのは私だけだったし。
開発機材はウィンドウ環境の HP 9000 Series 300。
標準の IME は漢字変換に癖があって、妙に単漢字変換に強かった。
「みなごろし」で変換する “鏖” の字はチーム内で流行ったっけ。
私のネット源氏名「緇隰」は、HP 9000 で「くろ」と「さわ」を別々に変換した時に出てきた文字が由来。
チームメンバーが発見した、変換しようとすると IME が死んでしまう言葉「へめげれみっちょんどてちてぷう」も覚えている。
基板は F2 System。 仕様は
という感じ。
最初に書いたプログラムは、1 面から登場する水玉模様で丸い殻の陸貝の敵、名前はガオガーラ。
地形に貼り付いて移動して、「目の前が壁」の 90° なら曲がって進める。
後に、ピラミッドの面から登場する蠍の敵も担当。
こちらも地形に貼り付いて移動するけど、「目の前が崖」の 270° の角も進める。
似た様なプログラムだけど、慣れてから書いた後者の方がコンパクトで綺麗に書けて、自分でも驚いたっけ。
水の面のボスは、死ぬ時に☆形の軌跡を描く様にしたんだけど、ちょっと判りづらかったかも。
機械の面はゼンマイ仕掛けのザコ、そのザコを発生させる中型の敵、ボスを担当したので、好きな面。
そのザコを発生させる敵は、当たっても押されるだけで死なない様に作ったのに、PCE 版は当たると死ぬ様になっていて、とても不満だった。
機械の面のボスは、68000 のアセンブラで 2,000 行を超えるソースだったんだけど、ほぼ完成していた物を作業ミスで消しちゃって、作り直した。
でも試行錯誤を終えた後だったので、書き直した方がコンパクトで綺麗になっていた。
前述の地形に貼り付くザコと同じ様な状況に。
隠れボーナスとして、巨大歯車を残したまま倒すと 1 枚につきン点(具体値失念)、パーツ全壊(歯車×2、腕×2、タンク、ピストン×2)でン点(具体値失念)、という 2 通りを設定してある。
歯車を残すのは簡単だけど、パーツ全壊は特にピストンだけを攻撃して壊すのが難しくて、もう少し軟らかくしておけばよかったと後悔。
F2 のオブジェクト(スプライト)にはグループ機能があって、「前のオブジェクトの下に続ける」、「前のオブジェクトの右に続ける」、「起点オブジェクトの Y 座標まで戻す」等を組み合わせて、複数枚のオブジェクトで構成される大きな絵を簡単に扱える様になっている。
普通は絵を 16×16 ピクセル単位で矩形に分割して重ならない様に敷き詰める方法でグループにする。
機械の面のボスがゼンマイのザコを口から出して手で摑むのを、摑んでいる感じを出す為に、手とザコが重なるグルーピング(奥の爪 → それに重ねてザコ → それに更に重ねて手前の爪)にしてみた。
F2 や、同じグルーピングが出来る仕様の F3 でも、私が担当した物でこういう構成をしたのは後にも先にもこれだけ。
地形を這う様に広がる炎は、見た目も構造ももっと綺麗に作りたかった。 パーツ毎に当たり判定を取ると割り当てられたスタックが足りなくなったので、実はパーツ単位で 1 つ飛びにしか当たり判定を取っていない。 だから、高い所から落下する等でうまく炎の中に入れれば、安全地帯が存在する。 まあ、縮むと配置が変わるから、安定した安全地帯じゃないけど。
ピラミッドの面のボスや雲の面で出てくる、発生して雷を落として消える雲。 仕様書上には存在せず、有り物の絵を組み合わせて私が創作した物。 大らかな時代だったな。
基板は、開発当初は F2 + 回転スクリーンのチップ(『ドンドコドン』と同じ仕様?)だった。
とは云っても拡大がしたいだけで、回転に用はなかった。
その後、F2 + 拡大スクリーンのチップ(『メタルブラック』等と同じ仕様)になった。
仕様は
という感じ。
スクリーンは拡大のみなのに対してオブジェクトは縮小のみなので、ゲーム中で拡大表示をするに当たっては、オブジェクトの表示物は等倍に加えて倍サイズの絵も持っていて、それを 1/2〜原寸表示する事で、ゲーム画面として原寸〜2 倍までの表示をしていた。
実はこのスクリーンチップにはバグがあって、横方向に 256 ピクセル毎に 1 ピクセル分の重複が発生する。
つまり 1 倍に設定しても、実際には 1 と 1/256 倍というちょっと拡大された表示になる。
また、それとは別に、開発中の基板で「スクリーンが横方向に画面半分ズレて、本来は画面外で行われているスクロールの書き換えが画面中央に見える」というハードウェアのバグがあって、それを担当ハード屋さんに伝えたら「ソフトが悪いんじゃないの?」と言われたのは忘れていない。
じゃあレジスタ設定で再現してみろってんだ。
ネームエントリーで「TBY」と入力すると、ハイスコア表示では「TA🐾」になる仕込みをした。
開発機材の UNIX での私のログイン名 tabby = ぶち猫から。
全面クリア後のクレジットでも、私の名前の横に猫の足跡が出る。
デモプレイ中、キックオフ後にパスボタンを 32 回押してちょっと待つと「くまたに」が現れる仕込みをした。
熊谷開発のゲームによく使われているのを、その前に携わった『ミズバク大冒険』で知ったので、勝手に仕込んじゃった。
マスクがオレンジ色の版だと 32 回なのは覚えているけど、マスクが青い版では回数を減らしたのは覚えているものの 10 回か 16 回のどちらか失念。
そのマスクが青い版がどういう物だったのか失念。
海外版だった様な記憶もあるんだけど、単純に海外版の『FOOTBALL CHAMP』ではなかった覚えもある。
当時のゲームは、使う絵をセル単位で区切って共通部分をまとめて(「コンバート」と呼んでいた)ROM に焼くんだけど、そのコンバート用ツールが幅 256 ピクセルを超える部分を警告なしにカットしちゃう不親切な仕様で、この版のタイトルロゴがそれを超えていると判明したのはキャラクタ用 ROM の量産を発注した後だった。
ハミ出た部分は当然ない。
マスクは 16 色使えてソフトウェア定義だったので、足りない部分をマスクで表示して問題を回避したのを覚えている。
デッドコピーの基板を見せて貰った事があるんだけど、それはハードウェアが安物の不完全で、スクリーンの拡大、オブジェクトの縮小とマスクのソフトウェア定義が出来ない代物だった。
だから、ゲーム中に拡大表示をする場面では表示が出鱈目になったし、「くまたに」はその場でマスクのパターン定義をして表示していたので、これも出鱈目な絵が出た。
そのデッドコピーの問題だかで、普段は顔を合わせない法務部の人が来て、プログラマ一人一人にいろいろな事を訊くんだけど、話が嚙み合わなかった記憶がある。
法:「この拡大表示を実現しているのはハードウェアですか、ソフトウェアですか?」
私:「拡大はハードウェアでしています」
法:「じゃあソフトウェアは関係ないんですね?」
私:「いえ、ソフトウェアで制御をします」
法:「じゃあハードウェアは関係ないんですか?」
みたいな感じで。 特許絡みでその辺を明確にする必要がある事を私が学習するのは、もう少し先。
バグ出しの為に社内で遊んで意見を出して貰った時、画面上部中央にあるレーダー表示の輝点の数が足りない気がすると言われて、デバッガでひとコマずつ確認した覚えがある。
動き回っていると人間の目で 11 個はなかなか数えられないというだけの話だった。
基板は F3 System。 仕様は大体 F2 + 拡大スクリーンのチップに似ている。
という感じ。
パレットは F2 までは RGB 各 4bit(4,096 色)だったけど、F3 からは RGB 各 8bit(16,777,216 色)になった。
スクリーンにはいくつかバグっぽい仕様があって、スクロールのレジスタを 0 にしても 4 枚でちょっとずつ位置がズレているのと、各スクリーンの設定レジスタの並びが 0, 1, 3, 2 だかになっていた記憶がある。
確かハード屋さんへ意見を出したんだけど「試作チップの時のソフトがそのまま動く様にと思って」という大きなお世話で製品版も同じ仕様だった。
ンな物は直すわ。
もしかして後のリビジョンでは直っていたりするのかな。
メインプログラマを任されたんだけど、システムを構築しながら他のプログラマに作業を割り振るのは上手くいかなかった。 他のプログラマを待たせる訳にはいかないから、未完成なシステムで作業をしてもらわざるを得なかった。 もっと独りで準備したかったな。
登場キャラクタは実写取り込みで、スタジオでモノクロのスチル写真を大量に撮って、それをスキャンしてドット絵師さんが手作業で着色していた。
だいぶ写真が暗くて、あまり実写っぽい感じにはならなかった。
この辺の色変換でもプログラムで解決すべく参加してみたかったけど、余裕がなかった。
新しい基板だったので、キャラクタを ROM に焼く為のキャラコンバータも新規に作った。
キャラコンバータの仕事は、絵のファイルを読み込んでオブジェクトやスクリーンのセル単位の矩形に分割し、既存のビットパターンと重複がないかどうかを照合してそれを排除して ROM イメージを作り、どの番号のキャラクタを組み合わせれば元の絵になるかという構成データを作る、という物。
F2 までのキャラコンバータは、退勤時に実行開始して翌日の出勤時に終わっているか、という位に実行時間の掛かるツールだった。
私が新規に作った物は大体 1 時間未満で完了した。
その後の開発にいい貢献をしたと自負している。
以降、いろいろな基板のフォーマットに対応していく。
クロサワ式乱数はこのプロジェクトで生み出した。
☞ クロサワ式乱数
応援だったのでハードウェア構成は判らない。
大型キャラが表示されていたので、スタイルオブジェクト(後述)だと思う。
2 体 1 組で動くボスを作った。
『クイズ世界は SHOW by ショーバイ!!』の番組中に登場する物。
これの改修を担当するまで、タイトー製である事と MSX で動いている事は知らなかった。
キャラコンバータに MSX 用の変換ルーチンを追加。
ずっと 680x0 に触ってきていたので、絶対アドレスなのに 16bit しかない事に違和感があったのを覚えている。
開発機材がカラー端末の HP 9000 Series 700 になった。
同時に 1GB の HDD が 5 台収まったタワーケースも導入されたんだけど、5GB という大容量に感動して、チーム内で「ごっぎっがっ!」と 1 音ずつ区切る様に発音する遊びが流行った。
オブジェクトはスタイルオブジェクトというシステム。
通常のオブジェクトは 16×16 ピクセルで、そのキャラ番号を指定すると表示されるけど、スタイルオブジェクトはキャラを 4×4 個並べた 64×64 ピクセルの大きさ。
4×4 個 16 キャラ分のキャラ番号はスタイル ROM に焼いて、そのインデックス番号で絵を指定する。
ドライブゲーム等の大型キャラを表示するゲームで使われていた。
キャラコンバータにスタイルオブジェクトのフォーマットを追加したのは、『スーパーチェイス』か『チェイスボンバーズ』のどちらかだと思う。
コースデータ作成用のツールと、それを視覚化する X11 のツールを作った。
コンバータを作った流れで、ROM 焼き機の制御ソフトを作った。 エスケープシーケンスでカラー表示をしたので、カラー端末を使い始めたこの頃だと思う。
元々は中研で作られた『ペップリス』という仮称のテスト段階のゲームだった。
縦画面の 1 人用で、「端子は全段同じ色」、「端子に繋がらないループでも消える」、「ブロックは I 型と L 型のみ(だったかな?)」という仕様だった。
それを見てちょっと惜しいと思い、私的に X68000 で「端子は段毎に違う色」、「端子 2 つ以上を繋がないと消えない」、「ブロックに T 型と十字型と行き止まりを追加」という仕様で作り直してみたのが、熊谷で作る発端になったのかな。
X68000 で爆弾のドット絵を描いた覚えがあるけど、中研版にあったかどうかは覚えていない。
AC 版では行き止まりブロックは出さなかったけど、理由を覚えていない。
中研版は B board という基板で、CPU は 68000、オブジェクトとスクリーンが共通キャラだった。
でも熊谷で作るに当ってはローコストを追求する事になり、L board という Z80 のカスタムチップの基板で、プログラマ 2 名、キャラ絵師 2 名という少人数のチーム編成だった。
Z80 でコードを書いたのは久し振り。
マスクのフォントデザインも手掛けた。
オペレータさんの評価はそんなに悪くなかったと聞いていたんだけど、結局はロケテストのみで製品にはならなかった。
この基板は 320×240 ピクセルまで表示が出来たんだけど、JAMMA 規格の仕様で表示可能走査線数(というかタイミング)が決まっていたので、黒いマスクを 2 行表示して 320×224 にしていた。 でも専用筐体だから JAMMA 規格から逸脱しても大丈夫だったんじゃないかと思うんだけど。
道はスクリーンをラスター単位で拡大する事で表示している。
X11 でコースデータを主観表示する数学的検証をして、ラスター処理でも起伏の表現がそれなりに出来るつもりで道表示システムを書いたんだけど、実機での視覚効果は今ひとつだった。
アイテムで敵の邪魔をしながらレースをする、『マリオカート』的なゲーム。
好きなゲームなんだけど、YouTube には綺麗な動画が上がっていないな。
完璧にエミュレート出来ないみたいだ。
応援でラスボスを作った。
仕事で書いた最後の 680x0 のコードで、かなり丁寧に書いた覚えがある。
記念にソースを手元に持っておけばよかったと後悔。
このプロジェクトの途中で、熊谷は中研に統合されて引っ越した。
基板は FX System。 ベースは初代 PlayStation。 家庭用と大きく違う仕様は
という感じ。 音源等は担当外なのでよく知らない。
開発機材は PC 互換機になった。
3DCG を先行してやっていた部署もあったけど、私がいた熊谷と大阪は経験がなかった。 そこで、秋葉原のデジタルハリウッド(タイトーが資本参加していた)で、SGI の WS を使って OpenGL での研修をした。 大崎にも先行して PS で開発している部署があって、そことの連絡係として数回行った覚えがある。 それらの部署は後に横浜の中央研究所へ引っ越す事に。
2D の時代は 680x0 のアセンブラだったけど、PS は C で開発をするという事で、部署内での C の講習会の講師をした。 全員にアセンブラの素養があるという恵まれた環境だったので、あまり教えるのに苦労した覚えはない。
680x0 時代には先輩の作ったノンプリエンプティブなマルチタスクモニタがあって、設計や作業を分担するのが楽だった。
原理はだいたい理解していたので、R3000 と C の環境になるのに合わせて、腕試しも兼ねて自前で作ってみる事にした。
GW の休みで実家へ帰った時に、当時持ち歩いていた HP200LX と Turbo C で基礎設計をしたのを覚えている。
当初は『サイキックフォース』の為に作ったんだけど、熊谷で同時進行だった『レイストーム』と『スーパーフットボールチャンプ』でも使われる事になり、以後いくつかのプロジェクトで使ってもらった。
名前は『TTS』。
当初は Tabby's Task Switcher の略、後に Tabby's Thread Slicer の略という事に。
背景のプログラムを担当していて、お気に入りはゲイツステージの雷雨の街。
雷光でビル群が逆行気味になるのは、なかなかに恰好良く作れたと自負している。
でも、あるビルの屋上の CLUT(テクスチャのパレット)が共通の物とは違う新たな物になっている(これはキャラ屋さんのミス)のに気付かなくて(これは私のミス)、一部分だけ逆光効果が現れないというバグがある。
AC 版でやらかして PS 版で直したのか、PS 版でやらかして直せなかったのか、までは失念。
ウォンステージの香港は、動きがないと寂しいので電飾をチカチカさせたけど、「香港は空港が街中にあるので、電飾を点滅させてはいけない」という豆知識を思い出したのは、作り終えてから。
PS 版のセーブデータの後ろの方の特定番地に「Tabby」と入っていると、メモリーカードのアイコンが通常の赤ではなく青い炎になる仕込みをした。
このセーブデータを使うと、他のチームメンバーが仕込んだある隠しコマンドの論理を反転して、そのコマンドを入力しなくてもオープニングムービー再生中にある効果が現れる。
私のログイン名 tabby から。
このデータは隠しコマンドでは作れず、自分用のデータは開発機材で作った。
今なら、メモリーカード編集ツールやエミュレータで再現が可能かな。
元熊谷。 TTS を使ってもらった。
元熊谷。 TTS を使ってもらった。
元熊谷以外のチームで初めて TTS を使ってもらった。
プログラムは ITL さんに外注。
キャラはタイトー側で作った。
ITL さんへ 1〜2 回お邪魔したんだけど、その時に『スペースインベーダー』を産んだ西角友宏さんと会ってお話をしたのが印象に残っている。
当初は違うシステムだったらしいけど、途中から TTS を使ってもらった。
キャラコンバート周りのお世話をした。
バグ出し作業をしている時に Yack. さんの謎フレーズ「男、バグ出し男」に大笑いした覚えがある。
基板は WOLF System。 LPX の IBM-PC に Voodoo のビデオカードを載せた物。 ROM-DOS をブートして、ゲーム本体は DOS エクステンダで動く。
テストモード(コイン数や難易度の設定)を日本語化するという試みをした。 小林洋行さんの赤城フォントを使わせて頂いた。
PS の TTS を IA-32 用に移植。
最初は「アセンブラが付いているから」という理由で買った私物の Watcom C で作って、それを更に Visual C に移植した。
『サイキックフォース2012』 の Dreamcast 版。
PS の TTS を SH4 用に移植。
DC 開発キット(Katana)が非常に繊細で、よく壊れたっけ。
業務で最後に書いたコードだったけど、ソフトもハードも買わなかった。 今思えば、記念に買っておけばよかった。