ここでいくら議論したって開発者じゃないんだからどれが望ましい望ましくないなんて分かるはずないので、検証に支障が出るなら説明する、その説明を見て悪用するかどうかは個人の良心に委ねるしかないのでは?
あくまでwikiとしては必要だから載せているだけで、悪用方法を広めるために掲載しているのではないという姿勢でいればいいと思う。
通報 ...
ここでいくら議論したって開発者じゃないんだからどれが望ましい望ましくないなんて分かるはずないので、検証に支障が出るなら説明する、その説明を見て悪用するかどうかは個人の良心に委ねるしかないのでは?
あくまでwikiとしては必要だから載せているだけで、悪用方法を広めるために掲載しているのではないという姿勢でいればいいと思う。
同意見です。
説明できる人が常にいるとは限らないのが実情で、せっかく取ってもらったデータが意味を成さなくなる可能性もあるのが懸念点ですね。
こういうバグや仕様の悪用とみられるものは、不具合のページに記載するというルールで統一するとして、絶食厳選のページの扱いはどうしましょう...
不具合とは少し違うかもしれないですが、現在のページは削除で不具合ページに簡単な説明だけ残す形がいいかと思います。
そうなるんですかね...?
例えばほかに、『食材バッグ満杯時やいつのまに育成時に食材を持ってこなくなる』というのは、どう考えるべきなのでしょうか。ゲーム内に記述が無いですがバグではなく仕様と断定できるのでしょうか?記載削除または移転するべきでしょうか?
今まさに進められているメインスキルのクールタイムについての検証も新たなグリッチ方法の発見のために行われているようなものなので、中止するべきだったりするんでしょうか?
意外と仕様とバグの線引きは簡単じゃない気がします。
「FL10以降は一枠目のサブスキルが金枠確定」ということでさえ隠し要素として長らく公式からの情報が無かった(まさかバグではないだろうと考えられていたものの、バグではないと断定できるわけでもない)ですし、未だに「FL40以降は二枠目まで金枠確定」ということもバグの可能性を否定できないです。
ポケモンというシリーズ自体、種族値や個体値、努力値といった隠し要素を一切公言せず、それでいて黙認しているような姿勢だったりするので、「これはバグ」「これは仕様」みたいに分かりやすく選別する方法が無いように思います。
『利用規約 第17条 禁止行為』において明確に禁止されていて抵触しそうなこととしては
⑨本サービスを運営するサーバーに、誤作動、バグ、その他の不具合を発生させ得る行為。
⑭他社が上述の各行為を行う際にこれを補助し、又は、容易にするような行為。
の2点が挙げられますね。
上述したいずれのバグ/グリッチと考えられる操作はいずれも「サーバーに誤作動やバグなどの不具合を発生させ得る」とは考えにくいとは思います。(いずれも「特殊な仕様」ではあるものの、通常の動作の範疇で収まってはいる)
長々と申し訳ないのですが、自分の意見をまとめてみました。
現時点の編集方針だと、「絶食厳選」と「いつ育運用」の扱いに差があるのは二重規範になっていると思います。
専用の記事まで存在する「絶食厳選」がありだとするなら、「いつ育運用」などの記事があっても良いはずで、どちらもダメだとするなら、両方とも削除あるいは移転するべきでしょう。
プラス1バグも「すごく重篤な事態を引き起こす」みたいに扱われていますが、実際にはこまめにアプリを開く必要があって非常に手間がかかる上、食材もメインスキルも発動しない点からそこまで大きな問題は起きないと考えています。
そのため、個人的な意見ですが、グリッチと捉えられかねない絶食厳選、いつ育運用、クールタイムスキップ法などの検証であっても、そういった旨の注意書きを残したうえで記事が有ったりしても良いのかなと思います。
もちろん、通常の動作では起こりえないこと(例:「6匹以上のチームを編成する」、「睡眠リサーチを1日に3回以上行う」など)や通常のゲームプレイ時には行わない操作によって起きる挙動(例:「睡眠リサーチ中に意図的に通信を切断する」、「意図的にサーバーへの通信量を上げて負荷をかける」、「タイムゾーン切り替えで時間を巻き戻す」など)は利用規約で禁止されている「サーバーに、誤作動、バグ、その他の不具合を発生させ得る行為」として明確に書くべきではないと思いますので、何らかのルールは必要でしょう。
みなさんの意見も聞いてみたいです。よろしくお願いします。
kさんの意見に同意です。通常のゲームプレイで起こり得ない状況であるか?サーバーに負担をかけるような操作か?に視点を絞るのが良いと思います。絶食厳選、いつ育運用、+1バグ、食材バッグの上限運用、クールタイムスキップ(仮)についてはバグの悪用と言うのは大袈裟で、あくまで小ネタというのが私の認識です。
運営がお知らせを出すまでは基本的に黙認でいいと思う(明らかに鯖に負荷をかけるようなものはもちろんダメ)
各編集者は書きたくなったら書く、wiki全体の方針はページを作ったりどこかに記載したりするのを推奨も規制もしない
そういう意味だと、いつ育運用のページは作ってみたいんですよね。
メリットもデメリットも明確にあって、どんなポケモンが適しているとか、どんな状況で行うのが良いのかとか考察してみる価値があって面白そうなので。絶食厳選でのゴクリンの評価のように新しい発見もあるかもしれません。
ただ、プラス1バグについては、雑談板とか検証ページとかで検閲している人がいて勝手に投稿が削除されてしまっていたので、よほど何か記載させたくない理由を持っている人が居るようには思います。(絶食厳選については検閲が働いていないのが謎ですが...)
そういった人の意見が聞けるならぜひ聞きたいです。
私も一旦は現状の編集方針に同意している手前、勝手にページを作ったりしようとは思わないですが、逆に今の編集方針に従うと絶食厳選についてあれほど詳細に書かれたページがMenu Barにさえ載っているのは問題があるようにも思います。
もし“各編集者は書きたくなったら書く、wiki全体の方針はページを作ったりどこかに記載したりするのを推奨も規制もしない”というのを採用するなら、『バグ・グリッチは存在せず、公式にお知らせがあるまでは原則すべての挙動を仕様として扱う。』ことになるけど別にそれでいいんじゃないかな
だってその判断をするのは運営しかできないし、特に問題は無いように思う
もちろん明らかに規約違反なものはアウトだけど微妙なもの(+1バグとか)は認める方針にすれば勝手に検閲してる人もできなくなるでしょう(もしくは荒らしとして通報)
すみません、今の所議論の方向性としてはバググリッジの記述は認めて良いという意見が主流という認識で間違いないのでしょうか
もしそうであれば、不具合ページにてプラス1バグを削除した編集は議論不十分ということで差し戻します
①バグと仕様の線引きを絶食厳選やプラス1バグなどを含めて逐一行い、包括的に定めたうえでバグ利用に関する記述は一切しない
②利用規約で禁止されているような「サーバーに問題を引き起こすような挙動」を除いてバグと仕様の線引きをせず、必要に応じて注意書きを添えたうえで記載を許す。
大きくこの2つの方向性があるかなというところです。
商業的な攻略サイトに比べたときのこのwikiの良さは「自由さ」にあると思います。
すでにこのサイトは絶食厳選のページが500PV/日を超えていて、他では扱いにくい情報の受け皿的な役割を担っているようにも思います。
なので、できれば②のような編集方針が良いかなと思いますし、今のところ異論は出ていないのかなという印象です。
バグ/グリッチ関連の記述について。
"攻略・検証wiki"として、記述は避けられない情報だと考えます。検証にも有益です。
他方、既に指摘されている通りバグと仕様の線引が難しい点が問題です。
また「ゲームバランスを崩しかねない」「悪用は推奨しない」などの注釈は、
実質的には「これを使えばゲームバランスを崩せる」「悪用できる」と暗に示しているも同義だと考えます。
実質的なグリッチ情報のタグ付けとして利用されてしまうことも想定され、個別の注釈は却って逆効果という見方です。
また、「絶食厳選は注釈が不要」「プラス1バグは注釈が必要」など、統一した判断基準を設定できない事例が今後も続くことも予想されます。
以上の内容を踏まえて、
上記3点を目的として、バグ/グリッチ系の関連情報については
「不具合ページにおいて、状況再現方法についての簡単な記載のみに留め、個別の注釈等も付けない」ことを提案します。
プラス1バグを編集例とすると、
***プラス1バグ
ポケモンの所持数が満杯になり、いつのまに育成へと移行した際、お手伝い回数が1回分多くカウントされるという現象のこと。
(例えば、お手伝い3回分の時間だけいつのまに育成をした場合、いつのまに育成で獲得したエナジー量のポップを表示すると4回分のお手伝いをした際の獲得エナジー量が表示され、実際に獲得される。)
このような形が想定されます。
注釈に関しては不具合ページの最上部に「不具合の積極的な悪用は推奨しない」との文言を一文添えるだけに留める程度が落とし所だと考えます。
とするとつまり、「いつ育運用」についてのページ作成の是非や既存の「絶食厳選」のページの扱いはどうなりますか?
また、まさにグリッチとなりそうな「メインスキルのクールタイムの検証」は公の目標が「クールタイムをスキップするグリッチの発見」なわけですが、検証の中止等の措置が必要だったりしますか?
そもそも、バグか仕様かの線引きが困難であるということは「エナジー0での睡眠リサーチでは出現ポケモンが固定される」「いつのまに育成に移行した際にお手伝い回数が1回加算される」などの動作が不具合なのかどうかさえ分からないということです。
最も明確な不具合かどうかの判別方法としては「公式が発表している情報かどうか」がありますが、ポケモンというゲーム自体、細かい仕様の説明を一切行わないという姿勢がみられるため、本wikiに記載可能な情報が極端に制限されてしまいます。
かといって、それ以外の客観的な基準を設けるには、「不具合/仕様を管理人などの権限のある者が一通り仕分けしておく」といった方法以外にないと思います。これも一考の余地はあると思いますが、非常に多岐にわたる(そもそも仕様であると明言されているものが圧倒的に少ない)ため、かかる労力が甚大すぎる気がします。
提案されているような『不具合ページへの統括』という措置だと、「あれも不具合」「これも不具合」という魔女狩りに発展しかねないと思います。
注釈を書く時点で特別な情報だと分かってしまうのでどんなバグっぽい挙動も一旦仕様だと認めてどこでも普通に記述していい派です。
+1バグを利用したいつ育ページをもし作るなら、普通にいつ育について書いた後に
「なお、いつのまに育成中はアプリを開くたびにおてつだい回数が1回増える仕様があるため高頻度でアプリを開くと効率を高めることができる」
のようにさらっと書いていいと思っています
>> 105
個別の質問が複数あるため、順を追って見解を述べます。
主軸としてあるのは「大きく効率を伸ばすグリッチ的要素を孕みながら、開発側が想定していると示す根拠がないゲームプレイ情報を不具合ページで扱う」という考えです。
この際、グリッチと示す特別な注釈は付けない方がよいと考えます。
まず、対象的な事例である「いつ育運用」と「プラス1バグ」について述べます。
「いつ育運用」については個別ページ作成に問題がないものと考えます。
大きく効率を伸ばすグリッチ的要素を持つが、開発側が想定していると示す根拠があるためです。
"いつのまに育成できのみだけしか持ってこない"ことはゲーム内マニュアルに記載があることから、"きのみだけを持ってくるように限定できる"ことは開発側の想定の範囲内と考えられます。
「プラス1バグ」については個別ページ作成を避けるべきと考えます。
大きく効率を伸ばすグリッチ的要素を持ち、開発側が想定していると示す根拠に欠けるためです。
"いつのまに育成が1回多く扱われる"ことはゲーム内マニュアル、及び公式X等を含めて言及がないことから、開発の想定の範囲内である根拠に欠けると考えられます。
2つの事例を踏まえ、質問があったその他の事例にも見解を述べます。
「絶食厳選」については個別ページ作成に問題がないものと考えます。
"エナジーが貯まるほどより多くのポケモンに出会える"ことはゲーム内マニュアルに記載があることから、"エナジーを貯めないほど少ないポケモンに限定できる"ことは想定の範囲内と考えられます。
「メインスキルのクールタイムの検証」については、公の目標は「グリッチの発見」ではなく、検証の一覧ページにあるように「メインスキル発動後、一定時間の間スキル発動の抽選が行われないという現象について」の解明だと考えます。
ついては、「メインスキルのクールタイムの検証」は個別ページ内での議論・記述を行うものと考えます。
しかし、検証によって得られた"クールタイムをスキップする具体的な手順"は、公式からのアナウンスがない限りグリッチ的要素として不具合ページにて記述するものと考えます。
「wikiに記載可能な情報が極端に制限されてしまう」という点については、指摘は当たらないと考えます。
当ゲーム公式は、バグに関して積極的に情報開示を行う姿勢を取っており(例:鍋の一部上限を超えた際に料理が不可能になるバグの計算式開示)細かな仕様説明を行っていると評価できます。
このような基準を用いる限り、記載できなくなる情報は
だけに留まるため、"攻略・検証wiki"の運営には問題がないものと考えます。
「あれも不具合」「これも不具合」という魔女狩りに発展しかねない
前述の通り、不具合ページへの移行が議論される情報は
この2項に留まると考えています。
ついては、指摘されるような状況には発展しないものと考えます。
「大きく効率を伸ばすグリッチ的要素を孕みながら、開発側が想定していると示す根拠がないゲームプレイ情報を不具合ページで扱う」という指針であっても根本的には問題が解決しないと考えます。
「開発側が想定していると示す根拠」について
そもそも開発側が何を想定し、どのような設計を行なっているのかを単なるユーザーである我々の側からは判別が難しいです。
例えば「食材バッグが満杯になってから4回分のお手伝いでは食材を持ってくるが、5回目以降ではきのみしか持ってこない」というのが仕様なのかバグなのかは判断しかねます。
プラス1バグと称される現象についても、以下のように考えることで想定している挙動であると見なすことも可能です。
・「所持数の空きが残り1つの状態で食材を3つ持ってくると2つ分は消滅する」というように所持数に入りきらなかった分は消滅するという現象があるため、このお手伝いをカウントするために+1回分多くのお手伝いを行なったことにしている。
ゲーム開発側から直接説明されていない事柄については、結局のところ人によって判断が分かれる可能性を排除できません。
また、絶食厳選について、エナジー0で出現するポケモンが固定されているというのは想定した仕様であったとしても、「チームの切り替えを利用して一切エナジーを与えずに一週間過ごす」というのは開発側の想定しているプレイではないと考えられます。なので、私としてはこの指針で判断すれば「掲載は不適切」と考えています。これは、まさに人によって判断が分かれる好例でしょう。
『「wikiに記載可能な情報が極端に制限されてしまう」という点については、指摘は当たらない』という点について
少なくともクールタイムの検証については、「検証する価値がない」という理由で一旦終了しており、「クールタイムをスキップできるかもしれない」という新たな価値が発見されたことで再開した経緯があります。
そのため、グリッチに繋がるような検証や記載を一切排除するということであれば、この検証は当wikiにおいては不適切な検証として中止せざるを得ないかと思います。
上述の通り、「運営が何を想定し、何を想定していないのか、我々には判断ができない」わけですから、編集に際して大きな制限がかかったり、「魔女狩り」のような問題が発生することは避けられないと考えます。
記載を禁止/排除する理由がない
「バグか仕様か判別の付きにくい内容は一律で一切記載しない」という方針ではないのであれば、運営によって直接禁止されている行為あるいは倫理的・社会的に問題のある内容ではない限り、記載を禁止/排除する理由はないかと思います。
まずは何より、「なぜ記載を禁止/排除するのか」という点を明確にしていただく必要があると思います。
太字>> 110
再度、個別の質問に対して回答します。
>>例えば「食材バッグが満杯になってから4回分のお手伝いでは食材を持ってくるが、5回目以降ではきのみしか持ってこない」というのが仕様なのかバグなのかは判断しかねます。
そのような仕様を示す記述が公式に存在しないため、前述の基準に照らせば仕様ではなく不具合となります。
>>「所持数の空きが残り1つの状態で食材を3つ持ってくると2つ分は消滅する」というように所持数に入りきらなかった分は消滅するという現象があるため、このお手伝いをカウントするために+1回分多くのお手伝いを行なったことにしている。
そのような仕様を示す記述が公式に存在しないため、前述の基準に照らせば仕様ではなく不具合となります。
>>ゲーム開発側から直接説明されていない事柄については、結局のところ人によって判断が分かれる可能性を排除できません。
「ゲーム開発側から直接説明されていない」という客観的事実がある限り、人によって判断が分かれる可能性はありません。
>>「チームの切り替えを利用して一切エナジーを与えずに一週間過ごす」というのは開発側の想定しているプレイではないと考えられます。
チーム切り替えによってエナジーが初期化される仕様については公式の記載がなく、私の判断基準としても不具合に当たる事例であり、当該部分の個別ページにおける掲載は不適切だと考えます。
>>グリッチに繋がるような検証や記載を一切排除するということであれば、
グリッチに繋がるような検証や記載を一切排除することは全く主張していません。
むしろ、あらゆる検証は"攻略・検証wiki"として歓迎されるべきものと考えています。
排すべきは検証の結果得られたグリッチを悪用する具体的な手順を共有することであり、検証の結果得られた内容の簡潔な記載を排除することを主張するものではありません。
また、当然ながら検証そのものについても排除する必要は全くありません。
>>「なぜ記載を禁止/排除するのか」
前述の通り、記載を禁止/排除する主張や意図はどこにもありません。
グリッチを悪用する具体的手順や、それが悪用可能なグリッチであることを示す注釈は避けるべきであるというのが、一貫した主張です。
>> 100について差し戻しました
ここで明言しておきますが、バグ・グリッジについての記述が全面禁止になったとしても、バグについて記述することは即時の編集ブロック措置の対象とはしません
勿論削除されてもなおしつこく編集し続けるようでしたら荒らし行為として規制するでしょうが、それはバグと他の情報で基準は変わりません
バグについての検証をすること・検証していたらバグが判明したこと・方針決定前にバグについて検証していたこと、これらいずれに対しても規制対象にいたしません
『悪用』の基準は何でしょうか?
通常、対戦ゲーム等でグリッチと呼ばれるバグを利用したプレイが禁止/推奨されないことに関する最たる理由は『他人に迷惑をかける点』であると考えています。
ただ、このポケモンスリープというゲームにおいて、個人のゲームプレイが他者に干渉することはほとんどありません(ソーシャルリサーチによる飴のやりとりのみだと思います)。この観点で言えば、『悪用』と呼べるような行為は存在しないように思います。
「いつのまに育成に移行した際にお手伝い回数が1回増える」という現象自体は8月にはすでに確認され、運営にも報告されていることです。その当時からすでに一部のユーザーはこの現象を利用してゲームをプレイしているわけですが、特段の運営からの動きはありません。これは『当ゲーム公式は、バグに関して積極的に情報開示を行う姿勢を取っており(例:鍋の一部上限を超えた際に料理が不可能になるバグの計算式開示)細かな仕様説明を行っていると評価できる』とするならば、バグではなく仕様として判断しても差し支えないと考えられるのではないでしょうか。
管理人さんの方で、措置の方針を示していただけることは大変ありがたいです。
ただ、削除される前提でページの作成や編集をしようとは思えないのも実情かと思います。
絶食厳選のページに関しても、肝心の具体的な手順の記載を削除してしまうのであれば、ページの存在価値を失わせるに十分な大きな措置だと思います。
個人的な見解とはなりますが、『運営によって直接禁止されている行為あるいは倫理的・社会的に問題のある内容ではない限り、記載/編集は自由』とし、『個々の不適切と判断される記載については一旦削除した上で、必要であれば編集相談板等の場で議論する』という方針が混乱や軋轢を生まない落としどころかなと思います。
>> 117
>>この観点で言えば、『悪用』と呼べるような行為は存在しないように思います。
>>バグではなく仕様として判断しても差し支えないと考えられるのではないでしょうか。
これを踏まえ、プラス1バグに注釈を付ける理由は全くないと言えそうです。
『悪用』と呼べるような行為は存在しないため、「悪用は推奨しない」という文言は必要ないでしょう。
また、そもそもバグではなく仕様と判断することになるため、やはり悪用するしない以前のただのゲーム仕様ということになりそうです。
わかりました
バグか仕様かいちいち私が基準を付けることはできませんし、直接禁止と明言されている行為を除いて、全ての現象を記載してよいということにしましょう
ただし、Wikiに記載されているバグと思しき現象を実際に行って不具合を起こしたとしても、私や当Wikiは責任を持てないということは明記しておきます