Đúc chính tả - Cách tối ưu hóa sát thương mỗi giây


23

Hãy tưởng tượng chúng ta có một phù thủy biết một vài phép thuật. Mỗi phép thuật có 3 thuộc tính: Sát thương, thời gian hạ nhiệt và thời gian sử dụng. Thứ RPG khá chuẩn.

Thời gian hồi chiêu: lượng thời gian (t) cần có trước khi có thể sử dụng lại câu thần chú đó. Một câu thần chú tiếp tục "hồi chiêu" ngay khi nó bắt đầu sử dụng.

Thời gian truyền: lượng thời gian (t) cần để sử dụng một câu thần chú. Trong khi trình hướng dẫn đang truyền một cái gì đó, một câu thần chú khác không thể được sử dụng và nó không thể bị hủy bỏ.

Câu hỏi là: Làm thế nào bạn sẽ tối đa hóa thiệt hại cho các bộ phép thuật khác nhau?

Thật dễ dàng để tính toán thiệt hại cao nhất trên mỗi lần sử dụng. Nhưng còn trong những tình huống tốt hơn là chờ đợi sau đó để bị "mắc kẹt" khi sử dụng một câu thần chú sát thương thấp khi có sẵn một thứ cao hơn nhiều thì sao?

Ví dụ,

  1. Fireball: 3000 sát thương, thời gian cast 3 giây, hạ nhiệt 6 giây.

  2. Frostbolt: 20 sát thương, thời gian cast 4 giây, hạ nhiệt 4 giây.

  3. Fireblast: 3 sát thương, thời gian cast 3 giây, hạ nhiệt 3 giây.

Trong trường hợp này, sát thương mỗi giây của bạn sẽ cao hơn nếu bạn chọn sử dụng phép DPCT thấp hơn (fireblast) thay vì frostbolt. Vì vậy, chúng ta phải xem xét hậu quả của việc chọn một câu thần chú. văn bản thay thế

Trong ví dụ sau đây là các trường hợp "quá đúc" và "chờ đợi". văn bản thay thế


Tại sao tôi phải làm 1-3-1 trong tình huống này? Tại sao không 1-2-1? Tại sao không 1-2-3-1, hiệu quả hơn 1-3-1-X nếu một mình 1-3-1 sẽ không giết được mục tiêu?

@Joe Wreschnig: Cảm ơn bạn đã chỉ ra điều đó. Là một sai lầm trong ví dụ của tôi. Đơn giản hóa nó bây giờ chỉ còn 2 trường hợp.
aaronfarr

1
Tham lam, như trong việc chọn chính tả dps có sẵn cao nhất bất cứ khi nào có thể. Bỏ qua logic khác tức là. đang chờ đợi.
aaronfarr

1
Chỉ để làm vẩn đục nước. Xem xét một câu thần chú gây sát thương, nhưng mất 50 giây để sử dụng. Đó là dps / dpct là ∞, nhưng không bao giờ được chọn nếu mục tiêu có thể bị giết bằng các phương tiện khác trong vòng chưa đầy 50 giây.
deft_code

1
Bạn nên liên kết với bản dupe tại math.stackexchange.com/questions/10414/NH
Sparr

Câu trả lời:


23

Tất cả AI là tìm kiếm!

Khi bạn đi vào can đảm của AI, thật đáng kinh ngạc là nó thực sự tìm kiếm bao nhiêu .

  • trạng thái : thời gian hồi chiêu còn lại của tất cả các phép thuật có sẵn.
  • thể lực : tổng thiệt hại
  • chi phí : tổng thời gian thực hiện
  • các nhánh : bất kỳ phép thuật đã biết. Nếu chính tả vẫn còn trong thời gian hồi chiêu, chỉ cần thêm giá trị đó vào thời gian sử dụng.
  • mục tiêu : tổng sức khỏe của mục tiêu. Mục tiêu phải là một lượng sát thương hữu hạn, vì vậy trong trường hợp mục tiêu không xác định, hãy chọn lượng máu lớn nhất có thể.
    Ngoài ra, mục tiêu có thể mất ít hơn 50 giây và tìm kiếm sẽ tìm thấy thiệt hại tối đa có thể được thực hiện trong 50 giây.

Cắm các tham số này vào Tìm kiếm chi phí thống nhất (UCS) và kế hoạch chiến đấu tối ưu được đảm bảo. Thậm chí tốt hơn nếu bạn có thể đưa ra một heuristic, tìm kiếm bằng A * hoặc IDA * và bạn sẽ nhận được câu trả lời tương tự nhanh hơn nhiều.

Một số lợi thế hơn khi sử dụng UCS là nó có thể tìm thấy thứ tự diễn viên tối ưu cho các tình huống phức tạp hơn nhiều so với cách bạn cung cấp chỉ với 3 biến. Một số khía cạnh khác có thể dễ dàng thêm vào:

  • thiệt hại theo thời gian
  • làm mới phép thuật để giảm thời gian hồi chiêu của các phép thuật khác
  • phép thuật vội vàng gây ra các phép thuật khác để đúc nhanh hơn.
  • tăng cường thiệt hại gây ra các phép thuật khác để làm thiệt hại nhiều hơn.

UCS không toàn năng. Nó không thể mô hình hóa lợi ích của phép thuật bảo vệ. Vì vậy, bạn sẽ phải nâng cấp lên tìm kiếm alpha-beta hoặc minimax.
Ngoài ra, nó không xử lý ảnh hưởng khu vực và chiến đấu nhóm rất tốt. UCS có thể được điều chỉnh để đưa ra giải pháp hợp lý trong những tình huống này, nó không được đảm bảo để tìm giải pháp tối ưu.


2

Đây là một vấn đề tối ưu hóa tổ hợp chuyên biệt. Khi số lượng phép thuật tăng lên, khó khăn trong việc tìm kiếm sự kết hợp / mô hình tối ưu của các phép thuật tăng lên đáng kể. Heuristic tương tự như những gì được sử dụng cho vấn đề ba lô sẽ có giá trị trong việc giải quyết vấn đề này.


1

Bạn cần suy nghĩ về 'sát thương trên một đơn vị thời gian đúc' (DPCT) - ví dụ, một quả cầu lửa với 3 giây và gây ra 3000 sát thương sẽ tạo ra 1000 DPCT.

Nếu bạn phải đợi 3 giây cho thời gian hồi chiêu trước khi sử dụng nó, điều đó sẽ giảm xuống còn 500 DPCT (3000 sát thương, chia cho tổng cộng 6 giây, bao gồm cả thời gian chờ)

Vì vậy, bạn chỉ cần xác định thời gian sát thương mỗi lần sử dụng của mỗi phép, bao gồm cả thời gian chờ còn lại cho thời gian hồi chiêu. Chọn một cái có DPCT cao nhất, Đợi nếu cần, sau đó bỏ nó. Lặp lại cho đến khi ông chủ chết :)


vấn đề là DPCT có thể rất sai lệch. Ví dụ: chúng tôi thêm 2 phép thuật vào hỗn hợp Fireball: 3000 sát thương, 3 giây, thời gian hồi chiêu 6 giây, DPCT: 1000 Spell # 2: 20 sát thương, 4 giây, 4 giây hồi chiêu, DPCT: 5 Spell # 3: 3 sát thương, 3 giây, 3 giây hồi chiêu, DPCT: 1 (hãy nhớ, thời gian hồi chiêu bắt đầu ngay khi phép thuật được sử dụng) Mặc dù Spell # 3 có DPCT thấp hơn nhưng nó sẽ dẫn đến DPS cao hơn (1-3-1-3 .. .) so với Chính tả số 2 (1-2-1-2 ...).
aaronfarr

1

Sử dụng ví dụ của bạn, có lẽ bạn muốn hai phép thuật gần nhau hơn về hiệu quả, nhưng có thể mang lại cho bạn một lợi thế khác. Có thời gian cast ngắn (hoặc không có thời gian cast cho vấn đề đó) sẽ rất hữu ích, vì vậy nó có thể đáng sử dụng ngay cả khi nó ít gây sát thương hơn và mất nhiều thời gian hơn để sử dụng lại.

Bạn luôn có thể áp đặt một yếu tố khác vào phương trình. Mana / Magic Points có thể phục vụ mục đích này, bằng cách cho phép người chơi xác định xem việc sử dụng những điểm đó có xứng đáng với lợi ích hay không.

Nhìn chung, như bluescrn đã nói, DPCT (hay DPS như được gọi trong nhiều trò chơi được điều chỉnh và thảo luận bởi những người chơi đang tìm kiếm sự pha trộn tốt nhất) thực sự là yếu tố chính bạn sẽ muốn cân bằng, đặc biệt là nếu bạn có bất kỳ loại nào cây công nghệ / kỹ năng cho phép người chơi khác nhau tiến bộ với các kỹ năng khác nhau, nhưng với khả năng gây sát thương tương tự tại vị trí nhất định trong trò chơi.


0

Tìm ra thuật toán này hoạt động tốt cho mục đích của tôi.

Mọi người đã đưa ra một số điểm tuyệt vời. Cung cấp cho nó các tham số mục tiêu cuối cùng sẽ cho phép các thuật toán tìm kiếm thông thường thực hiện công việc của chúng. I E. gây sát thương tối ưu trong t giây, làm x sát thương trong thời gian tối ưu.

Thuật toán của tôi chỉ đơn giản trả về chuỗi các phép thuật có DPS cao nhất. Nó là một thuật toán nhanh vì nó cắt giảm kích thước của tập hợp bạn đang duyệt, không yêu cầu kiến ​​thức về các kỹ thuật cây tìm kiếm khác.

Bước đầu tiên là xác định phép thuật có sát thương cao nhất trên mỗi lần sử dụng. Phép thuật này trở thành phép thuật "cơ bản" vì nó sẽ đảm bảo sát thương cao nhất mỗi giây. Có nghĩa là, bạn phải luôn sử dụng phép này nếu đáp ứng 2 điều kiện sau: 1) Chính tả cơ bản có sẵn (không có thời gian hồi chiêu). 2) Bạn hiện không sử dụng một câu thần chú.

Vì vậy, nó trở thành một vấn đề điền vào các phép thuật khác trong khi phép thuật cơ bản là thời gian hồi chiêu. Giữa (thời gian cast) và (thời gian hồi chiêu - thời gian cast). Tuy nhiên, một số chồng chéo có thể xảy ra (quy tắc 2 ở trên là sai).

Sau đó, nó trở thành một vấn đề đệ quy thông qua tất cả các phép thuật không phải là cơ sở để tìm tất cả các chuỗi phép thuật không vi phạm 2 quy tắc.

Đối với các phép thuật trùng lặp DO, bạn phải xử phạt chúng vì thiệt hại tiềm tàng, phép thuật cơ bản có thể đã gây ra (tối đa thiệt hại tối đa của nó).

Lấy ví dụ, 2 phép thuật

Sát thương 1: 300, thời gian cast 3 giây, thời gian hồi chiêu 10 giây

Sát thương 2: 290, thời gian cast 3 giây, thời gian hồi chiêu 3 giây

Thiệt hại lớn nhất đến từ chuỗi 1 - 2 - 2 - 2. Điều này gây ra sự chồng chéo 2 giây thành một diễn viên số 1 tiềm năng. Tuy nhiên, điều này vẫn có lợi vì nếu bạn không sử dụng phép thứ ba (tức là 1 - 2 - 2), bạn sẽ gây sát thương 880 với 1 giây để dự phòng. Nếu bạn sử dụng phép thuật số 2 thêm, bạn sẽ thực hiện 1170 - 2 giây của số 1 là 200. Vì vậy, 970 sát thương là sát thương tương đối của bạn.


-2

Bạn có thể làm một trường hợp chuyển đổi kiểu "cấp độ bảo mật" đơn giản.

Đây chỉ là trên đỉnh đầu của tôi vì vậy hãy cẩn thận các lỗi logic vượt quá mức suy nghĩ trạng thái mệt mỏi của tôi, nhưng tôi hy vọng điều này có thể giúp bạn bắt đầu.

Giả sử thời gian của bạn được thực hiện trong số nguyên khối -

// after casting spell
int remainingTime = (coolDown - castTime);
switch(spellJustCast)
{
  // assuming the cast method will have some input validation for whether the spell
  // is off cooldown or not, pass the time as a parameter
  case 3 : castSpell1(remainingTime);
           castSpell2(remainingTime);
           break;
  case 1 : castSpell2(remainingTime);
           castSpell3(remainingTime);
           break;
  case 2 : castSpell1(remainingTime);
           castSpell3(remainingTime);
           break;
  default: System.out.println("Debug!");
           break;
}

Một số cuộc gọi phương thức là không cần thiết do thời gian chính tả của bạn, nhưng luôn có chỗ để cập nhật theo cách này.

Chỉnh sửa: Tôi mới nhận ra, bạn sẽ cần đặt lại thời gian còn lại sau khi bỏ bùa mới, có lẽ tốt nhất để biến nó thành thuộc tính / trường lớp và đặt nó từ một cuộc gọi trong các phương thức castSpell.


Tôi thực sự không biết bạn đang cố gắng làm gì ở đây, nhưng không có công cụ trò chơi hiện đại nào có chức năng như castSpell1 và castSpell2.

1
@Joe Wreschnig Ý tôi là chúng là phương thức riêng của anh ấy trong các lớp trò chơi tùy chỉnh của anh ấy, đây chỉ là một ví dụ trừu tượng, không phải là một chi tiết.
kymully

1
Phải, đó không phải là cách các phép thuật hoạt động trong các động cơ hiện đại. Có một hàm castSpell lấy một đối tượng có các trường được đọc từ một tệp. Một tuyên bố chuyển đổi như vậy sẽ không thể duy trì trong bất kỳ động cơ thực sự nào, và một số loại thuật toán lập kế hoạch là bắt buộc.

@Joe Wreschnig Tôi hiểu. Tôi chỉ đơn thuần là đưa ra một cách để giải quyết vấn đề. Ví dụ này được viết bằng java, không dành cho động cơ hoặc khung cụ thể. Nhưng nếu nó không thể được thực hiện như bạn nói, câu trả lời của tôi là vô hiệu.
kymully
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.