태그 글 보관함: 테스트

개밥 먹기(Eating your own dog food)

개밥 먹기는 IT 개발에서 사용되는 속어이다. 보통의 경우, 자신이 개발한 제품(소프트웨어)의 품질을 테스트하는 행동을 가리킨다. 위키피디어에 의하면 미국의 개 사료 브랜드인 알포의 1980년대 TV 광고에서 배우 론 그린(Lorne Greene)이 자신의 개에게 사료를 먹이는 장면에서 시작되었다고도 하며, 또 다른 이야기로는 칼 칸 펫 푸드(Kal Kan Pet Food)의 사장이 주주회의 때 ‘나는 우리의 개밥을 먹는다’라고 밝힌 것에서 유래했다고도 한다(링크). 개밥 먹기라는 단어가 주는 불쾌감 때문에, 이를 순화시키자는 의견이 있는 듯 하지만, 개인적으로는 IT 프로젝트의 어두운 단면을 희화화한 적절한 단어가 아닌가 생각한다.

개밥 먹기와 일반적인 테스트는 그 성격을 조금 달리한다. 테스트는 기본적인 오류의 탐색, 개발 제품의 가장 기본적인 기능의 작동 여부 등을 확인한다고 하면, 개밥 먹기는 제품 자체의 사용성과, 효용 등의 관점에서 접근을 한다고 보면 된다. 게임 개발에서는 ‘게임의 재미’를 확인하기 위해서 개밥 먹기를 수행하게 된다.

대부분의 프로그래머, 그래픽 디자이너, 게임 디자이너는 제작 중 ‘테스트’를 충실하게 수행한다. 자신이 작업한 작업물이 정상적으로 돌아가는지는 확인 하는 것은 업무의 기본이다. 하지만, 대부분의 경우 ‘테스트’를 하더라도 ‘개밥 먹기’를 수행하지 않는 경우가 많다.

전체 팀원들은 주기적으로 개밥 먹기를 하면서 ‘자신이 작업한 파츠’가 ‘전체 게임의 재미’에 어떤 식으로 영향을 미치는지에 대한 관찰을 해야한다. 종종 자기가 맡은 작업에 집중하거나 혹은 주어진 일에만 몰두한 나머지 전체 결과물과의 조화를 해치는 경우가 자주 발생을 하곤 하는데, 이는 결국 개밥 먹기를 제대로 수행하지 않았기 때문이다.

개밥 먹기는 제품 제작 과정에서 꽤 중요한 위치를 차지하지만, 몇 몇 팀원들의 경우에는 개밥 먹기에 대한 거부감을 나타낼 수 있다. 가장 많은 저항은 (정말 개밥 처럼 만든 나머지) 먹기 불편함을 호소하는 경우이다. 사실 개밥 먹기에서 발견되는 ‘먹기 불편함’은 가장 먼저 개선되어야 할 사항 중 하나이며, 그러한 ‘먹기 불편함’을 팀원들이 공유를 하고, 먹기 좋은 사람의 음식으로 만들 방법을 찾아내야 한다. 이를 위해서 프로젝트 관리자는 개밥 먹기를 적극적으로 이끌고 운영해야 한다. 억지로라도 맛을 보여주고, 문제 상황을 인식시켜야 한다.

게임이 ‘먹기 불편한’ 가장 큰 이유는 무엇일까?-‘게임이 재미가 없기 때문’이다. 소속 팀원들이 디아블로 3에는 열광하지만 자신이 만드는 게임의 최신 빌드(Build)에는 무관심하다면, 그것은 그 프로젝트에 심각한 위기가 닥쳐왔다는 것을 의미한다. 개밥을 먹기 바란다. 그것도 자주.

프로그래머를 위한 프로토타입 용 그래픽 리소스 얻기

(주: 글의 내용은 개인적인 의견임을 알아 둡시다)

프로토타이핑

프로토타이핑은 게임의 재미를 검증하고, 나아가서는 구현된 결과물을 수정하여 아이디어를 확장하게 해준다. 좋은 프로토타입을 만드는 데 가장 중요한 부분은 플레이 가능한 게임을 빠르게 구현하는 것이다. 프로토타입을 통하여 게임 디자인 기획서의 목적과 한계를 확인한 후 본 게임을 깔끔하게 다시 만드는 것이 보통이다.

게임의 최종 목적이 귀여운 캐릭터와 아기자기한 그래픽을 통한 승부가 아니라면, 선과 원 그리고 사각형만 가지고도 게임이 재미있어야 한다. 기본 시스템과 동작이 재미있고 여기에그래픽이 추가 된다면 금상첨화가 될 테니까. 하지만 세상은 그리 호락호락 하지 않다. 그래픽이 붙지 않은 상태의 자연 상태의 게임은 목적과는 전혀 다른 게임이 되어버린다. 텍스트만을 이용해서는 복잡한 게임은 만들 수 도 없을 뿐만 아니라, 만들었다고 해도 마치 선사시대 게이머들이나 좋아 할 만 한 넷 핵류 게임처럼 보이게 된다. 이 복잡해 보이는 물건을 ‘절대로 아무도 읽지 않을 설명서’를 줄창 써서 프로토타입 테스터들에게 보내면 이런 메일을 받게 된다.

  • “어떻게 하는지 모르겠어요.”
  • “내가 해야 할 일이 무엇인가요?”
  • “동그란 원과 사각형 혹은 저기 보이는 파란 사각형 중 어느게 저인가요?”
  • “왜 제가 빨간 사각형을 피해야 합니까?”

내가 틀렸다. 지난 8개월 간의 경험과 무지막지한 피드백들을 통해 프로토타입에는 최소한의 그래픽이 필요하다는 결과를 도출 할 수 밖에 없었다.

요즘 이런거 테스터들도 잘 안한...

 

적절한 그래픽 리소스

그럼 프로토타입에는 어느 정도의 그래픽 리소스가 필요할까? 개인적으로는 나름 이하와 같은 가이드 라인을 만들었다.

원칙 1) 에니메이션은 작업에 포함시키지 않는다

프로토타입에 쓰이는 리소스는 실제 버전에서는 무조건 버리게 된다. 애니메이션 같이 품이 많이 들고 낭비인 지점에 신경쓰지 말자. 물론 별도의 동작(공격 등)을 해야한다면 공격 시에 사용할 그림 한장 정도면 된다.

원칙 2) 타입이나 종류 등은 구분이 되어야 한다.

리소스를 아낀다고 다른 종류의 유닛을 하나의 이미지로 처리하지 않는다. 최소한 색이라도 바꿔서 쓰도록 하자. 게임 디자인 상 들어가야 할 필수 요소들은 빼 먹지 않고 그래픽 리소스를 채워 넣는다. 여기서도 꾸미기 요소(이펙트, 배경 등)는 제외한다.

너구리 게임을 예로 들자면 먹어야 할 아이템, 장애물, 사다리 등 게임의 요소로서 영향을 끼치는 것에 대한 구분 용도로 꼭 그래픽 리소스를 넣어야 한다.

그래픽 리소스 +1을 획득하였습니다

그럼 그래픽 리소스는 어떻게 얻어낼까? 본인 스스로 아트 디자인이나 그래픽 리소스 제작 스킬이 있다면 직접 그려도 된다(하지만 나는 당신이 아트 디자인에 관련한 소양이 없기 때문에 프로그래머 혹은 기획자가 되었다는 걸 알고 있다). 또는 주변의 그래픽 디자이너에게 밥을 한끼 사주고 시키거나, 무력으로 그림 잘 그리는 동생을 진압하여 노예처럼 쓰는 방법도 있다(실제 90년대의 국내 아마추어 게임계에서 많이 쓰였던 착취 방식이기도 하다). 하지만 프로토타이핑을 하며 필요한 사소한 리소스 들이 계속 추가 될때 마다, 시도때도 없이 남에게 구두로 리소스를 요청하기는 쉽지않다.

대다수의 훌륭한 어른들은 아무것도 하지 않고 이루려고 한다(혹은 아주 약간의 노력으로 무언가를 이루려고 하기도…). 여기서는 그러한 방법들을 아래서 소개하고자 한다.

우선 프로그래머의 친구 Google에서 Game Sprite로 검색 할 경우 다음의 결과가 나온다.

짜잔!

위와 같이 많은 리소스 들이 존재한다. 이것을 가져다 쓰도록 하자. 검색 결과 상위에 랭크되어 있는 다음의 사이트들에서도 많은 구작 게임들의 스프라이트를 얻을 수 있다.

과거(네오지오Neogeo를 기점으로 이전) 콘솔 게임기들은 하드웨어의 제약으로 인해 비디오 램과 그것을 찍는 방식이 지정되어 있었다. 현재와 같은 일반적인 3D가속 방식을 사용하지 않기 때문에 특정 비디오 램에 이미지를 넣고, 해당 이미지를 특정 레이어로 지정을 하면 찍어주는 그런 블라블라한 방식인 것으로 알고 있는데… 더 이상 자세한 설명은 생략한다(필요 할 경우 직접 검색을 해 보시라). 중요한 것은 레이어 방식 인데, 해당 레이어를 통해서 우선순위가 지정되기 때문에, 비슷한 유형의 특정 스프라이트들은 같은 레이어에 몰아서 넣게 된다(2D 대전 액션의 경우 배경→ 배경 사람 → 뒷 이펙트 → 케릭터 → 앞 이펙트 식). 요즘의 게임 에뮬레이터들은 특정 레이어를 켜거나 끌 수 있는 기능을 제공하고 있는데, 해당 기능을 사용하여 특정 이미지만 깔끔하게 볼 수 있다.

이러한 에뮬레이터의 상태 기능이나 연속 스크린샷 기능, 메크로 기능 등을 적절히 이용하면 원하는 동작이 나오도록 할 수 있을 것이고 그 결과물을 사용하자(물론 바퀴를 다시 발명하는 과오를 범하지 않기 위해 위의 사이트들 에서 누군가 미리 작업해 놓은 것이 있는지 확인하는 것은 필수).

또한 각종 게임 관련 사이트에서 아이템 류의 아이콘 이미지 등을 추출 할 수 있다. 게임 관련 사이트 들에서 공략 등을 이유로 스킬 아이콘이나 아이템 아이콘 등을 표기해 주는 경우가 많은데 이 데이터들을 차용하는 것도 한 방법이다. 브라우저에서 표기되는 모든 이미지 데이터는 하드에 임시로 저장된다. 임시 폴더를 직접 확인하거나 구글 크롬 이용자의 경우 개발자 도구를 사용하면 쉽게 이미지를 얻어올 수 있다.

아무리 찾아도 내 게임은 워낙 독특해서 적절한 이미지를 찾기 어렵다면 직접 그리는 방법이있다. 가마수트라에 게시되어 있는 개발자를 위한 2D 게임 아트란 글을 참조 한다.

마지막으로 주의사항 한 가지. 직접 제작한 것이 아닌 ‘따온’ 데이터는 정식 게임에 포함되지않도록 해야 한다. 여기 나온 팁들은 어디까지나 내부 용도의 테스트에만 사용되어야 하며, 용도를 벗어나게 될 경우 저작권 송사에 휘말릴 수 있다. 개인적으로, 몇 년 전 서비스했던 온라인 게임의 최초 개발 시 테스트용으로 집어넣은 상용 게임의 사운드 파일이 있었는데, 게임의 분위기와 잘 어울린다 생각하고 신경을 못쓰고 있다가 그대로 클로즈 베타 릴리즈를 한 적 이 있었다(물론 파악한 뒤에 바로 삭제하였다). 한 가지 팁을 주자면, 개발용 리소스를 디렉토리를 별도로 두고(root/dev/ 식으로) 실제 사용될 그래픽 리소스가 올라올 때는 실제 사용될 디렉토리에 넣는 식으로 하나씩 옮기면 실수를 하지 않을 것이다.