게임 개발을 다룰 때 소프트웨어 테스트가 다른가요?

필자는 일반적인 소프트웨어 개발과 게임 개발의 차이점에 대해이 논문 을 읽었 으며 저자는 소프트웨어 테스트와 관련하여 몇 가지 좋은 점을 지적했습니다.

... 게임 개발자들은 게임 디자이너의 창의적 욕구가 변화함에 따라 이러한 테스트의 빠른 노후화로 인해 자동 테스트를 사용하는 것을 주저합니다.

그래서,이 글을 읽게되면 게임을 다루거나 테스트 할 때 소프트웨어 테스팅의 어떤 다른 측면을 다르게 생각해야합니까? 누구든지 이것에 대해 경험이 있거나 다른 것에 대해 들었습니까?

현대 게임은 실제로 사내 또는 독점 게임 엔진을 사용하여 개발 된 수많은 창의적인 예술 콘텐츠입니다. 엔진 자체는 렌더링, 지오메트리, 물리, AI 모듈 등 대부분의 부품에 대해 테스트 할 수 있습니다. 마찬가지로 간단한 테스트를 개발 된 컨텐츠의 개별 부분에 첨부 할 수도 있습니다. 이것은 단위 및 화이트 박스 테스트가 실제로 가능하고 성공적임을 의미합니다.

"전체 제품"에 관한 한 게임은 시뮬레이션입니다. 단순한 비즈니스 프로그램보다 생성 복잡성이 더 클 수 있습니다. 끝없이 독특하고 절차 적으로 생성 된 세계와 계획이 잘 짜여진 행동을 가진 엔터프라이즈 자원 계획자를 생각해보십시오. 간단히 말해서, 게임의 맥락에서 무언가를 할 수있는 독특한 방법의 수는 수학적으로 매우 클 수 있습니다. 실제로 그것은 게임 판매 포인트로 간주됩니다.

또한 최종 출력은 순수한 시청각이며 이러한 출력의 절대 정확성에 대한 결정적인 표준은 없습니다. GPU 칩은 실제로 정밀하지 않은 경우에도 정확한 계산을 수행 할 필요가 없으며 많은 계산 만 수행 할 수 있습니다.

그리고 마지막으로 주요 목표는 엔터테인먼트 입니다. 60+ FPS를 실행하고 멋지게 보이고 끝없는 재미있는 콘텐츠를 보유하고 있다면 게이머는 결함이 있어도 괜찮습니다 .

이를 통해 기존의 자동화 된 블랙 박스 테스트 아이디어를 게임에 적용 할 때 "실제로 가치가없는"영역에 배치합니다.

그러나 최근에 NN이 게임을 하도록 훈련 시키려는 시도가 있었는데 , 이는 효과적으로 탐색적이고자가 학습하는 원숭이 테스트의 한 형태입니다.

gamedev를 한 지 몇 년이 지났지 만 좋은 대답 외에도 추가하고 자세하게 설명하고 싶은 것이 있습니다.

먼저 이미 언급 한 결과는 엄격한 "FPS 임계"제약 조건 및 계산 / 메모리 예산에 비해 시각적이고 청각 적이라는 것입니다. 질문이 더 좋아 보일 때 정확성에 대한 생각이 흐릿 해집니다. "좋아요? 말더듬이없이 부드럽게 작동합니까? 개발자와 개발자가 조정하고 조정하는 동안 디자이너 / 개발자 공동 작업으로 인해 빠른 반복마다 모양과 소리가 약간 달라집니다.

다른 하나는 테스터가 대단 할 수 있다는 것입니다! 그들은 이후는, 다른 도메인에 테스터의 이상의 전용 그룹을 발견 적이 원하는소프트웨어를 테스트합니다. 그들은 재미 있어요. 그들은 컴퓨터 옆에 중독되어 잠을 자면서 게임의 구석 구석을 탐험합니다. 실제로 소프트웨어에 구애받지 않고 소프트웨어의 모든 구석을 철저히 테스트하는 사람들이 실제로 모호한 결함을 발견하는 것은 매우 쉽습니다. 현재 업계에서는 테스터가 작업하기가 좀 더 어렵습니다. 많은 사람들이 소프트웨어에 생계를 연결하는 전문가이기 때문에 작업을 수행하기 위해 소수의 기능에 의존하기 때문에 소진에 관심이있는 것은 아닙니다. 언제나 구석 구석까지 당연히 인간 테스터에 크게 의존 할 수없는 경우에는보다 자동화 된 테스트가 필요합니다.

또 다른 하나는 게임의 코드베이스가 일반적으로 몇 년과 몇 년 동안 유지되고 수정되고 확장되지 않는다는 것입니다. 6502 어셈블리에서 처음 개발 한 Super Mario 개발자가 게임이 출시 된 후 오랫동안 원래 코드와 비슷한 것을 유지해야하는 것은 아닙니다. Doom 3은 아마도 Doom 1의 0 줄 코드 (또는 가까운)를 사용합니다. 프랜차이즈가 계속 진행되는 경우 최신 게임은 "업그레이드"보다 "속편"과 비슷합니다. 대부분의 게임은 패치와 DLC를 출시하고 출시 한 후 코드가 완성됩니다. 그것은 제가 수십 년 동안 포팅되어 유지 된 Amiga 시절의 코드를 유지 관리하는 VFX 산업과는 큰 대조를 이룹니다. 게임은 일반적으로

게임 코드베이스의 수명이 짧은 이유 중 하나는 하드웨어와 밀접한 관련이 있기 때문입니다. 최첨단의 특성 및 FPS 핵심 요구 사항과 결합하면 하드웨어 세부 사항을 추상화하는 방식으로 개발할 수없는 경우가 많습니다. 그것들은 종종 대상 하드웨어 생성을 위해 매우 구체적으로 쓰여졌으며, PS3가 PS4로 대체 된 후 오래지 않아 PS5 등으로 대체되고 매우 빠르다. 하드웨어 기능은 게임 디자인 및 개발에서 중요한 역할을하며 일반적으로 PS4 용으로 작성된 것과 동일한 코드를 PS4 용으로 작성하는 것은 가치가 없습니다. 예를 들어, 세대를 위해 지속되는 대부분의 게임 프랜차이즈는 여전히 차세대 엔진을 작성합니다 최신 하드웨어의 기초부터 시작합니다.

수명이 짧은 코드베이스는 유지 관리 시간이 제한적입니다 (즉, 코드를 수정해야하는 제한된 시간). 업그레이드 할 때마다 엔진의 범위가 점점 커지면서 수년에 걸쳐 코드가 변경되는 데 시간이 제한되어 있으며 게임이 미션 크리티컬에 가까운 곳이 아니라는 사실과 함께 가장 철저한 단위 및 통합 테스트를 적용해야합니다. 미래의 변화가 일어나지 않을 경우 미래 ​​변화의 무결성을 보장하는 데는 아무런 이점이 없으며, 레거시 코드베이스의 단위 테스트 및 리팩토링 측면은 처음에는 "레거시"가 없다면 자연적으로 관련이 없습니다.

항상 관련성이없는 또 다른 작은 것은 게임이 데스크탑 포트가없는 매우 좁은 범위의 하드웨어 만 대상으로 할 수 있다는 것입니다. 이러한 경우, 하드웨어 및 드라이버가 완전히 다른 소프트웨어를 실행하는 사용자 인 이러한 상황에서 예측할 수없는 결함의 큰 원인이 제거됩니다.

즉, 최고 / 가장 높은 수준의 통합 테스트가 더 즉각적으로 유용한 경향이 있습니다. 예를 들어, 많은 게임은 "재생"에 대해 시간이 지남에 따라 게임 상태가 어떻게 변하는 지 기록하는 방법을 활용할 수 있습니다. 이러한 재생 기능은 게임이 결정 론적이며 다른 사람이 이전에 기록한 게임 세션을 재생하기 위해 자체적으로 테스트 도구의 형태로 사용될 수 있습니다.

또한 소규모 스튜디오에서 게임 개발자가 게임을 위해 봇을 작성하는 것과 같은 일을하고 최대 속도로 게임을하도록하고 시뮬레이션을 실행했습니다. 원래는 하루나 이틀 후에 모호한 충돌이 발생한 후 수정했습니다. 시뮬레이션을 다시 실행하고 몇 주 동안 시뮬레이션을 실행 한 후에도 더 이상 중단이 발생하지 않을 때까지 반복했습니다. 따라서 gamedevs에서 소프트웨어 테스트에 이르기까지 흥미로운 실용적 접근 방식이 있지만, 가장 복잡한 통합 테스트 수준과 비슷한 방식으로 플레이어가 실제로 게임과 실제로 상호 작용하는 방식과 매우 유사하게 시뮬레이션하는 경우가 많습니다.

마지막으로,이 큰 AAA 게임 엔진은 완전히 다른 종류의 짐승과 비슷해지기 시작했습니다. 더 긴 수명, 더 큰 코드베이스와 더 긴 유지 보수 기간으로 하드웨어를 조금 더 잘 추상화하고 레벨 에디터가 완전한 개발 환경과 비슷해지기 시작했습니다. 큰 엔진은 아마도 코드를 유지하는 시간이 상당히 길어질 경우 더욱 철저한 테스트 절차를 요구할 것입니다. 여전히 많은 게임 스튜디오는 거대한 AAA 게임 엔진을 작성하지 않습니다. 라이센스를 얻거나 범위가 상당히 작고 몇 년 동안 유지되지 않을 작은 독점 엔진을 개발합니다.