約 3,189,545 件
https://w.atwiki.jp/goodgames/pages/633.html
TeamControler R0.05.02 先程、ユーザの皆様に御送付させて頂きました。 もし届いていない方がいらっしゃいましたら御連絡下さい。 ( - )
https://w.atwiki.jp/goodgames/pages/1607.html
武器使用統計 4-6 (PDWs編) 新パッチにて武器特性が変更されるようですので、変更前の状況を調べてみました。 Battlefield4では当該カテゴリの全ての武器をアンロックしているプレイヤーのみ集計対象としています。 (詳細はこちら) ■集計前提 集計対象期間 2015/01/01 00時頃から2015/05/25 24時頃まで (ともに日本時間) 集計対象地域 限定せず 該当期間内に戦績の存在する総プレイヤー数 1,174,233件 集計対象(*1)プレイヤー数 115,525名 (*1)該当カテゴリーの全ての武器がアンロック済みとなっており、 該当期間内に2ラウンド以上の戦績が存在するプレイヤー Category Personal Defense Weapons 武器名 該当期間内の総装備時間(時) 該当カテゴリ内の相対的な装備時間の割合 該当期間内の総キル数 集計対象者に占める使用者数 左記集計対象に於ける平均KPM 1 AS-VAL 950 14.751% 81,917 547 1.437 2 CZ-3A1 573 8.905% 49,226 315 1.430 3 JS2 78 1.218% 6,499 82 1.380 4 UMP-45 231 3.600% 17,134 247 1.231 5 MPX 1,318 20.468% 90,381 964 1.143 6 PP-2000 242 3.768% 16,472 132 1.131 7 P90 289 4.499% 17,823 331 1.025 8 MP7 295 4.589% 17,988 251 1.014 9 SR-2 1,250 19.413% 75,053 632 1.000 10 UMP-9 278 4.322% 16,445 252 0.985 11 PDW-R 367 5.703% 21,576 203 0.979 12 CBJ-MS 266 4.138% 15,544 178 0.972 13 MX4 297 4.626% 17,168 227 0.960 比較対象となる過去の統計情報はこちらになります。 ( - )
https://w.atwiki.jp/goodgames/pages/1169.html
Mantle公式発表 ようやくMantle対応Battlefield4がリリースされましたが... Mantle renderer now available in Battlefield 4 残念なことに、いやわかっていたことですが... 件のAPUですら14%の性能向上だそうです。 CF環境で55%性能向上は数字はともかく妥当なところでしょう。 200FPS級の環境が欲しい方は実質的にMantleしか選択肢が無いことになるのかもしれません。 でも、なぜSinglePlayerモードで測定しているのでしょうか... MultiPlayerモードの方がFPSが高くなり無意味な程の性能になるのか? ここは本当に理由不明 多くの方にとって2 64-player multi-playerのケースが一番気になるところでしょう。 AMD FX-8350とIntel 4Coreの性能差を考えると、 多くのユーザが25%の性能向上を享受することは難しいと思いますが、 このケースで使用されているHD7970のように GPUが十分に高性能ならIntel 4Coreでも15～20%程度の性能向上は期待して良さそうです。 「Mantleによる性能向上は1桁%ではない」 AMDさん正直です。 今日は早く帰れれば試してみたいのですが... ( - )
https://w.atwiki.jp/goodgames/pages/807.html
今日はここまで 比較的小型のマップで日本勢が優位なのは予想していましたが、 ConquestDominationの圧勝は全くの予想外でした。 続きは明日公表いたします。 明日は残りのDLCとTDMの予定ですが、これまた予想外の結果が... ( - )
https://w.atwiki.jp/goodgames/pages/1475.html
StatsNow!! Prototype 7 本日は小修正を行いました。 総ラウンド数を追加しました Battlelogではわかりそうでわからないのが総ラウンド数。 勝利と敗北は表示されるものの合計は表示されません。 またQuitも表示されないので総ラウンド数は不明。 Quit率から逆算すれば総ラウンド数が算出出来ますが、少々面倒な計算が必要です。 そこでグラフのToolTipに表示致しました。 ラウンド番号が飛んだ場合は他のゲームモードでプレイしていたり、 規定のラウンド時間に達しなかったなどが原因と考えられます。 また、軽微ですがReal SPM表示の小数点以下桁数を変更致しました。 ゲージ(メーター)表示のバンドを変更しています 相変わらずのセンス不足(?)によりかなり見辛いのですが、 10Percentileごとに色分けしてあります。 ScreenShotにてマウスカーソルを撮影していないため少々分かりづらいのですが、 ゲージの色が付いている部分にマウスカーソルを合わせると、 ゲージの下に10ごとのPercentileが表示されます。 ちなみにRSPM238近辺の濃い橙色部分から、RSPM405近辺の水色部分までの間に 50%のプレイヤーが集中しています。 尚、ゲージのレンジが90Percentile(RSPM504)までしか存在しないため、 90超に該当する方はゲージを突き抜けます。 総平均は362、中央値は370となっています。 モジュール更新のため、本日(2014/08/04)22時より数分間サービスを停止されて頂きます。 ( - )
https://w.atwiki.jp/goodgames/pages/1030.html
雑感 0007 ■続ETA (全くゲームとは無関係かつPCとは少々異なるお話) 一つ前の雑感0006に「ETAって何だ?」と記載しましたが、 15分後に気付きました。 毎日のように見てるじゃん。 scpの残り時間はETA 03 15のように表示されますね。 ファイル転送終了までの時間ですから、これもある意味では到着予定ですね。 ■訂正されたR8 ChangeLog 超意訳を書いていておかしいとは思いましたが、 Battlelogに表示されるLiveScoreboardの記述がまるごと消滅しました。 このChangelogはサーバ側のアップデートモジュールに関するものですが、 LiveScoreboardに必要となるサーバ側機能は標準で搭載されているため、 Battlelog側だけ機能追加を行えば実現可能なはず。 従って、サーバ側のChangeLogに記載されるべきではありません。 しかし、Battlelogを見てもそれらしき表記は追加されて居らず、 ChangeLogからは該当行が消えてしまいました。 ( - )
https://w.atwiki.jp/goodgames/pages/493.html
ランキング その9 以下、ランキング実行委員会さんへの御連絡になりますが、 プレイヤーさんも参考になるかもしれません。 ラウンド開始から終了までの総時間に占める、 各プレイヤーの実プレイ(Death後のRespawn待ち時間を含まない)時間の比を集計しました。 ■集計対象 対象期間 2012/03/05から2012/08/08まで 対象データ StatsNow!!が収集した全ラウンド情報 対象ゲームモード StatsNow!!が収集対象としている全てのゲームモード 除外データ Quitした戦績 総データ戦績数 9,937,213件 ラウンド時間に占めるプレイ時間 戦績数 100% 7,507 95%以上100%未満 217,107 90%以上95%未満 654,137 85%以上90%未満 1,135,429 80%以上85%未満 1,400,275 75%以上80%未満 1,343,507 70%以上75%未満 1,068,618 65%以上70%未満 761,161 60%以上65%未満 526,654 55%以上60%未満 381,538 50%以上55%未満 302,443 45%以上50%未満 255,632 40%以上45%未満 231,745 35%以上40%未満 214,840 30%以上35%未満 205,934 25%以上30%未満 199,418 20%以上25%未満 197,618 15%以上20%未満 197,597 10%以上15%未満 201,033 5%以上10%未満 211,216 0%以上5%未満 223,804 この統計の重要なポイントとして 「途中接続の場合でも計算の分母はラウンド総時間となる」ところにあります。 例えば、総ラウンド時間が10分のラウンドに5分経過後に接続した場合、 接続中の全時間が有効プレイ時間だったとしても50%として計上されます。 また、ラウンド開始と同時に接続し5分間がRespawn待ちだった場合も50%となりますが、 これらは区別出来ません。 これはBF3のスコアリングシステムがプレイヤーの接続開始時刻を記録していないことが原因です。 ( - )
https://w.atwiki.jp/goodgames/pages/647.html
GGC閉鎖 既に御存知の通り、BanList所有数では世界最大(だと思う)のAntiCheatNetworkであるGGC-STREAMが閉鎖されました。 ウチの各サーバもこちらと相互接続されていましたが、 BanListの供給が絶たれたため、推定15,000名のチーターさんが野に放たれました。 昨日(2013/01/01)だけ見てもチーターさんが多かったのは納得出来ます。 早速対策を開始しますが折角の正月休みはこれで無くなりそうです。 ( - )
https://w.atwiki.jp/goodgames/pages/931.html
3930K使います 多数の御要望がありました「足枷にならないCPU」として、 現在StatsNow!!用サーバの1台として稼働しているマシンから Core i7-3930Kを一時的に用途転用致します。 残念ではございますが、 ここのところBF3プレイヤーは大幅減少中となっており、 生成される戦績数も減少しているため問題は無いと判断致しました。 尚、フロントアクセス(Webからの検索やTeamControlerからの戦績照会)に付きましては、 本サーバは無関係ですので影響を受けることはありません。 今週末を逃すとベータテストの期間が終わってしまいますので、 週末には確実に実施する必要がありますね。 (2013/10/10 00 50追記) そもそも論になりますが、本試験の目的は「推奨環境でどの程度楽しめるか」を確認することと、 「推奨環境でダメならどの程度の環境を用意すれば楽しめるか」を確認することにあります。 従って、6CoreクラスのCPUを用意しなくても 「楽しめる」レベルの環境を用意することは可能であることが確認出来ていますが、 GPUの能力が使い切れないような状況で測定するのもいかがなものかと考えから、 やや一般的ではないCPUを投入する次第です。 ( - )
https://w.atwiki.jp/goodgames/pages/877.html
DirectX11.1 いつか来るだろうと思っていたら遂に来た。EAからの抗議のメール。 悪口は程々にしろといつか言われると思っていましたが。 なんと田中美香社長から直々に。 でもアドレスがgmail。 内容はDirectX11.1とBF4の関係に関する御質問でした。(苦笑) 本件、いくつかの誤解があるんじゃないかと思います。 普通ならご本人に直接確認するところですが 社長のgmail宛に変なメール送るわけにもいかないのでここに書いておきます。 まずDirectX11.1高性能説。 答えはここDirect3D 11.1 Features(SDK仕様英語版)に全て書いてありますので読んでみて下さい。 と書いて終わりにしたら怒られるので続行します。 そもそもの話ですがDirectXってなんだか御存知でしょうか? Windows上で3Dグラフィクスを使うためのAPIですか。 なるほど。XBOXは無視ですね。 いいえ、そんな意地悪な質問をしているわけではありません。 XBOXの話は置いておいて、Windowsの話だけに的を絞ると、 DirectXはWin32APIを経由せずに直接各種ハードウェアをアクセスするためのAPI群の「総称」です。 従って、3Dグラフィクスとは関係のないDirectXも色々とあります。 例えば音。DirectAudioやDirectSound。 さらに入力デバイスアクセスはDirectInput。 これはキーボードやマウスだけでなく、ゲームパッドなどの状態も取得出来ます。 他にも色々とあったような気がしますが忘れました。 そして主役のDirect3D。 これのおかげで我々はゲームが楽しめるわけです。 が、これ文字通り3D専用なんですね。なんと2D描画が全く出来ません。 2Dなんて不要ですか。でもそれだとチャットが表示出来ませんね。 チャットの文字が3D風に飛び出してくるのはちょっとイヤですね。 自分のHPや武器の残弾数なども全て単純な2D描画です。 他にも色々とあります。スコアボードは典型的な2Dですし、オプションの各種設定画面も2Dです。 しかし... 恐らくBFBC2あたりまでは一見2Dに見える描画も実は全て3Dになってしました。 これ文章で書くと全然イメージが伝わらないと思います。 かと言って絵を描く時間は無く、サンプルプログラムを用意するほどの話でもないので このまま文字で続行しますが。 3Dゲームとは仮想的な3次元空間の中でプレイすることは誰もが理解していると思います。 従って、幅(X)、高さ(Y)、奥行き(Z)の3軸の概念があります。 この空間に2Dの描画を行うと何が問題になるかと申し上げると たった一言なのですが常に遠近感が表現されてしまうところが大きな問題になります。 単純に考えると遠近感は自分からの距離が問題になるため、 奥行き(Z軸)を中心に考えることになりますが、 仮想的な3D空間に2D描画を行う場合、奥行きはゼロを指定します。 つまり、自分からの距離がゼロの地点に厚さの無いジオメトリ(オブジェクト)を描画すれば2Dになるわけです。 すみません。これはウソです。いいえ、半分ぐらいは事実ですが。 このままだとまた問題が発生します。 奥行きはゼロなので一番手前に2Dの物体が描画されます。 でも仮想的な3D空間では左右(X軸)や上下(Y軸)でも遠近感が発生します。 これ当然ですよね。 自分の目の前(奥行き方向の距離はゼロ)で地上に止っている飛行機と、 同じく奥行き方向の距離はゼロでも上空1000mの戦闘機が同じ大きさで見えたらおかしいじゃないですか。 左右方向も同じことになります。 従って、 {仮想的な3D空間では画面中心の一点以外は全て遠近感が発生する}ことになります。 本当はココに絵を描きたいところですが.... はい、描いてきました。力作です。(苦笑) 絵の中に書いた文言がイマイチでした。 正しくは「Direct3DでScoreBoardを描く場合、このような形が四角く描画される」となります。 理由は前述の通り、画面中央から遠い位置程遠近感の影響で中央方向に縮んで描画されるためですね。 四隅が尖っていますが、四隅が中央から一番遠くに位置するため、中央方向に縮められた結果、四角く描画されます。 Direct3Dってなんて面倒なんでしょう。 でも数年前までは本当にこんなことをしていたんですね。 実際にはFrostbiteなどなどの描画エンジンが自動的に収縮率の計算を行うので、 グラフィックデザイナーは四角くデザインすれば良いのですが、 VRAM上に展開されるタイミングでは本当にこのように変形させた2Dオブジェクトが必要でした。 大昔にはDirectDrawと名付けられた2DAPIも存在していましたが、Direct3Dとの相性の悪さから廃止されてしまいました。 ようやくDirectX10.1になり、Direct2DなるAPIが実装されたことによりこの問題の大部分が解決しました。 普通に四角く描けば四角く画面に描画される。 当たり前のことが当たり前に実現出来る時代がようやく到来しました。 しかしまた暗転。 大ヒット作だったDirectX9に比べ短命だったのがDirectX10。 DirectX10.1がリリースされたものの、あっさりとDirectX11にその座を譲ることになりました。 ここ某Microsoftさんが暴挙に出ました。 なんと、Direct2DはDirectX10.1でしか動かなかった!! 長くなりすぎたので一気に結論に突入します。 他にも質問を頂いているので。(苦笑) Direct2DがDirectX10.1でしか動かないのはある意味事実なのですが、 もう一歩正しく描くとDirectX10.1からしか呼び出せなかったとなります。 そのためDirectX11時代は下記のような方式でDirect2Dを利用していました。 Direct2D - DirectX10.1 - DirectX11 一度DirectX10.1用の画像を生成しその画像をDirectX11のAPIに渡す方式です。 明らかに無駄 結論。 DirectX11.1ではDirect2Dと直接連携して処理を行うことが可能となり、 DirectX10.1が介在するオーパヘッドが無くなるため以前より高性能になります。 でも2D描画って元々描画負荷は微々たるものだし、 DirectX10.1が介在していたことによるオーパヘッドは全てCPU負荷になるため、 GPU処理にはなんら影響を与えないんですよね。 DirectX11.1とBF4と問われているため、BF4への影響になりますが 先日実施した推奨環境に関する微妙な試験でもわかる通り、 ほぼ間違いなくBF4ではGPUネックになることが予想されるため、 相当古いモデルのCPUを使わない限りCPU負荷が下がることがメリットになることは無いんじゃないかと思います。 DirectX11.1ではその他にもいくつか改善点がありますが、 3Dゲームの性能に影響を与えるものはほとんど含まれていません。 ではの御質問へ次へ。 ( - )