試験公開中

このエントリーをはてなブックマークに追加

はじめる! Squirrel

達人出版会

1,045円 (950円+税)

ゲームなどへの組み込みをターゲットとした、クラス・例外・ジェネレータなど多機能でありながらC++で7000行しかないスマートな軽量スクリプト言語、Squirrelによるスクリプティングを初歩から説明。

刊行記念:ykandaさんインタビュー 第2回

『はじめる! Squirrel』の刊行を記念して、著者であるykandaさんにお話をうかがいました。
(2010年12月17日、聞き手:高橋征義)

(「ykandaさんインタビュー第1回」からの続き)

「橋と橋の間にある島を意識して、 勉強していける本があったらいいなあと思います」

── この本を書こうと思ったきっかけについて教えてください。

ykanda 最初は会社で使うために、自分の時間を使って書いてました。 ネットに情報はあったんですけど、本当に教科書的に使えるような内容としてはいまいちなものばかりという印象がありまして。 組み込みにフォーカスしてやってるところとか、そういった情報が散漫にあるだけだったのですね。

さっきも言ったようにゲーム屋さんの場合、スクリプターさんがこういったものをメインで使うっていうケースが多いと思うんですね。 もちろんプログラマも使うときは使うんですけど。 で、スクリプターさんに打ってもらう時に、いきなり公式ページのリファレンスとか渡して、文法はこうなってるんだよとか言っても、ほぼ通じないと思ったんです。 なので、教科書的に使えるのが必要だなと思い至ったのがまず最初ですね。 この本自体というわけではなくて、仕事で使おうと思って、最初の元になるドキュメントを作ったきっかけはそんなところです。

まあ、そこにたまたまナイスな感じで原稿募集をしている方がいらっしゃったので(笑) 「物は試し」という感じでした。 これでまあ、広まってくれたら、こういったものがあるのを知らない人が知ってくれれば、知ってて探している人がいればその人のためになればいいな、という感じですね。 ゲームを生業としているプログラマって、僕の印象かもしれないんですけど、あんまりこういった文章と言いますか、物書きをしない人が多いなって言うような雰囲気があって、 そういったところにまず自分が突っ込んでみたいというのはありました。

世の中にあるプログラミングとかの本に関しても、圧倒的にゲーム以外が多い印象があります。 なぜかっていうとまず、ゲーム以外の方が、プラットフォームとかがオープンだっていうのがある。 なので、プラットフォームに関したことを記事として書きやすいというのがまず一つ背景としてあると思うんですよ。

ゲームプログラマも、アルゴリズムや細かいテクニックとかを駆使しているけど、基本的にその会社で閉じた世界のことが多かったと思います。 例えば、任天堂が提供するSDKを使って、みたいなことだったら本を出しても誰も手を出せない。 なんで、開発本を書こうと思っても書くわけにはいかないし、書いたとしても、読む人がそれを実践する環境を準備できない、といったようなことになってしまうんですね。 だから、DirectXの本っていっぱいあると思うんですけど、コンシューマハードという環境でゲームを作ろう、という本はほとんどない。 コンシューマハードの開発環境を使う上で守らなくてはいけない守秘義務みたいなものもありますし。

でもそうじゃなくて、こう、まだ書ける余地はあると思うんですよ。 例えば、もうちょっとぼかした書き方というと変ですけど、ゲームで使う物理とかAIの解説といった本はハードウェアや環境に依存しないので、結構出ています。 ああゆうのは、ハードウェアや環境に比較的依存しない、知識とか考え方の問題なので、オープンっていえばオープン。 そういった書けるものに関しては本は出てるんですけど、それにしても書く人はいないなあというような印象はあって。

やっぱり、特に国内に限って言うと、ゲームを作るっていうことがコンシューマハードのAPIを叩くということと本当に直結しちゃってるような、そういった印象があったりするんで、 逆に言えばそういうところじゃなければ、みんなもっと書いてもいいんじゃない、っていうような考えがあるわけですね。 なのでまず、自分が第一にやってみようというのが、また一つのきっかけというか、考えではあるんですね。

──海外は違うんでしょうか?

ykanda いや、海外もあんまり変わらないかもしれませんね、あまり自信はないですけど。 日本に入ってきてる本って、もともと海外製で、それを邦訳してみましたみたいなっていうのも結構多いんですが、 そう考えると「プロがプロ向けに本を書く」というケースは日本より多いかもしれません。

あんまりプロは使わないだろうみたいな技術の本とか、ホビー、アマチュア向けみたいな本はまあわりとありますが、 同人ゲームを作ろうみたいな切り口で書いてある本とかが結構多くて。 謎のキャラクターがかぶさっていたりとか。 そうじゃない国内製の本も、もちろんあるにはあるんですけど。

アマとプロとでは、使えるプラットフォーム、使うプラットフォームが若干違うというのもあるかも。 でもDirectXとかは、もちろんプロの開発者も使っていて、商業ベースのゲームとかをばんばん作ってるわけなんで、そういった意味で言えば、環境の違いはないとも言える。

ただまあ、知識とか考え方の問題や、その差とかはわりとあるとは思いますね。 そこを一足飛びに乗り越えられるような環境を使って、まあとりあえずゲーム作ってみよう、っていうような切り口が非常に多い。 なので、プロの開発者がそれを見ても、たぶんあんまり役には立たないじゃないかといった感じのものが多くなるっていう状況に繋がっている気はちょっとしますね。 ニーズがあるから存在しているわけなので、僕の口からこの状況を真っ向に否定するというわけではないですが。

例えば吉里吉里とかっていう環境があったりするんですけど、ああいったものを覚えたとしても、あんまり、PS3とか360とかやってる人たちにはおそらく役に立たんと。 ゲーム自体は作れると思うんですけど、PS3や360の商品として吉里吉里などで作れる類のゲームが出たとして、誰が喜ぶのか?みたいな話でもある。 目指しているもの、必要としているもの、が若干違いがあるかなという気はしますね。

もう一つ違う話をしてみましょう。 作業体制とかの話なのですが、アマっぽい人とかが集まると企画がどうとかゲーム性がどうとか、キャラクターデザインとかグラフィック云々の話を中心に ゲーム作りを進める事が多い印象がありますが、データをどうやって共有してこうか、とかそうゆう話はあまりでない。 何十人と集めて、いや二人とか三人でも変わらないと思うんですけど、一本のタイトルを協力しながら作るために、 バージョン管理をするであるとか、コンバートワークフローを構築するとか、そういった発想をまず持ってないという感じがしますね。

職業的に、多人数でそれなりの規模のものを作る場合だと意識せざるを得ないですよね、やってると。 バージョン管理システムを中心にしたコード共有を行わないとか、コンバートを一つ一つ手作業でやるとか、やってたりすると非常にめんどくさい。 なので、ゲームソフトウェアを開発しましょうって話だと、その辺りの話がもちろん出てくるのですが、その辺りを実践的に解説している本って聞いたことが無い。

本当にプロでない人向けにすると、まず第一にモノを作りましょうみたいな切り口で、なるべく易しい本になっちゃうというのは、 ある程度仕方のないというか、必然的な成り行きになるかなという気はしますね。

──それでも、この前のセガの方が書かれた「ゲームプログラマになる前に覚えておきたい技術」とか、最近出た「ゲームエンジンアーキテクチャ」とかもありますよね?


ykanda 「ゲームプログラマになる前に覚えておきたい技術」とかは良い本だと思いますが、実はあれですらまだ途中というか、 まさしく名前のとおりに「なる前」の話であるというか。

──橋渡し的な、橋の向こう側には届いていない?

ykanda わりと長い橋だとは思うんですけど、さっき言ったようなアマとプロで使う知識のギャップのみたいなのは、実はそれくらいあるんだよ、という感じがしますね。 決してイヤミではなくて。 「ゲームエンジンアーキテクチャ」の方に関して言えば、あれはもっとこう、ひどい現実を突きつける本、ということで(笑) 本の最後に「この本で触れていないこと」みたいなのが書いてあって、「ああ、まだ全部じゃないんだ」という。 ちょっと極論すぎるかもしれませんが、ああゆう本に書かれている内容を全部覚えたとして、実はまだゲームを作ることはできないんだよと(笑)

この橋は本質的に終わることはなくて、むしろ橋が今どんどん伸びている状況なんですよ。 絵も音も扱い易くなって、いろんなことが簡単にできるようになって、今はネットワークもあるからそれもちゃんと使えるようになった、 というような環境がそろって、ゲーム作りっていうのは簡単にできるようになったとは言われてるんですけど、 その一方でさっき言った、橋がものすごーく長くなっちゃって、先端にに辿り着くまでが、大変になっちゃってる状況なんですよね。

そんなのもう始めからやる気になかなかなれない、という気がしますね。 ただ、橋ってのはただの一本道じゃなくて、途中にいろんな島がある、あってもいいかな、と思うんですよ。 例えばSquirrelとかの組み込みのスクリプトっていうのを使って作る、っていう手法を覚える、そういうのも一つの島かなあと。 本当にやったことのない人だとそういったことがあるんだっていうことすら発想に出てこない感じがするんで。

例えば、バージョン管理であるとか、コンテンツワークフローとか、実装だけじゃなくて、開発環境とかもちゃんと考えてモノを作んないといけないっていう、 それも一つの島だと思うんですよ。 本当にいろんな島がある。

そして全体を一つの長い橋として考えるんじゃなくて、途中にいろんな島があって、そこを通りながら、いろんな道に行けたらいい。 島と島をつなぐ橋は、実は一本じゃないかもしれないし、逆に専門的な一本道の橋もあるかもしれません。 そういった、次の橋に行くための、今の話の文脈で言ったら教本ですよね、こっちに行けばこんな風なことが行われている、次の島はこんなのがありますよ、 みたいな本がもっともっと増えればいいかなあという気がしますよ。

めちゃめちゃ難しい本か、めちゃめちゃ簡単な本しかない感じがするんで、もうちょっとフォーカスを絞ってくれて、橋と橋の間にある島を意識して、 勉強していける本があったらいいなあと思います。 それも一つの本を書こうとしたきっかけっていうか、いま言ったような感じでゲームに対する知識を得られる環境が形造られるためにはどうしたらいいかっていうのを考えたい気はしますね。

「ゲームエンジンアーキテクチャ」にしろ、「ゲームプログラマになる前に覚えておきたい技術」にしろ、やたら分厚いじゃないですか(笑) あれはもう一つの話として切っても切れない、最小単位であるっていうんだったら、あの形になるのはしょうがないかなあって思うんですけど、もうちょっとこう、プロとして必要なしっかりした知識の本なんだけど、手頃なサイズでまとまった本がいっぱいあったらいいなあって思います。

──実際に書いてみていかがでしたか?

ykanda 正直な話、相当変化をたどりました。 いろいろ打ち合わせとかも重ねて、フォーカスみたいなのは大事だなあと感じました。 さっきの話を蒸し返しますけど、どの島に行けるのか、どの島にいる人が読むのか、みたいなところを意識しないと味付けに差が出る。 僕はもうほんとに単純にリファレンスがあればいいと思って書いてたんですけど、実際に打つ人のことを考えるといろいろ変わったなあという印象は受けますね。

「60fpsのループの中で回るコードだけを書きたいんです、みたいな人たちが結構多いような気がして」

──なにか宣伝したいことがあれば。

ykanda また次のやつは書きたいなと思ってるんで、とりあずここで言っておいて、自分で逃げられないようにしておこうかなあと(笑) Squirrelの組み込み方とかの方を解説したやつですね。

あとはWeb周りとか楽しそうだなあと思ってるんで、誰か教えてください(笑) 僕はゲームとかはもちろん好きで、今でも自分はゲームプログラマだと思っていて、いろんな技術があってそれを勉強しようとするとき、最終的にそれでゲームが作れるか?という問いかけみたいなものが常に頭の中にあります。 たとえば今Webって言いましたけど、それで何か一つゲームっぽいものが作れないかなと。

ゲームプログラマっていうとなぜかみんな、コンシューマハードで動いている、30fps、60fpsで動いているビデオゲームのプログラマっていうのを想像すると思うんですよね。 もうちょっとこう、別なハードであるとか、別なパラダイムであってもいいんじゃないかな。

例えば、ソーシャルゲーム、一応っていうと失礼ですが、ゲームって言っても良い気はします。 ゲームプログラマ、コンシューマとかでやってきた、さっき言った30fps、60fpsでゲームが回ってるっていうようなビデオゲームのプログラマからすると、 あれはまあ、ゲームじゃないんじゃない?っていう風に言うひとが、たまーにいるんですけど・・・

──たまにじゃないと思いますよ。割とふつうに。

ykanda そう言われると、逆に自分は結構面白ければ何でもいいタイプ、っていうと語弊があるかな。 うまく説明できていないけど。 ビデオゲームのプログラマも、もうちょっといろんなところに目を向けてもいいんじゃないかなって思うところがある。

別の例でいうと、FlashがGPUアクセラレータで50万ポリゴン書けますとか、そういったものが出てきていて、 ブラウザ上でもコンシューマハードに迫るものが作れるようになりそうだ、これは面白そうだと個人的に思うわけです。 一方、WebもFlashもぜんぜん興味なさそうな人とかが、僕の見てきたビデオゲームのプログラマには多い。

……もう自分の宣伝ではないですけど(笑)

──いえいえ、気にせず(笑)

ykanda 似てるようで似てない話かもしれませんが、ゲーム”プログラマ”である以上、ちゃんとみんなソフトウェアエンジニアであるっていう意識を持って欲しいとは思います。 ぼくはソフトウェアエンジニアかっていうと、そんな立派な肩書きをぶら下げることの出来る程の人間じゃないと思いますけど、 そんな僕から見ても、良くも悪くもゲームを作りたいだけ、っていう人がすごく多かったんですよね。 これはプログラマに限った話ではなく、むしろプランナーやディレクター、もっと言えば会社とかそんなレベルで。

──ソフトウェアエンジニアリング、あるいはコンピュータサイエンスかもしれないですけど、あまり興味がないとか?

ykanda 興味の無い人を否定するわけじゃないんですけど、そのような人が圧倒的に多かったという印象です。 知識としてもちろん知ってるという人や、ゲームに役立てようと思っていろんな研究をした結果そこに行き着いちゃったという人はいると思いますが。

ただ、ゲームが好きでいて、その開発に従事している割には、ソフトウェアを作るための知識に対する視野が狭いなあと感じる人は多い。 個人的なスタンスとして、いろんなテクノロジーとかカルチャーとかに対して貪欲でなければいけないと思っているのですが、「僕はゲームが好きでゲームだけ作っていたいんです」、 「60fpsのループの中で回るコードだけを書きたいんです」みたいな人たちが結構多いような気がして。

──そうなんですか。傍から見ると、ゲームプログラマの方が、例えばWebプログラマよりプログラミングとして高度なプログラミングをしたりすることも多いように見えるんですけど。

ykanda それはパフォーマンスとかに対する姿勢を外から見るとそうなるだけだと思うんですよ。 姿勢というか、ワンループをこの処理時間で済ませなくては行けないとか、ビット単位で考えるのは基本、みたいに比較的シビアな数字で常に考えてる雰囲気を外から見るとそうなるのかなと。 それは姿勢としては間違っていないですし、品質の良いゲームを作る上で無視できないのはもちろんです。

けど、そればかり重視されるっていう風潮はちょっと問題だと思うんですよね。 ゲーム作りってそれだけじゃないじゃん、というところでしょうか。

企画を考えること、それを仕様に落としこむこと、データで表現すること、ロジックで表現すること。 こんなのを全部ひっくるめて1個のプロダクトを作るっていうのが、ゲームソフトの開発をソフトウェアエンジニアリング的に解釈した構造だと思うんですよ。 なので、そこに参加するなら、ある程度プログラミングとか以外でも、ソフトウェア作りに関する知識を持ってないとダメだって考え方が、僕はあって。 専門家になれと言いませんが、けど、もうちょっとその辺のことを考えないと、君たちが今作りたいと思っているゲームはこの先まともに作れなくなるかもしれないよ、 といった、そんなようなことを僕は思ってるんですね。

ここでちょっとたまには自分の話をしようかと思うんですけど(笑) 分からないことはないんですよ、ゲームそのものの実装に集中したい、というような気持ちは。

それに対する僕のスタンスとしては、じゃあ君たちはそういうことだけやっておいてくれ、俺はその裏方を支えるから、みたいな感じです。 周りは結構そういうゲーム作りたい、ゲームループの中身をがりがり書きたいっていう、そういう人たちが結構多かったんで、 でもそれだけだとゲームは作れないんで、ならそっちの方は俺がやるよみたいな。 要は裏方的な仕事、でしょうか。

彼らがあまり考えたり、時間を使いたくないと思うような部分で、良いやり方を探して提案したり、サポートできる体制を作りたいなと。 そんなことを特に強く考えるようになりました。

もちろん自分でゲームのメインの部分を書く、みたいなことも好きです。 でもこの先、特に日本の国内のゲーム業界ですね、「ゲーム業界それでいいの?」みたいな事を考えると、 「ゲームというソフト」作りに対する姿勢というか風潮を僕は疑いたくなるときがたまにあって、僕はそこを何とかしていきたいなあと思っています。

「ゲーム業界に古くから伝わる伝説の技術で「タスクシステム」っていうのがありまして(笑)」

──最後に読者に、読んだ方、読もうという方に対してメッセージ的なことを。

ykanda 簡単な切り口で書いたつもりなんで、プログラミングの基礎的な概念そこそこにとどめたので、逆にそういった視点で分かりにくいところがあれば、ぜひフィードバックを送ってください。 この本に限らず、達人出版会さんのやり方として、フィードバックを受けてドキュメントがよくなるというのがあるので、そこにみなさんも参加してほしいなというのがありますね。 初めて書いたので、そんなに上手くできていないんじゃないかという不安があるわけですよ。 ちゃんと手応えを感じて、もっと良くできるんだったらそうしていきたい、という気がしますね。

これが一つ。

あと、もう一つが、みんなももっと書いてみましょうよと(笑) さっきも言いましたけど、フォーカスを絞ればもっといろいろ書けることはあると思うんですね。

たとえば、「タスクシステム」について語ってみるとか。 あ、ゲーム業界に古くから伝わる、伝説の謎の技術で「タスクシステム」っていうのがありまして(笑)

──聞いたことあります。コルーチンとかファイバーみたいなものですよね?

ykanda いやあ、ところがどっこい、みたいな(笑) そういう風に書く人もいれば、オブジェクトとupdate関数がセットになったものを連結したリストがあって、単にゲームループの中で順番にリストを辿ってupdate関数をコールするだけ、っていう簡単な実装でも「タスクシステム」と呼ぶケースもあると思います。

僕はその折衷案というか、基本的にオブジェクトと関数のセットというのは変わりませんが、update関数がいわゆるコルーチンみたくなってて、 タスクが何か処理をしてるんだけど、任意の状態でいったん止めて、他のタスクに処理を渡ったり、他のタスクの処理を待ったり、そんな感じで全体が回る、 というようなものを基本としてイメージしています。

これを真面目に実装しようとすると、いろいろ楽しくて、頭の中がハッピーになるんですよ。 タスク同士が参照しあっていているような場合、関連しあうタスク同士のupdateをどう管理するかとか。

実行するときの優先順位とか、そもそもどこまでタスクで管理するとか、あと破棄するときの作法であるとか、 実行するときにそれをどういう風に実行する、たとえばPS3みたいなCELLとか乗っかっていて複数同時に処理を並列に走らせるようなアーキテクチャを持ってるとして、 じゃあそれをつかってタスクをどういう風に動かしていくか?みたいな話がすごく枝分かれしていく。

「タスク」っていう単語を出すだけで結構誤解を招きそうですごく怖いんですよ。 なんて言うんでしょうか、「家庭の味」系のお話とでもいいますか、「あなたの家のタスクはどんなお味?」みたいな(笑) 雑煮とか味噌汁のように、ある人にとってはスタンダードでも、他の人からは変わった感じに見える場合がある、というものだと思ってるので。この説明の仕方にも語弊があるのかもしれませんけど。

でも、タスクって基本的にハードとかそんな話じゃないんで、ぜんぜん楽しく語れると思います。 もちろんアーキテクチャに依存した話もあるのですが。 正解がない分、誰かがこうだと言い切っちゃうと、反発する人もいれば賛成する人もいて、そこが結構難しいし、楽しいところでもあるんですけど。 そうゆう話を集めてみると、読み物としてきっと楽しいんじゃないかなあと。 こんな例がありました、みたいな感じでもいいかもしれないし。 これ俺書こうかな(笑)

すみません、また話がそれましたけど、みんな書けることはあると思うので、何かたまには自分の知識を見つめ直してみてはどうかなと。 決して本を出せっていう話ではないのですが。

僕は物事を勉強するときに、本仕立てで文書を書くっていうことをするんですね。 用語とかばーっと並べてみて、これはこういう要素なんだなと、その要素に関する説明とサンプルとかを書いていって、 本を書くつもりで自分の中で知識を固めていくみたいなことをするのですが、それがけっこう楽しいやり方だと思ってます。 本を書くのは楽しいですし、いいですよためになりますよ、ということを知ってほしいなと。 特にゲームループにしか興味ない、そこのゲームプログラマの方(笑)、たまにはこういうことをやってみてもいいんじゃないかなっていう気がします。

こんなところですかね。

──きれいに終わったところで、どうもありがとうございます。

Home 書籍一覧 はじめる! Squirrel ▲ ページトップへ戻る