プロローグ−ありし日のシンリュウ−

デラハーンさんのSS版シンリュウの実験によると、 基本HP・能力値変化の最大値は32767 (=215-1)のようです(それを越えるとマイナスになる)。
そこで、PS版では基本HPの上限は100なので、アヌビアスのHPが 5の倍数であることを考えると最大値は32865 ではないか、という予測をしました。答えだけ知りたければ 最後にジャンプ！

限界を越えてアヌビアスのHPを上げるには？

まずはコンピュータの内部で整数がどのように扱われているか、 ということを説明します。

符合つき整数と2の補数

10進絶対値2の補数
+701110111
+601100110
+501010101
+401000100
+300110011
+200100010
+100010001
+000000000
-010000000
-110011111
-210101110
-310111101
-411001100
-511011011
-611101010
-711111001
-8----1000
符合つき整数を2進数で表す場合にはどうしたら良いか？

最も単純な方法は、符合ビット＋絶対値(再上位のビットが0なら+、 1なら-とし、残りは普通の2進数と同じ)という形にすること なのですが、そうすると0が +0,-0 の2種類に分かれたりして不便です。

そこで昔の人は2の補数表示という 方法を考えました。
n bitの2進整数Nの2の補数は 2n-N で表されます。

具体的には、4bit符合つき整数(0000〜1111)を10進数に直すと、 2の補数表示だった場合は

「0,1,2,…,7,-8,-7,…,-1」

になります。(左図参照)

こうすると、

簡単に符号部と絶対値に変換できる
符合ビットを他の数値ビットと同列に扱える
0が一意に決まる
扱える数が一つ増える
など、いろいろ便利なことが多いので、 多くのコンピュータで2の補数が使われています。
オーバーフローとは、計算結果が、その数が 表現できる領域を越えることです。 4bitの場合は、計算結果が -8〜7 を越えるとオーバー フローです。例えば 7+1=-8 (0111+0001=1000) という一見奇妙なことが起きるわけです。また、符号ビット以上の 数は切り捨てられるおかげで、-1+1=0 (1111+0001=0000) という計算が行なえるわけです。

これらはコンピュータアーキテクチャに関する本に詳しいので、 詳細を知りたければそちらを探して下さい。
参考書:コンピュータアーキテクチャ(オーム社) 、馬場 敬信 著
＃…むぅ、研究者などやっているせいでついこういう書き方に なってしまう。

符合なし整数(C言語なら unsigned int)の場合は微妙に扱いが異なるん ですが、符合ビットもまとめて扱えるのが2の補数表示の良いところなので、 やってることはほとんど変わらないはず。 (乗除算のあたりはきちんと理解しているわけではないので御容赦願います)

この場合は扱える数が 0〜2n-1(4bitなら 7,1Byteなら 255, 2Byteなら 65535,3Byteなら 16777215)になり、オーバーフローした場合は、 はみ出した桁は切り捨てられます(例えば65535(2Byte)+1の場合は0)。
ゲーマーなら、1,2,3Byteのオーダーくらいは基礎知識として 知っておいたほうが良いと思います。良く出てくるので。

(詳細)65536は2進数では1 00000000 00000000 なのですが、変数の大きさが2Byte(16bit)の場合、それ以上の桁(この場合 17桁目の1)は切り捨てられるので、00000000 00000000 (つまり0)になっちゃいます。

普通はオーバーフローしないようにプログラムを書くのですが、 常人ではオーバーフローさせられないような変数を扱う場合は 省略してしまう場合が多いようです。

(余談)DQ3(FC版)では、パラメータが最高値(255)になると それ以上上がらなくなるのですが、能力上昇の種を使うと更に 上がって0になるという(!)現象がおきました。デバッグ甘いぞ。

カルドセプトの話に戻ります。

つまり、どんどんHPをあげていけば、マイナスになってもそのうち プラスになるということです。

シンリュウ(SS版)の場合は、おそらく護符の数自体が65536に達すると 0に戻ると思われるので、多分やっても無駄でしょう。(護符数のために 2Byte以上の領域を確保しているとはどうしても思えないので)

(追加報告 8/16)デラハーンさんがSS版でいくつまで護符を買えるか 実験しました。ご苦労さまです。以下、その報告です。 

SS版でゴフはどこまで買えるか、をやったので
一応報告します。
ゴフの総数ではなく、それぞれのエリアの属性の
ゴフが33000になった所でマイナスに反転しました。厳密には32768だと
思われます。総魔力もマイナスになって曲が元に戻りました。
この状態でシンリュウ、グレイスを使ってみましたところ、マイナスにはならずに
0でした。さらに33000程、買い足してみたらプラスに戻ったものの
持っているはずの65536ゴフ（たぶん）が消えてしまいました。
0に戻ったという方がいいのかな。0の裏に６万あるはずなのに、
いくら売ろうとしても売れません。（あっ枯渇していたらどうなったんだろう？）

その後、33000持っているゴフが２種類あって、総魔力がマイナスの状態のまま
城に着いたら目標達成しておわっちゃいました。
ゴフにも符号があったのが不思議です。
ここまで。

ですがアヌビアスの場合、死者数は 2Byte(16bit) で処理されているくさいので、プラス→マイナス→プラス という循環を見られるかも知れません。

もしそうなら、
32767 (10進数)= 01111111 11111111 (2進数)で
45875 ×5 (10進数)= 11 01111111 11111111 (2進数)なので
死者数を 45895にあげることで HPが32867になるのではないかと…

禁断のPAR

先日(10/10)デラハーンさんの協力を得て新たな実験を行いました。 PAR(プロアクションリプレイ)を用いて死者数を直接変えた結果です。

死者数ダメージ基本ST能力値変化
45885マイナス5032767
45875327675032717
6553327655032715

どうやら、総攻撃力の値が 32767を超えた場合もダメージは反転するようです。 ゆえに、理論的な最大ダメージは
32767 (死者数45875のときのアヌビアス+チェンジソルブ)
である、という結論に達しました。

報酬のカードの比率について

さて、ここでもうひとつ考察してみましょう。

報酬のうち、N,S,Rが占める割合は決まっています。 さて、この報酬の内訳を決めているのは何でしょうか？

一見この割合は無茶苦茶に見えますが、もちろんその裏には計算式があります。 (対応テーブルを作るような美しくないプログラムなど存在に値しません。) そして、これは大体一定の割合で増えているように見えます。

私はその割合を N:S:R=3:2:1 で決め打ちし、四捨五入という仮定の元で 計算したところ良い一致を見たので、 四捨五入を実行する関数f(y)を定義し、 内訳の計算式をf(ax) (xは報酬の数、aは適当な係数)と仮定します。
私だったら f(y)←(int)(y+0.5) とするけどそれは置いといて…

コンピュータにとって、割り算は若干時間がかかるのと、 整数がらみの罠があるので私はあまり使いません。 もしプログラマが同じことを考えたとしたら、分数ではなく小数の積、 しかもできるだけ桁数を削って計算させようとしたとしても不思議ではありません。

私の予想としては 「1/6を0.15で、1/3を0.3で代用させている」 んじゃないか？ という気がします。微妙に違う可能性はありますけどね。 報酬が1000枚くらいあれば詳細に検討できるんですが(無理無理)。 この仮説が正しいなら、カードの比率は正確には

N:S:R=55%:30%:15%

となります。

カード集め、画廊集め

 これが正しいとして、いったい何枚集めればコンプリートが 達成できるか、を計算してみました。ただし、カードと画廊の出現は 完全にランダムと仮定します。

その前に、画廊を集めるのにいったい何回勝てば良いのか、 考えてみましょう。集める絵は 29枚。1回目は必ずNew画廊が 増えますが、2枚目は1回目の絵が出ないことが条件(確率 28/29)。 同様に3枚目は 27/29。つまり平均的に

29/29+29/28+29/27+…+29/1≒115回

かかります。 同様にして、コンプリート時の枚数の平均値は、 Rカード:219枚、S:321枚、N:286枚となります。 上記の割合からコンプしたときのカードの総数の平均を計算すると、 それぞれ
219/0.15≒1460枚, 321/0.30≒1070枚, 286/0.55≒520枚
となります。やはり一番効いてくるのはRカードで、コンプ するためにはおよそ1400枚程度のカードを集めることになります。 ただし、実際には「同じカードは同時に複数出現しない」 と「3勝 Newカード」システムの存在によって、これよりも若干少ない 値になります。皆さんも、総数1300枚くらいでコンプしませんでしたか？
・おまけ

以前デラハーンさんと話をしたときに、『「後手」は相手に先制を与える 能力ではないか？』という話題が上ったことがあります。 確かに後手のグラフィックを見ると、「ドンッ」っていう先制時の アクションが相手側に付与されています。
しかし、先制+後手の組合わせを防御側にさせてもやはり防御側が 先制するので、この説はちょっと弱いです。
というわけで、個人的にはプログラマが「後手のアクションを 『作る余裕がなかった/思いつかなかった/やめて作業を減らしたかった』 ので相手に先制アクションをさせることでごまかした」 説をとってみます。(いぢわる？)

戻る