CN117320793A

CN117320793A - 游戏管理装置、游戏管理方法和程序

Info

Publication number: CN117320793A
Application number: CN202280035543.XA
Authority: CN
Inventors: 仓林修一
Original assignee: Cygames Inc
Current assignee: Cygames Inc
Priority date: 2021-03-17
Filing date: 2022-03-04
Publication date: 2023-12-29
Also published as: JP7129513B1; WO2022196390A1; US20240033645A1; JP2022143284A

Abstract

本发明提供一种游戏管理装置(10)，包括：存储单元(11)，用于存储由一个或多于一个成员构成的多个群组的列表；合并对象搜索单元(15)，用于从成员数量未达到游戏中预先设置的上限且处于能够添加成员的状态的群组中，搜索满足合并条件且能够相互合并的两个或多于两个群组；建议单元(16)，用于向能够相互合并的两个或多于两个群组呈现合并的建议，并且接受对所述建议的回复；以及合并单元(17)，用于在从能够相互合并的两个或多于两个群组接收到意思是接受所述建议的回复的情况下，将能够相互合并的两个或多于两个群组合并以生成单个群组。

Description

游戏管理装置、游戏管理方法和程序

技术领域

本发明涉及游戏管理装置、游戏管理方法和程序。

背景技术

随着在线游戏变得普遍，大量玩家参与的游戏类型(以下称为“多人游戏”)越来越受欢迎。示例多人游戏是大量玩家参与的大乱斗游戏。大乱斗游戏提供20对20或50对50的团队战斗、或者100个个体玩家为生存而彼此战斗的模式等(参见非专利文献1)。

现有技术文献

非专利文献

非专利文献1：“さぁ今からはじめよう！いちからわかる『フォートナイトバトル』の遊び方。”、[online]、2018年8月10日、任天堂、[20 2 1年2月5日検索]、インターネット<URL:https://topics.nintendo.co.jp/article/f5e9088e-95fb-11e8-b123-063b7ac45a6d>

发明内容

发明要解决的问题

存在创建用于参与多人游戏的群组(用户集合)的各种方法。示例包括以诸如“公会”、“氏族”、“团体”或“小队”等的名称预先形成群组的静态方法、以及针对每个游戏创建称为“房间”的临时群组的动态方法。此外，用于邀请用户参与这样的房间的机制包括预先形成各种用户之间的连接的方法、在列表中呈现一起玩战斗的用户的方法、以及随机地邀请其他用户的方法。

为了在游戏中带来变化并且为了不论时间段和时间如何都稳定地聚集用户，优选针对每个游戏创建临时群组的方法。然而，通过该手段，存在聚集期望数量的成员需要很长时间的情况，这可能给用户带来压力。

本发明解决提供用于在针对每个游戏创建临时群组的方法中缩短直至聚集期望数量的成员为止的时间的手段的问题。

用于解决问题的方案

本发明提供一种游戏管理装置，包括：

存储单元，用于存储由一个或多于一个成员构成的多个群组的列表；

合并对象搜索单元，用于从成员数量未达到游戏中预先设置的上限且处于能够添加成员的状态的群组中，搜索满足合并条件且能够相互合并的两个或多于两个群组；

建议单元，用于向能够相互合并的两个或多于两个群组呈现合并的建议，并且接受对所述建议的回复；以及

合并单元，用于在从能够相互合并的两个或多于两个群组接收到意思是接受所述建议的回复的情况下，将能够相互合并的两个或多于两个群组合并以生成单个群组。

此外，本发明提供一种游戏管理方法，其中，计算机进行以下操作：

存储由一个或多于一个成员构成的多个群组的列表；

从成员数量未达到游戏中预先设置的上限且处于能够添加成员的状态的群组中，搜索满足合并条件且能够相互合并的两个或多于两个群组；

向能够相互合并的两个或多于两个群组呈现合并的建议，并且接受对所述建议的回复；以及

在从能够相互合并的两个或多于两个群组接收到意思是接受所述建议的回复的情况下，将能够相互合并的两个或多于两个群组合并以生成单个群组。

此外，本发明提供一种程序，用于使得计算机用作：

存储部件，用于存储由一个或多于一个成员构成的多个群组的列表；

合并对象搜索部件，用于从成员数量未达到游戏中预先设置的上限且处于能够添加成员的状态的群组中，搜索满足合并条件且能够相互合并的两个或多于两个群组；

建议部件，用于向能够相互合并的两个或多于两个群组呈现合并的建议，并且接受对所述建议的回复；以及

合并部件，用于在从能够相互合并的两个或多于两个群组接收到意思是接受所述建议的回复的情况下，将能够相互合并的两个或多于两个群组合并以生成单个群组。

发明的效果

本发明实现了用于在针对每个游戏创建临时群组的方法中缩短直至聚集期望数量的成员为止的时间的手段。

附图说明

图1是用于说明根据本实施例的游戏管理装置的特征的图。

图2是示出根据本实施例的游戏管理装置的示例硬件结构的图。

图3是根据本实施例的游戏管理装置的示例功能框图。

图4是示意性示出由根据本实施例的游戏管理装置处理的信息的示例的图。

图5是示意性示出由根据本实施例的游戏管理装置处理的信息的示例的图。

图6是示意性示出由根据本实施例的游戏管理装置处理的信息的示例的图。

图7是示出利用根据本实施例的游戏管理装置的处理的示例流程的序列图。

图8是由根据本实施例的游戏管理装置实现的示例显示画面。

图9是由根据本实施例的游戏管理装置实现的示例显示画面。

图10是示出利用根据本实施例的游戏管理装置的处理的示例流程的序列图。

图11是由根据本实施例的游戏管理装置实现的示例显示画面。

图12是由根据本实施例的游戏管理装置实现的示例显示画面。

图13是根据该示例的示例系统结构图。

具体实施方式

<第一实施例>

“概述”

根据本实施例的游戏管理装置通过使用针对每个游戏创建临时群组的方法来创建用于参与游戏的群组。游戏管理装置通过除了使用“以个体为单位参与群组”的方法之外还使用“相互合并群组”的方法来创建群组。

现在，将参考图1通过与现有技术比较来说明本实施例的技术特征。

该图中的“动态群组”是针对每个游戏临时创建的群组。每次聚集可以玩的用户以创建临时群组。一般地，临时群组在游戏结束时解散。

该图所示的“静态群组”是不论游戏的执行定时如何都预先创建的群组。例如，静态群组是从家庭成员、共同朋友或共同熟人等创建的。此外，这样的静态群组用作用于参与游戏的单元以及用于与其他静态群组合并的单元。注意，静态群组在游戏结束时不解散，并且一般地，静态群组例如响应于来自用户的指令的输入而解散。

本实施例的技术是用于用户以用户为单位加入动态群组技术和动态群组相互合并技术(图中均未示出)的组合。

迄今为止已知有用于用户以用户为单位加入静态群组技术、用于静态群组相互合并技术、以及用于用户以用户为单位加入动态群组技术。然而，尚不存在用于相互合并动态群组的技术。因而，尚不存在将用于用户以用户为单位加入动态群组技术和用于相互合并动态群组技术组合的技术。

“硬件结构”

接着，将说明游戏管理装置的硬件结构。根据本实施例的游戏管理装置中所提供的各个功能单元通过硬件和软件的任意组合来实现，该硬件和软件主要包括任意计算机的中央处理单元(CPU)、其存储器、该存储器中所加载的程序、存储该程序的存储单元(诸如硬盘(其可以存储在装置的出货之前已存储的程序、以及诸如致密盘(CD)等的存储介质中所存储的或从因特网上的服务器等下载的程序)等)、以及网络连接接口。此外，本领域技术人员将理解，存在用于实现功能单元的方法和装置的各种变形例。

图2是示出游戏管理装置的示例硬件结构的框图。如图2所示，游戏管理装置包括处理器1A、存储器2A、输入/输出接口3A、周边电路4A和总线5A。周边电路4A包括各种模块。注意，各个装置不需要包括周边电路4A。

注意，游戏管理装置可以由多个物理上和/或逻辑上分离的装置构成。在这种情况下，各个装置可以包括上述的硬件结构。可替代地，游戏管理装置可以由物理上和逻辑上的单个装置构成。

总线5A是处理器1A、存储器2A、周边电路4A和输入/输出接口3A相对于彼此发送和接收数据所用的数据传输路径。处理器1A是诸如CPU或图形处理单元(GPU)等的计算处理装置。存储器2A是诸如随机存取存储器(RAM)或只读存储器(ROM)等的存储器。输入/输出接口3A包括：用于从输入装置、外部装置、外部服务器、外部传感器等获得信息的接口；用于向输出装置、外部装置、外部服务器等输出信息的接口；等等。示例输入装置包括键盘、鼠标和麦克风。示例输出装置包括显示器、扬声器、打印机和邮件程序。处理器1A可以向各个模块发出指令，并且可以基于各个模块的计算结果来进行计算。

“功能结构”

接着，将说明游戏管理装置的功能结构。图3示出游戏管理装置10的示例功能框图。如该图所示，游戏管理装置10包括存储单元11、群组添加单元12、群组搜索单元13、成员添加单元14、合并对象搜索单元15、建议单元16和合并单元17。

这些功能单元实现以下种类的处理(其各自将在下文进行说明)。

·数据管理

·用于新创建动态群组的处理

·用于以用户为单位加入动态群组的处理

·用于相互合并动态群组的处理

-数据管理-

数据管理由存储单元11实现。存储单元11存储由一个或多于一个成员构成的多个群组的列表(以下称为“群组列表”)。在群组列表中，登记了在当前时间存在的群组。也就是说，在创建群组时将群组登记在群组列表中，并且在群组解散(游戏结束)时将群组从群组列表删除。

图4示意性示出示例群组列表。在所示的示例中，“群组标识信息”、“成员数量”、“群组属性信息”和“成员”彼此关联。注意，在群组列表中还可以登记其他信息。

“群组标识信息”是用于将多个群组彼此区分开的信息。例如，游戏管理装置10根据预定义的规则来向各群组发出群组标识信息。

“成员数量”指示在当前定时属于各群组的成员的数量。注意，成员数量可以是群组属性信息的一部分。

“群组属性信息”是各群组的属性信息。群组属性信息包括从游戏系统可以获得的信息的集合，诸如各个成员所使用的玩家角色的种类、玩家等级、由游戏系统根据玩家的熟练度所计算出的排名或战力值、以及各个成员共同拥有的物品。此外，群组属性信息可以包括由成员确定的群组名称、群组的平均等级(例如，自称等级或构成成员的等级的平均值)、成员之间的通信所使用的语言等。[0]

“成员”是指示在当前时间属于各群组的成员的信息。在该图所示的示例的情况下，在该栏中记载用户标识信息。

注意，存储单元11除了可以存储上述的群组列表之外，还可以存储诸如图5所示的用户列表等的用户列表。在用户列表中，登记了已登记为用户且可以参与游戏的用户。在所示的示例中，“用户标识信息”和“用户属性信息”彼此关联。注意，在用户列表中还可以登记其他信息。

“用户标识信息”是用于将多个用户彼此区分开的信息。例如，游戏管理装置10根据预定义的规则向各用户发出群组标识信息。

“用户属性信息”是可以与群组属性信息进行对照的用户数据，并且与群组属性信息在类型上兼容。用户属性信息是从游戏系统可以获得的信息的集合，诸如所使用的玩家角色的种类、玩家等级、由游戏系统根据玩家的熟练度所计算出的排名或战力值、以及所拥有的物品。

-用于新创建动态群组的处理-

用于新创建动态群组的处理由图3中的群组添加单元12实现。群组添加单元12基于用户操作来创建新群组，并且将新创建的群组登记在群组列表中。

各用户经由具有通信功能的用户终端(诸如智能电话、平板电脑、个人计算机、游戏机、智能手表或移动电话等)进行规定的用户操作。用户终端与游戏管理装置10执行通信，以与游戏管理装置10协作地向用户提供规定的游戏功能。

例如，希望在扮演中心角色的同时创建群组的用户经由用户终端进行用于新创建群组的操作。响应于该操作，群组添加单元12将该群组新添加到群组列表。

例如，群组添加单元12向群组发出新群组标识信息，并且将该群组标识信息添加到群组列表(参见图4)。此外，群组添加单元12在群组列表中的成员数量的栏中登记“1”。然后，群组添加单元12将用户的用户标识信息登记在成员栏的首领栏中。

此外，可以允许新创建了群组的用户确定并登记用于加入该群组的群组加入条件。群组加入条件被存储在存储单元11中。

图6示意性示出群组加入条件的示例。群组加入条件与群组属性信息在类型上兼容。也就是说，通过使用例如所使用的玩家角色的种类、玩家等级、由游戏系统根据玩家的熟练度所计算出的等级或战力值、所拥有的物品等来定义群组加入条件。还可以通过使用所使用的语言、存在地区、过去参与游戏次数、性别、年龄层、所使用的终端的种类等来定义群组加入条件。注意，群组加入条件的内容以及在定义群组加入条件时要使用的项目不限于上述这些。

此外，如何处理群组加入条件的方式可能有所不同，而不受任何特定限制。例如，配置可以是这样的：不满足针对各群组所设置的群组加入条件的用户永远不被允许加入该群组。在这种情况下，例如，游戏被配置成使得不允许不满足群组加入条件的用户申请加入相应的群组。游戏管理装置10配备有用于检查各用户是否满足各群组的群组加入条件的功能，即，用于将群组加入条件与用户属性信息进行对照以判断是否许可用户加入群组的功能。

可替代地，配置可以是这样的：群组加入条件是用作在各用户搜索要加入的群组时的基准的信息，从而允许甚至不满足群组加入条件的用户加入群组。在这种情况下，例如，游戏被配置成使得即使不满足群组加入条件的用户也被允许申请加入相应的群组，从而根据群组的首领的决定而允许该用户加入群组。

-用于以用户为单位加入动态群组的处理-

用于以用户为单位加入动态群组的处理由图3中的群组搜索单元13和成员添加单元14实现。群组搜索单元13从群组列表(参见图4)中所登记的、成员数量未达到游戏中预设的上限、且处于可以添加成员的状态的群组(以下称为“招募群组”)中，搜索规定群组。群组搜索单元13的该功能被提供给搜索要加入的群组的用户。例如，群组搜索单元13参考群组列表中所登记的群组属性信息来从群组列表中所登记的招募群组中搜索与搜索条件匹配的群组。

搜索条件可以由各用户创建。例如，希望搜索要加入的群组的用户经由用户终端进行群组搜索操作。在该操作中，用户创建搜索条件，并且输入用于搜索满足所创建的搜索条件的群组的指令。响应于所输入的指令，群组搜索单元13搜索满足搜索条件的群组。示例搜索条件是“平均等级：3级以上，并且所使用的语言：日语”。可替代地，可以允许通过使用群组名称作为搜索条件(诸如群组名称：CYCYGA等)来搜索期望的群组。

可替代地，搜索条件可以由群组搜索单元13基于各用户的用户属性信息来自动创建。例如，希望搜索要加入的群组的用户输入用于搜索群组的指令。响应于所输入的指令，群组搜索单元13基于用户的用户属性信息创建搜索条件，并且搜索满足所创建的搜索条件的群组。用于基于用户属性信息来创建搜索条件的处理的详情可能有所不同，而不受任何特定限制。

各群组中的成员数量的上限是在游戏中预定义的。不允许包括超过该上限的成员。注意，成员数量达到该上限可以是用于开始游戏的条件；然而，该特征不一定是必需的。

仅对于开始游戏之前的群组才可以允许新成员加入群组，或者除了对于开始游戏之前的群组之外还对于游戏期间的群组，可以允许新成员加入群组。在前者情况下，仅开始游戏之前的群组可以成为招募群组。另一方面，在后者情况下，开始游戏之前的群组以及游戏期间的群组可以成为招募群组。

群组搜索单元13将搜索结果发送到用户终端。然后，用户终端显示搜索结果。

成员添加单元14向群组列表(参见图4)中所登记的群组添加并登记新成员。

例如，经由由群组搜索单元13提供的功能进行了群组搜索的用户进行用于从用户终端上所显示的群组搜索单元13的搜索结果中选择要加入的群组的操作。

成员添加单元14可以响应于该选择操作而将用户的用户标识信息作为所选择的群组的成员登记到群组列表中。

可替代地，成员添加单元14可以响应于该选择操作而向群组的首领询问是否许可用户的加入。然后，成员添加单元14可以响应于从群组的首领接收到许可加入的回复，将用户的用户标识信息作为所选择的群组的成员登记到群组列表中。该查询以及回复的接收经由包括游戏App内的功能以及电子邮件地址的发送等的各种众所周知的技术来实现。

-用于相互合并动态群组的处理-

用于相互合并动态群组的处理由图3中的合并对象搜索单元15、建议单元16和合并单元17来实现。

合并对象搜索单元15从成员数量未达到游戏中预设的上限且处于可以添加成员的状态的群组(招募群组)中选择满足合并条件且可以相互合并的两个或多于两个群组。

建议单元16向通过合并对象搜索单元15的搜索所找到的可以相互合并的两个或多于两个群组建议合并，并且接受对该建议的回复。该建议以及回复的接收经由包括游戏App内的功能以及电子邮件地址的发送等的各种众所周知的技术来实现。

在从可以相互合并的两个或多于两个群组接收到意思是接受建议的回复的情况下，合并单元17将可以相互合并的两个或多于两个群组合并以创建单个群组。

以下将参考图7中的序列图来进一步详细说明该处理的示例流程。

首先，作为招募群组的第一群组的首领经由用户终端输入用于搜索可以合并的群组的指令(S101)。响应于所输入的指令，游戏管理装置10的合并对象搜索单元15搜索可以与第一群组合并的群组(S102)。

合并条件包括“(第一条件)属于相互群组的成员的总数不大于上限”。利用该条件，可以抑制合并之后的成员数量超过游戏中所设置的上限的问题。

此外，可以通过经由与(AND)条件将上述的“第一条件”与“通过使用群组加入条件以及在当前定时属于群组的成员的属性中的至少一个所定义的第二条件”联合来准备合并条件。

第二条件的示例包括经由逻辑运算符联合的以下条件中的至少一个或多于一个：

“相互群组加入条件之间的类似度大于或等于基准值”；

“基于在当前定时属于群组的成员的用户属性所计算出的相互群组属性之间的类似度大于或等于基准值”；

“基于在当前定时属于群组的成员的用户属性所计算出的相互群组属性之间的差异度大于或等于基准值”；

“基于在当前定时属于一方的群组的成员的用户属性所计算出的该群组的群组属性满足另一方的群组的群组加入条件”；

“在相互群组加入条件中指定的所使用的语言一致”；

“在相互群组加入条件中指定的存在地区一致”；以及

“在相互群组加入条件中指定的所使用的终端的类型一致”。

第二条件可以是预先定义的，或者可以由成员(例如，首领)针对每个群组来指定。

没有限制计算相互群组加入条件之间的类似度的方法，并且可以采用各种方法。此外，作为基于在当前定时属于群组的成员的用户属性来计算群组属性的方法，例如，可以采用使用成员的等级、参与游戏次数或年龄层等的统计值(平均值、众数、最大值、最小值或中值等)作为群组属性的方法。此外，没有特别限制计算相互群组属性之间的类似度的方法，并且可以采用各种方法。

利用以上给出的第二条件的示例中的条件“基于在当前定时属于群组的成员的用户属性所计算出的相互群组属性之间的类似度大于或等于基准值”，可以选择相互类似的群组作为合并对象。这使得可以创建类似成员所属的群组。另一方面，利用条件“基于在当前定时属于群组的成员的用户属性所计算出的相互群组属性之间的差异度大于或等于基准值”，可以选择相互不类似的群组作为合并对象。这使得可以创建具有各种属性的成员所属的群组。

在S102之后，游戏管理装置10的建议单元16将S102中的搜索结果以及在该搜索结果中指示的用于与“可以与第一群组合并的群组”合并的建议发送到第一群组的首领的用户终端(S103)。然后，第一群组的首领的用户终端显示这些信息(S104)。

例如，在第一群组的首领的用户终端上显示诸如图8所示的画面等的画面。该画面显示满足与第一群组的合并条件且可以与第一群组合并的一个或多于一个群组的列表。此外，该画面显示群组名称、平均等级、在当前定时的成员数量、在群组加入条件中指定的所使用的语言、用于浏览其他详细信息的链接等，作为与各群组有关的信息。注意，示例画面仅仅是示例，并且可以显示与各群组有关的其他信息。

然后，第一群组的首领的用户终端接受对上述建议的回复的输入(S105)。然后，第一群组的首领的用户终端将所接受的回复发送到游戏管理装置10(S106)。在第一群组的首领希望与列表中所显示的群组其中之一合并的情况下，第一群组的首领选择该群组，并且进行与该群组合并的提议的输入。另一方面，在第一群组的首领不希望与列表中所显示的群组中的任一个合并的情况下，第一群组的首领输入该意思。

注意，图7的S107中及其之后的处理是在S105中第一群组的首领进行了与列表中所显示的群组其中之一合并的提议的输入的情况下的处理。在S105中第一群组的首领进行了意思是不希望与列表中所显示的群组中的任一个合并的输入的情况下，不执行S107中及其之后的处理，并且由S101触发的合并处理结束。

在S107中，游戏管理装置10的建议单元16将用于与第一群组合并的建议发送到由第一群组的首领选择作为合并对象的第二群组的首领的用户终端(S107)。然后，第二群组的首领的用户终端显示这些信息(S108)。

例如，在第二群组的首领的用户终端上显示诸如图9所示的画面等的画面。该画面显示与向第二群组提议了合并的群组(第一群组)有关的信息。此外，该画面显示群组名称、平均等级、在当前定时的成员数量、在群组加入条件中指定的所使用的语言、用于浏览其他详细信息的链接等，作为与该群组有关的信息。注意，示例画面仅仅是示例，并且可以显示与该群组有关的其他信息。

然后，第二群组的首领的用户终端接受对上述建议的回复的输入(S109)。然后，第二群组的首领的用户终端将所接受的回复发送到游戏管理装置10(S110)。在第二群组的首领接受与所显示的群组的合并的情况下，第二群组的首领回复该意思。另一方面，在第二群组的首领不接受与所显示的群组的合并的情况下，第二群组的首领回复该意思。

在从第二群组的首领接受了意思是接受与第一群组的合并的回复的情况下，游戏管理装置10的合并单元17进行用于将第一群组和第二群组合并以创建新的单个群组的处理(S111)。然后，游戏管理装置10的合并单元17向第一群组的首领的用户终端和第二群组的首领的用户终端通知合并完成(S112和S113)。

在S111的处理中，合并单元17将已合并的第一群组和第二群组从群组列表(参见图4)中删除，并且将新创建的单个群组登记在群组列表中。然后，合并单元17使属于第一群组的成员和属于第二群组的成员全部都属于新创建的单个群组。

此外，合并单元17可以将第一群组和第二群组的群组属性信息的至少一部分(群组名称等)与新创建的单个群组相关联地登记在群组列表中。在这种情况下，前面所述的群组搜索单元13也参考合并之前的群组属性信息来进行前面所述的群组搜索。这使得用户可以基于合并之前的群组的群组属性信息(群组名称等)来搜索合并之后的群组。

此外，合并单元17可以基于第一群组和第二群组的群组属性信息的至少一部分(平均等级等)来创建新的群组属性信息，并且可以将该新的群组属性信息与新创建的单个群组相关联地登记在群组列表中。例如，合并单元17可以将第一群组的平均等级和第二群组的平均等级的平均值登记为新创建的单个群组的平均等级。

注意，尽管未示出，但在从第二群组的首领接受了意思是不接受与第一群组的合并的回复的情况下，合并单元17不进行用于将第一群组和第二群组合并的处理。

“操作和优势”

根据本实施例的游戏管理装置10通过使用针对各游戏创建暂定群组的方法来创建用于参与游戏的群组。此外，游戏管理装置10通过除了使用“以个体为单位参与游戏”的方法之外还使用“相互合并群组”的方法来创建群组。

这里，如参考图1所述，迄今为止尚不存在用于相互合并动态群组的技术。因而，不存在将用于以用户为单位加入动态群组的技术和用于相互合并动态群组的技术组合的技术。

根据本实施例的游戏管理装置10通过在针对每个游戏创建临时群组的方法中利用迄今为止尚不存在的上述技术，实现了直至聚集期望数量的成员为止的时间的缩短。

根据本实施例的游戏管理装置10的最大优势在于，可以将迄今为止仅针对诸如公会等的静态群组所实现的“用于合并群组的功能”也应用于作为临时的动态群组的房间。

此外，根据本实施例的游戏管理装置10使得可以缩短多人游戏中的匹配时间(用户聚集时间)。对于现有游戏，适用的唯一方法例如是经由SNS或游戏内聊天而重复邀请直到达到多人游戏中的指定成员数量为止。根据本实施例的游戏管理装置10使得能够进行用于“与更大群组合并”的操作，这大大提高了满足指定成员数量的速度。

此外，根据本实施例的游戏管理装置10实现了具有高兼容性的优异特征。根据本实施例的游戏管理装置10在不会破坏现有的公会系统、朋友系统或房间系统的情况下，可以被实现为“向房间的附加功能”。用户可以在直接应用现有房间的操作特征的同时，享受由根据本实施例的游戏管理装置10实现的房间合并(群组合并)。

此外，根据本实施例的游戏管理装置10实现了易于实现的优异特征。由于根据本实施例的游戏管理装置10不需要客户端侧的任何特殊实现、并且可以被实现为向服务器侧的数据库的简单查询，因此引入成本低。

<第二实施例>

根据本实施例的游戏管理装置具有用于将正在执行合并处理的多个群组锁定的功能，由此抑制“除了正在执行的合并之外还执行其他合并、由此合并之后的群组的成员数量超过游戏中所设置的上限这一问题”。以下将给出详细说明。

合并单元17识别作为锁定对象所要选择的群组，并且将所识别的群组登记为锁定对象。此外，合并单元17识别要解除锁定的群组，并且将所识别的群组解除锁定。

将作为锁定对象所登记的群组例如从群组搜索单元13的搜索对象中排除。

此外，将作为锁定对象所登记的群组例如从成员添加单元14的处理对象中排除。例如，在如以下那样的情况下，从成员添加单元14的处理对象中排除是有效的。

示例是如下的情况：在紧挨在群组被登记为锁定对象之前进行的利用群组搜索单元13的搜索的结果中包括的、并且呈现给用户的群组然后被登记为锁定对象，然后用户进行用于申请加入该群组的输入。在这种情况下，在用户进行用于申请加入该群组的输入的定时，该群组已被登记为锁定对象。因而，成员添加单元14不执行用于让用户加入该群组的处理。在这种情况下，可以向用户呈现诸如以下等的消息：“很抱歉，所选择的群组已被锁定，不允许加入”。

此外，将作为锁定对象所登记的群组例如从合并对象搜索单元15的搜索对象中排除。

此外，将作为锁定对象所登记的群组例如从建议单元16的处理和合并单元17的处理中排除。例如，在如以下那样的情况下，从建议单元16的处理和合并单元17的处理的对象中排除是有效的。

示例是如下的情况：在紧挨在群组被登记为锁定对象之前进行的利用合并对象搜索单元15的搜索的结果中包括的、并且作为合并对象呈现给群组的首领的群组然后被登记为锁定对象，然后用户进行与该群组合并的提议的输入。在这种情况下，在用户进行与该群组合并的提议的输入的定时，该群组已被登记为锁定对象。因而，建议单元16不执行用于向被提议了合并的群组建议与该群组合并的处理。此外，合并单元17不执行用于将群组与被提议了合并的群组合并的操作。在这种情况下，可以向用户呈现诸如以下等的消息：“很抱歉，所选择的群组已被锁定，不允许合并”。

以下将参考图10的序列图来更详细地说明该处理的示例流程。注意，对于与参考图7中的序列图所述的处理相同的处理，将适当省略说明。

首先，作为招募群组的第一群组的首领经由用户终端输入用于搜索可以合并的群组的指令(S201)。响应于所输入的指令，游戏管理装置10搜索可以与第一群组合并的群组(S202)。

接着，游戏管理装置10将S202中的搜索结果以及在该搜索结果中指示的用于与“可以与第一群组合并的群组”合并的建议发送到第一群组的首领的用户终端(S203)。然后，第一群组的首领的用户终端显示这些信息(S204)。例如，在第一群组的首领的用户终端上诸如图8所示的画面等的画面。

然后，第一群组的首领的用户终端接受对上述建议的回复的输入(S205)。然后，第一群组的首领的用户终端将所接受的回复发送到游戏管理装置10(S206)。在第一群组的首领希望与列表中所显示的群组其中之一合并的情况下，第一群组的首领选择该群组，并且进行与该群组合并的提议的输入。另一方面，在第一群组的首领不希望与列表中所显示的群组中的任一个合并的情况下，第一群组的首领进行该意思的输入。

注意，图10的S207中及其之后的处理是在S205中第一群组的首领进行了与列表中所显示的群组其中之一合并的提议的输入的情况下的处理。在S205中第一群组的首领进行了意思是不希望与列表中所显示的群组中的任一个合并的输入的情况下，不执行S207中及其之后的处理，并且由S201触发的合并处理结束。

在S207中，游戏管理装置10将第一群组以及由第一群组的首领选择为合并对象的第二群组登记为锁定对象(S207)。

在S208中，游戏管理装置10将用于与第一群组合并的建议发送到第二群组的首领的用户终端(S208)。然后，第二群组的首领的用户终端显示这些信息(S209)。例如，在第二群组的首领的用户终端上显示诸如图9所示的画面等的画面。

然后，第二群组的首领的用户终端接受对上述建议的回复的输入(S210)。然后，第二群组的首领的用户终端将所接受的回复发送到游戏管理装置10(S211)。在第二群组的首领接受与所显示的群组的合并的情况下，第二群组的首领回复该意思。另一方面，在第二群组的首领不接受与所显示的群组的合并的情况下，第二群组的首领回复该意思。

在从第二群组的首领接收到意思是接受与第一群组的合并的回复的情况下，游戏管理装置10进行用于将第一群组和第二群组合并以创建新的单个群组的处理(S212)。在S212的处理中，游戏管理装置10将已合并的第一群组和第二群组从群组列表(参见图4)中删除，并且将新创建的单个群组登记在群组列表中。作为将第一群组和第二群组从群组列表中删除的结果，第一群组和第二群组变为解除锁定(S213)。注意，新创建的单个群组不继承锁定。

然后，游戏管理装置10向第一群组的首领的用户终端和第二群组的首领的用户终端通知合并完成(S214和S215)。

注意，尽管未示出，但在从第二群组的首领接受了意思是不接受与第一群组的合并的回复的情况下，游戏管理装置10不进行用于将第一群组和第二群组合并的处理。响应于回复的接受，游戏管理装置10将第一群组和第二群组解除锁定。

根据本实施例的游戏管理装置10的结构在其他方面与第一实施例中的结构相同。

根据本实施例的游戏管理装置10实现了与根据第一实施例的游戏管理装置10相同的操作和优势。此外，根据本实施例的游戏管理装置10使得可以执行控制，以在适当定时将已开始合并处理的群组锁定，由此禁止除进行中的合并处理以外的合并的执行。这使得可以抑制“除了正在执行的合并之外还执行其他合并、由此合并之后的群组的成员数量超过游戏中所设置的上限这一问题”。

<变形例>

-第一变形例-

在以上所述的情况下，沿着以下流程进行合并处理：从第一群组接受用于搜索合并对象的请求，响应于该请求而搜索满足与第一群组的合并条件的群组，向第一群组建议与通过搜索找到的群组合并，并且基于来自第一群组的回复来向第二群组建议合并。

作为变形例，游戏管理装置10可以在未从群组其中之一接受用于搜索合并对象的请求的情况下，在预先定义的规定定时(例如，按规定的时间间隔)从招募群组中搜索可以相互合并的两个或多于两个群组，并且可以向这些群组建议与群组的相互合并。

在本变形例的情况下，例如，在通过搜索所找到的可以合并的两个或多于两个群组的首领的用户终端上显示诸如图11和图12所示的画面等的画面。在图11和图12中的示例的情况下，通过搜索找到群组“群组名称：CYCYGA”和群组“群组名称：MINMIN”作为可以合并的两个或多于两个群组，并且向这些群组中的各群组建议与彼此的合并。

在这种情况下，在从双方的群组接收到意思是接受合并的回复的情况下，合并单元17进行用于合并这些群组的处理。另一方面，在从至少一方的群组接收到意思是不接受合并的回复的情况下，合并单元17不进行用于合并这些群组的处理。

注意，在本变形例的情况下，如图11和图12的画面的右上方所示，可以指定建议的有效时间段。此外，在建议的有效时间段变为零之前、没有从双方的群组接收到意思是接受合并的回复的情况下，合并单元17可以取消用于合并这些群组的处理，从而使建议无效。在这种情况下，合并单元17可以从向双方的群组建议合并的定时起、直到“建议的有效时间段变为零的定时”、“从至少一方的群组接受意思是不接受合并的回复的定时”、以及“在从双方的群组接受意思是接受合并的回复之后合并完成的定时”中的最早定时为止，将该双方的群组登记为锁定对象。

-第二变形例-

在以上所述的情况下，向各群组的一个成员(首领)建议群组的合并；可替代地，配置可以是这样的：向各群组的多个成员建议合并。例如，可以预先针对各群组登记建议所针对的至少一个成员。此外，在从作为建议的对象所登记的至少一个成员其中之一接收到回复的情况下，游戏管理装置10可以在将该回复视为来自群组的回复的同时继续进行后续处理。

-第三变形例-

在以上所述的情况下，预先假定合并两个群组以创建单个群组；可替代地，可以合并三个或多于三个群组以创建单个群组。在这种情况下，在诸如图8所示等的合并对象搜索结果画面中，用户可以选择多个群组并且可以向这多个群组提议合并。注意，执行控制以使得能够在提议合并的群组的成员数量与所选择的群组的成员数量的总和不超过游戏中预先设置的上限的范围内选择多个群组。

例如，诸如图8所示等的接收到合并对象的搜索结果的CYCYGA中的MU-KUN可以从搜索结果中所显示的多个群组中选择群组“群组名称：MINMIN”(以下称为“MINMIN”)和群组“群组名称：BANANAN”(以下称为“BANANAN”)作为合并对象。

在这种情况下，向MINMIN的首领建议与CYCYGA和BANANAN的合并。此外，向BANANAN的首领建议与CYCYGA和MINMIN的合并。此外，在MINMIN的首领和BANANAN的首领两者都回复了接受合并的意思的情况下，将这三个群组合并。在MINMIN的首领和BANANAN的首领中的至少一个未接受合并的情况下，不合并这三个群组。

<示例>

以下说明更具体地体现上述的游戏管理装置10的示例。注意，以下示例仅仅是示例，并且本实施例不限于该示例。

-概述-

图13示出根据该示例的系统结构。在该示例中，向不满足参与多人游戏的指定成员数量的房间(群组)的主人用户推荐用作候选合并目的地的其他房间，并且如果存在用户希望合并的房间，则将这两个房间合并以创建新房间。可以从用于搜索用于管理房间的数据库的操作和用于更新数据库的操作方面定义该示例。该示例中的房间合并处理按以下方式执行。

(1)当用户新创建了房间并且开始招募用户时，该系统的客户端侧UI模块([M3]UI模块)通过使用当前房间作为参数来在服务器侧调用[M1]搜索模块的搜索功能，以搜索用作候选合并目的地的房间。[M1]搜索模块在[D1]房间DB中搜索可以与作为参数所接收到的房间合并的房间，并且将这些房间返回到客户端。

(2)客户端侧模块将从服务器接收到的候选合并目的地信息显示在UI上，并且向用户建议房间合并。此时，优选通过除了显示合并目的地房间的名称之外还显示房间中的用户数量、等级信息等，来激励用户合并房间。

(3)如果用户希望进行房间合并并且向客户端侧UI模块发出了用于合并的指令，则客户端侧模块将合并请求发送到服务器侧的[M2]合并模块，该合并请求包括由用户主办的房间以及合并目的地房间作为两个参数。

(4)[M2]合并模块从[D1]房间DB获取锁定以防止合并目的地房间超过成员数量的上限。该锁定结构防止作为房间的多次合并的结果而导致超过成员数量的上限等。作为实现，优先将锁定的房间从[M1]搜索模块的搜索结果中排除。此外，在可以进行实时通信的情况下，优选[M3]UI模块不显示锁定的房间。

(5)[M2]合并模块向[D1]房间DB发出数据更新请求以创建包含属于两个房间的所有用户的新房间，并且执行合并处理。此时，优选将两个现有房间的名称或标识符(ID)设置为新创建的房间的别名。

-数据结构-

位于本示例的核心的数据结构是房间。房间具有在系统中唯一可标识的ID、以及人类可辨认的名称或编号，并且包括多个用户作为成员。此时，一般地，允许单个用户同时仅参与一个房间。可以如以下给出的式(1)那样定义房间(“room”)。

[数学式1]

room∶＝[id,criteria,user_o,user₁,…,user_n,alias_o,alias₁,…,alias_m] 式(1)

这里，“id”表示用于唯一地标识系统内的房间的标识符。“criteria”表示可以参与该房间的用户的条件(群组加入条件)：例如，可以设置诸如等级或装备等的游戏特定条件。“user_i”表示属于房间的第i个用户的标识符，并且“alias_i”表示指派给房间的别名。如果在合并了房间时、可以通过使用合并之前的名称来访问通过合并所创建的房间，则更容易聚集用户。因而，优选使得各房间能够具有合并之前的各个房间的名称作为别名。

-原函数-

该示例可以用以下三个原函数的组合的形式来实现。

(1)用于搜索用作合并候选的房间的函数。该函数例如由以下给出的式(2)表示。

[数学式2]

search(room,max)→[room′₁,room′₂,…,room′_n] 式(2)

该函数接收构成查询的房间信息“room”，搜索满足“room”的“criteria”且在将两个房间中的成员数量相加到一起时成员总数不超过“max”的房间，并返回这样的房间的列表。注意，作为实现，优选从“search”函数的搜索对象中排除通过后面将说明的lock函数所锁定的房间。

(2)用于合并两个“room”的函数。该函数例如由以下给出的式(3)表示。

[数学式3]

merge(room₁,room₂)→room′|member(room′)＝member(room₁)∪member(room₂) 式(3)

该函数是接收两个“room”并将这两个“room”合并以创建“room”的函数。此时，设属于“room”的用户集合由“member(room)”表示，则新创建的房间的成员由作为自变量给出的两个房间的成员的并集表示。作为该示例的实现，尽管“room”的“id”是新创建的，但优选保存合并之前的“room1”和“room2”的“id”或名称作为“room”的别名。此外，可想到的合并“room”的“criteria”的方法包括：“采用各个房间的标准中的更严格的标准的方法”；“采用各个房间的标准中的更宽松的标准的方法”；“采用被提议了合并的房间的“criteria”的方法”；以及“在合并时由用户新确定“criteria”的方法”。

(3)用于锁定特定“room”的函数。该函数例如由以下的式(4)表示。

[数学式4]

lock(room₁,room₂)→success | fail 式(4)

该函数是接收两个“room”、并且从属于其他群组的用户中获取用以禁止对相应房间的参考和相应房间的更新的锁定的函数。该锁定机构防止了作为房间的多次合并的结果而导致超过成员数量的上限等。在未能获取到针对两个房间的两个锁定的情况下，释放所有的锁定，并且返回“fail”。仅当成功获取到针对两个房间的两个锁定时，才返回“success”。

以下附加了示例参考模式。

1.一种游戏管理装置，包括：

2.根据1所述的游戏管理装置，其中，

针对各个群组定义用于成为成员的群组加入条件，以及

所述合并条件是通过使用所述群组加入条件来定义的。

3.根据1所述的游戏管理装置，其中，所述合并条件是通过使用属于群组的成员的用户属性来定义的。

4.根据1至3中任一项所述的游戏管理装置，其中，所述合并条件包括属于相互的群组的成员的数量的总和小于或等于上限的条件。

5.根据1至4中任一项所述的游戏管理装置，其中，

所述存储单元存储将群组属性信息与所述多个群组中的各个群组相关联的列表，

所述合并单元在合并了两个或多于两个群组的情况下，在将合并之前的两个或多于两个群组从所述列表删除的同时，将合并之后的单个群组登记在所述列表中，以及

所述合并单元将合并之前的两个或多于两个群组中的各个群组的群组属性信息与合并之后的单个群组相关联地登记在所述列表中。

6.根据5所述的游戏管理装置，还包括群组搜索单元，所述群组搜索单元用于参考所述列表中所登记的群组属性信息，从所述列表中所登记的群组中搜索与搜索条件匹配的群组。

7.根据1至6中任一项所述的游戏管理装置，其中，

存在群组中的成员数量的上限，

所述合并对象搜索单元搜索能够与第一群组合并的一个或多于一个群组，所述第一群组是成员数量未达到游戏中预先设置的上限且处于能够添加成员的状态的群组其中之一，

所述建议单元向所述第一群组建议将通过搜索而找到的一个或多于一个群组作为能够合并的群组，并且接受指示从能够合并的群组中选择的一个或多于一个群组作为合并对象的回复，

所述合并单元在从所述第一群组接收到用于选择一个或多于一个群组的回复之后，将所述第一群组和所选择的一个或多于一个群组登记为锁定对象，所述锁定对象不能与其他群组合并，

所述建议单元在从所述第一群组接收到用于选择一个或多于一个群组的回复之后，向所选择的一个或多于一个群组建议与所述第一群组的合并，并且接受来自所选择的一个或多于一个群组的回复，以及

在从所选择的一个或多于一个群组接收到意思是接受与所述第一群组的合并的回复的情况下，所述合并单元将所述第一群组和所选择的一个或多于一个群组合并。

8.一种游戏管理方法，其中，计算机进行以下操作：

存储由一个或多于一个成员构成的多个群组的列表；

9.一种程序，用于使得计算机用作：

本申请要求基于2021年3月17日提交的日本专利申请2021-043722的优先权，并且其全部公开内容被并入本文。

附图标记说明

1A 处理器

2A 存储器

3A 输入/输出接口

4A 周边电路

5A 总线

10 游戏管理装置

11 存储单元

12 群组添加单元

13 群组搜索单元

14 成员添加单元

15 合并对象搜索单元

16 建议单元

17 合并单元

Claims

1.一种游戏管理装置，包括：

2.根据权利要求1所述的游戏管理装置，其中，

针对各个群组定义用于成为成员的群组加入条件，以及

所述合并条件是通过使用所述群组加入条件来定义的。

3.根据权利要求1所述的游戏管理装置，其中，所述合并条件是通过使用属于群组的成员的用户属性来定义的。

4.根据权利要求1至3中任一项所述的游戏管理装置，其中，所述合并条件包括属于相互的群组的成员的数量的总和小于或等于上限的条件。

5.根据权利要求1至4中任一项所述的游戏管理装置，其中，

6.根据权利要求5所述的游戏管理装置，还包括群组搜索单元，所述群组搜索单元用于参考所述列表中所登记的群组属性信息，从所述列表中所登记的群组中搜索与搜索条件匹配的群组。

7.根据权利要求1至6中任一项所述的游戏管理装置，其中，

存在群组中的成员数量的上限，

8.一种游戏管理方法，其中，计算机进行以下操作：

存储由一个或多于一个成员构成的多个群组的列表；

9.一种程序，用于使得计算机用作：