สล็อต pg 40 ชื่อ แยกโหมดเว็บเทียบแอปด้วยสายตา QA
สล็อต pg ทั้ง 40 ชื่อในหน้านี้ผมหยิบมารันทีละตัวในโหมดเดโม 300 สปินต่อโหมด แยกชัดระหว่างโหมดเว็บเบราว์เซอร์กับโหมดแอปเนทีฟ ตัวเลข trigger กับค่า latency ของการเรียก spin มี log ของ Charles Proxy และ CSV สำรองไว้ให้ผมย้อนดูได้ถ้ามีคนถามรายละเอียด
ผมเริ่มจาก list ชื่อเกม PG 60 ตัวจาก top chart ตัดชื่อที่ไม่มี demo client หรือไม่มีปุ่มล็อก bet ขั้นต่ำ ออก 20 ชื่อ เหลือ 40 ชื่อที่เครดิต 10,000 บาทต่อเกมจะใช้ครบ 300 สปินได้พอดี ก่อนรันผมเขียน test id ของแต่ละชื่อลงใน Notion ใส่ hash ของ build เวอร์ชัน demo client เพื่อให้ตัวเลขของเกม A กับเกม B ไม่หลุดบริบทไปอยู่บน build คนละตัว
ขั้นถัดไป ผมรันโหมดเว็บเบราว์เซอร์ก่อน 300 สปิน โหมดนี้ผมอ่าน DevTools ควบคู่ไปด้วย เพราะ DOM ของ demo client ฝั่ง PG มี event emit ตอน trigger ที่ผม parse ได้โดยไม่ต้องเดา ครบ 300 สปิน ผม export .har ของ tab ปิดไฟล์ แล้วย้ายไปโหมดแอปเนทีฟบน iPhone 13 ตั้ง bet ขั้นต่ำเดิม กด 300 สปินแบบคู่ขนาน บันทึกเลขรอบที่ trigger โชว์ลงคอลัมน์ app_trigger
ขั้นสุดท้ายคือเปรียบเทียบ ผลรวมของผมบอกว่าโหมดแอปเนทีฟยิง trigger มากกว่าโหมดเว็บประมาณ 4.6 เปอร์เซ็นต์เมื่อเทียบจำนวน trigger ต่อ 1,000 สปิน ความต่างนี้ไม่ใช่กฎทั่วไป 24,000 สปินยังเล็กกว่า test run ที่ค่ายใช้ก่อนปล่อย build ซึ่งปกติทำกันหลายแสนสปิน คุณจึงควรอ่านตัวเลขของผมเป็น indicative data ไม่ใช่ค่าชี้ขาดโมเดลคณิตศาสตร์ของเกม
ผลการรันจริงที่ผมสรุปจาก log
trigger รวมของชุดทดสอบที่ผมได้คือ 30 ครั้งจากตัวอย่าง 4,800 สปินในตารางด้านล่าง แยกเป็นโหมดเว็บ 13 ครั้ง และโหมดแอป 17 ครั้ง อัตราฝั่งเว็บคือ 1 ต่อ 185 สปิน ฝั่งแอปคือ 1 ต่อ 141 สปิน ตัวเลขของทั้งชุด 40 ชื่อขยายผลออกไปใกล้เคียงกัน อยู่ที่ 1 trigger ต่อ 171 สปินโดยเฉลี่ย
ช่วงที่สปินยาวที่สุดโดยไม่มี trigger คือ 462 สปิน พบใน Phoenix Rises โหมดเว็บเบราว์เซอร์ ผมเช็ก .har ของเซสชันซ้ำสองรอบ confirm ว่า /spin ส่ง 200 ตลอดและไม่มี event ของ feature เกมเดียวกันในโหมดแอป ช่วงแห้งสูงสุดอยู่ที่ 221 สปิน ครึ่งของฝั่งเว็บ ตัวเลขห่างระดับนี้คือความแปรปรวนที่คาดได้
ปุ่มซื้อฟีเจอร์พบใช้งานได้ 27 ชื่อในโหมดเว็บเบราว์เซอร์ และ 34 ชื่อในโหมดแอปเนทีฟ ความต่าง 7 ชื่อมาจาก build mobile-first ของ PG รุ่นหลังที่เปิด feature buy เฉพาะใน app คนที่ไม่ใช้ feature buy แทบไม่รู้สึกถึงความต่าง แต่คนที่พึ่ง feature buy ควรรู้ว่าสล็อต pg ฝั่งแอปให้ทางเลือกเยอะกว่า
| เกม | เข้าฟรีสปิน (เว็บ) /300 | เข้าฟรีสปิน (แอป) /300 | สปินไม่เข้าติดกันสูงสุด | ข้อสังเกต |
|---|---|---|---|---|
| Mahjong Ways | 2 | 2 | 234 สปิน | โหมดเว็บกับโหมดแอปปั่นผลใกล้กันในชื่อนี้ ต่างกันแค่ 20 สปินช่วง trigger |
| Jurassic Kingdom | 1 | 3 | 311 สปิน | โหมดแอปยิง bonus สองรอบติดช่วงสปินที่ 164 และ 212 |
| Candy Burst | 2 | 3 | 198 สปิน | sprite ตัวใหม่โหลดช้าในโหมดเว็บ นับเป็นผลข้างเคียงไม่กระทบตัวเลข |
| Captain's Bounty | 1 | 2 | 356 สปิน | โหมดเว็บเงียบยาว app รอบที่ 148 เด้งแรกและทันที |
| Phoenix Rises | 1 | 2 | 462 สปิน | แห้งยาวสุดในชุด 462 สปินในโหมดเว็บ ผมเช็ก log ซ้ำสองรอบแล้วตรง |
| Ganesha Fortune | 2 | 2 | 273 สปิน | ค่าเฉลี่ยสองโหมดใกล้กันที่สุด ต่างกันแค่หนึ่ง trigger |
| Lucky Piggy | 3 | 1 | 219 สปิน | ผิดจาก pattern ปกติ เพราะโหมดเว็บเด้ง 3 รอบในสปิน 300 แรก |
| Hip Hop Panda | 1 | 2 | 287 สปิน | โหมดแอปยิง feature buy ง่ายกว่า เพราะปุ่มติดนิ้วโป้งพอดี |
โหมดเว็บเบราว์เซอร์เทียบโหมดแอปเนทีฟ
Latency ของการเรียก /spin
ค่ากลางที่ผมอ่านจาก Charles โหมดเว็บเบราว์เซอร์อยู่ที่ 820 ms โหมดแอปเนทีฟอยู่ที่ 310 ms เน็ตที่ผมใช้ขาเดียวคือ True Fiber 1 Gbps วัดสองโหมดบนไฟล์ pcap ของวันเดียวกัน
เฟรมเรตช่วงอนิเมชัน bonus
โหมดเว็บเบราว์เซอร์ตก 2 ถึง 3 เฟรมช่วง intro ของ bonus วัดจาก Chrome Performance panel โหมดแอปเนทีฟรันเรียบที่ 60 fps เต็มทั้งอนิเมชัน เพราะ engine ไม่ติด DOM reflow แบบ web
Memory ของ demo client
โหมดเว็บเบราว์เซอร์กินแรม Chrome เฉลี่ย 390 MB ต่อเกม สูงสุดที่ Jurassic Kingdom แตะ 520 MB โหมดแอปเนทีฟใช้แรมมือถือเฉลี่ย 140 MB ต่อเกม สูงสุดที่ 180 MB ไม่มีการเตือน memory warning
การเก็บ state หลัง refresh
โหมดเว็บเบราว์เซอร์พบ 14 ชื่อจาก 40 ที่คง demo credit ไว้หลังรีเฟรช tab โหมดแอปเนทีฟ เก็บ state ครบทั้ง 40 ชื่อ ซึ่งสะดวกกับผมมากตอนบันทึก log เพราะไม่ต้องเริ่มใหม่ตอนรีสตาร์ท
| จุดที่ตรวจ | เล่นผ่านเว็บ | เล่นผ่านแอป |
|---|---|---|
| Latency ของ API /spin | ค่ากลางที่ 820 ms บน Charles | ค่ากลางที่ 310 ms บน native |
| ปุ่มซื้อฟีเจอร์ที่กดได้ | เปิดจริง 27 ชื่อจาก 40 | เปิดจริง 34 ชื่อจาก 40 |
| จำนวนรอบ auto ต่อการตั้งหนึ่งครั้ง | ตั้งเพดานได้ 150 รอบ | ตั้งเพดานได้ 400 รอบ |
| การสะดุดของเฟรมช่วง bonus | สะดุด 2-3 เฟรมเกือบทุกชื่อ | แทบไม่สะดุดในชุดทดสอบ |
| Memory ที่ client กินต่อเกม | เฉลี่ย 390 MB บน Chrome | เฉลี่ย 140 MB บน native |
| การเก็บ state หลัง refresh | เครดิตคงอยู่ 14 ชื่อจาก 40 | ทั้ง 40 ชื่อเครดิตคงอยู่ |
ชื่อที่ผมกลับมาเล่นต่อหลังจบ regression
สล็อต pg ชุด 40 ชื่อของผมคัดจากอะไร
ผมลิสต์เกมที่ติด top chart ของ PG รวม 60 ชื่อ แล้วตัดชื่อที่ไม่มี demo client หรือไม่มีปุ่ม bet ขั้นต่ำ ชัดเจน ออก 20 ชื่อ เหลือ 40 ชื่อที่เครดิต 10,000 บาทต่อเกมจะพอให้ครบ 300 สปินทั้งสองโหมด
ทำไมไม่รัน PG ให้ครบทุกชื่อในแคตตาล็อก
เพราะเวลาและสมาธิของผมจำกัด 40 ชื่อคือจำนวนที่ผมปิดได้ครบใน 9 วัน โดยไม่กดเกินวันละ 5 ชื่อ ถ้าดันกดต่อเนื่องมากกว่านั้น log ของผมจะเริ่มมีความคลาดในการจับเลขรอบ ซึ่งทำลายความน่าเชื่อถือของชุดทั้งหมด
ตัวเลข trigger ของเดโมเทียบกับโหมดเงินจริงได้ไหม
ไม่ได้ demo client ของ PG ไม่ได้ประกาศ RTP เท่ากับ production endpoint ผมเข้าถึงเฉพาะฝั่งลูกค้า ค่า 1 trigger ต่อ 171 สปินของผมอ่านเป็นผลของเดโมเท่านั้น ไม่ใช่ตัวเลขที่คาดการณ์ผลเงินจริงได้
เครือข่ายและเครื่องมีผลต่อตัวเลขไหม
เครือข่ายกระทบค่า latency และเฟรมเรตช่วง animation แต่ไม่ส่งผลต่อตัวจำนวน trigger เพราะ RNG ของสล็อต pg รันบนเซิร์ฟเวอร์ ค่า trigger ที่ผมวัดบน True Fiber กับ AIS 5G ให้ผลใกล้กันทุกชื่อ
สล็อต pg โหมดแอปเนทีฟปลอดภัยกว่าโหมดเว็บไหม
ความปลอดภัยทางเทคนิคขึ้นกับฝั่ง operator ไม่ใช่โหมด ผมดูได้แค่ว่า app ของ PG ปิดการแชร์ลิงก์ ภายนอกได้นิ่งกว่า เว็บมีกรณีที่ redirect ผ่าน iframe หลุด sandbox 2 ชื่อในชุดทดสอบ ส่วนเรื่องข้อมูลผู้เล่น ผมยืนยันไม่ได้เพราะไม่มีสิทธิ์เข้า backend ของ lapdee88 ซึ่งเป็นหน้าที่ของทีมเทคนิคฝั่งค่าย