Разработка движка: порядок работы
Когда нужен исходный код, как проверить изменение и что включить в результат.
Разработка движка
Начинайте с воспроизводимой проблемы: какие действия дают неверный результат, что ожидалось и на каком бинарном файле это происходит. Правка исходников нужна, когда проблему нельзя решить кодом проекта, настройкой или расширением.
Выбрать уровень изменения
| Задача | Где работать |
|---|---|
| Логика игры, интерфейс, ресурсы | C# проекта и настройки. Пересборка движка не нужна. |
| Инструмент или интеграция через доступный API | Выбор API расширений. |
| Новая нативная функциональность отдельной библиотекой | Нативные расширения. |
| Изменение ядра, рендерера или встроенного редактора | Отдельная рабочая копия исходников и собственная сборка. |
Руководства на сайте не требуют редактирования ядра сами по себе. Не смешивайте изменение проекта, исправление документации и изменение движка в одном необъяснимом наборе файлов.
Рабочий порядок
- Сохраните воспроизведение на исходном бинарном файле. Запишите версию 1.0.0 и идентичность конкретной сборки: одной версии недостаточно, чтобы различать локальные бинарные файлы.
- Подготовьте отдельную рабочую копию и проверьте существующие изменения. Не очищайте чужие файлы и не подменяйте установленный Runtime пробной сборкой.
- Выберите target, архитектуру, точность и модули по инструкции сборки. Для Windows есть отдельная инструкция, для C# — этапы управляемой сборки.
- Сделайте минимальное изменение, устраняющее причину. Отделите переименование API от изменения поведения.
- Добавьте регрессию: C++-тесты движка проверяют внутреннюю логику; проект-пример проверяет работу через публичный API.
- Проверьте исходное воспроизведение на новом бинарном файле. Для изменения формата сохраните и снова загрузите данные; для публичного API проверьте используемый SDK и расширения; для экспорта запустите полученную игру.
- Обновите RU/EN-инструкцию, если изменились действие, имя, ограничение или результат.
Что считать результатом
Компиляция подтверждает сборку выбранной конфигурации. Она не подтверждает отсутствие регрессий, качество кадра или работоспособность экспорта. Чистый headless-тест также не доказывает работу настоящего GPU.
В результате укажите изменённые файлы, причину, конфигурацию сборки, фактически выполненные проверки, известные ограничения и место отдельного тестового бинарного файла. Если запуск отказал или фильтр не выбрал тесты, сохраните этот исход как отказ или неполную проверку. Не называйте его успешным тестированием.
Когда нужен только текст документации, достаточно сверки с исходниками и воспроизводимого примера: устанавливать новую сборку поверх рабочего движка для этого не требуется.