あるゲームでは乱数による判定をロード時から現在までに
カウントしたフレームの数で決めているらしい。
ツクールXPの場合で言えば 0 から 99 までの乱数を取得する際に
Graphic.frame_count ％ 100と書くようなものだ。
もちろん繰り返し処理中などで用いることはできないが
それ以外では十分な均等性を確保できる。
乱数取得ならちゃんと専用の関数があるので
無理に使う必要はないかも知れないが。
カウントしたフレームの数で決めているらしい。
ツクールXPの場合で言えば 0 から 99 までの乱数を取得する際に
Graphic.frame_count ％ 100と書くようなものだ。
もちろん繰り返し処理中などで用いることはできないが
それ以外では十分な均等性を確保できる。
乱数取得ならちゃんと専用の関数があるので
無理に使う必要はないかも知れないが。
コメント
いつもこちら、参考にさせてもらってます。
乱数には以前から研究対象として作業しています。
デフォルト状態の"rand"は使い勝手がいいので、
よく使いますが、
仮にリプレイ機能を搭載した作品を作る際は、
それらのデータ(乱数で取得した結果)を全て記録するのは
膨大で、また色々困難な事も出てきます。
そこで考えたのが、
最初に"rand"で出した値を基にして、
乱数を要求する毎に
そのタイミングと求められた幅から
乱数を生成して返すというものです。
使うたびに基の値も(規則的に)変わります。
これなら記録する必要のあるデータが
基本的には最初の値だけで済み、
同じフレーム内であっても何度も使えます。
但しこれは一定間隔かつ同じ幅を求め続けられる様な
システムには不向きかもしれません。
リプレイに限らず使い道は多いにあると思います。
実際に使ってもいます。
検証結果からも乱数がほぼ同じ確率で
生成できている事を確認できています。
改良すべきところは今のところ見当たりませんが
一応まだ未完成としています。
この乱数生成のスクリプトは、
各々のゲームにあわせた仕様にしているので、
汎用性はあまりありませんが。
コメントありがとうございます。
なるほど、リプレイ機能というのは今まで
考えたことはありませんでした。
確かに完璧に再現できなければ機能として成立しませんからね。
乱数生成用の関数は汎用性は高いですが
各々のゲームにとって最適な乱数を生成しようとするなら
個別に作ったほうがいいかも知れませんね。