デモシーナー、Smashさん（Fairlight）にインタビュー
2013/10/18
「プログラマーと翻訳者は似てますよね。両者とも1つの言語を別の言語に翻訳してるわけだから、、」 数年前に、とあるエンジニアの方に言われた言葉です。プログラマー/コーダーという職業やその内容について興味を持つようになったのは、これがきっかけだった気がします。（キーボードを使うということぐらいしか、共通点はないと思っていた…笑） 翻訳者は1つの人間の言語や文化（など）を別の言語に翻訳して、プログラマーは人間の言語や概念（など）を、機械が理解できる言葉、“コード”に翻訳する、、？？ だけど、デモの作品のように、頭の中にあるイメージを画面に出したい時はどうするの…？深まる謎…。
さて、今回は、デモシーンで長く活動を続けていて、デモシーン内の「ベストコーダーの1人」としても知られる、FairlightのSmashさんにインタビューをお願いしました。ポップなデモからセンチメンタルなものまで、様々なタイプのデモを生み出しているSmashさんですが、実はミュージシャンとしてデモシーンに入ったことをご存知ですか？インタビューでは、そんなミュージシャンからコーダーに転向した経緯や、Smashさんの作業方法、“人気のデモ”を作るための秘密、そして、、これはチャーンス！とばかりに、プログラミング/コーディングの質問もぶつけてみました。（プログラミング知識ゼロがベストコーダーに聞く！というのがテーマの質問です…苦笑）
少々長いですが（1万字インタビューならぬ、1万6000字！どどーん！）、一読も二読も読む価値アリ。
秋の夜長に、じっくりとお楽しみください！
秋の夜長に、じっくりとお楽しみください！
——————————————————————–
まずは簡単に自己紹介をお願いできますか？
 |
| Photo by smash |
こんにちは、マット･スウォボダ（Matt Swoboda）です。デモシーンでは”Smash”として活動しています。今はFairlightというグループのコーダーをしています。
初めに“ルーツ”みたいなものからお聞きしたいのですが、初めてコンピューターに触れたのはいつ頃でしたか？
コンピューターを使い始めたのは結構遅かったです。僕が10歳の時に初めて家にコンピューターが来たんですが、それも父親が仕事で使うビジネス用で、何だかよく分からないものだったんですよ。学校ではBBC Microを使ったこともありましたけど、日常的に使っていたわけではないので。だから、きちんとしたPCに触れたのは12歳の時ですね。
ちなみに、どんなお子さんだったのでしょう？物を作るのが好きだったり、ゲームや恐竜が好きだったりとか、、
いつもレゴで遊んでるような、なかなかクリエイティブな子どもだったと思いますよ。でも絵を描いたり楽器を弾いたりするのは苦手でしたね。学校の成績は良かったんですが、たぶんちょっと怠け者だったかな、、（笑）
なるほど（笑） では、デモシーンとの出会いと、参加しようと思ったきっかけを教えてください。
デモやクラックトロの作品自体は、前にも何度か学校や友達のAmigaで見たことがあったんです。でも、それが何なのかは知らずに見ていました。自分自身でデモシーンを見つけるきっかけになったのは、1993～94年頃のコンピューター雑誌（「PC Format Magazine」）に付いてきたCDですね。そのCDに、「Second Reality」みたいなデモとか、トラッカーソフト、あとすごい量の.mod形式の音楽が入っていたんです。
最初に興味を持ったのはプログラミングでした。自分でゲームにしてみたいアイデアがあったので、学校のAcorn Archimedesや自宅のQBasicでBASICをいじっていたんですが、そのうちに “ゲームには音楽が必要だろう！”と思うようになって・・。それでトラッカーソフトを出してきて、自分で作曲するようになったんです。
MODの音楽は、本当によく聞いていましたね。曲だけじゃなくて、作曲者が書いたサンプルテキストもすべて読んでいました。いったい何が起きているんだろう？って、このシーンの盛り上がりに興味を持ったのもこれがスタートでした。1994年か95年には自宅からインターネットに接続できる環境になったので、それからしばらくしてIRCの#traxチャンネルとか、トラッキングシーンを見つけたんです。
ちなみに、“ゲームにしてみたいアイデア”っていうのは、実際にゲームにしたんでしょうか？
いえ、当時は音楽を作ることのほうが興味があったので、数年間はコーディングを全くしなかったんです。あれ以降、仕事としてゲームを作ったことは何度かありますけどね…。いつかまた、自分でゲームを作ってみようとする日が来るかもしれませんね（笑）
楽しそうですね（笑） さて、お話を伺っていると作曲に興味があったとのことですが、実際、90年代の作品ではミュージシャンとして名前がクレジットされていますよね。でも、、今は完全なるコーダーです。何がきっかけで転向したのでしょう？このあたりの経緯を教えていただけますか？
デモシーンとの最初の接触は、トラッキングシーンを通してだったんです。でも、わりと長い間デモ自体については何も知らない状態でしたね。僕はただトラッカーで作曲をしていて、作ったものをネット（Hornet Archive）で公開したり、#traxチャンネルの人たちとチャットしたり、曲をコンポに出したりということをしていました。 NOISEとか Theraliteっていう音楽グループに参加してたこともありますね。#traxは、アメリカ、カナダ、オーストラリアといったヨーロッパ以外のユーザーが多数派を占めていて、デモの分野にはあまり関与していない人たちが集まっていたんです。だから僕も最初は何も知らなかったんですが、徐々にデモシーンの存在に気付くようになってきて、それからデモを見るようになりました。
トラッカーの使い方に慣れてくると、コンポでも少しずつ結果を残せるようになってきたんです。それで、友達に頼んでデモパーティーのミュージックコンポ（コンテストの音楽部門）に出してもらったり、ディスクマガジン（デモシーン関連のオンラインマガジン）なんかに曲を提供するようになりました。あとは、いくつかデモのグループと組んでサントラを作ったりもしましたね。最初はそれだけで、特にそこから何かが始まることもなかったんですけど、そのうちに知り合いのミュージシャンを通してRazor 1911のPCデモの部門を復活させようとしていた人たちと出会って、グループに参加することになりました。デモとか64K用の音楽をいくつか担当しましたね。
デモシーンのミュージシャンとして、そこそこ成功していた時期もあったんですよ。Miasmahのコンピレーションとか、実際のCDとしてリリースされたものも何曲かありますし、Assembly（フィンランドのデモパーティー）みたいな規模の大きいデモパーティーのコンポの予選に通過したり、コンポで賞をとったり、わりと評判の良いミュージックディスクもいくつか作りましたしね。毎日何時間もFast Tracker 2で作曲する生活が3、4年ぐらいは続いたでしょうか。でも、飛び抜けて良くできたってわけではないんです。思うに、僕はミュージシャンのタイプではなかったんでしょうね、、。アイデアと努力である程度まではいったけど、ミュージシャンとしての生まれつきの才能があったわけではなかったんです。
大学に進んだ後は、状況がいろいろと変わってきました。1998年、僕が18歳の時です。まず、自分で実際のデモパーティーに出かけていける自由とお金を手にしたことが大きかったですね。最初はベルギーで開催されたWired 98にイギリスのシーナーたちと参加して、それからはいろんなデモパーティーに行くようになりました。それと、2000年にRazor 1911をやめてFairlightにグループを移ったので、新しいチームと作業するようになったという変化もありました。この頃になると、トラッカーを使った音楽のリリース数はゆっくりと下降線をたどっていて、みなMP3に移行し始めていたんです。僕自身は、Fast Tracker 2からプロの音楽ソフトへの移行は果たせなかったですね。他の人たちが作るようなクオリティまで達することができなかったので、興味が薄れていったんです。（それと、“大学生活を謳歌していた”という理由もあります（笑））
そのあとは、コーディングに熱中するようになりましたね。以前にもプログラムを組んだことはありましたけど、大学ではコンピューターサイエンスの専攻だったので、JavaとかCを勉強しないといけなかったんです。でも、しっくりきたんですよね。自分に合っているというか、自然に入ってきたんです。楽しんでやっていました。JavaやCの他には、卒業制作でネットワーク型の3Dスペースシューティングゲームを作ったので、OpenGLも学びましたね。それで、大学を卒業した2001年に最初のデモ（64K）を作ったんです。出来栄えもひどいですし、自分でも何をやっているのかほとんど分かってなかったんですが、いい勉強にはなりました。おかげで“デモコードのバグ取り”という貴重な体験ができただけでなく、グラフィックコーダーとしてゲーム業界にも就職できたんですから…。
就職してからは、仕事でグラフィックのコーディングをして家ではデモを作るという生活になったので、かなりの速さで上達していったと思います。スキルも経験もある人たちに囲まれていたおかげで、だんだんと自分のやってることが理解できるようになってきたんです。それで、もう音楽を作る時間はないなぁ…なんて思っていたら、いつの間にかコーダーになっていたんですよね！（笑） それでも、イントロとか自分の作品の音楽は時々作ってみたりしたんですけど、音楽とグラフィック/コードの両方をやるのは、あまりにも時間がかかりすぎると気付いてやめました。もっとスキルがあって、音楽制作に専念している人に任せたほうが、よっぽどいいですね。
たしかに、いろんなグループと組んで作業していますよね…
“numb res” by CNCD & Fairlight
そうだったんですか？ では、こういったコラボレーションはどのようにスタートするのですか？まずコンセプトやエフェクト、ムードなどのアイデアがあって始まるものなのでしょうか？
僕は、新しいエフェクトとか技術を年がら年じゅう考えているような人間で、“ビッグアイデア”が浮かぶと、何ヶ月もかけて開発するタイプなんです。大抵は、秋とか冬の静かな季節ですね。過去には、流体力学、パーティクル・システム、リアルタイムレイトレーシング、ボリューメトリックレンダリング、SDF（符号付き距離場）のメッシングなんかに取り組んできました。いつもRevision/Breakpoint（ドイツのデモパーティー）やAssemblyのような規模の大きいパーティーを目標にしてデモを作るんですが、作るぞ！と決めたら、まずは新しいエフェクトが“デモのベース”としてうまく機能する方法から考えるんです。エフェクトがしっかり出ているか？効果的な形で使われているか？とか。だから僕たちの作るものは技術重視のデモと言えるかもしれませんね。僕にとってのデモは、作品の中核を成している技術やエフェクト、コードを見せることなんです。技術的に優れたものがなければデモを作る意味はないと思うし、その効果を証明できないのなら、わざわざリアルタイムでやる必要はないと感じているんです。もちろん、デモの作品を作ろうと思う動機や理由はいろいろあるだろうし、“楽しいから作ってる”っていう人を否定するつもりはありませんよ。でも、僕個人にとっては常に、技術的な格好良さが、デモを作るときの重要なポイントですね。
技術重視のデモ、、、ということは、何はさておき技術的な部分を先に作るのでしょうか？音楽は後から入れるということですか？
まず最初にアイデアがあって、そのアイデアを後押しするような音楽をもらって、それからデモを作り始められれば理想的なんですけど、そんなことは滅多にありませんね、、。実際にこの順番で作れた場合は、“ベストデモ”と呼ばれるようなものにつながるんじゃないでしょうか。（「Agenda Circling Forth」（動画）、「Numb Res」（動画）、「Blunderbuss」（動画）はこの方法で作ったんですが、そういう結果になっているような気がします。） この順番で作るとデザインがより音楽に合ったものになりますし、（映像と音の）自然な流れができると思います。
“Blunderbuss” by Fairlight / Direct To Video
ただ、いつも一緒に作業する決まったミュージシャンがいるわけではないので、デモのサントラはいつも悩みのタネなんですよ（笑） 友達に頼むこともありますが、大体は誰かが送ってきたものとか、soundcloudやbandcampで聞いたものとか、何かしらのつながりがある人の曲を聞いて決めていますね。音楽はデモにとって決定的な要素なので、きちんとした作品にするには本当に重要なものなんです。
作業を始める段階で音楽が手元にない場合は、映像を作りながらサントラも作ることになります。この方法も音楽を編集（“1分長いぞ！どこか削れ！”とか）できるので良い方法ではあるんですが、かなり後にならないと音の全体像が把握できないという難点もあります。一番良いのは、音楽に導かれるようにしてデモを作るという方法だと思いますね。映像の雰囲気や方向性が、音楽とできる限り近づかないといけないんです。
タイトルはどのタイミングで決めるのですか？
早い段階で何か明確に見えているものがある場合は別として、タイトルはいつも最後に決めていますね。ただ、僕たちの作品のタイトルには、あまり的確とは言えないようなものもあるかも…（笑） ネットのアナグラム自動生成ツールを使ってタイトルを決めたことも何度かありますね…。
えっ？それはちょっと信じがたい気もしますけど、、（笑） では、もう少し具体的にデモの制作の流れを教えていただけますか？それと、どこから作品のインスピレーションを得ているのかも知りたいです。
デモを作る時は、僕たちの場合（といっても、僕か、僕とDestopなんですけど）、まず“デモを作るか作らないか”を決めます。毎回ほぼ必ず目標としている日が頭の中にあって、その日の1～2ヵ月前あたりに決めるんです。大体いつも、Revision/Breakpoint/The Gathering（ノルウェーのデモパーティー）といったイースターの時期のデモパーティーと、夏のAssemblyを目指して作り始めますね。でも、どちらか片方にしか出せないこともあれば、両方出せない年もあります…（笑）
まずは、最近興味を持っていることとか、取り組んでいることをチェックします。大概は技術とかエフェクトの話になるんですが、場合によってはモデリングの方法とかアニメーションの技法とか、作品の製作技術だったりすることもあります。それで、そこからデモとして成り立つものを模索するんです。あとは、自分の持っているアイデアとか、参考にした動画なんかを持ち込んで話し合いをしますね。アイデアはいつもデモシーン以外のところから見つけるようにしていて、ミュージックビデオとか、アート作品とか、vimeoやbehance.netなんかを参考にすることもあります。
あなたの作る作品は、デモシーナー（とそれ以外の人）の間ですごく人気がありますよね。何か“人気のデモを作る秘訣”のようなものがあるのでしょうか？もしくは、デモを作る時に特に気をつけていることなどありますか？
見ている人と感情的なつながりを築けるかどうかが、そのデモの良し悪しや印象、力量を判断する上での決定的な要素になると僕は考えていて、長く愛される作品となるかどうかも、そこにかかっていると思っています。でも、どうすればこのつながりを築くことができるのか…。それを知るのは、とても難しいですね。うまく達成できれば、デモは“パーツのより集め”以上の存在になるんです。僕たちの場合、「Numb Res」と「Agenda Circling Forth」で、そういうつながりを築けたんじゃないかと思っていますね。だからこそ、あれほどの人気を得ることができたんだと思います。
“Agenda Circling Forth” by Fairlight & CNCD
逆に、いろんな面で（前述の2つのデモより）はるかに優れたパーツを使って構成しても、そういうつながりを築けなかった作品もありますね。デモの場合、この感情的なつながりは、映像と音楽の結びつきの強さによって生まれることが多いようです。さっきの2つのデモは、まず音楽を見つけて、その解釈に沿って作るという方法を採った作品なんですが、人気が出た理由は、このあたりにあるんじゃないかと思いますね。ただの偶然ではないと思いますよ。
すごく興味深いですね。個人的に、あなたのデモは音楽を絶対にBGMとか脇役にしないなと感じています、、。
では音楽の話題ついでにお聞きしますが、もしも、著作権とかライセンスの問題がなかったら、デモに使ってみたい音楽というのはありますか？（つまり、バッハでもマドンナでも何でも使えるとしたら、、、）
これはその時に作っているデモによりますね。音楽が手元にない状態で作り始めるときは、毎回頭の中に自分の理想とするサントラが流れていますね。たとえば、いちばん最近の「Apocalypse When」だったら、Leftfieldの「Phat Planet」ですかね。
“Apocalypse When” by Fairlight
映像も音楽もすごくドラマチックなデモですね。最初に見た時、映画のオープニングかと思いました（笑）
デモには、盛り上がる部分と静かな部分を使って、波を作らないといけないんです。実際、デモの設計方法には、盛り上がる部分を3回入れるというシンプルで決まったパターンがあると聞いたことがありますね。まず、最初のゆったりしたイントロの後に1回、中頃で1回、そして終わり頃、少しクールダウンした後に1回というやり方です。うまくバランスを取ってペース配分を考えられれば、見ている人たちの期待感も高まり、デモの効果をフルに体感することができるんですよね。音楽は、この波に合ったものにしないといけないんです。
映像が盛り上がっている場面に音楽のクライマックスの部分が当たれば、相互作用ですごい効果が生まれます。でも、音楽は静かなのにデモの映像だけが盛り上がっていたり、映像は静かなのに音楽だけが高まっていくっていうのはダメですね。結びつきを完全に失ってしまいます。音楽にも波が必要で、映像と同じように、印象的で人を引き付けるものでなければいけないんです。だから僕はサントラやサウンドスケープよりも、実際の曲を使うのが好きですね。でもその場合は、色彩とかバリエーションとか、映像の制作にも十分な幅を与えてくれるような曲でないといけないんです。
僕にとって理想的なデモのサントラは、心に残る強い聞かせどころがあって、あとで思い出して歌ってしまうような曲ですね。それで曲のクライマックスの部分を思い出すと、その時の映像も一緒に浮かんでくるようならベストです（ここでのデモのサントラっていうのは、ルールのないコンセプトデモのことではなくて、“大作”ってことです（笑））。 だから、ボーカルのある曲を使うのが好きなんでしょうね。繰り返しになりますが、つながりが大切なんです。ボーカルが入ると、ほぼ間違いなく印象に残りますし、見ている時のガイドにもなるんです。心に残るようなものを作りたかったら、ボーカルがないとすごく難しいでしょうね。もしかしたら、ボーカルのある曲を使うことが記憶に残るデモへの近道と言えるかもしれませんね（笑）
僕はパンクとかロックの音楽が好きなので、そういうジャンルのサントラを使ってデモを作ってみたいです。ただ、それはすごく難しいかな…。いつかそういう音楽のミュージックビデオを担当できる日が来るかもしれませんね（笑）
65daysofstaticの音楽を使ってデモを作ってみたいとはずっと思っています。デモとすごく合う気がするんです。
もし、これをお読みになっている方で65daysofstaticの関係者の方がいましたらご連絡ください（笑）
（残念ながら私には理解できない部分ですが、デモを作ってる方のためにお願いします…） どんなプログラムを使ってデモを制作していますか？自作のデモツールを使ったりしていますか？
すべての作業の中心となるデモツールがあって、それを使っています。2000年代のあたま頃に開発して、そこから作り直したりしているものなんですが、現在のバージョンは2007年ぐらいからありますね。インターフェースも、その時からほとんど変わってないです。After EffectsやeyeOn Fusionにも似ていますが、すべてリアルタイムで動きます。それから、アーティストが1人でも、デモを制作できるようなしくみになっています。まぁ、実際にはそういうことはありませんけどね…。でも、作業をうまく分割できるという特徴を持ったツールではあるんです。つまり、コーダーは新しいエフェクトとコードを担当して、アーティストは全体を調整したり、カメラを作ったり、グラフィックの追加や色の修正、デザインの作業ができるようになっています。それと、これがかなり重要なんですが、コーダーとアーティストが一緒に作品に取り掛かれるようになっているんです。僕の場合、ハンドコーディングよりもデザインの作業がしやすいので、1人で作業する時もこのツールを使っていますね。
というか、実際は何にでもこのツールを使っていますね。2000年代半ば以降のデモはすべてこのツールで作りましたし、同じ頃からの64Kの作品もすべてそうです。他には、ディスクマガジンの「Zine」、インタラクティブ･インスタレーションやプロジェクションマッピングのプロジェクト、レンダリング用にエクスポートしたパーティクル･シミュレーション、ミュージックビデオの制作にも使いましたね。すごく柔軟性のあるツールなんです。 （*こちらのデモツールは後日「notch」という名称でリリースされたようです。）
デモはどこで作っていますか？必ず音楽を聞きながら作業するとか、お茶を飲むとか、“コーディングは真っ暗な部屋でやるに限る”とか、デモを作るときの“こだわり”みたいなものはありますか？
あまり自由になる時間がないので、ちょっと時間ができた時にデモを作っています。コードを書くのは、列車の中だったり、仕事の昼休み、夕方、夜、週末の家にいる時間ということもあれば、オフィスで遅い時間に作業したり、長時間フライトの飛行機の中とか、喫茶店で書くこともあります。必然的にラップトップで作業することが多くなってきていますね。フレームレートは最悪なんですが、どこでも作業できるという点はすごく良いです。
作業中は、いつも大体音楽を聞いています。それから、コーヒーとかダイエットコーラを飲んでいます。ビールを飲みながらデモを作るという楽しみは、数少ない“デモパーティー･コーディング”の機会にとっておいてあるので…（笑） それと、僕はわりとどこでも作業できるタイプだと思いますね。静かな場所や暗い場所でなくても大丈夫です。むしろそういう場所よりは、列車の中で作業するのが好きですね。インターネット（これがクセモノ）もないですし、時間が決まっているのもいいんです。1時間でこの作業をやろうと決めたら、あとはひたすらやるだけですからね。短時間の集中だったら簡単なんですが、僕の場合、長い時間になってくると結構キツくて…。飽きたり、集中が切れたりして、効率よくこなせていない気がしますね。でも、1時間だけだったら、すごく集中して能率的に作業できるんです。
トレイン･コーディングですか、、（笑） 話は変わりますが、あなたのデモの映像やエフェクトはすごく現実的なものが多いような気がします。抽象的なものにしない理由が何かあるのでしょうか？
“現実的なもの”は、人がそれを何であるか理解できるからこそ、力強いツールになるんです。たとえば、大きくて抽象的なかたまりを作ったとします。でも、これが実際にはどのくらいの大きさなのかは誰にも分からないわけです。巨大なかたまりかもしれないし、ごくごく小さなものかもしれない。これだけで理解するのは難しいんです。でも、隣にビルを置いてみたとします。こうすれば、そのビルを基準にして、誰にでもかたまりの大きさが分かるようになります。こうなると、もはやただの抽象的なかたまりではなくなって、“道を占拠するもの”になりますね…（笑） 現実や知覚を歪めて別の形にするというのは、僕がデモの中でよく使う手法ですね。シンプルなものだと、煙を文字の形にしてみたり、少し複雑なものだと、ビルをパーティクル（粒子）にして吹き飛ばすとか…。すごく興味をそそられる考えなんですよ。
それと、現実の要素は観客とのつながりを築く上ですごく効果的だと思いますね。見ている人がデモシーン以外の人の場合は特にそうです。（デモシーンの人たちは立方体とかグロー効果を見慣れているので、もうすでに現実の一部になっている人もいるんじゃないかと思いますが、、） 例を挙げると、完全にプログラムから生成した抽象的なものであっても、シェーディングは現実的なものにするようにしています。僕は、典型的なリアルタイムグラフィックスの見た目が、フラットだし不格好なので嫌いなんです。だから、できる限りそこから離れようと思っていますね。
こういうエフェクトはどうやって作るんですか？まず本物を見るか頭の中で想像して、それからプログラムで再現する方法を考えるのでしょうか？
新しいエフェクトを思い付くと、まずは参考資料をいろいろと当たってみるんです。実物も見ますが、やろうとしていることのオフラインレンダリングとか、動画もチェックしますね。このほうが役に立つ場合もあるんです。エフェクトでいつも目標としているのは、“これまでにリアルタイムでやってきたことの先へ進む”ということですね。それで、次のステップはオフラインレンダリングなんです。本質を保ちつつもっと簡単に表現するために、どんな妥協をして、どんな抜け道を使っているのかを見るのが好きですね。関連性があれば研究論文を読むこともありますが、まずはとにかくググる（笑） それから先は、作っては表現したいものと比較する、の繰り返しになります。
あなたはよく、デモシーンのベストコーダーの1人として名前が挙げられていますよね。日本のイベントでは、サインを求められていたと聞きました（笑） そこで、この絶好のチャンスを活かすべく、コーディングやプログラミングに関する質問をさせてください。（私自身はプログラミングの知識はゼロなので、バカバカしい質問だったらごめんなさい…。）
コーディングをする上で、いちばん難しいことは何ですか？
コーディングでいちばん難しいこと・・・。うーん、、、まずは締め切りとか時間のプレッシャーが挙げられるでしょうね。「ここまでやってみたい」と自分で思っていたことをすべてやる時間は絶対にないし、時間がない時に限ってバグの処理に何時間もとられたりしますから。でも僕がコーディングで一番難しいと思うのは、自分で作ろうとするものの芸術的な部分とか、数学的な部分であって、コード自体ではないですね。コードはコードでしかなくて、ある時点を超えると、自分が欲しいものを書く方法は分かるようになるんです。だから、コードを書くことではなくて、“何をするのか”、“どうやって実現させるのか”を考えるのが難しいところですね。
僕は、ものすごく数学が得意なわけではなくて…。まずまずだとは思うんですが、決して数学の天才ではないので、論文なんかに出てくる巨大な方程式を理解するのに苦労することが多いですね。実装されたものを見れば理解できるんですけど…。論文を詳しく理解しようとするよりも、ハイレベルな説明から自分のやり方を見つけるほうが簡単な気がしています。だから僕の場合、数学がコーディングで一番難しいことかもしれないですね（笑）
芸術面と数学ですか、、、
それと、インスピレーションを得たり、新しいアイデアを考え出すというのも難しい場合があるんですが、本当に難しいのは、“新しくて難しいけれど、決して不可能ではない”題材を見つけることだと思いますね。“新しくて素晴らしいけれど、動作が遅い”っていうものを作るのはすごく簡単なんです。でも、どんなに賢くて新しいことをやってるデモでも、1fpsで動くんだったら意味がない。だからといって、200fpsで楽に動くけど、全く新しいことにチャレンジしていないデモだったら、今度は簡単すぎますね。いつも意識しなければならない微妙なラインがあるんです。あとは、あまりにも高度すぎて、現在の最高水準のマシンに載せても重いという場合は、やり過ぎです。この場合、上手いトリックや、（その技術に）近いものを探さなければならないんですが、ものによってはエフェクトをダメにしてしまうこともあるんです。このバランスを取るのはすごく難しくて、賢明な選択が必要になります。僕も何年か前に考えていたエフェクトが、最近になってようやく実用レベルに達したという経験は何度かあります（笑）
行き詰まりを感じた時はどうしていますか？
コーディングの良いところは、やらなければいけないことが常に100個ぐらいあって、そのほとんどがインスピレーションを必要としないタスクなんです。こういうタスクは、時間と労力をかければこなせます。なので、エフェクトのコーディングに良いアイデアが浮かばない時は、ツールをいじったり、バグを修正したり、GUIを改善します。しばらく問題から離れてみると、戻った時には解決してたりするもんなんです（笑）
場合によっては、エフェクトの問題から数ヶ月間離れてみることもありますね。解決策が見つかるまで、他のことをやってみるんです。そうすると、そこで見つけた方法が放っておいた問題にも使えたりする…。コードの素晴らしさは、まさにこういうところにありますね。特にグラフィックスコーディングは、すべてがリンクしてるんです。コーディングを始めた初日に学んだことであっても、1年目に学んだことであっても、これまでに学んできたことはすべて重要なことであって、何年か経ったあとに必要になったりするんです。たとえば、15年前のソフトウェアレンダリングのテクニックは、現代のプログラマブルGPUで役に立ちます。積み重ねたものが、その人の知識になっていくんです。もちろん、必要な経験を積むには何年もかかるという別の見方もありますが、（コーディングは）比較的少ない知識でも、いろんなことができると思いますね。
では、コーディングをする上で、いちばん楽しいことは何ですか？
グラフィックスコーディングは、技やテクニック、アルゴリズムがつまった“巨大な道具箱”のようなものだと僕は考えているんです。新しい問題に直面したり、新しいエフェクトを作る時には、まずこの箱の中をのぞいて、手持ちの道具を組み合わせて対処します。新しいエフェクトと言っても、すべて新しいもので作るのではなく、自分がすでに持っている技やテクニックを新しい方法で組み合わせて作り出すことが多いんです。
時々、新しいテクニックが道具箱に加わると、すごくワクワクしますね。適切な道具がないことで今まで解けなかった多くの問題が、突然解決するんですから…。具体的な例で言うと、僕は今年、アニメーション化された複雑なポリゴンメッシュを処理できる、高速でリアルタイムのレイトレーサーを作ることができたんです（「5 Faces」で使っています）。これは大きかったですね。これまでレイトレーサーが必要だった問題が、一気に解決したんです。それに、数年前のアイデアを思い出したりして、“やっとこれもできるな…”なんて考えていますね。あと、DirectX11に移行した時も驚きでしたし、大きな転機になりました。自分の知る限りまだ誰もやっていないことだったり、見たことのないものだったり、本当に新しいものを考えついた時は最高の瞬間ですね。そこから、まったく新しい可能性が開けていくんです。
“5 faces” by Fairlight & Cloudkicker
あなたの考える、“良いコードの定義”とは何ですか？
これは、いろいろと議論の余地がありそうですね（笑） ただ、僕の考えでは、良いコードとはシンプルで読みやすく、効率的にタスクをこなすものであり、安定していて、強固なものだと思っています。派手なトリックやスマート過ぎるコードっていうのは、過大評価されてると思いますね（笑）
そうなんですか！逆だと思っていました（笑） では、良いコーダーになるために必要なことは何ですか？
良いコーダー、特に良いグラフィックスコーダーとかデモコーダーっていうのは、すごく頭の良い人である場合が多い気がします。（別に、自分もそうだって言ってるわけじゃないですよ（笑）） コーディングは“問題を解決すること”で、良いコーダーはそれが得意な人のことです。グラフィックスコーディングもデモコーディングも、制約がある環境で問題解決をすることが求められるんです。ここでの制約というのは、リアルタイムグラフィックスの限界という意味です。どんなに速いコンピュータを使っても、課題は常にあります。それに、チームが少人数だったりなどの時間やリソースの制約もありますし、パフォーマンスや技術的な制約もあります。でもこの制約だらけの環境の中で、魔法のように素晴らしいものを作ったり、非現実的なものを現実的に見せないといけない。（笑） このタスクをこなすには、既成概念にとらわれない考え方をする“水平思考”や、発想力、独創性、明確な考えが必要になりますし、問題を小分けにして対処できるよう、状況を分析する力も求められます。
それと、意外かもしれませんが、良いコーダーは他の人と作業できなければなりません。分野の異なる人たちと作業するなかで、自分の問題を分かってもらえるように説明したり、相手の問題を自分で理解することが求められるんです。さらに、良いデモコーダーであれば、こういう大変な作業を“無料で”やってもらえるようにしなければなりません。それと、プロジェクトをリードしたり、集まってくれた人たちを管理することも必要です。仕事ではないので作業を強制することはできませんし、自分が対価を支払うわけでもありません。他にも色々とやりたいことがあるなかで、一緒にやってみたいと思ってもらえなければ、作業は進まないんです。これには対人関係のスキルとか、リーダーシップとか、あとは魅力も必要になりますね（笑） なので、良いグラフィックスコーダー、良いデモコーダーになるには、賢くならないといけないのと、人付き合いも上手にならないといけません（笑）
さらにもう1つ加えれば、この分野で良いコーダーになるためには、他の分野の能力も重要です。良いデモ/グラフィックスコーダーというのは、“優れたアーティスト”でもあるんです。コーディングしかできなくて、コード以外のことは分からないっていうのは、実践的な面で良いコーダーとは呼べないですね。デモコーダーは、多才である必要があるんです。ゲームの開発チームとか、他の環境だったら別の人が担当することでも、デモでは自分でやらないといけないんです。64Kの作品を作った時は、特に多くのことを学びましたね。システムのこと、Windows自体のコーディング、ツールの設計とプログラミング、コンテンツのプロシージャル生成、アニメーション、コンパイラ、ライトマップの焼き込み、オーディオプログラミング、シンセ/VSTの作成、圧縮、UV生成、テクスチャリング、ディレクション、モデリング…。さまざまな分野で、多くのことを経験できたんです。
もはや学校のような感じですね（笑） では、デモの話題に戻って、定番の質問にいきましょうか。好きなデモ、心に残るデモ、影響を受けたデモ、、または人生を変えたデモ… あなたにとって特別なデモを教えてください。
何だろう…。初めてこれはスゴいと思ったデモで、自分でもやってみたいと思ったもので言うと、Psychic Link & Acmeの「Paper」（動画）で、スケッチが絵に変わるシーンですかね。あとは、Pulseの「Square」（動画）とか、Acmeの「303」（動画）も大好きですね。90年代のStatixのデモは、当時の僕にとって“デモの定義”みたいなものでしたね。高い芸術性と技術が組み合わさったものがデモなんだ、っていう。当時というか、今でもたぶんそうです。それから、Moppi Productionsの「Assembly 2004 invite」（動画）もすごく好きですね。小さめの作品だけど、完成されているんです。
ストリートの要素が入っていて、楽しいデモばかりですね。こういう遊び心は、あなたの作品でもよく見られる気がします（笑）
さて、あなたはかなり長い間デモシーンにいるわけですが、あなたにとってのデモ、デモシーンとは何でしょう？どうしてデモを作るのですか？
どうしてって言われても…（笑） どうしてなんでしょうね…。自分でも分からなくなる時があるんです。なぜこれほど多くの時間を、こんな意味のないものに費やしているんだろうって。作った作品を見るのは、要求が多くて、何をリリースしても絶対に満足しないコンピューターオタクたちですからね…。それに、なぜ一銭にもならないことにこんなに多くの技術スキルを使うんだろうとも思う時がありますね。でも、この質問への答えは、“デモを作るのが好きだから”になると思います。（ただし、デモをリリースするっていうのはまた別です。Pouetとかのコメントにはうんざりしていて、あれを見るとリリースする気がなくなるんですよね。）
デモを作っている時だけは、完全に自由になれるんです。利益のためじゃなく、自分たちのために、ただ楽しいからやっているだけですからね。制作の途中で、“空をもっと青く”とか、“ちょっと退屈だからロボットを足してみよう”とか言い出す人はいません。（でも、これは実際にゲームの開発中に外部のプロデューサーに言われた言葉です（笑）） 自分たちで100％コントロールできる、好きなことができる時間なんです。“遊びで何かスゴイことをする”とか、“何かスゴイものに参加する”という、同じ目的を持った才能のある人たちと一緒に作業できますしね。作品をリリースできなかったとしても、自分たちに腹を立てるだけで済みます。それに、たとえ完璧とは言えない作品をリリースして、気に入らないっていう人がいても、返金する必要はありませんから。（まぁ、金返せ！って言われそうな雰囲気はありますけど（笑）） リリースすれば終わりで、また次に取りかかれます。それに、もし良いものができれば、自分たちがやったことに誇りを感じられます。だから、“制作の自由さとそこから得られる経験”っていうのが、僕がデモを作る理由ですね。
デモシーンとの出会いで、人生が変わったと思いますか？
間違いないですね。2001年に初めて作った64Kのおかげで最初の就職先をゲーム産業で見つけることができましたし、その後の転職の時にも大きな強みになりました。デモシーンのおかげで、いろいろなチャンスに恵まれたんです。デモシーンに参加するということは（ここでの“参加”っていうのは、Pouetでデモを見てるだけじゃなくて、実際に活動するってことですよ（笑））、世界の秘密結社の一員になるようなものですね。お互いへの敬意があります。すごい人たちがたくさん関わっている場所なんですよ。デモシーンとの出会いから、良い友達が世界中にたくさんできましたし、いろんな場所に旅行したり、面白い人たちに出会ったり、ロックンロールな体験もできました（笑） だから、デモシーンは確実に僕の人生を変えたと言えるでしょうね。もしくは、人生の方向性を決める手助けになったとも言えます。正直なところ14歳からこのシーンにいるので、デモシーンに出会っていなかったらっていうのを想像するのは難しいです、、。
14歳！ ということは、人生の半分以上ってことですよね（笑） デモシーンの歴史を目撃した、、というか、もう歴史の一部ですね。
ただ、変化する世界の中で、デモシーンはどんどん取り残されているんです。古典的なプラットフォームを使ったり、あまのじゃくなサイズ制限を設定したり…。どこか古いスタイルや郷愁を感じさせる作品もデモシーンには多くて、、常に過去を振り返っているんですよね。そうこうしているうちに、デモシーン以外の人たちが僕たちの生み出した表現手段を使うようになってきた。“芸術目的でリアルタイムグラフィックスを使う”っていうのは、僕たちデモシーンの人間が生み出した表現方法なのに、今や彼らのほうが上手になりつつあって、僕らが目指すものよりも、もっと自由で楽しいことをやっているんです。ここから学ぶべきものがあると思いますね。デモシーンは前に進む必要があるんです。ただ問題は、シーンに関わる人の多くがそうは思っていないことにありますね。90年代のデモシーンに留まって、子供時代に体験したことを、そのままの形で残したいと思っている人が多いんです。つまり、デモシーン自体が成長と変化を妨げる最大の障害になっているんです。でも、何事もずっと同じままではいられませんから。
では、将来のデモシーンはどうなってほしいと思いますか？
デモシーンの未来はシーンに対する人々の努力や作品にかかっているので、今後どうなっていくのかは分からないです。これは、もうずいぶん長い間議論の対象になっていますね。個人的には、クリエイティブなコーダーとアーティストが最新のハードウェアを使って何かを作り、リアルタイムエフェクトの世界を前進させるようなものになればいいなと思っています。
なるほど。では、個人的なところではどうですか？今後作ってみたい作品などはありますか？
これまでよりも小さめのデモにして、もっとたくさん作ってみたいですね。だんだん10部構成で6分ぐらい続くデモを作る気力がなくなってきているのと、そういうデモは近頃の視聴者には不向きかなと思っているんです。デモシーナーたちは好きでしょうけど、シーン以外の人が見たら“どうしてランダムなんだ？一貫性もないし、理解できない”って思うでしょうね。それよりはアイデアを1つに絞って、2分ぐらいの何か格好いいものが作りたいですね。
楽しみですね！（笑） それでは最後にデモシーナー、デモファンの方にメッセージをお願いします。
作品を作ってください。デモシーンの存続を決めるのはあなたです。
——————————————————————–
かなり曖昧な質問が多かったにも関わらず、そのすべてに丁寧に回答してくださったSmashさん。辛抱強く対応していただき（笑）、ありがとうございました！
Smashさんの作品は、彼のブログ「direct to video」や、PouetのFairlightのページでもチェックできます。ブログでは、デモのより具体的で詳細な技術などが公開されていますよ。（あと、こちらのDisplayhackの記事でも、、） それから英語での動画になりますが、AssemblyTVではSmashさんがFairlightのデモの技術を説明した動画も公開されています。技術方面に詳しい方も、そうではない方も、是非チェックしてみてください。（たぶん技術が分かる方には、じゅるるな内容だと思われます）
最後までお読みいただき、ありがとうございました！
———————————————————————-
そもそも“デモ”ってなに？パソコンの話？と思った方は、まずはこちらのMoleman2のドキュメンタリーをチェック。（この映画の監督、シラードさんのインタビューはこちらでどうぞ。）
#1: 日本のデモシーナー、qさん（nonoil、gorakubuのコーダー）にインタビューは、こちら。
#2: デモシーナー、Gargajさん(Conspiracy、Ümlaüt Design)にインタビューは、こちら。
#3: デモシーナー、Preacherさん(Brainstorm、Traction)にインタビューは、こちら。
#4: デモシーナー、Zavieさん(Ctrl-Alt-Test)にインタビューは、こちら。
#5: デモシーナー、Smashさん（Fairlight）にインタビューは、こちら。
#6: デモシーナー、Gloomさん（Excess、Dead Roman）にインタビューは、こちら。
#7: 日本のデモシーナー、kiokuさん（System K）にインタビューは、こちら。
#8: デモシーナー、kbさん（Farbrausch）にインタビューは、こちら。
#9: デモシーナー、iqさん（RGBA）にインタビューは、こちら。
#10: デモシーナー、Navisさん（Andromeda Software Development）にインタビューは、こちら。
#11: デモシーナー、Pixturさん（Still, LKCC）にインタビューは、こちら。
#12: デモシーナー、Crypticさん（Approximate）にインタビューは、こちら。
#13: 日本のデモシーナー、0x4015（よっしんさん）にインタビューは、こちら。
#14: デモシーナー、Flopine（Cookie Collective）にインタビューは、こちら。
#15：デモシーナー、nobyさん（Epoch、Prismbeings）にインタビューはこちら。
私がデモシーンに興味を持った理由、インタビューを始めた理由は、こちらの記事にまとめてあります。また、デモやデモシーンに関連する投稿はこちらからどうぞ。
Interview with Demoscener – Pixtur (Still, LKCC)
デモシーナー、Navisさん（ASD）にインタビュー
