원문: Game AI: The State of the Industry By Steven Woodcock
Gamasutra
November 1, 2000
** Game Developer Magazine 2000년 8월호에 실렸던 글입니다 ++

번역자: 류광 GPGstudy.com

역자의 말

게임 AI 분야의 2000년 총 결산이라고 할 수 있는 글입니다. 선진국과의 격차가 어느 정도인지를 알 수 있으며, 특히 "AI에 대해서 무엇을 어떻게 공부할 것인가"에 대한 좋은 지침이 될 수 있다고 생각합니다. 꽤 긴 글이지만... 꼼꼼이 읽을만한 가치가 있다고 생각합니다....

2000년 게임 AI의 현주소 - 1부 1 페이지

차례
작년 이후의 경향
AI SDK의 가능성

이 보고서는 2000 GDC(Game Developers Conference)의 AI 토론회를 주재한 Steven Woodcock이 그 회의에서 나온 주요 주제들을 정리한 것으로, 2부로 구성될 게임 AI 보고서 시리즈의 1부에 해당한다. 2부는 다음 주에 올라올 예정인데, John E. Laird가 쓴 AI 학계와 개발자들이 서로 좀 더 정보를 잘 공유할 수 있도록 하는 방안에 대한 이야기와 Ensemble Studio의 Dave Pottinger가 쓴 게임 AI의 향후 전망에 대한 이야기가 수록될 것이다.

서문

올해 GDC 직후 확실해 진 것은, 개발자, 제작자, 관리자들의 머리속에 게임 AI의 중요성이 확고하게 자리잡았다는 점이다. 이제 게임 AI는 게임 설계 과정 속의 하나의 중요한 부분으로 인식되고 있다. "일정에 여유가 생길 때 시도해 볼만한 것"이라던가 "대학의 여름 방학동안 아르바이트생에게 파트 타임으로 맡기는 것" 같은 인식은 사라진 듯하다. 많은 사람들이 게임 AI를 다듬는 것이 게임의 그래픽 엔진에 새로운 기능들을 추가하는 것만큼이나 중요한 일이라고 여기고 있다. 다른 말로 하면, 게임 AI는 이제 "체크 리스트"의 한 항목이 된 것이다. 올해 GDG의 AI 토론회에 대한 반응이나 필자(Steven Woodcock)의 웹 사이트(www.gameai.com)에 있는 여러가지 설문 조사 결과를 볼 때, 개발자들이 다른 게임들보다 좀 더 뛰어난 AI를 만들고자 적극적으로 새롭고 더 나은 기법들을 찾고 있다는 것만큼은 명백한 사실로 받아들여야 할 것이다.

GDC AI 토론회에서 벌어지는 논의의 기술적 수준과 질도 계속 높아지고 있다. 더욱 중요한 것은, GDC에서 열린 "초보를 위한 AI(AI for Beginners)" 세션이 만원 사례를 기록했다는 점. 지금 만들고 있는 게임의 AI를 향상시키고자 하는 개발자들은 물론 자신의 프로그래머들이 무슨 말을 하는지 이해하고자 하는 제작자, 아티스트들도 많이 참여했던 것 같다.

작년의 보고서와 마찬가지로, 이 글에서는 필자와 Neil Kirby, Eric Dybsand 등이 이끈 AI 토론회를 통해서 수집, 정리한 몇가지 생각들을 이야기해 보겠다. GDC의 AI 토론회에서는 개발자들이 고민하고 있는 문제들, 그들이 사용하는 기술들, 그리고 업계의 향후 방향에 대한 생각 등 매우 가치있는 자료들을 수집할 수 있었다. 또한 이 글에서는 필자의 웹 사이트에서 지난 수년간 실행했던 몇가지 설문 조사 결과들(이것들 중 일부는 AI 토론회의 토론에서 흥미있는 주제들이 되기도 했다)에 대해서도 언급하겠다.

자원: 이젠 문제가 안된다?

작년 글(Game AI: The State of the Industry http://www.gamasutra.com/features/19990820/game_ai_01.htm)에서 AI 개발자들이 (드디어) 게임 설계 과정에 참여하게 되었으며, 그것이 좀 더 나은 AI 유닛들을 만드는 데 도움이 되었다는 점을 언급했었다. 또한 게임 AI에 더 많은 프로그래머들을 할당하는 프로젝트들이 늘고 있으며, 전체 CPU 자원에서 AI 코드가 차지하는 비율도 더 커지고 있다는 점도 이야기했었다.

올해 토론회에서는, 무엇보다도 자원 경쟁이 끝났다는 점이 명백해졌다(그림 1). 토론회에 참석한 개발자 중 거의 80% 정도가 자신의 현재 또는 이전 프로젝트에서 적어도 한 명이 AI를 전담했다고 말했다. 또한 둘 이상의 개발자들이 AI를 전담한다는 경우도 약 대략 3분의 1 정도가 되었다. 이러한 프로그래밍 자원에서의 급격한 성장은 실제로 지난 수 년간 발매된 게임들의 AI 품질이 상당히 증가되었다는 결과를 낳았으며, 하나의 개발 팀에 적어도 한 명, 경우에 따라서는 두 명 이상의 AI 전담자가 있다는 것은 현재 업계나 시장의 현실을 볼 때 거의 최대치에 달한 것이라고도 할 수 있다.

그림 1: GDC 2000 토론회에서의 설문 조사 결과

더욱 흥미로운 것은, AI 개발자들이 차지할 수 있는 CPU 자원의 양이다. 평균적으로 AI 개발자들은 이제 CPU 사이클의 25% 정도를 차지하는 것으로 나타났다. 이는 1999년 토론회에서 나왔던 수치의 250%나 되는 것이다. 작년과 올해의 CPU 수준차를 생각해 볼 때, 게임의 AI가 차지하는 CPU 자원은 엄청나게 증가한 셈이다.

또한 많은 개발자들이 게임 AI에 대한 일반적인 태도 자체가 변했다는 말을 했다. 작년의 주문이 "프레임율을 떨어뜨리지 않는 한도 안에서 해결해!"였던 것에 비해, 올해는 AI라는 것이 게임의 다른 측면들만큼이나 중요하다는 인식이 개발팀 전체에서 자리잡고 있는 듯하다. 믿거나 말거나, 몇몇 프로그래머들은 "새 그래픽 기능이 멋지긴 하진만, AI 속도를 늦추지 않는 한도 안에서 해결해!"라는 말을 다른 동료들에게 한다고까지 말했다. 이것이 바로 게임 AI의 중요성에 대한 인식이 증가한다는 것을 증명하는 좋은 예가 아닐까...

또한 개발자들은 자원 문제에 대해 별 걱정이 없어 보였다. 몇몇 개발자들(특히 턴방식 게임을 만드는 사람들)은 컴퓨터 유닛의 AI를 위해 실질적으로 컴퓨터 자원의 100%를 사용해야 한다고 동료들에게 말한다고 한다. 물론 그들은 자원을 더 많이 사용한다고 해서 항상 더 나은 게임 플레이가 가능해 지는 것은 아니고, 단지 더 깊은 게임 플레이가 되는 결과가 되는 경우가 많다는 점을 인정했다(그런데, 재미있는 것은 토론회에 참가한 턴방식 개발자들 모두가 일종의 전략 게임들을 만들고 있다는 점... 흥행을 위해서는 실시간 전략 게임을 만들어야 한다는 점은 무시하는 듯..). 거의 모든 개발자들이 CPU 효율을 높이기 위해서 뿐만 아니라 AI 부분이 게임 엔진의 다른 부분들과 독립적으로 돌아가게 하기 위해서 어떤 형태로든 스레드를 적극적으로 사용한다는 점도 주목할만 하다.

AI 개발자들은 3D 그래픽 카드들의 성능 향상 덕분에 AI에 CPU 자원을 더 많이 투여할 수 있게 되었다는 말을 많이 했다. 이제는 그래픽 프로그래머들에게 할당해야 할 CPU 자원의 양이 적어도 문제가 없는 것이다...

작년 이후의 경향

1998년, 1999년 GDC에서 언급된 여러 AI 기술들이 작년 동안 더욱 성장하고 가속화되었다. 최근 몇 달 간 흥미로운 AI를 강조하며 출시된, 그리고 실제로 그 덕분에 흥행에도 성공한 몇몇 게임들을 볼 때, 업계의 전문적 기술 수준이 높아지고 있다는 점은 확실한 것 같다. 그럼 몇 가지 경향들을 살펴보자.

인공 생명 : 1999년 GDC 이후 가장 명백한 경향은 인공 생명 기술을 사용한 게임의 물결이다. 맥시스의 심즈에서부터 CogniToy의 Mind Rover에 이르기까지, 개발자들은 자신의 게임 캐릭터들이 좀 더 사실적이고 생명체와 비슷한 행동을 하도록 만드는데 인공 생명 기법들로부터 많은 힌트를 얻고 있다.

그림 2 : 미로 안을 이동하는 스마트 로버 - CogniToy이 Mind Rover 중 한 장면

인공 생명 기법의 위력은 실세계의 살아 있는 유기체들에 대한 연구에서 비롯된 것이다. 인공 생명은 살아 있는 생명체들의 행동을 흉내내는 방법을 찾는 분야라고 할 수 있으며, 초기에는 규칙들을 일일이 코딩하는 방법이 쓰였지만, 그 이후 유전자 알고리즘, 플로킹 등 다양한 기법들이 창안되었다. 이러한 기법들의 핵심은, 복잡한 행동(예를 들어 음식을 만드는 것)의 다양한 행동 방식들을 일일이 식별하고 그것들을 일일이 코드로 만드는 것이 아니라, 문제를 좀 더 작은 조각들로 나누고(예를 들어서 냉장고를 열고, 접시를 꺼내고, 전자 렌지에 넣는다), 그것들을 일종의 의사 결정 계통 구조로 연결시키는 것이다. 게임 캐릭터는 자신의 요구를 만족시키기 위해 취해야 할 행동 방식을 그러한 의사 결정 계통 구조 안에서 찾고 그것이 가리키는 특정한 행동을 하게 되며, 결과적으로는 매우 복잡한 행동을 무리 없이 해내는 것으로 보이게 된다. 저수준에서 일어나는 행동(명시적으로 하드 코딩된 행동)과 캐릭터의 동기/요구에 의해 결정되는 고수준의 행동 사이의 상호 작용에 의해, 모든 행동 방식들을 일일이 복잡한 코드로 만들지 않고도 좀더 사실적이고 "지능적인" 행동이 일어나게 된다 (역주: 인공 생명(적어도 게임이나 디지털 애니메이션에서 쓰이는)의 핵심은, 비교적 간단한 규칙을 가진 개별 개체들이 군집을 이루고 서로 상호작용함으로써 매우 복잡하고 사실적인 행동을 만든다는 점이다. 고전적인 Life 게임이나 플로킹이 대표적인 예이고, 심즈 이외에 최근 가장 주목할 만한 것은 - 게임은 아니지만 - 2000년 6월에 문을 연 sodaplay.com이다. sodaplay의 모델은 두 종류의 질점(고정점과 자유점)과 두 종류의 연결선(스프링과 근육)들로만 이루어지며, 질점의 자유 낙하나 연결선의 진동, 주기적인 확장과 수축 같은 아주 간단한 규칙들만으로 살아 있는 곤충 같은 행동 방식을 표현한다).

단순하지만 매우 놀라운 행동을 나타낼 수 있다는 이러한 접근 방식은 작년 동안 많은 개발자들의 관심을 끌게 되었으며, 이를 구현한 게임들도 많이 나왔었다. 가장 유명한 것은 아마 심즈(The Sims)일 것이다. 이 게임은 맥시스의 공동 설립자이자 심즈의 설계자인 Will Wright가 이름을 붙인 "똑똑한 환경(smart terrain)"이라는 기법을 사용한다. 게임 안에서 모든 캐릭터들은 다양한 동기와 요구들을 가지며, 주변 환경은 그들의 요구를 만족시키기 위한 다양한 수단들을 제공한다. 환경의 각 객체들은 자신 주변에 있는 캐릭터에게 자신이 무엇을 제공할 수 있는지를 알려 준다. 예를 들어서, 배가 고픈 캐릭터가 냉장고 앞으로 다가가면 냉장고는 "난 음식이 있어"라고 말하며, 캐릭터는 그 말을 듣고 냉장고에서 음식을 꺼내서 먹을 것인지를 결정하게 된다. 음식 자체는 캐릭터에게 "나는 요리를 해야 먹을 수 있어"라고 알려 주며, 전자 렌지는 "나는 요리를 할 수 있어"라고 알려주는 식이다. 이들은 캐릭터가 하나의 행동에서 하나의 행동으로 자연스럽게 이동할 수 있도록 이끌어 주는데, 이런 방식 대신 다양한 주변 객체들에 대한 구체적인 행동 방식들을 일일이 캐릭터에게 기억시켜야 했다면 프로그래밍이 매우 복잡해졌을 것이다.

그림 3 : Sims에서 핵심적인 역할을 하는 것이 바로 인공 생명 기법이다.

개발자들은 이러한 접근 방식의 가능성을 명확히 받아 들였으며, 토론회에서도 많은 이야기가 진행되었다. 다른 장르에서의 활용에 대한 아이디어들도 많이 나왔다. 예를 들어서, 일인칭 슈팅 게임 안의 한 방에 지뢰들이 깔려 있다고 하자. NPC가 개별적으로 지뢰들을 식별하고 피하게 하는 것보다는, 지뢰들이 NPC들에게 "조심해"라고 말해 주는 것이 훨씬 더 간단하고 효율적이다. 토론회에서는 이런 식의 아이디어를 말하는 사람들이 매우 많았기 때문에, 내년에는 아마 다양한 인공 생명 기법들을 사용하는 게임들이 더욱 많이 나올 것 같다.

길찾기. 작년 토론회와 비교했을 때 주목할만한 점은, 올해에는 길찾기(path-finding)에 대한 질문이 별로 나오지 않았다는 것. 가장 선호하는 길찾기 알고리즘은 역시 A* 알고리즘(좀 더 자세한 정보는 Bryan Stout의 Smart Moves: Intelligent Path-Finding을 참고할 것. (역주: 책선전! Game Programming Gems에는 무려 네 개의 섹션들에서 A*와 길찾기를 이야기합니다...약 50여 페이지...)로 밝혀졌으나, 모두 자신의 구체적 프로젝트에 맞게 나름대로의 변형과 개선을 가하고 있었다. 방법은 조금씩 달라 보여도 결국은 모두 A*를 사용하고 있었던 것..... 또한 대부분의 사람들이 영향력 맵, 끌개-밀치개(attractor-repulsor) 시스템 (역주: 이건 맵에 미리 일정한 길찾기 정보를 부여해 두는 방식을 말하는 것 같다. 빠른 길은 캐릭터를 끌어 당기고, 장애물은 캐릭터를 밀치는 등등), 플로킹 같은 기법들도 적극 활용하고 있는 것으로 보였다. 개괄하자면, 길찾기에 한해서는 게임 개발계가 일정한 해결책을 이미 찾아낸 것이며 이제는 특정 게임에 대한 특수한 구현(3D 공간에서의 길찾기, 경로의 계통적 구조화를 통한 최적화, 경로가 막혀 있는지를 효율적으로 식별하는 방법 등등)으로 초점이 이동한 것이라 할 수 있다.

그림 4. Ensemble Studio의 Age of Empires II: The Age of Kings - 지형 분석을 포함시킴으로써 좀 더 새로운 길찾기를 구현했다.

개발자들이 길찾기 문제를 무리 없이 다룰 수 있게 됨에 따라, 이제는 지형 분석을 통한 복잡한 길찾기의 문제를 해결하는 단계로 접어들 수 있게 된 것 같다. 지형 분석은 AI가 지형을 연구하고 다양한 자연적 지형들을 식별하는 것으로(예를 들어 유닛들이 고립될 수 있는 협곡이나 적의 매복이 있을만한 장소 등등), 단순한 길찾기보다는 훨씬 더 복잡한 문제이다. 지형 분석을 제대로 해낼 수 있으면 다중적인 "해상도"들로 된 게임 맵에 대한 정보를 게임 AI에 제공할 수 있으며, 이를 통해서 좀 더 복잡한 길찾기 문제를 해결할 수 있게 된다. 또한 지형 분석은 AI가 맵의 각각의 장소들에 대한 지식을 가지게 하는 것에도 도움이 되며, 그러한 지식을 통해서 AI의 많은 과제들 (역주: 예를 들어서 유닛들을 어디로 집중시킬 것인가, 어디에 숨겨 둘 것인가 등등)을 좀 더 쉽게 해결할 수 있다. 그러나 요즘 게임들이 흔히 가지고 있는 기능들 중 하나인 랜덤 지형 맵 생성 기법으로 생성된 생성된 맵에 대해 지형 분석을 수행하는 것은 상당히 어려운 문제이다 (역주: 이는 게이머가 맵 에디터로 맵을 만드는 경우에도 마찬가지). 지형이 무작위적으로 생성된다는 것은 개발자가 맵을 미리 분석해서 적당한 정보를 끼워 두고 게임 AI가 그것을 이용하게 하는 일이 불가능하다는 것을 의미하기 때문이다.

작년 토론회 이후에 출시된 몇몇 게임들 중에는 지형 분석을 시도한 것들이 있었다. 예를 들어서 Ensemble Studios는 Age of Kings에서 전작과는 전혀 다른 접근 방식을 사용했다. 상당히 복잡한 지형 분석 능력을 부여한 것이다. 또한 금광이라던가 건물을 놓을만한 가장 이상적인 자리 등의 주요 장소들을 결정하는데 영향력 맵 (역주: 영향력 맵, influence map은 말 그대로 세력 분포도를 얻기 위한 것. 개념적으로 설명한다면, 맵을 철판으로, 적 유닛을 얼음으로, 아군 유닛을 난로로 생각하면 된다. 얼음들과 난로들에 의한 열전도에 따라 철판의 온도 분포가 달라지며, 뜨거울 수록 아군이 장악하고 있는 곳이고 차가울 수록 적이 장악하고 있는 곳으로 간주하는 방식이다. 물론 이것은 비유일 뿐이고, 구현 방식은 다양하다. "전선(border line)은 어디인가"라는 질문에서 비롯된 게임 AI 뉴스그룹의 토론으로부터 나온 영향력 맵은 게임 AI 관련 뉴스그룹 활동의 기념비적인 성과라고 할 수 있다.)을 활용하기도 했다. 영향력 맵은 수송 지점이나 공격 경로를 식별하는데에도 쓰였다. AI는 알려진 적 건물들의 영향력을 파악하고, 그것에 기반해서 미리 들키지 않으면서 적이 장악한 영역으로 습격할 수 있는 경로를 찾는다.

 

지형 분석을 흥미롭게 사용한 또 다른 게임으로는 Red Storm의 Force 21을 들 수 있다. 이 게임의 개발자들은 가시성 그래프(오른쪽 박스의 "가시성 그래프" 참고)를 이용해서 게임의 지형을 개별적인, 그러나 서로 연결된 영역들로 나눴다. AI는 그것들을 이용해서 서로 다른 해상도에서의 길찾기를 수행한다. 맵들을 "갈 수 있는 곳(보이는 곳)"과 "갈 수 없는 곳(보이지 않는 곳)"으로 적절히 영역을 나누어 두면, AI는 유닛들에게 고수준의 이동 명령만 지시하고 구체적인 이동 방식(장애물에 부딪히지 않는 것, 다리를 건널 것인지 그냥 개울을 건널 것인지 등등)은 유닛들에게 맡길 수 있다. 유닛들 주변의 국소 영역에서는 A* 알고리즘으로 길을 찾게 하면 되므로, 다른 AI 과제들에 더 많은 CPU 자원을 돌릴 수 있다는 추가적인 장점도 생긴다 (역주: 흔히 계통적 길찾기라고 하는 기법. 게임 세계 안의 모든 타일들에 대해 길찾기를 수행하는 것이 아니라, 예를 들어 세계 맵, 대륙 맵, 나라 맵, 마을 맵, 마을 안의 건물 맵 식으로 나누고, 대륙과 대륙, 나라와 나라, 마을과 마을 사이의 연결 정보를 설정해 두면 길찾기가 대단히 간단해 진다. 한 나라의 한 던젼의 지하 9층에서 다른 나라의 한 성의 옥좌까지 길을 찾는다고 생각해 보라..).

대형 - 길찾기 주제와 밀접한 관련을 가진 것이 바로 유닛들의 대형 문제, 즉 일단의 유닛들이 좀 더 사실적으로 이동하게 하는 문제이다. 올해 토론회에서는 몇몇 개발자들만이 자신의 게임에서 대형 기능을 구현하고 있다고 밝혔지만, 그렇지 않은 개발자들도 대형 문제에 큰 관심을 보였다(아마 최근 대형 기능을 가진 게임들이 많이 나왔기 때문인 것 같다). 대형 기능을 구현하는 대부분의 개발자들은 비교적 엄격한 규칙 기반 시스템을 가진 일종의 플로킹 기법을 사용해서 유닛들이 어떻게 움직이고 어떻게 대형을 유지하는지를 결정하는 편이었다. 스포츠 게임을 만들고 있는 한 개발자는 "플레이북" 접근 방식(축구 코치가 사용하는 것과 비슷한)을 고려하고 있다고 말했다.

상태 기계와 계통적 AI. 신경망이나 유전자 알고리즘같은 좀더 "학술적인" 기술들보다는 간단한 규칙 기반의 유한 상태 기계 또는 퍼지 상태 기계(FSM과 FuSM)를 선호하는 경향은 여전했다. 개발자들은 개념적으로 간단한 상태 기계 쪽이 이해하거나 구현, 디버깅하기 쉬우며, 인공 생명 기술을 이용한 게임들에서 볼 수 있는 캡슐화 종류들과도 잘 맞아 떨어진다고 받아들이고 있었다.

주목할 것은 상태 기계들을 새로운 방식으로 사용하고자 하는 움직임이었다. 복잡한 AI 결정 과정을 일련의 작고, 정의하기 쉬운 단계들로 나누는 데 인공 생명을 사용하는 것과 비슷한 이유 때문에 개발자들은 AI 설계에 계층적인 또는 계통적인 접근 방식을 받아들이고 있었다. Interplay의 Starfleet Command와 Red Storm의 Force 21이 그런 접근 방식을 사용했다. "장군", "사령관"들은 자신이 지휘하는 전술적 부대들에게 일반적인 이동과 공격 명령을 내리고, 각 부대의 야전 사령관 또는 전술가들은 자신이 받은 명령에 기반해서 개별 유닛들에게 좀 더 구체적인 이동과 공격 명령을 내리는 방식이다.

토론회 참석자들 중 전략 게임을 만들고 있는 개발자들은 대부분 이러한 계층적 접근 방식을 이미 구현하고 있거나 구현할 계획이라고 말했다. 이러한 방식은 좀 더 사실적인 결과를 얻을 수 있을 뿐만 아니라, 디버깅도 단순하게 만든다. 그러한 대부분의 개발자들은 구체적인 전술적 명령 수행 방식은 코드 상에 고정시켜 두되 전략적 수준의 AI는 사용자가 직접 조정, 변경할 수 있도록 하는 용도로도 이러한 계층적 접근 방식을 사용한다고 밝혔다. 이러한 것은 게이머가 전략 게임을 좀 더 재미있고 오래 즐길 수 있도록 고안된 게임들, 예를 들어서 Stars나 Empire of Fading Suns, Alpha Centauri 등에서 볼수 있는 주요한 경향이다.