'게임/개발 이야기'에 해당되는 글 31건

  1. 2009/10/01 로딘 보노횽과의 잡담 (12)
  2. 2009/06/28 로딘 iDoGame 리그 - 뭔가 만들어볼까나? (2)
  3. 2009/06/23 로딘 나도 폐인 (6)
  4. 2009/05/17 로딘 레이싱 게임에서의 위치 동기화 (8)
  5. 2008/12/22 로딘 오디션 잉글리쉬 베타 테스트 (6)
  6. 2008/06/06 로딘 Ouroboros Number (10)
  7. 2008/04/12 로딘 문득 든 생각 (6)
  8. 2007/11/12 로딘 Project T, Postmortem (4)
  9. 2007/11/07 로딘 C# 공부 : MsnJuly 개발 (12)
  10. 2007/10/01 로딘 정말 힐러는 재미없는가? (10)

#0
최근 창 밖으로 청계천이 보이는 곳에 위치한 A모사에 입사하였습니다.
이번엔 클라이언트팀의 팀원입니다. 그리고보면 제 이력은 참 유별납니다.
게임 업계에는 서버 플머로 입문했는데 말입니다. 두 번째 프로젝트를 할 때는 PM 겸업이긴 했지만 클라이언트 플머였구요. 이직해서 진행했던 프로젝트에서는 다시 서버를 맡게 되었습니다. 그리고 이 곳에서 다시금 클라이언트를 만지게 되었네요.
뭐 결국 따지고보면 게임 로직을 하고 싶어했고, 하다 보니깐 이런 식이 된 것 같습니다만...
주위 분들도 제 정체를 헷갈려하시길래 ㅎㅎ.

여튼 그래서 요즘은 또 지긋지긋한 충돌 처리를 하고 있습니다(...)
두 번째 프로젝트에서의 끔찍했던 기억이 떠오르네요.
(어려워서 그러는거지 싫어하는 작업은 아닙니다. ㅎㅎ)

한창 현기증 나던 와중에 보노횽이 말을 걸어와서 이런저런 이야기를 나눴는데...
오늘은 그 썰을 풀어봅니다. (이제 허본좌님 얼굴도 지겹잖아요.)

#1
http://www.codeproject.com/kb/tips/vc20 ··· bug.aspx

VS2003에는 이런 버그가 있다고 하네요.
대충 요약하자면 유일해야 할 싱글턴 객체가 컴파일러 최적화에 의해 2개가 생길 수도 있다라는 야그같은데... 전 VS2008을 쓰니깐 안심. (아직 구시대의 유물을 쓰고 있는 보노횽에게 애도를...)

요즘 싱글턴은 디자인 패턴 중 하나라고 칭송받지도 않는, 그야말로 개나소나 너도나도 사용하는 패턴이 되었는데요. 그동안 이런저런 진통을 겪기도 하였지요.
예를 들면 소멸 순서 관리가 안 되서 별도의 자료 구조에서 생성/소멸 관리를 해준다거나...
멀티 스레드에 취약해서 DCL(Double-checked Locking) 기법을 사용한다거나... 뭐 그랬죠.

static 변수를 활용하는 방법이다보니,
dll과 exe 사이에서는 또 유일성이 보장되지 않는다는 문제도 있는데요.
http://www.gpgstudy.com/forum/viewtopic ··· ac51d770
이런 방법으로 해결이 가능하다고 하네요.
이건 보노횽이 보여준 코드... 일케 막 공개해도 되는건가? ㅎㅎ

전 최근에 Loki 라이브러리에 포함된 녀석을 사용하고 있습니다.
구현 내역을 보면 현기증날 것 같지만 사용하는데는 큰 무리가 없지요.

#2
VS(Visual Studio)에서 작업을 하다보면,
솔루션 탐색기가 아닌 다른 곳을 통해 코드를 선택하게 될 때가 있는데요.

예를 들면, 이미 열려 있는 문서들의 탭을 통해 다른 소스로 이동한다거나...
VA(Visual Assist)의 'Open File in Solution' 기능을 이용한다거나 말이죠.

이후 다시 솔루션 탐색기를 보면 화면에 열린 파일이 선택되어 있어야 해피할텐데 그렇지 않은 경우가 있지요.

도구 - 옵션 - 프로젝트 및 솔루션 - 솔루션 탐색기에서 활성화된 항목 추적

...으로 선택할 수 있는 옵션인데요. 의외로 모르는 분들이 많더군요.
예전엔 디폴트 값으로 켜져 있었던 것 같은데, 최근 VS에서는 꺼져 있는 것 같네요.

#3
제가 느끼는 VS 각 에디션의 차이는 다음과 같습니다.

익스프레스 : VA 안 깔림. 매크로 안 됨. 썅.
프로페셔널 : 프로파일링 기능 빠졌음. 썅.
팀슈트 : 비싸서 회사에서 안 사줌. 썅.


#4
한 때 프로그래머라고 하면 모두 얼리어댑터 일꺼라고 생각했던 시절이 있습니다.
물론, 컴퓨터나 프로그래밍적인 측면에서 말이죠.

예를 들면, 윈도우 새 버전이 나오면 일단 깔아본다던지...
좋은 라이브러리가 있다더라...라고 소문이 들리면 갖다써본다던지...
근데 현실은 시궁창이더군요.

전 운이 좋았는지 항상 제맘대로 외부 라이브러리를 사용할 수 있었는데요.
stl 조차도 꺼리는 플머들이 세상엔 많더군요. 바퀴를 다시 발명할 필요는 없을텐데요.

자신이 쓰기 싫으니깐 오히려 악성 루머를 퍼뜨리는 자들도 있는데요.
'루프 돌면서 vector에 들어있는 녀석을 erase하니깐 좆ㅋ망ㅋ. 이거 못 쓰겠군?'
이 말은 '1 + 2 * 3 = 9'라고 말하는 것과 같다고 생각합니다.

인간은 모르는 것에 공포를 가진다고 하지요?
십분 이해하고 그걸로 더욱 조심할 수 있다면 긍정적이겠지만...
플머라는 자들이 모른다고 기피를 해서는 안 되는 종족이잖아요?

#Epilogue
쓰고보니 완전 두서없는 포스팅이네요.
단지 허본좌님 사진을 더이상 보기 싫었을 뿐이니 필요한 부분은 골라 읽어주세요. ㅎㅎ

이올린에 북마크하기(0) 이올린에 추천하기(0)
2009/10/01 11:36 2009/10/01 11:36
예전에 이런 글을 쓴 기억이 납니다.
사람들의 생각은 다 비슷비슷한가 봅니다. 네가 방금 떠올린 아이디어는 이미 다른 몇 명도 생각했었고, 그 중 몇 명은 이미 만들고 있다는 이야기도 있지요.

최근 한게임에서 아이두게임이라는 서비스를 준비하고 있습니다. ㅜㅗㅜ에서 일하시는 선배의 소개로 미리 접하게 되었는데, 이제는 공개되서 여기저기서 언급되고 있네요.
항간에는 애플의 앱스토어를 따라 만든거 아니냐는 야그도 있고 하지만, 그건 그거고 이건 이거라고 생각합니다. 실제로 써보면 단순히 따라했다 수준으로 치부할만한 물건도 아니고요.

사용자 삽입 이미지

사실 이런 시스템은 결국 플랫폼을 제작한 곳과 일부 선구자들만 배부르게 되어 있는 구조라고 생각합니다만, 그럼에도 불구하고 GameOVEN의 아름다움에 혹해서 요즘 뭔가 만들어보고 있습니다. (별로 돈을 만져보겠다는 생각은 하고 있지 않습니다.)

GameOVEN을 좀 써보니 이건 쓰면 쓸수록 놀랍습니다.
일단 루아 디버깅 환경이 탁월합니다. break point, step trace, watch window, call stack 기능만으로도 제작진에 존경을 표하고 싶네요. 또한, 제공되는 라이브러리들이 훌륭합니다. 네트워크의 경우, 프로토콜만 정의하면 MFC 컨트롤들의 이벤트 만들듯이 손쉽게 서버/클라이언트 통신을 구현할 수 있게끔 되어 있습니다. 이미지 라이브러리는 2D 스프라이트들을 편하게 조작할 수 있게 해줍니다. 각종 컨트롤들을 이벤트 드리븐 형태로 제어할 수 있다는 점도 적절하네요. Luabind를 지원함으로써 클래스 정의가 가능하다는 점도 훌륭합니다.

그런데 생각해보면 이런 내용의 대부분은 C# 따위를 이용했다면 간단히 해결됬을 수도 있지 않았을까 싶습니다. 물론 플랫폼을 C++로 짜면서 바인딩하는데 좀 어려움이 있었겠지만, 이런 툴을 만들 정도의 노력이면 충분히 가능했을 것 같고요. 뭐, 나름대로 어른들의 사정이 있었겠지요. :)

여하튼 만들고 있는 녀석은 이렇습니다.

사용자 삽입 이미지

이제 막 시작한거라 스샷은 의미가 없네요(...)
판에 깔린 카드들을 기억한 후 4명이 번갈아 가면서 카드를 5장씩 집어가 포커룰에 따라 승부를 겨루는 게임이지요. 제 조루근성에 완성이 될지는 모르겠습니다만, GameOVEN을 접해본다는데 의의를 두도록 하지요.

막상 만들다보니 자잘한 불편함이 눈에 띄네요.
가장 절실한 건 우선 VS의 F12 키에 할당되어 있는 find the definition of a function(맞나?) 기능. 함수 수정할라고 온갖 소스를 다 뒤지고 있자면 짜증이 이만저만이 아니네요. 두번째로 열린 문서 간을 오가는 Ctrl + tab 키 기능. 이건 지금 단순히 로테이션만 되고 있어서, 최근 열린 파일 2개를 주로 오가면서 작업하는 제게는 고통입니다. 그밖에도 인텔리센스의 부재, 애매모호한 Project Explorer의 파일 정렬 방식, Scene1 창은 왜 닫을 수 없는가? 등 열거하자면 끝이 없겠지만, 일단은 앞의 2가지가 제 작업 속도의 반은 까먹는 기분이네요.

어찌됬든 향후의 발전을 기대해봅니다.
저는 다시 작업하러 ㄱㄱ.
이올린에 북마크하기(0) 이올린에 추천하기(0)
2009/06/28 18:02 2009/06/28 18:02
사용자 삽입 이미지

망했다. 이제 그만 자야할텐데(...)

김우스(여친)의 추천으로 심즈3 시작.
간만에 접한 심즈 시리즈라서 일단 장로딘을 생성. 이것저것 해본다.

평소의 내 모습을 떠올리며 완벽주의자, 천재, 빈대, 잠꾸러기, 컴퓨터 귀재의 특성을 가지고 창창한 청년으로 시작하였으나... 자신의 꿈(법의학 전문가)을 이루기 위한 고단한 삶 속에서 어느덧 장년이 되어 직장(경찰서)에서 만난 블레어라는 여성과 결혼. 야!!

그제서야 본래의 목적을 떠올리고 급히 김우스를 생성. 앞집으로 이사시켜 플레이를 시작.
대충 직장만 구한 후 앞집남 로딘을 꼬셔본다. 허나 이노므 남자는 뭐가 그리 직장 일이 바쁜지 보이지 않고 아내인 블레어와만 친분을 쌓을 뿐!

나중에 알고보니 출퇴근 시간이 묘하게 어긋나서...
로딘이 퇴근하면 우스가 출근하고, 우스가 퇴근하면 한밤중. 자고 일어나면 로딘 출근...

쉬는 날마저 애매하게 어긋나 있었지만 일주일에 하루! 그와 그녀는 만날 수 있었다.
김우스는 평생의 꿈인 요리도 제쳐두고 그에게 구애. 그러나 그는 가정이 있는 남자. 집으로 놀러 오긴 하였으나 끝끝내 과도한 스킨십을 거부하였다.

그러기를 10여일...(인가?)
'우리 같이 살아효~' 라는 끝없는 신호 끝에 그들이 동거를 시작한 것은 장로딘이 노년이 되어 가기 며칠 전. 급히 저멀리 해변을 빌려 결혼 파티를 열었으나 뭔가 시간을 잘못 택했는지 김우스는 파티에 음식만 차려놓은 후 직장에 출근해버렸다(...)
신부 없는 결혼식은 앙꼬 없는 단팥빵, 붕어 없는 붕어빵... 이건 아닌가? 여튼 그렇게 망쳐버렸고, 이틀 후 그들은 조용히 둘만의 결혼식을 올린다. (블레어 미안)

알콩달콩한 신혼 생활은 시작한 김우스와, 이젠 김씨가 된 로딘.
허나 김로딘의 노년이 멀지 않았다! 빠르게 애새퀴를 갖자! 바야흐로 김우스는 평생 행복 보상으로 '뛰어난 출산 능력'까지 하사받고 단박에 임신. 며칠 후, 어여쁜 여자 아이를 기대하며 - 이미 연아라는 이름도 생각해두고 - 병원으로 향한 그들에게 의사가 들려주는 청천벽력과도 같은 소식.

'축하합니다~ 남자 아이가 탄생하였습니다~'
.
.
'남자 아이가 탄생하였습니다!'

무심한 하늘은 그렇게 그들에게 남자 아이를 주셨고, 그 녀석의 이름은 봉남이가 되었다.

어느덧 김봉남은 청소년이 되었고, 이미 로딘은 노년이 되었지만 김우스는 아직 팔팔한(?) 장년. 그들은 딸을 포기할 수 없었다. 그래서 강행한 2차 시도!

둘째, 말남 탄생.
셋째, 종남 탄생.
넷째, 또남 탄생.

오~ 하느님 제발. 어찌 우리에게 이런 시련을 주십니까!!!

무분별한 출산으로 양육이 불가능해진 그들은 급기야 로딘의 전처인 블레어에게 아이들을 맡기게 되었으나, 그나마도 얼마 안 가 블레어가 늙어 죽어버려서 애매하게 고아가 되어 버린 말남, 종남, 또남이는 입양 센터에서 줏어가게 된다.

이제 더이상 애새퀴를 만들 힘도 없는 로딘 할아버지와 우스 할머니,
성실히 키워주지 않아 도벽이 생겨버린 아들래미 봉남이와의 앞날은 어찌될 것인가...


...이 글은 어디까지나 게임 상의 이야기입니다. 너무 심취하지 맙시다.
...이 글의 원본은 알만한 사람은 다 아는 곳에 있습니다. 트랙백 타고 오신 분들도 계시죠?

이올린에 북마크하기(0) 이올린에 추천하기(0)
2009/06/23 03:52 2009/06/23 03:52
TAG

0. 1인 플레이

네트워크 플레이가 되는 레이싱 게임을 만들어봅시다. 뭐부터 해야하죠?
일단은 1인 플레이가 되야 겠지요. 코스 위에 캐릭터가 올바르게 서 있고, 가속키를 누르면 가속하고, 브레이크 키를 누르면 감속하고, 커브도 좀 틀 줄 알고...
뭐 이런거야 왠만한 게임들과 다를 바가 없죠.

1. 기본적인 네트워크 플레이

자, 이제 2인 이상의 네트워크 플레이가 되도록 해봅시다.
서로 간의 통신이 되야겠군요. 유명한 프로토콜로 TCP와 UDP가 있네요.
어떤 걸 사용해야 하죠? 뭐, 서로의 차이점은 구글님께 물어보면 금방 나오니깐 자세히 설명은 하지 않겠습니다. 여튼 보아하니 UDP는 TCP보다 일반적으로 빠릅니다. 해야할 일을 좀 적게 하니깐요. 하지만 그렇기 때문에 확신이 없습니다. 이걸 어떻게 활용할까요?

저라면 아래와 같이 설계하겠습니다.

사용자 삽입 이미지
일단 각 클라이언트는 특정 클라이언트에게 자신의 조작 정보를 UDP로 보냅니다.
'나 가속키 누르고 있어!'
'나 지금은 브레이크키 안 누르고 있어!'

그 특정 클라이언트는 이렇게 수집된 정보를 이용해서 각 클라이언트의 상태를 계산합니다. 이런 역할을 하는 녀석을 슈퍼 피어(super peer) 혹은 로컬 서버(local server) 등의 이름으로 보통 칭하더군요. 여기서는 이후 '슈퍼 피어'라고 칭하겠습니다.
슈퍼 피어는 상태값을 계산해서 다시 각 클라이언트들에게 브로드캐스팅해줍니다. 역시나 UDP를 사용하고요.
'지금 A 플레이어는 요기쯤 있어연.'
'B 플레이어는 점프중이네연.'

이러한 정보는 중간에 1~2개쯤 잃어버려도 괜찮답니다. 어차피 순식간에 다음 패킷이 와서 최신 상태를 갱신해주니깐요. 그렇기 때문에 빠르게 많이 보낼 수 있는게 좋습니다. 조금이라도 최신 정보인 편이 좋으니깐요. (이 부분이 본 포스팅의 주제인 동시에, 뒤에서 좀 더 자세히 설명하게 됩니다.) 그래서 UDP를 사용합니다.
순서가 바뀌는 것도 사실은 곤란하기 때문에 각 패킷에는 시간 정보를 첨부합니다.

하지만 '아이템을 먹었다! 사용했다!' 이런 류의 정보라면 UDP로 보내기엔 좀 곤란합니다.
내가 부스터 아이템을 먹어서 사용했는데 아무런 반응이 없어봐요. 얼마나 억울하겠어요? 그래서 이 경우엔 신뢰할 수 있는 TCP 프로토콜을 이용해서 서버에게 정보를 알립니다. 그럼 서버는 이 녀석이 정말 아이템을 가지고 있나? 등의 검증을 거친 후 모두에게 알려주게 되지요.

2. 상태 동기화

여기까지 제작이 되었다면 어디 한 번 플레이 해보도록 합시다.
얼랄라~ 옆에 가는 놈들 움직임이 튀어요!! 당연한 이야기지요. 슈퍼 피어가 UDP로 최신 상태를 계속 보내준다고는 해도 얼마나 자주 보내주겠습니까? 상태 정보의 구조체를 아무리 간소히 한다고 해도 아래 정도는 되지 않을까요?
이미 40바이트인데요. 8명이 함께 하고 있다면 320바이트네요. 초당 10번쯤 보낸다고 해도 결국 10프레임짜리 움직임이 되니깐 자연스러워 보일리가 없지요. 그럼 어쩌지요?

자, 제 목표는 30프레임이라고 해봅시다. 그 정도면 적당히 자연스러운 움직임으로 보일 것 같습니다. 그렇다면 초당 30번, 정보를 받아 그리는 방법이 가장 아름답겠습니다만, 네트워크 사정이 허락을 해줄 것 같지 않습니다. 어쩔 수 없이 초당 10번만 보내기로 하고... 정보를 받는 사이에 2프레임씩만 더 그려주면 30프레임이 되지 않나요?
사용자 삽입 이미지
대략 이런 느낌입니다. ??로 표기된 부분에서 적당히 그려준다면 될 것 같네요.

이를 위해 각 클라이언트는 외삽을 합니다. 즉, 1번 프레임의 데이터를 받으면 그걸 이용해서 슈퍼 피어와 같은 방식으로 계산해서 2번 프레임의 데이터를 얻습니다. 2번 프레임의 데이터를 받기 전에 미리 미래의 데이터를 구해두는 거지요. (각 클라이언트는 당연히 슈퍼 피어가 될 수 있으므로 그 계산 루틴을 가지고 있습니다.)

그리고 1번 프레임을 그렸던 시간과 2번 프레임을 그리게 될 시간, 그리고 현재의 시간을 이용해서 현재 프레임의 데이터를 얻습니다. 간단한 선형 보간이지요.
참~ 쉽죠잉~~~!
물론, 이 와중에 2번 프레임의 데이터가 오면 다시 덮어주고 다음 프레임을 외삽하고 사이 데이터들을 보간해서 구합니다. 이 때 2번 프레임 값으로 바로 그려버리면 외삽으로 구한 추측값과 달라서 위치나 모션이 살짝 튈 수도 있습니다. (혹은 2번 프레임 데이터는 잃어버리고 3번 프레임 데이터가 올 수도 있습니다.) 그런 경우라면 그 데이터를 그리는 데에 바로 사용하지 않고 외삽/보간 값을 구하는데만 활용해도 좋습니다.

이런 방식을 데드 레커닝(Dead Reckoning)이라고 하더군요.
실제로 구현을 해보면 외삽을 위해 위에서 언급한 데이터에 추가로 데이터가 더 필요하게 될 겁니다. 그렇다보면 UDP로 주고 받을 데이터량이 너무 많아지는 건 아닌가 싶지만 그 경우엔 변경된 데이터만 보내주는 방식으로 좀 줄일 수가 있습니다. 물론 변경된 데이터의 종류를 표현하기 위한 비트 플래그 따위가 있어야 겠고요.
선형 보간으로 자연스러운 움직임이 나오지 않을 정도로 네트워크 사정이 안 좋다면, 클라이언트의 CPU 타임을 좀 더 사용하는 방법도 있습니다. 슈퍼 피어가 과거의 프레임 3개를 보내거나, 2개를 보내고 클라이언트가 미래의 프레임 2개를 외삽해서 베지어 곡선을 그리듯이 보간을 하는 거죠. (...라곤해도 전 이렇게 구현해본 적이 없어서 어떨지 모르겠습니다.)

3. 그 밖의 이슈

이것만으로도 가지고 놀만 하지만 서비스하기에는 완전치 못합니다. 특히 우리 나라와 같은 공유기 환경에서는 UDP 홀펀칭이 반드시 필요합니다. 그리고 보안 이슈도 있습니다. 누군가 독한 맘 먹고 클라이언트를 해킹해서 슈퍼 피어를 조작하면 게임 전체가 조작되어 버릴 수 있습니다. (간간히 주요 정보를 서버에 TCP로 보내서 검증하는 보완책이 있겠지요.)
또 슈퍼 피어의 연결이 끊어졌을 때도 문제가 발생합니다. 빠르게 그 역할을 대신해줄 클라이언트를 정해줘야 겠지요. 뭐, 일반적인 P2P 게임에서는 방장이 나가면 걍 게임이 종료되어 버리는 식으로 구현한 경우도 많아서, 유저들도 이 경우는 인정해주는 눈치기는 합니다.

* 사설

생뚱맞게 왜 이런 포스팅이 갑자기 올라왔냐고 묻는다면 그냥 스트레스 해소라고 답변하겠습니다. 길게 적으면 구차해질뿐...

이올린에 북마크하기(0) 이올린에 추천하기(0)
2009/05/17 00:10 2009/05/17 00:10
* 오디션 잉글리쉬

http://ae.hanbiton.com/

요즘 만들고 있는 녀석입니다.
드리머스로 이직한지도 이제 거의 1년이 되어 가는데요.
혼자 쓸쓸히 만든 서버가 드뎌 유저들의 손길을 타게 되네요.

말이 클베지 신청하면 다 할 수 있으니 한번씩들 해봅시다요. :)


* 기타 근황

자, 2학기도 끝났습니다. (지난 포스팅이 2학기 시작할 때 쓴건데...)

이번 2학기는 유난히도 힘들었는데요.
오프라인 과목이 3과목으로 늘어난게 타격이 컸던 것 같습니다.
사이버 강의 2과목도 유달리 귀찮은 녀석들이었고...

담 학기는 좀 널널했음 좋겠습니다. ;ㅅ;
(아아... 캡스톤 언제 하지?)

아빠소는 만렙이 코 앞입니다.
이올린에 북마크하기(0) 이올린에 추천하기(0)
2008/12/22 14:06 2008/12/22 14:06

지난 목요일 강의를 끝으로 '알고리즘 설계와 분석' 과목이 종강되었습니다.
간만에 돌아온 학교, 이번 학기 최초의 종강이네요.

이 과목에서는 분할 정복법, 동적 프로그래밍, 탐욕적 기법, 되추적, 분기한정법 순으로 알고리즘 풀이 기법을 배웠는데요. 평소에 관심이 많던 분야였던지라 흥미진진 하였습니다.
물론, 베스트 티쳐상을 수상하셨었다는 손교수님의 강의도 좋았구요. 짝짝짝.

학기 중에는 2~3주에 한번씩 과제가 나왔는데요.
ACM 문제를 풀어 MFC로 래핑한 프로그램을 제출하는 식이었습니다.
(제 기억 속의) 2학년 때에 비해 갑자기 난이도가 상승한 기분이라 같이 수업받는 후배들이 불쌍했지만 당황스러웠지만 이건 이것대로 재밌었습니다.

총 5번의 과제가 나왔었는데 그중에서도 가장 어려웠던 Ouroboros Number의 주요 코드를 여기 공개해봅니다.
일종의 되추적 기법을 이용했는데요. 첨엔 자료구조를 잘못 잡아서 캐삽질하고... 전체적으로 4~5시간쯤 걸린 것 같습니다. 쩝.



문제는 요녀석입니다. ^-^
http://acm.uva.es/p/v100/10040.html

이올린에 북마크하기(0) 이올린에 추천하기(0)
2008/06/06 18:16 2008/06/06 18:16

꽃들이 만발하는 4월입니다.
아제로스에는 와우로 폐인 생활을 하시던 캘타스횽이 옛 영광을 찾고자 돌아오셨지요.

한편, 해치지않아요 길드에는 새로운 바람이 불고 있습니다.
소위 노장이라 불리우는 자들은 휴지기에 들어갔고, 새로 수급된 피들이 활발하게 활동하고 있네요. 길원만으로 카라잔을 완주하는 꿈은 아직 버리지 않았답니다.

여튼 오늘은 집에 돌아오는 길에 문득 든 생각이 있어 키보드를 잡았습니다.
바로, 블리자드가...

'확장팩 패키지에 60렙 캐릭터를 끼워 팔면 어떨까?'

...라는 생각이지요.

지금 이 시간에도 수많은 유저들은 와우를 즐기고 있습니다.
그리고 이 유저들은 자신의 지인들과 함께 플레이하기를 열망하고 있습니다.
헌데 이 뉴비들은 지인들과 함께 놀 수 있는 만렙까지의 과정이 너무 부담스럽습니다.
그래서 지금도 수많은 뉴비들이 아제로스로의 여행을 망설이고 있지요.

물론 요근래 1렙부터 60렙 58렙까지의 아제로스 생활은 매우 윤택해졌습니다.
블리자드로서는 기껏 만들어둔 컨텐츠가 아깝기도 하겠지요.
하지만 지금은 아웃랜드 생활만으로도 몇 달을 보낼 수 있는 볼륨을 가지고 있습니다.
아서스횽도 곧 오실테고요. ㅎㄷㄷ

이왕 이렇게된거 말그대로 아웃랜드 생활만 즐겨도 되지 않을까요?
이쁘게 확장팩 DVD 패키지를 꾸며서 원하는 종족, 클래스의 60렙 캐릭터를 만들 수 있는 카드(?)를 판매하는 것이지요. 가격은 석달치 정액 수준의 5만원 정도면 적절할 듯 하네요. (이게 아깝다고 느껴질 정도의 사람이라면 걍 1렙부터 키워도 상관없는 노릇!)
(뭐, 사실 마비노기처럼 대놓고 온라인으로 캐릭터를 팔아도 상관없긴 하지만, 이건 좀 없어보이니깐...)

자, 블리자드 횽들 이걸로 돈 좀 만져볼 수 있지 않을까요?
(아님 말고...)
자자, 빨리 돈 벌어서 리치킹을 내놔!!!!!!!


< 별책 부록 > - 로딘의 근황

* 의외로 모르는 분들이 많던데... 로딘군은 작년 말일을 끝으로 가마소프트를 떠났답니다. 6년 동안 정든 고향같은 곳이었지만, 저에게는 또 저 나름대로의 길이 있으니깐요.
* 그리고 복학을 했습니다. 학부 3학년생이지요. 두둥! (...라곤해도 대부분 사이버 강좌입니다.)
* 학교와 병행 가능한 조건으로 새로운 직장도 구했습니다. 드리머스 에듀테인먼트라는 생긴지 1년 남짓한... 멋진 분들이 많이 계신 곳이랍니다. :)
* 저녁에는 탁구를 배우고 있습니다. 고딩 때 이후 처음인데 조금씩 실력이 느는게 눈에 보여 즐겁네요.

- 지금은, 고등학교 졸업 이후 가장 바쁜 나날들 @로딘
이올린에 북마크하기(0) 이올린에 추천하기(0)
2008/04/12 00:27 2008/04/12 00:27

0. 잡소리
제목을 포스트모템이라고 해놓고 보니 뭔가 거창해보이네요(...) 실은 저 단어가 생각이 안 나서 영어 사전까지 뒤져봤어요. ('부검'이라는 의미는 어러케 알고 있던거지?!)
일단은 제가 지난 2년간 몸담았던 프로젝트를 주제로 삼습니다만, 게임의 내용에 대해서 보다는 프로젝트 매니징에 대해 다뤄보려고 해요. 그게 제 역할이기도 했고요.

1. 기록 - History
때는 2005년 8월초, 프로젝트를 함께 시작한 멤버들은 모두 릴(http://rylonline.com/) 개발부터 라이브까지 산전수전 다 겪은 친구들이었고, 무엇보다 '기록을 남기는게 중요하다!'라는 공통된 주장을 하고 있었지요. '어떻게 하는게 좋을까?'
그 와중에 발견한 웹 프로그램이 있었으니... Trac!!! (http://trac.edgewall.org/)
위키 + 버그트래킹 시스템에 svn과도 연동이 되다니... 이런 킹왕짱 프로그램을 봤나!

하지만 이 녀석을 사용하기까지는 약간의 진통이 있었어요. 우선은 처음 써보는 시스템이다보니 팀원들이 적응하는데까지 시간이 제법 걸렸고, 특히 그림 그리는 아찌들이 위키로 뭔가 작성하는 걸 엄청 부담스러워 한다는거...

그래서 이쁜 오구라 유코도 친근감있는 로고도 달아보고, 위키 페이지에 간단히 코멘트를 달 수 있게끔 매크로(애드온)도 만들어 보았습니다.

사용자 삽입 이미지
또 티켓 페이지가 한 눈에 들어오지 않는다는 의견에 레이아웃도 손보고, 이미지도 올리기 쉽게끔 매크로를 제작해보았지요.

사용자 삽입 이미지
손수 한글 번역도 했었는데, 나중에는 저보다 더 잘 해주신 분(http://kldp.net/projects/trac-ko/)이 계셔서 감사히 사용했습니다(...) 이런 정성이 있었기에, 지금은 신입 팀원도 편하고 빠르게 우리 시스템에 녹아들 수 있게 된게 아닌가 생각해 봅니다.

제가 화이트 보드를 관리 시스템에 채용하지 않는 가장 큰 이유는 히스토리의 중요성을 여러번 뼈저리게 느꼈기 때문입니다. '나중에 문서로 옮기면 되지 않느냐?'라는 반론에 전 '중간에 누군가 어떤 내용을 지운 행동마저도 중요하다.'라고 답변해주고 싶습니다. 그리고 추후에 누구라도 손쉽게 이 기록에서 원하는 내용을 찾아낼 수 있게끔 해주는 것이 더욱 중요하겠고요.

2. PM의 역할?
프로젝트 초창기부터 지금까지 저는 꾸준히 삼권분립(...)을 주창해 왔습니다. 각각 프로듀서(Producer), 프로젝트 매니져(Project Manager), 디렉터(Director)라는 직책이 되겠는데요. 그 역할은 아래와 같습니다.
  • 프로듀서 : 얼굴 마담입니다. 팀 외부 세력(?)과의 포트 역할이 됩니다. XP에서 언급되는 '고객'이기고 하고, SCRUM에서의 '닭'과도 흡사하네요.
  • 프로젝트 매니져 : 프로젝트 진행이 막힘없이 되도록 윤활유 역할이 되어줍니다. 스케줄을 총책임집니다. SCRUM에서의 Scrum master와 비슷한 역할인 듯 합니다.
  • 디렉터 : 컨텐츠의 퀄리티를 책임지고, 각 모듈 간의 우선 순위를 결정합니다. 즉, SCRUM에서의 Product owner 역할을 일부 수행합니다.

다른 분들이 사용하는 의미와는 좀 다를 수도 있겠습니다만, 마땅한 용어가 없으니 저는 이렇게 정의내려 봤습니다. 디렉터를 좀 세분화해서 아트 디렉터(그래픽 아티스트)와 테크니컬 리더(프로그래머)가 추가되서 오권분립(...)도 그럴싸.

전 PM으로서 무엇보다 팀원들이 작업을 하는데 불편함이 없도록 하는데 최우선 가치를 두었습니다. 업무적으로는 앞서 밝힌 바와 같은 시스템외에도 일일 빌드 및 테스트, 백업 자동화 시스템을 구축(python, 쉘 스크립트 이용)하였고, 이를 Trac에서 매일 확인할 수 있게끔 하였습니다. 그리고 맥스 스크립트를 잘 다루는 '테크니컬 아티스트'의 충원을 매우 원했는데, 오늘 이시간까지도 성취하지는 못했습니다...llorz

업무 배정에 있어서도 모듈의 우선 순위 내에서 각 개인이 원하는 일을 할 수 있게끔 배려하였습니다. (사기충전에 도움이 되고, 보다 정확한 일정이 나옵니다.) 그리고 이건 작은 팀이었기에 가능한 일이었을 수도 있지만, 각 분야의 팀장을 따로 두지 않고 모든 팀원의 스케줄을 직접 관리하였고, 공유할 수 있도록 노력하였습니다. 무엇보다 팀원 각자가, 옆 사람이 지금 뭘 하고 있는가를 손쉽게 파악할 수 있게 하는 것이 중요했다고 생각합니다.
Trac의 티켓 시스템을 버그 트래킹만이 아닌 작업일지의 용도로도 사용하였는데, 각자 매일 업데이트하고 다른 이들이 이를 손쉽게 볼 수 있음으로서 서로간의 삽집도 방지할 수 있었고요. (불필요한 작업을 하고 있을 때 빠르게 캐치할 수 있지요.) 요즘 괜히 애자일 방법론에서 의사소통의 중요함을 강조하고 있는게 아니지요.

또한, 주간/월간으로 각 팀원간의 진척 사항과 이후의 할 일을 기록으로 남겨 공유하였습니다. 매주 금요일에 검토 시간을 가졌는데, 이 때는 제가 초안을 작성 후 각 팀원들의 자리를 돌면서 개인 면담을 가지면서 수정해나가는 형태였습니다. 그렇게 정리된 안에 디렉터와 프로듀서의 의견을 받아 다음 작업들의 우선 순위가 재정리되고 분배되었지요. 월간 검토 회의는 모두 모여서 이야기하는 형태였습니다. 하고보니 일종의 '스프린트 검토 회의'였는데, 지금 생각해보면 주간 검토 시간에도 짧게라도 모두 모여서 이야기하는 형태가 되었다면 압박을 주는 면에서(...) 괜찮지 않았을까 생각됩니다. 제가 좀 만만해서 아무래도 느슨해지는 감이 있더군요.

3. 그래서...
그래서 이 프로젝트는 어떻게 되어가고 있을까요? 아직은 뭐라고 평할 수 없는 ing 상태입니다만, 프로젝트만 놓고 봐서는 팀원들 모두 즐겁게 일하고 고객 만족도를 높이면서 조금은 느리게(...) 진행중입니다. 뭐 여튼, 거창하게 포스트모템을 작성하기에는 이른 시기이지요.
하지만 요즘 화두가 되고 있는 SCRUM이라는 녀석과 제가 진행해온 방식에 일맥상통하는 부분이 많다고 느껴져 사례 보고의 일종으로 글을 작성해보고 싶었습니다. 또 이를 바탕으로 다시금 돌아볼 수 있는 계기도 되고요.

* 좀 다른 이야기
지난주 kgc2007에 참석해서 애자일에 대한 이런저런 이야기를 들으면서 느낀바가 많았습니다. 남기룡님(http://mypage.sarang.net/tt/)이 보여주신 화이트보드의 일정판을 보니, 그걸 웹프로그램으로 옮긴 형태가 떠올랐고요. (Trac도 로드맵과 리포트 기능을 잘 커스터마이징하면 될 듯 하지만, 아무래도 한 눈에 들어오지는 않지요. 요건 나중에 따로 기획안을 포스팅해보고 싶네요.) 김창준님(http://agile.egloos.com/)이 언급하신 'Hourly Scrum'도 신선했고요. 긴장감 유지에 좋을 듯 하네요. (우리 팀은 아무래도 이게 좀 부족...) 박일님(http://parkpd.egloos.com/)의 TDD 강의도 즐거웠습니다. 글로만 봤을때는 두리뭉실했던 mock 객체, 저희 팀에 정말 필요한 것이었고 확실히 입력되었습니다.

이올린에 북마크하기(0) 이올린에 추천하기(0)
2007/11/12 16:30 2007/11/12 16:30
Last Update : 2007. 11. 07.

사용자 삽입 이미지
사용자 삽입 이미지

요즘 그냥 왠지 C# 공부가 하고 싶어져서 책을 한 권 봤어요.
http://kangcom.com/common/bookinfo/book ··· 03270008
주말동안 와우하면서 와이번 타는 시간, 전문 기술 제작 시간...
짬짬히 읽었더니 이제 뭐든지 만들 수 있을 듯한 기분이에요.

그래서 뭘 해볼까 고민하다가 미소녀(MSN), 네이뇬(NateOn) 클론 통합 메신저따위를 생각해봤어요.
요즘 네이뇬 쓰는 자들이 많던데 전 메신저를 2개나 띄우고 싶지는 않거든요.
프로젝트명은 '미소녀네이뇬'정도가 좋겠군요.

실은 이미 개발 시작한지 일주일도 넘었는데...
문득 예전에 이즈횽이 했던 것처럼 개발일지를 남기면 좋을 것 같다는 생각이 들어서 이렇게 포스팅을 하게 됬어요.

그런고로 개발 일지 고고싱.


생각해보니 제 블로그는 http://allgd.net/ 에 등록이 되어 있었네요.
...해서 자꾸 제목을 고치거나 수정일을 갱신하면 민폐가 될 듯 해요.
그런고로 제목과 갱신일을 수정하는 건 오늘이 마지막!
마지막 갱신일은 본문 꼭대기에 표시하겠으니 참고하시와요.

이올린에 북마크하기(0) 이올린에 추천하기(0)
2007/11/07 18:50 2007/11/07 18:50
TAG , ,
오늘도 아빠소는 아제로스... 아니 이젠 아웃랜드 생활을 하고 있습니다.
아빠소는 그동안 남들이 이래라 저래라 하는거 듣기 싫어서 심하게 낯을 가려서 길팟으로만 인던을 다녔는데, 요즘은 생각을 고쳐먹고 막공 같은 곳에도 끼어 다니고 있습니다.

헌데 요즘 파티찾기 채널을 보면 말입니다...

[5. 파티찾기][이천오백비터]: 카라잔골팟가실..신기..복술님들뫼십니다..언넝들오세여..
[5. 파티찾기][둠블링가]: 수렁막넴 힐러님 모십니다 4/5 작업완
[5. 파티찾기][카미루]: 증기(일반)가실 힐러분 모셔오 오시면 바로 ㄱㄱ

(예문의 등장인물은 가상의 인물입니다만, 내용은 사실입니다.)


...전신에 힐러만 찾네?

예~~~~~~전에, 불타는 성전이 나오기 전부터도 사제님은 귀족. 도닥은 천민.
그렇담 다들 힐러하기를 싫어해서 이렇게도 힐러 구하기가 힘든걸까요?

항간에는 사람들이 힐러를 하기 싫어한다고들 합니다.
(http://fieldkim.egloos.com/3406551)
그런 의미에서 힐러를 없애는게 좋지 않겠냐...는 의견도 있네요.
(http://www.thisisgame.com/board/view.ph ··· Borderby)

하지만 제가 보기엔 힐러 역시, 딜러만큼은 아니더라도 최소한 탱커만큼 나름의 수요가 있어 보입니다. 당장 우리 '해치지않아요' 길드 내에도, 죽어가는 파티원의 체력을 회복시키면서 쾌감을 느끼는 고모뼈같은 자가 있고, 힐러는 다른 이의 죽음을 주관한다고 표현하셨던 진산마님 같은 분도 계시죠.

그런데 딜러보다 탱커나 힐러가 적은 이유는, 일단 어렵기 때문이고, 또한 실수를 했을 때 받게 되는 부정적인 피드백이 강하기 - 바로 티가 나는 - 때문입니다.
거기에 덧붙여 힐러가 이렇게나 적은 이유는 너무너무너무 어렵기 때문입니다(...)

당장 와우에 사제를 하나 생성했다고 칩시다.
어찌어찌 힐 스킬을 익히며 10렙이 되었습니다. 힐하려고 키웠으니 신성 특성 ㄱㄱ. (암흑 특성 타고 딜할꺼면 차라리 절대무적흥마를 하지)
15렙쯤 되니... 몹이 죽을 생각을 안해! 어쩌다 애드되니깐 어어? 무덤에서 언니와 면담하기를 수십회. 저기 옆의 도닥은 푹푹찍찍 잘도 렙업하는데 나는 웨 요모양?

...나 안해!


네, 제가 생각하는 문제는 힐러를 플레이함에 있어 힐의 재미를 느끼기도 전에 솔플 단계에서 어떤 벽에 부딪친다라는데 있다는거죠. 마찬가지로 어찌어찌 만렙이 되었다하더라도, 하고 싶은 일을 같이 할 파티원을 구하지 못 한다면 아무것도 할 수 없게 됩니다. (고모뼈는 경매 차익을 이용한 장사라도 하지...)

꾸준히 파티플을 하면서 힐의 재미, 그리고 플레이 방식을 익혀왔다면 꾸준히 즐겁게 할 가능성이 큽니다. (물론, 최초의 취향 차이는 있겠지만요.) 하지만 세상만사 원하는데로만 될리는 없지요. 지인이 없으면 부캐질이나 하고 있어야 하는 현실. 그렇게 딜러의 길을 걷게 되겠지요.

뭐, 이와 관련해서 세원옹과 의견을 나눌 기회가 있었는데요. 이 와중에 나온 해결책은 힐러가 솔플을 할 때도 파티원과 함께 할 수 있도록 하자(응?)라는 것이었습니다.
바로 AI 파티원(소환수가 됬든, 펫이든 용병이든)을 제공해 주는거지요. 이 스킬(혹은 기능)은 솔플에서만 가능하게 하거나 파티원이 적을수록 많은 AI 파티원을 이용할 수 있게 한다거나 하는 제약을 둡니다. 이로써 힐러는 자기의 본분을 충실히 이행하면서 플레이 방식을 익히고, 보람도 찾고 재미도 있고... 뭐, 그렇게 되지 않을까요?

뭐, 자세한 건 아래의 대화 원문을 살펴봅시다. :)

여기는 세원옹과의 대화 원본. 기니깐 접어두자.


...어떤가요? 이런 힐러, 해보고 싶지 않나요?
이올린에 북마크하기(0) 이올린에 추천하기(0)
2007/10/01 18:51 2007/10/01 18:51
TAG , ,