![]() |
本帖最后由 SailCat 于 2020-11-29 12:17 编辑 在早期的红白机直到PS2次世代的主机游戏中,几乎所有的随机数都是通过预置的“随机数表”来实现的 随机数表在FC、SFC上一般体现为一个随机打乱的256长度的表格(也可能更短),它覆盖了00-FF的所有数字,只是顺序有点错乱 一个典型的随机数表例如: [0xB7, 0x97, 0x3A, 0x46, 0xBA, 0x86, 0x0C, 0xBF, 0xA3, 0xF1, 0xE0, 0x1C, 0x5F, 0x93, 0xF8, 0x94, 0x9F, 0x9A, 0xA1, 0x8E, 0x69, 0xE6, 0x92, 0xA5, 0x8D, 0x47, 0x8C, 0x54, 0x51, 0xEC, 0x79, 0x10, 0x4C, 0x0D, 0x87, 0xCD, 0x56, 0x2F, 0xF0, 0xEE, 0x31, 0xD1, 0x09, 0x8B, 0x07, 0x9C, 0xE4, 0x36, 0xB6, 0x35, 0x4B, 0xF4, 0xAB, 0xC2, 0x11, 0x33, 0xE5, 0x0E, 0x82, 0xC4, 0x55, 0x20, 0xD3, 0x23, 0x85, 0x7F, 0x9D, 0x4E, 0x19, 0x06, 0xB1, 0x39, 0x0A, 0xA2, 0x34, 0xBD, 0xE7, 0x03, 0x02, 0x2E, 0xB0, 0xB4, 0x22, 0xFC, 0x42, 0x4A, 0xE9, 0xDF, 0xC3, 0xBE, 0x2A, 0xDB, 0x62, 0xA0, 0xA6, 0x6F, 0x12, 0x91, 0x98, 0x3E, 0x6C, 0x66, 0xAC, 0xBB, 0xF9, 0x44, 0xF5, 0xC5, 0x27, 0xC9, 0xA8, 0x52, 0xED, 0x14, 0x6D, 0xEB, 0x1B, 0xD4, 0x80, 0x5B, 0xB2, 0x5C, 0x28, 0x4F, 0xDD, 0x99, 0xCB, 0x59, 0xC6, 0xB5, 0x0F, 0x45, 0xE8, 0xD8, 0x2C, 0x24, 0xD7, 0xC7, 0x43, 0x1F, 0x72, 0xEF, 0xE3, 0x5A, 0xD9, 0x2B, 0x96, 0xEA, 0x2D, 0x57, 0x16, 0x70, 0x9E, 0x5D, 0x04, 0x3B, 0x7B, 0x63, 0x5E, 0xA7, 0x1A, 0x17, 0xCC, 0x65, 0x67, 0xFD, 0x7E, 0xDA, 0x15, 0x58, 0x53, 0x38, 0x60, 0x21, 0x6B, 0x7C, 0x40, 0xCA, 0x81, 0x73, 0xC0, 0x41, 0x68, 0xDE, 0x00, 0xAF, 0x08, 0x3F, 0xF2, 0x1E, 0xDC, 0xCE, 0xB8, 0x75, 0x25, 0x05, 0xD5, 0x7A, 0xCF, 0xE2, 0x78, 0x18, 0x30, 0x29, 0x74, 0x32, 0x8A, 0x1D, 0xC8, 0x89, 0xFB, 0xF3, 0xFE, 0xD2, 0xA4, 0x26, 0x3C, 0xAA, 0x77, 0x6E, 0x88, 0xF7, 0x50, 0xB9, 0xA9, 0x13, 0xB3, 0xAD, 0x61, 0x90, 0x64, 0x84, 0x9B, 0x8F, 0xD6, 0x95, 0xE1, 0xFF, 0x83, 0x0B, 0x7D, 0x49, 0x37, 0xFA, 0xD0, 0xF6, 0xC1, 0xAE, 0x3D, 0x6A, 0x71, 0xBC, 0x76, 0x01, 0x48, 0x4D] 因为内存有限,FC上的许多游戏甚至只有几KB的数据量,能用0.25KB来放一个随机数已经很不容易了。因此游戏中的所有机制,但凡调用到随机数,都是从这个表里按指针来获取。 由于表只有一个写死了,FC又没有机内时钟且可以随时reset,就导致了出现了鼎鼎大名的“电源技”——即通过电源reset使得随机数指针回到开头,然后加载你的进度,只要分析汇编拿到内存中的表,并且知道哪些操作会调用随机数,调用几个,所有的随机数都是有章可循的。 FF1(最终幻想1)可以通过这个方法用1/201的机率杀掉最终boss——只要在最终boss前存档,再reset读档后,并且使用特定的攻击方式进行攻击即可。当然这个原因是因为FF1的程序逻辑本身有问题,随机数取到00会通过任何几率判定。 这个用随机数表的做法一直延续到了次世代的PS2,只是随机数表从写死在ROM里逐渐变成按电源即时生成(故此电源技依然一直有效),表也会有不止一个。 到了后来,才逐渐变成了采用随机数种子、即时生成随机数,不再查表的方式。 尽管遍历一个乱数表可以比较大程度的解决连续生成同一个数的问题,但当所需要的随机数并不是处于0-255的范围时,通过位运算进行限格的结果依然无法保证机率平均。 以上表其中一行为例: 0x40, 0xCA, 0x81, 0x73, 0xC0, 0x41, 0x68, 0xDE, 0x00, 0xAF, 0x08, 0x3F, 0xF2, 0x1E, 0xDC, 0xCE 如果需要的随机数只是0-7的范围,即对上面的数全部取&8的处理,结果是 0,2,1,3,0,1,0,6,0,7,0,7,2,6,4,6 可以看到,0出现了很多很多次,而5没有出现。 这种所谓的短期集中情况,其实是无解的,不论你用什么办法,比如空指针(取一个跳一个)或者其他办法,都解决不了,上表的取1跳1结果是 0 1 0 0 0 0 2 4 3 5 6 7都没有,0出现5次,随机个屁 想要解决这个问题,除了按你的取数周期和大小生成shuffle表之外,无任何其他解。但就算是如此,就属于你想要的随机了吗? 要知道,随机,随机,重点在于其不可预知和每件事互相独立的特性。某人抛硬币连续20次正面之后,下一次正面的结果依然是49.97%(反面49.97%,直立0.06%)。但如果生成了一个随机数,你就知道下面100%不会再生成同样的一个数,那这不叫真随机,这叫可以预知。尽管有些反直觉,但确实如此。 但随机数种子+即时生成随机数,内部依然是各种求余、移位和哈希算法,只要知道了种子和算法,所有的序列都是可以推定的,这依然不是真随机,而是伪随机。 为什么几乎所有语言,原生随机数都是0-1之间的数,且含0不含1? 原因是,随机数的哈希算法实际上是都是位运算,比如16位的哈希结果会在0b0000000000000000到0b1111111111111111(0~65535)之间。 但是第一,65535这个数字只有1、3、15、17、255、257、3855、4369、21845这9个约数,它不能被大多数你想要的随机范围整除。如果你用求余来进行随机范围处理,是没有办法保证机率均匀的(例如余以100,那0-35的机率会显著比36-99来得大)。 第二,0b1111111111111111不一定会被解释为65535,也可以是-1,而负数随机数对于大多数机率判定就是灾难了。 因此,语言的做法就是将其转换为浮点数,而根据大多数CPU的解释,这只需要解释为在最前面加一个小数点就行。 而在最前面加一个小数点,其结果就成了0b0.0000000000000000到0b0.1111111111111111之间。 前者是0.0,后者是多少呢,准确来说是0.9999847412109375。 由于所有浮点数乘法的原生取整算法都是向下取整,而后面这个数乘以50000之后依然高达49999.2,因此,16位浮点伪随机数在值域范围内,已经足以应付1~50000中任何一个机率区间的(长期均匀)随机性。 |
随机数算法应该不会有那么大的问题吧。。 拿python试了一下, ![]() 确实会有一些偏差非常大的情况。可以考虑的方法是用shuffle打乱一个数组然后存储作为备用数。 但是是不是随机没啥需要讨论的。毫无疑问常见的语言都应该有一个设计得还行的随机器。然而随机器一个重要的要求是任意两次抽数的概率几乎是独立的,所以连续抽多个数,里面某个数出现n次的概率几乎是个二项分布。但如果从需求来看二项分布的概率还是太高了。所以如果你要求这种抽到一个数多次的概率很低,一般算法的随机器是没有这个功能要求的。 我想得到的解决方法有两个: 一是按我上面说的,在需要多次抽数时,生成一个长度至少超过你需要的类数的2~3倍的数组,用随机方法打乱数组(具体算法我就不知道了,python有这个函数可以参考),抽数时按顺序抽,用完了在生成。这样连续抽到2~3次以上某个数的概率被严格限制为0(除非你真到了第一个数组用完了又继续用第二个数组的时候有连续抽到4~6个数的概率,那只能说你赢了)。这种方法可以遍历数组,并且不怎么重复。能想到的隐患就是存储的数据可能会被恶意篡改。 二是用其他的特殊的随机算法。比如线性同余法使用迭代来计算下一个概率,你可以想得到,这种迭代算法一定有个周期,并且只有间隔一个周期时两个数才会重复。然而如果你自己写的话很可能会写出极为Naiive的算法,比起调用别人的函数还是差了一点。 |
本帖最后由 灯笼菜刀王 于 2020-11-27 16:01 编辑 没错,很早以前我就在纠结这个了, 实际上也得到很多人的指导 虽然各种随机方式可以均衡1000次1W次的样本, 然而,实际应用中难免要面对"某个阶段随机实在太接近"这种"很唯心"的结果,笑 其实, 哪怕像福利彩票那样的乒乓球现场摇点都难免出现连续的情况, 觉得"不够随机"也只是小样品范围内的结果而已,如果不想这样,就像你说的, 抽到两个接近的话就再抽一次之类的也是一种方法呗 这也是我采用"先打乱样品顺序,再随机抽一个出来"这种让人家说没太多意义的做法的原因,------"让自己安心点" ![]() --------------- 说个故事, 我曾经做了一个"武器破损率"的系统, 攻击敌人的时候有概率让武器损坏, 一开始是直接用 rand(100) < 损坏率 来判定的, 结果测试的时候, 3%的概率,理论上33次才会破损一次的概率, 让某个黑旋风连续破三把...., 于是,把随机样本增加一万倍,重置随机种子,增加随机节点, 更换随机位置........ 结果, 那个黑旋风还是一样, 连续坏给你看 因此,我知道了, 这原因根本就不是样本多少, 而是脸 ![]() 再怎么均衡的随机也扛不住黑旋风例亏或白面郎君整天受 ![]() 所以, 现在改成了, 不直接消失而是先出现(损坏)的后缀, 然后在损坏判定生效的同时增加一个保护回合, 避免黑得透亮的家伙...... ![]() |
本帖最后由 ppspssss 于 2020-11-27 11:33 编辑 https://rpg.blue/thread-406406-1-1.html 印像中@灯笼菜刀王 老师 說过这个問題 我记得以前电脑老师说过所有电脑随机值都是伪随机, 没有真随机, 不知有没记错 为什么电脑能抽随机数,这个问题确实难想,毕竟不会凭空生成随机值? 看随机数抽取的原理,老师举过例比如自制小装置 6个小灯轮换,通过不同时间断点, 停下的灯就是随机的值, 那时间相近, 抽取的值我就不知道了 , 不过难免有些情况要同一帧抽多个元素, 比如初始化卡组, 十连抽 举例网游中的抽卡那些 , 确实依然是伪随机, 是有规律 , 我发现比如接近同一时间内抽取出的角色比较接近 , 一些网游戏是这样 , 抽过卡肯定有这种感觉 有时抽好多都不出, 有时有人连抽几个好东西, 除了人为改动公式, 比如 如果抽到相近的数字则触发再抽一次, 当然很多人为操纵因素就不算了 , 被套路了也不知道 |
本帖最后由 phunmung5173 于 2020-11-27 15:34 编辑 不确定RM的底层逻辑。但是电脑其实是没有办法自己随便生成一堆数字的,它必须依赖一个根 (root) 并以其为基础生成乱数。如果每次使用的根是一样的,那么每次出来的结果都会是一样的。 最常见的解决方法是取得电脑的时钟时间,毕竟不太可能每次开游戏都是同一小时同一秒,这样某种意义上就实现了所谓的 「真乱数」 游戏设计方面,真乱数并不适合用在会影响游戏核心体验的地方。 这样设计会严重影响游戏体验,现实生活因为不可控所以常常会感到无力感,难不成来到游戏世界还要体验这种无力感吗? —————————————————————————————————————————————————————————————————————————— 补充: 还有一种机制叫 Pseudorandom number (伪随机数) 例如虽然告诉玩家A卡的掉落几率是10% , 但是实际计算内每一次抽不中A的时候就提升A的几率,并重置已经抽中的卡的掉落几率。 可以有效的减少卡牌掉落的重复性,抽不到想要的卡,多抽几次总会出来。 |
因为这个随机和老虎机类似吧 有特定的算法可以算出来在什么时候会出现什么结果 |
正好最近在做抽卡游戏,一开始做1~100随机抽数字,有一次连续抽到3个33↓![]() 惊得我都截图了(x) 要说这个概率是小得很,但纯随机就是这样吧~概率再小运气到了都能给你弄出来XD |
这是一段随机测试代码, randomTest(10,10000000);大致数据都在 10%,所以在大样本测试下...随机是均衡的, 但是这种测试可能存在,某段时间重复出现某个区间值,这就像运气差的时候各种非酋,运气好的时候,各种欧皇 |
站长信箱:[email protected]|手机版|小黑屋|无图版|Project1游戏制作
GMT+8, 2025-5-19 12:31
Powered by Discuz! X3.1
© 2001-2013 Comsenz Inc.