ゲームの進展状況17 ボタンを作る

よくあるやつ。マウスでクリックすると、ボタンが押された判定になって…というやつ。
意外に簡単そうな話…だが、実はこれが意外とくせもので、完成までにたぶん20分くらいはかかると思う。

ウディタではマウスの位置のX,Y座標と、クリック「されている」かどうかを判定するものがある。
なので、クリックしたという、いわゆるクリック状態がONからOFFに切り替わった瞬間、というものを取得しなければならない。なんとなく微分の話に似ている…?

さて、そのためにまずはボタンが押された、とは何なのかを定義する必要がある。
ボタンを押す、ということは、
そのボタン(ピクチャ)内でマウスをクリックし、そしてその範囲内でマウスのクリック状態を解いた時、あるいはボタン外でクリックしてそしてボタンの範囲内でマウスのクリックを解いた、というような状態がしっくりくる。
要するに、重要なのはボタン(ピクチャ)の範囲内でマウスのクリックが解かれた、ということである。
それにのっとり、いろいろとやってこれを実現。

(実をいうと後ろの条件は範囲外で押されたときに何かのフラグを立てて、そして範囲内に入ってのクリックの維持、というものを防げばよいはず)

さて、これでBET切り替えができるようになった。
続いては各BETボタンを押すことにより、BET額が増加していき、「りんご」の価値が上昇していく、というのを考えることになる。

しかしここで、どうやってBETと「りんご」の価値を対応させるか、というところ。
本物のアニマロッタなどでは、かなりBETによってばらつきがある。
1BETで乱数を生成させて、50%の確率で「りんご」の価値アップ、とすると、低ベットならば差がついていいが、ご存知の通りこの場合ハイベットでは試行回数の増加により確率が収束する可能性が極めて高い。
たとえば1BETで0か1、リンゴの価値がアップするとすると、3BETならせいぜい0が1/8で1が3/8で2が3/8、そして3が1/8とまあまあばらつくが、100BETともなると、計算すれば分かると思うがほとんど50付近に一気にかたよってくるはず。たとえば40、を考えると、100回中1/2が40回起こる反復試行、ととらえて100C40(1/2)^40(1/2)^60を考えることになる。…つまり0.01084…となり、
もはやちょっと50から2割ずれただけでもわずか1%。
いうなればほとんどの確率で40~60以内に収まってしまう、ということになり、
これではBETによるリンゴの多様性を図ることはできない。
なので、それぞれ1,5,10,20,50などBETでの加算ごとに、異なる価値アップのテーブルを用意しなければいけないことになる。

だがまあ、「りんご」の実装は別に急ぐことでもないので、あとまわしで十分。まずはBETシステムを完成させて、ユーザーがBET額を指定してゲームをループさせる、ということができれば、一通りゲームシステムがとりあえず完成したことになる。