공지사항
해당 문서는 Project_TK에 사용될 보상에 대한 시스템 문서입니다.
라고는 말했지만 ㅎㅎ 오늘은 주제가 주제인 만큼 시스템 문서 기반으로 하되 (사실 문서 상으로는 별 내용이 없어서)
주저리 주저리 코멘트를 많이 달듯 합니다.
◎ 보상 시스템
▪ 보상 시스템이란?
각각의 콘텐츠에서 보상으로 주어지는 재화 또는 아이템들의 지급과 관련하여 그에 따른 모든 규칙들을 정립해 놓은 것을 말한다.
▪ 보상 시스템의 구현을 위한 개념
1. 보상을 지급해야 하는 콘텐츠 별 데이터 테이블에 [reward] 컬럼이 존재해야 한다.
2. [DT_Reward] 데이터 테이블을 생성하여 지급해야 하는 모든 보상품들을 입력한다.
3. 콘텐츠 별 데이터 테이블의 [reward] 컬럼에 [DT_Reward]에 존재하는 보상 코드명을 입력한다.
4. 보상 코드명이 호출되면 [DT_Reward] 데이터 테이블에 있는 보상품을 규칙에 따라 지급한다.
사실상 보상품을 어떻게 지급할 것인가? 하는 부분은 위에 설명한 개념으로 끝난다(?)라고 할 수 있습니다만 바로 이해가 되실런지...
이부분은 다음 주제로 로그인 이벤트 (출석 체크)를 논하면서 DT_LoginEvent 와 DT_Reward에 입력된 값들을 가지고 한번 더 설명해 드릴게요.
▪ 보상품의 종류
보상으로 지급 가능한 보상품은 아래와 같다.
보상품 |
||
재화 |
미공개 |
- |
미공개 |
- |
|
미공개 |
- |
|
미공개 |
- |
|
아이템 |
세부 내용 미정 |
|
|
|
|
|
|
|
|
|
|
영웅 |
세부 내용 미정 |
|
|
|
|
|
|
|
|
|
미공개라고 한 부분은 이미 결정되어 있는데 공개하면 무슨 게임을 만들고자 하는지 대충 아실듯 해서 잠시 보류를... 설마 이미 눈치채신건 아니시겠죠?
세부 내용 미정이라는 부분은 아직 결정을 안했답니다.
지금 공개하는 기획서들 다 실시간으로 작성해서 올리는 것들이에요. (워드로 한번 작성하고 다시 올린답니다)
그래서 아직 결정하지 않은 것들이 아주 많답니다. 또한 [풋내기 원정대]와 달리 기획 문서를 올리는 순서 (작성하는 순서)가 이상한건
이런 것들은 크게 생각하지 않아도 쉽게 결정될 수 있는 부분이라 (어느 게임이든 비슷하게 사용되는 부분이라) 바로 바로 작성해서 올린답니다.
▪ 보상 데이터 테이블 구조
: 자세한 사항은 [보상 데이터 테이블 구조] 문서를 참조하도록 한다.
- 끝-
기획 문서는 사실상 이렇게 마무리 하는데 (아니면 보상 코드명 형식을 추가해 놓거나) 오늘은 보상 데이터 테이블을 구성하는 파라미터 들에 대해서 추가 설명을...
◦ 보상 코드명
일단 보상 코드명은 [보상 데이터 테이블 구조] 문서에 [보상 코드명] 이라는 시트로 설명되어 있는데 그 내용은 아래와 같아요.
reward의 R을 맨 앞에 두어 해당 코드명이 보상에 대한 코드명이다는 것을 명시하구요.
그 후에 콘텐츠 종류들이 나열되는데 지금 상점, 출석 체크 (로그인 이벤트), 운영 이벤트, 쿠폰 이벤트만 명시되어 있고 미정이라고 되어 있는건...
정말 미정이기 때문입니다. 아직 안했어요 ㅎㅎ. 지금 생각드는건 업적, 일일 퀘스트 같은것도 있을 수 있겠고 다른건... 다음 기회에 ㅎㅎ
숫자를 6자리로 쓰는건 코코모 재직 시절 서버 프로그래머 동생이 6자리 하자고 적으면 문제된다고 해서 단순히 6자리로 시작했는데
거기에 익숙해 졌는지 줄이니까 정말 문제가 되더라구요. 그래서 6자리로 계속 사용하고 있어요.
◦ 주석
말 그대로 주석입니다. 해당 리워드가 어떤 콘텐츠의 보상 품이냐 라는 부분을 남겨 놓아요.
◦ 드랍 타입
이게 좀 바로 이해하기 어려울 수도 있는 부분인데 아래와 같이 구성됩니다.
- GACHA
가챠 보상을 나타냅니다. 입력된 보상품들 중에서 1개만 드랍된다고 생각하시면 되구요. 재화 및 아이템 코드명만 보상품으로 입력 가능합니다.
- SET_ONE
이게 문제가 되는 부분인데 일단 가챠의 확장 버전으로 사용되구요. 사용 용도를 설명하자면 아래와 같아요.
실제 테이블 상에는 보상품을 최대 10개까지 입력할 수 있어요. 가챠의 경우를 예를 들면 10개 중에서 1개가 떨어진다고 할 수 있죠.
헌데 10개가 아니라 20개 중에서 1개가 떨어져야 한다면? 20개가 아니라 30개, 40개 중에서 하나라면?
이 경우에는 GACHA 라는 타입으로는 해결을 할 수가 없죠. 그래서 만든게 SET_ONE이에요.
SET_ONE은 보상품에 재화 및 아이템 코드명 뿐만 아니라 리워드 코드명도 넣을 수 있어요.
그래서 쉽게 설명을 하면 1번 가챠부터 5번 가챠 중에 어떤 번호의 가챠를 뽑을지 먼저 선택을 하고 (1 ~ 5번 중에 번호를 하나 선택)
선택된 가챠 번호에서 보상품을 최종적으로 1개 획득해 내는거죠.
이렇게 되면 각각의 번호에 10개의 보상품을 넣을 수 있으니 총 50개 중에서 1개가 선택되는 형태인거죠.
쉽게 설명한다고 했는데 이해가 되셨나요? ㅠㅠ
참고로 앞서 리워드 코드명의 숫자가 6자리라고 했잖아요. 전 리워드를 10 단위로 사용해요. 000010, 000020 이런 순으로요.
그리고 만약 해당 리워드가 SET일 경우에는 000011, 000012, 000013 이렇게 해서 000010에 종속된 리워드 번호다 라고 나름 명시를 한답니다.
이렇다는건 최대 90개까지의 보상품 중에서 1개를 고를 수 있다 라는 규칙이 정해져요. 사실 90개 이상 필요한 경우는 아직은 경험해 보지 못해서.
아 중요한게 빠졌네요. SET_ONE에서 리워드 코드명도 넣을수 있다고 했잖아요. 헌데 해당 리워드 코드명의 드랍 타입은 꼭 GACHA이어야 해요.
SET_ONE 안에 SET_ONE 또는 SET_MUL의 드랍 타입이 들어가면 무한 반복되는 사태가 발생할 수도...
- SET_MUL
이번에는 ONE이 아니라 MUL이에요. MUL은 MULTI를 나타내구요. 하나의 아이템을 획득하는게 아니라 2개 이상의 아이템을 획득할 수 있다는 의미에요.
당연히 SET_으로 시작하기에 재화, 아이템 뿐만 아니라 리워드 코드명도 입력 가능하고요 (단 GACHA 타입만)
해당 타입은 2개 이상 떨어질 수 있기 때문에 나중에 나오지만 확률(droprate) 컬럼에 들어가는 확률이 독립 확률이에요. 즉 독립적으로 확률 굴림을 하여
각각의 보상품이 떨어지는가 안떨어지는가 굴림을 할 수 있다는 의미에요.
여기서 하나의 규칙이 또 존재하는데 제가 설계한 보상 데이터 테이블 구조에서는 SET_MUL에서 2 종류의 보상품만 떨어져라, 3 종류의 보상품만 떨어져라
라고 정의할 수는 없어요. 그렇게 하고자 한다면 컬럼을 하나 더 파야겠죠 ㅎㅎ
- PACKAGE
이번에는 패키지란 드랍 타입인데 이건 간단해요. 명시된 모든 보상품들이 다 떨어진다에요. 확률 굴림 없이요.
물론 개념이 그렇다는 거지 테이블 구조상 확률이 10000%(만분율)로 명시는 해야 되요. 하지만 뭐 하드 코딩으로 입력된 확률값 무시하고 무조건 나오게도 할수가 있겠죠.
- EVERYDAY
해당 보상을 매일마다 지급하는 드랍 형태에요. 단 최초 보상은 단 한번만 지급하구요.
최근 게임들 보면 월정액 구입하면 최초에 얼만큼 주고 매일마다 얼마씩 주는걸 구현하기 위한 드랍 타입이에요.
그리고 여기서 이슈가 또 하나 있는데 제 데이터 테이블 구조상에는 최초 보상품은 1개만 입력 가능하게 되어 있다는 거에요. (재화 또는 아이템)
아... 적다가 생각났는데... 보상품에 리워드 코드명을 넣으면 2개 이상 줄수도 있겠네요... 왜 그땐 생각을 못했지? 바로 수정해야 겠어요 ㅎㅎ
◦ 최초 보상
최초로 지급되는 보상을 나타내요. 앞서 설명했듯이 재화 또는 아이템 코드명만 입력 가능했는데 리워드 코드명도 입력 가능하도록 수정해야 겠어요
◦ 최소 수량
드랍되는 보상품의 최소 수량을 나타내요
◦ 최대 수량
드랍되는 보상품의 최대 수량을 나타내요.
최소 수량과 최대 수량이 동일한 경우에는 명시된 수량이 나타나구요. 다른 경우에는 해당 범위내에서 랜덤하게...
코코모에서는 하나의 컬럼을 사용하고 다른 기법을 섰는데... 전 2개로 나누는게 편하더라구요. 눈에도 잘 들어와서...
◦ 보상품
보상품을 나타내는 컬럼이에요. 드랍 타입에 따라서 리워드 코드명의 입력 가능 여부가 결정되구요. 재화나 아이템은 다 입력 가능해요.
◦ 확률
드랍 확륭을 나타내는 컬럼이에요. 만분율로 표기되구요.
숫자만 입력한 경우는 해당 라인이 모두 숫자로만 되어 있어야 하고 총합은 꼭 10000 이어야 해요.
꼭 10000으로 하는 이유는 예를 들어 1000 과 9000을 입력하여 10000을 만들려고 했는데 실수로 1000과 900을 입력 했어요. 0이 하나 빠진거죠.
헌데 이럴때 숫자가 정해져 있지 않으면 실수를 한 건지 원래 의도가 그런건지 알수가 없어요.
그래서 지정된 숫자를 두고 총합이 그 숫자가 안될때는 오류다 라고 인식하는 거죠.
K숫자로 입력한 경우에는 해당 라인은 역시 K숫자로만 이루어져야 하구요. 해당 확률들은 독립된 확률로 각각의 명시된 확률에 따라 굴림을 하는거에요.
물론 숫자는 만분율을 기준으로 해요.
◦ 최소 수량
위에 내용과 동일해요.
◦ 최대 수량
위에 내용과 동일해요.
오늘은 이렇게 보상 시스템에 대해서 알아봤는데요. 아마 한번에 이해하기 어려운 내용들이 많으실거에요.
궁금하신 부분은 방명록에 남겨주시면 힘닿는데로 설명을 해드릴게요.
'게임 기획 이야기 > Project_TK' 카테고리의 다른 글
로그인 이벤트 시스템 2_출석 체크 프로세스 (0) | 2017.10.12 |
---|---|
로그인 이벤트 시스템 1 (0) | 2017.10.11 |
스트링 시스템 (0) | 2017.08.09 |
쿠폰 관련 UI (0) | 2017.08.08 |
툴 팁 UI (0) | 2017.08.08 |