在開始實作與瞭解細部功能前，讓我們先初步的看過整體架構是怎麼運作的，以利後續 demo 實作與各部件解析時，有個目前資料流動到哪裡的概念，並且會說明哪個部件是我們使用 Open-Match 需要實作的部件，哪些是 Open-Match 無需異動的核心。

配對框架

參照官網架構圖，我們可以分隔出三個主要類別：

• 框架核心(Core Open Match Services)：部署於 kubernetes 上的配對核心，可透過 gRPC & HTTP 接口呼叫使用
• 客製化部件(藍色+粉紅色部分)：需自行實作用來滿足核心接口與配對邏輯的部件，主要有三個部分
  • Game Frontend：用以產生配對條件請求的部件，通常會依據玩家的各種特性與標籤，產生符合該玩家的遊戲配對請求，而這份請求稱之為 Ticket
  • Match Function (MMF)：被框架核心所呼叫的配對邏輯，開發者需依據遊戲的需求，實作符合各種標籤屬性的配對方法，透過配剖析(MatchProfiles) 裡的 Tickets 產出每一場配對組合(Matches)
  • Director：此部件透過持續向 Open-Match Backend 呼叫，取出配對組合(Matches) ，並且將符合配對邏輯的 Matches 與遊戲伺服器(DGS)介接
• 遊戲伺服器與平台(灰色部分)：此部分不屬 Open-Match 框架，而是遊戲伺服器本身與儲存使用者各種屬性資訊的平台服務

依據其架構切分，可以看出我們需滿足 Tickets 產生配對請求，並撰寫用配對用的邏輯 Match Function(MMF)，最後 Director 用以決斷配對組合 Matches 如何與遊戲伺服器(DGS)登入或註冊。而這些設計的主要目的，依然是把“配對”這件事從遊戲伺服器本身抽離出來，讓配對伺服器與遊戲伺服器更方便的水平拓展，藉由實作 Open-Match 預留好的部件 Game Frontend、Match Function 與 Director 滿足上述流程。

Referance

• https://open-match.dev/site/