ที่มา

แพลตฟอร์ม

• แสดงข้อความหรือภาพเมื่อเดินไปใกล้ช่อง (prompt message)
• กด x เพื่อเปิดสื่อ ได้แก่ โน้ต, เว็บไซต์, วีดีโอ, ภาพ

ถ้ามี role เป็น admin, owner หรือ builder จะทำได้มากกว่านี้ คือเพิ่มสิ่งกีดขวาง และเพิ่มจุดวาร์ปไปช่องอื่น แต่เนื่องจากไม่มี role เหล่านั้นเลยไม่สามารถใช้ลูกเล่นนั้นได้ ทำให้ต้องเปลี่ยนปริศนาข้อนึงที่ให้ผู้เล่นเดินเขาวงกตล่องหน ให้เป็นเดินหาข้อความแทน

มีตะกุกตะกักบ้างตอนวางของในแผนที่ เชคของเป็นครั้งคราวเพราะคนอื่นต้องเข้ามาจัดบูธเวลาเดียวกัน บางทีของที่ตั้งไว้ก็โดนลบไป (แต่เราก็ไปลบของคนอื่นโดยไม่ได้ตั้งใจเหมือนกัน เช่นเรือโจรสลัดลำใหญ่มหึมาของ Siam Board Games ที่น่าจะเผลอลบไป 3 ครั้ง ได้)

ลูกเล่นนึงที่ใช้คือ ประตูเข้ารหัส เป็นลูกเล่นของ gather.town ที่ยังเป็น beta ตั้งค่าวุ่นวายหน่อย แต่ก็ใช้งานได้ ติดปัญหาเล็กน้อยคือประตูจะเปิดค้าง 5 วินาที จึงอาจมีคนหลุดเข้าไปบ้าง แต่ไม่ได้เป็นอะไรที่ซีเรียสนัก

ทำไมกลายเป็นเว็บไปได้?

ในตอนแรกสุดมีการวางแผนให้ผู้เล่นต้องเดินไปหาสตาฟเพื่อตรวจคำตอบ แต่ในเมื่อเราเล่นแบบออนไลน์รูปแบบอยู่แล้ว ถ้ามีหน้าสำหรับตรวจคำตอบให้เลยจะสะดวกกว่า จึงคิดว่าจะใช้แนบลิงก์ Google Sites หรือ Google Forms ให้ใน gather.town เลย แต่ไป ๆ มา ๆ ด้วยความที่เพิ่งได้รู้จักกับ Svelte หมาด ๆ เลยนึกครึ้มทำเป็น web app ซะเลย

ที่จริง มี github project ที่ใช้สร้างเว็บสำหรับ puzzle hunt โดยเฉพาะ ที่ gph-site และได้เคยลอง fork มาทำเล่นจนเสร็จแล้ว แต่ติดตรงที่ต้องให้ผู้เล่นสร้างบัญชีในเว็บ ซึ่งจะวุ่นวายถ้าต้องกรอกข้อมูลนู่นนี่นั่นเพียงเพื่อแก้ปริศนาสั้น ๆ (ที่ลงท้ายดันนานกว่าที่คิด) เลยไม่สามารถใช้ได้ อย่างไรก็ตาม ลูกเล่นหลายอย่างก็หยิบจาก gph-site นี่หละ เอามาเขียนใหม่เอง

ตอนแรก ๆ ก็กะว่าทำเป็นหน้าแยกกัน ตรวจคำตอบแล้วจบ อย่างน้อยสุดก็ให้ผู้เล่นกรอกชื่อและอีเมลหลังเล่นเสร็จ เพื่อส่งให้ทีมงานไปแจกรางวัล แต่นึกสนุกอยากทำให้เหมือน puzzle hunt ที่เคยไปเล่น ก็เลยใส่ลูกเล่นเพิ่ม ไป ๆ มา ๆ กลายเป็น full-stack ไปได้ (...) ถ้ามี login ด้วยนี่คือครบเลย tech ที่ใช้เขียนเว็บได้แก่: Svelte, Sapper, Node.js, PostgresSQL, host บน Heroku ส่วน user interface ใช้ Svelte Material UI

1. ตรวจคำตอบบน server - ตอนแรกว่าจะฝังคำตอบที่เข้ารหัสไว้ใน javascript เลย แต่ด้วยความที่ต้องใช้ server เพื่อทำอย่างอื่นอยู่แล้วเลยตรวจคำตอบบน server ไปเลย ส่วนหนึ่งก็คือกันโกงนั่นแหละ แต่อีกส่วนคือจะได้เก็บข้อมูลอื่น ๆ ได้
2. แสดงคำใบ้ - ในด่าน 1 ให้คำใบ้ตรง ๆ เลย แต่ผู้เล่นสามารถเลือกเปิดได้ ส่วนในด่าน 2 เป็นของซูม ไม่แน่ใจว่าตอนแรกวางแผนอะไรไว้ แต่สุดท้ายก็เลือกให้แสดงเมื่อเปิดปริศนา 20 นาที (30 นาทีสำหรับข้อสุดท้าย)
3. ตารางอักษร - ตอนแรกวางแผนใช้ภาพนิ่ง แต่นึกได้ว่าถ้าทำให้ตารางเป็นปุ่มช่วยทดด้วย น่าจะเล่นสะดวกขึ้นมาก ก็เลยออกมาเป็นอย่างที่เห็น ที่จริงซ่าคิดจะใส่ลูกเล่นแพรวพราว เช่น ทดได้ เปลี่ยนสีได้ แต่กลัวจะไม่ได้ทำอย่างอื่นเลยพับไป
4. บันทึกคำตอบ - ผู้เล่นบางคนไม่ได้เล่นต่อเนื่องตั้งแต่ต้นจนจบ เลยเพิ่มลูกเล่นนี้ขึ้นมา จะได้ไม่ต้องขุดคำตอบเก่า ๆ มาตอบใหม่อีกที นอกจากนั้นทำให้สามารถกันไม่ให้ใช้เครื่องเดียวกันส่งคำตอบซ้ำ ๆ หลายครั้ง เพื่อกรอกอีเมลหลีายคนได้ (แต่ถ้า clear cache เป็นก็ทำได้อยู่ดีแหละ...)
   
   ซึ่งกลายเป็นว่าลูกเล่นสำคัญในด่านที่ 2 เพราะว่าผู้เล่นต้องเดินไปมาระหว่างกระดาน ถ้าต้องทดคำตอบแล้วเดินมาตอบที่กระดานกลางก็จะดูน่าหงุดหงิดมาก เลยเก็บคำตอบไว้ใช่ระหว่างหน้าได้
5. ตารางอันดับ - ตอนแรกไม่ได้คิดถึงขั้นนี้ เพราะรู้ว่าต้องสร้าง database ซึ่งไม่เคยใช้มาก่อนเลย แต่พอคิดขึ้นได้ว่าสุดท้ายต้องเก็บข้อมูลผู้เล่นที่เล่นจบอยู่ดี เลยไปศึกษาและโชคดีที่ทำเสร็จได้ไม่ยากนัก เนื่องจาก heroku มี PostgresSQL เป็น add-on ให้อยู่แล้ว
6. เก็บข้อมูลเวลา และจำนวนครั้งที่ตอบผิด - อธิบายละเอียดด้านล่าง ข้อมูลเหล่านี้จะเป็นประโยชน์มากเวลาออกแบบกิจกรรมปริศนาในภายภาคหน้า ซึ่งส่วนนี้ทำได้ไม่ยากเพราะต้องตรวจคำตอบบน server อยู่แล้ว
7. Discord - ได้ไอเดียมาจาก gph-site ที่แจ้งเตือนใน Discord ทุกครั้งที่มีการส่งคำตอบ เลยลองทำขึ้นมาดูบ้าง เนื่องจากเป็นระบบส่งข้อความอย่างเดียว เลยสามารถใช้ webhook ได้ ไม่ต้องถึงขั้นเขียน bot
   
   ทีแรกก็ว่าจะมาเชคเป็นบางครั้งบางคราว แต่ปรากฏว่าอ่านแล้วสนุก ก็เลยแทบจะเปิดค้างไว้... โดยเฉพาะตอนที่เข้าไปดูคนอื่นเล่นอยู่ ทำให้บางครั้งสามารถเดินเข้าไปบอกคำใบ้ได้เลย (แต่ใจนึงก็กลัวเป็น unsolicited advice ยังไงไม่รู้)
   
   สิ่งนึงที่เพิ่มตอนหลัง ๆ คือ สร้าง alias ให้ทุกคน (เช่น mountain_dew) เวลาอ่านใน Discord จะได้รู้ว่าเป็นคำตอบของใคร โดยไม่ต้องรู้ว่าเป็นใคร
8. ให้คำใบ้เวลาคำตอบใกล้เคียง - ข้อดีของการเล่นบนเว็บคือ สามารถให้คำใบ้ได้ถ้ามาถูกทางแล้วแต่ยังตอบไม่ถูก โดยเฉพาะข้อที่เมื่อแก้ในขั้นแรกแล้วได้วลี ที่ต้องเอาไปทำต่ออีกทีหนึ่ง (ในภาษา puzzle hunt คือ keep going)
   
   สิ่งที่ต่างจาก puzzle hunt ทั่วไปคือ แจ้งให้ผู้เล่นทราบถ้าคำตอบผิดไปเพียง 1 ตัวอักษร ซึ่งในกิจกรรมปริศนาปกติจะไม่ค่อยมีกัน เพราะถ้าผิดแล้วจะผิดแบบไปคนละโลกเลย แต่ด่านที่ 1 มีความแปลกตรงที่ให้หาตำแหน่งของตัวอักษรในตาราง ทำให้บางครั้งผู้เล่นอาจอ่านผิดไปเป็นช่องข้าง ๆ แทน หรือตัวอักษรบางตัวอาจจะยากเกินไป (เช่น มีชู้ = #) ทำให้หาได้ไม่ครบ จึงดูสมเหตสมผลที่จะแจ้งให้ และดีใจที่ผู้เล่นชอบ
   
   จะเห็นว่า ลูกเล่นนี้ใส่ไว้ตอนท้าย ๆ ... ไม่ใช่ว่าไม่สำคัญ แต่เพราะรู้ว่าใช้เวลาไม่นานมาก
9. แชร์ลงโซเชียล - ได้รับแรงบันดาลใจจากปริศนาใน LINE ของค่าย riddler ว่าเวลาเล่นจบแล้วเราอยากแชร์ (=ขิง) ว่าได้อันดับเท่าไหร่ ดีที่มีคนเขียน component ไว้ให้ใช้ได้เลย ไม่ต้องขุด api มาศึกษาเอง (แต่ที่จริงก็อ่านไประดับนึงละ)
10. ให้คะแนนปริศนา - ในเมื่อมี database แล้ว ก็เลยนึกสนุกอยากเก็บข้อมูลให้มากขึ้น เลยใส่ระบบลงคะแนนหลังจากตอบเสร็จแล้ว

• Notification - แจ้งเตือน เตือนอะไร? เตือนให้ทุกคนเห็นว่ามีคนแก้ข้อนี้ได้แล้ว! เนื่องจากใช้ socket.io อยู่แล้วเลยทำได้ไม่ยาก แต่คิดไปคิดมาคนเล่นน่าจะรู้สึกกดดันมากกว่าท้าทาย ก็เลยพับไป เหลือเพียงแค่นับจำนวนคนที่เล่น ณ เวลานั้น
• แก้ snackbar - หลังจากที่ผู้เล่นส่งคำตอบ จะมีข้อความโผล่ด้านล่างว่าถูกหรือไม่ (snackbar) โดยใช้ของ default บน Svelte Material UI แต่พอใช้จริงก็มีปัญหาว่าโผล่สั้นไป ตัวอักษรเล็กไป หรือไปชนกับ interface ของ gather.town แต่ว่าไม่ได้ย้อนกลับมาทำส่วนนี้ เพราะเท่าที่มีอยู่ก็พอใช้ได้แล้ว รอบหน้าต้องหาทางออกใหม่
• Badge - เรามี point แล้ว (นับว่าทำเสร็จไปกี่ข้อ) มี leaderboard แล้ว จะครบสามเกลอ PBL ได้ก็ต้องเพิ่ม badge สิ! แต่พอจะนั่งเขียนโค้ดก็เห็นว่าต้องเก็บข้อมูลเยอะมาก และละเอียดมาก (เช่น badge คนที่คลิกตารางครบ 100 ครั้ง) ก็เลยล้มเลิกไป แต่งานหน้าก็อาจซ่าลองทำดู
• ห้องแชท - ถ้าผู้เล่นที่เล่นพร้อมกันสามารถส่งข้อความหากันได้ทันทีเลย ก็ดูน่าสนุกนะ แต่ต้องกรองแสปม กันสปอยล์ ก็เลยไม่ได้ทำ และในงานจริงก็ค้นพบว่าผู้เล่นส่งข้อความคุยกันใน gather.town กันได้ ก็เลยคิดว่าดีแล้วที่ไม่ไปทำซ้ำซ้อน
• ใส่เสียง - พยายามมาพักนึง อยากให้มีเสียงกระดิ่งเวลาตอบถูกหรือเสียงออดเวลาตอบผิด เพิ่ม immediate feedback แต่ไม่สำเร็จ ทั้ง ๆ ที่เป็น html ปกติซะด้วยซ้ำ รอบหน้าแก้ตัวใหม่

เวลาที่ใช้

เนื่องจากงานนี้จัดเพียง 3 วัน และมีกิจกรรมอื่นในงานให้ร่วมสนุกอีก เลยไม่อยากให้ใช้เวลากับปริศนามากเกินไป จึงได้เก็บข้อมูลว่าผู้เล่นใช้เวลากับปริศนาเท่าไหร่ แต่เป็นการเก็บข้อมูลแบบหยาบ ๆ นั่นคือ จับเวลาเริ่มครั้งเดียวตอนที่เปิดหน้าปริศนาครั้งแรก และนับจนถึงเวลาที่ส่งคำตอบสุดท้ายของด่าน 1 และด่าน 2 จึงมีบางคนที่เปิดวันแรก แต่ได้เริ่มเล่นจริงวันสุดท้าย ทำให้เวลาไม่ตรงกับความเป็นจริง

ครึ่งนึงของผู้เล่นจบด่านที่ 1 ได้ใน 2 ชั่วโมง นานกว่าที่คิดไว้มากกกกกกกก เพราะมี 6 ข้อ แต่ต้องเดินรอบแผนที่ด้วย ก็เลยบอกไม่ได้ว่านานที่ปริศนาเอง หรือนานเพราะหาคำใบ้

และจบด่านที่ 2 ใน 4 ชั่วโมง ถ้าหักด่านแรกก็เหลือ 2 ชั่วโมง ก็คือพอ ๆ กัน (แต่ไม่ต้องเดินรอบแผนที่แล้ว)

โดยรวมนับว่าสนุกสำหรับคนที่ชอบเล่นอยู่แล้ว นั่นคือ 11 ข้อ ข้อละ 20 นาทีแต่ก็นานเกินไปมากโขถ้าเป้าหมายการออกแบบคือบุคคลทั่วไป

แต่ก็จะเห็นได้ว่า มีผู้เล่นจำนวนหนึ่งที่ใช้เวลาถึง 3 ชั่วโมงในด่านที่ 1 และ 6 ชั่วในด่านที่ 2 ส่วนผู้เล่นที่ใช้เวลาถึง 8 ชั่วโมง มีถึง 7 คน ก็ไม่น่าจะใช่เรื่องบังเอิญที่จะเป็นกลุ่มที่ไม่ได้เล่นต่อเนื่องทั้งหมด

จำนวนครั้งที่ตอบผิด

ก่อนจะถึงเป้าหมายก็ต้องมีการล้มลุกคลุกคลานกันบ้าง เลยรวบรวมว่าข้อไหนที่มีคนตอบผิดเยอะสุด โดยวัดจากอัตราส่วนคำตอบที่ผิด และคำตอบที่ถูก

เช่น ในข้อ 1-1 (ปลา) โดยเฉลี่ยแล้วผู้เล่นจะตอบผิด 2 ครั้ง ก่อนจะตอบถูก 1 ครั้ง ส่วนข้อ 2-2 (วงกลม) ผู้เล่นจะตอบผิด 15 ครั้งก่อนจะเจอคำตอบที่ถูก (!!!) ซึ่งนับว่าเยอะมาก

ข้อที่มีคนตอบผิดบ่อยเป็นอันดับ 1 คือ ข้อ 2-2 (Puzzle B) เพราะข้อมูลกระจายหลายจุด เวลาตอบเลยต้องค่อย ๆ ตอบเท่าที่หาได้ แล้วเพิ่มไปเรื่อย ๆ

ข้อที่มีคนตอบผิดมากเป็นอันดับ 2 คือ ข้อ 1-5 (ดาบ) เพราะผู้เล่นมองไม่ออกว่าดาบห่างจากช่องที่ยืนอยู่กี่ช่อง

คะแนนโหวต

คะแนนความสนุกไม่ห่างกันเลย อยู่ 3.5 - 4.5 อันนี้ไม่รู้เหมือนกันว่าทำไมเกาะกลุ่มกัน เพราะโจทย์คล้าย ๆ กัน เพราะความสนุกกะยาก หรือเพราะไม่กล้าโหวตว่าไม่สนุกกันนะ

ข้อที่สนุกสุด กลับเป็น 2-3 (จราจร) ที่ไม่ได้มีอะไรซ่อนไว้เบื้องหลัง

ความเห็น

ประเมินตัวเอง

ด้านของปริศนา

ปริศนาด่านที่ 2 ซูมเป็นคนเขียน โดยได้ไป playtest และแก้บ้าง จึงละไว้ (เว้นแต่ว่าซูมจะเขียนเพิ่ม ก็จะเอามาไว้ตรงนี้) แต่ที่พอจะคอมเมนท์ได้คือ มีการสื่อสารผิดพลาด ในตอนแรกเข้าใจว่าฝั่ง TBS จะทำกราฟฟิคให้ใหม่ แต่สุดท้ายก็ใช้ภาพที่ร่างไว้ ก็เลยเป็นภาพพื้นหลังสีขาวธรรมดา ๆ

ส่วนปริศนาด่านที่ 1 นับว่าทำออกมาได้เป็นที่น่าพอใจตามโจทย์ที่ได้รับมา คือให้เดินทั่วงานเพื่อหาคำใบ้ อย่างคำใบ้ข้อปลาบางจุดที่ถึงกับต้องเดินเข้าไปในบูธถึงจะเห็น และได้ใช้ลูกเล่นของ gather.town พอสมควร (prompt message, blank object)

ที่จริงแล้ว มีเป้าหมายการออกแบบอีกอย่าง คือออกแบบ pure puzzle ที่ใช้แค่คำใบ้ก็หาคำตอบได้ ในการทดสอบตอนแรก (2 คน) คนทดสอบทำได้แม้จะไม่บอกอะไรเลย นอกจากว่าใช้ตาราง 5x5 แต่สำหรับคนทั่วไปก็ท้าทายเกิน อย่างข้อปลา (1-1) ในตอนแรกกะให้หาปลา แล้วสังเกตว่าจำนวนช่องรวมกันได้ 25 ช่อง เต็มตารางพอดี และมีวิธีวางให้ลงทุกช่อง แต่คนทดสอบนึกไม่ถึง สุดท้ายเลยต้องเขียนเป็นคำสั่งว่าให้เอากลุ่มปลามาวางเหมือน tetris ก็เลยต้องล้มพับเป้าหมายนี้ไป

แล้วทำไมถึงไม่เอาคำอธิบายใส่ในแผนที่เลยหละ? เพราะมันจะรกมาก ยิ่งต้องเดินไปมาหาข้อมูล แล้วเดินกลับมาอ่านคำอธิบายอีก ซึ่งถ้าข้อมูลเยอะไปสุดท้ายผู้เล่นก็ต้องจดลงกระดาษอยู่ดี และอาจสงสัย (พลางสาปแช่ง) ว่า แล้วทำไมไม่เขียนออกมาให้เลยในหน้ากระดาษเดียว ก็เลยสรุปได้ออกมาเป็นผลลัพธ์อย่างที่เห็น

ส่วนที่เปลี่ยน หลังจาก draft แรก

• เปลี่ยนคำตอบ - ในตอนแรกใช้คำว่า READ UNDER LETTERS USED TWICE ซึ่งก็ตรงไปตรงมา แต่พบว่าต้องมาหาต่อว่าข้อไหนใช้กี่ตัวอักษร และต้องบอกใบ้ในแผนที่ว่าเป็นคำใบ้ที่เท่าไหร่ ผู้เล่นจะได้รู้ว่าหาครบหรือยัง ทำให้นึกขึ้นได้ว่าที่จริงแล้วก็ทำให้เป็น 5 ตัวอักษรให้หมดเลย จะได้จำง่าย โชคดีที่ปรับคำตอบข้ออื่นได้ไม่ยากมาก เช่น จาก READ เป็น READS จาก LETTERS เป็น CELLS จาก USED เป็น TAKEN แต่ก็ต้องเพิ่มคำแปลให้ จะได้ไม่สับสนเกินไป ส่วนคำตอบสุดท้ายยังเหมือนเดิม
  
  ถามว่าทำไมต้องอ่านข้างล่าง ไม่อ่านในช่องไปเลย? เหตุผลหนึ่งคือจะได้เป็นการบังคับทางอ้อมให้แก้ปริศนาครบ 5 ข้อ เพราะถ้าขาด 1 ข้อ จะขาดตัวอักษร 2 ตัวเลย ทำให้เดายากขึ้น อีกเหตุผลนึงคือ จะได้ขยายให้เป็นคำสั่งที่มี 5 คำ ถ้าเป็นแค่ READS CELLS TAKEN TWICE มันจะขาดไปคำนึง ก็ต้องเพิ่มคำสร้อยไป อย่าง THEN, ONLY, WHICH
• เรียงตำแหน่งให้อ่านจากบนลงล่าง หรือซ้ายไปขวา อย่างใดอย่างหนึ่ง ทำให้ไม่ต้องใบ้ในแผนที่ว่าข้อมูลนี้เป็นตัวอักษรที่เท่าไหร่ เพราะถ้าหาข้อมูลครบแล้วคำตอบจะอ่านได้ชัด
• ทว่าการปรับให้เล่นง่ายขึ้น ก็ต้องแลกมาด้วยการสร้างตารางใหม่หมด และแก้ปริศนาหลายข้อ อย่างข้อ 1-3 (ใบเฟิร์น) ต้องใช้ตัวอักษรในตารางมาสร้างคำใบ้ แม้จะมีเงื่อนไขเต็มไปหมด แต่ก็โชคดีที่สร้างตารางได้แถมใช้เวลาไม่นานนัก แต่กลับมีผลข้างเคียงที่ไม่ตั้งใจคือ ตัวอักษรเดียวกันซ้อนบนล่างกันหลายคู่ ไม่รู้ว่ามาอย่างไรเหมือนกัน
• ข้อปลา (1-1) - จากที่ต้องมาเรียงตัวอักษรเอาเองโดยดูจากขนาดของตัวต่อ (3,4,5,6,7) ให้เป็นการอ่านเรียงจากบนลงล่าง แต่ก็ยังคงออกแบบให้อ่านเรียงจากขนาดได้เช่นเก่า
• ข้อ minesweeper (1-2)- ตอนแรกทำเป็นเขาวงกต แต่พอไม่ได้มี role ใน gather.town เลยสร้างไม่ได้ จึงเปลี่ยนมาเป็น logic puzzle ที่คนส่วนใหญ่รู้จัก โดยยังคงวิธีหาข้อมูลเหมือนเดิม คือการเดินไปบนช่องเปล่า ๆ แล้วมีข้อมูลโผล่ขึ้นมา
• ข้อใบเฟิร์น (1-3) - ให้อ่านจากปลายหนึ่งไปอีกปลายหนึ่ง ตอนแรกผู้เล่นต้องเอาใบเฟิร์นไปไล่ทาบในตารางจนเจอตัวอักษรที่ตรง แต่ผู้ทดสอบบอกว่าสับสนไป และอีกอย่างคือปรับให้ตัวอักษรที่ใช้ตอบอยู่ในคำเลย เพราะในตอนแรกต้องหยิบตัวอักษรอื่นที่วางตรงกับตำแหน่งของไฟที่ติดกับใบเฟิร์น
• ข้อดาบ (1-4) - ปรับจากที่ต้องเอาตัวอักษรมาเรียงใหม่ตามเลข (เช่น 1/7 หมายถึงเป็นตัวอักษรแรก) เป็นอ่านจากบนลงล่าง โดยยังเก็บตัวเลขที่บอกลำดับไว้เหมือนเดิม ส่วนวิธีหาข้อมูลและวิธีอ่านตำแหน่งยังคงเหมือนเดิม
• ข้อวิทยุ (1-5) - ตอนแรกเขียนคำใบ้เป็น
  1. ชี้เมาอีโทวันอังคาร
  2. นางโกหกโอเอกวันพฤหัส
  3. กลางกิ๊กเอจัตวาวันศุกร์
  4. ก้อยฆ่าไอสามัญวันจันทร์
  5. #####
  ผู้เล่นต้องคิดต่อว่า 1) ประโยคแต่ละประโยคแยกออกมาได้เป็น 5 คำ 2) เป้าหมายคือต้องหาคำตอบที่หายไป 3) เวลาอ่านให้อ่านเป็นแถวแนวนอน แต่ตอน playtest ต้องอธิบายอยู่ดีว่าทำอะไร สุดท้ายเลยปรับเป็นแบบที่เห็นในงานคือบอกเลยว่า "แถวที่ 1 - มีชู้ = #" และบอกหมวดหมู่เลยว่าเป็นหมวดอะไร เช่น นิ้ว วัน สระภาษาอังกฤษ เสียงวรรณยุกต์ แต่ก็ดันลืมบอกแถวแรกว่าเป็นศีล ก็เลยทำให้สับสนกัน (ซึ่งกลายเป็นว่าคนส่วนใหญ่คิดไปว่า การมีชู้คือมี 3 คน ทำให้ได้เลขที่ถูกโดยไม่ตั้งใจ)

ด้านการเขียนเว็บ

นับว่าประสบความสำเร็จ เพราะไม่ได้มีเป้าหมายจะมาไกลขนาดนี้ในทีแรก ตอนแรกก็กลัวว่าถ้า server มีปัญหาที่หาวิธีแก้ไม่ได้แล้วจะหายนะ แต่ก็ไม่ได้เกิดปัญหาใหญ่มาก ก็จะมี server ล่มสองครั้ง ซึ่งพอ restart ก็กลับมาเป็นปกติ ถ้าในอนาคตต้องทำโปรเจคใหญ่กว่านี้ มีคนเล่นพร้อมกันหลักพัน (!?!) (ในงานนี้ มีเล่นพร้อมกันสูงสุด 80 คน) ต้องหา solution ที่ดีกว่านี้ อาจจะต้องจ้างคนมาทำจริงจังเลย และอาจต้องจ่ายเงินค่า domain name, host, database, etc.

ด้านผลตอบรับของผู้เล่น

ผู้จัดงานถึงกับบอกว่าปริศนาเป็นตัวชูโรงของงานเลย (!!!)

รอบหน้าอยากเพิ่มอะไร

• อยากใส่โจทย์ที่ต้องเล่นบนเว็บ (เช่น https://2020.galacticpuzzlehunt.com/puzzle/so-you-think-you-can-spell#right) อาจจะเป็นอักษรไขว้ธรรมดาก็ได้
• อยากใส่โจทย์ความรู้ทั่วไป (trivia) ที่เกี่ยวกับบอร์ดเกม เป็นส่วนหนึ่งของปริศนา

ขอบคุณ

• ขอบคุณพี่มิลค์ ผู้จัดงาน Thailand Board Game Show ที่ให้ Code Breaker ได้เป็นส่วนร่วมงานครั้งนี้
• ขอบคุณอิมและธนะ ที่เป็นผู้ทดสอบ draft แรกสุด
• ขอบคุณผู้เล่นกลุ่มแรก ๆ ที่ให้ feedback เรื่องความยากของปริศนา ทำให้สามารถนำไปใช้เพื่อปรับหรือเพิ่มคำใบ้ได้ทันที่ และทำให้คนอื่นที่มาเล่นทีหลังได้เล่นสนุกขึ้น
• ขอบคุณข้อติชม ทั้งจากแบบสอบถามบนเว็บ จากข้อความใน chat บน gather.town และจากการที่ได้พูดคุยโดยตรงใน gather.town เลย ้โดยเฉพาะ https://www.twitch.tv/beaver41 ที่อัดไลฟ์ระหว่างไข เลยกลับมาดูย้อนหลังได้ว่าติดตรงไหน

เก็บตก

• ข้อ 2-3 (จราจร) แทบจะทุกคนจะตอบ CDREAKW ก่อน (คือใส่ครบ 7 ตัว) แล้วตามด้วย CDRAW เพราะคิดว่า 1 เป็นจำนวนเฉพาะ ซึ่งก็ปกติ แต่มีผู้เล่นคนนึงที่คิดว่า 2 ไม่ใช่จำนวนเฉพาะ เลยตอบโดยไม่มีตัว D ทำให้งมอยู่นานมาก
• ในตอนเปิดงาน มีคนเขียน script ส่งคำตอบเป็นตัวอักษร 5 ตัวทั้งหมดที่เป็นไปได้! ถ้าจะไล่คำ 5 ตัวอักษรทั้งหมด จะได้ 26x26x26x26x26 กรณี แต่ด้วยเงื่อนไขที่เพิ่มขึ้นมาว่าต้องอ่านบนลงล่างหรือซ้ายไปขวาได้ เลยเหลือเพียง 2x(5x5x5x5x5) = 6250 กรณี ถ้าส่งคำตอบวินาทีละ 10 ครั้งก็จะใช้เวลาเพียง 10 นาทีก็จะไล่จนครบ
  
  แต่ยังดีที่ server ยังไม่ล่ม และใช้ script แค่ 2 ข้อจาก 5 ข้อ เลยไม่ได้ส่งผลกระทบอะไรต่อคนอื่น เสียดายอย่างคือพอได้คำตอบเสร็จก็ไม่ได้เล่นต่อ .... หรือเปลี่ยนเครื่องก็ไม่รู้เหมือนกัน
• มีคนตั้งสมมติฐานว่า ถ้าเปิดประตูโดยใช้รหัสว่า ENTER ก็น่าจะแก้ปริศนาชิงรางวัลว่า PRIZE นะ (!!!) ไม่แน่ใจว่าสุดท้ายได้ลองจริงมั้ย
• มีคนแอบมาเล่นตอนตี 5 ด้วย! ที่ตลกคือ alias เป็นคำว่า restless night พอดี