ประสิทธิภาพลดลงในการนำ A * ไปใช้ในเกมป้องกันหอคอย


9

ฉันกำลังสร้างเกม Tower Defense ใน Flash โดยไม่มีเส้นทางที่กำหนดไว้ล่วงหน้า

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

นี่เป็นปัญหาการใช้งานหรือเป็น 40x40 มากเกินไปหรือไม่

แก้ไข:

โครงสร้างของรหัสของฉัน:

  • ข้อมูลทั้งหมดจะถูกบันทึกในเซลล์อาร์เรย์ 2 มิติ
  • แต่ละเซลล์มีพาเรนต์ในทิศทางพา ธ (1-8 ตามเข็มนาฬิกา) และอาร์เรย์ที่เข้ารหัสระดับบิตของลูกในพา ธ (ทุกบิตแทนค่าเด็ก)
  • การค้นหาดำเนินการโดย A * ด้วยการประมาณระยะทางยูคลิด

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

1
เมื่อฉันติดตั้ง A * เป็นครั้งสุดท้ายที่ฉันจำได้ว่ามันทำงานผ่านกริด 64x64 ในเวลา 1ms ดังนั้นดูเหมือนว่าจะมีปัญหากับการใช้งานของคุณ ฉันแนะนำให้โพสต์รหัสของคุณหรือแก่นสารของมันเพื่อให้เราสามารถช่วยคุณได้มากขึ้น
Marc Müller

ดูการแก้ไขที่ฉันได้เพิ่ม
Dani

1
ถ้า 40x40 ช้าเกินไปโอกาสดีที่คุณทำสิ่งผิดพลาดมาก โพสต์รหัสหรือโปรไฟล์ของคุณ อีกทางหนึ่งคือขยายขนาดและดูว่าเกิดอะไรขึ้น - หากตาราง 80x80 ใช้เวลานานกว่าสี่เท่าคุณจะพบสิ่งที่แตกหักอย่างมาก
ZorbaTHut

ขอชื่อเรื่องได้มากกว่านี้หน่อยได้ไหม?
tenpn

คำตอบ:


4

ฉันไม่สามารถแสดงความคิดเห็นได้ แต่โปรไฟล์แรกใน Flex ทุกอย่างอื่นคาดเดาได้


ฉันจะทำโปรไฟล์แฟลชโครงการให้ยืดหยุ่นได้อย่างไร?
Dani

ใช่และไม่. ฉันไม่คิดว่าคุณจะโหลดโครงการแฟลชโดยตรง ฉันคิดว่าคุณอาจจะสามารถโปรไฟล์ swf โดยไม่มีแหล่งที่มาและยังคงได้รับข้อมูลระดับฟังก์ชั่น ฉันจะใช้ google เพื่อค้นหา "การทำโปรไฟล์โครงการแฟลชแบบยืดหยุ่น" หรือคล้ายกัน ฉันทำและได้สิ่งนี้: flexblog.edchipman.ca/ซึ่งดูมีแนวโน้ม
Jonathan Fischoff

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

13

ฉันสมมติว่า TD คือ 'Tower Defense'

ฉันคิดว่า A * กำลังจะลงน้ำสำหรับเรื่องนี้

ในช่วงเริ่มต้นของเกมน้ำท่วมเติมพื้นที่เกมจากจุดทางออกเพื่อสร้างแผนที่การเคลื่อนไหว:

 |---------|
 |5|4|3|3|3|
 |5|4|3|2|2|
->5|4|3|2|1->
 |5|4|3|2|2|
 |5|4|3|3|3|
 |---------|

และการเคลื่อนไหวอยู่เสมอกับสี่เหลี่ยมจัตุรัสที่มีค่าต่ำกว่า

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

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

วิธีที่ง่ายกว่าคือการเติมน้ำท่วมซ้ำอีกครั้ง


6
การเติมน้ำท่วมซ้ำอีกครั้งมีราคาแพงกว่าการทำ A * สำหรับหน่วยจำนวนน้อย - ประมาณความยาวของบอร์ด - อย่างน้อยในแง่อัลกอริธึม (และเนื่องจากนี่คือแฟลชค่าคงที่ที่ไม่ใช่อัลกอริธึม ไม่ควรใช้อย่างมีประสิทธิภาพ) แต่นี้เป็นรูปแบบที่ดีมากสำหรับหน่วยการสื่อสารจำนวนมากและจะเรียกว่าการแพร่กระจายการทำงานร่วมกัน - scalablegamedesign.cs.colorado.edu/wiki/Collaborative_Diffusion

@Joe Wreschnig: การเชื่อมโยงที่ดีว้าว ฉันเคยใช้เทคนิคนั้นมาก่อน แต่ไม่เคยรู้เลยว่ามันถูกเรียกว่าอะไร ขอบคุณ
tenpn

@ โจตราบใดที่มีอุปสรรคอย่างน้อยในแผนที่ฉันไม่คิดว่ามันจะไม่มีประสิทธิภาพมากกว่าการเรียก A * นั่นคือฉันเชื่อว่าเฉพาะแผนที่ที่เปิดกว้างและเกือบจะไม่มีสิ่งกีดขวางเท่านั้น
edA-qa mort-ora-y

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

@ โจนั่นคือสิ่งที่ฉันโต้เถียงว่าแม้จะมีหอคอยเพียงไม่กี่แห่ง A * ก็จะมีโอกาสสัมผัสได้เกือบทุกพื้นที่ แต่สำหรับอสูรกาย N ตัวมันต้องการเพียง total_squares / N เท่านั้นที่จะมีประสิทธิภาพน้อยกว่าการเติมน้ำท่วม
edA-qa mort-ora-y

2

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


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

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

0

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


0

ฉันเดาว่าการชะลอตัวของคุณเป็นเพราะคุณกำลังคำนวณเส้นทางสำหรับตัวละครทั้งหมดพร้อมกัน การคำนวณเส้นทางสำหรับตัวละครตัวหนึ่งนั้นรวดเร็ว แต่ถ้ามีตัวละครสองโหลในฉากนั้นก็จะทำให้ชะงัก

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


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

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