三天像三年：Meta Horizon Worlds Creator Academy Seoul 2025 回顾
一次只有三天的 Creator Academy 与 Hackathon，却集中暴露了工程、产品、展示、合作与沟通中的许多问题。这是 Ducky Bumpy Arena 的开发回顾，也是一次关于“做出来之后还缺什么”的复盘。
1三天像三年
2025 年 11 月，我和 Lven 去了首尔，参加 Meta Horizon Worlds Creator Academy Seoul。
活动只有三天。结束以后，我却有一种很奇怪的感觉：好像成长了三年。
不是因为三天里真的学完了三年的知识，也不是因为我们做出了多么伟大的作品。真正让我产生这种感觉的，是很多原本可能要在更长时间里逐渐遇到的问题——工程、产品、展示、合作、沟通，甚至我怎样面对优秀的人——突然在高压环境里同时撞了过来。
第一天参观 Meta Korea Office，听分享、认识来自不同国家的创作者，晚上参加 Happy Hour；后面两天一边上课，一边学习 Horizon Worlds 的工具链并参加 Jam。我们要在很短的时间里，从一个想法出发，做出能够真正发布和试玩的 World。
我和 Pauline 组队做了 Ducky Bumpy Arena：一群小鸭子在不断缩小的水池里互相撞飞，掉出去以后会复活，在限时内把最多玩家弹出场地的人获胜。
为了把它做出来，我连续两晚只睡了两个多小时。那时我几乎是第一次真正使用 Horizon Worlds 的这套开发方式，却给自己选了一个涉及多人、玩家管理、碰撞、Attach、实时计分和 Respawn 的玩法。最后我们真的把它跑了起来，也留下了一些很严重的 Bug。
我们没有成为活动最终选出的 Standout World。
但回头看，我反而觉得：正因为没有得到那个结果，这次经历才逼着我去想一些比“代码有没有写完”更重要的问题。
过去我最有信心的是第一件事。这三天真正补上的，是后面两件事。
2这是一次什么样的活动？
Meta 官方将这次活动称为 Worlds Creator Academy Seoul。活动于 2025 年 11 月 19–21 日在首尔举行，100 多名创作者来自 9 个国家和地区，最终发布了 49 个 World 或 Asset；这也是 Worlds Creator Academy 第一次来到亚洲。1
它并不是单纯的比赛。Meta 对 Creator Academy 的定位是 workshop、hackathon 和 creator community event 的结合：先介绍平台、用户、设计、发现与商业化，再由 Creator Experts 和 Meta Staff 带大家熟悉 Desktop Editor、TypeScript、Horizon APIs、交互和移动端优化，最后把这些内容压缩进一次真正的创作实践。1
对我而言，三天大概可以压缩成这样：
| 时间 | 我最主要的感受 |
|---|---|
| Day 1 | Meta Office、分享、认识 Creator、Happy Hour，快速进入一个完全不同的创作者环境 |
| Day 2 | 学习工具链、TypeScript 与 Horizon APIs，同时开始 Jam，项目很快进入高压开发 |
| Day 3 | 继续开发、测试、发布、展示与收尾，开始意识到“做出来”和“被理解”并不是同一回事 |
官方后来把 Boopi、BoomBoomBean、You Are Plane、Thai Ghost 列为这次首尔活动的四个 Standout Worlds。1 这件事后来也成为我复盘自己作品时一个很重要的参照。
这篇文章主要记录我自己的 Jam 经历和事后反思。活动规模、日期、公开课程内容与 Standout Worlds 使用 Meta 官方回顾核对；具体开发过程、合作和判断则是个人视角。
3从零开始的一天半
这次 Jam 对我最直接的挑战，是我并不是游戏开发新手，却几乎是 Horizon Worlds 的平台新手。
我平时主要做 Unity、VR、物理交互和沙盒游戏开发，因此“怎样设计一个游戏系统”并不陌生。但到了 Jam 现场，具体工具完全变了：Desktop Editor、TypeScript、Horizon APIs、Player、Attach、Collision、UI、多人状态……很多东西都需要边查、边试、边建立认知。
正常学习一个新平台时，人会先做 Tutorial，再做几个小实验，逐渐知道什么能做、什么不能做，最后才开始正式项目。
Hackathon 刚好相反。
你先决定要做什么，然后在截止时间的倒计时里，被迫把缺少的知识补上。
这是一种非常不舒服、但学习密度极高的状态。
3.1可迁移的不是 API，而是解决问题的方法
这次经历也让我更确信：真正能跨技术栈迁移的，并不是记住多少 API。
我可以完全不知道 Horizon Worlds 某个具体接口叫什么，但过去积累的工程习惯仍然有效：
- 先把需求拆成独立问题；
- 找到最不确定、风险最高的部分；
- 做最小实验验证它到底可不可行；
- 区分游戏规则、玩家状态和表现层；
- 出问题时先缩小范围，而不是整套系统一起乱改；
- 先让核心循环跑起来，再处理扩展功能。
换句话说，工具链会变，但下面这条链不会那么容易过时：
理解问题 → 建立模型 → 找到证据 → 实现 → 验证。
这可能也是我能在这么短时间里上手的根本原因。过去那些个人项目、工作中的 Debug 和系统开发，并没有直接告诉我 Horizon API 应该怎么写，却训练了我面对一个陌生系统时应该怎样推进。
4Ducky Bumpy Arena
我们的 Jam 作品叫 Ducky Bumpy Arena。
如果只用一句话描述：
一群小鸭子在不断缩小的泳池里互相撞飞；掉出去可以无限复活，在限时内把最多玩家弹出场地的人获胜。
它很简单，也很荒诞。
这正是我们想要的。
4.1核心循环
当时 Jam 的主题强调 Humor 与 Absurdity，我们希望玩法本身就能制造滑稽场面，而不是靠对白或剧情告诉玩家“这里很好笑”。
鸭子的形象承担了一部分荒诞感；多人碰撞承担了不可预测性；不断缩小的水池让局面越来越拥挤；无限复活则保证玩家即使掉下去，也不会在剩余时间里只能旁观。
从设计上说，我现在仍然觉得这个核心想法是成立的。
尤其当几只鸭子真的在很小的平台上互相乱撞时，游戏会自然产生一种很强的混乱感。它不是精确竞技，更像一种大家不断把局面搞得更糟的 Party Game。
4.2真正困难的是多人状态
规则本身并不复杂，真正让项目迅速膨胀的是多人。
单机里，“玩家掉下去了”可能只是一次位置重置；多人里却会立刻出现一串问题：
谁把谁撞出去？
什么时候算一次有效击落？
本地和远端分别知道什么？
Respawn 后玩家状态怎样恢复？
排行榜什么时候更新？
比赛开始和结束如何同步？
玩家加入、离开或状态异常时怎么办？
再加上碰撞、Attach、UI 与各种 Horizon API，这个游戏很快从“一个简单的鸭子互撞小游戏”变成了一组互相依赖的状态机。
而我们只有大约一天半真正能持续开发，白天还有课程。
现在回头看，这其实已经埋下了后面最大的风险：我们选择的是一个概念简单、实现却并不小的作品。
5我仍然为执行力感到骄傲
这篇复盘并不是为了事后证明“我们当时全都做错了”。
恰恰相反，我仍然很为那两天的执行感到骄傲。
我是在几乎刚接触 Horizon Worlds、TypeScript 和相关 API 的情况下开始这个项目，却最终把多人玩家管理、碰撞、计分、复活和基本比赛循环连接了起来。Pauline 也同时承担了游戏设计、美术和大量视觉工作。我们是在一个很陌生的环境里合作，最终确实做出了一个可以玩的东西。
这件事对我很重要，因为它验证了我过去最有信心的一种能力：面对陌生问题时，能够快速学习并推进到可运行的结果。
问题是，Hackathon 最后也让我看见了这种能力的边界。
一个作品能够被实现，不代表它就是最适合那次 Jam 的作品。
一个系统技术上更复杂，也不代表它在有限的评审时间里更有价值。
真正值得复盘的，不是“为什么我们做得这么难却没有被选中”，而是：
为什么我们会自然地把“更难做”误认为“更值得做”？
6复杂并不自动意味着更好
这是我从这次 Jam 带走的最重要教训之一。
我很容易对技术难度产生偏爱。多人、状态同步、碰撞、复杂系统，对工程师来说很有吸引力，因为这些问题真的难，解决以后也会产生非常直接的成就感。
可 Hackathon 并不是一场“谁实现的系统最复杂”的比赛。
它更像是在问：
在极短时间里，你能不能把一个有意思的想法变成一个完整、清晰、能被别人立刻感受到的体验？
这两种目标并不完全相同。
6.1Ducky Bumpy Arena 与 Boopi
Meta 官方最后列出的 Standout Worlds 里有 Boopi。1
我后来经常拿它和自己的作品做对比，不是为了说谁“技术更强”，而是因为这种对比很能说明问题。
Ducky Bumpy Arena 的乐趣依赖真正的多人状态：需要多个人同时进来，理解规则，然后真的开始互相撞。最精彩的地方往往不是打开游戏第一秒就出现，而是几个人逐渐挤到更小的水池里，场面开始失控的时候。
而一个更聚焦、更容易单人理解的体验，对评审来说有天然优势：不需要先组织多人，不需要解释一整套状态，几秒钟就能知道“我要做什么”，也更容易把剩余时间用于视觉、动画、音效和手感。
所以真正值得比较的，并不是：
多人比单机复杂多少？
而是：
一个陌生人需要多久，才能感受到作品最好的那一部分？
这才是我们真正吃亏的地方。
6.2没有被体验到的价值，等于没有完成传递
如果一个作品内部做了很多事情，但玩家没有进入那个状态，那么这些价值对玩家而言并不存在。
我现在会用一个很粗糙的式子提醒自己：
这当然不是一个严谨的数学模型。它只是提醒我：如果后一个因子接近 0，前面再高也很难发挥出来。
Hackathon 尤其如此，因为评委的注意力本身就是稀缺资源。一个项目可能花了两天做复杂系统，但如果必须试玩十分钟才能进入状态，而另一个项目十秒就能把核心体验交到面前，后者在这种场景下往往更有效。
这不是“会包装比真正做好更重要”。
恰恰相反。
展示、Onboarding 和第一分钟体验，本来就是产品的一部分。
Meta 自己在活动最后也专门安排了 brand-building 环节，让 Creator 为刚发布的 World 制作社交内容；官方回顾对此的总结很直接：发布只是故事的一半，另一半是把它分享出去。1
6.3Demo 应该从第一天开始设计
我们当时更像是：
如果再来一次，我会把顺序反过来：
“怎么展示”不应该是作品做完以后的包装问题，而应该在设计阶段就决定。
如果核心玩法依赖多人，那就应该尽早思考：
- 没凑齐人时还能不能看懂？
- 能不能用 Bot、录像或其他方式展示关键时刻？
- 第一次进入的人需要几句话才能开始？
- 最有趣的一幕能不能在一分钟以内稳定出现？
- 有没有一个极其明确的视觉焦点？
这些问题并不降低作品的技术含量，反而是在决定技术投入最终能不能转换成真实体验。
7Hackathon 不是缩短版的正式项目
我以前很容易把 Hackathon 理解成“正式项目，只是时间更短”。
现在我觉得这个理解并不准确。
正式项目需要考虑长期维护、扩展性、内容规模、技术债和持续运营；Hackathon 的资源模型完全不同。它通常是在极短时间里验证一个概念，并把概念压缩成别人能够立即理解的成品。
两者优化目标不同：
| 正式项目更关注 | Hackathon 更关注 |
|---|---|
| 长期架构 | 核心概念 |
| 扩展性 | 可理解性 |
| 完整功能链 | 最小但完整的体验 |
| 持续迭代 | 截止时间前的完成度 |
| 长期技术成本 | Demo 与第一印象 |
| 未来需求 | 现在真正能展示什么 |
在正式项目里，多做一层基础设施也许是在为未来省成本；在一天半的 Jam 里，多做一层基础设施可能就是少半天 Polish。
这也是一个很反直觉的地方：
能力越强，有时反而越容易 Scope 过大。
因为你知道自己“应该能做出来”，于是会不断把更多问题纳入实现范围。最后真正的失败不一定是某个 API 写不出来，而是没有及时问：
就算能做出来，它值得在这两天里做吗？
8人比作品更重要
如果只把 Creator Academy 当成一个比赛，其实会错过它最珍贵的部分。
我以前可以在网上看到来自世界各地的开发者，也可以读他们的帖子、看他们的作品，但三天里和这么多不同背景的 Creator 待在同一个空间，感受完全不同。
官方统计显示，这次首尔活动有来自 9 个国家和地区的 100 多名 Creator。1 对我来说，高密度的人本身就是信息：不同的人怎样理解游戏、怎样介绍自己的作品、怎样和陌生人合作、怎样处理不熟悉的工具，这些东西很难从文档里学到。
8.1和 Pauline 做一个游戏
我这次 Jam 的 Partner 是 Pauline。
在我的印象里，她同时具有游戏开发、设计和美术方面的能力。对我来说，这种合作方式很新鲜：我会很自然地从系统、功能和“这个逻辑能不能跑”出发，而她会更多考虑一个 World 看起来是什么感觉、玩家第一眼会看到什么、怎样让一个想法具有明确的视觉形象。
Ducky Bumpy Arena 最终能够成为一个真正的“作品”，而不只是我电脑里的一堆多人逻辑，很大程度上来自这种不同能力的组合。
Hackathon 很适合暴露一个事实：
合作的意义并不是两个人把工作量除以二，而是把两个不同的视角叠在一起。
如果两个人思考方式完全一样，合作可能只是加速；如果视角互补，才可能改变最后做出来的东西。
9我和 Lven：一次真正让我后悔的沟通失误
这次活动里，我最需要认真记录的一个错误，和代码没有关系。
我是和 Lven 一起来首尔的。他是我们的主美和美术总监，也是我非常敬重、关系非常好的前辈。
出发以前，我们并没有把“Jam 时要不要一起组队”这件事明确说开。
我当时有一个很强的念头：既然难得来到一个国际活动，我想尽可能认识不同国家的创作者，和不同的人合作，从而获得更多平时没有机会获得的经验。这个动机本身，我现在仍然觉得没有问题。
问题是，我把它留在了自己的脑子里。
第二天早上又发生了一些很混乱的小事。我没有及时看到他的消息，自己匆忙去吃了早餐；到了活动现场以后，我先认识其他 Creator，后来又在一种很仓促的状态下和 Pauline 组了队。
我没有先和 Lven 把这件事说清楚。
最后，他一个人做了自己的 Jam 项目。
后来他还找过我帮忙做功能，但那时我已经完全陷在自己这边的多人系统里，没有抽出时间。
事情结束以后，我越想越觉得自己处理得很差。
9.1动机合理，不代表过程没有问题
最开始我会下意识给自己解释：
我只是想和其他 Creator 合作。
我只是想最大化学习。
我并不是故意不和他组队。
这些都是真的。
但它们并不能消除另一个同样真实的事实：
一个会影响另一个人的决定，我没有提前和他沟通。
我脑子里的意图不会自动传输给别人。
我看到的是“尝试一次新的合作”；别人实际经历到的，却可能是“我们一起来参加活动，你突然和别人组队，而且没有提前告诉我”。
后来我认真向他道歉。他也坦率地告诉我，当时确实觉得这件事情做得不太对；但既然已经把话说开，他也没有再追究，我们的关系依然很好。
这次经历让我记住了一件很朴素的事：
解释不能代替提前沟通。
很多合作冲突并不是因为谁有恶意，而是双方从来没有在开始之前明确过各自默认的东西。
9.2合作问题往往发生在真正开始工作之前
如果以后再参加类似活动，我会在 Jam 开始以前就明确几件事：
- 我们是否默认一起组队？
- 如果想和其他人合作，要不要提前说？
- 各自最想从活动里获得什么？
- 谁负责什么？
- 如果两个项目同时出现紧急问题，优先级是什么？
- 有没有彼此期待但从来没有说出口的事情？
这些问题看起来不像“开发”，却会直接决定开发过程里的信任和体验。
10Networking：不要为了认识人而制造问题
Creator Academy 也让我反思了另一种“主动”。
我本来比较内向，后来一直有意识训练自己更主动地认识人、争取机会。这件事总体上给我带来了非常大的收益。
但在这种活动里，我也会很容易进入一种奇怪状态：
这个人很厉害，我难得见到他，我应该和他说点什么。
于是“我真的有什么问题”会慢慢变成“我必须想一个问题”。
我有过这样的交流：本来只是为了有机会认识一位更高级别的人，于是问了一个和 Horizon Worlds 在中国大陆可用性有关的问题。对方很认真回答了平台、语言、商业和地区条件等限制，但对话后来逐渐转向一些其实不值得占用对方时间的个人问题。
事后我真正后悔的，并不是“问错了一个问题”，而是我意识到：
我把建立联系本身当成了目标。
10.1有价值的交流，比“聊上了”更重要
现在我更愿意区分两种主动：
一种是为了证明“我很积极，所以我要说点什么”。
另一种是我真的有一个经过思考的问题，而对方恰好是最适合回答的人。
后者即使只有两分钟，也可能很有价值；前者即使聊了很久，最后留下的可能只是尴尬。
所以如果以后再遇到优秀的 Creator、老师或行业前辈，我希望自己先问：
这个问题为什么值得问他？我自己已经做过什么功课？他的回答真的可能改变我的判断吗？
Networking 对我来说不应该是“尽量认识更多人”，而应该是尽量产生真实、尊重彼此时间的交流。
这也和我后来在工作里的另一个反思很像：主动应该服务于事情，而不是服务于存在感。
11如果再参加一次 Hackathon
如果今天让我重新参加一次类似的 Jam，我不会只是告诉自己“下次再努力一点”。
这次最大的问题从来不是努力不够。
某种意义上，我们甚至努力过头了。
真正需要改变的是策略。
| 这次更接近 | 下一次我会尝试 |
|---|---|
| 先看自己能实现多复杂 | 先定义一个 10 秒能理解的核心体验 |
| 功能越做越多 | 尽早冻结 Must-have Scope |
| 多人是玩法前提 | 提前准备单人也能理解的 Demo |
| 最后才考虑展示 | 第一天就设计 Demo 和第一分钟体验 |
| 大量时间用于功能实现 | 强制给 Polish、Onboarding、音画反馈留时间 |
| 出现 Bug 后继续补系统 | 先问这个功能是否真的值得救 |
| 临时决定合作关系 | Jam 开始前确认队友、目标和优先级 |
| 为了认识人而主动聊天 | 有真实问题和价值时再交流 |
1. 先写一句话 Pitch
如果我不能用一句话让完全不了解项目的人知道它为什么有意思，说明概念可能还没有收敛。
Ducky Bumpy Arena 现在其实可以很快描述清楚：
小鸭子在不断缩小的泳池里互相撞飞，限时内击落最多玩家的人获胜。
下一步就应该继续问：
这句话里哪一部分是绝对不能丢的？
鸭子？
互相撞飞？
缩圈？
计分？
多人？
如果必须删掉一半功能，留下什么仍然能让这个作品成立？
这才是 Hackathon 的 Scope。
2. 最早验证最危险的假设
如果核心玩法依赖多人，那就不能先把 UI、场景和附加规则全部做好，再在最后发现多人逻辑不稳定。
应该第一时间验证：
两个真实玩家能不能进入同一个核心循环，而且真的好玩？
如果答案是否定的，越早知道越便宜。
3. 先让它完整，再让它复杂
过去我很容易把“完成度”理解成“功能数量”。
现在我更愿意区分：
- 功能多不多；
- 核心循环有没有闭环；
- 第一次进入是否知道做什么；
- 操作有没有反馈；
- 输赢是否清楚；
- 视觉是否统一；
- 游戏结束以后是否有明确收尾。
一个只有一个机制、但从进入到结束都完整的作品，往往比一个有五套系统、每套都差最后 20% 的作品更像真正的游戏。
4. 为展示保留明确预算
不是“如果最后有时间再 Polish”。
而是一开始就决定：
最后几个小时不再加系统，只修体验和展示。
因为在 Hackathon 里，展示并不是额外工作。
它就是交付的一部分。
12没有成为 Standout，并不等于这次失败
我当时当然很希望作品能得到认可。
尤其两天几乎没有睡，最后看到结果时，很难完全没有失落。
但隔了一段时间再看，我不太想用“获奖 / 没获奖”定义这次经历。
Meta 最终发布了 49 个 World 或 Asset，并选出了四个 Standout Worlds。1 从评审角度看，他们当然需要在有限时间里选择最能够代表活动成果的作品；而从我自己的角度看，这次 Jam 的价值却远不止那一个结果。
它至少让我确认了三件事。
12.1工程：我确实可以在陌生环境里快速做出来
面对几乎陌生的平台，我可以快速建立认知、解决问题并完成一个多人游戏原型。
这份自信我不想因为结果不好就丢掉。
12.2产品：技术价值必须转换成用户能感受到的体验
复杂不是价值本身。
如果一个玩家需要很久才能理解作品最好玩的地方，那么设计就还有问题。
如果一个评委必须先听我解释系统有多难，才能知道它为什么好，那么 Demo 就还有问题。
“我做了什么”和“别人感受到了什么”之间，永远存在一段需要主动设计的距离。
12.3合作：意图不会自动成为共识
我可以没有恶意，甚至有很合理的动机，但如果没有提前沟通，仍然可能伤害合作关系。
技术问题通常会报错。
沟通问题不会。
它往往直到事情结束以后，才让人意识到哪里不对。
这次 Jam 最重要的收获，不是学会了多少 Horizon API，而是第一次非常集中地看见：工程能力只是创作的一部分。产品需要被理解，合作需要被沟通，而有限时间里最重要的能力之一，是知道什么不做。
13三天以后，我真正带走了什么
活动结束的最后一晚，大家去了高楼上的 Rooftop Lounge 收尾。前面两天几乎一直处于赶不完、修不完、来不及的状态，到了那个时候才突然意识到：真的结束了。
三天很短。
短到工具链才刚刚熟一点，活动就结束了；短到很多认识的人还没来得及真正了解，就要分别；短到一个游戏从不存在到发布，只经历了一个周末都不到的时间。
但也正因为短，一切都被压缩得非常明显。
平时一个项目做几个月，问题可以被流程掩盖。Scope 大一点，好像还有下个 Sprint；Onboarding 不够好，可以下个版本再修；合作里没说清楚的事情，也许过几天还有机会慢慢解释。
Jam 不给这种缓冲。
它会逼着所有问题立刻显现。
你会看到自己最熟悉的能力到底能不能迁移，也会看到自己一直依赖的优势在哪里突然失效；会发现一个作品“很难做”和“很好”不是同义词，也会发现一个人的好意和另一个人的感受并不是同一件事。
所以我才会觉得，这三天像三年。
不是因为我在三天里学会了三年的 TypeScript。
而是因为一些原本可能要在未来几年里一点点遇到的问题——关于工程、产品、合作和自己——在这三天里同时撞了过来。
如果以后还有机会再参加 Hackathon，我当然希望做出一个更漂亮、更聚焦、完成度更高的作品，也希望自己能够更从容地和优秀的人交流、合作。
但下一次我最想带上的，并不是“这次少写几个 Bug”。
而是这三个问题：
它真的值得做吗？
别人能迅速感受到它为什么好吗？
和我一起做这件事的人，我们真的把话说清楚了吗？
这大概就是 MHCP Seoul 2025 真正留给我的东西。
注释
CONTINUE EXPLORING