스펙 변경

https://youtu.be/bzWibA7izF8

• 게임의 스펙 변경은 피해야 하지만, 유연히 대처해야 하기도 함.
• 스펙 변경의 문제
  • 변경 전의 제작이 헛수고가 될 수 있음
  • 개발 과정이 늘 수 있음
  • 제작 비용 추가 발생 가능
  • 의욕 저하
• 아무리 앞을 보고 계획한 게임 스펙도 실제 만들어야 발견되는 문제도 있음.
• 구상한 게임을 누구나 볼 수 있는 형태로 만들려면 완성해야 함
• 완성을 위해 그 만큼 자료 조사, 구상 시 자료 조사가 게임 제작과 동일한 크기가 될 수 있음
• 팀의 개발물의 방향성에 따라 달라짐
  • 언뜻 보기엔 같아도 프로그래머 등이 다르면 내용물은 상당히 다름
• 일정 상 사양 변경도 흔함
• 단, 게임이 재미없다고 스펙 변경은 가급적 피해야함.
  • 기획 단계부터 재미를 보는 것이 좋음
• 제작물은 여러 가지의 조합
  • 예) 적 캐릭터 이동에 스펙, 기초 디자인, 모델, 모션, 이펙트, 프로그램, 스크립트, 효과음 등이 필요
• 우선 작업 중 하나가 늦어지거나 뒤의 작업에 해당하는 전체 일정이 막히면 제작 진행 불가
• 더 좋은 방법이나 기술, 공수 줄이기, 예상보다 낮은 성능 등 그 외에도 수많은 스펙 변경의 기회가 있고, 그 선택에 고민함
• 실제 스펙 변경은 '케이스 바이 케이스'
• 문제가 있는데도 고집해서 스펙 변경 없이 계속 만드는 것은 무리수
• 스태프 등이 문제점을 인지한 경우 나중에 '그럴 줄 알았다'는 안 됨
  • 문제점 발견 시, 바로 언급하기.
  • 개발자는 누구나 예외 없음.
  • 손님이나 플레이어는 문제가 있어도 바꿀 수 없음
  • 하지만 개발자는 스펙 변경이 가능함
• 컴퓨터이기에 모순된, 해결 불가 이슈 발생도 많지만, 그렇기에 집단 지성도 얕볼 수 없음
• 수단을 나열하고 그 중 최적의 답을 선택. 장, 단기적인 검토가 필요
• 마사히로의 경우
  • 발생 이슈는 최대한 빠르게 즉시 결론을 내리려함. 대부분은 그 자리에서 바로.
    • 망설이는 시간 아까움
    • 그 판단에는 정보가 필요
    • 정보가 불명확할수록 오판할 가능성이 높아져, 아는 것은 전부 듣고 싶다고함.
  • 상담 방식에 대한 고민도 손해
  • 개발은 항상 움직이는 것
  • 상담이 빨랐다면 손실도 적었을 것.