“我们认识很多主播”“平台关系很好”“会做全球市场推广”都可能是真的。可这些话没法验收。发行合作一旦开始，团队交出去的不只是收入分成，还可能有商店控制权、定价权、玩家数据、品牌资产，以及未来几年的选择空间。
签约前把话问到底：这些资源什么时候用到你的游戏上，由谁负责，会交出什么；承诺没兑现，又怎么处理。
本文是商业协作检查框架，不构成法律意见。涉及权利归属、责任限制、跨境税务和争议解决时，应由熟悉对应法域和游戏业务的律师审阅最终文本。
把“支持”改成可以点收的东西
假设合同写着“发行商负责公关、市场营销和平台关系”。这句话覆盖面很大，却没有一项能在周五下午判断是否完成。
把它拆成表格：
| 承诺 | 负责人 | 交付物 | 截止时间 | 验收方式 |
|---|---|---|---|---|
| 商店页优化 | 具体岗位或姓名 | 文案、关键词、胶囊反馈稿 | 页面上线前若干周 | 双方书面确认版本 |
| 创作者推广 | 具体岗位或供应商 | 名单、联络记录、寄送与回应状态 | Demo／发售节点 | 可导出的执行记录 |
| 媒体公关 | 公关负责人 | 媒体库、新闻稿、采访安排与结果 | 明确节点 | 链接与联系人记录 |
| 平台活动 | 商务负责人 | 申报项目、状态与平台反馈 | 各活动截止日前 | 后台或邮件证据 |
表中的时间不必照搬，它只是结构示例。表里要把“努力”与“成果”拆开：发行商无法保证媒体刊登或平台推荐，但可以承诺按时备好材料、完成联络、同步状态并交回记录。无法控制的结果不能硬写保证，能够控制的动作也不该只写“尽合理努力”。
账号归谁，比密码在哪更重要
合作顺利时，账号安排像小事；合作破裂时，它决定游戏能不能继续卖。
逐个列出 Steamworks、主机平台、商店后台、域名、官网、社交媒体、Discord、邮件列表、广告账户、分析工具、客服系统和本地化平台。对每项写清：
- 法律上的账户主体是谁；
- 谁拥有最高管理员权限；
- 哪些人只需要日常操作权限；
- 双重验证与恢复方式由谁保管；
- 合作结束后几天内完成移交；
- 历史数据、素材和沟通记录以什么格式导出。
“开发者也有一个登录账号”并不等于拥有控制权。若应用挂在发行商主体下，要确认平台是否支持共享管理、转移需要哪些条件、发生争议时谁能发起。Steamworks 提供应用管理共享和应用转移机制，但具体资格与流程应以当时官方说明及合同安排为准，不能把“平台理论上可转”当作退出方案已经完成。
数据访问不能等月报
发行商给一份漂亮月报，和开发团队能访问原始经营数据，是两回事。至少区分这些层级：
- 商店访问、愿望单、销量、退款和地区分布；
- 营销链接、广告花费、素材版本和渠道结果；
- 创作者与媒体联络记录；
- 社区反馈、客服工单和已知问题；
- 平台付款、扣款、税费与可追溯结算明细。
合同应说明访问频率、延迟、粒度、保存期限和导出格式。若因平台限制只能由发行商查看，也要约定固定报告、合理查询权与审计方式。
某次营销效果差，还能复盘。合作一年后仍不知道钱花到哪、哪种语言的玩家在买、玩家为什么退款，才真的难补。没有数据，你既无法纠正发行商，也无法为下一款游戏积累判断。
钱要按瀑布顺序读
“五五分成”几乎没有单独意义。先画收入瀑布：平台和支付渠道扣除什么，退款与税费如何处理，可回收成本有哪些，谁批准新增成本，回收顺序如何，汇率和结算周期怎样，最后哪一层才进入分成。
特别留意范围模糊的“营销费用”“外部服务”“管理费”和“关联公司费用”。对小团队更实用的控制包括：预算上限、超额需书面同意、按项目列明、不得把其他项目成本摊入，以及定期提供凭证。
不要只模拟畅销。再算三个难看的情况：销量只达到保守预期的一半；发售延期六个月；合作提前终止。合同是否仍让团队付得起维护，答案比乐观模型更能暴露风险。
退出权需要三个零件
合同写了“重大违约时可终止”，不代表你就能顺利离开。退出机制至少要把触发、补救和移交三件事写明。
触发
触发条件应对应可观察事件，例如长期未结算、关键交付物在书面通知后仍未完成、破产或停止营业、未经同意转让核心权利、严重损害品牌、长期失联。也可以协商无过错终止，但通常会涉及通知期、未回收成本和补偿，必须算清。
补救
多数问题值得给合理补救期。合同要写通知送达方式、补救期限和判断完成的依据。不要让“双方友好协商”成为无限等待；也不要把轻微延迟直接升级为核爆式终止。
移交
终止生效后，商店应用、构建、源文件、域名、素材、商标使用、社区管理、客服记录、玩家数据、未付款项和第三方合同分别怎样处理？哪些许可立即停止，哪些为已售用户继续存在？谁通知平台和合作方？
列一份附件式移交清单，比正文里一句“双方应配合”可靠得多。清单还应有完成日期和未按期移交的后果。
谈判时别只听成功案例
向发行商索取两类联系人：合作顺利的团队，以及经历延期、销量不佳或最终分开的团队。后者更能说明对方如何面对坏消息。问题可以很直接：预算变化是否提前告知？数据能否自助查看？发售后多久还会回应？意见不同时谁做决定？退出时账号和素材是否按期移交？
也审视自己。开发方要承诺的里程碑、构建质量、沟通频率和素材交付同样应具体。只有发行方被验收、开发方保留无限弹性的合同，也不可能稳定执行。
签字前的最后一页
把整份协议压缩成一页运行摘要：谁拥有什么、谁决定什么、谁在何时交付什么、钱怎么走、数据在哪里、怎样结束。请没有参与谈判的核心成员照着摘要复述。
如果大家对商店账号归属、营销预算批准或终止后的应用去向给出不同答案，不要急着签。合同最有用的时候，常常不是上庭那天，而是双方关系正好时。它逼着大家趁早把最难的话说清楚。
合同与账号安排参考
参考资料
- Developer / Publisher AgreementsIGDA Developer Satisfaction Survey
- Application Management SharingSteamworks Documentation
- Transferring ApplicationsSteamworks Documentation