It is common in co-publishing models for a game publisher to commission a developer to custom-develop a game and authorize its commercial operation. However, the performance process in such cooperative game development is filled with uncertainties—from early-stage delivery quality and scheduling issues, to mid-stage commercial release and promotion, potential major operational incidents, and finally to later-stage data performance, termination, and server shutdown—each of which may give rise to disputes.
In light of this, we believe that a publishing agency agreement should, to the greatest extent possible, include detailed provisions on rights and responsibilities, to ensure timely launch, quality operation, and transparent revenue settlement. This is the shared objective of both the publisher and the developer.
This series of articles aims to clarify key issues in both the contractual negotiation and performance phases of game development cooperation, by drawing on our legal practice experience and judicial case precedents, in order to assist both publishers and developers in achieving their respective contracting goals.
(I) How Should Acceptance Standards Be Defined?
During the acceptance phase, a common dispute is as follows:
When the delivery milestone arrives, the publisher expresses dissatisfaction with the delivered game product and repeatedly demands revisions, while the developer believes that the submitted version meets the agreed criteria and accuses the publisher of intentional delay and refusal to pay development fees or advance revenue shares. Disagreements arise over whether delivery has been completed and whether the version conforms to agreed standards, ultimately leading to litigation.
This article summarizes several key issues for consideration by both developers and publishers.
First, the parties should explicitly define who is responsible for setting the acceptance standards and how those standards are formulated.
The parties may attach detailed indicators as annexes to the development contract at the time of signing.
If comprehensive criteria cannot be agreed upon initially, vague expressions such as “meeting publisher standards” or “to the publisher’s satisfaction” should be avoided.
Instead, the parties should first document the agreed-upon specifics in the contract to lock in basic requirements, and then stipulate that the publisher will subsequently lead in formulating more detailed documents, with the developer’s cooperation.
On this point, courts tend to apply strict scrutiny and impose higher obligations on the publisher.
In case No. (2019) SPC Civil Final 433, the Supreme People’s Court held that WeChat chat logs and planning documents submitted by the publisher were insufficient as evidence of acceptance standards.
Where acceptance standards are lacking, courts tend to find that the publisher bears the obligation to submit such standards, as it is the commissioning party and therefore should provide specific requirements to the developer.
Second, acceptance indicators should be as objective and quantifiable as possible, and typically cover the following dimensions:
1. Technical Quality
(1) The parties should list potential game bugs and classify their severity. Common categories include: server stability, data security, game ecosystem balance, system functionality errors, operational failures, payment/recharge issues, event anomalies, version updates, reward distribution, compatibility issues, etc.
(2) These dimensions should be translated into measurable indicators. For example, technical stability on mainstream devices can be defined based on whether issues such as frame drops, crashes, black screens, or system freezes occur. Server performance may be assessed by specifying minimum continuous uptime requirements.
2. Functional Content
(1) The duration of playable content (e.g., sufficient to support at least 60 days of gameplay for an average player);
(2) Based on game type, the contract should include detailed specifications on characters, controls, rules, scenes, UI, art design, music, events, storyline, monetization systems, etc.
3. Data Testing
(1) Device model compatibility requirements for testing;
(2) Version requirements for test builds;
(3) Metrics to be tested at each delivery stage, including: Day 1 Retention, Day 3 Retention, Weekly Retention, Monthly Retention, Average Revenue Per Paying User (ARPPU), Daily Active Users (DAU), Monthly Active Users (MAU), payment conversion rate, Lifetime Value (LTV), etc.
(4) Specification of whether results from the developer, publisher, or a third-party platform shall be deemed conclusive.
Special Considerations Based on Legal Practice
Contracts should reserve space for dynamic updates to acceptance standards. The parties may agree that any additional standards confirmed in stamped written documents shall prevail as supplementary terms.
Care should be given to the weighting of evaluation metrics. Even if acceptance standards are clearly defined, in practice developers often fail to fully meet them, yet the game can still be commercially released and generate revenue.
In such situations, courts do not automatically find that the developer’s breach has frustrated the purpose of the contract.
Instead, they consider the facts of the case, industry norms, and the publisher’s conduct.
For instance, in case No. (2020) Jing 73 Minchu 444, the Beijing IP Court held that whether the deliverable satisfies functional requirements is the essence of software acceptance.
If the developer submits a runnable program for inspection, the publisher cannot use failure to deliver source code as a valid defense for rejecting acceptance.
The actual implementation of acceptance standards should be actively pursued.
During the product acceptance process, if the developer delays performance or the publisher is dissatisfied, both parties should issue timely notices, communicate in good faith, and retain evidence.
In most cases, fulfillment of acceptance conditions depends on mutual cooperation. The party refusing to cooperate may bear liability for resulting losses.
For example, in case No. (2022) SPC Civil Final 1060, the developer urged the publisher to confirm testing times and other acceptance duties, but the publisher failed to respond.
The Court held that the developer’s failure to deliver the final product was attributable to the publisher.
Finally, where no acceptance criteria are stipulated or where such terms are ambiguous, courts will refer to the actual performance of the parties and assign legal liability based on the parties’ true intent and fault.
Under such circumstances, both the publisher and the developer face a passive position and bear a heavier burden of proof.
Accordingly, both parties should preemptively mitigate risk and not rush into signing loosely drafted contracts for the sake of expediency.