元数视角 | 游戏研发与运营合同里，最贵的条款不是钱，是日期

收益分成从哪一天起算，通常是这类协议中对金额影响最大的条款。合同中一般表述为“自游戏正式商业化运营之日起分成”，看起来已经具备足够的可操作性。

问题在于，当前游戏行业内的产品基本采用多平台运营模式。微信小游戏、抖音、应用商店、自有官服——各平台的审核节奏、测试周期、开放充值的时间都不一样。于是同一句约定将面临两种解释：各平台分别起算，还是等所有版本的测试周期跑完再统一算。

事实上，我们可以把判定标准写成一个可验证的动作——是开启充值、通过平台审核，还是达到某个流水门槛？甚至乎多平台、多版本上线时，分别起算，还是以最后一个上线的版本为准。

这类合同常有“以运营方确认为准”“经运营方验收通过”的表述，但很少写清楚一件事：确认的形式是什么。

于是项目组的实际做法就成了默认规则——群里发一版，对方回一句“这版可以上”，就算通过了。赶档期的时候更常见：先上线，验收后补。

问题在于，一旦事后要回答“上线时这一版到底合不合格”，双方手里大多只有通讯平台的聊天记录，而聊天记录存在碎片化、措辞随意的特点。

比较可行的做法，是在合同里约定一个门槛：凡是影响交付时限或验收标准的变更，书面确认后同步调整或者限期提出异议；其余的小调整，定期汇总确认。有了这条线，“拖延”和“改需求”就不再一言难尽。

建筑项目改设计要出变更单，游戏项目改需求常常是群里一句话，而变更频率又极高——一个玩法数值、一个活动入口、一份美术资源，随时在调。到了交付节点对不上的时候，就必然出现一个死局：一方说“你拖延交付”，一方说“你临时改需求”。两边说的可能都是事实，但如果没有变更记录，谁也证明不了自己那部分是事实。

结合公开裁判文书中法院的普遍裁判观点，可参考下述做法：

研发方这边，看的是有没有一条说得清的基线——最初约定的范围是什么、后来每一次改了什么、改的时候有没有同步确认工期和费用。尤其是收到新增需求时，有没有及时回复工期是否顺延、费用是否增加，并且区分清楚“合同内的优化”和“新增功能”。这两件事没做，事后再说“是因为你改需求”，就很难被采信。

运营方这边，看的是提出变更时有没有同步确认对上线时间、分成和费用的影响，以及收到版本后有没有在约定期限内，以清单形式提出具体、可复现的问题以及保留相应的反馈记录。

停运常常被当成“关掉服务器”这一个动作。但从项目角度看，它和立项一样需要排期、分工和验收。

首先是过渡期从哪天起算。合同一般约定终止后设置不少于 60 天的过渡期，但“确定终止之日”是哪一天——发函之日、对方收到之日，还是双方达成合意之日？在实务争议里，这几个日子往往差得很远。

其次是公告的发布主体问题。游戏的使用群体为游戏玩家，与其他公共平台不同，游戏内的公告页面通常仅由掌握服务端的主体能够推送，且玩家若不登录，便无法查看公共渠道发布的公告。

所以停运配合义务这类后合同义务最好在合同里写成清单作为合同附件：谁发公告、在哪些渠道、几日内完成、数据以什么格式移交、补偿方案怎么定、一方不配合时如何处理。

这四个日期都不是签约时想不到的事项。恰恰相反——基本都想到了，谈过了，却没被记录下来。而后来真正把双方推上法庭的，正是那些当时看起来不值得为它停下的节点：一个未足够清楚的分成起算日，一次没落到纸面上的确认。

游戏行业的节奏很快，单个版本从需求到上线往往只有几周。但正因为快，法律才更需要与项目同步推进，在每个关键节点上，留下一个能被还原的、不被误读的痕迹。

吴汝梵

律师

执业领域：知识产权、商事争议解决

邮 箱：wurufan@yuanshulaw.com