Game Development Services
从现有工程评估到功能开发、商业化 SDK 接入和上线排查，先把目标、范围与责任边界说清楚，再进入实施。
Service Scope
下面是当前可沟通的主要方向。具体能否承接、周期和费用，需要结合工程状态、目标平台与交付要求评估。
服务 01
围绕明确的玩法目标和平台要求，评估原型、功能模块或可交付版本的开发范围。
适合谁
已有需求文档、参考产品或核心玩法，希望尽快形成可演示版本的团队。
可约定的交付物
服务 02
基于客户合法持有的现有工程，评估玩法调整、界面替换、内容扩展和平台适配。
适合谁
已有可运行源码，需要完成品牌替换、功能调整或发行前改造的团队。
可约定的交付物
服务 03
按目标平台和账号条件，评估广告、支付、登录、统计及第三方服务的工程接入。
适合谁
产品主体已经可运行，需要补齐上线、变现或运营基础能力的项目。
可约定的交付物
服务 04
针对加载、内存、包体、运行稳定性和发布阻塞问题，提供有边界的定位与优化建议。
适合谁
临近测试或发布，已经出现性能问题、构建故障或平台审核阻塞的项目。
可约定的交付物
Delivery Process
先形成共同认可的范围和验收方式，再按阶段推进。每一步都留下可以检查的结果。
01
确认目标平台、现有资料、核心问题和期望时间，判断是否适合合作。
02
拆分功能边界、交付物、验收方式、依赖条件和不包含内容，再给出周期与报价。
03
按里程碑提供可检查版本，及时确认方向，减少集中到最后才发现偏差的风险。
04
按约定标准验收并整理源码、配置和说明文档，明确质保与后续支持边界。
Quote Factors
同样叫“二次开发”，工程质量、平台数量和资源准备程度不同，工作量可能完全不同。
Service Boundary
清晰的边界既保护客户，也保护交付质量。以下内容会在正式合作前进一步写入报价或合同。
FAQ
先回答最常见的范围问题，仍不确定的部分可以在初次沟通中继续拆解。
可以先沟通方向，但正式报价前仍需要把核心玩法、目标平台、功能范围和验收标准整理到可评估程度。
可以先做技术评估。需要确认工程能否运行、Unity 与依赖版本、代码质量，以及客户是否拥有合法的修改和商业使用权。
默认以程序开发和工程集成为主。需要新增美术、动画、音频或文案时，会在报价中单独列明资源来源和费用。
交付范围内的问题修复和质保按合同约定执行；新增需求、环境变化、长期维护和运营支持需要另行报价。
Project Review
建议附上目标平台、现有工程状态、需要解决的问题、预算范围和期望时间。
