englishjapanesefrench
http://akihiko.shirai.as

[Shortcuts]

メインメニュー

blog[RDF]

検索

Recent Documents

新着ダウンロード

ログイン

ユーザ名:

パスワード:


パスワード紛失

新規登録

オンライン状況

2 人のユーザが現在オンラインです。 (1 人のユーザが documents (wiki) を参照しています。)

登録ユーザ: 0
ゲスト: 2

もっと...

アクセスカウンタ

今日 :2929
昨日 :103103103
今週 :433433433
今月 :3520435204352043520435204
総計 :1947065194706519470651947065194706519470651947065
平均 :457457457
taquino.net


Top / 遊びを科学する

Documents > Essay? > 遊びを科学する

ゲーム学問のススメ「遊びを科学する」



はじめに

大それたタイトルなんだけど、博士論文を書いていてこのテーマ「遊びの科学」で100ページ弱書いてしまったので、論文には書かなかった新しい知見を加えると共に、徐々にまとめていこうと思う。 ネットにおいてありますが、著作権は破棄していません。私の著述を出版したい!という人は遠慮なく連絡ください。引用する場合は、事前に連絡ください。コメントなども遠慮なくください(あんまり腹立つことを書いてほしいとは思わないけど)。

科学的遊び、科学者の遊び

最近気になること

最近エンタテイメントコンピューティングとか言う名前で沢山の学会、研究会、国際会議が開催されている。特に日本は盛ん。たいてい、ゲーム業界が絡んでいるようでいて、実際にはそれほどコアなコラボレーションをしているわけではない(フランスで企業と大学、といったらもっと親密な付き合いをする)。そう、いわゆる「遊びの科学」のようでいて、「学者の遊び」になっているような気がする。気のせいだろうか? ほんの数年しかゲーム業界にかかわってこなかった私がこんな風に感じるんだから、実際のゲームプロダクトにかかわっている真面目なエンジニアはもっとイライラしているに違いない。 そんな人たちが「あースッキリした」と思って、楽しいゲームを開発する助けになるような書き物になればいいなと思って筆を執っている。

科学と工学

「科学と工学どっちが上?」なんて質問は愚問だろう。でも、多くの工学部の学生が「科学の方が上なんじゃないかなあ…?」なんて答えてしまうかもしれない。どういうわけか両者には大きな先入観と歴史的軋轢がある。たとえばwikipediaなどいい例で、科学と工学の違いについては、とても中立とはいえないような記述が沢山見られる。wikipediaは中立とユーザによる編集を許しているシステムなのに、なぜそんなことが起きるのか。理由は簡単だ。科学と工学は回転する時間尺度が違う。科学シンパには「時間がある」のである。執筆者の数が違いすぎる。工学者側はあまりに忙しくて、「パブリックドメインのための執筆」なんて自分の約にもたたないことのために時間を費やすなんて時間を持ち合わせていないのだ。

遊びのための実装技術

そんな中で「実装技術」というのは、最も軽視される工学のようにおもう。ゲーム会社に居たときのストレスのほとんどがこれだったかもしれない。英国人は実装技術に美学を求める。日本人はわりと、それに関してあっさりしている人とこだわる人が真っ二つだ。ゲーム開発においては、どっちにしろ、マスタを焼いてしまえばそれまでなので、ディレクタ・プロデューサは「どっちでもいいから安定して動いてくれればいい」「速くてかっこよければいい」とかそんな感じだ。フロントエンドのエンジニアは、自分のペースで仕事できる人は、こだわり派が多いように思う。むしろハックやチートみたいな手段に陶酔するタイプは私のであった中では少数派だ。

逆アセンブルするまでもなく…

焼いては棄て、焼いては棄て…の技術に付き合うのは疲れる。多くのゲームエンジニアが、心血注いで作り上げた技術は、たいてい、マスタアップすると「見たくもないコード」になっている。時にはGPLなコードをふんづかまえてきたものであったり、出所の知れないコードであったり、某英語訳本の丸まるコピーにちょっと安定化させるためのHackを突っ込んだものであったり…要は「見たくもない」と同時に「見せられない」「見せるために書いてない」コードなのである。プラットフォームメーカーのエンジニアが書いたミドルウェアやSDKのようにドキュメントが日英で書かれているようなものはまだいい。そこそこ動くサンプルもあるし、多くのゲームデベロッパーに(暇なときに)触ってもらえるチャンスがある。大手ゲームメーカーのシステム系エンジニアも同様のチャンスがある。しかし、純粋なゲームアプリ開発者の書くコードが再利用される例というのは、一部の流出事件や、サブコンのコード付納品といった事例を除いてというのは非常にまれなことだと思う。

抱え込まない、自慢する

学問を否定する地盤

ゲーム開発を取り巻く環境はここ10年以内でずいぶんと変わったと思う。それに、市場を支える今後の動向もなんとなく不安だ。そう、惰性で物を作って収入を得られた時代はもうとっくに終わってるはずなんだ。ここから先を作り出す責任も、楽しみも、すべてゲーム開発者の手にある。 日本のゲーム開発者は一時期の大量消費、大量生産の時代に大きく狂ってしまった。キャラクターマーチャンダイジングとのカップリングによる、超駄作でも収入が得られる仕組みによって「間に合う時期に、それらしいものを作る」というスタイルが大前提になってしまった。この時期にゲーム開発の世界に足を踏み込んだエンジニアというのは、専門学校卒の方々が多い。夢とパッションで前に進むことができたし、大学卒が遊んでいる間にバブルも崩壊して就職難にあえいでいる一方、SFCやPS1で大稼ぎできる小気味よい時期が何年も続いたのである。大学に行くとか、学問を究めるとかいったことに何の興味もない、むしろ否定。今じゃ立派な社長であっても、「何の話をしてるんですか?」というぐらい、だ。

ゲームの面白さはどこから生まれるか

こういった現場育ちの成功体験が強い社長さんやプロデューサさんの多くに「面白さの仕組み」みたいな話をすると、たいてい機嫌が悪くなる。そして『面白さの方程式みたいなもんは、全部私の頭にある』とおっしゃる。しかも『それを具現化するためにこの仕事をしている!』と力説する。まあもっともだし、否定する気もないんですが、もし公開済み株式会社であったとしたら、株主の皆さんにそのリスクを教えてあげたいところである。

外部発表をさせない地盤

多くの有名プロデューサにこの手の話を聞くと、たいてい「いやー、エンジニアを外部発表させると調子に乗るから」とか「引き抜かれるから」という話をする。そのためにファミ通や、GDCや、カンファレンスなどで自分がしゃべるのだという。もしくはTDと呼ばれる技術分かってないけど、技術ディレクターという職名を冠する茶髪系技術者が自慢話をしているのである。 その意義については理解できないこともない。確かに苦労して引き抜いた技術者を他に行かせない、迷わず今の仕事を全うしてほしい、という気持ちもわかる。が、技術は人につくのだ。そしてそのエンジニアは人間なのだ。さらに言うと、最近のエンジニアはもうちょっとかしこいし、学問も少しは理解しないと生きていけない世界なのだ。もうちょっとガスの抜き方について考えてあげるのが人の上に立つ人間ではないのか。

花火師の技術

話が遠回りになってしまったが、結局のところ20世紀末の日本のゲームの成功なんて、そういうものなのである。江戸末期の百花繚乱とあまり変わらないようにも見えてくる。外国から見れば、ジャポニズムとして学ぶことは多いだろう。しかも、手法として、論理的にとらえて、咀嚼して、自分たちの画風として生かすのである。後の世で「このゲーム作家は日本のゲームに影響を受けた」といったように評価されたとしても、当の日本のゲームは生き残っているかどうか不明である。 「それが日本の運命」と言ってもいいのかもしれない。誰もとめられないようにも思う。たとえて言えば「花火師の技術」なのである。常に爆死と隣り合わせで、一瞬の消費芸術のために、命を削れるエンジニアが、日本には居るのである。そこに美学を求めてしまう環境やそこで一山稼いでしまう、山師が存在することも見過ごせないのだが。

まとめ

今日のところの筆をとめるために、まとめておく。 私のように半外人になってしまった研究者や、ゲーム業界に居たときから半分学者みたいなことをやっていた立場からすると、ゲーム実装技術というのは「宝の山」なのである。「ぜひともわが国に持ち帰って、自国の技術として開花させようぞ」といったところなのである。 つまり、日の丸の技術者が軽んじれば軽んじるほど、笑いが止まらない外人が増えるという仕組みである。しかし!もしこれを読んでいる日本のゲームエンジニアが、大卒だったり大学院卒だったりして(別に学歴はどうでもよい)、少しは学問としての手法を学んでいる人物だとすれば、ぜひ、それをまとめて論文として投稿・出版するなり、特許を取得するなり、どこぞのオープンソースプロジェクトでソース公開するなりしてほしいと思う。出来れば学会で。出来れば日本と英語圏で2回は発表してもらいたいと思う。そういった機会として扱われるのであれば「学者の遊び」が主になっている、なんたらゲーム会議なり、ほげほげエンタテイメントコンピューティング国際会議なんてのも役に立つと思うのだ。そして、そういう気概のある若いエンジニアを擁してしまった企業、開発チームの上司は、悪い顔ひとつせずに、旅費と参加費ぐらい出してやってほしいと思う。有給休暇は使ってもらうとして。


以下は執筆予定の章

飽きる・飽きない

「飽きっぽい」のは誰のせい?

「飽き」のメカニズム

「面白い」を測定する

物理評価と主観評価

逃れられない物理評価尺度

質と時間

遊び研究の歴史

中世・近代・現代の遊び研究

遊びの要素

遊びの目的

生活と遊び

システムとしての遊び

遊んでいるようで遊べない人々

遊びとアートとゲームの違い


Notice

このドキュメントは無保証です.
This document have no warranty.


Comment Please!


Name:

Last update at 2005-04-30 08:54:47

Counter: 862, today: 1, yesterday: 1

Front page   Edit Freeze Diff Backup Upload Copy Rename Reload   New List of pages Search Recent changes   Help   RSS of recent changes
Counter: 862, today: 1, yesterday: 1
Last-modified: Tue, 10 May 2005 17:35:43 GMT (4543d)
Powered by XOOPS Cube The XOOPS Project / all rights are reserved by Akihiko Shirai / XOOPS Cube
Theme Designed by OCEAN-NET