Stage1st

 找回密码
 立即注册
搜索
查看: 5426|回复: 20
打印 上一主题 下一主题

[PC] 印象中虚幻引擎的游戏每次更新数据都极大

[复制链接]
     
跳转到指定楼层
楼主
发表于 2023-12-21 12:20 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
本帖最后由 Hinanya 于 2024-3-7 14:49 编辑

看着次次不管大小更新都能占原游戏总占用量60%以上的更新数据,我陷入了沉思……

印象中虚幻引擎的游戏每次更新数据都极大
就很想问问潭友想证实一下

一、是否存在虚化引擎的游戏每次更新数据都极大的普遍性问题?
二、如果是,可能是什么原因导致的?
三、作为普通游戏玩家,在如此高强度的反复读写情况下改如何尽量保护自己的硬盘?






关键词:虚幻引擎 EPIC unity UnrealEngine UE 电子游戏 数据更新 patch 庞大 数据很大 硬盘 企业文化
回复

使用道具 举报

     
2#
发表于 2023-12-21 13:33 | 只看该作者
更新数据大是因为数据加密打包在一个DATA里,跟引擎没关系
回复

使用道具 举报

     
3#
发表于 2023-12-21 14:26 | 只看该作者
虚幻引擎默认打包是全部打包进单个pak文件里面
更新的时候不是差分更新,而是覆盖的话,体积就会特别大

Unity有的游戏也会有这个问题

https://docs.unrealengine.com/4. ... Projects/Packaging/
回复

使用道具 举报

4#
发表于 2023-12-21 15:31 | 只看该作者
不做差分更新反而是保护你硬盘。做差分更新需要先把本地包解压再打包回去,反而会闹那种100k更新读写硬盘1小时,不如重新下游戏来的快的笑话
回复

使用道具 举报

     
5#
 楼主| 发表于 2023-12-21 15:52 | 只看该作者
原来如此,感谢回答


记得当年半条命2时代,音乐、音效、伪装成图标的字体文件,各种文件诚诚实实地裸漏在外面,各类素材唾手可得,也促使了社区极其亚文化的发展
现在一个个文件捂得比谁都紧
回复

使用道具 举报

6#
发表于 2023-12-22 09:13 来自手机 | 只看该作者
Hinanya 发表于 2023-12-21 15:52
原来如此,感谢回答



打包主要也是为了读盘速度,以现在的游戏,操作系统打开数以千计的小文件的速度远远慢于把它们都打包在一个文件里而只需要打开这个文件并拿出需要的内容。
回复

使用道具 举报

     
7#
发表于 2023-12-22 09:21 | 只看该作者
现在游戏体量大都是十万个文件级别的,文件越碎 io性能越差
当然要做打包
回复

使用道具 举报

     
8#
发表于 2023-12-22 10:13 | 只看该作者
就不能来个patch.pak吗
回复

使用道具 举报

     
9#
 楼主| 发表于 2023-12-22 10:46 | 只看该作者
すぴぱら 发表于 2023-12-22 09:21
现在游戏体量大都是十万个文件级别的,文件越碎 io性能越差
当然要做打包

确实,如此说来大pak文件,迁移扫描都比碎文件方便,自然代价就是更新的次次读写

希望未来能有技术突破吧
回复

使用道具 举报

10#
发表于 2023-12-22 12:09 | 只看该作者
本帖最后由 eilot 于 2023-12-22 12:17 编辑

那麼也要提到日在校園1.0版,他將大量素材都打包為一個檔,印象中他的資料夾才得不足10個檔案,每個1GB以上,容量好像有7~8GB
結果每次更新都是直接換了一個檔案...而1.0版超多BUG,所以也超多次更新,每次都是GB以上
多年後乾脆出2.0版,其後也有數次更新,但都是百多MB程度
而它的愚人節的序章試玩版也要GB以上,不過最恐怖是他內有多個語言,包括繁簡中文等...
回复

使用道具 举报

     
11#
发表于 2023-12-22 12:31 | 只看该作者
Steam的更新肯定是基于差分的,只不过是基于二进制而不是文件内容的,也就是说每个文件都会拆分成1-2M的小块来下载,更新的时候只需要比较哪些块发生变化了,不然就做不到实际下载内容比文件内容小那么多了
至于主楼的问题估计所有打包archive/pak的游戏都有,比如2077一个小更新总是能下好几十个GB,去steamdb看文件大小变化实际上就几十MB
不负责猜测这种问题一般是文件结构发生很大变化(二进制意义上),导致需要重下的部分大量增加,因为打包之后的总大小并不能说明什么问题,可能包体里的文件早就面目全非了。
回复

使用道具 举报

     
12#
发表于 2023-12-23 07:35 来自手机 | 只看该作者
Hinanya 发表于 2023-12-22 10:46
确实,如此说来大pak文件,迁移扫描都比碎文件方便,自然代价就是更新的次次读写

希望未来能有技术突破 ...

有啊,傲腾,已经被抛弃了

—— 来自 Xiaomi 23054RA19C, Android 13上的 S1Next-鹅版 v2.5.4
回复

使用道具 举报

13#
发表于 2023-12-23 07:52 | 只看该作者
虚幻玩的不多 但2077每次更新都是20G 40G
我旧电脑硬盘装了2077本体容量就吃紧了 根本放不下更新包 结果每次更新都是删了游戏重下 太麻了
回复

使用道具 举报

     
14#
发表于 2023-12-23 08:30 | 只看该作者
印象中有些日厂的游戏喜欢下个几m到几十m然后更新几十g数据,看着是心烦
回复

使用道具 举报

     
15#
发表于 2023-12-23 09:33 | 只看该作者
又不是虚幻的问题
很多非虚幻的,每次更新有大量贴图模型文件的战略游戏更新一次比重新下游戏还慢,没错说的就是战锤全战
回复

使用道具 举报

     
16#
 楼主| 发表于 2024-3-7 12:45 | 只看该作者
Wiksy 发表于 2023-12-22 09:13
打包主要也是为了读盘速度,以现在的游戏,操作系统打开数以千计的小文件的速度远远慢于把它们都打包在一 ...

不不不,我还是感觉很不对劲

我其实指的就是《永劫无间》

每次更新都是一次写入和带宽占用灾难,但是其程序初始化读取速度是我见过第二慢的
简单来说就是写的灾难根本没有换来读的速度
更吊诡的是《永劫无间》甚至连结束程序也速度极慢,大概30秒win桌面才能相应,这里的运行环境甚至是i9。
回复

使用道具 举报

     
17#
发表于 2024-3-7 13:19 来自手机 | 只看该作者
Hinanya 发表于 2024-3-7 12:45
不不不,我还是感觉很不对劲

我其实指的就是《永劫无间》

永劫无间是用unity做的啊

—— 来自 meizu 16s Pro, Android 9上的 S1Next-鹅版 v2.5.4
回复

使用道具 举报

18#
发表于 2024-3-7 14:09 | 只看该作者
本帖最后由 朋友 于 2024-3-7 14:13 编辑
wtyrambo 发表于 2023-12-22 10:13
就不能来个patch.pak吗

能,只是厂商做不做的问题。ue是支持生成patch的,而且也不需要在本地重新打包,他会把多个资源包同时挂载起来

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
回复

使用道具 举报

     
19#
 楼主| 发表于 2024-3-7 14:46 | 只看该作者
ギナ 发表于 2024-3-7 13:19
永劫无间是用unity做的啊

—— 来自 meizu 16s Pro, Android 9上的 S1Next-鹅版 v2.5.4 ...

其实见过第一慢的叫做《杀戮间2》,虚幻引擎,我一2万的ROG能做到初始化1-2分钟,太深刻了从此有烙印了(对了也是那种一更新狠不得重下的玩意,好在半年才会更新一次)





已经删游保平安了
回复

使用道具 举报

     
20#
发表于 2024-3-7 15:28 | 只看该作者
半衰期2属于极端个例吧,产品本身就算是起源引擎的演示教材了,也为了MOD支持做了大量工作
回复

使用道具 举报

     
21#
发表于 2024-3-7 19:31 来自手机 | 只看该作者
Hinanya 发表于 2024-3-7 14:46
其实见过第一慢的叫做《杀戮间2》,虚幻引擎,我一2万的ROG能做到初始化1-2分钟,太深刻了从此有烙 ...

所以这其实跟引擎没啥关系,单纯是开发组的技术问题

—— 来自 meizu 16s Pro, Android 9上的 S1Next-鹅版 v2.5.4
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

小黑屋|Archiver|上海互联网违法和不良信息举报中心|网上有害信息举报专区|962110 反电信诈骗|举报电话 021-62035905|stage1st 沪ICP备13020230号-1 沪公网安备 31010702007642号

GMT+8, 2024-5-5 23:48 , Processed in 0.034657 second(s), 6 queries , Gzip On, Redis On.

Powered by Discuz! X3.4

© 2001-2017 Comsenz Inc.

快速回复 返回顶部 返回列表