Як розробити програмне забезпечення гри таким чином, щоб його було легко провести?

Чи практично використовувати тестовий фреймворк типу JUnit в ситуації розвитку ігор? Яких міркувань щодо дизайну ви можете дотримуватися, щоб зробити вашу гру більш відчутною? Які частини гри можна / слід перевірити, а які частини слід / потрібно залишити для тестування на людях?

Наприклад, якщо ігровий цикл інкапсульований однією функцією, здається, що це було б дуже важко перевірити. Мені подобається переробляти функцію "оновлення", яка займає дельту часу і рухається вперед в ігровій логіці; це дозволяє зробити такі цікаві хитрощі, як можливість уповільнити гру, подаючи її фальшиві, повільніші дельти часу.

Одне з принципів TDD полягає в тому, що ви дозволяєте TDD в деяких випадках впливати на ваш дизайн. Ви пишете тест для системи, потім пишете код, щоб зробити тестовий прохід, підтримуйте залежності якомога дрібніше.

Для мене є лише дві речі, які я не тестую в рамках одиничного тестування:

По-перше, я не перевіряю візуальні елементи та те, як виглядають речі. Я перевіряю, що об'єкт буде знаходитись у потрібному місці після його оновлення, що камера буде скидати об'єкт поза його межами, що трансформації (принаймні ті, що виконуються поза шейдерами) виконуються належним чином перед передачею графічному двигуну , але як тільки він потрапляє у графічну систему, я малюю лінію. Мені не подобається намагатися знущатися над такими предметами, як DirectX.

По-друге, я не дуже перевіряю основну функцію циклу гри. Я перевіряю, що кожна система буде працювати, коли вона проходить розумну дельту, і що системи працюють правильно разом, коли потрібно. Тоді я просто оновлюю кожну систему правильною дельтою в ігровому циклі. Насправді я міг би провести тест, який би показав, що кожна система називається з правильною дельтою, але в багатьох випадках я вважаю, що це надмірна кількість (якщо ви не займаєтеся складною логікою, щоб отримати свою дельту, то це не зайвий рівень).

Ноель Льопис охопив тестування одиниці, наскільки я вважаю, що ви шукаєте:

• http://gamesfromwithin.com/stepping-through-the-looking-glass-test-driven-game-development-part-1
• http://gamesfromwithin.com/stepping-through-the-looking-glass-test-driven-game-development-part-2
• http://gamesfromwithin.com/stepping-through-the-looking-glass-test-driven-game-development-part-3
• http://gamesfromwithin.com/backwards-is-forward-making-better-games-with-test-driven-development
• (він також має багато інших статей про TDD)

Що стосується тестування всього циклу гри, є ще одна методика запобігання функціональних регресій у вашому коді. Ідея полягає у тому, щоб ваша гра сама грала через систему повторного відтворення (тобто спочатку записує входи програвача, а потім відтворює їх протягом іншого виконання). Під час відтворення ви створюєте знімок стану кожного об'єкта для кожного кадру. Цю колекцію держави потім можна назвати «золотим образом». Під час рефакторингу коду, ви запускаєте повтор знову та порівнюєте стан кожного кадру із золотим зображенням. Якщо вона відрізняється, тест не вдався.

Переваги цієї методики очевидні, є кілька речей, з якими потрібно бути обережними:

• Ваша гра повинна бути детермінованою, тому вам слід бути обережними з такими речами, як залежно від вашого системного годинника, системних / мережевих подій, генераторів випадкових чисел, які не є детермінованими. тощо.
• зміни вмісту після створення золотого зображення можуть спричинити законні відмінності у вашому золотому зображенні. Не обійтися цим способом - при зміні вмісту вам потрібно відродити свій золотий образ.

Я погоджуюся з коментарями Джеффа та jpaver. Я також хотів додати, що прийняття компонентної моделі для вашої архітектури значно підвищує її доцільність. У компонентній моделі кожен компонент повинен виконувати одну одиницю роботи і повинен бути перевірений ізольовано (або з обмеженими макетними об'єктами).

Крім того, інші частини гри, які покладаються на сутність, повинні покладатися лише на підмножину компонентів, які функціонують. На практиці це означає, що ви можете зазвичай знущатися з декількох підроблених компонентів, щоб полегшити тестування цих областей, або ви можете просто скласти часткові об'єкти для цілей тестування. наприклад, ви не залишаєте компоненти для візуалізації та введення, оскільки вони не потрібні для перевірки фізики.

Нарешті, я б ігнорував поради щодо продуктивності, які ви отримуєте від деяких користувачів ігрового співтовариства щодо інтерфейсів. Напишіть код добре з інтерфейсами, і якщо у вас виникнуть проблеми з продуктивністю в дорозі, ви зможете легко профайлювати, ідентифікувати та рефактор для вирішення проблеми. Мене не переконували занепокоєння Ноеля щодо впливу інтерфейсів на продуктивність або складності, які вони додали.

Однак, не перестарайтеся намагатися перевірити кожну дрібницю самостійно. Як і більшість речей, тестування та дизайн стосуються досягнення правильного балансу.

Я думав, що додам другу відповідь, відповідаючи на коментар ОП про те, що користувач може замінити одиничні тести. Я вважаю, що це абсолютно неправильно, оскільки мета одиничних тестів - не гарантувати якість. Якщо ви хочете провести тести, щоб забезпечити якість вашої програми, ви, швидше за все, слід вивчити тести сценаріїв або інвестувати в чудовий моніторинг.

(За умови чудового моніторингу та продукту, що працює як послуга, дійсно можливо натиснути на "тестування" на клієнта, але вам потрібно мати складну систему, яка швидко виявляє помилки та скасовує відповідні зміни. Швидше за все, це занадто багато для невелика команда розвитку.)

Основна перевага модульних тестів полягає в тому, що вони змушують розробника написати краще розроблений код. Акт тестування кидає виклик розробнику відокремити проблеми та інкапсулювати дані. Це також заохочує розробника використовувати інтерфейси та інші абстракції, щоб він перевіряв лише одне.