zoukankan      html  css  js  c++  java
  • 手游(刀塔传奇类)数值设计思路流程

    手游数值特点

    相比于端游数值,手游(刀塔传奇类)数值的设计受手游系统的影响存在一些差异。这里,简单分析一下手游、端游之间一些大的差异之处,然后结合这些差异,试着进行手游数值的设计。

    • 单角色与多角色
    在游戏角色方面,大部分端游中玩家作为一个扮演者,扮演的是游戏世界中的一个角色(有时候角色也会配备一个宠物),玩家需要对这一个角色进行多方面的控制(例如行走、释放技能等等),而手游中玩家是作为一个控制者,手游的PVE(即常说的推图)玩法就是一个玩家控制多个角色上战场与多个怪物进行多次战斗的表现形式。因此,手游更多玩的是不同角色的收集和培养。
    • 数值深度与广度
    端游中玩家的消费主要承载在玩家所扮演的单个角色的成长线培养上,是从数值的深度(偏几率式)进行设计。而手游中玩家需要同时培养多个角色,将端游中单角色的深度培养转化为多角色的广度(多成长线偏积累式的)培养。手游多角色培养的特点为此带来的好处也是显而易见的:减轻单角色培养的压力;属性数值得到横向的扩充(可以这么理解:端游角色的攻击力一般在4-5位数,再多就像页游了,但是手游多个角色的攻击力总和达到6位数也不会让玩家感受不好),数值反馈更强烈直接。
    • 经济开环与闭环
    端游中玩家之间会有交易行为,是一个开环的经济(全开放:传奇永恒;半开放:镇魔曲)。手游中玩家只与系统进行交易,是一个闭环的经济。闭环经济有好有坏,好的一面是玩家作为个体在游戏里一个人也能单机玩下去,而且不用担心工作室破坏游戏生态,坏的一面是长久的玩下去会越玩越无聊,寿命较之端游会短很多,所以就会出现不停的开新服情况。
    经济设计方面,开环经济的端游中,物品的产出、流通、消耗存在各种穿插,属于多对多的关系,数值设计上较为复杂。而闭环经济的手游中,一种玩法或者活动的产出对应一条成长线的消耗,穿插较少,属于一对一的关系,数值设计上较为简单(这里的简单指的是不用考虑物品的流通,宏观层面的经济架构简单,但是对于物品的产出与消耗设计仍然要保持谨慎)。
    以上,分析了手游端游之间的三大差异点,在后面的手游数值设计时,会考虑这些差异点,进行数值设计思路上的一些调整。
    战斗体系
    1. 确定角色可能拥有的各种属性
      1. 属性的名称(种类)
        • 一般只有底层属性,属性与属性之间独立不相关
      2. 属性的类型
        • 数值型
        • 百分比型
      3. 属性的作用
        • 属性在什么时候进行计算
        • 属性在进行战斗计算时的位置
    2. 确定战斗规则
      1. 伤害判定规则
        • 命中、闪避、暴击、格挡判定
      2. 战斗计算公式
        • 值转率计算公式:涉及命中、闪避、暴击、格挡值转率
        • 伤害计算公式:涉及生命、攻击、防御及相关属性的计算
      3. 技能、BUFF这类数值在搭建完战斗模型后再进行嵌入
    3. 选取游戏中某一角色(卡牌)作为标准角色
    4. 设定游戏稳定期标准角色的数值预期
      1. 稳定期
        • 成长线、任务活动玩法绝大部分均已开放
      2. 基于数值感受设定
        • 一场战斗的时间预期
        • 标准角色在稳定期(比如65级)的属性数值预期
    5. 结合标准角色数值预期以及战斗公式,进行优化调整
      1. 优化调整战斗公式中的参数
      2. 优化调整标准角色的属性数值
    6. 设计属性数值随等级增长的曲线
      • 曲线拟合
    7. 结合增长曲线以及优化的属性数值预期,获得理论上不同等级下标准角色的标准属性数值
    8. 设定其他角色(卡牌)间属性数值差异化的程度
      1. 以标准角色为基准,数值差异化的程度为一比例关系,假定为k
      2. 某角色的标准属性数值=标准角色的标准属性数值×k
      3. 这里,不同角色(卡牌)之间允许有强弱之分,强角色的获得一般作为消费点
    9. 获得理论上的不同职业在各个等级下的标准属性数值
    10. 设定游戏内标准怪物的数值预期
      1. 一场战斗的时间预期
      2. 怪砍玩家伤害预期(结合玩家标准生命值)
    11. 结合标准怪物数值预期以及标准玩家标准属性数值,计算得到标准怪物在各个等级下的标准属性数值(理论值)
    12. 设定不同种类怪物间属性数值差异化的程度
      1. 以标准怪物为基准,数值差异化的程度为一比例关系,假定为s
      2. 某怪物的标准属性数值=标准怪物的标准属性数值×s
      3. 这一步需要在数值调优时不断优化标准怪物数值
    13. 获得理论上的不同种类怪物在各个等级下的标准属性数值
    经济体系
    • 确定消耗模块的物品(材料、货币、经验)
    • 确定产出模块的物品(材料、货币、经验)
    消耗模块(成长体系)
    1. 开放等级设定
      • 不同成长线在什么等级下进行开放
    2. 性价比设定
      • 规划不同成长线的性价比顺序
      • 设定完性价比顺序后,需要选取一条成长线作为基准消耗模块,其他消耗模块都会参照基准消耗模块进行数值设定工作,以及后续的数值优化调整工作
    3. 标准玩家状态
      • 设定标准角色在每条成长线中所处的状态
    4. 属性分配设定
      1. 规划不同成长线拥有的属性种类
      2. 设定不同成长线中各属性数值在标准属性数值内的占比
      3. 设定每条成长线下能够获取到的属性最大值
        • 通过设定比例k来求取,属性最大值=属性标准值*k
    5. 物品(材料、货币、经验)消耗设计
      1. 对每一条成长线,单独进行建模处理(VBA)
      2. 计算标准玩家的物品消耗、极限玩家的物品消耗
      3. 优化、调整数值
    6. 结合属性分配设定和物品消耗设计,计算出标准玩家的性价比
      1. 这里,可以同时获得其他层次玩家的性价比(需要对层次状态进行设定)
      2. 对比之前设定的性价比,进行数值优化调整,满足设定的预期
    说明:消耗模块的数值涉及到游戏的盈利,一般先于产出模块进行设计
    产出模块(任务、活动、玩法)
    1. 次数设定
      • 不同产出模块的挑战次数的设定
      • 一般与VIP等级挂钩,根据不同VIP等级确定各消费层次的玩家
    2. 开放等级设定
      • 不同任务、活动、玩法在什么等级下进行开放
      • 一般配合对应的成长线一起开放
    3. 性价比设定
      • 规划不同任务、活动、玩法的性价比顺序
      • 设定完性价比顺序后,需要选取其中一个作为基准产出模块,其他产出模块都会参照基准产出模块进行数值设定工作,以及后续的数值优化调整工作
    4. 标准玩家状态
      • 设定标准角色在每个产出模块中所处的状态(挑战次数)
    5. 物品(材料、货币、经验)产出设计
      • 对每个产出模块,单独进行建模处理(依据实际情况确定需不需要进行建模)
      • 计算标准玩家能够获得的奖励数量
      • 优化、调整数值
    6. 结合各产出模块的耗时和物品产出设计,计算出标准玩家的性价比
      • 对比之前设定的性价比,进行数值优化调整,满足设定的预期
    说明:标准玩家状态一旦设定好以后,对于产出是能够进行精确计算的(受挑战次数的限制)
    数值调优
    • 战斗体系数值调优
    1. 基于消耗模块,得出标准角色在各个等级下的实际标准属性数值
    2. 结合技能、BUFF,优化调整技能或BUFF参数、战斗公式参数,使之满足设定的标准角色数值预期
    3. 优化调整其他职业在各个等级下的实际标准属性数值
    4. 优化调整标准怪物的属性数值,同时获得其他种类怪物的优化属性数值
    • 经济体系数值调优
      • 不断进行产出模块、消耗模块两者的数值优化(基本上是对之前设定的数值进行反复调整,找出最优值的过程)
    数值配置
    • 代码完成前
    1. 在程序进行数值方面的代码实现时参与其中
    2. 规划需要用到的数值字段、表结构
    • 代码完成后
    1. 数值设计表中的数值转移到数值配置表
    2. 刷表生成配置文件,代入游戏进行体验验证
  • 相关阅读:
    mac下svn提交失败的解决方法
    mac终端下svn常用命令
    在Linux系统安装Nodejs 最简单步骤
    Cocos Creator学习笔记
    最好用的.NET敏捷开发框架-RDIFramework.NET V3.6版全新发布 100%源码授权
    史上最全面的SignalR系列教程-目录汇总
    RDIFramework.NET敏捷开发框架 ━ 工作流程组件介绍
    微信公众号开发系列-玩转微信开发-目录汇总
    RDIFramework.NET ━ .NET快速信息化系统开发框架 V3.3版本全新发布
    RDIFramework.NET代码生成器全新V3.5版本发布-重大升级
  • 原文地址:https://www.cnblogs.com/architecture101-gbt/p/8305752.html
Copyright © 2011-2022 走看看