有一堆杂七杂八的懒得写中长篇的日记就为了吐槽，加上想要记一下都学了什么干了什么事情，所以开个单篇记录一下。
想写写，不想写不写。
2025
2025.10.2
国庆第二天，因为卡在「难的打不过弱的不想动所以不知道干什么」的状态，并没有太随便过假期，又学了点。
今天把 AriaOfTutorial 的玩家控制器重构了，把重力缩放效果和控制器拆分了，用事件和属性交流，感觉很单一职责了，代码看着清楚地很，舒服。
有一说一重力缩放还有那些技巧改善后，加上视觉缩放效果和落地挤压动画后，手感就变得好起来了，虽然滞空时间还是很长，但是从原来的高跳变成了长横跳，这实际上是顶点重力缩放太小导致的。
接着又做了动画机，本来想手搓，后面还是选择了 animator，因为状态不多而且放假不想写多。一个小插曲是还以为遇见编辑器 bug 了，结果发现是蜘蛛网连错了，折腾一个钟 无事发生。
然后晚些时候把 git 清理了一下，网上的教程也是太繁杂了，甚至连 UserSettings 这种东西都加进 git，在我看了文件内容后感觉这种界面设置应该不用加进 git，所以又加进 .gitignore 然后删除追踪了。我还特别记了一下命令，因为每次都忘。
git rm -r --chace # -r 是递归文件夹 --chache 是只删除缓存而不是实际文件
git add . # 删除后再将所有文件添加进追踪，原来没在 .gitignore 的加进缓存区四舍五入就是没更改，而后进 .gitignore 的则没被添加进缓存区，所以会被在追踪列表判定为删除更改。
git commit -m "clean track files but in .gitignore" # 英语不好，这里是 commit 的信息然后又花了一个钟手搓了一个简单的背景图视差效果。最后用昨天才发现的「原来能在 Sprite Editor 里面设置 tile 的碰撞箱」的「窍门」把地图碰撞箱改了改。
别的好像没什么。
2025.10.16
好忙哦。
这些天印象比较深刻的就是听了不少 GDC 的讲座，感觉在技术和开发理念上得到了很多启发和新视角。不过基本都记在本站了，所以这里就不提及了。
其次就是一些 PCG 的内容，比如说地形生成，研究了一下麦块的地形生成。
体验了一下agent编程，虽然听说很多，但是并没有想要实际去用。体验的一次感觉还是有点难用，感觉其节约的成本在api调用的了解上了。感觉使用agent进行编程的前提是api文档和命名够清晰，架构也能被人所理解，不然根本就看不懂agent在写什么，出bug还要找。不过确实在调用api上很厉害，我用agent写obsidian的定制插件，我让agent写，写完我再改改api和各种错误。如果以不长期维护为前提进行开发感觉还是有可行之处。
不过总的说目前我还是没法准确理解 agent 编程，所以对其的使用应该更加谨慎。
其他的就没印象了。
2025.10.23
我觉得有必要结算一下了。
这些天主要在重新学习 C++，特别是现代 C++。看了《C++之旅 第三版》前面 8 章（基本上是语法）。感触颇深，感觉C++还是超级自由的。我再也不乱黑 C++ 石山了。 C++应该是带着浓厚自由历史的石山。
同时意外的是，学C++的时候突然感觉以前看了几次没看懂的rust教程突然变得简单了，rust许多设计存在的原因突然就神奇的冒了出来。
具体的读书笔记应该是在图书馆内的。
2025.11.27
这段时间基本上没学什么，要么是复习，要么在刷视频，要么在写代码，要么在打游戏。越到期末周只会玩越爽写代码越爽定律这块.
2026
2026.2.23
赶时间复习考试完以后我把这事给忘了，或者说从年初起就没怎么写笔记。现在寒假快结束了才想起来。
不过问题不大，寒假期间还是有学东西的，虽然和寒假前的计划完全不一样：和人合作做一个完整的多人2D横版物块破坏游戏，并且有完整的功能甚至更多联机功能，同时还补图形学和Shader知识，如果有空可以尝试写 Minecraft 光影。
现在看来当时犯了个经典错误，忽视了人的生产力是有限的这一个事实。想要通过意志力强撑是完全不行的，在有充足动机的情况下心理上想要行动是简单的，但是精神上思考的疲惫确实真实的，所以并不能靠意志严格高效用光每一点时间。这点是我在前几天琢磨的时候才领会到的。
所以真实的寒假情况是，在学校瞎摸瞎玩了一周，然后回到家中又疯玩了一周老滚5（一周就打通黎明守卫和主线了），还写了一段游戏评价。然后又一边写小说回去写物块破坏游戏摸鱼，两周蒸气统计打了108多个钟的游戏。结果1月24左右泰拉更新1.4.5，连着第二天深岩银河更新新赛季，完了又是停止开发猛玩一周。
通关完泰拉145第二天下午出门转圈的时候突然注意到假期过去大半了，想到还什么都没做但是不知道做点什么，忽地起了个念头说：「做 UNO 吧！」，然后也没想多动手连续进行了为期7天总计69小时的编程马拉松，最后写出来了。（某种角度上，这还是我的第一个作品，完整的作品）
跑完马拉松我才知道，或者说注意到，我好像从来没有对项目开发周期的时间概念，直到这个项目补足这块（谢谢 Wakatime，手动计时我是懒得干的）。统计了小时数我才知道没经验的人写这样一个项目要花多少时间，我在打泰拉1.4.5存档的时候算过通关时间是50h左右，我在学校一周能坐20h-40h，平均是25h多点。这能量出什么？也就是说，这样一个游戏需要我近3周时间才能完成，甚至这时间能拿去给我通关老滚5两次，或者通关泰拉1.4.5传奇1次还剩20h，或者把深岩银河一个职业打几级晋升。
夸张哦。现在终于知道开发到底是多花精力和时间的事情了，好消息是在算了时间之后，我终于学会不乱开坑了——因为开坑前一算时间就是没法安排，完全弄不了一点。现在每天都好好规划开发时间，安排开发计划了，感觉节奏也比以前什么都不管有精力就全力输出好很多，当然还有关于士气的管理。
另外说一点，用小时计数感觉比用天计数更好，小时计数更精准和适应碎片化的时间，天计数如果每天时间都碎片化的话很容易不准。不过当然在按年来进行的规划中还是天计数更好算。
昨天花了一点时间学了一下 Shaderlab，然后自己动手写了一个 Shaderlab。虽然只是简单的颜色混合（col.rgb = lerp(col.rgb, _MaskColor.rgb, _MaskColor.a);)，但是却是我自己手写的 Shader，不赖。
所以从某种意义上，我还是在寒假里完成了一个项目，学了 Shader。虽然都不深，但是我觉得已经足够了。
deep dig 之死说的是
2026.10.25
最近在写 3D 的 Demo，说实在我也是很能磨洋工了，咪摸这么久才到 3D 世界。
本来 2 月过去了，开学没多久我就打算制作一个完整的多人卡丁车游戏来作为 3D Demo 的能力测试项目，但是中间由于完美主义、算法竞赛、学业压力等几个因素，卡丁车项目我基本上都没怎么开发。从 2 月到 6 月这段时间一直在忙各种乱七八糟的事情，Unity 只能是偶尔刷视频看看，完全没有动手。
而 6 月底，我在学业上和经济上遭遇了打击，并连带产生了对个人能力的怀疑。我对未来越来越不太看好，进而开始荒废和颓废自己。在这个过程中，我一边尝试设计一个完整的、目标是正式上架 Steam 的独立游戏项目，研究游戏设计和市场，不断想点子然后放弃，最后到头来什么也没有产出。
7 月，因为独立游戏再一次让我受挫，加上小学期一周八天全是早八加半天或是全天满课的折磨，我把目光方向了更加简单而能够为我带来一丝哪怕是虚假安全感或者优越感的小众领域，我开始观看 Tsoding 和 Jonathan 的一些言论和直播，哪怕是长达几个钟的直播我也一直看，吃饭在看，洗衣服也再看。我了解到了我原来认为是 Hacker 和 Geeker 的人们常做的事情，让我印象最深的便是对开源的理解，以及「如果你想做，那你就自己实现，而不是所求。」这样的态度，我重新理解了以前实际上没抓到点的开源精神和自由精神，并结合我以前对商业模式的浅薄理解，形成了更大的、让我更舒适的视角。
在 7 月到 8 月之间，我重新折腾了以前没认真折腾的 Neovim 甚至浅浅安装和尝试了 Emcas，还学习了 Linux 的一些更多知识。因为折腾这些东西，加上 Tsoding 经常从底层角度揭露魔法，结合以前就有过的一些吱声片语，我尝试克服对底层的恐惧以及急功近利的心（毕竟已经颓废摆烂了，也就没有功利心了哈哈）。我去了解到从 Roslyn 和 .NET 源生成器这种黑魔法，到 LSP、渲染技术、内核编程、网络编程、AOT、JIT 等各个方面我以前没有仔细去了解的内容，我还浅浅去探究了一下 KCP 是做什么的，还比如说 TCP 的经典黏包问题。
感谢，虽然这段时间我几乎什么实际项目也没做，但是却极大丰富了我对计算机的世界观。我知道计算机的基础四大件肯定会有这些东西，但是让我去看课我肯定会困到睡着，而且无法和实践有效连接的知识对我就像空中楼阁，容易忘掉。另一个则是这些知识的理解实际上可能和外面真正要求的水平还有相当差异，但是对我这样的野路子来说能够为我指明道路已经是万幸了。
下面的话是之间从今天的笔记里面写的，我觉得这些话能体现我这阵子关于编码的新理解，虽然我也不知道是否是多余。
实际上光是受击反馈就从19点搞到20点半了。搞这么慢的原因还是在于没有完全跟教程走，而是慢吞吞去研究如何写会比较舒服和优质。
比如说花了些时间研究基于领域的匈牙利式命名，比如说引起资源命名使用领域缩写来命名，例如 Hitbox 的碰撞层命名成
HB_Ally和HB_Hostile。我个人认为，虽然这种命名方法看着有些诡异和小团体，但实际上对互相熟悉的团队或者说个人多天以后再看来认知负担会比较小。另一个研究则是关于 Hitbox / Hurtbox 的设计。Hitbox 和 Hurtbox 实际上都是不同 GameObject 之间的例外，因此应用了之前的依赖规则使用了 SerializeField 和 LogError 直接提示，对同物体间的组件之间的组件要求 RequireComponent。这一套下来我在添加组件的时候心智负担小了不少，我都不用思考代码底层具体怎么样也能整理清楚依赖关系，可以说我之前设计的品味规则实际上是对可维护性这块有效果的。
而 Hitbox / Hurtbox 设计上我也再次体会到设计模式和代码结构实际上都是一场赌，如果你未来用得到某个功能你就可以提前做好准备，否则不论什么状态都会或是容易或是不容易两种方向的改变存在。设计模式实际上是中庸之道，在未来和现在之间根据你的显示需求获得中庸的结果就可以了，不论怎么写的不会变好。不过我肯定的是，简洁的架构对可维护性好，而可维护性其实才是代码能够持续开发的根本，对于长期修改的软件来说，持续使用和持续开发等同密切相关。因此可维护性是代码能够持续开发的根本。
走一步想一步还是慢，不过我希望前期这样思考，能够积累足够的经验，提高以后的开发速度，尤其是重构和添加新功能时思考的速度。