ฉันจะทำอย่างไรเพื่อหลีกเลี่ยงการตั้งค่าสถานะและตรวจสอบครั้งเดียวตลอดทั้งรหัสของฉัน

พิจารณาการ์ดเกมเช่นHearthstone

มีการ์ดหลายร้อยใบที่ทำสิ่งที่หลากหลายซึ่งบางอย่างก็มีเอกลักษณ์แม้แต่บัตรเดียว! ตัวอย่างเช่นมีการ์ด (เรียกว่า Nozdormu) ที่ช่วยลดผู้เล่นหันไปเพียง 15 วินาที!

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

คุณเคยดูระบบส่วนประกอบของเอนทิตีและกลยุทธ์การส่งข้อความเหตุการณ์หรือไม่?

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

หากเอฟเฟกต์มีเงื่อนไขอย่างต่อเนื่อง (ใช้ได้กับการหมุน X แต่ใช้เฉพาะในบางสถานการณ์) คุณอาจต้องตรวจสอบเงื่อนไขเหล่านั้นในระยะต่าง ๆ

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

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

RobStone อยู่ในเส้นทางที่ถูกต้อง แต่ฉันต้องการอธิบายอย่างละเอียดเพราะนี่คือสิ่งที่ฉันทำเมื่อฉันเขียน Dungeon Ho!, Roguelike ที่มีระบบเอฟเฟกต์ซับซ้อนสำหรับอาวุธและคาถา

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

Effect type: deal damage (enumeration, string, what-have-you)
Effect amount: 20
Source: my weapon
Target: opponent
Effect Cost: 20
Cost Type: Mana

จากนั้นเมื่อเอฟเฟกต์ยิงให้มีรูทีนทั่วไปที่จัดการกับการประมวลผล เหมือนคนงี่เง่าฉันใช้คำสั่ง case / switch ขนาดใหญ่:

switch (effect_type)
{
     case DAMAGE:

     break;
}

แต่วิธีที่ดีกว่าและยิ่งกว่านั้นคือผ่านทาง polymorphism สร้างคลาส Effect ที่ล้อมข้อมูลทั้งหมดนี้สร้างคลาสย่อยสำหรับเอฟเฟกต์แต่ละประเภทจากนั้นให้คลาสนั้นแทนที่เมธอด onExecute () เฉพาะสำหรับคลาส

class Effect
{
    Object source;
    int amount;

    public void onExecute(Object target)
    {
          // Do nothing
    }
}

class DamageEffect extends Effect
{
    public void onExecute(Object target)
    {
          target.health -= amount;
    }
}

ดังนั้นเราต้องมีคลาส Effect พื้นฐานจากนั้นเป็นคลาส DamageEffect ด้วยเมธอด onExecute () ดังนั้นในโค้ดการประมวลผลของเราที่เราต้องการ

Effect effect = card.getActiveEffect();

effect.onExecute();

วิธีจัดการกับการรู้ว่ามีอะไรในการเล่นคือการสร้างรายการ Vector / Array / linked / etc ของเอฟเฟกต์ที่ใช้งานอยู่ (ของประเภทเอฟเฟกต์, คลาสฐาน) ที่ติดอยู่กับวัตถุใด ๆ (รวมถึง playfield / "เกม") ดังนั้นแทนที่จะต้องตรวจสอบว่ามีเอฟเฟกต์พิเศษอยู่ในการเล่นหรือไม่ วัตถุและปล่อยให้พวกเขาดำเนินการ หากเอฟเฟกต์ไม่ได้ติดอยู่กับวัตถุก็ไม่ได้อยู่ในการเล่น

Effect effect;

for (int o = 0; o < objects.length; o++)
{
    for (int e = 0; e < objects[o].effects.length; e++)
    {
         effect = objects[o].effects[e];

         effect.onExecute();
    }
}

ฉันจะเสนอคำแนะนำเล็กน้อย บางคนขัดแย้งกัน แต่อาจมีประโยชน์บ้าง

พิจารณารายการเทียบกับธง

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

พิจารณารายการและการแจกแจง

คุณสามารถเพิ่มเขตข้อมูลบูลีนไปยังคลาสไอเท็มของคุณคืออะไรนั่นคือและอะไร หรือคุณสามารถมีรายการของสตริงหรือองค์ประกอบ enum เช่น {“ isAThis”,“ isAThat”} หรือ {IS_A_THIS, IS_A_THAT} ด้วยวิธีนี้คุณสามารถเพิ่มอันใหม่ในการแจงนับ (หรือ const const) โดยไม่ต้องเพิ่มฟิลด์ ไม่ใช่ว่ามีอะไรผิดปกติกับการเพิ่มเขตข้อมูล ...

พิจารณาพอยน์เตอร์ของฟังก์ชัน

แทนที่จะเป็นรายการของแฟล็กหรือ enums สามารถมีรายการของการดำเนินการเพื่อดำเนินการสำหรับรายการนั้นในบริบทที่แตกต่างกัน (Entity-ish ... )

พิจารณาวัตถุ

บางคนชอบวิธีที่ขับเคลื่อนด้วยข้อมูลหรือใช้สคริปต์หรือส่วนประกอบเอนทิตี แต่ลำดับชั้นวัตถุแบบเก่าก็มีค่าควรพิจารณาเช่นกัน คลาสพื้นฐานจำเป็นต้องยอมรับการกระทำเช่น“ เล่นการ์ดนี้สำหรับเทิร์นเฟส B” หรืออะไรก็ตาม จากนั้นการ์ดแต่ละประเภทสามารถแทนที่และตอบสนองตามความเหมาะสม อาจมีวัตถุผู้เล่นและวัตถุเกมด้วยเช่นกันดังนั้นเกมสามารถทำสิ่งต่าง ๆ เช่นถ้า (player-> isAllowedToPlay ()) {เล่น ...

พิจารณาความสามารถในการดีบัก

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

ในที่สุดการปรับโครงสร้างใหม่: พิจารณาการทดสอบหน่วย

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

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

void test1()
{
   Game game;
   game.addThis();
   game.setupThat(); // use primary or backdoor API to get game to known state

   game.playCard(something something).

   int x = game.getSomeInternalState;
   assertEquals(“did it do what we wanted?”, x, 23); // fail if x isn’t 23
}

อย่างที่คุณเห็นการทำให้การเรียก API ระดับบนสุดของเกม (หรือเครื่องเล่น, การ์ด, & c) มีความเสถียรเป็นกุญแจสำคัญในกลยุทธ์การทดสอบหน่วย

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

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