Разработка игры силами сторонней студии (аутсорсинг) или заказная разработка (Work for Hire) — стандартная практика в индустрии. Однако именно на стыке «Заказчик — Разработчик» возникает наибольшее количество судебных споров. Договор на разработку игры должен быть максимально детализированным документом, устраняющим любые двусмысленности в техническом задании, сроках и порядке приемки работ. Устные договоренности в GameDev не работают: если функционал не описан в контракте, юридически исполнитель не обязан его реализовывать.
Согласно статье 1296 ГК РФ, по умолчанию исключительные права на программу для ЭВМ, созданную по заказу, принадлежат заказчику, если договором не предусмотрено иное. Однако это правило имеет массу исключений, особенно если в разработке используются «фоновые технологии» (Background IP) разработчика, такие как собственные движки или библиотеки.
Техническое задание как основа договора
Юридическая прочность договора на разработку напрямую зависит от качества приложений к нему. Мы настаиваем на том, чтобы неотъемлемой частью контракта являлись:
- Гейм-дизайн документ (GDD). Подробное описание механик, сюжета и контента.
- Техническое задание (ТЗ). Требования к стеку технологий, производительности, платформенной совместимости.
- Roadmap и Milestones. Календарный план с четкими этапами (Вертикальный срез, Альфа, Бета, Голд-мастер).
В договоре необходимо предусмотреть процедуру «Change Request» — внесения изменений в ТЗ. Разработка игр — итеративный процесс, и требования могут меняться. Без формализованной процедуры любое отступление от ТЗ может быть расценено как нарушение договора, либо привести к бесконечному раздуванию бюджета (feature creep) за счет заказчика.
Модели оплаты: Fixed Price vs Time & Material
Выбор финансовой модели определяет распределение рисков. Мы помогаем адаптировать договор под выбранную схему:
- Fixed Price (Фиксированная цена). Риски на стороне разработчика. Если он не уложится в бюджет, доделывать придется за свой счет. В таком договоре критически важна четкая приемка.
- Time & Material (Время и материалы). Оплата за отработанные часы. Риски на стороне заказчика. Здесь мы прописываем жесткие требования к отчетности (тайм-шиты, доступ к трекерам задач типа Jira) и квалификации специалистов (грейды), чтобы заказчик не платил за обучение джуниоров по ставке сеньоров.
Интеллектуальная собственность и Open Source
Самый опасный пункт договора на разработку игры — это права на IP. Если разработчик использует в проекте Open Source компоненты с вирусными лицензиями (GPL), это может обязать заказчика раскрыть исходный код всей игры. Мы включаем в договоры гарантии «лицензионной чистоты» (IP Warranty) и обязанность исполнителя согласовывать использование любых сторонних библиотек.
Также важно урегулировать права на «Background IP». Если студия-аутсорсер использует свой проприетарный код (например, сетевой модуль), заказчик должен получить на него широкую, безотзывную, безвозмездную лицензию, иначе после релиза он окажется на «крючке» у разработчика.
- Юридическая помощь в решении проблемных ситуаций
- Консультации юриста онлайн проводятся Пн-Пт, с 10:00 до 18:00 часов
Приемка работ и гарантийный период
Процедура сдачи-приемки (Acceptance) — это момент истины. Мы формулируем критерии приемки (Acceptance Criteria) так, чтобы исключить субъективизм («мне не нравится, как прыгает персонаж»). Приемка должна базироваться на соответствии ТЗ и отсутствии критических багов (Blocker, Critical, Major).
Договор обязательно должен содержать гарантийный период (Warranty Period), обычно 6–12 месяцев после релиза, в течение которого разработчик обязан бесплатно исправлять выявленные ошибки. Это защищает заказчика от ситуации, когда баги всплывают только под нагрузкой реальных игроков (на этапе Live Ops).