【游戏设计】一套完整的商业游戏包含的内容
-
主要是为了快速【从零】搭建一个大致能用的框架
持续更新，需要查漏补缺
通用后台
基础功能
-
是否通过后台配置活动
-
如果通过后台配置所有活动，那么客户端就能少更新，活动通过服务端来发送。好处在于所有内容可以随时替换而无需更新/热更新，坏处在于如果使用单独的配制方法，一是不好维护（除非做一个专门的查看、配置活动工具，或者传入的配置本身就是明文，否则这只能在后台上配，难以对比，存在一定风险），二是需要做好SVN管理，否则的话容易掉配置。
- 适合小游戏等更新不方便的情况。
-
如果不通过后台配置活动，那么每更新一次活动配置，客户端就要做一次更新。好处是明文配置，好维护，坏处是仅更新活动时需要热更。不过一般而言，没有单独更新活动的需求。
- 适合大部分情况。
-
-
用什么样的方式防作弊
- 不同情况有不同的处理方式，一般是使用后台计算，或是前后端联合验证防作弊。
GM后台
必备功能
-
权限管理
- 管理各个后台账号能访问、能操作的功能
- 查看各个账号的操作行为记录
-
服务器修改
- 开新服、老服状态修改（新服、老服、满员、维护）
-
玩家信息操作
-
玩家渠道、UID、区服、昵称、注册时间
-
玩家资源
-
体力
- 体力的获取及消耗记录
-
货币、代币资源
- 货币、代币资源来源以及变动记录
-
角色装备等资源
- 角色装备等资源来源以及变动记录
-
相关次数资源
- 各模块单独计数的资源以及变动记录
-
-
玩家社交关系
-
邮件
- 邮件发件人、收取时间、附件、领取状态
-
好友
- 好友UID、昵称
-
私聊记录
- 对方UID、聊天记录
-
所属公会
- 所属公会ID、昵称
-
-
玩家付费状况
- 订单时间、订单号、购买商品ID、价格、内容、折扣、商户订单号（支付宝等）、支付状态
- 玩家付费代币消耗记录
- 累充、阶段累充
-
玩家游戏进度
- 玩家等级、经验
- 新手引导步骤
- 主线任务状况
- 每日每周任务状况
- 成就状况
-
-
公会信息操作
- 类似与玩家信息统计的设计
-
运营功能
-
礼包码
-
注意事项
- 出现礼包码的地方默认有复制按钮，以便记录
- 如果没有复制按钮，那么如果使用字母则使用大写字母。避免出现lI这类情况。最好是全部用大写字母。
-
功能
-
兑换码的类型
-
限时-同用户单类单次-多个兑换码
- 限时：该兑换码有时间限制，过期后失效
- 同用户单类单次：该类兑换码同用户只能使用一次。即使一个用户获取了多个兑换码，如开小号，拿朋友的兑换码，也无法重复激活该类兑换码。
- 多个：生成一批兑换码。
- 该类型一般做网页活动的时候发，或者开服的时候当开服奖励。
-
限时-同用户单类多次-多个兑换码
- 同用户单类多次：该类兑换码同用户可以使用多次。如果一个用户获取了多个兑换码，那么他们就能使用多个，直到使用上限（或者没有使用上限，比较少见）。
- 比较少见，因为这类兑换码附带了交易属性，玩家是可以在游戏外交易兑换码的，所以一般不发这类兑换码，或者获取这类兑换码的方式就是官方购买
-
不限时-同用户单类单次-单个兑换码
- 不限时：有效时间无限。
- 单个兑换码：只有一个兑换码
- 该类型一般是开服的时候从市场里游戏页面一起放出的兑换码。所有人都使用同一个兑换码且只能使用一次。
-
另外有的还有渠道礼包码，将限定条件添加上去就可以
-
-
兑换码操作功能
-
查看兑换记录
- 用户在什么时间兑换了什么类型的、什么ID的兑换码，获得了什么奖励。
-
重定义兑换码时间
- 将无限期兑换码变为有限期，或是更改有效时间等。
-
已有类型下新增/删除一批兑换码
- 在已有类型下继续新增一批兑换码，以便追加奖励。
- 在已有类型下删除一批未使用的兑换码。一般不使用这一功能。仅用作操作失误后补救的情况。
-
删除某类型兑换码
- 删除某类兑换码。一般用作销毁兑换码，也用作操作失误后补救的情况。
-
更改某类型兑换码奖励内容
- 更改兑换码激活后的奖励。一般不使用这一功能。仅用作操作失误后，还未发送兑换码时补救的情况。
- 解决兑换码奖励发错且已流入用户的事故，可以从兑换记录清查并且重置对应奖励的情况入手。
-
-
-
-
公告修改
- 不同渠道不同公告
- 公告类型（系统/活动/其他）
- 默认显示的公告，公告排列顺序与默认排列顺序
- 公告标题与内容（视情况可能要做富文本）
-
邮件
-
邮件发送时间、发送人、发送内容、附带奖励、自动删除时间
- 邮件类型（系统邮件、新手邮件、普通邮件）
-
-
信息监控
-
聊天监控
- 支持查找角色名、角色ID、关键字。便于筛选出广告
-
邮件监控
-
-
首次充值返利与充值返利重置
- 所有玩家首次充值某个档位都会获得额外付费代币返利。可以手动重置所有玩家的充值返利状况。
-
删档返利
- 具体情况具体设计，大致就是参加了一测二测的玩家在下一次测试时获得额外付费代币返利
-
回归活动与回归邮件
- 具体情况具体设计，大致就是离线超过xx天的玩家在登录当天开启一连串的回归活动以及获得回归邮件。
- 注意玩家半夜登录会导致当天没有时间完成活动的情况，因此建议首日不做要求，只要登录即可。
-
玩家封禁
- 封禁，解封（时间封禁）
- 禁言，解禁（时间禁言）
- 永久封禁（封账号，封设备，封IP等等）
-
白名单
- 账号、设备、IP白名单
-
虚拟充值
- 具体就是触发各种充值相关数据的充值，除了没充钱以外其他的东西都有。充值内容和档位一样。
-
-
数据面板（全渠道/分渠道，全服/单服）
-
每日新增用户数，对应渠道，对应服务器以及新增时间
-
用户活跃
-
活跃用户的定义
- 常见的定义有：在APP内在线时长大于等于10分钟的、每日登录次数1次或1次以上的，等等。
- 合适的定义依据应用环境的不同而不同，但活跃用户的核心是真正认为产品有价值的用户，其他的都是表象。
- 同样，也可以依据活跃行为的程度，如累计在线时长等，给活跃用户分级。
- 注意留存和活跃不一样，有可能存在用户始终不活跃但始终留存的情况。这时候这部分用户应当被划为流失风险用户。
-
-
用户留存
-
新增用户留存
- 新增用户到第N天是否还在登录
- N日留存率计算方法为：在第一日注册，第N日存在登录的用户数/第一日注册的用户数。注意不是当日登录数/注册总数。
- 假如数据是3日和7日留存，而某玩家登录时间为首日次日和七日，那么该玩家不计入3日留存，但计入7日留存。
-
付费用户留存
- 付费用户N日留存率计算方法为：第一日付费用户到第N日时还存在登录的用户数/第一日付费的用户总数
-
未付费用户留存
-
流失风险用户
- 即存在登录，但是没有达到活跃用户标准的用户。
- 可以对流失风险用户单独进行分析。
-
-
用户付费
-
用户付费率
- 一般来说，N日用户付费率计算方法为：在某个服务器的第N日时，付费用户总数/所有用户总数。
- 假如数据是7日付费，那么第六日注册的玩家在第七日付费了，也会计入7日付费。
- 另外用户付费率有时候也指活跃用户付费率。即：在某个服务器的第N日时，活跃付费用户总数/活跃用户总数。在游戏行业一般将两个分开看待。
-
用户付费构成
- 新增付费用户
- 老付费用户
- 付费栏位比例
-
ARPU（阶段内平均每用户收入）
- N日ARPU的计算方法为：在某个服务器的第N日时，所有用户收入/用户总数。
- 用来衡量玩家平均付费欲望。
- 如果起始阶段不是首日的话，一般会采用AU（活跃用户）而非所有用户来计算。
-
ARPPU（阶段内平均每付费用户收入）
- N日ARPPU的计算方法为：在某个服务器的第N日时，所有用户收入/付费用户总数。
- 用来衡量付费玩家的付费欲望。
- 如果起始阶段不是首日的话，一般会采用AU（活跃用户）而非所有用户来计算。
-
ROI（投资回报率）
- 投资回报率的计算方法为：总收益/总支出
- 总支出可以使用用户单价×用户数计算
- 总收益可以直接统计，也可以使用LTV、ARPU或者ARPPU计算
-
LTV（用户平均生命周期价值）
- 也就是用户平均从注册到流失的的时间内所产生的价值。
- 阶段内LTV计算时按所有用户生命周期只到这个阶段为止来计算。
- N日LTV的计算方法为：从首日到第N日为止，累计收益/用户总数
- 如果都从首日开始计算，N日LTV等于N日ARPU。
-
-
用户消耗
-
用户钻石消耗
- 核心的观察点，用户把钻石都花到哪里去了，根据这个做后续的付费设计。
-
其他资源消耗
- 基本上是观察用户的养成选择消耗。
-
-
玩家分析
-
玩家等级分布
-
停留关卡分布
-
停留新手引导分布
-
充值途径统计
- 包括直充和礼包
-
-
活动排期
-
单服整体排期
- 也就是从开服开始到后面的所有活动排期。
-
单服阶段活动内容
- 最好可以便利地查看从第X天开始到第Y天这期间的所有活动排期，以便于数据分析。
-
-
通用设计规则
-
UI设计规则
- 标准弹窗框体、标准按钮大小、各种功能的按钮标准形状与颜色
- 独立Icon大小、以及是否有Icon底图、文字底图
- 不要出现半透明叠底下有前面的按钮盖住了后面的按钮的情况
- 如果两个页面的按钮操作逻辑与位置相似，那么尽量把按钮放置在相同的位置上
-
文字描述规则
- 适用于不同状况的标准字体，字号（标题、一般正文、按钮、Icon文字等）
- 适用于不同功能，不同说明类型的文字格式（强调/区分）
- 通用，可复用格式的信息格式、字色字号（如当前值/最大值，红/绿=>绿/绿）
- 图标+文字/数目的说明形式是否统一
通用系统
-
多面板跳转规则
- 有没有类似打开页面为A-B-C-A的循环嵌套设计。
- 如果存在循环嵌套，返回和不停嵌套的表现是什么样的。
- 注意信息的刷新，常见的是A-B-C-A，一顿操作后返回C，此时A的操作结果应该在C的信息面板上反映出来。
-
同时开启多个弹窗规则
- 连续开启弹窗时，如何处理可能出现过多弹窗的问题（非默认弹脸，而是弹窗跳转）
- 可以定义最多3弹窗，如果继续开启弹窗则先关闭最后一个弹窗，再打开新的弹窗。注意该行为需要测试，避免频繁操作的功能要反复开启关闭。
-
红点规则
- 红点由前端控制还是后端控制，消了红点后换设备了，红点还在不在
- 红点的出现、消除、穿透规则，不要复杂。
- 红点的刷新规则。
-
通用获得道具展示规则
- 主要是每类单独列出，并且默认做成可复用的形式。
通用中台功能
-
进入游戏之前的功能
- 公告
- 服务器组、选服、合服
- 上次登录、服务器里的玩家信息记录
- 渠道SDK
- 登录、登录页定制、登录加载页
-
报错、修复
- 修复功能
- 运行时Debug面板
- 玩家报错日志自动上传到服务器
- 内存分析工具
-
更新
- 热更、强更、停服维护
- CDN工具、刷CDN流程、FTP工具
- 停服更新流程，踢下线热更流程
-
开发
- 自动打包工具，Jenkins
- 开发服、体验服、正式服
-
运行体验
- 低中高配的定义
- UI加载、响应速度，以及相应合格标准
- 加载策略，加载速度，加载页面与进度条
- 预下载/预加载，预下载常见于小游戏刚进新手引导时下载后面要用的资源
- 切后台再切回后的体验
- 断线重连
- 弱网重连，弱网提示，弱网bug（一次性发一堆消息或执行了一堆操作）
-
兼容性
- TopN机型测试
- 常见模拟器测试
- 电脑端小游戏测试
-
数据后台，GM后台
运营公告模板
- 版本更新公告
- 服务器维护公告
- 开服合服公告
-
-
补充一些想到的，有些可能比较偏细节
通用后台
- 版本功能开关控制（或许可以归类到通用的后台配置中）
- 分版本分平台控制，主要用于iOS提审时临时屏蔽提审版本的部分功能
通用系统
-
热更新（客户端、服务端）
- 资源热更
- 代码热更
-
国际化
- 静态国际化：一个游戏版本对应一种语言，不可在运行时切换语言
- 动态国际化：游戏内包含多种语言，可在运行时切换语言
-
新手引导
- 引导触发条件
- 引导表现形式（是否有遮罩、是否高亮目标、是否可打断、附带剧情等等）
- 引导显示层级需要注意不能错乱，例如被更高层级的视图遮盖
-
功能解锁
- 解锁条件（根据游戏内容而定，例如通过某个关卡、完成某个主线任务等等，程序设计时需要提前预留相关接口）
- 锁定与解锁表现可以提前定义好，做成可复用的形式
-
任务与成就
- 达成或触发条件（同样程序设计时需要预留相关接口）
- 进度的计算方式，从任务激活开始、从游玩开始、从当天登录开始等等
-
定时刷新和重置
- 例如道具的刷新、Boss的刷新、排行版重置等等
- 刷新的时机（每日、每周、每版本、手动）
-
充值
- 订单创建、支付、发货、自动补单、人工处理掉单
- 支付流程：SDK-游戏服务端-游戏客户端三端间的交互和校验
-
第三方能力接入
- 支付：Google Play, Apple Pay, 米大师, 客服充值, 支付宝等等
- 广告：广告位、广告填充、冷却处理
- 数据上报（自己有则不需要）
- 聊天（也可以自己造！）
- 版本功能开关控制（或许可以归类到通用的后台配置中）
-
@Pamisu 感谢！国际化这个晓得，但是写的时候忘记了
补充一点，采用国际化的时候就尽量少使用角标这类型的设计，因为很容易角标写不下
