TapTap 制造

第 2 期社区激励计划的积分已经全部到账了，大家可以去查看一下自己的积分余额。
这一周（3 月 16 日 - 3 月 22 日）我们收到了 70 篇帖子，其中 58 篇通过审核。本期有 12 篇被加精，比上一期多了不少。
首期活动传送门：
翻帖子的时候有个明显的感觉——这期大家写开发心得更愿意展开了，不只是"我做了个什么"，而是会聊到具体怎么实现的、踩了哪些坑、为什么选了某个方案。这类帖子读起来确

目前测试了多次，发现在服务端上并不能读取到之前的云存档。
当前联网模式下的存档读取流程是这样的：读取优先级（Server.lua _LoadPlayerData）：
先读 serverCloud（服务端云存储） — serverCloud:BatchGet(uid) 读取 sv_core、sv_military、sv_progress 三个分片
如果 serverCloud 有数据 → 直接使用，

要先给方案，先给个官方觉得有创意的游戏才能给资格？首先创意的审核人肯定是官方吧，这样考虑是不是有点不客观？这个审核人代表不了所有玩家啊~审核人觉得不好玩的不一定玩家不觉得好玩啊，反过来也一样审核人觉得好玩的，玩家不一定觉得好玩啊~其次，开放资格，参与的人多了，自然容易爆款的创意游戏概率就大了。爆款游戏如果是通过审核来界定的，这不是很不符合逻辑吗

本人有一个TapTap制造的邀请资格待赠，现举办一个小型游戏脑洞创意征集，经过综合考量之后，方案最优的参加者可以获得我的邀请资格，以期邀请到优秀创作者生产出好游戏。
设计要求：以我个人作品《闲趣一条街》游戏为背景——《闲趣一条街》是一个集合了各种趣味摊位的休闲游戏合集，致力于打造可编辑个人化的游戏街道。你需要在里面设计一个独立的游戏摊位。必须有计分机制（或类似），且每局分数结果存在不确定性。风格主

踩过的坑
1. clientCloud 与 serverCloud 是两套独立存储这是整个迁移过程中代价最大的一个坑。旧版单机架构使用 clientCloud（客户端云存储）保存玩家进度，迁移到服务端权威架构后改用 serverCloud。我们最初以为切换 API 就行了，结果发现：serverCloud 根本读不到 clientCloud 里的数据——它们是完全独立的存储空间，key 相同也不互

1. "Action 请求 → 服务端处理 → 状态广播"三段式架构这是我们最终采用的、经过验证的服务端权威架构模式：客户端 UI 操作 → Client.SendAction(action, params, callback)
→ 服务端 actionHandlers[action](playerInfo, params)
→ 修改 game state → pushStateToClien

起点：一段提示词引发的思考
在一次游戏文案协作中，我写下了这样一段提示词：
你好，我希望在这个对话当中，你将是一个非常耐心，富有创意但是尊重我的选择的游戏文案创作者，你每次会通过问各种简单的问题来确定我的需求，并根据我的需求给出创作内容，并且还会贴心的附上一些能够优化或者更有创意的小巧思来启发我。
回头看来，我意识到这段话里藏着一套完整的 AI 协作方法。它不只适用于文案创作——任何需要 AI 产

踩过的坑
1. 单文件膨胀到不可维护项目早期所有 UI 都写在一个文件里，迅速突破 2000 行。Lua 没有 class 关键字、没有 IDE 级别的重构工具，一旦单文件过大，查找函数、理解调用链都变得极其痛苦。后来拆分出 14 个 UI 文件（UIBattle、UIShop、UITech、UIMailbox 等），每个文件只负责一个功能面板，可维护性立刻改善。教训：Lua 项目 800 行就该