最近なにかと話題のゲームエンジンUnity。ずっと前から気になっていてちょくちょくいじってはいたんですが、実際にゲームを作ってみたことはありませんでした。そんなところにIGDA日本のUnityのセミナーがありまして、面白そうな内容でぜひ行こうと思ったんですが、Unityをろくに触らないまま遠路出かけるのはもったいないということで、急遽ゲームを１本でっちあげてみました。

ゲームはこちらです。要求スペックはそこそこ高めです。

• Avoider（要Unity Web Player）

ちなみにセミナーの内容については「強火で進め」さんのブログにまとめられています。

• IGDA日本ゲーム開発セミナー「Unityの導入と実践」に参加して来ました

以下、メイキング的なメモ書きです。

今回、時間がなかったこともあって、「リソースは自作しない」というのを絶対方針にしました。UnityにはAsset Storeという公式の素材マーケットがあるので、主にそこからフリーのものをいろいろ見つくろってきています。背景やトゲ付き鉄球など、全部既製の素材です。

また、プレイヤーキャラクターはMixamoを利用しました。有料ですが、3Dの人体モデルを作成したり、自作のモデルをアップロードしてモーションをつけたりできるサービスです。今回は、Mixamo本家で3Dモデルを作成して$10で購入し、Unityのプラグイン（Mixamo Animation Store）から歩きモーションと立ちモーションをそれぞれ$10で購入しました。しめて$30です。モデリングもモーション付けも自分でやるとものすごく大変な作業ですから、とりあえずこうして解決してしまえるのはとてもありがたいです。

ゲームデザインについてですが、作る直前にUnity上でラグドールの実験をしてまして、ラグドールが吹っ飛ぶのは面白いよねということで（ゲームのバグ動画などでよくありますよね）いろいろ物を投げ込んでぶつけて吹っ飛ばしてやろうと。物理エンジンも活用できるし、見栄えがするのでいいかなと思いました。

吹き飛ぶときの爆発はDetonator Explosion Frameworkを使用しています。Prefabをスクリプト１行で生成するだけで派手な爆発をしてくれるアセットです。ゲームの内容的にはなぜ爆発するんだって感じですが（笑）、一度使ってみたかったので。まあ、特撮などでも意味もなく爆発しますし。このキャラがそういう体質なんでしょう、きっと。

避けゲーということで安直にAvoiderとタイトル決定。たぶん主人公の名前か何かでしょう。タイトル画面は、Adobe Fireworksで適当にプリセットのスタイルを適用して字詰めしてロゴを作成、プレイヤーキャラを配置してライトを当ててできあがり。ちょっとでも動きがないと寂しいので、トゥイーンライブラリのiTweenを使って、ライトのフェードインとロゴの明滅をさせています。ちなみにこのトゥイーンライブラリというのはFlashの世界で生まれて発展してきたもので、簡単に言うと「動き」をライブラリ化したものです。コード１行でオブジェクトをアニメーションさせたりできます。UnityにもFlashのタイムラインのようなアニメーション機能があるのですが、Flash同様、トゥイーンライブラリのほうが楽に動きをつけられる場面が往々にしてあります。iTweenのサイトのExamplesに印象的なデモがたくさんあります。

ただ避けて生き延びるだけではゲームとして単純すぎると思ったので、宝石を取るとスコアが加算されるようにしました。ゲームはプレイヤーに２つ以上のことを同時にさせるといいそうです（参考：社長が訊く『New スーパーマリオブラザーズ Wii』）。というか、Asset StoreにGem Shaderというシェーダがあって、綺麗な宝石モデルも入っていたので使ってみたというのが本当のところで、順序が逆かもしれません。ちなみにシェーダの中身をまったく見てません。ブラックボックスのまま使って（使えて）しまっています。

宝石を取ったときにエフェクトがないと取った感が出ないのでどうしようかと思ったんですが、標準アセットのParticlesパッケージの中にあったFireworksをもうこれでいいやとそのまま使用。あとは、せっかくなのでコンボボーナスをつけたり、宝石を２種類にしてスコアを変えたりしてよりゲームっぽくしてみました。なお、時間が経つと宝石が小さくなって消えるのもiTweenを使ってます。

難易度調整、実はこれが一番時間がかかったかもしれないんですが、NORMALモードとHARDモードを用意するという逃げに走りました。あとカメラアングルは最初もっと低かったんですが、フィールドの上のほうがオブジェクトに隠れて見づらくなり、下のほうばかりをうろうろするプレイになってしまって、あまりに不自然だったので、ほとんどトップビューにしてしまいました。せっかくのキャラクターがよく見えなくなってしまうので躊躇したんですが仕方なしです。タイトル画面のアップでカバーする感じですかね（笑）。それと、プレイヤーキャラの当たり判定は、胴体より下だけにしてあります。

BGMは、一応DTMerなので本来なら自作するべきところなんですが、CubaseのLoopMashのプリセットをちょっといじって書き出してシーンに配置して終わり。宝石を取った効果音もCubase付属音源から適当な音色を探してきて使用。オブジェクトが跳ね返る音は効果音素材CDからです。

と、こんな感じで作ったんですが、ゲーム内容的にも制作工程的にも相当横着してますね。とりあえず見ていただいた方々に面白いと言っていただけたので（ありがとうございます！）いいのかな？と思います。既存のアセットを使いまくってるのはバレバレでしたけど（笑）。

*

さて、こうして短期間で１本でっちあげてみて、Unityのことが以前よりもずっとよくわかったというか、正直、過小評価してたような気がしてきました。すごいゲームエンジンだとは認識していたんですが、ゲームエンジン本体よりも、周辺の文化圏こそが真価だったんじゃないかと。今回、他人のアセットの力を素直に借りようと最初に決断していたとはいえ、素材を探してぽんぽん放りこんで、ちょこちょことスクリプトを書き足すだけで、あっという間にそれっぽいものが組み上がっていくのは、いいんだろうか本当にって感じでした。ほとんどチートのような気もするんですが、実はこれが本来の使い方（のひとつ）なのかもしれません。セミナーの講演の中でもレゴブロック的という話があったように記憶しています。

実のところ、現状のAsset Storeはサーバがかなり重かったりして、お世辞にも使いやすいとは言えないのですが（公式フォーラムのこのスレッドで、Unityの中の人いわくなんとかするそうです）、そのあたりが解決されてアセットの数が増えれば、さらにとんでもないことになりそうな予感がします（なお、ゲームに使用可能な3D素材については他にもTurboSquidなどがあります）。

あと、スクリプトについても、まだ慣れていなくてAPIがあまり身についていないのですが、何か引っかかったらUnity Answersやフォーラムで検索すればすぐ答えが出てきましたし、そもそも今回自分で書いたJavaScriptコードが全部で600行ほどしかありません。流暢に書けなくてもどうにでもなる量です。

このスピードとこのコード量で、１人で、仮にも物理エンジンが走り、人体モデルが動くような3Dゲームをでっちあげられるというのは、今までは考えられなかったことなんじゃないでしょうか。3Dゲームを作れるのはナムコとセガくらいみたいな時代もあったと思うんですが、すごいカジュアル化です。Unityが言うには「民主化」とのことですが、ある意味、言い訳ができなくなりつつあるようで、ちょっと怖いなと……まあ、一方で、リソース作りが大変なのは基本的に変わらないとも思うんですけどね。

こうした至れり尽くせりのゲームエンジンに乗っかれるかというのは、特にプログラミングをする人にとって心情的に難しいところもあると思うんですが、自分の場合はどうもメリットのほうが大きそうなので、本気で乗っかってみようかなと考えはじめてます。

とりあえず、もう１本くらい実験作を作ってみたいですね。もうちょっとシーンやスクリプト的に凝った何か。

Unityの簡単な説明をすると、米Unity Technologies社製のゲームエンジンで、PCやブラウザ、iPhone等で動く3Dアプリケーションを作ることができます。GUI環境に3Dモデル等の素材を放り込んで、JavaScriptやC#でスクリプトを書くだけで（割と）簡単に動かせます。Flashを触っている方は、Flash IDEの3D版だと考えればだいたい感覚的にあってるかも。ブラウザ上でGPUアクセラレーションつきの本格的な3Dが動くこと、iPhoneの3Dゲームが比較的手軽に作れること、開発環境の制限バージョンが無料になったことなどで人気が出ているようです（残念ながらまだ日本語化されていないのですが）。ブラウザのプラグインをインストールして公式のデモを見ると、かなりのものが動くのが分かると思います。

というところで、唐突ですが、ABAさんのパーティクルテストにつられて、似たような、オブジェクトをたくさん出す実験をしてみました。

• Particle Test

プロジェクトファイルはこちら。

おそらく個々のGameObjectがパーティクルを描画するのはGPU的に嫌だろうということで、GameObjectは座標を保持するだけにして、下のようなスクリプトでビルボード群のメッシュを毎フレーム作成してまとめて描画してみました。とりあえずCore 2 Duo/3.16GHz、RADEON 4550で10000個は出ているようです（上限を上げればもっと出るかもしれません）。UnityのJavaScriptは.NET（Mono）ベースで、C++の半分の速度は出るよとのことなんですが、確かに結構な速さはあるようです。

function LateUpdate()
{
	var particles = GameObject.FindGameObjectsWithTag("Particle");
	...

	var i = 0;
	var size = 0.5;
	for (var particle in particles) {
		var position = particle.transform.position;
		vertices[i++] = Vector3(position.x - size, position.y - size, position.z);
		vertices[i++] = Vector3(position.x - size, position.y + size, position.z);
		vertices[i++] = Vector3(position.x + size, position.y + size, position.z);
		vertices[i++] = Vector3(position.x + size, position.y - size, position.z);
	}
	...

	var mesh = GetComponent(MeshFilter).mesh;
	mesh.Clear();
	mesh.vertices = vertices;
	mesh.colors = colors;
	mesh.uv = uv;
	mesh.triangles = triangles;
}

まあ、パーティクルを多数出すだけならUnity組み込みのパーティクルシステムを使えばいいんですが、シューティングの敵弾などで自前でやる必要が出てくることもあるかなと。

ちなみにUnityのいいところは、開発環境がそのまま実行・デバッグ環境になることですね。下の画面のように、実行中に視点を動かして、描画が正しく行われているか確認したりというのが、何の苦労もなくできます。

Unityというプラットフォームがどんな感じかについてはまた後ほど（たぶん）。

どこかの絵を見て連想したので作ってみました。いわゆるポンのバリエーションで、マウスクリックでパドルが反対側にワープします。せっかくなので、BlurFilterを使ってパドルにモーションブラーをかけてみたりしました。

パドルをボールに合わせるのに加えて、パドルを早く反対側に移動させないとボールが返しにくい、でも早くクリックしすぎても駄目というタイミングゲームにもなっているのがミソかなと勝手に思ってます。だいたいゲームというのは、アクションにせよ何にせよ、プレイヤーに２つ以上のことを同時にさせると面白くなるんじゃないかと。１つだとどうすればいいかすぐ分かってしまうので。

ただ、マウスカーソルがFlashからはみ出さないように頑張るという不自然な３つ目が出てきてしまって微妙。マウスカーソル自体邪魔だし、ブラウザゲームでは、マウスが使えるといってもネイティブアプリケーションと同じようには扱えないってことでしょうか。

今日活躍のプチ関数。

private function clamp(n:Number, min:Number, max:Number):Number {
	if (n < min) { n = min; }
	if (n > max) { n = max; }
	return n;
}

スコアのカンストつき加算にまで乱用してたり。

　
score = clamp(score + 1, 0, 9999);
　

作る前は100行ゲームを意識してたんですが、こういうのが好きな体質なので無理っぽいです……。

面白そうなので行ってきました。日帰りだし、まだその域に達していないので研究会だけ。たまにこういうのに行ってみるとやる気が出てくるなあ。パワーエサを食べたパックマンみたいに一定時間（駄目だろうそれ）。

パネルディスカッションの、フリーソフトを同人ソフトとして作り直すのはどうかという話。付加価値は絶対に必要として（iPhoneみたいに別プラットフォームならあまり気にならない？）、フリーでうまくいっていたものをリッチに作り直しても、文字通り蛇足になりかねないのが難しいところだと思います。プロトタイピングの話との合わせ技で、フリー版をプロトタイプを兼ねて公開するというやり方ならありかも。というか割と普通ですかね。

プロトタイピング自体は、ゲームに限らず、何かを作るのに普遍的に有効なテクニックだと思います。たとえば絵なら、ラフ絵をたくさん描いて、良さそうなものだけを選んでペン入れ・彩色みたいな。早い段階で悪いものを取り除いたり、きちんと修正すれば、結果が底上げされて実力を水増し（笑）できると。コーエーのシミュレーションゲームの君主パラメータ決定みたいなものだと思ってるんですが。

音楽も同様。というか自分そんな感じで作曲してます。HDDに思いつきで入力したフレーズがたくさんあって、ファイル名に使えそうなら”#”、使えなさそうなら”-”とか印をつけて（記号に意味はない。いつのまにかそうなってた）。困ったら適当にいくつか引っ張り出して無理やりくっつけるとか。安直です。まずいです。

ちなみに、ABAさんの講演でwonderflが紹介されてました。もっともっと人気になってほしいウェブサービスです。

あと帰りにちょっと寄った秋葉原Hey。ミスタードリラーグレートが２台並んでるとか、しかも同期連射つきとかうらやましい。だいたい、連射装置で有利になるパズルゲームってどうなんだろう。先行入力でもつければなんとかならないかなあ。

を読んで思い出したこと。

初代ゼルダの伝説は画面の端に移動するとマップが切り替わるようになってますけど、地上と地下で画面切り替え時のスクロール速度が違うんですよね。これも地下の閉塞感を効果的に演出していて、ボディブローの類だと思います。この条件式たったひとつでできる処理がどういう経緯で入ったんだろうと考えると興味深いです。

以前は60fps原理主義者だったけど、DSでいろいろ遊んでいて考えが変わったなあ。遅延のある液晶画面で同期スムーズスクロールは画面がぼけっぱなしで目がやられることが。こういう場合、あえて30fpsにして液晶が完全に描き換わるのを待ったほうがいいのかな、とか。

あと、今のGPUってフルHDで60fpsキープして好き放題描画するにはまだ全然性能足りてないでしょうし。たとえGPUの性能が10倍になっても、なんだか今の10倍くらいの仕事は余裕でさせられそうじゃないですか。真・三國無双で画面内が本当に群衆で埋めつくされるのはいつになるんだろう。

RPGなどで映画的な演出をするには低フレームレートのほうがいい場合があるんでしょうね。映画は24fpsなので、ゲームでも24fpsにするとそのカクカクした動きが映画のように格調高く見えることがあるという。ただ、映画もフレームレートを上げようという話があるみたいなので、今後はそうした効果は保証されなくなったりするのかも。

ちなみに、2Dシューティングだと60fpsでもフレームあたり自機が４ドット（低解像度で）とか動くので、30fpsだと弾幕の間をすり抜けられなくなります。ケイブの弾幕シューティングでショットボタン押しっぱなしで移動速度が遅くなるようになっているのは、単にそういうゲームデザインというだけでなく、フレームあたりの移動量を落とさないと敵弾の隙間で止まれず弾避けが物理的に不可能になるという切実な面もあると思います。そのあたりを意識していなくて理不尽ゲー気味になっているシューティングをたまに見る気がする。つまり、自機の速度が速い（＝１フレームあたり移動量が大きい）のに隙間の狭い弾幕が飛んでくるという。

それとモーションブラーのこともありますね。ゲームの映像の多くは、フレームごとに動きの情報が含まれていない、リアルのカメラでは撮影できないシャッター速度１／∞という特殊な映像。モーションブラー＝時間軸のアンチエイリアスってどこで耳にしたんだっけ。全画面で時間軸アンチエイリアスをかけるとそれだけで負荷数倍になるわけで、他の要因とあわせて数倍、数倍と掛け算していくと、GPUの性能はまだ本当にまったく足りないんだと思う。その筋では。3Dゲーム自体がムーアの法則に喧嘩売ってるというか。

僕なんかのやることにはもう完全にオーバースペックですけど。PCから駆動系はなくなってしまえと思っているので、当然ビデオカードもファンレスだし（笑）。

ActionScript 2ではこれを秒100回実行するだけでパフォーマンス的にもう限界だったんですが、ActionScript 3では余裕があるのでもう少しきちんとやりたいなと（2Dで、しかもキーボード操作でどこまでやる意味があるのかわからないので、あくまで未定）。

で、いろいろ本を眺めて付け焼刃をつけようとしてるわけですが、本格的にやるなら、走行性能曲線やその他のいろんなグラフを作成してコードから利用するものを作らないといけなさそう。これは挙動のシミュレートだけじゃなく、先のエントリで書いた、ハンドルの応答の調整のようなことにも役に立つんじゃないかと。

さらに、そうした特性エディタ（仮称。もっといい呼び名ないでしょうか）は、ゲーム一般のオブジェクトの制御にも便利なんじゃないだろうか。特に、ゲーム実行中にon the flyでオブジェクトやカメラなどの特性をグラフでコントロールできれば、かなり制作効率が上がって、なおかつゲーム自体のバランスもきちんと調整できるような気がする。いちいち勘で式を何度も書き換えてコンパイルせずに済むし、assert的な異常値の入力の検知も自動的についてくる。どう使うか、どれだけうまく行くかはともかく、そうした仕組みを検討してみる価値はあるように思った。

エディタをどうしよう。何か出来合いのソフトで使えそうなものがあればそれが一番なんですが。単に曲線を描いてデータ化できるだけでなく、数式なども通るやつ。

現在メインで作っているのは、Windows用の全方向スクロールシューティングです。タイトルは「デルタ・ストライダー２（仮称）」。開発度は30％くらいで、まだ画面を見せられる段階にはなってません。

とりあえず前作のデモ動画です↓

操作はアナログスティックとショットボタン１個のみ。非弾幕系で、ちゃんと意識して狙って撃てて、避けられて、ごく自然にかっこいい動きができるのが売りです。これを操作そのままに大幅発展させたものになるんですが……順調に遅延してます（シェ○ムー並み）。

それどころか、Xbox 360で自作ゲームの配信が可能になるそうで、今C++で作ってるんですが、いっそのことXNAでプログラム書き直したほうがいいんじゃないかとあわてて調べてたり。まだどうするかわかりませんが。

というか、ずっとダラダラやってる間にあちこち全方向シューだらけになってしまったような。皆考えることは同じってことでしょうか。できれば今年中に完成が見えるあたりまで持っていきたいなと。こればかり作っているともたないので（特に敵キャラのモデリング。いわゆるアブストラクトシューティングのように割り切ったほうが賢いのかもしれないけれど……）息抜きでFlashで遊んだりすると思いますが。