Skip to content

Latest commit

 

History

History
60 lines (50 loc) · 12.9 KB

CHANGELOG.md

File metadata and controls

60 lines (50 loc) · 12.9 KB
Raw

Release history

v0.4.0 (alpha)

Release notes

  • Thanks to completion of Issues #42 and #45, there is no longer a need to use the openmatch-base image when building components of Open Match. Each stand alone appliation now is self-contained in its Dockerfile and cloudbuild.yaml files, and builds have been substantially simplified. Note: The default Dockerfile and cloudbuild.yaml now tag their images with the version number, not dev, and the YAML files in the install directory now reflect this.
  • This paves the way for CI/CD in an upcoming version.
  • This paves the way for public images in an upcoming version!

v0.3.0 (alpha)

This update is focused on the Frontend API and Player Records, including more robust code for indexing, deindexing, reading, writing, and expiring player requests from Open Match state storage. All Frontend API function argument have changed, although many only slightly. Please join the Slack channel if you need help (Signup link)!

Release notes

  • The Frontend API calls have all be changed to reflect the fact that they operate on Players in state storage. To queue a game client, 'CreatePlayer' in Open Match, to get updates 'GetUpdates', and to stop matching, 'DeletePlayer'. The calls are now much more obviously related to how Open Match sees players: they are database records that it creates on demand, updates using MMFs and the Backend API, and deletes when the player is no longer looking for a match.
  • The Player record in state storage has changed to a more complete hash format, and it no longer makes sense to remove a player's assignment from the Frontend as a separate action to removing their record entirely. DeleteAssignment() has therefore been removed. Just use DeletePlayer instead; you'll always want the client to re-request matching with its latest attributes anyway.
  • There is now a module for indexing and deindexing players in state storage. This is a much more efficient, as well as being cleaner and more maintainable than the previous implementation which was hard-coded to index everything you passed in to the Frontend API at a specific JSON object depth.
    • This paves the way for dynamically choosing your indicies without restarting the matchmaker. This will be implemented if there is demand. Pull Requests are welcome!
    • Two internal timestamp-based indices have replaced the previous timestamp index. created is used to calculate how long a player has been waiting for a match, accessed is used to determine when a player needs to be expired out of state storage. Both are prefixed by the string OM_METADATA so it should be easy to spot them.
  • A call to the Frontend API GetUpdates() gRPC endpoint returns a stream of player messages. This is used to send updates to state storage for the Assignment, Status, and Error Player fields in near-realtime. It is the responsibility of the game client to disconnect from the stream when it has gotten the results it was waiting for!
  • Moved the rest of the gRPC messages into a shared messages.proto file.
  • Added documentation to Frontend API gRPC calls to the frontend.proto file.
  • Issue #41|PR #48 There is now a HA Redis install available in install/yaml/01-redis-failover.yaml. This would be used as a drop-in replacement for a single-instance Redis configuration in install/yaml/01-redis.yaml. The HA configuration requires that you install the Redis Operator (note: currently alpha, use at your own risk) in your Kubernetes cluster.
    • As part of this change, the kubernetes service name is now redis not redis-sentinel to denote that it is accessed using a standard Redis client.
  • Open Match uses a new feature of the go module logrus to include filenames and line numbers. If you have an older version in your local build environment, you may need to delete the module and go get github.com/sirupsen/logrus again. When building using the provided cloudbuild.yaml and Dockerfiles this is handled for you.
  • The program that was formerly in examples/frontendclient has been expanded and has been moved to the test directory under (test/cmd/frontendclient/)[test/cmd/frontendclient/].
  • The client load generator program has been moved from test/cmd/client to (test/cmd/clientloadgen/)[test/cmd/clientloadgen/] to better reflect what it does.
  • Issue #45 The process for moving the build files (Dockerfile and cloudbuild.yaml) for each component, example, and test program to their respective directories and out of the repository root has started but won't be completed until a future version.
  • Put some basic notes in the production guide
  • Added a basic roadmap

v0.2.0 (alpha)

This is a pretty large update. Custom MMFs or evaluators from 0.1.0 may need some tweaking to work with this version. Some Backend API function arguments have changed. Please join the Slack channel if you need help (Signup link)!

v0.2.0 focused on adding additional functionality to Backend API calls and on reducing the amount of boilerplate code required to make a custom Matchmaking Function. For this, a new internal API for use by MMFs called the Matchmaking Logic API (MMLogic API) has been added. Many of the core components and examples had to be updated to use the new Backend API arguments and the modules to support them, so we recommend you rebuild and redeploy all the components to use v0.2.0.

Release notes

  • MMLogic API is now available. Deploy it to kubernetes using the appropriate json file and check out the gRPC API specification to see how to use it. To write a client against this API, you'll need to compile the protobuf files to your language of choice. There is an associated cloudbuild.yaml file and Dockerfile for it in the root directory.
    • When using the MMLogic API to filter players into pools, it will attempt to report back the number of players that matched the filters and how long the filters took to query state storage.
    • An example MMF using it has been written in Python3. There is an associated cloudbuild.yaml file and Dockerfile for it in the root directory. By default the example backend client is now configured to use this MMF, so make sure you have it avaiable before you try to run the latest backend client.
    • An example MMF using it has been contributed by Ilya Hrankouski in PHP (thanks!). - The API specs have been split into separate files per API and the protobuf messages are in a separate file. Things were renamed slightly as a result, and you will need to update your API clients. The Frontend API hasn't had it's messages moved to the shared messages file yet, but this will happen in an upcoming version.
    • The example golang MMF has been updated to use the latest data schemas for MatchObjects, and renamed to manual-simple to denote that it is manually manipulating Redis, not using the MMLogic API.
    • The API specs have been split into separate files per API and the protobuf messages are in a separate file. Things were renamed slightly as a result, and you will need to update your API clients. The Frontend API hasn't had it's messages moved to the shared messages file yet, but this will happen in an upcoming version.
  • The message model for using the Backend API has changed slightly - for calls that make MatchObjects, the expectation is that you will provide a MatchObject with a few fields populated, and it will then be shuttled along through state storage to your MMF and back out again, with various processes 'filling in the blanks' of your MatchObject, which is then returned to your code calling the Backend API. Read thegRPC API specification for more information.
    • As part of this, compiled protobuf golang modules now live in the internal/pb directory. There's a handy bash script for compiling them from the api/protobuf-spec directory into this new internal/pb directory for development in your local golang environment if you need it.
    • As part of this Backend API message shift and the advent of the MMLogic API, 'player pools' and 'rosters' are now first-class data structures in MatchObjects for those who wish to use them. You can ignore them if you like, but if you want to use some of the MMLogic API calls to automate tasks for you - things like filtering a pool of players according attributes or adding all the players in your rosters to the ignorelist so other MMFs don't try to grab them - you'll need to put your data into the protobuf messages so Open Match knows how to read them. The sample backend client test profile JSONhas been updated to use this format if you want to see an example.
  • Rosters were formerly space-delimited lists of player IDs. They are now first-class repeated protobuf message fields in the Roster message format. That means that in most languages, you can access the roster as a list of players using your native language data structures (more info can be found in the guide for using protocol buffers in your langauge of choice). If you don't care about the new fields or the new functionality, you can just leave all the other fields but the player ID unset.
  • Open Match is transitioning to using protocol buffer messages as its internal data format. There is now a Redis state storage golang module for marshaling and unmarshaling MatchObject messages to and from Redis. It isn't very clean code right now but will get worked on for the next couple releases.
  • Ignorelists now exist, and have a Redis state storage golang module for CRUD access. Currently three ignorelists are defined in the config file with their respective parameters. These are implemented as Sorted Sets in Redis.
  • For those who only want to stand up Open Match and aren't interested in individually tweaking the required kubernetes resources, there are now three YAML files that can be used to install Redis, install Open Match, and (optionally) install Prometheus. You'll still need the sed instructions from the Developer Guide to substitute in the name of your Docker container registry.
  • A super-simple module has been created for doing instersections, unions, and differences of lists of player IDs. It lives in internal/set/set.go.

Roadmap

  • It has become clear from talking to multiple users that the software they write to talk to the Backend API needs a name. 'Backend API Client' is technically correct, but given how many APIs are in Open Match and the overwhelming use of 'Client' to refer to a Game Client in the industry, we're currently calling this a 'Director', as its primary purpose is to 'direct' which profiles are sent to the backend, and 'direct' the resulting MatchObjects to game servers. Further discussion / suggestions are welcome.
  • We'll be entering the design stage on longer-running MMFs before the end of the year. We'll get a proposal together and on the github repo as a request for comments, so please keep your eye out for that.
  • Match profiles providing multiple MMFs to run isn't planned anymore. Just send multiple copies of the profile with different MMFs specified via the backendapi.
  • Redis Sentinel will likely not be supported. Instead, replicated instances and HAProxy may be the HA solution of choice. There's an outstanding issue to investigate and implement if it fills our needs, feel free to contribute!

v0.1.0 (alpha)

Initial release.