白狼（はくろう）

【告知】 あの名作アクションシューティングゲーム メタルスラッグを存分にリスペクトした 「Aqua Ippan」のデモバージョンが遂に発表しました！ ゲーム内にて、BGMを提供させていただきました！ 何卒よろしくお願いします！ youtube.com/watch?v=aQ-iyC…

【DRAGON BREED】③ 世界観が見え始めた『竜のゲーム』の画面を見ると、「巨大な獣同士の血腥いぶつかり合い」、そんな画を想像してたんですが、グロ表現はありませんでした。 このゲームの企画を担当したのは、後に『METAL SLUG』の兵器名の由来にもなった『メルティ・ハニー』その人です。 しかも、あの可愛らしい『怪傑やんちゃ丸』の企画をした良識ある女性ですから、私が期待した表現に、共感してもらえるわけがありません。 また、『DRAGON BREED』のスタイルは、皆さんも御存知の時代のトレンドとでも言いましょうか、登場する怪獣たちは洗練された宇宙怪獣のようなデザインになってましたね。 席が隣だった後輩が担当した、主人公が乗るドラゴンのデザインは、どこかで見たことがある感じでしょ？ ドラゴンのデザインに悩んでいた後輩が、私の机の上にあった『強殖装甲ガイバー』のコミック本を参考にして、あのドラゴンを描いたんです。 私がガイバーフリークじゃなきゃ、あのデザインは生まれてこなかったんですよ。 ガイバーといえば、メタスラドッターズのMAX-D君もガイバーが好きで、彼が作った小さなガイバーのワンオフフィギュアを貰ったことがあるんですが、細部まで作り込んであって、手先の器用な子だなと感心した覚えがあります。 その彼のデビュー作がたしか『DRAGON BREED』で、その頃のクレジットネームは、ROKUJIZO、その後CannonになりMAX-Dになるという、改名が忙しい子です。 彼は入社当時、高校を卒業したばかりの真面目そうな可愛い少年に見えたんですが、入社初日からデザインルームでタバコをプカプカ吸ってたんです。 彼が未成年だと聞いていたので、皆は「舐められないように頑張って大人ぶってるんだよ…」と優しく影からエールを送っていました。 結局、彼はジッピーレース主任に呼び出され叱られるという、アイレム高校が生活指導してるみたいになって、学生の頃よく見た職員室のヤンキーを思い出して微笑ましかったです。 あとで本人に聞いてみると、実はタバコは苦手だったとのこと。 「あぁ、やっぱり無理して吸ってたんだね…」 と、大人の階段を登るROKUJIZO君を、カワイイ、カワイイと、ナデナデしてました。 ある日、彼が珍しく始業時間ギリギリに出社してきたので、 「なんかあった？」 と聞くと、電車内で、ずっと睨み合ってた男が、同じ駅で降りてきて、 「メンチ切ったやろ！」 と、言いがかりをつけてきたので、トイレで殴り合っていたとのこと。 そんな武闘派なROKUJIZO君は、『DRAGON BREED』では背景を担当していたと思います。 話が逸れましたが… こうして『DRAGON BREED』は、時代のトレンドに合わせて宇宙怪獣のような表現を取り入れることで、世界観に壮大さや神秘性を与えていたのかもしれませんね。 私のアナクロ怪獣のデザインは見事に却下されたわけですが、私の怪獣ゲームの夢はいつか別の形で叶えてみたいです。 血まみれの怪獣ゲーム！いつか作ってみたいですね。 そして石崎さんの「竜はカッコええ！」で始まったこのゲーム、アイレムとしては珍しく、最高にインパクトのあるゲームになりました。 おわり #DragonBreed #ゲーム開発秘話

【DRAGON BREED】② 竜をテーマにしたゲームを作りたい、企画の長である石崎さんは、私にこう言いました。 「竜がカッコええことを皆に伝えたいんや！」 「簡単でええからカッコええ竜の絵を描いてくれ！」 どうやらプレゼン用の『竜のゲーム』のラフを描いてほしいようです。 私は別のゲームを開発中で毎日深夜残業してるのに容赦がありません…。 ドラゴンではなく竜ということなので、私の頭に浮かんだのは、1966年に公開された東映の特撮映画『怪竜大決戦』です。 この映画に出てくる怪獣たちはチビっ子が喜ぶようなデザインじゃないんですが、そんな、ちょっと怖いデザインが新鮮に見えて目立つんじゃないかと思いました。 その映画に出てくる巨大ガマは、後に『仮面の忍者 赤影』に使い回されたんですよ。 小さい頃からこの映画が大好きで何度も見ています。 なので、このゲームに出てくる竜を始めとする怪獣たちの容姿は、『怪竜大決戦』に出てくる竜やガマのような、おどろおどろしく少しアナクロで、格好良いというよりは、怖い感じの怪獣が良いかなと思ったんです。 噛みつき、食いちぎり大量の血液が迸り、返り血が民家や城を真っ赤に染め、薄暗い画面で、竜が炎を吐けば画面がフワッと明るくなるような演出にワクワクしていました。 いざ竜を描いてみると難しくて、『怪竜大決戦』に出てくるような純和調の怪竜にはならず、ちょっと和洋折衷なモンスターといった感じです。 私が描いた竜の額には、ZZガンダムのハイ・メガ・キャノンのような砲門がありますね。 そして、竜には手足はいらないそうです。 『海底軍艦』に出てきた守護竜、マンダと同じスタイルでいくことになりました。 この動画は、当時、深夜残業してまで描かされた素材の一部です。 つづく #DragonBreed #ゲーム開発秘話

【モンスター絵師、可愛い仕事に救われる】 SNKを辞めてイラストレーターになった頃、気がつくとダークなモンスターを描いてくれという依頼しか来ませんでした。 たまに、この『キノコの兵隊』みたいな可愛い仕事が来ると、すごく嬉しかったんです。 こういう絵を描くのが好きなんでしょうね。 おどろおどろしいモンスターのウロコやトゲトゲを格好良く描くのは、めちゃくちゃしんどいんですが、シンプルなキャラは手数が少なく描けて、休みも増えて、しかもギャラは同じ。 正直「助かった…！」と思わずにいられない、ありがたい仕事だったんです。

【SNKでは需要がない私の絵を、Pixivに問う】 パチスロ開発は、私にとって暗黒の時代でした。 私の絵を若い社員達は「おもしろい」「可愛い」と評価してくれましたが、常務は、私を見つけるたびにこう言います。 「あの気味の悪い絵を描き直してくれ！」 「私の仕事は、常務に気に入られる絵を描くことじゃない」 そう説明しても聞き入れてもらえず、毎日「描き直せ」と詰め寄られて悩んでいたんです。 私が常務に毎日難癖をつけられているのは皆が知ってたんですが、相手が常務ですから、メタスラチームの仲間でさえ恐れをなして擁護してくれません。 「少しは庇ってくれよ…」 と、本来なら盾になるべき、私の絵を推すmeeher君に言うと、こう言ってくれたんです。 「今度、常務が描き直せなんてバカげたことを言ったら、ボクがビシッと言ってやりますよ！」 数時間後、私とmeeher君が喫煙スペースでタバコを吸っていると、常務がやって来ました。 性懲りもなく、また私に詰め寄り、こう言います。 「あんな気持ち悪い絵は、誰も見たくないんだよ！」 今だ！meeher君！ビシッと言ってやれ！と、彼に目をやると、火を付けたばかりのタバコを灰皿で揉み消し、ドアを開け、ゆっくりとフェードアウトしていくmeeher君。 やはり相手が常務ですし、誰よりも臆病な彼に、あんな啖呵が切れるわけがありません…。 そんな時、後輩たちの勧めで、世間に私の絵がどう見えるのかを問う気持ちで始めたのが、お絵描き投稿サイトPixivでした。 Pixivでも評価されなかったら、私の絵は本当に需要がないんだろうなと不安でしたが、幸運にも連続してランキング入りできたり、小さいサイズでしたが画集に載せてもらったりして、落ち込むことばかりだった日々の中で、救われた思い出があります。 この魔女っ子の絵は、Pixivに毎週一枚の絵を投稿するため、土日の2日で描いていたものです。 投稿するたびに頂ける優しいコメントに癒やされていたので、毎週それを続けるのは大変でしたが、とても楽しかったのを覚えています。 #pixiv #魔女

【速報】Native Instruments、iZotope、Plugin Alliance、Brainworxが正式な破産手続きへ移行。音響實存主義的に読み解く。 「大変だ千空！NIもiZotopeもPlugin Allianceも、正式な破産手続きに入るって発表があったぞ！俺たちの機材が全部使えなくなる！」 「落ち着け、クロム。声明を読んだか」 「読んでない！ヤベえじゃないか！」 「今すぐサーバーが落ちるわけじゃねえ。製品のダウンロード、オーソライズ、サポート、全部継続中だ。これはM&Aに向けた法的プロセスの予定通りの手順だ。オーディオに深いルーツを持つ複数の企業との交渉が順調に進んでいると声明に書いてある」 「……じゃあ今は大丈夫なのか、千空」 「短期的にはそうだ。だが今回の件はもっと本質的な問いを突きつけてる」 「どういうことだ」 「アナログの実機を考えろ。メーカーが消滅しても、コンセントから電圧をぶち込めば回路は動く。物理法則は契約に従わない。だがプラグインは違う。オーソライズサーバーというインフラが止まった瞬間に、どれだけ精巧な物理モデリングも、どれだけ正確に測定したTHDのデータも、全部ただのデータの塊になる」 「……バーチャル機材の唯一の弱点か」 「電気は裏切らないが、サーバーは止まる。アナログ機材は電圧に従い、プラグインは契約に従う。これが『バーチャル機材』という概念の本当のコストだ」 「じゃあ俺たちはどうすればいい」 「M&Aの成功を祈りながら、今ある機材で、目の前のトラックに正しい電圧を流し続けるだけだ。それしかねえ。唆るぜ、これは——という話でもないが」 声明全文： ni-japan.jp/news/update-fr… #唆るぜDTM #音響實存主義 #音樂廃人不法集會 #DTM #NativeInstruments #PluginAlliance

That one unreachable Slug Gunner in MS5 Mission 2 has always bothered me, so much so that I finally decided to do something about it myself.

【ドブケラドプスが出来るまで】 ドブケラドプスを、SFホラーの金字塔「エイリアン」のライフサイクルに重ねてみました。 ドブケラドプスはゼノモーフ、ゴマンダーはエッグチェンバー、インスルーはドブケラドプスの胚を媒介するフェイスハガー。 そこに加えて、ゴマンダーを成熟させるためのスイッチとなる種を打ち込む播種体バラカス、そして、その頂点に立つ存在として、ゴマンダーの卵胞を産み落とすクイーンドブケラドプスがいれば、ドブケラドプスの侵食サイクルが見えてきます。 でも決定的に違うのは、バイドは「生物的な繁殖」をやりつつ、最後に人類が作ったメカや、その複製、そしてあらゆる生命体を苗床にして形を決めている点です。 しかも、その融合は安定動作ではなく、侵食中に苗床の部位が崩れたり欠損したりして、その事故がもたらす後遺症が完成形になるんです。 インスルーによって持ち込まれた胚が、一つの器の中で融合する過程で、不慮の事故が起きた例が、ドブケラドプスの四肢欠損です。 メカが露出しているのは、その融合中に生じた断裂痕や崩落跡なんですね。 そして、生存の危機にさらされた瞬間、腹部を突き破って現れる、もう一つの顔は、偶然、胚を二つ抱え込んだまま融合が進んでしまった結果です。 インスルーが苗床として選んだ物体によって様々な姿になる。 つまり、ドブケラドプスには完成図がない……とか考えながら、当時はドット絵を描いていたんですよ。 ※私は普段ゲームをしないので、今のR・TYPEの公式設定は知らないんです。　　　　 違っている部分があってもご了承くださいね☺️ - English below - 【The Birth Cycle of Dobkeratops】 I tried mapping Dobkeratops onto the life cycle of Alien, the landmark of sci-fi horror. Dobkeratops is the Xenomorph, Gomander is the egg chamber, and Insrue is the Facehugger that carries and implants the Dobkeratops embryo. On top of that, there is the seeding form Barakus, which injects the seed that acts as the switch to mature Gomander, and above them all, there is Queen Dobkeratops, the being at the top that lays Gomander’s egg follicles. With all of them in place, the infestation cycle of Dobkeratops starts to come into view. But the decisive difference is that the Bydo carry out a kind of biological reproduction, while in the end determining their form by using human-made machines, their replicas, and all kinds of living creatures as host beds. And that fusion is not a stable process. During the infestation, parts of the host bed may collapse or be lost, and the aftereffects of those accidents become the final form. One example of an accident during the process in which the embryo brought in by Insrue fuses within a single vessel is Dobkeratops’s missing limbs. The exposed machinery is the result of ruptures and collapses that occurred during that fusion process. And the other face that bursts through the abdomen at the moment of mortal danger is the result of the fusion having progressed while, by chance, two embryos were still lodged inside. Its form changes depending on what kind of object Insrue chooses as the host bed. In other words, Dobkeratops has no fixed final design... That is the sort of thing I was thinking about while drawing the pixel art back then. Note: I do not usually play games, so I honestly do not know the current official R-TYPE lore. Please forgive me if some parts differ from it ☺️ #RTYPE #RTYPELore

縦読み ←ナムコの縦読み 　　　　アイレムの縦読み→ 詳細は画像の[ALT]・[代替]の文字をタップ。

Tried revamping the Soldier Select sequence in MS5. MS5 one is possibly the most impressive iteration in the series imo. And THAT must be what has gotten me carried away with revamping it more than I should have haha.

A slight update on the last video, with Ptolemaic soldiers now putting up more of a fight than just fleeing off the camera to never return.

Had some fun dissecting and tweaking the PM repair station event entity in MS5. Surprisingly, actors at the station are actually coded to interact with each other; Commander won't yell at the Elites unless their slack-off let his stress gauge value accumulate up to 90 in total.

Slug Mobile: "Finally, you came! Time to drive... wait, why are you FLYING?! Come bac-"

ちょっと昔の開発話「ロム焼き」 今回は、前回のようにデータ分解したものを、 実機で動かすところまで持っていく流れについての話です。 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.

ちょっと昔の開発話「データ分解」 今回は、描いたドットグラフィックを実装するまでの流れについての話です。 これまでと同様、あくまで 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?”

独Native Instruments社に関する報道について minet.jp/contents/info/…

ざっくりまとめると↓ ・Native Instruments（iZotope / Plugin Alliance / Brainworxの親会社）が予備的な破産手続きに入ったことが判明 ・負債の主因は拡大路線と高額買収で、製品や開発チームの失敗ではない ・事業は短期的に停止しない ・今後、Soundwide体制（NI / iZotope等）が分割・売却される可能性 ・パートナー企業やユーザーエコシステム (Kontakt / Reaktor / Maschine / Komplete)への影響は不透明 ・NIの技術・人材・製品価値は非常に高く、事業そのものが消滅する可能性は低いとの専門家見解あり 即座に使えなくなる話ではないが、今後の動向は注視すべき段階。

izotopeやPAを統合管理していたのにこれは寝耳に水なんてもんじゃないなぁ 突然、戦隊ものの合体ロボが爆破したような感じ

Native Instruments GmbH is in preliminary insolvency. cdm.link/ni-insolvency/

When the waving bridge is having a bad mood today:

自動生成ではなくてアーティキュレーションやダイナミクス関係なら最高だなぁ>RT