시작 글

일이라는 게 일단 집중하기 시작하면 ‘어휴 어떻게 시작하나’ 하는 마음을 지울 수 있다. 눈 앞에 있는 걸 치우기 급급하기 때문에 그런 생각을 할 여유도 없어진다. 그러니까 일단 엉덩이를 무겁게 하고 IDE를 켜고 그 다음을 생각하자, 라는 게 나의 지론이다. 하지만 의례히 지론이라는 게 그렇듯이 내 지론도 만병통치약은 아니다. 일종의 가이드라인이라고 해야 할까. 이 라인을 따라 가면 어떻게든 무난하게 출구로는 나갈 수 있습니다. 하는 표시. 고속도로에서 국도로 빠질 때 표시해주는 빨간색 초록색 줄선같은 거라고나 할까. 아무튼 적당히 잘 맞아떨어지긴 한다. 하지만 그 줄을 따라서 국도로 나가는데 성공하고 나면? 그러니까 가이드라인이 제시하는 어떤 선을 지나치고 나면 다음 목적지는 어떻게 정하지? 가이드라인은 어디로 사라진걸까, 어리둥절해서는 깜빡이를 켜고 갓길에 차를 세워버리려나?

실제 운전자라면 네비게이션을 따라서 그냥 움직이기만 하면 되는 ‘간단한 일’일 것이다. 예컨데 이중 삼중의 대비책이 구비되어 있는 셈이다. 하지만 나는 목적지도 제대로 모르는 운전자이기 때문에 걸핏하면 갓길에 차를 세우곤 한다. 가이드라인의 끝에 다다르면 거의 대부분은 그런 상황이 벌어진다.

이번에도 예외는 없었다. 집중하고 있던 짧은 가이드라인의 끄트머리에 서서는 우왕좌왕, 어찌해야 할 바를 모른다. 지도를 보면서 고민한다. 자, 이제 어쩐다.

잘 모르겠네. 기록이나 해볼까.

뭐, 그런 심정이다.

작업

screenshot

이번에 한 작업은 히스토리 기능이다.

일단 스토리를 주축으로 생각하면서 만든 게임이다보니, 텍스트에 대해 여러가지로 생각하게 된다. 내가 스토리 게임을 하면서 가장 불편했던 점은 내가 어디까지 진행했는지를 자꾸 까먹는다는 점이다. 세이브를 해두고 한참 후에야 다시 켰을때, 어라, 내가 뭐하다가 여기서 멈춰 있었더라. 고민하게 된다. 소설책이라면 이전 내용을 빠르게 다시 훑어보고 이어서 읽을 수 있을텐데. 그렇다고 처음부터 플레이하기를 강제한다면 그건 게임이 아니라 고역이 된다. 그렇다면 소설처럼 빠르게 훑어볼 수 있는 기능이 있으면 되지 않을까. 그런 기능이 뭐가 있지? 하는 생각의 흐름. 답은 비주얼 노벨에서 찾을 수 있었는데, 뭐 예상하다시피 히스토리 기능이다. 간단하게 소설책과 비슷한 사용자 경험을 제공할 수 있다.

사실 히스토리 기능은 개발을 시작하기 전에 꽤 고민한 기능이다. 이 게임의 플레이타임을 전혀 고려하지 않았기 때문이다. 쉽고 짧게 플레이할 수 있는 게임에서 히스토리 기능은 그야말로 계륵같은 기능이지 않을까? 하는 고민을 전면으로 내세우고는 있지만, 사실은 역시 귀찮기 때문이다. 새로운 기능을 또 어떻게 끼워넣는담. 새로운 기능 개발 전의 나는 항상 이런 고민과 함께 바로 앞에 커다란 성벽이라도 있는 듯이 군다. 그러다가 ‘에잇 해버리자’ 하고는 해버리는데, 해보면 성벽 정도는 아니고 그냥 아파트 울타리 정도의 높이라는 걸 알게 된다. 뭐, 돌이켜보면 인생이라는 게 보통 그런 거였다.

나는 꽤 꼼꼼하게 따져가며 구현하는 걸 잘 못하기 때문에 이번에도 일단 부딪혀봤다. 대충 이런 흐름이다.

  1. 지금까지 달성한 이벤트 이름을 저장해두고 이벤트의 스크립트 내부에 있는 나레이션과 대사를 전부 보여주면 되지 않을까?
  2. 개발 중…
  3. 달성한 이벤트 중에서도 일부만 달성했을수도 있고, 늘 발동하는 스크립트도 있을 수 있네. 어쩐다.
  4. 히스토리 내역을 확인할 때 달성한 이벤트 내부에 있는 조건을 실시간으로 확인하면 되지 않을까?
  5. 개발 중…
  6. 한번만 성공으로 처리하고 다시 처리하지 않는 이벤트는 이벤트 달성 후 히스토리 내부에서 체크 시 true가 될 수가 없다.
  7. 스크립트 내부를 조건으로 부분 스크립트로 나눠서 인덱스 처리하고, 인덱스도 이벤트 이름과 함께 저장하자.
  8. 개발 중…
  9. 완성

뭐 복잡하게 적어놨는데, 결국 스크립트 이름과, 그 스크립트에서 출력할 부분의 인덱스들을 함께 저장하는 방식으로 구현 처리했다. 주먹구구식으로 개발해나가지 않았으면 처음부터 이 방법으로 갔을지도 모르겠다.

개발이라는 게 사실 처음에 만든 프레임이 있으면 어떻게든 그 프레임을 깨지 않고 수정을 가하려고 하게 마련이다. 3~6번까지의 과정이라는 게 사실 그 과정이었다. 모험심을 가지고 완전히 뒤엎어보자!는 식이 코딩에는 꽤 위험한 방식이기 때문인데, 뒤엎으면서 생길 사이드이펙트 때문에 되려 시간을 더 잡아먹을수도 있기 때문이다. 어떻게 보면 개발이란 유지보수의 확장형에 불과할지도 모르겠다.

바로 이런 문제 때문에 TDD를 해야 하는 것인데, 휴. 해야 하는 것인데, 라고 생각만 하네, 늘.


맺음 글

깜빡이가 깜빡거리는 와중에 글을 쓰고 있으니까 괜히 마음이 불안하다. 뒤에서 차가 경적이라도 울리면 화들짝 놀라게 된다. 여기 계속 서있어도 되는 걸까, 걱정한다. 얼른 수첩을 접고 지도를 펼친다. 목적지가 어디였더라, 그럼 다음으로 경유해야 할 곳은, 하며 머리가 복잡해진다.

어휴, 언제 도착할 수 있는거야, 목적지는.