Planning a simultaneous global release: what simship really costs

At some point in planning a release, someone asks whether all the languages should go out on day one. The instinct is usually yes: one launch, one wave of coverage, every market invited at the same time. The industry has a word for that plan — simship, short for simultaneous shipment — and it is a genuinely strong strategy when a game can support it.

It is also the most expensive way to schedule a release, and the cost is not paid in money so much as in flexibility. Simship works by moving deadlines earlier, not by adding capacity. Every language you commit to on launch day pulls your text freeze months forward and puts your launch date at the mercy of the slowest language in the set.

This article is about making that trade deliberately: what simship actually buys, what it charges you, and how to decide — including how to change your mind late without moving the date.

What you are actually buying

The argument for simship is that attention does not distribute evenly over time. A launch concentrates it: press coverage, streamers, storefront front pages, algorithmic recommendation, word of mouth among players who all started at once. A market that arrives six months later gets a version of your game with none of that momentum around it, and the second launch rarely recreates the first.

There is a second, less discussed benefit: it is easier to keep a community together when everyone is playing the same content at the same time. Discussion, guides, videos, and fan work all cross language boundaries, and a player who cannot participate because their version does not exist yet often simply moves on. For a game with a strong social or competitive component, that matters more than the coverage does.

There is also a defensive reason. In markets where players want a language you have not shipped, someone else may fill the gap — an unofficial translation appears, or worse, an unauthorised build. You cannot really prevent that, but shipping the language yourself removes the demand it feeds on.

The cost is a much earlier text freeze

Here is the mechanic that decides everything else. Translation cannot start until text is stable, review cannot start until translation is done, and in-game checking cannot start until translated text is in a build. Those steps happen in sequence and each one takes calendar time. If they all have to finish before launch, then the launch date minus that whole chain is your text freeze date — and that date is much earlier than most teams expect.

The number of languages barely changes the length of that chain, since languages run in parallel. What it changes is the number of ways the chain can go wrong, and it changes the cost of every late edit. On a single-language release, rewording a line is a five-minute decision. Under simship, the same line is a change request that has to reach every translator, come back, be reviewed, and be re-checked in context — for each language, before a date that does not move.

The honest way to state the trade is this: simship does not ask you to work harder near the end. It asks you to finish your writing much earlier and then actually leave it alone. Teams that agree to simship without agreeing to that second half get the costs without the benefits.

Running translation against a game that is still changing

In practice no game stops changing months before launch, so simship is really a discipline for managing change rather than eliminating it. The workable version is batching: freeze and send text in sections as they are finished, rather than holding everything for one enormous handoff at the end. Each batch has its own freeze, and the game around it can keep moving.

This requires an exception process, because there will be exceptions. Decide in advance who can approve a change to frozen text, what information travels with it, and how it reaches every language. A change that goes to one translator through a direct message and never reaches the others is how a game ships with five languages saying one thing and a sixth saying something else.

Track state per batch per language rather than as a single overall percentage. 'Localization is 80 percent done' hides the situation where one language is finished and another has not started, which is exactly the situation that decides whether you make the date.

batch     | frozen  | ja    | fr    | de    | zh-Hans
----------|---------|-------|-------|-------|--------
prologue  | 03-14   | check | check | check | review
chapter-1 | 03-28   | check | review| trans | trans
chapter-2 | 04-11   | review| trans | trans | queued
ui-final  | 04-18   | trans | queued| queued| queued

Decide what gives: the date, the scope, or a language

Every release plan has three things that can move — the launch date, the amount of content, and the language list — and near the end you can usually only protect two. The failure mode is refusing to choose, which means all three quietly degrade at once: the date slips a little, content gets trimmed in a hurry, and the languages ship at whatever quality the remaining time allowed.

The choice worth making early is which one you will sacrifice, and the least damaging answer is often a language. Cutting a language from the launch set, weeks before launch, is a decision you can make cleanly: you remove it from the store metadata, you do not announce it, and you ship it later as a real update with its own small moment of attention. Nobody is disappointed by a language they were never promised.

The alternative — shipping a language that had two weeks less review than the others — is worse in a specific way. Players in that market do not experience it as a schedule compromise. They experience it as what your game is, in their language, and they say so in reviews that stay on the page long after you have fixed it.

This is why announcing your language list carries real weight. Once a market has been told a language is coming on day one, taking it back costs goodwill you cannot buy again. Announce the languages you are confident in, and let the others be a pleasant surprise.

When staggering is the better call

Simship is not automatically the more ambitious choice; sometimes it is just the more expensive one. A staggered release — your primary language first, others as they are ready — is genuinely better in several common situations.

• The game is still finding its final shape, and the text will keep changing through early access or a first-season update cycle
• You have no reliable way to check translated text in context yet, so a bigger launch just means more untested surface
• The extra languages are speculative rather than demand-driven, and a smaller launch lets you spend on the ones your data actually supports
• Your team is small enough that launch week itself needs everyone, and a multilingual launch multiplies support and community load at exactly that moment
• The content is heavily text-driven, so any schedule pressure lands directly on translation quality

A staggered launch still needs a plan

The weak version of staggering is 'we will add languages later', which usually means never, because after launch nobody owns it. The strong version treats each language addition as a small release with its own date, its own announcement, and its own checking pass — which also gives you a second and third moment of visibility instead of one.

Two things make later languages far cheaper than the first one: keeping your text exportable and your keys stable so a new language is a new column rather than a new project, and keeping notes on the questions your first translators asked, since the next ones will ask most of the same ones. If you handled the first language well, the fifth is mostly a scheduling problem.

Whichever route you choose, write the decision down with its reasoning. Six months from now, someone will ask why a language shipped later, and the answer should be a recorded trade-off rather than a vague memory of running out of time.