아래 내용은 kgc 2010에서 배현직 님이 발표하신 내용을 간략하게 요약한 것입니다.
제목은 Game API Design이지만 실제 내용은 Engine API 디자인, Library API Design 정도가 될 수 있겠습니다.
1. 한정된 복잡도 내에서 얼마나 많은 기능을 넣을 수 있는가가 API 설계 기조
2. 같은 이름 다른 내용의 클래스 끼리 충돌이 발생하는 것을 방지
- namespace의 사용
- 잘 지은 인터페이스 열 주석 안부럽다.
3. 필요한 외부 라이브러리는 프로젝트에 포함
- third party include 는 사용자 인터페이스에 포함하기 보다는 implementation part에 포함하는 것이 좋음
- third party 라이브러리의 버전업 등으로 인해 추후 해당 라이브러리를 찾지 못할 수 있음
4. 사용성 vs 확장성
- engine이 할 수 있는 것과 하지 못하는 것에 대한 role과 한계를 정할 것.
- 많은 사람들이 사용하고 있는 것이 바로 "표준"
- engine의 기능이 늘어날 수록 사용법이 복잡 해 진다. 이런경우 frequent use를 다시 조사.
다시 API를 제공한다(facide pattern, visitor pattern)
- 복잡한 파라메터는 :
+ 구조체로 넘긴다
+ 엔진 자체에 state machine를 두어 각 인터페이스로 엔진 state machine에 값을 채우고 trigger 함수 호출
- 클래스 관계도는 단순하게!! 디자인 패턴에 무지하더라도 사용 할 수 있는 것을 지향
- 사용자가 엔진 내부 객체의 life cycle 같은 것에 신경 쓰지 않고 사용할 수 있도록 디자인
- 쉽게 사용할 수 있는 API(인자도 없고 리턴 값도 간단한)의 경우 에러 내용을 쉽게 알 수 있게 해줘야 한다
(상세한 에러 리포팅 기능 필수)
5. 하위 호환성
- API가 안 바뀌는 것이 가장 좋음
- 추가 되고 변경되더라도 기존 파라메터의 의미가 변경되지 않도록 유지
- API가 달라지는 경우 어떻게 하는가?
파라메터가 자주 변경 될 가능성이 있는 경우 구조체로 만드는 것도 한가지 방법
- release note 작성 필수
6. 기타
- c/c++ 입력 전용 파라메터면 const
- smart pointer를 엔진 api에서 노출 시 thread safe를 고려 할 것
smart pointer 같은 것을 포함 시킬 때 thread safe를 고려하지 않는다면
문제가 발생 했을 때 엔진 문제인지 게임 로직 문제인지 찾기가 힘들어 질 수 있다.
- stl, boost 사용시 주의. visual studio 버젼이 변경되면 build 안 될 수도 있음
- 쓰기 쉽게 할 것
도움말 작성 필수(overview, tutorial, API 명세)
재밌게 쓰게 할 것(툴 제공, 간단한 GUI, 튜토리얼, 샘플)
- 항상 잘 돌아가는 엔진 제공
자동화된 unit test suite
샘플 프로그램, 데모
7. 요약
변강쇠 엔진 - 어떻게 다루든 잘 작동 할 수 있도록 만들어진 튼튼한 엔진
성능? 편의성?
