1.0 데이터 주도적 설계의 마법

제1부
프로그래밍 기법들

1.0 데이터 주도적 설계의 마법
아이디어 #1 기본
필요할때마다 텍스트를 읽어서 처리할수 있는 시스템을 만드는게 좋다
(최종 출시 시점에서는 이진 파일을 이용하겠지만, 개발 단계는 텍스트 파일을 사용하여 편집/수정이 쉽게 한다)

아이디어 #2 최소한의 원칙
상수들을 하드 코딩 하지 말고 텍스트 파일에 넣어야 한다

아이디어 #3 하드 코딩을 아예 없애라
게임을 단일한 용도로 설계하지 말고 최대한 범용적인 기능성을 담당하도록 분리한다

아이디어 #4 게임의 흐름은 스크립트로 제어할 것
게임 안에서의 어떠한 장면을 연출할 때는 스크립트를 사용하는 것이 좋다
단순한 원인-결과 로직 역시 스크립트의 대상이 된다
스크립트를 채용하면 시스템의 설계를 상당히 단순화시킬 수 있다

아이디어 #5 스크립트 남용의 해악
스크립트를 사용할때의 원칙: 로직과 데이터의 분리
복잡한 로직은 코드에, 데이터는 코드 외부에.

스크립트는 데이터의 성격과 로직의 성격을 함께 가지고 있다는 위험성이 있다.

경계가 애매하다는 것이 문제
로직이 복잡하면 코드에 넣어라
스크립팅 언어는 게임 개발에 필요한 시간과 자원을 너무 소비하지 않도록 해야 한다

아이디어 #6 데이터의 중복을 피해라
여러곳에서 쓰일 데이터를 전역적인 데이터로 만들어라

아이디어 #7 데이터를 만들어 내는 도구를 작성할 것
제대로 된 도구를 만들어 두면 게임 개발 속도가 훨씬 빨라진다.

C++를 이용한 크로스 플랫폼 개발 - 빌드 시스템과 툴 체인

Chap2 빌드 시스템과 툴 체인

크로스 플랫폼 프로젝트의 성공 열쇠는 추상화

아이템7: 각 플랫폼에서 가장 잘 특화된 컴파일러를 사용하라

성능과 플랫폼 지원을 선택 기준으로 삼아 가장 뛰어난 컴파일러를 선택한다
프로젝트에서 여러가지 컴파일러가 사용되면 컴파일러 특화 코드를 사용할 가능성이 적어진다.

아이템8: IDE를 적절히 활용하라

플랫폼마다 빌드 방법이 다르므로 gmake와 같은 크로스 플랫폼툴을 사용하라

편집기나 디버깅을 위해 IDE를 사용하는 것은 좋으나, 빌드 시스템으로는 사용하지 말아야 한다
IDE에 기반한 빌드 시스템은 다른 플랫폼으로 이식되지 않으므로 Makefile을 사용해야 한다

아이템9: Windows에 Cygwin을 설치한다

Windows 또는 UNIX 계열의 시스템에서 빌드나 디버그를 해야하는 경우를 위해 Cygwin등을 사용한다

아이템10: 크로스 플랫폼 개발을 위해 make를 이용한다

특정 IDE를 사용하면 이식성과는 거리가 멀어지게 된다
이식 가능하도록 만들고 싶다면 크로스 플랫폼한 방식을 찾아야 한다

C++를 이용한 크로스 플랫폼 개발 - 정책과 관리

Chap1 정책과 관리

아이템1: 모든 플랫폼을 동등하게 생각하라

Netscape 의 예

1군 플랫폼: Mac OS X, Linux, Windows

그 외: BSD, Solaris, AIX, HP/UX 등

1군 플랫폼에서 모든 기능이 구현되어야 하며, 릴리즈에 앞서 모든 내부 테스트를 통과해야 함

기준을 만족하지 못하면 릴리즈 불가

플랫폼간 차이는 동일한 구현을 어렵게 한다

1. 컴파일 타임의 에러를 체크한다

2. 스모크 테스트. 매일 아침마다 마지막 빌드된 바이너리로 QA에서 전체적인 테스트를 수행한다

아이템2: 공통된 코드베이스를 구축한다

공통적으로 사용할 수 있는 코드와 플랫폼 특화 코드를 분리한다

팩토리 디자인 패턴을 사용한다.

플랫폼 특화 팩토리를 만든다

플랫폼 별의 차이는 폴더를 나누어 저장한다.

크로스 플랫폼 빌드에서의 주의해야 할 내용

- 해당 플랫폼에 맞는 컴포넌트와 라이브러리만 빌드한다

- 올바른 Makefile 파일을 사용하도록 한다

- #define이 잘 동작하도록 명령 행 인수를 이용한다

- 빌드된 컴포넌트와 응용 프로그램은 적당한 폴더에 복사한다. 테스트와 배포는 이 폴더를 기준으로 한다

아이템3: 개발자가 작성한 코드는 여러 컴파일러로 컴파일해봐야 한다

여러 컴파일러로 빌드하는 것의 중요성

- 컴파일러에 특화된 기능, 플래그, 매크로의 사용을 피할수 있도록 해준다

- C/C++ 표준의 구현 차이로 인한 충격을 최소한으로 막아주고 검증되지 않은 기능을 사용하지 않도록 해준다

- 각 컴파일러는 서로 다른 종류의 경고와 에러를 알려주기 마련이다. 이런 경고와 에러를 수정하면 개발이 좀 더 부드럽게 이루어질 수 있으며 코드도 건강해진다

- 각 컴파일러가 생성하는 이진 코드는 서로 다르다. 때문에 발견하기 어려운 문제들을 해명하는데 도움이 된다

아이템4: 여러 플랫폼에서 코드를 빌드한다

- 모든 플랫폼에서 빌드 테스트와 스모크 테스트를 하는 것은 빌드 트리를 깨끗하게 관리하는 것 이상의 의미를 가진다

- 모든 개발자가 모든 플랫폼에서 빌드해보길 원하지도 않고, 그럴수도 없다

- 소스 코드를 저장소에 체크인하기 전에 모든 플랫폼에서 빌드하고 테스트해볼것을 강제한다면 모든 플랫폼이 동일한 속도로 개발될 것이며, 그만큼 크로스 플랫폼 개발이 성공적으로 이루어질 가능성이 높아진다

아이템5: 각 플랫폼에서 빌드를 테스트한다

세 개의 메인 플랫폼을 매일 아침 테스트

스모크 테스트를 위해, 매일 아침에 Tinderbox 빌드들이 취합되어 QA에 전달(스모크 테스트 완료전까지 모든 체크인은 금지)

플랫폼 중 하나에서 새로운 문제 발견시 Tinderbox와 bonsai는 해당 문제와 관련된 체크인을 격리시킴

아이템6: 컴파일러 경고에 귀 기울이자

경고가 발생한 코드는 거의 이식 불가능하다

1. 일정 시간을 추자하여 경고를 수정하고 체크인한다

2. 빌드 과정에서 발생한 경고의 수를 확인하여 일정 수준을 넘어서면 체크인을 금지시킨다

컴파일러 옵션을 조정하여 언어 표준을 강제할 수 있다(언어 표준에 맞지 않은 모든 코드들을 경고나 에러로 출력할 수 있도록)