อะไรคือข้อได้เปรียบของ OpenGL ที่มีอยู่เหนือเฟรมเวิร์ก / เอนจิ้นสำหรับผู้พัฒนารายย่อย? [ปิด]

ฉันสังเกตเห็นแนวโน้มของนักพัฒนาอินดีที่หลีกเลี่ยงเฟรมเวิร์กและเอ็นจิ้นและเคลื่อนไปสู่การใช้ OpenGL ที่เปลือยเปล่าหรือใช้ร่วมกับ SDL / SFML2 ในฐานะนักพัฒนาอินดี้ฉันไม่สามารถเห็นสิ่งที่ OpenGL ระดับต่ำสามารถเสนอให้กับเอนจิ้นหรือเฟรมเวิร์กแยกกันได้

เอ็นจิ้นและเฟรมเวิร์กที่เหมาะสมที่สุดให้ฟังก์ชั่นที่คุณต้องการและไม่เคยเข้ามาขวางทางคุณเลย พวกเขาอาจเปิดตัวเลือกเพื่อจัดการกับ OpenGL โดยตรง บางคนเสนอฟังก์ชั่นในการรวบรวมข้ามแพลตฟอร์ม!

ฉันเข้าใจความทะเยอทะยานที่จะเรียนรู้สิ่งที่เกิดขึ้นใต้กระโปรงหน้ารถ แต่ฉันไม่สามารถมองเห็น Upsides ใด ๆ ที่ OpenGL อาจเสนอให้กับนักพัฒนาอินดี้ผ่านเครื่องมือหรือกรอบงาน

คุณช่วยอธิบายเหตุผลในการสร้างเกมตั้งแต่เริ่มต้นด้วย OpenGL ได้ไหม?

นี่เป็นคำถาม / คำตอบตามความเห็นเป็นส่วนใหญ่ดังนั้นจึงไม่จำเป็นต้องเหมาะสำหรับแพลตฟอร์มนี้ แต่อย่างไรก็ตาม:

ทำไมไม่มีเฟรมเวิร์ก / เอ็นจิ้นในฐานะอินดี้? นี่คือสองเซ็นต์ของฉัน:

• การขาดงบประมาณ:นี่อาจเป็นจุดที่ใหญ่ที่สุดสำหรับนักพัฒนารายเล็ก / อินดี เฟรมเวิร์กหรือเอ็นจิ้นจำนวนมากจะไม่อนุญาตให้คุณเผยแพร่ผลิตภัณฑ์ของคุณโดยไม่ต้องซื้อรุ่นที่แพงกว่า (สมมติว่ามีรุ่นราคาถูกหรือฟรีให้บริการทั้งหมด) และ / หรือจ่ายค่าลิขสิทธิ์ บางครั้งคุณต้องจ่ายครั้งเดียวต่อแพลตฟอร์มเช่นกัน
• ความซับซ้อน:เครื่องยนต์หรือกรอบงานส่วนใหญ่ตกอยู่ในหนึ่งในสองประเภท:
  • มันมีข้อ จำกัด มากสำหรับประเภทพิเศษหนึ่งเกม ( RPG Makerเป็นตัวอย่างทั่วไป)
  • หรือพวกคุณทั่วไปเกินไปที่มีหลายสิ่งที่คุณมักจะไม่ใช้ (เช่นUnity )
• รหัสกรรมสิทธิ์: เอ็นจิ้นส่วนใหญ่ไม่ได้เป็นโอเพ่นซอร์สและเพื่อให้ได้แหล่งที่มาที่แท้จริงคุณจะต้องจ่ายมากขึ้น (หากมีให้) หากไม่มีซอร์สโค้ดจริงที่ย้ายไปยังแพลตฟอร์มอื่นอาจเป็นเรื่องยากหรือเป็นไปไม่ได้ (อีกครั้งRPG Makerจะเป็นตัวอย่างที่สมบูรณ์แบบ)
• Clunkyness:นี่เป็นความเห็นส่วนตัวของฉัน แต่อย่างน้อยสำหรับฉันนี่มักจะเป็นสิ่งที่ค่อนข้างใหญ่เมื่อพิจารณาจากเครื่องมือและกรอบที่สร้างไว้ล่วงหน้าโดยเฉพาะอย่างยิ่งเมื่อคุณสร้างเกมเล็ก ๆ ขึ้นมา ใครที่ต้องการเล่นเกมเบรกเกอร์ขนาดเล็กที่มีขนาด 200 KB แต่มีขนาดของรันไทม์ถึง 50 MB?
• ตัวเลือกภาษา: เอ็นจิ้นและกรอบงานบางอย่างไม่มีห้องสมุดที่จะใช้ในโค้ดของคุณเอง แต่พวกเขามีกรอบงานหรือรันไทม์ที่จะใช้ภาษาสคริปต์ของตัวเองหรือบางภาษาที่ตั้งไว้ (เช่น Javascript หรือ C #) หากคุณกำลังเขียนเอนจินแบบกำหนดเองคุณสามารถใช้ภาษาใดก็ได้ที่คุณเลือก
• การคุ้มครองงานของคุณ:หากคุณใช้เครื่องมือ premade หรือกรอบงานโอกาสสูงที่คนอื่น ๆ อาจมีเวลามากขึ้นในการเปลี่ยนหรือถอดรหัสรหัสหรือสินทรัพย์ของคุณสิ่งที่คุณอาจต้องการหลีกเลี่ยง (แม้ว่าจะเป็นเพียงเพื่อรักษาคะแนนสูงสุดของคุณ ทำความสะอาด) รหัสที่กำหนดเองและการจัดการสินทรัพย์เพิ่มอุปสรรคที่ใหญ่กว่าที่จะใช้โดยเฉพาะอย่างยิ่งเมื่อรวบรวมเป็นรหัสพื้นเมือง
• การสร้างแบรนด์:สิ่งนี้อาจมีน้อยสำหรับหลาย ๆ คน แต่เอ็นจิ้นและกรอบงานบางอย่างบังคับให้คุณแสดงโลโก้ของพวกเขาหรืออาจจะเป็นโฆษณา แน่นอนว่าสิ่งนี้มักขึ้นอยู่กับใบอนุญาตที่แท้จริงค่าธรรมเนียมใบอนุญาตเป็นต้น
• ความไม่ลงรอยกันกับสิทธิ์การใช้งาน:นี่เป็นสิ่งที่หลายคนไม่ได้คำนึงถึงเมื่อเลือกเครื่องยนต์ แต่ขึ้นอยู่กับสิ่งที่คุณต้องการทำนี่อาจเป็นปัจจัยสำคัญ แม้ว่าคุณจะซื้อเครื่องมือบางอย่างคุณอาจถูก จำกัด ไม่ให้เปิดเผยแหล่งที่มาหรือวัสดุที่เกี่ยวข้อง บางสิ่งเช่นนี้อาจทำให้การแก้ไขเป็นไปไม่ได้แม้ว่าคุณต้องการให้ผู้ใช้สามารถทำได้ นำตัวอย่างซอร์สของ Valve ( Half-Life 2 , Team Fortress 2 , ฯลฯ ) เป็นตัวอย่าง: พวกมันอนุญาตให้ modders ใช้ engine ของพวกเขาสำหรับโครงการของพวกเขาเอง หากเกมเหล่านี้มีพื้นฐานมาจาก (ตัวอย่าง) Unreal Engine จะไม่สามารถทำได้เนื่องจากข้อ จำกัด ที่ระบุไว้ในข้อกำหนดสิทธิการใช้งาน

เอ็นจิ้นและเฟรมเวิร์กที่เหมาะสมที่สุดให้ฟังก์ชั่นที่คุณต้องการและไม่เคยเข้ามาขวางทางคุณเลย

ทำพวกเขา ค่อนข้างขึ้นอยู่กับว่าคุณกำลังทำอะไรอยู่การพูดแบบกราฟิก

สำหรับเกมหลายประเภทมีคำตอบมาตรฐานสำหรับคำถามแบบกราฟิก ยกตัวอย่างเช่นเกม 2D โดยเฉลี่ยสามารถจัดการได้ดีกับฤทธิ์ 2D เช่น XNA / MonoGame มันเป็นเพียงสไปรต์ซึ่งสามารถเข้ามาเป็นชุดสำหรับภูมิประเทศสามารถหมุนได้และอื่น ๆ

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

ตอนนี้คุณกำลังใช้การทำแผนที่ปกติและอาจทำแผนที่แบบพารัลแลกซ์ ทั้งหมดในบริบทเดียวกันของ "การเรนเดอร์เรนเดอร์" แต่ต้องการเอ็นจิ้น 2D บริสุทธิ์จำนวนมากสามารถจัดการได้ โดยเฉพาะมันต้องใช้ "สไปรต์ blitting" multitextured ซึ่งไม่ใช่สิ่งที่เครื่องยนต์ 2D จำนวนมากสามารถทำได้

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

ดังนั้นคุณต้องเลือกอย่างใดอย่างหนึ่งต่อไปนี้:

1. ละทิ้งความคิด ซึ่งหมายความว่าเกมของคุณถูก จำกัด โดยเครื่องยนต์ของคุณ
2. แฮ็คเครื่องยนต์เพื่อให้มีหลายไซต์ สมมติว่าคุณมีสิทธิ์เข้าถึงซอร์สโค้ดตอนนี้คุณก็สามารถนำไปใช้กับตัวเองเพื่อกระตุ้นโค้ดของคนอื่นได้ นอกจากนี้ยังหมายความว่าคุณต้องบำรุงรักษาและไม่ทำลายมันด้วยการสะดุด
3. ทำสิ่งที่ดีที่สุดที่คุณสามารถทำได้ภายใต้ข้อ จำกัด ของเครื่องยนต์ ดังนั้นคุณจะได้รับรัลแลกซ์บนแผนที่ปกติ แต่ไม่ใช่ในสี อาจไม่ใช่สิ่งที่คุณต้องการ แต่ก็ดีกว่าไม่มีอะไรเลย

ยกตัวอย่างเช่นใช้ Geometry Wars เครื่องยนต์ 2D ส่วนใหญ่จะดูดภาพเหล่านี้เนื่องจากส่วนใหญ่สร้างขึ้นรอบ ๆ สไปรต์ไม่ใช่เส้น นั่นเป็นเกมที่ต้องใช้โหมดแสดงภาพที่พิเศษมาก

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

นอกจากนี้ยังมีปัญหาในทางปฏิบัติ: เอ็นจิ้นของเกมไม่สามารถพกพาได้อย่างเท่าเทียมกัน

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

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