Gamasutra水口氏のインタービューに見る、日本の同人ゲームとゲームインディーズの未来

Gamasutraの水口哲也氏のインタビューに、日本の同人ゲーム/ゲームインディーズの話題が挙がっていた。

• Gamasutra - Feature - "Nobody Beats the Miz: Q Entertainment's Tetsuya Mizuguchi on Name Recognition"

Gamasutra:「新しい人を発掘するという意味で、どのようにして『Every Extend』を見つけたのですか？このゲームのオリジナルは同人ゲームです。日本ではこのような同人サークルがゲーム産業への良い登竜門だと思いますか？」

水口:「それはある美的思想をもった人たちの一種のインディーズ・バンドですね。オリジナルの『Every Extend』はディレクターの世永が見つけたもので、PC向けのフリーウェアとして公開されていました。作者に連絡を取ってもよいかどうか訊かれたので、私は『OK、やるべきだ』と言いました。コンタクトを取ってみたところ、作者は学生でした。これは驚きましたね。名古屋大学の学生で、とても若かったので、『おお、こりゃいいね』と思いましたよ。で、音とビジュアルエフェクトを付けて『Every Extend Extra』としてコンソールゲームで出してもいいかどうか話したところ、とても興奮してましたね。結局、彼には『Every Extend Extra』チームにゲームデザイナーとして参加してもらいました。

こういう状況は本当にいいことだとおもいます。若い人がPCフリーゲームを作り、誰かがそれをみつける…、本当にいい話だと思いますよ。」

PSPでリリースされている「Every Extend Extra」は、元はd:id:o_mega氏作のフリーゲームである。

EVERY EXTEND EXTRA エブリ エクステンド エクストラ - PSP

参考:Every Extend Extra／ゲーム情報ポータル：ジーパラドットコム

ゲームインディーズ冬の時代の日本国内において、Every Extend Extraは確かに本当にいい話の例だろうと思う。多くは情報の海の奥底に埋もれるか、タダ同然で権利を買い上げられるか、まあ、不運な運命を辿る。そういう意味では、Every Extend Extraには日本のゲームインディーズの未来が託されているのかもしれない。大げさだが。

Gamasutraのインタビューワーは日本のゲームシーンについて若干知識があるらしく、次のように続く。

Gamasutra:「こういう事例というのは今後より多くなってゆくんでしょうか？米国では、ゲーム産業に入るための方法としてインディペンデントなゲーム開発を選ぶ人たちが結構います。ですが日本では、同人ゲームシーンの規模が大きく、結構な数の人たちが業界には入っていないように見えます。たとえば、こちらでは長健太氏の名前が、そういったゲーム産業の主流に参加しないで活動している人として有名です。」

水口:「長健太さん？」

Gamasutra:「多分、アメリカでは『Tumiki Fighters』や『Noiz』などのゲームで一番人気のある人ですよ。デザインから、アートやミュージックに至るまで全部一人で作っている人です。ところが、一般のコンピュータ会社で技術職に就く40歳くらいの人のようなのです。彼のゲームは本当に人気があります。」

d:id:ABA氏は本当に海外での知名度が高い。一方の水口氏は知らないようだ。

それはさておき、インタビューワーは興味深い指摘をひとつしている。水口氏が「kind of an indie band type aesthetic（ある美的思想をもった人たちの一種のインディーズ・バンド）」と呼ぶ*1同人ゲーム界隈は、規模が大きいにも拘らず(ごく一部を除き)ゲーム産業の登竜門となっていないのは、指摘のとおりだ。

Gamasutra:「ところで、その界隈の流れは沢山追いかけているんですか？それとも『Every Extend』が最初ですか？」

水口:「ええ、私自身は見ていませんが、Q ENTERTAINMENTでは世永のような若い才能がいつも見ています。時々、『これどうおもいます？』と訊いてきますよ。また多分、こういう機会があるでしょうね。」

最後の一文は、日本のゲームインディーズにとって一瞬期待させてくれる。だが、そのまま鵜呑みするわけにはいかないだろう。

水口氏本人が同人ゲーム界隈の流れを追いかけていない、というのがひとつの例だ。もし金の卵がゴロゴロしているのなら、目を皿のようにして探すはずだ。それをしていないとはつまり、日本のゲーム開発者、ゲームプロデューサー、あるいは経営に近い人間は、「同人ゲーム界隈＝ゲームインディーズ」とは見ていない、ということだ。

多くが趣味として作られる同人ゲームがコンシューマータイトルまで行くためには、

• クオリティ
• ボリューム
• 表現
• 著作権
• 商品としての魅力

などなどさまざまな障壁が待っている。しかもこれは最低ラインのハードルであって、そこから先はさらにプロのタイトルとのガチンコ勝負というさらなるハードルが待ち構えている。言うまでもなく、厳しい道だ。

「Every Extend」の例にせよ、うがった見方をすれば、一種の"保険"ではなかったか、と見ることも出来る。Q ENTERTAINMENTの立ち上げ時期、いくら水口氏率いるとはいえ、大手ではなく実績もない企業が、紙の上以外に影かたちもない*2タイトルを作り出すより、あるていど成立したものを拾い上げてきた方が保障がある。後発組にはつきもののリスクを犯さなければいけない状況下でリスクを最小限にする一種の方法だったのではないか、と見ることも出来る。

もしそうならば、やはりまだまだ冬の時代のままなのだ。その状況が幾分暖かくなるためには、市場にある程度のインパクトが必要になる。それも、まともな利益が期待できない(つまり、食ってゆけない)低額カジュアルゲーム市場でもなく、市場のパイが狭すぎるPC市場でもなく、海外勢に太刀打ちできないPCオンライン市場でもなく、経営者層・経営者層に近い人間にもはっきりとインパクトがある、日本のコンシューマー市場で必要なのだ。残念だが。

「Every Extend Extraには日本のゲームインディーズの未来が託されている」というのは、大袈裟ではないのかもしれない。

*1:皮肉だろうか？aestheticという単語は相当堅苦しいと言うか、なんというか、そんな単語である。

*2:そして、面白いのかどうかはもちろん、売れるかどうかすら分からない

Firefox拡張japanizeの対応サイトにGamasutraを追加

最近公開されたFirefox用の拡張にjapanizeというものがある。これは簡単に言えば、人力の翻訳プロクシだ。翻訳データはWikiのように登録ユーザが編集する形を取っている。公開後間もないので登録サイトの数が少ないが、特殊な専門用語が踊っているサイトは*1機械翻訳よりも精度が期待できそうだ。もっとも、基本的にはメニューの項目などを日本語化するくらいで、本文の翻訳まではあまり想定していなさそうである。一般的なニュースサイトなどは機械翻訳の方が良いだろう。

• ネットを日本語化する:Japanize

対応サイトにigda.orgがあったのだが、japanizeをインストールして閲覧したところ、北米のチャプターが訳されていない部分が多かったので、以前Annual Reportの翻訳を手伝った時にちょうどチャプターの名前を日本語化していたデータを参考に追加しておいた。とりあえず、日本語化されてないチャプターはなくなったはずだ。

次に、Gamasutraを翻訳サイトに追加した。といってもトップページをざっと訳しただけだが。Gamasutraはトップページの情報量が多く、さらに改行などの問題で上手く翻訳データが反映されず、苦労した。まだまだ抜けているところもあるので、協力者募集。

Gamasutraはゲーム開発者にとって非常に有用な情報の宝庫であるが、いかんせん英語圏のサイトなので、日本の開発者にはなじみが薄い。記事自体の翻訳には色々問題もあるが、とりあえずメニューなどが日本語化されているだけでもだいぶなじみやすくなったろうと思う。

暇があれば、GamestudiesやGame-Reserach.comとかもやってみたい。

*1:つまり訳すために専門知識が必要なサイト

CEDEC2006に出ます

CEDEC2006の登録期限が迫ってますが、私は今年は講師側で出ます。といっても発表するわけではなくてラウンドテーブルのお手伝いですが。

ラウンドテーブルなので当日の参加者の面子やその場の雰囲気で内容は大きく変わってくるだろうと思いますが、最終日なので1日目・2日目の関連セッション（IGDAアカデミックなど）の内容も組んだ形になると思います(予想ですが)。

Adobeが次期Flash Player/次期Flashオーサリングツールの機能を募集中

• Flash Team: Feature requests for the Flash Player - post them here.
• Flash Team: Feature requests for interactive designers and developers - post them here.
• Flash Team: Feature requests for designers and animators - post them here.

一番上のエントリーが次期Flash Player(FP10?)に関して。下2つのエントリーが次期Flashオーサリングツール(Flash 9?10?)に関して。ユーザ層別にエントリーが分かれている様子。

on(release)が無くなる！と一時期話題になったが、多分、日本語で日本のAdobeに言うよりも、英語で直接リクエストを投げた方が意見が通りやすいだろう。言いたいことがある方はおはやめに（英語で）。

要望のリスト抜粋

以下のような要望があげられている。
Flash Playerへのリクエストの中から目に付いたものの抜粋。実際にはもっと多くのリクエストがあがっている。

• オープンなcodecのサポート
• 右書き（アラビア語・ヘブライ語など）のテキスト入力サポート
• コンテクストメニュのカスタマイズ
• ogg,midiのサポート
• 3D API(DirectX/OpenGL)
• FileReference.getSelectedFilePath()
• ファイルのPOST送信機能
• plugin機能
• yield
• lambda function
• 戻る・ブックマークのサポート
• テキスト周りのシステムカラーサポート
• HTMLのよりよいサポート
• p2p
• マウスカーソルハンドリングの改善
• サウンド・動画の倍速再生
• セキュリティ
• GPSサポート

必ずしも速くないAVM2のint/uint型

ActionScript3.0になって、それまで数値は全てNumber型であらわされていたものが、int型とuint型で型指定できるようになった。この、int/uint型の利点としてよく言われることの一つとして高速化がある。

ためしにこういうコードを書いて実験してみると確かに速い。

var t:Number = getTimer();
var cnt:Number;
for(var i:Number=0;i<1000000;i++){
	cnt++;
}
var temp:Number = (getTimer()-t);

結果：20 ms

var t:Number = getTimer();
var cnt:int;
for(var i:int=0;i<1000000;i++){
	cnt++;
}
var temp:Number = (getTimer()-t);

結果：8 ms

ところがである。どうもそうは問屋が卸さないらしい。

• kuwamoto.org » Blog Archive » Avoid ints in ActionScript
• gskinner.com: gBlog: Types in AS3: ints not so fast, uints slow!

Sho Kawamoto氏によれば、以下のようなコードを試すとint型よりもNumber型の方が速いらしい。

for (i=0; i<10000000; i++)
	j = (j + 15) / 7;

On my machine, the int version takes 331ms, while the Number version takes 291ms.

さらに、Grant Skinner氏の詳しい調査によると、なんとuint型がNumber型よりも遅い、という結果になったという。

もっとも、このテストはまだFlex2がベータの時の実験結果のようなので、正式版の今となっては必ずしもそのまま鵜呑みにできない結果である。そこで自分でも同様のテストを行ってみた。

テストコード

public function testFunc():void{
	var i:int;
	var j:int;
	var t:Number;
	var n:Number;
	
	//int 
	t = getTimer();
	for(j=0;j<10;j++){
		for(i=0;i<16777215;i++){var a:int=[code]; }
	}
	n = getTimer()-t;
	n /= 10;
	this.outputStr += "[int](int):"+n.toString()+"\n";
	
	//uint
	t = getTimer();
	for(j=0;j<10;j++){
		for(i=0;i<16777215;i++){var b:uint=[code];}
	}
	n = getTimer()-t;
	n /= 10;
	this.outputStr += "[int](uint):"+n.toString()+"\n";
	
	//Number
	t = getTimer();
	for(j=0;j<10;j++){	
		for(i=0;i<16777215;i++){var c:Number=[code];}
	}
	n = getTimer()-t;
	n /= 10;
	this.outputStr += "[int](Number):"+n.toString()+"\n";
	
	// *
	t = getTimer();
	for(j=0;j<10;j++){
		for(i=0;i<16777215;i++){var d:*=[code];}
	}
	n = getTimer()-t;
	n /= 10;
	this.outputStr += "[int](*):"+n.toString()+"\n";
}

for文を16777215回まわし、その中でローカル変数a,b,c,dを宣言し、ループイテレータ変数(i)に対していくつかの計算をして代入している。a,b,c,dはそれぞれ、int型、uint型、Number型、**1型の変数として宣言した。さらに、このfor文を10回行い、10回の平均値を求めた。

結果

結果は以下のようになった。

• [int]はループイテレータ変数(i)の型を示している
• テストの計算式はGrant Skinner氏のコードを参考にした
• 減算がなかったのでi-1とi-2を追加した
• mxmlc:Version 2.0 build 143452,-optimize=trueでコンパイル
• マシン:PentiumM 1.1GHz, OS:WinXP Pro SP2

var v:TYPE = i/2;

[int](int):634.3
[int](uint):618.2
[int](Number):216.5
[int](*):2313.3
























































-



























var v:TYPE = i*2;

[int](int):633.4
[int](uint):625.2
[int](Number):212
[int](*):745.8
























































-



























var v:TYPE = i+2;

[int](int):179.1
[int](uint):178.5
[int](Number):226.2
[int](*):743.4
























































-



























var v:TYPE = i<<1;

[int](int):249.2
[int](uint):241.8
[int](Number):214.1
[int](*):285.8
























































-



























var v:TYPE = i-1;

[int](int):167.4
[int](uint):161.8
[int](Number):227.5
[int](*):740.8
























































-



























var v:TYPE = i-2;

[int](int):184.7
[int](uint):646.4
[int](Number):235.1
[int](*):764

分析

• *型は予想通りどのテストでも遅い
• 加算はint/uintの方がNumberよりも速い（但し、50ms程度）
• 乗算・除算はint/uintの方がNumberより約3倍遅い
• ビットシフトはint/uintの方がNumberより遅い(但し、30ms程度。どの型もあまり差がない)
• 減算は興味深い結果
  • i-1の時はint/uintの方がNumberよりも速い
  • i-2の時はintとNumberの差はあまり変わらないが、uintが遅い(intの約3倍)

これから判断すると、uintがintよりもいつも遅くなるという仕様は正式版では改められてはいるが、場合によってはuintが遅い時があるようだ。また、「乗算・除算はint/uintの方がNumberより遅い」というのはやはり同様のようだ。

Sho Kawamoto氏の解説によれば、

virtually all math is done internally as Number, not as int.

つまり内部的には数学演算は全てNumber型で処理しているのでこういう結果になるらしい。

正しい型指定 vs. 最適化

Sho Kawamoto氏は以上のような結果からint/uint型ではなくNumber型をAS2の時と同じように使うことを薦めている。それに対し、以下のような反論もある。

• Tink » Blog Archive » Use the Correct Type for the Job

16777215回も回して数十msの差なら大した問題ではない、と。それよりも適した正しい型指定をする方が重要だ、と。

たしかに、16777215回も回すfor文があったら、型指定云々の前にまずアルゴリズムを見直すべきだ。コンパイラやAVM2の仕様が変わったら、こういう最適化Tipsは役に立たなくなる可能性もある(もっとも、型指定まわりの仕様がそうそう変更されるとも思わないが…)。実際問題として、Flashが重いのは描画処理がかなりの原因であり、レンダリングエンジンはFP8とFP9ではほぼ同じでAVM1/AVM2でも共通なので、最適化はコードよりも描画部分に力を入れるべきだろう。

そんなことを考えながら以下の記事を読むとなおいいかもしれない。

• BIT-101 Blog » Blog Archive » Optimization: When to do it.

ちなみに、ループイテレータ変数(i)は正しい型という意味でも、パフォーマンス最適化という意味でもint型にすべきのようだ。

*1:アスタリスク、全ての型を表す

ActionScript3 メモと感想

なんとか時間が出来たので、久しぶりにFlash関係について書いてみる。

ActionScript3.0は「硬い」

初めてActionScriptに触ったのは、AdobeのLiveMotion*1のものだったのだが、さくっと書いてさくっと試せる、まさにスクリプト、という感じのものだった。それがAS2になって段々とJavaっぽく（硬い言語っぽく）なり、そして今回のAS3だ。「実に硬い言語になったなぁ」、という感じである。

AS2までは、言語APIの拡張、という感じで後方互換を保ちながらも機能追加、という感じがするアップデートだったものが、新しい実行環境(AVM2)の搭載を期に一気に言語APIを整理したようだ。特に、描画APIとイベントAPI周りというFlashで最も重要な部分が大分違うので、別言語でFlash(swf)を作成しているかのような感じがする(文法はほとんど同じはずなのだが)。

一般的にスクリプト言語は、結構あいまいな記述でもそのまま動いてしまったりするので「やわらかい」感じがする。対して、CやJavaはちょっとした事ですぐに"怒られる"ので、まるで厳しい教師が付きっ切りで見ているかのような、「硬い」感じがする。じゃあ、AS3はどちらかというと、後者のような感じがする。

例えば、

var t:Number = getTimer();
doSomething();			//とても重い処理
tf.text = getTimer() - t;	//かかった時間を表示

みたいなコードはAS2まではOKだったのが、AS3では型変換がされていないと怒られる*2。

var t:Number = getTimer();
doSomething();			//とても重い処理
var t2:Number = getTimer() - t;	//かかった時間を求める
ft.text = t2.toString();	//型変換して表示

このように書く必要がある。これくらいはコンパイラ、あるいは実行エンジンが動的に判断してよろしくやってくれないかなー、と思うのだが、AS3は厳格らしい。このあたり、人間が色々考えなくともコンピュータがよろしくやってくれる、スクリプト言語のメリットが薄れた感じがする。もちろん、最適化とか考えれば型の概念は必要になるのだけれども。基本は型の概念なし、指定すると最適化される、とかいう仕様だったら…、とも思うが、さすがにそれは無理か。

ともかく、AS1/2やJavaScriptやP言語のような、よい意味での柔軟さがAS3では若干スポイルされるのは間違いない。その代わり、実行速度や細かいエラーなどカッチリとコードを書ける利点が増えた。これまではおかしなコードを書いていても、コンパイルさえ通れば何にも教えてくれなかったので、後になっておかしな挙動を見つけて、一体なんでだろうと何時間も悩んだ挙句に見つけたのがケアレスミス、などということもよくあった。ある程度以上のFlashアプリケーションを開発するなら良い改良点だと思う。特にゲーム開発という意味では、アセンブリでごりごりと最適化！というような流れのあるゲームプログラミングのノウハウが今まで以上に使えるようになるだろう。Flash Playerというブラックボックスに阻まれて今まで手を出せなかった部分に、手を突っ込むにはAS3ぐらい「硬く」ないといけないのかもしれない。

もっとも「硬い」と言ってもJavaよりは柔軟性がある感じがする。おそらく最大のライバルになるであろう、Java Appletのように、いちいちオフスクリーンを用意して…といった目的への距離の遠さは感じない。Proce55ingはちょっと齧っただけだが、いい勝負のような気がする。まあ、しかし、普及率とユーザー層の多さを考えると、Flash Player 9とAS3が、辛うじて残っていたJava Appletの領域を侵食して駆逐しそうだ。それから先、クライアントサイドの領域がFlash一辺倒になるかどうかは、AdobeとMicrosoftのケンカの結果によるだろうけど。

-profileオプションが気になる

Flash9はまだでていないし、お金もないのでFlex2SDKでAS3をいじっている。コンパイラはmxmlcというものでmxmlというxmlかasファイルをコンパイルしてswfを作成する。コンパイラオプションが相当数あるのでいろいろいじっていたら、ドキュメントに載っていない、-compiler.profile/-profileオプションというものを発見。

コンパイルオプションの説明は

generate a movie that is suitable for performance profiling

とだけで、とりあえずtrueにしてみたものの何が変わったのか分からない。検索してもどこにも情報がないので一旦あきらめたものの、非常に気になるオプションだ。

なぜ気になるか、と言えばFlex1/1.5の時には旧Macromedia純正のActionScript Profilerというプロファイラ*3があり、非常に便利そうだったからだ。Flashの場合最適化が必要になるケースが多く、プロファイラがあれば非常に有用なことが予想されたのだが、Flex1/1.5は個人で手の出せる代物ではないので泣く泣くあきらめていた*4。Flex2はFlex1/1.5とは若干方向性が異なるものの、おそらくプロファイラはあるだろう、と予想しているのでまさにこれなのではないかと思うのだが…。実は有償版にしかプロファイラは付属しないのだろうか。

fdbを使いこなせたら良さそう

fdbはFlex2SDKにmxmlcなどと一緒に付属するデバッガだ。使い方を調べている途中なのでなんとも言えないが、使いこなせれば便利そうだ（もしかすると、これがプロファイラとして機能するのかもしれない）。

つかうにはちょっとコツがいる。

• まず、fdbをコマンドラインから立ち上げる
• コンソールに(fdb)と表示されるのでrunと入力してデバッガを開始する
• コンパイルオプションで-debug=trueとしたSWFを実行する(※このとき、再生が停止するので注意。SAFlashPlayerなどの場合、ウィンドウが開かないので実行されていないのかと勘違いして何度も実行させようとすると大変なことに。)
• コンソールでブレイクポイントなどを指定した後、continueと入力
• SWFが実行再開する

ブレイクポイントなどを指定せず、すぐにcontinueとするだけでもtrace文を拾ってくれたりするのでテキストファイルをいちいち確認する必要がないので便利。基本的にはFlash IDE付属のGUIデバッガと同じように使えるようだ。

*1:Macromedia Flash対抗ソフト。本家よりも使い易い面もあって(とくにタイムライン周りやビヘイビア)気に入っていたのだが、すぐに開発中止になった。

*2:少なくともFlex2SDKのmxmlcでは。

*3:Flash IDEについている、DL速度をエミュレートする"プロファイラ"ではなくて、一般的な開発環境で言うところの、実行時のプロファイラ

*4:AsProfやFlasPなどのフリーのものもあったが、AsProfはAS1専用、FlasPはリンク切れ、と帯に短し襷に長し…

GDC2006のゲームデザイン関連公演ふたつ

• Half-Life2の工学的ゲームデザインプロセス - プレイテストによる製作評価ループ
• 映画的ゲームデザイン - ゲームプレイへの融合

とりあえず、リンクだけ。前者は開発プロセスとしても面白い。後者はRicheard Rouge III氏の公演で、なかなか新しい視点。