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

  와룡전 메인 페이지 진짜 메인 페이지 만큼은 꽤나 깔끔하게 잘 뽑아줬다! 출정과 무장 열람 정도로 단출한 화면이지만 상당히 기대감이 있는 화면이었는데.. 사실 '와룡전' 이라고 하면 내가 군주가 아닌 군사가 되어 건의를 하고 내정에 장수를 배치하고 전쟁의 경우 타국이 침공을 하지 않는 이상은 원한다고 아무때나 전쟁을 진행하는 것이 아닌 군주에게 건의 후 승낙 했을 시 타국과의 전쟁이 진행되는 일반적인 그 당시 삼국지와는 다른 느낌을 주던 게임이었다. 그런 게임을 와룡전 만들어줘! 딱 이 한마디로 저런 기대감 넘치는 화면을 만들어줬으니 스스로 AI의 발전이 참 대단하구나! 란 생각을 했지만 출정 버튼을 누르자마자 모든 기대는 와르르 무너졌다. 와룡전 출정 페이지 여기까지도 진짜 기대감을 뿜뿜하며 이야 뭔 AI가 말 한마디 했다고 저렇게 만들어주냐!  진짜 엄청난 일을 내가 하고 있구나! 란 생각이 들었다. 특히 삼국지 하면 시나리오 선택하고 원하는 군주 선택하면 시작되는 페이지인데 이걸 이 녀석이 구현한 것인가?  정말 기술의 발전이 놀랍다는 생각을 하게 되는 화면이다. 그리고 아래 두 개의 전투에 잠금 표시가 있는 것을 보고  오!! 황건의 난을 시원하게 이기면 호뢰관 전투가 진행되는구나!  이런 생각을 품으며 관도 대전까지 있는 것을 보니 원소도 고르고 조조도 고를 수 있구나!  진짜 게임 회사에서 사람 쉽게 잘라내는데 거기엔 이유가 있는 법!! 그럼 난 혹시나 회사가 힘들어지거나 해고의 바람이 불어도 저렇게 단어 몇 글자 쳐도 쉽사리 게임이 나오는 시기를 생각하면 다시 한번 창업에 도전해야 하나?  이런 참 미친 생각을 잠깐이지만 했다는 것이 너무 창피할 정도로 전투 화면이 사람의 기운을 쭉 빼버렸다.  전투 화면   쌍욕을 할 뻔 했다!  아니 그냥 욕을 바로 박았다!  그럼 그렇지!!  AI는 신나게 내가 원하는 내용을 싹 다 이야기해줘야 하는데...

  오늘 오후부터 시작하는 와룡전 리메이크 프로젝트 오늘은 와룡전 리메이크에 첫 발을 내딛는 날입니다. 항상 이야기 하지만 전 기획자 입니다! 천상 기획자!! 그냥 시스템 기획만 하는 사람 그래도 고전 게임을 한번 만들어봐야지! 라고 이야기하며 과거에 엄청 재미나게 즐겼던 게임을 한번 만들어 볼 생각을 가지고 클로드도 프로로 업그레이드 했는데 와룡전 만들자 이렇게 말하고 버튼 몇번 띡띡 누르니 토큰 다 썼다고 am3:40 에 충전 된다는 소리만 나오네요 사용 툴 리스트 및 버전 - 클로드 : Sonnet 4.6 적응형 - 기획자 : 나 - 컴퓨터 : Cpu: 7950X3D                Gpu: Rtx 4080Super                Ram: 64G 그 외엔 모두 다 제가 텍스트 치고 알아서 잘 만들어 볼 예정입니다. 40대 기획자 아저씨 - 고전 게임을 그리워하며 최애 게임인 와룡전 리메이크 시작하겠습니다! 다음화 예고 시원한 토큰 샤워로 개발 일기를 1개씩 채워나갈 예정입니다. 내일 회사 가서 플머 아저씨들한테 자랑해야지! 그리고 너네 필요 없다고! 놀릴 예정! 왠지 사과만 죽어라 할 것 같지만 그래도 한 마디 해야지 홀로 서기 중이라고!! 다음화는 이거 누르시면 됩니다.

포스팅 요약 키우기 게임에서 캐릭터 레벨을 999+로 설계하면 스탯 시트가 순식간에 수십만 줄이 됩니다. 이걸 어떻게 줄이고, 개발팀에 어떻게 설득하느냐 — 그 판단 과정을 정리했습니다. 레벨 설계하다가 멘탈이 나간 날 키우기 게임을 만들고 있습니다. 키우기 장르 특성상 레벨이 일반적인 RPG처럼 99에서 끝나지 않습니다. 최소 999, 길게 보면 사실상 무한대에 가까운 확장을 전제로 설계해야 합니다. 그러다 보니 캐릭터 한 명당 스탯 시트를 짜면 1,000줄 단위 가 기본입니다. 여기에 10년 서비스를 목표로 앞뒤 버퍼까지 잡으면 캐릭터 한 명에 만 줄 . 캐릭터가 10명이면 10만 줄, 100명이면 100만 줄입니다. 고유 ID 앞자리 숫자도 만 단위로 맞춰야 하고요. 솔직히 말하면 이건 개 미친짓 입니다. 영혼의 밸런스를 잡는 프로젝트가 아닌 이상, 이 구조로 가면 기획자 혼자 엑셀 노가다에 묻힙니다. 해결책 1 — 개발팀에 구조를 먼저 제안하세요 가장 현실적인 방법은 기획자가 먼저 구조를 제안하고, 개발팀과 합의하는 겁니다. 방법은 간단합니다. 1레벨과 최종 레벨(예: 1,000레벨)의 최대 스탯만 정해두고, 레벨 1 상승 시 스탯 증가량을 최종값 ÷ 최대 레벨로 자동 계산하도록 개발에 요청합니다. 기획서에는 시작값과 끝값, 증가 공식 만 적으면 됩니다. 중간 999줄은 개발 쪽에서 코드로 처리합니다. 주니어 기획자 입장에서 이 제안을 개발팀에 설득할 때 포인트는 하나입니다. "제가 줄 별로 다 채우는 것보다, 공식으로 처리하면 밸런스 수정도 훨씬 빠릅니다." 틀린 말이 아니고, 개발팀 입장에서도 나쁘지 않은 제안입니다. 해결책 2 — BM 구조를 먼저 확인하세요 다만 이 방법이 통하지 않는 경우가 있습니다. 핵심 BM이 장비 강화나 연구 트리 같은 곳에 몰려있다면, 레벨 구간별로 스탯 분기점이 생겨야 유저가 결제 허들을 느낍니다. 이럴 때는 레벨 수를 줄이더라도 수백 단위로 압축 하...