Feynman's Library

http://blog.naver.com/hite97?Redirect=Log&logNo=60053474486

알기 쉽게 잘 정리되어 있네요 ^^



※ 아래는 보관소 글...
http://feynmanr.tistory.com/entry/맛있는-쇠고기-그들의-등급에-대하여펌

출시일 : 1998년 8월
퍼블리셔 : UBI Soft
장르 : 팀기반 전략 슈팅
플랫폼 : Windows 95/98
팀규모 : 16명의 풀타임 개발자, 6명의 파트타임 개발자



GOOD

1. 통일된 비전
비록 문서화 되어 있지 않앗으나, 모든 팀원이 프로젝트에 대한 명확한 비전을 공유하고, 이를 믿고 있었다는 것은 힘든 시간들을 이겨내는데 큰 도움이 되었다.

2. 효율적인 디자인 제작 과정
간단한 스케치에서 시작하여, 최종 작업전 테스트를 거치는 효율적인 방법을 사용함으로써 낭비되는 노력을 최소화했다.

3. Tom Clancy의 인지도
유명한 게임이력/개발자없이 출발했지만 그의 이름 덕분에 주목받을 수 있었다.

4. 물리엔진의 손질
"충돌검사"에 대한 로직을 최적화 함으로써 안정성과 속도를 모두 개선할 수 있었다.

5. 팀의 단합.



BAD

1. 초기 기획의 부재
제대로된 문서를 만들지 않아서 진행상황/누락된 부분 등을 체크하는데 어려움을 겪었다.

2. 인력 부족
정확한 규모의 파악에 실패(1번 사항과 연관되어.. )/능력의 과대 평가/자금부족 등으로 인한 투입 이원 산출 실패로 심각한 인력의 부족을 경험해야 했다.

3. 검증되지 않은 기술에 의존
외부 엔진에 의존했던 렌더링/네트워크 기술이 실제로 원활하게 사용하는데 문제가 있었다.

4. 핵심 인력 손실
수석 엔지니어의 건강 악화로 인해 개발 마무리 단계에서 중요 인력 부재로 인한 큰 어려움을 겪었다.

5. 부족한 테스트 기간
위에 기술한 여러가지 이유로 일정이 촉박해져 충분한 테스트를 거칠 수 없었다. 그럼에도 불구하고 중대한 모든 결함을 수정하여 출시했으나, 결국 출시 후 발견된 몇 가지 버그에 대한 패치를 진행할 수 밖에 없었다.

출시일 : 2000년 10월 20일
장르 : SF-FPS
퍼블리셔 : Activision
플랫폼 : 윈도우 95/98/NT/2000, 매킨토시, 리눅스, PS2
풀타임 개발자 : 20명
계약직 : 13명
개발 기간 : 6개월의 사전제작, 18개월의 본제작



GOOD

1. Quake Engine에 맞춰 작업
- 엔진 완성 전에 작업했으므로, 싱글/멀티의 실행 파일을 초기부터 분리하여 작업했으며, 이 덕분에 싱글 플레이어 게임에는 획기적인 변화를 줄 수 있었고, 훨씬 더 많은 변화를 주는 것이 가능했다.
- Quake 3에서 사용하는 기본적인 3D 모델 포맷을 과감히 버리고 필요한 3D 모델 포맷을 개발하여 (Carcass) 사용함으로써 사용되는 메모리량을 크게 줄여 원하는 내용을 담을 수 있게 됨
- Lip Sync 시스템을 개발하여 사용

2. 처음부터 플롯과 스토리를 완성
- 잘 짜여진 확고한 스토리를 초기부터 끝까지 유지했기 때문에, 작업을 중단하는 일 없이, 부드럽게 모든 작업을 수행할 수 있었음.

3. 대화
- 직원들이 임시로 녹음한 음원으로 미리 작업한 후, 실제 성우들의 녹음을 진행했기 때문에 대화와 관련한 모든 작업들이 빠르고 정확하게 진행되었다.

4. Star Trek 외관의 재창조
초기에 많은 시간을 들여 캐릭터-레벨 간의 비율을 확정하고 모든 레벨에 사용할 표준적인 스케일을 정착시킨 후 부터는 거의 재작업없이 공간을 만들어갈 수 있었다.
그리고, 환경/캐릭터를 제작할 때, Star Trek 설정 자료들을 충분히 참조하여 작업했기 때문에 완성도 높은 세계를 구현하는데 성공했다.

5. 영리한 NPC의 제작
- 넓은 레벨 안에서 "동료"들의 길찾기 문제를 해결.
- 동료 NPC의 전투 게임 수준과 적 NPC의 플레이어 공격 빈도를 잘 조절하여 게임플레이에 밸런스를 맞춰주었다.




BAD

1. 불충분한 프로그래머 수
인공지능/탐색 시스템에 할당할 프로그래머를 일찍 구하지 않아서 이런 부분과 관련한 업무에 과부하가 걸림

2. Ghoul Model -> Quake 3 model -> skeleton 기반 모델
최종적으로 skeleton 기반 모델을 사용한 것은 훌륭한 결정이었지만, 여러 단계의 시행착오를 겪으므로해서 일정/품질에 좋지 않은 영향을 주게 되었다.

3. 스크립트 작업에 필요한 일의 양을 과소 평가
기반 시스템 변경/Icarus 스크립트 자체 문제 등으로 인한 잦은 재작업과 오류를 수정하기 위해 끊임없는 노력을 기울였기 때문에 결과적으로 스크립트 작업에 계획된 시간보다 너무나 많은 시간이 소모되었다.

4. 새로운 Quake 3 기술로의 이전
지속적인 개발 단계 중이었던 Quake 3를 사용하므로써 새로운 빌드가 도착할 때마다 레벨을 재작업해야 했음.
로우 폴리곤 기반의 Quake 1,2 하에서 계획되었던 레벨들은 high 폴리곤 기반의 Quake 3에 들어오자 레벨 용량이 너무 커지는 문제가 나타났고, 이를 해결하기 위해 좀 더 작은 단위의 레벨로 재디자인 함으로써 문제를 해결했으나, 결과적으로 "2배 많은 작업 + 더 짧아진 레벨"이라는 부작용을 겪어야 했다.

5. 완성되지 않은 미션 통계
미션 종료 후, 플레이어의 활동을 평가하는 미션 통계 시스템을 구현 완료하지 못해서, 미션 통계가 가져올 수 있는 계획적인 긍정적 효과들을 얻지 못했다.

§ 미션 통계가 가져올 수 있는 긍정적 효과들 §
① 재플레이 욕구 증가
② 레벨의 상호작용(interactivity)
③ 다양한 결과를 낳는 이벤트(multiple-outcome events)에 중점을 둘 수 있음
④ 플레이어의 실력에 등급을 주고 그에 따라 보상을 줌