(NDC2014) 야생의 땅 듀랑고의 자유도 높은 아이템 시스템 구현

(NDC2014) 야생의 땅 듀랑고의 자유도 높은 아이템 시스템 구현

1. 듀랑고의 아이템

- 현실에서는 아이템의 용도를 사용자가 결정하지만, 일반적인 게임에서는 개발자가 결정한다.

- 의도에서 벋어나는 정보는 독이다.

  복잡한 시스템과 정보는 게이머와 디자이너, 프로그래머까지 혼란에 빠뜨린다.

- 가죽 장화를 먹게 해달라는 것은 아이템 시스템의 자유도와 창발성을 상징한다.

- 가죽장화는 가죽(따뜻함, 질김, 칼로리)과 장화(발에 신는 것, 방어도)의 속성을 가지면서 가죽과 장화라는 특성을 가진다.

  즉, 아이템은 특성의 조합이라는 것이다.

- 이는 아이템 생성 방식이 기존 방식으로는 불가능하며, 재료의 특성을 유지하면서 랜덤성(계산된 돌연변이)이 있도록 해야 한다는 것이다.

- 아이템은 제작(속성을 변형, 조합)과 채집(무에서 유를 창조)으로 생성된다.

  

2. 프로토타입Z5

- 태그 : 통나무 아이템의 예

> 특성 : 탈 수 있는, 깎을 수 있는

> 속성 : 건조 정도, 두께, 단단함, 무게

> 탈 수 있는의 관심 속성 : 건조 정도, 두께

> 깎을 수 있는의 관심 속성 : 두께, 단단함

- 채집 : 소나무의 예

> 채집할 수 있는 대상 : 소나무 가지, 뿌리, 통나무, 송진

> 소나무 가지를 채집할 경우, 유저가 소나무 가지를 선택하는 순간 생산기가 불러진다.

> 생산기는 채집도구, 레시피 종류, 즉 어떤 스크립트를 쓸 것인지, 어떤 나무로부터 왔는지에 따라 결과물을 낸다.

> 이 결과물은 나름의 특성을 가지고 있다. 나뭇가지는 때릴 수 있으니 둔기도 될 수 있고, 막대기도 될 수 있다.

  소나무 가지의 특성 : 탈 수 있는, 둔기, 막대기, 깎을 수 있는

  속성 : 길이, 유연함

  재질 : 소나무

> 속성은 레시피의 결과로 조금 달라질 수 있다.

- 제작 : 도끼 만들기

> 위의 소나무 가지를 재료로 활용

> 또 하나의 재료 돌날

  특성 : 날카로운, 날

  속성 : 날카로움, 단단함

  재질 : 돌

> 도끼 레시피 : 막대기, 날, 묶을 수 있는

> 도끼 레시피가 요구하는 속성. 특성을 포함한 재료를 모두 넣으면 도끼가 제작된다.

  도끼 특성 : 도끼, 둔기, 막대기

  속성 : 유연성, 단단함, 길이, 날카로움, 손에 들 수 있음

  재질 : 돌, 소나무

- 프로토타입Z5의 결과, 재료를 무한정으로 반복 제작(제작 결과물을 다시 재료로)하여 수치의 무한현상이 일어났다.

- 프로토타입Z5의 문제

> 데이터의 파편화

ㆍ데이터의 특성, 재질, 속성을 설정하는 것과 아이템을 생성하는 것 모두 다른 파일이다.

ㆍ프로토타입 시기라 마땅한 툴이 없었고 직접 파일을 수정해야 했기 때문에 실수가 많았다.

> 스크립트

ㆍ툴이 없이 디자이너가 직접 코딩에 관여

ㆍ사소한 오타부터 로직 오류까지 발생

> 데이터 발산

ㆍ데이터를 컨트롤 할 수가 없다.

ㆍ엄격한 룰을 적용하면 해결할 수는 있지만 재미가 반감

> 시스템 자체는 재미있다는 평이 많았으나 테스트가 고비용이고, 디자이너가 과로로 죽어간다.

3. 랩터빌드

- 데이터 구조 변경

> 태그에 속성값을 묶었다. 그룹화!

  통나무 - 탈 수 있는 - 건조 정도, 두께

         - 깎을 수 있는 - 두께, 단단함

- 데이터 입력 툴 지원

> 웹페이지 기반으로 제작

> 완료 누르면 자동으로 검증해준다.

- validation(검증) 개념 도입 : 파편화 된 데이터를 서로 연결해서 데이터가 잘 있나 확인하고, 형식을 갖추고 있나 확인하는 역할

> validator : 사전 정보를 입력하면 가상의 결과를 도출하여 스크립트를 돌아본다. 이 과정에서 에러를 발견할 수 있다.

- 결과

> 데이터로 인한 오류 감소

ㆍ툴에서 데이터 오류 검증

ㆍ테스트 비용 대폭 감소

ㆍ프로그래머 도움이 필요한 부분 대폭 감소

ㆍ멘탈 붕괴 감소

> 웹페이지 기반 데이터 입력 툴 실패

ㆍ대량의 데이터를 작업해야 하는데, 하나씩 클릭해서 형식에 맞춰 입력하는 것은 의미가 없었다.

ㆍ엑셀과 같은 툴과 호환해서 대규모 데이터를 입력하지 않으면 의미가 없다.

> validator의 실패 케이스

ㆍ입력한 것에 따른 고정된 루트의 가상 결과를 도출하기 때문에 분기나 랜덤 값을 잡을 수가 없다.

ㆍ5% 확율을 잡기 위해 100번을 돌려야 한다.

> 자유도 및 창발적 요소 감소

ㆍ데이터 검증을 위해 채택한 엄격한 데이터가 재미의 근본을 해쳤다.

ㆍ구조가 엄격해졌기 때문에 언제나 기대하던 특성에 있을 만한 속성이 있어, 항상 기대된 데이터만 나온다.

4. 세번째 이터레이션

- 속성 개편

> 속성을 다시 아이템에 붙였다.

> 비교적 간단한 규칙으로 특성에 포함되지 않는 속성들도 관리하도록

  기본값들을 가지고 있되 언제든지 접근하면 그 데이터가 없더라도 설정된 기본값을 가져오거나, 

  차후 레시피에서 디자이너가 지정하지 않아도 정해진 규칙에 맞게 속성을 어느정도 자동으로 개설

> 레시피 안에서 의도하지 않은 것들이 일어나게 하여 창발적 제작을 유도

- 스크립트 

> 디자이너에게 필요한 클래스, 메소드, 항목만을 쓸 수 있게 개편

- 스크립트 분기점 규격화

> 일반적으로 쓰이는 분기점을 분석해서 밸리데이터가 분기점을 다 한번씩 검토하도록 하려고 노력 중

- 데이터 발산 검증 툴(예정)

> 제작된 아이템이 어떤 범주의 랜덤 값을 가져서 수치를 가지고 나오는 것이 아니라,

  범위 자체를 포함하고 있는 아이템을 만들어서 그 아이템을 다시 재료로 써도 범위를 크게 벋어나지 않도록

  만약 제작한 아이템으로 여러번 다시 제작을 해봤는데 범위가 늘어나면 발산이 일어난 것

5. 마무리

- 아무리 강조해도 부족하지 않은 소통

- 작업자의 실수를 잡아주는 툴은 필수

- 빠른 이터레이션에 더 신경을 쓰자