Lua ทำงานเป็นภาษาสคริปต์ในเกมได้อย่างไร

ฉันค่อนข้างขุ่นมัวว่า Lua คืออะไรและเกมที่ตั้งโปรแกรมใน C ++ จะใช้งานอย่างไร ฉันถามหลักเกี่ยวกับวิธีการรวบรวมและเรียกใช้

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

หรือมันทำหน้าที่เหมือน bash script ใน Linux ที่มันรันโปรแกรมแยกจากโปรแกรมหลักอย่างสิ้นเชิงหรือไม่?

การเขียนสคริปต์เป็นนามธรรมการเขียนโปรแกรมที่คุณ (แนวคิด) มีโปรแกรม (สคริปต์) ทำงานภายในโปรแกรมอื่น (โฮสต์) ในกรณีส่วนใหญ่ภาษาที่คุณเขียนสคริปต์นั้นแตกต่างจากภาษาที่โฮสต์ถูกเขียน แต่สิ่งใด ๆ ที่เป็นนามธรรมของโปรแกรมภายในโปรแกรม a อาจถูกพิจารณาว่าเป็นสคริปต์

ตามแนวคิดแล้วขั้นตอนทั่วไปในการเปิดใช้งานการเขียนสคริปต์มีดังต่อไปนี้ (ฉันจะใช้ pseudo-c สำหรับโฮสต์และ pseudo-lua สำหรับสคริปต์เหล่านี้ไม่ใช่ขั้นตอนที่แน่นอน แต่คล้ายกับโฟลวทั่วไปที่คุณเปิดใช้งานสคริปต์)

1. สร้างเครื่องเสมือนในโปรแกรมโฮสต์:

   VM m_vm = createVM();

2. สร้างฟังก์ชั่นและเปิดเผยให้กับ VM:

   void scriptPrintMessage(VM vm)
   {
       const char* message = getParameter(vm, 0); // first parameter
       printf(message);
   }
   
   //...
   
   createSymbol(m_vm, "print", scriptPrintMessage);
   

   โปรดสังเกตว่าชื่อที่เราสัมผัสกับฟังก์ชั่น ( print) ไม่จำเป็นต้องตรงกับชื่อภายในของฟังก์ชั่นนั้น ( scriptPrintMessage)

3. เรียกใช้โค้ดสคริปต์ที่ใช้ฟังก์ชัน:

   const char* scriptCode = "print(\"Hello world!\")"; // Could also be loaded from a file though
   doText(m_vm, scriptCode);
   

นั่นคือทั้งหมดที่มีให้มัน โปรแกรมจะไหลในลักษณะต่อไปนี้:

1. คุณโทรdoText()มา scriptCodeการควบคุมจะถูกโอนไปยังเครื่องเสมือนที่จะดำเนินการข้อความภายใน

2. printรหัสสคริปต์พบสัญลักษณ์ที่ส่งออกไปก่อนหน้านี้ scriptPrintMessage()จากนั้นจะโอนการควบคุมฟังก์ชั่น

3. เมื่อscriptPrintMessage()เสร็จสิ้นการควบคุมจะโอนกลับไปที่เครื่องเสมือน

4. เมื่อทั้งหมดของข้อความในscriptCodeได้รับการดำเนินการจะเสร็จสิ้นและการควบคุมจะถูกโอนกลับไปที่โปรแกรมของคุณบนเส้นหลังdoText()doText()

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

• การแยกข้อกังวล: เป็นรูปแบบทั่วไปในการเขียนเอ็นจิ้นเกมใน C / C ++ จากนั้นเป็นเกมจริงในภาษาสคริปต์เช่น lua ถูกต้องแล้วรหัสเกมสามารถพัฒนาได้อย่างสมบูรณ์โดยอิสระจากเอ็นจิ้นเอง

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

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

• คุณสมบัติภาษา: เมื่อใช้ภาษาสคริปต์ขึ้นอยู่กับการเลือกของคุณสำหรับภาษาโฮสต์และสคริปต์คุณสามารถใช้ประโยชน์จากคุณสมบัติที่ดีที่สุดที่แต่ละภาษามีให้ โดยเฉพาะอย่างยิ่ง coroutines ของ lua เป็นคุณสมบัติที่น่าสนใจมากซึ่งยากมากที่จะนำไปใช้ใน C หรือ C ++

แม้ว่าสคริปต์จะไม่สมบูรณ์แบบ มีข้อเสียทั่วไปบางประการในการใช้สคริปต์:

• การดีบักนั้นยากมาก: โดยปกติแล้วตัวดีบั๊กที่รวมอยู่ใน IDE ทั่วไปนั้นไม่ได้ออกแบบมาเพื่อการดีบักโค้ดภายในสคริปต์ ด้วยเหตุนี้การดีบักการติดตามคอนโซลจึงเป็นเรื่องปกติมากกว่าที่ฉันต้องการ

  ภาษาสคริปต์บางภาษาเช่น lua มีเครื่องมือช่วยในการดีบักซึ่งสามารถใช้ประโยชน์จาก IDE บางตัวเช่น Eclipse การทำเช่นนี้เป็นเรื่องยากมากและฉันไม่เคยเห็นการดีบักสคริปต์ทำงานได้ดีเท่าการดีบักแบบดั้งเดิม

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

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

• ประสิทธิภาพการทำงาน: เป็นโปรแกรมที่แปลความหมายทั่วไปและมีความหมายสำหรับเครื่องเสมือนนามธรรมซึ่งสถาปัตยกรรมอาจแตกต่างจากฮาร์ดแวร์จริงสคริปต์มักจะทำงานช้ากว่าโค้ดท้องถิ่น VMs บางอย่างเช่น luaJIT และ V8 ทำหน้าที่ได้ดีมาก สิ่งนี้อาจสังเกตได้ถ้าคุณใช้งานสคริปต์อย่างหนัก

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

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

การเขียนสคริปต์เป็นเพียงเครื่องมือ วิธีที่คุณใช้มันเพื่อสร้างเกมที่ยอดเยี่ยมนั้นขึ้นอยู่กับคุณ

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

รหัส Lua ถูกตีความโดย Lua runtime ซึ่งเป็นรหัส C ที่คุณเชื่อมโยงเป็นห้องสมุด (ปกติ) ในโปรแกรมของคุณเอง คุณสามารถอ่านเพิ่มเติมเกี่ยวกับวิธีการ Lua ทำงานที่หน้าแรกของ Lua โดยเฉพาะอย่างยิ่ง Lua ไม่ใช่ "คลาสที่ไม่คอมไพล์" ตามที่คุณคาดการณ์โดยเฉพาะอย่างยิ่งถ้าคุณกำลังนึกถึงคลาส C ++ เนื่องจาก C ++ นั้นแทบจะไม่เคยคอมไพล์แบบไดนามิกในทางปฏิบัติ อย่างไรก็ตามรันไทม์ของ Lua และวัตถุที่สร้างโดยสคริปต์ Lua ที่เกมของคุณรันใช้เนื้อที่ในพูลหน่วยความจำระบบของเกม

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

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

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

ภาษาสคริปต์ส่วนใหญ่รวมถึง Lua ทำงานบน Virtual Machine ( VM ) ซึ่งโดยทั่วไปจะเป็นระบบในการแมปคำสั่งสคริปต์กับคำสั่ง CPU "ของจริง" หรือการเรียกใช้ฟังก์ชัน โดยปกติ Lua VM จะทำงานในกระบวนการเดียวกันกับแอปพลิเคชันหลัก นี่เป็นความจริงอย่างยิ่งสำหรับเกมที่ใช้งาน Lua API มอบฟังก์ชั่นหลายอย่างที่คุณเรียกใช้ในแอพพลิเคชั่นเนทีฟเพื่อโหลดและรวบรวมไฟล์สคริปต์ เช่นluaL_dofile()รวบรวมสคริปต์ที่กำหนดลงใน Lua bytecodeแล้วเรียกใช้ bytecode นี้จะถูกแมปโดย VM ที่ทำงานอยู่ภายใน API ไปยังคำสั่งเครื่องดั้งเดิมและการเรียกใช้ฟังก์ชัน

กระบวนการของการเชื่อมต่อเป็นภาษาพื้นเมืองเช่น C ++ ด้วยภาษาสคริปต์ที่เรียกว่ามีผลผูกพัน ในกรณี Lua API นั้นมีฟังก์ชั่นที่ช่วยให้คุณเปิดเผยฟังก์ชั่นพื้นฐานของโค้ดสคริปต์ ตัวอย่างเช่นคุณสามารถกำหนดฟังก์ชั่น C ++ say_hello()และทำให้ฟังก์ชั่นนี้เรียกใช้ได้จากสคริปต์ Lua Lua API ยังมีวิธีการสร้างตัวแปรและตารางด้วยรหัส C ++ ที่จะสามารถมองเห็นได้สำหรับสคริปต์เมื่อมีการเรียกใช้ คุณสามารถแสดงคลาส C ++ ทั้งหมดให้กับ Lua ได้ ตรงกันข้ามยังเป็นไปได้ Lua API ช่วยให้ผู้ใช้ปรับเปลี่ยนตัวแปร Lua และเรียกใช้ฟังก์ชั่น Lua จากรหัส C ++ พื้นเมือง

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

หวังว่าสิ่งนี้จะช่วยชี้แจงคำถามของคุณ

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

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

หากคุณต้องการเขียนเอ็นจิ้นเกมด้วยตัวเอง (หรือคุณทำงานกับเอ็นจิ้นการเรนเดอร์เท่านั้น) ข้อความนี้มีค่ามากสำหรับการทำความเข้าใจว่าภาษาสคริปต์สามารถรวมเข้ากับเอ็นจิ้น / เกมได้ดีที่สุดอย่างไร

และถ้าคุณต้องการสร้างภาษาสคริปต์ของคุณเองนี่เป็นหนึ่งในสถานที่ที่ดีที่สุดในการเริ่มต้น (เท่าที่ฉันรู้)

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

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

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

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

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

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

การแก้ไขที่สำคัญ: จากการวิจัยเพิ่มเติมฉันพบว่ามีการโต้เถียงมากกว่าคำจำกัดความของภาษาสคริปต์ (ดูขั้วของ Ousterhout ) คำวิจารณ์หลักของการกำหนดภาษาในฐานะ "ภาษาสคริปต์" คือมันไม่สำคัญต่อไวยากรณ์หรือความหมายของภาษาที่ตีความหรือเรียบเรียง

ในขณะที่ภาษาที่มักจะถูกพิจารณาว่า "ภาษาสคริปต์" มักจะตีความตามธรรมเนียมดั้งเดิมมากกว่าที่จะรวบรวม แต่ความหมายที่สั้นและสั้นของคำว่า "ภาษาสคริปต์" นั้นขึ้นอยู่กับการรวมกันของวิธีการที่ผู้คนมองพวกเขา

โดยทั่วไปแล้วการพูดภาษาอาจถือว่าเป็นภาษาสคริปต์ได้ง่าย (สมมติว่าคุณเห็นด้วยกับการแบ่งขั้วของ Ousterhout) หากเป็นไปตามเกณฑ์ต่อไปนี้ (อ้างอิงจากบทความที่ลิงก์ด้านบน):

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

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