Unityでパーティクルの実験

最近Unityをいじくったりしてます。

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

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

UnityParticle500

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

おそらく個々の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のいいところは、開発環境がそのまま実行・デバッグ環境になることですね。下の画面のように、実行中に視点を動かして、描画が正しく行われているか確認したりというのが、何の苦労もなくできます。

UnityIDE500

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

2010年1月5日

Warp Smash


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

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

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

今日活躍のプチ関数。

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行ゲームを意識してたんですが、こういうのが好きな体質なので無理っぽいです……。

2009年5月11日

同人・インディーゲーム開発の現状と課題

IGDA日本 同人・インディーゲーム部会(SIG-Indie)第1回研究会「同人・インディーゲーム開発の現状と課題」

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

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

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

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

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

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

2009年5月3日

ゼルダの伝説の画面切り替え

時のオカリナにおける上から目線 – 枯れた知識の水平思考

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

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

2008年11月26日

ゲームのフレームレート

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

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

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

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

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

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

2008年9月30日

トップページ
プロフィール

はてなブックマーク
wonderfl