ver1.4にて、チェーンボンバーやビンゴバルーンに大きめの修正を加えたものが以下。
ナインビンゴを除いたINは14661000であり、OUTは11730300となり、POは80.01%と、ほぼ設定したPO率そのものとなった。
これより、少なくとも通常ゲームがPO率80%にはなるように設定できることが分かった。
そしてワンダー等の加算がだいたい10付近とみられるので、全体として90%。ラウンドワンが88%とかどこかで書かれていた気がするが、これくらいなら確かに設定可能な数値である。
上のゲーム別のPO率を見ると、どれもPO率80%の6%前後に収まっており、調整機構がよく働いているといえる。
アニマロッタがただ運だけで、設定とか関係ないという極論を展開しだした人物も過去にはいたが、そのようなことは通常否定される。が我はその決定的な証拠は見ていないので絶対に偽であるとは言わないが、ほぼほぼ確実にPOの設定はある。
通常ゲームのPO率設定がいったいどこまで可能か、ということでとりあえず状態値0と100固定でやってみて、どれくらいが設定可能なPO率かを推測したい。
状態値100や0はそこそこ設定が極端になっており、これより状態値を上げたり下げたりすると例えばビンゴバルーンで必ずFREE1個とか必ずFREE3個とかいう固定パターンっぽくなるので、これ以上状態値の幅を広げるのはまずいかと思われる。
ではいったいどれくらいのPO率ならまともに遊べるのか、という話で、上の例で考えることにする。ワンダー全部含めて、トータルのINは16290000、OUTは13977011で全体PO率は85%である。桁が多すぎてしっくりこないので100で割ってみる。すると、
INが162900に対してOUTは139770となる。
1ゲーム30000BETだったのでこれを100で割ると1ゲーム300BETとなり、各種ゲームにはそれぞれ30BETずつすることになる。
手持ちを例えば10000円でラウンドワンの価値に合わせて、4000枚程度を購入したとする。
ここから、300BETを続けた場合、PO率は85%なのでざっくり計算すると1ゲーム当たり45枚メダルを失うことになる。
もし2時間くらい遊べば、1ゲーム平均2分と仮定するとゲーム数は60回なので、2700枚を失うことになる。
まとめると1万円で4000枚購入して、2時間ほど遊べば残り枚数は1300枚。
これがPO率85%というものである。実際にも起こりそうな気がする。
遊べるか遊べないかでいうと、これは遊べない部類に入る。
とりあえず上記の話を次の記事で改めてまとめることにする。PO率とは何であるかを。
ブログ内検索
2019年11月26日火曜日
2019年11月25日月曜日
16-5 チェーンボンバー初期配置設定
PO調整機構ver1.4にて、ビンゴバルーンにそこそこましな配置アルゴリズムを適用。内容は全記事に書かれている。さて、ボンバーのPO率設定の基準は落下してくる爆弾の色にのみ依存する、とされていたが、さすがにこれでは弱そう、ということでチェーンボンバーの初期配置にも手を加えることにした。
チェーンボンバーの初期配置は現行ではランダムに1から54までの数字を2つ選んで、その2つのマス間で番号を入れ替える、というもの。最初には上のほうに1~25が配置されているが、この入れ替えを繰り返せばランダムっぽくなるであろう、という発想。
この現行の配置システムに基づけば、54までの数字の選びを48や42などにすると、上のほうにばかり番号がまばらに分散することになる。
これをつかさどる引数を「上段指数」とする。
この上段指数が大きければ大きいほど、上段に番号が集まりやすい、つまり低設定となる。
上段指数が100の場合は最低設定、ということで上から6段に分散させて、0の場合は普通に分散する、ということにする。下段に集中させるのはちょっといろいろ準備が必要なため。あと指数有効率として、たとえば80と設定すると80%の確率で上段指数に基づいた番号の入れ替えが行われる。でないと下1,2,3段とかにまったく出現しないなどの極端な例が発生してしまう。
上段指数が100で指数有効率が100ならば全部上5段におさまり、
上段指数が100で指数有効率が0ならただのランダム分散、
上段指数が0で指数有効率が0でもランダム分散、
上段指数0で指数有効率100のときもランダム分散。
こうするためには上段指数100で選択範囲が30、上段指数0で選択範囲を54としたいので一次関数の決定とまったく同様に考えて-0.24x+54でよい。
以下の画像は比較用。
上段指数100,指数有効率50
上段指数100,指数有効率80
上段指数100,指数有効率95(笑)
上段指数50,指数有効率80
上段指数50の場合、先述の式によると上限IDは42であるから、上から7段目同士までの入れ替えを90%の確率で行い、それ以外はランダム入れ替え、ということになる。
すると上の画像のように、上7段に集中しやすくなる。
いろいろ実験した結果、とりあえず上段指数100,指数有効率75を最低設定、つまり状態値0として、状態値100では上段指数0,指数有効率0にする予定。つまりランダム配置。
もっとPO率を上げるには、もっと爆弾の色を増やす。下段集中のプログラムはまたやりたかったら作る。
これらの設定を施しPO調整機構ver1.4を立ち上げる。
チェーンボンバーの初期配置は現行ではランダムに1から54までの数字を2つ選んで、その2つのマス間で番号を入れ替える、というもの。最初には上のほうに1~25が配置されているが、この入れ替えを繰り返せばランダムっぽくなるであろう、という発想。
この現行の配置システムに基づけば、54までの数字の選びを48や42などにすると、上のほうにばかり番号がまばらに分散することになる。
これをつかさどる引数を「上段指数」とする。
この上段指数が大きければ大きいほど、上段に番号が集まりやすい、つまり低設定となる。
上段指数が100の場合は最低設定、ということで上から6段に分散させて、0の場合は普通に分散する、ということにする。下段に集中させるのはちょっといろいろ準備が必要なため。あと指数有効率として、たとえば80と設定すると80%の確率で上段指数に基づいた番号の入れ替えが行われる。でないと下1,2,3段とかにまったく出現しないなどの極端な例が発生してしまう。
上段指数が100で指数有効率が100ならば全部上5段におさまり、
上段指数が100で指数有効率が0ならただのランダム分散、
上段指数が0で指数有効率が0でもランダム分散、
上段指数0で指数有効率100のときもランダム分散。
こうするためには上段指数100で選択範囲が30、上段指数0で選択範囲を54としたいので一次関数の決定とまったく同様に考えて-0.24x+54でよい。
以下の画像は比較用。
上段指数100,指数有効率50
上段指数100,指数有効率80
上段指数100,指数有効率95(笑)
上段指数50,指数有効率80
上段指数50の場合、先述の式によると上限IDは42であるから、上から7段目同士までの入れ替えを90%の確率で行い、それ以外はランダム入れ替え、ということになる。
すると上の画像のように、上7段に集中しやすくなる。
いろいろ実験した結果、とりあえず上段指数100,指数有効率75を最低設定、つまり状態値0として、状態値100では上段指数0,指数有効率0にする予定。つまりランダム配置。
もっとPO率を上げるには、もっと爆弾の色を増やす。下段集中のプログラムはまたやりたかったら作る。
これらの設定を施しPO調整機構ver1.4を立ち上げる。
16-4 ビンゴバルーン暫定配置アルゴリズム
なんかアルゴリズムとか仰々しい名前を冠しているが、要するにただ最適化はできないので、それに近い良い配置法をこちらが考えてPCに実行させる、というそれだけのもの。
仮に最適解が求められたとしても、その配置データをまるごとウディタ側に持ってくるのも大変な上、なによりそんなに最適化してしまうとユーザー側の利益になってまうやん、という2つの理由から、そこそこのアルゴリズム、しかも実装しやすい簡単なものでよいだろう、という発想に至ったのである。
まず以下のように配置を優先する。
7個オッズアップ→7個ライン→7個リーチ→5個オッズアップ→5個ライン→…
途中で5個リーチ→4個オッズアップというなんかおかしい流れになるが、まあよしとする。
さてビンゴのパターンは7個ラインが2つ、5個ラインが4つ、4個ラインが8つ、3個ラインが10個ある。まずはn個ラインのm個目のビンゴとして、7つ組を返す関数を定義。
5個など7個に満たなければ、その5個以外は0を返すようにする。
こうしてできあがった、ある意味関数とも呼べるこの作用をfとしておく。
次に、現在までに入った球数から、すべてのmとnの組み合わせに対してfを作用させて、必要な各種ラインまでに何個必要であるのかを2+4+8+10個の変数に格納する。
そして配置可能なFREE個数とを比較して、以下のように処理を行う。
配置可能数<最低必要個数 しょうがないのでそれを採用する。
配置可能数=最低必要個数 この最低個数となるものをもってビンゴとなり処理終了
配置可能数>最低必要個数 最低個数分配置して、繰り返し上記の作業を行う。
もちろんこのやり方が最適解であるはずがないが、それでも現状の単純すぎる配置方法よりはなかなかに良いものになる…と期待している。
これに至っては、ペイアウト率をあらかじめたくさん試行させてだいたいの概算値をつかんでおく予定である。
本当はプログラムは大量計算と実際の演出をするウディタと別に分けたいが、なんか時間がもったいないので全部をウディタでさせることにする。
mathematicaとかはこういうのはifとかwhileやwhichやforなどでかなり楽に記述できる(単純とは言ってない)上に計算能力が非常に高いという利点はあるが…。
このプログラムを考えている間にもPO調整は進行中である。
仮に最適解が求められたとしても、その配置データをまるごとウディタ側に持ってくるのも大変な上、なによりそんなに最適化してしまうとユーザー側の利益になってまうやん、という2つの理由から、そこそこのアルゴリズム、しかも実装しやすい簡単なものでよいだろう、という発想に至ったのである。
まず以下のように配置を優先する。
7個オッズアップ→7個ライン→7個リーチ→5個オッズアップ→5個ライン→…
途中で5個リーチ→4個オッズアップというなんかおかしい流れになるが、まあよしとする。
さてビンゴのパターンは7個ラインが2つ、5個ラインが4つ、4個ラインが8つ、3個ラインが10個ある。まずはn個ラインのm個目のビンゴとして、7つ組を返す関数を定義。
5個など7個に満たなければ、その5個以外は0を返すようにする。
こうしてできあがった、ある意味関数とも呼べるこの作用をfとしておく。
次に、現在までに入った球数から、すべてのmとnの組み合わせに対してfを作用させて、必要な各種ラインまでに何個必要であるのかを2+4+8+10個の変数に格納する。
そして配置可能なFREE個数とを比較して、以下のように処理を行う。
配置可能数<最低必要個数 しょうがないのでそれを採用する。
配置可能数=最低必要個数 この最低個数となるものをもってビンゴとなり処理終了
配置可能数>最低必要個数 最低個数分配置して、繰り返し上記の作業を行う。
もちろんこのやり方が最適解であるはずがないが、それでも現状の単純すぎる配置方法よりはなかなかに良いものになる…と期待している。
これに至っては、ペイアウト率をあらかじめたくさん試行させてだいたいの概算値をつかんでおく予定である。
本当はプログラムは大量計算と実際の演出をするウディタと別に分けたいが、なんか時間がもったいないので全部をウディタでさせることにする。
mathematicaとかはこういうのはifとかwhileやwhichやforなどでかなり楽に記述できる(単純とは言ってない)上に計算能力が非常に高いという利点はあるが…。
このプログラムを考えている間にもPO調整は進行中である。
2019年11月23日土曜日
16-3 PO調整機構(3)
以下にPO調整によってうまく目標のPO率80%に近づけられているかを順を追って確認していく。
ver1.0 調整機構を実装。状態値が+1,0,-1の間で変動,0や100を超えてしまう
結果 スマッシュ、バルーン、ガーデン、エイト→高 ドロップ、ファーム→低
9ゲームPO率 75.7%
ver1.1 調整幅に加重をとり、範囲を0~100に、その他数値の微調整
結果 459回試行 ガーデン、ファームがそれぞれ不調
9ゲームPO率 79.4% いい感じに調整できている。…が気のせいかもしれない
ver.1.2 ビンゴガーデンの状態値が高いときより良いカードが出る、ファームの状態値が低い時のカードによりFREE1個が出やすく、バルーンの状態値高でFREE2,3個がさらに出やすくする修正を実行。
結果 ガーデン、バルーンがPO率低。ただこれはアルゴリズム等の問題なので、保留。
ファームのPOが低下し、理想に近く。ハニーエイトは30倍ボーナスが7回くらい出ており、これで630000枚の放出。これを除くと744000枚のIN中532800となり、71.6%となる。
したがって7連以降は設定のいかんにかかわらずスタート隣接マスが2個になる確率を高くすることが望まれる。スマッシュはより高設定低設定の差を大きくする、などが改善点。
9ゲームPO率 85.0%
ver1.3 ハニーエイト7連以降連荘しにくくなり、ファーム、スマッシュなどの設定をさらに調整。また、ハニーエイトで2個以下の時にも3個になってしまう問題を修正。
結果 824ゲーム分を集計。おおむね試行回数を増加させたおかげでよい感じに収束。
すべてのゲームが設定した80%周辺に収まっている。
9ゲームPO率 78.6%
注意:最下段のPO率が82%とかいうのはバグで、これはおそらくINが10000000を超えていることによる変数参照か何かの問題と思われる。
状態値の参考↓
アニマドロップ 79
チェーンボンバー 0
サンダースマッシュ 90
ビンゴバルーン 100
ビンゴガーデン 100
ビンゴファーム 23
ハニーエイト 100
アニマツリー 100
ハッピーフラワー 100
ボンバーはやはり数字が上に偏るか下に偏るかでより調整をかけたほうがよさそう。
バルーン、ガーデンは保留として、ファームがようやくPO率80%に対応した。
ハニーエイトは8連以降必ずスタート周辺拠点が2個という条件にしたため、やはり周辺スタートが3個以上でもエイトボーナスなしでは70%少しが限界?ということでエイトボーナス獲得の条件をもとに戻す。ツリーは全体的に良い設定として見直したい。フラワーはまあ…とりあえずこのままにしておくかちょっといじくる。
ver1.4 ビンゴバルーンの配置アルゴリズムを一新。ハニーエイトでエイトボーナス発生率を通常に戻す。やっぱり適切なパラメータ設定が難しいのはこういうところでも同じ。
しかしこうやって回収率を自ら設定してプログラムして実際にうまくいくことがなんか快感を覚えるというか…(変態)
ビンゴバルーンの配置の基準は以下
「まず7個ラインについて判定し、ビンゴになるならそれらをビンゴになるように配置、リーチになるならそのように配置。そしてビンゴとリーチの両方を考えて、残ったFREEの個数を5個ラインの判定に回す。5,4,3個ラインでもまったく同様の処理を行い、それでも余ったものはオッズアップとして配置する。」
なおこれまでの配置アルゴリズムは「あと1個でビンゴのところにFREEを配置。それ以外は適当(いい加減)なところに配置」というしょぼい配置方法だったため、PO率のそこそこの上昇が見込まれる。こうなると7個ラインの成立確率が高くなるわけである。
あと、ハッピーフラワーの高状態値により良い初期芽構成になるように修正。またビンゴガーデンも同様に高状態値に期待値最良のカードが出やすく(具体的には状態値100で80%)なるように修正。これで再び様子を見る。ついでにツリーも修正。
ボンバーも上段指数と有効率を実装、詳細は次の記事で。
結果
ver1.0 調整機構を実装。状態値が+1,0,-1の間で変動,0や100を超えてしまう
結果 スマッシュ、バルーン、ガーデン、エイト→高 ドロップ、ファーム→低
9ゲームPO率 75.7%
ver1.1 調整幅に加重をとり、範囲を0~100に、その他数値の微調整
結果 459回試行 ガーデン、ファームがそれぞれ不調
9ゲームPO率 79.4% いい感じに調整できている。…が気のせいかもしれない
結果 ガーデン、バルーンがPO率低。ただこれはアルゴリズム等の問題なので、保留。
ファームのPOが低下し、理想に近く。ハニーエイトは30倍ボーナスが7回くらい出ており、これで630000枚の放出。これを除くと744000枚のIN中532800となり、71.6%となる。
したがって7連以降は設定のいかんにかかわらずスタート隣接マスが2個になる確率を高くすることが望まれる。スマッシュはより高設定低設定の差を大きくする、などが改善点。
9ゲームPO率 85.0%
ver1.3 ハニーエイト7連以降連荘しにくくなり、ファーム、スマッシュなどの設定をさらに調整。また、ハニーエイトで2個以下の時にも3個になってしまう問題を修正。
結果 824ゲーム分を集計。おおむね試行回数を増加させたおかげでよい感じに収束。
すべてのゲームが設定した80%周辺に収まっている。
9ゲームPO率 78.6%
注意:最下段のPO率が82%とかいうのはバグで、これはおそらくINが10000000を超えていることによる変数参照か何かの問題と思われる。
状態値の参考↓
アニマドロップ 79
チェーンボンバー 0
サンダースマッシュ 90
ビンゴバルーン 100
ビンゴガーデン 100
ビンゴファーム 23
ハニーエイト 100
アニマツリー 100
ハッピーフラワー 100
ボンバーはやはり数字が上に偏るか下に偏るかでより調整をかけたほうがよさそう。
バルーン、ガーデンは保留として、ファームがようやくPO率80%に対応した。
ハニーエイトは8連以降必ずスタート周辺拠点が2個という条件にしたため、やはり周辺スタートが3個以上でもエイトボーナスなしでは70%少しが限界?ということでエイトボーナス獲得の条件をもとに戻す。ツリーは全体的に良い設定として見直したい。フラワーはまあ…とりあえずこのままにしておくかちょっといじくる。
ver1.4 ビンゴバルーンの配置アルゴリズムを一新。ハニーエイトでエイトボーナス発生率を通常に戻す。やっぱり適切なパラメータ設定が難しいのはこういうところでも同じ。
しかしこうやって回収率を自ら設定してプログラムして実際にうまくいくことがなんか快感を覚えるというか…(変態)
ビンゴバルーンの配置の基準は以下
「まず7個ラインについて判定し、ビンゴになるならそれらをビンゴになるように配置、リーチになるならそのように配置。そしてビンゴとリーチの両方を考えて、残ったFREEの個数を5個ラインの判定に回す。5,4,3個ラインでもまったく同様の処理を行い、それでも余ったものはオッズアップとして配置する。」
なおこれまでの配置アルゴリズムは「あと1個でビンゴのところにFREEを配置。それ以外は適当(いい加減)なところに配置」というしょぼい配置方法だったため、PO率のそこそこの上昇が見込まれる。こうなると7個ラインの成立確率が高くなるわけである。
あと、ハッピーフラワーの高状態値により良い初期芽構成になるように修正。またビンゴガーデンも同様に高状態値に期待値最良のカードが出やすく(具体的には状態値100で80%)なるように修正。これで再び様子を見る。ついでにツリーも修正。
ボンバーも上段指数と有効率を実装、詳細は次の記事で。
結果
16-2 PO調整機構(2)
しばらくゲームをさせた結果、以下のようになった。
内部値↓
アニマドロップ -28
チェーンボンバー 67
サンダースマッシュ 150
ビンゴバルーン 150
ビンゴガーデン 146
ビンゴファーム -48
ハニーエイト 128
アニマツリー 65
ハッピーフラワー 40
ナインビンゴを除くと、2565000のINに対してOUTは1942300となり、PO率は75.7%である。一見なんとなくうまくいってそうに見えるが、これはもしかするとたまたまな可能性がある。内部値を見てわかる通り、100や0を超えてしまっている。
アニマドロップやビンゴファームは内部値をマイナスにしなければいけないほど高設定であり、ビンゴバルーン、ビンゴガーデンは低設定であることが分かる。
ここから言えることは、もう少しアニマドロップなどの状態値を引数とする設定を下げる必要があり、ビンゴガーデン、ビンゴファームの設定を全体的に上げる必要がある、と思われる。まだ100ゲームもやっていないので何とも言えないが、これまでの調整しないPO結果からもファームとドロップのPOが高く、ガーデンとバルーンのPOが低いことは承知していた。
ガーデンとバルーンはまだこちらの配置アルゴリズムがそこまでよくないのに起因している。特にビンゴバルーンとか。
ビンゴバルーンの配置基準は極めて難しい問題なのでとりあえず保留するとして、
ドロップとファームは修正の余地あり。
ファームはチャンスカードでしかPOを操作していないので、やはり通常時のカードのFREEマスでも制御しようと思う。
内部値↓
アニマドロップ -28
チェーンボンバー 67
サンダースマッシュ 150
ビンゴバルーン 150
ビンゴガーデン 146
ビンゴファーム -48
ハニーエイト 128
アニマツリー 65
ハッピーフラワー 40
ナインビンゴを除くと、2565000のINに対してOUTは1942300となり、PO率は75.7%である。一見なんとなくうまくいってそうに見えるが、これはもしかするとたまたまな可能性がある。内部値を見てわかる通り、100や0を超えてしまっている。
アニマドロップやビンゴファームは内部値をマイナスにしなければいけないほど高設定であり、ビンゴバルーン、ビンゴガーデンは低設定であることが分かる。
ここから言えることは、もう少しアニマドロップなどの状態値を引数とする設定を下げる必要があり、ビンゴガーデン、ビンゴファームの設定を全体的に上げる必要がある、と思われる。まだ100ゲームもやっていないので何とも言えないが、これまでの調整しないPO結果からもファームとドロップのPOが高く、ガーデンとバルーンのPOが低いことは承知していた。
ガーデンとバルーンはまだこちらの配置アルゴリズムがそこまでよくないのに起因している。特にビンゴバルーンとか。
ビンゴバルーンの配置基準は極めて難しい問題なのでとりあえず保留するとして、
ドロップとファームは修正の余地あり。
ファームはチャンスカードでしかPOを操作していないので、やはり通常時のカードのFREEマスでも制御しようと思う。
16-1 PO調整機構(1)
ゲームのシステムもまあまあ整ってきたところで、そろそろPO調整システムを実装しようと思っている。
本当は昨日やっていたが、突然USBが抜けた扱いに(抜けていないにも関わらず)なった音がして、その後更新をしてセーブをすると「CommonEvent.dat 0KB」という我々にとってスーパーデラックス0%0%0%並みの衝撃になる事案発生。
それを解決するのに時間がかかってしまったので、日を改めて今日ついに実装していくことにする。
それに伴い、ハニーエイトの設定案件としてスタートの周囲に何個番号があるか、ということでPO率調整をしようと思う。(ほかにも数字の偏りや、端っこに出現しやすい、などもあるが今回は考えない。理由は端っこの定義とかをすると面倒なので。周囲のマスを判定してマスが存在しない(=0)が1以上とかの要件が必要になるためである)
真ん中付近で、周囲のマスを判定して番号があれば1以上が返される。
がよく見てみるとマスが存在しない場合は0を返すので、上のプログラムだと実は変数0番に1以上の値があるとそれをカウントしてしまう…という問題があることがぱっと見るとわかるがその場所はなんとなく変数として使っていないので問題ない。
カウントが1以下ならやり直し、としているが、これを設定ごとに「1以下やり直し」「2以下やり直し」の2つに分ければよいだけである。
ただもしかすると周囲に3個マスがないような配置になることもあるので、一定回数やって周囲3を見つけられなければおとなしく周囲2でよい、ということにする。
目安としては100回程度。
さて、ここまで準備が整ったところで、いよいよPO率がうまく働いているか長時間稼働させてテストする。
PO率調整には状態値を用いる。最初は状態値50で、以後目標POより低ければ状態値を+1補正し、高ければ-1補正する。するといい感じにある値に収束するのではないか、という考え。かなり単純でこの方法だとすぐさま攻略法がばれてしまうわけだが(最初に100BETして合計WINが合計BETより下がった時点で最低BETにして内部値を上昇させまくって100になったころ合いを見計らって大量BETするというやり方)最初なのでこれくらいでよい。
だがしかし、PO率80%に相当する状態値が0~100にない場合は、おそらく0か100の値をとってしまうだろうとみている。その場合は、0や100に達したゲームの状態値を引数とした各種確率を見直すことになる。
いずれにせよ、長いことゲームを回さなければなにもできないので、ゲームスタートや。
今は9ゲームのPO率80%を目標として動作させている。
ナインビンゴは現状ではほかのゲーム依存なので、POの調整のしようがない。
本物ならばラインがそろえば配当GETなどがあるのでそれでいけるかもしれないが。
ワンダーチャンスとかを含めればこの80%に少し加わってくるので、たぶんPO率88%とか90%とかいう実機に近い形を出せるのではないかと期待している。
このPO率調整という楽しい遊びができるようになるまで一体何十万行のプログラムを書いたことか…。
次の記事では、ある程度の階数ゲームを行わせた時の結果と考察を書く予定。
本当は昨日やっていたが、突然USBが抜けた扱いに(抜けていないにも関わらず)なった音がして、その後更新をしてセーブをすると「CommonEvent.dat 0KB」という我々にとってスーパーデラックス0%0%0%並みの衝撃になる事案発生。
それを解決するのに時間がかかってしまったので、日を改めて今日ついに実装していくことにする。
それに伴い、ハニーエイトの設定案件としてスタートの周囲に何個番号があるか、ということでPO率調整をしようと思う。(ほかにも数字の偏りや、端っこに出現しやすい、などもあるが今回は考えない。理由は端っこの定義とかをすると面倒なので。周囲のマスを判定してマスが存在しない(=0)が1以上とかの要件が必要になるためである)
真ん中付近で、周囲のマスを判定して番号があれば1以上が返される。
がよく見てみるとマスが存在しない場合は0を返すので、上のプログラムだと実は変数0番に1以上の値があるとそれをカウントしてしまう…という問題があることがぱっと見るとわかるがその場所はなんとなく変数として使っていないので問題ない。
カウントが1以下ならやり直し、としているが、これを設定ごとに「1以下やり直し」「2以下やり直し」の2つに分ければよいだけである。
ただもしかすると周囲に3個マスがないような配置になることもあるので、一定回数やって周囲3を見つけられなければおとなしく周囲2でよい、ということにする。
目安としては100回程度。
さて、ここまで準備が整ったところで、いよいよPO率がうまく働いているか長時間稼働させてテストする。
PO率調整には状態値を用いる。最初は状態値50で、以後目標POより低ければ状態値を+1補正し、高ければ-1補正する。するといい感じにある値に収束するのではないか、という考え。かなり単純でこの方法だとすぐさま攻略法がばれてしまうわけだが(最初に100BETして合計WINが合計BETより下がった時点で最低BETにして内部値を上昇させまくって100になったころ合いを見計らって大量BETするというやり方)最初なのでこれくらいでよい。
だがしかし、PO率80%に相当する状態値が0~100にない場合は、おそらく0か100の値をとってしまうだろうとみている。その場合は、0や100に達したゲームの状態値を引数とした各種確率を見直すことになる。
いずれにせよ、長いことゲームを回さなければなにもできないので、ゲームスタートや。
今は9ゲームのPO率80%を目標として動作させている。
ナインビンゴは現状ではほかのゲーム依存なので、POの調整のしようがない。
本物ならばラインがそろえば配当GETなどがあるのでそれでいけるかもしれないが。
ワンダーチャンスとかを含めればこの80%に少し加わってくるので、たぶんPO率88%とか90%とかいう実機に近い形を出せるのではないかと期待している。
このPO率調整という楽しい遊びができるようになるまで一体何十万行のプログラムを書いたことか…。
次の記事では、ある程度の階数ゲームを行わせた時の結果と考察を書く予定。
2019年11月22日金曜日
15-15 自作アニマロッタプレイ動画
まだまだ不十分ではあるが、ひとまずそれっぽいものができたので中間発表的な意味合いで動画をとっておくことにする。
自動的に開始時に全ゲーム500BETずつされるようにしている。
定義によると内部値は3000~4000なので、これは金りんごLv2またはLv3のゾーンと思われる。
ちなみに我がいろいろ加工や自作などして頑張って作ったピクチャは以下。
png形式のものが852個、bmp形式のものが79個ある。
プログラム作成もなかなか時間がかかるが、良い画像を探してきたり加工したり透過処理すること自体も実は相当大変である。
今後の予定としては、BETタイム時の各ゲームの状態を再現しようと考える。
例えばビンゴガーデンはFREE配置はまだ行われていないし、チェーンボンバーも色の組み合わせや爆弾、番号の配置は決まっていない。これらに加えて、現時点での問題であるオッズ表等の更新も併せて行おうと思っている。
なお、BETタイムをより精密化し、上限なども設けた。
一つでも上限オーバー見込みが発生すると全ゲームBETは押せなくなり、もちろんその該当ゲームも押下できなくなる。
アニマの基準通り、3000BETを上限とし、アニマツリーのみ前回WINを引き継げる。ただし3000より大きい継続では追加のBETはできない。また、5000を超えると自動的に継続は5000となる。
BETタイムの条件設定は相当複雑なので、これはたぶん作るのは難しいと思う。
自動的に開始時に全ゲーム500BETずつされるようにしている。
定義によると内部値は3000~4000なので、これは金りんごLv2またはLv3のゾーンと思われる。
png形式のものが852個、bmp形式のものが79個ある。
プログラム作成もなかなか時間がかかるが、良い画像を探してきたり加工したり透過処理すること自体も実は相当大変である。
今後の予定としては、BETタイム時の各ゲームの状態を再現しようと考える。
例えばビンゴガーデンはFREE配置はまだ行われていないし、チェーンボンバーも色の組み合わせや爆弾、番号の配置は決まっていない。これらに加えて、現時点での問題であるオッズ表等の更新も併せて行おうと思っている。
なお、BETタイムをより精密化し、上限なども設けた。
一つでも上限オーバー見込みが発生すると全ゲームBETは押せなくなり、もちろんその該当ゲームも押下できなくなる。
アニマの基準通り、3000BETを上限とし、アニマツリーのみ前回WINを引き継げる。ただし3000より大きい継続では追加のBETはできない。また、5000を超えると自動的に継続は5000となる。
BETタイムの条件設定は相当複雑なので、これはたぶん作るのは難しいと思う。
登録:
投稿 (Atom)












