钩针编织等距城市：可爱游戏Cotton City

《Cotton City》真正值得关注的不是“钩针编织城市”这个讨喜的皮，而是开发者 n1kozor 用一套极其克制的技术方案——程序化几何加2.5D 混合渲染——把一种高度手工化的视觉语言塞进了 Unity 的实时管线里，这为小团队独立游戏如何在“美术风格独特性”和“性能可维护性”之间找平衡提供了一个可复用的样本。

一个被“可爱”标签掩盖的技术决策

先看原文里最容易被读者滑过去的一句话：所有画布上看到的针脚，都是程序化几何（procedural geometry）。这意味着开发者没有为每一栋房子、每一条道路手工建模，而是用代码生成针脚的形状、排列和密度。对于一个以“编织”为核心视觉隐喻的游戏来说，这个选择几乎是反直觉的——编织天然让人联想到手工、不可复制、每一针都不同，但 n1kozor 偏偏把它交给了算法。

“It's rendered in Unity, rather than using volumetric rendering. To keep it manageable, I cache and reuse geometry, use lower-detail models at a distance, and prepare geometry in the background where possible.”

这段话里藏着三个独立的优化手段：几何缓存与复用、距离相关的 LOD（低细节模型）、后台几何预生成。它们单独看都不新鲜，但组合在一个“每一针都要看起来像真的钩出来的”游戏里，就构成了一个有意思的张力——玩家越放大，越要看到针脚的细节；而放大恰恰是 LOD 系统最不擅长的场景。开发者用“缓存加复用”来对冲这个矛盾，本质上是在承认：完全动态生成每一针的成本不可接受，必须把一部分结果固化下来。

2.5D 模式才是真正的工程亮点

原文提到游戏有一个可选的 2.5D 模式：已完成的建筑使用带深度数据的缓存图像，而 3D 只留给场景中移动的物体。这个划分非常精准。城市建造游戏里，绝大多数建筑一旦放置就不再移动，它们是静态的、可预测的、可以被“烘焙”成图像的。而车辆、行人、可能还有施工动画，才是真正需要实时 3D 渲染的部分。

这个决策的后果是：静态部分的渲染成本被压到极低，动态部分保留了 3D 的灵活性。对于一个 alpha 阶段的独立项目来说，这比追求“全 3D 统一管线”要务实得多。它也让 macOS 版本的移植变得更容易——原文在 Discord 上确认了 macOS 版本在计划中，而 2.5D 方案对图形 API 的依赖远低于纯 3D 体积渲染。

两种模式对应两类玩家，也对应两种技术压力

游戏提供战略模式和创意模式：前者棉花资源有限，后者资源无限。这个设计在玩法层面是常见的“挑战/沙盒”二分法，但在技术层面它意味着两套不同的性能画像。战略模式下，玩家会反复调整布局、拆除重建，程序化几何的生成频率更高；创意模式下，玩家可能铺满整张地图，几何缓存的总量会逼近上限。n1kozor 提到的“后台准备几何”在这个语境下就不只是优化，而是维持两种模式都不卡顿的必要条件。

对独立开发者的启示：风格不是靠堆美术，是靠选对管线

Cotton City 目前只是一个 Windows alpha demo，内容有限，更多功能和内容还在后面。但它的技术路径已经清晰：用程序化生成解决“手工感”的量产问题，用 2.5D 混合渲染解决静态场景的性能问题，用缓存和 LOD 解决缩放时的细节问题。这三件事没有一件是新技术，但把它们对准一个具体的、非标准的视觉目标，就形成了差异化。

“the cotton textures and miniature scale are central to the experience”

开发者自己说得很清楚：棉花质感和微缩尺度是体验的核心。而这两点恰恰是最容易被“全 3D 体积渲染”毁掉的东西——体积渲染会让针脚看起来像毛绒而不是钩织，会让微缩感变成模糊的雾。选择 Unity 的常规渲染管线而不是体积方案，不是技术保守，是审美自觉。

对从业者来说，这个案例的价值在于：当一个游戏的视觉核心是一种“非数字原生”的材质（钩针、毛线、布料、纸艺）时，最危险的做法是直接用物理渲染去模拟它。更可行的路径是像 n1kozor 这样，先想清楚哪些部分可以固化成图像、哪些部分必须实时计算，然后用程序化几何去填补中间的缝隙。Cotton City 能不能成为一款好玩的游戏，现在下结论还太早；但它已经是一个值得拆解的技术决策样本。