Files
dc-docs/output/feishu-docs/O481wRPFfiU8IIk2dwScMyTWnjg.md
T
2026-07-11 12:30:54 +08:00

11 KiB
Raw Blame History

O481wRPFfiU8IIk2dwScMyTWnjg

Source: https://dianchukeji.feishu.cn/wiki/O481wRPFfiU8IIk2dwScMyTWnjg

1.工作内容概述

  • 继续拆解、记录实机数据,初步分析其中的数学规律
  • 学习积累二合类的数值设计基础知识
  • 研究AI建模分析的方法
  • 优化当前的内容
    • 订单流水线动画
    • 主界面剧情按钮
    • 仓库界面
    • 整理存档机制,新增2个重置调试按钮

2.进度

2.1 继续拆解、记录实机数据,初步分析其中的数学规律

- 今天拆解到第26个订单、第15个剧情

图片 图片 - 初步尝试让AI分析当前的表格,得出一些规律 图片 - 提示词方式 - 给出数值记录表 - 让AI从数值模型的角度分析 图片 - 订单等级分布中,AI总结得出 - 订单需求整体是“低阶密集 + 高阶稀疏”的结构 - Lv3~5 是核心消耗区,这些低等级物品始终存在于大部分订单中 - 5级以上的物品作为高难度挑战 图片 - 从生成器使用分布中,AI总结出 - 系统是“双生成器经济”,但权重明显不均 - 轻篮生成器:23次 - 咖啡机生成器:18次 - 咖啡机的作用不是平衡,而是: - 提供“变化” - 制造“稀有订单” - 拉开“难度差” 图片 - 从物品等级vs平均奖励的分析,AI总结出 - 奖励多集中在中等级的物品(3级到5级),高等级物品主要当成高难度挑战 - 反思 - AI分析数值的角度太浅,分析出来的结论对实际数值设计帮助不大 - 后续改进优化 - 仍然需要人来思考分析数值的角度:AI是辅助从数值中总结规律,但是它不能定义方向。要从什么角度分析,仍然要靠人 - 使用AI建模分析的方法不太对,这个需要进一步研究

2.2 学习积累二合类的数值设计基础知识

2.2.1 订单奖励模型

  - 订单奖励不能按指数级增长,一般二合的常见做法都是
    - “指数成本”定义高阶物有多难,再用“幂律压缩”设定高阶物值多少钱
  - 奖励是线性的:奖励跟着成本走,那么就是下面这样
    - 但是奖励指数增长,并不符合玩家体验
    - 所以问题是:如何设计奖励增长曲线,保证适配玩家体验的同时,又能适配成本的增长趋势

成本 线性奖励 16 16 512 512 16384 16384 - 用“幂律压缩”设计的奖励: 成本 线性奖励 幂律奖励(β=0.7) 10 10 5 100 100 25 1000 1000 125 10000 10000 630 - 成本是2的n-1次方,但奖励不是2的n-1次方的倍数,而是用幂律函数来设定 - 奖励一般是: 图片 - 其中 符号 作用 Cost 表示“做这个东西有多难”(指数增长) β 控制“难度 → 奖励增长有多慢”(压缩程度) a 控制“整体奖励规模有多大” - 如何理解:相当于给奖励做了第二套的指数增长曲线,但是这套指数增长曲线是可以认为调控的,可以比成本高,也可以比成本低 - 这样做的好处 - 奖励被控制在合理区别,不会随着二合成本的指数增长而增长 - 但是奖励本身数值的增长曲线,是跟着成本的增长曲线一起上升的

2.2.2 剧情 / 装修消耗模型

  - 二合游戏里金币通常不是自由经济货币,而是剧情推进门票。
    - 玩家完成订单获得金币
    - 金币再用于:清理餐厅、装修场景、解锁剧情、升级区域
  - 二合游戏一般用分段函数来设计剧情消耗的金币

图片 - 对应的体验就是: 阶段 消耗曲线 体验目标 新手期 低线性增长 快速装修、快速看剧情 成长期 次指数增长 开始需要多订单积累 后期 分段指数 / 高阶任务 多日目标、付费压力、活动参与

2.2.3 体力模型

  - 体力模型的意义是控制玩家的游玩节奏
  - 二合常用的基础公式为

图片 - 其中: - E(max)为体力上限 - E(0)当前体力 - r:恢复速度 - t:离线时间

2.2.4 棋盘空间模型

  - 除了成本压力,二合游戏还有棋盘空间带来的压力
  - 基础公式

图片 - 其中 - occupancy:空间利用率 - G:棋盘总格子数 - UUU:已占用格子数 - S=G−US=G-US=G−U:空闲格子数 - 二合游戏会用空间利用率为关键指标,判断玩家压力 - 一般设置一个压力阈值, - 例如:空间利用率大于95%,玩家可使用的格子只有5%,则判断玩家进入高压状态 - 一般用这个数值来 - 实时调节订单难度 - 1设置付费点

2.3 研究AI建模分析的方法

个人认为,AI建模分析主要有以下2种使用方法 - 规则抽象层:帮助人梳理数值之间的关系 - 输入: - 记录好的Excel数值表 - 人为规定的数值分析角度 - 例如:分析二合游戏中等级与奖励之间的关系 - AI做的事情: - 按照人为规定的方向,把复杂现实简化成变量和关系、建立数学模型 - 例如:总结出2个数值之间关系的数学公式。是A=B还是A=2B? - 产出 - 数学建模公式 - 可解释的数值关系 - 前向模拟层:在上一层的基础上,进行计算与验证,用数学模型模拟实际的游玩过程 - 输入: - 数学模型 - 玩家行为规则 - AI做的事情:根据数学模型和规则,模拟玩家游玩的过程,推导未来的数值演变 - 输出 - 确定的数值结果,例如 - 玩家每完成一个平均消耗成本 - 玩家每完成一个订单点击的次数

2.4 优化当前的内容

2.4.1 订单流水线动画

  - 之前订单完成并退出时,会有卡顿
  - 修复后效果

2.4.2 主界面剧情按钮

  - 参考《浪漫餐厅》的样式,优化主界面的剧情按钮

图片

2.4.3 仓库界面

  - 实现了完整的仓库栏位解锁机制

2.4.4 整理存档机制,新增2个重置调试按钮

  - 重置玩家存档:重置所有进度包括棋盘进度、体力金币钻石的数量、剧情进度等
  - 重置仓库:重置仓库栏位解锁的进度

3.收获与反思

  • 像数值拆解这种需要大量经验、判断力的工作,AI只能当辅助
    • 后续用AI分析数值时,应当先自己定义好拆解的角度、方向,让AI辅助梳理

4.下一步计划

  • 调研拆解
    • 继续拆解、记录实机数据
    • 根据实机数据,总结反推出数值设计规律
    • 学习积累二合类的数值设计基础知识(对于数值调研拆解,基础数值设计知识很重要)
  • 美术线
    • 在拆解调研的空余时间中,抽空优化相关美术资源

5.项目规划

参考: https://jasminehuang477-cmd.github.io/share_hyper_casual_game_design_guide/#s10 https://merge2iaa-selectionanalysis.netlify.app/

  • 开发计划:
    • 任务详情看第二个文档的十、两周开发建议节奏
    • 非开发计划中的内容,不优先开发
  • 拆解调研任务 目标 核心任务 完成情况 完成《浪漫餐厅》关卡/数值相关设计拆解分析,说明从中收获了哪些二合类游戏设计的关键认知,输出拆解分析报告并进行内部分享
    • ok——写拆解分析报告大纲
    • 对《浪漫餐厅》关卡/数值相关设计进行拆解分析
      • 实机记录数据(完成后才方便做下面的内容)
        • 需要反思如何改进
      • 学习数值拆解调研的方法
        • 研究AI建模分析的方法
        • ok—在网上学习数值调研拆解相关的方法
        • ok—向楚真日报学习
        • 问刘鹏
      • 学习积累二合类的数值设计基础知识(对于数值调研拆解,基础数值设计知识很重要)
      • 从微观反推宏观内容:研究对具体设计组合的抽象、理解、演化方向预判
      • 数值拆解方向
        • (核心)订单数值
        • 棋盘关卡
      • 需要结合订单刷新机制
    • 总结《浪漫餐厅》关卡/数值相关设计的规律
    • 总结二合类游戏设计的关键认知
    • 整理以上2点内容,进行内部分享
    • 使用自动化批量关卡生成方案+分析的关卡和数值设计规律+订单刷新机制,铺量关卡。目标是铺至少40单的游戏内容量(大概1个小时左右的游玩流程)

30%

  • 上线前要完成的任务 目标 核心任务 完成情况 关卡和数值设计铺量
    • 对《浪漫餐厅》关卡/数值相关设计进行拆解分析
      • 需要跟之前的订单刷新机制结合起来
    • 总结《浪漫餐厅》关卡/数值相关设计的规律
    • 用AI生成并配置好类似规律的关卡和数值

30%

基础功能 - 文本提示信息框——完成 - 购买弹窗——暂时搁置 - 边缘系统

75%

商业化 - 上架微信小游戏 - UI适配(已经跑通流程,只需要再操作一遍) - 打包优化(已经跑通流程,只需要再操作一遍)

30%

更换新主题的美术资源 - 持续优化美术资源生成管线 - 目前还差 - 仓库界面 - 个人信息界面 - 思考问题 - 继续解决美术风格的饱和度问题和AI味道问题 - 物品链和生成器链考虑优化美术资源 - 将笔刷、毛刷等物品加入,弥补目前物品链物品过于相似的问题

95%

优化 - 手感调优 - 上线前测试找bug

40%