> For the complete documentation index, see [llms.txt](https://hetcreep.gitbook.io/hetcreep-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hetcreep.gitbook.io/hetcreep-docs/gacharatedesigndatum/guides/pricing-and-example.md).

# ราคาและตัวอย่างค่าที่ล็อกจริง (Pricing & Example)

### 5. ราคา — วิธีที่ผิด 2 รอบก่อนจะถูก

ส่วนนี้น่าจะมีประโยชน์ที่สุดสำหรับคนทำเกมไทย เพราะ **วิธีที่ดูสมเหตุสมผลที่สุดผิดทั้งสองรอบ**

#### รอบที่ 1 (ผิด) — สมมติว่าทุกเกมขายราคา USD เท่ากันทั่วโลก

เอาราคา USD ของแต่ละเกมมาหารด้วยค่าแรงไทย แล้วสรุปว่าแพงหรือถูก

**ผิดตรงไหน**: เกมกาชาสายใหญ่ทำ **regional pricing** จริง — SEA ตั้งราคาต่ำกว่า USD nominal ประมาณ 50-70% การเอาราคา USD มาเทียบตรง ๆ จึงเปรียบเทียบของคนละอย่าง

#### รอบที่ 2 (ยังผิด) — ใช้ค่าแรง**ขั้นต่ำ**เป็นตัวหารทุกประเทศ

พอแก้เป็นราคาท้องถิ่นจริงแล้ว หารด้วยค่าแรงขั้นต่ำของแต่ละประเทศ ผลออกมาว่าจีนแพงผิดปกติ (burden 12.70-15.88% เทียบกับ JP/KR/US ที่ 1.84-5.69%)

**ผิดตรงไหน**: ค่าแรงขั้นต่ำของจีนอยู่แค่ **18-26% ของค่าแรงเฉลี่ย** ขณะที่ไทยอยู่ **47-66%** และค่าเฉลี่ย OECD อยู่ที่ \~55% (อัตราส่วนนี้เรียกว่า Kaitz ratio)

พูดอีกอย่าง: **"ค่าแรงขั้นต่ำ" ไม่ได้แปลว่าสัดส่วนเดียวกันของรายได้จริงในสองประเทศ** — ใช้เป็นตัวหาร ข้ามประเทศไม่ได้

#### รอบที่ 3 (ถูก) — ราคาท้องถิ่น ÷ ค่าแรง**เฉลี่ย** ของประเทศตัวเอง ไม่ผ่าน FX เลย

วัด 9 จุดจากเกมจริง แต่ละจุดใช้ราคาในสกุลเงินของประเทศนั้น หารด้วยค่าแรงเฉลี่ยของประเทศนั้น ไม่มีการแปลงค่าเงินอยู่ในสมการเลยสักครั้ง:

```
เกาหลี — Blue Archive (เฉลี่ย)       0.94%
ญี่ปุ่น — FGO คุ้มสุด                0.98%
สหรัฐฯ — Genshin                     1.00%
สหรัฐฯ/ญี่ปุ่น — FEH คุ้มสุด          1.08%
เกาหลี — Blue Archive (median)       1.15%
สหรัฐฯ/ญี่ปุ่น — FEH เล็กสุด          1.32%
ญี่ปุ่น — FGO เล็กสุด                1.48%
จีน — Genshin/HSR                    3.36%
จีน — Arknights                      4.20%

ค่าเฉลี่ย 1.72%  ·  มัธยฐาน 1.11%  ·  ช่วง 0.94-4.20%
```

พอแก้ตัวหารเป็นค่าแรงเฉลี่ย **จีนเข้ากลุ่มเดียวกับทุกคนทันที** (3.36-4.20% ไม่ใช่ 12-16%)

**ใช้มัธยฐาน ไม่ใช่ค่าเฉลี่ย** เพราะทนต่อ outlier ฝั่งจีนมากกว่า

**สูตรสำหรับตลาดไทย** (ตัวเลขค่าแรงเป็นข้อมูลสาธารณะ เปลี่ยนตามปี ควรอัปเดตเอง):

```
ค่าแรงเฉลี่ยทั้งประเทศ ฿15,700/เดือน ÷ 21.75 วันทำงาน = ฿721.84/วัน

ราคาต่อ pull = 1.11% × ฿721.84 = ฿8.01
```

**ข้อควรระวังที่ต้องบอกไว้**: ราคา pull ของ FGO/FEH/Blue Archive ที่ใช้เป็นค่าประมาณจากช่วงราคา ไม่ใช่ตัวเลขนิ่งจาก official store ทุกจุด — มัธยฐานทนต่อความคลาดเคลื่อนของจุดเดียวได้ แต่ไม่ใช่ ตัวเลขที่ verify 100%

**revalidate cadence**: ตัวเลขค่าแรงเฉลี่ยข้างบนต้องเช็คใหม่ทุกต้นปี (ไม่ใช่แค่ "ควรอัปเดตเอง" ลอย ๆ)

***

### 6. ตัวอย่างค่าที่ล็อกจริงหนึ่งชุด

> **นี่คือคำตอบของโปรเจกต์หนึ่ง ไม่ใช่คำตอบสากล** — เอาไปดูวิธีคิด อย่าลอกตัวเลข เกมคุณมีโรสเตอร์ ตลาด และโมเดลรายได้คนละแบบ input ต่างกันผลก็ต่างกัน

**band rate — เลือกจุดกึ่งกลางของ corridor ที่วัดได้**

ช่วง exemplar: 0.600% (Genshin/HSR) → 6% (FEH) ⇒ จุดกึ่งกลาง `(0.6 + 6) / 2 = 3.3%`

```
legendary   0.0330000    3.3000 %
epic        0.0886663    8.8666 %
rare        0.2382337   23.8234 %
common      0.6401000   64.0100 %   <- absorber ดูดเศษปัดให้ SUM = 1 พอดี
```

แบ่งแบนด์ล่างแบบ geometric อัตราส่วน `r = 2.686857` ตกลงมาจากสมการ ไม่ได้เลือกเอง

**4 แบนด์ ไม่ใช่ 3** — เพราะโรสเตอร์นี้ตัวหายากยัง "เล่นได้จริง" ไม่ใช่ filler แบบ 3★ weapon ของ Genshin จึงไม่มี "dump tier" ที่โครงสร้าง 3 แบนด์ทุกตัวพึ่งอยู่ (รูปนี้ตาม Arknights)

**pity**

```
P[legendary] = 100      reach = 3.61%    E[cycle] = 29.25 pull
P[epic]      = 10       reach = 43.36%   (floor pity, ตาม I18: 0.30 <= reach <= 0.60)
```

`P = 100` ถูกเลือกเหนือค่าที่ derive ได้ (`P = 80`) เพราะ reach ที่ 100 ต่ำกว่าที่ทุก exemplar พึ่ง pity อยู่ — คือ **ผู้เล่นส่วนใหญ่ได้ของก่อนถึงเพดาน** ซึ่งเป็นเจตนาของ flat rate

**ราคา** (ต่อจาก §5 — สมมติ 1 gem = ฿0.5)

```
c = ฿8.01 ÷ ฿0.5/gem = 16.02  ->  16 gem
cost_multi = ceil(10 × 16 × (1 - 0)) = 160 gem = ฿80.00     [I17, d = 0]
```

**shard ต่อ duplicate — FROZEN โดยตั้งใจ ไม่ derive**

```
common 1  ·  rare 3  ·  epic 7  ·  legendary 19
```

ตอนแรก derive จากอัตราส่วน `r` ตัวเดียวกับที่แบ่งแบนด์ ซึ่งดู "สวย" — แต่แปลว่า **ทุกครั้งที่ re-ratify band rate ในอนาคต เศรษฐกิจ shard ทั้งระบบจะถูก reprice เงียบ ๆ** ทั้งที่เป็นคนละการตัดสินใจ

วัด wobble จริงในช่วง corridor: ค่า `S[legendary]` แกว่งจาก 9.19 ถึง 134.32 (14 เท่า)

เช็ค exemplar: Blue Archive 30/5/1, FGO 90/50/30, Arknights 10/5→15/8 — **ทั้งสามเป็นตารางแบน ที่คนเขียนเอง ไม่มีเกมไหน derive จากสูตร** ⇒ ตัด tie ทิ้ง freeze เป็น base อิสระ

**บทเรียน: "derive ได้" ไม่ได้แปลว่า "ควร derive" — ผูกสองระบบที่เป็นคนละการตัดสินใจเข้าด้วยกัน คือหนี้ ไม่ใช่ความสง่างาม**

**star ladder — uniform 6 duplicate ทุก rarity (★2→★5)**

ดราฟต์แรกใช้ ladder แยกตาม rarity (legendary/epic ★3→★5 ที่ 100/60 shard ต่อขั้น) แล้วคำนวณออกมาว่า **maxed legendary = 909 pull** ซึ่งแพงกว่า FGO NP5 (เกมที่กิน duplicate หนักที่สุดในกลุ่ม) ถึง 3 เท่า

เทียบ exemplar จริง:

```
Genshin C6        ~7 copies    350-540 pull
FGO NP5           ~5 copies    500-567 pull
Arknights Pot6     0 copies    (duplicate เป็น side-grade ไม่ใช่แกนพลัง)
```

รื้อใหม่ด้วย `dup = 6` เท่ากันทุก rarity — เลือก 6 เพราะเป็นค่าเดียวที่หารลงตัวพร้อมกันกับ `S` ทั้ง 4 ค่า ที่ freeze ไว้ (ข้อจำกัดทางคณิตศาสตร์จริงจาก `gcd(3, S)`) ผลลัพธ์:

```
legendary   364 pull    <- อยู่ในช่วง Genshin C6 และต่ำกว่า FGO NP5
epic        203 pull
rare         50 pull
```

**featured share `u = 0` ถาวร**

ไม่ใช่ "ยังไม่ทำ" แต่คือ **จะไม่ทำ** — ไม่มีกลไก featured character ในเกมนี้เลย

เหตุผลไม่ได้มาจาก exemplar (ทุกเกมมี featured) แต่มาจากงานวิจัยเรื่องพฤติกรรม: featured banner ทำงาน ผ่าน **targeted desire** — ผู้เล่นเล็งตัวใดตัวหนึ่ง แล้วกลไก variable-ratio reinforcement (Skinner), near-miss effect, goal-gradient effect ทำงานแรงขึ้นมากเมื่อมีเป้าหมายเฉพาะเจาะจง เอาเป้านั้นออก แรงกดดันก็หายไปด้วย เป็นการตัดสินใจเชิงจริยธรรมของเจ้าของโปรเจกต์ ไม่ใช่ข้อสรุปทางเทคนิค


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://hetcreep.gitbook.io/hetcreep-docs/gacharatedesigndatum/guides/pricing-and-example.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
