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

ลองสร้างเว็บเกมด้วยคอนเซปต์ที่รวบรวมรายการฟีดแบ็กจากผู้ใช้แล้วนำไปปล่อยอัปเดตในวันถัดไป
เป็นโปรเจ็กต์ที่ทำขึ้นเพื่อให้คุ้นเคยกับเครื่องมือ AI และเปิด GitHub ไว้แล้ว ลองเข้าไปดูได้ตามสบาย
game: https://spiralwave.frogred8.dev
github: https://github.com/frogred8/SpiralWave

• ภาพรวมและการวางแผนโปรเจ็กต์
  • แรงจูงใจและเป้าหมาย: ทดลอง vibe coding โดยใช้เครื่องมือ AI ที่พัฒนาขึ้นมากแล้วอย่าง Gemini เป็นต้น และลองพัฒนาเว็บเกมด้วยเทคโนโลยีที่ยังไม่เคยใช้
  • ทิศทางการพัฒนา: ตัดสินใจทำมินิเกมเว็บแบบ 'เก็บทรัพยากรตามเวลาจำกัด' ที่สะท้อนความคิดเห็นผู้ใช้แบบอัตโนมัติทุกวัน
• การสร้างต้นแบบเริ่มต้น
  • คอนเซปต์หลัก: เกมเก็บทรัพยากรและจัดสกิลทรีที่ไม่มีการแข่งขันหรือการสูญเสีย
  • การใช้ AI: แปลงภาพสเก็ตช์บนกระดาษเป็นพรอมป์ต์ แล้วสร้างโครงสร้างเกมพื้นฐานบน TypeScript, Vite, Phaser ได้ภายใน 30 นาที
• ข้อจำกัดของการทำ logic ที่ซับซ้อนและการแก้เองโดยตรง
  • การพัฒนาสกิลทรี: logic สกิลเงื่อนไขก่อนหน้าแบบพื้นฐานให้ AI ทำได้ แต่ logic ที่ซับซ้อนอย่างการยกเลิกโหนดกลางแล้วทำให้โหนดลูกถูกยกเลิกต่อเนื่องกันนั้น AI แก้ไม่ได้ จึงลงมือทำเอง
  • การข้าม test code: เนื่องจากมีการเปลี่ยนดีไซน์บ่อยและต้องการพัฒนาอย่างรวดเร็ว จึงตั้งใจเดินหน้าต่อโดยไม่เขียน test code
• การรีแฟกเตอร์ครั้งใหญ่และลักษณะเฉพาะของการดีบักด้วย AI
  • งานแยก UI: เพราะไฟล์เดียวเริ่มใหญ่เกินไปจึงแยกโค้ด UI ออกมา แต่ความสม่ำเสมอและความพึงพอใจด้านโครงสร้างยังต่ำ และยืนยันได้ว่าวิธีเสริมพรอมป์ต์แล้วค่อยทำงานใหม่เหมาะกับงานขนาดใหญ่
  • บั๊กเรื่องลำดับการทำงาน: สำหรับ runtime error หลังรีแฟกเตอร์ที่เกิดจากลำดับการอัปเดตสถานะกับการแสดง UI สลับกัน AI กลับใส่แต่ guard code แบบพร่ำเพรื่อ สุดท้ายมนุษย์นักพัฒนาต้องไล่ดู flow แล้วแก้โค้ดเพียงสองบรรทัดก็จบอย่างง่ายดาย
  • ความผิดพลาดของ AI ดูมีความเป็นมนุษย์พอสมควร จนให้ความรู้สึกแปลก ๆ
• การใช้ Git auto-commit และการนำไกด์มาใช้
  • การจัดทำไกด์พรอมป์ต์: เพื่อลดความยุ่งยากจากการสั่งซ้ำ ๆ จึงนำไฟล์แนวทาง (GEMINI.md) ที่สรุป tech stack และวิธีการทำงานมาใช้
  • workflow อัตโนมัติ: ตั้งค่าให้หลังทำงานโค้ดเสร็จ ระบบสร้าง commit message อัตโนมัติที่มีเวลาใช้งานของเอเจนต์, พรอมป์ต์คำสั่ง และสรุปงาน เพื่อช่วยลดภาระการรีวิวแบบง่าย ๆ
• การออกแบบสถาปัตยกรรมอัปเดตอัตโนมัติและการปรับให้เหมาะสม
  • การเปลี่ยนวิธี deploy: เดิมวางแผนจะปล่อยอัตโนมัติแบบเรียลไทม์ทุก 2 ชั่วโมง แต่เพราะอัตราเกิด runtime bug สูงราว 25% ทำให้ความเสถียรของบิลด์ต่ำ จึงเลิกแนวทางนั้นและเปลี่ยนเป็นสร้าง/ปล่อย daily test build แยกต่างหาก
  • Cron workflow: ใช้ node:cron สร้างกระบวนการอัตโนมัติแบบ monolithic ตั้งแต่ 'รวบรวมฟีดแบ็ก → คัดกรอง → สร้างโค้ด → สร้างบิลด์และรีลีส → deploy'
  • การอัปเดต release note: แชร์ไฟล์รายชื่อเซิร์ฟเวอร์ระหว่าง Docker instance ผ่าน common volume และใช้แคชหมดอายุ 5 นาทีเพื่อควบคุมภาระโหลด อีกทั้งยังทำให้สามารถแสดง release note โดยนำคำขอหลายภาษาของผู้ใช้มาปรับเป็นภาษาอังกฤษก่อนแล้วค่อยแปลกลับอีกครั้ง
• ฟีเจอร์ที่ถูกตัดออกระหว่างการพัฒนา
  • ฟังก์ชันแนะนำความคิดเห็นบน leaderboard (Like) (ไม่มีตัวระบุและมีภาระค่าใช้จ่ายจาก API call)
  • เครื่องมือจัดการข้อมูลสกิลแบบละเอียด (ติดข้อจำกัดด้านจินตนาการและแก้ JSON ตรง ๆ มีประสิทธิภาพกว่า)
  • การสร้างสภาพแวดล้อม Docker แบบกระจายตามแต่ละบริการ (เพื่อให้การปฏิบัติการและการจัดการซับซ้อนน้อยที่สุดจึงรวมเป็น image เดียว)
  • ฟังก์ชันแจ้งเตือนทางอีเมลเมื่อมีการนำความคิดเห็นผู้ใช้ไปใช้ (ความน่าเชื่อถือของการเก็บอีเมลโดยไม่สมัครสมาชิกและความเสี่ยงการสวมรอย)
  • การเพิ่มโฆษณาด้านข้าง (ขั้นตอนอนุมัติของแพลตฟอร์มที่น่าเหนื่อยล้าและผลตอบแทนต่ำเมื่อเทียบกับราคาต่อหน่วย)
• ความเห็นหลังพัฒนาด้วย AI
  • trade-off ระหว่างประสิทธิภาพการผลิตกับการทดสอบ: ความเร็วในการลงมือพัฒนาเพิ่มขึ้นราว 10 เท่า แต่ก็เจอข้อจำกัดที่เวลาและความเหนื่อยล้าจากการตรวจสอบ (QA) เพิ่มขึ้นตามสัดส่วน
  • ลักษณะของคุณภาพโค้ด: ความสมบูรณ์ในระดับฟังก์ชันสูง แต่ความอ่านง่ายต่ำจนมองภาพรวม flow ได้ยาก และยังพบแนวโน้มที่จะใส่แพตเทิร์นการ generalize ที่ใหญ่เกินความจำเป็น แม้ในสถานการณ์ที่การ hard-code เฉพาะจุดจะเหมาะกว่า

[recast7838]

น่าสนุกดีนะ