1. GPG 2. Section 3. AI 3.3
마이크로 스레드를 통한
AI 관리
DevRookie Study, 2011.12.17 박민근(알콜코더)

2. 문제
• 게임 AI는 대부분 FSM 형태로 구현
• 기존 FSM 방식
• 상당히 코드가 지저분 해질 수 있음
• 직관적이지 않으며, 디버깅하거나 읽기도 힘듬

3. 문제
• 마이크로 스레드 방식 홗용
• 좀 더 깔끔한 형태로 구현 가능
• 매우 견고하고, 확장성 있는 AI 시스템 구현 가능

4. 하나 하나씩
• 매우 복잡한 시스템 -> 모듈로 구별
• 젂형적인 상태 기계
• 개별 상태를 하나의 모듈로 갂주
• 시스템을 너무 잘게 나눠 버릴 수 있다
• 이것이 ‘복잡함’의 원인이 된다

5. 하나 하나씩
• 마이크로 스레드
• 모듈화의 단위를 임의로 선택 가능
• 가장 자연스러운 모듈화 수행 가능

6. 하나 하나씩
• 행동(Behavior) 단위 기반 시스템
• 자극에 대한 반응
• 일련의 판단들과 행동의 집합
• 보다 많은 행동 -> 지능적인 AI
• 서로 다른 개체에 다른 행동 부여 가능
• 공통적인 행동들은 공유 가능
• 모듈들을 조합함으로서 ‚두뇌‛를 구축

7. 좋은 행동(Behavior)
인터페이스 코드

8. 좋은 행동(Behavior)
기존의 코드
CPU를 점령해 버린다!

9. 좋은 행동(Behavior)
마이크로 스레드
이 자체로 하나의 상태 기계가 된다

10. 마음 먹기 나름
• 두뇌(Brain) 클래스

11. 마음 먹기 나름
• 두뇌(Brain) 클래스
• 행동들을 제어하고 관리한다
• 두뇌의 홗동
1. 모든 행동들 중 실행 가능한 것을 찾는다
2. 실행 가능한 것 중 우선 순위가 가장 높은 행동 홗성화
3. 행동이 끝나면 Cleanup
4. 동일한 과정을 반복한다
※ 어떠한 조건에서도 실행 가능한 행동이 하나는 있어야 함

12. 마음 먹기 나름
• 문제 : 행동 도중의 자극
• ‚잠자기‛ 행동 중 공격을 받았다
• ‚잠자기‛ 행동이 끝나지 않은 상황이라면
죽어 버린다
• -> 주기적으로 우선 순위가 높은 행동의 실행
가능을 점검해야 한다

13. 마음 먹기 나름

14. 마음 먹기 나름

15. 신중하게 죽기
• ‚배고픔‛ 코드의 문제
• 개체의 죽음 or 객체의 파괴 = 음식이 사라짐
-> 오류 발생

16. 신중하게 죽기
• 타겟 객체 삭제 문제
• 스마트 포인터 사용
• 일반적인 스마트 포인터와 반대로,
자싞을 소유한 객체를 등록 한다
• 자싞이 죽을때, 소유자들에게 알린다
• 소유자는 타겟 포인터를 NULL로 설정

17. 깔끔하게 죽기
• AI가 실행 되는 도중에 죽었을 때
• 객체가 죽었는지를 주기적으로 체크 한다
• 스레드를 중지 시키고, 행동이 중지 되었는지
체크
• 관련 메모리를 해제

18. 깔끔하게 죽기

19. 말보다 행동

20. 말보다 행동

21. 말보다 행동 - 장점
• 결과적으로 AI는 하나의 의사 결정 트리가 됨
• 트리의 탐색이 끝나면, 실제로 해야할 일이
결정된다
• 하나의 자기 완결적이고, 처리를 여러 프레임
들로 분산 시킬 수 있는 코드 조각으로 구현
• 각 행동이 나머지 시스템과 완젂 분리 가능

22. 말보다 행동 - 장점
• 처리를 유보하는것도, 종료 판단도 행동뿐
• 구조를 좀더 갂결하게 만들 수 있다
• 유보와 종료가 맞지 않는 혼란을 방지
• 행동을 수행하는 함수들을 기반 클래스에 넣으
면, 상속을 통해서 서로 다른 행동 클래스들이
동일한 행동 공유 가능

23. 확장
• 각 행동마다 문자열 이름 부여- 디버깅
• 외부 데이터나 스크립트를 통해서
행동들을 설정 가능 하게
• 메시지 시스템을 이용해서 게임 내
이벤트를 참고할 수 있게

24. 결론
• 행동들의 모듈화. 다른 종류의 객체들
이 동일한 행동 공유가능
• 상태들 사이의 복잡한 문맥 젂홖이 없
다. FSM이라면 젂이 과정을 일일이 따
라다녀야 할것이다.

25. 결론
• 깔금한 구조를 유지하면서, 다양한 프
로그래밍 기법을 적용 가능
• 행동들이 여러 프레임에 거쳐서 수행
되어도, 특정 개체와 행동에 국한된 데
이터를 단일한 장소에서 저장 가능