소리꽃 KeyBloom TIL 27
파티클 컨트롤 통일·공연 출력 창 버그·0.1.5 출시에서 나온 것들. 앞선 TIL 26에서 이어진다.
컨트롤 설계
슬라이더를 여러 개 주려면 서로 침범하지 않아야 한다
속도를 올렸더니 파티클이 퍼지는 크기까지 같이 커졌다. 사용자 입장에서는 “속도”를 만졌는데 모양이 바뀐 것이라, 원하는 그림을 맞추려면 두 슬라이더를 번갈아 왔다 갔다 해야 한다. 슬라이더가 늘어날수록 이 왕복이 곱으로 늘어 결국 아무도 안 만지게 된다.
원인은 물리 쪽에 있었다. 항력(속도에 비례해 감속시키는 저항)을 받으며 날아가는 것의 도달 거리는 초기 속도를 항력으로 나눈 값이라, 속도만 올리면 거리도 같이 늘어난다. 둘이 자연히 얽혀 있는 것이다. 얽힌 걸 그대로 두면 컨트롤이 얽힌다.
떼는 방법은 속도와 항력을 같은 비율로 함께 올리는 것이다. 나눈 값은 그대로라 도달 거리는 안 변하고, 대신 같은 거리를 더 빨리 가고 더 빨리 사라진다. 그러면 “속도”는 시간만, “폭·높이”는 크기만 담당한다.
여기서 가져갈 건 물리식이 아니라 순서다. 컨트롤을 설계할 때 먼저 각 슬라이더가 책임질 축을 말로 정하고(“이건 시간, 이건 크기”), 구현이 그 축을 침범하면 구현을 고친다. 반대로 하면 슬라이더 이름이 실제 동작을 못 따라간다.
한 축만 제한하면 형태가 무너진다
분수는 세게 쏘면 화면 밖으로 솟는다. 포물선의 최고점(apex)을 화면 안으로 눌러 담으려고 위로 가는 속도만 깎았더니, 옆으로 가는 속도는 그대로라 세게 칠수록 분수가 눕는 모양이 됐다.
제한은 값 하나를 자르는 게 아니라 형태를 유지한 채 걸어야 한다. 세로를 절반으로 깎았으면 가로도 절반으로 깎아야 발사각이 유지된다. 화면 밖으로 나가는 걸 막는 모든 곳에 같은 함정이 있다 — 크기를 줄일 때 비율을 안 지키면 잘리는 대신 찌그러진다.
가둔다고 했으면 안의 움직임까지 걷어야 한다
“폭을 최소로 하면 눌린 건반 너비 안에만 나오게” 하기로 했다. 시작 위치를 건반 폭으로 좁혔는데도 파티클이 밖으로 새어 나왔다. 좌우로 흔들리는 움직임이 폭 설정과 무관하게 살아 있었기 때문이다.
컨트롤이 사용자에게 한 약속은 “이 안에서만 논다”인데, 안에서 도는 움직임 중 하나라도 그 약속을 안 받으면 약속이 절반만 지켜진다. 사용자는 절반 지켜지는 컨트롤을 고장으로 본다. 그래서 흔들림 폭도 같은 값에 묶어, 폭이 0이면 흔들림도 0이 되게 했다.
경계를 거는 컨트롤을 만들 땐 “그 경계를 넘을 수 있는 요소가 또 뭐가 있나”를 한 번 훑는 게 맞다.
무엇을 보여줄지 정하기
자동으로 알 수 없는 건 한 곳에 적고 나머지는 읽기만 한다
모션마다 쓰는 컨트롤이 다르다. 나선은 회전 반경을 쓰고, 불꽃은 폭을 안 쓴다. 안 쓰는 슬라이더가 화면에 떠 있으면 만져도 아무 일이 안 일어나서 사용자가 앱을 의심한다.
“안 쓰는 건 알아서 안 보이게 못 하나”를 따져 봤는데, 완전 자동은 안 된다. 어떤 모션이 무엇을 쓰는지는 코드가 스스로 알 수 없는 도메인 지식 — 그 분야를 아는 사람만 판단할 수 있는 것 — 이라 사람이 적어야 한다. 그러면 남는 선택은 “몇 군데에 적을 것인가”뿐이다.
전에는 모션마다 화면 코드에서 하나씩 감췄다 보였다 했다. 적는 곳이 여럿이라 새 모션을 넣을 때마다 빠뜨렸다. 그래서 모션 정의 자체에 “이 모션이 쓰는 컨트롤” 목록을 달고, 화면은 그 목록만 읽게 했다. 이제 새 모션이 생기면 그 한 줄만 적으면 되고 틀릴 자리가 하나로 준다.
자동화가 안 되는 지식을 만났을 때 목표는 자동화가 아니라 “틀릴 수 있는 자리를 하나로 모으기”다.
창과 기다림
보냈다가 아니라 받았다를 기준으로 삼는다
공연 출력용 두 번째 창은 본 화면과 그림을 공유하지 않고, 필요한 정보만 받아 따로 그린다. 창을 띄우자마자 배경 이미지를 보냈더니 아무것도 안 나왔다. 창이 아직 받을 준비를 안 한 상태라 보낸 것이 그냥 없어진 것이다.
고쳐 놓은 방식은, 받는 쪽이 준비를 마치고 “이제 됐다”고 알리면 그때 보내는 것이다. 이렇게 양쪽이 신호를 주고받아 시작을 맞추는 걸 핸드셰이크라고 한다. 새 창·새 화면에 현재 상태를 넘기는 자리마다 같은 함정이 있다. 띄우는 쪽 타이밍을 재서 맞추려 들면 기기가 느릴 때 다시 깨진다.
기다리는 구간을 빈 화면으로 두지 않는다
앞선 TIL 25에서 업데이트 진행률을 띄웠는데, 설치를 누르고 다운로드가 실제로 시작될 때까지 잠깐은 여전히 아무 신호가 없었다. 그동안 화면이 그대로면 눌린 건지 멈춘 건지 알 수 없어서 사용자가 다시 누르거나 앱을 끈다.
그래서 누른 즉시 “준비 중”을 띄우고, 진행률을 알 수 있게 되면 진행바로 바꾼다. 진행률을 모르는 구간이 있다는 게 문제가 아니라, 그 구간에 아무것도 없다는 게 문제다. 누르면 즉시 무언가 변해야 한다.
요약
- 슬라이더가 여러 개면 각자 책임질 축을 먼저 정하고, 구현이 그 축을 침범하면 구현을 고친다
- 한 축만 제한하면 형태가 찌그러진다 — 제한은 비율로 건다
- 가둔다는 약속은 안에서 도는 움직임까지 다 걷어야 지켜진다
- 자동으로 알 수 없는 지식은 자동화 대신 “틀릴 자리를 하나로” 모은다
- 상태 전달은 보낸 시점이 아니라 받을 준비가 끝난 시점을 기준으로
- 기다리는 구간을 빈 화면으로 두면 사용자는 고장으로 읽는다