#002. 세상에 쉬운 일은 하나도 없다! 와룡전을 만들라고 했는데....

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

#001. 클로드와 만드는 와룡전 리메이크 기획 지금 시작합니다!

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

캐릭터 레벨 스탯 시트, 100만 줄 쓸 뻔했습니다 — 키우기 게임 데이터 설계 실무 노트

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

하향 패치 강행했다가 1주일 만에 롤백한 이유 — 경영진을 설득하지 못한 기획자의 기록

이미지
  매출 압박과 하향 패치의 딜레마 라이브 게임(Live Ops)을 서비스하다 보면, 매출 압박에 시달리는 사업부나 경영진으로부터 아찔한 밸런싱 오더가 내려오곤 합니다. "최근 캐시 상점 패키지 수익률이 너무 낮습니다."  로그를 까보니 특정 'NPC 약탈 티켓' 의 효율이 너무 좋아서 헤비 유저들이 결제를 안 하네요.  "당장 다음 정기 점검 때 이 티켓 보상을 삭제하세요." 이런 오더가 내려오면 기획자는 선택의 기로에 섭니다.  경영진의 오더를 수용하여 공식 카페가 불타는 것을 지켜보거나, 치밀하게 수치화된 데이터로 오더의 위험성을 증명하고 시스템을 방어하거나. 저 역시 과거, 전자의 길을 택해 100% 롤백(Rollback)을 겪어야만 했던 뼈아픈 기억이 있습니다.  그날의 실패 사례와 그 이면에 숨겨진 리스크 통제 로직을 담담하게 복기해 봅니다. 공시지가식 보상의 치명적 오류 (Loss Aversion) 당시 티켓 삭제 오더를 방어하기 위해, 해당 티켓이 가진 최대 효율을 원화 가치로 환산했습니다(약 4,500원 상당).  그리고 캐시 상점의 최대 할인율을 적용해, 사라진 티켓 자리에 최대 할인율을 적용한 자원을 직접 지급하는 '등가교환'의 우회안을 올렸습니다. 하지만 회의실에서 돌아온 대답은 차가웠습니다.  "지급량이 너무 많습니다. 할인율 빼고, 시스템 기본가로 계산해서 확 줄이세요." 저는 반대했습니다.  유저가 체감하는 티켓의 가치(실거래가)가 있는데, 개발사가 임의로 정한 기본가(공시지가)로 후려치면 유저들은 강제로 철거당하는 듯한 박탈감을 느낄 것이라 경고했죠.  하지만 결과는 기획안 반려, 그리고 원안 강행이었습니다. 경영진은 유저가 원하는 타이밍에 능동적으로 보상을 얻는 '플레이 선택권' 을 뺏는 행위의 심리적 손실(Loss Aversion)을 간과했습니다.  엑셀 상의 산술적인 숫자만 맞추면 유저의 분노가 상쇄될 것이라는 치명적인 오판의 결과...

[게임 기획 실무] AI 프롬프트로 스킬 시스템 엑셀(DB) 테이블 설계하는 방법

이미지
  어제 올린 글에서 "이력서에 단순 AI 툴 사용 가능이라고 쓰지 말고, 기획을 검증한 과정을 증명하라"라고 강조했습니다. 그러자 게시글 보셨던 지인(지망생) 분이 묻습니다. "대체 그 게임 기획 AI 프롬프트를 실무에서 어떻게 쓴다는 겁니까?" 오늘은 10년 차 이상 중소기업 시스템 파트장인 제가 실제로 AI를 협업 툴이자 시뮬레이터로 쥐어짜는 방식을 가감 없이 공개하겠습니다.  단언컨대, 저는 AI에게 "스킬 시스템 DB 구조를 만들어줘"라고 명령하고 그것을 복사해서 붙여넣는 1차원적인 접근은 절대 하지 않습니다. 1. 신입 기획자의 함정: AI에게 완성된 '기획서'를 한 번에 요구하지 마십시오 스킬 시스템 기획서를 쓴다고 가정해 봅니다.  신입이나 지망생분들이 가장 많이 하는 실수는 챗GPT를 켜자마자 이렇게 입력하는 것입니다. "MMORPG WOW 스타일의 스킬 시스템 기획서를 작성해 줘!" 이렇게 나온 텍스트는 겉보기엔 그럴싸합니다.  하지만 이건 여러분의 프로젝트 엔진이나 서버 아키텍처에는 1도 맞지 않는 '실무에서 작동하지 않는 껍데기'에 불과합니다.  기획은 소설을 쓰는 게 아닙니다.  기획자는 데이터(Data)가 클라이언트와 서버 사이에서 어떻게 굴러가는지 통제해야 합니다.  이를 고민하지 않은 결과물은 현업 개발자들에게 반려 대상 1순위가 됩니다. 👉핵심 요약:  AI에게 완성된 기획서를 통째로 요구하지 마십시오. 데이터 통제력이 결여된 기획서는 실무 포트폴리오로 사용할 수 없습니다. 2. 게임 DB 테이블 설계의 본질: 데이터의 방향성과 규칙 정립 AI에게 키보드를 두드리기 전에, 기획자 본인의 머릿속에서 먼저 '이 시스템이 우리 게임에서 어떻게 굴러갈 것인가'에 대한 확고한 뼈대가 정립되어야 합니다. 한 번 찍으면 고정되는 '트리(Tree)형' 스킬을 만들 것인가? 유저가 룬이나 보석을 박아 속성을 마음대로 ...