Open Match – Tutorials

Docs: How to build a basic Matchmaker

Mon, 01 Jan 0001 00:00:00 +0000

Objectives

Understand how to use Open Match for Matchmaking.
Author a simple Match Function, Game Frontend and Director in Golang.
Build and run an E2E Matchmaker by connecting these components to an Open Match deployment.

Prerequisites

Set up a Kubernetes Cluster

Some basic understanding of Kubernetes, kubectl is required to efficiently completely this tutorial. Follow the instructions to set up a Kubernetes cluster, install and configure kubectl to connect to this cluster.

Install Open Match

Lets setup Open Match next by running the steps in Install Open Match Core. Please be sure to also install the default Evaluator.

Note

If you already installed Open Match for the Getting Started Demo, you can skip this step. Simply delete the demo namespace and proceed.

Set up Image Registry

Please setup an Image registry(such as Docker Hub or GC Container Registry) to store the Docker Images used in this tutorial. Once you have set this up, here are the instructions to set up a shell variable that points to your registry:

REGISTRY=[YOUR_REGISTRY_URL]

If using GKE, the below command can be used to populate the image registry:

REGISTRY=gcr.io/$(gcloud config list --format 'value(core.project)')

Get the Tutorial template

Make a local copy of the Tutorials Folder. Checkout release-x.y branch（e.g. release-1.3, release-1.4） of the Open Match Git repository. Use tutorials/matchmaker101 of release-x.y branch as a working copy for all the instructions in this tutorial.

For convenience, set the following variable:

TUTORIALROOT=[SRCROOT]/tutorials/matchmaker101

Create the Tutorial namespace

Run this command to create a namespace mm101-tutorial in which all the components for this Tutorial will be deployed.

kubectl create namespace mm101-tutorial

References

Please read through the Matchmaking Guide as the Matchmaker in this tutorial is modeled around the components introduced in the Guide. Also, keep the API Reference handy to look up Open Match specific terminology used in this document.

A complete solution for this tutorial can be found at tutorials/matchmaker101/solution To use the solution directly, just run the “Build and Push” step in each of the component sections and then go to Deploy and Run

Overview

The goal is to build a basic game mode based Matchmaker where there are a fixed set of game modes and each Player intends to find a match for a specific game mode.

The tutorial walks through building the Game Frontend, Director, Match Function and then deploys them together. Here is a high-level flow once all these components are set up:

The Game Frontend creates Tickets that specified a game mode.
The Director requests for matches for a specific game mode.
The Match Function queries for Tickets from the current pool that match this constraint and groups available Tickets into match proposals.
The Director receives the matches and sets fake Assignments for Tickets in these.
The Game Frontend receives these Assignments and then deletes the Tickets.

For the curious mind

Open Match enables the user to plug in a custom component called the Evaluator. The Evaluator is responsible for deduplicating any concurrently generated proposals, discarding or promoting the proposals as result Matches. Open Match provides a default Evaluator that this tutorial uses. This tutorial is designed not to generate concurrent conflicting proposals so Evaluation is a no-op. The deployment step deploys the default Evaluator in the tutorial namespace and configures this in Open Match. See the Evaluator Guide for details on proposal evaluation.

Next Steps

Docs: Add new matchmaking criteria

Mon, 01 Jan 0001 00:00:00 +0000

Objectives

Adds new search criteria to Open Match
Write a MatchFunction to get Tickets from multiple Pools and generate Team-based Matches.

Prerequisites

Basic Matchmaker Tutorial

It is highly recommended that you run the Basic Matchmaker tutorial as it introduces the core concepts that this tutorial builds upon. After completion, please remember to cleanup the basic tutorial before proceeding.

Set up Image Registry

Please setup an Image registry(such as Docker Hub or Google Cloud Container Registry) to store the Docker Images used in this tutorial. Once you have set this up, here are the instructions to set up a shell variable that points to your registry:

REGISTRY=[YOUR_REGISTRY_URL]

If using GKE, you can populate the image registry using the command below:

REGISTRY=gcr.io/$(gcloud config list --format 'value(core.project)')

Get the Tutorial template

Make a local copy of the Tutorials Folder. Checkout release-x.y branch（e.g. release-1.3, release-1.4） of the Open Match Git repository. Use tutorials/matchmaker102 of release-x.y branch as a working copy for all the instructions in this tutorial.

For convenience, set the following variable:

TUTORIALROOT=[SRCROOT]/tutorials/matchmaker102

Create the Tutorial namespace

Run this command to create a namespace mm102-tutorial in which all the components for this Tutorial will be deployed.

kubectl create namespace mm102-tutorial

References

A complete solution for this tutorial is in the folder tutorials/matchmaker102/solution.

Changes to Components

Overview

For this tutorial, let’s consider a game where each Player will choose to play the Match with a specific role (one of DPS, support or tank). Assume that a Match (for each game-mode) will comprise of one Player of each role. Here are the high-level changes to the Game Frontend, the Director and the MatchFunction to achieve this:

The Game Frontend will specify the role on a new SearchField on each Ticket.
The Director will specify multiple Pools in each MatchProfile, one per role.
The MatchFunction will query for Tickets for each Pool and generate Matches with a Ticket of each role.

The below sections cover the changes to be made to the key components to achieving this.

Game Frontend

This tutorial provides a Game Frontend scaffold ($TUTORIALROOT/frontend) that generates a Ticket with the game mode specified (as implemented for the basic Matchmaker). The mock Ticket generation is implemented in makeTicket() in $TUTORIALROOT/frontend/ticket.go.

We need to add a new SearchField to the Ticket to represent the role property for this Player. The below code snippet picks a random role and sets it as a StringArg SearchField for the fake Ticket.

func makeTicket() *pb.Ticket {
  ticket := &pb.Ticket{
    SearchFields: &pb.SearchFields{
      Tags: []string{
        gameMode(),
      },
      StringArgs: map[string]string{
        "attributes.role": role(),
      },
    },
  }

  return ticket
}

func role() string {
  roles := []string{"role.dps", "role.support", "role.tank"}
  return roles[rand.Intn(len(roles))]
}

Please update the Ticket creation logic in $TUTORIALROOT/frontend/ticket.go with the above snippet and make your own tweaks.

Director

This tutorial provides a Director scaffold ($TUTORIALROOT/director) that generates a MatchProfile per game-mode and then calls FetchMatches for each MatchProfile. The MatchProfile generation is implemented in generateProfiles() in $TUTORIALROOT/director/profile.go

In the basic Matchmaker, each MatchProfile had a single Pool specifying the game-mode filter. For this tutorial, we will have a Pool per role that filters the role along with the filter for the mode. Thus, the generateProfiles() will generate a MatchProfile for each game-mode, each of which will have a Pool per role. Below is a sample snippet to achieve this:

func generateProfiles() []*pb.MatchProfile {
  var profiles []*pb.MatchProfile
  modes := []string{"mode.demo", "mode.ctf", "mode.battleroyale"}
  roles := []string{"role.dps", "role.support", "role.tank"}
  for _, mode := range modes {
    var pools []*pb.Pool
    for _, role := range roles {
      pools = append(pools, &pb.Pool{
        Name: fmt.Sprintf("pool_%s_%s", mode, role),
        TagPresentFilters: []*pb.TagPresentFilter{{Tag: mode}},
        StringEqualsFilters: []*pb.StringEqualsFilter{
          {
            StringArg: "attributes.role",
            Value:     role,
          },
        },
      })
    }

    profiles = append(profiles, &pb.MatchProfile{
      Name:  "profile_" + mode,
      Pools: pools,
    })
  }

  return profiles
}

Please update the MatchProfile creation logic in $TUTORIALROOT/director/profiles.go with the above snippet and make your own tweaks.

MatchFunction

This tutorial provides a MatchFunction scaffold ($TUTORIALROOT/matchfunction) that generates Match proposals for the MatchProfile that gets passed in. The core matchmaking logic is implemented in makeMatches() in $TUTORIALROOT/matchfunction/mmf/matchfunction.go.

The QueryPools helper from the matchfunction library already provides the ability to query Tickets for all the Pools in the MatchProfile. Also, the basic Matchmaker implementation already picks players from each Pool into the Match - hence just by the MatchProfile having one Pool per role, the existing MatchFunction will generate Match proposals with Tickets of each role.

Although no changes are needed to the core matchmaking logic, you may add some logging or tweak the number of players from each role in a team, etc., to observe the change in matchmaking behavior.

Build, Deploy, Run

Build and Push Container images

Now that you have customized these components, please run the below commands from $TUTORIALROOT to build new images and push them to your configured image registry.

docker build -t $REGISTRY/mm102-tutorial-frontend frontend/
docker push $REGISTRY/mm102-tutorial-frontend
docker build -t $REGISTRY/mm102-tutorial-director director/
docker push $REGISTRY/mm102-tutorial-director
docker build -t $REGISTRY/mm102-tutorial-matchfunction matchfunction/
docker push $REGISTRY/mm102-tutorial-matchfunction

Deploy and Run

Run the below command in the $TUTORIALROOT path to deploy the MatchFunction, Game Frontend and the Director to the mm102-tutorial namespace:

sed "s|REGISTRY_PLACEHOLDER|$REGISTRY|g" matchmaker.yaml | kubectl apply -f -

Output

All the components in this tutorial simply log their progress to stdout. Thus to see the progress, run the below commands:

kubectl logs -n mm102-tutorial pod/mm102-tutorial-frontend
kubectl logs -n mm102-tutorial pod/mm102-tutorial-director
kubectl logs -n mm102-tutorial pod/mm102-tutorial-matchfunction

Cleanup

Run the command below to remove all the components of this tutorial:

kubectl delete namespace mm102-tutorial

This will delete all the components deployed in this tutorial. Open Match core in open-match namespace can then be reused for other exercises but you will need to re-customize it.

What’s Next

Given that a Ticket can only pick one game-mode, the Matchmaker implemented so far generate Matches from completely partitioned Tickets, where a Ticket is only considered for a game-mode. Next, we can learn how to use the default evaluator to handle scenarios where a Ticket may specify multiple game mode preferences and hence may be picked by more than one MatchFunction.

Docs: Use the Default Evaluator

Mon, 01 Jan 0001 00:00:00 +0000

Objectives

Understands how and why we need the Default Evaluator to resolve proposal conflicts.
Instructs your MatchFunction to use the default Evaluator.

Prerequisites

Basic Matchmaker tutorial

Set up Image Registry

Please setup an Image registry(such as Docker Hub or GC Container Registry) to store the Docker Images that will be generated in this tutorial. Once you have set this up, here are the instructions to set up a shell variable that points to your registry:

REGISTRY=[YOUR_REGISTRY_URL]

If using GKE, you can populate the image registry using the command below:

REGISTRY=gcr.io/$(gcloud config list --format 'value(core.project)')

Get the tutorial template

Make a local copy of the tutorials Folder. Checkout release-x.y branch（e.g. release-1.3, release-1.4） of the Open Match Git repository. Use tutorials/default_evaluator of release-x.y branch as a working copy for all the instructions in this tutorial.

For convenience, set the following variable:

TUTORIALROOT=[SRCROOT]/tutorials/default_evaluator

Create the tutorial namespace

Run this command to create a namespace default-eval-tutorial in which all the components for this tutorial will be deployed.

kubectl create namespace default-eval-tutorial

References

A complete solution for this tutorial is in the folder tutorials/default_evaluator/solution.

Evaluation

Overview

In the basic Matchmaker, each Ticket had only one game-mode and the Director generated a MatchProfile per game-mode. Thus concurrently executing MatchFunction (for each MatchProfile) worked with completely partitioned (by game-mode) Ticket Pools. However, this may not always be the case. There are scenarios in which, the Pools specified in concurrent MatchProfiles may have an overlap and thus concurrently executing MatchFunctions could use overlapping Ticket in its Proposals.

In a lot of real matchmaking scenarios, this overlap is desired. To generate high-quality Matches, you may want your Ticket to be considered concurrently for multiple possible MatchProfiles and then be able to compare the quality of these overlapping Matches, picking the highest quality Match and discarding the rest. The ability to provide this model of executing concurrent MatchFunctions on overlapping Ticket Pool is a core value proposition of Open Match.

To allow generation of proposals using overlapping Tickets but still provide unique Matches to the Director, Open Match synchronizes all the proposals generated by concurrently executing MatchFunctions and passes these to an Evaluator to perform de-collision.

Since basic cases may either not need an evaluation or may need very simple evaluation, Open Match provides a default Evaluator as an optional component that may work in most scenarios. At a high level, there are three evaluation scenarios for you to consider when using Open Match:

Your MatchProfiles completely partition the Ticket Pool and so you will never have collisions(the basic Matchmaker falls under this usage). The default Evaluator handles this scenario and you do not have to make any changes.
Your MatchProfiles may use overlapping Ticket Pools - but each MatchFunction can simply generate a quality score for that Match based on certain game-specific criteria (latency, MMR, etc.). The default Evaluator can be used for this scenario by following instructions in this tutorial to add specific information needed for evaluation to the Match in your MatchFunction.
You have complex evaluation logic that cannot be simplified to a score for a Match but rather involves comparing some details of the overlapping Matches. Open Match provides you with the ability to plug in your custom Evaluator to handle this case. See the tutorial for using a Custom Evaluator for details.

Default Evaluator

The Evaluator for Open Match at a high level accepts Match proposals (that may be overlapping) and returns non-overlapping result Matches. Open Match provides an optional default score based Evaluator that you can deploy with core Open Match installation.

The default Evaluator expects that the MatchFunction populate a ‘score’ for the generated Matches. When it is invoked with a list of proposals, it simply sorts the Matches by score and in case of collision, picks the Match with the highest score as a result and discards the other colliding matches.

The MatchFunction may use a game-specific information (MMR, latency, etc.) to compute the score for this Match. It populates the score in a DefaultEvaluationCriteria proto that is shown below.

message DefaultEvaluationCriteria {
  double score = 1;
}

The MatchFunction embeds the populated DefaultEvaluationCriteria in the Match’s Extensions field (Extensions are a mechanism Open Match uses to pass blobs of specific information across components that extend Open Match). The default Evaluator accesses the score for the Match from this field and uses it as a proxy for the Match quality. This tutorial provides step-by-step instructions and samples to generate the score and populate the DefaultEvaluationCriteria for a Match.

Using the Default Evaluator

Scenario Overview

For this tutorial, we will tweak the basic matchmaking scenario to enable a Player to select more than one game-mode to be considered for finding a Match. Given that the Director for our Matchmaker generates a MatchProfile per game-mode, concurrent MatchFunction executions handling different MatchProfiles will both consider the same Ticket(Player) for their respective Match proposals. We will use the default Evaluator provided by Open Match to resolve conflicts in this scenario.

To generate a score (for evaluation) indicating the Match quality, we will introduce a new property on each Ticket indicating the time at which the Ticket entered matchmaking queue. The MatchFunction can then aggregate the wait times for all the Tickets in a Match to generate a score for that Match. Higher the score, longer the total wait times and higher the likelihood that the default Evaluator will pick the Match in case of a conflict.

Here are the changes we need to make at a high level to our components to achieve this:

The Game Frontend will generate Tickets with two game-mode preferences.
The Game Frontend will add a new SearchField indicating the time of entry in matchmaking queue.
The MatchFunction will generate the score for each Match to be used as evaluation criteria.

The below sections provide details of these changes:

Game Frontend

This tutorial provides a Game Frontend scaffold ($TUTORIALROOT/frontend) that generates a Ticket with the game-mode specified (as implemented for the basic Matchmaker). The mock Ticket generation is implemented in makeTicket() in $TUTORIALROOT/frontend/ticket.go.

The below snippet adds a new SearchField representing the time of entry in matchmaking queue:

func makeTicket() *pb.Ticket {
  ticket := &pb.Ticket{
    SearchFields: &pb.SearchFields{
      Tags: gameModes(),
      DoubleArgs: map[string]float64{
        "time.enterqueue": enterQueueTime(),
      },
    },
  }

  return ticket
}

func enterQueueTime() float64 {
  // Implement your logic to return a random time interval.
}

func gameModes() []string {
  modes := []string{"mode.demo", "mode.ctf", "mode.battleroyale", "mode.2v2"}
  // Implement your logic to return any two of the above game-modes randomly
}

Please update the Ticket creation logic in $TUTORIALROOT/frontend/ticket.go with the above snippet adding your logic to pick the random time and game-modes.

MatchFunction

Just because a Ticket has multiple game-modes, the MatchFunction will now consider Tickets for Match generation that other concurrent proposals use. Thus without any change to the core matchmaking logic here, we will generate overlapping results across MatchFunction executions.

To use default Evaluator, the MatchFunction needs to calculate a score for each Match and populate that in the DefaultEvaluationCriteria field. The code below demonstrates how to populate this field in the MatchFunction:


func makeMatches(p *pb.MatchProfile, poolTickets map[string][]*pb.Ticket) ([]*pb.Match, error) {
...
// Add score calculation logic here.
    matchScore := scoreCalculator(matchTickets)
    evaluationInput, err := ptypes.MarshalAny(&pb.DefaultEvaluationCriteria{
      Score: matchScore,
    })

    if err != nil {
      log.Printf("Failed to marshal DefaultEvaluationCriteria, got %w.", err)
      return nil, fmt.Errorf("Failed to marshal DefaultEvaluationCriteria, got %w", err)
    }

  ...
}

func scoreCalculator(tickets []*pb.Ticket) float64 {
  matchScore := 0.0
  // Add your logic to compute the score for this Match here
  return matchScore
}

Add the above snippet to the MatchFunction and populate the logic for score calculation. One strategy you may use is to aggregate the wait time for each Ticket and use that value as the score.

Build, Deploy, Run

Build and Push Container images

Now that you have customized these components, please run the below commands from $TUTORIALROOT to build new images and push them to your configured image registry.

docker build -t $REGISTRY/default-eval-tutorial-frontend frontend/
docker push $REGISTRY/default-eval-tutorial-frontend
docker build -t $REGISTRY/default-eval-tutorial-director director/
docker push $REGISTRY/default-eval-tutorial-director
docker build -t $REGISTRY/default-eval-tutorial-matchfunction matchfunction/
docker push $REGISTRY/default-eval-tutorial-matchfunction

Deploy and Run

Run the below command in the $TUTORIALROOT path to deploy the MatchFunction, Game Frontend and the Director to the default-eval-tutorial namespace:

sed "s|REGISTRY_PLACEHOLDER|$REGISTRY|g" matchmaker.yaml | kubectl apply -f -

Output

All the components in this tutorial simply log their progress to stdout. Thus to see the progress, run the below commands:

kubectl logs -n default-eval-tutorial pod/default-eval-tutorial-frontend
kubectl logs -n default-eval-tutorial pod/default-eval-tutorial-director
kubectl logs -n default-eval-tutorial pod/default-eval-tutorial-matchfunction

To check the logs from the default Evaluator, run the following commands:

# Locate the Evaluator pod(s) using the following command
kubectl get pods -n open-match

# Check the logs from the Evaluator pod
kubectl logs -n open-match <Evaluator Pod>

Cleanup

Run the below command to remove all the components of this tutorial:

kubectl delete namespace default-eval-tutorial

This will delete all the components deployed in this tutorial. Open Match core in open-match namespace can then be reused for other exercises but you will need to re-customize it.

What’s Next

There are scenarios where evaluating overlapping Matches may need context from both Matches and thus the logic may not be represented by a single score computed in isolation for a Match. In such cases, you can build your custom Evaluator and connect that to Open Match.

Docs: Build a Custom Evaluator

Mon, 01 Jan 0001 00:00:00 +0000

Objectives

The tutorial aims to explain how to :

Build your Custom Evaluator
Deploy, Run your custom Evaluator and configure Open Match core to use it

Prerequisites

Default Evaluator tutorial

It is highly recommended that you run the default Evaluator tutorial as it introduces the core concepts that this tutorial builds upon. After completion, please remember to cleanup the default Evaluator tutorial before proceeding.

Note

Given that all the other tutorials so far use the default Evaluator, the chances are, you already have the default Evaluator deployed in the open-match namespace. That is OK as at a later point, you will simply configure Open Match to point to your custom Evaluator in this tutorial’s namespace.

However, given that the default Evaluator in the open-match namespace will not be used for this tutorial, you may choose to delete it. Alternatively, you may delete the open-match namespace and Install Open Match Core without installing the default Evaluator.

Set up Image Registry

REGISTRY=[YOUR_REGISTRY_URL]

If using GKE, you can populate the image registry using the command below:

REGISTRY=gcr.io/$(gcloud config list --format 'value(core.project)')

Get the tutorial template

Make a local copy of the tutorials Folder. Checkout release-x.y branch（e.g. release-1.3, release-1.4） of the Open Match Git repository. Use tutorials/custom_evaluator of release-x.y branch as a working copy for all the instructions in this tutorial.

For convenience, set the following variable:

TUTORIALROOT=[SRCROOT]/tutorials/custom_evaluator

Note

This tutorial only focuses on building the custom Evaluator and so the working copy of Matchmaker components already has the changes to Frontend, Director that were made to work with the default Evaluator.

Create the tutorial namespace

Run this command to create a namespace custom-eval-tutorial in which all the components for this tutorial will be deployed.

kubectl create namespace custom-eval-tutorial

References

It is highly recommended that you read the Evaluator Guide to familiarize yourself with the lifecycle of a Match proposal through the synchronization and evaluation phases. Also, keep the API Reference handy to look up Open Match specific terminology used in this document. The tutorial also customizes the Open Match installation with the configuration of the custom Evaluator. The Customization Guide is a good reference for those changes.

A complete solution for this tutorial is in the folder tutorials/custom_evaluator/solution.

Custom Evaluator

Scenario Overview

For this tutorial, we will use the matchmaking scenario where a Player selects more than one game-mode to be considered for finding a Match. This will result in concurrent MatchFunction executions to generate overlapping results and hence require evaluation. We will build a custom Evaluator and configure Open Match to resolve conflicts using this Evaluator. We will also add the property on the Ticket indicating the time at which the Ticket entered matchmaking queue.

Note

Comparing to the default Evaluator, the Matchmaking function need not precompute any score to hint on Match quality. You will have full control over what Tickets decide a better Match with a custom evaluator.

Thus, the only change to the Matchmaker components from the default Evaluator tutorial is that we will not compute the score or the DefaultEvaluationCriteria in the Match Function. The core of the tutorial thus will focus on authoring the Evaluator and customizing Open Match with it.

Building the Evaluator

Please revisit the Evaluator overview section in the default Evaluator tutorial as it specifically calls out the scenario in which a custom Evaluator is needed.

This tutorial provides an Evaluator scaffold ($TUTORIALROOT/evaluator) as a starting point. The basis Evaluator server implementation in $TUTORIALROOT/evaluator/evaluate/server.go provides the following functionality:

Creates a gRPC service that listens on the configured port
Implements the Evaluate() interface that Open Match prescribes
Accepts a stream of proposals in its implementation for this interface and then calls into a simplified helper method.
Streams back results from the helper method to Open Match.

Below is the evaluate() helper method in $TUTORIALROOT/evaluator/evaluate/evaluator.go where the core evaluation logic should be implemented. At runtime, Open Match calls the Evaluate() method and streams the proposals for evaluation. This triggers the evaluate() method with a list of proposals. The evaluate() method should de-collide the proposals and return a list of results that Open Match will then return back to the Director.

func evaluate(proposals []*pb.Match) ([]string, error) {
  // Core evaluation logic
  return []string{}, nil
}

Please add your evaluation logic to this method. Here are some strategies for evaluation you may use when you detect Matches with overlapping Tickets:

Aggregate the wait time of the Tickets on the Match. The Match with higher aggregate wait time is selected and the rest are discarded.
Match with the Ticket with the longest wait time gets selected and others discarded.

These are just suggestions. You can also experiment with your own evaluation criteria for this scenario.

As a reference, you may check the implementation of the tutorial solution Evaluator that uses strategy 2.

Build and Push

Now that we have a custom Evaluator, please run the below commands in the $TUTORIALROOT to build and push the Evaluator to your configured image registry.

docker build -t $REGISTRY/custom-eval-tutorial-evaluator evaluator/
docker push $REGISTRY/custom-eval-tutorial-evaluator

Deploy and Customize

Run the below command in the $TUTORIALROOT path to deploy the custom Evaluator to the custom-eval-tutorial namespace:

sed "s|REGISTRY_PLACEHOLDER|$REGISTRY|g" evaluator/evaluator.yaml | kubectl apply -f -

We need to update the Open Match ConfigMap with details of the custom Evaluator. The Customization Guide provides some details on customizing your Open Match installation. The updated ConfigMap for the custom Evaluator is present in the customization.yaml. Run the below command in the $TUTORIALROOT path to customize Open Match installation:

kubectl apply -f customization.yaml --namespace open-match

Build, Deploy, Run Matchmaker

Build and Push Container images

Now that you have customized these components, please run the below commands from $TUTORIALROOT to build new images and push them to your configured image registry.

docker build -t $REGISTRY/custom-eval-tutorial-frontend frontend/
docker push $REGISTRY/custom-eval-tutorial-frontend
docker build -t $REGISTRY/custom-eval-tutorial-director director/
docker push $REGISTRY/custom-eval-tutorial-director
docker build -t $REGISTRY/custom-eval-tutorial-matchfunction matchfunction/
docker push $REGISTRY/custom-eval-tutorial-matchfunction

Deploy and Run

Run the below command in the $TUTORIALROOT path to deploy the MatchFunction, Game Frontend. the Director to the custom-eval-tutorial namespace:

sed "s|REGISTRY_PLACEHOLDER|$REGISTRY|g" matchmaker.yaml | kubectl apply -f -

Output

All the components in this tutorial simply log their progress to stdout. To see the progress, run the below commands:

kubectl logs -n custom-eval-tutorial pod/custom-eval-tutorial-frontend
kubectl logs -n custom-eval-tutorial pod/custom-eval-tutorial-director
kubectl logs -n custom-eval-tutorial pod/custom-eval-tutorial-matchfunction

To check the logs from the custom Evaluator, run the following commands:

kubectl logs -n custom-eval-tutorial pod/custom-eval-tutorial-evaluator

Cleanup

Run the below command to remove all the components of this tutorial:

kubectl delete namespace custom-eval-tutorial

This will delete all the components deployed in this tutorial. Open Match core in open-match namespace can then be reused for other exercises but you will need to re-customize it.