Joe Cassavaugh 在 InfoQ 发布的一场演讲中，介绍了自己从软件工程师到围绕益智游戏系列 Clutter 建立个人项目的经历。Cassavaugh 表示，该系列的销售额已超过 600 万美元，为他带来了超过 200 万美元的净收入；当时他正准备推出该系列的第 19 款游戏。但这段经历的价值并不只在于数字，还在于他将单个产品转变为能够持续多年的业务时所采用的方法。
故事始于 iWin 停止开发一款他曾参与的游戏之后。他未来的合作伙伴建议他自己制作这款游戏，于是他在一个周末内围绕匹配相似物品的想法开发出了原型。他从 iWin 获得了知识产权，并达成协议：iWin 在两年内拥有发布任何新游戏的优先拒绝权。随后，他于 2011 年推出了第一款 Clutter 游戏。
第一款游戏的表现没有达到他的预期：15 个月后的收入约为 5 万美元，而不是他预想的两种情况之一——低于 1 万美元或高于 10 万美元。不过，他利用现有的引擎和工具，在大约 6 个月的开发时间内完成了第二部作品。第二部作品带来了约 5 万美元收入，同时也帮助提高了第一款游戏的累计收入。此时，Cassavaugh 开始将该系列视为一种不断积累的资产，而不是彼此独立的产品。
真正发生了什么变化？
Cassavaugh 将这种影响称为“系列效应”。每一次新发行都会带来初始收入，同时也会重新激活旧游戏的销售。他表示，各部作品并不总能取得相同的成绩，但推出新游戏能够让系列持续出现在玩家面前，这帮助他应对了可下载电脑游戏市场的收缩。
这段经历也展现了迎合玩家偏好的局限性。第四部作品偏离了 Clutter 的基本风格，加入了小游戏，但玩家并没有像他预期的那样接受这一变化。相反，其他作品通过在熟悉的机制中提供变化，而不是替换原有机制，取得了更好的表现。此外，Cassavaugh 还利用故事、图片和引语为谜题增添个性，后来开始直接征求玩家的反馈。
为什么这则消息对开发者很重要？
演讲中最重要的技术经验是，速度并非来自工作更长时间，而是来自减少重复劳动。在使用自己于 iWin 开发的内部框架之后，Cassavaugh 逐步迁移到 Unity。他估计，与此前的环境相比，自己的生产力提高了 4 到 6 倍。但他也说明，Unity 同时扩大了他能够完成的工作范围，因此能力的提升并没有全部直接转化为开发周期的缩短。
此后，他持续进行重构。他创建了一个小游戏基础类，负责处理菜单栏、游戏之间的切换、计时器和窗口等共享元素。这样一来，他无需每次重新构建这些功能，就可以加入新游戏。他还将更多工作转移到内容文件和自动化工具中，而不是为每个谜题编写新的代码。
Cassavaugh 提到了一个虽小却很有代表性的例子：通过修改谜题设置的存储方式，在同一行中使用多个键值对，减少了一项原本需要手动重复完成的工作。他还使用 Batch 和 PaintShop Pro 等工具自动创建图片集；此前，准备这些图片需要大约 3 天的重复劳动。
平衡数量与可生产性
按照他的描述，每款游戏表面上包含约 1800 个谜题，但实际数字更接近 900 或 1000 个，因为其中很大一部分依赖于内容的重新组合，以及图片集和规则的变化。每个版本大约包含 200 个基于引语或段落的谜题。这种将代码与内容区分开的方式，使他能够扩大游戏规模，而不必按同等程度增加软件系统的规模。
他还为玩家提供了不同的游玩选项，例如暂停计时器或调整元素旋转速度，同时保留谜题的基本规则。他指出，大约一半的玩家不使用计时器，这促使他设计出既适合寻求挑战的玩家，也适合希望轻松游玩的玩家的体验。
certi.news 的编辑解读
Clutter 真正发生的变化，是项目从一款独立游戏转变为一个由复用、内容积累以及与玩家持续保持联系所驱动的小型生产系统。这并不是建立个人项目的保证性配方；Cassavaugh 展示的数字属于他个人的经历和市场，而且他的成功依赖于多年的持续投入，以及拥有会回归新版本的玩家群体。
对其他开发者而言，最具可迁移性的经验是明确哪些内容应当保持不变、哪些内容可以变化：清晰的游戏规则、共享的技术架构，以及持续更新的内容。尚待回答的问题包括：这种模式在其他市场中能否复制，以及项目依赖单个人和单个系列所带来的风险。因此，应将这场演讲视为一个关于范围管理和生产管理的实际案例，而不是证明个人开发通常优于开发团队。