a6561caa0103b47f96ff5a51d65cc7c03d56ace4f1f268acfa268ef002ff1947e5071cbe


a6561caa0103b47f96ff5a51d65cc7c03d57ace4f1f268acfa268ef002ff19474b497df6


a6561caa0103b47f96ff5a51d65cc7c03d54ace4f1f268acfa268ef002ff19449b096233



이것만 봐서는 실제로 어떻게 돌아가는지 상상하기 꽤 귀찮을 거 같으므로

실제로 돌아가는 과정을 좀 설명하자면


일단 건독의 관통 판정/대미지 굴림에서 중요한 건 세 가지임.

1. 명중 개수 2. 그 중 최대 달성치 3. 크리(달성치가 20) 개수.

이건 그걸 입력값으로 받기 위한 쿼리를 설계한 건데.




가장 간단한 첫 번째 안은

최대 3개까지 있을 수 있는 달성치를 전부 드롭박스 형태로 입력하는 방식임.

단, 2사 달성치가 없을 경우는 3사는 디폴트값으로 없음으로 튀어나오므로

2사 달성치를 없음으로 해 두면, 엔터 한 번으로 3사 체크를 넘길 수 있는 셈.



이 중에서 최대치는 내가 [[{?{1사 달성치}, ?{2사 달성치}, ?{3사 달성치}}kh1]] 형태로 그때그때 구해야 하지만

대신 인터페이스를 쓰는 PL의 입장에서는 입력값의 '순서'를 헷갈려도 별 문제가 없다는 게 가장 큰 메리트.


단점으로는, 2사와 3사 달성치 입력 시에 총 21칸의 드롭박스를 뒤져서

자신의 달성치를 찾아 넣어야 한다는 사실 그 자체.

애초에 드롭박스 자체가 입력값을 한정해서 오작동을 예방하는 것 이상으로

'마우스에서 손 떼서 키보드로 손을 옮기는 귀찮음을 줄이는' 게 목적인데

솔직히 휠 굴려가면서 달성치를 클릭하는 것도 만만찮게 귀찮을 공산이 크다.




그래서 두 번째 형태도 만들어봤는데

이거는 PL이 달성치 1~3개 중 가장 큰 값은 자신이 직접 구해서 넣어야 하지만,

그 다음부터는 1~19의 달성치를 하나의 선택지 안에 몰아넣어서

드롭박스를 뒤지는 수고를 줄여준 모델.


덤으로 내가 최대치를 직접 구하지 않아도 된다는 소소한 장점도 있다.

물론 그 대가는 PL이 최대치를 눈으로 보고 찾아야 한다는 점.




그리고 가장 복잡한 세 번째 형태는, 모든 달성치가 정렬되어 있다는 가정 하에

최대 달성치가 크리티컬이 아닌데, 2번째, 3번째 달성치에서 크리가 뜨는 건 입력 오류고

2번째 달성치가 크리티컬이 아닌데, 3번째 달성치가 크리가 뜨면 역시 오류잖아.

이런 실수를 원천예방하기 위해서

앞의 입력값이 크리티컬이 아니면 다음 드롭박스에서 크리티컬을 배제하도록 만든 모델.


근데 생각해보니 현실적인 휴먼 에러는 '3사가 크리티컬이 아닌데 크리티컬을 눌러버리는' 경우보다

'2사는 크리티컬이 아니지만 3사가 크리티컬인 상황에서, 아무 생각 없이 2사가 크리가 아니라고 눌렀다가

3사에서 크리티컬 항목이 사라져서 벙찌는 상황'일 거 같단 말임...

솔직히 이건 내가 좀 뇌절을 친 거 아닌가 싶다.




그래서 솔직히 셋 중 어느 쪽으로 가야 할지 잘 몰?루



님들은 셋 중 뭐가 가장 편하고 실수가 적을 거 같음???