초기 시절을 돌아보며 실수로 본 몇 가지

• Quake 개발 초기는 기술적 과욕과 조직 운영 문제가 함께 드러난 시기였고, 안정적인 기반을 택했다면 팀의 부담을 줄일 수 있었음
• 멀티플레이어와 모딩은 더 보수적인 Doom++ 엔진에서도 구현 가능했으며, Quake의 급격한 기술 전환은 디자이너들에게 반복적인 재작업을 만들었음
• 스타트업식 업무 강도를 계속 유지하면 팀이 지치기 때문에, 성숙해지는 회사에는 더 많은 여유(slack) 가 필요했음
• 원래의 회사 주식 구조와 buy/sell agreement는 나쁜 인센티브를 만들었고, 표준적인 베스팅 주식 방식이 더 나은 선택으로 남음
• 레벨 디자이너에게 게임 디자인과 강한 시각 디자인 감각을 동시에 요구한 일은 역할 설계의 부담을 키웠고, 아티스트와 디자이너를 더 일찍 짝지었어야 했음

Quake 개발에서 드러난 기술적 과욕과 개인적 한계

• Quake는 기술적으로 지나치게 야심적이었음
  • 멀티플레이어와 모딩 작업은 Doom++ 엔진 안에서도 훌륭하게 만들 수 있었음
  • 더 안정적인 기반을 유지했다면 디자이너들은 여러 차례 기반이 뒤집히는 상황을 덜 겪었을 것임
  • 이후 게임에서 전체 6DOF 환경과 캐릭터를 도입하는 순서도 가능했음
• 개발 과정에서 사람들을 너무 강하게 몰아붙였음
  • 성숙해지는 회사에는 더 많은 여유가 필요함
  • 스타트업 수준의 강도를 계속 유지하면 사람들이 지침
• Quake 시기에는 개인적 한계도 받아들여야 했음
  • 거의 인간적으로 가능한 최대치로 일했지만 목표 지점을 계속 넘기며 일정이 지연됐음

회사 소유 구조와 역할 설계의 부담

• 창업자들이 짊어졌던 원래의 회사 주식 구조와 buy/sell agreement는 실수였음
  • 현재 프로젝트에서 열심히 일하는 사람들에게만 소유권이 남도록 하려는 의도였음
  • 결과적으로 나쁜 인센티브가 생겼음
  • Silicon Valley의 표준적인 베스팅 주식(vesting stock) 접근이 더 나았을 것임
• 레벨 디자이너에게 게임 디자인뿐 아니라 강한 시각 디자인 감각까지 요구한 일은 스스로 책임을 완전히 받아들이지 못한 “실제 문제”로 남아 있음
  • 레벨 디자이너는 플레이가 좋을 뿐 아니라 보기에도 멋진 것을 만들어야 했음
  • 기술이 더 풍부한 표현 수단을 제공하면서 이 요구는 더 어려워졌음
  • Romero가 이를 잘 해냈고, 회사의 기대 수준이 초기에 그렇게 형성됐음
• 아티스트와 디자이너를 더 일찍 짝지어 작업하게 했어야 했음
  • 디자이너들 사이에는 내부 다툼이 있었음
  • 시각적 요소를 잘 다룰 수 있는 디자이너들이 그렇지 못한 디자이너들을 깎아내렸음
  • 마지막에 “Sorry, Sandy.”라고 덧붙였음