꿈꾸는자의 생각의 파편들... :: 'Game Dev...' 카테고리의 글 목록 (2 Page)

달력

10

« 2018/10 »

  •  
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  •  
  •  
  •  

예전.. 만들던 미드가르드의 원화중에.. 일러스트 몇개가 있더군요..

다른곳에 오픈하심 안되구요... ㅎ.ㅎ; 나름대로 저작권이 있는 거라서..

여기 까페분들에게 살짝 오픈합니당..

(뭐~~ 중단된 프로젝트라서 크게 문제될것은 없겠네요~~ ㅎ.ㅎ )

 

요건.. 여자 글라디에이터라는 2차 전직 클래스의 원화였습니다.

일종의 검투사?? ㅋㅋ 모티브는 짐작하셨듯이.. 영화에서 따왔구요..

힘을 중시하는 전사 클래스의 모습입니다...

 

요기서 3차전직하면.. 베르세르카라는 광폭전사로..

피와 체력을 희생하여.. 광폭한 검사로 변하는 모습의 원화도 작업하던 것이 있었는데...

Posted by 꿈꾸는자의 생각의파편들

# WOW(월드 오브 워크래프트)  레벨디자인 엿보기

 

                                                                                       작성일 : 2004-01-13


 
WOW에도 성이 있었군
공성전을 할 수 있을려나?


성의 입구가 왠지 유적의 입구 같군
이거 무늬만 성 아냐?


고대의 성인가? 아니면 유적인가?
헤깔리네 정말~

 
뭐야 이건?
성스러운 돌(신석)?


성 내부에 흐르는 녹색 강에 빠지니 이런 지하 통로가...
그러나 안에 감옥은 없었다.


성을 나와 다시 모험을 떠난다.
맵이 넓어 이동 자체가 너무 노가다라는 생각이 든다.


오옷, 크리스마스 트리야?
하지만 트리에 장식은 달려 있지 않았다. 


이런 외딴 곳에 집이?
멀리 흉측한 집이 보인다.
 

우욱! 역시 유령의 집이였나?
해골들이 나뒹굴고 있구 정말 무서워~


행군을 한참 하자... 풍차가 멀리 보인다.
오, 기대되는 걸~


으윽, 달랑 풍차만 있네
되게 실망했다.


계속 가자 멋진 시계탑이 있는 저택이 보인다.
처음 시작 할 때 스크린샷을 안 찍어두어서
여기가 처음 시작 지점인지 아닌지 모르겠다.


# WOW 알파테스트 버전 실행 소감

 

전체적인 분위기 : 전체적으로 싸늘하고 으스스하다.
캐릭터 스타일 : 워크래프트3 보다 한 단계 더 차가운 느낌을 준다.
맵 구성 : 광활한 필드가 아닌 다소 좁은 중세의 숲속을 표현한 것 같다.
인터페이스 : 좌, 우 이동이 Q, E이고 좌, 우 시점 이동이 A, D인데,
처음에는 다소 불편하다는 느낌을 받았으나 10분 정도 지나자 할 만 했다.
하지만 기존 게임과 많이 차이나는 인터페이스는 약간의 도박성을 띤다고 생각한다.
액션성 : 일타일득 식의 단순 타격 외에는 별 다른 액션감을 느낄 수 없을 것 같다.
따라서 마우스 클릭킹(Clicking) 노가다 게임이 될 공산이 높다고 볼 수 있다.

총평 : 국내 온라인 게임들의 맵디자인이 광활한 필드 위주가 많아 조금은
색다른 인상을 받았다. 전체적으로 팩키지 게임을 하는 것 같은 인상을 주지만
크게 새로운 게임성을 갖추지는 못한 것 같다.

Posted by 꿈꾸는자의 생각의파편들
다음은 제가 10여년  동안 게임 개발자로 있으면서 게임 개발자를 뽑으면서
생겼던 일들을 정리해 봅니다. 만약 이글을 읽는 분이 회사에 들어간다거나
팀장급이라 직원을 뽑고자 할때 어느정도 참고를 하셨으면 좋겠습니다.

내용이 백서라 생각날때 마다 추가로 더 내용을 넣겠습니다.

1장. 사원을 뽑을때 다음과 같은 사람은 뽑지마라.

  보통 수습기간을 3개월가랑을 두는데, 이때, 일하는 습관을 유심히 살펴
보기길 바랍니다. 제가 팀원을 데리고 일하면서 이러한 사람은 조금 힘들
거나 팀웍에 문제가 되는 사람을 정리 해봅니다.


1. 업무시간의 2/3를 사이트를 써치하거나 뉴스 기사거리를 읽거나 만화를
    읽으며 하루 일과를 보내는 사람은 뽑지마라.  

   - 대부분 개발자들이 내세우는 것이 "개발은 어쩔땐 잘되고 어쩔땐, 하루
     종일 안될 때가 있다"라고 한다.
     하지만 365일 인터넷 서핑족으로 살면서 개발자라  우기는 서핑족이
     있다. 절대 이런 사람들과 일하면 실력이 좋더라도  팀웍이 깨지거나
     게임 개발 기간에 차질이 생긴다. 절대로 이런 사람은 급여가 싸더라도
     회사의 팀웍을 위해서는 사퇴 시키거나 뽑지마라.

     지금 이글을 읽는 분도 가슴에 손을 대고 진지하게 생각해보라 자신이
     개발자인지? 아님 서핑족인지 말이다. 아마 모르긴 몰라도 자신이 더
     어떤 종족에 해당하는지 알 수 있을 것이다.


2. 이력서에 책을 썼거나 나름데로 알려진 홈페이지 운영자는 뽑지마라.

   - 이부분은 필자도 어쩜 포함 되는 내용일수도 있습니다. 하지만, 유명한
     홈페이지를 가지고 있더라도 업무를 볼때 공과 사가 구분되어야 된다고
     본다.  개인 홈페이지는 어디까지나 사적인 행위이다. 하지만 업무시간에
     버졋이 펼져 놓고 사사 껀껀 답변을 달아주면서 하루 업무를 보는 개발자
     가 있다. 공과 사는 분명해야 하고, 프로그래밍 작업이라는 것이 집중을
     요하는 직업인 만큼 홈페이지의 답변을 달아주다보면 회사일보다는 답변
     에 대한 해답을 찾아주느라  본연의 일을 못하는 경우를 많이 보았다.

     그리고 책을 썼던 사람치고 나름데로 자아도취에 빠져 있지 않은 사람을
     못보았다. 책과 관련된 질문이나 쇄도하는 편지를 열어보면서 하루 업무
     를 보는 사람을 주위에서 많이 보았다. 당연 앞서 이야기 한것 처럼 개인적
     업무의 흐름이 깨지고 전체적인 업무 지연로 연결되고, 팀웍이 깨지기
     마련이다.

     책쓴이는 나름데로 절제를 하며 한다고 하지만 어디 사람이 하는 것이고
     회사일보다 개인적인 성취감에 도취하다보면  일보다는 사적인 일에
     치우쳐서 하는 경우를 많이 보았다.  고로 경험상 이력서란에 책을 썼다
     거나 나름데로 유명한 사이트에서 답변을 잘달아주는 활동성 있는 사람은
     조금은 고심을 하면서 뽑길 바란다. 물론 100%로 모든 사람이 다 그렇다는
     것은 아니다. 하지만 나이가 어릴수록 공과 사의 구분없이 일하는 사람을
     많이 보았다. 이런사람은 뽑아서 데리고 쓸때, 잔소리를 하는 것도 나중에
     는 서로 불편한 관계로 이어지기 때문에 초창기때 부터 잘 고려하길 바란다.


3. 이력서가 화려한 사람은 뽑지마라.

    - 이력서란에 경력란이 화려한 사람을 가끔 보았다. 그것도 1년에 한번씩
       회사를 옮겨 다니거나 잦은 회사 변경이 있는 사람을 많이 보았다.
       이런 사람 100이면 100정도는 1년도 안되서 다른 회사로 옮긴다.

       물론 현재 회사가 문제가 커서 옮기는 경우도 있겠지만, 그렇지 않고
       이유 없이 잠적하거나, 이상한 핑계로 회사를 옮기는 식으로 프로젝트의
       흐름을 깨거나 전체적인 회사 어려움을 격도록 무책임한 사람을 많이
       보았다. 적어도 이력서를 보면 이사람이 책임감이 있는지 없는지를
       판단하고 뽑아라.  또한 이런 사람이 입사할때는 이번만은 오랜동안
       회사를 다녀보겠다고 하지만, 약간의 인간적 문제나 난해한 어려움에
       붙이지면 과감하게 무책임해지는 스타일들이 많다.

       경력자를 뽑을땐, 적어도 한회사에서 하나의 프로젝트를 완성해본 사람
       또는 3년이상의 이직없이 회사를 다닌사람을 뽑아라 그럼 어느정도
       안정된 프로젝트가 될 것이다.

      

4. 지각을 자주 하는 사람은 과감히 짤라라.

   - 대체로 보면 수습기간에도 지각을 자주 하는 사람을 많이 보았다. 또한
     경력자인데도 불구하고 지각을 자주 하는 사람을 많이 보았다.
      대체로 이런 사람들이 내세우는 것의 공통주제가 개발자들은 출근 시간이
      Free해야 업무의 효율이 오른다고 한다. 허나 이런 사람들이 모여 있는
      개발사 100이면 100, 거의 게임이 나온적이 없거나 나와도 실패하는
      경우가 허다했다. 적어도 자신이 신념을 갖고 개발하는 사람이라면,
      지각하는 시간까지 아깝지 않을까 생각한다. 주로 지각하는 문제가
      밤 늦게 까지 게임을 한다거나 통신을 한다거나 해서 늦는 경우가
      허다하다. 어느정도 지각하는 것이야 특별한 경우라 한다지만, 잦은
      지각은 팀웍이나 업무를 진행하는데 있어 전체적인 발란스를 깨는
      경우가 초래한다.
      잦은 지각하는 개발자는 다른 회사를 가도 비슷하다. 이런사람은 개인적
      으로 개발자로써의 자질이 부족하다고 여겨진다. 분명 게임 개발자라면,
      시간에 대한 나름데로의 소신과 판단이 있어야 된다고 본다.


5. 성실하다고, 착하다고 사람을 뽑지마라.

   - 보통 사람을 뽑을때 상대방이 편해보이거나 착해보이거나 성실해보이는
     사람 위주로 뽑는 경우도 많다. 허나 개발자는 개발에 센스가 있는 사람을
     뽑아야 서로가 편하고 개발하는데 있어 진행이 원활하다.
     개발은 성실하다고만 해서 진행이 되는 것이 아니며, 착하다고 좋은
     타이틀이 나오는 것은 아니다.


6. 소심하거나 내성적인 사람은 뽑지마라.

   - 과거에 병특중에 너무 소심하고 내성적이라 업무의 차질을 격은 적이
     몇번 있었다. 사람은 착해 보이고 어느정도 실력은 있었으나, 팀전체와
     동화 되질 못하고, 소심한 성격으로 개인적인 어찌 보면 왕따 기질을
     갖고 있는 개발자가 있다. 이런 사람이 들어오게 되면 팀전체의 분위기가
     이상한 방향으로 흐르게 된다. 이렇게 되면 어쩔땐 당사자를 불쌍히 여겨
     또는 나름데로 친해보고자 농담을 지나치게하게 되고, 결국 전체적으로
     이상한쪽으로 흐름이 잡히고 만다. 차라리 처음부터 이런스타일은 뽑지마라.


7. 개발자는 개발자만이 알아본다.

   - 개발자는 같은 개발자만이 평가를 하고 어느정도 능력을 가늠할수 있다.
     물론 대놓고 실력 나쁘시네요? 할수는 없지만 나름데로 저사람이 어느정도
     잘한다 못한다는 평가를 하게 된다. 하지만 경영자들은 주위에서 주서듣고
     또는 유명한 게임을 개발했다고 해서 뽑아쓰는 경우가 허다하다.
    
     중요한건 유명한 게임을 개발했어도 그사람이 거기서 어떤역활을 해서
     그게임에 어떤 영향을 미치는 역활을 했는가가 더 중요하다.
     그냥 했으니까? 유명한 회사에 근무했다는 이유만으로 뽑아 쓰는건 화약을
     짊어 지고 불길로 뛰어드는 아둔한 생각이다. 사람을 뽑을때는 개발자의
     눈으로 개발자가 파악하는 순으로 뽑아쓰자. 어설프게 경영자나 메니져가
     좋다고 데려와 팀장이나 개발자로 앉혀놓고 개발하면 그회사는 우주로
     간다. ^^;

     예를 들어 특정 개발자는 실제 코딩은 하지 않고, 말로 개발하는 사람을
     보았다. 물론 메니져나 경영자는 신뢰가 가고 게임을 잘만드는 사람으로
     착각하는 경우를 많이 보았다. 허나 그런 사람이 팀장이라고 할때, 그밑에
     있는 사람들의 피나는 작업상황을 어찌 같은 개발자로 통탄하지 않으랴...
     개발자는 실무에 밝아야 하고 실제 실력이 중요하다.
     말로 개발하는 사람이 개발하면 결국 우주로 갈수 밖에 없는 같은 회사에
     근무하는 다른 개발자까지 비참하게 만드는 상황으로 연출된다.


8.  밤에만 개발할려는 사람 과감이 짤라라.

   - "저는 밤에만 코딩이 잘되요! " 라고 하는 프로그래머가 있다. 또는 낮에는
     좀비처럼 비실비실하다가, 저녁만 되면 팔팔해 지는 개발자도 있다.

     개발자중 40~50%가 아마도 이럴거라 생각한다. 허나 회사 생활을 하면서
     게임을 개발한다고 한다면 패턴을 바꾸어 낮에 근무하고 밤에 퇴근하는
     스타일로 바꾸어야 하는데 굳이 이런 스타일을 고수하는 사람이라면
     역시 팀웍에 저해가 되기 때문에 과감이 짤라야 원활한 게임 개발을 할 수
     있다. 괜히 밤근무조, 낮근무조가 생기면... 과연 언제 전체회의가 이뤄
     질 것이며, 과연 같은 근무시간에 개발을 한다손 치더라도 서로간의 의사
     소통이 될까 말까 할텐데... 언제 뜻을 이루고 개발을 한단말인가?

     물론 이부분은 필자의 개인적인 소견으로 치우칠 수 있는 부분이다.
     하지만  필자가  다년간 밤에 근무하는 올배미족들과 작업을 해봐도
     낮에 근무하는 사람보다 잘 하거나 못하거나 하는 상황을 보진 못했다.
     오히려 올배미 족들의 특징은 오픈 베타나 정식 써비스 때 대량의 버그를
     생산하여,  게임을 즐기려는 게이머들에게 색다른 버그를 찾아 다니게
     하는 즐거움(?), 또는 고통을 주는 상황은 많이 보았다.

     게임개발은 밤과 낮에 구분없이 다 같이 개발하는 것이며, 밤이라 집중이
     더 잘되고 낮이라 집중이 안되는 건 아니라 여겨진다. 개발자 스스로가
     어떤 마음을 먹고 개발을 하느냐의 마음자세가 문제지 결코 환경이
     문제가 되지 않는다 여겨진다. 회사는 어느정도의 규칙이 있는 상황하에
     협조가 되어 게임 제작이 되어야 원활히 진행 된다고 본다.


9. 이유 없이 불만이 많은 사람 과감히 짤라라.

   - 어떤 직원은 입사후에 보면 특정한 불만을 토로 하는 경우를 보았다.
     이런 사람들의 가장 큰 문제점은 하나의 불만을 해결해 준다고 끝나는
     경우를 못 보았다.
     나중에는 어떤 불만인지 모르는 불만으로 주위 사람을 동조하는 경우를
     많이 보았다. 특별한 불만이라는 것 없이 그냥 회사가 싫다던가,
     개발 시스템이 문제가 있다던가 하는 식의 전체를 아우르는 식의 문제점
     만을 내놓는 사람을 많이 보았다. ( 아마도 피해의식을 갖는 사람인지?
     아님 어릴때 자라면서 자신이 소중해 하는 것을 많이 남에게 뺏겨서
     그런지??)

     이런 사람은 실력은 좋을수 있으나 창의적이지가 못하다. 그리고 가장
     중요한건 누구나가 회사의 문제점이나 시스템적인 문제은 이미 알고
     있다는 것이다. 대부분의 사람들의 특징은 문제점을 이야기 하는 것을
     좋아하지만 문제점에 대한 대안을 내놓고 해결하려는 사람은 없다는
     것이다. 만약 문제점만을 강조하며, 마치 자신과 주위사람이 모두 불만이
     있는냥 이야기 하는 사람은 과감히 짤라라. 데리고 있어봐야 팀웍에
     마이너스 역활을 하는 사람이라면 실력이 아무리 좋더라도 아니 데리고
     있는만 못하다.


10. 남보다 더 좋은 컴퓨터 사양을 주어야 게임을 만들수 있다는 사람 짤라라.

   - 개발자라면 고사양을 요구하는 건 당연하다. 하지만, 이상하게도 거의
      병적으로 최신기종, 최고 좋은 컴퓨터만을 고수 하는 개발자를 많이
      보았다. 어떻게 보면 저사람이 개발자일까? 아님 용상의 용팔이나 테크노의
      테팔일까 하는 생각이 들때가 있다. 점심이나 휴식시간에 잠깐의 이야기
      대화중 컴퓨터 부품에 대한 내용이 나오면 거의 모르는 부품이 없고, 정보의
      바다라고 할 정도로 모든 하드웨어 지식을 눈으로만 보는 것이 아닌, 손동작
      발동작, 그리고 입으로 들려주는 서라운드 사운드 까지 해서 종합 멀티미디어
      스타일로 바로 옆에서 모든 정보를 듣게 된다. 참 대단한 사람이다.
      그런 열정을 개발에 쏟아 넣으면 얼마나 좋으련만, 과연 이런 사람이 개발을
      하면 얼마나 좋은 게임이 나올지 아무도 모른다.

      개발자라면 어느정도 하드웨어 지식은 필요하고 최신 하드웨어에 대한
      정보를 알아두는 건 어쩜 당연하다고 할수 있다. 하지만 지나치게 하드웨어를
      요구하고 새로온 직원 컴퓨터의 부품까지 챙겨서 자신의 컴퓨터에 다는
      정도의 개발자들이 있다면 과감히 짤라라.

      이사람은 개발보다는 하드웨어에 관심이 많은 사람이고, 취향자체가 다르다.
      오히려 용산쪽으로 취직을 시켜주는 것이 당사자의 미래를 위해 좋을 수도
      있을 것이다. ^^;

      또한 최신기종으로만 개발을 해서 고사양을 요구하는 게임을 개발하면
      아직도 저사양을 사용하는 유저들은 어떻게 게임을 하란 말인가?
      앞서 이야기한 좋은 사양을 사용하는 개발자를 친구로 만들어주면
      어찌어찌 해서 게임을 해 볼 수도 있을지 모른다. ^^*
    
      진정한 개발자라면 자신에 주어진 환경에서 최선의 작품을 만들어 내줄
      아는 개발자가 훌륭한 개발자라 여겨진다. 좋은 컴퓨터나 하드웨어가
      있으면 더 나은 게임을 만들수가 있고 시간적인 절약은 된다. 하지만
      필자가 만나본 개발자중 편집증 처럼 하드웨어에 집착하는 사람치고
      훌륭한 개발자를 본적이 없었던거 같다.


11. 약속을 어기는 사람은 과감히 짤라라.

   - 일을 하다보면 스케쥴을 잡고 스케쥴에 대한 일정표를 작성하게 마련이다.
     그런데, 대개 보면 일정을 못맞추는 경우를 많이 본다. 그런데, 자세히
     더 나아가 아주 유심히 보면 앞서 이야기한 번호에 대한 것을 충실히 따르고
     이행하는 사람들이 그러하다.  예를 들어보면 업무시간에 서핑만 한다거나
     지각이 잦거나 하는 사람들의 경우 약속이라는 개념은 없다.
     그냥 언젠간 되겠지?  팀장님이 알아서 해주겠지 하는 스타일의 무책임한
     무책임론자들이 있다.

     당연 이런사람들이 같은 팀이나 프로젝트에 있다면 그프로젝트의 팀웍이
     와해되고, 언젠간 모두 손에 손잡고 같이 망하세! 또는 같이 무책임해 지세~
     결국 회사 사장에게도 손에 손잡고, 배째세.. 하는 상황이 된다. 물론 올바른
     팀장이라면, 너무 착한 팀장이라면 중간에서 죽어나거나 할 것이며, 반면
     엄한 팀장이라면 팀원들은 쬐거나 이미 짤랐을 것이라 여겨진다.

     약속을 이행하지 못하는자! 무책임한자 과감히 짤라라.


12. 업무시간에 게임을 자주 하는 사람 과감히 짤라라.

   - 게임 개발을 하다보면 가끔 프로게이머를 능가하는 개발자들이 등장한다.
     문제는 이런 개발자가 게이머가 될려고는 하지 않는다. 아무래도 나름데로
     프라이버시가 있어서 그런지 아님 개발자가 더 좋아서 인지? 아님, 다양한
     게임을 안정적이게 해 볼수가 있어서인지 모르지만 개발자를 사칭하는
     프로게이머를 많이 보았다. 주로 기획자들이 주류를 이루고, 프로그래머
     들중에는 간간이 있다. 물론 기획자들은 어찌보면 타 게임을 분석하면서
     새로운 게임을 만들기 위해 (또는 그대로 복사해서 그림 바꾸고 내용만
     바꾸어 개발하기 위해)서 라고 인정할 수도 있다.

     그런데, 프로그래머들도 마찮가지로 어느정도 필요하다. 허나 점심먹고
     저녁먹고, 출근하자마자, 365일 게임을 즐기면서 개발을 못하는, 또는
     밤새 게임하고 와서 회사에 앉아 집에가서 어떻게 플레이를 할까 고민
     하면서, 하루를 때우기식으로 개발에 임하는 개발자는 과감히 짤라라.

     개발자는 어느정도 절제를 하면서 나름데로, 중도있게 게임을 즐기고
     분석하며 나름데의 통찰력을 갖고 개발에 임해야 한다고 본다.

     개발자가 프로게이머가 되면 결국 게임은 안나오고 주위 팀원들은 다양한
     게임을 즐겨 해 볼 수 있다.


13. 어떤 문제나 일을 주었을때 긍정적인 사고보다 부정적인 사고로 접근하는
     사람은 과감히 짤라라.

    - 가끔씩 일을 시켜 보면 어떤 사람은 처음부터 이래저래 변명을 늘어 놓으며
      "이래서 문제가 있고 저래서 문제가 있고 해서 이것밖에는 못해요"
      또는, "이것만 만들께요" 하는 사람이 있다.
      보통 이런 사람과 일을 해보면 짜증이 난다거나 아예 처다만 봐도 인상을
      쓰게 되는 사람이 있다. 회사에서 또는 특정 팀에서 같이 일을 해보면 분명
      1~2명씩은 이런 사람이 있는데 그렇다고 일을 깔끔히 마무리하는 방식의
      사람은 아니다. 그리고 실력이 남달리 뛰어나거나 하지도 못하는 경우가
      많다. 오히려 주위의 개발자들과 일을 하면서 점점 부담을 갖고 일을 진행하게
      되는데, 결국 나중에는 부정적인 사고를 갖는 개발자와는 일을 하고 싶어하지
      않는다.

      무조건 예스맨이 되라는 이야기는 아니다 분명 일을 처리하다보면 부정적인
      면도 있고, 긍정적인 면도 있을 것이다. 하지만 해보지도 않고 무조건적으로
      부정적이게 보는 사람들이 있다.

      보통 긍정적인 사고를 갖는 개발자들은 먼저 일을 해보고 와서 문제점을 하나
      하나 이야기 하면서 해결점을 제시한다거나 하며 다른 사람과 커뮤니케이션이
      이루어 지는 반면 무조건적 이래서 안되니 저래서 안되니 하는 방식의 개발자
      들은 일방적인 명령식 또는 망무간의 방식으로 일을 진행해 팀웍을 해치는
      경우가 많다. 이런사람은 회사나 팀을 위해 과감히 짤라라.


                                                                   2003년 12월 05일 목요일
                              게임 개발자의 옥석이 가려지기 바라면서... 이준곤씀.
                                                                   2003년 12월 09일 화요일 수정함.

출처 :
http://leechen.wzsoft.com/
Posted by 꿈꾸는자의 생각의파편들

전직 후, 처음 기획서를 받아쥐었을 때, 그다지 기대를 하진 않았다. 단지 다음에 이어질 MMORPG 프로젝트로 넘어가기 전에 잠시 몸을 담을 프로젝트라고만 생각했다. 예전에도 "요거 일단 끝내주면 다음이 정말 멋진거 하자고~" 라는 식으로 꼬드김을 당했다가 피를 본 적이 있어서, 가능한한 빨리 마무리 지으리라고 다짐했다.

 

기획서를 봤다. 그저 그런 고전 게임의 리메이크라고만 생각했다. 그리고는 작업에 들어가서 새로운 방법론도 연습하는 겸사겸사 최선을 다해서 작업에만 몰두했다. 몇달후 게임이 본 모습을 보이게 되었는데...

 

어라? 이거 재미있잖아? 그래픽도 이쁘고...

 

그랬다. 개발팀 모두 재미있어했다. 경영진들도, 외부인들도 다들 마음에 들어했다. 프로토타입만 보여줘도 다들 만족스런 표정을 지었다. 그런 과정에서 점차 튜닝을 하고 버그를 잡고 밸런스를 맞춰나갔다.

 

흠. 그런데, 어떻게 이런 게임이 나온거지?

 

기획서만 봤을 땐, 이런 게임이라고는 생각치 못했는데 말이다. 예전엔, 피터지게 갈구고 싸우고 개기고 음모를 꾸미고 욕하고 해도 얻을 수 없었는데 말이다. 돌이켜보면, 그 흔한 말싸움 한번 없이 너무나도 순탄한 과정을 밟아왔고, 다들 모여서 테스트하면서 아이디어를 내고 채택하는 등의 정말 평온한 개발 과정이었다. (물론 압박이 없을리야 없지만, 그정도는 이제 기본이니...)

 

나를 포함해서, A급 개발자로 도배한 것도 아니고, 다들 열정에 들떠 매일매일 야근하지도 않고(물론 한분은 예외), 멋진 엔진을 사서 작업한 것도 아니고, 최고급 기술력으로 승부한 것도 아니고, 눈이 돌아가는 그래픽으로 승부한 것도 아니다. 그런데, 게임이 재미있게 만들어진 것이다. (개발자라면 다들 자기 게임은 재미있다라고 하지만, 타사의 평가를 종합봤을 때 그정도는 아닌 듯하다)

 

그리고는 깨달음을 얻었다.

 

1. 게임성은 기획서에서 나오지 않는다.

 

예전엔 정말 완벽한 기획서에 대한 환상이 있었다. 그래서, 기획서에 구멍이 보이면 기획자를 무지막지하게 공격했던 적이 있다. 그것도 하나 생각해보지 못했느냐고. 물론, 내가 기획서를 짜보고 난 후, 그런 생각은 이제 절대 하지 않는다. ㅋㅋㅋ

 

아무튼, 완성된 게임의 조작감, 성취감, 긴장과 이완 등으로 인한 재미를 초기 기획서에 담는다는 것은 요즘 생각해보면 정말 불가능에 가까운 일이 아닐까 한다. 그런 것들은 당연히 오랜 개발 과정에서 대화와 타협(-_-)을 거쳐서 점차 녹아 들어가게 되는 법.

 

결국 게임이란 개발팀이 만들어낸 DNA를 먹고서 진화해나가며, 기획자는 초기기획서는 없는 거라고 생각해고 항상 다음번 진화를 위한 DNA지도를 설계하게 되는 것이다.

 

2. 좋은 게임은 좋은 사람들이 만들어간다.

 

"게임은 혼자서 만드는 게 아니다."

 

좋은 팀웍이 있다면 좋은 게임은 자연스럽게 나오게 된다. 이런 좋은 팀웍은 대체로 평화적이며 근면한 사람들 사이에서 꽃피기 쉽다. 마치 우리팀처럼. 물론 이 블로그에 울 회사 사람들이 자주 와서 하는 말이지만, 이렇게 괜찮은 팀을 만나본 건 처음이다. 그래서, 다음 프로젝트는 정말 기대하고 있다. 헤헤헤.

 

팀웍의 기본은, 자신에게 주어진 일에 최선을 다하는 것, 그리고 자신으로 인해 팀에 피해를 주지 않는 것이리라. 그리고, 너무 공격적인 멤버가 있으면 곤란하다는 것을 추가하고 싶다. 너무나 당연한 이야기일까?

 

3. 그러나, 운영/마케팅이 더욱 중요하다

 

아무리 좋은 게임도 마케팅의 도움 없이는 힘들다. 우리 게임이 대박의 길에서 한걸음 벗어나게 된 원인이 여기에 있다. 자세히 이야기를 풀어보자면 대략 다음과 같다.

 

@(*&*#&%*#_*(#*(*$(#*$)*#@$*#)*@#&*&*)#&ㄲ$*)#&$#

 

헥헥헥. 나도 드러내놓고 까대고 싶지만 이딴걸로 고소당하기는 싫으니깐.. ^^;;

 

4. 맺음말

 

너무나 당연한 말을 어렵게 해서 우스울지도 모르겠다. 그러나, 이런 건 겪어봐야 아는 법. 실패를 겪어본 사람만이 느끼는, 좋은 팀에 대한 고마움을 한번 써보고 싶었다. ;)

Posted by 꿈꾸는자의 생각의파편들

예전에 이런 일이 있었다.

 

몬스터마다 Drop 하는 아이템의 종류 및 확률 테이블의 설정을 변경하느라고 프로그래머와 신경전을 벌이고 있었다. 내 불만의 주된 원인은, (사실은 게임내에서 얼마나 잘 떨어지는지 추적도 하지 않는 주제에) 기획서대로 아이템이 떨어지기 위한 게임의 구현이 정확하지 않다는 것이었다. 당시의 구현은 그럭저럭 확률이 기획서와 비슷하지만 정확하지는 않았고, 몬스터마다 다르게 설정하기도 힘들었다. (즉, D&D의 보물 타입과 같이 구현되어 있었다)

 

전직 프로그래머(-_-)이었고 그 프로그래머가 친한 학과 후배이다 보니, 생각해오던 구현을 강요하게 되었고, 그러다가 서로의 약점을 건드리는 바람에 폭발 직전에까지 갔다가, 어째어째 양보하여 전투가 끝이 났다.

 

웃긴 건, 그 당시 나의 피해의식은 "왜 이렇게 밸런스 수정하기가 어려운거지?"라는 것이었다. 실제로 기획 작업을 해보면서 느낀 점이, 서비스중인 게임의 경우 미세한 조정이 항상 발생하게 되는데, 그때마다 프로그래머들의 눈치를 계속 봐야 한다는 게 정말 불만이었다.

 

물론 코드 수정이라는 것이 오랜동안의 전체 빌드와 패치, 업로드, 재시작, 그리고 최종점검까지 걸리는 시간동안 프로그래머들이 느끼는 심적 부담감이 막중하다는 것은 사실이다. 더군다나 전투 공식이나 객체의 파라미터 같은 부분적 코드/데이터 수정이 아니라, 기존의 DB에 누적된 데이터를 보정해야 하는 밸런싱 패치의 경우, 스트레스는 정말 상상 못할 만큼 어마어마하다. (세상의 게임 기획자들이여.. 당신들은 이것만큼은 이해해줘야 합니다)

 

그러나, 아무리 코드 내부에 각종 데이터들이 하드코딩으로 박혀 있을지라도, 꼭 필요한 것은 해야 하는 법. 결국 유저들 눈치 보고, 프로그래머 눈치 보고, 그래픽 디자이너 눈치를 보고, 불쌍한 운영팀 눈치를 보느라 기획자의 마음은 곪아 들어게 되고, 밸런싱 이야기만 나오면 쥐구멍으로 숨고 싶어지는 지경에까지 이르렀다.

 

이제 다시 프로그래머로 전업한 레이옷은, 우리팀의 기획자들은 그런 슬픔에 젖지 않도록 애를 쓰고 있다. 가능한한 파라미터들은 XML 에 명시, 실시간으로도 리로딩할 수 있게 했고, 몇몇 로직들은 lua 스크립트로 빼내서 역시 손쉽게 수정할 수 있도록 했다. 하지만, 진정한 데이터 주도적인 게임이 되려면 아직도 한참 멀었다. 아직도 수정하기 위해서는 프로그래머에게 구두 요청을 해야 하기 때문에... (우리 기획자들도 여전히 스트레스를 받을지도 모른다. 물어보진 않았지만...)

 

그리고는 깨달음을 얻었다.

 

1. 기획자들에게 밸런싱툴을 제공할 것

 

가장 이상적인 케이스가 바로 WarCraft3 (그리고 NWN과 모로윈드) 의 에디터. 

 

그러나, 아직 실력이 되지 않아서, 각종 룰과 객체들을 툴 레벨로 빼내는 것이 쉽지는 않다. 모드를 제작할 수 있을 정도의 툴을 만드는 그날까지 노력하는 수밖에. 아무튼, 프로그래머의 도움 없이 기획자들이 알아서 척척척 스스로 어린이~ 가 되도록 해주면 되겠지. 그동안의 밸런싱 히스토리까지도 로그로 남겨주면 금상첨화.

 

2. 기획자들이 손쉽게 테스트할 수 있는, 다양한 콘솔 명령어들을 제공할 것

 

이 깨달음의 핵심은 실시간 Modification 이다.

 

때와 장소를 가리지 않고, 테스트하고 싶은 기능들을 실시간으로 고칠 수 있도록 한다는 것이 주목적. MMORPG 의 경우 더더욱 필요한 기능이리라. 콘솔창을 띄우고 각 객체의 속성에 접근, 수정 후 테스트할 수 있도록 하는 것인데, 좀더 나아간다면 자동화된 밸런스 테스트까지도 실시간으로 이루어질 수 있으면... :)

 

이를 위해서는 각종 접근 제어 및 암호화와 보안 관련 작업이 선행되어야 할 듯.

 

3. 데이터 주도적인 게임 설계

 

온갖 게임 관련 서적에서 항상 주장하던 유명한 명제.

 

그네들도 다들 피를 봤기 때문에 그런 말을 하는 것이리라. 손쉬운 수정, 손쉬운 테스트, 손쉬운 기능 추가... 더이상 말하지 않아도 다들 잘 이해할 것이다.

 

주의할 것은, 기획팀에서 아예 손쉽게 수정할 수 있는 툴을 제공하라고 처음부터 전방위 압박 공격을 해야지 개발 후반부가 편해진다는 거다. 너무 이해하다가는 서로서로 피곤해지니, 기획팀과 프로그램팀이 힘을 합해 PM과 경영진에게 툴 개발 스케줄을 따내는 것도 좋은 방책일 듯. ㅋㅋㅋ

 

----

 

"구현 신경쓰지 말고, 밸런싱이나 잘해요!" 라고 맞받아치던 후배의 한마디를 아직도 잊을 수가 없다. 이놈의 원죄는 언제쯤 씻겨질 것인가...

Posted by 꿈꾸는자의 생각의파편들

 

1. 서버가 안정적으로 허용하는 접속자 수 설정

2. 1 유저당 몇 마리의 몬스터를 몇 초에 하나씩 주느냐

3. 한 지역에 어느 정도의 유저가 들어가서 존재하는 것이 최적인가

4. 3의 유저가 어느 정도 체제하는가 (어느 정도의 몹을 잡아야 하는가)

5. 4의 결과로 얼마 정도의 돈을 버는가

6. 5의 결과로 어떤 소비를 할 수 있는가 (물약이나 새로운 장비 구입 등)

7. 재충전에 걸리는 시간 (전투 이외의 할 것이 있는 경우도 시간 계산)

 

이런 예측을 하고 나면 몬스터의 난이도나 스폰(spawn) 시간, 맵 분포들을 조절할 수 있게 됩니다.

 

--> 나리띠님! 이런 비법의 공개는 너무 늦은 감이 있습니닷! 

 

 

부끄러운 이야기이지만 한때 MMORPG 기획물을 먹을 때, 공식 혹은 비공식적으로 밸런스를 더이상 하고 싶지 않다고 선언한 적이 있습니다. 꿈 많은 기획 초보에서 일년만에 타락한 실패한 기획자가 된 거죠. 알게 모르게 욕도 많이 먹었습니다. 대놓고 실력없다고 욕먹은 적도 있습니다. 그 암울했던 시절의 밸런싱 스토리를 한번 풀어내보겠습니다.

 

 

1. 완벽한 밸런스?

 

모든 유저들의 마음에 쏙 드는 리밸런싱은 있을 수 없다. 그러나, 가장 많은 유저들이 만족한다면 그게 바로 제대로 된 밸런스다.

 

기술이 추가되거나, 전투 공식이 수정되거나, 몬스터 배치가 바뀌거나, 아이템 가격이 변동되면 분명히 누군가는 불만을 토로하게 되더군요. 그 누군가가 게임 내에서 길마 등 일정 지위(-_-)에 도달해 있거나, 덕망(-_-)이 높거나, 사장과 안면이 있거나, 게시판 글발이 좋을 경우 후폭풍이 무조건 몰아치더라구요.

 

물론 개발팀 특히 기획팀이 최선(자포자기~)을 다하지 않아서 그랬겠지만, 결국 불쌍한 운영팀만 욕을 먹게 되더군요. 결국, 패치 후 필연적으로 발생하는 유저들의 불만을 눈가리고 아웅하기 위해,  불쌍한 기획자와 운영자들은 다음과 같은 얍삽한 노하우를 얻게 되었습니다.

 

 - 모든 아이템의 가격은 시간이 흐름에 따라서 점차 떨어져야 한다

 - 모든 기술의 MP 소모량은 시간이 흐름에 따라서 점차  줄어들어야 한다

 - 동일 레벨의 필요경험치는 시간이 흐름에 따라서 점차  줄어들어야 한다

 - 동일 레벨의 육성 시간은 시간이 흐름에 따라서 점차 짧아져야 한다

 - 모든 제한 요소는 시간이 흐름에 따라서 점차  완화되어야 한다

 

즉, 어떤 새로운 기능이 들어갈 때 페널티 관련 파라미터들은, 이후 플레이어들의 비난을 감안해서, 약간 높게 책정되어야 한다는 건데요, 처음부터 적정 수준을 잡았다가 플레이어들이 시위를 할 경우 더이상 낮추다간 큰일나게 되기 때문입니다.

 

이런 식의 데미지를 한번이라도 입어봤던 분들은, 요즘도 종종 이런 이야기를 합니다.

 

"일단은 이정도로 하고 분위기를 봐서 낮추든가 합시다"

 

 

2. 아무도 믿지 말라?

 

이 부분에 대해서는 제 잘못이 아주 큽니다. 왜냐하면, 기획자라는 넘이 캐릭터를 처음부터 끝까지 키워보지 않았기 때문이지요. 아무튼, 게임이 어떻게 돌아가는지, 요즘 플레이어들의 불만이 뭔지, 스스로 상황 파악이 안되고 주위 사람들에게 불평 불만을 들어야만 아는 상황이었으니... 이사람 말에 솔깃, 저사람 말에 갸웃하게 되는 지경이었습니다.

 

그러다가, 열혈 플레이어였던 사장 운전사의 피를 토하는 한마디!

 

"아.. 캐릭터 키우기가 너무 힘들어. 지금 다들 게임을 접으려고 하고 있단 말이야. 길마들 다 난리야!!!"

 

이 말을 듣고, 한쪽 종족의 성장 곡선을 완화시키는 패치를 내보냈더랍니다. 그 결과는... 다들 짐작하시겠지요. 그 이후, 열렙하는 개발자들의 하소연은 30-40% 허풍으로, 플레이어들의 게시판 이야기는 70-80% 과장으로 인식하게 되는 병을 얻었습니다. 게임 자체가 종족간 대립 구도를 채택해서 이런 불신증상은 더했다는... 웬만한 불만은 무시하고, 게시판에서 호소력이 있는 명문을 발견하거나, 여러 명한테서 동일한 불만을 듣게 되면, 보완 작업에 들어갔습니다.

 

그나마, 이쪽 저쪽 불만을 모두 접하는 운영팀의 이야기가 가장 중립적이었습니다. 그치만, 자기 캐릭을 키우는 넘은 또 그게 아니더군요.

 

제가 좀더 많이 플레이를 했더라면 충분히 막을 수 있었던 실패담이지만, 웬지 모르게 그게 안되더군요. 다들 저보고 제발 플레이좀 해보라고 이야기하곤 했지만, 그냥 한귀로 흘려버렸다는.... (물론 다들 속으로 정말 답답해하고 어떤 사람은 욕도 많이 했겠지요) 프로페셔녈이라면 절대 그럴리가 없었겠지요. 자기가 만든 게임에 대한 애정 부족! 그때 저때문에 피보신 많은 분들께 여기서나마 잠시 사죄를 드려봅니다.

 

 

3. 밸런싱에 대한 주관적인 접근(X)

 

사실 이게 본론이 되겠습니다. 사실 나리티님의 글에서 나온 목록중에서 많은 부분에 대해서 고민을 안해본게 아닙니다만, 그런 데이터 수집 활동이 너무 주관적이며 신용도가 낮다는데 문제가 있습니다. 결론부터 말하자면, 플레이어들의 게임 플레이에 대한 로그 분석 활동이 기획자들의 주요 업무가 되어야 한다는 거구요. 그에 따른, 프로그래머들의 서포트가 있어야 한다는 겁니다. (라기보다는, 아예 초기 개발 시점부터 기획팀에서 이후 조사를 위한 필요 데이터를 명시한 기획서를 넘기고, 프로그램팀에서 관련 데이터를 가공하기 쉽도록 DB에 남긴다..가 되겠네요)

 

지금 참가중인 프로젝트에서도 이런 부분이 너무 미숙해서, 회의에 들어가면 대체로 주관적인 평가들을 많이 하곤 합니다. 더군다나 퍼블리셔에서 누군가가 한마디한 것들이 점차 증폭되어 정말 진리인양 개발팀으로 흘러 들어오는 걸 보고 있노라면.. 으..

 

 "게임이 어려워서 동접이 늘지 않아요.." <-- 동접 이야기가 또 나오네요.. -_-+

 "처음에 몇 번 해보고 다들 접어요"

 "유저중 절반이상이 어느 수준에서 게임을 포기해요"

 "하다보면 자꾸 튕기고, 짤려요"

 

분명히 이런 부분은 데이터를 가지고 객관적으로 접근해야 하는 것임에도 불구하고, 다들 너무 즉흥적이면서 주관적으로 접근하는 경향이 있더군요. 처음부터 이런 부분을 감안하고 데이터를 남겨놓지 않으면, 정작 필요할 때 문제의 원인을 파악하기 힘든 경우가 많은데... (그렇다고 특별한 지시 없이도 알아서 필요 데이터를 잘 축적해주는 프로그래머는 드물지요)

 

(그렇다고 데이터 만능주의로 흐르다가는 게임의 본연의 모습을 잃어버릴지도 모르겠네요. 가령, 플레이 시작후 일주일만에 총 신규가입자의 10%가 떨어져나가는데 이 원인은 20레벨에서 25레벨의 경험치가 너무 많아서 그런게 아니라 퀘스트의 복잡도가 너무 높고 플레이 시간이 길어져서 중얼 중얼중얼... 퀘스트를 하루에 1.5개 이상 주어지고 초보들의 소지금액을 현재의 20%로 증가시키기 위한 대책안을 마련해서 중얼 중얼... 물론 비지니스로의 가치는 충분하겠습니다만~)

 

시스템 디자인 시점에서도 분명 나리띠님의 글처럼 안배가 되어 있어야 하겠지만, 과연 그게 원안대로 잘 적용되고 있는지, 플레이어들이 만족하고 있는지를 파악하려면, 테스트 시점이나 오픈 이후에도 분명 데이터 분석을 통한 사후 검증 및 개편작업은 필연적일 것입니다.

 

 

4. 결론 : 데이터 마이닝(?)

 

전개가 좀 산만했네요. 억지로 정리를 해본다면, 완벽한 밸런싱이라고 하는 것은 다른 사람이나 자신의 주관적 판단보다는 객관적인 데이터를 토대로, 다수 플레이어들의 불평불만(-_-)을 가지치기하듯 최소화한다. 라고 우길 수 있겠습니다.

 

DB 전문인 후배에게 물어보니, 다들 한번쯤 들어봤을 데이터 마이닝이나 OLAP 등의 분야가 이런 부분을 다루는 거라고 하네요. 단순한 데이터에서 의미를 마이닝(mining)해내어 트렌드를 찾아내고 정책을 결정하는 거라나요? 맨 위의 그림을 보면 대충 무슨 의미인지는 아시겠습니다만.

 

큰 회사라면 몰라도, 고만고만한 작은 회사들에서는 이런 부분을 제대로 갖추기가 힘들지 않을까 합니다. 우선 무엇을 저장할지를 골라주는 경험많은 기획팀과, 어떻게 저장할지를 결정해주는 DBA, 그리고 데이터를 분석해서 적절히 플랜을 작성할 마케팅 담당자가 필수적이겠습니다. 물론, 프로그래머는 당연히 시키는 데로 데이터를 DB로 넘겨야죠.

 

물론 지금도 많은 회사들은 접속 회수와 시간, 지역/성별/나이별 통계 자료, 시간대별 분포도 등을 기반으로 마케팅 플랜을 작성하는 곳은 많겠습니다만, 게임 내부적인 수많은 파라미터들을 남겨서 이후 리밸런싱에 활용하는 회사는... 글쎄요 NCSoft 라면 아마 그렇게 할지도 모르겠습니다.

 

KGDA의 어딘가에서 본 글처럼, 아무래도 한국에는 이를 제대로 할 줄 아는 개발자가 많지 않은 듯 합니다. (이게 개발자가 알아서 해야 할 일은 아니겠지만요)

 

참고로 후배가 연재중인 DataWareHousing 에 관해서 소개한다.

 

http://reiot.com/moin.cgi/DataWarehousing

 

----

 

그나저나, 이렇게 결론지으면 뭐하나요? 동접이 늘어나질 않는데... ㅠㅠ

Posted by 꿈꾸는자의 생각의파편들

원문보기

 

많은 현업 개발자들은, (그리고 절대다수의 아마추어 개발자들은) 게임 개발에 있어서 스크립트는 필수적이라고 생각하고, 이를 지원해주지 않는 많은 한국의 프로그래머들을 비웃을지도 모른다. 그러나, 우리 프로그래머들이 스크립트를 도입하기 싫어서 안하는 건 아니다. 시간이 많이 남거나, 반복되는 작업과 요청이 귀찮거나, 아예 처음부터 스크립트를 쓸 작정을 하고 시작했을 때에나, 이전 프로젝트에서 스크립트 덕택에 짭짤했거나, 상부의 강요가 있지 않은 이상, 개발 도중에 스크립트를 도입하는 건 꽤나 귀찮고 어려운 일이다. 어쨌든 이러저러하게 도입했다 하더라도 그 스크립트가 어디어디까지를 지원할 것인가는 프로그래머의 손에 달려 있다. 경력이 짧은 프로그래머들에게 워크래프트3, NWN, 모로윈드의 스크립트를 기대한다는 것은 좀 무리가 아닐까 한다.

 

http://www.reapers.org/nwn/reference/ -- NWN 스크립트 레퍼런스

 

레이옷이 처음 스크립트를 도입한 계기가 바로 스타크래프트의 트리거 시스템의 파워풀함이었으며, 여기에서 감명을 받아서 만든, AI 용 스크립트가 바로 최초의 스크립트였다. 이 넘을 DB에 넣어두고 서버 뜰 때 한번 읽게 하는 정도여서, 빠른 수정과 결과 바로 보기 같은 용도로는 쓰기가 좀 애매했다. 당연히, 기획자들이나 운영자들은 이들의 존재를 잘 알지 못했으며, 단지 AI 개선의 요청이 있을 경우 프로그래머들이 적절히 고치는 정도였달까?

 

두번째 프로젝트에서도 처음부터 스크립트를 도입할 생각은 없었다. XP 를 기반으로 필요한 것만 제일 빨리 구현하고 논다..라는 개발방침 덕분에 한달만에 게임의 골격을 완성하고, 이후부터 서서히 기능추가와 최적화를 해나갔기 때문이다. 처음에는 select() 기반의 TCP 로 했다가 IOCP 를 도입하고, UDP 를 도입하고, Windows Service 를 사용하고, 새로운 게임 모드를 추가할 때쯤, lua script 를 도입하게 되었다. 계기는, redpixel 님과의 오프라인 만남에서 컬쳐쇼크를 먹었기 때문! (아마도 한국에서 루아를 제일 잘 다루는 분이 아닐까 한다)

 

http://www.lua.org -- 루아 공식 홈페이지

http://www.redwiki.net -- 네트워크 프로그래머라면 한번쯤 가봐야 하는 레드위키

 

루아를 도입하고 나서 얻은 것은, 왜 처음부터 이걸 하지 않았나..하는 후회이다. 리얼타임 게임개발이랄까? 컴파일과 빌드 없이 실시간으로 코드를 수정하고 그 결과를 본다는 게 얼마나 편했던지... 기존의 안정화된 C++ 코드를 점차 루아로 치환해나갔기 때문에, 별다른 문제점도 없었고 문법이 별로 어렵지 않아서 개발팀 내부의 정보 확산도 용이했다. 속도 문제야 뭐 루아가 원체 빠르니까... 한가지 걱정이 남아있다면, 그것은 바로 디버깅이다. 아직까지 VC++ 에서 line by line 실행해가면서 스택을 보는 게 지원되지 않아서... 우리의 희망은 LuaPlus 라는 루아 확장 모듈을 만드는 회사에서 개발중인 디버깅 지원... (지금은 스택 보기만 지원함)

 

http://wwhiz.com/LuaPlus/index.html -- LuaPlus

 

세상에서 제일 훌륭한 프로그래머는 바로 게으른 프로그래머라고 하는 말처럼, 스크립트는 프로그래머를 게으르게 해주는 좋은 축복의 선물이라고 감히 말해본다.

Posted by 꿈꾸는자의 생각의파편들

게임 업계를 떠돌다보면 많은 경우 개발이 진행되는 도중에 투입되는 경우가 많다.

중간 투입의 경우 크게 두 가지의 경우가 볼 수 있다고 하겠다.

 

1. 프로젝트의 기초 틀이 잡힌 상태에서 본격적인 리소스 작업을 위한 인력이 부족해서 투입되는 경우.

2. 프로젝트가 진행되는 도중에 여러가지 요인으로 기존 기획자가 나가서 기획 인력이 없는 상태에서 새롭게 투입되는 경우.

 

사실 1번의 경우는 별로 할 말이 없다.

기반이 닦인 상태라면 팀장급 기획자 및 게임 디렉터의 역할을 맡은 사람이 엄연히 잘 이끌어 줄 것이니 그에 맞추어서 따라가면 될 것이다.

 

어느 정도 경력이 쌓인 상태의 기획자의 경우 2번의 경우에 많이 투입이 된다고 생각하기에 2번에 대한 나의 경험을 얘기해보고자 한다.

 

나의 경우 2000년 이후부터  현재 몸 담고 있는 D사에 입사하기 전까지는 거의 모든 프로젝트에 중간 투입이 되었다.(대다수의 경우 급여가 밀린 상태에서 밀린 카드값을 결제하기 위해 급하게 회사를 옮긴 경우가 많은 것이 하나의 요인일 것이다.)

 

모든 경우를 얘기하자면 너무 길어질 것 같으니 내가 겪은 프로젝트 별로 나눠서 글을 올리려고 한다.

 

오늘의 경험담

 

MMORPG 개발 경험이 없는 기획팀장이 있던 회사에 투입이 되었던 상황.

 

2001년 여름에 나는 광장동에 있는 M사의 G프로젝트에 투입이 되었다.

 

당시 기획팀의 구성은

 

1인의 메인 기획팀장이 있었으며 나와 같은 날에 신입 기획자가 한 명이 입사를 하여 총 3명으로 구성이 되었다.

내가 입사하기 전에 1인의 기획자가 있었으나 기획팀장과 의사 충돌로 인하여 퇴사한 것으로 알고 있다.

 

당시 입사한 후에 내가 파악한 기획의 상태와 문제점은 아래와 같다.

 

개발이 진행된 상황

1. 깔끔하고 귀여운 풍의 그래픽 리소스는 풍족한 상태.

  - 3개 종족중 2개 종족의 그래픽 리소스 작업 완료.

  - 기본적인 인터페이스 구조의 완성

2. 외부적인 모양에 대한 설정 완료

  - 그래픽 작업을 위한 설정 문서는 많이 작업되어 있는 상태.

  - 아이템에 대한 간단한 개요 정도의 설정은 있는 상태.

3. 개발 상황.

  - 서버 연동되어 캐릭터의 이동만 구현된 상태.(라지만 거의 진행 안 된 상태.)

 

내가 파악했던 당시 기획의 문제점

(개발 및 그래픽 보다는 기획에 대한 문제점만 열거하겠다.)

1. 외부적인 설정은 있었지만 기본적인 게임의 구조가 안 잡힌 상태.

  - 게임의 시스템에 대한 구조가 전혀 잡혀있지 않아서 개발 파트 역시 무엇을 개발해야 할 지 몰랐던 상태.

2. 아이템 등에 대한 개요는 있지만 실질적으로 게임에서 어떻게 사용이 되는지에 대해서 전혀 잡혀있지 않았다.

3. 게임의 구조가 잡히지 않은 상태에서 잡힌 문제점 많은 인터페이스.

 

그 외에 열거하자면 수 없이 많지만 간단하게 정리했다.

한 마디로 보이는 것에 대한 개요만 있고 어떤 게임이 될 것인지에 대한 설정이 전혀 없었다.

라고 할 수 있는 상태였다.

 

내가 중점적으로 보완하려 했던 사항.

 

1. 게임의 뿌리를 잡자.

기본적으로 유저가 3가지 종족을 골라서 자유롭게 성장을 한다는 컨셉은 잡혀있던 상태였다.

자 그럼 이 컨셉을 가지고 어떻게 성장을 시킬 것인간에 대한 구체적인 시스템을 잡기 위해서 각종 페러미터에 대한 개요을 잡았다.

각 페러미터간의 상성에 대한 개요를 잡고 캐릭터의 성장에 대한 클래스 시스템의 도입.

각 클래스와 페러미터의 연계

유저의 행동이 페러미터에 끼치는 영향 등을 정리하였다.

그 외에 아이템의 페러미터와 그 페러미터가 끼치는 영향등에 대한 개요를 잡았다.

 

위의 작업은 개발자가 어느정도의 테이블을 준비해야 하며 서로 연계되는 데이터의 묶음과 패킷의 전달 방식을 정리하는 데에 도움이 되며 또한 각 페러미터의 실질적인 데이터를 구성하는 데에 있어서도 기준을 잡아주는 역할을 한다고 할 수 있다.

 

2. 시스템의 특징을 추가하자.

위에서 열거했던 시스템은 유저의 기본적인 성장 방식 및 전투 등의 가장 기초적인 부분을 이루는 구성이라고 할 수 있다.

그 시스템을 잡은 후에 해당 시스템과 연계하여 게임의 특징이 되는 시스템을 추가하는데 주력하였다. (당시에는 기본적으로 이동 과 전투만 있을 뿐 전혀 특징이 없는 기획이었다.)

 

그리하여 게임에서 주력으로 내세울만한 시스템을 내세우기 시작했으며 그 때 주력으로 삼았던 것은 국가 시스템이었다.

그 국가 시스템에 대해서 개발팀에게  "유저 한 명 한 명이 유닛이 되는 전략 시뮬레이션"이라고 설명했었다.

그 시스템을 덧붙이기 위하여 실시간 전략시뮬레이션 및 턴제 전략 시뮬레이션들의 개념을 많이 변형및 개량하여 MMORPG에 맞는 시스템을 구현하기 위해 노력했다.

 

유저 한 명 한 명에게 목표를 부여하고 자칫하면 지루해지거나 너무 복잡해질 수 있는 상황에 대해서는 경계를 해가며 중점을 잡기 위해 노력을 했다.

또 하나의 기획자와 함께 수없이 상상과 대화를 통한 가상 플레이를 진행하였다.

 

독특한 길드전을 구성하기 위해서 미식 축구의 시스템을 빌려오기도 하는 작업등을 하며 컨셉을 유지할 수 있는 독특한 시스템의 구성에 주력하였다.

 

또한 3가지 종족이 있다는 컨셉을 이어가며 특징을 잡을 수 있는 방향을 생각했다.

 

엘프와 불의 민족. 바람의 민족

각 종족간의 상성과 특징.

그리고 그들만의 문화.그 문화에 따른 클래스의 성장 및 종족 스킬등.

그에 대한 개요를 잡는데 주력했다.

 

3. 세부적인 데이터의 작성

개요를 잡은 후에는 세부적으로 유저에게 보여질 데이터를 잡는 데 주력하였다.

예를 들어 아이템의 경우 내가 아이템 페러미터의 개요와 연동 방식을 정리해서 전달하고 벨런싱에 대한 개요를 잡아주었고 당시 신입 기획자가 엑셀 데이터를 채워넣는 역할을 하였다.

 

나는 스킬 조합 시스템을 구성하였고 너무나 독특한 시스템이기에 신입 기획자가 처리할 수 없어서 실질적인 페러미터 데이터도 내가 구성하였다.

또한 스킬에 따른 그래픽 이펙트를 구상하고 구현 문서를 작업하여 이펙트 담당 그래픽 디자이너와 하루 종일 앉아서 그래픽 작업에 대해서 얘기하고 데이터를 제작하였다.

 

4. 인터페이스의 재작업

당시 2001년 9월호 온라인 게임 관련 잡지들에 구라 스샷을 작업하여 보낸 기억이 있다.

이 때 작업하면서 너무 안타까웠던 것은 인터페이스의 구성이 너무 시대의 흐름에 역행을 하고 있었다는 것이었다.

 

2001년 이전에 나온 국산  MMORPG 게임은 대다수가 큼직큼직한 인터페이스를 사용하여 팝업 창들이 게임 화면을 많이 가리는 것이 많았다.

나는 당시 아나키 온라인을 플레이하고 새로 개발 준비되는 게임들을 벤치마킹 하고 있었는데

당시의 흐름은 윈도우 인터페이스 처럼 작고 간편하고 팝업에 장식이 많지 않고 깔끔한 인터페이스로 가는 단계였다.

지금 서비스중인 라그나로크나 마비노기 등의 게임을 보면 이해가 될 것이다.

당시는 그런 흐름으로 가는 과도기였기에 나는 작고 깔끔하고 간편한 인터페이스를 지향하고 그런 방향으로의 변화를 요구했다.

또한 기존의 인터페이스는 기획의 뿌리가 잡히지 않은 상태에서 작업이 된 것이 많아서 게임의 특징을 표현하는 데에 너무 부족한 문제도 있었다.

위에서 열거했듯이 기획에 대한 개요를 작업했고, 개요가 작업된 후에는 인터페이스에서 표현할 것이 명확하게 잡혀있는 상태였기 때문에 인터페이스를 잡기에 더 수월했다고 할 수 있다.

 

당시 인터페이스를 작업하는데 있어서 나는 기획 문서에서 간단한 레이아웃을 잡고 그에 대한 설명과 필요 그래픽 리소스를 정리하여 전달하였었다.

허나 그래픽 디자이너 역시 인터페이스 작업에 대한 경험이 없는 상태여서 문제가 많았고 결국엔 내가 그래픽 디자이너 옆에 앉아서 레이아웃을 픽셀단위로 직접 잡아주고 심지어 텍스쳐까지 골라주기도 했다.

 

그 과정에서 개발 기간이 딜레이 된다는 점(인터페이스를 재작업하면 그래픽 뿐만 아니라 프로그래머도 재작업을 해야하므로)에 대해서 실장급 멤버에게 엄청난 욕을 먹었다.

실제로 눈 앞에서

"배준호씨 게임 만들 생각이 있는거에요? 없는거에요"

라는 말까지 들었으니까..

허나 난 인터페이스는 유저와 게임이 인터랙션을 이루는 핵심이라 생각했고 절대 양보할 수 없었다.

그 회사에서 내가 끝까지 고집을 부린 유일한 작업이라고 생각된다.

 

 

반성되는 부분.

 

1. 열정이 사라진 기획팀장을 신뢰하지 못함.

당시 여러가지 문제로 인해서 개발실은 매우 불안정한 상태였다.

다 밝히긴 어렵지만 정치가들이 설치기 시작하면서 개발 실장이 갈리는 사태가 발생했다.

그 몇달 전부터 많은 문제가 쌓여오면서 기획 팀장은 매우 지쳐있었고 열정까지 사라져 있었다.

실제로 기획 팀장은 개발상에 필요한 일을 하지 않았고 할 수 있는 상태도 아니었다.

그는 개발 이외의 외부 업체및 간부들과의 커뮤니케이션을 진행하며 기획자 둘이 작업한 것을 취합하는 역할을 하였다.

허나 그는 이미 지칠대로 지친 상태였다고 생각된다.

그래서 나는 그를 신뢰하지 못 했고 그 점은 그가 작업한 결과물에 대한 불신으로 이어졌다.

그 부분들이 내가 강력하게 시스템을 주도했던 원인이 되기도 했지만 한 팀으로서 공동 작업을 해야 했어야 한다는 부분에 대해서는 아쉬운 점이 많다.

하지만 신입 기획자와의 호흡은 좋았다.

 

2. 너무나 촉박했던 일정.

촉박한 일정에 대해서 경영진을 설득하는 것을 포기하였다.

그 일정에 맞추기 위해서 퇴근을 포기하고 회사에서 먹고자는 것을 생활화하였다.

그런 과정에서 일정과 퀄리티의 조율을 했어야 했는데.

그 당시 나는 다른 퀄리티를 모두 양보했지만 인터페이스에 대한 퀄리티를 양보하지 않았었고 그 부분은 일정 초과의 원인이 되었다.

그 부분을 포기했다면 일정을 맞추기는 맞추었을 것이다.

문제는 초반에 개발 과정의 문제점을 먼저 파악했으면서 그것을 설득하지 못한 나의 잘못이라고 생각된다.

 

3. 아쉬운 퇴사.

그렇게 작업한 것도 오래가지 못 했고 결국 급여가 체불되면서 나는 퇴사를 할 수 밖에 없었다.

퇴사하는 날에 인터페이스에 대한 작업을 완료했던 것으로 기억한다.

인수인계를 하는 부분에 있어서 적어도 내가 남긴것은 누구나 보기 쉽게 할 수 있도록 노력했다.

당시 내 상황이 그렇게 어렵지만 않았어도 급여 체불을 견디면서 작업을 할 수 있었을텐데, 그걸 할 수 없던 나의 상황이 너무나 아쉬웠다.

조금만 버티었다면 좋은 결과를 날 수 있을것이라 생각했지만 개발실장과 기획팀장의 퇴사. 그리고 나도 퇴사를 하면서 신입 기획자 혼자 남게 되었다.

그도 엄청난 열정으로 열심히 잡아가려했지만 신입으로서는 너무 벅찬 역할이었고 프로젝트는 점점 산으로 가고 결국엔 문을 닫은 것으로 알고 있다.

 

 

그 외의 이야기.

위의 경험들을 토대로 나름대로 내가 내린 결론은 다음과 같다.

 

1. 기존의 작업물을 무시하기 보다는 다시 한 번 살펴보고 이해할 수 있도록 노력을 하자.

내가 기획팀장을 신뢰하지 않은 것은 장단점이 있었다고 생각된다.

그의 생각을 내가 정확히 이해를 했다면 시스템을 잡는 과정에서도 좀 더 시간이 단축될 수 있었다는 아쉬운 마음이 있다.

 

많은 기획자들이 입사하는 경우 기존 작업을 제대로 이해하려하기보다는 비판먼저 하는 경우가 많다.

실제 그 작업물이 안 좋은 경우도 있지만 자신의 입지를 굳히기 위해서 이전 작업을 비판하는 경우도 많다고 생각한다.

다른 사람의 작업물을 비판하기 전에 먼저 그가 어떤 생각으로 왜 그런 결과물을 만들었는지 심도있게 검토하는 과정이 필요하다고 생각이 된다.

 

----------------------------------------------------------------------------------------

 

오늘은 기획팀장이 존재하는 회사에 입사하여 팀장을 보좌(하기보다는 약간은 무시하며)하며 작업했던 경험을 넣었다.

 

작업된 것이 많은 상태라서 급한 리소스 제작에 쫓기지는 않았던 상황이다.

다음에는

팀은 세팅되고 개발은 전혀 진행되지 않은 상태에서 기존 기획을 이어받은 경험을 얘기해보고자 한다.

 

Posted by 꿈꾸는자의 생각의파편들

요즘에 신규 온라인 게임 기획에 들어갔는데요......

기획자인 저로서는 가장 신나기도 하고 가장 고통스럽기도 한 기간이죠.

 

아래의 글은 사실 몇 달전에 떠돌던 글인데, 재미있게 읽은 것 같아서 붙입니다^^

=======================================================================================

게임 회사 망치는 방법 10
Francois Dominic Laramee
translated from www.gignews.com/fdloriginalten.htm

매년 1000~10000 명이 자신감을 가지고 게임 사업을 시작한다.

모두 끝내주는 아이디어와 실력으로 대박을 꿈꾼다. 이들 대부분이 몇개월 가지 못하고 망한다.

대박으로 가는길은 정해져 있지 않다. 그러나 실패를 하는 방법은 아주 많다. 여기 몇가지를 보여준다.


1 - 잘못된 게임 장르를 선택해라.

작년에 난 20여명의 게임 개발자들을 만났다.

그중 3개만 제외하고 다들 PC multi-player FPS를 만들고 있었다.

매년 1200 ~ 3000 의 PC게임들이 발매 된다.


이중 가반수 이상이 FPS또는 RTS다. Carmack, valve, blizzard와 대항할 순 없다.

뭔가 색다른 점이 없다면 FPS, RTS는 절대적으로 피해라.

현실적이어라, 아마 당신은 Carmack을 능가할 순 없다.

한 년에 5개 이상의 성공 적인 FPS는 보기 힘들다.

'경쟁자들이 많은 제품을 만드는건 회사를 망가뜨리는 지름길이다.'

이 단어들을 중시해라 = 'Market research', 'originality'



2 - 일일 드라마 회사를 만들어라.

게임 개발자들은 마치 화학제품과 같다. 잘못 석으면 회사는 폭발한다.

Cat Herding syndrome - 실력좋은 사람들만 모았다.
                       그러나 서로 잘 지내지 못한다.   
                       서로 회사 정치에나 신경을 더 많이 쓰고 헐 뜻는데 시간을 낭비한다.
                       프로젝트가 망한다.

Prima Donna syndrome - 아무하고도 일할 수 없는 사람이 한명있다.
                       나한테도 한번 일어 났었다.
                       내 전에 있던 회사에 감옥에서 나온 핵커를 고용한 적이 있었다. 
                       그는 잘 지냈지만 스케쥴, 작업 현황에 관해 얘기를 시작하면 폭발했다.
                       결국 나중에 소스를 가지고 달아났다.
                       프로젝트는 300%돈을 더 낭비했다. 이런 이들은 빨리 해고해라.

Misplaced Greed syndrome - 실력자들에게 높은 연봉을 주는 걸 실어해서 아마추어들을 고용한다.
                           프로젝트가 망한다.

Unstoppable Inertia syndrome - 내 가장 처음 직업엔 엄청나게 못하는 프로그래머가 있었다.
                               어떤 프로젝트든지 5배가 넘는 시간이 소요됐고 기능들도 반이상이 삭제됐다.
                               보스가 너무 착해 해고를 하지 못했다.
                               '프로 헤드헌터를 사용해라.
                               실력있는 헤드헌터는 엄청 유용하다.



3 - 잘못된 License 를 택하라.

좋은 license는 50000이상의 추가 판매의 효과를 본다.

어떤경우는 200,000장이상의 효과도 본다. 그러나 license가 다 같지 않다.

얼마전 나는 수퍼 히어로 캐릭터를 바탕으로 한 게임 제의를 받았다.

캐릭터도 멋지고 난 여러가지 아이디어를 생각할 수 있었다.

그러나 판권 소유자는 만화책에 나와있는 그대로 하나도 틀리지 않게 만들라는 조건을 제시했다.

우리는 이 프로젝트를 맡지 않았고 얼마후 난 이 프로젝트를 맡은 다른 팀에 대한 좋지 않은 소식을 들었다.



4 - 누구나 기획을 할 수 있다고 생각해라.

게임을 엄청 많이 한다고 해서 좋은 기획자가 될 수 없다.

게임회사엔 프로젝트에 회의를 느낀 사람들이 따로 게임회사를 만들어 더 좋은 제품을 내 놓을거라고

생각하는 사람들이 많다. 그러나 게임은 그토록 쉽게 만들 수 없다.

나는 어떤 회사에선 상관이 너무 게임에 관섭을 많이 해서 시간을 낭비하는 것을 봤다.

이런 실수를 하지 말라.



5 - 실력있는 개발자들이 낮은 연봉에 대박을 노리고 게임업계에 일할거라 생각하라.

게임 개발은 점차 더 복잡해지고 있다.

Cutting-edge 게임을 PSX2용으로 만드는 건 이제 로켓만드는것 처럼 복잡하다.

똑똑한 프로그래머들이 필요하고 이들은 게임 업계뿐 아니라 다른 업계들에서도 일할 수 있다.

Intel, Lucent, Lucasfilms들이 주는 연봉을 맞출 수 있어야 한다.

그러므로 이급 개발자들에 만족하기 싫으면 돈주기를 아끼지 마라.

( 일년에 1억을 버는 개발자 한명이 4000을 버는 두명보다 더 나을 것이다. )

이들은 게임의 대박약속에 더 낮은 연봉에 일하지 않을 것이다. (대박후의 상금이 '엄청' 높아야 할 것이다.)

요즘은 게임회사들이 Ph.d등을 데려오는 시대다. 그러므로 연봉 수준이 최소한 다른 업계들과 비슷해야 한다.




6 - 아주 많은 도박을 해라

요즘은 최소한 50-70%의 완성을 하지 않으면 publisher를 구할 수 없다.

멋진 대모없이 투자도 불가능 하다.

그러므로 시작을 할 경우, 돈을 전혀 벌지 못할 지도 모를 제품에 어느정도 시간을 써야한다.

그러나 거기서 멈춰라. 일단 투자를 받아야 한다.




7 - 심하게 관리해라

게임 개발자들은 버릇없고, 자기주장이 강한 사람들이다.

그렇기 때문에 심하게 관리를 하려하면 문제가 많을 것이다 꼭 필요한 제재를 못할 것이다.

예를 들어 개발자들은 정리 정돈을 잘 하지 않는다.

그래픽 디자이너들은 그리고, 프로그래머들은 책과 자료들을 많이 읽어야 한다.

정리정돈을 강요하는 건 그들을 모욕하는 행위다.

Project관리를 하루 이상 세분화 하는 건 시간 낭비다.

나는 관리자가 개발자들에게 regular meeting 시간, 공장식 고용/해고, 옷 입기, 정시 출/퇴근을 강요해서

거의 폭동이 일어날 번 한걸 본적이 있다.

이들이 비효율적이라고 생각할 수 있다.

나도 Business 학교에서 그렇게 배웠다.

그러나 비효율성이 좋은 경우가 있다. 이는 그중의 하나다.

지금의 작은 관리의 승리는 나중에 대재해로 확산될 수 있다는걸 명심해라.




8 - 관리를 너무 적게 해라.

이젠 '창의적인 혼란'의 시대가 아니다.

게임은 'software engineering'이다. 30,000개의 file들이 각각 어떤 상황에 있는 지 누군가 관리를 해야한다.

코드가 바뀐지도 모르고 개발자도 마구 바뀌어서 6개월 프로젝트가 7개월 늦춰진 경우를 허다하게 봤었다.




9 - 유명한 회사들의 뒤를 따르고 싶어해라.

당신은 id나 blizzard가 될 필요가 없다.

자그만 게임들을 만들면서 잘 사는 개발자들이 아주 많다.

1999년에 한달동안 'who wants to be millionaire'가 600,000장 가까이 팔았다.

이는 Baldur's gate, half-life, tiberian sun이 일년동안 판 장수보다 많다.

그리고 이는 30억, 또는 3차원 프로그래밍 신이 필요하지 않았다.




10 - 모든게 최고여야 한다고 생각해라.

이것은 세상에서 가장하기 힘든 일이다.

무엇이 충분한지 알아라. 모든 부분을 최고로 하려다간 돈과 힘이 부족해서 망한다.

당신의 resource는 제한 ?다. 그러므로 당신 게임의 '강점'을 잘 택하고 거기에 노력을 퍼부어라,

그리고 나머지 부분은 어느정도 까지면 문제가 없다고 판단을 해라.

어디서 절약할줄 알아라.

Posted by 꿈꾸는자의 생각의파편들
2005.01.07 22:33

[펌] 밸런싱에 대해.. Game Dev.../게임만들기2005.01.07 22:33

  • 게임에 있어서 발랜싱은 즐거움을 더해주는것, 상호경험을 극대화하는것, 게임에 있어서 부정적인 경험을 최소화하는데 목표가 있다. 즐거움의 요소에는 그래픽, 기술(효과.속도), 사운드, 스토리, 스토리전개(자기몰입), 상호적 게임플레이 등이 있고, Turn-off(재미없는 부정적요소)에는 멀티플레이에서 이미 경쟁할 수 없는데 게임을 계속해야하는 경우, 반대로 승리가 보장되었는데 계속해야하는 경우, 게임 하는데 부익부 빈익빈 현상의 가중, 재미없는 판단(항상 똑같은 행동을 요구)의 연속 등이 부정적 요소에 해당된다. 이러한 부정적 요소를 막을 수 있는 방법이 게임 발랜싱 기술이다.
  • 꾸준히 발전하게 만들어라 - 게임을 해나가는데 진전이 있어야 게이머가 즐거움을 느낌.
  • 상을 주는것을 강조하고, 벌을 주는것을 최소화하라 - 벌을 줄때 게이머들은 벌 받기전에 세이브하고 나가는 등의 cheat(속임수)를 쓴다.
  • 이미 진것으로 판단된 플레이어는 퇴장할 수 있게 해야한다. 계속 남아 훼방놓거나 누구의 편을 드는 경우가 없어야한다.
  • 모든 판단의 중요성을 주어라. 그러나 마이크로 매네지먼트(군 전체의 전략이 아닌 군인 개개인의 전략)는 위험하다. - 스타크래프트에서 초반의 판단은 중요하지만 일정한 게임이 진행된 후에는 별로 중요하지 않다. 이는 중요 판단 시점이 있어야 하는것을 의미한다. 중요하지 않은 판단(게임의 승패에 많은 영향이없는 판단)은 컴퓨터가 AI로 자동판단하게 하는게 플레이어에게 편하다.
  • 통계적으로 이길확률이 똑같게 만들어라. 그래야 상대편을 유념하고 자기의 판단을 하게 된다. 어느 하나만 높다면 플레이어는 항상 그것만 선택한다. - 스타크래프트 좋음, 디아블로 나쁨(팔라딘, 바바리안 확률높음)
  • Posted by 꿈꾸는자의 생각의파편들