1편 : http://gall.dcinside.com/mgallery/board/view/?id=trpg&no=58863


-----


저번 편에서는 '자작룰은 만든 놈이 아니면 써먹기가 힘든 경우가 많다' 는 결론에서 끝이 났어. 


이번편에선 그 부분에 대해서 이어서 쓸게


-----


1) 자작룰은 정말로 남들이 다루기 힘든가?


선문답이지만 꼭 자작룰이라고 남들이 쓰기 힘드라는 법은 없어. 

그냥 그 룰이 좆같아서 그런거야. 자가경험에서 말하자면 내것도 자작룰이지만 다들 쉽게쉽게 마스터링에 쓰거든


자작룰이라는 편견 때문에 팀원이 안모여요 ㅜㅜ 같은건 내가 여기서 해결해 줄순 없고..  기술적인걸 쓸게


그럼 굳이 '자작룰' 만 꼬집어서가 아니라(대부분 자작룰의 문제점들로 비추어지겠지만),도대체 어떠한 룰의 좆같음이 '마스터링 하기 어려운' 룰을 만드는건지 살펴보자


-----


2) 실사용 문제


자작룰은 시스템도 세계관(설정)도 뭐 그렇게까지 나쁘진 않은데, 도저히 만든놈이 아니면 못써먹겠거나, 만든 놈도 정작 마스터링을 해보면 잘 안굴러갈때가 꽤 많아

이건 룰을 만드는 과정에서 '실사용례'를 깊게 생각하지 않고 만든 경우에 이런 일이 생겨


줄줄이 길게 설명충 하느니 예시들로 채울게


1) 권장인원은 5인이라고 정하고 룰은 만들었으나, 어떻게 5명의 플레이어를 수용하고 , 3인도 4인도 6인도 아닌 딱 5인이 권장인원이어야 하는 설계 요소를 고려하지 않음

2) 이걸로 플레이를 하면, 몇시간 정도의 세션을 하게 될지 생각하지 않음. 생각을 했더라도, 그 시간을 구간 단위로 잘라서 매듭을 어떻게 연결해야 될지 설계하지 않음

3) 룰이 다룰 것은 많으나, 플레이의 시작 부분, 기승전결의 '기' 를 어떻게 다뤄야 할지, 그리고 그 '기' 부분에 대한 충분한 설계적 지원의 부재

4) 참여한 각 캐릭터(PC) 마다 어느정도의 활약과 역할을 부여하고, 분배하고, 나누고, 관리해야 될지에 대한 '인적자원' 처리 부분에 대한 설계의 부재

5) ☆예외처리 설계의 부재


1~4번에 대해서는 추가 설명이 필요 없고, 5번에 대해서 깊게 파보자 



2-1) 예외처리란?


프로그램 용어로, '의도,기대한 결과값이 아닌 것이 나왔을때의 취급방침/행동방침' 을 말함


대부분 논리/설계나 알고리즘의 소양이 부족한 사람들이  예외처리와 오류/버그를 혼동해서 용어를 스까버리는 경우가 많은데, 완전히 다른것이고 어떻게 다른것인지까지 설명하기에는 여백이 너무 적어서 "TRPG 구조에서의 예외/오류/버그 를 구분하고 취급하는 법" 에다가 나중에 쓰도록 하겠다


이런 예외처리를 위한 룰의 기능중에 가장 단순한 예시는 '캐릭터의 사망과 부활' 과 관련된 룰이라고 볼수 있어.

룰의 특색에 따라 취급이 다르긴 하지만, 캐릭터의 사망이라는건 이야기 내에서 한명의 인물이 뚝 실이 끊겨버린거고, 

그래서 이것저것 페널티를 지거나 대가를 치루더라도 부활을 할수 있는 규칙을 갖춘 룰들이 꽤 있지


대놓고 살의의 파동에 눈을 뜬 마스터거나, 이벤트/스토리에 맞춰서 사망하는게 아닌 이상 얼마든지 주사위 신의 변덕으로 캐릭터는 사망하고,

의도치 않게 맥이 뚝 끊길수 있지. 이런 '예외처리'를 위해서  부활과 관련된 규칙을 적어 두는걸 예외처리라고 이해하면 돼


자작룰들은 플레이 내에서 벌어질수 있는 이러한 '예외적 상황에 대한 처리' 에 매우 취약해(이게 구린 수준미달 상업룰들도 널렸어

만들때부터 완성시킬때까지 룰의 중심인 A 라는 컨텐츠를 효과적으로 구현해내는데 눈이 멀어서 

실제로 게임 내에서 A를 수행하기 위해서 벌어지는 온갖 예외적 상황에 대한 준비가 덜 되어있지

물론 '게임마스터의 재량' 으로 처리할순 있겠지만, 그런것까지 따지면 이번 장의 취지와 안맞으므로 나중에 또 쓸게


즉, 룰을 만들때는 실제로 플레이가 벌어질 상황에 맞추어 어떠한 변수들이 작용될수 있는지 한번씩 점검해 보는게 좋아.


이건 굳이 테스트를 해보지 않아도 개발단계에서 깨달을수 있어, 판정이나 시스템 등을 하나하나 살펴보면서 

'이 판정들이 실제로 플레이에서 어떤 상황에 쓰일까? 기승전결중 어떤 상황에 쓰일까?' 라던가

'이 아이템 때문에 좆같은 일이 생기는 일은 없을까?' 같은걸 짚어보는거지.


대부분 자기 룰이 완성이 되어갈 시점에선 너무나도 뽕이 한가득 차있어서 잘 안들여다보게 돼..

자기가 힘들게 써놓은 룰의 '실사용시 좆같을수 있는 점'을 찾는건 힘들거야. 



3) 게임마스터의 영역


상업룰과 자작룰의 가장 큰 차이는 게임마스터로써 이 룰을 어떻게 다루어야 하는 방침이 알려져있냐 아니냐도 커


상업룰이라면 게임마스터용 가이드라인이 따로 제공이 되거나, 굳이 읽는게 싫어도 이미 많은 사람들이 그 룰을 쓰고 있으니 몇번 플에 참여해보고 'ㅇㅎ 이렇게 하는거구나!' 하고 깨닫고 따라하면 돼


하지만 자작룰은 그게 없어, 어떻게 다뤄야 하는지도 어떻게 세션을 열어야 될지도 감이 안오지 


여기서 자작룰 제작자로써 네가 선택할수 있는건 아래의 세개중 한가지야


1) 충분한 샘플을 제공한다. 시나리오샘플이나 세션데이터 샘플, 혹은 내용이 주작이어도 좋으니 리플레이 같은걸 써서 동봉해도 좋아

2) 게임마스터 가이드 란을 따로 작성한다.  길고 어렵지만, 사실 이게 제일 좋긴 해. 방침들도 정하기 좋고

3) 1,2번이 모두 귀찮다면. GM의 권력/권한을 확대하고, GM의 재량에 내용을 맡김에 대해서 뚜렷하게 언급하면 돼. 근데 이건 대놓고 아몰랑 하는거라 인식이 좋진 않을거야



4) 직관적이고 쓰임새 좋은 세계관/설정


이건 길게 말할 것도 없어, 본인의 설정 딸에 키야 취한다~ 하고 죽죽 써내려가도 좋지만, 저번장에 쓴 인터페이스 부분에도 해당되지만


역시 좋은 '떡밥' 을 잘 제공해주는 것 만큼 자작룰에서 매력을 느끼기 좋은 법도 없어. 


자신의 자작룰이 남들도 잘 써줬으면 좋겠다면, '오 좀 뽕 차오르는데?' 싶은 떡밥/설정을, 그 중에서도 세션에 구체적으로 써먹기 좋은 직관적인 것으로 잘 넣어 보도록 해



-----------


쓰다보니까 너무 길어지고 다들 장문은 싫어하니까 'TRPG룰 에서 예외/오류/버그' 를 구분,취급하는 법에 대해서 쓰고


다음 장에선 'TRPG룰이 ORPG환경에서 구린 이유' 와 TR과 OR의 구조적 차이에 대해 쓸게


다들 열심히 질좋은 자작룰을 만드는데 도움이 되면 좋겠음


-------------------



TRPG 구조에서의 예외/오류/버그 를 구분, 취급 하는 법


1) 예외


이미 위에서 예시와 함께 설명 했으니 생략한다


2) 오류


사실 컴퓨터 소프트웨어 같은 튜링머신 구조가 아닌, 사람이 주사위를 굴리는 TRPG룰에서 '오류'를 정의하기란 힘들어


플레이 중에는 기껏해봐야 '엌 나 수치 잘못 넣음' "으앜 나 주사위 잘못 썼어요 2d6가 아니라 3d6였음" 이런게 '오류' 겠지

아니면 진짜로 룰에다가 오타를 넣었거나 숫자를 잘못 넣어서 오류가 났거나 하는거지


예외처리는 '룰 자체에선 문제가 없지만 플레이를 저해할수 있는 변수' 라고 볼수 있었어

위에서 말한 오류는 '룰 자체에 문제가 있는것이나 취급에 문제를 일으킴' 이지


3) 버그


사실 이 항목을 쓰게 된건 예외와 버그를 구분짓고 싶어서 쓴거야.


TRPG룰을 쓰다보면 몇번씩 두가지 이상의 해석이 겹치면서 무엇을 우선 처리해야 되는가? 에 대한 부분이 많아.

이건 명백하게 프로그램에서 봐도 버그라고 할수 있어.


왜? 고장난건 아니잖아? 라고 할지 모르겠지만, 버그는 반드시 기능이 고장난게 아니라 기능이 븅신같은 결과를 낳아도 버그라고 해

가장 쉬운 예시는 창과 방패야   '롱소드: [방어구]를 반드시 파괴함'  하고   '방패: 파괴불가' 가 한 전투에서 맞 부딫히면 도대체 어떻게 할건데?

무엇을 우선처리 할것이고 이런건 GM재량이나 스토리/연출 에 맞추기도 참 애매해


자작룰을 만들다 보면 컨텐츠를 넣는 뽕에 취해서 이렇게 아이템이나 판정들이 서로 버그 충돌을 일으키는 두가지 이상의 요소를 집어넣는 경우가 허다해.



*'예외처리' 부분은 GM의 재량으로 처리가 용이하다. 자작룰을 만드는 시점에선 넣으면 좋으나 없어도 재량에 맡길수 있다

*'버그' 부분은 GM의 재량으로도 어찌하기 흠좀무한 경우가 생김. 이런건 필수적으로 따져가면서 룰을 만들어야 함


--------


댓글에 질문은 환영이야 



*추신: 글을 보다보면 내가 서사보다 데이터딸 치는 룰을 즐길거 같이 느낄수 있는데, 난 서사를 더 즐기고 그걸 훌륭히 지원하기 위한 룰의 설계에 더 집중하는 편이야

 TRPG에서의 서사도 프로그래밍과 공학적 관점에서 흥미롭게 얼마든지 분석할수 있어. 나중에 쓸게