From 85e2fd54b1f193978c4c0432be4cd768c5e9dbf6 Mon Sep 17 00:00:00 2001 From: Eltrac Date: Fri, 11 Apr 2025 23:37:37 +0800 Subject: docs: weekly draft Former-commit-id: 56399d14d3c362fb675d50e07cd28a584df57fbf --- ...\344\272\272\345\221\250\345\210\212-vol-24.md" | 126 ++++++++++++++++++++- 1 file changed, 120 insertions(+), 6 deletions(-) (limited to 'content/posts/weekly') diff --git "a/content/posts/weekly/\347\250\273\350\215\211\344\272\272\345\221\250\345\210\212-vol-24.md" "b/content/posts/weekly/\347\250\273\350\215\211\344\272\272\345\221\250\345\210\212-vol-24.md" index dab011c1..54d03db1 100644 --- "a/content/posts/weekly/\347\250\273\350\215\211\344\272\272\345\221\250\345\210\212-vol-24.md" +++ "b/content/posts/weekly/\347\250\273\350\215\211\344\272\272\345\221\250\345\210\212-vol-24.md" @@ -2,7 +2,11 @@ title: 稻草人周刊 Vol.24 subtitle: description: -tags: +tags: + - 编程 + - 写作 + - 游戏开发 + - 认知 related_cards: date: 2025-04-09 17:22:45 categories: 稻草人周刊 @@ -11,7 +15,9 @@ draft: true toc: true --- -random shit, maybe music and stuff + + + ## 🙋 在做什么 @@ -23,17 +29,125 @@ random shit, maybe music and stuff ## 💬 本期杂谈 -### a topic +### 写给独立游戏开发者的爽文 -content here +{{< callout "文章链接：[The Balatro Timeline](https://localthunk.com/blog/balatro-timeline-3aarh)" "📜" >}} -[#tag](/tags/tag) +我大概是在一个月前就发现了《小丑牌》作者的博客 LocalThunk，这篇文章在我的阅读列表里躺了大半个月，读这篇文章的时候我恨我没有早点点开读它，读完的时候我大概经历了三次颅内高潮，因为读起来实在是太爽了。 -## 💡 新知复盘 +作者花了一年多的时间制作并发布了《小丑牌》（Balatro），当他写道「这个本来只是做给我和我几个朋友的游戏，居然不知怎么地有这么多陌生人想要买它」的时候，我意识到游戏或许就应该是这样的——先娱乐自己，再娱乐身边的人，最后让更多的人感到开心。 + +作者也提到，做这种项目非常重要的一点在于，当自己感受不到驱动力的时候就停下来，这可以帮你： + +1. 不精疲力尽地开始下一个想法； +2. 不自责地休息一段时间，然后更强势地回归。 + +作者还提到，他在刚开始的时候禁止自己玩新的肉鸽游戏，因为他不想无意识地抄袭别人的好点子。他想要犯错，想要重新造轮子，不想借鉴现存游戏中已经被验证过的设计。我想这是值得学习的。 + +不过，《小丑牌》其实是作者在下班后完成的一个爱好项目，一开始并没有当作正经的工作，他甚至在之前从未想过可以靠游戏赚钱。这让我想到了 Toby Fox，他似乎在一开始也不清楚自己到底在干什么。这样的成功兴许是不容易复现的[^1]，但足以说明爱好也能创造不可估量的财富。 + +[#游戏开发](/tags/游戏开发) + +### 博客写作的态度 + +{{< callout "文章链接：[LocalThoughts](https://localthunk.com/blog/localthoughts)" "📜" >}} + +这是《小丑牌》作者的第一篇博客文章，他在这篇文章里写的一句话让我感触良多： + +> I wanted to share more of the what happened and how instead of here's how you should do it and why. +> +> 我想要分享的更多是「发生了什么以及怎么回事」，而不是「你应该怎么办以及为什么」。 + +这段话让我开始反思我之前的博客文章是否带有过强的说教意味，我也在过去的写作中意识到，尽管我非常喜欢拆解底层逻辑和剖析深层次的原因，但过多的对「为什么」的论述似乎不总是能够吸引读者，至少读者很少对这样的内容作出回应。 + +兴许我应该在谈论「为什么」之前，多谈一谈「发生了什么」。在切入正题之前讲故事，或者用故事来辅助自己阐述观点，也确实是惯用的做法。 + +此外，兴许应该戒一戒说教瘾，也要认识到自己经验的局限性和读者自身经验的复杂性。自身的逻辑再完备，也不适用于所有情况——*完了我意识到自己现在就在说教。* + +好吧，那就等我尝试多写一些「怎么样」和「发生了什么」之后，再来对比一下它们和「为什么」和「你应该」的区别吧。 + +[#写作](/tags/写作/) + +### 论业余项目 + +{{< callout "文章链接：[The blissful zen of a good side project](https://joshcollinsworth.com/blog/the-blissful-zen-of-a-good-side-project)" "📜" >}} + +原谅我词穷，不知道应该怎样翻译业余项目才好。简而言之，作者讲到自己在之前大概有一年多没有在闲暇时间开启一个新的业余项目了，在某天晚上，他打开自己的笔记本电脑新建了一个文件夹，找回了原先的感觉。 + +- 选择做什么并不重要，重要的是我选了某些东西来做。 +- 我知道我没有在创造时，我的一部分枯萎了，而且我认为，我们内心都有那样的冲动。 +- ==我认为我们存在的意义就是创造新东西==。 + +令我感触最深的，是作者对于业余项目的态度：It's done when you're done with it. 一个项目不一定要真的完成了才算是「完成了」，当你不想继续了，心想「就这样吧」，这个项目的意义就到此为止了。一个好的业余项目不一定要有任何结果。 + +我想到了现在躺在我硬盘里腐烂发臭的两个游戏项目，一个算是我的第一个电子游戏项目 Warstro，另一个是最近一个月做的 Philora。这两个项目都在做到一半时让我感到焦虑，不想继续，但不继续似乎又是在否定自己的选择，令我很是煎熬。但转念一想，我从这两个半途而废的项目中都学到了不少： +- **Warstro** + - 教训：别用 React 写游戏（认真）。 + - 我所使用的 boardgame.io 引擎教会了我用一个全局变量数组储存所有游戏状态，这样便于管理。在 [Heart Hunter](/posts/为战斗献上心脏/) 中我就沿用了这一方法，所以在玩家死亡后重置游戏状态的操作，我几乎没有遇到任何问题，而且访问常用的游戏对象也变得很丝滑。 +- **Philora** + - AI 取代程序员还很遥远，就连目前最好的编程模型也会生成一大堆冗余代码。 + - 游戏或许是我目前为止接触到的最复杂的软件设计，相比之前，之前做的 Java Web 项目真的非常清晰易懂。 + - 不要让 AI 从一个空的项目文件开始写，那真的会让人摸不着一点头脑。 + - 我开始找一些游戏编程相关的书和文章来看。 + +就像许久未见面的朋友，友谊或许已经难以延续，但对方给自己带来的影响是深远且无法计量的。意识到这一点之后，放下一定要完成的执念就变得更容易了。 + +[#编程](/tags/编程/) + +### 重造轮子的原则 + +{{< callout "文章链接：[Wheel Reinventor's Principles // Tobias Løfgren](https://tobloef.com/blog/wheel-reinventors-principles/)" "📜" >}} + +程序员社群里的主流观点是：你不应该重新造轮子。直接使用别人已经写好的软件库能够节省时间，达成的效果往往也更好，有社区维护且被广泛使用的库往往也更安全。然而，作者指出，重新造轮子也有很好的理由： + +1. 学习。从零开始编写一个库，能让程序员对底层的技术有更深刻的理解。 +2. 特定的用途。不是所有的轮子都适用于每一种情况，有时候你确实需要为自己的需求重新造一个更适合的轮子。 +3. 创新。现有的轮子，尽管很流行，但并不一定好。如果你有好点子，就做一个更好的。 +4. 享受。重新造轮子可以是一件快乐的事情，不需要理由。 + +重造轮子的人必须谨记自己为什么要造这个轮子，不能忘记。同时，他们也应该遵许以下原则： + +1. 最小化第三方库依赖。 +2. 使用最简单的工具和最底层的技术。 +3. 自己动手。 + +我知道有不少游戏开发者会自己写游戏引擎，或是在已有的、较简单的游戏引擎上实现自己的一套工具库用于后续的游戏开发。尽管我还不是一个成熟的游戏开发者，但我的确有在我的不少游戏项目中复用之前写的渲染管理器和状态管理器。我之前还听过一句戏谑的话：每个写博客的人最终都会造自己的博客程序（我自己确实也这样干过）。 + +我自己新造轮子的感受确实是快乐的，对相关领域的理解也会加深，如果你不是为企业工作，自己做项目时享受新造轮子的过程又未尝不可，不要被主流观点限制住了。 + +[#编程](/tags/编程/) + +### 我们低估了自我效能的重要性 + +{{< callout "文章链接：[我们高估了智力的重要性 \| Randy's Blog](https://lutaonan.com/blog/oi/)" "📜" >}} + +我不太喜欢作者起的这个标题，读完这篇文章之后，我认为作者想说的并非是「我们高估了智力的重要性」，而是「我们低估了自我效能的重要性」。 + +我并不认可作者所说的「因为 AI，智力的差距变得更容易弥补了」，但我认可「人们应该主动利用智能」这一说法。或许，我们的关注点从来就不应该是「AI 到底有没有智能」「AI 会不会取代人类」，而是「我们应该如何利用 AI 所提供的智能」，而「如何利用」这一点，就与作者所说的「自我效能」有关。 + +作者认为自我效能可以通过后天训练（关注不能改变的智力，不如关注自己能够改变的），并引用了心理学家 Albert Bandura 提出的影响自我效能的四种因素： + +1. 掌握经验 + 通过亲身体验成功完成任务的经验来建立自信。 +2. 替代经验 + 观察与自己相似的人完成任务的经验，提升自己的信念。 +3. 社会说服 + 他人的鼓励和积极评价能够增强自我效能。作者认为这个条件是较为被动的，但我认为人在一定程度上可以选择自己所处的环境。 + 解读身体信号的方式会影响自我效能。将紧张解读为「我不行」和解读为「兴奋」将会造成两种相反的结果。 + +你看，作者其实有大半的篇幅都在谈「自我效能」这一个概念，甚至根本不用提到 AI。 + +[#认知](/tags/认知/) + +## 💡 新知复盘 ## 🗣️ 碎碎念 - 在宿舍保证睡眠质量的方法只有一个：带耳塞。因为不能要求别人，所以只能做好自己能做的。除了室友打鼾（以及另外两个被鼾声吵到睡不着辗转反侧的室友的床板的声音），宿舍的门板隔音也是差到没边，走廊另一边有人说话和走路都能听得很清楚，夜里要一两点过后才能彻底安静。我发现自己的深度睡眠时间短得离谱，很难达到一小时，结果习惯每晚上床带耳塞之后，深度睡眠时间显著增加…… 不过，还真想尽早搬出去，因为他妈的不想闻室友的屎味了。 +- 我不需要很大的空间，但我愈发清醒地意识到自己难以接受所有的事情都只能在一张并不宽敞的书桌上完成，所有的东西都只能在书桌的架子和柜子上放置，也不能用接受只比我肩膀宽一些的柜子塞下我所有的衣服…… 因为空间不足，我的 Mac Mini 在不到半个月的时间里产生了三处明显的磕碰；我在写下这段文字的今天在烧水时烫伤了手臂，水浸透了我的便签，我真的担心某一天水会撒在我的书和插排上；我的电脑、插排和书桌上原本的插座，间隔都不超过十厘米，我要在那不到四十立方厘米的空间里塞下所有的线缆…… +- 写「论业余项目」这一节的时候，我竟然愣了半天翻译不出来「Side Project」这个词，就当我放弃了翻译，开始概括那篇文章的意思时，我发现自己非常自然地写下了「业余项目」四个字…… 它就这么顺滑地从我的脑子里溜了出来，好神奇…… + +[^1]: 话是这么说，但自称能复现的成功难道不是成功学吗…… \ No newline at end of file -- cgit v1.2.3