cloudnativegame / kruise-game-open-match-director Goto Github PK

背景需求

存在以下情况，进入匹配后对局（Match）信息需要反馈给玩家客户端或游戏大厅。例如，一个对局中存在多个队伍，每个队伍的对应的玩家ID情况需要在Assignment所表示，以便玩家客户端或游戏大厅watch Assignment时可以及时获取对应信息。然而，该类信息通常由匹配逻辑决定，匹配结果的产物是Match，因此需要一种协议，将Match中的extensions透传至Assignment。

设计

Director会将match对象所有的extensions透传至Assignment. 因此对于开发者，在编写match function时，将希望被玩家客户端或游戏大厅的新增信息记录在match的extensions即可。

背景

当存在玩家间允许异步进入房间，或是允许玩家退出补位的情况时，需要利用Open Match Backfill机制实现上述功能。

设计

• Backfill 新增 SearchFields Tag "game.kruise.io/connected"，表示该Backfill对应的房间已经开始游戏。
• Backfill 新增 Extensions Key "game.kruise.io/connection"，记录Backfill对应对局的连接信息。
  上述字段同时出现，例如：

pb.Backfill{
			SearchFields: &pb.SearchFields{
				Tags: []string{"game.kruise.io/connected"},
			},
			Extensions: map[string]*anypb.Any{
				"game.kruise.io/connection": any,
			},
		}

director fetch Match时若出现Backfill，则查看该Backfill是否已经分配过，若分配过，则将match的tickets assign 对应连接信息；若未分配过，则新分配gs给match的tickets。

背景

当前director默认支持一种游戏的游戏服筛选。现在提出一种支持多个游戏的director方案，来支持集群中部署多种游戏服。

设计

director

新增名为 game_name 的 profile，pool filter为string类型。例如，集群中存在三种游戏：football、basketball、tennis，director将生成以下profile：

	p := []*pb.MatchProfile{
		{
			Name: "football",
			Pools: []*pb.Pool{
				{
					Name: "game_name",
					StringEqualsFilters: []*pb.StringEqualsFilter{
						{
							StringArg: "game_name",
							Value:     "football",
						},
					},
				},
			},
		},
		{
			Name: "basketball",
			Pools: []*pb.Pool{
				{
					Name: "game_name",
					StringEqualsFilters: []*pb.StringEqualsFilter{
						{
							StringArg: "game_name",
							Value:     "basketball",
						},
					},
				},
			},
		},
		{
			Name: "tennis",
			Pools: []*pb.Pool{
				{
					Name: "game_name",
					StringEqualsFilters: []*pb.StringEqualsFilter{
						{
							StringArg: "game_name",
							Value:     "tennis",
						},
					},
				},
			},
		},
	}

这里的game_name对应在Kubernetes集群中的GameServerSet的名称。若希望返回正确结果，集群中应存在名为football、basketball、tennis的gss对象。

open-match其他自定义组件的处理逻辑

• mmf 根据pool来筛选ticket与backfill

• game frontend创建ticket时带上相应的searchField，例如希望匹配足球游戏时，ticket创建所示：

  &pb.Ticket{
    	  SearchFields: &pb.SearchFields{
    		  StringArgs: map[string]string{
    			  "game_name": "football",
    		  },
    	  },
      }
  

背景需求

为了尽可能降低网络延迟并优化玩家体验，大型多人在线对战(PvP)游戏经常采取在全球范围内部署服务器的做法。这种布局确保了玩家可以连接到地理位置邻近的节点，以获得更流畅的游戏过程。然而，为了丰富游戏的趣味性，在网络延迟允许的前提下，来自世界各地的玩家也应有机会加入到同一场对战中。这就将游戏内的匹配逻辑带入了一个全新的复杂性层级。
以往，OKG的director系统各自独立运行于每个服务器集群之中，专注于处理本地集群的匹配要求，同时仅限于指派各自集群内的服务器资源。不难看出，这种单一集群的模式由于局限于特定区域，无法满足跨区域游戏匹配需求，阻碍了全球化玩家互动的潜能。
如今要想跨越这个障碍，就必须对现有的游戏匹配架构进行全方位的更新，创建一个能够在全球范围内高效匹配玩家的模型。这种全域匹配系统的引进，不仅能够提供更好的玩家游戏体验，还能促进不同文化背景的玩家之间的交流，为游戏带来更加广泛的国际影响力。

架构设计

方案架构图如下图所示

• 每个地域存在一套Kubernetes集群环境
• 每个地域的Kubernetes集群都安装OKG，并部署相同名称的GameServerSet
• 选择某地（此例中为Region A）Kubernetes集群作为Host集群，部署Open Match

匹配过程如下：

1. 玩家客户端访问各地Ping Server，获取即时延迟数据。
2. 将各地延迟数据作为ticket属性，向Host集群的Open Match发起请求，进入匹配队列。
3. Host集群中Director将生成与地域有关的Profile，并解析生成的Match、寻找对应地域的可用房间服，获取其地址并返回。

Director改造设计

为满足上述架构，kruise-game-open-match-director（OKG Director）需要进行全地域化改造：

• 配置多集群GameServer访问权限
• profile name 格式改变，带上地域属性
• 解析match，根据match中的profile name访问对应地域的GameServer

新增启动参数

-- slave-clusters

• default: "", which means only host cluster exists.
• usage: Specify the slave cluster names, which are also the names of corresponding kubeconfig secrets. Format is "{cluster_1_secret_name},{cluster_2_secret_name},..."

profile命名规范

• 当 slave-clusters 为默认值，即不存在从集群时，profile命名与之前一致，以gssName作为名称
• 当存在slave-clusters，profile命名规范如下：{gssName}_{cluster_name}.例如，存在两个gss，分别为game-1，game-2；同时存在一个从集群region-b，则会生成四个profile，其命名分别为：game-1_Host; game-1_region-b; game-2_Host; game-2_region-b.

master集群访问slave集群资源

从集群（图中的region B、C所在集群）的kubeconfig以主集群open match同命名空间下的secret形式部署，主集群拿到从集群的访问权限。