마이크로 스레드를 통한 AI 관리

GPG 2. Section 3. AI 3.3

DevRookie Study, 2011.12.17 박민근 ( 알콜코더 )

문제

• 게임 AI 는 대부분 FSM 형태로 구현

• 기존 FSM 방식• 상당히 코드가 지저분 해질 수 있음

• 직관적이지 않으며 , 디버깅하거나 읽기도 힘듬

문제

• 마이크로 스레드 방식 활용• 좀 더 깔끔한 형태로 구현 가능

• 매우 견고하고 , 확장성 있는 AI 시스템 구현

가능

하나 하나씩

• 매우 복잡한 시스템 -> 모듈로

구별

• 전형적인 상태 기계

• 개별 상태를 하나의 모듈로 간주

• 시스템을 너무 잘게 나눠 버릴 수

있다

• 이것이 ‘복잡함’의 원인이 된다

하나 하나씩

• 마이크로 스레드

• 모듈화의 단위를 임의로 선택 가능

• 가장 자연스러운 모듈화 수행 가능

하나 하나씩

• 행동 (Behavior) 단위 기반 시스템• 자극에 대한 반응

• 일련의 판단들과 행동의 집합

• 보다 많은 행동 -> 지능적인 AI

• 서로 다른 개체에 다른 행동 부여 가능

• 공통적인 행동들은 공유 가능

• 모듈들을 조합함으로서 “두뇌”를 구축

좋은 행동 (Behavior)

인터페이스 코드

좋은 행동 (Behavior)

기존의 코드

CPU 를 점령해 버린다 !

좋은 행동 (Behavior)

마이크로 스레드

이 자체로 하나의 상태 기계가 된다

마음 먹기 나름

• 두뇌 (Brain) 클래스

마음 먹기 나름

• 두뇌 (Brain) 클래스• 행동들을 제어하고 관리한다

• 두뇌의 활동

1. 모든 행동들 중 실행 가능한 것을 찾는다

2. 실행 가능한 것 중 우선 순위가 가장 높은 행동

활성화

3. 행동이 끝나면 Cleanup

4. 동일한 과정을 반복한다

※ 어떠한 조건에서도 실행 가능한 행동이 하나는

있어야 함

마음 먹기 나름

• 문제 : 행동 도중의 자극• “ 잠자기” 행동 중 공격을 받았다

• “ 잠자기” 행동이 끝나지 않은 상황이라면

죽어 버린다

• -> 주기적으로 우선 순위가 높은 행동의

실행 가능을 점검해야 한다

마음 먹기 나름

마음 먹기 나름

신중하게 죽기

• “ 배고픔” 코드의 문제• 개체의 죽음 or 객체의 파괴 = 음식이

사라짐

-> 오류 발생

신중하게 죽기

• 타겟 객체 삭제 문제• 스마트 포인터 사용

• 일반적인 스마트 포인터와 반대로 ,

자신을 소유한 객체를 등록 한다

• 자신이 죽을때 , 소유자들에게 알린다

• 소유자는 타겟 포인터를 NULL 로 설정

깔끔하게 죽기

• AI 가 실행 되는 도중에 죽었을 때• 객체가 죽었는지를 주기적으로 체크 한다

• 스레드를 중지 시키고 , 행동이 중지

되었는지 체크

• 관련 메모리를 해제

깔끔하게 죽기

말보다 행동

말보다 행동

말보다 행동 - 장점

• 결과적으로 AI 는 하나의 의사 결정 트리가

됨

• 트리의 탐색이 끝나면 , 실제로 해야할

일이 결정된다

• 하나의 자기 완결적이고 , 처리를 여러

프레임들로 분산 시킬 수 있는 코드

조각으로 구현

• 각 행동이 나머지 시스템과 완전 분리 가능

말보다 행동 - 장점

• 처리를 유보하는것도 , 종료 판단도 행동뿐

• 구조를 좀더 간결하게 만들 수 있다

• 유보와 종료가 맞지 않는 혼란을 방지

• 행동을 수행하는 함수들을 기반 클래스에

넣으면 , 상속을 통해서 서로 다른 행동

클래스들이 동일한 행동 공유 가능

확장

• 각 행동마다 문자열 이름 부여 -

디버깅

• 외부 데이터나 스크립트를 통해서

행동들을 설정 가능 하게

• 메시지 시스템을 이용해서 게임 내

이벤트를 참고할 수 있게

결론

• 행동들의 모듈화 . 다른 종류의

객체들이 동일한 행동 공유가능

• 상태들 사이의 복잡한 문맥 전환이

없다 . FSM 이라면 전이 과정을

일일이 따라다녀야 할것이다 .

결론

• 깔금한 구조를 유지하면서 , 다양한

프로그래밍 기법을 적용 가능

• 행동들이 여러 프레임에 거쳐서

수행 되어도 , 특정 개체와 행동에

국한된 데이터를 단일한 장소에서

저장 가능