ログインした船の緊急ワープをバンピングにより妨害する行為は仕様の不正利用

公式フォーラム : 開発者スレッド 『エクスプロイト (※仕様の不正利用) : 緊急ワープを阻害する目的でのバンピング (Exploit: Bumping in order to prevent E-Warp)』 #1 より

(2013.11.29 10:47 by CCP Dolan)


宇宙空間にログインした船に対しバンピングを行うことで、その船を操作もできずログアウトもできずの 「黄泉」 に封じ込めてしまう行為は、今後は仕様の不正利用 (※つまり規約違反) であるとみなされる。

宇宙空間にログインして緊急ワープに入るまでの船は、モジュールを起動することも、ワープをキャンセルすることもできずで、その間の自衛手段がまったくないため、いかなる方法によってもワープに入るのを阻害されるべきではない。この間にバンピングを受けた船はそれに対し手の施しようがないわけだけど、これは仕様の意図するところではないんだ。

付記 :
  • 通常のゲームプレイで交戦フラグの立った船は、宇宙空間でのログアウト時に船が一定時間宇宙空間に残るようになるわけだけど、今回の警告はそのような船に対しての行為には当てはまらない。なので、宇宙空間でログアウトするのであれば可能な限り 「安全にログオフ」 機能を使うことをお勧めするよ。
  • 今回の警告が当てはまるのは特定の条件に当てはまる船に対して行った場合にのみ、つまり宇宙空間にログイン 「してきた」 船に対して行った場合にのみだ。

よろしくね。

(※捕捉 : バブルによってログイン時の緊急ワープを妨害するのは問題ないようです)




同スレ #34 より

(2013.11.29 11:49 CCP Dolan)


《Chribba》
その状況におかれたとして、どうやって被害を証明すればいいの?

こちらでログを見ればすぐにわかるよ。報告さえしてくれれば、確認作業はすべてログまかせだ (もちろん、動画やスクリーンショットがあるにこしたことはないけどね)。




同スレ #69 より

(2013.11.29 15:23 by CCP Masterplan)


《Tara Read》
緊急ワープの仕様や、POS からのログイン/ログオフの仕様を、将来的に改善する予定はあるの? 結局そうするのが一番実際的で、理にかなっていると思うんだけど。

《Vincent Athena》
この仕様そのものを排除しないの? たとえば、始めからトップスピードで宇宙空間にログインするようにするとかさ。停止状態でログインするのではなくて。

うん、この問題を解決し、かつ他に抜け道ができてしまわないような方策をこちらでも検討している。おそらく提案してもらったものと似たようなかたちになるんじゃないかな。この問題は僕らの案件リストにものっているし、具体的な案ができしだい CSM に打診することになると思うよ。

(※追記 : Rubicon 1.1 にて、宇宙空間にログインした船は、あらかじめワープに入った状態で宇宙空間にポップするよう変更されました)

[Rubicon 1.0] 高速ライト/ヘビーミサイルランチャー v2 - 03

([Rubicon 1.0] 高速ライト/ヘビーミサイルランチャー v2 - 02 からの続き)

公式フォーラム : 開発者スレッド 『高速系ミサイルランチャー v2 ([Rubicon] Rapid Missile Launchers - v2)』 #2255 より

(2013.11.27 11:54 by CCP Rise)


僕が反対意見にとりあっていないという話がずっとでているけど、それは違うよね。

今回の変更に対する懸念に対してはまず https://forums.eveonline.com/default.aspx?g=posts&m=3851753#post3851753 (※本ブログには未収) でレスした。さらに多くのフィードバックに目を通したあと、https://forums.eveonline.com/default.aspx?g=posts&m=3864075#post3864075 (※本ブログではこちら前半) で再びレスしている。そして最後に、「不満の量」 にもかかわらず 「なぜ僕がそれにもとづいて判断をしなかったのか」 について、https://forums.eveonline.com/default.aspx?g=posts&m=3864922#post3864922 (※本ブログではこちら後半) ではっきりとコメントした。

前のページのフィードバックを見てごらんよ。僕に対するただの悪口でしかないものや、ECM について語っているものがあるなかで、実際に高速ライトミサイルランチャーを使っているというプレイヤーの投稿が 1件、そしてその 1件は新しい高速ライトミサイルランチャーを楽しんでいると書いている。これはここまでのスレッドの様子をまさに体現していると思うし、僕が修正案に大きな変更を加えなかった理由でもある。

Rubicon のリリース以降、さまざまな手段を通して今回の影響を見守っているよ。モジュールの使用数、CSM とのディスカッション、実際に使用しているプレイヤーとの会話、そして僕自身 Tranquility で使ってみることなどでね。一部 (特にこのスレッド) では、今回の変更全体に対する不満が高いようだけど、その大部分は 「リロードに 40秒もかかって楽しくない」 を繰り返すだけで内容がまったくない。

引き続き状況を注視していくつもりだし、変更が必要だとの確信が得られれば躊躇なく変更を加えるよ。

追記 : 今回の変更は、リリースサイクルの終盤になってから加えたわけだけど、こういうことは今後ないようにしたい。今回の場合、リリース直後に変更を加えることがわかっているのに初期案のまま高速ヘビーミサイルランチャーを実装してしまうよりも、意図通りの仕様で実装したうえで、バランスが必ずしも良くなかった場合は調整する余裕もある、というかたちにしたほうが望ましいと思ったんだ。高速ライトミサイルランチャーについても同様の考え方をとった。今でもこれは正しい判断だったと思っているけど、今後はこのようなかたちをとらなくても済むようにしていきたいと思っているよ。




同スレ #2283 より

(2013.11.27 17:18 by CCP Rise)


ここ何ページかにあがっていたポイントについてコメントしたいと思う。すべてに答えられてはいないかもしれないけど、その場合はごめんね。

相変わらず僕がフィードバックを無視しているという件 : こう感じられるのは、おそらくこちらが実際に何か行動しないかぎり、みんなとしては取り合ってもらっている実感がないからだと思う。確かに、多くの人が今回の変更に反対していたにもかかわらず、僕は新案に変更を加えなかったけど、これが 「無視」 にあたると僕は思わない。意見には全力で耳を傾けてきたし、決して無視なんてしていないけど、ある程度のフィードバックがあるにもかかわらず、なんらそれにもとづいた対応がとられなければ不満にも感じられるだろうし、無視されているように感じられるのもわかる。僕としてはそうではないんだと言い続けるしかないし、また、フィードバックを重視していること、そして一見そうでないように見えるときでさえ、フィードバックは僕らの判断に影響を与えているよと言い続けるしかないかな。

高速ヘビーは新しい仕様にし、高速ライトは従来のままにしておくという案について : この案はもちろん検討したんだけど、両者間の一貫性のなさがどうしても受け入れられなかった。両者とも似た名前を持っていることをはじめ、さまざまな部分 (フィッティング要件、1段階小さい弾薬を使用する点、その他) でパターンが共通しているにもかかわらず、実際の仕様がまったく異なるというのはどうにも望ましくないように思えた。ただ、高速ライトにこの仕様を適用するのは、まず高速ヘビーで仕様の実際を確かめてからでもよかったのでは、という点については僕も認めるよ。

数値データについて : 指摘された点のうち、一部にはまったくそのとおりだというものもある。こちらでの数値データの取り扱いについて何点かコメントを :
  1. 以下に限るわけではないけど、さまざまな分野のデータをチェックしている : モジュールの起動回数、モジュールによるダメージ量、売買数、このモジュールを使うと思われる船との関係で設定した指標、等だ。
  2. データはすごく有用だけど、それでわかることには限界があるのも確かだ。データからすべてが読み取れるとは思っていない。EVE のような複雑なゲームであればなおさらね。でも、だからと言ってデータが有用な情報源でないということにもならない。フォーラムのフィードバックについてだって、結局同じことが言えるわけだしね。
  3. すでに述べてくれた人もいたけど、すごく重要なことで僕らが常に念頭においているのは、モジュールの普及率を見定めるにあたっては、モジュールの強さやプレイヤーの好き嫌いだけでない、さまざまな 「きっかけ」 を考慮する必要があるということだ。Tranquility サーバーでは (※内部?) テストサーバーと違い、スキルトレーニング、入手難度、外見、そして諸々の事情による開発パターンなどが関わっており、それらがデータに大きな影響を与えるため、得られるデータもテストサーバーでの値とは大きく異なってくる。テストサーバーではどの船も同じ外見をしているし、誰もがスキルポイント MAX だからね。それは忘れないようにしているよ。

最後に、モジュールの 「楽しさ」 という要素は、客観的に評価するのはすごく難しいんだということは言わせてほしい。さまざまな方面で 「楽しんで」 もらっている証拠が現れ始めているし、僕としては 「無難で普通なものを実装して済ますよりも、今までとは異なることをしたい」、という点については考えは変わっていない。おそらくみんな疑っていることだろうから、どんな 「証拠」 があるのか述べると、直接的には僕自身の体験や、ここに投稿してくれたプレイヤーの体験、もしくは僕と直接言葉を交わしたプレイヤーの体験によるものだ。また、間接的には他のゲームに似たようなメカニクスが存在していることが挙げられる。例えば War Thunder の飛行機はひとつ残らずこの仕様なわけだけど、基本的にはみんなそれをすごく楽しんでいる。引き続き可能な限り多くの情報を得たいと思っているし、もし使ってみて 「楽しくない」 (これは「良くない」 とはまた別だ。良くないのであればリロード 30秒にするとか、装填数を増やすとかして調整できるからね) のであれば、ここに投稿して知らせてほしい。




同スレ #2286 より

(2013.11.27 17:41 by CCP Rise)


でも現状では、フリゲート虐殺特化システムと、肉弾戦ヘビーアサルトミサイル以外で (もちろんウェブは必要)、まともに使えるミサイルがないんだよ。

もしさまざまな問題の元凶がこれだというのであれば、高速ランチャーとはまったく別の問題として取り組む必要がある。本当にそうなのかという点については何とも言えないけど、ヘビーミサイルを十分に見直して、現状で問題ないのかどうかを Rubicon 1.1 までに確かめておきたいと思う。もし調整が必要だということになればそれを行うまでのことで、ヘビーミサイルの問題を高速ライトミサイルランチャーで解決してはいけないんだ。

([Rubicon 1.0] 高速ライト/ヘビーミサイルランチャー v2 - 04 に続く)

Evelopedia : タイムダイレーション (遅延)

Evelopedia : タイムダイレーション (遅延 ; Time Dilation)



EVE においてラグは、基本的には多数のプレイヤーが宇宙空間で複雑な行動をとることによってひきおこされる。プレイヤーの一人一人が何らかの行動をするたびに、その行動をリアルタイムで処理していく必要があるが、負荷の高い状況ではハードウェアがプレイヤーの行動を処理しきれず、ラグが起こる。こういった現象は艦隊戦において最も顕著だ。

件のハードウェアは 「ノード」 と呼ばれ、ノード上ではゲーム内のリージョンが処理されるが、リージョン内の活動量が比較的小さければ、ひとつのノード上で複数のリージョンを処理可能だ。しかし、リージョン内の活動量が上昇するにつれて各ノードは処理性能の限界に近づき、最終的にはリアルタイムでの処理ができなくなる状態にまで達する。

ここで力を発揮するのがタイムダイレーションだ。ノードの負荷が高くなると、タイムダイレーションにより EVE 内の時間経過が引き延ばされる。安定して処理できるレベルにまでノード上のすべての星系の時間を遅くすることで、ハードウェアは処理を余裕をもって行えるようになるのだ。プレイヤーはこれを、たとえば 「タイムダイレーション 50%」 であれば、「ゲームがいつもの 50% のスピードで動く」 というかたちで経験することになる。タイムダイレーションの状態はアイコンによってクライアント上に示される。


クライアント上での表示

ノードの負荷が (プレイヤーの活動量増加により) 一定量に達すると、そのノード上で動いているすべての星系にその時点でのタイムダイレーション量を示すアイコンが表示される。スクリーンショットに映ったアイコンは黄色のものだ。

ざっくりと指針を示すと :

アイコンの色 時間経過
Green 若干遅くなる
Yellow 通常の半分
Red 低速

開発者ブログ : PLEX for GOOD

開発者ブログ : PLEX for GOOD

(※すでに JP コミュニティー向けの記事 (どちらかというとプレス向けの趣ですが) が発表されていますが、私も途中まで元記事を訳してあったのでこちらでも掲載することにしました。若干内容が異なる部分もあります。)

(2013.11.20 17:16 by CCP Falcon)


2013年 11月 8日、フィリピンは Haiyan (Yolanda) 台風により未曾有の被害を受けました。

自然の猛威とその被害の大きさに世界が心を痛めるなか、CCP としても状況を注視してまいりました。フィリピンでは依然として危機的な状況が続いています。現地には世界何百もの地域から救いの手が伸びつつあるとはいえ、支援が十分過ぎるということはないはずです。

4,000 もの人命が失われ、12,000 もの人々が怪我を負い、行方不明者は 1,100人以上、300万人の方々が家を失うという今回の事態に際し、みなさまの多くから 『再び "PLEX for GOOD (PLEX で慈善活動を)" を開催してほしい』 との暖かい声をいただけたことは、私たちとしても喜びに堪えません。

みなさまの声にお応えしたいと思います。



本日 2013年 11月 20日から、2013年 12月 7日 の土曜日 (UTC) までのあいだ、CCP ではプレイヤーのみなさまから本キャンペーンへの寄付を受けつけます。この期間に寄付していただいた PLEX 1枚につき、CCP hf. では 15米ドルをアイスランド赤十字のフィリピンでの活動に寄付いたします。

本キャンペーンへの寄付は以下の手順により行っていただけます :

  • キャラクター "CCP PLEX for GOOD" を 1枚以上の PLEX の受取人とした、アイテム交換契約を作成してください。有効期限は 14日に設定してください。
  • 契約は作成後、24時間以内に受理されます。通常は受理までにそれほど時間はかかりません。

受取人が間違いなく上記キャラクターであるか、そしてそのキャラクターの所属コーポが "C C P Corporation" あるかを確認し、誤ったキャラクターに PLEX を渡してしまうことのないよう十分にご注意ください。間違ったキャラクターに渡してしまった PLEX については、CCP としてはその返却を保証することができません。(※さすがと言うべきか、"PLEX for GOOD" などというキャラクターがしっかり存在していますのでご注意ください)

これまでの 3年間、何度か PLEX for GOOD キャンペーンを開催してまいりましたが、そのたびごとにこのキャンペーンの趣旨にコミュニティーのみなさまよりご支援、激励をいただけたこと、そして本活動への積極的なご参加をいただけたことにつき、CCP ではみなさまに深く感謝しております。"PLEX for GOOD" キャンペーンを通じてこれまでに 100,000米ドル以上を、ハイチ、日本、パキスタン、そしてアメリカの、自然災害被害者への救済活動に寄付させていただくことができました。2004年のインド洋地震およびそれに続く津波にて初めて寄付を募って以来、EVE コミュニティーによる慈善活動への寄付金は総額で 150,000米ドル以上にのぼっています。

今回 CCP ではみなさまへの感謝の気持ちを込め、寄せていただいた PLEX ごとに、ゲーム内アイテム 「Sisters of EVE Food Relief “'Humanitarian' T-shirt YC115”」 を 2着 (男女用各 1着ずつ) 差し上げることにいたしました。これを着用することでキャンペーンへのご賛同を表明していただければ幸いです。T シャツのデザインは目下制作中で、12月 10日の火曜日に配布されます。



今回のキャンペーンがこれまででも最も大きな成功を収めたものとなるよう、サプライズを用意しているのですが、これについては 11月 27日水曜日に、CCP Bro による開発者ブログ上で詳細が発表される予定です。

このプログラムの仕組みについてさらに知りたい方はこちらの FAQ をご覧ください。PLEX についてはこちらをご覧ください。なお、"PLEX for GOOD" キャンペーンへのご寄付は控除の対象となりませんのでご注意ください。アイスランド赤十字 (Raudi Krossinn a Islandi) についてはウェブサイト http://www.raudikrossinn.is/ をご覧になるか、Efstaleiti 9, 103 Reykjavik、電話番号 +354 570 4000 central@redcross.is まで直接お問い合わせください。

-The EVE Community Team

"PLEX for GOOD" キャンペーンに乗じた詐欺についてですが、いかなるかたちのものであれ、 CCP としては道徳的観点からそのような行為を容認することはできません。該当行為に対しては即時かつ厳正に対処していく用意がありますのでご注意ください。

Women's 'Humanitarian' T-shirt YC 115

開発者側からの問題提起 : 信用取引スキルとマーケット UI は今のままでよいのか?

公式フォーラム : 開発者スレッド 『フィードバック求む : 「信用取引」 スキルと 「正確な」 マーケット UI (Feedback Request - Margin trading and accurate market UI)』 #1 より

(2013.11.21 17:02 by CCP Rise)


僕のチームがこの問題に取り組み始めてからずいぶん経つ。もともとは Rubicon でこれらの仕様に変更を加える予定でいたんだけど、CSM との長時間のディスカッションの結果、その時点での解決策には納得がいかないということになった。というわけで、こちらにもディスカッションの場を開いてみんなから意見を募りたい。

何のことだかわからないという人のために捕捉しておくね :

「信用取引」 スキルをトレーニングすることで、買い注文を出す際に代金の 「全額」 ではなく 「一部」 のみをエスクローに預託するだけでよくなるんだけど、「信用取引詐欺」 はこの仕様を巧みに利用したものだ。買い注文を出した側がウォレット内を空にしておくと、誰かがその注文にモノを売ろうとしても取引が失敗、消滅してしまう。つまり実質的に 「ニセの買い注文が出せるようになる」 ということだね。被害者は、信用取引にもとづいてたてられたニセの買い注文に目をつけ、そこにモノを流し込めるとふんで、(※買い注文を出したプレイヤーがあらかじめ売りに出しておいた) ぼったくり価格の商品を買い込んだはいいが、儲けるどころか、行き場のないアイテムの山に埋もれて終わる、というのが通常のパターンだ。

CSM と話し合いをしていく中で問題となった点がもうひとつあったので、それについてもはっきりさせておきたい :

今回の問題提起は 「詐欺」 そのものについてではないし、他のプレイヤーをハメること (これはきわめて 「EVE らしい」 ことだし、僕らとしてはまったく問題視していない) の是非についてでもない。今回僕らが問題だと感じているのは、「クライアントが (マーケット UI をとおして) 実質的にプレイヤーに嘘をついている」 という点なんだ。実際には成立し得ない注文を表示することでね。

当初僕らが CSM に提示した解決案は、「注文を成立させるのに必要な ISK がウォレット内になければ、注文はキャンセルされる」 というものだった。複数の注文をたてたいけど、そのすべてをカバーするだけの ISK が手元にない、というプレイヤーであれば、この方法なら引き続き信用取引スキルの恩恵にあずかれることになる。例えば、手元に 700万しかなくても、ソーラックスに 500万、別件でラプチャーにも 500万で買い注文をだせる、ただし、手持ちが 500万を切るとどちらの注文もキャンセルされてしまう、といったかたちだ。

この解決案にはいくつか難点がある。なかでも、手持ちの ISK を最大限に投資したいと考えている未来の投資家に不要に圧力をかけてしまうという点で非常に問題だ。ほかにも、実際にはとうていカバーしきれない注文である一方で、それが満たされることも実質的にはありえないような注文をたてることによる高度な駆け引き、的な遊び方を阻害することにもなる。賛成にしろ反対にしろ、この解決案について意見があれば聞かせてほしい。

第 2 の解決案 (これは CSM とのディスカッションの過程であがったものだ) は、「買い注文が信用取引によるものかどうかを、マークによってマーケット UI 上で識別できるようにする」 というものだ。この場合、買い注文をだす際に信用取引を用いるかどうかを決めてもらうことになる。それにもとづき注文にマーク (色とかチェックボックスとかね) がつくので、その注文がリスクを伴うものなのかどうかが売り手にわかるようになる。でも、これにもやっぱり難点がいくつかある。正当な注文をあやしくみせてしまったり、インターフェースがわかりづらくなったり、注文を出す際のクリック数が増えてしまったり、初心者が詐欺に遭うのを恐れて安い注文を避けてしまうことで余計な出費をさせてしまったり、等だ。

これは複雑な問題だし、僕らとしても慎重に扱いたいと思っているけど、みんなのほうでアイデアや意見があればぜひとも聞かせてほしい。

どうもありがとう!

(※関連記事 ('13/07/09): 「信用取引詐欺」 (Margin Trading scam))
(※関連記事 ('13/07/24): CCP Falcon、「信用取引詐欺」 に引っかかった初心者を諭す)