» 您尚未登录:请 登录 | 注册 | 标签 | 帮助 | 小黑屋 |


发新话题
打印

[其他] 突然想到了halo3回放模式的一个问题

看完这贴,恍然大悟鸟。


TOP

引用:
原帖由 大头木 于 2007-9-27 16:27 发表


只记录动作就行了啊,要是真的把所有信息,坐标等都记录下来,那想慢放,想回放不就可以实现了。
记录动作的话信息量不会少,要记录方向,速度,质量等等问题。



TOP

引用:
原帖由 枉凝眉 于 2007-9-27 16:32 发表
晕,记住物体实时的坐标干什么
只要记住所有物体的指令坐标,在哪个时间点发出什么样的指令,剩下的让机器自己运算出来了
好比让主角从a点到b点跑了一条直线,录像只要记住指定的起始时间、指令的具体内容就行 ...
游戏里的物件不是一个孤立的存在,不像做Flash,制定轨迹就可以了,如果记录轨迹的话,还要记录物件之间的交互,记录量会更加的大。

目前大部分的游戏录像,包括SC,Halo3,几乎所有的模拟器,都是记录玩家的输入序列和机器初始状态,然后重新“玩”了一次游戏,就这么简单而已。


TOP

引用:
原帖由 xphi 于 2007-9-27 16:46 发表


游戏里的物件不是一个孤立的存在,不像做Flash,制定轨迹就可以了,如果记录轨迹的话,还要记录物件之间的交互,记录量会更加的大。

目前大部分的游戏录像,包括SC,Halo3,几乎所有的模拟器,都是记录玩 ...
记录物件之间的交互做什么?交互的规则是游戏中早就有了,重新调用这个规则不就行了?

现在的sc、cs录像,无非都是记录指令与时间的关系,交互的规则已经包含在游戏程序里了,根据指令的结果重新运行出交互的规则就可以了

TOP

我晕,都扯哪里去了,回放个录像都能扯飞了,还搞到随机去了

从图形学上看,你只是回放录像的话,只需要把渲染的命令存贮下来,回放的时候直接让引擎再渲染一遍就好了,哪那么麻烦,还要计算AI。。。那些都是已经决定了的东西

不能后退的原因是。。。那是现渲染,不是播视频文件,哪个听说过代码可以倒过来执行的
(没玩HALO3,推测,如有误差见谅)

TOP

SC,模拟器的录像文件都是可以拿来看的,不相信的人自己去分析一下录像文件就完了么,我没兴趣再去和考猜来思考问题的人讨论了。

TOP

引用:
原帖由 枉凝眉 于 2007-9-27 16:32 发表
晕,记住物体实时的坐标干什么
只要记住所有物体的指令坐标,在哪个时间点发出什么样的指令,剩下的让机器自己运算出来了
好比让主角从a点到b点跑了一条直线,录像只要记住指定的起始时间、指令的具体内容就行 ...
这样做法会产生物体运动不同步的误差,一个例子就是录像以正常游戏视角和用户观赏视角来观看会导致帧数不一致,帧数不一致会导致物体运动加快或变慢而产生时间误差。这种误差不能通过跳帧来修正,因为跳帧本身也产生误差。动作游戏中这类误差会累积的非常快,这样后果就是录像播到中后期会出现很滑稽的画面。所以基于时间轴记录物体的状态永远要比记录指令要精确的多,数据耗费也多得多。
所以现在流行的做法是状态采样,在一个短的时间间隔里对状态采一次样,采样点之间的状态由机器实时运算,这样做数据量较少而误差也可控

TOP

看完都晕了,我总结一下吧,通俗的,比如在游戏的过程中我按手柄1秒向前走3然后射,这时电脑根据算法算出怪物当时难度的最佳反应,比如怪后退3然后回射,录像文件仅记录了我的初始地点—>向前3—>射,怪的初始地点—>后退3—>回射,并不会记录任何ai或任何控制器输入,也不会在后期渲染的时候再计算什么,只记录了得到的结果,所以这个过程是连续的,不可以从中间某步骤开始,以上是我的理解

TOP

错了,电脑只会记忆你的初始地点,向前3,射,怪的反应是计算出来的

TOP

其实不就一录像嘛!其实不就是一即时预渲染的cg片头嘛!什么事都没有!你们继续忽悠吧!

TOP

有这么复杂嘛?

只要完全记录随机数生成程序的入力,这个随机数就是个定数,无论输入多少遍出来的都是唯一值

和电脑交互的就只是玩家的入力,AI这些都是算出来的阿...

[ 本帖最后由 Ashley 于 2007-9-27 17:33 编辑 ]

TOP

引用:
原帖由 hudihutian 于 2007-9-27 17:26 发表
错了,电脑只会记忆你的初始地点,向前3,射,怪的反应是计算出来的
也有可能,但是如果回放速度是2倍呢,那岂不马上三红?或者是隔帧渲染?我觉得只记录结果会更省资源,回放可以做的更漂亮
我举个只记录输入,回放的时候即时计算物理和ai失败的典型例子吧,xb时代的rsc2,如果游戏的时候发生坠落峡谷的情况,看回放的时候就会会出现车辆乱走,我认为那就是因为回放文件只记录了控制器输入,而回放时的物理反馈和游戏时候有差别

TOP

引用:
原帖由 xphi 于 2007-9-27 16:25 发表


3维空间中位置坐标需要x,y,z 3个值,方向向量也需要x,y,z三个值。还仅仅是位置方向。
引用:
原帖由 xphi 于 2007-9-27 16:19 发表


这个计算太奇怪了,一般来讲,记录一个物件的位置,方向,需要六个座标值,这个值就是你这里计算的35K的3倍,算是100K吧,如果场景中有1000个物件的话,就需要100M,每分钟100M,还仅仅只是位置信息……。
首先申明,我前面已经提到HALO的录像是存储操作信息和AI取值。这样的优点是数据非常小,缺点是不能自由取段播放和倒放。

其次,我也很蛋痛,希望证明录像通过完全记录时间轴上的路径位置和状态数据的方式,虽然数据量会多很多,但也不是完全不现实的。

首先地图是多大?

很显然,地图坐标大小和画面分辨率毫无关系,HALO也不是一个像素级别移动的游戏。
你前面提到地图取值达到1百万*1百万,并没有提到场景的高度,我理解为是一个纯平面的场面,才导致前面的算法并未加上Z轴,而且这个1百万也太不严谨。

我们重新假设来场景的地图取值。
假设场景为1平方公里见方,高100M的空间。地图最小移动尺度为2cm.
那么地图单位就为50000*50000*5000。
这里可以使用一个优化算法,就是把整个地图平均分成(ABCD)等16个区,那么每个区的坐标就是3125*3125*5000.
还有halo的地图并不是所有坐标角色都能到达,对于主角来说,至少有一半以上的地形不能去到,对于npc和敌人来说,便有更多地方不能去了。
这些不能到达的坐标,可以在地图取值中删掉。
在这里,我们优化掉一半。那么得到3125*3125*2500.
那么一个人物地图坐标就是312531252500=48C4507514+分区A=11个字节
坐标我们只记录人物的运动状态,静止状态不用记录。假设人物70%时间在运动,30%时间静止。

人物视角角度坐标。
我们假设精度达到水平方向2000*垂直方向2000,去除人物瞄准的死角,比如正上方和正下方。
得到面对角度坐标为2000*1600=1313340=7个字节
坐标我们只记录准心的运动状态,静止状态不用记录。假设人物60%时间在瞄准,40%时间固定视角。

人物动作状态。
根据HALO的动作数量,3个字节足以表现所有状态。
我们只记录运动改变状态,静止或者延续状态不用记录。假设人物50%时间在改变状态,50%时间保持静止状态或者延续状态。


人物武器种类和副武器种类 2个字节,这个不需要每帧做记录,每次更换武器记录一次。我们假设1s更换一次武器。

手雷
4种手雷每种两个。使用4字节。每次手雷数目变化的时候记录。假定平均2s记录一次。

武器弹数
每把武器使用2个字节,一共4个字节,消耗的时候记录。假定平均0.5s记录一次。

装备装置
一个字节,消耗或者改变的时候记录。假定平均30s记录一次。

护盾
2个字节,消耗或者改变的时候记录。假定平均2s记录一次。

这样我们得到主角的全状态记录数据。因为halo3的回放是30Fps,所以我们只按照30Fps来计算。

主角一分钟数据量
位置坐标
11*70%*30fps*60=13860字节

瞄准坐标
7*60%*30fps*60=7560字节

动作状态
3*50%*30fps*60=2700字节

武器种类
2*60=120字节

手雷
4*30=80字节

武器弹数
4*120=480字节

护盾
2*30=120字节

总共一分钟主角占用24kb的数据


我们假设战场上有1个重要npc,4个次要npc,20个敌人,其中重要npc的数据是主角的40% ,次要npc的数据是主角的25%,敌人的数据是主角的10%.
总共人物数据是24+24*40%+24*4*25%+24*20*10%=一分钟106KB

即使把其他战场上的多余数据如弹道,物体移动,和场景破坏等整体数据加起来算作主角的2倍。

也不过一分钟318kb的数据,半小时时间10mb不到。
这还没做过数据压缩。

所以说录像通过完全记录路径位置和状态数据的方式,文件虽然大,也还是算行得通的。

[ 本帖最后由 zo 于 2007-9-27 18:34 编辑 ]

TOP

引用:
原帖由 zo 于 2007-9-27 18:30 发表



首先申明,我前面已经提到HALO的录像是存储操作信息和AI取值。这样的优点是数据非常小,缺点是不能自由取段播放和倒放。

其次,我也很蛋痛,希望证明录像通过完全记录时间轴上的路径位置和状态数据的方 ...
只看了第一段,后面部分还没看,我首先指出你的一个计算上的基本问题。

在记录物件的位置时,即使在一个1km^3的空间中记录,以2cm为精度,那么也只需要x,y,z三个坐标值,每个值的极限大小为50000,对于每一个值我只需要用一个16位的无符号整数字(0-65535)来表示就可以了,一个坐标值占用2字节,所以一共只需要6个字节,不知道你在那里优化了半天怎么还需要11个字节。

TOP

你后面的计算我看了一下,不可靠的推测太多了,特别是对某些物件使用数秒的时间单位进行采样,这肯定使不合理的,比如在Halo3中,2秒的时间我都可以丢出去2、3个手雷了。

此外,你对于场景中的物件这个概念的理解有问题。对于一个主角,由于是一个活动的模型,以Halo为例,就是一个人的样子,是包含了很多个物件的,头,手,躯干,武器。此外场景中的所有可以移动的物体都是物件。

所以我们也来简化的算一下:
每个物件位置6个字节,方向矢量以球面坐标来计算,取极低的精度,每维只用一个字节,总共三个字节,场景中共有1000个物件,每秒30帧的采样率计算,每分钟在不考虑数据结构,文件结构,附加数据的情况下,供需消耗(6+3)x1000x30x60=16,200,000个字节,也就是16M的数据量,事实上这个数据还是很不充分的。

TOP

发新话题
     
官方公众号及微博