태그 보관물: 프로그래머

집중을 하자!!

사람의 집중력은 아이폰과 같습니다. 높은 곳에서 떨어뜨려도 멀쩡할 때도 있지만, 어떤 경우에는 사소한 충격에도 크랙이 날 때가 있지요. 그런 사고에서 아이폰을 보호하기 위해 우리는 범퍼를 씁니다. 아래에는 제가 사용하는 집중력을 유지하기 위한 범퍼 같은 팁들을 모아 봤습니다.

창을 항상 같은 위치에 고정시킨다

미니맵은 보통 어디에 있나요?  HP와 MP를 표기 할 때는? 누구나 떠오르는 자리가 있을 겁니다. 그것은 그곳에 고정되어 있기 때문이죠. 작업 할 때도 마찬가지 입니다. 스크립트를 위한 Notepad++은 화면 우측에 길게, 게임클라이언트는 좌측에. 그 게임 클라이언트의 콘솔창은 게임 클라이언트 아래. 식으로 항상 같은 위치에 존재한다면 자신도 모르는 사이에 시선이 그곳으로 움직이게 될껍니다. 그런 작업을 원활하게 하기 위해 저는 sizer 같은 프로그램을 사용합니다.

이런 프로그램은 윈도우를 애매하게 켜두는 것이 아닌 창끼리 1픽셀 단위로 딱딱 맞춰야하는 편집증인 사람들에게도 좋습니다. 저의 경우는 와이드 모니터 2대를 세로로 세워놓고 모니터를 반반 나누어 쓰는 것을 즐깁니다. 총 4개의 구역을 만들고 텍스트를 편집 할 일이 있는 경우는 한쪽 모니터를 가득 채워쓰는 식입니다.
이제 더 이상 필요한 창을 찾기위해 해매는 유목민이 되지 맙시다

작업용 컴퓨터는 작업 전용이다

예전 다니던 회사에서 아이폰용 게임을 개발 할 때 아이맥(iMac)을 사용 했습니다. 프로젝트에는 2명의 프로그래머가 있었고, 게임의 코드는 윈도우, 게임에 들어가기 전까지의 UI들은 코코아 프레임웍(Cocoa Frameworks)을 사용 하였기 때문에 윈도우와 맥 2대를 번갈아 가며 사용해야 했습니다.

저는 타이핑의 즐거움에 눈을 뜬 기계식 키보드의 노예였기 때문에 아이맥의 멤브레인 키보드를 사용할 수 없었고, 그래서 키보드 공유기를 사용하여 하나의 키보드로 작업했습니다. Xcode와 VC를 오갈때마다 단축키와. 알트키의 위치. 게다가 p/s2 전용 키보드 공유기 이기 때문에 눌러지지 않는 조합 등…… 작업을 하며 두 개의 OS를 오가다 보니. 내가 다리가 불구인 전직 해병대인지 나비(Na’vi) 족인지 구분이 안가는 지경이였습니다. 같이 작업하는 옆자리의 동료와 이야길 해보았는데, 그는 아이맥의 기본 키보드를 사용하였고, 키보드 자체가 다르니까 작업할 때 크게 햇갈리지 않는다고 합니다. 요즘은 저도 맥북에어를 쓸 때 OS에 관계없이 저도 모르게 Command + 스페이스를 쓰게 되더군요. 전용 기기는 이렇게 중요합니다.

약간의 비용을 감수하더라도 작업용 컴퓨터는 작업만 되게 하는 것이 중요합니다. 그래야 앉으면 자신도 모르게 습관적으로 작업을 하게 됩니다. 회사에선 일을 잘하는 프로그래머가 집에선 집중을 못하고 코드 한 줄도 못짜는 경우가 부지기수입니다. 일본에서는 전용기의 중요성을 나타낸 만화도 있습니다.

전용 컴퓨터를 사용하면 3배쯤 개발이 빨리됩니다

모든 일은 자동화 한다

일을 하기 위해 의자에 앉습니다. 아 커피가 없네요. 커피를 한잔 타오고, 아직 집중이 안되니 커피를 한모금 마시며, 이메일을 체크합니다. 한 모금 더 마시고, 이슈 트레커를 보기위해 웹브라우져를 켜니, 웹브라우저 홈으로 걸려있는 네이버에 클릭을 안할 수 없는 뉴스가 있네요. “산골 학교 교장 선생님 갑자기 벗으며…”  클릭해보니 산골 학교 교장 선생님이 교내 동아리 축재 무대에 올라가 늦은 나이에 만든 몸을 보여주며, 너희들도 뭐든 하면 된다. 라고 하는 감동적인 뉴스네요. 또, 한 모금 마시고, 역시 뉴스 하다보니 게임 뉴스도 좀 봐줘야할 것 같아 디스이즈게임 같은 곳을 갔다가 또 한 모금 마시고. 아… 그러고보니 소변이 마렵습니다. 화장실에 다녀온 후, 일단 작업용 소프트웨어를 켜면서, 다시 이슈 트레커를 보기 위해 웹 브라우저를 켜고, 또 네이버 뉴스를 클릭합니다. 이러다 보면 점심먹을 시간입니다. 물론 이 모든 이야기는 제 이야기가 아닙니다(크흠).

집중력은 사소한 곳에서 흐트러 집니다. 그리고 그 횟수가 많으면 많을 수록 딴짓 할 확률이 높지요. 웹 브라우저의 홈(Home)은 작업용 이슈 트레커로 고정해 놓습니다. 오전 시간에 몇 개의 이슈를 처리할지 미리 결정하고, 시간 당 커피의 양도 조절해야 합니다. 그래야 화장실을 많이 안가거든요.

실제 작업 때 사용하는 프로그램들도 마찬가진데, 조금이라도 수작업으로 하는 작업을 줄이도록 애써야 합니다. 이하는 파이드 파이퍼스에서 작업을 하며 고안한 도구들 입니다.

스크립트 수정 및 확인을 편하게

우리는 스크립트를 파이썬(Python)과 json형식으로 데이터 테이블을 사용합니다. 그리고 편집기는 Notepad++을 사용하지요. 스크립트를 편집해서 확인 할 때마다 클라이언트를 Alt+F4로 끄고, 탐색기를 켜서 작업 프로젝트 폴더를 선택한 후 실행하고 확인 하겠지요? 번거롭지만 자신도 모르게 하고 있는 일들. 이것을 자동화 하기 위해 외부에서 클라이언트에게 스크립트 리로드 신호를 주고, 해당 클라이언트로 윈도우 포커스를 옴겨주는 프로그램을 만들고, Notepad++의 실행 기능을 사용해서 실행하도록 하였습니다. 이제 스크립트를 수정 중 단축키를 누르면 클라이언트가 알아서 스크립트를 다시 읽고, 해당 게임 클라이언트로 포커스도 가 있는 상태가 됩니다.

 컴파일시 번거로운 기존 클라이언트 끄기

작업 중 클라이언트를 켜서 테스트를 하다가, VC로 수정을 하는 경우가 종종 있습니다. 클라이언트를 끄지 않았다면 컴파일을 할 때 에러가 납니다. 그렇다면 마우스로 클라이언트를 선택 후 프로그램을 끄고, 다시 컴파일을 하게 되지요. 혹시나 PostBuild 기능으로 무언가 작업을 한다면 그저 버튼 한번으로는 해결이 안되고, 소스에 빈 줄을 넣는다거나 하는 식으로 컴파일 자체를 다시 하도록 명령 내려야 합니다. 그런 번거로운 일들에 대비해서, 두 가지 작업을 해보았습니다.

1) 컴파일이 가능하도록 타겟 파일 이름을 변경해줍니다.(켜져 있어도 파일 이름 변경은 가능합니다.) Prebuild 에 이하와 같이 작업해 넣으시면 됩니다.

if exist $(TargetPath) (
   move /Y $(TargetPath) $(TargetPath).bak
   @exit /b 0
)

2) 프로그램 최 상단에서 FindWindow로 클라이언트를 찾아. postMessage로 WM_QUIT를 날려줍니다.

자 이와 같은 방식으로 조금 귀찮은 작업을 자동화 했습니다.

전투 시뮬레이터와 통계를 위한 로그 기능

현재 개발중인 R 프로젝트는 병력을 구성하여 전투를 하는 방식의 게임입니다. 물론 켜면 바로 설정된 데이터 대로 전투를 하는 클라이언트 테스트 기능을 미리 구비하여 사용 중에 있습니다(이와 관련한 글은 여기를 참조). 하지만 그것만으론 부족하지요. 게임의 특성 상 많은 조합을 항상 직접 해보면서 벨런스를 맞출 수는 없습니다. 때문에 밸런스 테스트 용도로 별도의 시뮬레이터 기능을 만들었고, 모든 조합을 시뮬레이션하며 로그를 남긴 후 그 로그를 사용하여 통계를 뽑아냅니다. 몇 초 안에 내가 수정한 값으로 인해 이뤄지는 버터플라이 이펙트들을 확인 할 수 있습니다. 물론 시간 절약은 말할 필요도 없겠지요? :-)

모든 사소한 일들도 불편하다면 수정한다

작업 능률을 떨어 뜨리는 것들은, 프로그래머를 귀찮게 하더라도 꼭 해결해야 합니다. 프로그래머 입장에서는 귀찮은 1~2분짜리 일이라도 디자이너들이나 기획자들의 시간을 엄청나게 빼앗는 경우가 매우 많기 때문입니다.

오래전 경험으로 예를 들자면, 예전 회사에서는 3D Max를 사용할때 1개의 3D Max파일이 1개의 에니메이션을 처리하던 구조 였습니다. Export 때마다 에니메이션 이름 칸을 채워 넣어야 했구요. 익스포트 때마다 디자이너는 타블렛 팬을 오른손에 말아쥐고 손가락 두어개를 펴서 독수리 타법으로 이름을 처 넣어야 했습니다. 디자이너의 요구사항은 없었지만 이대로는 안되겠다 싶어 애니메이션 이름 란에 디폴트로 편집 중인 파일명을 넣어주는 기능을 추가해 주었습니다. 디자이너 분은 당연한 일이라 생각하고 별 고민없이 하던 작업이였지만 편리해지니 매우 고마워했습니다.

같은 동료로서 상대가 상대방에 맞춰 일하기 좋게 해주는 것은 좋지만, 본인이 힘든 것 까지 참을 필요는 없습니다. 언제나 지금 하는 일에 대해서는 내가 갑(甲)이기 때문입니다.

맞다! 사람은 호의가 계속되면 권리인 줄 안다!

끝으로…

자 여기까지 집중력을 떨어뜨리지 않고 오래 일하는 법에 대해서 길게 써보았습니다. 집중력은 자주 깨지기 마련입니다. 지금의 저도 일이 잘 되지않아 이 글을 쓰고 있습니다(-_-). 집중력을 올리는 것이 잘 안된다면 집중을 크게 하지 않아도 잘 되는 일을 먼저 하십시요. 혹은 본인이 재미있게 생각하는 일을 잘게 쪼게서, 힘들게 하는 일 중간 중간에 하세요. 혹은 마일스톤을 찍으면 본인 스스로에게 게임 선물을 하는 것도 좋지요. 집중력은 내공 같다는 생각이 듭니다. 고수일수록 잘 조절해서 사용하잖아요? 조절하지 못하고 폭발(몇 일씩 야근을 한다던가)하면 주화입마에 빠져 몇 일 밤낮동안 사경을 해매기도 하니까요. 잘 조절하고 관리해서 모두들 하시는일 좋은 마무리 하셨으면 좋겠습니다.

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

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

프로토타이핑

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

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

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

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

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

 

적절한 그래픽 리소스

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

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

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

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

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

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

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

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

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

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

짜잔!

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

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

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

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

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

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