티스토리 뷰

아래 내용은 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
   샘플 프로그램, 데모

.. 요약 ..
 변강쇠 엔진 - 어떻게 다루든 잘 작동 할 수 있도록 만들어진 튼튼한 엔진
 성능? 편의성? 

댓글
댓글쓰기 폼