현업(게임) 시스템 기획자의 실무 노트

모바일 캐릭터 수집 RPG의 길드 시스템 을 기획하고, 기획서의 테이블과 플로우를 그대로 HTML/JS 프로토타입으로 구현해 본 작업입니다. 아래 데모는 별도 서버 없이 브라우저에서 바로 동작하며, 유저 데이터를 직접 수정하면서 정렬·권한·랭킹 반영을 확인할 수 있습니다. 1. 시스템 개요 길드는 출석·기부·연구·레이드·채팅으로 구성되며, 채팅을 제외한 모든 활동에서 길드 공헌도 를 획득합니다. 누적 공헌도로 길드 레벨이 1~25까지 성장하고, 레벨에 따라 최대 인원(20→50명)과 부길드장 수(1→5명), 길드 버프가 확장됩니다. 일일 콘텐츠는 모두 UTC 00시에 초기화됩니다. 2. 등급과 권한 길드원 등급은 길드장 / 부길드장 / 길드원 3단계입니다. 이름·엠블렘·가입 조건 변경과 해산은 길드장 전용, 가입 승인·등급 변경·추방·소개글·공지·연구 오픈은 부길드장까지, 채팅은 전 등급이 사용합니다. 권한이 없는 항목은 딤드 처리하고 터치 시 안내 메시지를 출력합니다. 데모 상단의 등급 시뮬레이션으로 직접 확인할 수 있습니다. 3. 길드 리스트 · 생성 · 가입 목록은 가입 신청한 길드 > 만원이 아닌 길드 필터 > 공헌도 높은 순 > 인원 많은 순 으로 정렬합니다. 가입 방식은 신청 / 즉시 가입 / 암호 입력(전용 숫자 키패드, 4자리) 3종이며, 동시 가입 신청은 최대 3개로 제한합니다. 검색 시에는 만원 길드도 필터링하지 않고 전체 검색합니다. 길드 생성은 프레임·문양·색상 엠블렘 조합, 이름 2~10자(특수문자·중복 검증), 소개글 20자, 공지 200자로 구성됩니다. 4. 길드원 관리 (유저 리스트) 등급, 이름·UID, 레벨, 접속 정보, 누적/주간 공헌도를 표시합니다. 기본 정렬은 주간 공헌도 내림차순 > 레벨 내림차순 > 이름 오름차순 이고, 컬럼 터치로 우선 정렬과 오름/내림 토글이 가능합니다. 접속 정보는 접속 중 / N분 전 / N시간 전 / N일 N시간 전 / N일 전 포맷으로 자동...

 안녕하세요! '호랭이물어갈기획놈들' 입니다. 지난번 글에서는 어떤 서버 방식으로 설계를 하는게 제일 좋은지 알아봤다면 이번 3편에서는 길드 입장 버튼의 배치와 최적의 길드 콘텐츠 오픈 타이밍과 가입 플로우에 대해 이야기 드리려고 합니다. 바로 시작하겠습니다. 1. 길드 입장 버튼의 위치와 UI 중요도 대다수의 모바일 게임들을 보면 길드 버튼은 메인 로비에 던전, 상점, 장비 등과 같이 플레이 하는 유저들의 손가락이 아주 쉽게 닿는 곳에 포진하고 있습니다. 물론 길드 콘텐츠가 필요없는 싱글 게임의 경우엔 예외지만 모바일 MMORPG나 수집형 RPG, 전쟁 게임 같은 길드 콘텐츠가 핵심으로 자리잡은 게임들 로비 UI에는 길드 창으로 진입하는 버튼은 구석에 두거나 서랍장 버튼 안에 숨겨두어선 안됩니다. <그림 1. 라오킹 연맹 버튼 위치> 버튼 위치: 메인 로비(또는 필드 화면) 우측 하단이나 우측 상단 등 유저의 엄지손가락이 가장 쉽게 닿는 메인 HUD 영역 . <그림 2. 블루 아카이브 서클 버튼 모양> UI 강조 디자인: 길드는 유저의 장기 잔존율(리텐션)을 책임지는 핵심 엔드 콘텐츠입니다. 따라서 여러 번 뎁스(Depth)를 파고 들어가지 않도록, 메인 UI에 독립적이고 큼직하게, 눈에 확 띄는 방패나 깃발 모양의 아이콘으로 배치하여 "이 게임은 길드가 매우 중요하다" 는 것을 시각적으로 각인시켜야 합니다. 즉 여러분이 개발하는 장르의 특성에 맞게 길드 입장 버튼 모양과 UI의 위치를 잘 잡아서 유저들의 동선을 장르에 맞게 잡아주는 것이 1차적으로 중요하다고 생각합니다. 아마 시안을 가져가면 100% 확률로 상급자에게 '여기에 이 버튼을 왜 넣었는지' 설명해야 하는 순간이 옵니다.  UI 디자이너와 논의할 때도 '단순히 예쁘니까, 쓰기편하니까'라는 이유보다는, 우리 프로젝트 특성상 길드 콘텐츠가 얼마나 중요한지 명확한 근거를 대며 설득해야 합니다. 기획자라면 항상 이 부분...

안녕하세요, '호랭이 물어갈 기획놈들' 입니다. 지난 포스팅에서는 길드 상점의 Key-Value 데이터 구조화를 다뤘습니다. 상점이 공헌도를 소비하는 창구라면, 오늘 주제인 길드 공동 연구 와 길드 레이드 는 길드원 전체가 함께 만들어가는 핵심 협동 콘텐츠입니다. "보스를 같이 잡고 버프 레벨을 올린다"는 표면적인 기획을 넘어, 수익 모델(BM)을 자연스럽게 녹이는 방법과 플레이 경험(UX)을 끌어올리는 실무 설계 포인트를 정리했습니다.

 안녕하세요! '호랭이 물어갈 기획놈들' 입니다. 지난 포스팅들을 통해 길드 로비 UI와 출석, 기부 등 길드 시스템의 뼈대를 잡았습니다.  이제 유저들이 열심히 모은 '길드 코인(공헌도)'을 사용할 [길드 상점]을 기획할 차례입니다. 하지만 상점 설계와 판매 리스트 작성 전에 , 시스템 기획자라면 알아두면 좋은 KeyValue 관련 내용에 대해 이야기 하려고 합니다. 1. 데이터 테이블 최적화 KeyValue 이번에 이야기 드리는 길드 시스템처럼 대형 콘텐츠 제작 시 파생되는 데이터 테이블의 양이나 테이블 안에 컬럼의 개수가 상상을 초월할 정도로 많습니다. 특히 이번 길드 시스템의 경우 간단하게 잡아도 아래와 같이 구성됩니다. 길드 정보: 길드 레벨, 필요 공헌도, 레벨별 최대 인원 증가 테이블 길드 Auth: 길드장, 부길드장 등 직급별 권한 테이블 길드 출석: 출석 시 획득하는 공헌도 및 길드 코인 보상 테이블 길드 선물: 공헌도를 소모해 상자를 오픈하고 길드원과 나누는 보상 테이블 길드 기부: 무료/유료 기부 타입별 재화 획득 테이블 길드 연구: 연구 트리 및 레벨별 버프 수치 테이블 길드 레이드: 보스 스펙 및 토벌 보상 테이블 대충 읊어봐도 10개가 훌쩍 넘어가는 테이블을 작성해야 합니다.  이를 전부 개별 테이블로 쪼개서 서버 프로그래머에게 넘기면, 개발 시 연결할 테이블 찾아서 서버 프로그래머가 열심히 작업하느라 개발 리소스도 낭비되고 향후 라이브 서비스 시 관리도 매우 힘들어집니다. 이때 주요한 팁을 하나 말씀드리려고 합니다. 고정된 데이터는 Key-Value로 빼라! 이게 무슨 이야기야 라고 의아해 하실 수 있는데 컬럼 숫자가 적고(1개 ~ 3개), 라이브 서비스 중 구조적인 변경이 거의 없을 것으로 예상되는 기능(예: 길드 출석 보상, 길드 기부 보상) 같은 내용은 굳이 개별 테이블 보다는 'Key-Value'라는 말 그래도 키-값의 구조를 가진 공통의 테이블 하나에 몰아넣고 관리하는 ...

 안녕하세요! '호랭이물어갈기획놈들' 입니다. 지난 3편에 이어 이번엔 길드 로비 UI 설계와 출석, 기부 시스템과 같은 핵심 시스템에 대한 내용을 집중적으로 이야기 하려고 합니다. 우선 길드 로비 UI의 경우 길드 가입 후 입장하면 바로 보이는 UI로 메인 로비와 같이 다양한 콘텐츠들이 촘촘히 배치되고 많은 정보를 담고 있습니다. 다양한 정보들로 인해 유저분들이 혼란스럽지 않도록 중요도에 따라 정리 및 분리해서 한눈에 보기 편하게 배치하는 것이 중요합니다. 그럼 길드 로비 UI 부터 시작하겠습니다. 1. 길드 로비 UI 설계 <그림 1. 로스트 소드 길드 UI> 로스트 소드의 경우 상단에 탭 버튼으로 길드에 다양한 시스템을 확인할 수 있습니다. 메인으로 되는 '길드 정보' 탭을 길드 입장 시 선택되는 기본 값으로 잡고 있습니다. ■ 좌측 영역: 길드의 정체성 (Static Info) 길드 명함: 길드 마크(엠블럼), 길드명, 현재 길드 레벨. 성장 지표: 다음 레벨까지의 경험치(공헌도) 바. 우리 길드가 얼마나 성장했는지 시각적으로 보여주어 공동의 목표를 상기시킵니다. ■ 중앙 영역: 길드의 방향성 (Guild Usage) 공지사항:  길드장이 작성한 공지를 로비 한가운데에 배치하여 커뮤니티의 방향성을 공유합니다. 기부: 매일 수행하는 핵심 루틴 중 하나. 출석: 이것도 마찬가지로 매일 수행하는 루틴. ■ 우측 영역: 길드의 방향성 (Guild Usage) 길드 투자: 일정 금액 및 길드 코인을 투자해 일정 금액이 모이면 보상을 지급하는 시스템 이처럼 수집형 RPG 게임에서 길드 로비의 UI 설계는 위와 같이 잡는 것으로 생각해주시면 됩니다. 2. 길드 출석 시스템: 접속의 가치 부여 출석은 유저가 길드원으로서 수행하는 가장 기초적인 활동입니다. 여기에 추가로 길드 출석을 진행하면 어떤 이점이 있는지 이 행동을 진행하면 어떤 이득이 있고 하지 않는다면 어떤 불이익이 있는지 설명해주는 이야기를 보통 공지 사항 부...

 안녕하세요. 호랭이 물어갈 기획놈들입니다.  지난 프롤로그에서 길드 시스템을 도대체 왜 만들어야 하는지, 그 거대한 의도에 대해 다루어 보았습니다.  오늘은 기획서의 본편으로 들어가, 길드 시스템을 게임 속에 실제로 구현하기 위한 가장 뼈대가 되는 기술적, 구조적 설계에 대해 이야기해 보겠습니다. 지난 시간에 길드를 '왜' 만드는지, 그 역할에 대해 진지하게 고민해 보았습니다. 결론적으로 길드는 게임 내의 '작은 사회'입니다. 이 사회가 삐그덕거리지 않고 원활하게 돌아가려면 명확한 시스템(규칙)이 필요합니다. 우선 이 작은 사회를 어떠한 방식으로 설계하고 만들지(서버 타입을 웹 방식으로 할지 소켓으로 할지) 생각하고 그 다음으로 '작은 사회'라고 했는데 이때 구성원은 어떻게 나눠야 할지 마지막으로 그렇게 나눈 구성원의 권한은 어떻게 되는지 알아보겠습니다. 1. 퀄리티를 가르는 보이지 않는 손: 웹(Web) vs 소켓(Socket) 길드 시스템 기획에 들어가기 앞서, 기획자가 개발팀과 가장 먼저 합의해야 할 중대한 사안이 바로 '서버 동기화 방식'입니다.  이 선택이 우리가 아는 '진짜 살아 숨 쉬는 길드'를 만들지, 아니면 '껍데기만 길드인 웹 게시판'을 만들지를 결정합니다. 그럼 간략하게 웹 방식과 소켓 방식에 대해 이야기 드리겠습니다. <그림 1. 추방을 당했지만 추방 당한 줄 모르는 유저> 웹(Web) 방식 (비동기화)   흔히 네이버 카페나 게시판을 생각하시면 됩니다.  클라이언트가 서버에 패킷(요청)을 쏠 때만 데이터를 받아옵니다.  만약 이 방식으로 길드를 만들면 치명적인 UX 붕괴가 발생합니다.  길드장 또는 부길드장이 나를 길드에서 강퇴시켰더라도, 내가 화면을 새로고침하거나 재접속하기 전까지는 내 화면에 여전히 길드원으로 나오는 '유령 상태'가 유지됩니다.  강퇴당한 줄도 모르고 길드 채팅을 치는 대참사가 벌어지는 것이죠. 더 슬픈 ...