ikanatto weblog

ちなみにスタンドアロン版といっても公式に作られたものではなく、ユーザーがソースコード等をコンパイルしてpak詰めしたものに近い状態で公開されています。公開自体もだいぶ昔の話で、Quake 2エンジン部分コード公開直後あたりだったように記憶しています。

他のサイトの話によると大まかに二つほどスタンドアロン版があるようです。axionとltktbmがそれで、前者は設定などを全てコンソール入力から行えるエキスパート向け、後者が丁寧なGUIのついた初心者向けです。とりあえず、後者に限って話をします。

Download and Install

インストールにあたって用意すべきファイルは多くありません。とりあえず本体はこちら（70MB弱）。あとはマップやサウンド、スキンなどを適宜追加するものなのですが、若干古いMODなだけに扱っているサイトが閉鎖したりファイルがリンク切れをしていることも往々にしてあります。一応こちらに今までパブリックに公開されたマップのほぼ全てを置いておきます（260MB）。

本体をダウンロードしたらさくっと解凍してください。お好みの場所にフォルダを移したら、基本的にこれでインストールも完了です。おもむろにaq2.exeをダブルクリックすればクライアントが起動します。マップパックをダウンロードした人は出てきたフォルダの中身をactionフォルダに移してください。

How to Play

aq2.exeを実行したら遊べる状態、といわれてもコンソールが開いた状態になってそれっきりですよね。ここからまず何をするべきか、色々ありますので順を追って説明していきましょう。

1. 画面の設定

今のところデフォルトの設定になっています。まずはEscキーを押してメニューを呼び出します。そして上下キー（↑↓）でカーソルを動かしVideoを選択してEnterを押します。

すると画面設定に関する設定が表示されますので、お好みの状態にしてください。今時のPCなら、最大解像度にしてもまったく問題ないはずです。私がAQ2を遊んでいたのはMMX 266MHzクラスのPCが15万円くらいの時代でした。それでも最高の設定でまったく問題なく動いていました。

設定が終わったらEscを押してください。画面が再起動されて新しい設定が適応されたはずです。

2. キーバインド

おなじみキーバインドです。メニューを呼び出し、Optionsを選択してください。下のほうにCustomize Controlsというのがあるのでこれを選びます。

するといくつかの選択肢が出てきます。上からMovement Bindings（動き）、Weapon Bindings（武器）、Radion Bindings（ラジオ）、Misc Bindings（その他）です。動きに関してはETのそれとまったく同じなので、ご自身が最も遊びやすいと思うバインドをしてください。

武器の設定についてはちょっと解説が必要かもしれません。Special Weaponというのは各プレイヤーの選んだそれぞれの武器です。M4やスナイパーライフルなどがこれに当たります。そしてSpecial Weapon Functionとは各武器固有の機能のことで、スナイパーライフルであればズーム、M4ならバースト切り替えなどのことです。

ラジオは、まんま設定されたことをチームにラジオとして流します。これは単品で使うよりも、他に「誰が」「誰を」「どこで」「どうした」と伝えるチームチャットと共に使うことが一般的です。このやり方については後ほど説明します。

その他設定は実はかなり重要です。まず一番最初に確認すべきはBandage Woundです。これは敵の攻撃を受けて出血した場合（Bleeding）、手当てをしないといつまでもダメージを受け続けます。これを止めるのがこのコマンドです。また高いところから落ちてダメージを受けた際にも手当てをしないと移動が制限されます。他は読んで字のごとくの機能なのでお好みで設定してください。

3. その他の設定

他のFPS同様、マウス感度や音量などの設定をしてください。

4. BOTと遊ぶ

加筆予定 -20050520-

投稿者 ikanatto : 06:04 PM | コメント (0)

May 18, 2005

Enemy Territory: QUAKE Wars

Enemy Territoryはどこへ向かっているのか？

Splash Damage（以下SD)のトップページが久しぶりに更新されました。が、更新された内容はかなり驚きです。私はてっきりSDはRtCW2を作っているものかと思っていたのですが、まさかこんなのを作っていたとは…。

まだプレイも何もしていないのでコメントする時期ではないのですが、スクリーンショット一枚見た限りではアンリアルXMPをDoom3に移植したように見えます。また紹介文を読んだ限りではETのゲームシステム＋乗り物をそのままQuake世界に持ち込んだだけのようにも感じます。果たしてどんなゲームになるのか、正直不安8割期待2割といったところです。

以下はSDの紹介文和訳です。原文

そういえばetproの新しいバージョン出てます。3.1.15です。特に面白い機能の追加などはないようです。

Enemy Territory: QUAKE Wars(TM)開発のお知らせ

5月16日、id software（以下id）とActivisionはEnemy Territory: QUAKE Wars（以下ETQW）の開発を発表した。開発はSplash Damage（以下SD）が行い、idのMegaTextureレンダリング技術を使用する。ETQWはStrogg侵略と地球防衛軍の戦いを舞台にしたオンラインシューティングゲームで、仲間との連携、永続的な階級制度、昼と夜のミッション、そして強力な武器と乗り物がある。ETQWはプレイヤーたちを地球をめぐる新時代戦争の最前線へと送り込む。

idのCEO、Todd Hollensheadは言う。「Quakeのファンは長年Strogg本星での驚異的な戦いを楽しんできた。ETQWではプレイヤー達をすべての事の発端であるStroggによる地球侵攻の場面に戻り、人間か侵略者かになって生存を賭けた数多のキャンペーンを戦い抜く。他のidが手がけたゲームのように、ETQWは血みどろの戦いと、ファンタスティックな世界観、そして絶妙のバランスを保っており、魅力的で未来的なゲーム体験をお届けできる。」

SDのリードゲームデザイナーでありオーナー、Paul Wedgwoodは言う。「Wolfenstein: Enemy Territoryが数多のレヴューをされ、Game of the Yeahを受賞し、数多くのファンを獲得したことをとても誇りに思う。そしてまたidと共同でETQWの開発に携われることは驚くべきチャンスだ。Stroggによる地球侵攻の話はとても魅力的で、今回ETQWの開発を通じて徹底的なディティールと現実感を持たせたマップにより、話だけの世界を現実のものとすることが出来る。」

Struggの侵略が始まると、プレイヤーはEDF（Earth Defense Force 地球防衛軍）もしくはStroggの野蛮な軍隊のどちらかに属し、5つのクラスのうちからひとつを選択する。それぞれのクラスは専門化された武器や装備などで特色つけられている。戦う兵士達は40以上の便利で未来的な乗り物、配置可能な構造物、Quad-bikeや戦車、エイリアンウォーカーのような防衛システムを使い、大規模地上戦闘を繰り広げる。またヘリコプターや反重力戦艦による空からの攻撃も可能である。各々の戦闘において、チームは敵陣にて基地を建造して防衛システム、遠距離大砲、レーダー、そして前方指示システムを配置したり、障害物を破壊および建造することで素早い行動と戦略的優位を得ることが出来る。

ヘッドライト、サーチライト、そしてまた月明かりによるリアルでダイナミックな陰陽により昼夜を問わず戦いが繰り広げられる。一方で空気、天気、植物の組み合わせの正確なシミュレーションによって今までにないリアリズムの度合いに達する。戦場はMegaTextureにより完全に再現される。MegaTextureはidの開発したまったく新しいレンダリング技術で、数百万のポリゴンとギガバイトクラスのテクスチャを単一かつシームレスで、タイル張りではない風景にすることができる。またユニークなディティールダウンによってインチ四方サイズから遠方の水平線も明瞭なまでに対応する。

プレイヤーはクラスごとの特定のミッションをこなしたり、ファイアチームに参加することでボイスチャットやゲームの状況に敏感なミッション命令システムの利用といった便利な指示とコミュニケーションが可能である。複数の戦いで激しく争うキャンペーンでは、兵士は勝利のためだけではなく有用なスキル、チーム貢献による報酬、永続的な軍階級と勲章獲得のためにも戦う。ETQWは今年のE3でActivisionのブース（南ホールの1224番）にて公開される。

投稿者 ikanatto : 03:55 PM | コメント (0)

May 12, 2005

A little progress on project

It seems that the plugin project has been advanced a little. For now a plugin can load mds bones ( in fact, blame me...), however, there are lots of unloaded things, vertices and animations as well as tags. Still a quite time required to deal with them, in addition it is not destination of this project. The mdm/mdx exportor, that is!

I have a couple of messages that some people are waiting for this plugin out. Alright what has been done gave me a some common senses of c++ and max plugin building. So far I could do faster or smarter than I did, It should be. Please be patient for a while... thanks.

投稿者 ikanatto : 11:09 AM | コメント (0)

デザイン変更中

タイトルの通りWebのレイアウトとスタイルを変更しています。途中非常に読みにくくなったりアクセスできなくなったりするかもしれませんが、ご容赦願います。

ちなみに、先日TEIOU SEKKAIさんで遊んでいた時に私の実名をチャットで書いた方がいました。知り合いでETを遊んでいる人はいないはずなのですが…。

投稿者 ikanatto : 10:51 AM | コメント (0)

May 10, 2005

ET:UrT近況

Rumor has it...（ここだけの話･･･）

...we may start some testing very shortly for ET. Watch for upcoming information. Initially, we will not be using the new player models, but we will be testing some of the upcoming levels that have been seen, such as Tub's work.

More info soon.

以上は5月2日付けのフォーラムにてosさんの書き込みです。限定的ですがもう少しでテストプレイ段階に入るようです。SIDのスタンスとしてはクローズドベータをするつもりはなさそうなので、公開されるときすでにかなりの完成度になっているものと思われます。

スクリーンショットも小出しなだけにこちらも身悶えしてしまいますが、ここはぐっとこらえてQ3版UrTにフラストレーションをぶつけましょう。

現在フォーラムでは公式マップパックに何個、どれ（公式・個人作成問わず）を入れるか協議中です。ETは公式が6個だけということもあってちょっと不自由な思いもしましたので、ここで積極的に意見を投じたいところです。

ちなみにUrTはマップの完成度がかなり高いと＊個人的に＊思います。ゲーム性の面でもビジュアルの面でも、です。MODの良し悪しを往々にして決定する要素だけに、マップで既に＊個人的に＊定評のあるUrTですから嫌でも期待が高まってしまいます！

そんなきれいで楽しいマップを作ってくれているマップデザイナーtubさんのHPはtubさんこちらです。今まで作ったものに加えて今作っているもの、改良しているものなども紹介してくれています。ちらりと見るだけでも楽しいですよー。

投稿者 ikanatto : 12:26 PM | コメント (0)

May 07, 2005

W:ETソースコード朗読会　補足３

Reading the Source Code of W:ET Appendix #3

ゴールデンウィークもいよいよ終盤戦、みなさまごきげんいかがでしょうか。私は旅行行ったりフリーマーケット行ったりライブイベント行ったり釣りに行ったりゲームしたりと実に気ままに過ごしました。

今日は雨も降っていますしゲーム（もちろんET）をして一日をつぶそうとしていたのですがルーターの調子がすこぶる悪いので唐突にソースコード朗読会補足です。今回はクライアントサーバー間での情報のやり取りと同期、また若干ですがチートツールについても言及します。

クライアントの情報送信と予測

クライアントとサーバーの情報のやりとりについてすこしばかり。

みなさんETを遊んでいる時は大抵キーボードを使っているかと思います。この場合プレイヤーはキーボードで「前進（forward）」に割り当てたキーを押すと前進しますよね。当たり前なことを申しましたが、実はこの部分にはいくつか段階があります。

まずプレイヤーであるみなさんが「前進」に割り当てたキーを押すと、クライアント（みなさんのETプログラムです）は、「前進」キーを押してるぞ、とサーバーに情報を送ります。言い換えると、前進キーを押しただけではまだ前進していません。あくまで押した情報が送信されているに過ぎないのです。この前進キーを押している情報がサーバーに届き、移動の処理が行われ、計算された速度と位置がクライアントに返って来た時点で初めてクライアント（プレイヤー）は無事移動したことが確認できます。

またちょっとややこしいのですが、クライアントソフトはサーバーに送ったデータを元に、「こんな情報が戻ってくるに違いない」と予測を行います。なぜこんなことをするのでしょうか。理由はサーバークライアント間の通信タイムラグ、そして環境差による処理フレームレート同期を図ることが困難であるからです。もしクライアントがキー情報を送ってから、サーバーが速度と位置情報を返してくるまで何もしないと、ping値にもよりますが約0.5秒程操作と動きにズレが生じます。これは凄まじくプレイヤーにとってストレスになりETを駄作にしかねない問題です。クライアントが予測して結果を即座に画面へ反映してくれるおかげで、ストレスのない操作が可能になっております。

しかしあくまでも「予測」であるため、実際にサーバー上で処理される数値とズレを生じる可能性があります。この原因は回線の問題であったり処理の遅れであったりはたまたアンチラグの補正であったりと様々です。予測値と実際がずれた場合プレイヤーは奇妙な現象に遭遇します。つまりワープしたり、巻き戻ったり、相手が見えないのに攻撃を受けたり、逆に何もない空間を撃ったつもりでも当たっていたりします。

アンチラグ機能は他のプレイヤー移動という非常に予測しにくい情報に対する別角度からの補償です。サーバーはクライアントが見ている時間に遡って攻撃判定を行います。つまり現在のプレイヤーではなく（攻撃側クライアントping相当の）過去のプレイヤーが攻撃されているのです。

みなさん自分の画面ではRailgunの列車を動かしている相手を完全に捕らえているはずなのに列車にばかり当たって倒せないことなかったでしょうか。これこそがマップオブジェクト（障害物）とプレイヤー位置の非同期による問題です。あなた（私）が見ているとき射線は開けているけど、撃った情報がサーバーで処理されるまでの間に列車は動きます。加えて今見ているものも過去のものです。そして当たり判定を行うときアンチラグ機能により相手の位置は私が撃った時間のものに戻ります。しかし列車の位置は戻どころか余計に進みます。ゆえに弾丸はゴツンと鈍く列車に当たってしまいます。

サーバーとクライアントの関係について詳しくはこちらCode3Arenaにてご確認ください。

チートツールについて

上記のようにプレイヤーの具体的な数値はサーバー上で主に扱われています。そしてサーバーはクライアントからはキー情報（とコンフィグ）しか受け付けません。逆に言うとクライアントに送られてきているのはあくまでも計算結果であり、これをクライアントがバイナリ改変やメモリアクセスによって変更してもサーバー上の数値は変わらないのです。つまり攻撃可能な位置にいない相手をいきなり倒す、自分が死なないようなチートはサーバーハックでもしない限り無理です。

しかし考える限り可能なチート行為はあります。既に世に出ているオートエイムやウォールハックの類はまさにそれです。オートエイムはサーバーから送られてきた相手の位置情報を元にプレイヤーの視線方向を調整するものです。ウォールハックはクライアントソフトもしくはドライバソフトに改変をし、特定オブジェクトの描写条件を変更することによって達成しているものと思われます。これらのチート行為はQ3エンジンの特性上未然に防ぐ方法はありません。あくまでもメモリ監視や定期的にスクリーンショットを確認するなどによってのみ除外可能となります。

またとある特定条件下では、プレイヤーに対して攻撃が無効になったり当たりにくくなったりなど特殊な扱いを受ける場合があります。これはもともと通信の不具合など偶発的に起こりうる事態を保障する機能ですが、この状態を故意に作り出したとすればこれは立派なチート行為と考えられます。

チートしてまでゲームするくらいならバスケットボール持ってフリースローでもしていた方が健康にも良いですし楽しいのではないでしょうか。楽しくないゲームをしてストレスを溜める必要もないですしね。ET以外にも世の中には楽しいことなんてうなるほどありますが、私はとことんET負けた時はフリースローして気を紛らわしています:-D。

投稿者 ikanatto : 02:27 AM | コメント (0)

May 04, 2005

熱…

ADSL回線を複数台で使用するためにルーターを置いているのですが、どうにもこうにも熱で動作不良を起こしてしまっているようです。バッファローのBBR 4HGという安価なものなので性能は期待していませんでしたが、まさかこんなトラブルがあるとは…。

投稿者 ikanatto : 04:49 PM | コメント (0)

May 02, 2005

W:ETソースコード朗読会　第七回

Reading the Source Code of W:ET #7

今回の目標

さてさて本日もソースコードを飽きずに見ます。ただ、あまりプレイそのものに直接関係ない部分を紹介しても誰も興味を持ってくれずに悲しいので、今回と次回はゲームプレイに大きく関与するところにしましょう。

今回はプレイヤーの射撃、特に散弾に関する処理を見ていきます。次回はプレイヤーの移動に関連する項目を取り上げる予定です。

散弾現象について

既にご存知の通り、ETではピストル・SMG・ライフルにて程度の差はあれど照準に対して着弾点がずれる散弾現象がおきます。もしこれがないとモバイルMGは事実上最強の武器となりゲーム性を著しく損なう結果となるでしょう。現実性とゲーム性の点から散弾現象は妥当であり、遊ぶ立場からするとこの特性を詳しく知っておくことは大きなアドバンテージになりえます。

ソースコード朗読会第二回目にて取り上げておりますが、武器には固有の散弾率が設定されています。この数値は弾丸が発射される際に参照され、数値を最大としてこの範囲内でランダムにずれを引き起こします。そのため武器単体での数値の比較ではステンが最小の散弾となります。

しかしETではこの散弾率はさらにプレイヤーのライトウェポン・クラススキル及び発射体勢、発射方法によってさらに補正を受けます。ただ補正を受けるといっても感覚的にしか経験できず、これを比較するのは困難でした。

そこで今回はソースコードの視点からこれを明示的に比較検討してゆきます。

PM_AdjustAimSpreadScale

さっそくソースコードを見ます。bg_pmove.c 3063行以降を見てください。

void PM_AdjustAimSpreadScale( void ) {
	int		i;
	float	increase, decrease;

	（省略）

	pm->ps->aimSpreadScale = (int)pm->ps->aimSpreadScaleFloat;
}

関数の名前をみると、PM_AdjustAimSpreadScaleとなっていますからいかにも散弾率を調整するような関数ですね。

	switch(pm->ps->weapon) {
	case WP_LUGER:
	case WP_SILENCER:
	case WP_AKIMBO_LUGER:
	case WP_AKIMBO_SILENCEDLUGER:

	（省略）

	case WP_K43_SCOPE:
	case WP_GARAND_SCOPE:
	case WP_FG42SCOPE:
		if( pm->skill[SK_MILITARY_INTELLIGENCE_AND_SCOPED_WEAPONS] >= 3 ) {
			wpnScale = 5.f;
		} else {
			wpnScale = 10.f;
		}
		break;

	（省略）

	case WP_STEN:
		wpnScale = 0.6f;
		break;
	case WP_KAR98:
	case WP_CARBINE:
		wpnScale = 0.5f;
		break;
	}

この関数で最初に目を引くのがこのcase文です。何をしているのかを見てみると、pm->ps->weaponが示す武器の種類に応じてwpnScaleを設定しています。これによるとピストルは0.4、エンジニアの持つライフルは0.5、サブマシンガン（STEN含め）が0.6、モバイルMGが0.9です。ちょっと注意が必要なのはCoの武器FG42とスコープ付ライフルです。Coのスキルが3以上の場合は5、それ以外は10となります。狙撃武器は他の武器に比べて極端に高い数値になっていることを留意しておいてください。

if (wpnScale) {
		if( pm->ps->eFlags & EF_CROUCHING || pm->ps->eFlags & EF_PRONE ) {
			wpnScale *= 0.5;
		}
		decrease = (cmdTime * AIMSPREAD_DECREASE_RATE) / wpnScale;

その次の部分に行きましょう。if文の条件がpm->ps->eFlags & EF_CROUCHING || pm->ps->eFlags & EF_PRONEを見ています。つまりプレイヤーがしゃがんでいる、もしくは伏せているかを見ており、もしそうならwpnScaleを半分にしています。これからwpnScaleは武器の散弾率と乗算して散弾を抑制する数値だろうと予想できます。それにしてもCoの武器は散らばりすぎの気がしますが…。

decreaseはなんでしょうかね。cmdTimeは前回の処理時間と今回の差を1000で割ったもの、つまり経過時間（秒）です。これとAIMSPREAD_DECREASE_RATE定数を乗算し、wpnScaleで割っていることから散弾率の時経緩和量でしょうかね。

		viewchange = 0;
		if(BG_IsScopedWeapon(pm->ps->weapon)) {
			for(i = 0; i < 2; i++) {
				viewchange += fabs(pm->ps->velocity[i]);
			}
		} else {
			for( i = 0; i < 2; i++ ) {
				viewchange += fabs( SHORT2ANGLE(pm->cmd.angles[i]) - SHORT2ANGLE(pm->oldcmd.angles[i]) );
			}
		}
		viewchange = (float)viewchange / cmdTime;
		viewchange -= AIMSPREAD_VIEWRATE_MIN / wpnScale;
		if (viewchange <= 0) {
			viewchange = 0;
		} else if( viewchange > (AIMSPREAD_VIEWRATE_RANGE / wpnScale) ) {
			viewchange = AIMSPREAD_VIEWRATE_RANGE / wpnScale;
		}
		viewchange = viewchange / (float)(AIMSPREAD_VIEWRATE_RANGE / wpnScale);
		increase = (int)(cmdTime * viewchange * AIMSPREAD_INCREASE_RATE);
	} else {
		increase = 0;
		decrease = AIMSPREAD_DECREASE_RATE;
	}

次のif節にいくと、プレイヤーが狙撃中かどうかを見ています。もしそうならプレイヤーの移動量を、そうでないなら視野の変化量をviewchangeに代入しています。そして時間差で割ることで単位時間当たりの量にしています。これからAIMSPREAD_VIEWRATE_MINをwpnScaleで割ったものを除算しています。次のif節でviewchangeが0〜AIMSPREAD_VIEWRATE_RANGE / wpnScaleになるように調整され、結局viewchangeは0〜1の値になります。最終的にincreaseがviewchangeと時間差によって決定されます。decreaseが散弾率の緩和でしたから、こちらは増加因子でしょうか。

	pm->ps->aimSpreadScaleFloat += (increase - decrease);
	if (pm->ps->aimSpreadScaleFloat < 0) pm->ps->aimSpreadScaleFloat = 0;
	if (pm->ps->aimSpreadScaleFloat > 255) pm->ps->aimSpreadScaleFloat = 255;
	pm->ps->aimSpreadScale = (int)pm->ps->aimSpreadScaleFloat;
}

計算によって得られたincreaseとdecreaseの差を取ってaimSpreadScaleFloatに代入しています。結局この関数は、照準から着弾点のぶれ補正を武器の種類と体勢によって増減させるもののようです。decreaseが大きいほど早く補正量が減少するので、しゃがみや伏せがずれ抑制に効果があることが確認できました。同様に狙撃時は移動しながら、それ以外では視野を動かしながらだとincreaseが余計に増加しますので、正確な射撃を求めるなら狙撃は動かず、それ以外はきょろきょろせずに射撃を行うとよいのでしょう（30度以内ならOK）。しかししゃがみも伏せも同じ補正とはちょっと不思議ですね。

PM_Weapon

pmove.cには武器以外にも移動やクライアントからの入力処理といったゲーム中核部分の処理が多く含まれています。3198行以降にはPM_WEAPONなる関数があるのですが、これは武器発射に関するもっとも大きな処理と判断を行うものです。実に1000行以上もあります。散弾率を知りたい私たちが用があるのは、実際に発射することが可能であると判断された以降の4188行以下です。

	aimSpreadScaleAdd = 0;

	switch( pm->ps->weapon ) {
	case WP_KNIFE:
	case WP_PANZERFAUST:
	case WP_DYNAMITE:

	（省略）

	case WP_SMOKE_MARKER:
		addTime = 1000;
		break;
	// -NERVE - SMF
	default:
		break;
	}

4188〜4325のswitch文は、武器ごとの散弾量（なぜかここで定数量が決定されている）と次の行動までの時間です。これによるとピストルは20、エンジニアのライフル50、Coのライフル200、FG42は100、SMGは15〜25、固定MG及びモバイルMG（セット）は20となっています。ここでもCoの武器は不遇です…。

	switch( pm->ps->weapon ) {
	case WP_GARAND_SCOPE:
	case WP_K43_SCOPE:
		pm->pmext->weapRecoilTime = pm->cmd.serverTime;
		pm->pmext->weapRecoilDuration = 300;
		pm->pmext->weapRecoilYaw = crandom() * .5f;

	（省略）

	default:
		pm->pmext->weapRecoilTime = 0;
		pm->pmext->weapRecoilYaw = 0.f;
		break;
	}

続いて4385行目までです。ここは武器の「反動」についての設定のようです。これによるとCoの狙撃銃は発射後0.3秒間、上方向に0.5ないし0.25（COスキル3以上）、水平方向に-0.5〜0.5の速度で補正を受けます。FG42では0.1秒間にまたモバイルMG（セットでない）は0.2秒間に垂直方向のみに0.01程（COスキル3以上で半減）の補正を受けます。またモバイルMGとピストルも補正を受けます。

	pm->ps->aimSpreadScaleFloat += 3.0*aimSpreadScaleAdd;
	if (pm->ps->aimSpreadScaleFloat > 255)
		pm->ps->aimSpreadScaleFloat = 255;
	if( pm->skill[SK_MILITARY_INTELLIGENCE_AND_SCOPED_WEAPONS] >= 3 && pm->ps->stats[STAT_PLAYER_CLASS] == PC_COVERTOPS ) {
		pm->ps->aimSpreadScaleFloat *= .5f;
	}
	pm->ps->aimSpreadScale = (int)(pm->ps->aimSpreadScaleFloat);

さらに進むとこんな部分があります。aimSpreadScaleFloatがここの関数によって計算された散弾量をさらに加算されています。どこまで散弾させるつもりなんでしょうか。注目して欲しいのは2つ目のifで、COのスキルが3以上になると（もちろんクラスがCOで）aimSpreadScaleFloatが半減されます。これは驚くべき効果です！…といいたいところですが、もともとCoの武器（ライフルとFG42）が無茶な散弾量設定なのでそれほど効果があるともいえません。しかししかし！ステンは他SMGと同じ散弾率なのにこの適応を受けますから、事実上散弾が半減したSMGといえます（威力とオーバーヒートがありますが）。

さて、ここでも散弾量の上がりましたが最終的にはどうなるのでしょうか。

FireWeapon

ところ変わってg_weapon.cです。3884行以降にFireWeaponといういかにもな名前の関数があります。見てみましょう。

	if (g_userAim.integer) {
		aimSpreadScale = ent->client->currentAimSpreadScale;
		aimSpreadScale+= 0.15f;
		if(aimSpreadScale > 1)
			aimSpreadScale = 1.0f;	// still cap at 1.0
	} else {
		aimSpreadScale = 1.0;
	}

currentAimSpreadScaleは、0〜255の値を持つaimSpreadScaleを255で割ったものですから0〜1となります。これに問答無用で0.15プラスされます。凄まじい処理ですが、狙った場所に必ず弾丸が当たるのも困るので良いことです。この最大は1となり、結局aimSpreadScaleは0.15〜1です。

	if( ent->client->ps.groundEntityNum == ENTITYNUM_NONE ) {
		aimSpreadScale = 2.0f;
	}

少し飛んでこの部分を見てみましょう。if条件はプレイヤーの足元の状態を見ており、何もない、つまりプレイヤーが空中の場合aimSpreadScaleが強制的に2に設定されます。後でわかりますが、これが2になると通常の散弾量の2倍となります。これは空中にいる限り必ず適応されますので、単発だろうが連射だろうが相当の散弾を覚悟しなければいけません。

さていよいよ個々の武器発射段階になります。

	switch( ent->s.weapon ) {
	case WP_KNIFE:
		Weapon_Knife( ent );
		break;

	（省略）

		Weapon_FlamethrowerFire( ent );
		break;
	case WP_MAPMORTAR:
		break;
	default:
		break;
	}

ここは武器ごとに弾丸を出したり、パックを出したり、炎を噴出したりする関数を呼び出しています。散弾率が影響される弾丸系の武器は次のような形になっています。

	case WP_LUGER:
		Bullet_Fire( ent, LUGER_SPREAD*aimSpreadScale, LUGER_DAMAGE, qtrue );
		break;

Bullet_Fireは朗読会三回目で取り上げました、弾丸の当たり判定を行うものです。これに引数としてent（プレイヤー）とLUGAR_SPREAD（第二回で紹介）とaimSpreadScaleをかけたもの、そしてダメージを渡しています。これは今までの流れからすんなりと受け入れられるかと思います。…しかし次のところを見てください。

ここではなんとあれほど苦労して計算してきた散弾率の計算をフイにして、ライフルの場合にはaimSpreadScaleを1に設定しています！つまりこれはライフルを撃つ場合、しゃがんでいようが視界をブン回そうが連射していようが空を飛んでいようがまったく同じ散弾率になってしまうのです。…これを作った人の考えてることがよくわからなくなります。ライフルを飛んだり走ったりする時の突入用武器としなさいということなのでしょうかね。

まとめ

最終的に当たり判定の関数に渡される散弾率のパラメータから、何が散弾率に影響しているのかがわかったかと思います。つまりピストルとSMG（含むステンとFG42）の場合武器固有の散弾量、武器固有の時間ごと散弾量減衰、体勢による散弾量減衰幅の違い、視野角変更による散弾量増加、弾丸発射による散弾量増加が要因です。一方でライフルはどんな状況でも一定の散弾量であり、これは利点にも欠点にもなりえるかと思います。

一般的な話だけだとわかりにくいので一つ例を挙げます。SMGは一秒間に6回射撃が行われるので、散弾量は一秒間で60*6=360増加します。もししゃがんでいて照準の動きが±30度以内で少なかった場合、散弾量は1秒間で600減少します。つまり射撃による散弾量の増加を完全に抑えることが可能になります。立っていた場合は300減少し、若干散弾に影響が出ます。数値的にいうと、約25％散弾量が増加します。さらに近接戦闘時のように走り回って（立っていて）照準を激しく動かすような場合、時間経過と共に散弾量が増加し、これに弾丸発射の追加があるとすぐに散弾上限に達してしまいます。

これをふまえてSMGで戦うもっとも実用的な戦術は、立って（走って）照準の動きを最低限にして一秒間に3〜4発発射すると攻撃力と散弾量をうまくコントロールできるのではないでしょうか。ただ、理論上のお話と実際出来るかどうかは別問題ですが…。そこをこなせる人が、いわゆる「すごい」人なのかもしれませんね。

蛇足ですがライトウェポンスキルが4でCoスキルが3以上のCoのステンは、空を飛んでいない限り走り回っても連射してもほとんど散弾しなくなります。

投稿者 ikanatto : 04:49 PM | コメント (0)

ETPRO 3.1.13雑感

etproの新しいバージョンが出て数日が経過しました。もはやETのスタンダードといっても過言ではないＭＯＤになったetproですが、新バージョンの評価は私の知りえる範囲であまりよいとは言えないようです。武器ごとにヒットサウンドの有無が設定されたりなど、少なからず(？)な部分があるからでしょう。そんななか、特に気になる話がフォーラムにありました。

etproが重くなったというものです。どの程度遅くなるのかについては環境によって様々でしょうが、etproのフォーラムにこんな報告例がありました。

あくまで事例の一つですが、これを見る限り3.1.9と3.1.13は10％近くのfps差が出ています。そのため快適（＝有利）なプレイはマシンスペックや回線速度といった個々人の環境により強く依存する傾向となります。etproはアンチラグ機能の強化を謳っていますが、副作用としてより大きな負荷をもたらしては本末転倒と言わざるを得ません。

しかし無理もない結果といえばそれまでなのでしょう。etproはバージョンアップを重ねるにつれバグ修正やチート対策を施されてきました。これが通常のものよりも余計な負荷を発生させることは想像に難くありません。ですがこれらはサーバーサイドのコードでありクライアントのFPSが10％以上も落ち込む直接の原因とするにはいささか疑念が残ります。少なくとも3.1.9と3.1.13の間で非常に大きな差が生じている状況を満足に説明できないのではないでしょうか。

etproはあくまでMODで描写系やネットコードに関するエンジン部分の改変はないのですから、考えられる理由はそれほど多くないでしょう。つまり単純に新機能追加でサーバーサイドとクライアントサイドの処理が大幅に増加したからではないでしょうか。

そうなるとかなりの処理量増加をもたらす新機能群が果たして相応の効果を持っているかが問題になります。個人的には、NOです。3.1.9から3.1.13に盛り込まれた要素にはむしろET自体の持ち味を殺す要素もあります。ROF（=Rate of Fire）を変更するものはまさにその通りで、RtCWのmp40発射率でETのダメージ及び散弾率を適応すると間違いなく攻撃された相手はほぼ即死です。また距離によるダメージ減衰の消滅はスナイパーの存在意義を否定しています。Coはどこにクラスとしてのアイデンティティーを見出せばいいのでしょうか。これらの設定が強制ではないにしろ、ゲーム性を高めるものとは捉えにくいでしょう。

一方で評価されるべき点も多くあります。マップ位置のチャットへの反映、スパウンタイマー組み込み、新しいcvarなど。実際使用したことがあるのは半数もありませんが、精力的にユーザーの意見を反映しています。

fpsに直接関係ないのですが、プレイ感に最も大きな影響を与えていると考えるのはアンチラグ機能に関してです。ソースコードを読んだ際に紹介しましたが、アンチラグはかなりの処理量を伴います。具体的には誰かが「一回」攻撃を行うたびに、「全てのプレイヤー」の位置履歴を検索、設定、パーツ配置、当たり判定を行い、位置を元に戻します。もしサーバーに32人接続していて、16人が一秒間に6発撃てるSMGを撃ったとすると、32*16*6=3072回も一秒間に一連の処理が行われることになります。これはetproに限らずetmain共通の事項です。しかしetproはアンチラグ処理に手を加えており具体的に何をしたのかはわかりませんが、処理量は増加したように感じます。特に接続クライアントが増加するに従い当たり・くらい判定に違和感を強く受ける感覚があることは事実です。

ただヘッドショットの判定は今まで（ET2.60含め）ですとアンチラグ機能が有効ではありませんでしたが、etproではバッチリ効いています。これは出会い頭の銃撃戦からいきなりヘッドショットが入ることでも感じているのではないでしょうか。これはetproを評価すべき点だと思います。

イメージ

興味がある方はソースコードのg_combat.c 840行以降のIsHeadShot関数を見てください。この関数はダメージを与える関数からヘッドに当たったかどうかを見るために参照されますが、ヘッドの位置参照にアンチラグ機能は働いていません。ところがダメージを与える関数を呼び出す当たり判定の関数ではアンチラグ機能が有効です。つまり当たり判定関数ではヘッドに当たっていても、プレイヤーが動いていた場合ダメージ処理ではヘッドショットが無効になる可能性が高いのです。以上余談でした。

それにしても、クライアントでfpsが大幅に下がる原因がよくわかりません。時折HUDの表示が乱れる・消えることも不可解です。まあ3.1.13はまだベータですから今後処理が改良された安定バージョンがリリースされるはずです。これに期待しましょう。

投稿者 ikanatto : 12:56 PM | コメント (0)