답변:
인터넷 베타 테스터가 아닌 현장 플레이 테스터에 대해 이야기하고 있다고 가정합니다.
규칙 # 1 : 그들을 도와주지 마십시오 . 좌절은 당신이 확인해야 할 가장 중요한 것이어야합니다. 이상적인 상황은 한쪽에는 팀이 있고 한쪽에는 비디오 카메라가 있고 다른 하나는 화면에 다른쪽에는 플레이 테스터가있는 양방향 미러입니다. 분명히 이것은 대부분의 사람들에게 실현 가능하지 않으므로 최선을 다하십시오. 디자이너가 앉아서 사람들이 붙어있는 곳을 보는 것만으로도 매우 유용한 정보입니다. 그들이 게임을 집으로 가져갈 때 어깨 너머에 서 있지 않을 것이므로 특정 섹션을 통과하는 방법에 대한 조언을 제공한다고해서 필요한 정보를 얻을 수는 없습니다. 편집 : 그것을 넣는 또 다른 방법은 이것입니다 : 그들이 틀렸다고 생각하지 마십시오 .
규칙 # 2 : 그들이 원하는 것을주지 마십시오 . 플레이 테스트 세션 후에는 그들이 작성하는 설문지가 있습니다. 그들이 제시 한 구체적인 제안은 일반적으로 액면가를 취하는 것이 현명하지 않습니다. 일반적으로 대부분의 응답을 유발하는 근본 원인이 있으며이를 표현하는 방법을 모릅니다. 당신이 그것을 알아낼 수 있다면, 당신은 그것을하는 것이 좋습니다. 지금은 구체적인 예를 제시하는 데 문제가 있습니다.
규칙 # 3 : 데이터는 왕 이다. 가능하다면 (정말로 다른 위시리스트 아이템입니다) 가능한 모든 것을 추적하십시오. 플레이어가 죽는 곳을 추적합니다. 특정 총에서 탄약이 부족한 곳을 추적하십시오. 그들이 놓친 픽업을 추적하십시오. 그들이 구매 한 업그레이드를 추적하십시오. 적들이 어떤 피해를 입는 지 추적하십시오. 분명히 이것들은 FPS 특정 예제이지만, 당신이하는 게임에 대한 도메인 특정 예제가 있다고 확신합니다. 모두가 무언가를하고 있거나하지 않는 경우, 대개는 좀 더 시간을 들여 살펴 봐야하는 영역입니다.
기본적으로 플레이어의 생각은 중요하지 않습니다 . 당신은 선수들이하는 일에 대한 원수를 얻는 것에 관심을 갖습니다 . 게임을보고 좌절감을 느끼게하고 무엇을하는지 알려면 처녀의 눈이 필요합니다.
충돌이 발생하면 미니 덤프를 조사하십시오 . 완벽하지는 않지만 충돌 위치를 파악하는 데 매우 유용한 도구입니다.
내장 버그보고 도구도 고려하십시오. 사용자가 스크린 샷을 찍고 설명을 추가하여 게임 내부에서 자동으로 누군가에게 이메일로 보낼 수있는 것. 게임에서 지원하는 경우 세계 스냅 샷 (즉, 빠른 저장 또는 일종의 메모리 덤프)이 이상적입니다.
on-site playtesters
데이터 를 확장하는 것은 왕의 정서입니다 (+1 to Tetrad!).
녹음 및 재생 조사 :
(key/button state, joystick/mouse coords, frame #)입력 상태가 변경 될 때마다 튜플 만 저장하면 됩니다. 입력을이 스트림으로 리디렉션하는 것만 큼 재생이 간단합니다. (이전에는 많은 플랫폼 점프 게임에서이 작업을 수행했습니다.)이러한 방법을 기반으로 한 "재생"시스템에는 많은 장점이 있습니다.
기록 된 스트림이 아닌 임의의 입력으로 연결 하면 밤새 또는 개발 시스템이 유휴 상태 일 때마다 몸을 담글 수 있는 훌륭한 원숭이 테스트 가 있습니다.
그런 다음 이벤트 녹화를 수행하십시오 . 가상의 FPS의 경우, "무기 W를 사용하여 지점 Z에서 시간 T : X가 Y를 죽였습니다"와 같은 것으로 시작하십시오 : 로그에 넣으십시오.
데이터를 수집 한 후 수집을 자동화 하는 방법을 알아보십시오 . 개발하는 동안 우아하지 않아도됩니다.
데이터를 수집 할 수있는 한 실제로 중요하지 않습니다.
이제 크래시 덤프, 스택 추적 및 입력 또는 이벤트 기록을 수집하십시오. 더 많은 이벤트와 더 많은 데이터 소스를 추가하십시오.
getFreeMemoryBytes() 30 분마다getFPS() 주기적으로"지도에 표시"는 RTS 또는 FPS지도의 조감도를 계획 한 후 잠시 후에 정말 멋질 수 있습니다. 게임 시작 후 시간을 나타내는 슬라이더를 위에 올려 놓습니다. 이벤트 유형을 선택하십시오 ( "금을 얻었음", "죽은 사람"등). 데이터 세트를 선택하십시오 : 지난 몇 개월 동안 한 게임, 500 게임. 슬라이더를 오른쪽으로 당기기 시작하고지도에서 활동 팝을 봅니다.
그리고 당신 이이 물건에 도움이되는 좋은 라이브러리를 찾을 수 없다면 (여기에 몇 가지가 있습니다!), 자신의 롤링을 고려하십시오 : 그것은 좋은 학습 경험이며 특히 우아 할 필요는 없습니다. 유용합니다.
데이터를 가져 오면 어떻게해야하는지 파악할 수 있습니다. =)
물론 이것은 a) 어떤 종류의 테스트를하고 싶고 b) 어떤 종류의 게임을 테스트하고 c) 어떤 종류의 테스터와 인프라를 사용할 수 있는지에 달려 있습니다.
a) 기능, b) 균형 조정 c) 게임 디자인을 테스트하는 경우에도 크게 다릅니다.
그러나 일반적으로 이러한 측면을 고려할 수 있습니다 ...
* a) 직업에 맞는 사람을 선택하십시오. 언급하기에는 너무 간단하게 들리지만, 여러 번 보았고 다시 생방송을 보았습니다. 항상 그렇듯이 사람들이 다른 직업을 얼마나 잘하는지에 관해서는 사람들 사이에 큰 차이가 있습니다. 테스트를 기꺼이하거나 열망하는 일부 사람들은 비정상적인 (또는 단순한) 버그를 발견 할만큼 충분히 놀지 못할 수도 있습니다. 일부는 버그를 잘 설명하지 못합니다. 일부는 균형 문제를 테스트하는 데 더 좋고, 일부는 시각적 약점에 더주의를 기울이고, 일부는 특이한 방식으로 게임을 플레이하는 데 더 창의적이고, 숨겨진 / 희귀 한 버그를 찾고, 일부는 기술적 또는 시각적 품질에 더주의를 기울이고, 일부는 측면을 이해하는 데 더 좋습니다 (게임 테스터가 원하는 경우) 의미있는 변화를 제안 할 수도 있습니다.
* b) Issue-Tracker / Bug-Tracker 소프트웨어 사용 이 도구는 문제를 구성하는 데 도움이 될뿐만 아니라 테스터가 내부에서 작업 할 프레임을 제공하고 피드백을 통해 학습함으로써 테스터의 출력 품질을 향상시키는 데 도움이됩니다. 개발자의 문제에 대해 테스터없이 작업하는 것보다 테스터의 출력 품질을 훨씬 빠르게 향상시키는 데 도움이됩니다. 게임 스튜디오에서 사용하는 일반적인 소프트웨어는 Mantis, JIRA (및 기타 많은 것들입니다.) 일반적인 목록과 SO에 대한 이 게시물 은 Wikipedia 를 참조하십시오 .
c) 게임 내 테스트 도구 추가 일반적으로 게임의 특정 수준이나 섹션을 테스트하는 바로 가기입니다. 게임 중에 테스터에게 추가 정보를 표시하여 버그 리포트에 추가 할 수 있습니다. 이것은 레벨에서의 위치, 씬의 활성 오브젝트 수, 현재 사용중인 텍스처 램 또는 팔레트의 양, 개발자에게 도움이 될 수 있습니다.
d) 숙련 된 테스터와 신선한 혈액의 결합 항상 게임에 경험이 많은 테스터가 일반적인 문제가 무엇인지, 어떻게 테스트 (재)하는지 배우는 것이 좋습니다. 동시에, 특히 균형을 잡기 위해 새로운 "처녀"플레이어를 가끔 원합니다.
e) 테스트 관리자 프로세스를 조정하고 현재 게임, 현재 우선 순위 및 사용 가능한 테스터 및 테스트 환경에 맞게 조정하는 사람.
f) 테스트 플랜 문서를 작성하십시오. 이것은 추가 게시물의 가치가 있습니다.
Tetrad가 언급했듯이 가능한 한 객관적인 데이터를 얻으십시오. 특정 이벤트를 저장하고 모든 이벤트를 .csv에 덤프하기 위해 후크를 넣는 것은 그리 어렵지 않습니다. 그리고 일단 Excel로 가져 오면 젖소가 집으로 돌아올 때까지 공부하고 그래프를 작성하고 플롯 할 수 있습니다.
또한 답변하려는 특정 질문이 있습니다. 과학자들은 단지 앉아서 실험을하지 않고 과학을 수행하지 않습니다. 데이터에 대해 구체적이고 측정 가능한 질문이 있습니다. 같은 접근법을 사용하면 종종 플레이 테스트를 최대한 활용할 수 있습니다. 게임이 "좋은지"파악하려고 시도하는 것은 정량화하기가 매우 어렵습니다. 그러나 간단한 튜토리얼 미션이 예상 5 분 밖에 걸리지 않거나 테스터가 특정 퍼즐을 풀기 위해 고군분투하고 있는지 파악하면 실제로 평가할 수 있습니다.
때로는 테스트하는 가장 효과적인 방법은 짧은 버스트를 반복하는 것입니다. 두 명의 테스터가 아침에 한 시간 정도 가도록하고 확인한 문제를 일부 변경 한 후 다음날 아침 새로운 테스터와 다시 가도록합니다. 분명히 오후에 개선 할만큼 작은 기능을보고 있어야합니다. 그러나 특히 완고한 문제의 경우이 방법은 매우 성공적 일 수 있습니다.
Tetrad의 규칙 # 1에 확실히 동의하십시오. 그들을 도와주지 마십시오. 나는 당신이 그들을 도울 수 없다는 것을 설명하고 그들이 도움을 요청하는 것이 도움이 필요하다면 설명해야한다고 경고합니다. 이런 식으로 플레이어는 결국 좌절하지 않습니다.
설문지는 예 / 아니요 단순한 질문 대신 개방형 질문을해야하며, 테스터의 연령과 수에 따라 양식을 작성하거나 질문을 할 수 있습니다. 그들의 역사와 그들이 테스트하고있는 게임 장르에 대한 친숙성에 대해 질문하는 것도 중요합니다. 게임에 대한 특정 답변에 컨텍스트가 추가됩니다.
다행히도 내 게임이 충돌하면 오류에 관한 정보를 얻을 수 있으므로 그 사진을 찍고 플레이어의 활동을 기록 할 수 있습니다. 일반적으로 나는 어린 나이 그룹을 테스트하므로 충돌이 발생했을 때 그들에게 훌륭한 일을하고 있음을 설명해야합니다. 게임을 마친 후 화를 낼 수 있습니다. 플레이 테스터는 개발자 팀이 절대 "올바른"방식으로 게임을 플레이 할 수없는 모호한 버그를 찾는 데 능숙한 것으로 입증되었습니다.
충돌 보고서의 경우 플레이 테스터가 아닌 유료 QA 직원에게 의존해야합니다. QA는 버그를 찾아서 의미있는 방식으로보고 할 수있는 능력을 발휘하기 위해 특별히 고용 한 사람이며, 우수한 테스터는 무게가 금으로 표시됩니다 (프로그래머에 비해 금의 무게는 10 분의 1 만!).
"오, 그들이 우연히 충돌을 발견하면, 우리는 그들이 그것을 테스트하지 않기 때문에 놓치고 싶지 않을 것"에 대해 걱정한다면 ... 이것이 바로 로깅입니다. 충분히 좋은 로깅 시스템은 충돌을 정확하게 재현 할 수있는 충분한 재생 요소를 기록해야합니다.
디자인 피드백의 경우 게임 디자이너가 실제로 게임을 보도록하는 것 (또는 필요한 경우 비디오 레코더 사용)을 대신 할 수는 없습니다. 플레이 테스터의 기억이나 의견에 의존하지 마십시오. 그러나 그들이 실시간으로 경기하는 것을보고 있다면, 그들의 얼굴과 몸의 자세를보고 참여하고 지루하거나 좌절하는지 여부만으로도 명백합니다.
** Don't help them **