Game Plans

What a game plan is

A game plan is the sizing behind one game product: the memory, disk, CPU, player slots, ports, addressing and backup allowance a customer buys. It is what provisioning actually builds from. Nothing a customer sends with an order can change any of it — the plan and the product are the only authorities on size.

Where a plan is edited

On the product that sells it. There is no separate Plans page in the game module; an old link to one lands on Products.

To reach it: open Products, create or edit a product whose category type is Game Servers, and look for the Game server configuration section. That section only appears for a game category — see Product Categories for how a category's type is set.

The section holds two different things and keeping them apart matters:

• The plan — memory, swap, CPU, disk, disk priority, process ceiling, player slots, extra ports, addressing, backup ceilings and the catalogue entry. Every product owns its plan; the same editor is embedded here and saved with the product.
• The product's own game fields — whether the customer may pick the game at checkout, a forced game for this product, and the extra ports this product adds on top of the plan's. These have no equivalent on a plan.

The section subtitle states the rule that governs both: these values are what provisioning builds from, and nothing a customer sends with an order can change them.

Before you fill anything in

A banner appears at the top of the section when your machines cannot build what this product sells. It comes in three forms, and each names a different fix:

• No game node exists yet, so nothing can build this product.
• No game node is reporting, so nothing can build this product.
• The node runtime is forced into stub mode, so nothing is being built.

Its severity follows the product's own Active switch. On an inactive product it is a note: configure and price it now, and leave it inactive until a machine is online. On an active product it is a warning, and the wording is blunt — an order placed now invoices, takes payment and settles without a server ever being created. Either add a game node, or deactivate the product until your machines can build one.

The product's own game fields

Product-level game fields

Field	What it does
Force this game	Overrides the plan's catalogue entry for this product only. Leave it on Whatever the plan sells unless one plan is deliberately sold as several games.
Extra ports for this product	Added on top of the plan's extra ports, 0–32. Use it when one product bundles a voice server or a map viewer the plan does not.
Let the customer pick the game	Off by default. With it off, a game sent with an order is ignored and logged rather than honoured.

Retired catalogue entries still appear in the game selector, marked as retired, so a product that already sells one keeps showing which game it sells.

The plan fields

In the product modal the plan shows as a one-line summary with an Edit plan button; the button opens the full editor. The summary is built from the draft, so an unsaved edit reads as one. The plan's name is taken from the product's name — there is no second Name box to fill in.

Game plan fields

Field	What it does
Catalogue entry	Pins the plan to one game, or leave it on Any entry the product allows and let the product decide. See Game Catalogue.
Description	Free text for your own reference.
Memory in MB	The container's hard memory limit. Must be greater than zero, and must not be below the game's own minimum.
Swap in MB	Swap on top of memory. Zero is the safe default.
Disk in MB	Enforced by the kernel as a filesystem quota, not a periodic size check. Must be greater than zero.
CPU percent	100 is one full core; 50 is half a core. Must be greater than zero.
Player slots	Written into the game's own configuration and exported to it. Leave blank for a game that has no slot concept.
Extra ports	On top of the main connection port, 0–32. A query listener and a remote-console listener each need one.
Disk priority	Relative share of disk throughput when machines are busy, 10–1000. 500 is the neutral middle.
Process ceiling	How many processes the container may hold open, so one server cannot exhaust a machine. Defaults to 512.
Addressing	Shared address with allocated ports or Dedicated address per server. Shared addressing is what makes a low price tier possible; a dedicated address costs one public address per server.
Backups kept	How many restore points the plan includes. Zero means backups are not part of this plan.
Backup size ceiling in MB	Total space the backups may occupy. Counting backups alone is not enough — ten copies of a large install is a great deal of storage nobody sold. Leave blank for no ceiling; a company-wide default can be set in Game Settings.
Available for sale	Deactivating stops new builds from this plan without losing the history. An order that reaches a deactivated plan is refused by name.

The memory floor

Under the fields, the editor prints Minimum memory for this game for the entry the plan points at. Go below it and the line turns red with an explanation: the plan is below the minimum memory its game needs to start, so a server built from it could only fail to boot. The save is blocked while that is true, and a banner on the section says the plan cannot be saved yet.

This is the same number the provisioner uses. If it were ever bypassed, the failure would land after the customer had paid.

Validation

Memory, disk and CPU must each be greater than zero. Disk priority must be between 10 and 1000. Extra ports must be between 0 and 32. A plan the platform will reject blocks the whole product save, because the plan is written before the product row is.

When a plan is copied instead of edited

If the plan this product points at is owned by another product, or is sold by more than one, a warning appears before you type: saving will copy the plan and point this product at the copy. Nothing another product sells is changed — including which game it installs. That matters more for games than for virtual machines, because a game plan carries the game itself: silently writing a shared plan would not merely resize another tier, it could change which game that tier's next order installs.

How a plan binds to a node

It does not, and that is deliberate. There is no node picker and no location restriction on a game plan. A plan may use any machine that can take it, and the placement rules do the rest:

1. If the customer chose a location at checkout, only machines in that location are considered.
2. Each remaining machine is judged against this plan — is it active, is it accepting new servers, has it enough sellable memory, is it under its server ceiling, has it free ports, can it enforce a disk quota, and for a dedicated-address plan does it have an address to give.
3. The survivors are ranked by genuinely free memory and the emptiest one wins.

Every rejected machine keeps its reason, which is what the placement preview shows you.

Placement preview

Once a product has a saved plan, a Placement preview button appears in the section. It is a read-only dry run that resolves the plan against your machines and runs the same admission check a real order runs.

It opens with the sizing being placed — memory, disk, CPU and addressing, echoed back from the server so you are looking at what was actually judged rather than at unsaved fields. Then a count of eligible machines out of candidates, and a card per machine marked Can take this plan or Cannot take this plan, with every blocking reason listed rather than only the first, and warnings listed separately in a different colour. A warning is not a refusal.

Ineligible machines are shown rather than hidden. “This plan can go nowhere” and “this plan can go to four machines, all of which are draining” look identical once the failures are hidden, and only one of them is an emergency.

Where a plan resolves to nothing at all, it says so. The refusal and warning texts are listed in Game Nodes.

Tip: Open the preview whenever an order will not build. It names, per machine, exactly what is in the way — which is usually a drained machine, an unseeded port pool, or storage that cannot enforce a quota.

Pricing a game product

The plan carries no money. Price is set on the product like any other — see Products.

Billing cycles

Game products sell on any cycle the product offers, including hourly. Two settings on the Billing settings tab exist specifically for hourly game servers, under a Game servers heading in the hourly section:

• Bill stopped game servers — on by default. Keep charging an hourly game server while the customer has it stopped. Switched off, a stopped server is not metered, is never suspended for low credit, and gets no low-credit warning; the world stays on disk.
• Monthly price cap — off by default. Never charge an hourly service more than its product's monthly price within a calendar month. Once reached, the rest of the month is free and the service cannot be suspended for running out of credit.

Locations

A game product can list the locations a customer may choose from, on the product's delivery section — the same Available Locations picker other product types use. The location the customer picks narrows placement to machines in that location.

There is no per-location surcharge for game products. The Location Pricing panel is offered for virtual-machine and plugin-provisioned products; a game product prices one figure per cycle. To charge more for a premium site, sell it as its own product.

Add-ons

Everything a customer can buy on top of their plan is a product option — see Product Options. The game module can grant these as real resources, and a catalogue of them can be seeded for you from Game Settings → Storefront. The seeded set is:

Seeded game add-ons

Group	Add-ons
Resources	Extra memory in 1 GB and 4 GB steps, extra storage in 20 GB and 50 GB steps, and an extra CPU core. Memory, storage and CPU apply live.
Players	Player slots in steps of 10, 25 and 50. Slots take effect on the next restart.
Network	One extra port, five extra ports, and a dedicated address.
Backups	Five and fifteen extra backup slots.
Support	Priority support, extended support, a fully managed server and a one-off setup service. These bill and renew and change nothing on the server.

Each resource add-on has a per-server limit, and the module refuses a purchase it cannot honour with a message the customer can act on: the add-on is already active, it has reached its per-server limit, a server may hold at most 32 extra ports, the machine has no spare address to dedicate, that many slots needs more memory than the server has (add memory first), or the change would leave the server below the memory its game needs to start.

Slots are deliberately not sold up to the technical ceiling. Each game publishes how many slots a gigabyte of memory can carry, and seeded plans ship below it, so there is headroom left to sell and the refusal a customer eventually meets names the next upsell rather than being a dead end. The company-wide fallback ceiling is the Player slots per GB setting.

Whether a server restarts by itself to apply an add-on that needs one is the Restart automatically to apply an add-on setting, off by default — the safer choice for a server with people on it.

Upgrade paths

Which tiers a customer may move to, and in what order, is set on the product's Upgrade Paths tab. A plan change is a resize: memory, disk, CPU, slots and ports move. It cannot change the game. Moving a server to a plan that runs a different game or version is refused on both sides, because that is a reinstall of the server's content and not a resize — the customer is told to order it as a new server.

Seeding a whole storefront

Rather than building products one at a time, Game Settings → Storefront can create them in bulk: one category, one product per memory tier of every title in your catalogue, the plan behind each, and the upgrade paths between them. The tiers are multiples of each game's own minimum memory, so every tier is legal for the game it belongs to, and each tier's disk and slots scale with it. A price per gigabyte per month drives the whole ladder, with quarterly and annual derived from it.

Products are created inactive, deliberately. After seeding, everything is edited on the product itself and none of it needs a re-seed. The seeds are covered in full in Game Settings.

Common problems

• The plan section will not save. A field is out of range or the plan is under the game's minimum memory. The offending field is outlined and the memory line turns red.
• An order was refused: the product names no game plan. Point the product at a live plan and retry the deployment.
• An order was refused: the plan has been deactivated. Turn Available for sale back on, or move the product to a live plan.
• An order was refused for capacity or ports. Open the placement preview; it names which machine failed and why.
• Editing one product changed another. It did not — but check the copy warning. A plan shared by several products is copied on save, so the tier you edited now has its own plan and the others are untouched.
• The plan is not shown and a warning says the list could not be read. The plan is left exactly as it is on save. Check that game hosting is on for your company and that your account holds the game permission.

Related: Game Hosting Overview, Game Catalogue, Game Nodes, Game Servers, Products, Product Options.