애드온 ui 에 대한 고찰 - 3

2013/01/02 - [Scaleform Etc] - 스케일폼을 위한 작은 변명

2013/01/14 - [Scaleform Etc] - 애드온 ui 에 대한 고찰 - 0

2013/01/14 - [Scaleform Etc] - 애드온 ui 에 대한 고찰 - 1

2013/01/15 - [Scaleform Etc] - 애드온 ui 에 대한 고찰 - 2

1. 리스트 데이터 바인딩

지금부터 설명할 리스트 데이터 바인딩은 좀 어렵습니다.

정확히 말하자면 어렵다기 보다는, 각 회사마다 개발하는 게임 시스템에 따라 내용이 확연히 달라질 수 있기 때문입니다.

그렇기에 설명은 제가 생각하기에 가장 일반적인 게임의 시스템을 예로 들어 말하겠습니다.

(제가 설명할 게임 시스템 조차 저희 회사의 시스템과 꽤 거리가 있습니다...)

자, 인벤토리라는 것의 정의에 대해서부터 생각을 해볼까요?

쉽게 생각하면 아이템의 목록을 말하는 겁니다. 아마 게임 구조에 따라 스킬이나 제작 기술 목록도 아이템의 범주로 넣었을 수도 있고, 안넣었을 수도 있을 겁니다.

전 아이템, 스킬, 제작 기술, 혹은 소환수 까지 모두 아이템이라는 구조 안에 넣어보도록 하겠습니다

아이템이나 스킬, 제작 기술, 소환수 등... 이것들은 캐릭터가 소유한 "무엇" 을 뜻합니다.

창고와 인벤토리, 스킬 리스트, 제작 기술 리스트 등은 그것을 가지고 있는 리스트인 셈입니다.

그에 반해 퀵슬롯 같은 경우는 인벤토리와 스킬리스트에 대한 일종의 바로 가기입니다. 링크일 뿐이지 실제 소유한 것은 아니라는 거죠...

퀵슬롯의 물약을 클릭하거나 단축키로 사용했다면, 실제 퀵슬롯의 물약을 사용한 것이 아니라 인벤토리 어딘가에 있는 물약을 사용한겁니다.

스킬 또한 마찬가지죠...

아마도 다음과 같은 시스템을 가진 MMORPG가 가장 많지 않을까 싶습니다

1. 인벤토리(창고, 스킬/제작기술 리스트)의 아이템은 언제든(쿨타임이 허용하는 한) 사용할 수 있다

2. 퀵슬롯 리스트는 인벤토리의 소모성 아이템과 스킬 리스트를 링크할 수 있다

3. 장비 리스트는 인벤토리의 링크이다(장비되어 있어도 인벤토리에 존재하는 게임시스템을 가진 경우겠죠)

4. 장비... 그리고 창고, 제작기술 리스트 안의 모든 아이템은 링크할 수 없다

이런 시스템을 구현하려면 아이템은 보통 다음과 같은 타입으로 나눌 것입니다

1. 소모성 (물약, 주문서 류)

2. 장비 (무기, 방어구, 악세사리)

3. 스킬 (전투 / 비전투 스킬)

4. 제작기술 (각종 제작기술)

이정도의 게임 시스템을 가지고 바인딩 되는 시나리오를 짜보겠습니다.

1. 클라이언트는 UI 와 인벤토리(창고, 장비, 스킬/제작기술 리스트)만을 배열로 바인딩 한다

2. 바인딩 된 모든 아이템은 고유한 id 값을 가진다.

3. 퀵슬롯에는 해당 id에 대한 정보만 가지고 있을 뿐이고, 이런 링크 정보만이 바인딩 된다

4. 실제 아이템은 인벤토리(창고, 장비, 스킬/제작기술 리스트)만 가지고 있으므로 모든 아이템 사용의 이벤트는 인벤토리에서만 일어난다

어떻게 4번이 가능하냐고요? 퀵슬롯을 마우스 클릭해서 사용했는데 퀵슬롯에서 이벤트가 발생을 해야 한다고요?

아니죠... 정확히는 퀵슬롯에서 이벤트가 발생한게 아닙니다. 바꿔 말하면 퀵슬롯에서는 이벤트가 일어났지만, 아이템은 인벤토리의 것을 사용한겁니다.

Window 의 바로가기 아이콘을 생각해보시면 되지 않을까요?

그렇다면 퀵슬롯에서 발생한 이벤트는 어떻게 하느냐... 그거야 당연히 링크되어 있는 원래 아이템으로 이벤트를 날려주면 됩니다.

(인벤토리).dispatchEvent({type:"click", data:링크된 원본데이터객체})

이런 식으로 코딩을 하면 된다는 겁니다.

링크되어 있는 쪽은 클라이언트와 전혀 통신할 이유가 없습니다.

퀵슬롯 링크를 바꿀 때마다 링크 정보 정도만을 주고 받으면 되는 것이죠...

이렇게 함으로서 리스트 바인딩도 앞서 설명했던 바인딩과 같이 단일객체하고만 통신이 가능합니다.

클라이언트는 이 리스트바인딩 객체의 dispatchEvent 만 바라보고 있으면 되는 겁니다.

커스텀 개발자가 뜬금없는 곳에서 어떤 이벤트를 날리건 말건 신경 안써도 되는거죠.

2. 실제 개발을 한다면

이런 시나리오 속에서 클라이언트는 다음과 같이 설정을 할겁니다.

ListBinding.setList("inventory", 인벤토리배열);
ListBinding.setList("skill", 스킬배열);
ListBinding.setList("craft", 제작시술배열);
ListBinding.setList("storage", 창고배열);

그러면 UI 개발자가 해야할 일은 다음과 같습니다.

ListBinding.addBind("inventory", CoreList);

자 이런 식의 api는 괜찮습니다만 이번에는 링크들에 대해서 해볼까요...

ListBinding.setLink("quicklist", 퀵슬롯 배열);

자 여기서 문제가 발생합니다.

앞서 말한 인벤토리(창고, 장비, 스킬/제작기술 리스트)는 진짜 데이터입니다만... 퀵슬롯은 순수한 데이터라고 하기 힘듭니다.

그리고 유저들이 마음대로 UI를 만든다고 생각해보면, 링크형의 리스트는 수없이 만들어질 수 있습니다.

그렇기에 이건 서버측에 저장하는 접근 방법이 달라져야 합니다.

3. 커스텀 UI 정보를 저장하고 활용하려면

이게 어려워집니다...

유저마다 사용하는 UI 종류는 천차만별인데, 그에 대한 정보를 저장해야 할 겁니다.

하지만 앞서 말한대로 이것은 순수한 데이터가 아닙니다.

퀵슬롯 1번에 물약을 등록했다는 것은 말이죠... 일종의 환경설정 ini 파일 같은거란 말이죠... 이건 단지 Window 의 바로가기 아이콘일 뿐이니까요...

이건 게임데이터가 아닌 유저의 설정정보로 저장되어져야 한다는 말입니다.

ListBinding.setLink("quicklist", 퀵슬롯 배열);

가 아닌

Setting.setUI(유저별커스텀UI데이터);

정도의 api가 되어야 한다는 말이죠... 이건 리스트 바인딩 객체가 처리할 일이 아니라는 겁니다

저장할 정보의 예를 들어볼까요?

알아보기 쉽게 xml 로 해보죠

뭐 이정도로 저장하면 될겁니다.

잘못 이해하시면 안될 것이 이 데이터는 커스텀 UI 개발자 마음대로 저장하고 가져다 쓰는 겁니다.

서버 개발자나 클라이언트는 전혀 알 필요가 없지요... 문서타입도 알 필요없고요...

커스텀 개발자가 저장해둔 설정파일을 클라이언트가 불러다 주면 그걸 가지고 알아서 꾸미는 겁니다.

이런 식으로 커스텀 UI를 어떻게 만들던 설정정보를 마음대로 서버에 저장하고 가져다 쓸 수 있게 됩니다.

ListBinding.setLink("quicklist", 퀵슬롯 배열);

이런 코드는 전혀 필요가 없는 것이죠...

글이 길어졌으니 오늘은 여기까지만...