ポケモンWiki没資料庫

GBビルで捕獲したポケモンの個体値

author: 2P (ポケモンWiki)

ポケスタシリーズでGBビルを使用して捕獲したポケモンの個体値に関する雑な調査

検証の背景

初代ポケモンでは個体値は攻撃/防御/すばやさ/特殊が各4bitずつ, 計16bitの値である. しかし疑似乱数の挙動の解析により, 非シンボルエンカウントの野生ポケモンの個体値は0からFFFFまでのすべての値が出るわけではなく, 取り得る値はかなり限られているとされている.

また, ポケモンリーグ'99においてポケモンの開発関係者が最高個体値は出ないと語ったとの証言もある.

一方で, "最高個体値が出た" という話: 第四回蒼い月オフ用育成日記 (魔人島)

これよく見たらドードーGB使ってるな。
ドードー/ドードリオGB使用時のみFFFFが出現しうる…という可能性を思いついたが、もしそうなら調整困難じゃないか?
(もしかして既出?)

— ASPEAR (@AspearBerry05) September 8, 2018

ポケスタシリーズのGBエミュレーションの精度が微妙で実機と挙動が違うというのは一考に値する説である. 軽く調査してみることにした.

使用ソフト

調査方法

ざっくり説明すると

ただし, 私の持ってたn64実機はスクラップ化して動かないので, エミュを使います.

...ポケスタシリーズのGBエミュレーション精度が怪しいって話なのにそれを別エミュ上で動かしてどーするという話なんですが. そういうわけで, この検証の結果にあんまり厳密性はありません.

使用エミュ

64エミュ
Project64 2.3.2.202 + angrylion's RDP with OpenGL 1.5
GBエミュ (個体値確認)
BGB 1.5.7

結果

処理落ち (PCスペック不足?) のため倍速化しても体感0.8倍速ぐらいな感じで, フラストレーションをためつつ1ばんどうろ(エンカウント率25)で4匹つかまえまえたところで, 一旦レポートして終了. 気が短い

4匹とも個体値リストにはない個体値でした.

まとめ

仮説: クロック周期がズレているのでは?

赤緑青の個体値生成はだいたいこんな感じ (ピカ版はちょっとちがう):

c2 = 0
c3 = c4 = 1
dDiv3 ∈ {45,46,47}
dDiv4 ∈ {1,2,3}
0 <= hRandomAdd1 < エンカウント率
0 <= rDiv2 <= 255
rDiv3 = (rDiv2 + dDiv3)%256
rDiv4 = (rDiv3 + dDiv4)%256

hRandomAdd2 = (hRandomAdd1 + rDiv2 + c2)%256
hRandomAdd3 = (hRandomAdd2 + rDiv3 + c3)%256
hRandomAdd4 = (hRandomAdd3 + rDiv4 + c4)%256
個体値 = (hRandomAdd4 << 8) + hRandomAdd3
(攻防 = hRandomAdd4, 速特 = hRandomAdd3)

rDiv(FF04h)は256クロック毎に1加算される8bitの値. 第一世代の乱数では前回生成した乱数+ rDiv + carryを新しい乱数とする.

ポケモンとのエンカウント時には乱数を複数個連続で生成するが, この生成間隔(dDiv3, dDiv4) がだいたい一定なので, 個体値が偏る.

速特 = hRandomAdd1 + 2*rDiv2 + 定数
攻防 = hRandomAdd1 + 3*rDiv2 + 定数

2式よりrDiv2を消去すると
速特 = 2/3 * 攻防 + 1/3 * hRandomAdd1 + 定数

ポケスタのGBビルとGB実機で違う個体値が出る原因は, 生成間隔がズレているためなのではないかと仮説を立てた.

そして, この生成間隔の実機とのズレが一定(定数)であると仮定する. この仮定の下, 個体値表を生成してみた.

なお, 仮定が正しいかどうかここでは検証しない. デバッガなしでは辛すぎる.

0 <= x <= 255
0 <= y <= 255
dDiv3 ∈ {x,x+1,x+2}
dDiv4 ∈ {y,y+1,y+2}

仮定が正しければ, ポケスタ金銀のGBビルで出現する個体値表は, これで生成される65536通りの表の中のどれかである.

次にpj64でドードーGB使用中にトキワの森(エンカウント率8)にて適当にマスターボールを50回ほど投げ, 捕獲したポケモンの個体値すべてを含むテーブルのみに絞り込む. 1536通りが残った.

最後に, これらのテーブルのすべてに共通して含まれる個体値を抽出. テーブルのうちどれか1つは本物の個体値表であるという仮定なのだから, 積集合は本物の個体値表の部分集合になるはず. 生成された個体値表を以下に掲載する.

個体値FFFFがエンカウント率25と30で出現するとの結果を得た.

絞り込みに使用した個体はすべて倍速で捕獲したものだが, GBビル等速(体感0.3倍速)で捕獲したものの個体値も調べたところ上記のリストの範囲内であった. 倍速化の有無は個体値に影響しないと見て良いかも.

同様にピカチュウ版もGBビルで起動し, 倍速でポケモン屋敷(エンカウント率10)の入口付近を右往左往して捕獲した個体を元に個体値表を生成した. PCスペック不足のため4倍速モードだと処理落ちで逆に遅くなるという知見が得られた.

繰り返しになるが, あくまでもこれは部分集合であり, 不完全なリストである. ここに無い個体値でも出現しないとは限らない.

まとめ2

以上の仮定が正しいなら, ポケスタ金銀のGBビルで個体値FFFFはエンカウント率25または30で出現しうる.