Twitter @HigenekoTwitter #XNA
今日は招待サンプルを紹介します。
Xbox Live!の機能のひとつに、フレンドリスト内の友達と一緒にネットワークゲームをプレイしたいときに誘える招待機能があります。XNA GS 3.0ではこの招待機能がサポートされています。招待するケースとしては以下の二つのケースがあります。
XNA GS 3.0上では、このどちらのケースでもNetworkSession.InviteAcceptedイベントが発生します。このイベントを受け取った時に、NetworkSession.JoinInviteメソッドを呼ぶことで招待された側が招待した側のセッションに接続できるようになっています。以下はイベントハンドラへの登録と、ハンドラ内での処理の例です。
NetworkSession.InviteAccepted += InviteAcceptedEventHandler;
void InviteAcceptedEventHandler(object sender, InviteAcceptedEventArgs e) { // 現在のセッションから抜ける if (networkSession != null) { networkSession.Dispose(); networkSession = null; } // 招待されたセッションに入る networkSession = NetworkSession.JoinInvited(maxLocalGamers); }
同じゲームをプレイしている場合は、通常のNetworkSessionの振る舞いと殆ど同じですが、違うゲームをプレイしている場合は振る舞いの仕方が変わってきます。ただし、これらの処理は全てOS側で行われるのでゲーム開発者は前述のInviteAcceptedイベントの実装をするだけです。
テスト時の注意
招待機能はXbox Live!の機能なので、ネットワークゲームのテストの様にシステムリンク(ローカル)を使ってテストできるのと違い、クリエータークラブ会員になっているゲーマータグが二つ必要なことに注意してください。
今回はセーフエリア サンプル(Safe Area)の紹介をします。
世の中には様々なTVがある
ゲームをプレイする人達のTV環境は実に様々なものがあります。
オーバースキャンとセーフエリア
PCモニタなどのイメージ全体を表示するアンダースキャン方式に対して、HDTV、SDTVのどちらも、その多くがイメージ全体を表示することのできないオーバースキャン方式を採用しています。
イメージ全体を表示することができないので、ゲームでスクリーン座標の左上(0, 0)に文字を表示したりするとオーバースキャン方式のディスプレイでは文字が読めなくなってしまいます。
こういったオーバースキャン方式のディスプレイには以下の二つのタイプのセーフエリアがあります。
タイトルセーフエリアには文字などの大事な情報を表示する領域で、下図の青い色の領域になります。アクションセーフエリアは殆どのディスプレイで表示される領域です数では緑色の枠内の領域になります。そして、赤い部分はディスプレイによっては全く表示されない領域です。
この画像は1280x720の画像なので、ゲームのインターフェースのデザインなどをするときにガイドラインとして使えるようになっています。
さて、タイトルセーフエリアに大事な情報を表示するからといって、Xbox 360、PCの両方で文字列をタイトルセーフエリアに描画した場合、Xbox 360上での見た目は良いとしても、PC上だと無駄にまわりのスペースが空いてしまいます。
そこで、XNA GS 3.0から追加されたViewport.TitleSafeAreaプロパティを使います。このプロパティPC上では元のビューポートのサイズと一緒になりますが、Xbox 360上ではビューポートの80%の領域、つまりタイトルセーフエリアを返します。
Safe Areaサンプル内にあるAlignedSpriteBatchクラスでは文字列をタイトルセーフエリアの右端、左上といった位置情報を指定して描画できるようになっています。
また、SafeAreaOverlayはコンポーネントになっていて、Xbox 360、デバッグの設定の時のみにタイトルセーフエリアの外側の領域を赤く表示するようになっています。
実際のゲーム開発の場合に気をつける事としては、
解像度とアスペクト比
TVモニタの場合は標準解像度の640x480から、1080pの1980x1080まで様々な種類があり、またアスペクト比も16:9と4:3の二種類があります。
Xbox 360向けのゲームで様々な解像度とアスペクト比に対応するもっとも簡単な方法は720p、つまり1280x720を使うことです。Xbox 360には1/4～4倍の解像度にスケーリングしてくれるハードウェアがあるので、720pを設定するとどの解像度でも自動的にスケーリングしてくれます。また、720pのアスペクト比は16:9ですが、4:3のTVを使った場合にはTV上では以下のようにレターボックス表示になります。
モニタとの距離
ゲーム開発中、PCモニタとの距離は60センチ程度ですが、実際にリビングルームでゲームをする場合は3メートル程の距離があります。と、米国では言ってますが日本の住宅事情を考えると、もうちょっと短い距離になりそうですが、要点としては自室でPCモニタを見ている感覚でゲームを作ってしまうと、リビングルームでプレイする時に文字が小さくて読めないという問題が発生します。目安としては720pの解像度で20ポイント以上の大きさの文字列をつかうことです。
TVとの距離の他にも
レイアウトに注意
3Dゲームのシーンを描画する時には気にする必要はあまりありませんが、メニュー画面などをデザインする時にはセーフエリアを意識してデザインする必要があります。特に、パズルゲームやテーブルゲームなどの固定画面型の2Dゲームの場合にはレイアウトがそのままゲームプレイに影響するので、画面一杯使ってレイアウトした結果、TV上ではゲームをプレイするのが不可能になってしまったなんて事にならないよう注意しましょう。
元ネタ:Safe Areaに含まれるドキュメントファイルから
Creators Club Onlineに以下の３つの新しいサンプルが追加されました。
一気に紹介すると長くなるので、三回に分けてそれぞれのサンプルを紹介していきます。今回はローカライゼーション サンプルについて紹介します。
ローカライゼーション
コミュニティゲームでゲームを投稿する場合、配信地域を選ぶことができます。現状ではアメリカ、カナダ、イギリス、フランス、イタリア、そしてスペインの６カ国で、2009年の前半には日本が加わり７カ国になります。世界の複数の国々の人達に自分の作ったゲームを楽しんで貰うためには必要な作業としてローカライズがあります。そこで、このサンプルではローカライズされた文字列とアセットの使い方のコードが含まれています。
ローカライズされた文字列表示
このサンプルでは言語別のリソースファイル(.resxファイル)を用意し、ゲームクラスコンストラクタの中で実行環境の言語情報を以下のコードのように指定して文字列を変更しています。
Strings.Culture = CultureInfo.CurrentCulture;
SpriteFontDescriptionクラスから派生したLocalizedFontDescriptionクラスに複数のリソースファイルを指定できるようになっていて、ここに各言語の文字列が入ったリソースファイルを指定し、コンテント･パイプライン内でLocalizedFontProcessorによって変換されます。
言語別のリソースファイルは、リソース名.言語コード.resxのようになっています。このサンプルではリソース名がStringsになっていて日本語のリ��ースファイル名はStrings.ja.resxとなっています。この言語コードはISO 639-1で定義されているアルファベット２文字になっています。
殆どの場合は言語コードを指定するだけで済むのですが、言語コードだけでは足りなくなる場合もあります。例えば、同じ英語でもアメリカの場合はcolorでもイギリスの場合はcolourと違いがあります。その場合は言語コードと国名コードの組み合わせを使います。国名コードはISO 3166-1で定義されているアルファベット２文字を使います。アメリカの英語の場合はen-US、イギリスの英語の場合はen-GBとなります。
この言語コード-国名コードの組み合わせをカルチャ名と呼び、カルチャを表すCultureInfoクラスを生成する時に以下のコードのようにして使用します。
Strings.Culture = new CultureInfo("en-GB");
ローカライズされたアセット読み込み
ローカライズ作業の大半は文章の翻訳になりますが、中にはテクスチャ等のアセット自体をローカライズしたい時があります。このサンプルでは読み込むアセット名を前述のリソースファイル名と同じように、アセット名.カルチャ名の組み合わせであることを前提として使うGetLocalizedAssetNameメソッドがゲームクラスに宣言されていて、国別の国旗テクスチャを変更しています。
以下はコミュニティゲームがサポートする国と言語の表です。
特徴として、カナダでは公用語が英語とフランス語の２つの言語が使われていることです。
このサンプルは複数の言語へのローカライズの参考にもなりますが、リソースファイルを使った日本語表示の方法としても参考になるサンプルだと思います。
前回に続いてPIXの機能と、私が実際にどんな状況でPIXを使って来たかを交えて紹介します。
ちなみにPIXはピクスと呼びます。たまにピックスと呼ぶ人もいますが私のまわりではピクスが多いです。
RenderウィンドウからDebug This Pixelメニューを使って表示されるDebuggerタブで、前回はDebug VertexやDebug Pixelをクリックしてのシェーダーのデバッグを紹介しましたが、今回はEvent部分をクリックして表示される情報について説明します。
Debuggerタブ内のそれぞれのピクセル情報の上の部分には、そのピクセルを描画したイベントが表示されます。上の場合はDrawIndexedPrimitiveとなっています。ここをクリックすると、左下にあるイベントウィンドウ内で該当するイベントが選択されます。
描画順序のチェック
PIXは描画に関する全てのイベントとその情報を記憶しているので、好きなイベントを選択することで描画の課程を調べることができます。これはVisual Studio上でブレークポイントを設定するといった未来時間一方向へのデバッグに対して、PIXではキャプチャーしたフレーム内での時間を自由に移動できるデバッグをすることができます。
イベントを選択した状態でRenderタブを選択すると、選択されたイベント処理が終わった直後の描画結果、つまりフレーム描画の途中結果を見ることができます。
不透明のオブジェクトを描画する場合、手前から奥にむけて順に描いていくのが効果的なのですが、普通にゲームをプレイしている限りでは描画順序は判らないし、描画コードを追いかけるのにも負担が掛かります。PIXを使うとそういった描画順序をここで簡単に確認できます。例えば、おっさんを描いている途中のこの段階で、遠景によく使われるスカイドームのオブジェクトが既に描画されている場合は、最後に書くべきスカイドームが先に描画されているという問題を発見することができます。
Meshデータの表示
Draw系のイベントを選択した時、Meshタブにはその描画がどの様に行われたかの詳細な情報が表示されます。Meshタブの上の方には三つのワイヤーフレーム画面が表示され、左から順に以下のようになっています。
Pre-Vertex Shader画面には頂点シェーダーに送られる頂点、通常はローカル座標のモデルが表示されます。Post-Vertex Shader画面には頂点シェーダー処理後、つまり射影座標内でのモデルが表示されます。そして最後は透視変換後のビューポート座標でのモデルが表示されるViewport画面となっています。
そして、それら三つの画面の下には頂点シェーダーに入力頂点のリストを表示するPreVSタブと、頂点シェーダー処理後の頂点リストを表示するPostVSタブがあります。
頂点シェーダーを書いている場合に良くあるのが頂点変換ミスです。この場合、画面に変な形のモデルが表示されている場合は頂点シェーダーに問題があるというのはすぐに判るのですが、画面に何も表示されない場合は頂点変換ミスの他にもピクセルシェーダー内でのミスという場合もあるので、Viewport画面にちゃんと表示されているかを確認することで、頂点シェーダー、ピクセルシェーダーのどちらに問題があるかを絞り込む事ができます。
頂点リスト内の頂点はクリックして選択することができ、選択された頂点は下図の様にモデル表示画面内と頂点リスト内で黄色で表示されます。また、頂点リスト内では選択された頂点が属する三角形の他の頂点が赤色で表示されます。
Deviceのステートの表示
Meshタブ内で頂点シェーダーが正しく動作しているのを確認したけど、まだモデルが表示されない。そんな時に調べるのがDeviceステートです。この情報はEventsウィンドウに表示されているイベントの左側にある数字(下図の黄色い部分)をダブルクリックすることで表示されます。
Detailsウィンドウには新たにDeviceタブが追加表示されます。このDeviceタブの中には更に複数のタブが追加されます。それぞれのタブにはカテゴリ別のDeviceのステート情報が記載されています。
私がここでよく使うのはPixel StateタブとOutput Stateタブです。Pixel Stateタブ内ではCullingやViewport、そしてAlphaテストなどの情報が役に立ちます。特にCullingが逆になっているとモデルがちゃんと表示されないし��Alphaテストに間違った値を設定しているとモデルが全く表示されないということもあります。また、Samplersセクションでは、どんなテクスチャが設定されているかを調べることができます。このSamplers部分で設定されているテクスチャの数字をダブルクリックすると、以下の様に設定されているテクスチャの詳細を見ることができます。
グロスマッピング、ディテールテクスチャといった、描画結果への反映が少ないようなテクスチャや、テクスチャに色以外の情報を入れている場合はここで調べたりしています。
Output Stateタブ内ではデプステストの有無、ブレンディングステートを調べるのに使っています。特にアルファブレンドを使っている場合の見た目では判りづらいステートの違いはここで調べています。
PIXを活用しよう
急ぎ足でしたが、二回に渡ってPIXの機能を紹介しました。2Dゲームと違って3Dの場合は実に様々なステートがあり、2Dゲームの場合はトライ＆エラーでどうにかなった問題も3Dゲームの場合はトライ＆エラーをするには時間が掛かりすぎてしまいます。そういった問題を解決するのにPIXは非常に強力なツールです。シェーダーのサンプルは沢山ありますが、シェーダーサンプル単体では問題なく動いたのにゲームに組み込んでみたら、動かなくなったなんて話を良く聞きます。そんな時にもPIXを使うと、なぜ動かないのかを調べることができます。
また、Xbox 360向けに開発している場合でも、開発しているPCにShader Model 3.0のビデオカードがあれば、Windows用のプロジェクトに変換して実行できるようにしておけば、殆どの場合は描画に関するデバッグは問題なくできます。そのままデバッグできない例としてはXbox 360限定のvfetchを使った場合ですが、vfetchはあくまで頂点データのフェッチ用の命令なので、シェーダー全体のコード量に比べると非常に小さく、頂点データをフェッチした後のシェーダーはWindows上でもデバッグできます。
私は、初代Xboxの頃からPIXを使って７年くらい経ちますが、今では描画に問題があったらすぐにPIXを立ち上げて調査するというのが習慣化していて、私にとってPIXはゲーム開発に必須のツールとなっています。
綺麗な絵を出すシェーダープログラミングに比べると地味なものですが、これを機にPIXに触れてもらえば幸いです。
Dream-Build-Playコンテストの受賞者が発表されました。今年は去年に増してクオリティの高いゲームが多数エントリーしました。そこで今回は受賞作品とその動画を紹介します。
第１位 CarnyValue: Showtime
第2位 Battle Tennis
http://www.battletennis.com/
第3位 Weapon of Choice
http://www.mommysbestgames.com/
第4位 WeHurricaneX2
これらの受賞作品のいくつかは制作者サイト内でコミュニティゲーム配信予定ということアナウンスされているものもあるので、これらの受賞ゲームに加え、惜しくも受賞を逃したけどクオリティの高いゲームがコミュニティゲームに配信されるではないでしょうか？