1. GPG 2. Section 3. AI 3.2
게임 객체 AI를 위한
마이크로 스레드
DevRookie Study, 2011.12.03 박민근(알콜코더)

2. 문제
• 청소부(janitor) 객체
• 대상을 선택하고, 그 대상으로 이동
• 충분히 가까워졌으면, 그 대상을 치움
• 이러한 과정을 계속 반복

3. 단순한 해결 방법
모든 CPU를 점령해 버린다!!!

4. 전통적인 해결 방법
• 매 프레임마다 처리 함수를 호출한다
상당히 복잡한 코드
새로운 멤버 변수의
필요성

5. 간단하고 일반적인 방법
• 스레드로 만들어서 해결!
• 문제점
• 많은 양의 스레드의 부하
• 비싼 문맥 젂환 비용

6. 해결 – 마이크로 스레드
• 원하는 것
• 객체 갱신 코드가 CPU를 독점하는 것처럼 동작
• 한프레임 처리 이후에는 WaitOnFrame() – 대기

7. 해결 – 마이크로 스레드
• 명령 포인터
• 실행할 다음 명령을 가르키는 하나의 레지스터
• 스택 포인터
• 함수의 모든 지역 변수들은 스택 포인터에 상대적인
위치에 저장된다
• 스택 포인터에서 다음 명령 포인터를 뽑아온다
• 스택 포인터를 변경함으로서 다음 명령 포인터를 변

8. 해결 – 마이크로 스레드
• 스택 포인터
• 함수의 모든 지역 변수들은 스택 포인터에 상대적인
위치에 저장된다
• 스택 포인터에서 다음 명령 포인터를 뽑아온다
• 스택 포인터를 변경함으로서 다음 명령 포인터를 변
경할 수 있다

9. 해결 – 마이크로 스레드

10. 해결 – 마이크로 스레드
• 이젂에 발표했던 스택 와인딩 기법의 활용!!
• 어셈블리로만 구현이 가능하다
• 스택 포인터를 변경함으로서, 문맥 젂환 효과를 구현

11. 스택 관리
• 스택마다 4KB의 메모리 페이지 하나를 할당한다
• 스택이 채워질 1MB의 주소 공간을 할당
• 주소 공간이 넘치게 되면 Page Fault 오류 발생!
• 스택 크기 관리를 제대로 하지 않으면, 메모리 깨짐
• 해결 방법
• 스택 풀
• 모든 마이크로 스레드들이 스택 풀을 공유한다

12. 몇가지 문제들
• 게임의 로딩과 저장
• 스택은 메모리 주소의 정보 -> 저장/로딩이 일반적
으로 불가능하다
• 구조화된 예외 처리(SEH)
• 스택 포인터가 스택 주소 밖이기 때문에 문제 발생
• OuputDebugString
• SHE 문제 때문에 프로그램이 죽어 버림

13. 결론
• 스레드는 독립적인 AI 객체들의 코드 작성을 단순화
• 마이크로 스레드는 메모리 사용량, CPU 비용에 장점
• 스크립팅 언어에도 이미 사용됨
• Lua, Python, SCUMM
• 하지만 어셈블리와 관리의 어려움 때문에, 현재의 개발
현실에서는 실제로 사용하기 어렵다!
• 그냥 이런게 있다고만 알아 두자