이 게시물에는 두 개의 일기가 포함되어 있습니다. 하나 는 Hamlet: The Village Building Game 의 디자이너인 David Chircop 의 일기 이고 다른 하나 는 게임 개발자인 Johnathan Harrington 의 일기입니다. 여기서 목표는 디자인에 대한 두 가지 다른 관점과 접근 방식을 제공하는 것입니다. 포스트 전반에 걸쳐 우리는 게임이 성장하고 가마솥에서 부딪히면서 모든 것이 어떻게 변했는지 볼 수 있도록 햄릿의 프로토타입 사진을 다소 시간순으로 흩뿌렸습니다. 즐기다!
마지막 업데이트: Kickstarter 후원자에게 사본이 배송되기 시작했으므로 Hamlet: Founders' Deluxe Edition 은 SPIEL '22에서 65€에 한정 수량으로 구매할 수 있습니다.
디자이너 일기: 공간 감각에 관한 것
제가 게임 제작에 손을 댄 이후로, 마을 건축업자는 제가 모델링할 수 있는 매력적인 유망주였습니다. 일반적으로 게임에 대한 나의 형성 경험은 The Settlers , Age of Empires 및 WarCraft 와 같은 게임과 같은 RTS 장르에 깊이 뿌리를 두고 있습니다. 나는 그 게임들을 정말 좋아했지만, 그 게임들에서 내가 가장 좋아했던 것은 전투나 기술 트리가 아니었다. 시작 20분 만에 시청과 몇 명의 농민이 등장하고 처음부터 물건을 만들고 형성하기 시작했습니다.
나는 노동자들의 관리, 노동자들의 움직임, 노동자들이 너무 멀리 걷지 않도록 나무꾼을 숲 가까이에 배치하는 것을 즐겼다. 나는 별 생각 없이 그리고 거의 필연적으로 우리 마을이 스스로 조직되기 시작한다는 사실을 즐겼습니다. 서로 이웃한 집들, 목재 생산 지역, 광산 지역, 나중에 확장할 수 있다고 알고 있는 위치에 농장이 배치됩니다. 이 모든 것이 역학의 필요성과 함께 지도의 무작위성, 지역 간의 거리감, 분리, 그리고 꽤 정리된 것에 대한 나의 욕망과 결합되어 결국 "장소"가 나타나도록 허용했습니다. 나중에 내가 이름을 지었다고 합니다. 종종 웃기고 우스꽝스럽거나 유치할 정도로 외설적인데, 데이빗 사이를 알면서요.
그리고 조금 축소해서 우리 마을이 살아 있는 모습을 지켜봤습니다. 이 귀여운 건물에서 다른 건물로, 물건을 나르는 마을 사람들.
이것은 내가 가장 좋아하는 부분이었습니다. 다른 마을 발견, 더 강한 군대를 만들기 위한 경쟁, 방어 및 기회주의적 반격과 같은 게임에 자주 수반되는 다른 아크는 모두 나에게 부차적인 것이었습니다. 나는 종종 마을을 작동 상태로 가져온 다음 저장을 포기하고 다시 시작하여 건물을 다시 만들고 이번에는 무엇이 나타날지 확인했습니다.
이것은 핵심적으로 햄릿 에게 가장 큰 영감을 줍니다. 2021년 3월, 4년 간의 온오프 개발 끝에 힘든 AAA 비디오 게임 작업을 통해 출판하고 싶은 햄릿 을 갖게 되었습니다. 2021년 10월까지 저는 이 게임의 "완성된" 버전이라고 생각했던 것을 얻었습니다. 게임은 균형 있고, 매끄럽고, 능률적이며, 짧고, 경쟁적이며, 설명하기 쉬웠습니다. 보기 좋게 생겼습니다. 그것은 좋은 마을 건설자를 만드는 요소를 가지고있었습니다. 네, 물론 "하지만"이 있습니다.
2021년 11월에 Hamlet 의 Kickstarter를 연기했습니다.. 우리는 일부 예술을 다시 하고 싶었고, 비디오에서 조금 더 오래 작업하고 싶었고, 페이지를 다듬고 싶었습니다. 나는 내가 완성된 것으로 기록했던 게임을 발견했지만, 또한 어떤 면에서는 나를 완전히 만족시키지 못한 게임을 발견했습니다. Kickstarter 덕분에 몇 개월의 추가 시간을 벌고 그 이유를 알아보기 위해 자리에 앉았습니다.
David Lynch의 "Catching the Big Fish"에서 나는 원래 아이디어를 유지하기 위해 그의 주장을 기억합니다. 항상 "최상의" 결정을 내리는 것이 아니라 원래 아이디어에 가장 도움이 되는 결정을 내리는 것입니다. 게임이나 영화와 같이 환원이나 증류를 포함하는 창의적인 과정을 필요로 하는 미디어에서 영감에 대한 이러한 고수는 달성하기가 더 중요할 뿐만 아니라 더 어려워집니다.
Kickstarter 지연이 나에게 부여한 추가 시간과 함께 나는 "햄릿"에 자신을 가두었습니다.Mighty Boards 사무실에서 몇 주 동안 앉아 있었습니다. 아무한테도 말을 거의 하지 않는 이상한 시간이었고, 사람들이 나를 방해하는 것을 두려워했던 것 같아요. 당시 게임에 액세스할 수 있었던 사람들과 생각하고 몇 가지 토론을 하고 친애하는 친구이자 동료 디자이너인 Gordon과 몇 가지 깊은 토론을 한 후 문제를 정확히 지적 했습니다 . 더 나은 게임이 되었지만 "장소" 생성을 중단했습니다. 이름을 지을 수 있는 장소입니다.
이름이 있는 장소
왜 이런 일이 일어났는지 알아내는 것은 그리 어렵지 않았습니다. 게임을 합리화하는 과정에서 우리는 게임이 가지고 있던 거리 제한을 대부분 제거하여 많은 덩어리를 제거했습니다. 이는 모든 작업자가 거의 모든 곳으로 쉽게 이동할 수 있음을 의미하며, 효율성을 위해 서로 가까이 있어야 하는 건물의 중요성을 경시했습니다. 위치가 중요하지 않은 경우 매력적인 공간 퍼즐, 다양한 타일과 건물, 다양한 효과가 있더라도 대부분 상징적입니다. 장소감은 '어디'에 대한 질문에서 나온다. 이걸 어디에 둘까요? 목재는 어디에 있습니까? "어디"가 중요하지 않으면 장소가 없습니다.
움직임은 보드 게임에서 가장 오래되거나 가장 기본적인 메커니즘 중 하나일 것입니다. 그것은 또한 수사학적으로 가장 효율적인 것 중 하나입니다. 저는 조각을 한 곳에서 다른 곳으로 옮깁니다. 누구나 공감할 수 있는 선명한 이미지 생성기입니다. 또한 불행히도 때때로 가장 짜증나는 일입니다. 특히 Eurogames에서 그렇습니다.
보드 게임에서 우리는 종종 공간을 부분으로 추상화하기 때문에 움직이는 조각은 종종 계산 연습으로 이어집니다. 이것은 몇 개의 공간으로 제한될 때("하나 또는 두 개의 공간을 이동할 수 있습니다") 주제별로 공명하는 시간 프레임 및 공간에 매핑될 때 괜찮 습니다 . 광기의. 또한 지역 제어 게임에서 도시 대 도시 또는 지역 대 영역과 같이 훨씬 더 큰 공간에서도 의미가 있습니다.
하지만 그 중간 지점은 어떻습니까?
다음은 내 사고 과정입니다.
작업자 배치는 이동 없는 순회입니다
. 저는 항상 작업자 배치가 이 이동 문제에 대한 자연스러운 반응이라고 상상했습니다. 작업자 배치에 대한 초기 고전의 대부분은 내가 햄릿 이 생성하기를 원하는 장소 크기 정도의 공간을 매핑했습니다. 석기 시대 , Caylus , Agricola 를 생각 하고 있습니다 . 그들은 움직임을 건너 뛰면서 우리에게 횡단을 보여 주었고, 장소 사이의 거리가 아닌 공간의 "점유"로 제한을 이동했습니다. 햄릿 은 거리가 필요합니다. 사실 이동 자체보다 거리가 더 필요합니다. 또 뭐?
그런 다음 론델과 만칼라 게임이 있는데, 이는 움직임의 터치를 다시 도입하는 작업자 배치 게임이며 공간 계산의 주판을 피하는 제한이 있습니다. 이러한 게임은 좋은 중간 지점이며 일반적으로 제한이 있는 거리를 매핑하는 영리한 방법입니다. 그러나 그것들은 가능한 행동들 사이의 순서와 거리가 신중하게 계산되는 엄격하게 설계되고 빡빡한 시스템입니다. Hamlet 은 대체로 모든 마을이 완전히 다른 샌드박스 게임이며 건물의 위치는 모두 신흥 경제와 플레이어의 배치 결정을 기반으로 합니다.
이러한 유형의 게임은 일반적으로 일련의 작업을 올바르게 계획하기 위해 상당한 노력을 기울여야 하는 계획의 불투명성 문제가 있어 움직임/작업 선택 메커니즘이 상당히 전방적이고 집중적입니다. 햄릿 에서 움직임은 중요하지만 이미 많은 움직이는 부분이 있기 때문에 계획의 불투명도를 방해할 수 없습니다: 신흥 경제, 유기적이고 그리드 없는 마을 건설, 공간 퍼즐, 도로.
이 시점에서 나는 공간을 제한하는 덜 직접적인 "활성" 모드에 관심을 돌렸습니다. 아마도 천천히 구축되는 것, 계획하기에 조금 더 명확한 것입니다. 중간 크기의 공간에 적합한 것입니다. 내 관심은 훈련 게임과 네트워크 빌더로 바뀌었습니다. Brass 및 Steam
과 같은 게임노동자는 노동자인 햄릿 의 경우처럼 그들의 "능동적" 요소의 움직임을 통해서가 아니라 네트워크의 느린 발전과 결과적으로 상기 네트워크를 통한 상품의 이동을 통해 장소감을 획득한다.
Enter Donkey Hamlet
의 매우 특정한 경우의 해결책은 과거에 많은 위대한 디자이너들이 작업자 배치를 생각해 냈을 때 했던 것처럼 무브먼트에서 능동 요소를 분리하는 것이었습니다. 그런 다음 더 수동적이고 느린 구축 방식으로 장소와 움직임의 감각을 도입하십시오. 햄릿 에는 이제 마을 주민과 당나귀라는 두 명의 다른 일꾼이 있습니다. 마을 사람은 빠르고 적극적인 행동을 취하여 덩어리와 제한을 줄임으로써 얻을 수 있는 모든 장점(속도, 민첩성, 선택의 명확성)을 제공합니다. 당나귀는 느린 네트워크 구축자이자 자원의 이동자로서 그에 수반되는 모든 훌륭한 것들을 제공합니다: 느린 장기 계획, 거리감.
이 둘의 시너지는 마음 속에 수사학을 구성하고 햄릿 의 전략을 구성합니다 . 마을 사람들의 직접적인 행동은 배송을 구축, 정제 및 이행하는 데 필요한 자원을 전달하기 위해 당나귀 네트워크에 의존하며, 당나귀 네트워크의 성장은 확장 자금을 마련하기 위한 마을 주민들의 효율적인 행동 계획에 달려 있습니다. 이것은 만족스러운 점진적인 성장 주기를 형성하고 갑자기 타일 배열이 활기차고 살아있는 마을에 생기를 불어넣습니다. 아마도 이번에는 더 창의적일 것입니다.
"DAVIDTOWN!"" — 아, 창의성.
나는 지금 존에게 지휘봉을 넘길 것이다. 디자인에 대한 나의 접근 방식과 이 일기는 매우 경험적이었습니다. 그래서 나는 John에게 내가 만든 경험이 어떻게 천천히 정제되어 오늘날의 것이 되었는지에 대한 보다 기술적인 분석 과정을 알려달라고 요청했습니다.
데이비드 처캅
개발자 일기: OSHA 승인 — 작업 순서의 햄릿
David의 밝은 톤에 속지 마십시오. 그는 햄릿 에게 많은 땀과 피를 쏟았다 . 그는 게임의 대리석을 매우 복잡하면서도 우아한 것으로 조각했습니다. 결국 내가 이 프로젝트에 참여할 때가 되었을 때 우리가 할 일은 대리석을 닦고 빛나게 만드는 것뿐이었습니다. 이 부분에서 제가 이야기하고 싶은 것은 플레이 테스트 과정을 공유하고 햄릿 개발 과정에서 내가 느꼈던 점과 잘 하지 못한 점에 대한 것입니다.
게임 개발에는 많은 작업이 필요하며 외부 플레이 테스트는 확실히 중요한 부분입니다. 테스트를 너무 많이 하고, 손가락을 꼬고, 최고가 되기를 바라는 것은 유혹적입니다. 그러나 나는 종종 이것이 비생산적이라고 생각합니다. 더 중요한 것은 각 플레이 테스트가 답변 가능한 질문을 하고 있다는 것입니다. 질문을 작게 만들고(다른 사람들도 답변을 도와줄 수 있도록) 추적 가능/문서화 가능(너무 모호하거나 추측적이거나 거창하여 답변을 녹음할 수 없는 경우 더 나은 질문이 있을 것입니다). 이 게시물에서 나는 (그리고 일반적으로 Mighty Boards) 어떻게 플레이 테스트를 최대한 활용하려고 노력하는지 보여주고 싶습니다.
소개
우리는 햄릿 을 나누었습니다외부 플레이 테스트를 3개의 웨이브로 나눕니다. 테스트를 웨이브로 나누면 꽤 많은 일을 할 수 있습니다. 첫째, 워크로드를 관리하기 쉽게 만듭니다. "우리는 테스트, 테스트, 테스트만 하면 됩니다"라고 말하는 것은 달성할 수 없기 때문에 두려운 일입니다. 최종 테스트가 보이지 않습니다! 둘째, 각 웨이브가 고유한 질문을 갖도록 합니다. 이제 목표(질문에 답)가 있을 뿐만 아니라 목표도 보입니다. (질문이 충분히 답이 되면 테스트가 끝난다.) 셋째, 큰 변화를 일괄적으로 푸시할 수 있다. 이것은 각 변경 사항이 질문과 답변에 모두 영향을 미치기 때문에 중요합니다. 또한 테스터의 제안과 우려 사항을 적절하게 처리할 수 있습니다(올바른 개발 버전에 피드백을 배치하여).
우리는 이 게시물이 우리에게 보이는 것처럼 조직적이지 않기 때문에 이 파도가 고정되어 있지는 않지만 합리적으로 정확한 표현입니다. 또한 외부 테스트만 포함합니다. 나는 David(디자이너)와 Nick Shaw (솔로 버전 디자이너) 처럼 혼자서 게임을 (많이) 했습니다 . 또한 이제 Mighty Boards의 모든 사람들(및 다른 인접 회사의 친구 및 가족)이 일부 버전의 Hamlet 을 플레이했습니다 . 이 게시물의 일부 내용은 이러한 내부 플레이 테스트를 의미하지만 마케팅 관리자는 이 게시물을 15분 미만으로 읽을 것을 요청했기 때문에 외부 플레이 테스트에 대해서만 이야기하겠습니다.
그래서 우리는 그것을 모두 3개의 핵심 파동으로 나누었습니다(각 파동에는 고유한 조수가 있음).
• 포커스 그룹 파동
— 느낌 조수
— 균형 조수
• 매스 웨이브
- 개념 조수
- 브레이크 조수
• 블라인드 웨이브
- 룰북 조수
- 플레이 용이성 조수
포커스 그룹 플레이
테스트 내부 플레이 테스트를 통과한 후에는 회사 외부의 플레이어에게 다가가기 시작할 때였습니다. 햄릿 이 아직 초기 단계에 있었기 때문에 우리는 영향 범위를 작게 유지 했습니다. 우리는 많은 사람들이 우리 게임이 아직 끝나지 않았다는 이유만으로 우리 게임에 대해 나쁜 인상을 받는 것을 원하지 않았기 때문에 우리가 알고 있고 신뢰하는 그룹에 머물면서 대답하고 싶은 두 가지 큰 질문을 던졌습니다.
첫 번째 질문은 "게임이 균형 잡힌 느낌이 드나요?"였고, "교회가 너무 많은/너무 적은 점수를 줍니까?" 또는 "어떤 깃발 건물이 가장 많은 점수를 얻나요?"와 같은 개별 부분에 대해 보다 관리하기 쉬운 질문으로 분류했습니다. 평균?" 플레이 테스트에서 실시간으로 사용한 엑셀 시트가 있었습니다. (우리는 이 세션에서 게임을 한 적이 없습니다. 우리는 관찰하고, 셀을 채우고, 생각에 잠겨 고개를 끄덕였습니다.)
Excel 시트에는 각 라운드의 각 작업자 작업, 해당 작업이 만든 점수 및 각 작업이 수행된 횟수가 기록되었습니다. 균형의 관점에서 볼 때 이 시트를 통해 플레이어 간 포인트 효율성, 작업 간 포인트 효율성, 초기 작업자 투자를 통해 얻은 기회 비용 및 기타 여러 메트릭을 계산할 수 있게 되어 정말 기쁩니다. 여기에서 많은 숫자가 변경되었습니다. 우리가 내부적으로만 게임을 했다면 분명하지 않았을 것입니다. 각 플레이어는 자신의 방식으로 설정되는 경향이 있으므로 조각을 움직이는 몇 개의 추가 손을 사용하면 어떤 숫자를 높이거나 낮추어야 하는지 알 수 있습니다.
또한 동일한 웨이브 중에 사소한 업데이트를 제공할 수 있었습니다. 첫 번째 플레이 테스트에서 깃발 건설이 너무 좋은 경우 비용을 약간 올리거나 최종 점수 집계를 약간 줄일 수 있습니다. 개별 깃발 건물이 전체 결과를 흐리게 만들지는 않겠지만 이러한 작은 변화는 여전히 우리가 더 큰 그룹으로 가기 전에 작은 것들을 파악할 수 있는 기회를 주었습니다. 즉, 각 개별 변경 사항은 여전히 내부 변경 로그 및 피드백 양식에 표시되어 있으므로 계속 추적했습니다. 뭔가 고장 나면 우리는 알 수 있습니다.
두 번째 질문은 "게임을 하는 느낌이 어떻습니까?"였고, 다시 "당나귀에 대해 어떻게 느꼈습니까?"와 같은 보다 다루기 쉬운 질문으로 분류되었습니다. 또는 "연결에 대해 어떻게 느꼈습니까?" 또는 "게임 길이는 좋았습니까?" 여기서도 엑셀 시트가 도움이 되었습니다. 예를 들어, 기분이 좋다/직관적으로 느껴졌던 행동과 취한 행동의 수 사이에는 명확한 상관관계가 있었습니다. 이것은 액면 그대로 들립니다. 건물을 만드는 것이 기분이 좋다면 플레이어는 더 많이 할 것입니다. 그러나 수행되는 횟수가 증가하기 때문에 후속 테스트에서 조치가 기분이 나아지기 시작했는지 여부를 확인할 수 있으므로 숫자를 갖는 것에는 항상 가치가 있습니다.
또한 Google 양식을 통해 플레이 테스터의 피드백과 플레이 테스트 후 포커스 그룹 토론을 수집했습니다. 솔직히, 우리는 리셉션에 꽤 실망했습니다. 일반적으로 내부 플레이 테스트 감정과 외부 감정 사이에 불일치가 종종 있기 때문에 이 시점에서 플레이 테스트 프로세스에 거대한 딸꾹질이 있습니다. 내부 테스트에는 잘 아는 사람들이 있으므로 그룹이 아닌 사람들을 대상으로 할 수 있으므로 가르치는 것이 훨씬 쉽습니다. 게다가 보드게임 회사에 있는 사람들은 보드게임에 능숙한 경우가 많기 때문에 무게 허용 범위가 외부 테스트만큼 넓지 않습니다. 마지막으로, 내부적으로 사람들이 당신을 이해하게 되며, 이는 더 큰 커뮤니케이션 허용 범위를 제공합니다. 외부 플레이 테스터가 게임에 대한 귀하의 의도를 항상 이해하는 것은 아닙니다.
작은 촌락우리는 이미 SPIEL에서 초기 내부 버전을 보여주었습니다. 이것이 좋은 일인지 나쁜 일인지 다른 사람이 토론하게 할 것입니다. 한 가지 좋은 점은 우리가 사람들을 대상으로 한 데모 동안 게임이 어떤 느낌이었는지에 대한 정보가 이미 꽤 많았다는 것입니다(숫자만큼은 아니지만). 그러나 플레이어의 감정에 대한 논쟁의 뼈대는 분명했고 이러한 포커스 그룹을 시작하기 전에 우리는 이미 효과가 있는 것과 그렇지 않은 것을 잘 알고 있었습니다.
대규모 플레이 테스트
이 웨이브에서 우리가 살펴본 첫 번째 질문은 "플레이어가 햄릿 을 경험하고 있습니까?" 였습니다. 이 질문이 상당히 모호해 보이지만 설명하겠습니다.
당시 햄릿 은 데이비드와 내가 함께 작업한 첫 번째 게임이었습니다. 그는 매우 재능 있는 디자이너이고, 나는 전체 개발에 있어 괜찮은 사람이라고 생각합니다. 그러나 우리는 여전히 프로젝트에서 자주 난관에 부딪쳤습니다. 그는 나에게 흥미로운 디자인을 주었지만 분명히 약간의 차이가 있었습니다. 한 번의 반복으로 나는 경제 주입을 철저히 조사했습니다. 다른 버전에서는 다른 가방 제작 메커니즘을 제안했습니다. 다른 시간에는 개별 플레이어 보드에 대한 아이디어를 가지고 놀았습니다. 등등.
내가 무언가를 제거하고 그가 다른 것을 추가하는 것을 n번째 반복한 후에, 우리 문제가 개념 문제라는 것이 분명해졌습니다. 개발자로서 나는 Hamlet 이 공정하고, 깨끗하고, 배우기 쉬우며, 룰 오버행이 없는 등 기능적인 게임을 원합니다. 그러나 디자이너로서 David는 Hamlet 에 대한 비전을 가지고 있었습니다 . 그는 공유에 대한 게임을 만들고 싶었습니다. 도시가 성장함에 따라 물류가 더 어려워지는 거대한 도시에 대한 게임, 모든 일이 일어날 시간이기 때문에 모든 일이 일어나는 유기적 성장에 대한 게임을 만들고 싶었습니다. 나는 그가 이 비전을 전달할 수 있었을 때에만 우리 둘 다 만족스러운 버전을 얻었다고 생각합니다. 그때부터 개발이 정말 순조롭게 진행되기 시작했고 숫자나 게임 흐름과 같은 쉬운 일에 집중할 수 있었습니다.
따라서 첫 번째 질문은 매우 명확했습니다. 나는 마침내 David의 의도를 얻었지만 외부 플레이어가 마침내 Hamlet 에 손을 뻗기 시작했을 때 그들의 의도도 이해했을까요? 각 플레이어가 자신의 방향(당나귀, 도로, 정제, 건물 또는 기타)을 가질 수 있지만 모두가 공동 보드의 기쁨을 느끼고 부담을 관리할 수 있도록 경험을 충분히 정리하고 지시했다면 거대한 도시에 의해 부과되었습니다. 처음에는 이에 대한 피드백을 받는 것이 어려웠지만 궁극적으로 매우 유용한 데이터를 수집할 수 있었습니다.
우리가 집중한 두 번째 질문은 "게임이 어떤 식으로든 중단될 수 있습니까?"였습니다. 게임은 정말 과감하지만 더 미묘한 방식으로 중단될 수 있습니다. 때때로 게임 상태가 플레이할 수 없게 될 수 있습니다. 햄릿 의 이전 버전플레이어가 반사회적으로 플레이하면 돈을 받을 수 없는 게임 상태였습니다. 이것은 우리가 고맙게도 아주 빨리 발견한 바람직하지 않은 상태입니다.
그러나 때때로 게임 상태는 단순히 플레이하기가 덜 즐거워질 수 있습니다. 게임이 너무 오래 끌리는가, 너무 느리게 증가하는가, 적절한 속도로 게임에 리소스를 주입하는가, 더 많은 작업자를 추가하면 정신적인 부담이 가중되는가 바람직하지 않은 방법 등. 이 모든 것이 게임에 균열을 일으키지만, 돈을 벌 방법이 없는 것이 펑크난 타이어와 같다면, 후자의 조건은 느린 펑크와 더 비슷합니다. 공기가 빠져나간 후에야 알게 될 것입니다. 훨씬 더 오래 사용됩니다. 게임이 천천히 공기를 내보내는지 알아보는 가장 좋은 방법(아마도 유일한 방법일 수도 있음)은 스트레스 테스트를 통해 타이어가 펑크날 때까지 최대한 다양한 사람들과 최대한 많은 게임을 하는 것입니다! 그것이 우리가 외부 테스트를 통해 달성하려고 했던 것입니다.
블라인드 플레이
테스트 블라인드 플레이 테스트에서 두 가지 주요 질문을 합니다. 첫 번째 질문은 "규칙집이 이해할 수 있습니까?"입니다. 우리는 Hamlet 이 플레이어의 상호작용과 틀에 얽매이지 않는 메커니즘으로 인해 복잡해지는 정말 간단한 게임의 핵심이라고 생각합니다. 특히 햄릿 에게는 좋은 규칙이 가장 중요합니다 . 3-웨이트 게임을 2처럼 느낄 수 있습니다. 핵심 경험을 명확하고 효율적인 방식으로 플레이어에게 전달할 수 있다면 모든 플레이어가 자신의 것을 가질 수 있다고 진정으로 믿습니다.
블라인드 플레이 테스트에서 우리가 묻고 싶은 두 번째 질문은 "플레이어가 게임 플레이 중에 기억해야 할 정보가 있습니까?"입니다. 이것은 이미 우리가 계속 주시하고 있는 것이지만 우리가 거기에 있다는 맥락에서만 가능합니다(질문이 쉽고 간결하게 답변될 수 있도록). 우리가 거기에 없으면 어떻게됩니까? 플레이어가 질문에 쉽게 답할 수 있습니까? 우리는 규칙 오버행이 가볍거나 존재하지 않는다고 생각하지만 다른 사람들도 그렇게 느끼는지 측정하는 것이 좋습니다. 보드 게임은 커뮤니케이션의 핵심입니다. 블라인드 플레이 테스트는 우리가 (아직) 당신의 거실에 실제로 있지 않을 때에도 우리의 디자인을 전달할 수 있는지 확인하는 데 도움이 됩니다.
이 두 가지 질문에 대해 우리는 새로운 포커스 그룹을 만났고 디자이너로서 우리에게 가장 어려운 일을 했습니다. 닥치고 놀게 두십시오. 첫 번째 조수를 위해 우리는 그들이 상자를 얻는 순간부터 그것을 압축해야합니다. 그들이 규칙서를 집어들게 하고, 그것을 읽고, 학습 과정을 시간을 쟀습니다. 룰북에 틀린 부분이 없는지 살펴보고 (플레이테스트 후 설문지를 통해) 어떤 표현이 오해를 불러일으켰는지 알아내려고 노력했습니다. 두 번째 조수를 위해 우리는 그들이 스스로 룰북을 읽게 했지만, 발생한 오해를 해명했습니다. 그런 다음 플레이 테스트 동안 침묵을 지키며 게임 플레이 중 어떤 규칙이 깨지는지 확인합니다.
이전의 파도와는 반대로, 이 두 조수는 서로 밀물과 썰물을 일으켰습니다. 보드 게임, 특히 출시가 임박한 경우 리뷰어나 퍼블리셔, 다른 디자이너와 개발자, 심지어 배포자까지 많은 사람들의 손에 넘어가게 됩니다. 이러한 각 당사자는 다른 방식으로 게임을 처리하기를 원합니다. 어떤 사람들은 순수한 경험을 하고 싶어하고(그래서 우리는 적어도 볼 수 있는지 묻습니다), 다른 사람들은 스스로 이해하기를 원하지만 완료되지 않은 일(이 경우 규칙 책)에 너무 많은 시간을 소비하지 않기를 원합니다. . 조류가 확실히 어리석은 것처럼 느껴졌기 때문에 규칙 피드백(명확성 또는 유지 여부)을 거부합니다.
오늘날까지도 우리는 물리적으로 존재하는지 여부에 관계없이 블라인드 테스트로부터 피드백을 받고 있습니다. 결국, 플레이어가 게임을 거실로 가져오거나 BGG에 좋은 댓글을 남기는 즉시 우리 벨트 아래에 있는 또 다른 비공식 블라인드 테스트입니다. 우리 회사의 친한 친구이자 더 나은 디자이너가 게임을 플레이하고 블라인드 룰북 피드백을 주었습니다. 비록 게임이 세계의 7개 바다(또는 그 중 적어도 2개)의 보트에 있음에도 불구하고 지난 주까지만 해도 말입니다. 이 피드백은 첫 번째 사본에 포함되지 않지만 우리는 Hamlet 을 믿습니다., 그래서 우리는 롤링 온라인 룰북과 미래의 룰북을 계속 업데이트할 것입니다(아마도 미래의 흥미진진한 확장에 앞서?). 그럼에도 불구하고 인쇄본에 대한 가장 최근의 변경 사항은 여전히 매우 명확합니다. 블라인드 테스터와 Discord의 훌륭한 사람들 덕분에 룰북뿐만 아니라 그래픽 디자인에도 많은 QOL 변경 사항이 있으므로 상자를 사용하는 경험이 고품질의 버터처럼 매끄럽게 느껴지기를 바랍니다. 우유.
결론
Playtesting은 전체 책은 아닐지라도 책의 챕터일 수 있으므로 여기에서 너무 자세히 설명하지 않았습니다. 그러나 이 게시물은 다음과 같은 몇 가지 핵심 사항을 제공했으면 합니다.
• 모든 플레이 테스트에는 질문이 필요합니다(그러나 모든 플레이 테스트가 반드시 좋은 답변을 제공하지는 않음)
• 사람들이 답을 줄 수 있도록 도와주세요(안내하지만 이끌지 마십시오. 좋은 질문은 열려 있습니다. 질문, 반드시 닫힌 답변이 있어야 합니다!)
• 웨이브에서 플레이 테스트하고 이 웨이브가 끝날 때까지 큰 변경 사항을 유지합니다(사소한 변경 사항은 종종 괜찮습니다. Sharpie 스트로크가 해결하면 큰 문제가 아닐 수도 있음)
• 플레이 테스트 시간을 정하십시오. 어떤 종속성과도 일치시키려면
• 오래 걸리는 게임은 값비싼 게임입니다(당신의 시간도 비용입니다, 동료 디자이너)
• 개발 워크로드를 관리 가능하게 만드십시오.
• 쉬운 질문 을 하십시오.
• 여러 질문을 하십시오.
• 기록 가능한 질문을 하십시오(파도 및 조수, 파도 및 조수)
이상입니다. 게임 플레이 테스트를 돕고 싶다면 Discord 에 가입하여 현재 테스트 코디네이터와 연락할 수 있습니다. 우리는 항상 피드백도 기다리고 있습니다. 특히 플레이 테스트에 관한 긴 BGG 게시물을 즐겨 읽는 사람들의 피드백도 기다리고 있습니다.
조나단 해링턴