ちょっとここでネタをはさむ。
ビンゴファームはある規則により、配置番号が偏らないようにできているが、その制限を取り払うと以下のようになる。本家では起こらないので注意。
40ラインの配当が76倍、スーパーの配当10倍が16個で160倍、ハイパーの配当50倍が2個で100倍、計336倍のあたりとなる。
余談だが、現時点でのコモンイベントファイルはすでに6MB以上に膨れ上がっている。
2019年11月29日金曜日
16-10 BETタイム再強化とおまけ
BETタイム時に、各種設定が見えないようにして、ロゴの追加や、BET時にBET額が徐々に上がっていく演出を実装。
閉じるボタンを描画したが、まだ閉じることはできない。
ちょっとここでネタをはさむ。
ビンゴファームはある規則により、配置番号が偏らないようにできているが、その制限を取り払うと以下のようになる。本家では起こらないので注意。
上の画像のように1が入ればオールラインである。
オールラインになると2つ目の画像のようになり、
40ラインの配当が76倍、スーパーの配当10倍が16個で160倍、ハイパーの配当50倍が2個で100倍、計336倍のあたりとなる。
余談だが、現時点でのコモンイベントファイルはすでに6MB以上に膨れ上がっている。
ちょっとここでネタをはさむ。
ビンゴファームはある規則により、配置番号が偏らないようにできているが、その制限を取り払うと以下のようになる。本家では起こらないので注意。
40ラインの配当が76倍、スーパーの配当10倍が16個で160倍、ハイパーの配当50倍が2個で100倍、計336倍のあたりとなる。
余談だが、現時点でのコモンイベントファイルはすでに6MB以上に膨れ上がっている。
2019年11月27日水曜日
16-9 サンダースマッシュのPO率(2)
さて、まずはサンダースマッシュにはこちらが調べたところでは12パターン存在して、
パターンxのことをxと表記することにして、左側がx,右側がyのことをx-yと表記することにすると、1,4,6,7,9,10,12が最下段に雷があり、2,3,5,8,11が最下段に雷がない。
たぶんこんな感じの分析であっていると思う。確証はないので注意。
なにしろサンダースマッシュの確率を解析する人物がほかにいなくて…。
ちなみに、実際に最高設定のスマッシュをたくさん実行したところ、やはり長くやるとPO率が110%を超えてくる。さらに、超高額リーチの発生頻度がそこそこ多め。やはり設定が良いと思われる。
パターンxのことをxと表記することにして、左側がx,右側がyのことをx-yと表記することにすると、1,4,6,7,9,10,12が最下段に雷があり、2,3,5,8,11が最下段に雷がない。
さらに、左右対称となるような組み合わせは、最下段に必ず1個だけ雷マスが配置されることから、片方は1,4,6,7,9,10,12のいずれかから1つ、そしてもう片方は2,3,5,8,11のいずれかから1つ選ばれる。したがってそのような組み合わせは存在しない。
次に、1-2と2-1のようなひっくり返すと同じものになるような2つの組み合わせは、明らかにPO率が同一であるから、以後いろいろなパターンを調べる際は、左の最下段に雷があるものとしてよいことになる。
となると、全体の組み合わせとしては7*5=35通りの配置が考えられることになる。
この35通りの中で、どの組み合わせがPO率が良く、また期待値のおおまかな分布はどうなっているのか、そして片側全消し、両側全消しの確率はいくらか、を見ていくことにする。
あ、1とか2とかの配置は実際はどうやねん、ということについてはこの記事の下のほうでたぶん画像を張り付ける。画像の順番に、左から1,2,3,4,5,6,7,8,9,10,11,12という感じ。
以下は35種類の組み合わせを記述した「表」である。エクセルが使えるのは大学のPCだけや…。というわけで簡単なもので代用する。
左から組み合わせ、PO率、片側全消し回数、両側全消し回数、配当発生回数、1倍以上回数、3倍以上回数、5倍以上回数、10倍以上回数、30倍以上回数、50倍以上回数であり、それぞれ試行回数は10000回としている。これ以上は時間がかかる。
なお10000回なので、PO率の小数点1桁は信頼性がかなり低いと思われる。
仮定として、オッズアップは各ブロック50%で、全消しは100%でオッズアップすることにしているはず。
組 PO 片全 両全 獲得 ×1 ×3 ×5 ×10 ×30 ×50
なお10000回なので、PO率の小数点1桁は信頼性がかなり低いと思われる。
仮定として、オッズアップは各ブロック50%で、全消しは100%でオッズアップすることにしているはず。
組 PO 片全 両全 獲得 ×1 ×3 ×5 ×10 ×30 ×50
1-2 87.5% 28回 0回 5392回 3451回 470回 116回 33回 28回 0回
1-3 98.9% 86回 6回 6055回 2445回 437回 187回 94回 92回 6回
1-5 85.0% 33回 2回 5431回 3285回 375回 95回 35回 35回 2回
1-8 82.2% 115回 3回 4734回 1417回 306回 190回 120回 118回 4回
1-11 94.6% 97回 12回 4939回 1812回 415回 199回 122回 109回 15回
1-3 98.9% 86回 6回 6055回 2445回 437回 187回 94回 92回 6回
1-5 85.0% 33回 2回 5431回 3285回 375回 95回 35回 35回 2回
1-8 82.2% 115回 3回 4734回 1417回 306回 190回 120回 118回 4回
1-11 94.6% 97回 12回 4939回 1812回 415回 199回 122回 109回 15回
4-2 85.1% 6回 0回 5055回 3293回 645回 134回 11回 6回 0回
4-3 75.6% 5回 0回 5618回 2298回 591回 205回 20回 5回 0回
4-5 81.7% 5回 0回 5159回 3191回 533回 116回 13回 5回 0回
4-8 55.5% 16回 0回 4267回 1382回 420回 196回 37回 16回 0回
4-11 61.8% 4回 1回 4614回 1726回 454回 181回 51回 6回 1回
6-2 83.2% 18回 1回 5321回 3225回 508回 197回 24回 19回 1回
6-3 92.7% 63回 5回 5354回 2066回 622回 407回 78回 68回 5回
6-5 77.9% 14回 2回 5406回 3090回 454回 170回 20回 16回 2回
6-8 84.1% 93回 5回 5106回 1285回 498回 401回 110回 98回 5回
6-11 80.3% 45回 6回 5547回 1615回 480回 281回 129回 51回 7回
7-2 119.0% 25回 2回 5637回 3854回 1044回 356回 54回 27回 2回
7-3 124.2% 49回 2回 6267回 3051回 1027回 612回 110回 51回 2回
7-5 104.1% 15回 1回 5556回 3550回 818回 251回 32回 16回 1回
7-8 102.1% 71回 4回 4744回 1930回 734回 517回 158回 75回 4回
7-11 102.9% 36回 6回 5022回 2192回 718回 411回 201回 42回 9回
9-2 65.5% 11回 1回 5756回 2166回 391回 98回 18回 12回 1回
9-3 63.0% 31回 3回 5742回 1357回 367回 148回 40回 34回 3回
9-5 61.0% 7回 4回 5765回 1850回 308回 82回 16回 11回 4回
9-8 53.4% 41回 6回 5134回 851回 263回 129回 51回 47回 6回
9-11 58.9% 32回 2回 5434回 1098回 311回 153回 60回 34回 6回
10-2 87.8% 33回 5回 4383回 2515回 704回 204回 50回 38回 5回
10-3 124.6% 132回 13回 5242回 2062回 751回 417回 155回 145回 16回
10-5 84.3% 32回 7回 4514回 2425回 581回 193回 43回 39回 7回
10-8 129.4% 204回 23回 3846回 1307回 539回 396回 236回 227回 26回
10-11 114.2% 137回 12回 4048回 1485回 528回 328回 197回 149回 22回
12-2 116.3% 22回 1回 7159回 4474回 642回 215回 38回 23回 1回
12-3 104.4% 35回 5回 7012回 2756回 771回 340回 57回 40回 5回
12-5 103.1% 9回 0回 7039回 3991回 558回 146回 17回 9回 0回
12-8 80.3% 62回 2回 5210回 1589回 479回 263回 84回 64回 3回
12-11 86.1% 31回 5回 5551回 1989回 569回 256回 89回 36回 5回
というわけで、このデータによると下の画像の組み合わせが最も悪い。
もちろんほかのカードの把握し忘れなどもあるので確実ではないが、それでもこの組み合わせの期待値は低い。組み合わせは8-9
逆に、下に挙げるほうは最高の期待値を誇る組み合わせ。8-10である。
片側全消し率はなぜか最も高く、2%にも上る。
期待値が高くなる原因としては、右側は雷が最下段のどこにHITしても必ず次の段も雷になる、ということに由来している…?
それにしても、パターン8が相手によってはよくも悪くもなりうるというのは意外である。
なお、パターン2,3,4,5,9が雷マス6個以下、1,6,7,8,10,11,12が雷マス7個以上である。
そこまで雷マスの個数による有利かどうかの判断はつけにくい傾向がある…?
片側全消しはざっくりとみて平均で0.5%(200回に1回)、両側全消しは0.05%(2000回に1回),
という感じか…?
4-3 75.6% 5回 0回 5618回 2298回 591回 205回 20回 5回 0回
4-5 81.7% 5回 0回 5159回 3191回 533回 116回 13回 5回 0回
4-8 55.5% 16回 0回 4267回 1382回 420回 196回 37回 16回 0回
4-11 61.8% 4回 1回 4614回 1726回 454回 181回 51回 6回 1回
6-2 83.2% 18回 1回 5321回 3225回 508回 197回 24回 19回 1回
6-3 92.7% 63回 5回 5354回 2066回 622回 407回 78回 68回 5回
6-5 77.9% 14回 2回 5406回 3090回 454回 170回 20回 16回 2回
6-8 84.1% 93回 5回 5106回 1285回 498回 401回 110回 98回 5回
6-11 80.3% 45回 6回 5547回 1615回 480回 281回 129回 51回 7回
7-2 119.0% 25回 2回 5637回 3854回 1044回 356回 54回 27回 2回
7-3 124.2% 49回 2回 6267回 3051回 1027回 612回 110回 51回 2回
7-5 104.1% 15回 1回 5556回 3550回 818回 251回 32回 16回 1回
7-8 102.1% 71回 4回 4744回 1930回 734回 517回 158回 75回 4回
7-11 102.9% 36回 6回 5022回 2192回 718回 411回 201回 42回 9回
9-2 65.5% 11回 1回 5756回 2166回 391回 98回 18回 12回 1回
9-3 63.0% 31回 3回 5742回 1357回 367回 148回 40回 34回 3回
9-5 61.0% 7回 4回 5765回 1850回 308回 82回 16回 11回 4回
9-8 53.4% 41回 6回 5134回 851回 263回 129回 51回 47回 6回
9-11 58.9% 32回 2回 5434回 1098回 311回 153回 60回 34回 6回
10-2 87.8% 33回 5回 4383回 2515回 704回 204回 50回 38回 5回
10-3 124.6% 132回 13回 5242回 2062回 751回 417回 155回 145回 16回
10-5 84.3% 32回 7回 4514回 2425回 581回 193回 43回 39回 7回
10-8 129.4% 204回 23回 3846回 1307回 539回 396回 236回 227回 26回
10-11 114.2% 137回 12回 4048回 1485回 528回 328回 197回 149回 22回
12-2 116.3% 22回 1回 7159回 4474回 642回 215回 38回 23回 1回
12-3 104.4% 35回 5回 7012回 2756回 771回 340回 57回 40回 5回
12-5 103.1% 9回 0回 7039回 3991回 558回 146回 17回 9回 0回
12-8 80.3% 62回 2回 5210回 1589回 479回 263回 84回 64回 3回
12-11 86.1% 31回 5回 5551回 1989回 569回 256回 89回 36回 5回
というわけで、このデータによると下の画像の組み合わせが最も悪い。
もちろんほかのカードの把握し忘れなどもあるので確実ではないが、それでもこの組み合わせの期待値は低い。組み合わせは8-9
片側全消し率はなぜか最も高く、2%にも上る。
それにしても、パターン8が相手によってはよくも悪くもなりうるというのは意外である。
なお、パターン2,3,4,5,9が雷マス6個以下、1,6,7,8,10,11,12が雷マス7個以上である。
そこまで雷マスの個数による有利かどうかの判断はつけにくい傾向がある…?
片側全消しはざっくりとみて平均で0.5%(200回に1回)、両側全消しは0.05%(2000回に1回),
という感じか…?
たぶんこんな感じの分析であっていると思う。確証はないので注意。
なにしろサンダースマッシュの確率を解析する人物がほかにいなくて…。
ちなみに、実際に最高設定のスマッシュをたくさん実行したところ、やはり長くやるとPO率が110%を超えてくる。さらに、超高額リーチの発生頻度がそこそこ多め。やはり設定が良いと思われる。
16-8 サンダースマッシュのPO率(1)
PO調整をするようになってから気づいたが、サンダースマッシュのPO率がどうも初期雷数依存ではあまりないという事実が判明してきた。
高設定にしてもスマッシュは目標のPO率80%に届かないし、逆に低設定にしてもなかなか7割を割らない感じである。
これには考えられる原因が2つあって、一つ目は
そもそもPO率が低い⇔初期雷数が少ない を真としていることであって、
この場合は、それぞれのパターンの組み合わせのPO率を個別に調べ上げる必要あり。
2つ目は低設定や高設定パターンのサンプルを採取していない、ということである。
そういうわけで、演出を抜いた高速実験を行う。余計な部分を削り取って、とりあえずあったら面白そうな情報をピックアップして適当にいろいろ変更してみた。
上の動画はひたすら試行回数を重ねてPO率やその他の情報を割り出している最中である。
これにより、1回あたりのゲームにかかる時間が大幅に短縮された。
とりあえず数万回程度を目安にしてどういう状況化を把握していきたいと思う。
いやなんかmathematicaにスマッシュのパターンを再度うちこむのに嫌気がさして、もういっそのこと実装したゲームから演出やその他いろいろPO計算に不要なものは排除してウディタでそのままやったほうが、いい、という結論を得たので…。
もちろんこれはコピーしたゲームをいじくっているわけであり、もとのゲームは残っている。さすがにそんな愚かな行為はしない(といいつつつい先日もデータが消えていたりする)
ただ秒速8ゲーム程度なので、以後いろんなパターンで実際に確率やPOを求めていくときはもうちょっと余計な操作がないかチェックして、1ゲーム当たりの処理時間を早くしようと思っている。とりあえずたくさん試行すれば70%台におさまるはず。これまでのデータから見るに。
よく雲の大樹の攻略法を教えてください!とかいう質問を見かけるが、そもそもどんな配置がどんな確率で発生する等の情報が得られなければ、それは開発側でもない限り不可能である。なおKONAMIのアニマロッタを作っているグループは我の憧れである。一度はアニマロッタの機械構造やプログラムなどの事項をこちらのほうが知りたいほうや…。
プログラムなどや様々な確率を知ることができればこちらはシミュレーションでおそらく全ゲーム対応可能だと思う。
したがってこのブログで攻略法を扱うことは不可能である。だがこういう設定になるとこんな感じの挙動で、PO率がこれくらいで…という話はすることができる。
高設定にしてもスマッシュは目標のPO率80%に届かないし、逆に低設定にしてもなかなか7割を割らない感じである。
これには考えられる原因が2つあって、一つ目は
そもそもPO率が低い⇔初期雷数が少ない を真としていることであって、
この場合は、それぞれのパターンの組み合わせのPO率を個別に調べ上げる必要あり。
2つ目は低設定や高設定パターンのサンプルを採取していない、ということである。
そういうわけで、演出を抜いた高速実験を行う。余計な部分を削り取って、とりあえずあったら面白そうな情報をピックアップして適当にいろいろ変更してみた。
これにより、1回あたりのゲームにかかる時間が大幅に短縮された。
とりあえず数万回程度を目安にしてどういう状況化を把握していきたいと思う。
いやなんかmathematicaにスマッシュのパターンを再度うちこむのに嫌気がさして、もういっそのこと実装したゲームから演出やその他いろいろPO計算に不要なものは排除してウディタでそのままやったほうが、いい、という結論を得たので…。
もちろんこれはコピーしたゲームをいじくっているわけであり、もとのゲームは残っている。さすがにそんな愚かな行為はしない(といいつつつい先日もデータが消えていたりする)
ただ秒速8ゲーム程度なので、以後いろんなパターンで実際に確率やPOを求めていくときはもうちょっと余計な操作がないかチェックして、1ゲーム当たりの処理時間を早くしようと思っている。とりあえずたくさん試行すれば70%台におさまるはず。これまでのデータから見るに。
よく雲の大樹の攻略法を教えてください!とかいう質問を見かけるが、そもそもどんな配置がどんな確率で発生する等の情報が得られなければ、それは開発側でもない限り不可能である。なおKONAMIのアニマロッタを作っているグループは我の憧れである。一度はアニマロッタの機械構造やプログラムなどの事項をこちらのほうが知りたいほうや…。
プログラムなどや様々な確率を知ることができればこちらはシミュレーションでおそらく全ゲーム対応可能だと思う。
したがってこのブログで攻略法を扱うことは不可能である。だがこういう設定になるとこんな感じの挙動で、PO率がこれくらいで…という話はすることができる。
16-7 ペイアウト率とは
ペイアウト率(略してPO率、とこのブログでは記述する)とは、PAYという支払いに対してOUTという外に出す、つまり排出、ということで、ある掛け金に対してどれくらいの割合で手元に勝ち金?が返ってくるかを意味する。
例えばPO率80%ならば、100BETすれば平均80枚ほど勝つ計算になるし、
PO率105%ならば10000BETすれば平均で10500枚ほど勝つことになる。
簡単な例として、6面サイコロがあるとして、1が出れば掛け金5倍、それ以外は掛け金没収、というゲームがあれば、PO率はちょっと計算していくと83.3%となる。
また、この掛け金5倍が7倍だった場合、111.7%となる。
・・・というのはうそで、計算ミスだったので実際は116.7%だった。
100%より小さければかけた人は長い目で見ると損をするし、100%より大きければかけた人は得をする、というものである。短時間ではそうならないことも普通にある。
メダルゲーム等のPO率は最高設定でも100%であるらしい。よって最高設定以外の場合では基本負ける。
ではどのくらい負けるか、ということを実例を交えて紹介したいと思う。
まず、10000円で4000枚ほどメダルを購入するとする。そして個別に30BETずつしてナインビンゴということで10ゲーム分あるので、1回のゲームではトータル300BETということになる。1回あたり2分でゲームが回ると仮定するとだいたい以下の結論を得る。ただあくまで理論上なのでほかSTとの兼ね合いなども考えると、以下のようにはたぶん行かないと思われる。
PO率100% いつまででも遊べる
PO率95% 9時間ほど遊べる
PO率92% 6時間弱ほど遊べる
PO率90% 4時間強ほど遊べる
PO率88% 4時間弱ほど遊べる
PO率85% 3時間ほど遊べる
具体的な計算方法としては、PO率がn%であるとすると、1回あたり300*(1-(n/100))=300-3n枚を失うことになるので、もともと4000枚であるとすると、4000/(300-3n)回遊べることになり、これは1回あたり2分なので8000/(300-3n)分くらい遊べることになる。
我の自作アニマロッタでは目標として全体のPO率を70%~110%くらいに設定できるようにしたいと思っている。
例えばPO率80%ならば、100BETすれば平均80枚ほど勝つ計算になるし、
PO率105%ならば10000BETすれば平均で10500枚ほど勝つことになる。
簡単な例として、6面サイコロがあるとして、1が出れば掛け金5倍、それ以外は掛け金没収、というゲームがあれば、PO率はちょっと計算していくと83.3%となる。
また、この掛け金5倍が7倍だった場合、111.7%となる。
・・・というのはうそで、計算ミスだったので実際は116.7%だった。
100%より小さければかけた人は長い目で見ると損をするし、100%より大きければかけた人は得をする、というものである。短時間ではそうならないことも普通にある。
メダルゲーム等のPO率は最高設定でも100%であるらしい。よって最高設定以外の場合では基本負ける。
ではどのくらい負けるか、ということを実例を交えて紹介したいと思う。
まず、10000円で4000枚ほどメダルを購入するとする。そして個別に30BETずつしてナインビンゴということで10ゲーム分あるので、1回のゲームではトータル300BETということになる。1回あたり2分でゲームが回ると仮定するとだいたい以下の結論を得る。ただあくまで理論上なのでほかSTとの兼ね合いなども考えると、以下のようにはたぶん行かないと思われる。
PO率100% いつまででも遊べる
PO率95% 9時間ほど遊べる
PO率92% 6時間弱ほど遊べる
PO率90% 4時間強ほど遊べる
PO率88% 4時間弱ほど遊べる
PO率85% 3時間ほど遊べる
具体的な計算方法としては、PO率がn%であるとすると、1回あたり300*(1-(n/100))=300-3n枚を失うことになるので、もともと4000枚であるとすると、4000/(300-3n)回遊べることになり、これは1回あたり2分なので8000/(300-3n)分くらい遊べることになる。
我の自作アニマロッタでは目標として全体のPO率を70%~110%くらいに設定できるようにしたいと思っている。
2019年11月26日火曜日
16-6 PO率調整機構(4)
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率とは何であるかを。
これより、少なくとも通常ゲームが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月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
すると上の画像のように、上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%
状態値の参考↓
アニマドロップ 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以上とかの要件が必要になるためである)
がよく見てみるとマスが存在しない場合は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タイムをより精密化し、上限なども設けた。
アニマの基準通り、3000BETを上限とし、アニマツリーのみ前回WINを引き継げる。ただし3000より大きい継続では追加のBETはできない。また、5000を超えると自動的に継続は5000となる。
BETタイムの条件設定は相当複雑なので、これはたぶん作るのは難しいと思う。
15-14 BETタイムほぼ完成
ついにりんごとの関係性を定義し、いよいよBETによりりんごが生成されるように。
あとは各ゲームの更新やBETタイム時の挙動、BETタブの移動ボタンくらいを作れば十分。
どうでもいいが一応言っておくと、左上のゲームから順にりんごの内部値は
1498,1377,1082,1436,1157,1272,1492,1483,1147である。
内部値1250付近が金と銀の境目だったので、そこを境に上の画像でも金と銀に分かれている。実際に200BETをしてもたぶん上と似たようなりんごの色になるはず。
ちなみにハニー7連と書かれていてハニーエイトでBETできるやん、という鋭い指摘があるかもしれないが、これは7連のほうの状況を更新していないだけで、内部としては0連の状態に戻っているのでBETの追加は可能である。
2019年11月21日木曜日
15-13 BET拒否要件
BETタイム作成の一環として必要なものが、BET要求に対する拒否である。つまり、4クレジットしかないのに5BETできない、という単純にその話。
ボタンが押して機能しないことを示唆するために、ボタンを灰色にする必要がある。
この辺りの条件はいろいろと複雑だったが、実装に成功。なんか一部描画位置がずれているところがあるはそれは気にしない。
画像のように、現在CREDITより少ない場合はボタンが暗いし、反応もしなくなった。
ただハニーエイトだけ、継続BET後の追加BETを不可にする、という動作ができていないためボタンが暗くなっていないのでここは以後の修正点。
条件は「REBET済」かつ「1連荘以上」のときにBETを禁止すればよい。
おそらくBETタイムはりんご抜きでほぼ完成体に近いので、ここからはりんご発生の実装を行っていき、以前のべたりんご発生基準に基づいてBETでりんごが生成される。
これによってBETタイムからゲームスタートへの橋渡しがほぼ完了となる。
(オッズ表のBET更新による更新など課題もあるが)
ここまで行けば全体の流れが良い感じになるはずなので、再び動画を上げる予定である。
なお追加の行をいろいろ挟んでいったためこのコモンイベントのプログラムは1500行超となった。しかしここにりんごの話を入れるのでやはりさらに行が多くなることは免れない。
ボタンが押して機能しないことを示唆するために、ボタンを灰色にする必要がある。
この辺りの条件はいろいろと複雑だったが、実装に成功。なんか一部描画位置がずれているところがあるはそれは気にしない。
ただハニーエイトだけ、継続BET後の追加BETを不可にする、という動作ができていないためボタンが暗くなっていないのでここは以後の修正点。
条件は「REBET済」かつ「1連荘以上」のときにBETを禁止すればよい。
おそらくBETタイムはりんご抜きでほぼ完成体に近いので、ここからはりんご発生の実装を行っていき、以前のべたりんご発生基準に基づいてBETでりんごが生成される。
これによってBETタイムからゲームスタートへの橋渡しがほぼ完了となる。
(オッズ表のBET更新による更新など課題もあるが)
ここまで行けば全体の流れが良い感じになるはずなので、再び動画を上げる予定である。
なお追加の行をいろいろ挟んでいったためこのコモンイベントのプログラムは1500行超となった。しかしここにりんごの話を入れるのでやはりさらに行が多くなることは免れない。
2019年11月20日水曜日
15-12 BETタイム整備(3)
全ゲームREBETボタンなど必要なボタン類を張り付け、ボタンの入力条件を定義した。
例えば返り値24はツリーのハーフ継続であり、この値が返されたならばアニマツリーに一回前のBET額の半分をBETすることになる。
なお、REBETが350など5,10,20,50,100,500でない場合は、これになるための自動BETわけが行われるものとする。なお、分散をなるべくとるために5BET*70の処理として扱うのではなく、100*3+50*1として扱うものとする。
このアルゴリズムは、例えば1234という値ならば500で割った商と余りを考えて、そのあまりの次は100で同じことをしていき、各種商のリストがBETボタンの押し回数に相当するという簡単なプログラムによってなされる。ただし700で100*7とかにならないように必ず500での商と剰余から考えるべきである。なければ普通に500BET処理のループを0回としてよいので。
全ゲームBETボタンは、アニマロッタ5の性質によると、BET可能なものに対して、すべて左ボタンに相当するBET額を足すものとなる。
もしツリーやハニーが継続状態ならば、これは除かれる。
全ゲームREBETボタンは、何もBETしていない状況で機能して、この場合は継続ボタンも押される扱いになる。ツリーはハーフ可能であっても全額継続になる。
BET切り替えは初期5で、押される(返り値26)10,20,50,100,500,5,10,…と遷移する。
以上の処理を作成しBET額表示もするようにして、あとはりんごの一様分布プログラム作成により、たぶんBETタイムが完成する。
ここからまたかなりいろいろプログラムを組んで、適切な変数に適切なBET額を格納できるように。
とりあえず、はじめからを押せば継続がリセットされてボタンも初期状態に戻るなどの機能もつけておいた。
ここに後は全ゲームBETや全ゲームREBETの条件、そしてメダルが足りない場合あるいは上限BET数に達した場合にボタン操作を受け付けなくするなどの処理が必要になる。
ここまでして初めてBETに関する処理がおそらく終わったことになり、ここからようやくりんごの話になる。
やはり継続とかの話や、REBETの話も交えてBETタイムを作っているためかなり複雑になる。
ちなみに上の画像だと、実はハニーエイトに継続3000BETをしているのにボタンが変化しない、ツリーも同様など問題点もあるがそのあたりも修正予定である。
意外にこのBETタイムの根幹をなすコモンイベント771だけでも現段階で1000行を超えるという…。結構いろいろ描画すべきものや例外も多いので仕方がない。
例えば返り値24はツリーのハーフ継続であり、この値が返されたならばアニマツリーに一回前のBET額の半分をBETすることになる。
なお、REBETが350など5,10,20,50,100,500でない場合は、これになるための自動BETわけが行われるものとする。なお、分散をなるべくとるために5BET*70の処理として扱うのではなく、100*3+50*1として扱うものとする。
このアルゴリズムは、例えば1234という値ならば500で割った商と余りを考えて、そのあまりの次は100で同じことをしていき、各種商のリストがBETボタンの押し回数に相当するという簡単なプログラムによってなされる。ただし700で100*7とかにならないように必ず500での商と剰余から考えるべきである。なければ普通に500BET処理のループを0回としてよいので。
全ゲームBETボタンは、アニマロッタ5の性質によると、BET可能なものに対して、すべて左ボタンに相当するBET額を足すものとなる。
もしツリーやハニーが継続状態ならば、これは除かれる。
全ゲームREBETボタンは、何もBETしていない状況で機能して、この場合は継続ボタンも押される扱いになる。ツリーはハーフ可能であっても全額継続になる。
BET切り替えは初期5で、押される(返り値26)10,20,50,100,500,5,10,…と遷移する。
以上の処理を作成しBET額表示もするようにして、あとはりんごの一様分布プログラム作成により、たぶんBETタイムが完成する。
ここに後は全ゲームBETや全ゲームREBETの条件、そしてメダルが足りない場合あるいは上限BET数に達した場合にボタン操作を受け付けなくするなどの処理が必要になる。
ここまでして初めてBETに関する処理がおそらく終わったことになり、ここからようやくりんごの話になる。
やはり継続とかの話や、REBETの話も交えてBETタイムを作っているためかなり複雑になる。
ちなみに上の画像だと、実はハニーエイトに継続3000BETをしているのにボタンが変化しない、ツリーも同様など問題点もあるがそのあたりも修正予定である。
意外にこのBETタイムの根幹をなすコモンイベント771だけでも現段階で1000行を超えるという…。結構いろいろ描画すべきものや例外も多いので仕方がない。
2019年11月19日火曜日
15-11 BETタイム整備(2)
さて、話を戻していよいよBETタイムのプログラム及びピクチャの貼り付けを行っていく。
なんか5BETの5という数字に違和感があってちょっぴり悲しいが…。
後はここからプログラムでREBETなどの情報を拾ったりしていく。
いやこれはまだまだ時間がかかりそうや…。やっていることは何も難しくはないが設置座標や例外をいろいろ指定するのがなかなか大変で…。
後はここからプログラムでREBETなどの情報を拾ったりしていく。
15-10 BETとりんごの関係
BETとりんごの関係、つまり1BETでりんごの内部値がどれだけ上昇するか、などは明らかになっていないしこれを議論しているサイトもほとんどみたことない。
がしかし、3000BETを続けていると150000付近のワンダーチャンスになったりすることを考えると、平均的にBET額の7倍がりんごの内部値として適切ではないか、という考えを得る。
例えば100BETすると内部値は700付近で、内部値700は銅リンゴの範囲であるがたまにぶれて銀リンゴなどに変化する…というような事象を考えると、とりあえずは50%程度の分散があるものとしても良いような気がする。
分布の仕方はガウス分布が普通だが、これはウディタで実装するのはなかなかに面倒なので、最も簡単な一様分布で行うことにする。実は内部値は整数なので離散的ということから本当は分布とかいうわけにはいかないがそのあたりはゆるくいく。
そういうわけで、以下のようにBETによるりんごの発生を仮定する。
1BET→内部値3~11上昇
5BET→内部値15~55上昇
10BET→内部値30~110上昇
20BET→内部値60~220上昇
50BET→内部値200~500上昇
100BET→内部値400~900上昇
500BET→内部値3000~4000上昇
くらいにしておこうと思う。
これなら100BETで銅や銀が出て、200で銀や金Lv1が出る、という事象にもさほど矛盾していないと思う。がこちらが即席で作った適当な基準であるため、これが正しいとはまったく言い切っていないし検証も全然していないことに注意。
そしていよいよボタンの配置に取り掛かるが、REBETなどの効果も付与したいので
ボタンの配置には注意する必要がある。
REBETは前回に1BET以上のBETがあった場合に出現するので過去にBETした額を保存しておく必要がある。これが0のときのみ、0BETの状態で「1BET」のボタンが出現する。
BETされた後は1BETボタンがいつも出るのは周知の事実。そしてほかにも注意すべきことがあり、継続の判定やその扱い、ナインビンゴのBET制限など結構細かいところを津kるうとなるとそんなに簡単な話ではない。
あと継続とかのボタンも作らないといけないらしい。「はじめから」のボタンも含めて4種類。これらを作るだけでも結構時間がかかった。こうすることでようやくプログラムの作成を行うことができる。
がしかし、3000BETを続けていると150000付近のワンダーチャンスになったりすることを考えると、平均的にBET額の7倍がりんごの内部値として適切ではないか、という考えを得る。
例えば100BETすると内部値は700付近で、内部値700は銅リンゴの範囲であるがたまにぶれて銀リンゴなどに変化する…というような事象を考えると、とりあえずは50%程度の分散があるものとしても良いような気がする。
分布の仕方はガウス分布が普通だが、これはウディタで実装するのはなかなかに面倒なので、最も簡単な一様分布で行うことにする。実は内部値は整数なので離散的ということから本当は分布とかいうわけにはいかないがそのあたりはゆるくいく。
そういうわけで、以下のようにBETによるりんごの発生を仮定する。
1BET→内部値3~11上昇
5BET→内部値15~55上昇
10BET→内部値30~110上昇
20BET→内部値60~220上昇
50BET→内部値200~500上昇
100BET→内部値400~900上昇
500BET→内部値3000~4000上昇
くらいにしておこうと思う。
これなら100BETで銅や銀が出て、200で銀や金Lv1が出る、という事象にもさほど矛盾していないと思う。がこちらが即席で作った適当な基準であるため、これが正しいとはまったく言い切っていないし検証も全然していないことに注意。
そしていよいよボタンの配置に取り掛かるが、REBETなどの効果も付与したいので
ボタンの配置には注意する必要がある。
REBETは前回に1BET以上のBETがあった場合に出現するので過去にBETした額を保存しておく必要がある。これが0のときのみ、0BETの状態で「1BET」のボタンが出現する。
BETされた後は1BETボタンがいつも出るのは周知の事実。そしてほかにも注意すべきことがあり、継続の判定やその扱い、ナインビンゴのBET制限など結構細かいところを津kるうとなるとそんなに簡単な話ではない。
あと継続とかのボタンも作らないといけないらしい。「はじめから」のボタンも含めて4種類。これらを作るだけでも結構時間がかかった。こうすることでようやくプログラムの作成を行うことができる。
15-9 新フォント作成
以前から気づいていたが、アニマロッタには基本的に3つのフォントが使用されている。
まず、WINに関係する装飾のかなりついたフォント。そしてツリーの階数やハニーの個数など、あまり装飾されないちょっと細めのフォント。あとは普通にリーチや番号に関係するナンバーである。
そのうち、2つ目のものを1つ目のもので代用していたため、そろそろ新しくこの2つ目を作成しようかと思う。
そのために適したフォントを探っている。
すると「baloo」系のフォントがなかなか良い感じなのではないかと思った。
まず、WINに関係する装飾のかなりついたフォント。そしてツリーの階数やハニーの個数など、あまり装飾されないちょっと細めのフォント。あとは普通にリーチや番号に関係するナンバーである。
そのうち、2つ目のものを1つ目のもので代用していたため、そろそろ新しくこの2つ目を作成しようかと思う。
そのために適したフォントを探っている。
すると「baloo」系のフォントがなかなか良い感じなのではないかと思った。
これを利用してBETタイムのフォントの構築をしていく予定である。
まずは貼り付けて、ここからいろいろ加えていく。
15-8 BETタイム整備(1)
ふと思えばアニマロッタ系でこれぞと思えるような達成を残した記憶がない。
アニマ初代からすごくやっていた時代が何年かあったが、それでもビンゴガーデンは4ラインしないしアルティメットは獲得しないしドリームもキングも獲得しない。
…という愚痴はさておき、ここではBETタイムの作成を行っていく。ただ、これの作成はそこまで容易、というわけではなくそこそこ面倒。
ではどのように作成するのかを考えていく。一応超マルチですでにそのシステムは作ったが(90000+100*ゲーム数+61あたりのピクチャでBETボタンを描画)、ナインビンゴでは大きなまとまったタブの中に出てくるのでそもそも構造が違う、ということでまた白紙で考えることにした。
とりあえずまずはピクチャ100011としてあらかじめ切り抜いた大タブを張り付けよう…と思ったのだが、いろいろと加工が必要。ここからして時間がかかるという難点。
1枚目の画像を2枚目の画像に加工した。地道や。
アニマ初代からすごくやっていた時代が何年かあったが、それでもビンゴガーデンは4ラインしないしアルティメットは獲得しないしドリームもキングも獲得しない。
…という愚痴はさておき、ここではBETタイムの作成を行っていく。ただ、これの作成はそこまで容易、というわけではなくそこそこ面倒。
ではどのように作成するのかを考えていく。一応超マルチですでにそのシステムは作ったが(90000+100*ゲーム数+61あたりのピクチャでBETボタンを描画)、ナインビンゴでは大きなまとまったタブの中に出てくるのでそもそも構造が違う、ということでまた白紙で考えることにした。
とりあえずまずはピクチャ100011としてあらかじめ切り抜いた大タブを張り付けよう…と思ったのだが、いろいろと加工が必要。ここからして時間がかかるという難点。
1枚目の画像を2枚目の画像に加工した。地道や。
なんかこれだけで1時間くらいかかったような。その他のボタンの加工作業も含めて。
後は切り取ったり塗ったりして作ったボタン。次の記事以降ではこれらを利用してBETタイムを構築しようと思っている。
2019年11月16日土曜日
15-6 シンキングタイム一部実装
シンキングタイムのピクチャなどを準備し、それっぽいようになった…が実はバルーンを置けないし回せない。以前は回せていたが、配置座標の変更によるもの。
これらの処理はまああとでいいだろう…。
さてここからはハニーエイトとアニマツリーに連荘とフロアを記載する予定である。
これらの処理はまああとでいいだろう…。
15-5 BETタイムウェイト
BETタイムのカウントがちゃんと表示されるように。
ピクチャ番号は49~51を使用している。
なんかピクチャ番号をほぼメモしてないので半ば収拾がつかなくなっているのは誠に残念。ゲーム開始前に番号が表示されているのもいつかは修正予定。このあたりは特に難しい処理ではない。
次はシンキングタイムでのカウントダウンなどの処理を行い、そして次はハニーエイトとアニマツリーに現在の継続状況を表示することとする。
これらは超マルチでも対応できるようにあらかじめピクチャ10000~90000を使用するようにする。がしかしタブ表示に関わるピクチャの番号設定を忘れてもうて…。
まあ実際の画面で確認しながら探すと、
90000+100nを(nはnゲーム目という意味)始点としており、ビンゴバルーンは4ゲーム目なので開始は90400。
内訳をみると
90401~90410…リーチのその番号表示
90415~90420…配当確定時などの枠装飾とアニメーション
90421~90430…WIN数とその背景
90440~90450…リーチ、高額リーチ、超高額リーチなどの出現演出
90451~90475…りんごに関する表示
という具合で、次のピクチャは90500から上記のように入っていることを考えると
猶予のあるピクチャは90480~90499付近となる。
連荘数やフロア数とその背景なので、どちらもかならず2桁(ハニーエイト100連とかは絶対にないとみても良い。継続率はシミュレーションで確か6割くらいだったような記憶があるような気がするので、6/10を100乗したものの対数をとると100(Log6-Log10)=100*(0.7781-1)=100*(-0.2219)=-22.19というわけで10^(-23)に10^0.81、つまり6付近をかけているので、実際のところ確率は6*10^(-23)程度というわけでこれは0にしてええやろ。イメージとしては1兆分の1の確率を2回連続で当てるようなもの。
あっLogとしたのは「いち」と「エル」が見分けに杭からしただけであって、特にlogとLogを明確に区別したわけではない。
複素関数とかの話になるとLogという大文字Lには多価関数(1つの引数に対して複数の返り値を持つような関数。例えばarcsin0)の意味合いがついたりするとかどっかに聞いたことがあるので。もちろんLogは底を10としている。
そういうわけで、２桁を表示して後ろのもこもこやとげとげなので、ピクチャは90481~90483を使うことにした。
あっシンキングタイム中の移動可能を示すマークとかも必要なのでこれらは90484と90485あたりを使うことにするか…。
詳細な実装の画像などは次の記事で。
なんかピクチャ番号をほぼメモしてないので半ば収拾がつかなくなっているのは誠に残念。ゲーム開始前に番号が表示されているのもいつかは修正予定。このあたりは特に難しい処理ではない。
次はシンキングタイムでのカウントダウンなどの処理を行い、そして次はハニーエイトとアニマツリーに現在の継続状況を表示することとする。
これらは超マルチでも対応できるようにあらかじめピクチャ10000~90000を使用するようにする。がしかしタブ表示に関わるピクチャの番号設定を忘れてもうて…。
まあ実際の画面で確認しながら探すと、
90000+100nを(nはnゲーム目という意味)始点としており、ビンゴバルーンは4ゲーム目なので開始は90400。
内訳をみると
90401~90410…リーチのその番号表示
90415~90420…配当確定時などの枠装飾とアニメーション
90421~90430…WIN数とその背景
90440~90450…リーチ、高額リーチ、超高額リーチなどの出現演出
90451~90475…りんごに関する表示
という具合で、次のピクチャは90500から上記のように入っていることを考えると
猶予のあるピクチャは90480~90499付近となる。
連荘数やフロア数とその背景なので、どちらもかならず2桁(ハニーエイト100連とかは絶対にないとみても良い。継続率はシミュレーションで確か6割くらいだったような記憶があるような気がするので、6/10を100乗したものの対数をとると100(Log6-Log10)=100*(0.7781-1)=100*(-0.2219)=-22.19というわけで10^(-23)に10^0.81、つまり6付近をかけているので、実際のところ確率は6*10^(-23)程度というわけでこれは0にしてええやろ。イメージとしては1兆分の1の確率を2回連続で当てるようなもの。
あっLogとしたのは「いち」と「エル」が見分けに杭からしただけであって、特にlogとLogを明確に区別したわけではない。
複素関数とかの話になるとLogという大文字Lには多価関数(1つの引数に対して複数の返り値を持つような関数。例えばarcsin0)の意味合いがついたりするとかどっかに聞いたことがあるので。もちろんLogは底を10としている。
そういうわけで、２桁を表示して後ろのもこもこやとげとげなので、ピクチャは90481~90483を使うことにした。
あっシンキングタイム中の移動可能を示すマークとかも必要なのでこれらは90484と90485あたりを使うことにするか…。
詳細な実装の画像などは次の記事で。
2019年11月15日金曜日
15-4 アニマツリー修正
修正点は以下。
1,ツリー上昇時に全部配当獲得フロア扱いになる(演出の問題で、配当などには影響なし)
2,看板内のフロア数が表示されていない
修正前↓
これは調べてみると、コモンイベント539に問題があり、これから上昇するフロアが例えば2の場合は真ん中のフロア(画像では16,19,21,24があるところ)を配当フロアとして描画してから、y座標240推移する、というプログラムだったので、これは変更しなければならない。
フロアの更新は、相対的な上昇階数だけでなく、現在の初期からの上昇階数に依存する。
そして後細かいこととして、上の画像なら5Fが見えた時に一瞬、欠けた表示になるのも修正。これはある場合分けを抜かしていることが原因。
たぶんわかりづらい文章だとは思うが…。
なお、5Fは確実に配当フロアなため、先ほどまで行ってきた引数を必要としないので修正は楽。
修正後↓
あとはこのフロアの数字などにもうちょっと装飾をつけたいと思っている。
加えて、たぶんこの感じだと30Fとかの幕も危険な香りがするのでたぶん修正が必要。
まもなく講義なのでここで休憩。
1,ツリー上昇時に全部配当獲得フロア扱いになる(演出の問題で、配当などには影響なし)
2,看板内のフロア数が表示されていない
修正前↓
フロアの更新は、相対的な上昇階数だけでなく、現在の初期からの上昇階数に依存する。
そして後細かいこととして、上の画像なら5Fが見えた時に一瞬、欠けた表示になるのも修正。これはある場合分けを抜かしていることが原因。
たぶんわかりづらい文章だとは思うが…。
なお、5Fは確実に配当フロアなため、先ほどまで行ってきた引数を必要としないので修正は楽。
修正後↓
加えて、たぶんこの感じだと30Fとかの幕も危険な香りがするのでたぶん修正が必要。
まもなく講義なのでここで休憩。
15-3 シーン推移
ここでは、次ゲームに移行するときの処理を作っていこうと思う。
まずは自分でシーン推移に関するそれっぽい画像を作る。
後はこれが画面左側から流れてきて、そして去っていくという流れになる。
なおこの際、ゲーム画面が明転して、この青い帯の背景には不動の星が発生する。
あとロゴ。
いや本当はもうちょっといい感じのものを作りたかったが、素材等がないのでしょうがない。
お手製のものだというのがわかるだろう。星とかはペイントで描いたし、何気に黄色の星の塗り忘れがあるという…。
ロゴはなかったのでもともとのアニマロッタのロゴを移動させたり削ったりして無理やり作った。
これによりゲームの更新がまあまあな見た目になったので、ちょっと満足した。
なおこのシーン転換中に様々な変数(数万個)とピクチャ(約100000個)のリセットを行っている。
次はアニマツリーの整備を行う。
追記:そういえばなんの法則かは知らないが、このシーン推移は各アニマロッタナンバリングで異なった気がする。右斜め上からしゅっと来るのが４とかで、ほかには円が縮小したりとかいろいろ。
またこのシーン推移、青色と緑色と赤色があるらしい。どういう条件で変化するかは不明。
まずは自分でシーン推移に関するそれっぽい画像を作る。
なおこの際、ゲーム画面が明転して、この青い帯の背景には不動の星が発生する。
あとロゴ。
お手製のものだというのがわかるだろう。星とかはペイントで描いたし、何気に黄色の星の塗り忘れがあるという…。
ロゴはなかったのでもともとのアニマロッタのロゴを移動させたり削ったりして無理やり作った。
これによりゲームの更新がまあまあな見た目になったので、ちょっと満足した。
なおこのシーン転換中に様々な変数(数万個)とピクチャ(約100000個)のリセットを行っている。
次はアニマツリーの整備を行う。
追記:そういえばなんの法則かは知らないが、このシーン推移は各アニマロッタナンバリングで異なった気がする。右斜め上からしゅっと来るのが４とかで、ほかには円が縮小したりとかいろいろ。
またこのシーン推移、青色と緑色と赤色があるらしい。どういう条件で変化するかは不明。
2019年11月3日日曜日
15-2 アニマロッタのタッチスクリーンについて
なぜかアニマロッタのタッチスクリーンとかいう検索ワードがあったのでこれについてちょっと考えてみる。
経験則から言うと、何かしらの信号などで触れている情報を得て、それでボタンなどの制御を行っていると思われる。自作アニマロッタの場合は、当然PCなのでタッチ等ができないのでクリックで代用している。
なお、2か所タッチした場合はその間が反応することから、これはおそらく2か所以上の場合は重心を取っているものであろうと思われる。
例えば画面左上、右上、左下の3か所をタッチすれば重心の定義から画面を3*3等分したときの左上1区画の右下の点を指すはず。実際にやっていないが。
上記に加えて右下もタッチすればたぶん画面の中心点となる。
でこれが何に役立つかというと全然役立たない。
ただこのタッチパネルの困る点として、なぜか店によってはその設定がずれていることがあり(主に横方向のずれが多い)、BET時やメニュー時に誤爆することがあるのが問題。あと強くタッチしなければ反応しないものもあるなど、結構プレイに支障をきたすレベル。
したがって同時にBETボタンを押してメダル100枚で100BET×2ができるのではないかとやり方は通用しないっぽい。
経験則から言うと、何かしらの信号などで触れている情報を得て、それでボタンなどの制御を行っていると思われる。自作アニマロッタの場合は、当然PCなのでタッチ等ができないのでクリックで代用している。
なお、2か所タッチした場合はその間が反応することから、これはおそらく2か所以上の場合は重心を取っているものであろうと思われる。
例えば画面左上、右上、左下の3か所をタッチすれば重心の定義から画面を3*3等分したときの左上1区画の右下の点を指すはず。実際にやっていないが。
上記に加えて右下もタッチすればたぶん画面の中心点となる。
でこれが何に役立つかというと全然役立たない。
ただこのタッチパネルの困る点として、なぜか店によってはその設定がずれていることがあり(主に横方向のずれが多い)、BET時やメニュー時に誤爆することがあるのが問題。あと強くタッチしなければ反応しないものもあるなど、結構プレイに支障をきたすレベル。
したがって同時にBETボタンを押してメダル100枚で100BET×2ができるのではないかとやり方は通用しないっぽい。
登録:
投稿 (Atom)