从STG录像回放到随机数生成

Sonicthedgehog

来晚了……

想说的什么东西还是说一下吧。
那么我来总结一下！
一开始在说STG游戏的录像功能怎么实现。
为此我还特意下了th14随便打了个一面看看录像文件多大。

11KB。真是够小的。不过也是正常吧。

一个正常的录像文件应该包含以下信息才能确保在播放时能还原玩家玩游戏时的场景等等。
>录像文件本身的文件信息：如录像文件标识，文件大小等等。
>录像的基本信息：如播放时间，玩家角色，使用配装，落率什么的。
>录像真正的回放信息。

前两个部分都算是实现中比较简单的，不多赘述。
录像文件真正的大小取决于回放信息的算法、实现和存贮方法。

★于是为了缩小rpy文件的大小我们很容易可以想到只要记录玩家的操作即可，即记录那个按键什么时候按下松开。
这样的话就可以十分精确的还原原玩家在玩耍时发生的一切了。只需要按照记录的键位在程序内重演一遍即可，关卡什么的完全按照游戏内正常的载入方式载入。

于是几个比较关键的问题出现啦！（可能大家没有细说的我也算上了）
1.如何精确计时？
2.如果有随机弹幕怎么办？
3.播放时如何同步？

好哒！个人见解说明时间到！
1.关于精确计时，个人认为多线程是不可取的。想要同步记录些什么的话我是比较偏向直接吧记录这个过程加在按键判定里边的，这样一次判定必定同时记录当时的时间信息和按键，同时也会把作用按键反馈给游戏主进程。然后就是记录，可以记录按键按下和松开这两个事件，后边加上对应的按键编号和触发时间即可。
再有，关于时间的记录，我有两种方法。其一就是把（当前系统的毫秒时间-释放给用户控制的系统毫秒时间）计为触发时机。其二就是把当前第x帧作为触发时机。因为我并不确定TH系列中游戏的时间机制——到底是按照系统时间推进时间还是按照每帧逐步推进时间，所以两种方法用起来都有风险。我比较迷糊没想出什么对策。欢迎补充呐
2.关于随机弹幕。前边也说了，我比较喜欢的方法是先写好一种生成弹幕的随机方法，这种随机方法的随机原理是对一个种子进行复杂运算得出一个伪随机数（弱弱的比如0.5*sin(timeGetTime())+0.5可以生成一个值域在(0,1)的伪随机数←你没看错不是[0,1]），当做生成弹幕的参数。进入游戏时就记录好这个种子，存录像的时候也存进去即可。再看再读取。
3.关于同步播放，我不确定双线程是否可以，因为按照逻辑推测没推测出什么来。不过还是推荐单线程，稳定，易编写。而且播放的同步性也取决于1中所说的时间点的记录方法（两个）。


OK，最后我就不再说什么存档里边再用数据压缩的事情了……写不下去啦啦啦啦啦我要去玩……

tryourbreast

隨機數的話曾經看到一個可用在圖像渲染中的隨機數生成方法,代碼是這樣的:

float random( vec2 p )
{
  // We need irrationals for pseudo randomness.
  // Most (all?) known transcendental numbers will (generally) work.
  const vec2 r = vec2(
    23.1406926327792690,  // e^pi (Gelfond's constant)
     2.6651441426902251); // 2^sqrt(2) (Gelfond–Schneider constant)
  return fract( cos( mod( 123456789., 1e-7 + 256. * dot(p,r) ) ) );  
}

// (p的取值是(0,0)至(1,1))

簡單來說就是把一個大數除以超越數的乘積,然後取餘數,然後餘下的餘數就應該很隨機了

不過,這個方法是渲染那邊的人不想用隨機材質生成在屏幕各點隨機的數值想出來的,不知道在傳統代碼裡的可行性(

苏我爱丽丝

一直很好奇呢，关于REP回放的随机弹生成重现问题QAQ