สร้างเกมใช้เวลา 3 เดือนถ้าไม่มี LLM แต่ถ้ามี LLM ใช้แค่ 3 วัน

• วิศวกรซอฟต์แวร์ที่มีประสบการณ์ 15 ปี แชร์ประสบการณ์ พัฒนาเกมไพ่จากวัยเด็กด้วยภาษา Go
• ตอนพัฒนา “Truco” โดยไม่มี LLM (Large Language Model) ต้องแก้ทุกปัญหาด้วยตนเองทั้งหมด ไม่ว่าจะเป็น การออกแบบ UI และการดีพลอยแบบ serverless จนใช้เวลา 3 เดือน
• ตอนทำ “Escoba” ใช้ LLM ช่วย แปลงโค้ดแบ็กเอนด์และเร่งความเร็วในการพัฒนา อย่างมาก โดย พรอมป์ครั้งเดียวก็ใช้งานได้เกือบทั้งหมด
• ช่วงท้ายของบทความมี ตัวอย่าง Tic-Tac-Toe พร้อมไกด์แบบ ทีละขั้นตอน สำหรับสร้างเกมด้วย Go backend, การแปลงเป็น WASM และการเชื่อมกับ React เพื่อให้ใครก็เริ่มทำเกมเองได้
• แต่ ฟรอนต์เอนด์ React และการจัดการสถานะเกมบน WASM ก็ยังต้องดีบักและลงมือทำเองอยู่ดี

---

บทนำ

• วิศวกรซอฟต์แวร์ที่มีประสบการณ์ 15 ปีตระหนักว่าตัวเองยังไม่เคยสร้างและเผยแพร่เกมจริง ๆ มาก่อน
• จึงตัดสินใจพัฒนาเกมไพ่เกมหนึ่งที่เคยเล่นกับเพื่อน ๆ ในอาร์เจนตินาตอนเด็กด้วยภาษา Go

Truco: 3 เดือนโดยไม่มี LLM

• เริ่มพัฒนาเกมไพ่ชื่อ Truco ตั้งแต่วันที่ 18 มิถุนายน 2024 โดยใช้ Go backend และเขียนฟรอนต์เอนด์ด้วยความรู้ React เพียงเล็กน้อย
• ความท้าทายใหญ่ที่สุดคือ การทำ UI และเพื่อหลีกเลี่ยงการต้องมีเซิร์ฟเวอร์ จึงใช้ TinyGo เพื่อ transpile เป็น WASM (WebAssembly) แล้วนำไฟล์ static ไปดีพลอยบน GitHub Pages
• ในช่วงที่ยังไม่มี LLM ผู้เขียนต้องค้นหารายละเอียดทุกอย่างเองและลองผิดลองถูกอยู่ตลอด จนใช้เวลาราว 3 เดือนกว่าจะเสร็จ
• ไม่มีเป้าหมายด้านโฆษณาหรือรายได้ แค่ต้องการทำเกมนี้ให้เสร็จ และแม้จะเปิดตัวมาแล้ว 1 ปี ก็ยังมีคนเล่นอย่างต่อเนื่อง
  • เล่น Truco: https://marianogappa.github.io/truco-argentino
  • แบ็กเอนด์ (Golang): https://github.com/marianogappa/truco
  • ฟรอนต์เอนด์ (React): https://github.com/marianogappa/truco-argentino

Escoba: 3 วันเมื่อมี LLM

• หนึ่งปีต่อมา ระหว่างเดินทางไปอาร์เจนตินาเพื่อเยี่ยมครอบครัว เขาได้สอนหลานเล่นเกมไพ่ยอดนิยมอันดับสองชื่อ Escoba
• ครั้งนี้เขาใช้ LLM (Claude) โดยคัดลอกแบ็กเอนด์ของ Truco มาก่อน จากนั้นอธิบายกติกาของ Escoba ผ่านพรอมป์และขอให้รีแฟกเตอร์โค้ด
• แค่พรอมป์แรกก็ได้ผลลัพธ์ที่เกือบสมบูรณ์แล้ว เหลือเพียงบั๊กเล็กน้อยและฟีเจอร์เสริมบางส่วนที่ต้องแก้ด้วยมือ
• ส่วนฟรอนต์เอนด์ยังต้องลงมือทำและดีบักเองอีกหลายวัน ข้อจำกัดของ LLM, ทักษะ React และสภาพแวดล้อมที่ค่อนข้างแปลกซึ่งให้ WASM เป็นตัวจัดการสถานะเกม ล้วนเป็นความท้าทาย
  • เล่น Escoba: https://marianogappa.github.io/escoba-de-15
  • แบ็กเอนด์ (Golang): https://github.com/marianogappa/escoba
  • ฟรอนต์เอนด์ (React): https://github.com/marianogappa/escoba-de-15

ทีละขั้นตอน: วิธีสร้างเกมของตัวเอง

• ผู้เขียนแนะนำ ไกด์ภาคปฏิบัติขั้นต่ำและโค้ดตัวอย่าง เพื่อให้คนอื่นลองพัฒนาเกมด้วยตัวเองได้
• มีรีโพซิทอรีตัวอย่าง Tic-Tac-Toe ให้ fork ไปเริ่มต้นได้ทันที
  • แบ็กเอนด์: https://github.com/marianogappa/tictactoe-backend
  • ฟรอนต์เอนด์: https://github.com/marianogappa/tictactoe-frontend
  • เดโม: https://marianogappa.github.io/tictactoe-frontend/

การพัฒนาแบ็กเอนด์

• แบ็กเอนด์แบบ turn-based สามารถออกแบบฟังก์ชันการทำงานได้อย่างชัดเจน
• หากต้องการคงโครงสร้างแบบ serverless ไว้ การหลีกเลี่ยงรูปแบบที่ผู้เล่นหลายคนต้องเล่นกันแบบคนต่อคนถือเป็นทางเลือกที่สมจริง หากไม่มีเซิร์ฟเวอร์เชิงพาณิชย์รองรับ

การพัฒนาฟรอนต์เอนด์

• ฟรอนต์เอนด์ต้องรองรับงานต่อไปนี้
  • ขอสร้าง GameState ใหม่จากแบ็กเอนด์
  • แสดงสถานะบน UI
  • มีอินเทอร์เฟซให้เลือกการกระทำที่ถูกต้อง
  • เมื่อมีการกระทำ ให้ส่งคำสั่งไปยังแบ็กเอนด์
  • หากถึงตาของบอท ให้ร้องขอไปยังแบ็กเอนด์

การแปลงแบ็กเอนด์เป็น WASM

• หากต้องการ build โค้ด Go ให้เป็น WASM ให้ใช้ GOARCH=wasm GOOS=js go build
• อาจมีปัญหาเรื่องขนาดไบนารีที่ใหญ่ จึงใช้ TinyGo เพื่อลดขนาด
• เพื่อ export ฟังก์ชันที่จะเชื่อมกับฟรอนต์เอนด์ ต้องเขียน entry point แยกใน Go (เช่น main_wasm.go) แล้วแยกการ build ตามกรณี
• ในฟังก์ชันหลักต้องบล็อกด้วย select {} เพื่อไม่ให้โปรแกรมจบทันที

การเชื่อมข้อมูลระหว่างแบ็กเอนด์กับฟรอนต์เอนด์

• struct แบบยืดหยุ่นของ Go อย่าง GameState ไม่สามารถ serialize/deserialize จาก WASM ได้โดยตรง
• จึงจำเป็นต้อง แลกเปลี่ยนข้อมูลทั้งหมดในรูปแบบ JSON
• โดยอ้างอิงเอกสารของ TinyGo ทั้งอินพุตและเอาต์พุตจะต้องส่งผ่านการ serialize เป็น JSON

อินเทอร์เฟซระหว่างฟรอนต์เอนด์กับแบ็กเอนด์

• ฝั่งฟรอนต์เอนด์จะเรียกใช้ฟังก์ชันของ backend โดยตรง
• GameState ถูกจัดการอยู่ภายใน WASM เท่านั้น ฟรอนต์เอนด์ไม่สามารถ mutation ได้ และ backend คือแหล่งข้อมูลจริงเพียงหนึ่งเดียวเสมอ
• หลัง recompile WASM ต้องนำไฟล์ใหม่มาแทนที่ และมีตัวอย่างการใช้ Makefile เพื่อทำงานอัตโนมัติ

สภาพแวดล้อมการรัน WASM

• ในการรัน ต้องใส่ wasm_exec.js ไว้ใน head และใช้สคริปต์ดังกล่าวเพื่อสร้าง instance แล้วจึงรัน

บทสรุป

• การสร้างเกมเป็นประสบการณ์ที่สนุก และแนวทางที่ใช้ Go, WASM และ React ร่วมกันก็เป็นสิ่งที่ใคร ๆ ลองทำตามได้
• แม้ ความช่วยเหลือจาก LLM จะเพิ่มผลิตภาพได้มาก แต่ ทักษะด้านฟรอนต์เอนด์และประสบการณ์ในการดีบัก ก็ยังสำคัญอยู่เสมอ
• ใคร ๆ ก็สามารถ ลองพัฒนาเกมด้วยตัวเอง ด้วยโครงสร้างแบบนี้ได้ จึงน่าลองทำดู

[codong]

ถ้าเป็นโค้ดที่สร้างขึ้นมาแล้วมีการใช้ document.getElementById ใน React นี่ใช้ LLM ตัวไหนกันนะ....

[onetoday]

รู้สึกเหมือนเป็นพาดหัวล่อคลิกชัด ๆ เลย..
"ถ้าสร้างตั้งแต่แรกใช้เวลา 3 เดือน แต่ถ้าสร้างอะไรที่คล้ายกันอีกครั้งใช้เวลา 3 วัน"

[savvykang]

ดูเหมือนว่าผู้เขียนต้นฉบับจะเป็นคนที่ไม่ค่อยรู้ว่าปกติตัวเองทำอะไรอยู่

[GN⁺]

ความคิดเห็นจาก Hacker News

• สิ่งที่ผมชอบในโพสต์นี้คือมันชี้ให้เห็นข้อเท็จจริงที่นักพัฒนาหลายคนมองข้ามไป นั่นคือในการพัฒนาเกม คอขวดแทบไม่เคยเป็นเรื่องการเขียนโค้ดเอง คนทำเดี่ยวก็สามารถสร้างเมคานิกได้เร็วอยู่แล้วแม้ไม่มี AI ส่วนที่ยากจริงคือเลเยอร์ที่มองไม่เห็นด้านบนเหล่านี้ เช่น การบาลานซ์ game loop การจูนความยาก การสร้างแอสเซ็ตที่ไม่ดูขัดกัน และการขัดเกลาให้ผู้ใช้สนใจต่อเนื่องเกิน 5 นาที นี่จึงเป็นเหตุผลว่าทำไมหลังยุค LLM เราถึงยังไม่ได้เห็นเกมยอดเยี่ยมล้น Steam เทคโนโลยีลดกำแพงลงไปหนึ่งชั้น แต่กำแพงที่ใหญ่กว่ายังอยู่เหมือนเดิม ตอน Unity แจ้งเกิดในยุค 2010s ก็เหมือนกัน เอนจินทำให้การพัฒนาเกมเป็นประชาธิปไตยมากขึ้น แต่สิ่งที่เพิ่มขึ้นแบบระเบิดไม่ใช่จำนวนเกมดี ๆ หากเป็นจำนวนความพยายามที่จะสร้างเกมมากกว่า LLM ทำแบบเดียวกันกับโค้ด และโมเดลภาพก็ทำแบบเดียวกันกับงานศิลป์ แต่เครื่องมือพวกนี้ยังบอกไม่ได้ว่าเกมไหนสนุกจริง สำหรับผม คำถามที่น่าสนใจคือถ้า AI ไม่ได้ช่วยแค่การทำให้เสร็จ แต่ช่วย playtest ด้วยจะเกิดอะไรขึ้น ถ้ามันพัฒนาไปถึงขั้นรันลูปหลายพันรอบแล้วบอกได้ว่าเมคานิกไหนทำให้ผู้เล่นจำลองยังอยากเล่นต่อ บทบาทของมันก็คงขยายจากแค่ตัวช่วยเพิ่มผลิตภาพไปเป็นคู่หูด้านดีไซน์ได้ เรายังไม่ถึงจุดนั้น แต่บทความนี้ให้ความรู้สึกเหมือนเป็นข้อมูลตั้งต้นช่วงแรก ๆ ที่กำลังมุ่งไปทางนั้น

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

  • อยากโต้แย้งตัวอย่างเรื่องการผงาดของ Unity ในยุค 2010s ว่าเกมดี ๆ ไม่ได้เพิ่มขึ้นมากนัก จริง ๆ แล้วถ้าเทียบกับยุค XBLA ปริมาณเกมมหาศาลที่เรามีตอนนี้คงเป็นไปไม่ได้เลยหากไม่มีเครื่องมืออย่าง Unity, Godot, Gamemaker, Renpy, RPG Maker กล่าวคือมันมีการก้าวกระโดดชัดเจนไม่ใช่แค่เชิงคุณภาพ แต่เชิงปริมาณด้วย

  • สำหรับผม ลิตมัสเทสต์ของ generative AI คือการสร้าง spritesheet ทั้งชุดสำหรับเกมแอ็กชัน 2D pixel art เช่น อย่างน้อยก็ทำให้ได้สมบูรณ์แบบสำหรับรถถังหรือการเคลื่อนไหวของตัวเอก แต่จนถึงตอนนี้ก็ยังไม่เคยเห็นตัวอย่างที่สำเร็จจริง

  • ผมคิดว่าประเด็นที่ว่า "AI บอกคุณไม่ได้หรอกว่าเกมของคุณสนุกจริงไหม" คือ insight สำคัญ AI ไม่สามารถสัมผัสเกมในแบบเดียวกับที่มนุษย์สัมผัสได้ หรือแม้แต่ประสบการณ์อื่นใดก็ไม่ใช่แบบมนุษย์ มันทำได้แค่คาดเดาระดับหนึ่งจากข้อมูลการประเมินของมนุษย์ต่อเกมคล้าย ๆ กัน กล่าวคือ AI ไม่สามารถสนุกกับเกมของคุณได้ แก่นนี้แหละที่จะนิยามบทบาทของแรงงานมนุษย์ในยุค AI ต่อไป มันพิสูจน์ว่าแม้ AI จะเขียนเอกสารหรือโค้ดให้ดูเหมือนมนุษย์ได้ระดับหนึ่งจากข้อมูลในอดีต แต่ยังมีการบูรณาการและประสบการณ์ที่มีความหมายซึ่งมีแต่มนุษย์จริงเท่านั้นที่ทำได้ มีจุดที่คุณค่าของมนุษย์ทดแทนไม่ได้ เพียงแต่เราต้องมองคุณค่านั้นในมุมใหม่

  • รูปแบบนี้ไม่ได้เกิดแค่กับการพัฒนาเกม แต่เกิดกับสาขาอื่นด้วย อย่างที่ทุกคนคาดหวัง agent-based coding ก็มีศักยภาพมหาศาล แต่ตอนนี้ยังเหนือชั้นจริง ๆ แค่กับบางงานเท่านั้น เช่น เว็บแอปเดโมเร็ว ๆ หรือการเชื่อมไลบรารีขนาดเล็ก ส่วนซอฟต์แวร์ขนาดใหญ่จริงยังนำไปใช้ได้ไม่ดีนัก ทั้งวิธีที่โมเดลถูกฝึกและความรู้ในการใช้งานของเราก็ยังไม่พอ เรื่องนี้ไม่น่าแปลกใจ git เองหลังออกมาแล้ว 5 ปีก็ยังมีแค่บริษัทระดับหัวกะทิที่ใช้งานได้ดี และกว่าจะเป็นที่แพร่หลายก็ใช้เวลาอีก 5 ปี สุดท้ายตอนนี้เราคุ้นเคยกับมันมากแล้ว แต่ผมกลับมองว่า LLM ใช้ให้ถูกทางยากกว่า git เสียอีก ถ้าทุกผลิตภัณฑ์ OSS หรือบล็อกโพสต์ไม่โหมเกินจริงแบบ "มันจบแล้ว ทุกอย่างถูกปฏิวัติแล้ว" กันไปหมด เราอาจพัฒนาได้เร็วกว่านี้ก็ได้ ตอนนี้เรายังอยู่ในช่วงลองผิดลองถูกและการทดลอง และมันต้องใช้เวลา อย่าเพิ่งตัดสินเร็วเกินไป ถ้าทุกอย่างถูกแก้หมดแล้วจริง อย่างน้อยเราควรถูกถมทับด้วยซอฟต์แวร์ที่ดีกว่านี้มาก แต่ตอนนี้เรายังอยู่ในระดับที่พยายามหาสมดุลกันอยู่ แค่นี้ก็ถือว่าน่าประทับใจมากแล้วสำหรับเทคโนโลยีใหม่ที่เพิ่งโผล่มา 1-2 ปี

• ที่ LLM นำหน้าอยู่ 3 เดือน ก็เพราะมันอาศัยโค้ด เกมเก่าในฐานะเทมเพลต และที่สำคัญที่สุดคืออาศัยประสบการณ์กับความผิดพลาดทั้งหมดที่สะสมมาจากการเขียนมือก่อนหน้านั้น

  • ตอนแรกนึกว่าจะเป็นแค่พาดหัวเรียกแขก แต่พอเห็นส่วนที่ว่า "คัดลอก backend ของ Truco แล้วอธิบายกติกา Escoba ให้ Claude ฟังแบบยาว ๆ จากนั้นให้มันรีแฟกเตอร์โค้ด" ก็รู้สึกทึ่งขึ้นมาจริง ๆ ทำให้สงสัยว่าถ้าคนมารีแฟกเตอร์เองจะใช้เวลานานเท่าไร อาจเกิน 3 วันก็ได้ หรืออาจไม่ก็ได้

  • อีกประเด็นหนึ่งคือเกมนี้เป็นเกมแรกของผู้เข้าร่วม ซึ่งสำคัญมาก หมายความว่าตอนลองทำครั้งแรกคุณต้องรับมือกับตัวแปรที่ไม่รู้จักอีกมาก แต่ถ้าคุณเคยผ่านมันมาแล้วครั้งหนึ่งและได้ insight กับ know-how มา พอเริ่มใหม่อีกครั้ง ต่อให้ไม่มี LLM ก็น่าจะทำเสร็จได้เร็วกว่า 3 เดือนมาก

  • อันที่จริงผมก็เคยสัมผัสเองว่าเมื่อทำโปรเจ็กต์เดิมซ้ำเป็นครั้งที่สองสาม สิ่งที่ครั้งแรกใช้เวลาหลายเดือน ครั้งถัดไปจะลดเหลือประมาณหนึ่งในสาม

• <i>กระแอม</i> ผมเคยทำเสร็จภายใน 24 ชั่วโมงด้วยซ้ำ มีตัวอย่างอยู่ที่ nordicgamejam.com อยากจะบอกว่ายุคก่อนมี LLM, GenAI และก่อน Unity นั้น สิ่งที่ดีที่สุดคือ Microsoft XNA กับ C# งานอาร์ตก็ส่วนใหญ่เป็นระดับวาดมือด้วย Paint แต่ถึงอย่างนั้นก็ยังมีเกมสนุก ๆ เกิดขึ้นทุกปีมากพอ และบางเกมอย่าง Baba is You หรือ Braid ก็เป็นที่รู้จักในวงกว้าง โค้ดไม่ใช่คอขวด และส่วนตัวผมมั่นใจว่าคอขวดจริงคือการสื่อสารกันระหว่างสมาชิก

  • ขอเสริมความเห็นเรื่องการสื่อสารในทีมเป็นคอขวดสำคัญว่า บ่อยครั้งแม้แต่การ 'สื่อสาร' กับตัวเองในหัวก็ยากอย่างน่าประหลาดเหมือนกัน

• อ่านจากกระแสคอมเมนต์นี้แล้วรู้สึกว่าหลายคนไม่มีประสบการณ์พัฒนาเกมจริง ๆ โปรเจ็กต์ที่ LLM ถูกนำมาใช้แบบนี้เป็นประเภทที่มีอยู่มากแล้วใน training data เช่น เป็นโปรเจ็กต์ที่ใช้สอนในวิชาเขียนโปรแกรมเบื้องต้น และในประเทศแถบยุโรปใต้ก็มีเกมคล้ายเกมไพ่ที่บล็อกนี้พูดถึงอยู่เยอะมาก ตอนผมอยู่ปีหนึ่งมหาวิทยาลัย ผมเองก็เคยทำ Moon Patrol ด้วย Python จากศูนย์โดยแทบไม่มีประสบการณ์ ใช้เวลา 2-3 เดือน เขียนโค้ดดึก ๆ สัปดาห์ละ 3 วัน การทำเกมไพ่จริง ๆ ง่ายกว่านั้นอีก LLM มีประโยชน์แน่นอนในหลายจุด แต่ตัวอย่างง่าย ๆ แบบนี้ไม่เหมาะจะใช้เป็น benchmark วัดผลิตภาพหรือประโยชน์ด้านการเขียนโค้ดของ LLM

• ผมเคยทำงานลักษณะนี้กับ LLM แบบค่อย ๆ แวะมาทำอยู่หลายวัน: stacky ถ้านับเวลาที่ทำจริงก็น่าจะราวสองวัน ตอนแรกเขียนแบบ ground-up แล้วค่อยเขียนต่อแบบ brownfield โดยไม่ได้ตั้งใจจะทำจริงจังถึงขั้นสมบูรณ์ แต่พอเริ่มเติมรายละเอียดและฟีเจอร์มากขึ้น ไอเดียก็ยิ่งผุดขึ้นมาเรื่อย ๆ (super rotation, DAS ฯลฯ) ตอนนี้ยังไม่เสร็จดี น่าจะอยู่แค่ 10-20% ของเกมทั้งหมด เวอร์ชัน WebGL ก็รันได้ แต่ถ้าผมเดินหน้าทำ Tetris เวอร์ชันสมบูรณ์แบบเกินไปก็คงโดนฟ้องแน่ ๆ และก็ไม่มีเงินจ่ายค่าไลเซนส์ด้วย เลยหยุดไว้ สุดท้ายสิ่งที่ได้คือความมั่นใจและประสบการณ์ เมื่อไม่นานมานี้เห็นลิงก์ใน HN เกี่ยวกับฟังก์ชันพาราเมตริก ก็เลยทำ playground ชื่อ graphy ขึ้นมาใน 1-2 ชั่วโมงเช่นกัน แน่นอนว่ายิ่งลงรายละเอียดก็ยิ่งกินเวลา แต่ถ้าคุณรู้ชัดว่าอยากได้อะไร งานแบบนี้ทำกับ LLM แล้วค่อนข้างสนุก

  • ขอชมว่าไอเดียตีความ Tetris ใหม่นั้นเจ๋งมาก แต่อยากบอกไว้ว่าในเครื่อง MacBook Pro M4 Max ใหม่กับ Firefox มันใช้คอร์เต็ม 100% และพัดลมหมุนหนักมาก

• ผมทำเกมเป็นงานอดิเรกระดับจริงจังมานานและทำเสร็จไปหลายเกมแล้ว แต่โดยรวมแล้วกระแสคอมเมนต์นี้ดูเหมือนคนที่มีประสบการณ์พัฒนาเกมจริงไม่มากนัก ผมไม่เห็นด้วยกับคำพูดที่ว่าการเขียนโค้ดในเกมเป็นเรื่องง่าย การคิดไอเดียสดใหม่หรือเมคานิกดัดแปลงแนวเกมอาจง่ายกว่า แต่ส่วนที่ยากกว่ามากคือการเขียนโค้ดให้มันเกิดขึ้นจริง ลองนึกภาพว่าจะทำ Vampire Survivors แบบมัลติเพลเยอร์แล้วเพิ่มการปรับแต่ง battlemech ดู การจินตนาการนั้นง่าย แต่จะทำให้มันเกิดขึ้นจริงด้วย LLM อย่างเดียบนั้นแทบเป็นไปไม่ได้ กรณีนี้เป็นแค่กติกาเกมไพ่ที่รู้จักกันหมดอยู่แล้ว เลยง่ายพอ ๆ กับเกมงู ไม่ได้จะตำหนิคนเขียนบทความ แต่อยากชี้ว่าหลายคนกำลังตัดสินเรื่องการพัฒนาโดยไม่มีประสบการณ์ทำเกมจริง

  • ผมไม่เห็นด้วยกับความคิดที่ว่าการเขียนโค้ดคือส่วนยากของการพัฒนาเกม มันอาจยากก็จริง แต่สิ่งที่ยากจริงคือการคิดไอเดียใหม่ ๆ ที่สนุก ถ้ามีไอเดียดีแล้ว คุณก็แค่แตกมันออกเป็นชิ้นเล็ก ๆ แล้วทำซ้ำไป ในที่สุดก็เขียนมันได้ อุปสรรคแท้จริงคือช่วงที่คุณต้องตัดสินใจจากหน้ากระดาษเปล่าว่าจะสร้างอะไร ลองออกไปเดิน ลองสารพัดวิธี ปัญหานี้วนอยู่ในศิลปะมาหลายพันปีแล้ว ในทางกลับกัน การเขียนโค้ดสุดท้ายก็เป็นงานเชิงวิศวกรรม ผมเองช่วงนี้กำลังเรียนทำเกมและเรียนคณิตศาสตร์ไปด้วย แต่การเรียนเวกเตอร์หรือควอเทอร์เนียนกลับง่ายกว่าการตอบคำถามว่า "ผมอยากทำเกมอะไร"

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

• ถ้าจะทำเกมแบบ client-side ทั้งหมดจริง ๆ ผมสงสัยว่าทำไมถึงเขียนเหมือนจำเป็นต้องมี "backend" แล้วทำไมถึงใช้เทคโนโลยีต่างกันเฉพาะ backend แทนที่จะใช้แบบเดียวกันทั้งแอป

• ผมรู้สึกว่าในอุตสาหกรรมซอฟต์แวร์ แทบไม่เหลือพื้นที่ให้ไอเดียถูกทำให้เป็นจริงได้ง่ายและเร็วอีกแล้ว การแข่งขันมันดุเดือดเกินไป ต่อให้จับตลาดเล็กแค่ไหนก็ยังต้องแข่งตรงกับ VC ระดับโลกและ AI ระดับโลก ในอดีตอย่างน้อยคุณยังหาช่องเฉพาะที่บริษัทใหญ่ไม่สนใจได้ ตอนนี้ไม่ว่าจะตลาดใหญ่จาก VC หรือตลาด niche ก็ต้องแข่งกับคนทั้งโลกอยู่ดี สุดท้ายเลยเหลือแค่ตลาดเล็กที่ต้องใช้เทคโนโลยีซับซ้อนมาก หรือพื้นที่ที่กำไรต่ำ โอกาสล้มเหลวสูง และวงจรชีวิตสั้น (ซึ่งเกมส่วนใหญ่ก็อยู่ในกลุ่มนี้) กรณีแรกก็ต้องทำการตลาดแบบเดินไปอธิบายสินค้าทีละราย จากประสบการณ์ในวงการเกม ก่อนจะเข้าสู่ขั้นพัฒนาจริง ตัวอย่างความสำเร็จระดับดังมากยังแค่ประมาณ "ได้ล้านวิว แล้วอีก 6 เดือนก็เงียบหาย" พอรายได้ประจำแทบไม่มี การเริ่มต้นเลยบั่นทอนกำลังใจสุด ๆ การสร้างเกมแบบ Minecraft แทบไม่ต่างจากถูกรางวัลลอตเตอรี่ แต่ข้อดีคือวงการเกมยังเป็น meritocracy มากกว่าอุตสาหกรรมซอฟต์แวร์อื่น คุณภาพและความสนุกยังมีผลต่อการถูกรับไปใช้จริง ส่วนอุตสาหกรรมอื่นเต็มไปด้วยเขาวงกตของกฎระเบียบ การผูกขาดจาก network effects หรือการควบคุมโดยภาครัฐ บางทีก็หวังว่าในช่วงต้นรัฐบาลจะบอกตรง ๆ ไปเลยว่า "สายนี้บริษัทนี้ยึดหมดแล้ว ไปทำอย่างอื่นเถอะ อย่ามาเปิดสตาร์ตอัป" อย่างน้อยจะได้ไม่เสียเวลาไปหนึ่งปี

• ผมสงสัยว่าเมื่อไรคนจะตระหนักเสียทีว่าโปรเจ็กต์ greenfield (สร้างใหม่ทั้งหมด) คือกรณีที่แย่ที่สุดสำหรับการ benchmark ความสามารถของ agent coding

• เหตุผลที่ผมชอบ LLM คือมันช่วยให้ผมจัดการโค้ดได้ใกล้เคียงกับวิธีที่ผมทำ abstraction ของโปรแกรมในหัวมากขึ้น เวลาอ่านโค้ด ผมจะเข้าใจมันเหมือนเป็น AST โดยแปลงฟังก์ชันกับการเรียกใช้ให้เป็นโหนดนามธรรมของอินพุตและผลลัพธ์ LLM ทำให้การแปลงย้อนจากสิ่งนี้กลับมาเป็นโค้ดง่ายขึ้นมหาศาล ผมไม่ต้องคอยไล่หาตัวอย่างโค้ดที่ตรงกับไอเดียหรือขุดความจำอีกแล้ว แค่สั่งให้ LLM เขียนโค้ดซ้ำ ๆ อย่างการตั้งค่าเริ่มต้น WiFi ให้ ผลลัพธ์คือผมประกอบโปรแกรมได้เหมือนต่อบล็อกเลโก้ วิธีนี้ทำได้อยู่แล้วแม้ก่อนมี LLM แต่ต้องใช้แรงมากกว่านี้มาก ทุกวันนี้ผมเลยพัฒนาอะไรข้ามภาษาได้อย่างสบาย แม้จะไม่ได้เรียนรู้โครงสร้างภายในหรือไวยากรณ์ของแต่ละภาษาเยอะนัก แต่นั่นแหละคือประเด็น ภาษาและไวยากรณ์เป็นแค่รายละเอียดรองที่ไม่เกี่ยวกับตรรกะการไหลของโปรแกรม สุดท้ายแล้วอย่างที่เราไต่จาก machine code ไป assembly ไป C และต่อไปยังภาษาในระดับสูงขึ้นเรื่อย ๆ ตอนนี้เรากำลังเข้าใกล้สิ่งที่ไม่ใช่แค่การ "เขียนโค้ด" แต่เป็น "การทำโปรแกรม" เองมากขึ้น ไม่มีใครรู้ว่ารูปแบบสุดท้ายจะเป็นอย่างไร แต่ชัดเจนว่าเวลาที่เราใช้ไปกับการ "เขียน" จะน้อยลง และเวลาที่ใช้กับ "การทำโปรแกรม" จะมากขึ้นเรื่อย ๆ

  • เห็นด้วย สมัยก่อนก็คงมีคนกังวลว่าถ้าเขียนด้วย C แล้วไม่เข้าใจระดับ assembly จริง ๆ วันหนึ่งจะเจอปัญหาใหญ่ แต่สิ่งที่เกิดขึ้นจริงคือเครื่องมือเพิ่มผลิตภาพของนักพัฒนาก้าวหน้าไปเรื่อย ๆ AI ก็เหมือนกัน ข้อดีใหญ่ที่สุดคือการดึงงานซ้ำซากที่ชัดเจนเกินไปออกจากนักพัฒนา แต่ก่อนเราเสียเวลามากกับการไล่ memory leak และ segmentation fault ใน C ตอนนี้ภาษาแบบ modern ทำให้ไม่ต้องเสียเวลาแบบนั้นแล้ว เช่นเดียวกัน งานอย่างหาตัวอย่างรายละเอียดการ implement จุกจิกหรือค้นเอกสารก็จะค่อย ๆ หายไป สุดท้ายนักพัฒนาจะได้โฟกัสกับส่วนที่สร้างสรรค์มากขึ้น