Other services

Beyond players, sessions, config, flags and player saves, a project can switch on the services below. Each is per environment, like everything else: managed on the environment's pages in the console, and reached by your game through the platform API, except Sign in with GreenMind and Analytics, which your game and site reach through their own standard protocols. Every route is in the API reference.

Legal documents

Your own terms and policies, which your players accept in your game: a terms of service, a privacy policy, an EULA. The text stays on your website. On the environment's Legal documents page you add each one with a key (terms, privacy), a title, its address and its current version, and say whether a player must accept it before playing. Managing them needs the Legal documents permission.

When the text changes, change the version. Every player is then asked again, because what they accepted was the old version. The record of which version each player accepted, and when, is kept, even after a document is deleted.

From your game:

GET /players/me/legal/outstanding with the player's token lists the required documents whose current version they have not accepted. Empty means they may play.
Show those documents, and when the player accepts, POST /players/me/legal/accept with the key and version of each one they saw. A version that is no longer current is refused, so a player never accepts text they were not shown. Accepting again what was accepted already changes nothing.
GET /legal/documents lists every document, required or not, for a menu that links to them.
Your server can check a player with GET /players/:playerId/legal before it lets them into a match.

A player's standing is also on their page in the console, opened from the Players page.

Tours

Guided introductions to parts of your game or site, each meant to be shown to a player once. You write them on the environment's Tours page and switch each on when it is ready.

Your game asks for them with GET /players/me/tours, which lists the switched-on tours with whether this player has finished each, and marks one finished with POST /players/me/tours/:tourId/complete, which answers 204. Finishing a tour twice is the same as finishing it once.

Blog

News and patch notes, written and published on the environment's Blog pages. A test blog is separate from the production one, so you can draft and throw away posts without them ever reaching players.

Your game or launcher reads published posts only: GET /blog/posts, newest first and a page at a time (pass the answer's next as cursor for the next page), narrowed with category or tag; GET /blog/posts/:slug for one post and what to read next; GET /blog/categories and GET /blog/tags for the ones that have a published post. Drafts and posts scheduled for later are not there until they are published.

Support

Support requests and player reports, worked on the environment's Support page by members with the admin or support role, and by the environment's staff.

Your game files them for the signed-in player:

POST /support/requests with a subject, a message and, if the player gives one, an email address to answer at. A player with no linked GreenMind account and no email address can be helped only in your game, so ask for one if you want to reply.
POST /support/reports when a player reports another player of the same environment, with the reported player's id, your own word for the reason (cheating, harassment, name), and anything they wrote. Staff see both players' ids and names, and look them up on the Players page.

Each answers 201 with the request's id in the inbox. A player can file ten of these an hour, requests and reports together; after that they are refused with 429 rate-limited until the hour has passed, and the Retry-After header says how many seconds that is.

Staff

Every environment has a Staff page, which cannot be switched off. It gives a GreenMind account the admin or support role on that one environment, without making them a member of your org: for example, a contractor who answers support in production and should see nothing else. Roles on the whole project are given on its People page, and the org's admins and teams are managed on your GreenMind account (see Concepts).

Audit log

Every change made by hand is recorded: who made it, what it was, where and when. That covers config, flags, tours, game data, legal documents, the blog, store credentials, server keys, player sign-in, Sign in with GreenMind, roles, teams and invitations, promotion, and what staff do to a player, a support request or a report. A change your game server makes with a server key is recorded too, with the key named as who made it: grants, take-backs, unlocks, deleting, renaming or signing out a player. Stat counters, a match reporting its progress and server sign-ins are not.

An environment's Audit log, in the Access group of its pages, shows that environment's changes to whoever administers it. A project's, opened from the project page, shows the project's and every environment's to whoever administers the project. Your org's admins see everything in the org on the Audit log tab of the org's page on your GreenMind account. A list narrows by kind of change, by who made it, by what it was made to and by day.

Nothing secret is kept: a key, a token or a password is recorded only as having changed. Records are kept for two years. When somebody deletes their GreenMind account, or you delete a player, the records keep what was done and forget who.

OAuth clients that let players sign in to your game or website with a GreenMind account, using standard OpenID Connect. The issuer is https://accounts.greenmindmedia.com, and its discovery document at /.well-known/openid-configuration names every endpoint, so any OpenID Connect library can be pointed at it.

You make and change clients on the environment's Sign in with GreenMind page, which needs the Sign in with GreenMind permission there. Making one also needs the project to have switched the service on. Each client belongs to the environment it was made in: your test clients sign players in to test and nothing else, and no other environment's page lists them. Pick how it signs players in when you make it:

Game: the device flow. Your game shows a QR code and a short code, the player confirms on their phone or computer, and your game polls for the result. No redirect URI.
Web, desktop or mobile app: authorization code with PKCE, back to a redirect URI you register. A public client, with no secret.
Website with a server: the same, but your server proves itself with a client secret when it exchanges the code. The secret is shown once, when the client is made; only a hash is kept, so a lost secret means deleting the client and making another.

Redirect URIs must be https. A web, desktop or mobile app may also return to a private-use scheme named after a domain you own, such as com.yourstudio.game:/oauth/callback. Plain http to localhost or 127.0.0.1 is accepted only in an environment other than production, for developing against a server on your own machine. After signing out, players are sent back to the root of each site your redirect URIs name.

A client's kind and client id are fixed when it is made; its name and redirect URIs can be changed later. Deleting one stops it signing anybody in at once.

Your clients can ask for openid, profile, offline_access and gm:user. The ID token carries the player's GreenMind account id as sub and, with profile, their public name as name. It never carries an email address, even when email is asked for.

Every player is asked to agree the first time they sign in to one of your clients, on a screen that names your org and project and says the app is not made by GreenMind. Only GreenMind's own apps skip that screen.

This is separate from Players: a GreenMind sign-in identifies a GreenMind account, and does not by itself make a player in your environment.

Analytics

Visits to your website, counted by the same analytics GreenMind's own sites use, in a dashboard of the environment's own. Switch Analytics on for the project, set the environment's website address on its overview, then set it up on the environment's Analytics page. Setting it up is for the environment's admins; reading it needs the Analytics permission.

Setting up makes the environment's website in analytics, named after your project and environment, and shows the snippet to put in the head of every page of your site:

<script
  defer
  src="https://analytics.greenmindmedia.com/script.js"
  data-website-id="<your website id>"
  data-exclude-search="true"
></script>

Visits appear within a minute. Query strings are left out of what is counted, since they so often carry tokens and codes. If your website moves, change its address on the overview and press Update name and address on the Analytics page; the website id stays the same, so nothing on your site changes.

To read it, choose Open analytics and sign in with GreenMind. You see the websites of the environments you hold the Analytics permission on, and nothing else: not another environment of yours you were not given, and not anybody else's. Your people can read it but not change or delete it.

The tracker sets no cookies, but it records visits, so load it only once a visitor agrees where the law you answer to asks for that, and name it in your privacy policy. Visits are kept for 24 months, then deleted.

Commerce

Selling in your game through Steam, with your own keys, is described in Commerce.