การระบุเนื้อหาในเครื่องมือสร้างเกม?


12

ฉันต้องการระบุเนื้อหาที่โหลด แต่ไม่ทราบว่าควรเลือกแบบใด มี 2 ​​ตัวเลือก:

  • ชื่อ (สตริง)

    • นี่เป็นวิธีที่ง่ายที่สุดและรวดเร็วด้วย unordered_map (O (1)) แต่วิธีที่ช้ากว่านั้นใช้จำนวนเต็ม
    • เข้าใจได้ง่ายในรหัส
  • จำนวนเต็ม

    • ที่เร็วที่สุด
    • ไม่เข้าใจในโค้ด

ฉันรู้ว่าสายไม่ปลอดภัยหรือเร็ว แต่มันแย่ขนาดนั้นหรือนับว่าแย่ในชื่อ AAA เท่านั้น? ฉันสามารถสร้าง enums ใช้จำนวนเต็ม แต่ถ้าฉันโหลดฉากสินทรัพย์ ฯลฯ จากไฟล์ตอนรันไทม์ฉันไม่สามารถใช้ enums ได้ มีวิธีทำให้จำนวนเต็มเหล่านี้สามารถอ่านได้ถ้าพวกเขาจะถูกสร้างขึ้นที่ runtime?

ฉันรู้ว่าปัญหานี้มีเธรดไม่กี่ทั่วอินเทอร์เน็ต แต่ฉันไม่สามารถหาวิธีที่สำคัญในกรณีนี้


10
ทำไมไม่ใช้ทั้งสองอย่าง รุ่นสตริงเชื่อมต่อกับ Dictionary <string, int> ซึ่งจะเรียกพจนานุกรม <int, Asset> คุณสามารถหลีกเลี่ยงเลเยอร์ตามสตริงในรหัส แต่ใช้เลเยอร์ตามสตริงสำหรับการโต้ตอบกับผู้ใช้
Krythic

2
ฉันต้องการที่ @ Krythic's point หากรหัสของคุณชอบความเร็วเป็นจำนวนเต็มให้โค้ดของคุณใช้จำนวนเต็ม หากผู้ใช้ของคุณชอบสตริงสำหรับความชัดเจนให้ผู้ใช้ของคุณใช้สตริง ทั้งสองสามารถอยู่ร่วมกันได้อย่างมีความสุข (และคุณสามารถรวบรวมรุ่นสตริงในการพัฒนาสร้างเท่านั้นหากคุณต้องการข้ามค่าโสหุ้ยโดยสิ้นเชิงในการเปิดตัว)
DMGregory

ปัญหาเดียวกันในบริบทที่แตกต่างกันเล็กน้อย: วิธีการใช้งานไอเท็มต่างกัน - อะไรคือความแตกต่าง?
Philipp

คำตอบ:


19

คุณสามารถรองรับได้ทั้ง

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

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

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


กรณีของฉัน: ฉันต้องการเปลี่ยนเนื้อหาของวัตถุดังนั้นฉันจึงส่งคำขอพร้อมชื่อวัสดุใหม่ (สตริง) จากนั้นในระบบกราฟิกมีการค้นหาในแผนที่ <string, pointer> unorderered และตัวชี้วัสดุของวัตถุจะถูกแทนที่ด้วยตัวชี้ใหม่ ดังนั้นในกรณีของฉันฉันไม่ต้องแปลงเป็นจำนวนเต็มหรือ (เพราะฉันแปลงเป็นตัวชี้และใน algorhytms บ่อยครั้งที่ฉันใช้พอยน์เตอร์ฉันจะใช้สตริงสำหรับสิ่งต่าง ๆ เป็นครั้งคราว)
Tudvari

หรือฉันควรใช้จำนวนเต็ม ID-s แทนพอยน์เตอร์ทุกที่ที่เป็นไปได้? (ดังนั้นฉันไม่จำเป็นต้องรวมไฟล์ส่วนหัวของเนื้อหาเช่น) ตอนนี้องค์ประกอบของ renderer จะเก็บตัวชี้ของวัสดุที่ใช้ซึ่งสามารถใช้งานได้โดยตรงโดยโปรแกรมกราฟิก แต่ฉันต้องรวม Material.h . แต่เมื่อฉันเก็บเฉพาะจำนวนเต็มที่ส่วนประกอบ renderer ฉันไม่จำเป็นต้องรวม Material.h แต่ฉันต้องทำการค้นหาตามจำนวนเต็มในอาร์เรย์พอยน์เตอร์ ฉันคิดว่าอันหลังดีกว่า ใช่ไหม? ฉันควรกำหนดสิ่งนี้ใหม่หรือไม่?
Tudvari

1

ในโครงการของฉันฉันใช้สตริงที่แฮชซึ่งจะถูกแปลงในเวลารวบรวมเป็นตัวเลข (ฉันต้องการ!) ดังนั้นเมื่อฉันต้องการทรัพยากรเช่นพื้นผิวฉันก็เรียก

MngTexture->get(hash("my_texture"))

และเนื่องจากฉันสร้างกรอบงานเอนทิตีที่เรียบง่ายและฉันจำเป็นต้องโหลดข้อมูลส่วนประกอบจากไฟล์ฉันสร้างภาษาง่าย ๆ เช่น json เพื่อเก็บข้อมูล แต่สามารถคอมไพล์ได้ (เปลี่ยนคำและตัวอักษรจากตัวเลขเป็นตัวเลขและจากสตริงเป็นค่าแฮช) . ตัวอย่างเช่นถ้าฉันต้องการเชื่อมโยงพื้นผิวด้วยแฮช ID ("my_texture") กับ "ball.PNG" ในไฟล์ข้อมูลของฉันฉันจะมี

|my_texture| = "ball.PNG"

ที่ไหน | | เป็นโอเปอเรเตอร์ที่บอกให้คอมไพเลอร์แฮชคำข้างใน

ดังนั้นโดยทั่วไปฉันใช้สตริงที่ถูกแมปไปยัง ints ในเวลารวบรวม (ดังนั้นพวกเขาจึงไม่มีค่าใช้จ่าย) ทั้งในรหัสจริงและในไฟล์ที่เป็นกระแสสำหรับการโหลดส่วนประกอบ สำหรับการคำนวณแฮชเวลารวบรวมเพียงแค่ google มันเป็นฟังก์ชั่นที่เรียบง่ายของรหัส 5-10 บรรทัด

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

หวังว่านี่จะช่วยได้


0

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

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.