Re: [闲聊]游戏开发者抱怨现在程式码夸张膨胀“可能有99%的内容都是
楼主: tomer (卯月影) 2022-07-04 05:46:49
嗯...
是觉得他这么喜欢底层
这么热爱程式设计师对CPU对内存配置了若指掌的“黄金时代”的话
那我想他不适合写游戏
去做一些韧体或者嵌入式开发呗
那些把萤幕点亮或者让USB装置动起来的工作应该会让他非常有成就感
本来在游戏产业中程式设计师就不是主角
是把企划落地成产品的工匠
产品能不能符合设计规格才是重点
只要能如期如质完成
你厉害想从头造轮子
还是导入一堆乱七八糟的东西
随便你
当然我能理解他讲的是实际上正在发生的问题
但他的结论是世界上大多数的工程师都是不懂底层的垃圾
这就没什么建设性了
如何选择适当的SW stack
规划好什么要开发、什么功能要导入lib、什么部分要外包
以在有限的预算、人力内
如期如质将产品完成
这也是SWPM的工作
极端点说
若你的产品真的那么有价值
世人就算卖肾脏都想要拥有
开发资源无限
你甚至可以找AMD找nvidia专门帮你开案子做专用平台
如果没那么有价值
那就识时务
有多少资源做多少事吧
别想太多
※ 引述《pl132 (pl132)》之铭言：
: 游戏开发者Cliffski抱怨现在程式码夸张膨胀“可能有99%的内容都是垃圾”
: https://tinyurl.com/229o8zbm
: 作为一名从事独立游戏设计和程式业务的开发者，克里夫斯基（Cliffski）在一篇文章中
: 吐槽道 —— 这年头的“程式码膨胀”，已经到了令人发指的地步。
: 他以自己常使用的一个云端备份服务为例来说明，这个由某个大公司提供的云端备份工具
: ，基本上提供的服务就是指向本地端硬盘上的一个资料夹，然后把内容复制到一个远端伺
: 服器上。而上传到服务器时，大公司可能需要做一些与数据库管理有关的事情，例如给这
: 一堆上传的档案分配一个名称，并验证谁下载了它。
: “这是一家大公司，所以他们有大的程式，而且可能经常被骇客攻击，所以需要一些安全
: 保障，也需要一些验证，以确保在我上传和他们接收档之间没有被篡改过。我明白这一点
: 。”他表示。“但基本上这个程度的目的就是列举一些文件，读取它们，上传它们，然后
: 关闭连接，并提供一个日志档，说明是否成功，如果不成功，出了什么问题。事实上，我
: 自己也从头开始写过这样的程式码，使用wininet API和服务器上的php与MySQL数据库对
: 话。与企业级的东西相比，我的东西可能没有那么强大，但它确实可以做到。”
: 不过他表示，今天他所使用的这个大公司提供的上传工具，档案大小共有230MB，里头有
: 2700个不同的档案，就为了管理这个过程。
: 他表示这说明了现在的应用程式，已经超越了“臃肿”可以形容的程度，程式档案的膨胀
: 已经变成“完全的、彻底的、明显的荒谬和疯狂”。
: 一个普通的程式设计师都可以编写一个同样功能的程式，它的程式码量小到只有这个应用
: 程式的 1/20，足以将文件安全、快速地上传到服务器。甚至可以是一个单独的 .exe 可
: 执行文件，无需成百上千的动态链接库（DLL）。
: 不仅可行，而且简单、可靠、高效、易于调试。只需稍微努力那么一下，它就会起到切实
: 的作用。
: 那么，现在的程式码为什么会变得这么大而臃肿呢？
: “我见过不少程式员在干这种烂活，我知晓这种情况是怎么发生的。”他表示，越来越多
: 程式设计师不去研究通过底层的高效程式码来完成工作，且许多人甚至从未写过所谓的好
: 程式码。很多人往往就是引用DLL函示库，需要什么就去找什么。
: “我可以断言，在你的电脑中许多应用程式，99.9%的程式码是绝对无用的，甚至从来没
: 有被执行过。它只是在那里，在一套多达65个档案的DLL函示库中，这只是因为某个程式
: 设计师想做一些微不足道的事情，比如保存一个位图，但他们不想从底层来写这个程式
: ，所以他们导入了一整桶臃肿的垃圾来实现它。”
: 举个例子，当年一个仅 64Kb 的《Elite》游戏，就包含了庞大的星系、3D 太空战斗、职
: 业发展系统、交易、以及数千颗可供探索的行星。
: 诚然，现如今电脑速度已经快到可以忽略程式的臃肿。但是在你使用电脑时，正在怀疑自
: 己到底有没有点下去按钮的这半秒钟时间里，频率动辄数 GHz 的处理器世界里，早已过
: 去了数十亿年。我们浪费了个人计算机 99% 的算力和能耗，就为了这些垃圾程式。
: 想像一下，在你急着想要在档案总管中快速搜寻某个档案的时候，工作管理员却在那搞一
: 堆废话，如果你查一下后台，竟有102 个程序在忙碌著，天知道他们在干什么！
: 或许正因如此，我们才在几乎没有干任何事情的情况下，你发现你去年才买的机器，今年
: 就“老了”。
: 你甚至需要每年都换一部新手机、新电视，以执行那些臃肿不堪的串流媒体 App —— 只
: 因为它们依赖执行的程式码是如此糟糕！
: 他表示他非常怀唸过去程式的黄金时代，程式员们对内存和 CPU 的限制了如指掌。如
: 今，我们已经被迫生活在了一个效率极其低下、但浪费又如此夸张的泥潭里。
是觉得他这么喜欢底层
这么热爱程式设计师对CPU对内存配置了若指掌的“黄金时代”的话
那我想他不适合写游戏
去做一些韧体或者嵌入式开发呗
那些把萤幕点亮或者让USB装置动起来的工作应该会让他非常有成就感
本来在游戏产业中程式设计师就不是主角
是把企划落地成产品的工匠
产品能不能符合设计规格才是重点
只要能如期如质完成
你厉害想从头造轮子
还是导入一堆乱七八糟的东西
随便你
当然我能理解他讲的是实际上正在发生的问题
但他的结论是世界上大多数的工程师都是不懂底层的垃圾
这就没什么建设性了
如何选择适当的SW stack
规划好什么要开发、什么功能要导入lib、什么部分要外包
以在有限的预算、人力内
如期如质将产品完成
这也是SWPM的工作
极端点说
若你的产品真的那么有价值
世人就算卖肾脏都想要拥有
开发资源无限
你甚至可以找AMD找nvidia专门帮你开案子做专用平台
如果没那么有价值
那就识时务
有多少资源做多少事吧
别想太多
※ 引述《pl132 (pl132)》之铭言：
: 游戏开发者Cliffski抱怨现在程式码夸张膨胀“可能有99%的内容都是垃圾”
: https://tinyurl.com/229o8zbm
: 作为一名从事独立游戏设计和程式业务的开发者，克里夫斯基（Cliffski）在一篇文章中
: 吐槽道 —— 这年头的“程式码膨胀”，已经到了令人发指的地步。
: 他以自己常使用的一个云端备份服务为例来说明，这个由某个大公司提供的云端备份工具
: ，基本上提供的服务就是指向本地端硬盘上的一个资料夹，然后把内容复制到一个远端伺
: 服器上。而上传到服务器时，大公司可能需要做一些与数据库管理有关的事情，例如给这
: 一堆上传的档案分配一个名称，并验证谁下载了它。
: “这是一家大公司，所以他们有大的程式，而且可能经常被骇客攻击，所以需要一些安全
: 保障，也需要一些验证，以确保在我上传和他们接收档之间没有被篡改过。我明白这一点
: 。”他表示。“但基本上这个程度的目的就是列举一些文件，读取它们，上传它们，然后
: 关闭连接，并提供一个日志档，说明是否成功，如果不成功，出了什么问题。事实上，我
: 自己也从头开始写过这样的程式码，使用wininet API和服务器上的php与MySQL数据库对
: 话。与企业级的东西相比，我的东西可能没有那么强大，但它确实可以做到。”
: 不过他表示，今天他所使用的这个大公司提供的上传工具，档案大小共有230MB，里头有
: 2700个不同的档案，就为了管理这个过程。
: 他表示这说明了现在的应用程式，已经超越了“臃肿”可以形容的程度，程式档案的膨胀
: 已经变成“完全的、彻底的、明显的荒谬和疯狂”。
: 一个普通的程式设计师都可以编写一个同样功能的程式，它的程式码量小到只有这个应用
: 程式的 1/20，足以将文件安全、快速地上传到服务器。甚至可以是一个单独的 .exe 可
: 执行文件，无需成百上千的动态链接库（DLL）。
: 不仅可行，而且简单、可靠、高效、易于调试。只需稍微努力那么一下，它就会起到切实
: 的作用。
: 那么，现在的程式码为什么会变得这么大而臃肿呢？
: “我见过不少程式员在干这种烂活，我知晓这种情况是怎么发生的。”他表示，越来越多
: 程式设计师不去研究通过底层的高效程式码来完成工作，且许多人甚至从未写过所谓的好
: 程式码。很多人往往就是引用DLL函示库，需要什么就去找什么。
: “我可以断言，在你的电脑中许多应用程式，99.9%的程式码是绝对无用的，甚至从来没
: 有被执行过。它只是在那里，在一套多达65个档案的DLL函示库中，这只是因为某个程式
: 设计师想做一些微不足道的事情，比如保存一个位图，但他们不想从底层来写这个程式
: ，所以他们导入了一整桶臃肿的垃圾来实现它。”
: 举个例子，当年一个仅 64Kb 的《Elite》游戏，就包含了庞大的星系、3D 太空战斗、职
: 业发展系统、交易、以及数千颗可供探索的行星。
: 诚然，现如今电脑速度已经快到可以忽略程式的臃肿。但是在你使用电脑时，正在怀疑自
: 己到底有没有点下去按钮的这半秒钟时间里，频率动辄数 GHz 的处理器世界里，早已过
: 去了数十亿年。我们浪费了个人计算机 99% 的算力和能耗，就为了这些垃圾程式。
: 想像一下，在你急着想要在档案总管中快速搜寻某个档案的时候，工作管理员却在那搞一
: 堆废话，如果你查一下后台，竟有102 个程序在忙碌著，天知道他们在干什么！
: 或许正因如此，我们才在几乎没有干任何事情的情况下，你发现你去年才买的机器，今年
: 就“老了”。
: 你甚至需要每年都换一部新手机、新电视，以执行那些臃肿不堪的串流媒体 App —— 只
: 因为它们依赖执行的程式码是如此糟糕！
: 他表示他非常怀唸过去程式的黄金时代，程式员们对内存和 CPU 的限制了如指掌。如
: 今，我们已经被迫生活在了一个效率极其低下、但浪费又如此夸张的泥潭里。
作者: hizuki (ayaka) 2022-07-04 06:21:00
是有道理，但是望向仙剑4为何失败就有程式太卡
作者: Axarz631 (荒) 2022-07-04 06:32:00
所有的开发工具本来就是为了人机沟通产生的 这么爱讲求程式执行效率怎不用组合语言写 写得出3A大作我就三餐拜
作者: alinwang (kaeru) 2022-07-04 06:56:00
仙4卡的问题是防盗软件，但隔天就发修正程式解决了。
作者: johnny3 (キラ☆) 2022-07-04 07:03:00
GTA online之前程式就太烂读取超久 还是玩家修好的
作者: b325019 (望月) 2022-07-04 07:19:00
程式效率固然重要但是够用就好不必叠砖造瓦我支持在有限度范围内优化执行效率
作者: lucky0417 (L.W) 2022-07-04 07:50:00
确实，他应该选错方向了，不过独立开发就随他了
作者: pgame3 (G8goat) 2022-07-04 08:09:00
是说照他这玩法正常的3a做可以变多小阿
作者: lucky0417 (L.W) 2022-07-04 08:23:00
公司要压日期的，如果他一款3A做好几年甚至十年以上可以很小，如果他不在乎中间还要翻新
作者: salamender (banana king) 2022-07-04 09:03:00
小团队怎么刻底层无所谓，大团队有一套可以系统训练后可以磨合一小段时间就实作的工具我个人觉得还挺重要。
作者: kashiwa27 (UDON) 2022-07-04 09:13:00
也不会变多小 因为占大部分容量的是图片影片和音乐
作者: q251425 (Bestimak) 2022-07-04 09:15:00
问题是他说的包含程式库 而游戏来说程式根本没多少容量
作者: kurtsgm 2022-07-04 11:12:00
照他这做法 3A也没办法小太多啦....倒是一些老游戏重新上PC的 比方说超任的FF6 原本在超任上可能只有几Mb 上了PC变成1G这种 照他做法的确可以大幅降低 也许缩到50~100M但像是什么2077 66G 缩个10G 20G就很厉害了 但完全无感然后2077自干版的bug可能多三倍
