MMO游戏运营数据的采集方法与流程

本发明涉及大型多人在线(mmo)网络游戏的运营管理等，具体地说是涉及如何采集mmo游戏运营中的各种相关数据以供研发、维护、运营、管理等各部门用于分析，改进相应的运营策略。本发明可应用于各种网络游戏的运营，特别是面对大型多人在线游戏，目前已经成功应用于多款手游中。

背景技术：

一般在线游戏的生命周期分为游戏立项、评审、内测、封测、公测这些前期阶段，以及维护与运营管理等后期商业化阶段。在前期，开发团队会将主要精力放在技术模块、美术资源，玩法策划与数值策划三大主要方面；特别是在开发周期有限，策划玩法主体有重大变更的mmo多人大型在线游戏开发过程中尤为突出。

游戏的开发周期中运营管理的切入点在整个研发周期后段。随着游戏开发不断完善，游戏的生命周期渡过了立项、评审、内测、封测、公测这些重要且艰难的时刻，逐渐过渡到运行维护与运营管理等真正意义的商业化阶段，这个阶段意味着真金白银且决定了游戏的成功与辉煌。在这个阶段管理团队面对的主要问题与亟待解决的课题也自然过渡到掌控玩家留存与活跃、充值与消费、消费点占比、甄别作弊与非法获利、有效玩法模块、玩家喜好、游戏内汇率物价波动、非法广告、安全对抗、玩家投诉善后、故障定位等全领域的游戏经营与分析。

游戏经营分析数据是任何一款游戏取得成功的关键后继环节。目前还在运营的各类端游、页游和手机游戏，后继的游戏运营分析数据模式上都有各自的不同特点，但主要的问题依然可以归结如下：1.过分关注营收，数据粒度粗，对于用于改善经营需要的数据不足；2.数据单一，不能查询定位复杂逻辑关系；3.数据质量参差不齐，关键性数据一旦丢失，造成历史空白不能还原历史；4.数据结构混乱，把多个不同事件的数据混存一起，不便规模化处理；5.数据存储方式随意，异质的存储形式，导致后期运营数据分析异常复杂，几乎难以实现；6.没有规格划的数据结构，无法复用，增加后期开发成本，带来系统稳定性风险。

技术实现要素：

为解决上述以往所收集的游戏经营分析数据的各种问题，本发明提供一种mmo游戏运营数据采集方法，其主要包括以下步骤：

步骤s1：根据实际需求，对mmo游戏主要玩法内容转换为多个可以单独考虑的不同视角，即维度化；

步骤s2：根据步骤s1转换得到的多个维度确定相应于所述多个维度的mmo游戏经营分析数据的数据结构；

步骤s3：开发相应的mmo经营分析数据获取模块，并进行部署以实现相关数据的采集；

步骤s4：将获取到的mmo游戏经营分析数据通过网络以报文方式传输到异地保存，并在本地留底；并将mmo游戏经营分析数据导入数据库以满足各类二次开发的需要。

在步骤s1中实际需求由需求方(运营管理决策者、运行维护团队、业务受理部门、安全部门、客户关系与支持、市场宣传部门等)根据自身工作职能针对需要获取的游戏经营分析数据提出相应的需求，并对游戏主要玩法内容转换为可以单独考虑的视角即维度化，这些不同的视角可以从不同的侧面反映/印证某项业务的运行状况/某一事件或行为的发生，即从多维角度共同反映/印证某一事件。

步骤s2中相应于所述多个维度的mmo游戏经营分析数据的数据结构由相应的规范文件来确定/规范。所述规范文件规定相关的数据结构至少包括：基础数据和业务数据，其中基础数据包含某游戏行为事件发生时的出处、时间；业务数据包含此事件的参与者、参与内容、参与程度及事件状态机等主要业务相关内容。并且在规范化化的过程中尽量多地使用数字/数值来代表特定的信息即使将相关的信息数字化/数值化。

步骤s4中:将获取的mmo游戏经营分析数据导入数据库，所述的数据库以所述的规范文件为标准结构的数据库，在数据导入过程中按照所述的规范文件对游戏经营分析数据进行相应的合规性检测，并生成检测报告。

附图说明

图1为本发明实现mmo游戏经营分析数据采集方法的工作流程图；

图2至图5为本发明针对某款mmo游戏设计的获取经营分析数据的部分规范文件的内容。

具体实施方式

为了使本发明所解决的技术问题、技术方案以及有益效果更加清楚明白，以下结合附图对本发明进行进一步详细说明。应该理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

参照图1，本发明提供一种实现mmo游戏经营分析数据的采集的流程图，如图1所示其包括以下步骤：

步骤s1：根据实际需求，对mmo游戏主要玩法内容转换为多个可以单独考虑的不同视角，即维度化；

步骤s2：根据步骤s1转换得到的多个维度确定相应于所述多个维度的mmo游戏经营分析数据的数据结构；

步骤s3：开发相应的mmo经营分析数据获取模块，并进行部署以实现相关数据的采集；

步骤s4：将获取到的mmo游戏经营分析数据通过网络以报文方式传输到异地保存，并在本地留底；并将mmo游戏经营分析数据导入数据库以满足各类二次开发的需要。

在步骤s1中，需求方(运营管理决策者、运行维护团队、业务受理部门、安全部门、客户关系与支持、市场宣传部门等)根据自身工作职能针对各自需要获取的mmo游戏经营分析数据提出相应的需求。在mmo游戏的商业化运行中，游戏公司为了获取更好的经营业绩，需要及时了解玩家的喜好、甄别作弊与非法获利、游戏中的缺陷、玩家的体验反馈、玩家的活跃度以及消费等情况，以便及时进行改善和维护。为此游戏公司各个业务部门需要根据自己的职能提出相应的mmo游戏经营分析数据需求，以获取各自关心的游戏经营分析数据。例如客户关系与支持部门需要获取玩家的意见以及投诉，运营管理决策者需要获取玩家的活跃度以及相应的消费情况等。根据具体的实际需求对游戏主要玩法内容转换为可以单独考虑的视角即维度化，这些不同的视角可以从不同的侧面反映某些业务的运行状况，即从多维角度共同印证某些事件。例如为了发现游戏中玩家是否作弊这一情况，即使相应的安全模块缺失了相关玩家作弊的记录，也可以从道具的流转，物品拍卖记录，玩家资产的流动、人物等级流水等多个视角分别设置相应的数据结构从多个维度记录相关的信息。如发现在某一时刻玩家的道具增加原因是发生了交易行为，但在同一时刻该玩家的资产未发生减少，则可以判断游戏运营中该玩家实施了作弊。

在步骤s2中，相应于所述多个维度的mmo游戏经营分析数据的数据结构由相应的规范文件来确定/规范。所述规范文件规定相关的数据结构至少包括：基础数据和业务数据，其中基础数据包含某游戏行为事件发生时的出处、时间；业务数据包含此事件的参与者、参与内容、参与程度及事件状态机等主要业务相关内容。并且在规范化化的过程中尽量多地使用数字/数值来代表特定的信息即使将相关的信息数字化/数值化。所述规范文件还必须满足以下条件：

1.规范文件要语义清晰，所有字段必须含数据类型、大小及中文描述；

2.规范文件要对状态机的各种状态做含义解释；

3.规范文件规设置自研工具，以进行数据构成与实际生成的游戏经营分析数据相对应的合规性检测，并生成检测报告；

4.规范文件要有变更(增加，删除，更改)checklist附件文件，用于记录何时何人对规范文件做了何种修改。并且规范文件尽量不要删除原有字段，造成数据构成的改变，这种改变会引起下游环节产生意想不到的问题。只增加不删除，无用字段闲置弃用最佳；

5.规范文件要求对一条mmo游戏经营分析数据进行大小限定例如将其限定为1kb以内。

图2为规范文件中为了记录玩家道具的流动情况设置了专门的数据结构“itemflow”，该结构中各种字段的名称，类型以及相关的含义的描述。其中字段包括类型为“datetime”型的“dteventtime”字段(游戏事件发生的时间)、类型为“int”型的“platid”字段(平台类型，当其值为0时表示ios，为1时表示android)、类型为“int”的“izoneareaid”字段(针对分区分服的游戏填写分区id，用来唯一标示一个区；非分区分服游戏请填写0)、类型为“uint”的“vroleid”字段(角色id)、类型为“int”的“jobid字段”(职业编号)、类型为“int”的“level”字段(等级)、类型为“int”的“itemtype”字段(道具类型)、类型为“int”的“itemid”字段(道具id)、类型为“int”的“aftercount”字段(动作后物品的存量)、类型为“int”的“count”字段(本次发生数量)、类型为“int”的“addorreduce”字段(货币增加或减少，值为0时增加、为1时减少)、类型为int的reason字段(道具流动的一级原因)、类型为int的subreason字段(道具流动的二级原因)。

图3所示的规范性文件的部分内容定义了游戏中货币的类型的数据结构imoneytype,当其值为1时、代表游戏中的货币为mt_money(元宝)，当其值为2时、代表游戏中的货币为mt_coupon(点券)，当其值为3时、代表游戏中的货币为mt_gold(金币)，当其值为5时、代表游戏中的货币为mt_coupon(技能书页)，当其值为6时、代表游戏中的货币为mt_point(贡献点)，当其值为7时、代表游戏中的货币为mt_coupon(声望)。同时图3所示的规范文件的部分内容还分别定义了用于记录玩家货币流动的数据结构“moneyflow”,该结构中各种字段的名称，类型以及相关的含义的描述。其中字段包括类型为“datetime”型的“dteventtime”字段(游戏事件发生的时间)、类型为“int”型的“platid”字段(平台类型，当其值为0时表示ios，为1时表示android)、类型为“int”的“izoneareaid”字段(针对分区分服的游戏填写分区id，用来唯一标示一个区；非分区分服游戏请填写0)、类型为“uint”的“vroleid”字段(角色id)、类型为“int”的“jobid字段”(职业编号)、类型为“int”的“level”字段(等级)、类型为“int”的“imoneytype”字段(货币的类型)、类型为“uint64”的“aftermoney”字段(动作后的货币数)、类型为“int”的“imoney”字段(动作涉及的货币数)、类型为“int”的“addorreduce”字段(货币增加或减少，值为0时增加、为1时减少)、类型为int的reason字段(货币流动的一级原因)、类型为int的subreason字段(货币流动的二级原因)等。

图4所示的规范性文件的部分内容定义了游戏中记录人物等级流水的数据结构playlvflow，其包含的字段除了之前介绍的dteventtime、patid、izoneareaid、vroleid、jobid、level、reason(道具流动的一级原因)、subreason字段(道具流动的二级原因)这些字段以外，还包括类型为“int”的“curexp”字段(当前经验)、类型为“int”的“beforelevel”字段(动作前等级)、类型为“int”的“afterlevel”字段(动作后等级)以及类型为“int”的“time”字段(升级所用时间)。

图5所示的规范性文件的部分内容定义了游戏中拍卖信息发送日志挂单的数据结构是secbusinessshopshowflow，其包含的字段除了之前介绍的dteventtime、platid字段以外，还包括类型为“int”的“areaid”字段(账户的类型，当其值为0时代表微信、为1时代表手机qq、为3时代表游客)、类型为“int”的“zoneid”字段(小区号id)、类型为“uint64”的“roleuid”字段(卖方角色ruid)、类型为“int”的“rolejobid”字段(卖方角色职业编号)、类型为“int”的“rollevel”字段(卖方角色等级)、类型为“int”的“userip”字段(卖房玩家ip地址)、类型为“uint64”的“acutionid”字段(交易行为挂单编号，与交易行为完成日志中的挂单编号一致)、类型为“int”的“acutionmaintype”字段(拍品主类型)、类型为“int”的“acutionsubtype”字段(拍品子类型)、类型为“int”的“acutionpricetype”字段(价格类型，0为元宝、1为金币)、类型为“int”的“acutionprice”字段(拍品价格)、类型为“int”的“acutionitemi”字段(拍品道具编号)、类型为“int”的“acutionsubtype”字段(拍品子类型)、类型为“uint64”的“acutionuuid”字段(拍品uui)、类型为“int”的“acutionlevel”字段(拍品等级)、类型为“int”的“acutionqlty”字段(拍品品质等级)、类型为“int”的“acutionsubtype”字段(拍品子类型)、类型为“int”的“acutiontime”字段(拍品挂单时间)、类型为“int”的“itemamount”字段(拍品数量)。

根据图2-图5所示规范性文件的部分内容，当游戏中的安全模块未发现作弊事件时，游戏运营者从数据结构“itemflow”、“moneyflow”、“playerlvflow”等多个维度综合检测出可能的作弊行为。如发现在某一时刻玩家的道具增加、其原因是对发生了相应的道具交易行为，但是同一时刻资产并未发生减少则可以判断游戏运营中该玩家实施了作弊/产生异常；或者某一时刻玩家的道具增加或者战斗力提升。其原因是玩家的等级发生了改变但从数据结构“playerlvflw”看同一时刻该玩家等级并未提升，则可判断发生作弊/异常。

在步骤s3中，开发相应的mmo游戏经营分析数据获取模块，并进行部署以实现相关数据的获取。例如可以在mmo游戏客户端中增加用于获取经营分析数据的模块/代码段，用于及时获取相关的数据。

在步骤s4中，mmo游戏经营分析数据一旦生成通过网络以报文方式传输到异地保存，并在本地留底，防止应网络问题造成的数据缺失；并将mmo游戏经营分析数据导入以规范文件为标准结构的数据库，这样可以做到方便满足各类二次开发的需要。所述的报文可以是udp/tcp报文。

本发明mmo游戏经营分析数据采集方法很好地支持了自身业务与不断拓展的需要，总结其优点如下：

1.部署流程顺畅，高效结合需求方、开发方、第三方、维护方和使用方的关切，降低沟通成本；

2.支持游戏经营分析数据信息品类广泛(性能、业务、安全、行为)，这样可以做到总览与细分实现灵活，使一批游戏经营分析数据支持粒度粗细不同的经营分析需要；

3.支持多角度考察某单独业务模块；

4.拒绝数据造假与便于发现缺失等异常，由于任何游戏内事件的发生必然反映正在多个维度(二维以上)，这样一个维度数据的缺失可以从另一个维度的数据来印证；

5.数据结构通过规范文件管理，结构有序、语义清晰、变更历史可以追溯；

6.降低数据复杂度，轻松管理更多的业务模块；

7.可以快速有效还原历史数据缺失，提高数据结构的复用性，减少后期开发成本。