CN118179044A - 游戏公会合并方法及设备 - Google Patents

Abstract

本申请实施例提供一种游戏公会合并方法及设备。该方法中，获取第一公会的玩家信息，玩家信息包括第一公会中的玩家行为数据；根据玩家信息确定第一公会的公会健康度，公会健康度用于表示第一公会的运营情况，公会健康度与玩家行为数据相关；检测公会健康度是否达到合并条件；若公会健康度达到合并条件，将第一公会合并到第二公会。该方法通过公会健康度可以及时发现并回收运营情况不佳的游戏公会，避免玩家因误入此类公会而导致的游戏体验下降，改善玩家体验，提高玩家留存率。并且，通过公会健康度可合并游戏公会，从而有效减少游戏公会数量，降低游戏公会所占用的网络资源，提高网络资源利用率。

Description

游戏公会合并方法及设备

技术领域

本申请涉及计算机技术领域，尤其涉及一种游戏公会合并方法及设备。

背景技术

目前，游戏公会(也可称为家族、帮派、门派等)，是多人在线游戏中常见的玩家社交平台。

相关技术中，公会通常由玩家自行创建，创建门槛较低，导致公会数量过多，需要消耗较多的网络资源。此外，公会通常由创建者自行运营，因而游戏平台难以对公会进行监管，无法调整调配相应的网络资源，影响玩家体验。例如，对于创建者已流失的公会，或恶意创建(如广告推广等)的公会，游戏平台无法将其解散并回收相应的网络资源，既占用了网络资源，又干扰了玩家对公会的选择和体验，甚至使加入此类公会的玩家因公会缺少活力(比如聊天人数较少，活动较少)、或广告过多体验不佳等原因而离开，大大降低玩家的留存率。

因此，亟待提出一种用于调配网络资源，提升玩家留存率的方案，用以解决上述至少一个技术问题。

发明内容

本申请的多个方面提供一种游戏公会合并方法及设备，用以提高玩家留存率，降低游戏公会所占用的网络资源，提高网络资源利用率。

本申请实施例提供一种游戏公会合并方法，该方法包括：

获取第一公会的玩家信息，玩家信息包括第一公会中的玩家行为数据；

根据玩家信息确定第一公会的公会健康度，公会健康度用于表示第一公会的运营情况，公会健康度与玩家行为数据相关；

检测公会健康度是否达到合并条件；

若公会健康度达到合并条件，将第一公会合并到第二公会。

进一步可选地，该方法还包括：响应第一玩家的公会创建请求，建立与第一玩家关联的第一公会，第一公会设置为待响应公会；发布第一公会，以使第二玩家响应发布信息，并加入设置为待响应公会的第一公会；检测第一公会是否达到预先设置的创建条件，创建条件与第二玩家相关；若第一公会达到创建条件，将第一公会从待响应公会切换至正式公会，以完成第一公会的创建。

其中，进一步可选地，创建条件包括加入第一公会的第二玩家数量超过设定数量阈值。

检测第一公会是否达到预先设置的创建条件，包括：响应第二玩家的加入请求，将第二玩家添加至第一公会，并更新第二玩家数量；检测第二玩家数量是否超过设定数量阈值。

若第一公会达到创建条件，将第一公会从待响应公会切换至正式公会，包括：若第二玩家数量超过设定数量阈值，则在公会管理器中将第一公会注册为正式公会；将第一公会从待响应公会列表切换至公会列表中。

其中，进一步可选地，该方法还包括：在发布第一公会之后的第一预设时长内，若第一公会未达到创建条件，则取消创建第一公会。

进一步可选地，根据玩家信息确定第一公会的公会健康度，包括：

从玩家行为数据中获取预设时段内的任务执行情况，其中，任务执行情况包括以下至少一种信息：玩家执行玩法任务的次数、在玩法任务中达成的目标数量、玩家经验值；根据任务执行情况计算得到公会健康度。

其中，进一步可选地，预设时段为设定天数，玩家经验值包括战令经验值。

根据任务执行情况计算得到公会健康度，包括：将设定天数内第一公会中所有玩家的战令经验值相加，并以所有玩家的战令经验值之和作为成员活跃指数；将成员活跃指数与第一公会的公会规模参数输入预设算法模型中，得到公会健康度；其中，公会规模参数由第一公会中的玩家数量决定。

进一步可选地，检测公会健康度是否达到合并条件，包括：基于公会健康度确定第一公会所属等级；根据第一公会所属等级判断第一公会是否符合合并条件。

若公会健康度达到合并条件，将第一公会合并到第二公会，包括：

若第一公会符合合并条件，则将第一公会和第二公会注册到公会管理器的待合并公会列表中；在预设周期内遍历待合并公会列表，并对待合并公会列表中待合并的第一公会和第二公会对进行合并操作，以使加入第一公会的所有玩家转移到第二公会。

其中，进一步可选地，根据第一公会所属等级判断第一公会是否符合合并条件，包括：判断第一公会所属等级是否为符合自动合并条件的第一等级。

若第一公会符合合并条件，则将第一公会和第二公会注册到公会管理器的待合并公会列表中，包括：

若第一公会所属等级为第一等级，则向第一公会发布合并警告；在合并警告发出后的第二预设时长内，若第一公会的公会健康度未达到独立存续条件，则将第一公会与公会健康度排在第二预设位次的第二公会，注册为公会管理器的公会列表中的待合并公会对；其中，独立存续条件包括第二预设时长内第一公会的公会健康度排在第一预设位次。

在预设周期内遍历待合并公会列表，并对待合并公会列表中待合并的第一公会和第二公会对进行合并操作，包括：在待合并公会对注册之后的设定时刻，将第一公会的所有玩家从第一公会的成员列表转移至第二公会的成员列表中，并注销第一公会以及第一公会中管理成员的管理成员身份。

其中，进一步可选地，根据第一公会所属等级判断第一公会是否符合合并条件，还包括：若第一公会所属等级不是第一等级，则判断第一公会的管理成员是否提出手动合并请求；判断第一公会所属等级是否为符合手动合并条件的第二等级。

若第一公会符合合并条件，则将第一公会和第二公会注册到公会管理器的待合并公会列表中，包括：

若第一公会的管理成员提出手动合并请求，并且第一公会所属等级为第二等级，则向第二公会发送合并邀约请求，或者接收第二公会发送的合并邀约请求；在合并邀约请求被接收后的第三预设时长内，若第一公会和第二公会达成合并邀约，则将第一公会和第二公会注册为公会管理器的公会列表中的待合并公会对。

进一步可选地，该方法还包括：响应对第一公会发出的弹劾请求，发布弹劾请求，以使第三玩家响应弹劾请求，并确认是否基于弹劾请求更换第一公会中的管理成员；其中，弹劾请求中包括请求更换为新管理成员的玩家的标识，请求更换为新管理成员的玩家属于第一公会；若确认更换管理成员的第三玩家数量达到弹劾人数阈值，则将第一公会中的管理成员更换为弹劾请求中的新管理成员。

本申请实施例还提供一种电子设备，包括：存储器和处理器；所述存储器用于存储一条或多条计算机指令；所述处理器用于执行所述一条或多条计算机指令以用于：执行本申请实施例提供的方法中的步骤。

本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，计算机程序被执行时能够实现本申请实施例提供的方法中的步骤。

在本申请实施例提供的技术方案中，获取第一公会的玩家信息，该玩家信息包括第一公会中的玩家行为数据。进而，根据玩家信息确定第一公会的公会健康度。由于公会健康度与玩家行为数据相关，因而，通过公会健康度可以看出第一公会中玩家的表现情况，从而采用玩家表现情况反映第一公会的运营情况。进而，基于第一公会的运营情况考虑是否对第一公会进行相关处理，具体来说，可以检测公会健康度是否达到合并条件，若公会健康度达到合并条件，将第一公会合并到第二公会，以避免第一公会中的玩家因公会运营情况而导致的体验不佳，提高玩家留存率。综合上述步骤，通过公会健康度可以及时发现并回收运营情况不佳的游戏公会，避免玩家因误入此类公会而导致的游戏体验下降，改善玩家体验，提高玩家留存率。并且，通过公会健康度可合并游戏公会，从而有效减少游戏公会数量，降低游戏公会所占用的网络资源，提高网络资源利用率。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请一示例性实施例提供的游戏公会合并方法的流程示意图；

图2为本申请一示例性实施例提供的申请界面的示意图；

图3为本申请一示例性实施例提供的邀请界面的示意图；

图4为本申请一示例性实施例提供的公会创建方法的流程示意图；

图5为本申请一示例性实施例提供的创建界面的示意图；

图6为本申请一示例性实施例提供的自荐界面的示意图；

图7为本申请一示例性实施例提供的电子设备的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

目前，游戏公会，又称家族、帮派、门派等，是多人在线游戏中常见的玩家社交平台。游戏公会通常由多个玩家组成，玩家可在公会中聊天、或参与游戏副本等活动，因而游戏公会大大丰富了玩家的游戏体验。本申请中将游戏公会简称为公会。

相关技术中，公会通常由玩家自行创建，创建门槛较低，导致公会数量过多，需要消耗较多的网络资源。比如，需要为公会建立相应的语音频道，创建游戏副本资源等。并且，公会数量过多，公会平均人数较少，也会出现聊天氛围不足的问题，影响玩家体验，降低玩家的留存率。

此外，随着游戏市场的日益繁荣，如何留住游戏中的玩家，以提高玩家留存率，成为游戏研发运营的关键问题之一。目前，相关技术中，上述公会通常由创建者自行运营，比如由创建者对公会进行日常管理、活动组织、解散等社群维护操作，因而游戏平台难以对公会进行监管，无法调整调配相应的网络资源，影响玩家体验。例如，对于创建者已流失的公会，或恶意创建(如广告推广等)的公会，游戏平台无法将其解散并回收相应的网络资源，既占用了网络资源，又干扰了玩家对公会的选择和体验，甚至使加入此类公会的玩家因公会缺少活力(比如聊天人数较少，活动较少)、广告过多导致体验不佳等原因而离开，大大降低玩家的留存率。

因此，亟待提出一种用于调配网络资源，提升玩家留存率的方案，用以解决上述至少一个技术问题。

本申请实施例提供一种游戏公会合并方法及设备，可应用于游戏场景，涉及至少一终端设备，和/或至少一服务设备。例如，至少一终端设备可以是手机、平板电脑、PC等，终端设备中搭载有游戏的客户端，至少一服务设备可以是服务器，从而，由上述至少两个设备相配合以执行游戏场景中游戏公会合并的各个步骤。

相较于相关技术，本申请实施例中，获取第一公会的玩家信息，该玩家信息包括第一公会中的玩家行为数据。进而，根据玩家信息确定第一公会的公会健康度。由于公会健康度与玩家行为数据相关，因而，通过公会健康度可以看出第一公会中玩家的表现情况，从而采用玩家表现情况反映第一公会的运营情况。例如，若第一公会中玩家执行任务的次数较为频繁，那么，说明第一公会的玩家较为活跃，第一公会当前的运营情况较为良好；而第一公会中玩家执行任务的次数较少，则说明第一公会的玩家并不活跃，第一公会当前的运营情况存在一定问题，此时需要考虑是否对第一公会进行相关处理，比如将第一公会合并到较为活跃的其他公会中。具体来说，本申请实施例中，可以检测公会健康度是否达到合并条件，若公会健康度达到合并条件，将第一公会合并到第二公会，以避免第一公会中的玩家因公会运营情况而导致的体验不佳，提高玩家留存率。从而，通过公会健康度可以及时回收运营情况不佳的游戏公会，避免玩家因误入此类公会而导致的游戏体验下降，改善玩家体验，提高玩家留存率。并且，通过公会健康度可合并游戏公会，从而有效减少游戏公会数量，降低游戏公会所占用的网络资源，提高网络资源利用率。尤其是，及时释放创建者已流失的公会、恶意创建(如广告推广等)的公会等运营情况不佳的游戏公会所占用的网络资源。

需要说明的是，本申请实施例涉及的服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式***，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。

本申请实施例涉及的终端设备，可以是指向用户提供语音和/或数据连通性的设备，具有无线连接功能的手持式设备、或连接到无线调制解调器的其他处理设备。例如移动电话(或称为“蜂窝”电话)和具有移动终端的计算机，例如，可以是便携式、袖珍式、手持式、计算机内置的或者车载的移动装置，它们与无线接入网交换语音和/或数据。例如，个人通信业务(Personal Communication Service，PCS)电话、无绳电话、会话发起协议(SIP)话机、无线本地环路(Wireless Local Loop，WLL)站、个人数字助理(Personal DigitalAssistant，PDA)等设备。

针对上述技术问题，在本申请一些实施例中，提供了一种解决方案，以下结合附图，详细说明本申请各实施例提供的技术方案。

本申请实施例提供了一种游戏公会合并方法，图1为本申请一示例性实施例提供的游戏公会合并方法的流程示意图。该方法可应用于游戏场景下服务设备和/或搭载游戏客户端的终端设备，由终端设备和/或服务设备执行本方法的具体流程。如图1所示，该方法包括：

101、获取第一公会的玩家信息，玩家信息包括第一公会中的玩家行为数据；

102、根据玩家信息确定第一公会的公会健康度，公会健康度用于表示第一公会的运营情况，公会健康度与玩家行为数据相关；

103、检测公会健康度是否达到合并条件；

104、若公会健康度达到合并条件，将第一公会合并到第二公会。

通过上述方法通过公会健康度来实现游戏公会之间的合并，能够及时发现并回收运营情况不佳的游戏公会，从而，既可避免公会中的玩家因公会运营不佳而导致的游戏体验下降，提高玩家留存率，又可有效减少游戏公会数量，降低游戏公会所占用的网络资源，提高网络资源利用率。

下面将分别介绍上述方法中各个步骤的具体实施过程。

本申请实施例中，玩家进入游戏后，可通过公会列表选择想加入的公会。例如，游戏界面中可展示“公会大厅”控件，玩家通过选择该控件获取可加入的公会列表，并选择加入该公会列表中发布的一个公会。公会列表中发布有已创建的公会、以及正处于待响应阶段的待响应公会。本申请涉及的公会创建方式参见下文实施例，此处暂不展开。

当然，也可以通过其他途径加入公会，本申请并不限定。例如，玩家可由好友邀请加入到某一公会，或者在参与某一玩法后，由***基于玩家的玩法偏好推荐可加入的游戏公会，并从该玩法跳转到游戏公会的加入界面。

玩家加入到游戏公会之后，可以在游戏公会中与其他玩家进行社交，参加游戏公会中的活动。相关技术中，公会通常由玩家自行创建并管理，创建门槛较低，导致公会数量过多，需要消耗较多的网络资源。并且，相关技术中由于公会是由创建者自行运营的，因而游戏平台难以对公会进行监管，无法调整调配相应的网络资源，影响玩家体验。

针对上述问题，本申请实施例中，提供了一种全新的游戏公会合并方式，用以对游戏中创建的公会进行监测，从而及时发现并回收运营情况不佳的游戏公会，避免玩家加入到公会运营不佳的公会而导致的游戏体验下降，提高玩家留存率，同时有效减少公会数量，降低公会所占用的网络资源，提高网络资源利用率。为便于描述，本申请将需要监测的公会称为第一公会。

对于游戏中需要监测的第一公会，首先需要了解该公会的运营情况。基于此目的，101中，可以先获取第一公会的玩家信息。进而，102中，根据玩家信息确定第一公会的公会健康度。其中，公会健康度用于表示第一公会的运营情况，该公会健康度与玩家行为数据相关。

本申请实施例中，第一公会的玩家信息，可以是加入到第一公会的各个玩家的玩家信息。其中，各个玩家的玩家信息包括但不限于以下任意一种或组合：各个玩家的玩家行为数据、配置数据、游戏客户端数据。第一公会的玩家信息，也可以是对加入到第一公会的所有玩家在某一维度上的玩家信息的统计数据。例如，对第一公会中所有玩家执行公会日常任务的频率进行统计，得到第一公会的玩家日常任务活跃度。或者，也可以对第一公会中所有玩家在公会中聊天的频率进行统计，得到第一公会的玩家社交活跃度。此处用于评估玩家行为表现的维度可根据实际需求制定，本申请并不限定。

具体来说，玩家行为数据包括但不限于以下任意一种或组合：各个玩家的登录数据、玩法数据、培养***数据、技能***数据、武器***数据、宠物***数据、等级数据、战力数据、***使用数据、副本数据、体力数据、玩家偏好数据(比如玩家偏好登陆时段、玩家偏好地图、玩家偏好角色类型等)。其中，各个玩家的登录数据包括但不限于：登录天数、登录时长、登录时段。玩法数据包括但不限于：玩家参与的游戏任务、任务类型、任务执行结果(如奖品、彩蛋效果、等级提升效果等)，或者也可以是玩家参与的游戏关卡、关卡、关卡执行结果(如奖品、彩蛋效果、等级提升效果等)，还可以是玩家参与的公会团队活动、特定活动玩法、随机玩法。特定活动玩法可根据当前时间(如春节、七夕等)或者玩家位置(如玩家所处地块、玩家所处地形区域)设置。

通过玩家信息可以反映第一公会中各个玩家在游戏公会中的表现。例如，基于各个玩家的玩家行为数据可以反映出各个玩家在游戏公会中所处状态(如聊天状态、战斗状态、休闲状态)、武器使用情况、道具使用情况、击杀表现、采集表现、宠物升级情况，等等。

进而，基于第一玩家的玩家信息可以进一步确定第一公会的运营情况。

本申请实施例中主要通过公会健康度这一指标来表示公会的运营情况。可选地，还可以基于公会健康度为公会列表中的公会进行排序，以便玩家参考这一排序选择自身喜欢的公会。在公会健康度排序中，一个公会的排名越靠前，说明该公会的公会健康度越高，表示该公会的运营情况越好。这一指标与玩家信息中的玩家行为数据相关，可以根据玩家行为数据确定对应公会的公会健康度。当然，实际应用中，除了玩家行为数据之外，公会健康度还可以结合其他参数综合评估，例如，公会规模、公会规模变化(如新增玩家数量)、公会等级提升速度、公会中玩家之间的社交活动发起次数、公会玩家的虚拟资产变化情况，等等。

在一可选实施例中，102中根据玩家信息确定第一公会的公会健康度的一种实现方式为：

首先，102中，从玩家行为数据中获取预设时段内的任务执行情况。

本申请实施例中，预设时段内的任务执行情况，包括以下至少一种信息：玩家执行玩法任务的次数、玩法任务类型、在玩法任务中达成的目标数量、玩家经验值、玩家在线时长。玩法任务类型比如是游戏剧情关卡、游戏副本、特殊玩法活动(如节假日的玩法活动等)。上述任务执行情况的统计时段可以根据实际需求预先设置为设定天数，也可以根据公会规模、服务器中的活跃玩家数量来动态设置，本申请并不限定。例如，上述任务执行情况的统计时段可以根据实际需求预先设置为3天。或者，也可以在寒暑假或节日时将上述统计时段设置为3天，在非假期时段中将上述统计时段设置为7天。

进而，102中，根据预设时段内的任务执行情况计算得到公会健康度。可选地，公会健康度记录在第一公会的公会公共数据中，例如，记录第一公会的近3天中每天的公会健康度数据。

具体而言，在一可选实施例中，假设预设时段为设定天数。假设预设时段内的任务执行情况中包括玩家经验值，并且假设玩家经验值包括战令经验值。基于上述假设，根据任务执行情况计算得到公会健康度的步骤可以实现为：将设定天数内第一公会中所有玩家的战令经验值相加，并以所有玩家的战令经验值之和作为成员活跃指数；将成员活跃指数与第一公会的公会规模参数输入预设算法模型中，得到公会健康度。其中，公会规模参数由第一公会中的玩家数量决定。

例如，假设设定天数为3天，假设任务执行情况包括3天内第一公会中各个玩家的战令经验值，战令经验可通过玩家完成日常任务增加。基于上述假设，可以将3天内第一公会中所有玩家的战令经验值相加，从而以3天内所有玩家的战令经验值之和作为成员活跃指数。进而，通过以下算法公式对成员活跃指数与第一公会的公会规模参数进行计算，得到公会健康度，即：公会健康度＝(成员活跃指数/((第一公会中的玩家数量*80+80)*200*3))*100。

除了战令经验值之外，还可以基于第一公会中各个玩家在预设时段内产生的其他玩家信息计算公会健康度，此处并不限定。例如，根据3天内第一公会中玩家的登录频次计算公会健康度。例如，根据一周内第一公会中参与公会团体任务的玩家数量以及公会规模计算公会健康度。

值得说明的是，可选地，第一公会中的玩家完成各类玩法时，如完成日常任务，会为第一公会增加增加各类玩法对应的活跃度。通过活跃度可为公会健康度额外加成，从而，活跃度越高，公会的公会健康度越高。进一步可选地，公会健康度与公会中玩家的游戏收益和/或游戏技能输出值绑定，从而鼓励玩家积极参与各类玩法增加公会健康度。

103中，检测公会健康度是否达到合并条件。

104中，若公会健康度达到合并条件，将第一公会合并到第二公会。

具体来说，在一可选实施例中，103中，基于公会健康度确定第一公会所属等级；根据第一公会所属等级判断第一公会是否符合合并条件。进而，104中，若第一公会符合合并条件，则将第一公会和第二公会注册到公会管理器的待合并公会列表中；在预设周期内遍历待合并公会列表，并对待合并公会列表中待合并的第一公会和第二公会对进行合并操作，以使加入第一公会的所有玩家转移到第二公会。

本申请实施例中，公会等级主要根据公会健康度设置。例如，基于前文示例中的公式计算得到的公会健康度，可以根据公会健康度可以将公会分为多个等级。具体而言，根据公会健康度的数值从低到高，对应的公会所属等级依次为：岌岌可危(对应公会健康度的数值为0至9之间)、摇摇欲坠(对应公会健康度的数值为10至29之间)、欣欣向荣(对应公会健康度的数值为30至49之间)、兴旺发达(对应公会健康度的数值为50以上)。本申请实施例中公会等级越高，公会健康度越高，说明公会的运营情况越好。当然，公会等级的划分方式并不限定于上述示例的4个等级，还可以划分为6个等级、8个等级、12个等级。

针对公会所属等级不同，可以设置适用于不同等级公会的合并条件。下面结合具体示例介绍不同等级公会适用的合并条件。

一方面，对于等级较低的公会，其对应的公会健康度较低，说明公会的运营情况不佳。此情况下，为避免玩家加入此类公会导致的诸多问题(如玩家体验不佳，甚至玩家流失)，避免公会数量过多导致的网络资源消耗过大，需要及时发现并回收此类公会。因而，本申请中设置了自动合并条件，用以从众多公会中筛选出运营情况不佳的公会，并及时回收此类公会。

具体来说，在一可选实施例中，103中，根据第一公会所属等级判断第一公会是否符合合并条件，包括：判断第一公会所属等级是否为符合自动合并条件的第一等级。继续上文示例，假设符合自动合并条件的第一等级可以是岌岌可危(对应公会健康度的数值为0至9之间)，那么，需要判断第一公会所属等级是否为岌岌可危。

进而，104中，若第一公会符合合并条件，则将第一公会和第二公会注册到公会管理器的待合并公会列表中，包括：若第一公会所属等级为第一等级，则向第一公会发布合并警告；在合并警告发出后的第二预设时长内，若第一公会的公会健康度未达到独立存续条件，则将第一公会与公会健康度排在第二预设位次的第二公会，注册为公会管理器的公会列表中的待合并公会对。在合并警告发出后的第二预设时长内，若第一公会的公会健康度达到独立存续条件，则取消针对第一公会的自动合并操作。

其中，独立存续条件包括但不限于：第二预设时长内第一公会的公会健康度排在第一预设位次。例如，第二预设时长内第一公会的公会健康度排在公会列表中的前30位(如第一预设位次)。或者，独立存续条件也可以设置为：第二预设时长内第一公会所属等级脱离第一等级。或者，独立存续条件也可以设置为：第二预设时长内第一公会所属等级达到高于第一等级的第二等级。

继续上文示例，假设符合自动合并条件的第一等级可以是岌岌可危(对应公会健康度的数值为0至9之间)，假设前述步骤中判定第一公会所属等级为岌岌可危。假设独立存续条件为：5天(即第二预设时长)内第一公会所属等级高于岌岌可危的欣欣向荣(即第二等级)。

基于上述假设，需要向第一公会发布合并警告。该合并警告用于表示公会运营情况极差。此情况下，若不及时优化该第一公会的运营情况，则需停止该第一公会的运营，并将该第一公会合并至其他公会中，以保证该第一公会中各个玩家的玩家体验。在判定第一公会所属等级为岌岌可危之后，可以向第一公会的一级管理者(如创建者)和二级管理者(如被授权的管理者)发送通知邮件，并在邮件中指示上述管理者，在合并警告发出后的3天内，若第一公会所属等级未达到欣欣向荣(对应公会健康度的数值为50以上)，则三天后将该第一公会随机合并到公会健康度排名最高的前十个公会(即第二预设位次)中的任意一个。从而，在合并警告发出后的3天内，若第一公会所属等级未达到欣欣向荣，则将公会健康度排名最高的前十个公会中任意一个公会随机确定为第二公会，并将第一公会与该第二公会注册为公会管理器的公会列表中的待合并公会对。在合并警告发出后的3天内，若第一公会所属等级达到欣欣向荣，则取消针对第一公会的自动合并操作。

进而，得到公会列表中的待合并公会对之后，104中，在预设周期内遍历待合并公会列表，并对待合并公会列表中待合并的第一公会和第二公会对进行合并操作，包括：在待合并公会对注册之后的设定时刻，将第一公会的所有玩家从第一公会的成员列表转移至第二公会的成员列表中，并注销第一公会以及第一公会中管理成员的管理成员身份。

本申请实施例中，为提升合并效率，避免公会自动合并操作对玩家的影响，可以设置固定时刻用以执行自动合并操作。比如，每日0点执行自动合并操作。

继续上文示例，假设在待合并公会对注册之后的设定时刻为每日0点。基于此，基于前文步骤得到的待合并公会对，在待合并公会对注册之后的0点，将第一公会的所有玩家从第一公会的成员列表转移至第二公会的成员列表中，并注销第一公会以及第一公会中管理成员(包括一级管理员、二级管理员)的管理成员身份。

需要说明的是，实际应用中，第一公会和第二公会合并之后，公会贡献值等虚拟资源也将从第一公会的账户转移到第二公会的账户中，并分配给对应成员，从而保证公会合并之后公会成员的利益不受影响，提升玩家体验。合并之后，第二公会的成员数量可临时超过规定成员数量上限，但是，若要向第二公会继续添加成员，则需第二公会中的成员数量小于规定成员数量上限。合并之后，公会建筑、公会驻地、公会宣言等数据，则以宿主公会(如前文介绍的第二公会)为准。

可以理解的是，除了上述示例的第一公会和第二公会之外，实际应用中，还可以对三个或者三个以上的公会进行自动合并。具体合并流程相似，此处不再展开。

另一方面，对于各个等级的公会，本申请中还设置有一种手动合并条件，用以满足公会之间的合并需求。

具体来说，在一可选实施例中，104中，根据第一公会所属等级判断第一公会是否符合合并条件，还包括以下步骤：

若第一公会所属等级不是第一等级，则判断第一公会的管理成员是否提出手动合并请求；判断第一公会所属等级是否为符合手动合并条件的第二等级。

继续上文示例，假设符合自动合并条件的第一等级可以是岌岌可危(对应公会健康度的数值为0至9之间)。假设符合手动合并条件的第二等级包括：摇摇欲坠(对应公会健康度的数值为10至29之间)、欣欣向荣(对应公会健康度的数值为30至49之间)、兴旺发达(对应公会健康度的数值为50以上)。基于上述假设，判断第一公会的一级管理者和/或二级管理者(即管理成员)是否提出手动合并请求。以及，判断第一公会所属等级是否为符合手动合并条件的第二等级。

进而，基于上述步骤的判断结果，104中，若第一公会符合合并条件，则将第一公会和第二公会注册到公会管理器的待合并公会列表中，包括：

若第一公会的管理成员提出手动合并请求，并且第一公会所属等级为第二等级，则向第二公会发送合并邀约请求，或者接收第二公会发送的合并邀约请求；在合并邀约请求被接收后的第三预设时长内，若第一公会和第二公会达成合并邀约，则将第一公会和第二公会，注册为公会管理器的公会列表中的待合并公会对。

继续上文示例，假设符合自动合并条件的第一等级可以是岌岌可危(对应公会健康度的数值为0至9之间)。假设符合手动合并条件的第二等级包括：摇摇欲坠(对应公会健康度的数值为10至29之间)、欣欣向荣(对应公会健康度的数值为30至49之间)、兴旺发达(对应公会健康度的数值为50以上)。假设前述步骤中判定第一公会所属等级属于摇摇欲坠。

基于上述假设，第一公会的管理者可以选取手动合并触发控件，从而查看公会合并列表，该列表中展示有符合合并资格的所有公会。这里的合并资格包括但不限于：公会中玩家数量少于玩家数量上限，公会所属门派与第一公会所属门派相同，公会不存在违规行为。

进而，第一公会的管理者可以通过手动合并请求来主动申请并入公会合并列表中的任意一个公会(即第二公会)，例如图2所示的申请界面中可发起合并申请。以图2示出的游戏界面为例，可以选取8个帮派(即公会)中的一个帮派作为申请并入的帮派(即第二公会)。也可以接受由公会合并列表中的任意一个公会(即第二公会)提出的合并邀约请求，例如图3所示的邀请界面中接收其他帮派的邀请，从而触发本帮派(即第一公会)进入手动合并流程。在发出手动合并请求之后，或者接受合并邀约请求之后，将第一公会和上述任意一个公会注册为公会管理器的公会列表中的待合并公会对，并在当日23点执行本次手动合并流程。若第一公会的管理者在23点之后完成待合并公会对的注册，则在次日23点执行本次手动合并流程。

手动合并流程与前文介绍的自动合并流程类似，具体实施可参见上文，此处不再赘述。

实际应用中，除了上述几个等级的公会，处于较低等级的公会(如岌岌可危)也可以主动发起手动公会合并流程，从而，进一步保证公会中的玩家体验。

在本实施例中，获取第一公会的玩家信息，该玩家信息包括第一公会中的玩家行为数据。进而，根据玩家信息确定第一公会的公会健康度。由于公会健康度与玩家行为数据相关，因而，通过公会健康度可以看出第一公会中玩家的表现情况，从而采用玩家表现情况反映第一公会的运营情况。进而，基于第一公会的运营情况考虑是否对第一公会进行相关处理，具体来说，可以检测公会健康度是否达到合并条件，若公会健康度达到合并条件，将第一公会合并到第二公会，以避免第一公会中的玩家因公会运营情况而导致的体验不佳，提高玩家留存率。综合上述步骤，通过公会健康度可以及时发现并回收运营情况不佳的游戏公会，避免玩家因误入此类公会而导致的游戏体验下降，改善玩家体验，提高玩家留存率。并且，通过公会健康度可合并游戏公会，从而有效减少游戏公会数量，降低游戏公会所占用的网络资源，提高网络资源利用率。

相关技术中，游戏公会的创建方式，通常是由玩家自行创建，且创建门槛较低，导致公会数量过多，需要消耗较多的网络资源。公会数量过多还会带来监管压力，影响玩家游戏体验，造成玩家留存率低。

针对上述问题，在上述或下述实施例中，还提供了一种游戏公会创建方式。具体来说，如图4所示，可以采用以下步骤创建游戏公会。

401、响应第一玩家的公会创建请求，建立与第一玩家关联的第一公会，第一公会设置为待响应公会。

402、发布第一公会，以使第二玩家响应发布信息，并加入设置为待响应公会的第一公会。

具体来说，第一玩家发出公会创建请求，并在游戏公会的创建界面中填写意图创建的第一公会的创建信息，比如公会名称、宗旨，支付一定数额的虚拟货币创建该第一公会。以图5所示的创建界面为例，玩家可在该界面输入帮派名称、帮派宗旨。接收到第一玩家发出的公会创建请求以及填入的上述创建信息之后，建立与第一玩家关联的第一公会。该第一公会在公会管理器中注册为待响应公会，并展示给意图加入公会的其他玩家。可选地，可以向第一玩家的好友推送第一公会的推荐信息，以引导好友加入第一公会。或者，也可以在游戏服务器中广播第一公会的招募信息，以便在响应期(如图5所示的24小时)内召集到足够数量的玩家加入第一公会。

403、检测第一公会是否达到预先设置的创建条件，创建条件与第二玩家相关。

在一可选实施例中，创建条件包括但不限于：加入第一公会的第二玩家数量超过设定数量阈值。例如，设定数量阈值可以设置为固定数值，如40个。此外，设定数量阈值也可以设置为数值范围。例如，根据游戏服务器中近一个月的玩家活跃度，动态设置设定数量阈值，如将设定数量阈值设置为全服活跃玩家的百分之一。

基于上述创建条件，403的一种可选实现方式为：响应第二玩家的加入请求，将第二玩家添加至第一公会，并更新第二玩家数量；检测第二玩家数量是否超过设定数量阈值。

例如，假设创建条件包括：加入第一公会的第二玩家数量超过40个(即设定数量阈值)。响应每一个第二玩家对第一公会的加入请求，将第二玩家添加至第一公会，并给第二玩家数量加1，直到检测到第二玩家的数量超过40个。

实际应用中，创建条件还可以包括：申请创建该公会的玩家活跃度达到设定活跃度阈值。例如，申请创建该公会的玩家活跃天数达到设定活跃天数阈值，如本月登录天数超过20天。再例如，申请创建该公会的玩家登录频率达到设定登录频率阈值，如连续三周登录次数超过5次。值得说明的是，创建条件还可以参考其他因素设置，此处并不限制。

404、若第一公会达到创建条件，将第一公会从待响应公会切换至正式公会，以完成第一公会的创建。

在一可选实施例中，404的一种可选实现方式为：若第二玩家数量超过设定数量阈值，则在公会管理器中将第一公会注册为正式公会；将第一公会从待响应公会列表切换至公会列表中。

基于上述示例的假设，若检测到在24小时的响应期内第二玩家的数量超过40个，则在公会管理器中将第一公会从待响应公会注册为正式公会，并将第一玩家设置为第一公会的一级管理者。还会将第一公会从待响应公会列表切换至公会列表中。

在发布第一公会之后的第一预设时长(即响应期)内，若第一公会未达到创建条件，则取消创建第一公会。例如，在24小时的响应期内，若加入到第一公会的第二玩家的数量未超过40个，则取消创建第一公会，退回第一玩家缴纳的创建费用，并向已加入第一公会的第二玩家通知创建失败的消息。

当然，第一玩家在响应期内也可以主动取消第一公会的创建，并向已加入第一公会的第二玩家通知创建失败的消息。

相较于相关技术中的游戏公会的创建方式，本实施例中，通过响应机制创建游戏公会，可以为游戏公会提前积攒人气，并提高游戏公会的创建门槛，避免游戏中出现过多公会的问题，减少游戏公会所占用的网络资源，提高网络资源利用率。

相关技术中，游戏公会主要由创建者自行管理，导致游戏平台难以对公会进行监管，无法调整调配相应的网络资源，影响玩家体验。例如，对于创建者已流失的公会，或恶意创建(如广告推广等)的公会，游戏平台无法将其解散并回收相应的网络资源，既占用了网络资源，又干扰了玩家对公会的选择和体验，甚至使加入此类公会的玩家因公会缺少活力(比如聊天人数较少，活动较少)、或广告过多体验不佳等原因而离开，大大降低玩家的留存率。

针对上述问题，在上述或下述实施例中，还提供了一种游戏公会弹劾机制，用以更换游戏公会的管理者，解决创建者已流失或管理者存在恶意行为(如广告推广行为等)等问题。

本申请实施例中可选地，响应对第一公会发出的弹劾请求，发布弹劾请求，以使第三玩家响应弹劾请求，并确认是否基于弹劾请求更换第一公会中的管理成员。其中，弹劾请求中包括请求更换为新管理成员的玩家的标识，请求更换为新管理成员的玩家属于第一公会。

具体来说，第一公会中，任意一个玩家均可以发起对一级管理者的弹劾请求，弹劾请求中包括意图更换的新一级管理者，新一级管理者可以是发起者也可以是第一公会中的其他玩家。发起弹劾请求需要支付虚拟货币，无论弹劾是否成功均不退回这一费用，以避免弹劾机制的公平性。发起弹劾请求之后，进入弹劾响应期，比如弹劾响应期可以为3小时。在弹劾响应期内，第一公会中的其他玩家(即第三玩家)可响应弹劾请求，并确认是否基于该弹劾请求更换第一公会中的一级管理者。

进而，若确认更换管理成员的第三玩家数量达到弹劾人数阈值，则将第一公会中的管理成员更换为弹劾请求中的新管理成员。

具体来说，弹劾人数阈值可以根据第一公会的规模设置，比如，设置为第一公会中玩家总数的三分之二，或者，设置为第一公会中玩家总数的二分之一。举例来说，假设弹劾人数阈值设置为第一公会中玩家总数的三分之二。假设玩家总数为45人。此时，第一公会中，若确认更换管理成员的第三玩家数量达到45人，则将第一公会中的一级管理者更换为弹劾请求中的新一级管理者。弹劾期间，可以由弹劾发起者主动取消弹劾，也可以在弹劾发起者离开第一公会之后自动取消弹劾。

值得说明的是，弹劾期间无法执行与公会管理相关的业务，比如，无法请离第一公会中的任何玩家，拆除第一公会的公会建筑，等等。

本实施例中，通过上述步骤构建出游戏公会弹劾机制，从而，通过主动弹劾来更换游戏公会的管理者，解决创建者已流失或管理者存在恶意行为(如广告推广行为等)等问题，提升玩家游戏体验，提高玩家留存率。

在上述或下述实施例中，还提供了一种游戏公会自荐机制，也可用以更换游戏公会的管理者，解决创建者已流失或管理者存在恶意行为(如广告推广行为等)等问题，提升玩家游戏体验，提高玩家留存率。

本申请实施例中可选地，响应对第一公会发出的自荐请求，发布自荐请求，以使第四玩家响应自荐请求，并确认是否基于自荐请求将自荐发起者更换为第一公会中的管理成员。其中，自荐请求中包括请求更换为新管理成员的玩家的标识，请求更换为新管理成员的玩家属于第一公会。

具体来说，第一公会中，任意一个玩家均可以发起对一级管理者职位的自荐请求。以图6所示的自荐界面为例，玩家可在该自荐界面输入自荐请求。发起自荐请求需要支付虚拟货币，无论自荐是否成功均不退回这一费用，以避免自荐机制的公平性。发起自荐请求之后，进入自荐考察期，比如自荐考察期可以为72小时。在自荐考察期内，第一公会中的二级管理者(即第四玩家)可响应自荐请求，并确认是否基于该自荐请求更换第一公会中的一级管理者。

进而，若所有第四玩家(比如第一公会中的二级管理者)均确认更换管理成员，则将第一公会中的管理成员更换为自荐请求中的新管理成员。自荐成功后，原一级管理者降级为第一公会的普通成员。若存在至少一个第四玩家反对更换管理成员，则自荐失败。自荐期间，可以由自荐发起者主动取消自荐，也可以在自荐发起者离开第一公会之后自动取消自荐。

值得说明的是，自荐期间无法执行与公会管理相关的业务，比如，无法请离第一公会中的任何玩家，拆除第一公会的公会建筑，等等。

本实施例中，通过上述步骤构建出游戏公会自荐机制，从而，通过主动自荐也可更换游戏公会的管理者，解决创建者已流失或管理者存在恶意行为(如广告推广行为等)等问题，提升玩家游戏体验，提高玩家留存率。

需要说明的是，上述实施例所提供方法的各步骤的执行主体均可以是同一设备，或者，该方法也由不同设备作为执行主体。

另外，在上述实施例及附图中的描述的一些流程中，包含了按照特定顺序出现的多个操作，但是应该清楚了解，这些操作可以不按照其在本文中出现的顺序来执行或并行执行，操作的序号如101、102等，仅仅是用于区分开各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的消息、设备、模块等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。

图7是本申请一示例性实施例提供的电子设备的结构示意图，如图7所示，该电子设备包括：存储器701、处理器702、通信组件703以及显示组件704。

存储器701，用于存储计算机程序，并可被配置为存储其它各种数据以支持在电子设备上的操作。这些数据的示例包括用于在电子设备上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。

其中，存储器701可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

处理器702，与存储器701耦合，用于执行存储器701中的计算机程序，以用于：获取第一公会的玩家信息，玩家信息包括第一公会中的玩家行为数据；根据玩家信息确定第一公会的公会健康度，公会健康度用于表示第一公会的运营情况，公会健康度与玩家行为数据相关；检测公会健康度是否达到合并条件；若公会健康度达到合并条件，将第一公会合并到第二公会。

进一步可选地，处理器702还用于：响应第一玩家的公会创建请求，建立与第一玩家关联的第一公会，第一公会设置为待响应公会；发布第一公会，以使第二玩家响应发布信息，并加入设置为待响应公会的第一公会；检测第一公会是否达到预先设置的创建条件，创建条件与第二玩家相关；若第一公会达到创建条件，将第一公会从待响应公会切换至正式公会，以完成第一公会的创建。

其中，进一步可选地，创建条件包括加入第一公会的第二玩家数量超过设定数量阈值。

处理器702检测第一公会是否达到预先设置的创建条件时，具体用于：响应第二玩家的加入请求，将第二玩家添加至第一公会，并更新第二玩家数量；检测第二玩家数量是否超过设定数量阈值。

处理器702若第一公会达到创建条件，将第一公会从待响应公会切换至正式公会时，具体用于：若第二玩家数量超过设定数量阈值，则在公会管理器中将第一公会注册为正式公会；将第一公会从待响应公会列表切换至公会列表中。

进一步可选地，处理器702还用于：在发布第一公会之后的第一预设时长内，若第一公会未达到创建条件，则取消创建第一公会。

进一步可选地，处理器702根据玩家信息确定第一公会的公会健康度时，具体用于：

从玩家行为数据中获取预设时段内的任务执行情况，其中，任务执行情况包括以下至少一种信息：玩家执行玩法任务的次数、在玩法任务中达成的目标数量、玩家经验值；根据任务执行情况计算得到公会健康度。

其中，进一步可选地，预设时段为设定天数，玩家经验值包括战令经验值。

处理器702根据任务执行情况计算得到公会健康度时，具体用于：

将设定天数内第一公会中所有玩家的战令经验值相加，并以所有玩家的战令经验值之和作为成员活跃指数；将成员活跃指数与第一公会的公会规模参数输入预设算法模型中，得到公会健康度；其中，公会规模参数由第一公会中的玩家数量决定。

进一步可选地，处理器702检测公会健康度是否达到合并条件时，具体用于：基于公会健康度确定第一公会所属等级；根据第一公会所属等级判断第一公会是否符合合并条件。

处理器702若公会健康度达到合并条件，将第一公会合并到第二公会时，具体用于：

若第一公会符合合并条件，则将第一公会和第二公会注册到公会管理器的待合并公会列表中；在预设周期内遍历待合并公会列表，并对待合并公会列表中待合并的第一公会和第二公会对进行合并操作，以使加入第一公会的所有玩家转移到第二公会。

其中，进一步可选地，处理器702根据第一公会所属等级判断第一公会是否符合合并条件时，具体用于：判断第一公会所属等级是否为符合自动合并条件的第一等级。

处理器702若第一公会符合合并条件，则将第一公会和第二公会注册到公会管理器的待合并公会列表中时，具体用于：

若第一公会所属等级为第一等级，则向第一公会发布合并警告；在合并警告发出后的第二预设时长内，若第一公会的公会健康度未达到独立存续条件，则将第一公会与公会健康度排在第二预设位次的第二公会，注册为公会管理器的公会列表中的待合并公会对；其中，独立存续条件包括第二预设时长内第一公会的公会健康度排在第一预设位次。

处理器702在预设周期内遍历待合并公会列表，并对待合并公会列表中待合并的第一公会和第二公会对进行合并操作时，具体用于：在待合并公会对注册之后的设定时刻，将第一公会的所有玩家从第一公会的成员列表转移至第二公会的成员列表中，并注销第一公会以及第一公会中管理成员的管理成员身份。

其中，进一步可选地，处理器702根据第一公会所属等级判断第一公会是否符合合并条件时，还用于：若第一公会所属等级不是第一等级，则判断第一公会的管理成员是否提出手动合并请求；判断第一公会所属等级是否为符合手动合并条件的第二等级。

处理器702若第一公会符合合并条件，则将第一公会和第二公会注册到公会管理器的待合并公会列表中时，具体用于：

若第一公会的管理成员提出手动合并请求，并且第一公会所属等级为第二等级，则向第二公会发送合并邀约请求，或者接收第二公会发送的合并邀约请求；在合并邀约请求被接收后的第三预设时长内，若第一公会和第二公会达成合并邀约，则将第一公会和第二公会注册为公会管理器的公会列表中的待合并公会对。

进一步可选地，处理器702还用于：响应对第一公会发出的弹劾请求，发布弹劾请求，以使第三玩家响应弹劾请求，并确认是否基于弹劾请求更换第一公会中的管理成员；其中，弹劾请求中包括请求更换为新管理成员的玩家的标识，请求更换为新管理成员的玩家属于第一公会；若确认更换管理成员的第三玩家数量达到弹劾人数阈值，则将第一公会中的管理成员更换为弹劾请求中的新管理成员。

进一步，如图7所示，该电子设备还包括：电源组件705、音频组件706等其它组件。图7中仅示意性给出部分组件，并不意味着电子设备只包括图7所示组件。

其中，通信组件703被配置为便于通信组件所在设备和其他设备之间有线或无线方式的通信。通信组件所在设备可以接入基于通信标准的无线网络，如WiFi，2G、3G、4G或5G，或它们的组合。在一个示例性实施例中，通信组件经由广播信道接收来自外部广播管理***的广播信号或广播相关信息。在一个示例性实施例中，通信组件可基于近场通信(NFC)技术、射频识别(RFID)技术、红外数据协会(IrDA)技术、超宽带(UWB)技术、蓝牙(BT)技术和其他技术来实现。

其中，显示组件704可以实现为显示器，该显示器包括屏幕，其屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。未屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。

其中，电源组件705，为电源组件所在设备的各种组件提供电力。电源组件可以包括电源管理***，一个或多个电源，及其他与为电源组件所在设备生成、管理和分配电力相关联的组件。

本实施例中，通过公会健康度可以及时发现并回收运营情况不佳的游戏公会，避免玩家因误入此类公会而导致的游戏体验下降，改善玩家体验，提高玩家留存率。并且，通过公会健康度可合并游戏公会，从而有效减少游戏公会数量，降低游戏公会所占用的网络资源，提高网络资源利用率。

相应地，本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，计算机程序被执行时能够实现上述方法实施例中可由电子设备执行的各步骤。

本领域内的技术人员应明白，本申请的实施例可提供为方法、***、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(***)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载批。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (10)

1.一种游戏公会合并方法，其特征在于，所述方法包括：

获取第一公会的玩家信息，所述玩家信息包括所述第一公会中的玩家行为数据；

根据所述玩家信息确定所述第一公会的公会健康度，所述公会健康度用于表示第一公会的运营情况，所述公会健康度与所述玩家行为数据相关；

检测所述公会健康度是否达到合并条件；

若所述公会健康度达到所述合并条件，将所述第一公会合并到第二公会。

2.根据权利要求1所述的方法，其特征在于，还包括：

响应第一玩家的公会创建请求，建立与所述第一玩家关联的所述第一公会，所述第一公会设置为待响应公会；

发布所述第一公会，以使第二玩家响应发布信息，并加入设置为所述待响应公会的所述第一公会；

检测所述第一公会是否达到预先设置的创建条件，所述创建条件与所述第二玩家相关；

若所述第一公会达到所述创建条件，将所述第一公会从所述待响应公会切换至正式公会，以完成所述第一公会的创建。

3.根据权利要求2所述的方法，其特征在于，所述创建条件包括加入所述第一公会的第二玩家数量超过设定数量阈值；

所述检测所述第一公会是否达到预先设置的创建条件，包括：

响应所述第二玩家的加入请求，将所述第二玩家添加至所述第一公会，并更新所述第二玩家数量；

检测所述第二玩家数量是否超过所述设定数量阈值；

所述若所述第一公会达到所述创建条件，将所述第一公会从所述待响应公会切换至正式公会，包括：

若所述第二玩家数量超过所述设定数量阈值，则在公会管理器中将所述第一公会注册为正式公会；

将所述第一公会从待响应公会列表切换至公会列表中。

4.根据权利要求2或3所述的方法，其特征在于，还包括：

在发布所述第一公会之后的第一预设时长内，若所述第一公会未达到所述创建条件，则取消创建所述第一公会。

5.根据权利要求1所述的方法，其特征在于，所述根据所述玩家信息确定所述第一公会的公会健康度，包括：

从所述玩家行为数据中获取预设时段内的任务执行情况，其中，所述任务执行情况包括以下至少一种信息：玩家执行玩法任务的次数、在所述玩法任务中达成的目标数量、玩家经验值；

根据所述任务执行情况计算得到所述公会健康度。

6.根据权利要求5所述的方法，其特征在于，预设时段为设定天数，所述玩家经验值包括战令经验值；

所述根据所述任务执行情况计算得到所述公会健康度，包括：

将设定天数内所述第一公会中所有玩家的战令经验值相加，并以所有玩家的战令经验值之和作为成员活跃指数；

将所述成员活跃指数与所述第一公会的公会规模参数输入预设算法模型中，得到所述公会健康度；其中，所述公会规模参数由所述第一公会中的玩家数量决定。

7.根据权利要求1所述的方法，其特征在于，所述检测所述公会健康度是否达到合并条件，包括：

基于所述公会健康度确定所述第一公会所属等级；

根据所述第一公会所属等级判断所述第一公会是否符合所述合并条件；

所述若所述公会健康度达到所述合并条件，将所述第一公会合并到第二公会，包括：

若所述第一公会符合所述合并条件，则将所述第一公会和所述第二公会注册到公会管理器的待合并公会列表中；

在预设周期内遍历所述待合并公会列表，并对所述待合并公会列表中待合并的所述第一公会和所述第二公会对进行合并操作，以使加入所述第一公会的所有玩家转移到所述第二公会。

8.根据权利要求7所述的方法，其特征在于，所述根据所述第一公会所属等级判断所述第一公会是否符合所述合并条件，包括：

判断所述第一公会所属等级是否为符合自动合并条件的第一等级；

所述若所述第一公会符合所述合并条件，则将所述第一公会和所述第二公会注册到公会管理器的待合并公会列表中，包括：

若所述第一公会所属等级为所述第一等级，则向所述第一公会发布合并警告；

在所述合并警告发出后的第二预设时长内，若所述第一公会的公会健康度未达到独立存续条件，则

将所述第一公会与公会健康度排在第二预设位次的第二公会，注册为公会管理器的公会列表中的待合并公会对；其中，所述独立存续条件包括所述第二预设时长内所述第一公会的公会健康度排在第一预设位次；

所述在预设周期内遍历所述待合并公会列表，并对所述待合并公会列表中待合并的所述第一公会和所述第二公会对进行合并操作，包括：

在所述待合并公会对注册之后的设定时刻，将所述第一公会的所有玩家从所述第一公会的成员列表转移至所述第二公会的成员列表中，并注销所述第一公会以及所述第一公会中管理成员的管理成员身份。

9.根据权利要求8所述的方法，其特征在于，所述根据所述第一公会所属等级判断所述第一公会是否符合所述合并条件，还包括：

若所述第一公会所属等级不是所述第一等级，则判断所述第一公会的管理成员是否提出手动合并请求；

判断所述第一公会所属等级是否为符合手动合并条件的第二等级；

所述若所述第一公会符合所述合并条件，则将所述第一公会和所述第二公会注册到公会管理器的待合并公会列表中，包括：

若所述第一公会的管理成员提出所述手动合并请求，并且所述第一公会所属等级为所述第二等级，则向所述第二公会发送合并邀约请求，或者接收所述第二公会发送的合并邀约请求；

在合并邀约请求被接收后的第三预设时长内，若所述第一公会和所述第二公会达成合并邀约，则

将所述第一公会和所述第二公会，注册为公会管理器的公会列表中的待合并公会对。

10.一种电子设备，其特征在于，包括：存储器和处理器；

所述存储器用于存储一条或多条计算机指令；

所述处理器用于执行所述一条或多条计算机指令以用于：执行权利要求1-9任一项所述的方法中的步骤。