- สามารถพัฒนาเกมได้อย่างง่ายและสนุกเพียงพอแม้จะไม่ใช้ เกมเอนจินเชิงพาณิชย์
- ไม่จำเป็นต้องใช้ฟีเจอร์ส่วนใหญ่ของเอนจินขนาดใหญ่ และการเขียนเครื่องมือขึ้นเองจะเพิ่มทั้ง ความยืดหยุ่นและประสิทธิภาพในการพัฒนา
- การใช้ C# สมัยใหม่และไลบรารีโอเพนซอร์ส สามารถมอบสภาพแวดล้อมการพัฒนาที่เพียงพอได้โดยไม่ขึ้นกับขนาดทีม
- สามารถจัดวางไปป์ไลน์ให้เหมาะกับความต้องการได้ด้วยการผสานไลบรารีอย่าง FMOD, SDL3, Dear ImGui เข้ากับเครื่องมือที่สร้างเอง
- ในด้าน การพัฒนาข้ามแพลตฟอร์ม การบำรุงรักษา และความสามารถในการพอร์ต เฟรมเวิร์กน้ำหนักเบาที่สร้างขึ้นเองมีข้อได้เปรียบมาก
บทนำ: ความเห็นจากนักพัฒนาเกมที่ทำงานมา 20 ปี
- แม้ในปี 2025 ก็ยังพัฒนาเกมวิดีโอโดยไม่ใช้ เกมเอนจินเชิงพาณิชย์
- คนรอบตัวมักประหลาดใจที่ไม่ได้ใช้เอนจินเชิงพาณิชย์
- ฟังก์ชันพื้นฐานของเอนจินขนาดใหญ่อย่าง Unity หรือ Unreal เมื่อลองเทียบกับการทำเองแล้วไม่น่าพอใจนัก และสุดท้ายก็มักต้องสร้างหลายส่วนขึ้นมาใหม่
- เมื่อใช้เอนจินเชิงพาณิชย์ มักต้องเผชิญปัญหาจาก การเปลี่ยนนโยบายทางธุรกิจ หรือการอัปเดตอยู่บ่อยครั้ง
- การสร้าง เครื่องมือขนาดเล็ก ที่เหมาะกับแต่ละโปรเจกต์ขึ้นมาเองมีประสิทธิภาพกว่า และดูแลรักษาได้ง่ายกว่าในระยะยาว
การเลือกภาษาโปรแกรมที่จำเป็นต่อการพัฒนาเกม
- ใช้ C# เป็นภาษาหลักมาอย่างยาวนาน
- C# ยุคใหม่พัฒนาขึ้นมากเมื่อเทียบกับอดีตทั้งด้าน ประสิทธิภาพ ไวยากรณ์ และประสบการณ์การพัฒนา
- มีฟีเจอร์ hot reload อย่าง dotnet watch ซึ่งสะดวกมากสำหรับการแก้โค้ดและทดสอบแบบเรียลไทม์
- แม้แต่คนที่ไม่ใช่นักพัฒนาก็เข้าถึงได้ง่าย ทำให้ แบ่งบทบาทและทำงานร่วมกันในทีมได้อย่างมีประสิทธิภาพมากขึ้น
- ความสามารถ reflection ที่มีมาในตัวเป็นจุดแข็งสำหรับการสร้างเอดิเตอร์หรือเครื่องมือ
ไลบรารีข้ามแพลตฟอร์มและการทำเรนเดอร์·อินพุต
- ใช้ SDL3 เพื่อทำฟังก์ชันพื้นฐานทั้งหมด เช่น หน้าต่าง การเรนเดอร์ คอนโทรลเลอร์ และการรองรับข้ามแพลตฟอร์ม
- GPU abstraction ของ SDL3 ทำให้รองรับสภาพแวดล้อมที่หลากหลายอย่าง DirectX, Vulkan, Metal ได้ง่ายขึ้น
- ใช้ C# เลเยอร์ ที่เขียนครอบบน SDL เอง (เช่น Foster) เป็นยูทิลิตีส่วนกลาง
- ใช้ FMOD เป็นเครื่องมือเสียงเชิงพาณิชย์ตัวสุดท้ายที่ยังคงใช้ ส่วนอื่นนอกนั้นสร้างไปป์ไลน์บนพื้นฐานโอเพนซอร์ส
- เคยมีประสบการณ์ทำ OpenGL/DirectX เองโดยตรงมาก่อน และความเสถียรของ SDL เป็นข้อได้เปรียบที่สำคัญมาก
วิธีจัดการแอสเซ็ต (Assets)
- หากใช้เอนจินที่ทำเอง ก็เพียงโหลดไฟล์ที่เกมต้องใช้เท่านั้นอย่างเรียบง่าย
- ในกรณีแอสเซ็ตขนาดเล็ก เช่น เกมพิกเซลอาร์ต จะโหลดไฟล์ทั้งหมดเข้าหน่วยความจำครั้งเดียวตอนเริ่มต้น
- ในโปรเจกต์ขนาดใหญ่ จะโหลดเฉพาะแอสเซ็ตที่ต้องใช้ตามคำขอ และปล่อยหน่วยความจำเมื่อเปลี่ยนฉาก
- หากต้องมีการคอนเวิร์ต ก็เพียงเขียนสคริปต์ให้จัดการอัตโนมัติระหว่างคอมไพล์ก็เพียงพอ
เอดิเตอร์เลเวลและเครื่องมือ UI
- เชื่อมข้อมูลกับเอดิเตอร์เลเวลโอเพนซอร์สอย่าง LDtk, Tiled, Trenchbroom ได้ง่าย
- โดยทั่วไปมักสร้าง เอดิเตอร์แบบปรับให้เหมาะกับแต่ละโปรเจกต์ ขึ้นเอง
- ไม่ได้เขียนตัว UI หลักเอง แต่ใช้งาน immediate-mode GUI ของ Dear ImGui อย่างเต็มที่
- การผสาน reflection ของ C# กับ ImGui ทำให้สามารถแสดงสถานะของเกมออบเจ็กต์แบบเห็นภาพได้แบบเรียลไทม์
- หากจำเป็นก็ผสมใช้ทั้งเครื่องมือภายนอกที่เหมาะกับงานและเครื่องมือที่สร้างเอง
การพัฒนาข้ามแพลตฟอร์มและความสามารถในการพอร์ตไปคอนโซล
- ในอดีตการพอร์ตไปคอนโซลทำให้จำเป็นต้องเลือก C++ แต่การมาของ C# Native-AOT ช่วยแก้ปัญหานี้ได้
- เฟรมเวิร์กโอเพนซอร์สอย่าง FNA ก็กำลังขยายการรองรับคอนโซลอย่างจริงจัง
- หากใช้เลเยอร์ abstraction แบบทั่วไปที่ SDL3 รองรับ ก็สามารถใช้โค้ดเบสเดียวกันได้บนแทบทุกระบบ
สภาพแวดล้อมการพัฒนา: ระบบนิเวศแบบเปิดที่มี Linux เป็นศูนย์กลาง
- เปลี่ยนแพลตฟอร์มพัฒนาหลักเป็น Linux และเข้ากันได้ดีมากกับทูลเชนโอเพนซอร์ส
- แม้ยังมีการเชื่อมโยงกับซอฟต์แวร์เชิงพาณิชย์บางตัวอยู่ (เช่น vscode, github) แต่ยิ่งระบบนิเวศโอเพนซอร์สกว้างขึ้น การรองรับก็ยิ่งเพิ่มขึ้น
- โดยส่วนตัวกำลังจัดสภาพแวดล้อมการทำงานแบบเดียวกันบนแพลตฟอร์มที่ใช้ Linux หลากหลายแบบ เช่น Steam Deck
Q&A เพิ่มเติมและกรณีตัวอย่าง
- คำถามเรื่องการใช้ Godot: หากต้องการพัฒนาโดยยึดเอนจินโอเพนซอร์สเป็นหลัก แนะนำ Godot นอกเหนือจากนั้นยังชอบเครื่องมือคัสตอมมากกว่า
- งาน 3D: เอนจินขนาดใหญ่มีข้อได้เปรียบ แต่สำหรับโปรเจกต์ขนาดเล็กที่มีความเฉพาะทาง เฟรมเวิร์กที่ปรับให้เหมาะกับงาน ก็เพียงพอ
- ความต้องการด้านเทคนิคระดับสูง: หากระดับความต้องการเหมาะสม การใช้เอนจินขนาดใหญ่อย่าง Unreal ก็ไม่มีปัญหา
- การเปลี่ยนเอนจินในระดับทีม: เหมาะกับการพัฒนาขนาดเล็ก/เดี่ยว และแม้แต่สตูดิโอขนาดกลางถึงใหญ่ก็มีกรณีเปลี่ยนไปใช้คัสตอมเอนจินมากขึ้นเพื่อ หลีกเลี่ยงความเสี่ยงระยะยาว
- เวิร์กโฟลว์แอสเซ็ต: สามารถแปลงไฟล์ Aseprite เป็นแอนิเมชันได้อัตโนมัติโดยใช้แท็กและไทมิงที่มีมาในตัว
บทสรุป
- การสร้างเกมโดยไม่ใช้เกมเอนจินเชิงพาณิชย์เป็นทางเลือกที่ขึ้นอยู่กับ รสนิยมและวิธีการทำงาน
- ให้เลือกวิธีที่เหมาะกับตัวเองโดยให้ความต้องการและความสนุกเป็นสิ่งสำคัญที่สุด
5 ความคิดเห็น
เป็นกิจกรรมที่ดีมากครับ
ผมเป็นนักพัฒนาเกมยุคแรก ๆ
ก่อนที่ Unreal จะออกมา แน่นอนว่าบริษัทพัฒนาเกมต่าง ๆ
ต้องพัฒนาเอนจินกันเองเป็นเรื่องปกติ
และนั่นก็คือความสามารถในการแข่งขันโดยตรง
การพัฒนาเอนจินในตอนนั้น งานส่วนใหญ่คือการพัฒนาเครื่องมือ
โดยมีแกนหลัก เคอร์เนล การเรนเดอร์ และระบบอินพุต/เอาต์พุตอื่น ๆ เป็นพื้นฐาน
ตอนนั้นผมรับผิดชอบเครื่องมือสำหรับพาร์ติเคิล เสียง เลเยอร์ และอ็อบเจ็กต์
ทีมมีอยู่ 7 คน แต่ถ้ารวม ๆ กันแล้วก็น่าจะทำเครื่องมือกันได้เกิน 20 ตัวแบบสบาย ๆ
ตั้งแต่วันหนึ่งที่ Unreal ออกมา เกมแบบผลิตจำนวนมาก
ก็หลั่งไหลออกมา จนไม่มีใครลงทุนกับการพัฒนาเอนจินอีกแล้ว
ตอนนั้นเหมือนหลายคนจะแยกตัวไปตั้งบริษัทกัน
นี่ก็เป็นเรื่องเมื่อ 27 ปีก่อนแล้ว
ตอนนี้ผมก็อายุมากขึ้นมากแล้ว และกำลังทำงานด้านอื่นที่ไม่ใช่เกมอยู่
มันทำให้นึกถึงช่วงเวลาอันชวนคิดถึง
ที่เคยทำงานระดับคอร์แยกตามโหมด directx, opengl
ตามการ์ดจอแต่ละรุ่น
สู้ ๆ ครับ...
ช่วงนี้ผมหาเอนจินมาทำเกมวางแผนอยู่นาน จนเริ่มคิดว่าถ้าอย่างนั้นทำเอนจินขึ้นมาเองน่าจะดีกว่า แต่พอได้เห็นตัวอย่างคนที่ลงมือทำจริงแล้วประสบความสำเร็จ ก็รู้สึกมีพลังใจขึ้นมาเลยครับ
ความเห็นจาก Hacker News
หลังจากพัฒนาเอนจินเกม 2D คนเดียวมา 5 ปี และรับงานที่เกี่ยวข้องแบบมีค่าจ้าง ก็อยากอธิบายประเด็นสำคัญที่คนส่วนใหญ่มักไม่รู้
เอนจินเป็นส่วนที่ง่าย
ส่วนที่สำคัญจริง ๆ คือ tooling รอบเอนจิน, คอนเทนต์, และ asset pipeline
การนำเข้า texture, audio, model files (gltf, fbx, แอนิเมชัน ฯลฯ) จากแหล่งข้อมูลและฟอร์แมตที่หลากหลาย
ฟีเจอร์แก้ไขพื้นฐานในแอป editor เช่น crop, copy, paste, undo, redo, save, delete
การแสดงผลและฟังก์ชันที่ทำให้นักพัฒนาสามารถสร้างและจัดการข้อมูลจริงใน editor ได้ (เช่น entity, แอนิเมชัน, scene, audio graph, รองรับ scripting ฯลฯ)
การแพ็กเกจข้อมูลและ preprocessing เช่น static geometry baking, shader compilation, texture/audio resampling และ packing, การสร้าง asset pack สำหรับคอนเทนต์เกม
เมื่อทั้งหมดนี้เสร็จแล้ว ส่วน runtime จริง ๆ (ก็คือ main loop ของเกมและ subsystem ต่าง ๆ) กลับเป็นเพียงส่วนเล็ก ๆ ของทั้งระบบ
นี่จึงเป็นเหตุผลว่าทำไมในสตูดิโอเกม คนที่ดูแลเอนจินมีจำนวนน้อย แต่โปรแกรมเมอร์ที่ทำเครื่องมือมีจำนวนมากกว่า
เอนจิน detonator: https://github.com/ensisoft/detonator
สิ่งสำคัญคือโฟกัสกับการสร้างเอนจินที่เหมาะกับเกมของตัวเอง มากกว่าจะพยายามทำให้ใช้ได้สารพัดอย่าง
เรื่อง UI, การบีบอัด ฯลฯ แก้ได้ด้วยไลบรารีและเฟรมเวิร์ก
การที่ OP ใช้ไลบรารีขนาดเล็กอย่าง imGUI ก็เป็นตัวอย่างที่ดี
เพราะไม่ได้สร้างเอนจินสำหรับทุกเกม งานจำนวนมากจึงกลายเป็นสิ่งที่แทบไม่ต้องทำเลย
เอนจินเป็นเหมือน runtime ขนาดเล็กที่พ่วงอยู่กับ asset pipeline
ทุกวันนี้แม้แต่ shader compiler ก็ยิ่งสำคัญกว่า 3D API มากขึ้นเรื่อย ๆ
ส่วนที่น่าสนใจไปกระจุกอยู่ที่ shader compiler ขณะที่ 3D API ทำหน้าที่แค่รัน shader และส่งข้อมูลต่อ
เวลาคนพูดถึงเอนจิน ก็มักจะนับรวม asset pipeline กับ editor เข้าไปด้วย
เอนจินยุคนี้ไม่ได้มีแค่ main loop + ฟังก์ชัน 3D API
แม้จะใช้เอนจินอย่าง Unity ก็มีนักพัฒนาน้อยมากที่จะเขียนแค่โค้ดเรนเดอร์
แน่นอนว่าการใช้ Unity/Unreal ก็ไม่ได้แปลว่าจะไม่ต้องใช้เครื่องมือ asset เองเลย
ช่วงหลังมานี้ผมกำลังยกเครื่องเอนจินสำหรับภาคต่อใหม่ และเห็นด้วยกับประเด็นนี้มาก
อย่างที่เขียนไว้ใน postmortem คนส่วนใหญ่มักนึกถึงโค้ดที่อยู่ในไฟล์เกม executable เมื่อพูดถึงเอนจิน แต่ในทางปฏิบัติ ผมคิดว่าสัดส่วนที่ใหญ่กว่าคือโค้ดที่ไม่ได้ถูกส่งไปพร้อมเกม เช่น level editor, content pipeline, debugging/profiling, และ workflow การพัฒนา
การพัฒนาเครื่องมือเป็นงานที่น่าเบื่อและทำให้หมดแรงได้ง่ายกว่าการพัฒนาเอนจิน
นี่จึงเป็นสาเหตุที่การพัฒนาเกมด้วย custom engine จำนวนมากหยุดชะงักกลางทาง
postmortem: https://ruoyusun.com/2025/04/18/game-sequel-lessons.html
การสร้าง editor ตั้งแต่ศูนย์เป็นงานใหญ่พอสมควร
ถ้าเป็นไปได้ก็ใช้ editor ที่มีอยู่แล้ว
เช่นการจับคู่ TrenchBroom (editor ของ Quake) + func_godot และฝั่ง 2D ก็มี Tiled
สำหรับการจัดการข้อมูลเกมเคยมี CastleDB แต่ตอนนี้ถูกรวมเข้ากับ Hide (editor 3D เต็มรูปแบบ) แล้ว
หลังจากสร้างเครื่องมือเสร็จ การออกแบบเกมและสร้างคอนเทนต์ก็ยังเป็นอีกขั้นหลักอยู่ดี
เมื่อหลายปีก่อนผมเคยทำคลาส "sprite" แบบง่าย ๆ ด้วย SDL2 และ C++ เล็กน้อย แล้วเพิ่มฟีเจอร์พื้นฐานอย่าง collision
ถ้าจะเรียกสิ่งที่ผมทำว่าเอนจิน มันก็เป็นเหมือนตัวช่วยเสริมแบบจักรยานไฟฟ้ามากกว่า
ประเด็นคือบ่อยครั้ง "เอนจิน" กลับกลายเป็นตัวพาโปรเจกต์/เกมทั้งเกม
หลายครั้งเกมต้องปรับตามเอนจิน จึงเป็นเหตุผลว่าทำไมผมถึงหลีกเลี่ยงการใช้เอนจินใหญ่ ๆ อย่าง Unity มาโดยตลอด
สุดท้ายเอนจินพวกนี้ก็มักพาให้ทำโครงสร้างเกมแบบเดิม ๆ ต่างกันแค่ asset
สำหรับผม การเริ่มต้นด้วย SDL ที่มี learning curve สั้นกว่า ดีกว่าเสียเวลาไปกับการเรียนเอนจิน และ SDL ยังเอาไปใช้กับโปรเจกต์ข้ามแพลตฟอร์มอื่นนอกเหนือจากเกมได้ด้วย
เกมของผม: https://store.steampowered.com/app/2318420/Glypha_Vintage/
แม้จะบอกว่าการสร้างเอนจินเองใช้เวลานาน แต่ก็อยากถามว่า ถ้าจะให้เชี่ยวชาญ Unreal หรือ Unity จนสามารถเอาไอเดียไปทำเป็นเกมได้ทันที ต้องใช้เวลามากแค่ไหน
สุดท้ายเมื่อสร้างเอนจินของตัวเองเสร็จ ผมก็จะมีความเชี่ยวชาญระดับนั้นอยู่แล้ว จึงประหยัดเวลาในระยะยาว
ยิ่งมีประสบการณ์ด้านวิศวกรรมมากขึ้น การทำเองก็ยิ่งได้เปรียบในแง่เวลา
ยิ่งเกมมีความเฉพาะทางหรือเป็นตลาดเฉพาะ การทำเองก็ยิ่งสมเหตุสมผล
การไปหลงอยู่กับ UI ซับซ้อนของ Unreal หลายเดือน แล้วเพิ่งรู้ว่าสิ่งที่ต้องการแทบทำไม่ได้ในเอนจินเอนกประสงค์นั้น เป็นประสบการณ์ที่ไม่มีประสิทธิภาพ
ในทางกลับกัน ถ้าเป็นเกมแนว open-world RPG ขนาดใหญ่เหนือจริง การทำเองไม่ใช่ตัวเลือกที่ดี
ข้อจำกัดของ custom engine กลับช่วยกระตุ้นความคิดสร้างสรรค์ และถึงจะไม่ใช่งานระดับสูงสุด ก็อาจได้เกมที่มีเอกลักษณ์มากกว่า
ผมเคยสร้างเอนจินเอง
ตอนแรกใช้เวลาประมาณหนึ่งปี ผ่านการลองผิดลองถูกและทางตันนับไม่ถ้วน
ได้ทำแทบทุก subsystem ที่เห็นในเกม เช่น 3D rendering, adaptive UI, skeletal animation, save files, smart objects, pathfinding, scripting, audio, physics
โดยเฉพาะอย่างยิ่ง ผมทำระบบย้อนเวลาเอง (คล้ายระบบใน Braid)
ฟีเจอร์แบบนี้ต้องการการรองรับจากทุก subsystem ของเอนจิน (script, physics ฯลฯ)
เพราะผมรู้จักทุกส่วนของเอนจินที่สร้างเอง จึงมีอิสระมหาศาลในการพัฒนาฟีเจอร์เพิ่มเติม
แต่หลังจากพัฒนาไปหนึ่งปี ผมก็เริ่ม burnout และหมดแรงจูงใจ
ผมไม่รู้เรื่อง Unreal แต่ Unity ทำให้พัฒนาได้เร็วกว่าเขียนเองมากกว่า 10 เท่า
ฟีเจอร์ physics เพิ่มได้ใน 1 นาที แต่ถ้าทำเอนจินเอง แค่ต่อไลบรารีภายนอกก็อาจกินเวลา 1-2 วัน
ฟีเจอร์ visualization ภายในที่ Noel แสดงให้ดูใน Unreal นั้น Unity ก็มีมาให้ในตัว
การแก้ไขอย่างการจัดการ bounding box ก็มีมาให้เป็นพื้นฐาน
ถ้าพฤติกรรมพื้นฐานของเอนจินยังไม่พอ ก็ขยายได้ง่ายด้วย ImGui หรือ CSS engine บนฐาน Yoga
มีทั้ง particle editor ขั้นสูง, shader ที่ลดความซับซ้อนแล้ว, modular data streaming และฟีเจอร์อีกมากมาย
ในทางทฤษฎีอยากทำเองทั้งหมด แต่สุดท้ายเวลามีจำกัด จึงต้องให้ความสำคัญกับการทำให้เสร็จก่อน
เวลาที่ใช้ในการเรียน Unreal หรือ Unity ให้เอาไอเดียมาทำเป็นเกมได้ทันที กับเวลาที่ใช้สร้างเอนจินเอง เป็นคนละคำถามกัน
แค่ให้ไอเดียเล็กน้อย ก็ทำ prototype ที่เล่นได้ภายในไม่กี่ชั่วโมง
Unity ช่วงแรกต้องเขียนโปรแกรมบ้าง ส่วน Unreal ใช้แค่ Blueprint ก็ไปได้เกือบถึงขั้นพร้อมออกเกมแล้ว
ดูวิดีโอ prototype เกมสไตล์ Super Hexagon เสร็จใน 10 นาที: https://www.youtube.com/watch?app=desktop&v=p8MzsDBI5EI
สิ่งที่เป็นเอกลักษณ์ของ Unity จริง ๆ มีประมาณ prefab ส่วนที่เหลือเป็นแนวคิดทั่วไปของการพัฒนาเกม
ถ้ามองจากฝั่งนักพัฒนา Unreal ก็ทำ prototype คล้ายกันใน Unity ได้ในไม่เกิน 1 ชั่วโมง
สมมติฐานที่ว่า “หลังเอนจินเสร็จแล้ว” อาจไม่สมจริงตั้งแต่ต้น
แม้แต่พฤติกรรมง่าย ๆ อย่าง GameObject.Instantiate ถ้าจะทำเองในเอนจิน ก็ต้องใช้ทรัพยากรมหาศาล
ยิ่งเมื่อคำนึงถึงความซับซ้อนอย่าง physics 2D/3D, shader, การรองรับแพลตฟอร์มต่าง ๆ
ถ้าเป้าหมายคือเอนจิน ก็จงสร้างเอนจิน แต่ถ้าเป้าหมายคือเกม ก็จงสร้างเกม
ถ้ามีความรู้ด้านการพัฒนาเกมมากพอจนสร้างเอนจินเกมได้
การเรียน Unreal หรือ Unity ให้ใช้ทำ prototype ได้ ใช้เวลาแค่วันเดียวก็พอ
การชำนาญแบบสมบูรณ์อาจใช้เวลานาน แต่เวลาในการทำ prototype เกมที่ต้องการนั้นเทียบกันไม่ได้เลย
การสร้างเกมโดยไม่ใช้เอนจินใหญ่แบบ "ทำได้ทุกอย่าง" นั้นง่ายกว่า สนุกกว่า และบางครั้งก็มีประสิทธิภาพกว่าด้วย
แต่พอได้เจาะฟีเจอร์เฉพาะของเอนจิน (เช่น inverse kinematics หรือ animation blending ของ Unreal) ก็จะรู้สึกว่า "ดีแล้วที่ไม่ต้องมานั่งทรมานทำเอง 2-3 สัปดาห์"
ความมินิมอลและการป้องกันการบวมตัวของระบบก็สำคัญ แต่เหตุผลที่เอนจินแบบนี้ได้รับความนิยมก็เพราะมันช่วยแบกงานหนักแทน
เมื่อก่อนผมก็ทำแบบนี้เหมือนกัน
ตอนทำเกม 3D เกมแรก ผมลงมือทำเองทั้ง input, object management, culling, model loading, math library, graphics, normal map, SSAA และอื่น ๆ แต่สุดท้ายความคืบหน้าของตัวเกมจริง ๆ กลับอยู่ที่ 0%
ถึงอย่างนั้น สำหรับโปรเจกต์ 2D งานอดิเรก ผมก็ยังพัฒนาแบบไม่มี dependency โดยใช้แค่ browser canvas
ในทางปฏิบัติก็คือ browser ทำหน้าที่เป็นเอนจิน
ตอบความเห็นที่ว่า “ดีแล้วที่ไม่ได้ทำเอง”
ถ้ามองถึงอาชีพนักพัฒนาอินดี้ในระยะยาว ต่อให้ใช้เวลาหลายสัปดาห์ การเข้าใจอย่างลึกซึ้ง + การเป็นเจ้าของซอร์สโค้ด 100% และมูลค่าการนำกลับมาใช้ซ้ำ ก็ยังมีค่ามากกว่า
วิทยานิพนธ์จบการศึกษาของผมเป็นเรื่องการพอร์ต particle engine บน NeXTSTEP/Objective-C ไปยัง Windows 95/Visual C++ (ใช้ OpenGL และมีตัวอย่าง marching cubes)
ธีมแบบนี้ทุกวันนี้ในเอนจินสมัยใหม่กลับเป็นเพียงส่วนหนึ่งของฟีเจอร์บรรทัดเดียว
การใช้เอนจินช่วยให้โปรเจกต์เดินหน้าได้เร็วขึ้นมาก และไม่ต้องเสียเวลาไปกับการพัฒนาโครงสร้างพื้นฐาน
การสร้างวงล้อขึ้นใหม่อีกครั้งไม่ใช่เรื่องสนุกสำหรับคนส่วนใหญ่
ฟีเจอร์อย่าง inverse kinematics หรือ animation blending
ถ้ามันเป็นแกนหลักของเกม ก็อาจคุ้มที่จะลงมือทำเอง แต่ถ้าไม่ใช่ มันก็เป็นเพียงกับดักทางเทคนิคที่ไม่จำเป็น
ผมทำเกมในแบบของตัวเองด้วย Lua และ Love2D
ความสนุกส่วนหนึ่งอยู่ที่การตั้งข้อจำกัดให้ตัวเอง
ถ้าการพัฒนาเริ่มไม่สนุก นั่นคือสัญญาณว่ามีบางอย่างผิดไป และควรหาวิธีที่ดีกว่า
เกม YOYOZO ของผมมีขนาดแค่ 39KB แต่ก็ได้ติดอยู่ในรายชื่อเกมยอดเยี่ยมแห่งปี 2023 ของ Ars Technica ร่วมกับเกมใหญ่ ๆ
https://news.ycombinator.com/item?id=38372936
หลังจากซื้อ Playdate มาหลายปี ในที่สุดก็เริ่มลองเล่นกับ SDK และกำลังหัด Lua เป็นครั้งแรก
แม้จะคิดถึงระบบ type ที่เข้มงวดและความปลอดภัยทางภาษา แต่สำหรับบริบทนี้มันก็เพียงพอ
ตอนนี้ผมทำได้แค่ tech demo เล็ก ๆ ที่ให้ข้อความหมุนในพื้นที่ 3D ปลอมตาม crank
https://bsky.app/profile/haydenblai.se/post/3lpgnya4cqk2a
ทำโปรเจกต์นี้แล้วเพิ่งรู้ว่าจากประสบการณ์เดิมกับ CRUD/เว็บแอปเมื่อหลายปีก่อน ผมลืมตรีโกณมิติไปแทบหมดแล้ว
ข้อดีสูงสุดของการพัฒนาบน Playdate คือ canvas ตายตัว ทำให้แค่กำหนดตำแหน่งพิกเซลก็แน่ใจได้ว่าจะทำงานเหมือนกันทุกเครื่อง ซึ่งให้ความรู้สึกเป็นอิสระมาก
ก่อนหน้านี้ผมทำแต่ responsive UI มาตลอด ประสบการณ์แบบนี้จึงสดใหม่มาก
ทุกครั้งที่พยายามสร้างอะไรด้วย game engine (Godot, Unity, Unreal ฯลฯ) ผมมักต้องต่อสู้กับตัวเอนจินเอง
สุดท้ายมันให้ความรู้สึกเหมือนเอา asset ไปวางทับบนรูปแบบเกมที่ถูกกำหนดไว้แล้ว ทำให้สร้างเกมแบบที่ตัวเองต้องการได้ยาก
ถ้าเปรียบกับเว็บ ก็เหมือนของสำเร็จรูปอย่าง WordPress
เมื่อโครงสร้างพื้นฐานไม่ตรงกับเจตนาเดิม ก็ต้องอาศัยการแฮ็กและทางอ้อมจำนวนมาก
และสิ่งที่เติมเชื้อไฟให้เรื่องนี้ก็คือ "game templates"
คุณสามารถซื้อ template ที่แค่เปลี่ยน title screen กับ model ก็ดูเหมือนเกมเสร็จสมบูรณ์แล้ว
เกมใหม่บน Steam เกือบครึ่งหนึ่งแทบเป็นแค่เกมจาก template ของ Unity/Unreal ที่เปลี่ยน skin เล็กน้อย
ตัวอย่างต่าง ๆ:
https://assetstore.unity.com/packages/templates/…
https://store.steampowered.com/app/2488370/Cash_Cleaner_Simulator/
https://store.steampowered.com/app/2073910/A_Webbing_Journey/
https://store.steampowered.com/app/3498270/Better_Mart/
https://store.steampowered.com/app/2625420/Drive_Beyond_Horizons/
https://store.steampowered.com/app/3163790/Toy_Shop_Simulator/
https://store.steampowered.com/app/3023600/Horse_Farm_Simulator/
https://store.steampowered.com/app/3124550/Liquor_Store_Simulator/
บน Google Play เกมทุกเกมดูคล้ายกันไปหมด และยังมีปัญหาเฉพาะแบบ Unity เช่น โหลดนาน ปัญหาเรนเดอร์ ตัวอักษรเพี้ยน บั๊กเสียง ฯลฯ
ถ้าเป็นเกม "idle RPG" สำหรับโฆษณาบนมือถือ เรื่องแบบนี้อาจพอรับได้ แต่ในวงการ VR ผมไม่ค่อยเข้าใจเลยว่าทำไมถึงยังใช้ Unity กัน
ถ้าจะให้ผ่านเกณฑ์ประสิทธิภาพของ Meta Quest Store ต้องรื้อหลายส่วนของ Unity engine ทิ้ง
มันทั้งปรับจูนประสิทธิภาพยาก และวิธีทำงานก็ล้าสมัย
ถ้าคุณอยากสร้างซอฟต์แวร์คุณภาพสูง ก็เป็นไปไม่ได้ที่จะเริ่มจากเอนจินที่ไว้ใจไม่ได้
ผู้เขียน (Noel) คือคนที่สร้างเกม Celeste ซึ่งขายได้มากกว่า 3 ล้านชุด
https://en.wikipedia.org/wiki/Celeste_(video_game)
ผมเองก็เห็นด้วยในหลายส่วน และกำลังสร้างเฟรมเวิร์กเกม C# แบบเน้นโค้ดอยู่ (เป็นผู้สืบทอดทางจิตวิญญาณของ XNA/Monogame โดยใช้ Sokol แทน SDL)
https://zinc.graphics/
จุดแข็งของ C# สมัยใหม่: cross-platform, NativeAOT compilation, native hot reloading, reflection ฯลฯ
ส่วนตัวผมยังเพิ่ม source generator เข้าไปด้วย
แม้ภาพลักษณ์แย่ในอดีตจะยังหลงเหลืออยู่ แต่พัฒนาการของ CoreCLR และตัวภาษาในช่วง 5 ปีหลังนั้นน่าทึ่งมาก
มีเพียงอย่างเดียวที่ผมยังอยากได้คือ Union Types ซึ่งตอนนี้มี proposal แล้ว และหวังว่าจะเพิ่มเข้ามาในปีหน้า
https://github.com/dotnet/csharplang/blob/main/proposals/TypeUnions.md
ผมเคยใช้ C# แค่กับ Win32 หรือ Unity และแม้จะมีความรู้เอนจินระดับล่างฝั่ง C/C++ อยู่บ้าง แต่เคยคิดมาตลอดว่า C# คงใช้ข้ามแพลตฟอร์มอย่างเกมคอนโซลไม่ได้
ตอนนี้ผมเพิ่งรู้ว่าที่คิดมานั้นผิด
ไม่ว่าจะเป็นซอฟต์แวร์แบบไหน ผมมักชอบเริ่มจากศูนย์
สำหรับคนที่มีประสบการณ์กับโปรเจกต์ใหญ่ มันอาจดูช้า แต่ในช่วงเริ่มต้นแบบสตาร์ตอัปกลับเร็วกว่า
ทำแค่สิ่งจำเป็นขั้นต่ำ และเมื่อมี abstraction แล้ว ความเร็วในการเพิ่มฟีเจอร์ใหม่จะยิ่งสูงขึ้น
ซอฟต์แวร์องค์กรขนาดใหญ่กับมินิเอนจินที่ผมเขียนเองนั้นให้ productivity ต่างกันโดยสิ้นเชิง
โค้ดที่เขียนเองตัดทิ้งและ refactor ได้ทันที จึงเร็วกว่าเยอะ
ด้วยเหตุนี้ผมจึงชอบทั้ง microservices และทีมขนาดเล็ก
แน่นอนว่าเมื่อทำเอง คุณต้องผ่านทั้งการลองผิดลองถูกและกับระเบิดที่พร้อมพังเสมอ อีกทั้งยังต้องใช้เวลาหลายปีกว่าจะเข้าใจธรรมชาติที่แท้จริงของภาษาและแพลตฟอร์ม
แต่ท้ายที่สุด กระบวนการนั้นเองก็กลายเป็นวิชาฝีมือที่ติดตัวนักพัฒนา
ไม่ใช้เอนจิน แล้วใช้แค่เฟรมเวิร์กระดับ MonoGame แทนจะเป็นยังไงบ้าง ผม/ฉันสงสัยอยู่ครับ/ค่ะ~
"กระบวนการนั้นเองสุดท้ายก็จะกลายเป็นประสบการณ์สั่งสมของนักพัฒนา" เห็นด้วยอย่างยิ่งครับ