ทำไมผู้พัฒนาเกมถึงเขียนโปรแกรมของตัวเองแทนที่จะใช้สิ่งที่มีอยู่

ฉันสังเกตว่าผู้พัฒนาเกมขนาดใหญ่และมีชื่อเสียงมักจะพัฒนาเอนจิ้นของตัวเอง ตัวอย่างเช่น Valve, Crytek, Ubisoft, Epic Games และ Square-Enix

อาจเป็นเพราะพวกเขาทำได้หรือเป็นไปได้ว่าเครื่องยนต์ที่มีอยู่ไม่ตอบสนองความต้องการมากพอดังนั้นเราจะพัฒนาของเราเอง? ฉันนึกภาพเกมที่ต้องใช้เอนจิ้นเฉพาะไม่ได้ ความชอบของ Unity หรือ Unreal นั้นเพียงพอที่จะสร้างเกมประเภทใดก็ได้ แม้ว่าจะไม่ได้พวกเขามีซอร์สโค้ดซึ่งสามารถแก้ไขได้เพื่อตอบสนองความต้องการพิเศษบางอย่าง

ทำไมผู้พัฒนาเกมถึงเขียนโปรแกรมของตัวเองแทนที่จะใช้สิ่งที่มีอยู่

มีเหตุผลหลายประการที่สตูดิโออาจเลือกที่จะ "สร้าง" แทนที่จะเป็น "ซื้อ" เทคโนโลยีของพวกเขา:

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

โดยทั่วไปแล้วมันมีเหตุผลที่ดีที่จะเป็นเจ้าของและควบคุมสิ่งต่าง ๆ ที่มีความสำคัญต่อความสำเร็จของธุรกิจของคุณ

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

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

โปรดทราบว่าสตูดิโอบางรายการที่คุณระบุไว้ (โดยเฉพาะ Crytek และ Epic) ได้หยุดความพยายามในการครองตลาดเกมโดยตรงและแน่นอนว่าจะทำให้ผู้ผลิตมิดเดิลแวร์มากกว่าผู้พัฒนาเกม

ตามที่กล่าวโดยJosh Petrie :

" ไม่ได้สร้างที่นี่ซินโดรม ;"

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

ฉันทดสอบเอนจิ้นเกมประเภทต่าง ๆ การเรนเดอร์ API และ Ploobs ที่โดดเด่น UNITY WaveEngine, XNAFinalEngine, Love, Ogre และอื่น ๆ อีกมากมาย ... ฉันต้องการเริ่มเขียนเกม - ฉันดาวน์โหลดมากมองสบาย ๆ และจุดเข้าเอกสารที่ดี ...

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

ซึ่งเป็นสิ่งที่ฉันทำลงเอย

ดังนั้นฉันเลือกที่จะตั้งค่า XNA เนื่องจากฉันรู้จัก C # แล้วและเริ่มคิดว่าควรเริ่มต้นอย่างไร ฉันต้องการความคิด

ฉันตัดสินใจว่าไม่ว่าจะเกิดอะไรขึ้นฉันจะเข้าสู่ 3Dโดยตรง

การพื้นฐานลงเป็นเย็น - สิ่งที่เทพดาชุด แต่ที่ผมก้าวหน้าฉันสิ้นสุดการค้นพบอุปสรรคใหม่และอุปสรรค - จริงครั้งแรกของฉันเป็นขีด จำกัด ของชุด เป้าหมายของฉันคือการสร้างเกมที่สามารถแสดงผลอย่างน้อย 10,000 รายการในมุมมอง frustum ได้ตลอดเวลา

ฉันเริ่มต้นการเดินทางครั้งใหม่ของการใช้ Shader Based Instancing (และเรียนรู้ HLSL ในขณะที่ฉันอยู่ที่นี่) ฉันทิ้ง XNA ที่สร้างขึ้นในวัตถุ Model and Effect เพื่อเขียนแทนตัวเอง ฉันมีปัญหาในการทำความเข้าใจกับลำธาร VBO ในตอนแรก ฉันทำสิ่งต่าง ๆ เสียหาย - ฉันไปทางออนไลน์เพื่อถามคำถามเกี่ยวกับสิ่งที่ติดตั้งไว้และเก็บไว้จนกระทั่งในที่สุดฉันก็เข้าใจว่า GPU กำลังทำอะไรอยู่ มันจ่ายออกไป; ตอนนี้ฉันมีหน่วยงานทดสอบมากกว่าสองพันรายการที่ซูมเข้ามาในวิวพอร์ตของฉันหลังจากผ่านการดีบัก VBO ของฉันด้วย PIX (dxsdk) สองสามวัน

ตอนนี้ฉันมีแนวคิด "บางอย่าง" เกี่ยวกับวิธีการสร้างการแสดงผลท่อ แต่ยังไม่เสร็จ - ฉันลงเอยด้วยการสร้างสถานะเกมของตัวเองกล้องโพสต์เอฟเฟกต์และวัตถุเอนทิตีของตัวเองย้ายออกจาก XNA Content Pipeline ตัวตัก (ไม่ชอบส่วนตัวต่อสิ่ง XNB) สร้างความลึกที่ซับซ้อนเรียงลำดับและผสมผสานรูปทรงเรขาคณิตที่แยกจากกันของรัฐและยังมีสไปรต์และข้อความที่ไม่ถูกต้องทั้งหมดที่ถูกฉายเข้าไปในฉากเกม

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

ตอนนี้เครื่องยนต์ของฉันเสถียรมากและใกล้จะเสร็จแล้ว มันไม่สมบูรณ์แบบ: การเขียนสคริปต์นั้นมีคุณค่าและ GUI ไม่ยอดเยี่ยมเลย แต่ฉันก็ยังรักมัน โค้ดหลายพันรายการสินทรัพย์และสื่อ - ซ่อนตัวอยู่ในพื้นที่เก็บข้อมูล 2GB git ส่วนตัวและอาการปวดหัวทั้งหมดที่ฉันต้องทำคือพยายามพัฒนารูปแบบที่ฉันไม่เคยทำมาก่อน อุปสรรคทุกอย่างที่ฉันเอาชนะได้คือบทเรียนที่เรียนรู้ - และการผ่อนปรน

ฉันดึงออกเกือบทุกอย่างที่ฉันต้องการ

แต่ในที่สุด - ฉันตัดสินใจว่าถึงเวลาที่จะทำให้เธอผิดหวัง เท่าที่ฉันพอใจตัวเองเขียนเครื่องมือขนาดใหญ่เช่นนี้ด้วยตัวเองพร้อมคำแนะนำจากเน็ตและเพื่อน ๆ ของ gamedev อื่นฉันตัดสินใจว่าฉันจะทำมันทั้งหมดอีกครั้ง - และทำได้ดีกว่า - เพราะตอนนี้เวลานี้ฉันส่วนใหญ่รู้แล้ว ฉันกำลังทำอะไรอยู่.

โครงการนั้นยังคงซ่อนตัวอยู่ใน repo GIT ของฉัน

รอบที่สองของฉันในการเขียนเอ็นจิ้นใหม่ (คราวนี้บน MonoGame) กำลังก้าวหน้าไปด้วยดี เมื่อมีบางสิ่งบางอย่างแตกหักง่ายกว่าที่จะแก้ไข ระเบียบน้อย ฉันหวังว่าจะแสดงเกมของฉันต่อสาธารณชนในบางครั้งในปีนี้เนื่องจากฉันมักจะแนบกับโค้ดของฉันเล็กน้อย

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

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

เหตุผลสำคัญที่แน่นอนที่จะเขียนเครื่องมือของคุณเอง (และที่น่าประหลาดใจผมว่าไม่มีใครได้เรียกว่าออกมานี้ยัง) สำหรับการแก้จุดบกพร่อง

หากคุณเขียนเกมที่มีขนาดใหญ่และซับซ้อนและมีข้อผิดพลาดในเกมและคุณมีซอร์สโค้ด (และคุ้นเคยกับซอร์สโค้ดนั้นอย่างใกล้ชิดโดยอาศัยการเขียน) คุณสามารถแนบดีบักเกอร์เพื่อ กระบวนการและค้นหาสิ่งที่ทำให้เกิดความผิดพลาด เสร็จสิ้น

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

การพัฒนาเกมนั้นยาก แต่การแก้ไขข้อบกพร่องนั้นยากกว่า ในหนังสือของฉันอะไรซึ่งจะทำให้การพัฒนาเกมยาก แต่การแก้จุดบกพร่องได้ง่ายขึ้นเป็นใหญ่ชนะสุทธิ

มีคำตอบที่ดีมากที่นี่ แต่พวกเขาขาดจุดสำคัญอีกจุดหนึ่ง

หลายของเครื่องยนต์ออกใบอนุญาตได้ในวันนี้เริ่มต้นจากการเป็นเครื่องมือเฉพาะ

มาลอง Unreal เป็นตัวอย่างเพราะมันแพร่หลายมาก

วันนี้เมื่อคุณนึกถึง Unreal คุณมักจะนึกถึงเครื่องยนต์ที่คุณอนุญาตและสามารถใช้แทนการสร้างของคุณเอง แต่นั่นไม่ได้เกิดขึ้นเสมอไปและเป็นครั้งคราวที่ Unreal engine ไม่มีอยู่จริง นิติบุคคลแยกต่างหาก

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

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

มีเหตุผลอื่น ๆ ที่สตูดิโออาจเลือกที่จะ "สร้าง" แทนที่จะเป็น "ซื้อ" เทคโนโลยีของพวกเขา:

• แพลตฟอร์มใหม่: ระบบปฏิบัติการมือถือใหม่คอนโซลหรือตัวควบคุม คิดถึง leapmotion, google glass ฯลฯ การสนับสนุน cross-plataform นั้นยาก
• กลไกเกมใหม่และ / หรือบรรณาธิการในเกม : คิดถึง FEZ เมื่อหลายปีก่อน (2D vs 3D)
• ขาดการเปิดแหล่งที่มาบรรณาธิการเกมที่ดีฟรี ไม่มีเอกสารที่ดีเกี่ยวกับแหล่งเกมเก่าที่มีอยู่
• วิวัฒนาการของ เครื่องมือใน toolchain ของสตูดิโอ (หรือเพิ่มใหม่)
• ราคาเครื่องยนต์และสงครามใบอนุญาต

ฉันยังเห็นด้วยกับคำขอ / ความต้องการเฉพาะและการกำหนดราคาเครื่องยนต์และสงครามใบอนุญาตบังคับให้สตูดิโอบางแห่งเปิดตัวบางเครื่องยนต์

แรงจูงใจที่ดีในการ "ซื้อ" หรือ "ใช้" เครื่องมืออื่น ๆ คือ:

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

เหตุผลทางประวัติศาสตร์ (ส่วนใหญ่)
ซึ่งเกี่ยวข้องกับการกำหนดราคา

ทุกเกมที่คุณเห็นว่าทำงานเป็น Unreal หรือ CryEngine ในปีที่ผ่านมาต้องจ่ายเงินเป็นจำนวนมาก โดยเฉพาะอย่างยิ่งถ้าคุณต้องการรับซอร์สโค้ด (เช่น: คุณต้องการ UE ไม่ใช่ UDK เท่านั้น)

แต่สิ่งนี้เปลี่ยนไป ตอนนี้ทุกคนสามารถซื้อเครื่องยนต์ที่ใหญ่กว่าได้เมื่อการแข่งขันด้านราคาเริ่มต้นขึ้น
นั่นหมายความว่า ...

• คุณจะเห็นเกมมากขึ้นโดยใช้ทั้ง UE4 และ CryEngine
  แม้ว่าพวกเขาจะไม่เป็นเกม AAA เหมือนที่เคยเป็นมา
• ข้อกำหนดและความต้องการที่กำหนดเองสำหรับแต่ละโครงการจะไม่หายไป
  ดูเครื่องยนต์ Warhammer40k / COH ที่ Relic หรืออันที่นายพลใช้ใน EA
  ดังนั้นแม้ว่าใคร ๆ ก็สามารถซื้อเครื่องยนต์ที่ใหญ่กว่าได้ แต่พวกเขาก็ไม่ได้เสนอทางเลือกที่ดีกว่า
• มีคนอื่นในตลาด ชอบความสามัคคี
  ผู้คนต่างชื่นชอบมันใช้งานง่ายประสิทธิภาพที่รวดเร็วและร้านขายสินทรัพย์ขนาดใหญ่
  แน่นอน Unity สามารถปรับใช้กับแพลตฟอร์มเกือบทุกชนิด

ใช่แล้ว ความต้องการการกำหนดราคาในอดีตและเช่น

แล้วองค์กรของทีมล่ะ?

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

ดังนั้นฉันต้องการกลุ่มสนับสนุนเพื่อทำเช่นนั้น แต่นั่นทำให้ค่าใช้จ่าย: ผู้คนมากขึ้นสถานที่มากขึ้นโทรศัพท์สายมากขึ้นการบริหารมากขึ้น ...

ทางออกหนึ่งในการทำเช่นนี้อาจเป็นการเอาท์ซอร์ส ... กับ บริษัท มิดเดิลแวร์, ปล่อยทรัพยากรให้กับธุรกิจของฉันในการสร้างเกม, คือกลุ่มสร้างสรรค์และนักเขียน

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

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

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

คำตอบของฉันแตกต่างจากคำตอบที่มีอยู่ดังนั้นฉันจึงเพิ่มคำตอบแม้ว่าจะมาช้า:

หากคุณนำตัวอย่าง Valve มาจากคำถามหรือชุด Witcher เป็นกระบวนการ:

• ใบอนุญาตเครื่องยนต์
• ดัดแปลง / ดัดแปลงเครื่องยนต์ตามวัตถุประสงค์ของคุณ
• ปล่อยเกมและสร้างรายได้
• สร้างเอ็นจิ้นของตัวเองสำหรับเกมต่อไป

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

ครูการเขียนโปรแกรมของฉันบอกเราใช้เฉพาะ API / วิธี / คลาส / ฟังก์ชั่นที่คุณรู้วิธีสร้าง

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

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

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

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

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

อย่างไรก็ตามฉันหวังว่าฉันจะทำให้ชัดเจนในสิ่งที่ฉันพยายามชี้ให้เห็น