ポケモンスリープ攻略・検証Wiki

編集相談板 / 50

1414 コメント
views
1 フォロー
50
名前なし 2023/12/06 (水) 13:42:12 6370b@44bea

[[不具合]]の+1バグの項ですが、悪用非推奨と言いつつ、具体的な悪用方法まで説明していませんかね

通報 ...
  • 51

    コピペしてきただけなので、文章の内容は元のままです。確かに括弧の中身は要らないかもしれません。
    ちなみに同様にグリッチが疑われる行為(仕様として明言されていないこと)として
    ・絶食厳選(エナジー0状態だと完全に出現ポケモンが固定される)
    ・いつ育運用(きのみとくいのポケモンをあえて所持数上限を維持しておくことで食材確率を0にする)
    ・食材バッグ満杯運用(食材バッグを満杯にしておけば、食材確率を0にできる)
    ・メインスキルのクールタイムスキップ法(スキルが発動したポケモンを手持ちと入れ替えて発動回数を増やせる?未確定)
    ・睡眠リサーチ結果待機法(睡眠リサーチ結果画面で長時間放置しておけば、その間はげんきが減ることなくお手伝いできる)
    など様々あって、検証の上では参照できた方が良いものの、悪用が広まってゲーム開発に支障をきたす可能性のある事象は多くありますが、線引きはどこに設定する感じなのでしょうか。
    絶食厳選とかはすでにかなり広まってしまっているものの、明らかにゲーム設計として望ましいものではないようにも思います。

    52

    個人的な見解としては、対戦ゲームでも協力ゲームでもなく、仮にグリッチをしていたとしても他者のゲームプレイに影響するわけではないので、そこまで神経質に扱う必要はないかなと思っています。
    ただ、ゲーム開発者側に何らかの不利益を与える可能性はあり得るので、管理人の定めたルール通り「不具合のページにおいておいて、検証をする人が参照できるけど、そうじゃない人には目に付かない位置に書く」という決定に異論はないです。

  • 53
    名前なし 2023/12/06 (水) 14:27:21 271f2@ea9ef >> 50

    ここでいくら議論したって開発者じゃないんだからどれが望ましい望ましくないなんて分かるはずないので、検証に支障が出るなら説明する、その説明を見て悪用するかどうかは個人の良心に委ねるしかないのでは?
    あくまでwikiとしては必要だから載せているだけで、悪用方法を広めるために掲載しているのではないという姿勢でいればいいと思う。

    104
    名前なし 2023/12/08 (金) 13:46:58 e4267@45130 >> 53

    バグ/グリッチ関連の記述について。
    "攻略・検証wiki"として、記述は避けられない情報だと考えます。検証にも有益です。
    他方、既に指摘されている通りバグと仕様の線引が難しい点が問題です。

    また「ゲームバランスを崩しかねない」「悪用は推奨しない」などの注釈は、
    実質的には「これを使えばゲームバランスを崩せる」「悪用できる」と暗に示しているも同義だと考えます。
    実質的なグリッチ情報のタグ付けとして利用されてしまうことも想定され、個別の注釈は却って逆効果という見方です。

    また、「絶食厳選は注釈が不要」「プラス1バグは注釈が必要」など、統一した判断基準を設定できない事例が今後も続くことも予想されます。

    以上の内容を踏まえて、

    • グリッチ悪用を推奨しない
    • 無用な編集合戦を防止する
    • 情報ごとに注釈の有無で議論する余地を無くす

    上記3点を目的として、バグ/グリッチ系の関連情報については
    不具合ページにおいて、状況再現方法についての簡単な記載のみに留め、個別の注釈等も付けない」ことを提案します。

    プラス1バグを編集例とすると、
    ***プラス1バグ
    ポケモンの所持数が満杯になり、いつのまに育成へと移行した際、お手伝い回数が1回分多くカウントされるという現象のこと。
    (例えば、お手伝い3回分の時間だけいつのまに育成をした場合、いつのまに育成で獲得したエナジー量のポップを表示すると4回分のお手伝いをした際の獲得エナジー量が表示され、実際に獲得される。)

    このような形が想定されます。
    注釈に関しては不具合ページの最上部に「不具合の積極的な悪用は推奨しない」との文言を一文添えるだけに留める程度が落とし所だと考えます。

    105
    k 2023/12/08 (金) 14:15:59 修正 389d7@08738 >> 53

    とするとつまり、「いつ育運用」についてのページ作成の是非や既存の「絶食厳選」のページの扱いはどうなりますか?
    また、まさにグリッチとなりそうな「メインスキルのクールタイムの検証」は公の目標が「クールタイムをスキップするグリッチの発見」なわけですが、検証の中止等の措置が必要だったりしますか?

    そもそも、バグか仕様かの線引きが困難であるということは「エナジー0での睡眠リサーチでは出現ポケモンが固定される」「いつのまに育成に移行した際にお手伝い回数が1回加算される」などの動作が不具合なのかどうかさえ分からないということです。
    最も明確な不具合かどうかの判別方法としては「公式が発表している情報かどうか」がありますが、ポケモンというゲーム自体、細かい仕様の説明を一切行わないという姿勢がみられるため、本wikiに記載可能な情報が極端に制限されてしまいます。
    かといって、それ以外の客観的な基準を設けるには、「不具合/仕様を管理人などの権限のある者が一通り仕分けしておく」といった方法以外にないと思います。これも一考の余地はあると思いますが、非常に多岐にわたる(そもそも仕様であると明言されているものが圧倒的に少ない)ため、かかる労力が甚大すぎる気がします。
    提案されているような『不具合ページへの統括』という措置だと、「あれも不具合」「これも不具合」という魔女狩りに発展しかねないと思います。

    107
    名前なし 2023/12/08 (金) 15:18:54 271f2@ea9ef >> 53

    注釈を書く時点で特別な情報だと分かってしまうのでどんなバグっぽい挙動も一旦仕様だと認めてどこでも普通に記述していい派です。
    +1バグを利用したいつ育ページをもし作るなら、普通にいつ育について書いた後に
    「なお、いつのまに育成中はアプリを開くたびにおてつだい回数が1回増える仕様があるため高頻度でアプリを開くと効率を高めることができる」
    のようにさらっと書いていいと思っています

    108
    名前なし 2023/12/08 (金) 15:27:10 1edb5@45130 >> 53

    >> 105
    個別の質問が複数あるため、順を追って見解を述べます。
    主軸としてあるのは「大きく効率を伸ばすグリッチ的要素を孕みながら、開発側が想定していると示す根拠がないゲームプレイ情報を不具合ページで扱う」という考えです。
    この際、グリッチと示す特別な注釈は付けない方がよいと考えます。

    まず、対象的な事例である「いつ育運用」と「プラス1バグ」について述べます。

    1. 「いつ育運用」については個別ページ作成に問題がないものと考えます。
      大きく効率を伸ばすグリッチ的要素を持つが開発側が想定していると示す根拠があるためです。
      "いつのまに育成できのみだけしか持ってこない"ことはゲーム内マニュアルに記載があることから、"きのみだけを持ってくるように限定できる"ことは開発側の想定の範囲内と考えられます。

    2. 「プラス1バグ」については個別ページ作成を避けるべきと考えます。
      大きく効率を伸ばすグリッチ的要素を持ち、開発側が想定していると示す根拠に欠けるためです。
      "いつのまに育成が1回多く扱われる"ことはゲーム内マニュアル、及び公式X等を含めて言及がないことから、開発の想定の範囲内である根拠に欠けると考えられます。

    2つの事例を踏まえ、質問があったその他の事例にも見解を述べます。

    1. 「絶食厳選」については個別ページ作成に問題がないものと考えます。
      "エナジーが貯まるほどより多くのポケモンに出会える"ことはゲーム内マニュアルに記載があることから、"エナジーを貯めないほど少ないポケモンに限定できる"ことは想定の範囲内と考えられます。

    2. 「メインスキルのクールタイムの検証」については、公の目標は「グリッチの発見」ではなく、検証の一覧ページにあるように「メインスキル発動後、一定時間の間スキル発動の抽選が行われないという現象について」の解明だと考えます。
      ついては、「メインスキルのクールタイムの検証」は個別ページ内での議論・記述を行うものと考えます。
      しかし、検証によって得られた"クールタイムをスキップする具体的な手順"は、公式からのアナウンスがない限りグリッチ的要素として不具合ページにて記述するものと考えます。

    3. 「wikiに記載可能な情報が極端に制限されてしまう」という点については、指摘は当たらないと考えます。
      当ゲーム公式は、バグに関して積極的に情報開示を行う姿勢を取っており(例:鍋の一部上限を超えた際に料理が不可能になるバグの計算式開示)細かな仕様説明を行っていると評価できます。

      • 検証については個別ページで行う
      • グリッチ的要素を孕み、開発側が想定していると示す根拠がないゲームプレイ情報は不具合ページに状況再現方法を簡素に記載する
        このような基準を用いる限り、記載できなくなる情報は
      • グリッチ的要素を含むゲームプレイの、悪用に関する具体的な実用例
        だけに留まるため、"攻略・検証wiki"の運営には問題がないものと考えます。
    4. 「あれも不具合」「これも不具合」という魔女狩りに発展しかねない
      前述の通り、不具合ページへの移行が議論される情報は

      • グリッチ的要素を孕み、開発側が想定していると示す根拠がない具体的なゲームプレイ情報
      • 進行不可能になるなど、バグとしての緊急度が高い
        この2項に留まると考えています。
        ついては、指摘されるような状況には発展しないものと考えます。
    110
    k 2023/12/08 (金) 16:29:31 修正 61403@08738 >> 53

    「大きく効率を伸ばすグリッチ的要素を孕みながら、開発側が想定していると示す根拠がないゲームプレイ情報を不具合ページで扱う」という指針であっても根本的には問題が解決しないと考えます。

    1. 「開発側が想定していると示す根拠」について
      そもそも開発側が何を想定し、どのような設計を行なっているのかを単なるユーザーである我々の側からは判別が難しいです。
      例えば「食材バッグが満杯になってから4回分のお手伝いでは食材を持ってくるが、5回目以降ではきのみしか持ってこない」というのが仕様なのかバグなのかは判断しかねます。
      プラス1バグと称される現象についても、以下のように考えることで想定している挙動であると見なすことも可能です。
      ・「所持数の空きが残り1つの状態で食材を3つ持ってくると2つ分は消滅する」というように所持数に入りきらなかった分は消滅するという現象があるため、このお手伝いをカウントするために+1回分多くのお手伝いを行なったことにしている。
      ゲーム開発側から直接説明されていない事柄については、結局のところ人によって判断が分かれる可能性を排除できません。
      また、絶食厳選について、エナジー0で出現するポケモンが固定されているというのは想定した仕様であったとしても、「チームの切り替えを利用して一切エナジーを与えずに一週間過ごす」というのは開発側の想定しているプレイではないと考えられます。なので、私としてはこの指針で判断すれば「掲載は不適切」と考えています。これは、まさに人によって判断が分かれる好例でしょう。

    2. 『「wikiに記載可能な情報が極端に制限されてしまう」という点については、指摘は当たらない』という点について
      少なくともクールタイムの検証については、「検証する価値がない」という理由で一旦終了しており、「クールタイムをスキップできるかもしれない」という新たな価値が発見されたことで再開した経緯があります。
      そのため、グリッチに繋がるような検証や記載を一切排除するということであれば、この検証は当wikiにおいては不適切な検証として中止せざるを得ないかと思います。
      上述の通り、「運営が何を想定し、何を想定していないのか、我々には判断ができない」わけですから、編集に際して大きな制限がかかったり、「魔女狩り」のような問題が発生することは避けられないと考えます。

    3. 記載を禁止/排除する理由がない
      「バグか仕様か判別の付きにくい内容は一律で一切記載しない」という方針ではないのであれば、運営によって直接禁止されている行為あるいは倫理的・社会的に問題のある内容ではない限り、記載を禁止/排除する理由はないかと思います。
      まずは何より、「なぜ記載を禁止/排除するのか」という点を明確にしていただく必要があると思います。

    112
    名前なし 2023/12/08 (金) 17:09:15 1edb5@45130 >> 53

    太字>> 110
    再度、個別の質問に対して回答します。

    1. >>例えば「食材バッグが満杯になってから4回分のお手伝いでは食材を持ってくるが、5回目以降ではきのみしか持ってこない」というのが仕様なのかバグなのかは判断しかねます。
      そのような仕様を示す記述が公式に存在しないため、前述の基準に照らせば仕様ではなく不具合となります。

    2. >>「所持数の空きが残り1つの状態で食材を3つ持ってくると2つ分は消滅する」というように所持数に入りきらなかった分は消滅するという現象があるため、このお手伝いをカウントするために+1回分多くのお手伝いを行なったことにしている。
      そのような仕様を示す記述が公式に存在しないため、前述の基準に照らせば仕様ではなく不具合となります。

    3. >>ゲーム開発側から直接説明されていない事柄については、結局のところ人によって判断が分かれる可能性を排除できません。
      「ゲーム開発側から直接説明されていない」という客観的事実がある限り、人によって判断が分かれる可能性はありません。

    4. >>「チームの切り替えを利用して一切エナジーを与えずに一週間過ごす」というのは開発側の想定しているプレイではないと考えられます。
      チーム切り替えによってエナジーが初期化される仕様については公式の記載がなく、私の判断基準としても不具合に当たる事例であり、当該部分の個別ページにおける掲載は不適切だと考えます。

    5. >>グリッチに繋がるような検証や記載を一切排除するということであれば、
      グリッチに繋がるような検証や記載を一切排除することは全く主張していません。
      むしろ、あらゆる検証は"攻略・検証wiki"として歓迎されるべきものと考えています。
      排すべきは検証の結果得られたグリッチを悪用する具体的な手順を共有することであり、検証の結果得られた内容の簡潔な記載を排除することを主張するものではありません。
      また、当然ながら検証そのものについても排除する必要は全くありません。

    6. >>「なぜ記載を禁止/排除するのか」
      前述の通り、記載を禁止/排除する主張や意図はどこにもありません。
      グリッチを悪用する具体的手順や、それが悪用可能なグリッチであることを示す注釈は避けるべきであるというのが、一貫した主張です。

    114
    Spect 2023/12/08 (金) 17:32:33 >> 53

    >> 100について差し戻しました


    ここで明言しておきますが、バグ・グリッジについての記述が全面禁止になったとしても、バグについて記述することは即時の編集ブロック措置の対象とはしません
    勿論削除されてもなおしつこく編集し続けるようでしたら荒らし行為として規制するでしょうが、それはバグと他の情報で基準は変わりません
    バグについての検証をすること・検証していたらバグが判明したこと・方針決定前にバグについて検証していたこと、これらいずれに対しても規制対象にいたしません

    117

    『悪用』の基準は何でしょうか?
    通常、対戦ゲーム等でグリッチと呼ばれるバグを利用したプレイが禁止/推奨されないことに関する最たる理由は『他人に迷惑をかける点』であると考えています。

    ただ、このポケモンスリープというゲームにおいて、個人のゲームプレイが他者に干渉することはほとんどありません(ソーシャルリサーチによる飴のやりとりのみだと思います)。この観点で言えば、『悪用』と呼べるような行為は存在しないように思います。

    「いつのまに育成に移行した際にお手伝い回数が1回増える」という現象自体は8月にはすでに確認され、運営にも報告されていることです。その当時からすでに一部のユーザーはこの現象を利用してゲームをプレイしているわけですが、特段の運営からの動きはありません。これは『当ゲーム公式は、バグに関して積極的に情報開示を行う姿勢を取っており(例:鍋の一部上限を超えた際に料理が不可能になるバグの計算式開示)細かな仕様説明を行っていると評価できる』とするならば、バグではなく仕様として判断しても差し支えないと考えられるのではないでしょうか。

    管理人さんの方で、措置の方針を示していただけることは大変ありがたいです。
    ただ、削除される前提でページの作成や編集をしようとは思えないのも実情かと思います。

    絶食厳選のページに関しても、肝心の具体的な手順の記載を削除してしまうのであれば、ページの存在価値を失わせるに十分な大きな措置だと思います。

    個人的な見解とはなりますが、『運営によって直接禁止されている行為あるいは倫理的・社会的に問題のある内容ではない限り、記載/編集は自由』とし、『個々の不適切と判断される記載については一旦削除した上で、必要であれば編集相談板等の場で議論する』という方針が混乱や軋轢を生まない落としどころかなと思います。

    118
    名前なし 2023/12/08 (金) 18:32:32 5d7ea@45130 >> 53

    >> 117
    >>この観点で言えば、『悪用』と呼べるような行為は存在しないように思います。
    >>バグではなく仕様として判断しても差し支えないと考えられるのではないでしょうか。

    これを踏まえ、プラス1バグに注釈を付ける理由は全くないと言えそうです。
    『悪用』と呼べるような行為は存在しないため、「悪用は推奨しない」という文言は必要ないでしょう。

    また、そもそもバグではなく仕様と判断することになるため、やはり悪用するしない以前のただのゲーム仕様ということになりそうです。

    120
    Spect 2023/12/08 (金) 22:03:26 >> 53

    わかりました
    バグか仕様かいちいち私が基準を付けることはできませんし、直接禁止と明言されている行為を除いて、全ての現象を記載してよいということにしましょう
    ただし、Wikiに記載されているバグと思しき現象を実際に行って不具合を起こしたとしても、私や当Wikiは責任を持てないということは明記しておきます

  • 113
    名前なし 2023/12/08 (金) 17:23:00 6370b@3a8aa >> 50

    判断が必要くらいなら、全面OKか全面NGにして、
    全面OKの場合どこまで記載するか議論したほうがいい思いますが、いかがでしょうか?

  • 116
    名前なし 2023/12/08 (金) 17:59:58 efefc@fc7b3 >> 50

    不具合ページに載せる載せないの議論もこのように毎回個別にやるのでしょうか。
    「バグと仕様の線引が難しい」とありましたが、
    ここまでの議論を読んで改めて、「グリッチ的要素」「悪用」にあたるものとそうでないものとの切り分けも難しいし判断が割れているように感じられます。
    あらゆる仕様を説明するスタイルでもない以上、公表する仕様と公表してない仕様はあるだろうし
    公表してない仕様=運営が想定していないだろう事態 と推定してしまうのも、
    それで恣意的にメニュー等への記載を制限するのもおかしい気がします。
    「公式から明確にバグだと示されたもの」「サーバー等に悪影響を与える可能性の高いもの」以外、推奨も禁止もなし、と言うのが分かりやすいのではないのかと思います。

    119

    今ここでこれだけ議論が白熱している最大の理由は「バグの悪用」を推奨するような記載はNGという編集方針を設けようとした際に、その線引きが難しいのではないか?というものになります。
    例えば、上述した『運営によって直接禁止されている行為あるいは倫理的・社会的に問題のある内容ではない限り、記載/編集は自由』という編集方針に変えれば、基本的には議論の必要なく画一的な判断ができるはずです。