'게임 개발/관리'에 해당되는 글 157건

  1. 2012/01/05 온라인 게임에서 일회성 마케팅에 대한 생각 (2)
  2. 2011/10/09 이진 파일 형상 관리 방법 (4)
  3. 2011/10/01 추가 근무는 자랑거리가 아닙니다. (2)
  4. 2011/09/10 팀 플레이어를 채용할 것 (4)
  5. 2011/07/14 위키(Wiki)는 게임 개발에 적합하지 않습니다.
  6. 2011/06/30 하나로 관리해야 하는 자료를 여러 개로 나누지 말 것
  7. 2011/06/06 원격 서비스를 명령행에서 중지하고 다시 시작하기
  8. 2011/03/19 잠수 패치는 소비자의 알 권리를 무시하는 행위
  9. 2011/03/12 게임 개발에 테스트 서버는 필수 (2)
  10. 2011/02/04 소프트웨어 개발에서 일정은 의미가 적습니다. (2)
  11. 2011/01/09 집단 지성을 활용해서 팀의 문제를 빨리 해결하기 (2)
  12. 2010/06/12 토털 사커에서 배워야 하는 팀의 운영 (2)
  13. 2010/01/17 즉흥적인 결정을 피할 것 (2)
  14. 2010/01/17 데이터 수동 입력을 줄이기 위해서 네이밍(Naming)을 활용할 것
  15. 2010/01/17 회의를 효율적으로 하는 방법
  16. 2010/01/10 기획자와 현장 고객의 비교 (2)
  17. 2010/01/09 스크럼(Scrum) 프로세스에 대한 의문 (2)
  18. 2010/01/09 퍼포스(Perforce)에서 잘못된 체인지리스트(Changelist)를 지우는 방법
  19. 2009/09/13 추정하지 말고 측정할 것 (2)
  20. 2009/09/10 TortoiseBlame을 활용해 보아요
  21. 2009/09/06 외주 결과물에 의존하는 것을 줄일 것 (2)
  22. 2009/09/06 의존적 공동 작업은 폴링(Polling) 방식이 아니라 이벤트 드리븐 (Event-Driven) 방식이 돼야 합니다 (2)
  23. 2009/08/09 TortoiseSVN에서 ignore-on-commit을 활용해서 불필요한 커밋 막기
  24. 2009/07/09 문제를 편법으로 해결하려고 하지 말고, 되도록 장기적 관점에서 접근하고 해결하세요 (2)
  25. 2009/07/04 외부 도구의 갱신 필요성을 판단하는 기준
  26. 2009/06/21 서브버전(Subversion) 저장소 일부를 다른 저장소와 동기화하는 방법
  27. 2009/06/13 서브버전(Subversion) 서버 없이 TortoiseSVN으로 로컬 저장소 만들기 (2)
  28. 2009/06/08 효율적인 소프트웨어 형상 관리 저장소 관리 방법
  29. 2009/06/07 게임에서 스크립트 언어의 올바른 활용 방안 (2)
  30. 2009/06/07 게임 리소스 파일 무결성 보장 방법 (2)
◀ 이전페이지 1 2 3 4 5 ... 6 다음페이지 ▶

온라인 게임에서 일회성 마케팅에 대한 생각

게임 개발/관리 2012/01/05 17:39
마케팅은 제품에 맞춰 실행해야 합니다. 특히 온라인 게임은 일반적인 상품과 달리 구매 결정이 한 번으로 끝나지 않기 때문에, 다른 접근 방식을 취해야 합니다. 일회성 마케팅 전략은 온라인 게임에선 잘 통하지 않습니다.

온라인 게임은 영화보다는 드라마에 가깝습니다. 영화는 재미가 없더라도 개봉 초기에 마케팅을 통해 한 번 표를 팔기만 하면 됩니다. 따라서 영화는 패키지 게임과 비슷합니다. 반면에 드라마는 아무리 마케팅을 열심히 해도 재미가 없다면 시청률이 나오지 않습니다. 따라서 드라마는 온라인 게임과 비슷합니다.

이벤트 경품 같은 일회성 마케팅 전략은 패키지 게임엔 적합할 수 있지만, 온라인 게임에서는 밑 빠진 독에 물 붓기인 바보 같은 짓입니다. 차라리 다양한 경로를 통해 인지도를 높여서, 꾸준히 신규 사용자를 끌어 오는 전략이 낫습니다. 그리고 마케팅보다는 게임의 재미를 끌어 올려 사용자 수를 유지하는 것에 더 집중해야 합니다.
2012/01/05 17:39 2012/01/05 17:39
트랙백 0개, 댓글 2개가 달렸습니다.

이진 파일 형상 관리 방법

게임 개발/관리 2011/10/09 21:41
텍스트 파일이 아닌 이진 파일은, Subversion으로 형상 관리할 때 골칫거리입니다. 워드 문서는 그나마 diff라도 쉬운 편인데, 엑셀이나 파워 포인트로 만든 문서는 diff도 보기 어렵습니다. TortoiseSVN에서 지원하지 않는 형식의 다른 이진 파일은 말할 것도 없습니다. 그런데 게임 개발할 때엔 일반적인 소프트웨어 개발과 달리 이진 파일을 많이 사용하므로 더 문제입니다.

그러므로 이진 파일 사용을 최대한 줄여야 합니다. 형식이 꼭 필요한 문서는, HTML로 저장하는 게 최선인 듯합니다. 그런 문서에 위키를 사용하는 것은 사용법이 복잡하고 형상 관리 시스템과 동기화시키기 어렵기 때문에 좋지 않습니다. 내용만 필요한 각종 속성 정의 문서는 엑셀 대신에 .xml이나 .csv로 저장하면 될 것 같습니다.

텍스트 파일로 바꿀 수 없는 이진 파일엔 lock 기능을 사용해야 합니다. Lock 기능을 사용하는 방법은 Locking에 나와 있으니, 참고하면 될 것입니다.

하지만 lock을 사용하더라도, branch와 trunk 간의 병합 시 발생하는 충돌을 막을 수는 없습니다. 따라서 이진 파일 형상 관리의 궁극적인 해법은 형상 관리 시스템에 이진 파일을 넣는 일을 줄이는 것입니다.
2011/10/09 21:41 2011/10/09 21:41
트랙백 0개, 댓글 4개가 달렸습니다.

추가 근무는 자랑거리가 아닙니다.

게임 개발/관리 2011/10/01 12:54
야근이나 주말 근무 같은 추가 근무를 하는 사람 중에 그걸 인정 받고 싶어하는 사람이 많습니다. 하지만 추가 근무는 자랑거리가 아닙니다. 추가 근무를 한다는 것은 뭔가 잘못됐다는 증거입니다.

추가 근무의 주된 원인은 다음과 같습니다.

첫째, 잘못된 일정 때문에 추가 근무를 하는 경우입니다. 이런 경우는 대개 관리자의 무리한 요구가 근본적인 원인입니다. 그런데 때론 작업자의 작업 기간 예상이 잘못돼서 발생하기도 합니다.

둘째, 불필요한 작업을 하느라고 필요한 작업을 못하는 경우입니다. 이런 경우는 작업의 목표를 잊고 자신의 욕심을 채우기 위해 불필요한 갈아엎기나 기술 연구에 시간을 소비하는 경우입니다.

셋째, 근무 시간에 다른 일을 하느라 시간을 소비한 경우입니다. 필수적인 휴식 외의 사적인 활동에 근무 시간을 상당히 소비하는 사람이 많습니다.

어떤 게 원인이든 추가 근무는 바람직하지 않습니다. 게임 개발은 최소 2년 이상 투자해야 하는 긴 작업이고, 추가 근무는 장기적으로 봤을 때 오히려 손해입니다. 그리고 적절한 보상도 이뤄지지 않는 추가 근무를 개인의 삶까지 희생해 가며 할 이유는 더더욱 없습니다.
2011/10/01 12:54 2011/10/01 12:54
트랙백 0개, 댓글 2개가 달렸습니다.

팀 플레이어를 채용할 것

게임 개발/관리 2011/09/10 15:38
게임 개발은 작업 중 대부분이 협업으로 이뤄집니다. 따라서, 반드시 협업 능력이 뛰어난 사람을 채용해야 합니다. 아무리 기술적인 능력이 뛰어나더라도 프로젝트의 성공을 위해 헌신하지 않고 개인적인 성취에만 관심이 있는 사람은, 팀에 도움이 되지 않으며 때로는 방해가 되기도 합니다.

야구나 축구에서 최고 기록을 기록 중인 스타 플레이어에게 기록에 대한 느낌을 물어 보면 대부분 같은 대답을 합니다. '내 기록엔 관심이 없고, 팀의 승리에 도움이 되고 싶다.' 그들이 그렇게 말하는 이유는, 이타적인 사람이라서가 아니라 팀의 승리가 행복을 가져다 주고 자신의 경력에도 도움이 된다는 걸 알기 때문일 것입니다.

참고로, 구글에서는 개인주의적 성향이 강한 사람도 채용한다고 합니다만, 그건 두 세 명의 프로그래머로도 작업이 가능한 경우일 것이고 게임 개발은 이제 최소 20명 이상이 협업해야 하는 큰 일입니다.

게임 개발을 할 때엔 능력이 다소 부족한 사람이더라도 팀 플레이어를 채용하는 게 좋습니다.
2011/09/10 15:38 2011/09/10 15:38
트랙백 0개, 댓글 4개가 달렸습니다.

위키(Wiki)는 게임 개발에 적합하지 않습니다.

게임 개발/관리 2011/07/14 09:52
한때 위키에 매료돼서 직접 설치도 해 보고 꽤 오랫동안 사용해 봤지만, 위키는 게임 개발엔 적합하지 않습니다.

위키의 제일 큰 장점은 공동 편집이 쉽다는 것인데, 게임 개발할 때엔 어차피 형상 관리 소프트웨어를 사용해서 문서를 관리하게 되므로 위키의 장점이 사라집니다. 더구나 위키는 사용하기 어렵고 편집 기능도 부족합니다.

팀 내 의사소통 수단이 필요하다면, 위키보다는 블로그, 게시판, 트위터, 페이스북, 이메일, 또는 메신저 등의 도구가 훨씬 낫습니다. 다른 도구로도 위키의 기능 대부분을 훨씬 쉽게 대신할 수 있습니다.
2011/07/14 09:52 2011/07/14 09:52
트랙백 0개, 댓글 0개가 달렸습니다.

하나로 관리해야 하는 자료를 여러 개로 나누지 말 것

게임 개발/관리 2011/06/30 21:52
많은 양의 자료를 관리할 때엔 실수를 최소화하는 방향으로 관리해야 하는데, 이를 위해서는 불필요한 중복을 줄이는 게 중요합니다.

아이템 등의 항목을 관리할 때, 속성을 나타내는 열의 수가 너무 많아져서 여러 개의 쉬트로 분할하는 경우도 있습니다. 하지만 이것은 좋지 못한 방법입니다. 하나로 관리해야 하는 것을 억지로 여러 개로 나누면, 자료를 추가, 삭제, 또는 변경할 때 여러 쉬트를 모두 손대야 하기 때문입니다.

관리자는 자료 관리 방식에도 신경을 많이 써야 합니다.
2011/06/30 21:52 2011/06/30 21:52
트랙백 0개, 댓글 0개가 달렸습니다.

원격 서비스를 명령행에서 중지하고 다시 시작하기

게임 개발/관리 2011/06/06 00:57
게임을 개발하다 보면, 원격 서버에 있는 여러 서비스를 다시 실행시켜야 할 때가 있습니다. 그럴 때에 다음과 같은 내용을 .cmd 파일로 만들어서 처리하면 편합니다. server_name하고 service_name엔 실제로 사용하는 값을 넣으면 됩니다.

sc \\server_name stop service_name
:stop_wait
sc \\server_name query service_name | find "STOPPED"
if errorlevel 1 goto stop_wait

sc \\server_name start service_name
:run_wait
sc \\server_name query service_name | find "RUNNING"
if errorlevel 1 goto run_wait
2011/06/06 00:57 2011/06/06 00:57
트랙백 0개, 댓글 0개가 달렸습니다.

잠수 패치는 소비자의 알 권리를 무시하는 행위

게임 개발/관리 2011/03/19 14:39
온라인 게임은 패치가 자주 이뤄집니다. 그런데, 각 패치마다 어떤 것이 변경됐는지 알리지 않는 개발 팀이 많습니다. 굳이 알릴 필요가 없다고 생각할 수도 있지만, 게임을 돈 내고 하는 사용자 입장에서 패치 내역은 꽤 중요한 정보입니다. 이렇게 중요한 정보를 공개하지 않는 것은 사용자를 무시하는 행위인 것입니다.

패치가 이뤄지면 게임이 달라집니다. 사용자는 게임을 해 보면서 패치에 적응할 수도 있지만, 패치 내역을 알고 있으면 적응이 훨씬 빠릅니다. 그리고 패치 이후 달라진 부분을 알지 못해서 손해를 보는 일도 줄어 듭니다. 뿐만 아니라, 패치에 대한 의견을 좀 더 정확하게 개발 팀에 말할 수 있게 됩니다.

흔히 어떤 게임은 잘 만들었는데 운영이 좋지 않아서 망했다는 얘기를 하곤 합니다. 그 운영에서 중요한 부분 중 하나가 업데이트이며, 패치 내역을 정확하고 구체적으로 공개하는 것은 업데이트를 잘하는 방법 중 하나입니다.
2011/03/19 14:39 2011/03/19 14:39
트랙백 0개, 댓글 0개가 달렸습니다.

게임 개발에 테스트 서버는 필수

게임 개발/관리 2011/03/12 14:35
테스트 서버는 두 가지 목적을 위해서 필요합니다. 하나는 버그를 줄이기 위해서이고, 다른 하나는 신규 개발 결과물에 대한 사용자의 반응을 얻기 위해서입니다. 그리고 그 두 가지 목적을 적은 위험과 비용으로 달성할 수 있습니다.

테스트 서버를 이용하면 다수의 사용자가 다양한 행동을 했을 때 생기는 버그를 찾을 확률이 높아집니다. 사내 테스트나 전문 QA로도 부족한 부분을 채워 줄 수 있습니다. 즉, '성당과 시장'이라는 글에서 말하는 장점을 취할 수 있는 것입니다.

사용자의 반응을 얻는 것은 버그를 줄이는 것보다 더 중요합니다. 사용자의 플레이 로그와 플레이 후기 등을 참고해서, 사용자가 원하는 쪽으로 개발 방향을 잡을 수 있습니다. 단, 테스트 서버에서 플레이하는 사용자의 성향은 일반 서버의 사용자 성향과 좀 다를 수 있다는 점도 고려해야 합니다.
2011/03/12 14:35 2011/03/12 14:35
트랙백 0개, 댓글 2개가 달렸습니다.

소프트웨어 개발에서 일정은 의미가 적습니다.

게임 개발/관리 2011/02/04 11:21
많은 사람이 소프트웨어를 개발할 때 저지르는 실수 중 하나는, 일정에 큰 의미를 두는 것입니다. 그 사람들은 소프트웨어 개발이 기계가 공장에서 제품을 찍어내는 것처럼 시간에 정확히 맞출 수 있을 거라는 기대를 하고 있습니다. 하지만, 실제로는 그렇게 될 수 없으며, 그렇게 되는 게 오히려 잘못된 것입니다.

창조적인 작업을 하는 데 시간이 얼마나 걸릴지 예측하는 것은 어려운 일입니다. 소프트웨어 개발은 기본적으로 창조적인 작업입니다. 여기서 창조적이라 함은 특별히 새로운 개념의 제품을 만드는 것을 말하는 것이 아니라, 지금까지 해 왔던 일과 똑같은 일을 하지 않음을 말하는 것입니다. 소프트웨어 개발을 할 때엔 항상 새로운 요청사항을 수용해야 하고, 기존 작업물과의 연동도 처리해야 하고, 경험해 보지 않은 기술도 적용해야 합니다.

그런데도 사람들은 기간을 억지로 정해 놓고 거기에 맞추라고 요구하는데, 이는 어리석은 행동입니다. 생산성 향상, 추가 근무, 또는 작업 축소를 하지 않고 일정을 맞추는 방법은 한 가지뿐입니다. 그건 바로, 작업물의 품질을 희생해서 작업을 최대한 빠르게 진행하는 것입니다. 하지만, 이건 프로그래밍에 있어서는 통하기 어려운 방법입니다. 프로그래밍에서는 사소한 버그 하나로 인해서 전체 소프트웨어가 동작하지 않는 때도 잦습니다. 결국, 일정에 맞추려다가 일정을 맞추지 않는 것보다 못한 결과를 가져오기 쉽습니다.

소프트웨어 개발에선 일정을 예측하는 것이 어려우며 일정을 지키려고 노력하는 것도 의미가 별로 없습니다.
2011/02/04 11:21 2011/02/04 11:21
트랙백 0개, 댓글 2개가 달렸습니다.

집단 지성을 활용해서 팀의 문제를 빨리 해결하기

게임 개발/관리 2011/01/09 00:46
집단 지성이라는 개념이 유용한데도 불구하고, 이걸 잘 활용하는 사례는 별로 없는 것 같습니다. 개발 조직에서도 집단 지성의 개념을 활용하면, 어려운 문제를 빨리 해결할 수 있습니다.

예를 들어, 어떤 심각한 문제가 생겼다고 하겠습니다. 보통은 문제를 듣고, 몇몇 관련자들만 회의에 참석해서 의견을 말하고, 그걸 토대로 그 문제에 대해서 잘 모르는 팀장이 해결책을 결정합니다. 그 해결책대로 몇몇 팀원이 문제를 해결하려고 노력하고, 안 되면 팀장이 다른 해결책을 제안합니다. 이런 방식으로 문제를 접근하면, 문제를 다양한 각도에서 접근할 수 없고 진행 과정이 오래 걸려서 좋지 않습니다.

하지만 집단 지성을 활용하면 달라집니다. 어떤 문제에 대해서 팀의 여러 사람들이 의견을 나누되, 각자 시간을 내서 독립적으로 문제 해결을 시도합니다. 하지만 다른 사람이 어떻게 접근하는지도 서로 보면서, 접근 방법을 계속 개선합니다. 결국 문제를 다수의 사람이 병렬적으로 접근하기 때문에, 문제는 좀 더 빨리 해결될 수 있습니다. 참고로, 병렬적으로 접근할 수 없는 문제라면, 다수의 사람이 투표를 통해 해결 방향을 정하면 됩니다.

집단 지성의 활용을 멀리에서 찾을 것이 아니라, 주변부터 찾으려고 노력해야 합니다.
2011/01/09 00:46 2011/01/09 00:46
트랙백 0개, 댓글 2개가 달렸습니다.

토털 사커에서 배워야 하는 팀의 운영

게임 개발/관리 2010/06/12 14:47
지금은 압박 축구로 변형되긴 했지만, 토털 사커는 현대 축구에 새로운 방향을 제시한 전술입니다. 우리는 토털 사커에서 특히 포지션의 개념이 약화됐다는 것에 주목해야 합니다.

공격수는 공격만 하고, 수비수는 수비만 하는 축구는 효율적이지 못합니다. 공격할 때엔 체력 부담을 낮추면서 역습을 대비할 수 있는 정도로만 수비를 하고, 되도록 많은 사람이 공격에 참여하는 게 훨씬 효율적입니다. 반대로, 수비할 때엔 공격수도 전방에서부터 압박을 해 줘야 효율적입니다.

게임 개발에서 팀의 운영도 마찬가지입니다. 기획을 할 때엔 많은 팀원이 다양한 아이디어를 내고, 기획자는 수집한 아이디어를 토대로 기획서를 작성하며, 프로그래머와 아티스트가 작업자 입장에서 문제점을 미리 검토하고, QA가 게이머 입장에서 사용성도 검토해야 효과적입니다. 기획뿐만 아니라 프로그래밍, 그래픽, 그리고 테스트도 모두 마찬가지입니다. 각자의 역할이 중요한 게 아니라, 지금 팀이 무슨 일에 집중해야 하는가가 중요한 것입니다.

하지만, 아직도 많은 팀이 기획자는 기획만 하고, 프로그래머는 코딩만 하고, 아티스트는 그래픽 작업만 하며, QA는 테스트만 합니다. 이렇게 각자의 권한과 책임을 지나치게 강조하면, 다른 파트의 도움을 받을 수 없게 됩니다.

전역적 최적화를 고려하지 않는 부분적 최적화는 좋지 않습니다. 팀은 개인을 단순히 모아 놓은 집합이 아니라, 한 목표를 향해 일사불란하게 움직이는 하나의 덩어리가 돼야 합니다.
2010/06/12 14:47 2010/06/12 14:47
트랙백 0개, 댓글 2개가 달렸습니다.

즉흥적인 결정을 피할 것

게임 개발/관리 2010/01/17 21:20
결정을 서둘지 말라. 하룻밤을 자고 나면 좋은 지혜가 생긴다. - 푸시킨
게임 개발을 하다 보면, 어떤 일을 결정해야 할 때가 잦습니다. 그런데 이런 상황에서 주의 깊게 생각해 보지도 않고 결정을 내리는 것은 좋지 않습니다. 생각은 즉흥적으로 할 수 있지만, 그 생각을 실제 행동으로 옮기는 것엔 신중해야 합니다. 왜냐하면 한 번 행동으로 옮긴 것을 되돌리는 것은 생각을 바꾸는 것보다 훨씬 어렵기 때문입니다. 즉흥적인 결정 뒤엔 언제나 후회가 뒤따릅니다.
2010/01/17 21:20 2010/01/17 21:20
트랙백 0개, 댓글 2개가 달렸습니다.

데이터 수동 입력을 줄이기 위해서 네이밍(Naming)을 활용할 것

게임 개발/관리 2010/01/17 20:45
네이밍이 무엇인지 아는 사람은 많지만, 네이밍을 어떻게 활용해야 좋을지 아는 사람은 드문 듯합니다. 데이터 관리에서 네이밍이 효과를 제일 발휘할 때는, 손으로 입력하는 것을 줄이는 것입니다.

예를 들어, 아이디가 A라는 무기가 있다고 하겠습니다. 이 무기의 이름은 big sword이고, 메쉬는 big_sword_mesh.mesh, 아이콘 이름은 big_sword_icon.tga입니다. 이 무기를 관리하려면 위의 값을 따로 입력해서 어딘가에 파일로 저장해 두어야 합니다. 무기가 한 두 개라면 상관 없겠지만, 무기 수가 늘어날수록 관리해야 할 데이터가 계속 늘어나게 됩니다. 더 큰 문제는 데이터가 늘어나면 그만큼 실수도 늘어난다는 것입니다.

위의 예에서 발생하는 문제를 쉽게 해결하려면 네이밍을 사용하면 됩니다. 메쉬는 .mesh를, 아이콘 이름은 .tga를 아이디에 붙여서 표현한다라고 정하면, 별도의 파일에 메쉬 이름과 아이콘 이름을 기록할 필요가 없습니다. 위의 예에선 각각 A.mesh, A.tga가 되겠습니다. 아이디 대신에 무기의 이름을 활용하면 이해하기 더 쉽겠지만, 파일 이름으로 표현하기 어려운 이름이 많으므로 논의를 통해 결정하는 게 좋습니다.

프로젝트 관리의 핵심은 덜 중요한 일에 자원을 적게 할당하고, 더 중요한 일에 자원을 많이 할당하는 것입니다. 네이밍은 그런 일을 가능하게 하는 방법 중 하나입니다.
2010/01/17 20:45 2010/01/17 20:45
트랙백 0개, 댓글 0개가 달렸습니다.

회의를 효율적으로 하는 방법

게임 개발/관리 2010/01/17 13:56
어떤 조직이 효율적으로 운영되는지 판단하려면, 회의에 참가해 보면 쉽게 알 수 있습니다. 회의 과정이 비효율적인 조직은 업무도 비효율적으로 처리할 가능성이 높습니다. 최근에 회의를 자주 참석해 보면서, 어떻게 하면 회의를 효율적으로 할 수 있을지 생각해 봤습니다.

첫째, 의제를 명확하고 결과 지향적으로 정해야 합니다. 대부분 회의가 단지 지식 공유를 목적으로 소집되는데, 이것은 명백한 시간 낭비입니다. 회의에 참석하는 사람은 각자 지식에 대한 이해도가 다릅니다. 그런데, 이해가 덜 된 사람을 위해서 이미 내용을 이해하고 있는 사람까지도 계속 참석해 있어야 합니다. 지식을 공유하는 목적이라면, 회의가 아니라 문서를 통해 각자 필요한 부분을 읽어 보게 해야 합니다. 긴급하고 필수적인 내용을 공유해야 한다면 회의 외에는 좋은 방법이 없습니다. 하지만, 그렇지 않을 때가 대부분입니다. 회의는 결정을 내리는 데에만 주로 쓰여야 합니다.

둘째, 아무에게나 발언권을 주면 안 됩니다. 회의를 하다 보면 몇몇 사람만 계속 얘기를 하고, 다른 사람은 듣고만 있게 됩니다. 이건 전적으로 회의 진행자의 실수입니다. 회의에선 모든 사람이 공평한 발언 기회를 갖되, 필요 이상으로 얘기를 많이 하지 않도록 조정해야 합니다. 개인당 발언 시간 제한을 두는 방법이 제일 나을 것입니다.

셋째, 회의 내용에 대해서 사전에 문서 공유를 해야 합니다. 회의에 참석해서야 회의의 내용을 알게 되는 것은 참가자가 미리 준비를 하지 못하게 되는 단점이 있을 뿐만 아니라, 회의 시간이 회의 내용을 이해하느라 소모된다는 단점까지 있습니다. 사전에 모두가 알고 있어야 하는 내용은 미리 전달해 주고, 회의 도중에 생각나는 것은 회의 때에 이야기하는 식이 돼야 합니다.

넷째, 회의와 관련 있는 얘기만 하도록 해야 합니다. 회의를 하다 보면 의제와 전혀 무관하거나 당장은 필요 없는 얘기가 종종 나옵니다. 그런 얘기가 도움이 될 수는 있지만, 의제에 대한 집중도를 떨어트리고 회의에서 다뤄야 할 중요할 내용을 제대로 다루지 못하게 만드는 문제가 생깁니다.

다섯째, 자세한 얘기는 당사자끼리 얘기하도록 해야 합니다. 회의 시간에 모두가 들을 필요가 없는 얘기는 관련된 당사자끼리 따로 모여서 얘기하는 게, 모두의 시간을 조금이라도 덜 낭비하게 만듭니다.

여섯째, 회의 진행 도중의 기록을 반드시 남겨야 합니다. 회의를 하면 아무 기록도 남기지 않고 얘기만 하다가 끝나는 때가 잦습니다. 회의를 했다면 반드시 어떤 기록이 남아서 업무에 활용돼야 합니다.

관리자는 어떻게 하면 회의를 효과적으로 진행할 수 있을지 계속 고민해야 합니다.
2010/01/17 13:56 2010/01/17 13:56
트랙백 0개, 댓글 0개가 달렸습니다.

기획자와 현장 고객의 비교

게임 개발/관리 2010/01/10 13:56
익스트림 프로그래밍(Extreme Programming)의 현장 고객에서 생각을 따와서, 기획자를 현장 고객으로 생각할 수 있습니다. 하지만, 기획자는 일반 고객과 약간 다른 성격을 갖고 있으므로, 그대로 적용하는 것은 어려워 보입니다.

일반적으로 고객은 돈을 지불하는 역할을 합니다. 고객이 생산자에게 원하는 것을 말하면, 생산자는 그것을 생산하는 데에 필요한 비용과 시간을 답해 줍니다. 고객은 생산자의 답변을 참고해서, 그에 맞는 돈을 지불합니다. 그런데 여기서 돈에 관련된 문제는 전적으로 고객의 책임입니다. 예를 들어, 위험 요소가 많다는 답변을 듣고도 돈을 지불했다면, 그 돈을 날리는 것은 고객이 감수한다는 것입니다. 고객 자신이 원하는 것을 충분히 설명하지 않았거나 잘못 설명해서 엉뚱한 물건이 나온다면, 그 또한 고객의 책임입니다.

그런데, 일반적으로 게임 기획자는 결과에 대해 책임을 많이 지지 않습니다. 위험 요소가 많다는 답변을 듣고도 강행한 후에 결과가 잘못돼도, 기획자는 책임을 떠안지 않습니다. 그리고 자신이 원하는 기획을 정확하고 구체적으로 표현하지 않아서 생기는 문제에 대해서도 책임을 지지 않습니다. 실제로 프로젝트에 문제가 생겼을 때 영향을 받는 것은 개발 팀 전체입니다. 이렇다 보니, 기획자는 기획에 대해 책임감을 강하게 느끼기 어렵고, 신중한 결정을 하질 않게 되는 것입니다. 이건 기획자 개인의 문제라기보다는 게임 개발 체계의 문제입니다.

하지만 프로그래머가 기획을 간섭하려 하는 것은 좋지 않다고 봅니다. 기획자의 요구에 대해 예상되는 문제점과 필요한 자원을 정확히 알려 주는 것에 중점을 두어야 할 것입니다. 기획자에게 충분한 정보를 주었음에도 불구하고 일이 잘못된 방향으로 전개된다면, 관리자의 협조를 얻어 함께 조율하는 게 나을 것입니다. 만약 관리자마저도 잘못된 결정을 한다면, 다른 팀이나 회사를 알아보는 게 나을 것입니다.
2010/01/10 13:56 2010/01/10 13:56
트랙백 0개, 댓글 2개가 달렸습니다.

스크럼(Scrum) 프로세스에 대한 의문

게임 개발/관리 2010/01/09 21:09
제가 있는 팀에서는 현재 어떤 정형화된 소프트웨어 개발 프로세스도 도입해서 쓰고 있지 않습니다. 전에 다른 회사에서 스크럼 프로세스를 경험해 본 적이 있는데, 장점도 있지만 단점도 많았습니다. 다른 분야로부터 도입된 여러 소프트웨어 방법론이 대부분 그렇듯이, 스크럼 프로세스도 소프트웨어 개발, 특히 게임 개발엔 왠지 부적합해 보입니다.

스크럼 프로세스에선 일정 기간 단위로 스프린트라는 것을 정해서 계획을 미리 잡아 두라고 합니다. 그런데 게임 개발에서 30일 단위로 할 일을 정하고 일정을 정하는 게 과연 의미가 있을까요? 일정을 고정시키면 변화하는 상황에 빠르게 대처할 수 없고, 반대로 일정을 바꾸면 계획의 의미가 퇴색됩니다. 개발을 진행하다 보면 무수한 변수가 발생해서, 일정을 언제나 수정해야 할 때가 대부분입니다.

스프린트 첫날에 일정을 잡는 게 과연 정확할까요? 충분한 사전 정보 없이 일정을 잡는 게 큰 의미가 있을까요? 구현하다 보면 예상치 못한 문제가 생기기 마련이고, 그 문제를 해결하는 데 얼마나 시간이 걸릴지는 아무도 모릅니다. 따라서 스프린트 첫날에 비교적 정확한 일정을 잡는다는 것은 불가능에 가깝습니다.

스크럼 프로세스에선 회의를 매일 하기를 권장합니다. 그런데 그게 과연 큰 의미가 있을까요? 필요할 때마다 참석해야 하는 사람끼리 모여서 회의를 하는 게 낫지 않을까요? 특별한 의제 없이 회의를 한다는 것은 시간 낭비입니다.

스크럼 프로세스에선 스프린트 단위로 결과를 공개하고 회고하기를 주장합니다. 이것도 역시 필요할 때마다 공개하는 게 나아 보입니다. 외부의 요청이 있을 때 즉시 공개할 준비는 언제나 돼 있어야 하는 것이고, 반면에 회고는 필요할 때마다 하면 충분해 보입니다.

스크럼에선 스프린트 단위로 한 가지 목표를 정하라고 하는데, 별로 의미가 없습니다. 한 달 단위로 어떤 목표를 세우기가 애매합니다. 왜냐하면, 한 달 동안 한 가지 큰 일조차 못할 수도 있고, 많은 중요한 일을 할 수도 있기 때문입니다.

스크럼 프로세스에 대해 전체적으로 생각해 보면, 고정 생산 분야에나 적합한 방식을 연구 개발 위주의 소프트웨어 분야에 무리하게 적용시킨 것 같습니다.
2010/01/09 21:09 2010/01/09 21:09
트랙백 0개, 댓글 2개가 달렸습니다.

퍼포스(Perforce)에서 잘못된 체인지리스트(Changelist)를 지우는 방법

게임 개발/관리 2010/01/09 20:48
퍼포스를 사용하다 보면, 대기 중인 체인지리스트가 불필요하게 남아 있을 때가 가끔 있습니다. 이걸 지우려면 콘솔 명령 창(cmd.exe)을 열어서 다음처럼 하면 됩니다.

p4 change -d [번호]
예: p4 change -d 1000

참고: p4 change
2010/01/09 20:48 2010/01/09 20:48
트랙백 0개, 댓글 0개가 달렸습니다.

추정하지 말고 측정할 것

게임 개발/관리 2009/09/13 10:54
어떤 문제를 해결하려고 할 때, 추정에 의존하는 방법은 되도록 피해야 합니다. 추정은 틀릴 확률이 높기 때문에, 측정에 드는 노력 대비 효과가 작을 때에만 사용하는 게 좋습니다.

측정이 추정보다 유용한 대표적인 예로, 게임 밸런스 조정을 들 수 있습니다.

대부분 기획자는 자신의 생각을 근거로 밸런스를 조정하려고 합니다. 하지만, 그렇게 해서는 게이머가 실제로 원하는 밸런스를 맞추기가 어렵습니다. 그렇다고 게시판 글이나 QA 담당자 의견에 따르는 것도 좋지 않습니다. 대체로 게시판의 글은 소수의 적극적인 사람에 의해 쓰여지기 때문에 일반 게이머의 생각과 차이가 크고, QA 담당자의 의견도 일반 게이머의 의견과 다를 확률이 높기 때문입니다.

이럴 때 제일 좋은 방법은 실제 게이머의 플레이 과정을 기록해서 분석하는 것입니다. Valve’s Approach to Playtesting: The Application of Empiricism를 보면 이런 방법이 잘 소개돼 있습니다. 그 글에 따르면, 단순히 게임 데이터만 분석하는 게 아니라, 신체적인 변화까지 분석한다고 하는군요.

측정하고 분석할 자원이 부족하거나 측정이 아예 불가능할 때가 아니라면, 대체로 측정이 추정보다 낫습니다.
2009/09/13 10:54 2009/09/13 10:54
트랙백 0개, 댓글 2개가 달렸습니다.

TortoiseBlame을 활용해 보아요

게임 개발/관리 2009/09/10 10:22
TortoiseSVN을 사용하다 보면, 파일의 어떤 부분을 누가 수정했는지 보고 싶을 때가 종종 있습니다. 이때 로그를 다 검색해 가면서 바뀐 부분을 찾는 것은 비효율적입니다. 이럴 땐 TortoiseBlame이라는 도구를 사용하면 편합니다. TortoiseBlame을 사용하려면, 탐색기에서 마우스 오른쪽 단추 클릭하고 TortoiseSVN을 고른 다음에 Blame...을 고르면 됩니다. 참고로, 실행한 다음에 왼쪽 Revision Author 목록 위에서 마우스 오른쪽 단추를 클릭하면, 추가적으로 유용한 기능이 더 있습니다. 
2009/09/10 10:22 2009/09/10 10:22
트랙백 0개, 댓글 0개가 달렸습니다.

외주 결과물에 의존하는 것을 줄일 것

게임 개발/관리 2009/09/06 10:38
외주는 좀 더 적은 비용으로 결과를 얻기 위해 사용됩니다. 하지만, 비용만 아끼려고 외주를 하다 보면, 자체 개발보다 손해가 오히려 많이 생깁니다. 특히 문제가 되는 것은 외주 결과물에 의존하는 다른 작업이 많을 때입니다.

효과음이나 배경음을 외주 업체에 맡기는 것은 대체로 현명한 선택입니다. 왜냐하면 효과음이나 배경음이 잘못되더라도 그것에 의존적인 부분이 없어서, 다른 작업은 그대로 진행할 수 있기 때문입니다. 최악의 경우엔 해당 소리를 아예 빼 버리거나 임시 파일로 대체해도 문제가 없습니다.

하지만, 게임 UI에 사용할 플래시 액션스크립트를 외주로 처리하는 것은 좋은 선택이 아닙니다. 왜냐하면, C++ 코드는 해당 액션스크립트에 의존적이라서, 액션스크립트가 잘못되면 C++ 코드도 정상적으로 동작하지 않기 때문입니다. 게다가 외주의 특성상, 문제를 발견했을 때 빠르게 대처하는 게 불가능합니다. 그렇다고 UI 액션스크립트를 제거하거나 임시 데이터로 대체할 수 있는 것도 아닙니다. 또, 액션스크립터와의 의사소통에 소모되는 C++ 프로그래머의 시간, 그리고 부정확한 의사 전달에 따른 문제까지 고려하면, 단점이 생각보다 많습니다.

그렇다면 외부 라이브러리나 게임 엔진 등도 외주와 비슷한 개념인데, 이것은 어떻게 봐야 할까요? 이건 좀 다릅니다. 어떤 기능을 항상 추가하거나 수정하므로 문제가 많이 생기는 외주와 달리, 외부 기술을 있는 그대로 도입하는 것은 크게 문제가 되지 않습니다. 해당 기술에 의존적이긴 하지만, 해당 기술은 변경해야 할 경우가 대체로 드뭅니다. 따라서 외부 기술을 사용하는 팀은 외부 기술의 작업 상황과 무관하게 자신의 작업을 할 수 있습니다.

외주를 도입하려고 한다면, 단지 비용만 생각하지 말고 그 이상의 문제도 생각해 봐야 합니다.
2009/09/06 10:38 2009/09/06 10:38
트랙백 0개, 댓글 2개가 달렸습니다.

의존적 공동 작업은 폴링(Polling) 방식이 아니라 이벤트 드리븐 (Event-Driven) 방식이 돼야 합니다

게임 개발/관리 2009/09/06 10:06
일을 하다 보면 여러 작업자가 함께 일해야 할 때가 있습니다. 그런데 그 과정에서 한 사람의 작업이 끝나야, 다른 사람이 그 작업물을 이용해 어떤 일을 할 수 있는 때가 잦습니다. 이럴 때 한 사람의 작업이 끝나면, 그 작업자가 다른 작업자에게 완료 여부를 즉시 통보하는 게 좋습니다.

이렇게 하지 않으면, 다른 작업자는 자신이 필요로 하는 작업물이 나왔는지 주기적으로 확인하는 낭비가 생깁니다. 그렇다고 작업 확인 주기를 늘리면, 작업 연계 처리가 그만큼 늦어져 버립니다.

이렇듯 폴링 방식으로 공동 작업을 하면 비효율적이므로, 이벤트 드리븐 방식으로 공동 작업을 하는 게 좋습니다.
2009/09/06 10:06 2009/09/06 10:06
트랙백 0개, 댓글 2개가 달렸습니다.

TortoiseSVN에서 ignore-on-commit을 활용해서 불필요한 커밋 막기

게임 개발/관리 2009/08/09 15:37
템플릿 역할을 하기 위해서 저장소에 등록된 파일이지만, 로컬에서 수정한 내용을 커밋하지 말아야 하는 파일도 있습니다. 예를 들면 로컬용 정보(IP, 아이디, 암호, 기타 옵션 등)가 담긴 설정 파일(.ini, .xml 등)이 이에 해당합니다.

전에는 이런 파일을 저장소에 등록하는 일을 항상 피하려고 노력했습니다. 그렇게 하면 잘못 커밋된 파일 때문에 다른 사람이 문제가 생기는 일은 없지만, 설정 파일 형식이 바뀌었을 때 자동으로 갱신이 안 되니 설정 파일 형식이 맞지 않게 되는 문제가 있었습니다.

그런데 언젠가부터 TortoiseSVN에 ignore-on-commit이라는 기능이 생겨서, 이젠 그렇게 하지 않아도 되니 편합니다. 이 기능을 사용하려면 커밋 대화 상자의 파일 이름 위에서 마우스 오른쪽 버튼 클릭해 컨텍스트 메뉴를 띄우고 'Move to changelist'를 선택한 다음에 'ignore-on-commit'을 선택하면 됩니다.
2009/08/09 15:37 2009/08/09 15:37
트랙백 0개, 댓글 0개가 달렸습니다.

문제를 편법으로 해결하려고 하지 말고, 되도록 장기적 관점에서 접근하고 해결하세요

게임 개발/관리 2009/07/09 01:33

어떤 사람은 문제를 정공법으로 공략하려고 하지 않고, 지금 당장 쉽고 편해 보이는 방법으로 해결하려고 합니다. 재치가 있다거나 영리하다는 평가를 받는 사람이 대개 이런 경향을 갖습니다. 이런 사람이 제안하는 방법을 관리에 도입하면 나중에 상당히 골치 아파집니다.

임시방편은 그 순간엔 유용한 해결책이 될 수 있습니다. 하지만, 임시방편은 시간이 지날수록 아무것도 하지 않는 것보다 못하게 되는 때가 잦습니다. 문제는 되도록 장기적 관점에서 접근해서 근본적인 부분을 해결해야 합니다. 임시방편은 어디까지나 임시로 쓰여야 합니다.

문제를 해결하는 방법을 선택하는 기준은, 어떤 방법이 지금 당장 제일 편한가가 아니라, 어떤 방법이 제일 합리적인가입니다.

2009/07/09 01:33 2009/07/09 01:33
트랙백 0개, 댓글 2개가 달렸습니다.

외부 도구의 갱신 필요성을 판단하는 기준

게임 개발/관리 2009/07/04 19:58

게임 개발을 하다 보면, 외부에서 제작한 도구를 많이 사용하게 됩니다. 예를 들어, 컴파일러, 그래픽 소프트웨어, 게임 엔진, 그리고 기타 라이브러리 등입니다. 이런 도구는 새 버전이 계속 나오는데, 과연 새 버전을 계속 적용해야 하는지 판단하기 어렵습니다. 이럴 때엔 제일 많은 사람이 사용 중인 버전으로 계속 갱신하는 게 좋습니다.

외부 도구를 지속적으로 갱신하면 다음과 같은 장점이 있습니다. 지원을 쉽게 받을 수 있고, 필요한 기능이 이미 구현돼 있을 수 있으며, 최적화나 버그 수정이 더 돼 있을 수도 있습니다. 반면에 외부 도구를 갱신하지 않으면 다음과 같은 장점이 있습니다. 예상치 못한 부분에서 문제가 생길 확률이 적고, 커스터마이제이션(customization)이 좀 더 쉬우며, 손에 익숙하므로 생산성이 높습니다.

위와 같이 어느 방식이 항상 더 낫다고 말할 순 없어서, 프로젝트의 상황에 따라 결정하는 게 바람직합니다. 하지만, 기본적으로는 제일 다수가 사용하는 버전을 그대로 따라가는 게 장기적으로 봤을 때 편합니다. 장기적으로 볼 때엔 유지보수라는 측면이 제일 중요한데, 어떤 버전이 얼마나 지원을 쉽게 받을 수 있고 얼마나 다수의 개발자가 그 일을 할 수 있는지 생각해 보면, 왜 다수가 사용 중인 버전을 따라가는 게 좋은지 알 수 있습니다.

2009/07/04 19:58 2009/07/04 19:58
트랙백 0개, 댓글 0개가 달렸습니다.

서브버전(Subversion) 저장소 일부를 다른 저장소와 동기화하는 방법

게임 개발/관리 2009/06/21 00:05

저장소의 내용 일부를 외부 저장소에 그대로 반영시켜야 할 때가 있습니다. 예를 들면, 개발팀의 소프트웨어를 QA팀에 제공한다든지 할 때입니다. 이런 일을 할 때에도 어떤 방법이 가장 효율적일지 생각해 봐야 합니다.

우선 이럴 때 접근 권한을 어떻게 할 것인지 정해야 합니다. 예를 들어, 개발팀의 저장소를 열어 주고 QA팀에게 읽기 권한만 줄 수도 있을 것이고, QA팀에게 저장소를 열어 달라고 하고 쓰기 권한을 얻을 수도 있을 것입니다. 전자의 방법을 채택하면 동기화를 고민할 필요가 없으니까 제일 좋습니다. 여기서는 후자의 방법을 채택해야만 하는 상황을 가정합니다.

동기화 방법으로 제일 쉽게 떠오르는 것은 변경된 파일을 모았다가 QA팀의 저장소에 복사하고 직접 커밋하는 방법일 것입니다. 하지만 이 방법은 변경된 파일 목록을 일일이 관리해야 하는 문제가 있으므로 추천하지 않습니다.

대안은 서브버전이 관리해 주는 변경된 파일 목록을 이용해 합병(merge)을 사용하는 방법입니다. 이 방법은 개발팀에서 QA팀에게 최신 소프트웨어를 항상 제공하고 싶지는 않을 때 좋습니다. 개발팀에서 소프트웨어를 넘겨 줘야 할 때마다 QA팀 저장소에 합병하면 됩니다.

만약 QA팀이 개발팀의 최신 버전을 항상 자동으로 얻고 싶어 한다면, 서브버전의 external 기능을 사용하면 됩니다. 동기화가 자동으로 되므로, 특별한 문제가 없다면 이 방법이 좋겠습니다.

2009/06/21 00:05 2009/06/21 00:05
트랙백 0개, 댓글 0개가 달렸습니다.

서브버전(Subversion) 서버 없이 TortoiseSVN으로 로컬 저장소 만들기

게임 개발/관리 2009/06/13 21:54

형상 관리를 하려면 대개 서버 애플리케이션을 설치해야 하는 번거로움이 있습니다. 하지만 TortoiseSVN을 사용하면, 서버를 설치하지 않고도 로컬 저장소를 만들고 형상 관리를 할 수 있습니다. 이 기능은 개인적으로만 사용하는 자료가 있는데, 백업만으로는 충분하지 않고 버전 관리를 해야 하는 파일이 있을 때 유용합니다.

로컬 저장소를 만드려면 탐색기에서 마우스 오른쪽 버튼 클릭으로 컨텍스트 메뉴를 띄운 다음에 'Create Repository here...'를 선택하면 됩니다. 로컬 저장소의 경로는 file:///D:/work와 같은 형태입니다. (\가 아니라 /입니다.) 자세한 사용법은 Chapter 3. The Repository을 참고하시면 됩니다.

2009/06/13 21:54 2009/06/13 21:54
트랙백 0개, 댓글 2개가 달렸습니다.

효율적인 소프트웨어 형상 관리 저장소 관리 방법

게임 개발/관리 2009/06/08 23:06
요즘은 개발팀 대부분이 소프트웨어 형상 관리(Software Configuration Management) 도구를 사용하고 있지만, 제대로 활용하고 있는 곳은 드뭅니다. 프로젝트를 효율적으로 관리하고 싶으면, 형상 관리를 효율적으로 하는 방법을 알아 두어야 합니다. 제가 좋다고 느끼는 원칙과 방법을 아래에 적어 보겠습니다.

기본적으로, 하나의 형상 관리 저장소에 들어가야 할 자료는 해당 소프트웨어의 빌드에 필요한 모든 자료입니다. 소스 코드(.cpp, .h, .sln 등), 모델링 데이터 원본(.max 등), 이미지 데이터 원본(.jpg, .png, .psd등), 각종 기획 문서(.doc, .xls 등), 소스 코드가 없는 라이브러리 파일(.dll, .lib 등), DB 스키마 등 해당 소프트웨어를 빌드하고 유지보수할 때 필요한 모든 자료를 다 넣어야 합니다. 소스 코드를 제외한 데이터의 원본을 저장소에 넣지 않는 개발팀이 많은데, 이러면 나중에 데이터를 수정해야 할 때 원본이 없어서 수정을 못 하는 불상사가 생깁니다. 하지만, 빌드에 필요한 각종 외부 소프트웨어는 버전 관리가 필요없고 용량만 많이 차지하므로 저장소에 넣지 말아야 합니다. 그런 소프트웨어는 다른 파일 공유 서버에 보관하고 링크만 저장소에 넣어 두는 게 좋습니다.

배포용 데이터가 모여 있는 폴더엔 원본을 넣지 말아야 합니다. 원본을 넣어 놓으면 사용자에게 공개할 우려가 있고, 나중에 배포할 때 불필요한 파일을 걸러 내는 작업을 해야 하는 번거로움도 생깁니다.

브랜치(branch)는 소프트웨어 개발에서 필요악입니다. 브랜치에서의 작업이 적으면 적을수록 관리하기 좋습니다. 게임 개발에서는 텍스트 파일이 아닌 이진 파일을 병합해야 하는 일이 자주 발생하는데, 이진 파일을 병합하는 것은 어렵습니다. 그러므로, 게임 개발 시엔 브랜치 사용을 더더욱 최소화해야 합니다. 하지만 그렇다고 브랜치 없이 개발을 진행하는 것은 거의 불가능합니다.

브랜치는 최소한 하나는 있어야 합니다. 그건 배포용 브랜치입니다. 배포용 브랜치는 QA를 진행하고 거기서 발생한 문제를 수정하기 위해서 필요합니다. Trunk(주 개발 버전)에서 기능 추가가 끝나면, 배포용 브랜치로 병합합니다. 배포용 브랜치에서 QA를 통과하면 실제로 배포합니다. 각 브랜치의 수정은 수정이 완료될 때마다 주 개발 버전으로 병합해야 합니다. 주기적으로 자동 병합하게 하는 것도 좋겠습니다. 참고로, 게임은 두 가지 버전을 동시에 관리할 일이 거의 없으므로, 1.0이나 2.0 등으로 배포용 branch의 이름을 정하지 말고 release라고 간단히 정하면 됩니다.

브랜치와 트렁크 간의 동기화는 별도로 작업하지 말고 병합 기능을 활용해야 합니다. 병합 기능을 활용하면 실수를 줄일 수 있고 서로 다른 부분도 쉽게 파악이 가능합니다.

빌드를 통해 만들어 낼 수 있는 파일은 저장소에 올리지 않는 게, 저장소 용량을 아낄 수 있고 충돌이 생기지 않으므로 좋습니다. 하지만 예외적으로, 파일 패킹 등의 추가 과정을 거쳐야 최종 배포본을 얻을 수 있을 때엔 최종 결과물도 저장소에 올려 놓는 게 편합니다. 사내 QA 팀 등에 실제 사용자의 것과 최대한 비슷한 배포본을 빠르게 배포할 수 있기 때문입니다. 그런데 큰 파일을 올려 놓으면 저장소의 크기가 너무 커지는 게 아닌가 걱정할 수 있습니다. 하지만 서브버전 등의 소프트웨어는 파일의 변경 사항만 누적 기록하는 방식을 쓰므로, 파일 내용이 버전마다 많이 바뀌지 않는다면 크게 문제가 되지 않습니다.

빌드로 생성 가능한 실행 파일도 저장소에 넣지 않는 게 원래 원칙입니다. 하지만 시험용으로 배포할 때 실행 파일도 같이 받을 수 있게 하면, 실행 파일과 데이터의 버전이 안 맞을 우려도 없고 배포하기도 편해서 좋습니다. 따라서 로컬 빌드된 실행 파일이 위치할 폴더를 하나 만들고, 빌드 서버가 배포할 실행 파일을 커밋할 폴더는 따로 두는 게 좋습니다. 예를 들어, 빌드된 실행 파일이 위치할 폴더가 local_binary라면 빌드 서버가 배포할 실행 파일 폴더는 binary로 하면 됩니다. 데이터 참조는 "../data" 식으로 똑같이 참조할 테니 문제가 없습니다.

배포할 버전은 branch에 tag를 달아서 나중에 쉽게 얻을 수 있도록 해 둬야 합니다. 버전 이름은 배포 제품 용도, 날짜, 그리고 SVN 리비전을 조합해 만들어 두면 찾기 쉽습니다. 예를 들어, 오픈 베타 테스트용 버전이고 2001년 1월 1일에 SVN 리비전 3420으로 만들었다면, Korea.OBT.2001.1.2.3420처럼 하면 됩니다.

참고:
2009/06/08 23:06 2009/06/08 23:06
트랙백 0개, 댓글 0개가 달렸습니다.

게임에서 스크립트 언어의 올바른 활용 방안

게임 개발/관리 2009/06/07 00:35

요즘 게임 개발자는 스크립트 언어를 많이 사용하고 있습니다. 문제는 스크립트 언어를 남용하는 때가 적지 않다는 것입니다.

스크립트 언어를 프로그래머만 사용하고 편집이나 디버깅이 까다롭다면, 스크립트 언어 사용의 큰 장점을 살리지 못하는 것입니다. 게임 개발에서 스크립트 언어를 사용하는 최대 장점은, 프로그래머가 아닌 사람이 게임 로직을 제어할 수 있다는 것입니다. 이 장점을 살리지 못하는 스크립트 사용은, C++ 대신에 다른 언어를 사용하는 것일 뿐입니다. 프로그래머만 스크립트 언어를 사용한다고 해도, 빌드와 게임 로딩에 걸리는 시간을 줄인다거나 코드가 간결해지는 장점이 있을 수도 있습니다. 하지만 낯선 언어, 기능이 부족한 편집기와 디버거, 그리고 C++과의 연동 작업 등을 고려하면, 단점이 더 많습니다.

텍스트 데이터 표현을 스크립트 언어로 하는 것도 스크립트 남용의 좋은 예입니다. 스크립트 언어는 로직을 제어하는 데에만 써야 합니다. 텍스트 데이터 표현엔 XML이나 엑셀 문서 등의 좋은 포맷이 많이 있습니다.

스크립트 언어는 분명히 장점을 갖고 있지만, 단점이 더 많은 일에도 스크립트 언어를 사용하는 것은 좋은 선택이 아닙니다.

2009/06/07 00:35 2009/06/07 00:35
트랙백 0개, 댓글 2개가 달렸습니다.

게임 리소스 파일 무결성 보장 방법

게임 개발/관리 2009/06/07 00:16
게임은 일반적인 소프트웨어와 달리, 리소스 파일이 많이 필요합니다. 리소스 파일 내의 리소스는 유효한 형식이 정해져 있습니다. 그런데 유효하지 않은 값을 실수로 집어넣어서 문제가 생기는 때가 잦습니다.

무효한 자료 입력을 막는 제일 좋은 방법은 입력 시 무효한 값을 입력할 수 없게 원천봉쇄하는 것입니다. 엑셀(Excel)이나 액세스(Access)에서는 필드 값의 범위를 정할 수 있고, VBA를 써도 유효성 검사를 할 수 있다고 합니다. 써 보진 않았지만, XML에서도 스키마를 이용하면 유효성 검증이 된다고 합니다.

두 번째로 고려해야 할 방법은 유효성 검사 도구를 만드는 것입니다. 직접 도구를 제작하지 않고는 유효성 검사가 불가능한 때도 있으므로, 거의 필수적인 도구입니다. 이 도구를 만들어서 빌드 서버가 빌드할 때 유효성 검사도 함께하게 하면 좋습니다. 각 리소스 작업자가 이 도구를 커밋 전에 항상 실행할 수도 있겠지만, 그건 좀 불편합니다.

리소스 파일 관리를 어떻게 할 것인가는 게임 개발에서 상당히 중요한 일입니다. 따라서 관리자는 이런 문제를 어떻게 하면 쉽게 해결할 수 있을지 계속 고민해야 합니다.

참고:
엑셀을 이용한 데이터 입력의 딜레마
엑셀로 작업한게임데이터의 유효성검사에대해..
2009/06/07 00:16 2009/06/07 00:16
트랙백 0개, 댓글 2개가 달렸습니다.
◀ 이전페이지 1 2 3 4 5 ... 6 다음페이지 ▶