플라잉(그래플 걸려도 낙하 안 함) 턀치맨에 새로운 선장이 왔다.
왕이 죽었다. 국왕 만세!
모두 새로운 턀갤에도 재미있는 번개플과 텍섹이 활발하기를 기도하자.
그런데 내가 이 짓거리를 왕조가 넘어갈 때까지 계속하게 될 줄은 몰랐네...
아무튼, 그래서 이번에 작업을 완료... 하지는 못했지만, 아무튼 좀 급하게 보고하는 매크로는
다름아닌 [제압 사격]이다.
대충 이런 소사를 묘사하는 룰이라고 생각하면 됨.
댄디 식으로 표현하자면, 한글판 DMG 267p의 총화기 관련 '연사' 룰과 거의 같은 개념이다.
표적에 대해서 사격을 하는 게 아니라, '칸'에 대해서 사격하고 거기에 있거나 진입하는 적에 대해
일종의 내성 굴림(건독 용어로는 [회피 행동])을 요구해서,
달성치가 제압 사격의 달성치보다 낮으면 실패하면 피해를 입는 방식.
건독에서는 회피 행동을 하면 다음 행동을 잃어버리므로
걍 맞고 버틸 수 있는 몸빵이 아닌 한, 이미 성공한 제압 사격은 유용한 CC기이기도 하다.
이렇게만 보면 참 간단해보이고,
실제로도 한 칸에밖에 사격할 수 없는 단발/점사 화기의 제압사격은 간단하게 만들 수 있었다.
기존에 만들어뒀던 스킬 체크 매크로를 좀 수정하면 됐으니까.
약간 쓸데없는 기교를 부려서,
사격의 명중 여부에 따라서 다른 단추가 나오게 하는 짓을 하느라 시간을 좀 잡아먹었지만...
그리고 크리티컬 나온 거 보여주겠다고 몇 번 돌렸는데, 크리티컬보다도 베어리(1 성공)와 펌블이 먼저 뜨더라.
이거 새 왕의 즉위에 대한 상서로운 징조라고 쳐도 되려나???
근데 솔직히 저 '크리티컬' 설명은 굳이 필요한가 싶기도 하고.
아무튼.
자, 그러면 뭐가 문제냐?
'연사'가 있는 화기, 자동소총이나 기관총의 경우는 더 많은 총알을 퍼부을 수 있으므로
한 턴에 최대 50발까지의 자동 사격이 가능하다.
댄디 고인물이라면 화염 폭풍(Fire Storm) 주문을 생각해도 좋을 것 같다.
칸끼리 서로 인접해 있다면, 몇 개의 칸을 이어지게 제압 사격을 가할 수 있다는 식이지.
그런데 댄디 화염폭풍은 그냥 10*10*10ft 입방체 10개로 고정되어 있다면, 건독은
1. 최대 50발의 총알을 임의로 분배하되
2. 한 칸에는 최소 10발의 총알을 분배해야 하며(즉 최대 5칸)
3. 한 칸에 할당된 총알 10발당, 1회의 제압사격 굴림이 이루어지며
4. 한 칸에 할당된 총알의 개수마다 명중률에 보정이 붙는데
5. 총 몇 개의 칸을 대상으로 제압 사격을 했는지에 대해서도 보정이 붙는다는
말로 설명하면 간단해 보이지만
이걸 코드 상으로 구현해 보려 하면 매우매우 번거로운 룰링이다...
하물며 이건 Roll20 무료 기능이 지원하는 한계 내에서 작동해야 하는 매크로란 말임.
내가 주사위 굴림을 했는데, 이게 몇 번째 칸의 몇 번째 사격에 대해 한 판정인지 파악하는 게
매크로 내부적으로 처리하는 것도 골아프지만, 사용자 입장에서도 헷갈리기 짝이 없고.
결국 '사수의 이동 방식'은 다 같은 값을 공유하는데도
이걸 별개의 매크로로 분리해 버리면, 입력했던 값을 쿼리에 일일히 다시 입력해 줘야 하고...
이런 문제를 겪을 게 명백한지라, 고민을 많이 했다.
결국에 문제는 그거임, Roll20에서 변수에 어떤 값을 저장해 놓는 게 불가능하다는 거.
API를 쓰는 이유도 따지고 보면 그게 가장 클 거고.
'몇 번째 칸에 몇 개의 총알을 할당해 놓았나'랑 '사수의 이동 방식' 정도만 어디 저장해 놓을 수 있으면
아무리 계산과정이 복잡하다고 해도,
몇 개의 매크로를 연이어 쓰게 하면 별 문제 없이 해결할 수 있을 거거등...
...음, 잠깐만.
'변수에 어떤 값을 저장해 놓는 게 불가능하다'...고?
언제부터 'Turn Tracker에 2^53 - 1까지의 숫자를 저장할 수 없다고 착각한 거지?
뭐... 라고?
아니... 어차피 이 턴 플레이어는 매크로 상당수를 구동하기 위해서
자기 토큰을 선택한 상황이어야만 하니
그냥 &{tracker:+}로 간단하게 turn tracker에 값을 덧셈 저장할 수 있다는 건 맞지만...
@{tracker|token_id}로 tracker의 값을 가져올 때는, selected를 쓸 수가 없지 않...
Prefix란, Prefix에 매달리지 않고선 살아갈 수 없는 무료계정들을 위해 존재하는 것인데.
포럼에는 이미 Turn Tracker Pointer라는 테크닉이 연구된 바 있더라고.
결국 Roll20 매크로 작성에서 가장 골 아픈 건 '모든 roll의 계산은 순서상 마지막에 처리되기 때문에,
이 값의 결과에 따라서 다른 매크로를 불러오려고 하면 chat의 버튼 형태로 불러올 수밖에 없는데,
이렇게 다른 매크로를 호출하면, 앞의 매크로에서 얻은 값 상당수를 뒤의 매크로로 보내줄 방도가 없다'는 점인데
이 테크닉을 동원하면, 원래 이니시 값을 보존한다 해 봤자 몇 자리 안 될 것임이 분명하므로
남은 이니시 칸의 여유분을 '5~6바이트 가량의 메모리' 로 사용할 수 있음!
이렇게 적당한 값을 곱해서 턴 트래커에 저장하고
나눗셈과 나머지 연산을 반복해서 값을 호출하면 되니까.
물론, 건독은 이니시가 이론상 세자릿수가 능히 될 수 있는 룰이기 때문에
이 짓을 한다고 해도 제압 사격에 필요한 모든 데이터를 매크로에 저장할 수 있냐 하면...
갖은 잔머리를 굴려서 경우의 수 나눠 가며 데이터를 압축하는 짓을 하니 진짜 아슬아슬하게 되더라;;
생각해 보면 판정에 필요한 데이터가 5바이트가 넘는 건독은 똥룰이 맞는 거 같다...
아무튼, 그러면 이제 문제는 간단해졌다.
먼저 이런 식으로 제압 사격에 사용할 제원들을 설정하게 해서,
그 결과에 따라서 각 칸의 '굴림'을 하도록 만들면 되는 거지.
부적절한 값이 입력될 때는, 이렇게 에러 메시지를 띄우면서
'첫째 칸 굴림' 단추를 날려버리면 될 테고.
그리고 이렇게 최대 5번의 '첫째 칸 제압 사격'을 굴리는 식.
물론 5번의 사격을 전부 한 번에 체크하므로, 렉은 어마무시하다...
그래도 뭐, 솔직히 제압 사격 정도면 주사위를 직접 굴린다 해도
그리 빨리 되지는 않을 거라는 점을 위안 삼도록 하자.
이 경우는 50발을 한꺼번에 굴린 거지만, 만약 사격이 다른 칸에도 배분되어 있다면...
이런 식으로, 맨 마지막 줄에 다음 칸 굴림을 알리는 버튼이 나오므로
이걸 계속 클릭해 가면서 제압사격을 이어나가는 것이 가능한 식.
이걸로 대충 제압사격 판정 자체는 거의 완성했으므로
이제 [회피 판정], 제압 사격에 대한 대미지 굴림,
그리고 '제압 사격이 이루어진 턴이 아닌, 자신의 턴에 제압 사격이 된 칸에 진입한 캐릭터'를 위한
제압 사격 토큰 만들기... 를 순차적으로 완성하면, 제압 사격 관련 룰링도 완성!
...이 되었어야 했는데.
이런 유용한 테크닉을 지금까지 안 쓰려고 했던 데는 이유가 있는 게.
"아아~ 이런곳에서 쓰고 싶지 않았는데"
(대미지 판정 때 다시 입력해야 하는 '사격 모드')
"만약 내가 턴 트래커 포인터를 쓸 수 있다는 게 알려지면"
(대미지 판정 때 명중 판정의 결과를 일일히 다시 입력해야 했던 쿼리들)
"너 말고 다른 놈들도 나한테 변수 저장을 해달라고 할 거 아니냐."
(사격 말고도 걍 모든 판정마다 붙어 있는 이동 방법 수정치...)
ㅇㅇ... 저런 식으로 매크로 간에 수평적인 값의 '저장 및 이동'이 가능하다는 게 증명되어 버렸으니
이제 저런 귀찮은 부분들을 남겨놓을 명분이 없다...
이동 방식을 그냥 토큰 클릭만으로 받아올 수 있으면 얼마나 편할지 생각해봐.
물론 몇 가지 걸리는 점이 없지는 않음.
턴 트래커의 값을 참조하는 식으로 매크로를 동작하게 만들면,
턴 트래커를 끄거나 턴 트래커에 토큰이 올라가 있지 않은, 즉 맵 상에서의 전투가 아닌 상황에서
매크로가 동작하지 않을 거라는 점이라던가.
(근데 솔직히 내가 겪어본 마스터 대부분은 턴 트래커 끄는 것도 귀찮아했음...)
비전투 상황이 되거나, 기타 룰에 의해서 이동 방식이 바뀔 경우에
그걸 수동으로 처리해 줘야 하는 문제라던가...
(근데 룰상으로 이동 방식에 따른 수정이 바뀌는 건 스카우트의 '풋 워크' 정도뿐이고
그런 것을 수동 처리해 주는 거나, 판정 때 자기 이동방식을 클릭하게 하는 거나 같은 난이도 아닌가?)
건독은 '이동 방식'을 라운드가 넘어가도 자기 턴 전까지는 유지하기 때문에
'이동 방식'의 값이 턴 트래커의 정렬 알고리즘을 망가뜨리지 않으려면
이니시에 2**43 가량의 값을 곱해줘야 할 테고
그러면 PL들은 자기 이니시 값을 눈으로 확인 불가능할 거라던가...
(근데 이니시 값을 굳이 자기 눈으로 확인할 필요가 있나? 순서만 맞으면 되지...)
전부 내 기준으로는 별 문제가 아닌 거 같거든???
내가 느끼기에 가장 큰 문제점은 내가 귀찮다는 거다...
말했다시피 이동 방법 수정치가 없는 판정은 손에 꼽기 때문에
결국 기존의 모든 매크로를 뜯어고쳐야 하며
포인터 참조는 lnline Roll을 쓰기 때문에, index manipulation의 모든 order가 뒤틀릴 게 명백하니까...
그래서 결국 다음에 만들어야 할 건
turn tracker 처리에 가장 영향을 많이 줄 이니시 굴림, [전술 판정] 관련일 거 같고
그 이후로도 기존의 모든 매크로들을 수정하는 작업을 하고 나서야 [제압 사격]을 완성할 수 있을 거 같음.
미완성된 매크로를 보고하는 것도 이런 이유였음.
일단 작업이 재개되면 기존 매크로를 대대적으로 수정하는 게 우선시될 테니, 중간보고가 한참 미뤄질 테고.
더더구나 내가 생각치 못했던 문제가 내포되어 있음에도 수정을 단행했다가,
다 바꾸고 나서야 '님 그거 오히려 더 불편할 거 같은데요' 라는 피드백을 들으면 그것도 곤란해지니까.
만약 이 Turn Tracker Pointer에 대해서, 내가 미처 생각하지 못한 문제점이나
사용자 입장에서 불편할 거 같은 게 더 있을 거 같으면
댓글로 말해주면 고맙겠음!
그러면 작업이 좀 더 진전되고 나서 다시 뵐게얌.
중간에 짤로 있는 pointer 코드가 잘못돼서(이게 더 낫겠네 하고 건드렸다가 안 되게 만들었음) 수정했습니다.
그는.... 신이야!