Я часто при обсуждении новой функциональности задаю банальный вопрос, ответ на который оказывается не таким очевидным, как кажется:
Что именно мы пытаемся проверить?
Иногда оказывается, что мы тестируем не свою систему, а функциональность платформы, сторонней библиотеки или фреймворка.
В контексте разработки игр полезно понимать, что команда не увлеклась и не начала тестировать, например, сам Unity.
С собственным движком ситуация становится интереснее.
Потому что движок и игра далеко не всегда остаются независимыми системами. Грубо говоря, бывают ситуации, когда одно не может жить без другого.
В какой-то момент оказывается, что часть игровых тестов на самом деле проверяет не игру, а платформу под ней.
Именно это наблюдение заставило меня по-другому посмотреть на вопрос собственных игровых движков.
Когда движок становится частью игры
В идеальном мире движок и игра должны быть двумя разными системами.
Мы можем развивать игру независимо от движка, а движок независимо от конкретной игры.
На практике так получается не всегда.
Мне доводилось сталкиваться с проектами, где проверка работы движка происходила через игру.
Тогда:
- дефекты движка проявляются как дефекты игры;
- игровые тесты начинают выполнять роль тестов платформы;
- регрессия становится дороже;
- локализовать проблему становится сложнее.
В результате новые версии движка начинают выпускаться сложно и болезненно. Это может требовать большого вовлечения команды игры, чтобы корректно всё интегрировать.
Часто это означает, что разделение между платформой и игрой не было заложено на уровне архитектуры. В результате снижается тестируемость как движка, так и самой игры.
Проблема не в runtime
Когда обсуждают движки, разговор обычно идет про:
- графику;
- производительность;
- физику;
- сетевой код.
Но для команды это далеко не единственные вопросы, о которых стоит думать.
Не менее важен другой вопрос:
Насколько удобно будет работать с этой системой через несколько лет?
Современные движки включают в себя не только runtime, но и целую экосистему:
- инструменты разработки;
- профайлеры;
- средства диагностики;
- документацию;
- интеграцию с CI/CD;
- тестовые фреймворки.
Например, Unity предоставляет Unity Test Framework с поддержкой Edit Mode и Play Mode тестов. Unreal тоже имеет собственный набор инструментов.
Когда в компании есть внутренний движок, далеко не всегда всё это существует и поддерживается на сопоставимом уровне. И это неудивительно — подобная инфраструктура требует серьёзных вложений.
Вывод
Когда в компании есть собственный движок, полезно задавать не только вопрос:
Насколько наш движок готов не только решать текущие задачи, но и поддерживать развитие продукта в долгосрочной перспективе?
Но и другой:
Есть ли у нас экосистема, которая позволяет эффективно развивать и тестировать игры на этом движке, а также безболезненно мигрировать на его новые версии?
Стоимость современного игрового движка находится не только в runtime.
Она находится в инструментах автоматизации, тестировании, документации, внутренних процессах и архитектурных решениях.
Это те вещи, которые редко видны на первых этапах разработки, но именно на них позже уходят человеко-годы тестирования, расследования сложных дефектов и поддержки платформы.