워드프로세싱과 게임플레이

E3덕에 게임UI 관련 뉴스가 자주 들리고, 최근 uxfactory의 “웹디자이너가 게임 기획에서 배울만한 요소들” 이라는 글을 보고 예전 HCI2003에서 발표했던 내용이 생각나서 적습니다. 몇 년전에는 게임기획자분들과 함께 프로젝트를 진행하기도 하는등 게임 디자인에서 배울 수 있는 점을 찾으려고 시도했었는데요, 재미도 있었지만 어렵기도 했었던 기억이 남습니다. 어렵다고 말씀드린 이유는 제품과 게임, 두 가지 인터랙션의 근본적인 차이 때문이었죠.

Computer as Theatre에서 저자 Laurel은 인간-컴퓨터 활동을 생산적인 것과 경험적인 것으로 나눕니다. (Human-computer activity may be divided into two broad categories: productive and experiential.) 흔히 말하는 HCI에서의 UI는 생산적인 것이고 게임은 경험적인 것에 속합니다. 게임은 특정 과업을 수행하기 위한 과정이라기보다는 상호작용을 통한 경험 그 자체를 위한 것입니다. 경험적인 활동인 게임에서 Efficiency만을 최적화한다면 어떤 상황이 벌어질까요. 게임 패드로 캐릭터 이름을 직접 입력하게 하는 것은 비효율적이니까 캐릭터이름은 일괄 적용될 테고, 대전게임의 ‘→+LP,RP,RP,RP,RK,RP,LK,RK,RP,LP+RP’ 10단 콤보 입력명령은 비효율적이니까 단축명령키를 만들지도 모릅니다. 물론 실제로는 그래선 안 되고 그럴 리도 없지만요.

재미가 있고 없고가 어떤 차이를 가져다주는지의 명확한 예는 사용성 테스트입니다. 게임에서의 베타테스트는 게이머들의 자발적인 참여로 이루어집니다. 인기 게임의 경우 엄청난 경쟁을 통해 선발되며, 수천 명의 테스터가 헌신적으로 수십, 수백 시간을 미완성의 게임을 플레이하는데 투자합니다. 그래서 여러 가지 오류들을 잡아내고 문제점을 보완할 수 있게 되지요. 반면 사용성 테스트는 어떤가요. 상황에 따라 다르지만, 일반적으로 10명 안쪽의 사람들을 섭외해 길어야 한두 시간의 테스트를 위해 적지 않은 비용을 지급합니다. 수많은 게이머의 목소리를 어떻게 분석하고 요구 사항을 추출하여 이를 시스템에 적용할까요? 분명히 UX 프로세스에 적용할만한 부분이 있을것입니다.

워드프로세서에서 문서를 완성하는 경우와 롤플레잉 게임을 시작해 엔딩을 보는 경우를 비교해보면,

일반적으로 게임플레이를 할때는 한 개 이상의 세이브 파일을 생성하고 워드프로세서를 사용하는 경우는 계속 덮어쓰면서 하나의 파일을 생성합니다. 물론 게임에서도 계속 덮어쓰면서 하나의 파일을 만들 수도 있고 워드에서도 Save as로 버전관리를 할 수 있지만 기본적으로 대부분의 게임 UI 에서는 슬롯이라는 개념이 있어서 손쉽게 다른 세이브 파일을 생성할 수 있도록 지원하죠. 이런 비슷한 화면을 제품 UI에서도 본 적이 있습니다. 디지털 카메라의 설정화면이었는데요 사용자는 주어진 3 개의저장 공간에 현재 상태의 모든 설정 정보- 예를 들면 이미지의 크기나 해상도, 플래시모드, 화이트밸런스, 셔터스피드와 조리개 크기, 노출모드, 카메라 감도등 수십 가지에 달하는 설정 정보들을 저장해 두고 필요할 때 다시 불러올 수 있습니다. 이렇게 생성된 여러 개의 세이브파일은 원하는

시점의 상황으로 돌릴 수 있도록 해줍니다.  ‘자동저장’ 기능에도 차이가 있습니다. 워드는 일정 시간 간격으로 저장되는 반면 게임의 경우, 자동저장은 어떤 이벤트가 일어났을 때 예를 들어 중간보스를 크리어하거나 맵을 이동했을 경우에 이루어지는 것이 보통입니다. 한참 놀다가 잠깐 동안 불타올라 열심히 작성했는데 마침 그때 오류가 발생해 10분 전으로 돌아간다면 아무것도 남지 않게 됩니다. 워드에서의 자동저장 옵션도 몇 분 간격이 아니라 몇 자 간격이라면 어떨까 하는 생각을 해본 적이 있습니다.

만약 한참 작업한 문서를 저장하지 않고 워드프로세서를 종료하였을 때, 사용자의 명령대로 즉시 종료된다면 어떨까요. 직후에 시스템으로부터 “문서가 저장되지 않았습니다.”라는 메시지까지 받는다면 확실히 절망적이겠죠. 워드프로세서를 종료하는 사용자의 행동은 저장 여부를 묻는 대화 상자를 표시함으로써 제한됩니다. 사용자의 행동 가능 범위를 적절하게 제한함으로써 사용자의 다음 행동을 유도하는 방법 역시 게임에서는 자연스럽게 사용됩니다.

원숭의 섬의 비밀(1990)

예를 들어 주인공이 마을 장로와 대화를 하지 않았다면 문지기가 막아서서 밖으로 내보내지 않는 다던지 특정 아이템을 취하지 못했다면 봉인된 문을 열수 없는 경우 등이 이에 해당합니다. 마을 밖으로 나가서 한참을 진행하고 나서야 ‘아 그때 장로와 대화를 했었어야 하는데… ” 라는 사실을 안다면 게이머가 얼마나 당혹스러울지 게임 디자이너는 알고 있기 때문입니다. 아직도 생생하게 기억나는 루카스아츠사의 1990 년작 ‘원숭의 섬의 비밀 (Secret of Monkey Island’)은 ‘제한’의 효과를 잘 활용한 사례로 들 수 있습니다. 다른 게임과는 달리 이 게임의 주인공 가이브러시는 낭떠러지에서 떨어져도 다시 퉁겨져 올라오며 식인종에게 잡혀서 갇히더라도 탈출하는 방법이 제공되는 등 결코 죽는 일이 없었는데, 그래서 불필요한 걱정 없이 주어진 문제를 해결하는데 몰입할 수 있었습니다. 

어떤면에서는 적절한 Metaphor와도 관련이 있습니다. 주인공이 낭떠러지에서 떨어지면 사망하는 것이 실제의 상황이라면, 다시 퉁겨져 올라오는 것은 게임디자이너가 실제와 다른 매핑을 하는 경우입니다. 실제 공책과 똑같이 워드프로세서를 구현하려고 한번 지워진 글은 영원히 되살리지 못하게 만들어서는 안 되는 것과 같이 UI 디자이너들은 실제와는 다른 매핑을 적용하기 위한 논리적인 상황을 늘 고려해야 합니다. 워드프로세서의 잘못된 메타포로인해 얼마나 많은 사람이 작업물을 잃어버려서 좌절을 맛보았을까요. 워드프로세서를 사용하면서 사용자가 떠올리는 메타포는 펜으로 글을 쓰는 노트이기 때문에 이미 적은 글들이 저장하지 않았다면 메모리에서 사라질 수 있다고 인식하지 못합니다. 알고 있다고 하더라도 망각하게 되죠. 이런 사용자모델과 시스템모델이 차이가 나면, 시스템을 사용자모델에 맞추어주거나 다른 사용자모델을 제공해 줘야 합니다. 사용자모델을 바꾸기위해 저장되지 않은 영역과 저장된 영역을 구분해서 표시해주면 어떨까요. 마지막 저장 이후 작성된 부분은 흐린 잉크로 곧 지워질것 같은 느낌으로요. 반면 스프링노트처럼 실시간으로 계속 저장되는 것은 시스템모델을 사용자모델과 같게 해준 예가 될 수 있습니다.

마이트앤 매직(1987)

 그 밖에 사용설명서의 도움 없이 조작을 익히고 몰입할 수 있게 해주는 직관적인 UI, 고급사용자와 일반사용자의 격차를 절충하는 방법 등 게임 UI에서 배울만한 것들은 넘쳐납니다. 그리고 게임UI에서는 일반적인 응용프로그램들보다 훨씬 자유롭고 창의적인 인터페이스를 발견할 수 있습니다. HCI 분야에서의 UI와는 달리 게임 UI에서는 일정한 표준이 거의 존재하지 않습니다. 아직 텍스트기반의 인터페이스가 대부분이었을 시기에도 게임에서는 3D를 지향하고 있었고 현재에도 AR, Gesture등 새로운 인터페이스의 시도가 계속 되는 부분이 바로 게임입니다.

무엇을 재미있게 만드는 것은 무엇을 효율적으로 만드는 것보다 훨씬 어렵습니다. 만약 궁극의 UI라는것이 있다면 가장먼저 게임분야에서 나오지 않을까요.