สวัสดีครับ/ค่ะ ช่วงนี้ผม/ฉันได้ทำเกมมือถือชื่อ ‘Sumbi’ ขึ้นมาคนเดียว เป็นเกมโร้กไลก์แนวตั้งที่ได้แรงบันดาลใจจากการดำน้ำหาของของแฮนยอแห่งเกาะเชจู เกมนี้คือการลงทะเลด้วยลมหายใจเพียงครั้งเดียว เก็บอาหารทะเล แล้วตัดสินใจว่าจะโลภต่ออีกนิดหรือกลับขึ้นมาตอนนี้เลย
ผม/ฉันเริ่มออกแบบเมื่อวันที่ 2 กรกฎาคม และอัปโหลดบิลด์แรกขึ้น Google Play ในวันที่ 9 กรกฎาคม จากนั้นก็เล่นเองและแก้จุดที่ยังน่าเสียดายต่อเนื่อง จนถึงวันที่ 19 กรกฎาคมก็อัปโหลดบิลด์ v1.1 ขึ้นโปรดักชันแล้ว
สิ่งที่สงสัยมาตั้งแต่แรกไม่ใช่แค่ว่า “AI เขียนโค้ดได้เร็วแค่ไหน” แต่คือถ้าให้ AI หลายโมเดลรับบทต่างกันแล้วทำงานเหมือนทีมพัฒนาทีมเดียวกัน จะสร้างเกมที่พร้อมออกจริงได้ไกลแค่ไหน ผม/ฉันอยากลองทดสอบเรื่องนั้น
เป็นเกมแบบไหน
‘Sumbi’ ได้ชื่อนี้มาจาก ‘เสียงซุมบี’ ซึ่งเป็นเสียงหายใจคล้ายผิวปากที่แฮนยอเป่าออกมาหลังเสร็จจากการดำน้ำและขึ้นสู่ผิวน้ำ
หนึ่งรอบใช้เวลาประมาณ 10–30 วินาที ใช้มือเดียวบังคับแฮนยอให้ดำน้ำลึกลงไปหรือเก็บอาหารทะเลรอบตัว ต้องขึ้นมาแตะผิวน้ำอย่างปลอดภัยจึงจะนำของที่เก็บมาได้ครบ ทำให้ต้องชั่งใจตลอดว่าจะโลภต่ออีกหน่อยหรือกลับขึ้นมาตอนนี้ พอขึ้นมาแล้วก็คิดบัญชีของที่เก็บได้ อัปเกรดความจุปอด ตีนกบ ตะกร้าตาข่าย และสายตา จากนั้นก็ดำลงไปอีกครั้ง
ผม/ฉันใส่ระบบดราฟต์แบบโร้กไลก์ที่ให้เลือก 1 จาก 3 ความสามารถในแต่ละรอบ, สารานุกรมอาหารทะเล 60 ชนิด, อุปกรณ์และสายการเติบโต, การเลื่อนระดับแฮนยอ และหลุมดำน้ำที่ต่อเนื่องลงไปถึง 100 เมตร การควบคุมตั้งใจให้เรียบง่าย แต่ยิ่งดำน้ำซ้ำมากเท่าไร สถิติและบิลด์ที่ผู้เล่นเล็งไว้ก็จะยิ่งต่างกัน
ผม/ฉันไม่ได้ใช้ AI เป็นนักพัฒนาสารพัดประโยชน์คนเดียว
ถ้าให้โมเดลเดียวรับผิดชอบตั้งแต่การออกแบบ การพัฒนา ไปจนถึงการตรวจงานตัวเอง ก็มีโอกาสสูงที่จะยึดสมมติฐานของตัวเองเป็นคำตอบที่ถูกต้องไปเลย ผม/ฉันจึงแบ่งบทบาทแบบนี้
- Fable 5: โครงสร้างเกมและสเปกฟีเจอร์, เป้าหมายสมดุลเศรษฐกิจ, ออกแบบเงื่อนไขความสำเร็จ
- Opus 4.8: พัฒนา Flutter·Flame, เขียนเทสต์, ดีบัก
- Fable 5: เทียบสเปกที่เขียนไว้ตอนแรกกับผลการพัฒนาอีกครั้ง เพื่อตรวจการตกหล่นและ regression
- Codex GPT-5.5: รีวิวโค้ดและส่วนที่เปลี่ยนแปลงอย่างอิสระ พร้อมชี้ edge case
ลำดับงานโดยรวมคือ ออกแบบ → พัฒนา → ผู้วางแผนเดิมตรวจทานซ้ำ → รีวิวโค้ดแบบอิสระ → ทดสอบอัตโนมัติและเล่นจริง
พอได้ลองทำจริงก็พบว่าสิ่งที่สำคัญกว่าการเขียนพรอมป์ให้ดูดี คือการกำหนดเงื่อนไขความสำเร็จที่ตรวจสอบได้ไว้ก่อน แทนที่จะบอกว่า “ทำให้ความรู้สึกเติบโตดีขึ้น” ผม/ฉันกำหนดเป็นตัวเลข เช่น จำนวนครั้งที่ซื้อได้ใน 10 นาทีแรก เวลาที่ใช้จนเลื่อนระดับครั้งแรก และในแต่ละช่วงการเติบโตมีช่วงที่ยาวเกินไปหรือไม่ซึ่งผู้เล่นซื้ออะไรไม่ได้เลย จากนั้นค่อยตรวจด้วยตัวจำลองเศรษฐกิจและเทสต์
ตอนนี้มีเทสต์อัตโนมัติ 627 รายการ และผ่านทั้งหมด การวิเคราะห์แบบ static ของ Flutter ก็ผ่านโดยไม่มีข้อผิดพลาดทั้งในส่วนโค้ดแอป เทสต์ และเครื่องมือ
ตัวอย่างที่ AI พลาดแบบดูเหมือนจะถูก
การออกแบบครั้งแรกไม่ได้กลายเป็นเกมที่สนุกทันที
เวอร์ชันแรก ๆ มีเป้าหมายให้ขุดเก็บได้ต่อรอบเพียง 5–9 ชิ้นเท่านั้น ทั้งที่เป็นเกมเก็บของ แต่ทะเลกลับดูโล่ง ผม/ฉันลองเล่นเองแล้วตัดโครงสร้างนี้ทิ้งไป เปลี่ยนให้ยิ่งเติบโต ฟิลด์ยิ่งอุดมสมบูรณ์ และตำแหน่งที่เก็บไปแล้วก็มีอาหารทะเลงอกขึ้นมาใหม่ ในบางบิลด์การเติบโต สามารถเก็บได้ราว 40 ชิ้นต่อรอบ
สายการเติบโตก็คล้ายกัน มีโหนดถึง 290 โหนด แต่การเล่นจริงกลับเกือบเป็นเส้นตรง AI ทำได้ตามข้อกำหนดเรื่อง “290 โหนด” แต่ไม่ได้สร้างความสนุกจากการเลือกมาด้วย สุดท้ายผม/ฉันจึงแยกโครงสร้างใหม่เป็น 3 เส้นทางเฉพาะทางและโหนดถาวร
AI สร้างโค้ดจำนวนมากได้อย่างรวดเร็ว แต่ไม่ได้รับประกันทั้งความสนุกและลำดับความสำคัญ การเล่นเองแล้วพูดให้ชัดว่า “อันนี้ไม่สนุก” หรือ “ฟีเจอร์เยอะ แต่ไม่เห็นเป้าหมายถัดไป” ยังเป็นหน้าที่ของมนุษย์อยู่ดี
ผม/ฉันสร้างไปป์ไลน์ภาพและเสียงเองด้วย
แอสเซ็ตภาพหลักอย่างตัวละครแฮนยอ อาหารทะเล อุปกรณ์ และไอคอนการ์ด ผม/ฉันสร้างด้วย GPT image generation API ไม่ได้นำชีตที่สร้างมาใช้ตรง ๆ แต่เอาเข้าไปในไปป์ไลน์ปรับแต่งที่มีทั้งการลบ chroma key, จัดแนวเฟรม, ทำขนาดให้เท่ากัน และ pixel quantization แล้วค่อยตรวจอีกที ส่วนฉากหลัง ฟองอากาศ และลำแสง ส่วนใหญ่ใช้การวาดด้วยโค้ด
ด้านเสียง แทนที่จะรวบรวมแอสเซ็ตจากภายนอก ผม/ฉันสังเคราะห์ WAV ด้วยโค้ด Dart โดยตรง เสียงซุมบีที่ได้ยินตอนจบการดำน้ำถูกตั้งให้เป็นเสียงสำคัญที่เชื่อมชื่อเกมเข้ากับตอนจบของหนึ่งรอบการเล่น
มุมมองที่เปลี่ยนไปหลังจากได้สร้างมันขึ้นมา
คนมักพูดกันว่า “ถ้าสั่ง AI เก่ง มันก็ทำได้ดี” แต่ครั้งนี้สิ่งที่ผม/ฉันได้เรียนรู้มากกว่านั้นคือ “ต้องมีโครงสร้างที่จับผิดได้เมื่อมันพลาด”
ผม/ฉันแยกบทบาทผู้ออกแบบ ผู้พัฒนา และผู้ตรวจงานออกจากกัน แล้วให้โมเดลต่างตัวเข้ามาตรวจแผนและโค้ดแบบเข้มข้น การตัดสินขั้นสุดท้ายให้เป็นหน้าที่ของตัวเลข เทสต์ และการเล่นจริง วิธีนี้เสถียรกว่าการคุยยาวกับโมเดลเดียวแล้วให้มันรับผิดชอบทุกอย่างมาก
แม้ AI จะเร็วขึ้น คอขวดของการพัฒนาเกมคนเดียวก็ไม่ได้หายไป เพียงแต่ตำแหน่งของคอขวดเปลี่ยนจากการเขียนโค้ดไปเป็นการตัดสินใจ อะไรควรเก็บ อะไรควรทิ้ง และทำไมตอนนี้มันยังไม่สนุก คือเรื่องที่ใช้เวลานานที่สุด
Google Play
https://play.google.com/store/apps/details?id=com.kinderia.sumbi
เกมนี้ยังเป็นเกมที่ผม/ฉันทำคนเดียว เลยยังมีจุดที่ขาดอยู่มาก อยากฟังความเห็นว่ามันไม่สนุกหรือเปล่า หรือเมนูการเติบโตซับซ้อนเกินไปไหม ถ้ามีคำถามเรื่องวิธีพัฒนาหรือการแบ่งบทบาทของแต่ละโมเดล ก็ฝากไว้ได้สบาย ๆ
ยังไม่มีความคิดเห็น