Tramway SDK – การผสานอย่างนอกรีตของเอนจิน Half-Life และ Morrowind

• Tramway SDK คือแพ็กเกจกราฟิก/เฟรมเวิร์ก/เอนจินเกมที่พัฒนามาตลอด 3 ปีที่ผ่านมา โดยมุ่งเป็นเอนจินน้ำหนักเบาที่ต่อต้านความต้องการสเปกสูงและเวิร์กโฟลว์แบบเอดิเตอร์โมโนลิธิกของเอนจินกระแสหลัก
• มองว่าเอนจินกระแสหลักอย่าง Unity และ Godot ต้องการฮาร์ดแวร์เกินความจำเป็นแม้สำหรับเกม low-poly เรียบง่าย จึงตั้งเป้ารองรับการทำงานบน ฮาร์ดแวร์ในช่วง 15 ปีล่าสุด รวมถึงการเรนเดอร์แบบซอฟต์แวร์แรสเตอร์ไรซ์ด้วย
• วิธีสร้างคือเขียนโค้ดด้วยการ สืบทอดคลาส Entity แทนการสลับไปมาระหว่าง GUI แบบโหนดกับโค้ด และเลือกใช้เฉพาะเอดิเตอร์ที่จำเป็น
• การสร้างเลเวลอิงเวิร์กโฟลว์แบบบรัชของ Quake โดยใช้ตัวแปลง .map, lightmap, Gouraud shading และระบบ input/output แบบ Source
• แม้จะมุ่งสู่ open-world streaming และเฟรมเวิร์ก RPG ที่ใกล้เคียง 3D RPG Maker แต่ยังอยู่ใน ช่วงพัฒนาเริ่มต้น จึงต้องเผื่อใจเรื่อง API ที่ยังไม่เสถียรและส่วนที่ยังไม่ได้พัฒนา

---

ปัญหาที่ Tramway SDK ต้องการแก้

• Tramway SDK เป็นทั้งแพ็กเกจกราฟิก เฟรมเวิร์ก และเอนจินเกม และยังใช้การสะกดสไตล์ heavy metal ว่า “T̈ra̦m̊ẅa̦ÿ SD̈K” ด้วย
• คำวิจารณ์ต่อเอนจินกระแสหลักมุ่งไปที่ Turbobloat
  • มองว่า Unity ต้องการฮาร์ดแวร์ที่แรงมากและใช้พลังงานมาก
  • มองว่า Godot ดีกว่า Unity เล็กน้อย แต่ก็ยังต้องการฮาร์ดแวร์ที่มีสมรรถนะพอสมควร
  • เชื่อว่าเกมอย่าง low-poly horror roguelite deckbuilder simulator ควรจะรันได้สบายบนฮาร์ดแวร์อายุ 15 ปี
• Tramway SDK ระบุว่าสามารถรันได้บน ฮาร์ดแวร์แทบทุกชนิดในช่วง 15 ปีล่าสุด เพราะไม่มี Turbobloat
  • สามารถสลับไปใช้ ซอฟต์แวร์แรสเตอร์ไรซ์ เพื่อให้ทำงานได้แม้ไม่มีการ์ดจอ
  • ยกตัวอย่างไปถึงอุปกรณ์อย่างเครื่องปิ้งขนมปังหรือ ตู้เย็นที่แสดงกราฟิกได้
• ต่อข้อโต้แย้งแบบ “ก็ซื้อคอมที่ดีกว่าสิ” มีการโต้กลับด้วยเหตุผล 3 ข้อ
  • ปัญหาเรื่อง ความสามารถในการซื้อหา เพราะหลายคนไม่มีงบสำหรับฮาร์ดแวร์แรง ๆ
  • ปัญหา ขยะอิเล็กทรอนิกส์ เพราะการผลิตชิปคอมพิวเตอร์ส่งผลเสียต่อสิ่งแวดล้อม และถ้าซอฟต์แวร์ไม่พองโตเกินจำเป็น ก็เพียงซื้อฮาร์ดแวร์ใหม่เมื่อของเดิมเสียและซ่อมไม่ได้
  • มองว่าเมื่อมีคอมพิวเตอร์ที่ยังทำงานได้ดีอยู่แล้ว ก็ไม่มีเหตุผลต้องซื้อเครื่องใหม่เพียงเพราะ Turbobloat ของคนอื่น

วิธีสร้างและฟีเจอร์

• วิธีสร้างแบบโหนดถูกวิจารณ์ว่าเป็นการจัดการกับ “หลายสิ่งที่ดูเหมือนเป็นสิ่งเดียว” และบังคับให้ต้องสลับไปมาระหว่าง GUI แบบโหนดกับโค้ด
• ใน Tramway SDK สามารถเขียนโค้ดโดย สืบทอดคลาส Entity แล้วจึงสร้างเลเวลด้วยเอดิเตอร์เลเวล
  • ไม่ใช้โหนด แต่จัดโครงสร้างแบบยึดเอนทิตีเป็นศูนย์กลาง
  • หลีกเลี่ยงเวิร์กโฟลว์ที่ต้องสลับไปมาระหว่างโค้ดกับ GUI แบบโหนด
• ยังมองว่า เอดิเตอร์แบบโมโนลิธิก ของเอนจินกระแสหลักเป็นปัญหา
  • ต้องรอให้ทั้งเอดิเตอร์โหลดขึ้นมาพร้อมฟีเจอร์ทั้งหมดแม้จะไม่ได้ใช้
  • เอดิเตอร์ของ Tramway SDK ทุกตัวเป็นแบบเลือกใช้ได้
  • หากต้องการใช้แค่เฟรมเวิร์ก ก็ใช้เพียง C++ runtime ได้
  • หากต้องการแค่สร้างเลเวล ก็ใช้เฉพาะเอดิเตอร์เลเวลได้
  • ไฟล์ข้อมูลเป็นรูปแบบค่าคั่นด้วยช่องว่าง จึงสามารถแก้ด้วยมือได้แม้ไม่มีเอดิเตอร์
• ในด้านกราฟิก ระบุว่าสามารถสร้างภาพตัวอย่างได้ด้วยเพียง lightmap และ Gouraud shading
  • ตัวอย่างดังกล่าวสามารถเรนเดอร์ได้แม้บน fixed-function pipeline ของการ์ดจอระดับ Direct3D 7
• การสร้างเลเวลรองรับเวิร์กโฟลว์แบบบรัชตามสาย Quake
  • Tramway SDK มีตัวแปลงไฟล์ .map ที่จะแปลงบรัชเป็น triangle mesh
  • แสดงเวิร์กโฟลว์ที่สร้างเลเวลใน Trenchbroom แล้วไปตั้งค่าต่อในเอดิเตอร์เลเวลของ Tramway SDK
  • เอนจินจะเรนเดอร์เลเวลพร้อม lightmap ภายในระบบ
  • สามารถตั้งค่าปฏิสัมพันธ์ระหว่างเอนทิตีในเลเวลได้ด้วย ระบบ input/output ที่คล้าย Source
  • ในอนาคตมีแผนจะทำ Source logic entity ให้ครบทั้งหมด เพื่อให้ทำ visual scripting ได้ภายในเอดิเตอร์เลเวล
• ในฝั่ง RPG มองว่าเครื่องมืออย่าง RPG Maker และม็อดหรือ total conversion บนฐาน Morrowind เป็นกรณีที่น่าสนใจ เพราะสามารถสร้างสิ่งต่าง ๆ ได้มากมายด้วยการเปลี่ยนข้อมูล
  • Tramway SDK มีส่วนขยาย เฟรมเวิร์ก RPG ที่ใกล้เคียงกับ RPG Maker สำหรับ 3D
  • เอนจินถูกออกแบบให้รองรับ level streaming มาตั้งแต่ต้น จึงมองว่าสามารถทำเกมสไตล์ RPG แบบ open world ได้รวดเร็วและง่ายขึ้น
• โดยสรุป Tramway SDK คือเอนจินเกมแบบยึดเอนทิตีเป็นศูนย์กลางในสไตล์ Quake/Source พร้อมส่วนขยายแบบเลือกใช้ได้ เช่น open-world streaming และเฟรมเวิร์ก RPG
• สถานะการพัฒนายังอยู่ในระยะเริ่มต้นมาก
  • API ยังไม่เสถียร
  • ฟีเจอร์บางอย่างอาจพังหรือยังทำงานไม่ได้
  • ยังมีหลายส่วนที่ไม่ได้พัฒนา
  • ผู้พัฒนาระบุว่ากำลังปรับปรุงอย่างรวดเร็ว
• GitHub repository: racenis/tram-sdk

[GN⁺]

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

• อาจมีคนพูดว่า “ก็แค่ซื้อคอมพิวเตอร์ที่ดีกว่าเดิมสิ” แต่ผมเห็นด้วยอย่างยิ่งว่าการต้องซื้อคอมพิวเตอร์ที่ดีกว่าเดิมเพราะแบบนั้นเป็นเรื่องแย่ ผู้คนจำนวนมาก โดยเฉพาะคนในประเทศกำลังพัฒนา ไม่มีเงินพอจะซื้อฮาร์ดแวร์มารัน Turbobloat และการผลิตชิปก็ส่งผลเสียต่อสิ่งแวดล้อมอย่างมาก
  ถ้าซอฟต์แวร์ยุคใหม่ไม่บวมเทอะทะขนาดนั้น เราก็คงซื้อเครื่องใหม่ก็ต่อเมื่อฮาร์ดแวร์เดิมเสียและซ่อมไม่ได้เท่านั้น ถ้ามีคอมพิวเตอร์ที่ยังทำงานได้ดีอยู่ ก็ไม่มีเหตุผลต้องซื้อเครื่องใหม่เพราะซอฟต์แวร์บวม ๆ ของคนอื่น และเงินก้อนนั้นอาจเอาไปซื้อ Dr. Pepper ได้ 1,000 กระป๋องด้วยซ้ำ เป็นโปรเจกต์ที่ดีมากจริง ๆ หวังว่าจะอัปเดตความคืบหน้าให้ดูต่อไป

  • บอกว่า “ความละเอียดหน้าจอตั้งแต่ 320x200 ถึง 800x600” ก็จริง แต่ความละเอียดที่สูงกว่านั้นไม่ได้ถูกคิดค้นขึ้นมาเพราะ Turbobloat อย่างเดียวเสียหน่อย
  • พูดแบบนั้นก็จริง แต่ดูเหมือนเอนจินจะต้องใช้ OpenGL 4 GPU ทั้งที่กราฟิกดูอยู่ในระดับที่การ์ด Voodoo ก็น่าจะทำได้
  • ไม่รู้ว่า Turbobloat คืออะไร จากบริบทอ่านแล้วเหมือน “เทคโนโลยีกราฟิกที่ฉันไม่ชอบ” แต่ก็ไม่แน่ใจว่าอะไรนับเป็น Turbobloat บ้าง
  • การสร้างและจัดส่งคอมพิวเตอร์ใหม่อาจคุ้มค่าในระยะยาวก็ได้ เพราะประสิทธิภาพและความประหยัดพลังงานที่ดีขึ้นอาจชดเชยผลกระทบต่อสิ่งแวดล้อมได้เมื่อเวลาผ่านไป
    แน่นอนว่าถ้าใช้เพื่อความบันเทิงก็ตัดสินยาก และ Game Boy เก่า ๆ อาจสนุกกว่าพีซีเกมมิ่งรุ่นใหม่กินไฟ 1000W ก็ได้

• ประโยคที่ว่า “หนึ่งต้องเป็นหนึ่ง ไม่ควรเป็นหลายสิ่งที่แกล้งทำเป็นหนึ่ง เมื่อใช้โหนด คุณต้องทำให้กลุ่มของหลายสิ่งแกล้งทำเป็นหนึ่ง” ให้ความรู้สึกแบบ Terry Pratchett มาก ๆ และยอดเยี่ยมจริง ๆ
  เป็นประโยคที่ Sam Vimes น่าจะคิดขึ้นมาระหว่างทำคดีซับซ้อน ผมชอบมาก และหวังว่าจะพัฒนาต่อไปเรื่อย ๆ ยังไม่ได้ลองใช้เอง แต่มีไอเดียจะนำไปใช้กับ โปรเจกต์ AI ของผม

  • ถ้าแยกประโยคนั้นออกมาดูอย่างเดียว กลับรู้สึกว่ามันผิดอย่างชัดเจนไม่ใช่หรือ เรามองกลุ่มของหลายสิ่งเป็นหนึ่งเดียวอยู่ตลอด
    มนุษย์คือกลุ่มของอวัยวะ อวัยวะคือกลุ่มของสารเคมี สารเคมีคือกลุ่มของโมเลกุล โมเลกุลคือกลุ่มของอะตอม แต่ในแต่ละระดับเราก็มองเป็นหนึ่งเดียว การห้ามทำแบบนั้นฟังดูไม่สมเหตุสมผล ถึงอย่างนั้นโปรเจกต์ก็ดูเท่มาก
  • ผมนึกภาพว่า Sam Vimes พูดแบบนั้นแล้วจากนั้นก็ต้องเติบโตอย่างเจ็บปวดเพราะ Sybil และยอมรับอย่างไม่เต็มใจว่า “บางครั้งหนึ่งก็อาจต้องเป็นมากกว่าหนึ่ง”
    ส่วน ระบบเอนทิตีคอมโพเนนต์ ของ Vetinari แม้ดูซับซ้อน แต่ก็ทำงานได้ถูกต้อง และทำให้เมืองบ้า ๆ นั้นเดินหน้าไปได้
  • วลีนี้ดูเหมือนตั้งใจพูดกับคนที่เคยลองวิธีแก้อื่นแล้วไม่ชอบ แต่ในฐานะคนที่ไม่เคยใช้เกมเอนจินมาก่อน ถ้าอธิบายง่าย ๆ ได้ว่า โหนด เชื่อมโยงกับการ “ทำให้กลุ่มของหลายสิ่งแกล้งทำเป็นหนึ่ง” อย่างไรก็คงดี
    ผมเดาว่าประสบการณ์ผู้ใช้ของตัวแก้ไขโหนดชวนให้ใส่คุณสมบัติและความสัมพันธ์ให้กับสิ่งอย่าง Vector ของ Finger ต่าง ๆ แต่สุดท้าย Vector ก็เป็นแค่ “กลุ่มของสิ่งต่าง ๆ” ไม่ใช่ “ชนิด” ที่มีพฤติกรรมของตัวเอง จึงผูกโค้ดเข้ากับมันได้ยากหรือเปล่า
    สงสัยว่าคำว่า “ทุกอย่างคือ Entity และก็เขียนโค้ดไปเลย” หมายถึงให้สร้างคลาส Hand ที่เก็บ Fingers และมีสถานะกับพฤติกรรมของตัวเอง แทนที่จะใช้ Vector ใช่ไหม หรือหมายถึงให้สืบทอดคลาสย่อยของ Entity ต่ออีกชั้นเพื่อทำให้เฉพาะเจาะจงขึ้น แทนที่จะสร้างอินสแตนซ์โหนดที่รวมค่าคงที่บางอย่างกับสมาชิกความสัมพันธ์ไว้ล่วงหน้ากันแน่
  • ย่อหน้าถัดมาน่าสนใจมาก: “เมื่อสร้างอะไรสักอย่างด้วยโหนด คุณต้องสลับไปมาระหว่าง GUI ของโหนดกับโค้ดอยู่ตลอด”
    โครงสร้าง Node/GDScript ของ Godot อาจมองได้ว่าเป็นคำตอบรูปแบบหนึ่งต่อข้ออ้างนี้ มันพยายามทำให้การ “สลับไปมา” นั้นลื่นไหลและผสานกันมากที่สุดด้วยสิ่งอย่างตัวดำเนินการ $ และการเติมข้อความอัตโนมัติ ถึงอย่างนั้นสุดท้ายก็ต้องปล่อยเกมออกมาอยู่ดี ผมจึงคิดว่าวิธีคิดแบบ “หนึ่งคือหนึ่ง” จะเป็นฝ่ายชนะในท้ายที่สุด
  • น่าเสียดายที่ทุกสิ่งล้วนเป็นกลุ่มของสิ่งต่าง ๆ ที่แกล้งทำเป็นหนึ่ง แม้แต่สิ่งที่ดูเป็นหนึ่งเดียวก็เช่นกัน สิ่งดีที่สุดที่เราทำได้คือแกล้งทำแบบนั้นต่อไป หรือหลบเลี่ยงไม่ให้ถูกจับได้เท่านั้น

• ยิ่งเวลาผ่านไป ก็ยิ่งรู้สึกเหมือนมีแรงภายนอกบางอย่างที่ทำให้ คุณภาพของเอนจินเกม ต่ำลง สิ่งที่แพร่หลายในแวดวงเทคโนโลยีโดยทั่วไปมักเป็นสิ่งที่ทำเป็นหลักสูตรได้ง่าย
  เอดิเตอร์แบบ node-based อย่าง Unity มีโครงสร้างที่เหมาะมากสำหรับอธิบายต่อเนื่องหลายคาบเรียน ในทางกลับกัน เอนจินอย่าง raylib สามารถเข้าใจได้ในช่วงบ่ายเดียว จึงยากที่จะมีคอร์ส raylib ระดับมหาวิทยาลัยเกิดขึ้นได้ ดังนั้นจึงเกิดวงจรที่โรงเรียนแนว bootcamp ผลิตนักพัฒนามือสมัครเล่นที่รู้แค่ Unity/Unreal บริษัทก็รับคนสาย Unity/Unreal และมหาวิทยาลัยก็กลับไปสอนสิ่งนั้นอีก คล้ายกับปรากฏการณ์ที่ Java ได้รับความนิยม
  อีกทั้งแต่ละบริษัทก็มีความต้องการต่อโปรเจกต์ Unity ต่างกัน Unity จึงต้องปรับเอนจินต่อไปในฐานะบริษัทแสวงกำไรที่รับมือลูกค้า ไม่ใช่โปรแกรมเมอร์ขี้บ่นคนหนึ่ง และสุดท้ายก็กลายเป็น Turbobloat เอนจินของ Half-Life และ Morrowind เกิดจากสถานการณ์พิเศษที่โปรแกรมเมอร์ผู้หลงใหลได้รับเงินให้พัฒนาสิ่งที่พวกเขาคิดว่าเจ๋ง จึงได้เอนจินแบบขั้นต่ำที่เหมาะกับนักพัฒนาเกมมืออาชีพและเทคโนโลยีที่ยอดเยี่ยมออกมา
  โปรเจกต์นี้ดูเหมือนอยู่กึ่งกลางระหว่าง raylib กับ Unity ผมกังวลอยู่บ้างว่ามันอาจยังไม่พอจะดึงดูดโปรแกรมเมอร์มือสมัครเล่น และอาจทำอะไรเยอะเกินไปสำหรับโปรแกรมเมอร์ที่ต้องการเอนจินขนาดเล็ก หวังว่าผมจะคิดผิด และประสิทธิภาพกับความสมบูรณ์ก็ดูดีจริง ๆ มีนักพัฒนาที่เบื่อ Unity อยู่แน่นอน และเมื่อวัฏจักรความถวิลหาเริ่มขยับไปสู่ยุค 2000 ก็มีความต้องการจริงในการเล่นและสร้างเกมที่ความซับซ้อนด้านกราฟิกไม่ถึงระดับ Half-Life 2 โทนของเว็บดีไซน์และเอกสารก็ดีด้วย

  • จุดสำคัญอีกอย่างคือ เมื่อเกมกับเอนจินถูกสร้างขึ้นไปพร้อมกัน ทั้งสองอย่างก็สามารถปรับให้เข้ากันได้ Doom ไม่สามารถมีพื้นอีกชั้นวางอยู่เหนือพื้นได้ ซึ่งเป็นข้อจำกัดของเอนจินที่มาจากข้อจำกัดของ CPU และนักออกแบบเลเวลก็สร้างกลเม็ดให้มันดูเหมือนทำได้
    ถ้าออกแบบทั้งสองอย่างไปพร้อมกัน ก็สามารถใช้ฟีเจอร์ที่เพิ่มเข้ามาได้อย่างเต็มที่ และหลีกเลี่ยงฟีเจอร์ที่ทำได้ไม่ดี หรือถึงขั้นปรับ สไตล์ศิลป์ ให้เข้ากับเอนจินได้เลย ม็อบทรงเหลี่ยมแบบพิกเซลของ Minecraft เข้ากับเอนจินได้ดี แต่ถ้าเริ่มทำให้ละเอียดขึ้น มันจะตกลงไปใน uncanny valley ที่ดูเชยและกระอักกระอ่วนกว่า Minecraft เสียอีก จนกว่าจะเรนเดอร์ด้วยจำนวนโพลิกอนที่มากพอจนดูใช้ได้
  • จำได้ว่าคนที่เคยทำงานกับ Bioshock น่าจะเป็น lead designer เคยพูดในสัมภาษณ์ว่า “ถ้าจะทดลองไอเดียใหม่ในบริษัท ต้องตั้งทีมและใช้เวลาอย่างน้อยหนึ่งเดือนกว่าจะมีอะไรให้จับต้องได้ แต่ที่บ้าน ผมสามารถสร้างแคมเปญ Doom ทั้งชุดได้ในคืนเดียว”
  • ผมชอบ การพัฒนาเกมแบบอิงไลบรารี อย่าง raylib หรือ libgdx แต่ก็มีเหตุผลที่เกมอย่าง Slay the Spire ไปใช้ Unity แล้วต่อด้วย Godot ในภาคต่อ
    ผมไม่คิดว่าผู้คนใช้ Unity เพราะถูกอาจารย์ที่ชอบความซับซ้อนสอนมาผิด ๆ
  • เกมสมัยก่อนคมชัดจริง ๆ แต่เกมสมัยนี้รันเละเทะ แครช ต้องดาวน์โหลด 150GB และใช้เวลา 150 ปีถึงจะเปิดขึ้นมา ถ้าเราเล่นเกมเพราะกราฟิกจริง ๆ MMO ที่ได้รับความนิยมมากที่สุดเกมหนึ่งคงไม่ใช่เกมที่มีพื้นฐานจากเบราว์เซอร์เกมปี 2002 และตั้งแต่แรกเราก็คงเล่นความเป็นจริงแทนเกมไปแล้ว
    ดูสิ่งที่ Epic Games ทำกับ Fortnite ก็ได้ พวกเขาฆ่าเกมที่เคยโฟกัสฉากแข่งขันและรันลื่น ๆ ด้วย กราฟิกแบบ Turbobloat กับสกิน
  • ปรากฏการณ์ที่ว่า “มีโปรแกรมเมอร์ที่รู้แค่ Unity/Unreal ออกมา บริษัทรับคนสาย Unity/Unreal และมหาวิทยาลัยก็สอนซ้ำอีก” ก็เกิดคล้ายกันใน ArcGIS

• เห็นด้วยอย่างเต็มที่กับปัญหา การบวมพองแบบเทอร์โบ เครื่องสมัยนี้แรงขึ้นมาก แต่โปรแกรมส่วนใหญ่กลับรู้สึกช้ากว่าเมื่อก่อน
  ตัวโปรเจกต์ก็เจ๋งมาก และดีไซน์เว็บไซต์ได้ A+

  • คำว่า “โปรแกรมส่วนใหญ่ช้ากว่าเมื่อก่อน” ดูเหมือนจะจริงเฉพาะกับคนที่โชคดีได้ใช้ฮาร์ดแวร์ที่แรงเกินจำเป็นเล็กน้อยในช่วงเวลาหนึ่งเท่านั้น
    จากมุมของคนที่ใช้ฮาร์ดแวร์ธรรมดาในยุค Windows 98/2000/XP การใช้ Windows 10/11/KDE/Gnome ฯลฯ บนโน้ตบุ๊กราคาถูกยุคใหม่ที่มี SSD นั้นตอบสนองได้ดีกว่ามาก แม้จะรันเว็บแอปที่ถูกมองว่าบวมอย่าง vscode หรือ Slack ก็ตาม
  • ผมไม่เข้าใจคำว่า Turbobloat เคยทำเกมมาก่อนแต่ไม่เคยได้ยิน ผู้เขียนก็ไม่ได้ให้คำนิยาม และค้นใน Kagi ก็เจอแต่โพสต์ที่ส่งมานี้ ส่วน Google ก็ไม่มีผลลัพธ์ที่เกี่ยวข้อง
    สงสัยว่ามันแค่หมายถึง “บวมมาก ๆ” หรือเปล่า พออ่านไซต์ต่อก็เห็นสำนวนอย่าง “การจำลองฟิสิกส์แบบเหนือจริง” ด้วย เลยคิดว่าสุดท้ายคงหมายถึง “บวมมาก ๆ”

• มุมมองที่ว่า “เกม Unity ส่วนใหญ่ดูแย่มาก แม้จะใช้ shader สวย ๆ, normal mapping และเทคนิคอื่น ๆ” ดูเหมือนจะพบได้บ่อยขึ้นเรื่อย ๆ ในคนบางรุ่น
  แน่นอนว่าเทคนิค texture mapping บางประเภทได้หายไปแล้ว ฉากหลังของ Ikaruga ยอดเยี่ยมเกินความจำเป็น โดยเฉพาะเอฟเฟกต์ป่าเรียบง่ายในช่วงต้น เกมจำลองรถไฟบางเกมในยุค PS2 ก็ทำสิ่งนี้ได้เช่นกัน
  แต่ถ้ามีแหล่งกำเนิดแสงแบบมีทิศทางแรง ๆ เหมือนดวงอาทิตย์ส่องวัตถุที่เป็นประกาย และผู้เล่นเคลื่อนที่ วิธีนี้ก็จะพังลง หากเป็นสภาพแวดล้อมครึ้ม ๆ และไม่มีวัตถุไดนามิกเลย ก็สามารถเลี่ยงกลเม็ดแบบสมัยใหม่ได้ค่อนข้างมาก

  • ใช่ ปัญหาคือเกมสมัยใหม่บางเกมทั้งครึ้มและไม่มี dynamic lighting แต่ก็ยังจงใจใช้ Lumen อยู่ดี Silent Hill รีเมกเป็นแบบนั้น รันช้ามาก ดูแย่ลงบน PS5 Pro และหญ้าก็ดูด้อยกว่าเกมเก่า ๆ ด้วย
    ฉากดั้งเดิมของ Silent Hill ถูกสร้างขึ้นเพื่อให้กลเม็ดการปรับแต่งประสิทธิภาพดูมีเหตุผลอยู่แล้ว พวกเขาใส่พื้นที่หมอกถาวรที่เรียกว่า “พื้นที่หมอก” เพื่อให้จัดการวัตถุบนหน้าจอได้ง่าย แต่รีเมกกลับสิ้นเปลืองการประมวลผลมหาศาลเพื่อสร้างหมอกที่สมจริง แทนที่จะเป็นหมอกที่ดูเหนือธรรมชาติ
  • เกม Unity ที่ดูดีจะไม่ดู “เหมือนเกม Unity” คนจึงไม่นึกถึงเกมเหล่านั้นเป็นตัวอย่างของ “เกม Unity หน้าตาเป็นอย่างไร” ดังนั้นภาพจำของเกม Unity จึงยังคงอยู่ที่ “ค่อนข้างหยาบ” ต่อไป
    ทักษะด้านศิลป์ ที่ทำให้ภาพดูดีไม่ได้หายไปเลย เพียงแต่กระจายตัวอย่างไม่สม่ำเสมอมาก ๆ เท่านั้น ทีมที่มีโมเดลเลอร์, texture artist, animator และความสามารถด้าน visual programming ที่ดี ไม่ว่าจะใช้ Unreal, Unity หรือเอนจินของตัวเอง ก็ทำให้ภาพออกมาดูดีได้
  • มีความดื้อรั้นว่าการใช้วัสดุเพียงอย่างเดียวสามารถแก้ปัญหา texture และ normal mapping ที่ไม่พอได้ ซึ่งไม่จริง และเป็นผลจากการเข้าใจผิดหรือบิดเบือนข้อความการตลาดของสิ่งอย่าง Unreal Engine
    ใน Super Mario Sunshine เงา “คมชัด” ที่ GameCube เรนเดอร์ไม่ได้ จริง ๆ แล้วใช้ mesh แบน ๆ เงาใต้กันสาดใกล้ Shine Gate ใน Delfino Plaza ไม่ใช่ texture แต่เป็น mesh ในทางกลับกัน เหตุผลที่ลานกระเบื้องซึ่งมีเงา mesh นั้นวางอยู่ดูดี ไม่ใช่เพราะใช้ texture ขนาดยักษ์หนึ่งไฟล์ แต่เพราะทำ UV mapping ให้ texture ขนาด 128x128px หลายสิบไฟล์อย่างเหมาะสม
    ถ้าเป็นเกมสมัยใหม่คงใช้ texture กำแพงอิฐสองแบบกับแพตเทิร์น noise เพื่อผสมกัน และทั้งสามอย่างเป็น 2048x2048px ส่วนเงาก็ใช้ ray tracing เพื่อสร้างขอบที่คมชัด น่าขันที่แม้ VRAM และความเร็วบัสจะเพิ่มขึ้น แต่เรากลับเลือก texture ที่ใหญ่ขึ้นแทนที่จะใช้ texture จำนวนมากขึ้น normal mapping ก็เช่นกัน เราเข้าใจผิดว่า normal map ล้าสมัย และการโมเดลรายละเอียดทั้งหมดจริง ๆ คือหนทางที่ก้าวหน้ากว่าในเชิงเทคนิค แทนที่จะใช้ร่วมกับโมเดลที่แบ่งละเอียดยิ่งขึ้น ทรงกลมที่เหลี่ยมน้อยลงนั้นโอเค แต่การโมเดลทุกรอยแตกและรอยขีดข่วนบนทรงกลมจริง ๆ เป็นเรื่องโง่และสิ้นเปลืองการคำนวณ
  • ด้วยของอย่าง Unity คุณสามารถทำอะไรสักอย่างที่ใช้งานได้ค่อนข้างเร็ว แต่ถ้าจะให้มันดูดีจริง ๆ ต้องมีทักษะและการขัดเกลาเพิ่มเติมต่างหาก
    แม้แต่เกม “2D” อย่าง Factorio ก็มี ความต่างด้านการขัดเกลา มหาศาลระหว่างรุ่นเปิดตัวครั้งแรก, 1.0 และเวอร์ชันปัจจุบัน ความต่างนี้เห็นได้ชัดในเกมที่มีม็อดด้วย โดย asset ของม็อดมัก “ใช้ได้” แต่ดูไม่ขัดเกลาเท่าตัวเกมหลัก

• เมื่อไม่นานมานี้ผมกลับไปเล่น Half-Life 2 อีกครั้ง และแปลกใจว่ามันยังดูดีมากแค่ไหนแม้ไม่มีแพ็ก texture ความละเอียดสูง

  • ผมคิดว่านี่เป็นเพราะเลือก art style ของเกมได้ฉลาดสุด ๆ มีพื้นผิวแบบ diffuse จำนวนมากที่เข้ากับการอบแสงล่วงหน้าได้ดี และท้องฟ้าครึ้มทำให้ใช้แสงแวดล้อมที่กระจายตัวได้ แทนที่จะเป็นแสงมีทิศทางที่บังคับให้เกิด shading ที่ขึ้นกับมุมมองและขอบเงาคมคอนทราสต์สูง
    พื้นผิวที่เป็นประกายส่วนใหญ่ก็ไม่ได้มันวาวจัดเกินไป ซึ่งช่วยได้เช่นกัน ตัวเลือกเหล่านี้เข้ากันได้ดีและน่าเชื่อกับโลกดิสโทเปียสุดขั้วที่เก่าโทรมและถูกยึดครอง ขณะที่ texture โทนสีสงบช่วยผูกภาพรวมทั้งหมดเข้าด้วยกัน
  • ดังนั้นผมจึงคิดว่า art direction ที่ดีจริง ๆ ย่อมชนะพลังกราฟิกล้วน ๆ เสมอ Source ก็น่าประทับใจในยุคนั้นอยู่แล้ว แต่ส่วนที่คงทนมาถึงตอนนี้คือสภาพแวดล้อมและโมเดลถูกออกแบบอย่างพิถีพิถันแค่ไหน
    Valve ทุ่มทรัพยากรไปกับการใส่รายละเอียดภายใต้ข้อจำกัดทางเทคนิคและรีดมันออกมาให้ได้มากที่สุด และแม้เวลาจะผ่านไป 20 ปี มันก็ยังดูเป็นหนึ่งเดียวและออกแบบมาอย่างดี
  • Half-Life 2 ได้รับอัปเดตหลายครั้งในด้าน shading และระดับรายละเอียดหลังวางจำหน่าย จึงดูดีกว่าตอนเปิดตัวเล็กน้อย ถึงอย่างนั้น ณ วันที่เปิดตัว มันก็เป็นเกมที่น่าประทับใจด้านภาพอยู่แล้ว
  • ผมกลับไปเล่น Half-Life 2 อีกครั้งเมื่อไม่ถึงสัปดาห์ก่อน และทำให้คิดว่า “แม้เลเวลจะไม่ได้อัดแน่นด้วยรายละเอียดเท่าเกมสมัยใหม่ แต่ทิศทางเชิงศิลป์ของกราฟิกและการออกแบบเลเวลนั้นดีกว่านักออกแบบสมัยใหม่จำนวนมากที่มีงบใหญ่กว่า”
  • Black Mesa ซึ่งเป็นการรีเมก HL1 ด้วยเอนจิน HL2 ก็สนุกดี ผมเล่นช่วงโรคระบาดและไม่เสียใจเลย

• ในฐานะคนที่ทำงานอยู่ในทีมเล็ก ๆ ที่สร้าง เกม low-poly ด้วย Godot เรื่องนี้เจ๋งมาก
  ประโยคอย่าง “เวลาสร้างอะไรด้วย node ก็ต้องสลับไปมาระหว่าง GUI ของ node กับโค้ดตลอด” และ “เอนจินกระแสหลักมีตัวแก้ไขเกมขนาดยักษ์ตัวเดียว และไม่ว่าจะใช้ฟีเจอร์อะไร ก็ต้องรอ 10 นาทีให้มันโหลดทั้งหมด” โดนใจมาก แม้ใน Godot ผมแทบไม่ได้ใช้ฟีเจอร์หวือหวา แต่ debug loop ก็ยังรู้สึกช้ากว่าตอนผมเขียนโปรแกรมในสภาพแวดล้อมอื่นมาก
  ไอเดียที่ให้ editor หลายตัวทำงานร่วมกันโดยยึดสเปกไฟล์ข้อมูลเดียวกันก็ดี IDE แบบรวมศูนย์ทำให้นักพัฒนาหลายคนสร้าง merge conflict ได้ง่าย ดังนั้น editor ที่มีจุดประสงค์เฉพาะมากขึ้นอาจช่วยให้นักพัฒนาแต่ละบทบาทจำกัดขอบเขตและลักษณะของการเปลี่ยนแปลงได้ด้วย รอดูว่าเอนจินนี้จะพัฒนาไปอย่างไร

  • เมื่อเดือนที่แล้วในแฮกกาธอน ผมค่อนข้างภูมิใจที่หาวิธีทำ test-driven development ให้โมดูล C# โดยไม่ต้องเปิด Unity ได้
    ผมสามารถมีส่วนร่วมในส่วนของตัวเองได้แม้ใช้ netbook สเปกต่ำ ผมไม่เคยเขียน C# เลยแม้แต่บรรทัดเดียว แต่ก็ไม่คิดจะยอมทิ้ง TDD บน command line ผมรู้ว่ามันเป็นไปได้ และสุดท้ายก็ทำให้มันใช้ได้ ทุกคนคิดว่าผมบ้า และฝ่าย developer relations ของสปอนเซอร์ก็ช่วยอะไรไม่ได้เลย
    แรงเสียดทานใหญ่ที่สุดในสุดสัปดาห์นั้นยังคงเป็นเรื่องที่คอมพิวเตอร์ที่ดีที่สุดต้องใช้เวลาชั่วกัลป์ไปกับการเปิดและเปิดใหม่ IDE บ้า ๆ ของ Unity น่าทึ่งมากที่ผู้คนยอมทนกับโซ่ตรวนแบบนี้

• มีการใช้คำว่า “Turbobloat” และบอกว่าเอนจิน “บวมเทอะทะ” ซึ่งก็ถูกอยู่ระดับหนึ่ง แต่ก็คุ้มค่าที่จะอธิบายว่าสำหรับตัวเองแล้วมันหมายถึงอะไร มองว่าฟีเจอร์ใดเป็น ความบวมเทอะทะ และตัดอะไรออกจากโปรเจกต์ Tramway บ้าง
  เช่น สำหรับบางคน การรวมเฟรมเวิร์ก RPG ไว้ด้วยก็อาจดูเป็นความบวมเทอะทะ แต่ Tramway มีสิ่งนั้นอยู่

  • ดังนั้นจึงใส่มันไว้เป็น ส่วนขยายแบบเลือกใช้ได้ แม้จะเป็นส่วนหนึ่งของโปรเจกต์เอนจินที่ใหญ่กว่า แต่ก็เป็นตัวเลือกโดยสมบูรณ์
    ผมชอบหลักการของ C++ ที่ว่า “จ่ายต้นทุนเฉพาะสิ่งที่ใช้เท่านั้น”

• มีเขียนไว้ว่า “วิธีใช้เฟรมเวิร์กสำหรับมือใหม่ที่กลัว C++ หรือแค่เขียนไม่เป็น” ซึ่งผมเป็นอย่างหลัง และรู้สึกขอบคุณหน้า Getting Started มาก
  มีกาน้ำชาปรากฏขึ้นมา และผมก็เข้าใจสิ่งที่คิดว่าตัวเองคงไม่มีทางเข้าใจ ตอนนี้มีเวลาพักเที่ยงแค่ 30 นาที เลยไม่มีเวลาทำบทช่วยสอนให้จบ แต่การที่มันทำให้ผมอยากทำต่อ ก็แสดงให้เห็นได้ดีว่าเอกสารนี้สนุกและเข้าถึงง่ายแค่ไหน

• มีใครหาเพจ Design Patterns เจอไหม? มันเป็นกระดานคะแนนเป้าหมาย 100% ที่ผมชอบมาก

  • มีลิงก์อยู่ที่หน้าโฮม: “ดีไซน์แพตเทิร์นที่ใช้แล้ว 82% ถ้าใช้ครบทุกแพตเทิร์นเมื่อไหร่ จะลบโปรเจกต์แล้วเขียนใหม่ด้วย Rust โดยไม่มีเชิงวัตถุ”
  • ผมหาอยู่นานแล้วแต่ก็ยังหาไม่เจอ