ふくD（FukuD）

エンジンズでゲーム開発、主にディレクター。
元SNKでサムライスピリッツ、カービィ鏡の大迷宮などを経て、最新作SHADOW LABYRINTHをディレクション。
Game director at Engines. Former SNK: Samurai Spirits, Kirby & the Amazing Mirr

[ふくD（FukuD） @engines_D]

エンジンズというゲーム制作会社でディレクターをやっています。
サムライスピリッツシリーズ、星のカービィ（鏡の大迷宮/怪盗ドロッチェ団/集めてカービィ）、ブレイドスマッシュ等手掛けてまいりました。
ゲームに関係ある事ない事、情報発信等つぶやいていきます。

よろしくお願いします。

[ふくD（FukuD） @engines_D]

When SAMURAI SHODOWN II was released, I remember walking through the long underground passage from Tokyo Station to the Keiyo Line.
The walls were completely lined with huge visual ads of Haohmaru and Nakoruru illustrated by Shinkiro.

It was a moment I’ll never forget.

真SAMURAI SPIRITSがリリースされた年の東京駅から京葉線への長い通路の壁に森気楼さんの覇王丸とナコルルのビジュアル広告がズラーっと並んでいたのを見た時の感動は忘れません。

[Gamer_lafan @gamer_lafan]

If you grew up playing SNK games, you know exactly what I’m talking about.

Those incredible character illustrations? That was Shinkiro.

From 1990 to 2000, he defined the visual identity of Neo Geo — Fatal Fury, Art of Fighting, Samurai Shodown, The King of Fighters, Metal Slug… So many legendary titles brought to life through his art. His illustrations didn’t just promote the games — they gave them soul.

Later, he moved to Capcom and continued his legacy, working on GBA Capcom titles, CAPCOM VS SNK 1 & 2, and even contributing artwork to Street Fighter V and VI.

A true legend in fighting game history.

[ふくD（FukuD） @engines_D]

詳しいやり方はその会社さんに行ったことが無いので分かりませんが、開発途中で実機チェックは必須なので作っていたはずですよ。そもそも当時は開発ロム基盤が無いとゲームできないので。
在籍中に他社さんの開発中のゲーム見せてもらって”こんなの作ってるんだ”とワクワクしてましたしね。

I don’t know the exact process since I’ve never been to that company,
but hardware checks during development were essential, so they must have done them.
Back then, you couldn’t even run a game without a development ROM board.
While I was there, I sometimes got to see games other companies were working on,
and it was always exciting to think, “Wow, this is what they’re making.”

[M.D.スコット @kronosjapan1]

@engines_D サードパーティのネオジオ開発会社は独自のプロトタイプゲームEPROMを作成したのでしょうか？それともSNKがサービスを提供していたのでしょうか？『Mystic Wand』『空手忍者 翔』『Ninja Gaiden II』といったプロトタイプゲームはどうなったかご存知ですか？

[ふくD（FukuD） @engines_D]

これは初めて見ました。

[kuipon @kuipon]

@engines_D コロコロでファミコン記事やってた時に買った必需品。新作サンプルやバージョンアップ、アルミホイルに包まれたROMだけ届くことが多いので、こっちでROM引っこ抜いて差し替えてました。（抜いたのは送り返す）

[ふくD（FukuD） @engines_D]

ちょっと昔の開発話「ロムのデータリサイクル」

前回書ききれなかった、ロムの再利用工程について書いてみます。
これは私がいた制作環境での話なので、現場によって細かい違いはあるかもしれません。

①：ロム焼き（データ書き込み）
※概要は前回の投稿をご覧ください

②：不要になったロムのシールを剥がす
※紙製のシールなので、どうしても剥がし跡が残ります

③：お湯を張った洗面器にロムを浸けて洗う
※主な目的はシール跡をきれいに落とすこと。
　「精密機器をお湯に？」と最初は本当に驚きました

④：ロムに付いた水分を丁寧に拭き取る

⑤：データイレーサーでロムのデータを消去
※EPロムは中央のガラス窓から紫外線を当てることで消去します。
　紫外線が内部に閉じ込められた電荷（＝データ）を逃がすため、全ビットが初期状態に戻ります。

⑥：再び書き込み可能な状態になる
※消去済みのロムはケースに入れて保管

ざっと書くと、こんな流れでした。

初めて見たときは「本当にお湯で大丈夫なの？」と思いましたが、
丁寧に扱うならアルコールで拭くのが一般的なのかもしれません。

特に、中央のガラス部分は汚さないようにと先輩から教わりました。

今思えば、当時はいろいろと豪快でしたね。

A little story from the old days of development:
“Recycling EPROM Data”

In my previous post, I couldn’t go into detail about how we reused ROMs, so here’s the general workflow.
This was specific to my development environment, so other studios may have done things slightly differently.

1. Burning the ROM (writing data)
For details, please see the previous post.

2. Removing the label from unused EPROMs
The labels were paper stickers, so adhesive residue usually remained.

3. Washing the EPROMs in a basin of warm water
The main purpose was to remove the leftover adhesive.
Yes — putting precision electronics into warm water sounds questionable.
I was surprised the first time I saw it too.

4. Carefully drying the chips
All moisture had to be completely wiped off.

5. Erasing the data with a UV EPROM eraser
EPROMs are erased by exposing the quartz window in the center to ultraviolet light.
The UV light releases the electrical charge trapped inside the chip (which stores the data),
returning all bits to their default state.

6. The chip becomes writable again
The erased EPROMs were placed back into storage cases until needed.

That was the general process.

When I first experienced it, I really wondered whether warm water was safe.
If handled carefully, wiping with alcohol was probably the more proper method.
I was specifically told to keep the small quartz window clean.

Looking back, things were surprisingly bold in those days.

[ふくD（FukuD） @engines_D]

はい、ご質問ありがとうございます。
まず、私はゲームシステムのディレクターなので、UGSF関連��以下のURLのタゴッチ博士が専門になります。
https://t.co/7Kbig3loSL
なのでわかる範囲でお答えしますとSHADOWLABYRINTHはパックマンでメトロイドヴァニアを作ろうだったと思います。
その後UGSFの世界観を取り入れてキャラクターデザインやストーリーが作られました。
テー��―はゼビウスに浸食されたイメージとしてデザインモチーフにゼビウスの意匠が盛り込まれています。

Thank you for your question.
As I’m the game system director, UGSF-related topics are handled by Dr. Tagotch on the official site below:
https://t.co/7Kbig3loSL
So, speaking within what I know, Shadow Labyrinth began with the idea of creating a Metroidvania-style game based on Pac-Man.
Later, elements of the UGSF universe were incorporated, shaping the character design and story.
Tebe was designed with the concept of being influenced by Xevious,
and its design motif includes visual elements inspired by Xevious.

[ふくD（FukuD） @engines_D]

日焼けマシンですね、ほんとはロム洗いまで入れたかったのですが尺が長くなりすぎるので割愛しました。
次の機会があればお話ししたいと思います。

es, the “sunburn machine,” so to speak.
I actually wanted to include the part about ROM washing as well, but it would have made things too long, so I left it out.
If there’s another opportunity, I’d love to talk about it.

[転清 @kurofunepai]

とても鮮明な再現で当時を思い出します。
EP ROMを再利用する為の通称「日焼けマシン」も加えて頂けたら…

[ふくD（FukuD） @engines_D]

ちょっと昔の開発話「ロム焼き」

今回は、前回のようにデータ分解したものを、
実機で動かすところまで持っていく流れについての話です。
NEOGEO時代と SHADOW LABYRINTH では、まったく異なる形になっています。

それぞれの時代における、
プレイチェックまでの大まかな流れはこんな感じです。

■ SHADOW LABYRINTH の場合

① 各スタッフが作ったデータを、常にエンジン（Unity）上に集約
　※この時点で、エディター上で基本的なチェックプレイが可能

② その時点のデータをアプリとして出力し、exe化
　※アプリとしての動作確認が必要な場合や、
　　エディターを導入していないスタッフ向け

③ 出力された exe ファイルを、必要なスタッフが各自ダウンロードしてゲーム起動

■ NEOGEO時代

① グラフィック、プログラム、サウンドごとに、
　使っているPCと専用の機材を繋ぎ ロム焼き を行う
　※���ム焼きとは、EP-ROM にデータを記憶させる作業のことで、
　　当時は皆「ロム焼き」と呼んでいました

② 焼いたロムに、「どのデータが入っているか」を記したシールを貼る

③ 完成したロムを、複数コピーできる専用機械で必要数コピー

④ ロムを基板に挿し、その基板を筐体に取り付けてゲーム起動

昔はロム焼き機の数が少なく、
プロジェクトが立て込んでいる時などは、
ロム焼き機の取り合いが激しかったですね。

あちこちから
「アンドーくん貸してぇ！」
という声が飛び交っていました。

ちなみに アンドーくん とは、
ロム焼き機のメーカーが 安藤電機 という会社で、
機材にも「ANDO」と書かれていたことから、
自然とそう呼ばれるようになった名前です。

なお、複数コピーができる機械は、スーパーアンドーくん や
��ッグアンドーくん など、チームごとに呼び方が違っていたようです。

A little development story from the past: “ROM Burning.”

This time, I’m talking about the process of taking decomposed data, like in the previous post, and bringing it to the point where it actually runs on real hardware.
The workflow was completely different between the NEOGEO era and SHADOW LABYRINTH.

Here’s a rough overview of how things went up to the point of playtesting in each era.

■ In the case of SHADOW LABYRINTH

Each staff member’s data is constantly integrated into the engine (Unity).
At this stage, basic playtesting can already be done within the editor.

The current data is built into an application and exported as an .exe.
Used when testing the game as a standalone build, or for staff who don’t have the editor installed.

The exported .exe is downloaded by the necessary staff, and the game is launched.

■ In the NEOGEO era

Graphics, program, and sound data were each written to ROM by connecting the PC in use to dedicated hardware — this process was called “ROM burning.”
ROM burning meant writing data onto EP-ROM chips, and that’s what everyone called it back then.

A label indicating what data was stored was attached to each burned ROM.

The completed ROMs were duplicated in the required quantity using a dedicated copying machine.

The ROMs were inserted into the board, the board was mounted into the cabinet, and the game was launched.

Back then, there were very few ROM burners available, and when multiple projects overlapped,
there was intense competition to use the machines.

You’d often hear voices around the office shouting:
“Ando-kun, can I borrow you?!”

By the way, Ando-kun was the nickname for the ROM burner,
named after its manufacturer, Ando Electric, since the equipment had “ANDO” written on it.

The machines capable of making multiple copies were sometimes called things like
“Super Ando-kun” or “Big Ando-kun,” depending on the team.

[ふくD（FukuD） @engines_D]

ここは探索必須ルートでは無いですからね。
Dラインの垂直ジャンプはちょっとシビアでしたから、アップ���ートでやりやすくなったと思います。

[春雨 夏コミ土曜日東ツ57ｂしんぐん会 @wingeddeath]

溶鉱炉エリアは初回プレイではシャイアンG.A.I.A.エリアクリアしてから発見、探索した記憶があります。このDラインを登るアクションですが初回プレイでわからなくて悩みまくりましたｗ。

[ふくD（FukuD） @engines_D]

���回からずいぶん時間が経ってしまいました。
忘れていたわけでもやる気が無い訳でもないので、皆さんお付き合いください。
今回は壊れた溶鉱炉編です。
ここのボスは倒すとGAIAのスキルが得られますが、倒さなくてもクリアは可能です。
では、引き続きSHADOWLABYRINTHを宜しくお願いします。

It’s been quite a while since the last update.
It’s not that I forgot or lost motivation, so please stick with me.
This time, it’s the Broken Smelter edition.
Defeating the boss here grants you the GAIA skill, but it’s also possible to clear the area without it.

As always, thank you for your continued support of Shadow Labyrinth!

[ふくD（FukuD） @engines_D]

そうですね、侍スピリッツ以前（NAM1975 やリーグボウリング、クイズ大捜査線など）はそういったツールは全くなくて、すべて手作業でした。 作業中に間違いが（1つずつずれてた等）見つかって、修正しようとするも混乱して訳が分からなくなってしばらく窓の外を眺めて心を静めるとかやってましたよ。

Yes, that’s right.
Before Samurai Spirits—on titles like NAM-1975, League Bowling, and Quiz Daisousasen—there were no such tools at all. Everything was done completely by hand.
Sometimes we’d discover a mistake in the middle of the work—like everything being shifted by one tile.
We’d try to fix it, only to get completely confused, and then end up staring out the window for a while, trying to calm ourselves down.

[あっぷる @zubaapple]

そういえば
似通った複数の絵をマップチップに分解してチップ画像を生成、各絵ごとにマップ展開データに変換するツールとか作ったっけ
そこからマップチップは使用するカラーパレットが同じので集めてこちらも画像チップ毎に圧縮
マップ展開データも符号���して圧縮するまで自動化
あとはマップ展開データと、マップチップを渡せば絵が復元するみたいな仕組みやった
マップチップは複数の絵で共有するんだけど
マップチップの数に制��あるので
マップチップを減らす割合を指定して間引く処理も入れてた
間引くと多少絵がカクつくけどまあ以外に分からないもんやね

これ人の手でやるには究極パズルになる( * ॑꒳ ॑*)
、

[ふくD（FukuD） @engines_D]

この種の投稿をするようになってから、昔の仲間と記憶を掘り起こしながら会話する機会が増えました。
ちょうど先日この件も話で出てました。
その時の話では、ARTBOXに切り替わったタイミングは侍スピリッツ途中だったのではないか？という事に落ち着きました。
ARTBOXは２D開発の最後まで使っていたと思います。
777とARTBOXでなにが変わり、どういった効果があったのかはまた次の機会にお話ししたいと思います。

Since I started making posts like this, I’ve had more chances to reconnect with old teammates and dig back into our memories together.
Just the other day, this topic actually came up in one of those conversations.
From what we could recall, it seems that the switch to ARTBOX likely happened partway through the development of Samurai Spirits.
As far as we remember, ARTBOX continued to be used all the way to the end of SNK’s 2D development era.

I’d like to talk about what changed between 777 and ARTBOX, and what kind of impact that transition had, on another occasion.

[M.D.スコット @kronosjapan1]

@engines_D 詳しいご説明ありがとうございます。777を使用して開発された最後のネオジオゲームは何でしたか？ARTBOXを使用して開発された最初のネオジオゲームは何でしたか？これにより開発期間はどれくらい短縮されましたか？

[ふくD（FukuD） @engines_D]

ちょっと昔の開発話「データ分解」 今回は、描いたドットグラフィックを実装するまでの流れについての話です。 これまでと同様、あくまで SNKに在籍していた当時の話になります。 各社それぞれハードスペックや開発環境が異なると思いますので、 「SNK（NEOGEO）ではこうだったんだな」という感覚で読んでください。 NEOGEO開発においても、前述した777を使用していた時代から、 その後に登場した ARTBOX というSNKオリジナルの開発機材へと進化していきました。 なお、私は背景グラフィッカーとしてデザイナーをしていましたので、 ここでは背景グラフィックを例にして説明します。 NEOGEOの解像度は 320×256ドット （※当時はピクセルではなく「ドット」と呼んでいました）。 『侍スピリッツ』の場合、背景にスクロールや縮小表示があるため、 640×416ドット で描いていました。 FHDの1920×1080と比べると、かなり少ないですよね。 4Kや8Kと比べると、昔の画面は本当に豆粒のようです。 この背景をゲームに出すためには、まずデータに分解する必要がありました。 図のように、640×416ドットで描いた背景を 16×16ドットの四角 に分割して並べます。 この四角を当時は 「1キャラ」 と呼んでいました。 同じキャラ（コ��ペで作る複製をイメージしてください）は、 容量節約のため同じ番号を割り振ります。 この時、コピペした部分が解りにくくなるように工夫するのも大変でしたね。 777の時代では、この配置を 40×26マスの方眼紙 に手書きで、 「どこにどの番号のキャラが置かれているか」を描いていました。 ※ARTBOXの時代になると、これが自動化され、 紙に書く工程はなくなりました。 グラフィックを並べるデータは、 16×16＝256マス を1単位として 「BANK」 と呼びます。 このBANKが 00 / 01 / 02 … と複数集まり、 ひとつのゲームのグラフィックデータになります。 ※BANKの数が増えると、その分容量も増えていきます。 『侍スピリッツ』では、全グラフィックを 16個のBANK に収めていました （とはいえ、開発後半になるにつれて増えていくことになります）。 補足ですが、1キャラに指定できるパレットは1つだけ です。 これも初期の頃はパレット番号を紙に書いて管理していましたが、 後にグラフィックデータの中へ直接持たせられる���うになりました。 開発では、この 「1キャラをどう節約するか」 に心血を注いでいて、 1人のキャラも、1枚の背景も、 すべて決められた容量の中に収めなければなりませんでした。 なので 「1キャラ足りない〜、誰か譲って〜！」 といったデザイナー同士のやり取りも、よくありましたね。

A bit of old development talk: “Data Decomposition”

This time, I’ll talk about the process of taking hand-drawn pixel graphics and turning them into something that could actually be implemented in a game.
As with previous posts, this is purely based on my own experience back when I worked at SNK.
Hardware specs and development environments differed from company to company, so please read this as:
“Ah, this is how things were done at SNK (NEOGEO).”
Even within NEOGEO development, the workflow evolved over time—from the era when we used the previously mentioned 777, to the later introduction of ARTBOX, an SNK-original development system.
I worked as a background graphic designer, so I’ll explain this using background graphics as an example.
The NEOGEO’s resolution was 320×256 dots
(back then, we called them “dots,” not pixels).
In the case of Samurai Spirits, backgrounds supported scrolling and scaling, so we actually drew them at 640×416 dots.

Compared to Full HD (1920×1080), that’s a very small resolution.
When you think about 4K or 8K today, old game screens really were tiny—like grains of rice.

To get these backgrounds into the game, the first step was to break them down into data.
As shown in the diagram, a background drawn at 640×416 dots was divided into 16×16 dot squares and arranged accordingly.
At the time, we called each of these squares “one character” (1 char).

Identical characters (think of them as copy-and-pasted tiles) were assigned the same number to save memory.
Designing things so that these reused parts wouldn’t be too obvious was actually quite challenging.
During the 777 era, this layout was recorded by hand on 40×26 grid paper,
writing down exactly which character number was placed in each position.
Once we moved to the ARTBOX era, this process was automated, and the step of writing everything on paper disappeared.
Graphics data was organized in units of 16×16 = 256 characters, called a “BANK.”
Multiple BANKs—00, 01, 02, and so on—were combined to form the complete graphics data for a game.

Naturally, the more BANKs you used, the more memory was required.
In Samurai Spirits, all graphics were originally packed into 16 BANKs
(though this number increased as development progressed).
As a side note, each character could use only one palette.
Early on, palette numbers were also managed by writing them down on paper,
but later they could be embedded directly into the graphics data.

In development, we poured a lot of effort into figuring out how to save even a single character.
Every character and every background had to fit within strict memory limits.
So it wasn’t uncommon to hear designers saying things like:
“Hey, I’m one character short—can someone spare one?”

[ふくD（FukuD） @engines_D]

ですね。
あくまで私の内容は自分が開発していた環境の話なので、開発場所が変わればやり方も変わると思います。
うちではこんなんだったよーみたいな話があればどんどん発信してください。

That’s right.
What I’m sharing here is just based on the development environment I worked in,
so the workflow would naturally differ depending on where you were developing.
If you have stories like “this is how we did it at our place,”
please feel free to share them!

[ニューファンキー小林 @nf_ban]

@hogecats2 んー…各社で方針がかなり違うと思います。SNK(ネオジオ)ではふくDさんのポストが参考に。
https://t.co/u6tZO2SwRt
MSXの画像変換ツールはパレット昇順or降順のソートが多いですがMSXのスプライトにとってはORすると数値が増えるのでカラー1を汎用な黒方向にするのはある意味理想的かもしれません。

[ふくD（FukuD） @engines_D]

あ、確かに誤解招く図ですね。
今の開発スタッフにプログラマーが抜けてました。
訂正！

Ah, good catch—this diagram could cause a misunderstanding.
I forgot to include the programmer in the modern development side.
Correction!

[春日ハルミ@1y10m @kasugaharumi]

クラウドさん開発もできて優秀すぎる

[ふくD（FukuD） @engines_D]

ちょっと昔の開発話「開発の仕組み」

詳しい話というより、かなりざっくりとした内容です。
プランナー、デザイナー、サウンド、プログラマーなど、各スタッフが作ったデータを組み合わせてゲームは動いています。
今の開発では、オンライン上にすべての制作物を集約し、各プラットフォーム向けにアプリケーション化して出力します。
基本的には、各スタッフのPC内のデータと、クラウド上のデータをやり取��しながら進める形ですね。

一方、昔は基本の流れこそ同じですが、全スタッフの端末がオフラインという決定的な違いがありました。
フロッピーディスクのデータや、手書き・ワープロで作った「紙」の資料をプログラマーさんに渡し、手入力で処理してもらっていました。
そのため、出力されたゲームに間違いがあると、
元の資料なのか、入力ミスなのかを調べるのが本当に大変でした。
開発終盤は皆ピリピリしているので、トラブルから大喧嘩に発展することもありました。
（今となってはいい思い出……と思っているのは自分だけ？）

私が最新でディレクションした SHADOW LABYRINTH は、
スタッフ全員がフルリモートで作り上げましたが、昔では考えられなかったことですね。
テクノロジーの進歩は本当にすごいです。

A bit of old development talk: “How game development works”

This isn’t a detailed explanation, just a rough overview.
Games are made by combining data created by planners, designers, sound staff, programmers, and others.
In modern development, all production data is gathered online in one place, then built into an application tailored for each platform.
Basically, development progresses by exchanging data stored on each staff member’s PC and in the cloud.

In the past, the basic flow was similar, but there was one crucial difference:
every staff member’s machine was offline.
Data stored on floppy disks, as well as handwritten or word-processed paper documents, were handed directly to programmers, who manually entered everything.
As a result, when something was wrong in the final build, it was very hard to tell whether the mistake came from the original document or from a manual input error.

Toward the end of development, tensions ran high, so small mistakes could easily turn into serious conflicts.
I even had some big arguments myself.
(Now they’re fond memories… or at least, they are to me.)
The latest project I directed, SHADOW LABYRINTH, was developed entirely by a fully remote team working from long distances.
That would have been unthinkable back in the old days.

The progress of technology is truly amazing.

[ふくD（FukuD） @engines_D]

見かけて面白そうだったので自分もやってみました。ChatGPTに”これまで私があなたをどう扱ってきたのかを画像にしてください。”の結果。
I saw this going around and thought it looked fun, so I tried it myself.
This is what I got when I asked ChatGPT:
“Please turn how I’ve treated you up to now into an image.”

[ふくD（FukuD） @engines_D]

@lexelias はい、ありがとうです。
数件指摘があったのでリポストしています〜。

[ふくD（FukuD） @engines_D]

@fujitanozomu ご指摘ありがとうございます！

[ふくD（FukuD） @engines_D]

ちょっと昔の開発話「開発機材」

本題に入る前に少しお詫びです。
前回のパレットに関する投稿でいくつかご指摘をいただき、実際に当時キャラを描いていたデザイナーとも話をしました。
その中で、自分が勘違いしていた事や、すっかり忘れていた事を思い出せたので、整理してから訂正版を改めてアップします。
前回は、まさかここまで反響があるとは思っておらず、うろ覚えの情報を書いてしまい申し訳ありませんでした。
もう30年以上前の話なので、今後も記憶違いなどが出てくるかもしれません。その際は、ぜひやさしく指摘してもらえると助かります。
ということで、今回は開発機材の話です。
主にデザイナーが使っていた機材になります。

①：SONY SMC-777
マシンの細かいスペックは専門外なので省きます。
これはSNK以外でも、当時多くの開発会社で使われていました。（SNKが機種を変えた後も、中古で探している会社さんがありました）
このPCの良いところは、機材の右側に付いていたカーソルパッド（四角い板）ではないかと思います。
十字パッドと呼んでいた気もします。
このパッドでカーソルを動かし、ドットを打っていくので、開発部屋には常に
「カタタタ、タン！」
という音が鳴り響いていました。

PCにはデータ用の記憶装置が内蔵されておらず、3.5インチのフロッピーディスクを差し込んで保存していました。
②：14インチ アナログモニター
今ではほとんど見かけなくなった、ブラウン管のアナログモニターです。
モニターごとに色の出方が違うので、「標準モニター」を決め、目で確認しながら背面のツマミを回して色味を調整していました。

③：3.5インチ フロッピーディスク
容量は1.44MB。
1つのプロジェクトで使う枚数は、結構な数になります。
しかも、データはよく壊れるのでバックアップは必須。
たまに開発部屋から悲鳴が上がっていました。
自分も何度かやられましたね……1日分の仕事が消えるんです。
ディスクには判別用にラベルを書くのですが、各デザイナーさんが個性的な絵を描いていて、それを見るのも楽しかったです。

入社して��年後にハードディスクというものが登場しましたが、当時は
「1MB＝1万円」
という時代。
100MBのハードディスクは100万円。
「絶対に落とすな」と言われるレベルの超貴重品でした。
今のペンタブレットからは想像もつかない描き方ですが、
自分が入社する前は、方眼紙に描いたものをエンジニアが入力して絵を出力していたそうです。
そう考えると、当時の環境でも十分“魔法”みたいな存在でしたね。

A Development Story from a While Back: “Development Equipment”

Before getting into the main topic, a brief apology.

After my previous post about color palettes, I received several comments and had a chance to talk with the designer who actually drew the characters at the time.
That conversation helped me realize a few things I had misunderstood, as well as details I had completely forgotten. After reviewing and organizing my memories, I’m posting a corrected version.
That helped me realize a few things I had misunderstood and also reminded me of details I had completely forgotten, so I’d like to post a corrected version.
When I made the previous post, I honestly didn’t expect it to get this much attention, and I ended up writing some information based on vague memories. I’m sorry about that.
These events were more than 30 years ago, so there may be more mistakes or memory gaps in future posts as well. If that happens, I’d appreciate gentle corrections.

With that said, this time I’d like to talk about development equipment—specifically, the tools mainly used by designers.
1) SONY SMC-777

I’ll skip the detailed specifications, since I’m not a hardware expert.
This machine wasn’t used only at SNK—many development studios at the time used it as well. Even after SNK moved on to different systems, some companies were still hunting for used units.

One of its best features was the cursor pad—a square pad mounted on the right side of the machine. I think we called it a “D-pad” back then.
Designers moved the cursor with this pad and placed pixels one by one, so the development room was always filled with sounds like:

“katatata, tan!”
The PC itself had no internal storage. All data was saved using 3.5-inch floppy disks.

2) 14-inch analog monitor
These were CRT analog monitors—something you almost never see today.
Color reproduction differed from monitor to monitor, so we designated a “standard monitor” and adjusted the color by eye, turning the knobs on the back of the unit.

3) 3.5-inch floppy disks

Each disk held 1.44 MB.
For a single project, you’d end up using quite a lot of them.

On top of that, data corruption was common, so backups were absolutely essential.
Sometimes you’d hear screams coming from the development room. I experienced it myself a few times—losing an entire day’s worth of work was not unusual.

To identify each disk, we wrote labels on them, and many designers drew their own unique illustrations. Looking at those labels was surprisingly fun.
A few years after I joined the company, hard disks finally appeared.
At the time, storage cost about 10,000 yen per megabyte.
A 100 MB hard drive cost around 1 million yen, and we were told very clearly: “Never drop it.”
It was treated as an extremely valuable piece of equipment.

Compared to today’s pen tablets, the way we worked back then is almost unimaginable.
But before I joined, designers would draw on graph paper, and engineers would manually input the data to output the graphics.

Seen from that perspective, even our environment back then felt almost magical.

[ふくD（FukuD） @engines_D]

情報ありがとうございます、助かります。
調べてみたら確かにその通りでした。
フロッピーの2HDと2DDが、記憶の中で完全に混ざってました。
RS-232C周りの対応とか、当時はいろいろありましたよね。

Thank you for the information, that really helps.
I checked it myself and you’re absolutely right.
I had completely mixed up 2HD and 2DD floppy disks in my memory.
There were also all kinds of complications around RS-232C back then, weren’t there?

[Hiroyuki NAKAYAMA @bunniesfield]

@engines_D SMC-777は3.5インチフロッピーを利用可能でしたが容量は約280KB。
1986年にPC98用に3.5インチ1.25MBのドライブが発売され、ウチではこれが接続可能なSMC用FDDインターフェイスボードを自作してCP/M経由で利用していました。
3.5インチ1.44MBはさらに後のIBM PS2以降、日本ではほぼDOS/V以降でした。