Unity เป็นแพลตฟอร์มที่มีมาอย่างยาวนานและมีการพัฒนาอย่างต่อเนื่อง อย่างไรก็ตาม เมื่อทำงานกับหลายโปรเจ็กต์ในเวลาเดียวกัน คุณยังคงประสบปัญหาในการใช้แหล่งข้อมูลทั่วไป (.cs) ไลบรารี (.dll) และเนื้อหาอื่นๆ (รูปภาพ เสียง แบบจำลอง รูปแบบสำเร็จรูป) ในบทความนี้ เราจะพูดถึงประสบการณ์ของเราเกี่ยวกับวิธีแก้ปัญหาแบบเนทีฟสำหรับปัญหาดังกล่าวสำหรับ Unity
วิธีการกระจายทรัพยากรที่ใช้ร่วมกัน
มีหลายวิธีในการใช้ทรัพยากรที่ใช้ร่วมกันสำหรับโครงการต่างๆ แต่แต่ละวิธีมีข้อดีและข้อเสีย
1. การทำสำเนา - "ด้วยมือ" เราทำซ้ำทรัพยากรระหว่างโครงการ
จุดเด่น:
- เหมาะสำหรับทรัพยากรทุกประเภท
- ไม่มีปัญหาการพึ่งพา
- ไม่มีปัญหากับ GUID ของเนื้อหา
จุดด้อย:
- ที่เก็บยักษ์
- ไม่มีตัวเลือกสำหรับการกำหนดเวอร์ชัน
- ความยากลำบากในการติดตามการเปลี่ยนแปลงทรัพยากรที่ใช้ร่วมกัน
- ความยากลำบากในการอัปเดตทรัพยากรที่ใช้ร่วมกัน
2.
จุดเด่น:
- คุณสามารถทำงานกับแหล่งที่มา
- คุณสามารถกระจายสินทรัพย์
- ไม่มีปัญหาการพึ่งพา
จุดด้อย:
- จำเป็นต้องมีทักษะ Git
- Git ไม่เป็นมิตรกับไฟล์ไบนารี - คุณต้องรวม LFS
- การควบคุมการเข้าถึงสำหรับที่เก็บ
- ความยากลำบากในการอัพเกรดและดาวน์เกรด
- การชนกันของ GUID เป็นไปได้และไม่มีพฤติกรรมที่ชัดเจนในส่วนของ Unity เพื่อแก้ไข
3. NuGet - การกระจายไลบรารีที่ใช้ร่วมกันผ่านแพ็คเกจ NuGet
จุดเด่น:
- ทำงานสะดวกกับโครงการที่ไม่ขึ้นอยู่กับ Unity
- การแก้ไขเวอร์ชันและการอ้างอิงที่สะดวก
จุดด้อย:
- Unity ไม่ทราบวิธีการทำงานกับแพ็คเกจ NuGet ทันที (คุณสามารถค้นหา NuGet Package Manager สำหรับ Unity บน GitHub ซึ่งแก้ไขปัญหานี้ได้ แต่มีความแตกต่างเล็กน้อย)
- ความยากลำบากในการกระจายสินทรัพย์ประเภทอื่น
4. Unity Package Manager - การกระจายทรัพยากรที่ใช้ร่วมกันผ่านโซลูชันเนทีฟสำหรับ Unity
จุดเด่น:
- อินเทอร์เฟซแบบเนทีฟสำหรับการทำงานกับแพ็กเกจ
- ป้องกันการเขียนทับไฟล์ .meta ในแพ็คเกจในกรณีที่ GUID ขัดแย้งกัน
- ความสามารถในการกำหนดเวอร์ชัน
- ความสามารถในการแจกจ่ายทรัพยากรทุกประเภทสำหรับ Unity
จุดด้อย:
- ความขัดแย้งของ GUID ยังคงเกิดขึ้นได้
- ไม่มีเอกสารสำหรับการดำเนินการ
วิธีหลังมีข้อดีมากกว่าข้อเสีย อย่างไรก็ตามตอนนี้ยังไม่ได้รับความนิยมมากนักเนื่องจากขาดเอกสารดังนั้นเราจะพูดถึงรายละเอียด
ผู้จัดการแพคเกจความสามัคคี
Unity Package Manager (ต่อไปนี้เรียกว่า UPM) เป็นเครื่องมือจัดการแพ็คเกจ ถูกเพิ่มเข้ามาใน Unity 2018.1 และใช้สำหรับแพ็คเกจที่พัฒนาโดย Unity Technologies เท่านั้น อย่างไรก็ตาม ตั้งแต่เวอร์ชัน 2018.3 เป็นต้นมา สามารถเพิ่มแพ็คเกจแบบกำหนดเองได้
ส่วนต่อประสานตัวจัดการแพ็คเกจ Unity
แพ็คเกจไม่ได้อยู่ในแหล่งที่มาของโครงการ (ไดเรกทอรีสินทรัพย์) พวกเขาอยู่ในไดเร็กทอรีแยกต่างหาก %projectFolder%/Library/PackageCache
และไม่ส่งผลกระทบต่อโครงการ แต่อย่างใด การกล่าวถึงเฉพาะในซอร์สโค้ดอยู่ในไฟล์ packages/manifest.json
.
แพ็คเกจในระบบไฟล์โครงการ
แหล่งที่มาของแพ็คเกจ
UPM สามารถใช้แหล่งที่มาของแพ็คเกจได้หลายแหล่ง:
1. ระบบไฟล์
จุดเด่น:
- ความเร็วในการใช้งาน
- ไม่ต้องใช้เครื่องมือของบุคคลที่สาม
จุดด้อย:
- ความซับซ้อนของการกำหนดเวอร์ชัน
- การเข้าถึงระบบไฟล์ร่วมกันเป็นสิ่งจำเป็นสำหรับทุกคนที่ทำงานกับโครงการ
2. พื้นที่เก็บข้อมูล Git
จุดเด่น:
- สิ่งที่คุณต้องมีคือที่เก็บ Git
จุดด้อย:
- คุณไม่สามารถสลับระหว่างเวอร์ชันผ่านหน้าต่าง UPM
- ใช้ไม่ได้กับที่เก็บ Git ทั้งหมด
3. พื้นที่เก็บข้อมูล npm
จุดเด่น:
- รองรับฟังก์ชัน UPM อย่างสมบูรณ์และใช้เพื่อแจกจ่ายแพ็คเกจ Unity อย่างเป็นทางการ
จุดด้อย:
- ขณะนี้ละเว้นแพ็คเกจเวอร์ชันสตริงทั้งหมดยกเว้น "-preview"
เราจะดูการใช้งาน UPM + npm ด้านล่าง บันเดิลนี้สะดวกเพราะช่วยให้คุณสามารถทำงานกับทรัพยากรประเภทใดก็ได้และจัดการเวอร์ชันของแพ็คเกจ และยังรองรับอินเทอร์เฟซ UPM แบบเนทีฟอย่างสมบูรณ์
ในฐานะที่เก็บ npm คุณสามารถใช้
การตั้งค่าสภาพแวดล้อม
ก่อนอื่นคุณต้องติดตั้ง
สร้างแพ็คเกจ
ในการสร้างแพ็คเกจ คุณต้องใส่ไฟล์ package.json
ซึ่งจะอธิบายไปยังไดเร็กทอรีที่มีเนื้อหาของแพ็คเกจนี้ คุณต้องทำสิ่งต่อไปนี้:
ไปที่ไดเรกทอรีโครงการที่เราต้องการสร้างแพ็คเกจ
รันคำสั่ง npm init และป้อนค่าที่ต้องการระหว่างไดอะล็อก สำหรับชื่อ ให้ระบุชื่อในรูปแบบโดเมนย้อนกลับ เช่น com.plarium.somepackage
เพื่อความสะดวกในการแสดงชื่อแพ็คเกจ ให้เพิ่มคุณสมบัติ displayName ใน package.json แล้วกรอกข้อมูลลงไป
เนื่องจาก npm เป็นแบบ js ไฟล์จึงมีคุณสมบัติหลักและสคริปต์ที่เราไม่ต้องการ ซึ่ง Unity ไม่ได้ใช้ เป็นการดีกว่าที่จะลบออกเพื่อไม่ให้คำอธิบายของแพ็คเกจอุดตัน ไฟล์ควรมีลักษณะดังนี้:
- ไปที่ไดเรกทอรีโครงการที่เราต้องการสร้างแพ็คเกจ
- รันคำสั่ง npm init และป้อนค่าที่ต้องการระหว่างไดอะล็อก สำหรับชื่อ ให้ระบุชื่อในรูปแบบโดเมนย้อนกลับ เช่น com.plarium.somepackage
- เพื่อความสะดวกในการแสดงชื่อแพ็คเกจ ให้เพิ่มคุณสมบัติ displayName ใน package.json แล้วกรอกข้อมูลลงไป
- เนื่องจาก npm เป็นแบบ js ไฟล์จึงมีคุณสมบัติหลักและสคริปต์ที่เราไม่ต้องการ ซึ่ง Unity ไม่ได้ใช้ เป็นการดีกว่าที่จะลบออกเพื่อไม่ให้คำอธิบายของแพ็คเกจอุดตัน ไฟล์ควรมีลักษณะดังนี้:
{ "name": "com.plarium.somepackage", "displayName": "Some Package", "version": "1.0.0", "description": "Some Package Description", "keywords": [ "Unity", "UPM" ], "author": "AUTHOR", "license": "UNLICENSED" }
- เปิด Unity และสร้างไฟล์ .meta สำหรับ package.json (Unity ไม่เห็นเนื้อหาที่ไม่มีไฟล์ .meta แพ็คเกจ Unity เปิดอ่านอย่างเดียว)
ส่งพัสดุ
ในการส่งแพ็คเกจ คุณต้องรันคำสั่ง: npm publish --registry *адрес до хранилища пакетов*
.
การติดตั้งและอัพเดตแพ็คเกจผ่าน Unity Package Manager
ในการเพิ่มแพ็คเกจในโครงการ Unity คุณต้อง:
- เขียนลงไฟล์
manifest.json
ข้อมูลเกี่ยวกับแหล่งที่มาของแพ็คเกจ ในการทำเช่นนี้ คุณต้องเพิ่มพร็อพเพอร์ตี้scopedRegistries
และระบุขอบเขตและที่อยู่ของแหล่งที่มาที่จะค้นหาขอบเขตเฉพาะ"scopedRegistries": [ { "name": "Main", "url": "адрес до хранилища пакетов", "scopes": [ "com.plarium" ] } ]
- ไปที่ Unity และเปิดหน้าต่าง Package Manager (การทำงานกับแพ็คเกจที่กำหนดเองนั้นไม่แตกต่างจากการทำงานกับแพ็คเกจในตัว)
- เลือกแพ็คเกจทั้งหมด
- ค้นหาแพ็คเกจที่ต้องการและเพิ่ม
การทำงานกับแหล่งที่มาและการดีบัก
เพื่อให้แหล่งที่มาเชื่อมต่อกับโครงการ คุณต้องสร้าง
การใช้แพ็คเกจไม่จำกัดขอบเขตสำหรับการดีบัก อย่างไรก็ตาม เมื่อทำงานกับแพ็คเกจใน Unity คุณไม่สามารถไปที่ IDE โดยคลิกที่ข้อผิดพลาดในคอนโซลหากเกิดข้อผิดพลาดในแพ็คเกจ นี่เป็นเพราะ Unity ไม่เห็นสคริปต์เป็นไฟล์แยกต่างหาก เนื่องจากเมื่อใช้ Assembly Definition สคริปต์จะถูกรวบรวมไว้ในไลบรารีและรวมไว้ในโปรเจ็กต์ เมื่อทำงานกับแหล่งที่มาจากโปรเจ็กต์ การเปลี่ยนคลิกผ่านไปยัง IDE จะพร้อมใช้งาน
สคริปต์ในโครงการที่มีแพ็คเกจที่เชื่อมต่อ:
สคริปต์จากแพ็คเกจพร้อมเบรกพอยต์ที่ใช้งานได้:
แก้ไขด่วนสำหรับแพ็คเกจ
แพ็คเกจ Unity ที่เพิ่มในโครงการเป็นแบบอ่านอย่างเดียว แต่สามารถแก้ไขได้ในแคชแพ็คเกจ สำหรับสิ่งนี้คุณต้อง:
- ไปที่แพ็คเกจในแคชแพ็คเกจ
- ทำการเปลี่ยนแปลงที่จำเป็น
- อัปเดตเวอร์ชันในไฟล์
package.json
. - ส่งพัสดุ
npm publish --registry *адрес до хранилища пакетов*
. - อัปเดตเวอร์ชันของแพ็คเกจเป็นเวอร์ชันที่ถูกต้องผ่านอินเทอร์เฟซ UPM
ข้อขัดแย้งในการนำเข้าแพ็คเกจ
เมื่อนำเข้าแพ็คเกจ ข้อขัดแย้งของ GUID ต่อไปนี้อาจเกิดขึ้น:
- แพ็คเกจ - แพ็คเกจ หากพบว่าเมื่อนำเข้าแพ็กเกจแล้วพบว่าแพ็กเกจที่เพิ่มมีเนื้อหาที่มี GUID เดียวกัน เนื้อหาที่มี GUID ที่ตรงกันจากแพ็กเกจที่นำเข้าจะไม่ถูกเพิ่มลงในโปรเจ็กต์
- แพ็คเกจเป็นโครงการ เมื่ออิมพอร์ตแพ็กเกจแล้วพบว่าโปรเจ็กต์มีเนื้อหาที่มี GUID ที่ตรงกัน แอสเซทจากแพ็กเกจจะไม่ถูกเพิ่มลงในโปรเจ็กต์ อย่างไรก็ตาม สินทรัพย์ที่ขึ้นอยู่กับพวกเขาจะเริ่มใช้สินทรัพย์จากโครงการ
การโอนสินทรัพย์จากโครงการไปยังแพ็คเกจ
หากคุณถ่ายโอนเนื้อหาจากโปรเจ็กต์ไปยังแพ็กเกจขณะที่ Unity เปิดอยู่ ฟังก์ชันการทำงานจะถูกรักษาไว้ และลิงก์ในเนื้อหาที่ขึ้นต่อกันจะเริ่มใช้เนื้อหาจากแพ็กเกจ
มันเป็นสิ่งสำคัญ: เมื่อคัดลอกเนื้อหาจากโครงการไปยังแพ็คเกจ ความขัดแย้งระหว่างแพ็คเกจกับโครงการที่อธิบายไว้ในส่วนด้านบนจะเกิดขึ้น
วิธีแก้ปัญหาที่เป็นไปได้สำหรับความขัดแย้ง
- กำหนด GUID ใหม่ตามอัลกอริทึมของตัวเองเมื่อนำเข้าเนื้อหาทั้งหมดเพื่อหลีกเลี่ยงการชนกัน
- การเพิ่มเนื้อหาทั้งหมดในโครงการเดียวโดยแยกเป็นแพ็คเกจในภายหลัง
- สร้างฐานข้อมูลที่มี GUID ของเนื้อหาทั้งหมดและตรวจสอบเมื่อส่งแพ็คเกจ
ข้อสรุป
UPM เป็นโซลูชันใหม่สำหรับการแจกจ่ายทรัพยากรที่ใช้ร่วมกันใน Unity ซึ่งเป็นทางเลือกที่คุ้มค่ากับวิธีการที่มีอยู่ คำแนะนำที่อธิบายไว้ในบทความเกิดขึ้นจากกรณีจริง เราหวังว่าคุณจะพบว่ามีประโยชน์
ที่มา: will.com