ฉันจะทำให้ตัวแทน A * หลีกเลี่ยงตัวแทนอื่น ๆ ได้อย่างไร


19

ฉันใช้อัลกอริทึม A * หลายเอเจนต์บนแผนที่ย่อย ตัวแทนเคลื่อนไหวในแกน X และ Y เท่านั้น ฉันหลีกเลี่ยงการชนกันระหว่างพวกเขาโดยการตรวจสอบที่อื่น ๆ เมื่อคำนวณเส้นทาง

มันทำงานได้ดียกเว้นสถานการณ์ที่ตัวแทนต้องผ่านไทล์เดียวกันจากทิศทางที่แตกต่างกัน ในสถานการณ์เช่นนี้ทางออกที่ดีที่สุดคือให้ตัวแทนหนึ่งรอให้ตัวแทนผ่าน:

สถานการณ์ตัวอย่าง

นอกจากนี้หากไม่มีทางเดินตอนเหนือเส้นทางเดินก็จะล้มเหลว

ฉันจะใช้อัลกอริทึมดังกล่าวได้อย่างไร


2
คำตอบของวิธีการสร้าง "ปริมาณการใช้ AI"? มีความเกี่ยวข้องที่นี่
Anko

ความเห็นเล็ก ๆ น้อย ๆ 1) ฉันคิดว่าฉันไม่ได้อยู่คนเดียวเมื่อพิจารณา 100% ว่าศัตรูสองคนสามารถทับซ้อนกันได้เมื่อข้าม เฉพาะในกรณีที่คุณเลือกสไตล์ที่เหมือนจริงมากซึ่งจะแปลก แต่ในอีกด้านหนึ่งก็ใช้ได้กับ Zelda 2) คุณอาจพิจารณาอนุญาตเส้นทางที่มีความละเอียดแผนที่ (* 2, * 2) ดังนั้นศัตรูสองคนสามารถข้ามในเส้นทางกว้าง 1 หน่วย 3) คุณอาจออกแบบแผนที่เพื่อให้มีหลายเส้นทางให้เลือก (อาจเป็นข้อ จำกัด ที่น่าสนใจใครจะรู้? :-))
GameAlchemist

คำตอบ:


18

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

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

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


19

แทนที่จะแก้ปัญหาของคุณต่อไปนี้เป็นวิธีใช้มะนาวและทำน้ำมะนาว

เมื่อหลายปีก่อนเพื่อนของฉันกำลังทำงานใน FPS ที่รู้จักกันดีซึ่งมีปัญหาที่คุณอธิบายอย่างแม่นยำ: พื้นที่ที่ จำกัด จะมีตัวละคร AI จำนวนหนึ่งที่มีตำแหน่งที่ต้องการเป็นพิเศษและอัลกอริทึมการค้นหาเส้นทางยังคงชนอยู่เสมอ เข้าหากัน โดยเฉพาะอย่างยิ่งผู้เล่นจะพูดขว้างระเบิดเข้าไปในห้องเล็ก ๆ ที่เต็มไปด้วยศัตรูและตัวละคร AI ในพื้นที่แต่ละคนจะพยายามวิ่งหนีออกไป แต่วิ่งเข้าหากันและจบลงด้วยการหยุดหันหลัง ตีคนอื่นหันไปรอบ ๆ และอื่น ๆ มันดูไม่สมจริงมาก

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

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


1
+1 ฉันชอบสิ่งนี้มันถูกโค่นล้มและใช้งานได้อย่างสมบูรณ์ =)
Patrick Hughes

3

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

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

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

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


ตรงนี้ - ดูเหมือนว่าจะมีการรับรู้ร่วมกันมากว่าการค้นหาเส้นทางหมายถึง A * และนั่นก็ไม่เป็นเช่นนั้น
Steven Stadnicki

2

หากคุณมีระบบการเคลื่อนที่แบบเลี้ยว / เห็บกว่าที่คุณสามารถสร้างกราฟ 3 มิติซึ่งแต่ละช่วงการเปลี่ยนภาพจะย้ายเอเจนต์ไปสู่ลักษณะของแผนที่ในอนาคต จากนั้นให้ตัวแทนแต่ละคนเรียกร้องกระเบื้องที่พวกเขาจะอยู่ในจุดนั้นในอนาคตและทำเครื่องหมายว่าไม่สามารถเข้าถึงได้ แต่ละเอเจนต์จะมีตัวเลือกพิเศษของ "ẅaiting" เป็นตัวเลือกถัดไปซึ่งเป็นวิธีที่ 3 ในการเปลี่ยนผ่านกราฟ สิ่งนี้จะยากขึ้นในระบบของคุณ แต่ควรให้ผลลัพธ์ที่ดีกว่าการรอคอยแบบสุ่ม ยิ่งไปกว่านั้นถ้าคุณอนุญาตให้ตัวแทน 2 คนสื่อสารด้วยการมีหนึ่งในนั้นส่งข้อความว่า "ฉันต้องการส่งคุณ" ถ้ามันเป็นเส้นทางที่สั้นที่สุดที่จะส่งผ่านตัวแทนนั้น


นี่คือกระดาษที่พูดถึงลูกบาศก์เวลานั้น: www0.cs.ucl.ac.uk/staff/D.Silver/web/Applications_files/ …และนี่คือการดำเนินการ: allseeing-i.com/ASIPathFinder
Rakka Rage

0

เมื่อใช้อัลกอริทึมอย่าง A * คุณจะมีละติจูดที่ดีที่สุดในการทำงานกับการวิเคราะห์ต้นทุน

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

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

ในกรณีที่มีเพียงเส้นทางเดียวการค้นหาเส้นทางจะล้มเหลวหรือพวกเขาจะเลื่อนซึ่งกันและกันจนกว่าพวกเขาจะหยุดชะงัก

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

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


0

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

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

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

  1. คุณจะตัดสินใจได้อย่างไรว่ามีอีกวิธีที่ยอมรับได้รอบตัวแทนอื่น ๆ หรือไม่? คุณไม่ต้องการรอตัวแทนคนอื่นหากมีที่ว่างพอที่จะเดินไปรอบ ๆ เขา ความล้มเหลวในการค้นหาเส้นทางเมื่อพิจารณาตัวแทนอื่น ๆ เป็นสัญญาณที่ชัดเจนของสถานการณ์ที่คุณต้องการแก้ไข แต่ในตัวอย่างที่คุณนำมาใช้จะไม่เกิดความล้มเหลวในการค้นหาเส้นทาง แต่คุณสามารถ - ด้วยการคำนวณนิดหน่อย - ตัดสินใจว่าเส้นทางทางเลือก A * ให้คุณไปรอบ ๆ ตัวแทนอื่น ๆ ในวงกลมเล็ก ๆ หรือใช้เส้นทางที่แตกต่างอย่างสิ้นเชิงเช่นทางเดินตอนเหนือ

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


0

หนึ่งในวิธีแก้ปัญหาที่เป็นไปได้คือการปิดการใช้งานการชนกันของหน่วยในจุดที่แคบเช่นนี้

ตัวอย่างเช่นในเกมสตาร์คราฟต์คนงาน (SCVs, Probes, Drones) จะไม่ชนกันเมื่อขุดผลึก

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