개발 팀이랑 처음 만날 때 마일스톤이 어떻게 되어있는지 물어보고,
그거에 대한 내용을 아예 전달받지 못하면, 그냥 그 팀은 거르면 됨.
마일스톤이 있는 팀과 없는 팀은 일의 효율이나 성과에서 100% 이상 차이난다고 보면 됨.
마일 스톤은 게임 개발 일정의 이정표? 이런식으로 이야기 할수 있는데, 개발 단계에선 크게
프리 프로덕션
엔진 프루프
메카닉 프로토 타입
에피소드 프로토 타입
알파
베타
파이널
이런식으로 볼수 있음.
파이널 이후에는 신규 업데이트나 기타 DLC 등등의 추가 개발기간이 있을수 있지만,
얼추 저 정도가 인디 게임에서는 필수 마일스톤이라 볼수 있음.
프리 프로덕션
아무런 개발이 진행되어 있지 않은 상태를 말함.
이 단계에서는 게임 디자인, 상업성 등등을 가지고, 팀을 구하거나(인디의 경우), 퍼블리셔 등등을 구하는 단계임.
이후 마일스톤에 대해 자세한 가이드라인이 없다면, 프로젝트는 뻥 하고 터질 가능성이 높음.
미래에 대한 대비를 안해두고 무작정 개발하는건데, 이러면 언제 야근 해야하는지, 언제까지 만들어야 하는지 아무 것도 모르기 때문임.
당연히 팀의 사기나 존망 여부도 문제가 생기는거고...
엔진 프루프
게임 엔진에 대해 증명 하는 단계임. 자체 엔진일경우 그걸 이용해서 개발이 가능 한지 등등을 증명 해야함.
자체 엔진이 아니더라도, 상용 엔진의 사용법이나, 그걸로 기획했던걸 구현할수 있다는걸 증명 하는것처럼..
이 단계 까지는 아티스트들은 필요가 없기 때문에, 아직까지 실제 팀원은 없을 수도 있지만, 적어도 디자인 단계의 세부사항은 정리된게 필요함.
메카닉 프로토 타입
이제 게임 메카닉을 증명하고, 이게 재밌을지 재미 없을지, 프로젝트를 더 진행 할지 말지 결정하는 단계임.
개발 되는 게임의 30%는 여기서 접는거 같음. 디자이너의 디자인으로 여기까지 개발을 했는데, 재미가 없다?
이러면 그냥 프로젝트를 접는게 맞는거임. 여기서 아무리 땜질을 해도 더 나아지는건 하늘의 별따기 수준으로 어렵다고 봄.
솔직히 간단한 AABB 충돌 구현만 해도 재미를 느낄수 있는데, 여기서부터 재미없으면... 똥겜의 탄생이 머지 않았다라고 볼수 있음.
에피소드 프로토 타입
게임으로 치면 레벨 하나를 완성한거임. 이때 까지만 해도 디자이너가 코딩해도 되지만 이 이후부터는 실제 릴리즈할 코드에 가깝기 때문에
가급적 디자이너는 코딩에서 멀어지는게 좋음. (물론 전문 디자이너가 코딩을 제일 잘하면 어쩔수 없지만;;)
여기선 각각의 메카닉을 테스트 하는게 아니라 전체적인 게임 자체를 판단하는 마지막 단계라 생각하면 됨.
솔직히 여기까지 왔는데, 노잼이면 접어야지... 그래도 아직까지는 개발 초기라 큰 타격은 없다고 봄.
스팀에 있는 대다수의 앞서 해보기 게임들이 이 단계에서 신청 하는거임.
크라우드 펀딩도 여기 까지 진행한거면 그나마 성공할 확률이 있는거로 봐도 됨.
알파
가끔 알파 테스트 라면서 참여하라는데 그게 이거임.
이제 다수의 완성된 에피소드들이 있고, 게임의 90%이상이 완성 됬다고 보면 됨.
알파단계라면 UI, UX 전부다 완성되서 릴리즈 해도 되는 정도임.
물론 아직 발견 못한 버그가 있을수 있고, 아트나 사운드는 완성이 덜 됬을수도 있음.
남아 있는건 밸런스 패치고, 세부 디테일 정도임.
또 마이크로레벨 최적화나, 안정성 등등을 수정하는게 이 때 라고 보면 될듯.
베타
이제 게임은 완성 됬다고 보면 됨. 클로즈 베타, 오픈 베타, 뭐가 됬던간에 실제 게임이랑 거의 차이가 없는게
그래서 그러는거임. 알파에서 베타는 순식간이라 보면 되서, 일단의 버그만 수정하면 베타에 도달하는거.
물론 아직 릴리즈가 나오지는 않았기 때문에 버그같은걸 수정하긴 해야하는거.
또 알파가 끝났으면 이때는 매주 테스트 하고 반영하고, 테스트하고를 반복하는게 좋음.
파이널 이후에 테스트 하는게 아니라 베타 전에 테스트하는게 정답임.
파이널
대망의 릴리즈임. 게임이 출시되고, 시장에 정식으로 출현하는게 이 때임.
기간으로 따지면 에피소드와 알파 사이가 가장 길고, 험난한 개발 단계인거 같음.
물론 알파에서 베타까지 도달하는데, 1년이고 2년이고 걸릴수는 있지만, 그래도 그때는
얼추 빠릿하게 되는데, 메인 컨텐츠를 개발하는 에피소드 이후부터 알파까지가 제일 어려운거 같음.
이때가 제일 재밌기도 하지만, 싸움도 많이 나는거 같아서 아쉬웠음.
그리고 크라우드 펀딩을 에피소드 만들고 나서 하는거 같던데, 솔직한 감상으로는 후원하기가 꺼려짐.
게임도 터져나가고, 바뀌는것도 많고, 등등등.
그리고 다시한번 말하지만 이정도 마일스톤도 확정지은게 없는 팀은 거르는게 좋음.
내부 개발 프로세스도, 워터풀보다 처참하게 진행할 가능성이 대다수라... (적고보니 내 사이드 프로젝트 같음...)
기간으로 따지면 느낌이 게임 스케일 따라 다르지만 2년짜리 프로젝트면
프리프로덕션 - 3주 - 엔진 프루프 - 3주 - 메카닉 - 1달 ~ 2달 - 에피소드 -
- 6개월 ~ 1년 이상 - 알파 - 기간 산정이 불가능 - 베타 - 1달 - 파이널
이런 느낌?
알파때 버그나 고칠게 많으면 베타까지가 길어지는거고, (물론 무작정 길어지면 안되겠지만;;)
적으면 짧아 지는거 이런 느낌?
저 기간은 정확하지는 않아도, 정해두고 모든 팀원이 도달 하려고 노력하는게 좋음.
너무 허황된 계획도 안좋지만, 예상보다 길어지는 경우가 허다 해서, 적당히 타이트하게 잡는건 나쁘지는 않는듯.
테스트는 메카닉 프로토타입 때부터는 꾸준히 하면서 (매주 금요일마다 사람이 많이 모이는 카페에서 등등)
그 데이터를 수집하고, 정리 하는게 개발하는데 큰 도움이 될거임.
그리고 그 정보를 바탕으로 큰 시간이랑 자본이 매몰되기 전에 게임을 접을지, 진행할지 결정하는거고...
좋은글은 개추여
근데 저런 용어들을 쓰는 회사가 우리나라에 있나?
근데 팀 멤버에 따라 경우의수가 있을수있다고 생각하는데? 마일스톤에따른 일정이 다 정해져있고 개발중인 팀이라면 새로운멤버가 팀에 기여하는 부분은 어디있음? / 메인 프로그래머 들이기 전에 프로그래머 역량을 모르고 마일스톤만 열심히 짠다고 그게 그대로 진행되는게 더 이상한거 같은데
나도 m1.m2.m3 이런식으로 마일스톤 진행하다보니 저런 용어는 좀 생소해서리...근데 저런식으로 중간중간 데드라인 안만들고 그냥 만들면 진짜 ㅈ 됨.....안그래도 인디게임 만들면서 늘어지는 사람들이 얼마나 많은데.
학교에서 쓰던 마일스톤이라 그냥 거기에 맞춰서 이야기 해봤는데, 따로 위키쪽을 보니 앞부분은 first playable로 묶어서 이야기하고, 알파와 베타 사이에 code freeze(컨텐츠 개발 완료 확정 마일스톤), 베타와 파이널 사이에 code release(콘솔 개발 리뷰, 추가 QA 테스트) 파이널(Gold master) 으로 나누는듯. 마일스톤 자체가 외부에 시연하거나, 퍼블리셔한테 검증 받는 일정? 이런 쪽에도 쓰여서 더 추가되는게 있는듯.
그냥 나는 노파심에 하는말일수도 있는데, 팀 꾸리는 사람이 팀원의 역량을 파악하고 그에 맞게 한계내에서 멋진게임을 내는게 이상론적이라고 생각해서, 혹시 이 글을 보고 멋진 프로젝트가 마일스톤의 여부만에 따라 개발되지 못할수도 있다는 생각을 했음.. 뭐든지 일반화나 절대 깨지지 않는 스탠스 같은건 곤란하지 않겠어 :)
asd// 마일 스톤으로 나눠 두는건 팀이 일할때 언제까지 어느정도의 결과물을 보여줘야 한다를 약속하는거임. 새로운 멤버가 들어오거나 현 멤버가 나가더라도, 디자이너가 기획한걸 보고 작업할수 있어야 하는거고;; GDD나 TDD, 코멘트, 소스 컨트롤 시스템 같은게 중요한게 인원 변동이 있더라도, 작업의 유지보수나 인원 투입이 쉬워지는거니까.
asd// 또 마일 스톤을 정해두는건 개발 기간을 어느정도 예측하는건데, 이건 최소한의 계획을 정해두는거니까;; 예를 들어 무작점 팀원을 구하는데 팀장이 생각하기에 팀을 이끌고 3년짜리 프로젝트를 생각했었는데, 마일스톤을 안 세워두고, 비밀로 하고 있으면, 다른 팀원들은 그걸 이해하지 못하니 갈등이 생기는거임. 마일스톤이 있다 하더라도, 얼마든지 외부의 원인이나, 내부 환경 등등에 따라 개발 기간은 늘어나거나 줄어들수 있는거니까 유동적으로 생각하는게 좋음.
성공한 인디겜 중에 이대로 진행한 팀 전세계 뒤져봐도 아무도 없다 재정 튼튼한 회사도 아니고 업계 베테랑도 아닐텐데 한치 앞도 보기 힘든 인디 개발팀이 마일스톤을 거창하게 짜둔다? 기획자가 어디서 겉멋만 든 사람일 확률이 높으니 그 사람을 걸러라(짜지 말란 소리 아님)
진짜 게임 만들어본 사람 글인가?? 그냥 인터넷에서 줏어담은 글 같은데;;;
ㄴ전혀 거창한 마일스톤이 아닌데, 왜 거창하다고 하는지 모르겠네;; 게임은 1년짜리 2개 만들어본 경험이 있음. 지금은 2년짜리 사이드 프로젝트 진행 중이고;; 물론 나는 기획자가 아니긴 하지만, 적어도 일정에 대한 계획도 안잡고 만드는건 좀...
마일스톤이 없어도 곤란하지. 작업자가 완성될 건축물에 대한 느낌을 당연히 알아야되니까. ㅇㅇ형은 변동사항에 대해서 유연하게 대처하는 방법도 고민해야 한다. 하는 말씀이신거 같음
알파는 내부 테스트용으로 비공개 아니냐?
ㄴ 비공개로 모집 하긴 함. 알파 자체도 게임이 거의 완성 된거니까... 참여해본 알파테스트 중에 유명한건 블러드본이랑 스타2 있는듯.
마일스톤은 게임으로 치면 세이브포인트 비슷한거라고 생각하면 댐. 어느 지점까지 진행하면 저장 ㅇㅇ
근데 대규모 개발업체는 뭐 내가 어떻게 알 방법이 없는데 소규모 개발팀은 프루프 오브 컨셉 하나 만들고 그걸로 나갈사람 나가고 남은사람은 개발에 달라붙고 이런식 아님??