Dev GardenGreenhouse Notes
查看 Markdown 原件 打开原型
Design Documentdesign/system-review-beta48.md

现有系统审视:保留、深化、合并与冻结

日期:2026-09-07。基于当前 beta48 本地代码、已有试玩记录和用户确认的方向。这里是设计判断,不是玩家行为统计,也不是删除批准。本轮没有改动玩法或旧存档。

判断基准

主体是种植与经营:看到自己养出的成果,决定它的去向,用收益改变温室。安静挂机应可持续,主动经营应带来可感知的优势。故事、收集与随机惊喜可以加强它,不必全部变成赚钱工具。

审视一个系统时问:

  1. 拿掉后,玩家失去的是一种独特的快乐/选择,还是只是少读一块界面?
  2. 能否影响下一次种植、收获、投入,或者留下值得欣赏与记住的成果?
  3. 初次解锁后,它是否还会带来变化?一次性成长奖励完成使命不等于失败。
  4. 它与其他机制是合作还是重复?玩家是否需要为同一件事学习多套规则?
  5. 乐趣是否抵得上学习、操作和维护成本?当前证据不够时标待验证,不虚构精确评分。

系统盘点

系统建议独特价值与风险后续判断依据
种植、生长、照料、开花核心保留、优先深化养育与收获的主体;若只变进度条,视觉成果和主动照料的回报仍不足能否记住自己养过的一盆,理解照料收益
安静挂机、离线成长与归来反馈核心保留不是需要惩罚才能成立的低效模式;离开后应有可期待结果不盯屏能前进,回来知道发生了什么
收花入库、整株寄售核心保留、重平衡现金与材料的去向;价差过大或需求无限时会变成标准答案是否出现合理的即时回款与继续攒花两种选择
常驻花束与大宗订单核心保留、优先深化赋予种植组合与钱的来源;周单优势与固定配方可能令路线单一不同阶段是否有不同合适路线,而非全程追唯一最高价
扩建与分期核心保留让收益换成可见空间与生产能力等待是否空洞,扩建后是否改变玩法;暂不加逾期利息
滴灌、集中水箱、肥土机、批量收获核心支持、保留解放重复操作,是成长奖励自动化前后确实更轻松;不撤回便利性制造需求
温室大师保留但冻结扩充付费商业托管,不等于普通浇水设备;目前管理薄荷与金盏花收益和服务边界清楚,留下扩建/投入决策;不加多个称号档位
成长路线与科研入口保留并分工成长负责短期方向,科研负责新能力;重复门槛会成为两套任务清单同一成果是否要求多次领取/解锁;不是机械砍到固定节点数
观察笔记高风险,优先重审当前主要消费是研究;研究完后可能只剩累积数字检查真实产出与用途;不为消耗它新增一个兑换商店
土壤酸碱与绣球颜色高潜力,窄范围深化少数已能影响外观和订单的栽培选择颜色差异看得见、需求用得上;不扩成每盆多参数仪表盘
土壤养分与堆肥保留、减负生长投入和收获回流;阈值操作容易变第二套浇水与自动肥土、投入回报一起核算,避免额外频繁提醒
留株、再开花、留种有潜力、暂缓扩种同一株持续养育、花与种子的取舍必须有有用的种子需求与合理周期,不能只制造无限库存
蝴蝶兰精养与样株保留可选试验、冻结扩充观察与个体差异的候选,不应强迫所有玩家精养是否有不同于盯数值的判断与值得保留的结果
植物差异与图鉴保留收藏、辨识与不同生产用途新品种至少有一个可感知差异,不以数量扩内容
访客出现、授粉、携种、伴生条件有潜力、保留花园有生命,配置能带来发现;不必全用于订单玩家能否为了某个访客改变组合,而不是自动刷数字
访客卡片等级合并/精简候选等级目前参与部分门槛;与图鉴、笔记可能重复记账保留有具体效果的等级,其他可回归图鉴进度;需迁移门槛
蚜虫与生物防治保留但不扩病虫清单有限照料差异和生态联系;不应重新变成催办器处理影响清楚、频率可接受,不靠强制手动刷次数
鸡肥、超级鸡肥、金坷垃冻结档位、合并候选主动花钱换时间;当前多为速度/时长/价格区别没有不同使用场景就保留为同一道具升级,不占多套学习空间
水费、供水账单、循环节水收缩候选给自动化成本与节水投资;若无实质决策则只增加焦虑优先考察并入设备运营成本,默认自动处理;不加罚款或复杂能源
阿溪代售花摊与余量选择限期验证、冻结扩充处理材料余量;30分钟等待与不确定销量可能只是多一步手续实际是否用于有意识的去库存;若无独特价值,并入库存代售而非独立工作区
春季杯的命题种植与评分保留可选内容、冻结扩充检验培育成果的潜力,与赚钱订单不同玩家是否愿意为评审改种/调土,而不只是走八个流程
春季杯花市与三档定价优先合并/退场候选与普通销售、代售重叠,增加第二套经营教学先测试压缩或跳过是否损失真实乐趣;不是立即删除已参加的活动
幸运转盘冻结扩充,候选独立可选奖励用户希望偶尔爆发式惊喜,这个诉求合理;与赛事绑定和普通奖励贬值是风险不做主线门槛;迁移前处理琉璃苣来源、保底进度与未领结果
林阿姨委托、回信、纪念物保留,少量深挖不扩写量已有用户明确正反馈,提供需求和记忆继续辅助种植经营;不转成主线阅读游戏、不让大师替玩家完成关键故事
云存档、恢复码、花园命名基础设施保留维护保护游玩投入与归属感,不应因不直接好玩就删可靠、少打扰、不会丢档
排行榜保留现有可选入口、冻结扩展有竞争意愿者的选择,不是必然无用;也不是当前留存解方不新增奖励压力;不因QA数据或未验证指标推断经营优劣
场景/账本、观赏画面、BGM体验支持保留看植物与密集操作是两种需求;视觉不是可无限推迟的装饰共用逻辑、减少重复界面维护;观赏需真实呈现成果
实时摘要、提示、日志、反馈、QA工具保留、界面合并可发现性与维护能力,不是独立玩法同一状态不多处催促;QA不计作游戏内容,重复通知应清理
草莓、遗传、交易、养蜂、能源扩展继续冻结/研究有潜力但未满足现有主循环的验证前置不是本轮已实现内容,不混入删除清单

最容易在迭代中失去作用的内容

  • 研究完成后的笔记、永久灌溉后的滴灌奖励、没有新效果的访客等级。
  • 只提高数值、没有新用途的肥料档位;无限留种但没有种苗需求。
  • 被高收益配方完全替代的基础订单;功能相同却更麻烦的销售入口。

这与“完成使命后退场”不同:新手任务结束、试用设备被升级替代是正常成长。应停止把退役道具当稀有奖品、收拢完成任务,而非强造新的用途让它永远活着。

维护和退出策略

  1. 本轮只做盘点。冻结 = 修bug与存档兼容仍继续,不投入新内容;不是放任损坏。
  2. 第一优先收缩的是重复流程和展示,不是消灭一种玩家喜欢的体验。
  3. 赛事花市、卡片等级、水务、代售工作区分别做可撤回的小实验;一次只改一处,记录玩家是否更轻松、是否丢掉选择。
  4. 真正删除前梳理解锁、种子来源、奖励、进行中状态、云存档、自动化依赖。已付钱、已得奖品和未结算收益必须保留或补偿;旧字段先兼容。
  5. 不以单个AI的偏好代替全部玩家。收集/偶发惊喜/安静观赏各有独立价值,也不能用“有人可能喜欢”无限保护所有功能。

修订后的开发顺序

  1. 先验证种植、订单、即售和投入的真实选择。余量代售也接受审视,不视为必保成果。
  2. 同一阶段核查成长与研究重复门槛、笔记价值和失效奖励;先停止继续堆叠。
  3. 验证扩建前后的体验跃迁,不先扩写更昂贵的等级。
  4. 选择一个收缩实验,优先赛事花市流程;先明确保留命题种植的什么乐趣,再决定跳过/合并方式。
  5. 深度候选优先绣球颜色与具体需求,其次配置植物吸引访客。完整遗传和新品种扩充仍暂缓。
  6. 用新档与中期档请挑剔玩家复测:问做了什么选择、期待什么结果、哪处只是手续,不问是否认可设计说明。

代码核对入口

  • 游戏规则与渲染 prototype/game.js:orders、getResearchProjects、getWholePlantSalePrice、getStallSurplus、EVENT_STAGES、CARETAKER、WATER_UTILITY。
  • 上一轮顺序方向复盘开发日志

结论不是“砍到只有种花”,而是让多样内容围绕少数强体验。当前最值得深化的是种植经营、可见的植物差异与成长成果;最值得收缩的是重复手续、弱消费和同一事物的多套进度。