Shift Portal

Worked examples: reading the pages a game shows you

The glossary defines terms one at a time. These four examples run in the other direction: a page a player actually meets, taken apart line by line, with each term named as it appears.

Each example is written to be followed with the real page open in another tab. None of them reproduce a specific publisher's wording, because that wording changes; they describe the structure that nearly all of these pages share, which does not.

Example one: a registration page

A typical desktop game registration asks for four things and implies a fifth.

  1. Email address. This becomes the account identifier and the recovery route. A typo here is unrecoverable in a single opt-in flow, because the account is attached to an address nobody controls.
  2. Player name. Public inside the game, visible in match results and often on third-party statistics sites. Not the place for a real name or a handle reused elsewhere.
  3. Password. A passphrase of several unrelated words, used nowhere else, following the guidance the Australian Cyber Security Centre publishes for individuals.
  4. Date of birth. Used for age gating, and sometimes to decide which features are available. It is also the field most often filled in carelessly, and a wrong answer here can be awkward to correct later.
  5. The region, which is usually implied rather than asked. Many sign-up pages select a server region from the reader's location and show it in small type near the confirmation button. This is the decision that sets ping for the life of the account, and it is the one detail worth hunting for before submitting.

The tick boxes at the bottom repay reading. One accepts the terms and privacy policy, which is required. Any other box is usually marketing consent, and where the two are combined into a single box, that is worth noticing rather than accepting by reflex.

After submitting, a single opt-in account works immediately; a double opt-in account waits for a verification email. If neither happens, the address was probably mistyped.

Example two: a store page

Store pages in this category are built around one design decision: the price of an item is shown in a currency the reader has no feel for. Reading one in order defeats that.

  • Open the currency purchase screen first and calculate the AUD cost per token for each bundle. The arithmetic is in money and purchase terms.
  • Identify what the item is: an object, a chance at an object, a period of benefit, or access to a reward track.
  • Look for a renewal note. Periods of account benefit frequently renew automatically, and the cancellation control sits in account settings, not in the store.
  • Look for an expiry. Seasonal items lapse at the end of a season, and the page rarely separates permanent from temporary clearly.
  • Decide whether the leftover currency will genuinely be spent. If not, the bundle discount is not a discount.
  • Keep the confirmation email. Consumer guarantees under the Australian Consumer Law apply to digital purchases made in Australia, as the ACCC explains, and a claim is far easier to make with the transaction record in hand.

Example three: a system requirements page

System requirements are published as two columns, and the useful reading is of what sits between them. Minimum means the game starts. Recommended means the publisher considers the experience good, usually without saying at what resolution or frame rate. A machine that matches the recommended column exactly will still run differently depending on its storage, its background applications and its display.

The two lines most worth checking carefully are the operating system and the graphics card. The operating system line tells a reader whether the platform in front of them is supported at all — a desktop-only title has no mobile answer — and whether support means a native build or a compatibility layer. The graphics line, read together with the VRAM figure, predicts whether the symptom of an underpowered machine will be a low steady frame rate, which is playable, or stutter, which is not.

One practical note for Australian connections: check the installation size and the patch cadence before starting a download on a metered plan. A major update can be a significant fraction of a monthly allowance.

Two further lines on a requirements page repay a second look. The storage figure is the installed size, not the download size, and the two differ because the installer unpacks; a drive with exactly enough free space will fail partway through. The network note, where one exists, states whether a permanent connection is required, which for a multiplayer title it almost always is — meaning the game is unavailable when the connection is, and that no part of it is playable offline.

Example four: patch notes

Patch notes open with a marketing summary and then get useful. Skim past the season announcement to the list of changes, and read for four words: increased, reduced, removed and now. Those mark the substantive edits. A change to a vehicle's penetration or reload, described in one line, will alter how a match plays far more than the new cosmetic set described in four paragraphs above it.

For a returning player, reading the notes for the intervening updates in order is the fastest way back. Community summaries describe how a change felt; the notes describe what the change was, and only one of those is checkable.

Two habits make notes easier to use over time. Read them at the version the account is actually on, which the launcher shows, rather than at the latest version, since a client that has not been updated is playing by the older rules. And treat a change described as an adjustment with mild suspicion: it is the word publishers use for both a small correction and a substantial rebalance, and only the numbers beside it say which.

Where a change affects something a player has paid for — a premium vehicle, a seasonal track, a purchased benefit — the notes are also the record that matters if the matter is later raised with the publisher's support channel, so noting the date and version at the time costs nothing.

Putting the four together

The game this site uses as its recurring example is World of Tanks, because it exercises every page type above: a single opt-in registration, a store built on premium currency, a published requirements page for Windows, macOS and Linux, and regular patch notes attached to a tech tree. The vendor is the authority on all of its specifics, and its own site is where those specifics should be read.

Visit the World of Tanks website

What to watch out for on any of these pages

  • A price shown only in tokens until the final confirmation screen.
  • A registration that bundles marketing consent into the terms tick box.
  • A download link that does not lead to the publisher's own domain.
  • A requirements page with no date, next to a game that has had several major updates.
  • A classification claim made on a marketing page rather than in the Australian Classification Board database.