ในช่วงหลายทศวรรษที่ผ่านมา โปรแกรมเมอร์เกมได้พัฒนาเทคนิคหลายอย่างเพื่อจัดทำและช่วยแก้ปัญหาในการใช้ "NPC" ที่ชาญฉลาดและสนุกสนาน เทคนิคที่รู้จักมากที่สุดคือ:
- (จำกัด) เครื่องจักรของรัฐ
- ต้นไม้พฤติกรรม
เทคนิคเหล่านี้ช่วยให้โปรแกรมเมอร์เกมและนักออกแบบเกมสามารถย้ำการนำพฤติกรรมของ NPC ไปใช้และยังสามารถให้เหตุผลเกี่ยวกับพฤติกรรมดังกล่าวได้อีกด้วย
ด้วยความนิยมที่เพิ่มขึ้นของ ECS (Entity Component System) คำถามก็เกิดขึ้น: เทคนิคเหล่านั้นเข้ากันได้กับ ECS หรือไม่
ฉันคิดว่าพวกเขาเป็นเช่นนั้น แม้ว่าเราจะต้องตรวจสอบ ในราคาเท่าไหร่ก็ตาม
เริ่มต้นด้วยเครื่องของรัฐ
เครื่องสถานะเป็นตัวเลือกที่ดีมากหากคุณสามารถระบุสถานะแยกกันของ NPC ได้ และหากคุณต้องการจำกัดความเป็นไปได้ในการเปลี่ยนจากรัฐหนึ่งไปอีกรัฐหนึ่ง บ่อยครั้งที่เรายังสามารถกำหนดเหตุการณ์/การกระทำที่จะรับผิดชอบต่อการเปลี่ยนแปลงสถานะ และเหตุการณ์/การกระทำที่จะทริกเกอร์เมื่อมีการดำเนินการเปลี่ยนแปลง
ใน ECS สถานะจะแสดงด้วยส่วนประกอบซึ่งเชื่อมโยงกันโดยเอนทิตี การจัดการสถานะดำเนินการโดยระบบ ซึ่งจะสอบถามเอนทิตีตามประเภทส่วนประกอบ ใน ECS เอนทิตีสามารถเชื่อมโยงกับอินสแตนซ์ประเภทส่วนประกอบบางประเภทได้เพียงอินสแตนซ์เดียวเท่านั้น แต่เนื่องจากเราสามารถมีประเภทส่วนประกอบได้ "ไม่จำกัด" พื้นที่สถานะจึงกลายเป็นอนันต์เช่นกัน
มาดูตัวอย่างที่เป็นประโยชน์มากขึ้น
สัญญาณไฟจราจรสามารถมีได้ 3 สถานะ สีแดง สีเหลือง สีเขียว หากเรากำหนดส่วนประกอบของธงสำหรับทุกรัฐ เราจะสามารถเพิ่มทั้งสามองค์ประกอบให้กับเอนทิตีเดียวกันได้ ซึ่งทำลายตรรกะของเรา เพื่อกำหนดข้อจำกัดให้กับสถานะ เราสามารถกำหนดองค์ประกอบได้เพียงองค์ประกอบเดียว: TrafficLightStateComponent ซึ่งเก็บค่า enum TrafficLightState ซึ่งมี 3 กรณี red, yellow, green ด้วยวิธีนี้ เราสามารถตรวจสอบให้แน่ใจว่าเอนทิตีซึ่งเป็นตัวแทนของสัญญาณไฟจราจรสามารถอยู่ในสถานะที่ถูกต้องเพียงสถานะเดียวเท่านั้น
แล้วข้อจำกัดในเรื่องการเปลี่ยนแปลงของรัฐล่ะ?
สมมติว่าเราต้องการให้แน่ใจว่า red ไม่สามารถเปลี่ยนเป็น green ได้โดยตรงโดยไม่อยู่ในสถานะ yellow จริงๆ แล้วนี่ซับซ้อนกว่ามาก สิ่งที่เราสามารถทำได้คือนำ TrafficLightStateComponent ไปใช้ในลักษณะที่นักพัฒนาซอฟต์แวร์ไม่สามารถตั้งค่าได้โดยตรง แต่ใช้วิธีการเปลี่ยนรูปแบบสาธารณะเท่านั้น ซึ่งจะตรวจสอบว่าการเปลี่ยนแปลงที่เราต้องการดำเนินการนั้นเป็นไปได้หรือไม่
แล้วการดำเนินการกับการเปลี่ยนแปลงสถานะล่ะ?
การเปลี่ยนแปลงสถานะในสถานการณ์ ECS ของเราคือการอัปเดตค่าส่วนประกอบ มีแนวคิดเกี่ยวกับระบบรีแอกทีฟ โดยที่ระบบ (หรือโค้ดบางอย่างในระบบ) จะถูกดำเนินการไม่ใช่ทุกขีด แต่จะดำเนินการเพียงครั้งเดียวเท่านั้น หลังจากการเปลี่ยนแปลงในสถานะเอนทิตีเกิดขึ้น
การใช้งานที่เป็นไปได้ใน Unity ECS
สิ่งที่ฉันอธิบายไว้ในย่อหน้าสุดท้ายสามารถนำไปใช้ได้ในระยะเวลาที่เหมาะสมโดยโปรแกรมเมอร์ผู้มีทักษะ อย่างไรก็ตาม อย่างที่ฉันพูดถึงไปแล้ว เทคนิค AI ไม่เพียงสร้างขึ้นเพื่อทำให้โปรแกรมเมอร์มีความสุขเท่านั้น แต่ยังเพิ่มศักยภาพให้กับนักออกแบบเกมและช่วยให้ทั้งสองฝ่ายเข้าใจ พฤติกรรม NPC ที่ซับซ้อนโดยการแสดงภาพสถานะปัจจุบันในการรันแอปพลิเคชัน
เพื่อให้บรรลุผลทั้งหมดนี้ เราจำเป็นต้องมีเครื่องมือแก้ไข ซึ่งจะช่วยให้เรากำหนดสถานะและการแปลงสถานะได้ เครื่องมือนี้ควรให้ความเป็นไปได้ในการสร้างประเภทส่วนประกอบที่แสดงถึงสถานะและวิธีการแปลงสถานะที่ถูกต้อง เครื่องมือนี้ยังสามารถสร้างโครงสร้างพื้นฐานสำหรับระบบที่มีปฏิกิริยาได้อีกด้วย และสุดท้ายแต่ไม่ท้ายสุด ควรให้ความเป็นไปได้ในการเลือกเอนทิตีที่มีประเภทสถานะขณะรันไทม์ และดูว่าสถานะนั้นอยู่ในสถานะใดในปัจจุบัน
ต้นไม้พฤติกรรม
ในความคิดเห็นที่ต่ำต้อยของฉัน ต้นไม้พฤติกรรมเป็นวิธีที่ดีเยี่ยมในการควบคุมโฟลว์ของอัลกอริธึมที่ซับซ้อน กำหนดค่าได้ และ "แสดงได้" ในระดับหนึ่งของนามธรรม ทุกสิ่งที่เราสามารถทำได้ด้วยแผนผังพฤติกรรมนั้นสามารถทำได้ด้วยภาษาการเขียนโปรแกรมสำหรับวัตถุประสงค์ทั่วไป แต่นักออกแบบเกมไม่สามารถเข้าถึงได้ และเป็นการยากที่จะประเมิน โดยเฉพาะหากคุณมีเครื่องมือในการแสดงภาพสถานะของแผนผังพฤติกรรมในขณะรันไทม์
จากการฉายแนวคิดบน ECS เราตระหนักดีว่าแผนผังพฤติกรรมสามารถเป็นตัวแทนรหัสภายในของระบบได้ โหนดปลายสุด (การดำเนินการและเงื่อนไข) ของแผนผังพฤติกรรมสามารถทำงานได้โดยตรงในโลกของเอนทิตี หรือสำเนาของค่าจากโลกของเอนทิตี
มีคำถามที่น่าสนใจมากมาย
- ต้นไม้ควรถูกกระตุ้นทุกครั้งหรือไม่?
- เราควรสนับสนุนสถานะโหนดที่ทำงานอยู่และในขณะที่ทริกเกอร์แผนผัง ต้นไม้ควรข้ามไปยังโหนดที่ทำงานล่าสุดโดยตรงหรือไม่
- โหนดควรทำงานกับกลุ่มของเอนทิตีหรือในเอนทิตีเดียว?
- เราควรจะทำให้ต้นไม้ทำงานแบบขนานสำหรับทุกเอนทิตีโดยใช้งานหรือไม่?
- ต้นไม้ควรถูกนำเสนออย่างไร (ในตัวแก้ไข)?
- โหนดต้นไม้ควรมีพารามิเตอร์ / สถานะของตัวเองหรือควรกำหนดทุกอย่างด้วยส่วนประกอบและเอนทิตี?
ทั้งหมดนี้เป็นคำถามที่ยอดเยี่ยมและ IMHO เป็นการยากที่จะให้คำตอบที่ชัดเจน ฉันเดาว่าคำตอบเดียวที่สมเหตุสมผลคือ:
ขึ้นอยู่กับ Behavior Tree Tooling ที่คุณจินตนาการ
คุณต้องระบุผลประโยชน์ที่แท้จริงที่คุณต้องการได้รับจากการแสดงอัลกอริทึม NPC พร้อมแผนผังพฤติกรรม และนอกเหนือจากประโยชน์และข้อผิดพลาดแล้ว ข้อจำกัดของ ECS ยังนำมาสู่ประเด็นสำคัญอีกด้วย และอย่าลืม:
ถ้าไม่พอดีก็อย่าฝืน
