[아카이브] 울티마 온라인의 리소스 시스템

[Zerasion 4]

sequoia 님이 작성하셨던 포스팅의 아카이빙입니다.

---

 

이 글에서 스레드 분리되었습니다.

파파랑님의 주변 친구 2 입니다. :-) 라프 코스터의 해당 포스팅은 제가 번역했던 게 있는데, 워낙 영어 실력이 짧은데다 대충 아는 사람끼리 공유하느라 음슴체로 번역해놔서 그대로 올리기는 좀 민망하네요.

일단 어투를 바꾸고 좀 곁가지로 샌 부분 쳐내면서 의역을 해봤습니다. 줄인다고 줄였는데도 내용이 꽤 기네요. "시뮬레이션의 꿈"의 주제의식과 라프 코스터의 지향점은 좀 다른 것 같은데, 일단 아래 글도 라프코스터가 2006년에 올린 글이니까 감안해서 보시면 될 것 같습니다.

0. (시뮬레이션의 꿈 아티클에 달린 라프 코스터의 댓글에서)
울온이 구체적인 예로 들어진 김에 말하자면, 울온은 내부에선 엄청 심플하게 만들려고 노력했고 실제로 그 시뮬레이션은 매우 심플합니다. 물론 액터 숫자만으로도 복잡성의 함정에 빠지게 되었지만, 관련해서 아래와 같은 글을 썼습니다. (이게 이번에 번역한 글) 그 중 마지막 파트가 정확히 이 글(시뮬레이션의 꿈)에서 말하는 문제에 대한 것입니다.

http://www.raphkoster.com/2006/06/03/uos-resource-system/
http://www.raphkoster.com/2006/06/04/uos-resource-system-part-2/
http://www.raphkoster.com/2006/06/05/uos-resource-system-part-3/

그러나 울온에서 위 시스템에 기반해서 만든 것 중 많은 성공적인 요소가 완전히 아포페니아 디자인에 대한 것입니다. 이에 대해서도 글을 썼습니다.

http://www.raphkoster.com/2006/06/09/why-dont-our-npcs (이건 번역하지 않았습니다.)

1.
라프 코스터는 리소스 시스템 디자인과 함께 "드래곤 시나리오"를 오리진 입사 지원서에 첨부했는데, 그 시스템 디자인이 울온의 핵심 메카닉으로 채택되면서 오리진에 입사할 수 있게 되었습니다. 드래곤 시나리오는 시뮬레이션의 꿈에도 인용된 그 내용이죠.

인용

"토끼 개체수가 갑자기 감소하면(어떤 열정적인 모험가가 새로 얻은 철퇴를 시험했다고 해봅시다), 늑대는 사슴 같은 다른 먹잇감을 찾아야만 할 겁니다. 그 결과로 사슴의 개체수가 감소하면, 그 지역의 드래곤이 익숙한 먹이를 찾을 수 없게 되어 지역 마을을 공격하게 되는 거죠. 이 모든 게 자동적으로 일어나기 때문에, 이것들은 어마어마한 모험의 가능성을 만들 겁니다."

원래의 게임 메카닉대로라면 위 상황을 타개하기 위해 플레이어들은 드래곤을 죽이거나 드래곤에게 먹이를 바치는 방법으로 마을을 지킬 수 있었어야 합니다. 그러나 당시(1995년) 기술로는 드래곤이 먹이를 찾기 위해 주변 탐색을 할 수 있는 범위가 한 화면 정도에 불과했고 그나마도 너무 느렸기 때문에 실제로 현실화되지 못했죠.

2.
위와 같은 시스템을 만들기 위한 아이디어는 기존 MUD의 제작 시스템을 개선하기 위한 아이디어에서 출발했습니다. 원래 전통적인 MUD에서는 아이템이 "마스터 카피"의 ID를 갖고 있고 마스터 카피의 특성을 이용해서 생성되는 방식이었고, 제작 시스템은 레시피 시스템으로 되어있었습니다. 그런데 레시피 시스템은 기본적으로 테이블을 관리하는 방식이고 나무 재료를 추가할 때 마다 나무와 관련된 테이블 전체를 엎어야 하는 시스템이었습니다.

새로운 아이디어의 핵심은 오브젝트에 추상화된 속성을 넣어 오브젝트가 "나무로 만들어졌음"을 추적할 수 있게 만들고 레시피는 재료 오브젝트에 "나무로 만들어졌는지"를 확인하게 만드는 방식이었습니다. 즉 아이템이 어떤 재료로 사용될 수 있는지를 리소스의 집합으로 표현한 것이죠. (이 때까지는 리소스가 "라벨"일 뿐이었지만 나중에 swg에서는 스탯 있는 리소스 개념을 추가했습니다.) 울온 코어 팀의 노력으로 리소스 시스템이 발전하게 되었습니다.

울온에서 대부분의 오브젝트는 4가지 타입의 리소스의 "라벨"을 갖고 있습니다. (울온에서의 오브젝트는 아이템, 자연물, 인공물, NPC, 플레이어를 모두 포괄합니다.)

PRODUCTION :
오브젝트의 "재질"을 의미합니다. 자연물이라면 이 타입의 리소스를 계속 생산해내기 때문에 regrowth rate가 있고, 인공물이라면 regrowth rate는 없고 재질만을 나타내겠죠. 이 리소스 타입은 모든 오브젝트에 붙어있고, 나머지 리소스 타입은 AI와 관련이 있습니다.

FOOD :
오브젝트가 먹는 음식을 의미합니다. 오브젝트는 FOOD타입의 오브젝트를 근처에서 찾고, 찾아가서 먹습니다. 이 리소스 타입에는 bite size(입 크기)와 stomach size(배 크기), 그리고 최소 관심 크기가 있어서 한 번에 bite size씩 먹고 stomach size가 찰 때 까지 먹는데, 최소 관심 크기 이하를 PRODUCTION하는 오브젝트는 관심을 갖지 않고 지나칩니다.

SHELTER :
오브젝트가 집으로 삼는 타입의 리소스입니다. 오브젝트는 SHELTER 타입의 오브젝트를 근처에서 찾고, 적당한 크기(이 값도 정의되어 있겠죠?)라면 둥지(lair)로 삼습니다. 배가 부르면 둥지로 돌아옵니다.

DESIRE :
오브젝트가 좋아하는 리소스입니다. 배도 부르고 둥지도 마련했다면 이 타입의 리소스를 찾아다닙니다. 찾으면 둥지로 가져옵니다. 가져올 수 없다면 둥지로 돌아가는 대신 이 리소스 근처를 배회합니다. aversion 플래그를 켜면 좋아하는 대신 무서워하거나 피합니다.

마슬로우의 욕구 단계 이론처럼 오브젝트는 FOOD->SHELTER->DESIRE 순으로 만족하려고 합니다.

예를 들어 토끼 오브젝트는 다음과 같습니다.
PRODUCTION : FUR(약간, 리젠 안됨), MEAT
FOOD : GRASS, FLOWER, VEGETABLE (매우 작은 입 크기, 작은 배 크기)
SHELTER : GRASS, BUSH (BUSH를 둥지로 삼음)
DESIRE : aversion CARNIVOREMEAT

늑대 오브젝트는 다음과 같습니다.
PRODUCTION : FUR(중간 양, 리젠 안됨), CARNIVOREMEAT
FOOD : MEAT (중간 입 크기, 작은 배 크기)
SHELTER : TREE, CAVE (CAVE를 둥지로 삼음)
DESIRE : aversion CARNIVOREMEAT

늑대 같은 경우 무리짓기 AI가 있어서 서로 가까이 있고 싶어하고 무리의 입 크기/배 크기를 더합니다.

위의 드래곤은 다음과 같이 됩니다.
PRODUCTION : SCALE(중간 양, 리젠 안됨), CARNIVOREMEAT(매우 많은 양)
EAT : MEAT, CARNIVOREMEAT (큰 입 크기, 매우 큰 배 크기)
SHELTER : MOUNTAIN, CAVE (CAVE를 둥지로 삼음)
DESIRE : GOLD, GEM, MAGIC

3.
월드에서도 리소스가 생산되는데, 모든 걸 오브젝트로 만들기엔 서버 용량이 무리가 있어서 8x8 청크마다 청크 알(chunk egg)라는 보이지 않는 오브젝트를 만들었습니다. 청크 알은 청크의 static 지형 데이터를 분석해서 해당 청크에서 어떤 리소스를 생산할 지 판단합니다. 나무가 있으면 WOOD를 생산하고, 광맥이 있으면 ORE를 생산하는 식으로 작동하는데, 유저 눈에 보이는 건 static 데이터이기 때문에 유저가 보기엔 나무 하나만 베면 8x8지역의 나무가 다 빨려나오는 걸로 보이는 부작용(?)이 있습니다.

그래서 숫자가 적은 오브젝트는 그냥 다이나믹 오브젝트로 배치하고 다이나믹 오브젝트는 직접 리소스를 생산하기도 하지만 오브젝트에 스크립트를 코딩해서 붙일 수도 있었습니다. 당연히 라이브 단계에서는 버그의 온상이 되었고(...) 라프코스터가 울온에서 손 뗀 뒤로는 더욱 버그의 온상이....

주제와는 관계없는 얘긴데 어떤 사람이 "날" 스크립트에다가 플레이어 시체도 자를 수 있는 코드를 넣었다가 인육 먹는 게임이 된 적도 있다고 합니다.

오브젝트가 스폰될 때는 PRODUCTION에 있는 리소스를 월드에 좀 가져오는 셈인데, 전역적인 리소스 은행을 두고 월드 전체에 퍼진 리소스의 양을 제한했습니다. 즉 월드에서 특정 리소스가 파괴될 때 리소스 은행으로 가져오고, 스폰될 때 리소스 은행에서 리소스를 내주는 방식이죠. 리소스 은행에 고기가 없다면 스폰될 때 고기가 필요한 토끼 같은 동물이 더이상 스폰되지 않습니다. 이걸 "닫힌 경제"라고 부릅니다.

오브젝트 스폰은 자연발생설을 따라(...) 잔디가 많은 곳에서는 잔디 먹는 오브젝트가 생성되고 고기가 많은 곳에는 고기 먹는 오브젝트가 생성되는 식이었는데, "스폰 영역"을 지정해서 영역마다 예를 들면 잔디 먹는 오브젝트가 필요할 때 이 영역에는 토끼를, 저 영역에는 사슴을 스폰하는 식으로 지정할 수 있었습니다.

위에서도 말했듯 늑대는 무리짓기 AI가 있었는데, 혼자 있을 때는 자기 입 크기보다 큰 고기를 생산하는 사슴을 공격하지 않는데, 무리를 지으면 입 크기를 더하기 때문에 늑대 무리는 사슴을 공격하게 되었습니다. 사슴이 없으면, 사람도 공격합니다.

근데 이렇게 배고플때만 공격하게 만드니까 늑대가 항상 위협적인 건 아니었는데, 게임플레이 상 어떤 동물은 항상 위험하길 바라는 팀원이 있어서 "어그로"시스템을 넣게 되었습니다.

어쨌든 그래서 플레이어가 토끼를 너무 열심히 잡으면 늑대는 먹을 토끼가 없으니 무리를 지어 사슴을 사냥하고, 드래곤은 평소에 먹던 사슴이 너무 적어지니 음식을 찾기 위해 탐색 범위를 넓히다가 탐색 범위가 플레이어 마을까지 넓어지면 마을을 공격하게 되는 거죠.

근데 이 탐색 연산 자체가 너무 비싸서 최적화를 좀 했는데, 일단 탐색을 좀 자주 안 하게 해도 안 되어서 유저가 안 보는 곳에 있는 오브젝트는 잠든 상태로 만들어버렸습니다. 당연히 이렇게 하면 큰 스케일의 월드 시뮬레이션은 망했고......

그리고 리소스 수요를 제대로 조사를 못 해서 문제가 생겼는데, 유저가 고기는 먹어 없애지만 모피FUR는 인벤에 쌓아뒀기 때문에 모피가 없어서 토끼가 리젠 안 되는 현상이 생겨버렸습니다.

게다가 굳이 이런 거 이렇게 열심히 만들어야 되냐 싶은 생각을 가진 팀원들도 있었는데, 베타 때 구현 책임자가 그런 사람 중 하나라서 결국 알파 때는 좀 된다 싶던 게 베타 때는 하나도 작동하지 않게 되었습니다. (ㅜㅜ)

4.
울온의 마이닝 시스템은 변성transmutation이라는 방식으로 만들어졌습니다.

위에서 말한 청크 에그가 맵의 static데이터를 분석해서 "광맥pile of ore"이라는 오브젝트가 있으면 광물ORE 리소스를 생산했는데, 그 광물의 종류가 철IRON이냐 구리COPPER냐에 따라서 광맥의 렌더링 색깔을 바꿔줘야 했기 때문에 오브젝트에 변수 값을 저장할 수 있는 object variable (objvar)라는 기능을 사용했습니다. 

그래서 ORE를 생성하는 청크 에그의 objvar에 금속 타입을 랜덤하게(타입 별로 레어도 차이는 두고) 설정하는 스크립트를 넣고, 렌더링할 때도 금속 타입에 대해 색깔을 룩업하는 테이블을 두어 색깔 차이를 주고, 실제로 플레이어가 채광핬을 때 생성된 ORE 아이템에 청크 에그의 금속 타입 objvar를 전송transfer했습니다.

마찬가지로 ORE를 제련해서 METAL 주괴로 만들 때도 ORE 아이템의 금속 타입 objvar를 주괴 아이템에 전송하고, 실제로 갑옷을 생성할 때도 마찬가지 방법으로 했는데, 두 가지 이상의 타입의 금속으로 아이템을 생성했을 때는 아마도 더 흔한 금속 타입을 받도록 했던 것 같습니다.

나중에 swg에서는 이 방법 대신 IRON 리소스 타입과 COPPER 리소스 타입이 METAL 리소스 타입을 상속받는 방식으로 만들었습니다.

변성을 사용해서 여러 가지 다른 짓(?)도 할 수 있었는데, 돌 마법사는 ORE를 MAGIC으로 바꿀 수 있다든가, 드루이드의 힘은 근처의 GRASS나 TREE의 양에 영향을 받는다든가, 네크로맨서는 누가 죽을 때마다 청크 에그에 DEATH리소스를 축적해놨다가 "mine death magic" 스킬로 퍼갈 수 있게 한다든가 하는 식으로 만들었습니다. 네크로맨서는 이런 식으로 희생용 제단도 만들고 죽음의 사원도 만들고...

이거 말고도 청크 에그에 흔적을 남기게 해서 "진짜 추적"을 만든다든가, MAGIC과 METAL을 합쳐서 MITHRIL을 만들게 한다든가, 드래곤의 불이 진짜 불을 붙게 만든다든가, KARMA나 REPUTATION을 만든다든가, HUMIDITY가 GRASS의 리젠율과 METAL의 녹스는 속도(decay rate)에 영향을 주게 만든다든가 하는 식으로 응용이 가능할 듯 합니다.

5.
그런데 여기에 빠진 게 바로 "인과율"입니다. 드래곤 예시를 보면, 드래곤이 배고파서 온건지 랜덤 스폰으로 온 건지 플레이어가 분간할 수가 없는 거죠. 죽여버리면 편하지만 먹을걸 줘서 해결이 가능한지는 알 방법이 없는 거.

좀 다른 예를 들어서, 농작물을 토끼가 먹어치우면 농부가 토끼를 싫어하게 만들 수는 있는데, 실제로 농부가 플레이어에게 "토끼가 내 농작물을 먹어치우고 있어. 토끼를 죽여줘"라고 말하게 만들고 싶은 거죠.

이 부분은 만들자고 제안했지만 못 만든 건데, 농부는 농작물을 DESIRE하고, 토끼는 농작물을 EAT하기 때문에, 농부에게 "그가 DESIRE하는 자원을 갖고 경쟁하는 상대를 싫어하기"라는 템플릿을 넣어놓을 수 있게 만드는 거죠. 플레이어가 토끼를 죽이면 농부가 보상을 지급하는 걸 정적인 퀘스트를 만들어넣지 않고도 구현할 수 있게 되는 겁니다. 만약 토끼를 다 잡았더니 사슴이 와서 농작물을 먹는다면? 이제 농부가 사슴을 잡는 플레이어에게 보상을 주겠죠.

아까 드래곤의 예로 돌아가면, 마을 사람이 다른 마을 사람을 DESIRE하게 하면 마을 사람을 잡아먹는 드래곤을 잡는 플레이어에게 마을 사람이 보상을 줄 수 있겠죠. 녹 괴물이 마을의 금속을 잡아먹으면, 마을 사람 중에 금속을 DESIRE하는 대장장이만 녹 괴물에 현상금을 걸겠죠.

이거 구현이 좀 까다로운 게 농부에게 기억력registry을 줘야 되고 토끼를 제3의 오브젝트인 농작물을 통해서 농부에게 기억시켜야 하는 데다가 플레이어 액션도 제 3의 오브젝트인 토끼를 통해 농부에게 릴레이되어야 했었죠.

구현이 까다롭다보니 우선순위에 밀리고 급한 일 처리하느라 결국 구현을 못 했습니다.

사실 이거 제안할 때 테스트 케이스는 삼각관계였습니다. Bob도 HUMANFEMALE을 DESIRE하고 Fred도 HUMANFEMALE을 DESIRE하다가 둘 다 Nellie에게 정착하면 서로의 DESIRE를 두고 경쟁하는 상대방을 죽여달라고 플레이어에게 부탁하는 거죠. 그러다 Nellie가 드래곤에게 잡혀먹히면 둘 다 드래곤을 죽여달라고 플레이어에게 부탁하고(...)

이거 말고도 NPC의 이동경로를 수동으로 세팅하기보단 피로도FATIGUE를 도입해서 밤엔 자게 한다든가, 하루의 시간이 지나감에 따라서 SHELTER가 집이었다가 일터였다가 바뀌게 한다든가, 준법시민은 DARK를 aversion하게 해서 도둑들이 어둠속으로 다니게 한다든가 하는 등의 아이디어가 있었습니다.

이쪽에서 제일 하이레벨 인터페이스는 마을에서 누군가 스토리를 외치고 다니게 만드는 거였죠. "농부 Hayseed가 농작물이 자꾸 망쳐져서 걱정이랍니다!" "Fred가 Nellie에 대한 질투 때문에 Bob을 죽였다고 합니다!!" 하는 식으로..

6. 문제들

리소스 시스템 구현은 대부분 동적으로 조립된 텍스트에 기반하고 있었는데, 로컬라이즈할 때 큰 문제가 되어서 많은 부분이 static text로 대체되고 대사들의 맛이 사라졌습니다.

이건 만들고 보니 거의 스폰과 기본적인 행동양식을 시뮬레이션하는 인공생명 시뮬레이터에 하이레벨 퀘스트 시스템을 합쳐놓은 수준이었습니다. 그런데 다음과 같은 요소가 없으면 이런 걸 열심히 만드는 게 별로 의미가 없을 것 같습니다.

* 플레이어에게 인과율을 드러낼 것. 그렇지 않으면 랜덤이나 마찬가지.
* NPC가 원하는 걸 플레이어에게 전달하고 원하는 걸 채워주면 응답하게 할 것.
* 스태틱 데이터는 가능한 피할 것. 근데 전통적인 게임 개발팀에선 좀 무리다.
* 변수들이 항상성을 가지게 할 것. 인공생명 시뮬레이터는 보통 발산하는데 플레이어에겐 재미없는 현상입니다.
* 리소스를 닫힌 계로 만들지 말 것. 플레이어가 리소스를 모아두는 게 큰 영향을 미친다.
* 길찾기와 탐색에 CPU자원이 엄청나게 드니까 구현 가능한 수준으로만 만들 것.

마지막 문제의 경우 옛날에 MUD제작 커뮤니티에서 이런 얘기를 좀 한 바에 의하면 시뮬레이션 수준에 LOD를 두거나, 마지막 인터랙션한 시간 타임스탬프를 찍어놓고 다음번 인터랙션할 때 한꺼번에 시뮬레이션하거나, 힐클라이밍+브로드캐스팅을 쓰는 방법 등이 있었습니다. 이미지 프로세싱 기술은 잘 최적화되어있으므로 여기에 활용할 수 있을 것 같습니다.

닫힌 계는 확실히 실수였는데 현실세계에서는 대부분의 리소스가 사실상 무제한이고, 제한이 있는 게 재미있는 경우는 보통 지역적으로만 리소스가 모자라는 경우입니다. 인과율을 드러내는 건 일이 좀 많긴 하겠지만 하면 될 것 같습니다.

7. 결론

마음속으로는 이 리소스 시스템을 여러 가지 방법으로 발전시킬 구상이 있습니다. 어느 시점이 되면 지금처럼 정적 데이터와 1회용 퀘스트를 산더미처럼 쌓아놓은 MMORPG보다 견고한 시뮬레이션 모델을 만드는 게 싸게 먹히게 될 겁니다.

솔직히 CPU를 혹사시키는 문제에 있어서는 이 시스템보다 3D 충돌 체크가 더 심할 거라고 보는데, CPU 파워가 점점 강해지고 있으니 더 많은 가능성이 열릴 겁니다.

오랫동안 일해오면서 핸드크래프트주의자에 비해 시뮬레이셔니스트들이 좀 힘든 길을 온 것 같습니다. CPU파워가 빨라지는 속도가 사람이 손으로 시나리오를 만드는 속도보다 빨라지고 있습니다. 언젠가는 현실이 1995년에 디자인한 그 세계를 따라잡게 되겠지요.

[Zerasion 4]

Voosco 님이 작성하셨던 리플라이의 아카이빙입니다.

---

 

뭔가 울컥하네요. 

오래전에 하던 어떤 프로젝트가 있습니다. 드랍되었기에 이후에는 진행하지 않았습니다만, 제가 그 프로젝트에서 해보고 싶었던 것에 미련이 많이 남아 아직도 가슴 한 켠에 간직(?) 하고 있거든요. 라프 코스터님이 써내려가신 내용들 중 여기에 겹치는 부분이 있고, 제가 생각지 못한 부분도 있고, 반대로 제 방법을 썼더라면 해결할 수 있었을텐데 ... 싶은 내용들도 있고 그러네요. 

왠지 오랜동안 혼자 고독하게(?) 추진해오던 어떤 일에 대해 다른 이들도 그걸 염두에 두고, 생각하고 있었고, 누군가는 추진도 하고 있었다는걸 알게되니 기쁜 마음이 들어 감상적인 얘기 적어봤습니다. 

좋은 글 감사합니다.

[Zerasion 4]

paparang 님이 작성하셨던 리플라이의 아카이빙입니다.

---

 

인용

뭔가 울컥하네요.

저도 이 형님 글 읽고 짠했습니다. 거의 20년전에 이런걸 만들려 했다니 :oops:

[Zerasion 4]

멋진 글 공유해주셔서 감사드립니다. =)

최근에 GTA나 SKYRIM 등에서 보여줬던 "각각의 라이프사이클을 갖는 AI" 정도의 구현력이라면,
위 본문에서 언급한 "라벨" 개념만 얹으면 바로 라프코스터의 구상대로 동작할 것 같다는 생각이 듭니다.

데들리던전의 주인장이신 껍질인간님이 스카이림이 가진 무한한 가능성 대비 게임 내에서 풀어낸 컨텐츠가 조악하기 짝이 없다고 혹평했던 게 오버랩되서 재미있네요.

닫힌 경제의 리소스 부분에서, 플레이어가 가져간 부분을 월드 리소스에서 제하는 방식으로 하면 "월드 내에 전체 리소스 량은 유지하면서 플레이어에게는 누적할 여지를 줄 수 있는" 식의 좀더 유연한 대처가 가능할 것 같다는 생각이 잠깐 들었지만, 역시 시뮬레이션 해봐야 결과를 알 수 있겠네요. ㅎㅎ

포럼에서 논의된 다른 많은 이야기들이 대체로 추상적인 개념 상의 논의가 많았던 데에 반해, 이 포스팅과 이전 스레드의 포스팅은 실제 구현 매커니즘을 설명하면서 예로 들고 있어 실무적으로 접근할 수 있다는 장점이 도드라지는 것 같습니다. =)

[Zerasion 4]

sequoia 님이 작성하셨던 리플라이의 아카이빙입니다.

---

 

다시 읽어보니 라프 코스터를 3인칭으로 지칭하면서 시작했다가 뒤로 갈수록 1인칭이 되는 이상한 글이 되었네요. :-( 송구스럽습니다.

저도 짧은 영어로 이 글을 읽다가 급 감동이 오면서 굳이 번역까지 하게 되었는데, 정말 라프코스터의 만감이 고스란히 전달되는 글이었습니다. 팀원들에 대한 존중과 섭섭함이 엇갈리고, 아쉬움이 진하게 묻어나오고, 심지어 후배 개발자로서 어떤 사명감까지 느껴지기도 했죠...

다들 아시겠지만 라프 코스터는 울온의 리드 디자이너로 일하다가 라이브 도중 스타워즈 갤럭시즈(SWG)의 크리에이티브 디렉터로 자리를 옮겼죠. 이 글에서도 종종 스타워즈 갤럭시즈에서 리소스 시스템을 어떻게 발전시켰는가에 대한 힌트가 나옵니다.

개인적으로 울온을 못 해본 게 큰 아쉬움으로 남는 반면, 스타워즈 갤럭시즈는 운좋게도(?) CU(컴뱃 업데이트) 이전에 해보면서 엄청난 충격을 받았던 기억이 있습니다. 제 마음속의 하드코어 시뮬레이션주의자는 그렇게 생겨났던 것 같네요.

그리고 울온과 SWG는 나란히 라이브와 여러 차례의 확장팩을 거치면서 기존 팬들의 거센 비난을 받았다는 공통점도 있죠(...) 개인적으로도 CU이전의 SWG가 그리운데, Pre-CU SWG를 프리서버로 복원하는 프로젝트가 있지만 안정성에 좀 문제가 있어서 즐기긴 어렵겠더라고요. 개인적으로도 저 프로젝트의 취지에 동감합니다. ㅜㅠ

국내에는 게임에서의 시뮬레이션의 디자인에 대한 논의가 거의 없었던 것처럼 보이는데, GDF에서 많은 이야기를 나눌 수 있으면 좋겠네요. :-)

[Zerasion 4]

Voosco 님이 작성하셨던 리플라이의 아카이빙입니다.

---

 

제 경험이 좁아서일지, 견문이 좁아서일지 ... 북미쪽 개발씬에 올라오는 개발에 관련된 아티클들을 읽다보면 느끼는 점은 이런 식의 거시적인 어떤 계(system)를 다루는 분야에 대해서는 상대적으로 글이 많지 않다는 느낌입니다. 여기서 비교의 대상은 플레이어 개인을 분류/분석하거나, 그 개인이 가진 개별적인 동기나 의도를 분류/분석하는 등의 작업들이 되겠죠. 특정한 게임 디자인 장치가 어떤 과정을 거쳐 플레이어에게 어떤 의도, 동기, 심상을 전달하는가에 대한 글들은 질적으로나 양적으로나 풍성하고 의견들도 다양하다고 느끼는데, 그런 플레이어들의 복잡한 동기나 의도들이 모여서 서로 충돌하는 상황 및 그 과정을 분석하고 어떻게 다룰 것인가에 대한 의견을 제시하는 글은 - 어디까지나 상대적으로, 게다가 전적으로 제 경험에만 의존해서 볼 때 - 다소간 부족한 느낌이거든요. 

이게 단순히 제가 보고들은게 한정적이라 그런건지, 아니면 각 문화권에서 주류를 차지하는 게임의 장르에 연관된 문제인지도 가끔은 궁금하더군요. 북미의 스탠드 얼론 중심에 약간의 멀티플레이가 옵셔널하게 끼는게 일반적인 게임들과, 우리나라의 온라인 디폴트에 다른 플레이어의 존재를 빼도박도 못하게 느끼면서 플레이해야하는 상황 사이의 차이가 낳은 결과인지 가끔 궁금하기도 합니다. 

어디까지나 개인적인 견해이지만, 이 글에서 라프 코스터가 보여주고 있는 규모와 깊이의 시뮬레이션은 사실상 스탠드 얼론 타입의 게임에서는 '그렇게까지는' 많이 필요하지 않을 듯 합니다. 그보다는 복잡하게 여러 사람들이 얽혀야만 하는 mmog류의 게임들에는 오히려 필연적일 수 있고, 또 그렇게 여러 사람이 얽히는 상황에서 훨씬 더 유용하게 쓰일 수 있다고 느끼거든요. 

그래서 드리고 싶은말은, 그런데 대해 다루는 글을 접하기가 어려운 가운데 좋은 글 소개해주셔서 감사하다는 말씀을 ... ^^;;

[Zerasion 4]

 

인용

어디까지나 개인적인 견해이지만, 이 글에서 라프 코스터가 보여주고 있는 규모와 깊이의 시뮬레이션은 사실상 스탠드 얼론 타입의 게임에서는 '그렇게까지는' 많이 필요하지 않을 듯 합니다. 그보다는 복잡하게 여러 사람들이 얽혀야만 하는 mmog류의 게임들에는 오히려 필연적일 수 있고, 또 그렇게 여러 사람이 얽히는 상황에서 훨씬 더 유용하게 쓰일 수 있다고 느끼거든요. 

 

말씀하신 취지에 따라 이전 포스팅인 시뮬레이션의 꿈과 본문에서 다뤄진 사례가 SNG와 MUG(이렇게 쓰니 상당히 오랜만에 보는 기분이..)가 아니었나 하는 생각이 듭니다.

그리고 스탠드얼론에서 그렇게까지나 필요하지 않을 것 같음에도 불구하고 GTA과 SKYRIM에서 이를 시도했고, 또한 시도를 했으나 플레이어에게 그로 인해 발생하는 유의미한 게임 경험을 제공해주지 못했다는 측면에서 저 역시 껍질인간님을 인용해 비판해 보게 되었네요 ㅎㅎ

그런데 문득 그런 생각이 들었습니다.
모든 시뮬레이션의 인과 흐름이 모든 플레이어에게 충분히 인지되어야만 하나? 라는 의문이 드는데요.
현실 세계의 수많은 인과 관계를 다수의 일반인이 인지할 수 없기에 각 계의 전문가들이 조사/연구해서 각종 매체를 사용해 이를 공유하는 것 처럼, 이런 흐름을 조사하는 사람도 게임 내의 플레이어 역할 중 하나로 만들어 주는 건 어떤가 해서요.

집단 서사와 관련한 Voosco님의 글에서 이러한 "서사의 중계 행위"가 얼마나 중요한지에 대해 언급된 적이 있는데요, 마찬가지로 이같은 "세계 단위의 서사를 해설하는 사람"이 게임 내에 하나의 롤이 되면 어떨까 하는 생각을 해봤습니다.
아니면 게임 내의 뉴스 (판타지 배경이면 펍의 '소문' 같은 설정도 좋겠죠) 같은 곳에서 시스템이 이를 간략하게 알 수 있도록 공개해준다거나, 그도 여의치 않다면 홈페이지 등에서 별도의 공간을 할애해 이를 소개해주는 것도 좋을 것 같고 말이죠.

뭔가 산으로 가는 것 같지만.. 어디까지나 꿈 이야기였습니다.. ㅎㅎ

[Zerasion 4]

sequoia 님이 작성하셨던 리플라이의 아카이빙입니다.

---

인용

 

집단 서사와 관련한 Voosco님의 글에서 이러한 "서사의 중계 행위"가 얼마나 중요한지에 대해 언급된 적이 있는데요, 마찬가지로 이같은 "세계 단위의 서사를 해설하는 사람"이 게임 내에 하나의 롤이 되면 어떨까 하는 생각을 해봤습니다.
아니면 게임 내의 뉴스 (판타지 배경이면 펍의 '소문' 같은 설정도 좋겠죠) 같은 곳에서 시스템이 이를 간략하게 알 수 있도록 공개해준다거나, 그도 여의치 않다면 홈페이지 등에서 별도의 공간을 할애해 이를 소개해주는 것도 좋을 것 같고 말이죠.

뭔가 산으로 가는 것 같지만.. 어디까지나 꿈 이야기였습니다.. ㅎㅎ

 

이브 온라인의 경우 아예 개발사가 게임 내에서 일어난 재미있는 일을 영상으로 만들어 퍼뜨리고 그러죠. :-) 그러고보니 최근에 이브 온라인 사상 최대규모의 전쟁이 일어났다는 기사도 있었는데 이것도 개발자가 트위터로 이번 게 최대규모 맞음 ㅇㅇ 인증해주기도 했고요. 개인적으로도 전 월드 규모의 에픽한 사건은 게임을 운영하는 쪽에서 비용을 들여 전달해줄 만한 가치가 있다고 생각해요.

다른 예로는 부족전쟁을 들 수 있겠는데, 부족전쟁에 오래된 세계의 연표를 보면 개별 플레이어의 이름이 역사로 기록되고 그 역사는 분량과 그들 사이의 정치관계만으로도 장대한 대서사시처럼 보일 정도죠. 쉐도우베인에서도 비슷한 시도를 해서, 플레이어들 사이의 사건이 월드에 영향을 미치면 공식 시나리오에 포함시켜주는 식의 운영을 했다는 이야기를 들은 적이 있는데 이제 와서는 찾기가 좀 힘든 것 같네요.

사실 꼭 위에서 언급한 샌드박스 게임들이 아니더라도, MMORPG들에서의 여러 사건들을 이렇게 개별적인 플레이어의 행적을 역사로 기록해주는 것이 의미있는 시도가 되는 경우가 있을 거라고 생각합니다. 가까운 예로는 WOW의 용개 같은 플레이어가 있겠죠. 블리자드 코리아가 용개 캐릭터(의 패러디)를 몇 번인가 공식 홍보에 쓴 적은 있는 것 같은데, 사실 좀 더 적극적으로 활용할 방법이 있지 않았을까 싶기도 하거든요. 엔하위키에 올라온 내용만 봐도 충분히 에픽한 분(?)이고요.

결론은, 집단서사의 전달을 위해 꼭 인게임에서 스토리를 전달할 필요는 없더라 라는 것입니다. :-)

 

인용

제 경험이 좁아서일지, 견문이 좁아서일지 ... 북미쪽 개발씬에 올라오는 개발에 관련된 아티클들을 읽다보면 느끼는 점은 이런 식의 거시적인 어떤 계(system)를 다루는 분야에 대해서는 상대적으로 글이 많지 않다는 느낌입니다. 여기서 비교의 대상은 플레이어 개인을 분류/분석하거나, 그 개인이 가진 개별적인 동기나 의도를 분류/분석하는 등의 작업들이 되겠죠. 특정한 게임 디자인 장치가 어떤 과정을 거쳐 플레이어에게 어떤 의도, 동기, 심상을 전달하는가에 대한 글들은 질적으로나 양적으로나 풍성하고 의견들도 다양하다고 느끼는데, 그런 플레이어들의 복잡한 동기나 의도들이 모여서 서로 충돌하는 상황 및 그 과정을 분석하고 어떻게 다룰 것인가에 대한 의견을 제시하는 글은 - 어디까지나 상대적으로, 게다가 전적으로 제 경험에만 의존해서 볼 때 - 다소간 부족한 느낌이거든요. 

 

북미에 비해 한국에는 많다는 뜻인가요? 어디에 가면 많이 볼 수 있을까요?

 

 

(아카이버 주: 엔하위키 미러 페이지는 다음으로 대체합니다. https://namu.wiki/w/Drakedog )

2017년 12월 12일 Zerasion님이 수정하였습니다.

[Zerasion 4]

Voosco 님이 작성하셨던 리플라이의 아카이빙입니다.

---

 

한국은 애초에 이것도 저것도 적은 편인 듯 하구요 ^^;; 그나마 요새는 컨퍼런스 등이 열리면 관련자료는 풍족해져서 좋더군요. 제가 말씀드린 한국쪽 자료들은 주로 이런데 관련한 자료들입니다. 단지 절대적인 양으로 보면 여전히 많지 않구요. 이건 단순히 시장의 크기 차이를 반영하는 거라 보긴 합니다만. 

단지 가마수트라 등 해외에는 좀더 안정적인(?) 채널이 있는데 비해 한국은 그런 일종의 채널은 없는지라 아쉽긴 합니다.

[Zerasion 4]

romuska 님이 작성하셨던 리플라이의 아카이빙입니다.

---

 

인용

결론은, 집단서사의 전달을 위해 꼭 인게임에서 스토리를 전달할 필요는 없더라 라는 것입니다. :-)

그게, 마비노기랑 몇몇 게임들이 최초로 봉인을 깬 사람의 이름을 기록한다거나 하는 시스템을 만들어 넣었었는데 그리 훌륭하게 작동해주진 않았었어요. 용개사건보다 더 큰게 이인화의 한국형 디지털 스토리텔링 : 「리니지2」바츠 해방 전쟁 이야기 http://www.yes24.com/24/goods/1525335?scode=032&OzSrank=10 에서 언급되었던 바츠해방전선일텐데 오히려 이쪽은 나름 이쁘게 작동해주었죠. 문제는 이게 시스템에서 제공한거냐 하면 음.. 안한 건 아니겠지만요. :> 이런 식의 리소스 활용은 자칫 잘못하면 "난 퍼펙트한 게임 월드를 만들었어!"라는 개발자의 자위가 되기 쉬워서... 
오히려 게임이 전달해야 하는 건 집단서사가 아니라 개인서사가 아닐까 라고 생각합니다. 최근의 라스트오브어스도 그렇고.. 가상체험이니까요. 물론 그 위에 스타크래프트의 우리 콩까지마사건까지 넣자면 여러가지 집단서사가 존재할 수 있고, 분명 열광할 수 있는 부분이긴 한데 그건 게임이 벽을 넘어서 스포츠의 영역에 도달해야만 만날 수 있는게 아닐까 싶어요. 예를 들어 임요환의 테란 컨트롤은 아름답고 예술성이 느껴지지만, 마비노기의 최초의 봉인을 깬 로무스카가 되는 건 단순히 타이밍과 운의 문제라는 생각이 들어서-_-a 그런 '타이밍과 운이 좋았던 사람'의 이름을 남기는 게 의미가 있는지 & 조낸폐인만이 도달할 수 있는 라인을 설정해서 그걸 돌파하는 예술성에 의미를 부여하는 게 맞는지...쩝쩝.