Concepts
GreenMind Publishing has a small model: an org owns projects, a project has environments, and each environment gets every service the project has switched on. This page explains each piece.
Orgs
An org owns your projects. Every GreenMind account comes with one, its default org, where what the account makes goes unless it chooses another. There is no separate kind of org for studios: a studio's org is an org named for the studio, either the default org of somebody on the team, renamed and shared with more admins, or the default org of an account made with the studio's email address. Its admins can rename it, invite more admins and take anybody out, the person it came with included, as long as one admin is left. Somebody who leaves the default org their account came with, or hands it on to the studio, gets a fresh default org of their own.
Making more orgs than the one an account comes with is for supporters of GreenMind, who keep what they made if their support ends.
Orgs are GreenMind-wide: the same org can own your game here, your universes in OnlyLore and your bands in Ensemblis. They are managed on your GreenMind account, under Orgs: their name, their admins and their teams. The console only chooses which one you are working in, from the org switcher at the top of every page, where your default org is listed first and the rest by name.
Moving a project to another org
Somebody who is an admin of two orgs can move a project from one to the other, from the first org's Projects page on your GreenMind account. The new org's admins reach it at once and the old org's no longer do; people holding a role on the project themselves keep it. What the old org gave it cannot follow it, and the move says so before it is confirmed: roles its teams held on the project or its environments, its own roles held there, and invitation links offering those are taken away. The project's own teams move with it. A publishing project needs the new org to have accepted the agreements below and to have room on its plan; its environments, keys, players and usage go with it.
Plans and licences
Every org has a plan, Free to begin with, whose limits and your usage against them are on the console's Usage page. GreenMind sets an org's plan: ask for a higher one with Request a higher plan on that page, and for a GmCommon licence with Request a GmCommon licence on the org's GmCommon page. Each request reaches GreenMind's support team with your org, its plan and its usage, and the page shows that it is waiting until we answer. See Getting started.
An org is the party to the Publisher Terms, the Data Processing Addendum and the Acceptable Use Policy. An admin of the org accepts them on its behalf when they make its first project, or before that from the checklist on the org's home in the console, and the console records who accepted which revision and when. Somebody who may make projects but is not an admin is asked to have an admin do so first.
When an agreement is revised, an admin has to accept the new revision before the org can make new projects or environments. Your existing environments keep working in the meantime.
Members and roles
People join an org with their GreenMind account. What they may do is a role held somewhere: the role says what, and where says on what. A role is held on one project (and so every environment of it) or on one environment, by a person or by a team of the org.
The org's admins reach every project of every product the org owns. Who they are, and the org's teams, are managed on your GreenMind account, by invitation link or from the people already in the org.
Every project has two built-in roles:
| Role | What it allows where it is held |
|---|---|
admin |
Everything: making environments, switching services, server keys, sign-in settings, players, config, flags, tours, blog, staff and integrations |
support |
Working support requests and player reports, and seeing the project |
Your org's own roles
When neither fits, make a role of your own on the org's Roles page, on your GreenMind account beside its admins and teams: a name, a line saying what it is for, and the permissions it carries, such as config and feature flags for a level designer, or crash reports only for a QA lead. Permissions come in three kinds, by where they take effect:
| Kind | Takes effect when the role is held on | Examples |
|---|---|---|
| In environments | a project or an environment | Config, Feature flags, Players, Server keys, Crashes |
| In projects | a project | Project settings (environments and services) |
| In the org | the org, by one of its teams | Members, Roles, New projects, Usage, Licences |
A role can only be given where at least one of its permissions takes effect. One carrying only what is In the org (Members, Roles, New projects, Usage, Licences) is given to one of the org's teams, on the team's page on your GreenMind account. Changing a role changes it at once for everybody who holds it, and deleting it takes it from all of them and withdraws any invitation offering it.
Nobody puts into a role a permission they do not hold on the org themselves, and nobody gives or takes away more than they hold where it is held: making somebody an admin of a project takes being able to do everything in that project. Somebody who makes a project without being an admin of the org is made its admin.
Inviting and changing roles
A project's and an environment's People pages list who holds a role there, directly or through a team. People are invited by link: an invitation names a role and the project or environment, can be used once and expires after 14 days. Whoever opens the link while signed in can accept it, so send it only to the person it is for. Accepting an invitation never lowers a built-in role somebody already holds in that place. Nobody can change their own roles.
An environment's Staff page (see Other services) shows who may work in that environment, your own roles included.
Projects
A project is one game. It has a name and a key. The key:
- is 3 to 40 characters: lower-case letters, digits and hyphens, starting with a letter;
- is unique across the platform, so a key somebody else has used is refused;
- cannot be changed, because it is your production app key.
Its name can be changed at any time, by its admins, on the project page.
Review
GreenMind reviews every new project before it may use the platform. Until GreenMind approves it, the project can be set up but nothing of it reaches players: the API answers its credentials and sign-ins with 403 project-not-approved, and server keys, webhooks, Login with GreenMind apps, a custom dashboard, analytics and store credentials cannot be made, nor services switched on. If GreenMind does not approve a project, or later suspends it, the project page says why, and its admins can resubmit it for review once they have put it right. See Getting started.
Environments
An environment is a separate copy of everything your game uses: its own players, config, flags, tours, blog, support requests, staff and server keys. Nothing is shared between environments, so a test player can never appear in production and a config change in test never reaches your players.
Every project starts with production and test. You can add more, as many as your org's plan allows: three in all on the Free plan, six on Studio. See Environments and releases.
App keys
Each environment has an app key, the name the API and your builds use for it:
| Environment | App key |
|---|---|
production |
the project key: skyforge |
| any other | the project key, an underscore, the environment: skyforge_test, skyforge_staging |
Project and environment keys cannot contain underscores, so two projects can never produce the same app key.
You rarely send an app key yourself. Every credential names one environment, and the API acts in that one. The one exception is signing in with EOS, where the client has no credential yet and says which environment it is signing in to.
Services
A project switches services on and off in the console, and a switch applies to all of its environments. A request for a service the project has not switched on is refused with service-disabled. A change takes up to 30 seconds to reach the API.
| Service | What it gives you |
|---|---|
| Players | The player table, sign-in and player tokens. Always on |
| Sessions | Lobbies your players create, join and ready up in, started by your game server |
| Config | Values and tables your game reads at runtime and you change without a new build |
| Feature flags | Features switched on and off per environment |
| Legal documents | Your terms and policies, and which version each player has accepted |
| Tours | Guided introductions, each shown to a player once |
| Blog | News and patch notes, written in the console |
| Support | Support requests and player reports, worked by your support staff |
| Player saves | JSON your game saves per player, in slots you name |
| Crash reports | Unreal's crash reporter pointed at your environment, its crashes grouped into bugs |
| Analytics | Website analytics for the site your game links to, read signing in with GreenMind |
| Sign in with GreenMind | OAuth clients that let players sign in to your game or site with a GreenMind account |
| Commerce | Selling through Steam with your own keys: products, orders and entitlements |
| Realms | Seasons, or any span of time that starts every player with a fresh inventory |
| Inventory | Currencies with a ledger, and items, bought with currency or granted by your server |
| Cards | Card types and templates, the cards each player owns, and their decks |
| Progression | XP, skill trees whose nodes are bought with currency, and unlocks |
| Stats | Counters per player and per environment |
The last five are the game services.
Server keys and staff are part of every project and cannot be switched off.
The console and the API
You manage everything in the console at publishing.greenmindmedia.com. Your game and your game servers talk to the platform API:
https://api.greenmindmedia.com/api/platform/v1
The API is versioned in its path (v1); see Versioning for what may change within a version and how a change is announced. Every request and response is JSON, save a crash upload. The API reference describes every route, and the same API is described for programs at /openapi.json, an OpenAPI 3.1 document.
GreenMind's own games
GreenMind's games are projects on this platform like yours, owned by GreenMind's org, and use it the same way: players sign in through the platform API, the game reads its config and flags from it, and the services, limits and usage on these pages apply to them as to you. A new game of ours gets no private path, so what you read here is what it runs on. The one exception is the Dawn of Irkalla builds released before the platform, which keep the routes they shipped with.