Welcome to MSDN Blogs Sign in | Join | Help

Browse by Tags

All Tags » ゲーム開発   (RSS)
Thursday, July 03, 2008 8:54 PM

コミュニティゲームへのゲーム投稿 その3

今回は投稿されたゲームのピアレビューの詳細を説明します。ピアレビュー(Peer Review)のピアとは日本では聞き慣れない言葉ですが、仲間、同僚といった意味があります。ちなみにネットワーク形態の1つでP2Pと呼ばれているピア・ツー・ピア(Peer-to-Peer)のピアも同じ意味です。 ピアレビューでは大まかに分けて以下の４つについてレビューをします。 投稿されたゲームの情報が正しいものか ゲームが正常動作するか 禁止事項に反していないか ゲーム投稿者のClassfication(分類)が妥当なものか
Posted by Yuichi Ito | 0 Comments
Wednesday, July 02, 2008 7:41 PM

コミュニティゲームへのゲーム投稿 その2

今回は作成したゲームの投稿の仕方を紹介します。投稿できる形式はccgameファイル形式で、これはVisual Studio上のメニューから ビルド/Package {プロジェクト名} as XNA Creators Club Games を選択することで生成されます。 XNA Creators Club Onlineのトップ画面の上方にあるメニューから Games/submit game を選択します。 この時に下の様なプロジェクト編集画面になります。もし、この画面が表示されなかった場合は、プレミアムアカウントでサインインしていない可能性があります。
Posted by Yuichi Ito | 1 Comments
Wednesday, May 21, 2008 4:13 PM

コミュニティゲーム・ベータ開始

Creators Club Online のリニューアルと同時に Community Gamesのベータ版 が開始されました。このベータは 北米地域のCC会員向け のものなので日本からベータ版を使ってみたいと言うときにはいくつかの注意が必要です。 日本からでもCC会員であれば、ゲームの投稿、投稿されたゲームのピアレビューをすることができ、投稿されたゲームはピアレビューを通過すると北米地域のマーケットプレースに配信されます。 北米地域のマーケットプレースに配信されたゲームは、Creators Club
Posted by Yuichi Ito | 0 Comments
Wednesday, May 07, 2008 7:38 PM

XNA GSで作ったゲームを遊ぶ

XNA GSで製作したゲームを友達のPCなど、開発環境の入っていないPCで動作させるにはいくつかのランタイムが必要になります。現状では、必要とするランタイムがインストールされているかを自分で調べてインストールする必要がありますが、将来的には作ったゲームを手軽に配布できる仕組みを提供する予定です。 XNA GSE 1.0で作られたゲームの場合 .Net 2.0 : Vistaには.Net 2.0は既に含まれているのでインストールする必要はありません Direct X 9.0c : DirectX End-User
Posted by Yuichi Ito | 2 Comments
Filed under: , ,
Friday, March 21, 2008 8:29 PM

テクスチャ撮影

テクスチャが欲しい その昔、コンシューマ機で3Dが使えるようになった時に使えるテクスチャのサイズは非常に限られたもので、中には最大32x64という、ウェブサイト上に使われるバナーより小さいサイズのテクスチャしか使えないマシンもありました。それが今ではSM1.1が使えるビデオカードでは2,048x2,048が基本になり、Xbox 360やDX10が使えるビデオカードでは8,192x8,192までの大きさのテクスチャが使えるようになりました。 これだけ大きなサイズのテクスチャが使えると、より高精度なものを作ることができる利点はありますが、逆に言えばそれだけのクオリティのものを作らなければいけないという面倒さが増えてしまいました。
Posted by Yuichi Ito | 1 Comments
Tuesday, February 12, 2008 6:48 PM

ネットワーク　その１０　オブジェクト所有権

クライアント/サーバー と ピア・ツー・ピア 型のどちらのネットワーク形態が優れているのかを議論するのが好きな人たちがいます。しかし、個人的にこの議論は間違ったものだと思います。誰が 「どちらか一方のネットワーク形態を選ばなくてはいけない」 と言ったんですが？私は両方の長所を活かしたハイブリット形式の大ファンです。 ネットワークプログラミングは妥協との戦いです。100%の正確さと、ラグがまったく無いという２つの状態を両立することは不可能で、トレードオフをしなければいけません。 時にはラグが多少大きくっなっても正確さをとる場合もあれば、逆に正確さを犠牲にして高いレスポンスを必要とする場合もあります。
Posted by Yuichi Ito | 1 Comments
Monday, February 11, 2008 8:12 PM

ネットワーク　その９　究極の圧縮方法

今まで紹介してきた狡猾な圧縮方法より効果的なデータ圧縮方法があります。それはデータ自体を送らないということです。 もちろん、まったくデータを送らないのでは相手側との同期ができません。でも、時には同期すること自体が重要ではない場合があります。 ２つのルール ゲームプレイに関連するものは同期しなければならない 殆どの物はゲームプレイに関与しない 効果音やアニメーションは殆どの場合は同期する必要がありません。もし、ネットワークを介してキャラクターが前に走って移動する場合、それぞれりマシンではその情報を元に、走るアニメーションを再生させ、そのアニメーションに合わせて靴音を鳴らすことができます。靴音が鳴るタイミングが多少ずれていてもゲームプレイには関係ないのでネットワークを介して足音を同期させる必要はありません。
Posted by Yuichi Ito | 1 Comments
Thursday, February 07, 2008 7:44 PM

ネットワーク　その７　ビットフィールドで圧縮

ビットフィールドは古くから知られている素晴らしいデータパッキング手法です。C#プログラマーがビットフィールドを使う機会は非常に少ないですが、ネットワークパケットの圧縮にはもってこいなので、この機会に使ってみましょう。 バイトは８ビット、intは３２ビット。でも、送るべきデータが８ビットや３２ビットの倍数にならないときはどうします？例えば以下のようなデータを送るとします。 bool isAlive; // 生きているか？ bool isFiring; // 撃っているか？ enum Species
Posted by Yuichi Ito | 1 Comments
Thursday, January 31, 2008 8:15 PM

ネットワーク　その６　量子化で圧縮

ビット数の少ない方が多いものより消費するスペースは小さくなります。 もしint型の値が0～100までの範囲しか取らないと判っているのなら、そのまま４バイトのint型として送るより、byte型にキャストして送ることができます。 場合によっては値が表す範囲を値をずらすことによって減らすことができます。例えば、キャラクターの高さのデータを送る必要があり、高さはcmで表されるとします。このゲーム中のキャラクターの高さの範囲は、ドワーフ(100cm)から巨人(300cm)まであります。 300という値はbyteで表現できる範囲(0-255)を超えているので、キャストすることはできません。
Posted by Yuichi Ito | 0 Comments
Tuesday, January 29, 2008 6:38 PM

ネットワーク　その５　圧縮

限られたネットワーク帯域の中では、送信するデータを圧縮することは非常に重要なことです。 Zip等の一般的な圧縮アルゴリズムはネットワークゲーム向けではありません。これらの圧縮はある程度のデータ量がある場合は効率良い圧縮が期待できますが、ネットワークパケットのように小さいデータを圧縮するには不向きです。ここで必要なのは２０バイトのデータを１０バイトにするような圧縮方法です。 初心者がよく考える手法として、送信側で複数のパケットを続けてバイトストリームして一般的な圧縮アルゴリズムを使って圧縮し、圧縮されたデータをパケットに分割して送受信するというものがあります。確かに圧縮率は高くなるのですが、この手法には致命的名欠点があります。この手法では、圧縮したデータを展開するに全てのパケットが失われること無く、順番に配信される必要があります。この為にはSenDataOptions.ReliableInOrderを使う必要があり、レイテンシが増加する原因になってしまいます。
Posted by Yuichi Ito | 0 Comments
Friday, January 25, 2008 11:43 AM

ネットワーク　その４　帯域　ボイスチャットについて

XNAフレームワークはボイスチャットをサポートしており、ヘッドセットがある場合に自動でチャットができるようになっています。便利な機能ではありますが、使用中はより多くのネットワーク帯域が必要になることに注意が必要です。 音声データは500 B/s以下の帯域に圧縮され、ヘッドセットに向かって喋った時のみにデータ転送を行います。 デフォルトの状態では全てのプレイヤー同士で会話することができるようになっています。もし、ひとりが他の15人のプレイヤーに話しかけた場合、 500 * 15 = 7.3KB/s
Posted by Yuichi Ito | 1 Comments
Monday, January 07, 2008 6:44 PM

ネットワーク　その1　レイテンシ

「さて」とセイウチはいった「ネットワークの話をしましょう」 (訳注:元ネタはルイス・キャロルの セイウチと大工 から) ネットワークゲームプログラマーには以下の三つの不死の敵がいます レイテンシ データが相手に届くまでに掛かる遅延時間 パケットロス データが相手に届かない現象 帯域 送ることのできるデータ量の上限 以上の三つについて順に話しましょう。 レイテンシは物理的理由によって決まります。SFの世界では何十年もの昔に実現しているのに、物理学者は未だに光速を超える手段を発見していません。ですから、秒速３０万キロ/秒を超える速度でデータを送ることができません。これは物理学者のせいです(そんなに難しいことなのか？)
Posted by Yuichi Ito | 1 Comments
Wednesday, May 02, 2007 11:17 PM

Content Pipeline その３ そのカスタマイズ

2008/02/22 追記:XNA 2.0のサンプルを ここ に追加しました。 長いよ え～、今回の記事は非常に長く、単に読むだけでも10分程、内容を理解しながらだと30分以上掛かることもあるかもしれないので、暇な時間を見つけて読んでやってください。本当は、数回に分けて書こうと思っていたのですが、一気に読んだ方が理解が深まると思い、一つの長い記事にまとめました。 いよいよコーディング GSE 1.0 Refreshで追加された新機能として文字列描画がありますが、使用する文字コードを spritefont
Posted by Yuichi Ito | 3 Comments
Attachment(s): TextMessageSample.zip
Tuesday, April 17, 2007 8:32 PM

Content Pipeline その２ その流れ

コンテントの流れ 前回は、コンテントマネージメントに関する問題の複雑さについて書きました。今回から、その問題を解決する為に設計されたXNAのコンテント・パイプラインの仕組みを紹介していきます。下図は、XNAのコンテント・パイプラインの概念図です。 パイプラインの名から判るように、コンテントが上から下へ流れるように処理され、アセットとしてできあがったものをゲームで使うようになっています。コンテントを川の水、アセットを水道水として考えると、コンテント・パイプラインは、浄水場と配水管に例えることができます。
Posted by Yuichi Ito | 0 Comments
Monday, April 16, 2007 7:33 PM

Content Pipeline その１ その問題点

ゲームにはコンテントが必要 ゲーム製作で欠かせない要素として、プログラミングの他にコンテント作成があります。コンテントとは、3Dモデル、テクスチャ、フォント、サウンド、ゲームのパラメーターといったものの総称です。このコンテントを作るツール、例えばテクスチャならフォトショップ、3DモデルならMayaなどといったツールをDCC(Digital Content Creation)ツールと呼びます。DCCツールというと、高いお金を払って買うものと思われがちですが、自分で撮ったお気に入りの写真をゲームで使えば、その写真を撮るのに使ったデジカメはある意味DCCツールといえる訳です。さらに言えば、ゲームで使われるメッセージなどをWindowsに付いてくるメモ帳を使えば、それも立派なDCCツールとなるわけです。
Posted by Yuichi Ito | 0 Comments
More Posts Next page »
 
Page view tracker