What! Studio : 밸런스 기획이란 무엇인가
Created by 방영훈 [zerasion], last modified on 4월 26, 2018
강연 내용 정리
1. 좋은 밸런스 방법
- 선택지를 가치있게 만든다
- 성장 피드백을 체감할 수 있게 한다
2. 밸런스 절차
- 기준 선정 - 데이터 입력 - 피드백 반영
- 기준 선정
- 효용 가치를 설정한다.
- 투자 대비 소득이 어느 한 쪽의 효용 가치가 크거나 적지 않게
- 서로 다른 선택지가 모두 의미 있게 만들기 위해 다음과 같은 방법을 사용해볼 수 있다.
- 보상의 종류를 서로 다르게 설정한다.
- Ex) 던전 A는 골드 보상, 던전 B는 랜덤 장비 상자 보상
- 골드가 필요한 플레이어는 A를, 장비가 필요한 플레이어는 B를 플레이
- 진입 제한 조건을 설정한다.
- Ex) 던전 A와 B 모두 골드 보상이며, A = 10,000 골드, B = 5,000 골드일 때
- 당연히 A의 효용 가치가 더 높기 때문에 플레이어들은 모두 A 던전만 플레이하고 B 던전은 버려질 것
- 하지만 A는 하루에 한 번만 입장할 수 있다는 식으로 제한 조건을 설정하면 해결 가능
- 플레이어 상황에 따라 선택할 수 있도록 설정한다.
- Ex) 두 던전 A와 B의 시간 당 소득이 A>B일 때, 클리어에 A는 60분, B는 10분 필요한 경우
- 효율은 A가 높지만, 60분짜리 컨텐츠를 플레이할 수 없는 환경의 플레이어는 조금 적은 보상을 받더라도 B를 선택
- 충분한 시뮬레이션을 진행한다.
- 대안을 마련할 수 있도록 초기 기준을 선정한다.
- 후하게 설정한 수치를 이후 패치로 낮추는 것은 부정 동향을 야기시킴.
- 보수적으로 접근하고 이후에 피드백에 따라 조금씩 완화하는 방법이 안전함.
- 데이터 입력
- 밸런스 작업은 데이터 양이 많고 변경이 잦기 때문에 최대한 자동화를 활용해야 한다.
- 속도가 빠르고, 실수를 줄여줌
- 자동화가 어려운 경우는, 두 명의 작업자가 동시에 작업하고 결과가 동일한지 비교해본다.
- 비효율적일 수 있지만, 결제 관련 내용 등의 주요 데이터는 안전하게 작업해야 함.
- 캐시 아이템 상점 설정 등
- 피드백 반영
- 내부 테스트 결과 또는 실제 라이브 플레이어 동향에 따라 피드백을 반영한다.
- 기준 선정 단계부터 다시 진행해야 할 수도 있고, 설정한 기준에 맞지 않는 데이터를 변경해야 할 수도 있다.
- 전체적인 데이터를 다각도로 분석하고 상황에 맞는 수정 방안을 선택
참관 후기
전체적으로 입문자 청강 레벨의 세션이라 강연 제목처럼 "밸런스 기획이란 어떤 업무인가"를 설명하는 자리였습니다.
실무자를 대상으로 한, "진정한 밸런스 기획이 무엇인지 제가 보여드리겠습니다!"라고 잘못 읽히기 좋지만, 어쨌든 제목 그대로에 충실한 강연이었습니다.
다만 입문 단계다보니, 간단한 문제 제시와 1차적 해결법을 알려주는 정도에서 그쳤기 때문에 딱 한 단계만 더 들어가서 질문해보면 의문점들이 많이 생기기도 합니다.
먼저 보상의 종류를 다양하게 마련해 각 컨텐츠의 효용을 지키도록 설정한다는 내용은, 거시적으로 결국 그 서로 다른 보상이 하나의 단일 가치로 환산될 수 있다면 마찬가지로 플레이어들은 가장 효용 가치가 높은 컨텐츠를 선택적으로 소비하게 됩니다.
던전 A는 골드를 주는데 던전 B는 장비를 준다. 그런데 그 장비를 골드로 가치 환산할 경우 장비 등급 및 개수와 지급 확률에 따라 결국 어느 던전이 더 좋은 던전인지를 판단할 수 있습니다.
진입 제한 조건은 너무 명쾌한 해법이라 딱히 이견이 없지만, 그 다음 플레이어 상황에 따른 선택이라는 부분이 사실 가장 큰 의문점을 남겼습니다.
60분짜리 컨텐츠가 더 좋은 보상을 제공하는데, 플레이어 여건이 따라주지 않아서 보상도 적은 10분짜리 컨텐츠를 플레이할 수 밖에 없다면, 결국 여건을 갖춘 플레이어들의 이점이 누적되면서 전체 플레이어들의 파워 스케일이 고르게 분포되지 못하고, 심지어 상황에 따라서 컨텐츠의 이용자 자체가 줄어들게 되는 결과까지 가져올 수 있습니다. 이런 부분이 과연 "예시로 들기에 적합한 해법이었을까?"라고 다시 생각해보면 개인적으로는 오히려 위험성이 높은, 잘못 사용되기 좋은 예시가 아닌가 살짝 근심을 가져보게 됩니다.
신선한 내용은 데이터 크로스 체크 부분이었습니다.
한 작업자의 작업 내용을 적용/배포하기 전에 다른 작업자가 추가 검토하는 이른 바 Peer Review 시스템이 지금까지 제가 접해본 바로는 일반적인 크로스 체크 방식이었는데요, 강연에서는 서로 다른 두 작업자가 각각 같은 작업을 진행하고 그 작업이 일치하는 지 확인하는 크로스 체크 방식을 소개했는데 매우 납득되면서도 신기했습니다. 이미 작업된 내용을 검토하는 것은 직접 입력과 달리 검토에서 누락되는 부분이 필연적으로 발생할 수 밖에 없는데 각자 작업하고 작업 결과를 비교한다면 그런 부분은 확실히 적어질 것 같았습니다.
다만, 누가 작업해도 작업자 관점에서 벌어지는 실수를 둘 다 반복해서 결과물의 Diff 상에는 오류가 없었지만 결국은 데이터 결함이 발생할 수 있다. 라는 가능성이 완전히 없어지지는 않았기 때문에, 근본적인 해결 방안이라기보다는 "이런 방법도 있구나" 정도의 의의가 있던 것 같습니다.
Comments:
Document generated by Confluence on 5월 02, 2019 16:24