Core เทคโนโลยีใหม่เชิงทดลองสำหรับการสร้างวิดีโอเกม

 (github.com/damn)
2 คะแนน โดย GN⁺ 2024-09-09 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

  • coreCore คืออะไร

    • coreCore คือวิธีเชิงทดลองในการสร้างวิดีโอเกมในรูปแบบเครื่องมือและเอนจินสำหรับสร้างเกม Action-RPG รวมถึงตัวแก้ไขคุณสมบัติ
    • ใช้ระบบคอมโพเนนต์แบบเรียบง่าย โดยคอมโพเนนต์อยู่ในรูปเวกเตอร์ clojure แบบ [keyword value]
    • เอนทิตีหลากหลายชนิดประกอบขึ้นจากแมปของ clojure
    • ผลข้างเคียงภายในเกมถูกจัดการด้วยคอมโพเนนต์อย่าง [:tx/foo param] ซึ่งมีโครงสร้างคล้าย datomic
    • สถานะทั้งหมดของเกมถูกเก็บไว้ใน atom เดียวชื่อ app/state และเอนทิตีก็อยู่ในรูป atom ภายใน atom หลักเช่นกัน
    • เนื้อหาทั้งหมดของแอปพลิเคชันถูกเก็บไว้ใน resources/properties.edn ผ่านการตรวจสอบด้วย malli-schemas และสามารถแก้ไขผ่าน GUI ได้

  • ภาพหน้าจอ

  • วิธีเริ่มพัฒนา

    • ป้อนคำสั่งต่อไปนี้:
      • lein dev
    • แอปพลิเคชันจะเริ่มทำงานและดำเนินการต่อไปนี้ด้วย:
      • เริ่มต้นเซิร์ฟเวอร์ NREPL
      • เมื่อปิดแอปพลิเคชัน (กด ESC จากเมนูหลัก) clojure.tools.namespace จะรีเฟรชไฟล์ที่เปลี่ยนแปลงและเริ่มแอปใหม่
      • หากเกิดข้อผิดพลาด ไม่จำเป็นต้องรีสตาร์ต JVM เพียงแก้ข้อผิดพลาดแล้วเรียก dev-loop/restart!
      • สามารถผูกคำสั่งต่อไปนี้กับปุ่ม F5 ใน VIM เพื่อใช้งานได้: nmap <F5> :Eval (do (in-ns 'dev-loop)(restart!))

  • ใบอนุญาตโค้ด

    • ให้ใช้งานภายใต้ใบอนุญาต MIT

  • ใบอนุญาตของแอสเซ็ต

    • แอสเซ็ตที่ใช้เป็นแบบกรรมสิทธิ์และไม่ใช่โอเพนซอร์ส

สรุปโดย GN⁺

  • coreCore เป็นเครื่องมือที่ช่วยให้สร้างเกม Action-RPG ได้ง่าย โดยใช้ระบบคอมโพเนนต์แบบเรียบง่ายเพื่อจัดการสถานะของเกม
  • การเก็บสถานะทั้งหมดของเกมไว้ใน atom เดียว และการแก้ไขคุณสมบัติผ่าน GUI ทำให้มีประโยชน์ต่อผู้พัฒนา
  • แม้จะให้ใช้งานภายใต้ใบอนุญาต MIT แต่แอสเซ็ตที่ใช้เป็นแบบกรรมสิทธิ์
  • เครื่องมือที่มีความสามารถคล้ายกันได้แก่ RPG Maker และ Unity

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-09-09
ความคิดเห็นบน Hacker News

  • เจ๋งดี ถึงจะไม่เคยปล่อยเกมเอง แต่ผมชอบดู แนวทางที่แตกต่างกัน ในการพัฒนาเกมเสมอ
    เท่าที่ผ่านมา Bevy ช่วงแรกดูดี แต่มีปัญหาในการใช้งานจริงเยอะและอาจเละเทะได้ ส่วน Unity ด้วยแนวทาง gameobject กับคอมโพเนนต์แบบประกอบกัน ถือว่าใช้งานได้จริงที่สุด เอนจินไม่เข้ามาขวาง และหลีกเลี่ยงสปาเกตตีได้ง่าย
    ผมไม่ชอบ Godot โครงสร้างลำดับชั้นแบบ OOP ที่ไม่ดี ภาษาในตัวที่ไม่ค่อยดี และ “signals” ที่ตั้งใจจะลดสปาเกตตีกลับทำให้เพิ่มขึ้นอีก Pygame ค่อนข้างดีสำหรับโปรเจกต์เล็ก ๆ และเราสามารถวางชั้น OOP หรือ functional ของตัวเองทับบนฐานแบบ procedural ได้
    ผมไม่รู้จัก Clojure แต่ก็น่าสนใจที่พยายามทำ การใช้งานจริงแบบ functional ในโดเมนที่โดยทั่วไปดูเหมาะกับ OOP

    • ในฐานะนักพัฒนาเกมมืออาชีพที่เคยทำผลิตภัณฑ์จริงด้วยทั้ง Unity และ Godot ผมแทบไม่เห็นด้วยเลยกับการประเมิน Godot และ Unity แบบนั้น
      signals ของ Godot เป็นความก้าวหน้าครั้งใหญ่เมื่อเทียบกับการขาดความเป็นโมดูลของคลาสในตัวของ Unity โดยพื้นฐานแล้ว Godot กับ Unity มีโมเดล scene/node/component เหมือนกัน แต่ผมว่า Godot ทำได้ดีกว่า
      ข้อดีของ Unity คือเรนเดอเรอร์ 3D, PhysX ในตัว, แบ็กเอนด์ il2cpp สำหรับ C#, profiler, ประสิทธิภาพการทำงานโดยรวม และการรองรับคอนโซล ในทางกลับกัน การออกแบบของ Godot มีความเป็นหนึ่งเดียวกันมากกว่า ส่วน Unity ตั้งแต่ราวปี 2018 เหมือนแตกออกไป 10 ทิศทาง
    • ผมไม่ใช่นักพัฒนาเกม แต่ การออกแบบเชิงวัตถุของ Godot ถือว่าค่อนข้างดีในบรรดาที่ผมเคยใช้
      ช่วงนี้ผมทำ C++ ฝั่ง embedded เลยไม่ได้ใช้ OOP มากนัก แต่ผมเรียนเขียนโปรแกรมด้วย C# จึงคุ้นกับ inheritance อยู่พอสมควร
    • Godot ยอดเยี่ยม และผมคิดว่าอีกสัก 5 ปีมันจะกลายเป็น Blender ของการสร้างเกม เวอร์ชัน 4 ใช้งานจริงได้ และรองรับโปรเจกต์อินดี้ส่วนใหญ่ได้
      พื้นที่ที่ Unity ยังนำอยู่คือระดับ “Triple I” และ “Double A” เพราะฟีเจอร์ 3D/ประสิทธิภาพ เครื่องมือ และแอดออนดีกว่า สำหรับโปรเจกต์ AAA ทั้งคู่ก็ไม่ใช่ตัวเลือกที่ดีที่สุด
      สำหรับเกม 2D และเกม 3D แบบเรียบง่าย ตอนนี้ดูเหมือนไม่มีเหตุผลให้ใช้ Unity แล้ว และผมคิดว่า Godot จะค่อย ๆ แซงหน้า ขณะที่ส่วนแบ่งของ Unity จะลดลงอย่างต่อเนื่อง
    • ในฐานะนักพัฒนาเชิงพาณิชย์ เมื่อก่อนผมใช้ Unity และตอนนี้ใช้ Godot ผมเห็นด้วยกับคำวิจารณ์เรื่อง GD Script และ signals และผมหลีกเลี่ยงด้วยการใช้ การจัดการ event ของ C#
      สิ่งที่น่าหงุดหงิดที่สุดคือ node กับสิ่งต่าง ๆ ใน editor ที่ไม่รู้ว่าเป็นบั๊กหรือฟีเจอร์กันแน่ และรู้สึกชัดมากว่าเดิมทีมันถูกทำขึ้นสำหรับโปรเจกต์ “เล็ก”
      ดังนั้นผมแทบไม่ใช้ editor นอกจากจัดองค์ประกอบของ scene และตั้งลำดับชั้นแบบคร่าว ๆ เครื่องมือที่ใช้ประจำคือ Emacs+C# LSP, ใช้ VS Code สำหรับดีบัก และใช้ Godot editor สำหรับปรับ scene tree
    • ผมเคยใช้ Godot ค่อนข้างจริงจัง และมีเหตุผลให้ไม่ชอบมันอยู่ แต่ผมว่า GDScript ไม่ใช่เหตุผลนั้น
      โดยพื้นฐานมันคือ Python ที่ใส่ semantics แบบ slot/emit แล้วผสานกับ editor ซึ่งกลับถือว่าโอเค ดีกว่าวิธีซับซ้อนที่ต้องผสานผ่าน build system, metadata และไฟล์ตั้งค่าภายนอก ให้สิ่งเหล่านี้อยู่ในภาษาน่าจะดีกว่า

  • บอกว่าสามารถทำให้การพัฒนาเกมเรียบง่ายขึ้นได้ แต่กลับโยนศัพท์เฉพาะมาเพียบอย่าง Clojure vectors, datomics, atoms, transactions, malli schemas ใครอธิบายได้ไหม?

    • ถ้าขัดเกลาคำแนะนำให้เข้าใจง่าย Core คือเครื่องมือทดลองที่พยายามทำให้ การสร้างแอ็กชัน RPG เรียบง่ายขึ้น
      มันแสดงองค์ประกอบและคุณสมบัติของเกมเป็นโครงสร้างข้อมูลง่าย ๆ และเก็บสถานะทั้งหมดของเกมไว้ในคอนเทนเนอร์เดียว (app/state) เพื่อให้จัดการและอัปเดตได้ง่าย
      อีกทั้งยังมี GUI สำหรับแก้ไขคอนเทนต์เกมที่เก็บไว้ในไฟล์เดียว (resources/properties.edn) ทำให้คนที่ไม่ใช่โปรแกรมเมอร์เข้าถึงได้ง่ายขึ้น และใช้สคีมา Malli เพื่อตรวจสอบข้อมูล โดยตั้งเป้าให้คอนเทนต์สอดคล้องกันและลดข้อผิดพลาด
    • พูดอย่างเป็นธรรม เขาแค่ถามว่าการพัฒนาเกมสามารถทำให้ง่ายขึ้นได้ไหม คำตอบน่าจะมีแนวโน้มว่า “ไม่ได้”
    • วลีที่ต้องแนบมาด้วยเสมอคือ “ความเรียบง่ายไม่เท่ากับความง่าย”: https://www.youtube.com/watch?v=SxdOUGdseq4
      Clojure vector โดยพื้นฐานแล้วใกล้เคียงกับ list ส่วน atom คือ reference ที่เปลี่ยนค่าได้ซึ่งชี้ไปยังโครงสร้างข้อมูลแบบ immutable และมองได้เหมือน pointer ที่มี semantics การอัปเดตเฉพาะ
      transaction คล้ายกับ database transaction คือเปลี่ยนโครงสร้างข้อมูลหลายอย่างพร้อมกัน โดย commit ก็ต่อเมื่อทุกงานสำเร็จ และถ้าล้มเหลวก็ rollback หรือ retry
      Malli schema คือวิธีทำ type checking ในภาษา dynamic typing ส่วน Datomic คือ implementation ของฐานข้อมูลแบบไม่ใช่ SQL บนพื้นฐานโครงสร้างข้อมูล immutable ที่ไม่เขียนทับการเปลี่ยนแปลงแบบทำลายข้อมูลเดิม แต่จะเพิ่มเข้าไปเท่านั้น ทำให้ย้อนกลับไปดูช่วงเวลาใดในอดีตก็ได้
    • ภาษา Clojure มี โมเดลการจัดการสถานะ ในตัว และโปรเจกต์นี้เป็นความพยายามที่จะนำโมเดลนั้นมาใช้กับการพัฒนาเกม
      ผมคิดว่าวิธีที่ดีที่สุดในการเรียนรู้โมเดลนี้คือดูทอล์ก “Are we there yet” ของ Rich Hickey ผู้สร้าง Clojure
    • Clojure vector เป็นโครงสร้างข้อมูลในตัวของภาษา และมีหน้าตาแบบ [1 2 3]
      ผมใช้มันเพื่อประกอบ side effect เช่น [:tx/foo 3] และเรียกสิ่งนี้ว่า transaction คล้ายกับ Datomic ตรงนี้ :tx/foo คือ keyword และระบุพฤติกรรมของคอมโพเนนต์แบบไม่ซ้ำกัน

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

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

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

    • ถ้าอย่างนั้นมันไม่ค่อยเข้ากับไซต์นี้หรือเปล่า? โดยรวมแล้ว Hacker News เป็นที่ที่พูดถึงไอเดียใหม่ ๆ ที่น่าสนใจ ไม่ใช่ที่ที่พูดแค่การปรับปรุงแบบค่อยเป็นค่อยไปของ C++ กับ Unity
      ผมนึกถึงเกมได้หลายเกมที่ออกมาจากความหมกมุ่นเชิงวิชาการแปลก ๆ แบบนี้ Jonathan Blow ในคอมเมนต์พี่น้องก็ด้วย และพอเห็นโปรเจกต์นี้ผมนึกถึง Braid ทันที
      การสร้างแบบ procedural generation เมื่อก่อนก็เคยเป็นหัวข้อในหอคอยงาช้าง และความก้าวหน้าทุกอย่างของกราฟิก 3D ก็เริ่มจากเปเปอร์วิชาการที่ดูเป็นไปไม่ได้โดยสิ้นเชิงในตอนแรก หลายอย่างที่เป็นกระแสหลักในเกมตอนนี้ ครั้งหนึ่งก็เคยเป็นไอเดียเชิงวิชาการเฉพาะกลุ่มมาก่อน
    • ผมไม่คิดว่าสกรีนช็อต “น่าเกลียด” แต่เห็นด้วยว่า README ใช้งานจริงแทบไม่ได้ ไม่มีเอกสาร ไม่มีตัวอย่าง และไม่มีคำอธิบายว่าทำไมควรใช้มัน
      มันล้มเหลวตั้งแต่ขั้นพื้นฐานในการสื่อว่ามันทำอะไร
    • การสร้างอะไรที่กระตุ้นความคิดทางปัญญาก็มีคุณค่า ต่อให้ใช้เวลา 100 ชั่วโมงสร้าง datomics แบบ Clojure แล้วสร้างคอนเทนต์เลเวลได้แค่ 1 ชั่วโมง แต่ 1 ชั่วโมงก็ยังมากกว่า 0 ชั่วโมง
      ถ้าไม่อย่างนั้นจะเบื่อจนไม่ได้สร้างอะไรเลย แบบนี้กลับถือว่าได้กำไร คล้ายกับ ตรรกะที่ Jonathan Blow ใช้ Jai ในการพัฒนาอินดี้
    • เขาก็เขียนไว้อยู่ว่าเป็นงานทดลอง

  • น่าแปลกที่เอกสารของ repository นี้มีน้อยขนาดนี้แต่กลับมีบทสนทนาออกมาค่อนข้างเยอะ ดูจากโค้ดแล้วมันดูเหมือนเป็นโปรเจกต์มากกว่า game engine
    property editor น่าสนใจ แต่ผมว่าโพสต์นี้ได้รับการโหวตเพราะชื่อเรื่องมากกว่าเนื้อหา

  • ดีเลย ดีใจที่ได้เห็นนักพัฒนาแบบผมที่ พัฒนาเกมด้วย Clojure ถึงบางครั้งจะทำให้ชีวิตตัวเองยากขึ้นก็ตาม :)
    ตอนนี้กำลังพัฒนาเกมยิง TPS มัลติเพลเยอร์ 3D ด้วย Clojure อยู่ ถ้าสนใจ เดโมอยู่ที่นี่: https://prototype-game.pages.dev
    เร็ว ๆ นี้จะลงบล็อกโพสต์เกี่ยวกับเส้นทางการพัฒนาด้วย

    • ช่วงเวลาที่หลายคนเข้าไปในพื้นที่เสมือน วิ่งเล่นกันแบบฉับพลัน และใช้แชตในเกม เป็นหนึ่งในภาพบนอินเทอร์เน็ตที่ผมชอบที่สุด

  • ผมชอบ Clojure นะ แต่ภาษาเชิงฟังก์ชันที่ใช้ โครงสร้างข้อมูลแบบไม่เปลี่ยนรูป ไม่ใช่ตัวเลือกที่แปลกไปหน่อยสำหรับการพัฒนาเกมวิดีโอเหรอ?

    • เป็นไปได้อย่างแน่นอน และมี trade-off ที่น่าสนใจ
      นี่คือบทความที่ผมชอบเกี่ยวกับการพัฒนาเกมเชิงฟังก์ชัน:
      https://prog21.dadgum.com/228.html
      https://prog21.dadgum.com/23.html
      https://prog21.dadgum.com/24.html
      https://prog21.dadgum.com/25.html
      https://prog21.dadgum.com/26.html
    • รู้สึกค่อนข้างเป็นธรรมชาติเลย เพราะ Clojure อยู่บน JVM โปรเจกต์นี้จึงใช้ libgdx ภายใน สามารถ deploy ไปได้ทุกแพลตฟอร์ม และมีไลบรารีขนาดใหญ่
      ที่เหลือก็ใช้ Lisp ทำได้แทบทุกอย่าง วิธีที่ Clojure จัดการโครงสร้างข้อมูลแบบไม่เปลี่ยนรูป และระบบ protocol ที่ยอดเยี่ยม (https://www.freshcodeit.com/blog/clojure-protocols-and-the-e...) ทำให้แยกทั้งเกมออกเป็นคอมโพเนนต์ต่างหากได้ง่าย
    • Tim Sweeney ก็ดูเหมือนจะเดิมพันไปทางนั้นผ่าน Verse ใน UEFN เหมือนกัน Verse ค่อนข้างเหมือนการทำให้ Haskell เข้าถึงได้ง่ายขึ้น
    • ก็ไม่ได้แปลกขนาดนั้น เกม AA หรือ AAA ถัดไปคงไม่ใช้ แต่แม้ในโดเมนที่มีปฏิสัมพันธ์สูงมากอย่าง reducer ของ React หรือ Redux ก็เห็น immutability กันบ่อย
      Clojure มีศักยภาพด้านประสิทธิภาพดีกว่า Ruby หรือ Python และทั้งสองภาษานั้นก็เคยถูกใช้จริงในเกมอินดี้เชิงพาณิชย์มาแล้ว
    • Functional programming แทบไม่เคยถูกลองใช้อย่างจริงจังในการพัฒนาเกมเลย วงการพัฒนาเกมกับแวดวงวิชาการมีส่วนทับซ้อนกันน้อย
      สตูดิโอย่อมหลีกเลี่ยงความเสี่ยง และชอบกลยุทธ์ที่คุ้นเคยอย่าง object-oriented หรือใช้ ECS กับฝูงจำนวนมาก
      โดยส่วนตัวผมมองว่า functional programming อาจเข้ากันได้ดี แต่ต้องหา architecture ที่แก้ปัญหาการพัฒนาเกมจริง ๆ ให้ได้ก่อน ควรเริ่มจากการทดลองเล็ก ๆ และ game jam ก็เหมาะกับเรื่องนี้พอดี

  • มีแพลตฟอร์มสร้างเกมเชิงพาณิชย์ชื่อ Core ที่ทำงานบน Unreal Engine 4 อยู่แล้ว
    https://en.wikipedia.org/wiki/Core_(video_game)

  • น่าจะเลือกชื่อผิดแล้ว ชื่อนี้ถูกใช้ในสายนี้อยู่แล้ว: https://www.coregames.com/create

    • ผมก็นึกถึงอันนั้นเป็นอย่างแรกเหมือนกัน โดยเฉพาะเพราะฝั่งนั้นคือการสร้างเกมภายในเกม จึงอาจมองว่าเป็นวิธี “ใหม่” ในการเขียนเกมได้ด้วย

  • ถ้าวิเคราะห์ข้อมูล “เวลา/ความซับซ้อนที่ทุ่มให้ game engine” กับ “ความซับซ้อน/ความน่าสนใจของเกมที่ออกมา” น่าจะน่าสนใจ
    ในฐานะนักพัฒนาเกม ผมคาดว่าผลตอบแทนของเกมใหม่ ๆ ที่ออกมาจากระบบ template/engine แบบเรียบง่ายจะเป็น เส้นโค้งลอการิทึมที่ให้ผลตอบแทนลดลง
    กล่าวอีกอย่างคือ ยิ่งคุณทำให้เครื่องปั๊มคุกกี้ดีขึ้นเท่าไร ความหลากหลายของคุกกี้ก็ยิ่งลดลง