游戏制作模型（十四）——游戏运营

太公望

本文尝试从设计者的视角简单描述游戏运营包含的步骤和思路，欢迎交流～
游戏上线



在游戏正式上线之前，需要做好充足的准备，首先需要保证游戏品质过关，这点需要通过“技术测试”和“玩法测试”验证。
“技术测试”是指游戏性能、稳定性等底层技术达到上线标准（通常会参考市面上同类竞品设定一个标准）。
“玩法测试“是指玩家的游戏体验符合设计者的预期，最终体现在留存、付费上。
在以上两个基本条件满足后，还得考虑运营游戏的基础设施建设是否跟上了，包括：

• 游戏发版本流程
  
• 前后端更新流程（如强更和热更）
  
• 数据备份和回滚支持
  
• 游戏埋点相关（通过日志分析数据）
  
• BMS后台（查询、检测、管理玩家数据）
  
• 邮件和奖励（给玩家做通知、发奖励的功能）
  
• ...
  

在游戏运营的过程中，我们总是希望通过数据分析更快发现和定位线上问题，通过后台管理工具控制线上问题造成的影响，最终通过邮件、补偿来安抚受影响玩家的情绪。
游戏更新



更新流程

上面说的运营游戏需要的基础设施包含发版和前后端更新流程，这是因为当游戏上线后，需要有一个固定的游戏更新节奏。而每次更新，都会暂停运营服务器，发布新的客户端版本资源，同时更新服务端版本，开放新版本下载渠道，然后开放服务器，最终完成更新。不同的技术方案可能会带来流程上的精简或增加，但是不变的是需要一个明确的发布更新流程来指导工作，具体包括：

• 游戏定包后，内网做回归测试，完整测试游戏内的所有功能
  
• 发布外网做回归测试
  
• 提前发布更新公告通知玩家
  
• 停服，上传新版本客户端和服务器资源
  
• 开放客户端资源更新，启动服务器，开启白名单测试
  
• 完成更新，正式对外
  

每一次上线更新都应该像第一次上线一样对外，如果出现事故，对游戏的损失是无法预估的。
更新节奏

当游戏上线后，除了持续修复bug，还需要给玩家提供持续不断的游戏内容更新，让玩家对新内容有期待，是留存的关键。
这时除了游戏本身的更新节奏之外，还会收到玩家的反馈，可以分为紧急、普通、建议三个级别，其中紧急的问题需要在最短时间内解决，普通的问题跟着周版本放出，建议的问题可以考虑放进后续大版本的设计中去。
由此可以倒推出合适的更新节奏是：至少每周1次的bug fix和小特性放出，至少每月1次的玩法内容优化，至少每3个月1次的大版本更新。
运营活动



通常游戏正式上线之前，会储备过量的内容，便于制定后续运营的节奏。一方面会根据第一个正式版本的生命周期预期，来发布达到满足对应生命周期所需的内容。除此之外，还需要考虑如何满足玩家不断变化的需求和反馈，延长游戏的生命周期。
在游戏发布后，通常会定期发布运营活动来促进活跃/付费。运营活动可以简单定义为在一段时间内，提供有限次高额奖励的有游戏内容。我们在游戏中主要是通过更丰富的奖励或更有特色的玩法，让玩家形成持续的游戏期待，最终实现留存在游戏内。此时，对游戏核心玩法层或系统框架层的改动成本会很高，这时主要是通过游戏运营活动协调玩家的游戏体验。运营活动可以和核心玩法相结合，也可以脱离核心玩法之外的独特玩法形式，结合对应奖励，让玩家对游戏不断产生新鲜感和目标感。
需要注意的是，运营活动是跳脱于原有游戏经济体系之外的额外资源投放渠道，一定程度上会破坏游戏设计期间制定的资源投放节奏。过多、过于丰富的运营活动所投放的资源，会加速玩家消耗游戏本身的内容，所以也会有设计团队在开发期间就订好了上线活动的资源投放规划，将这些资源产出也并入完整的资源产出当中，避免缩短游戏本身的生命周期。
在实际运营活动的设计上，通常会分为以下几种类型：

• 增益状态：如活动期间战斗数值额外提升/体力消耗降低
  
• 达成数量目标类：
  
  
  
  • 通过收集特定数量的道具换取奖励
    
  • 通过累积签到、活跃时长换取奖励
    
  • 全服玩家累计达到指定条件或完成指定目标的次数满足一定条件，发放全服奖励
    
  
  
• 新玩法：独立于原核心玩法的全新玩法模式，比如afk里的打牌活动
  
• 抽奖：使用游戏内货币/特定素材参与抽奖，博赢大奖的可能性
  

运营活动的包装方式还是需要切合游戏本身的玩法、背景，才能给玩家最大程度的代入感。
<hr/>游戏需要通过一次次的更新让自己变得更好，每一次更新的内容都是设计者给玩家交出的答卷。
在理想情况下，游戏设计者和玩家会在游戏更新的过程中共同成长。