การเพิ่มพลังในระบบที่ใช้ส่วนประกอบ


29

ฉันเพิ่งเริ่มได้รับการออกแบบตามส่วนประกอบ ผมไม่ทราบว่าสิ่งที่เป็น"สิทธิ"วิธีที่จะทำเช่นนี้คือ

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

การหุ้มเกราะนั้นได้รับการออกแบบในเกมที่มีส่วนประกอบเป็นอย่างไร

ที่ที่ฉันสับสนคือโล่มีส่วนประกอบสามอย่างที่เกี่ยวข้อง

  • ลดความเสียหาย / กรอง
  • สไปรต์
  • Collider

เพื่อทำให้ความแตกต่างของเกราะที่แย่ลงอาจมีพฤติกรรมมากขึ้นซึ่งทั้งหมดอาจเป็นส่วนประกอบ:

  • เพิ่มสุขภาพสูงสุดของผู้เล่น
  • สุขภาพ regen
  • การโก่งกระสุน
  • ฯลฯ

  1. ฉันคิดอย่างนี้ไหม โล่ควรเป็นเพียงองค์ประกอบที่ยอดเยี่ยมหรือไม่
    ฉันคิดว่านี่เป็นคำตอบที่ผิด ดังนั้นหากคุณคิดว่านี่เป็นวิธีที่จะไปกรุณาอธิบาย

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

  3. โล่ควรเป็นส่วนประกอบที่มีส่วนประกอบอื่นหรือไม่?
    ฉันไม่เคยเห็นหรือได้ยินอะไรแบบนี้ แต่อาจเป็นเรื่องปกติและฉันก็ยังไม่ลึกพอ

  4. โล่ควรเป็นชุดของส่วนประกอบที่เพิ่มเข้ากับเครื่องเล่นหรือไม่
    อาจเป็นไปได้ที่จะมีองค์ประกอบพิเศษในการจัดการอื่น ๆ เช่นพวกเขาสามารถลบออกเป็นกลุ่ม (ทิ้งไว้เบื้องหลังองค์ประกอบการลดความเสียหายโดยไม่ตั้งใจตอนนี้น่าสนุก)

  5. มีอะไรอีกที่เห็นได้ชัดสำหรับคนที่มีประสบการณ์ด้านส่วนประกอบมากกว่าใช่ไหม


ฉันใช้เสรีภาพในการทำให้ชื่อของคุณเฉพาะเจาะจงมากขึ้น
Tetrad

คำตอบ:


11

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

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

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

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

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

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

มีอะไรอีกที่เห็นได้ชัดสำหรับคนที่มีประสบการณ์ด้านส่วนประกอบมากกว่าใช่ไหม

ฉันจะทำอย่างละเอียดเล็กน้อย

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

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

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

Handler Stage    Handler Level     Handler Priority
In               Pre               System High
Out              Invariant         High
                 Post              AboveNormal
                                   Normal
                                   BelowNormal
                                   Low
                                   System Low

In - incoming messages
Out - outgoing messages
Index = ((int)Level | (int)Priority)

คอมโพเนนต์ "stats" ติดตั้งเครื่องมือจัดการข้อความ "ความเสียหาย" ที่ดัชนี In / Invariant / Normal ทุกครั้งที่ได้รับข้อความ "ความเสียหาย" ให้ลดจำนวน HP ตามจำนวน "ค่า"

พฤติกรรมมาตรฐานอย่างเป็นธรรม (ใส่ความต้านทานความเสียหายตามธรรมชาติและ / หรือลักษณะทางเชื้อชาติบางอย่าง)

องค์ประกอบโล่ติดตั้งตัวจัดการข้อความ "ความเสียหาย" ที่ดัชนี In / Pre / High

Every time a "damage" message is received, deplete the shield energy and substract
the shield energy from the damage value, so that the damage down the message
handler pipeline is reduced.

damage -> stats
    stats
        stats.hp -= damage.value

damage -> shield -> stats
    shield
        if(shield.energy) {
            remove_me();
            return;
        }
        damage.value -= shield.energyquantum
        shield.energy -= shield.energyquantum;

     stats
        stats.hp -= damage.value

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

มีเหตุผล? แจ้งให้เราทราบหากฉันสามารถเพิ่มรายละเอียดเพิ่มเติม

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


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

@ นิคฉันไม่เคยพยายามสอนอะไรให้ใครเลย แต่แบ่งปันสิ่งที่ฉันรู้ในเรื่องนี้ อย่างไรก็ตามฉันจะเพิ่มเหตุผลเบื้องหลังว่า "ไม่" ที่หวังว่าจะลบ downvote ที่ไม่พึงประสงค์ :(
เรน

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

@Nick ส่วนใหญ่ของระบบเอนทิตีมีทั้งองค์ประกอบที่เกี่ยวข้องกับตรรกะและกราฟิกดังนั้นในกรณีนี้การมีเอนทิตีสำหรับการป้องกันมีเหตุผลอย่างแน่นอน ในระบบเอนทิตีแบบลอจิคัลล้วนๆ "autonomy" เป็นผลิตภัณฑ์ของความซับซ้อนของวัตถุการพึ่งพาและอายุการใช้งาน ในที่สุดความต้องการคือกษัตริย์ - และการพิจารณาว่าไม่มีความเห็นพ้องที่แท้จริงเกี่ยวกับสิ่งที่เป็นระบบเอนทิตี้ของมีพื้นที่มากมายสำหรับการแก้ไขปัญหาที่เหมาะกับโครงการ :)
เรน

@deft_code โปรดแจ้งให้เราทราบหากฉันสามารถปรับปรุงคำตอบของฉันได้
เรน

4

1) ฉันคิดมากหรือไม่ โล่ควรเป็นเพียงองค์ประกอบที่ยอดเยี่ยมหรือไม่

อาจขึ้นอยู่กับว่าคุณต้องการให้รหัสของคุณสามารถนำมาใช้ซ้ำได้หรือไม่

2) โล่ควรเป็นนิติบุคคลของตัวเองที่ติดตามตำแหน่งของผู้เล่นหรือไม่?

ไม่เว้นแต่ว่าโล่นี้เป็นสิ่งมีชีวิตชนิดหนึ่งที่สามารถเดินไปมาอย่างอิสระในบางช่วง

3) โล่ควรเป็นส่วนประกอบที่มีส่วนประกอบอื่นหรือไม่?

ฟังดูเหมือนเอนทิตี้ของเยอะดังนั้นคำตอบคือไม่

4) โล่ควรเป็นชุดของส่วนประกอบที่เพิ่มเข้ามาในเครื่องเล่นหรือไม่?

มันมีโอกาส

"การลดความเสียหาย / การกรอง"

  • ฟังก์ชั่นองค์ประกอบโล่หลัก

"ผีสาง"

  • มีเหตุผลที่คุณไม่สามารถเพิ่ม SpriteComponent อื่นให้กับตัวละครของคุณ (ในคำอื่น ๆ มากกว่าหนึ่งองค์ประกอบของบางประเภทต่อเอนทิตี)?

"A collider"

  • คุณแน่ใจหรือว่าต้องการอีกอัน ขึ้นอยู่กับกลไกฟิสิกส์ของคุณ คุณสามารถส่งข้อความถึง ColliderComponent ของตัวละครและขอให้เปลี่ยนรูปร่างได้หรือไม่?

"เพิ่มพลังชีวิตสูงสุดของผู้เล่น, ฟื้นฟูพลังชีวิต, กระสุนโก่ง, ฯลฯ "

  • สิ่งประดิษฐ์อื่น ๆ อาจทำเช่นนี้ได้ (ดาบ, รองเท้า, แหวน, คาถา / ยา / การเยี่ยมชมศาลเจ้าเป็นต้น) ดังนั้นสิ่งเหล่านี้ควรเป็นส่วนประกอบ

3

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

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

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

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


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

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


3

โล่ควรเป็นส่วนประกอบที่มีส่วนประกอบอื่นหรือไม่?

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

class Shield : Component
{
    void Start() // happens when the component is added
    {
        sprite = entity.add_component<Sprite>( "shield" );
        collider = entity.add_component<Collider>( whatever );
        //etc
    }

    void OnDestroy() // when the component is removed
    {
        entity.remove_component( sprite );
        entity.remove_component( collider );
    }

    void Update() // every tick
    {
        if( ShouldRemoveSelf() ) // probably time based or something
            entity.remove_component( this );
    }
}

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

มันจะสับสนน้อยกว่าถ้าฉันใช้gameObjectหรืออะไรบางอย่าง เป็นการอ้างอิงถึงวัตถุเกม / นิติบุคคล / สิ่งที่เป็นเจ้าของส่วนประกอบ
Tetrad

0

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

ฉันทำสิ่งที่คล้ายกันสำหรับองค์ประกอบที่เคลื่อนย้ายได้ของฉันมันนับเขตข้อมูลที่เป็นสคริปต์ keyreaction (subclass ของสคริปต์ในเครื่องมือของฉัน) สคริปต์นี้กำหนดวิธีการที่ตามข้อความอินพุตของฉัน เช่นฉันสามารถทำอะไรเช่นนี้ในไฟล์นิยามของฉัน tempalte

camera template
    moveable
    {
        keyreaction = "scriptforcameramoves"

    }  

player template
    moveable
    {
        keyreaction = "scriptfroplayerkeypress"

    }  

จากนั้นในองค์ประกอบที่เคลื่อนย้ายได้ของฉันในระหว่างการลงทะเบียนข้อความฉันลงทะเบียนสคริปต์วิธีการ (รหัสใน C #)

Owner.RegisterHandler<InputStateInformation>(MessageType.InputUpdate, kScript.Do);

แน่นอนว่าสิ่งนี้ขึ้นอยู่กับวิธีการทำของฉันตามรูปแบบของฟังก์ชั่นที่ RegisterHandler ของฉันใช้ ในกรณีนี้ (ผู้ส่ง IComponent, อาร์กิวเมนต์ประเภท ref)

ดังนั้น "สคริปต์" ของฉัน (ในกรณีของฉันยัง C # เพียงรวบรวมรันไทม์) กำหนด

 public class CameraMoveScript : KeyReactionScript
{
 public override void Do(IComponent pSender, ref InputStateInformation inputState)
 {
    //code here
 }
}

และ KeyReactionScript คลาสพื้นฐานของฉัน

public class KeyReactionScript : Script
{
      public virtual void Do(IComponent pSender, ref InputStateInformation inputState);
}

หลังจากนั้นเมื่อคอมโพเนนต์อินพุตส่งข้อความชนิด MessageTypes.InputUpdate ด้วยประเภทเช่นนั้น

 InputStateInformation myInputState = InputSystem.GetInputState();
 SendMessage<InputStateInformation>(MessageTypes.InputUpdate, ref myInputState);

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

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

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