Welcom to MEGAMIX

통합 메신저 PIDGIN(피진)

MEGAMIX — Fri, 20 Nov 2009 22:00:43 +0900

국내에서는 가장 많은 분들이 사용하시는 메신저가 대부분 MSN, NATEON 등일텐데요

각각의 프로그램은 버전이 올라갈수록 무거워졌고 따로 설치해 관리하기가 번거롭기도 합니다.

다양한 메신저를 통합해 가볍게 실행하는 무료 메신저 클라이언트가 바로 PIDGIN 입니다.

AIM

Bonjour

Gadu-Gadu

Google Talk

Groupwise

ICQ

IRC

MSN

MySpaceIM

SILC

SIMPLE

Sametime

XMPP

Yahoo!

Zephyr

공식 홈페이지 : http://www.pidgin.im/

네이트온 플러그인 : pidgin-nateon-2.5.6-svn137+multi-chat.rar (설치된 폴더에 덮어쓰기 하면 됩니다)

마이크로 블로그 플러그인 : pidgin-microblog-0.2.4.exe ( 트위터가 지원됩니다)

이런 콘프레이크 같으니라구 !!!

MEGAMIX — Tue, 17 Nov 2009 03:42:54 +0900

뭐 누군들 알았겠습니까…만….

윈도우도 새로 설치했겠다 포스팅도 간만에 올려볼까 새벽 이시간에 웹서핑 도중 충격적인 사실 발견.!!!

이렇답니다….

<정말 호랑이 기운이 솟아나기는 하는걸까?>

한번쯤 바쁜 일상을 사는 현대인은 쿨~하게 아침식사를 해야한다며 후다닥 먹어치웠던 그것!

( 과학적 검증은 잘 몰라 혹시나 당할지 모르는 고소 고발에 무서워 본인의 생각은 적지 않습니다. )

얼마전 회사 동료에게 들은 이야기 인데

‘율무차’ 와 ‘둥굴레차’ 는 혈기 왕성한 남성의 스테미너에 안좋은 영향을 미친다 는데 이게 사실인가요 ??

(간만에 올리는 포스팅이 영양가 없어 죄송합니다.)

키보드 마우스 공유 프로그램 Synergy(시너지)

MEGAMIX — Wed, 28 Oct 2009 13:52:50 +0900

Synergy 1.3.1 for PC (한영전환 패치 적용) SynergyInstaller_hangulkey.exe

WINDOWS 7 USB/DVD 다운로드 도구

MEGAMIX — Mon, 26 Oct 2009 15:42:26 +0900

Windows 7 ISO 이미지를 사용해서 부팅 가능한 USB를 만들때 사용합니다.

드래곤 네스트 성우영상

MEGAMIX — Sat, 26 Sep 2009 14:54:20 +0900

Attached Multimedia

개발자의 심리학

MEGAMIX — Thu, 24 Sep 2009 19:25:54 +0900

개발자는 어떤 사람일까? 개발자는 과학자에 속한다는 사람도 있고, 엔지니어에 속한다는 사람도 있고, 예술가에 속한다는 사람도 있다. 개발자는 지적인 작업으로 새로운 것을 창조하기 때문에 예술가에 가깝다. 그럼 이러한 예술가들을 어떻게 이해해야만 잘 관리할 수 있을까? 지금부터 그에 대한 내용을 알아보자.

개발이라는 작업은 고도의 집중력을 필요로 한다. 개발자가 개발하기 위해서는 명명규칙, 공통 API, 디자인 패턴, DB 테이블 구조, 성능, 상호 인터페이스 등등 많은 내용들을 머릿속에 장전하고 개발을 시작해야 한다.

■개발자의 직업병

이러한 내용이 머릿속에 제대로 장전되지 않으면, 오류가 생기거나 개발 속도가 떨어진다. 한 가지 일에 집중해야 하는 직업 특성상 개발자를 주변에서는 내성적인 사람이라고 오해하기도 한다. 하지만 그들 성격이 내성적이기 때문에 그런 것이 아니라, 정신의 에너지를 내부에 집중해야 하기 때문에 다른 사람이 볼 때 그렇게 보이는 것이다.

개발자들은 숲을 보기보다는 나무를 보는 경향이 있으며, 작은 것에 민감하게 반응한다. 또한 자기 관심 분야에는 굉장한 열정을 보이지만 다른 분야에는 관심을 보이지 않는다. 모든 개발자가 그런 것은 아니지만, 외부에서 개발자를 보는 인식은 대체로 위와 같다.

개발자는 자기 자신과 일을 가장 많이 한다. 타인과 같이 일하는 시간보다, 자기 자신과 대화하면서 일하는 시간이 많다. 그러다 보니 다른 사람과의 커뮤니케이션 기술이 부족한 경우가 많아서 함께 일하는 데 원활하지 못한 경우가 있다.

그런데 개발자라고 처음부터 내성적이고, 커뮤니케이션이 부족한 사람은 아니었을 것이다. 직업 특성상 자기 자신과의 싸움을 오랫동안 외롭게 하다 보니 그렇게 된 것이다. 개발자와 함께 일하는 관리자와 이해 관계자들은 이러한 개발자의 특성을 잘 이해해야만 프로젝트를 성공적으로 수행하는 데 유리하다.

■개발자의 무아지경

개발자가 고도의 집중 상태에 빠져드는 것은 마치 ‘무아지경’과도 같다(영어로는 ‘in the zone’ 또는 ‘flow’라고 한다). 한번 이런 상태에 빠지면 굉장한 속도로 개발을 해 나간다. 개발자의 생산성이 최대가 되는 순간이다. 그런데 한 가지 안타까운 것은 이 상태가 너무나도 쉽게 깨져 버린다는 것이다. 한 예를 들어보자.

개발자가 열심히 무아지경에 빠져서 개발하고 있는데, 갑자기 고객으로부터 전화가 왔다. 개발자는 전화를 받자마자 고객으로부터 짜증 섞인 목소리를 들었다.

고객은 온갖 짜증을 내면서 이따위 시스템 못 써먹겠다고 불평불만을 쏟아낸다. 이 순간 개발자의 무아지경 상태는 깨졌고, 이를 다시 회복하는 데에는 많은 시간이 소요될 것이다. 머릿속에 장전해 놓은 각종 명명규칙, 공통 API, 디자인 패턴, DB 테이블 구조, 성능, 상호 인터페이스 등등 많은 내용이 순식간에 언로드(unload)되고 고객의 짜증섞인 불만 내용이 머릿속에 로딩(loading)된다.

이를 다시 끄집어내고(unload) 다시 무아지경에 빠지기 위해 명명규칙, 공통 API, 디자인 패턴, DB 테이블 구조, 성능, 상호 인터페이스 등의 내용을 다시 장전하기 위해서는 정신 상태부터 치유해야 한다. 갑자기 고객으로부터 온갖 욕을 얻어먹은 개발자는 정신 치유를 위해 담배를 피우던지, 음악을 듣던지 하는 휴식 시간이 필요하다.

그런데 프로젝트 막바지에 다다라서 시간이 촉박하고 깐깐한 관리자를 만났다면 그나마도 못한다. 정신적인 쇼크 상태에서 개발을 지속하다 보면 많은 오류를 양산하게 되고, 향후 고객으로부터 다시 한 번, 이 시스템 못 써먹겠다는 소리를 듣는 악순환이 이어진다.

낮에는 이해 관계자들의 전화에 시달려 일을 하지 못한 개발자는 드디어 모두 퇴근한 밤이 되어서야 자기 자신만의 시간을 가질 수 있었다. 밤새 무아지경에 빠져서 수정사항을 다 고친 후에야 퇴근했다. 그런데 다음날 아침 9시에는 관리자가 프로젝트 진행 상태를 점검하기 위해 이해 관계자와 함께 하는 회의 시간을 잡아 놓았었다.

관리자와 이해 관계자는 아침 9시에 모여서 회의가 시작되기를 기다리는데, 개발자는 아직 출근도 안했다. 관리자는 개발자가 어제 몇 시에 퇴근했는지 모르는 채, 그리고 왜 야근을 해야 하는지도 모르는 채, 매일 지각 출근한다고 이미 불만이 많았다.

고객은 아침 9시부터 불러놓고 회의도 안 한다면서 관리자를 독촉하기 시작했고, 관리자는 연신 휴대폰을 부여잡고 개발자에게 전화를 한다. 드디어 아침 10시가 되어 개발자가 나타나자, 관리자는 그동안 참았던 모든 불만을 다 쏟아냈다. 이를 묵묵히 듣고 있던 개발자는 끊었던 담배를 다시 피워야만 했다. 그렇게 프로젝트는 진행이 되었고, 그래도 끝을 보게 되었다.

드디어 프로젝트 종료보고를 하던 어느 날 그 개발자는 홀연히 사라져 버렸다. 그가 어디로 갔는지 아는 사람은 없었다. 혹자는 그가 머리를 깎고 중이 되었다는 사람도 있고, 그가 공사장에서 트럭 몰고 있는 모습을 봤다는 사람도 있고, 이민을 갔다는 사람도 있고, 다들 추측만 난무했다.

위는 실제 사례는 아니지만, 현장에서 얼마든지 있을 수 있는 사례다. 개발자는 고도의 집중상태에 한번 빠지면 엄청난 생산성을 낼 수 있지만, 아쉽게도 이 상태는 외부의 충격에 의해 쉽게 깨져버린다. 그런데 이 무아지경 상태는 context switching(문맥 변화)이 일어나는 상태에서만 깨진다.

컴퓨터에서 프로세스나 스레드가 바뀔 때 context switching이 일어난다. 하나의 CPU는 한 번에 하나의 작업만 할 수 있기 때문에, 여러 작업을 동시에 하기 위해서는 작업이 바뀔 때마다 context switching을 해서 작업을 진행하기 위한 기본적인 내용을 CPU 레지스터에 로딩해야만 한다. 사람의 두뇌도 이와 유사해 비슷한 일을 계속하는 경우에는 context switching이 일어나지 않는다.

개발자가 개발하는 중간에 지금 무슨 일을 하고 있는지 묻는 질문은 context switching을 일으키지 않는다. 하지만 위의 사례처럼 고객의 전화를 받는 작업은 context switching을 일으킬 수 있는 작업이다. 개발자는 과학자도 엔지니어도 아니다. 자기 자신과의 싸움에서 새로운 것을 창조해 내야 하는 예술가인 것이다. 그런 예술가를 마치 하나의 기계 부속품인 것처럼 고장나면 교환하면 된다고 간주하거나, 통제를 많이 하면 할수록 더 일을 잘 한다고 생각한다면, 개발자의 업무 특성을 잘 이해하지 못한 것이다.

■무아지경에 빠지기 위한 환경

유명한 개발자 사이트인 DevX(www.devx.com)에 보면 Bryan Dollery가 2003년에 쓴 ‘개발의 심리학 이해’라는 글이 있다(www.devx.com/DevX/Article/11659). 이 글에 보면 개발자가 무아지경에 빠지는 것을 돕는 세 가지 방법이 나와 있다.

- 적절한 정신적 격리 상태를 제공할 것
- 창의적인 에너지를 재충전할 수 있는 적절한 시간을 제공할 것
- 이치에 맞는 특별한 요구를 수용해줄 것

개발자가 정신적으로 집중할 수 있도록 방해되는 주변 환경을 차단해야 한다. 한 예로 수정사항이나 요구사항은 개발자가 직접 듣는 것이 아니라 관리자가 일괄 취합해서 우선순위를 정해 개발자에게 전달하는 것이 전체 프로젝트의 생산성을 높이는 데 도움이 된다.

개발자가 개발에 집중할 수 있도록 주변 환경을 조성해 주는 것이 관리자로서 해야할 첫 번째 임무인 것이다. 두 번째는 개발자가 중복된 실수를 하지 않도록 그들에게 적절한 휴식시간을 제공해 주어야 한다는 것이다. 무아지경 상태에 다시 빠질 수 있도록 적절한 휴식이 필요하기 때문이다. 세 번째는 개발자들이 원하는 특별한 요구사항이 있다면 수용해주라는 것이다.

긍정 심리학 분야의 세계적인 대가인 시카고 대학의 칙센미하이(Csikszentmihalyi) 교수는 노벨상 수상자 또는 뛰어난 과학자들의 심리 상태를 연구해 몰입(flow)에 대한 많은 책을 썼다. 특히 우리나라에도 소개된 ‘몰입의 즐거움’, ‘몰입의 경영’ 등을 통해 ‘몰입 이론’으로 세계적인 명성을 얻었다.

그가 인용한 한 유명 컴퓨터 과학자는 자신이 샤워를 할 때 가장 많은 아이디어가 떠올랐다고 한다. 그러던 그가 한 회사에 취직을 했는데, 그 회사는 샤워 부스를 제공하지 않았다. 그 이후 그는 새로운 아이디어가 떠오르지 않아서 그만 두었고 샤워부스를 제공해 주는 다른 회사로 옮겼다. 그랬더니 거기에서는 많은 아이디어가 떠올라서 일을 계속 할 수 있었다고 한다.

여기에서 샤워부스는 개발자의 특별한 요구사항에 속하는데, 아마 우리나라의 환경에서는 개발자 1명을 위해 샤워부스까지 만들어 주기는 어려울 것이다. 그것보다는 개발자들이 무아지경(몰입)에 다시 쉽게 빠질 수 있도록 적절한 휴식 공간을 제공해 주는 것이 더 좋은 방법이다.

■개발자는 멀티태스킹 기계가 아니다

조엘은 그의 블로그의 ‘개발자는 멀티태스킹 기계가 아닙니다(Human Task Switches Considered Harmful)’라는 글에서 개발자에게 두 가지 일을 동시에 시키지 말라고 했다. 위에서 언급했듯이 개발자가 개발을 하기 위해서는 한 가지 일에 집중해야 한다.

그런데 두 가지 일을 한꺼번에 시키면 개발자는 두 가지 일 사이에서 문맥교환(context swtching)을 하느라고 오히려 전체 개발 시간이 더 늦어지게 된다. <그림 1>은 조엘이 제시한 예제이다. A라는 작업과 B라는 작업이 있는데, 각각 10초씩 걸린다. 이를 순서대로 처리하면 아래와 같다.

이를 멀티태스킹으로 처리하면 <그림 2>와 같다.

순서대로 처리하면 A를 처리하는 데 10초, B를 처리하는 데 20초가 걸렸다. 평균으로 하면 15초이다. 그런데 멀티태스킹으로 하면 A를 처리하는 데 19초, B를 처리하는 데 20초 걸렸다. 평균 19.5초이다. 오히려 멀티태스킹의 평균 시간이 더 큰 것을 알 수 있다.

문맥을 교환하는 데 비용이 드는 경우도 따져봐야 한다. 실제 개발자가 멀티태스킹을 하기 위해서는 문맥 교환 비용이 들어간다. 문맥을 교환하는 데 0.5초가 걸린다고 가정하고 계산하면 <그림 4>와 같다.

평균적으로 보면 멀티태스킹이 28초나 걸린다는 것을 확인할 수 있다. 이렇듯 개발자에게 두 가지 일을 동시에 시키는 것은 결국 생산성만 악화시키는 결과를 초래한다. 개발자들이 한 가지 일에 집중할 수 있도록 관리자는 일을 적절히 배분하는 기술과 요령을 익혀야 한다.

가장 최악의 케이스는 관리자가 개발자에게 할 일을 모두 던져주고 알아서 하라는 식으로 두는 경우이다. 그렇게 일을 주면 개발자는 한 가지 일에 집중할 수 없다. 관리자는 근본적으로 일에 대한 관리를 하는 사람이다. 자신이 작업에 대한 관리를 하지 않고 개발자에게 일임한다면 그 팀의 생산성은 좋지 않을 것이다.

■비자아적 프로그래밍(egoless programming)

비자아적 프로그래밍은 『컴퓨터 프로그래밍의 심리학』(The Psychology of Computer Programming, Weinberg 1971)이라는 책에서 처음 언급됐다. 그 책의 요지는 개발자는 자신이 만든 프로그램에 자아를 투영해서는 안 된다는 것이다. 프로그램을 마치 자신의 작품인 것처럼 생각한다면 남들의 비판에 방어적이 되기 때문이다. 오류보고서는 인신공격으로, 검토는 위협으로, 작업에 대한 질문은 비생산적으로 생각해 오히려 제품의 품질을 떨어뜨릴 수 있다. 팀으로 작업하는 프로젝트에서는 이러한 상황을 내버려 둬서는 안 된다.

누군가가 자신의 코드에 대해 오류를 지적하면 개발자는 감정적으로 대응하게 되고, 나중에는 오류가 있더라도 지적을 하지 않는 사태가 발생해 결국에는 프로젝트의 품질이 떨어질 수 있다. 따라서 개발자는 프로그램을 자신의 작품처럼 생각해서는 안 되며, 팀 작업의 결과물로 인식해야 한다는 것이다. 이러한 ‘비자아적 프로그래밍을 위해 개발자가 갖춰야 할 10가지 지침(Ten Commandments of Egoless Programming)’이라는 것을 TechRepublic이라는 사이트에서 Lamont Adams라는 사람이 주장했다.

1. 당신은 실수할 수 있다는 것을 받아들이고 이해하라
실수는 일찍 발견할수록 좋은 것이다. 일찍 발견할수록 수정 비용도 적게 든다.

2. 당신의 코드는 당신의 작품이 아니다
코드 리뷰의 목적은 문제를 발견해서 치료하는 것이다. 그것을 개인적인 감정으로 받아들이지 마라

3. 장기도 훈수 두는 사람이 더 잘 안다
장기를 두다 보면 장기에 몰입해서 장기를 두는 사람보다도 주변에서 훈수를 두는 사람이 더 잘 알 수도 있다. 따라서 주변에서 하는 가르침에 겸손해야 한다.

4. 조언 없이 코드를 다시 쓰지 마라
혼자서 독단적으로 판단해서 코드를 다시 작성하지 말고, 코드 리뷰를 통해 코드를 다시 작성해라

5. 잘 알지 못하는 사람들을 존경하고, 복종하고, 참아라.비기술자들은 개발자들을 좋을 때는 오페라의 프리마돈나처럼 생각하지만, 안 좋을 때는 울보로 간주한다. 여기에 휘둘리지 마라.

6. 세상에서 변하지 않는 진리는 변한다는 것이다.
변화에 대해 열린 마음으로 웃으면서 받아들여라. 요구사항의 변화, 플랫폼의 변화, 기술의 변화 이 모든 것에 대해 열린 마음으로 받아 들여라.

7. 진정한 권위는 직위가 아닌 지식으로부터 나온다.지식은 권위를 낳고, 권위는 존경을 낳는다. 그러므로 비자아적 프로그래밍 환경에서 존경을 받고 싶다면 지식을 쌓아라.

8. 당신이 알고 있는 지식을 고수하며 싸워라. 그러나 패배는 겸허히 받아 들여라.때로는 당신의 아이디어가 채택되지 않을 수 있다. 심지어 나중에 그것이 더 낫다고 밝혀지더라도 “내가 말한 게 맞죠?”라면서 복수할 필요는 없다.

9. 독방의 개발자는 되지 마라어두운 사무실에 홀로 앉아서 콜라 살 때만 나타나는 은둔형 개발자는 되지 마라.

10. 사람이 아닌 코드를 비판하고, 코드가 아닌 사람에게 친절해라코드에 대한 코멘트는 긍정적이며, 개선하는 방향으로 해야 하며, 기존 코드에 대한 비판적인 방향은 좋지 않다.

이러한 비자아적 프로그래밍이 정착되기 위해서는 프로젝트 팀 내에서도 노력이 필요하다. 가령 “이 프로그램은 누가 짜서 이렇게 오류가 많아”라는 식으로 말하게 되면 이는 결국 말하는 사람 스스로가 개발자와 코드를 하나로 인식한 셈이 된다.

이러한 언급을 용인하고 묵인해 주는 환경에서는 비자아적 프로그래밍을 할 수 없다. 또한 개발자가 한번 개발한 코드에 대해서는 영구적인 오류 수정 권한을 부여하는 환경에서도 비자아적 프로그래밍을 할 수 없다. 비자아적 프로그래밍은 특히 오픈소스 환경에서도 잘 적용되는 개념이다. 한명의 독창적인 작품이 아닌 공동의 작품으로 간주하는 오픈소스 환경에서는 누구든지 오류를 수정하고 개선해 가면서 함께 개발해 나갈 수 있다.

이러한 비자아적 프로그래밍은 여러 명이 작업하는 팀 환경에서는 어느정도 필요한 부분이다. 그런데 위의 10가지 지침을 다 지키려면 개발자는 소인이 아닌 군자가 되어야 한다. 남의 비판도 겸허히 받아들여야 하고, 자신이 공들여 애써 만든 작품을 남들이 무너뜨리더라도 웃으면서 받아들여야 한다.

개발자는 자존심을 다 버리고 군자가 되어야 한다. 현실적으로 쉽지 않은 일이다. 필자는 현재도 개발을 하지만, 필자가 개발하는 프로그램에는 최대한의 정성을 다 쏟으려고 노력한다. 하나의 작품을 만든다는 생각으로 내 자신의 자아를 투영한다. 그래야만 정성을 가지고 애착을 가지고 만든다. 만약 개발자가 프로그램에 자아를 심지 않는다면 어떤 정성과 애착을 가지고 잘 만들 수 있을까? 자아 없이 잘 통제하고 잘 감시하면 좋은 프로그램이 나올 수 있을까?

정도의 차이는 있겠지만, 극단적인 비자아적 프로그래밍도 좋지 않으며, 그렇다고 프로그램에 자신의 자아를 너무 투영한 나머지 주변의 충고를 무시하는 것도 좋지 않다.

필자는 앞으로도 내 ‘작품’에는 자아를 투영할 것이다. 자신의 작품에는 항상 최선을 다 하고 싶은 것이 예술가들의 자존심이다. 이를 무시한 채, 자아를 버리라고 강요하는 것은 이 또한 현실을 무시한 생각이다. 열린 마음으로 자신의 작품을 향한 주변의 비판을 받아들이는 예술가야말로 진정으로 좋은 작품을 만드는 예술가다.

참고자료
1. 소프트웨어 공학의 사실과 오해, 로버트 L. 글래스, 2003
2. 조엘 온 소프트웨어, 조엘 스폴스키, 2004
3. Professional 소프트웨어 개발, 스티브 맥코넬, 2004
4. 똑똑하고 100배 일 잘하는 개발자 모시기, 조엘 스폴스키, 2007
5. 스크럼-팀의 생산성을 극대화시키는 애자일 방법론, 켄 슈와버, 마이크 비들, 2002
6. 피플웨어, 톰 디마르코, 2003
7. 개발의 심리학 이해, http://www.devx.com/DevX/Article/11659
8. 개발자는 멀티태스킹 기계가 아닙니다, http://www.joelonsoftware.com/articles/fog0000000022.html
9. 비자아적 프로그래밍을 위한 10가지 지침, http://articles.techrepublic.com.com/5100-10878_11-1045782.html

[필자소개]
한용희 woom33@korea.com｜현재 Microsoft Visual C# MVP이며, 여러 SW 개발 프로젝트에 참여했다. 다양한 SW 개발 프로젝트에 참여해 오면서 항상 더 나은 개발 방법에 대해 고민하고 있다.

마비노기 영웅전의 타격판정

MEGAMIX — Tue, 22 Sep 2009 14:11:42 +0900

■ 타격 판정이란 무엇인가

칼 과 같은 근접 무기를 들고 전투를 하는 게임에서 가장 기본이 되는 처리는 "때리고 맞는 판정"을 하는 것입니다. 이를 <타격 판정>이라고 하는데, 3D로 만들어진 많은 게임들은 다양한 방식으로 타격 판정을 하게 되며 이것이 게임성에 큰 영향을 주게 됩니다.

액션 게임을 많이 해보신 분들은 그 차이를 아시겠지만, 보통의 온라인 게임들은 단순한 방식으로 타격 판정을 하기 때문에 세밀한 액션성을 살리기에 적합하지 않습니다. 그러나 마비노기 영웅전에서는 재미있고 리얼한 액션을 위해 한층 정교한 타격 판정을 실시하고 있습니다.

■ 보통의 MMORPG 방식

타 격 판정을 하는 가장 단순한 방법은 오직 공격자와 피격자 사이의 거리만 가지고 체크하는 것입니다. 공격이 이루어졌는데 둘이 일정 거리내에 있었다면 맞은 것으로 판정하게 됩니다. 이런 방식을 쉽게 설명하자면, 캐릭터와 몬스터를 구(球) 또는 원통과 같이 매우 간단한 모습으로 간주하는 것입니다.

아래 그림은 예를 들어서 나타내본 것인데, 파란 원과 빨간 원이 겹치면 몬스터는 공격에 맞았다고 판정됩니다.

그리고 방향에 의한 판정을 추가할 수도 있습니다. 이럴 때는 공격 범위가 부채꼴과 비슷한 모습으로 체크됩니다.

그 리고 이런 요소들은, 시간에 의한 움직임 역시 반영되지 않습니다. 칼을 한 번 휘두르면 범위 내의 모든 몬스터들이 동시에 맞을 뿐이지, 오른쪽에서 왼쪽으로 휘두른다고 해서 왼쪽 몬스터가 오른쪽 몬스터보다 조금 더 늦게 맞지는 않습니다.

보통의 온라인 게임들은 대개 이렇게 단순하게 타격판정을 합니다.

MMORPG 는 액션성이 중요하지 않으므로 이런 식으로 타격판정을 해도 큰 문제가 없지만, 순간의 조작으로 생사가 오가는 액션 게임에서는 이런 처리만으로는 많이 부족해집니다. 몬스터와의 거리와 방향만이 고려되고, 몬스터의 모양이나 움직임 시간, 고저차 같은 것은 전투에 영향을 미치지 않기 때문입니다.

■ 마비노기 영웅전의 타격 판정 방식

영웅전에서는 액션게임이라는 이름에 부끄럽지 않고자, 정교한 타격 판정 방식을 쓰고 있습니다. FPS 게임 엔진의 기초 위에 디테일한 근접무기 판정을 덧붙인 방식입니다.

플 레이어와 몬스터에는 모두 위 그림과 같은 히트박스(hitbox)라는 것이 있습니다. 히트박스는 움직이는 사지에 각각 눈에 보이지 않는 상자를 입힌 것으로, FPS 게임에서 총알에 맞았는지 판별할 때에 이 상자를 기준으로 처리하게 됩니다. 여러분이 즐겨쏘는(?) 헤드샷 같은 것도, 머리에 해당하는 히트박스가 맞았는지 판단하는 방식으로 처리합니다. 다른 곳에 비해 어느 부위가 약점이라는 것도 이런 식으로 만들어집니다.

FPS 게임이라면 선(線)으로 발사되는 총알 궤적이 히트박스에 맞았는지 체크하는 것만으로도 충분합니다. 그러나 영웅전은 근접공격이 주가 되는 게임이므로 더 특수한 처리가 필요합니다. 칼날이 휩쓸고 간 면(面)이 히트박스에 맞았는지 판정하는 것입니다. 이를 통해 칼이 팔을 베고 지나갔는지 다리를 베고 지나갔는지 정교한 판정이 가능합니다. 18세 버전에서 몬스터 몸에 묻는 피도 무작위로 보이는 게 아니고, 타격된 부위에 정확히 나타나는 것입니다.

이 때문에 움직임의 시간에 따른 영향도 생겨납니다. 칼을 오른쪽에서 왼쪽으로 휘두르면, 왼쪽에 있는 몬스터는 오른쪽 몬스터보다 늦게 맞게 됩니다. 타격감을 위해 칼날이 몬스터 몸에 걸려 잠시 멈추는 처리도 동작하므로, 다수의 적에 포위되어 싸우는 불리한 상황에는 정말 0.1초의 차이로 생사가 달라질 수 있습니다.

이런 정교한 처리는 '쫀득한 타격감'의 바탕이 됩니다. 타격감을 만드는 요소는 이펙트, 사운드, 카메라 처리 등 여러가지가 있지만 여기에다 정교한 타격판정이 더해져 영웅전 특유의 쾌감이 생깁니다.

Attached Multimedia

* 위 동영상에서 몬스터의 움직임과 히트박스의 움직임이 달라보이는 이유는, 서버와 클라이언트 사이에 통신시간(ping)과 보간(interpolation) 처리로 인해 클라이언트 쪽이 0.1초 정도 과거의 모습을 보여주기 때문입니다. 공정성을 위해 이에 따른 오차를 줄이고자 서버에서 지연보상(lag compensation)이라고 하는 처리를 해 과거시점으로 히트박스의 위치를 되돌려 판정하는 처리가 들어가는데, 복잡하니까 자세한 설명은 생략합니다.

플 레이어도 적의 공격에 맞을 때에도 비슷하게 정교한 방식을 사용합니다. 이 때문에 자세나 움직임에 따라서 재미있는 상황이 전개되기도 합니다. 제가 테스트 플레이를 할 때 겪은 일로는, 전투 중에 체력도 스태미나도 바닥난 절체절명의 순간에, 힘들어서 허리를 숙이는 동작을 하다가 아슬아슬하게 화살을 피해서 살아남은 적이 있었습니다. 이런 의외의 순간들이 벌어지는 것도 영웅전만의 매력입니다.

(비슷하게 재현해보았습니다)

그 리고 새로 등장할 캐릭터 커스터마이즈 메뉴에는, 캐릭터의 '키'를 조절할 수 있게 됩니다. 정교한 타격 판정 때문에, 영웅전에서는 키가 크면 공격범위가 약간 더 넓어지게 됩니다. 그 대신 밸런스를 맞추기 위해서 공격속도가 약간 더 느려지게 했습니다. 그리고 덩치만큼 약간이나마 화살도 더 잘 맞게 됩니다. +-5% 정도의 미세한 차이라서 크게 드러나는 것은 아니지만요.

하지만 영웅전이라도 맹목적으로 리얼리티만을 추구하는 것은 아닙니다. 리얼리티는 게임의 재미를 위해 존재하므로, 재미를 위해서는 적당한 과장도 섞여 있습니다. 특히 스매시 계열의 액션들은 통쾌함을 위해 뻥뻥 날라가게 만들었습니다.

지연보상 이외에도 온라인 플레이를 보완하는 여러가지 복잡한 테크닉과 트릭이 곁들여져서 영웅전의 종합적인 타격감과 공방을 만들게 됩니다.

■ 거대한 몬스터를 상대할 때에 드러나는 차이점

영웅전의 정교한 타격 판정의 이점은 몸집이 큰 거대 몬스터와 싸울 때 더욱 빛을 발합니다.

Attached Multimedia

영 웅전의 거대한 보스 몬스터와 싸워본 분들은 이 이야기를 실감하실 겁니다. 위 동영상에서 거대 몬스터의 뒷발목을 칼로 베는 장면처럼, 몬스터의 몸통과 사지에 각각 타격이 맞아 들어가며, 보스의 공격 역시 마찬가지입니다. 멀리서 창을 던져 몬스터의 약점에 꽂아넣는 플레이는 쉽게 할 수 있는 것이 아닙니다.

액션이든 RPG이든 영웅전 외의 온라인 게임에서 이런 방식을 쓰는 게임은 거의 없으며, 있더라도 한정적으로만 적용하곤 합니다. 일부 게임에서는 보스 이외의 피래미 몬스터와의 전투에는 기술적 문제로 동기화(同期化) 처리를 하지 않아서, 나와 같은 몬스터를 상대하고 있는 동료가 내게는 허공에 칼질을 하고 있는 것처럼 보이기도 합니다.

영웅전에서는 이런 디테일한 타격 공방에, 물리 엔진이 주변 환경을 시뮬레이션하므로 한층 현장감과 긴장감을 제공합니다. RPG이든 액션이든 다른 온라인게임에서 한 번도 겪어보지 못한 체험을, 이 게임의 세계에서는 즐기실 수 있을 겁니다.

하드디스크의 내용을 알기쉽게 SpaceMonger

MEGAMIX — Wed, 16 Sep 2009 16:49:32 +0900

SpaceMonger 는 하드디스크와 파일시스템을 비주얼적으로 보여주는 유틸리티 입니다.

하드디스크에 설치된 프로그램의 용량, 디렉토리 구조등을 파악할때 유용합니다.

거짓말 같지만 사실인 얘기들

MEGAMIX — Fri, 11 Sep 2009 01:42:03 +0900

1. 오른손잡이가 왼손잡이보다 평균적으로 9년 오래 산다.

2. 딥키스를 하면 입안에서는 4만개의 기생충과 250종류의 박테리아가 교환된다.

3. 재채기를 심하게 하면 늑골이 부러진다.
그리고 정말 심하게 재채기를 하면 머리나 목 혈관이 파열되어 죽을 수가 있다.

4. 이소룡의 움직임이 너무 빨라 필름의 재생속도를 늦춰야 했다.

5. 사람은 눈을 뜨고 재채기를 할 수 없다.

6. 뇌는 텔레비전을 보고 있을 때 보다 자고 있을 때 더 활발하게 움직인다.

7. marlboro의 최초 오너는 폐암으로 죽었다.

8. 세계에서 가장 어린 나이에 아기를 낳은 부모의 연령은 8세, 9세였다.
1910년 중국의 이야기.

9. 전화를 발명한 벨은 평생 그의 부인과 어머니에게 전화를 걸지 못했다.
왜냐하면 두 사람 다 귀가 들리지 않았기 때문이다.

10. 미국에서 영어를 말하는 사람과 중국에서 영어를 하는 사람의 수를 비교해 보면,
중국에서 영어를 하는 사람의 수가 더 많다.

11. 남성은 여성보다 작은 글자를 더 잘 읽을 수 있다.
하지만 여성은 남성보다 작은 소리를 더 잘 듣는다.

12. 사람은 자신의 호흡을 멈춰 자살을 할 수 없다.

13. 돼지는 하늘을 볼 수 없다.

14. 달팽이는 3일 동안 잠을 잘 수 있다.

15. 코끼리는 샴푸를 할 수 없는 유일한 동물이다.

16. 맥도널드의 이익의 4할은 해피세트가 벌고 있다.

17. 인간은 평균적으로 매일 3회 자명종 시계를 멈추고 있다.

18. 달걀이 먼저인지 병아리가 먼저인지,
창세기에 의하면 “달걀이 먼저”라고 되어 있다.

19. 여성은 남성보다 눈을 깜박거리는 회수가 2배 많다.

20. 개가 쵸콜릿을 먹으면 죽는 경우가 있다. 심장과 신경에 영향을 미치기 때문이다.

21. 악어에게 물렸을 때 도망치는 방법. 악어의 눈알을 손가락으로 찔러버린다.

22. 성서에 나오지 않는 동물은 고양이.

23. 바퀴벌레는 머리가 없어도 10일 이상 살 수 있다.

24. 8할의 미국인들은 파란색을 좋아한다.

25. 손톱의 성장 속도는 엄지손가락이 가장 빠르다. 가장 느린 것은 중지.

26. 평균적인 4세의 아이는 매일 400번이상의 질문을 한다.

27. 달이 바로 위에 있을 때는 체중이 가벼워진다.

28. 사람은 평균적으로 하루에 6번 화장실에 간다.

29. 인간이 평생 단 한 번도 머리를 자르지 않으면 머리의 길이는 10미터가 된다.

30. 지금도 사용되고 있는 가장 긴 지명은
“Taumatawhakatangihangaoauauotameteaturipukakpikimaungahoronukupokaiwhenuakitanatahu.”
뉴질랜드에 있는 어느 언덕의 이름.

31. 이어폰을 1시간 이상하고 있으면, 귀안의 박테리아의 수는 700배가 된다.

32. 코카콜라는 원래 녹색이었다.

33. 세계에서 가장 많은 이름은 Muhammad.

34. 111,111,111 x 111,111,111 = 12,345,678,987,654,321

35. 모든 북극곰은 왼손잡이.

36. 평균적으로 인간은 죽음보다 거미를 무서워한다.

37. 전기의자는 치과의사에 의해 발명 되었다.
ㅡ 전기의자를 고안한 것은 치과의사(알프레드 사우스윅),
그것을 제작한 것은 에디슨사 직원인 해롤드 브라운.
에디슨 자신은 전기의자와 직접적인 관련이 없습니다.

38. 라이터는 성냥보다 먼저 발명되었다.

Making of Street Fighter 4 (Pass)

MEGAMIX — Thu, 10 Sep 2009 23:16:28 +0900

Attached Multimedia

동영상 인코딩 : 유마일 인코더

MEGAMIX — Tue, 08 Sep 2009 02:09:05 +0900

* 프로그램 설치시 디비고P2P가 설치됩니다. 원치 않으시는 분은 체크박스에서 제거 하시고 설치하세요.

* 최근 업데이트 : UmileEncoder_1_9_6_0.exe

스타크래프트2 배틀넷 2.0 스크린샷

MEGAMIX — Sat, 22 Aug 2009 11:54:21 +0900

Torchlight(토치라이트)

MEGAMIX — Sun, 26 Apr 2009 15:20:21 +0900

미소스 기술력의 새로운 역작 'Torchlight(토치라이트)'

Title: Torchlight

Release date : TBA(미정) l Genre : Action RPG

Developer : Runic Games l Publisher : Perfect World
Platform : PC Online

액션 MMOG ‘미소스(Mythos)’를 개발중이던 플래그십 스튜디오 시애틀의 옛 멤버들이 새로운 게임 개발사를 설립, 액션 RPG MMO 개발을 재개한다.

새로운 개발사의 사명은 ‘루닉 게임즈(Runic Games)’로 플래그십 스튜디오 시애틀의 핵심 멤버들이 그대로 포진해 있다.

이 중에는 플래그십 스튜디오 시애틀에서 ‘미소스’의 프로젝트 디렉터를 담당했던 트라비스 발드리(Travis Baldree)와 블리자드 노스, 플래그십 스튜디오의 창립 맴버이자 ‘미소스’ 개발을 총괄했던 맥스 쉐퍼(Max Schaefer)가 포함되어 있다.

루닉 게임즈는 자신들의 홈페이지(http://www.runicgames.com)를 통해 “루닉 게임즈는 그들의 전문적인 기술을 사용해 게임 시장에서 성공할 수 있는 액션 RPG MMO 장르를 개발해 나갈 것이다.”라고 밝혔다.

DIABLO 3 - 유저인터페이스

MEGAMIX — Tue, 31 Mar 2009 13:42:22 +0900

DIABLO 3 - 컨셉아트 (몬스터)

MEGAMIX — Fri, 20 Feb 2009 10:19:13 +0900