binfreeze

@forisra 我没理解你要表达的意思. 你是觉得 Jonathan Blow 因为给出了老派的 C++ 建议, 觉得他编程能力弱? 如果你仔细研究过他所做到的事情. 看过他直播写代码. 这人跟弱可是毫无关系. 在我看来, 他可能是世界上游戏编程领域最厉害的几个人之一. 甚至是第一.

@forisra Jonathan Blow 的编程流派更像是在 C++ 里面写 C. 这并不是降低编程难度, 而是提高了编程难度. 表面上看起来降低难度是因为对语言特性的依赖变小了, 但把程序员的精力更集中在了解决具体的问题上. 这才是真正的难点. 如何用最简单的工具搭建出来复杂的系统.

取决于你打算做什么类型的游戏..
如果做环世界同类的, 就那美术标准如果还要把不会画画当作卡住自己的因素, 就有点扯了.. 这种游戏的障碍只是编程.
而对于土豆兄弟来说, 想要赚到钱, 游戏设计则成了主要障碍. 这游戏在编程和美术上的难度就更低了.

@geligaoli 今天心情好, 多跟你侃几句. 我清楚的记得 2022 年, 是我自学编程的第三年的夏天. 我把 3000 行不到的 PNG 解析写出来替换掉了大家常用的 stb_image 或者 libpng. 从那一天那一刻, 我对编程世界认知就完全变化了. 这就是一个三星期左右工作量的程序, 如果是现在的我, 也就一星期的工作量. 可你放眼望去, 有几个人自己写. 他们就算实现出来, 会写多少行代码? 看看 Rust 仓库的 png 解析是用多少行代码实现. 看看多少人写游戏引擎还要集成 stb_image 的. 都自己写游戏引擎了, 集成几十个开源库在里面, 你在写啥啊? 写胶水程序也值得骄傲吗? 而且这种用了几十个第三方组件的开源库还不止一个. 诚实地说, 你在这里说什么, 我其实并不在乎. 因为我们并不是一类人, 如果是我看到跟我走一样路径的人, 而且还仅仅是走了个开头, 我根本不会产生质疑. 我觉得这很正常. 上面提到的 raddebugger, 那作者有个 discord 群, 那里面的人都用 C 从头写的程序. 就连那个 raddebugger 都只是两个人在搞. 这 2 个人全职搞下来的东西, 就已经有 VS debugger 差不多的功能了. 而且 99% 的部分都是从头写的, 没有集成几个第三方的库. 你可以去关注一下这些项目这些人. 我做到的这些, 在那个群里我都难以启齿. 这都是太平常的事情了. 结果到了这里, 到了中文社区, 大家又觉得不可思议. 甚至一些人拿出来几十年的工作资历来教育我. 你让我怎么看待这些事情. 我只能是觉得可悲又可笑.

@geligaoli 我也可以讨论下 "自我实现的乐趣". 比如你说的, 从一些小的应用开发做起. 就说个最最最简单的, 一个秒表, 或一个计算器. 有些人用 C# 在 WPF 里面实现出来, 就可以很满足. 觉得自己好牛逼, 会编程了. 可有些人在实现完之后, 会产生疑问. 这个文字是怎么跑上面去的, 这个按钮点击为什么会产生作用. WPF 提供的这些接口背后到底是如何完成这些的. 有这些疑问的人, 并不会在通过完成这种简单的应用程序上获得自我满足. 我就算是误导, 也只是误导了某一类性格的人, 而不是全部. 既然不同路线适合不同的人, 你所说的大众化的路线, 也同时存在误导一些人的可能性.

@geligaoli 刚才说的废话太多了. 这次简单一点. 你去动手写一些我提到的那些程序. 别想着一次性就写出来完美的, 而是一步一个脚印慢慢去做. 不要去提前就规划整个程序, 而是只把这一步干完, 再去构想下一步. 完成了几步之后, 再去重构代码. 重构之后, 再去做下一步. 如此反复. 那些复杂的程序, 也就没有那么复杂了. 现在互联网上的知识, 都是教你, 从最开始就要设计好一切. 这从根本上就跟人类解决问题时候的过程是相冲突的. 当你提到那些程序的困难时, 也是把它当作一个整体在谈论. 可任何机器都不是一下子凭空变出来的不是么, 而是一个零件一个零件组装起来的.

@geligaoli 这不需要 20 年的天才.. 只需要有一个迎难而上的决心. 在你已经落后别人许多的时候, 如何在竞争中缩短差距? 我选择用英文直接学是为了缩短差距. 选择比较硬核的技术路线也是出于这个目的. 很多人会因为自己曾经所失去的一些, 比如没有读一个好大学, 去给自身画个圈, 觉得很多东西离自己太遥远, 从而选择更符合自己"身份"的事情去做. 编程里面也有这种, 比如觉得一些库提供的功能是 "神圣且不可侵犯" 的, 是超出自己能力很多的人写出来的, 自己不敢去尝试, 他们会安慰自己, 等我工作 10 年, 20 年之后, 再去做同类的事情, 就像你提出的看法一样. 但事情根本没有表面上看起来那么简单, 因为我们只能活一次, 如果你现在不去做这些, 20 年后, 从 30 岁到了 50 岁, 就更没有精力和勇气去做这件事了. 你以为只是推迟, 实际上是从根本上斩断了自己在另一个路线上的可能性. 这几个月我没上论坛, 刚把游戏需要的 UI 系统写完. 可能听起来很唬人, 但当你真的去做了这件事, 也没有想象中那么难. 编程水平的提升并不是一个单纯代码量的累计, 而是根据你所解决问题的难度来决定水平提升速度的. 另外补充一下, 我的 C 语言编译器也没写完. 把前端部分写完就搁置了. 内存分配也有不同难度的, 如果只是线性分配, 去看 raddebugger 的源代码, 里面有很简单的实现. Vulkan 渲染器这些也都有很多参考代码. 如果你写过一些 C 程序, 看懂这些代码并不难. 但如果你一直都是写脚本语言, 就会觉得跨度很大, 像一堵墙一样. 因为人在学习编程的过程, 并不是在死记硬背, 而是在一种培养直觉, 只有你把自己 "泡在" 这些难题中, 才能获得这些直觉. 就像学习英语需要语言环境, 学习编程同样需要创造一种环境. 比如用 C 语言无时无刻都在面对指针, 那它就会像吃饭喝水一样没有挑战了. 你也可以试着把文本编辑器的自动补全关掉, 以及任何智能提示, 可能刚开始会很不习惯, 但久而久之, 你会获得记住变量名和函数名的能力. 失去了工具的辅助, 就会强迫你用大脑的工作记忆区域去承载更多的信息, 但也同时锻炼了大脑的这个功能. 工作记忆的强弱, 对于解决编程问题也是非常重要, 就像国际象棋棋手在脑海里面下盲棋一样, 哪怕你在电脑屏幕上盯着代码, 他们也不可能是都集中在一起的, 这些代码在不同的位置上前后关联, 都需要工作记忆作为前提, 然后才能展开时候的思维活动, 去理清这些问题的脉络. 我在这跟你讲这堆东西, 如果你是一个有一些水平的程序员, 自然能明白他们的含义, 也能判断我是不是在装. 如果你从来没解决过一些复杂的问题, 自然也听不懂这些.

确实就是无病呻吟。你这么多年工资涨了 10 倍，哪怕 3000 一个月作为起点，现在也 3 万了。一个人在上海生活，不用养老婆孩子供房贷。能说出来为了填饱肚子就已经筋疲力尽这种话，也是够文艺的了。哪天订外卖的时候，也跟外卖小哥说说自己多么筋疲力尽。看人家什么眼神看你。