- game-design -

说明

在这个页面中，您将看到我在各种不同项目中设计的各种模块功能的：

• 系统案示例。
• 项目录屏，包括灰盒阶段、功能研发阶段以及上线阶段的内容。

一、系统案示例

1.1 系统相关

• 局内派对点奖励规则
• 战令通行证功能

1.2 战斗相关

• 占领模式战场规则
• 枪械后坐力规则

1.3 角色相关

• 角色设计：无聊猿

二、项目录屏

• Party Icon 封测阶段视频演示

• Dragon Brawlers 公测阶段主播演示

• Dragon Brawlers 龙王觉醒模式演示

三、随笔

• 复杂游戏系统设计与“涌现”理论

什么是系统？

系统的定义：系统是由一系列相互关联的组件组成的整体，这些组件之间的相互作用形成了系统的属性和行为，这些属性和行为不仅属于组件，还属于整个系统。

• 组件：它们具有内部状态、边界和行为。这些组件之间通过相互作用来形成系统的结构。
• 相互作用：组件之间的相互作用通过行为实现，这些行为通常涉及资源（如信息或物质）的流动。系统中的相互作用可能会形成循环，这些循环对系统的行为产生深远影响。
• 涌现：涌现是系统中强化循环和平衡循环的平衡状态，产生有组织的系统行为，这种行为不仅由组件的属性决定，还受到它们相互之间的关系影响。

组件和互动

组件（Components）

在系统中，组件指系统的基本构建单元。每个组件都有内部状态、边界和行为。组件是系统中的节点，它们可以独立运作，并通过行为与其他组件互动。

• 状态（State）：组件的状态由多个属性组成，这些属性在任何给定时刻都具有特定的值。系统中的状态常常是从更低层级的子系统的状态聚合而成。
• 边界（Boundaries）：每个组件都有边界，边界定义了组件的局部领域，其中与其他组件的互动比其他地方更频繁。边界可以有助于将系统的不同组件模块化，减少中心控制的需求。
  • 某些系统在顶层设计时，其中的若干模块就应该明确边界，在框架审查不严格的团队，甚至会出现双重开关的设计，增加迭代难度。
• 行为（Behaviors）：组件之间通过行为相互影响。这些行为会引发资源的流动，包括源、资源、容器和汇。资源可以是任何可数、可存储或可交换的东西，如生命值、子弹或资源领域。

行为与资源流动

• 源（Sources）：源是能够增加其他组件的资源数量的组件。源通常代表着某种资源的不断供应。其内部状态决定了资源的产生速率。
  • 如：MOBA游戏中的小兵、野怪，卡牌游戏中的PVE关卡。
• 资源（Resources）：资源代表从一个组件流向另一个组件的数量。资源可以是各种可计量、可存储或可交换的东西，包括物质和信息。
  • 如：玩家补兵获得金币，玩家完成关卡获得奖励。
• 容器（Containers）：容器接收和累积资源，其状态在某一时刻表示为一个数量。
• 汇（Sinks）：汇是资源流向容器的出口。汇的行为是以每单位时间输出的资源数量来定义的，但当容器为空时，它不再能输出资源。

强化循环与平衡循环

• 强化循环（Reinforcing Loops）：强化循环增强组件的行为，通常用于奖励成功和增强早期的优势。这种循环有时被称为“雪球”循环，因为即使优势很小，它也会被不断放大。
• 平衡循环（Balancing Loops）：平衡循环减弱组件的行为，有助于维持或恢复系统中各组件的平衡。它通常会限制早期领先者，以避免差距不断扩大。
• 如：卡牌游戏中主线关卡的阶梯式数值体验设计，玩家通常在一个章节中，前n个小关卡中都能顺利通过（强化循环）。而直到玩家即将通关该章节时，难度陡增，甚至失败，则此时玩家需要前往其他系统进行数值养成（平衡循环），直至玩家在主线关卡的战力数值符合通关条件。

意外后果与复合系统

意外后果循环

意外后果循环是一种隐藏了一段时间的循环，最终以报复的方式返回系统中。这种循环通常是由于短期视野和系统性忽视导致的。意外后果循环的解决方法是细致地审查系统，并深入了解其中的潜在原因和影响。

• 如：某货币的产出超限，游戏的拍卖行系统设置了系统自动求购，但没有为自动求购设计上限。
• 增长极限：我们经常会假设，给定一些结果，做更多会导致这样结果的事情，会带来相同方向持续不断的线性增长。这几乎是不可能的，原因在于：对于每一个由强化循环提供反馈的加速条件，都有一个由限制条件提供的单独的平衡循环。

复合系统

复合系统由多个组件组成，这些组件通过形成循环连接在一起。复合系统的特点是，每个组件都影响自己未来的状态和行为。复合系统可以看作是系统中的系统，每个子系统都相对独立，但又与更大的系统相互作用。

• 如：战队系统包含好友系统、活动系统包含商城系统。

系统深度

系统深度是指组件存在于多个组织层级中，这些组件本身又由更低层级的组件组成。系统深度创造了多层次的结构，这些结构具有吸引力，因为它们易于上手，同时也具有不同层次的复杂性。系统深度允许我们构建复杂但可管理的系统，这些系统可以适应不同的需求和挑战。

涌现

在游戏设计和复杂系统理论中，”涌现”（emergence）是一个重要概念，它指的是复杂系统中新的性质、行为、或模式从简单的组件或规则互动中产生的现象。这些新的性质通常不能简单地由组件的属性或规则的总和来预测，而是系统级别的表现。

• 在游戏设计中，涌现意味着游戏中的复杂性不仅来自于单个游戏元素或机制，而是由这些元素之间的相互作用和组合产生的。这可以导致玩家在游戏中经历出乎意料的、独特的情境和挑战。游戏设计师可以利用涌现来创建更具深度和多样性的游戏体验，而不仅仅依赖于预定的剧情或规则。

• 举个例子，涌现在游戏中可以表现为玩家的行为和决策在不同的情境下引发了不同的结果，创造了非线性的游戏进程。这意味着玩家的互动和选择会导致游戏中的新情节或问题的出现，这些情节和问题是根据玩家的行为而演变的，而非事先设定好的。

涌现在游戏中提供了更多的自由度和可能性，使游戏更富有挑战性和吸引力。设计师可以通过巧妙地设置游戏规则和元素之间的相互关系，鼓励玩家发现新策略、探索未知领域，并以独特的方式解决问题。这种设计方法可以增加游戏的回放价值，因为不同玩家在不同时间可能会经历不同的涌现情况。

在 “云顶之弈”（Teamfight Tactics）这款游戏中，让玩家从三个海克斯技能中选择一个的设计正是一个促使涌现的例子。这是一个很好的示范，显示了如何通过复杂的元素交互来创造非线性和多样性的游戏体验。

在游戏进程中，玩家会面临选择海克斯的阶段，可以选择拾取一个特定的装备，这个装备赋予棋子一个特定的技能或能力；也可以选择一个特定的技能，这个技能会影响棋子在战斗中的表现。这里的涌现来自于以下因素：

1. 选择的多样性：每一轮提供给玩家的三个选项通常都是不同的技能或装备，它们可以为不同类型的棋子提供不同的效果。这创造了多种可能的策略和组合，促使涌现的出现。
2. 玩家的战术选择：玩家必须考虑他们当前的队伍构建、角色的职业和阵容，以及他们的游戏计划。这些因素会影响他们在每轮选择哪个装备的决策。
3. 互动效应：由于每个棋子可以携带多个装备，装备之间的互动效应也会涌现。不同装备的组合可能会创造出强大的效果，这种效果在游戏中并不是提前定义好的，而是由玩家的选择和实际战斗中的效果产生的。
4. 游戏进程的演变：由于游戏是逐渐发展的，玩家的队伍和战术也会随着时间演变。这意味着涌现的策略和效果会随着游戏的进行而变化，创造出不同的游戏体验。

这个设计让 “云顶之弈” 充满了涌现性，因为它为玩家提供了丰富的选择和策略空间，每一轮都有可能涌现出不同的结果。这种设计方法使得游戏更具深度和多样性，同时也增加了玩家的决策和策略性。

优雅的系统思维

最终，系统思维的目标是创建优雅的系统。优雅的系统具有亚稳态，能够随时间变化，但仍然保持熟悉的感觉。这些系统具有层次深度和对称性，没有特殊情况或遗留问题。整个系统是由组件之间的相互作用形成的，因此整个系统具有高层次的定义，同时包含深层次的复杂性。

综上所述，系统思维是一种强大的工具，可用于理解复杂问题和设计创新系统。通过深入了解系统的组成组件、互动、涌现、系统深度和其他关键概念，我们能够更好地应对现实生活中的挑战，尤其是在游戏设计、系统工程和科学领域。系统思维有助于我们拆分复杂问题，找到解决方案，并优化系统以实现更好的性能和可持续性。

更新日志

一、设计目的

1.1 设计模型：

1.1.1 普通技能：僵尸

step 1: 施放技能 “僵尸”

• 玩家在关键时刻施放 “僵尸” 技能，享受做出决策的愉悦感，因为他们需要在危险情境下迅速反应，使自己进入无敌状态。

step 2: 技能状态持续

• 在技能状态持续期间，玩家体验到心流，因为他们需要不断地评估战斗情境，决定是否保持 “僵尸” 状态或恢复正常状态。
• 玩家在技能状态持续期间建立心智模型，了解何时最有效地利用无敌状态以获得优势。

step 3: 技能取消或技能结束

• 玩家体验到满足感，因为他们根据游戏情境和对手行为的变化，做出决定是继续保持 “僵尸” 状态还是取消技能。
• 玩家通过技能的取消或结束建立心智模型，进一步了解技能的使用时机和有效性。

1.1.2 大招技能 “无聊领域”

step 1: 施放技能 “无聊领域”

• 玩家在施放 “无聊领域” 时体验到心流，因为这是一个关键的决策步骤，涉及一对一对决的选择，玩家充满期待。
• 玩家通过学习何时施放 “无聊领域” 建立心智模型，玩家需要考虑选择哪一位敌方英雄进行对决。

step 2: 技能状态持续

• 在 “无聊领域” 技能状态持续期间，玩家体验到心流，因为他们需要全神贯注地与对手一对一对决。
• 玩家在技能状态持续期间建立心智模型，了解如何最合适的在无聊领域中应对敌人的行为，以保持优势。

step 3: 技能状态结束

• 玩家在技能状态结束时可能会体验到满足感或挫败感，这取决于他们是否成功战胜了对手。
• 玩家通过技能状态的结束建立心智模型，通过决斗的方式击杀敌人，可获得满足感与成就感。

1.2 设计风险：

• Q：使用无敌方式切入战局，导致无聊猿大招命中指定角色的技能行为是指向性的，是否影响平衡性？
  • A：如果在施放大招前就使用了无敌技能，那么在进入无聊领域时，无聊猿的大招将进入CD状态。作为无聊猿的玩家同样需要承受在无聊领域中接近对方的风险。
• Q：因为大招的决策几乎是一次性的，如何处理无聊猿在对错误的目标施放大招后的负反馈（例如将过于强势的英雄带到无聊领域中，导致自己被击杀）？
  • A：在无聊领域的关卡设计中，双方出生在同一面片碰撞上，面片中心有镂空障碍，接近彼此需要绕过该镂空障碍。玩家可通过关卡机制带来的躲避、迂回等处理方式，以此来稀释错误决策带来的负反馈。

二、功能需求

2.1 无聊猿普通技能：僵尸

• 技能定位：变身、无敌

• 技能描述：

  • 无聊猿瞬间转化为僵尸，一段时间内处于完全无敌状态，增加移动速度，无法开火或使用其他技能。

• 技能细节：

  • 施放类型：点击施放，可提前点按恢复为常态
  • 技能状态持续时间：待定
  • 技能冷却时间：待定
  • 冷却计算方式：点击施放即开始计算

• 技能操作：

  • 技能施放：按下技能键后立即施放
  • 技能停止：技能状态持续时间结束，或再次点击技能按钮结束技能，此时无聊猿变回常态
  • 技能取消：通用技能取消机制

• 其他技能效果

  • 期间内完全无敌，消除所有减益效果
  • 使用技能后，弹药立即装填
  • 使用期间可以接受治疗

2.2 无聊猿大招技能：无聊领域

• 技能定位：控制、伤害、空间

• 技能描述：

  • 无聊猿引导0.5秒，与距离最近的敌方英雄同时传送至一个半径50的无聊领域，获得10%的额外伤害加成。在此领域内，无聊猿与目标将进行一对一的对决。

• 技能细节：

  • 施放类型：点击施放
  • 技能状态持续时间：待定
  • 技能冷却时间：充能，能量满可立即施放；技能状态持续时间内可持续充能，但处于无聊领域内时技能不可施放

• 技能操作：

  • 技能施放：按下技能键后立即施放
  • 索敌规则：与自身距离最近的敌方英雄
  • 技能取消：通用技能取消机制

• 空间传送规则：

  • 技能状态持续时间结束，我方与被传送的英雄依旧存活，双方英雄传送回原点
  • 技能状态持续时间内，其中一方被击杀，另一方英雄传送回原点
  • 若有多个无聊猿同时施放该技能，均传送到同一空间。

三、美术需求

3.1 无聊猿普通技能：次元裂缝

• 技能表现（变身参考）

• 技能表现（模型参考，左常态，右僵尸态）

3.2 无聊猿普通技能：无聊领域

更新日志

一、设计目的

引入新的战场玩法，以增加游戏的多样性，提高竞技趣味，并促进游戏长期玩家留存。

二、功能概述

占领模式的玩法规则规则、功能交互，明确定义占领模式的胜负规则以及玩家的体验流程。

三、功能规则

3.1 占领模式玩法规则

• 占领模式中，战场上散布着多个占领点，每个占领点每秒都会产生一定数量的胜利点数。胜利的关键在于，当任意一队的胜利点数首先达到设定值时，该队将获胜。游戏的核心目标是争夺这些占领点，需要不断争夺和保卫以保持领先地位。

3.2 占领点预制

• 占领点将采用触发器（Trigger）的预制体，用于在客户端检测触发器范围内的队伍数量，从而实现占领交互。占领区域的大小将由触发器预制体的碰撞范围决定。

• 占领状态将分为3个状态，一旦变为已占领状态，将无法再次变回中立状态，只能更改占领点的归属方：

  • 中立状态（灰色）：初始状态，不产生胜利点数。
  • 我方状态（蓝色）：已占领，产生胜利点数，计入我方队伍。
  • 敌方状态（红色）：已占领，产生胜利点数，计入敌方队伍。

• 占领规则包括以下情况：

  • 中立状态下：

    • 场景1：当占领区域内只有1个队伍时，开始占领。占领时间应从触发器的captureTime字段读取（单位：毫秒）。占领时间结束后，占领点的归属将变为触发占领时间的队伍（不属于该队伍的占领点才会触发captureTime的计算）。
    • 在占领过程中，如果占领点内的队伍之一离开该区域，则该队伍的captureTime将逐渐重置为0。
    • 场景2：如果占领过程中，占领区域内有其他队伍进入，占领将暂停。占领时间会继续计算，但只有占领点内只有1个队伍时，占领时间才能继续计算。
    • 场景3：如果A队伍占领一个点，B队伍进入该区域并驱逐A队伍，需要等待已经计算的captureTime逐渐重置为0，才能再次触发captureTime。
      • 如果在此过程中，A队伍重新进入占领区域，清零过程将暂停。此时，A队伍将B队伍的玩家驱逐出占领点，清零的captureTime会逐渐回满。

  • 已占领状态下：

    • 场景1：当占领区域内没有我方玩家，敌对玩家进入占领区域，开始占领。占领时间将从触发器的captureTime字段读取（以毫秒为单位）。占领时间结束后，占领点的归属将变为触发占领时间的队伍（不属于该队伍的占领点才会触发captureTime的计算）。
    • 场景2：占领过程中，占领区域内有其他队伍进入，占领将暂停。只有在占领点内只有敌对队伍时，占领时间才会继续计算。
    • 场景3：占领过程中，如果敌对队伍的玩家被驱逐出占领区域，已经计算的captureTime将逐渐重置为0。
      • 如果在清零期间，敌对队伍重新进入占领区域，清零进程将暂停。

• 占领点会根据占领预制体的getPointPerSecond字段，每秒为占领点的归属方增加胜利点数。每秒都会计算每支队伍拥有的占领点，从而决定胜利点数。

• 占领点的UI样式将包括以下元素：

  • 占领点名称：通过name#string字段配置，用于在UI中显示，只允许填写大写英文字母A-Z。
  • 占领点图标样式：在预制体内提供下拉选项，包括L/S/M，用于控制占领点图标的UI位置。

3.3 胜负与结算规则

触发结算条件：

1. 战场时间限制（roundTime#float）内，任何一方率先达到occupyWinPoint#int的胜利点数，即可获胜。
   • 胜利方：达到胜利点数的一方将获胜。
   • 失败方：结算时拥有的胜利点数较少的一方将失败。
2. 如果在战场的时间限制（roundTime#float）内，没有任何一方达到胜利点数，比赛将在时间结束后进行结算。
   • 胜利方：在结算时拥有胜利点数更多的一方将获胜。
   • 失败方：在结算时拥有胜利点数较少的一方将失败。

3.4 占领模式配置

• 占领点预制将包括以下字段以支持功能实现：

  字段名	类型	描述
  captureTime	int	占领时间（毫秒）
  getPointPerSecond	int	每秒获得的胜利点数
  pic	string	占领点图片路径（数组，每个状态有3张图）

• 客户端战局配置：

  • 引入占领模式配置表：capture_target_cfg，用于配置占领模式的相关信息。
  • 以下是新增字段：

  字段名	类型	描述	备注
  occupyWinPoint	int	胜利点数	新增字段
  occupyPointFx	string	胜利点数增长特效，配置数组，大于等于该分数展示的特效	新增字段
  roundTime	float	比赛时长	复用
  noticeSelfTeamScoreHalf	int	通知-我方获胜进度已过半 我方拥有胜利点数大于等于occupyWinPoint/2时	规则变更
  noticeEnemyTeamSocreHalf	int	通知-敌方获胜进度已过半 对方拥有胜利点数大于等于occupyWinPoint/2时	规则变更
  noticeWinRemain	int	通知-再击败{0}名敌人即可获胜 –> 通知-再获得{0}分数即可获胜	规则变更
  occupyWeaponDelTime	int	占领模式武器掉落消失时间	新增字段
  occupyResurgenceType	int	占领模式死亡后复活方式	新增字段
  occupyResurgenceTime	int	占领模式复活等待时间	新增字段
  occupyResurgenceBuff	int	占领模式复活时添加buffId	新增字段

• 战服与平台配置：

  • 新增gameId=5000，表示占领玩法规则
  • 新增gameType=600，表示占领游戏类型

3.5 占领模式交互表现

• 不同状态的占领点样式

  • 我方点位：蓝色：

    

  • 敌方点位：红色：

    

  • 中立点位：灰色：

    点位进度条：根据不同队伍触发的captureTime，展示进度条，绕占领点底一周展示。

• 模式UI：需要展示以下内容。

  

  • A 分数情况：分别展示两队的当前分数，需展示进度条与具体数值。

  • B 占领点情况：地图内所有点位的占领情况（我方归属、敌方归属、中立）。

    • 占领点图标根据占领点预制的pic字段展示。

  • C 胜利点增加情况：每秒有跳字效果，根据当前不同的加分值展示不同特效，根据模式配置表的occupyPointFx字段索引特效。

  • 占领过程：我方captureTime触发时，若角色在该占领区域内，则展示正在占领UI。

    

  • 占领点HUD界面：占领点上方需根据预制内的Pic配置，展示对应的HUD界面，实现方式参照血条。

    

    • 显示层级：该HUD在场景中穿透墙壁，但会被任意Caster遮挡。

3.5 占领模式交互表现

四、美术需求

4.1 美术需求清单

名称	需求类型	描述图片
占领点模式UI：包含进度条、占领图标（我方归属、敌方归属、中立）；图标大小需设计3个级别（使用边框区分），用于区分不同占领点的重要程度；当前点位的摆放方式也需要设计：小x2、中x1、大x1 占领点图标内部根据地图场景，设计贴合地图场景的剪影	UI
占领进程进度条UI	UI
占领点HUD	UI
占领点地板贴图	模型贴图
归属权更换场景特效	特效	由占领点中心向占领点四周播放白色波纹
占领进度条特效：缓慢流动光效	特效

更新日志

一、设计目的

新增枪械的后坐力机制，强化射击手感，增加枪械策略性与射击趣味性

二、流程图

三、概述

• 枪械现在在射击时，会附带后坐力，后坐力表现区别于现有的震屏功能。本文中将对后坐力的触发方式、触发表现进行规范与细化。

四、配置表

4.1 新增字段

在枪械预制中新增以下配置

四、功能规则

4.1 后坐力计算

• 后坐力信息读取：枪械预制中新增后坐力脚本。

  • 读取脚本中配置后坐力信息，后坐力信息中枚举了在“连续射击”状态内，每1次射击的镜头偏移量。每1次连续射击的重新触发，都需要从后坐力信息的第1个条目进行重新读取。

    KEY（开火次数）	X	Y	备注
    3	0.2	0	表示从第0枪~第3枪，每次射击镜头绕X轴移动0.2个单位。
    10	0.15	0.2	表示从第4枪~第10枪，每次射击镜头绕X轴移动0.5个单位，绕Y轴移动0.2个单位。
    18	0	-0.2	表示从第11枪~第18枪，每次射击镜头绕Y轴移动-0.2个单位，18枪之后若无配置，则按照第18枪的配置信息执行偏移，直至子弹耗尽。

• 连续射击的失效

  • 当两次射击间隔≥recoilGapTime配置的时间，武器被视为停火，下次射击重新计算后坐力。

4.2 后坐力表现

• 新增后坐力运动表现：枪械预制中新增后坐力曲线脚本，用于控制每次射击镜头偏移的运动曲线，调用Unity的Curve组件实现。

  

  • X轴表示后坐力表现时长，一般配置为枪械的射击间隔；Y轴为偏移量表现速度。
  • 图示，若图内枪械为“霰弹枪”的后坐力镜头表现，根据该曲线，则表现为：
    • 射击后，枪械在0.05s内会迅速播放偏移量的95%，剩余5%部分在0.05s内表现完成。霰弹枪短时间快速抬高，滞空，进入回准表现。

• 镜头偏移坐标：

  • 绕X轴的偏移：根据prefab配置镜头像素偏移，该偏移量可累计。
    • 0=不偏移；负整数=向下偏移；正整数=向上偏移。
  • 绕Y轴的偏移：根据prefab配置进行准星像素偏移，该偏移量可累计。
    • 0=不偏移；负整数=向左偏移；正整数=向右偏移。
  • 偏移时长：根据后坐力脚本配置时长，控制准星完成该次偏移所需要的时间，该时间可累计。
    • 配置毫秒。

4.3 准星回位

• 准星回位触发条件：两次射击间隔≥recoilGapTime配置的时间，开始进行准星回位流程。
• 准星回位方式：计算玩家在射击或连续射击期间获得的所有Y轴与X轴偏移量，根据该偏移量，移动准星进行回位。
  • 回位的持续时间：根据recoilMoveBackTime的配置时长，控制准星从当前位置移动到回位位置所需的时间。
  • 新增回位运动表现：在每一把枪械预制中新增参数（同4.2 后坐力表现），用于控制每次回位准星偏移的运动曲线。
• 新增bool类型字段：isForceMoveBack
  • TRUE= 强制回准。
  • FALSE= 如果玩家通过滑屏激活了aimingCamera，则不进行回准。

4.4 震屏功能

• 现在在射击时，调用现有的CameraShake功能，每一次射击，震屏表现的持续时间与后坐力表现时长相等。
• 枪械预制中可加载震屏文件。

更新日志

一、设计目的

玩家可以通过在游戏中获取派对点，增加游戏的趣味性和奖励；这个功能的目标是让玩家在游戏中的行为有正向奖励反馈，同时也为OGX在游戏内使用卡牌技能提供正当性。

二、功能概述

• 此规则主要围绕派对点的产出、掉落交互、奖池、奖池表现及派对点的局内掉落方式进行设计。
• OGX玩家在游戏中使用技能卡牌将消耗派对点，这些派对点将通过各种方式返回给普通玩家。
  • 玩家通过开启宝箱、击杀NPC等枚举行为可获得派对点。
  • 玩家一旦成功撤离，将根据场上玩家存活的数量，从撤离奖励池获得派对点。

三、流程示意图

3.1 完整流程

3.2 抽奖流程

四、新增配置

4.1 party_point_action_cfg

• 新增配置表party_point_action_cfg，用于配置玩家获得派对点奖励的不同行为。

[TABLE_BEGIN]

[TABLE_END]

4.2 party_point_reward_cfg

• 新增配置表party_point_reward_cfg，用于配置玩家获得的派对点奖励。

[CONFIG_BEGIN]

[CONFIG_END]

[TABLE_BEGIN]

[TABLE_END]

4.2.1 配置示例

party_point_reward_cfg
[
[
{
"jackpotPercent": 500,
"loseAddPro": "{3:1500,5:3000}",
"onceWinEmptyTimes": 5
}
],
[
{
"id": 1,
"partyPointReward": 90,
"pro": "1000",
"noticeId": 500011
},
{
"id": 2,
"partyPointReward": 80,
"pro": "800",
"noticeId": 500011
},
{
"id": 3,
"partyPointReward": 70,
"pro": "600",
"noticeId": 500011
},
{
"id": 4,
"partyPointReward": 60,
"pro": "400",
"noticeId": 500011
},
{
"id": 5,
"partyPointReward": 50,
"pro": "200",
"noticeId": 500011
}
]
]

五、功能规则

5.1 功能开关

• 判断当前匹配对局内是否有OGX玩家或AI上帝。
  • 如果有OGX玩家或AI上帝：启用派对点奖励规则。
  • 如果没有OGX玩家或AI上帝：禁用派对点奖励规则。

5.2 派对点产出

• 局内目前有奖池设计，OGX玩家在局内消耗的所有派对点都将进入奖池，产出派对点的方式与来源请查看系统案：O OB卡牌功能 。
  • 消耗派对点的途径包括：使用卡牌，读取ob_card_cfg配置表的bonus字段进行产出。
  • BOSS一旦死亡，OGX玩家消耗的派对点，不进行任何处理。
• 派对点校验：在结算过程中，玩家获得的派对点，不允许大于OGX在局内消耗的派对点，若结算时检测到该情况，则没收玩家所有派对点。

5.3 派对点分配

• OGX产出的派对点，一部分进入“派对点奖池”，另一部分进入“撤离奖励池”，分配方式如下：
  • 派对点奖池：OGX产出派对点 * jackpotPercent字段，得出的派对点进入派对点奖池。
  • 撤离奖励池：剩余派对点，计入撤离奖励池。

5.4 撤离奖励池

• OGX附身的BOSS死亡时，将“派对点奖池”内的所有派对点，计入“撤离奖励池”，派对点奖池不复存在。此后OGX玩家花费的派对点也计入“撤离奖励池”。
• 该奖励不会立即获得，只有成功撤离，进入结算流程的玩家，才可获得从撤离奖励池中分得奖励，具体表现查看系统案：D 夺金模式 战斗结算。
  • 在BOSS死亡时，系统将记录击杀BOSS的队伍与队伍情况，供结算使用。
  • 若为是，则将 撤离奖励池中的派对点数量 / 击杀BOSS时队内存活的玩家数量 = 玩家获得的撤离派对点奖励。玩家获得派对点奖励后，将所获得的派对点从“撤离奖励池”中扣除。

5.5 派对点奖池

• 奖池抽取条件：当玩家完成指定的枚举行为时，有可能在派对点奖池中完成一次抽取，枚举行为根据party_point_action_cfg配置表的completedAction字段读取，具体如下：

  • 100=开启宝箱，读取actionValue的宝箱id。关于夺金模式内开启宝箱的具体规则，查看系统案：夺金模式宝箱规则。
  • 200=击杀指定NPC，读取actionValue的NPC的id。关于夺金模式内击杀NPC的具体规则，查看系统案：NPC系统。

• 奖池抽取概率：能否进行1次抽奖，是由 行为概率 与 保底概率 相加决定的。

  • 完成指定行为后，可根据party_point_action_cfg中所完成行为的actionPro字段，获得行为概率。
  • 若某次抽奖失败，失败次数+1，失败次数可累加；每次抽奖时根据party_point_reward_cfg的loseAddPro字段增加抽奖保底概率。
    • loseAddPro为对象字段，第一个数配置失败次数，第二个数配置增加的概率。抽奖失败次数≥第一个数时，读取该数组的第二个数增加保底概率，失败次数只会判断对象中最大的失败次数值生效。
    • 玩家成功获得1次抽奖资格后，失败次数清零。

• 奖池轮空：成功进行1次抽取后，玩家的任何行为都不再触发抽奖以及失败次数 ，直到玩家完成的行为次数大于等于onceWinEmptyTimes字段值。

• 奖池抽取：玩家获得抽取资格后，进入party_point_reward_cfg进行抽取，具体规则如下：

  • 读取各个奖励id的千分比pro字段，随机出玩家所获得的奖励。
  • 最终获得的奖励根据随机到奖励实例的partyPointReward字段进行配置，该字段配置值为千分比。
    • 当前奖池的派对点总额 * partyPointReward字段值，为玩家最终获得的奖励。
  • 玩家获得奖励后，需将获得的派对点从奖池中扣除。
    • 从奖池内获得的派对点，保底为1。
    • 若当前奖池派对点总额为0，则玩家抽取后不会获得任何奖励。

• 玩家从派对点奖池获得的派对点奖励，视为玩家在局内所携带的物品，玩家一旦死亡，其携带的派对点将会作为物品掉落，供其他玩家拾取。

5.5.1 派对点奖池：常态交互

• 当前奖池内派对点的总数量如下图所示，该界面表现为功能常态。

  

  • 展示派对点图标、当前奖池内的派对点总额。
  • 每当OGX玩家消耗派对点时，经过分配的派对点，会在派对点总额后方，以加号附带白色数字方式进行动效展示，在动效播放完成后，派对点总额数值应有当前值到目标值的逐步数字跳动表现。
    • 派对点来源展示：派对点增加时，需附带派对点来源信息（OGX使用了什么卡牌导致的奖池派对点增长），如图所示。
    • 卡牌图标读取ob_card_cfg配置表的icon字段。

5.5.2 派对点奖池：奖池抽取

• 当玩家完成了指定行为，获得派对点时，该界面播放奖池抽取表现。

  

  • 组件内出现3个老虎机形式的滚动数字框，框内数字快速跳动，相关的数字停止逻辑如下
    • 若服务端下发的奖励id中partyPointReward值为A，则数字有可能表现为：A + A + A 或 A + B + A 或 B + A + A ，三种数字停止逻辑中随机一种进行表现。
    • 数字应该由左至右逐个停止，每个停止时间为0.7秒。
    • B的数值随机在party_point_reward_cfg配置表中取与玩家所获得奖励相同的actionId的partyPointReward进行展示。
  • 数字停止后，玩家获得派对点奖励，播放奖励获得表现。

5.5.3 派对点奖池：奖励获得

• 当玩家获得了派对点奖励，抽取表现播放完成，应播放奖励获得表现。

  

  • 展示派对点图标、先展示所获得的百分比，随后百分比数字会变化为根据百分比换算的具体派对点数。
  • 派对点图标从组件中飞出，目标点为背包图标的UI位置，图中“+999”在过程中变为0，同时播放逐步数字跳动表现。
    • 派对点以道具形式进入背包，若此时背包已满，则掉落在场景中。
  • 该表现播放完成后，该界面组件恢复为常态；若当前还有未展示完成的奖励，则恢复为”奖池抽取”态继续播放表现。

5.5.4 派对点奖池：通知相关

• 奖池通知：获得一个派对点奖励时，该奖励ID中的noticeId有配置值时，则去tips_cfg读取通知信息，进行全局广播。
  • 该奖励的格式应该为：“{0}掠夺了派对奖池，获得了{1}派对点数！”
    • {0} = 玩家昵称
    • {1} = 所获得的派对点数
• BOSS死亡通知：OGX附身的BOSS一旦死亡，则去tips_cfg读取通知信息id为ogx_dead_info的字段，进行全局广播。
  • 该通知的格式应该为：“BOSS已经死亡，击杀的队伍总计获得{0}派对点！”
    • {0} = 当前撤离奖池中的派对点数

5.5.5 派对点奖池：奖池消失表现

• OGX附身的国王死亡时，将“派对点奖池”内的所有派对点，计入“撤离奖励池”；此时派对点奖池的UI组件应做消失表现。

  ​

  • 先播放碎裂特效，碎裂特效播放完成后，UI消失。

六、美术需求

名称	数量	备注	参考链接
派对点奖池界面设计	1	包含以下子标题中涉及到的界面需求与动效需求 5.5.1 派对点奖池：常态交互 5.5.2 派对点奖池：奖池抽取 5.5.3 派对点奖池：奖励获得
奖池老虎机特效	1		无主之地3老虎机 无主之地2老虎机
奖池UI碎裂特效	1
奖励获得派对点飞行特效	1		https://www.bilibili.com/video/BV1BY4y1h7qm 10秒~14秒

更新日期：2020-8-26

Version 1.00 last saved by：朱兴韬

创建文档

1. 设计目的

优化战令功能交互，重构战令任务系统，强化功能可玩性。

2. 流程图

3. 功能简述

• 将战令任务拆分为龙宠条件与模式条件，在任务链中抓取了对应任务后，服务端需对其赋予龙宠条件与模式条件限制。

• 重构后战令任务实例的组成变为：龙宠/模式（选其一）限制条件+任务条件+完成条件；战令购买条件+龙宠/模式（选其一）限制条件+任务条件+完成条件。

• 平台简述：

  • ruleType=4，resetRule=2时，表示该任务实例为战令每日任务

  • ruleType=4，resetRule=3时，表示该任务实例为战令赛季任务（常规任务）

  • ruleType=5，resetRule=3时，表示该任务实例为战令赛季任务（需购买战令才可进行并完成）

4. 具体设计

4.1 平台相关

4.1.1 新增任务链选取规则与字段

• 在task_base中新增以下字段，用于控制战令任务规则，当ruleType=4/5时，成功读取chainId后，进入该字段进行任务链处理。

• 以上两个字段都配置为1时，随机取其一作为限制条件（概率平均）

  • 有一者为0，取另一字段作为限制条件。
  • 都为0则不抽取该条信息。

• 抽取方式：

  • 在randomNum中取得抽取次数，在对应chainId中抓取等额次数的任务，不存在抓空。

  • 概率：概率在对应chainId的task_base中的probability字段体现。

4.1.2 新增任务规则

• task_control配置表新增ruleType=4，表示在龙宠与模式中进行随机限制。

  • 表示随机任务，去指定chainId中抽取任务时，需进行以下操作：

  • 根据battlePassPetLimit字段，查询玩家目前已拥有龙宠，在已拥有龙宠中选定1只（概率平均），限制玩家仅使用该龙宠才可完成任务。

  • 根据battlePassModeLimit字段，查询玩家目前已解锁模式，在已解锁模式中选定1个（概率平均），限制玩家仅使用该模式才可完成任务。

  • 任务限制模式、龙宠信息需形成消息下发客户端。

• task_control配置表新增ruleType=5，表示战令限制随机任务，去chainId中抽取任务时，需进行以下操作：

• 查询玩家是否已购买战令，已拥有战令才可进行任务（任务会先下发，但需购买战令才可进行并完成）。

4.1.3 新增重置规则与字段

• task_control配置表字段randomDays#int，表示每X（配置天数）自然日可读取randomNum#int进行任务抽取，当ruleType=4/5时才读取该字段信息。

• 当ruleType=4/5时，进行以下处理：

  • 到randomDays读取自然日信息，判断当前赛季经过的自然日天数，以此为基准执行抽取。
    • 例：randomDays的配置值为5，randomNum配置值为4，当前赛季已进行了16个自然日。玩家（当日注册新号）此时登录游戏触发了战令任务抽取业务，则执行4次（包含跨赛季第1次）抽取流程，下发数量共16个任务给玩家。

• 在1个赛季内，ruleType=4/5的任务都可完成，跨赛季后任务清零，并执行1次抽取（跨赛季后第1次抽取无需满足配置的自然日条件）。

4.1.4 新增任务条件

• 根据战服传出数据，新增以下任务类型

4.1.5 逐级解锁

• task_control配置表中的levelLimit#int字段将配置任务的生成等级，玩家只有达到了配置值，才可生成任务实例。

4.1.6 数据下发

• 服务端需下发以下信息，供客户端维护：

  • ruleType=4，resetRule=2时（战令每日任务）

    • 下发ruleType与resetRule值
    • 下发任务条件、任务奖励、任务限制信息（龙宠或模式）
    • 下发任务刷新时间戳

  • ruleType=4，resetRule=3时（战令赛季任务）

    • 下发ruleType与resetRule值

    • 下发任务条件、任务奖励、任务限制信息（龙宠或模式）

    • 下发任务刷新时间戳

  • ruleType=5，resetRule=3时（战令赛季任务）

    • 下发ruleType与resetRule值
    • 下发任务条件、任务奖励、任务限制信息（龙宠或模式）
    • 下发任务刷新时间戳

4.3 战服相关

4.3.1 数据下发

• 统计战局内以下数据，向平台下发:

  • 恢复生命（使用治疗类技能，恢复他人生命也计算在内）。

  • 造成伤害（仅对敌方角色造成伤害计算在内，吃鸡模式宝箱、其他玩家的召唤物不计算在内）。

4.4 客户端相关

4.4.1 数据处理

• 处理服务端下发的任务消息中的数据，判断任务类型，根据不同任务类型做差异表现。

• 以下chainId在客户端为taskType：

  • chainId=5000，表示战令每日任务。

  • chainId=5011/5012，ruleType=4，表示战令赛季任务。

  • chainId=5011/5012，ruleType=5，表示战令赛季任务（需购买战令才可进行并完成）。

• 处理每个任务的限制条件，条件分为：龙宠、模式。

4.4.2 任务界面-任务排序规则

• 根据平台下发消息，对任务进行排序，规则如下：

• 任务（收起）：

  • 优先1：可领取态优先展示（包含每日与赛季），后方跟随相同龙宠或限制模式任务（如果有），若玩家此时执行了领取任务操作，不会进行重新排序。

  • 优先2：完成进度最高的任务（进行态，包含每日与赛季），后方跟随相同龙宠或限制模式任务（如果有）。

  • 优先3：同一限制条件（相同限制龙宠或相同限制模式）的进行态任务，自动对齐（卡片归类到同一处）；若玩家解锁了战令，战令赛季任务也可参与对齐。

  • 优先4：没有其他可进行任务时，展示未解锁的战令专属任务。

  • 例：收起态有3个slot，玩家未解锁战令，目前玩家剩余1个赛季任务与若干个赛季战令任务，slot1展示赛季任务，slot2/3展示未解锁态的战令专属任务。

  • 优先5：客户端作假维护的待刷新态卡片。

• 任务（展开），展开时会根据任务类型分类，每日任务不参与下列排序：

  • 优先1：同一限制条件（相同限制龙宠或相同限制模式）的任务，自动对齐（卡片归类到同一处）；若玩家解锁了战令，战令专属任务也可参与对齐。

  • 优先2：玩家未解锁战令时，所有已下发但不可完成的战令专属任务，始终显示在展开态的末尾。

  • 优先3：客户端作假维护的待刷新态卡片。

4.4.3 任务界面交互-收起态

• 任务为收起状态时，交互如下图所示：

• 收起态时，任务界面内由上到下有3个slot，为slot1、slot2、slot3，分别展示收起态排序前3的任务。

  • 其中slot内含有任务卡片，卡片主要包含以下2个状态；（待刷新态与战令专属态在下文：展开态中描述）。

    • 可领取态（根据上文排序，优先级最高），包含以下内容：

      • 主题图标（根据平台下发的限制条件去item_base或mode_sty索引）。
      • 任务文本（task_base）。
      • 可领取蒙版、底板。

    • 玩家点击了可领取态slot的卡片，按顺序执行以下动效：

      • 动效1：经验图标从卡片处飞向左上角，左上角进度条组件执行增加表现，战令主进度条执行增加表现。

        • 若增加过程中经过了对应节点圆形图标，节点需从未解锁态变为解锁态并播放光效。
        • 对应节点的奖励（免费奖励、战令奖励）需从未解锁态变为解锁可领取态，可领取态需展示太阳花光效。

      • 动效2：卡片播放透明度由100%到0%消失的0.35秒先慢后快弹性动画。

      • 动效3：列表推进动画：若玩家点击的是slot1的可领取卡片，slot2的卡片向上移变为slot1，slot3的卡片向上移变为slot2，通过排序新增一张卡片从下方移入界面填充slot3；动画为持续1秒的慢（100%）→快（150%）→慢（100%）的弹性移动动画。

        • 若玩家点击的是slot2的可领取卡片，slot3的卡片向上移变为slot2，通过排序新增一张卡片从下方移入界面填充slot3。
        • 若玩家点击的是slot3，通过排序新增一张卡牌从下方移入界面填充slot3。

    • 已领取的任务卡片不再展示

• 进行态包含以下内容：

  • 主题图标（根据平台下发的限制条件去item_base或mode_sty索引）。
  • 任务文本（task_base）+限定龙宠/模式 ：%s（具体索引id见字符串配置处）。
  • 任务目标与进度条（task_base）。
  • 任务奖励（task_base）。
  • 玩家点击了进行态的卡片，执行以下操作
    • 若该任务的限制条件为指定龙宠，返回主界面切换为对应龙宠；玩家在房间内时队伍内有相同龙宠则展示code=104010
    • 若该任务的限制条件为指定模式，返回主界面切换为对应模式；玩家在房间内且不为队长时展示code=21101

• 点击红框内热区，将任务界面变为：展开态，按顺序执行以下动效：

• 动效1：3个slot内的卡片播放大小由100%到0%的0.35秒先慢后快弹性动画。

• 动效2：任务展开态由屏幕右侧至左以先慢后快弹性动画形式进入界面，参照聊天功能抽屉动画。

4.4.4 任务界面交互-展开态

• 任务为展开状态时，交互如下图所示

• 任务主题1（展示每日任务卡片）：

  • 主题文本：“每日任务”（UI层已有，直接复用）。

  • 倒计时文本：“刷新倒计时：”（UI层发布，需翻译）。

  • 需程序自行换行后展示倒计时，附带倒计时图标，倒计时根据平台下发的该任务链刷新时间戳展示，每日任务倒计时跟随主题文本形成组件，会随界面拖动移动。

  • 具体倒计时显示规则复用上层战令功能。

• 任务主题2（展示赛季任务、战令专属任务卡片）：

  • 主题文本：“赛季任务”（UI层已有，直接复用）。
  • 倒计时文本：“新任务解锁：”（UI层发布，需翻译）。
  • 需程序自行换行后展示倒计时，附带倒计时图标，倒计时根据平台下发的该任务链刷新时间戳展示，赛季任务倒计时固定在屏幕右侧，不会随界面拖动移动。
  • 具体倒计时显示规则复用上层战令功能。

• 展开态可左右拖动查看更多卡片：

  • 初始展开界面时，每日任务标题与卡片组件定位最左侧，此时界面不可向右拖动。
  • 初始向左拖动时，每日任务组件跟随卡片可根据拖动移出到界面外，赛季任务标题组件与卡片可随拖动移动到左侧，如图。
  • 赛季任务标题到左侧时不会移动到屏幕外，继续拖动将只移动赛季任务的卡片部分。
    • 此时向右拖动到底每日任务组件可回到界面内。

• 展开态时，任务界面内由左到右有若干个slot，按上文（任务排序规则）提到的排序展示任务。

  • 其中slot内含有任务卡片，卡片主要包含可领取态与进行态（样式复用4.4.3收起态的描述），及以下状态：

  • 可领取态：

    • 在界面展开状态点击可领取态的任务时，展开态关闭为收起态，播放领取已完成任务的相关动效（4.4.3可领取态动效）。
    • 此时同时进行收起态的slot维护，不会将点击完成的任务填充进收起态的slot1。
    • 已领取的赛季任务卡片不再展示，在展开态中需判断任务类型。
      • 若为每日任务，则领取完后需在对应slot处展示待刷新态卡片。

  • 进行态：点击进行态的任务，执行4.4.3进行态中相同的描述。

  • 战令专属态（未解锁态）：卡片任务进度条与奖励处盖有蒙版，蒙版上方展示文字：“战令专属任务”

  • 待刷新态

    

    • 作假表现，客户端自行维护展示，如下图展示，该卡片无点击事件
    • 如图该卡片有两种样式，根据config（全局变量表）的key=300控制两种样式的生成数量
      • Data1=等待刷新卡片的数量。
      • Data2=等待刷新（战令专属）卡片的数量。

  • 根据排序，一般展示在其他形态卡片末尾，在没有其他可进行任务时，展示待刷新态卡片。

  • 等待刷新（包含等待刷新 战令专属）的卡片符合对齐条件，应归类展示，但等待刷新 战令专属卡片，应展示在该类型卡片的末尾。