为什么制作组会把废案放在游戏文件里?
- 445 个点赞 👍
胖虎：“大家看，这是我的新毛衣，好看吧！是不是我穿上特别帅气？！”
众人：“是啊是啊！”
大雄：“哎，胖虎，你这毛衣怎么有一根突出来的线头儿？”（轻轻一拽）
........
查看全文>>
队友被抓边笑边刷 - 123 个点赞 👍
据说英雄联盟有一半的新英雄机制是老蝎子提供的.
查看全文>>
片面辰光 - 25 个点赞 👍
因为一些东西会以非直观的方式被引用在正式逻辑里
比如一段
if（true）
xxxxx
else
xxxxx
虽然else后面的东西不会被用到，但依然被判定为引用了
而上面的“true”是一个曾经某个版本有可能是true有可能是false的逻辑，但后续迭代的过程中事实上变成了只会是true，但有可能没人敢确定真的不会有false的情况，有可能根本忘了这回事，最终进行资源整理的时候，else里的东西就被认为是“有用的”自然就被打包进正式版本里了。
查看全文>>
命运sniper - 17 个点赞 👍
各位都在说删了废案会导致游戏无法运行
但其实更现实的一个原因是你根本没法找全所有的废弃素材。你要找首先就得知道那些素材是废弃没用的，问题是这些素材藏在工程文件的各个地方，没人知道每一个文件到底是有用的还是废案，所以很难删干净
查看全文>>
天堂旅行者 - 12 个点赞 👍
不说段子，真实的原因就两种：
次要原因：劳资花了大力气搭建出来的，隐藏了好歹比直接删了多个心理安慰。
首要原因：我得防着那个傻比制作人待会又要出尔反尔了。
那种说删了游戏就运行不了其实就是个段子。
九成九的项目是不可能出现这种情况的。
查看全文>>
灰常能打 - 8 个点赞 👍
不是很敢动 查看全文>>
知乎用户 - 5 个点赞 👍
废案都算好的
我刚工作的时候, 用的代码管理器还是TFS, 有一个项目有将近一个G大, 下了一个小时, 下载下来一看, 资源文件里有一个cs1.6的安装包... 我把这个安装包装出来, 真的是cs
我觉得这玩意绝对没用吧, 但是删了程序就跑不起来了, 于是我想着可能是名称占位? 就随便找了个小文件替换上去, 结果依旧报错....
然后我懒得研究了, 反正我只要不提交这个安装包就好, 下次获取也不会碰他了, 后来的兄弟们辛苦点了
直到客户项目现场, 部署的程序里, 这个安装包依然在
查看全文>>
梦见未来 - 4 个点赞 👍
大概是不知道关联了啥吧，我以前玩bimmake时把识图课书最后面的图纸给做成建模玩，做完了看剖面时发现二楼多了一堵墙，大概是做的时候多复制了一道，删了会直接导致我二楼所有内墙和整栋小别墅的外墙全部消失，原来是我把墙合并了但漏了一楼内墙没合并。
查看全文>>
2000 - 2 个点赞 👍
清理资源是一件需要耐心，恒心，信心，细心
还需要能力，时间，反复测试。
最后收益怎么说呢
老板不会给你加一分钱
查看全文>>
扼杀黑暗 - 0 个点赞 👍
别说了，我最近写web作业，也是删了一个不重要的标签就乱码了，只能留着，更别说游戏了
查看全文>>
不能超过16个字符 - 0 个点赞 👍
纯外行，好奇问一下AI编的程度会有这些问题吗
查看全文>>
南天游击队 - 0 个点赞 👍
能动就不要动
查看全文>>
焦冶 - 0 个点赞 👍
我曾经在什么都没动的情况下，写完代码玩了把王者。
电脑自动待机了。我玩完王者再打开发现，不能跑了。。
查看全文>>
北安 - 1458 个点赞 👍
查看全文>>
洛催更 - 1400 个点赞 👍
你以为的废案:
一个文件夹名字叫废案，里面放着的全是不需要的资源。既然不需要了那删了也无所谓吧。
实际上的废案:
遍布于项目文件夹的各个角落，与有用的资源混杂在一起。
偶尔会有人心血来潮想要清理一下，但是程序不知道美术资源是暂时没用还是彻底没用，美术也不知道策划是暂时不要还是彻底不要。至于策划，可能已经忘了这回事了。
以下就是一段可能发生的对话:
A:这个东西还要不要？我看好像没地方再用，不然删了吧。
B:不知道，这不是我做的，看一下提交历史。
C:哦，这个是以前XX需求的。
A:什么时候的事了，那这个还要吗。
C:呃，先放着吧，我后面看一下。
A:行。
*后来再也没有人去管它
发布于 2024-03-29 01:50・IP 属地福建查看全文>>
顶级吹烫糊涂鸡 - 1353 个点赞 👍
查看全文>>
银雪猫 - 979 个点赞 👍
查看全文>>
胡艺萧 - 453 个点赞 👍
查看全文>>
梦见未来 - 432 个点赞 👍
现在有一个公园，入口有个保安收门票。
旁边立了个牌子上面写一行字：
一人一票，一票2块，只收现金。
你是一个旅行团的向导，你厌倦了每次进来都要手动根据团里的人数给保安交现金。你希望能够包月、或者扫码支付、或者先记账，年底统一交付。
但是这个公园不归你管，保安根本就不听你的方案，你不给他现金，他就不开门。
于是你在旁边砌了一个检测的自动门和一个硬币箱，过一个人它就会自动往保安亭里扔两枚硬币，保安就会开门。
虽然很蛋疼，但是至少看起来一切正常并且自动化运行。
突然有一天，冒出来个人说我们要推行网络交易，把硬币都清空了。于是后面来的人通过了自动门，然后死活进不去公园。
“我们不知道自动门旁边为什么要有一个硬币箱，但我们知道里面如果没有硬币的话，公园门就开不了了。”
发布于 2025-01-10 00:18・IP 属地浙江查看全文>>
如墨 - 389 个点赞 👍
收到离职同事交接的 一段工程设备动画的模型和源文件。后续需要我做动画，渲染和找人配音。
模型里有一个矿水泉瓶子，还是X夫山泉。
因为要给上级源文件，放个瓶子显得不专业，我就把这个瓶子删了。
模型报错。 各种找，看配合关系。
艹 瓶子盖是红的， 瓶子盖是设备的可调发光旋钮，ABS材质，外面贴了半透明的图。剩下瓶身埋在机器内部，外面看不到。
想起来以前做过一个动画，音量指示器，模型里是一节竹子，贴了个发光材质。
发布于 2024-08-26 07:16・IP 属地山西真诚赞赏，手留余香还没有人赞赏，快来当第一个赞赏的人吧！查看全文>>
陆仁贾 - 334 个点赞 👍
不敢删。
谁知道傻逼策划有没有配进去。
谁知道傻逼程序有没有调用。
谁知道傻逼美术有没有用材质。
谁知道傻逼测试能不能测到。
谁知道傻逼制作人会不会突然跟你说要。
谁知道傻逼老板会不会突然过头七。
所以，留着更安全。
发布于 2024-02-15 19:07・IP 属地四川查看全文>>
SE还我女神侧身像 - 285 个点赞 👍
你写过程序就会知道各种东西能有多离谱。
我在清理个人文件夹时发现了一个名为''artifact''的文件夹，内有同名的''artifact.sln''和''artifact.cpp''。
其中一段长这样：
int a[11]; for (int i = 0; i < 10; i++) { a[i] = 0; } for (int i = 0; i < 10; i++) { std::cout << a[i] << ' '; }我十分确信这个名为a的数组没有在任何其它地方被应用，因为整个程序就不到100行。但是一旦删除，另一个名为''getlfts''的函数会在运行时报错（这个名为'a'的数组在''main''里）。
stack around the variable 'ls3' was corrupted.谁能告诉我这两个变量有什么关系？
然后在排查这一出bug的时候，离谱的来了。
在Visual Studio 2022上使用Debug模式时程序报错，Release模式不报错？
在IDE外双击运行Debug不报错，使用Visual Studio Code的组件检测，也没有出现数组越界。
然后我把那一段的注释删掉，重新编译，运行，数组越界没了？？？？？
（重复上述流程）
（重复上述流程）
......
最终，我宣布我无法解决这个问题，哪怕这玩意儿看起来的确没有用，我也不可能删掉它。（反正这串儿代码保证了程序正常运行，那还是留着吧）
查看全文>>
MiklyWay - 253 个点赞 👍
你以为的废案：柜子里装的东西，丢一个就好了。
实际上某些废案：存在于把柜子立起来的几个脚之中，具体是谁、有几个不明确，你如果拆错了，柜子直接倒。
发布于 2024-02-15 01:40・IP 属地重庆查看全文>>
九妖 - 244 个点赞 👍
你叫宫本茂，是任天堂的一个底层打工人，你在制作《超级马里奥兄弟》的时候，为了节约资源，在海洋关卡不加载树的图形素材。
然后你发现天上的云彩不见了。
发布于 2025-02-21 10:07・IP 属地北京查看全文>>
Jupiter - 236 个点赞 👍
查看全文>>
夙青 - 221 个点赞 👍
查看全文>>
1900 - 161 个点赞 👍
因为组装资源的人，跟使用资源的人，是两拨人。（虽然同一拨人可能也改变不了什么）
同时，因为工具的限制，很多时候，一个资源是否被引用，是没有统计的。
也就是说，你躺在资源列表里的1，2，3，4，5号资源，到底用了几次，用在哪里，并不是每个开发工具都能帮你准确数出来的。
而且，引用资源可能包括脚本里，也可能在底层代码里出现个别硬编码（如果开发不够讲究的话）。
参与的人一多之后，反复改来改去以后，到底有多少处地方有可能引用资源，就真的不好说了。
这种情况下，如果冗余资源不是占比特别高的话，清理资源其实是一件风险很高的事。
比如你在一个低概率事件里需要显示一屏幕的CG，结果其中一个火光效果的素材被你不小心清理掉了。到时候显示成一块黑屏甚至游戏崩溃，就不好了。
这种bug哪怕测试都很难测出来。
所以，如果不是占用地方特别夸张，一般开发团队就不会去主动清理，没必要为了些许好处去引入巨大的bug风险。
最关键的是，占用的空间成本是玩家来承担的，不是开发团队来承担……
但出了bug，败坏的是开发团队的声誉。
编辑于 2024-02-15 18:05・IP 属地山东查看全文>>
Sental Cristar - 84 个点赞 👍
如果你做过大型项目，你就会知道，屎山有多恶心。
没人知道某段代码会以什么方式影响到整个项目。
我遇到的一个恶心的事儿，经过排查，主要是全文搜索，非常确定某个文件夹下的代码都是无用的，我就把这个文件夹删了。
我还挺自信的，感觉这些代码绝对没用，因为我在里面发现了语法错误，如果真的有用，编译过程必然报错，而事实是编译过程很顺利。
然后，我醉了，删完之后，反而编译不通，而且报错的地方看起来和删掉的那个文件夹毫无关系。
我就不服了，查了两周，把40万行规模的代码研究得透透的，终于找到了问题。
编译过程其实是有bug的，删掉的那个文件夹中有语法错误，导致涉及到它的一个编译过程提早结束了，结束得刚刚好，正好绕过有bug的那部分脚本。
你说为什么没在这步报错？因为前人在那一步里加了“||exit 0”，也就是无论如何都强制脚本返回成功。
直到现在，这个屎山还是我负责呢，因为只有我最懂它了，领导说投资了两周时间研究，我现在是公司的重要资产，这个屎山项目的守护精灵(daemon)，要世世代代镇守它。
后来，我还是把那个文件夹删了，但编译用的脚本太复杂，懒得看了。
我直接创建了一个fuck.c的文件，里面用字符画了个中指，这肯定不是有效代码，一样能起到制造编译错误的作用，后面的过程就一样了。
你敢想，有时语法错误是项目编译成功的必要条件。
总结下，废案不删除，多半是因为删除它们需要额外的人力成本，鬼知道会有什么蝴蝶效应。
保留它们，无非是占用点儿空间和流量，无伤大雅。
还可以留着让玩家挖掘，保不齐有奇效。
发布于 2024-02-17 00:01・IP 属地北京真诚赞赏，手留余香还没有人赞赏，快来当第一个赞赏的人吧！查看全文>>
李明阳 - 30 个点赞 👍
很久之前的某二游，新角色CV名叫“結崎このみ”，但游戏里只能显示“結崎の”，“こ”和“み”看不见。
开发者收到错误报告后也很懵，某旧角色CV“上原あかり”全部正常显示，“の”也可以显示，为啥只有“こ”和“み”不行？
我研究发现，因为游戏最初版本只用到了あかりの这四个假名，有人把除此之外的假名字体都删了。
编辑于 2024-02-16 13:18・IP 属地海南查看全文>>
林轻武 - 16 个点赞 👍
查看全文>>
王梓
