Skip to Content
2026Idle Obelisk Miner 심층 분석: 인디 개발자가 벤치마킹해야 할 것

Idle Obelisk Miner 심층 분석: 인디 개발자가 벤치마킹해야 할 것

결론부터 말하면, 방치형게임갤에서 말하는 “오벨”은 Idle Obelisk Miner다.

이 게임을 인디 개발자 관점에서 볼 때 가장 중요한 포인트는 “콘텐츠가 엄청 많다”가 아니다. 진짜 강점은 새로운 시스템을 계속 추가하면서도 이전에 만든 시스템의 가치를 죽이지 않는 구조에 있다.

오벨은 전형적인 방치형 게임처럼 숫자만 커지는 게임이 아니라, 진행할수록 게임 자체의 규칙과 할 일이 계속 바뀌는 unfolding game에 가깝다. 처음에는 광석을 캐고 바를 만드는 단순한 게임인데, 어느 순간 폭탄·드론·스킬트리·챌린지·카드·펫·별자리·고고학·낚시·Arcanist가 붙으면서 “내가 처음 시작한 게임과 같은 게임이 맞나?” 싶은 수준으로 확장된다.

그리고 이 구조가 방치형게임갤에서 오벨 얘기가 계속 나오는 핵심 이유다.


1. 지금 오벨이 어느 정도 규모인가

오벨은 더 이상 “소수 매니아가 하는 작은 방치형 게임” 수준이 아니다.

2026년 9월 기준 Google Play에는 1M+ 다운로드, 평점 4.8, 약 2.9만 리뷰가 표시되어 있고, 미국 App Store에서는 4.9점, 약 2.8천 평가를 받고 있다. Google Play 페이지에서는 당시 **Simulation 매출 순위 상위권(#7)**으로도 노출됐다.

업계 데이터 쪽 숫자는 더 인상적이다. PocketGamer.biz가 AppMagic 추정치를 인용한 2026년 기사에 따르면 Checkbox Entertainment는 Idle Obelisk Miner에서 누적 약 1,100만 달러의 플레이어 지출, 약 93.3만 다운로드를 기록한 것으로 추정되며, 2025년 12월에는 한 달 매출이 처음으로 110만 달러를 넘었다.

단순 계산하면 누적 다운로드당 매출은 약 11.8달러다. 캐주얼 방치형 게임치고 굉장히 높은 수치다.

2026년 8월 모바일 게임 업계 팟캐스트 two & a half gamers는 더 공격적인 추정치를 내놨다. 당시 오벨이 일 매출 약 10만 달러, 일 다운로드 4~5천 수준이라고 분석했다. 이 수치는 공식 재무자료가 아니라 제3자 추정치라 그대로 사실로 받아들이면 안 되지만, 최소한 업계가 오벨을 “작은 인디게임”이 아니라 고LTV 하드코어 방치형 성공 사례로 보기 시작했다는 뜻이다.

회사 자체도 특이하다. 영국 Companies House의 Checkbox Entertainment LTD 기록을 보면 2019년 설립된 회사이고, 2024년 공개 재무 요약 기준 직원 수는 1명, 총자산 약 £501k, 순자산 약 £351k였다. 현재는 Alex 혼자 모든 것을 만드는 형태는 아니다. 개발 로그를 보면 Alex가 게임의 핵심을 만들었고, Celio가 아트, FrozenAra가 백엔드 및 각종 기술 작업에 참여했다. 최근 커뮤니티에서는 3인 팀으로 언급되기도 한다.

즉, 오벨은 “완전한 1인 개발작”이라고 단정하기보다 1인 중심으로 출발해 초소형 팀으로 확장된 게임으로 보는 게 정확하다.

여기서 인디 개발자가 봐야 할 점

오벨의 성공은 대형 콘텐츠 제작팀, 고급 3D 그래픽, 대규모 UA가 전제되지 않는다.

시스템 설계와 장기 밸런싱이 압도적으로 좋은 게임이면 작은 팀도 매우 높은 LTV를 만들 수 있다.


2. 게임의 기본 뼈대

오벨의 가장 기초적인 루프는 단순하다.

광석 채굴 → 바 제작 → 업그레이드 → 더 좋은 광석 채굴 → 레벨 상승 → Prestige → 영구 성장 → Obelisk 격파 → 새 시스템 해금

중요한 것은 중앙에 Obelisk라는 명확한 보스 게이트가 있다는 점이다.

Obelisk는 단순히 보스가 아니라 사실상 게임 전체의 콘텐츠 해금 스위치다.

대표적인 해금 흐름은 다음과 같다.

Obelisk 진행주요 해금
1Workshop
2Drones
4Skill Tree
10Challenges
12Contracts
15Cards
17Pets
19Construct
23Stargazing
30Archaeology
37Fishing
70 전후Arcanist 계열 후반 콘텐츠

이 구조가 굉장히 중요하다.

보통 인디 개발자가 콘텐츠를 많이 넣고 싶으면 처음부터 메뉴에 전부 노출한다. 그러면 플레이어는 시작 5분 만에 버튼 18개를 보고 피로해진다.

오벨은 반대로 콘텐츠를 가진 채로 숨겨둔다.

플레이어는 항상 “다음 Obelisk를 잡으면 뭔가 열린다”는 기대를 갖는다.

그래서 동일한 채굴 루프를 반복하는 동안에도 단순히 숫자가 올라가는 것이 아니라 다음 게임 규칙을 해금한다는 느낌이 생긴다.


3. 오벨의 진짜 핵심: 새로운 시스템이 옛 시스템을 다시 살린다

오벨의 시스템 숫자만 보면 위험한 설계처럼 보인다.

  • 광석
  • 바 제작
  • Prestige
  • Artifact
  • Bomb
  • Drone
  • Contract
  • Challenge
  • Card
  • Pet
  • Statue / Construct
  • Stargazing
  • Archaeology
  • Fishing
  • Relic
  • Lootbug
  • Event
  • Arcanist
  • 각종 후반 확장

일반적인 게임이라면 이렇게 시스템이 늘어날수록 과거 콘텐츠가 쓰레기가 된다.

하지만 오벨은 상당수 시스템을 서로 교차 연결한다.

예를 들어 카드 시스템은 광석, 바, 폭탄, 드론, 광맥, 펫, 별, 고고학 블록, 물고기 등 거의 모든 행동에서 파생된다. 즉 카드를 추가하는 순간 기존 채굴이나 제작이 다시 의미를 얻는다.

Stargazing은 별이라는 새로운 콘텐츠를 추가하지만, 그 진행에 Vein 자원이 필요하다. Fishing에서 얻는 아이템은 다시 별 생성률, 골든 플로어, 레인보우 플로어, 대미지 등에 영향을 준다. Skill Tree는 단순 스탯 업그레이드만 주는 것이 아니라 Auto Floor, Auto Bomber, Veinmorpher, Polychrome Card 같은 새 행동 방식 자체를 해금한다.

그래서 새 시스템이 “옆에 붙은 미니게임”이 아니라 기존 게임 전체의 효율을 다시 계산하게 만든다.

이게 오벨의 가장 중요한 설계 철학이다.

새 콘텐츠가 생길 때마다 플레이어가 과거 시스템의 최적해를 다시 계산하게 만든다.

방치형게임갤에서도 이 현상이 그대로 보인다.

“초반에는 Bomb of Plenty가 좋았는데 월드3에 가니 Transmuter가 더 좋아진다”, “별자리를 먼저 올릴지 카드 작업을 할지 모르겠다”, “낚시 열리는 게 기대된다”, “정해진 공략이 없어서 더 재미있다” 같은 글이 계속 나온다.

즉 게임이 플레이어에게 지속적으로 성장 동선 문제를 던진다.


4. 왜 숫자게임인데 전략게임처럼 느껴지는가

많은 방치형 게임은 실제로 선택지가 없다.

돈 모음 → 가장 싼 업그레이드 구매 → 다음 업그레이드 구매.

오벨은 성장 축이 너무 많기 때문에 모든 것을 동시에 올릴 수 없다.

예를 들어 중반 플레이어는 동시에 이런 고민을 한다.

  • Gem을 Bomb Cap에 쓸까
  • Card Gilding에 쓸까
  • Skill Point를 살까
  • Star를 올릴까
  • Archaeology를 밀까
  • Fishing을 밀까
  • Drone 레벨을 올릴까
  • 다음 Obelisk를 억지로 잡을까

중요한 것은 정답이 플레이어의 현재 상태에 따라 달라진다는 것이다.

이 덕분에 단순한 방치형 게임인데도 플레이어들이 서로 스크린샷을 올리고 “내 진로 좀 봐줘”라고 질문한다.

게임의 메타 자체가 커뮤니티 콘텐츠가 된다.

Wiki에 Bomb/Drone 계산기, Archaeology 계산기, 이벤트 시뮬레이터, 자원 계산기, Transmuter vs Bomb of Plenty 계산기 등이 따로 존재한다. 유저가 Monte Carlo 시뮬레이터까지 만든다.

이건 개발자 입장에서 엄청난 자산이다.

게임의 시스템 깊이가 충분하면 유저가 게임 밖에서 게임을 계속 플레이한다.

Discord에서 토론하고, Reddit에서 빌드를 묻고, Wiki를 읽고, 스프레드시트를 만들고, 계산기를 돌린다.

실제 앱을 켜지 않은 시간에도 머릿속에서는 오벨을 하고 있는 것이다.


5. Automation을 “편의 기능”이 아니라 “보상”으로 만든다

오벨의 또 하나 중요한 점은 초반에는 직접 해야 하는 행동이 많지만, 진행하면서 자동화가 해금된다는 것이다.

예를 들면:

  • Drone
  • Auto Floor
  • Auto Bomber
  • Star auto collect 계열
  • 각종 오프라인 시스템

처음부터 자동이면 플레이어가 시스템을 이해하지 못한다.

반대로 평생 수동이면 노동이 된다.

오벨은 상당 부분을 다음과 같이 설계한다.

수동으로 시스템 학습 → 반복에 익숙해짐 → 자동화 해금 → 새로운 수동 시스템 등장

이 패턴을 계속 반복한다.

그래서 자동화가 QoL 옵션이 아니라 강력한 성장 보상처럼 느껴진다.

이건 인디 방치형 게임에서 거의 그대로 벤치마킹할 가치가 있다.

다만 오벨은 이 부분을 지나치게 밀어붙인 구간도 있다. 방치형게임갤의 2개월 후기에서는 “초반이 매우 액티브하다”, “재화 손해를 보기 싫으면 약 1시간마다 접속해야 한다”는 불만이 나온다. Reddit에서도 최적 플레이는 장시간 앱을 켜두는 쪽이라는 지적이 있다.

따라서 복사할 것은 자동화의 성장 보상화이지, “게임을 켜두게 만드는 압박”은 아니다.


6. RNG가 단순 가챠가 아니라 생산량 최적화 문제가 된다

오벨에는 희귀 드롭이 굉장히 많다.

카드는 액션마다 매우 낮은 확률로 등장하고, Polychrome/Infernal 등 후반 희귀 단계도 존재한다. 특정 펫이나 카드 역시 극단적으로 낮은 확률을 가진다.

그런데 재미있는 점은 플레이어가 단순히 “운 좋기를 기다리는” 것이 아니라 시도 횟수를 늘리는 방법을 최적화한다는 것이다.

예를 들어:

  • Bomb 발사 횟수 증가
  • Drone uptime 증가
  • Craft multiplier 증가
  • Game speed 증가
  • 특정 floor multiplier 증가
  • Auto 시스템 해금

결국 확률형 보상이 생산설비 최적화 게임으로 바뀐다.

이 방식은 방치형과 궁합이 좋다.

좋은 희귀 드롭 설계는 다음 두 가지가 같이 있어야 한다.

  1. 기본 성장 경로는 RNG 없이도 전진한다.
  2. RNG jackpot은 성장 속도나 빌드를 크게 바꾼다.

오벨은 대체로 이 구조를 지킨다.

다만 지나치게 희귀한 카드와 완성도 100%를 엮으면 피로가 생긴다. 실제 App Store 리뷰에는 Founder Bomb에 연결된 카드 때문에 완전 무과금 100% completion이 사실상 불가능하다는 불만도 있다.

따라서 인디 개발자가 따라 한다면 희귀 드롭은 속도를 바꾸되 진행 자격 자체를 잠그지 않는 방향이 안전하다.


7. “No Ads”가 단순 착한 BM이 아니라 고LTV 전략이다

오벨의 BM을 잘못 이해하면 안 된다.

이 게임은 광고가 없다. 심지어 선택형 보상 광고도 없다.

하지만 과금이 약한 게임도 아니다.

App Store에 노출되는 IAP만 봐도:

  • Drone Value Pack $0.99
  • Megabomb $1.99
  • Transmuter Bomb $2.99
  • 2x Bar Income + 3x Bomb Damage $9.99
  • 2x Ore and PP Income $12.99
  • Founders Bundle $24.99
  • 여러 Value Pack / Limited Pack

등이 존재한다.

Founder에는 추가 VIP progression도 있다. Wiki 기준 Founder 구매 이후 실결제 금액에 따라 VIP Tier가 올라가고 Freebie, Game Speed, Supply Drop, Rainbow Floor 등 다양한 영구 보너스가 증가한다.

즉 구조적으로 보면 오벨은 저압박 + 고지출 깊이 모델이다.

차이는 구매를 강요하는 방식에 있다.

플레이 중 광고 팝업을 띄우거나 “지금 안 사면 손해”를 계속 보여주지 않는다. Gem도 Freebie Pack과 각종 시스템으로 지속 획득할 수 있고, 중후반에는 Gem 생산 자체를 하나의 성장 축으로 만든다.

그래서 커뮤니티 반응이 독특하다.

Reddit에는 “광고가 없고 탐욕스럽지 않아서 오히려 돈을 더 썼다”, “Founder Pack은 효율보다 개발자를 후원한다는 의미가 크다”는 댓글이 반복적으로 나온다.

이것은 굉장히 중요한 BM 인사이트다.

유저는 과금 자체를 싫어하는 것이 아니라, 게임이 자신을 과금 대상으로 취급하는 느낌을 싫어한다.

오벨은 먼저 장기간의 재미와 신뢰를 준 다음, 고액 패키지를 “후원 + 가속”처럼 받아들이게 만든다.

인디 개발자가 벤치마킹할 방식

초기부터 VIP 10단계를 그대로 복사할 필요는 없다.

오히려 아래 구조가 현실적이다.

  • 광고 없음
  • 첫 3~7일 동안 과금 팝업 최소화
  • 유료 재화도 플레이로 획득 가능
  • 1~2개의 영구 Supporter Pack 제공
  • Supporter Pack은 QoL + 적당한 영구 배수 + 뱃지/스킨
  • 콘텐츠 자체는 무과금도 모두 접근 가능

이렇게 하면 “결제 유도”가 아니라 좋아하는 게임을 후원하는 행위로 포지셔닝할 수 있다.


8. Founder 시스템은 사실상 커뮤니티형 크라우드펀딩 장치다

Founder Bundle은 단순 패키지가 아니다.

Founder에게는 게임 내 효과 외에도 Badge, Founder Stats, Discord Role 등이 붙는다. 일정 Founder 수에 도달하면 개발자가 전체 Founder 보상을 추가하기도 했다.

이 구조는 결제자를 “고래”가 아니라 프로젝트 후원자로 재정의한다.

이게 꽤 영리하다.

일반 모바일게임에서는 과금 사실을 자랑하기 어렵다.

오벨에서는 반대로 “나도 Founder가 됐다”는 게시물이 올라오고 다른 유저가 환영한다.

결제가 사회적 지위와 개발자 후원의 의미를 동시에 얻는다.

인디게임이라면 이 방식은 충분히 응용 가능하다.

예:

  • Supporter Badge
  • 게임 크레딧 이름 등재
  • Discord Role
  • Supporter 수 milestone마다 전체 유저에게 소액 보상
  • 커뮤니티 투표로 NPC 이름 결정
  • 오래된 supporter를 게임 내 statue/NPC로 등장

실제로 오벨은 업데이트에서 커뮤니티 멤버를 Statue로 넣는 방식도 사용했다.

대형 UA가 없는 인디게임에서 이런 구조는 돈을 쓰는 유저를 동시에 마케팅 채널로 만든다.


9. Completion %가 장기 목표를 만드는 방식

오벨은 전체 Completion Percentage를 눈에 보이게 제공한다.

이것이 생각보다 강력하다.

보통 방치형 게임의 문제는 플레이어가 “내가 이 게임을 얼마나 했는지” 알기 어렵다는 것이다.

오벨에서는 카드 하나, 업그레이드 하나, Statue 하나가 Completion으로 누적된다.

그래서 플레이어는 다음과 같은 목표를 가진다.

  • 다음 Obelisk
  • 다음 시스템 해금
  • 특정 Card
  • 모든 Card Gilding
  • 특정 Star max
  • Fishing progress
  • Archaeology progress
  • 전체 Completion 50%
  • 전체 Completion 100%

시간축이 여러 개 겹친다.

새 대형 업데이트가 나오면 Completion 분모가 커져 기존 70% 플레이어가 50%대로 내려가기도 한다. 일반 게임이면 “내 진행도가 후퇴했다”고 화낼 수 있는데, 오벨 커뮤니티는 오히려 “할 게 또 생겼다”는 반응을 보이는 경우가 많다.

이건 엔드게임을 계속 뒤로 미는 아주 값싼 방법이다.

새 월드를 만들 때 100개의 스토리 퀘스트가 없어도 Completion 항목 1,000개를 추가하면 수집가에게는 수개월의 목표가 생긴다.


10. Live Ops가 메인 게임과 분리되어 있다

오벨의 이벤트는 별도의 진행 구조와 Prestige를 가진다.

과거 방치형게임갤 이벤트 공략을 보면 이벤트는 메인 게임 진행도와 크게 관계없이 뉴비도 참여할 수 있도록 구성되어 있었다.

이 방식도 좋다.

장기 서비스 게임에서 메인 계정 스펙을 그대로 이벤트에 적용하면 오래 한 사람만 즐긴다.

반대로 별도 성장판을 주면:

  • 신규 유저도 참여 가능
  • 기존 유저도 처음부터 다시 성장하는 재미를 경험
  • 개발자가 밸런스를 독립적으로 조절 가능
  • 본게임 정체 구간에서 다른 속도의 progression 제공

할 수 있다.

작은 팀이라면 시즌마다 거대한 신규 콘텐츠를 만들기보다 같은 시스템을 다른 룰로 재조합하는 이벤트가 훨씬 효율적이다.


11. 작은 팀 관점에서 특히 배워야 할 기술적 선택

오벨은 GameMaker Studio 2 / GML로 만들어졌다.

화려한 엔진 기술보다 중요한 것은 방대한 상태를 안정적으로 저장하고 계산하는 시스템이다.

FrozenAra의 개발 로그를 보면 실제로 오벨 팀이 시간을 많이 쓴 부분은 이런 문제다.

  • autosave 중 변수 scope 충돌
  • cloud save 안정성
  • custom OAuth2 account
  • Go backend
  • PostgreSQL save database
  • RNG state 저장
  • save scumming 방지
  • 대형 숫자 overflow

2025년 개발 로그 기준 자체 계정 시스템에는 2만 명 이상이 가입했고, 전체 압축 save DB 용량은 약 550MB에 불과했다고 한다.

이 게임에서 인디 개발자가 배워야 할 기술적 우선순위는 그래픽이 아니다.

1. Modifier 시스템

스탯을 코드 곳곳에서 직접 계산하지 말고 통합해야 한다.

예:

Base Value × Permanent Multiplier × Temporary Buff × Card × Pet × Star × Event Modifier

시스템이 10개가 넘어가면 이 구조가 없으면 밸런스 수정 자체가 불가능해진다.

2. Unlock Predicate 시스템

기능마다 하드코딩하지 말고:

obelisk_level >= 23

card_count >= X

world >= 3

같은 조건을 데이터로 관리하는 편이 좋다.

3. Action Event Bus

onMine, onCraft, onBomb, onFish, onPrestige 같은 이벤트를 중앙화하면 나중에 Card, Achievement, Quest, Drop Table을 기존 코드 수정 없이 붙일 수 있다.

오벨 같은 “기존 행동에 새로운 드롭을 붙이는 게임”에서는 거의 필수다.

4. Save Versioning

장기 운영에서는 세이브 포맷이 계속 바뀐다.

save_version과 migration 함수를 초기에 만드는 것이 좋다.

5. Offline Simulation

방치형에서 로딩 후 10초간 계산하는 순간 UX가 무너진다.

Reddit에서 오벨이 배터리를 많이 먹지 않고, 오프라인 계산이 빠르다는 점이 반복적으로 칭찬받는다.

시뮬레이션을 프레임 단위로 재생하지 말고 가능한 부분은 시간 × 기대값 형태로 집계해야 한다.


12. 방치형게임갤 반응에서 보이는 오벨의 힘

최근 방치형게임갤 검색 결과를 보면 오벨은 단순 추천글보다 진행 질문이 많다.

이건 좋은 신호다.

대표적으로:

  • “2주 동안 이것만 붙잡고 있었다”
  • “15일차인데 개재밌다”
  • “낚시 열릴 것 같아서 설렌다”
  • “정해진 공략이 없어서 더 재밌다”
  • “보석을 카드에 쓸지 Bomb Cap에 쓸지 모르겠다”
  • “BOP보다 Transmuter가 좋아지는 시점이 있었구나”

같은 반응이 나온다.

반대로 불만도 명확하다.

  • 초반이 너무 액티브함
  • 매크로 유혹이 있음
  • 자원 손실을 줄이려면 자주 접속해야 함
  • 무엇을 해야 할지 지나치게 복잡할 수 있음
  • Wiki 의존도가 높음
  • 일부 late-game grind가 지나치게 길음

즉 오벨은 누구에게나 좋은 게임이 아니라, 숫자 최적화와 장기 progression을 좋아하는 사람에게 극단적으로 맞춘 게임이다.

이게 오히려 성공 이유다.

많은 모바일게임은 모든 사람에게 7점짜리 게임을 만들려고 한다.

오벨은 특정 유저에게 10점짜리 게임을 만든다.


13. 인디 개발자가 벤치마킹해야 할 것 — 우선순위

S급: 반드시 가져올 만한 것

1. Unfolding 구조

처음부터 모든 기능을 보여주지 마라.

플레이 30분, 2시간, 1일, 3일, 1주 단위로 게임 규칙 자체가 하나씩 열리게 만드는 게 좋다.

단순히 “새 업그레이드”가 아니라 “새 메뉴/새 행동/새 의사결정”이어야 한다.

2. 중앙 progression gate

오벨의 Obelisk처럼 모든 시스템을 묶는 하나의 목표가 필요하다.

예:

  • Tower 층수
  • Boss rank
  • Planet
  • 연구 레벨
  • 던전 깊이

플레이어는 항상 “다음 해금까지 얼마 남았는지” 알아야 한다.

3. 새 시스템이 옛 시스템 2개 이상을 강화하게 만들기

내가 가장 추천하는 규칙이다.

새 시스템을 추가할 때 최소한 기존 시스템 2개에서 입력을 받고, 기존 시스템 2개에 출력을 주게 만들어라.

예:

Fishing

입력:

  • Mining에서 bait 획득
  • Prestige에서 rod bonus 획득

출력:

  • Fish가 crafting multiplier 증가
  • 특정 fish가 boss damage 증가

이렇게 해야 콘텐츠가 섬처럼 분리되지 않는다.

4. Automation을 progression reward로 사용

처음에는 수동으로 경험시키고, 지겨워질 때 자동화를 준다.

이 패턴은 방치형에서 매우 강하다.

5. Completion / Collection meta

하나의 장기 completion 수치를 만들어라.

카드, 업적, 펫, 연구, 보스, 희귀 아이템을 전부 이 숫자 아래 넣으면 유저는 자기 계정을 “완성 중인 프로젝트”로 보기 시작한다.


A급: 강하게 추천

6. 플레이어가 계산할 여지를 남겨라

모든 업그레이드에 “DPS +10%”만 넣으면 계산할 게 없다.

서로 다른 축을 만들어야 한다.

  • 생산량
  • 생산 속도
  • 치명타
  • 드롭률
  • 재화 변환 효율
  • 자동화 속도
  • capacity
  • offline cap

그러면 상황마다 최적해가 바뀐다.

7. Premium currency 자체를 생산 시스템으로 만들기

Gem을 오직 현금으로만 사게 하지 말고, 플레이 자체로 Gem 생산 효율을 키우게 하는 구조가 좋다.

“현질 재화”가 아니라 또 하나의 progression resource가 된다.

8. Supporter monetization

과금 버튼을 계속 밀지 말고, 오래 플레이한 유저에게 영구 supporter pack을 제공하는 방식이 인디게임에 특히 잘 맞는다.


14. 벤치마킹하지 않는 게 좋은 부분

1. 초반 과도한 액티브 플레이

“자동화를 보상으로 준다”와 “처음 20시간 노동시킨다”는 다르다.

핵심 루프를 이해하는 데 필요한 수동 플레이만 남겨야 한다.

2. 1시간 단위 접속 압박

방치형은 기본적으로 플레이어가 떠나는 것을 허용해야 한다.

최적 플레이와 현실적인 플레이의 격차를 너무 크게 만들면 유저가 매크로/에뮬레이터로 간다.

3. Wiki 없이는 이해하기 어려운 정보 구조

오벨의 커뮤니티 활성화에는 도움이 되었지만 진입장벽도 크다.

인디게임이라면 게임 안에 최소한:

  • 다음 목표
  • 주요 공식
  • 아이템 출처
  • unlock 조건

정도는 보여주는 편이 좋다.

4. 시스템 수 자체를 따라 하기

오벨은 수년에 걸쳐 쌓인 게임이다.

처음부터 Fishing, Archaeology, Star, Card, Pet을 다 만들면 개발이 끝나지 않는다.

오벨을 베끼는 가장 나쁜 방법은 오벨의 콘텐츠 개수를 베끼는 것이다.


15. 내가 1인 인디 개발자라면 이렇게 만든다

오벨의 구조를 그대로 복사하지 않고 최소 형태로 줄이면 다음 정도면 된다.

출시 버전

Core

  • 자원 5~8종
  • 제작 자원 3~5종
  • 업그레이드 30~50개
  • 중앙 Boss progression
  • Prestige
  • 영구 Artifact

첫 번째 unfolding layer

  • Bomb 또는 Active Skill

두 번째 unfolding layer

  • Drone 또는 Worker automation

세 번째 unfolding layer

  • Card / Collection system

네 번째 unfolding layer

  • Challenge

이 정도면 충분하다.

중요한 것은 시스템 개수가 아니라 서로 물리는 구조다.

예를 들어 출시 버전에서 4개 시스템만 있어도:

  • Bomb를 많이 쓰면 Bomb Card 등장
  • Card가 Drone 속도 강화
  • Drone이 Prestige 재화 생산
  • Prestige가 Bomb capacity 강화

처럼 원형으로 연결하면 된다.

플레이어는 4개 시스템을 4개가 아니라 하나의 큰 기계처럼 느낀다.


16. 추천 콘텐츠 생산 공식

오벨식 시스템을 만들고 싶다면 새 기능 하나를 설계할 때 아래 체크리스트를 쓰는 걸 권한다.

새 시스템 하나당 반드시 넣기

1. Input 2개

기존 시스템에서 자원을 받는다.

2. Output 2개

기존 시스템을 강화한다.

3. Automation 1개

진행하면 반복 행동이 자동화된다.

4. Jackpot 1개

낮은 확률로 매우 기분 좋은 보상이 나온다.

5. Visible milestone 3개 이상

다음 목표가 항상 보인다.

6. Long-term collection 1개

카드/도감/완성도에 기록된다.

이 조건을 만족하면 작은 시스템 하나로 플레이 시간이 상당히 늘어난다.


17. 오벨에서 가장 중요한 한 문장

오벨은 “콘텐츠가 많아서” 좋은 게임이 아니다.

새 콘텐츠가 추가될 때마다 기존 콘텐츠의 가치와 최적해가 바뀌기 때문에 좋은 게임이다.

이것이 1인 개발자가 가장 크게 벤치마킹해야 할 부분이다.

화려한 그래픽이나 스토리를 매달 대량 생산할 수 없는 인디 개발자에게는 특히 중요하다.

잘 만든 시스템 하나가 다른 시스템 5개의 가치를 다시 높이면, 콘텐츠 생산비는 선형인데 플레이어가 느끼는 깊이는 기하급수적으로 커진다.

오벨의 진짜 경쟁력은 바로 이 시스템 복리다.


최종적으로 벤치마킹 우선순위를 매기면

  1. Obelisk 같은 중앙 해금 목표
  2. 진행할수록 새로운 게임이 열리는 unfolding 구조
  3. 새 시스템이 기존 시스템을 다시 중요하게 만드는 cross-link 설계
  4. 수동 → 자동화 해금을 성장 보상으로 사용하는 방식
  5. 여러 성장축 사이의 선택 문제
  6. Completion / Card / Collection을 통한 장기 목표
  7. Premium currency를 플레이로 생산 가능하게 하는 경제
  8. 광고 없는 저압박 BM + supporter형 고가 패키지
  9. Discord/Wiki/계산기를 만들 정도의 전략 공간
  10. 수년간 확장 가능한 데이터 중심 코드 구조

반대로 따라 하지 말아야 할 것은 과도한 초반 수동 플레이, 잦은 접속 압박, 설명 부족, 극단적 희귀 RNG, 콘텐츠 개수 자체다.

인디 개발자 입장에서 오벨을 가장 잘 베끼는 방법은 겉모습을 베끼는 것이 아니다.

“플레이어가 다음 시스템을 궁금해하고, 새 시스템을 열면 예전에 하던 시스템까지 다시 만지게 되는 게임”을 만드는 것이다.

그 구조만 구현해도 오벨에서 가장 가치 있는 70~80%를 가져온 셈이다.


참고 자료

Last updated on