Don’t Start with a Publisher. Start with the Route You Can Actually Ship.

Begin a China plan with the route your game and team can ship. Publisher contacts matter later, once you know which work you need a partner to own.

This matters because “China publishing” is used for several different ambitions: localizing a worldwide Steam release, building a Chinese community, formally publishing in mainland China, placing a mobile game on mainland storefronts, or simply testing whether the game’s premise travels. If you request proposals before separating those outcomes, every vendor can answer a different question and still sound convincing.

Formal mainland publishing and platform requirements depend on the title, platform, entities, services, and current rules. Validate the selected route before committing a release date.

Describe the route from the player’s side

A route should describe what the player can do, not what the studio hopes to possess.

Too vague: “Get a Chinese publisher.”

Useful: “A Simplified Chinese player can understand and buy our global PC build on Steam, complete the game without mainland-specific services, and receive Chinese-language support.”

Also useful: “A player in mainland China can download and use the approved mobile game through named local channels, with the required local operator, account, payment, minor-protection, support, and data systems.”

Those sentences imply different builds, contracts, budgets, evidence, and dependencies. Choose the one that fits the product and still works when real people have to operate it.

Separate these four routes before comparing partners

Route A: learn before distributing

You test the Chinese name, capsule, description, trailer, genre vocabulary, and perhaps a narrow demo slice. You listen to target players and study whether they understand the same fantasy the original page promises.

Use this route while the game is early, global positioning is still moving, or the team lacks reliable Chinese-language support. Its output is evidence: comprehension findings, terminology, product risks, and a go/no-go decision. Keep public wording clear that this research does not announce a release.

The main advantage is reversibility. Changing a title treatment after ten structured tests is cheap. Changing it after a campaign, contract, and full localization is not.

Route B: serve Chinese-speaking players on the international PC release

The global Steam build includes accurate Simplified Chinese support. The store page is rebuilt for comprehension rather than machine-translated. The team runs at least one sustainable feedback and support route. Acquisition experiments use trackable links and modest budgets.

This can be a serious product strategy for a small PC studio. It can produce direct learning without pretending to be formal mainland publication. It also has limits: access and platform conditions are not controlled by the studio, local channels may not be available, and services designed only for overseas environments may create friction.

State those limits internally and in public wording. “Chinese-language release” is safer and more accurate than implying a locally published mainland edition when none exists.

Route C: formal mainland publication and operation

This route involves an eligible publishing structure and the current approval process for the title, followed by actual distribution and operation. The NPPA’s service guide for games authorized by overseas copyright holders describes applicant qualifications, materials, content review, correction, decisions, and publication of results. That should immediately tell an overseas indie that the route is more than submitting a translated executable.

Choose it when mainland distribution is central to the business case, the content and business model can be assessed early, the studio can deliver stable materials and revisions, and the economics still work after partner and operational costs. The partner relationship must cover more than submission: accounts, builds, localized assets, channel operations, support, data access, updates, incident response, and exit.

Route D: mainland mobile distribution

Mobile combines game publishing questions with platform records, application filing, SDKs, identity, payments, privacy, data, channel integration, and live operations. A port that is technically possible may still be commercially or operationally unsuitable.

Give mobile its own system and responsibility map; Route B plus an APK will not cover the work. If mobile is already peripheral to the product, a China plan rarely justifies creating a maintenance-heavy port.

Score the route you must operate

Score each plausible route from one to five on the following dimensions. The number is less important than the argument written beside it.

Dimension	The question behind the score
Player fit	Do target players understand and want this specific game?
Product fit	Can the build, content, business model, and service design support the route?
Team capacity	Can named people deliver localization, builds, support, partner management, and incidents?
Dependency load	How much of the route depends on approvals, platforms, counterparties, or infrastructure outside your control?
Reversibility	Can the studio learn and change direction before the expensive commitment?
Data access	Will the studio see enough trustworthy product and commercial evidence to improve?
Economics	After localization, partner share, operations, support, tax, and acquisition, can the route still make sense?
Exit quality	Can player obligations, accounts, assets, data, and support be handled cleanly if the route ends?

A high-reach route with low data access and no clean exit is not obviously better than a narrower route the studio controls. A formal route with a strong partner may be exactly right for one game and a distraction for another.

Buy evidence in order of cost

The cheapest risk is usually comprehension. Test the name, capsule, short description, and trailer. If target players cannot identify the genre or player verb, more distribution does not help.

Next comes product experience. Localize enough of the build to test onboarding, font, UI, input, tone, and the first meaningful decision. Do not localize fifty thousand words to discover that the core loop is being sold as the wrong kind of game.

Then test operations. Can the team answer Chinese-language support? Can reports reach engineering with context? Can it publish accurate patch notes? Can it distinguish a regional network symptom from a game-server failure? Run the loop at small scale.

Only after those layers produce evidence should expensive route work inherit their assumptions. Formal approval and distribution may still require early content and partner assessment, but assessment is different from announcing a launch.

Give partners a route brief they can answer

Send a concise route brief, not a generic pitch deck. It should contain:

• the exact route and player outcome;
• platform, genre, business model, online features, user-generated content, and update plan;
• current build state and localization state;
• rights ownership and known third-party restrictions;
• Chinese-language market evidence, with limits stated;
• the services you need the partner to own;
• the data, accounts, and decision access the studio requires;
• budget range, decision date, and kill conditions.

Ask the partner to respond with named deliverables. “Marketing support” should become a campaign brief, creator list criteria, asset calendar, reporting format, budget owner, and review cadence. “Handle approvals” should become applicant identity, prerequisite assessment, material list, build/content review process, revision flow, status evidence, and the parts no party can guarantee.

References help, but operational detail tells you how the relationship will work. Ask how a rejected asset, build mismatch, urgent crash, disputed translation, player-data request, or contract exit moves through their queue. Evaluate the machinery behind the presentation.

Assign the work that rarely appears in the pitch

Partnership conversations naturally dwell on launch moments. Push into the less glamorous work:

• Who owns and can recover each storefront, developer, social, advertising, analytics, and support account?
• Who can export raw or sufficiently detailed data?
• Who approves price, discount, release, update, rollback, shutdown, and public incident wording?
• Who pays for rework after a platform or review request?
• Which team handles nights, weekends, and holidays during launch?
• Who keeps localized source files, fonts, terminology, art, trailers, and patch notes?
• What happens to players, services, pages, and data when the relationship ends?

If the answer is “we will work it out together,” the work is not yet estimated.

Set exit conditions while the route is still optional

A kill condition is a fact that stops or narrows the route. Examples include a rights conflict, a required content change that breaks the game, loss of studio data access, unacceptable account ownership, a budget ceiling, no viable support owner, an SDK or infrastructure dependency the build cannot accept, or a schedule that misses the product’s global window.

Set these before partner outreach creates social momentum. Walking away from a route after a clear condition fails is management, not betrayal.

Also set a learning condition: what evidence would justify the next investment? It might be consistent store-page comprehension, strong demo completion among the intended genre audience, support volume the team can handle, or a partner proposal with verified operational detail. Avoid universal numerical thresholds copied from other games. The sample, genre, source, and cost matter.

The route test

You have a shippable route when you can point to:

1. one precise player outcome;
2. one distribution and operating structure;
3. a build scope that supports it;
4. named internal and external owners;
5. a list of approvals, platform records, accounts, and technical dependencies;
6. a support and incident loop;
7. evidence gates before spending increases;
8. stop and exit conditions.

At that point, “Which publisher?” becomes useful. You can compare each partner’s operation against a route you already understand.